From nobody Wed Oct 1 00:08:31 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7B01A880E; Wed, 1 Oct 2014 00:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-yjdWXesJyg; Wed, 1 Oct 2014 00:08: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 817761A884A; Wed, 1 Oct 2014 00:08: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 53D66F71; Wed, 1 Oct 2014 09:08: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 EsFg58FVEIVT; Wed, 1 Oct 2014 09:08:12 +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, 1 Oct 2014 09:08:12 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id CA93320036; Wed, 1 Oct 2014 09:08:12 +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 nf_Q8XkiAmzK; Wed, 1 Oct 2014 09:08:12 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CE27520035; Wed, 1 Oct 2014 09:08:11 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A72712EBD548; Wed, 1 Oct 2014 09:08:10 +0200 (CEST) Date: Wed, 1 Oct 2014 09:08:09 +0200 From: Juergen Schoenwaelder To: "Y. Richard Yang" Message-ID: <20141001070809.GA37068@elstar.local> Mail-Followup-To: "Y. Richard Yang" , netmod@ietf.org, IETF ALTO 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: http://mailarchive.ietf.org/arch/msg/netmod/Le122Dv_MlCdAz4O_blaM55drls Cc: IETF ALTO , netmod@ietf.org Subject: Re: [netmod] Key-value data structures in YANG/JSON encoding 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, 01 Oct 2014 07:08:22 -0000 On Tue, Sep 30, 2014 at 04:31:03PM -0400, Y. Richard Yang wrote: > A particular example of using key-value map is the network-map, which is > defined as a key-value store to enforce that each named endpoint address > group has a unique name. A specific example is in Section 11.2.1.7 of RFC > 7285 (http://www.rfc-editor.org/rfc/rfc7285.txt): > > "network-map" : { > "PID1" : { > "ipv4" : [ > "192.0.2.0/24", > "198.51.100.0/25" > ] > }, > "PID2" : { > "ipv4" : [ > "198.51.100.128/25" > ] > }, > "PID3" : { > "ipv4" : [ > "0.0.0.0/0" > ], > "ipv6" : [ > "::/0" > ] > } Since YANG's native encoding is XML, how would you represent this in XML with the restriction that XML element names are defined by the data model and all values are in XML elements? /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 Oct 1 05:09:02 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 474741A035C for ; Wed, 1 Oct 2014 05:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, 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 QvpQluwBezGW for ; Wed, 1 Oct 2014 05:08:59 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 15EAE1A033A for ; Wed, 1 Oct 2014 05:08:59 -0700 (PDT) Received: from localhost (173-38-208-169.cisco.com [173.38.208.169]) by mail.tail-f.com (Postfix) with ESMTPSA id BD4BF1280997 for ; Wed, 1 Oct 2014 14:08:57 +0200 (CEST) Date: Wed, 01 Oct 2014 14:08:56 +0200 (CEST) Message-Id: <20141001.140856.2030093089379385909.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: http://mailarchive.ietf.org/arch/msg/netmod/uxkM6DMlZoh3o8Nd9pQ79FhFL_Y Subject: [netmod] virtual interim X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 01 Oct 2014 12:09:01 -0000 Hi, I am confused. This message http://www.ietf.org/mail-archive/web/netmod/current/msg10638.html says we have a meeting today, but this one http://www.ietf.org/mail-archive/web/netmod/current/msg10724.html says the next meeting is next week. Do we have a meeting today? (if so, what is the agenda?) /martin From nobody Wed Oct 1 05:11:59 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA111A033A for ; Wed, 1 Oct 2014 05:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwY3_mKza_t7 for ; Wed, 1 Oct 2014 05:11:53 -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 E6D631A0331 for ; Wed, 1 Oct 2014 05:11: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 0458CF9C; Wed, 1 Oct 2014 14:11:51 +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 WF0Cdr_wu_Of; Wed, 1 Oct 2014 14:11:50 +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, 1 Oct 2014 14:11:50 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9302D20037; Wed, 1 Oct 2014 14:11:50 +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 O4EhtpN5JPTI; Wed, 1 Oct 2014 14:11:49 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4CECE20035; Wed, 1 Oct 2014 14:11:49 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 95D692EBDAB0; Wed, 1 Oct 2014 14:11:48 +0200 (CEST) Date: Wed, 1 Oct 2014 14:11:48 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20141001121148.GB37998@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20141001.140856.2030093089379385909.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141001.140856.2030093089379385909.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Pf3CWsuqmvc5ObosfCWV56SjmUU Cc: netmod@ietf.org Subject: Re: [netmod] virtual interim 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, 01 Oct 2014 12:11:55 -0000 On Wed, Oct 01, 2014 at 02:08:56PM +0200, Martin Bjorklund wrote: > Hi, > > I am confused. This message > http://www.ietf.org/mail-archive/web/netmod/current/msg10638.html says > we have a meeting today, but this one > http://www.ietf.org/mail-archive/web/netmod/current/msg10724.html says > the next meeting is next week. > > Do we have a meeting today? (if so, what is the agenda?) We have a meeting today to work on YANG 1.1 as we discussed in New York and as it is written down in the New York meeting minutes. The first meeting to discuss data models organized by Tom will be on October 8th. /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 Oct 1 07:02:05 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 985521ACDAD for ; Wed, 1 Oct 2014 07:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.335 X-Spam-Level: X-Spam-Status: No, score=-2.335 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786, 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 GeQ_OA1aT8yB for ; Wed, 1 Oct 2014 07:02: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 B6CE11A87E2 for ; Wed, 1 Oct 2014 07:02:01 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6CDEBFA6 for ; Wed, 1 Oct 2014 16:02: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 B6j4C-i09aNu for ; Wed, 1 Oct 2014 16:01:59 +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, 1 Oct 2014 16:01:59 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id BFC5B20038 for ; Wed, 1 Oct 2014 16:01:59 +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 s4LYWtnkJOyM; Wed, 1 Oct 2014 16:01: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 D529020036; Wed, 1 Oct 2014 16:01:58 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C9C652EBDF05; Wed, 1 Oct 2014 16:01:58 +0200 (CEST) Date: Wed, 1 Oct 2014 16:01:58 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20141001140158.GA38460@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: http://mailarchive.ietf.org/arch/msg/netmod/tUQlNNQlPavKG8NBTz1vw6TmqDg Subject: [netmod] virtual interim meeting input 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, 01 Oct 2014 14:02:04 -0000 Hi, I have updated the issues list and we now have a number of issues in the EDIT state (means Martin needs to make the edits) and we have still some open issue left. I like to go through the following list today (lets see how far we get): ** Y23 Do we have consensus to do Y23-03? Do we also add modifier ignore-case? This seems natural and was part of the mailing list discussion, but it is not part of Y23-03. Will this affect DSDL mappings, is this easy to support there? ** Y25 An intense discussion on the mailing list. Key observation is that there is no way to turn auto-numbering off in case it hurts (and this WG knows that there are situations where it can hurt). Lada suggested a modifier 'auto-numbering true/false' with a default of true but Martin still does not like it (because then his code has to support both options anyway). MB's suggesting to remove value and position statements seems strange given that they are fine, it is just the auto-numbering that is problematic. ** Y10 Resolution of the syntax issue. ** Y05: Needs discussion (Y05-03 added) ** Y12: unclear ** Y13: LL action pending? ** Y16: MB to check Y16-02? ** Y18: (LL action done) ** Y26: unclear how to proceed ** Y28: AB action item ** Y34: AB action item, but move to EDIT? ** Y49: MB wrote Y49-03, discuss again We may want to use etherpad for joint note taking. http://etherpad.tools.ietf.org:9000/p/notes-ietf-netmod-virtual-interim-2014-10-01?useMonospaceFont=true /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 Oct 1 07:17:10 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9344C1ACDC0 for ; Wed, 1 Oct 2014 07:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.136 X-Spam-Level: X-Spam-Status: No, score=-1.136 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, RP_MATCHES_RCVD=-0.786, WEIRD_PORT=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 DxpaPSiYnUPr for ; Wed, 1 Oct 2014 07:17:04 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 734381ACDBE for ; Wed, 1 Oct 2014 07:17:04 -0700 (PDT) Received: from [172.29.2.202] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id C2E30140504; Wed, 1 Oct 2014 16:17:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1412173022; bh=/TJadUGfV0VbRyc76qE81H4Pm8ZALbdsaegX28oQcb4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ts1DLai4JDlZnz/XD0vNQCT3PXjNqbIsDKODJnQ0HRPZjqbgYxpPOebpk+UMib0RM tJDRe3pXTTki/JioHFWNc+v2xABhjFFFl7LkHr4SMAiPopfETD/RiI4s2Oo92vxhOr U70Yfw9ruw8qtWUxUWbu61pRII34VQmooPTLTPJQ= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <20141001140158.GA38460@elstar.local> Date: Wed, 1 Oct 2014 16:17:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141001140158.GA38460@elstar.local> To: =?iso-8859-1?Q?J=FCrgen_Sch=F6nw=E4lder?= X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/DFOQGzthyzE_N8w9iwG5TS_3Z_E Cc: netmod@ietf.org Subject: Re: [netmod] virtual interim meeting input X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 01 Oct 2014 14:17:06 -0000 Hi, it seems two groups of people are waiting at different webex telcos. :-( What is the authoritative URL where we all can meet? Lada On 01 Oct 2014, at 16:01, Juergen Schoenwaelder = wrote: > Hi, >=20 > I have updated the issues list and we now have a number of issues in > the EDIT state (means Martin needs to make the edits) and we have > still some open issue left. I like to go through the following list > today (lets see how far we get): >=20 > ** Y23 >=20 > Do we have consensus to do Y23-03? Do we also add modifier > ignore-case? This seems natural and was part of the mailing list > discussion, but it is not part of Y23-03. Will this affect DSDL > mappings, is this easy to support there? >=20 > ** Y25 >=20 > An intense discussion on the mailing list. Key observation is that > there is no way to turn auto-numbering off in case it hurts (and > this WG knows that there are situations where it can hurt). Lada > suggested a modifier 'auto-numbering true/false' with a default of > true but Martin still does not like it (because then his code has > to support both options anyway). MB's suggesting to remove value > and position statements seems strange given that they are fine, it > is just the auto-numbering that is problematic. >=20 > ** Y10 >=20 > Resolution of the syntax issue. >=20 > ** Y05: Needs discussion (Y05-03 added) >=20 > ** Y12: unclear >=20 > ** Y13: LL action pending? >=20 > ** Y16: MB to check Y16-02? >=20 > ** Y18: (LL action done) >=20 > ** Y26: unclear how to proceed >=20 > ** Y28: AB action item >=20 > ** Y34: AB action item, but move to EDIT? >=20 > ** Y49: MB wrote Y49-03, discuss again >=20 > We may want to use etherpad for joint note taking. >=20 > = http://etherpad.tools.ietf.org:9000/p/notes-ietf-netmod-virtual-interim-20= 14-10-01?useMonospaceFont=3Dtrue >=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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Oct 1 07:17:48 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57D111ACDC1 for ; Wed, 1 Oct 2014 07:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.326 X-Spam-Level: X-Spam-Status: No, score=-2.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786, T_FILL_THIS_FORM_SHORT=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 EriRtePzmgS6 for ; Wed, 1 Oct 2014 07:17: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 CF8C41ACDB9 for ; Wed, 1 Oct 2014 07:17:36 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A0C3BF99 for ; Wed, 1 Oct 2014 16:17: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 gXhTWoqJhyUd for ; Wed, 1 Oct 2014 16:17: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 ; Wed, 1 Oct 2014 16:17:34 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id EA82B20035 for ; Wed, 1 Oct 2014 16:17:34 +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 m1FW_iSTDGdq; Wed, 1 Oct 2014 16:17:33 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6CAFF20036; Wed, 1 Oct 2014 16:17:33 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 620332EBE003; Wed, 1 Oct 2014 16:17:33 +0200 (CEST) Date: Wed, 1 Oct 2014 16:17:33 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20141001141733.GC38460@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="4Ckj6UjgE2iN1+kY" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Grqzl4BwjY2ZTvjmsF2je7sD17k Subject: [netmod] virtual interim meeting webex 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, 01 Oct 2014 14:17:43 -0000 --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, here is again the webex information in case you lost it or went somewhere else. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="netmod-webex.txt" Topic: NETMOD WG Date: Every Wednesday, from Wednesday, August 27, 2014 to Wednesday, October 22, 2014 Time: 4:00 pm, Europe Summer Time (Berlin, GMT+02:00) Meeting Number: 649 102 111 Meeting Password: 1234 ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/j.php?MTID=mbbe9c321c8e9f472df4ce74c1987a0f0 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: 1234 4. Click "Join". 5. Follow the instructions that appear on your screen. To view in other time zones or languages, please click the link: https://ietf.webex.com/ietf/j.php?MTID=me720293ef5473cc3bf963302b2f6a8f1 ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- Call-in toll number (US/Canada): 1-650-479-3208 Access code:649 102 111 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/mc 2. On the left navigation bar, click "Support". You can contact me at: cmorgan@amsl.com 1-510-492-4085 To update this meeting to your calendar program (for example Microsoft Outlook), click this link: https://ietf.webex.com/ietf/j.php?MTID=m4f877f2e629b841380e2d593e4e39b87 WebEx will automatically setup Meeting Manager for Windows the first time you join a meeting. To save time, you can setup prior to the meeting by clicking this link: https://ietf.webex.com/ietf/meetingcenter/mcsetup.php The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php. http://www.webex.com CCP:+16504793208x649102111# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. --4Ckj6UjgE2iN1+kY-- From nobody Wed Oct 1 12:08:32 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34BB81A1A8F; Wed, 1 Oct 2014 12:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHoJsRuU_Nt6; Wed, 1 Oct 2014 12:08:10 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6B091A8029; Wed, 1 Oct 2014 12:08:08 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id hi2so1722523wib.8 for ; Wed, 01 Oct 2014 12:08:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=P81s8Vncmdnf7EBbuzkuJJH7r8j/KQ7TDz71Za/nMSw=; b=yMjDgsDM6BASJZVA5JQLTSaK9jMnja9xmpmCR3qoakALwge5a/UpIqqRPUNNL0VzOA EklXAlZ+BF+mZ76HwUCoeFeAAEGS6vyyAGqgAkp+S0HjQf+XwlSUnPWRkF7OOKk5UbXU aFq7dEq2qlMyE32yMSQq4kAVzv2ca9rAoScWd2Mbjg135X6N2okkDAlPXtdGz66bKLb9 tSEpnLSlc8zUps5cWFEsKzv3Rv9BsWVeqQOv29RZxJvpHKgxwq/fKyQJRRn0EQEzvQHg YLvrsiavWdeDsjP/el8Be59zRT7APIzZ5GbRrifQK2OPmp6UOcvwuS+YmeZeqdIx91MB hw3g== MIME-Version: 1.0 X-Received: by 10.180.79.34 with SMTP id g2mr16850712wix.10.1412190487596; Wed, 01 Oct 2014 12:08:07 -0700 (PDT) Sender: yang.r.yang@gmail.com Received: by 10.27.178.161 with HTTP; Wed, 1 Oct 2014 12:08:07 -0700 (PDT) In-Reply-To: <6882466.1412133800694.JavaMail.root@mswamui-chipeau.atl.sa.earthlink.net> References: <6882466.1412133800694.JavaMail.root@mswamui-chipeau.atl.sa.earthlink.net> Date: Wed, 1 Oct 2014 15:08:07 -0400 X-Google-Sender-Auth: vyDGg_DNeDCoEGjvF41YBywQjvU Message-ID: From: "Y. Richard Yang" To: Randy Presuhn Content-Type: multipart/alternative; boundary=f46d041825d85e55d405046138b9 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/xEtslFPXWpVqUYPM3v6wefuL_f8 Cc: IETF ALTO , netmod@ietf.org Subject: Re: [netmod] Key-value data structures in YANG/JSON encoding X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 01 Oct 2014 19:08:12 -0000 --f46d041825d85e55d405046138b9 Content-Type: text/plain; charset=UTF-8 On Tue, Sep 30, 2014 at 11:23 PM, Randy Presuhn < randy_presuhn@mindspring.com> wrote: > Hi - > > >From: "Y. Richard Yang" > >Sent: Sep 30, 2014 2:48 PM > >To: Andy Bierman > >Cc: IETF ALTO , netmod@ietf.org > >Subject: Re: [netmod] Key-value data structures in YANG/JSON encoding > ... > >more general issue regarding completeness of data types in YANG: > > > >- list is an ordered array > > > >- container is a static, heterogeneous associate array > ... > > Why do you say "static"? > > It is my relative aspect, comparing list and container. The additional substatements to list (key, max-, min-elements, ordered-by, and unique) appear to me to enable more dynamic operations (the introduction of key allows insert first, last, before, after) and provide more consistency during and post dynamics (max-, min- check size, unique check duplicate, resort if ordered by). As a contrast, container is more like a (static) class definition in C++/java to provide simpler bundling. Of course, it still supports basic edit-config operations, and hence in this sense is not static at all. I am curious on if there were discussions during the design on introducing these two different types of interior nodes. In the context of key-value store example, we need the key substatement to indicate the key, and hence need to use list, but then need to implement the additional APIs such as insert first/last/before/after which have no meaning for a key value store. In other words, the key-value store appears to be a setting that may not need the helping-with-dynamic part. Richard --f46d041825d85e55d405046138b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Sep 30, 2014 at 11:23 PM, Randy Presuhn <randy_presuhn@= mindspring.com> wrote:
Hi -

>From: "Y. Richard Yang" <yry@cs.yale.edu>
>Sent: Sep 30, 2014 2:48 PM
>To: Andy Bierman <andy@yumawor= ks.com>
>Cc: IETF ALTO <alto@ietf.org>= ;, netmod@ietf.org
>Subject: Re: [netmod] Key-value data structures in YANG/JSON encoding ...
>more general issue regarding completeness of data type= s in YANG:
>
>- list is an ordered array
>
>- container is a static, heterogeneous associate array
...

Why do you say "static"?


It is my relative aspect, comparing list and container. Th= e additional substatements to list (key, max-, min-elements, ordered-by, an= d unique) appear to me to enable more dynamic operations (the introduction = of key allows insert first, last, before, after) and provide more consisten= cy during and post dynamics (max-, min- check size, unique check duplicate,= resort if ordered by). As a contrast, container is more like a (static) cl= ass definition in C++/java to provide simpler bundling. Of course, it still= supports basic edit-config operations, and hence in this sense is not stat= ic at all.

I am curious on if there were discussio= ns during the design on introducing these two different types of interior n= odes.=C2=A0

In the context of key-value store exam= ple, we need the key substatement to indicate the key, and hence need to us= e list, but then need to implement the additional APIs such as insert first= /last/before/after which have no meaning for a key value store. In other wo= rds, =C2=A0the key-value store appears to be a setting that may not need th= e helping-with-dynamic part.

Richard

--f46d041825d85e55d405046138b9-- From nobody Wed Oct 1 12:24:00 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92D161A701E; Wed, 1 Oct 2014 12:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.276 X-Spam-Level: X-Spam-Status: No, score=-1.276 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=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 KxehRJSse9YQ; Wed, 1 Oct 2014 12:23:51 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BA871A7005; Wed, 1 Oct 2014 12:23:50 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id ho1so1713797wib.10 for ; Wed, 01 Oct 2014 12:23:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=0R260bKPwJ5cGSyBD2utdymzFH0iB3TA32IHjqyuTCU=; b=TAEnrvlbc6jaAdPdveZ6V8lq/vincd+4kpZTdnbuPyKfNxRrUxbK3DCIkzjHKz6yV1 sPjrCiJSiIN60GhvchzOoBSU5IUv8YwbNvd1sJOg6bQmJ6Gz5EZ+xC5xWgKUe8zcmAhD MI05ddgBEAxmcDo5LxwK+TEkzVPQwGH34U5SFvttN1cljp5xc6SkVC521zkWzsLwdx7e aJdPUOFrqtr+5hlSvIX7TEA9nZKEmR6XOv0SvVm1pNCnH/eU43AtcigkSgf3129/B4ys fN0p9NCWdnWFjJRxX7LLpyya1mctGD51olXOwrCSb5L25MEg6mAidqkWnGhJbHq9N7D4 qTIw== MIME-Version: 1.0 X-Received: by 10.194.110.33 with SMTP id hx1mr66274230wjb.12.1412191429095; Wed, 01 Oct 2014 12:23:49 -0700 (PDT) Sender: yang.r.yang@gmail.com Received: by 10.27.178.161 with HTTP; Wed, 1 Oct 2014 12:23:49 -0700 (PDT) In-Reply-To: <20141001070809.GA37068@elstar.local> References: <20141001070809.GA37068@elstar.local> Date: Wed, 1 Oct 2014 15:23:49 -0400 X-Google-Sender-Auth: _A7r2FpZ78cOg2NKAh8gubnP3WE Message-ID: From: "Y. Richard Yang" To: Juergen Schoenwaelder , "Y. Richard Yang" , netmod@ietf.org, IETF ALTO Content-Type: multipart/alternative; boundary=089e010d861a7c793c05046170e2 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/XPdggr8z13uEiHt7anZxhis4GIk Subject: Re: [netmod] Key-value data structures in YANG/JSON encoding X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 01 Oct 2014 19:23:52 -0000 --089e010d861a7c793c05046170e2 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 1, 2014 at 3:08 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Sep 30, 2014 at 04:31:03PM -0400, Y. Richard Yang wrote: > > > A particular example of using key-value map is the network-map, which is > > defined as a key-value store to enforce that each named endpoint address > > group has a unique name. A specific example is in Section 11.2.1.7 of RFC > > 7285 (http://www.rfc-editor.org/rfc/rfc7285.txt): > > > > "network-map" : { > > "PID1" : { > > "ipv4" : [ > > "192.0.2.0/24", > > "198.51.100.0/25" > > ] > > }, > > "PID2" : { > > "ipv4" : [ > > "198.51.100.128/25" > > ] > > }, > > "PID3" : { > > "ipv4" : [ > > "0.0.0.0/0" > > ], > > "ipv6" : [ > > "::/0" > > ] > > } > > Since YANG's native encoding is XML, how would you represent this in > XML with the restriction that XML element names are defined by the > data model and all values are in XML elements? > Would you consider this as a limitation of the restriction? With the restriction, if we have the YANG data type to introduce key-value store, for XML, the Mapping Rule may still be that of using two elements with name and value: pid-name = (or just key as name), pid-value = (or value). But for json and languages that support maps, the mapping does not. Make sense? Richard > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 --089e010d861a7c793c05046170e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Oct 1, 2014 at 3:08 AM, Juergen Schoenwaelder <j.sc= hoenwaelder@jacobs-university.de> wrote:
On Tue, Sep 30, 2014 at 04:31:03PM -0400, Y.= Richard Yang wrote:

> A particular example of using key-value map is the network-map, which = is
> defined as a key-value store to enforce that each named endpoint addre= ss
> group has a unique name. A specific example is in Section 11.2.1.7 of = RFC
> 7285 (http://www.rfc-editor.org/rfc/rfc7285.txt):
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "network-map" : {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "PID1" : {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "ipv4" : [ >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "192.0.2.0/24",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "198.51.100.0/25"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 },
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "PID2" : {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "ipv4" : [ >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "198.51.100.128/25"=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 },
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "PID3" : {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "ipv4" : [ >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "0.0.0.0/0"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ],
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "ipv6" : [ >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "::/0"= ;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }

Since YANG's native encoding is XML, how would you represent thi= s in
XML with the restriction that XML element names are defined by the
data model and all values are in XML elements?

Would you consider this as a limitation of the restriction?

With the restriction, if we have the YANG data type to in= troduce key-value store, for XML, the Mapping Rule may still be that of usi= ng two elements with name and value: pid-name =3D (or just key as name), pi= d-value =3D (or value). But for json and languages that support maps, the m= apping does not. Make sense?

Richard

=C2=A0

/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 Bre= men, Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-univ= ersity.de/>
--089e010d861a7c793c05046170e2-- From nobody Thu Oct 2 00:15:35 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D89201A0107; Thu, 2 Oct 2014 00:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4v_M8v96dEVn; Thu, 2 Oct 2014 00:15: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 195531A00FE; Thu, 2 Oct 2014 00:15:30 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 90E32FA4; Thu, 2 Oct 2014 09:15:28 +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 esuT-HtRvpHE; Thu, 2 Oct 2014 09:15: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; Thu, 2 Oct 2014 09:15:27 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 575E920037; Thu, 2 Oct 2014 09:15:26 +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 zNmGiMtTT4Rw; Thu, 2 Oct 2014 09:15:25 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3D01320036; Thu, 2 Oct 2014 09:15:24 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2B9BC2EBFA8A; Thu, 2 Oct 2014 09:15:23 +0200 (CEST) Date: Thu, 2 Oct 2014 09:15:23 +0200 From: Juergen Schoenwaelder To: "Y. Richard Yang" Message-ID: <20141002071522.GA40160@elstar.local> Mail-Followup-To: "Y. Richard Yang" , netmod@ietf.org, IETF ALTO References: <20141001070809.GA37068@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: http://mailarchive.ietf.org/arch/msg/netmod/ugXHkV-Yb0iuUVCW7ucHwEFMbE4 Cc: IETF ALTO , netmod@ietf.org Subject: Re: [netmod] Key-value data structures in YANG/JSON encoding 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, 02 Oct 2014 07:15:33 -0000 On Wed, Oct 01, 2014 at 03:23:49PM -0400, Y. Richard Yang wrote: > On Wed, Oct 1, 2014 at 3:08 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > On Tue, Sep 30, 2014 at 04:31:03PM -0400, Y. Richard Yang wrote: > > > > > A particular example of using key-value map is the network-map, which is > > > defined as a key-value store to enforce that each named endpoint address > > > group has a unique name. A specific example is in Section 11.2.1.7 of RFC > > > 7285 (http://www.rfc-editor.org/rfc/rfc7285.txt): > > > > > > "network-map" : { > > > "PID1" : { > > > "ipv4" : [ > > > "192.0.2.0/24", > > > "198.51.100.0/25" > > > ] > > > }, > > > "PID2" : { > > > "ipv4" : [ > > > "198.51.100.128/25" > > > ] > > > }, > > > "PID3" : { > > > "ipv4" : [ > > > "0.0.0.0/0" > > > ], > > > "ipv6" : [ > > > "::/0" > > > ] > > > } > > > > Since YANG's native encoding is XML, how would you represent this in > > XML with the restriction that XML element names are defined by the > > data model and all values are in XML elements? > > > > Would you consider this as a limitation of the restriction? > > With the restriction, if we have the YANG data type to introduce key-value > store, for XML, the Mapping Rule may still be that of using two elements > with name and value: pid-name = (or just key as name), pid-value = (or > value). But for json and languages that support maps, the mapping does not. > Make sense? > I am saying that YANG was designed to model data carried by NETCONF (check the title of RFC 6020) and NETCONF uses XML as its data encoding with a set of restrictions that were found useful to simplify things (all data in XML elements, no mixed content, ...). Several details of the YANG language are related to XML (e.g., much of the type system, the usage of xpath in must/when expressions, instance identifier as a subset of xpath, ...). Alternate _encodings_ are proposed (such as JSON) but the question raised here seems to be whether we want to start an effort to turn YANG into a schema language for JSON (which it is not today and this is by design and not by accident). /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 Oct 2 01:31:51 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38E161A01D5; Thu, 2 Oct 2014 01:31: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 DBVXeXoIhjUn; Thu, 2 Oct 2014 01:31:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CCAE1A002D; Thu, 2 Oct 2014 01:31:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141002083148.1436.15021.idtracker@ietfa.amsl.com> Date: Thu, 02 Oct 2014 01:31:48 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/u6VXfuuOvs2-HHkHBeTrOAAAZ-E Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-01.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, 02 Oct 2014 08:31:49 -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 : YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) Author : Martin Bjorklund Filename : draft-ietf-netmod-rfc6020bis-01.txt Pages : 180 Date : 2014-10-02 Abstract: YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. This document obsoletes RFC 6020. 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: http://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6020bis-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/ From nobody Thu Oct 2 01:37:06 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7AA61A01B0 for ; Thu, 2 Oct 2014 01:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, 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 sbJcAx1BMtnV for ; Thu, 2 Oct 2014 01:36:44 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 866DC1A01D5 for ; Thu, 2 Oct 2014 01:36:44 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 8E8F6128098C for ; Thu, 2 Oct 2014 10:36:43 +0200 (CEST) Date: Thu, 02 Oct 2014 10:36:43 +0200 (CEST) Message-Id: <20141002.103643.614023022702737829.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <20141002083148.1436.15021.idtracker@ietfa.amsl.com> References: <20141002083148.1436.15021.idtracker@ietfa.amsl.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: http://mailarchive.ietf.org/arch/msg/netmod/WLgK8Ls0h3rQsJzb7f9yo8gWOeQ Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-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: Thu, 02 Oct 2014 08:36:55 -0000 Hi, I have posted draft-ietf-netmod-rfc6020bis-01.txt, which addresses 11 of our issues. These issues are now in the REVIEW state in the issues list (https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html) Please review the draft or the diff to make sure that these issues are properly addressed. When these are reviewed, I will post a new version with a new set of issues addressed. /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 : YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) > Author : Martin Bjorklund > Filename : draft-ietf-netmod-rfc6020bis-01.txt > Pages : 180 > Date : 2014-10-02 > > Abstract: > YANG is a data modeling language used to model configuration and > state data manipulated by the Network Configuration Protocol > (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. > This document obsoletes RFC 6020. > > > 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: > http://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6020bis-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/ > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Thu Oct 2 01:46:07 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC3941A002D; Thu, 2 Oct 2014 01:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, 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 terIytZfbtNi; Thu, 2 Oct 2014 01:46:04 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id C5EFE1A0211; Thu, 2 Oct 2014 01:46:03 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 153EC128097C; Thu, 2 Oct 2014 10:46:03 +0200 (CEST) Date: Thu, 02 Oct 2014 10:46:02 +0200 (CEST) Message-Id: <20141002.104602.316004437093709527.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20141002071522.GA40160@elstar.local> References: <20141001070809.GA37068@elstar.local> <20141002071522.GA40160@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: http://mailarchive.ietf.org/arch/msg/netmod/5EdtdVgC3rnSUfZMUpvSCqpWjas Cc: alto@ietf.org, netmod@ietf.org Subject: Re: [netmod] Key-value data structures in YANG/JSON encoding X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 02 Oct 2014 08:46:06 -0000 Juergen Schoenwaelder wrote: > On Wed, Oct 01, 2014 at 03:23:49PM -0400, Y. Richard Yang wrote: > > On Wed, Oct 1, 2014 at 3:08 AM, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > On Tue, Sep 30, 2014 at 04:31:03PM -0400, Y. Richard Yang wrote: > > > > > > > A particular example of using key-value map is the network-map, which is > > > > defined as a key-value store to enforce that each named endpoint address > > > > group has a unique name. A specific example is in Section 11.2.1.7 of RFC > > > > 7285 (http://www.rfc-editor.org/rfc/rfc7285.txt): > > > > > > > > "network-map" : { > > > > "PID1" : { > > > > "ipv4" : [ > > > > "192.0.2.0/24", > > > > "198.51.100.0/25" > > > > ] > > > > }, > > > > "PID2" : { > > > > "ipv4" : [ > > > > "198.51.100.128/25" > > > > ] > > > > }, > > > > "PID3" : { > > > > "ipv4" : [ > > > > "0.0.0.0/0" > > > > ], > > > > "ipv6" : [ > > > > "::/0" > > > > ] > > > > } > > > > > > Since YANG's native encoding is XML, how would you represent this in > > > XML with the restriction that XML element names are defined by the > > > data model and all values are in XML elements? > > > > > > > Would you consider this as a limitation of the restriction? > > > > With the restriction, if we have the YANG data type to introduce key-value > > store, for XML, the Mapping Rule may still be that of using two elements > > with name and value: pid-name = (or just key as name), pid-value = (or > > value). But for json and languages that support maps, the mapping does not. > > Make sense? > > > > I am saying that YANG was designed to model data carried by NETCONF > (check the title of RFC 6020) and NETCONF uses XML as its data > encoding with a set of restrictions that were found useful to simplify > things (all data in XML elements, no mixed content, ...). Several > details of the YANG language are related to XML (e.g., much of the > type system, the usage of xpath in must/when expressions, instance > identifier as a subset of xpath, ...). > > Alternate _encodings_ are proposed (such as JSON) but the question > raised here seems to be whether we want to start an effort to turn > YANG into a schema language for JSON (which it is not today and this > is by design and not by accident). I think the question is if it would be a good idea to add a "map" keyword to YANG. Then, if we have "map", we can decide how to encode it in XML and JSON. For the record, I do not think we should add this. I am not sure when it is a good idea to model an open-ended map (i.e., with keys that are not formally defined). In many cases I think it is better with something like: list my-map { key "key"; leaf key { type identityref { ... } // this means all keys are // formally defined in YANG } leaf value { type string; } } /martin From nobody Thu Oct 2 02:31:03 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBFA51A01F7 for ; Thu, 2 Oct 2014 02:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tU3pK3ZR7aGt for ; Thu, 2 Oct 2014 02:30: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 718751A005C for ; Thu, 2 Oct 2014 02:30:56 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 4456B7F8; Thu, 2 Oct 2014 11:30: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 2_UiKRVXk559; Thu, 2 Oct 2014 11:30: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, 2 Oct 2014 11:30:54 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9A0F020036; Thu, 2 Oct 2014 11:30:54 +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 ldeHqFQ_rG8B; Thu, 2 Oct 2014 11:30:53 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8BB2220035; Thu, 2 Oct 2014 11:30:53 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7B8F02EBFF52; Thu, 2 Oct 2014 11:30:53 +0200 (CEST) Date: Thu, 2 Oct 2014 11:30:53 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20141002093053.GB40545@elstar.local> Mail-Followup-To: netmod@ietf.org, Martin Bjorklund References: <20141002083148.1436.15021.idtracker@ietfa.amsl.com> <20141002.103643.614023022702737829.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141002.103643.614023022702737829.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/i253W9jWr_btXLWvTTZywZJbNDU Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-01.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: Thu, 02 Oct 2014 09:31:01 -0000 On Thu, Oct 02, 2014 at 10:36:43AM +0200, Martin Bjorklund wrote: > Hi, > > I have posted draft-ietf-netmod-rfc6020bis-01.txt, which addresses 11 > of our issues. These issues are now in the REVIEW state in the issues > list (https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html) > > Please review the draft or the diff to make sure that these issues are > properly addressed. When these are reviewed, I will post a new > version with a new set of issues addressed. > WG members, once you have reviewed the changes, send a short note to the list so that we can track that reviews of the edits have been done. /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 Oct 2 03:06:23 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E39481A02BA for ; Thu, 2 Oct 2014 03:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOm53-9XqENt for ; Thu, 2 Oct 2014 03:06:21 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFF141A029D for ; Thu, 2 Oct 2014 03:06:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=974; q=dns/txt; s=iport; t=1412244382; x=1413453982; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=2aUt6NZCpBMFrCtzimeOlTHLaK7iQhoY9+MOfUYu6FA=; b=ZVTixbzAkccRAMJdh5bvl5lyBrGO+e2bG+A/U2k9xPyYN3dNtTxJ8jpR EAsMs/U9dcw3+pj5pX0nXl+zNYevxf4S5lkKurXm/Z3XmCw9WXVBONQoe i3OelFnWjEY7JafOQqE1RtGBHfUbxhN8mNoJ3iXz1JMGZolo3AX43QlFZ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsGAFUjLVStJV2T/2dsb2JhbABggmsjgTDTPBYBcgmECjpRAT5CJwQuiCMBlzilWJR4BZFti0aVc4NjgjSBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,638,1406592000"; d="scan'208";a="356974445" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-9.cisco.com with ESMTP; 02 Oct 2014 10:06:01 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s92A60A3021030 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 2 Oct 2014 10:06:00 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Thu, 2 Oct 2014 05:06:00 -0500 From: "William Lupton (wilupton)" To: "netmod@ietf.org" Thread-Topic: Mandatory and optional ranges Thread-Index: AQHP3ih3IT74Ah1ZGECTWzsVHNUgKw== Date: Thu, 2 Oct 2014 10:05:59 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [10.55.121.115] Content-Type: text/plain; charset="us-ascii" Content-ID: <22F064B76CED0443BB6CC0EEAA6ADE76@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/VCU1necewVvxEPP9T5mdBH19a2I Subject: [netmod] Mandatory and optional ranges X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 02 Oct 2014 10:06:23 -0000 All, Someone asked me whether a YANG definition can distinguish the parts of a range that are mandatory and the parts that are optional, e.g an int leaf XXX might be required to support 1..10 but 11..20 might be optional. It seems that being able to associate 11..20 with a feature would be a nice solution and would be equivalent to YANG 1.1 Y11 (allow if-feature on enums)? But I don't think that range "1..10|11..20" can be split into multiple range statements, so this would not be trivial? A use case from the DSL world (I can't be too specific) is where the valid values for two leaf nodes are coupled. If leaf WWW =3D 1 then XXX =3D 1..1= 0 but if leaf WWW =3D 2 then XXX =3D 11..20. A future module version might a= dd WWW =3D 3 and tie it to XXX =3D 21..30. I suppose that a "must" statement could be used (?) but I quite like the feature approach, especially given the analogy with YANG 1.1 Y11. Comments? Thanks, William Lupton From nobody Thu Oct 2 05:08:28 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76B2A1A1BF0 for ; Thu, 2 Oct 2014 05:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.564 X-Spam-Level: X-Spam-Status: No, score=0.564 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_45=0.6, MANGLED_LOAN=2.3, RP_MATCHES_RCVD=-0.786] 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 IH6kwXTmcsHj for ; Thu, 2 Oct 2014 05:08:08 -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 6EF081A1C03 for ; Thu, 2 Oct 2014 05:08: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 434C2902 for ; Thu, 2 Oct 2014 14:08: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 M-fGAACK3YVL for ; Thu, 2 Oct 2014 14:08: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 for ; Thu, 2 Oct 2014 14:08:04 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5B0ED20035 for ; Thu, 2 Oct 2014 14:08:04 +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 L9z_SWkTiUYH; Thu, 2 Oct 2014 14:08: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 C2E3120038; Thu, 2 Oct 2014 14:08:02 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 01EAE2EC0945; Thu, 2 Oct 2014 14:08:01 +0200 (CEST) Date: Thu, 2 Oct 2014 14:08:01 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20141002120801.GA41278@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="VbJkn9YxBvnuCH5J" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ExWELkntT6pvHQHC1fQc3aJXR5A Subject: [netmod] draft minutes of the NETMOD 2014-10-01 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: Thu, 02 Oct 2014 12:08:14 -0000 --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, attached are the draft minutes of yesterday's virtual interim meeting. Please let me know if something needs fixing by the beginning of next week so that I can send the final version to the secretariat. You can also 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 --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="netmod-2014-10-01-minutes.txt" ============================================================= NETCONF Data Modeling Language WG (netmod) 5th YANG 1.1 Virtual Interim Wednesday, October 1st, 2014, 16:00-18:00 CEST Minutes Juergen Schoenwaelder ============================================================= * Participants - AB = Andy Bierman - PH = Peter van Horne - JS = Juergen Schoenwaelder - LL = Lada Lhotka - DR = David Reid - KW = Kent Watsen - MJ = Mahesh Jethanandani - EV = Eric Volt status check of the action items * Y23: support negative patterns as string restrictions MB: We will not do ignore-case since this is not supported by XSD based tools while the other modifier can be implemented outside the regex engine. MB: I will document this so we do not loose this bit of information. Issue moved to EDIT. * Y25: make enum numbering purely informative and optional MB and LL explain their positions (essentially a recap of the mailing list discussion) AB: My implementation does not track enum number changes. AB: I believe we should not have had these statement (position, value) in the first place. AB: Why does the autonumbering on/off not work? MB: Then I have to implement emus/bits without a value/position anyway. MB: Why would your turn it off? AB: I doubt that anyone can move their code to a different implementation and hence this is not portable anyway. AB: You (MB and DR) want a permanent code point but this does need to happen at compile time. MB: But the code point is there today. LL: Explicit value/position statements are noise to a module where there are no natural values. LL: I believes autonumbering on/off is a reasonable compromise. RFC 6020 says: "The value is unused by YANG and the NETCONF messages, but is carried as a convenience to implementors." It also says in section 10: "An "enumeration" type may have new enums added, provided the old enums's values do not change." AB: From a modeling point of view, sometimes an enum has a natural numeric value but sometimes it simply does not have such a value. KW: I like the idea for autonumbering being optional but numbers are important if there are natural numbers assigned. Lets do a poll of opinions. The options are: (1) No change (2) Remove auto numbering (3) Add statement to make auto numbering optional (on/off) Name your choice starting from the most preferred option to the least preferred option. MB: 1, 2, 3 LL: 2, 3, 1 AB: 3, 2, 1 DR: 1, 3, 2 KW: 2, 3, 1 JS: 2, 3, 1 JS: Is (2) more complicated on the upgrade path? LL: No because you take away only convenience to implementors. This needs to be taken to the list. (The result may mean that there is a majority for making a change here and out of the two options to make a change, it seems there is a majority to remove the auto numbering - which is after all a convenience to implementors.) Y10: allow restrictions on enumerations MB: I prefer Y10-01 because it does not need new syntax. AB: I do not see the value of this, why not define a new type? MB: With subtyping, you can inherit semantics that are lost if you define a new separate type. LL: I suggested on the list include and exclude, which is different from Y10-02. DR: I have seen usage of this in SMIv2 but I have no strong opinion on this. LL: I prefer to leave things as they are. Poll of opinions. The options are: (1) No change (2) Do Y10-01. MB: 2 JS: 2 KW: 2 LL: 1 AB: 1 AB: Does this interact with auto-numbering? MB: Current solution does work with auto-numbering, but it can be made to work if we remove auto-numbering. AB: For a large enumeration, Y10-01 is not user friendly. For small lists, create a new type. AB: I prefer a solution that allows to say I use all except this one (closer to LL's proposal on the list) MB: If you add an enum to a base type and you have exclude foo, then the addition carries through and this may or may not be what you want. Y10-01 at least makes it always clear what the set of values is. JS: I see your point but it may not make (conformance related) things worse than they are. MB: Y10-01 is better than the current situation and not more costly. If you define a separate type, you also have to list all enums plus you have to cut'n'paste the descriptions and the compiler will not be able to understand the relationship between the two types. Proposal: Move forward with Y10-01. Y05: unprefixed path in top-level typedef AB: One issue is to resolve prefixes, another is relative nodes where the context node matters. MB: My action item on this is not complete. Need to work on this and we should return to this issue later. Y12: initialized-by system JS: Is this issue resolved such that it can move into the EDIT state? JS: What is the alternate syntax referred to? JS: In the minutes, I see system-initialized true|false. MB: I agree to move this to the EDIT state. The syntax can be debated while being in the REVIEW state. --VbJkn9YxBvnuCH5J-- From nobody Thu Oct 2 06:04:53 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF951A86DE; Thu, 2 Oct 2014 06:04:52 -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 Nl6Z77O1M_nI; Thu, 2 Oct 2014 06:04:45 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32F511A6FB1; Thu, 2 Oct 2014 06:04:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 0583D5409F1; Thu, 2 Oct 2014 15:04:42 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEnSwfPygH6N; Thu, 2 Oct 2014 15:04:37 +0200 (CEST) Received: from localhost (cst-prg-119-246.cust.vodafone.cz [46.135.119.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 36F325403AA; Thu, 2 Oct 2014 15:04:19 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder , "Y. Richard Yang" In-Reply-To: <20141001070809.GA37068@elstar.local> References: <20141001070809.GA37068@elstar.local> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Thu, 02 Oct 2014 15:03:50 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/CIv4ffTzJNoXwN3NxMhWs_1ylb0 Cc: IETF ALTO , netmod@ietf.org Subject: Re: [netmod] Key-value data structures in YANG/JSON encoding X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 02 Oct 2014 13:04:52 -0000 Juergen Schoenwaelder writes: > On Tue, Sep 30, 2014 at 04:31:03PM -0400, Y. Richard Yang wrote: > >> A particular example of using key-value map is the network-map, which is >> defined as a key-value store to enforce that each named endpoint address >> group has a unique name. A specific example is in Section 11.2.1.7 of RFC >> 7285 (http://www.rfc-editor.org/rfc/rfc7285.txt): >> >> "network-map" : { >> "PID1" : { >> "ipv4" : [ >> "192.0.2.0/24", >> "198.51.100.0/25" >> ] >> }, >> "PID2" : { >> "ipv4" : [ >> "198.51.100.128/25" >> ] >> }, >> "PID3" : { >> "ipv4" : [ >> "0.0.0.0/0" >> ], >> "ipv6" : [ >> "::/0" >> ] >> } > > Since YANG's native encoding is XML, how would you represent this in > XML with the restriction that XML element names are defined by the > data model and all values are in XML elements? Moreover, even in JSON we have to work with essentially the same schema as in XML, so as to be able to interpret XPath expressions in the data model. So indeed, a new data node type would be needed for this. 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 Thu Oct 2 11:25:30 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE091A1A79; Thu, 2 Oct 2014 11:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKS2TR1ypC_R; Thu, 2 Oct 2014 11:25:26 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E7DE1A1A81; Thu, 2 Oct 2014 11:25:26 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id x12so4000275wgg.32 for ; Thu, 02 Oct 2014 11:25:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=p4VIBTdtM5GJecanyhJnzFPhR2xLdY5a6JJAwTjvljQ=; b=NPnrfMe0Dr65frDvugqfnHr3bJtFQm1zdoskbLMAtnB4H6yPkS4u1F2wthXxKVK+75 mI3rEqDMeHHqWjXB+mlvsGUB4M9elrLNp261QP4VtszSVHRtAmHcpXchEJn45KnI91k4 Gmc1SL64AZt45bPK1UZuhvDFxUGtWNs4o9OHaq+sqa3WwOhmjQCohxtb/0Mq15yJwP34 KOmRY5h9X0/IDagPBe8Ishf/RD4jXEVx+WC57Cboeb3eXIbmKzgPCpNsefPqwtDepCpC okynnhXHsrXZtPQEaUeYel24MKNFQE6RqoggnNGqYWlLrPKcOA58Pas35entHXi5vXax PFag== MIME-Version: 1.0 X-Received: by 10.180.198.10 with SMTP id iy10mr6384070wic.10.1412274324836; Thu, 02 Oct 2014 11:25:24 -0700 (PDT) Sender: yang.r.yang@gmail.com Received: by 10.27.178.161 with HTTP; Thu, 2 Oct 2014 11:25:24 -0700 (PDT) In-Reply-To: <20141002071522.GA40160@elstar.local> References: <20141001070809.GA37068@elstar.local> <20141002071522.GA40160@elstar.local> Date: Thu, 2 Oct 2014 14:25:24 -0400 X-Google-Sender-Auth: lu5RkfMUQHBjBfODLdvzt8I15xA Message-ID: From: "Y. Richard Yang" To: Juergen Schoenwaelder , "Y. Richard Yang" , netmod@ietf.org, IETF ALTO Content-Type: multipart/alternative; boundary=047d7b6226d075188c050474bda7 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/aoDyMaPeoBJ7gbKaN3Maga9_6s4 Subject: Re: [netmod] Key-value data structures in YANG/JSON encoding X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 02 Oct 2014 18:25:28 -0000 --047d7b6226d075188c050474bda7 Content-Type: text/plain; charset=UTF-8 Hi Juergen, On Thu, Oct 2, 2014 at 3:15 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > > > I am saying that YANG was designed to model data carried by NETCONF > (check the title of RFC 6020) and NETCONF uses XML as its data > encoding with a set of restrictions that were found useful to simplify > things (all data in XML elements, no mixed content, ...). Several > details of the YANG language are related to XML (e.g., much of the > type system, the usage of xpath in must/when expressions, instance > identifier as a subset of xpath, ...). > > Yes. The binding of YANG as a data description language to XML is clear. > Alternate _encodings_ are proposed (such as JSON) but the question > raised here seems to be whether we want to start an effort to turn > YANG into a schema language for JSON (which it is not today and this > is by design and not by accident). > > Good comment. My personal opinion, JSON is widely used enough to justify this effort. Richard > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > --047d7b6226d075188c050474bda7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Juergen,

On Thu, Oct 2, 2014 at 3:15 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:=
=

I am saying that YANG was designed to model data carried by NET= CONF
(check the title of RFC 6020) and NETCONF uses XML as its data
encoding with a set of restrictions that were found useful to simplify
things (all data in XML elements, no mixed content, ...). Several
details of the YANG language are related to XML (e.g., much of the
type system, the usage of xpath in must/when expressions, instance
identifier as a subset of xpath, ...).


Yes. The binding of YANG as a data des= cription language to XML is clear.=C2=A0
=C2=A0
Alternate _encodings_ are proposed (such as JSON) but the question
raised here seems to be whether we want to start an effort to turn
YANG into a schema language for JSON (which it is not today and this
is by design and not by accident).

<= br>
Good comment. My personal opinion, JSON is widely used enough= to justify this effort.=C2=A0

Richard
<= br>
=C2=A0
/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 Bre= men, Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-univ= ersity.de/>
--047d7b6226d075188c050474bda7-- From nobody Fri Oct 3 05:58:26 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 022441A039D for ; Fri, 3 Oct 2014 05:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.291 X-Spam-Level: * X-Spam-Status: No, score=1.291 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FILL_THIS_FORM=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.157, J_CHICKENPOX_48=0.6, MANGLED_LOOK=2.3, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_HTML_ATTACH=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 mJp8LilDL0wQ for ; Fri, 3 Oct 2014 05:58:08 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E27871A00BB for ; Fri, 3 Oct 2014 05:58:02 -0700 (PDT) X-AuditID: c1b4fb30-f79736d0000053b8-b7-542e9d583892 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 01.BC.21432.85D9E245; Fri, 3 Oct 2014 14:58:01 +0200 (CEST) Received: from [159.107.198.29] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.3.174.1; Fri, 3 Oct 2014 14:58:00 +0200 Message-ID: <542E9D57.7010108@ericsson.com> Date: Fri, 3 Oct 2014 14:57:59 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "netmod@ietf.org" Content-Type: multipart/related; boundary="------------070902080105040106060000" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNLMWRmVeSWpSXmKPExsUyM+JvjW7kXL0Qg52TuS3mX2xkdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqXTf5gKnv2Qqpg74R17A2PXb6EuRk4OCQETiRndr9kgbDGJ C/fWA9lcHEICRxklDmzbwgjhrGaUeHSmnx2kildAW+Ld3itANgcHi4CKxK3HeiBhNgEjian9 51lAbFGBKIk7l/pZIcoFJU7OfAIWFxFQl5i5cz3YMmEBG4k/z1aC2cwCQRKz2v+D1QsJaEg8 vPCXdQIj7ywk7bOQlEHYuhIX/k+BistLbH87h3kW0KnMAtMZJTZ+X88GkdCWWLbwNTOEbSTR tXkCG0TRHEaJ1hWXmBYwcqxiFC1OLU7KTTcy0kstykwuLs7P08tLLdnECAzdg1t+G+xgfPnc 8RCjAAejEg+vArNeiBBrYllxZe4hRmkOFiVx3oXn5gULCaQnlqRmp6YWpBbFF5XmpBYfYmTi 4JRqYDTSWefZ+Sg1ykF+7seXR48oZ7L/iLp/Y27Bsm3noqeamMstXDbr6aPadaGsvFMS2cun 3tl5znl9+KPvQsLfrqy8ZT5x+8snXpu/JLhru7ycczyUz2f+3TtXXjw1Tq8yPvDhcKzWgZ4T Lw+u7pdbm+MdUd3xLetcUZHZGt/qzdZ1D99vfqT5NSpOiaU4I9FQi7moOBEAA6/vKD4CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/NkNGFBZVi0w0w8GPJ_VcLrVF4fI Subject: [netmod] replace a value in a leaf list - what does it mean? X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 03 Oct 2014 12:58:22 -0000 --------------070902080105040106060000 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Hello,
I am trying to formulate my proposal about non-Unique values in a leaf-list, and during this I found, I do not understand what an edit-config: replace operation means in YANG 1.0 for a leaf-list.

If I have a leaf-list [a,b,c,d] and I issue an edit-config opertion where the value "b" of the leaf-list is replaced by "b"
what is the result:
1) [a,b,c,d]  - seems natural as replacing something with itself should not modified the data

or

2) [a,b,c,d,b] - according to RFC6020 chapter 7.7.7
   In an "ordered-by user" leaf-list, the attributes "insert" and
   "value" in the YANG XML namespace (Section 5.3.1) can be used to
   control where in the leaf-list the entry is inserted.  These can be
   used during "create" operations to insert a new leaf-list entry, or
   during "merge" or "replace" operations to insert a new leaf-list
   entry or move an existing one.

	...

   If no "insert" attribute is present in the "create" operation, it
   defaults to "last".
So replace can be used on a leaf-list. Insert defaults to last. This would point at 2) as the solution.

Opinions?
regards balazs



-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320                        Tel: +36-1-437-7320
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
--------------070902080105040106060000 Content-Type: text/html; charset="ISO-8859-1"; name="RFC 6020 - YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF).htm" Content-Transfer-Encoding: quoted-printable Content-ID: Content-Disposition: inline; filename*0="RFC 6020 - YANG - A Data Modeling Language for the Network C"; filename*1="onfiguration Protocol (NETCONF).htm" = RFC 6020 - YANG - A Data Modeling Language for the Network Con= figuration Protocol (NETCONF) =20 =20
=
[Docs] [txt|pdf] [draft-ietf-netmod...<= /a>] [Diff1] [Diff2] [Errata]
=
= PROPOSED STANDARD
= Errata Exist
Internet Engineering Task Force (IETF)                 M. Bjorklund, Ed.
Request for Comments: 6020                                Tail-f Systems
Category: Standards Track                                   October 2010
ISSN: 2070-1721


                  YANG - A Data Modeling Language for<=
/span>
              the Network Configuration Protocol (NETC=
ONF)

Abstract

   YANG is a data modeling language used to model configuration and
   state data manipulated by the Network Configuration Protocol
   (NETCONF), NETCONF remote procedure calls, and NETCONF notifications.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Sec=
tion 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-edit=
or.org/info/rfc6020.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IET=
F Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.=
org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.








Bjorklund                    Standards Track        =
            [Page 1]

 
RFC 6020                  =
        YANG                      October 2010


   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

   1. Introduction ...........................=
=2E........................8
   2. Keywords ...............................=
=2E........................8
   3. Terminology ............................=
=2E........................8
      3.1. Mandatory Nodes .................=
=2E.........................10
   4. YANG Overview ..........................=
=2E.......................11
      4.1. Functional Overview .............=
=2E.........................11
      4.2. Language Overview ...............=
=2E.........................13
           4.2.1. Modules and Submodules .=
=2E...........................13
           4.2.2. Data Modeling Basics ...=
=2E...........................13
           4.2.3. State Data .............=
=2E...........................18
           4.2.4. Built-In Types .........=
=2E...........................18
           4.2.5. Derived Types (typedef) =
=2E...........................19
           4.2.6. Reusable Node Groups (gr=
ouping) ....................20
           4.2.7. Choices ................=
=2E...........................21
           4.2.8. Extending Data Models (a=
ugment) ....................22
           4.2.9. RPC Definitions ........=
=2E...........................23
           4.2.10. Notification Definitio=
ns ..........................24
   5. Language Concepts ......................=
=2E.......................25
      5.1. Modules and Submodules ..........=
=2E.........................25
           5.1.1. Import and Include by Re=
vision .....................26
           5.1.2. Module Hierarchies .....=
=2E...........................27
      5.2. File Layout .....................=
=2E.........................28
      5.3. XML Namespaces ..................=
=2E.........................29
           5.3.1. YANG XML Namespace .....=
=2E...........................29
      5.4. Resolving Grouping, Type, and Ide=
ntity Names ..............29
      5.5. Nested Typedefs and Groupings ...=
=2E.........................29
      5.6. Conformance .....................=
=2E.........................30
           5.6.1. Basic Behavior .........=
=2E...........................31
           5.6.2. Optional Features ......=
=2E...........................31
           5.6.3. Deviations .............=
=2E...........................31
           5.6.4. Announcing Conformance Information in the
                  <hello> Message .................................=
=2E..32
      5.7. Data Store Modification .........=
=2E.........................34
   6. YANG Syntax ............................=
=2E.......................34



Bjorklund                    Standards Track        =
            [Page 2]

 
RFC 6020                  =
        YANG                      October 2010


      6.1. Lexical Tokenization ............=
=2E.........................34
           6.1.1. Comments ...............=
=2E...........................34
           6.1.2. Tokens .................=
=2E...........................34
           6.1.3. Quoting ................=
=2E...........................35
      6.2. Identifiers .....................=
=2E.........................36
           6.2.1. Identifiers and Their Na=
mespaces ...................36
      6.3. Statements ......................=
=2E.........................37
           6.3.1. Language Extensions ....=
=2E...........................37
      6.4. XPath Evaluations ...............=
=2E.........................38
           6.4.1. XPath Context ..........=
=2E...........................38
      6.5. Schema Node Identifier ..........=
=2E.........................39
   7. YANG Statements ........................=
=2E.......................39
      7.1. The module Statement ............=
=2E.........................39
           7.1.1. The module's Substatemen=
ts .........................41
           7.1.2. The yang-version Stateme=
nt .........................41
           7.1.3. The namespace Statement =
=2E...........................42
           7.1.4. The prefix Statement ...=
=2E...........................42
           7.1.5. The import Statement ...=
=2E...........................42
           7.1.6. The include Statement ..=
=2E...........................43
           7.1.7. The organization Stateme=
nt .........................44
           7.1.8. The contact Statement ..=
=2E...........................44
           7.1.9. The revision Statement .=
=2E...........................44
           7.1.10. Usage Example ........=
=2E............................45
      7.2. The submodule Statement .........=
=2E.........................46
           7.2.1. The submodule's Substate=
ments ......................48
           7.2.2. The belongs-to Statement=
 ...........................48
           7.2.3. Usage Example ..........=
=2E...........................49
      7.3. The typedef Statement ...........=
=2E.........................49
           7.3.1. The typedef's Substateme=
nts ........................50
           7.3.2. The typedef's type State=
ment .......................50
           7.3.3. The units Statement ....=
=2E...........................50
           7.3.4. The typedef's default St=
atement ....................50
           7.3.5. Usage Example ..........=
=2E...........................51
      7.4. The type Statement ..............=
=2E.........................51
           7.4.1. The type's Substatements=
 ...........................51
      7.5. The container Statement .........=
=2E.........................51
           7.5.1. Containers with Presence=
 ...........................52
           7.5.2. The container's Substate=
ments ......................53
           7.5.3. The must Statement .....=
=2E...........................53
           7.5.4. The must's Substatements=
 ...........................55
           7.5.5. The presence Statement .=
=2E...........................56
           7.5.6. The container's Child No=
de Statements ..............56
           7.5.7. XML Mapping Rules ......=
=2E...........................56
           7.5.8. NETCONF <edit-config&=
gt; Operations ...................56
           7.5.9. Usage Example ..........=
=2E...........................57
      7.6. The leaf Statement ..............=
=2E.........................58
           7.6.1. The leaf's default value=
 ...........................58
           7.6.2. The leaf's Substatements=
 ...........................59



Bjorklund                    Standards Track        =
            [Page 3]

 
RFC 6020                  =
        YANG                      October 2010


           7.6.3. The leaf's type Statemen=
t ..........................59
           7.6.4. The leaf's default State=
ment .......................59
           7.6.5. The leaf's mandatory Sta=
tement .....................60
           7.6.6. XML Mapping Rules ......=
=2E...........................60
           7.6.7. NETCONF <edit-config&=
gt; Operations ...................60
           7.6.8. Usage Example ..........=
=2E...........................61
      7.7. The leaf-list Statement .........=
=2E.........................62
           7.7.1. Ordering ...............=
=2E...........................62
           7.7.2. The leaf-list's Substate=
ments ......................63
           7.7.3. The min-elements Stateme=
nt .........................63
           7.7.4. The max-elements Stateme=
nt .........................63
           7.7.5. The ordered-by Statement=
 ...........................64
           7.7.6. XML Mapping Rules ......=
=2E...........................64
           7.7.7. NETCONF <edit-config&=
gt; Operations ...................65
           7.7.8. Usage Example ..........=
=2E...........................66
      7.8. The list Statement ..............=
=2E.........................67
           7.8.1. The list's Substatements=
 ...........................68
           7.8.2. The list's key Statement=
 ...........................68
           7.8.3. The list's unique Statem=
ent ........................69
           7.8.4. The list's Child Node St=
atements ...................70
           7.8.5. XML Mapping Rules ......=
=2E...........................70
           7.8.6. NETCONF <edit-config&=
gt; Operations ...................71
           7.8.7. Usage Example ..........=
=2E...........................72
      7.9. The choice Statement ............=
=2E.........................75
           7.9.1. The choice's Substatemen=
ts .........................76
           7.9.2. The choice's case Statem=
ent ........................76
           7.9.3. The choice's default Sta=
tement .....................77
           7.9.4. The choice's mandatory S=
tatement ...................79
           7.9.5. XML Mapping Rules ......=
=2E...........................79
           7.9.6. NETCONF <edit-config&=
gt; Operations ...................79
           7.9.7. Usage Example ..........=
=2E...........................79
      7.10. The anyxml Statement ..........=
=2E..........................80
           7.10.1. The anyxml's Substatem=
ents ........................81
           7.10.2. XML Mapping Rules ....=
=2E............................81
           7.10.3. NETCONF <edit-confi=
g> Operations ..................81
           7.10.4. Usage Example ........=
=2E............................82
      7.11. The grouping Statement ........=
=2E..........................82
           7.11.1. The grouping's Substat=
ements ......................83
           7.11.2. Usage Example ........=
=2E............................84
      7.12. The uses Statement ............=
=2E..........................84
           7.12.1. The uses's Substatemen=
ts ..........................85
           7.12.2. The refine Statement .=
=2E............................85
           7.12.3. XML Mapping Rules ....=
=2E............................86
           7.12.4. Usage Example ........=
=2E............................86
      7.13. The rpc Statement .............=
=2E..........................87
           7.13.1. The rpc's Substatement=
s ...........................88
           7.13.2. The input Statement ..=
=2E............................88
           7.13.3. The output Statement .=
=2E............................89



Bjorklund                    Standards Track        =
            [Page 4]

 
RFC 6020                  =
        YANG                      October 2010


           7.13.4. XML Mapping Rules ....=
=2E............................90
           7.13.5. Usage Example ........=
=2E............................91
      7.14. The notification Statement ....=
=2E..........................91
           7.14.1. The notification's Sub=
statements ..................92
           7.14.2. XML Mapping Rules ....=
=2E............................92
           7.14.3. Usage Example ........=
=2E............................93
      7.15. The augment Statement .........=
=2E..........................93
           7.15.1. The augment's Substate=
ments .......................94
           7.15.2. XML Mapping Rules ....=
=2E............................94
           7.15.3. Usage Example ........=
=2E............................95
      7.16. The identity Statement ........=
=2E..........................97
           7.16.1. The identity's Substat=
ements ......................97
           7.16.2. The base Statement ...=
=2E............................97
           7.16.3. Usage Example ........=
=2E............................98
      7.17. The extension Statement .......=
=2E..........................98
           7.17.1. The extension's Substa=
tements .....................99
           7.17.2. The argument Statement=
 ............................99
           7.17.3. Usage Example ........=
=2E...........................100
      7.18. Conformance-Related Statements =
=2E.........................100
           7.18.1. The feature Statement =
=2E...........................100
           7.18.2. The if-feature Stateme=
nt .........................102
           7.18.3. The deviation Statemen=
t ..........................102
      7.19. Common Statements .............=
=2E.........................105
           7.19.1. The config Statement .=
=2E...........................105
           7.19.2. The status Statement .=
=2E...........................105
           7.19.3. The description Statem=
ent ........................106
           7.19.4. The reference Statemen=
t ..........................106
           7.19.5. The when Statement ...=
=2E...........................107
   8. Constraints ............................=
=2E......................108
      8.1. Constraints on Data .............=
=2E........................108
      8.2. Hierarchy of Constraints ........=
=2E........................109
      8.3. Constraint Enforcement Model ....=
=2E........................109
           8.3.1. Payload Parsing ........=
=2E..........................109
           8.3.2. NETCONF <edit-config&=
gt; Processing ..................110
           8.3.3. Validation .............=
=2E..........................111
   9. Built-In Types .........................=
=2E......................111
      9.1. Canonical Representation ........=
=2E........................112
      9.2. The Integer Built-In Types ......=
=2E........................112
           9.2.1. Lexical Representation .=
=2E..........................113
           9.2.2. Canonical Form .........=
=2E..........................114
           9.2.3. Restrictions ...........=
=2E..........................114
           9.2.4. The range Statement ....=
=2E..........................114
           9.2.5. Usage Example ..........=
=2E..........................115
      9.3. The decimal64 Built-In Type .....=
=2E........................115
           9.3.1. Lexical Representation .=
=2E..........................115
           9.3.2. Canonical Form .........=
=2E..........................115
           9.3.3. Restrictions ...........=
=2E..........................116
           9.3.4. The fraction-digits Stat=
ement .....................116



Bjorklund                    Standards Track        =
            [Page 5]

 
RFC 6020                  =
        YANG                      October 2010


           9.3.5. Usage Example ..........=
=2E..........................117
      9.4. The string Built-In Type ........=
=2E........................117
           9.4.1. Lexical Representation .=
=2E..........................117
           9.4.2. Canonical Form .........=
=2E..........................117
           9.4.3. Restrictions ...........=
=2E..........................117
           9.4.4. The length Statement ...=
=2E..........................117
           9.4.5. Usage Example ..........=
=2E..........................118
           9.4.6. The pattern Statement ..=
=2E..........................119
           9.4.7. Usage Example ..........=
=2E..........................119
      9.5. The boolean Built-In Type .......=
=2E........................120
           9.5.1. Lexical Representation .=
=2E..........................120
           9.5.2. Canonical Form .........=
=2E..........................120
           9.5.3. Restrictions ...........=
=2E..........................120
      9.6. The enumeration Built-In Type ...=
=2E........................120
           9.6.1. Lexical Representation .=
=2E..........................120
           9.6.2. Canonical Form .........=
=2E..........................120
           9.6.3. Restrictions ...........=
=2E..........................120
           9.6.4. The enum Statement .....=
=2E..........................120
           9.6.5. Usage Example ..........=
=2E..........................121
      9.7. The bits Built-In Type ..........=
=2E........................122
           9.7.1. Restrictions ...........=
=2E..........................122
           9.7.2. Lexical Representation .=
=2E..........................122
           9.7.3. Canonical Form .........=
=2E..........................122
           9.7.4. The bit Statement ......=
=2E..........................122
           9.7.5. Usage Example ..........=
=2E..........................123
      9.8. The binary Built-In Type ........=
=2E........................123
           9.8.1. Restrictions ...........=
=2E..........................124
           9.8.2. Lexical Representation .=
=2E..........................124
           9.8.3. Canonical Form .........=
=2E..........................124
      9.9. The leafref Built-In Type .......=
=2E........................124
           9.9.1. Restrictions ...........=
=2E..........................124
           9.9.2. The path Statement .....=
=2E..........................124
           9.9.3. Lexical Representation .=
=2E..........................125
           9.9.4. Canonical Form .........=
=2E..........................125
           9.9.5. Usage Example ..........=
=2E..........................126
      9.10. The identityref Built-In Type .=
=2E.........................129
           9.10.1. Restrictions .........=
=2E...........................129
           9.10.2. The identityref's base=
 Statement .................129
           9.10.3. Lexical Representation=
 ...........................130
           9.10.4. Canonical Form .......=
=2E...........................130
           9.10.5. Usage Example ........=
=2E...........................130
      9.11. The empty Built-In Type .......=
=2E.........................131
           9.11.1. Restrictions .........=
=2E...........................131
           9.11.2. Lexical Representation=
 ...........................131
           9.11.3. Canonical Form .......=
=2E...........................131
           9.11.4. Usage Example ........=
=2E...........................131
      9.12. The union Built-In Type .......=
=2E.........................132
           9.12.1. Restrictions .........=
=2E...........................132



Bjorklund                    Standards Track        =
            [Page 6]

 
RFC 6020                  =
        YANG                      October 2010


           9.12.2. Lexical Representation=
 ...........................132
           9.12.3. Canonical Form .......=
=2E...........................133
      9.13. The instance-identifier Built-I=
n Type ...................133
           9.13.1. Restrictions .........=
=2E...........................134
           9.13.2. The require-instance S=
tatement ...................134
           9.13.3. Lexical Representation=
 ...........................134
           9.13.4. Canonical Form .......=
=2E...........................134
           9.13.5. Usage Example ........=
=2E...........................134
   10. Updating a Module ....................=
=2E.......................135
   11. YIN ..................................=
=2E.......................137
      11.1. Formal YIN Definition .........=
=2E.........................137
           11.1.1. Usage Example ........=
=2E...........................141
   12. YANG ABNF Grammar ....................=
=2E.......................143
   13. Error Responses for YANG Related Error=
s ......................165
      13.1. Error Message for Data That Violates a unique
            Statement ...............................................165
      13.2. Error Message for Data That Violates a
            max-elements Statement ..................................165
      13.3. Error Message for Data That Violates a
            min-elements Statement ..................................165
      13.4. Error Message for Data That Vio=
lates a must Statement ...166
      13.5. Error Message for Data That Violates a
            require-instance Statement ..............................166
      13.6. Error Message for Data That Does Not Match a
            leafref Type ............................................166
      13.7. Error Message for Data That Violates a mandatory
            choice Statement ........................................166
      13.8. Error Message for the "insert" =
Operation ................167
   14. IANA Considerations ..................=
=2E.......................167
      14.1. Media type application/yang ...=
=2E.........................168
      14.2. Media type application/yin+xml =
=2E.........................169
   15. Security Considerations ..............=
=2E.......................170
   16. Contributors .........................=
=2E.......................171
   17. Acknowledgements .....................=
=2E.......................171
   18. References ...........................=
=2E.......................171
      18.1. Normative References ..........=
=2E.........................171
      18.2. Informative References ........=
=2E.........................172














Bjorklund                    Standards Track        =
            [Page 7]

 
RFC 6020                  =
        YANG                      October 2010


1.  Introduction

   YANG is a data modeling language used to model configuration and
   state data manipulated by the Network Configuration Protocol
   (NETCONF), NETCONF remote procedure calls, and NETCONF notifications.
   YANG is used to model the operations and content layers of NETCONF
   (see the NETCONF Configuration Protocol [RFC4741], Section 1.1).

   This document describes the syntax and semantics of the YANG
   language, how the data model defined in a YANG module is represented
   in the Extensible Markup Language (XML), and how NETCONF operations
   are used to manipulate the data.

2.  Keywords

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14, [RFC2119].=


3.  Terminology

   o  anyxml: A data node that can contain an unknown chunk of XML data.

   o  augment: Adds new schema nodes to a previously defined schema
      node.

   o  base type: The type from which a derived type was derived, which
      may be either a built-in type or another derived type.

   o  built-in type: A YANG data type defined in the YANG language, such
      as uint32 or string.

   o  choice: A schema node where only one of a number of identified
      alternatives is valid.

   o  configuration data: The set of writable data that is required to
      transform a system from its initial default state into its current
      state [RFC4741].

   o  conformance: A measure of how accurately a device follows a data
      model.

   o  container: An interior data node that exists in at most one
      instance in the data tree.  A container has no value, but rather a
      set of child nodes.





Bjorklund                    Standards Track        =
            [Page 8]

 
RFC 6020                  =
        YANG                      October 2010


   o  data definition statement: A statement that defines new data
      nodes.  One of container, leaf, leaf-list, list, choice, case,
      augment, uses, and anyxml.

   o  data model: A data model describes how data is represented and
      accessed.

   o  data node: A node in the schema tree that can be instantiated in a
      data tree.  One of container, leaf, leaf-list, list, and anyxml.

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

   o  derived type: A type that is derived from a built-in type (such as
      uint32), or another derived type.

   o  device deviation: A failure of the device to implement the module
      faithfully.

   o  extension: An extension attaches non-YANG semantics to statements.
      The extension statement defines new statements to express these
      semantics.

   o  feature: A mechanism for marking a portion of the model as
      optional.  Definitions can be tagged with a feature name and are
      only valid on devices that support that feature.

   o  grouping: A reusable set of schema nodes, which may be used
      locally in the module, in modules that include it, and by other
      modules that import from it.  The grouping statement is not a data
      definition statement and, as such, does not define any nodes in
      the schema tree.

   o  identifier: Used to identify different kinds of YANG items by
      name.

   o  instance identifier: A mechanism for identifying a particular node
      in a data tree.

   o  interior node: Nodes within a hierarchy that are not leaf nodes.

   o  leaf: A data node that exists in at most one instance in the data
      tree.  A leaf has a value but no child nodes.

   o  leaf-list: Like the leaf node but defines a set of uniquely
      identifiable nodes rather than a single node.  Each node has a
      value but no child nodes.




Bjorklund                    Standards Track        =
            [Page 9]

 
RFC 6020                  =
        YANG                      October 2010


   o  list: An interior data node that may exist in multiple instances
      in the data tree.  A list has no value, but rather a set of child
      nodes.

   o  module: A YANG module defines a hierarchy of nodes that can be
      used for NETCONF-based operations.  With its definitions and the
      definitions it imports or includes from elsewhere, a module is
      self-contained and "compilable".

   o  RPC: A Remote Procedure Call, as used within the NETCONF protocol.

   o  RPC operation: A specific Remote Procedure Call, as used within
      the NETCONF protocol.  It is also called a protocol operation.

   o  schema node: A node in the schema tree.  One of container, leaf,
      leaf-list, list, choice, case, rpc, input, output, notification,
      and anyxml.

   o  schema node identifier: A mechanism for identifying a particular
      node in the schema tree.

   o  schema tree: The definition hierarchy specified within a module.

   o  state data: The additional data on a system that is not
      configuration data such as read-only status information and
      collected statistics [RFC4741].

   o  submodule: A partial module definition that contributes derived
      types, groupings, data nodes, RPCs, and notifications to a module.
      A YANG module can be constructed from a number of submodules.

   o  top-level data node: A data node where there is no other data node
      between it and a module or submodule statement.

   o  uses: The "uses" statement is used to instantiate the set of
      schema nodes defined in a grouping statement.  The instantiated
      nodes may be refined and augmented to tailor them to any specific
      needs.

3.1.  Mandatory Nodes

   A mandatory node is one of:

   o  A leaf, choice, or anyxml node with a "mandatory" statement with
      the value "true".

   o  A list or leaf-list node with a "min-elements" statement with a
      value greater than zero.



Bjorklund                    Standards Track        =
           [Page 10]

 
RFC 6020                  =
        YANG                      October 2010


   o  A container node without a "presence" statement, which has at
      least one mandatory node as a child.

4.  YANG Overview

4.1.  Functional Overview

   YANG is a language used to model data for the NETCONF protocol.  A
   YANG module defines a hierarchy of data that can be used for NETCONF-
   based operations, including configuration, state data, Remote
   Procedure Calls (RPCs), and notifications.  This allows a complete
   description of all data sent between a NETCONF client and server.

   YANG models the hierarchical organization of data as a tree in which
   each node has a name, and either a value or a set of child nodes.
   YANG provides clear and concise descriptions of the nodes, as well as
   the interaction between those nodes.

   YANG structures data models into modules and submodules.  A module
   can import data from other external modules, and include data from
   submodules.  The hierarchy can be augmented, allowing one module to
   add data nodes to the hierarchy defined in another module.  This
   augmentation can be conditional, with new nodes appearing only if
   certain conditions are met.

   YANG models can describe constraints to be enforced on the data,
   restricting the appearance or value of nodes based on the presence or
   value of other nodes in the hierarchy.  These constraints are
   enforceable by either the client or the server, and valid content
   MUST abide by them.

   YANG defines a set of built-in types, and has a type mechanism
   through which additional types may be defined.  Derived types can
   restrict their base type's set of valid values using mechanisms like
   range or pattern restrictions that can be enforced by clients or
   servers.  They can also define usage conventions for use of the
   derived type, such as a string-based type that contains a host name.

   YANG permits the definition of reusable groupings of nodes.  The
   instantiation of these groupings can refine or augment the nodes,
   allowing it to tailor the nodes to its particular needs.  Derived
   types and groupings can be defined in one module or submodule and
   used in either that location or in another module or submodule that
   imports or includes it.







Bjorklund                    Standards Track        =
           [Page 11]

 
RFC 6020                  =
        YANG                      October 2010


   YANG data hierarchy constructs include defining lists where list
   entries are identified by keys that distinguish them from each other.
   Such lists may be defined as either sorted by user or automatically
   sorted by the system.  For user-sorted lists, operations are defined
   for manipulating the order of the list entries.

   YANG modules can be translated into an equivalent XML syntax called
   YANG Independent Notation (YIN) (Section 11), allowing applications
   using XML parsers and Extensible Stylesheet Language Transformations
   (XSLT) scripts to operate on the models.  The conversion from YANG to
   YIN is lossless, so content in YIN can be round-tripped back into
   YANG.

   YANG strikes a balance between high-level data modeling and low-level
   bits-on-the-wire encoding.  The reader of a YANG module can see the
   high-level view of the data model while understanding how the data
   will be encoded in NETCONF operations.

   YANG is an extensible language, allowing extension statements to be
   defined by standards bodies, vendors, and individuals.  The statement
   syntax allows these extensions to coexist with standard YANG
   statements in a natural way, while extensions in a YANG module stand
   out sufficiently for the reader to notice them.

   YANG resists the tendency to solve all possible problems, limiting
   the problem space to allow expression of NETCONF data models, not
   arbitrary XML documents or arbitrary data models.  The data models
   described by YANG are designed to be easily operated upon by NETCONF
   operations.

   To the extent possible, YANG maintains compatibility with Simple
   Network Management Protocol's (SNMP's) SMIv2 (Structure of Management
   Information version 2 [RFC2578], [RFC257=
9]).  SMIv2-based MIB modules
   can be automatically translated into YANG modules for read-only
   access.  However, YANG is not concerned with reverse translation from
   YANG to SMIv2.

   Like NETCONF, YANG targets smooth integration with the device's
   native management infrastructure.  This allows implementations to
   leverage their existing access control mechanisms to protect or
   expose elements of the data model.










Bjorklund                    Standards Track        =
           [Page 12]

 
RFC 6020                  =
        YANG                      October 2010


4.2.  Language Overview

   This section introduces some important constructs used in YANG that
   will aid in the understanding of the language specifics in later
   sections.  This progressive approach handles the inter-related nature
   of YANG concepts and statements.  A detailed description of YANG
   statements and syntax begins in Section 7.

4.2.1.  Modules and Submodules

   A module contains three types of statements: module-header
   statements, revision statements, and definition statements.  The
   module header statements describe the module and give information
   about the module itself, the revision statements give information
   about the history of the module, and the definition statements are
   the body of the module where the data model is defined.

   A NETCONF server may implement a number of modules, allowing multiple
   views of the same data, or multiple views of disjoint subsections of
   the device's data.  Alternatively, the server may implement only one
   module that defines all available data.

   A module may be divided into submodules, based on the needs of the
   module owner.  The external view remains that of a single module,
   regardless of the presence or size of its submodules.

   The "include" statement allows a module or submodule to reference
   material in submodules, and the "import" statement allows references
   to material defined in other modules.

4.2.2.  Data Modeling Basics

   YANG defines four types of nodes for data modeling.  In each of the
   following subsections, the example shows the YANG syntax as well as a
   corresponding NETCONF XML representation.

4.2.2.1.  Leaf Nodes

   A leaf node contains simple data like an integer or a string.  It has
   exactly one value of a particular type and no child nodes.

   YANG Example:

       leaf host-name {
           type string;
           description "Hostname for this system";
       }




Bjorklund                    Standards Track        =
           [Page 13]

 
RFC 6020                  =
        YANG                      October 2010


   NETCONF XML Example:

       <host-name>my.example.com</host-name>

   The "leaf" statement is covered in Section 7.=
6.

4.2.2.2.  Leaf-List Nodes

   A leaf-list is a sequence of leaf nodes with exactly one value of a
   particular type per leaf.

   YANG Example:

     leaf-list domain-search {
         type string;
         description "List of domain names to search";
     }

   NETCONF XML Example:

     <domain-search>high.example.com</domain-search>
     <domain-search>low.example.com</domain-search>
     <domain-search>everywhere.example.com</domain-search>

   The "leaf-list" statement is covered in Secti=
on 7.7.

4.2.2.3.  Container Nodes

   A container node is used to group related nodes in a subtree.  A
   container has only child nodes and no value.  A container may contain
   any number of child nodes of any type (including leafs, lists,
   containers, and leaf-lists).

   YANG Example:

     container system {
         container login {
             leaf message {
                 type string;
                 description
                     "Message given at start of login session";
             }
         }
     }







Bjorklund                    Standards Track        =
           [Page 14]

 
RFC 6020                  =
        YANG                      October 2010


   NETCONF XML Example:

     <system>
       <login>
         <message>Good morning</message>
       </login>
     </system>

   The "container" statement is covered in Secti=
on 7.5.

4.2.2.4.  List Nodes

   A list defines a sequence of list entries.  Each entry is like a
   structure or a record instance, and is uniquely identified by the
   values of its key leafs.  A list can define multiple key leafs and
   may contain any number of child nodes of any type (including leafs,
   lists, containers etc.).

   YANG Example:

     list user {
         key "name";
         leaf name {
             type string;
         }
         leaf full-name {
             type string;
         }
         leaf class {
             type string;
         }
     }



















Bjorklund                    Standards Track        =
           [Page 15]

 
RFC 6020                  =
        YANG                      October 2010


   NETCONF XML Example:

     <user>
       <name>glocks</name>
       <full-name>Goldie Locks</full-name>
       <class>intruder</class>
     </user>
     <user>
       <name>snowey</name>
       <full-name>Snow White</full-name>
       <class>free-loader</class>
     </user>
     <user>
       <name>rzell</name>
       <full-name>Rapun Zell</full-name>
       <class>tower</class>
     </user>

   The "list" statement is covered in Section 7.=
8.

4.2.2.5.  Example Module

   These statements are combined to define the module:




























Bjorklund                    Standards Track        =
           [Page 16]

 
RFC 6020                  =
        YANG                      October 2010


     // Contents of "acme-system.yang"
     module acme-system {
         namespace "http://acme.example.com/system";
         prefix "acme";

         organization "ACME Inc.";
         contact "joe@acme.example.com";
         description
             "The module for entities implementing the ACME system.";

         revision 2007-06-09 {
             description "Initial revision.";
         }

         container system {
             leaf host-name {
                 type string;
                 description "Hostname for this system";
             }

             leaf-list domain-search {
                 type string;
                 description "List of domain names to search";
             }

             container login {
                 leaf message {
                     type string;
                     description
                         "Message given at start of login session";
                 }

                 list user {
                     key "name";
                     leaf name {
                         type string;
                     }
                     leaf full-name {
                         type string;
                     }
                     leaf class {
                         type string;
                     }
                 }
             }
         }
     }




Bjorklund                    Standards Track        =
           [Page 17]

 
RFC 6020                  =
        YANG                      October 2010


4.2.3.  State Data

   YANG can model state data, as well as configuration data, based on
   the "config" statement.  When a node is tagged with "config false",
   its subhierarchy is flagged as state data, to be reported using
   NETCONF's <get> operation, not the <get-config> operation.=
  Parent
   containers, lists, and key leafs are reported also, giving the
   context for the state data.

   In this example, two leafs are defined for each interface, a
   configured speed and an observed speed.  The observed speed is not
   configuration, so it can be returned with NETCONF <get> operatio=
ns,
   but not with <get-config> operations.  The observed speed is not=

   configuration data, and it cannot be manipulated using <edit-config=
>.

     list interface {
         key "name";

         leaf name {
             type string;
         }
         leaf speed {
             type enumeration {
                 enum 10m;
                 enum 100m;
                 enum auto;
             }
         }
         leaf observed-speed {
             type uint32;
             config false;
         }
     }

4.2.4.  Built-In Types

   YANG has a set of built-in types, similar to those of many
   programming languages, but with some differences due to special
   requirements from the management domain.  The following table
   summarizes the built-in types discussed in Sect=
ion 9:











Bjorklund                    Standards Track        =
           [Page 18]

 
RFC 6020                  =
        YANG                      October 2010


       +---------------------+-------------------------------------+
       | Name                | Description                         |
       +---------------------+-------------------------------------+
       | binary              | Any binary data                     |
       | bits                | A set of bits or flags              |
       | boolean             | "true" or "false"                   |
       | decimal64           | 64-bit signed decimal number        |
       | empty               | A leaf that does not have any value |
       | enumeration         | Enumerated strings                  |
       | identityref         | A reference to an abstract identity |
       | instance-identifier | References a data tree node         |
       | int8                | 8-bit signed integer                |
       | int16               | 16-bit signed integer               |
       | int32               | 32-bit signed integer               |
       | int64               | 64-bit signed integer               |
       | leafref             | A reference to a leaf instance      |
       | string              | Human-readable string               |
       | uint8               | 8-bit unsigned integer              |
       | uint16              | 16-bit unsigned integer             |
       | uint32              | 32-bit unsigned integer             |
       | uint64              | 64-bit unsigned integer             |
       | union               | Choice of member types              |
       +---------------------+-------------------------------------+

   The "type" statement is covered in Section 7.=
4.

4.2.5.  Derived Types (typedef)

   YANG can define derived types from base types using the "typedef"
   statement.  A base type can be either a built-in type or a derived
   type, allowing a hierarchy of derived types.

   A derived type can be used as the argument for the "type" statement.

   YANG Example:

     typedef percent {
         type uint8 {
             range "0 .. 100";
         }
         description "Percentage";
     }

     leaf completed {
         type percent;
     }





Bjorklund                    Standards Track        =
           [Page 19]

 
RFC 6020                  =
        YANG                      October 2010


   NETCONF XML Example:

     <completed>20</completed>

   The "typedef" statement is covered in Section=
 7.3.

4.2.6.  Reusable Node Groups (grouping)

   Groups of nodes can be assembled into reusable collections using the
   "grouping" statement.  A grouping defines a set of nodes that are
   instantiated with the "uses" statement:

     grouping target {
         leaf address {
             type inet:ip-address;
             description "Target IP address";
         }
         leaf port {
             type inet:port-number;
             description "Target port number";
         }
     }

     container peer {
         container destination {
             uses target;
         }
     }

   NETCONF XML Example:

     <peer>
       <destination>
         <address>192.0.2.1</address>
         <port>830</port>
       </destination>
     </peer>

   The grouping can be refined as it is used, allowing certain
   statements to be overridden.  In this example, the description is
   refined:










Bjorklund                    Standards Track        =
           [Page 20]

 
RFC 6020                  =
        YANG                      October 2010


     container connection {
         container source {
             uses target {
                 refine "address" {
                     description "Source IP address";
                 }
                 refine "port" {
                     description "Source port number";
                 }
             }
         }
         container destination {
             uses target {
                 refine "address" {
                     description "Destination IP address";
                 }
                 refine "port" {
                     description "Destination port number";
                 }
             }
         }
     }

   The "grouping" statement is covered in Secti=
on 7.11.

4.2.7.  Choices

   YANG allows the data model to segregate incompatible nodes into
   distinct choices using the "choice" and "case" statements.  The
   "choice" statement contains a set of "case" statements that define
   sets of schema nodes that cannot appear together.  Each "case" may
   contain multiple nodes, but each node may appear in only one "case"
   under a "choice".

   When an element from one case is created, all elements from all other
   cases are implicitly deleted.  The device handles the enforcement of
   the constraint, preventing incompatibilities from existing in the
   configuration.

   The choice and case nodes appear only in the schema tree, not in the
   data tree or NETCONF messages.  The additional levels of hierarchy
   are not needed beyond the conceptual schema.









Bjorklund                    Standards Track        =
           [Page 21]

 
RFC 6020                  =
        YANG                      October 2010


   YANG Example:

     container food {
       choice snack {
           case sports-arena {
               leaf pretzel {
                   type empty;
               }
               leaf beer {
                   type empty;
               }
           }
           case late-night {
               leaf chocolate {
                   type enumeration {
                       enum dark;
                       enum milk;
                       enum first-available;
                   }
               }
           }
       }
    }

   NETCONF XML Example:

     <food>
       <pretzel/>
       <beer/>
     </food>

   The "choice" statement is covered in Section =
7.9.

4.2.8.  Extending Data Models (augment)

   YANG allows a module to insert additional nodes into data models,
   including both the current module (and its submodules) or an external
   module.  This is useful for example for vendors to add vendor-
   specific parameters to standard data models in an interoperable way.

   The "augment" statement defines the location in the data model
   hierarchy where new nodes are inserted, and the "when" statement
   defines the conditions when the new nodes are valid.








Bjorklund                    Standards Track        =
           [Page 22]

 
RFC 6020                  =
        YANG                      October 2010


   YANG Example:

     augment /system/login/user {
         when "class !=3D 'wheel'";
         leaf uid {
             type uint16 {
                 range "1000 .. 30000";
             }
         }
     }

   This example defines a "uid" node that only is valid when the user's
   "class" is not "wheel".

   If a module augments another module, the XML representation of the
   data will reflect the prefix of the augmenting module.  For example,
   if the above augmentation were in a module with prefix "other", the
   XML would look like:

   NETCONF XML Example:

     <user>
       <name>alicew</name>
       <full-name>Alice N. Wonderland</full-name>
       <class>drop-out</class>
       <other:uid>1024</other:uid>
     </user>

   The "augment" statement is covered in Sectio=
n 7.15.

4.2.9.  RPC Definitions

   YANG allows the definition of NETCONF RPCs.  The operations' names,
   input parameters, and output parameters are modeled using YANG data
   definition statements.
















Bjorklund                    Standards Track        =
           [Page 23]

 
RFC 6020                  =
        YANG                      October 2010


   YANG Example:

     rpc activate-software-image {
         input {
             leaf image-name {
                 type string;
             }
         }
         output {
             leaf status {
                 type string;
             }
         }
     }

   NETCONF XML Example:

     <rpc message-id=3D"101"
          xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
       <activate-software-image xmlns=3D"http://acme.example.com/syste=
m">
         <image-name>acmefw-2.3</image-name>
      </activate-software-image>
     </rpc>

     <rpc-reply message-id=3D"101"
                xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
       <status xmlns=3D"http://acme.example.com/system">
         The image acmefw-2.3 is being installed.
       </status>
     </rpc-reply>

   The "rpc" statement is covered in Section 7.=
13.

4.2.10.  Notification Definitions

   YANG allows the definition of notifications suitable for NETCONF.
   YANG data definition statements are used to model the content of the
   notification.













Bjorklund                    Standards Track        =
           [Page 24]

 
RFC 6020                  =
        YANG                      October 2010


   YANG Example:

     notification link-failure {
         description "A link failure has been detected";
         leaf if-name {
             type leafref {
                 path "/interface/name";
             }
         }
         leaf if-admin-status {
             type admin-status;
         }
         leaf if-oper-status {
             type oper-status;
         }
     }

   NETCONF XML Example:

     <notification
         xmlns=3D"urn:ietf:params:netconf:capability:notification:1.0">=
;
       <eventTime>2007-09-01T10:00:00Z</eventTime>
       <link-failure xmlns=3D"http://acme.example.com/system">
         <if-name>so-1/2/3.0</if-name>
         <if-admin-status>up</if-admin-status>
         <if-oper-status>down</if-oper-status>
       </link-failure>
     </notification>

   The "notification" statement is covered in S=
ection 7.14.

5.  Language Concepts

5.1.  Modules and Submodules

   The module is the base unit of definition in YANG.  A module defines
   a single data model.  A module can define a complete, cohesive model,
   or augment an existing data model with additional nodes.

   Submodules are partial modules that contribute definitions to a
   module.  A module may include any number of submodules, but each
   submodule may belong to only one module.

   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.



Bjorklund                    Standards Track        =
           [Page 25]

 
RFC 6020                  =
        YANG                      October 2010


   A module uses the "include" statement to include its submodules, and
   the "import" statement to reference external modules.  Similarly, a
   submodule uses the "import" statement to reference other modules, and
   uses the "include" statement to reference other submodules within its
   module.  A module or submodule MUST NOT include submodules from other
   modules, and a submodule MUST NOT import its own module.

   The import and include statements are used to make definitions
   available to other modules and submodules:

   o  For a module or submodule to reference definitions in an external
      module, the external module MUST be imported.

   o  For a module to reference definitions in one of its submodules,
      the module MUST include the submodule.

   o  For a submodule to reference definitions in a second submodule of
      the same module, the first submodule MUST include the second
      submodule.

   There MUST NOT be any circular chains of imports or includes.  For
   example, if submodule "a" includes submodule "b", "b" cannot include
   "a".

   When a definition in an external module is referenced, a locally
   defined prefix MUST be used, followed by ":", and then the external
   identifier.  References to definitions in the local module MAY use
   the prefix notation.  Since built-in data types do not belong to any
   module and have no prefix, references to built-in data types (e.g.,
   int32) cannot use the prefix notation.

5.1.1.  Import and Include by Revision

   Published modules evolve independently over time.  In order to allow
   for this evolution, modules need to be imported using specific
   revisions.  When a module is written, it uses the current revisions
   of other modules, based on what is available at the time.  As future
   revisions of the imported modules are published, the importing module
   is unaffected and its contents are unchanged.  When the author of the
   module is prepared to move to the most recently published revision of
   an imported module, the module is republished with an updated
   "import" statement.  By republishing with the new revision, the
   authors explicitly indicate their acceptance of any changes in the
   imported module.







Bjorklund                    Standards Track        =
           [Page 26]

 
RFC 6020                  =
        YANG                      October 2010


   For submodules, the issue is related but simpler.  A module or
   submodule that includes submodules needs to specify the revision of
   the included submodules.  If a submodule changes, any module or
   submodule that includes it needs to be updated.

   For example, module "b" imports module "a".

     module a {
         revision 2008-01-01 { ... }
         grouping a {
             leaf eh { .... }
         }
     }

     module b {
         import a {
             prefix p;
             revision-date 2008-01-01;
         }

         container bee {
             uses p:a;
         }
     }

   When the author of "a" publishes a new revision, the changes may not
   be acceptable to the author of "b".  If the new revision is
   acceptable, the author of "b" can republish with an updated revision
   in the "import" statement.

5.1.2.  Module Hierarchies

   YANG allows modeling of data in multiple hierarchies, where data may
   have more than one top-level node.  Models that have multiple top-
   level nodes are sometimes convenient, and are supported by YANG.

   NETCONF is capable of carrying any XML content as the payload in the
   <config> and <data> elements.  The top-level nodes of YANG=
 modules
   are encoded as child elements, in any order, within these elements.
   This encapsulation guarantees that the corresponding NETCONF messages
   are always well-formed XML documents.










Bjorklund                    Standards Track        =
           [Page 27]

 
RFC 6020                  =
        YANG                      October 2010


   For example:

     module my-config {
         namespace "http://example.com/schema/config";
         prefix "co";

         container system { ... }
         container routing { ... }
     }

   could be encoded in NETCONF as:

     <rpc message-id=3D"101"
          xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"
          xmlns:nc=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
       <edit-config>
         <target>
           <running/>
         </target>
         <config>
           <system xmlns=3D"http://example.com/schema/config">
             <!-- system data here -->
           </system>
           <routing xmlns=3D"http://example.com/schema/config">
             <!-- routing data here -->
           </routing>
         </config>
       </edit-config>
     </rpc>

5.2.  File Layout

   YANG modules and submodules are typically stored in files, one module
   or submodule per file.  The name of the file SHOULD be of the form:

     module-or-submodule-name ['@' revision-date] ( '.yang' / '.yin' )

   YANG compilers can find imported modules and included submodules via
   this convention.  While the YANG language defines modules, tools may
   compile submodules independently for performance and manageability
   reasons.  Errors and warnings that cannot be detected during
   submodule compilation may be delayed until the submodules are linked
   into a cohesive module.








Bjorklund                    Standards Track        =
           [Page 28]

 
RFC 6020                  =
        YANG                      October 2010


5.3.  XML Namespaces

   All YANG definitions are specified within a module that is bound to a
   particular XML namespace [XML-NAMES], which is a glo=
bally unique URI
   [RFC3986].  A NETCONF client or server uses t=
he namespace during XML
   encoding of data.

   Namespaces for modules published in RFC streams [RFC4844] MUST be=

   assigned by IANA, see Section 14.

   Namespaces for private modules are assigned by the organization
   owning the module without a central registry.  Namespace URIs MUST be
   chosen so they cannot collide with standard or other enterprise
   namespaces, for example by using the enterprise or organization name
   in the namespace.

   The "namespace" statement is covered in Sec=
tion 7.1.3.

5.3.1.  YANG XML Namespace

   YANG defines an XML namespace for NETCONF <edit-config> operatio=
ns
   and <error-info> content.  The name of this namespace is
   "urn:ietf:params:xml:ns:yang:1".

5.4.  Resolving Grouping, Type, and Identity Names

   Grouping, type, and identity names are resolved in the context in
   which they are defined, rather than the context in which they are
   used.  Users of groupings, typedefs, and identities are not required
   to import modules or include submodules to satisfy all references
   made by the original definition.  This behaves like static scoping in
   a conventional programming language.

   For example, if a module defines a grouping in which a type is
   referenced, when the grouping is used in a second module, the type is
   resolved in the context of the original module, not the second
   module.  There is no worry over conflicts if both modules define the
   type, since there is no ambiguity.

5.5.  Nested Typedefs and Groupings

   Typedefs and groupings may appear nested under many YANG statements,
   allowing these to be lexically scoped by the hierarchy under which
   they appear.  This allows types and groupings to be defined near
   where they are used, rather than placing them at the top level of the
   hierarchy.  The close proximity increases readability.





Bjorklund                    Standards Track        =
           [Page 29]

 
RFC 6020                  =
        YANG                      October 2010


   Scoping also allows types to be defined without concern for naming
   conflicts between types in different submodules.  Type names can be
   specified without adding leading strings designed to prevent name
   collisions within large modules.

   Finally, scoping allows the module author to keep types and groupings
   private to their module or submodule, preventing their reuse.  Since
   only top-level types and groupings (i.e., those appearing as
   substatements to a module or submodule statement) can be used outside
   the module or submodule, the developer has more control over what
   pieces of their module are presented to the outside world, supporting
   the need to hide internal information and maintaining a boundary
   between what is shared with the outside world and what is kept
   private.

   Scoped definitions MUST NOT shadow definitions at a higher scope.  A
   type or grouping cannot be defined if a higher level in the schema
   hierarchy has a definition with a matching identifier.

   A reference to an unprefixed type or grouping, or one which uses the
   prefix of the current module, is resolved by locating the closest
   matching "typedef" or "grouping" statement among the immediate
   substatements of each ancestor statement.

5.6.  Conformance

   Conformance is a measure of how accurately a device follows the
   model.  Generally speaking, devices are responsible for implementing
   the model faithfully, allowing applications to treat devices which
   implement the model identically.  Deviations from the model can
   reduce the utility of the model and increase fragility of
   applications that use it.

   YANG modelers have three mechanisms for conformance:

   o  the basic behavior of the model

   o  optional features that are part of the model

   o  deviations from the model

   We will consider each of these in sequence.









Bjorklund                    Standards Track        =
           [Page 30]

 
RFC 6020                  =
        YANG                      October 2010


5.6.1.  Basic Behavior

   The model defines a contract between the NETCONF client and server,
   which allows both parties to have faith the other knows the syntax
   and semantics behind the modeled data.  The strength of YANG lies in
   the strength of this contract.

5.6.2.  Optional Features

   In many models, the modeler will allow sections of the model to be
   conditional.  The device controls whether these conditional portions
   of the model are supported or valid for that particular device.

   For example, a syslog data model may choose to include the ability to
   save logs locally, but the modeler will realize that this is only
   possible if the device has local storage.  If there is no local
   storage, an application should not tell the device to save logs.

   YANG supports this conditional mechanism using a construct called
   "feature".  Features give the modeler a mechanism for making portions
   of the module conditional in a manner that is controlled by the
   device.  The model can express constructs that are not universally
   present in all devices.  These features are included in the model
   definition, allowing a consistent view and allowing applications to
   learn which features are supported and tailor their behavior to the
   device.

   A module may declare any number of features, identified by simple
   strings, and may make portions of the module optional based on those
   features.  If the device supports a feature, then the corresponding
   portions of the module are valid for that device.  If the device
   doesn't support the feature, those parts of the module are not valid,
   and applications should behave accordingly.

   Features are defined using the "feature" statement.  Definitions in
   the module that are conditional to the feature are noted by the
   "if-feature" statement with the name of the feature as its argument.

   Further details are available in Section 7=
=2E18.1.

5.6.3.  Deviations

   In an ideal world, all devices would be required to implement the
   model exactly as defined, and deviations from the model would not be
   allowed.  But in the real world, devices are often not able or
   designed to implement the model as written.  For YANG-based





Bjorklund                    Standards Track        =
           [Page 31]

 
RFC 6020                  =
        YANG                      October 2010


   automation to deal with these device deviations, a mechanism must
   exist for devices to inform applications of the specifics of such
   deviations.

   For example, a BGP module may allow any number of BGP peers, but a
   particular device may only support 16 BGP peers.  Any application
   configuring the 17th peer will receive an error.  While an error may
   suffice to let the application know it cannot add another peer, it
   would be far better if the application had prior knowledge of this
   limitation and could prevent the user from starting down the path
   that could not succeed.

   Device deviations are declared using the "deviation" statement, which
   takes as its argument a string that identifies a node in the schema
   tree.  The contents of the statement details the manner in which the
   device implementation deviates from the contract as defined in the
   module.

   Further details are available in Section 7=
=2E18.3.

5.6.4.  Announcing Conformance Information in the <=
hello> Message

   The namespace URI MUST be advertised as a capability in the NETCONF
   <hello> message to indicate support for the YANG module by a NET=
CONF
   server.  The capability URI advertised MUST be of the form:

     capability-string   =3D namespace-uri [ parameter-list ]
     parameter-list      =3D "?" parameter *( "&" parameter )
     parameter           =3D revision-parameter /
                           module-parameter /
                           feature-parameter /
                           deviation-parameter
     revision-parameter  =3D "revision=3D" revision-date
     module-parameter    =3D "module=3D" module-name
     feature-parameter   =3D "features=3D" feature *( "," feature )
     deviation-parameter =3D "deviations=3D" deviation *( "," deviation )=


   Where "revision-date" is the revision of the module (see
   Section 7.1.9) that the NETCONF server =
implements, "module-name" is
   the name of module as it appears in the "module" statement (see
   Section 7.1), "namespace-uri" is the name=
space URI for the module as
   it appears in the "namespace" statement (see Section 7.1.3),
   "feature" is the name of an optional feature implemented by the
   device (see Section 7.18.1), and "devi=
ation" is the name of a module
   defining device deviations (see Section 7.=
18.3).

   In the parameter list, each named parameter MUST occur at most once.




Bjorklund                    Standards Track        =
           [Page 32]

 
RFC 6020                  =
        YANG                      October 2010


5.6.4.1.  Modules

   Servers indicate the names of supported modules via the <hello>
   message.  Module namespaces are encoded as the base URI in the
   capability string, and the module name is encoded as the "module"
   parameter to the base URI.

   A server MUST advertise all revisions of all modules it implements.

   For example, this <hello> message advertises one module "syslog"=
=2E

   <hello xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
     <capability>
       http://example.com/syslog?module=3Dsyslog&amp;revision=3D2008-=
04-01
     </capability>
   </hello>

5.6.4.2.  Features

   Servers indicate the names of supported features via the <hello>=

   message.  In <hello> messages, the features are encoded in the
   "features" parameter within the URI.  The value of this parameter is
   a comma-separated list of feature names that the device supports for
   the specific module.

   For example, this <hello> message advertises one module, informi=
ng
   the client that it supports the "local-storage" feature of module
   "syslog".
<hello xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
  <capability>
    http://example.com/syslog?module=3Dsyslog&amp;features=3Dlocal-st=
orage
  </capability>
</hello>

5.6.4.3.  Deviations

   Device deviations are announced via the "deviations" parameter.  The
   value of the "deviations" parameter is a comma-separated list of
   modules containing deviations from the capability's module.

   For example, this <hello> message advertises two modules, inform=
ing
   the client that it deviates from module "syslog" according to the
   deviations listed in the module "my-devs".








Bjorklund                    Standards Track        =
           [Page 33]

 
RFC 6020                  =
        YANG                      October 2010


   <hello xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
       <capability>
         http://example.com/syslog?module=3Dsyslog&amp;deviations=3Dm=
y-devs
       </capability>
       <capability>
         http://example.com/my-deviations?module=3Dmy-devs
       </capability>
     </hello>

5.7.  Data Store Modification

   Data models may allow the server to alter the configuration data
   store in ways not explicitly directed via NETCONF protocol messages.
   For example, a data model may define leafs that are assigned system-
   generated values when the client does not provide one.  A formal
   mechanism for specifying the circumstances where these changes are
   allowed is out of scope for this specification.

6.  YANG Syntax

   The YANG syntax is similar to that of SMIng [RFC3780] and programming
   languages like C and C++.  This C-like syntax was chosen specifically
   for its readability, since YANG values the time and effort of the
   readers of models above those of modules writers and YANG tool-chain
   developers.  This section introduces the YANG syntax.

   YANG modules use the UTF-8 [RFC3629] character enco=
ding.

6.1.  Lexical Tokenization

   YANG modules are parsed as a series of tokens.  This section details
   the rules for recognizing tokens from an input stream.  YANG
   tokenization rules are both simple and powerful.  The simplicity is
   driven by a need to keep the parsers easy to implement, while the
   power is driven by the fact that modelers need to express their
   models in readable formats.

6.1.1.  Comments

   Comments are C++ style.  A single line comment starts with "//" and
   ends at the end of the line.  A block comment is enclosed within "/*"
   and "*/".

6.1.2.  Tokens

   A token in YANG is either a keyword, a string, a semicolon (";"), or
   braces ("{" or "}").  A string can be quoted or unquoted.  A keyword
   is either one of the YANG keywords defined in this document, or a



Bjorklund                    Standards Track        =
           [Page 34]

 
RFC 6020                  =
        YANG                      October 2010


   prefix identifier, followed by ":", followed by a language extension
   keyword.  Keywords are case sensitive.  See S=
ection 6.2 for a formal
   definition of identifiers.

6.1.3.  Quoting

   If a string contains any space or tab characters, a semicolon (";"),
   braces ("{" or "}"), or comment sequences ("//", "/*", or "*/"), then
   it MUST be enclosed within double or single quotes.

   If the double-quoted string contains a line break followed by space
   or tab characters that are used to indent the text according to the
   layout in the YANG file, this leading whitespace is stripped from the
   string, up to and including the column of the double quote character,
   or to the first non-whitespace character, whichever occurs first.  In
   this process, a tab character is treated as 8 space characters.

   If the double-quoted string contains space or tab characters before a
   line break, this trailing whitespace is stripped from the string.

   A single-quoted string (enclosed within ' ') preserves each character
   within the quotes.  A single quote character cannot occur in a
   single-quoted string, even when preceded by a backslash.

   Within a double-quoted string (enclosed within " "), a backslash
   character introduces a special character, which depends on the
   character that immediately follows the backslash:

    \n      new line
    \t      a tab character
    \"      a double quote
    \\      a single backslash

   If a quoted string is followed by a plus character ("+"), followed by
   another quoted string, the two strings are concatenated into one
   string, allowing multiple concatenations to build one string.
   Whitespace trimming and substitution of backslash-escaped characters
   in double-quoted strings is done before concatenation.

6.1.3.1.  Quoting Examples

   The following strings are equivalent:

     hello
     "hello"
     'hello'
     "hel" + "lo"
     'hel' + "lo"



Bjorklund                    Standards Track        =
           [Page 35]

 
RFC 6020                  =
        YANG                      October 2010


   The following examples show some special strings:

     "\""  - string containing a double quote
     '"'   - string containing a double quote
     "\n"  - string containing a new line character
     '\n'  - string containing a backslash followed
             by the character n

   The following examples show some illegal strings:

     ''''  - a single-quoted string cannot contain single quotes
     """   - a double quote must be escaped in a double-quoted string

   The following strings are equivalent:

         "first line
            second line"

     "first line\n" + "  second line"

6.2.  Identifiers

   Identifiers are used to identify different kinds of YANG items by
   name.  Each identifier starts with an uppercase or lowercase ASCII
   letter or an underscore character, followed by zero or more ASCII
   letters, digits, underscore characters, hyphens, and dots.
   Implementations MUST support identifiers up to 64 characters in
   length.  Identifiers are case sensitive.  The identifier syntax is
   formally defined by the rule "identifier" in S=
ection 12.  Identifiers
   can be specified as quoted or unquoted strings.

6.2.1.  Identifiers and Their Namespaces

   Each identifier is valid in a namespace that depends on the type of
   the YANG item being defined.  All identifiers defined in a namespace
   MUST be unique.

   o  All module and submodule names share the same global module
      identifier namespace.

   o  All extension names defined in a module and its submodules share
      the same extension identifier namespace.

   o  All feature names defined in a module and its submodules share the
      same feature identifier namespace.

   o  All identity names defined in a module and its submodules share
      the same identity identifier namespace.



Bjorklund                    Standards Track        =
           [Page 36]

 
RFC 6020                  =
        YANG                      October 2010


   o  All derived type names defined within a parent node or at the top
      level of the module or its submodules share the same type
      identifier namespace.  This namespace is scoped to all descendant
      nodes of the parent node or module.  This means that any
      descendent node may use that typedef, and it MUST NOT define a
      typedef with the same name.

   o  All grouping names defined within a parent node or at the top
      level of the module or its submodules share the same grouping
      identifier namespace.  This namespace is scoped to all descendant
      nodes of the parent node or module.  This means that any
      descendent node may use that grouping, and it MUST NOT define a
      grouping with the same name.

   o  All leafs, leaf-lists, lists, containers, choices, rpcs,
      notifications, and anyxmls defined (directly or through a uses
      statement) within a parent node or at the top level of the module
      or its submodules share the same identifier namespace.  This
      namespace is scoped to the parent node or module, unless the
      parent node is a case node.  In that case, the namespace is scoped
      to the closest ancestor node that is not a case or choice node.

   o  All cases within a choice share the same case identifier
      namespace.  This namespace is scoped to the parent choice node.

   Forward references are allowed in YANG.

6.3.  Statements

   A YANG module contains a sequence of statements.  Each statement
   starts with a keyword, followed by zero or one argument, followed
   either by a semicolon (";") or a block of substatements enclosed
   within braces ("{ }"):

     statement =3D keyword [argument] (";" / "{" *statement "}")

   The argument is a string, as defined in Sec=
tion 6.1.2.

6.3.1.  Language Extensions

   A module can introduce YANG extensions by using the "extension"
   keyword (see Section 7.17).  The extensi=
ons can be imported by other
   modules with the "import" statement (see Se=
ction 7.1.5).  When an
   imported extension is used, the extension's keyword MUST be qualified
   using the prefix with which the extension's module was imported.  If
   an extension is used in the module where it is defined, the
   extension's keyword MUST be qualified with the module's prefix.




Bjorklund                    Standards Track        =
           [Page 37]

 
RFC 6020                  =
        YANG                      October 2010


   Since submodules cannot include the parent module, any extensions in
   the module that need to be exposed to submodules MUST be defined in a
   submodule.  Submodules can then include this submodule to find the
   definition of the extension.

   If a YANG compiler does not support a particular extension, which
   appears in a YANG module as an unknown-statement (see Section 12),
   the entire unknown-statement MAY be ignored by the compiler.

6.4.  XPath Evaluations

   YANG relies on XML Path Language (XPath) 1.0 [XPATH] as =
a notation
   for specifying many inter-node references and dependencies.  NETCONF
   clients and servers are not required to implement an XPath
   interpreter, but MUST ensure that the requirements encoded in the
   data model are enforced.  The manner of enforcement is an
   implementation decision.  The XPath expressions MUST be syntactically
   correct, and all prefixes used MUST be present in the XPath context
   (see Section 6.4.1).  An implementation=
 may choose to implement them
   by hand, rather than using the XPath expression directly.

   The data model used in the XPath expressions is the same as that used
   in XPath 1.0 [XPATH], with the same extension for root n=
ode children
   as used by XSLT 1.0 [XSLT] (Sec=
tion 3.1).  Specifically, it means
   that the root node may have any number of element nodes as its
   children.

6.4.1.  XPath Context

   All YANG XPath expressions share the following XPath context
   definition:

   o  The set of namespace declarations is the set of all "import"
      statements' prefix and namespace pairs in the module where the
      XPath expression is specified, and the "prefix" statement's prefix
      for the "namespace" statement's URI.

   o  Names without a namespace prefix belong to the same namespace as
      the identifier of the current node.  Inside a grouping, that
      namespace is affected by where the grouping is used (see
      Section 7.12).

   o  The function library is the core function library defined in
      [XPATH], and a function "current()" that returns a no=
de set with
      the initial context node.

   o  The set of variable bindings is empty.




Bjorklund                    Standards Track        =
           [Page 38]

 
RFC 6020                  =
        YANG                      October 2010


   The mechanism for handling unprefixed names is adopted from XPath 2.0
   [XPATH2.0], and helps simplify XPath expressions in YANG.  No=

   ambiguity may ever arise because YANG node identifiers are always
   qualified names with a non-null namespace URI.

   The context node varies with the YANG XPath expression, and is
   specified where the YANG statement with the XPath expression is
   defined.

6.5.  Schema Node Identifier

   A schema node identifier is a string that identifies a node in the
   schema tree.  It has two forms, "absolute" and "descendant", defined
   by the rules "absolute-schema-nodeid" and "descendant-schema-nodeid"
   in Section 12, respectively.  A schema nod=
e identifier consists of a
   path of identifiers, separated by slashes ("/").  In an absolute
   schema node identifier, the first identifier after the leading slash
   is any top-level schema node in the local module or in all imported
   modules.

   References to identifiers defined in external modules MUST be
   qualified with appropriate prefixes, and references to identifiers
   defined in the current module and its submodules MAY use a prefix.

   For example, to identify the child node "b" of top-level node "a",
   the string "/a/b" can be used.

7.  YANG Statements

   The following sections describe all of the YANG statements.

   Note that even a statement that does not have any substatements
   defined in YANG can have vendor-specific extensions as substatements.
   For example, the "description" statement does not have any
   substatements defined in YANG, but the following is legal:

     description "some text" {
         acme:documentation-flag 5;
     }

7.1.  The module Statement

   The "module" statement defines the module's name, and groups all
   statements that belong to the module together.  The "module"
   statement's argument is the name of the module, followed by a block
   of substatements that hold detailed module information.  The module
   name follows the rules for identifiers in Sec=
tion 6.2.




Bjorklund                    Standards Track        =
           [Page 39]

 
RFC 6020                  =
        YANG                      October 2010


   Names of modules published in RFC streams [RFC4844] MUST be assig=
ned
   by IANA, see Section 14.

   Private module names are assigned by the organization owning the
   module without a central registry.  It is RECOMMENDED to choose
   module names that will have a low probability of colliding with
   standard or other enterprise modules and submodules, e.g., by using
   the enterprise or organization name as a prefix for the module name.

   A module typically has the following layout:

     module <module-name> {

         // header information
         <yang-version statement>
         <namespace statement>
         <prefix statement>

         // linkage statements
         <import statements>
         <include statements>

         // meta information
         <organization statement>
         <contact statement>
         <description statement>
         <reference statement>

         // revision history
         <revision statements>

         // module definitions
         <other statements>
     }

















Bjorklund                    Standards Track        =
           [Page 40]

 
RFC 6020                  =
        YANG                      October 2010


7.1.1.  The module's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | anyxml       | 7.10    | 0..n        |
                 | augment      | 7.15    | 0..n        |
                 | choice       | 7.9     | 0..n        |
                 | contact      | 7.1.8   | 0..1        |
                 | container    | 7.5     | 0..n        |
                 | description  | 7.19.3  | 0..1        |
                 | deviation    | 7.18.3  | 0..n        |
                 | extension    | 7.17    | 0..n        |
                 | feature      | 7.18.1  | 0..n        |
                 | grouping     | 7.11    | 0..n        |
                 | identity     | 7.16    | 0..n        |
                 | import       | 7.1.5   | 0..n        |
                 | include      | 7.1.6   | 0..n        |
                 | leaf         | 7.6     | 0..n        |
                 | leaf-list    | 7.7     | 0..n        |
                 | list         | 7.8     | 0..n        |
                 | namespace    | 7.1.3   | 1           |
                 | notification | 7.14    | 0..n        |
                 | organization | 7.1.7   | 0..1        |
                 | prefix       | 7.1.4   | 1           |
                 | reference    | 7.19.4  | 0..1        |
                 | revision     | 7.1.9   | 0..n        |
                 | rpc          | 7.13    | 0..n        |
                 | typedef      | 7.3     | 0..n        |
                 | uses         | 7.12    | 0..n        |
                 | yang-version | 7.1.2   | 0..1        |
                 +--------------+---------+-------------+

7.1.2.  The yang-version Statement

   The optional "yang-version" statement specifies which version of the
   YANG language was used in developing the module.  The statement's
   argument is a string.  If present, it MUST contain the value "1",
   which is the current YANG version and the default value.

   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.







Bjorklund                    Standards Track        =
           [Page 41]

 
RFC 6020                  =
        YANG                      October 2010


7.1.3.  The namespace Statement

   The "namespace" statement defines the XML namespace that all
   identifiers defined by the module are qualified by, with the
   exception of data node identifiers defined inside a grouping (see
   Section 7.12 for details).  The argument=
 to the "namespace" statement
   is the URI of the namespace.

   See also Section 5.3.

7.1.4.  The prefix Statement

   The "prefix" statement is used to define the prefix associated with
   the module and its namespace.  The "prefix" statement's argument is
   the prefix string that is used as a prefix to access a module.  The
   prefix string MAY be used to refer to definitions contained in the
   module, e.g., "if:ifName".  A prefix follows the same rules as an
   identifier (see Section 6.2).

   When used inside the "module" statement, the "prefix" statement
   defines the prefix to be used when this module is imported.  To
   improve readability of the NETCONF XML, a NETCONF client or server
   that generates XML or XPath that use prefixes SHOULD use the prefix
   defined by the module, unless there is a conflict.

   When used inside the "import" statement, the "prefix" statement
   defines the prefix to be used when accessing definitions inside the
   imported module.  When a reference to an identifier from the imported
   module is used, the prefix string for the imported module is used in
   combination with a colon (":") and the identifier, e.g., "if:
   ifIndex".  To improve readability of YANG modules, the prefix defined
   by a module SHOULD be used when the module is imported, unless there
   is a conflict.  If there is a conflict, i.e., two different modules
   that both have defined the same prefix are imported, at least one of
   them MUST be imported with a different prefix.

   All prefixes, including the prefix for the module itself MUST be
   unique within the module or submodule.

7.1.5.  The import Statement

   The "import" statement makes definitions from one module available
   inside another module or submodule.  The argument is the name of the
   module to import, and the statement is followed by a block of
   substatements that holds detailed import information.  When a module
   is imported, the importing module may:





Bjorklund                    Standards Track        =
           [Page 42]

 
RFC 6020                  =
        YANG                      October 2010


   o  use any grouping and typedef defined at the top level in the
      imported module or its submodules.

   o  use any extension, feature, and identity defined in the imported
      module or its submodules.

   o  use any node in the imported module's schema tree in "must",
      "path", and "when" statements, or as the target node in "augment"
      and "deviation" statements.

   The mandatory "prefix" substatement assigns a prefix for the imported
   module that is scoped to the importing module or submodule.  Multiple
   "import" statements may be specified to import from different
   modules.

   When the optional "revision-date" substatement is present, any
   typedef, grouping, extension, feature, and identity referenced by
   definitions in the local module are taken from the specified revision
   of the imported module.  It is an error if the specified revision of
   the imported module does not exist.  If no "revision-date"
   substatement is present, it is undefined from which revision of the
   module they are taken.

   Multiple revisions of the same module MUST NOT be imported.

                        The import's Substatements

                 +---------------+---------+-------------+
                 | substatement  | section | cardinality |
                 +---------------+---------+-------------+
                 | prefix        | 7.1.4   | 1           |
                 | revision-date | 7.1.5.1 | 0..1        |
                 +---------------+---------+-------------+

7.1.5.1.  The import's revision-date Statement

   The import's "revision-date" statement is used to specify the exact
   version of the module to import.  The "revision-date" statement MUST
   match the most recent "revision" statement in the imported module.

7.1.6.  The include Statement

   The "include" statement is used to make content from a submodule
   available to that submodule's parent module, or to another submodule
   of that parent module.  The argument is an identifier that is the
   name of the submodule to include.  Modules are only allowed to





Bjorklund                    Standards Track        =
           [Page 43]

 
RFC 6020                  =
        YANG                      October 2010


   include submodules that belong to that module, as defined by the
   "belongs-to" statement (see Section 7.2.2).  Submodules are only
   allowed to include other submodules belonging to the same module.

   When a module includes a submodule, it incorporates the contents of
   the submodule into the node hierarchy of the module.  When a
   submodule includes another submodule, the target submodule's
   definitions are made available to the current submodule.

   When the optional "revision-date" substatement is present, the
   specified revision of the submodule is included in the module.  It is
   an error if the specified revision of the submodule does not exist.
   If no "revision-date" substatement is present, it is undefined which
   revision of the submodule is included.

   Multiple revisions of the same submodule MUST NOT be included.

                       The includes's Substatements

                 +---------------+---------+-------------+
                 | substatement  | section | cardinality |
                 +---------------+---------+-------------+
                 | revision-date | 7.1.5.1 | 0..1        |
                 +---------------+---------+-------------+

7.1.7.  The organization Statement

   The "organization" statement defines the party responsible for this
   module.  The argument is a string that is used to specify a textual
   description of the organization(s) under whose auspices this module
   was developed.

7.1.8.  The contact Statement

   The "contact" statement provides contact information for the module.
   The argument is a string that is used to specify contact information
   for the person or persons to whom technical queries concerning this
   module should be sent, such as their name, postal address, telephone
   number, and electronic mail address.

7.1.9.  The revision Statement

   The "revision" statement specifies the editorial revision history of
   the module, including the initial revision.  A series of revision
   statements detail the changes in the module's definition.  The
   argument is a date string in the format "YYYY-MM-DD", followed by a
   block of substatements that holds detailed revision information.  A
   module SHOULD have at least one initial "revision" statement.  For



Bjorklund                    Standards Track        =
           [Page 44]

 
RFC 6020                  =
        YANG                      October 2010


   every published editorial change, a new one SHOULD be added in front
   of the revisions sequence, so that all revisions are in reverse
   chronological order.

7.1.9.1.  The revision's Substatement

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | description  | 7.19.3  | 0..1        |
                 | reference    | 7.19.4  | 0..1        |
                 +--------------+---------+-------------+

7.1.10.  Usage Example

     module acme-system {
         namespace "http://acme.example.com/system";
         prefix "acme";

         import ietf-yang-types {
             prefix "yang";
         }

         include acme-types;

         organization "ACME Inc.";
         contact
             "Joe L. User

              ACME, Inc.
              42 Anywhere Drive
              Nowhere, CA 95134
              USA

              Phone: +1 800 555 0100
              EMail: joe@acme.example.com";

         description
             "The module for entities implementing the ACME protocol.";

         revision "2007-06-09" {
             description "Initial revision.";
         }

         // definitions follow...
     }





Bjorklund                    Standards Track        =
           [Page 45]

 
RFC 6020                  =
        YANG                      October 2010


7.2.  The submodule Statement

   While the primary unit in YANG is a module, a YANG module can itself
   be constructed out of several submodules.  Submodules allow a module
   designer to split a complex model into several pieces where all the
   submodules contribute to a single namespace, which is defined by the
   module that includes the submodules.

   The "submodule" statement defines the submodule's name, and groups
   all statements that belong to the submodule together.  The
   "submodule" statement's argument is the name of the submodule,
   followed by a block of substatements that hold detailed submodule
   information.  The submodule name follows the rules for identifiers in
   Section 6.2.

   Names of submodules published in RFC streams [RFC4844] MUST be
   assigned by IANA, see Section 14.

   Private submodule names are assigned by the organization owning the
   submodule without a central registry.  It is RECOMMENDED to choose
   submodule names that will have a low probability of colliding with
   standard or other enterprise modules and submodules, e.g., by using
   the enterprise or organization name as a prefix for the submodule
   name.



























Bjorklund                    Standards Track        =
           [Page 46]

 
RFC 6020                  =
        YANG                      October 2010


   A submodule typically has the following layout:

     submodule <module-name> {

         <yang-version statement>

         // module identification
         <belongs-to statement>

         // linkage statements
         <import statements>
         <include statements>

         // meta information
         <organization statement>
         <contact statement>
         <description statement>
         <reference statement>

         // revision history
         <revision statements>

         // module definitions
         <other statements>
     }


























Bjorklund                    Standards Track        =
           [Page 47]

 
RFC 6020                  =
        YANG                      October 2010


7.2.1.  The submodule's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | anyxml       | 7.10    | 0..n        |
                 | augment      | 7.15    | 0..n        |
                 | belongs-to   | 7.2.2   | 1           |
                 | choice       | 7.9     | 0..n        |
                 | contact      | 7.1.8   | 0..1        |
                 | container    | 7.5     | 0..n        |
                 | description  | 7.19.3  | 0..1        |
                 | deviation    | 7.18.3  | 0..n        |
                 | extension    | 7.17    | 0..n        |
                 | feature      | 7.18.1  | 0..n        |
                 | grouping     | 7.11    | 0..n        |
                 | identity     | 7.16    | 0..n        |
                 | import       | 7.1.5   | 0..n        |
                 | include      | 7.1.6   | 0..n        |
                 | leaf         | 7.6     | 0..n        |
                 | leaf-list    | 7.7     | 0..n        |
                 | list         | 7.8     | 0..n        |
                 | notification | 7.14    | 0..n        |
                 | organization | 7.1.7   | 0..1        |
                 | reference    | 7.19.4  | 0..1        |
                 | revision     | 7.1.9   | 0..n        |
                 | rpc          | 7.13    | 0..n        |
                 | typedef      | 7.3     | 0..n        |
                 | uses         | 7.12    | 0..n        |
                 | yang-version | 7.1.2   | 0..1        |
                 +--------------+---------+-------------+

7.2.2.  The belongs-to Statement

   The "belongs-to" statement specifies the module to which the
   submodule belongs.  The argument is an identifier that is the name of
   the module.

   A submodule MUST only be included by the module to which it belongs,
   or by another submodule that belongs to that module.

   The mandatory "prefix" substatement assigns a prefix for the module
   to which the submodule belongs.  All definitions in the local
   submodule and any included submodules can be accessed by using the
   prefix.






Bjorklund                    Standards Track        =
           [Page 48]

 
RFC 6020                  =
        YANG                      October 2010


                      The belongs-to's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | prefix       | 7.1.4   | 1           |
                 +--------------+---------+-------------+

7.2.3.  Usage Example

     submodule acme-types {

         belongs-to "acme-system" {
             prefix "acme";
         }

         import ietf-yang-types {
             prefix "yang";
         }

         organization "ACME Inc.";
         contact
             "Joe L. User

              ACME, Inc.
              42 Anywhere Drive
              Nowhere, CA 95134
              USA

              Phone: +1 800 555 0100
              EMail: joe@acme.example.com";

         description
             "This submodule defines common ACME types.";

         revision "2007-06-09" {
             description "Initial revision.";
         }

         // definitions follows...
     }

7.3.  The typedef Statement

   The "typedef" statement defines a new type that may be used locally
   in the module, in modules or submodules which include it, and by
   other modules that import from it, according to the rules in




Bjorklund                    Standards Track        =
           [Page 49]

 
RFC 6020                  =
        YANG                      October 2010


   Section 5.5.  The new type is called the =
"derived type", and the type
   from which it was derived is called the "base type".  All derived
   types can be traced back to a YANG built-in type.

   The "typedef" statement's argument is an identifier that is the name
   of the type to be defined, and MUST be followed by a block of
   substatements that holds detailed typedef information.

   The name of the type MUST NOT be one of the YANG built-in types.  If
   the typedef is defined at the top level of a YANG module or
   submodule, the name of the type to be defined MUST be unique within
   the module.

7.3.1.  The typedef's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | default      | 7.3.4   | 0..1        |
                 | description  | 7.19.3  | 0..1        |
                 | reference    | 7.19.4  | 0..1        |
                 | status       | 7.19.2  | 0..1        |
                 | type         | 7.3.2   | 1           |
                 | units        | 7.3.3   | 0..1        |
                 +--------------+---------+-------------+

7.3.2.  The typedef's type Statement

   The "type" statement, which MUST be present, defines the base type
   from which this type is derived.  See Section=
 7.4 for details.

7.3.3.  The units Statement

   The "units" statement, which is optional, takes as an argument a
   string that contains a textual definition of the units associated
   with the type.

7.3.4.  The typedef's default Statement

   The "default" statement takes as an argument a string that contains a
   default value for the new type.

   The value of the "default" statement MUST be valid according to the
   type specified in the "type" statement.

   If the base type has a default value, and the new derived type does
   not specify a new default value, the base type's default value is
   also the default value of the new derived type.



Bjorklund                    Standards Track        =
           [Page 50]

 
RFC 6020                  =
        YANG                      October 2010


   If the type's default value is not valid according to the new
   restrictions specified in a derived type or leaf definition, the
   derived type or leaf definition MUST specify a new default value
   compatible with the restrictions.

7.3.5.  Usage Example

     typedef listen-ipv4-address {
         type inet:ipv4-address;
         default "0.0.0.0";
     }

7.4.  The type Statement

   The "type" statement takes as an argument a string that is the name
   of a YANG built-in type (see Section 9) or =
a derived type (see
   Section 7.3), followed by an optional blo=
ck of substatements that are
   used to put further restrictions on the type.

   The restrictions that can be applied depend on the type being
   restricted.  The restriction statements for all built-in types are
   described in the subsections of Section 9.

7.4.1.  The type's Substatements

               +------------------+---------+-------------+
               | substatement     | section | cardinality |
               +------------------+---------+-------------+
               | bit              | 9.7.4   | 0..n        |
               | enum             | 9.6.4   | 0..n        |
               | length           | 9.4.4   | 0..1        |
               | path             | 9.9.2   | 0..1        |
               | pattern          | 9.4.6   | 0..n        |
               | range            | 9.2.4   | 0..1        |
               | require-instance | 9.13.2  | 0..1        |
               | type             | 7.4     | 0..n        |
               +------------------+---------+-------------+

7.5.  The container Statement

   The "container" statement is used to define an interior data node in
   the schema tree.  It takes one argument, which is an identifier,
   followed by a block of substatements that holds detailed container
   information.

   A container node does not have a value, but it has a list of child
   nodes in the data tree.  The child nodes are defined in the
   container's substatements.



Bjorklund                    Standards Track        =
           [Page 51]

 
RFC 6020                  =
        YANG                      October 2010


7.5.1.  Containers with Presence

   YANG supports two styles of containers, those that exist only for
   organizing the hierarchy of data nodes, and those whose presence in
   the configuration has an explicit meaning.

   In the first style, the container has no meaning of its own, existing
   only to contain child nodes.  This is the default style.

   For example, the set of scrambling options for Synchronous Optical
   Network (SONET) interfaces may be placed inside a "scrambling"
   container to enhance the organization of the configuration hierarchy,
   and to keep these nodes together.  The "scrambling" node itself has
   no meaning, so removing the node when it becomes empty relieves the
   user from performing this task.

   In the second style, the presence of the container itself is
   configuration data, representing a single bit of configuration data.
   The container acts as both a configuration knob and a means of
   organizing related configuration.  These containers are explicitly
   created and deleted.

   YANG calls this style a "presence container" and it is indicated
   using the "presence" statement, which takes as its argument a text
   string indicating what the presence of the node means.

   For example, an "ssh" container may turn on the ability to log into
   the device using ssh, but can also contain any ssh-related
   configuration knobs, such as connection rates or retry limits.

   The "presence" statement (see Section 7.5.5=
) is used to give
   semantics to the existence of the container in the data tree.



















Bjorklund                    Standards Track        =
           [Page 52]

 
RFC 6020                  =
        YANG                      October 2010


7.5.2.  The container's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | anyxml       | 7.10    | 0..n        |
                 | choice       | 7.9     | 0..n        |
                 | config       | 7.19.1  | 0..1        |
                 | container    | 7.5     | 0..n        |
                 | description  | 7.19.3  | 0..1        |
                 | grouping     | 7.11    | 0..n        |
                 | if-feature   | 7.18.2  | 0..n        |
                 | leaf         | 7.6     | 0..n        |
                 | leaf-list    | 7.7     | 0..n        |
                 | list         | 7.8     | 0..n        |
                 | must         | 7.5.3   | 0..n        |
                 | presence     | 7.5.5   | 0..1        |
                 | reference    | 7.19.4  | 0..1        |
                 | status       | 7.19.2  | 0..1        |
                 | typedef      | 7.3     | 0..n        |
                 | uses         | 7.12    | 0..n        |
                 | when         | 7.19.5  | 0..1        |
                 +--------------+---------+-------------+

7.5.3.  The must Statement

   The "must" statement, which is optional, takes as an argument a
   string that contains an XPath expression (see Section 6.4).  It is
   used to formally declare a constraint on valid data.  The constraint
   is enforced according to the rules in Section 8=
.

   When a datastore is validated, all "must" constraints are
   conceptually evaluated once for each data node in the data tree, and
   for all leafs with default values in use (see Section 7.6.1).  If a
   data node does not exist in the data tree, and it does not have a
   default value, its "must" statements are not evaluated.

   All such constraints MUST evaluate to true for the data to be valid.

   The XPath expression is conceptually evaluated in the following
   context, in addition to the definition in S=
ection 6.4.1:

   o  The context node is the node in the data tree for which the "must"
      statement is defined.

   o  The accessible tree is made up of all nodes in the data tree, and
      all leafs with default values in use (see Section 7.6.1).




Bjorklund                    Standards Track        =
           [Page 53]

 
RFC 6020                  =
        YANG                      October 2010


   The accessible tree depends on the context node:

   o  If the context node represents configuration, the tree is the data
      in the NETCONF datastore where the context node exists.  The XPath
      root node has all top-level configuration data nodes in all
      modules as children.

   o  If the context node represents state data, the tree is all state
      data on the device, and the <running/> datastore.  The XPath =
root
      node has all top-level data nodes in all modules as children.

   o  If the context node represents notification content, the tree is
      the notification XML instance document.  The XPath root node has
      the element representing the notification being defined as the
      only child.

   o  If the context node represents RPC input parameters, the tree is
      the RPC XML instance document.  The XPath root node has the
      element representing the RPC operation being defined as the only
      child.

   o  If the context node represents RPC output parameters, the tree is
      the RPC reply instance document.  The XPath root node has the
      elements representing the RPC output parameters as children.

   The result of the XPath expression is converted to a boolean value
   using the standard XPath rules.

   Note that since all leaf values in the data tree are conceptually
   stored in their canonical form (see Sections =
7.6 and 7.7), any XPath
   comparisons are done on the canonical value.

   Also note that the XPath expression is conceptually evaluated.  This
   means that an implementation does not have to use an XPath evaluator
   on the device.  How the evaluation is done in practice is an
   implementation decision.















Bjorklund                    Standards Track        =
           [Page 54]

 
RFC 6020                  =
        YANG                      October 2010


7.5.4.  The must's Substatements

                 +---------------+---------+-------------+
                 | substatement  | section | cardinality |
                 +---------------+---------+-------------+
                 | description   | 7.19.3  | 0..1        |
                 | error-app-tag | 7.5.4.2 | 0..1        |
                 | error-message | 7.5.4.1 | 0..1        |
                 | reference     | 7.19.4  | 0..1        |
                 +---------------+---------+-------------+

7.5.4.1.  The error-message Statement

   The "error-message" statement, which is optional, takes a string as
   an argument.  If the constraint evaluates to false, the string is
   passed as <error-message> in the <rpc-error>.

7.5.4.2.  The error-app-tag Statement

   The "error-app-tag" statement, which is optional, takes a string as
   an argument.  If the constraint evaluates to false, the string is
   passed as <error-app-tag> in the <rpc-error>.

7.5.4.3.  Usage Example of must and error-message<=
/span>

     container interface {
         leaf ifType {
             type enumeration {
                 enum ethernet;
                 enum atm;
             }
         }
         leaf ifMTU {
             type uint32;
         }
         must "ifType !=3D 'ethernet' or " +
              "(ifType =3D 'ethernet' and ifMTU =3D 1500)" {
             error-message "An ethernet MTU must be 1500";
         }
         must "ifType !=3D 'atm' or " +
              "(ifType =3D 'atm' and ifMTU <=3D 17966 and ifMTU >=3D=
 64)" {
             error-message "An atm MTU must be  64 .. 17966";
         }
     }







Bjorklund                    Standards Track        =
           [Page 55]

 
RFC 6020                  =
        YANG                      October 2010


7.5.5.  The presence Statement

   The "presence" statement assigns a meaning to the presence of a
   container in the data tree.  It takes as an argument a string that
   contains a textual description of what the node's presence means.

   If a container has the "presence" statement, the container's
   existence in the data tree carries some meaning.  Otherwise, the
   container is used to give some structure to the data, and it carries
   no meaning by itself.

   See Section 7.5.1 for additional inform=
ation.

7.5.6.  The container's Child Node Statements

   Within a container, the "container", "leaf", "list", "leaf-list",
   "uses", "choice", and "anyxml" statements can be used to define child
   nodes to the container.

7.5.7.  XML Mapping Rules

   A container node is encoded as an XML element.  The element's local
   name is the container's identifier, and its namespace is the module's
   XML namespace (see Section 7.1.3).

   The container's child nodes are encoded as subelements to the
   container element.  If the container defines RPC input or output
   parameters, these subelements are encoded in the same order as they
   are defined within the "container" statement.  Otherwise, the
   subelements are encoded in any order.

   A NETCONF server that replies to a <get> or <get-config> r=
equest MAY
   choose not to send a container element if the container node does not
   have the "presence" statement and no child nodes exist.  Thus, a
   client that receives an <rpc-reply> for a <get> or <get=
-config>
   request, must be prepared to handle the case that a container node
   without a "presence" statement is not present in the XML.

7.5.8.  NETCONF <edit-config> Operations

   Containers can be created, deleted, replaced, and modified through
   <edit-config>, by using the "operation" attribute (see [RFC4741],
   Section 7.2) in the container's XML element.

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





Bjorklund                    Standards Track        =
           [Page 56]

 
RFC 6020                  =
        YANG                      October 2010


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

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

      If the operation is "create", the node is created if it does not
      exist.  If the node already exists, a "data-exists" error is
      returned.

      If the operation is "delete", the node is deleted if it exists.
      If the node does not exist, a "data-missing" error is returned.

7.5.9.  Usage Example

   Given the following container definition:

     container system {
         description "Contains various system parameters";
         container services {
             description "Configure externally available services";
             container "ssh" {
                 presence "Enables SSH";
                 description "SSH service specific configuration";
                 // more leafs, containers and stuff here...
             }
         }
     }

   A corresponding XML instance example:

     <system>
       <services>
         <ssh/>
       </services>
     </system>

   Since the <ssh> element is present, ssh is enabled.

   To delete a container with an <edit-config>:











Bjorklund                    Standards Track        =
           [Page 57]

 
RFC 6020                  =
        YANG                      October 2010


     <rpc message-id=3D"101"
          xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"
          xmlns:nc=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
       <edit-config>
         <target>
           <running/>
         </target>
         <config>
           <system xmlns=3D"http://example.com/schema/config">
             <services>
               <ssh nc:operation=3D"delete"/>
             </services>
           </system>
         </config>
       </edit-config>
     </rpc>

7.6.  The leaf Statement

   The "leaf" statement is used to define a leaf node in the schema
   tree.  It takes one argument, which is an identifier, followed by a
   block of substatements that holds detailed leaf information.

   A leaf node has a value, but no child nodes in the data tree.
   Conceptually, the value in the data tree is always in the canonical
   form (see Section 9.1).

   A leaf node exists in zero or one instances in the data tree.

   The "leaf" statement is used to define a scalar variable of a
   particular built-in or derived type.

7.6.1.  The leaf's default value

   The default value of a leaf is the value that the server uses if the
   leaf does not exist in the data tree.  The usage of the default value
   depends on the leaf's closest ancestor node in the schema tree that
   is not a non-presence container:

   o  If no such ancestor exists in the schema tree, the default value
      MUST be used.

   o  Otherwise, if this ancestor is a case node, the default value MUST
      be used if any node from the case exists in the data tree, or if
      the case node is the choice's default case, and no nodes from any
      other case exist in the data tree.





Bjorklund                    Standards Track        =
           [Page 58]

 
RFC 6020                  =
        YANG                      October 2010


   o  Otherwise, the default value MUST be used if the ancestor node
      exists in the data tree.

   In these cases, the default value is said to be in use.

   When the default value is in use, the server MUST operationally
   behave as if the leaf was present in the data tree with the default
   value as its value.

   If a leaf has a "default" statement, the leaf's default value is the
   value of the "default" statement.  Otherwise, if the leaf's type has
   a default value, and the leaf is not mandatory, then the leaf's
   default value is the type's default value.  In all other cases, the
   leaf does not have a default value.

7.6.2.  The leaf's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | config       | 7.19.1  | 0..1        |
                 | default      | 7.6.4   | 0..1        |
                 | description  | 7.19.3  | 0..1        |
                 | if-feature   | 7.18.2  | 0..n        |
                 | mandatory    | 7.6.5   | 0..1        |
                 | must         | 7.5.3   | 0..n        |
                 | reference    | 7.19.4  | 0..1        |
                 | status       | 7.19.2  | 0..1        |
                 | type         | 7.6.3   | 1           |
                 | units        | 7.3.3   | 0..1        |
                 | when         | 7.19.5  | 0..1        |
                 +--------------+---------+-------------+

7.6.3.  The leaf's type Statement

   The "type" statement, which MUST be present, takes as an argument the
   name of an existing built-in or derived type.  The optional
   substatements specify restrictions on this type.  See Section 7.4 for
   details.

7.6.4.  The leaf's default Statement

   The "default" statement, which is optional, takes as an argument a
   string that contains a default value for the leaf.

   The value of the "default" statement MUST be valid according to the
   type specified in the leaf's "type" statement.




Bjorklund                    Standards Track        =
           [Page 59]

 
RFC 6020                  =
        YANG                      October 2010


   The "default" statement MUST NOT be present on nodes where
   "mandatory" is true.

7.6.5.  The leaf's mandatory Statement

   The "mandatory" statement, which is optional, takes as an argument
   the string "true" or "false", and puts a constraint on valid data.
   If not specified, the default is "false".

   If "mandatory" is "true", the behavior of the constraint depends on
   the type of the leaf's closest ancestor node in the schema tree that
   is not a non-presence container (see Sectio=
n 7.5.1):

   o  If no such ancestor exists in the schema tree, the leaf MUST
      exist.

   o  Otherwise, if this ancestor is a case node, the leaf MUST exist if
      any node from the case exists in the data tree.

   o  Otherwise, the leaf MUST exist if the ancestor node exists in the
      data tree.

   This constraint is enforced according to the rules in Section 8.

7.6.6.  XML Mapping Rules

   A leaf node is encoded as an XML element.  The element's local name
   is the leaf's identifier, and its namespace is the module's XML
   namespace (see Section 7.1.3).

   The value of the leaf node is encoded to XML according to the type,
   and sent as character data in the element.

   A NETCONF server that replies to a <get> or <get-config> r=
equest MAY
   choose not to send the leaf element if its value is the default
   value.  Thus, a client that receives an <rpc-reply> for a <ge=
t> or
   <get-config> request, MUST be prepared to handle the case that a=
 leaf
   node with a default value is not present in the XML.  In this case,
   the value used by the server is known to be the default value.

   See Section 7.6.8 for an example.

7.6.7.  NETCONF <edit-config> Operations

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





Bjorklund                    Standards Track        =
           [Page 60]

 
RFC 6020                  =
        YANG                      October 2010


      If the operation is "merge" or "replace", the node is created if
      it does not exist, and its value is set to the value found in the
      XML RPC data.

      If the operation is "create", the node is created if it does not
      exist.  If the node already exists, a "data-exists" error is
      returned.

      If the operation is "delete", the node is deleted if it exists.
      If the node does not exist, a "data-missing" error is returned.

7.6.8.  Usage Example

   Given the following "leaf" statement, placed in the previously
   defined "ssh" container (see Section 7.5.9<=
/a>):

     leaf port {
         type inet:port-number;
         default 22;
         description "The port to which the SSH server listens"
     }

   A corresponding XML instance example:

     <port>2022</port>

   To set the value of a leaf with an <edit-config>:

     <rpc message-id=3D"101"
          xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"
          xmlns:nc=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
       <edit-config>
         <target>
           <running/>
         </target>
         <config>
           <system xmlns=3D"http://example.com/schema/config">
             <services>
               <ssh>
                 <port>2022</port>
               </ssh>
             </services>
           </system>
         </config>
       </edit-config>
     </rpc>





Bjorklund                    Standards Track        =
           [Page 61]

 
RFC 6020                  =
        YANG                      October 2010


7.7.  The leaf-list Statement

   Where the "leaf" statement is used to define a simple scalar variable
   of a particular type, the "leaf-list" statement is used to define an
   array of a particular type.  The "leaf-list" statement takes one
   argument, which is an identifier, followed by a block of
   substatements that holds detailed leaf-list information.

   The values in a leaf-list MUST be unique.

   Conceptually, the values in the data tree are always in the canonical
   form (see Section 9.1).

   If the type referenced by the leaf-list has a default value, it has
   no effect in the leaf-list.

7.7.1.  Ordering

   YANG supports two styles for ordering the entries within lists and
   leaf-lists.  In many lists, the order of list entries does not impact
   the implementation of the list's configuration, and the device is
   free to sort the list entries in any reasonable order.  The
   "description" string for the list may suggest an order to the device
   implementor.  YANG calls this style of list "system ordered" and they
   are indicated with the statement "ordered-by system".

   For example, a list of valid users would typically be sorted
   alphabetically, since the order in which the users appeared in the
   configuration would not impact the creation of those users' accounts.

   In the other style of lists, the order of list entries matters for
   the implementation of the list's configuration and the user is
   responsible for ordering the entries, while the device maintains that
   order.  YANG calls this style of list "user ordered" and they are
   indicated with the statement "ordered-by user".

   For example, the order in which firewall filters entries are applied
   to incoming traffic may affect how that traffic is filtered.  The
   user would need to decide if the filter entry that discards all TCP
   traffic should be applied before or after the filter entry that
   allows all traffic from trusted interfaces.  The choice of order
   would be crucial.

   YANG provides a rich set of facilities within NETCONF's <edit-confi=
g>
   operation that allows the order of list entries in user-ordered lists
   to be controlled.  List entries may be inserted or rearranged,
   positioned as the first or last entry in the list, or positioned
   before or after another specific entry.



Bjorklund                    Standards Track        =
           [Page 62]

 
RFC 6020                  =
        YANG                      October 2010


   The "ordered-by" statement is covered in Se=
ction 7.7.5.

7.7.2.  The leaf-list's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | config       | 7.19.1  | 0..1        |
                 | description  | 7.19.3  | 0..1        |
                 | if-feature   | 7.18.2  | 0..n        |
                 | max-elements | 7.7.4   | 0..1        |
                 | min-elements | 7.7.3   | 0..1        |
                 | must         | 7.5.3   | 0..n        |
                 | ordered-by   | 7.7.5   | 0..1        |
                 | reference    | 7.19.4  | 0..1        |
                 | status       | 7.19.2  | 0..1        |
                 | type         | 7.4     | 1           |
                 | units        | 7.3.3   | 0..1        |
                 | when         | 7.19.5  | 0..1        |
                 +--------------+---------+-------------+

7.7.3.  The min-elements Statement

   The "min-elements" statement, which is optional, takes as an argument
   a non-negative integer that puts a constraint on valid list entries.
   A valid leaf-list or list MUST have at least min-elements entries.

   If no "min-elements" statement is present, it defaults to zero.

   The behavior of the constraint depends on the type of the leaf-list's
   or list's closest ancestor node in the schema tree that is not a non-
   presence container (see Section 7.5.1):=


   o  If this ancestor is a case node, the constraint is enforced if any
      other node from the case exists.

   o  Otherwise, it is enforced if the ancestor node exists.

   The constraint is further enforced according to the rules in
   Section 8.

7.7.4.  The max-elements Statement

   The "max-elements" statement, which is optional, takes as an argument
   a positive integer or the string "unbounded", which puts a constraint
   on valid list entries.  A valid leaf-list or list always has at most
   max-elements entries.




Bjorklund                    Standards Track        =
           [Page 63]

 
RFC 6020                  =
        YANG                      October 2010


   If no "max-elements" statement is present, it defaults to
   "unbounded".

   The "max-elements" constraint is enforced according to the rules in
   Section 8.

7.7.5.  The ordered-by Statement

   The "ordered-by" statement defines whether the order of entries
   within a list are determined by the user or the system.  The argument
   is one of the strings "system" or "user".  If not present, order
   defaults to "system".

   This statement is ignored if the list represents state data, RPC
   output parameters, or notification content.

   See Section 7.7.1 for additional inform=
ation.

7.7.5.1.  ordered-by system

   The entries in the list are sorted according to an unspecified order.
   Thus, an implementation is free to sort the entries in the most
   appropriate order.  An implementation SHOULD use the same order for
   the same data, regardless of how the data were created.  Using a
   deterministic order will make comparisons possible using simple tools
   like "diff".

   This is the default order.

7.7.5.2.  ordered-by user

   The entries in the list are sorted according to an order defined by
   the user.  This order is controlled by using special XML attributes
   in the <edit-config> request.  See Se=
ction 7.7.7 for details.

7.7.6.  XML Mapping Rules

   A leaf-list node is encoded as a series of XML elements.  Each
   element's local name is the leaf-list's identifier, and its namespace
   is the module's XML namespace (see Section =
7.1.3).

   The value of each leaf-list entry is encoded to XML according to the
   type, and sent as character data in the element.

   The XML elements representing leaf-list entries MUST appear in the
   order specified by the user if the leaf-list is "ordered-by user";
   otherwise, the order is implementation-dependent.  The XML elements




Bjorklund                    Standards Track        =
           [Page 64]

 
RFC 6020                  =
        YANG                      October 2010


   representing leaf-list entries MAY be interleaved with other sibling
   elements, unless the leaf-list defines RPC input or output
   parameters.

   See Section 7.7.8 for an example.

7.7.7.  NETCONF <edit-config> Operations

   Leaf-list entries can be created and deleted, but not modified,
   through <edit-config>, by using the "operation" attribute in the=

   leaf-list entry's XML element.

   In an "ordered-by user" leaf-list, the attributes "insert" and
   "value" in the YANG XML namespace (Section =
5.3.1) can be used to
   control where in the leaf-list the entry is inserted.  These can be
   used during "create" operations to insert a new leaf-list entry, or
   during "merge" or "replace" operations to insert a new leaf-list
   entry or move an existing one.

   The "insert" attribute can take the values "first", "last", "before",
   and "after".  If the value is "before" or "after", the "value"
   attribute MUST also be used to specify an existing entry in the leaf-
   list.

   If no "insert" attribute is present in the "create" operation, it
   defaults to "last".

   If several entries in an "ordered-by user" leaf-list are modified in
   the same <edit-config> request, the entries are modified one at =
the
   time, in the order of the XML elements in the request.

   In a <copy-config>, or an <edit-config> with a "replace" o=
peration
   that covers the entire leaf-list, the leaf-list order is the same as
   the order of the XML elements in the request.

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

      If the operation is "merge" or "replace", the leaf-list entry is
      created if it does not exist.

      If the operation is "create", the leaf-list entry is created if it
      does not exist.  If the leaf-list entry already exists, a
      "data-exists" error is returned.

      If the operation is "delete", the entry is deleted from the leaf-
      list if it exists.  If the leaf-list entry does not exist, a
      "data-missing" error is returned.



Bjorklund                    Standards Track        =
           [Page 65]

 
RFC 6020                  =
        YANG                      October 2010


7.7.8.  Usage Example

     leaf-list allow-user  {
         type string;
         description "A list of user name patterns to allow";
     }

   A corresponding XML instance example:

     <allow-user>alice</allow-user>
     <allow-user>bob</allow-user>

   To create a new element in this list, using the default <edit-confi=
g>
   operation "merge":

     <rpc message-id=3D"101"
          xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"
          xmlns:nc=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
       <edit-config>
         <target>
           <running/>
         </target>
         <config>
           <system xmlns=3D"http://example.com/schema/config">
             <services>
               <ssh>
                 <allow-user>eric</allow-user>
               </ssh>
             </services>
           </system>
         </config>
       </edit-config>
     </rpc>

   Given the following ordered-by user leaf-list:

     leaf-list cipher  {
         type string;
         ordered-by user;
         description "A list of ciphers";
     }

   The following would be used to insert a new cipher "blowfish-cbc"
   after "3des-cbc":







Bjorklund                    Standards Track        =
           [Page 66]

 
RFC 6020                  =
        YANG                      October 2010


     <rpc message-id=3D"101"
          xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"
          xmlns:nc=3D"urn:ietf:params:xml:ns:netconf:base:1.0"
          xmlns:yang=3D"urn:ietf:params:xml:ns:yang:1">
       <edit-config>
         <target>
           <running/>
         </target>
         <config>
           <system xmlns=3D"http://example.com/schema/config">
             <services>
               <ssh>
                 <cipher nc:operation=3D"create"
                         yang:insert=3D"after"
                         yang:value=3D"3des-cbc">blowfish-cbc</ciph=
er>
               </ssh>
             </services>
           </system>
         </config>
       </edit-config>
     </rpc>

7.8.  The list Statement

   The "list" statement is used to define an interior data node in the
   schema tree.  A list node may exist in multiple instances in the data
   tree.  Each such instance is known as a list entry.  The "list"
   statement takes one argument, which is an identifier, followed by a
   block of substatements that holds detailed list information.

   A list entry is uniquely identified by the values of the list's keys,
   if defined.



















Bjorklund                    Standards Track        =
           [Page 67]

 
RFC 6020                  =
        YANG                      October 2010


7.8.1.  The list's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | anyxml       | 7.10    | 0..n        |
                 | choice       | 7.9     | 0..n        |
                 | config       | 7.19.1  | 0..1        |
                 | container    | 7.5     | 0..n        |
                 | description  | 7.19.3  | 0..1        |
                 | grouping     | 7.11    | 0..n        |
                 | if-feature   | 7.18.2  | 0..n        |
                 | key          | 7.8.2   | 0..1        |
                 | leaf         | 7.6     | 0..n        |
                 | leaf-list    | 7.7     | 0..n        |
                 | list         | 7.8     | 0..n        |
                 | max-elements | 7.7.4   | 0..1        |
                 | min-elements | 7.7.3   | 0..1        |
                 | must         | 7.5.3   | 0..n        |
                 | ordered-by   | 7.7.5   | 0..1        |
                 | reference    | 7.19.4  | 0..1        |
                 | status       | 7.19.2  | 0..1        |
                 | typedef      | 7.3     | 0..n        |
                 | unique       | 7.8.3   | 0..n        |
                 | uses         | 7.12    | 0..n        |
                 | when         | 7.19.5  | 0..1        |
                 +--------------+---------+-------------+

7.8.2.  The list's key Statement

   The "key" statement, which MUST be present if the list represents
   configuration, and MAY be present otherwise, takes as an argument a
   string that specifies a space-separated list of leaf identifiers of
   this list.  A leaf identifier MUST NOT appear more than once in the
   key.  Each such leaf identifier MUST refer to a child leaf of the
   list.  The leafs can be defined directly in substatements to the
   list, or in groupings used in the list.

   The combined values of all the leafs specified in the key are used to
   uniquely identify a list entry.  All key leafs MUST be given values
   when a list entry is created.  Thus, any default values in the key
   leafs or their types are ignored.  It also implies that any mandatory
   statement in the key leafs are ignored.

   A leaf that is part of the key can be of any built-in or derived
   type, except it MUST NOT be the built-in type "empty".





Bjorklund                    Standards Track        =
           [Page 68]

 
RFC 6020                  =
        YANG                      October 2010


   All key leafs in a list MUST have the same value for their "config"
   as the list itself.

   The key string syntax is formally defined by the rule "key-arg" in
   Section 12.

7.8.3.  The list's unique Statement

   The "unique" statement is used to put constraints on valid list
   entries.  It takes as an argument a string that contains a space-
   separated list of schema node identifiers, which MUST be given in the
   descendant form (see the rule "descendant-schema-nodeid" in
   Section 12).  Each such schema node identi=
fier MUST refer to a leaf.

   If one of the referenced leafs represents configuration data, then
   all of the referenced leafs MUST represent configuration data.

   The "unique" constraint specifies that the combined values of all the
   leaf instances specified in the argument string, including leafs with
   default values, MUST be unique within all list entry instances in
   which all referenced leafs exist.  The constraint is enforced
   according to the rules in Section 8.

   The unique string syntax is formally defined by the rule "unique-arg"
   in Section 12.

7.8.3.1.  Usage Example

   With the following list:

     list server {
         key "name";
         unique "ip port";
         leaf name {
             type string;
         }
         leaf ip {
             type inet:ip-address;
         }
         leaf port {
             type inet:port-number;
         }
     }








Bjorklund                    Standards Track        =
           [Page 69]

 
RFC 6020                  =
        YANG                      October 2010


   The following configuration is not valid:

     <server>
       <name>smtp</name>
       <ip>192.0.2.1</ip>
       <port>25</port>
     </server>

     <server>
       <name>http</name>
       <ip>192.0.2.1</ip>
       <port>25</port>
     </server>

   The following configuration is valid, since the "http" and "ftp" list
   entries do not have a value for all referenced leafs, and are thus
   not taken into account when the "unique" constraint is enforced:

     <server>
       <name>smtp</name>
       <ip>192.0.2.1</ip>
       <port>25</port>
     </server>

     <server>
       <name>http</name>
       <ip>192.0.2.1</ip>
     </server>

     <server>
       <name>ftp</name>
       <ip>192.0.2.1</ip>
     </server>

7.8.4.  The list's Child Node Statements

   Within a list, the "container", "leaf", "list", "leaf-list", "uses",
   "choice", and "anyxml" statements can be used to define child nodes
   to the list.

7.8.5.  XML Mapping Rules

   A list is encoded as a series of XML elements, one for each entry in
   the list.  Each element's local name is the list's identifier, and
   its namespace is the module's XML namespace (see Section 7.1.3).






Bjorklund                    Standards Track        =
           [Page 70]

 
RFC 6020                  =
        YANG                      October 2010


   The list's key nodes are encoded as subelements to the list's
   identifier element, in the same order as they are defined within the
   "key" statement.

   The rest of the list's child nodes are encoded as subelements to the
   list element, after the keys.  If the list defines RPC input or
   output parameters, the subelements are encoded in the same order as
   they are defined within the "list" statement.  Otherwise, the
   subelements are encoded in any order.

   The XML elements representing list entries MUST appear in the order
   specified by the user if the list is "ordered-by user", otherwise the
   order is implementation-dependent.  The XML elements representing
   list entries MAY be interleaved with other sibling elements, unless
   the list defines RPC input or output parameters.

7.8.6.  NETCONF <edit-config> Operations

   List entries can be created, deleted, replaced, and modified through
   <edit-config>, by using the "operation" attribute in the list's =
XML
   element.  In each case, the values of all keys are used to uniquely
   identify a list entry.  If all keys are not specified for a list
   entry, a "missing-element" error is returned.

   In an "ordered-by user" list, the attributes "insert" and "key" in
   the YANG XML namespace (Section 5.3.1) =
can be used to control where
   in the list the entry is inserted.  These can be used during "create"
   operations to insert a new list entry, or during "merge" or "replace"
   operations to insert a new list entry or move an existing one.

   The "insert" attribute can take the values "first", "last", "before",
   and "after".  If the value is "before" or "after", the "key"
   attribute MUST also be used, to specify an existing element in the
   list.  The value of the "key" attribute is the key predicates of the
   full instance identifier (see Section 9.13) for the list entry.

   If no "insert" attribute is present in the "create" operation, it
   defaults to "last".

   If several entries in an "ordered-by user" list are modified in the
   same <edit-config> request, the entries are modified one at the =
time,
   in the order of the XML elements in the request.

   In a <copy-config>, or an <edit-config> with a "replace" o=
peration
   that covers the entire list, the list entry order is the same as the
   order of the XML elements in the request.





Bjorklund                    Standards Track        =
           [Page 71]

 
RFC 6020                  =
        YANG                      October 2010


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

      If the operation is "merge" or "replace", the list entry is
      created if it does not exist.  If the list entry already exists
      and the "insert" and "key" attributes are present, the list entry
      is moved according to the values of the "insert" and "key"
      attributes.  If the list entry exists and the "insert" and "key"
      attributes are not present, the list entry is not moved.

      If the operation is "create", the list entry is created if it does
      not exist.  If the list entry already exists, a "data-exists"
      error is returned.

      If the operation is "delete", the entry is deleted from the list
      if it exists.  If the list entry does not exist, a "data-missing"
      error is returned.

7.8.7.  Usage Example

   Given the following list:

     list user {
         key "name";
         config true;
         description "This is a list of users in the system.";

         leaf name {
             type string;
         }
         leaf type {
             type string;
         }
         leaf full-name {
             type string;
         }
     }

   A corresponding XML instance example:

     <user>
       <name>fred</name>
       <type>admin</type>
       <full-name>Fred Flintstone</full-name>
     </user>






Bjorklund                    Standards Track        =
           [Page 72]

 
RFC 6020                  =
        YANG                      October 2010


   To create a new user "barney":

     <rpc message-id=3D"101"
          xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"
          xmlns:nc=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
       <edit-config>
         <target>
           <running/>
         </target>
         <config>
           <system xmlns=3D"http://example.com/schema/config">
             <user nc:operation=3D"create">
               <name>barney</name>
               <type>admin</type>
               <full-name>Barney Rubble</full-name>
             </user>
           </system>
         </config>
       </edit-config>
     </rpc>

   To change the type of "fred" to "superuser":

     <rpc message-id=3D"101"
          xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"
          xmlns:nc=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
       <edit-config>
         <target>
           <running/>
         </target>
         <config>
           <system xmlns=3D"http://example.com/schema/config">
             <user>
               <name>fred</name>
               <type>superuser</type>
             </user>
           </system>
         </config>
       </edit-config>
     </rpc>











Bjorklund                    Standards Track        =
           [Page 73]

 
RFC 6020                  =
        YANG                      October 2010


   Given the following ordered-by user list:

     list user {
         description "This is a list of users in the system.";
         ordered-by user;
         config true;

         key "name";

         leaf name {
             type string;
         }
         leaf type {
             type string;
         }
         leaf full-name {
             type string;
         }
     }

   The following would be used to insert a new user "barney" after the
   user "fred":

     <rpc message-id=3D"101"
          xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"
          xmlns:nc=3D"urn:ietf:params:xml:ns:netconf:base:1.0"
          xmlns:yang=3D"urn:ietf:params:xml:ns:yang:1">
       <edit-config>
         <target>
           <running/>
         </target>
         <config>
           <system xmlns=3D"http://example.com/schema/config"
                xmlns:ex=3D"http://example.com/schema/config">
             <user nc:operation=3D"create"
                   yang:insert=3D"after"
                   yang:key=3D"[ex:name=3D'fred']">
               <name>barney</name>
               <type>admin</type>
               <full-name>Barney Rubble</full-name>
             </user>
           </system>
         </config>
       </edit-config>
     </rpc>






Bjorklund                    Standards Track        =
           [Page 74]

 
RFC 6020                  =
        YANG                      October 2010


   The following would be used to move the user "barney" before the user
   "fred":

     <rpc message-id=3D"101"
          xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"
          xmlns:nc=3D"urn:ietf:params:xml:ns:netconf:base:1.0"
          xmlns:yang=3D"urn:ietf:params:xml:ns:yang:1">
       <edit-config>
         <target>
           <running/>
         </target>
         <config>
           <system xmlns=3D"http://example.com/schema/config"
                xmlns:ex=3D"http://example.com/schema/config">
             <user nc:operation=3D"merge"
                   yang:insert=3D"before"
                   yang:key=3D"[ex:name=3D'fred']">
               <name>barney</name>
             </user>
           </system>
         </config>
       </edit-config>
     </rpc>

7.9.  The choice Statement

   The "choice" statement defines a set of alternatives, only one of
   which may exist at any one time.  The argument is an identifier,
   followed by a block of substatements that holds detailed choice
   information.  The identifier is used to identify the choice node in
   the schema tree.  A choice node does not exist in the data tree.

   A choice consists of a number of branches, defined with the "case"
   substatement.  Each branch contains a number of child nodes.  The
   nodes from at most one of the choice's branches exist at the same
   time.

   See Section 8.3.2 for additional inform=
ation.













Bjorklund                    Standards Track        =
           [Page 75]

 
RFC 6020                  =
        YANG                      October 2010


7.9.1.  The choice's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | anyxml       | 7.10    | 0..n        |
                 | case         | 7.9.2   | 0..n        |
                 | config       | 7.19.1  | 0..1        |
                 | container    | 7.5     | 0..n        |
                 | default      | 7.9.3   | 0..1        |
                 | description  | 7.19.3  | 0..1        |
                 | if-feature   | 7.18.2  | 0..n        |
                 | leaf         | 7.6     | 0..n        |
                 | leaf-list    | 7.7     | 0..n        |
                 | list         | 7.8     | 0..n        |
                 | mandatory    | 7.9.4   | 0..1        |
                 | reference    | 7.19.4  | 0..1        |
                 | status       | 7.19.2  | 0..1        |
                 | when         | 7.19.5  | 0..1        |
                 +--------------+---------+-------------+

7.9.2.  The choice's case Statement

   The "case" statement is used to define branches of the choice.  It
   takes as an argument an identifier, followed by a block of
   substatements that holds detailed case information.

   The identifier is used to identify the case node in the schema tree.
   A case node does not exist in the data tree.

   Within a "case" statement, the "anyxml", "choice", "container",
   "leaf", "list", "leaf-list", and "uses" statements can be used to
   define child nodes to the case node.  The identifiers of all these
   child nodes MUST be unique within all cases in a choice.  For
   example, the following is illegal:

     choice interface-type {     // This example is illegal YANG
         case a {
             leaf ethernet { ... }
         }
         case b {
             container ethernet { ...}
         }
     }







Bjorklund                    Standards Track        =
           [Page 76]

 
RFC 6020                  =
        YANG                      October 2010


   As a shorthand, the "case" statement can be omitted if the branch
   contains a single "anyxml", "container", "leaf", "list", or
   "leaf-list" statement.  In this case, the identifier of the case node
   is the same as the identifier in the branch statement.  The following
   example:

     choice interface-type {
         container ethernet { ... }
     }

   is equivalent to:

     choice interface-type {
         case ethernet {
             container ethernet { ... }
         }
     }

   The case identifier MUST be unique within a choice.

7.9.2.1.  The case's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | anyxml       | 7.10    | 0..n        |
                 | choice       | 7.9     | 0..n        |
                 | container    | 7.5     | 0..n        |
                 | description  | 7.19.3  | 0..1        |
                 | if-feature   | 7.18.2  | 0..n        |
                 | leaf         | 7.6     | 0..n        |
                 | leaf-list    | 7.7     | 0..n        |
                 | list         | 7.8     | 0..n        |
                 | reference    | 7.19.4  | 0..1        |
                 | status       | 7.19.2  | 0..1        |
                 | uses         | 7.12    | 0..n        |
                 | when         | 7.19.5  | 0..1        |
                 +--------------+---------+-------------+

7.9.3.  The choice's default Statement

   The "default" statement indicates if a case should be considered as
   the default if no child nodes from any of the choice's cases exist.
   The argument is the identifier of the "case" statement.  If the
   "default" statement is missing, there is no default case.

   The "default" statement MUST NOT be present on choices where
   "mandatory" is true.



Bjorklund                    Standards Track        =
           [Page 77]

 
RFC 6020                  =
        YANG                      October 2010


   The default case is only important when considering the default
   values of nodes under the cases.  The default values for nodes under
   the default case are used if none of the nodes under any of the cases
   are present.

   There MUST NOT be any mandatory nodes (Sectio=
n 3.1) directly under
   the default case.

   Default values for child nodes under a case are only used if one of
   the nodes under that case is present, or if that case is the default
   case.  If none of the nodes under a case are present and the case is
   not the default case, the default values of the cases' child nodes
   are ignored.

   In this example, the choice defaults to "interval", and the default
   value will be used if none of "daily", "time-of-day", or "manual" are
   present.  If "daily" is present, the default value for "time-of-day"
   will be used.

     container transfer {
         choice how {
             default interval;
             case interval {
                 leaf interval {
                     type uint16;
                     default 30;
                     units minutes;
                 }
             }
             case daily {
                 leaf daily {
                     type empty;
                 }
                 leaf time-of-day {
                     type string;
                     units 24-hour-clock;
                     default 1am;
                 }
             }
             case manual {
                 leaf manual {
                     type empty;
                 }
             }
         }
     }





Bjorklund                    Standards Track        =
           [Page 78]

 
RFC 6020                  =
        YANG                      October 2010


7.9.4.  The choice's mandatory Statement

   The "mandatory" statement, which is optional, takes as an argument
   the string "true" or "false", and puts a constraint on valid data.
   If "mandatory" is "true", at least one node from exactly one of the
   choice's case branches MUST exist.

   If not specified, the default is "false".

   The behavior of the constraint depends on the type of the choice's
   closest ancestor node in the schema tree which is not a non-presence
   container (see Section 7.5.1):

   o  If this ancestor is a case node, the constraint is enforced if any
      other node from the case exists.

   o  Otherwise, it is enforced if the ancestor node exists.

   The constraint is further enforced according to the rules in
   Section 8.

7.9.5.  XML Mapping Rules

   The choice and case nodes are not visible in XML.

   The child nodes of the selected "case" statement MUST be encoded in
   the same order as they are defined in the "case" statement if they
   are part of an RPC input or output parameter definition.  Otherwise,
   the subelements are encoded in any order.

7.9.6.  NETCONF <edit-config> Operations

   Since only one of the choice's cases can be valid at any time, the
   creation of a node from one case implicitly deletes all nodes from
   all other cases.  If an <edit-config> operation creates a node f=
rom a
   case, the NETCONF server will delete any existing nodes that are
   defined in other cases inside the choice.

7.9.7.  Usage Example

   Given the following choice:










Bjorklund                    Standards Track        =
           [Page 79]

 
RFC 6020                  =
        YANG                      October 2010


     container protocol {
         choice name {
             case a {
                 leaf udp {
                     type empty;
                 }
             }
             case b {
                 leaf tcp {
                    type empty;
                 }
             }
         }
     }

   A corresponding XML instance example:

     <protocol>
       <tcp/>
     </protocol>

   To change the protocol from tcp to udp:

     <rpc message-id=3D"101"
          xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"
          xmlns:nc=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
       <edit-config>
         <target>
           <running/>
         </target>
         <config>
           <system xmlns=3D"http://example.com/schema/config">
             <protocol>
               <udp nc:operation=3D"create"/>
             </protocol>
           </system>
         </config>
       </edit-config>
     </rpc>

7.10.  The anyxml Statement

   The "anyxml" statement defines an interior node in the schema tree.
   It takes one argument, which is an identifier, followed by a block of
   substatements that holds detailed anyxml information.






Bjorklund                    Standards Track        =
           [Page 80]

 
RFC 6020                  =
        YANG                      October 2010


   The "anyxml" statement is used to represent an unknown chunk of XML.
   No restrictions are placed on the XML.  This can be useful, for
   example, in RPC replies.  An example is the <filter> parameter i=
n the
   <get-config> operation.

   An anyxml node cannot be augmented (see Sect=
ion 7.15).

   Since the use of anyxml limits the manipulation of the content, it is
   RECOMMENDED that the "anyxml" statement not be used to represent
   configuration data.

   An anyxml node exists in zero or one instances in the data tree.

7.10.1.  The anyxml's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | config       | 7.19.1  | 0..1        |
                 | description  | 7.19.3  | 0..1        |
                 | if-feature   | 7.18.2  | 0..n        |
                 | mandatory    | 7.6.5   | 0..1        |
                 | must         | 7.5.3   | 0..n        |
                 | reference    | 7.19.4  | 0..1        |
                 | status       | 7.19.2  | 0..1        |
                 | when         | 7.19.5  | 0..1        |
                 +--------------+---------+-------------+

7.10.2.  XML Mapping Rules

   An anyxml node is encoded as an XML element.  The element's local
   name is the anyxml's identifier, and its namespace is the module's
   XML namespace (see Section 7.1.3).  The=
 value of the anyxml node is
   encoded as XML content of this element.

   Note that any prefixes used in the encoding are local to each
   instance encoding.  This means that the same XML may be encoded
   differently by different implementations.

7.10.3.  NETCONF <edit-config> Operations

   An anyxml node is treated as an opaque chunk of data.  This data can
   be modified in its entirety only.

   Any "operation" attributes present on subelements of an anyxml node
   are ignored by the NETCONF server.





Bjorklund                    Standards Track        =
           [Page 81]

 
RFC 6020                  =
        YANG                      October 2010


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

      If the operation is "merge" or "replace", the node is created if
      it does not exist, and its value is set to the XML content of the
      anyxml node found in the XML RPC data.

      If the operation is "create", the node is created if it does not
      exist, and its value is set to the XML content of the anyxml node
      found in the XML RPC data.  If the node already exists, a
      "data-exists" error is returned.

      If the operation is "delete", the node is deleted if it exists.
      If the node does not exist, a "data-missing" error is returned.

7.10.4.  Usage Example

   Given the following "anyxml" statement:

     anyxml data;

   The following are two valid encodings of the same anyxml value:

     <data xmlns:if=3D"http://example.com/ns/interface">
       <if:interface>
         <if:ifIndex>1</if:ifIndex>
       </if:interface>
     </data>

     <data>
       <interface xmlns=3D"http://example.com/ns/interface">
         <ifIndex>1</ifIndex>
       </interface>
     </data>

7.11.  The grouping Statement

   The "grouping" statement is used to define a reusable block of nodes,
   which may be used locally in the module, in modules that include it,
   and by other modules that import from it, according to the rules in
   Section 5.5.  It takes one argument, whic=
h is an identifier, followed
   by a block of substatements that holds detailed grouping information.

   The "grouping" statement is not a data definition statement and, as
   such, does not define any nodes in the schema tree.

   A grouping is like a "structure" or a "record" in conventional
   programming languages.



Bjorklund                    Standards Track        =
           [Page 82]

 
RFC 6020                  =
        YANG                      October 2010


   Once a grouping is defined, it can be referenced in a "uses"
   statement (see Section 7.12).  A groupin=
g MUST NOT reference itself,
   neither directly nor indirectly through a chain of other groupings.

   If the grouping is defined at the top level of a YANG module or
   submodule, the grouping's identifier MUST be unique within the
   module.

   A grouping is more than just a mechanism for textual substitution,
   but defines a collection of nodes.  Identifiers appearing inside the
   grouping are resolved relative to the scope in which the grouping is
   defined, not where it is used.  Prefix mappings, type names, grouping
   names, and extension usage are evaluated in the hierarchy where the
   "grouping" statement appears.  For extensions, this means that
   extensions are applied to the grouping node, not the uses node.

7.11.1.  The grouping's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | anyxml       | 7.10    | 0..n        |
                 | choice       | 7.9     | 0..n        |
                 | container    | 7.5     | 0..n        |
                 | description  | 7.19.3  | 0..1        |
                 | grouping     | 7.11    | 0..n        |
                 | leaf         | 7.6     | 0..n        |
                 | leaf-list    | 7.7     | 0..n        |
                 | list         | 7.8     | 0..n        |
                 | reference    | 7.19.4  | 0..1        |
                 | status       | 7.19.2  | 0..1        |
                 | typedef      | 7.3     | 0..n        |
                 | uses         | 7.12    | 0..n        |
                 +--------------+---------+-------------+

















Bjorklund                    Standards Track        =
           [Page 83]

 
RFC 6020                  =
        YANG                      October 2010


7.11.2.  Usage Example

     import ietf-inet-types {
         prefix "inet";
     }

     grouping endpoint {
         description "A reusable endpoint group.";
         leaf ip {
             type inet:ip-address;
         }
         leaf port {
             type inet:port-number;
         }
     }

7.12.  The uses Statement

   The "uses" statement is used to reference a "grouping" definition.
   It takes one argument, which is the name of the grouping.

   The effect of a "uses" reference to a grouping is that the nodes
   defined by the grouping are copied into the current schema tree, and
   then updated according to the "refine" and "augment" statements.

   The identifiers defined in the grouping are not bound to a namespace
   until the contents of the grouping are added to the schema tree via a
   "uses" statement that does not appear inside a "grouping" statement,
   at which point they are bound to the namespace of the current module.






















Bjorklund                    Standards Track        =
           [Page 84]

 
RFC 6020                  =
        YANG                      October 2010


7.12.1.  The uses's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | augment      | 7.15    | 0..1        |
                 | description  | 7.19.3  | 0..1        |
                 | if-feature   | 7.18.2  | 0..n        |
                 | refine       | 7.12.2  | 0..1        |
                 | reference    | 7.19.4  | 0..1        |
                 | status       | 7.19.2  | 0..1        |
                 | when         | 7.19.5  | 0..1        |
                 +--------------+---------+-------------+

7.12.2.  The refine Statement

   Some of the properties of each node in the grouping can be refined
   with the "refine" statement.  The argument is a string that
   identifies a node in the grouping.  This node is called the refine's
   target node.  If a node in the grouping is not present as a target
   node of a "refine" statement, it is not refined, and thus used
   exactly as it was defined in the grouping.

   The argument string is a descendant schema node identifier (see
   Section 6.5).

   The following refinements can be done:

   o  A leaf or choice node may get a default value, or a new default
      value if it already had one.

   o  Any node may get a specialized "description" string.

   o  Any node may get a specialized "reference" string.

   o  Any node may get a different "config" statement.

   o  A leaf, anyxml, or choice node may get a different "mandatory"
      statement.

   o  A container node may get a "presence" statement.

   o  A leaf, leaf-list, list, container, or anyxml node may get
      additional "must" expressions.

   o  A leaf-list or list node may get a different "min-elements" or
      "max-elements" statement.




Bjorklund                    Standards Track        =
           [Page 85]

 
RFC 6020                  =
        YANG                      October 2010


7.12.3.  XML Mapping Rules

   Each node in the grouping is encoded as if it was defined inline,
   even if it is imported from another module with another XML
   namespace.

7.12.4.  Usage Example

   To use the "endpoint" grouping defined in =
Section 7.11.2 in a
   definition of an HTTP server in some other module, we can do:

     import acme-system {
         prefix "acme";
     }

     container http-server {
         leaf name {
             type string;
         }
         uses acme:endpoint;
     }

   A corresponding XML instance example:

     <http-server>
       <name>extern-web</name>
       <ip>192.0.2.1</ip>
       <port>80</port>
     </http-server>

   If port 80 should be the default for the HTTP server, default can be
   added:

     container http-server {
         leaf name {
             type string;
         }
         uses acme:endpoint {
             refine port {
                 default 80;
             }
         }
     }

   If we want to define a list of servers, and each server has the ip
   and port as keys, we can do:





Bjorklund                    Standards Track        =
           [Page 86]

 
RFC 6020                  =
        YANG                      October 2010


     list server {
         key "ip port";
         leaf name {
             type string;
         }
         uses acme:endpoint;
     }

   The following is an error:

     container http-server {
         uses acme:endpoint;
         leaf ip {          // illegal - same identifier "ip" used twice
             type string;
         }
     }

7.13.  The rpc Statement

   The "rpc" statement is used to define a NETCONF RPC operation.  It
   takes one argument, which is an identifier, followed by a block of
   substatements that holds detailed rpc information.  This argument is
   the name of the RPC, and is used as the element name directly under
   the <rpc> element, as designated by the substitution group
   "rpcOperation" in [RFC4741].

   The "rpc" statement defines an rpc node in the schema tree.  Under
   the rpc node, a schema node with the name "input", and a schema node
   with the name "output" are also defined.  The nodes "input" and
   "output" are defined in the module's namespace.





















Bjorklund                    Standards Track        =
           [Page 87]

 
RFC 6020                  =
        YANG                      October 2010


7.13.1.  The rpc's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | description  | 7.19.3  | 0..1        |
                 | grouping     | 7.11    | 0..n        |
                 | if-feature   | 7.18.2  | 0..n        |
                 | input        | 7.13.2  | 0..1        |
                 | output       | 7.13.3  | 0..1        |
                 | reference    | 7.19.4  | 0..1        |
                 | status       | 7.19.2  | 0..1        |
                 | typedef      | 7.3     | 0..n        |
                 +--------------+---------+-------------+

7.13.2.  The input Statement

   The "input" statement, which is optional, is used to define input
   parameters to the RPC operation.  It does not take an argument.  The
   substatements to "input" define nodes under the RPC's input node.

   If a leaf in the input tree has a "mandatory" statement with the
   value "true", the leaf MUST be present in a NETCONF RPC invocation.
   Otherwise, the server MUST return a "missing-element" error.

   If a leaf in the input tree has a default value, the NETCONF server
   MUST use this value in the same cases as described in Section 7.6.1.
   In these cases, the server MUST operationally behave as if the leaf
   was present in the NETCONF RPC invocation with the default value as
   its value.

   If a "config" statement is present for any node in the input tree,
   the "config" statement is ignored.

   If any node has a "when" statement that would evaluate to false, then
   this node MUST NOT be present in the input tree.















Bjorklund                    Standards Track        =
           [Page 88]

 
RFC 6020                  =
        YANG                      October 2010


7.13.2.1.  The input's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | anyxml       | 7.10    | 0..n        |
                 | choice       | 7.9     | 0..n        |
                 | container    | 7.5     | 0..n        |
                 | grouping     | 7.11    | 0..n        |
                 | leaf         | 7.6     | 0..n        |
                 | leaf-list    | 7.7     | 0..n        |
                 | list         | 7.8     | 0..n        |
                 | typedef      | 7.3     | 0..n        |
                 | uses         | 7.12    | 0..n        |
                 +--------------+---------+-------------+

7.13.3.  The output Statement

   The "output" statement, which is optional, is used to define output
   parameters to the RPC operation.  It does not take an argument.  The
   substatements to "output" define nodes under the RPC's output node.

   If a leaf in the output tree has a "mandatory" statement with the
   value "true", the leaf MUST be present in a NETCONF RPC reply.

   If a leaf in the output tree has a default value, the NETCONF client
   MUST use this value in the same cases as described in Section 7.6.1.
   In these cases, the client MUST operationally behave as if the leaf
   was present in the NETCONF RPC reply with the default value as its
   value.

   If a "config" statement is present for any node in the output tree,
   the "config" statement is ignored.

   If any node has a "when" statement that would evaluate to false, then
   this node MUST NOT be present in the output tree.















Bjorklund                    Standards Track        =
           [Page 89]

 
RFC 6020                  =
        YANG                      October 2010


7.13.3.1.  The output's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | anyxml       | 7.10    | 0..n        |
                 | choice       | 7.9     | 0..n        |
                 | container    | 7.5     | 0..n        |
                 | grouping     | 7.11    | 0..n        |
                 | leaf         | 7.6     | 0..n        |
                 | leaf-list    | 7.7     | 0..n        |
                 | list         | 7.8     | 0..n        |
                 | typedef      | 7.3     | 0..n        |
                 | uses         | 7.12    | 0..n        |
                 +--------------+---------+-------------+

7.13.4.  XML Mapping Rules

   An rpc node is encoded as a child XML element to the <rpc> eleme=
nt
   defined in [RFC4741].  The element's local name is the rpc's
   identifier, and its namespace is the module's XML namespace (see
   Section 7.1.3).

   Input parameters are encoded as child XML elements to the rpc node's
   XML element, in the same order as they are defined within the "input"
   statement.

   If the RPC operation invocation succeeded, and no output parameters
   are returned, the <rpc-reply> contains a single <ok/> elem=
ent defined
   in [RFC4741].  If output parameters are returned, they are encod=
ed as
   child elements to the <rpc-reply> element defined in [RFC4741<=
/a>], in
   the same order as they are defined within the "output" statement.



















Bjorklund                    Standards Track        =
           [Page 90]

 
RFC 6020                  =
        YANG                      October 2010


7.13.5.  Usage Example

   The following example defines an RPC operation:

     module rock {
         namespace "http://example.net/rock";
         prefix "rock";

         rpc rock-the-house {
             input {
                 leaf zip-code {
                     type string;
                 }
             }
         }
     }

   A corresponding XML instance example of the complete rpc and rpc-
   reply:

     <rpc message-id=3D"101"
          xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
       <rock-the-house xmlns=3D"http://example.net/rock">
         <zip-code>27606-0100</zip-code>
       </rock-the-house>
     </rpc>

     <rpc-reply message-id=3D"101"
                xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/>
     </rpc-reply>

7.14.  The notification Statement

   The "notification" statement is used to define a NETCONF
   notification.  It takes one argument, which is an identifier,
   followed by a block of substatements that holds detailed notification
   information.  The "notification" statement defines a notification
   node in the schema tree.

   If a leaf in the notification tree has a "mandatory" statement with
   the value "true", the leaf MUST be present in a NETCONF notification.

   If a leaf in the notification tree has a default value, the NETCONF
   client MUST use this value in the same cases as described in
   Section 7.6.1.  In these cases, the cli=
ent MUST operationally behave
   as if the leaf was present in the NETCONF notification with the
   default value as its value.



Bjorklund                    Standards Track        =
           [Page 91]

 
RFC 6020                  =
        YANG                      October 2010


   If a "config" statement is present for any node in the notification
   tree, the "config" statement is ignored.

7.14.1.  The notification's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | anyxml       | 7.10    | 0..n        |
                 | choice       | 7.9     | 0..n        |
                 | container    | 7.5     | 0..n        |
                 | description  | 7.19.3  | 0..1        |
                 | grouping     | 7.11    | 0..n        |
                 | if-feature   | 7.18.2  | 0..n        |
                 | leaf         | 7.6     | 0..n        |
                 | leaf-list    | 7.7     | 0..n        |
                 | list         | 7.8     | 0..n        |
                 | reference    | 7.19.4  | 0..1        |
                 | status       | 7.19.2  | 0..1        |
                 | typedef      | 7.3     | 0..n        |
                 | uses         | 7.12    | 0..n        |
                 +--------------+---------+-------------+

7.14.2.  XML Mapping Rules

   A notification node is encoded as a child XML element to the
   <notification> element defined in NETCONF Event Notifications
   [RFC5277].  The element's local name is the notification's
   identifier, and its namespace is the module's XML namespace (see
   Section 7.1.3).





















Bjorklund                    Standards Track        =
           [Page 92]

 
RFC 6020                  =
        YANG                      October 2010


7.14.3.  Usage Example

   The following example defines a notification:

     module event {

         namespace "http://example.com/event";
         prefix "ev";

         notification event {
             leaf event-class {
                 type string;
             }
             anyxml reporting-entity;
             leaf severity {
                 type string;
             }
         }
     }

   A corresponding XML instance example of the complete notification:

     <notification
       xmlns=3D"urn:ietf:params:xml:ns:netconf:notification:1.0">
       <eventTime>2008-07-08T00:01:00Z</eventTime>
       <event xmlns=3D"http://example.com/event">
         <event-class>fault</event-class>
         <reporting-entity>
           <card>Ethernet0</card>
         </reporting-entity>
         <severity>major</severity>
       </event>
     </notification>

7.15.  The augment Statement

   The "augment" statement allows a module or submodule to add to the
   schema tree defined in an external module, or the current module and
   its submodules, and to add to the nodes from a grouping in a "uses"
   statement.  The argument is a string that identifies a node in the
   schema tree.  This node is called the augment's target node.  The
   target node MUST be either a container, list, choice, case, input,
   output, or notification node.  It is augmented with the nodes defined
   in the substatements that follow the "augment" statement.

   The argument string is a schema node identifier (see Section 6.5).
   If the "augment" statement is on the top level in a module or
   submodule, the absolute form (defined by the rule



Bjorklund                    Standards Track        =
           [Page 93]

 
RFC 6020                  =
        YANG                      October 2010


   "absolute-schema-nodeid" in Section 12) of=
 a schema node identifier
   MUST be used.  If the "augment" statement is a substatement to the
   "uses" statement, the descendant form (defined by the rule
   "descendant-schema-nodeid" in Section 12) =
MUST be used.

   If the target node is a container, list, case, input, output, or
   notification node, the "container", "leaf", "list", "leaf-list",
   "uses", and "choice" statements can be used within the "augment"
   statement.

   If the target node is a choice node, the "case" statement, or a case
   shorthand statement (see Section 7.9.2)=
 can be used within the
   "augment" statement.

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

   The "augment" statement MUST NOT add multiple nodes with the same
   name from the same module to the target node.

7.15.1.  The augment's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | anyxml       | 7.10    | 0..n        |
                 | case         | 7.9.2   | 0..n        |
                 | choice       | 7.9     | 0..n        |
                 | container    | 7.5     | 0..n        |
                 | description  | 7.19.3  | 0..1        |
                 | if-feature   | 7.18.2  | 0..n        |
                 | leaf         | 7.6     | 0..n        |
                 | leaf-list    | 7.7     | 0..n        |
                 | list         | 7.8     | 0..n        |
                 | reference    | 7.19.4  | 0..1        |
                 | status       | 7.19.2  | 0..1        |
                 | uses         | 7.12    | 0..n        |
                 | when         | 7.19.5  | 0..1        |
                 +--------------+---------+-------------+

7.15.2.  XML Mapping Rules

   All data nodes defined in the "augment" statement are defined as XML
   elements in the XML namespace of the module where the "augment" is
   specified.

   When a node is augmented, the augmenting child nodes are encoded as
   subelements to the augmented node, in any order.



Bjorklund                    Standards Track        =
           [Page 94]

 
RFC 6020                  =
        YANG                      October 2010


7.15.3.  Usage Example

   In namespace http://example.com/schema/interfaces, we have:

     container interfaces {
         list ifEntry {
             key "ifIndex";

             leaf ifIndex {
                 type uint32;
             }
             leaf ifDescr {
                 type string;
             }
             leaf ifType {
                 type iana:IfType;
             }
             leaf ifMtu {
                 type int32;
             }
         }
     }

   Then, in namespace http://example.com/schema/ds0, we have:

     import interface-module {
         prefix "if";
     }
     augment "/if:interfaces/if:ifEntry" {
         when "if:ifType=3D'ds0'";
         leaf ds0ChannelNumber {
             type ChannelNumber;
         }
     }

















Bjorklund                    Standards Track        =
           [Page 95]

 
RFC 6020                  =
        YANG                      October 2010


   A corresponding XML instance example:

     <interfaces xmlns=3D"http://example.com/schema/interfaces"
                 xmlns:ds0=3D"http://example.com/schema/ds0">
       <ifEntry>
         <ifIndex>1</ifIndex>
         <ifDescr>Flintstone Inc Ethernet A562</ifDescr>
         <ifType>ethernetCsmacd</ifType>
         <ifMtu>1500</ifMtu>
       </ifEntry>
       <ifEntry>
         <ifIndex>2</ifIndex>
         <ifDescr>Flintstone Inc DS0</ifDescr>
         <ifType>ds0</ifType>
         <ds0:ds0ChannelNumber>1</ds0:ds0ChannelNumber>
       </ifEntry>
     </interfaces>

   As another example, suppose we have the choice defined in
   Section 7.9.7.  The following construct=
 can be used to extend the
   protocol definition:

     augment /ex:system/ex:protocol/ex:name {
         case c {
             leaf smtp {
                 type empty;
             }
         }
     }

   A corresponding XML instance example:

     <ex:system>
       <ex:protocol>
         <ex:tcp/>
       </ex:protocol>
     </ex:system>

   or

     <ex:system>
       <ex:protocol>
         <other:smtp/>
       </ex:protocol>
     </ex:system>






Bjorklund                    Standards Track        =
           [Page 96]

 
RFC 6020                  =
        YANG                      October 2010


7.16.  The identity Statement

   The "identity" statement is used to define a new globally unique,
   abstract, and untyped identity.  Its only purpose is to denote its
   name, semantics, and existence.  An identity can either be defined
   from scratch or derived from a base identity.  The identity's
   argument is an identifier that is the name of the identity.  It is
   followed by a block of substatements that holds detailed identity
   information.

   The built-in datatype "identityref" (see Sec=
tion 9.10) can be used to
   reference identities within a data model.

7.16.1.  The identity's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | base         | 7.16.2  | 0..1        |
                 | description  | 7.19.3  | 0..1        |
                 | reference    | 7.19.4  | 0..1        |
                 | status       | 7.19.2  | 0..1        |
                 +--------------+---------+-------------+

7.16.2.  The base Statement

   The "base" statement, which is optional, takes as an argument a
   string that is the name of an existing identity, from which the new
   identity is derived.  If no "base" statement is present, the identity
   is defined from scratch.

   If a prefix is present on the base name, it refers to an identity
   defined in the module that was imported with that prefix, or the
   local module if the prefix matches the local module's prefix.
   Otherwise, an identity with the matching name MUST be defined in the
   current module or an included submodule.

   Since submodules cannot include the parent module, any identities in
   the module that need to be exposed to submodules MUST be defined in a
   submodule.  Submodules can then include this submodule to find the
   definition of the identity.

   An identity MUST NOT reference itself, neither directly nor
   indirectly through a chain of other identities.







Bjorklund                    Standards Track        =
           [Page 97]

 
RFC 6020                  =
        YANG                      October 2010


7.16.3.  Usage Example

     module crypto-base {
         namespace "http://example.com/crypto-base";
         prefix "crypto";

         identity crypto-alg {
             description
                "Base identity from which all crypto algorithms
                 are derived.";
         }
     }

     module des {
         namespace "http://example.com/des";
         prefix "des";

         import "crypto-base" {
             prefix "crypto";
         }

         identity des {
             base "crypto:crypto-alg";
             description "DES crypto algorithm";
         }

         identity des3 {
             base "crypto:crypto-alg";
             description "Triple DES crypto algorithm";
         }
     }

7.17.  The extension Statement

   The "extension" statement allows the definition of new statements
   within the YANG language.  This new statement definition can be
   imported and used by other modules.

   The statement's argument is an identifier that is the new keyword for
   the extension and must be followed by a block of substatements that
   holds detailed extension information.  The purpose of the "extension"
   statement is to define a keyword, so that it can be imported and used
   by other modules.

   The extension can be used like a normal YANG statement, with the
   statement name followed by an argument if one is defined by the
   extension, and an optional block of substatements.  The statement's
   name is created by combining the prefix of the module in which the



Bjorklund                    Standards Track        =
           [Page 98]

 
RFC 6020                  =
        YANG                      October 2010


   extension was defined, a colon (":"), and the extension's keyword,
   with no interleaving whitespace.  The substatements of an extension
   are defined by the extension, using some mechanism outside the scope
   of this specification.  Syntactically, the substatements MUST be YANG
   statements, or also defined using "extension" statements.  YANG
   statements in extensions MUST follow the syntactical rules in
   Section 12.

7.17.1.  The extension's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | argument     | 7.17.2  | 0..1        |
                 | description  | 7.19.3  | 0..1        |
                 | reference    | 7.19.4  | 0..1        |
                 | status       | 7.19.2  | 0..1        |
                 +--------------+---------+-------------+

7.17.2.  The argument Statement

   The "argument" statement, which is optional, takes as an argument a
   string that is the name of the argument to the keyword.  If no
   argument statement is present, the keyword expects no argument when
   it is used.

   The argument's name is used in the YIN mapping, where it is used as
   an XML attribute or element name, depending on the argument's "yin-
   element" statement.

7.17.2.1.  The argument's Substatements

                 +--------------+----------+-------------+
                 | substatement | section  | cardinality |
                 +--------------+----------+-------------+
                 | yin-element  | 7.17.2.2 | 0..1        |
                 +--------------+----------+-------------+

7.17.2.2.  The yin-element Statement

   The "yin-element" statement, which is optional, takes as an argument
   the string "true" or "false".  This statement indicates if the
   argument is mapped to an XML element in YIN or to an XML attribute
   (see Section 11).

   If no "yin-element" statement is present, it defaults to "false".





Bjorklund                    Standards Track        =
           [Page 99]

 
RFC 6020                  =
        YANG                      October 2010


7.17.3.  Usage Example

   To define an extension:

     module my-extensions {
       ...

       extension c-define {
         description
           "Takes as argument a name string.
           Makes the code generator use the given name in the
           #define.";
         argument "name";
       }
     }

   To use the extension:

     module my-interfaces {
       ...
       import my-extensions {
         prefix "myext";
       }
       ...

       container interfaces {
         ...
         myext:c-define "MY_INTERFACES";
       }
     }

7.18.  Conformance-Related Statements

   This section defines statements related to conformance, as described
   in Section 5.6.

7.18.1.  The feature Statement

   The "feature" statement is used to define a mechanism by which
   portions of the schema are marked as conditional.  A feature name is
   defined that can later be referenced using the "if-feature" statement
   (see Section 7.18.2).  Schema nodes ta=
gged with a feature are ignored
   by the device unless the device supports the given feature.  This
   allows portions of the YANG module to be conditional based on
   conditions on the device.  The model can represent the abilities of
   the device within the model, giving a richer model that allows for
   differing device abilities and roles.




Bjorklund                    Standards Track        =
          [Page 100]

 
RFC 6020                  =
        YANG                      October 2010


   The argument to the "feature" statement is the name of the new
   feature, and follows the rules for identifiers in Section 6.2.  This
   name is used by the "if-feature" statement to tie the schema nodes to
   the feature.

   In this example, a feature called "local-storage" represents the
   ability for a device to store syslog messages on local storage of
   some sort.  This feature is used to make the "local-storage-limit"
   leaf conditional on the presence of some sort of local storage.  If
   the device does not report that it supports this feature, the
   "local-storage-limit" node is not supported.

     module syslog {
         ...
         feature local-storage {
             description
                 "This feature means the device supports local
                  storage (memory, flash or disk) that can be used to
                  store syslog messages.";
         }

         container syslog {
             leaf local-storage-limit {
                 if-feature local-storage;
                 type uint64;
                 units "kilobyte";
                 config false;
                 description
                     "The amount of local storage that can be
                      used to hold syslog messages.";
             }
         }
     }

   The "if-feature" statement can be used in many places within the YANG
   syntax.  Definitions tagged with "if-feature" are ignored when the
   device does not support that feature.

   A feature MUST NOT reference itself, neither directly nor indirectly
   through a chain of other features.

   In order for a device to implement a feature that is dependent on any
   other features (i.e., the feature has one or more "if-feature" sub-
   statements), the device MUST also implement all the dependant
   features.






Bjorklund                    Standards Track        =
          [Page 101]

 
RFC 6020                  =
        YANG                      October 2010


7.18.1.1.  The feature's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | description  | 7.19.3  | 0..1        |
                 | if-feature   | 7.18.2  | 0..n        |
                 | status       | 7.19.2  | 0..1        |
                 | reference    | 7.19.4  | 0..1        |
                 +--------------+---------+-------------+

7.18.2.  The if-feature Statement

   The "if-feature" statement makes its parent statement conditional.
   The argument is the name of a feature, as defined by a "feature"
   statement.  The parent statement is implemented by servers that
   support this feature.  If a prefix is present on the feature name, it
   refers to a feature defined in the module that was imported with that
   prefix, or the local module if the prefix matches the local module's
   prefix.  Otherwise, a feature with the matching name MUST be defined
   in the current module or an included submodule.

   Since submodules cannot include the parent module, any features in
   the module that need to be exposed to submodules MUST be defined in a
   submodule.  Submodules can then include this submodule to find the
   definition of the feature.

7.18.3.  The deviation Statement

   The "deviation" statement defines a hierarchy of a module that the
   device does not implement faithfully.  The argument is a string that
   identifies the node in the schema tree where a deviation from the
   module occurs.  This node is called the deviation's target node.  The
   contents of the "deviation" statement give details about the
   deviation.

   The argument string is an absolute schema node identifier (see
   Section 6.5).

   Deviations define the way a device or class of devices deviate from a
   standard.  This means that deviations MUST never be part of a
   published standard, since they are the mechanism for learning how
   implementations vary from the standards.








Bjorklund                    Standards Track        =
          [Page 102]

 
RFC 6020                  =
        YANG                      October 2010


   Device deviations are strongly discouraged and MUST only be used as a
   last resort.  Telling the application how a device fails to follow a
   standard is no substitute for implementing the standard correctly.  A
   device that deviates from a module is not fully compliant with the
   module.

   However, in some cases, a particular device may not have the hardware
   or software ability to support parts of a standard module.  When this
   occurs, the device makes a choice either to treat attempts to
   configure unsupported parts of the module as an error that is
   reported back to the unsuspecting application or ignore those
   incoming requests.  Neither choice is acceptable.

   Instead, YANG allows devices to document portions of a base module
   that are not supported or supported but with different syntax, by
   using the "deviation" statement.

7.18.3.1.  The deviation's Substatements

                 +--------------+----------+-------------+
                 | substatement | section  | cardinality |
                 +--------------+----------+-------------+
                 | description  | 7.19.3   | 0..1        |
                 | deviate      | 7.18.3.2 | 1..n        |
                 | reference    | 7.19.4   | 0..1        |
                 +--------------+----------+-------------+

7.18.3.2.  The deviate Statement

   The "deviate" statement defines how the device's implementation of
   the target node deviates from its original definition.  The argument
   is one of the strings "not-supported", "add", "replace", or "delete".

   The argument "not-supported" indicates that the target node is not
   implemented by this device.

   The argument "add" adds properties to the target node.  The
   properties to add are identified by substatements to the "deviate"
   statement.  If a property can only appear once, the property MUST NOT
   exist in the target node.

   The argument "replace" replaces properties of the target node.  The
   properties to replace are identified by substatements to the
   "deviate" statement.  The properties to replace MUST exist in the
   target node.






Bjorklund                    Standards Track        =
          [Page 103]

 
RFC 6020                  =
        YANG                      October 2010


   The argument "delete" deletes properties from the target node.  The
   properties to delete are identified by substatements to the "delete"
   statement.  The substatement's keyword MUST match a corresponding
   keyword in the target node, and the argument's string MUST be equal
   to the corresponding keyword's argument string in the target node.

                       The deviates's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | config       | 7.19.1  | 0..1        |
                 | default      | 7.6.4   | 0..1        |
                 | mandatory    | 7.6.5   | 0..1        |
                 | max-elements | 7.7.4   | 0..1        |
                 | min-elements | 7.7.3   | 0..1        |
                 | must         | 7.5.3   | 0..n        |
                 | type         | 7.4     | 0..1        |
                 | unique       | 7.8.3   | 0..n        |
                 | units        | 7.3.3   | 0..1        |
                 +--------------+---------+-------------+

7.18.3.3.  Usage Example

   In this example, the device is informing client applications that it
   does not support the "daytime" service in the style of RFC 867.

     deviation /base:system/base:daytime {
         deviate not-supported;
     }

   The following example sets a device-specific default value to a leaf
   that does not have a default value defined:

     deviation /base:system/base:user/base:type {
         deviate add {
             default "admin"; // new users are 'admin' by default
         }
     }

   In this example, the device limits the number of name servers to 3:

     deviation /base:system/base:name-server {
         deviate replace {
             max-elements 3;
         }
     }




Bjorklund                    Standards Track        =
          [Page 104]

 
RFC 6020                  =
        YANG                      October 2010


   If the original definition is:

     container system {
         must "daytime or time";
         ...
     }

   a device might remove this must constraint by doing:

     deviation "/base:system" {
         deviate delete {
             must "daytime or time";
         }
     }

7.19.  Common Statements

   This section defines substatements common to several other
   statements.

7.19.1.  The config Statement

   The "config" statement takes as an argument the string "true" or
   "false".  If "config" is "true", the definition represents
   configuration.  Data nodes representing configuration will be part of
   the reply to a <get-config> request, and can be sent in a
   <copy-config> or <edit-config> request.

   If "config" is "false", the definition represents state data.  Data
   nodes representing state data will be part of the reply to a <get&g=
t;,
   but not to a <get-config> request, and cannot be sent in a
   <copy-config> or <edit-config> request.

   If "config" is not specified, the default is the same as the parent
   schema node's "config" value.  If the parent node is a "case" node,
   the value is the same as the "case" node's parent "choice" node.

   If the top node does not specify a "config" statement, the default is
   "true".

   If a node has "config" set to "false", no node underneath it can have
   "config" set to "true".

7.19.2.  The status Statement

   The "status" statement takes as an argument one of the strings
   "current", "deprecated", or "obsolete".




Bjorklund                    Standards Track        =
          [Page 105]

 
RFC 6020                  =
        YANG                      October 2010


   o  "current" means that the definition is current and valid.

   o  "deprecated" indicates an obsolete definition, but it permits new/
      continued implementation in order to foster interoperability with
      older/existing implementations.

   o  "obsolete" means the definition is obsolete and SHOULD NOT be
      implemented and/or can be removed from implementations.

   If no status is specified, the default is "current".

   If a definition is "current", it MUST NOT reference a "deprecated" or
   "obsolete" definition within the same module.

   If a definition is "deprecated", it MUST NOT reference an "obsolete"
   definition within the same module.

   For example, the following is illegal:

     typedef my-type {
       status deprecated;
       type int32;
     }

     leaf my-leaf {
       status current;
       type my-type; // illegal, since my-type is deprecated
     }

7.19.3.  The description Statement

   The "description" statement takes as an argument a string that
   contains a human-readable textual description of this definition.
   The text is provided in a language (or languages) chosen by the
   module developer; for the sake of interoperability, it is RECOMMENDED
   to choose a language that is widely understood among the community of
   network administrators who will use the module.

7.19.4.  The reference Statement

   The "reference" statement takes as an argument a string that is used
   to specify a textual cross-reference to an external document, either
   another module that defines related management information, or a
   document that provides additional information relevant to this
   definition.






Bjorklund                    Standards Track        =
          [Page 106]

 
RFC 6020                  =
        YANG                      October 2010


   For example, a typedef for a "uri" data type could look like:

     typedef uri {
       type string;
       reference
         "RFC 3986: Uniform Resource Identifier=
 (URI): Generic Syntax";
       ...
     }

7.19.5.  The when Statement

   The "when" statement makes its parent data definition statement
   conditional.  The node defined by the parent data definition
   statement is only valid when the condition specified by the "when"
   statement is satisfied.  The statement's argument is an XPath
   expression (see Section 6.4), which is us=
ed to formally specify this
   condition.  If the XPath expression conceptually evaluates to "true"
   for a particular instance, then the node defined by the parent data
   definition statement is valid; otherwise, it is not.

   See Section 8.3.2 for additional inform=
ation.

   The XPath expression is conceptually evaluated in the following
   context, in addition to the definition in S=
ection 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.

   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.

   o  If the "when" statement is a child of any other data definition
      statement, the context node is the data definition's node in the
      data tree.

   o  The accessible tree is made up of all nodes in the data tree, and
      all leafs with default values in use (see Section 7.6.1).









Bjorklund                    Standards Track        =
          [Page 107]

 
RFC 6020                  =
        YANG                      October 2010


   The accessible tree depends on the context node:

   o  If the context node represents configuration, the tree is the data
      in the NETCONF datastore where the context node exists.  The XPath
      root node has all top-level configuration data nodes in all
      modules as children.

   o  If the context node represents state data, the tree is all state
      data on the device, and the <running/> datastore.  The XPath =
root
      node has all top-level data nodes in all modules as children.

   o  If the context node represents notification content, the tree is
      the notification XML instance document.  The XPath root node has
      the element representing the notification being defined as the
      only child.

   o  If the context node represents RPC input parameters, the tree is
      the RPC XML instance document.  The XPath root node has the
      element representing the RPC operation being defined as the only
      child.

   o  If the context node represents RPC output parameters, the tree is
      the RPC reply instance document.  The XPath root node has the
      elements representing the RPC output parameters as children.

   The result of the XPath expression is converted to a boolean value
   using the standard XPath rules.

   Note that the XPath expression is conceptually evaluated.  This means
   that an implementation does not have to use an XPath evaluator on the
   device.  The "when" statement can very well be implemented with
   specially written code.

8.  Constraints

8.1.  Constraints on Data

   Several YANG statements define constraints on valid data.  These
   constraints are enforced in different ways, depending on what type of
   data the statement defines.

   o  If the constraint is defined on configuration data, it MUST be
      true in a valid configuration data tree.

   o  If the constraint is defined on state data, it MUST be true in a
      reply to a <get> operation without a filter.





Bjorklund                    Standards Track        =
          [Page 108]

 
RFC 6020                  =
        YANG                      October 2010


   o  If the constraint is defined on notification content, it MUST be
      true in any notification instance.

   o  If the constraint is defined on RPC input parameters, it MUST be
      true in an invocation of the RPC operation.

   o  If the constraint is defined on RPC output parameters, it MUST be
      true in the RPC reply.

8.2.  Hierarchy of Constraints

   Conditions on parent nodes affect constraints on child nodes as a
   natural consequence of the hierarchy of nodes. "must", "mandatory",
   "min-elements", and "max-elements" constraints are not enforced if
   the parent node has a "when" or "if-feature" property that is not
   satisfied on the current device.

   In this example, the "mandatory" constraint on the "longitude" leaf
   are not enforced on devices that lack the "has-gps" feature:

       container location {
           if-feature has-gps;
           leaf longitude {
               mandatory true;
               ...
           }
       }

8.3.  Constraint Enforcement Model

   For configuration data, there are three windows when constraints MUST
   be enforced:

   o  during parsing of RPC payloads

   o  during processing of NETCONF operations

   o  during validation

   Each of these scenarios is considered in the following sections.

8.3.1.  Payload Parsing

   When content arrives in RPC payloads, it MUST be well-formed XML,
   following the hierarchy and content rules defined by the set of
   models the device implements.





Bjorklund                    Standards Track        =
          [Page 109]

 
RFC 6020                  =
        YANG                      October 2010


   o  If a leaf data value does not match the type constraints for the
      leaf, including those defined in the type's "range", "length", and
      "pattern" properties, the server MUST reply with an
      "invalid-value" error-tag in the rpc-error, and with the error-
      app-tag and error-message associated with the constraint, if any
      exist.

   o  If all keys of a list entry are not present, the server MUST reply
      with a "missing-element" error-tag in the rpc-error.

   o  If data for more than one case branch of a choice is present, the
      server MUST reply with a "bad-element" in the rpc-error.

   o  If data for a node tagged with "if-feature" is present, and the
      feature is not supported by the device, the server MUST reply with
      an "unknown-element" error-tag in the rpc-error.

   o  If data for a node tagged with "when" is present, and the "when"
      condition evaluates to "false", the server MUST reply with an
      "unknown-element" error-tag in the rpc-error.

   o  For insert handling, if the value for the attributes "before" and
      "after" are not valid for the type of the appropriate key leafs,
      the server MUST reply with a "bad-attribute" error-tag in the rpc-
      error.

   o  If the attributes "before" and "after" appears in any element that
      is not a list whose "ordered-by" property is "user", the server
      MUST reply with an "unknown-attribute" error-tag in the rpc-error.

8.3.2.  NETCONF <edit-config> Processing

   After the incoming data is parsed, the NETCONF server performs the
   <edit-config> operation by applying the data to the configuratio=
n
   datastore.  During this processing, the following errors MUST be
   detected:

   o  Delete requests for non-existent data.

   o  Create requests for existent data.

   o  Insert requests with "before" or "after" parameters that do not
      exist.








Bjorklund                    Standards Track        =
          [Page 110]

 
RFC 6020                  =
        YANG                      October 2010


   During <edit-config> processing:

   o  If the NETCONF operation creates data nodes under a "choice", any
      existing nodes from other "case" branches are deleted by the
      server.

   o  If the NETCONF operation modifies a data node such that any node's
      "when" expression becomes false, then the node with the "when"
      expression is deleted by the server.

8.3.3.  Validation

   When datastore processing is complete, the final contents MUST obey
   all validation constraints.  This validation processing is performed
   at differing times according to the datastore.  If the datastore is
   <running/> or <startup/>, these constraints MUST be enforc=
ed at the
   end of the <edit-config> or <copy-config> operation.  If t=
he
   datastore is <candidate/>, the constraint enforcement is delayed=

   until a <commit> or <validate> operation.

   o  Any "must" constraints MUST evaluate to "true".

   o  Any referential integrity constraints defined via the "path"
      statement MUST be satisfied.

   o  Any "unique" constraints on lists MUST be satisfied.

   o  The "min-elements" and "max-elements" constraints are enforced for
      lists and leaf-lists.

9.  Built-In Types

   YANG has a set of built-in types, similar to those of many
   programming languages, but with some differences due to special
   requirements from the management information model.

   Additional types may be defined, derived from those built-in types or
   from other derived types.  Derived types may use subtyping to
   formally restrict the set of possible values.

   The different built-in types and their derived types allow different
   kinds of subtyping, namely length and regular expression restrictions
   of strings (Sections 9.4.4 and 9.4.6) and range restrictions of
   numeric types (Section 9.2.4).

   The lexical representation of a value of a certain type is used in
   the NETCONF messages and when specifying default values and numerical
   ranges in YANG modules.



Bjorklund                    Standards Track        =
          [Page 111]

 
RFC 6020                  =
        YANG                      October 2010


9.1.  Canonical Representation

   For most types, there is a single canonical representation of the
   type's values.  Some types allow multiple lexical representations of
   the same value, for example, the positive integer "17" can be
   represented as "+17" or "17".  Implementations MUST support all
   lexical representations specified in this document.

   When a NETCONF server sends data, it MUST be in the canonical form.

   Some types have a lexical representation that depends on the XML
   context in which they occur.  These types do not have a canonical
   form.

9.2.  The Integer Built-In Types

   The integer built-in types are int8, int16, int32, int64, uint8,
   uint16, uint32, and uint64.  They represent signed and unsigned
   integers of different sizes:

   int8  represents integer values between -128 and 127, inclusively.

   int16  represents integer values between -32768 and 32767,
      inclusively.

   int32  represents integer values between -2147483648 and 2147483647,
      inclusively.

   int64  represents integer values between -9223372036854775808 and
      9223372036854775807, inclusively.

   uint8  represents integer values between 0 and 255, inclusively.

   uint16  represents integer values between 0 and 65535, inclusively.

   uint32  represents integer values between 0 and 4294967295,
      inclusively.

   uint64  represents integer values between 0 and 18446744073709551615,
      inclusively.











Bjorklund                    Standards Track        =
          [Page 112]

 
RFC 6020                  =
        YANG                      October 2010


9.2.1.  Lexical Representation

   An integer value is lexically represented as an optional sign ("+" or
   "-"), followed by a sequence of decimal digits.  If no sign is
   specified, "+" is assumed.

   For convenience, when specifying a default value for an integer in a
   YANG module, an alternative lexical representation can be used, which
   represents the value in a hexadecimal or octal notation.  The
   hexadecimal notation consists of an optional sign ("+" or "-"), the
   characters "0x" followed a number of hexadecimal digits, where
   letters may be uppercase or lowercase.  The octal notation consists
   of an optional sign ("+" or "-"), the character "0" followed a number
   of octal digits.

   Note that if a default value in a YANG module has a leading zero
   ("0"), it is interpreted as an octal number.  In the XML instance
   documents, an integer is always interpreted as a decimal number, and
   leading zeros are allowed.

   Examples:

     // legal values
     +4711                       // legal positive value
     4711                        // legal positive value
     -123                        // legal negative value
     0xf00f                      // legal positive hexadecimal value
     -0xf                        // legal negative hexadecimal value
     052                         // legal positive octal value

     // illegal values
     - 1                         // illegal intermediate space



















Bjorklund                    Standards Track        =
          [Page 113]

 
RFC 6020                  =
        YANG                      October 2010


9.2.2.  Canonical Form

   The canonical form of a positive integer does not include the sign
   "+".  Leading zeros are prohibited.  The value zero is represented as
   "0".

9.2.3.  Restrictions

   All integer types can be restricted with the "range" statement
   (Section 9.2.4).

9.2.4.  The range Statement

   The "range" statement, which is an optional substatement to the
   "type" statement, takes as an argument a range expression string.  It
   is used to restrict integer and decimal built-in types, or types
   derived from those.

   A range consists of an explicit value, or a lower-inclusive bound,
   two consecutive dots "..", and an upper-inclusive bound.  Multiple
   values or ranges can be given, separated by "|".  If multiple values
   or ranges are given, they all MUST be disjoint and MUST be in
   ascending order.  If a range restriction is applied to an already
   range-restricted type, the new restriction MUST be equal or more
   limiting, that is raising the lower bounds, reducing the upper
   bounds, removing explicit values or ranges, or splitting ranges into
   multiple ranges with intermediate gaps.  Each explicit value and
   range boundary value given in the range expression MUST match the
   type being restricted, or be one of the special values "min" or
   "max". "min" and "max" mean the minimum and maximum value accepted
   for the type being restricted, respectively.

   The range expression syntax is formally defined by the rule
   "range-arg" in Section 12.

9.2.4.1.  The range's Substatements

                 +---------------+---------+-------------+
                 | substatement  | section | cardinality |
                 +---------------+---------+-------------+
                 | description   | 7.19.3  | 0..1        |
                 | error-app-tag | 7.5.4.2 | 0..1        |
                 | error-message | 7.5.4.1 | 0..1        |
                 | reference     | 7.19.4  | 0..1        |
                 +---------------+---------+-------------+






Bjorklund                    Standards Track        =
          [Page 114]

 
RFC 6020                  =
        YANG                      October 2010


9.2.5.  Usage Example

     typedef my-base-int32-type {
         type int32 {
             range "1..4 | 10..20";
         }
     }

     typedef my-type1 {
         type my-base-int32-type {
             // legal range restriction
             range "11..max"; // 11..20
         }
     }

     typedef my-type2 {
         type my-base-int32-type {
             // illegal range restriction
             range "11..100";
         }
     }

9.3.  The decimal64 Built-In Type

   The decimal64 type represents a subset of the real numbers, which can
   be represented by decimal numerals.  The value space of decimal64 is
   the set of numbers that can be obtained by multiplying a 64-bit
   signed integer by a negative power of ten, i.e., expressible as
   "i x 10^-n" where i is an integer64 and n is an integer between 1 and
   18, inclusively.

9.3.1.  Lexical Representation

   A decimal64 value is lexically represented as an optional sign ("+"
   or "-"), followed by a sequence of decimal digits, optionally
   followed by a period ('.') as a decimal indicator and a sequence of
   decimal digits.  If no sign is specified, "+" is assumed.

9.3.2.  Canonical Form

   The canonical form of a positive decimal64 does not include the sign
   "+".  The decimal point is required.  Leading and trailing zeros are
   prohibited, subject to the rule that there MUST be at least one digit
   before and after the decimal point.  The value zero is represented as
   "0.0".






Bjorklund                    Standards Track        =
          [Page 115]

 
RFC 6020                  =
        YANG                      October 2010


9.3.3.  Restrictions

   A decimal64 type can be restricted with the "range" statement
   (Section 9.2.4).

9.3.4.  The fraction-digits Statement

   The "fraction-digits" statement, which is a substatement to the
   "type" statement, MUST be present if the type is "decimal64".  It
   takes as an argument an integer between 1 and 18, inclusively.  It
   controls the size of the minimum difference between values of a
   decimal64 type, by restricting the value space to numbers that are
   expressible as "i x 10^-n" where n is the fraction-digits argument.

   The following table lists the minimum and maximum value for each
   fraction-digit value:

     +----------------+-----------------------+----------------------+
     | fraction-digit | min                   | max                  |
     +----------------+-----------------------+----------------------+
     | 1              | -922337203685477580.8 | 922337203685477580.7 |
     | 2              | -92233720368547758.08 | 92233720368547758.07 |
     | 3              | -9223372036854775.808 | 9223372036854775.807 |
     | 4              | -922337203685477.5808 | 922337203685477.5807 |
     | 5              | -92233720368547.75808 | 92233720368547.75807 |
     | 6              | -9223372036854.775808 | 9223372036854.775807 |
     | 7              | -922337203685.4775808 | 922337203685.4775807 |
     | 8              | -92233720368.54775808 | 92233720368.54775807 |
     | 9              | -9223372036.854775808 | 9223372036.854775807 |
     | 10             | -922337203.6854775808 | 922337203.6854775807 |
     | 11             | -92233720.36854775808 | 92233720.36854775807 |
     | 12             | -9223372.036854775808 | 9223372.036854775807 |
     | 13             | -922337.2036854775808 | 922337.2036854775807 |
     | 14             | -92233.72036854775808 | 92233.72036854775807 |
     | 15             | -9223.372036854775808 | 9223.372036854775807 |
     | 16             | -922.3372036854775808 | 922.3372036854775807 |
     | 17             | -92.23372036854775808 | 92.23372036854775807 |
     | 18             | -9.223372036854775808 | 9.223372036854775807 |
     +----------------+-----------------------+----------------------+












Bjorklund                    Standards Track        =
          [Page 116]

 
RFC 6020                  =
        YANG                      October 2010


9.3.5.  Usage Example

     typedef my-decimal {
         type decimal64 {
             fraction-digits 2;
             range "1 .. 3.14 | 10 | 20..max";
         }
     }

9.4.  The string Built-In Type

   The string built-in type represents human-readable strings in YANG.
   Legal characters are tab, carriage return, line feed, and the legal
   characters of Unicode and ISO/IEC 10646 [ISO.10646]:

     ;; any Unicode character, excluding the surrogate blocks,
     ;; FFFE, and FFFF.
     string =3D *char
     char =3D %x9 / %xA / %xD / %x20-D7FF / %xE000-FFFD /
            %x10000-10FFFF

9.4.1.  Lexical Representation

   A string value is lexically represented as character data in the XML
   instance documents.

9.4.2.  Canonical Form

   The canonical form is the same as the lexical representation.  No
   Unicode normalization is performed of string values.

9.4.3.  Restrictions

   A string can be restricted with the "length" (Section 9.4.4) and
   "pattern" (Section 9.4.6) statements.

9.4.4.  The length Statement

   The "length" statement, which is an optional substatement to the
   "type" statement, takes as an argument a length expression string.
   It is used to restrict the built-in type "string", or types derived
   from "string".

   A "length" statement restricts the number of Unicode characters in
   the string.






Bjorklund                    Standards Track        =
          [Page 117]

 
RFC 6020                  =
        YANG                      October 2010


   A length range consists of an explicit value, or a lower bound, two
   consecutive dots "..", and an upper bound.  Multiple values or ranges
   can be given, separated by "|".  Length-restricting values MUST NOT
   be negative.  If multiple values or ranges are given, they all MUST
   be disjoint and MUST be in ascending order.  If a length restriction
   is applied to an already length-restricted type, the new restriction
   MUST be equal or more limiting, that is, raising the lower bounds,
   reducing the upper bounds, removing explicit length values or ranges,
   or splitting ranges into multiple ranges with intermediate gaps.  A
   length value is a non-negative integer, or one of the special values
   "min" or "max". "min" and "max" mean the minimum and maximum length
   accepted for the type being restricted, respectively.  An
   implementation is not required to support a length value larger than
   18446744073709551615.

   The length expression syntax is formally defined by the rule
   "length-arg" in Section 12.

9.4.4.1.  The length's Substatements

                 +---------------+---------+-------------+
                 | substatement  | section | cardinality |
                 +---------------+---------+-------------+
                 | description   | 7.19.3  | 0..1        |
                 | error-app-tag | 7.5.4.2 | 0..1        |
                 | error-message | 7.5.4.1 | 0..1        |
                 | reference     | 7.19.4  | 0..1        |
                 +---------------+---------+-------------+

9.4.5.  Usage Example

     typedef my-base-str-type {
         type string {
             length "1..255";
         }
     }

     type my-base-str-type {
         // legal length refinement
         length "11 | 42..max"; // 11 | 42..255=

     }

     type my-base-str-type {
         // illegal length refinement
         length "1..999";
     }





Bjorklund                    Standards Track        =
          [Page 118]

 
RFC 6020                  =
        YANG                      October 2010


9.4.6.  The pattern Statement

   The "pattern" statement, which is an optional substatement to the
   "type" statement, takes as an argument a regular expression string,
   as defined in [XSD-TYPES].  It is used to rest=
rict the built-in type
   "string", or types derived from "string", to values that match the
   pattern.

   If the type has multiple "pattern" statements, the expressions are
   ANDed together, i.e., all such expressions have to match.

   If a pattern restriction is applied to an already pattern-restricted
   type, values must match all patterns in the base type, in addition to
   the new patterns.

9.4.6.1.  The pattern's Substatements

                 +---------------+---------+-------------+
                 | substatement  | section | cardinality |
                 +---------------+---------+-------------+
                 | description   | 7.19.3  | 0..1        |
                 | error-app-tag | 7.5.4.2 | 0..1        |
                 | error-message | 7.5.4.1 | 0..1        |
                 | reference     | 7.19.4  | 0..1        |
                 +---------------+---------+-------------+

9.4.7.  Usage Example

   With the following type:

     type string {
         length "0..4";
         pattern "[0-9a-fA-F]*";
     }

   the following strings match:

     AB          // legal
     9A00        // legal

   and the following strings do not match:

     00ABAB      // illegal, too long
     xx00        // illegal, bad characters







Bjorklund                    Standards Track        =
          [Page 119]

 
RFC 6020                  =
        YANG                      October 2010


9.5.  The boolean Built-In Type

   The boolean built-in type represents a boolean value.

9.5.1.  Lexical Representation

   The lexical representation of a boolean value is a string with a
   value of "true" or "false".  These values MUST be in lowercase.

9.5.2.  Canonical Form

   The canonical form is the same as the lexical representation.

9.5.3.  Restrictions

   A boolean cannot be restricted.

9.6.  The enumeration Built-In Type

   The enumeration built-in type represents values from a set of
   assigned names.

9.6.1.  Lexical Representation

   The lexical representation of an enumeration value is the assigned
   name string.

9.6.2.  Canonical Form

   The canonical form is the assigned name string.

9.6.3.  Restrictions

   An enumeration cannot be restricted.

9.6.4.  The enum Statement

   The "enum" statement, which is a substatement to the "type"
   statement, MUST be present if the type is "enumeration".  It is
   repeatedly used to specify each assigned name of an enumeration type.
   It takes as an argument a string which is the assigned name.  The
   string MUST NOT be empty and MUST NOT have any leading or trailing
   whitespace characters.  The use of Unicode control codes SHOULD be
   avoided.

   The statement is optionally followed by a block of substatements that
   holds detailed enum information.




Bjorklund                    Standards Track        =
          [Page 120]

 
RFC 6020                  =
        YANG                      October 2010


   All assigned names in an enumeration MUST be unique.

9.6.4.1.  The enum's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | description  | 7.19.3  | 0..1        |
                 | reference    | 7.19.4  | 0..1        |
                 | status       | 7.19.2  | 0..1        |
                 | value        | 9.6.4.2 | 0..1        |
                 +--------------+---------+-------------+

9.6.4.2.  The value Statement

   The "value" statement, which is optional, is used to associate an
   integer value with the assigned name for the enum.  This integer
   value MUST be in the range -2147483648 to 2147483647, and it MUST be
   unique within the enumeration type.  The value is unused by YANG and
   the XML encoding, but is carried as a convenience to implementors.

   If a value is not specified, then one will be automatically assigned.
   If the "enum" substatement is the first one defined, the assigned
   value is zero (0); otherwise, the assigned value is one greater than
   the current highest enum value.

   If the current highest value is equal to 2147483647, then an enum
   value MUST be specified for "enum" substatements following the one
   with the current highest value.

9.6.5.  Usage Example

     leaf myenum {
         type enumeration {
             enum zero;
             enum one;
             enum seven {
                 value 7;
             }
         }
     }

   The lexical representation of the leaf "myenum" with value "seven"
   is:

     <myenum>seven</myenum>





Bjorklund                    Standards Track        =
          [Page 121]

 
RFC 6020                  =
        YANG                      October 2010


9.7.  The bits Built-In Type

   The bits built-in type represents a bit set.  That is, a bits value
   is a set of flags identified by small integer position numbers
   starting at 0.  Each bit number has an assigned name.

9.7.1.  Restrictions

   A bits type cannot be restricted.

9.7.2.  Lexical Representation

   The lexical representation of the bits type is a space-separated list
   of the individual bit values that are set.  An empty string thus
   represents a value where no bits are set.

9.7.3.  Canonical Form

   In the canonical form, the bit values are separated by a single space
   character and they appear ordered by their position (see
   Section 9.7.4.2).

9.7.4.  The bit Statement

   The "bit" statement, which is a substatement to the "type" statement,
   MUST be present if the type is "bits".  It is repeatedly used to
   specify each assigned named bit of a bits type.  It takes as an
   argument a string that is the assigned name of the bit.  It is
   followed by a block of substatements that holds detailed bit
   information.  The assigned name follows the same syntax rules as an
   identifier (see Section 6.2).

   All assigned names in a bits type MUST be unique.

9.7.4.1.  The bit's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | description  | 7.19.3  | 0..1        |
                 | reference    | 7.19.4  | 0..1        |
                 | status       | 7.19.2  | 0..1        |
                 | position     | 9.7.4.2 | 0..1        |
                 +--------------+---------+-------------+







Bjorklund                    Standards Track        =
          [Page 122]

 
RFC 6020                  =
        YANG                      October 2010


9.7.4.2.  The position Statement

   The "position" statement, which is optional, takes as an argument a
   non-negative integer value that specifies the bit's position within a
   hypothetical bit field.  The position value MUST be in the range 0 to
   4294967295, and it MUST be unique within the bits type.  The value is
   unused by YANG and the NETCONF messages, but is carried as a
   convenience to implementors.

   If a bit position is not specified, then one will be automatically
   assigned.  If the "bit" substatement is the first one defined, the
   assigned value is zero (0); otherwise, the assigned value is one
   greater than the current highest bit position.

   If the current highest bit position value is equal to 4294967295,
   then a position value MUST be specified for "bit" substatements
   following the one with the current highest position value.

9.7.5.  Usage Example

   Given the following leaf:

     leaf mybits {
         type bits {
             bit disable-nagle {
                 position 0;
             }
             bit auto-sense-speed {
                 position 1;
             }
             bit 10-Mb-only {
                 position 2;
             }
         }
         default "auto-sense-speed";
     }

   The lexical representation of this leaf with bit values disable-nagle
   and 10-Mb-only set would be:

     <mybits>disable-nagle 10-Mb-only</mybits>

9.8.  The binary Built-In Type

   The binary built-in type represents any binary data, i.e., a sequence
   of octets.





Bjorklund                    Standards Track        =
          [Page 123]

 
RFC 6020                  =
        YANG                      October 2010


9.8.1.  Restrictions

   A binary can be restricted with the "length" (Section 9.4.4)
   statement.  The length of a binary value is the number of octets it
   contains.

9.8.2.  Lexical Representation

   Binary values are encoded with the base64 encoding scheme (see
   [RFC4648], Section 4).

9.8.3.  Canonical Form

   The canonical form of a binary value follows the rules in [RFC4648].

9.9.  The leafref Built-In Type

   The leafref type is used to reference a particular leaf instance in
   the data tree.  The "path" substatement (Se=
ction 9.9.2) selects a set
   of leaf instances, and the leafref value space is the set of values
   of these leaf instances.

   If the leaf with the leafref type represents configuration data, the
   leaf it refers to MUST also represent configuration.  Such a leaf
   puts a constraint on valid data.  All leafref nodes MUST reference
   existing leaf instances or leafs with default values in use (see
   Section 7.6.1) for the data to be valid=
=2E  This constraint is enforced
   according to the rules in Section 8.

   There MUST NOT be any circular chains of leafrefs.

   If the leaf that the leafref refers to is conditional based on one or
   more features (see Section 7.18.2), th=
en the leaf with the leafref
   type MUST also be conditional based on at least the same set of
   features.

9.9.1.  Restrictions

   A leafref cannot be restricted.

9.9.2.  The path Statement

   The "path" statement, which is a substatement to the "type"
   statement, MUST be present if the type is "leafref".  It takes as an
   argument a string that MUST refer to a leaf or leaf-list node.






Bjorklund                    Standards Track        =
          [Page 124]

 
RFC 6020                  =
        YANG                      October 2010


   The syntax for a path argument is a subset of the XPath abbreviated
   syntax.  Predicates are used only for constraining the values for the
   key nodes for list entries.  Each predicate consists of exactly one
   equality test per key, and multiple adjacent predicates MAY be
   present if a list has multiple keys.  The syntax is formally defined
   by the rule "path-arg" in Section 12.

   The predicates are only used when more than one key reference is
   needed to uniquely identify a leaf instance.  This occurs if a list
   has multiple keys, or a reference to a leaf other than the key in a
   list is needed.  In these cases, multiple leafrefs are typically
   specified, and predicates are used to tie them together.

   The "path" expression evaluates to a node set consisting of zero,
   one, or more nodes.  If the leaf with the leafref type represents
   configuration data, this node set MUST be non-empty.

   The "path" XPath expression is conceptually evaluated in the
   following context, in addition to the definition in Section 6.4.1:

   o  The context node is the node in the data tree for which the "path"
      statement is defined.

   The accessible tree depends on the context node:

   o  If the context node represents configuration data, the tree is the
      data in the NETCONF datastore where the context node exists.  The
      XPath root node has all top-level configuration data nodes in all
      modules as children.

   o  Otherwise, the tree is all state data on the device, and the
      <running/> datastore.  The XPath root node has all top-level =
data
      nodes in all modules as children.

9.9.3.  Lexical Representation

   A leafref value is encoded the same way as the leaf it references.

9.9.4.  Canonical Form

   The canonical form of a leafref is the same as the canonical form of
   the leaf it references.









Bjorklund                    Standards Track        =
          [Page 125]

 
RFC 6020                  =
        YANG                      October 2010


9.9.5.  Usage Example

   With the following list:

     list interface {
         key "name";
         leaf name {
             type string;
         }
         leaf admin-status {
             type admin-status;
         }
         list address {
             key "ip";
             leaf ip {
                 type yang:ip-address;
             }
         }
     }

   The following leafref refers to an existing interface:

     leaf mgmt-interface {
         type leafref {
             path "../interface/name";
         }
     }

   An example of a corresponding XML snippet:

     <interface>
       <name>eth0</name>
     </interface>
     <interface>
       <name>lo</name>
     </interface>

     <mgmt-interface>eth0</mgmt-interface>













Bjorklund                    Standards Track        =
          [Page 126]

 
RFC 6020                  =
        YANG                      October 2010


   The following leafrefs refer to an existing address of an interface:

     container default-address {
         leaf ifname {
             type leafref {
                 path "../../interface/name";
             }
         }
         leaf address {
             type leafref {
                 path "../../interface[name =3D current()/../ifname]"
                    + "/address/ip";
             }
         }
     }

   An example of a corresponding XML snippet:

     <interface>
       <name>eth0</name>
       <admin-status>up</admin-status>
       <address>
         <ip>192.0.2.1</ip>
       </address>
       <address>
         <ip>192.0.2.2</ip>
       </address>
     </interface>
     <interface>
       <name>lo</name>
       <admin-status>up</admin-status>
       <address>
         <ip>127.0.0.1</ip>
       </address>
     </interface>

     <default-address>
       <ifname>eth0</ifname>
       <address>192.0.2.2</address>
     </default-address>











Bjorklund                    Standards Track        =
          [Page 127]

 
RFC 6020                  =
        YANG                      October 2010


   The following list uses a leafref for one of its keys.  This is
   similar to a foreign key in a relational database.

     list packet-filter {
         key "if-name filter-id";
         leaf if-name {
             type leafref {
                 path "/interface/name";
             }
         }
         leaf filter-id {
             type uint32;
         }
         ...
     }

   An example of a corresponding XML snippet:

     <interface>
       <name>eth0</name>
       <admin-status>up</admin-status>
       <address>
         <ip>192.0.2.1</ip>
       </address>
       <address>
         <ip>192.0.2.2</ip>
       </address>
     </interface>

     <packet-filter>
       <if-name>eth0</if-name>
       <filter-id>1</filter-id>
       ...
     </packet-filter>
     <packet-filter>
       <if-name>eth0</if-name>
       <filter-id>2</filter-id>
       ...
     </packet-filter>












Bjorklund                    Standards Track        =
          [Page 128]

 
RFC 6020                  =
        YANG                      October 2010


   The following notification defines two leafrefs to refer to an
   existing admin-status:

     notification link-failure {
         leaf if-name {
             type leafref {
                 path "/interface/name";
             }
         }
         leaf admin-status {
             type leafref {
                 path
                   "/interface[name =3D current()/../if-name]"
                 + "/admin-status";
             }
         }
     }

   An example of a corresponding XML notification:

     <notification
       xmlns=3D"urn:ietf:params:xml:ns:netconf:notification:1.0">
       <eventTime>2008-04-01T00:01:00Z</eventTime>
       <link-failure xmlns=3D"http://acme.example.com/system">
         <if-name>eth0</if-name>
         <admin-status>up</admin-status>
       </link-failure>
     </notification>

9.10.  The identityref Built-In Type

   The identityref type is used to reference an existing identity (see
   Section 7.16).

9.10.1.  Restrictions

   An identityref cannot be restricted.

9.10.2.  The identityref's base Statement

   The "base" statement, which is a substatement to the "type"
   statement, MUST be present if the type is "identityref".  The
   argument is the name of an identity, as defined by an "identity"
   statement.  If a prefix is present on the identity name, it refers to
   an identity defined in the module that was imported with that prefix.
   Otherwise, an identity with the matching name MUST be defined in the
   current module or an included submodule.




Bjorklund                    Standards Track        =
          [Page 129]

 
RFC 6020                  =
        YANG                      October 2010


   Valid values for an identityref are any identities derived from the
   identityref's base identity.  On a particular server, the valid
   values are further restricted to the set of identities defined in the
   modules supported by the server.

9.10.3.  Lexical Representation

   An identityref is encoded as the referred identity's qualified name
   as defined in [XML-NAMES].  If the prefix is not pre=
sent, the
   namespace of the identityref is the default namespace in effect on
   the element that contains the identityref value.

   When an identityref is given a default value using the "default"
   statement, the identity name in the default value MAY have a prefix.
   If a prefix is present on the identity name, it refers to an identity
   defined in the module that was imported with that prefix.  Otherwise,
   an identity with the matching name MUST be defined in the current
   module or an included submodule.

9.10.4.  Canonical Form

   Since the lexical form depends on the XML context in which the value
   occurs, this type does not have a canonical form.

9.10.5.  Usage Example

   With the identity definitions in Section 7=
=2E16.3 and the following
   module:

     module my-crypto {

         namespace "http://example.com/my-crypto";
         prefix mc;

         import "crypto-base" {
             prefix "crypto";
         }

         identity aes {
             base "crypto:crypto-alg";
         }

         leaf crypto {
             type identityref {
                 base "crypto:crypto-alg";
             }
         }
     }



Bjorklund                    Standards Track        =
          [Page 130]

 
RFC 6020                  =
        YANG                      October 2010


   the leaf "crypto" will be encoded as follows, if the value is the
   "des3" identity defined in the "des" module:

     <crypto xmlns:des=3D"http://example.com/des">des:des3</cryp=
to>

   Any prefixes used in the encoding are local to each instance
   encoding.  This means that the same identityref may be encoded
   differently by different implementations.  For example, the following
   example encodes the same leaf as above:

     <crypto xmlns:x=3D"http://example.com/des">x:des3</crypto&g=
t;

   If the "crypto" leaf's value instead is "aes" defined in the
   "my-crypto" module, it can be encoded as:

     <crypto xmlns:mc=3D"http://example.com/my-crypto">mc:aes</c=
rypto>

   or, using the default namespace:

     <crypto>aes</crypto>

9.11.  The empty Built-In Type

   The empty built-in type represents a leaf that does not have any
   value, it conveys information by its presence or absence.

   An empty type cannot have a default value.

9.11.1.  Restrictions

   An empty type cannot be restricted.

9.11.2.  Lexical Representation

   Not applicable.

9.11.3.  Canonical Form

   Not applicable.

9.11.4.  Usage Example

   The following leaf

     leaf enable-qos {
         type empty;
     }




Bjorklund                    Standards Track        =
          [Page 131]

 
RFC 6020                  =
        YANG                      October 2010


   will be encoded as

     <enable-qos/>

   if it exists.

9.12.  The union Built-In Type

   The union built-in type represents a value that corresponds to one of
   its member types.

   When the type is "union", the "type" statement (Section 7.4) MUST be
   present.  It is used to repeatedly specify each member type of the
   union.  It takes as an argument a string that is the name of a member
   type.

   A member type can be of any built-in or derived type, except it MUST
   NOT be one of the built-in types "empty" or "leafref".

   When a string representing a union data type is validated, the string
   is validated against each member type, in the order they are
   specified in the "type" statement, until a match is found.

   Any default value or "units" property defined in the member types is
   not inherited by the union type.

   Example:

     type union {
         type int32;
         type enumeration {
             enum "unbounded";
         }
     }

9.12.1.  Restrictions

   A union cannot be restricted.  However, each member type can be
   restricted, based on the rules defined in Secti=
on 9.

9.12.2.  Lexical Representation

   The lexical representation of a union is a value that corresponds to
   the representation of any one of the member types.







Bjorklund                    Standards Track        =
          [Page 132]

 
RFC 6020                  =
        YANG                      October 2010


9.12.3.  Canonical Form

   The canonical form of a union value is the same as the canonical form
   of the member type of the value.

9.13.  The instance-identifier Built-In Type

   The instance-identifier built-in type is used to uniquely identify a
   particular instance node in the data tree.

   The syntax for an instance-identifier is a subset of the XPath
   abbreviated syntax, formally defined by the rule
   "instance-identifier" in Section 12.  It i=
s used to uniquely identify
   a node in the data tree.  Predicates are used only for specifying the
   values for the key nodes for list entries, a value of a leaf-list
   entry, or a positional index for a list without keys.  For
   identifying list entries with keys, each predicate consists of one
   equality test per key, and each key MUST have a corresponding
   predicate.

   If the leaf with the instance-identifier type represents
   configuration data, and the "require-instance" property
   (Section 9.13.2) is "true", the node i=
t refers to MUST also represent
   configuration.  Such a leaf puts a constraint on valid data.  All
   such leaf nodes MUST reference existing nodes or leaf nodes with
   their default value in use (see Section 7.6=
=2E1) for the data to be
   valid.  This constraint is enforced according to the rules in
   Section 8.

   The "instance-identifier" XPath expression is conceptually evaluated
   in the following context, in addition to the definition in
   Section 6.4.1:

   o  The context node is the root node in the accessible tree.

   The accessible tree depends on the leaf with the instance-identifier
   type:

   o  If this leaf represents configuration data, the tree is the data
      in the NETCONF datastore where the leaf exists.  The XPath root
      node has all top-level configuration data nodes in all modules as
      children.

   o  Otherwise, the tree is all state data on the device, and the
      <running/> datastore.  The XPath root node has all top-level =
data
      nodes in all modules as children.





Bjorklund                    Standards Track        =
          [Page 133]

 
RFC 6020                  =
        YANG                      October 2010


9.13.1.  Restrictions

   An instance-identifier can be restricted with the "require-instance"
   statement (Section 9.13.2).

9.13.2.  The require-instance Statement

   The "require-instance" statement, which is a substatement to the
   "type" statement, MAY be present if the type is
   "instance-identifier".  It takes as an argument the string "true" or
   "false".  If this statement is not present, it defaults to "true".

   If "require-instance" is "true", it means that the instance being
   referred MUST exist for the data to be valid.  This constraint is
   enforced according to the rules in Section 8.

   If "require-instance" is "false", it means that the instance being
   referred MAY exist in valid data.

9.13.3.  Lexical Representation

   An instance-identifier value is lexically represented as a string.
   All node names in an instance-identifier value MUST be qualified with
   explicit namespace prefixes, and these prefixes MUST be declared in
   the XML namespace scope in the instance-identifier's XML element.

   Any prefixes used in the encoding are local to each instance
   encoding.  This means that the same instance-identifier may be
   encoded differently by different implementations.

9.13.4.  Canonical Form

   Since the lexical form depends on the XML context in which the value
   occurs, this type does not have a canonical form.

9.13.5.  Usage Example

   The following are examples of instance identifiers:

     /* instance-identifier for a container */
     /ex:system/ex:services/ex:ssh

     /* instance-identifier for a leaf */
     /ex:system/ex:services/ex:ssh/ex:port

     /* instance-identifier for a list entry */
     /ex:system/ex:user[ex:name=3D'fred']




Bjorklund                    Standards Track        =
          [Page 134]

 
RFC 6020                  =
        YANG                      October 2010


     /* instance-identifier for a leaf in a list entry */
     /ex:system/ex:user[ex:name=3D'fred']/ex:type

     /* instance-identifier for a list entry with two keys */
     /ex:system/ex:server[ex:ip=3D'192.0.2.1'][ex:port=3D'80']

     /* instance-identifier for a leaf-list entry */
     /ex:system/ex:services/ex:ssh/ex:cipher[.=3D'blowfish-cbc']

     /* instance-identifier for a list entry without keys */
     /ex:stats/ex:port[3]

10.  Updating a Module

   As experience is gained with a module, it may be desirable to revise
   that module.  However, changes are not allowed if they have any
   potential to cause interoperability problems between a client using
   an original specification and a server using an updated
   specification.

   For any published change, a new "revision" statement (Section 7.1.9)
   MUST be included in front of the existing "revision" statements.  If
   there are no existing "revision" statements, then one MUST be added
   to identify the new revision.  Furthermore, any necessary changes
   MUST be applied to any meta-data statements, including the
   "organization" and "contact" statements (Sections 7.1.7, 7.1.8).

   Note that definitions contained in a module are available to be
   imported by any other module, and are referenced in "import"
   statements via the module name.  Thus, a module name MUST NOT be
   changed.  Furthermore, the "namespace" statement MUST NOT be changed,
   since all XML elements are qualified by the namespace.

   Obsolete definitions MUST NOT be removed from modules since their
   identifiers may still be referenced by other modules.

   A definition may be revised in any of the following ways:

   o  An "enumeration" type may have new enums added, provided the old
      enums's values do not change.

   o  A "bits" type may have new bits added, provided the old bit
      positions do not change.

   o  A "range", "length", or "pattern" statement may expand the allowed
      value space.





Bjorklund                    Standards Track        =
          [Page 135]

 
RFC 6020                  =
        YANG                      October 2010


   o  A "default" statement may be added to a leaf that does not have a
      default value (either directly or indirectly through its type).

   o  A "units" statement may be added.

   o  A "reference" statement may be added or updated.

   o  A "must" statement may be removed or its constraint relaxed.

   o  A "mandatory" statement may be removed or changed from "true" to
      "false".

   o  A "min-elements" statement may be removed, or changed to require
      fewer elements.

   o  A "max-elements" statement may be removed, or changed to allow
      more elements.

   o  A "description" statement may be added or clarified without
      changing the semantics of the definition.

   o  New typedefs, groupings, rpcs, notifications, extensions,
      features, and identities may be added.

   o  New data definition statements may be added if they do not add
      mandatory nodes (Section 3.1) to exist=
ing nodes or at the top
      level in a module or submodule, or if they are conditionally
      dependent on a new feature (i.e., have an "if-feature" statement
      that refers to a new feature).

   o  A new "case" statement may be added.

   o  A node that represented state data may be changed to represent
      configuration, provided it is not mandatory (Section 3.1).

   o  An "if-feature" statement may be removed, provided its node is not
      mandatory (Section 3.1).

   o  A "status" statement may be added, or changed from "current" to
      "deprecated" or "obsolete", or from "deprecated" to "obsolete".

   o  A "type" statement may be replaced with another "type" statement
      that does not change the syntax or semantics of the type.  For
      example, an inline type definition may be replaced with a typedef,
      but an int8 type cannot be replaced by an int16, since the syntax
      would change.





Bjorklund                    Standards Track        =
          [Page 136]

 
RFC 6020                  =
        YANG                      October 2010


   o  Any set of data definition nodes may be replaced with another set
      of syntactically and semantically equivalent nodes.  For example,
      a set of leafs may be replaced by a uses of a grouping with the
      same leafs.

   o  A module may be split into a set of submodules, or a submodule may
      be removed, provided the definitions in the module do not change
      in any other way than allowed here.

   o  The "prefix" statement may be changed, provided all local uses of
      the prefix also are changed.

   Otherwise, if the semantics of any previous definition are changed
   (i.e., if a non-editorial change is made to any definition other than
   those specifically allowed above), then this MUST be achieved by a
   new definition with a new identifier.

   In statements that have any data definition statements as
   substatements, those data definition substatements MUST NOT be
   reordered.

11.  YIN

   A YANG module can be translated into an alternative XML-based syntax
   called YIN.  The translated module is called a YIN module.  This
   section describes symmetric mapping rules between the two formats.

   The YANG and YIN formats contain equivalent information using
   different notations.  The YIN notation enables developers to
   represent YANG data models in XML and therefore use the rich set of
   XML-based tools for data filtering and validation, automated
   generation of code and documentation, and other tasks.  Tools like
   XSLT or XML validators can be utilized.

   The mapping between YANG and YIN does not modify the information
   content of the model.  Comments and whitespace are not preserved.

11.1.  Formal YIN Definition

   There is a one-to-one correspondence between YANG keywords and YIN
   elements.  The local name of a YIN element is identical to the
   corresponding YANG keyword.  This means, in particular, that the
   document element (root) of a YIN document is always <module> or
   <submodule>.

   YIN elements corresponding to the YANG keywords belong to the
   namespace whose associated URI is
   "urn:ietf:params:xml:ns:yang:yin:1".



Bjorklund                    Standards Track        =
          [Page 137]

 
RFC 6020                  =
        YANG                      October 2010


   YIN elements corresponding to extension keywords belong to the
   namespace of the YANG module where the extension keyword is declared
   via the "extension" statement.

   The names of all YIN elements MUST be properly qualified with their
   namespaces specified above using the standard mechanisms of
   [XML-NAMES], i.e., "xmlns" and "xmlns:xxx" attribute=
s.

   The argument of a YANG statement is represented in YIN either as an
   XML attribute or a subelement of the keyword element.  Table 1
   defines the mapping for the set of YANG keywords.  For extensions,
   the argument mapping is specified within the "extension" statement
   (see Section 7.17).  The following rules=
 hold for arguments:

   o  If the argument is represented as an attribute, this attribute has
      no namespace.

   o  If the argument is represented as an element, it is qualified by
      the same namespace as its parent keyword element.

   o  If the argument is represented as an element, it MUST be the first
      child of the keyword element.

   Substatements of a YANG statement are represented as (additional)
   children of the keyword element and their relative order MUST be the
   same as the order of substatements in YANG.

   Comments in YANG MAY be mapped to XML comments.























Bjorklund                    Standards Track        =
          [Page 138]

 
RFC 6020                  =
        YANG                      October 2010


               Mapping of arguments of the YANG statements.

            +------------------+---------------+-------------+
            | keyword          | argument name | yin-element |
            +------------------+---------------+-------------+
            | anyxml           | name          | false       |
            | argument         | name          | false       |
            | augment          | target-node   | false       |
            | base             | name          | false       |
            | belongs-to       | module        | false       |
            | bit              | name          | false       |
            | case             | name          | false       |
            | choice           | name          | false       |
            | config           | value         | false       |
            | contact          | text          | true        |
            | container        | name          | false       |
            | default          | value         | false       |
            | description      | text          | true        |
            | deviate          | value         | false       |
            | deviation        | target-node   | false       |
            | enum             | name          | false       |
            | error-app-tag    | value         | false       |
            | error-message    | value         | true        |
            | extension        | name          | false       |
            | feature          | name          | false       |
            | fraction-digits  | value         | false       |
            | grouping         | name          | false       |
            | identity         | name          | false       |
            | if-feature       | name          | false       |
            | import           | module        | false       |
            | include          | module        | false       |
            | input            | <no argument> | n/a         |
            | key              | value         | false       |
            | leaf             | name          | false       |
            | leaf-list        | name          | false       |
            | length           | value         | false       |
            | list             | name          | false       |
            | mandatory        | value         | false       |
            | max-elements     | value         | false       |
            | min-elements     | value         | false       |
            | module           | name          | false       |
            | must             | condition     | false       |
            | namespace        | uri           | false       |
            | notification     | name          | false       |
            | ordered-by       | value         | false       |
            | organization     | text          | true        |
            | output           | <no argument> | n/a         |
            | path             | value         | false       |



Bjorklund                    Standards Track        =
          [Page 139]

 
RFC 6020                  =
        YANG                      October 2010


            | pattern          | value         | false       |
            | position         | value         | false       |
            | prefix           | value         | false       |
            | presence         | value         | false       |
            | range            | value         | false       |
            | reference        | text          | true        |
            | refine           | target-node   | false       |
            | require-instance | value         | false       |
            | revision         | date          | false       |
            | revision-date    | date          | false       |
            | rpc              | name          | false       |
            | status           | value         | false       |
            | submodule        | name          | false       |
            | type             | name          | false       |
            | typedef          | name          | false       |
            | unique           | tag           | false       |
            | units            | name          | false       |
            | uses             | name          | false       |
            | value            | value         | false       |
            | when             | condition     | false       |
            | yang-version     | value         | false       |
            | yin-element      | value         | false       |
            +------------------+---------------+-------------+

                                  Table 1


























Bjorklund                    Standards Track        =
          [Page 140]

 
RFC 6020                  =
        YANG                      October 2010


11.1.1.  Usage Example

   The following YANG module:

     module acme-foo {
         namespace "http://acme.example.com/foo";
         prefix "acfoo";

         import my-extensions {
             prefix "myext";
         }

         list interface {
             key "name";
             leaf name {
                 type string;
             }

             leaf mtu {
                 type uint32;
                 description "The MTU of the interface.";
                 myext:c-define "MY_MTU";
             }
         }
     }

   where the extension "c-define" is defined in Section 7.17.3, is
   translated into the following YIN:























Bjorklund                    Standards Track        =
          [Page 141]

 
RFC 6020                  =
        YANG                      October 2010


     <module name=3D"acme-foo"
             xmlns=3D"urn:ietf:params:xml:ns:yang:yin:1"
             xmlns:acfoo=3D"http://acme.example.com/foo"
             xmlns:myext=3D"http://example.com/my-extensions">

       <namespace uri=3D"http://acme.example.com/foo"/>
       <prefix value=3D"acfoo"/>

       <import module=3D"my-extensions">
         <prefix value=3D"myext"/>
       </import>

       <list name=3D"interface">
         <key value=3D"name"/>
         <leaf name=3D"name">
           <type name=3D"string"/>
         </leaf>
         <leaf name=3D"mtu">
           <type name=3D"uint32"/>
           <description>
             <text>The MTU of the interface.</text>
           </description>
           <myext:c-define name=3D"MY_MTU"/>
         </leaf>
       </list>
     </module>

























Bjorklund                    Standards Track        =
          [Page 142]

 
RFC 6020                  =
        YANG                      October 2010


12.  YANG ABNF Grammar

   In YANG, almost all statements are unordered.  The ABNF grammar
   [RFC5234] defines the canonical order.  To improv=
e module
   readability, it is RECOMMENDED that clauses be entered in this order.

   Within the ABNF grammar, unordered statements are marked with
   comments.

   This grammar assumes that the scanner replaces YANG comments with a
   single space character.

   <CODE BEGINS> file "yang.abnf"

   module-stmt         =3D optsep module-keyword sep identifier-arg-str
                         optsep
                         "{" stmtsep
                             module-header-stmts
                             linkage-stmts
                             meta-stmts
                             revision-stmts
                             body-stmts
                         "}" optsep

   submodule-stmt      =3D optsep submodule-keyword sep identifier-arg-st=
r
                         optsep
                         "{" stmtsep
                             submodule-header-stmts
                             linkage-stmts
                             meta-stmts
                             revision-stmts
                             body-stmts
                         "}" optsep

   module-header-stmts =3D ;; these stmts can appear in any order
                         [yang-version-stmt stmtsep]
                          namespace-stmt stmtsep
                          prefix-stmt stmtsep

   submodule-header-stmts =3D
                         ;; these stmts can appear in any order
                         [yang-version-stmt stmtsep]
                          belongs-to-stmt stmtsep








Bjorklund                    Standards Track        =
          [Page 143]

 
RFC 6020                  =
        YANG                      October 2010


   meta-stmts          =3D ;; these stmts can appear in any order
                         [organization-stmt stmtsep]
                         [contact-stmt stmtsep]
                         [description-stmt stmtsep]
                         [reference-stmt stmtsep]

   linkage-stmts       =3D ;; these stmts can appear in any order
                         *(import-stmt stmtsep)
                         *(include-stmt stmtsep)

   revision-stmts      =3D *(revision-stmt stmtsep)

   body-stmts          =3D *((extension-stmt /
                            feature-stmt /
                            identity-stmt /
                            typedef-stmt /
                            grouping-stmt /
                            data-def-stmt /
                            augment-stmt /
                            rpc-stmt /
                            notification-stmt /
                            deviation-stmt) stmtsep)

   data-def-stmt       =3D container-stmt /
                         leaf-stmt /
                         leaf-list-stmt /
                         list-stmt /
                         choice-stmt /
                         anyxml-stmt /
                         uses-stmt

   yang-version-stmt   =3D yang-version-keyword sep yang-version-arg-str
                         optsep stmtend

   yang-version-arg-str =3D < a string that matches the rule
                           yang-version-arg >

   yang-version-arg    =3D "1"

   import-stmt         =3D import-keyword sep identifier-arg-str optsep
                         "{" stmtsep
                             prefix-stmt stmtsep
                             [revision-date-stmt stmtsep]
                         "}"







Bjorklund                    Standards Track        =
          [Page 144]

 
RFC 6020                  =
        YANG                      October 2010


   include-stmt        =3D include-keyword sep identifier-arg-str optsep
                         (";" /
                          "{" stmtsep
                              [revision-date-stmt stmtsep]
                          "}")

   namespace-stmt      =3D namespace-keyword sep uri-str optsep stmtend

   uri-str             =3D < a string that matches the rule
                           URI in RFC 3986 >=


   prefix-stmt         =3D prefix-keyword sep prefix-arg-str
                         optsep stmtend

   belongs-to-stmt     =3D belongs-to-keyword sep identifier-arg-str
                         optsep
                         "{" stmtsep
                             prefix-stmt stmtsep
                         "}"

   organization-stmt   =3D organization-keyword sep string
                         optsep stmtend

   contact-stmt        =3D contact-keyword sep string optsep stmtend

   description-stmt    =3D description-keyword sep string optsep
                         stmtend

   reference-stmt      =3D reference-keyword sep string optsep stmtend

   units-stmt          =3D units-keyword sep string optsep stmtend

   revision-stmt       =3D revision-keyword sep revision-date optsep
                         (";" /
                          "{" stmtsep
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                          "}")

   revision-date       =3D  date-arg-str

   revision-date-stmt =3D revision-date-keyword sep revision-date stmtend=










Bjorklund                    Standards Track        =
          [Page 145]

 
RFC 6020                  =
        YANG                      October 2010


   extension-stmt      =3D extension-keyword sep identifier-arg-str optse=
p
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [argument-stmt stmtsep]
                              [status-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                          "}")

   argument-stmt       =3D argument-keyword sep identifier-arg-str optsep=

                         (";" /
                          "{" stmtsep
                              [yin-element-stmt stmtsep]
                          "}")

   yin-element-stmt    =3D yin-element-keyword sep yin-element-arg-str
                         stmtend

   yin-element-arg-str =3D < a string that matches the rule
                           yin-element-arg >

   yin-element-arg     =3D true-keyword / false-keyword

   identity-stmt       =3D identity-keyword sep identifier-arg-str optsep=

                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [base-stmt stmtsep]
                              [status-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                          "}")

   base-stmt           =3D base-keyword sep identifier-ref-arg-str
                         optsep stmtend

   feature-stmt        =3D feature-keyword sep identifier-arg-str optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              *(if-feature-stmt stmtsep)
                              [status-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                          "}")





Bjorklund                    Standards Track        =
          [Page 146]

 
RFC 6020                  =
        YANG                      October 2010


   if-feature-stmt     =3D if-feature-keyword sep identifier-ref-arg-str
                         optsep stmtend

   typedef-stmt        =3D typedef-keyword sep identifier-arg-str optsep
                         "{" stmtsep
                             ;; these stmts can appear in any order
                             type-stmt stmtsep
                             [units-stmt stmtsep]
                             [default-stmt stmtsep]
                             [status-stmt stmtsep]
                             [description-stmt stmtsep]
                             [reference-stmt stmtsep]
                          "}"

   type-stmt           =3D type-keyword sep identifier-ref-arg-str optsep=

                         (";" /
                          "{" stmtsep
                              type-body-stmts
                          "}")

   type-body-stmts     =3D numerical-restrictions /
                         decimal64-specification /
                         string-restrictions /
                         enum-specification /
                         leafref-specification /
                         identityref-specification /
                         instance-identifier-specification /
                         bits-specification /
                         union-specification

   numerical-restrictions =3D range-stmt stmtsep

   range-stmt          =3D range-keyword sep range-arg-str optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [error-message-stmt stmtsep]
                              [error-app-tag-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                           "}")

   decimal64-specification =3D fraction-digits-stmt

   fraction-digits-stmt =3D fraction-digits-keyword sep
                          fraction-digits-arg-str stmtend





Bjorklund                    Standards Track        =
          [Page 147]

 
RFC 6020                  =
        YANG                      October 2010


   fraction-digits-arg-str =3D < a string that matches the rule
                              fraction-digits-arg >

   fraction-digits-arg =3D ("1" ["0" / "1" / "2" / "3" / "4" /
                               "5" / "6" / "7" / "8"])
                         / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"

   string-restrictions =3D ;; these stmts can appear in any order
                         [length-stmt stmtsep]
                         *(pattern-stmt stmtsep)

   length-stmt         =3D length-keyword sep length-arg-str optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [error-message-stmt stmtsep]
                              [error-app-tag-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                           "}")

   pattern-stmt        =3D pattern-keyword sep string optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [error-message-stmt stmtsep]
                              [error-app-tag-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                           "}")

   default-stmt        =3D default-keyword sep string stmtend

   enum-specification  =3D 1*(enum-stmt stmtsep)

   enum-stmt           =3D enum-keyword sep string optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [value-stmt stmtsep]
                              [status-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                           "}")







Bjorklund                    Standards Track        =
          [Page 148]

 
RFC 6020                  =
        YANG                      October 2010


   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

   require-instance-arg-str =3D < a string that matches the rule
                              require-instance-arg >

   require-instance-arg =3D true-keyword / false-keyword


   instance-identifier-specification =3D
                         [require-instance-stmt stmtsep]

   identityref-specification =3D
                         base-stmt stmtsep

   union-specification =3D 1*(type-stmt stmtsep)

   bits-specification  =3D 1*(bit-stmt stmtsep)

   bit-stmt            =3D bit-keyword sep identifier-arg-str optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [position-stmt stmtsep]
                              [status-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                            "}"
                          "}")

   position-stmt       =3D position-keyword sep
                         position-value-arg-str stmtend

   position-value-arg-str =3D < a string that matches the rule
                              position-value-arg >

   position-value-arg  =3D non-negative-integer-value

   status-stmt         =3D status-keyword sep status-arg-str stmtend





Bjorklund                    Standards Track        =
          [Page 149]

 
RFC 6020                  =
        YANG                      October 2010


   status-arg-str      =3D < a string that matches the rule
                           status-arg >

   status-arg          =3D current-keyword /
                         obsolete-keyword /
                         deprecated-keyword

   config-stmt         =3D config-keyword sep
                         config-arg-str stmtend

   config-arg-str      =3D < a string that matches the rule
                           config-arg >

   config-arg          =3D true-keyword / false-keyword

   mandatory-stmt      =3D mandatory-keyword sep
                         mandatory-arg-str stmtend

   mandatory-arg-str   =3D < a string that matches the rule
                           mandatory-arg >

   mandatory-arg       =3D true-keyword / false-keyword

   presence-stmt       =3D presence-keyword sep string stmtend

   ordered-by-stmt     =3D ordered-by-keyword sep
                         ordered-by-arg-str stmtend

   ordered-by-arg-str  =3D < a string that matches the rule
                           ordered-by-arg >

   ordered-by-arg      =3D user-keyword / system-keyword

   must-stmt           =3D must-keyword sep string optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [error-message-stmt stmtsep]
                              [error-app-tag-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                           "}")

   error-message-stmt  =3D error-message-keyword sep string stmtend

   error-app-tag-stmt  =3D error-app-tag-keyword sep string stmtend





Bjorklund                    Standards Track        =
          [Page 150]

 
RFC 6020                  =
        YANG                      October 2010


   min-elements-stmt   =3D min-elements-keyword sep
                         min-value-arg-str stmtend

   min-value-arg-str   =3D < a string that matches the rule
                           min-value-arg >

   min-value-arg       =3D non-negative-integer-value

   max-elements-stmt   =3D max-elements-keyword sep
                         max-value-arg-str stmtend

   max-value-arg-str   =3D < a string that matches the rule
                           max-value-arg >

   max-value-arg       =3D unbounded-keyword /
                         positive-integer-value

   value-stmt          =3D value-keyword sep integer-value stmtend

   grouping-stmt       =3D grouping-keyword sep identifier-arg-str optsep=

                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [status-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                              *((typedef-stmt /
                                 grouping-stmt) stmtsep)
                              *(data-def-stmt stmtsep)
                          "}")

   container-stmt      =3D container-keyword sep identifier-arg-str optse=
p
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [when-stmt stmtsep]
                              *(if-feature-stmt stmtsep)
                              *(must-stmt stmtsep)
                              [presence-stmt stmtsep]
                              [config-stmt stmtsep]
                              [status-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                              *((typedef-stmt /
                                 grouping-stmt) stmtsep)
                              *(data-def-stmt stmtsep)
                          "}")




Bjorklund                    Standards Track        =
          [Page 151]

 
RFC 6020                  =
        YANG                      October 2010


   leaf-stmt           =3D leaf-keyword sep identifier-arg-str optsep
                         "{" stmtsep
                             ;; these stmts can appear in any order
                             [when-stmt stmtsep]
                             *(if-feature-stmt stmtsep)
                             type-stmt stmtsep
                             [units-stmt stmtsep]
                             *(must-stmt stmtsep)
                             [default-stmt stmtsep]
                             [config-stmt stmtsep]
                             [mandatory-stmt stmtsep]
                             [status-stmt stmtsep]
                             [description-stmt stmtsep]
                             [reference-stmt stmtsep]
                          "}"

   leaf-list-stmt      =3D leaf-list-keyword sep identifier-arg-str optse=
p
                         "{" stmtsep
                             ;; these stmts can appear in any order
                             [when-stmt stmtsep]
                             *(if-feature-stmt stmtsep)
                             type-stmt stmtsep
                             [units-stmt stmtsep]
                             *(must-stmt stmtsep)
                             [config-stmt stmtsep]
                             [min-elements-stmt stmtsep]
                             [max-elements-stmt stmtsep]
                             [ordered-by-stmt stmtsep]
                             [status-stmt stmtsep]
                             [description-stmt stmtsep]
                             [reference-stmt stmtsep]
                          "}"

   list-stmt           =3D list-keyword sep identifier-arg-str optsep
                         "{" stmtsep
                             ;; these stmts can appear in any order
                             [when-stmt stmtsep]
                             *(if-feature-stmt stmtsep)
                             *(must-stmt stmtsep)
                             [key-stmt stmtsep]
                             *(unique-stmt stmtsep)
                             [config-stmt stmtsep]
                             [min-elements-stmt stmtsep]
                             [max-elements-stmt stmtsep]
                             [ordered-by-stmt stmtsep]
                             [status-stmt stmtsep]
                             [description-stmt stmtsep]
                             [reference-stmt stmtsep]



Bjorklund                    Standards Track        =
          [Page 152]

 
RFC 6020                  =
        YANG                      October 2010


                             *((typedef-stmt /
                                grouping-stmt) stmtsep)
                             1*(data-def-stmt stmtsep)
                          "}"

   key-stmt            =3D key-keyword sep key-arg-str stmtend

   key-arg-str         =3D < a string that matches the rule
                           key-arg >

   key-arg             =3D node-identifier *(sep node-identifier)

   unique-stmt         =3D unique-keyword sep unique-arg-str stmtend

   unique-arg-str      =3D < a string that matches the rule
                           unique-arg >

   unique-arg          =3D descendant-schema-nodeid
                         *(sep descendant-schema-nodeid)

   choice-stmt         =3D choice-keyword sep identifier-arg-str optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [when-stmt stmtsep]
                              *(if-feature-stmt stmtsep)
                              [default-stmt stmtsep]
                              [config-stmt stmtsep]
                              [mandatory-stmt stmtsep]
                              [status-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                              *((short-case-stmt / case-stmt) stmtsep)
                          "}")

   short-case-stmt     =3D container-stmt /
                         leaf-stmt /
                         leaf-list-stmt /
                         list-stmt /
                         anyxml-stmt

   case-stmt           =3D case-keyword sep identifier-arg-str optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [when-stmt stmtsep]
                              *(if-feature-stmt stmtsep)
                              [status-stmt stmtsep]



Bjorklund                    Standards Track        =
          [Page 153]

 
RFC 6020                  =
        YANG                      October 2010


                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                              *(data-def-stmt stmtsep)
                          "}")

   anyxml-stmt         =3D anyxml-keyword sep identifier-arg-str optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [when-stmt stmtsep]
                              *(if-feature-stmt stmtsep)
                              *(must-stmt stmtsep)
                              [config-stmt stmtsep]
                              [mandatory-stmt stmtsep]
                              [status-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                           "}")

   uses-stmt           =3D uses-keyword sep identifier-ref-arg-str optsep=

                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [when-stmt stmtsep]
                              *(if-feature-stmt stmtsep)
                              [status-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                              *(refine-stmt stmtsep)
                              *(uses-augment-stmt stmtsep)
                          "}")

   refine-stmt         =3D refine-keyword sep refine-arg-str optsep
                         (";" /
                          "{" stmtsep
                              (refine-container-stmts /
                               refine-leaf-stmts /
                               refine-leaf-list-stmts /
                               refine-list-stmts /
                               refine-choice-stmts /
                               refine-case-stmts /
                               refine-anyxml-stmts)
                          "}")

   refine-arg-str      =3D < a string that matches the rule
                           refine-arg >

   refine-arg          =3D descendant-schema-nodeid



Bjorklund                    Standards Track        =
          [Page 154]

 
RFC 6020                  =
        YANG                      October 2010


   refine-container-stmts =3D
                         ;; these stmts can appear in any order
                         *(must-stmt stmtsep)
                         [presence-stmt stmtsep]
                         [config-stmt stmtsep]
                         [description-stmt stmtsep]
                         [reference-stmt stmtsep]

   refine-leaf-stmts   =3D ;; these stmts can appear in any order
                         *(must-stmt stmtsep)
                         [default-stmt stmtsep]
                         [config-stmt stmtsep]
                         [mandatory-stmt stmtsep]
                         [description-stmt stmtsep]
                         [reference-stmt stmtsep]

   refine-leaf-list-stmts =3D
                         ;; these stmts can appear in any order
                         *(must-stmt stmtsep)
                         [config-stmt stmtsep]
                         [min-elements-stmt stmtsep]
                         [max-elements-stmt stmtsep]
                         [description-stmt stmtsep]
                         [reference-stmt stmtsep]

   refine-list-stmts   =3D ;; these stmts can appear in any order
                         *(must-stmt stmtsep)
                         [config-stmt stmtsep]
                         [min-elements-stmt stmtsep]
                         [max-elements-stmt stmtsep]
                         [description-stmt stmtsep]
                         [reference-stmt stmtsep]

   refine-choice-stmts =3D ;; these stmts can appear in any order
                         [default-stmt stmtsep]
                         [config-stmt stmtsep]
                         [mandatory-stmt stmtsep]
                         [description-stmt stmtsep]
                         [reference-stmt stmtsep]

   refine-case-stmts   =3D ;; these stmts can appear in any order
                         [description-stmt stmtsep]
                         [reference-stmt stmtsep]


   refine-anyxml-stmts =3D ;; these stmts can appear in any order
                         *(must-stmt stmtsep)
                         [config-stmt stmtsep]



Bjorklund                    Standards Track        =
          [Page 155]

 
RFC 6020                  =
        YANG                      October 2010


                         [mandatory-stmt stmtsep]
                         [description-stmt stmtsep]
                         [reference-stmt stmtsep]

   uses-augment-stmt   =3D augment-keyword sep uses-augment-arg-str optse=
p
                         "{" stmtsep
                             ;; these stmts can appear in any order
                             [when-stmt stmtsep]
                             *(if-feature-stmt stmtsep)
                             [status-stmt stmtsep]
                             [description-stmt stmtsep]
                             [reference-stmt stmtsep]
                             1*((data-def-stmt stmtsep) /
                                (case-stmt stmtsep))
                          "}"

   uses-augment-arg-str =3D < a string that matches the rule
                            uses-augment-arg >

   uses-augment-arg    =3D descendant-schema-nodeid

   augment-stmt        =3D augment-keyword sep augment-arg-str optsep
                         "{" stmtsep
                             ;; these stmts can appear in any order
                             [when-stmt stmtsep]
                             *(if-feature-stmt stmtsep)
                             [status-stmt stmtsep]
                             [description-stmt stmtsep]
                             [reference-stmt stmtsep]
                             1*((data-def-stmt stmtsep) /
                                (case-stmt stmtsep))
                          "}"

   augment-arg-str     =3D < a string that matches the rule
                           augment-arg >

   augment-arg         =3D absolute-schema-nodeid

   unknown-statement   =3D prefix ":" identifier [sep string] optsep
                         (";" / "{" *unknown-statement2 "}")

   unknown-statement2   =3D [prefix ":"] identifier [sep string] optsep
                         (";" / "{" *unknown-statement2 "}")

   when-stmt           =3D when-keyword sep string optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order



Bjorklund                    Standards Track        =
          [Page 156]

 
RFC 6020                  =
        YANG                      October 2010


                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                           "}")

   rpc-stmt            =3D rpc-keyword sep identifier-arg-str optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              *(if-feature-stmt stmtsep)
                              [status-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                              *((typedef-stmt /
                                 grouping-stmt) stmtsep)
                              [input-stmt stmtsep]
                              [output-stmt stmtsep]
                          "}")

   input-stmt          =3D input-keyword optsep
                         "{" stmtsep
                             ;; these stmts can appear in any order
                             *((typedef-stmt /
                                grouping-stmt) stmtsep)
                             1*(data-def-stmt stmtsep)
                         "}"

   output-stmt         =3D output-keyword optsep
                         "{" stmtsep
                             ;; these stmts can appear in any order
                             *((typedef-stmt /
                                grouping-stmt) stmtsep)
                             1*(data-def-stmt stmtsep)
                         "}"

   notification-stmt   =3D notification-keyword sep
                         identifier-arg-str optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              *(if-feature-stmt stmtsep)
                              [status-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                              *((typedef-stmt /
                                 grouping-stmt) stmtsep)
                              *(data-def-stmt stmtsep)
                          "}")




Bjorklund                    Standards Track        =
          [Page 157]

 
RFC 6020                  =
        YANG                      October 2010


   deviation-stmt      =3D deviation-keyword sep
                         deviation-arg-str optsep
                         "{" stmtsep
                             ;; these stmts can appear in any order
                             [description-stmt stmtsep]
                             [reference-stmt stmtsep]
                             (deviate-not-supported-stmt /
                               1*(deviate-add-stmt /
                                  deviate-replace-stmt /
                                  deviate-delete-stmt))
                         "}"

   deviation-arg-str   =3D < a string that matches the rule
                           deviation-arg >

   deviation-arg       =3D absolute-schema-nodeid

   deviate-not-supported-stmt =3D
                         deviate-keyword sep
                         not-supported-keyword optsep
                         (";" /
                          "{" stmtsep
                          "}")

   deviate-add-stmt    =3D deviate-keyword sep add-keyword optsep
                         (";" /
                          "{" stmtsep
                              [units-stmt stmtsep]
                              *(must-stmt stmtsep)
                              *(unique-stmt stmtsep)
                              [default-stmt stmtsep]
                              [config-stmt stmtsep]
                              [mandatory-stmt stmtsep]
                              [min-elements-stmt stmtsep]
                              [max-elements-stmt stmtsep]
                          "}")

   deviate-delete-stmt =3D deviate-keyword sep delete-keyword optsep
                         (";" /
                          "{" stmtsep
                              [units-stmt stmtsep]
                              *(must-stmt stmtsep)
                              *(unique-stmt stmtsep)
                              [default-stmt stmtsep]
                          "}")






Bjorklund                    Standards Track        =
          [Page 158]

 
RFC 6020                  =
        YANG                      October 2010


   deviate-replace-stmt =3D deviate-keyword sep replace-keyword optsep
                         (";" /
                          "{" stmtsep
                              [type-stmt stmtsep]
                              [units-stmt stmtsep]
                              [default-stmt stmtsep]
                              [config-stmt stmtsep]
                              [mandatory-stmt stmtsep]
                              [min-elements-stmt stmtsep]
                              [max-elements-stmt stmtsep]
                          "}")

   ;; Ranges

   range-arg-str       =3D < a string that matches the rule
                           range-arg >

   range-arg           =3D range-part *(optsep "|" optsep range-part)

   range-part          =3D range-boundary
                         [optsep ".." optsep range-boundary]

   range-boundary      =3D min-keyword / max-keyword /
                         integer-value / decimal-value

   ;; Lengths

   length-arg-str      =3D < a string that matches the rule
                           length-arg >

   length-arg          =3D length-part *(optsep "|" optsep length-part)

   length-part         =3D length-boundary
                         [optsep ".." optsep length-boundary]

   length-boundary     =3D min-keyword / max-keyword /
                         non-negative-integer-value

   ;; Date

   date-arg-str        =3D < a string that matches the rule
                           date-arg >

   date-arg            =3D 4DIGIT "-" 2DIGIT "-" 2DIGIT







Bjorklund                    Standards Track        =
          [Page 159]

 
RFC 6020                  =
        YANG                      October 2010


   ;; Schema Node Identifiers

   schema-nodeid       =3D absolute-schema-nodeid /
                         descendant-schema-nodeid

   absolute-schema-nodeid =3D 1*("/" node-identifier)

   descendant-schema-nodeid =3D
                         node-identifier
                         absolute-schema-nodeid

   node-identifier     =3D [prefix ":"] identifier


   ;; Instance Identifiers

   instance-identifier =3D 1*("/" (node-identifier *predicate))

   predicate           =3D "[" *WSP (predicate-expr / pos) *WSP "]"

   predicate-expr      =3D (node-identifier / ".") *WSP "=3D" *WSP
                         ((DQUOTE string DQUOTE) /
                          (SQUOTE string SQUOTE))

   pos                 =3D non-negative-integer-value

   ;; leafref path

   path-arg-str        =3D < a string that matches the rule
                           path-arg >

   path-arg            =3D absolute-path / relative-path

   absolute-path       =3D 1*("/" (node-identifier *path-predicate))

   relative-path       =3D 1*(".." "/") descendant-path

   descendant-path     =3D node-identifier
                         [*path-predicate absolute-path]

   path-predicate      =3D "[" *WSP path-equality-expr *WSP "]"

   path-equality-expr  =3D node-identifier *WSP "=3D" *WSP path-key-expr

   path-key-expr       =3D current-function-invocation *WSP "/" *WSP
                         rel-path-keyexpr





Bjorklund                    Standards Track        =
          [Page 160]

 
RFC 6020                  =
        YANG                      October 2010


   rel-path-keyexpr    =3D 1*(".." *WSP "/" *WSP)
                         *(node-identifier *WSP "/" *WSP)
                         node-identifier

   ;;; Keywords, using abnfgen's syntax for case-sensitive strings

   ;; statement keywords
   anyxml-keyword      =3D 'anyxml'
   argument-keyword    =3D 'argument'
   augment-keyword     =3D 'augment'
   base-keyword        =3D 'base'
   belongs-to-keyword  =3D 'belongs-to'
   bit-keyword         =3D 'bit'
   case-keyword        =3D 'case'
   choice-keyword      =3D 'choice'
   config-keyword      =3D 'config'
   contact-keyword     =3D 'contact'
   container-keyword   =3D 'container'
   default-keyword     =3D 'default'
   description-keyword =3D 'description'
   enum-keyword        =3D 'enum'
   error-app-tag-keyword =3D 'error-app-tag'
   error-message-keyword =3D 'error-message'
   extension-keyword   =3D 'extension'
   deviation-keyword   =3D 'deviation'
   deviate-keyword     =3D 'deviate'
   feature-keyword     =3D 'feature'
   fraction-digits-keyword =3D 'fraction-digits'
   grouping-keyword    =3D 'grouping'
   identity-keyword    =3D 'identity'
   if-feature-keyword  =3D 'if-feature'
   import-keyword      =3D 'import'
   include-keyword     =3D 'include'
   input-keyword       =3D 'input'
   key-keyword         =3D 'key'
   leaf-keyword        =3D 'leaf'
   leaf-list-keyword   =3D 'leaf-list'
   length-keyword      =3D 'length'
   list-keyword        =3D 'list'
   mandatory-keyword   =3D 'mandatory'
   max-elements-keyword =3D 'max-elements'
   min-elements-keyword =3D 'min-elements'
   module-keyword      =3D 'module'
   must-keyword        =3D 'must'
   namespace-keyword   =3D 'namespace'
   notification-keyword=3D 'notification'
   ordered-by-keyword  =3D 'ordered-by'
   organization-keyword=3D 'organization'



Bjorklund                    Standards Track        =
          [Page 161]

 
RFC 6020                  =
        YANG                      October 2010


   output-keyword      =3D 'output'
   path-keyword        =3D 'path'
   pattern-keyword     =3D 'pattern'
   position-keyword    =3D 'position'
   prefix-keyword      =3D 'prefix'
   presence-keyword    =3D 'presence'
   range-keyword       =3D 'range'
   reference-keyword   =3D 'reference'
   refine-keyword      =3D 'refine'
   require-instance-keyword =3D 'require-instance'
   revision-keyword    =3D 'revision'
   revision-date-keyword =3D 'revision-date'
   rpc-keyword         =3D 'rpc'
   status-keyword      =3D 'status'
   submodule-keyword   =3D 'submodule'
   type-keyword        =3D 'type'
   typedef-keyword     =3D 'typedef'
   unique-keyword      =3D 'unique'
   units-keyword       =3D 'units'
   uses-keyword        =3D 'uses'
   value-keyword       =3D 'value'
   when-keyword        =3D 'when'
   yang-version-keyword=3D 'yang-version'
   yin-element-keyword =3D 'yin-element'

   ;; other keywords

   add-keyword         =3D 'add'
   current-keyword     =3D 'current'
   delete-keyword      =3D 'delete'
   deprecated-keyword  =3D 'deprecated'
   false-keyword       =3D 'false'
   max-keyword         =3D 'max'
   min-keyword         =3D 'min'
   not-supported-keyword =3D 'not-supported'
   obsolete-keyword    =3D 'obsolete'
   replace-keyword     =3D 'replace'
   system-keyword      =3D 'system'
   true-keyword        =3D 'true'
   unbounded-keyword   =3D 'unbounded'
   user-keyword        =3D 'user'










Bjorklund                    Standards Track        =
          [Page 162]

 
RFC 6020                  =
        YANG                      October 2010


   current-function-invocation =3D current-keyword *WSP "(" *WSP ")"

   ;; Basic Rules

   prefix-arg-str      =3D < a string that matches the rule
                           prefix-arg >

   prefix-arg          =3D prefix

   prefix              =3D identifier

   identifier-arg-str  =3D < a string that matches the rule
                           identifier-arg >

   identifier-arg      =3D identifier

   ;; An identifier MUST NOT start with (('X'|'x') ('M'|'m') ('L'|'l'))
   identifier          =3D (ALPHA / "_")
                         *(ALPHA / DIGIT / "_" / "-" / ".")

   identifier-ref-arg-str =3D < a string that matches the rule
                           identifier-ref-arg >

   identifier-ref-arg  =3D [prefix ":"] identifier

   string              =3D < an unquoted string as returned by
                           the scanner >

   integer-value       =3D ("-" non-negative-integer-value)  /
                          non-negative-integer-value

   non-negative-integer-value =3D "0" / positive-integer-value

   positive-integer-value =3D (non-zero-digit *DIGIT)

   zero-integer-value  =3D 1*DIGIT

   stmtend             =3D ";" / "{" *unknown-statement "}"

   sep                 =3D 1*(WSP / line-break)
                         ; unconditional separator

   optsep              =3D *(WSP / line-break)

   stmtsep             =3D *(WSP / line-break / unknown-statement)

   line-break          =3D CRLF / LF




Bjorklund                    Standards Track        =
          [Page 163]

 
RFC 6020                  =
        YANG                      October 2010


   non-zero-digit      =3D %x31-39

   decimal-value       =3D integer-value ("." zero-integer-value)

   SQUOTE              =3D %x27
                         ; ' (Single Quote)

   ;;
   ;; RFC 5234 core rules.
   ;;

   ALPHA               =3D %x41-5A / %x61-7A
                         ; A-Z / a-z

   CR                  =3D %x0D
                         ; carriage return

   CRLF                =3D CR LF
                         ; Internet standard new line

   DIGIT               =3D %x30-39
                         ; 0-9

   DQUOTE              =3D %x22
                         ; " (Double Quote)

   HEXDIG              =3D DIGIT /
                         %x61 / %x62 / %x63 / %x64 / %x65 / %x66
                         ; only lower-case a..f

   HTAB                =3D %x09
                         ; horizontal tab

   LF                  =3D %x0A
                         ; linefeed

   SP                  =3D %x20
                         ; space

   VCHAR               =3D %x21-7E
                         ; visible (printing) characters

   WSP                 =3D SP / HTAB
                         ; whitespace

   <CODE ENDS>





Bjorklund                    Standards Track        =
          [Page 164]

 
RFC 6020                  =
        YANG                      October 2010


13.  Error Responses for YANG Related Errors

   A number of NETCONF error responses are defined for error cases
   related to the data-model handling.  If the relevant YANG statement
   has an "error-app-tag" substatement, that overrides the default value
   specified below.

13.1.  Error Message for Data That Violates a unique Sta=
tement

   If a NETCONF operation would result in configuration data where a
   unique constraint is invalidated, the following error is returned:

     error-tag:      operation-failed
     error-app-tag:  data-not-unique
     error-info:     <non-unique>: Contains an instance identifier =
that
                     points to a leaf that invalidates the unique
                     constraint. This element is present once for each
                     non-unique leaf.

                     The <non-unique> element is in the YANG
                     namespace ("urn:ietf:params:xml:ns:yang:1").

13.2.  Error Message for Data That Violates a max-elemen=
ts Statement

   If a NETCONF operation would result in configuration data where a
   list or a leaf-list would have too many entries the following error
   is returned:

     error-tag:      operation-failed
     error-app-tag:  too-many-elements

   This error is returned once, with the error-path identifying the list
   node, even if there are more than one extra child present.

13.3.  Error Message for Data That Violates a min-elemen=
ts Statement

   If a NETCONF operation would result in configuration data where a
   list or a leaf-list would have too few entries the following error is
   returned:

     error-tag:      operation-failed
     error-app-tag:  too-few-elements

   This error is returned once, with the error-path identifying the list
   node, even if there are more than one child missing.






Bjorklund                    Standards Track        =
          [Page 165]

 
RFC 6020                  =
        YANG                      October 2010


13.4.  Error Message for Data That Violates a must State=
ment

   If a NETCONF operation would result in configuration data where the
   restrictions imposed by a "must" statement is violated the following
   error is returned, unless a specific "error-app-tag" substatement is
   present for the "must" statement.

     error-tag:      operation-failed
     error-app-tag:  must-violation

13.5.  Error Message for Data That Violates a require-in=
stance Statement

   If a NETCONF operation would result in configuration data where a
   leaf of type "instance-identifier" marked with require-instance
   "true" refers to a non-existing instance, the following error is
   returned:

     error-tag:      data-missing
     error-app-tag:  instance-required
     error-path:     Path to the instance-identifier leaf.

13.6.  Error Message for Data That Does Not Match a leaf=
ref Type

   If a NETCONF operation would result in configuration data where a
   leaf of type "leafref" refers to a non-existing instance, the
   following error is returned:

     error-tag:      data-missing
     error-app-tag:  instance-required
     error-path:     Path to the leafref leaf.

13.7.  Error Message for Data That Violates a mandatory =
choice Statement

   If a NETCONF operation would result in configuration data where no
   nodes exists in a mandatory choice, the following error is returned:

     error-tag:      data-missing
     error-app-tag:  missing-choice
     error-path:     Path to the element with the missing choice.
     error-info:     <missing-choice>: Contains the name of the mis=
sing
                     mandatory choice.

                     The <missing-choice> element is in the YANG
                     namespace ("urn:ietf:params:xml:ns:yang:1").







Bjorklund                    Standards Track        =
          [Page 166]

 
RFC 6020                  =
        YANG                      October 2010


13.8.  Error Message for the "insert" Operation

   If the "insert" and "key" or "value" attributes are used in an
   <edit-config> for a list or leaf-list node, and the "key" or "va=
lue"
   refers to a non-existing instance, the following error is returned:

     error-tag:      bad-attribute
     error-app-tag:  missing-instance

14.  IANA Considerations

   This document defines a registry for YANG module and submodule names.
   The name of the registry is "YANG Module Names".

   The registry shall record for each entry:

   o  the name of the module or submodule

   o  for modules, the assigned XML namespace

   o  for modules, the prefix of the module

   o  for submodules, the name of the module it belongs to

   o  a reference to the (sub)module's documentation (e.g., the RFC
      number)

   There are no initial assignments.

   For allocation, RFC publication is required as per RFC 5226
   [RFC5226].  All registered YANG m=
odule names MUST comply with the
   rules for identifiers stated in Section 6.2, and MUST have a module
   name prefix.

   The module name prefix 'ietf-' is reserved for IETF stream documents
   [RFC4844], while the module name prefix 'irtf-' is reserved for I=
RTF
   stream documents.  Modules published in other RFC streams MUST have a
   similar suitable prefix.

   All module and submodule names in the registry MUST be unique.

   All XML namespaces in the registry MUST be unique.

   This document registers two URIs for the YANG and YIN XML namespaces
   in the IETF XML registry [RFC3688].  Following the format in RFC
   3688, the following have been registered.

     URI: urn:ietf:params:xml:ns:yang:yin:1



Bjorklund                    Standards Track        =
          [Page 167]

 
RFC 6020                  =
        YANG                      October 2010


     URI: urn:ietf:params:xml:ns:yang:1

     Registrant Contact: The IESG.

     XML: N/A, the requested URIs are XML namespaces.

   This document registers two new media types as defined in the
   following sections.

14.1.  Media type application/yang

  MIME media type name:  application

  MIME subtype name:  yang

  Mandatory parameters:  none

  Optional parameters:  none

  Encoding considerations:  8-bit

  Security considerations:  See Section&=
nbsp;15 in RFC 6020

  Interoperability considerations:  None

  Published specification:  RFC 6020

  Applications that use this media type:

    YANG module validators, web servers used for downloading YANG
    modules, email clients, etc.

  Additional information:

     Magic Number:  None

     File Extension:  .yang

     Macintosh file type code:  'TEXT'

  Personal and email address for further information:
     Martin Bjorklund <mbj@tail-f.com>

  Intended usage:  COMMON

  Author:
     This specification is a work item of the IETF NETMOD working group,
     with mailing list address <netmod@ietf.org>.



Bjorklund                    Standards Track        =
          [Page 168]

 
RFC 6020                  =
        YANG                      October 2010


  Change controller:
     The IESG <iesg@ietf.org>

14.2.  Media type application/yin+xml

  MIME media type name:  application

  MIME subtype name:  yin+xml

  Mandatory parameters:  none

  Optional parameters:

     "charset":  This parameter has identical semantics to the charset
     parameter of the "application/xml" media type as specified in
     [RFC3023=
].

  Encoding considerations:

     Identical to those of "application/xml" as
     described in [RFC3023], Section&nb=
sp;3.2.

  Security considerations:  See Section&=
nbsp;15 in RFC 6020

  Interoperability considerations:  None

  Published specification:  RFC 6020

  Applications that use this media type:

    YANG module validators, web servers used for downloading YANG
    modules, email clients, etc.

  Additional information:

     Magic Number:  As specified for "application/xml" in [RFC3023],
                    Section 3.2.

     File Extension:  .yin

     Macintosh file type code:  'TEXT'

  Personal and email address for further information:
     Martin Bjorklund <mbj@tail-f.com>

  Intended usage:  COMMON





Bjorklund                    Standards Track        =
          [Page 169]

 
RFC 6020                  =
        YANG                      October 2010


  Author:
     This specification is a work item of the IETF NETMOD working group,
     with mailing list address <netmod@ietf.org>.

  Change controller:
     The IESG <iesg@ietf.org>

15.  Security Considerations

   This document defines a language with which to write and read
   descriptions of management information.  The language itself has no
   security impact on the Internet.

   The same considerations are relevant as for the base NETCONF protocol
   (see [RFC4741], Section 9).

   Data modeled in YANG might contain sensitive information.  RPCs or
   notifications defined in YANG might transfer sensitive information.

   Security issues are related to the usage of data modeled in YANG.
   Such issues shall be dealt with in documents describing the data
   models and documents about the interfaces used to manipulate the data
   e.g., the NETCONF documents.

   Data modeled in YANG is dependent upon:

   o  the security of the transmission infrastructure used to send
      sensitive information.

   o  the security of applications that store or release such sensitive
      information.

   o  adequate authentication and access control mechanisms to restrict
      the usage of sensitive data.

   YANG parsers need to be robust with respect to malformed documents.
   Reading malformed documents from unknown or untrusted sources could
   result in an attacker gaining privileges of the user running the YANG
   parser.  In an extreme situation, the entire machine could be
   compromised.











Bjorklund                    Standards Track        =
          [Page 170]

 
RFC 6020                  =
        YANG                      October 2010


16.  Contributors

   The following people all contributed significantly to the initial
   YANG document:

    - Andy Bierman (Brocade)
    - Balazs Lengyel (Ericsson)
    - David Partain (Ericsson)
    - Juergen Schoenwaelder (Jacobs University Bremen)
    - Phil Shafer (Juniper Networks)

17.  Acknowledgements

   The editor wishes to thank the following individuals, who all
   provided helpful comments on various versions of this document:
   Mehmet Ersue, Washam Fan, Joel Halpern, Leif Johansson, Ladislav
   Lhotka, Gerhard Muenz, Tom Petch, Randy Presuhn, David Reid, and Bert
   Wijnen.

18.  References

18.1.  Normative References

   [ISO.10646]  Intern=
ational Organization for Standardization,
                "Information Technology - Universal Multiple-Octet Coded
                Character Set (UCS)", ISO Standard 10646:2003, 2003.

   [RFC2119]    Bradner, S=
=2E, "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3023]    Murata, M.=
, St. Laurent, S., and D. Kohn, "XML Media
                Types", RFC 3023, January 2001.=


   [RFC3629]    Yergeau, F=
=2E, "UTF-8, a transformation format of ISO
                10646", STD 63, RFC 3629, Novem=
ber 2003.

   [RFC3688]    Mealling, =
M., "The IETF XML Registry", BCP 81, RFC 3688,
                January 2004.

   [RFC3986]    Berners-Le=
e, T., Fielding, R., and L. Masinter, "Uniform
                Resource Identifier (URI): Generic Syntax", STD 66,
                RFC 3986, January 2005.

   [RFC4648]    Josefsson,=
 S., "The Base16, Base32, and Base64 Data
                Encodings", RFC 4648, October 2=
006.

   [RFC4741]    Enns, R., =
"NETCONF Configuration Protocol", RFC 4741,
                December 2006.



Bjorklund                    Standards Track        =
          [Page 171]

 
RFC 6020                  =
        YANG                      October 2010


   [RFC5226]    Narten, T.=
 and H. Alvestrand, "Guidelines for Writing an
                IANA Considerations Section in RFCs", BCP 26, RFC 5226,
                May 2008.

   [RFC5234]    Crocker, D=
=2E and P. Overell, "Augmented BNF for Syntax
                Specifications: ABNF", STD 68, RFC =
5234, January 2008.

   [RFC5277]    Chisholm, =
S. and H. Trevino, "NETCONF Event
                Notifications", RFC 5277, July =
2008.

   [XML-NAMES]  Hollan=
der, D., Tobin, R., Thompson, H., Bray, T., and A.
                Layman, "Namespaces in XML 1.0 (Third Edition)", World
                Wide Web Consortium Recommendation REC-xml-names-
                20091208, December 2009,
                <http://www.w3.org/TR/2009/REC-xml-names-20091208>.

   [XPATH]      Clark, J. and =
S. DeRose, "XML Path Language (XPath)
                Version 1.0", World Wide Web Consortium
                Recommendation REC-xpath-19991116, November 1999,
                <http://www.w3.org/TR/1999/REC-xpath-19991116>.

   [XSD-TYPES]  Malhot=
ra, A. and P. Biron, "XML Schema Part 2: Datatypes
                Second Edition", World Wide Web Consortium
                Recommendation REC-xmlschema-2-20041028, October 2004,
                <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.

18.2.  Informative References

   [RFC2578]    McCloghrie=
, K., Ed., Perkins, D., Ed., and J.
                Schoenwaelder, Ed., "Structure of Management Information
                Version 2 (SMIv2)", STD 58, RFC 257=
8, April 1999.

   [RFC2579]    McCloghrie=
, K., Ed., Perkins, D., Ed., and J.
                Schoenwaelder, Ed., "Textual Conventions for SMIv2",
                STD 58, RFC 2579, April 1999.

   [RFC3780]    Strauss, F=
=2E and J. Schoenwaelder, "SMIng - Next
                Generation Structure of Management Information",
                RFC 3780, May 2004.

   [RFC4844]    Daigle, L.=
 and Internet Architecture Board, "The RFC
                Series and RFC Editor", RFC 4844, July 2007.

   [XPATH2.0]   Berglund=
, A., Boag, S., Chamberlin, D., Fernandez, M.,
                Kay, M., Robie, J., and J. Simeon, "XML Path Language
                (XPath) 2.0", World Wide Web Consortium
                Recommendation REC-xpath20-20070123, January 2007,
                <http://www.w3.org/TR/2007/REC-xpath20-20070123>.



Bjorklund                    Standards Track        =
          [Page 172]

 
RFC 6020                  =
        YANG                      October 2010


   [XSLT]       Clark, J., "XSL =
Transformations (XSLT) Version 1.0",
                World Wide Web Consortium Recommendation REC-xslt-
                19991116, November 1999,
                <http://www.w3.org/TR/1999/REC-xslt-19991116>.

Author's Address

   Martin Bjorklund (editor)
   Tail-f Systems

   EMail: mbj@tail-f.com








































Bjorklund                    Standards Track                  [Page 173]

Html markup produced by rfcmarkup 1= =2E106, available from http://tools.ietf.org/= tools/rfcmarkup/ --------------070902080105040106060000-- From nobody Fri Oct 3 10:20:54 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 576F21A6EF1 for ; Fri, 3 Oct 2014 10:20:52 -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 xj8y8kvKOayr for ; Fri, 3 Oct 2014 10:20:50 -0700 (PDT) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64FE41A1AA6 for ; Fri, 3 Oct 2014 10:20:50 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id r5so1348680qcx.35 for ; Fri, 03 Oct 2014 10:20:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yrhX6Kl6oAGHyrmPAp1E7tiEhbqvA+3pVlUAon8uXXY=; b=EsymLbQe7E4gsT7c0CrQyu/r65q3Myv/0PRmwHywfPB+lAzM/Mqt9dRZ2Hesm2oQdm p8rKIdbBm3neg00+RsGk2Vx8NBTuvYN3/v+1QsrSFYYE+F4EuWzmhfdNPlhrLLM/E7Zq 9U+87nP6lOhQZQP1vT8L3qU+2cASiGbof0JgSpypivbJfeoDeRpX7bl+CeRUi4QWDADY 6l7C4o/Fl8O20ROu2JSjIA8OP3yL12x/8mpn3mTEaOkZiRsM+MVfVVqZyfb2nXgahfZu UdFU+LbcDua37HoV1EgNjzjUDzE/XNYQYHM6nfBCX/jDOfDKGlZyiTQcwwnlmnP/Pd/t 461Q== X-Received: by 10.140.97.136 with SMTP id m8mr7321590qge.95.1412356849646; Fri, 03 Oct 2014 10:20:49 -0700 (PDT) Received: from [192.168.1.101] (108-247-124-220.lightspeed.sntcca.sbcglobal.net. [108.247.124.220]) by mx.google.com with ESMTPSA id w20sm2106602qge.21.2014.10.03.10.20.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 03 Oct 2014 10:20:49 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Mahesh Jethanandani In-Reply-To: <20141002120801.GA41278@elstar.local> Date: Fri, 3 Oct 2014 10:20:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141002120801.GA41278@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/oRVfmyT-MplZu_fVXcTsI6_u4P4 Cc: netmod@ietf.org Subject: Re: [netmod] draft minutes of the NETMOD 2014-10-01 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, 03 Oct 2014 17:20:52 -0000 Juergen, Are we voting on Y25 options that you state in the meeting minutes? The options are: (1) No change (2) Remove auto numbering (3) Add statement to make auto numbering optional (on/off) I am voting 1, 3, 2. On Oct 2, 2014, at 5:08 AM, Juergen Schoenwaelder wrote: > Hi, >=20 > attached are the draft minutes of yesterday's virtual interim meeting. > Please let me know if something needs fixing by the beginning of next > week so that I can send the final version to the secretariat. >=20 > You can also find all the virtual interim meeting minutes next to the > YANG 1.1 issue list in the NETMOD WG subversion repository: >=20 > http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ >=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 > = ___________________________________________= ____ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod Mahesh Jethanandani mjethanandani@gmail.com From nobody Fri Oct 3 12:29:10 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2AEA1A1A73 for ; Fri, 3 Oct 2014 12:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.286 X-Spam-Level: X-Spam-Status: No, score=-15.286 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGpxGlikAMeB for ; Fri, 3 Oct 2014 12:29:06 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CB681A1A15 for ; Fri, 3 Oct 2014 12:29:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1255; q=dns/txt; s=iport; t=1412364546; x=1413574146; h=from:to:subject:date:message-id:mime-version; bh=EGXB4VdBwl0wcgjiBQuSJFYGARWrVFW7Ig/PfUWFN04=; b=ATX0ZWas95qCfemlvO+t8lFTqH9THYxwmcgHNOn93DnKNE+uqB00+LC7 OiUPBlp/BR4TzRoJLvXl05q553MCDEGeh/dd74kLJFy3tImLpF3wQ+Jge zSM4hKw2HLZU+XMWZO7nMelpbn8s4ztFsGD8onkL6UBKwbrCeH5T6VcX9 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8IABb4LlStJV2c/2dsb2JhbABggkhGgS/TYxYBcgmDehCBCwELAXQnBIhRmVKlV5UABZF0i0qWAINjgjSBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,649,1406592000"; d="scan'208,217";a="360479029" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 03 Oct 2014 19:29:05 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s93JT5dh030336 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 3 Oct 2014 19:29:05 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.38]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Fri, 3 Oct 2014 14:29:05 -0500 From: "Aseem Choudhary (asechoud)" To: "netmod@ietf.org" Thread-Topic: Augmentation of Optional Key Thread-Index: AQHP30BKmgU9XpAl0kqr5y/ub7faYg== Date: Fri, 3 Oct 2014 19:29: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.2.3.120616 x-originating-ip: [10.154.208.191] Content-Type: multipart/alternative; boundary="_000_D054470E798A5asechoudciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ZJh4gNPmfPEIFnMVqjG4d2zPWWY Subject: [netmod] Augmentation of Optional Key X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 03 Oct 2014 19:29:08 -0000 --_000_D054470E798A5asechoudciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I am not sure if this has been discussed during the proposal of Optional ke= y. Are we planning to support optional key augmentation to a module ? If yes, = how does it look like. If no, why not? -thanks, Aseem --_000_D054470E798A5asechoudciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <08371EA30757774BB4DE0115A9FB6986@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi all,

I am not sure if this has been discussed during the proposal of Option= al key. 

Are we planning to support optional key augmentation to a module ? If = yes, how does it look like. If no, why not?

-thanks,
Aseem
--_000_D054470E798A5asechoudciscocom_-- From nobody Sat Oct 4 11:35:18 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25A8D1A0142 for ; Sat, 4 Oct 2014 11:35: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 julgW3XKAdZ6 for ; Sat, 4 Oct 2014 11:35:15 -0700 (PDT) Received: from mail-qc0-f177.google.com (mail-qc0-f177.google.com [209.85.216.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 862F21A0120 for ; Sat, 4 Oct 2014 11:35:15 -0700 (PDT) Received: by mail-qc0-f177.google.com with SMTP id c9so2405575qcz.22 for ; Sat, 04 Oct 2014 11: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=OiQ3LzbnyYh+QfVez7Ol2eCfYs/DtY+4IIXZICcy1a4=; b=BA87uAcQlRguM7nuTjPoQlpICLq5rhaxgEDhU/pR4abcmc8FM5LAn51guv8fwe87Zh eqNsI+Q8lQf1b4ytTHeS1HKY4hOX6B7yYvhBmxOiCcM1jPOrg2avTaiVJlZJvnkiETSq 0FPo0ueAjU5Saak0p49NtLUslZ9stVusFntxyfHXRpdp5q5g+5lwLCJgtmR8R4IQd15w 9idurq19mUbF46Fw3XS7Dwzm+8Ns+Dl9ms/2cCm+fL9sLrEvF7Xbx3CG5a8OsJWvjgPE ixhwTns093E00VZ0RzzzCHfUfVdQLhWJvbubSwQUOwb1iuVDRzPc0vYS2D9UloUXZbxl 4ZeQ== X-Gm-Message-State: ALoCoQkrgTxhYVzYP4IYB//44bYBXk9dsq+BRs3oQHEe+UKAPBO0OV1X3U6xhUehMw2HapDSi2HF MIME-Version: 1.0 X-Received: by 10.229.46.3 with SMTP id h3mr12314904qcf.4.1412447714329; Sat, 04 Oct 2014 11:35:14 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Sat, 4 Oct 2014 11:35:14 -0700 (PDT) In-Reply-To: <20140915170229.GA13054@elstar.local> References: <20140915170229.GA13054@elstar.local> Date: Sat, 4 Oct 2014 11:35:14 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a1133bc7446caac05049d1c82 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/U3ot43wX1C9EQMgkbiCi-SFw704 Subject: Re: [netmod] rfc6087bis Issues List X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 04 Oct 2014 18:35:17 -0000 --001a1133bc7446caac05049d1c82 Content-Type: text/plain; charset=ISO-8859-1 Hi, The issue tracker is (finally) updated. Andy On Mon, Sep 15, 2014 at 10:02 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Sat, Sep 13, 2014 at 12:12:03PM -0700, Andy Bierman wrote: > > Hi, > > > > I created an issue tracker on github for the YANG Usage Guidelines > update. > > > > https://github.com/netmod-wg/rfc6087bis/issues > > > > Great. Looking at the various YANG 1.1 minutes, I found: > > - Y27 "possible action to add guidelines how to go from current to > deprecated to obsolete in RFC 6087bis" > > - Y36 "one could also think about guidelines on how to structure > notifications to make resource identification easier" > > - Y06 "Guidelines should say better use single quotes for pattern." > > These may not all be actionable but perhaps still useful to track > them. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > --001a1133bc7446caac05049d1c82 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

The issue tracker is (finally) upda= ted.

Andy


On Mon, Sep 15, 2014 at 10:02 AM, Juergen S= choenwaelder <j.schoenwaelder@jacobs-university.de&= gt; wrote:
On Sat, Sep 13, 2014 at= 12:12:03PM -0700, Andy Bierman wrote:
> Hi,
>
> I created an issue tracker on github for the YANG Usage Guidelines upd= ate.
>
> https://github.com/netmod-wg/rfc6087bis/issues
>

Great. Looking at the various YANG 1.1 minutes, I found:

- Y27 "possible action to add guidelines how to go from current to
=A0 =A0deprecated to obsolete in RFC 6087bis"

- Y36 "one could also think about guidelines on how to structure
=A0 notifications to make resource identification easier"

- Y06 "Guidelines should say better use single quotes for pattern.&quo= t;

These may not all be actionable but perhaps still useful to track
them.

/js

--
Juergen Schoenwaelder=A0 =A0 =A0 =A0 =A0 =A0Jacobs University Bremen gGmbH<= br> Phone: +49 421 200 3587=A0 =A0 =A0 =A0 =A0Campus Ring 1, 28759 Bremen, Germ= any
Fax:=A0 =A0+49 421 200 3103=A0 =A0 =A0 =A0 =A0<http://www.jacobs-university.de/&= gt;

--001a1133bc7446caac05049d1c82-- From nobody Sat Oct 4 13:08:26 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79A271A026E for ; Sat, 4 Oct 2014 13:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzfWIK8VA5Cv for ; Sat, 4 Oct 2014 13:08: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 A7CEF1A0255 for ; Sat, 4 Oct 2014 13:08:05 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id ED6C5FA2; Sat, 4 Oct 2014 22:08: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 iW6-yavL9d8C; Sat, 4 Oct 2014 22:08:02 +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; Sat, 4 Oct 2014 22:08:02 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id D326E20038; Sat, 4 Oct 2014 22:08:02 +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 aMI3zn5Y0uB1; Sat, 4 Oct 2014 22:08:01 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8FFB220035; Sat, 4 Oct 2014 22:08:01 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 22FF72EC2807; Sat, 4 Oct 2014 22:07:58 +0200 (CEST) Date: Sat, 4 Oct 2014 22:07:58 +0200 From: Juergen Schoenwaelder To: "Aseem Choudhary (asechoud)" Message-ID: <20141004200756.GA49023@elstar.local> Mail-Followup-To: "Aseem Choudhary (asechoud)" , "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: http://mailarchive.ietf.org/arch/msg/netmod/DSViF8Qxh01OupzZ3uVM3ONfbrc Cc: "netmod@ietf.org" Subject: Re: [netmod] Augmentation of Optional Key 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: Sat, 04 Oct 2014 20:08:19 -0000 On Fri, Oct 03, 2014 at 07:29:04PM +0000, Aseem Choudhary (asechoud) wrote: > Hi all, > > I am not sure if this has been discussed during the proposal of Optional key. > > Are we planning to support optional key augmentation to a module ? If yes, how does it look like. If no, why not? > The main issue is that a key defines (as part of the contract between client and server) what uniquely identifies a list element. It is difficult to change this contract. During the virtual interim on September 3rd, we discussed that adding additional optional keys to a key is difficult since it breaks the expections of an old client when it talks to a new server. The same argument will hold for optional key augmentations - a client not knowing about the key augmentation will see multiple elements in a list with the same key, which is problematic. Despite this, we discussed at some length during the New York interim that we need to extend the instance-identifier syntax to support optional keys. I need to start a separate thread to discuss this and in particular the implications of this for existing implementations. /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 Sat Oct 4 13:32:21 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD1151A0282 for ; Sat, 4 Oct 2014 13:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gRktvRadPJP for ; Sat, 4 Oct 2014 13:32: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 3E8361A0242 for ; Sat, 4 Oct 2014 13:32: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 115B7FD2; Sat, 4 Oct 2014 22:32: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 ozFr5e0kiMd8; Sat, 4 Oct 2014 22:32: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; Sat, 4 Oct 2014 22:32:15 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 91B9A20036; Sat, 4 Oct 2014 22:32: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 6EDHe881I34j; Sat, 4 Oct 2014 22:32: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 762C820035; Sat, 4 Oct 2014 22:32:14 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9D1E32EC287B; Sat, 4 Oct 2014 22:32:13 +0200 (CEST) Date: Sat, 4 Oct 2014 22:32:13 +0200 From: Juergen Schoenwaelder To: Mahesh Jethanandani Message-ID: <20141004203213.GB49023@elstar.local> Mail-Followup-To: Mahesh Jethanandani , netmod@ietf.org References: <20141002120801.GA41278@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: http://mailarchive.ietf.org/arch/msg/netmod/MWI1IHa1PoNHaQKpFGHDdv-pHhY Cc: netmod@ietf.org Subject: Re: [netmod] draft minutes of the NETMOD 2014-10-01 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: Sat, 04 Oct 2014 20:32:19 -0000 Mahesh, we are not voting in the IETF. I did a poll of opinions in order to see where we are (were you already gone at that time?). A poll of opinion is a way to determine where we are in the process of finding censensus, see RFC 7282 for a great reading about IETF consensus finding. Since we have rather different opinions here, can you explain why you want no change? Note that RFC 6020 says: "The value is unused by YANG and the NETCONF messages, but is carried as a convenience to implementors." It seems necessary to gain an understanding how implementations are affected by (2) or (3) (and I assume people favoring (1) likely do this because (2) or (3) affect their implementation). /js On Fri, Oct 03, 2014 at 10:20:46AM -0700, Mahesh Jethanandani wrote: > Juergen, > > Are we voting on Y25 options that you state in the meeting minutes? > > The options are: > (1) No change > (2) Remove auto numbering > (3) Add statement to make auto numbering optional (on/off) > > I am voting 1, 3, 2. > > On Oct 2, 2014, at 5:08 AM, Juergen Schoenwaelder wrote: > > > Hi, > > > > attached are the draft minutes of yesterday's virtual interim meeting. > > Please let me know if something needs fixing by the beginning of next > > week so that I can send the final version to the secretariat. > > > > You can also 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 > > Mahesh Jethanandani > mjethanandani@gmail.com > > > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Sat Oct 4 18:15:47 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC5A11A0360 for ; Sat, 4 Oct 2014 18:15:44 -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 fA31i2YIUuf1 for ; Sat, 4 Oct 2014 18:15:43 -0700 (PDT) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB34A1A0332 for ; Sat, 4 Oct 2014 18:15:42 -0700 (PDT) Received: by mail-yk0-f181.google.com with SMTP id q200so1163324ykb.26 for ; Sat, 04 Oct 2014 18:15:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Lg0V6r8RTc+4+iH61cYdjND0bGWYUgUwj/X7KWFPfDw=; b=H7BWiAGfgZLentZDBK3PSpDIkr08OCT+pDY6aiffsjaFh9PFpWGdwjiU82heaVyxH5 06wWm+1x2Ww0E0CIkt86s2CsCcaEPzuSNqk6IpnQzSkN5lQkOS+dccbHOuL5+cReDZTP lP8+czqy55ZsvfFIB5sqxT/Hi85A9jx4rR19FaVrpHkIMpDukA2JgrMalJWQofiM18BP CJJmTcyH14Z1eo+6DrvtUUti9IoKZv4umNuSPDEvMCodF9nsKWU74EEVpvbC6gFhpkm0 o5n819IrFGX1YwUa6l2NlbmM2nGaEvlRXSNL/ET0entDfREXIt/G/fniRtRmHE/3yAMj BzEg== X-Received: by 10.236.13.38 with SMTP id a26mr5680039yha.23.1412471742081; Sat, 04 Oct 2014 18:15:42 -0700 (PDT) Received: from [192.168.1.101] (108-247-124-220.lightspeed.sntcca.sbcglobal.net. [108.247.124.220]) by mx.google.com with ESMTPSA id 8sm5154535yhp.8.2014.10.04.18.15.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 04 Oct 2014 18:15:41 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Mahesh Jethanandani In-Reply-To: <20141004203213.GB49023@elstar.local> Date: Sat, 4 Oct 2014 18:15:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <18BCB49E-E250-457F-962B-5006F01D8F29@gmail.com> References: <20141002120801.GA41278@elstar.local> <20141004203213.GB49023@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/CJVR_T8LVaMUS0hzSA8eLOl-9vg Cc: netmod@ietf.org Subject: Re: [netmod] draft minutes of the NETMOD 2014-10-01 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: Sun, 05 Oct 2014 01:15:45 -0000 Juergen, You mentioned in the minutes that you were planning to take the = discussion to the list. Sorry, I was not there for the poll, as I had to = hang up to head to work. > This needs to be taken to the list. (The result may mean that > there is a majority for making a change here and out of the two > options to make a change, it seems there is a majority to remove > the auto numbering - which is after all a convenience to > implementors.) See comments inline. On Oct 4, 2014, at 1:32 PM, Juergen Schoenwaelder wrote: > Mahesh, >=20 > we are not voting in the IETF. I did a poll of opinions in order to > see where we are (were you already gone at that time?). A poll of > opinion is a way to determine where we are in the process of finding > censensus, see RFC 7282 for a great reading about IETF consensus > finding. >=20 > Since we have rather different opinions here, can you explain why you > want no change? Note that RFC 6020 says: "The value is unused by YANG > and the NETCONF messages, but is carried as a convenience to > implementors." True. The values are carried as a convenience and as such are just that. > It seems necessary to gain an understanding how > implementations are affected by (2) or (3) (and I assume people > favoring (1) likely do this because (2) or (3) affect their > implementation). My rational for opting for (1) is mainly because how I am used to enums, = i.e. that they are auto numbered and I do no have to add a value = statement. Call me lazy, but I like that feature. So even though they = are carried as a convenience, they are there if anyone wants to use = them. (I guess that means implementations can choose to ignore the value = that is carried and assign their own??) So unless not auto numbering = them buys us a big advantage, I am inclined to leave them as is. HTH. mj >=20 > /js >=20 > On Fri, Oct 03, 2014 at 10:20:46AM -0700, Mahesh Jethanandani wrote: >> Juergen, >>=20 >> Are we voting on Y25 options that you state in the meeting minutes? >>=20 >> The options are: >> (1) No change >> (2) Remove auto numbering >> (3) Add statement to make auto numbering optional (on/off) >>=20 >> I am voting 1, 3, 2. >>=20 >> On Oct 2, 2014, at 5:08 AM, Juergen Schoenwaelder wrote: >>=20 >>> Hi, >>>=20 >>> attached are the draft minutes of yesterday's virtual interim = meeting. >>> Please let me know if something needs fixing by the beginning of = next >>> week so that I can send the final version to the secretariat. >>>=20 >>> You can also find all the virtual interim meeting minutes next to = the >>> YANG 1.1 issue list in the NETMOD WG subversion repository: >>>=20 >>> http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ >>>=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 >>> = ___________________________________________= ____ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >> Mahesh Jethanandani >> mjethanandani@gmail.com >>=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 Mahesh Jethanandani mjethanandani@gmail.com From nobody Sun Oct 5 06:44:14 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C201A02F0; Sun, 5 Oct 2014 06:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.779 X-Spam-Level: X-Spam-Status: No, score=-0.779 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=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 CQQh1CjQwgJe; Sun, 5 Oct 2014 06:44:10 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id CE4D31A007C; Sun, 5 Oct 2014 06:44:09 -0700 (PDT) Received: from [192.168.1.121] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 0EAC428B1AFD; Sun, 5 Oct 2014 09:44:09 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_A9DE895C-EF9A-4E5B-A1DC-6D8113E4749B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: <20141001141733.GC38460@elstar.local> Date: Sun, 5 Oct 2014 09:44:07 -0400 Message-Id: <6F82AD50-7237-40A4-9742-DAE53BA99866@lucidvision.com> References: <20141001141733.GC38460@elstar.local> To: Juergen Schoenwaelder , NETMOD Working Group X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/zOJl9VKXgaLPFsnn7XCCQVBgNh4 Cc: YANG Doctors , netmod-chairs@tools.ietf.org, "" Subject: [netmod] virtual interim meeting including webex X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 05 Oct 2014 13:44:12 -0000 --Apple-Mail=_A9DE895C-EF9A-4E5B-A1DC-6D8113E4749B Content-Type: multipart/mixed; boundary="Apple-Mail=_623EA8E2-24D5-4DBF-945A-42D4B3CC1B20" --Apple-Mail=_623EA8E2-24D5-4DBF-945A-42D4B3CC1B20 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Just a reminder that this week's NETMOD interim meeting marks = the first in the change of format of our meetings. This week we will = begin alternating between a Yang modeling-focused meeting versus a yang = 1.1 issues meeting which will occur the week after next.=20 As I mentioned, I'd like to get an agenda assembled ahead of = time. To-date, I have two topics on the agenda for discussion. If you = have others, please send them to me as soon as possible. We will be using the same WebEx as we have been using which is = attached. --Tom (as NETMOD co-chair) --Apple-Mail=_623EA8E2-24D5-4DBF-945A-42D4B3CC1B20 Content-Disposition: attachment; filename=netmod-webex.txt Content-Type: text/plain; name="netmod-webex.txt" Content-Transfer-Encoding: quoted-printable Topic: NETMOD WG Date: Every Wednesday, from Wednesday, August 27, 2014 to Wednesday, = October 22, 2014 Time: 4:00 pm, Europe Summer Time (Berlin, GMT+02:00) Meeting Number: 649 102 111 Meeting Password: 1234 ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to = https://ietf.webex.com/ietf/j.php?MTID=3Dmbbe9c321c8e9f472df4ce74c1987a0f0= 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: 1234 4. Click "Join". 5. Follow the instructions that appear on your screen. To view in other time zones or languages, please click the link: https://ietf.webex.com/ietf/j.php?MTID=3Dme720293ef5473cc3bf963302b2f6a8f1= ------------------------------------------------------- To join the audio conference only=20 ------------------------------------------------------- Call-in toll number (US/Canada): 1-650-479-3208 Access code:649 102 111 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/mc 2. On the left navigation bar, click "Support". You can contact me at: cmorgan@amsl.com 1-510-492-4085 To update this meeting to your calendar program (for example Microsoft = Outlook), click this link: https://ietf.webex.com/ietf/j.php?MTID=3Dm4f877f2e629b841380e2d593e4e39b87= WebEx will automatically setup Meeting Manager for Windows the first = time you join a meeting. To save time, you can setup prior to the = meeting by clicking this link: https://ietf.webex.com/ietf/meetingcenter/mcsetup.php The playback of UCF (Universal Communications Format) rich media files = requires appropriate players. To view this type of rich media files in = the meeting, please check whether you have the players installed on your = computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php.=20 http://www.webex.com CCP:+16504793208x649102111#=20 IMPORTANT NOTICE: This WebEx service includes a feature that allows = audio and any documents and other materials exchanged or viewed during = the session to be recorded. By joining this session, you automatically = consent to such recordings. If you do not consent to the recording, = discuss your concerns with the meeting host prior to the start of the = recording or do not join the session. Please note that any such = recordings may be subject to discovery in the event of litigation. --Apple-Mail=_623EA8E2-24D5-4DBF-945A-42D4B3CC1B20 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_623EA8E2-24D5-4DBF-945A-42D4B3CC1B20-- --Apple-Mail=_A9DE895C-EF9A-4E5B-A1DC-6D8113E4749B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUMUsnAAoJEPcO+I7eiUJZwucQAJv8mKqysQelbZ3PClMKTlDi xmxE2CRLqqQvPPhp2bZdlsZacWDM7ZC/zWCCQOLZpt1B22+K2Zwl2FvqtY78PVPA 7HcIPWDLtyAm4O2IZX/TOieW9W2SOATmENDVS0wJpF8QafgSr/D3clBLyupjl3+V s9QdtPcCzNWENYVbKjQWh2I8Wy9pmigvwic6oe5jM7dh78jGChpjl5otghk97Orr W4yvmeOUqwXZO0YHKUxBTaWoVj31SoBSYIZEV6hNoPrpJR43GPAbFxutCbz24fCO B19TcCYUOJ0JzncP6wWy1CS0fudoOyF2eEdSMt71496T5wF9nx4C0RptMv+goP0z 6Ndje0xd2LNEeaR5qxcojyHig59gn62nJP0GdFh4wKxkJUu+AdrdnvpnXQXPxfo6 qE8cGaFslZqfPPVNlb5/5fLtCwxwFd6HMq81if/fi3gsUpbCGTQKG2jsc7tLC+mG n8tB+ph+jOeRO0bi7TY3uFND4DPuVVIutZzPGgTDG58bjaLBMjYNvlMGI7c8f/eh WIJNRPpWjTqoTqDNjXoUJcrN39aAvFFy0Dlmpw3nsgDXHcMyaylVrZIwEkfVcDpf fdN2+6XsgeGA3I8cRrmJCOddKqdI5XnxkMCq9ZRF8uFXnNb8BDEDG+lx3NrILfGE ItcAeqsaN63Ls7TTUxth =HdRn -----END PGP SIGNATURE----- --Apple-Mail=_A9DE895C-EF9A-4E5B-A1DC-6D8113E4749B-- From nobody Sun Oct 5 23:29:33 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE00E1A1AF9 for ; Sun, 5 Oct 2014 23:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bz_Q2YZErfNp for ; Sun, 5 Oct 2014 23:29: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 D8CBE1A00B0 for ; Sun, 5 Oct 2014 23:29:29 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E29D2E8A; Mon, 6 Oct 2014 08:29: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 zHkXAEKA4HkW; Mon, 6 Oct 2014 08:29: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; Mon, 6 Oct 2014 08:29:27 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 582F22003A; Mon, 6 Oct 2014 08:29:27 +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 37bmWglsZB9e; Mon, 6 Oct 2014 08:29:26 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 684FD20036; Mon, 6 Oct 2014 08:29:26 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6687A2EC349E; Mon, 6 Oct 2014 08:29:26 +0200 (CEST) Date: Mon, 6 Oct 2014 08:29:26 +0200 From: Juergen Schoenwaelder To: Mahesh Jethanandani Message-ID: <20141006062926.GC51842@elstar.local> Mail-Followup-To: Mahesh Jethanandani , netmod@ietf.org References: <20141002120801.GA41278@elstar.local> <20141004203213.GB49023@elstar.local> <18BCB49E-E250-457F-962B-5006F01D8F29@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18BCB49E-E250-457F-962B-5006F01D8F29@gmail.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/wFn8LlDLJ5ru8BVWg5GO36jpPnQ Cc: netmod@ietf.org Subject: Re: [netmod] draft minutes of the NETMOD 2014-10-01 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: Mon, 06 Oct 2014 06:29:32 -0000 On Sat, Oct 04, 2014 at 06:15:39PM -0700, Mahesh Jethanandani wrote: > > My rational for opting for (1) is mainly because how I am used to > enums, i.e. that they are auto numbered and I do no have to add a > value statement. Call me lazy, but I like that feature. So even > though they are carried as a convenience, they are there if anyone > wants to use them. (I guess that means implementations can choose to > ignore the value that is carried and assign their own??) So unless > not auto numbering them buys us a big advantage, I am inclined to > leave them as is. The autonumbering 'feature' causes side effects: The order of definition of enums can't be modified anymore (unless explicit values are assigned) and additional enums can only be made at the end. If you want to maintain enums for things that do not have a natural number associated to then (e.g., timezones or country codes), then autonumbering makes this difficult. Note that this is different from enums in programming languages where the autonumbering is local to a compiler run. If you add something in the middle, you will recompile and everything gets renumbered and you are fine. (Note that tools can still autonumber (e.g., create C/C++/Java enums) when they generate code as long as the code is compiled into something that is internally version consistent.) The core of the issue is that auto-numbering makes it difficult for data modelers to maintain certain enums while the benefit is only a 'convenience to implementors'. In the early YANG days, the priority was always YANG 'reader', then YANG 'writer' and finally YANG 'implementors'. The enum/bits auto-numbering puts 'implementors' higher than 'writers'. /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 Oct 6 04:19:47 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 591391A1BDA for ; Mon, 6 Oct 2014 04:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.913 X-Spam-Level: X-Spam-Status: No, score=0.913 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] 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 8n0mMm1ChRy6 for ; Mon, 6 Oct 2014 04:19:42 -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 48CD71A1BC7 for ; Mon, 6 Oct 2014 04:19:41 -0700 (PDT) X-AuditID: c1b4fb3a-f79da6d0000008c7-61-54327acb28ea Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 72.C2.02247.BCA72345; Mon, 6 Oct 2014 13:19:39 +0200 (CEST) Received: from [159.107.197.222] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.65) with Microsoft SMTP Server id 14.3.174.1; Mon, 6 Oct 2014 13:19:38 +0200 Message-ID: <54327ACA.3090606@ericsson.com> Date: Mon, 6 Oct 2014 13:19:38 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "netmod@ietf.org" Content-Type: multipart/mixed; boundary="------------030107060003090907030709" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBLMWRmVeSWpSXmKPExsUyM+Jvje7pKqMQg4a3chbzLzayOjB6LFny kymAMYrLJiU1J7MstUjfLoEr4+DETywFB+0qft/7wNTA+Ei/i5GTQ0LAROLGh9nsELaYxIV7 69m6GLk4hASOMkqsPnyLFcJZwyjxduVqVpAqXgFtiY1TjrOA2CwCKhJ//j4H62YTMJKY2n8e LC4qECVx51I/VL2gxMmZT8DiIgLqEjN3gmzg5GAW0JSY390JFhcWkJPYeeArI0Q8QGLp5hPM ILaQgIbEwwt/WScw8s1CMmoWkjII21biwpzrUHF5ie1v50DFoyRmvJ7EChNv3jobKu4t8ff6 NfYFjOyrGEWLU4uLc9ONjPRSizKTi4vz8/TyUks2MQKD9uCW31Y7GA8+dzzEKMDBqMTDm7Df MESINbGsuDL3EKM0B4uSOO/Cc/OChQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTAW+LtrpR6O y3Er074SISi6/NLbI+dE7ue2Xnde/zTw2ecmqwtvPS8vYri/2FNFitP/4v7HbxgVlq8pvZ7i 07ejfNUfx5c5MafTD/zYPH9+wZpTJyctPXJni70DWydbXrj2yUl2ESfVlrHJLL4TqXLxrt0N /6D1s6eUrVN0mPV6fXfgi9ClgjzMSizFGYmGWsxFxYkAfT5TGTsCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/uZIQ2JPGU_6Mrt56XYQuDyhp6Yg Cc: EGBOSCH Subject: [netmod] non-unique leaf-lists X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 06 Oct 2014 11:19:43 -0000 --------------030107060003090907030709 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Hello, After the New York interim I volunteered to write a proposal about how to implement leaf-lists that might have non-unique (repeated) values. I attached my proposal for it. Please comment! regards Balazs -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist ECN: 831 7320 Tel: +36-1-437-7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com --------------030107060003090907030709 Content-Type: text/plain; charset="windows-1252"; name="nonUniqueleafListproposal-3.txt" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="nonUniqueleafListproposal-3.txt" Date: 2014-10-06 rev 3 Balazs Lengyel NonUnique leaf-list ######################################################################## Two proposals are developed. In proposal-1 leaf-lists can have non-unique leafs. In proposal-2 additionaly addressing leafs inside a leaf-list can be done by position. In each proposal a set of assumptions and decisions are needed. For each issue the first option is the proposed solution. Q1) A nonUnique leaf-list shall be handled as a A1a) set of separate leafs better functionality, lets try it A1b) single unit simple Q2) Is there a need for removing all values at once A2a) No, we don't do that in Yang1 either A2b) Yes it would be nice Q3) if we have a leaf-list with nonUnique values in the datastore a value in the edit-config addresses A3a) the first such value in the datastore simple A3b) all such values in the datastore simple for delete/remove; strange for replace; merge should be additive but merging [a,a,a] with [a] will result in [a] which is not additive; very strange for insert-after we want to insert one value, but suddenly it can become multiple values; Q4) Will edit-config-create fail in the nonUnique case if an already existing value is created in edit-config ? A4a) No it just means adding one more leaf with the existing value. Create shall be possible to use for adding new values. A4b) Yes, this is more similar to the unique case. Use merge or replace if you want to add an existing value e.g. replace [a,a] with [a,a,a] ######################################################################## Proposal-1 NonUnique leaf-lists --- Change to chapter 3: leaf-list: Like the leaf node but defines a set of uniquely identifiable nodes rather than a single node. Each node has a value but no child nodes. change to leaf-list: Like the leaf node but defines a set of nodes rather than a single node. Each node has a value but no child nodes. --- Change to chapter 4.2.2.2: A leaf-list is a sequence of leaf nodes with exactly one value of a particular type per leaf. What does this mean? Does it mean that leaf-lists need to have unique leafs? Change to: A leaf-list is a sequence of leaf nodes. --- Change to chapter 7.7 Remove: The values in a leaf-list MUST be unique. --- Change to chapter 7.7.2 Add: unique-leaf-list cardinality 0..1 --- Add a level 3 chapter before 7.7.6 7.7.5b The unique-leaf-list Statement The "unique-leaf-list" statement takes as an argument the string "true" or "false". If "unique-leaf-list" is "true", values within the leaf-lists must be unique. If "unique-leaf-list" is "false", values within the leaf-lists may be repeated. If "unique-leaf-list" is not specified, the default is true. --- Change chapter 7.7.7 The operations way of working is dependent on the value of unique-leaf-list. If unique-leaf-list is true the current handling is unchanged. If unique-leaf-list is false the following applies: delete/remove: delete/remove the addressed value (first occurence) from the leaf-list. If a value exists multiple times in edit-config try to delete 2/3/ instances of the value. For delete it is an error if insufficient value instances exist in datastore. create: create value. It succeeds even if value already exists, just adds the value once more. If no "insert" attribute is present in the "create" operation, it defaults to "last". If a value exists multiple times in edit-config repeat the steps. replace: delete the (first) value if it exist, and create it as specified by insert. If the insert attribute refers to a value, it is the first occurrence of the value that is indicated. If insert is not specified create the value at the end of the leaf-list. If a value exists multiple times in edit-config repeat the steps. merge: For each specific value, the number of instances of the value in edit-config and the datastore are matched against each other. For these value instances the merge works like replace. If edit-config contains more instances, the additional ones are created as in a create operation. If the datastore contains more instances, they are not modified. ######################################################################## Proposal-2 NonUnique leaf-lists and addressing by position A5) Position can only be used in an "ordered-by user" leaf-list. For system-ordered lists it leads to error. (Same as insert) A6) Position must be between 1 and the length of the leaf-list, if it is not, send an error message. Indexing starts at 1 not 0, following XPATH conventions. A7) In a delete/remove operation if position is specified, the value, has no effect, it may be omitted by the client. (Addressing by position takes precedence over addressing by value.) A8) If both the position and the value attributes are specified in edit-config for the same data node, the value attribute has no effect and may be (should be) ommitted by the client. A9) If position is specified, the insert attribute can only take the values after and before. First and last are error. (There is no sense in specifying position once the insert=first/last is specified, it would just add one more useless and complicated case.) --- Additional Changes to chapter 7.7.7 In an "ordered-by user" leaf-list, the attribute "position" in the YANG XML namespace (Section 5.3.1) can be used to address specific values in the leaf-list. delete/remove: same as in Proposal-1 create: add to the proposal-1 text: If position is specified and but insert is not specified insert=after is implied. replace/merge: if position is specified but insert is not, replace the value specified by position. If both position and insert=after/before is specified, insert a new leaf with the value at the specified position. (replace/merge works differntly with and without position.) ######################################################################## example: Ethernet0/0 1500
192.0.2.4 24
--------------030107060003090907030709-- From nobody Mon Oct 6 13:01:12 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 402391A898A for ; Mon, 6 Oct 2014 13: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 xDU-lGtxebWI for ; Mon, 6 Oct 2014 13:01:07 -0700 (PDT) Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ACBA1A8974 for ; Mon, 6 Oct 2014 13:01:07 -0700 (PDT) Received: by mail-qc0-f171.google.com with SMTP id i17so4557882qcy.2 for ; Mon, 06 Oct 2014 13:01: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=v7iAM/eXkExVBOO3TmyParvRRh3OjC4o/LZTvuhZMRw=; b=IBrQ7JNPSd8/Jx2jz3unZ5JhJhXcwlImF8Z6/IgwlqInJnVHFfNnp+yDTpuqLXUwaZ onJ9F1W9CZlgIrwzdBIDops0zONoWdf1rWybFF0gIfM4HBNlPbtc5kaqwkHIhWS9B177 rVy2XgTlX+6OCNb/ajlZpF5iIWa8H1+RozeD45w7MCBDahR8EPKy2c8dzwWsl8DT26ti TXCq/XFnGkWsLUqTuCz00+G4zugQC3h5VEHHBI1tzlyJHnelxJzP4CKDr8K6d0tRfFiq GtPa4rBQbq5psilgg6zw2VjBgpibb8sqN1ORe/9hTKTDFpyWIIZiv4KW+gcEiYnRNEvt JDVw== X-Gm-Message-State: ALoCoQml/2CLKXYcvA6Bkj6Q5OF5uBWk60H9CPFgaSNl6KjXEXwMnUPKiNmq+UzwMccZSR4TkD6q MIME-Version: 1.0 X-Received: by 10.140.39.37 with SMTP id u34mr30677192qgu.36.1412625666342; Mon, 06 Oct 2014 13:01:06 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Mon, 6 Oct 2014 13:01:06 -0700 (PDT) In-Reply-To: <54327ACA.3090606@ericsson.com> References: <54327ACA.3090606@ericsson.com> Date: Mon, 6 Oct 2014 13:01:06 -0700 Message-ID: From: Andy Bierman To: Balazs Lengyel Content-Type: multipart/alternative; boundary=001a11c120d20b4bef0504c68b60 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/E4ERs3LLOBQj_tWPS3R-IbyIWFQ Cc: "netmod@ietf.org" , EGBOSCH Subject: Re: [netmod] non-unique leaf-lists X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 06 Oct 2014 20:01:10 -0000 --001a11c120d20b4bef0504c68b60 Content-Type: text/plain; charset=ISO-8859-1 Hi, On Mon, Oct 6, 2014 at 4:19 AM, Balazs Lengyel wrote: > Hello, > After the New York interim I volunteered to write a proposal about how to > implement leaf-lists that might have non-unique (repeated) values. I > attached my proposal for it. Please comment! > regards Balazs There are two interesting data modeling issues raised in your proposal. I think we should identify and agree on the problems first, and then pick apart the solution details after that. I-1) Do all leaf-lists need to be edited as individual components? [current: yes, propose: no] Can the data model specify that all leaf-list values are provided/replaced at once? Or is this also a protocol issue? Note that current "replace" operation for leaf-list is a no-op because it replaces the individual value with the same value. I-2) Do all leaf-lists need to contain unique values? [current: yes, propose: no] Depending on I-1, position-based editing may not be needed. One work-around is to always put this sort of leaf-list in its own container so the "replace" operation on the container can be used. IMO both issues should be addressed in YANG 1.1 (and in NETCONF if needed). The solution for position-based editing looks OK to me. Andy --001a11c120d20b4bef0504c68b60 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

On Mon, Oct 6, 2014 at 4:19 AM, Balazs Lengyel <= ;balazs.le= ngyel@ericsson.com> wrote:
= Hello,
After the New York interim I volunteered to write a proposal about how to i= mplement leaf-lists that might have non-unique (repeated) values. I attache= d my proposal for it. Please comment!
regards Balazs


There are two= interesting data modeling issues raised in your proposal.
I thin= k we should identify and agree on the problems first, and then pick apart t= he
solution details after that.

I-1) Do = all leaf-lists need to be edited as individual components? [current: yes, p= ropose: no]
Can the data model specify that all leaf-list values = are provided/replaced at once?
Or is this also a protocol issue?<= /div>
Note that current "replace" operation for leaf-list is = a no-op because
it replaces the individual value with the sam= e value.

I-2) Do all leaf-lists need to contain un= ique values? [current: yes, propose: no]
Depending on I-1, positi= on-based editing may not be needed.
One work-around is to always = put this sort of leaf-list in its own container
so the "repl= ace" operation on the container can be used.

= IMO both issues should be addressed in YANG 1.1 (and in NETCONF if needed).=
The solution for position-based editing looks OK to me.


Andy


--001a11c120d20b4bef0504c68b60-- From nobody Mon Oct 6 14:17:35 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7895E1A1A19 for ; Mon, 6 Oct 2014 14:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.286 X-Spam-Level: X-Spam-Status: No, score=-15.286 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNFjrjHwXhKU for ; Mon, 6 Oct 2014 14:17: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 72B7F1A8A3C for ; Mon, 6 Oct 2014 14:17:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14205; q=dns/txt; s=iport; t=1412630245; x=1413839845; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=92wh+EEMi+cMymRvNC7tu5DddOh9WZOrkdIjdA3R6LY=; b=OjXc6Tpifh8WFDq5vIOigOHKRcc9D5xZ+zl7GFRxJFj+Pj7d05ixAd9z GO9TBGfQtrgc7DMLdTeXK36YxerrGbN/v7oMIZbSCickcwe6NUcPRsO5K Hte3p9IzanLCjNnf2wSbqM24+V9yuNEivXsNUNn0qgqkRR9ofIRoZ7tDO g=; X-IronPort-AV: E=Sophos;i="5.04,665,1406592000"; d="scan'208,217";a="201909195" 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; 06 Oct 2014 21:17:23 +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 s96LHMdB022338; Mon, 6 Oct 2014 21:17:22 GMT Message-ID: <543306E2.4060206@cisco.com> Date: Mon, 06 Oct 2014 23:17:22 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: "Thomas D. Nadeau" , Andy Bierman References: <79C50B72-6505-4A01-A3FE-6A5FEBD71750@lucidvision.com> <8ECCF40D-132A-4662-B983-3D5B94211AD4@lucidvision.com> In-Reply-To: <8ECCF40D-132A-4662-B983-3D5B94211AD4@lucidvision.com> Content-Type: multipart/alternative; boundary="------------040505000000010406070300" Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/OZzrg2jLoPfiEX5zQOHiXSWdqFA Cc: "netmod-chairs@tools.ietf.org" , NETMOD Working Group , "netmod-ads@tools.ietf.org" Subject: Re: [netmod] NETMOD Interim Meeting Format 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: Mon, 06 Oct 2014 21:17:33 -0000 This is a multi-part message in MIME format. --------------040505000000010406070300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, I understand that the ACL draft will be updated and presented (draft to be updated), the syslog one as well, and the OSPF. Note: the OSPF will be standardized in the OSPF WG, but I don't see any harm to present in NETMOD since there is a connection with the routing YANG model. Regards, Benoit > > This is the interim meeting. This was the only request for > discussion post my announcement of the meeting, so its going on the > agenda. *) > > --Tom > > On Sep 30, 2014:9:55 AM, at 9:55 AM, Andy Bierman > wrote: > >> Hi, >> >> I would like to finish the current chartered items, instead of >> starting new work. >> IMO new unchartered work can be discussed on the mailing list. >> >> >> Andy >> >> >> On Tue, Sep 30, 2014 at 9:27 AM, Thomas D. Nadeau >> > wrote: >> >> >> Cool. We can add you to the agenda for the next meeting. >> Please prepare to give a brief introduction/review of the draft >> and then have an interactive discussion around it. >> >> --Tom >> >> >> On Sep 30, 2014:9:06 AM, at 9:06 AM, Eric Voit (evoit) >> > wrote: >> >> > I would like to talk about >> draft-voit-netmod-peer-mount-requirements >> > at an upcoming (next Wednesday's?) meeting. Can you put it on >> the agenda? >> > >> > Alex is also aiming to have "-02" of draft-clemm-netmod-mount >> > available Friday. It would be good to talk about that as well. >> > >> > Thanks, >> > Eric >> > >> >> -----Original Message----- >> >> From: netmod [mailto:netmod-bounces@ietf.org >> ] On Behalf Of Thomas D. >> >> Nadeau >> >> Sent: Thursday, September 25, 2014 10:21 AM >> >> To: NETMOD Working Group >> >> Cc: netmod-chairs@tools.ietf.org >> ; netmod-ads@tools.ietf.org >> >> >> Subject: [netmod] NETMOD Interim Meeting Format Update >> >> >> >> >> >> Netmod WG: >> >> >> >> Juergen, Benoit and I have discussed a plan by which we >> will divide up >> >> the interim meetings into two categories. Going forward, we >> will alternate >> >> meetings each week to focus on either a) Yang Model production >> or b) Yang 1.1 >> >> updates/issue discussion/resolution. Starting with the next >> scheduled meeting >> >> two weeks on Wednesday, October 8, 2012, we will begin this >> cadence with a) >> >> and then b), and as such will be working on Yang Model >> production at that >> >> meeting. The following meeting will focus on b) and so on. >> >> >> >> Ahead of each Yang Modeling meeting I would like to ask >> that those >> >> wishing to propose models for discussion do so as early as >> possible so that an >> >> agenda can be assembled ahead of time. Please either post >> proposals to the >> >> NETMOD list or to me directly and I will keep track of >> proposals in the issue >> >> tracker. Also, in order to address feedback we have received >> after the last >> >> official IETF meeting that the agenda slots are too tight to >> facilitate >> >> significant/detailed discussion of models, the meeting format >> will be fairly loose >> >> to allow for extensive discussion/hacking of models. Given >> this change it is >> >> possible that if significant discussion and progress is made >> on a single model, >> >> that only that single model will be discussed during an entire >> meeting. It is >> >> possible too that if that discussion is not concluded, that it >> spills over into the >> >> next meeting two weeks later. >> >> >> >> Meeting minutes/notes will be kept in the same format and >> posted as >> >> are done for the current meetings. >> >> >> >> If anyone has suggestions/questions regarding the meeting >> format >> >> updates, please discuss here. >> >> >> >> Cheers, >> >> >> >> --Tom >> >> >> >> >> > >> > >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> >> > --------------040505000000010406070300 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear all,

I understand that the ACL draft will be updated and presented (draft to be updated), the syslog one as well, and the OSPF.
Note: the OSPF will be standardized in the OSPF WG, but I don't see any harm to present in NETMOD since there is a connection with the routing YANG model.

Regards, Benoit

This is the interim meeting.   This was the only request for discussion post my announcement of the meeting, so its going on the agenda. *)

--Tom

On Sep 30, 2014:9:55 AM, at 9:55 AM, Andy Bierman <andy@yumaworks.com> wrote:

Hi,

I would like to finish the current chartered items, instead of starting new work.
IMO new unchartered work can be discussed on the mailing list.


Andy


On Tue, Sep 30, 2014 at 9:27 AM, Thomas D. Nadeau <tnadeau@lucidvision.com> wrote:

        Cool. We can add you to the agenda for the next meeting.  Please prepare to give a brief introduction/review of the draft and then have an interactive discussion around it.

        --Tom


On Sep 30, 2014:9:06 AM, at 9:06 AM, Eric Voit (evoit) <evoit@cisco.com> wrote:

> I would like to talk about draft-voit-netmod-peer-mount-requirements
> at an upcoming (next Wednesday's?) meeting.   Can you put it on the agenda?
>
> Alex is also aiming to have "-02" of  draft-clemm-netmod-mount
> available Friday.  It would be good to talk about that as well.
>
> Thanks,
> Eric
>
>> -----Original Message-----
>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Thomas D.
>> Nadeau
>> Sent: Thursday, September 25, 2014 10:21 AM
>> To: NETMOD Working Group
>> Cc: netmod-chairs@tools.ietf.org; netmod-ads@tools.ietf.org
>> Subject: [netmod] NETMOD Interim Meeting Format Update
>>
>>
>>      Netmod WG:
>>
>>      Juergen, Benoit and I have discussed a plan by which we will divide up
>> the interim meetings into two categories. Going forward, we will alternate
>> meetings each week to focus on either a) Yang Model production or b) Yang 1.1
>> updates/issue discussion/resolution.  Starting with the next scheduled meeting
>> two weeks on Wednesday, October 8, 2012, we will begin this cadence with a)
>> and then b), and as such will be working on Yang Model production at that
>> meeting. The following meeting will focus on b) and so on.
>>
>>      Ahead of each Yang Modeling meeting I would like to ask that those
>> wishing to propose models for discussion do so as early as possible so that an
>> agenda can be assembled ahead of time. Please either post proposals to the
>> NETMOD list or to me directly and I will keep track of proposals in the issue
>> tracker. Also, in order to address feedback we have received after the last
>> official IETF meeting that the agenda slots are too tight to facilitate
>> significant/detailed discussion of models, the meeting format will be fairly loose
>> to allow for extensive discussion/hacking of models.  Given this change it is
>> possible that if significant discussion and progress is made on a single model,
>> that only that single model will be discussed during an entire meeting. It is
>> possible too that if that discussion is not concluded, that it spills over into the
>> next meeting two weeks later.
>>
>>      Meeting minutes/notes will be kept in the same format and posted as
>> are done for the current meetings.
>>
>>      If anyone has suggestions/questions regarding the meeting format
>> updates, please discuss here.
>>
>>      Cheers,
>>
>>      --Tom
>>
>>
>
>


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




--------------040505000000010406070300-- From nobody Mon Oct 6 14:30:11 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 959BD1A8A55 for ; Mon, 6 Oct 2014 14:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.286 X-Spam-Level: X-Spam-Status: No, score=-15.286 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CApbh5isVzlK for ; Mon, 6 Oct 2014 14:30:05 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 017591A8A04 for ; Mon, 6 Oct 2014 14:30:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11978; q=dns/txt; s=iport; t=1412631005; x=1413840605; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=FAHYFkhD+gvqsHvhkZYNf3kyWWXQbkMggJV3fIGzGPg=; b=BiAkbi4xLKvV7TCeLbQphcZnRa5dtBHxuy28qI15bNduKA/Ep6vO0uMy Nqln1P+Eql5xSluKzrg7UVGCjWXxk+rEC4Gf3JIX0WFzvc0HBuRARb1De rbjxM0lHqOKhnuvj5Ck0cauxMkppnVCkkIS0BYT//W1y4ogp/hdsyWQFH M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAOwIM1StJA2M/2dsb2JhbABfgw5TTQsEzBgBCYZ5VAKBBxYBe4QDAQEBAwEBAQFrCwUHBAIBCBEEAQEoBycLFAkIAgQOBYg2CA3BPQETBI9YbQcGgyeBHgWLHYZXhn2ETYEtg0KKAIcRg2NsgUiBAgEBAQ X-IronPort-AV: E=Sophos; i="5.04,665,1406592000"; d="scan'208,217"; a="84530403" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-2.cisco.com with ESMTP; 06 Oct 2014 21:30:04 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s96LU3W7000787 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 Oct 2014 21:30:03 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.175]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Mon, 6 Oct 2014 16:30:03 -0500 From: "Acee Lindem (acee)" To: "Benoit Claise (bclaise)" Thread-Topic: [netmod] NETMOD Interim Meeting Format Update Thread-Index: AQHP2MwO8703bAbImUWr+5+84Iwqb5waMzUAgAAF5oCAAAfnAIAABY0AgAmxgACAAAOGgA== Date: Mon, 6 Oct 2014 21:30:02 +0000 Message-ID: <518135C4-1807-4733-8AEC-CC3D4CC9A2B7@cisco.com> References: <79C50B72-6505-4A01-A3FE-6A5FEBD71750@lucidvision.com> <8ECCF40D-132A-4662-B983-3D5B94211AD4@lucidvision.com> <543306E2.4060206@cisco.com> In-Reply-To: <543306E2.4060206@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.197] Content-Type: multipart/alternative; boundary="_000_518135C4180747338AECCC3D4CC9A2B7ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/wwKGV2RmgtYO4SaOyig8NEsC4GI Cc: "netmod-chairs@tools.ietf.org" , "netmod-ads@tools.ietf.org" , NETMOD Working Group Subject: Re: [netmod] NETMOD Interim Meeting Format 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: Mon, 06 Oct 2014 21:30:07 -0000 --_000_518135C4180747338AECCC3D4CC9A2B7ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Oct 6, 2014, at 5:17 PM, Benoit Claise > wrote: Dear all, I understand that the ACL draft will be updated and presented (draft to be = updated), the syslog one as well, and the OSPF. Note: the OSPF will be standardized in the OSPF WG, but I don't see any har= m to present in NETMOD since there is a connection with the routing YANG mo= del. OSPF WG Chair Hat On: I think it would be great to have the OSPF model presented and reviewed = in netmod as well. Thanks, Acee Regards, Benoit This is the interim meeting. This was the only request for discussion pos= t my announcement of the meeting, so its going on the agenda. *) --Tom On Sep 30, 2014:9:55 AM, at 9:55 AM, Andy Bierman > wrote: Hi, I would like to finish the current chartered items, instead of starting new= work. IMO new unchartered work can be discussed on the mailing list. Andy On Tue, Sep 30, 2014 at 9:27 AM, Thomas D. Nadeau > wrote: Cool. We can add you to the agenda for the next meeting. Please pr= epare to give a brief introduction/review of the draft and then have an int= eractive discussion around it. --Tom On Sep 30, 2014:9:06 AM, at 9:06 AM, Eric Voit (evoit) > wrote: > I would like to talk about draft-voit-netmod-peer-mount-requirements > at an upcoming (next Wednesday's?) meeting. Can you put it on the agend= a? > > Alex is also aiming to have "-02" of draft-clemm-netmod-mount > available Friday. It would be good to talk about that as well. > > Thanks, > Eric > >> -----Original Message----- >> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Thomas D. >> Nadeau >> Sent: Thursday, September 25, 2014 10:21 AM >> To: NETMOD Working Group >> Cc: netmod-chairs@tools.ietf.org; n= etmod-ads@tools.ietf.org >> Subject: [netmod] NETMOD Interim Meeting Format Update >> >> >> Netmod WG: >> >> Juergen, Benoit and I have discussed a plan by which we will divide= up >> the interim meetings into two categories. Going forward, we will alterna= te >> meetings each week to focus on either a) Yang Model production or b) Yan= g 1.1 >> updates/issue discussion/resolution. Starting with the next scheduled m= eeting >> two weeks on Wednesday, October 8, 2012, we will begin this cadence with= a) >> and then b), and as such will be working on Yang Model production at tha= t >> meeting. The following meeting will focus on b) and so on. >> >> Ahead of each Yang Modeling meeting I would like to ask that those >> wishing to propose models for discussion do so as early as possible so t= hat an >> agenda can be assembled ahead of time. Please either post proposals to t= he >> NETMOD list or to me directly and I will keep track of proposals in the = issue >> tracker. Also, in order to address feedback we have received after the l= ast >> official IETF meeting that the agenda slots are too tight to facilitate >> significant/detailed discussion of models, the meeting format will be fa= irly loose >> to allow for extensive discussion/hacking of models. Given this change = it is >> possible that if significant discussion and progress is made on a single= model, >> that only that single model will be discussed during an entire meeting. = It is >> possible too that if that discussion is not concluded, that it spills ov= er into the >> next meeting two weeks later. >> >> Meeting minutes/notes will be kept in the same format and posted as >> are done for the current meetings. >> >> If anyone has suggestions/questions regarding the meeting format >> updates, please discuss here. >> >> Cheers, >> >> --Tom >> >> > > _______________________________________________ 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 --_000_518135C4180747338AECCC3D4CC9A2B7ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <693E02AF87C82048A1B951AF655CB0D5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
On Oct 6, 2014, at 5:17 PM, Benoit Claise <bclaise@cisco.com> wrote:

Dear all,

I understand that the ACL draft will be updated and presented (draft to be = updated), the syslog one as well, and the OSPF.
Note: the OSPF will be standardized in the OSPF WG, but I don't see any har= m to present in NETMOD since there is a connection with the routing YANG mo= del.

OSPF WG Chair Hat On:

   I think it would be great to have the OSPF model presente= d and reviewed in netmod as well.  

Thanks,
Acee  




Regards, Benoit

This is the= interim meeting.   This was the only request for discussion post my a= nnouncement of the meeting, so its going on the agenda. *)

--Tom<= /div>

On Sep 30, 2014:9:55 AM, at 9:55 AM, Andy Bierman <andy@yumaworks.com> w= rote:

Hi,

I would like to finish the current chartered items, instead of startin= g new work.
IMO new unchartered work can be discussed on the mailing list.


Andy


On Tue, Sep 30, 2014 at 9:27 AM, Thomas D. Nadea= u <tnadeau@lucidvision.com> wrote:

        Cool. We can add you to the agenda for the next= meeting.  Please prepare to give a brief introduction/review of the d= raft and then have an interactive discussion around it.

        --Tom


On Sep 30, 2014:9:06 AM, at 9:06 AM, Eric Voit (evoit) <evoit@cisco.com> wrote:<= br>
> I would like to talk about draft-voit-netmod-peer-mount-requirements > at an upcoming (next Wednesday's?) meeting.   Can you put it= on the agenda?
>
> Alex is also aiming to have "-02" of  draft-clemm-netmo= d-mount
> available Friday.  It would be good to talk about that as well. >
> Thanks,
> Eric
>
>> -----Original Message-----
>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Thomas D.<= br> >> Nadeau
>> Sent: Thursday, September 25, 2014 10:21 AM
>> To: NETMOD Working Group
>> Cc: netmod-chairs@tools.ietf.org; netmo= d-ads@tools.ietf.org
>> Subject: [netmod] NETMOD Interim Meeting Format Update
>>
>>
>>      Netmod WG:
>>
>>      Juergen, Benoit and I have discussed a plan by= which we will divide up
>> the interim meetings into two categories. Going forward, we will a= lternate
>> meetings each week to focus on either a) Yang Model production or = b) Yang 1.1
>> updates/issue discussion/resolution.  Starting with the next = scheduled meeting
>> two weeks on Wednesday, October 8, 2012, we will begin this cadenc= e with a)
>> and then b), and as such will be working on Yang Model production = at that
>> meeting. The following meeting will focus on b) and so on.
>>
>>      Ahead of each Yang Modeling meeting I would li= ke to ask that those
>> wishing to propose models for discussion do so as early as possibl= e so that an
>> agenda can be assembled ahead of time. Please either post proposal= s to the
>> NETMOD list or to me directly and I will keep track of proposals i= n the issue
>> tracker. Also, in order to address feedback we have received after= the last
>> official IETF meeting that the agenda slots are too tight to facil= itate
>> significant/detailed discussion of models, the meeting format will= be fairly loose
>> to allow for extensive discussion/hacking of models.  Given t= his change it is
>> possible that if significant discussion and progress is made on a = single model,
>> that only that single model will be discussed during an entire mee= ting. It is
>> possible too that if that discussion is not concluded, that it spi= lls over into the
>> next meeting two weeks later.
>>
>>      Meeting minutes/notes will be kept in the same= format and posted as
>> are done for the current meetings.
>>
>>      If anyone has suggestions/questions regarding = the meeting format
>> updates, please discuss here.
>>
>>      Cheers,
>>
>>      --Tom
>>
>>
>
>


_______________________________________________
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

--_000_518135C4180747338AECCC3D4CC9A2B7ciscocom_-- From nobody Mon Oct 6 15:19:34 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 484851A8AB6; Mon, 6 Oct 2014 15:19:31 -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 zRXaCB5fpe6S; Mon, 6 Oct 2014 15:19:29 -0700 (PDT) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42A4C1A8913; Mon, 6 Oct 2014 15:19:29 -0700 (PDT) Received: by mail-yk0-f182.google.com with SMTP id 131so2347320ykp.41 for ; Mon, 06 Oct 2014 15:19:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=1fPiCtUO5Bu1eDzi8oncCocfnYFwXKjBjZT9JwNBsg4=; b=EKIEMRO2azqh11/TpJWPpvXOG5A4WuqaYpU0gbowzuWeFQgeP5zyMBXLm4gqFz0nQZ +RjMxzurQWnjHS0lnpcZN82lg24wPK2JNIcyO3SJMpedM4ZpCPDi7lJwipXUTbm44iMT NZVYSzArFnDr5elTVWsOTZZO+ZgT/0N4iDgQI74p3uIQ3qrH7IBRz+HDzUJFQeQTEt2o DtHFkY5WGkDjhnUPcFoZBHfaH+pJw8boNOhzCcvZf+H8KBX+/OBVURqeyjPyEST73mXb UIUSuP0u1iK47OI4/YjL2eWCXS61/zMw6iHMMMKP+JaJ5QrbZpZ78BB7byozWm/9jCo1 aKCw== MIME-Version: 1.0 X-Received: by 10.236.87.227 with SMTP id y63mr28746561yhe.25.1412633968630; Mon, 06 Oct 2014 15:19:28 -0700 (PDT) Received: by 10.170.113.134 with HTTP; Mon, 6 Oct 2014 15:19:28 -0700 (PDT) Date: Mon, 6 Oct 2014 18:19:28 -0400 Message-ID: From: Alia Atlas To: "i2rs@ietf.org" , "netmod@ietf.org" , "rtgwg@ietf.org" , "isis-wg@ietf.org" , OSPF List , "idr@ietf. org" , "routing-discussion@ietf.org" Content-Type: multipart/alternative; boundary=20cf3010eabde5e0fb0504c879ae Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/_J_5UIiWtfCUq8VlQnYNG0agwTY Cc: Adrian Farrel Subject: [netmod] Creation of rtg-yang-coord mailing list X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 06 Oct 2014 22:19:31 -0000 --20cf3010eabde5e0fb0504c879ae Content-Type: text/plain; charset=UTF-8 The rtg-yang-coord mailing list will provide a forum for coordination of the development of YANG models being worked on for Routing, in order to provide a consistent view to the NMS. The intended participants are people active in Routing working groups and interested in the associated YANG models, and YANG experts assisting with Routing YANG models. While this list will help with the synchronization, WGs with responsibility for core routing protocols are expected to also be responsible for the development of YANG models for those protocols. To subscribe, visit: https://www.ietf.org/mailman/listinfo/rtg-yang-coord Regards, Alia --20cf3010eabde5e0fb0504c879ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

The rtg-yang-coord mailing list will provide a f= orum for coordination of the development=C2=A0=C2=A0of YANG models being wo= rked on for Routing, in order to provide a=C2=A0consistent view to the NMS.= =C2=A0 The intended participants are people active in Routing working group= s and interested in the=C2=A0associated YANG models, and YANG experts assis= ting with Routing YANG=C2=A0models. While this list=C2=A0will help with the= synchronization, WGs with responsibility for core=C2=A0routing protocols a= re expected=C2=A0=C2=A0to also be responsible for the development of YANG m= odels for those=C2=A0=C2=A0protocols.=C2=A0

To subscribe, visi= t:

= https://ww= w.ietf.org/mailman/listinfo/rtg-yang-coord

Regar= ds,

Alia

--20cf3010eabde5e0fb0504c879ae-- From nobody Mon Oct 6 18:29:10 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 265ED1A0242 for ; Mon, 6 Oct 2014 18:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.173 X-Spam-Level: X-Spam-Status: No, score=-1.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHWvZdNS_4hJ for ; Mon, 6 Oct 2014 18:29:05 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 664FC1A90F8 for ; Mon, 6 Oct 2014 18:29:05 -0700 (PDT) Received: from [10.147.230.57] (unknown [166.170.36.152]) by lucidvision.com (Postfix) with ESMTP id 2C08228B42B1; Mon, 6 Oct 2014 21:29:04 -0400 (EDT) Content-Type: multipart/alternative; boundary=Apple-Mail-09E0B5DB-9D0E-4CF1-AE66-37FE8DD5AE1A Mime-Version: 1.0 (1.0) From: Thomas Nadeau X-Mailer: iPhone Mail (12A405) In-Reply-To: <518135C4-1807-4733-8AEC-CC3D4CC9A2B7@cisco.com> Date: Mon, 6 Oct 2014 18:29:02 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <79C50B72-6505-4A01-A3FE-6A5FEBD71750@lucidvision.com> <8ECCF40D-132A-4662-B983-3D5B94211AD4@lucidvision.com> <543306E2.4060206@cisco.com> <518135C4-1807-4733-8AEC-CC3D4CC9A2B7@cisco.com> To: "Acee Lindem (acee)" Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Dc2ZiRqjpCGBgzMQ7a_3bpifwAQ Cc: "netmod-chairs@tools.ietf.org" , "netmod-ads@tools.ietf.org" , NETMOD Working Group Subject: Re: [netmod] NETMOD Interim Meeting Format 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, 07 Oct 2014 01:29:08 -0000 --Apple-Mail-09E0B5DB-9D0E-4CF1-AE66-37FE8DD5AE1A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable We are glad to support this. The interim meetings held every other week are a= place to hash out and work on models regardless of which WG they belong in.= Of course of the agenda fills up we may need to prioritize but for now we h= ave room and so I want to support this as best I can. Tom (netmod hat on) > On Oct 6, 2014, at 2:30 PM, Acee Lindem (acee) wrote: >=20 >=20 >> On Oct 6, 2014, at 5:17 PM, Benoit Claise wrote: >>=20 >> Dear all, >>=20 >> I understand that the ACL draft will be updated and presented (draft to b= e updated), the syslog one as well, and the OSPF. >> Note: the OSPF will be standardized in the OSPF WG, but I don't see any h= arm to present in NETMOD since there is a connection with the routing YANG m= odel. >=20 > OSPF WG Chair Hat On: >=20 > I think it would be great to have the OSPF model presented and reviewed= in netmod as well. =20 >=20 > Thanks, > Acee =20 >=20 >=20 >=20 >>=20 >> Regards, Benoit >>>=20 >>> This is the interim meeting. This was the only request for discussion p= ost my announcement of the meeting, so its going on the agenda. *) >>>=20 >>> --Tom >>>=20 >>>> On Sep 30, 2014:9:55 AM, at 9:55 AM, Andy Bierman w= rote: >>>>=20 >>>> Hi, >>>>=20 >>>> I would like to finish the current chartered items, instead of starting= new work. >>>> IMO new unchartered work can be discussed on the mailing list. >>>>=20 >>>>=20 >>>> Andy >>>>=20 >>>>=20 >>>>> On Tue, Sep 30, 2014 at 9:27 AM, Thomas D. Nadeau wrote: >>>>>=20 >>>>> Cool. We can add you to the agenda for the next meeting. Plea= se prepare to give a brief introduction/review of the draft and then have an= interactive discussion around it. >>>>>=20 >>>>> --Tom >>>>>=20 >>>>>=20 >>>>> On Sep 30, 2014:9:06 AM, at 9:06 AM, Eric Voit (evoit) wrote: >>>>>=20 >>>>> > I would like to talk about draft-voit-netmod-peer-mount-requirements= >>>>> > at an upcoming (next Wednesday's?) meeting. Can you put it on the a= genda? >>>>> > >>>>> > Alex is also aiming to have "-02" of draft-clemm-netmod-mount >>>>> > available Friday. It would be good to talk about that as well. >>>>> > >>>>> > Thanks, >>>>> > Eric >>>>> > >>>>> >> -----Original Message----- >>>>> >> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Thomas D= . >>>>> >> Nadeau >>>>> >> Sent: Thursday, September 25, 2014 10:21 AM >>>>> >> To: NETMOD Working Group >>>>> >> Cc: netmod-chairs@tools.ietf.org; netmod-ads@tools.ietf.org >>>>> >> Subject: [netmod] NETMOD Interim Meeting Format Update >>>>> >> >>>>> >> >>>>> >> Netmod WG: >>>>> >> >>>>> >> Juergen, Benoit and I have discussed a plan by which we will d= ivide up >>>>> >> the interim meetings into two categories. Going forward, we will al= ternate >>>>> >> meetings each week to focus on either a) Yang Model production or b= ) Yang 1.1 >>>>> >> updates/issue discussion/resolution. Starting with the next schedu= led meeting >>>>> >> two weeks on Wednesday, October 8, 2012, we will begin this cadence= with a) >>>>> >> and then b), and as such will be working on Yang Model production a= t that >>>>> >> meeting. The following meeting will focus on b) and so on. >>>>> >> >>>>> >> Ahead of each Yang Modeling meeting I would like to ask that t= hose >>>>> >> wishing to propose models for discussion do so as early as possible= so that an >>>>> >> agenda can be assembled ahead of time. Please either post proposals= to the >>>>> >> NETMOD list or to me directly and I will keep track of proposals in= the issue >>>>> >> tracker. Also, in order to address feedback we have received after t= he last >>>>> >> official IETF meeting that the agenda slots are too tight to facili= tate >>>>> >> significant/detailed discussion of models, the meeting format will b= e fairly loose >>>>> >> to allow for extensive discussion/hacking of models. Given this ch= ange it is >>>>> >> possible that if significant discussion and progress is made on a s= ingle model, >>>>> >> that only that single model will be discussed during an entire meet= ing. It is >>>>> >> possible too that if that discussion is not concluded, that it spil= ls over into the >>>>> >> next meeting two weeks later. >>>>> >> >>>>> >> Meeting minutes/notes will be kept in the same format and post= ed as >>>>> >> are done for the current meetings. >>>>> >> >>>>> >> If anyone has suggestions/questions regarding the meeting form= at >>>>> >> updates, please discuss here. >>>>> >> >>>>> >> Cheers, >>>>> >> >>>>> >> --Tom >>>>> >> >>>>> >> >>>>> > >>>>> > >>>>>=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 --Apple-Mail-09E0B5DB-9D0E-4CF1-AE66-37FE8DD5AE1A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
We are glad to support this. The interim meetings held every other week are a place to hash out and work on models regardless of which WG they belong in. Of course of the agenda fills up we may need to prioritize but for now we have room and so I want to support this as best I can.

Tom (netmod hat on)



On Oct 6, 2014, at 2:30 PM, Acee Lindem (acee) <acee@cisco.com> wrote:


On Oct 6, 2014, at 5:17 PM, Benoit Claise <bclaise@cisco.com> wrote:

Dear all,

I understand that the ACL draft will be updated and presented (draft to be updated), the syslog one as well, and the OSPF.
Note: the OSPF will be standardized in the OSPF WG, but I don't see any harm to present in NETMOD since there is a connection with the routing YANG model.

OSPF WG Chair Hat On:

   I think it would be great to have the OSPF model presented and reviewed in netmod as well.  

Thanks,
Acee  




Regards, Benoit

This is the interim meeting.   This was the only request for discussion post my announcement of the meeting, so its going on the agenda. *)

--Tom

On Sep 30, 2014:9:55 AM, at 9:55 AM, Andy Bierman <andy@yumaworks.com> wrote:

Hi,

I would like to finish the current chartered items, instead of starting new work.
IMO new unchartered work can be discussed on the mailing list.


Andy


On Tue, Sep 30, 2014 at 9:27 AM, Thomas D. Nadeau <tnadeau@lucidvision.com> wrote:

        Cool. We can add you to the agenda for the next meeting.  Please prepare to give a brief introduction/review of the draft and then have an interactive discussion around it.

        --Tom


On Sep 30, 2014:9:06 AM, at 9:06 AM, Eric Voit (evoit) <evoit@cisco.com> wrote:

> I would like to talk about draft-voit-netmod-peer-mount-requirements
> at an upcoming (next Wednesday's?) meeting.   Can you put it on the agenda?
>
> Alex is also aiming to have "-02" of  draft-clemm-netmod-mount
> available Friday.  It would be good to talk about that as well.
>
> Thanks,
> Eric
>
>> -----Original Message-----
>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Thomas D.
>> Nadeau
>> Sent: Thursday, September 25, 2014 10:21 AM
>> To: NETMOD Working Group
>> Cc: netmod-chairs@tools.ietf.org; netmod-ads@tools.ietf.org
>> Subject: [netmod] NETMOD Interim Meeting Format Update
>>
>>
>>      Netmod WG:
>>
>>      Juergen, Benoit and I have discussed a plan by which we will divide up
>> the interim meetings into two categories. Going forward, we will alternate
>> meetings each week to focus on either a) Yang Model production or b) Yang 1.1
>> updates/issue discussion/resolution.  Starting with the next scheduled meeting
>> two weeks on Wednesday, October 8, 2012, we will begin this cadence with a)
>> and then b), and as such will be working on Yang Model production at that
>> meeting. The following meeting will focus on b) and so on.
>>
>>      Ahead of each Yang Modeling meeting I would like to ask that those
>> wishing to propose models for discussion do so as early as possible so that an
>> agenda can be assembled ahead of time. Please either post proposals to the
>> NETMOD list or to me directly and I will keep track of proposals in the issue
>> tracker. Also, in order to address feedback we have received after the last
>> official IETF meeting that the agenda slots are too tight to facilitate
>> significant/detailed discussion of models, the meeting format will be fairly loose
>> to allow for extensive discussion/hacking of models.  Given this change it is
>> possible that if significant discussion and progress is made on a single model,
>> that only that single model will be discussed during an entire meeting. It is
>> possible too that if that discussion is not concluded, that it spills over into the
>> next meeting two weeks later.
>>
>>      Meeting minutes/notes will be kept in the same format and posted as
>> are done for the current meetings.
>>
>>      If anyone has suggestions/questions regarding the meeting format
>> updates, please discuss here.
>>
>>      Cheers,
>>
>>      --Tom
>>
>>
>
>


_______________________________________________
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-09E0B5DB-9D0E-4CF1-AE66-37FE8DD5AE1A-- From nobody Tue Oct 7 11:51:42 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7491A7028 for ; Tue, 7 Oct 2014 11:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.285 X-Spam-Level: X-Spam-Status: No, score=-15.285 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, RP_MATCHES_RCVD=-0.786, 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 VGLHs_n9rrBS for ; Tue, 7 Oct 2014 11:51:38 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 673AC1A8748 for ; Tue, 7 Oct 2014 11:51:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5790; q=dns/txt; s=iport; t=1412707898; x=1413917498; h=from:to:cc:subject:date:message-id:mime-version; bh=PsgEjFfTVsixWH/YdmSabbedLPx674YrZbRzY+NeoT0=; b=g1QskHstvY+/1/zyVbpiuh6dMNi2qs4X0zr/t/+J0KHVc6vlUJvko2Vr oa/jMTdl8CRnsxS3IbN2xa6vzxb/h9wBwA58O/id+n5XsId5uRKAzPfgE PC9DRhcHuO0xa5QY4IN7DGt0/I/7vAH7QPobPSPF4di9sKs6Sbx7gIGpW 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsFAC41NFStJV2Y/2dsb2JhbABfgkhGU1kDvBmOfoFvh0sCgRAWAXIJhAUBBC1MEgEqViYBBA4NiDYNwi0BF5ATMYM0gR4FkXaEPoh3lB+DY4I0gQIBAQE X-IronPort-AV: E=Sophos;i="5.04,672,1406592000"; d="scan'208,217";a="361446374" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 07 Oct 2014 18:51:37 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s97IpbnY000461 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 7 Oct 2014 18:51:37 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.163]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Tue, 7 Oct 2014 13:51:37 -0500 From: "Alexander Clemm (alex)" To: "netmod@ietf.org" Thread-Topic: New revision of YANG mount draft Thread-Index: Ac/iXt0c8kMXz8u2QICzU6EjzD0qCw== Date: Tue, 7 Oct 2014 18:51:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.205.44] Content-Type: multipart/alternative; boundary="_000_DBC595ED2346914F9F81D17DD5C32B571C81379Dxmbrcdx05ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/zS9_lrEy0y-2sVd7R4mQ8BUoDNM Subject: [netmod] New revision of YANG mount draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 07 Oct 2014 18:51:40 -0000 --_000_DBC595ED2346914F9F81D17DD5C32B571C81379Dxmbrcdx05ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, we just wanted to let you know that we have just posted a new revision of d= raft-clemm-netmod-mount: http://datatracker.ietf.org/doc/draft-clemm-netmod-mount/ This document updates an earlier revision that we had posted about a year a= go. It also addresses requirements and use cases in http://datatracker.ietf.org/doc/draft-voit-ne= tmod-peer-mount-requirements/ Here is the abstract: This document introduces capabilities that allow YANG datastores to reference and incorporate information from remote datastores. This is accomplished by extending YANG with the ability to define mount points that act as references to data nodes in remote datastores, and by providing the necessary means to manage and administer those mount points. This facilitates the development of applications that need to access data that transcends individual network devices while improving network-wide object consistency. This document also lays the groundwork for optional extensions to support subscriptions to remote object updates and transparent caching of objects. These options will speed application performance without sacrificing data consistency. Kind regards --- Alex --_000_DBC595ED2346914F9F81D17DD5C32B571C81379Dxmbrcdx05ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

we just wanted to let you know that we have just pos= ted a new revision of draft-clemm-netmod-mount:

http://datatracker.ietf.org/doc/draft-clemm-netmod-mount/=    

This document updates an earlier revision that we ha= d posted about a year ago.  It also addresses

requirements and use cases in http://datatracker.ietf.org/doc/draft-voit-netmod-peer-mount-requirements/<= /a>

 

Here is the abstract:

 

This document introduces capabilities that allow YAN= G datastores to

   reference and incorporate information f= rom remote datastores.  This

   is accomplished by extending YANG with = the ability to define mount

   points that act as references to data n= odes in remote datastores, and

   by providing the necessary means to man= age and administer those mount

   points.  This facilitates the deve= lopment of applications that need

   to access data that transcends individu= al network devices while

   improving network-wide object consisten= cy.

 

   This document also lays the groundwork = for optional extensions to

   support subscriptions to remote object = updates and transparent

   caching of objects.  These options= will speed application performance

   without sacrificing data consistency.

 

Kind regards

--- Alex

--_000_DBC595ED2346914F9F81D17DD5C32B571C81379Dxmbrcdx05ciscoc_-- From nobody Tue Oct 7 18:55:36 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86B2A1A88DA for ; Tue, 7 Oct 2014 18:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.286 X-Spam-Level: X-Spam-Status: No, score=-15.286 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MEY_MASvB60y for ; Tue, 7 Oct 2014 18:55:33 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 814E31A88E2 for ; Tue, 7 Oct 2014 18:55:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7765; q=dns/txt; s=iport; t=1412733333; x=1413942933; h=from:to:cc:subject:date:message-id:mime-version; bh=IQtzET4BO96Jvp0pZpkKEuDVdYo7xazIKQ3WqKtBKfk=; b=KEkQoAAYpcW/NyJ1NACjre4ae2Wq9H3csgvLzfOSThnnNbG/v4J03aqV cx5D0yL8xxrh6t+M43V4IopOZzBopwwvebcJyivGpWaEW1aa/W3iC73hs zHv+MTzTpHy0quszek2z3v10557A1RtHcNFAVLesC420y54/er7hj/mHV w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuMGAJCYNFStJA2K/2dsb2JhbABfgkhGU1gEvBWOGoFvh0sCgQ0WAXIJhAUBAgItTBIBHQ1WJgEEDg0BiDUNwgsBF5ATMYM0gR4FkXaEPoh3lB+CIIFDbAGBR4ECAQEB X-IronPort-AV: E=Sophos;i="5.04,674,1406592000"; d="scan'208,217";a="361477152" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-3.cisco.com with ESMTP; 08 Oct 2014 01:55:32 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s981tWkn026907 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 8 Oct 2014 01:55:32 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.41]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Tue, 7 Oct 2014 20:55:32 -0500 From: "Eric Voit (evoit)" To: "netmod@ietf.org" Thread-Topic: Peer Mount intro slides for Netmod Interim (was RE: New revision of YANG mount draft) Thread-Index: Ac/imuxouWdT1npqQAyRBa2FkxXa3w== Date: Wed, 8 Oct 2014 01:55:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.134.135] Content-Type: multipart/alternative; boundary="_000_EF64FF31F4C4384DBCE5D513A791C2B120A42E4Dxmbalnx11ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Nb9xsJhH4SpsmtxvB26OM8cYuOw Subject: [netmod] Peer Mount intro slides for Netmod Interim (was RE: New revision of YANG mount draft) X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Oct 2014 01:55:35 -0000 --_000_EF64FF31F4C4384DBCE5D513A791C2B120A42E4Dxmbalnx11ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For those of you who want a copy of the slides Alex & I will be presenting = tomorrow, they can be downloaded here The topics will be introduction to and discussion upon the drafts listed be= low. Thanks, Eric Voit & Alex Clemm From: Alexander Clemm, October 07, 2014 2:52 PM Hi, we just wanted to let you know that we have just posted a new revision of d= raft-clemm-netmod-mount: http://datatracker.ietf.org/doc/draft-clemm-netmod-mount/ This document updates an earlier revision that we had posted about a year a= go. It also addresses requirements and use cases in http://datatracker.ietf.org/doc/draft-voit-ne= tmod-peer-mount-requirements/ Here is the abstract: This document introduces capabilities that allow YANG datastores to reference and incorporate information from remote datastores. This is accomplished by extending YANG with the ability to define mount points that act as references to data nodes in remote datastores, and by providing the necessary means to manage and administer those mount points. This facilitates the development of applications that need to access data that transcends individual network devices while improving network-wide object consistency. This document also lays the groundwork for optional extensions to support subscriptions to remote object updates and transparent caching of objects. These options will speed application performance without sacrificing data consistency. Kind regards --- Alex --_000_EF64FF31F4C4384DBCE5D513A791C2B120A42E4Dxmbalnx11ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

For those of you who w= ant a copy of the slides Alex & I will be presenting tomorrow, they can= be

downloaded here<= /span>

 

The topics will be int= roduction to and discussion upon the drafts listed below.=

 

Thanks,

Eric Voit & Alex C= lemm

 

From: Alexande= r Clemm, October 07, 2014 2:52 PM

Hi,

 

we just wanted to let you know that we have just pos= ted a new revision of draft-clemm-netmod-mount:

http://datatracker.ietf.org/doc/draft-clemm-netmod-mount/=    

This document updates an earlier revision that we ha= d posted about a year ago.  It also addresses

requirements and use cases in http://datatracker.ietf.org/doc/draft-voit-netmod-peer-mount-requirements/<= /a>

 

Here is the abstract:

 

This document introduces capabilities that allow YAN= G datastores to

   reference and incorporate information f= rom remote datastores.  This

   is accomplished by extending YANG with = the ability to define mount

   points that act as references to data n= odes in remote datastores, and

   by providing the necessary means to man= age and administer those mount

   points.  This facilitates the deve= lopment of applications that need

   to access data that transcends individu= al network devices while

   improving network-wide object consisten= cy.

 

   This document also lays the groundwork = for optional extensions to

   support subscriptions to remote object = updates and transparent

   caching of objects.  These options= will speed application performance

   without sacrificing data consistency.

 

Kind regards

--- Alex

--_000_EF64FF31F4C4384DBCE5D513A791C2B120A42E4Dxmbalnx11ciscoc_-- From nobody Tue Oct 7 22:36:48 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 306E81ACD0C for ; Tue, 7 Oct 2014 22:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.678 X-Spam-Level: X-Spam-Status: No, score=-2.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=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 NJGjFTMAEevn for ; Tue, 7 Oct 2014 22:36:43 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id AA5111A9237 for ; Tue, 7 Oct 2014 22:36:42 -0700 (PDT) Received: from [172.20.3.232] (unknown [209.37.255.2]) by lucidvision.com (Postfix) with ESMTP id 2499E28B6654 for ; Wed, 8 Oct 2014 01:36:40 -0400 (EDT) From: "Thomas D. Nadeau" Content-Type: multipart/signed; boundary="Apple-Mail=_C5D2B010-C900-45F5-9283-826D9F1E696C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: <454FAA2B-D7C6-4AD4-98CE-F64B3ABF0D6A@lucidvision.com> Date: Tue, 7 Oct 2014 22:36:36 -0700 To: NETMOD Working Group Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/94VT0SGq41zT7uDoA5b6A8ZGyEc Subject: [netmod] Interim NETMOD WG meeting Wednesday, Oct 8 Draft 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, 08 Oct 2014 05:36:45 -0000 --Apple-Mail=_C5D2B010-C900-45F5-9283-826D9F1E696C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The NETMOD WG will meet in Oct 8, 2014 for an interim meeting = with a focus on Yang model development. The following is the draft = agenda. Meeting time is 7-9AM PST. 1. Agenda Bashing 2. ACL Model - Dean Bogdanovic 3. Syslog Model - Kiran Koushik 4. http://datatracker.ietf.org/doc/draft-clemm-netmod-mount/ - = evoit@cisco.com =20 Meeting Materials: IRC, or Internet Relay Chat, is often used as a real-time = communication capability. IRC software can be found for all operating = systems. The IRC clients comparison chart on Wikipedia can help you pick = one for your operating system = (https://en.wikipedia.org/wiki/Comparison_of_Internet_Relay_Chat_clients#O= perating_system_support) You don't have to have a complex setup to use IRC. You can use = the web client for Freenode, which doesn't require any download or = setup. Just pick a nickname and join #netmod-wg:=20 http://webchat.freenode.net/?channels=3Dietf,netmod-wg IRC channel on freenode called #netmod-wg with integrated = meetbot. Web-ex:=20 Topic: NETMOD WG Date: Every Wednesday, from Wednesday, August 27, 2014 to Wednesday, = October 22, 2014 Time: 4:00 pm, Europe Summer Time (Berlin, GMT+02:00) Meeting Number: 649 102 111 Meeting Password: 1234 ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to = https://ietf.webex.com/ietf/j.php?MTID=3Dmbbe9c321c8e9f472df4ce74c1987a0f0= 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: 1234 4. Click "Join". 5. Follow the instructions that appear on your screen. To view in other time zones or languages, please click the link: https://ietf.webex.com/ietf/j.php?MTID=3Dme720293ef5473cc3bf963302b2f6a8f1= ------------------------------------------------------- To join the audio conference only=20 ------------------------------------------------------- Call-in toll number (US/Canada): 1-650-479-3208 Access code:649 102 111 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/mc 2. On the left navigation bar, click "Support". You can contact me at: cmorgan@amsl.com 1-510-492-4085 To update this meeting to your calendar program (for example Microsoft = Outlook), click this link: https://ietf.webex.com/ietf/j.php?MTID=3Dm4f877f2e629b841380e2d593e4e39b87= WebEx will automatically setup Meeting Manager for Windows the first = time you join a meeting. To save time, you can setup prior to the = meeting by clicking this link: https://ietf.webex.com/ietf/meetingcenter/mcsetup.php The playback of UCF (Universal Communications Format) rich media files = requires appropriate players. To view this type of rich media files in = the meeting, please check whether you have the players installed on your = computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php.=20 http://www.webex.com CCP:+16504793208x649102111#=20 IMPORTANT NOTICE: This WebEx service includes a feature that allows = audio and any documents and other materials exchanged or viewed during = the session to be recorded. By joining this session, you automatically = consent to such recordings. If you do not consent to the recording, = discuss your concerns with the meeting host prior to the start of the = recording or do not join the session. Please note that any such = recordings may be subject to discovery in the event of litigation. --Apple-Mail=_C5D2B010-C900-45F5-9283-826D9F1E696C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUNM1lAAoJEPcO+I7eiUJZLJUP/2XxHufT6ONM5d7VGQtlJcgu qGfd9adCJVN4jF2gVYnDumPlSg/QAI2ZsOSMvJ99VRauvo7U1azsa7a/zVPlxVyG 2apuQA+OBGKu4r4mmyVF//fBALv0TfDjE7sIZvhCB6wc8gUilIP5ID650rNUeEdJ rN+3vAeBIg0gjbFNCBzAWlZZ6CEqFPJ39fxhJtDTes9rCm5ztvuQFt274JFhCrQZ BlyISjBHsKKPn5dsniULq46p58mY9Bwq7T2/WCLLLiA1SNhaJKBHNfWSEbDwnYKi URPq8ILzO8hIVrHg3iwBjMpYLXzyzXY2ErrLbLUq3ILHGh/lOg6Zdi2q7+cG3Oy4 Vnze6Yh6PAL9b5LKTvV/YKCha5Ic1M4y8t18UrykHEN1gNA7hqNNtsIdxw27qMGP 8fUYrGD3BObdLxiwjHoyhQbTFiPAnnR//saONN3/5/vAycF1+eh5cPQ9ylICj1xr Ue6vKSd36JD56D7msBkr7MiZgZjlgp9HVfzSVoutLFNW3iLIxQ43UGFOrpskvU+L vR5kCHUTv0DAqXYKSG3/mPrISkwi88MaNh662CseRUDMwBpgig/6YJLbCimVKU+y ap8B6Hx/zDJFJJ5b8TvM6pwOpcUGn/tDix3JdVUZmAIs7mAjXHoMMLAc1Akj6slM +lKB8Ar7t6aYW7vebCtp =2pCX -----END PGP SIGNATURE----- --Apple-Mail=_C5D2B010-C900-45F5-9283-826D9F1E696C-- From nobody Tue Oct 7 23:46:22 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D47F91A0034 for ; Tue, 7 Oct 2014 23:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCPCpMM3_DvO for ; Tue, 7 Oct 2014 23:46:19 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A3791A004C for ; Tue, 7 Oct 2014 23:46:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1631; q=dns/txt; s=iport; t=1412750779; x=1413960379; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=NdZpx32BMlebCOns+O9kJpu6x0wpDWWKHLXZwyMAQd4=; b=IE77XifQPFvC0PqzjbP2xDuhYm8r519nS8RphPsXggdwvrbShTAUJjnT rlHez2OgEpfdnGn47Ra9aPheDfIgfuzDm28poIDQmWwAVZOVtDb+Vsw1g g1oBfHyh+Cbn4kkfK079sXyI+w300XeSwsrtz3MJV3VTWWtLVpA3M80N1 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAITcNFStJV2a/2dsb2JhbABcA4MOU1gEyxaHUQKBBhYBe4QEAgQ6Pw4EAQgOAiYrFyUCBA4FiD7CDwEXBJAwEAcRhDoFkXeLTZYKg2NsgUiBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,675,1406592000"; d="scan'208";a="361523299" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 08 Oct 2014 06:46:18 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s986kItl004457 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Oct 2014 06:46:18 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.38]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Wed, 8 Oct 2014 01:46:18 -0500 From: "Aseem Choudhary (asechoud)" To: Juergen Schoenwaelder Thread-Topic: [netmod] Augmentation of Optional Key Thread-Index: AQHP30BKmgU9XpAl0kqr5y/ub7faYpwgsxkAgATz+4A= Date: Wed, 8 Oct 2014 06:46:17 +0000 Message-ID: In-Reply-To: <20141004200756.GA49023@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.70.64] Content-Type: text/plain; charset="us-ascii" Content-ID: <06266D3BAF6D284BA08667878B9A729D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/extJg59AuxtsDkxIt5vM8fkGxp4 Cc: "netmod@ietf.org" Subject: Re: [netmod] Augmentation of Optional Key X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Oct 2014 06:46:21 -0000 Thanks JS. I hope we find way out of backward compatibility concern. I will look forward to such discussion. -regards, Aseem On 10/4/14, 1:07 PM, "Juergen Schoenwaelder" wrote: >On Fri, Oct 03, 2014 at 07:29:04PM +0000, Aseem Choudhary (asechoud) >wrote: >> Hi all, >>=20 >> I am not sure if this has been discussed during the proposal of >>Optional key. >>=20 >> Are we planning to support optional key augmentation to a module ? If >>yes, how does it look like. If no, why not? >>=20 > >The main issue is that a key defines (as part of the contract between >client and server) what uniquely identifies a list element. It is >difficult to change this contract. During the virtual interim on >September 3rd, we discussed that adding additional optional keys to a >key is difficult since it breaks the expections of an old client when >it talks to a new server. The same argument will hold for optional key >augmentations - a client not knowing about the key augmentation will >see multiple elements in a list with the same key, which is >problematic. > >Despite this, we discussed at some length during the New York interim >that we need to extend the instance-identifier syntax to support >optional keys. I need to start a separate thread to discuss this and >in particular the implications of this for existing implementations. > >/js > >--=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 Wed Oct 8 05:26:03 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE511A0334 for ; Wed, 8 Oct 2014 05:26:01 -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 1h7KaeiryK5U for ; Wed, 8 Oct 2014 05:25:59 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D00731A0338 for ; Wed, 8 Oct 2014 05:25:58 -0700 (PDT) X-AuditID: c1b4fb30-f79736d0000053b8-0e-54352d5412fa Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id BC.D7.21432.45D25345; Wed, 8 Oct 2014 14:25:57 +0200 (CEST) Received: from [159.107.197.222] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.26) with Microsoft SMTP Server id 14.3.174.1; Wed, 8 Oct 2014 14:25:56 +0200 Message-ID: <54352D53.9040308@ericsson.com> Date: Wed, 8 Oct 2014 14:25:55 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Martin Bjorklund , "netmod@ietf.org" Content-Type: multipart/mixed; boundary="------------090706000500010801000108" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUyM+JvjW6ormmIwbMOLovu7mfsFvMvNrI6 MHksWfKTyWPjr8UsAUxRXDYpqTmZZalF+nYJXBn/Tp9hK5hpX/Hg5QbWBsbPWl2MnBwSAiYS x9Y/ZYSwxSQu3FvP1sXIxSEkcJRRYufjw6wQzhpGiakf57OBVPEKaEvcb34P1sEioCJxbPMi VhCbTcBIYmr/eRYQW1QgSuLOpX5WiHpBiZMzn4DFRQS8JDrvXwDrFRaQkfh58T3YTGaBAIm+ u9eYQGwhAQ2Jhxf+sk5g5J2FpH0WkrJZjBxAtr3Eg61lEGF5ie1v5zBD2D4S13+dZcEUt5f4 eXIS+wJG9lWMosWpxUm56UZGeqlFmcnFxfl5enmpJZsYgeF6cMtvgx2ML587HmIU4GBU4uFd MMskRIg1say4MvcQozQHi5I478Jz84KFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MMbMzdvC qXv0wszb90Qcd07V1bu0bltd3v/gDXw207/uCF9dY3Jcx/asQiVD8d7JQn1ft+VEH5QwkTSV 7dCszL35UFkrbw878wQdh4cyO35cS7XWWLO8d4m0w5YfS+66fSmVW7Dimrlp7ayLT+ud16// 4ifhHfPp+OoHfLfjq2W+y3Up7lHflavEUpyRaKjFXFScCAARf1t1OAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/z6bUQ8wN1__zbepLFpWeonze-yg Subject: [netmod] Actions in YANG 1.1 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Oct 2014 12:26:01 -0000 --------------090706000500010801000108 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Hello Martin, Here is my updated proposed text for actions. Is it good enough to insert into the draft? Any questions, modifications? If it is OK please add it to the draft. It has not really changed since the first version, as I did not get any strong comments. See the received questions at the end of the text. regards Balazs -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist ECN: 831 7320 Tel: +36-1-437-7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com --------------090706000500010801000108 Content-Type: text/plain; charset="windows-1252"; name="actionProposal2.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="actionProposal2.txt" version 1 Action Statement: !Change name of chapter 4.2.9 to: RPC and Action definitions !Add to chapter 4.2.9 YANG also allows the definition of actions: NETCONF RPCs that are connected to the data model. Some operation are naturally connected to data items e.g. a restarting an interface or flushing a dynamic forwarding table. Actions are similar to RPCs but they are modeled within a container or a list. ---note: IMHO we do not need to add examples here, it would be enough to have them in chapter 7. !Add a new chapter after the current 7.13 7.13-B. The action Statement The "action" statement is used to define a NETCONF RPC operation connected to a specific data node. It can be the substatement of container, list, grouping or augment. It takes one argument, which is an identifier, followed by a block of substatements that holds detailed action information. The argument is the name of the action. The "action" statement defines an action node in the schema tree. Under the action node, a schema node with the name "input", and a schema node with the name "output" MAY also defined. The nodes "input" and "output" are defined in the module's namespace. An action MUST NOT be defined within an rpc, another action or a notification, that is the action statement MUST NOT have an rpc, another action or a notification statement as one of its ancestors in the schema tree. The action statement MUST NOT have an rpc, another action or a notification statement as one of its ancestors even in a conceptualy flattened schema tree where all augments are inserted at their target points and all uses statements are replaced by the referenced grouping. 7.13-B.1. The action's Substatements +--------------+---------+-------------+ | substatement | section | cardinality | +--------------+---------+-------------+ | description | 7.19.3 | 0..1 | | grouping | 7.11 | 0..n | | if-feature | 7.18.2 | 0..n | | input | 7.13.2 | 0..1 | | output | 7.13.3 | 0..1 | | reference | 7.19.4 | 0..1 | | status | 7.19.2 | 0..1 | | typedef | 7.3 | 0..n | +--------------+---------+-------------+ ----note: The input and the output statements should be moved in the document structure. They should not be under action, but become a separate level 2 heading. Their text should be changed to sat rpc or action. 7.13-B.4. XML Mapping Rules For an action request, an action node (which is part of the YANG XML namespace Section 5.3.1) is encoded as a child XML element to the rpc element, and contains a single data XML element. The data element SHALL contain any and all containers and list nodes from the top level till the list/container containing the action defined in YANG. For lists all key leafs are also included. The last container/list containes an XML element that carries the name of the defined action. Within it the input parameters are encoded the same way as for YANG defined rpc operations. If the action operation invocation succeeded, and no output parameters are returned, the contains a single element defined in [RFC4741]. If output parameters are returned, a single data element is returned within the rpc-reply just as after a operation. The data element SHALL contain any and all containers and list nodes from the top level till the list/container containing the action defined in YANG. For lists all key leafs are also included. The last container/list containes an XML element that carries the name of the defined action. Within it the output parameters are encoded the same way as for YANG defined rpc operations. 7.13-B.5. Usage Example The following example defines an action to reset one server at a server farm: module server-farm { namespace "http://example.net/server-farm"; prefix "sfarm"; list server { key name; leaf name { type string; } action reset { input { leaf reset-at { type yang:date-and-time; mandatory true; } } output { leaf reset-finished-at { type string; mandatory true; } } } } } A corresponding XML instance example of the complete rpc and rpc- reply: apache-1 2014-07-29T13:42Z apache-1 2014-07-29T13:45Z ######################################################## Questions received: Q1) Andy: Why is data wrapper needed ? Answer: Not crucial, but it makes the reply more similar to an reply. Proposal: Unless someone objects leave it there. Q2) On the interim: Why do we use a nested list of XML elements for encoding instead of something like: /server["name=apache-1"] 2014-07-29T13:42Z Lada sad back in 2009 that with this encoding it would not be possible to have two actions with the same name in the same module due to problems with the DSDL mapping. This encoding would also mean that the access control has to understand the contents of the instance identifier. Is that a problem? Proposal: stick to current encoding --------------090706000500010801000108-- From nobody Wed Oct 8 08:14:43 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54A7A1A6F01 for ; Wed, 8 Oct 2014 08:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, 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 c_bAxpzgH1YI for ; Wed, 8 Oct 2014 08:14:40 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id AF8E01A1B1B for ; Wed, 8 Oct 2014 08:14:39 -0700 (PDT) Received: from [10.100.150.125] (unknown [144.49.132.3]) by lucidvision.com (Postfix) with ESMTP id BE29228B7655 for ; Wed, 8 Oct 2014 11:14:37 -0400 (EDT) From: "Thomas D. Nadeau" Content-Type: multipart/signed; boundary="Apple-Mail=_DB80F35B-EEB0-4075-B4AA-594495A1001F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: <3E03501B-CA0B-433D-A18F-F77DD223EBE7@lucidvision.com> Date: Wed, 8 Oct 2014 08:14:34 -0700 To: NETMOD Working Group Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/LAzzp3mmsbGXPRbcFUDfj1FY4U0 Subject: [netmod] Call for consensus to Accept ACL Model draft-bogdanovic-netmod-acl-model-02 as a WG draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Oct 2014 15:14:41 -0000 --Apple-Mail=_DB80F35B-EEB0-4075-B4AA-594495A1001F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The co-authors of draft-bogdanovic-netmod-acl-model-02 have = asked the NETMOD chairs to post a call to adopt the draft as a WG = document.=20 The draft can be found here: http://tools.ietf.org/html/draft-bogdanovic-netmod-acl-model-02 The model itself has been extracted and can be directly accessed = here using git: = https://github.com/YangModels/yang/blob/master/experimental/ietf/ACL-MODEL= / Please comment by the close of business on Monday, October 13, = 2014. --Tom (As NETMOD co-chair) --Apple-Mail=_DB80F35B-EEB0-4075-B4AA-594495A1001F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUNVTbAAoJEPcO+I7eiUJZlY8QAIjDenoViFvEHWuDcgDOuqlP qFlcD9lIb3qV/q5ywuldluCbBEuR1TzZv/qfCjGGXDi69MiyHuOiy2NM7zVBGiSl 5qDlz48yDsDAzgP+O/WAcULzRvASgY4QIazAqXUZ6vDTiVWkrupIyn6Oi3EwZKSa 3zKGBnax2droaDTqSzsjOR9I6TsENOjSWrOc4jFLqQV48/MToRVpBWaOJked6MLE rZW5fUFqnrqhE7wvQ0wedfWRhna4nnNCJjFECJqJeMDJf7tHLb9/nHDzHhYj+dbK WRLf9n9qMVGPd+Kj1DqwRUJWc3WzneHcIYX3h2cocvpj1HEl5v4IEG+j1q1jp8Qr zePToQniicwPA3d/PE4f4kU29PwcId/PD/6mlWuh4nTRHMFpjvpX45SCKgXeDe0B VDbrBLbbGivIuc93+1qx8KJL/I8jn+lnnykFUOaRYOHYAoaRqN2KPLrEag/3novK bPCLYeIckCatMvv+fCZRVlph3gUpe3uRmpusN0CxB0Ough31vbWsKEJMO9gmsuJS 4QzbUEB8oI1wPr+hsrzNrenhJ7p4fFr9tt81okUPjv7ee1/I/k7Lo+zrAkaUxlNF QNdopbTvYeiw6VBluJz2pVXSeTYsxKY2znOxn8menxdq1/t/plrX7wd2Qqh8vmnh l3aHnASkFLKnfpGQTtLF =imCa -----END PGP SIGNATURE----- --Apple-Mail=_DB80F35B-EEB0-4075-B4AA-594495A1001F-- From nobody Wed Oct 8 08:14:55 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE7641A6F05 for ; Wed, 8 Oct 2014 08:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, 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 R13Kr4EGxCtS for ; Wed, 8 Oct 2014 08:14:47 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA261A6F07 for ; Wed, 8 Oct 2014 08:14:47 -0700 (PDT) Received: from [10.100.150.125] (unknown [144.49.132.3]) by lucidvision.com (Postfix) with ESMTP id 5E63028B765E for ; Wed, 8 Oct 2014 11:14:46 -0400 (EDT) From: "Thomas D. Nadeau" Content-Type: multipart/signed; boundary="Apple-Mail=_9C27F32D-C678-4AD3-A940-A31C7293DB2C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: <589EC930-B7D9-4F30-B550-7297F43E0C0D@lucidvision.com> Date: Wed, 8 Oct 2014 08:14:45 -0700 To: NETMOD Working Group Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/F4x3G5VK-ZjLbu07j8deVFgRurI Subject: [netmod] NETMOD WG Poll to Adopt ACL Yang Model draft-wildes-netmod-syslog-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: Wed, 08 Oct 2014 15:14:49 -0000 --Apple-Mail=_9C27F32D-C678-4AD3-A940-A31C7293DB2C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The co-authors of draft-wildes-netmod-syslog-model-03.txt have = asked the NETMOD chairs to post a call to adopt the draft as a WG = document.=20 The draft can be found here: http://tools.ietf.org/html/draft-wildes-netmod-syslog-model-03 The model itself has been extracted and can be directly accessed = here using git: = https://github.com/YangModels/yang/tree/master/experimental/ietf/SYSLOG-MO= DEL Please comment by the close of business on Monday, October 13, = 2014. --Tom (As NETMOD co-chair) --Apple-Mail=_9C27F32D-C678-4AD3-A940-A31C7293DB2C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUNVTlAAoJEPcO+I7eiUJZ7B4P/1LyZhRyajwEGRF+CGrjnPj0 rpwtCuUnr4A334+ubEh1zv6g8UQffivt+TDML8QBDRWFCY/jLb9FtU/JgkiS00kp VsQY5Jjuah10ePsYsYFW5+LWa7XLvXXxYMf6zZlrTKU+nbs8RU77XDOdHI7U5SaP s3+TJB5839QqJl3D53f8E/MX0/x/5DcMO+d0gyQuZVuojH70ra4qH2MxPHEoMjB/ xRhuKlPip9G45ZCjPUJF6ee/a5ldGaxtoazNekUhjr+kAArkdGBT9LyJTdayjdOa qQSTF8AigHm1moj56/cGpPlfHi+Rc798pNHTUDz5defS4x8AowkTbpXBaLL1ZPtr IEno18QbXzppN3XCfDm7qKb+egLBXuFBEfFgxHc+3GY5ANtB6uUX9WC9o8qoXdW8 09Q+hyMEQ6xtoDWiBC6K34QGFQFxl54Ot02W8HFBdH5PKryB3izndWaVXriijgFf Q04t3r1VjW0Nk1vdFFIGkI/U7PnqYaCTZrvpaaGHzEuYXg5faC7xNaMP6u2LG1p6 PR4rDdQuf2slePsRO/f7WfMtuhW/TaB0hZOzxGpjN+GiWKqOccqFZDZjBpjWaOt5 JKTBOsp/5J4NZtzQU7sHfmh+xrZHuV54+d6WGkw4/jPcWccaCNwqE5ld28XfgGuT qk3Uro8Q7pRMNcYNmxPI =J7an -----END PGP SIGNATURE----- --Apple-Mail=_9C27F32D-C678-4AD3-A940-A31C7293DB2C-- From nobody Wed Oct 8 08:46:41 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 462D51A6F8C for ; Wed, 8 Oct 2014 08:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.477 X-Spam-Level: X-Spam-Status: No, score=-3.477 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1YiZEUGGrnG for ; Wed, 8 Oct 2014 08:46:37 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1946E1A6F82 for ; Wed, 8 Oct 2014 08:46:36 -0700 (PDT) X-AuditID: c1b4fb30-f79736d0000053b8-1e-54355c5b5ed0 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 65.E2.21432.B5C55345; Wed, 8 Oct 2014 17:46:35 +0200 (CEST) Received: from [159.107.197.222] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.68) with Microsoft SMTP Server id 14.3.174.1; Wed, 8 Oct 2014 17:46:34 +0200 Message-ID: <54355C5A.4030304@ericsson.com> Date: Wed, 8 Oct 2014 17:46:34 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Andy Bierman References: <54327ACA.3090606@ericsson.com> In-Reply-To: Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUyM+JvjW50jGmIQetnCYsHR2axW8y/2Mjq wOSxZMlPJo+W/ossAUxRXDYpqTmZZalF+nYJXBnrpyxgLriuU/F/4TPmBsYeuS5GTg4JAROJ 2X8+sEHYYhIX7q0Hsrk4hASOMko0PL7PCOGsYZT4sng9K0gVr4C2xPLXc8A6WARUJA6+vM4M YrMJGElM7T/PAmKLCkRJ3LnUD1UvKHFy5hOwuIiAqsSFuRPB6pkF/CR+Tm4AiwsDzbz16QtY XEigQGJW5zkmEJtTIFDiwPQZTBD1uhIX/k9hgbDlJba/nQNVryHx8MJf1gmMgrOQrJuFpGUW kpYFjMyrGEWLU4uTctONjPRSizKTi4vz8/TyUks2MQID9uCW3wY7GF8+dzzEKMDBqMTDu2CW SYgQa2JZcWXuIUZpDhYlcd6F5+YFCwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamAUqxHh7Tvd 3MeoKOXuyXF3Z/3/XSu7laO2nGfeJ/w4wkrNOltFRfrOnLcLWrc9nHUoZ17oyYnGoe78Ba/O +JbNvTZ90UfudpNrK8Ucrbhlm5RjU7o/hllJfrTZ/ylq1STxtJw696aPk+IdgpOXZuu3xrdF mi76wvQnKXdOq7L6BeuapvZoKSWW4oxEQy3mouJEAJCRd1w5AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/YFyOPjE_hq5SXsKkWDm_IPdesjo Cc: "netmod@ietf.org" , EGBOSCH Subject: Re: [netmod] non-unique leaf-lists X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Oct 2014 15:46:39 -0000 Hello Andy,
See below.
Balazs

On 2014-10-06 22:01, Andy Bierman wrote:
Hi,

On Mon, Oct 6, 2014 at 4:19 AM, Balazs Lengyel <balazs.lengyel@ericsson.com> wrote:
Hello,
After the New York interim I volunteered to write a proposal about how to implement leaf-lists that might have non-unique (repeated) values. I attached my proposal for it. Please comment!
regards Balazs


There are two interesting data modeling issues raised in your proposal.
I think we should identify and agree on the problems first, and then pick apart the
solution details after that.

I-1) Do all leaf-lists need to be edited as individual components? [current: yes, propose: no]
[BALAZS] : While I proposed yes, I could live with a No. Stating that nonUnique leaf-lists can only be handled as a unit would make things _much_ easier. Its gained functionality versus complexity. Any opinions?
Can the data model specify that all leaf-list values are provided/replaced at once?
Or is this also a protocol issue?
Note that current "replace" operation for leaf-list is a no-op because
it replaces the individual value with the same value.
[BALAZS]: Not really, as written in 7.7.7 rfc6020, the value can be moved in the list. So the value stays, but its position in the list changes.

I-2) Do all leaf-lists need to contain unique values? [current: yes, propose: no]
[BALAZS]: Definitely NO That's my proposal.
Depending on I-1, position-based editing may not be needed.
One work-around is to always put this sort of leaf-list in its own container
so the "replace" operation on the container can be used.
[BALAZS]: The work-around is feasible, we actually use something like that in Ericsson.

IMO both issues should be addressed in YANG 1.1 (and in NETCONF if needed).
The solution for position-based editing looks OK to me.


Andy



-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320                        Tel: +36-1-437-7320
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
From nobody Wed Oct 8 09:03:05 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D868B1A8893 for ; Wed, 8 Oct 2014 09:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, 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 ZrSi0q-TcRtq for ; Wed, 8 Oct 2014 09:02:56 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 705311A6F85 for ; Wed, 8 Oct 2014 09:02:54 -0700 (PDT) Received: from [10.100.150.125] (unknown [144.49.132.3]) by lucidvision.com (Postfix) with ESMTP id 8013628B77FF for ; Wed, 8 Oct 2014 12:02:53 -0400 (EDT) From: "Thomas D. Nadeau" Content-Type: multipart/signed; boundary="Apple-Mail=_4C48651B-774B-4CB4-AB5C-5FAD6CD1F8AA"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: <4B2C5E57-5DD9-4571-A994-4554B2D699EB@lucidvision.com> Date: Wed, 8 Oct 2014 09:02:52 -0700 To: NETMOD Working Group Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/buz-dEvy0tDiJZnSmfJ_OYj7s7U Subject: [netmod] interim net mod WG meeting minutes X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Oct 2014 16:03:04 -0000 --Apple-Mail=_4C48651B-774B-4CB4-AB5C-5FAD6CD1F8AA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 [07:00] =3D=3D Thomas__ [90318403@gateway/web/freenode/ip.144.49.132.3] = has joined #netmod-wg [07:00] -ChanServ- [#IETF] Welcome to the Internet Engineering Task = Force channel on FreeNode IRC Network - the largest open international = community of network designers, operators, vendors, and researchers = concerned with the evolution of the Internet architecture and the smooth = operation of the Internet. [07:01] #chair Thomas__ schoenw [07:01] Current chairs: Thomas__ kwatsen schoenw [07:01] =3D=3D Benoit__ [ad26d10a@gateway/web/freenode/ip.173.38.209.10] = has joined #netmod-wg [07:07] #info Tom goes over agenda [07:08] =3D=3D Clyde [ad24f0a7@gateway/web/freenode/ip.173.36.240.167] = has joined #netmod-wg [07:08] =3D=3D Dana_ [4086de3d@gateway/web/freenode/ip.64.134.222.61] = has joined #netmod-wg [07:08] ##topic ACL Model (presented by Dean B.) [07:08] #undo [07:08] Removing item from minutes: [07:08] #topic ACL Model (presented by Dean B.) [07:08] =3D=3D meetbot changed the topic of #netmod-wg to: ACL Model = (presented by Dean B.) [07:08] passing the ball to Dean B [07:09] =3D=3D jft [adb11655@gateway/web/freenode/ip.173.177.22.85] has = joined #netmod-wg [07:12] = https://tools.ietf.org/html/draft-bogdanovic-netmod-acl-model-02 [07:13] = http://tools.ietf.org/html/draft-bogdanovic-netmod-acl-model-02 [07:13] draft is updated at that URL [07:16] #link = https://tools.ietf.org/html/draft-bogdanovic-netmod-acl-model-02 [07:17] note: only msgs preceded by a '#' are capture by = meetbot [07:17] if you order by number, how do you insert - does this = cause renumbering? [07:18] #info Blair asks if there is a pattern to follow [07:18] #undo [07:18] Removing item from minutes: [07:18] #info Blair asks if there is a pattern to follow for = key/value mapping (hashmap) [07:19] this was discussed during last week's Yangathon @ ODL = Dev Summit. Others are encountering this issue [07:20] Are we discussing ACL or hashmaps? [07:21] please post this issue to the list to record the need = to add this when we hack Yang 2.0 [07:21] ACL but the issue pertains to modeling hash maps [07:21] (similar to what was discussed on the list last week) [07:22] I do not see the relationship to hash maps. ACLs are = an ordered list. [07:23] is was also wondering about that [07:23] lada asks you have configuration and running state in = the same tree. isn't there a protocol that allows for configuration = outside of netconf. how do you plan to deal with the case where there = are two writers? [07:23] #info lada asks you have configuration and running = state in the same tree. isn't there a protocol that allows for = configuration outside of netconf. how do you plan to deal with the case = where there are two writers? [07:23] the issue is around the internal mapping of the = ordered list -> hash map internally. [07:25] benoit asks: where/how are these extra extensions to = be developed? [07:26] #info benoit asks: where/how are these extra = extensions to be developed? [07:26] remember to use #info for meetbot [07:26] yes sorry! *) [07:26] #info Tom learns how to use IRC again. *) [07:27] =3D=3D Dean__ [4281f10d@gateway/web/freenode/ip.66.129.241.13] = has joined #netmod-wg [07:28] #info Dana says that L2 is an based model, but mpls = might be good for an example [07:28] #info Dean stresses that this is an early example of = how to extend things in standard ways [07:28] #info to show how is can be extended nicely in the = future [07:29] #info [two comments up] s/an based model/in base = model/ [07:32] #info Kiran asks when this can move forward to a WG = chartered item [07:32] #info all authors agreed that they felt it was ready [07:32] #info Tom says he'll take it to the list [07:33] #undo [07:33] Removing item from minutes: [07:33] #info discussion about if its ready now [07:33] #info no objections raised [07:33] #link = http://tools.ietf.org/html/draft-wildes-netmod-syslog-model-03 [07:33] #info Tom says he'll take it to the list [07:34] #undo [07:34] Removing item from minutes: [07:34] #topic syslog [07:34] =3D=3D meetbot changed the topic of #netmod-wg to: syslog [07:34] #link = http://tools.ietf.org/html/draft-wildes-netmod-syslog-model-03 [07:44] #info ill issue a call for adoption of the syslog = model shortly [07:44] who asked the question? [07:44] I think Alex Clemm [07:44] yes Alex [07:44] Call-in User_7 [07:45] yes that is Alex talking now=20 [07:45] #info Call-in User_7 (Alex Clemm?) asks about support = for structured data [07:50] #info kwatsen asks and is assured that other encodings = beyond structured-data can be added in the future [07:50] #info github link for ACL model discussed earlier: = https://github.com/YangModels/yang/blob/master/experimental/ietf/ACL-MODEL= /draft-bogdanovic-netmod-acl-model-02.txt [07:50] this is just the model - not in draft format. [07:53] #info calls for adoption of the draft as a NETMOD WG = draft [07:53] =46rom = http://trac.tools.ietf.org/area/ops/trac/wiki/yang-doctors-review-history,= J=FCrgen is the YANG doctor for syslog. J=FCrgen, have you had the = chance to review this document? What do you think? [07:54] #info Latest SYSLOG model posted too: = https://github.com/YangModels/yang/blob/master/experimental/ietf/SYSLOG-MO= DEL/draft-wildes-netmod-syslog-model-03.txt [07:55] I have not read the latest version but I appreciate = the work that apparently has already gone into this new revision. If = there is a call for adoption, I will likly push this up on my priority = list. [07:55] #info confirmed Call-in User_7 is Alex [07:56] #info - lads asks if this should be in net mod if = syslog is closed [07:56] #info Lada questions if another WG should do this = work. Benoit otes that syslog WG is concluded. [07:57] #undo [07:57] Removing item from minutes: [07:57] #info Lada questions if another WG should do this = work. Benoit notes that syslog WG is concluded. [07:57] #info - benoit is ok to do these in net mod if there = are no other homes for this [08:00] #info Benoit points out that there are requests for = many models for which there are no homes for, and creation of a WG per = model wouldn't scale [08:00] #undo [08:00] Removing item from minutes: [08:00] #info Benoit points out that there are requests for = many models for which there are no homes, and creation of a WG per model = wouldn't scale [08:01] #info one suggestion is to have one WG focused on = models and another on the language [08:03] We had this discussion N times before, I suggest we = try to get data models done and deal with scalability issues once we = reach the boundaries [08:03] i agree - we've gone a bit sideways here... [08:04] #info schoenw recommends that we get data models done = and deal with scalability issues once we reach the boundaries [08:04] #info Thomas__ agrees [08:06] #info Thomas__ recommends we incubate more Yang = Doctors as a means to scale modeling work [08:06] #info: Kent, I have increase the number of YANG = doctors recently. [08:06] = https://www.ietf.org/iesg/directorate/yang-doctors.html [08:07] #info I asked for comments to accept or not this = draft as a WG draft [08:07] kent commented that he is ok to accept this but that = Jeff Haas needs to review.=20 [08:07] clyde - Ron Bonica did review but didn't suggest any = changes. [08:08] #action Thomas__ to send mail to list asking to move = to a chartered item status [08:08] #topic Mount Points [08:08] =3D=3D meetbot changed the topic of #netmod-wg to: Mount Points [08:09] #info ref for draft under discussion = http://datatracker.ietf.org/doc/draft-clemm-netmod-mount/ [08:09] I will stop listening now since I need to draw = attention to the other meeting I am in [08:09] #into @EricVoit notes that this work originates from = OpenDaylight Project [08:10] #info earlier draft posted a year ago, since then it = has been implemented and an updated draft posted [08:11] @schoenw, thanks for the heads-up [08:13] #info @EricVoit notes that this work originates from = OpenDaylight Project [08:13] i had a typo before s/into/info [08:13] #undo [08:13] Removing item from minutes: [08:14] #info @EricVoit, and running code in ODL=20 [08:28] #info question regarding impact on device - does if = have to implement pub/sub and async notification? [08:29] #info Alex explains that there are two roles: mount = client and mount server [08:29] #info the mount server may support the ability for = async notifications [08:30] #info Benoit asks if there is an advantage to this = approach over existing protocols (VRRP) [08:34] =3D=3D Dana_ [4086de3d@gateway/web/freenode/ip.64.134.222.61] = has quit [Ping timeout: 246 seconds] [08:35] #this is a YANG-specific solution, unknown if other = protocols would benefit from being model-aware [08:44] this is a yang language thing, not a specific = protocol thing (netconf/restconf) [08:45] its a usage extension really. sort of a behavioral = change. [08:47] #info Benoit__ asks if this is really an extension of = YANG (no, it can be implemented with existing Yang 1.0) [08:48] #info Balazs questions if the protocol extensions = should be brought to the NETCONF WG [08:49] #info Alex explains that this can be implemented on = top of existing NETCONF. Extensions (pub/sub) would be in a different = draft [08:49] #undo [08:49] Removing item from minutes: [08:49] #info Alex explains that this can be implemented on = top of existing NETCONF. NETCONF extensions (pub/sub) would be in a = different draft [08:53] #info Eric notes that NETCONF is not required. Other = protocols (HTTP) were tried as well [08:54] interesting, for HTTP is a data-model (Yang) used for = what to HTTP resource(s) mounted? - yes, if RESTCONF... [08:55] typo s/for HTTP is a/for HTTP, if a/ [08:57] #info - time check. we need to wrap in 3 min... [08:59] #info the importance of the problem [08:59] #info this seems very app-specific [09:00] #info what ODL is doing seems just one way this could = be done [09:01] #action kwatsen to take this to the list [09:02] thanks again Kent for taking notes! [09:02] =3D=3D Clyde [ad24f0a7@gateway/web/freenode/ip.173.36.240.167] = has quit [Quit: Page closed] --Apple-Mail=_4C48651B-774B-4CB4-AB5C-5FAD6CD1F8AA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUNWAsAAoJEPcO+I7eiUJZ9o4P/RiXEluvi63RKD6svf7cf4D3 W7IC9Cr9C/I9kOTYGQF6l6YeCxqCnBxDL9j2GPBLwMqLjbaJW2OOB4hhOlnsgxWg Q72H/0QQeUSjHGZU5psPYflM7zDZpXDBfJWphuxcoaxMwElVAO8N4WMJpyOwTaoK hkljANT3VjGHvBLW1qCx3JIhBZM0rmQRFB1MDqbbecR+7xCRCmCUo3byBwrFgDqM rBd66FHF8F6ROVnk+JtgFqvM5ITfsclu9cE6c6Tpvk6kHKJsRMwRocUzn6i+VHjy pGPco11H+a/TP3lzsIjH1VDDgctu1m3L6aO5SXD3W65SqrK08/u2b4D/6lulPKQD nNPsFxWmNLvuulHwA05b7DTqUM7ZKDuY3F70GD13dpz70yOB2CJuEUm6rV3MgW/b IbTrvk5/oKfSITV+2hgz9qiDpW7ZoXY5BeZhakhIKK/gfWqz8QhS2ewfKxBLMXb6 OLBzb0pgGAVCRTDeuZ1zVxNV2iBcCYoivlUnXA1Cvj3c12kJWHThJn2B6uIl/TKn MXpPsrdcjW0LR2T+CYM2iIf9i6/I4vJwzNY8i50wY0IjrMVh0/IUyVsU8DJuga5x f9gAdPxB0tPTwuLOOfTWEMkZXBwhPZ7KA6qzwNT6Chub/PTRv9TU4acZjatgO1al glFhPqUWw5gloFluKNbO =jQY5 -----END PGP SIGNATURE----- --Apple-Mail=_4C48651B-774B-4CB4-AB5C-5FAD6CD1F8AA-- From nobody Wed Oct 8 09:38:37 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 628DF1A8F36 for ; Wed, 8 Oct 2014 09:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, 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 2OeAFmHzV6Vf for ; Wed, 8 Oct 2014 09:38:32 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id D69511A911B for ; Wed, 8 Oct 2014 09:38:31 -0700 (PDT) Received: from [10.100.151.192] (unknown [144.49.132.3]) by lucidvision.com (Postfix) with ESMTP id ED5A628B7939 for ; Wed, 8 Oct 2014 12:38:30 -0400 (EDT) Content-Type: multipart/mixed; boundary=Apple-Mail-07AD0197-0F86-490E-AF40-89102BBC3216 Content-Transfer-Encoding: 7bit From: Thomas Nadeau Mime-Version: 1.0 (1.0) Date: Wed, 8 Oct 2014 09:38:28 -0700 Message-Id: <766247DF-0BFB-4AAA-9D37-95B6819A4978@lucidvision.com> To: NETMOD Working Group X-Mailer: iPhone Mail (12A405) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/FPW5qcHTwZDl6UtLavBXPuxWo5E Subject: [netmod] netmod wg interim meeting minutes .2014-10-08-14.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: Wed, 08 Oct 2014 16:38:34 -0000 --Apple-Mail-07AD0197-0F86-490E-AF40-89102BBC3216 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --Apple-Mail-07AD0197-0F86-490E-AF40-89102BBC3216 Content-Type: text/plain; name=netmod-wg.2014-10-08-14.00.txt; x-apple-part-url=63EB67BA-E8AD-45F4-BE0F-DFC285574497 Content-Disposition: attachment; filename=netmod-wg.2014-10-08-14.00.txt Content-Transfer-Encoding: quoted-printable =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D #netmod-wg Meeting =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Meeting started by kwatsen at 14:00:07 UTC. The full logs are available at netmod-wg/2014/netmod-wg.2014-10-08-14.00.log.html . Meeting summary --------------- * Agenda Bashing (kwatsen, 14:00:18) * ACL Model (presented by Dean B.) (kwatsen, 14:08:37) * LINK: https://tools.ietf.org/html/draft-bogdanovic-netmod-acl-model-02 (schoenw, 14:12:55) * LINK: http://tools.ietf.org/html/draft-bogdanovic-netmod-acl-model-02 (Thomas__, 14:13:49) * LINK: https://tools.ietf.org/html/draft-bogdanovic-netmod-acl-model-02 (kwatsen, 14:16:13) * Blair asks if there is a pattern to follow for key/value mapping (hashmap) (kwatsen, 14:18:57) * lada asks you have configuration and running state in the same tree. isn't there a protocol that allows for configuration outside of netconf. how do you plan to deal with the case where there are two writers? (kwatsen, 14:23:31) * benoit asks: where/how are these extra extensions to be developed? (kwatsen, 14:26:03) * Tom learns how to use IRC again. *) (Thomas__, 14:26:39) * Dana says that L2 is an based model, but mpls might be good for an example (kwatsen, 14:28:20) * Dean stresses that this is an early example of how to extend things in standard ways (Thomas__, 14:28:26) * to show how is can be extended nicely in the future (kwatsen, 14:28:39) * [two comments up] s/an based model/in base model/ (kwatsen, 14:29:38) * Kiran asks when this can move forward to a WG chartered item (kwatsen, 14:32:30) * all authors agreed that they felt it was ready (kwatsen, 14:32:43) * discussion about if its ready now (kwatsen, 14:33:28) * no objections raised (kwatsen, 14:33:51) * LINK: http://tools.ietf.org/html/draft-wildes-netmod-syslog-model-03 (Clyde, 14:33:53) * syslog (kwatsen, 14:34:06) * LINK: http://tools.ietf.org/html/draft-wildes-netmod-syslog-model-03 (Clyde, 14:34:25) * ill issue a call for adoption of the syslog model shortly (Thomas__, 14:44:09) * Call-in User_7 (Alex Clemm?) asks about support for structured data (kwatsen, 14:45:38) * kwatsen asks and is assured that other encodings beyond structured-data can be added in the future (kwatsen, 14:50:24) * github link for ACL model discussed earlier: https://github.com/YangModels/yang/blob/master/experimental/ietf/ACL-MOD= EL/draft-bogdanovic-netmod-acl-model-02.txt (Thomas__, 14:50:45) * calls for adoption of the draft as a NETMOD WG draft (Thomas__, 14:53:06) * Latest SYSLOG model posted too: https://github.com/YangModels/yang/blob/master/experimental/ietf/SYSLOG-= MODEL/draft-wildes-netmod-syslog-model-03.txt (Thomas__, 14:54:43) * confirmed Call-in User_7 is Alex (kwatsen, 14:55:15) * - lads asks if this should be in net mod if syslog is closed (Thomas__, 14:56:56) * Lada questions if another WG should do this work. Benoit notes that syslog WG is concluded. (kwatsen, 14:57:11) * - benoit is ok to do these in net mod if there are no other homes for this (Thomas__, 14:57:25) * Benoit points out that there are requests for many models for which there are no homes, and creation of a WG per model wouldn't scale (kwatsen, 15:00:42) * one suggestion is to have one WG focused on models and another on the language (kwatsen, 15:01:26) * schoenw recommends that we get data models done and deal with scalability issues once we reach the boundaries (kwatsen, 15:04:12) * Thomas__ agrees (kwatsen, 15:04:31) * Thomas__ recommends we incubate more Yang Doctors as a means to scale modeling work (kwatsen, 15:06:08) * : Kent, I have increase the number of YANG doctors recently. (Benoit__, 15:06:32) * LINK: https://www.ietf.org/iesg/directorate/yang-doctors.html (Benoit__, 15:06:53) * I asked for comments to accept or not this draft as a WG draft (Thomas__, 15:07:05) * ACTION: Thomas__ to send mail to list asking to move to a chartered item status (kwatsen, 15:08:31) * Mount Points (kwatsen, 15:08:41) * ref for draft under discussion http://datatracker.ietf.org/doc/draft-clemm-netmod-mount/ (Thomas__, 15:09:07) * earlier draft posted a year ago, since then it has been implemented and an updated draft posted (kwatsen, 15:10:50) * @EricVoit, and running code in ODL (Benoit__, 15:14:06) * question regarding impact on device - does if have to implement pub/sub and async notification? (kwatsen, 15:28:32) * Alex explains that there are two roles: mount client and mount server (kwatsen, 15:29:04) * the mount server may support the ability for async notifications (kwatsen, 15:29:40) * Benoit asks if there is an advantage to this approach over existing protocols (VRRP) (kwatsen, 15:30:48) * Benoit__ asks if this is really an extension of YANG (no, it can be implemented with existing Yang 1.0) (kwatsen, 15:47:35) * Balazs questions if the protocol extensions should be brought to the NETCONF WG (kwatsen, 15:48:43) * Alex explains that this can be implemented on top of existing NETCONF. NETCONF extensions (pub/sub) would be in a different draft (kwatsen, 15:49:37) * Eric notes that NETCONF is not required. Other protocols (HTTP) were tried as well (kwatsen, 15:53:19) * - time check. we need to wrap in 3 min... (Thomas__, 15:57:32) * the importance of the problem (kwatsen, 15:59:42) * this seems very app-specific (kwatsen, 15:59:59) * what ODL is doing seems just one way this could be done (kwatsen, 16:00:21) * ACTION: kwatsen to take this to the list (kwatsen, 16:01:01) Meeting ended at 16:02:34 UTC. Action items, by person ----------------------- * kwatsen * kwatsen to take this to the list * Thomas__ * Thomas__ to send mail to list asking to move to a chartered item status People present (lines said) --------------------------- * kwatsen (69) * Thomas__ (30) * meetbot (11) * schoenw (7) * Benoit__ (6) * Clyde (2) Generated by `MeetBot`_ 0.1.4= --Apple-Mail-07AD0197-0F86-490E-AF40-89102BBC3216 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --Apple-Mail-07AD0197-0F86-490E-AF40-89102BBC3216-- From nobody Wed Oct 8 10:03:23 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 896801A9177 for ; Wed, 8 Oct 2014 10:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rpy4pCE-lkW4 for ; Wed, 8 Oct 2014 10:03: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 A97A21A6FF8 for ; Wed, 8 Oct 2014 10:03: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 31353F5A; Wed, 8 Oct 2014 19:03:18 +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 drT2TWwB9b-C; Wed, 8 Oct 2014 19:03: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; Wed, 8 Oct 2014 19:03:17 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id A3AFD20036; Wed, 8 Oct 2014 19:03:17 +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 Cj0PKWX6WeiJ; Wed, 8 Oct 2014 19:03: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 F081E20035; Wed, 8 Oct 2014 19:03:16 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1344A2EE831B; Wed, 8 Oct 2014 19:03:15 +0200 (CEST) Date: Wed, 8 Oct 2014 19:03:14 +0200 From: Juergen Schoenwaelder To: Thomas Nadeau Message-ID: <20141008170313.GB73652@elstar.local> Mail-Followup-To: Thomas Nadeau , NETMOD Working Group References: <766247DF-0BFB-4AAA-9D37-95B6819A4978@lucidvision.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <766247DF-0BFB-4AAA-9D37-95B6819A4978@lucidvision.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/yV_k-sy29ZlkfjA2WPKLqZ-VB24 Cc: NETMOD Working Group Subject: Re: [netmod] netmod wg interim meeting minutes .2014-10-08-14.00 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, 08 Oct 2014 17:03:21 -0000 On Wed, Oct 08, 2014 at 09:38:28AM -0700, Thomas Nadeau wrote: > > People present (lines said) > --------------------------- > > * kwatsen (69) > * Thomas__ (30) > * meetbot (11) > * schoenw (7) > * Benoit__ (6) > * Clyde (2) > I think there were more people in the call. I heard Lada speaking up for instance. /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 Oct 8 10:18:57 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3831ACC82 for ; Wed, 8 Oct 2014 10:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, 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 eSYvgDh3p9O2 for ; Wed, 8 Oct 2014 10:18:53 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 81E1C1ACD08 for ; Wed, 8 Oct 2014 10:18:52 -0700 (PDT) Received: from [10.100.151.192] (unknown [144.49.132.3]) by lucidvision.com (Postfix) with ESMTP id B2E7028B7A59; Wed, 8 Oct 2014 13:18:51 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Thomas Nadeau X-Mailer: iPhone Mail (12A405) In-Reply-To: <20141008170313.GB73652@elstar.local> Date: Wed, 8 Oct 2014 10:18:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <766247DF-0BFB-4AAA-9D37-95B6819A4978@lucidvision.com> <20141008170313.GB73652@elstar.local> To: Juergen Schoenwaelder Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/qVnx6RxX-ihYvOLF8HiY9DDr1Mc Cc: NETMOD Working Group Subject: Re: [netmod] netmod wg interim meeting minutes .2014-10-08-14.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: Wed, 08 Oct 2014 17:18:55 -0000 Yes there were. These we just those that joined irc which is how we recorded= meeting minutes (thanks again Kent!). I asked everyone at the start to join= and provided easy instructions for how to join. This is how we will continu= e to record meeting minutes and attendees going forward as it automates and s= treamlines things. Tom=20 > On Oct 8, 2014, at 10:03 AM, Juergen Schoenwaelder wrote: >=20 >> On Wed, Oct 08, 2014 at 09:38:28AM -0700, Thomas Nadeau wrote: >>=20 >> People present (lines said) >> --------------------------- >>=20 >> * kwatsen (69) >> * Thomas__ (30) >> * meetbot (11) >> * schoenw (7) >> * Benoit__ (6) >> * Clyde (2) >=20 > I think there were more people in the call. I heard Lada speaking up > for instance. >=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 From nobody Wed Oct 8 10:34:09 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 322FE1ACD38 for ; Wed, 8 Oct 2014 10:34:05 -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 e6eI_E2wppku for ; Wed, 8 Oct 2014 10:34:03 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0142.outbound.protection.outlook.com [65.55.169.142]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D9221ACD3D for ; Wed, 8 Oct 2014 10:34:03 -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.0.1044.10; Wed, 8 Oct 2014 17:34:00 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.196]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.72]) with mapi id 15.00.1044.008; Wed, 8 Oct 2014 17:34:00 +0000 From: Kent Watsen To: Juergen Schoenwaelder Thread-Topic: [netmod] netmod wg interim meeting minutes .2014-10-08-14.00 Thread-Index: AQHP4xZSkau5eoqegESZar+i8D/BkZwmbVEAgAAImW4= Date: Wed, 8 Oct 2014 17:34:00 +0000 Message-ID: <94F3CA5D-636D-44A8-BEEF-7A17085C7294@juniper.net> References: <766247DF-0BFB-4AAA-9D37-95B6819A4978@lucidvision.com>, <20141008170313.GB73652@elstar.local> In-Reply-To: <20141008170313.GB73652@elstar.local> 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: [166.137.93.24] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458; x-forefront-prvs: 0358535363 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(5423002)(199003)(51704005)(377454003)(189002)(24454002)(21056001)(19580405001)(19580395003)(64706001)(76482002)(77096002)(85852003)(66066001)(86362001)(92566001)(20776003)(105586002)(230783001)(40100002)(31966008)(101416001)(36756003)(87936001)(15202345003)(99286002)(85306004)(46102003)(33656002)(110136001)(80022003)(2656002)(15975445006)(106116001)(107046002)(92726001)(54356999)(95666004)(106356001)(76176999)(50986999)(4396001)(120916001)(97736003)(99396003)(122556002)(104396001)(142923001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/f041lKqvxmXr-BU1S5w8tefEv_k Cc: NETMOD Working Group Subject: Re: [netmod] netmod wg interim meeting minutes .2014-10-08-14.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: Wed, 08 Oct 2014 17:34:05 -0000 Current best practice (until meetbot grows a new keyword) is for everyone t= o #info when the join with their real name, that way: 1) they are counted i= n the summary as having said at least one line and 2) there is a mapping fr= om their nickname to real name. =20 Some meetings even make a point to ask everyone to this during agenda bashi= ng. =20 Kent > On Oct 8, 2014, at 1:03 PM, "Juergen Schoenwaelder" wrote: >=20 >> On Wed, Oct 08, 2014 at 09:38:28AM -0700, Thomas Nadeau wrote: >>=20 >> People present (lines said) >> --------------------------- >>=20 >> * kwatsen (69) >> * Thomas__ (30) >> * meetbot (11) >> * schoenw (7) >> * Benoit__ (6) >> * Clyde (2) >=20 > I think there were more people in the call. I heard Lada speaking up > for instance. >=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 Wed Oct 8 10:47:14 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C55C41ACD62 for ; Wed, 8 Oct 2014 10:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, 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 9jhkY3kqXvze for ; Wed, 8 Oct 2014 10:47:12 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 83A0C1ACD59 for ; Wed, 8 Oct 2014 10:47:12 -0700 (PDT) Received: from [10.102.170.228] (mobile-166-171-250-029.mycingular.net [166.171.250.29]) by lucidvision.com (Postfix) with ESMTP id 7CAE228B7B48; Wed, 8 Oct 2014 13:47:11 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Thomas Nadeau X-Mailer: iPhone Mail (12A405) In-Reply-To: <94F3CA5D-636D-44A8-BEEF-7A17085C7294@juniper.net> Date: Wed, 8 Oct 2014 10:47:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7CF9051D-DE1C-46CA-88E0-39BE759B777A@lucidvision.com> References: <766247DF-0BFB-4AAA-9D37-95B6819A4978@lucidvision.com> <20141008170313.GB73652@elstar.local> <94F3CA5D-636D-44A8-BEEF-7A17085C7294@juniper.net> To: Kent Watsen Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/gMlnThcguwtlwH-X-Yy-EcnBgzU Cc: NETMOD Working Group Subject: Re: [netmod] netmod wg interim meeting minutes .2014-10-08-14.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: Wed, 08 Oct 2014 17:47:13 -0000 Thanks. That's what I will insist on next time for sure.=20 Tom=20 > On Oct 8, 2014, at 10:34 AM, Kent Watsen wrote: >=20 >=20 > Current best practice (until meetbot grows a new keyword) is for everyone t= o #info when the join with their real name, that way: 1) they are counted in= the summary as having said at least one line and 2) there is a mapping from= their nickname to real name. =20 >=20 > Some meetings even make a point to ask everyone to this during agenda bash= ing. =20 >=20 > Kent >=20 >>> On Oct 8, 2014, at 1:03 PM, "Juergen Schoenwaelder" wrote: >>>=20 >>> On Wed, Oct 08, 2014 at 09:38:28AM -0700, Thomas Nadeau wrote: >>>=20 >>> People present (lines said) >>> --------------------------- >>>=20 >>> * kwatsen (69) >>> * Thomas__ (30) >>> * meetbot (11) >>> * schoenw (7) >>> * Benoit__ (6) >>> * Clyde (2) >>=20 >> I think there were more people in the call. I heard Lada speaking up >> for instance. >>=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 >=20 From nobody Wed Oct 8 15:08:45 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2781A1AD6 for ; Wed, 8 Oct 2014 15:08: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 5YLA20P-tEeb for ; Wed, 8 Oct 2014 15:08:29 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0139.outbound.protection.outlook.com [65.55.169.139]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E39C31A1AB7 for ; Wed, 8 Oct 2014 15:08:24 -0700 (PDT) Received: from BN1PR05MB454.namprd05.prod.outlook.com (10.141.59.17) by BN1PR05MB940.namprd05.prod.outlook.com (10.255.206.143) with Microsoft SMTP Server (TLS) id 15.0.1044.10; Wed, 8 Oct 2014 22:08:23 +0000 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.0.1044.10; Wed, 8 Oct 2014 22:08:21 +0000 Received: from BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.239]) by BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.239]) with mapi id 15.00.1044.008; Wed, 8 Oct 2014 22:08:21 +0000 From: Kent Watsen To: "Alexander Clemm (alex)" , "netmod@ietf.org" Thread-Topic: [netmod] New revision of YANG mount draft Thread-Index: AQHP40RfcXk3qRma8kec20irC7AonA== Date: Wed, 8 Oct 2014 22:08:21 +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 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB454;UriScan:; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 0358535363 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(71364002)(199003)(51444003)(164054003)(51694002)(377454003)(99286002)(19625215002)(36756003)(2656002)(92726001)(99396003)(19300405004)(19617315012)(95666004)(19580395003)(76482002)(77096002)(87936001)(40100002)(85852003)(122556002)(97736003)(106356001)(106116001)(15975445006)(16236675004)(31966008)(4396001)(15202345003)(86362001)(46102003)(85306004)(64706001)(20776003)(101416001)(107046002)(92566001)(21056001)(50986999)(120916001)(54356999)(19580405001)(80022003)(66066001)(105586002)(107886001)(2501002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB454; H:BN1PR05MB456.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_D05B28DE84531kwatsenjunipernet_" MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB940; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/OT66NVk_ilUqn4NsS5jxmxBk_Q4 Subject: Re: [netmod] New revision of YANG mount draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Oct 2014 22:08:40 -0000 --_000_D05B28DE84531kwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Per my action from today's virtual meeting regarding this draft, my fundame= ntal question regards the importance of IETF standardizing this model. Please understand that I'm fully aware of and familiar with OpenDaylight's = implementation of this draft. I think that the desire for an application/= controller to stay in sync with device's via pub/sub with async notificatio= n is important. Of course, RFC6470's netconf-config-change event provides= this, albeit it's not threshold or interval based as your draft says shoul= d be possible. But this draft isn't the YANG module that a "mount server" would advertise;= this draft presents the YANG module a "mount client" would advertise. I'm= not sure what the interoperability issue is that necessitates standardizin= g this. Lastly, after importance of problem, I wonder about the effectiveness of th= e solution. I while I can go along with applications/controllers "mounti= ng" subtrees internally, I don't perceive a general desire or need to prese= nt said mounts or even mount/unmount RPCs via a northbound interface, as do= ing so just means the application/controller is a pass-thru to a higher-lev= el system and not doing anything meaningful itself. Thanks, Kent From: "Alexander Clemm (alex)" > Date: Tuesday, October 7, 2014 at 2:51 PM To: "netmod@ietf.org" > Subject: [netmod] New revision of YANG mount draft Hi, we just wanted to let you know that we have just posted a new revision of d= raft-clemm-netmod-mount: http://datatracker.ietf.org/doc/draft-clemm-netmod-mount/ This document updates an earlier revision that we had posted about a year a= go. It also addresses requirements and use cases in http://datatracker.ietf.org/doc/draft-voit-ne= tmod-peer-mount-requirements/ Here is the abstract: This document introduces capabilities that allow YANG datastores to reference and incorporate information from remote datastores. This is accomplished by extending YANG with the ability to define mount points that act as references to data nodes in remote datastores, and by providing the necessary means to manage and administer those mount points. This facilitates the development of applications that need to access data that transcends individual network devices while improving network-wide object consistency. This document also lays the groundwork for optional extensions to support subscriptions to remote object updates and transparent caching of objects. These options will speed application performance without sacrificing data consistency. Kind regards --- Alex --_000_D05B28DE84531kwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <03815C5D978F3948A5EFE0146533AC76@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

Per my action from today's virtual meeting regarding this draft, my fu= ndamental question regards the importance of IETF standardizing this model.=

Please understand that I'm fully aware of and familiar with OpenDaylig= ht's implementation of this draft.   I think that the desire for an ap= plication/controller to stay in sync with device's via pub/sub with async n= otification is important.   Of course, RFC6470's netconf-config-change event provides this, albeit it's not thres= hold or interval based as your draft says should be possible. 

But this draft isn't the YANG module that a "mount server" w= ould advertise; this draft presents the YANG module a "mount client&qu= ot; would advertise.  I'm not sure what the interoperability issue is = that necessitates standardizing this.

Lastly, after importance of problem, I wonder about the effectiveness = of the solution.   I  while I can go along with applications/cont= rollers "mounting" subtrees internally, I don't perceive a genera= l desire or need to present said mounts or even mount/unmount RPCs via a northbound interface, as doing so just means the application/co= ntroller is a pass-thru to a higher-level system and not doing anything mea= ningful itself.

Thanks,
Kent


From: "Alexander Clemm (alex)&= quot; <alex@cisco.com>
Date: Tuesday, October 7, 2014 at 2= :51 PM
To: "netmod@ietf.org" <= netmod@ietf.org>
Subject: [netmod] New revision of Y= ANG mount draft

Hi,

 

we just wanted to let you know that we have just pos= ted a new revision of draft-clemm-netmod-mount:

http://datatracker.ietf.org/doc/draft-clemm-netmod-mount/=    

This document updates an earlier revision that we ha= d posted about a year ago.  It also addresses

requirements and use cases in http://datatracker.ietf.org/doc/draft-voit-netmod-peer-mount-requirements/<= /a>

 

Here is the abstract:

 

This document introduces capabilities that allow YAN= G datastores to

   reference and incorporate information f= rom remote datastores.  This

   is accomplished by extending YANG with = the ability to define mount

   points that act as references to data n= odes in remote datastores, and

   by providing the necessary means to man= age and administer those mount

   points.  This facilitates the deve= lopment of applications that need

   to access data that transcends individu= al network devices while

   improving network-wide object consisten= cy.

 

   This document also lays the groundwork = for optional extensions to

   support subscriptions to remote object = updates and transparent

   caching of objects.  These options= will speed application performance

   without sacrificing data consistency.

 

Kind regards

--- Alex

 --_000_D05B28DE84531kwatsenjunipernet_-- From nobody Wed Oct 8 15:26:05 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01C501A1AA9 for ; Wed, 8 Oct 2014 15:26: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 cmgFTPsGXRFa for ; Wed, 8 Oct 2014 15:26:00 -0700 (PDT) Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CF8A1A0AFE for ; Wed, 8 Oct 2014 15:26:00 -0700 (PDT) Received: by mail-qc0-f180.google.com with SMTP id x3so49493qcv.11 for ; Wed, 08 Oct 2014 15:25: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=bIp3uGpQABjB5dWM5mp0TOcyJRhEw0gBnQUDozf/4QY=; b=C0TS3EzOl0qyTCmb8o3BYInRUFi1ALHBxqS8+7m4rznXdT5ScQX8WCTwT8Jhws4SnS YwnRc9ia8jT/NTp2h3VfEvdpMgwgtBhLLQoGKmGpaUtDEEfPYEqL5y3pOj6LAlLGHcdc fY5dfItWPp6M0XrB1LII3GVDWv1kJkKZCaWLKJCKH/mJSx7FI2TMOmRBndZsyJPULLdQ 8L8sjlX0yieOiXHSqc1zrAKSTrZirAk2qyvVT0FfgDFiQcdYUo2YjFy02Mi9DqNV8rNX 03LwcPSMHOYDKWKlmWBX+lK6X98N554j9lcEbpW0pT1FaBNnH9C+uPeTCwsB/D+CI0+/ PT+g== X-Gm-Message-State: ALoCoQkOPZuUzNaxxytbOAdMW+7ZMizSp76duKsPt7iQZXThy5+idXggImt4XXaKh5UDidqU8yE3 MIME-Version: 1.0 X-Received: by 10.224.88.137 with SMTP id a9mr17933800qam.88.1412807159442; Wed, 08 Oct 2014 15:25:59 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Wed, 8 Oct 2014 15:25:59 -0700 (PDT) In-Reply-To: References: Date: Wed, 8 Oct 2014 15:25:59 -0700 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: multipart/alternative; boundary=001a11c2bbc0e039200504f0cc49 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/KixVXSflh54cTisbPPSffzeytxQ Cc: "netmod@ietf.org" Subject: Re: [netmod] New revision of YANG mount draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Oct 2014 22:26:03 -0000 --001a11c2bbc0e039200504f0cc49 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 8, 2014 at 3:08 PM, Kent Watsen wrote: > > Per my action from today's virtual meeting regarding this draft, my > fundamental question regards the importance of IETF standardizing this > model. > > Please understand that I'm fully aware of and familiar with > OpenDaylight's implementation of this draft. I think that the desire for > an application/controller to stay in sync with device's via pub/sub with > async notification is important. Of course, RFC6470's > netconf-config-change event provides this, albeit it's not threshold or > interval based as your draft says should be possible. > > But this draft isn't the YANG module that a "mount server" would > advertise; this draft presents the YANG module a "mount client" would > advertise. I'm not sure what the interoperability issue is that > necessitates standardizing this. > > Lastly, after importance of problem, I wonder about the effectiveness of > the solution. I while I can go along with applications/controllers > "mounting" subtrees internally, I don't perceive a general desire or need > to present said mounts or even mount/unmount RPCs via a northbound > interface, as doing so just means the application/controller is a pass-thru > to a higher-level system and not doing anything meaningful itself. > > +1 This seems like a generic master-agent/sub-agent control module, but there is no protocol specified to setup the system and keep it in synch. IMO network data models should just be YANG modules that describe multi-device behavior. The controller can use whatever southbound protocols it needs to implement the network model on devices. Simply gathering remote device subtrees into a common container does not seem very useful. > Thanks, > Kent > > Andy > > From: "Alexander Clemm (alex)" > Date: Tuesday, October 7, 2014 at 2:51 PM > To: "netmod@ietf.org" > Subject: [netmod] New revision of YANG mount draft > > Hi, > > > > we just wanted to let you know that we have just posted a new revision of > draft-clemm-netmod-mount: > > http://datatracker.ietf.org/doc/draft-clemm-netmod-mount/ > > This document updates an earlier revision that we had posted about a year > ago. It also addresses > > requirements and use cases in > http://datatracker.ietf.org/doc/draft-voit-netmod-peer-mount-requirements/ > > > > Here is the abstract: > > > > This document introduces capabilities that allow YANG datastores to > > reference and incorporate information from remote datastores. This > > is accomplished by extending YANG with the ability to define mount > > points that act as references to data nodes in remote datastores, and > > by providing the necessary means to manage and administer those mount > > points. This facilitates the development of applications that need > > to access data that transcends individual network devices while > > improving network-wide object consistency. > > > > This document also lays the groundwork for optional extensions to > > support subscriptions to remote object updates and transparent > > caching of objects. These options will speed application performance > > without sacrificing data consistency. > > > > Kind regards > > --- Alex > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --001a11c2bbc0e039200504f0cc49 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Wed, Oct 8, 2014 at 3:08 PM, Kent Watsen <kwatsen@juniper.net= > wrote:

Per my action from today's virtual meeting regarding this draft, m= y fundamental question regards the importance of IETF standardizing this mo= del.

Please understand that I'm fully aware of and familiar with OpenDa= ylight's implementation of this draft. =A0 I think that the desire for = an application/controller to stay in sync with device's via pub/sub wit= h async notification is important. =A0 Of course, RFC6470's netconf-config-change event provides this, albeit it's n= ot threshold or interval based as your draft says should be possible.=A0

But this draft isn't the YANG module that a "mount server&quo= t; would advertise; this draft presents the YANG module a "mount clien= t" would advertise.=A0 I'm not sure what the interoperability issu= e is that necessitates standardizing this.

Lastly, after importance of problem, I wonder about the effectiveness = of the solution. =A0 I =A0while I can go along with applications/controller= s "mounting" subtrees internally, I don't perceive a general = desire or need to present said mounts or even mount/unmount RPCs via a northbound interface, as doing so just means the application/co= ntroller is a pass-thru to a higher-level system and not doing anything mea= ningful itself.


+1

This seems like a generic master-agent/sub-agent control module, but= there is no protocol
specified to setup the system and keep it i= n synch.

IMO network data models should just be YA= NG modules that describe multi-device behavior.
The controller ca= n use whatever southbound protocols it needs to implement the network
=
model on devices.=A0 Simply gathering remote device subtrees into a co= mmon container does not
seem very useful.


=A0
Thanks,
Kent


Andy
=A0

From: "Alexander Clemm (alex)&= quot; <alex@cisco.co= m>
Date: Tuesday, October 7, 2014 at 2= :51 PM
To: "netmod@ietf.org" <netmod@ietf.org>
Subject: [netmod] New revision of Y= ANG mount draft

Hi,

=A0

we just wanted to let you know that we have just pos= ted a new revision of draft-clemm-netmod-mount:

http://datatracker.ietf.org/doc/draft-c= lemm-netmod-mount/ =A0=A0=A0

This document updates an earlier revision that we ha= d posted about a year ago.=A0 It also addresses

requirements and use cases in http://datatracker.ietf.org/doc/draft-voit-netmod-peer-mount-requirements/<= /a>

=A0

Here is the abstract:

=A0

This document introduces capabilities that allow YAN= G datastores to

=A0=A0 reference and incorporate information from re= mote datastores.=A0 This

=A0=A0 is accomplished by extending YANG with the ab= ility to define mount

=A0=A0 points that act as references to data nodes i= n remote datastores, and

=A0=A0 by providing the necessary means to manage an= d administer those mount

=A0=A0 points.=A0 This facilitates the development o= f applications that need

=A0=A0 to access data that transcends individual net= work devices while

=A0=A0 improving network-wide object consistency.=

=A0

=A0=A0 This document also lays the groundwork for op= tional extensions to

=A0=A0 support subscriptions to remote object update= s and transparent

=A0=A0 caching of objects.=A0 These options will spe= ed application performance

=A0=A0 without sacrificing data consistency.<= u>

=A0

Kind regards

--- Alex

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


--001a11c2bbc0e039200504f0cc49-- From nobody Wed Oct 8 15:27:49 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1101A1AA9 for ; Wed, 8 Oct 2014 15:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.286 X-Spam-Level: X-Spam-Status: No, score=-15.286 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e_RgZAfKC_Ry for ; Wed, 8 Oct 2014 15:27:43 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB4821A0AFE for ; Wed, 8 Oct 2014 15:27:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18601; q=dns/txt; s=iport; t=1412807263; x=1414016863; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=tjruIY/ogvoAkSDDGVW047XKA6IQjh2NDPoEMPKqBS4=; b=KsL3MNMUiM+xjInnYaXLi+8jT2MihT4y0nqLEDBndbdNqYehIUI91UsR 81vXYclawXHd5HMwC/+q9aPa6fguYwknbY0i3unHZbug0Ck9dTeNoR9Fp s8vXbRSvnfvQ/a19P6BlWEX8ycXGE2qinZUlBMNAWTYokkdynHKUZXiEp g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAIG5NVStJV2Z/2dsb2JhbABfgkhGU1y7Bo4dgW+HSwKBChYBe4QDAQEBBC1FFwIBCA4DAwEBAQsdBzIUCQgCBAESCBOIIw3GFAEXj2wnIBcBgy2BHgWRd4Q+gXaGSDyDCY0bg3+DY2yBBkKBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,681,1406592000"; d="scan'208,217";a="358631189" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 08 Oct 2014 22:27:41 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s98MRf36000868 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Oct 2014 22:27:41 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.163]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Wed, 8 Oct 2014 17:27:41 -0500 From: "Alexander Clemm (alex)" To: Kent Watsen , "netmod@ietf.org" Thread-Topic: [netmod] New revision of YANG mount draft Thread-Index: AQHP40Rf8kMXz8u2QICzU6EjzD0qC5wmwz0g Date: Wed, 8 Oct 2014 22:27:40 +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: [10.154.204.15] Content-Type: multipart/alternative; boundary="_000_DBC595ED2346914F9F81D17DD5C32B571C814EA7xmbrcdx05ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/OflP0q188jUECTqkg-uZvOH52p8 Subject: Re: [netmod] New revision of YANG mount draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 08 Oct 2014 22:27:46 -0000 --_000_DBC595ED2346914F9F81D17DD5C32B571C814EA7xmbrcdx05ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kent, yes, this is fundamentally about the mount client. However, the "mount cli= ent" itself is part of a server to other clients. This is why it has a dat= astore, which it presents to its clients. "Client" is merely a role; it is= not the top of the "food chain", you may have cascading relationships betw= een systems where a system is client to one system and server to another. = For these reasons, this is not merely a matter of how you build an applicat= ion and about "consuming" data from remote system, but about at the same ti= me making it accessible to other systems. This is why we believe it matter= s and affects interoperability, hence is relevant for standardization. Mountpoint management is generally not intended for clients of the datastor= e which includes the remote information. It is intended for purposes of sy= stem management and administration. In general, the mount structures will = be automatically populated and bootstrapped as part of mountpoint implement= ation and the underlying implementation infrastructure. They are not of co= ncern for general applications. However, for a complete system, it is impo= rtant that these aspects are addressed, which is why they are included in t= he specification. Regarding config change events, I agree those are important and can address= some cases (basically when only config data is involved), but somewhat lim= ited if we want also address operational data represented in YANG datastore= s. Changes/updates to such data are not subjected to configuration change = events. To synchronize and receive updates, applications today would need = to retrieve this information on demand and, for many applications, resort t= o polling. There are many issues with polling known from SNMP, including l= ack of efficiency, lack of robustness, difficulty to synchronize polling in= tervals, etc. This is why we believe that the ability to support subscript= ions to data updates are important - not just for more efficient implementa= tions of mount caching, but also beyond that once YANG-defined data is to b= e used for assurance and not just fulfillment-related applications. Thanks --- Alex From: Kent Watsen [mailto:kwatsen@juniper.net] Sent: Wednesday, October 08, 2014 3:08 PM To: Alexander Clemm (alex); netmod@ietf.org Subject: Re: [netmod] New revision of YANG mount draft Per my action from today's virtual meeting regarding this draft, my fundame= ntal question regards the importance of IETF standardizing this model. Please understand that I'm fully aware of and familiar with OpenDaylight's = implementation of this draft. I think that the desire for an application/= controller to stay in sync with device's via pub/sub with async notificatio= n is important. Of course, RFC6470's netconf-config-change event provides= this, albeit it's not threshold or interval based as your draft says shoul= d be possible. But this draft isn't the YANG module that a "mount server" would advertise;= this draft presents the YANG module a "mount client" would advertise. I'm= not sure what the interoperability issue is that necessitates standardizin= g this. Lastly, after importance of problem, I wonder about the effectiveness of th= e solution. I while I can go along with applications/controllers "mounti= ng" subtrees internally, I don't perceive a general desire or need to prese= nt said mounts or even mount/unmount RPCs via a northbound interface, as do= ing so just means the application/controller is a pass-thru to a higher-lev= el system and not doing anything meaningful itself. Thanks, Kent From: "Alexander Clemm (alex)" > Date: Tuesday, October 7, 2014 at 2:51 PM To: "netmod@ietf.org" > Subject: [netmod] New revision of YANG mount draft Hi, we just wanted to let you know that we have just posted a new revision of d= raft-clemm-netmod-mount: http://datatracker.ietf.org/doc/draft-clemm-netmod-mount/ This document updates an earlier revision that we had posted about a year a= go. It also addresses requirements and use cases in http://datatracker.ietf.org/doc/draft-voit-ne= tmod-peer-mount-requirements/ Here is the abstract: This document introduces capabilities that allow YANG datastores to reference and incorporate information from remote datastores. This is accomplished by extending YANG with the ability to define mount points that act as references to data nodes in remote datastores, and by providing the necessary means to manage and administer those mount points. This facilitates the development of applications that need to access data that transcends individual network devices while improving network-wide object consistency. This document also lays the groundwork for optional extensions to support subscriptions to remote object updates and transparent caching of objects. These options will speed application performance without sacrificing data consistency. Kind regards --- Alex --_000_DBC595ED2346914F9F81D17DD5C32B571C814EA7xmbrcdx05ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Kent,

 

yes, this is fundament= ally about the mount client.  However, the “mount client” = itself is part of a server to other clients.  This is why it has a dat= astore, which it presents to its clients.  “Client” is mer= ely a role; it is not the top of the “food chain”, you may have ca= scading relationships between systems where a system is client to one syste= m and server to another.  For these reasons, this is not merely a matt= er of how you build an application and about “consuming” data from remote system, but about at the same time making it accessible t= o other systems.  This is why we believe it matters and affects intero= perability, hence is relevant for standardization. 

 

Mountpoint management = is generally not intended for clients of the datastore which includes the r= emote information.  It is intended for purposes of system management a= nd administration.  In general, the mount structures will be automatically populated and bootstrapped as part of mou= ntpoint implementation and the underlying implementation infrastructure.&nb= sp; They are not of concern for general applications.  However, for a = complete system, it is important that these aspects are addressed, which is why they are included in the specification= . 

 

Regarding config chang= e events, I agree those are important and can address some cases (basically= when only config data is involved), but somewhat limited if we want also a= ddress operational data represented in YANG datastores.  Changes/updates to such data are not subjected t= o configuration change events.  To synchronize and receive updates, ap= plications today would need to retrieve this information on demand and, for= many applications, resort to polling.  There are many issues with polling known from SNMP, including lack of efficiency= , lack of robustness, difficulty to synchronize polling intervals, etc.&nbs= p; This is why we believe that the ability to support subscriptions to data= updates are important – not just for more efficient implementations of mount caching, but also beyond that once= YANG-defined data is to be used for assurance and not just fulfillment-rel= ated applications. 

 

Thanks

--- Alex

 

From: Kent Wat= sen [mailto:kwatsen@juniper.net]
Sent: Wednesday, October 08, 2014 3:08 PM
To: Alexander Clemm (alex); netmod@ietf.org
Subject: Re: [netmod] New revision of YANG mount draft

 

&n= bsp;

Per my = action from today's virtual meeting regarding this draft, my fundamental qu= estion regards the importance of IETF standardizing this model.<= /span>

&n= bsp;

Please = understand that I'm fully aware of and familiar with OpenDaylight's impleme= ntation of this draft.   I think that the desire for an application/co= ntroller to stay in sync with device's via pub/sub with async notification is important.   Of course, RFC6470's = netconf-config-change event provides this, albeit it's not threshold or int= erval based as your draft says should be possible. <= /p>

&n= bsp;

But thi= s draft isn't the YANG module that a "mount server" would adverti= se; this draft presents the YANG module a "mount client" would ad= vertise.  I'm not sure what the interoperability issue is that necessitates standardizing this.

&n= bsp;

Lastly,= after importance of problem, I wonder about the effectiveness of the solut= ion.   I  while I can go along with applications/controllers &quo= t;mounting" subtrees internally, I don't perceive a general desire or need to present said mounts or even mount/unmount RPCs v= ia a northbound interface, as doing so just means the application/controlle= r is a pass-thru to a higher-level system and not doing anything meaningful= itself.

&n= bsp;

Thanks,=

Kent

&n= bsp;

&n= bsp;

From: "Alexander Clemm (alex)" <alex@cisco.com>
Date: Tuesday, October 7, 2014 at 2:51 PM
To: "netmod@ietf.org&quo= t; <netmod@ietf.org>
Subject: [netmod] New revision of YANG mount draft=

&n= bsp;

Hi,

 =

we just wanted to let yo= u know that we have just posted a new revision of draft-clemm-netmod-mount:

http://datatracker.ietf.org/d= oc/draft-clemm-netmod-mount/    

This document updates an= earlier revision that we had posted about a year ago.  It also addres= ses

requirements and use cas= es in http://datatracker.ietf.org/doc/draft-voit-netmod-peer-mount-requirements/<= /a>

 =

Here is the abstract:

 =

This document introduces= capabilities that allow YANG datastores to

   reference a= nd incorporate information from remote datastores.  This

   is accompli= shed by extending YANG with the ability to define mount

   points that= act as references to data nodes in remote datastores, and

   by providin= g the necessary means to manage and administer those mount

   points.&nbs= p; This facilitates the development of applications that need

   to access d= ata that transcends individual network devices while

   improving n= etwork-wide object consistency.

 =

   This docume= nt also lays the groundwork for optional extensions to

   support sub= scriptions to remote object updates and transparent

   caching of = objects.  These options will speed application performance<= /span>

   without sac= rificing data consistency.

 =

Kind regards<= /span>

--- Alex

--_000_DBC595ED2346914F9F81D17DD5C32B571C814EA7xmbrcdx05ciscoc_-- From nobody Thu Oct 9 05:33:32 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 299C61ACE2F for ; Thu, 9 Oct 2014 05:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, 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 aG3raZ6Z7mCk for ; Thu, 9 Oct 2014 05:33:29 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id EAF641ACE36 for ; Thu, 9 Oct 2014 05:33:28 -0700 (PDT) Received: from h200.viagenie.ca (h200.viagenie.ca [206.123.31.200]) by jazz.viagenie.ca (Postfix) with ESMTPSA id BF4BD403E1 for ; Thu, 9 Oct 2014 08:33:27 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: JF Tremblay In-Reply-To: Date: Thu, 9 Oct 2014 08:33:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <766247DF-0BFB-4AAA-9D37-95B6819A4978@lucidvision.com> <20141008170313.GB73652@elstar.local> To: NETMOD Working Group X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/iYl7OxecONx5VY65aiDU9_N_-Sw Subject: Re: [netmod] netmod wg interim meeting minutes .2014-10-08-14.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, 09 Oct 2014 12:33:31 -0000 On Oct 8, 2014, at 1:18 PM, Thomas Nadeau = wrote: >> On Oct 8, 2014, at 10:03 AM, Juergen Schoenwaelder = wrote: >>=20 >>> On Wed, Oct 08, 2014 at 09:38:28AM -0700, Thomas Nadeau wrote: >>>=20 >>> People present (lines said) >>> --------------------------- >>>=20 >>> * kwatsen (69) >>> * Thomas__ (30) >>> * meetbot (11) >>> * schoenw (7) >>> * Benoit__ (6) >>> * Clyde (2) >>=20 >> I think there were more people in the call. I heard Lada speaking up >> for instance. >>=20 >> /js >>=20 > Yes there were. These we just those that joined irc which is how we = recorded meeting minutes (thanks again Kent!). I asked everyone at the = start to join and provided easy instructions for how to join. This is = how we will continue to record meeting minutes and attendees going = forward as it automates and streamlines things. >=20 > Tom=20 Just a note, I was on the irc call and my handle isn=92t on the list. = Looks like the meetbot only records the name of those who spoke (with = their number of lines apparently). If this is the preferred way to = record, we could do a roll call on irc to make sure everyone speaks once = and is recorded (just an idea).=20 I noted the following people on the webex (in the order they appeared in = Webex when I noted them):=20 Tom Nadeau Eric Voit Alexander Clemm Aseem Choudhary Balazs Lengyel Benoit Claise Clyde Wildes Dana Blair David Reid Dean B Juerguen Kent Watsen Kiran Koushik Agrahara Sreenivasa Lada Lhotka Mahesh Jethanandani Peter Van Horne Jean-Francois Tremblay Call-in User_[4,6-8] (there were 4 of them at that time) JF= From nobody Thu Oct 9 05:50:49 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF0F11ACE41 for ; Thu, 9 Oct 2014 05:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, 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 hkZbkw4-OY-r for ; Thu, 9 Oct 2014 05:50:47 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 646621ACE4D for ; Thu, 9 Oct 2014 05:50:46 -0700 (PDT) Received: from [10.102.170.228] (mobile-166-171-250-029.mycingular.net [166.171.250.29]) by lucidvision.com (Postfix) with ESMTP id B689428B9498; Thu, 9 Oct 2014 08:50:45 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Thomas Nadeau X-Mailer: iPhone Mail (12A405) In-Reply-To: Date: Thu, 9 Oct 2014 05:50:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <759F3218-56D7-41F6-99A4-7A4531B3971D@lucidvision.com> References: <766247DF-0BFB-4AAA-9D37-95B6819A4978@lucidvision.com> <20141008170313.GB73652@elstar.local> To: JF Tremblay Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/YfDg5rl5oH83F2IhvFi5BHoYHiQ Cc: NETMOD Working Group Subject: Re: [netmod] netmod wg interim meeting minutes .2014-10-08-14.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, 09 Oct 2014 12:50:48 -0000 Ok cool. We need to take a roll call at the start of the meeting then. A sim= ple approach is to simply have everyone type a hello message into irc to au= tomate this.=20 Tom=20 > On Oct 9, 2014, at 5:33 AM, JF Tremblay wrote: >=20 > On Oct 8, 2014, at 1:18 PM, Thomas Nadeau wrote:= >=20 >>> On Oct 8, 2014, at 10:03 AM, Juergen Schoenwaelder wrote: >>>=20 >>>> On Wed, Oct 08, 2014 at 09:38:28AM -0700, Thomas Nadeau wrote: >>>>=20 >>>> People present (lines said) >>>> --------------------------- >>>>=20 >>>> * kwatsen (69) >>>> * Thomas__ (30) >>>> * meetbot (11) >>>> * schoenw (7) >>>> * Benoit__ (6) >>>> * Clyde (2) >>>=20 >>> I think there were more people in the call. I heard Lada speaking up >>> for instance. >>>=20 >>> /js >=20 >> Yes there were. These we just those that joined irc which is how we recor= ded meeting minutes (thanks again Kent!). I asked everyone at the start to j= oin and provided easy instructions for how to join. This is how we will cont= inue to record meeting minutes and attendees going forward as it automates a= nd streamlines things. >>=20 >> Tom >=20 > Just a note, I was on the irc call and my handle isn=E2=80=99t on the list= . Looks like the meetbot only records the name of those who spoke (with thei= r number of lines apparently). If this is the preferred way to record, we co= uld do a roll call on irc to make sure everyone speaks once and is recorded (= just an idea).=20 >=20 > I noted the following people on the webex (in the order they appeared in W= ebex when I noted them):=20 > Tom Nadeau > Eric Voit > Alexander Clemm > Aseem Choudhary > Balazs Lengyel > Benoit Claise > Clyde Wildes > Dana Blair > David Reid > Dean B > Juerguen > Kent Watsen > Kiran Koushik Agrahara Sreenivasa > Lada Lhotka > Mahesh Jethanandani > Peter Van Horne > Jean-Francois Tremblay > Call-in User_[4,6-8] (there were 4 of them at that time) >=20 > JF > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 From nobody Thu Oct 9 05:52:56 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC571ACE32 for ; Thu, 9 Oct 2014 05:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.286 X-Spam-Level: X-Spam-Status: No, score=-15.286 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lY3AjcMUCKyV for ; Thu, 9 Oct 2014 05:52: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 3161A1ACE50 for ; Thu, 9 Oct 2014 05:52:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5381; q=dns/txt; s=iport; t=1412859173; x=1414068773; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=lEXBqSmTNyeX32lmHyycBCdSNlb7ewcLde36uSmUrU0=; b=W1uWpZ4xoYVCVgfPwDqIz7X5g76vb+o+1oUDlHziZ2iLAOQqY2pbsv3X mg1LEIicgw0XAoKv2cHAWm0s0A3Qiepp0SZXV4GmUgZkbb5TndaFp76Gd 03iX0SunSeVO1Tpyu2AtWf4O1tk0BrqBCJPo+jXYu/5MrWQYqAiT8Kx4+ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuYEAICENlStJssW/2dsb2JhbABcA4NhWIhhwi8BCYZ5VAKBHwF7hAQBAQQBAQFrCgEOAgsECgIICRYIBwkDAgECAQkMHxEGAQwBBQIBAYg6DcQaARcEjQKCbQEBPxAHCQiEOgWGLZceh2aEbok9gXqBazsvAYEOgTsBAQE X-IronPort-AV: E=Sophos;i="5.04,684,1406592000"; d="scan'208,217";a="204940419" 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 Oct 2014 12:52:51 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s99Cqout017522; Thu, 9 Oct 2014 12:52:50 GMT Message-ID: <54368522.9070402@cisco.com> Date: Thu, 09 Oct 2014 14:52:50 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Thomas Nadeau , Juergen Schoenwaelder References: <766247DF-0BFB-4AAA-9D37-95B6819A4978@lucidvision.com> <20141008170313.GB73652@elstar.local> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050209040903050106020004" Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/mgiU25T2jYzBiV8m9-AWcCSKSaY Cc: NETMOD Working Group Subject: Re: [netmod] netmod wg interim meeting minutes .2014-10-08-14.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, 09 Oct 2014 12:52:56 -0000 This is a multi-part message in MIME format. --------------050209040903050106020004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Tom, I'm all in favor of new participation tools. However, let's not forget https://www.ietf.org/iesg/statement/interim-meetings.html Detailed minutes, including a list of attendees, must be sent to proceedings@ietf.org and the working group mail list within 10 days of the event. So IRC is fine, and should be used as a tool to create the meeting minutes. Using whoever was logged in IRC as attendee list is not appropriate IMO. Also, there were a couple of points mentioned during the meeting that were not captured in IRC (so in the minutes). Does it mean it's the speaker responsibility to make sure his point in the minutes? Regards, Benoit > Yes there were. These we just those that joined irc which is how we recorded meeting minutes (thanks again Kent!). I asked everyone at the start to join and provided easy instructions for how to join. This is how we will continue to record meeting minutes and attendees going forward as it automates and streamlines things. > > Tom > > > >> On Oct 8, 2014, at 10:03 AM, Juergen Schoenwaelder wrote: >> >>> On Wed, Oct 08, 2014 at 09:38:28AM -0700, Thomas Nadeau wrote: >>> >>> People present (lines said) >>> --------------------------- >>> >>> * kwatsen (69) >>> * Thomas__ (30) >>> * meetbot (11) >>> * schoenw (7) >>> * Benoit__ (6) >>> * Clyde (2) >> I think there were more people in the call. I heard Lada speaking up >> for instance. >> >> /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 > --------------050209040903050106020004 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Tom,

I'm all in favor of new participation tools.
However, let's not forget https://www.ietf.org/iesg/statement/interim-meetings.html
Detailed minutes, including a list of attendees, must be sent to
proceedings@ietf.org and the working group mail list within 10 days of
the event.
So IRC is fine, and should be used as a tool to create the meeting minutes.
Using whoever was logged in IRC as attendee list is not appropriate IMO.
Also, there were a couple of points mentioned during the meeting that were not captured in IRC (so in the minutes). Does it mean it's the speaker responsibility to make sure his point in the minutes?

Regards, Benoit
Yes there were. These we just those that joined irc which is how we recorded meeting minutes (thanks again Kent!). I asked everyone at the start to join and provided easy instructions for how to join. This is how we will continue to record meeting minutes and attendees going forward as it automates and streamlines things.

Tom 




On Oct 8, 2014, at 10:03 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:


On Wed, Oct 08, 2014 at 09:38:28AM -0700, Thomas Nadeau wrote:

People present (lines said)
---------------------------

* kwatsen (69)
* Thomas__ (30)
* meetbot (11)
* schoenw (7)
* Benoit__ (6)
* Clyde (2)

I think there were more people in the call. I heard Lada speaking up
for instance.

/js

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

--------------050209040903050106020004-- From nobody Thu Oct 9 05:53:24 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 603601ACE32 for ; Thu, 9 Oct 2014 05:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnXie29sBwea for ; Thu, 9 Oct 2014 05:53:21 -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 F0C781ACE57 for ; Thu, 9 Oct 2014 05:53:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1963; q=dns/txt; s=iport; t=1412859199; x=1414068799; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=0s3s3uagujFT652L4/DVZeI2C5naIS7PXCpabe1dWmQ=; b=jvJPnGJhs1op/SSk3I+kdE7kf3RKOhwmTAEEZq30tI4OOyA0qMbSfcuw ZKz0EqfHfZp2TQ8r7JM0J49vpCjNWZ2iF5NoJubP+Pdu++tad2x2ZQEnD EAGeE6k299AS21m/8gJOOV4cvQzE4YsmBwMF563H/v3SShW/23uWqUjRN I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsEAEiENlStJssW/2dsb2JhbABfg2FYyxAKhnlUAoEfAXuEBAEBBAEBAS8BBTYKEQsQCAkWDwkDAgECARUwBgEMBgIBAYg6DcQaARMEjQaDRYRLAQSGLZJQhE6HZoRuiT2BeoFrOy+CSgEBAQ X-IronPort-AV: E=Sophos;i="5.04,684,1406592000"; d="scan'208";a="200830248" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 09 Oct 2014 12:53:17 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s99CrHvR007184; Thu, 9 Oct 2014 12:53:17 GMT Message-ID: <5436853D.8090306@cisco.com> Date: Thu, 09 Oct 2014 14:53:17 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: JF Tremblay , NETMOD Working Group References: <766247DF-0BFB-4AAA-9D37-95B6819A4978@lucidvision.com> <20141008170313.GB73652@elstar.local> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/rACyjnvggF01mglmkG95aouFYCs Subject: Re: [netmod] netmod wg interim meeting minutes .2014-10-08-14.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, 09 Oct 2014 12:53:23 -0000 On 09/10/2014 14:33, JF Tremblay wrote: > On Oct 8, 2014, at 1:18 PM, Thomas Nadeau wrote: > >>> On Oct 8, 2014, at 10:03 AM, Juergen Schoenwaelder wrote: >>> >>>> On Wed, Oct 08, 2014 at 09:38:28AM -0700, Thomas Nadeau wrote: >>>> >>>> People present (lines said) >>>> --------------------------- >>>> >>>> * kwatsen (69) >>>> * Thomas__ (30) >>>> * meetbot (11) >>>> * schoenw (7) >>>> * Benoit__ (6) >>>> * Clyde (2) >>> I think there were more people in the call. I heard Lada speaking up >>> for instance. >>> >>> /js >>> >> Yes there were. These we just those that joined irc which is how we recorded meeting minutes (thanks again Kent!). I asked everyone at the start to join and provided easy instructions for how to join. This is how we will continue to record meeting minutes and attendees going forward as it automates and streamlines things. >> >> Tom > Just a note, I was on the irc call and my handle isnt on the list. Looks like the meetbot only records the name of those who spoke (with their number of lines apparently). If this is the preferred way to record, we could do a roll call on irc to make sure everyone speaks once and is recorded (just an idea). > > I noted the following people on the webex (in the order they appeared in Webex when I noted them): > Tom Nadeau > Eric Voit > Alexander Clemm > Aseem Choudhary > Balazs Lengyel > Benoit Claise > Clyde Wildes > Dana Blair > David Reid > Dean B > Juerguen > Kent Watsen > Kiran Koushik Agrahara Sreenivasa > Lada Lhotka > Mahesh Jethanandani > Peter Van Horne > Jean-Francois Tremblay > Call-in User_[4,6-8] (there were 4 of them at that time) Two of those callers where Alex Clemm and Eric Voit. Regards, Benoit > > JF > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > From nobody Thu Oct 9 05:57:16 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 311031ACE74 for ; Thu, 9 Oct 2014 05:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.437 X-Spam-Level: X-Spam-Status: No, score=-1.437 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, RP_MATCHES_RCVD=-0.786] 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 nH0AGyMddV_2 for ; Thu, 9 Oct 2014 05:57:13 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 364FD1ACEAE for ; Thu, 9 Oct 2014 05:56:03 -0700 (PDT) Received: from [192.168.1.108] (unknown [195.113.220.254]) by mail.nic.cz (Postfix) with ESMTPSA id 76B1F13F811; Thu, 9 Oct 2014 14:56:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1412859361; bh=9xkUhfLOQ4b8TKkGU0AL6x0B88YG9k25Qw6CUa4ewuw=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Qzi3Fc5NJEDJkR8/Hp0lklbldZ7WQ7N0KhMWxK+C6Hqn2M1rYd8zWjeeAvmvGwCr5 4L5zA0k3ZhagBEVcadSas+a0WJmPWeIspMZLlveGmXNw2M9PGJqK+oef0Z2U8NvVCY u8+nJHRnH7AA71fg0u6lxY/xVk/yhty3NAjNBk+4= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <759F3218-56D7-41F6-99A4-7A4531B3971D@lucidvision.com> Date: Thu, 9 Oct 2014 14:55:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <766247DF-0BFB-4AAA-9D37-95B6819A4978@lucidvision.com> <20141008170313.GB73652@elstar.local> <759F3218-56D7-41F6-99A4-7A4531B3971D@lucidvision.com> To: Thomas Nadeau X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/3V8KiD474eBYmzlS-aMSY9834rs Cc: NETMOD Working Group Subject: Re: [netmod] netmod wg interim meeting minutes .2014-10-08-14.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, 09 Oct 2014 12:57:15 -0000 Hi, I=92ve never been an IRC user, so I just wonder why we need to have a = new minute-taking tool. For the other thread of interim meetings, = etherpad seems to work fine. Lada On 09 Oct 2014, at 14:50, Thomas Nadeau wrote: > Ok cool. We need to take a roll call at the start of the meeting then. = A simple approach is to simply have everyone type a hello message into = irc to automate this.=20 >=20 > Tom=20 >=20 >=20 >=20 >=20 >> On Oct 9, 2014, at 5:33 AM, JF Tremblay = wrote: >>=20 >> On Oct 8, 2014, at 1:18 PM, Thomas Nadeau = wrote: >>=20 >>>> On Oct 8, 2014, at 10:03 AM, Juergen Schoenwaelder = wrote: >>>>=20 >>>>> On Wed, Oct 08, 2014 at 09:38:28AM -0700, Thomas Nadeau wrote: >>>>>=20 >>>>> People present (lines said) >>>>> --------------------------- >>>>>=20 >>>>> * kwatsen (69) >>>>> * Thomas__ (30) >>>>> * meetbot (11) >>>>> * schoenw (7) >>>>> * Benoit__ (6) >>>>> * Clyde (2) >>>>=20 >>>> I think there were more people in the call. I heard Lada speaking = up >>>> for instance. >>>>=20 >>>> /js >>=20 >>> Yes there were. These we just those that joined irc which is how we = recorded meeting minutes (thanks again Kent!). I asked everyone at the = start to join and provided easy instructions for how to join. This is = how we will continue to record meeting minutes and attendees going = forward as it automates and streamlines things. >>>=20 >>> Tom >>=20 >> Just a note, I was on the irc call and my handle isn=92t on the list. = Looks like the meetbot only records the name of those who spoke (with = their number of lines apparently). If this is the preferred way to = record, we could do a roll call on irc to make sure everyone speaks once = and is recorded (just an idea).=20 >>=20 >> I noted the following people on the webex (in the order they appeared = in Webex when I noted them):=20 >> Tom Nadeau >> Eric Voit >> Alexander Clemm >> Aseem Choudhary >> Balazs Lengyel >> Benoit Claise >> Clyde Wildes >> Dana Blair >> David Reid >> Dean B >> Juerguen >> Kent Watsen >> Kiran Koushik Agrahara Sreenivasa >> Lada Lhotka >> Mahesh Jethanandani >> Peter Van Horne >> Jean-Francois Tremblay >> Call-in User_[4,6-8] (there were 4 of them at that time) >>=20 >> JF >> _______________________________________________ >> 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 Thu Oct 9 06:48:56 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D349B1ACEEF for ; Thu, 9 Oct 2014 06:48:42 -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 J9iLRxZkcFHo for ; Thu, 9 Oct 2014 06:48:38 -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 400241ACED9 for ; Thu, 9 Oct 2014 06:48:32 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-3b-5436922eb98b Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id E0.D1.21334.E2296345; Thu, 9 Oct 2014 15:48:30 +0200 (CEST) Received: from [159.107.197.222] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.65) with Microsoft SMTP Server id 14.3.174.1; Thu, 9 Oct 2014 15:48:29 +0200 Message-ID: <5436922D.3090107@ericsson.com> Date: Thu, 9 Oct 2014 15:48:29 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "netmod@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKJMWRmVeSWpSXmKPExsUyM+Jvja7eJLMQg+lzxSzmX2xkdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxuUW7oLFzBXrf3xmbmBcwdTFyMEhIWAicWtlShcjJ5ApJnHh 3nq2LkYuDiGBo4wSX9adYoZw1jBKLD45hRGkildAW2L53QnsIDaLgIrE9astzCA2m4CRxNT+ 8ywgtqhAlMSdS/2sEPWCEidnPgGLiwioS8zcCbKBg0MYqPftr2qQMLOArcSFOddZIGx5ie1v 54CNFBLQkHh44S/rBEa+WUgmzULSMgtJywJG5lWMosWpxcW56UbGeqlFmcnFxfl5enmpJZsY geF0cMtv3R2Mq187HmIU4GBU4uFNUDELEWJNLCuuzD3EKM3BoiTOu+jcvGAhgfTEktTs1NSC 1KL4otKc1OJDjEwcnFINjCF5DFv0i6MSAifeX+Iuc99xY8Jk3ei9dyzWv4m4ZavuZXXt6+oE GevexVVSJQdWzU/pKY9KkTRx1hG95biYN0u+b+p/t//rJExlv0ROfrIu4LExX1Bm2cWrJSuV Qq7YbF61tufy2/nvIp9/8yk5/yl5rvUM9waDs6sNJWxMW64ULhdS7Yh6qsRSnJFoqMVcVJwI AD60/T0IAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/vXtnN4W4r9mNU43TZ46ZSFOPflE Subject: [netmod] Additions to the issue list X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 09 Oct 2014 13:48:43 -0000 Hello Jurgen, Martin, Following the decisions of the new York interim could you please add actions and nonUnique leaf-lists as separate issues to the YANG 1.1 issue list please. regards Balazs -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist ECN: 831 7320 Tel: +36-1-437-7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Thu Oct 9 11:31:27 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6B11A0147 for ; Thu, 9 Oct 2014 11:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.285 X-Spam-Level: X-Spam-Status: No, score=-15.285 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, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSooyQMthreG for ; Thu, 9 Oct 2014 11:31:20 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97BA31A007E for ; Thu, 9 Oct 2014 11:31:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25845; q=dns/txt; s=iport; t=1412879480; x=1414089080; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=FTPI+M4QzGvCnLYoeQV+770AZAKAaQeKnkbitqZ46/M=; b=aOHirc5rlLZ7tkh/wcKrMj9eZr0UKnWCmvjlyUbWFDogcfCs9vS9J5Fs BOPhqwC5NguTOLa/IaqBAOwRp9Pu9iu0jG81+zKn51pfRIBCIAMlMwg1t JntmNt8L84h5KohkT7ZhqTWOZfChIW1csiHY9F9CdPYrWIxelMl+6RsFB Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcFAPjTNlStJV2Z/2dsb2JhbABfFoIyRlNYBLsKjh+Bb4dLAoEJFgF7hAMBAQECAi1FBxACAQgOAwMBAQELAhQHBzIUCQgCBAENBQgBEogjDcMYARePWRMnDRMRBgECB4MkgR4FkXmEQoF2hkg8gwqKTIJTg36DY2wBAYEEAh4GHIECAQEB X-IronPort-AV: E=Sophos; i="5.04,686,1406592000"; d="scan'208,217"; a="85514806" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-3.cisco.com with ESMTP; 09 Oct 2014 18:31:18 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s99IVIbY017367 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Oct 2014 18:31:18 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.41]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Thu, 9 Oct 2014 13:31:18 -0500 From: "Eric Voit (evoit)" To: Kent Watsen , "netmod@ietf.org" Thread-Topic: [netmod] New revision of YANG mount draft Thread-Index: AQHP40Rf8kMXz8u2QICzU6EjzD0qC5wmwz0ggAEPk+A= Date: Thu, 9 Oct 2014 18:31:17 +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: [10.116.134.135] Content-Type: multipart/alternative; boundary="_000_EF64FF31F4C4384DBCE5D513A791C2B120A43E39xmbalnx11ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/pvy7_OxUTTvWRXE654hxr8yfm3I Subject: Re: [netmod] New revision of YANG mount draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 09 Oct 2014 18:31:26 -0000 --_000_EF64FF31F4C4384DBCE5D513A791C2B120A43E39xmbalnx11ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kent, To your thoughts on "general desire or need to present said mounts": (1) There are successful generalized distributed datastores The Object Management Group has been standardizing a Data Distribution Service (DDS). Products in this space have a ~$100M current (and growing)= market. A DDS vendor is considering contributing to the IETF peer mount r= equirements draft. They want to add YANG support to their existing DDS pr= oducts for support multi-device abstractions. (Look for them to chime in o= n the Netmod list after their management gives a 'go-ahead'.) (2) Some in Academia suggesting we overload IGP to achieve distributed poli= cy/config convergence A white paper which showing applications brutalizing ISIS/OSPF to achieve a= specific policy goal is here. The paper proposes injecting fake configuration info into exi= sting Network Elements *in one place*. Network consistency is achieved au= tomatically via IGP convergence. IMHO, we should not be overloading routi= ng protocols to accomplish configuration convergence for new applications. = Instead with Mount objects and intents could be explicitly coordinated. More in line with your thoughts... From: netmod, October 08, 2014 6:28 PM Hi Kent, yes, this is fundamentally about the mount client. However, the "mount cli= ent" itself is part of a server to other clients. This is why it has a dat= astore, which it presents to its clients. "Client" is merely a role; it is= not the top of the "food chain", you may have cascading relationships betw= een systems where a system is client to one system and server to another. = For these reasons, this is not merely a matter of how you build an applicat= ion and about "consuming" data from remote system, but about at the same ti= me making it accessible to other systems. This is why we believe it matter= s and affects interoperability, hence is relevant for standardization. Mountpoint management is generally not intended for clients of the datastor= e which includes the remote information. It is intended for purposes of sy= stem management and administration. In general, the mount structures will = be automatically populated and bootstrapped as part of mountpoint implement= ation and the underlying implementation infrastructure. They are not of co= ncern for general applications. However, for a complete system, it is impo= rtant that these aspects are addressed, which is why they are included in t= he specification. Regarding config change events, I agree those are important and can address= some cases (basically when only config data is involved), but somewhat lim= ited if we want also address operational data represented in YANG datastore= s. Changes/updates to such data are not subjected to configuration change = events. To synchronize and receive updates, applications today would need = to retrieve this information on demand and, for many applications, resort t= o polling. There are many issues with polling known from SNMP, including l= ack of efficiency, lack of robustness, difficulty to synchronize polling in= tervals, etc. This is why we believe that the ability to support subscript= ions to data updates are important - not just for more efficient implementa= tions of mount caching, but also beyond that once YANG-defined data is to b= e used for assurance and not just fulfillment-related applications. Thanks --- Alex From: Kent Watsen [mailto:kwatsen@juniper.net] Sent: Wednesday, October 08, 2014 3:08 PM To: Alexander Clemm (alex); netmod@ietf.org Subject: Re: [netmod] New revision of YANG mount draft Per my action from today's virtual meeting regarding this draft, my fundame= ntal question regards the importance of IETF standardizing this model. Please understand that I'm fully aware of and familiar with OpenDaylight's = implementation of this draft. I think that the desire for an application/= controller to stay in sync with device's via pub/sub with async notificatio= n is important. Of course, RFC6470's netconf-config-change event provides= this, albeit it's not threshold or interval based as your draft says shoul= d be possible. RFC 6470 also doesn't support Pub/Sub, pre-dates YANG, and is tied t= o transport. See first backup slide of deck from yesterday. But this draft isn't the YANG module that a "mount server" would advertise;= this draft presents the YANG module a "mount client" would advertise. I'm= not sure what the interoperability issue is that necessitates standardizin= g this. Adding to what Alex says above... Some aspects can be delivered wi= th just a "mount client". And these alone are valuable. For "periodic" a= nd "on-change" binding types, enhancements for the "mount server" are valid= . Looking again to DDS, proof points on what functions will be interestin= g can be gleaned from the "Data-Centric Publish-Subscribe "writer" as descr= ibed in Section 7 of the OMG standard= . Lastly, after importance of problem, I wonder about the effectiveness of th= e solution. I while I can go along with applications/controllers "mounti= ng" subtrees internally, I don't perceive a general desire or need to prese= nt said mounts or even mount/unmount RPCs via a northbound interface, as do= ing so just means the application/controller is a pass-thru to a higher-lev= el system and not doing anything meaningful itself. Beyond the industry points above, there is one other item. If an de= vice has access to an object, it might create a new object or validate with= another (more abstracted?) one. Anything else could then use this new inf= o. Therefore please don't consider Peer Mount just pass-through, but inst= ead as a platform for local application can build their value-add. Thanks, Eric Thanks, Kent From: "Alexander Clemm (alex)" > Date: Tuesday, October 7, 2014 at 2:51 PM To: "netmod@ietf.org" > Subject: [netmod] New revision of YANG mount draft Hi, we just wanted to let you know that we have just posted a new revision of d= raft-clemm-netmod-mount: http://datatracker.ietf.org/doc/draft-clemm-netmod-mount/ This document updates an earlier revision that we had posted about a year a= go. It also addresses requirements and use cases in http://datatracker.ietf.org/doc/draft-voit-ne= tmod-peer-mount-requirements/ Here is the abstract: This document introduces capabilities that allow YANG datastores to reference and incorporate information from remote datastores. This is accomplished by extending YANG with the ability to define mount points that act as references to data nodes in remote datastores, and by providing the necessary means to manage and administer those mount points. This facilitates the development of applications that need to access data that transcends individual network devices while improving network-wide object consistency. This document also lays the groundwork for optional extensions to support subscriptions to remote object updates and transparent caching of objects. These options will speed application performance without sacrificing data consistency. Kind regards --- Alex --_000_EF64FF31F4C4384DBCE5D513A791C2B120A43E39xmbalnx11ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Kent,

 

To your thoughts on “general desire or need to present said mounts”: 

 

(1) There are successful generalized distributed dat= astores

The Object Management Group has been standardizing<= /a> a Data Distribution Service (DDS)= .  Products in this space have a ~$100M current (and growing) market.  A = DDS vendor is considering contributing to the IETF peer mount requirements = draft.   They want to add YANG support to their existing DDS prod= ucts for support multi-device abstractions.  (Look for them to chime in on the Netmod list after their management gives a = 216;go-ahead’.)

 

(2) Some in Academia suggesting we overload IGP to a= chieve distributed policy/config convergence

A white paper which showing applications brutalizing= ISIS/OSPF to achieve a specific policy goal is here= .   The paper proposes injecting fake configuration info into exi= sting Network Elements  *in one place*.  Network consistency is a= chieved automatically via IGP convergence.  IMHO,  we should not be overloading routing protocols to accomplish configuration co= nvergence for new applications.  Instead with Mount objects and intent= s could be explicitly coordinated.

 

More in line with your thoughts...  =

 

From: netmod, = October 08, 2014 6:28 PM

Hi Kent,

 

yes, this is fundament= ally about the mount client.  However, the “mount client” = itself is part of a server to other clients.  This is why it has a dat= astore, which it presents to its clients.  “Client” is mer= ely a role; it is not the top of the “food chain”, you may have ca= scading relationships between systems where a system is client to one syste= m and server to another.  For these reasons, this is not merely a matt= er of how you build an application and about “consuming” data from remote system, but about at the same time making it accessible t= o other systems.  This is why we believe it matters and affects intero= perability, hence is relevant for standardization. 

 

Mountpoint management = is generally not intended for clients of the datastore which includes the r= emote information.  It is intended for purposes of system management a= nd administration.  In general, the mount structures will be automatically populated and bootstrapped as part of mou= ntpoint implementation and the underlying implementation infrastructure.&nb= sp; They are not of concern for general applications.  However, for a = complete system, it is important that these aspects are addressed, which is why they are included in the specification= . 

 

Regarding config chang= e events, I agree those are important and can address some cases (basically= when only config data is involved), but somewhat limited if we want also a= ddress operational data represented in YANG datastores.  Changes/updates to such data are not subjected t= o configuration change events.  To synchronize and receive updates, ap= plications today would need to retrieve this information on demand and, for= many applications, resort to polling.  There are many issues with polling known from SNMP, including lack of efficiency= , lack of robustness, difficulty to synchronize polling intervals, etc.&nbs= p; This is why we believe that the ability to support subscriptions to data= updates are important – not just for more efficient implementations of mount caching, but also beyond that once= YANG-defined data is to be used for assurance and not just fulfillment-rel= ated applications. 

 

Thanks

--- Alex

 

From: Kent Wat= sen [mailto:kwatsen@juniper.net]
Sent: Wednesday, October 08, 2014 3:08 PM
To: Alexander Clemm (alex); netmo= d@ietf.org
Subject: Re: [netmod] New revision of YANG mount draft

 

&n= bsp;

Per my = action from today's virtual meeting regarding this draft, my fundamental qu= estion regards the importance of IETF standardizing this model.<= /span>

&n= bsp;

Please = understand that I'm fully aware of and familiar with OpenDaylight's impleme= ntation of this draft.   I think that the desire for an application/co= ntroller to stay in sync with device's via pub/sub with async notification is important.   Of course, RFC6470's = netconf-config-change event provides this, albeit it's not threshold or int= erval based as your draft says should be possible. <= /p>

 

<Eric> RFC 6470 also doesn’t support Pub= /Sub, pre-dates YANG, and is tied to transport.  See first backup slid= e of deck from yesterday.

&n= bsp;

But thi= s draft isn't the YANG module that a "mount server" would adverti= se; this draft presents the YANG module a "mount client" would ad= vertise.  I'm not sure what the interoperability issue is that necessitates standardizing this.

 

<Eric> Adding to what Alex says above…&n= bsp;  Some aspects can be delivered with just a “mount client= 221;.  And these alone are valuable.   For “periodic&#= 8221; and “on-change” binding types, enhancements for the ̶= 0;mount server” are valid.   Looking again to DDS, proof points on what functions will be interesting can be gleaned = from the “Data-Centric Publish-Subscribe “writer” as described in Section 7 of the OMG standard.=

&n= bsp;

Lastly,= after importance of problem, I wonder about the effectiveness of the solut= ion.   I  while I can go along with applications/controllers &quo= t;mounting" subtrees internally, I don't perceive a general desire or need to present said mounts or even mount/unmount RPCs v= ia a northbound interface, as doing so just means the application/controlle= r is a pass-thru to a higher-level system and not doing anything meaningful= itself.

 

<Eric> Beyond the industry points above, there= is one other item.  If an device has access to an object, it might cr= eate a new object or validate with another (more abstracted?) one.  An= ything else could then use this new info.   Therefore please don’t consider Peer Mount just pass-through, but instead as a= platform for local application can build their value-add.

 

Thanks,

Eric

&n= bsp;

Thanks,=

Kent

&n= bsp;

&n= bsp;

From: "Alexander Clemm (alex)" <alex@cisco.com>
Date: Tuesday, October 7, 2014 at 2:51 PM
To: "netmod@ietf.org&quo= t; <netmod@ietf.org>
Subject: [netmod] New revision of YANG mount draft=

&n= bsp;

Hi,

 =

we just wanted to let yo= u know that we have just posted a new revision of draft-clemm-netmod-mount:

http://datatracker.ietf.org/d= oc/draft-clemm-netmod-mount/    

This document updates an= earlier revision that we had posted about a year ago.  It also addres= ses

requirements and use cas= es in http://datatracker.ietf.org/doc/draft-voit-netmod-peer-mount-requirements/<= /a>

 =

Here is the abstract:

 =

This document introduces= capabilities that allow YANG datastores to

   reference a= nd incorporate information from remote datastores.  This

   is accompli= shed by extending YANG with the ability to define mount

   points that= act as references to data nodes in remote datastores, and

   by providin= g the necessary means to manage and administer those mount

   points.&nbs= p; This facilitates the development of applications that need

   to access d= ata that transcends individual network devices while

   improving n= etwork-wide object consistency.

 =

   This docume= nt also lays the groundwork for optional extensions to

   support sub= scriptions to remote object updates and transparent

   caching of = objects.  These options will speed application performance<= /span>

   without sac= rificing data consistency.

 =

Kind regards<= /span>

--- Alex

--_000_EF64FF31F4C4384DBCE5D513A791C2B120A43E39xmbalnx11ciscoc_-- From nobody Thu Oct 9 11:40:53 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB4141A01AE for ; Thu, 9 Oct 2014 11:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.286 X-Spam-Level: X-Spam-Status: No, score=-15.286 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iX3yDslqKYlV for ; Thu, 9 Oct 2014 11:40:50 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C65261A014E for ; Thu, 9 Oct 2014 11:40:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15092; q=dns/txt; s=iport; t=1412880049; x=1414089649; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=bmsLa6Lu49Jjul3RuKyPJkBdA6LZovohztmedRe9iSo=; b=GXG7EIJRZnem8S5YNfGk+kx4g5eIGKVcQEPjRUkA7+ZaHJNsOioIFh0T 2RTk2ewMwGC5PXfMETO3zH+cQNWm+dqOqYKwqFPl1EVUkbfB4RoihYqDz SBGVOmwqQGZbBtDBv5jgdwBUfOcXIODX5AMKRO6EyvRV7j3TWFBWSqFvN A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYFAIXWNlStJV2c/2dsb2JhbABfgkhGU1gEuwqOH4Fvh0sCgQkWAXuEAwEBAQQtXAIBCA4DAwECKAcyFAkIAgQBEhuIIw3DGgEXkDMYhEsFkXmEQocQgS48gwqNH4N+g2NsgUiBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,686,1406592000"; d="scan'208,217";a="361961061" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 09 Oct 2014 18:40:47 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s99Iekjh009270 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Oct 2014 18:40:46 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.49]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Thu, 9 Oct 2014 13:40:46 -0500 From: "Jan Medved (jmedved)" To: Kent Watsen , "Alexander Clemm (alex)" , "netmod@ietf.org" Thread-Topic: [netmod] New revision of YANG mount draft Thread-Index: AQHP40RfcXk3qRma8kec20irC7AonJwn+QKA Date: Thu, 9 Oct 2014 18:40:46 +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 x-originating-ip: [10.154.176.170] Content-Type: multipart/alternative; boundary="_000_D05C205587848jmedvedciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/QoCVPzCe9_fwIO2G60N1BbklJL8 Subject: Re: [netmod] New revision of YANG mount draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 09 Oct 2014 18:40:52 -0000 --_000_D05C205587848jmedvedciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kent, From: Kent Watsen > Date: Wednesday, October 8, 2014 at 3:08 PM To: "Alexander Clemm (alex)" >, "netm= od@ietf.org" > Subject: Re: [netmod] New revision of YANG mount draft Per my action from today's virtual meeting regarding this draft, my fundame= ntal question regards the importance of IETF standardizing this model. Please understand that I'm fully aware of and familiar with OpenDaylight's = implementation of this draft. I think that the desire for an application/= controller to stay in sync with device's via pub/sub with async notificatio= n is important. Of course, RFC6470's netconf-config-change event provides= this, albeit it's not threshold or interval based as your draft says shoul= d be possible. But this draft isn't the YANG module that a "mount server" would advertise;= this draft presents the YANG module a "mount client" would advertise. I'm= not sure what the interoperability issue is that necessitates standardizin= g this. Lastly, after importance of problem, I wonder about the effectiveness of th= e solution. I while I can go along with applications/controllers "mounti= ng" subtrees internally, I don't perceive a general desire or need to prese= nt said mounts or even mount/unmount RPCs via a northbound interface, as do= ing so just means the application/controller is a pass-thru to a higher-lev= el system and not doing anything meaningful itself. The client-to-server (i.e when a controller mounts a remote netconf device)= , at the very minimum, allows the controller to provide a multiplexing and= virtualization function for applications that wish to talk to modeled netw= ork elements, while allowing the application to work directly with device m= odels. An app only needs to connect to a single controller as opposed to ma= ny network elements. Moreover, an operator can define policies in the contr= oller that allow different access for different application to different po= rtions of a network element functionality. In effect, the controller becom= es a policy enforcement point. Today, Yang does not allow a controller application to work directly with d= evice yang models. A controller has to re-define device models into control= ler-specific models inside the controller and present the redefined models = to applications. We feel that controller implementations should stay a tran= sparent and model-independent plumbing between apps and network devices (ap= ps that wish to talk to network devices, that is; I think we all agree that= there is such a class of apps, in addition to apps that wish to access con= troller services only). Thanks, Kent Thanks, Jan From: "Alexander Clemm (alex)" > Date: Tuesday, October 7, 2014 at 2:51 PM To: "netmod@ietf.org" > Subject: [netmod] New revision of YANG mount draft Hi, we just wanted to let you know that we have just posted a new revision of d= raft-clemm-netmod-mount: http://datatracker.ietf.org/doc/draft-clemm-netmod-mount/ This document updates an earlier revision that we had posted about a year a= go. It also addresses requirements and use cases in http://datatracker.ietf.org/doc/draft-voit-ne= tmod-peer-mount-requirements/ Here is the abstract: This document introduces capabilities that allow YANG datastores to reference and incorporate information from remote datastores. This is accomplished by extending YANG with the ability to define mount points that act as references to data nodes in remote datastores, and by providing the necessary means to manage and administer those mount points. This facilitates the development of applications that need to access data that transcends individual network devices while improving network-wide object consistency. This document also lays the groundwork for optional extensions to support subscriptions to remote object updates and transparent caching of objects. These options will speed application performance without sacrificing data consistency. Kind regards --- Alex --_000_D05C205587848jmedvedciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Kent,


From: Kent Watsen <kwatsen@juniper.net>
Date: Wednesday, October 8, 2014 at= 3:08 PM
To: "Alexander Clemm (alex)&qu= ot; <alex@cisco.com>, "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] New revision = of YANG mount draft


Per my action from today's virtual meeting regarding this draft, my fu= ndamental question regards the importance of IETF standardizing this model.=

Please understand that I'm fully aware of and familiar with OpenDaylig= ht's implementation of this draft.   I think that the desire for an ap= plication/controller to stay in sync with device's via pub/sub with async n= otification is important.   Of course, RFC6470's netconf-config-change event provides this, albeit it's not thres= hold or interval based as your draft says should be possible. 

But this draft isn't the YANG module that a "mount server" w= ould advertise; this draft presents the YANG module a "mount client&qu= ot; would advertise.  I'm not sure what the interoperability issue is = that necessitates standardizing this.

Lastly, after importance of problem, I wonder about the effectiveness = of the solution.   I  while I can go along with applications/cont= rollers "mounting" subtrees internally, I don't perceive a genera= l desire or need to present said mounts or even mount/unmount RPCs via a northbound interface, as doing so just means the application/co= ntroller is a pass-thru to a higher-level system and not doing anything mea= ningful itself.

The client-to-server (i.e when a controller mounts a remote netconf de= vice), at the very minimum,  allows the controller to provid= e a multiplexing and virtualization function for applications that wish to = talk to modeled network elements, while allowing the application to work directly with device models. An app only needs to = connect to a single controller as opposed to many network elements. Moreove= r, an operator can define policies in the controller that allow different a= ccess for different application to different portions of a network element functionality. In effect,  = ;the controller becomes a policy enforcement point. 

Today, Yang does not allow a controller application to work directly w= ith device yang models. A controller has to re-define device models into co= ntroller-specific models inside the controller and present the redefined mo= dels to applications. We feel that controller implementations should stay a transparent and model-independent= plumbing between apps and network devices (apps that wish to talk to netwo= rk devices, that is; I think we all agree that there is such a class of app= s, in addition to apps that wish to access controller services only).


Thanks,
Kent

Thanks,
Jan



From: "Alexander Clemm (alex)&= quot; <alex@cisco.com>
Date: Tuesday, October 7, 2014 at 2= :51 PM
To: "netmod@ietf.org" <= netmod@ietf.org>
Subject: [netmod] New revision of Y= ANG mount draft

Hi,

 

we just wanted to let you know that we have just pos= ted a new revision of draft-clemm-netmod-mount:

http://datatracker.ietf.org/doc/draft-clemm-netmod-mount/=    

This document updates an earlier revision that we ha= d posted about a year ago.  It also addresses

requirements and use cases in http://datatracker.ietf.org/doc/draft-voit-netmod-peer-mount-requirements/<= /a>

 

Here is the abstract:

 

This document introduces capabilities that allow YAN= G datastores to

   reference and incorporate information f= rom remote datastores.  This

   is accomplished by extending YANG with = the ability to define mount

   points that act as references to data n= odes in remote datastores, and

   by providing the necessary means to man= age and administer those mount

   points.  This facilitates the deve= lopment of applications that need

   to access data that transcends individu= al network devices while

   improving network-wide object consisten= cy.

 

   This document also lays the groundwork = for optional extensions to

   support subscriptions to remote object = updates and transparent

   caching of objects.  These options= will speed application performance

   without sacrificing data consistency.

 

Kind regards

--- Alex

 --_000_D05C205587848jmedvedciscocom_-- From nobody Thu Oct 9 12:31:16 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 952421A0075 for ; Thu, 9 Oct 2014 12:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.286 X-Spam-Level: X-Spam-Status: No, score=-15.286 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yysrOPgeTFRx for ; Thu, 9 Oct 2014 12:31:12 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95A2D1A6FF7 for ; Thu, 9 Oct 2014 12:31:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=51619; q=dns/txt; s=iport; t=1412883072; x=1414092672; h=from:to:cc:subject:date:message-id:mime-version; bh=dF8/zRgvmeU+g3VrhKc6TMHajyDtbbn5Fo37YwxnQyo=; b=LE315ijTbpCqDl0/fsV8RdzFMMj9+uhLvOMMj0ZIZoO4xtKEyj9/vsuv uMGPBrmCYKqHq2RWqyO/5fdu05wYoW0YKpaLBFpS1oATEdxpagnyXA6su wWqtPsYDIQF9i/JOLlRt/psGlNz28vtHVyI0UdoSfM3aFHMrCj/GXA6Yj Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AksFAAXiNlStJA2M/2dsb2JhbABfgkhGU00MA8kogW2HTQKBCRYBe4QFAQQtTBIBKgMTAT8mAQQODYg2DcMXAReQEzGDNIEeBZF5hEKIPjyDCpEdg2OCNIECAQEB X-IronPort-AV: E=Sophos;i="5.04,686,1406592000"; d="scan'208,217";a="358904746" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-9.cisco.com with ESMTP; 09 Oct 2014 19:31:05 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s99JV5aq010316 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 9 Oct 2014 19:31:05 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.163]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Thu, 9 Oct 2014 14:31:04 -0500 From: "Alexander Clemm (alex)" To: "Clyde Wildes (cwildes)" Thread-Topic: Comments on syslog data model Thread-Index: Ac/j9qWzdk492fFYRg+Tb3MWb3sKbQ== Date: Thu, 9 Oct 2014 19:31:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.204.57] Content-Type: multipart/alternative; boundary="_000_DBC595ED2346914F9F81D17DD5C32B571C816175xmbrcdx05ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/61N7LKdJKR4TpiYKrFAk5x23kmQ Cc: "netmod@ietf.org" Subject: [netmod] Comments on syslog data 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, 09 Oct 2014 19:31:15 -0000 --_000_DBC595ED2346914F9F81D17DD5C32B571C816175xmbrcdx05ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Clyde, as mentioned on yesterday's call, I would suggest addressing RFC 5848 in YA= NG model (http://tools.ietf.org/html/draft-wildes-netmod-syslog-model-02). = This is the RFC for signed syslog messages. Since this is IETF standards = track and the YANG model is to be published by IETF as well, I think this n= eeds to be included. Since there are many applications that do not support syslog-sign, this can= be made feature-dependent. For this purpose, a feature "syslog-sign" can = be declared, and corresponding YANG items be marked with a statement "if-fe= ature syslog-sign". The incremental cost of implementation is thus zero wh= en signed syslog is not supported by an implementation. The RFC is here: http://tools.ietf.org/html/rfc5848 Please see specifically section 6.1, which defines a minimal set of paramet= ers that should be configurable. Here is a corresponding snippet that could be added to the model in fairly = straightforward manner. container syslog-sign { if-feature syslog-sign; presence "If present= , syslog-sign is activated for this receiver"; leaf certInitialRepeat { type uint16= ; } leaf certResendDelay { type uint16= ; } leaf certResendCount { type uint16= ; } leaf sigMaxDelay { type uint16= ; } leaf sigNumberResends { type uint16= ; } leaf sigResendDelay { type uint16= ; } leaf sigResendCount { type uint16= ; } Furthermore, to allow for configuration of sessions, you also need the foll= owing: choice signature-group { case 0 { = leaf single-signature-group { = type empty; = } } case 1 { = leaf pri-per-signature-group { = type empty; = } } case 2 { = list pri-range-signature-group { = key "sg-id"; = leaf sg-id { = type uint8; = } = leaf max-spri { = type uint8; = range "0 .. 192"; = } = } } case 3 { = leaf custom-signature-group-scheme { = type empty; = } } } leaf certificateBlock { config fals= e; description = "Certificate block that is in effect for this session"; type string= ; } leaf currentRebootSessionId= { config fals= e; type uint64= ; range "0 ..= 9999999999"; } leaf currentGlobalBlockCoun= ter { config fals= e; type uint64= ; range "0 ..= 9999999999"; } } In case you want to include monitoring, here is the following: container subscription-stats { if-feature syslog-stats; config false; leaf messages-sent { type uint32= ; } leaf messages-filtered { type uint32= ; } leaf certBlockResends { if-feature = syslog-sign; type uint32= ; } leaf sigBlocks { if-feature = syslog-sign; type uint32= ; } } Thanks --- Alex --_000_DBC595ED2346914F9F81D17DD5C32B571C816175xmbrcdx05ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Clyde,

 

as mentioned on yesterday’s call, I would sugg= est addressing RFC 5848 in YANG model (http://tools.ietf.org/html/draft-wil= des-netmod-syslog-model-02).  This is the RFC for signed syslog messag= es.  Since this is IETF standards track and the YANG model is to be published by IETF as well, I think this needs to be in= cluded. 

 

Since there are many applications that do not suppor= t syslog-sign, this can be made feature-dependent.  For this purpose, = a feature “syslog-sign” can be declared, and corresponding YANG= items be marked with a statement “if-feature syslog-sign”.&nbs= p; The incremental cost of implementation is thus zero when signed syslog is = not supported by an implementation. 

 

The RFC is here: http://tools.ietf.org/html/rfc5848

 

Please see specifically section 6.1, which defines a= minimal set of parameters that should be configurable. 

 

Here is a corresponding snippet that could be added = to the model in fairly straightforward manner.

 

        &nbs= p;            &= nbsp;          container syslo= g-sign {

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; if-feature syslog-sign;

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; presence

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     "If present, syslog-sign is activated for t= his receiver";

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; leaf certInitialRepeat {

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     type uint16;

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; }

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; leaf certResendDelay {

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     type uint16;

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; }

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; leaf certResendCount {

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     type uint16;

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; }

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; leaf sigMaxDelay {

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     type uint16;

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; }

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; leaf sigNumberResends {

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     type uint16;

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; }

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; leaf sigResendDelay {

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     type uint16;

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; }

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; leaf sigResendCount {

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     type uint16;

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; }

 

 

Furthermore, to allow for configuration of sessions,= you also need the following:

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; choice signature-group {

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     case 0 {

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        leaf single-signature-group= {

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            type e= mpty;

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        }

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     }

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     case 1 {

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        leaf pri-per-signature-grou= p {

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            type e= mpty;

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        }

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     }

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     case 2 {

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        list pri-range-signature-gr= oup {

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            key &q= uot;sg-id";

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            leaf s= g-id {

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;   type uint8;

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            }=

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            leaf m= ax-spri {

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;   type uint8;

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;   range "0 .. 192";

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            }=

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        }

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     }

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     case 3 {

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        leaf custom-signature-group= -scheme {

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            type e= mpty;

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        }

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     }

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; }

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; leaf certificateBlock {

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     config false;

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     description

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        "Certificate block tha= t is in effect for this session";

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     type string;

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; }

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; leaf currentRebootSessionId {

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     config false;

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     type uint64;

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     range "0 .. 9999999999";

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; }

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; leaf currentGlobalBlockCounter {

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     config false;

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     type uint64;

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     range "0 .. 9999999999";

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; }

        &nbs= p;            &= nbsp;          }

 

In case you want to include monitoring, here is the = following:

        &nbs= p;            &= nbsp;          container subsc= ription-stats {

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; if-feature syslog-stats;

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; config false;

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; leaf messages-sent {

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     type uint32;

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; }

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; leaf messages-filtered {

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     type uint32;

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; }

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; leaf certBlockResends {

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     if-feature syslog-sign;

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     type uint32;

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; }

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; leaf sigBlocks {

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     if-feature syslog-sign;

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     type uint32;

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; }

        &nbs= p;            &= nbsp;          }

 

Thanks

--- Alex

 

 

--_000_DBC595ED2346914F9F81D17DD5C32B571C816175xmbrcdx05ciscoc_-- From nobody Thu Oct 9 13:55:24 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC7D71A87E7 for ; Thu, 9 Oct 2014 13:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786, 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 6ZYuI_yIPWLw for ; Thu, 9 Oct 2014 13:55:22 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id A9E8A1A87F2 for ; Thu, 9 Oct 2014 13:55:21 -0700 (PDT) Received: from [192.168.1.121] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 00A5F28BA38E; Thu, 9 Oct 2014 16:55:20 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_A49AAD12-488D-42C6-8F5D-62E6354FCAD0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: <54368522.9070402@cisco.com> Date: Thu, 9 Oct 2014 16:55:19 -0400 Message-Id: <618473D4-D75D-4FA8-AFCB-405A4CBDC18A@lucidvision.com> References: <766247DF-0BFB-4AAA-9D37-95B6819A4978@lucidvision.com> <20141008170313.GB73652@elstar.local> <54368522.9070402@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/4Txbw9eKNSNF67N2fo4gwVnLM64 Cc: NETMOD Working Group Subject: Re: [netmod] netmod wg interim meeting minutes .2014-10-08-14.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, 09 Oct 2014 20:55:23 -0000 --Apple-Mail=_A49AAD12-488D-42C6-8F5D-62E6354FCAD0 Content-Type: multipart/alternative; boundary="Apple-Mail=_63ED5E69-EFB7-4313-9012-3AE3526998EE" --Apple-Mail=_63ED5E69-EFB7-4313-9012-3AE3526998EE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Oct 9, 2014:5:52 AM, at 5:52 AM, Benoit Claise = wrote: > Hi Tom, >=20 > I'm all in favor of new participation tools. > However, let's not forget = https://www.ietf.org/iesg/statement/interim-meetings.html > Detailed minutes, including a list of attendees, must be sent to > proceedings@ietf.org and the working group mail list within 10 days of > the event. > So IRC is fine, and should be used as a tool to create the meeting = minutes. > Using whoever was logged in IRC as attendee list is not appropriate = IMO. Why can't we just have everyone sign into IRC and post a message = when they join w their email address? I am very much trying to automate = the process as much as possible.=20 > Also, there were a couple of points mentioned during the meeting that = were not captured in IRC (so in the minutes). Does it mean it's the = speaker responsibility to make sure his point in the minutes? Kent was taking meeting minutes, so he must have missed the = issue. Volunteers - you get what you pay for! *) Seriously, the tool is = not the problem - it is just a means for recording the meeting and = conversations for those that also cannot connect into web ex for = whatever reason.=20 --Tom >=20 > Regards, Benoit >> Yes there were. These we just those that joined irc which is how we = recorded meeting minutes (thanks again Kent!). I asked everyone at the = start to join and provided easy instructions for how to join. This is = how we will continue to record meeting minutes and attendees going = forward as it automates and streamlines things. >>=20 >> Tom=20 >>=20 >>=20 >>=20 >>> On Oct 8, 2014, at 10:03 AM, Juergen Schoenwaelder = wrote: >>>=20 >>>> On Wed, Oct 08, 2014 at 09:38:28AM -0700, Thomas Nadeau wrote: >>>>=20 >>>> People present (lines said) >>>> --------------------------- >>>>=20 >>>> * kwatsen (69) >>>> * Thomas__ (30) >>>> * meetbot (11) >>>> * schoenw (7) >>>> * Benoit__ (6) >>>> * Clyde (2) >>> I think there were more people in the call. I heard Lada speaking up >>> for instance. >>>=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 >>=20 >=20 --Apple-Mail=_63ED5E69-EFB7-4313-9012-3AE3526998EE Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
On Oct 9, 2014:5:52 AM, at 5:52 AM, Benoit Claise <bclaise@cisco.com> wrote:

Hi Tom,

I'm all in favor of new participation tools.
However, let's not forget https://www.ietf.org/iesg/statement/interim-meetings.html
Detailed minutes, including a list of attendees, must be sent to
proceedings@ietf.org and the working group mail list within 10 days of
the event.
So IRC is fine, and should be used as a tool to create the meeting minutes.
Using whoever was logged in IRC as attendee list is not appropriate IMO.

Why can't we just have everyone sign into IRC and post a message when they join w their email address? I am very much trying to automate the process as much as possible. 

Also, there were a couple of points mentioned during the meeting that were not captured in IRC (so in the minutes). Does it mean it's the speaker responsibility to make sure his point in the minutes?

Kent was taking meeting minutes, so he must have missed the issue. Volunteers - you get what you pay for! *)  Seriously, the tool is not the problem - it is just a means for recording the meeting and conversations for those that also cannot connect into web ex for whatever reason. 

--Tom



Regards, Benoit
Yes there were. These we just those that joined irc which is how we recorded meeting minutes (thanks again Kent!). I asked everyone at the start to join and provided easy instructions for how to join. This is how we will continue to record meeting minutes and attendees going forward as it automates and streamlines things.

Tom 




On Oct 8, 2014, at 10:03 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:


On Wed, Oct 08, 2014 at 09:38:28AM -0700, Thomas Nadeau wrote:

People present (lines said)
---------------------------

* kwatsen (69)
* Thomas__ (30)
* meetbot (11)
* schoenw (7)
* Benoit__ (6)
* Clyde (2)

I think there were more people in the call. I heard Lada speaking up
for instance.

/js

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


--Apple-Mail=_63ED5E69-EFB7-4313-9012-3AE3526998EE-- --Apple-Mail=_A49AAD12-488D-42C6-8F5D-62E6354FCAD0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUNvY3AAoJEPcO+I7eiUJZSeEP/0CYDz+xxv9WFWjt5ZI0r5LZ xAm0s0sBD9SAwIrqP8Lt4aU/0pjeEs0MSu4IbEtykzVubUclXn8btM3xYXeChT6h j8mBi24LC0a0nhYOTt278Sa+/xStM9sKB0dgt49LkRscVyknDLu047OIOr0RSHde 6QhHI7gv8ni14GYzn67vMlLIxaxujSFbaRaUQkpYafyKLEFeM6L+hnvPc8KLOAMr Gr48R/fvPYAzghoCmju5ZtVvxPqprffPzxlQ297y01XM21T1ou+Zf+73w5iPPy9A 4jaSP4XSZzNmyrBPhlRBlGcltYOPUN6nmLyIqGebmX+zEXNF27vSg/CTB75LlLeD G6hZZZ6NpJdnpdlLXoFGS+XqcH0ZovQ9Wciv3pUv2dwCc5sSoEGk2/EGt089GAX6 py9IVo1QFTa/pIbcY9H2/jCxY3ekXwBXMKdjPhWhxTIQ2ju3DQfrPLCgMA6Fp4iA 5eahNxGJBsC38h4E9ie1bpFg8oGIS43jEHkzQyxZT54ZTi53HDPAvPGxUZ7NLl5J 2KWBCbjbo99F64dZQNnZQ+GbAU8qDvom4IjJMf+iKS3xZFYhtudAok7hgDSnwG/w /y2d3F1ZeBSocuk7D7WR1KjsW8fR8F+N64/wfqVe/g0+L1P88J6pfCb4BdgDgQln ECTNt2S8QIvjkAuTr0eS =B2DN -----END PGP SIGNATURE----- --Apple-Mail=_A49AAD12-488D-42C6-8F5D-62E6354FCAD0-- From nobody Thu Oct 9 13:55:50 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8EE91A8823 for ; Thu, 9 Oct 2014 13:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, 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 G8r23DQNychP for ; Thu, 9 Oct 2014 13:55:47 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 105991A87F2 for ; Thu, 9 Oct 2014 13:55:47 -0700 (PDT) Received: from [192.168.1.121] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 9FB9C28BA39F; Thu, 9 Oct 2014 16:55:46 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_F8C2B3C5-C523-4935-930F-F1417595808C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: Date: Thu, 9 Oct 2014 16:55:46 -0400 Message-Id: References: <766247DF-0BFB-4AAA-9D37-95B6819A4978@lucidvision.com> <20141008170313.GB73652@elstar.local> <759F3218-56D7-41F6-99A4-7A4531B3971D@lucidvision.com> To: Ladislav Lhotka X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/74a7jm3rWzrbKDFWFkawyZU36qo Cc: NETMOD Working Group Subject: Re: [netmod] netmod wg interim meeting minutes .2014-10-08-14.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, 09 Oct 2014 20:55:49 -0000 --Apple-Mail=_F8C2B3C5-C523-4935-930F-F1417595808C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Change is hard. On Oct 9, 2014:8:55 AM, at 8:55 AM, Ladislav Lhotka = wrote: > Hi, >=20 > I=92ve never been an IRC user, so I just wonder why we need to have a = new minute-taking tool. For the other thread of interim meetings, = etherpad seems to work fine. >=20 > Lada >=20 > On 09 Oct 2014, at 14:50, Thomas Nadeau = wrote: >=20 >> Ok cool. We need to take a roll call at the start of the meeting = then. A simple approach is to simply have everyone type a hello message = into irc to automate this.=20 >>=20 >> Tom=20 >>=20 >>=20 >>=20 >>=20 >>> On Oct 9, 2014, at 5:33 AM, JF Tremblay = wrote: >>>=20 >>> On Oct 8, 2014, at 1:18 PM, Thomas Nadeau = wrote: >>>=20 >>>>> On Oct 8, 2014, at 10:03 AM, Juergen Schoenwaelder = wrote: >>>>>=20 >>>>>> On Wed, Oct 08, 2014 at 09:38:28AM -0700, Thomas Nadeau wrote: >>>>>>=20 >>>>>> People present (lines said) >>>>>> --------------------------- >>>>>>=20 >>>>>> * kwatsen (69) >>>>>> * Thomas__ (30) >>>>>> * meetbot (11) >>>>>> * schoenw (7) >>>>>> * Benoit__ (6) >>>>>> * Clyde (2) >>>>>=20 >>>>> I think there were more people in the call. I heard Lada speaking = up >>>>> for instance. >>>>>=20 >>>>> /js >>>=20 >>>> Yes there were. These we just those that joined irc which is how we = recorded meeting minutes (thanks again Kent!). I asked everyone at the = start to join and provided easy instructions for how to join. This is = how we will continue to record meeting minutes and attendees going = forward as it automates and streamlines things. >>>>=20 >>>> Tom >>>=20 >>> Just a note, I was on the irc call and my handle isn=92t on the = list. Looks like the meetbot only records the name of those who spoke = (with their number of lines apparently). If this is the preferred way to = record, we could do a roll call on irc to make sure everyone speaks once = and is recorded (just an idea).=20 >>>=20 >>> I noted the following people on the webex (in the order they = appeared in Webex when I noted them):=20 >>> Tom Nadeau >>> Eric Voit >>> Alexander Clemm >>> Aseem Choudhary >>> Balazs Lengyel >>> Benoit Claise >>> Clyde Wildes >>> Dana Blair >>> David Reid >>> Dean B >>> Juerguen >>> Kent Watsen >>> Kiran Koushik Agrahara Sreenivasa >>> Lada Lhotka >>> Mahesh Jethanandani >>> Peter Van Horne >>> Jean-Francois Tremblay >>> Call-in User_[4,6-8] (there were 4 of them at that time) >>>=20 >>> JF >>> _______________________________________________ >>> 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 >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 >=20 --Apple-Mail=_F8C2B3C5-C523-4935-930F-F1417595808C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUNvZSAAoJEPcO+I7eiUJZ+VMQAI+hIjdmpORX5OSwDpZXpLrW /gLZgQ0nSzOhVBmpGFga+FZ1aNWw1fKVD5zPTwQ1w68FtSPIh0UpH3SKSomFoj+K MjEb28D4v3RQ1Nk52hytkuGHMzbiMU5WOPVZi+1RmEzdjtpVvsgLCPwshwolHyMZ vS2OGCtuTb4hbJzWJVY1WpSiiq6lcdFVUfsj55EV90qi3HoyRmcz0cdxKRLywcYt Bh3Bz88MPQ6XuO7LJWAWO8Ny/PFPyj1RqyKtZ0+KYCXhPj6QehS7jKE65DSbeQyB MbQW44Gcprihfx9ps1eT+CI+P8Mu5BZfD1jIv31jHiu2tTpNQcPw6IZIIWOcyu8f x5bdBDGGqmw42s38SRqeIzejw7OYNFDFl4FkKNKVZEzhOKtf3+u12wg8UTcNMIdC 4M2FAOjpvhCTrr/Uk9/K5/pcq0NnVRILhV5mkpa8OgKPJD5wazT1H1MdnM3NrmYj 4B20WMCH8fkJ3b9hyfg5j490rOhFzgloN7RY0pWKb9tX/Ug/tyUwoZVF5grCELIu ADUqVnynfkMmigWLFziBlRVigULnT7Sqt/1KmyBC1nRpDAsSLVb8xKHfBQNZvAZV H3e/mrYzHWOZTienI4xQ/5ttZeC4OQRiJjh7Be6NT3gxEeksyJ9Z0DiQE/ZXaTd8 JX7Rby65Y8zgO2y4K+Ha =vg+R -----END PGP SIGNATURE----- --Apple-Mail=_F8C2B3C5-C523-4935-930F-F1417595808C-- From nobody Thu Oct 9 14:59:37 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33B3D1A88F7 for ; Thu, 9 Oct 2014 14:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5XFURmM-Bik for ; Thu, 9 Oct 2014 14:59:33 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B4E81A8900 for ; Thu, 9 Oct 2014 14:59:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4373; q=dns/txt; s=iport; t=1412891973; x=1414101573; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=1h98Ldr40x0eUG6PlOABZtSD1DWQAQkkTAwnO1mB058=; b=glzKmcnYBiWpocVV/vdSHZS9qmV6p2TVptf1W04eNOBxJg1V3jMkq3nN Bo9qLCXTOoKoWuJyQXBoWi1jxBIWCX9EjX/xLe4xEz3ps3+zqrIND/H77 P1VL5fC/rP7usoDg9FYh1xrO3unI5tbkWFRC7kGs8kBdClPNvqHYNP4Dd g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAAIEN1StJA2I/2dsb2JhbABggw5TWATLF4dLAoEIFgF7hAMBAQEEOk8CAQgOAwMBAh8QMh0IAgQBEhuIIw3DAwEXkEuESwWReYRChxCBLjyDCo0fg36DY2yBSIECAQEB X-IronPort-AV: E=Sophos;i="5.04,687,1406592000"; d="scan'208";a="85585378" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-7.cisco.com with ESMTP; 09 Oct 2014 21:59:32 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s99LxWnE016094 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Oct 2014 21:59:32 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.49]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Thu, 9 Oct 2014 16:59:31 -0500 From: "Jan Medved (jmedved)" To: Kent Watsen , "Alexander Clemm (alex)" , "netmod@ietf.org" Thread-Topic: [netmod] New revision of YANG mount draft Thread-Index: AQHP40RfcXk3qRma8kec20irC7AonJwoMIcA Date: Thu, 9 Oct 2014 21:59:31 +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 x-originating-ip: [10.154.176.170] Content-Type: text/plain; charset="us-ascii" Content-ID: <84B32A301B875548B7A2838687E8E7F2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/a0AaThaVX_ZvemsKtPWnXtEXwck Subject: Re: [netmod] New revision of YANG mount draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 09 Oct 2014 21:59:35 -0000 Responding once again, hopefully with better formatted text. From: Kent Watsen Date: Wednesday, October 8, 2014 at 3:08 PM To: "Alexander Clemm (alex)" , "netmod@ietf.org" Subject: Re: [netmod] New revision of YANG mount draft > >Per my action from today's virtual meeting regarding this draft, my >fundamental question regards the importance of IETF standardizing this >model. > >Please understand that I'm fully aware of and familiar with >OpenDaylight's implementation of this draft. I think that the desire >for an application/controller to stay in sync with device's via pub/sub >with async notification is important. Of course, RFC6470's >netconf-config-change event provides this, albeit it's not threshold or >interval based as your draft says should be possible. > >But this draft isn't the YANG module that a "mount server" would >advertise; this draft presents the YANG module a "mount client" would >advertise. I'm not sure what the interoperability issue is that >necessitates standardizing this. > >Lastly, after importance of problem, I wonder about the effectiveness of >the solution. I while I can go along with applications/controllers >"mounting" subtrees internally, I don't perceive a general desire or need >to present said mounts or even mount/unmount RPCs via a northbound >interface, as doing so just means the application/controller is a >pass-thru to a higher-level system and not doing anything meaningful >itself. The client-to-server mount (i.e when a controller mounts a remote netconf device), at the very minimum, allows the controller to provide a multiplexing / virtualization function for applications that wish to talk to modeled network elements, while allowing the applications to work directly with device models. An app only needs to connect to a single controller as opposed to many network elements. Moreover, an operator can define policies in the controller that allow different access for different applications to different portions of a network element's functionality. In effect, the controller becomes a policy enforcement point. Today, Yang does not allow a controller application to work directly with device yang models. A controller has to re-define device models into controller-specific models inside the controller and present the redefined models to applications. We feel that controller implementations should provide a transparent and model-independent plumbing between apps and network devices (apps that wish to talk to network devices, that is; I think we all agree that there is such a class of apps, in addition to apps that wish to access controller services only). > >Thanks, >Kent Thanks, Jan > > >From: "Alexander Clemm (alex)" >Date: Tuesday, October 7, 2014 at 2:51 PM >To: "netmod@ietf.org" >Subject: [netmod] New revision of YANG mount draft > > >Hi,=20 >=20 >we just wanted to let you know that we have just posted a new revision of >draft-clemm-netmod-mount: > >http://datatracker.ietf.org/doc/draft-clemm-netmod-mount/ >This document updates an earlier revision that we had posted about a year >ago. It also addresses > >requirements and use cases in >http://datatracker.ietf.org/doc/draft-voit-netmod-peer-mount-requirements/ >=20 >/> >=20 >Here is the abstract: >=20 >This document introduces capabilities that allow YANG datastores to > reference and incorporate information from remote datastores. This > is accomplished by extending YANG with the ability to define mount > points that act as references to data nodes in remote datastores, and > by providing the necessary means to manage and administer those mount > points. This facilitates the development of applications that need > to access data that transcends individual network devices while > improving network-wide object consistency. >=20 > This document also lays the groundwork for optional extensions to > support subscriptions to remote object updates and transparent > caching of objects. These options will speed application performance > without sacrificing data consistency. >=20 >Kind regards >--- Alex From nobody Thu Oct 9 18:16:29 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFDA61AD04E for ; Thu, 9 Oct 2014 18:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-ynG5Ap6z8Y for ; Thu, 9 Oct 2014 18:16:23 -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 BD9541AD041 for ; Thu, 9 Oct 2014 18:16:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2342; q=dns/txt; s=iport; t=1412903783; x=1414113383; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=mLqF0ckdodt4PgztP3lFsNumA42v5TDcWso1s07SmpM=; b=T2hRKMwXs8Uarc61ksLVbZBexr89gtWOXfuF4J5V4ZZa11ekOLSRSBcW SJM/VzsWB2689j1cDk4UA8uInWyUPZ5JCyl2eSwr6+RdcgVe1ALuuaSvs gQWIwuNNw4Z9r54Bm5nwHjYkan0QnnWqG9XaL2bSR4CBweVmVZT7KUy/T U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFADAyN1StJA2D/2dsb2JhbABggw5TWATLDAyGd1QCgQkWAXuEBAEBAwEBAQEaUQsQAgEIOwsnCyUCBA4FiDYIDcMYAReQETMHgy2BHgWReYRChxCBLjyDCpEdgWg4gUNsgUiBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,689,1406592000"; d="scan'208";a="85620780" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-6.cisco.com with ESMTP; 10 Oct 2014 01:16:23 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s9A1GNwD008286 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 Oct 2014 01:16:23 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.175]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Thu, 9 Oct 2014 20:16:22 -0500 From: "Acee Lindem (acee)" To: "Thomas D. Nadeau" Thread-Topic: [netmod] Call for consensus to Accept ACL Model draft-bogdanovic-netmod-acl-model-02 as a WG draft Thread-Index: AQHP4wqZOFU3Ld8VA0GsywXxS1v2spwo3UyA Date: Fri, 10 Oct 2014 01:16:21 +0000 Message-ID: <2267A2CF-2103-47A9-99C8-E613017E252A@cisco.com> References: <3E03501B-CA0B-433D-A18F-F77DD223EBE7@lucidvision.com> In-Reply-To: <3E03501B-CA0B-433D-A18F-F77DD223EBE7@lucidvision.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.197] Content-Type: text/plain; charset="Windows-1252" Content-ID: <9D7D85E154222E4AA4BE8D20014CF704@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ADVKumheOj7eC6TijP1EUdCTjpE Cc: NETMOD Working Group Subject: Re: [netmod] Call for consensus to Accept ACL Model draft-bogdanovic-netmod-acl-model-02 as a WG draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 10 Oct 2014 01:16:26 -0000 Authors,=20 I have reviewed the document and have two rather fundamental comments that = preclude me from supporting WG adoption.=20 1. I think you should change the rule-name (type string) to a sequence-= number (type uint16 or int32). While using a string is ostensibly more flex= ible, network administrators have been using sequence numbers for over 30 y= ears now and will be throughly disappointed when they discover that ACE =93= 10=94 lexicographically precedes ACE =932=94. This comment has broader sig= nificance than just access lists since this model, if adopted and standardi= zed, will set a precedent for future models.=20 2. Please remove section 5 from the draft. This draft should not mix pa= cket filtering and route filtering. Though we may get to this hierarchy, I = believe that prefix-lists have much greater affinity with other routing pol= icies than access-lists. Note that there is a separate route-filtering mod= el in https://datatracker.ietf.org/doc/draft-zhdankin-netmod-bgp-cfg/. Fina= lly, the RTGWG is now chartered for YANG models that are not specific to ot= her Routing area working groups. The discussion of route filters belongs th= ere or in IDR (since BGP has the most rigorous routing policy requirements)= .=20 Also, a comparably minor comment, leaf-list targets requires a better defin= ition. It really isn=92t very useful without some guidance as to how an imp= lementation=92s targets should be represented.=20 Thanks, Acee=20 =20 On Oct 8, 2014, at 11:14 AM, Thomas D. Nadeau wro= te: >=20 > The co-authors of draft-bogdanovic-netmod-acl-model-02 have asked the NE= TMOD chairs to post a call to adopt the draft as a WG document.=20 >=20 > The draft can be found here: >=20 > http://tools.ietf.org/html/draft-bogdanovic-netmod-acl-model-02 >=20 > The model itself has been extracted and can be directly accessed here us= ing git: >=20 > https://github.com/YangModels/yang/blob/master/experimental/ietf/ACL-MOD= EL/ >=20 > Please comment by the close of business on Monday, October 13, 2014. >=20 >=20 > --Tom (As NETMOD co-chair) >=20 >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Oct 10 04:22:52 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C62811A8A69 for ; Fri, 10 Oct 2014 04:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 8qLH_hLmQhyG for ; Fri, 10 Oct 2014 04:22:25 -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 D326D1A8A60 for ; Fri, 10 Oct 2014 04:22:24 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKK29926; Fri, 10 Oct 2014 11:22:23 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 10 Oct 2014 12:22:22 +0100 Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.104]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Fri, 10 Oct 2014 19:22:14 +0800 From: Yangang To: "dblair@cisco.com" , "yihuan@cisco.com" , "kkoushik@brocade.com" , "Dean Bogdanovic" , Benoit Claise Thread-Topic: Some comments about ACL YANG model. Thread-Index: Ac/kfG/69WbYy6R4S1u5RcAcGjY6pw== Date: Fri, 10 Oct 2014 11:22:13 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.72.210] Content-Type: multipart/alternative; boundary="_000_D496C972D1A13540A730720631EC73413A418DD1nkgeml507mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/X7-G0UXCox0gRmocZ_u3veeE-oY Cc: Zhengguangying , "netmod@ietf.org" , Lizhenbin Subject: [netmod] Some comments about ACL 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: Fri, 10 Oct 2014 11:22:34 -0000 --_000_D496C972D1A13540A730720631EC73413A418DD1nkgeml507mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I am reviewing the ACL YANG model. And I got some doubts, maybe somebody ca= n help me to understand it. 1. There is one field: targets. In my understanding, maybe it is used = to record who reference this ACL. I don't know if Is it mandatory or not. O= r my understanding is wrong. 2. In packet-fields module, It looks the current definition is not so = sufficient. For example, no "!=3D" definition, and no mask in acl-ipv4-head= er-fields group, etc..... 3. In this draft, there is acl-type and ace-type. It looks the IP pack= et match and Ethernet packet match can be configured together. But it looks= only "OR" relationship is at there, no "AND" relationship. Thanks Yangang --_000_D496C972D1A13540A730720631EC73413A418DD1nkgeml507mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, =

 

I am= reviewing the ACL YANG model. And I got some doubts, maybe somebody can he= lp me to understand it.

 

1.      There is one field: targets. In my understanding, maybe it is used to r= ecord who reference this ACL. I don’t know if Is it mandatory or not.= Or my understanding is wrong.

 

2.      In packet-fields module, It looks the current definition is not so suff= icient. For example, no "!=3D" definition, and no mask in acl-ipv= 4-header-fields group, etc.....

 

3.      In this draft, there is acl-type and ace-type. It looks the IP packet m= atch and Ethernet packet match can be configured together. But it looks onl= y "OR" relationship is at there, no "AND" relationship.

 

Than= ks

Yang= ang

--_000_D496C972D1A13540A730720631EC73413A418DD1nkgeml507mbschi_-- From nobody Fri Oct 10 06:17:45 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 323B91ACDF2 for ; Fri, 10 Oct 2014 06:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.285 X-Spam-Level: X-Spam-Status: No, score=-15.285 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0bKkCk39hTh for ; Fri, 10 Oct 2014 06:17:36 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60C9D1ACDCF for ; Fri, 10 Oct 2014 06:17:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=208250; q=dns/txt; s=iport; t=1412947056; x=1414156656; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ZvXHw7qqVOjB+xh0+r6IkS9oiYNTK2nreZ4CswjfmEs=; b=fBDzehOhY6uxZqB0vzLmQ83tPjUvWgoROTiU0chds8pKaJ/rQ4jKiVn1 WBtM4jqriYNFHQQHQwaZ/k0foXpoIawKnViKuFlUkIv47OpCKaC6XPiUJ sww7ZZl8b1LJ4dlhJzayMAC9JHQTRp8HXFi+JKHgH1grUImShf9KG+ybX E=; X-Files: image001.png : 131224 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFABrcN1StJV2R/2dsb2JhbABggkhGU1gEuzmOK4Fvh0sCgQgWAXuEAwEBAQICBSAIAUsQAgEIEQMBAgYBAQECFgEGBwIFEAEODBQJCAIEAQ0EAQYCAQUNiCMNwmEBAQEBAQEBAQEBAQEBAQEBAQEBAQEXj2IRAR8NExEGAQICBYMkgR4Fj1+CGoNbAWaIPjyDCo0fg36Dd2wBgQ45gQIBAQE X-IronPort-AV: E=Sophos;i="5.04,692,1406592000"; d="png'150?scan'150,208,217,150";a="359125308" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-9.cisco.com with ESMTP; 10 Oct 2014 13:17:34 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s9ADHYCJ001394 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 Oct 2014 13:17:34 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.41]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Fri, 10 Oct 2014 08:17:34 -0500 From: "Eric Voit (evoit)" To: Andy Bierman , Kent Watsen Thread-Topic: [netmod] New revision of YANG mount draft Thread-Index: AQHP40bcXWBBH+aajkuz6A/yEBcVLJwpQYrA Date: Fri, 10 Oct 2014 13:17:33 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.116.134.135] Content-Type: multipart/related; boundary="_004_EF64FF31F4C4384DBCE5D513A791C2B120A4451Axmbalnx11ciscoc_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/4c_UXF2e8beZw0kkumOv8WHPpIE Cc: "netmod@ietf.org" Subject: Re: [netmod] New revision of YANG mount draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 10 Oct 2014 13:17:41 -0000 --_004_EF64FF31F4C4384DBCE5D513A791C2B120A4451Axmbalnx11ciscoc_ Content-Type: multipart/alternative; boundary="_000_EF64FF31F4C4384DBCE5D513A791C2B120A4451Axmbalnx11ciscoc_" --_000_EF64FF31F4C4384DBCE5D513A791C2B120A4451Axmbalnx11ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Andy Bierman, October 08, 2014 6:26 PM On Wed, Oct 8, 2014 at 3:08 PM, Kent Watsen > wrote: Per my action from today's virtual meeting regarding this draft, my fundame= ntal question regards the importance of IETF standardizing this model. Please understand that I'm fully aware of and familiar with OpenDaylight's = implementation of this draft. I think that the desire for an application/= controller to stay in sync with device's via pub/sub with async notificatio= n is important. Of course, RFC6470's netconf-config-change event provides= this, albeit it's not threshold or interval based as your draft says shoul= d be possible. But this draft isn't the YANG module that a "mount server" would advertise;= this draft presents the YANG module a "mount client" would advertise. I'm= not sure what the interoperability issue is that necessitates standardizin= g this. Lastly, after importance of problem, I wonder about the effectiveness of th= e solution. I while I can go along with applications/controllers "mounti= ng" subtrees internally, I don't perceive a general desire or need to prese= nt said mounts or even mount/unmount RPCs via a northbound interface, as do= ing so just means the application/controller is a pass-thru to a higher-lev= el system and not doing anything meaningful itself. +1 This seems like a generic master-agent/sub-agent control module, but there = is no protocol specified to setup the system and keep it in synch. A good mental model for the intent of what Mount is trying to accom= plish is in the picture below: [cid:image001.png@01CFE463.33A80BA0] If your email doesn't render the picture, see slide 7 of: http://www.slideshare.net/SanderMertens1/vortex-introduction-public (Note: This is not my slide, but one from Prismtech which addresses how DDS= is relevant to IoT. ) Without models that span devices, YANG is applicable for the "local state" = view on the left. With models that span devices, YANG can facilitate the v= iew on the right. Getting to a Data-centric global dataspace requires: * Logic which identifies which objects are authoritative in a multi-= device system * Logic which can assemble multi-device abstractions * Flexibility to support ACID and BASE convergence No single protocol will fulfill all of those functions. That is why the OM= G standards body has defined the DDS specification to support the needed behavior. IMO network data models should just be YANG modules that describe multi-dev= ice behavior. Yes, exactly. The hard part is ensuring consistency of the multi-d= evice abstraction. The controller can use whatever southbound protocols it needs to implement = the network model on devices. Simply gathering remote device subtrees into a common co= ntainer does not seem very useful. As shown on slide 5, there are network elements already managing multi-device abstractio= ns. With OPNFV, distributed analytics, and container based logic, there will be more such abs= tractions. Peer Mount is a useful tool which is already shown value and be= ing used in traditional SDN controllers. The IETF defining a generic techn= ology which also can be used between network elements would be very valuabl= e. Thanks, Eric Thanks, Kent Andy From: "Alexander Clemm (alex)" > Date: Tuesday, October 7, 2014 at 2:51 PM To: "netmod@ietf.org" > Subject: [netmod] New revision of YANG mount draft Hi, we just wanted to let you know that we have just posted a new revision of d= raft-clemm-netmod-mount: http://datatracker.ietf.org/doc/draft-clemm-netmod-mount/ This document updates an earlier revision that we had posted about a year a= go. It also addresses requirements and use cases in http://datatracker.ietf.org/doc/draft-voit-ne= tmod-peer-mount-requirements/ Here is the abstract: This document introduces capabilities that allow YANG datastores to reference and incorporate information from remote datastores. This is accomplished by extending YANG with the ability to define mount points that act as references to data nodes in remote datastores, and by providing the necessary means to manage and administer those mount points. This facilitates the development of applications that need to access data that transcends individual network devices while improving network-wide object consistency. This document also lays the groundwork for optional extensions to support subscriptions to remote object updates and transparent caching of objects. These options will speed application performance without sacrificing data consistency. Kind regards --- Alex --_000_EF64FF31F4C4384DBCE5D513A791C2B120A4451Axmbalnx11ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From: Andy Bie= rman, October 08, 2014 6:26 PM

On Wed, Oct 8, 2014 at 3:08 PM, Kent Watsen <kwatsen@juniper.net> wrote:

 

Per my action from today's = virtual meeting regarding this draft, my fundamental question regards the i= mportance of IETF standardizing this model.

 

Please understand that I'm = fully aware of and familiar with OpenDaylight's implementation of this draf= t.   I think that the desire for an application/controller to stay in sync with device's via pub/sub with async notification is impor= tant.   Of course, RFC6470's netconf-config-change event provides this= , albeit it's not threshold or interval based as your draft says should be = possible. 

 

But this draft isn't the YA= NG module that a "mount server" would advertise; this draft prese= nts the YANG module a "mount client" would advertise.  I'm n= ot sure what the interoperability issue is that necessitates standardizing this.

 

Lastly, after importance of= problem, I wonder about the effectiveness of the solution.   I  = while I can go along with applications/controllers "mounting" sub= trees internally, I don't perceive a general desire or need to present said moun= ts or even mount/unmount RPCs via a northbound interface, as doing so just = means the application/controller is a pass-thru to a higher-level system an= d not doing anything meaningful itself.

 

 

+1

 

This seems like a generic master-agent/sub-agent con= trol module, but there is no protocol

specified to setup the system and keep it in synch.<= o:p>

 <= /p>

<Eric>  A good mental model = for the intent of what Mount is trying to accomplish is in the picture belo= w:

If your email doesn’t render the = picture, see slide 7 of:

http://www.slideshar= e.net/SanderMertens1/vortex-introduction-public

(Note: This is not my slide, but one fr= om Prismtech which addresses how DDS is relevant to IoT. )

 

Without models that span devices, YANG = is applicable for the “local state” view on the left.  Wit= h models that span devices, YANG can facilitate the view on the right. = ;  Getting to a Data-centric global dataspace requires:

·        Logic which identifies which ob= jects are authoritative in a multi-device system

·        Logic which can assemble multi-= device abstractions

·        Flexibility to support ACID and= BASE convergence

 

No single protocol will fulfill all of = those functions.  That is why the OMG standards body has defined the DDS specification to suppo= rt the needed behavior.

 <= /p>

IMO network data models should just be YANG modules = that describe multi-device behavior.

 

<Eric> Yes, exactly.   = The hard part is ensuring consistency of the multi-device abstraction.=

 <= /p>

The controller can use whatever southbound protocols= it needs to implement the network

model on devices.  Simply gathering remote devi= ce subtrees into a common container does not

seem very useful.

 

<Eric> As shown on slide 5, there are network elements already= managing multi-device abstractions.  With OPNFV, distributed analytics, and container based logic, there will be more su= ch abstractions.  Peer Mount is a useful tool which is already shown v= alue and being used in traditional SDN controllers.  The IETF defining= a generic technology which also can be used between network elements would be very valuable.

 

Thanks,

Eric

 

 

Thanks,

Kent

 

 

Andy

 

 

From: "Alexander Clemm (alex)" <= alex@cisco.com><= br> Date: Tuesday, October 7, 2014 at 2:51 PM
To: "netmo= d@ietf.org" <netmod@ietf.org>
Subject: [netmod] New revision of YANG mount draft=

 

Hi,

 

we just wanted to let you know that we= have just posted a new revision of draft-clemm-netmod-mount:

http://datatracker.ietf.o= rg/doc/draft-clemm-netmod-mount/    

This document updates an earlier revis= ion that we had posted about a year ago.  It also addresses

requirements and use cases in http://datatracker.ietf.org/doc/draft-voit-netmod-peer-mount-requirements/<= /a>

 

Here is the abstract:

 

This document introduces capabilities = that allow YANG datastores to

   reference and incorporate= information from remote datastores.  This

   is accomplished by extend= ing YANG with the ability to define mount

   points that act as refere= nces to data nodes in remote datastores, and

   by providing the necessar= y means to manage and administer those mount

   points.  This facili= tates the development of applications that need

   to access data that trans= cends individual network devices while

   improving network-wide ob= ject consistency.

 

   This document also lays t= he groundwork for optional extensions to

   support subscriptions to = remote object updates and transparent

   caching of objects. = These options will speed application performance

   without sacrificing data = consistency.

 

Kind regards

--- Alex

--_000_EF64FF31F4C4384DBCE5D513A791C2B120A4451Axmbalnx11ciscoc_-- --_004_EF64FF31F4C4384DBCE5D513A791C2B120A4451Axmbalnx11ciscoc_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=131224; creation-date="Fri, 10 Oct 2014 13:17:31 GMT"; modification-date="Fri, 10 Oct 2014 13:17:31 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAkgAAAFMCAIAAAC/BdRzAAAAAXNSR0IArs4c6QAA/8pJREFUeF7s XQWAHFXS7vH1jbsbcUJIQhI0BILDocfhx2GHw+EaDvhxdzs4/HB3CBYX4u5uu1nfHf+/r+p1z+wm QHbj0M2wGWmt9+qVf+VJJpOWu7kUcCngUsClgEuBPwoFvH+UB3Gfw6WASwGXAi4FXAqQAq5gc+eB SwGXAi4FXAr8oSjgCrYtGE44cX/dj6s//srviS24qnuoSwGXAi4FXAr8FgU8boytjhOEIkvlkygH npQQS+K9/Zv8nJAvHPsYR+GlKoUXp/HUkH6ehH7hce3pOo6Ne5hLAZcCf2oKuIKtrsP/64INEqm6 qKou2NJ/syUeb8JIMwpLeetN/7Gud+ke51LApYBLgT8dBVzBtiVD7theXlss6dnEkjMCzEtjrrpP kiaabZSJacbzVLPSkrYVuCV35x7rUsClgEuBPyUF3BhbHYcdcigur5QkMyItLX6mwuo3QnFG+EGq OSG5hKVSzd1cCrgUcCngUqBOFHDX0DqRzRZYEipTuy0hhhdiZuZleWCriSUn0gtWmseKyQt7SkzO vGiriTB0M0rqPhbukS4FXAq4FHAo4Aq2uk8GTe6AJBPxpi/1O9qbI71SP6gUi1EKyq/yGQfig8/D v7br0o2w1X1k3CNdCrgU+FNTwI2x1X341Y/o2FmUTrZr0ZZvTHqstgM+JeULijRv3PJqfqQItGqb K9fqPjDukS4FXAr8uSngWmx1H3/xLm6Uku/E1ZgPknAKAtRl6Rh2EGtqzjlSTYWiujXdzaWASwGX Ai4F6kwBV7DVlXS2ADOyzRFHNLVgqPHrWDzmtfCKeuIxyC2f5D6KweZnbVvC8iUtP77XOJxxRFbP qazr3bnHuRRwKeBS4E9LAdcVWdehN45Ipn54fEY/gIHm0eT+ZMLLxJG4SCuVW/5KiDuKMxOO80Gw 4Uc9Bi+gUevB2Ae2noeC0HVI1nV43ONcCrgU+PNSwBVsWzD2ybgtx2zDl5EzWmQQSPFE1Of1xeNJ j88PwVVpWWHLKoxbK9eXAe2laYPchkEry7KCSBphcA6FAyrQYM75gF3ixN624P7cQ10KuBRwKfBn pIAr2Oo+6gkrrimMIuDE6iIaViKeiEOkwf6ClxHyKiqv8bOWfvD1iOkLFzMh0pPwJuJtmjU9asi+ Qwfunp20MjzwSSKvRG4G0tHjjSbiQS9Enru5FHAp4FLApUDtKOAKttrRy9nbSXeEsQYnouJfQdQl EjH5gHRHP6w0CLZSy3roufcmzpxTmfRAYgX9vhhknw9mWzwZqeraovkN553TsX4gU+02DAjkGq04 N/xZx6FxD3Mp4FLgT04BV7DVcQKoYIOBBj+j+h5hcMFKgySLQZglkmMmTV+ydkNW/SajJk2du2hZ LJ4MBb3du3Tq3K6tP+hbsHLZxKnTqiJxfzzZNCNw51WXd2oQCND4q/L7/Mmkjyagu7kUcCngUsCl QO0p4Aq22tPMPoLJjLTVpDQtHkv6fVErUG5ZE+ave/LV/y0vLreCGfE4JF3Cl4i2a1Tv2rPP3K1Z ll9SSeCcXBe3Hnnpw/HTZgYCgY7NG9x75dl5lpVBsYgd/DFYfKZWu+536B7pUsClgEuBPyEFXH/X Fg865RuMN48nGYgkrUVrK/7vqReXFlUlvMFETKVauFHQd+ul/+zZLCs3aWUmo1nJSLYVb+6zbvrH MXt27lQVi89YvmbsovVF9Fv6qyx/BQ5Dt5tfvzVE8uTlbi4FXApsEQV+A8l18877+3WnNre6PLt5 FN0ae7kWWx2p6MTYfJrQGCfISJnfuu3Z176fvRQRsr8duM/QfQauWLfqkw8+HNJ3wDFD+yMB0krE 1MUYhaXn8cYT1pKS6Bn/fqAqkJ3hSWQHvDkh3x67dTnxkINa5zFn0ool/KglwOnjSR+KA0SUJT0o EUjgql4L6SXeVDs313lZx8F0D/tTUkCKRxXHXJomOj06tDsHlX7IItTt8A2A75S/DJc58kzzl51N YfY0qYwunTiiE/zA60gsnrVBcg65HAFmnfd/ylHYNg/tCrY60hVzMs4sD48PlhWYAokhXqvIY510 xU0bgnldOrR/5PwTQ3Ju7JmNWQz4LM55kYKo3U5QUHmSsRKP//z7/ztr7QaUtVlJ+iGDVjzHk/zX OWfu07U5DozHYn6/nwwmcTwBLKElqILN73BjiuXq+ETuYS4F/lwUEPnjuD3S1UKkgHk9ficrLF2t dGpLpdaUIm9jwaZkZCqYj+ePA6KBmmjch1ADUqWBjZ6SfoazbWH45xqBbfe0riuy7rTV4mvC+SPL 32tFPBZKsCntklb93FzkNWZYVsiKZzBVEtVstnYmmqDXyzSTpMePr7u2bZFVVdrIWzWgc6vWDbKh RBYnrcdefb0gkkQozudHVE4qu1WqUQ2koRaguZbWE8eofnV/HPdIlwJ/KgqQbSGcpC2HMlbcgsoo Hn6PH3Wo0EbjiTCMLh+USrJrijzisElr5eHAoKtn09kTKc6EHAqgnAdlqz5wLtg/DTdP0WLdbatT wDd8+PCtftI/wwkV6ZHgIlDuvN6EJxlhgZr105S5a4rDhQUFXTt3alQvG+IHcgl8gex+KXUjfhYP FGUvnkwkPJ6ly1e1b97kxkvPOrh/z0P2619UGZ23YlVlOJzjS/bs1C4RixKgBI4SdWJKOI//o3ZA fSD8pNzh+iL/DFPPfcatQAHBcQW/esi01DTpeNG2iNBS2WiDeivKc8BVPsVhMKBCAp7gCC8bLqga +4EzuT/OiZ/hcaS7xZuIsZCHJ9ElgGeXGzALguqt7rZ1KOAKtrrTUTGwfBAwLEBD+qOvyrKmLly3 bH0F0vh/HDO6uLKqU/sOIb83iOntQYYJtbO4JwF5hgAbZJQwj6d7hzYDe3TKTsSyxFnZtWv7978d GU8m8wO+wXv2yvTCKU8NEGYf2IOyzOiDaWxg4mwuY9R9NN0j/2QUYMEow9ciheJATJAwG4MLHvj6 Yz4vjDa6XxhngO0Gm01ejlQzGqpQzbHTiBlkx+3wllyPmlXwNXw2jKrLvrgIVgIPTsZri+MHMQjl apeFt840dGNsdacjjTBMRFRk+7wRyyq3vE998M1nP06KWhmRSCQzFOnSvP7BfXqccNB+DLYlAB+p PUYxhZM+dhyFnYUpT7El30YBWRL1ZxRZ1nHXPRBJeAZ1bnXzuSfl05+JDVMfySYUfam5r+9SOF6u Y7nuo+ke+WejgAmSCXwQBJt8pNufcs6yqiR2Vp60iktLK8oqY9G4J8D0L42oMVVM8rbkDVcBcjCy ukRYEVooaeUEQ40a5SFegPpUfISvJiD4sdp9WI+zr8jgeqr1x59tJLbB87qCrc5EhesiKu4GuBut So81fvHa6x9/oSruaeD3n37cUfv1261BgGE2XzKBkBgnM3EgHcVMpzJg/umRJBxyIh73+5Do/9W0 hXe//FEs6RnYrcMt/zgqL8n0yHg84vcjAYWMR2+mMJNum4x+1/mp3ANdCvxpKACLzM6EpDOFcAuK gQe0oI9HLvzo+59mL5ybtKIhIL7CK+Ol3DL9hImYZySczYhyBiPbYOn5fMmMaDzetWeHI4bsf3S/ rjmmR1U8JFKQIEMG3QGrA9RcV7BtzXnnCrY6UxOzM2rBb+7NgI6GfMgHXvno01+mI95214XnDezQ AGYWpJagPdpSTdzrtPLIESLYkiLY1IrzeJA7taYyeumtd62MhKLejJAnfsAePa8/bRgEG3IvE8lY wgPlT9JQqkWyXcTkOg+ie+CfmAJpySAapQYzA6l8cWHs5nsfnr+6qMpjderauWnj+vWCGbDOGEQw +YzqGjEOEuYzG6ONiShMHuO5PGWl0XUFG+YsnJmIRvp37Hb95Rc0y2WCdEgcj1Bm4bBJnUXrDdxt K1HAFWx1JiRNLfE7+Kt8VPH+ftO9a6PJNk0aP/cvYohA/MSTTBpG8A0YIumbeDBtwWZc9UwNxlez li37AVhcBeHxMxYWJ5LZvsRNZ5x0YO+2FGhWDE5PnAex7E3etOuer/NYugf+CSmgPhSNb8EdGU14 vF7f0mLr/H/ft6ag8Lj9B5963BFN8sm68JM4qqRmR8KqU7GIv9hDA99gUmFPkx2iyY+rS8Ivvf3B +z+NadOizTO3XtE8xMiChycQpVfMPpNs8iccg232yG7ySJ1Jq05ycIQHfgTgHb/z5fdlsUTndm0O 6dMNHkiJIiNn0oN6tVgCsWi42TUpSrmEAo3eDM1pRJCZUWlP/Xr5vbp2HrxH147d+4yY+EskHs+x 4nvtvhtd+WwawOwRCTirM58i0pFnrmCr81i6B/45KYAggMC7MnsRtTeIlD/y4hsT5y3420knXnrS kKYZnqCVQLlOENU1SSsYZ5MpOCvD5ZEP3/9g6uTp06dOnz191vRfps2bOatX5245fk8mdpNeVHiF PIQ6b5AR6N+354ZkaPzkydGSyIA+XRhyU9eNbaKRc03nxj/nOGz9p3aN3zrSFBwheMcEFMC8hE7X pH495FPNXbAQ1hsQI6kHIjSMrzB/fSzSTHjguETXGjG4JPefHn7mUIG/4sCc9CVj8L9DKMJf0ad1 Zk5uRsyXWLJ6mcSa4bNn2j/LPtPBtiQfS0Sdu7kUcCmw2RQQwHLIGD/zmn0oNYNiuai04rtx33dv 0+jvh/cDGyKjEYwJtwxcL4iAUwzBXei1srODPbp37b/nHnsN6Ne3b59Bg/fq1aNnZoYEGDRpkscy +cTv8cLhiMYdFxw7pFX93G9GjShRDBK11dJ8oSn8oM1+AnfH36CAK9jqPj00XsbqtSTdC/179czw +iuqos+89TFyQCror/fBZV+WxHt/uRWoIEQy3lDs4dcyywsRWIwdrECpFSoGSqTPjy9xLMoGRs1c VlJcEPQmWzRrChaBrUZWYTEc7DSBXXZ4Iz1UUPencY90KfAno4BJ0ofa6QcL49OcZSvDHmvfgX0g 1aCYxrwo4AmUWf6oxx/1+yICwlCFv16re+8eXbp17tyl425dO3fo1L57726w9sDsMZ8V9lo4Sdjn BZvjm6gsscgcOWBA//Jw1dQFy4V10xZeVyfdBvPOjbHVnajS7hqaXNTnCyCOtqrSuvjuJ5aXlCeT 0UF9epx65CHNGmYCyQCpwvFwsrSivDJaWRWNRCojVZWRiki0IhyuqIqFY9HSqhKUByTC8aqqSFm4 srSiEu1sKiorkSmSGQ/fftH5/Tu2hNLHZMh41IJymcKXc3K6jFu/7g/jHulS4M9GAQgzBAFgUon7 Jez3/mfk9CdfeP6mC886uF8fiCX1yuCvH9072EzYqdW2ogKXpQKKgkkKd1j3JlomeFTjcJCXmWjT IRlfX3w/+aH//vfqyy8+eveO2SwHd9AV4MjhJskjrqWxdWahK9jqTkfUWYtzUFtmB6os74QVFTc9 8Fg0EKysKs9Mxv1gB8bE/AkUbAcCeA+vo5d+fX4Lnz5qulGI7Qt4o7EwCkHhbEQNNsvjvIDaimXE w6ccMeyvBw5CViQraBgP0KZvquOlJVuyCkcZw91cCrgU2FwKENoYvIM0/qQXNtazP8588j//ufPi s/bu1/PKfz+yakNRJBYJBkNeOCrpWoRrMkbuRLw8mcRfcSfSiYLuVORGlGALIBDhGsTN4k96Qslk uyZN7r7+gs++n3T/C6/+6/KLjtuzY1Z1zGXiFzFcz8rtzb11d7/fpIBLx7pPEICZJlh0jTgaCl14 nj1aZj141T+71M/CxPUGM6LBnAiKtaHAZWTGAHhM/7sf/ODzxP2JWCBWmRkL5yai2ZGqZn5fp/o5 7fNDvZrUG9Shxb4dm544sM9D11xxCqSahKMF8CAJMFawkSIgpzsgJb+LFaZ1fxj3SJcCfz4KQJjE YLZJGgclkccK+fzeBAqprfJEoNKfEw5ll1rBEl/WBm9GqT+7IpBfGcwr8mRUZuQXezNL/Bllgawi TzCclV/qzyoP5mIffF/uyw0H88Ke7ApPqCDpi2RlwVEJeRfA9aJaxCauTlVQocwS8t+Valtz/rkW W92paTpZKMYc8fch5ZCy70HkbPyc1dMWL4GLwe8N5GVl+n2JzFAglJmbEQhmZvgzgoGMIP4Gs0JW 0Ee5hRlOvrLFlaYX43vCFkjqCJ0awgbgQ/mRuZEGBJlZKhSaLAPfXhqf7Tyx73iHxwmUKr+9/fY+ qUf6vfO4v/8hKEBMLQLdEWAcKmrY639l1Jwnnn3hlnPP3G/vHn+//bnlxWXegA9hAiIYk7OAKAJL Tcwy9TnKxtgANFwx45isLNCQrL4mzEgC0rJT0/qPXXnmNyPGPPLiO1deetHR/dojR0ycl2Rhpo38 7tT9QxB8ez6Ea7HVndqENmbqExzo9DLSr55kBXVewhqyW7MLDtnrwkP3On9Y39P26fa3QT2O6dvl iG7Nh3ZqOLhVfp8mWV3rBdtmWU18VgPsb1m5llVfIsz6QioKXgBD8Gt8G8n+dEJCyRPgOlt6MQZA /DqWdm4PqWaC7aSYSc10uDvtp7oTVE+iWmza69e/0kohfdnZaOm2LM9Wcx/t+ph+lWrXMxezz1n3 h3GP3NkpAIEG3iVGOdwgQIYkHCtYCQ2l6NiXTC1fDBLL72fVtaQt0riSFOX0Z0PaJL7HX4VTFrnH NzhIC7rxBUNx8LWgxFvQS8CtCrMgP9szfmcn2K50f65g26LRInQ3GUCbWQPmlEs+ZFsokcywYllW HBIrm5hYCYSLM5KWvpAJArklTW34gjYYiCf8CZTLJPQjmA2voOBQ0kkiNW7gDHYSMHVsKtycNVrc /dtrU7auxtxb69LC5HrmX/WrbqzebnQrNb747Vut1c5b60Hd8+wsFEgbfikzhVEm5W0SLQNbKT6I YfHa3LTKOSlXNYcRzkHAJdXdohwrArM253X33QwKbL/VcDNuZhfbBdNfAE+TYahhrIPxS96HMRHE negBWAjrqKWzqBRi8yUuffMSDRAiURuJQpLBBhMfI9OwYr4Aj0siCC1OCx/6BCDhRABV1TcJ1U9h lLeZqEkbFFxPX86/joxJ+6nuo1hdYtWcmtUvIU8sVKRENwlmNdcHntChdI3zVbfJ9NJpbSfr/hTu kbsaBQxsgggzsmN1g0xEk+sr3MUG1RVsdR8wNqNgqnA86AvAJxmL0F+RIDIycB1pa7FCU9rwYhFF paZAgesrtdHpAY89+rQRPxUH+GCfxWMJVGPjH4fLIN2QOUJXCGGXNzJn0px4dX+ezT7SEcxpIm6z D/7NHWs8hy1Gax5TTYBtnkw1enL1BaraJ3ft2jpjuAufhYmO7vaHoIA7kHUfRlhfiKvJK073o99D 0QMji3IKPXOZyi/qHkEe8Q51LXhpTqMT+ZH3HnwfQ8tDr1dw67zIOUEPG2RTwi2CfClxx/u8Pl+c Zp9tLol5sT3zINOlDu1FES/65SZftaVsurgyIs3x4Wwy6mZfwLl6Gm02EaWT3ejVTdsYU9GnqA7f sv3ScGpLJXf/bUEBtdI2abG55tq2IPi2Pqcr2LaMwog7I6kjjmxeBsLiHi+q2cq9gSWV8blry2Yv L5y8eO3UpevnrC6csmTt1BXrpy4vnLKMr6n2a8ry9VNXFExZvmbaqvVTV62fvGzNrHXF66JWpc9f aQWiniAEXCxC/yQzIVn9JjcszQwl6V8W6u1sbWyDkICeUqWOumc3079a23tJzXj7SId4tT3Vlk0d 9+idjgJqsUHIOTNhY7fkTnfT7g1tigJuuv8WzAtMf8B0J8pRm4YEq2gyhK5sP85a958P3luwdHm0 LJoVDMVjVcgBRgl2BMLP+CAlFp2G6h2LxUKhECBIYKyhHqCqKpyTk9Ojc5dTjzuqd7u8+pJOIjVs 6s/UHm6sg5GUTHbG8aD9zfYQbyp3tFFi6q1SEFUP8ps8Xe2JKucTfD0j2NJULjv0pb/WOH8NO8/c WPVoGe7H3o3nMIJT79q+V3sH+/5lcN3tj08BGWgIsAqP550Jix567NHrzjl1yL79/nHHc8tKKinY AGcnyWF2MkgtSIJeN6h27cJ0/zO+/n7s/S/974qLLzyhXydALmBzpq7JLnHnWy1I+zu7uoJtC2jJ 0BlryJDpC18i8kce+O+nH373U9hvdd6tS/tW7XJCqGBjEA7JJT7A0SFfn1n7ZumWfH4RFAA/QFSO CAaMtpWWlC1cvGjJosUAOjjnb8f/7ZCBeeyzi8xhX1RSTABKgqNicji8oHK6ALlkmzPGRoJNm9tv DcEmfM7zm/OlJ3nKVzUFWNq46U/2gakP1b5Pnb8a+KyNT+acP03sbXN6bsHccw/dWhRIE2zvTlz8 4KOPXPuPUw7cr/85dz6/tLjCFWxbi8zb+TyuYKsrwW2rBSs7GoSibc3z73/9+sdft2ne8t+XXNim aQChNbgKVYhhX7zRsmuqfvINfsVHEU5mH3yEyMJf/DRp3op7n3ulYMO6v590xGkHHwi8f28sjjCb 7AoBiRNoJ231UmorqG27wWoUCGYtNJBryeOlGUPVxFKqTU+6EFIcZ9lqBjYwGVkyi1AH+qoKjZyg WbVLVpNy8RhyR2mwOmdjbioCligYkk3sS3xFwxa7sXgJIjSeBACMuS/TZJKf9Ff7+21LT/fsO5wC Mi8IgIx5AnBIWGyPPPH4lWecOGzIwLPFYmPxGX5NEEALb2p7w67FVluKba393RjbFlBSq8vE0Jhd EH77i28aNm5w962X7dYkkJ9EzXUixwrjlW1Fs60kyq5ZviZ9ALRdE9wRKGXTimzUuuXE4tnJRD6a iyYT9SxrQOeWd950dSjof/XdD5aWV9CDZqBVhbvEUJJlX9f+7bGByeE1NVdysisMIsombsAJxTNo YYctFLXBEULpmdZ4DGlP5xWva3o9xG89nQ+JpzB3VV7iDhNEq43GY1iJ+I2pMBQETohjgpLBN8yG IqpNaHsRvUCai3J70NO9xs5Ggd/IE3GDbTvbYP32/biCra7jhVVQMLyxwQ/5wQ8/rausPP+UE1sE ifvG5A70kUdVG/HnWBYAgYB+NG9+9v2N9z1xy/1PDn/gqVseePy9L0aw24XtkZRGvkkvEAyScci/ Lnm+8/92Unkk+dn3Y8THr/YdVmQ/EVMJwErxQuweirq6PkhtjvP7gtowB0YqXjR9ImoG/dZmLCd7 lxoCz5FzUocuMA0odWD/8VQsL3V2J7wnV1XvLpy9NNG0l4/XR0PZR5rEoxqIhKhDwinPwZ522GTg CNYHAcrR4mE1H2E7aQu1ob6777ahQLp2la6EkavSsiW3zcXds24TCriCre5kpQcD9GM3QmvynLkZ +fn9e3eEQGJJNdPzA5YnKKhYiB/TbYjXPgcccM75F5x1zrl4nXveBfhIfxvwuGh3waqQ1AYPDuE6 jFPt3a+v15c1ZeZCGko4r+364zs5I96oWNxum96tli7QxQrT59dlqjGk7JurYas5Ak9XFok1WjE0 TRAHK6R2RDJSNn16ETwAWifwi6gYEPiKLYu/6JUQRS0gjDkVYvg+BnQkFZ38oiIib9kAdlPnd6Xa dptPO/RCNbziTlbkDr0p9+JbgQKuYKs7EenMgiUGQWRZ61ava9a4Sba0ndDomharOWYHlkrs1ijb ap7na1Uv0CLf3zjXXz+DkhEbdgPUN5rfwAzCmyjtD8beGmR4cnIbLl+1njsBso5+Nrs+W5yB21eq iadQRBqsTzRRrGGpCRx0aqvhvUmPgaX/lPL/JNgQxIOGxkK6osroyrUFSsaask2EKSQghbsmq8Fq Q4PWeHLSzJlT5s5FYYTXL6RlA2SRmn6fOiflQPiCvRNnzP5l+hzk4+j5RWvApnbx9jGA6z733CO3 BQVcwbYtqLpDzukKti0gu3ZHk0UwHA4HMzJLE9bUxcunL183edm6X5avmbJi/ZTlBb8sK0B12uRl q6YuXT1rRcGMpQXTlqybvqRg+rLCWSs2TFmybtpK7LNmyvK1rGNbvmbCsrWTlq2dsnTtrCVrccLs vPph9HeiwRYjLkkKQmoL7ryuh7KVoseaOWfBFTff9PH33zPipiG/tFJxxzXpGGRqqKXbZ+neSL0X ijoFNIJ8QkWgZd1+192Tp88QT6LKb3uuOpXpHi/8vTTaGF3jgRtKy77+7scRP45SazLGLFKCjiHw pgXlel2Yg8tWrR/x088jRo7W5JIamz7OrxuidSWfe9zOTQFnWuI2fyPetnM/hHt3pICbFVn3eYAM BT+z+K1SjzXo3Ouaduh04V+PffaJxyrivjg8YES/8scBS5KADRbzIXSGjD/2J0RUh442vMeCKyEl 3gNKAtSO8XnYs80bj4bikUuuuPKuF16LVxZ/9sB19dGqHhE1iDcH/1BMQx5S94eoxZHOQj9u9rzh Tz965WWXD2nXkaDo8PbRjiQiM0xWcZdWU5jSHZJoycgbRiJM9U3z0wCtkvR5IC4hmYb/372DBw06 dMi+CgktB4hYtwWbmFmxQNIfizJfNOazFq0tvuO+u08++eT99tydSTrq/4VUAygMAWKYkYJ+WDjH 4vUlt9/9f2f97fSBe/bQ9kB2/ZyYa4L46ZRl1IJG7q67HAWo7xBeodLr/WT6qrvvv++yU4877OB9 NN2fcw6zWaa+W8e2C42ta7HVcbDIDoC8sp2NkE+BQKjK8pfE/ZXB3AppObjBCpX5MtF+sCyQU+LP KQ/mlPgyK/w5RVaoyBPCx3J/dlUoj7sFcsqCORUZeVUZ9Yt9mSWejAp/dqU3EA2wjRs6QjGWB+5D o17jvDQ+SCc5Mc1k2vwnquHINF646senvtTAE+RSi1btfP7MObPnp7E6T4WAYtTyhi0vMmLwqhJ3 pQSxGP3CNxVJqyRqrSouLSivrII4SsK1Kt9bVnHMimB90ZbklrV8ffHytetycvOr3aJINWeTzBB/ lceavWzNqtIKnCfq88AbaQUy8V7jbdg/5vPhloqjCfylUBW5iOhdOIGmyZTLzCKR2+Ddwgr0eBX5 zN3+2BRQtUfd0LohYMvkLc3gBVg5NTUUjZifvQ7ctk2XaqivmySWwWFQV4Qstnbhp7jAyUBOfvMf m9rb+elcwVZHgmtSJOWKghLH4n7pLsgMCBR80SLzomGuj2+xTkpvG/YW9MeQGyH4jzFk9MlfmC8s uqJtgeRz5KmLOYdJL+kk8EAGcGZaLQgToRBbUiL5qi6Wat22hhBg5C7D2CrA8DFuwkxkZ3UExple iLdSPodMwqUrVlmxYNNGrcXABGtqxgatnOWl1qOvf3Lzg0+++92oN78dv7AYmNCMGqLOb9aKwk9G zbzhwWfufu6/tzz44HuffBLxeCD8CmPWLU/855wbb3v87Y+xmwYXywEAnZUdCIZQoMdeHyCNiBpx ErJTkL6fuXzNNfc+fdNjz1xx172LyyMRfyAeCM1bvPzz78ePGD0JLkeIvTWV1r+fevGfN93+3Nuf Q3RJswUQN5gI5s1avuq9nyeMGPcLpNqE+Wtf+eynVz765rWPv5owa4nmU8rAmeIEN+G7jqyyUx6G OWC7uDnSRKujLKNZT387vgNLsg8i2BXqFxzptOrB1AQxl0RnvMjvNqg5i92QfCt9afRrEYTOpLVF px3KFXe7XmmnJNAuflOuYKv7ADrGAyYnWUD+UhrYeBxkCicZodaJdpzvckL+X90t5miKNk/UJRxE DBPhUOEvB0FE2i86hhEFK64e8INJwbVsZi9+G7/l69alGy8rgUacKgpnTsJ65KnnJ8+Ye/Qxx8LY mjhl+o233T5l/tLSpLW6PPLlTyPf+eDjvffd/6ijj77hphvbd+wE3+OGquTdDz/l84f+dfX181es Hj93sY5Hbn69eNITykKBH+VcLBambKcMpmDSjll4vfjS6/seePCFV/zrLyeeOG3OvIKSMrQoz83O +uaLz9esWgHhtL7KuufRJzz+0CWXXz1n6Yqxs1fwli2rpKw0EAhkZmZ+/PHHK9asm7p4zRsff7G6 tGrvQw4aNPTgdz78qKA4wmvIprV3GnQxiZV1nzXukTslBdLURFuRERxYU3/pxWyU+zYcly6MHH7f 6MGkbSlZxpwl1ZjN2VXncV34d6ck405zU65g2wpDodNyl+t5QbxKZVApNohZ8MvhhYwM+YbpEwBd hskUgKEDb2G51yqR6FeLlgBWSfikMw8wGSxPQCxV78jRv6xcufL2m6/cs2PzYf173Hbl3w/cd6// vvH6kvXFo6bO+GXm9MOG7H3Mvj326da+ocfao2cvXGHy3AXzFy685uxTezYOJeOJCVOm6x3lZPiS kfj6dYVQayvjsYBfoFWoQMPIjLHWTwVeRdW4kSPmzpjYq2uX/n16JGN+OBmPGzrwqnPPPuO4o7Dv hNkLFq1Ze/HZp/RonhvxeUdPm2KyVRNVVrTib0P3uvXSy44/atiIn8ck/L7d+/f76JsRDzz2SDha lpXlh9h35FmN8qatMGncU+xoCphWnyJ4jAZDK0xaUWFis5hS9VVoNIzw8ic2U9QZKv3tEYuF4xrZ SXRimtPQoQ54WMxQ2nCaH02FUBwbOot5uPCYOid3NCH+iNd3BdtWGFUjHXbRboTGzU86SJYna5kh 22CfwZUX8XrLLGvktIX/+eCLL0aPu/G22yZOn1FUUhpJJOctWw6BB9xn+A8h9sC1VdFIXv283AyU kRk/T15eXnl5ZePG+QsWLqqsirRv317JDemo6YjzFiwcvM9+wYBVUmmtXLt29MTJiMPhVIsWrsvM zC6PRrGn1xcEMKYk6UuxtZfYZOIztS698vLzLjgnLz/nmSef2VBQsW7dusysrLXryjt3bIXdYZPO W7S47579Qz6ruNJavmLV+CnTcLc4/8rVq3KzMwoLq9q2bICz+v3+gg1Fjz/9zNSZs/566mk333x9 MMCAnCPPILZVed/l1JetML//iKdQ14NxozicixQvSCPj9db4tYliy0Jp7DRBME+5GfUHuiVVRFId dEhmQgbmJ/trOZGcwZZuf0Qa78hncgXbVqC+lv3uckueRAVgoZG7NFqgjtNkEo0IKLEKLWvc4rVv fj3u7ude/vyHMQsWLOy7e5+SDeVeX2bUnz161uI3R09/beT4N38cM27eIkigksrSwpLiN74YPbe4 annMeuH9bz7+4ptTjjm2oWUN6rM72P29L76GzVcKuVVYMmryLFysZfMmi5cv+3TC3P977r95jZtH YtbXP09FxKtR88aFpRWjJk/9fvr8T0aNLkLhtoJgsc8qbEqk7XhK49bC1atwn01ad2zRpt2CBQsy s0LrS4uWVZQXQ8pC4iatds2br1m9csQvc+575rmGTZqEq6Kf/DwOgb16+Q1KSsqXFRTjHmAMHnHg waWFRe3bdjhgv6GtWjWCwMY+9MGKPFMgsV1ufLfCzP5jn4LYPY6o4UrIISZeKd2HlF30EHh9CcIr mO6D1MYYA0f8zMQD4Lpgaq7EyHmIxOE8fthzeEm7RiROY+7iJ78cklpyGcEWIAIAqSep7LnRtq02 4XzDhw/faif7050I85S+sbKE9crHXzdu2apbxw7jJoyPegMsNUZQhr4zgfWl6KhRzfw7xIIrI5CI Dxo0aPTkqfHKsjMO2z+DXCgqpuRY2TE7k1Rlf7/5YyCxNd6VOCSlikyy9j1xj788aY2dteCuR57+ 7oeR2fn12ndot9+gfn874qDeXbt2adsSHPvR51+vWrNq+fIlU6f+sn716gljRu/Vr1//Xt379h/0 /ffffvvtF8uWrVi8cPG+ew04duggSKHmTRt06tRl/vyFYyZM//r7Ed9+/lm/Xl1bNW/euFmzxYsX f/L5F4FQ8G8nntSjY8fP3n8vL7dRZlbu8iWLV6xcOnbsqGYN6/Xp0SPk1BDgbllkYc1csPDhxx8b OXL8zyN+rJcVOvn4Q1s3qTd18vRvv/1m1OjxyxYvHbBHr+bNGi+aN//9Dz7Iy8v961+O69qp/Wef fphfv37/3btPnTj1uxHfjxo1cdG8xQftt0ezFm0WL5g/+kfUwf08asyE73/4fre2bfIyMxGKU5Em wCUwZ11dcPPn2E68p1HjbIaCYPFYiwvKvv/5pz27dem+W4cPf5pYGkYnKVvaUdwpLiohSdWHCM8k 0dpE7FE/TEB5g3OSeV8iweSvB7AMmUcM2n3RopWjJs/Ya6/+XVvWF8e6Bo11dTANF1PB7Z2YcrvE rbl1bFsyTAS5gmBbE7OGnXdN1/4Djjv4oMeferLcnxlDXRVnOUPHnP2SSZXmoPj9iwYT0axY+Ior rnjwpVfDBau/eeTmfHoKjftCKsaEt0QBrFM/J4FYpOBFSxwNs/H0cDwWJK3nXn7rl0kzgNXRu0un i849NR+5ImLZ4C8iYUjcXFVUifqGBjn+OQuWojStS4f28cqKvNwsnImap4TfgPaBYjJfgvmiUWF4 DThUhMPeeLhRVg7KqxPeQHncWruhpHGjPDwJLhGLJAvXF7Ro0QgMv6oYkOuJ5vm5wDlGPSBEWyLs 8QYhehMRK1pcVrl2fVEi4kcOSOtWDRXxGLpxRVVyyaKFnTq2zgyyTSu+3FBeEczKyhBMzfJIeP3a dR1btcL7orLI2rWrW7dqngVnqNzbrAXLUcVRUVVpxcJ9duuUHeD3sNjgq9QxqwES9vsD6e6xk1LA YIvCByBGWBJI/t/NX3nLHXedd/xRxx417Ow7n1lWWiWZzKYfG5UbtdhMZw2gwfI7mGY2J9IJCU5X MeXHCpCIo+9952b1HrvyrG++G3v/f/936cWXHNu/PQDQHf1IU5IkyRkJzzspsXa523LVz60wZKbu ZVeLscHnSP5Sb4wItipYn1Hrpf99MG7y9CH77nfhWWde+89T6/nZhSCDIXGWkaOPR8ATa1E/s0WO Pyth9e3Qpl+X9jleq0FOFjAu0b4AzQogo3I8iVxpYkD/CyoWPDEIOSwBaHHQMBRsnJXlSUT9yKGO x/N8VvtGeejLk88GCMmcoKdls/rYGa9medkt83MpHU3MLgGpRmx+ntnXGO1Y27Xr1aVVp9YNcYc4 M06CG6gf9PTp1jE7AGyuSNCbCFmJJjlZeAqcB7vV8/u7tWrFG0tYjXKCXTu0yQmiXDwWtGKZVmL3 jq16tWver2uHAT27ZfhMMyCVag5G81aYMe4pdgoKpIr9qYbxlvgHuovJD+E3TOIXI0x+tl2Xkkgi fKNY5Oz0K8eKIpv0CjZ3mpSS0JuGLOxAnWOdqX9SewW721aigCvYtoiQ0smJeITYUI7mpBhs0Um3 08EojoOokvxCiYWHBbD/qx/HjB87Ye/de110wtCDe7eDJIC4Qna9lu8AzRIgH0ie1HtUUY4/rKv2 sGKNn8GoCQA1QgTZdXBG5CcCrN9TvRRrCjPNfDBtk4QIgUCSejURtgxqcDEJSjqaeID0XzFPafsK UpbchlqB5gpcP8yCwcJaD5M8E7iGXFez4IIAo5QKJPwjN6PrlajtyFOR2Ahuhlgn1ZnDdUJup4m5 fS6jCSBJjDallQYKkMxI5FcPIWswx+Ba9GGOYCZizoBZWPGBthHkB3gYWeMCN2QMEsyP5CY0+IOL Ioyf4N5gO8AoUiVRghrD3uKrSAKlCDyUxCRPQQVpxqRp1OGaa1tv6F3BthVouSv2thARQNHCcAHy LKLI27A+GT3p42+/Pf6oYy4968QsLO5obRoXAUDBpfomxUBNknEZkB/Tna2yWsjiQTBHlRxiFmrh jvxiUFTs8zHUZ1ysyuOyk7PVVICdH+QJ7LRpcw1zoEo6Fbf2Lyr8oFOzCNvRxc2lnNClk1awFSaI e4qdjwLVZxPuT4pc2AQqInMQyHYo1RZVlU1ro7GYsjlR8djXLyr9apMZwRD20UBsOFrlC6KgMxaL R2Dl03STVzwZI8IODgI2g/CSU7umd6ElKO6M24qzxBVsW4GY6bj1uxR2KvBSkABJmRQIBDeEI6Om TgEAccdmreBOJF6KnwprBNImCbiruBo9MKbwUs8LK1hT4oLvUt9INr98BeWWu6dSvhhyJx4jRB2V WY1J4EVTj8aa9MNW4SeOG+F+yXXhgc5LTwh3oTgKNYvRTqrRfDZcOl3m2facgI/YIo/GHwN4RjKK MSmXcFPUtgJr7NynwHQinhosK3UbSqI+ANWkHSBEF/oixiCiAEuShOhKwl2BXQg5Gs+AeIpHgn4r GgZITjgRQ6OkCkDlwPudjAHZDY4Q4hmw2X0yiopITs9AgGE9fi/zFa4SWIgy9/AyytnOTa9d6O5c wbYVBkujL7ueqyqJomQRItJfbdKM2bPnzj/5pBP7dm8OXwyb8UhkAWWoYNRfI5MtdEgACipHFDka sUgQlRdGPKUppymLiicgEWWB0Q/cnAsb6y1NrdVvpHJIdt2UJ6e6zcd9bCAlEXk26JGTcUmXkbnP rTAx3FPs3BTQ2ZGaUhBhdLsngKdt5Xmi9T3hpkE0tS9rkKxqYFU28EQa++J5iYpG3lhDT7SeJ5aR rGqY5WsSshr6Ig28VdnhwgaJitaZnkaeeP1ktFEy1tibaB7wZwMtHZeB/UcQG5mmKXVQ327U53bn JtzOf3duVuSWjBGTmeCAX1gc+cvlN/Xd/4DD9tn7sSef2EWyIk2CH2Eg/RayD29/8PnSSNXF553d tUFWEJmPDCSwCoecZ0cR0+PhKvZSPhQ0JBCxoSEEI2V00bDjXlpgkJJxdv4Y01LgsTHRDltcKf+b ZUfTxvBRgmKSaGqLQL0JWwKmDqk+spqbStw/CQrSuNO7NLmmdoMCLjF00abueUtmiHvsTkwByWCU XraYyb6I5flp0YYbhg8//S+HnnHsYdp+AgadY0upBqXzzPSzlZnHrCjxHOiEdY7SPTVTF7Pu4x/H PPDCW1dedNGxAzoiK7IagyiRNqWZ7cTk26lvzbXYtsLw7KoWmzw6Mv4YAEhaC5csXbdsWdsGCK5J FgdyAmG1qUbLLjxwwYg70M7rIhs6phLjaDybirQU0zqeQ+HxarSWnWyLij8BfVkx9bW0h5sjF1Na dVrCWkrmiahL04JTHsu0S0oui6aQmFxQWaoMC9g+SPOM7iqzFRhjVziFMwMZYyO2P+C2aWAhyRYO +XoWknujeVYiL5HMl8TdPEgyll6jjHL1/c+++fDzb82YuxpJttg/z4rmJsO5yVg9gJ0mzCs/yVxc XAV+fySViHc8NbVTHm9Xqm3V2eIKti0ip0mmkqjyLhVdUwEieYtJGkER9HRJxA864ADwlzRw8ZdY XkCE8L3m15uAlzhdjQNQvoWhBqw8dIdRW00icIwfiHGGt9RtKXJSgkc1Xw2tiTAye+Jw1qs5MswR VHyjfk5klQk0bbVB453xhNIQjk8kOzgeSr20I4KZYykVfLjnapJWw3KUfNKYe4vmhXvwrkABmQka 5BXLCmPvj3p9URShYN6K/1zmvhSbcEfBWsDk8VpfT1lwyT0PfTR+1ocT51x2z2OfTVjEXeD6oM4k c1Ba4ADtQGuB6C4IBHGCuNS42VNb2URqA3YFgu1C97jLCjZHW9esghrWwHYaAWpfjDNj/qP+2K5j UyQCc0tbLwdBhKd5sBqdPOtgXii7oURaxJsVDFkZ2fkr1q4HmtTc1egvM+GWB574cuQECDZUMYAZ FRl2Y7VSZYBKCFtOqL8x9Y0jJxwLSVM9nF30DAaU1h47s4Oein8pRzeR0SE1s+nfV1sjUvS3p3o6 kJJey3kqV6BtJ8bZaS5jzxXHksIXUaljA29D2rA/O2WVOq4JwE1cA8t64a13Sz2Zlf7sUiuj1J/1 8vsfgVOk6ITI2QTxIZQP/gcGkbohpDwO4WrNiqy+2bJvpyHLrn8ju5JgM/p4avWhPNN+felZCekr 5rYdILkT2gpJZFUl4K6ToBPrp7SQEyWZkjhhVn7so4u/Asop3FwKodE0uyEj1WxgaPrf0FPHKJee xiQ+2I3DaqzOG63R6i+Vu3XUQ6R7BZA2Ap78Zc6a9VXh0kDmC5+OfO6dj9/5+se5y9YWV6AfJzfU LxPrg5sx3FKIXpLEKF3TsKEjOF8yUmZvzaXUzH8NkqvTzxZj5nuYfvKruDTlXCn+tz+q3ZjyOKbt KUUF5gz6tf2jMTblo7y33+kNmKukDtD7qYOqsG3nmnv2bUIBGX70bfcAIQRvogALMcwrvAaOk5ms 3AQrDKWqBOy3iioro0ga9oT8ViDq868pLZYpy7aKAkciLnwaa1gMyEMmE4vvkYSpah3PzAI4mzW2 yQP+WU+6ywi2amq4jpaNse1U1+pqaC+I2/jR0iRHtTo2TTFPa/vpIJ/aMKkiAVLQ4k7agzyTCL/0 JvQq5Go+jKNpysl+d/YC9UqTNiGItQc3PC2QVIC6Xxe2vp0875cFC0s93knzF3044sd5qwqbd9gN MbbmzVriWeLo+UlxrX1VzUbBqoQWqW1qp82PRjY4w7GxipomeMwxG++z8UP9hryphSiSXTe+AV7O nGUbz5zfHS13h+1DAW05S0hj5hLhQ/PG9YB4XbChWHOgBJkAeVOo5TRzQzkdn/bs0T3LF0+WFwfj VVmJ8J69dsPciSWiPJvtuVEXjkLp4YSFG8qg+NXPR5AuxUZSOeemRG798d61eNjWuFN0wDfEDlD4 ALPOqrW09Wm1qTNKkTOwcohYIfEfkR5qJdCDQexvRfgGGAfhvVV1M5WbNuAjrTcVe+Q02nnVZJWC r2qa1qbkAJ899bybWuPhAOF1KTE9sTiEGguhR85Z/sjbXzz21sdPv/vRl+MnVgUzIlYg4cuqiPmm zZrTtEGjDq1bIioeQklAXF5GvLLmJjVvqqkSXCFYPSadhLfXGGyfkXav8kejAKwrcCLjCGQ6dhJt mGvVz8uaOG0We95DJsUAFgLOgTRj3yS0s1FZBU648vQTB7Zr0shfkRfbMKhl/WtPOxGcQhgd1fdM Y1FyMTpDEB/Vsn6e8EtWMNSlXSPjd5GGAIxJb7/V6o82gr/xPLuWYNvoQWxrJuVT2uTKv40G1F7T KTAUBVx9hHYHbeeySmUK4JShJn5U89EWhMpOaYaROjbxUqlmRmtzrJu0R7a7AEsTFshYcKvlmTBt 5rsff75w9YbRM+asqYihOjvpDwAWCIwGxkN7l0YN8r0xuh95OK5ozxS5ODm22l04H1TApsXQthHt 3dO6FNhiCohEw4Qn6BW5Dln4B+23T3F5+WufjoYogi4XtQj7qFXZCDZI+hJ5sWHQuv+af7706N0v PvR/j9x8SYtMDbdLq94kVTspJPDBXRn3+xG3/nL03PlLl+7Vt3dD5BpX11sNXM920sS3mGa7yAl2 RcGmJU3GptEkNxvLSX5iE8ptT36RaoRPpFtPAE99kFts5RRHfqE025WbQXaG7OKNJfAyd266N1Fs iEhQyCkwkJhuQCz0A4aOPnv+Kl9y1zSXRZpU2bSYSzOkVM10emZCtkVj0aKiotXr1s5fuKR+oxbe YBYeIBhEc01ItngA4MTexJGHHtysUZYwoTTfUXqLMSrBMBkC84z8zQT+9G5qKXq3/Wi5V3ApUJMC hHSjmPL72TLNCiSTANE+8YijsnLzXnj73Xd/mFYs4ecoVT20p9D3bNSHqQ7hhiT+9tlWx3wfbDXd iGICYebxQpLhhcI4uPqRWvz2jzMe+s9LwZysc049AVUB4voAvIn2tFK2sl/uKG0lCuwyBdqagMHW 7frkFF2mdiqVyp3uwcMSvI2XV6RIyGrunb5s7Zm33D3kyL/s1Wf3x558sgJtawA0R6Rd2x+X9CGk bMLIkvfB/hf27bFpJpsT8lT6cMQFTkQCyUq0rXnshdcjBau+fezGLGmhwXi0GXsVNaSKQQf+lTnh dBET28scDS4dNWflc299uLywPJ6VVZkIZ+VkhosqBg8c8MPPP7VvXP/i447Yu2trEByJIYDHE+hh c23735S/ND0vkQJZFYttTP+txALuaf6UFKih+xJBDmqdD4ba2JUlt9//UNGatbu1bztk/8H1c7Kz /VnQDgmpJbFq/kVJGpCO4d9AMkkkGkIqfyTq8fsiiYQ/GAqHw0h+xJ5LV676aczEBcuW+kLBW6+7 amD7xjnGocMQhTAKYxNSRSAlAi7LbKXJuGsJNrFiTOot102AZuj6Ka7I9KCOrrnbdqKoYMOaPm3p mr/fct+Qo47da/eejz71ZAUaTHsdwaZiWCUZa1h8xFwUpHwaVZSM2p8XU1wclQy2ocuoPxHLSFRe fuUVjz3/ZnT9qm8fv94RbLbIUBtJcpFtYMZfmxXaRQx/o3E0UwPaPYQpFUxolI+/+uXX4ycks4KV cXhNgn6PH+3Hjtpv0FlDBzXNYFFXNB7x+KCepvyRclWVXDadTRKJub7961aapO5pXApsdQqopmwc G+jgFGNvYMtbAWeLz1MQtp5/5Y3vRo2uSMJWg8DKYLJ+PBr0+Y1sY54IECSDiUQ8BM6KR/0ogINT BhKOkWxyWUVlNC83OxAL79Ov93mnn9wiJ6SV2gb7RhIjlXOVkWvW8Gz1R/4znXAXE2wYGjiwRdcx gg2IOIolYQQbvuevqQV3242mI9imLl579vD7DzrquH67d4PFVu7PQKNRVcSkO7URbOLQZ5td3G+c XhCmkEA2OI0KIdWctk9oNBpKwGK7EhZbeP2aEY9dT0SQVG2y7qhwUL8j2FSqqd0mPg9tekojkYmR HmvE5EVfjPp5xqJFcW9WLI78luRfhuxz8RGDM+BApRsGSK6Uu4rGnzLTUgZ0yqGt6B66uYy67eae e+atQAGNBEskI4FUDphigpCH2ay+xPUJa9y0BWuKSqpinNUBAkmyXBXuC3BT3B+cu6oAGSVdmjf2 oRgGTObzC2IbGiUhmTIaCGY3ysvdq3f7Rj7ikgSlGk7d91Rw1X/vZdK/IiBsnCiwFZ7xz3qKXUmw ASibnZFkKqrhnhZsM5l6rKmUJZ8L9zY27BMoCWPk2ZqyeO25tz1w8LEnDOjV9eHHH6vyhSIi2NQp R5ejWGwMlfHmvFHwkUAeAgg84IUSSIwCxq8Zn+N0x0cINlpsV/zr0f+8VVWw+rtHrs/FPujZi9bc ItIMG6hLVsTI5m8iIgVf3AMscy/E29z1Jfc9+fyqimRFFZ0kZx59yJkH7p5BnkOkAFQnv4t8pNck xlocFWY2N2qQwNigwrHya3r65ObfnrunS4HtR4E0n6R2voa/BAtLDF2b5Ca04Z/jXNc0Lk10POm6 +xPx2Hv3XQe5pf4TnfTpPUMpw0xcTQBMhEsEnUdezE3B9zzCFWxbcdB36uQRJ98BD2wLKk4w23jX yZFaPTWEhL8RlFw6CSVbkVrVTwWtjXcCvwNkhLQihBOPee7SpkWc8EyzAL6qSDTuEGctN8w5iK4o ZAZaWcKLYXaT/aVEgC3QcBIwGIDGE3CSYCe5EKWaolVtrQ2NMxLoMW3t1ijvvluuPKDv7vl+q77f qioqEB5HFpiwG4WdFCTEoriXgAHhxw4gQdrNmOHYWjfnnselwDakgEoW442UNcWWcYozF0PXeOh2 2Ukr10rkWLEc4kbyI145SRph0PWgZgqqJHbAbkSSxCvbimUnY/xrJeBoQd9ap1bHSDW9mJ3hpUtY bVTTbUiWP8apd0bB5qSnp5OYHR8QmKXkgvEDYSDhVqpSmF0GwYOYNeiNycaY2+O5EKkS05FmFoww CDSGr5gIidhfDM4ISD64JlA1hoYV6DHIghb+HPZZYV+iyp8MB1kck8CxyLmimEzEiCWHOjPoi4kY /BoZdBoil5KTXhBDWF6tbKB+lLqZRMJCgHsF6SijEEiDbGtoWRefdNDfhg5sk2317dqWz4WuwWwo DF+pwi+KwcwIAlpts1SN3xqgBnusjGxD223XXPtjLBF/zKcQB2BKQ4R6rOZaTa1RZI/09kNzQtHt 5KX7IpUygWxKNcIQU4CaaICGZP3RaxCHEv+wQT313ZStprwLFkyzGf+YxN4BT7U9BECdH0tsmJQe Q8gMmRaI33I99XoRsQ17GSUqkWRcZCwhzsvlf/tMFWLC8f5wP7idzIA325dsnBVskR1smeVvjVdm oGW2r1W2t3UWX62yPC0yk+3yM5qFPK0y/e3zMpsHrRZZvhY5eHlb5PhbZQXkqGCrLH+L7FAT1HN6 YgGg+IhVpIghDAZsTNA6KXsQkR52XWNxG3QFhNagcv71sH0fuu2avt07wg+DMAOyS0qQ4uyzKjR6 pgFOb8CKaXNQrXdIazdq/MB1lLh1nirugS4FakUBhgTkJSsKJA/FHJM+mNCBr6Vhk8A+pNaStFVF MRMkC8xeQtWVYg7Qc1cLhtjgf/ZtGqhu22qr1d27O/8eBXaBGJvTFCYWgSCTDAYvC0SgAkGYFcSs 9euL4uGq5vXzm+dlYjJSLdLEjTot979HsWq/YxqjrmXU7GWX3/3wCSeccNGRg1DUovkr6Zut3/F7 SAvcoX6j3KWed/VF6PeOdw+Pecqtj5Zu2PDVo7fmp6KGImJE3+P+qjHWdlMOxJlQhQphibwVKwYf I+xL5Ifhawi2MgBuFVYUFJfk5zdo2yCInC7Ybhl0n+pdovs2bbhU5xf159g3U4ebqu1DuPu7FKg7 BYRxbO5jGpfobdWlUdokdriYbxJWqdc66pqHY4n4p/f/C31tDE44Af5FLDpMKbmX0kGATg4F55IN Xg0JdRvur/tzuEduTIGdV7BpLl/6HetyCmsMIg2NMT8aNen9r78rLCnzRuMBCLxEpEOrFgcN2e+g /rvD3w3f2rZeWOFuRLkahOvPs5dcfd9jJx5/3EWHD0aNZ5oVLNPdbCjPBkCqDwWbi1eVBL2Bdk0z cZMy0cUgU0ElD8lEEhE62PmU4Y8VFxV+8TAEG39NoIYGpQQi2LBDNZytWk5wBO5U3YzAHyr2oGZt QZpOmLfivU+/nr1gQSQRDYSCldF4g7y8gwcNOvrg/ZqGtMwOPkwkSSOXTEXsJkz/bU3/Wj6uu7tL geoUsPUw4SPJFGGPa/EPatUmGbKmkoqdqYMmrHIKtgej8fgnD1yNBYdnULkofg2zmzCqujXkG/RK AsKeckZ6iok7NFuZAjujK9KJsaUH2yKJJNKQYEMUe6yF5dblD//nsXc/XVWZrEhkxZO5USuvIqPB hDVF97z17rXPvri6IpXItJUJ5pwOy7kPSHOm3VIC4TGlpbgK1VNh4OQpL+jWSHh9i4uq/vl/T/3t prtPuP6uf9738pqwtpyGHhc3+CnCTvDX4wXnPa1PSDK1idjnCecQbXCjBJLaOl+xf9wXjwn7BsUj iTtBBmSxZT304ffXP/PquGXryzLyI6GsCsTVMvPWVERf/W7EZXc/OGZJAXy/MfAx5aJajfThKDpY +mtbUd49r0uBrUcBlo1SJgnvSqQt1aiPXzooeHBXIktMS2lZk0pLjAgMqrqK60N9j6bEx4gvaflE BZRgkiaijbaDKammrpPa8u/WI8Af80w7i2AzQ5s2wqwnJkQp/Y3FCWt1lfXpmKlPffD1O6NmDn/s mdnLVnq8vmAyefCgAWf/9fgzTzq2f+/eoWAw7gtMnr94+CNProsS/6b6Zown+yLpwePajy6X8ATw BfBvLCagIMh7ZDKkLXTMVDWudjwI7ufBZ16YtHBZZUZ+cSBr8pLVT732gTaDIWM4ncPkQJETdFyw 2M3INcn0wKXUu59mJdWVK4j3BfMX7txvf5n/6ucj//vJzw+/+tmnP44LewK4cNf2bf923DHnnHry oYP3apqbDSTlNaXltz381JTlZXCoegDpzMh3Da5Uqm4ZbWs/Gu4RLgVqTQETD0gh8EFuaSjZXhYd d4vynLpR0jfuaHaubuHZ0TvDqlQgTatdJyZXTZ657o1aD99vHrBjXZHGv0zrQTOL9AuRGYkkSv59 qCaBofbeTzNf+fCzctT++zzRRDwz4PdWVfTu2P7qc09vBM+YHASxsaQo9uRrb06fvxBTaNhefa85 +QhkQ8QBRAoNia1sgflBXDdx9NEkEo8eVScD2FhL0tIvKOWWIyYvvuqRZ047+aRLDtkjizeieFly X1J+gOtFvfQrHnrG5UXZ9Yo9wUTSm5WM92qQ+er/XZnHXcNsD4AHVgRkShxSpcQK/eXWx4uLSkc8 cn2ehgSQeWUCcbqnMJxohRql22R8L83GS6kyOAQBwimrS+595j9rSsLIzGTqKZJPfZ4GgcD1Z5/W t2NDuSafBHu++ME3n/w0rjwRapITeva2ixshnTKBqCd+lxaKXtLWdPDR23KZtZYzyt19iyiwsX6X NgM3pfxxuZFdNGjtxLsIf0dnJDBEUvnV2mFUm3kASYtJVcdd+2g0Gv34QcbYJDhHfU4982gaoKzo p8NGH8tuwEuHp3Fy6oJnusa7/LJFw1/t4J3FYqu2IIt7DwYQ/sCg+Wna/Bfe/agk6YMjgODzmBSR SNv69W656PQ2IVaNZFnxDCuWb1ld6/lvvuC01g0bWRmZX06YPKegsgjJGgGr1IPsPl/cY9BKq+ld W+AFkARFOiAzQqzsqopFtaJT1nQp+hJUAQNmIDzRuEFDbywWQnq9DwZPomFePVvdk73sDCvtMIfi AJywKhzOzMxUzoPYwD6GTZQNftdY+5UdcEL8sq4yedujzywtq4oHAkzeR+5IoiojUnndBWcN7Igm HqjIsULxBAp36iet8/5y0LDBA8Dz68ojH/88CYxd7g2UWQAvD8RFqsnNUDRKY+6tN0ndM7kUqBUF jClW7ZgafnJHnklgjDlnHmLrqPmFaiKZyuJp57xOq6gVOCFOdbpq4hEIMDPTjVQzHTuwTOkVq/sZ jf/GvjNwod0ouFYP6O78exTYYYJNBQqnj10UwltVo4NGAGeb9pd+7c23/SFfMFFxxYmH/+f6y249 47QuWVmXn3xSY4SwAM5GPH0fSqJZ3p+wmvqsc086NlYZjgWyLrnn8aOv+L+/3vjQMx//vDKShM3h WGbI1FAYGxUMYvDUeoZx7qITm2U1aZofSVbOW7EAp2CpGqrWgDgnfkmkQsVw5UQSUMLIKvz7X48L RKoCkYpgrDQnWXXaMYchfwTdDCmwhF9EupAkaAAFa7UwbJUUFjTIJ8o+7pLVBQ65HE5NG2M6Ugw/ Vfs2LQCW6pwDpeHdT0cUVAH7wHNAz87P3Hz5PZf8fWi3Vsfv22eP1ijURriQ8lSLAsGmkF1nHX9Q g2z0bAs888FXh1zx76Ouv+em/74/bkUhYp8U6rg3MDqiDz4gcTl9un9vDrq/uxTYKhSwOUKEklle bF+F7R5HdhRemNhO2YzquZLdAdlm+Ax7oKaInUZ5Z1BO+bItLslpYyNsrEueAAUa29lomoioshpY gPfF5HYZQQtVVWL/hkMRy4MPCUWwbAVnV9FtFUK4J9lUMtt2o4pxV0tsKWV+qColvyH1fOn6iqLK aElF+dAD9z9ycM/dGgQP7N3y8dsu79uxGer5AyzYpvMO6hZwSINeFhr369I8PysDca+qBAqhAwVV kQ++G3HV7ffNXVsCb1tKeupzGnVLDZjabNydyCFQ51o2yGndsskvv0xcE0lUETmLBWJ6OsgsH0xP eDWiFIGHDupx743XHL//oOP363//9ZcN6tacHUoRqEOKITfjVJTKZ2L2TJw6yxMJD969h0BPAr5H bEIHbKWmVVQjAGA/jhO9c55PikLhM52xYH7C769fL+/C047qUi+0V9vm15/397OOPVKaawBbUnox CuNjLCCbkf3Vt1e3eCxswUQL5ZdErZHTZt300JMf/DzZWKv0ZlIQQrDVhpruvi4Ftg4FlO/SmdnO 2tWURbWZjEJfE87U1hqBEMSUbHHIYCVBDARHEZCBYX843glNQqaAxRYLq0Ys010QDNhr3lbb03or Ot+lrTVm6ZMqutouQFuHXH/Us+wwi02MMifsagZYLfeEoIfI4ojF3VuRSPpCWXn5+TozsObmeq0g ExeQKUlYD+wLqSaA9fFEFMVYVtumjeGfbJuXs3fP3Rpm+fx+75qyyMMvvYFEds4+QbgxHcWM94EF WZvMWf+tgecNGUfjCcMO8kai9z39HzjoIDCI6CFMArB8GJR454O3UjKj9u3S5KbTj7r5lGP2btME jQ0VWRVXSaCcDIULqFqIR3F7OHdhxHr2xVdzPcnjDthbPH2wlFhMXdPLJ7SyU7HkTOl2W0qq2dxn PxI+l1WWgQ6ZgQDuBDoBkvjhe8yyXaIQpEgYw4vZz1KIg7tq26pxpreqnie2V+f23Zs3DVqekmTg hY++nLaipMoWtBic4PYoI/yjcqX7XHWjAGe4Zl3VON4IFYl9mz7AprxFdrTlnQOe7vMGHD8kfEHo ow0UBuyIik8U2yDwlvQG8Dng9WAhMq3lAXokL5Pspc4nvuy2hXbasAhAFb8QgVyK9Po11dS60cA9 SijgGz58+I4ihYy7Dr6unDK0GrZiUosH1n4yy//h9+OrYLotW9p39z3qZyIRBFMlCicfg00IS7EY 0q53gwLmDeBc0+cvGtx/jyvPPPqAPrsdeuDgRcvXLVhXVFZeuVvzFm2bNXC0NRVAek0hQm2mFrgH gSRMeKhwXm/nti1mzV4wZfrsxasKevXuHQhYEXbVgTDwoKUgml/AbY9MQoHJN1fChSECIZajXhTD ITvRj5aG7D+I/heWNWdV6fD7n1y9avX5p540sFubIBOL0b+USAfq4pebJVC47Wwxw2g/g/xbzVbD jvrotDNxJ3BFTl28fPHa4rKy8oa5OV1aN4PzVwGCRFeI0Qkp4JvwsEg1DgemsLg0Ga66+coLDum/ 2+GD++Q3aDFyxlyYwv5oxcBeXciiLANI6962o6aXe90/HQXUq2hWESNWNuJqNZjkVzPXNSwGjVol IlBa44hxiK7L7H8BsouiDQ142cOov2L/Q0t+7fMfYcgde/A+1EQFfw4odBIsV+VSuyfqXekSZ1Y5 uZB+YiYBmPj3Gk/96cZyCx94h2ZFbuz8M55xTB6MdQDWxErLuv6hV+evXhmA3VVZeeLBQ04dNqih H3oOzRp0EIN/ICUrJFaFOadoAtiBkxJ1b6Xxs297ALPsrAP6nX3UgSwoUdB9e6uNQEsdpZ0EKAPk imvL4rc+/MzEeQuDubk9d0fOZltYYxaNHnSqEUhkWJdwYEA2wVuHG4ghxxNeSz+kAgAi0QAADBBI +sNV8dkLF86cMStcUXrssAOvOo2OQeRwwhqFnohrUnTrxk6HKquUJ225VXNSpCuwJvcEVCq2rJc+ H/Xmt+Nxe8FY8V5d2l16woltGwUlTxSpkeTGRCTmDfCCUeSUIkkVoK+4fZPVRQrDQj3jvpcXrV7V s37wqZuugMEXxK3GIBRhy23h5HQPdylQCwqIZLK3NB9gtVOQZXQzHaJEE6NUU38gSs3wUpGHqDxU TKiAhZXWguWFk2bPXFVQsL6wpKBwA1D0Yl5/ZuOmgHId2K1Dr3atenZo1SDIGB1eGVIRZ2OLqDZL h5CtRis/2gqqUXUd/q3FI7u7/hoFdkLBJh5FzoUA8uNvfu7dcXPmx7nyx3P9oa4tGx+zT+8D++0B wSazEAmGusSLbAEit8wh1cBgzGFOYb/5ZfGzhj8Au+O0/Qacd8z+8LnBXelsdV5+VZ4xSgwMDvpP g4CsfOvLie988/WakmIAgAUBmgofKWGGM6qikaAHUgHphx50+wR2qg/uSTyoRLHiOAMQIaOxTF+I uMnoOt+2zd+OO/rgPkAkpveV+MjsF0V+MMnBfGoj2Ixb9dcEG0miTnzJTxE+g775wehpz779YZWV hdNm+SJt8jOG9up+8hHDQn4FRcBDEWqLLE/lgUEFPIlp9Irf2bTHA2Chsx56Y9GatW0zE0/fekU9 VpRX+n2hbd81yGVqlwLVKLAJweaozsYjYzQ8LVaT7+hiEJPKVLBJvN4KI3EE+KiWNXLGvG9Hj589 Zxl6ssUD/mQgAIRzxtZ5CLK+WMzpQ5fRaFWuz9ulXbv9Bu89qE/7xn7TqkZCHpsWbE7TefFP2YuY O6RbiQI7TrCp29soLulPQ8GGRL2w5X/354lPvfdF3OdtnZP19+OPHtizPUJBMAjg/xPpJdFg45ST s3kZ5E2BKIq3DSv4yyPGvvj5T/jtzIP2+8dhA3AS5E+aVF7TWpoiA77z2lHVOBogpbDG47YhLv1a Ub5sbXlhUQnss3CiyotW8bFAVWVk7erlnTu0EcgO/+jp8zt16Nwk6PdDzEFgAbARNhugqlB0l/Q0 btKwWQPIX7KHwG5B9qk1BibhU9OvYdTMNO+8qYHjfjU4xWC4IBHfFmyLS8Ln3v5wedKTZ8VPOPSg Q/bes0mmF9cyAOQ1COGh6aun9QLRHD3cAJksWJ0z11Wed98TlTGre6N6j95wDioE/FY4CFKQsLWk Z+2o7+7tUuDXKaAMYC8OdvtG4pUTu8fIEYgzEwCRZQMNOeJJX0CdGSNnLHv1ow8Xr1/vDWXC7cIe pLJkIBPbT4dLHAW1jLfBEQPbDeyIzGevLxyLNquXc9LhBxwyoFs9YV4/Eit5efr41a+iWiNXK/sG eUPOOuaO6tagwI4TbM7qK+7n1FQT1SliBcotz5X3Pj13QykshmdvvKpTHhty+onCYcvDTXgbELnl dMGkETs/GfF4Jq9YfcMDj5aF8tH8NlhR9Y9jj/rbgXvQBpLcXIWjBCAW7ara5ojKjSAUCINSJq3f h6x+kQAUzniDumtxxy8pSQ6/9Y4DBvU996QjIP3wzYV3PGX5Qg9cfzYMMnrZHW+FvKeil3KWErZH ayBUsDmgwyYVS3VP3ozsKPttrALiG0gnyQHh7b3+5c9PfvFz0ue//ITDjhnYQ6xY+kJFf4TUqh6a UCIlEQ1kVYWeHbdSmrCuv+fBX9aWW6HczKTVtVnDO688HZmTSB0L2qnOW2OWuudwKVB3ChizzWlB LGg5tl5rR+WwsCAQ7vWUIpxfFH/81f/9Mn9RLBjyhnxVkQgzSaQ5YuN6eS3qN2hUr35WVlYkHinc sGHN+oL164oht5DJBm4K4x3K4SqLOjZteNEpJ+/RrqH0zpbW2z71uDirDFO/FardFWx1H91fOXJH Jo8wfYhRU5EtosvIlKMLEbjxJQnr+Tc+qvAE9u7f99i+nbLh6lPZozlEtodcG087YVnpE0YMUnr4 0Kfaay1euTwvPy83K7OwYH1Fwjt/3qK9evVulBuiu9KDUhJV2bS3da02Nl4TFx8ugswpCTzZ0ScU vQCSA7/BTT9rfeFV9zy+uri8ZaOGg/ekCMGXj7/35bx166fMmr/f3nuyCNoodyZDIxmPwMXBnqXy OPZNilpoblhvVWWo3rrJidk4suU8mFYR6Ovtz75aUVaVnRm6/oyj8sXYBDILm78RD5kKqJNRY67D 0Jrax8Z1A4oVFhUgT6xJo0Zr1hYUh+PrNhTnBrK6d2gOlRZ71pqitSK/u7NLgU1RQMWYGkP6Esgs zd7nZ1MJqkBaZFnpoIgwgA/KtPXj9KW3PvrcipJIMpADoywQjtZPxvbt0fmso4dd+NejTjtgr2MG 9D6od+e9u7bbr0fHA/fseeS+/Y8dsm+nJi0yvNE1K5d5/d4oWwkHSsLxH8ZMiHqzunZsjutyNYih sTCdmLriKDqR6SbgBMFruwi5c2BnE2warWVeo52dJIOrQopLJwK2H3/7U5UvuHv3Lvt0aoX0cc0k 4nTg7DSZG1L6ZWdUihkm00aNKc7cJo2b9OrSeWCfng1btPp58myEqBpnBnt3biNTSOUEu1zXfrOF Cmur1b7hpYWXqBHiZuGpm7xmzXX3Pbq8FDzibZiVMWzvvnBErC6NPP/JN5X+4PriwqXLVg/t1wv9 CmEBYdYz5pyM+ol07HQz5GmNZWl41cmtstWCdFtzIzzy9IdzuP3Ln0YtKCxr3KD+ifvuiSa/wvo0 gSWvRbO5NpJMmrol2WIs5fEC4CXUrVPnfj132+fAQV+OngQHcmXBuoP27QcxKaeqPVHdI1wKbAEF jHFmeyzsdESsHKoAw+6CvmvmMBN+OUvhW0GQO8io86hpj7/2Tqk3SPMrEqkf8P1lv8E3XHTKwXt2 79CoXr6XxTBoqw3sO+RTBZEFIKgFOT6rfYt6A/t0PeyQ/RE4X7ZkKSL9UQ9ymwNTZ85eubqg/x5d 4YwMAViWWAyEIjJrk/G1pCVluyyzBaOffqit5m+l09XyNNrewZhrKhk0lIpXXpaVlRGEjTJr9lx2 X8PPEoqV/bGqyvIqKheiVsjaU+wLjQaLHxsgbf5YLAljCJAfmJF7de8Ab0BJLLpsbaHEcxXsw6aA wxOb+ww4kEG1GruLZGMoC505Jy7dcMXdT62IZlTFQ15f5vI1BbhLvOYtWSKmZzDqyfxu/LQ7nnkP LTDihB2WrhaCJYbsYVuxU7PNSGp1ophos7m2oB78Ckvwa0X2kqP0gfG+cePGvozgmqKitcVJCGCR WSLjpTeOxOFxp/CsoAABKCi2tsB+5bSqAYiMA6T1XQSJIk28VsfWjWOJ8pUb1kiY091cCmxvCqTP OvXq6AvpG/CeCwthJos4km8h6yhjkgi4++FEeXPEhEf+9+GGYAacLZn+WO8W+Q9e/c8Ljh3ULADQ PvpUNDk5jGi4rlMS7ZD4OmIOiUwr1siTOHfYwGdvu2qfbh2C0Uqv3xfPyPph6szhT70KBsclqKBq P1Ld7DY3uga621akwA4TbDo3nE1XTrYQla/xP6bR4D37eCKRJStWvfvDxBIvG9agAADoTWWWF/CP eOE9ZF4FgZLhRvCXW95yj1WBbm32Kxz0YR8tPZkyZwX8bFkZmS1bNOFqL1JQMIoltWJLJ1ZKRqom OGnW8hvuemBVWay4MhEIZaMGbUNRGRZ9yNT5i5eyP6fHF0ayZzD3izETH331c9wkLB71sgKGC4UL SCkR2WHopLBYZAFzt8IhyrD6OGKsOq4YsW/lF41KilTTeB62/v36+RPxysrKl977COQq0Vp4ENby 4W8lKGkFKqxQFf/6kZ4KaqOPdpUfQ+Apszxw2lR5vACKjFpBeDCL4tbSFSjNSDRukIeLOu7RrThT 3VO5FNgcCggTVOsbBbyruIWUEKwP/jKPD1N9nXS/KpZ+h0AVKEtaP81c9dJ7n0VCmR6gOUTLD+rX ++5rz+neNMhsNaZ0ob4TjaUo0fySUk13E5OFgT9LoBHopcjTBigEFOjmIeums4+/6JTjAJvn98Sq vL4Jc5c89PIHYBlEWCyfowpX62haLcKwOc/p7vObFNiBySNqFohSZS/KtqqPNFofRNG8deXXPvTc qvKKQIavXYsWe3TpjnxIwHMgOAclC3m2foEoSTKxEOVV1IC8BK5icxfaKER4Q+kA65orYsmfxowv C8f9VSXP3Xhpz2b1kAPFzjji12SVd+1Fm4qQ6j1wtUrGO2PJqsvveGB1wl8SzIj6M2NVSWQDZ0eL X3nqzhZB6/Yn/vvZzGXF8WAQOf/hMIBUQhWF/zzh4LOPPgTJJ0x5FBNK9To7sKyKnnCFCDYUBYjp xlQOtXyhNuqPIs3sYzXEQPENtYEYKCibw8k3WNaV9z87d/X6gBVs3rDhvnvuEa6qQAIn42hoiEAo PRJUJw9JBI8rpS3gXioDocwYpLUvCNiFSCSS8AYmzZ49Z83azGTsnIP3OW3YPiKNq7cidvnQpcA2 p4BGM8iA5lKSKoXZDGtpdVly1OSpE2fOWV9eUVqF3rrJhvWye3bsOKjX7pmZWVfdfm+FNxD2eYLx qpP373/uUUMh0hQACGygBTYG7F/LV42znmmWEG0Mn8AwZPmmH2uOQjGMnL/0gedfKYArxp+REYuf fMgBZx60BySfkxUp3hThZanGEbXe3bYOBXagYJNRVYPDniWpZ2InNi+m43fTlz380svFDFr5UJXG 0BMq2iDGUG4CNzd8DGyYiWRI5oog30JK+DE/GDymISarMVAE4khlTyRD8diJB+1z/pH7YPpyCmqi BDcWTFfXoH6fvrbrA/5DbHoeSmtM/IjlW1JufTlh2gcjx81dugIF5YFELDNeed9tN+7eOvfSm+75 ZVVxOJgDzwiygffs3GH/3p0P7N2xS9P6knRogoQaALf9r4oSmRJsyMbEF45g43u5AcPa9u0L8zBX 2ZBaUrNwWli6C0piN9338LoyhAMCnnA4EAhA5iFBlHXlkG4gnTmn+RfQQuFYpS8DEM/xoCcjjtRV OnN8cN1URcL+kL99w7yHr76gIeIMPEHNBui/T1B3j52FAkY/22idTfOh2RNOpqVEB8y2SSeQ/pr2 k9EKN/o+RQGGwmpJD00I0XOSU9BrEDJm/rrwi/97Z+rcBdFAoAqhL38ghsbvKMNGlm8UZpYPIAlV qEbDEpKMHLH3nv86/mB2xJZMaXAoTgejjUykdQJwPTrR43QCCZdQaSRcMoDQ4f+wxi5cfsuTL5V5 MlEhU8+XvPey8/Zok6cFPJoPaSupvGenMHzTT23r0bWkSdruv+aXSp3ZqYuVo2pe8XdGJLW7udAm 9t/yh9jMx9+RWZEa2OFmXGzCHrKc0v6SLzs0ye/Xs1vlhoKitWt9cTZRg9EGLFJfMg6RQGxsT8yX RDg3hvwLP94k8B6A2cD7iEP0eWNRhOmCEJPh8mZ5gTOG7X/aoXtjYhF0mEYJ8G8UJdIxGzeTbnLX MsNF/EgWIO9ZH4nv8gKezu2aenOaTJwwsWeblsFwRSIS3qNXt5bN67/60qstGjbco2ePpcuXDe7b 6+FLTxzYsUWTnEwtG+eikkYYW1zRvyLY/vIzbVHN8+Lv5h++EwuW9ybPJVkmkniit0dr0FlL6oe8 +w0cXFFauGr5Yph8SdAQqicqwYH/RYLE4H6BuxL0RLQctEXbggAEaSKG/q7+eDTE0CZL0LFAZHgi Q3p3vvqc0xpJmn+CiER1S8mpBf3dXbcFBaQiU1B+JdJrBAUnExuSSZqRYNhXkzrqThAVVeajrfMp czu/qqCSPXUiUstSwHNRo3TuyiGCAZua15v3pDLxkbchKfTAtNtgWc9++vMDr7+1oLgiYoVQbxYl cg6WCEaw8Qa7hn0ZERSZAQQoFunbvvl1fz8uTySZ4OsY3Q6LjJNQlWI7DZ9Uf2mSl7IcRGuT+nn5 DRpNmjIJuAxQzRfPmTVkv/4Isghhbc2PIo5PLIuHZA9Q40+nvCGtE2uoS0G3inx5IA29yI1qrwP1 mem4y7DoAuSMouCNaZyeGitcYLx9SG/4wszagvtVjdlUY5kmPkKMtPPoLJHopL3sb97Q1navHWqx pU9/vXHV+8R2og8hFg0hAGt54QQHUVeVkpAcH6MeGq+dcFJKuWMVAfch5QgnSTDHZDAjUC/Daogg sC02FH6eWpLhPXJX7cgnU0D7WtBZIRfEI8RYPsfwGMJ7f732gVVFhS8+cGezHGv02FlNGjdo37rJ quUrOrZvhaDauXc+s3jR/FfvGd61YTZKu4GtimmQrvqqGHIK12whl3abGxfzOTQUI9R+Op2+rCFg cbucgHECiWnjPjeUxwCtEMoIhcNxJIZImomQUIiiS49eVcgLxUJOrDhgnmT9HE++h0k6mPZBkb96 YXfb5ShgpytTD/Kph0CsFNjwMi9kYNWzrYaLAn7bCRFInPf57eZ8ZgLoaokdoXYi7Uh2hq+F8zEq Szhd1yzcNEnN6sbBITUzs36HmIa1cU54AhEbtq568MWpK9ZU+AHubeVA14pVZub627VpVS+zHlzo S1euWFm4IeHLikFjSybyvbEHb7hit/oZcEJKigcnvHaTQXqasLcTod6sUcUB8IIipHf3f94aMXtR 0p/pKyu69G8nHjeoGy5h+CNtDSToLJEmRYpIBziWzzl54yoJqtsCm3Ufhm+pbyJKQ9VDVV1jeerK gE8I8WAwOHZmNdNb1EE242uqrIiZB9Ree/GhuiPgD1QojOLMQcfSTf+qWRv5swN2+EcWbMJCZgqL YZ5AYqBQXLv0saAY+DbOPoz8pC2YqjDV2JQhnN2wg7Mb3iD/yShC5gctcdFz1FKqyTGp+9Hh1KI6 SVdBrHjE5Pn/fuz5/fYefOvZR8O37twtBzphRbzWu2PnPvT0E6cedeQ/jju4voGWY2sdFStO39Ea z6kXNfNHT+tMHd6DrRzoHYquzd3Zt9dYbHYrADgV6V/BzxHCmJFUytD6cjhCqaoSTnNPweKSu5ka D/waRw4qsBgIgxkD1pBqfu62y1BARlNMKU4YKaAU55vCc8jchtBAUYpMGZkRFG90MUgbvjigN8yP 6TorxKBMA1V4IolIENY8To8SGMYTKNUkWmxzEIPfAgBbq8mDWYcE3gBEUQypT3jd9fw7I2csiCDI HY/meJN9WjU96dChe3Rpqb593ollrSxJfvDldyNHj4EH/vCh+5191BCs65mUK0asQrDJAqLPWwtB S6mWAGgS3BzWwuLYefc8vAZVcYFA6+zQCzdfCA2btKOVRi5X9lWhATOIbRypk4Ow0Cw08IY/0JWd TcIQ1dh0M2aZji+B2Q32isGApwCivJPIjd4NW/FAzMrAyUTg9Wjc6S3iuXB1bVBHASnnMwuR3ogx 8sRscO47Jdic1WszbrtOu+xAVyQTOwSB0MEG1Qx3QgSr+AHxdLA5pHG0quHMUoyMoEWQD7gUmNcv uYN8eZixhF+hS8ivLDdh1Ep0QqghG1VW2SS3+zPVioaixThFKXKorORUfpCWaVm3Pfp8eVnp9Zdc 0DLLh/IXTyyKPhfSWhDRKT5Ys1YNvx0xatrc+YceflCO3Dx9jFLBJlLN5uyNONwR3jqfzO/yj/qJ 7NIYsyIZy98uh9dqQPyhgogJHIMTEo1mwM9RFK6HLGItk6pKWKGeVjboX7RqCzAfTN6zBxBFGVp7 oApVtTPTkY3DWKvFqVbkd3feJhQQB7cz+VS8mMxbYU6d5kaT4uLLJUwytqRMxQy5DrscKo45HinQ ozy3II5qo1/6/Gj9iR2heiLDwXWKzxLWFIqXBxUq3v/9MPHTn8fFQzmRcLie17rw5BP+eewBHRvm ZSSimZ5kKOllhCJhNcjw9O/RYc+efaqKCs455WhMb4Ti7RokA1wnS7M+Se2mMx8EEeuELyfbWxCx EGtHs8aqyrLOLVu0bdIAIAhw/IvD1yjEojUmiXLiSUbZwAQ6J3YQvFaRPFxueBNE5jLjUBv+QkoB SU2sWbNE6PolTiJ1PmNoZOVQxZbClQ0+NFojY8+sdYbV6YZMaAtixXDh4BpQI5tgepAzSW35LDMk TSPeJrO4TmbKVrwTsIKulUyo5QQiRaXhZkoIgerIGkJNGoZTUBNN1ru4jPWVvrrzk9oTcDMKW8Eh gNhtBKoc3GiamaudayUYJS8d6rptjqZp2zg4H0BU3/159qLVBUfut3e3hvCv0wXtI7wq5gN0WyqE uMMGlnXqMUeUxKxX3v+BU5xAkxATJAYNN2d14MRJvWwmS9myv8Fy8nBqPKmWZCtWVBHlGxDIT2UA niKkhCBDJDXrhETis+WeDPAxkMnBwkBQuKozEv2FaPtBm48mY2gXLkadZkG72y5HAQ3jcnmnLcXZ rYo9xprt4fHCYiv90kVXx9rHjCnJSpZ5KmE2VprKSzlUZx1qIFnypWsy+ksDhopzDbxIpGAygFou nDa17r+eWgQ8BWHrjU+/iAZDVeHy+kHvnZdeePSe7eEygTnnp+8cZTUxgI0EPLGMBBP0u7fM+9d5 pyBhRDxGojTyHm1+cViv1kMJ7TQgep91wrDBuZ4oWAvS4Luff2K/KnlWLkS2FwRkJz4sun4gzc1L kHRPAg0YIWo5EGorUXDzL06qKAi12KhRaCgHKE5iY+Mx1fRjRBE+FsQZBQBWYnEGT5eUUIUDI20X wsJiY/+wZARouPSsERYKu+BRBLDPlmbm2FR0JU0Lr8WN12XX2pGmLlf4jWPEp8seavaiqTNbjBVt 324cEpLaICObXtIoph5f1SOd5oLkEKBExYhrKq5e4RZY3cKqykFmrtT5sVJKnGFr4UfIJDTvfuOt d7MzMs848VhEnjwAvxSZhuf1ow0MW+2QffHTEUMGNq5X/7Ovvl5TJGVssgnGs6wp9qM5y4bet3Jx avBE55LZ57yp9lC22JZf+UFcBIzpQdPi/KZCrdcw7Jx++EaThJkpqqjZMo/wYuDWhIf8qGuU64es 87zaQQc62rWyBzcZZJmJ9DsZ4QFMxSDKwio9PtSBwTNRiRpHL0sbEdYCxCurHlkHaV54L98glOvT X7Eb/hZhRUSGEueQTBVORtuzoOZBLTdOZlmXP/r6e1yoIh7N9MZPOWoYOmRkSP936GmU2kSWkxWa QWZkmcH9kAQnikMC0CQmBr2FNoWyJ+uS5NIw0Pp26YD0N6xGk2YvKpTY27KoNXX1hm+nL/hq8rzR 81evDSdx21UePxC5WMNK1dvmRzMc6qmxg+e1oY95HKEqSvXwF43BQXyE2FneZwVQHIxYO1+sauUw YUB14LQ42LzkG9x8KeoCPcEqX6gs4YsBJZeDaF72avPr97ftVd4dmjzisI9NgbQwIxNPMYwq88yW PtdkxddFOP3rVEsXrtypnxNxOO4F7VB0MT1WTi4lB4rxWPvNuQfxpeB0UUgnVDTf/8L7n/w4+syT TzjnsAHoQ0OkOJjqzO230VepdzH+BSZ/d8yMR596bp89dh9++d+hNkKZYumnVrDZveVwcn7Uia2P Zk97UaZV6qsg5JOZbgDmGz3Sdl84IV8NHdh1fOopSvkwHbKnHFFU79iJwK7sUWKifMfvZ1sD6beD s6v3V7V8d9uFKCA84Sh9YucnaSKIVAOEPYefgSPUimDVGzNz2cp1hesKC6FAev0BcbSgKAdJynxj Mx/deCK6EDqC6wS6JvdBR6l2LZrt1Wu3hkF2L8ug6YINubecNGba1HL2QFohExLL7j9ueXBeVVUw 6O8Q9D91y5X1xCGk8soOgqPmLBGATZL2aIwgRGMhaUdoLw/22NVByukh+IvUtQCl/nfTF9z24vuR QGYgHunfv/eSxQtWo80kLVfIO+i7PuAkNcnN3X/wgKGDB7TL9bDizV6n7GRR8JemX9TaXHO4mfmX yG9DlwKvH/JpQ9T6aeLMorKKipIoG4wg3oMQXxzVv6ji4fLAWmMx4tkBmbqHFxl8XEzpTo7Vyw51 bdu8b+dWSPUUZJaUtp0avTpQb4uZZkcKtuqCXYu1ddXGPxBEAQwjqIPdYAsomdIlWU1txjZiVK3k jLLXVg0Xg08ZadMrmDM5qa51F2x6V0agAmjA8o9avPa62+5u16LVo3deCWcjmq6pQBW9Vx4EscWA op2wIS8m/ZV3PjJ1/uIbr75sSPd26Pwid2imiMgyEsfIeMeismVb6nFswSY9eewqGflZs3XFdyge QrkZxfdS94HRxY1wrHkDmjBC34PtNsF7HRHHmpNlkIRVJR+7SoaXu+0yFEj1M9MMAs4Jpt0Lk1BZ iVKCsZHv52NnPvvqG8UlJWhHiznF9rkcc/GY0bCTJCXd4KqWt4SZQyJ+Mp4ZyqmoqAiFfGhHixKd Qw7Y57wzT8zzAfSO2AoIFVC3kgzJWge+k7QqZm+wLrn9/4qCfl8i8s9hQ04/aG+6TFixKhNTS3Ts SIcWFXDpZrqG3rDNDFs4bkY/kGQb6Vm6rCpx+g33l/pz4HwS/Hc48OFMYq8cNPqAoRiC+hupyvB6 Q4nwYYP7n370IY2CFMnKZUJFTc7Elt5QcrNuVFfLOMqfGLmjarKmwnr+9be/+WkktAEkq3olnRlQ SDEm7wjgOYlilhuRbVqSgcfxRVCnFwpEo3CuJlBM1SAn47wzTxvWr4fGlTQSlFIO/myCTS0n4xbT KSX6mpWE0wJoIr6ELwMGzaoq66tR42cuWFxYVB6N0T5AsApWNPQ+4ShWpEErggqBdGQaRpKXjEgW SZuIoWAgO5jRoknjvXbvvV/P1tLiGTME1rNMCOzlk3SjX1+FtZlZDfj/lAbEgk3+DBbBGlDisf52 wx0FG4oeuvrqfh2bsmYO3gd1rNhKrB14MKgrYa81dWXBuXfck5OT/dK/b2yd4UfuhhEYknIWo8+G iiSWDRQS2OI/nQPTLTY1RqsJNrEO2TROzuONSB9FrFDwPHw9cfb46bPWFpVUVEXhRUX9GcuVsBD4 fSB1wIc0EV9lOJoRDCZjYZA4DJVbd4rFgn5gwoSaNWrco2O7gwZ3bRSg1oabxCKiZqO77VIUMKuY w5WykrKoUSQB8NXgXbSef+/L1977NCc788j9BvXp1rFZs2YQUdTgwY/Q9JmBAMOLxj+1fjaJt8IV laHsDMk4QJ4Iu8aXl5fPXbz0429+XL52TfOWze8dfk1HtCKMwcGJIlWqbDXYbXPIiNvGev351BX3 vfRKuQ+yIvz4JRf0a9dIjmWimbwxFXp24ZwwpQqh9E33Nct6evLv5tyI2cc0w2LyI+u1YR6dfMtT ayoZm0SeVTIK920slER7DHZrQxd7AEyEsSM4DiyWCLfIybz5wvO6ob5VcuiZqKGqMc1mmsa1Yi9Z RpBjiY4mcL9651VaV9/+4KplSzu1bXnokEHtWzZvkFufwwd2x3irf4tBUegopJiAXNL4pn4N9YZB dSjsgRXrN/wyZ/5nI34Mh8OnHXvUWcfsT59TAol+1KQZBuLj2EQz7ctTlem1oGYtd92BFpsJD0u/ UPuuqS5hmMNiT2Ri2X3hgy/e+vRLVFhEWJEMmz0ZQCdO6BLoMkEcXs1fB3QG1QdM1kQ8iu8TaFcd CnBdDgRi4Yqgzx+A9IpGGufmXXHB2ft2b2saANJbTS4SuKjfX4hZWWL7/uWWwdHIBkSGJusSICdg ft3/4lvv/TzyiMOHXX/8ERCikBHwQxrOMSohw+mSu8jmNirwIA6f/37sf15/c0CHDvdfdwkmB0tv BEEfEhpWf4wyybHDUs7BNJsotSptLNjkbiXgTy8RAB4p0r4bM+2pl14tiUSB+ghGoTEpfg7J1cId cmECPgsIm5WVEwvHMLUJqgVQPCEy3I/hskhmMJNpUslovZD35GMOO/GQfbIlSZxZbxvF5mo5Od3d tz8FDFdKzqK6UFhQiiFFZgO0zP+NmvrIsy+0adV6+LVXdcilHiOCwahuxiywvSzqKVHjXj3kOCm9 Fbb1gbX+yTe+eP+b77u1a/Wfmy9Gl4l4sgqJCbBhIPxqK9tw64j2vfHjjOfe/wT8H4yU/++2G1tl WVAFJdwl14bLnKyHS1A2CPOlCTY118y3jmCj/835bvOHRGu/BGIE9XrxMq/vlhc/+XnK7ADQIcJV bZo16rd7r64d2jRt3MiT9K1au2bOkgXjp05bWVQSARJK3EIeV74VvfacM/bpjIcQxZYSkumnKT/J Zt+NDA31Ewj4kqR13h3Pzl685MTDhv7jxANV1wctoJfbVjLWCq4SjiPHcZips1GyyuBZ5oqHWbG8 3Lpu+F3r16+/8YrLhvZuA58T7HHJAoTpByvkzyTYlAeMew0fiJJlmyJJyKhgscdzxxOvjxj3Y8sW zU4aMmxA714N6ufmIEXINszV04ijFA6OA6OplfKlE+DBl6XlsQXL1nw9ctQ3E8aiMPOSv53614P2 ColaoZldwpu/I9g2stvUuSdBJfoiGSF/f+zcB599tnP7Fg/dRM8+isHpMsCRyMcM2P15RHhreTjs J71bzA9ImivvfHja4pXnnn76Kfv1ytP0XvITs8vkMaE4QwTD1BRlTaeL+nkc/qTPx0i4lMagXlBp t4b5Cq8IFNtXPvzu1Q8+yMnOO2jwoAMG7dW6aaPcLBKNnUztoXGu4Dh11d/I5cmeq+Vha8naQjDk W598GgnHDtxv/yvOOgbPzuKBOvDfZjOqu+PWp4BMo7Rp5byHoglPYnBD0jrx8tsqItHn7rm1TV4A Uk1qP2zBwLwLLNEeQH0DmhXCkOAzcdSqWXmCR0N1x562cJIA6BumPab99Y+/OWnSpBvPP+OwvXoG aFfEfB7W+tfKIhEJkkAexNujZjz77melSSAGJN749zV00TAZE3andhmMIZMeCVzijOQVUlepkdGQ lstXh5nsyHhi1El4Enx3z5tffD92XIPs0MlHH3HggJ6qFtg+fI4nlONvps179ZOvFhZUJPwZyarK JhnWA9dc3KlBFhI4UVGjZicq9jTiWSsaidHGS3zy06T7n3t978GDb7vgONyDnkbvhCEVWugxRODW hwXnSXLL4OKql83Ce+7DO6CCzEVAAB9w2nlris69/o7GDZv8775rGB2k8c19oUsoCIaEYWyoNhs5 YuvPYfuMO7COzYgx2+dGhtKgmhfRNY/n5c8nfvDVd31373nPzf8a2LF185xQnt80jwDCWyZcDVhe w5FVq1aUl5RWlBTHqqrCZWXlGwob5+TmeD0QKmxY46FSmeX3tm6cN6Bvj90HDho7YcKoCVPadeze oWk+E9sl00v0oF+dJI5IS1chmaUpDhcwCqxISKYZK4qGP/SEPyM0/PKLW+eEMAkAQoJIOp2YUvBh l6nyrQQRdEpx2mBJQNR2j74DP/9x9MhxE7t26d2kcQ5KypiZTJeAFQMYI4xOqTGiiUm7qgZfmqQ1 +ZrnljXKloBMBKPNi3AfiPz52OlPvPjfJk2b3H3bLYf2361N/az6fiuLzaUQxmcT+0wU1SWs1UtX VCIeUlpWVlgYLi8vLSpqlJMPg4zzO1qRxSHwZPmtJvmZ3bu0G3rwwZOmzx45eXr9pq27t24MKAep v3G3XYoC9jKfjh0j36H3r+fnSXM++WnsocOGHtW3M5wKCv8kM1tmGgMzbG424ZepL738yuhRo8eO HjN65Mj5c+YM7NdX102sxsyMYuUASyfxJU7bsmOPz7/8FvNsyN794vFohsTqaFHVzpeNs8Viln/+ moLx02dGmS6f3Kd3z8Z5Gaw65vM4SZFmGbefVaLYvH+TI2ED19kDV2sQWVviSJqnH/YZkvwFmGPZ qjWtmzS48vwz+7RpmgfFF03aWL2KUhuptmEhjad104aD9x6wcN6KwsKSRCAYjsemTZ144H6DM1GA ZsNWcTnRqE1thL8sJ1Rqn3j5zQ3FZTdddVnzDMT6WQSlkQtW+opWrH2C73vkiRE/jBmL/8aMnjh+ bE52duvmTWmF83EYCuU40leFquJYbk72srL4pMnT9uzRu3nDXD9ukaFESm1zjyYzkKc3YZ/a3Hxt uWiHuSLV0sLm1NOLU5Eb7LVyv3XEBbdl5ea88O9/tQBMKd1yiG9S4isWSUzK5wtLy19+/Q0EyaJI coLfLJkIej0XXXA+UlkzUAtta6DqhNDzT15WePbw27t26fzStRdmYT6Rxl7FftmcWaJCTje67DAp PB7oYksqrH/d+u91hcU3/uvKod1bMl6NMFZCug8goCVJgzp1lIlQmYd/VZcRCD4fngg1bBOXlF13 xx2BzNDdt9zUrVFAamtUOslDQI4ykURgb9LuN13LlltTvEmxJnmjtoiTmQ3/zzk33bt89Zr/PHhX yzw25uBCok8k5iVjyDGrPBx59qWX0PMUXhR/KIgOw6h2P+eMM+ploRwIrkg1Iim+eT0ZzWXFydNv vh3JVJ8+PJwwsptF0drOWHf/bUsBM3OUOVmnyDkRZdWz9eCL777/45j777p9QNMMwvoC2VumL/Lj KBSkOl/LsxzLzMnbkkVMjHgkH0L+0EEJno6FPcFiy7p0+GNLly56+z8PNiVOo7SH4fypVc4/JmQk bAUnFVT8686HyoI5OM/f9h/wj8P3CVrxECrYUJgVM+5H5EfA4Sm+fm7CPo6fQ509yhBpURJlj1pt DhUkSIWHKolaIWD9C2sYS5fuP/p76LGUm0ASKpgU3RxvfvCVsStXItQBw+0ffzn8b4P7wcVH8ygR o+w341SrG6LVuCRqnXHeFb27dr3r2vPBpCEBk1EvMdc2IsbznHFCypvRxA3i9lDSLtNBQT5TRIPY xlcVnuDnc9bc98Ajfx2694V/PUISdtikxXGwycMpkdWXWXt61uZZd6RObZJnbL1DdTo+d8CaMmNJ eaRqr732apTFtTOMbAYCkXJRh23E4mVB9cnKzT7v/HPOOeesf15wzsUXnncRZNo/z2fmX4BmMpwh LNQghoxUIUvdWLfWDfruudeMuYtWbMDkUW0CAVvbgPo92gmKgtkY6mNzMmKt3njPg2sLik47/i/7 dW/J1rqcLDJF2LWJHvbUifm8TB3U55anRowrCQ8jZFivtjk3XHphcfGGa2+7bdGGKGL1cB1g8ovD k/qx8UM6pxPmsSF/qt29gXejsBKxqOybtJatLpq7fHm/wYOailTD72F0SxSZJ6kCHqaWwDjODv7z ovMuPP8fF/7zvPPOPuvC8885/4J/BLOYqopeBdD7sLBB3dYD8TigbbN8z6C9+hcUl8xestqsE79H T/f3nYoCKa3NXu85fYRJMMoYWVhUTZtmgA2jPlQ+0X+OfmYsGvOYyidMDKyemLT4K51qrXKUdZp6 KVZKYf9oQIqiAMOBXrvy/C2aNQWPFyFcwzkKlZWv2soR8D28KJ0b5jTJy0Yfx1jC+nnqjPVcTfE9 nRwMqtFXArbX6JqWt/IlxeTKjHZCp+OZ1Puo7d0440rpyWfBJfPQI8qKw0vPBDCsYnTxE3ITSXC4 KlAdWJIbj8HVVN9j3XTR6fkBdB7wVib8r3/4RaXsHktEENPAwsNoWy03Ju9gsSqJV8VizZs3BUEE JzaAnCAQHi9EKCu9pvqw0kvbTjtZagaR5BBQia9Aa8wE98cIoloRhXcYR+zZsmXTqsrS4lL8KOWJ QkidUdXmld52nem5eU+9wyy21OPqE9pGBygCGn3449h7/vPuhRdeeOKAdnQ5GjsnZVioAaTLNSiO uQkOUY+/map2IrujM6qegZ7QT34y/r13P7rvynP279VWUgyZGUmj6TddZ9UyRwxEKcbeW2hZ193z /PS5c48YesA1pxyeidAd74zcFGf+Ee9IWlA7FowmzwvOnm70S6I8SHUYZuK+99MvT7z4Un5+7j3/ vrVjLoMZXAAQJKOBCe0vLehtZomaaHJCvlNfNtKYGFeg01Q9AqIWfDFx9o3PvHjKKaecf8DuEGxK PbwYL7a9wSqH8Y1jdZFG9gtnU67SodMVAcfiVK+PmvXcCy/eeNZfj953T9VM3W0XooBdFoJZpjYB XOFUiqJWACHka+9+Go33Xnrp4W8+Hw3BE6cLgQsYZqQfbkikyjKazOIWSTtCfiNAQ1EZhsWcOwFT jvMeiXfwZGNxR2ZgIpqIRfbs0++Lb7/9asQPzz/6UNdcC9hynMXoJm/iSJtLP7UXwT6vfvLjqyPG FSWSmQHfX4bsc+FhA/LIPXB+So2o128sQrWopLRN57OAHYsSSf4xwQnx/9d6Ex4R/RVngzeGGim4 DwCxvJgfoJbCNjB1CYdEFyCknRTWafQ96S2MWW+Pn/Hcex/H/Zlo5zb8zJP36dYiGwyNloikMfIX a3dXuCUoFpNWlF954y3HHn1Y757d5y5eghBaiOCD0NER/xEXlNSzIjdMUJgZOKV0JbgMRiuKlDEs Jxhc5JSxg4cQSjIVPPsPHXTRBZftu3vPWy87F4s2DmEGgR2wT1O+db3ZttuOE2yOEFdHmRFsBKDG +vja598+8eZn119//YFdG7319oeFlUyDZQdb0B5ZpgRJBVpNsCocxl/QNBKL+4JwF6NQRupGwEdi 5wi3wdOIAgD2yGzWOOfIQ494/ftZr/z31dsuPOPg/rsxGQWNxQg5rkZd9c0WtzpyKgMhYiqjVjga z8tiN95r7nl6xtyFA/fsM/zCU+olLWAc8HmoO2rUlVEH5iIZIcEQt2gyaaMr3JXwEOkckxsUgKH2 v69GvvDm67l59f593fW7NcuBPUS5Jr5wTUziqXkeijH5lBKTZBhhD3Mhozow+RZ1Ax+OmnLr86+e /88LTunf8eMPv1pTXIY1BpFCZJDCNRRlRhqWFDRVoIrIPt8WJ3EgIwRtHXQIAuYHrbSRpgoRDtQ9 LFgBOFYrm+ZmH3/MER9OXPjUE09fdfqJxw7pjwXMFWzbln23/tmd+QlegJcM8x0TyYfqTKyJV931 5NQ5c5598ZGLr7iLyb5sX6JzS7H5uRCSQTFn/IAqYA0Acpgxtbi+Y6XhAmjS/VELjCUUrIpY7HGH HYR+F9/8+NPj997dt6E/g+nltNp+o0Oi6oDpG9lOwg14syZsnTv8gXUxT3k8nuvz/PPIYcfv31tK rETRowcIdQgsN3YcYnYFtOiAKtUM/zgWXO3kCBgwJgo5XY8qKenZo4HKEmgFpKQXBnoDvI8ShBfw FVqUEsQKW97lSevMq+4qsTKhJB/Ru+v1fz9C0rkB9qyMtdniQdYxnDfs8YxaWnLljcOPP/ZIXyj0 /rc/+nxZkLu4HNYfqsJyZoyg5KCxitGHpFLRSyjGpAQIKyYEG55CkRnYe47x0PhDd1134T8uPqBf n5suPUcTi9LvbzsLth2XPOJMTHljPlE9JDNNX7hs/IzZA/feu03j7Gde/2DqsnVz1myYt2b9vNUF 89YWzltTgDezVq6fj/er1s1dvW7hmvXzV65dsHr9fLxZxd3wfgH+Yp9VBQvWrMc+i1eti1RF9h7c f8rSdZN+GX/goD07Nm8E34Rtp0mSBpK1JOfVCFpW6Ov9UduEubOkqOL+F1597H8fvfXd6J+nL/7w u1GzF8zdq2/3Oy86Mx/uOOUKujOkDkQ2wXR2UGWdijabc2xHhxaKyotzonvHNrl5TUaOmfj1mDG+ Jm0e/9/Hz7378Qdf/Vwe8XbfrQ3jA7wUYniCRJ6OmGxfVRwgks6m3a0oO1kPvnB14Q/jJ+3Rd89u rRq+/P5n4xasnLl6w0L4J1etnbN63YI1hfNB5JXr561av3AVqFeELtsL1hbMWbV63upCRObnr1mH 3eauLsSeC1avxcd5q9cuWrWuuHDD0AP2nre6ZNyY0YP26NW9HWHUN5vztv4K7Z6xthQQaWHPTwb4 1X9GqQQdDTPnyx9Hry/YcORfDvvk23FISUcZU9wD6wcvKEy+OCwhGkM+1JmyPyd2YGEJevxiTx++ F38gd8OXSHwEdiqxJ5Oert26lJYUL1y44OhDhzXJRHo4V3jRCVVayVtZmHXDb/Dta8E1Azy8T3HW S7YS3Xt+K6NBvQlTf0miCijhnTxj1vKCki5du2QAV1ieB9F6+i9s1uNjmyVI/tXkBvvlvK0VPYXl 8bJz8/XENo+nTs67V8bn7cAliefS60OBh/SYMX/Zig0l6JqQrCw69IC9JC8fpjCCnoYYQhctW9Ll RmVY2qJqy28IK5iqK4rCX474oXu37pYvOHvpyjAyLVGUBq2dsg0Dh1cApePIisT1+Y38xVBiBCM6 moL4pUOMvxxZUUMOGbr3Fx9/3rZV8wMG9BUw+tQdpa3xDtFrRc5a77yjV54aelfq/hmeolnMaKq/ 0heq8IcqfJnOq8yfyW/khV/TX/ql7lDuzwSaGY7SjzEr0+YO5p5SJxG+1fkAWxD/mDa56v1UW1qV QXFJP/P6OxMXrihMZpQH82asLlxRWLrXgP7DL/oHfHpB22HqeDacmab5VvYmtprNSWkT0PCACjao ZkcM6X/FRf+EM+g/b703a/WG0kBeoTf03rc/vvvZaAEqtWexiCwAm/K71FXSL5d+dVkZJCxHF5PP T/qQOA5tQcxMvPR7+Vv9BXQ40lzoz18DIG/YG4p5kOQlKrPQrNYRgFpPXfeAbUsBeyoZ14J41Vg4 zcGFGEMrau/GLy++FMgl7mC/8CVeQNqA/EPwmzvEoOETcjeIL02VmMA4VuMR+SBMKvM6bUmU1A/x 90snEMWt5xfITBGXePfe3Rs1bgoLjYI2K/frcb9cPvyuz0dPqpBwMs+Z7kxPJ2SaSNtC+qqeatjU LO1pNWgpWWrnDUoCjog3HgT3DNaBdi2as37Uk1hfUqRcT9doNSdtWlAj7Y6rrayGdJrwZUBhRX0g LkwUvlJ9cVy8UThkMUywL+1xdAa6+rCmhhjjC/1GJoxpzZdyKXG9cZSS7Sdutt+VtnCW1PZwJv9y nDBsGCQOoSJT4/9g3BMU9dJ2lCHQRghuychNRNAqEWoR03noeoR3Dr5lnY/rCqp+mb2o0psRCGbS AA+gcjp+wkEHw08oXblTno1qoyk86WhUm/kgmIooBzl4wG5HHDQEvlQooyj1jnmDVZbn42+/0xgY JbGCpeJnBsb1W8NK8lZWJbaLZGAD56TGKl5/ltK5m0uB2lAgPcxcm+NkVoIfwYzSVYMoxHYvP3ix aPSJfUfbQc5rMsPZzYYLJWaqvtTTqAjGlAsKaS7RcQ0+a7uoj0fPufyWRxeuLq+EXenLjKBPdkZu QUX42ddff+aVV8tjTD4T78xOt6mbh5BklNG8wazsID8h1yYSVcEm6VrQD1ThSBOcaboyz5Jm4Kq6 ySFgSl0cAwGXEr2LjOzTK5pAeYU3HvPhFUsgJYCEVAVgV93+sIINA6Idbpzpm2ZImHoNfMPnpwtG tB667iDuqAIyooWhhfUO17IP2GjUoirCyAaBTAwCGBv6VDIeDnriGdFoHk4iUWdtzqjTIX1S1IGF lHUhkeplIBXRB7EGx0QYMCShDIBtI+DBXEQBAxNYNy2eSI3mJq5orxrSDcs0CdxVp6173zuCAppW UNcrC8gSOSpdyUN+k3yXstUcz6NIOHnVWKRwC4BipmyEMkfdjm5ILPToW1+EdtXPv/fUm++VxjyB UEYuSqOrynKTkb1373bZef946J57AGkY8gcQ4BO/6862kYdjBqIPQW7Kd+JGU5YnQwFUutoSnTcu VHGkV+ptmoWUck8xk0UNXym/ZWcP0/0r1QVbO1vxavYatrPRpxb380cWbBx88blB4/FTN6EmgqGL +GMR+vbJEmYoWaCBcfVjVomXkPqS+uCjsTDEmWK/ZjTICmRmYZIBwSsWi6I4Jtub7NGuBTsXCQvi 4Ihp2YJ5J2Ze2tyqrXjTYpdeHTv6KsozoFnFw4CQq8IZ8/KglrLsQbr0mg5Ymr9ov9Te3Hij0ZYE yI2fvgZ3cymw2RTQ5ZUZBHUSCNLgC8DEzKSQwLWqnQypx72RmC8a9wI4j+qhOq7o4ZBlWLlAMmzt Q9Q96dQSqxVjWYVJ65ZHXx4xa055EO0Mq0KJ8rb51nV/P/adB6685dRhR3Rv3TELmRI4TzwExNXa cuNmE6quO1LAIzkRGJB8GklVQ4Yn+idAgMPTVz8zk4geUgsLHcFkvqRdzAglpYzzElopKK2+4Obh qiijSLcwUliZ3gIXFV9+Rj4R0MNrY42irk+2I477I69urDCE71G6LYgj0ignItJotDkPrwYPZZmP iZF0YiObFl4+DLA/EyYaijZGzVl5za13bVi1PMeKBKpK6nliDXzWJWeeDpQvnoxZTmwgavCOU/og L1IHk54SSlwu/bu0PHrIPsFwcU68soGVyIhHVq1ced6Vt/wwYx7stjDiHMQ1TZs7mzBSjdfRhBUk p9T0t9sRc8695i5KgRoVL3V4Cu0krPFmmd6y7KZkjHlXjV/0u9Q+FG/I/kiHSkD1NVS9p17/7JeF S6OBYCDgQarfaUce9PhNlwzdvUM9ePUTVjYzlmP+JFAQNhmKrsPTbO1DKG9EoAOFQRYNKK+z5i8U WKRky4aNBZ9PVhvnyvKummGWZrDJXpqPprEU8U8xWw4xFPVhUg1Xz7CcyBZ/1dpebu3H3C7n++MK NsNCElHieyKBAHQY7xhgY8ZPmnta5BBKcJCSxJpNNIdCHqEoTqzVr7Suf/L1q+66b3VBwZnHHvLi 7Vdff+qx15924iPXXzu4eztMGXb/RVYR87J4TvUiGs2zzqMobB+MR6FjnnPssLsuO/fMoYOvOfaI V4Zfd9LQg0uLKm958MlLHnh2wqoNEG9s+MFN2MGe5sbLqgqw6HGiAWNnpJShCFtLY93NpcDmUmBL YmxmfiLFH8qfk0tFpZMvMebgITeRbXND6gVRHCldfHXlle7Eor/B+rDCPnrmPxs77dtJ0yu8IZw/ OxG58bzTTt2/L5A1ECaA5gmsOIoL6TMqvKkBrJ1s07sCwr6wM5568sJ1a4rLpWNkot8ePSjz1I5K o4wTKreXcrZPta035ztyvgpLD7pDorsAVHE4e1Ca4Y2hvjDuxYut1yBEJUMEcU8jCHcyGm3u7fxx BZvpJW2UP+1UbzI44FCRac3h5xThgAqwhxfp/ZxdPiIjVPmtAst659uJ5195w6QpUzu2a33fv2/+ +9EHoRXNIf12O6BPh7ZoBqjFm/QLoBybcfHqlVt1bPNmRo+5v6ywCyYTe7Rvecbh+x++V9c22dZF Jx748B3DB/buM2fmrMuvu+nWJ16YvrIIfW+BIIB8XG0db4SrYyvaAUY+N5pPsXqG9XXu5lJg8ymQ biRt/lHOnloaZb+4bjLFXJObWDhl2w3pp64RseY0BheLC0Yy0YFjAm/K6qj1wjsflCW9GcDLiVTd eP45+3RuTZBY+u5gEYrHhmKBnIGqVnXg7HSbVqcx082AOr790WcM6rPWyNNzz35FSYrwYmlpjTdw VCI+4nRV1IYMmh9XbXM0XXlodllTJ6/xUqZcWXKUWoO7th+SVNjpRner3RBsFFQyosNYBHk+0Ef4 Es81k5XRV8xOMRJ2xSovhdTi+IcHoNRjvf3LnOOvvff+19/GDuedeMzTw6/s3yIfdSTaTA+57dK/ XSJyIiLRA1cjXNjSZUbd5YeUoTO7l+ITIpMYXShAgB66Z4vsRy878/4rL+7cuvnIKdPPuOXOix59 5eflhUVSk0AlDtMXaH7iH1XvOlvfyi9AiQAgD3zrW43S7on+BBSgS0P6QHFypSGmbvajq/+fvSvp 3DBBNub9h3G+AKwEFq2owhlHDTLxv5m9b+eiU0OVhEDOcAgzrOyY7fi7Bq0qPvm+JBkk/km46oxD D927fWOEo0JUUHEuJoWpIERsnDVsEBU8lV5r59kkcxvV0CLVsAR9PWrq/KXLoyz78yWzcp5459PD z73p6Ksf/OfDb972+lcf/LJo2rpKwMFAvOFFoDs+igA+Q7aRxrbfyJZWoAJzo7EYesJxSTrg6oCM SOoXbAfHOmsi3CIait+ldnyX3f6wq1t66ZiYZazekBwspLojoz/hB9CGzgam+UMnIv4hPPUllvXR zxPPue62+x5+fMOGDUcfetALj9510kGDGtChEVM0DXpMbNe/6pQCELpJ96NxTtom1GbPlLQQPTM+ eAlciPoZmp9lINgWs/br0fHpO2667vLLu3bu9Mv06VfdNPzS4fd+PPIXRNHLPL4KL5ok+OPAXxaY TTQhQGknWBod4BE5FNw4d3MpUAsKpMuzOqRHqhdQpp0jVPjJF/ABOQjhbaiWRI5juxsqjYDeiFiB CstfYvmBSYhFHMbKirA1eu7KN78edefTr1xy411/OefKy26476uRY1ESB1dmi/rZJx/SH5ofG1BA e2OLAFPEKdcVZyazV3CVnWv+p2wodGMVFIU333sPTIredXgB+XL0tFmVGTnoUzp+1qLPvv/x3sce ufzq604//5rr737quTc/++D7CbNWlUDSQyMHrSq8fgFypOcJDbLxQoq/riC2xYaUFFbNEfCMRmLa NGAIlA2+azEzdr5d/7CCTSYxmrdCb4ODHW5lIh9I0YbAtgW84SjgkbnBMRG1/JBqSyPWk5+P/Ms1 d9310jtr15adNOTgd+4Zft0JB7UOEuEXrn6E3zQ7y7gB4EcRgKtqfdodp5/WjqgapQlgtd3kVAQJ 4y3zpUoYFV6p5YEJlmtZh3Vv++y15z96zeUHDuy/ZMXqB19847iLbrnltY+/W1YABFjIabVNNZsN d5udkUMs8ahbx1bb8fiz779lMTYNj7GQkshbJlcZ8Ta4D2AI+oC8hTUcrESYHDHL8MLsXRS2Rsxb +vQ3Y2546b1Thz9+1KU3XnzXw0+89clXo39ZvKawfpMW2fkNLH8gFo/44uUnHH4QWFWQ8YhyiQzD KIELmCRoerIIF6YpjTvRmBJISLwyoNSX332TmYmeGrFQJJIZi/rj0WDQn5Wbh4bJJx595D23Xn3R GSceceB+bVu2mDVv/pufffHAy/879YZ/733Gv464+p5Ln37r/9759q3x86YXx0FAaANq2KE2DU9f hcxvVv754xEI+UAV4AHVJ8xybIIdAx9P/FuoCqj9krXTkHPHQWopCewpZv61IbWmLVg6fvqswfvs 065RzuffjSqBkeWUU28u7chIUBKpJ7KtObBXoy2ysg4Y3PeX+SunTp+x/+CBrZo2wNDBrTFu+sL/ vvfRky+8PGXaTKQlHzr0wBsvOX/YXrs1zfBnWlCaOOEECoBIeJJKq1EssaPkAhqs47fyJI7xZjsn VYbWjqHUCWk2vuH/9JdiWrLkjn+YCc10XatFw9yB/XYfcvAhwWDWoqVLps+c9ePIkZ9/+0NhWVUw q35evWxMWfg3wOWLV5V9O3Ls7rv36d2h+bcjJ6wvjwI+R2KFMGr1xm2JKp5QjbaL3st3xLPTm4HX g98xIo8q8fpB/yEH7DV/dfH4sWP37tOrW7uWNcDiNnfc3P12HAXsyWsmmzP7MG0weT76+sdwLH7w 4Qd+/PUYSS6o7WbSHlTlUxx9wEP17NqpqHDDwsXLDz9iWEbQmrtgzQ8Tpn30zajXP/jmxbc++t97 7/80dtzUaTPmL1ri8we7dd7twAP2P/TAA0454bjTTz7kqKGDpy9eu2jF2mAokJuMXnnWMXBCoqEg 8ifgZSNsgeld5sxqmbnMKFPgqp1lk4WCjY/j0Qi60/fu1WPYgfseddiQPXrsUT8ns7hgXVlZCbAi sjJy5s6e3r5l/WP322vg7t2H7T/w6GMO2Xe/gzp26dyiVavs3PwNRcULFi6aP3/h2HHjP/nss4++ HPHT+MmzFi9bvr4Qmfye3LzlpfEfx0zYo2cvuK3mL1nu8QfZWVscXIpIxHAN0w50DmwuiTCOhw8d 9MXHX7Rt2XT/AX0Jgpy+dKUWv7qshHUYpD+wYNPllyxE3z264SXjzbKzhgzuO2dZ8aQpM3fv03dF SdVb34y87/nXAfm4dNmajk0an3v80cMvPHX/Hu0bh+jNgCsAfQK1ZYwMuQK64bxAXpb4mso1I4LM ZNDp4AxgjcWiNoMEaSphQVp+GgEUlmRDCPrS4yJTtYRObcfcAMoD2px+2P59OncCdPGyFasmzVz4 8Y9jP/x50rRl60qTgZyGDTaUx0f8PLZbt+59OruCrTaj8SfY93cE21c/wKF90GFD6iDYjDIEnwdS olAPJ0nrylI9u3QqKS6ds2xVSTj58BPPfTzih5Ez5y1ctbZwQ1GjevV27951//57nHDw0H+edNw5 fxly1F499+rUvEezvOZZXqSHgCvefO/rDQBQiMf7dmo5rH9vgQkGO8CfyZwu6HMK3Ko6okTcyLPS PG5zV+3tM/LE0Ucpjg/w0pQKeJCspNU6P4jnOnD//uGqqhUrVlbCrvUHps2e2WW33drWy0F2DIjQ OMvXvUWDAbu1OWRAj1OG7T1s0L79d+vcpknjejm54aro8tVrZy9aOmH2vE9+Gv365yPWRLyLl67a o2tXWIazFixgqijGwzRZdaRZ9dVrM55/ZxNsdVC7NuMpd45dYEwTmkakGgNskkOhhkk4HH7uPy/e 98CDn331JYrwjzz8sPvu+r/H7r7umCED8pPEsoLSx2wt1CnKszC/2FhM4pzXXGOnQK2aXWUmxxbT QNOWdKvmEyDWK8WdgTbGI8Lgwo2CE3DneZjrcWufHp1uuOD0156697Ybrz182DD0wR41ZvQTTz91 1rmXoX2oYsHtZMHzLSaYe4JtTIEtQx5JzWR70dFCTeYhw7CCpMnI9Ldr3+qgg4ecd85ZN99w7Wsv 3PfMA9ffcumZZ/5l2JC+XTs1zKqftLKiVm6CMxxNAKB6Yg6Xl5XgcJynXYsWJiiAsyK/2eYbZVX6 IoRPDS+pb2Jn2hThXzCOkO4Wg08VcguyDaKroWVd+JdhJw7bH1BHQAkDLuvr732sUTM8MrKmsScY H2sX/nZtHBrat8M5xx84/NLTn7rv+leeeeC+2/99zhlnDt1//3btOoRCIWQAMdtay+0F3NFBsjUr mSrru3Jq4R9WsDG/1564UqpP+Grnu+yQv3FO6K/DDnji5qvfe/Cm6/46pF/LICYQyCEukkSMaObi gdTiEjGJpMMsQl3QCBMRJm6p0Et76TfCMwYXve6cY8oqhfmBFSKdQZQ5OfsIHOLnTxBw0LokzhcN U1fFQwpsJG4As/yAzk2uP/nAb58Y/uJt155//JEDenUJoO+FN4oUlF3Yg153qrpHbhEF6pAzYriE Fhq7Q4O5NJbD9dsEoWFuVfijZX8dtt8zN1x0y2lHnTq425AO+S38DCGDKxEOQKNn9G2HDiciTDoS is5ZHkYPqfKqOFIl4g3r19N1mYnAyLhAlysvKlKZTuygloBh7IKcLSvF2SIq/srBss4A7S6SjLDD ONK7JECIG4YIBylOPXjQwF6dEtFKGL2LV6wbM3NhGCCPVLtZ0SDgxgyQ4WEDaC9lJUG6BpbVJmDt 3Sb/9H1733ba0S9ed94RA/r4IqXo8RVFSgoKfzzoeB/wJQL+OLozMx2ByTV18TNvC4rU/Zw7WrCJ 7El5BJiruolNQlx12SgMFDFSm1ywbgaNacAh8bNPOenck47o16EFVn+kUUHlgWzQq6PwH7M+moBs k80Ya+Qo5yb8Nov/qtqnUnQrKIYyRvZlSAg6JxUFXD4FUKvDjrV+ZDMLJ2gyNlgDK0KOlcjjX6tn iwanHHrAnVdfdO7Zp7EBpMo1p9mpFrWkPYw4J7hPtYwp+/l1x+opMamDdzJVuC4z509/DIfembzK Fw4svJo9Rq2vTin9Um2j6pthYcwZegvS90H82+vLANhPNAI2zLai+VYil8IMqV/gypggJ8Oqk7Y0 VNwkyCCYWtF41AskVbAA13faPJx7OD/KsSVdRDJRUiuMua9aBI+210QQnokjj5NuJaARS1KitPym o4n52DEIqjNPODqDHUF9aP3688SpWKdojApJRFUQ565oDuiihqyCkAXLL5GRwCJg5SS50PmjFWxy ij6uwBXz+6MRmGtSJAA4F2YkmOfd1Aj+Fil2Npbf0YJNaaVUETYy8WUhscQy5aWYWHxJscVmvLR4 SxN8sb8MGAaOosAPlINEDNJAUhxxTVZnU60DgpZcDpYQIlZBgB0z7RXTht0XuYzrDcmNAXFR752s Ygsw86/DNjVG25Fzqe/V35j+cihhppGqtsbmlFt15hc8CeY9m6syrkBOkJg4ks2opdLc5CwHrro+ L3H+41X+eBxVP3Iw9qWsl17JNGtJsmq3rfcmq8VG26/P/p0rerG9Fqdd/jqO+sSGyaIlqXxT9wMS F6E8qdokrgxT5yz/cGaKz19Ae22/n35vT1rs6BeRxtBAapMgD0qnkBVJ9gdCkBRjER3DLAnCl7rC i1Rjx1KRWDlZgTigOrzIH/RUlgGkw0xTsQVpAdl9eU2iv8Osm8wJTmfQzX//a6O+CXbfBAulqQ9k XzCwH1nbPn+GNHQjhxJmk3COHIW2ud7e7VrjG+D8TZqzAAnP2CT1C35isLBm5GiprdBSTk88JdlE yLMxHtHd2YcN6eGsbVM9gx5JBZmUML4ZTRlTXaPsRTi1RPy6HrODeWGHCjb17zkU+HU1ymEDzUDd nL/22MjiTTlE0WBGF7CrWOWRMiWDrxWn3A07Sq9YAvYwIgfW8kdZqK+KokpKFWV8Y39ODaHDreah aizvGzstN3EOMcKMjmnL5tRuatFuctRMPaU+CVQ/bHRKQvvjpId4o0ODxQkeK+jzJ2x8SQPybT+E jV9QbV4q/Z3SQJV8Rhsxyry5JaOO7Gz62w7msl3m8jUmrCAPmJHWIXV8VFr2nIrN6JSwHYw6W9T1 7+zjzNtqB1ajjT2x2T5XNEjOZYcL7F35raSAyJTOzsgIV0QC/uDy1Wt0Acb3Am7HxQK6qVE95Whn Ym6ShfTxf+3vth1Fuap9e8Jhzn1QPSVcH+4ZJmz3zu0BkRS1ohsqKoogy4xuDWgyBS6pdqJq96y/ qGJC+pkFUdV9O86mtb7po/Zbz502uNuWPLU9+44UbNAKseYSBcDJlk9Ve3FyqvGAFxHMYHRL9EuT QX73L0oxYvJSxCw060UTesLwyzwIIsEdjYckNIWTEWVH5zRyDKmEkDEwvngFPBAEnC867RwNxaz1 qclolJo02HLJZpQXSuUE7AAqMILadnWqPpuITFu5q2m6VR9OHSznb02xp9UHCDDQ7e4PQhsT0B2y g9cTUr0ZAj4exmNBYDtRdJ5HIccUdUyCkY4Sx4/qscS3CMwZxU6lr71siXJIXZqQ04JiUB1arLbT 0t1/B1DA9pxrxiLnjWp+qn1iasaJZGBkn3RVEyw67qzJWSLMZJ7ITFB7gXNJ5hWrgDH9YC+ooqnQ 5Dyxzc5ALJQ1Vbhg4yKqNKkrGRa8PWRYdO/YEcyMC09bOF8hprBjLIpFhaosq8IcaWZ6C9vzdlPq l0rB1F/jbjdAHumqqfPeDFUNE6/6ANq8vtGwVj8LPpHOtng2pGCDa2RAkwlxngb1cy1vJdHEkpFw pRHbireAv/zX1oudi9mU44+AH6IFRsBY9lWI+ggUiWQVfmnTXLGq9aWOyo3VeMcWZy2VLAs7YMr+ +iV3pGBzFmllG/X4bTwD4AFknzPbTFGJsjl/bbPaMI/tUkOdPaqzIzgD3dEUZjD8aekLiBzPrXJO VSTl9vSp4gifmlQ106fmI6gKmTL4akw3w13O1BEfgqRD2zZRLSZMLM7oOg5dtLbgxfc+Hj1/OQCH ioA85PEAXy4iq1EwhM47Upe+Sb1MViJbgupdVdukdq3mJE7/LBHNnQ2vqBY0/JPu6qzLfH5Z0Yg6 aEZf5zzWRBY2qq3EnagrVV/ROHXTNR6dSIpf7PgGhMngFDEw/9ptw7hh5ICUxLHnYjq2I9P5COGL GBIV0x7t2yGeVBWrWltaMW1FsbIbEv9Q9y2to4zyKECRYsKlmaE1x7oG06VLvl8VTb86X2pYfmly eVOH2OdXzTvFdfIAvBG2BqUsjyDnA/EFqOmIQaLNgZJYDuCa9lsrOvdSxCHmQ0pjbrt8zUg1Dffw atRLzABtfLs6lErQnXPbkYJNpYWGtZzQkVLKce/qNFXlkMxQu5cEyESd1EJ6lGvgMxIagU0XCxIu EtXZUIfUmoEVl4DCx56+kgGpVpxOK1UiRcFEIFehrdTcNFqVvS/khdYViHwyyqmOPdiMvdDUWaCn ralbpckzPUZZ6zeVQWdixZlMZRaa3CYNX/pqxAV3P3Hg+bf97d/P3/Tfr76YtRYgDiWw4dhk0B8A mLoRoRIFMeqzUlhu1rbSGKG0RaCdiVNtMquuRwWQyZrU/tCKVxOs3W3XpICtrauby+4LEU9CVFRb Ocme4uCwcfdTyV+2b8OYa9LC3umoJnadwY9XjKv0ZR+/por79QdZBzSQLG40Yj6yHRVcc/179Ah5 4iEkwfuy3//8R+yJ1hUIOMH5QpAgzby0+cixQW3Wc9TUX1mltTeIk2NVgxPTP9aw5uS20+2/mly8 CabWJqCSwykUYfdU4iKxpzV+w3Nj6VmxqiAeYypjhj9YL8vmMmNJpwsao52YrpByOcIBRpNoVg72 Z79yKipGTVHXsb3x2I1TGRSgxEB9ygimXhtpwDt25u84wcZpLpD6Rj3RBrtiUNskUc8Go8Ykun7t GBO/+141DjOT9ZTqPvYFQxGf981PP3v16x+mLl9TCNQZr1Xh8yJlOAyMGUympBdNzkxecOpuyOE2 /yl7VUvlsG/PJqkjkySbw5ENKTbbzJGvwTC/rviZHkvJpLaQb9y2S6U/p9SfM3XF+s/GT776gYf+ etFVV9/+4LgJ40lkcL6sGKpx619nZlO24WHNRDfZkrqrvYpRz9BHFk+FUfTUUwkdYqdV5TaT6n+6 3WrYF6nn50ga0ZCEXka9RwdeVl+naERStNJ8AEapr54hqWkjqh7Zyp+IzmqMnZ4aLdNSL5c2JHYJ DgB8rY7Nsvt06ZSMVFq+0JgpM8bPW4+8KQAV0V0ptp1w/iYcdJsY4pqK5ka7bEyltG8cjt/05HH2 3JijDVOr2SUhEL7MaaAQAxgM6xG0aYBjjZo8NRDMAtO1bd4Mnlgpf0hJJNN2+NdXCYk0oB8bMnQc qqeSIfWSjibgrABpI2ASf5y8h51Tf91xgk2nqlpk1aas+SBZUJz/Yk+wGYs49Df/BU6DsW5eoloo 9LUVZiJ/cNqiFU++/fE/br330ItuOfuuF+99Z+SXU1cuLpN+EAIbio4YUFCZ/MibcBzQqk4CXgvJ SzTn7fs3ThjqREbPTfGSKsDC1Zp8WI3N0ud5egzPJCaleWh/Q18kOZkq7Eeas/roO3fcjYmcaFkF 12syXub3VAZ9eXl5e/buA2tUPT9KUu14JTeWSo+0rVT9hi54Db9BydMgHIiZiqgxrsYYn2CEI2+Y fe/cbRejgJ2Fb8qZ0+5el0CoOmrQO4ybzrui8kvITRwb1J0kWqaqjkwzTUyopvPo5NejGH5zllU9 9aYWaMFJZX6UrsGYdccefEAe4GDjsWRG6JHXXgboa4TpJQFxuhgAPDEZEeoWC1LO/GvclGLPjSQQ H50HbuIvFXWJpOhf56UXSv+76esamerwjYm+kKfiVpYviKeGufbR95PXV0WqYsjN9w7q3z/FZSLb IMXTccI2Jp46nuj6Yq2rLks6tvriJtkMhIu0F2gTBNXR3PilQfedbdvR649Ne5nshrgkNvlHuEig 9HXe46+jBnLC2hbHJt//BqGhdQb9gTNPP+OyCy8+dNghTZo0WbBgwYeffHrn/Q//4+Krz7v23ruf ffuNb0YjQLW0MgHfXYkCZssLwKxpPZDAX5KTrIm51eaRPQPswDusKDkDUbdxBrvNhN6m2dnJ50in ijOVJP2EPlCcCi+cRDtWwJuKF5C8K32BgoQ1ZcX6L8ZOf/6tb8aMHgc8MBqtyPWMVeb4kicecdjN l52TFQzQokLvGvEjGVeNEtOmmtE98aVYY/q9mb0m/bcagbVZuZxDnZm/oTHubCzg3o+hgCzKG0dN zBLBATYIvawKVQ2Ms4JTiMcxwCNThG59ae8rn41so39GHTD2IkidVuSY+GMUp3CTgixtaZA7xTyL RtHLBR47KlM4554dmw/evZc3GQGm7Iryin8/+czKGDRU6FeAQeetKu9IWFkC53Ie21dRcwL8qsAz BzoBJoczlD+0c7F5vwlCpl3H2akm0zkkSKMFVhfYa9C2x8xd/9pHnyVpriWzvNaQQXtowZL4ZmV8 ZAVJI3C1RxOnMXubUGiR4srVNUWAY4QzdsP+N+p9Sb9lc1rNHdMkoJ2N4XeoYBNBpvlUjsjXAUUy ujQHkopLpGLRRBLfrgBR1/iLREMP0EDocqcJIQnuUC4xymG2C/UBPhyCAKdhy3VciGZKZUXHvNzj +7S75a/D/nfrxZ8+dsfD115w+vGHduveaX1x4ddjRj35xtsX33H/Xy67/rB//d95D//3rve/f2vS wnFrI6sEcRwOAX1BoqiUwj0o8wAFJGaic+qssSIJ7jNm7qKbn3/zikf++8yH366mRsmjuBzw3lhj IH0/ORyqtMqkkaCV8DJIhA8iHSnDcGncBsD7ZxRZX85Y/sQnP1/39P9OuvGRIedce9Zt/3f7sy98 +OUXxaUlSWioibDfE2noid966ilXHXEAfBfBIHvsIitSVh10Z4IWDRrhIhDSATa3AcgemYBxDlAy 6Ql4pc2N1MMZBHDacOy9y/gzYnbSTEu0VNwoswvY2MfddiEKqKmRvhxTq9GXrIHkROJUeZF2C5uc aDf2JjFsijcj6myPJWYSVkn4vOTcMU5pikbObTFijM7GcmpAYPAECi8A94D6OVOTqIbMC0BiYUeo bLLg4sOFpx3dskG2JxENe/yz1pRecd8zY5aWMoKO88pp1Aw1RdvCsrKs80oS9tYXuU+bDdvlemlE IS3skJtU2hkkZ3kvH/VUzgnVeW/+cgWyg4yadJP+VzUAEUwmjqnyGIosXEfg909/WXrHc6+UejOq Ela2N3bqUYfVF+QhW8hw2TB+12rTzt5FCvvkbtDLB+sVpLwxqFMPJUODA8DtBCbyIhkB7YT0yah6 YBS9RLIUrcZkwJokINVL0re69Ozbegyz40CQZRI5Uk0NBhkE5BRbMxasnDRj7sDB+7RskvX1iLFF cQt5rVKPbIKkts7FAwJoOZaQ+jPYJzgLWuQJLocXYhEZjsixh1fC7wdIf7N6efsN7DNrWcG0ieMO 7d93txYNQ0Cf8xA7uGmj/F5d2x+wd7+jjjxon733796jR6tWrYKhzMrKqiWLl86cPXfs2HHffPvt O+9//uGnI0aOnTJl1oIZi5bPXbJmdVFFecwfByBXQG0pph7jL5qchj1ookjp+sOUefc/998lG8Ir NlQsXLp84pRp++3bX9gaKAJwnaPttTfiIYqXvtBgArM54vFFLGS4eIpj1vJ1RTOWLJ8wc8G4qbO/ /mn8h1//9Pp7n7/27qcfffzpjyNHT585e+mKVRBRHTt13KNPz4MPPOC4ww8/98wjfxw5MREpR4+C e6654pBebQHrAAquKin+5Mcx7Tt2Hti97Q9jpqwPQ4mgDEMbSZCXIXn4KQVTE+/h0AE9k0lA7vjx V1UzM4OlMAITPIbaWivRMNN/0P4D5q8qnjhu3N579O7WthkrP7feTHXPtI0pIOlZsqxyiEUBdFZN wFRgcvzv/a8bNGiyz9B+H3wzCh5paUivapgyrvmDNRBMF4RjQNgSIoqqDuaSyEdNPdALEBghmeja sU1VWemSRUuOOOSgJll+pHCpQJOEMi6Yeg3nEvK1Ove0SBy1LDRcevTsM2HSLxWxZBivuOenkWNL SqMtWrfzZZh0LzyCrMrkULAVi4iYR89H03ww+y+ZV7th6DdYkeCqQTiEnV/sDmf03BDDysOGZ5pO 5sGBBDvQrtZcAWQdqJT+qmFUn1meKgtszr/6E97rCx/TXzgzzg95tiFpfT1x6qOvvf/ZqEmV3iAU 0EAitk/3Tucdsz+U1BSLGUPYjJsMhSGZM5LQMnChGSsLRk2cMLBf37LKitkLlyd82iwZ/3OURKMQ GBMJ3GEF0AICQe2CCoC/2u9DDlFrT/yfGCyg+39eHd1fF2t7udDZlD6Q23BGYxKmNK9teJ1NnVrQ Dczm+AegSGBEX/lk5FNvfXDNTTcO7lLvslseXlYVjwUykoIXpQ7JGn9hjUE9JM9gHyDseH2sF0Oz QqQJ4iIclEggVt63dbNbrzjn7R+n/vf5Z++99KID+3VjPAy/CzJNGHJGfIrp3gRQpzRqLVm2YtHS lUuXL1+wePnqdevLyypLI5VxLPuAExVzJxpPBkKh/Pz8nJyc7MzM7IzMLPzNzs7MygpkZIwcPaq0 IhKO+SB7g8Q/CQ/ut0fnDm3ikSrphQPvQBw43GUV4bLKqvKqcHlFRTgcKS4tr6ysLC8traqqwB7U /ihCkrFIODsjVC83p3GjBi2bNmvTplWHdu1bN2/eLJ+S33GkIFj4xCtvz5+74K5/XdWqnh+wzqAJ ooaTV645+8a7Dj3q2MuP2/+mu5+evrYwGsgI+oDgACrCRIPvht0+YklkFSNZAPIMKjSjK+hALPOU 5JG8b+OhhM7gqyrrlJ/xwM2XfzN5+UMP3HPNWacdP3QvbcrqbrsIBWxedHxTJlOeHAGWhIfguL9f 27xlq6tvveT8W+6rgiGfYI9KBbbRTYNkABcBA1ZGwgDBYgiaLkPwGD4Y2BGN72oibjARPfnog9cu W/r1l98+98C9vRoFgAIFAUCr3zC6nUVs5p7KO1kjPXB3IFMEazPvABrk7HWRm598enlZRcITgqIG fx0qAfbYvftu7dp2btOuSb38DByIqDMyAn2+orIKdYLGgDAH7QxYlFy0oQonK8NVUO98Aa4e5VWV OMQXRMu3ZEW4Kh6JMkQFcRiLwSMKrgGzRGLRSBVKRqkF4iewbRRu0QDlUDwaw6+CbYyWNDEUGpFQ PuQNx6uqqvRw/MWZ4QDBo7DctQpOH3Jc1BepYgp3AJI4kQjC3MxOJvp2bHPjOSc1CqQyR43gTxuv dAlCwWbW+ESFx4s+bXc/8eSl55+zrrDwo+/GhoHDBw+NtAvhjdnV2cb4Joo8nwhGhXQoRepz3AE8 SqsLwjhGHr/z8svOvWzf/r1vvvgfuWocyy3ZMlfniK20bGOu2IGCzbSB1we0x4bR3bKk9fZXY594 +4Mrrr56v90aXHrzA8vDCUzVAFCuNiWFnaYUBNrB3BQ9AayEPutAwsbkg1iDQzLTivZu3uDWy//x 9k/TXn3h+TsvOvfA/j01rZhga9TkjFBDBQyDq0ZTpBswIpiTmpSh/oH1ldbygoL1xSVr1hSsLyhc t6Fk/YbCog0lmNMlJSWA0I5WhemiQBAu4MvKzkVOh8cP8H0ob5GAJ1lVWmjFIslYVRB3BqHFIhX1 6wmkA6dRMhSEZMzOz81uUC+/SaOGTRrWa964UdMG9Vo1q5+XSXBYzfhURRtrDF508mBx8Znu8jOW rWrZpFmTIFvs0I/g553PWFt41nX/d/DhR152wgEQbHM2lCOfTJsxsRspro51hRhdCfgrUJ+AeUwv E8gjmGIaTRG927iQsSRkWdEOucEHb/nXV78sfvKxR68645SjDuhnUra28Qx2T7/1KCCLjtZQqppt u5ejXmuDZZ10zvWtW7e+/tYL/37V7UlfiGCESWQLaVNKyhkNBtCzDvUSYNvi6+Is8qNpPWYNcNww c9gCVBkZ08mfjB1/+ND1K1Z8980Pzzx4b+8GXkAJQLvCjzUFm+OZlB5SEiKLQ2L4ISak0BXfhL3W 8qj10H/fGjNlpi87DyZUTHJMiOwbjUJMBaCL0s8AkxKeTAhErub0PMC4lBVAIE0on3h7nPLGKYkF gQlS9vc8SuGK5BLaXkA1VF1/6L0nO6d2E9lg5ASVSBFvWGWgNYIa6CQC7y5CKijFSUZYpkZtG5IR p+ftRbN9wYxI9NgD9//74YMhNsDsuqUsIKGAGTpnnUz/JhGr8vnfGDf3weeev+z8s9euK/h4xKgw kv9l7dNgm2STqSjiWgDhjaUsBtEciwWCFPNQCGCG66U12KjiDR0ZH7/ziktdwVYzGmloxaQ7JES8 /tXox9949/Krrh7ao+klN9y5NuqN+DMQypTAT81NZ5hOKRRmCpAI7TbMXWmHwXmB8rFQrKpHk/zb rjn3rR+mv/rSi3dcdM6Qft0c4GNOTA3AkUWpm4jWSGUT6oqxTRRsTQfVFnISKDTfOL+WRaKlFeHK SHx9cWVRZfj1Dz5YWxEppcbqy4ZSWF584MA9d2vdIsPniYWrFI00lAULLxcGX25WZk52RlbIgDIr YfQSdOXIdZUKMEoldi5MKHks5H3heQnIUQ/Dz5qoKTQB81iocDjv5vv3PfjQK08Zes2dTywoCUeh JyK2JvOYN+MJROMxYodAyYZIx4UkyZENTs2DqlTT6+DknlAi0jrD+9BtV38yfv4zTzx59dmnHb1f XxW97rbrUEBTfNMFm0z8hCfs9RRa1tFnXbFbh07X3XTRPy+73hMIeRMhgQSS8lB1OlFEYAEPgvXY 8h1RYrR+DnljVZXgREgxmTRMnDI2HrNQkiccfdjSRYt/+mnck/fd1bMh4chxFxJr0jkm+5I10/07 5jtGfXhdxulwZsarPQHYl1+On/7Wp1+uLqoCREc8EIJuK251THHGLMgYSGqWsDafT7VbE+WQmKIq tbbo0vcQarqeiHPeloKEaqQdo/vwMeUoCYjY8ptqK0UamUV2UEHIo0A8FFnDsINo9cufJAAzjYWE wkELrTiSsdyAd589ev/1sEM71kMrVigLUSjEevMqVxyjzUy2TQo2hOc9FgTbw889f/HZp65fv/6b 78eGITqlOZdjdkuantw7fwnEE1APYCLgqWP64BhYY8+Zi9G9DFPv4buuv8gVbPaMsrneXpFhdEOw vfbFyCfefOf6668fsluTa265a0lRedSfiX7RajJTE0r7i7kMLE/8jcaBrYGlHoyG2g820MPU8XuC 8ACw2xOcEu1b/euysyDYXnnx+TsuOf+gPemKxNxIJGOYnchTNxUhxlYzGpmZJGQImOHsJ2FPKXr5 Te6wmVya6cuHgTNc0z1gJI2fu+LOx56KZeRiwvjClT3btrztinOw7jtlqGr7KLdLKr2IIqjCjBoa H7UEtNFmwolbmdsghBYWCMg1ZiSK7OXMI7fSAqUiGtOjmOHi8c5dV3TG1XccfNgRl/x1yF0PPDd1 1fqKBPQFT1AcKRCxzH6R0LGwqBff4KhwDEkoUA+cmjbxJkkMGfiagUS0c6PcO2/+15eTlzz68ENX nHXq8Qf0Z8tHe3jdf3cFCmCupEVFTXIH9Rqk5FGw/f2Knp073XbDRSNGjOO8oqDCGmhjeZjJ64/C h5eZXUaZgumb8CWAMY/zovBE8iYRVsYMk53jHhoeXbt0+PLrb7/+buQzD93fqwFRshSuXpOEjWDj /qpMGk3StlTsL3kM98dCDVcN1hDw3Q+TF42eMnXS7LllkQgviRQzWZJpJDFfmIqrI73Ea0K3CV0U 4n+zfT/GF8dsFTwAmFB0aLXA6JqDlPT7MzKAoc/T4vx4Hwz44OCE3IafKYD+A7Ju+P3BYFBysuJR ny+AgAK+x3t+nwnLkxkzQdq6IUo+KWEHV3Zs3bp7h+YN/axGB1S/rXxogtmvCza13RyLTWRghcd6 beych5995trzz2rZuMmiJSsViovuKNulLBYbONuH4EokyqdjrgJuGOsvaMaeQLaGwQQ9unbks3fQ 4L7nn3f5Pv16/cldkdU53Z6nkASYlG9++fPTb7xz3dVXHtqjzS+/zCxFxBQo1JLciGlb4z8IsUgs Arcj/kNyIZQ4lB/G4aCGeRxFuwc0GYJHzY+e6w1ygl27dXjt5ykvvfAfuCKH9aMrUq0QmQbG06l8 pfJE+kiwZQYnhv4gG0WaI3JEmokUkBEmO3L+0V/tA3AAQxQLlhd8+OU3RSXFu3fretSh+4F7FWtf p5/jTxDPiKTUiGfQXFS8HLoWKPMI40mKjL1RJRTjVKxLzjd0voDCJU/CbDbJy2VYe/aaorNvuvvA /fa/7fTDpk2ZuSbmjfmhfbN2RZ7UB+cR3SCSN+X1MPaGBsX+EJvjMF1SYs12wFmWE08Ivs/6vkSv 3p0/nDD/0cceu/Tvpx57wACV3O62y1HAVvc1nY+CDalMqy3r+H9c0aN9mwduugKz1zgKbGe447SA /AD/4rClpVZpaUm3FnlsKCGgjro5RjyuotkZ2Pmx/779ydc/PfvoIz0aeEIUF8hnsie38Jnckrkf gt3LJjwp66z2syHaiJ+OUUGVQ8gcd6kidNn6otXrCktKKyNU3ZAWDMMtjkA4OAawBuoywcbAsXQ9 hf8NH5TXIKUYBoPhAqmDOqEAOlZxpQAMH7yaaSxodFOHo5WvnR1UGqQpDtUYX3/FzqrsasaKvtcX ovghelCqIBttd7GW05HjpUzbvpiOny3YxPvEtATQqcJrvTFm9iNPPXnLxWcP69/HOT92B6E0cRT3 gLPhI1JXMEBLVhZnZYba1Wd0Mv1+0h8ch+OGl4Wts893BZvD7s6iLmQFKZGA9NaXPz395ns3XvWv Q3q0gp5CgWazhDM/1MrBAAAebvHygsxQsF3TXOyMSaDiirYK36cKCzFgSKn47/fjX3755fsuuWjI Hl0Z0xNWg0AkAJ0989JlGyeJLdEoIYw6KUEpFTkSgTPMJjKEl48jrEYOxCdMK2UwPRXdg6qIyqkg VI2IMm8Ud8CoYyrSNGbLyF91ukEY6f3TVCPOCu8qGYl6gqCEXg97MO4GIxBPh7k7c03R6dfeedjB B/371EMykpJ+Wd121GtgpmJ/JEwvWl0ZjkU7tMrLt4Vx6h70uvIZKxcG7uNJ8+5/5PFLzjrluCF7 uYItnVC7yntOV7lXBwcSsyfs9RdY1hFnXLTnbl3uv/Ey+CIy4cmT3STQqyKHKzB0uCLLuuf5N38Y PRaTrmm9vNuu/levprlB8UOIgLJVfg/ABMgXOOSB51//+ufxjz1wX4+GfkyblE1g+0V/VbDRWhAz TPiEpUFQ+5QxUzIkEaUdRuACvWf9xV75zcg4K7X+6nx05EW6TKrOAvTAaoROXZSOBqye0t/Y0q+i do8plLEPY4qyKtyU1rSfsA+SUdiJlHdJm2nTgk2vmtIJ6GEugyty5Iyn//P8Df845fDB/dnuQ5dR nlWry0kcXBG8PGld6e0PPrp27XpEJIfts/el55yMdm7qhpF90rcEAJsWVVlnXmAEG7IJtL95OiWr DetvkmXLf/xtsm/5+Tf3DCoObBNXvM8EDSHZQUH2G4xbUOUQWAYjqQ6ocuWXBev+dtX/nX37g2fc fPctT78FbRE74Fcx27HQs12Lqjzsoa4Dg6QohLAFSRxuEdVT1FmnA8ZDqutijm3k/CTJjMZZgQP0 KA62Xo8TUaaeVrXIpdVEC6HrlHwjzChz2TncTBYpZJGCPJFkvH04LqpJNb2QNK3SNxRc5lLwKtpS Tc6uUs2Z5/Coa3Rfqe2zokiHBmE13Kg3qbdXGLMuuff5U2+6/ZzbH/r7DQ/NX1Om4Tpwku4Gea1j wXxrncVeepoExs/ddjkKUOSgDZtikduQpxQVOjEzPD7wDkQR4jtGjjEpkTkEMQv9M7h04sDXvhn7 4bgp6/35hf4Gs4oStz7yHDQn4Qmoa9p3HjEFtqGXjh3KbgG4B9NBd7WJrnKQM9mVF1K8xh/oKqPd pT9JY0KCNzu4ksIlyNLUdQMTVZqXmjVEp7EmXmkSr5nhGrlCUE29DtB6bQZ3ri5vtBxNq+FEg1WW ttcLQWH+rZe9OHEfuWtnHbGfHk/ER9R1RVcDi1V89lrhrDcpUWNWohT9bHcuOzIyDYy3pE1LbDQu UdjxDdGURI5iIb3t4SfnbIitDTVdG2zy4dgZr33+s1EFxAkK4crBZmo7R4rykV4iLbVSkwMxCnUf GYM7pdPYX207Dtmxgs3W3eznoymjQ20mC0kMnQNfBgVFB94wrqe20QO14v8ee2J5abg0kLvBk/Xt hCkffTMeh2hklmEuMpvW0nBQ9UBMxUAgA0EpgKVq5ZsK1erzYctoXo35zJmVZ6r/8mtXUVlc99GR EkpcjBMLUk37ZeN0SN2HKwOSp6Kqktor/OYUaVyeQDHcHqu1bcH24qsfTlu4oiqUV+wLLlhf/NRL r2lPcVTlyM2BpODqKItpRBPGgRHWDTJQl2Zabhkl3aO3GwUU89PR7bgmcZxVBQT7wLEPDxyjv+Qj Mi8PkJpls8xKWGzCtOmxQGbYn1nq8YcDmSs2FC9dVW5cGpJdQhaUanAypyyLKkuRsuQstb+CUr8R U2we0+pejtxyOFHeUDipgz11dq4YYiPhThFegi5HVfu3R8JRy9MlSi0GzzzKxk9kiLvRqezvN/37 ps4j5i0KT5NAcJcN6QmOL4lxBgmdMv5SUh5bvraoyhcq94YiwRxUBUyZOVue0ECRGJORaJykixFV LOrgci3rNpy8cOemzJVa0GKLd6370rnFlzZtqe3FV0KhMAVkhklnTAR2BP0CAdoEymakPyxSHLCP OD6gMSxZX7a6uMQKZCAq5M/IivoCk+fNYWkkS43JQkgHFoXTG1CMO4wp9Tp/VTlHVtpNixREmFcH ZxffnCdQc9axgxEwkA9IfQyg7QVIEMrJki+w0iDXH9UzfuKiJqhAYMMKhl8nT50hiDrwrviSvuCY mXNKpfIBCmM0GRU3CwDCBYNAhCh1OF8QmTwIm2NC/xo/7uI0/uPePgZM0uFY5aU533x50dRJvRoZ WdnAWcUos3iTXj3xBHAhJJ6hGuk4R+MG+R64ppJhJPwjxByLVjRvns2KLs4X9oeiJUQlC+CmTDmm fVBVhTTF3FzgJci27YtrVYwJ12sWqDE78I8gGcH6QF0akhIBp8wVwkcPimEoQxjSxKk/qiZxN0/a bu+JxCGwrKzcXMo2KKQcN4EIZPk4H0aL2ejY9HmyMpApwnxy4DUkY2FPPIpCI3WG0YskcFACuCyu TODLICZXRUz7YBARdzFzNenUaX20fR93Bwo2AaHZ1AaiZOdkQntAqoWohMxAYo8YpkdIUMrWjfJy czIDfm88wtqXynK8qZeHGg9xQAtv+CST1TALY8z0RxeXlmVkZQEZQUZTQnFG/di+tN+qV/sNoaw/ iU5Kf0lWVhZouH79OoYcYAULndR3AIcOFFMk/SOOji9aNGsKmwzheH8sitybpg0bsCJXqBZAEzsq 3IKWKesZ86gxucuQ2B3I9Pszd9CE3qpE/ZOdTCeKLvQypvZmFv28vJxFK1dj2gj/2ZWesnjpykiv n2Wd/pej61uJ3FhFTrQss6r0lKMOo6NCfG3CzcYTgawNLIOqoaL5ddDrzVcPuqQqbgfSG8nNK+HO Ut4jY35KiQudjPK0TheDjW5sBy6htSASCSpWcMOcbLD5/KXLxfuC0Ke4Hu2xhuxD2h1+yPJZZx57 VG6krF6svGGisrE3dvJRh4lXVtpVCo3odzVOV9ZwYBDxfbMmTUnNKHQaVLyZO6yp4257nXeHjorW paVqWjjBYDqBRo2b1ANw77Lly4Uy0AWD8JlRZVIPsSTzI1uhRcj668FDs8FC8crcRGXb/KyTDjlI uEPA+IlqB7uYgBth2GosW2Zu8vylC8OJcPvWLeThbeJvD1aqxUSs0642c9rPIk2xBbU/TclsmB0K Bf1r1qySvVl6FIvLJBdyEFUWVrO4Z/924uFZvnBGojw7Ec5NVJ173BGICUOHYGhSWg5JMJuHxeJI SKPKDmQWUL1pIyp323721olI7kG/QgHxXeuwaS8LTh8icSTgiyMgQP9+fYsTsU/HzRd4U3YvpJ8f Kg0wocBY5K0o1r6u+cGX/33rmfsN+uuA3e8678xLjjkQyiaS/pGjzHCC4I0KVL2EapLWrFWVC5ev 6NOlM2YX/ZxSU6VIhNtwrGyOUPBT2ehZta+KrCzYphBn8PVgsSFfCFdxuajxErvNPjSN0bbhzdfp 1Op97NupccPMzBE/j14bRdYYbPEsDB5HRKI/cMwGWFaOoLt13mGD7j7v5JP7dvnH/v1fuu2mXo2y UWJI9Ai4ZHAIyxFp0CbiPgBK4tPosWOQbtqjS1fQIgjhiZ2wPKSZ/vS+OX6xbbw67DisyBpjI95d kUWcXvmNmrz7+fdr12w4bOg+EGiiCwp+oXgDmLiBrF5+8Ozes1Onjl0zvYlBu3e77qIzW+cEJTIs eYrMF2TSEMtzvIClYfrfrNXFz7zyRsc2LU8/bF+IxrgFUAVqk9Q8tjGt6zQbN/cguXc7N9NEsJUV 7SeTOQUxBGi7WSvWT50xvU+v3o0b5EKQIbSOIiPmfRD6iNzLwL7H17h+7oDBe4e8Vs92bc496biD +nT0xaKATZFhkEVHVXWuVkyHW1qaePyFV/OzMy877Wgwxq5Mzs0l+x9vP1HFiX0tTg9+Qm6GvPG0 aNvxw6+/mTJr1uCB++WgrJTfIVcISKfswAE1Hu8lU8mqlx3o37vrwD16dG7VBKKOfMgV0a9QqKpR ASIViIglHuvfDz9XsH7dZWef0bFJPZlVEZR0pVXcbEsaS/qHTGSq0GxMIagMYqcB8RV5m4SuxSqt s15YzBTiOJqwzvNNzPadjAHwUIBbCQHQMuEZM23m8tVF+/bviccmZLxdYCCdqxjtkWpYq0PLZoP7 9RrQu0teFkUVdguzFpY0odMSAhD4mT5PiWWNm7P02Zdfa9uq5UUnH87UdFCHpd+kZooMMqls4MJt Oay4+eHDh2/bK/z62TlHnIdmb2uF0uFqCdzqklju2Ekzlqwq6Dugh4CcYgdJcWR3NkKwkrZQpuJW p2b5++/Rba+u7XO8mtqEmlG7lYxJMUbXQQ+KTGeXJm/4v3sT4fA155/brlEexkVRRO0Zu5PNxFoP jHClUQNE0MkZCPzqVBQI1+Y3a/PtiB/HT5k5YO/9cwTihIC20jgBSZSKmI4yCYxC48zA3j067dOz U5sG2cwcY8mBAA5htSNeJ2OYKB+K+KyVlnXzA0+sW11w1onH9+nQDIMp3aHcbVeigIyXRE3knc2g HHKEabND3pz6jX4YNfKb8WOjGfWat24OLkSUxgHvFoRf04ZC3+Bc+isiOdplSddQAQi2Ri4quO3h Z2cvWHzYQUNOPngvwWCLMomJzezTV4dtQENbkeUqZNQzSbgSgU4cPl+wMGLd/MgLS9aW7N61HVxG KgR1J/uVWsD0Fo0WaZwkO9H0ZyA8EQ96PIA169yx/dh5i0ZOmTZm+uIGrTo3qJ9BJ4wZLIwLJDo/ YrAwgkR/lg4D+MihBBKmGUHWaQCfcy3Qsb+fdN+zz2YFgv++9l/NcoA0wzQIWVhFTUpb5MVKp2Wy DUa02il3IFZkuiefOhweGDMe1AAkJ2zbQsu6+o4Xp86f0al9i9OPOXxAn64qhDQZXU1aLcByNvXo 6j6gnNjKEuMGSHZx8uuRY5/94H3kj/z9mKPOPJINXCSpD8KS/RhQo7ntqb1tR9PWKZXDDHlluhJw SNJJyJ2Yo6hOe+Orcc+//lZWRuiMY486bP+B+RlU0NTHkq6B6kdbWqZ+lZMa4oej1tdjZ7z42QfL V68a2mfw8EtPgdsK5fSS6+xuuwwF7HaHaTdcDYiECxmWufdHTnzkpdfArnm+QJP69TOzQsQLZo0H +hjJvEAiCSGDCc+BlEI/4A8RCBAsj0Awo6oyhjwlLLJrNhSsrwijN/Qxhxx+0SmH1mfAR/pNce5K jokte7YRBdODDxIAkZixbBBcyJN69p0vv5wwPREJP3Pz5e3qZ8lSY0eNzD3VBK+1J7yzFG2je6/9 adUCF+9VLOBZkrTue/p/o8dMwFjk5mQ0qlcvm0VQQP+XUUPskzl63ihy+JB4B9LgR0FFF0GFzAUi VqBuCNjNqwqLCiJRYLLfctnFe3VsAnclvTXcUerHTa8AXZS0wnB7LAs7UrCpv5D5o8zjxzuKFjH1 dS1mHdX9L7/+2c+j4kCf8/qzcnKZf2d6JegiLBae44EzsxL7cBKi5CYcRdZxAMDE8YooQCQBvP/P M04+emBPMQHJONQqVEimL+e1nzY70RHKr9UEm36hLEv4LapalvXFqJlPvPhSWSIRjlmhzDx/MIQI JgtEk/BWsvATdI2yMggwmwR7Ye9sGzYTyON6BVCvorgiFMCiVnrK8Uefc+QwREqonbCRwK/mB+1E 5HJvxaaA3eeW3Cc9uGyTX7gyLiogvsQ0WFEU+fi7H38YN6m0sjJWVRWg/4SJ+yxh9AUYUzCTI9Vb mQkKyKBNwg+GnDt4WiKhoLfv7n0OOWBI3w5N7fYrApDhOFG28dDQ+y5tPZjxT+RveFOBucU7AAP8 sqLoidffnbem1BsNX37SIcfs3UfXazynuIt08TGpks6d7ryCTZ2AMpToxQhCwyqYPHvl1z/+PGbG jCiqoaICZ81SHniJge6FMaJ4lvIfGBsGj4JLiIAPEgeKJmCyfl69fQbtf/iw/RqycxeVXVlaDWqa rDkavdflJ20t2pbjuyMFm60xwU8LdpHqKdHRiAWF5RQN9TL9Gzxos1Lw7ehfZsxbvKGkhOD3tmBT ustcM9OJR5MbGcilgGQqOkoGrcxQoEm9Bv169Tj6wL5QDBHKZtaksWX+cILNyC9nAtlY3CaawHUD zAvjGC6Fgoj14YjRv8yet3JdsdSfgPgR9A1V3QpLGCKZ2DsE+AN2tMF0BxY4MwukvYWAySatJvUb 9d6ty9B9+nRqkAnaCu441Q7WyLnbLkUBWfFUrUzZLgmB0EGFYgB+aIw7SkECAUyeMnGKYD+nXFgX eweZSR89XWkEhzp4JapWSjoSZxHKe0SkmevaK+G2JJ+sHMheQcoau6EmwREBfgOr9OsxM1au+XHy 9HioXjCZaJsRe/y2K3II5MgtHon4CPmoKVbEUnSMP1mJ1FzD351r/nNonJAEuo36CLAH5406jTX7 RctPFV5L36vHS3/VsYFOrDk+mv2vkoxADc5IG/bXz86KbSbD9hhZzqjtklm78fRUuSKZSBK+FRvL llAibCSTJBIwzOPMlxqn0imVPrF0GByvMUivY4BvtDWfgdww1qF9PkEN3vg+d6Vv7IlVg830o8FB VzOZoMcmARXT1FlusKfqzmoO6+Y4hFSDVzI5/kklPiis6JcIPQe0PpNxuO3gS9+VxmdXuFdJ4bL5 EUY3NvRf0TiJDRIXB2wiPFWKJ5Ke/qoua52G+r0KOecbnVeshEup9o7ihf3FgNLF0PExbDuqiZ/d GKMJhJaCYctfFLPWVFq3P/hYzB9cW1zGVlOA0q/acPsVFw1o3xDZ8RAOEAmyPLFdhlHHqy1BO6lg A02ZEmNyCoiWiewOGGiaMLYxp+toqiJSQ7bJeoKVmajQOtbMGjKCTAuUuepI+DIl2LbHmDqr1g4U bLZej3up9vD4jAZ+QamLBGuxVxGGQKtguDnzRtZNG4vYXs1V5SQNCZKIDAh1d0qXMraQ5QdRvCS9 1XEdCNH/UIJN1AX6tfVfVSNIU35gcg2cC1CTJSuHySUy4aup6jqh02hO+gidHSLjI2SZSDD8ozoe zy97SU6Uu+0yFDAspE4kKpoCW4BGKhIpIHqbbHRLwg+CCYVxN2NONyQ39mSRNmQJD3vi6oKHfzlz pPMykSrkHOyaq2eT6srqzk9yvXFLbkPqCUw5bioh6e7wvxXHPK999O0PQAavqES6GVKCR40eh0md ZcXPOPqw4/btDocE+Mng7RGMT7y2KZhmh0K6Ru1k64m9RIo3VXMhxdakuMMwMHtBWwOJ25H2BgVb GgszV1WtVH1w7oDYG5YOYXX1XHIdMcqKHFpzbd8+S8IOs9jMFFAaqVInwUZtYs1PABxh8xSJUpK8 dPMaltBDVKqpPBI7xJ5Njr1BVoyEo6EQFEQ5Pz3pkjIimhpZUw6Sdd9WZbYhJ23fU9vz2NBTKaCy SnRVlikxmBbFFKVFy8Cyn/0yNnGgHAVO5k+kOUeMgwXfBkPSVNySQOYi9ibOJeUW4orZPrN4+9L1 D3s1HXdZldiPJgWEiJp94M2IOshSNMsTYIqyTAUT85YkcFXrOQtkijgJIKZ1hu2ikTnEGcjFEF4Z 7fInl9Z/HP51vF/bhuS67MhSEEnGyz2+H6fMfeWDz9eVRiNATCZoMsV0VjCUDIczIpVP3HpV63oB pEfiBgnQ4zQW2DUEGxCEpH2VtrQkFAMMb7TNwfMrjAhlm+l5ZxQLh+yORmt/w5wQWaQV9FneaQhW 5kf6EqKr9MZfprTmbTG6O4FOYdhJKSIGLhhB8tORLs4aAOYpiEhT0GFFPKDWJG+UGYxuoDoSjWu+ xHJLSTUs3aIbOqut7Kxc9MeVajZ5HAqRAqIPMJIMMYTO5Bof9gakSz1nqAittKXGeBa02FLHQmnP A3kadkRkmJmNGLmDkD7VGXJbTF33nFubAmbQVZwovK8ZS6BqUWpJrxbE23TwBXpGYI+FN2VxMysa 9XY9W2oWwXfHXc28k8R6lY3cbF2KAEMpL/i2Xp2woHNNx2SNJH0jfh73n9fejHsD6FaM+2fPNqp5 qD5GI90QZMLI8eN0ZyrazMRQ3VrwqNI2IcS2vvO6DL3U6hJahHFF8DuaWLJG2AksyGIowl5GQx9B WvTJlyK+7M0oMZwqkvcoG6eITB5a5TqLtHTdDLGuC9tn27EDwAZ3Zn4oQXRJlSpJ6WEH9weACYM0 CYgdTc5hT1m6v9jxTAQgVmJwDLQP+NUIMCk1JCL3YJDgg+nGkADEKgJAii7OUTC1Orww7yJ92LYP 7bf2VQRIVuW0PX8M7xmbmGqC/AYnrQQ/kgT9o7uBaN9w/9JXCcNYCUtLjC8WtvEDIiwCDUu+lapO 4WgvEsnoyUDjNwLFAs9b2moLIPnO5orZ2gT/Y55PFBLCRRqgd+QEsB0FOhwiGQuPTEgOR9eUtECZ ErqK6dhL2EAZKsVWBPFgNrmAdyBXTKIM2FlQTqCIqv0k0lM6rm3rzAsJCiEbMhEF/GlRRezL736u qIx37NAFzdjof/D6/p+97wCMqsr+ftPTKyEQeq+CSBWkqNjruq5b7Iqg2HtviN21rH3tvaF0kF6k 95JACgkpJBDSe6Z/v9+5781MArru98fdVWeMYfLKLeeefs89pxkOSYQIe9wNCK6OjVqyYmU9Utar s8wBo6TlSbaWMu5/C0Gwn0MXFRZW0oLgw2oLqL7IrHhQXJSPGMyV+obazlGaSOAjPFP8zPTviL9R GRs82I7kI8w9oy+6cNejijG1J/JLa73/1QPaynA11Dqx7RltC6Yo+7JyQ1m4/CLPkhj4p7oI/BPA Gptl3CciTUmaJ4ng4lKICkXnCgkLzdDeZsiMUiaNxlsu4f8WSv7c0YTiYVBVDn2bSGg4YFijF+GO gplAUsnILxWBVRoWtekmAFTnLKUd1LE3lkypetxKg3HMJZCKycFHW9DEz51C+Ln/GgTE99iSjQk1 0aFBEhKJx1gvZNOC+MFGjNpTNaSXUJJoyhRYoQ0FI4/F4pdUC7wvGIQr6uya/ktd/+XJkSNBAAWc cWAidru5e++BXbt0qa+tjo2wOpsaXFIBMQLpwZ1NkTZLjM3SXFXeNjEeSYsk8kXhuYiKUPEdRHoj l5SKiGst8VSxyKOQiMGYjkQDyhqljYc0xsAe/UrImy2MK11ICbskV9TfJh+gV0xVUFELob5xWeQh g/cGWDQ5p5gKNByYaYxvqPaCO0HSSMitwGjFShcMUiDTD1rJNlLwIb21wBT0h/9NhPhv77G1XD6x KI52fC9kli3XTL1vaAYBD0Bw5XWqlHgG3Tz9/4PUkYj2K73SAmP+5RzU0wrNQ1fnx+nvXzYZfuBX AIGWXNIgGaZD+v9deUWJhpQ0QCCYJRel3RB0++WBpHcmJ1vEh6FiOPHZU1L14fyVu3Jzhvbv0VhX GxsRV1la1iY+yu5tfuSWyRakBYcFK+GRyrIR+YZ2uGNIQYeTYty4Fr4Evx+SK4qhSl0dzg8cVEL6 TTg5eJPJgtmKfvJPB1DQgaSr9BJrI6fM6O/TpRkKgbvlALWEyOkApPBSoxLCNcLOeYW1RJlcSIhZ ecjgYkGrUsIUZ/gQ9sPh64nRuDKy4no6TfjNCCGTnHqgPtJCBdGZMEuBUWXQpaUwDt5CiIk8r6Sa YIJeGQAXJJZNSTqFD3LoAs9jNKI4GGGyIbt36tGglA5sD+pC878U7v/Lo224hzAEwhAIQ+BfQUAs N90oNVTkWs384Yrt386bd++Uywf37lpT1lhYeAAiacigPm3skAAwOMlv6apX+8wiTRCdgaOf2D0R U4SVyGDzKf9qk8djt1lVZR8GcYCxi2Twq3LEap9O1dhgCRg9BJwuJ90qVscwmJmTmyyGSEYTSAdC GYlz77C0cDKDW168r+RMoAw6vmIvxoqqUiKtlPWgYsXlPDre4N6BCE6jaLCS2CICIdA8mtOuv8cT a60+hoLCRPO4ZWRpMQx4kYciqGRcugVilIKjVBMnG9vVB46IXFkVFuBk5UclxHQNO9h5WLD9K/wO 3w9DIAyB3xMEdOlAIWRMm0YFRUWzyTblmX8eLi/7cPp9qRGUE9wjMdi/MFOnONAYHUl27HZpNmRh 1L1+2ASh1w85xlBTRJz3+vE8I/rK60UaBMa+0WCCFJO4UexQM5pDOf7FyJFdS3UIXILmZcuAWwEq IJMDwNYn2b8Ss16f0wJJKadUdUlgNBTwJyMiQcRmyLlpseMMu4oSjpVs9D2cgOmH+sFelGyUZimH dOuK9WrwLK1P1WfI8Xz2qcOHgo1Pis9R3zDi0OiBVkF+FLUi9hibzcnrvk0kqQcwbfqxrqAr7ghM NUxUdeO/GzzyeyKj8FzDEAhD4H8QAsoO0Dkm5QlK5eKvQQOPi4qIbGxsxHcwWgcccAixppWDOEjJ uILKBtiipkThqaSAcOQV1o4mp7aJVBNuLeJJdQTfpMVOv59INQZmUQx6EaVoRJeqIbElCb9k9Km+ QSW73sL99YxLrOElDk7mA0LQqvLAqdEome2nuA58lDGIHJ7KTuRhQon+CCYmMsZL81FiHFx8GOIO ckd/THdm6oJMgBDyMf4MHj1WN2UYepARvwo05GCJvv2kV/+R93luKBhSaSxQqBbyk7gUFmw/CZ7w zTAEwhD4jUJARffxgIEejG3wfxhOmtY1Na2uriGjoKhBwiApOqQWGyo8gWlKgLbFimRaFFncPWP2 RUaTSsUdHluWzEnyIpuXGtPYlhMbBfULmZcHKQ2YRAKbTzC8TDbGW/rdiN4y5AXdek4T6m2hHhBl jLLiRKRJEiuG2ekyAC3SUYnAZjPikw1RzbvKOlNxOhQuckzBjJSesPZ4rgr7Zmr60qY4VmkmBqrU MaUFItNVnCqFsxHtzOhzFWMuXkQ1NmNXDNuL+FEQVjIMVYoQlI65KAcnH9fjp/W89moDVvlCQyxO KBkh8dWSz0+3YnWxbWBnUDsxxvQbxdvwtMIQCEMgDIEfg4ASY0pYcD9M2DLL56JoDfPwNdRHmM07 MvaqfJiMJoQMQBpbnCvywT/G+HieYVMcXVg1a26r6AYIK6bjUIf5UOaQmfLZurJMYHVZGauCPyWo 0eTCQSTpnYXp1Xl1SWK5OXP/C2++I/dUSTg9aIQnx4wYOxXfbYKthi5sDsghdYYqdBssYFGpg8AU XIhakWyfRVX1zSr7tWHjSJZ5satojzL2P1BFjzlGxOIUCacMUUNiKjDr1qTxnUEf6rGQDhTYQ8cn 9lmLA1f6XWafkbMf6hNqeRrXfuTfsMX2LwAUvh2GQBgCv0UIKPaNTS2e2NOZptSFN9ltsL3Gnjig b9cOh0tK9cA8ml9mi6RfcbBcHP1slGTMyYKoD6/J78TZPJhpyiZzeikPkCq6upnRjOTKco4MzUCQ lNc3FpWWyXYW95IiUDwGqaZR6EfYN6w9WnVWrczl25qdX+OmYUSBgpzuPHSqp7xS5+HFNcrDheiu uKExr6wKTwesIrZHIadLF5W8SSIh2dQP6bl3PvVcVSMPbMtBbUmUpgQbs2NwjnVu75bM7C3ZOYgw 0c05kZ0i3ZRUEyEStJ+kWKmyn3gRmZ5o1KrcoSykQKkmRp68r5y06nm1JPqHh7+M77wrQpSSUm03 /ouTcGHB9luk2fCcwhAIQ+BnQyBg0BhbU35UjU9yaM66iqqqqkO1KqclHXF0RgoPZmyiYrtMSUV5 ARMNF5o1M/LlVzn9m9IzF/yw8dPv5r353gduPbGm9CO7VE+/+HJ6xl48Dw4tHk5Yb2bdVmPrHAjr b5istTg83uRRCfhVemoKEaSkUNEd3K4TWYW62Jr2/GtvbsvMDto1Qfmmu+/UmHmezcIk/WUNTdUu X31jozJXORCxLGnSyeDwqa5pWL56zZq169G+LoRkDCoppBGEYuRhkSkGBJU+XF6kjFSyzciyLSMJ SjKOUPcm6rnKeJs5I/RWeOpAGaMiMv+F5AoLNh1s4X/CEAhD4PcKAYN56iKO8fIwzW6eep0/wvLl 3Nmyxya8XJk29NFJEmH+gM9CtqDao8WlWTfvO/DPecsefe2t5Tt2zVi4aFd2TkFJSVWdk+8ZuRFY FMZqcwtrltAQ5HgPGCc0wFQyM7hDa+vrLBExNR4LhBBrKSBnCPfwsN1GHyieg/VGJo9UMOIzdPqw Vyfh8bD5JEcztxBVvU8mDlKyQzK/yAbggUOl7VLTopF1UKwrRrKwTTYlObNgRTJOZn9ewaAB/QEQ CkruH+pbYCLbzIiWlEoHHmQ+lL1AApHdGuevYfjhtAMuSlZ79C9CR+QTy89iY9GP+VH4wfnJETPp NrLBYJ502AbktMr5wiFBrHMsCoD6fWUxBj5hwfZ7peXwvMMQCENAty8MD5iyICRIBDIsKSbK73Zu 37kj62BtE/yM4mqUTH92tVFFySFhiGC4brO5oLLh/S9mbN+V0alDxwvPO/fvTz3yyH233//wI9Hx 3PrCD49wa1pheXXJ4dLoqBi2IUfEcMq6EWfdNDNEo8vk8DAwhGw6OTGhubn5yWeef/b1T2655/Hs goPiV0T4iqNOM1c5yeVdbi9PDkBKHS6rqK6OiIwSD6eMjS5H/ZQC7EGJd8FQrc0ayunZYFla7LF1 dY12Ow+3KaED3ymKpNe4VJE2hlM2e0xNLpTUjlIWG6WuRWv0weAzVzh9DQw/YXyHD4W59d04y6a9 OaX1jUyXTXemqRQWpw2dsmWP1exB1IxJa4a3FuYg8pXhWCCTapu8bqngipPvJovLElHp8RdWVFc2 eZq8hjxDCwJABPDAQsWA3RCmrUMvdZz+b6bUCpNVGAJhCIQh8F+BgPK90Y6ifSJbT4zB4Dkr5Tnj kSuTuVfXnoj4/3jWXHvbtPbt20CCcE+NdpJZks9Z1VYPePSm3OKnX3u9vq7hwdtvO3vEgDaRtILQ NM+VicygI05iBMsamzZu2Dhh1Oi0tokIZoTVdaDO/cl38+csXlXjNu3JLUxokxbh4LDqvNr69eu6 d+rYs0e3lNTUTZs2Dxs6FDEpZT7thTe//PK7b8uraocP6sd6XCgaXFOzesOOE0cM754SzxQhNMIg LmQ3S7LJwzSEOKn0aHsKD63csnPOsk0b03MhSc4eNzwaRdClShHuPvPmh59+N6eksvaEgX2aPQgw caxA7Z6IyPKauoPFhzp1bE9fq1979p2PP/ludnlN7fH9++AEH8YAiy2j8PBL7348b/ma5WvWDxtx YjySk8HwffLFgrrmhNR2y9dv+cdnM7WYNu3aJzW4taff+uCzmXMr6hoH9+/DVLOyEtjJ21lcvj5j 3zuffbtxe8bKNeurquv69+2Rnl20YsPWvdl5GZk58PomJCbCCLUzZIb+U8MCDKJSWLD9V8gq3GkY AmEI/JchoNI10gSiV1COS0thEfBN/gMzxKS1S4obeNxxP2zZvmbjpuU/rI9OaNM2NQXmFAM0zEj7 q8dM4MumrIJde3P+etFFI/p0iBHz561PPtuVs3/JD1tWrtuybuPmtes3+lzeLl06Os22FStWjBh0 fPu2SZAntR7t2VffKiw5fNlllzU1Na/dsHnWnLmdu3RPSkkoqa7/YdXq226YMvaEPgP691y6Yk1E RGRscrsnXnzbGhVz1bWTVq1amZyQ3K5tIvfcLPbFazeOGDGyU2K03+OSNJD6rpY6b93kh8VjuufR J/IKSyLtjrQOXYsOlddXV3ZKjOrZOQ3zrar3PvWPt6zR8VffcP3KVT+0a5vWpk1sXmnDlh07B/Tr u/T7+W2io/r071Pm9L745j+R3+S6ydcvW70mIbl9+4Q4bDVCsL3w6jvjzjh73CmndO7Subq8rEfH dgDUu3OWYpsyL3vP3uyc+LROq9ZvGDdh9PMvvmaPirpm8vWLlv6QlNKxY3IMJatZK6l3zlqxZvHq dWefdvrg4wZectGZJmtkaVXDjLkLUKjlzHPO7NS5y3vvvT90yKCYyAi1YydZbVt/wq7I/zJ1hbsP QyAMgf88BMTpKFF4rBsnudX1LRpx4snJa1xxaL5kq/bMbbfc8Oe/1tV73vjku8tufXj2pn3Pfrbg iQ9nrcwoLqrV0vMO4dXDpdWuBmdybCz2uLijZIUJ1bBy7eZte/dlFhQXHiqPTWzTvWcftG63WG02 W00DSgXQpNu6fdeBkpJ777ljcJfEs0b1f/yeySeNG/3ZzFl55U1Oj9+KgkHuBhwMxwgdNnv/Acft zcoqO5h385SLu7S1a7aIdTsycNKOebQcES6fv6S8HLLEao1kNhJMQiaFatkoo4p0X/OWLevUucMj t113/cVn/eWUwY/dflW75OjDlTV4BX7C3Tl7ig8UXXfNJZ0TzB6fc8XWNbjY5HRqLs/Fpw6/c9Ll l110Pnba0rP3ZeXse+iGq/okR2hWx7r0DNSUVcXW/W7XupVLM3dvH9Sn54gTBivBb7Y7MGGP0/XE A7d3SklEtedN6TmFpcW3Tr68S7LDFxW3emcmhKJKNbJx26ZdezMmThh7/piBpx3XJcmiDeydtnzT pkZ75IBhoxev3vzcK6/B/xgTHyuNM42zWN7BiBmFS2HB9p+nqXCPYQiEIfA/AQE9WESNJeQPnLyG +SYhFWDavrRY6xkj+0+5/LLB/fp2aN8uLz93y47tW7Zt/eijD15//bW3334b8mniSaMjraYFCxYc qGh2Wyknbrtl8vU33XnV5Mkdu3a94IILbrjykq5pibChDpaW1TW7K11uPIOtrKqGhpTUdgkxYn4I h45PTKirr2nTJtLjQVZJa2q7tAaP9vHHM3p27x4Vbc7Myhg+fDhCSxDXX3Dw4LrdFGwYQEFBkdke Kbtf7F28gzIl/CubcGh8d/qedu07Kb4PI277ho0mT1NGVhZFo6bl7S8YfMKQKKtW49Uqqqq3pu+B 17GisjomIrK6tqlv926qvdz9hWNPGoev9Y1a0cHS9Zu31YozFmO4/fbbp0y5LiEh7t133y0vr1CH vZFof//+gssuv9rp0kry91949plFRUWDhgzFzl69SysqObhu2zbs1cEJCVlVUFDQWFffrUvXgGTi 8WyrpbSi/NW331mzcfPfrrr2oYfuUqEi3G5U59mP+IRdkf8TBBYeRBgCYQj8hyEQyOyoR62LW5I7 axLTr4f/qYTCKFlm0nqkJY0f2v+McSOGDeg5cshxfTqkXnfpxaOO798Lm2BtU+KjzIMHH5+ek/fl 3IW+6MT9ZfXVTbbIuPhGV5PN5OmWFNMzNYUZuSADrNGzlq5qMFtctqh9+cW1dfVbt+8wW6Ki49sg rdYX85YvXvT9NX+5qEdau5pGz/I1GwYMGTlvycramtqTx56YlhhT01i/MaPAG5X69XezELhR09wY FZkwsHOqzRb7xffLGmFr2uxFBw4kx8VHOWxG8Wo9YtBnjfhq5vxqt2V3bsGHX3wVEx11wbnnrVi/ vqHZ27ldh7qGhu15Be6o5M+/nGmzRVbUNEbHpcbFJGxcv67fwD7JSXGwACF7Kuvdm7fttEQmfzpz rt+KqnV1CdHxXTq1g2zblbUvNiUFiVRqausBzD6d2kP+zV62Lq0TErl0/O67WY3lZVMvu6i61rcr PctvT/hi5lxsQnqa6yNstq5dOzJwx+zYnZFVjh2+4cehwaLS+uyCwv79+q5cuaJLr76jx44f0K9d pGxYwjKmuR0sBtNCSwkLtv8wNYW7C0MgDIH/EQgo56PUgdNHpKJIpL4gN6lUgLtK1+FFWRcW5pUc wwnREb06pUVZTXER9rYpbVA3Hkw5KTZy2MjjrY647xct2rpl847Nm39YuaykaP+BfXv/eNopydGR CFRHSP2hqlqYKZmZmenpO1NiY/90wWljx4xbtnDBiqXLDxwo2bs34+zTJ5510gjw7orK2tx9+3bv Ts/akzHlisv7dk0BN09ITs7ZV7hw4aIom3bZX//Uu0f3JXNnJ9oj4mJj80pK8vJyMrZujo+MGDt0 MHetpCalFLLkXGJj45sQiOj2REXYTxk/9qxxI9olRB8/bMS61atRbe6UCeN2Z+Us+n5hfETUpRf/ sW/PHovmzOnTtUtd5eFVK5f8sPaHgv3Fw4YMSkxuk5+7f9GSJTaL9dK//LF/967zZ8+Mj09qqG16 9923V6xYvmnDugiL/c8XnhuFWBtNm7tsXUpq2qL5c+Ps1jumXJ0YBYgl5WYXfr9oISoeXHnpJT07 tlu2YE5CXGzXDmntU9t06dIrM2P39p17lq9Yu+z7BYMHDhgEWKd13Ltn7/ofVq9dsWbN6h/WrVnT rTP8molygsHYSgxBq/+temz/I/geHkYYAmEI/N4hQJnWEgZyRQ/zN3Zx5AAYP1J3nhns1YYPPGRl ZZVmq7VNm7imhqbE6EhIRB7HNjJUVdc2IOAjOT4GsorpteSUgdvjR+y9OsuMJ2saXJ999XWffv17 du/RKTVe4hxRpMYEz2RVTV2bpFhlrtTXN7rqG1JSUpDu8VBVfYTVFBsVFcUy2apMs14KFA1KjhKR 1jJmVRIH7lA9uwqacvvrmxpjo6IdkjCkrtFTV1PToX1yU7OrpKS4U4dOEQ7UN9eciJasb4yJi0KA KN6trWuur69HzujKmooGZ1NCQkJqUmoEM/7TKXrt/c+OPPGkQZ3bDR/YI5oHGVBjR6JDK2rapHBS aKG+sam+rqZdm3ZwmqrtMoyzsbEZhy6ioiIwFTXs9Kw89OJsqnM3N/fv2zs6IgLBIwj2abVQsmMa rsf2e6fg8PzDEAhD4P8KASmEpjNYfCdfxT4djm3jYBYKvui7XLplqBI/suaonulDXKCKoePYs+wv IWOylBnQP6HREIGrgU6x1YQsk3gUPeKDkJPQ+YSO7cfmGWhBfdEzmxhPYzD4WK3BcjZut9dm04vF Ua4b+bFwLhsSFVnKcMVj8jdrppueeHXiyaf86aQBKI/gNSFTGE+3MbuIpC7xsEqcfqhc4lER5Sin LuQcHn4HQKRn5JTjgHJd3ylUgGsh20LLAvxfFzb8fhgCYQiEIRCGgHgv4XKEfYbin2C4KLct5wrI klVRNYnJ1O+q68oaw1dkThaRx1xZMOAUOGlsqSxajG/nR2QJ7+pvGVIN3SqppgtX44GfWBbVQkAq KwGpLkLqqBcxGEg1kTp6S1YU2dHHpl5X+5P6OUDaTHKQAu/bzaZImwyJSUf0tCNMpyziC/5MBRwW SqU9SrgFrigAyg+LBClQ4BLfEctONdLaYhOZF/6EIRCGQBgCYQj8nyAAwRCQJYGGIIGOdIlR5IUI HnxXVdlUC0rGeFiGRrORf9OGI9+HC1L4N0WmkW5D9v9oFwZ6DEi7QL8BifVj01NPqjaVwRf4E7aU uFh1+aqMJ5Eu4uM0PviTibVahdwzz4kZ8TLwwUJa0xKVNCF4UjWhugsFRWDMCpKhH3RmtyB9l/4I S+D9pOwKC7b/EzaHXw5DIAyBMAQUBJSYCRVvLEITsHHkgYDgUQ8HQIfv8AEGrsDLB3ni8zDhIkwj xaYpYYyP6k69HpCU+KIuKpMxtP0j5Wug68DrqqmA1PRJtQFVUMYwm3DCz7gotqN6ADYWrNKApFES UooVMCozOS6mtqJCGXiw+XSvrCGkA3ALnYgCTuhHjR9beiwXpHIqw6B04/zb0T9hwRamyjAEwhAI Q+CYQSAgsQISLmCXtBJmIqv4UV+UDxBn1/ARdo9z1izALfJMQlPo69M/ariBU1xHlVuhRttP221H fV3ttIWOObAP92NiEsP0MRBSJI8FdhoFW21lRUNtlYhGBnoo6czsYi0NzR87kRZYGGUmhlqQOOf+ Y8sWDh45ZggdbigMgTAEwhD4MQgoIRF698groW5AfA8YT+otJQVbXQzcUo0rkaO+H9nCUccW+spR W1AiB3Iu0GCrkevimVKYe18yDm6YIYIEGfpXbEnv3qVr15QYJPqyyP6fZNqU5MlHDDK0i8DAAnAL hYAaQ0DWtppaWLCFKTEMgTAEwhD4v0LgSPEQkDSt5NlRJZbyUgaeDIQmHimulOwJ5fUBSXakpGwl 9n56kq2m8BOiMdCR+qL/1ltnwQOW4aaYQ+EbZv3Hx+pFQVbuqLm9HpuF9VqPnMWPTeRIOaqe/LH5 8u6PGZX/13UOvx+GQBgCYQiEIfC7gYBxyN2w2CheEJlvZjU7KS8nqV7UKbr/ry0wowM292N7awa0 /786+N0sVXiiYQiEIRCGQBgC/98QgABirMe/lkT/3z0c/cWwxXaMARpuLgyBMATCEPgdQkAZVLop FbCuJGkIPnKWO3Ag4P/PoAo9T/AvWvj/6+B3uGrhKYchEIZAGAJhCPzbEFAW23/4E7bY/sMAD3cX hkAYAmEI/B4hEMy+2cK4+/mgUBbbz5KSP+uhn99z+MkwBMIQCEMgDIEwBEIgwLzQoZEf/wHghAXb fwDI4S7CEAhDIAyBfwEBsP6fyf1//pP/LaCrEQbiJI9a5PrfHVugzZaNH72ZsGD7d8Ebfj4MgTAE whAIQ+DnQ+C/IGXCe2w/f3nCT4YhEIZAGAJhCPx/QEBVqfnPff6jnf3nphXuKQyBMATCEAhD4H8F Av9pQfOf7u9/Bc7hcYQhEIZAGAJhCPxGIRAWbL/RhQ1PKwyBMATCEPi9QiAs2H6vKx+edxgCYQiE IfAbhUBYsP1GFzY8rTAEwhAIQ+D3CoGwYPu9rnx43mEIhCEQhsBvFAJhwfYbXdjwtMIQCEMgDIHf KwTCgu33uvLheYchEIZAGAK/UQiEBdtvdGHD0wpDIAyBMAR+rxAIC7bf68qH5x2GQBgCYQj8RiEQ Fmy/0YUNTysMgTAEwhD4vUIgLNh+rysfnncYAmEIhCHwG4VAWLD9Rhc2PK0wBMIQCEPg9wqBsGD7 va58eN5hCIQhEIbAbxQC/9myNawNzvoFLik8Z5Ifm/zWP4FCe3IJf+Ex/PbKbYv8qI/+SovnQwqH 66XHW5QSDxYmb7mWR1znW34pshAcmBpN60v4W3WhPmY+Y4zcpG75RXVo0ZCaGu/KZUO3CBmHutv6 gZbDbvFX67H9vCIRIaMN6c6YRIs2g9MMhUzL5dJXKvAoFgtzaz31lp0eAZifmGT41q8cAgZGBTBd EbhHaCsUE/AdmAP8URdDy28GCf9HUUeQX1oMQeEWFGFc1/lDsPeQESrSNunkGUDqUEugNZUdnUMc 7eqP8aLAAoMD6MzBmIgaARngj78sXeFFM76Ax6rnFTCFHR3djDn6sH/luHZsLTZfEAcBrcAPgK0E FIDrY43wek0r9mqH/Vqjpjl1xPX5vT5KMPwIvmNp8RVIj2cO+/iDJ91yX9ZYyo17PCG9oBM8rvmN J/RvUpRckRB+e/0GjhrXvZpfBAn/5gO+ZvTDgeJP/K/GowaPpnUi4/OclhcjUj9yBS3xP7zvVW3q Iw2BBt9QgNC8Xv1FzeeRdvVfuKXuGo1I79K6PkovBigdefGIPjb5or5Lv5yVDJ6vtShoKwNVQxX4 qVmiU4/PjZfUTIzW1KBwza35qZB4/PpiyovoAcvG0fKWpjVp2rw12z+Zt7rGz8XgLYG7vqQcIf/w eHgZTRmrpVoIf367ECCyCnkaJOURUgQ1HPRoJT7+LvNrpZpWq2kNgkh8Gr99wHUdp3UuojDSoyMM 8VwRAYlEkA50qpBPp/pgA4pwQG28KZwiwBlCiUQQmz8hPYPU+B7x16AyP1sIkK1QENvW2Q0IQ+cW MjQvCFooFL+I+cZjBpNQRC6Uq/lcPqc/wOo4YJ9bA2MSi0AoCIMTZiXNSLOYiaJHXMHLc9bu+mTR +mq/eoc3QWKK/nSCFgaIi+otxa84SHU/ZOi/RqQ8thYbgG7+cS0LcsID9cFjtj71yZy5q9b5PO5u 7ZKfve/2DgmRZr/b6reY8bosnMmuufxOt8nu1Ez3P/Pmtsxsk+Y988QT7p1yFbQRu0kz+V1mE/Qy q2LcJgvR1eVz282R+GZSq2JWLNpKLMK40ITfh7cwBvJ1v99sNnP9TOhVrTGVJLPm8XpdmiXS5zfD muQdaDuwUyAEzNADzGTsYjnyPXy8Tk7abMFlM/rQLF5RFfESb3vRrzRvBgZ5LRaLwmO/WY3WIiqh VUc1NS6LYK6aAZrk6NC9CaSqlC+/x2umJmZRBE6Qut1Wq0Pa5axBEj6v2WyxAA4Ejho/QOvzYcp8 x+cxm60cCW4JcPwmn9PdFGmLxB8gGQtu4B+z1izjM/lcDmqB/N/L0ZqsJC2/2ap0AnZpMmGEpvTC 0jseeNRqi5x89eXnjTshQpno6JGvaiavn9CQiYGAMCIM3udym+0y+PDnNwwB8lQKJi8wQNGgWBUv f/D1dz9sBGFYXaBor9lqAYp26dh++HEDzznl5JT4CKAQkJ0IrMhKER/4r03xLqInMFzkDaQOWgLW WyEvlcTCx655yB40E9Qpq8Xu9fjMNrwF3BMFz2Rzg9RBaX4TkRRkZgdy6tqhRdFmkM9z5PjL53eh V5PZijYtJqtCZdAdfnk9XrvFwbaFS/idXrMdpIp5W6DUWqyax+THY0Laht4p3El9hEgxANAHaBBd WNykRQ7IonkixRgVNkZZRGrGDEB6aNkGnum2mDAaa2bBoWsemG6OiLjlij+dO36kXQgOXFMZbS6n 22EnbwM0haIxHvBetvObQcBja7H9KFhkBcH9sSq0Ig4cKnWazO6I6D0lFR/PXQoFzWey+SGHcB+/ baAArxl4oJkWbMlcn1vYFBnbbIvZV1IDow2Y5fMCq4DJwG6PCBXIIqh+VpPZQVRWLk6iHxDV6vZ4 8QBxyOOx0DYh9uN1oIzICyK0WENYXZEAfovFDEFrIoEAAU14Gl1QaqlG8Z5YG6KAolmLw2d2eDQr 8BHtevxQrdg/2L4bg7MAgWU8fBL4DSuT301+qx2kKXjmFSNONCkMCsIWGA/BAcFj1T0hJhPUKoV0 eN9sxR8+rwdCB9LR6dbcFpuNtIJ5mKifYbwgbzyJkUO6ktqgWvrcpAXR8diJ1+nzQ22AhENjPovm jbJBYSBMLBDdeNeirdmVefdz73+wYANIE4zE7QVXoedYjcQM6HpBpICQWZQMiqyk+HiH2Wfxudol JYjbBFMFcF1cWDxhoa6hoGESLcfrwXTsQSb0myGs8ERaQUAxVVC1kBlcHeADQNZ9B8vq/BZbXHLH rt3bte+UlNzepVl35RR+On/ZX+5+9MvV2+pIa36QCvBIKZ7CkUWpAyaSkCmNTF5iNRVHv9bs11Zm lNz45FtfLFgp3giqeqQ/K3Rcn8VqBvWQpQuhoBkLRQwIWzATgowkYJYfXW+GDoyOIRBFMoMV4B7u czhWK9gOBwLGBukGOrJbRYkTnoMfs8PiwTvgOLiL9kCjYBHi+SBhokkLbhoeFZFV1LlJaFZwjDU7 Mm6Z/tqHC9biEZsGtmB2e9wctckHDgqL10SSBxGJggmhRnXeHxHliI6yWnzOtLZJiv2YIH8pysEp vXaHSDW/z+kEQ5XJUunUXbeh3ppfLxb/8oLNUALEhQXNwEoHI2SAZuo/aLA1Kvb71RuBu6KSYP25 ZmDjUCJgH+HirEVLnRZbv0FD3cAHiBCBNLQ6ygMyTSvEhAsajRhC8KNxvaAkOdE8sQ3ix2SzNAG1 yeJpE1LSiMUm5CVGPWw94IjJQi0PA6MVAdOLQg4fIB18cE7N7DRZMCS+RomLB8xAUzoExHstThXs HZq9Zkho+E+ITbiF4XG+on5B5tE1CKQyaxggxoOpQC5YLDaR+ro8FhMvZINBJkUlDloZiRlTxkig SkZAcFrMFH6YpthmlNZoGTIeI3GZzOhdF75gJ+IZgeCUSYPB2CDBnRRNIDh26KHLxxDfJgvIJauk bP2e7O25hXDOYsp+C6FN0vaQHiihQUh+KyiC85LfyfERX378zw/eef2Egd2pTSrHBtUQaAMmvOYB cEx0QCn10AKphrvKzRr+/KYhAATQF9lPfwK1SVhHUdGw0k4++eSXH7/l7afveePZe7/753MvTJvW t1fvZp/51fc/+2zWEo9gCGWLwIc+BitQ0dwMqhQuoeuO2M0gIVmBinsOFO/YX7gtOx8o59OolqEB D74C1UmYZOYe/PCi8qeA6HQPvbEIVB/VdwoGaJoUo6B+c5Pb06xhADZQGVV2mlCaBTdAleLahNwm 7WNrxKSBdnxmcgz8CPPAkxSQVKxJnvSZKjolr6BwwWP6VhoGn32oYktu8dbsQvGtip/DBvcGNXlI c+4kUCCbwbRIg9BthUelpiR++s7LH7796pB+vcBvQIYkNpqYFKRq4wSKqN1BD42wKh24AIE+Z+Gk v97PMRVsyjUXxAUdROIxAMc0QxQBWcgcrRBv/kF9+6a1aePyW5b9sAdPUD8RRxkloKhIuQdrc7Ly 0pJSTxoxCkLA52rEguNFLw0Fm1WLEDuaqAOPPL5AdwJ2QuNxRNCXpkQqkMNl1WpNWr1ZgwQlokNr pOKI/qDvwSunNZno2UcjfNhiAjpyoWGHUBHEdRNe5HagSFDlEqS4gkiwKY+dIIpsGKjBULbpyAqs dZls0LLou2jyw9jU6oHuVjZIgeSDgUTbk++LD1GRE3U9do59L0VaPruVvkd0AWJuIlWDDCBKrSBm myAsTD2BohW3ZJeCRKt0UPE6OpQQwrDRrohhyD8HpoYtT/AIDQRDqlSy3CQTsbugUlpAloSMYgEQ ZfC04Dscqc1mc5OZwMHDqi84PfATC2klf1LsgvDMNsAcbaIRAAfdwbsiTEF8m+IsVR7K8Oe3CgFi lga8oj0h601tihedjRavJ9LnitG0eE1rq2mJPm1st8R/3Dv5/AnjTT7zJ3MWb8gthzUkfg7ZPrMS vYF1wCX8CCEQ+4Wlky64Ge+H7uj1R8SCymS7DrQDTwsGQDMRhAwkRCOC+Wp3l54g8ga0A2sObksT PDKQTxLEIbRJsSzb+H6bHY3oHeH1gEuGnADuBwt2GISTsGt2ZwQHiC+WRGqGg0f3LlqgSaPNRhO5 ENrE8zTEZG8MI2ywRLltEV6LQ11XNOj2gnNA9YTHFZRmh62oXiSp8Qtlnd2vpdg1yEAIW/QHagSh gejQCOEm3eEV7q3JLUWxomwI4/yVa5rHdI9NwcSAjNhgwq6ovEBfoSwBZjZqphte/GBb5r7rLvkL bn7wxYw+nVM/eHQqMJvYw+exU2oGRj7/zrfLN2w596JLopOSPnr/7f4d2rz62B3RYs2gE6zKpt0F a7dsLis/BLRsl9rh9Anj+3ZMNPt8DrjJxOGNZ77fsHvTzl01NZXRMY4enbpcePrEFAfc0TTa4DkE Zq/YvH3Dtj2VFbUJEdED+/WYOGFEcqQNdg3kWoNP272v+IddW0sOH64vb2gTlzB0SJ/xJ45KtOs6 IlAfahoQ98DhmkUrVxccKPZ6fe3bdoyNjvOANHxNXTrGnjFunCC/DTPak1uwYsXq8oo6vzW6Xds2 Z40f06dzAiQBaIsuGpECAgC1Mwb0hWklWiF8CGZLg2Zas2XP5u07D5VWxMXE9+/d44yJo/G+oC8n C/zekVmyYt2Gw1WHoBGmJbc7c8K4fp2B4dj6o1IG+vng65l+n/XSv5xX59fmL1q2Z28OvCPdOna+ 6JyzOsYo2Pq25uSu2V24M/8gdN62bRImDukb6W+OMGuXnHtuoo2D/OdXC5s0y+V/Pj2/tG7+vO/L Dh0c2m/AxReeCm718dffNbrdf7344mSHBf0qNRNzX7khfWtG+qHDpfHRkb17dj331NNjHRo0RhW4 5Xa7bTbxkIQ/v0UIKB1USNwjW9d+j8kGDvvA3/+5JiPr4vPPu+3CCRFeyAAgI98AAP/0SURBVATx dUB1M2mVmnb9Ay8VHK4YPrDPq7ddHgW+DLli0TbvLdySvrv4UHFVfXVyUsqAXj3PGTs2wSYk4PFn HihduWXXruKyjdt3p7VNnXjSmCiPx+qsu+ziM+CBA6nuyCnctj2joOhAvas5MTFxcL9+40cOTY7Q sJknu9fQiemmdIvAgp5IstF34elvgLBZvjUDNHiw+FC7+IR+PXueevK4pGj1OuxAqsV4ZntW7qq1 6yuraqClp6WlnTLh5D4dEsDi4EzEB7sI//xqttXmuPyiMxtcvjlLVqdn5Xpd7l49u59/zsQ2kWYQ zs7swtUZudv2FW3J3t+xXdvTB/eJ9jRF2bRLzj8n2uZzav63vplni4i9/LxTDhRXfbdw8aFDh4b0 7XXZxWdj2JB/H81Y7GpquvIPpyfGYMPPTDeJ8MOlm3Zt351eWVYRZY84YcBx408ahcGL3xMf2o6Y B7ZV9A0Hw9/2q0PJYyrY1OzFOBaABC022ZflNY/X57SYb3rl0+17sib/4bxTTx3xt5seMrtdbz92 1+DObYnR5PJet8Wy361dd9MDDq/3pVee3bhn/2uvv3xc944vP3J3FGSAhUj/1Fsfbdqxx9nUnBxp bmhsdtsSYGP97dxTrrngVNkspWLyyIvvbE7Pgn3nsHvcTqfZbBvQucvrj9xlp8z112mmO//xwab0 zAi3KyEqqqnBafY0H9ezyzOP3Q00rfdrN03/R3r+AQtiHnzeSAs2mVyNPk+PDu1fuf/etBgbduyA 8GDZCzftfOmdL5pc3hjZ0G7yWRD0F2Ez27zNqbHmD//xIpAGrT319tdrNm2K8Lsi7I7GRnhdTaZo y5/OPW3yORPjxXiDo5Zqp9dP20ysXAVRt9cHpaukyf3YP95Pz87z+1xW2EBAP68nPjri2YfvHdgu GnKxBjB545PV63bZ4WI3Od1+7MDZ4PK5/KJzLzlrLNRhp59b3hddd7vXHP3otOnPv/hcaelBzAv6 mtNiiXdY33jsvl5tojHa976Z8f7cNc7IpCY/XB7NSRF+a3O9w9P81gvP9WqbCO5wxqSHajXTtCce fHr6o676xmjNnOiI+OSfz4IwLr56Cky056c/cVx7CEHqnlUu7aEX303Py29uqo+KtPlczdgLiYmI ferhBwa3j3TomhD3CH519BMe8M+EgHJr0WJBCBV1OGwNmSEA7nv+7Q1ZOX88/9zbzp8AnRWeDnHr wL63gLK+XrHl1S/mmNzOlR88Cx2o2qfd9+SzewpKIXkcIigb3N4IR3TbxJTnH7mrWwxZzFtfzf9i 3uJGW4TJEYXgQmwmR/g8DnfTe3+fntQu9vppz2UfKLZ7/HYTaM3S6HKbHLZObZNef/iBdlGygayY luxKyXh1nISKif4ONnrve/Xt7Vk5DrMV29pmp8dqMTkiHc88ev/g9vBTQDCYyz3a9Pe/+mHT5ijs imGPw2dxwUdqMV3+x/NvOOvECO4FUr88ecrddZr1pekPP/f0Uw0Nbheciz5sDpiiIiOefuS+ASkx X8yY/97MJa6oxDragKZ4b1OEpzHS63712ad6piWCuU2YfH+d1//SE48+8dgjbrfH7vfF201f//Nl cWtpZ119D2LE3p5+X7+ObeE3YfSpS3v42ff25GeDM9hpNSLe1J0U5Xjm/ruO65RCX63E0oH1yCah CpD7mcv7P/eY5bHHHju2g9JtDiXiFJKo7RT6fzWbmUb6wo3pxQdLxgzsO7h3x9xDlQdKDli9nuHH D1A2PfxqWLZvVm7dsit9zKABZ44dnHng8Pad2xOiI849eawDG1Sa9uwns5Zt3hYbn/T4gw/c/Nfz LvrDuQkdum3csTMjM6tT5+692iVhaeeu3zlj0bJ2qR2fnvbotRef9ecLzu3QqbvJ7Rk9uB94N8y1 BWu3fLJodbtO3Z999P5Jf5z4hwtP796lp+ZpGjl4IEaSX1L+ybdzxp9y6rVXXDHpigv+ev7pPfsM 2Jadd7i80t/YNGpwf8RaoJe8GudDz77o1GyTJ133wI1/vviC09t26bNx5w5s2t13zz2XnHdmXIQN j73+0ZzFa7cmt0195J7bbrzsgj9cdEZq+26rd+/clZkxoFvXDm2TGfpFrwCpnvEc8FDQv0iAYN8X AHn67Q83ZuTEJafcduOUa6/645jRY+NjYnKzMhNjIo/v2xUS5YWPv1u+fnuHtM733nbbjVeeed75 p6e077F5x04YrH369++YHI+NQZh0H81a3Oizrdu8FWR405RJ1/7tkj59+27Zk9PkdhXvz5t40nCM pFv33v1OONFttuUWFvbv0+vW666aOHbkWRNP6d2hLUCHvt6YtbLZHrll+waz3zXpskvPmDC2Q2rb vn26gX6+mLsQ2w9nTDy9XQwgRD1x+msfbMzMjYlPeOCuW6/884Unj50QGxOdkZmdFB87uHdnxAWA Arm5/qumpGNLRb+51hSHhMyywhPCaCYEK9AxuHjD1qKKyn69e43q2w3WDNAAPgru+CpTPirm2+Vr sKk+sk/vtOS44vKKL775ZvzJp15xxVXXX/GHP15w1oABI7bt2lNcDQFnHjWwKyRTxy49jhs+3Odw ZO3L7dejxx1Trz9l3InnnjahV1p8cUnFV/Pmjzt5wuTLL7/m8ov+dOHpA44bsSkjo6yyyt3YOGxw X+5/GFsYYrIw4InbAoz3IO089cb7W7Lz4pKT75h6w6TLLzoFmBwVmZObFRdtH9KnByYId9QbX8ye v2ZTm3ZpD911202XnXfeBRPbtuu5NXPP1m1b+3bp3i0tGb00mLS3F6yqs9g2bVhnt9quvOzya6/8 68D+A7fs2F7l9hSXHj5t5JDu3XoOHDoccZy5Bw706tnt9inXnDFm9MQJ4/p2bavcM/+cv6bB4ti9 fSucjVf+7W+nnTy2S4c2A3r1gP8Gd99fuBqDueDU8Slx0NKp5T/+6hdbsnKSkuJuu2nqdVf+4cSR o/E9a296akLscb17QJcWnxE34vRNxV9zkOQvoiPLhpPSd4IfYIzafaW3HDHt2H31esElJ5w03Gxy L1m/qco4uaL2qxYuX474wnPOmkjMojMTsbUOSAj8FB5uWLR2i9cU8fy9d41Ki4YtkqxpFw7rccUF ExFPMWP+YtXxrn37PSbrGSeN7pugJckz5wzpe/vlFzF8RfrKzCqw+y0njxjWN8EcB+e+pp02tPeN V/yZkX6a1jOtzbcvP//4ZWeP6RzXSbz/J/ftfNk5f7B5HNt35dA9LT9rtqQ3u82jB/a5ZHRPdCG9 dDp1xGCfy3OopKxbfCTQKre8acHqVXaT96n7bh/WOQl9pfq1C0b1+tuF5yNy95vZi530FIKuCTbu PQBKFph94o+UE147iqrWbt4VafI/c/ctp/Xv0NWqDUu133LhSf+cdvdZI08Aohccbv5+5SYEpEy/ 84bR3R3QFjHgi0d0u/zsUzSb7fOZ88WvQoyFKen3uttEOd6f9sDFQ7r1jdVOH9Tp9qv+anG6d+7J rpV95sRI65ieiX3bJNtdTWkxkSd3Sz6lR8fhXdIwF1jDavPM627Waiv+/sAdfxt7wumDe11+/snK UMbuOLcxudfJddyOke/abTU7n7rvxlN6tekdqQ1pF3X9Bae8/cwDp4w8TmmX+mH23xw3D0+oFQQY pUSjgOJD7VrIzhhcLXRPMuYPcYU4GoJgD40O9i6pcYjig9FfX9cE7OqdmPzNyy89fNkfxnVJ6KBp 7cE9ere57IJz0djWjF1oDW91iLWM6pGS1iEFG9BtI7UxPaKByUO7JkabtT6piTOef3ra3/4wqktK mllL1bTxvZIvO/88WHW7sveC9csmFqOg8YNOle9UBDKjoHYVVKzdnm71e5+659aJ/dp3swOTHTf8 8eQ3Hr/nrNFD0TVIJ+dw84IV6yLM/ifvvnlUp3iwpo6adv6orn865zTEms1YsIC9CA/kKT6PMznK 9soj910yoveAaO3MAR1uvepSxERvzsjAJkh8pHl4zzY9U6PtcPxERY7rnjS2d7vhvTBwpSGA2LAB 7vHVVT17122XjR981uAel559OqxGUZGhUPq9CGWQczUQybsLS37I2OyzO5+++6az+7WHCjCqQ8wN 505478lHJ4w8gU4TJQrkVC+YG3fsfs3oe4wF21FgoS6Jk1ppbVSL5KJd9lTG9+vSNiGuzuVdvC4d f6otmXW7c0pLS7t26DCgZxoQ2u9BhKKc/VCyZNOmZo9/wHFDOiVZFWcU17A2YvSYJrM1s6jEKYdd YmNjcd5wR/ruRnWumu4LBlTAFeBy8QI8dlaTLysjHQ43FfuAqyAsh5xQgxhIjbNG4tic7BaqVe7a qSscBjWNLoYwybXisnJEPXXv1okxjhIOjy+dUlNxRq380EEOz6+t37ar0W8ZcPygtEQaJowUEV4+ esQozWvLzi0C5olDzo6QfAaq4LdJQ6gMfC/AU9Dbig1bfXbH4F49+qc44KmP0vzRGKfPDdu0Y1sI SsJEs0cMGHx8chv6EDAXRZajx4xFxPHe3CKEhipPr8fldFhMN026smOsFuH2QQRCXA0f1BmgQJzU oQoJ7pGfSLMH5pTmdgECEZoPjyFcWvlqoJpE223X/umPg9qmwEcUhcHIK+K/UHou91TR1tptuxDt MhBRbilR7Mvrg8cJr/RMju/aJl6hBIN+jPO2Cs7hz28PAkb4cAuWqcIKZRdLZJ1gF8LPqSEhQAIR jXY7iL/JhYAPDd6atrHRSubhozC8U5fOTo+7ug7xYWyKp2S4WeSGk9BmxpYcH2aMFyjJYm4bGwFk dqh4aXm9a9duEK6HyivEC8eDAyBGbL3DW1grphV2+7wSJLxy2y6XJQImUd/kKCAwfoQoPD3aJXdq kwQXK/pYtWl7vds/ZPAJnRPUATjFUrThw4ejw+zCIiQu4AkcOScA4rr1mmu6xNhAEdE+DZuIJw3t z1NxJltZWQ2Gx61xTyNELXyE1CkFILKhTnBhFx8tXHnJH4/rnMzB+DAk+BgZIU63isg+t4cHxvFt 49Yd2AAcMKBf79QYkGG034s9kRjN17lNQpeUNnp8mTA0BZZfe8KEYyzYQqiR8kuHU0DcGYBTdpvX 5SWvhJ00ZozPGrFw2Q8KU6HUzFm0AsdGzp0wLhp2HqOIbLADcLgKDYDLZ+flA2shbGasyfhs9a7P VqV/tjrjsx8yV+3e32SPrHa5auuxy6udc/K4mCjb+szsyY+9OnNLbqWEQqmjKXYHVDDXOWedhEi9 bXv23PDwa3O2FFRL14pkeNSfxwCI37ieWeFalVu2PLtsd9EBl81f52ki+xfGnZSQiJQE+YeKacOZ 9dwoublFkEfJcfCok1wz9+d7rI5qr+nrdTmfr9792eqd76/c9cnKvWu37LNqkS6Xu76egSKgqHfm r/j7d8uf/nrV32ete/67pW/NXphfWYspF5SVI46/b/fOQGuiOw+NIdbfhpgLaL/0iObva3I1Nnp8 8zfmfrp616ert3+B1AOrd63cva/R6/B5bQ1O7gyjKXAKzdeUGEtktoD0eZxGizFpEZE2HLeob6il zBZdAWfkeaCb5+bkUCDOACk3BVfEggP0I/oOAJGgOWgC9B8pqsAhPETA6qfUtazcXIvN0a9nX9wh F5Pj6tyR9/g4EZyYwOEBHvhDUMovh40hiBn++t+CgC6/gjs3dMaAFxOzcPaM6pCfgfEMKFYBwnBX uN1eq80cE+uAgoj9N3i2QaTl8ASUN68tqFiaeQiR/dGxMf5mJ5UqSZgB7MWxG4RrSaykQmYTXD4g T6cE8WKHPrPctTa3cklG6Z6CwyZrtIWygKwGz787d9lL3yx96bsNr87e/PSMlX+fsaCwto5s52AZ jtD06dGTB3aU50msNOW/RCgk/tx3oADHohEPMmtNzpfkTrs/Wrnz01U7t2Tk4PRCvcvX6CaZM4jR 5Y40O1KiY2Gn8nwtRLJJA7uzm+xmt8VZ50Yv+IGcM5ltHoucalAyhyRGHSDCakOXQ/r2k1A46us4 EYe4D54rxVwQB4MUE2aqpvjszymxeKy9O/ZUzFhcvjwtAFLFWYrg6VTCkBzGFjwy/t9Cl/9Tv8eY lQQgT+AfdWAhV3FQErgIbWXi2DF4dl/+gayCKuyf7a/RdmbmQrU6fcwJyrZj/C1O1POQADGvrqnZ 5/bs2rb1w/ff+5D/f4DPFx998vm770R46hPsflhi6L5rvG3aPbf37JJWWFz4/KtvXHHz45/OXQuN CVEbiGa0aeYO8QnPPXxvj9TkkkMHn3/9zUtvevjTuUsbGQfPjWGQYXZFw5NvffLnq26/484HHp/2 1LTpT33y+ccgMzjilL8U8z1p7Ah7ZMTqTVvmbtoBFa9G0+b/sGf79p0xZm3M0EHczAMdVtb6LfaM Pbvf54A/fgcj/uTTjz/96NvPPoSfIdqiRSHIA8FUzd4vv/l6zty5i5Z8P3ve7LkL5s+ZM+dAQT56 Ka+uQcxMYly80gPllB224RBJSHLCT019nc1m3bt391tvvQVooJ+P3v8I/37x8ftxmjeaiV0kLQqE d5MTZ0g9HrdK40VZJS1gM9mKJZENUdWmz8/Tg62XUT8xg4AWD9skINhC6IMw6/AjbEtrbHbC6xLl YAoJ6UkahGkLTiBuE+wxMGcEsqOFP78TCEj0r6AczTJmToAnQKGFRCQKZVHWFJZUkva9nqSEOMpA iym/qvmJ1z66cur9N91xx6NPTHvmmWc+/uBDZ7MbZ1KJbwyHZks2ix3bYkw4p1xE+E9C8LOr6p57 /9NLrr3tlrvuemT6tGdeeP69Dz5Erg8cPFM+9vo6z3czZn7//WKQ3qxZc+YsWLhw0ZLcnH1A1Kqa Gpz+jI2kzYfdYx6+FB4gZ2KJ1yCF6poaeJcydqd//D640kfvghA/fv+TTz7+8sN3EhAYojxGIkFt FovP3Wxyu2E+6ntaYE1+EVfYURCBBEBYTAgKIU3SzSOEL2ceJN8QUvZIziXJeUTo4SBU4Awc9jL9 brekXOG7DU1OHOMFA9FRDCTnhekop55E1xSDUz485oZmj7Fo+A+jtm4vH6Ne9ZRaAIkRTnQEdASh JY4EqWcQ9Ur4dU6OGTrwuK27985evibt6vO+Xb4WZ7DGHT8IUeoMq+PCMHEiI94VC0ZIktU8YdzY SWedbG6qxaraLFYfwuuhh9gsUQ474siBiECjEV3aDnnsti3p+2d9v3Lj7r3vzVq0JTv3xTuvQAAU EBEoNbpzuxOeumfVjpw5y1dt3ZPzwcyFu7NzsE0Vq2mHarRJj0xvdLlO6NHrzJNGt02O8znsudUN L732ekJsDNrHSPAbhj18nhVezwtvffLWB9+5GpuATBGa97pL/9I3NQbwhSVnjYhyu53njR321/PP jGSWBKTs0ppdTkhEhDwmxUbHO4jriRGWN554pNHpcvGcimazWu1e33FdOgNYERY7NNC6Jidb48E1 QWWFzRKvxbwnvqYJJ42/7rxzHM5mnn+lKYbOLEj5lRyX0DaKx+LomcFWJXbDTRBikm8FZ/r0s26S 0EtnBGIo03nk9vjoBZKMWkzcx0M6JE9Ea4sH31jhwEpDpBlLTLSCzcdYGDedvwyX5UlxSS1GIkRL ON2II01IStRiR/YYIWS4mf8lCChNEHFRghdUhoCQyG+l2exmBjh4vAgyJEcSBJOg+X1Z2JaLcUR0 75gKPpBX5b31/icavK6eXTtfO/a89knJFrM9r7Lh+U9m+iywz0gOeFf5w8HubZod3+V0AZl/UbXn xkeeq2poOKFH9zPGjklJijFFxuaWO199821zJN0SkBltY61vTru/sr7ZaovGeN0wKE3eIV06YMwO eCx87giRITztxn8ZGU0ykawouGOxOJBe4szxJ110+inRODPmdZpsoDv4dLwOky0pOjEJXEnlPPG5 /B43DtwKJxF1z+9BsCVkLMkOd9WeBe573Aywkj8BHQaNSt8S5sFEj2ANwnKRHQzeSoGxLDuUcytP H8ghcBscNm6Pq1HyQ2gutxeeGzlXTpGG3BVMF6HYttrKCAkC/F/CoZ87lmMnlpWSryelFhQLGG0B SCtc5m8qSXbJV0blBUbbuFF+r3P55q0H3Nr3q9fi+sXnnMngd2mHKgXP9xOnAHbIFXx3NTk7JTv6 dUzpl4Yt1liccuuXltw/JaFLHA57MCEyWoY5CBVlwsBu0++6+pF77vDZHFsz963dmcUFFCcnYs0j fdqE43s9dcek++6602yL3JiRtSm7FMrd5zNm13lN3QcMnP7w1HNPPn7koO7D+nTs2jEtwk7fifK0 gtg+/Xxu6eHya6+edPWV1xw3+IQxY8Zc/IdzX33x6fMmjBQshFalpSQmRiHawtnYLSmqZ9uoPu0T eqYkDOqY2js5vm+7pDbRTJWoZHy/ju2H9ewypk+P0X16jOzRZUjvbhHwwiImJQ7+cO/BSrpE1P4c MusIyNXBGK1tSjvIMLjduyTZereL7ZEc36ddUp92bXqnxvdvl5AWxWQ76gOh4nRDtKjTRDwgh67F 6W+HhqtIVOE1ExnAn4EcRMbCKbOMHAS+Eeh8Rv5ZPBC6yPK4nlQ6Pi4ay11cVoEuOGKmI1Ibjcz2 wC+QsmhT0r+GP79lCCjEMjBIzRQk7hasox3Dc4/MkufCPoEcwZ63bBWOb48fNoQb7Zr27cKllW5v 9x69nnrw5vPGjUbE1rD+3bp36ADvQavcNR4PEi1oVjvtHiKnyJJv5syvaPb0G3TC0w/ecu64oWMH 9hnSIw2749CHsRmvNheAt306tx8zoMfw3u1O6NluVO+Ow3p1cUCPBom1SUCEfEFxMR5E2g81E7wB L6pk3eOf7dok2yym5ob6HmkRvdrF9uvQplfb5L5t2w5IS8V2eNsYJu9RXhzoe/YIR3Oz7H6IjFLC ngmVkJcWufmERyFVNNz+GKDy8yvVkIYp2KYd2ivSdXHgYjtSN8QeilJP3TD0mMtVDxeIjY222i3F pYco5LhzSQcKtxjQrNUCQlYWIZMxHVtj57+E0MdOsAl09Z+QyQSuSTJDgZ3ijJQKDMHAEoHFjju+ W5v4yCqP+4lXP29sbOyW1q5vp8Qojk6ywzOKEl5ysmAs8KABfZBKYHfmfjYuubFUKhueF1HqCb3M TMlB3BMnQ7zmGz+g3aB+3XEIrKL8MC8r57sXLn7adhCB4/u2PaFfHzga9x/IRyNFpQdNLu/I/gNx i35wGbaHKXEcHpcYKuJnz8orRHatIb17/G38gOnXX/jo5Auvu3BCr2ScZubzsG/w4vG9ulmczuzc QtpbmDI2F0Ws4jgdxoa0zRaGYlGWgBDp73ar/SdYNaR4NDWgd1fEjm7cnVGtR8r4bPDgaTYIYMg6 TLNn9+44krM7M09xC2R5xevAevSG5ATc0xIUZ+ISKoNetUkgO2iUK/iOJJpmS6TVzBh9Jm6hoRmB Az819ZIJDOsAKWfi8Ww0ImlRmEUaA2aUNv0y3KiXD8xFREVCkSUEjuvX2+VxbsnKrZHQf0mEDVr0 Oy0mBMggpAVndIgPSs8Of367EFDkL9QKciY7Jg0iu5XVbrihsbGNUwB8Atvh//ji+/2HquJN/svO PEOd9N9XVAS+PmoId3YFvYWd2204fyxZToUipZcIB0SFp7K2Sm0YA1NBennFBcC/wX17IfwKLhkJ KpEsHnCLMyk4pSmPGYh4A+0hVoVqIxKsyjmwnt26QSn8YfeeSiEqiUeRtLHYiReDCUTUq0tHdJGR l4vxq0mRnOE3gVtFuSyF45ISzfYGcLFInMslxfIYqwwSCX2acEKVBqf4hOhttFZX1UpjwjjFNiC7 cznhHbE5qA2obC4IQ8AmCh1X6N1sZZpAEXIYw+A+vXFob+ueveAYHKjUB0AkApxmtczkhBh1joup gjBZL7PI6kbIrxMhj6lgM5R2tXzCkPWF4B2Vk0YtDr1i2AmWZJ7C/xAeN27kUAT6pmdnwhg/d+Kp DHyC4iISC/gEhQuZKfAu8G/cyBMSI2011ZWvf7akmliFk542YFKz2ZRX0ZSeV6wSgX+3cEUhIknk EBhSRtX6teIDBTaft0NKqmKi3yxcUtzkhGIIpwfWu8anFRQUmL2eLu3bY1DxCTiq7N+3bx9fly3r ohr3m2//E1YRPWmiT+HTrl07bMQ+O/2pf77/7RdfLpoxc+m8xauWbtqWX9NENBUgTBjeD+H1ZeXV r38yF9157BaMFl+cZq2gtDpn/wFxbPB4j5L8CN+iSPIjeZXQK1oYMdTu91TX1b/zxWK8W43pIOVY ZdPDz78xa8FSwOSUMUMT7I76mvp/fDgb4ZTI2gViazIh3Yk5/3B15r5C7hcLUYAYHA4cfFdBnXQJ q3XjuYKAn12kYFxMLOii6ODBMo/WZDEjk7H4gk1MskAfJrcVdPprEffBWBJJ70qxPXbokBiL5WB5 2ZtfLsKQ6s32Ws1WUNPw0Atvf/ztIu6zib6pq/K/TioKj/pfQiBUow2wBZK4pHECeYIcgNX1JhsC Q5bu2Hf/M299v3SZVfPeeMXferbFnrn46uNjsRm7NysLxMFEWSYtv9r94ptv6ZgsaIxb+J0U7TB7 nfsPHURtLLQMxMP1hLiYCKs/Ny9HpXbDxYN12iuvv8G8dpLqTwYpXEvOSuMfsSOhZ5JpTRwz3OZz V9fXv/nlwjLQr02rNZsKa0GDr82YvRByC/LjjAlD4C+qqKl+6/P5oFMwFvwgpR9+F1Y1ZeQXQJYo XGdZAKR7hXHKD931oEh01wxPDAI6xITDCJKTYj3u5pLD5dVexejIi/iCcEV88SBknFqpIYaEzClz xSCDG4YKNMhw5MhImxWZUN78bHY1Bo8dfYu2v9r18Auvfj17Pl6hExj+G4n/Nttw9FaFN/xaP8fu gLYuuwAIAp5/iceM5jOdXZI8kZmIGRG0cP3GssOHR/QfiDQfImMQbmdKTG0/e+ky6AzxZst9U/+M OD3eop1g3lV4aMO2bUlxUedOGA2u6rBoKe07bti0eXfu/iWbM3LLqrftO/D9pl0fzl70zlffwBQf O2QgVuXB1997f9b3OcU1GSVVy3ZnvvbRF9U1tb07tL/hknPRCKjiydffeXf+ws3FFXA9Lt++/+XP ZiBouF9qu6l/PguokJjU9vs1P+w/VLo7r6yg2rNkQ/obH34C64jpKL2ev5x/GkQvJthzSP8f1u+C SpWbX5yemb1zX+4P6ek/pO/5ZvHKosN1o0/oz61mi9a2XYfVm7fvLTi4dHP6nkO1m/cfWr45/eOZ Cz756hskFhkxdDAxVYFOj5aXg+2i5EGoI5WI1RG9ZdfuvQVFs9fs2FVc/fmitR989e3B0tKRQwcP 7NE50qy1a9tp/fr1GSUH5qzbvr/MtX1/+Zz12z6Zs/DTr2egVMfooYOg4SJ8+YvZCwDas049pX0M 8m2yAyAxqGXmwpWNzuYzTx3fJR4ApuLmiE2cs3Rlo9e7at2WXbmF73719ciRoxMd3I34YP4Kj89z ycSTkiNpm4rPn/si2I77ct4CLPiZE0/tiMBLrxYbCWdmBA7OZ+0vnL9ux7aC0q+Xrnnn8xkHSsvH jBrZu1ua7IKwiIK0IlQb/vwWIUBuwIIrXGKVNxhm0NJ1Ww6UVe4rKZuxYuMni9Z+NHf5h7O+X75+ a1lVeXy09Y5Jl51/4mDmXUNgBdwqyW1XrF2be/jwroKDB6qblm3e/doHnzabkZrLimysk849GagJ yYGOEmLiFi5cWu71L9u6Z1teyQdfzhw99MSOae0Xr15RVFa2I7cit9r3/cb0Vz74GLlV/TgAo/n/ dN5EdVZH0kmJUcMPCQHcCYOOtcOmsuzYm7krL3/RtswN+0u/XrT6429mHiwuOmnE0L7dumBqMHja tu+6bvv29Ny8RRu376uo37aveNGmve/MXPnR1zNNvuYRJ5DSIVk/XrDK53b/6eRxaXERjAdh2RAm Evt62Xpnk/P8UaO7JDMHUGRc9MwVqyubvT9szNqZe/C9rz4fMnxociTTwb8zZxlk5IUTRraLjabV RpEOyxVGAzMFfrRgFY6r/nH8iLQ4xFriKBC2/xK37czIKjiwcMOuTXmlXy1d98HX3xQfOjR6xHCE W0vsjBRCQaQ4HUUUm79eajx2gk3XuwUVlGmg4kTEmpbdVfHeSUD8+q07DxcXjT9+8IDunbHHY6dy ZIqPdmzbm1NVevAPp0wYM6gXfcCSXAc4tf9Q+bbNGzokx581boxyIHRolwixeKi8Mm///rzsnJx9 ufmFhY1ICDJqxPlnTuwQh40zLTKlfV5xSXp65p6srH3QlTzO008cde/1V7fBGmIQFi0iKSmz8EB2 bkFmRk7u/jxUwzlt9Ij7J12d4mAXiUmx7bt03ZuZfaDw4J6MrKLCghMGD7zvjhvWLVuS4HBccObJ ciRT+3zh+k3bd/Tt2uWxB+49+/SJY086cez4MXFJbbL3l+TlFkR4rYP7dgW6d05r02/w0AMHDuQX Febsz83Oyd6Xu8/Z0DBy6JALzzq7bQJOghnpIqWkAHVZhoPR/Yf4RUR69O/ZObFNSt7+/Oq6hvzC A4dLyzqkpvztD+dfOHEUHCZwIHZLSxx43JD8wwfzi4rzsnMzMvYivYuzuXHYcQP/dMH5baIjsBAA y6y5C2we/3kTT26LzCBSOoO+Q+xnfL/U72w655RxqTGRKnGlw2Fu26Hr9q3bGutqCwoLUBvnvDNO T0LyGErHRdgUv+jk0W1jo/CwSgkOrQWybdbc+YgI+MMZp7eNZsQLPn17dUlMTs3Lyy2vqio8UFJR Vp6SmHTVXy85e8IQrDJjmkW+6kjzW+Tp4TkpnUWkGrm46Gz0vBUUFu/LywUrb3bBbUZPWHx09JCB fc45dfyd118xuEMqIwndKL/BlOTxidHtOnTety8vP79gb0bG/pzcEUNPuOeu69etXBfrd//t7JPh GEfyYhpnEbYOHbtv25t1qKLiUEmJzee75IyJ3dvHpnbskJmZWVh4eHf63sLC/KGDj3vgtuu2r10X 4Xf+6ezTBBXVWUwRvgonJRcJEdmrDerbPSoppejgoQIIhNKyyrLy5Jioq//yx3NPOQm+T5aqMps6 pSX16tO/rKL8QHEJ+FJm5l74gRrqnSOHDr343JPbxiFcmnzty9kLHH7/n884Od4B/kepJh4b7atZ C00u119OPTk1DnEqHrvDkdKpS3p6VlVZdfGBouhI0wVnTYxHXnI/dhyX+V3Nfz7r5DZRiEHjWVD6 YxG6hZ0N6JdzFkQAJqdPiHeAYgm9nj3SUtp0zMvfX1ldk70/r66uLiE28tKLLzrv1NFQHZBwgS4o VVVSji78qgXbscwVKfGuRvlN3cmgMARhupLKGyXKYIFZmTgROgGySBGa1Ax4V7mq65xasoQIYnsJ hgNfwT6YDVndNKgluICT/4gxwqFj8NBGvwZ/X0VZZUNTY3JySnISCw1RzZGNPGS/bkCRbqdWcqgM jrHOHVPjpMwRtRtJMQAvMgTcocoGZEDGbmpax8Qoiwb/O6ufcROAiZhBJBXVbnSR1j4lATgJVwC2 hXCaEmc+fVppk/dPdzyKN7575Yk2SMMqNhcGBkfHJ8vSP/700xN7pT33wC3cIUCOADOPK9Q5/cWl pYgJTkyMbx8fhefB3A1yUpuPFDWSsY2xUyQoRKAg8SQyw4L0TabCstqKqjrMt30y98PUWUAVeQxN ED/w3ZcXV0FjiEmIaZMcoY6+IV4KYtJrM9c73WafNSZSamOIFS0lF0w4mgeCi7Bp2P+TconYRrai NeyNlxyqRv7OLh1ToBHHgvy8Wg1KIrg0pI61YpcavnxUupJoNwyy0cXINKwdjEgEXCHxJYAsOR20 kvJakFNyfEIaEq8ax8ARXwOxrVJl6lsQYTnwm4SA8pGJH4ZBSywBw0JIardbBS+omL3AditQkxvt UugdMe5eSasPnCwtr2uqr09NSU6IZhxgsxshxMRMBlvItjtOhQHl4J/IP1gHft2xTWwyzj0LYeL6 4SpXdXVdWlu8zosupx/ZeJD5nP1yk89QzfmnUTlZyBJqoCKxwsM1DfVNyfFxHZNJwhgjwzql+i6s NnSBcZbXe6vqaxsb61MSkjom4VAP5gh3JbeiMV6k+MFA41CjRHEjRjcj6hjlMiwuN7f8QYmMY2Q+ fgtSTFSUNYIo27SNjrdZ8ArAVcn9QC0SR98QGMkToaAo8aeiirHJAtcl2k+w+Gw88StHUeXMABxm B0qra5uaEMvdIZlh29zO93mlihypUAKjyanCgk2nQlVMOWC9Kkte6rMjSqQ5wso6llQqxIPHQhOA M/6hexjHASkzeC5D3VJxrH4sGIP3aPzJa+J4ZtlAMEHmpMFxa7EJDK+BMGloLBa4P11AAJYtMhJV 08mAYEzmy8IRDoQMMTsaywWqvS0G+PFUJ/+g2iJ1y1AhV2QNgqKUFSp9UeCoQg8bcw7e+Nyr8fHx M1+4F9vRQAW15Qu3/luz1303c/Ypx/d8/LbrLD4PHXZyC2LRqIChM3IatF5W/hWSlE4UOXFWykHH sTDAifPntrKc19GfheyQ/QACW3o3uzweh5WxTQosqjoAFTqpsSAP0iLjXXnP7XHarDxOY3yUfNWd 7GRAxj38SwIK7KgRki4E67OWKLYlWKJO3Dhqo0Pap8RFhT2BjL7pSmEX2FPDBDkQgaqsdfjzm4SA 8t7glySEVOWjsc+E+Hb62+V4Fh8AljCEnkFPpE79OnYA6BwDIZJ1yB6HgUs8cgUhySIYJko1bu1j z8zE6rWqUqB6EhlJJPQP3EVIg0fE+I9RNhq7xYyslBoketuKCvTV4PBI86zsaOSTVCNXg0HJXNaJ VI9xkx/nwU3MniX6Gmtr4BqyEpCCSMVQ8Rm6JUMRWmQpNCl3zAqFClIIHefpbVUPmbo+KZ2RX2JD otaBFJfkLU4dgQg+p9gJMk5W2WZYpUBcqF6q5uBMAIWcPESgytDV+VU/LGPhGxTPiOkKkP2vECFD l/D/PnxZJtWM2PEKR/BjRyg5M1lgFxbFXJjiFGevxGwDmuGotAzDy91XGhBcfrBTFVEhJwfhgFaO AZbNZh1nl9TOM2NbBzafHN1n4CLCBBENCN8dq72wWhtWWZWpZkFM7taRLFh10Iy0k5KajrQAlOah bUaoSJleBLhT7wK/9mhwpok/DciMIYHAEELBLWU0C2RJiU80uRjT8fHSjYgCrpafQ5q2YNe+75Ys RpenT5jAPFuIu2WUJqw2HplUJxxgSPlZY1tQU/wI4pOT5hnZqfATaI35sQ0/jmriCxFWHZfwmljT ml5KQ+JS7mGaUTicyVZ4/BlanhEfjEB7ye5BRNeD+gXK2GVgjiGftxk1dcFtJHIahjLFGyod23AU BlUB/Dw+gaFQc6AOiEWRUUL2S2YHRC8DJBRjXBodCyiXZd3Qq1IA8QVSzctwaVKqjMfqopEXlmr/ dwL8H26BahuxDjwWVSbkcCoCzYn+xE8G1cJqkVR4FGnQdKENisOC8gBFcZkzgSQvoo6l6MEjgKKs c0NiBSXgD7jkpd4UbBgiJfgM+I6KsJcSmqAvykEgN64Q5/2IEIb04TkUor3F4mJaSFUpUJGkkgKq 6Ki4JQ3HAm+Lu0MXx3BaKJ6nR1XCIcjTRIh8hj0kB7MRgAmSBCui/CNfEkJBk0B/DJN1IiG8ARs5 6cekFMgCJkHjPMDOCgEIK+apajIutCyRzzQEATpGM2LbApHSrKNCnZxhmE7+icLIKigMpQaQf4UT ReUgZhtB2Cd+4xCwnGUFz4Q2wAgxbCVyqgYR/w9j1Y8O7Vi6Ig2JJjAMAQo9aRQ2WBKpQU7YigZB cwhsG9xWMXHBNYaekn9KlkRG7VPJCEBZLGQ0IMFUiDYS0SdpsqRXddiQ6hGlmlxDO/jB+rEoO2N6 GeOge0Qkjh+ikWih1BmIWqvDTWGiTm+xITgESGvc+YbBbiPflhppaLrJrL0zb/0H33xttrgjrJa2 0YkI3SyuLHPydIn1mksuvvaMMXS66R8JcfYgwQfVSfVh5TXpCJHDwGspIi96Hz4UwzrZSKogwV4O Sam0AZFBclfwgxyS89DKBqLmpc6rYf/CJrl1UKkCE6PqyqrEtAAltBE0BMNLkTGldlCbA/dgESH0 jCMJnDh4ALRGkb0imFgSXVRYUXYpcdEA1AUstWpdxsZD2WIsBo6yBqEiCxf+/PYhAORmjhnUmhZz TfQkGkhwV6g4ZmKCsmHEaJErqAAFvBdvBs/8UE2VyBM9xkpecrlxnhoShGhEj6M6Pa38DmIiUcET X5IyZIiGyEXH09v8AEdRTgvuBkVE6iPEp95Xv6EoUqwpSlSquPgPmZjKIEXVHEcvxGa0RaGLHSxD cyU9GOwJ3yFKxLIURzwFmAgyXeRzvwQM0tOMfAjGuJCKgQNg9TgSu7AEbgSAD3JvDPQIXxf3/DgE 8UsxepmUJ9kVxC6UMz5iGHOfnWA12J0OMaH2Xy9hHlvBpmce0VFUiSvBJpQVZI4JwQBa4jjABubO zLc4Gy/4o/BYLbPsL1G5Yv1oUAHpgAtMvUswWsx/bJvJKWyE3hmRVjQgVOg4l0Q0KSaZD9rUQBuK MNloFcPE2GgyDtIwYoPorhdjEhNDpT3Eh1KZ5KgjGC6qfJJZJZWL1q9F6UJ3jQtzRTGIrp07nDZh bLvEKJUOkem5iHzsXOXlpqYm7eAS5CgJW9GBiDex26Bw8hC0FPvWyQ0DRlJTO0+IMaOVuB3Ymi6H 1MioH1DHxLtmpI5j8UYGZ+huSOXkIHkKjFmJV3ICIRMIQYwmgOkiWYWyYWLiOViteAESkqohtAhu k8NXD4YTQS4jeispBossmrB8xOCDMkHdg5Yc6UpuUCVWc5dfkuJAeEYLF5BqJPz5DUFAD3wVB0gL /7aYRMrjJtsFgodKQpBORM1ViKaC4CUISj7QH5lklIJB0TyZNqUkZZt6XZAQh7qEyhTtGhJLZWAW 7UvdCPkYEi4g2HAvWHFUR3JacXBfsg1SHMqVWCJYgj6kPWqh2BkRZNdjFymUjJ5Em6fRSdYCXiKa utowEP4lf1EUgZBEtIsmIOQm1KNLbpcJ0aDYXKFHUfEyMitFYGStvKH6lGMGVBREkxZhqdOhULF4 IjkXaqJqx/NX+TnWgo1A0PdmdKe5YrpkrTSnBTmUaULtjEJNKWP4F0sqphadVpRGdGrBI0xE1D3l YqaIh5mSgv5jWU5RPZB31/DTA1PEhtP5KBrQ7RtZX+GjkuM/YBjRu8lx4zb81KLC6Qojv4k+pcxH GYlIJ+Zok0OhaE9lNVVjlHBh8TRySszjimlYDT9bqORXnF5OZlLuyI4ArTA2T4c5N+wE5WQu0pGu ycoTcoxMp3agso0+SLpzlVlHscf0BKKmBihE6Q08iC1bA3xfeIQ6YMDRIsGB2GNKyRCiJTyksDAX QpriL0aEQBuES0MmbBAqGRZkJKmCBCh+I0MRECaia7pCsYrAhbHw/V97erpfJQP4Dw5a5W9TzFoh PzGYqAeNSrgv79DPxqvEXfBexEPC/U5Pt4g+YhT34MGRA7tn3PQiDUlNjsBHiIH7DnpQktoPC+xM q+d06pDvsrGu0D5wTz0VsLxEQKjbohHKVzo/JNWcsvHwW8Yvzj+1oy1uUV7DoQLZSMMbVuZhhVOI 9Kf2zCjYldMTj8IVSxjRG8ttA0wfHUIuG2arjAtDVcNAPnnKbD0rFvyVFO3wQ8lYFGtVz7NruYLj gGrDXgFBYiGFCLkY2G0hO6COGxZsIRhgCLYASihcIeoRgApZiAWKGwpAVbSBZLkmh5XFle0u2ek1 VA9u+8A5qQsd1ZDxgfUmfFo1qQo7GB/VmvSiOmfvQUeBbpOpTSB+DDYtgSoKr1u+QjTDwxybcnuq gQeIAjc4F3GZyniMeentG2OTu0ohNeiHt0IJVN5tqTeJQRYYmDwvCCrD1nsMga0+KaX9CbSFuygD Ef8rF4eCiJJygVAZBSP9TzmNaMANsVpsJugEVo0bH6OpwAXVjt6j6i74l+pGdwy1eCX8x28HAgZK tqAvA+1FxuloEcB2YmOAtwrCq1PU4vVRWKoQSZLhhEZTKqKE+iqshLqvniy8lQUSoHTVeeifBj6r awYlKLQV5Y5dh8g8ffyUFkE6MFo1MJzjl1chr+g0FZbItAeKT4hs4xAlxpGyWQbFqBlDNrF3g00x CauiWSaoo6JpAEQxIx04SvdszdbUTZ261eBFwxZWxlcAtFYT0af4a/in1TofgyG3QBUFGAM8oRZ6 aE8Gl1X/qn1aHZEC37iehggx5FOrNgI9BYRJ6AP6TGXFueumZ91thdktll+9zpEExXBwOrpkUUgJ J4M6YKdSJOiKkBFB0xqsih7kt8Ih0Z0YJKWUKEFuRSHyhZI+5Idv6Q+ot3QaNORoq+70KfIhiMMg bPWl0QNJgiQqYamhRBu4JXDTP0fgfHDV1BMK4Po49WmpWctIQiGtHgp/fmcQCEE5XS2SbaYgwxC8 UDxaSEkUOKUl6tFPugasACf5btQ3A7uOwNIW9B5KUwbzUfzniPdUu8ERGzgcQHIxk9SP/tG7Eodo KIbrFBjsQpEv/1YcUvrir5AYFkNxDlKW2lBQGVn11LUtO5a/AqK3hSQOpcpWSKfYDuTor5sij6Ur Up1jC+VRhmZhwM5Q0kO0Dx1dlBkhPkhlqHGN8ZfSRBQ6t1Cn5ImWn9a968MJeUxCTogKRl86JSiH XGArOdgs3zWabdF9qMBVFo/ybKtgqlD9TpQ73bfPJ0IVwACwjlTxBMtDEVVZdUFsU990q1empGy1 4EX9j8BsQviIvufHNo3MZ7wbCmSjMXlLjh9IFCuUZTXfEGizdyUy8dHvCvsxRmuseygnC849ANgj uElg6OEvvx0IBJfbQK0AoopbvgXaGlJN0Fr9KP+8jj7G4yoSJUAdCtEYdhJ4tLW8CeKwekTHfwPO IZKoBeHr9+Wa8UrAdgwM0lDBybjkUeE8ukWl9uxb+SeUuFYfBYRQYtHluTE49SzC8fCU3FKVWQNW mh7gEni8Fb9tdT2kVePrUbjrUZ76X750bAXbT8004HgMXT9hrGoV1QrpqxNyPSjYfrT1VlZXKxkY +prslkmm74AYk0MtCu0MZt2S0wYQrJUKE4g3MQQbZ6irnPimO1e5RQVxEAy4ChVsunAKwWl9sKGY aETByFO6PhsgmFBpb+yX6Tpti6ZaGWq6oBJrMQif1jMVqISSGF30QddlC0EYkPQ6KwklVLZhBOC0 6qPFY2HB9r/MKo7x2FoqRqEsW9AgqBMfIVek6JVe5cigIF7RbZIfYcoBUXQ070AAKwPizRBsPyLV Ai/oUR6hLMNA4+B4DFkVKuQwxxa6aUtp04qlqZtBmEiDLPQhe/+t91B0j6LOOQMvos0AvQej1o9K dPrQj/GS/yebO5aC7Uj+3GomrZHV2MrRU5aQhcpaH+FSCz08oNoU3zQ/QV1G2QchIkEIIHANd3Vd zxCiOgVAWohdyFMI0oSx5ySGXchbClF0QWzMpaWSqA5W855CITk8E1oHIkB1LZ6RJ9XzoXgWnJE+ ct0/oNCuBcnpZq5MOCiq5JtewlEpjgaASLehdKL6DUBEXzjD594CyIaIaglsgRXfDxX/LVVyvVHj nxbCO4TNtXos/OdvAgKh+pxMiCsuuNISD3Ws0h0AgUPMAUJWvCKA5y1kw5EabQt5o2u00pTILdxt QY8tSCrQY4Aw1P4TQ9VamlNie+msJqB6SssB8RegLIPltSBzw82os44QJqbGr28mitAN2W431HF9 gKT0lj6SwI1Qrth6kmIEh7IGeSuEl/460e+YCjZDzh9Ny9HheaQir3BCECwkClbwO6h7HaHAiNDS PWlBdh94RXHxEMQK3YI2eL2OjioYCW+IxWZoajp26YJNEVIrk01HowCDDlVz9A0nmQEPZLf8hAzs Z6ONdB4KBx06MjRDLIW0pgtg4yYnK2/zuor/0tciMOwAsSl6FDKDgSvvGNGVqgNDtgWmLlLNAE9Q Yw3ovyFuSWOxjWEHif9oqvTPBk/4wf95CLSSB6LGEmeCTD4oDEiRPNwfVCVbapAGJrdQzo6EwFFI Uj0UEnsSGEGIxhZoKUQA8dS0UA1HEjqXgGALXGzlZtSZm3pNpyAVHy0MR8lXNXcSnTFTddGgRPlq hI2wKSM5keIxyswNnW+L7qSdI7iovKOzX31cgZmr9n+1n2Mn2EKWQZ1MCiCMwFSvkySAClke+VNg rpZTX9SWuB54hg8Ytyhy9FdUVkXdQa/6bXFSpNVy6wITDyoVj8XnFVqE6CkhSBBEGqOhwE6AjIz+ ffq4A/IAjzEzAJLm4INcKHJEWXdHhPJxnncJnfVPYVHrOSgsbSEVWgAttK0QBA1thkfPCQMjsrFV 9zqdK2GvfwJ6iVIajPEbCxHSgiJyJXyDQpTvBEhav6sL6FCf6E8BInzvVwuBIxlrUAcSAmyB0kS8 VrhhNNCSvyt4CM9RoVgBLhHE9lZdh3oLjI5JoUcBbSiJ/QhjCbCF0C0VNXSDpbQk31B6adG+jKGl sFdDatkFLpCmQuJCg9HXOhDUUI8UTnp3R8z0CMb7q8UyNfBWRsiPzyYgtwz1IgDwIzgsMazFcim2 LpxOmT4twRriFpNGFUNsoRTpf+mmVcgoA3FQOm63wNiQMeuvBK7oaKdfDvgAgtpTS0i0MG70MerU JYdDxBgKtKITKOeluy5VTKMOcGUz0WySFwMSOtilGmYQSiFk0fqWxAfrhyiC91pSi3pd7nKMwaZD Vj84Ql0BNHqXkEvjj8A0Za6BXlpRS2vi0ReU78gt2f8PzA4UKNFf4c8vCYF/Tb+hq9ma2waIvdUQ /71VC5JZECEDeNBSqpFLiHwyPCgB7A2oU8EYyFCjrwURBZmJoWq3GL8gpIotVPRxtM9RtLrAY60m ZBC4Qd8hzanD4gECbUXFoWwpOGYOScYWGNlRhxhqV8kDxuKR5+isSR+JortQWgs6qFrMPZTej+Si IY8aHQoTCx1ei7d0Ftdq+r8kuv+0YBOG1AKY8idMcsWqkDhJDRlHMSQnh/BPZDD0I7e1jpq6c4/5 NfSK1pJPgLljkMWG+1vsQEdiJpkPrI0Cg9gNkg+HT+I7ukOmeelJktzIM3I4hGmTA7jFZ4VZ68dG 9EfUqWTJ8MbqQ8xdYjjWcMnNWQRP1LArxYuZ6t4wPRAcqH5UBkt0L0nuODBkDmA2N2ZIxqYuck9a lbzQp4I20AP9DRRFygUalPgGTJlRkjNBS5KMUa7jqKokD8HRHOQe4WskFTjVjZMBOpbwHlPsSdIs 1Teflnw6xjkKsVOloDzjepGFCzNg45IThYkSmFGF5ib/1oWSgEGaYqp+zkfPyIJTt8i4RzVTrY2+ fJIFlG3icX4BWHngT1d4eAUxXdKfZEg6KsX+ooj/e2j836JfxZhINigpjQyKgeBDfU2RS1Qd2ZQT +7SOlEDglQDHwiVZSrWegVq26jlgHOMdJLxW4ZNOGHxBcgsZ9CukoQdNCVrhYLTQpt6fQb9CF9KU YqxwjUjmDMFklUwAXkGlejIdY2jsO7N54JY6E61PXQieSUxwDVTCXMAiRxXxk0DAMZhHjheYgDGU mRiKOylSd+kYRAfcx5PIlsceOU8hfDbqJi1h2PwRjV9RERN/kCSRw1bJKfbI1tCCRIsgNYSkTTGk WsCVwiSRBldHSWR1qokZcfWslgILVinny4olSKi4K6i7KzQgb9erUTHpoLHETO0inF+tntOLdJTy IFkqUUjX1FUiWX1deEufmBy1CsD8l6PCn7LYyHOC6oAMRjBDRf4RxIYvWXIECj6z3JrNZYpASVyV jIMTFdklacr0ypkECXNPy7yQGkvSbnPq6FG+808JK0TeUGIAC6DIn4KCSHkmxCR50oD/Kpkkn1PC h8ltmJhDJV3FW04J8edN3SPKTKxYHFZ5AopweCJumLKHf4rPmolLTRYXcpcym4YJ2aQUMiLpCObo waE1pInj8HDg30qYyCBEaqCCmlQkVVaNpE+WNKiaF6UodHml9AND8Co0x0CQwhlZBpBwQTQ8XRJg PChCiPqmosPifzbIiwC7GI5MaCBw1rNJyvg5LQGx5CwQasFUkCQPPEIVyZNbkg6cR2HwCjKYScE8 JHwhYqq8X6RJ9MycPhySpDPhwNRmAGv9or4bcyejN9AHlp5ZaimFvXZm1eTgJH8lkh1ZBdpccX3x FAqEcNFfDtd/by3/2/QrmK/oF8WaW9Ev8vPqCqRCVLBiIIx48VX+IJFzvKgSHCtcJmWplCFC1+qW 5CnFszrBGPTLdP7KncOMr0qw6firBKWuABFtzWa3m7U4AvSrZzFhAkXJqSEUYWTrI3GQRwmiCS8g 7UBo6HPEqNxOZgsORuEzXx9T6UNDY8eS+8gEwvSarKwI4va6mBtISXGL1uRlnRpkENeHrDomrgsV qj+ZaEdxKh5sI5dDanMrUx1RIkg/SGuM2zyPjRKJTIZnk4xzTMtMKuQrhJ9KFEL4ScNu6R3TwQ/Y ApKHKVPBamXuEVAi0+eCJSoaVByEojRIEEzswux31AmYUllYLrBBusOgkIFaZBRzpkilDkl4CMXF Jqlo+WEREOG9ZAVgAFxAgEvu6T45ZR7+bCfh/4lef7QXHY66lS/6k14vxs1c71C4sWbI2wSMARdG inlmHzUBvnsPVW8trtx8sLJcznaB84MiAFZBbOCcGCKB4CDJCAO2SW1OMoGi3WXr11PPl0z0LISi EN2CQmj+dVu3NtOYkIyOZPvAJT4LAqMNZDKjlBE+klMV1WCtTpR2QBpsO4pEiMUgEovZ85H5kEUm 1A41yQmvI8E20mz7kKFRGi2qaHj5vS+A+n9//b36ZuZIVDYn7tZr2q0PPyXZElkigMkUUeLd62PC UdIkqhlIeW0JHGGJHZFqjSbtgRff2HGg7JM5i2YuWinyG/ntcLYbNeaCm4LAQzv+IwIwbSQUVafL uXzDDjxCRVqkAt6t0bQbH3qKgBcBRZFtJVtxOiG9WOoAVQ91ohLickliYjxqRTZkYWEgCnABrgpX mQiP/kBstz/yZLU6rqBYGNrnaQUiNkaJ4qSoiaC0TCcyd+msikwJq4/S9bc++gTeRbZoK9QB6LzI UI7CCdQ0WcUDaoEHObEJOBYaEfbFkj1iD4Q/xwwC/wH6BR6ihKXS5VlvTypKoHofcGDV5i2o2KCU euZ2lURAuLVuyxbQLymR+UvxIUM+Ov0yt6lAg7RB9RD4jKbQKpQnkL3NxuykrBbCTFnckiAXBlYy QTktJCKvSAsmYWczTI5KLw+z0ZJ/1WrabY9MxyMWrwvoSjPERQsJjIzsSqnK4BVup9LvwWRUIm+y amqfaFFr9mnL125HJjpwg9sefIQGGD/KDOB/+vlsVSmO5a0ps9X2NvimMglVln4CkqJQnB1gJkiW QoXQAiW90eNZsWmLEzzKAq2adQ6UvYlCM/xt0XIOV9z65DNT73+sEjyCZK5SrgC6zaj+QYCLBGJG SmigqlMZn+SutWJJWAmLE0MpBTNcWczvxwABztfl8QPgADv6bXZ6l2/YyD9RbUDKCiFDHwO/bTam uKZ1gP8sLh+q6kCrVdkm1Y8U/BHbVDeNjhmyH6WhnxKfypukfpQbWv/gVJbZhuqSKKYEqErJFX5E SdIefebv7302Y8a331075baFK3fARsFiI8k8spUiexlKKUAxADoDDwAd1P2DbeK1ajMWr9hfUes0 a6gZunj5ijqPW6E8fqgHWVFOApUt3Qvmf68cJbjeDCFpcbhMNi/oBpxRVEWIw0a6GWFfWFER1GS3 YoXQBeCpGsTvGYtX5ZZVkhQxaIgxFDglojEtD3QZNVXc+vCzb4aMHDNv+aaY2FhHBNfVazUpoqr3 aRkFxSBgzIJJcoAEsNmUh9NiAf7BzmOFACmd+tm87/MrqjhgTduduy8qMTmnqDg6mkn/lQuOHF0o HyiPMavKB1CwID1YcAPz8vjmf79MwerbRcuKq+udJk5kZ26ugNHsFJBKoVCf3RGpvPlYFtxFsXm/ TU7YWVGaFWOzNkJ+S6UotAydDr24NBv0dDIS9OXX9uYXY0h4lxBjInHldtJJFkwB695sYlFTYC6e xJdvFi4vqWjCZKs0LbOgxACL5GWVmlRgFLpSyZEQVyDICHkSDKsxSG7M8OdYQuCXpl8sn6KpJlRz XrQqvwLqH2mhutmzYMlyj/hLlB3DVcZjzZ6FCxbRyS6FbUG/LrP9x+gXJIwGaBzQQYKCt1bUiAb1 oUzn18vW5JbX0K/A9JBEYJA8UBqkJ8qRuGWEbyt5o5lRgQw1WWysT6OoHrYXlDC/ln3gIEjVyxJX knSWnhcOFZWRQWKiJJutNociXuT/B43odifSi4N9gxW43AuXL0flZIjJ3OJDigu5/GA7dphAUnBK 2B0GA04I0UhbhpIAYPl2yVIyPaXQ++i1R/UsL4oM6DmIZArCHyDYZi9cUsc6I4SekBKqSaFNK/eD UNF+/vf9R4x55OnHUPUSQxVGRwZiQr0weCRlUs0oBwfBZWU2PEom8a+gqAcYCzqVOTKrrwt17VDg RhoBY6RnyGb6evHy/dX1XESvaf6SJc10iREaGAzWBbNDUyjbALVDQVi0HApUVZ9KiQeDhfDLkSe4 jiXq/7RdqBvm4jlVtrSkKLU1aeYqn1aJ4tQcIVmyG5X+aFsox7l10pVXPnrTpMfvvv3VD96rACzM XPXiZv/BZn+zyd6sWQD6GtHs8msa6qSG2eLNu7PL6vAlMjbyngfuj7IimJAwwt39tW50BFUqJtL+ yEMPorQbDItaP28VubUDHk+DVAYD68TvwkbtkIcWFdYVaF3n42MHaj1VirEKjc3ZuGVfbSN6VySH h4sbPZiO0AKdeZhFRZ32w4ZNAwZ2XrpswfCh/XETT8IGLWjksLFsWgQqummVLuqhaAcyCXWg6y0c QIlTCvVi1jLIpbv2ZFbVw8BavXnHmRNPBQHWVVWectJwsHdUMFNytMnH9ml+WrVat9AzsEQQy+U0 R0dHPvjgnRgDWvt+S0Z6aTWgiocjo2MA2BKPVu0j4QHJaGbJRhzWCdDA8yVOL6Ghb1iYMPgDTq2o CWqB8rYTLNV+7UCTj/OChxalsc02NFsp5hfq9IjAIy6A+EEYzSYr7h6sp7KtNAz8uWDTlpzDxHta gX5ISq0clc0xKfzt4EKgOwzjYKMXkHFKYlrUZaiUWe+vaQh4hI4tcv/OW/tl6VcIp6i+EUvcYNYW btmZXVFDQtC0mAjrHffeE+GgmU9MQAX2Ri+WOCrSKvQL0jbVCGGCfovc7qPSLxi3qktY6yMeFjX6 wRzQI+ho3oaNeTUNpF8TmThRutlz2C+yR/afYJSAHvFkQaMXv0VBNKM7IKHa/Mdvqnpgx34TMLCo WYMqVwOXg8kMNRGvFDY2oVnyaFFkwe5KGnwq1zmZu/wUVkHQaI5I250P3gmjERN3mW14q7jRV+pS XIKlCvF8nV/LrfGgI+jN3NMSkkcvi7bu2VtdB0Kj1Qj/h1zMb+BvQFX5Fcl2NXNMRNRDjzwI9w95 gtD+oSZPqRA4SqvhYuHhhuS0nqQ+5W1qIFXiSRZjtNoBbXw/XO9Xujjewp8Ftc2lPj5GDtmkVYuV S81AtOQy8LFGffr4c8nGbTmHq6G2WqPMjz78kN2ib2Xg3cJmMnBVmhwmXY2HjZc2e8D90Jph4gpr UMcSlB8oVM79AoRqeeyxx47aLHqXXRCjf9aCoOzC6DMONt72+PPvfTW/ptEz4rie9Gyp0DloWCbt y4WrRo8f1z7aEheXMGPOwtPOPhsVVqY9+fSmbbvnLVqyafvuE0ePwMxvuOXuPTm58+bPbd+h07dz vt+etX9v9r7dm7eNGT3yymuuO+/C89HivCVrnnn5jZ27dy5ZsnTiKRPgyL788il/vfg8jOmKm+/b f7h27ry5M775Kj4pqWunTs3N2iOPv7Bu+9bvly7buHXnqDEjsPzXXH9XeUXN7O8XfvDFV52692zf NvnN9z7Zkl2wPT1j7/at48ac2OjRHnvqxe3pexYsWDiwV/c28TEYLa1pm9apQ/eunVLapab069nV ZrV/s3jZK2+/v37D5iU/bBo3/sSvvp5VX9c8e/bcT76c3aFjj07tk+qd7rsffXb9jl1zFy/ftG3n +DEjsIQvf/zNlt2ZOXszd2zddeKQ408dM7ypvmn86NFxDtYEVPnBoXB98PnnOzIz+w4YAMhcM+WW rl17tklNzjhQ9cSTz11w1snNTu0vk2447w/nvvr+zB0ZezKzs7fv3DN29LCvZ8ytqm6YM3/BZ9/M aduhU5d2bRyqrgco1qzNX7n+hbf+uSsr+9s5i/oPGJwUE9Hc5L3/iRc2bstYsGz1xi07Tz1pGNZr 5rINL77xz43rN65ZvWbihLHQaj+bv7y8QZvz3fzPP/0irUPHTmlt1XY0vckm06INW5968bWtm7fN +HZOSvu01PZtX/rwy8x9+9O3p2/emjV23NBZ85dWVtR+M3P2J9/OT0nr1jUtCXQ774etz7z6dnpW 9sLvlw8dcoIjCuqRdvWNd+ccKPnu2xk90jq2b5uiNinDn2MCgV+afqfefHdOXsF3336X1rnLV7MW bMnMycrZt3PthpPHjwYOX3n19X/7w7lY968XrXzxjXd2bN++eMUPJ4076arLr//LH3n9yiD9fn1U +h0zZgQ0P1gAl029Pf9wzaJFiz/5/Ov2Xbp/t2jp9uy83bvS927dNe6kkQ0e7dGnn9u+e++ChYuO 69M3MTqadZMs5kq3794nn9qZmTNn7oJBPfs4IqL+cNmkiy6+AHf3Fx16bNoz4884hZ6G2QvLS+vm zF386ay5kfFt+nRpV+/03PvMM9v3ZH4/Z0HPXv3i42O+Xbjs9bff3bp564rlP5x6ylhwock33b0n L3/m7Fmd0jqkpqb89Zobzr2Qk5o5+/vyssp5CxZ8OXNRVFzbXl3aQswsWL3jxbc/3JOXPXvewkF9 +yfFRWFpILT+8fGMjbsy0tN3Ze1OP+XEkVj0ZevTn3jh1W07d3z17ayU9h3S2qVANcEuC2RebZP7 0sm3/uHCsyGWbrjp3gMlpTPnz/n421mp3bp3SUl+850vtmTv37kns7y43O0yPffc65u3bP1s1szU Th27tG2LTZIrb7k/s6BsxhefdO/eO6JNwqQb7z5UVjFnwYKPv56T1KH7ex99Cga78of1J598EtyR MKwfeuKFNRu2Llq+at2WXeNPGv7au59uzsrdvTdrz7bdJ40e8dfLp1xyEZnwktXbp7/w6pZdO7+e s6BNavuu7VJw8fKpt+8/XDV77qxvvv62Y8d+7VMT9Wy2eoCfbMgqqaJ7RI8Jvh/RCB3dP/Fh7BDc h26pWu73+P01fv+1r33Wd+pj3aY8NvDae7Mq6p2wdVlCEMa0v9bvP+W2x+aVunP8/uc+n33dw09X +/1VPn9JQ3O531/q95972yMri5ty/f6xl1//yffLGljklW9dOf2NOXtL6+X7qZdP3e/3b6/2nzf1 gbwGL66kFxai3xK/f8xfr8YzVR7/SVff/tmmfbi4q+DQqZNuzvf70VFeVVOV31/m919012PLD9Tg 4phLr5+zfgu6/mL73sueeA5N4eeyx19dlFdZ5/c3+f2LM/bd+OxrZT4/RuJCLQcf4kzg7MSEOTA8 0AR3vN8P1+UFN92R5fJXYmAHawr8/gnX3DRv4xZ0+vXmfVc//jJer3N7i+ud6L3I7//DnQ9tLyjG UA/7/ZMef2l1ZhG6Y+Fg1Sw6IFzp4cOn2e9fn5Vz1SOPHfD75+cWj7/21uc+n4MXX5q/8tlv5tX4 OObxV92wTyAw+YlXFu8pBCQBwwlX3zZn9S5M+esduVc88QLa8aGiqLcZzWdXNv3xtkdyvf5Cv//t NekPvPslRogbpbVuTAEXz7v78a0HDu8tqz3j+ntz3H4Mde++fFQcRXcjr7rj093FeGbB9vQbnnoR 0MPuJkaKkeeU1509+fa9dT4MaVfR4bOm3JHh9WOxrpj+0vL0ArSMQY6+6ubv1m6t8Pu/2plz5fS/ o+WCqtoLb7kvSyDz7vIND7z+PqCU5/efdMXUDxcSBzByQaHw51hD4Bej3/GXTf1s/upGWTuQ4WXT /j53bxGWst7nL8bKXnozMCSrpPy8G+/M9pJqthaXYvXHXnotnql0k34/35wL8tldWHpU+l1TeBgk U+b1jr/6xk827gE6zd64+6onXwSyXTL91UX7y9EpmlqckR+gX3rz3HAeIVDPP2fn7ptee+OQjA3X y+ucZ155M2iKzKTo0F9uvweklAn+cPUt89ak4+KyourxU24HH1ixK+v6F9/EUPEi2Uut94zrby9t JivIzOcE0eaEy298f9Fq0B3+LPOClU0F2mf7/SdeOfW79Zsx1EV51ROnPFDs9Oc3uM669b49IAG/ /5NVGx999X20o0gJg7ny0efWZBYoHlhY3nj+dfdm1rHTLQWFp02+GQSI6+C+2EgEkCdcdj1IBnx1 zOWTwXkA0ve37r7s6RcxeJDY1c+8+WVm+ZZa/1mT7s4vb8aVH4orT7/h5lKns9LrH33FTW8v24yL JEa/f9w1t8zauA00+PKiFafffFdGRQ1au2baS3O2ZaEjcImi6mZcOej3//HOaZvyy/DkX6a/Mje3 FGPDkp165VSw1i3VnnNuuCu/1ocrPxRXnT7llkMuT7kPRH39V9uzMbuZG7ZOnvYyoEG+ZOA1GCCZ H/7mptSxxvaQ9n4yREXfVRFrWDlJ5RMdGSVhSz67lLpWW2yyCcMnYKQ+//zzDz74rK+5+eF77mSE D8x5r7Zi5fqvZi42R0SV1cEjDavcev4Zp9AdJxUszT6vwy4ebg/2TfllZ2Zhlx6920SZEYbRq1MH SHfa8tERjISQyL0Th/eI4K1Uiz26qBoODfb0w6otM75ZBBFV3eyCTWB2WCaMGor2O3XtUlVdw3gM 7IjCxJTa8Pize+dOZaWl7777dUFRDcMnpPIeXeAImPCgfpJelyU9I6t7jz5xNr7etV0cHoIIGTdi KJ7s1K1rWTVcnggYMbu8niWrN345bzls8No6+PClO69m93hZcVRysuK3g5qYKC0se0vFpVfvnofL Kg/We7Zl7D3jggs37tqDwW/btfuE4cPEYQInOI0ZvOd310fJKPE+NIrTTjoOQOjQoUNNdR0VIOxf meEJ9O4tKHKZrV9/OeuTL2bt3b2rqKBQ7QOC8pet3vrFvJUuk7+8vm5ndlafAQOh5aLlvj26sBY9 7EifZ9TANOwBdkhNKTkMd4Wq7coec3Jze/btmxhDu7BrxxRbdFxJKRzsDIJ0WLk5yOXWvBNGn4Av 7Tt2KK2qACgy9+Vg/+Pzrxd89MXsvOzsw4fhLWaD2J294IxTYLlSyw6NwP1ldLjfXau/LP3aLzp7 LHZmgNhABocF29nEChC7OKBA1lpmdk6vXr3iGVem9UprC5S2xETS2QUfo8l04rDukaTftkel35pm +PgZ0YCd4zEj+gGdenbpWFEBHzzYBZyGLinhq3Xv1Kn80OF33/2q4AA839wzVhU1B/TvX7A//+33 viwqrmWQhMXaxKgJcUCh7K2NQb/CtrwTThyAYffqGG+1RxQdKO/ds1dpUfHbH3yVX0LP6vasfb0H HBfj0EBlvbt0xJOMFjZbzj99rDAQP6K8GOurAiRM/nGjhgGx+3SLt9is5VU1u/dkAC6ffzXn86++ 27tr58HSMu4/ybpg8FEIgPG4VVhhRlZ29979kmJ4vXfnTjEJibmF5WojCqThwlEBcWwSJlbL6BFD 8Vifnv3KyioUT0NIl9Xsg27as1+fdslkMD3SEqNiEooPHmQaCKvl9FOGcYTyMLTfsSOGoN8O7dN6 dO7aKSkOPLZT567FpRVkWeASft/CVVu+nL0a7qvGRuyHMIxNCgwzKAWOXowkPT+/c+/ebWLJi3qm JcTExJWUlDAQw2wdfnwvLk3XboerqtWYxdvK33pwpfgTflH/zE8KNuUYCjkIieFiga+/4OxTu3Ua FBt125//2DkpVsJ5JCaP1TexyeuZfv/dbz957+1XX9IxhvXM91c23frQEzZH9JAhQ0xwsDu4Acuo HuIoJ0yObPJ7PHA8iEfZTCcyognQKKBPyefVK8I4XRD0yi+G/SDpmHE5cFxbS+pc9zzyKMA6bOjQ CDveYxy8x+MGp8ayRcrZBMoVdU4F1Qvle4cY+6vPTuvcq8cjzz67YWcWo9pZAJen2egQZxcyWrOD MawyVL1fycBFXGHkK8NaD1TU3/vwk6aI2OMGD4HrA6FBirFgwxjBwfzGyEejIJ0cLdDDdb2E6uBB Q3fuzEjfnXnGWRMaPd6cg01lBw8N6pKK97gVx5N0/DBcEidhFCFBwEveIYfXZ5P7OGWDgWMr1O0z xycmnD5x3DljR119/tmP3HILhl1QWnXXE9Odjoj+A4+Li4xm3I/FBjOVW3qK5iXUyq65ATEwjgij hoaSwoCeF6cRZeNdxRRBuXGYzAzrBOEJR6P41HyYDrpzmMHrrNK4v01qCvycZ5409q/nnv3w7bdi eWS4Xko1qTfVskqkTDX8+T9C4JelXzA9zcaq1UQMnn4TJFeIoZYT3BAhfbhLr7sUdWpscgHFGMmL oPyAO+po9Kty9fMUkd+vZFgE4h3lcAuwFHgF/EEt3y6x5teffbxjn54PPP/39el7OQKTCdibZjX/ 85lne/Ts88gzz6zdsdcXYWY4g4InuIWZaCmE7FH7WBQYPkt0RGRSpOnd558Y2L37g8+/vHJPCbcl uIMfzKQgSE79D0juwN46DjwgnFoxMT2FkSSH9Tgh6BGF2T455bQJ484YN/Yvfzj/7ttvUVsPCkou twfyT1EfAsMZixjwz3l9kTY7d3iETjB1D0qDKlng86BrwMTu9kebHLq4Qni3B9EhGIEqFcnZYfPA IsGQ0Dv1EarNRYEtfqKgkEDt1ptFPW0c09LyKyvvnf6kNyJi4PGDEeOGmFI0BcMDgo1fBFx4F/Go NLuMAWO9sKywGTA8MgTqOhY6+XQc1vFCyRuZ7y/7+SnBpjPyFgOAVu7rnmx/9t7rPnr+3j+eDGOI ZwkFBek5pRbjana4mxVnVGmFM7NyunXvOerEQfQaez12D60lmAVcfmIMNakInOfwuMgxGcPbHAOB 3yF5X2ZGaZULgQ8ZObkIq8Un1haBlUSsrtViWrUpCzrg5t37IqymbgmmzL1ZHbp0HzP2+NQObXwu p112XqOtdmWZIfjd6iFmYG3ioiKrKsowO3RcU9cQYdUmTBg6fNyYffn54PGgRlhjQgCM2FV+4B7d u+7bt6+qifra7sxCHkARGUPs8Tj9HoRcaHv27GnfqdNJI/qnpSXCr6aOg+ATFWlrkhaVZMLw9ZPk Ot9hO/g6aviIFUuWmVyuZKs2YviwTz9878TBg1iJWxDU7vfDhEIvERERdY3YWRCzEgYloqwwTbsd YbwU8zhk42dMf8+uXcpKimKjorp1bNcjLT4xms3k7M+Pb5c6buSAnl2TXfX1MI17d+0Oew6hmBje pozdQuSInXJDleYa8dAAIj90bMYS9+vVMydrb1kDTy1m7ivE6e7u7ewgs1i7vbIWUS9ih3k9IHWs Ps7gAOz40r1Tl8K83DYJsT07JWFZYx2RvMv2eVrBqGuswBH+HDMI/KL0ywM/wtXgKBN3hYU4L0hO VANRAAm7d92bkV5RR1UxY98BcMEYq8MBBQiRiCa/ot8t6blHpV/FRh1QrQSxyZe9Hhynwpe4qIiK ijKgCxThmuqGCJs2ftzQ4WPH5Obly6lmKq5VlY3wQ5w2HnHNJxYUH4C/IyoqqrCsCSi6YvUPXhdC FImrEB0r122BOMzMrQZOtk2Kbqp3RVq0U8cPH3XSqKKSom4d2mVhCvUe7Irtzsqj/YHAQb83Anqp F9d4bNuBeExVjtGP0P9NeGZPbmmEzdShbWyPrl2L9u9PSUjo3j6lS4fU2Bi8J2qcAComKrqitlYJ s949u+7L3lPZTErcuz/P7HV1To0jdyYDAkl5QSzogiKNdcWF/OE2c1PqYNYYfJQZ5m/7nL0Z5Q1e WLtZ+ZXQAzp1TGMcutetSy+qHCA9L9ohBNzuCDNLmJL2PG4sDVrbm5WZnNpu3MiBnbrENzbUyYk1 Lcpuq6+to0ICHVqj/6l/1y65WVmV9RT7WXmH/R53t46doG5YvcLepUHMQvUr8RmUbUaieXJzxQ9/ oc+PCjb0qstVg+HImWVew6DB+JQaxZBamDYMIxVjC2hnMdncPDiCh+ESxOVRQwaUHcx/dPo/Xnzp rRSzI765OdavRTNWjvYLAnbRw0knjnr7tTcenvYsph5pbgaA+rePuOCcU2564IFJ909/79vZaDoK PdY1IXwF9hh0gc3pu6+9/6nn335n6tV/A9MfNei48kMVDzz5+tMvvt42KcnSROkIHyDoAoOGqwSq EYWcTztp2OAvP3v/oaeeRZQUQjZuvu+haS+9tm3nlrFjRkMDpX5k4+FrOepIZwAG06tD4hkTx991 zz23PfjU5zO/k/DQZhAWkAPzjbP4AI0RQwZWVZY9MP2Vf/z93ThHdKSFpgxwcdTowS+99ep9T/PE jMIhpatKABJ+aB3iyROP71txoOC4bp0wzfFDj8vP2Dl+yKBIOCo9aMRkdzYD5vgZOezEV9/78MHn XiWEXQjDFF3S3YhQZ0EUSlN02jPJeu1fLr7vwWn3PPXKjfc+vXTNRtwddFy/2qrqR5/6x/PTX02F QWdx9EiN/dO5Z9x6862T7nnw83kL3ZiWyRchpqbosLY4qw1joz0n59c7tY396wUXPHrfA/c+9sIb b/7zjhsmxUl3Y0ee+M/3P3nsmX9Q3supUcpgqJagFgi21DbXXX75nXfcfc/jL95y75MrVv4AtMA0 I2D+qZQFcLzLYY1fCMt/h83+4vQLE0h4HmPTgQAnnvTW6289/Ph0fenNLlBN145tz7vw3FvuuXvy w0+9+9U3MLBIvx6dfjft3vUT9GtubqLi64UuawHa02EAt4zTh+8nDT/+888/fODJZ50WbXNO9vX3 P4Ropt3bNp06diyQDV4IzH1Pbt51dz7y6LOv7d6968RRjEO56k9/nfbw47c9+AQOBsRHRlJAUkZG b85Iv/G+x1558ampk66ASNu6c8fkOx974u9vpW9dd8aoQQNSY889/UywiGvvfPzDL78FZkdCFfM4 cQyGmQ38Vjv86c56NIWBpcbHb9+95+b7p7384t8nX3UlBtM5Je7SP/353rsfvPepV269/4lVq1ei X+ijoCmyrGHD3vzwo/uefBZcpkvb5D/98fw777z75kefef61d+65aWqimJhyZgMHTC3REM4SlxwN 35jkawdPi+A5csag4VSd1eXplxR56Z/+cPOd99/60AtvvvnmrTfdQBZkxtksChjFfyIRXo5TS24X bQ/4yZzwjpFa46E7N1aQXx0/pKa87Inn3nx6+sspifEOG5yQWN9RH7z33j2PPmvB0XG3J1bT+iVG XHXRhbfefe+tDz/71ltv3n3LTRDavmZXrPA90HOEwxZt8itJYQgxCgkl2iVr1C/4+dEkyIow8CGr l5HJKUVRWaCJ0xXAg5Dq7CRPotEIhVlk4V6Xbq7x+J46h4GfimYtPoJMUOQZ2TEUBLgKbVb6u7F/ 1uTSYuzK9Yq4Vr2zOtxyaUl2vqV+QB61Hu2s6274+MM3YQcl2bR4WTB1Yqa2WYuKIJIp0xvqBAwy Wv0YuldLEFjWmjWYPMCNaPpE0JoX59IS7RaslsWDGCSc4sBJbZ4GVaDnyWzNjHlhMEguEy9OcbQf LTDByDE7vIvfeKbCBfuJd9mawIsB7gKjJJ7g0nm3Xspd4MmzpTyswyeJE7qXj7OgViUZgXgUT50N MGnw0wNASs5BPGCQKgqZPeJYOrYQJKTeJYd46pq0uEi9wDevY75eLcYirl2eyqRhi34BAeiHysXB oz/yBdBxIsMKtu2kFzUdtIAHcFoiPlp/BiOE7oqTenAcg1wxxWgBHU+z+TQoMRg5IsIZut0IVsJn uDQ8uyN6LhdBuWeUgyT8OQYQ+KXpF9gObPH6cLTZrpAcdIpNaGipyp1AdiYUwR+PlmDVsSuUfnHI KclKAXMk/ZLtCuYg3B8uDW5GyLkrNE5Kd5NFRMJ2AIZ7vU1ef7LdCrzCvjj22EAsjRLZX+fUEhxB GmmUQ6IUk0JZ5EtMpYEWtCgLh8eznBZGwFfXa21idAUUc2HsvnAhXR+VuSubD/tVSJyHb/iOgEnY blVOLVb25NARCBbH1DDm6iYNThOQGHx6dqK6Fae+sZuCU09QtdtYaAk5LTwnU+3UkuV1tfdGPVjO /mLHHkNViiz2JjB4NIvxR4s1BBONewGwJnFcB4Tm1OId+s6LnOvh9idVYWEgtMCYmULn1dAY8Fa9 W4PtC7Aj64LLbC53ath5Y/QD04uYuL6wKEDODgKBtCo9gvuB5SZGsC/wIq443Gk2nXMyVYTASjaN FK8ToUbGquj9l/r8u9n9hS9Lymqeu2e4Ok0EHNfDAUhCFnEiEsWui0OZEv4EC9NLrUHtMsoLBQp7 SuJEfRUl6wu/82Qw2K6CiUg7hM3ZkPrF48OJsbOvvv6TD95KEnMBYYzIIiK+PiZGw9uw0UAMtAfV aS1ZSzHGZDcAaKTYNF8Ee1cZakhI7JlHtKUdyR2lomJwA0lTWiyF2gMQDKPlijWU5VfpvHEF6MI9 MGMjAa4VSS6l5smz28LNdVez5KOywbVCV7VsWuK+x+eCtiRpFWTENO8o4fABAShMFfbha5JnFIIS dDwby61BZXMTO+Ux/DAmRmarcm+p4ahBKAhgjDC38SjOlxL+zPmiSEyeh1tdDDL1rhL8CtEVzSvP g9jrknFF/JmYrDo5BLqiu0Oycanh4Umsgh2rwFXVO1LdhT+/AASOGf1KUQvl0MMa8qxuKD4AAbnd AkscJ45l9YVBc0cW+zIuiwn0++kHbyUqBP4R+iXmMLGVzv6o3kGlluxwCu0QyA5VUTJICv3qCMkU O6BOUJN6FVkhkNqGqq28J8ipM31SWRDKnI4wYGEBhqql5kWtmhsVFggqenH0nUW+EPAz4LqLlCjJ ++jpESkr3RkqG7igqunBRH0qTxVHqP9LmkVHbvj/5aAYG4cgJOfhD3mADExRnyIfvAuqdCG/j/Bc SYdAQmMfugcQQ0BSIpkRRaRyrlHI6MxOZiTcBb4fr9XGvYxmqP5IFSjjQb9ql0HRp9K8wb0ppvVm hcMg6o/hhNCG/Ug7hC+qIz3WQEFa2SxGj78AhutN/qRgC0ibQP/qSsjH62q2OBgBRTAaOTuIZRB7 kk0OmgFdjTDzsPXLrTVaesJJVYYNvoh4JUAETkML8lYBFAHZxmxpzJijmDLBwuetkB8b9+Yc368X dD0uAjMmIk2TylVKB4Z+rF3yZUkGOFyBNiVbZgjlQFYSBkJIrIsMgJJNLTVzRDGdDCQKL3jdENiC isQmoIUiKw5DTwPJ3HOigchaSdYrSS3A5DGUiYKeyCnJ/GzSl/ytSFBNihYw4hxV7jwlPCSwixEb 6jY5vjwLPyHyvWCQiNigYIA5RaEKHQPEiAErlYGvM0iY50HZHcDDNI/MzSLmIR+Df545Lvm0CDB8 kEbIAn2KEWscnhXIzIXiqplNdjRI2hBRZ2TJMzMvH3Y7kUUCvg74LCXnLKWv3w0gwM5FTh3kn7TY wGUk6ZdKoElFQxJyUkyyaygrOLerFiP8OWYQ+CXpV9RFlQ4VkboIEYkA/QIZVDwUUwSoe2Bz2PB2 IPeH0mzxIf1uytx3fN+e9DH8BP0ShZnzSTIZMr5MzzFJYwNSQ53ZJFuAX5AqrGAy8/8wFZWuXfMx 4rMkrJX0tPCSkZrlNDKT0DKVIuiH7iVgv6RMhI5OcpZ8qJIekXQiaiFkBgI1/UyCKtQkxIGz4S6v wwHBRw1bTVKvnKUyq6oPWR/pkoE16FIyvqp0EFBhMQGYu1DeZVJ4mhICwZB2pgfkPibcSEqSybln PCLNiuyU1iUnsnBOpHuEv1BxM8ofP5I9kNSRdxd6PJgteJugBoQM/0VyLMyRvbMXPZu5Ci5AAARY Ex6iFU6uTtoXlZRCGUwFyVrItxkjKCMDMEnnIoOFJ+o5P2X+giuGH0wHyi/1z88UbCpxqAxLgBok GYITQkw0D6AEmTOCAD2yWQVAI/qWiM+kJMA6wSMBPIHFfFxAQlp6wsnJkoWB66aSyo1j6EOw4PgU hQCWSwEO1pYYVSo8EU+gAaCKGQoMHNFcDqRNk8Exzb7KxizrhA+8dpIWlZqlGquiSbBaaZzBoGLk MQUyE0AhWT8UUGZU80MGAEUodfjFAAexirlimDWSqA/PhRlp1mw2fXYBuBGEOgQl1FJNQrwoFI7A SWTAI6Qhfqhs4qKyXBlMiDzcchzeiZSSQHplK0mELgApaIRhIk2VQ9KcCh5J7lLdfgPOEbwqcEdU U0UhSoeSv/RV4CFvRWWEtJKyIBKkElKcAhwBaYo4aSSEhANXmIwSbIjQEk0AOjpwAjqlUhwoMvEq NDgvc8haeY5PAi/pYEHCEi5Z+HPsIBCk0l+EfqlTkfhE2xPMYfJDfQcFLgxepyIr0UF8jLTDjI8/ i34liy7oGnl4JH8jo9SAb0o1ZDcwBUltgqHM+iYoTJYKjwzYjfKl8JZbMgUxI75kRNSZVwDMxFxw CkmWIOTGMgGK8RAfxYEm2ZnVi2DniuDJ2FSmShOoQG5RxHqRP1N4ngfqM7Q65EwNeETAokijiuag I4pNKYqswQ8oO9wAFP0aABUpQoYjfImcgpNX1MxDW4odEQxyFwoiLARJPuzBeSpxm2ANLD63D3tj 6BTJ+Ww0AEQJZyPMrqnoHTMU5Rfi2ceYHVF5ZXY6VYKtgFqpZ1PASjiscYdilSKZk0EhFvjAlHRm ak4ZnTwp4eUCKHIfg/EcO3Rv0ZKhRR21+eDQjSnIYyrDoUglkTpUXgQAMi8we0o1JuKSuggiqAXQ 8jKnq4sW/kVgqDWhIaK4NNoit5PnpTaA2LC0L9iLcFs4DRh+ymc4SN2KktS+eMHNQwViewvSCGUp h5uY4UQq0cOAPSGsVMp2iBSQVjlJScYtIpobxegOHjOm+6YDU2JBmWDUyJdKCSAySE6diZ2HACRD bhJeSjYoUAtsjbBbYiL8upiHmrVoYSQAyeYsmpCy3jgDhRV+SDUuhMIUSm4lgRiMYbLYVX0NXJF8 aNT5SB40kqleqLoeElyliFU6DaCa3qbwDQG96kK0UzIxL8NXsUkP25ddcLTiRFVaHiDAyFISHAlP GpAdNon55t+AOzUb/S4T0tIWNPQDfULGsIJ/8puasTHplvfCf7WCwL9Nv3IemPRL80ewX8Ea9g7o Vy0llRddYspKiLgSpYbErihUeaxVUl1KNdI5KIiFIEjv0Cnt+FFajaJfcdMoTw3z0JN+dSIU40pa EpcMN8YoXUg9Qm5CwfqAWG2DeWPRHIlbWmAOZaV3s3+RiKIKS1J03mGmBKKx4KlgMpm9zE1cS+pg kuqBBpgYHlJWRrE8IiofFWph1mBJVUcHCtiGTdRfeYiVEJRY1QegV9iQqUhBEpk7PP8wGTFJoQhy RfYLtUBMO31JBdKUavT1ivQRU02y+YufyKA7sWRBbrpUtsmoyJIV4yPlsl91W4lXGp2M6aISTw0B Or2qmENujimwHpeMRVe33R5su4v3S8xTSfBJkWpUztKJVf1jmCn6uoVeUJBUV36MwI9C/kfjCISx WrYjP7iqBqFbxkc+FSIT1JiFTRv7RhQJkmZQ+VjFY2AoHHrLvI4fxTblGSXSGaygYyp1f3yFtiU0 phiwviGnM8nAwJTNodrWDV5dUZW5qG5ElVB2Z6uPsYNm9Ew2HhiYcFNFbEEbS+l0SleSo2/4lx5k 2it8UKK6ZCqtNJQAbBWMjdEonh/y0YfCxWY25EA7oisItAPPM6zEAIiSjbL3KZaWRW3MyXjEK07R TEBJmlo8IzARyWfQHd6SCFhZC1kUAxx6jyFTkPUV0OvqgL4KfCPoiBFY6WhASMrhIBH+1P3U2EIn LypRQPAHgCJBYpyGjpZHWcjwJR1t/136FYCHfqRIWAAJSXdoku4M2ShXmpBaZT3CzcBJ9qx23US4 6LgjIVBoUJGVQcvGPjM3y/jRfQlB3qaUY/kofMZHb1Y1QrylNUC0CHAaHdnUi9KmYKCye4Qxq5Fz eILMfMbYDZKX9H5lwMK+dGQOUr2UQxQo6FtaAUIQyuJwJHKEIwjcUjNp9RH9UwQOZnCETcnB4H9j j0reFTMrlJspeFJECrhVgTedX6lK97JMOkAUuERnF5VTvRwkWDUe1YJ0J82q9VWWurBEnahF3Bsc lo8rPMGTynEnTbVQXNUg+aQamzjIdK6FMx24K2/q665wJrAlqUYm4zLGafAf1VtgMDKvIz5q5MGP Ek4B7iP39Gf4j+LPBpfWw3CMtw1ZEuhVPy6J1gwABfc7W3QMFmzgutGYsFAukm7Ay6iOMlTDvS0q SctP4OlQbiuP6DpRcCLGVb0BQ5woUB79E8ROtXjkCIGZtnxPDUx1+iPtEewy38CHxBb6sAE6PKar ujLjwKSN7/o7SksI3FXcIWQmYvhytzwEbIFxBvD5KCBtsQb6fX0xA3AOgpEP6A8dbfKtTVxpXM2k ddc/tg6/7+v/Hv22gO6RAMYVCgPFaXTWpoM3gJniItdRK6h5cFNdOGPrdTMw2BBcIkIMrhLCZ/Q1 V1xVEYt8lKeculqLdVa39SodIUyqBXUFXxGmLA5xeaslLRhiWKYgdeVCH1AcuSXVqr8MvttywPhL RYEYcwj9rrfcci4h7wfpKITFh04jYO7IqasWK2hgggqEC94ySEpoXQFA9UjmEOAkOswDcxI4hKxE SztB8Q1ZmwAsglJNTT1gZkgr/0IMBRY3wMY5EjWlwI4d7Wh9afT1/2mLDe8aOpeus8jkgzxLhwW9 hQaeKc+hsYvTElGMQarOQ/lgYI8ncB2dBJioaCIG3FXvahrGIsnrAqGWxyOCKqcSfrIJKhfpmdPp jTOS7TR9tXSHtfwlTylJEDJ49T3EDDWGpENJ3zpWs9Qf0+Gmv6r/Y8ChhaANAY6hrga4eouRqFGJ Hop/dbtQDdOQ9HxezcuwxmRM+jOi8oRoiK3WJWCPGvPVlVauCzFJKojDQyGb0Lro4oroVqwam3Rl RMDqS0Z7PgSGQU0/uIkLHorNEqpu3GIPPKwDStb9RxQBY51+1/8qcvj36LeFMheCNAQ1HCcEvWww 6YqmYRIE6UKeMNT5APgDyxSCRQaSEjsV7hg6e6g3IshzjmR/xvgMRDAoSGwy5bgj0gcpMcBhdPNI 0F6ic4mf8noQbwPYhWYM+hILSdJnyTmnFlgt1IXXJbODihgUz1Ag7pnbAGpB8D9CaXSKkN6NHEXg ThxkSPgbh0H+I6upUorwbqjUClHuAUlGIlhUUEhLZVGZXPJuC51Ypi03CDe1yrqQC1h10oW8rUek GnaSrKy+fIF2Aq2FkKfCRjVyXDbWKqgSGTigj8Ro02DyoWunQiAUzwHUiW/q4AObN/lxxjlEREl7 LT5KPIaoZq3kvA4KGbyhg8iSKwmnf1X/6P73kPYNNNLVHd2/F/KAzES/a4BBFvjHlHXC6Ih7rS7w GR3aP8ETjVsiWOkdNdQi/BuiT+neiVCgCU8XfUQfsvyj9IDWAkm9F5xaAL0MrTA4VmpPEpfJ9VRg aQEZvZcQBA2VakYXAdwK4LFChSBat2JAgs0t4NTCTNStxiA8WxKSDhe10PwRHdBwKQTvim4oYA2B rWCRHjygtDNCUOCvI1ZrdA3/3QoC/z/02wohVYu6vhLgk8pMCelN15BlCZWrS5H8UT8GZipa0hdW PRlskyz4iPeDtHwk7fLVEH4ZaDb4pN6vYpTEriAG/gjq6IgmTain9Q0R1Ze6SKWQTCkUHgGwqb4C 4zZ4AvevVOM6AQYGQLZJWgjO3Ri2gqtitqpBRW2cdIAbBIqLBhoMdhMUIToEAnSkKNQQUdJ7AErs zgBU0J6WceM6w/6DEw98C2UjIfMMBYsxeOEJoWaSPqWAympwjNAZ6RPQL2EcUiSvNY/98ajIwMxD GdaRC0gYq70xXRHgJqKcaMYd8YgbRqLhUZQ2jDgR3ZcawGrViC7dSSCB8Ru6vBLILcFoCHYZjKAT PsZUgxBQ30Jw2lhOvZeQNZaNcCmCKiMUY0hFlwi/1Xen9FmLdqbwIzAvKVbN8SidItRnTRWs1QR0 NKduSMGmomcCq2m4/pXjnguJ3zQxuUaGJhVC7gHtjL5EPqDvpeFxiWkhEFqtJDfojRZ0M1+JmwDY 1bIQGYy9EH15WkRt6UNlU4JyBAw95gruurdAZhbQNI1+9ad0ltgK62TnEqOh197Y8ziKJhMAWfjL v02/Qc9zAJUCG1cisySSghig79+EOOH0tRPMxsrC8iCuCaKqADneUVxbx1shDdW+jsw6vegWm2pK xxODERjxeyEYyCcUe0XGSaEagznKyzpfVgyB85Km9LA9uRncBdexXacX7GrLaBGNInSjbw3qA9Z9 YAaXwL8h+TWkX7zE+tfKMwRzTUhe8S7hEi0sJ2lH+V2kU+aixCNyhaZeCHErxcJgDkFPlYCAb6NX 4xAZ2zAkk8EVdeoW+Ovs1eB7xuuh6xvYA5NuZRy6ASe12ySJrx5Foftp2WrAhRvk4AI4YzBkSso/ GTQfFUcKaLE6tuhXjbc55sCMCFLWkZZOeNhIMShpOcg99RUL/YesPAgXmVlLZS10rPKi0Vwrt7d6 jU3p/xi9hFKfgFqwSv/wO4+Jtdblg7eNEbUcZMhADPatmpXH1CX+1tV/w9CWu0JsAWpoufQhTmcd 0fTp6gQjuKgGF0i4GiR+ZXDoq2IMOICwQT6OW2qIulqnz5aQOmJXmUxG9dkKbrzCMSiOoPcSJI8W IJUO1CEHOase3APgOHRrO4CROsg5HNUsaUwxo6CwNlaQTwC8sg9sQNUYjPGMgjp1fX0OAZioFo0f Y/IKwkfRkUMbDH+Xpfm36FdPbqAjcwihhCCr4RlXDM5YVrgo5Bk9yFvdUMJGTwsVigBqbQx0CZKj um60LFile89EldSXVPF1/gQIRTqSd4MbLfrTukVlNKw4eIALiWNN5G7goxRQxR3Uk+odgaQxBryg v2IQlz5NJc8CvNhAdXbT8qLeaQC9g0QaotKGxqnp5C9QCeWQgSEFwSNxmKpr/pbnxS+ivD6hhKoP NjgLwyo1BJgePWSwEf1B/hNkdPo3kbXSmfjVQqlYLRDPCgbYiKLmoPRpPQ/5u7VwCjIcLr8KXAgu H3WNYHzfT1psgeUOurYoadGpGqChi+nRa6GhHEqKGtFHath03YZGPrXcfTEwVtYjdKs5QGlB9NOf IbwCO5k4KigTDwzNeJyrEoj8UVE6EuakQzlkDWRq8JJjKKH7VaGedyMGUslIA/IG1gYjJHmbXuAQ c0TXfYxnFbazHR0HdNso4OZW4+djBCwepBjTlQN1L+DzDGQuMOasW1H6n0FPr64fqfZ0jVjGgMB/ CYNUpWdIA4oxqRZkhAGxqphIKNapuDIjXkCRgfqwFWYtUJFOgeERc5Sc1pth1yphBL3fBtx0jFJ8 hrll8LTuQw+ZQbDd8LcgBEJZxb9Fv2q/XIL4BUn4K4SyFIsWtGypyohbQrA6IPZ00sO1kBM+Cq/k SfFPCF6jC9k68QiGW/W75BahEUzSLx4QzoEjPwp/dMQMxVUFhhA3u96jsC/9oGqI7RiCmepFPOMS 5FepN3Q6CMRDqClw+joc8KcYD2ryfF1Ap+7K1xChqB/r1hmVTjucqTyjO3hkHIz5JzlIxDWiFnTG CE7Cc33KIxLKZ1STBkjFMayzm5D4Ox1OcvjdiGY0gskNtqZmGkKxocJfDVLhhkw5COfWXh+KwIAw k9HKMWLDLAvCPRjUqk9Aj9k2sisG5yXT060dk2z3GoMJtfYC2QCCXRjflHQ2hDkZj248qYwqgY9i zUHUV3gjH8U8ZYOPPxwSEtuo3DYGTuIxw3uLx3HVwIAQJablkDgVLpgKFAzoMMbb+j4cmlEHLQIf 5UXhD1fD4MukzpbySd7CIFVkMDsyEC7E92K0qqhfHBpIZCfdGVqbvKXeFejREWz8hE40FJgcmJyu ozeAPwEkkIHjdUggI6aI3eEIieSiZMs65AIkFGRteriariIEOFOIAFLAbBntpqCkBHAIuPSLMicd QoHg3eDysZPgABTuqVkHX1TgNRohnPTo6ABnDCyeWiZZAGMVWutzIUsd/hpCvIZQ+hn0K3ADL5VT UMrUFlRUK0dkACYA04B1+FEMFHfVTyhO6ysbfIurzscC1CDWlXBGxUDkQwoihiu2gy/GQcvgggoq ym1FzUFU4cBCw+3IAWQ3QVAxgMDBjXZeV8JZ5/5BhMc3gxYUB9NfN2ZpcDZ9XGoKBscydkOEPNST rT6G/439khxUs9z4UEFVSj8QRiT+X8nHpA9TJ8lQiEjvhCTuKb5nJBQHxHEtqKXzLs6U6m3o9KsD n4ORmco80C8ek7otIWzC6BV30QXYTqughxb7C3q7gZHq7IeMOtimPgY1Ih09Ai8qDAv5GNxCPa7b JAGfkDSrs5cf5Q4CVijRrdiu8lehVgKOFIP54/wgi0RQaMnhPSTDzcg7yAN7IhFkZQEe2C5cG2Tq zKmoue3J526476E6VgFTtohIvCBhGJfQohwk5gae0iTU0vJ5tC3yVVIyCSEivbXUPJPIHtxDBt5a TVu8cbP4qXHS0oJz86oF1KWVtYdiJRjDDkFiEteE3FeCGfUofL5hPUNt5Afj5Erjq8wK15CTje5d Ztnxl5aXT3v5LQgY2WvEL1hQTGXDwarzioIBCueQNnTF+vUCNcEkXKfUF80Y1dUUrgRkvCwtjjWg r6KKyumvvq4YCg6Ly5Na1uHKu59+YeqDj1bhsLQMTzQQAxdUOxIBExr+qvCKy8MHiM0oimHz+azI o4JkMQAUMxIQavytnAwyXvzSRT61SE5CdCesD7Nd8qy6PCYJvYxtbRzdlFGBoJDejzmJhISZkAc9 C3iVowc5IuQgt5zsRrYapagqvZ5hM7q6F4IKLZA+/EcoBP5d+gWaqlzb6SWHKuX0sWBOkDCJvVKC YV9J1S0g4Ycfa3AhM6KBaspTh7P2XDCiDdsAhpGsaIXpxGvwcYnxQ+oQlRNXDkEbNI5/kZcOeF6v mZds2gQ6FZ2OFKoGgCwhNDUkYgCnngOzZuYhvSNeRD6qVZt2IXew2lxg/hJmakCyWdK40vmZ+ECo AMjFKhvGOS+JuiPlKTAIzctLSHugWIfcEEYq7IiNMNm/KAPITcUDoPRX6Se9DaeqgFRXAggcDIL6 Kxo4WF7zxMtvgWtxnDgTzaTw7h82byO9EwAqu6woB8q/i4nQvaJyWYEnyzCF/vDKLfdNd4lmokej KCrzeQC9ak278ZHpjbzL4+hS8U6EmHSDjEE4mA3aw5NVePLxpxqQggLMFhQLDDECVdB/fk3DE6+9 pfNcZbnod0n7eJ0Zq/XVwQSVfMVv0jgeILSZmRIZPeXQPM6Jq2gA/iVjEg6FBUeuJSX+wRO4YSHj BYqJkRASRieVKZV4UDrPj34MXCRQBLloTMi/yIJt9VvszXQxsX9JNgZU5ao/+dIrewqR4559g4lT 7CPtoAAFa/bl7AWDRp70+NPTLVamxWpGRlSzCdXMFGPnaXX8Sa8Tju2aWetd1omCVFKpQnh4LCYU zJCQBIsLRdY0K+rrQbNDlnG0gIdnLV6dV1qJF1EfbMGipfVNeMmCB9wmapqqFCEyNSMDDKEvibHV BjI+yI+g4NLs9ny/dDlSwAnai+qnyJwLzHTMyMCB1pCUDeOv8nizS0pUnl/E8pJtIw+WHO5nDgGR behLaFKrb/YsXra6CSXslbAEgqo0AFgRFNRVj4XoSrgCHMUcKpqbs/KL+IChJoEMZsxb2m/YmGlP Pm6zcTyoZk1GwMw3RETEyxOPzJw+cgMAiSiMkagakATv8BH58MPaWUwfIxJI5q+ET+CHcJM/WQpW bUMiqBjlidQzpHMrDXGLiZAEOgqpY8wErxfUYkPKcAwMZdrcjHVGclFmQib8UWmBj2GEzAEN7Ked zcy5NvIsYS3IIdZEktNTE7GWapCb/QT+/t5v/Vv0S4tDkPyBp5/LK68SrVNHAIUMsAhUAY1P5ywc PGrMo088ZrUzYSluAQ0oZIB1IGo8KdTqsZqY2F7eVZiPW06fuVmzNiizTA5yIEMT6R19IwOUdDFr +er8imoWpnD6li9bU9/YrKcLkfGgKTAWFHQDOoH/IiGfGhWel/RUJGIW2nW7m53u7+bOJ4qCZKRl ZPYDciKhJbNVGUYJRog6GMIZSGWcC9Uu6pcYU6OPt4yQaxA9N1OUmwQUQb5tBhqzbFczsvXzXROq GyLzB70pPszLgvrTFE7gA9AbRHfTVUMQPdISgQuRA2iVzU37Sw+BYbJJJMECvXg98+YvQrJ8XFSO Lv4IbSp5rHK+gN8DGqBxgFHBp86v5ZUchDkDDgPmpmicozWj4DkHk110qImTBcdA1TB9R4BsgVBS 2zY0fPBk+r485QqCqoqURyKQhGNo2uFmd1bxQcXZVPuqxojTz7xEXy1cmV/pBENQ00fLgCREphK0 YiSYmgBkS4TkNSE/wZoAjEgGKKFHYNEWF7mKzc28uGrfjqW5IAsoEfwAOxPDELWIV7qFIpoDzY2f Emzwbgcc3EYMAVQSW6NmhjFU7iOi+JAREXl5pfqJCofFgDy2GFZCEeukqNl/2Ks12vgnBnGwujGh bUcmi1HrZDXtr/eiNdxtRpkVq1aFqjQoiVmBYgga8r1Da8CfhfW+Cq9e/yWn1luHSis0y0xIUVzS qJW7+TqmjjbLfNrCLXvyqhpwJdqmPfbw/fERkcBjjKdO04rrRDQq+YRO/fyzEovk01BET2rRKwvO H22zPvbggxERFuAiSq7kVzfVIleaiF6kuUJBJKUcYbQHfVq1xdFsIkcmFxZNJ7fBg8IZ0BbBrOEM EN6tHax143dshPWe++632CxNSChpeBswnWabqRHlXQQUBfUeAkRwBVdKPRykyx7jd0TiFZADCBgF E9BjcXVzUmonFMjgYGSOebUN+E1l1kbtLMfpLicMKcWxTFUYLRr0atVS2qPBpO1vaEZdOqCd+D5J e+gRMMfvg41uNIVFRO9FTW7AKuC6btIsaCe/lgAESwEiYahFdd5qD8FokZM5GF5BrafRwmeAnc2a uaDZXdjkZqFfQTw8UOLWDvnYPuarmSNR8gLtYJlIzBYKTvxgJPtrG+skizsVY4jUYIjz7116/cT8 /y36NWKAgAARLgsrKQP9QGhY5dxGV4VQCjgIEONgQ1NKSnsEwwGjmk3mCqxOk7/ezFsib7Ry1PkE 96xqxpqiBSxfYb0GJCQumbW8Jh8wASINOZMpBkwa2PmBeq44hZmmLVyzI7eM5B/nMD98z12JURGg NRiHinUW1zUbjlAmMa5BrVG07+E4SRoCDm5N2VDE3vHYtPuhiSv9tbimvsoNGcDyVUytjjaFA6DH oiYvGsFoMewDjV4WqZHiL9Qmnf5yr1aPrkWsArfVOAsbfXgYyAmWCo0ZjZT5/Aea/LgLua7I9pDH X+zSmgAB2h1sE4MscjtxRbgQk++gWVwEcBqtjgakCxceQsFiNkdGRj/86P2oPYl5VXvZYHGzE7BF F4GUFchfDOuiyWwq9mjFbg1rgVWAmHSb/I0ohINi9ybOK7/ej+vKpUSPlNcGGB70eg65XbhLxQUc wKQdbNYOofywsa2IJyOtKFwH3o+UzWJ2Q6fEYDxcYo89tslHKYgEoWi5sNF7oJFj85kiAI1lO/Zk lNeUUaQROHDiHXQpEUBtRgmk0gZfpUepFFqtXwMKHXBpxSzmTEUBuIFmCxohQbhG1EtgpJtYPqy4 ju4bJbkxAHCPQ24fxi/eLJgSKF0Ot9OPa7/C55UpbvwWFXt7cc1Tr7xRWlFx3qkn3/63cxzid2LC UxHyf7l52h0PPdAp1Xrd5BvHjR6Tt7/gcGXtpGuuPmVI71c//HTRluyoqJgJfbvfdM3Fi9ds+eyr r9t16Hjw4KFrrrhqxNDeaGfKTXf17te7YF/OnZNu6NGv+2W33z546LDS3OLygwevv37y3AXzaxs8 Dov1lWl3wa5++InnzNHRlXWNHdokPXnrtZjT9PdmL9+woW1iZGpy0oP33nTNpTfN/eg15PKfv2nb +59+2bltx8MHD1557eWjTugPiFw7+bYTR47KzM05VFF15y03jR/QneWIXA0mezTA95e/Xjvns/ea PJ47pz+b2Cal5lARiul1Sk2luSFY/smCpd/M/z4mNrZDp66FB4pff/oBvL50xYYZixa1aZdaV155 72039WgThyW89Ia7+vY/Lj9rz60339yrT8fL/3b9d5+/9eI/Xu/Rve95554K6H721Vyf3/m3v1z8 /ZpdM+fOa98hpbLs4AO33dY+Oe6r71fOmrcgLiEpNTW16EDBP599LFZii9HsSx/MmL1pZ3x87Lge aVMmXXbJTXcMGHhcSfae26674fj+3Zes3vHRt1/FpSaVV5VOuuLKiccdBwXzylseHHDC8YX795WW Fk+ZMmXhwoX19Y1RNvOLjz0SI/n4oVoC/6bcdM/QwQNz8/cXH66eNPm65auWoea4w+J4btqDcWJb z1655dt5izt36X7wQMHjd98cGxf1wDOvxMbGuiqKUX20e4f2NU7vPU+/GJWQ2Fh++JapU9qlJD/+ 9DO+iMiG+uZ20fEP33s9kPKlN94rrauvqqurLKs885SJk/9y9qIlm2ctXJTaIe1wVem9d97UKzEW VaDufOaFuMREZ3HJfTdd37l9InNQI9crikSFhdpPQuDfol8wAzAwMPo/3fHQ/Q/eN6RtDHS4v069 a9jo0YW5OVWlB++86ZbjBnR/8ZN5q9etS4qwDxs84Iar/vTDxm0fff5Vm9R2Bw8evOHaqycc36/J p11x8wP9Bw3Jz9o5ZdLVr7z62pDhIwoKDh46dOiGydfMXTCv1tkcbbW8fP/9KPfV0Kw98PizprjY 2ob6lLi4e++5/rWP5y9duTytTVJqm4QH77nxustu+O6DN+1Wqvzfr9r25ddftGmfeqC0fMq114w9 vjeKDl5xI0eYk5dde/jQXZOmnHRCPzVrJI10m60XXTn1o4/fgOviiWmPJyS2qa2ounXytX06tYdU o2Vj0ibdfN8JgwftKwCel187+bq1K5ZUlldE22OmPXwPLIKnnn3BE2GvrKtJSUieds/UKPGRXnLD bSeMHlNcUHi46MBdUyePPL5frcvz6JNPWqPjaqob2yS0feDu66C4v/rWB4fKKxqbnIfKy08ZN/7G Sy9c9sOWrxfOjW+TUFNZ88Cdd/RKjMNQP529Yt6ipZFxER06dSgsLn7tqYcTpCyc2+Tymm0XXzbl 40//CXKbfPOdQ04YVFhUVHzw8O033HDyoH6sMAWrzmKGSH7hrfeqK2rr6xtKK8rHnzrx0j+fe+21 t8589xVU/py7ZsOX385OTG5bfvjwpKsvHzmkP6TFlVffM/qk4wuL8srKyiZdftm5o4Y3Nrvum/6S LSa+tr4xKcr+3AM3YWzQZq666pYZ7/wjzq67czGSGXMXz5m/2J6YHNO5e2lJwftP3ONzNj3y3Msm R1xFXXPbpPhHbrv27Q8+mLsxKyk5pXuS7b7bb3n8qRfMtqj6ek+b+Ogn7p4E5QNK6iNPvBAbl1hd VX7PLdektE256uYHBw0dlZ+/r+JQ8dV/+eMZE06E3ffQ48/7Y2Lr6utT4qMfuusGyJfvF6/7Zu68 NgkJFlfdS88+AR6+YNWWWd/PT2nXvvzg4QfvvK1XSgzr+NA8+YkP9mVa/uCvGr9/yhtf9p70YK8p jw+b8lD6oSoUcXB5G1ESCA9j++q8Gx5ZWeot8PvHXz111vrtFX7/Zxuzrpn+Ml6s8vuvePrtWVlV +JJT3nju1Lv21Pvwfev+0vNvujfT59/n94+7aupni1c0+P0NHn+l3z9y0tQPd2aW+f3vzFl8ztSb t1c3lPr9Nz72yry1W6t8/qIGf7nfX+L3/+Hm+3fkFmEQeHLyE68vzSrAY/v9/rGXT0W/eRW15153 U2a1q8nv376v/PTr78jERb//pMumfL9xZ63fP2Nz7qTHX0FpFZ8TOglMCn+R33/q1TeiwR927rrp pdfRRT0KzLr9btz2+50+f+7h6jOuuzXbwx5fn7H8z3c8iWd2NfrPu/3RQp+/2O9/a83Wez74rNrv P+T1j5t0++uLN2Ek+Dng959yxdRqr3/l1t3XPDD9kIz/0nunbSsszap1nnnHI+l+f77f/+EPG+99 64NddZ5Tr7s1o8l/2O//x6wlF9335EEZSZMHqbb9dX7/pOfenJlRiCtoefQ1U19fthbfMaPddf4z brg7v8aN6ytKyk6beluZ11/q8o+58uavd+aj07fnLTlz6p1balxoeepjzy9ctxWzdsG09flxd9xf Jy3ZtBPvvjp/1Vm3PrTrcD3W4ron/v7tpl1oPL+q/qLbn8yGiur3f7Ry14NvfT4/o/D6Fz7GRLCa aKfW61+VsW/yC28DjHixyuuFjpVfUYe7wIdL7nxieWH10sKKSU++gD8BogtvvCfX699T6z/vpsf3 Y1kB0nXpt7/7GfpatWP3lOffBjphXi4XoE+HN9Ey/PmXEPi36dcL+j3npgfXljaBAEFfYyfd+cHG LKzg/LW7rn74GaxLIejruX8u2ZmHiztr3WdOviW/zokVXFVSdfqNdxXVu3F99FU3vLJoFdYOy33i pVO+2rEfiPHm3OXn33QPXsH3yU88vXjjDhB4g9NfWuPB60DC8+58ZFlxFe9Of2l5RhGuoK9xl00B DYJsd1e4zp18d1GFEwNbe7D65Mk3HXL7YSSNvfrmr7bvw8ML1u+88fEX0SNwBAnysYkBhBn7t+sx 5vmZeTc9+3cMTJGwF5SD2yBMtP+X64DnGOqr89aefcsje0orgPNXTXtx5va8ao//YJUH+AlO8se7 H19fWIZhVHn9J159w0eb96K1hev3XPfgU0RvUESNG0+C6v9wz7Mri5vXFlZf++CTaBbcCWABt9la 6z/35kfy3CT2N9dm3P7OV5j1vsraMyfdus/Fx96cueji+6ehBfSCdQNTrfb5Jlw6CZifg3FeccPM DVvRxVeb0yc9/ixIjMaTB1VM/CsOlP9t2nOYGrjBeTfclY1mwdkuvRm97y+vv+Dme3fWeDCp7UXl p0y5bY/wlnGX3/rdGnLmJfsrJk6+rcLjB5ALanwAI9694O5pW/NL8DpYzfi/3dhIzz+qFLhxZVdN /dlTbi2t8jb4/M9/t/rie5/DaME0Suo8gBLW64I7ntqSV4gnL5/22vysUgypwe8rqHWCSWLif7zt sW37SzDUpel5Nz/9GiCAB2p9Poxk2BU3fbSF67g1/8AF191Z4uSQ8g/X4xkM46K7HllRXL251n/W 1PsL6gmifQUH633+7Hqg68P7nHzm3fU77nnnE6CHB0vLUmI/6yPberLhAUlut1tZPcsHRuOyQZti knu1h0njDoYw7GgY4/jr5FHHQz537969rKJK4si1SJvN52pCrzk5WV2790iIRh0grW/XtvDXFxTD HtVcHt+5p02A6YMS7GjU7fKOHtQHzXZOa9+zZ8928VFQxzp17lBR2wBr1On1LVix6cu5K0wOW50T yqLsBXpcFiT4l6Gqncf07Oxe/fqnxDPTfu8eyZGxcbmH6lgn2mw6cfggvNKxc5dKFM2FHStV2JQb rdnHkri9evU5XHzwlbc/zjlQpe/Uyj5T/oHinn37o/4Uxj9m+FCVxH9HdgG2gj7/dNYXn83M3pNR VJCPZx3wqrtc5542XG1p0mENU9msDR48sLSquqBGyz7U1Ozzd+/UNjs722p3fDZj4cefz9i7e0dp aWlWdnb//gMTIgi6kUOHw0hRbm70q3ZjTV5nhBxzQDFiIOA5p4zGRdhzGTn7OnXvlRrHwnO927eJ j0/cvy8XFXJhqR8/qAv+7dqxU9eu3drFseJG987dyioq6aaAea+Coe324cMHodm0zl06dezSOSUa A0jr3LW6AU5TLTN7H2KHvvxyxYcfz8vas6uwKL9Hj06HivPfendGMRQdaadjx44VB4vfev/LvJLD 3AyAp9oRsXrl5q++XdLg9daCUGwRNSjjBk9CTQNQAsu9MzvfHOn44rM5H3zyXc6ejJKCAkxsQJ++ 1YcPvv3uNzlFNT6MGzNX6caDETI/C4N/3w/9PPqVUBA4pKWuEDc6nB73+BG9sQo9u3aphsotxpDZ 02TzuoFXWdm5vfv1T4qxAze6tU9wRMVWllVwE95iOv/0ccQ1bJw6okcM7gqc6dKxXfv2aW1jsX6g 5Q7AN+K0XWv0Opcs3/DVrCUem7mqGY4SnOv2cJ3V5rrUy8VPet7+Hv36tU1i/eBO7eITU5ILCvfD MAITG3Z8D9hS3Tt3KikvU9GAwDcEefAkkOyj9+zRrby8+rW3P887UIlwMW53SVQafiwO26hh5ACd OnbtAjxvm4Tv7TullVSW8ayS2bJi5bavZi7BPkt1HfyRrOINp8boYX3xWLe0tLr6JtUjwtAWLl87 a97yBre7srEZvlZsemHYNbVOs9uF4WXmFaIs4Yxv5n/62bycnXsPF8EBr+Xm5fcZ2NdhIyRGnTDM 5yRUZZdI/fabbSx1CXL2eE0TRp5A0HXrVllbp5JrMbKCvMgK4wYbezWVXr/bFSN37HY7PK5Z2Tkd OnVOjkPFUK1nx+SExGSIFe5veV0TxxyPi/26Jlls0QcOYQOHrtFFa3bPWLges65paMAV7jKoPThW B2OkbPaB4o49eyXFm1EGfdSw4dAg8Ag6QjWcVWvTv5i7EeWrGmGGo2o2GKMcMuMZBbP5+5Vbvp6/ 1my31dTVoeXu3bqUHz741jtf7D9QjqImjE6w2EYO7YGZ9unSweU3H6rRsDnniI5atXbLzDlL4Jws r2/enpXTtXfvhGjiRteO7cAMd+zdb4mI+e6beR99OjN9x7biov0ADGXRj2eoEjklQT/CSFXqCn6H yLn+4gtGd0nrG+O464q/dk6M4Y4PTsr7bSqmyGdB6QXZHvTwYf4Qmek+5r6UqwFxN+La9Fil+KaS QGD9UQ7WEI+wAnnozGXUjluLNFkxW/zAy+uBqFFLbragyntelfOuxx6xxEb3HnScLTpa1QliL5oX FZmVFAGK410sjdPrAp1wk4xL4dabZakYDsBmw6CxYcxwHPWMhMT4sTyJkfbXn35iUN/+D7/091VZ ecAk7vhywND9fNjcYkdmJ7zNwtDNbdoknTFx/Nknj7vy7LOmTb0pDoNHyIQP+Qs4fZH/LLkEeoDj dNioE39Yv2HV2nUTJ07kZrrXm2iPOm/8xAtPPuXy88574OYpkXB5ut2gc/ILlK7wNGM6AKlqjaBj pSuGhkLBUOV6yRpw3emOtNjUn2jZ3dQc4yADAhridVlY7LsTWclBnE4rJSBkuVftjcNHz/FQT/Gi mD1eQb9QD2UFGLWZ1j7xtJNHnHvyiZeef8bj99ze3qG98/zDA3ukPTD9ybV79+OptDjHm089Nrhn 9yeee2XV3qKsyuZbH3rUZbUdN3RIVEw09vbjYqNcXutd016a/uLrN06ZjLX329xJbSLPOPnEi08d e8WpY/9+152Rfi3Obv3HU48O7Nvpgb8/s3JvAWN/ELkpRY5+37LqX8/+36df8mKpc+ZG5SnQodnV CLQAGtgiJEZZqA/F6lHTGdetCPSSCnxqs8KKYjNYFGyTQnFTdAF0c2IDVwOZ2DRzhCNKcW3WrUVg Bdh9Re0d06eZIyKGDBlijwC3FAYiJIZmo9mmRNtK8AI0N7zCjoCKjc1RNge7lrIXJFjQntWiR6mw xA3KooHz2EA7qVbthcen9ejX/9EX/r4hcx/4NWSbUl7BzfUCLhKWqdiRzY6oCk9Orf+Wxx5G1ODw YUOwYee3M8Gj0+l3sJqqzM5OHMTFfZW+u6c/bo+0DRzQKyEuFgIpIi62zuub+shz0//+4p2TrwMT AH9Maps8cfzIs8cOu+6806ZPnYzZuZwNzdj4kNZQTDjKhA01flTEJlwTbgn6BM5H2bHXxccs1giE m4kXnlGBGEpCTBRqh94+7R8Pv/jyLVNvVAXraptqqAGaXFxHgwmAZ0VIVAsWAjSODx8Ge3HYC6tq bn/0YV+EbfDA48A3EGKuVhB8HQugF59Cl1SfzWACCIGhimlHVJd2oLbqnienNZtNxw3uHxFhY6gr 15FGHpYjv6Lm9oceM0Ul9B00iCd50ThWJMr8j+end+rZ5dFnn9ucng14IhYR4l99THYrWF5ejTbl /gdhmQzs1z86Kh7YhZJAZlipSiPRa3RpiYlgROPPHjf6mvPPefLuW+FN83Cr9yeDRxSaqc4U7iqs 6hZvffG+6z598b6LJhxPhitIxQek/JrN77F6mwCyCBYrExbsabaiPKZEPdg0VyySn/i1Xt275WRm 1jQQvXbnFDoslq4pXFcz3AgYt6reifg5HyL7pF+LxY7/VLFNtzMywr4vO6d9x45jhg3o2qVNU0M9 I/plUaMd9uo6Gn/4OFiYHgpCt4KCgoom2gfZeSWIxOqZCgsB60SZQaXHiygWGnmMDRN+zo4kCLCq zgOcOmv8sGEjh2E3jgVyRR3o2bVrfnZ2vYvO+lU/rIScQVO9O3coKyqIj4ntnJbcs0ObtnFxrPfk wTD+X3vfAWdVda1/78ydmTt9mApIR0ABayKoQbBFjUmMMTF5SRQLghSVXhWRYo0pmsRo1MTkxRg1 YI81saGoKCq99zoDTL9z+/l/31p7n3tmKNE89P3eP/c4DnfOPWeXtVffa69FuKlVBw6O5cGfaOSM Qad98M5bHy5a+LWBA/Bnr+7dG/bXtMvL6tahtGcn2Fkl3Y/quHHDeliXGPkH7y1EpV+FhrsiuYhj SXLkAGlmMg4OQmpP+vr16Llxzcr9CMGEZr1hd5bjdO7UmRW3/TR7RGg5eB4PU2/OAjKShFhNSqUm aEoO8uVAlWGoowATkaooZ+zz9ezZc8vGdaUl+d07l3U9qrwgmNPUHIZNd/5Zpw86c8jKtevwcGNT JD/bf97gAacMPHXdxm3rNm1t36nTkEEndupUHotEszMy1ixbX1nZ/idDhw0bc0O/E/uj9z7du2zd vK60rLBzx4q+3WACZCOSsqk5mR/wnT3o1K8N/tqaDesZh85ijYimViUhfR0GAp+PfkkIILRkPICS 2OIDKMhCWWfiQzTSglBHKDf4k9XcWaIa6Npl7crVNQ0Mql2zsToRbu7RowON/ngcSE4u7Ef0AYcn GJVIxqLqTkDpJEmRAMxc36FLp8Gnn9ihQ3miBUyD0f85OTlNIejrGgyCkGrSTr9ePdetWbG/GWzL t27TjuxksutRHUHytAy0L8SDJJNo3BIIwvoRbBDBu3WNTmGu75zBJ55y2qkr166lbJZ6ZEIpjIAn e/HFsyyeJyKhvOzAqjUrqzp0OHfIV9tXAmNDTpy1n7JBbrGoigooplKz07d+47qK9lVDThvQtWvn cFOTPxFft25DaWXVlcNGXHPt6BNO7I8Xe3XtXL19c1Fxfvcu7bt3KOpQQu9J3969Nm3atD/KqLQ3 3nhD6ZHkSSvCQQQWuhMahJ4K+IuHJhZBzWRltnrCcPWqVWVlFUOHDb9m9A3H9uutPqHCvCw81Kdn j7XrVteEqK2uXLfVHwn3b5+H1qKx8NvvfUw7ePWu/KysyvLiNWvXd+x61BlfPaZr54J4uDkoARMi v81pXs1RBcN90+b1dRHqvu+984YPmzY+36oNG0rbV555Wr9uXQpDzfUZUsASaBCNUg1esWbDUZ27 Dx5wdKdOheI/5RLXN4TATM4Fuxhy5prV6wVDnFcXrcGQlqzajNjqqhLf6nWruvTsPnjQgO7dj4o2 hbDivTt13Lh6eX0Lo6eXrV4Nidv36K67dmwuKins2qWqZ8fKAoh91FaHsLYmxMFpwyTcEnZMe9I+ RUPBfhY04jfqwsL9AidWlGjJ8+VmI2BHAg2CTjjIcCReQezJttTl+jt3qiy79LsXTZ02ubS0KB6O TBwzCnoNHspB/L/gNJx16BKNgEi4olRsuPDA3Xwnnh1uOf30gQuemj/nrnvAxyuLisG7VVoMOnXg bx986NnXut4ydYI/RhHbtarsexd/e8aUyR2L2qGvSWNGQl2CrgHNRKbmK8pKZsWbVBGDSgJzL8gU 3Ijo8S1ZvfKJJ54oLm2HPeSZUybze1nyblXFF513zrjrJ7RrVzxo0CDQLQZ2dHHG5d+9ePLU6R2P at/S0HT+uWd969zBmTlAx5iaWUrkeQhzFY/nV3t0eKChunNFVRdoJI6vY0XR979/0eTpk7u1b99c X3ve2edeeP6ZF5x35vU3XF9RWXbqKQOkBCEHyYh/WZesaDiIkrsUlr6cRAyCTa9uldk/+N63bpg8 uaKiIhwKTxo9CgoWtr6zGXwq7MlJ5CWjKgizTVS2GR68GfmJaI7UQSxIxoJxxmHRJRJrKZTDnVVl RZf/14+nTJ7cvn37cKj5grPOKS4sevyJx0rKy/Y3NU2dPAXPfLxi1aMLnixo166+OTx9+o3Qn/8+ /68z594NmVRVXJgVj53Q5+gnH/3z26+/3tLSsnHT2qt+8qPBJ/a66vuXjp06pWPHjs37Gi469xvf Pu+MD5cs++PTTxSWtWuqbZg1eSonCNtd1BHlaOnrUBD4vPSrgg1YkSf+FciuzFgYeEvt3J+R7ySB GLhyYG1l8MBap4qcH/3gu1OmTS0uLsbe9IwbRlMLhqRJRkELZBHYTYiF8JaoiQ5oX70FOfB2+imx Tj/x5OfmP3XL7T/HEZoOeUX5UQcvnnbaaff+7gEIiZtmjMuCXitlpnuUZP3oku8An8srSuOh+JTR 10HzBwWpDk3p6ySzYi3qQcGFMKhsf0ZOnOP/dMOahx75Y2WnTs31dTPGj0MXEKp4BbptHqS4vALb I9Ohs5GaMQp1R0KDBwx47cnHb5p3J3TqdnnZeaw8z0fzHFIZVUOK8BZwpwH9+ry44PFbbr0bt8uK 8nMcp0ufnn/50yPv/OONaDj8yaplo0eOOLVf1yu/f8mMG28uLy2LNbdcePY58NZ2KC371vnfnjBh UlVh0VmnDkRktGwuMBg906HTKSMeAqfCFVS/ICSWL5YTIafSKq1QM/sc0+/3jy145/U3m5saVq5e fvXwKwce38PfEoInLb+i/NLvXTJp2tT2JaVOKDLtuhu0tcqK/EWfLH7ymacidaFRw0dgOl857sTH nnp63t2/hOOqrDQPSgIaB4hyELfObric+NCtOP+Crw8ZPXlscVHRoAFn5Cfokzup/4mPLXjmljt+ Dvu1fWkRa5eDCX/t9AceuP+19lVTJ0x6+qnn77j9VyFfoqggF14i8PZPVq/7y4IFeeWVTbX1t4/H KtOB9+mqFc89Nd8JNdxwzdUlQIPjer04//Gbb78X56KgOxc4LX0ry79z4fmjJ01qV1JcmVcwa8Yx 3UoyLr/4ggnTJ1W0r0g0N10w+IxLzzuPgoLn3I/QmSA17flbFkZdz7Au0Y2Y/IJ8EstH002exFrB px6Kwv/G42Mwa2BnauVb/AAA4OLgqRyoiAEYfVTfYADRymabeL0h7oNGzz05Kpt8HQFUOBuAJpSi gHkYiR4QiUWShTmUCLiDkeAORoiFg0DFHaw6D5bKgRs0AG1EhUeLHCYszBICUEWPIcOZGE89Eu9k iimjipWqt9g3aooV5GblSaE98fUz3xf95RL7Cx+R2t0Yg7o9FY10RhhAQ3OsDAcO5Bl66mOJzMzM PDAaeUzv01/hLSCE8H0ZXjacMzjqIQd3GNAciZXnsCk14dEjX09wzOqopGNH02GJYwePqg5LW1YG rJOib8RGVGPA9OcgxLk5XpQfAITxMN6qb4qWFGQrlPA83PkQpdDZuZp6pyVZmMtz+jBe739kfqeu 3b5+1lcwwedfX7J7y6aJV34Pj6HlveGW9kHq+vjBWziiAAW2BA4srCadZcAEhB/TfZ8WbLJWR+BS 9BAOJmqlfIBiroYCLsS10zmJb3FAWo404TH9HW6JF8F1YFdZiR1foNIyvqW2qtiOjLmi3GFrBl9B OdOTc/XNsRIczZHX0Sl+cHgLCJkrDxdK8gc9vcSTUvFkaUDyrikPga4m9IzNN0ENCgbqxIK3eIV7 IvIB0dQV+XS4A115XFSOlOFbxUx1TCneKjfAgPBtXSSZj01y+UpdHfgWv5WHsDs9SoUxh3353Evh W7/6w9+6d+/+zTO/gjE8t3DZurUrp179Q3RNGgnFS/MQoUB+RdwWMoEaDSamZMJDW3J6Cg+rNYCu IVR5yEdeoRYrlV7BWODn/cWfn6ro2PVbZ5+MNl94e9n69avHXXUpGi8Q4kX75AMxX3GWD4593MGf YDJopDEcbxcMqMKNZkF3NZFYSQ6XCPGaACCgjXnlA54yWzA6hNRzCvFEMJBZKNySu0sZBC+2zhBW DQZeJDTZqFiU8IEH4qppiuXD/Bd+S0zArHHCKuorDfpKeGjYd+HwUX945LfoBUHXuoGlUG2M4NSH TFnGyRURX0JZQEx/eQx8rzocqYSDlVoXdCZu2h1JwQbuz+wQcraAISQiabBI6s/FWKGXJSGy8QdO bAToZFceqvxaWKs4BlWiiFUCRySWA+YIi5gLqyUFoItkEoEe6Eg5NacNeqPM0WMcBjXdlC88Xyxj 4GLgATjamAQbhgs71VP9um0Dv2qKwmX8ap4qcJV6lZ+qYMBaMrWiiF7Sm3SkKEiOkMQZbpvyXo7V M0GBsmxJtkHBxoJj4poRqayGL1Gc+5RMEafjwY/sNbJePBwvAgb5xdLwhh/xGeENaIRgF5hSURD3 KY9Oy5NGNGpHAjG9BAk5ft4Q7oMGI3E4YwO6uAiizs6khFchp08S/vItWoMOAHkD61knpC2r8Nbh KOvEi68uXPy3Z5455bTTsfP80UdLJowefULXcqjnzIFgJ8soBjkthMtIdIUOj3fb6Zmxp//5n0IA 5IndGyTsyIQXTFm8nGzhqilDVeSXz7qIxHlZHSVe0p+gE+6xuoUeJRZxyDOz4MWWAWj+CMn2wx8l K1w8lG85OBsRHoJLuafKEjxJY12eJDoI03ffVSgk4cbIZHkBlb5KwkZj1sgCprch5cAgwKx5NjwW z2WYBTsCk6Jg0xQHQp6qZsViCMKXivHKo0RnlawlBrcp+HHm550l8599+uQBA6Ox2JJPl46//rq+ HUvRIJy2lE8ilkDLuFR0EW5y4JVTlrEyzQdOrMu3SuoKZwIt6WT7/dh+AwPEUF96/6Onn31pwMmn YKf8wyUfjbtudD+4a+j6IrRwJlq1E7yNPUzulIrnhsFcljMwrQZYoi2ZiPtMdQHSwx30pbqtsCSs gqr7eIOGLwbD1Biivojeo+sOqHLnSdUjeV4PUONXLuxv8W+qTo8HMKrmSOLSa699+I8PQViq/SNn 37lKaAY8UJalFdclzxFsYC5DK++VPRLVcHblSFlsRCZV/AERhYKMm2mWZE2UaSqGJWMUbISeAM0s p4YvY6hw7Cdw+Bsu97gD5oo8FPF4IBO8FcsktEInmbI/fsD/ceyWUQ0i2eHCbPGfLRUhfYo/WqSA ZNuFdJHPqrOhfdnUlLEZQ1bIRph7m4tYIfHm3FnkWWFmpZFkpUzxxeaQlYNdWcqlTSwKhzbHTDOU dqRi0pboPBY0zPgmOGFggtBk+P7dESQcbFzahzVJn/zFtYSvJIktaDmAKoPW3Arw0IpjQRL5cM5g Lhg5fA4IYZJ0E7xAvQBsFhZFCEy7IFZBiDLCRtmPiFc8Cvgj00EinolFwWYAzCd3UHhAUoQhCtif rZq6SceluCGb9LL5jGOVDaGdu/ZkZAbgd6JG6WGa7FAzENpCCZwSpyBBDNy6xG8SXfo6YhBQlgq4 gniFDBQVlQLU+434DdKZpudRNFFRZGmfAgNYbcSUsD3She6pgTITCB9wX8OT1HWp+WH/hTSlQUyk GMmEJ5U6rXapIWmCzwYZLH0C/ymjDG4T4yRJFrpUlZhjVUFoBJIRkSIwiU7YScDAROXEs1SLkeeK bwH/kYyBghmmAOfPh/UpZKhiDA3IGZFu9lCl6mT42dPYsnnn9qzsIMKPYY7SllMzy/qBlBrAizBy vq1MwiC5GYYhfNehYt8V5gJuiGnS+NxVG8IxwaysrKN7dA6KSBZdFgnPoJVQdVcezClQgxBOSCHt YA9PBarCmvMVKc7VpGwBo8CKIyuInA3DWMWLpEuvTI8cVCEjbI0fMCM3AZjVHxQsxCX2zZhUMB8G ooCVYis0K+P9lauO78vDedT4cS8eJj8HInHTRlZJovLJcpX0Zcy6WLoxgY905DIPH3nSkRRsuioK Kdnf5DgEOSCr7FwNOciznJ5AE3ILjN4AXBVCrCnuJGM4Jc/IJl1yydyFJBfRSJYwTeAFsE4sFlwZ IBIRTCrqEZ7DryDnZBi8qeiuwySpATUZg6AwJ0mq9cM1QyO6/vpVPImYL5F/fF6/4VzjiQDCNuWw JPPFCCeGMgUxLAxYU1nyFx5QaGhHwvshfyWAn0Fa0iR1NhI0fYwcB++BGTB+UYhL8qKIfqURaiLf OSkhawMEDBLcATijBmhmhnIGbjnzYKrVrBRiMXlY4KVTEk1WwOBO37AudEf8lPU1wER+Spz0gJST mVJk4kV0BbjIMwi58iwfIxkR0ErRbkhLvM3aMzdFoCEijx8UbSwrndP0QOIrPILztgApwpTx2+bz wzdqeaavIwQBihdyG6kTLAxFuBsUF1cfUgyhFsV4+qSHNvku1p8b1DaLCdGADgdwfijdRhltPVaj lSvpKQKrdkiFz3vRDARegclKzlWjyELNEnFhRIIMLAHkobwUoiBTNLnihKMIKySTJkZlYM86pRmp CYdpAKtBqpnIQy+jisWpNPM5CiWEuDP4HRSJTEQSHMpLOlVXImPfMSShz5Rlo9hsU8ZKxkNM0epl OghMilGcMlMhRksv+OwOkycxohibrI+ySkl5BRtIKJsrJ+qrhC5i7mSeGLhVRJjdF0xP8wercKJk EsGsrBLRjIgdoXAQ8c1CHwoZzlPcTJkUlugbMNT4c7IRMQyUdenzajLpi8p4LcMkZ1COIRDLgGsR qTkhU3GWS9geuSPAS41CTH5sOKrJJxYOK6+RxwD+4BXkR+AMdDMItiJdFYvnHWnBpjyfyh5hRk4n TNCghayWqFCCo7AbEGvEGDfh1LLQiXgUGowEtBoxQEzCalGfomATdV3kJcEqkxHGLrWYXOKghFMQ azxvLBwOBk20sVCPqoX2DbtyyM9Ggwu52uigEKmr2iPwhof2YCJQWiiDN+KERcyEoct5Mpk/PXP4 QVJJIVBY/xqeCmGjWh6tf1TOzKJ6JAkcFclJM7KVJ+kWuV0tO+RMOCk6LQ0yJjz1liEyg6G2i+Km AlUCnP2LmBT2JI4N0cRkNlT4iHFGeENdpfUGGIpcUSoyn/lRxbZoAkR9ErxYmuqf4m9EvCHAWmxZ oxtg1RSARmLagUl7tBfF3WWuaDSZnQMpGMO5Cy6yqjs4xiDPoA80EolFs7PoI9E7oiikBZsLwiPx wSiOtimehhfRpSKGDgzPqilJe5iXvibGE8J+437dI/a8S21RMzMZcwrcTBU+KosSm0GGn8Wcj/Ac 0JeoAoChdKr8CW4rjxbBB+0RD2NXmczdZf5gzWoFkn2ru58KJ99NIPIwKyPqxDKB8aI9KlvXYdJG 8dRjEqcLiZ+6pXHdqIsMUh3EqDxKzVCcvoMDA1H9mL2IXm5M8DwTLFHSjgpgDlhsXgs4YVPCYowK J8MATHjgznAe3CHzyVHnpXpmlZFq5miBs9pbgIRYAeApOvhYOOryPTAcnTL3MuhkUThKHkjq8bSP pAv4CYV5GhkrPKSVCSFuGQtvSJssoUTABEAFzK2YZ5NU38Ex6NRk37pGhBWXjNwZ3zKbrowfcxYT Uhkv046Koo/XMqkuSGUyOYgk0xfjTeQlf4QhK3yALUdYsCnjE3tNOLUCCGgg5rYOSOwN0frV4DXz zIJMFkQURkmVivMmYLIorkVpVKDHEkinxBkYCx1IxtBYs8oiVYVy8C5hpyooHX9xHKP0IyeBSEPR eOALdkir9HFjWeDKo/lCcnVNPcFAoz+SzEQHcX0h9AVIOxyPuPgoOkjawGS2rDSMmUPvyxC9D5IR 6wjLhTjN/NuMPhOBLWqR2JxSZoiiTw8EQdzCUtEpixfW6FZCP4Q5XIKuIiCbCojpt9VGxA2NVrnN BiSORDORu1ZsJtHJrS4mHbot62dFUEAAJjUYnLIAu7b6tGAiFgI6snxLspGU/9QEzeaBMVVV1Blh qHstotbiACF4jeK94o+rIXKCdHiqWkAIU1ez5ukBTmI7h/S//yYEiEsWwz2KtmdRUso7l87orDiE ihPByh9d5Q60j4ezWduBKA6OQHUEu+NAORorvMSxJZ9Es6XnTHBSKUjVL3XH0dbC33CLIe04kwyT HzMukVKO+qPIBg5AjHvxKAiOGQ3VcGyxcGTHEDQSkKgIfCNSCpiJ9L1xMc5Is4p4pjIKsBRhiEi/ LkfYlWspm9PcTcY4tB+i8DMFsiizDdOzYhcKLVVZy8xIhgwz0CNGekGBC+AkHf0m8g2VXcojUcNV UIsotFadHJHgFYf3SI6qckZ8ghsy+BGpTGGj1MdvE0mYBDCw2ZRYsTo+13/DXUMr4wWMdMPQr6aO YpUewt9kiKKqiDFN+qUmQHolXLDUyq+sxQZl3T0VhzzG7F72jRgqgsByOebFg1tmbwPCCvmxcQJF /MSqkcM5TLhjXmiLBo/Ml8OQUdCzTa6pqsMRudT0MD432QnTAnlGsbH7xiKvMsH3s2kzqupB/BRT iKig3i4p3y66nJgZ6s9VP5kxFTgfPE8c46po8IiaPRD9CmKpX8i1ofZvelFvO37jDCHcuxT15KqG GNicdUOK4WVc0Oja0K1itfeSpuhsEZRTzZLLb93Q+kFDLbR3kD0aoStc0IJUFBAyi9LnSbzxILs2 JYauK87tbrwMQ6WFWk8KN0bNKALKnrAqNqKt8T85nGLWRddLyVv9uooQ7n3FXeOmQBJT3cpkr5YV iTuVctnFci1P6VGiFVqq6BnYGc+P0JXVTT3ISPQ11CvtK/xtO2YNlD+mryMCAXAU1zVnjXIrHsTg 9ljk6kyjwmF0cGugEzdESTExt2Q2sr9sQwmUfPGIaN9GsHHdNXhBVTcSFN3+uo9LeqOKSncTPmst DnUrCqMjs7fyUVBXnKHqYbCiRbbmWfpX8NCVwUR7w1vYsnyVBebj+htEDtCGEJRWzdNc1vFummQB E+NFcAdjbBdDUYLqBpKu/akWmGXCVpBDbNClplokYWqNBPEQ0h9D/Z1QEU3P2oWiH2jwjtiSJJuA ngmWS5w3vKjKQ7DRouQfNM3FV+xlyBoWp3yDxrzE/piSAikjzwLZJUURv6rrS2vyQZVYs3ni7nYK r5TT8hTjDKpMMmcpHgX2WL+x7HcKZxc+YFDOhQzloJGVXnF/JAWbgR7NLMOSWMfBJ3E19lKuqaf+ jHYhd7RsjcsKXaewCcMQd5yxpTBJhR2fFt1LxYwXu7VsqxqtLojls7BQC/Q23+p9+VrVOvmQGr0M L2V3upNy8SZ1R0PHXMesgtzTuxU6duHdkahWZpA51d5BPllk5SDt89psG9im8MzORx/zCufWQDIT 93bqLqEhWv5jgwK4J6P7f+YNMx7VDxXLD+jAHaoOQ5lUCtYeXuAuStv2Dwue9JefFwIu/QrARfcR VdL9rEvkompbLHHRW1CQfgIeBjWkyrU1vE02wNTu8a4yXydWauiGdnNwfBZES1Gx5zG8lEInO3+X B1ofjyhtrsvRg5keJ6edqUSDtUVjL2RdMnTHZBgII4TpRHOHITJbXXhuTArrEtqtd52vexmKsH/D t4SNPwU+HUFiIamTFZf24gpdMVk8S5WSxh5Oy+Wwz7ReO1WI2won7dsO0rot2yCEXbs2yKcOT7Pj orzHsG6KSJc/uHxbg1jYYytO7sLHVYn4jMvIUl+3sTzajObz/inWijiKZFHgVoWpJH+kJJu02dre OeBrNcF0bUTBEJWEqwBz1Yo03rd5ley6tenmYOP/DI/oawbd3OfbjlnlsYhA2d3TddJl1r0H5lqw HgPxDYgzWN8hdur7B2AAG5CbB355qAWhFag9W9Mt9aSyD8+Su4+5U/N+aHPzwLUz81SEM1O2n81N zzAPCu4DJuaVat7BtsIblwm6RHsocKTv/3sQsPSrYRfi5DYhGAfBEHedPJzdfSzBZBdCxfIjIW2C 0rpfDl6uf6v2aF4zWMT2DEEdEp9TaKWMwqK9asZepKO4EfWa3FQCJfiAilgvlbXGSdkpFBJUPRZm nUuTloTlC9uEBznd+2IySqEX8agrQ1Gbz4RUaAiCZzDuurWiG4GSZgWCBxVNsR1pri1TOtS6exiK wspAzS6QhN3ZmwSZehvtj8tcDkrOIupklrqaygxTlyTmFJcYRQOFgmHrghaU/GKiMPhIgMU6qyqo GSJBXio+PNOgadq7zF7guwz2CLoiU1OxratxpVaXAacOImW7GK1fQkLoQ2NUKg4DZPFAAudCPmpU nQQLMMFpjgPI6sq3cXpsEXe8q5yCrG726mkc/az6gvdOyg5z53DQJWSn9omUnsghmsJ14rWWvWvi D/6PIx8iHNMaTeJ60t0AaBMGnRqV1WVoA3nHaQOmrW3kjsSAyR2Vqw1JmxqfJl4Zt2WPjevhAXZd BJ8sirf5LN9YV4Z7+C2lVrsWrSqSulHYmmO0xU8zbpkFfsmycZNWcOTAy+jq3gEe5Kn0rX8bAl70 dsMDPGyxbcOKyW1wTDZXERuMHRM6kZhDV7Q4sU7I4ukdowNanGhGK7erLxjgQcBWeHsYfPbimcV2 G+ih5z7FFpQALhEnsnFg5oPNCNIIy6VK1hVcJoKa+jSPKJjgfkuVKZpyuarL/V0YebejGS2fYI1T MeOELswHfRxKMEPD3Ms7HaVxnrRDjLEYbXqkx9w3vM7zRmqnM2VgeWjZE/YlXZuGAALZ8OGGogR5 ppDB+mYk+qE1J1FYpVZNZ2CJ1+yH8BYTh1Eg45drxaIHLbOImAAZiWkHrwtz5whklWCbunAj5xEM sQcXUnI05ZI+oq5IicanRqTyVfpnTIF1E6eWzUzdK34MwFx2JlkBGRUi+gBlmzttSjSN0ZLjCnZb KKWI2I5MXL7br8Dr4Jf02yrE/xAP2tsewQZGLKLRDEBjlaKM4kNFJNVKeSLkc10unasSqpeH7eCP A1q0C9yK73v+aPU6m1Md0mPSaZNePG39jkewURFXcatKidq4OlQVbPq5jdDWDlJCy8tJUyLXBZVK OO9MPyccPxfQ/7MfNkGRyk40opa6tT3/fCDlHGigtwagCcKS/Sr5bBia4o0bmiTmi1E6JeBZcamV 5qR4mqIB+eMAfLZoZ9HLfYBxJ5EoslAaQ002qCzTT2lRXsLRoFzYXLqr1Kr31Gh0SCmcVGem+V7F j4REQajzXI0bgigmikYAhGORnCxEfZjdyoNyqDhyD6EAoUZXMQi+jWBTYUPKsjTnGZLdl7fOSa8g JHMyZqlKDgGBHPgwJ/namF8KCgWUK+J0ynYEunYS/OPZkpRvqTpo8AwAolHT2oi0yXKQ3MZjmA6q ihOUpk3ZzrSKlu7eKrfR780d7yiOpGDT6VIMufFSZpXtP60FC/ZaDQbIWzJDDtQKap6Vke1pVXAY UhGJJnIl8ofqnlendz2/2pVX12gzhtZ/tpIBLgM9lPTTd1uTjVk7r5jxUJ3uUDBKRdShQ11tSFT/ TMWD2ddcaYcbh4oJPKhE9IIkNQOvYPNOzQuUtszDgFaXxFxe4Nt37TBMzW1deVux3eQOd6HhhXdK 5h124eTLtJD71zD6fE/IIrUSbC6YvZhwAFaIZEpdkWgkR0+aeuKZsV6RSCwHZVpwuaz4YOOzSET+ cCh8drMWpDQ/sh5j3HhbbX0mgThjXKxGdB8SQm6ipEgsnp2lez42dru1eeE2YZVvazPx+LDstMmU YBhK6g/+o5t8Gp9s7EedbRvt2xKXBjemwknMtj3dRdK7m02ojWxrbU2xfa854f1WU3mYizEj+HhY 3aXNYE1MqzJIDx84EL5K4614r7RlOJ58AYUKcg45ZtU28DDPA8WY5HrS8HPD0wzbOeTSfr4vdA00 vF22jl3PLdvR2bTiW8qY1NYh59fuGGvLIjAw0pifhfqOEXg+lF7R3dfWdOQO07s0elMbt1qVET+e O/KAtO/hkodhrm2lmkpy6dcGfcjMac5jnTANntfE8Q4bqKgdiaFtJq6DtExf0MkMxvPZO3LPt1Zb lKYYPsN2BDFazVHvyCjFZytPulDzLoqXPaU+u5gowD8QPG1vymM6PfcrN4+2Xeg2q+BtuRVkXAxJ rWZq6OlPRwwCKhewZpppG/tKGq0q6Govl4rtuupbXmRGGjjmT5AoWWxpKdYJ+jnZOci2JlzItphq 2TaknQlzFCHkxWc7Cg+WujzEuIjkTS/+QLMURyiPDklyIMomGqS2kQP4g6U1OTKFYaOcDDI46vNu /L/p186uzSpQzIM1M6GPDAiqLT/xcBv/5BFebB4ZSMQZrq3TtyzUNCd/SpJMm1OLVhvBJ1uFlsz1 aS/pthmO+xWlZor8JQ8EjxK6jFpZFnJu0V42dO6BcGvOI9/rRmpqJygl1WQM2ozGipsJK16pO0B5 p5iNwucF9AoKWgKCQrD4MWT1AimCmsv7oZWZI6D2RFi3gcbn/VPJwJyGtEzNVTEMhtvZqiugLfx1 whKv70ppjc1VYQ6klEQXNi5ZTt3bdgihlEhoTZNujJAusYG+1RE8PN6Ixtbur9Qw1c3oQlbccaLi Ik+BtbuxDSix0aZGIh5mzkwJ80+turvLaAdk/tV/ZF29+ourirqKaiqm1EVBGRrgqqc6jJ2vjMmC ug3aiUPEAsRqx2bjVvDN/ZwC8+HtJILiEJFRLtjs0rRFAO9QPFD2EqzO4xAPtkWn9N+fHQJkxFY0 CAsipBkULpYBMUGArkiu+opebdZC20HQhJ5gwxENxSJ8BNEiZYHed0mB9VmU13uW2Xhj8KYoiyl8 9hCL0qHxW7giwYPM7sjk1KwyT3NpiL97vN/Mxf1a8dM1lXAINYlkdeTgqYAvD+toPXI69zhfmKfS G3rmoVLtnoBjcgYexZPGwLHlVLI59enyEO2IZxwkR5XAPIlswMgRSfemTd8sPajItDzMu+FkvzXy QtaurafHzhpdIw+kyygAHI3qOOjVio0oh7HPKTTaxHUrVuCS07gqlc1ACRJdPkQW8YwTJkxrllWC +DxnR7VJI+8EZMbeb8U5xXFtgYD2DzXyQ0zIQKqNYWT/RIL5hLN1X8Onm3as2ra7Bs5jyH8eheC4 gUv2OZHRZH8GHvgXiSyZilvUkXc/WIzlkxAmgZF1trckku8u/kB2ZNGiTlhyNZrBUr1KUYfVgVQh cDEVTZq02apvyLs6MHH+mtZ0aAf+eODiKjKQ0CkhzXWi2Ux/8fbqmtvv/TXLCPBuW5kic7PtyYcU gdmxmeXx0Lyri3pe8AxKY65cjNQWD1AgvJA38EnBwfQpFmQb9NA73jcOwBNFVzcyShKemppO7rOe UZmZGUzQNbWj8wo0u0YWZQ6Dn+mvDg+BA5fPpQ8UYnY276v7dOP2Vdt27gtHhCQNA6JRwYXT1y0p W3ZDz4RVjFoSzrsfLKEmbt8lufv94UQcpC3Vn11MNyJMJFtq2HrUTVR9g78uZ8TfGJWbO9hLRK0m 5qEs7vkIswHrGDf1Rr4rck5/lBtQHXcHoEaRnSTSNS16fzGiGw0xWN3KyzpcgkLTep+bZz7f+Jk3 U6KZo0NmgnKUMxM56a+fPlOOp6bElKu3CZ6LmHOccTdOl6Io0jAqdxjOpjPUw+YZlH+WeUnqZ8MJ 5Zif1EKxaneKvlxi4wdq7PB0bty1b9rcOyZNnRlBJovUMh+EhRyIZAdKBV01wGFLzb5P1m1cuWV7 dWM4AukMZJB6Apv31n6yduPKzXIflSV9mRFUt5XiJMs2bF68dHl9iDlKEXBkYuuNED2o2GplKR1W sCnoPOJHwGRQwpiTCFIk9A0K4pD6hFvv/tUTzz+w4IWrJ0xf8Nb7WD9WDrXNUHiwpqUBggbxA7Hm v7pw095GVn+Ihp95+SVMG4a8HhkEl9RFaY7Gn33xVZwlVK8C7TMIcWmM/5K01BGH12D5o9tkVAxS hS9OLouu5HvqtQ827GkUoYmQnDgTXbhLKCk2NWASucjQgoRF2HhlmbMMOSVxcJIe/WqZHmZp4yOo cUgtsyWWWL1lJ3rUNJ3G2KIKjClIkixuJoufHT+Kokzfw5BkoUNOXBgElTpRajgZ0jvNdgtGi6pU +6RBsg4GYcV0jewy8nQ/P6fkJ0eEPQAZGE1PG69F94tHrJmxA8WkKS/OyJhNnhhju+KcPkCtpyDQ MhBgwStvbtuzXzgjduSRAAbJAzgsxi0zmFe4YjLKiiPMcScwUbLmXyBJZChgHTj3cvWPA6krfScF gc9Jv0T6TP/4W39+L+n3xasn3Kj0K5ndxA6j5ofdCy3toBoMVxoPLHjp7c37WhTVmxL+Z156LZKI qD+Ao5CorFA48cLL/wiHNfM7SUBCOMwZGDyAlbYeNrbK1zUXETIASvlsNB72+558/d21e+tlcgzK oI/L7FRRYGELQHGewkwbFDeeZNf1rd2yB4PUoiLoGo+BvT758hs79u+PK5kKBzCBuWzIScQiL770 QjgmBUJItiInZKNHnGpAabuNIM0KC2K9bzCx1Zu3SnCAOaSEpFYSIUpdAYBdt7Pa8AQXuTljXhLR L+p7PLZpy26tscVkTAJzdMuMWwnWAsEPvp3/6vsbqlvI5ZJ0f+oKiUMRwYj+J199a0MN6mUxx6Bw QqOFSHNgKKgSRAMJhuz8F18+9pSBc+bNzmUFcmMd8auYSEbNh6JcRcjZaAPCQMl2FeVkTfG9miv4 GT/3zocXvPTIM/+4ftZPb7r7d7ua4wBOk883bt7tDz/13CPP/v36W26/8ecP7G5K4uG9Pt/ouT9/ ZP4L/1z0yejJs5q5lYPpyqIJ6hgGZrmA/GshKH+YkZuxHPQfHahnCxE5YUK+QLMvo1ZGlpQsYe45 AzQfdQJXDL920thhY8aOf+SxJxoBFCGFPXUN1fXNUV8g7M+O+rLr4xTLO1DCC0V3Er5X3/9w0746 fA4EgzfNnslqETCN/b66aHJvCAXR6NbLzc2efvONASTm8PsbfJnNvsCepvD+cBTtY3kjqDGBwj+N kR0NzRFfIOrLkuVibZ69zYm6BMue0lxzfK8sfG97bWMIOIMlzQggN+WuulAjpIC41FWdRI9xP6e5 sx4lgchW8Tvk+JG0GxlO0CZK/OI3qsGxGlAojhJHSi2gC/Ren8yujToRxO9mB/Gi0iR+765rQQ11 aCUQh2D8DUlfKMNX3ZzEzBFegk7xVSQzs7opWt/CRBvxhB/lJFr8qL+OMtpGKaOrlnoh9bImVCfM 8G2vbQGhYySNjq+6JSr8BUphViTD1+j37WyKgXoBDYwEH/Czu7YRyYmwGx1zIJIza5pbsDJIOIYh YZw1TaG90C8wR1IkeiEw94Ri+6JsH/53NK619HY1hDhgoHzAD7rfUdsUguDiqVzSOvczZNavLfpo 8979aBDwDPsCDY5/Z2MIA5Yij5I8CWjGQgGZEcdfXde8r4nlivG8PbtKrVeVG6sQeYzdw6Hvf/x3 /xb9Xj5ilJd+wR2xjqDfPUK/ER/oNwv0CxzYVl0HQQfEe+2DjzbV1KI6Gp5EVvAZt0zHNhsQAKhY GyeegFfk5OdMm3ljEBWIUdPLyQj5M0FN+0JhrDV+wJXZS2NkVx17ARYB96CYgq9F/Rn7o/G6BCr/ kuheXvjettrGFmYZB7FkoDDxztpwQ1RZOVJuyUaa1GEBL99eFwb5ADnDyFUF8RgsxEiqI77aaBII pmz3H+9/tGHPHpAtsv9Cpu1rCu1uaFKTAqwmkJ174+w5vuwcom7CT3pvSuArqq7UxWLQRKmaoaQL JtuSrGlsqUuAxiEuMC/mC3YysjCAhkRyV2OL1uriPha6Jif07a4PAUQgVTqokHMZZFUXgpitJ+MF q8mIB3LUpuT+mpSACfv9uxuaw8hJJYBCay+9vWjL3gbA38nIwYxQKHFfmBwvStPQ/9I7i7ftbyDl +jEw8u1d9ZwgMzS6hw3RXYZvx/7Gdu07ZzOdpq8+wZXdvr+ehdmywPYzMFRyM3rmpNZjkixl8/76 OuFjrKTYGALTxg/FnkhBTB+v+zKzL79i6JQbrrjn5zOLyspunHu7VtdzAsHLh145ZeyIe342u7hd +Yx5d+D+pxt3Y9GmTRkz7NrLfnnvHSYjitgDn52eD7fHZoiC+r/dNZFqlkt2h2b99Ff7Gpu/e96Q Cd8/J8eJZPpZjI911jMCF42cftPsW/tVZYTjvh8NH/Pg735T7PPNnXVrsKCwIRQuKGw3ZepwrMTw 66f373vM5vVrR10xdOHij17+aHlBfl7/iqKZU264+LJrH/vzA2B6L7z67rMvPV9alJ8X882bd2OD z3fllWOefvg3oKUfT5jd57jjqzdvbNi7+0c/xEBOx8rfPPsOXzC/trm5ol3J9EkjMfDhw8cPHDhw /eZN1fV7rxsx4szj+vzmwSeefW9JWWVFz6LMOdPHQe7OmHVrebv2dXuqp1w3vHuHcpR7wHmTsD/j by+9++yLL5SUFCN53Lxbpvxz0apH//pYeWl+TfXO0deMHHjSsViY4aMnDxgwYPO2Ldt2bJ046tqz +/ZDxqmHXnj7mddeL8gNHnVUh63bt/z69psQH/b6G0ueffbZyo4dt+3fO3XCDX3LCwCE742e0v+r p1Zv3Vi3Z+cNI4YNOKlffdI359afFeYXhvfvnzRiWKcuFU++/uHTr7zcoX3p/updMydM6VxWgIKB UIiQEhs16n8wakr/AQN31ezYumnjdSOufeXll+ubWlC64u6Z0/Ky/c8tXPrksy9WVJU311fPmjCy oqQdpNFNc35RUVBYt2f31PE3FLYrmnbrL0pKi0N7t183cnhZRYe5t94aCObWNjaVlne4eeJwlNsA GO+8/1Hgd2Oopb5mz4WnnzL8ikuff2fZk08/075TZW3NnukTJ5YU5c2945d5wWDL/j1jRw/v2qGj VGeMg0Pd9fsF/3z3/bKS3PblJXOmjXvzvWVPzJ+fV1S8f1/TiCt+MuS4bgUBZtADPdeFInfe/Ut/ IIieisvb3ThxZAELLMGKIEJ7q72LUx43D+tv+OxE8P/pk18o/V57/fQTjj12w5pVI4YPW/Thxy8s WlxSVNC3svDmyePBIn744+Gv/OVBLM9jry2a//eXS4tLYKfcdNO4EVeMfuYP90G5vGzS7D4nnrhn /brGfXtc+p01+w4nmN/Q1FzWruTmySNRNxJTuHj4xJNO+9qmTaub6+vHXD38/Y+XvLjo/fblFT0L 8+ZMv4H0e/NdKEtdV717yqhrju5cxUSscJb4Ml5994O/Pvl0SUXVzup9o6++4tzje6Jm2FlXjjvt 3POrN6+p2719xGVDB51+/C/+8OzC994pL8zsVFk+c9KE2bPuzAwGmnE2oKh49qTRhSJRvvHj4X/5 y4P4MGLMdBSy37plS/X27RNHDz/t+KNRExo2mVbvvOe+P++tqW6KtOyqqz918JmX/9eF11w59qmH 7skL+J5duAL0Ut4uf/eu7VcPvfzUAccDSpcMHfvtswdt2rxx+559I4Ze9p3TjocOf+MdP/cXFuyu a+hY0e62sdcCAt+4csxjj/ymnFXvKUsbYslZP/1FZlZ2uKHu+lGjunYsv/fhP7+6eG1hYf6x5TkT x99w020/ywwWNDY2VpQWzpw46re/f/SVD5aXFZX2KMqafdO4vy9a+vhTT3ft0L6+Zu/0seO6VDE1 vKaAvOeRJxe8/0lBUeFZx3QffvUPLx87q0efXnvWr7x2+DXV9aG//PWJqrLy2prqa4cOPfWrvYX7 TTvxxON37K/ZuGPX1Vdf/d4rL9fu3ZcVDN4+e1qpVM+BdAv7KEqHj51y05RJPY6qREfNcd+VY2dM mDqjb5eC68bOnDVpXM/OZegfWv411+P+tOxsZ+bMm2bPno0idoA/FV5a5AcLyjgM5UqqyoNcehCc Z8F5IfCV57/x0+Q4I3/zRJ9r53S+Zs4JI29atrsm7qCyD3KN8tuw43x73Nx/bo/siDn3/Pf8YbPu qnacGsfZ2OTsdpxdjvPd8Xe8udNZ7TinXDn+16+8vcdx6h0Hz/zojvvnr92333H2Jp0zrhizyXEW 1znfuP7G5REHzyzdWlvnOFsdZ/DQUU1Jp8FxTrxi4u8+3bnNcd7esvfcEWPx1V7HWVuXQBe4+e1J t/5zR2gLn7/+ucWr0MKjH6265rZf4sVax/nxrfc/u6kJo8Kfr6zaMPKuX+102MvehBORyWIuy6tb vjVm5uow7y/eWbu0Lnb2iJuWtnAKi3bs++aoSWujzgbHGTJs/JPvL9/uOH/9ZO2weT/D9DdXN50/ euZ7zRzGXQteu3jKbHxYFXIuvn4WBomOHnhn6bSH/gow1sadU68e96dl2/HAgg9WjJ5zN/p6btnG kXffjzt4stFxtjTELxh7y1LHAUAeevP9mx94BC9G4e/HEJNOXcIZPGziHz7ZtMZxfvrKW1+/fvqS Jme941x16z3PLl66ui564djZyx2O88E3l9z82wf3of0Vm0b/4g8YCWBeHXPeXLZlzE//hO4ADV2p dY2c8g7HuXDSvDe2NwBEi9ZsGzr3N2sdZ5njnH39zTvjzvq6GFrGn2j5oYWfTL3/jy+s3DTsrgfQ DrrAggKMUXhynUSz4wA4l8+9/6X1uzGjj/Y7F4yasbQ2gc//3BU779ppe6OJSDIKa7nFcbDE65pi GAOAfNGkWe/srK2HK0DRT1xO+mMQ0qGJnb7+t+h3wBXjf/fae8AZ0CwQ5r9uu+/p9XA3cxGBq4Ov vA6Ys3bXvm+MmrIi7oAS36mOAlsGXXYtFnpf0jnpykmHod+LJt767tb9oKb6uPO1Kyc88vEWoNbj 7y+/avbPgU4/vO2+5zfVAtPQxcurto64637cxEgahEvhQher6hsuGHXDstooMO2l3U1njZpYHXHA qgZeM/X+T7YA/1/fUnP+tZMwpI2Oc9lt9/199Va0sDXirG3idDCF8yfPe31HA2gQODzkihuA/6sc Z8A1k/7ywVq8Pv/TLSPn/ILsQsrIYahvb6q5Yu6vgLqbQSZjZuLhlZjvVePBcNbVhC8YdRMYGnjg B7tqv3Xd1NVJ8sABV0167P0VmNqrO0Nnj5wMegR1r24mCePbb0y9bfHW6uqkc9qVYzFODEPJ5LWP l4356X14C0QKpgdyAyguu+2hp9bX6nKsCHEMeAUkvHh3HYb049sfWrB6Px5bWxc7Z/R0DAyvP/KP j+b99lH0iMGHhIEDnlfc/YfHV1fjyd1J5ytXjf/FGx/jyeXNybNHzfi0hbS8cHvjN0ZMwk3A7Yyh 4xcsXoMPc15854yJs5bsjwF0V9z2m78twSTkSnLMoOjvj5u0cufOkEwBvQyd88tH3t8ArPj+DTNX bd+LSQGSwJyhc+790/tr0cgDL7x87vDRsx7609p9jfg2jOPxn5PUD6fzmp0S6/5RnySsS7hf4fLM QdBMMpkbRE12muS6UQMfK1wKc3/286lzbg/HQnMmj0f1SDwIXemldz9+9IXX45mJ/Q37oCPg6PJP vj6oRIqFwyzIikYLmD1biq6KPb5i3fruPXtUZbP+ZJ/OJVLdkNXF4DqHSgYr6uzjO+Dd47qUBYJ5 m/aExRGR8c+3lsx/7h9xJ94QQq12eP/jQ756TL7P17tL9317qtE4S3X7kRskpLXej+nUpW7nnl// 4al1eyJw78HEhstOel/Tq0+X9jk+vHtsh5Itq1Ydd0zvyiCH2q9jaTCvaMsu+qwTkdDXB/Qr8vm6 tu+6rzYCLWz5lk3dOld1yeO8LjhjgEb1fLJ8o5OV/chjLzz81+dXL/9099aNVGegWCbip/Y/SibY qWZfHZ487pjuNTu2/Or387fUxWHaf7xhdTw7+49//cefHn9p/bKVu7dv4+YGfHco6MHca75ENHTm Cd0wgN4VVUd37tY+3wcdp2uHiurauhWbNmXkZD3++Ct//MuLG1at2bOrBtPv37Pbnq3rf/Xw39bX tOQEfEf37Lxj+9ZfP/jUlhrUdhdXqt/36psfPfH8GwhFrW/mzeycQEM4xO1PboSFg5m+FWuW+rMz Hv/bGw/+6e/rlq+p3bnnmB7d9u3bd89DT67fwVlQB+QGAR2mWH1U+s1qIcA3btnYo2eXHiUZGHCf 9oHCguCmbdsRHM4IWLOB73/trY8fe+YfiELbU1vD2l5mF+L/U6vqi5zWF0q/IPvvnDMQ1AHsxe+C WKQoIyMqO09Y/VgS7mvfhi1b+/XqVZnpA5n3qWDBLikvyW0f0O9Zx3cANR1v6VesckO/MV+8vgXo L7vs8ciQE7vgyT5djgo1NolHLtOJROAFARH16tp+757tv37kqfV74OfmfgT3drG5tX5Hr979upZk YWx9q/Lzi4Obd25hRfhY6LwTusAT8JUu5XCr19THQBSBeLjEF8CT7bJZgP7lhYuf/Ptr2AloCjXT mYY4RKE18r9I6PxTesEF1b595Z76Os5Fc2QBgbNz6sNhsI4WeCEjYa2xG5ERrVu/qnfPo7oWkyf0 aV+CwjwbdzYz5jAe//qAvhhM/w65QV9yb3UN/ZaO758L1z7x4ofI01LfAI7CrWpMHxt39NxjOsf2 2bF1x28enr+zulnpizwt0ZLjT7CENJ5JYLdl5eMvfgQpUlezDzcz49EcpnLyrd+0pqCg4NHHX/v9 Yy+uWLEM9KgIiPLEiA8ge4xHspMxNJjj9+VkhC8aciImsv7TZf26dOoo3K/vUQXZudlrt9dyvfzR c7/aG6bkMUd16N2xY492iGzxde3WeXf1XvpThCPzcAW8jglULaBnUqMNmmORjCAg7Qsn4y1JAhkT YYXxcCxHCkZfduF59952G3yZ182as3wfHMDuq5+VYD6bM0etQA6W+WaG/fB7J/U4qlu7/DFD/6uq uIjlXuJgRByylFFzpt807a4500dedVl5Pvztvpp9sRm33IIaen2P65+Tn4fChRxdIg4wZSexC4pw WLJ4BJWghBN4HKNDZPNFiUQ9KtxmYc0aVGni2mcHWDpWL5z6DOYHd9b6bp47B39+5aST8/PzNZQS 1TQQlIAxoyCepL2XnddEJGALOJUVBH7xs7nde/S4/a47P129NZVHBlEMMYhjXmYAjHFgU9x6jcdz c3PRWjArmMnq6b5gdnY4Cr80SVeKkbKj5sYGJg/CFfCVlJeedc7ZZwwZfMnF35kyeTIfYBHADKXP HFSRkPMQRQHfz396W69j+sycPWfJ6g3ReLKsouq88845c/BZ37vkksnjJxBNhZIYwZxM5rDmIMu0 54ErAIbqnmOdI+50F5UUnnvuuV8/59yLvvmtSWMn4qvSHN8vfz7vmH7HzLlt3uKlKwpy/XfffeOx /frePGfux2s276yLTb9pVnYw5/jjj2eaBmktL7cAsSrT5973szt/O2rkCAIh0w/n0pmDh3z3ogu/ +Y0LJ94wriTH97M7pvc95tjb7rxzxdotRBaps80QVjSCVOVZFHLYiJfKqvwhviTj6AVAw+TRbE1d CL1jYiec9JWcgrysnCDvcj5tsFQbUKRIX58BAl8A/QIlgHX4AZYwNByHjZIOfG66KkgjR7YVjSCK yka98yvU9CB6wk+VlSmRfiSuaDiWlxfcUeubOW8OmN/JJ5+cV5Bv6B1CJUAMB43kQijGGZ3A6r5Z JhtIaW7WL++e2wP0e+dPF3+6ipxVYgcijOg0F1WsWDwrmMstfDlESZ1cB8nKmYwpB7fByLbvSUye PhMVmo477rjcXIghkROkYLITfIZOj5KAnHgwKxxnmIYwKRbQwZgxuwm33Dnn1rvGjhlNUcSTuBpb zPpnChn8ZGUF8oNBbkayypVEx7ANEsyuvY0333wreMtx/fsX5OdiJHr0DS+z3E2cWe5zc7J+fe+8 Pn36zLvtjg8+Wa1x+fFEOOkwKmfXnr23zJoVDAb79OtbUFgMBiibRKQ7XCgwlF9UeM4555x99tk/ /OEPp0yZIqNCSANHQU6S4eSiQjlJFRVjsE3J9c31+3GsHgNmUxh/MFPLimLrCd5RIgBKzjKehZIv Hm3BkvF7WULmfcaL2cFEJuHPDf7mSF3N7l7dOpGws7Owe6d7/7vrffv3Vh/dvbMgka99efGYay7r 0Lnbx8tX488Ewm4+z9bD4QSbZG5MneRV/o5euxf57psy7PHbJ/zwa8fRIMM0ycO4RMDbvCwn26HC AlwUN6tvxYbVlR07nHFK/95dKlpaWiC20AiQAPMRRYj/Bwtya5pqoZ9gK1hZas+u3datWbsnwuCi D9ds0LBD4CJVAZhW0cQ/F2+Gh33huo1FeTkVBb4Va1eUdmx/1uCTSyvbYf1wrI+ipaUlSwqu0taW I5m4CZ2lsblJozn2NtFYOH/ICQNO+cqqVZ9SbKB0Agygzp3WrduAcAm4zj9ct7NDz57L16/ZE/c1 wPzaXAPO3qGChl0LVFPJWBZLtmRmxDDu7h06rl6/YWeMO7RvffixRlX27tV9x84thcW5PTsUdass zMvjlhLDboShY0halhef9zbFcjN9557ef9DpX9u4dmPfXsfu2LK1qADN5nTrUFSclweCzmT5qQCK TsAiwotshjlS/cA3gJItZ2bD8390z247d+7ML8roVpV1dKeCdoVE8Trqtb4zT+1/2qDT1m/esr85 WhjwnXl6n1PPGgIL79PVGyo7dz1jYP8OHUohhBCsQn1zzabOlR2vHXrVmGtHnnBcT7ze5+g+u7bv aFfsryzxHd2loLg4q7mFmvt5g/qffuZZS1bC0aI8hToM7gcDOdVhmrM9u/dYt3rD5maCccnm/Zhy 5w6VPLJCW923bM260vadzjrjhI5HlTQ3IAyNh1o1csFm/bEBUS7TSn84NAS+UPrV8r/KrMmj8/L2 1TeorKJzJRkGK+jTp9eKjWtrHV+dz7d4M6IzwNMZ6YCTbC2RxJuLNwMlFq3bBPotKzT0e/YZJ5dW kH7hVAEfBCniqKoggAYgggX7igpym5oaNPpgXwvqRPsuGHzCwK+egp1u8m4JHezXu/valctrQnxm 2Zb6TF9up4pKBkdlZr364VrwjQ/X7QD77VqaA/zMzg3uaK4HwX68aW37nl0HDTyxc8eqOCoXylmq WAxbxZR/jPuIRIWl0xWEwsKkXLCzTAd8ecXq5ZVVpcOGXXXd9aOO69+NEgiUGCHr79215/KlG6rD DFRZunm3PxbuWkZSheh4dfFy0MLHm/Zl5hYcVVW2du26ssqyQV/p3L1zMNRUH4+18GSABN9RFwSZ JJNNoTBI/uxB2J0fuGXHTtUA8kuKQlFah+s3bW7f4ahBX+3RuUtufagB1SvRUWFBXl39fgz7mGP6 7t1TXVjk71qV06Ey2K44G1NAGWQEHuq5W3je4uEWtA9VOyuZDdlOntalw6er1+6O+wC3JZt2xCLh HlXFfDEzh6eaRIuFkKYYI2TCGZmse61iSNGkJeIPZxbj9W0h3733PTzw2GN6FxFPoPpEMwrAYze2 +O568P7jjz+6c0ngk417tjcR2vCJRfY3dSosx8Jl0wT4HJdKx4NcMuFWl4h8ZjPFgilCq3GgOcZU msM/6Q81BGPNOTBm6HNg3s+vHHfs3xbMv/vOe2Fatc8LFjg0//PAnvkGE4sgyG/wqV/980P3v1tV MXfmZH+oqQS2RXnmN88eMn3iuHZFBRWFhTdOnwYoZ0W5qMD4YMC/cumnryz4Y7y5YeTV18A5cMrx x7z0zJNz592DMZbn5Rb6cZ7RVyRBq7hyMpK5Np/joJNP/uNvf/1Bx8p5N05etXLZX/42P7e0ItzU dNXk62EN4vQjlqVXp4qLzv/62OvGl5eXl+Tnz7px3E8u+faUGya1r6wKh5rHjRpWJHQFew1wAEyC GfH8DMqYHu1LLjrv3BkTZpQX5A4ZdFpmrAWuhmCBf+j3L5kzZUZFZRlcpBeePfiSc8+A2wJWPxwg 1AAynCxfFGJ105o1f370sfyqo0JNDVeMH1taHBj2/e/MmzynS1VpuG7fN88cfMmFZzFXnFQohj8n W53DdGuEMxMtqkxQqYzHuxXmXHHpJTMn3tS5sjLR2Hjhmad96xtnr1i29K9PPVNQUVpfv+8nkyeu XrH80cefLiovrws1TZ42NTeQ+dJT8+fO/RnK1JXnZuVl0kDv0bPntgVPvfnGa6GW5s1rV153+Q9O Pan/Vd+/ZO7kWyqqqiJNtReeNQi7/X96fH5JZWVt/f4bJ00wBRxhiyNEzfGfc/rpD/7u/lc6dbp9 +oTLLr1kxrQZRaXtouHwpDEjgxl+mK1gWQD7yccf9/Qzz8+97dfxRKJDYV6xFKjT5Wt9qTaYvg4H gS+cfgXbcTH+3e87/dSv/Onh377zfNmcm6eTLSYjBZm+gspS0MKE6yaWtSsuKiqaNnlcTiyiPg8w ipXLlr664E+xprpRw4aD3gccR/qdc+s9ED6leblBMTFo7kRbQPg0Df1OHg8p+844+bhH7v/NO0d1 nH3jpFUrVz725JNFJZWRxuahE8aqiYD2u5YVXfmDS6dMmFhcWoEA5gkjr8V4wCtLgzmrP/7ktQV/ a6mvu+6aa0B9eHjIwFMe/N0Dr3TrPmnc9c8//fitt92Nss5V2GWJc7SBAOyTBN0q0InB3yRgP5gA 5VItl+rbdLL16tXzv+fPX/j6my2NTVs3bBt62eUnndw935eAT69zh6KhP7p0+oRbSssKo+F6RJm1 ExulqjB/2ccfPz1/QVMoOvLqKzDfk07o//hzz9966y+dzECXkvygLwG5mBkLAwI8WodDC/6MNSuW /ff8Z/JLSpuaQj+ZOo0mnd836OQTH/71PW9XlU6fNOXxp1647bbfwE3ZrbwkMxnBcgw+5eQ//+7+ RR0rZ8+c8sOLLpw7dWbnqqpQXe0FZw6+6IIhYlOSkYNXZjvxXIRsiwM2iDBxqR7TvWP5jy/97pTx M6rKiuOR5gnXjwHcIKRzEvSf4eH8TASXh1mh1ecrCWRmJ3DUWy4MGIYKfLw5gTvnzoJUzssPDjl9 wNCLz9d8zyXBrLtmz8MWelZ+weCvDfjJxd/Aw/Hm5hunzQjk5jQ3N511xuDBJ/eQ0FL5ORg7OCgZ HDoq0nUCtjbqUo3r2E1PUClo2/FUhQxADWQdCvCJZ0diCfgPoSHgnnjCE7l4hIlXM/EnhAQOZQd8 cfgM6bA251co8KETQDlCaySJBEkCkvzCK0f/+Y/3+VuSpfQIGhsVn5olGZ1arToGLpIMAHeCVH0Q wpSBAwHQfoLZpM1QhKkJEEMIO5qXxN+ogYgwDYiQghxWvsYVZgFdoJzkKreiXTf/1C+aI+IeKBvB mQD4S7M4BgUIQZXwNYciWbk52NzKloyziN1SDRdjA6LgMbQcjjgARUGeX1UUjfRtgiUXDIiXQA/t MBBfPRtoAWQvd/ijyyVKg1H04KkvKcyD8OMdByBCdHISfg48g3dxEhNZw7Pz+Cd+MJiGhuaionwN aMad3/zpyfJuXc4ZPBDNLlz08bZln0wYcRXGCUqoa0rk5sE8ZDth1AiHezkYFLDHibh6fEJ2WBny K6dL8SL+RMvojzKYcJRx+XFsAMczsY2XzMk2Z2iA0KKYqBgTPUo+EZhWs7I30v+2hsAXTL+gyhwh flotepolAeuElaOxI4ElxRYKqBh0BFrAWmUx/QY9OoZ+rxr96CP3ZYSSpXmGfpXEQL8BoV9VoHET LeACLZCQEQxMHzs8JfEAQsWziQ8t2NlL+iEJlY5Uzqg5GYshF3k8N49+UXU/KpXhWBxIWnYMLJlI XSnwHjzWEollw10oqUHA1OBzCcNLYp2usldlcjxiU0BOdwVwouCOP/+tQ7eeFw86CeN88Y1VG9eu njTiu/RYMF8WDx0xaD5ORx/pWsLMYVwCJiFMWTJRKs1yRuE4iF3pGpCE3UgJKt0KGBBwngyHI7Bc rUEhhwcAWweOvQAPKmCCOGqkO9wycXA58NCcgEnh1NIczZOsu+KblVnQH+nHqQNc4uTytSBNMYhU 5osnsE8WTiSCcAbpIOS3Kjfca4RVI0uIkUgLJlGIroWrh6r4UB6ljFE/K12jNVVaEVGPQ8ABrKnU W8bKsvh3a0kkbxzy+nyCzSPLUgcA5KYINulZZiejME9zUhQtrEcekNQywCCeNRQ/p8lExfnwKDIS laj/U9kiZ6+5zZhhRJKOOPE4jrZcfM2IR//792USDIoj3ybzjoN6DigeD4tFUIED4JEqOSMp2aBZ OoHj1HOFbk56PqUC0IUyfavUyJiuFP8Z9oowH+ZFcwt64HHZ8TLn/IXo0EyANQ3QpIoepso2pd3h 688g58dDOI8MYNA7ornb6GTXaqpy/kt2C7BNpgPPgG+GDnebvUdTQuslGKZpvewND1MjGTMnmcb9 4Gk2QZcO68ST5LBZEk/gpA3xldijgPHDn4/82zlgK6+8++ETLzxzwimnoKEP31540w1j+3fvRI8w KdrsEMsJcrSayAzozhxrqUsWb6FH8Q6xMxO4TzOd1brxjBm2nubm2T5s2cINYtaCaqQry1oJNrT6 mbU3C6n/qH8PJtiOLP1ahUoQRtCMx7flZD9zZtnFZS0tw8BIv8gigfORlwwb8RehX8FCPI0nWJkE yav80PitS1POf7NtQXwhFDHIVFCZjk1/yh5EsMkHvdg75CzdQsRZvWh1kWyMwqRnzHHJkSkc8WZR EX5J9GSSSD2ALQxEWZO2glui0CZxOsj37HsfI6B/yCkDUHVr0YdLp0wY2++o/IATxyY4KU4zgGAX xs8QFvanpAE3I2qFY1uC/kbyMbguoCGyPI30onkhtSoqlHxJxEsaBplIAfOUqkffkZ/8E5PDhhSy 6ipXkdpA2AAVAcnUkPyNTrnFyDRnOhnwO8nH757j5ZilAyui0BiykWSYrBkKf3fPQTi/S5CGW7qC CFBS6YYuVB0S9UJBqrq5roWCVy5iQkAZaDzHVB01X32Wfw6bK9Ijmdroy7qsOj6vQi33PEJO2JbO QTmY1H7F4ghCCEtPYSEx0ySfEQbvpmpOyWoyfcHsD1euOLFvv1w5CSwwxmFrLo9UVFLdXhNnsxf5 xxW6tFokj43mzSF7xatM+C0LIbgLUUAykV2K1mLaAjW1MCJUYHAITLgQBmzcSVQYiUmvLbO2nOSq IXqJNBfZ5R6W1+yjTAbHN5hCVkFnSyVpPIbBIJvkR1U6o0Co5OYThHgqyYsdFkelyTZZAkNKcmie WRFs8pemKaOggQLC89c1DaEdO3dCsvbp3rUAmizEHeUutjEpe4UmmAFQ+gQxMP8DP3OCdqxmMXR9 MTx7KkXYBJuw7IINK3BV1VAGlr7+DQh80fSrZCUKi2EHRhiIoFLsdFUXtY202IXP99HKFSf37Ycj 3OY4IvDI0q+iot3hQAdqpKmmSuGEP+gVUNXKJPsBuaaKYkvsmW6QkHo1Gw+USGUCIrwEL3k8V7ir 8CNhJJrgxlCubUeTA2gaHwg8V2U3eItmcA+Wyp76+t07d2QHsnr06IUNbQR+K1mqhNLxiBoqt6xA kS9loGLjmsvy99Syu2LDLKt+g+hopgo2IlpvmV5oRwkTUBISGme/ks9ZmR2bslmGUs0aBcDm95cv lI6VJN0nuZTszVTcdEWCK6gMH6PElbP7uGCDGQ01JdjIgUSZYUIVK1oM5jADVIZffVKf4/qXSZAF fXipCU5AqOavf+iKeMUGNAN5gcihEHV9cXpHjBADOyEMy8UoS0RtE6iLAma5Gs+xg4vKpiRO+CPK juoKz9ybHGKM0mcpACEclX0W/ACWR69xYSMt2aTJhKam4DGMWE0i3FYFR3YSLam4FXM8st3V/mQy ZgkNEtCcoSCHw5mpxRFAxpRYCLjB9Ih8Ui/WwBOZwMTMwblkzdzKKFG5owLDXXaZB4HHBbIZZVTv TLVmBa2CAvBhmSUsuYZIqWYrMDeCTdaYcKdFRc8R9VxMmw4c8bZjUTkVPCafUK4+E4EfJlemSFa0 reawZjMSFLEKu1lqTFWGIYGvAnRFKXSMLoT2XJSQFjzM0V2+9IfPBoEvjH6VJ1I/0bg3y/JUoqnl BHQQMpYvxecib0Q+E/2S8oRIoVkZWUZfiJFAItjQrzgZDAu2NC9Yx7x0Ymlh+5bPyCkAKSEixGyi FGVvARRurUBFbvrRqdoJhYihRsEn2YIChonLE0Z3VmlNOw/nlEit4DhGgAllMSeZCC3DQlU1VU5O a9XKJQWSavrKnlTUeaWW8E927jIMQEl3+cwiKGUJWRMOUDj1OznkzLkIg4IZm0TWfCPzXA6phCio ZWUsBy0bqcqNFaF0epIzzwg2Fx11ksKaDF8S7moFm/AxuQwvQ2tUa+Qv1xhIpV/QTR4YlyZxttvP 4T8cUrBZiWUyENu8DxInZNaHlkHKhNR+hO0BsPCl0QKQRUDBPoZCqdJl5bG2b72OZpaIJyGu2iG7 0g9PEpKQ+lgJkVpIoJMlWZgseGJcKnVFEJ1VFZT1pznhYY72Fc3Mm9I1VO+yapFR0hSoOmVZTrkv pKIeUu/Fg2mChqoGQgkRjixT5ilOYIagINVPWG/yslbDwLIJSou3AY+betwWhVjDV0dqcV4wR+Yn 6dksrqRUEBWtonmKl5I0wxZSah/HIzgrfMGIKlkVK5hk1rLdgYmIqoE/xTWKJWCNXaF99Tca3UbN cYWSVU4VRMbjZAJTjZmuiGTVDjkLqV5La5WqjmsG7eqYnmm0WoD0HykIfNH0q2uqy6cr6NFV2ywE zXTW5ID5L/sMh6Jf0Rgt/bINqQXqZwpJ5XouVYq/QAWbHYPguLmIMEbgqYBQdU12zZSMPW/pO6l3 LR+QPlNcQugCL+thJct2PMTCJK9ge1kitTQ3vXBIZTh6WYeLy0VpjjAxpXueSgwqykCSAE8owWMv FKGeQmlDagUoUbj8yvsX5aFmPxZeor3rQFQFkHg9qeitjsgUH9O/LQdwlxQCDF4aeCGzyEgIGR7C lUVneGcrceix1F0JmXrAyzON+9EM3eVOikti1qWEmTDcz+G9ac2aLfw9/8raiOLjsQz0jrI6gYuB r/JQijAVY/oWhiNGhJytUu1JwScRvEoY2oKFkXnTxQczHluOFuxT0ceGHJM1S6d2nc2qW9nTpiG7 mCQYd+3U0yCXVYAOAg6vrD3wa4PDHpnnCnJpVi+pOaqPaniF4AoxmYBSBdj0YxQjwQYdYArX7F82 2NNdqdbj0i6wSaGp21KzpGWLe+pu9aA2X0cCaQ4C/2MCIAAmERCBjeeUvDIzY2o+q0PXTk81VR2k 9mU65NpwVVL0qF+41hjxWr7kfVVxve+3RtS2mHGQlUrfUmT7gujXXVarl5DSXZjTKEqtkexnYRy6 J8QjuzgDZ+nXyEWhXy2T7HI4gyDAAzxEv4siqmmYGKGJzVPIZj4RJ0n7+rxsLdEPaaidosOMFE0Z 347SnJKk/VaRsS2u6bfW56RSh4m8YXshhsC4kDIkF7mqYmJkSkP8RdtFUdyjn8koW/XFSROkjAMg pbp5EnFT3bZtiNkzanVayU6nkph+Z/gyHSScI+LV0SMCbxQWBvIpshF7VfvhjyFeAxuryih47WNS HNTzQiuiVa7oQtOdEIen3Fu4HIFlkJY2ItM4qz/JsyqpQR7y0790Rbpvyvx11VOY54aQ2G9tvBBt KY5E7lPZYMCILC+wm0qENKNbl8YikoGrK0DhzPtmNmyNbJTHR+gQoHYE7xxcdookPNxs/ZbiaVDr XLQJ055OxBtkoV15pLLtWx1lQFH13dGNbwdiNDiDDdZtrcsvxhw+yAahdWpyp4rKIpBRkICUrRBQ cPJRlVuKfPSNYF+YzZhwDwEVMBsOTBK3qmPenbwUrhhVQ26wCTbp/VYgYDb2BRjKKuQR1TH5Io4Q +TMYkCh6sZhgQhuIMpHvCQ/sTiO8xSgiXtLX8BCjl7meKDXNLaiFF+jGDLbo0DRWWmJnSC7oitnc RT8NKqBck05XMHW1lnaeL9IfD4DAkaZf+swohQyPNcgmug52tT3u+hS3oLTTUoXMwQ+2RfoVhg+C lfA3xXVBY7YgGnorRzSx33ojJHKZrraA7tFaT5k1ktyOBXttaAZT2vozAozeoChVmuVpE3dT0OKY Kp/szWMrKAOhDBRUVcVU+JgwExbFlCwTSlZCQchEgseyMJ8YfbGJHO4zWd+GOE5wU3iCSHZ3/8/o jDQK1IIREsFWBZkD40Fkc8T1Y6a0U6FHpZNUQIeBAfpj0KkOnYJTwlv4sa0txQN6omkYEImlKC/J LoPhda3sM+xQgnPSqhOTTiAnC6xvuZdqGHLDrKa32h+/UqVAFgCfUBXBBBWm2vgXnw7LGrwMyzMo zMp+c/DXjXBXsaFSmp8lYkPmo8JGc4sIj9YQCQ0dSoHC9Kn3KLc17IRehSxQhdo2AgZtCgvGqF3h ra2sN3fAKk7YndX1hD5JokIlBhs4NLYIelF0k17wpQ1IEYSWJdf5tFk2kVKqAdj11B123lY3unxj 7DRXM1JA8Qk9xWMeUziQeA0oDJBSUl9vpN6xIzLP8x93mpYIU8O2g1VdErtrdI6IjYZehaDkI1kS fUlcPfAkXKk6GmYAqrYroOhVklXwiiJ9zgWe+xVTP8jS6ER0f8XoJAdFQ9tQ+t9DQ+Dz0q993oNX XvpN6YBmH9TDNe0rxB/ZDpd1N5QoI5StW1aOZtUqhh1qMg6utiC8oKhKNSUrbskdODe7IesSg3kP /2iqSGlR27W/jVFnGtOSESZmTJFRxqe82LgZTEMipVMs2UXvlLpIxRQ+Q+iv8iDrq3i300xPqXmk YKtMRRrHb0Y8CjxVUqlYUI7h2r7ikrK8xrpAPCCy01cuKOLHvdRcFGWdl6yTLIRdhQPp1JIkZYs9 7O9dELWrbGsGkK3p3XB+84zLvRSO+noKST3oaqYsyCAw+RxOSB3SZ7fYvFM66Gc1t/V4FTWUeDyJ I184B8ZzX7Jm/MIN68TfOE9FuQGhbYxnUQ+QN4Z7cqhwC3TJlu1NBKSDEHBQ3zglqLFYYxGNYstW QuepiSBgmFV6zZk0NdzAlvXIsKFEiRW0FnQrh7uF5OEm632mzfO6NCl0Mn9z3m1bPlRPvK8AtCjT qkV706V5V8/yIPG/XKpU46m32jIRsyHfeko6ai/DPKBbbSel8Wicp/eOt/e2ELNDV170udH5s848 /dzBICCre5AVSaHxwdaxVUue1T8cLbVFkjajOTwZ2hFajBVPwMFfcfG1rdHvxU8jSQ+CogcBUhsy cdvx0GxbwpVX7CDFmXOgPaBRYW3up6Dkmd2/AJ13yAfAhO8aB2mKTdmRt306NaPUNx7kaIMnqUX5 DBzJ+27q84Hodyju8BnI9wgKNvSmkpiKlznj4sqSlD1KV5vgkGzk0kUgFoAcVVH9ReqH8rwL6suJ WFMnFZ0Q3K90JHsLovOpUQjPRDpI+jcC9Mf6UH8V74s5LGSoLJJOM76rKyt7eyYm3iLTvyEYPgN8 04+kIZCGQBoCaQh8yRA4soKNggM1bHBe3MhamGQSPsHCrcac1KPZmlFFZKBIFPFE0OWrFj3/FXU9 EU0gpQ0/0QTXWEQjqYzdwDdSOlGSWV4yHWRT5PMac2h7YhNGuVNtRJxfxmv8JcM93V0aAmkIpCGQ hsAXBIEjuf1OqQaJkcV4djoIdSeGkoX+a/UNa3SN8VXrNqn3ElFDKaZSDQVizQl8OujN4W28jEq4 LITEfVTZaEO8AxtmrgykHkxKYhEKLm0dW0QsM2+7Re8p77DbuRWAXxCc082mIZCGQBoCaQh8SRA4 khYbg52Qz1pEE6oYIGmp2EM88SA7woxgTHIDmTk45CiF+vQ1ZoFPSvQkWhBhhXRzDFwQCYcoOQpJ iT1RmckoJ1qBEGgJyTbJ7GQiFtmybMFRGPLMr0b+INwI23kmiTUeNIH4Ei9i84Z8SUBPd5OGQBoC aQikIfDFQeBIWmyI9YgknAnT50JWSEkHiSWRyF0zAcYLibWEfVIVWsy9yK01Ob6CVE3YLnOmzLyF tphNH0KxJ5nbcMEiREgp4nwZj2/zz2gyAsSq4AFu8WX6kIxOz3qI4YdIPubJkGgoEY32x7tRzhe/ ODCnW05DIA2BNATSEPiyIHAkBVsAmXQz/Zu27WoxyS4YI4pKg5rbQuOWJIADRePCkkZFcznBeqMB J3IIdxMrN29pNFntcdqFIo91wcXog7hs8vmeefPNzXtqUYZXivDRlGO5Fsmci9SZSNr29zff2VpT p4chND5YxB6NQspPd0tPxB5PhKSl2peFcOl+0hBIQyANgS8UAszOe0Q7QPJ6ZH9CgQqmBMVPyJdR HUKxvGzUZ0E1VvzAUVkbc2qjiRbZdoPoQe2Gvc3xfS0USKhukUgGYpnZ9pw2T3oiCySKj+1qbK6L RHE8Cuba86+/vb0+hPJ0YUT3o/JyY+O+5mZmlMM5kkxKqWffeHvzvsawCMtQMqM5mVEbRjr9jJj3 jLA7c7Et00GRRxQT0o2lIZCGQBoCXzYEUqd17UnE//kIeDisyRf45hU3/PGP9xb6fK+/9cETC54q rqjYXbP/mquGnnNCb/TxxCtvPffSK+2KS7Kd2D23TA83x26+816UVd/bUFdVVjJv4rU4qvbtq8c/ 9odflLNcIcVYU9KZesddeQVFkb17R113/V9ffOXNRYval7TrXFUxecyoO++4PTsnZ39jY7uyqpsm jkQNp3sf+u9nPlxeXFJ2bEnB7GmjX3jr0+f+/mJZWVnT/r03Th7fsRRVnGwQpk76oGd3/ufwSLeQ hkAaAmkIpCHw5ULABBmqiPufXzgWHXOie+OxIVeO3eg4i+uTF90wfXldbJfjvLErfO6o6ZvCidX1 ofPHTF0Rd3Y4zse76lscp8lxNjQ52xwHr1w0afbi9dv3JZ3Trxi/RWr/wAWJX28vXTXijnu3Ok61 wxc3O84Vd/3u2ZXb9zjOTsdZ1xTDh+2O890pd7y1qRZtNjjOf916/5Mb69H1yrrEhWNnL0vyrd+/ uXzO/Y82o2XOFqWREC0pP+aSO+krDYE0BNIQSEPg/yYEINVQFRLXEXRFIuFLFkqJZkBw+HzrNm3t 3LVb5+JAkc/Xt31OUV7+zj0NS1ds7N2zd3mmrwQ3q4oY0QF3YtL30jur/vrSIoTqN4WakUsKydyw Z6aRjzhffUyPHnXVex94eMG23REtkpsZbilOIpEgKmLT+Hp54eL5L70TDvvCLZwPms1LxoOIhPT5 1m5YiVI+jz7+0kNP/GP5ymUbN67XXTcT+m+OA3y5GkW6tzQE0hBIQyANgS8SAkdQsGmQIwIhKV1i MQQ2akJBc1FWIbZeiyNJ2g+YSLv21s6aN9efHejTr28gNwfJtKJSUQESh0lGpK5RYX72XXfMPvro 3nPmzv109U4WiU/EsZeGRrbUNEyecWNmTna/4/pn5QWRXpvJljGMBEqcM1wk4cRKy0ou+Mb5Z509 5OKLL75pxjQdjc1IbweXDoj8IpEs3XYaAmkIpCHwJUBAkvzSXjligk3i85l/GAH9kGHH9Oi2Yf36 rQ2+BlTL3doQdSK9upT07lL2yaql2+O+Wp/vg/V7kPV63YYtJcWlZ57SC8ZdJBpPZDLwBMfOGMEv +VcRUbK3IZqf5Tt/SP+BZ56xYt0qyKCcnJyacATBIyu3bGvfrfvXTjmhomNxIhBLZEt1egjEvLyG CGIzfX36HLNr+46CHH+v8kCv9sGigmwNgNQEu0acaU6T9JWGQBoCaQikIfB/HwKQbZm33HLLkZoI jqNFE4kn5y/4wfcubpebEczK++0Dv3v9nY8Wvbdw/Mhh3UuLKoqKQk7G/ff/fuHCjzasXX3u4FPb Fbd78bV/fLBk5dtvLSrOCZzcq3dVebtnn3/+ku98C5YZi776fUuXrbjzp/ct+nD59m0bh115WUEW qyf8/ve/X/Lpmku//+0Xnnt+yYeL33/nXRzBPq53z54VJbAao77MPzz84Jply7559pCcYOGD993/ 0eJlr774j5xEsl+vblKtiNUhWE7GREOaFGBHChTpdtIQSEMgDYE0BP63IHAkM49oHS+pIs7pwAhC KH84Gs/PCWDfK0eSgYRxCtvvi0ScvGyUnpE9Np+vucVXmEurCTGNuIWIEjlTDQkVC7BibWY44osl /Ll5Yo2JmRkN++C0zJI7kXAoL5iLxrj9lqADFHZeUzialZERzA5gnw7HumNhX2GOL0dzk0gNICmM Ykqj25INR8x+/d9aznS/aQikIZCGwH8yBDTO/0gKNqbMhzMyiYJektPYLYHHjFbiW2S2K9Z3TyQd HOXG9yIFmWzfFBs1KSaRmksry2B4iQDzhgSY+opeyiSTkKAJhIZoeVWWctJgEKnRrfVxUEideUZ4 E25NZp6UmqGmeI4WXpKMkZ7ja3qCO32lIZCGQBoCaQj8b0LAjXlIOdSkmJcaTdZ0aj1Ce/fIC7YD IeFx8NnyaWKTea/UM57ZmCLuqWe9IkckkH3NYx8eUiylAGHeMvEr/5tLl+47DYE0BNIQ+I+HQFvm bCwilko3qewZDaFlYOlqQzor1wRJVQ/Xqi8qWXgXGavcRI7/8SBOAyANgTQE0hBIQ+DLhEArw0aF k2TGlxosto6mLSqubjZ3eObgFvNnpW7Ch4esjWnB9mUuYrqvNATSEEhDIA0BhQA9Z60qerc5dpXy 7dnNJjcnojk1pqHtItVsAimJez+SB7TTq5WGQBoCaQikIZCGwGeBgMmSkaq10uYlex5L/sXumhz/ EknYqg6LHtby5PtV2y0dLvFZ1iD9TBoCaQikIZCGwJGEQFKtLjlWbH4kdYZWMpMf/UIvFVVSOIY/ dD+iOgx23aR6jGmKR7jk0bRgO5JLlW4rDYE0BNIQSEPgs0AAYSBGsOnTurvm5sowhTwpsQ6SPsNU QEOMiW7IeS7ey0jvsX2WJUg/k4ZAGgJpCKQhcETfm0THAAAAfElEQVQhgFhHhC4y2CMD1aFtdmCU zNTtMtajTuL4GKpW80yYHNbyxNlbeQY5pjm0IMzs6QAW8UxHRR7RxUo3loZAGgJpCKQh8C8gQBGF sPwof5iJMdPJDHAvzXEy5WSzXuKWzMI/kGpuKIknxIS+ShVs6n2kKzKJWmfO/wPh86P9rhxU1wAA AABJRU5ErkJggg== --_004_EF64FF31F4C4384DBCE5D513A791C2B120A4451Axmbalnx11ciscoc_-- From nobody Fri Oct 10 06:18:27 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 080D71ACDFC for ; Fri, 10 Oct 2014 06:18:18 -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 Fcs3400aOQVX for ; Fri, 10 Oct 2014 06:18:08 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0723.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:723]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70F121ACDF2 for ; Fri, 10 Oct 2014 06:18:06 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB422.namprd05.prod.outlook.com (10.141.58.142) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Fri, 10 Oct 2014 13:17:43 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.226]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.226]) with mapi id 15.00.1049.012; Fri, 10 Oct 2014 13:17:43 +0000 From: Dean Bogdanovic To: "Acee Lindem (acee)" Thread-Topic: [netmod] Call for consensus to Accept ACL Model draft-bogdanovic-netmod-acl-model-02 as a WG draft Thread-Index: AQHP4wqZgoccLOXIYU6NUVXJCsIbYZwoiYSAgADJiwA= Date: Fri, 10 Oct 2014 13:17:42 +0000 Message-ID: <2D34D6C8-4D51-44E0-8BF1-5EEC71059F6D@juniper.net> References: <3E03501B-CA0B-433D-A18F-F77DD223EBE7@lucidvision.com> <2267A2CF-2103-47A9-99C8-E613017E252A@cisco.com> In-Reply-To: <2267A2CF-2103-47A9-99C8-E613017E252A@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.12] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB422; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 03607C04F0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(164054003)(24454002)(189002)(51704005)(199003)(64706001)(77156001)(104166001)(120916001)(31966008)(230783001)(50986999)(66066001)(87286001)(2656002)(101416001)(76482002)(87936001)(85852003)(82746002)(36756003)(62966002)(122556002)(19580395003)(19580405001)(40100002)(77096002)(33656002)(99396003)(89996001)(15975445006)(85306004)(83716003)(107046002)(86362001)(99286002)(93916002)(92726001)(106356001)(92566001)(105586002)(106116001)(95666004)(80022003)(46102003)(110136001)(21056001)(15202345003)(20776003)(76176999)(57306001)(50226001)(97736003)(4396001)(104396001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB422; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-ID: <63CC95094373FB41B7EF70474FAE80EC@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/CZDeVKWOPGnupJU0W3InbWsdeIE Cc: NETMOD Working Group Subject: Re: [netmod] Call for consensus to Accept ACL Model draft-bogdanovic-netmod-acl-model-02 as a WG draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 10 Oct 2014 13:18:18 -0000 On Oct 9, 2014, at 9:16 PM, Acee Lindem (acee) wrote: > Authors,=20 >=20 > I have reviewed the document and have two rather fundamental comments tha= t preclude me from supporting WG adoption.=20 >=20 > 1. I think you should change the rule-name (type string) to a sequence= -number (type uint16 or int32). While using a string is ostensibly more fle= xible, network administrators have been using sequence numbers for over 30 = years now and will be throughly disappointed when they discover that ACE = =9310=94 lexicographically precedes ACE =932=94. This comment has broader = significance than just access lists since this model, if adopted and standa= rdized, will set a precedent for future models.=20 Well, this is something we posted on the mailing list to ask opinions. Prob= lem with the sequence number is that inserting new entries is a problem if = the space is exhausted between entries. The rule-name type string is more f= lexible then a sequence number. > 2. Please remove section 5 from the draft. This draft should not mix p= acket filtering and route filtering. Though we may get to this hierarchy, I= believe that prefix-lists have much greater affinity with other routing po= licies than access-lists. Note that there is a separate route-filtering mo= del in https://datatracker.ietf.org/doc/draft-zhdankin-netmod-bgp-cfg/. Fin= ally, the RTGWG is now chartered for YANG models that are not specific to o= ther Routing area working groups. The discussion of route filters belongs t= here or in IDR (since BGP has the most rigorous routing policy requirements= ).=20 This is just an example how to add standard extensions. We needed a basic e= xample how to extend standard features and as you can see it is a bare mini= mum. Maybe enforcing language that this is solely an example would help? Dean >=20 > Also, a comparably minor comment, leaf-list targets requires a better def= inition. It really isn=92t very useful without some guidance as to how an i= mplementation=92s targets should be represented.=20 >=20 > Thanks, > Acee=20 >=20 >=20 >=20 > On Oct 8, 2014, at 11:14 AM, Thomas D. Nadeau w= rote: >=20 >>=20 >> The co-authors of draft-bogdanovic-netmod-acl-model-02 have asked the N= ETMOD chairs to post a call to adopt the draft as a WG document.=20 >>=20 >> The draft can be found here: >>=20 >> http://tools.ietf.org/html/draft-bogdanovic-netmod-acl-model-02 >>=20 >> The model itself has been extracted and can be directly accessed here u= sing git: >>=20 >> https://github.com/YangModels/yang/blob/master/experimental/ietf/ACL-MO= DEL/ >>=20 >> Please comment by the close of business on Monday, October 13, 2014. >>=20 >>=20 >> --Tom (As NETMOD co-chair) >>=20 >>=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 From nobody Fri Oct 10 06:25:12 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13BB61ACDFE for ; Fri, 10 Oct 2014 06:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.286 X-Spam-Level: X-Spam-Status: No, score=-15.286 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4WaX3HmOZ2X for ; Fri, 10 Oct 2014 06:25:07 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF86E1ACDCF for ; Fri, 10 Oct 2014 06:25:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9945; q=dns/txt; s=iport; t=1412947506; x=1414157106; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=P91KLFm9FZEBu6A0HKE05dX+XvMQaN1Auxir6FAc4mw=; b=jVy8UvkIbQqE3AUOGb833a/H+c9RO6l0seEfeZtT5SFRiuXFclkhY8Dq 2di1Ey4lYdR1X2PtGMVUODCeR1lugywKAUllrEZh+32hRrkrYIDm1tOYq LC5Cs3InnmVojLuPyRmS+RxeOudKyCrarS8hT1JW2eQKxgH/fiFjy2ycD I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAAndN1StJssH/2dsb2JhbABdA4MOU1iIYcJqAQmGeVQCgQYWAXuEAwEBAQMBAQEBawoBBQkCCxAICRYIBwkDAgECAQkMHxEGDQEFAgEBiDIIDcJhAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwSNAoJcEAIBIxwQBwkIhDoFhi2XHoEuhjiEboU/g36CDoFrOy8BgkkBAQE X-IronPort-AV: E=Sophos;i="5.04,692,1406592000"; d="scan'208,217";a="362196894" Received: from aer-core-2.cisco.com ([173.38.203.7]) by rcdn-iport-7.cisco.com with ESMTP; 10 Oct 2014 13:25:05 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s9ADP4Hx020676; Fri, 10 Oct 2014 13:25:04 GMT Message-ID: <5437DDFD.6000400@cisco.com> Date: Fri, 10 Oct 2014 15:24:13 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: "Thomas D. Nadeau" References: <766247DF-0BFB-4AAA-9D37-95B6819A4978@lucidvision.com> <20141008170313.GB73652@elstar.local> <54368522.9070402@cisco.com> <618473D4-D75D-4FA8-AFCB-405A4CBDC18A@lucidvision.com> In-Reply-To: <618473D4-D75D-4FA8-AFCB-405A4CBDC18A@lucidvision.com> Content-Type: multipart/alternative; boundary="------------020400000505020709030109" Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/9s4QwCLTVIAOWtkxqFihcZYgERQ Cc: NETMOD Working Group Subject: Re: [netmod] netmod wg interim meeting minutes .2014-10-08-14.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: Fri, 10 Oct 2014 13:25:09 -0000 This is a multi-part message in MIME format. --------------020400000505020709030109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Tom, > > On Oct 9, 2014:5:52 AM, at 5:52 AM, Benoit Claise > wrote: > >> Hi Tom, >> >> I'm all in favor of new participation tools. >> However, let's not forget >> https://www.ietf.org/iesg/statement/interim-meetings.html >> >> Detailed minutes, including a list of attendees, must be sent to >> proceedings@ietf.org and the >> working group mail list within 10 days of >> the event. >> >> So IRC is fine, and should be used as a tool to create the meeting >> minutes. >> Using whoever was logged in IRC as attendee list is not appropriate IMO. > > Why can't we just have everyone sign into IRC and post a message when > they join w their email address? Obviously, that didn't happen. Practically, in every meeting, you have people joining while the call already started. So, feel free to use whatever tools you want, but as, WG chair organizing this call, it's your responsibility to make sure that every person joining the call knows which tool to use and how to use it. In the end, what counts is to have good and complete meeting minutes. Regards, Benoit > I am very much trying to automate the process as much as possible. > >> Also, there were a couple of points mentioned during the meeting that >> were not captured in IRC (so in the minutes). Does it mean it's the >> speaker responsibility to make sure his point in the minutes? > > Kent was taking meeting minutes, so he must have missed the issue. > Volunteers - you get what you pay for! *) Seriously, the tool is not > the problem - it is just a means for recording the meeting and > conversations for those that also cannot connect into web ex for > whatever reason. > > --Tom > > >> >> Regards, Benoit >>> Yes there were. These we just those that joined irc which is how we recorded meeting minutes (thanks again Kent!). I asked everyone at the start to join and provided easy instructions for how to join. This is how we will continue to record meeting minutes and attendees going forward as it automates and streamlines things. >>> >>> Tom >>> >>> >>> >>>> On Oct 8, 2014, at 10:03 AM, Juergen Schoenwaelder wrote: >>>> >>>>> On Wed, Oct 08, 2014 at 09:38:28AM -0700, Thomas Nadeau wrote: >>>>> >>>>> People present (lines said) >>>>> --------------------------- >>>>> >>>>> * kwatsen (69) >>>>> * Thomas__ (30) >>>>> * meetbot (11) >>>>> * schoenw (7) >>>>> * Benoit__ (6) >>>>> * Clyde (2) >>>> I think there were more people in the call. I heard Lada speaking up >>>> for instance. >>>> >>>> /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 >>> >> > --------------020400000505020709030109 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Tom,


Hi Tom,

I'm all in favor of new participation tools.
However, let's not forget https://www.ietf.org/iesg/statement/interim-meetings.html
Detailed minutes, including a list of attendees, must be sent to
proceedings@ietf.org and the working group mail list within 10 days of
the event.
So IRC is fine, and should be used as a tool to create the meeting minutes.
Using whoever was logged in IRC as attendee list is not appropriate IMO.

Why can't we just have everyone sign into IRC and post a message when they join w their email address?
Obviously, that didn't happen. Practically, in every meeting, you have people joining while the call already started.
So, feel free to use whatever tools you want, but as, WG chair organizing this call, it's your responsibility to make sure that every person joining the call knows which tool to use and how to use it.
In the end, what counts is to have good and complete meeting minutes.

Regards, Benoit

I am very much trying to automate the process as much as possible.

Also, there were a couple of points mentioned during the meeting that were not captured in IRC (so in the minutes). Does it mean it's the speaker responsibility to make sure his point in the minutes?

Kent was taking meeting minutes, so he must have missed the issue. Volunteers - you get what you pay for! *)  Seriously, the tool is not the problem - it is just a means for recording the meeting and conversations for those that also cannot connect into web ex for whatever reason. 

--Tom



Regards, Benoit
Yes there were. These we just those that joined irc which is how we recorded meeting minutes (thanks again Kent!). I asked everyone at the start to join and provided easy instructions for how to join. This is how we will continue to record meeting minutes and attendees going forward as it automates and streamlines things.

Tom 




On Oct 8, 2014, at 10:03 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:


On Wed, Oct 08, 2014 at 09:38:28AM -0700, Thomas Nadeau wrote:

People present (lines said)
---------------------------

* kwatsen (69)
* Thomas__ (30)
* meetbot (11)
* schoenw (7)
* Benoit__ (6)
* Clyde (2)

I think there were more people in the call. I heard Lada speaking up
for instance.

/js

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



--------------020400000505020709030109-- From nobody Fri Oct 10 06:54:26 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBD441ACE06 for ; Fri, 10 Oct 2014 06:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=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 3IcHTFIrIcLG for ; Fri, 10 Oct 2014 06:54:22 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0739.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:739]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4918A1A031C for ; Fri, 10 Oct 2014 06:54:22 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB422.namprd05.prod.outlook.com (10.141.58.142) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Fri, 10 Oct 2014 13:53:53 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.226]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.226]) with mapi id 15.00.1049.012; Fri, 10 Oct 2014 13:53:53 +0000 From: Dean Bogdanovic To: Benoit Claise Thread-Topic: [netmod] netmod wg interim meeting minutes .2014-10-08-14.00 Thread-Index: AQHP4xZRz1TiHiZnHkqgAuBm8pxr3ZwmbVEAgAAEXACAAUgDAIAAhs6AgAEUTICAAAhGAA== Date: Fri, 10 Oct 2014 13:53:52 +0000 Message-ID: <3FE1F31A-70F3-44BB-B332-D260E32461A0@juniper.net> References: <766247DF-0BFB-4AAA-9D37-95B6819A4978@lucidvision.com> <20141008170313.GB73652@elstar.local> <54368522.9070402@cisco.com> <618473D4-D75D-4FA8-AFCB-405A4CBDC18A@lucidvision.com> <5437DDFD.6000400@cisco.com> In-Reply-To: <5437DDFD.6000400@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.12] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB422; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 03607C04F0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(52044002)(24454002)(189002)(43784003)(5423002)(199003)(64706001)(77156001)(104166001)(120916001)(16236675004)(230783001)(31966008)(50986999)(66066001)(87286001)(2656002)(101416001)(76482002)(87936001)(85852003)(82746002)(62966002)(36756003)(122556002)(19580395003)(19580405001)(40100002)(77096002)(33656002)(99396003)(89996001)(15975445006)(85306004)(83716003)(107046002)(86362001)(99286002)(93916002)(92726001)(106356001)(92566001)(105586002)(106116001)(95666004)(80022003)(46102003)(19617315012)(110136001)(21056001)(93886004)(15202345003)(20776003)(76176999)(57306001)(50226001)(97736003)(4396001)(104396001)(142923001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB422; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_3FE1F31A70F344BBB332D260E32461A0junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/hMPJx_DgA_WrPXjD_aGGfPwj_HI Cc: NETMOD Working Group Subject: Re: [netmod] netmod wg interim meeting minutes .2014-10-08-14.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: Fri, 10 Oct 2014 13:54:25 -0000 --_000_3FE1F31A70F344BBB332D260E32461A0junipernet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Benoit, Tom, I joined the IRC, but didn't post any comment. My name was recorded by the = channel (when I joined it), but didn't show up in the summary, as didn't ty= pe anything into it. Dean On Oct 10, 2014, at 9:24 AM, Benoit Claise > wrote: Tom, On Oct 9, 2014:5:52 AM, at 5:52 AM, Benoit Claise > wrote: Hi Tom, I'm all in favor of new participation tools. However, let's not forget https://www.ietf.org/iesg/statement/interim-meeti= ngs.html Detailed minutes, including a list of attendees, must be sent to proceedings@ietf.org and the working group mai= l list within 10 days of the event. So IRC is fine, and should be used as a tool to create the meeting minutes. Using whoever was logged in IRC as attendee list is not appropriate IMO. Why can't we just have everyone sign into IRC and post a message when they = join w their email address? Obviously, that didn't happen. Practically, in every meeting, you have peop= le joining while the call already started. So, feel free to use whatever tools you want, but as, WG chair organizing t= his call, it's your responsibility to make sure that every person joining t= he call knows which tool to use and how to use it. In the end, what counts is to have good and complete meeting minutes. Regards, Benoit I am very much trying to automate the process as much as possible. Also, there were a couple of points mentioned during the meeting that were = not captured in IRC (so in the minutes). Does it mean it's the speaker resp= onsibility to make sure his point in the minutes? Kent was taking meeting minutes, so he must have missed the issue. Voluntee= rs - you get what you pay for! *) Seriously, the tool is not the problem -= it is just a means for recording the meeting and conversations for those t= hat also cannot connect into web ex for whatever reason. --Tom Regards, Benoit Yes there were. These we just those that joined irc which is how we recorde= d meeting minutes (thanks again Kent!). I asked everyone at the start to jo= in and provided easy instructions for how to join. This is how we will cont= inue to record meeting minutes and attendees going forward as it automates = and streamlines things. Tom On Oct 8, 2014, at 10:03 AM, Juergen Schoenwaelder wrote: On Wed, Oct 08, 2014 at 09:38:28AM -0700, Thomas Nadeau wrote: People present (lines said) --------------------------- * kwatsen (69) * Thomas__ (30) * meetbot (11) * schoenw (7) * Benoit__ (6) * Clyde (2) I think there were more people in the call. I heard Lada speaking up for instance. /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 --_000_3FE1F31A70F344BBB332D260E32461A0junipernet_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable Benoit, Tom,

I joined the IRC, but didn't post any comment. My name was recorded by= the channel (when I joined it), but didn't show up in the summary, as didn= 't type anything into it. 

Dean

On Oct 10, 2014, at 9:24 AM, Benoit Claise <bclaise@cisco.com> wrote:

Tom,

On Oct 9, 2014:5:52 AM, at 5:52 AM, Benoit Claise <bclaise@cisco.com> wro= te:

Hi Tom,

I'm all in favor of new participation tools.
However, let's not forget https://www.ietf.org/ie= sg/statement/interim-meetings.html
Detailed minutes, including a list of attendees, must be = sent to
proc= eedings@ietf.org and the working group mail list within 10 days of
the event.
So IRC is fine, and should be used as a tool to create the meeting mi= nutes.
Using whoever was logged in IRC as attendee list is not appropriate IMO.

Why ca= n't we just have everyone sign into IRC and post a message when they join w= their email address?
Obviously, that didn't happen. Practically, in every meeting, you have peop= le joining while the call already started.
So, feel free to use whatever tools you want, but as, WG chair organizing t= his call, it's your responsibility to make sure that every person joining t= he call knows which tool to use and how to use it.
In the end, what counts is to have good and complete meeting minutes.

Regards, Benoit

I am very much trying to automate the process as much as possible.

Also, there were a couple of points me= ntioned during the meeting that were not captured in IRC (so in the minutes= ). Does it mean it's the speaker responsibility to make sure his point in t= he minutes?

Kent w= as taking meeting minutes, so he must have missed the issue. Volunteers - y= ou get what you pay for! *)  Seriously, the tool is not the problem - = it is just a means for recording the meeting and conversations for those that also cannot connect into web ex for whate= ver reason. 

--Tom<= /div>



Regards, Benoit
Yes there were. These we just those that joined irc which is=
 how we recorded meeting minutes (thanks again Kent!). I asked everyone at =
the start to join and provided easy instructions for how to join. This is h=
ow we will continue to record meeting minutes and attendees going forward a=
s it automates and streamlines things.

Tom=20




On Oct 8, 2014, at 10:03 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:


On Wed, Oct 08, 2014 at 09:38:28AM -0700, Thomas Nadeau wrot=
e:

People present (lines said)
---------------------------

* kwatsen (69)
* Thomas__ (30)
* meetbot (11)
* schoenw (7)
* Benoit__ (6)
* Clyde (2)

I think there were more people in the call. I heard Lada spe=
aking up
for instance.

/js

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


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



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

--_000_3FE1F31A70F344BBB332D260E32461A0junipernet_-- From nobody Fri Oct 10 08:13:33 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8D61A034B for ; Fri, 10 Oct 2014 08:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RsWYRCqtHOs4 for ; Fri, 10 Oct 2014 08:13:26 -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 3536A1A02BD for ; Fri, 10 Oct 2014 08:13:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4106; q=dns/txt; s=iport; t=1412954006; x=1414163606; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=P5sArJoucTHnnBHxh4vt5wSvQh6tSlmk8pcs/lpztn8=; b=Sydp+Swt2GK7yfDgOBWMuKr++AUv6SP4xGLK2cZ2yBuZdoHerFdHgOAm c3uvIAxNobxA7tweQljt8+R3WHc4PZnyaC5RQ0ZcBTQsESeV+dAZ/QPUD HkvNy64DUp9nC85bQHjSZqS2kdAgz0h/B9rVSOU4/HsojcVHVi0oRFyjx g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAA/3N1StJA2F/2dsb2JhbABggw5TWATLUAqGeVQCgQUWAXuEAwEBAQMBAQEBGlELBQsCAQgYIwsnCyUCBA4FiDYIDcFaAQEBAQEBAQEBAQEBAQEBAQEBAQEBF5ARMweESwWLIIZZhEKEPoJSgS4RK4MKkR2BfDiBQ2yBSIECAQEB X-IronPort-AV: E=Sophos;i="5.04,692,1406592000"; d="scan'208";a="85828989" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-6.cisco.com with ESMTP; 10 Oct 2014 15:13:25 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s9AFDPs0019734 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 Oct 2014 15:13:25 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.175]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Fri, 10 Oct 2014 10:13:25 -0500 From: "Acee Lindem (acee)" To: Dean Bogdanovic Thread-Topic: [netmod] Call for consensus to Accept ACL Model draft-bogdanovic-netmod-acl-model-02 as a WG draft Thread-Index: AQHP4wqZOFU3Ld8VA0GsywXxS1v2spwo3UyAgADJlQD//91FAA== Date: Fri, 10 Oct 2014 15:13:25 +0000 Message-ID: References: <3E03501B-CA0B-433D-A18F-F77DD223EBE7@lucidvision.com> <2267A2CF-2103-47A9-99C8-E613017E252A@cisco.com> <2D34D6C8-4D51-44E0-8BF1-5EEC71059F6D@juniper.net> In-Reply-To: <2D34D6C8-4D51-44E0-8BF1-5EEC71059F6D@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.196] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Advd1PtxcnrjaQH8qTLgbyt-Rfc Cc: NETMOD Working Group Subject: Re: [netmod] Call for consensus to Accept ACL Model draft-bogdanovic-netmod-acl-model-02 as a WG draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 10 Oct 2014 15:13:28 -0000 Hi Dean,=20 On 10/10/14, 9:17 AM, "Dean Bogdanovic" wrote: > >On Oct 9, 2014, at 9:16 PM, Acee Lindem (acee) wrote: > >> Authors,=20 >>=20 >> I have reviewed the document and have two rather fundamental comments >>that preclude me from supporting WG adoption. >>=20 >> 1. I think you should change the rule-name (type string) to a >>sequence-number (type uint16 or int32). While using a string is >>ostensibly more flexible, network administrators have been using >>sequence numbers for over 30 years now and will be throughly >>disappointed when they discover that ACE =B310=B2 lexicographically prece= des >>ACE =B32=B2. This comment has broader significance than just access list= s >>since this model, if adopted and standardized, will set a precedent for >>future models.=20 > >Well, this is something we posted on the mailing list to ask opinions. I=B9ll have to look in the archives. Was the rule-name string given support or simply no opposition? > Problem with the sequence number is that inserting new entries is a >problem if the space is exhausted between entries. The rule-name type >string is more flexible then a sequence number. Like I said, list based policies have used sequence numbers for over 30 years and this has not proved to be a serious problem. I don=B9t think we should change semantics with so little benefit when modeling existing constructs. For something completely new, these new ordering semantics could be explored. If I=B9m the only one who sees this as unwieldy, I=B9ll concede. I=B9ve auto-generated many configs with number based interface names or VRFs and been really annoyed at the sorted ordering. > >> 2. Please remove section 5 from the draft. This draft should not mix >>packet filtering and route filtering. Though we may get to this >>hierarchy, I believe that prefix-lists have much greater affinity with >>other routing policies than access-lists. Note that there is a separate >>route-filtering model in >>https://datatracker.ietf.org/doc/draft-zhdankin-netmod-bgp-cfg/. >>Finally, the RTGWG is now chartered for YANG models that are not >>specific to other Routing area working groups. The discussion of route >>filters belongs there or in IDR (since BGP has the most rigorous routing >>policy requirements). > >This is just an example how to add standard extensions. We needed a basic >example how to extend standard features and as you can see it is a bare >minimum. Maybe enforcing language that this is solely an example would >help? I didn=B9t notice that it was an example. I think this needs to be more clear - maybe even moved to an appendix. However, I=B9m happy as long as it is not normative.=20 Thanks, Acee=20 > >Dean > >>=20 >> Also, a comparably minor comment, leaf-list targets requires a better >>definition. It really isn=B9t very useful without some guidance as to how >>an implementation=B9s targets should be represented. >>=20 >> Thanks, >> Acee=20 >>=20 >>=20 >>=20 >> On Oct 8, 2014, at 11:14 AM, Thomas D. Nadeau >>wrote: >>=20 >>>=20 >>> The co-authors of draft-bogdanovic-netmod-acl-model-02 have asked the >>>NETMOD chairs to post a call to adopt the draft as a WG document. >>>=20 >>> The draft can be found here: >>>=20 >>> http://tools.ietf.org/html/draft-bogdanovic-netmod-acl-model-02 >>>=20 >>> The model itself has been extracted and can be directly accessed here >>>using git: >>>=20 >>>=20 >>> https://github.com/YangModels/yang/blob/master/experimental/ietf/ACL-MO >>>DEL/ >>>=20 >>> Please comment by the close of business on Monday, October 13, 2014. >>>=20 >>>=20 >>> --Tom (As NETMOD co-chair) >>>=20 >>>=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 > From nobody Fri Oct 10 08:53:43 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D48011A1AED for ; Fri, 10 Oct 2014 08:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sACChsf4cM_G for ; Fri, 10 Oct 2014 08:53:39 -0700 (PDT) Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 916A41A1A27 for ; Fri, 10 Oct 2014 08:53:39 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id x3so2175020qcv.10 for ; Fri, 10 Oct 2014 08:53:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=DJtnKm4rXfsk/uw6iidSEsjp7zXDcq8k9UmsmBI8ErY=; b=Fwh7aVc2z3esEj9Iyd6rPsClyeFvCYosIyN0s/9RvqVPDGegS8GHE8ktWwjRD3fxpP RKnt9mujdwyluvkm6z7JJHQP37zvdmw1jfxidQbw2ZeOmn5w1lWJBllvtPYGI1ZiRYg/ qRTeMJheaVvsMPD4VpsSkpBYuNPCOgoupyR53BDblute9tltqkayjuwAZW1d3ZSfXXTF zmjHk5mL20tztwDPOsncFjPTF7cA03KIjczeseuwdmg+nLGwKH2lX2jQayWrUzDFaGHD wBCn93Ik2PKBVlDd7S886PZUEYRtTowuXcuXaLJS5MLMQ108FFPSIJ7t8eWycX6EwOm/ GBrA== X-Gm-Message-State: ALoCoQk9g5jYBLh3VvsQVniGH3/L+fMCkpvA8y646H2r0mELcR3KoeLHR6gU7ptjd7wKEgf58JsY MIME-Version: 1.0 X-Received: by 10.229.27.71 with SMTP id h7mr9611841qcc.8.1412956418681; Fri, 10 Oct 2014 08:53:38 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Fri, 10 Oct 2014 08:53:38 -0700 (PDT) In-Reply-To: References: <3E03501B-CA0B-433D-A18F-F77DD223EBE7@lucidvision.com> <2267A2CF-2103-47A9-99C8-E613017E252A@cisco.com> <2D34D6C8-4D51-44E0-8BF1-5EEC71059F6D@juniper.net> Date: Fri, 10 Oct 2014 08:53:38 -0700 Message-ID: From: Andy Bierman To: "Acee Lindem (acee)" Content-Type: multipart/alternative; boundary=001a1133e5486b6ae40505138d8e Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/sr6piwEsJnUCoYF6cfET9Q3liMo Cc: NETMOD Working Group Subject: Re: [netmod] Call for consensus to Accept ACL Model draft-bogdanovic-netmod-acl-model-02 as a WG draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 10 Oct 2014 15:53:42 -0000 --001a1133e5486b6ae40505138d8e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Oct 10, 2014 at 8:13 AM, Acee Lindem (acee) wrote: > Hi Dean, > > On 10/10/14, 9:17 AM, "Dean Bogdanovic" wrote: > > > > >On Oct 9, 2014, at 9:16 PM, Acee Lindem (acee) wrote: > > > >> Authors, > >> > >> I have reviewed the document and have two rather fundamental comments > >>that preclude me from supporting WG adoption. > >> > >> 1. I think you should change the rule-name (type string) to a > >>sequence-number (type uint16 or int32). While using a string is > >>ostensibly more flexible, network administrators have been using > >>sequence numbers for over 30 years now and will be throughly > >>disappointed when they discover that ACE =B310=B2 lexicographically pre= cedes > >>ACE =B32=B2. This comment has broader significance than just access li= sts > >>since this model, if adopted and standardized, will set a precedent for > >>future models. > > > >Well, this is something we posted on the mailing list to ask opinions. > > I=B9ll have to look in the archives. Was the rule-name string given suppo= rt > or simply no opposition? > > > Problem with the sequence number is that inserting new entries is a > >problem if the space is exhausted between entries. The rule-name type > >string is more flexible then a sequence number. > > Like I said, list based policies have used sequence numbers for over 30 > years and this has not proved to be a serious problem. I don=B9t think we > should change semantics with so little benefit when modeling existing > constructs. For something completely new, these new ordering semantics > could be explored. If I=B9m the only one who sees this as unwieldy, I=B9l= l > concede. I=B9ve auto-generated many configs with number based interface > names or VRFs and been really annoyed at the sorted ordering. > > But this is YANG, not CLI. YANG has user-ordered lists so the keys do not have to be used to dictate an order (and should not be used). The keys can be used to describe the entry, so "9" and "10" are just labels. They sort correctly because the list is ordered-by user and the user knows that, and is expected to provide or insert entries in the desired order. Andy > > > > >> 2. Please remove section 5 from the draft. This draft should not mi= x > >>packet filtering and route filtering. Though we may get to this > >>hierarchy, I believe that prefix-lists have much greater affinity with > >>other routing policies than access-lists. Note that there is a separat= e > >>route-filtering model in > >>https://datatracker.ietf.org/doc/draft-zhdankin-netmod-bgp-cfg/. > >>Finally, the RTGWG is now chartered for YANG models that are not > >>specific to other Routing area working groups. The discussion of route > >>filters belongs there or in IDR (since BGP has the most rigorous routin= g > >>policy requirements). > > > >This is just an example how to add standard extensions. We needed a basi= c > >example how to extend standard features and as you can see it is a bare > >minimum. Maybe enforcing language that this is solely an example would > >help? > > I didn=B9t notice that it was an example. I think this needs to be more > clear - maybe even moved to an appendix. However, I=B9m happy as long as = it > is not normative. > > Thanks, > Acee > > > > > >Dean > > > >> > >> Also, a comparably minor comment, leaf-list targets requires a better > >>definition. It really isn=B9t very useful without some guidance as to h= ow > >>an implementation=B9s targets should be represented. > >> > >> Thanks, > >> Acee > >> > >> > >> > >> On Oct 8, 2014, at 11:14 AM, Thomas D. Nadeau > >>wrote: > >> > >>> > >>> The co-authors of draft-bogdanovic-netmod-acl-model-02 have asked > the > >>>NETMOD chairs to post a call to adopt the draft as a WG document. > >>> > >>> The draft can be found here: > >>> > >>> http://tools.ietf.org/html/draft-bogdanovic-netmod-acl-model-02 > >>> > >>> The model itself has been extracted and can be directly accessed > here > >>>using git: > >>> > >>> > >>> > https://github.com/YangModels/yang/blob/master/experimental/ietf/ACL-MO > >>>DEL/ > >>> > >>> Please comment by the close of business on Monday, October 13, > 2014. > >>> > >>> > >>> --Tom (As NETMOD 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 > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a1133e5486b6ae40505138d8e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Fri, Oct 10, 2014 at 8:13 AM, Acee Lindem (acee) &= lt;acee@cisco.com&g= t; wrote:
Hi Dean,

On 10/10/14, 9:17 AM, "Dean Bogdanovic" <deanb@juniper.net> wrote:

>
>On Oct 9, 2014, at 9:16 PM, Acee Lindem (acee) <acee@cisco.com> wrote:
>
>> Authors,
>>
>> I have reviewed the document and have two rather fundamental comme= nts
>>that preclude me from supporting WG adoption.
>>
>>=A0 =A0 1. I think you should change the rule-name (type string) to= a
>>sequence-number (type uint16 or int32). While using a string is
>>ostensibly more flexible, network administrators have been using >>sequence numbers for over 30 years now and will be throughly
>>disappointed when they discover that ACE =B310=B2 lexicographically= precedes
>>ACE =B32=B2.=A0 This comment has broader significance than just acc= ess lists
>>since this model, if adopted and standardized, will set a precedent= for
>>future models.
>
>Well, this is something we posted on the mailing list to ask opinions.<= br>
I=B9ll have to look in the archives. Was the rule-name string given support=
or simply no opposition?

> Problem with the sequence number is that inserting new entries is a >problem if the space is exhausted between entries. The rule-name type >string is more flexible then a sequence number.

Like I said, list based policies have used sequence numbers for over 30
years and this has not proved to be a serious problem. I don=B9t think we should change semantics with so little benefit when modeling existing
constructs. For something completely new, these new ordering semantics
could be explored. If I=B9m the only one who sees this as unwieldy, I=B9ll<= br> concede. I=B9ve auto-generated many configs with number based interface
names or VRFs and been really annoyed at the sorted ordering.



But this is YANG, not C= LI.
YANG has user-ordered lists so the keys do not have to be use= d
to dictate an order (and should not be used).=A0 The keys can b= e
used to describe the entry, so "9" and "10"= are just labels.
They sort correctly because the list is ordered= -by user and the user
knows that, and is expected to provide or i= nsert entries in the desired order.


Andy


=A0

>
>>=A0 =A0 2. Please remove section 5 from the draft. This draft shoul= d not mix
>>packet filtering and route filtering. Though we may get to this
>>hierarchy, I believe that prefix-lists have much greater affinity w= ith
>>other routing policies=A0 than access-lists. Note that there is a s= eparate
>>route-filtering model in
>>https://datatracker.ietf.org/doc/draft-zhdankin-= netmod-bgp-cfg/.
>>Finally, the RTGWG is now chartered for YANG models that are not >>specific to other Routing area working groups. The discussion of ro= ute
>>filters belongs there or in IDR (since BGP has the most rigorous ro= uting
>>policy requirements).
>
>This is just an example how to add standard extensions. We needed a bas= ic
>example how to extend standard features and as you can see it is a bare=
>minimum.=A0 Maybe enforcing language that this is solely an example wou= ld
>help?

I didn=B9t notice that it was an example. I think this needs to be more
clear - maybe even moved to an appendix. However, I=B9m happy as long as it=
is not normative.

Thanks,
Acee


>
>Dean
>
>>
>> Also, a comparably minor comment, leaf-list targets requires a bet= ter
>>definition. It really isn=B9t very useful without some guidance as = to how
>>an implementation=B9s targets should be represented.
>>
>> Thanks,
>> Acee
>>
>>
>>
>> On Oct 8, 2014, at 11:14 AM, Thomas D. Nadeau <tnadeau@lucidvision.com>
>>wrote:
>>
>>>
>>>=A0 =A0 =A0The co-authors of draft-bogdanovic-netmod-acl-model-= 02 have asked the
>>>NETMOD chairs to post a call to adopt the draft as a WG documen= t.
>>>
>>>=A0 =A0 =A0The draft can be found here:
>>>
>>>=A0 =A0 =A0http://tools.ietf.org/html/draft-= bogdanovic-netmod-acl-model-02
>>>
>>>=A0 =A0 =A0The model itself has been extracted and can be direc= tly accessed here
>>>using git:
>>>
>>>
>>>=A0 =A0 =A0https://github.com/YangMo= dels/yang/blob/master/experimental/ietf/ACL-MO
>>>DEL/
>>>
>>>=A0 =A0 =A0Please comment by the close of business on Monday, O= ctober 13, 2014.
>>>
>>>
>>>=A0 =A0 =A0--Tom (As NETMOD 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
>

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

--001a1133e5486b6ae40505138d8e-- From nobody Fri Oct 10 08:58:44 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4A771A8732 for ; Fri, 10 Oct 2014 08:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786, 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 4UCNjX55BCmh for ; Fri, 10 Oct 2014 08:58:28 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id E86B21A86EC for ; Fri, 10 Oct 2014 08:58:19 -0700 (PDT) Received: from [192.168.1.121] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 2705428BB84A; Fri, 10 Oct 2014 11:58:19 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_50DADF0C-FEAB-40C2-917A-65F7F5FCD33A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: <3FE1F31A-70F3-44BB-B332-D260E32461A0@juniper.net> Date: Fri, 10 Oct 2014 11:58:15 -0400 Message-Id: <409409DD-6289-4B1A-B44F-9CD451537BFC@lucidvision.com> References: <766247DF-0BFB-4AAA-9D37-95B6819A4978@lucidvision.com> <20141008170313.GB73652@elstar.local> <54368522.9070402@cisco.com> <618473D4-D75D-4FA8-AFCB-405A4CBDC18A@lucidvision.com> <5437DDFD.6000400@cisco.com> <3FE1F31A-70F3-44BB-B332-D260E32461A0@juniper.net> To: Dean Bogdanovic X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ioI5c1b9xeOFPt6e-4LqZR-0s8A Cc: NETMOD Working Group Subject: Re: [netmod] netmod wg interim meeting minutes .2014-10-08-14.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: Fri, 10 Oct 2014 15:58:34 -0000 --Apple-Mail=_50DADF0C-FEAB-40C2-917A-65F7F5FCD33A Content-Type: multipart/alternative; boundary="Apple-Mail=_F95AEC40-E9EE-4796-8185-2702A3E8CE04" --Apple-Mail=_F95AEC40-E9EE-4796-8185-2702A3E8CE04 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Yes. What we will be doing at the next meeting is taking a roll = call asking for names of who is on the call and I will ask again half = way through the meeting and again at the end. These will be recorded in = IRC as notes. --Tom On Oct 10, 2014:9:53 AM, at 9:53 AM, Dean Bogdanovic = wrote: > Benoit, Tom, >=20 > I joined the IRC, but didn't post any comment. My name was recorded by = the channel (when I joined it), but didn't show up in the summary, as = didn't type anything into it.=20 >=20 > Dean >=20 > On Oct 10, 2014, at 9:24 AM, Benoit Claise wrote: >=20 >> Tom, >>>=20 >>> On Oct 9, 2014:5:52 AM, at 5:52 AM, Benoit Claise = wrote: >>>=20 >>>> Hi Tom, >>>>=20 >>>> I'm all in favor of new participation tools. >>>> However, let's not forget = https://www.ietf.org/iesg/statement/interim-meetings.html >>>> Detailed minutes, including a list of attendees, must be sent to >>>> proceedings@ietf.org and the working group mail list within 10 days = of >>>> the event. >>>> So IRC is fine, and should be used as a tool to create the meeting = minutes. >>>> Using whoever was logged in IRC as attendee list is not appropriate = IMO. >>>=20 >>> Why can't we just have everyone sign into IRC and post a message = when they join w their email address? >> Obviously, that didn't happen. Practically, in every meeting, you = have people joining while the call already started. >> So, feel free to use whatever tools you want, but as, WG chair = organizing this call, it's your responsibility to make sure that every = person joining the call knows which tool to use and how to use it. >> In the end, what counts is to have good and complete meeting minutes. >>=20 >> Regards, Benoit >>=20 >>> I am very much trying to automate the process as much as possible.=20= >>>=20 >>>> Also, there were a couple of points mentioned during the meeting = that were not captured in IRC (so in the minutes). Does it mean it's the = speaker responsibility to make sure his point in the minutes? >>>=20 >>> Kent was taking meeting minutes, so he must have missed the issue. = Volunteers - you get what you pay for! *) Seriously, the tool is not = the problem - it is just a means for recording the meeting and = conversations for those that also cannot connect into web ex for = whatever reason.=20 >>>=20 >>> --Tom >>>=20 >>>=20 >>>>=20 >>>> Regards, Benoit >>>>> Yes there were. These we just those that joined irc which is how = we recorded meeting minutes (thanks again Kent!). I asked everyone at = the start to join and provided easy instructions for how to join. This = is how we will continue to record meeting minutes and attendees going = forward as it automates and streamlines things. >>>>>=20 >>>>> Tom=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> On Oct 8, 2014, at 10:03 AM, Juergen Schoenwaelder = wrote: >>>>>>=20 >>>>>>> On Wed, Oct 08, 2014 at 09:38:28AM -0700, Thomas Nadeau wrote: >>>>>>>=20 >>>>>>> People present (lines said) >>>>>>> --------------------------- >>>>>>>=20 >>>>>>> * kwatsen (69) >>>>>>> * Thomas__ (30) >>>>>>> * meetbot (11) >>>>>>> * schoenw (7) >>>>>>> * Benoit__ (6) >>>>>>> * Clyde (2) >>>>>> I think there were more people in the call. I heard Lada speaking = up >>>>>> for instance. >>>>>>=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 >>>>>=20 >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 --Apple-Mail=_F95AEC40-E9EE-4796-8185-2702A3E8CE04 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1

Yes. What we will be doing at the next meeting is taking a roll call asking for names of who is on the call and I will ask again half way through the meeting and again at the end. These will be recorded in IRC as notes.

--Tom



On Oct 10, 2014:9:53 AM, at 9:53 AM, Dean Bogdanovic <deanb@juniper.net> wrote:

Benoit, Tom,

I joined the IRC, but didn't post any comment. My name was recorded by the channel (when I joined it), but didn't show up in the summary, as didn't type anything into it. 

Dean

On Oct 10, 2014, at 9:24 AM, Benoit Claise <bclaise@cisco.com> wrote:

Tom,

On Oct 9, 2014:5:52 AM, at 5:52 AM, Benoit Claise <bclaise@cisco.com> wrote:

Hi Tom,

I'm all in favor of new participation tools.
However, let's not forget https://www.ietf.org/iesg/statement/interim-meetings.html
Detailed minutes, including a list of attendees, must be sent to
proceedings@ietf.org and the working group mail list within 10 days of
the event.
So IRC is fine, and should be used as a tool to create the meeting minutes.
Using whoever was logged in IRC as attendee list is not appropriate IMO.

Why can't we just have everyone sign into IRC and post a message when they join w their email address?
Obviously, that didn't happen. Practically, in every meeting, you have people joining while the call already started.
So, feel free to use whatever tools you want, but as, WG chair organizing this call, it's your responsibility to make sure that every person joining the call knows which tool to use and how to use it.
In the end, what counts is to have good and complete meeting minutes.

Regards, Benoit

I am very much trying to automate the process as much as possible.

Also, there were a couple of points mentioned during the meeting that were not captured in IRC (so in the minutes). Does it mean it's the speaker responsibility to make sure his point in the minutes?

Kent was taking meeting minutes, so he must have missed the issue. Volunteers - you get what you pay for! *)  Seriously, the tool is not the problem - it is just a means for recording the meeting and conversations for those that also cannot connect into web ex for whatever reason. 

--Tom



Regards, Benoit
Yes there were. These we just those that joined irc which is how we recorded meeting minutes (thanks again Kent!). I asked everyone at the start to join and provided easy instructions for how to join. This is how we will continue to record meeting minutes and attendees going forward as it automates and streamlines things.

Tom 




On Oct 8, 2014, at 10:03 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:


On Wed, Oct 08, 2014 at 09:38:28AM -0700, Thomas Nadeau wrote:

People present (lines said)
---------------------------

* kwatsen (69)
* Thomas__ (30)
* meetbot (11)
* schoenw (7)
* Benoit__ (6)
* Clyde (2)

I think there were more people in the call. I heard Lada speaking up
for instance.

/js

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



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


--Apple-Mail=_F95AEC40-E9EE-4796-8185-2702A3E8CE04-- --Apple-Mail=_50DADF0C-FEAB-40C2-917A-65F7F5FCD33A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUOAIXAAoJEPcO+I7eiUJZPGUP/jw9EiT6y0OVYWCQWLDahwP3 NQPxgEn6/meSrtAXK+d2xbP9zYHptSrh6pQmFqeZxG4kBLbM0jRp5lvotNFCFpAA EuEtXEIp4K2kb3e8LeWwH5WluaSGhzLLoT81WXxFPJGuP9sBaungIMv7SAkOtETG cTMUNvymsi2xtEcMQIO+qt+2DdPTHkYClnysA79nNVTCF0Tlxfx3jeyPn8HK/TV6 AxlFFxmjDM1GqOcEgkkpkk/3UIqwW30J6hwRUPkXGKvM2RtH/3PuKor6r3uhS0h2 UDhAWnrlQdU/zTP1rRy6QQwK2YZtKzFgMMbgCMHYPnsR1Cta30y4jHs5L1YVezoH oQJcnkthjjwNa1pKO8QSIkgHvJvTtH/nDas9JURazGawIpbog3TR0QMdEITVPalm Lp1Nye05qxBhJ8uK9Rdc+y9jJyuj+4QOTnyJzs34uTd614udMFVCa2PpOl7CYj0e UV0/J3MQH3BySJZN9jXfx3KLPcFYNyEomSvD8y5ZulOcY7EI/xXV9bBn1PKhpm8+ 2dXGM3uftR72Wtuq0LqphEAVC1N7VIcTwakXFfFcvrprxUBIZTR9qSlP+g5w9RRu 1JzF3e7lgzyibpJyprngP4/uh+Du3J9a28eFb+p81KMC4jlkEp4UB87nan0wuokL WdDz+KFRtgBBpwvfOUf8 =/fTq -----END PGP SIGNATURE----- --Apple-Mail=_50DADF0C-FEAB-40C2-917A-65F7F5FCD33A-- From nobody Fri Oct 10 09:00:16 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A84311A6FD4 for ; Fri, 10 Oct 2014 09:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786, 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 mf417uTnJ_t6 for ; Fri, 10 Oct 2014 09:00:10 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1431A8733 for ; Fri, 10 Oct 2014 09:00:09 -0700 (PDT) Received: from [192.168.1.121] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id D56F328BB887; Fri, 10 Oct 2014 12:00:08 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_09FF86D2-0442-4695-B02D-1471282CCF4E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: <5437DDFD.6000400@cisco.com> Date: Fri, 10 Oct 2014 12:00:05 -0400 Message-Id: <568564F0-09C9-4F70-AB4A-FC85476A7506@lucidvision.com> References: <766247DF-0BFB-4AAA-9D37-95B6819A4978@lucidvision.com> <20141008170313.GB73652@elstar.local> <54368522.9070402@cisco.com> <618473D4-D75D-4FA8-AFCB-405A4CBDC18A@lucidvision.com> <5437DDFD.6000400@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/MCEUk0m66MuECqty4Rl_yz_TGss Cc: NETMOD Working Group Subject: Re: [netmod] netmod wg interim meeting minutes .2014-10-08-14.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: Fri, 10 Oct 2014 16:00:15 -0000 --Apple-Mail=_09FF86D2-0442-4695-B02D-1471282CCF4E Content-Type: multipart/alternative; boundary="Apple-Mail=_AED1F4EA-1D9A-4F69-9EDB-0B35AAE1D787" --Apple-Mail=_AED1F4EA-1D9A-4F69-9EDB-0B35AAE1D787 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Oct 10, 2014:9:24 AM, at 9:24 AM, Benoit Claise = wrote: > Tom, >>=20 >> On Oct 9, 2014:5:52 AM, at 5:52 AM, Benoit Claise = wrote: >>=20 >>> Hi Tom, >>>=20 >>> I'm all in favor of new participation tools. >>> However, let's not forget = https://www.ietf.org/iesg/statement/interim-meetings.html >>> Detailed minutes, including a list of attendees, must be sent to >>> proceedings@ietf.org and the working group mail list within 10 days = of >>> the event. >>> So IRC is fine, and should be used as a tool to create the meeting = minutes. >>> Using whoever was logged in IRC as attendee list is not appropriate = IMO. >>=20 >> Why can't we just have everyone sign into IRC and post a message = when they join w their email address? > Obviously, that didn't happen. It didn't happen because I incorrectly assumed they were = auto-recorded. Next time I will explicitly ask people to post their = email/name for the record like in a blue sheet. > Practically, in every meeting, you have people joining while the call = already started. Yes. This is the same issue you have in a physical meeting. All = we do there is ask a few times for people to sign the blue sheet. We can = do that here too. > So, feel free to use whatever tools you want, but as, WG chair = organizing this call, it's your responsibility to make sure that every = person joining the call knows which tool to use and how to use it. > In the end, what counts is to have good and complete meeting minutes. Yep. --Tom >=20 > Regards, Benoit >=20 >> I am very much trying to automate the process as much as possible.=20 >>=20 >>> Also, there were a couple of points mentioned during the meeting = that were not captured in IRC (so in the minutes). Does it mean it's the = speaker responsibility to make sure his point in the minutes? >>=20 >> Kent was taking meeting minutes, so he must have missed the issue. = Volunteers - you get what you pay for! *) Seriously, the tool is not = the problem - it is just a means for recording the meeting and = conversations for those that also cannot connect into web ex for = whatever reason.=20 >>=20 >> --Tom >>=20 >>=20 >>>=20 >>> Regards, Benoit >>>> Yes there were. These we just those that joined irc which is how we = recorded meeting minutes (thanks again Kent!). I asked everyone at the = start to join and provided easy instructions for how to join. This is = how we will continue to record meeting minutes and attendees going = forward as it automates and streamlines things. >>>>=20 >>>> Tom=20 >>>>=20 >>>>=20 >>>>=20 >>>>> On Oct 8, 2014, at 10:03 AM, Juergen Schoenwaelder = wrote: >>>>>=20 >>>>>> On Wed, Oct 08, 2014 at 09:38:28AM -0700, Thomas Nadeau wrote: >>>>>>=20 >>>>>> People present (lines said) >>>>>> --------------------------- >>>>>>=20 >>>>>> * kwatsen (69) >>>>>> * Thomas__ (30) >>>>>> * meetbot (11) >>>>>> * schoenw (7) >>>>>> * Benoit__ (6) >>>>>> * Clyde (2) >>>>> I think there were more people in the call. I heard Lada speaking = up >>>>> for instance. >>>>>=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 >>>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_AED1F4EA-1D9A-4F69-9EDB-0B35AAE1D787 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
On Oct 10, 2014:9:24 AM, at 9:24 AM, Benoit Claise <bclaise@cisco.com> wrote:

Tom,

On Oct 9, 2014:5:52 AM, at 5:52 AM, Benoit Claise <bclaise@cisco.com> wrote:

Hi Tom,

I'm all in favor of new participation tools.
However, let's not forget https://www.ietf.org/iesg/statement/interim-meetings.html
Detailed minutes, including a list of attendees, must be sent to
proceedings@ietf.org and the working group mail list within 10 days of
the event.
So IRC is fine, and should be used as a tool to create the meeting minutes.
Using whoever was logged in IRC as attendee list is not appropriate IMO.

Why can't we just have everyone sign into IRC and post a message when they join w their email address?
Obviously, that didn't happen.

It didn't happen because I incorrectly assumed they were auto-recorded. Next time I will explicitly ask people to post their email/name for the record like in a blue sheet.

Practically, in every meeting, you have people joining while the call already started.

Yes. This is the same issue you have in a physical meeting. All we do there is ask a few times for people to sign the blue sheet. We can do that here too.

So, feel free to use whatever tools you want, but as, WG chair organizing this call, it's your responsibility to make sure that every person joining the call knows which tool to use and how to use it.
In the end, what counts is to have good and complete meeting minutes.

Yep.

--Tom




Regards, Benoit

I am very much trying to automate the process as much as possible.

Also, there were a couple of points mentioned during the meeting that were not captured in IRC (so in the minutes). Does it mean it's the speaker responsibility to make sure his point in the minutes?

Kent was taking meeting minutes, so he must have missed the issue. Volunteers - you get what you pay for! *)  Seriously, the tool is not the problem - it is just a means for recording the meeting and conversations for those that also cannot connect into web ex for whatever reason. 

--Tom



Regards, Benoit
Yes there were. These we just those that joined irc which is how we recorded meeting minutes (thanks again Kent!). I asked everyone at the start to join and provided easy instructions for how to join. This is how we will continue to record meeting minutes and attendees going forward as it automates and streamlines things.

Tom 




On Oct 8, 2014, at 10:03 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:


On Wed, Oct 08, 2014 at 09:38:28AM -0700, Thomas Nadeau wrote:

People present (lines said)
---------------------------

* kwatsen (69)
* Thomas__ (30)
* meetbot (11)
* schoenw (7)
* Benoit__ (6)
* Clyde (2)

I think there were more people in the call. I heard Lada speaking up
for instance.

/js

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




--Apple-Mail=_AED1F4EA-1D9A-4F69-9EDB-0B35AAE1D787-- --Apple-Mail=_09FF86D2-0442-4695-B02D-1471282CCF4E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUOAKFAAoJEPcO+I7eiUJZAcoP/266vHByBnG5h9Kt3Bl5n4Ct MD/ymQ4uruEtjrC/DhhgGZpbd+4EVEChL8tdU99gqzIWOPD72RBgdCG1gFj/2a0d anw7xU6jyNjpmRf26iaGgNz1XQdFXuQgSnmciU33F2jbzQz1ue3KzEppYeC1RwsG oVl0WZXum4UlQC+YmCe0qG8TYMaC4QpIN1Km72CSitsrrZAK2HrCAcumZGz0fch/ tA4HpQNu6vqieIhEHkD/B00YUOL+5xJMGRT/Dm/k1buoXrthQbqscXQt9TInjvOz Ijz6xCxG/jq6YZq9T4t0LJ/grsgg5Nf+b0ow/JFu7YzSdL6qtI6fmGRE++51/3hq kWuO35DGglSwbvZWBELuDD2XOWdL2yG6oqPoMZGXMSRu/SNTtnEdxp69Lsk/Jd/f QfOHqeeHklv7ujCj5PKqWWMVFGxPsqRu/Ems3sfR0GWe73ZGz3W0BitMKwfdE4Wy UcDsZWU46/v38C6Vv8sQAoL8oWqf05nMYBlTHrekdi5AvurhAPwQDfseBWGJT5XX BuGVCIOZxOejobCyvSJRxp2JitfJ5OnhDHPKW/dctlStgJY105yZKUDY0O/wT18r NVyh4Rf3Up9Q8kFibs8IDh72m7i8MqornEb+S7IdfsxBi+qgPdNqWoZC8O2R/xy4 +5TiYVKpuThxKFkygm/B =J9Aj -----END PGP SIGNATURE----- --Apple-Mail=_09FF86D2-0442-4695-B02D-1471282CCF4E-- From nobody Fri Oct 10 11:30:55 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 108031ACD7D for ; Fri, 10 Oct 2014 11:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.286 X-Spam-Level: X-Spam-Status: No, score=-15.286 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nGPoZm_JnV5 for ; Fri, 10 Oct 2014 11:30:40 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E40771ACD75 for ; Fri, 10 Oct 2014 11:30:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14784; q=dns/txt; s=iport; t=1412965836; x=1414175436; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=UMbAQaar+g6/0Cwmz3aEXpw6PIS2+U5bykHM9dW/C5I=; b=MxHvo3R+GwLMw4GlW4qZe+2SkV29lI6zqMQ8tXdm6JQd3HQLnjQ5BqP7 Y9FpBbcf7XAJFMNpRVD7E2PF1cWRDfcmRXGDwOD5Zcwuc19fvijAMZopw B19cFEozLpjFlWJOw0QfQwe8vo07ZNMeIFNrhxP+nY1pFJPOOk/F9Iisa I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYFAMIkOFStJV2T/2dsb2JhbABggkhGU1gE0mwCgQUWAXuEAwECBC1FBxIBCBEDAQIoORQJCAEBBAENBYg+v1sBAQEBAQEBAQEBAQEBAQEBAQEBAQEXkDMRB4RLBYUVjGSLUoEukGWDfoN3bIFIgQIBAQE X-IronPort-AV: E=Sophos;i="5.04,693,1406592000"; d="scan'208,217";a="362342495" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-3.cisco.com with ESMTP; 10 Oct 2014 18:30:35 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s9AIUXvk007049 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 Oct 2014 18:30:34 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Fri, 10 Oct 2014 13:30:32 -0500 From: "Lisa Huang (yihuan)" To: Yangang , "Dana Blair (dblair)" , "kkoushik@brocade.com" , Dean Bogdanovic , "Benoit Claise (bclaise)" Thread-Topic: Some comments about ACL YANG model. Thread-Index: Ac/kfG/69WbYy6R4S1u5RcAcGjY6pwAKxGAA Date: Fri, 10 Oct 2014 18:30:31 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.154.204.104] Content-Type: multipart/alternative; boundary="_000_D05D6F4255CBAyihuanciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/unz64-gRmjWhKm8ePcKLdgXbCS0 Cc: Zhengguangying , "netmod@ietf.org" , Lizhenbin Subject: Re: [netmod] Some comments about ACL 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: Fri, 10 Oct 2014 18:30:46 -0000 --_000_D05D6F4255CBAyihuanciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Yanggang, thanks for your review. Response in line. From: Yangang > Date: Friday, October 10, 2014 4:22 AM To: "Dana Blair (dblair)" >, Micr= osoft Office User >, "kkoushik@br= ocade.com" >, Dean Bogdanovic >, "Benoit Claise (bclaise)" > Cc: "netmod@ietf.org" >, Zhengguangying >, "Liubing (Leo)" >, Lizhenbin = > Subject: Some comments about ACL YANG model. Hi, I am reviewing the ACL YANG model. And I got some doubts, maybe somebody ca= n help me to understand it. 1. There is one field: targets. In my understanding, maybe it is used = to record who reference this ACL. I don=92t know if Is it mandatory or not.= Or my understanding is wrong. List of targets where ACL is applied. It is optional. 2. In packet-fields module, It looks the current definition is not so = sufficient. For example, no "!=3D" definition, Can you clarify? Do you mean !=3D for port source-port-range or des= tination-port-range? The draft doesn't intend to cover all fields in a pack= et but allows vendor to augment the model and extend the features. and no mask in acl-ipv4-header-fields group, etc=85.. Each leaf in acl-ipv4-header-fields group includes prefix because = of its type. We can enhance the description or the leaf name to avoid confu= sion. leaf destination-ipv4-address { type inet:ipv4-prefix; } 3. In this draft, there is acl-type and ace-type. It looks the IP pack= et match and Ethernet packet match can be configured together. But it looks= only "OR" relationship is at there, no "AND" relationship. Thanks Yangang --_000_D05D6F4255CBAyihuanciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Yanggang= , thanks for your review. Response in line.

From: Yangang <yangang@huawei.com>
Date: Friday, October 10, 2014 4:22= AM
To: "Dana Blair (dblair)"= <dblair@cisco.com>, Microsof= t Office User <yihuan@cisco.com&= gt;, "kkoushik@brocade.com= " <kkoushik@brocade.com>, = Dean Bogdanovic <deanb@juniper.net<= /a>>, "Benoit Claise (bclaise)" <bclaise@cisco.com>
Cc: "netmod@ietf.org" <= netmod@ietf.org>, Zhengguangying <zhengguangying@huawei.com>, "Liubing (Leo)" <leo.liubing@huawei.com&g= t;, Lizhenbin <lizhenbin@huawei.= com>
Subject: Some comments about ACL YA= NG model.

Hi, =

 

I am= reviewing the ACL YANG model. And I got some doubts, maybe somebody can he= lp me to understand it.

 

1.      There is one field: targets. In my understanding, maybe it is used = to record who reference this ACL. I don=92t know if Is it mandatory or not.= Or my understanding is wrong.

 

 
<yihuan>List of ta=
rgets where ACL is applied. It is optional.

2.      In packet-fields module, It looks the current definition is not so = sufficient. For example, no "!=3D" definition, 

 
<yihuan>Can you clarify? Do you mean= !=3D for port source-port-range or destination-port-range? The draft doesn't intend to cover all fields in a packet but allows vendor= to augment the model and extend the features.

and no mask in acl-ipv= 4-header-fields group, etc=85..

<yihuan> Each leaf in acl-ipv4-header-fields group includes= prefix because of its type. We can enhance the description or the leaf nam= e to avoid confusion.
lea= f destination-ipv4-address {
            type inet:ipv4-prefix;<=
/span>
        }

3.      In this draft, there is acl-type and ace-type. It looks the IP pack= et match and Ethernet packet match can be configured together. But it looks= only "OR" relationship is at there, no "AND" relationship.


 

Than= ks

Yang= ang

 --_000_D05D6F4255CBAyihuanciscocom_-- From nobody Fri Oct 10 11:36:13 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 699521ACDBD for ; Fri, 10 Oct 2014 11:36: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 i692mGs9x1WL for ; Fri, 10 Oct 2014 11:36:08 -0700 (PDT) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D50841ACD9D for ; Fri, 10 Oct 2014 11:36:07 -0700 (PDT) Received: by mail-qc0-f175.google.com with SMTP id x13so2403885qcv.34 for ; Fri, 10 Oct 2014 11:36:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rPoPsAd0vVdhJTLboL119z70ON36N/cDmFzwy7sh6Ew=; b=n4cojleyeAqx7707Hz0T1kufVAD/Rdp/bLQ1FpPcdl9du5b72hhberFn9BO0kQPlqA VZTRyvsQ7+RcRTf3XsP/Z2mmmuRQ+UuzascqPW2/W/KNuchFqVhzMkjZzbqFojAiihmg z3ytOFn31gvhfMZxAhrli2cgHnp3GVuOJfGhs056VUEiazeqUIvS4UZ9nXMgIfVSSL8X uT0cuXqMFDd6PbLgx1sIH4o79sjWhwQFvLEcWhZ5JREdk6e5X79Yxdn2RuIO17c41Trd js8uif6gVHBgXbSXouEPneN21R1vvkMKjxwwJt0eUK8x2utvIVAzSPkEhYnghxBg5Pq2 LWjw== X-Received: by 10.140.81.176 with SMTP id f45mr11303480qgd.62.1412966167066; Fri, 10 Oct 2014 11:36:07 -0700 (PDT) Received: from [192.168.1.101] (108-247-124-220.lightspeed.sntcca.sbcglobal.net. [108.247.124.220]) by mx.google.com with ESMTPSA id z89sm5655085qge.39.2014.10.10.11.36.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 10 Oct 2014 11:36:06 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: Mahesh Jethanandani In-Reply-To: Date: Fri, 10 Oct 2014 11:36:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0DA310C9-D8A7-4CF4-8AA1-5EC4CF95FE61@gmail.com> References: <3E03501B-CA0B-433D-A18F-F77DD223EBE7@lucidvision.com> <2267A2CF-2103-47A9-99C8-E613017E252A@cisco.com> <2D34D6C8-4D51-44E0-8BF1-5EEC71059F6D@juniper.net> To: "Acee Lindem (acee)" X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/YrqF7PLY0lH-oUMDZ1Tm3B1syqA Cc: NETMOD Working Group Subject: Re: [netmod] Call for consensus to Accept ACL Model draft-bogdanovic-netmod-acl-model-02 as a WG draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 10 Oct 2014 18:36:11 -0000 On Oct 10, 2014, at 8:13 AM, Acee Lindem (acee) wrote: >>>=20 >>> 1. I think you should change the rule-name (type string) to a >>> sequence-number (type uint16 or int32). While using a string is >>> ostensibly more flexible, network administrators have been using >>> sequence numbers for over 30 years now and will be throughly >>> disappointed when they discover that ACE =B310=B2 lexicographically = precedes >>> ACE =B32=B2. This comment has broader significance than just access = lists >>> since this model, if adopted and standardized, will set a precedent = for >>> future models.=20 >>=20 >> Well, this is something we posted on the mailing list to ask = opinions. >=20 > I=B9ll have to look in the archives. Was the rule-name string given = support > or simply no opposition? >=20 >> Problem with the sequence number is that inserting new entries is a >> problem if the space is exhausted between entries. The rule-name type >> string is more flexible then a sequence number. >=20 > Like I said, list based policies have used sequence numbers for over = 30 > years and this has not proved to be a serious problem. I don=B9t think = we > should change semantics with so little benefit when modeling existing > constructs. For something completely new, these new ordering semantics > could be explored. If I=B9m the only one who sees this as unwieldy, = I=B9ll > concede. I=B9ve auto-generated many configs with number based = interface > names or VRFs and been really annoyed at the sorted ordering. But the ACE is a ordered-by user list. If you do not the like the order = YANG generates, reorder it. Mahesh Jethanandani mjethanandani@gmail.com From nobody Fri Oct 10 11:59:51 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CDF21ACE5D for ; Fri, 10 Oct 2014 11:59: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 GdK0dA2VA1LJ for ; Fri, 10 Oct 2014 11:59:47 -0700 (PDT) Received: from mail-qg0-f41.google.com (mail-qg0-f41.google.com [209.85.192.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5B5A1ACE5B for ; Fri, 10 Oct 2014 11:59:47 -0700 (PDT) Received: by mail-qg0-f41.google.com with SMTP id f51so4416631qge.14 for ; Fri, 10 Oct 2014 11:59:46 -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=QlEOKcuNOyxfhjEMMSbBak2xCTrKs7EVfliSC8LUqj4=; b=lySZcCKLDwBRPV4BSSKfWO0XJo3ZvNe3BOBHBqALHxN64bejheUDfxz0xYkkgeteIf XBS1z8Xyki6Xz9aCp17pfZhAJHl8al9u3CXy5Ev3Np/Y8SVpKoandJQifvtufhtpVEiA gppHlu+VFRev1aLUFYewmsY38vUbQRFi4O0taNk7vKBKjUplQT7KLQKhkYtP6+xmXmJ3 rz1m95Qqn1AXTJEBYUHuYcM86DTU52TgHBK90qIF+Sb2l6J2wRGcW85Velh0huQU+qbv FcSapFNhNUgzSsSfWHc8Oyh+eW61scSHB75L/jCMqzv9IJjFEVkPO5xbRFZUU2JJ92TQ wwjQ== X-Gm-Message-State: ALoCoQmGMsq0U3VqWAslEOOpjhe5snKUjnOdZH8TX+HALaQeie8qkii0KBQby9cIuKiZ7m5UIbdi MIME-Version: 1.0 X-Received: by 10.229.24.137 with SMTP id v9mr11409295qcb.14.1412967586901; Fri, 10 Oct 2014 11:59:46 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Fri, 10 Oct 2014 11:59:46 -0700 (PDT) In-Reply-To: <0DA310C9-D8A7-4CF4-8AA1-5EC4CF95FE61@gmail.com> References: <3E03501B-CA0B-433D-A18F-F77DD223EBE7@lucidvision.com> <2267A2CF-2103-47A9-99C8-E613017E252A@cisco.com> <2D34D6C8-4D51-44E0-8BF1-5EEC71059F6D@juniper.net> <0DA310C9-D8A7-4CF4-8AA1-5EC4CF95FE61@gmail.com> Date: Fri, 10 Oct 2014 11:59:46 -0700 Message-ID: From: Andy Bierman To: Mahesh Jethanandani Content-Type: multipart/alternative; boundary=001a113351a418d70805051627c8 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/uxOqvOYOWAihUhHyzKHlMMX_GMM Cc: NETMOD Working Group Subject: Re: [netmod] Call for consensus to Accept ACL Model draft-bogdanovic-netmod-acl-model-02 as a WG draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 10 Oct 2014 18:59:49 -0000 --001a113351a418d70805051627c8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Oct 10, 2014 at 11:36 AM, Mahesh Jethanandani < mjethanandani@gmail.com> wrote: > > On Oct 10, 2014, at 8:13 AM, Acee Lindem (acee) wrote: > > >>> > >>> 1. I think you should change the rule-name (type string) to a > >>> sequence-number (type uint16 or int32). While using a string is > >>> ostensibly more flexible, network administrators have been using > >>> sequence numbers for over 30 years now and will be throughly > >>> disappointed when they discover that ACE =B310=B2 lexicographically > precedes > >>> ACE =B32=B2. This comment has broader significance than just access = lists > >>> since this model, if adopted and standardized, will set a precedent f= or > >>> future models. > >> > >> Well, this is something we posted on the mailing list to ask opinions. > > > > I=B9ll have to look in the archives. Was the rule-name string given sup= port > > or simply no opposition? > > > >> Problem with the sequence number is that inserting new entries is a > >> problem if the space is exhausted between entries. The rule-name type > >> string is more flexible then a sequence number. > > > > Like I said, list based policies have used sequence numbers for over 30 > > years and this has not proved to be a serious problem. I don=B9t think = we > > should change semantics with so little benefit when modeling existing > > constructs. For something completely new, these new ordering semantics > > could be explored. If I=B9m the only one who sees this as unwieldy, I= =B9ll > > concede. I=B9ve auto-generated many configs with number based interface > > names or VRFs and been really annoyed at the sorted ordering. > > But the ACE is a ordered-by user list. If you do not the like the order > YANG generates, reorder it. > YANG does not generate an order. YANG just says whether the entry order provided by the client in edit requests is significant or not. Some NETCONF servers will sort system-ordered entries, if configured that way, but YANG does not require any particular ordering for those entries. For a list that is ordered-by user, the order is totally up to the client. By default, new user-ordered entries are added last (after existing entries in the target datastore). The order these entries are provided in XML instance documents (e.g. ) must be maintained by the server. In JSON the array order must be preserved. > Mahesh Jethanandani > mjethanandani@gmail.com > > > Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a113351a418d70805051627c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Fri, Oct 10, 2014 at 11:36 AM, Mahesh Jethanandani <mjethanan= dani@gmail.com> wrote:

On Oct 10, 2014, at 8:13 AM, Acee Lindem (acee) wrote:

>>>
>>>=A0 =A01. I think you should change the rule-name (type string)= to a
>>> sequence-number (type uint16 or int32). While using a string i= s
>>> ostensibly more flexible, network administrators have been usi= ng
>>> sequence numbers for over 30 years now and will be throughly >>> disappointed when they discover that ACE =B310=B2 lexicographi= cally precedes
>>> ACE =B32=B2.=A0 This comment has broader significance than jus= t access lists
>>> since this model, if adopted and standardized, will set a prec= edent for
>>> future models.
>>
>> Well, this is something we posted on the mailing list to ask opini= ons.
>
> I=B9ll have to look in the archives. Was the rule-name string given su= pport
> or simply no opposition?
>
>> Problem with the sequence number is that inserting new entries is = a
>> problem if the space is exhausted between entries. The rule-name t= ype
>> string is more flexible then a sequence number.
>
> Like I said, list based policies have used sequence numbers for over 3= 0
> years and this has not proved to be a serious problem. I don=B9t think= we
> should change semantics with so little benefit when modeling existing<= br> > constructs. For something completely new, these new ordering semantics=
> could be explored. If I=B9m the only one who sees this as unwieldy, I= =B9ll
> concede. I=B9ve auto-generated many configs with number based interfac= e
> names or VRFs and been really annoyed at the sorted ordering.

But the ACE is a ordered-by user list. If you do not the like the order YAN= G generates, reorder it.

YANG does not = generate an order.
YANG just says whether the entry order provide= d by the client in edit requests is
significant or not.=A0 Some N= ETCONF servers will sort system-ordered entries,
if configured th= at way, but YANG does not require any particular ordering for those entries= .

For a list that is ordered-by user, the order is= totally up to the client.
By default, new user-ordered entries a= re added last (after existing
entries in the target datastore).= =A0 The order these entries are provided
in XML instance document= s (e.g. <edit-config>) must be maintained by the server.
In= JSON the array order must be preserved.



Mahesh Jethanandani
mjethanandani@gmail.com



Andy
=A0

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

--001a113351a418d70805051627c8-- From nobody Fri Oct 10 12:03:38 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 658A41ACE69 for ; Fri, 10 Oct 2014 12:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.511 X-Spam-Level: X-Spam-Status: No, score=-0.511 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, MALFORMED_FREEMAIL=1.487, MIME_QP_LONG_LINE=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 c1e9nBRWUd3s for ; Fri, 10 Oct 2014 12:03:33 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31E7F1ACE75 for ; Fri, 10 Oct 2014 12:03:33 -0700 (PDT) Received: by mail-pa0-f53.google.com with SMTP id kq14so2302454pab.12 for ; Fri, 10 Oct 2014 12:03:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :mime-version:content-type; bh=tblUbSs3SscG/zKlaupl/pyGf4PgJgZ/uIH/tZ9+S5c=; b=E3LadkvKw2L13Nsp1Lpz3Bp69ZV5IcBdoi047Ezo1EKyb2JzkJ1C4zGBtR/BapX+Hq 5hk1NSKWTshDyZWwqyAMJ9VSeHEgcVDg00BrCWQvAwzTikTyrTFICvA1Aw8CbQiz9NIk 0pMgahwsi67BT0mTcClEqjJI3FF+MlqKIub5Z0ImCqDArm/+MREYHpUxR+wbtwqkLbig AXV2gC9j0gizyIZ1bXqWMf2Mq+O59MPxA4zTCGXUpqNdet3/xhjX53KjbjJ1tvguXfGV UYdLm7KGQa/vqU1AcvW15CS+OhDldooAmI9IagFgjTPQZsqVrWkbQyG1Euky2cRwJ8Ov FoKA== X-Received: by 10.70.103.100 with SMTP id fv4mr7411416pdb.38.1412967812791; Fri, 10 Oct 2014 12:03:32 -0700 (PDT) Received: from [10.21.80.113] (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPSA id w1sm4179171pdb.52.2014.10.10.12.03.25 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 10 Oct 2014 12:03:31 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.4.4.140807 Date: Fri, 10 Oct 2014 12:03:21 -0700 From: Reinaldo Penno To: "Lisa Huang (yihuan)" , Yangang , "Dana Blair (dblair)" , "kkoushik@brocade.com" , Dean Bogdanovic , "Benoit Claise (bclaise)" Message-ID: Thread-Topic: [netmod] Some comments about ACL YANG model. Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3495787410_3344993" Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/TBFDlB-jzAuFpY2Qx2MOHPVu3r0 Cc: Zhengguangying , Lizhenbin , "netmod@ietf.org" Subject: Re: [netmod] Some comments about ACL 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: Fri, 10 Oct 2014 19:03:35 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3495787410_3344993 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable My suggestion would be to keep ACL draft as an intersection of ACL features found in vendor equipment as opposed to union. Keep it tight and small. One of the problems of the previous ACL draft is that it tried to cover every single possible feature. Folks can always augment ACL document with all kinds of features they need. From: "Lisa Huang (yihuan)" Date: Friday, October 10, 2014 at 11:30 AM To: Yangang , "Dana Blair (dblair)" = , "kkoushik@brocade.com" , Dean Bogdanovic , "Benoit Claise (bclaise)" Cc: Zhengguangying , "netmod@ietf.org" , Lizhenbin Subject: Re: [netmod] Some comments about ACL YANG model. Yanggang, thanks for your review. Response in line. From: Yangang Date: Friday, October 10, 2014 4:22 AM To: "Dana Blair (dblair)" , Microsoft Office User , "kkoushik@brocade.com" , Dean Bogdanovic , "Benoit Claise (bclaise)" Cc: "netmod@ietf.org" , Zhengguangying , "Liubing (Leo)" , Lizhenbin Subject: Some comments about ACL YANG model. Hi,=20 =20 I am reviewing the ACL YANG model. And I got some doubts, maybe somebody ca= n help me to understand it. =20 1. There is one field: targets. In my understanding, maybe it is used t= o record who reference this ACL. I don=B9t know if Is it mandatory or not. Or m= y understanding is wrong. =20 List of targets where ACL is applied. It is optional. 2. In packet-fields module, It looks the current definition is not so sufficient. For example, no "!=3D" definition, =20 Can you clarify? Do you mean !=3D for port source-port-range or destination-port-range? The draft doesn't intend to cover all fields in a packet but allows vendor to augment the model and extend the features. and no mask in acl-ipv4-header-fields group, etc=8A.. Each leaf in acl-ipv4-header-fields group includes prefix because of its type. We can enhance the description or the leaf name to avoid confusion. leaf destination-ipv4-address { type inet:ipv4-prefix; } 3. In this draft, there is acl-type and ace-type. It looks the IP packe= t match and Ethernet packet match can be configured together. But it looks only "OR" relationship is at there, no "AND" relationship. =20 Thanks Yangang _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --B_3495787410_3344993 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
My suggestion would be to kee= p ACL draft as an intersection of ACL features found in vendor equipment as = opposed to union. Keep it tight and small. One of the problems of the previo= us ACL draft is that it tried to cover every single possible feature.  = Folks can always augment ACL document with all kinds of features they need.&= nbsp;



From: "Lisa Huang (yihuan)" <yihuan@cisco.com>
Date: Friday, October 10, 2014 at 11:30 AM
To= : Yangang <yangang@huawei.com= >, "Dana Blair (dblair)" <dblair= @cisco.com>, "kkoushik@brocade.= com" <kkoushik@brocade.com&= gt;, Dean Bogdanovic <deanb@juniper.ne= t>, "Benoit Claise (bclaise)" <= bclaise@cisco.com>
Cc: Zhen= gguangying <zhengguangying@hua= wei.com>, "netmod@ietf.org" <= netmod@ietf.org>, Lizhenbin <lizhenbin@huawei.com>
Subject: Re: [netmod] Some comments about ACL Y= ANG model.

Ya= nggang, thanks for your review. Response in line.

From: Yangang <yangang@huawei.com>=
Date: Friday, October 10, 2014 4:2= 2 AM
To: "Dana Blair (dblair)" <= dblair@cisco.com>, Microsoft Office= User <yihuan@cisco.com>, "kkoushik@brocade.com" <kkoushik@brocade.com>, De= an Bogdanovic <deanb@juniper.net&g= t;, "Benoit Claise (bclaise)" <bclaise= @cisco.com>
Cc: "netmod@ietf.org" <netmod@ietf.org>, Zhengguangying <zhengguangying@huawei.com>, "Liubing (Leo)" <leo.liubing@huawei.com>= , Lizhenbin <lizhenbin@huawei.com>
Subject: Some comments about= ACL YANG model.


2.    &nb= sp; In packet-fields module, It looks the current definition is not so suffi= cient. For example, no "!=3D" definition, 

 

<yihuan&g= t;Can you clarify? Do you mean !=3D for port source-port-range or destination-port-ran= ge? The draft doesn't intend to cover all fields in a packet but allows vendor= to augment the model and extend the features.

and no mask in acl-ipv4-header-fields group, etc= …..

<yihuan> Each leaf in acl-ipv4-header-fields group = includes prefix because of its type. We can enhance the description or the l= eaf name to avoid confusion.

leaf destination-ipv4-address {
            type inet:ipv4-prefix;
        }

3.   = ;   In this draft, there is acl-type and ace-type. It looks the IP packet ma= tch and Ethernet packet match can be configured together. But it looks only = "OR" relationship is at there, no "AND" relationship.


<= div>

<= /span>

<= o:p> 

Thanks

Yangang

_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org= /mailman/listinfo/netmod --B_3495787410_3344993-- From nobody Fri Oct 10 14:09:55 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE5371A875E for ; Fri, 10 Oct 2014 14:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85mQHSlPtlq8 for ; Fri, 10 Oct 2014 14:09: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 776271AD3FD for ; Fri, 10 Oct 2014 14:09: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 C92B8903; Fri, 10 Oct 2014 23:09: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 GDV6raHYu23c; Fri, 10 Oct 2014 23:09:36 +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, 10 Oct 2014 23:09:38 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 40F0A20036; Fri, 10 Oct 2014 23:09:38 +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 e26-5NtVyccg; Fri, 10 Oct 2014 23:09:31 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B030120035; Fri, 10 Oct 2014 23:09:35 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E0B0D2EEA125; Fri, 10 Oct 2014 23:09:34 +0200 (CEST) Date: Fri, 10 Oct 2014 23:09:34 +0200 From: Juergen Schoenwaelder To: "Jan Medved (jmedved)" Message-ID: <20141010210934.GB80385@elstar.local> Mail-Followup-To: "Jan Medved (jmedved)" , Kent Watsen , "Alexander Clemm (alex)" , "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: http://mailarchive.ietf.org/arch/msg/netmod/yjfQ_k5o0506s4ql5UNROnpxAVc Cc: "netmod@ietf.org" Subject: Re: [netmod] New revision of YANG mount draft 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, 10 Oct 2014 21:09:47 -0000 On Thu, Oct 09, 2014 at 09:59:31PM +0000, Jan Medved (jmedved) wrote: > > Today, Yang does not allow a controller application to work directly with > device yang models. A controller has to re-define device models into > controller-specific models inside the controller and present the redefined > models to applications. How is this falling out of RFC 6020? /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 Oct 10 14:21:39 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7C9A1AD404 for ; Fri, 10 Oct 2014 14:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0NBoqD12_K5 for ; Fri, 10 Oct 2014 14:21:31 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 960B91AD402 for ; Fri, 10 Oct 2014 14:21:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2244; q=dns/txt; s=iport; t=1412976091; x=1414185691; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=41GQXk5PUVIbJFs+WX4O8JY/IyhQoKNRt7nzLJ1QipI=; b=BWh/gGTkCePpBi9gE+3k26JIM5UXmHGYK/qgwfsfJgowRPG20bpQ/I/1 0Zmz6fh1HY8Z8Uq6lmSTkrCC7d/b/tqkFHDFBZxL5S0VxccdsJ2nirqmK jKTn4mTFtmdCf9gPCJ/A/fD1uYOLy/R8H4+uK8Wi3l2fczMXwHGB8Q6YL E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAJhMOFStJA2L/2dsb2JhbABdA4MOU1gEyx+HUQKBBRYBe4QDAQEBBDo/DAICAgEIDgIBBAEBAQoUCQcbFxQJCAIEAQ0FCIg2v28BAQEBAQEBAQEBAQEBAQEBAQEBAQEXBJAPIRAHBguDHIEeBZF5oWODd2yBSIECAQEB X-IronPort-AV: E=Sophos;i="5.04,694,1406592000"; d="scan'208";a="85946880" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-7.cisco.com with ESMTP; 10 Oct 2014 21:21:30 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s9ALLT1P022931 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 Oct 2014 21:21:29 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.163]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Fri, 10 Oct 2014 16:21:29 -0500 From: "Alexander Clemm (alex)" To: Juergen Schoenwaelder , "Jan Medved (jmedved)" Thread-Topic: [netmod] New revision of YANG mount draft Thread-Index: AQHP40Rf8kMXz8u2QICzU6EjzD0qC5wopeSAgAGEYAD//6x3sA== Date: Fri, 10 Oct 2014 21:21:29 +0000 Message-ID: References: <20141010210934.GB80385@elstar.local> In-Reply-To: <20141010210934.GB80385@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.204.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/6kZXo2BCzMvHFXh2rHyirLfVd1Q Cc: "netmod@ietf.org" Subject: Re: [netmod] New revision of YANG mount draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 10 Oct 2014 21:21:34 -0000 What this refers to is the case of a hierarchy, where a system in a client = role accesseses another system in a server role (e.g. a controller) which i= tself is a client to another server (e.g. a network device). One (straight= forward) approach is to ignore the fact that the server (e.g. the controlle= r) can be a client, and simply have it incorporate its own set of YANG mode= ls to represent the other devices below it. The downside is that this requ= ires the controller to redefine and implement those models - they cannot be= simply reused as e.g. the "scope" is different, and the server has to have= a semantic "understanding" of everything in the devices underneath it. Thi= s brings about the same situation that NMS has had for decades, that integr= ating new devices into an operational environment is held hostage by the NM= S, which first needs to support (and require corresponding development supp= ort for) all those new parameters. In our case, we want to have the option= to simply incorporate "subtrees" from the device and make them accessible = to other applications by mounting them, without requiring further developme= nt (or requiring systems to "go around" the controller, which complicates d= evelopment of those other system and/or introduces other issues such as syn= chronization). =20 --- Alex -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Friday, October 10, 2014 2:10 PM To: Jan Medved (jmedved) Cc: Kent Watsen; Alexander Clemm (alex); netmod@ietf.org Subject: Re: [netmod] New revision of YANG mount draft On Thu, Oct 09, 2014 at 09:59:31PM +0000, Jan Medved (jmedved) wrote: >=20 > Today, Yang does not allow a controller application to work directly=20 > with device yang models. A controller has to re-define device models=20 > into controller-specific models inside the controller and present the=20 > redefined models to applications. How is this falling out of RFC 6020? /js --=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 Fri Oct 10 14:32:26 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54F2D1AD40A for ; Fri, 10 Oct 2014 14:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRmx1YBLX1LJ for ; Fri, 10 Oct 2014 14:32: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 B52931AD41C for ; Fri, 10 Oct 2014 14:32: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 85693E19; Fri, 10 Oct 2014 23:32: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 g92nT2IQXQHl; Fri, 10 Oct 2014 23:32:12 +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, 10 Oct 2014 23:32:13 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id D3F7720036; Fri, 10 Oct 2014 23:32: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 UvQ-g_F93VXw; Fri, 10 Oct 2014 23:32: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 1446720035; Fri, 10 Oct 2014 23:32:13 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 748F92EEA24F; Fri, 10 Oct 2014 23:32:12 +0200 (CEST) Date: Fri, 10 Oct 2014 23:32:12 +0200 From: Juergen Schoenwaelder To: Andy Bierman , Ladislav Lhotka Message-ID: <20141010213212.GC80385@elstar.local> Mail-Followup-To: Andy Bierman , Ladislav Lhotka , NETMOD Working Group References: <3E03501B-CA0B-433D-A18F-F77DD223EBE7@lucidvision.com> <2267A2CF-2103-47A9-99C8-E613017E252A@cisco.com> <2D34D6C8-4D51-44E0-8BF1-5EEC71059F6D@juniper.net> <0DA310C9-D8A7-4CF4-8AA1-5EC4CF95FE61@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: http://mailarchive.ietf.org/arch/msg/netmod/xiu1f39M83PLAC8hmUsxjklsv3w Cc: NETMOD Working Group Subject: Re: [netmod] Call for consensus to Accept ACL Model draft-bogdanovic-netmod-acl-model-02 as a WG draft 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, 10 Oct 2014 21:32:20 -0000 On Fri, Oct 10, 2014 at 11:59:46AM -0700, Andy Bierman wrote: > For a list that is ordered-by user, the order is totally up to the client. > By default, new user-ordered entries are added last (after existing > entries in the target datastore). The order these entries are provided > in XML instance documents (e.g. ) must be maintained by the > server. > In JSON the array order must be preserved. Are you sure draft-ietf-netmod-yang-json-00.txt says this? If not, make sure that Lada adds this as an open issue or an edit request. /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 Oct 10 14:37:46 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BED71AD433 for ; Fri, 10 Oct 2014 14:37:42 -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 mP3pzXGsgsIc for ; Fri, 10 Oct 2014 14:37:35 -0700 (PDT) Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CBE21A88B0 for ; Fri, 10 Oct 2014 14:37:35 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id s7so2208955qap.4 for ; Fri, 10 Oct 2014 14:37: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:content-type; bh=ZMIs2VjBi1A+m2CQWKEPzSeNLzFdEjgS8d41AW4vtMc=; b=W6js3hqkeBO8W+04APPUrx9vxXQRtVSZPw13iNK/WEM4BtnfG5mQ95HbQP7uBI9Gdh RuqrPlIfCa2sBNrTHZE6XYRnLKJpb09htI+AoQBy/FU4cpvglT9ypkabB+RhbntoZPIJ sqwtdm5h3oXotPkmeNsdPxbSbWYBdnnkXiaaDRXpfI4ZOrp0xkvHhSQKIL2M5OFjqa5h X/ObNaSlI9fxQCRlcWu7u2BxvdZ4zHpfhAK/+2/j64fjDdc54hoDvHcF1faG/mwP+zf5 +TYMUpBVbn81KUMG8ZEjwGVGZEse6RMKa3PWeI6GQvD3GoOhAFsb8ZwuPr+6MqeXyxYc Yqzg== X-Gm-Message-State: ALoCoQnlSeCXJIpzKaqKgtr+BDlEu864ehJUP4jxRB7UMHjdWwJqml/8S9rA7S38RnMzulUrYCT6 MIME-Version: 1.0 X-Received: by 10.224.28.68 with SMTP id l4mr13310972qac.16.1412977054487; Fri, 10 Oct 2014 14:37:34 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Fri, 10 Oct 2014 14:37:34 -0700 (PDT) In-Reply-To: <20141010213212.GC80385@elstar.local> References: <3E03501B-CA0B-433D-A18F-F77DD223EBE7@lucidvision.com> <2267A2CF-2103-47A9-99C8-E613017E252A@cisco.com> <2D34D6C8-4D51-44E0-8BF1-5EEC71059F6D@juniper.net> <0DA310C9-D8A7-4CF4-8AA1-5EC4CF95FE61@gmail.com> <20141010213212.GC80385@elstar.local> Date: Fri, 10 Oct 2014 14:37:34 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Ladislav Lhotka , NETMOD Working Group Content-Type: multipart/alternative; boundary=001a11c2c3ce68b0b20505185ba4 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/I8cMGD-MqkNf0bKUcRZyo5OU-Js Subject: Re: [netmod] Call for consensus to Accept ACL Model draft-bogdanovic-netmod-acl-model-02 as a WG draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 10 Oct 2014 21:37:42 -0000 --001a11c2c3ce68b0b20505185ba4 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 10, 2014 at 2:32 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Fri, Oct 10, 2014 at 11:59:46AM -0700, Andy Bierman wrote: > > > For a list that is ordered-by user, the order is totally up to the > client. > > By default, new user-ordered entries are added last (after existing > > entries in the target datastore). The order these entries are provided > > in XML instance documents (e.g. ) must be maintained by the > > server. > > In JSON the array order must be preserved. > > Are you sure draft-ietf-netmod-yang-json-00.txt says this? If not, > make sure that Lada adds this as an open issue or an edit request. > > I just checked sec 3.2.3 and 3.2.4. There is no mention of 'ordered-by user' for leaf-list or list statements. Lada, add as an open issue... /js > > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > --001a11c2c3ce68b0b20505185ba4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Fri, Oct 10, 2014 at 2:32 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Fri, Oct 10, 2014 at 11:59:46AM -0700, Andy Bierm= an wrote:

> For a list that is ordered-by user, the order is totally up to the cli= ent.
> By default, new user-ordered entries are added last (after existing > entries in the target datastore).=A0 The order these entries are provi= ded
> in XML instance documents (e.g. <edit-config>) must be maintaine= d by the
> server.
> In JSON the array order must be preserved.

Are you sure draft-ietf-netmod-yang-json-00.txt says this? If not,
make sure that Lada adds this as an open issue or an edit request.


I just checked sec 3.2.3 and 3.2.4.=A0
The= re is no mention of 'ordered-by user' for leaf-list or list stateme= nts.
Lada, add as an open issue...

/js


Andy
=A0
=
--
Juergen Schoenwaelder=A0 =A0 =A0 =A0 =A0 =A0Jacobs University Bremen gGmbH<= br> Phone: +49 421 200 3587=A0 =A0 =A0 =A0 =A0Campus Ring 1, 28759 Bremen, Germ= any
Fax:=A0 =A0+49 421 200 3103=A0 =A0 =A0 =A0 =A0<http://www.jacobs-university.de/&= gt;

--001a11c2c3ce68b0b20505185ba4-- From nobody Fri Oct 10 14:53:49 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 625A31AD44C for ; Fri, 10 Oct 2014 14:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmgF8f-anq41 for ; Fri, 10 Oct 2014 14:53:46 -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 902FE1AD44B for ; Fri, 10 Oct 2014 14:53: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 EA706F5C; Fri, 10 Oct 2014 23:53:44 +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 OcXJ2-dn3hn8; Fri, 10 Oct 2014 23:53: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; Fri, 10 Oct 2014 23:53:43 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id AA76F20036; Fri, 10 Oct 2014 23:53:43 +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 t1FyU_ICGqwg; Fri, 10 Oct 2014 23:53: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 658BE20035; Fri, 10 Oct 2014 23:53:42 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 18DAE2EEA324; Fri, 10 Oct 2014 23:53:41 +0200 (CEST) Date: Fri, 10 Oct 2014 23:53:41 +0200 From: Juergen Schoenwaelder To: "Alexander Clemm (alex)" Message-ID: <20141010215341.GD80385@elstar.local> Mail-Followup-To: "Alexander Clemm (alex)" , "Jan Medved (jmedved)" , Kent Watsen , "netmod@ietf.org" References: <20141010210934.GB80385@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Pz4S7pGathe0O7IyqPXeIkAswm8 Cc: "netmod@ietf.org" Subject: Re: [netmod] New revision of YANG mount draft 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, 10 Oct 2014 21:53:48 -0000 I still fail to see how all this falls out of RFC 6020. I see protocol discussion in draft-clemm-netmod-mount-02.txt (which is needed for what you want to do and likely even incomplete) but then the NETMOD WG is not about protocol work but about the data modeling language YANG and data models. In fact, my reading of the I-D is that you do not request to change anything in YANG at all - all you propose is to define a few extensions and a data model. Do you agree? Or where am I mis-understanding things? /js On Fri, Oct 10, 2014 at 09:21:29PM +0000, Alexander Clemm (alex) wrote: > What this refers to is the case of a hierarchy, where a system in a clien= t role accesseses another system in a server role (e.g. a controller) which= itself is a client to another server (e.g. a network device). One (straig= htforward) approach is to ignore the fact that the server (e.g. the control= ler) can be a client, and simply have it incorporate its own set of YANG mo= dels to represent the other devices below it. The downside is that this re= quires the controller to redefine and implement those models - they cannot = be simply reused as e.g. the "scope" is different, and the server has to ha= ve a semantic "understanding" of everything in the devices underneath it. T= his brings about the same situation that NMS has had for decades, that inte= grating new devices into an operational environment is held hostage by the = NMS, which first needs to support (and require corresponding development su= pport for) all those new parameters. In our case, we want to have the opti= on to simply incorporate "subtrees" from the device and make them accessibl= e to other applications by mounting them, without requiring further develop= ment (or requiring systems to "go around" the controller, which complicates= development of those other system and/or introduces other issues such as s= ynchronization). =20 > --- Alex >=20 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]= =20 > Sent: Friday, October 10, 2014 2:10 PM > To: Jan Medved (jmedved) > Cc: Kent Watsen; Alexander Clemm (alex); netmod@ietf.org > Subject: Re: [netmod] New revision of YANG mount draft >=20 > On Thu, Oct 09, 2014 at 09:59:31PM +0000, Jan Medved (jmedved) wrote: > >=20 > > Today, Yang does not allow a controller application to work directly=20 > > with device yang models. A controller has to re-define device models=20 > > into controller-specific models inside the controller and present the= =20 > > redefined models to applications. >=20 > How is this falling out of RFC 6020? >=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 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 Oct 10 14:56:27 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0C8F1A8849 for ; Fri, 10 Oct 2014 14:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.286 X-Spam-Level: X-Spam-Status: No, score=-15.286 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRm5yhFaZNb3 for ; Fri, 10 Oct 2014 14:56:23 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A92B11A8848 for ; Fri, 10 Oct 2014 14:56:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15478; q=dns/txt; s=iport; t=1412978182; x=1414187782; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=QJmd93MM6jOH4mVZ8BvoUjYPQV5b0ho5zB3hkaW12w0=; b=RQiBAPnqsikEHmx8b4rANuVrFSZX2OL10U9uHmkfGLhnshI0wi7DmN0e QpImDBs7Td9NDDPt6PL5bvy4AZo2D2rZoNj7CCEVjzhe0yaeOiFsM9AUf i+YqOfMlyGjZa/8NQTQCaLseiQqwgTdBFVZgBQiMypaClPQw8cjOzQxpK o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoFANBUOFStJV2Y/2dsb2JhbABggkhGU1gEyTaBYwEJhnlUAoEFFgF7hAMBAQEDAQEBARpRCwULAgEIEQMBAgEjBAcnCxQJCAIEDgWINggNv2ABAQEBAQEBAwEBAQEBAQEBAQEBF5AzDQQHhEsFkXmEQoJCgXyCUoEuESuDCpEdgXw4gUNsgUiBAgEBAQ X-IronPort-AV: E=Sophos; i="5.04,695,1406592000"; d="scan'208,217"; a="85939348" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-3.cisco.com with ESMTP; 10 Oct 2014 21:56:21 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s9ALuLQR018533 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 Oct 2014 21:56:21 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.175]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Fri, 10 Oct 2014 16:56:21 -0500 From: "Acee Lindem (acee)" To: Andy Bierman Thread-Topic: [netmod] Call for consensus to Accept ACL Model draft-bogdanovic-netmod-acl-model-02 as a WG draft Thread-Index: AQHP4wqZOFU3Ld8VA0GsywXxS1v2spwo3UyAgADJlQD//91FAIAATkwAgAAiR4A= Date: Fri, 10 Oct 2014 21:56:21 +0000 Message-ID: References: <3E03501B-CA0B-433D-A18F-F77DD223EBE7@lucidvision.com> <2267A2CF-2103-47A9-99C8-E613017E252A@cisco.com> <2D34D6C8-4D51-44E0-8BF1-5EEC71059F6D@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.84.182] Content-Type: multipart/alternative; boundary="_000_D05DCD964C4Daceeciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/-qZiHCRZLAmdL9xNwck1tQYSLz8 Cc: NETMOD Working Group Subject: Re: [netmod] Call for consensus to Accept ACL Model draft-bogdanovic-netmod-acl-model-02 as a WG draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 10 Oct 2014 21:56:25 -0000 --_000_D05DCD964C4Daceeciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable From: Andy Bierman > Date: Friday, October 10, 2014 at 11:53 AM To: Acee Lindem > Cc: Dean Bogdanovic >, NETMOD W= orking Group > Subject: Re: [netmod] Call for consensus to Accept ACL Model draft-bogdanov= ic-netmod-acl-model-02 as a WG draft On Fri, Oct 10, 2014 at 8:13 AM, Acee Lindem (acee) > wrote: Hi Dean, On 10/10/14, 9:17 AM, "Dean Bogdanovic" > wrote: > >On Oct 9, 2014, at 9:16 PM, Acee Lindem (acee) > wrote: > >> Authors, >> >> I have reviewed the document and have two rather fundamental comments >>that preclude me from supporting WG adoption. >> >> 1. I think you should change the rule-name (type string) to a >>sequence-number (type uint16 or int32). While using a string is >>ostensibly more flexible, network administrators have been using >>sequence numbers for over 30 years now and will be throughly >>disappointed when they discover that ACE =B310=B2 lexicographically prece= des >>ACE =B32=B2. This comment has broader significance than just access list= s >>since this model, if adopted and standardized, will set a precedent for >>future models. > >Well, this is something we posted on the mailing list to ask opinions. I=B9ll have to look in the archives. Was the rule-name string given support or simply no opposition? > Problem with the sequence number is that inserting new entries is a >problem if the space is exhausted between entries. The rule-name type >string is more flexible then a sequence number. Like I said, list based policies have used sequence numbers for over 30 years and this has not proved to be a serious problem. I don=B9t think we should change semantics with so little benefit when modeling existing constructs. For something completely new, these new ordering semantics could be explored. If I=B9m the only one who sees this as unwieldy, I=B9ll concede. I=B9ve auto-generated many configs with number based interface names or VRFs and been really annoyed at the sorted ordering. But this is YANG, not CLI. YANG has user-ordered lists so the keys do not have to be used to dictate an order (and should not be used). The keys can be used to describe the entry, so "9" and "10" are just labels. They sort correctly because the list is ordered-by user and the user knows that, and is expected to provide or insert entries in the desired ord= er. Okay =96 I missed this distinction but understand it now. Can we then add a= sequence-number to the model that an implementation knows how to order the= ACEs? Thanks, Acee Andy > >> 2. Please remove section 5 from the draft. This draft should not mix >>packet filtering and route filtering. Though we may get to this >>hierarchy, I believe that prefix-lists have much greater affinity with >>other routing policies than access-lists. Note that there is a separate >>route-filtering model in >>https://datatracker.ietf.org/doc/draft-zhdankin-netmod-bgp-cfg/. >>Finally, the RTGWG is now chartered for YANG models that are not >>specific to other Routing area working groups. The discussion of route >>filters belongs there or in IDR (since BGP has the most rigorous routing >>policy requirements). > >This is just an example how to add standard extensions. We needed a basic >example how to extend standard features and as you can see it is a bare >minimum. Maybe enforcing language that this is solely an example would >help? I didn=B9t notice that it was an example. I think this needs to be more clear - maybe even moved to an appendix. However, I=B9m happy as long as it is not normative. Thanks, Acee > >Dean > >> >> Also, a comparably minor comment, leaf-list targets requires a better >>definition. It really isn=B9t very useful without some guidance as to how >>an implementation=B9s targets should be represented. >> >> Thanks, >> Acee >> >> >> >> On Oct 8, 2014, at 11:14 AM, Thomas D. Nadeau > >>wrote: >> >>> >>> The co-authors of draft-bogdanovic-netmod-acl-model-02 have asked t= he >>>NETMOD chairs to post a call to adopt the draft as a WG document. >>> >>> The draft can be found here: >>> >>> http://tools.ietf.org/html/draft-bogdanovic-netmod-acl-model-02 >>> >>> The model itself has been extracted and can be directly accessed he= re >>>using git: >>> >>> >>> https://github.com/YangModels/yang/blob/master/experimental/ietf/AC= L-MO >>>DEL/ >>> >>> Please comment by the close of business on Monday, October 13, 2014= . >>> >>> >>> --Tom (As NETMOD 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 > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --_000_D05DCD964C4Daceeciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <61BD82016D43424BB50CA2957D0FDFDC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable


From: Andy Bierman <andy@yumaworks.com>
Date: Friday, October 10, 2014 at 1= 1:53 AM
To: Acee Lindem <acee@cisco.com>
Cc: Dean Bogdanovic <deanb@juniper.net>, NETMOD Working Group &= lt;netmod@ietf.org>
Subject: Re: [netmod] Call for cons= ensus to Accept ACL Model draft-bogdanovic-netmod-acl-model-02 as a WG draf= t



On Fri, Oct 10, 2014 at 8:13 AM, Acee Lindem (ac= ee) <acee@cisco.com&= gt; wrote:
Hi Dean,

On 10/10/14, 9:17 AM, "Dean Bogdanovic" <deanb@juniper.net> wrote:

>
>On Oct 9, 2014, at 9:16 PM, Acee Lindem (acee) <acee@cisco.com> wrote:
>
>> Authors,
>>
>> I have reviewed the document and have two rather fundamental comme= nts
>>that preclude me from supporting WG adoption.
>>
>>    1. I think you should change the rule-name (type stri= ng) to a
>>sequence-number (type uint16 or int32). While using a string is
>>ostensibly more flexible, network administrators have been using >>sequence numbers for over 30 years now and will be throughly
>>disappointed when they discover that ACE =B310=B2 lexicographically= precedes
>>ACE =B32=B2.  This comment has broader significance than just = access lists
>>since this model, if adopted and standardized, will set a precedent= for
>>future models.
>
>Well, this is something we posted on the mailing list to ask opinions.<= br>
I=B9ll have to look in the archives. Was the rule-name string given support=
or simply no opposition?

> Problem with the sequence number is that inserting new entries is a >problem if the space is exhausted between entries. The rule-name type >string is more flexible then a sequence number.

Like I said, list based policies have used sequence numbers for over 30
years and this has not proved to be a serious problem. I don=B9t think we should change semantics with so little benefit when modeling existing
constructs. For something completely new, these new ordering semantics
could be explored. If I=B9m the only one who sees this as unwieldy, I=B9ll<= br> concede. I=B9ve auto-generated many configs with number based interface
names or VRFs and been really annoyed at the sorted ordering.



But this is YANG, not CLI.
YANG has user-ordered lists so the keys do not have to be used
to dictate an order (and should not be used).  The keys can be
used to describe the entry, so "9" and "10" are ju= st labels.
They sort correctly because the list is ordered-by user and the user
knows that, and is expected to provide or insert entries in the desire= d order.

Okay =96 I missed this distinction but understand it now. Can we then = add a sequence-number to the model that an implementation knows how to orde= r the ACEs? 
Thanks,
Acee





Andy


 

>
>>    2. Please remove section 5 from the draft. This draft= should not mix
>>packet filtering and route filtering. Though we may get to this
>>hierarchy, I believe that prefix-lists have much greater affinity w= ith
>>other routing policies  than access-lists. Note that there is = a separate
>>route-filtering model in
>>https://datatracker.ietf.org/doc/draft-zhdankin-= netmod-bgp-cfg/.
>>Finally, the RTGWG is now chartered for YANG models that are not >>specific to other Routing area working groups. The discussion of ro= ute
>>filters belongs there or in IDR (since BGP has the most rigorous ro= uting
>>policy requirements).
>
>This is just an example how to add standard extensions. We needed a bas= ic
>example how to extend standard features and as you can see it is a bare=
>minimum.  Maybe enforcing language that this is solely an example = would
>help?

I didn=B9t notice that it was an example. I think this needs to be more
clear - maybe even moved to an appendix. However, I=B9m happy as long as it=
is not normative.

Thanks,
Acee


>
>Dean
>
>>
>> Also, a comparably minor comment, leaf-list targets requires a bet= ter
>>definition. It really isn=B9t very useful without some guidance as = to how
>>an implementation=B9s targets should be represented.
>>
>> Thanks,
>> Acee
>>
>>
>>
>> On Oct 8, 2014, at 11:14 AM, Thomas D. Nadeau <tnadeau@lucidvision.com>
>>wrote:
>>
>>>
>>>     The co-authors of draft-bogdanovic-netmod-a= cl-model-02 have asked the
>>>NETMOD chairs to post a call to adopt the draft as a WG documen= t.
>>>
>>>     The draft can be found here:
>>>
>>>     http://tools.ietf.org/ht= ml/draft-bogdanovic-netmod-acl-model-02
>>>
>>>     The model itself has been extracted and can= be directly accessed here
>>>using git:
>>>
>>>
>>>     https://github.c= om/YangModels/yang/blob/master/experimental/ietf/ACL-MO
>>>DEL/
>>>
>>>     Please comment by the close of business on = Monday, October 13, 2014.
>>>
>>>
>>>     --Tom (As NETMOD 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
>

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

 --_000_D05DCD964C4Daceeciscocom_-- From nobody Fri Oct 10 16:43:44 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0FD91A014F for ; Fri, 10 Oct 2014 16:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHWsdZsS6rw9 for ; Fri, 10 Oct 2014 16:43:41 -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 ED7531A0141 for ; Fri, 10 Oct 2014 16:43:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4274; q=dns/txt; s=iport; t=1412984621; x=1414194221; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+yTaGiOlMRu80jcWg/fzwmsNBH2+uLtOlnVSZnblLfU=; b=UOXvZ2SdGxVPn03yqRSRfB+10K0Zv1s3w6bSFrjqQ3sxLDOT+wJCJqo1 87fCzA2QdNeyGPuMvytNc7tpG38vK9bevMJ8ua4zMo6WxqWo+dALB5f1A g8K/6nlv/9XNJATEx8XDJu0qFnbJO0t4RcDbvXKFr2yUn5cS8S8rQGLVn 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAONtOFStJA2K/2dsb2JhbABdA4MOU1gEyyGHUQKBAxYBe4QDAQEBBDo/DAICAgEIDgIBBAEBAQoDEQkHGxcUCQgCBA4FCIg2wBABAQEBAQEBAQEBAQEBAQEBAQEBAQEXBJAPIRAHBguDHIEeBZF5jQCQZYN+g3dsgUiBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,695,1406592000"; d="scan'208";a="85970593" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-4.cisco.com with ESMTP; 10 Oct 2014 23:43:40 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s9ANhdMA012337 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 Oct 2014 23:43:40 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.163]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Fri, 10 Oct 2014 18:43:39 -0500 From: "Alexander Clemm (alex)" To: Juergen Schoenwaelder Thread-Topic: [netmod] New revision of YANG mount draft Thread-Index: AQHP40Rf8kMXz8u2QICzU6EjzD0qC5wopeSAgAGEYAD//6x3sIAAX9yA///IdYA= Date: Fri, 10 Oct 2014 23:43:38 +0000 Message-ID: References: <20141010210934.GB80385@elstar.local> <20141010215341.GD80385@elstar.local> In-Reply-To: <20141010215341.GD80385@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.204.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/hwME4YeWMYQ5aL4AB1Yb3RtVN-M Cc: "netmod@ietf.org" Subject: Re: [netmod] New revision of YANG mount draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 10 Oct 2014 23:43:42 -0000 Hi Juergen,=20 I am not sure with what you mean with "this falls out of RFC 6020"? =20 To your statement: "In fact, my reading of the I-D is that you do not reque= st to change anything in YANG at all - all you propose is to define a few e= xtensions and a data model." Yes, I agree; your understanding is correct. = The proposal we are making addresses the requirements within the existing = framework. =20 Regarding the "protocol portion", we are making the case that implementatio= n of this will be facilitated by having a push and/or pub/sub model for dat= a subtrees. This does not necessarily require actual protocol work (althou= gh such work could be defined) but can be addressed again within the existi= ng framework, using a subscription configuration model, notifications etc a= s outlined in the draft. =20 --- Alex -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Friday, October 10, 2014 2:54 PM To: Alexander Clemm (alex) Cc: Jan Medved (jmedved); Kent Watsen; netmod@ietf.org Subject: Re: [netmod] New revision of YANG mount draft I still fail to see how all this falls out of RFC 6020. I see protocol discussion in draft-clemm-netmod-mount-02.txt (which is need= ed for what you want to do and likely even incomplete) but then the NETMOD = WG is not about protocol work but about the data modeling language YANG and= data models. In fact, my reading of the I-D is that you do not request to = change anything in YANG at all - all you propose is to define a few extensi= ons and a data model. Do you agree? Or where am I mis-understanding things? /js On Fri, Oct 10, 2014 at 09:21:29PM +0000, Alexander Clemm (alex) wrote: > What this refers to is the case of a hierarchy, where a system in a clien= t role accesseses another system in a server role (e.g. a controller) which= itself is a client to another server (e.g. a network device). One (straig= htforward) approach is to ignore the fact that the server (e.g. the control= ler) can be a client, and simply have it incorporate its own set of YANG mo= dels to represent the other devices below it. The downside is that this re= quires the controller to redefine and implement those models - they cannot = be simply reused as e.g. the "scope" is different, and the server has to ha= ve a semantic "understanding" of everything in the devices underneath it. T= his brings about the same situation that NMS has had for decades, that inte= grating new devices into an operational environment is held hostage by the = NMS, which first needs to support (and require corresponding development su= pport for) all those new parameters. In our case, we want to have the opti= on to simply incorporate "subtrees" from the device and make them accessibl= e to other applications by mounting them, without requiring further develop= ment (or requiring systems to "go around" the controller, which complicates= development of those other system and/or introduces other issues such as s= ynchronization). =20 > --- Alex >=20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Friday, October 10, 2014 2:10 PM > To: Jan Medved (jmedved) > Cc: Kent Watsen; Alexander Clemm (alex); netmod@ietf.org > Subject: Re: [netmod] New revision of YANG mount draft >=20 > On Thu, Oct 09, 2014 at 09:59:31PM +0000, Jan Medved (jmedved) wrote: > >=20 > > Today, Yang does not allow a controller application to work directly=20 > > with device yang models. A controller has to re-define device models=20 > > into controller-specific models inside the controller and present=20 > > the redefined models to applications. >=20 > How is this falling out of RFC 6020? >=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 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Sat Oct 11 03:27:17 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E88F91A0290 for ; Sat, 11 Oct 2014 03:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmJDLa1IocFO for ; Sat, 11 Oct 2014 03:27:13 -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 E6A061A0275 for ; Sat, 11 Oct 2014 03:27: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 64912A8E; Sat, 11 Oct 2014 12:27: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 EirfmLqX5GqV; Sat, 11 Oct 2014 12:27: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; Sat, 11 Oct 2014 12:27:09 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 750F820036; Sat, 11 Oct 2014 12:27:09 +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 uXa7XaB5P7pv; Sat, 11 Oct 2014 12:27: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 CE5ED20035; Sat, 11 Oct 2014 12:27:07 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 08FBB2EEA698; Sat, 11 Oct 2014 12:27:06 +0200 (CEST) Date: Sat, 11 Oct 2014 12:27:06 +0200 From: Juergen Schoenwaelder To: "Alexander Clemm (alex)" Message-ID: <20141011102706.GA81740@elstar.local> Mail-Followup-To: "Alexander Clemm (alex)" , "Jan Medved (jmedved)" , Kent Watsen , "netmod@ietf.org" References: <20141010210934.GB80385@elstar.local> <20141010215341.GD80385@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/6MjmX1K4BFkkRW0krglISSEZrc4 Cc: "netmod@ietf.org" Subject: Re: [netmod] New revision of YANG mount draft 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: Sat, 11 Oct 2014 10:27:16 -0000 Alex, we seem to talk past each other, I am not sure why. You wrote something like this: > > > Today, Yang does not allow a controller application to work directly > > > with device yang models. A controller has to re-define device models > > > the redefined models to applications. So I am wondering what in RFC 6020 is leading to this statement. I did not find anything so I need your help to understand this. I am also getting confused when you say there is no protocol work needed, things can be done within the existing framework, but then you say there is a need for a push and/or pub/sub model for data subtrees (which is not there today). It helps me if you focus on clearly explaining what the technical details are you think should be standardized for your use case. There is lots of text why your use case is important but what I am looking for is a concise and clear description of the details that you think need to be standardized. Note that we so far have a setup in the IETF where one WG does protocol work and another takes care of the data modeling language and some core data models. I try to understand which pieces of concrete work you want to do so I can understand where things should be discussed. /js On Fri, Oct 10, 2014 at 11:43:38PM +0000, Alexander Clemm (alex) wrote: > Hi Juergen,=20 >=20 > I am not sure with what you mean with "this falls out of RFC 6020"? =20 >=20 > To your statement: "In fact, my reading of the I-D is that you do not req= uest to change anything in YANG at all - all you propose is to define a few= extensions and a data model." Yes, I agree; your understanding is correct= . The proposal we are making addresses the requirements within the existin= g framework. =20 >=20 > Regarding the "protocol portion", we are making the case that implementat= ion of this will be facilitated by having a push and/or pub/sub model for d= ata subtrees. This does not necessarily require actual protocol work (alth= ough such work could be defined) but can be addressed again within the exis= ting framework, using a subscription configuration model, notifications etc= as outlined in the draft. =20 >=20 > --- Alex >=20 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]= =20 > Sent: Friday, October 10, 2014 2:54 PM > To: Alexander Clemm (alex) > Cc: Jan Medved (jmedved); Kent Watsen; netmod@ietf.org > Subject: Re: [netmod] New revision of YANG mount draft >=20 > I still fail to see how all this falls out of RFC 6020. >=20 > I see protocol discussion in draft-clemm-netmod-mount-02.txt (which is ne= eded for what you want to do and likely even incomplete) but then the NETMO= D WG is not about protocol work but about the data modeling language YANG a= nd data models. In fact, my reading of the I-D is that you do not request t= o change anything in YANG at all - all you propose is to define a few exten= sions and a data model. >=20 > Do you agree? Or where am I mis-understanding things? >=20 > /js >=20 > On Fri, Oct 10, 2014 at 09:21:29PM +0000, Alexander Clemm (alex) wrote: > > What this refers to is the case of a hierarchy, where a system in a cli= ent role accesseses another system in a server role (e.g. a controller) whi= ch itself is a client to another server (e.g. a network device). One (stra= ightforward) approach is to ignore the fact that the server (e.g. the contr= oller) can be a client, and simply have it incorporate its own set of YANG = models to represent the other devices below it. The downside is that this = requires the controller to redefine and implement those models - they canno= t be simply reused as e.g. the "scope" is different, and the server has to = have a semantic "understanding" of everything in the devices underneath it.= This brings about the same situation that NMS has had for decades, that in= tegrating new devices into an operational environment is held hostage by th= e NMS, which first needs to support (and require corresponding development = support for) all those new parameters. In our case, we want to have the op= tion to simply incorporate "subtrees" from the device and make them accessi= ble to other applications by mounting them, without requiring further devel= opment (or requiring systems to "go around" the controller, which complicat= es development of those other system and/or introduces other issues such as= synchronization). =20 > > --- Alex > >=20 > > -----Original Message----- > > From: Juergen Schoenwaelder=20 > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Friday, October 10, 2014 2:10 PM > > To: Jan Medved (jmedved) > > Cc: Kent Watsen; Alexander Clemm (alex); netmod@ietf.org > > Subject: Re: [netmod] New revision of YANG mount draft > >=20 > > On Thu, Oct 09, 2014 at 09:59:31PM +0000, Jan Medved (jmedved) wrote: > > >=20 > > > Today, Yang does not allow a controller application to work directly= =20 > > > with device yang models. A controller has to re-define device models= =20 > > > into controller-specific models inside the controller and present=20 > > > the redefined models to applications. > >=20 > > How is this falling out of RFC 6020? > >=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 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 --=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 Sat Oct 11 08:37:54 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8831A6F47 for ; Sat, 11 Oct 2014 08:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.286 X-Spam-Level: X-Spam-Status: No, score=-15.286 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRfVT_L7gqHQ for ; Sat, 11 Oct 2014 08:37:51 -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 8312D1A1BCE for ; Sat, 11 Oct 2014 08:37:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3820; q=dns/txt; s=iport; t=1413041870; x=1414251470; h=message-id:date:from:mime-version:to:subject; bh=vifuGsYG2fwFg+nI5p3tW1V0qVbBDctKDgsz7x8Wun8=; b=SWConBCoEc49UAIU525fxdHyQt2nOFY/AQ8mawA7e98QBgXtwXm8NpRr PWoQHMd2MWFxtBk6dnP7VczV+1DsVYBTXMfh/W89cpPyrgPXxXVopxYQ7 yNGGLJQTYMzC7pKKjVwng0Xd8fsi3pMhqu4UEAvjAdCnpCMAh4xRdEfuq 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwFAKdOOVStJssW/2dsb2JhbABfAYNgWIhhwmeHTQKBGAF7hQIgHRYIEAMCAQIBNBcNBgIBAQWINQ2aJ6QoAQEIAQEBAR6QSoRMBZh9gXyCUoEuEYYnii2DfoN5Oy8BgkkBAQE X-IronPort-AV: E=Sophos;i="5.04,698,1406592000"; d="scan'208,217";a="206625412" 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; 11 Oct 2014 15:37:48 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s9BFbmng014382 for ; Sat, 11 Oct 2014 15:37:48 GMT Message-ID: <54394ECC.5080206@cisco.com> Date: Sat, 11 Oct 2014 17:37:48 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: NETMOD Working Group Content-Type: multipart/alternative; boundary="------------070207010409050904080801" Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/kRirQPk0DNOiAFo4ngQ_oPyA9Rg Subject: [netmod] YANG Advice and Editing Session at this coming IETF X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Oct 2014 15:37:52 -0000 This is a multi-part message in MIME format. --------------070207010409050904080801 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Like at the IETF 90 , we will be organizing a "YANG Advice and Editing Session" at this coming IETF meeting. *This is your chance *to get feedback from the YANG doctors in order to improve your YANG models. *Date and time*: Sunday, Nov9, 14:00-17:00 *Description*: At the IETF and in the industry in general, we observe a growing interest for configuration management with YANG modules. On Sunday afternoon, the YANG doctors will be available to provide advice on your YANG models. This session is not a tutorial on how to design YANG models and use NETCONF, but a place to get feedback on your data modeling questions, language usage questions, tools to use, etc... The afternoon will be dedicated to different time slots based on the number of requests and available YANG doctors. *Advanced participation notice* to bclaise@cisco.com and netmod-chairs@tools.ietf.org is welcomed. The details (basically this invite) will be posted soon under http://www.ietf.org/meeting/91/tutorials.html Tom Nadeau, NETMOD co-chair, might try to organize an extra ad-hoc session towards the end of the IETF week. Contact us (bclaise@cisco.com and netmod-chairs@tools.ietf.org ) if interested. Regards, Benoit --------------070207010409050904080801 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

Like at the IETF 90, we will be organizing a "YANG Advice and Editing Session" at this coming IETF meeting.

This is your chance to get feedback from the YANG doctors in order to improve your YANG models.

Date and time: Sunday, Nov9, 14:00-17:00

Description: At the IETF and in the industry in general, we observe a growing interest for configuration management with YANG modules. On Sunday afternoon, the YANG doctors will be available to provide advice on your YANG models. This session is not a tutorial on how to design YANG models and use NETCONF, but a place to get feedback on your data modeling questions, language usage questions, tools to use, etc...
The afternoon will be dedicated to different time slots based on the number of requests and available YANG doctors.

Advanced participation notice to bclaise@cisco.com and netmod-chairs@tools.ietf.org is welcomed.

The details (basically this invite) will be posted soon under http://www.ietf.org/meeting/91/tutorials.html

Tom Nadeau, NETMOD co-chair, might try to organize an extra ad-hoc session towards the end of the IETF week. Contact us (bclaise@cisco.com and netmod-chairs@tools.ietf.org) if interested.

Regards, Benoit
--------------070207010409050904080801-- From nobody Sat Oct 11 10:30:25 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97B961A6FC2 for ; Sat, 11 Oct 2014 10:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtRVWSrrBhek for ; Sat, 11 Oct 2014 10:30:17 -0700 (PDT) Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47EC01A6FBC for ; Sat, 11 Oct 2014 10:30:17 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id c9so3433772qcz.9 for ; Sat, 11 Oct 2014 10:30:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=NJsLb1+4YQ4WkuDBcdA2vkztovdi+7HY/jQoDzvbUbY=; b=KA9/IyipKp9YC+1B0XfgHfnPWDgOD5POT/bhstv4sIPA3gzg5EPrbrAifAa6c0YetT lBz45ZY8AeAbAJaTzDUtuEwad+K+aYt+NCorNIJZrDGVXyU0DZV5qb+oBY+5WGQB2TtA KXG0A7xIC5gkUuu4f1Ikc7MweW1o+5XSADTplg7IbAj4AWhi+oZx9f1+kdkN/MSNR0Pj VZfH3gPYPfSz2333Bn05Rdk/9arzRfzzOT9JQ5Kg0ibsSq244V0DGb6kYnsyp/6LO4Pd RjNNWltblJ68v81jqp5Yo7aLLml2/raMcHa/c89rfhgMXGzxRS6PrqwYQnkpJIEg3Pcx VZIA== X-Gm-Message-State: ALoCoQnV7Rr5lOofWGZfm5CGJ3ghu0aNXWE545MOZfqLykN/wkSD/WYDZbsi4OG1yhIwJGSvsPZc MIME-Version: 1.0 X-Received: by 10.224.20.9 with SMTP id d9mr21960506qab.7.1413048616369; Sat, 11 Oct 2014 10:30:16 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Sat, 11 Oct 2014 10:30:16 -0700 (PDT) In-Reply-To: <20141011102706.GA81740@elstar.local> References: <20141010210934.GB80385@elstar.local> <20141010215341.GD80385@elstar.local> <20141011102706.GA81740@elstar.local> Date: Sat, 11 Oct 2014 10:30:16 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , "Alexander Clemm (alex)" , "Jan Medved (jmedved)" , Kent Watsen , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11c1c560d45bd105052904ce Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/mz-DboB5g3PFIgXm4w7t5EJjQmU Subject: Re: [netmod] New revision of YANG mount draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Oct 2014 17:30:20 -0000 --001a11c1c560d45bd105052904ce Content-Type: text/plain; charset=ISO-8859-1 On Sat, Oct 11, 2014 at 3:27 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > Alex, > > we seem to talk past each other, I am not sure why. You wrote something > like this: > > > > > Today, Yang does not allow a controller application to work directly > > > > with device yang models. A controller has to re-define device models > > > > the redefined models to applications. > > So I am wondering what in RFC 6020 is leading to this statement. I did > not find anything so I need your help to understand this. I am also > getting confused when you say there is no protocol work needed, things > can be done within the existing framework, but then you say there is a > need for a push and/or pub/sub model for data subtrees (which is not > there today). > > It helps me if you focus on clearly explaining what the technical > details are you think should be standardized for your use case. There > is lots of text why your use case is important but what I am looking > for is a concise and clear description of the details that you think > need to be standardized. > > Note that we so far have a setup in the IETF where one WG does > protocol work and another takes care of the data modeling language and > some core data models. I try to understand which pieces of concrete > work you want to do so I can understand where things should be > discussed. > Perhaps we are disagreeing on the problem to solve, so we won't agree on the specific solutions that need to be chartered and standardized either. I do not agree with the premise that the network-level data models need to be the same as the device -level data models. A collection of data from several devices is just passed through to the client of the controller. This does not seem like network-level management to me. The controller can use NETCONF as its southbound protocol to the devices. It should decide what data to collect and what northbound data models to populate. I don't see why the devices need to be configured for this purpose. > /js > Andy > > On Fri, Oct 10, 2014 at 11:43:38PM +0000, Alexander Clemm (alex) wrote: > > Hi Juergen, > > > > I am not sure with what you mean with "this falls out of RFC 6020"? > > > > To your statement: "In fact, my reading of the I-D is that you do not > request to change anything in YANG at all - all you propose is to define a > few extensions and a data model." Yes, I agree; your understanding is > correct. The proposal we are making addresses the requirements within the > existing framework. > > > > Regarding the "protocol portion", we are making the case that > implementation of this will be facilitated by having a push and/or pub/sub > model for data subtrees. This does not necessarily require actual protocol > work (although such work could be defined) but can be addressed again > within the existing framework, using a subscription configuration model, > notifications etc as outlined in the draft. > > > > --- Alex > > > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de > ] > > Sent: Friday, October 10, 2014 2:54 PM > > To: Alexander Clemm (alex) > > Cc: Jan Medved (jmedved); Kent Watsen; netmod@ietf.org > > Subject: Re: [netmod] New revision of YANG mount draft > > > > I still fail to see how all this falls out of RFC 6020. > > > > I see protocol discussion in draft-clemm-netmod-mount-02.txt (which is > needed for what you want to do and likely even incomplete) but then the > NETMOD WG is not about protocol work but about the data modeling language > YANG and data models. In fact, my reading of the I-D is that you do not > request to change anything in YANG at all - all you propose is to define a > few extensions and a data model. > > > > Do you agree? Or where am I mis-understanding things? > > > > /js > > > > On Fri, Oct 10, 2014 at 09:21:29PM +0000, Alexander Clemm (alex) wrote: > > > What this refers to is the case of a hierarchy, where a system in a > client role accesseses another system in a server role (e.g. a controller) > which itself is a client to another server (e.g. a network device). One > (straightforward) approach is to ignore the fact that the server (e.g. the > controller) can be a client, and simply have it incorporate its own set of > YANG models to represent the other devices below it. The downside is that > this requires the controller to redefine and implement those models - they > cannot be simply reused as e.g. the "scope" is different, and the server > has to have a semantic "understanding" of everything in the devices > underneath it. This brings about the same situation that NMS has had for > decades, that integrating new devices into an operational environment is > held hostage by the NMS, which first needs to support (and require > corresponding development support for) all those new parameters. In our > case, we want to have the option to simply incorpor > ate "subtrees" from the device and make them accessible to other > applications by mounting them, without requiring further development (or > requiring systems to "go around" the controller, which complicates > development of those other system and/or introduces other issues such as > synchronization). > > > --- Alex > > > > > > -----Original Message----- > > > From: Juergen Schoenwaelder > > > [mailto:j.schoenwaelder@jacobs-university.de] > > > Sent: Friday, October 10, 2014 2:10 PM > > > To: Jan Medved (jmedved) > > > Cc: Kent Watsen; Alexander Clemm (alex); netmod@ietf.org > > > Subject: Re: [netmod] New revision of YANG mount draft > > > > > > On Thu, Oct 09, 2014 at 09:59:31PM +0000, Jan Medved (jmedved) wrote: > > > > > > > > Today, Yang does not allow a controller application to work directly > > > > with device yang models. A controller has to re-define device models > > > > into controller-specific models inside the controller and present > > > > the redefined models to applications. > > > > > > How is this falling out of RFC 6020? > > > > > > /js > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > > Fax: +49 421 200 3103 > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > -- > 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 > --001a11c1c560d45bd105052904ce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Sat, Oct 11, 2014 at 3:27 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
Alex,

we seem to talk past each other, I am not sure why. You wrote something
like this:

> > > Today, Yang does not allow a controller application to work = directly
> > > with device yang models. A controller has to re-define devic= e models
> > > the redefined models to applications.

So I am wondering what in RFC 6020 is leading to this statement. I did
not find anything so I need your help to understand this. I am also
getting confused when you say there is no protocol work needed, things
can be done within the existing framework, but then you say there is a
need for a push and/or pub/sub model for data subtrees (which is not
there today).

It helps me if you focus on clearly explaining what the technical
details are you think should be standardized for your use case. There
is lots of text why your use case is important but what I am looking
for is a concise and clear description of the details that you think
need to be standardized.

Note that we so far have a setup in the IETF where one WG does
protocol work and another takes care of the data modeling language and
some core data models. I try to understand which pieces of concrete
work you want to do so I can understand where things should be
discussed.

Perhaps we are disagreeing o= n the problem to solve, so we won't agree on the
specific sol= utions that need to be chartered and standardized either.

I do not agree with the premise that the network-level data models = need to be
the same as the device -level data models.=A0 A collec= tion of data from several
devices is just passed through to the c= lient of the controller. This does not
seem like network-level ma= nagement to me.

The controller can use NETCONF as = its southbound protocol to the devices.
It should decide what dat= a to collect and what northbound data models to populate.
I don&#= 39;t see why the devices need to be configured for this purpose.
=

/js

Andy
=A0

On Fri, Oct 10, 2014 at 11:43:38PM +0000, Alexander Clemm (alex) wrote:
> Hi Juergen,
>
> I am not sure with what you mean with "this falls out of RFC 6020= "?
>
> To your statement: "In fact, my reading of the I-D is that you do= not request to change anything in YANG at all - all you propose is to defi= ne a few extensions and a data model."=A0 Yes, I agree; your understan= ding is correct.=A0 The proposal we are making addresses the requirements w= ithin the existing framework.
>
> Regarding the "protocol portion", we are making the case tha= t implementation of this will be facilitated by having a push and/or pub/su= b model for data subtrees.=A0 This does not necessarily require actual prot= ocol work (although such work could be defined) but can be addressed again = within the existing framework, using a subscription configuration model, no= tifications etc as outlined in the draft.
>
> --- Alex
>
> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]
> Sent: Friday, October 10, 2014 2:54 PM
> To: Alexander Clemm (alex)
> Cc: Jan Medved (jmedved); Kent Watsen; netmod@ietf.org
> Subject: Re: [netmod] New revision of YANG mount draft
>
> I still fail to see how all this falls out of RFC 6020.
>
> I see protocol discussion in draft-clemm-netmod-mount-02.txt (which is= needed for what you want to do and likely even incomplete) but then the NE= TMOD WG is not about protocol work but about the data modeling language YAN= G and data models. In fact, my reading of the I-D is that you do not reques= t to change anything in YANG at all - all you propose is to define a few ex= tensions and a data model.
>
> Do you agree? Or where am I mis-understanding things?
>
> /js
>
> On Fri, Oct 10, 2014 at 09:21:29PM +0000, Alexander Clemm (alex) wrote= :
> > What this refers to is the case of a hierarchy, where a system in= a client role accesseses another system in a server role (e.g. a controlle= r) which itself is a client to another server (e.g. a network device).=A0 O= ne (straightforward) approach is to ignore the fact that the server (e.g. t= he controller) can be a client, and simply have it incorporate its own set = of YANG models to represent the other devices below it.=A0 The downside is = that this requires the controller to redefine and implement those models - = they cannot be simply reused as e.g. the "scope" is different, an= d the server has to have a semantic "understanding" of everything= in the devices underneath it. This brings about the same situation that NM= S has had for decades, that integrating new devices into an operational env= ironment is held hostage by the NMS, which first needs to support (and requ= ire corresponding development support for) all those new parameters.=A0 In = our case, we want to have the option to simply incorpor
=A0ate "subtrees" from the device and make them accessible to oth= er applications by mounting them, without requiring further development (or= requiring systems to "go around" the controller, which complicat= es development of those other system and/or introduces other issues such as= synchronization).
> > --- Alex
> >
> > -----Original Message-----
> > From: Juergen Schoenwaelder
> > [mailto:j= .schoenwaelder@jacobs-university.de]
> > Sent: Friday, October 10, 2014 2:10 PM
> > To: Jan Medved (jmedved)
> > Cc: Kent Watsen; Alexander Clemm (alex); netmod@ietf.org
> > Subject: Re: [netmod] New revision of YANG mount draft
> >
> > On Thu, Oct 09, 2014 at 09:59:31PM +0000, Jan Medved (jmedved) wr= ote:
> > >
> > > Today, Yang does not allow a controller application to work = directly
> > > with device yang models. A controller has to re-define devic= e models
> > > into controller-specific models inside the controller and pr= esent
> > > the redefined models to applications.
> >
> > How is this falling out of RFC 6020?
> >
> > /js
> >
> > --
> > Juergen Schoenwaelder=A0 =A0 =A0 =A0 =A0 =A0Jacobs University Bre= men gGmbH
> > Phone: +49 421 200 3587=A0 =A0 =A0 =A0 =A0Campus Ring 1, 28759 Br= emen, Germany
> > Fax:=A0 =A0+49 421 200 3103=A0 =A0 =A0 =A0 =A0<http://www.jacobs-universit= y.de/>
>
> --
> Juergen Schoenwaelder=A0 =A0 =A0 =A0 =A0 =A0Jacobs University Bremen g= GmbH
> Phone: +49 421 200 3587=A0 =A0 =A0 =A0 =A0Campus Ring 1, 28759 Bremen,= Germany
> Fax:=A0 =A0+49 421 200 3103=A0 =A0 =A0 =A0 =A0<http://www.jacobs-university.de/= >

--
Juergen Schoenwaelder=A0 =A0 =A0 =A0 =A0 =A0Jacobs University Bremen gGmbH<= br> Phone: +49 421 200 3587=A0 =A0 =A0 =A0 =A0Campus Ring 1, 28759 Bremen, Germ= any
Fax:=A0 =A0+49 421 200 3103=A0 =A0 =A0 =A0 =A0<http://www.jacobs-university.de/&= gt;

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

--001a11c1c560d45bd105052904ce-- From nobody Sat Oct 11 16:20:28 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43A891A1BC6 for ; Sat, 11 Oct 2014 16:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.964 X-Spam-Level: X-Spam-Status: No, score=0.964 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 MOh6n_Ef1_fu for ; Sat, 11 Oct 2014 16:20:24 -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 56A371A1A8E for ; Sat, 11 Oct 2014 16:20:23 -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 BKL30561; Sat, 11 Oct 2014 23:20:21 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 12 Oct 2014 00:20:20 +0100 Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.104]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Sun, 12 Oct 2014 07:20:02 +0800 From: Yangang To: "Lisa Huang (yihuan)" , "Dana Blair (dblair)" , "kkoushik@brocade.com" , "Dean Bogdanovic" , "Benoit Claise (bclaise)" Thread-Topic: Some comments about ACL YANG model. Thread-Index: Ac/kfG/69WbYy6R4S1u5RcAcGjY6pwAKxGAAAECN5S4= Date: Sat, 11 Oct 2014 23:20:02 +0000 Message-ID: References: , In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.22.247] Content-Type: multipart/alternative; boundary="_000_D496C972D1A13540A730720631EC73413A419D1Enkgeml507mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/bGRMEKy30GZNDBm41CwBfbY1_30 Cc: Zhengguangying , "netmod@ietf.org" , Lizhenbin Subject: [netmod] =?gb2312?b?tPC4tDogU29tZSBjb21tZW50cyBhYm91dCBBQ0wgWUFO?= =?gb2312?b?RyBtb2RlbC4=?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Oct 2014 23:20:26 -0000 --_000_D496C972D1A13540A730720631EC73413A419D1Enkgeml507mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IExpc2EgSHVhbmcg KHlpaHVhbikgW3lpaHVhbkBjaXNjby5jb21dDQq3osvNyrG85DogMjAxNMTqMTDUwjExyNUgMjoz MA0KytW8/sjLOiBZYW5nYW5nOyBEYW5hIEJsYWlyIChkYmxhaXIpOyBra291c2hpa0Bicm9jYWRl LmNvbTsgRGVhbiBCb2dkYW5vdmljOyBCZW5vaXQgQ2xhaXNlIChiY2xhaXNlKQ0Ks63LzTogbmV0 bW9kQGlldGYub3JnOyBaaGVuZ2d1YW5neWluZzsgTGl1YmluZyAoTGVvKTsgTGl6aGVuYmluDQrW 98ziOiBSZTogU29tZSBjb21tZW50cyBhYm91dCBBQ0wgWUFORyBtb2RlbC4NCg0KWWFuZ2dhbmcs IHRoYW5rcyBmb3IgeW91ciByZXZpZXcuIFJlc3BvbnNlIGluIGxpbmUuDQoNCkZyb206IFlhbmdh bmcgPHlhbmdhbmdAaHVhd2VpLmNvbTxtYWlsdG86eWFuZ2FuZ0BodWF3ZWkuY29tPj4NCkRhdGU6 IEZyaWRheSwgT2N0b2JlciAxMCwgMjAxNCA0OjIyIEFNDQpUbzogIkRhbmEgQmxhaXIgKGRibGFp cikiIDxkYmxhaXJAY2lzY28uY29tPG1haWx0bzpkYmxhaXJAY2lzY28uY29tPj4sIE1pY3Jvc29m dCBPZmZpY2UgVXNlciA8eWlodWFuQGNpc2NvLmNvbTxtYWlsdG86eWlodWFuQGNpc2NvLmNvbT4+ LCAia2tvdXNoaWtAYnJvY2FkZS5jb208bWFpbHRvOmtrb3VzaGlrQGJyb2NhZGUuY29tPiIgPGtr b3VzaGlrQGJyb2NhZGUuY29tPG1haWx0bzpra291c2hpa0Bicm9jYWRlLmNvbT4+LCBEZWFuIEJv Z2Rhbm92aWMgPGRlYW5iQGp1bmlwZXIubmV0PG1haWx0bzpkZWFuYkBqdW5pcGVyLm5ldD4+LCAi QmVub2l0IENsYWlzZSAoYmNsYWlzZSkiIDxiY2xhaXNlQGNpc2NvLmNvbTxtYWlsdG86YmNsYWlz ZUBjaXNjby5jb20+Pg0KQ2M6ICJuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9y Zz4iIDxuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4+LCBaaGVuZ2d1YW5n eWluZyA8emhlbmdndWFuZ3lpbmdAaHVhd2VpLmNvbTxtYWlsdG86emhlbmdndWFuZ3lpbmdAaHVh d2VpLmNvbT4+LCAiTGl1YmluZyAoTGVvKSIgPGxlby5saXViaW5nQGh1YXdlaS5jb208bWFpbHRv Omxlby5saXViaW5nQGh1YXdlaS5jb20+PiwgTGl6aGVuYmluIDxsaXpoZW5iaW5AaHVhd2VpLmNv bTxtYWlsdG86bGl6aGVuYmluQGh1YXdlaS5jb20+Pg0KU3ViamVjdDogU29tZSBjb21tZW50cyBh Ym91dCBBQ0wgWUFORyBtb2RlbC4NCg0KSGksDQoNCkkgYW0gcmV2aWV3aW5nIHRoZSBBQ0wgWUFO RyBtb2RlbC4gQW5kIEkgZ290IHNvbWUgZG91YnRzLCBtYXliZSBzb21lYm9keSBjYW4gaGVscCBt ZSB0byB1bmRlcnN0YW5kIGl0Lg0KDQoNCjEuICAgICAgVGhlcmUgaXMgb25lIGZpZWxkOiB0YXJn ZXRzLiBJbiBteSB1bmRlcnN0YW5kaW5nLCBtYXliZSBpdCBpcyB1c2VkIHRvIHJlY29yZCB3aG8g cmVmZXJlbmNlIHRoaXMgQUNMLiBJIGRvbqGvdCBrbm93IGlmIElzIGl0IG1hbmRhdG9yeSBvciBu b3QuIE9yIG15IHVuZGVyc3RhbmRpbmcgaXMgd3JvbmcuDQoNCg0KPHlpaHVhbj5MaXN0IG9mIHRh cmdldHMgd2hlcmUgQUNMIGlzIGFwcGxpZWQuIEl0IGlzIG9wdGlvbmFsLg0KDQoNCjIuICAgICAg SW4gcGFja2V0LWZpZWxkcyBtb2R1bGUsIEl0IGxvb2tzIHRoZSBjdXJyZW50IGRlZmluaXRpb24g aXMgbm90IHNvIHN1ZmZpY2llbnQuIEZvciBleGFtcGxlLCBubyAiIT0iIGRlZmluaXRpb24sDQoN Cjx5aWh1YW4+Q2FuIHlvdSBjbGFyaWZ5PyBEbyB5b3UgbWVhbiAhPSBmb3IgcG9ydCBzb3VyY2Ut cG9ydC1yYW5nZSBvciBkZXN0aW5hdGlvbi1wb3J0LXJhbmdlPyBUaGUgZHJhZnQgZG9lc24ndCBp bnRlbmQgdG8gY292ZXIgYWxsIGZpZWxkcyBpbiBhIHBhY2tldCBidXQgYWxsb3dzIHZlbmRvciB0 byBhdWdtZW50IHRoZSBtb2RlbCBhbmQgZXh0ZW5kIHRoZSBmZWF0dXJlcy4NCjxZYW5nYW5nPjog SSB1bmRlcnN0YW5kIHRoaXMgZHJhZnQgY2FuIG5vdCBjb3ZlciBhbGwgc2NlbmFyaW9zLiBCdXQg SSB0aGluayB0aGUgYmFzaWMgY2FwYWJpbGl0eSBtYXkgYmUgcHJvdmlkZWQgYXQgZmlyc3QsIGxp a2UgIj09IiwgIiE9IiwgYW5kIHRoaXMgcmFuZ2UuDQoNCmFuZCBubyBtYXNrIGluIGFjbC1pcHY0 LWhlYWRlci1maWVsZHMgZ3JvdXAsIGV0Y6GtLi4NCg0KPHlpaHVhbj4gRWFjaCBsZWFmIGluIGFj bC1pcHY0LWhlYWRlci1maWVsZHMgZ3JvdXAgaW5jbHVkZXMgcHJlZml4IGJlY2F1c2Ugb2YgaXRz IHR5cGUuIFdlIGNhbiBlbmhhbmNlIHRoZSBkZXNjcmlwdGlvbiBvciB0aGUgbGVhZiBuYW1lIHRv IGF2b2lkIGNvbmZ1c2lvbi4NCg0KbGVhZiBkZXN0aW5hdGlvbi1pcHY0LWFkZHJlc3Mgew0KDQog ICAgICAgICAgICB0eXBlIGluZXQ6aXB2NC1wcmVmaXg7DQogICAgICAgIH0NCg0KPFlhbmdhbmc+ OiBObyB1bmRlcnN0YW5kLCBob3cgdG8gc3VwcG9ydCB0aGUgd2lsZGNhcmQgbWFzayBpbiBwZXJm aXggbWF0Y2g/IGxpa2UgY29tbWFuZDogcnVsZSBbIHJ1bGUtaWQgXSB7IGRlbnkgfCBwZXJtaXQg fSBzb3VyY2UgeyBzb3VyY2UtaXAtYWRkcmVzcyBzb3VyY2Utd2lsZGNhcmQgfCBhbnkgfQ0KDQoN CjMuICAgICAgSW4gdGhpcyBkcmFmdCwgdGhlcmUgaXMgYWNsLXR5cGUgYW5kIGFjZS10eXBlLiBJ dCBsb29rcyB0aGUgSVAgcGFja2V0IG1hdGNoIGFuZCBFdGhlcm5ldCBwYWNrZXQgbWF0Y2ggY2Fu IGJlIGNvbmZpZ3VyZWQgdG9nZXRoZXIuIEJ1dCBpdCBsb29rcyBvbmx5ICJPUiIgcmVsYXRpb25z aGlwIGlzIGF0IHRoZXJlLCBubyAiQU5EIiByZWxhdGlvbnNoaXAuDQoNCg0KDQpUaGFua3MNCllh bmdhbmcNCg== --_000_D496C972D1A13540A730720631EC73413A419D1Enkgeml507mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

 

=B7=A2=BC=FE=C8=CB: Lisa Huang (yihuan) [yi= huan@cisco.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA10=D4=C211=C8=D5 2:30
=CA=D5=BC=FE=C8=CB: Yangang; Dana Blair (dblair); kkoushik@brocade.c= om; Dean Bogdanovic; Benoit Claise (bclaise)
=B3=AD=CB=CD: netmod@ietf.org; Zhengguangying; Liubing (Leo); Lizhen= bin
=D6=F7=CC=E2: Re: Some comments about ACL YANG model.

Yanggang, t= hanks for your review. Response in line.

From: Yangang <yangang@huawei.com>
Date: Friday, October 10, 2014 4:2= 2 AM
To: "Dana Blair (dblair)"= ; <dblair@cisco.co= m>, Microsoft Office User <yihuan@cisco.com>, "kkoushik@brocade.com" <kkoushik@bro= cade.com>, Dean Bogdanovic <deanb@juniper.net>, "Benoit Claise (bclaise)&= quot; <bclaise@ci= sco.com>
Cc: "netmod@ietf.org" <netmod@ietf.org>, Zhengguangyin= g <zhengg= uangying@huawei.com>, "Liubing (Leo)" <leo.liubing@huawei.com>, Lizhenbin <lizhenbin@huawei.com> Subject: Some comments about ACL Y= ANG model.

Hi, <= /span>

 

I am = reviewing the ACL YANG model. And I got some doubts, maybe somebody can hel= p me to understand it.

 

1.      There i= s one field: targets. In my understanding, maybe it is used to record who r= eference this ACL. I don=A1=AFt know if Is it mandatory or not. Or my under= standing is wrong.

 

 
<=
yihuan>List of targets where ACL is applied. It is optional.

2.      In pack= et-fields module, It looks the current definition is not so sufficient. For= example, no "!=3D" definition, 

 
<yihuan>Can you clarify? Do you mean != =3D for port source-port-range or destination-port-range? The draft doesn't intend to cover all fields in a packet but allows vendor= to augment the model and extend the features.
<Yangang>: I understand = this draft can not cover all scenarios. But I think the basic capability ma= y be provided at first, like "=3D=3D", "!=3D", and this range.

and no mask in acl-ipv4-hea= der-fields group, etc=A1=AD..

<yihuan> Each leaf in acl-ipv4-header-fields group includes= prefix because of its type. We can enhance the description or the leaf nam= e to avoid confusion.

leaf = destination-ipv4-address {
            type ine=
t:ipv4-prefix;
        }
<Yangang= >: No understand, how to support the wildcard mask in perfix match? like= command: rule [ rule-id ] { deny | permit } source { source-ip-address source-wildcard | any }

<= span style=3D"FONT-SIZE: 12pt" lang=3D"EN-US">3.      In this= draft, there is acl-type and ace-type. It looks the IP packet match and Et= hernet packet match can be configured together. But it looks only "OR&= quot; relationship is at there, no "AND" relationship.


<= span style=3D"FONT-SIZE: 12pt" lang=3D"EN-US">

 

Thank= s

Yanga= ng

--_000_D496C972D1A13540A730720631EC73413A419D1Enkgeml507mbschi_-- From nobody Sat Oct 11 16:36:37 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6F01A6F5A for ; Sat, 11 Oct 2014 16:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.964 X-Spam-Level: X-Spam-Status: No, score=0.964 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 jak3N49NTnEK for ; Sat, 11 Oct 2014 16:36:31 -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 6BE271A6F01 for ; Sat, 11 Oct 2014 16:36:30 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNN79732; Sat, 11 Oct 2014 23:36:28 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 12 Oct 2014 00:36:27 +0100 Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.104]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Sun, 12 Oct 2014 07:36:15 +0800 From: Yangang To: Reinaldo Penno , "Lisa Huang (yihuan)" , "Dana Blair (dblair)" , "kkoushik@brocade.com" , Dean Bogdanovic , "Benoit Claise (bclaise)" Thread-Topic: [netmod] Some comments about ACL YANG model. Thread-Index: AQHP5Lzn5AAcTi0Pa0mvIq3tgyteJJwrimcV Date: Sat, 11 Oct 2014 23:36:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.22.247] Content-Type: multipart/alternative; boundary="_000_D496C972D1A13540A730720631EC73413A419D2Cnkgeml507mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/xeGa4qxkUD2riM4PA7K4y7xLC1Q Cc: Zhengguangying , Lizhenbin , "netmod@ietf.org" Subject: [netmod] =?gb2312?b?tPC4tDogIFNvbWUgY29tbWVudHMgYWJvdXQgQUNMIFlB?= =?gb2312?b?TkcgbW9kZWwu?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Oct 2014 23:36:34 -0000 --_000_D496C972D1A13540A730720631EC73413A419D2Cnkgeml507mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksDQoNCg0KDQpZZXMsIEkgYWdyZWUuIFJpZ2h0IG5vdywgbWF5YmUgdGhlIHF1ZXN0aW9uIGlz IGhvdyB0byBkZWZpbmUgdGhlIHNtYWxsZXN0IGZ1bmN0aW9uIHNldC4NCg0KDQoNCklmIHRoaXMg cmFuZ2UgaXMgdG9vIGJpZywgc29tZSB2ZXJkZXJzIGNhbiBub3Qgc3VwcG9ydCBhbGwgZnVuY3Rp b25zLCBldmVuIGN1cnJlbnQgZGVmaW5lLCB0aGUgSVBWNCBhbmQgSVBWNiwgZXZlbiBldGhlcm5l dCBoZWFkZXIgbWF0Y2gsIGNhbiBiZSBjb25maWd1cmVkIGluIG9uZSBBQ0wsIGJ1dCBzb21lIHZl bmRvciBqdXN0IHN1cHBvcnQgSVBWNCBBQ0wsIElQVjYgQUNMLCBhbmQgTDIgQUNMLiBJdCBoYXZl IHJlbGF0aW9uIHdpdGggcGVyZm9ybWFuY2UgYW5kIGhhcmR3YXJlLg0KDQoNCg0KQnV0IGlmIHRo aXMgYmFzaWMgZnVuY3Rpb2luIGlzIHRvbyBzbWFsbC4gRm9yIE5NUywgdGhlcmUgaXMgbm8gZGlm ZmVyZW5jZSBiZXR3ZWVuICJpbnRlZ3JhdGlvbiB3aXRoIHByaXZhdGUgZXh0ZW5zaW9uIiBhbmQg ImludGVncmF0aW9uIHdpdGggcHJpdmF0ZSBkZWZpbml0aW9uIi4NCg0KDQoNCkkganVzdCBqb2lu IHRoaXMgZGlzY3Vzc2lvbiByZWNlbnRseSwgbWF5YmUgc29tZXRoaW5nIGFscmVhZHkgaXMgZGlz Y3Vzc2VkLg0KDQoNCg0KWWFuZ2FuZy4NCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQq3orz+yMs6IFJlaW5hbGRvIFBlbm5vIFtyYXBlbm5vQGdtYWlsLmNvbV0NCreiy83K sbzkOiAyMDE0xOoxMNTCMTHI1SAzOjAzDQrK1bz+yMs6IExpc2EgSHVhbmcgKHlpaHVhbik7IFlh bmdhbmc7IERhbmEgQmxhaXIgKGRibGFpcik7IGtrb3VzaGlrQGJyb2NhZGUuY29tOyBEZWFuIEJv Z2Rhbm92aWM7IEJlbm9pdCBDbGFpc2UgKGJjbGFpc2UpDQqzrcvNOiBaaGVuZ2d1YW5neWluZzsg bmV0bW9kQGlldGYub3JnOyBMaXpoZW5iaW4NCtb3zOI6IFJlOiBbbmV0bW9kXSBTb21lIGNvbW1l bnRzIGFib3V0IEFDTCBZQU5HIG1vZGVsLg0KDQpNeSBzdWdnZXN0aW9uIHdvdWxkIGJlIHRvIGtl ZXAgQUNMIGRyYWZ0IGFzIGFuIGludGVyc2VjdGlvbiBvZiBBQ0wgZmVhdHVyZXMgZm91bmQgaW4g dmVuZG9yIGVxdWlwbWVudCBhcyBvcHBvc2VkIHRvIHVuaW9uLiBLZWVwIGl0IHRpZ2h0IGFuZCBz bWFsbC4gT25lIG9mIHRoZSBwcm9ibGVtcyBvZiB0aGUgcHJldmlvdXMgQUNMIGRyYWZ0IGlzIHRo YXQgaXQgdHJpZWQgdG8gY292ZXIgZXZlcnkgc2luZ2xlIHBvc3NpYmxlIGZlYXR1cmUuICBGb2xr cyBjYW4gYWx3YXlzIGF1Z21lbnQgQUNMIGRvY3VtZW50IHdpdGggYWxsIGtpbmRzIG9mIGZlYXR1 cmVzIHRoZXkgbmVlZC4NCg0KDQoNCkZyb206ICJMaXNhIEh1YW5nICh5aWh1YW4pIiA8eWlodWFu QGNpc2NvLmNvbTxtYWlsdG86eWlodWFuQGNpc2NvLmNvbT4+DQpEYXRlOiBGcmlkYXksIE9jdG9i ZXIgMTAsIDIwMTQgYXQgMTE6MzAgQU0NClRvOiBZYW5nYW5nIDx5YW5nYW5nQGh1YXdlaS5jb208 bWFpbHRvOnlhbmdhbmdAaHVhd2VpLmNvbT4+LCAiRGFuYSBCbGFpciAoZGJsYWlyKSIgPGRibGFp ckBjaXNjby5jb208bWFpbHRvOmRibGFpckBjaXNjby5jb20+PiwgImtrb3VzaGlrQGJyb2NhZGUu Y29tPG1haWx0bzpra291c2hpa0Bicm9jYWRlLmNvbT4iIDxra291c2hpa0Bicm9jYWRlLmNvbTxt YWlsdG86a2tvdXNoaWtAYnJvY2FkZS5jb20+PiwgRGVhbiBCb2dkYW5vdmljIDxkZWFuYkBqdW5p cGVyLm5ldDxtYWlsdG86ZGVhbmJAanVuaXBlci5uZXQ+PiwgIkJlbm9pdCBDbGFpc2UgKGJjbGFp c2UpIiA8YmNsYWlzZUBjaXNjby5jb208bWFpbHRvOmJjbGFpc2VAY2lzY28uY29tPj4NCkNjOiBa aGVuZ2d1YW5neWluZyA8emhlbmdndWFuZ3lpbmdAaHVhd2VpLmNvbTxtYWlsdG86emhlbmdndWFu Z3lpbmdAaHVhd2VpLmNvbT4+LCAibmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5v cmc+IiA8bmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+PiwgTGl6aGVuYmlu IDxsaXpoZW5iaW5AaHVhd2VpLmNvbTxtYWlsdG86bGl6aGVuYmluQGh1YXdlaS5jb20+Pg0KU3Vi amVjdDogUmU6IFtuZXRtb2RdIFNvbWUgY29tbWVudHMgYWJvdXQgQUNMIFlBTkcgbW9kZWwuDQoN CllhbmdnYW5nLCB0aGFua3MgZm9yIHlvdXIgcmV2aWV3LiBSZXNwb25zZSBpbiBsaW5lLg0KDQpG cm9tOiBZYW5nYW5nIDx5YW5nYW5nQGh1YXdlaS5jb208bWFpbHRvOnlhbmdhbmdAaHVhd2VpLmNv bT4+DQpEYXRlOiBGcmlkYXksIE9jdG9iZXIgMTAsIDIwMTQgNDoyMiBBTQ0KVG86ICJEYW5hIEJs YWlyIChkYmxhaXIpIiA8ZGJsYWlyQGNpc2NvLmNvbTxtYWlsdG86ZGJsYWlyQGNpc2NvLmNvbT4+ LCBNaWNyb3NvZnQgT2ZmaWNlIFVzZXIgPHlpaHVhbkBjaXNjby5jb208bWFpbHRvOnlpaHVhbkBj aXNjby5jb20+PiwgImtrb3VzaGlrQGJyb2NhZGUuY29tPG1haWx0bzpra291c2hpa0Bicm9jYWRl LmNvbT4iIDxra291c2hpa0Bicm9jYWRlLmNvbTxtYWlsdG86a2tvdXNoaWtAYnJvY2FkZS5jb20+ PiwgRGVhbiBCb2dkYW5vdmljIDxkZWFuYkBqdW5pcGVyLm5ldDxtYWlsdG86ZGVhbmJAanVuaXBl ci5uZXQ+PiwgIkJlbm9pdCBDbGFpc2UgKGJjbGFpc2UpIiA8YmNsYWlzZUBjaXNjby5jb208bWFp bHRvOmJjbGFpc2VAY2lzY28uY29tPj4NCkNjOiAibmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRt b2RAaWV0Zi5vcmc+IiA8bmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+Piwg WmhlbmdndWFuZ3lpbmcgPHpoZW5nZ3Vhbmd5aW5nQGh1YXdlaS5jb208bWFpbHRvOnpoZW5nZ3Vh bmd5aW5nQGh1YXdlaS5jb20+PiwgIkxpdWJpbmcgKExlbykiIDxsZW8ubGl1YmluZ0BodWF3ZWku Y29tPG1haWx0bzpsZW8ubGl1YmluZ0BodWF3ZWkuY29tPj4sIExpemhlbmJpbiA8bGl6aGVuYmlu QGh1YXdlaS5jb208bWFpbHRvOmxpemhlbmJpbkBodWF3ZWkuY29tPj4NClN1YmplY3Q6IFNvbWUg Y29tbWVudHMgYWJvdXQgQUNMIFlBTkcgbW9kZWwuDQoNCkhpLA0KDQpJIGFtIHJldmlld2luZyB0 aGUgQUNMIFlBTkcgbW9kZWwuIEFuZCBJIGdvdCBzb21lIGRvdWJ0cywgbWF5YmUgc29tZWJvZHkg Y2FuIGhlbHAgbWUgdG8gdW5kZXJzdGFuZCBpdC4NCg0KDQoxLiAgICAgIFRoZXJlIGlzIG9uZSBm aWVsZDogdGFyZ2V0cy4gSW4gbXkgdW5kZXJzdGFuZGluZywgbWF5YmUgaXQgaXMgdXNlZCB0byBy ZWNvcmQgd2hvIHJlZmVyZW5jZSB0aGlzIEFDTC4gSSBkb26hr3Qga25vdyBpZiBJcyBpdCBtYW5k YXRvcnkgb3Igbm90LiBPciBteSB1bmRlcnN0YW5kaW5nIGlzIHdyb25nLg0KDQoNCjx5aWh1YW4+ TGlzdCBvZiB0YXJnZXRzIHdoZXJlIEFDTCBpcyBhcHBsaWVkLiBJdCBpcyBvcHRpb25hbC4NCg0K DQoyLiAgICAgIEluIHBhY2tldC1maWVsZHMgbW9kdWxlLCBJdCBsb29rcyB0aGUgY3VycmVudCBk ZWZpbml0aW9uIGlzIG5vdCBzbyBzdWZmaWNpZW50LiBGb3IgZXhhbXBsZSwgbm8gIiE9IiBkZWZp bml0aW9uLA0KDQo8eWlodWFuPkNhbiB5b3UgY2xhcmlmeT8gRG8geW91IG1lYW4gIT0gZm9yIHBv cnQgc291cmNlLXBvcnQtcmFuZ2Ugb3IgZGVzdGluYXRpb24tcG9ydC1yYW5nZT8gVGhlIGRyYWZ0 IGRvZXNuJ3QgaW50ZW5kIHRvIGNvdmVyIGFsbCBmaWVsZHMgaW4gYSBwYWNrZXQgYnV0IGFsbG93 cyB2ZW5kb3IgdG8gYXVnbWVudCB0aGUgbW9kZWwgYW5kIGV4dGVuZCB0aGUgZmVhdHVyZXMuDQoN CmFuZCBubyBtYXNrIGluIGFjbC1pcHY0LWhlYWRlci1maWVsZHMgZ3JvdXAsIGV0Y6GtLi4NCg0K PHlpaHVhbj4gRWFjaCBsZWFmIGluIGFjbC1pcHY0LWhlYWRlci1maWVsZHMgZ3JvdXAgaW5jbHVk ZXMgcHJlZml4IGJlY2F1c2Ugb2YgaXRzIHR5cGUuIFdlIGNhbiBlbmhhbmNlIHRoZSBkZXNjcmlw dGlvbiBvciB0aGUgbGVhZiBuYW1lIHRvIGF2b2lkIGNvbmZ1c2lvbi4NCg0KbGVhZiBkZXN0aW5h dGlvbi1pcHY0LWFkZHJlc3Mgew0KDQogICAgICAgICAgICB0eXBlIGluZXQ6aXB2NC1wcmVmaXg7 DQogICAgICAgIH0NCg0KDQozLiAgICAgIEluIHRoaXMgZHJhZnQsIHRoZXJlIGlzIGFjbC10eXBl IGFuZCBhY2UtdHlwZS4gSXQgbG9va3MgdGhlIElQIHBhY2tldCBtYXRjaCBhbmQgRXRoZXJuZXQg cGFja2V0IG1hdGNoIGNhbiBiZSBjb25maWd1cmVkIHRvZ2V0aGVyLiBCdXQgaXQgbG9va3Mgb25s eSAiT1IiIHJlbGF0aW9uc2hpcCBpcyBhdCB0aGVyZSwgbm8gIkFORCIgcmVsYXRpb25zaGlwLg0K DQoNCg0KVGhhbmtzDQpZYW5nYW5nDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXyBuZXRtb2QgbWFpbGluZyBsaXN0IG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86 bmV0bW9kQGlldGYub3JnPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l dG1vZA0K --_000_D496C972D1A13540A730720631EC73413A419D2Cnkgeml507mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi,

 

Yes, I agree. Right now, maybe the question is how to define the smalles= t function set. 

 

If this range is too big, some verders can not support all fun= ctions, even current define, the IPV4 and IPV6, even ethernet hea= der match, can be configured in one ACL, but some vendor just support IPV4&= nbsp;ACL, IPV6 ACL, and L2 ACL. It have relation with p= erformance and hardware.

 

But if this basic functioin is too small. For NMS, there = is no difference between "integration with private extension"= ; and "integration with private definition".

 

I just join this discussion recently, maybe something already is discuss= ed.

 

Yangang.  

 

=B7=A2=BC=FE=C8=CB: Reinaldo Penno [rapenn= o@gmail.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA10=D4=C211=C8=D5 3:03
=CA=D5=BC=FE=C8=CB: Lisa Huang (yihuan); Yangang; Dana Blair (dblair= ); kkoushik@brocade.com; Dean Bogdanovic; Benoit Claise (bclaise)
=B3=AD=CB=CD: Zhengguangying; netmod@ietf.org; Lizhenbin
=D6=F7=CC=E2: Re: [netmod] Some comments about ACL YANG model.

My suggestion would be to keep ACL draft as an intersection of ACL fea= tures found in vendor equipment as opposed to union. Keep it tight and smal= l. One of the problems of the previous ACL draft is that it tried to cover = every single possible feature.  Folks can always augment ACL document with all kinds of features they need. = ;



From: "Lisa Huang (yihuan)&qu= ot; <yihuan@cisco.= com>
Date: Friday, October 10, 2014 at = 11:30 AM
To: Yangang <yangang@huawei.com>, "Dan= a Blair (dblair)" <dblair@cisco.com>, "kkoushik@brocade.com" <kkoushik@bro= cade.com>, Dean Bogdanovic <deanb@juniper.net>, "Benoit Claise (bclaise)&= quot; <bclaise@ci= sco.com>
Cc: Zhengguangying <zhengguangying@huawei.c= om>, "netm= od@ietf.org" <netmod@ietf.org>, Lizhenbin <li= zhenbin@huawei.com>
Subject: Re: [netmod] Some comment= s about ACL YANG model.

Yanggang, t= hanks for your review. Response in line.

From: Yangang <yangang@huawei.com>
Date: Friday, October 10, 2014 4:2= 2 AM
To: "Dana Blair (dblair)"= ; <dblair@cisco.co= m>, Microsoft Office User <yihuan@cisco.com>, "kkoushik@brocade.com" <kkoushik@bro= cade.com>, Dean Bogdanovic <deanb@juniper.net>, "Benoit Claise (bclaise)&= quot; <bclaise@ci= sco.com>
Cc: "netmod@ietf.org" <netmod@ietf.org>, Zhengguangyin= g <zhengg= uangying@huawei.com>, "Liubing (Leo)" <leo.liubing@huawei.com>, Lizhenbin <lizhenbin@huawei.com> Subject: Some comments about ACL Y= ANG model.

Hi, <= /span>

 

I am = reviewing the ACL YANG model. And I got some doubts, maybe somebody can hel= p me to understand it.

 

1.      There i= s one field: targets. In my understanding, maybe it is used to record who r= eference this ACL. I don=A1=AFt know if Is it mandatory or not. Or my under= standing is wrong.

 

 
<=
yihuan>List of targets where ACL is applied. It is optional.

2.      In pack= et-fields module, It looks the current definition is not so sufficient. For= example, no "!=3D" definition, 

 
<yihuan>Can you clarify? Do you mean != =3D for port source-port-range or destination-port-range? The draft doesn't intend to cover all fields in a packet but allows vendor= to augment the model and extend the features.

and no mask in acl-ipv4-hea= der-fields group, etc=A1=AD..

<yihuan> Each leaf in acl-ipv4-header-fields group includes= prefix because of its type. We can enhance the description or the leaf nam= e to avoid confusion.

leaf = destination-ipv4-address {
            type ine=
t:ipv4-prefix;
        }

<= span style=3D"FONT-SIZE: 12pt" lang=3D"EN-US">3.      In this= draft, there is acl-type and ace-type. It looks the IP packet match and Et= hernet packet match can be configured together. But it looks only "OR&= quot; relationship is at there, no "AND" relationship.


<= span style=3D"FONT-SIZE: 12pt" lang=3D"EN-US">

 

Thank= s

Yanga= ng

_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
--_000_D496C972D1A13540A730720631EC73413A419D2Cnkgeml507mbschi_-- From nobody Sat Oct 11 22:22:41 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1A781A8885 for ; Sat, 11 Oct 2014 22:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 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, RP_MATCHES_RCVD=-0.786, 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 6PX5P0sHlV10 for ; Sat, 11 Oct 2014 22:22:31 -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 072131A886A for ; Sat, 11 Oct 2014 22:22:30 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKL43632; Sun, 12 Oct 2014 05:22:29 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 12 Oct 2014 06:22:27 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.21]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Sun, 12 Oct 2014 13:22:20 +0800 From: Qin Wu To: "Alexander Clemm (alex)" , Juergen Schoenwaelder , "Jan Medved (jmedved)" Thread-Topic: [netmod] New revision of YANG mount draft Thread-Index: AQHP40RfcXk3qRma8kec20irC7AonJwoMIcAgAEfzwCAAANUgIACcN1w Date: Sun, 12 Oct 2014 05:22:19 +0000 Message-ID: References: <20141010210934.GB80385@elstar.local> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.12.236] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/T3C6UltqvISwz8cQM7K6e6p2BLE Cc: "netmod@ietf.org" Subject: Re: [netmod] New revision of YANG mount draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 12 Oct 2014 05:22:35 -0000 LS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2Vz QGlldGYub3JnXSC0+rHtIEFsZXhhbmRlciBDbGVtbSAoYWxleCkNCreiy83KsbzkOiAyMDE0xOox MNTCMTHI1SA1OjIxDQrK1bz+yMs6IEp1ZXJnZW4gU2Nob2Vud2FlbGRlcjsgSmFuIE1lZHZlZCAo am1lZHZlZCkNCrOty806IG5ldG1vZEBpZXRmLm9yZw0K1vfM4jogUmU6IFtuZXRtb2RdIE5ldyBy ZXZpc2lvbiBvZiBZQU5HIG1vdW50IGRyYWZ0DQoNCldoYXQgdGhpcyByZWZlcnMgdG8gaXMgdGhl IGNhc2Ugb2YgYSBoaWVyYXJjaHksIHdoZXJlIGEgc3lzdGVtIGluIGEgY2xpZW50IHJvbGUgYWNj ZXNzZXNlcyBhbm90aGVyIHN5c3RlbSBpbiBhIHNlcnZlciByb2xlIChlLmcuIGEgY29udHJvbGxl cikgd2hpY2ggaXRzZWxmIGlzIGEgY2xpZW50IHRvIGFub3RoZXIgc2VydmVyIChlLmcuIGEgbmV0 d29yayBkZXZpY2UpLiAgT25lIChzdHJhaWdodGZvcndhcmQpIGFwcHJvYWNoIGlzIHRvIGlnbm9y ZSB0aGUgZmFjdCB0aGF0IHRoZSBzZXJ2ZXIgKGUuZy4gdGhlIGNvbnRyb2xsZXIpIGNhbiBiZSBh IGNsaWVudCwgYW5kIHNpbXBseSBoYXZlIGl0IGluY29ycG9yYXRlIGl0cyBvd24gc2V0IG9mIFlB TkcgbW9kZWxzIHRvIHJlcHJlc2VudCB0aGUgb3RoZXIgZGV2aWNlcyBiZWxvdyBpdC4gIFRoZSBk b3duc2lkZSBpcyB0aGF0IHRoaXMgcmVxdWlyZXMgdGhlIGNvbnRyb2xsZXIgdG8gcmVkZWZpbmUg YW5kIGltcGxlbWVudCB0aG9zZSBtb2RlbHMgLSB0aGV5IGNhbm5vdCBiZSBzaW1wbHkgcmV1c2Vk IGFzIGUuZy4gdGhlICJzY29wZSIgaXMgZGlmZmVyZW50LCBhbmQgdGhlIHNlcnZlciBoYXMgdG8g aGF2ZSBhIHNlbWFudGljICJ1bmRlcnN0YW5kaW5nIiBvZiBldmVyeXRoaW5nIGluIHRoZSBkZXZp Y2VzIHVuZGVybmVhdGggaXQuIFRoaXMgYnJpbmdzIGFib3V0IHRoZSBzYW1lIHNpdHVhdGlvbiB0 aGF0IE5NUyBoYXMgaGFkIGZvciBkZWNhZGVzLCB0aGF0IGludGVncmF0aW5nIG5ldyBkZXZpY2Vz IGludG8gYW4gb3BlcmF0aW9uYWwgZW52aXJvbm1lbnQgaXMgaGVsZCBob3N0YWdlIGJ5IHRoZSBO TVMsIHdoaWNoIGZpcnN0IG5lZWRzIHRvIHN1cHBvcnQgKGFuZCByZXF1aXJlIGNvcnJlc3BvbmRp bmcgZGV2ZWxvcG1lbnQgc3VwcG9ydCBmb3IpIGFsbCB0aG9zZSBuZXcgcGFyYW1ldGVycy4gIElu IG91ciBjYXNlLCB3ZSB3YW50IHRvIGhhdmUgdGhlIG9wdGlvbiB0byBzaW1wbHkgaW5jIQ0Kb3Jw b3JhdGUNCiAic3VidHJlZXMiIGZyb20gdGhlIGRldmljZSBhbmQgbWFrZSB0aGVtIGFjY2Vzc2li bGUgdG8gb3RoZXIgYXBwbGljYXRpb25zIGJ5IG1vdW50aW5nIHRoZW0sIHdpdGhvdXQgcmVxdWly aW5nIGZ1cnRoZXIgZGV2ZWxvcG1lbnQgKG9yIHJlcXVpcmluZyBzeXN0ZW1zIHRvICJnbyBhcm91 bmQiIHRoZSBjb250cm9sbGVyLCB3aGljaCBjb21wbGljYXRlcyBkZXZlbG9wbWVudCBvZiB0aG9z ZSBvdGhlciBzeXN0ZW0gYW5kL29yIGludHJvZHVjZXMgb3RoZXIgaXNzdWVzIHN1Y2ggYXMgc3lu Y2hyb25pemF0aW9uKS4gIA0KDQpbUWluXSBJbnRlcmVzdGluZywgSXMgdGhpcyBpZGVhIGFib3V0 IGRhdGFzdG9yZSBkYXRhIHN5bmNocm9uaXphdGlvbiBpbiBkaWZmZXJlbnQgbGV2ZWxzLiBPbmUg c3Vic2V0IG9mIGRhdGFzdG9yZSBkYXRhIGluIGxvd2VyIGxldmVsIGNhbiBiZSBuZXN0ZWQgaW50 byBhIGRhdGFzdG9yZSBpbiBoaWdoZXIgbGV2ZWwgYW5kIGluc2VydGVkIGFzIG1vdW50aW5nIHBv aW50LiBEYXRhc3RvcmUgZGF0YSBpbiBsb3dlciBsZXZlbCBkb2Vzbid0IG5lZWQgdG8gYmUgdW5m b2xkZWQgb3IgZXhwb3NlZCB0byBtb3JlIGhpZ2hlciBsZXZlbCBjbGllbnQgdGhhdCBpcyBvbiB0 b3Agb2YgdGhlIGNvbnRyb2xsZXIuIE1vdW50aW5nIHBvaW50IHByb3ZpZGUgYSByZWZlcmVuY2Ug cG9pbnQgaW4gdGhlIHJlbW90ZSBkYXRhc3RvcmUgdG8gcmV0cmlldmUgdGhlIGRhdGEuIE5ldHdv cmsgdG9wbyBpbmZvcm1hdGlvbiBnYXRoZXJpbmcgY2FuIGJlIGEgZ29vZCBleGFtcGxlIGZvciBz dWNoIGRhdGEgcmV0cmlldmluZy4gQnV0IGl0IGlzIG5vdCBjbGVhciB0byBtZSBob3cgdGhpcyBj YW4gc3VwcG9ydCBtdWx0aS10ZW5hbmN5IHdoZW4gZGlmZmVyZW50IHRlbmFudCBoYXMgZGlmZmVy ZW50IHZpZXcgb2YgbmV0d29yayB0b3BvLg0KSW4gYWRkaXRpb24sIHdoZXJlIHRvIGluc2VydCBk YXRhIGZyb20gcmVtb3RlIGRhdGFzdG9yZSBpbiB0aGUgbG9jYWwgZGF0YXN0b3JlIGlzIG5vdCB2 ZXJ5IGNsZWFyIGFzIHdlbGwuIA0KDQotLS0gQWxleA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogSnVlcmdlbiBTY2hvZW53YWVsZGVyIFttYWlsdG86ai5zY2hvZW53YWVsZGVy QGphY29icy11bml2ZXJzaXR5LmRlXQ0KU2VudDogRnJpZGF5LCBPY3RvYmVyIDEwLCAyMDE0IDI6 MTAgUE0NClRvOiBKYW4gTWVkdmVkIChqbWVkdmVkKQ0KQ2M6IEtlbnQgV2F0c2VuOyBBbGV4YW5k ZXIgQ2xlbW0gKGFsZXgpOyBuZXRtb2RAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbmV0bW9kXSBO ZXcgcmV2aXNpb24gb2YgWUFORyBtb3VudCBkcmFmdA0KDQpPbiBUaHUsIE9jdCAwOSwgMjAxNCBh dCAwOTo1OTozMVBNICswMDAwLCBKYW4gTWVkdmVkIChqbWVkdmVkKSB3cm90ZToNCj4gDQo+IFRv ZGF5LCBZYW5nIGRvZXMgbm90IGFsbG93IGEgY29udHJvbGxlciBhcHBsaWNhdGlvbiB0byB3b3Jr IGRpcmVjdGx5IA0KPiB3aXRoIGRldmljZSB5YW5nIG1vZGVscy4gQSBjb250cm9sbGVyIGhhcyB0 byByZS1kZWZpbmUgZGV2aWNlIG1vZGVscyANCj4gaW50byBjb250cm9sbGVyLXNwZWNpZmljIG1v ZGVscyBpbnNpZGUgdGhlIGNvbnRyb2xsZXIgYW5kIHByZXNlbnQgdGhlIA0KPiByZWRlZmluZWQg bW9kZWxzIHRvIGFwcGxpY2F0aW9ucy4NCg0KSG93IGlzIHRoaXMgZmFsbGluZyBvdXQgb2YgUkZD IDYwMjA/DQoNCi9qcw0KDQotLSANCkp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFj b2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQpQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAg ICAgIENhbXB1cyBSaW5nIDEsIDI4NzU5IEJyZW1lbiwgR2VybWFueQ0KRmF4OiAgICs0OSA0MjEg MjAwIDMxMDMgICAgICAgICA8aHR0cDovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFp bGluZyBsaXN0DQpuZXRtb2RAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbmV0bW9kDQo= From nobody Sat Oct 11 22:23:19 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B72D31A8885 for ; Sat, 11 Oct 2014 22:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 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, RP_MATCHES_RCVD=-0.786, 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 hxEgyuQPWnxE for ; Sat, 11 Oct 2014 22:22:45 -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 521181A8887 for ; Sat, 11 Oct 2014 22:22:44 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNN92477; Sun, 12 Oct 2014 05:22:42 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 12 Oct 2014 06:22:41 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.21]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Sun, 12 Oct 2014 13:22:37 +0800 From: Qin Wu To: Juergen Schoenwaelder , "Alexander Clemm (alex)" Thread-Topic: [netmod] New revision of YANG mount draft Thread-Index: AQHP40RfcXk3qRma8kec20irC7AonJwoMIcAgAEfzwCAAANUgIAACP+AgAAeuQCAALPIAIABt5zQ Date: Sun, 12 Oct 2014 05:22:37 +0000 Message-ID: References: <20141010210934.GB80385@elstar.local> <20141010215341.GD80385@elstar.local> <20141011102706.GA81740@elstar.local> In-Reply-To: <20141011102706.GA81740@elstar.local> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.12.236] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/yol09U-tU4JcUw2HWirL6aKibUo Cc: "netmod@ietf.org" Subject: Re: [netmod] New revision of YANG mount draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 12 Oct 2014 05:23:01 -0000 SGksDQpJIHRoaW5rIEp1ZXJnZW4gYXNrZWQgYSBnb29kIHF1ZXN0aW9uLCBJIGFtIHdvbmRlcmlu ZyBob3cgdGhpcyB3b3JrIGlzIHJlbGF0ZWQgdG8gc3VidHJlZSBmaWx0ZXJpbmcgZXhwcmVzc2lv bi4NCkkgdGhvdWdodCBpdCBpcyBxdWl0ZSByZWxhdGVkLg0KDQpSZWdhcmRzIQ0KLVFpbg0KLS0t LS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2VzQGll dGYub3JnXSC0+rHtIEp1ZXJnZW4gU2Nob2Vud2FlbGRlcg0Kt6LLzcqxvOQ6IDIwMTTE6jEw1MIx McjVIDE4OjI3DQrK1bz+yMs6IEFsZXhhbmRlciBDbGVtbSAoYWxleCkNCrOty806IG5ldG1vZEBp ZXRmLm9yZw0K1vfM4jogUmU6IFtuZXRtb2RdIE5ldyByZXZpc2lvbiBvZiBZQU5HIG1vdW50IGRy YWZ0DQoNCkFsZXgsDQoNCndlIHNlZW0gdG8gdGFsayBwYXN0IGVhY2ggb3RoZXIsIEkgYW0gbm90 IHN1cmUgd2h5LiBZb3Ugd3JvdGUgc29tZXRoaW5nIGxpa2UgdGhpczoNCg0KPiA+ID4gVG9kYXks IFlhbmcgZG9lcyBub3QgYWxsb3cgYSBjb250cm9sbGVyIGFwcGxpY2F0aW9uIHRvIHdvcmsgDQo+ ID4gPiBkaXJlY3RseSB3aXRoIGRldmljZSB5YW5nIG1vZGVscy4gQSBjb250cm9sbGVyIGhhcyB0 byByZS1kZWZpbmUgDQo+ID4gPiBkZXZpY2UgbW9kZWxzIHRoZSByZWRlZmluZWQgbW9kZWxzIHRv IGFwcGxpY2F0aW9ucy4NCg0KU28gSSBhbSB3b25kZXJpbmcgd2hhdCBpbiBSRkMgNjAyMCBpcyBs ZWFkaW5nIHRvIHRoaXMgc3RhdGVtZW50LiBJIGRpZCBub3QgZmluZCBhbnl0aGluZyBzbyBJIG5l ZWQgeW91ciBoZWxwIHRvIHVuZGVyc3RhbmQgdGhpcy4gSSBhbSBhbHNvIGdldHRpbmcgY29uZnVz ZWQgd2hlbiB5b3Ugc2F5IHRoZXJlIGlzIG5vIHByb3RvY29sIHdvcmsgbmVlZGVkLCB0aGluZ3Mg Y2FuIGJlIGRvbmUgd2l0aGluIHRoZSBleGlzdGluZyBmcmFtZXdvcmssIGJ1dCB0aGVuIHlvdSBz YXkgdGhlcmUgaXMgYSBuZWVkIGZvciBhIHB1c2ggYW5kL29yIHB1Yi9zdWIgbW9kZWwgZm9yIGRh dGEgc3VidHJlZXMgKHdoaWNoIGlzIG5vdCB0aGVyZSB0b2RheSkuDQoNCkl0IGhlbHBzIG1lIGlm IHlvdSBmb2N1cyBvbiBjbGVhcmx5IGV4cGxhaW5pbmcgd2hhdCB0aGUgdGVjaG5pY2FsIGRldGFp bHMgYXJlIHlvdSB0aGluayBzaG91bGQgYmUgc3RhbmRhcmRpemVkIGZvciB5b3VyIHVzZSBjYXNl LiBUaGVyZSBpcyBsb3RzIG9mIHRleHQgd2h5IHlvdXIgdXNlIGNhc2UgaXMgaW1wb3J0YW50IGJ1 dCB3aGF0IEkgYW0gbG9va2luZyBmb3IgaXMgYSBjb25jaXNlIGFuZCBjbGVhciBkZXNjcmlwdGlv biBvZiB0aGUgZGV0YWlscyB0aGF0IHlvdSB0aGluayBuZWVkIHRvIGJlIHN0YW5kYXJkaXplZC4N Cg0KTm90ZSB0aGF0IHdlIHNvIGZhciBoYXZlIGEgc2V0dXAgaW4gdGhlIElFVEYgd2hlcmUgb25l IFdHIGRvZXMgcHJvdG9jb2wgd29yayBhbmQgYW5vdGhlciB0YWtlcyBjYXJlIG9mIHRoZSBkYXRh IG1vZGVsaW5nIGxhbmd1YWdlIGFuZCBzb21lIGNvcmUgZGF0YSBtb2RlbHMuIEkgdHJ5IHRvIHVu ZGVyc3RhbmQgd2hpY2ggcGllY2VzIG9mIGNvbmNyZXRlIHdvcmsgeW91IHdhbnQgdG8gZG8gc28g SSBjYW4gdW5kZXJzdGFuZCB3aGVyZSB0aGluZ3Mgc2hvdWxkIGJlIGRpc2N1c3NlZC4NCg0KL2pz DQoNCk9uIEZyaSwgT2N0IDEwLCAyMDE0IGF0IDExOjQzOjM4UE0gKzAwMDAsIEFsZXhhbmRlciBD bGVtbSAoYWxleCkgd3JvdGU6DQo+IEhpIEp1ZXJnZW4sDQo+IA0KPiBJIGFtIG5vdCBzdXJlIHdp dGggd2hhdCB5b3UgbWVhbiB3aXRoICJ0aGlzIGZhbGxzIG91dCBvZiBSRkMgNjAyMCI/ICANCj4g DQo+IFRvIHlvdXIgc3RhdGVtZW50OiAiSW4gZmFjdCwgbXkgcmVhZGluZyBvZiB0aGUgSS1EIGlz IHRoYXQgeW91IGRvIG5vdCByZXF1ZXN0IHRvIGNoYW5nZSBhbnl0aGluZyBpbiBZQU5HIGF0IGFs bCAtIGFsbCB5b3UgcHJvcG9zZSBpcyB0byBkZWZpbmUgYSBmZXcgZXh0ZW5zaW9ucyBhbmQgYSBk YXRhIG1vZGVsLiIgIFllcywgSSBhZ3JlZTsgeW91ciB1bmRlcnN0YW5kaW5nIGlzIGNvcnJlY3Qu ICBUaGUgcHJvcG9zYWwgd2UgYXJlIG1ha2luZyBhZGRyZXNzZXMgdGhlIHJlcXVpcmVtZW50cyB3 aXRoaW4gdGhlIGV4aXN0aW5nIGZyYW1ld29yay4gIA0KPiANCj4gUmVnYXJkaW5nIHRoZSAicHJv dG9jb2wgcG9ydGlvbiIsIHdlIGFyZSBtYWtpbmcgdGhlIGNhc2UgdGhhdCBpbXBsZW1lbnRhdGlv biBvZiB0aGlzIHdpbGwgYmUgZmFjaWxpdGF0ZWQgYnkgaGF2aW5nIGEgcHVzaCBhbmQvb3IgcHVi L3N1YiBtb2RlbCBmb3IgZGF0YSBzdWJ0cmVlcy4gIFRoaXMgZG9lcyBub3QgbmVjZXNzYXJpbHkg cmVxdWlyZSBhY3R1YWwgcHJvdG9jb2wgd29yayAoYWx0aG91Z2ggc3VjaCB3b3JrIGNvdWxkIGJl IGRlZmluZWQpIGJ1dCBjYW4gYmUgYWRkcmVzc2VkIGFnYWluIHdpdGhpbiB0aGUgZXhpc3Rpbmcg ZnJhbWV3b3JrLCB1c2luZyBhIHN1YnNjcmlwdGlvbiBjb25maWd1cmF0aW9uIG1vZGVsLCBub3Rp ZmljYXRpb25zIGV0YyBhcyBvdXRsaW5lZCBpbiB0aGUgZHJhZnQuICANCj4gDQo+IC0tLSBBbGV4 DQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKdWVyZ2VuIFNjaG9l bndhZWxkZXIgDQo+IFttYWlsdG86ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRl XQ0KPiBTZW50OiBGcmlkYXksIE9jdG9iZXIgMTAsIDIwMTQgMjo1NCBQTQ0KPiBUbzogQWxleGFu ZGVyIENsZW1tIChhbGV4KQ0KPiBDYzogSmFuIE1lZHZlZCAoam1lZHZlZCk7IEtlbnQgV2F0c2Vu OyBuZXRtb2RAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtuZXRtb2RdIE5ldyByZXZpc2lvbiBv ZiBZQU5HIG1vdW50IGRyYWZ0DQo+IA0KPiBJIHN0aWxsIGZhaWwgdG8gc2VlIGhvdyBhbGwgdGhp cyBmYWxscyBvdXQgb2YgUkZDIDYwMjAuDQo+IA0KPiBJIHNlZSBwcm90b2NvbCBkaXNjdXNzaW9u IGluIGRyYWZ0LWNsZW1tLW5ldG1vZC1tb3VudC0wMi50eHQgKHdoaWNoIGlzIG5lZWRlZCBmb3Ig d2hhdCB5b3Ugd2FudCB0byBkbyBhbmQgbGlrZWx5IGV2ZW4gaW5jb21wbGV0ZSkgYnV0IHRoZW4g dGhlIE5FVE1PRCBXRyBpcyBub3QgYWJvdXQgcHJvdG9jb2wgd29yayBidXQgYWJvdXQgdGhlIGRh dGEgbW9kZWxpbmcgbGFuZ3VhZ2UgWUFORyBhbmQgZGF0YSBtb2RlbHMuIEluIGZhY3QsIG15IHJl YWRpbmcgb2YgdGhlIEktRCBpcyB0aGF0IHlvdSBkbyBub3QgcmVxdWVzdCB0byBjaGFuZ2UgYW55 dGhpbmcgaW4gWUFORyBhdCBhbGwgLSBhbGwgeW91IHByb3Bvc2UgaXMgdG8gZGVmaW5lIGEgZmV3 IGV4dGVuc2lvbnMgYW5kIGEgZGF0YSBtb2RlbC4NCj4gDQo+IERvIHlvdSBhZ3JlZT8gT3Igd2hl cmUgYW0gSSBtaXMtdW5kZXJzdGFuZGluZyB0aGluZ3M/DQo+IA0KPiAvanMNCj4gDQo+IE9uIEZy aSwgT2N0IDEwLCAyMDE0IGF0IDA5OjIxOjI5UE0gKzAwMDAsIEFsZXhhbmRlciBDbGVtbSAoYWxl eCkgd3JvdGU6DQo+ID4gV2hhdCB0aGlzIHJlZmVycyB0byBpcyB0aGUgY2FzZSBvZiBhIGhpZXJh cmNoeSwgd2hlcmUgYSBzeXN0ZW0gaW4gYSBjbGllbnQgcm9sZSBhY2Nlc3Nlc2VzIGFub3RoZXIg c3lzdGVtIGluIGEgc2VydmVyIHJvbGUgKGUuZy4gYSBjb250cm9sbGVyKSB3aGljaCBpdHNlbGYg aXMgYSBjbGllbnQgdG8gYW5vdGhlciBzZXJ2ZXIgKGUuZy4gYSBuZXR3b3JrIGRldmljZSkuICBP bmUgKHN0cmFpZ2h0Zm9yd2FyZCkgYXBwcm9hY2ggaXMgdG8gaWdub3JlIHRoZSBmYWN0IHRoYXQg dGhlIHNlcnZlciAoZS5nLiB0aGUgY29udHJvbGxlcikgY2FuIGJlIGEgY2xpZW50LCBhbmQgc2lt cGx5IGhhdmUgaXQgaW5jb3Jwb3JhdGUgaXRzIG93biBzZXQgb2YgWUFORyBtb2RlbHMgdG8gcmVw cmVzZW50IHRoZSBvdGhlciBkZXZpY2VzIGJlbG93IGl0LiAgVGhlIGRvd25zaWRlIGlzIHRoYXQg dGhpcyByZXF1aXJlcyB0aGUgY29udHJvbGxlciB0byByZWRlZmluZSBhbmQgaW1wbGVtZW50IHRo b3NlIG1vZGVscyAtIHRoZXkgY2Fubm90IGJlIHNpbXBseSByZXVzZWQgYXMgZS5nLiB0aGUgInNj b3BlIiBpcyBkaWZmZXJlbnQsIGFuZCB0aGUgc2VydmVyIGhhcyB0byBoYXZlIGEgc2VtYW50aWMg InVuZGVyc3RhbmRpbmciIG9mIGV2ZXJ5dGhpbmcgaW4gdGhlIGRldmljZXMgdW5kZXJuZWF0aCBp dC4gVGhpcyBicmluZ3MgYWJvdXQgdGhlIHNhbWUgc2l0dWF0aW9uIHRoYXQgTk1TIGhhcyBoYWQg Zm9yIGRlY2FkZXMsIHRoYXQgaW50ZWdyYXRpbmcgbmV3IGRldmljZXMgaW50byBhbiBvcGVyYXRp b25hbCBlbnZpcm9ubWVudCBpcyBoZWxkIGhvc3RhZ2UgYnkgdGhlIE5NUywgd2hpY2ggZmlyc3Qg bmVlZHMgdG8gc3VwcG9ydCAoYW5kIHJlcXVpcmUgY29ycmVzcG9uZGluZyBkZXZlbG9wbWVudCBz dXBwb3J0IGZvcikgYWxsIHRob3NlIG5ldyBwYXJhbWV0ZXJzLiAgSW4gb3VyIGNhc2UsIHdlIHdh bnQgdG8gaGF2ZSB0aGUgb3B0aW9uIHRvIHNpbXBseSENCiBpbmNvcnBvcg0KIGF0ZSAic3VidHJl ZXMiIGZyb20gdGhlIGRldmljZSBhbmQgbWFrZSB0aGVtIGFjY2Vzc2libGUgdG8gb3RoZXIgYXBw bGljYXRpb25zIGJ5IG1vdW50aW5nIHRoZW0sIHdpdGhvdXQgcmVxdWlyaW5nIGZ1cnRoZXIgZGV2 ZWxvcG1lbnQgKG9yIHJlcXVpcmluZyBzeXN0ZW1zIHRvICJnbyBhcm91bmQiIHRoZSBjb250cm9s bGVyLCB3aGljaCBjb21wbGljYXRlcyBkZXZlbG9wbWVudCBvZiB0aG9zZSBvdGhlciBzeXN0ZW0g YW5kL29yIGludHJvZHVjZXMgb3RoZXIgaXNzdWVzIHN1Y2ggYXMgc3luY2hyb25pemF0aW9uKS4g IA0KPiA+IC0tLSBBbGV4DQo+ID4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g PiBGcm9tOiBKdWVyZ2VuIFNjaG9lbndhZWxkZXINCj4gPiBbbWFpbHRvOmouc2Nob2Vud2FlbGRl ckBqYWNvYnMtdW5pdmVyc2l0eS5kZV0NCj4gPiBTZW50OiBGcmlkYXksIE9jdG9iZXIgMTAsIDIw MTQgMjoxMCBQTQ0KPiA+IFRvOiBKYW4gTWVkdmVkIChqbWVkdmVkKQ0KPiA+IENjOiBLZW50IFdh dHNlbjsgQWxleGFuZGVyIENsZW1tIChhbGV4KTsgbmV0bW9kQGlldGYub3JnDQo+ID4gU3ViamVj dDogUmU6IFtuZXRtb2RdIE5ldyByZXZpc2lvbiBvZiBZQU5HIG1vdW50IGRyYWZ0DQo+ID4gDQo+ ID4gT24gVGh1LCBPY3QgMDksIDIwMTQgYXQgMDk6NTk6MzFQTSArMDAwMCwgSmFuIE1lZHZlZCAo am1lZHZlZCkgd3JvdGU6DQo+ID4gPiANCj4gPiA+IFRvZGF5LCBZYW5nIGRvZXMgbm90IGFsbG93 IGEgY29udHJvbGxlciBhcHBsaWNhdGlvbiB0byB3b3JrIA0KPiA+ID4gZGlyZWN0bHkgd2l0aCBk ZXZpY2UgeWFuZyBtb2RlbHMuIEEgY29udHJvbGxlciBoYXMgdG8gcmUtZGVmaW5lIA0KPiA+ID4g ZGV2aWNlIG1vZGVscyBpbnRvIGNvbnRyb2xsZXItc3BlY2lmaWMgbW9kZWxzIGluc2lkZSB0aGUg DQo+ID4gPiBjb250cm9sbGVyIGFuZCBwcmVzZW50IHRoZSByZWRlZmluZWQgbW9kZWxzIHRvIGFw cGxpY2F0aW9ucy4NCj4gPiANCj4gPiBIb3cgaXMgdGhpcyBmYWxsaW5nIG91dCBvZiBSRkMgNjAy MD8NCj4gPiANCj4gPiAvanMNCj4gPiANCj4gPiAtLSANCj4gPiBKdWVyZ2VuIFNjaG9lbndhZWxk ZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KPiA+IFBob25lOiAr NDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSwgMjg3NTkgQnJlbWVuLCBHZXJt YW55DQo+ID4gRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cDovL3d3dy5qYWNv YnMtdW5pdmVyc2l0eS5kZS8+DQo+IA0KPiAtLSANCj4gSnVlcmdlbiBTY2hvZW53YWVsZGVyICAg ICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNCj4gUGhvbmU6ICs0OSA0MjEg MjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxLCAyODc1OSBCcmVtZW4sIEdlcm1hbnkNCj4g RmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cDovL3d3dy5qYWNvYnMtdW5pdmVy c2l0eS5kZS8+DQoNCi0tIA0KSnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMg VW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNClBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAg Q2FtcHVzIFJpbmcgMSwgMjg3NTkgQnJlbWVuLCBHZXJtYW55DQpGYXg6ICAgKzQ5IDQyMSAyMDAg MzEwMyAgICAgICAgIDxodHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4NCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWlsaW5n IGxpc3QNCm5ldG1vZEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9uZXRtb2QNCg== From nobody Mon Oct 13 04:05:25 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 910521A02EA; Mon, 13 Oct 2014 04:05: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 Xch_9uEsiSNh; Mon, 13 Oct 2014 04:05:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 75C1F1A0313; Mon, 13 Oct 2014 04:05:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141013110515.25281.96490.idtracker@ietfa.amsl.com> Date: Mon, 13 Oct 2014 04:05:15 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/4LMqspaD3GjPdmJgkb6VMg4Qvsw Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-yang-json-01.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: Mon, 13 Oct 2014 11:05:18 -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-01.txt Pages : 17 Date : 2014-10-13 Abstract: This document defines encoding rules for representing configuration, state data, RPC 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: http://tools.ietf.org/html/draft-ietf-netmod-yang-json-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-json-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/ From nobody Mon Oct 13 04:09:04 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD34D1A0306 for ; Mon, 13 Oct 2014 04:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.437 X-Spam-Level: X-Spam-Status: No, score=-1.437 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, RP_MATCHES_RCVD=-0.786] 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 EUDFL601hGOT for ; Mon, 13 Oct 2014 04:08:59 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C55F61A016A for ; Mon, 13 Oct 2014 04:08:58 -0700 (PDT) Received: from [192.168.1.108] (unknown [195.113.220.254]) by mail.nic.cz (Postfix) with ESMTPSA id 5BA2814012E for ; Mon, 13 Oct 2014 13:08:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1413198537; bh=t82j+Zmmk/9IIdk5b/OakPNo2zYe6n6ASMukdjPRMfM=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Date: References:To:Message-Id:Mime-Version; b=A4nmy72y2euEiVeF2DNIooSu49+VzREvX0hT77Qz/KZZWJZkcw2j3VMM9FNv2tKbq DGQ8IqrFM42HnSiZDTHQezmQ6mRM2GhcKFf1vzsLbeQuB6sq8odSiDuaIqJWSr3MF6 lw8fhvxjS/iRLLpp3pvLGpYHdFtOlLgsVDZH5Zs4= From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Oct 2014 13:08:54 +0200 References: <20141013110516.25281.32846.idtracker@ietfa.amsl.com> To: NETMOD Working Group Message-Id: <0031A8ED-D33E-459C-A648-8595821EE6FB@nic.cz> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/wyDh_iAXffuyYj0wlznz7O9ifiE Subject: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-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: Mon, 13 Oct 2014 11:09:01 -0000 Hi, this revision should address all issues and comments raised since -00. = Major changes are: o Metadata encoding was moved to a separate I-D, = draft-lhotka-netmod-yang-metadata. o JSON encoding is now defined directly rather than via XML-JSON mapping. o The rules for namespace encoding has changed. This affect both node instance names and instance-identifiers. o I-JSON-related changes. The most significant is the string encoding of 64-bit numbers. o When validating union type, the partial type info present in JSON encoding is taken into account. o Added section about I-JSON compliance. o Updated the example in appendix. o Wrote Security Considerations. o Removed IANA Considerations as there are none. Lada Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-ietf-netmod-yang-json-01.txt > Date: 13 Oct 2014 13:05:16 GMT+2 > To: Ladislav Lhotka , "Ladislav Lhotka" >=20 >=20 > A new version of I-D, draft-ietf-netmod-yang-json-01.txt > has been successfully submitted by Ladislav Lhotka and posted to the > IETF repository. >=20 > Name: draft-ietf-netmod-yang-json > Revision: 01 > Title: JSON Encoding of Data Modeled with YANG > Document date: 2014-10-13 > Group: netmod > Pages: 17 > URL: = http://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-json-01.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-json/ > Htmlized: = http://tools.ietf.org/html/draft-ietf-netmod-yang-json-01 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-yang-json-01 >=20 > Abstract: > This document defines encoding rules for representing configuration, > state data, RPC 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 Mon Oct 13 07:20:34 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3D4E1A004D for ; Mon, 13 Oct 2014 07:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnoZ85cGdmeM for ; Mon, 13 Oct 2014 07:20: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 0E89F1A0060 for ; Mon, 13 Oct 2014 07:20:05 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 647AF788; Mon, 13 Oct 2014 16:20: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 zqCizMeEXxlY; Mon, 13 Oct 2014 16:20:02 +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, 13 Oct 2014 16:20:02 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 998E220037; Mon, 13 Oct 2014 16:20:02 +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 zRHGW9pUmQgy; Mon, 13 Oct 2014 16:20:01 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 448CE20036; Mon, 13 Oct 2014 16:20:01 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 75D0A2EF4744; Mon, 13 Oct 2014 16:20:00 +0200 (CEST) Date: Mon, 13 Oct 2014 16:20:00 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20141013141959.GC53210@elstar.local> Mail-Followup-To: Ladislav Lhotka , NETMOD Working Group References: <20141013110516.25281.32846.idtracker@ietfa.amsl.com> <0031A8ED-D33E-459C-A648-8595821EE6FB@nic.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0031A8ED-D33E-459C-A648-8595821EE6FB@nic.cz> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/R4d7o5u292PvdF73v3lUNJN1GBM Cc: NETMOD Working Group Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-01.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, 13 Oct 2014 14:20:23 -0000 Lada, thanks for the update. I think we still have open issues: - Namespace name. The YANG namespace statement declares a URI to be used as a namespace while you propose to use module names in JSON. This makes round-trip conversions more difficult that needed. I do not think we resolved this issue. Lets not reiterate it but lets also not declare it resolved. ;-) - The draft says YANG lists are always mapped to unordered arrays in JSON. It is unclear how this works with lists ordered-by user, e.g. a packet filter list where the order matters. I understand that assuming no order is also an I-JSON requirement. Unfortunately, we do seem to have ordered data to deal with. - I am not sure I understand this logic: This document defines no mapping between the contents of JSON- and XML-encoded anyxml instances. It is not necessary because anyxml contents are not subject to YANG-based validation (see sec. 7.10 in [RFC6020]). Are you saying things outside of validation can be simply ignored? It is not totally clear why this is the case. I have something like Kent's configlets in mind for example. You maybe wanted to say that anyxml data should be rendered as much as possible using the various JSON types but how this is done is implementation specific. Since anyxml itself is essentially open ended XML, this is no worse that using anyxml in the first place. - It is not clear whether it is legal to encode everything into a string. This was discussed some time ago since essentially YANG's type system is based in literal string representations. - Related to the above: Do we really treat "bar": 13.5 as an encoding error? What is gained by doing this in comparison to simply convert to a string? I heard that some implementations do kind of ignore the JSON type in order to improve chances of interoperability. Does it make sense to track issues somewhere? /js On Mon, Oct 13, 2014 at 01:08:54PM +0200, Ladislav Lhotka wrote: > Hi, > > this revision should address all issues and comments raised since -00. Major changes are: > > o Metadata encoding was moved to a separate I-D, draft-lhotka-netmod-yang-metadata. > > o JSON encoding is now defined directly rather than via XML-JSON > mapping. > > o The rules for namespace encoding has changed. This affect both > node instance names and instance-identifiers. > > o I-JSON-related changes. The most significant is the string > encoding of 64-bit numbers. > > o When validating union type, the partial type info present in JSON > encoding is taken into account. > > o Added section about I-JSON compliance. > > o Updated the example in appendix. > > o Wrote Security Considerations. > > o Removed IANA Considerations as there are none. > -- 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 Oct 13 09:27:02 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F41651A1AFD for ; Mon, 13 Oct 2014 09:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jk5f2P-gYUDo for ; Mon, 13 Oct 2014 09:26:57 -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 237061A1ADA for ; Mon, 13 Oct 2014 09:26:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4672; q=dns/txt; s=iport; t=1413217617; x=1414427217; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=OV9S2QqWFTSjrXVakHAHo4nOK8bOv0WIfBkk4xVNQzk=; b=kEDIXZUAY4G8k1m7H4zvXBHAi/mZR4HDd6LOXEO7QoU7AOgpBxbdxBzM BWgq8/moexIh8KUWLjEsHV2WoyoXFnJPQgi+E5r/M9MkmdSbgwlRxDcYa 9NoxwjgDt+6V+JTPCWKlKePutUY5vwYG7vNRM/ZD6WfYMnjw03ELjktCf c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAPT7O1StJV2d/2dsb2JhbABYA4MOU1gEyxkKhnlUAoEdFgF9hAIBAQEDAQEBATc0CwUHAgICAQgOAgEEAQEBChQJBxsMCxQJCAIEAQ0FCIguCA3FFQEBAQEBAQEBAQEBAQEBAQEBAQEBARcEkBAhEAcGC4McgR4FkXmhY4N3bIFIgQIBAQE X-IronPort-AV: E=Sophos;i="5.04,711,1406592000"; d="scan'208";a="86515136" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-6.cisco.com with ESMTP; 13 Oct 2014 16:26:56 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s9DGQuQ8010636 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Oct 2014 16:26:56 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.41]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Mon, 13 Oct 2014 11:26:56 -0500 From: "Eric Voit (evoit)" To: Juergen Schoenwaelder , "Alexander Clemm (alex)" Thread-Topic: [netmod] New revision of YANG mount draft Thread-Index: AQHP5NSnXWBBH+aajkuz6A/yEBcVLJwuAk1Q Date: Mon, 13 Oct 2014 16:26:55 +0000 Message-ID: References: <20141010210934.GB80385@elstar.local> <20141010215341.GD80385@elstar.local> In-Reply-To: <20141010215341.GD80385@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.134.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/uHWB1BIsScvWfdo-CazVe4rT_Eg Cc: "netmod@ietf.org" Subject: Re: [netmod] New revision of YANG mount draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Oct 2014 16:27:00 -0000 > From: Juergen Schoenwaelder, October 10, 2014 5:54 PM >=20 > I still fail to see how all this falls out of RFC 6020. If by falling out you mean 'in conflict with', then I would agree that ther= e are not backwards compatibility issues with RFC 6020 section 6 syntax. T= his was by design. =20 However I believe Alex' and Jan's concerns are with Section 5.1 of RFC 6020= . This section includes statements such as: "For a module or submodule t= o reference definitions in an external module, the external module MUST be = imported." Bringing in targeted nodes and subtrees need not require visibility into th= e full submodule where the authoritative copy of the object might reside. > I see protocol discussion in draft-clemm-netmod-mount-02.txt (which is ne= eded > for what you want to do and likely even incomplete) but then the NETMOD W= G > is not about protocol work but about the data modeling language YANG and > data models. In fact, my reading of the I-D is that you do not request to= change > anything in YANG at all - all you propose is to define a few extensions a= nd a data > model. The 'on-demand' Mount does not need any protocol work. It is the easiest, = and is looking to standardize needed several syntax extensions. This type = of Mount is what is implemented in OpenDaylight today. =20 Not yet fully fleshed out in draft-clemm-netmod-mount are evolving capabili= ties such as 'periodic' and 'on-change' Mounts. Beyond additional syntax e= xtensions these will need mechanisms to allow Mount Server to pass changed = objects to Mount Client subscribers. RFC 5277 doesn't meet needs from several fronts. Most relevant to this WG = is that we want don't want any protocol work to be transport specific. Eric =20 > Do you agree? Or where am I mis-understanding things? >=20 > /js >=20 > On Fri, Oct 10, 2014 at 09:21:29PM +0000, Alexander Clemm (alex) wrote: > > What this refers to is the case of a hierarchy, where a system in a > > client role accesseses another system in a server role (e.g. a > > controller) which itself is a client to another server (e.g. a network > > device). One (straightforward) approach is to ignore the fact that > > the server (e.g. the controller) can be a client, and simply have it > > incorporate its own set of YANG models to represent the other devices > > below it. The downside is that this requires the controller to > > redefine and implement those models - they cannot be simply reused as > > e.g. the "scope" is different, and the server has to have a semantic > > "understanding" of everything in the devices underneath it. This > > brings about the same situation that NMS has had for decades, that > > integrating new devices into an operational environment is held > > hostage by the NMS, which first needs to support (and require > > corresponding development support for) all those new parameters. In > > our case, we want to have the option to simply incorporat > e "subtrees" from the device and make them accessible to other applicati= ons by > mounting them, without requiring further development (or requiring system= s to > "go around" the controller, which complicates development of those other > system and/or introduces other issues such as synchronization). > > --- Alex > > > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Friday, October 10, 2014 2:10 PM > > To: Jan Medved (jmedved) > > Cc: Kent Watsen; Alexander Clemm (alex); netmod@ietf.org > > Subject: Re: [netmod] New revision of YANG mount draft > > > > On Thu, Oct 09, 2014 at 09:59:31PM +0000, Jan Medved (jmedved) wrote: > > > > > > Today, Yang does not allow a controller application to work directly > > > with device yang models. A controller has to re-define device models > > > into controller-specific models inside the controller and present > > > the redefined models to applications. > > > > How is this falling out of RFC 6020? > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 >=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 Mon Oct 13 12:23:02 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C169E1A8AF1 for ; Mon, 13 Oct 2014 12:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARQhbEkLwntt for ; Mon, 13 Oct 2014 12:22:54 -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 B696A1A8AD0 for ; Mon, 13 Oct 2014 12:22:53 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 5F9AA764; Mon, 13 Oct 2014 21:22:52 +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 CjT-wlkq_dea; Mon, 13 Oct 2014 21:22:51 +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, 13 Oct 2014 21:22:51 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 09AE820036; Mon, 13 Oct 2014 21:22:51 +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 doUQCVR_GAYs; Mon, 13 Oct 2014 21:22:50 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BF4C420038; Mon, 13 Oct 2014 21:22:49 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id EE37A2EF5CD6; Mon, 13 Oct 2014 21:22:48 +0200 (CEST) Date: Mon, 13 Oct 2014 21:22:48 +0200 From: Juergen Schoenwaelder To: "Eric Voit (evoit)" Message-ID: <20141013192248.GA68615@elstar.local> Mail-Followup-To: "Eric Voit (evoit)" , "Alexander Clemm (alex)" , "netmod@ietf.org" References: <20141010210934.GB80385@elstar.local> <20141010215341.GD80385@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: http://mailarchive.ietf.org/arch/msg/netmod/wx7hang1rQEcWY0Dx3NdIQDUMiY Cc: "netmod@ietf.org" Subject: Re: [netmod] New revision of YANG mount draft 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, 13 Oct 2014 19:22:59 -0000 On Mon, Oct 13, 2014 at 04:26:55PM +0000, Eric Voit (evoit) wrote: > > From: Juergen Schoenwaelder, October 10, 2014 5:54 PM > > > > I still fail to see how all this falls out of RFC 6020. > > If by falling out you mean 'in conflict with', then I would agree that there are not backwards compatibility issues with RFC 6020 section 6 syntax. This was by design. > > However I believe Alex' and Jan's concerns are with Section 5.1 of RFC 6020. This section includes statements such as: "For a module or submodule to reference definitions in an external module, the external module MUST be imported." > > Bringing in targeted nodes and subtrees need not require visibility into the full submodule where the authoritative copy of the object might reside. > There is anyxml in YANG 1.0 and there is a proposal for anydata in YANG 1.1. > > I see protocol discussion in draft-clemm-netmod-mount-02.txt (which is needed > > for what you want to do and likely even incomplete) but then the NETMOD WG > > is not about protocol work but about the data modeling language YANG and > > data models. In fact, my reading of the I-D is that you do not request to change > > anything in YANG at all - all you propose is to define a few extensions and a data > > model. > > The 'on-demand' Mount does not need any protocol work. It is the easiest, and is looking to standardize needed several syntax extensions. This type of Mount is what is implemented in OpenDaylight today. > I am not sure. Can I run all NETCONF protocol operations transparently across these mount points? I doubt it. What you introduce is a "partitioning" of a datastore that does not architecturally exist so far. Does this lead to a new type of datastore or can I partition any datastore? How does this partitioning interact with ephemeral datastores discussed in I2RS? I believe there are serious _architectural_ questions that need to be discussed and depending on how they are resolved, there may be more or less protocol work needed. What triggered this discussions were statements of the form "YANG does not allow to do X" which I think is not correct since YANG really is not the issue. The mount work is extending/modifying/$(your-verb-here) the _architecture_ of NETCONF and YANG. It is not clear which WG is responsible for the underlying architecture. RFC 6244 was produced by NETMOD but then it describes more the framework and not the underlying architectural model (what Randy Presuhn I think calls the meta model). Perhaps we need to work on an architecture at some point in time, pretty much like we needed to define an architecture for SNMP at some point in time. The work on JSON encoding and the mount proposal clearly indicates that certain architectural assumptions are implicit and that leads to discussions that are difficult to close until we agree on an architecture. Who said history does not repeat? /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 Oct 13 12:49:53 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC7D91A7030 for ; Mon, 13 Oct 2014 12:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xe32NvtI6wrU for ; Mon, 13 Oct 2014 12:49:49 -0700 (PDT) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40F061A1BBF for ; Mon, 13 Oct 2014 12:49:49 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id x13so5580863qcv.18 for ; Mon, 13 Oct 2014 12:49: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=iN+ZMsYsgTzjoG3JVhgzU5TQcfFhPm65ZlwugzBGUAw=; b=ldieX/xKFurTgveFTfhyIwsMtRpzOoevYJrytkaIsVlV9xmap2DO3Q1FMS93bwqhEi aSn9+usmSe4ZwlsDHFDuZQglMI8hBXhJw9nQbd795gjKOeKfXXr3vrbALNvgHho+kQyh MjW92BE93sL1MZfz3qrIkuPRwpaG7Uha306BkSM+Sim3+BjdvhOf59u8LtrSDqFhDvQO cW2xQazQ53ZoJhMdS7Z96LQaVKR9eP4H/4CCYw2Y5KV6tV+HW53dy+dBq5Zwn5Zbj+V1 FymPSCT/JvIVkU0cNwek8zlMURfLENUZ+q2GWGnwVtRDqfQWW2C9Rzrr74gw3xwLL7YU eY1w== X-Gm-Message-State: ALoCoQkIZBoHWjYvO/yew/B8AwTCa+udU7YjLBn7OkmC/UJQggdcz0svmTGxrQwWnHw2uXSu808k MIME-Version: 1.0 X-Received: by 10.140.88.199 with SMTP id t65mr517802qgd.35.1413229788298; Mon, 13 Oct 2014 12:49:48 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Mon, 13 Oct 2014 12:49:48 -0700 (PDT) In-Reply-To: <20141013192248.GA68615@elstar.local> References: <20141010210934.GB80385@elstar.local> <20141010215341.GD80385@elstar.local> <20141013192248.GA68615@elstar.local> Date: Mon, 13 Oct 2014 12:49:48 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , "Eric Voit (evoit)" , "Alexander Clemm (alex)" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11c1337084c77e05055333e4 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/1qAHKlN3L8TEoa0_VZJyf8qxvDE Subject: Re: [netmod] New revision of YANG mount draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Oct 2014 19:49:52 -0000 --001a11c1337084c77e05055333e4 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 13, 2014 at 12:22 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Mon, Oct 13, 2014 at 04:26:55PM +0000, Eric Voit (evoit) wrote: > > > From: Juergen Schoenwaelder, October 10, 2014 5:54 PM > > > > > > I still fail to see how all this falls out of RFC 6020. > > > > If by falling out you mean 'in conflict with', then I would agree that > there are not backwards compatibility issues with RFC 6020 section 6 > syntax. This was by design. > > > > However I believe Alex' and Jan's concerns are with Section 5.1 of RFC > 6020. This section includes statements such as: "For a module or > submodule to reference definitions in an external module, the external > module MUST be imported." > > > > Bringing in targeted nodes and subtrees need not require visibility into > the full submodule where the authoritative copy of the object might reside. > > > > There is anyxml in YANG 1.0 and there is a proposal for anydata in > YANG 1.1. > > > > I see protocol discussion in draft-clemm-netmod-mount-02.txt (which is > needed > > > for what you want to do and likely even incomplete) but then the > NETMOD WG > > > is not about protocol work but about the data modeling language YANG > and > > > data models. In fact, my reading of the I-D is that you do not request > to change > > > anything in YANG at all - all you propose is to define a few > extensions and a data > > > model. > > > > The 'on-demand' Mount does not need any protocol work. It is the > easiest, and is looking to standardize needed several syntax extensions. > This type of Mount is what is implemented in OpenDaylight today. > > > > I am not sure. Can I run all NETCONF protocol operations transparently > across these mount points? I doubt it. > > What you introduce is a "partitioning" of a datastore that does not > architecturally exist so far. Does this lead to a new type of > datastore or can I partition any datastore? How does this partitioning > interact with ephemeral datastores discussed in I2RS? I believe there > are serious _architectural_ questions that need to be discussed and > depending on how they are resolved, there may be more or less protocol > work needed. > > This was my concern from the start. I think the mounted data is now read-only so YANG datastore validation does not apply. I do not want to partition the datastore. This would require a big change to many documents (including YANG). I can see that there might be some data models where it would be useful to collect the info from all the servers into one container within the controller NBI, but this is more of a proxy service than a mid-level manager service. I would expect the controller to provide its own northbound data models, that did aggregation, topN reporting, etc. The controller can use NETCONF as-is for the PULL model. Whether NETCONF notifications are sufficient or the desired solution to support a PUSH model is a valid issue -- but a general issue for controllers, not specific to the 'mount' draft. > What triggered this discussions were statements of the form "YANG does > not allow to do X" which I think is not correct since YANG really is > not the issue. The mount work is extending/modifying/$(your-verb-here) > the _architecture_ of NETCONF and YANG. It is not clear which WG is > responsible for the underlying architecture. RFC 6244 was produced by > NETMOD but then it describes more the framework and not the underlying > architectural model (what Randy Presuhn I think calls the meta > model). Perhaps we need to work on an architecture at some point in > time, pretty much like we needed to define an architecture for SNMP at > some point in time. The work on JSON encoding and the mount proposal > clearly indicates that certain architectural assumptions are implicit > and that leads to discussions that are difficult to close until we > agree on an architecture. > > Who said history does not repeat? > > /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 > --001a11c1337084c77e05055333e4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mon, Oct 13, 2014 at 12:22 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Mon, Oct 13, 2014 at 04:26:55PM +0000, Eric Voit= (evoit) wrote:
> > From: Juergen Schoenwaelder, October 10, 2014 5:54 PM
> >
> > I still fail to see how all this falls out of RFC 6020.
>
> If by falling out you mean 'in conflict with', then I would ag= ree that there are not backwards compatibility issues with RFC 6020 section= 6 syntax.=A0 This was by design.
>
> However I believe Alex' and Jan's concerns are with Section 5.= 1 of RFC 6020.=A0 =A0This section includes statements such as:=A0 "For= a module or submodule to reference definitions in an external module, the = external module MUST be imported."
>
> Bringing in targeted nodes and subtrees need not require visibility in= to the full submodule where the authoritative copy of the object might resi= de.
>

There is anyxml in YANG 1.0 and there is a proposal for anydata in
YANG 1.1.

> > I see protocol discussion in draft-clemm-netmod-mount-02.txt (whi= ch is needed
> > for what you want to do and likely even incomplete) but then the = NETMOD WG
> > is not about protocol work but about the data modeling language Y= ANG and
> > data models. In fact, my reading of the I-D is that you do not re= quest to change
> > anything in YANG at all - all you propose is to define a few exte= nsions and a data
> > model.
>
> The 'on-demand' Mount does not need any protocol work.=A0 It i= s the easiest, and is looking to standardize needed several syntax extensio= ns.=A0 This type of Mount is what is implemented in OpenDaylight today.
>

I am not sure. Can I run all NETCONF protocol operations transparently
across these mount points? I doubt it.

What you introduce is a "partitioning" of a datastore that does n= ot
architecturally exist so far. Does this lead to a new type of
datastore or can I partition any datastore? How does this partitioning
interact with ephemeral datastores discussed in I2RS? I believe there
are serious _architectural_ questions that need to be discussed and
depending on how they are resolved, there may be more or less protocol
work needed.


This was my concern from the start.=A0= I think the mounted data is now read-only
so YANG datastore vali= dation does not apply.

I do not want to partition = the datastore.=A0 This would require a big change to
many documen= ts (including YANG).=A0 I can see that there might be some
data m= odels where it would be useful to collect the info from all the servers
into one container within the controller NBI, but this is more of a = proxy service
than a mid-level manager service.=A0 I would expect= the controller to provide
its own northbound data models, that d= id aggregation, topN reporting, etc.

The controlle= r can use NETCONF as-is for the PULL model.
Whether NETCONF notif= ications are sufficient or the desired solution
to support a PUSH= model is a valid issue -- but a general issue for controllers,
n= ot specific to the 'mount' draft.

=A0
What triggered this discussions were statements of the form "YANG does=
not allow to do X" which I think is not correct since YANG really is not the issue. The mount work is extending/modifying/$(your-verb-here)
the _architecture_ of NETCONF and YANG. It is not clear which WG is
responsible for the underlying architecture. RFC 6244 was produced by
NETMOD but then it describes more the framework and not the underlying
architectural model (what Randy Presuhn I think calls the meta
model). Perhaps we need to work on an architecture at some point in
time, pretty much like we needed to define an architecture for SNMP at
some point in time. The work on JSON encoding and the mount proposal
clearly indicates that certain architectural assumptions are implicit
and that leads to discussions that are difficult to close until we
agree on an architecture.

Who said history does not repeat?

/js


Andy

=A0

--
Juergen Schoenwaelder=A0 =A0 =A0 =A0 =A0 =A0Jacobs University Bremen gGmbH<= br> Phone: +49 421 200 3587=A0 =A0 =A0 =A0 =A0Campus Ring 1, 28759 Bremen, Germ= any
Fax:=A0 =A0+49 421 200 3103=A0 =A0 =A0 =A0 =A0<http://www.jacobs-university.de/&= gt;

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

--001a11c1337084c77e05055333e4-- From nobody Mon Oct 13 16:09:28 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6E41A1A34 for ; Mon, 13 Oct 2014 16:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erviG8haRYdM for ; Mon, 13 Oct 2014 16:09:24 -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 075221A0052 for ; Mon, 13 Oct 2014 16:09:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5163; q=dns/txt; s=iport; t=1413241764; x=1414451364; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ZtHyENPP/h2W5CiJoDuJSEIGs5X1kgUKelyr9/TYG1g=; b=LcSe5kMsfhEjAFFOGdWpW1GBa4izclBVkQoiyDXSyemQhQQrEsp2JPJN nE++LXgBIHMbru8++q9IHXkpl798zUHOPTvvuSwO8arcZV9ctvBNorwUy r9yl9zUGkK5I7/6d8zJ81l6kTKBdFM82Gj7YLjhi07n/PcDKd3fp/mfAo M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFALBaPFStJA2J/2dsb2JhbABYA4MOU1zLO4dRAoEhFgF9hAIBAQEDATo/BQkCAgEIDgICAwMKFBAbFxcOAgQODYguCMUiAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwSPaSchEAcRgxyBHgWReY0AhnOJcoN+g3eBckKBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,714,1406592000"; d="scan'208";a="362974163" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-5.cisco.com with ESMTP; 13 Oct 2014 23:09:23 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s9DN9N7S031716 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Oct 2014 23:09:23 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.41]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Mon, 13 Oct 2014 18:09:22 -0500 From: "Eric Voit (evoit)" To: Juergen Schoenwaelder Thread-Topic: [netmod] New revision of YANG mount draft Thread-Index: AQHP5NSnXWBBH+aajkuz6A/yEBcVLJwuAk1QgAC+AAD//8MB0A== Date: Mon, 13 Oct 2014 23:09:22 +0000 Message-ID: References: <20141010210934.GB80385@elstar.local> <20141010215341.GD80385@elstar.local> <20141013192248.GA68615@elstar.local> In-Reply-To: <20141013192248.GA68615@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.134.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/EFKR7b88SVyykGMyI6aLJUeLDsk Cc: "netmod@ietf.org" Subject: Re: [netmod] New revision of YANG mount draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Oct 2014 23:09:26 -0000 > From: Juergen Schoenwaelder, October 13, 2014 3:23 PM >=20 > On Mon, Oct 13, 2014 at 04:26:55PM +0000, Eric Voit (evoit) wrote: > > > From: Juergen Schoenwaelder, October 10, 2014 5:54 PM > > > > > > I still fail to see how all this falls out of RFC 6020. > > > > If by falling out you mean 'in conflict with', then I would agree that = there are > not backwards compatibility issues with RFC 6020 section 6 syntax. This = was by > design. > > > > However I believe Alex' and Jan's concerns are with Section 5.1 of RFC = 6020. > This section includes statements such as: "For a module or submodule to > reference definitions in an external module, the external module MUST be > imported." > > > > Bringing in targeted nodes and subtrees need not require visibility int= o the full > submodule where the authoritative copy of the object might reside. > > >=20 > There is anyxml in YANG 1.0 and there is a proposal for anydata in YANG 1= .1. > > > > I see protocol discussion in draft-clemm-netmod-mount-02.txt (which > > > is needed for what you want to do and likely even incomplete) but > > > then the NETMOD WG is not about protocol work but about the data > > > modeling language YANG and data models. In fact, my reading of the > > > I-D is that you do not request to change anything in YANG at all - > > > all you propose is to define a few extensions and a data model. > > > > The 'on-demand' Mount does not need any protocol work. It is the easie= st, > and is looking to standardize needed several syntax extensions. This typ= e of > Mount is what is implemented in OpenDaylight today. > > >=20 > I am not sure. Can I run all NETCONF protocol operations transparently ac= ross > these mount points? I doubt it. For the use cases in the requirements document, the applications/use cases = are for the "read only" type of Mount. (I.e., I am not looking for the ful= l set of NETCONF protocol operations. I would rather have write operations= go through existing/embedded data consistency protections.) > What you introduce is a "partitioning" of a datastore that does not > architecturally exist so far. Does this lead to a new type of datastore o= r can I > partition any datastore? How does this partitioning interact with ephemer= al > datastores discussed in I2RS? I believe there are serious _architectural_ > questions that need to be discussed and depending on how they are resolve= d, > there may be more or less protocol work needed. Rather than partitioning, I actually see that this is more of a merging of = datastores across devices. The reality is that there are multiple datastor= e instances across the network, and some of us are trying to break down the= physical barriers which keep them separate -- at least from the point of v= iew of some types of applications. (These types of applications are those= which desire to view various sets of network elements as a cloud.) In any case, these are exactly the types of dialogs the drafts are trying t= o kick-start. Today's 'Mount' implementations built in Open Source forums = will be much poorer if they lack the types of due-diligence the IETF can dr= ive here. > What triggered this discussions were statements of the form "YANG does no= t > allow to do X" which I think is not correct since YANG really is not the = issue. The > mount work is extending/modifying/$(your-verb-here) > the _architecture_ of NETCONF and YANG. It is not clear which WG is > responsible for the underlying architecture. RFC 6244 was produced by NET= MOD > but then it describes more the framework and not the underlying architect= ural > model (what Randy Presuhn I think calls the meta model). Perhaps we need = to > work on an architecture at some point in time, pretty much like we needed= to > define an architecture for SNMP at some point in time. The work on JSON > encoding and the mount proposal clearly indicates that certain architectu= ral > assumptions are implicit and that leads to discussions that are difficult= to close > until we agree on an architecture. This is completely reasonable to me. RFC6244 page 14 asserts a device boun= dary which has been surpassed by reality. YANG already is being applied fo= r more than this. =20 In the future I expect YANG models and syntax which to provide for multi-de= vice abstractions. And we shouldn't be limited to just NETCONF transport. = =20 I recognize that the IETF hasn't partitioned the problem in quite this way = before. As you point out, this is a discussion beyond just this WG. Based= on what is happening in the industry, we don't have endless cycles to solv= e this problem. I will add Benoit to this thread as the problem is one whi= ch is relevant to multiple WGs and charters -- and perhaps to new charters. Eric =20 > Who said history does not repeat? >=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 From nobody Mon Oct 13 16:37:29 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F60A1A1A52 for ; Mon, 13 Oct 2014 16:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.286 X-Spam-Level: X-Spam-Status: No, score=-15.286 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBhpdV9pQrz9 for ; Mon, 13 Oct 2014 16:37:25 -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 B352E1A00A3 for ; Mon, 13 Oct 2014 16:37:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17562; q=dns/txt; s=iport; t=1413243444; x=1414453044; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=3yC3oaJdcSTgqPomq6Tcanjcqn6LYjJBmr9OeBBeWNo=; b=OVp1L9snhJjKiXsFgh43TqkeZp5aP+/R2xPKGTVwUlxZEB6MRe/4Rxff oN9BhM7zUMxfyEZI2+TyvfVHGvFIfZtOhRVmux84+CwXUPa9wwQ1yOIHz 7wa2KzDcQizBXAC2dZhYnEOnsMNTlfoXV7VvwkmVqsgPoziC8/e3WGf7Q s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAPpgPFStJV2c/2dsb2JhbABYA4JIRlNYBMs1AQmGeVQCgRoWAX2EAwEBBAEBASpBGQICAQgQAgMNHQcbDAsUAw4CBAESCBOIIw3FJAEBAQEBAQEBAQEBAQEBAQEBAQEBARcEkBANFAwKARGDHIEeBZF5jQCGc4lyg36Dd2yBCCQcgQIBAQE X-IronPort-AV: E=Sophos;i="5.04,714,1406592000"; d="scan'208,217";a="362990807" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 13 Oct 2014 23:37:23 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s9DNbNfX001357 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Oct 2014 23:37:23 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.41]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Mon, 13 Oct 2014 18:37:23 -0500 From: "Eric Voit (evoit)" To: Andy Bierman , Juergen Schoenwaelder , "Alexander Clemm (alex)" , "netmod@ietf.org" Thread-Topic: [netmod] New revision of YANG mount draft Thread-Index: AQHP5NSnXWBBH+aajkuz6A/yEBcVLJwuAk1QgAC+AACAAAeLAP//5Cjg Date: Mon, 13 Oct 2014 23:37:22 +0000 Message-ID: References: <20141010210934.GB80385@elstar.local> <20141010215341.GD80385@elstar.local> <20141013192248.GA68615@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.134.135] Content-Type: multipart/alternative; boundary="_000_EF64FF31F4C4384DBCE5D513A791C2B120A45949xmbalnx11ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/amEMybdC-E6ey1ZEQnrZ55RK3gI Subject: Re: [netmod] New revision of YANG mount draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 13 Oct 2014 23:37:27 -0000 --_000_EF64FF31F4C4384DBCE5D513A791C2B120A45949xmbalnx11ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Andy Bierman, October 13, 2014 3:50 PM This was my concern from the start. I think the mounted data is now read-o= nly so YANG datastore validation does not apply. Yes, read-only meets the needs of the use cases in the requirements = draft. For now hopefully existing validation mechanisms can handle feedbac= k towards the authoritative owner of an object. I do not want to partition the datastore. This would require a big change = to many documents (including YANG). I can see that there might be some data models where it would be useful to collect the info from all the serve= rs into one container within the controller NBI, but this is more of a proxy s= ervice than a mid-level manager service. I would expect the controller to provide its own northbound data models, that did aggregation, topN reporting, etc. There are many defacto multi-device controllers embedded within exis= ting network protocols (VRRP, ICCP, etc.). These controllers have overlapp= ing domains of interest. These controllers are perceived as 'real-time'. = They should not be seen as proxy as they create their own info based on the= underlying device abstractions/state. YANG syntax is an excellent way to= talk with these network embedded controllers. The controller can use NETCONF as-is for the PULL model. Whether NETCONF notifications are sufficient or the desired solution to support a PUSH model is a valid issue -- but a general issue for control= lers, not specific to the 'mount' draft. * Network elements will need to push their operational data to many = subscribers. Some implementations already use YANG syntax here. Netconf no= tifications have been demonstrated as insufficient for these applications. * Push of object changes from network elements is the only way to ge= t fast enough response time into application subscribers which exist off-bo= x. * There will be many controllers. There already are. We will not s= hrink back to just one. * We need transports other than NETCONF. Faster performance from mu= lticast Read-only object distribution is a good example of why NETCONF migh= t not be the only answer. Eric What triggered this discussions were statements of the form "YANG does not allow to do X" which I think is not correct since YANG really is not the issue. The mount work is extending/modifying/$(your-verb-here) the _architecture_ of NETCONF and YANG. It is not clear which WG is responsible for the underlying architecture. RFC 6244 was produced by NETMOD but then it describes more the framework and not the underlying architectural model (what Randy Presuhn I think calls the meta model). Perhaps we need to work on an architecture at some point in time, pretty much like we needed to define an architecture for SNMP at some point in time. The work on JSON encoding and the mount proposal clearly indicates that certain architectural assumptions are implicit and that leads to discussions that are difficult to close until we agree on an architecture. Who said history does not repeat? /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 --_000_EF64FF31F4C4384DBCE5D513A791C2B120A45949xmbalnx11ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From: Andy Bie= rman, October 13, 2014 3:50 PM
<snip>

 

This was my concern from the start.  I think th= e mounted data is now read-only

so YANG datastore validation does not apply.

 

<Eric> Yes, read-on= ly meets the needs of the use cases in the requirements draft.  For no= w hopefully existing validation mechanisms can handle feedback towards the authoritative owner of an object.

 <= /p>

I do not want to partition the datastore.  This= would require a big change to

many documents (including YANG).  I can see tha= t there might be some

data models where it would be useful to collect the = info from all the servers

into one container within the controller NBI, but th= is is more of a proxy service

than a mid-level manager service.  I would expe= ct the controller to provide

its own northbound data models, that did aggregation= , topN reporting, etc.

 <= /p>

<Eric> There are ma= ny defacto multi-device controllers embedded within existing network protoc= ols (VRRP, ICCP, etc.).  These controllers have overlapping domains of interest.  These controllers are perceived as ‘real-timeR= 17;.  They should not be seen as proxy as they create their own info b= ased on the underlying device abstractions/state.   YANG syntax i= s an excellent way to talk with these network embedded controllers.

 

The controller can use NETCONF as-is for the PULL mo= del.

Whether NETCONF notifications are sufficient or the = desired solution

to support a PUSH model is a valid issue -- but a ge= neral issue for controllers,

not specific to the 'mount' draft.

 

<Eric>

·      = ;  Network elements = will need to push their operational data to many subscribers. Some implemen= tations already use YANG syntax here.  Netconf notifications have been demonstrated as insufficient for these applications.<= /span>

·      = ;  Push of object ch= anges from network elements is the only way to get fast enough response tim= e into application subscribers which exist off-box.

·        There will be man= y controllers.  There already are.  We will not shrink back to ju= st one. 

·        We need transport= s other than NETCONF.  Faster performance from multicast Read-only obj= ect distribution is a good example of why NETCONF might not be the only answer.

 <= /p>

Eric

 

What triggered this discussions were statements of t= he form "YANG does
not allow to do X" which I think is not correct since YANG really is not the issue. The mount work is extending/modifying/$(your-verb-here)
the _architecture_ of NETCONF and YANG. It is not clear which WG is
responsible for the underlying architecture. RFC 6244 was produced by
NETMOD but then it describes more the framework and not the underlying
architectural model (what Randy Presuhn I think calls the meta
model). Perhaps we need to work on an architecture at some point in
time, pretty much like we needed to define an architecture for SNMP at
some point in time. The work on JSON encoding and the mount proposal
clearly indicates that certain architectural assumptions are implicit
and that leads to discussions that are difficult to close until we
agree on an architecture.

Who said history does not repeat?

/js

 

 

Andy

 

 


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

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

 

--_000_EF64FF31F4C4384DBCE5D513A791C2B120A45949xmbalnx11ciscoc_-- From nobody Mon Oct 13 17:52:35 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA0601A1A7F for ; Mon, 13 Oct 2014 17:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZRxUEgz7PA4 for ; Mon, 13 Oct 2014 17:52:31 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 115821A004C for ; Mon, 13 Oct 2014 17:52:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7268; q=dns/txt; s=iport; t=1413247951; x=1414457551; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=dwXEGgngfCq9maBFg/QvfYEdfj7HX2IeOO4cpVypQEk=; b=cNu7igppFZWom/gSg7zQYNpUWNsG1IMrusUmQJGB86QaPwhgdLd+6VWQ kDYYlkm8QW+Al5+rnmSiVbTLP3diMqVcOpmcia7j8jNLbJsUZ08T8SO9v TexIawuw6xtSHGNn/aG+bH+5wHX3tecU1/yCX5Obe+sYKG8q9mMjeixeu A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FAIBzPFStJA2F/2dsb2JhbABYA4MOU1gEy0eHUQKBFRYBfYQCAQEBAwE6PwwCAgIBCA4CAQEDAQEBCgISCQcbFxQDBggCBAENBQgTiBsIxU0BAQEBAQEBAQEBAQEBAQEBAQEBAQEXBJAQIRAHBguDHIEeBZF5jQCQZYN+g3dsgUiBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,714,1406592000"; d="scan'208";a="86650675" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-7.cisco.com with ESMTP; 14 Oct 2014 00:52:15 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s9E0qE7k004800 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Oct 2014 00:52:14 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.163]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Mon, 13 Oct 2014 19:52:14 -0500 From: "Alexander Clemm (alex)" To: Juergen Schoenwaelder , "Eric Voit (evoit)" Thread-Topic: [netmod] New revision of YANG mount draft Thread-Index: AQHP40Rf8kMXz8u2QICzU6EjzD0qC5wopeSAgAGEYAD//6x3sIAAX9yAgARbs4CAADEkAP//+2Dw Date: Tue, 14 Oct 2014 00:52:14 +0000 Message-ID: References: <20141010210934.GB80385@elstar.local> <20141010215341.GD80385@elstar.local> <20141013192248.GA68615@elstar.local> In-Reply-To: <20141013192248.GA68615@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.218.195] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/PW14KclCEFL6Qv3l0o2izdAXbqE Cc: "netmod@ietf.org" Subject: Re: [netmod] New revision of YANG mount draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2014 00:52:34 -0000 Hi Juergen, (several threads to respond to; Eric already provided responses to a lot of= the items, here just a few summary items from my perspective) Re: what technical details we think should be standardized: - The first aspect is the YANG extension that allows users to define mountp= oints (to logically incorporate subtrees from a remote datastore under a da= ta node). This can be done as part of a YANG module, i.e. is data model re= lated. =20 - The second aspect is a YANG data model that allows to monitor and manage = a "mount topology". This addresses the system management aspects of this c= oncept, generally not of concern to the applications that want to simply ac= cess the datastore, but required for a "complete" solution. Again, this ca= n be done as part of a YANG module, i.e. is data model related. =20 - The third aspect concerns the ability to subscribe to updates to a YANG d= atatree, and "push" those updates. This is more general than mount itself = and should presumably be separated into a separate draft. Subscriptions ca= n be represented as a configurable data model. Likewise, push can occur th= rough notifications, definable as part of a data model related. So, that o= ne too is data model related. (It is conceivable to also introduce differe= nt transports here, which would be discussion for a transport forum; howeve= r, our intent was to address these within the existing framework.) =20 Re: overall architecture, you are bringing up an interesting point that pro= bably needs visiting. RFC 6244, in section 3.1, clearly depicts the bounda= ry of the server as one device. It also suggests that the datastore does n= ot reach beyond the device boundaries (datastore is actually not depicted, = but config database and "system software components" - presumably for the c= onfig data). This is why we believe the mount capability is needed - to al= low the datastore to reach beyond those boundaries. If this involves exten= ding the architecture, then so be it. Worth mentioning along the same line= s, since RFC 6244 assumes that YANG will be always used in conjunction with= Netconf: Really, we would like to consider Netconf just one particular tra= nsport / set of services that can operate on / interact with a datastore, g= eared towards configuration and fulfillment-related use cases. That should= not rule out the possibility to apply other transports and services - such= as RESTconf (the possibility for which is not considered in the RFC), and = going forward possibly other transports/ interfaces, that for example focus= on pushing datastore information and operational data for applications whi= ch today might use SNMP. =20 Regarding making this transparent for all Netconf operations: The importan= t aspect and primary focus of the use case lies in providing an ability to = retrieve remote information. The motivation behind all this is not to prov= id "ACID" style management transactions across the network - in fact, we be= lieve that for many applications a "BASE" style of management is preferrabl= e and more appropriate, in which transactional guarantees, ability to rollb= ack,etc, are not provided as long as state becomes eventually consistent. T= his is also reflected in the companion requirements spec. We do not want t= o be bogged down in the aspects that would be required to make ACID work. = While we believe that "simple" configuration (not including transactions sp= anning multiple items) is achievable, we are happy to "scale down" the moun= t concept accordingly and leave transactionality or even configuration as a= whole out of scope. =20 --- Alex -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Monday, October 13, 2014 12:23 PM To: Eric Voit (evoit) Cc: Alexander Clemm (alex); netmod@ietf.org Subject: Re: [netmod] New revision of YANG mount draft On Mon, Oct 13, 2014 at 04:26:55PM +0000, Eric Voit (evoit) wrote: > > From: Juergen Schoenwaelder, October 10, 2014 5:54 PM > >=20 > > I still fail to see how all this falls out of RFC 6020. >=20 > If by falling out you mean 'in conflict with', then I would agree that th= ere are not backwards compatibility issues with RFC 6020 section 6 syntax. = This was by design. =20 >=20 > However I believe Alex' and Jan's concerns are with Section 5.1 of RFC 60= 20. This section includes statements such as: "For a module or submodule= to reference definitions in an external module, the external module MUST b= e imported." >=20 > Bringing in targeted nodes and subtrees need not require visibility into = the full submodule where the authoritative copy of the object might reside. >=20 There is anyxml in YANG 1.0 and there is a proposal for anydata in YANG 1.1= . > > I see protocol discussion in draft-clemm-netmod-mount-02.txt (which=20 > > is needed for what you want to do and likely even incomplete) but=20 > > then the NETMOD WG is not about protocol work but about the data=20 > > modeling language YANG and data models. In fact, my reading of the=20 > > I-D is that you do not request to change anything in YANG at all -=20 > > all you propose is to define a few extensions and a data model. >=20 > The 'on-demand' Mount does not need any protocol work. It is the easiest= , and is looking to standardize needed several syntax extensions. This typ= e of Mount is what is implemented in OpenDaylight today. =20 >=20 I am not sure. Can I run all NETCONF protocol operations transparently acro= ss these mount points? I doubt it. =20 What you introduce is a "partitioning" of a datastore that does not archite= cturally exist so far. Does this lead to a new type of datastore or can I p= artition any datastore? How does this partitioning interact with ephemeral = datastores discussed in I2RS? I believe there are serious _architectural_ q= uestions that need to be discussed and depending on how they are resolved, = there may be more or less protocol work needed. What triggered this discussions were statements of the form "YANG does not = allow to do X" which I think is not correct since YANG really is not the is= sue. The mount work is extending/modifying/$(your-verb-here) the _architecture_ of NETCONF and YANG. It is not clear which WG is respons= ible for the underlying architecture. RFC 6244 was produced by NETMOD but t= hen it describes more the framework and not the underlying architectural mo= del (what Randy Presuhn I think calls the meta model). Perhaps we need to w= ork on an architecture at some point in time, pretty much like we needed to= define an architecture for SNMP at some point in time. The work on JSON en= coding and the mount proposal clearly indicates that certain architectural = assumptions are implicit and that leads to discussions that are difficult t= o close until we agree on an architecture. Who said history does not repeat? /js --=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 Mon Oct 13 17:58:20 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20DC31A1A6D for ; Mon, 13 Oct 2014 17:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fT21UpQk6Ku for ; Mon, 13 Oct 2014 17:58:17 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3ECB1A1A4C for ; Mon, 13 Oct 2014 17:58:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1523; q=dns/txt; s=iport; t=1413248297; x=1414457897; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=WawXrsbpWj3wKjvk7VaUg592nTUz7V0C4/42eHYfkxw=; b=Cj4AdiOC4fSm3LhCpnkqrn2l8UKZZxiqKHU77N78JRgCozwurRQyIcVC el6qvaUSQFT0cSfOz/iLl4Wq7HN9HPFAIyiYtm+qExAgRG2bkeQ7l3/5y FZ2/EHYNd96lZs17fdv+IQnEb/eH9QWFWrPvF34LrbbXNPcVZ/xHq1w44 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAPRzPFStJA2K/2dsb2JhbABbgw6BL9MYAoEVFgF9hAMBAQQ6PxACAQgOFBQQMiUCBAENDYg2xU4BAQEBAQEBAQEBAQEBAQEBAQEBAQEXkBQxBwKDK4EeAQSReaFjg3eCNIECAQEB X-IronPort-AV: E=Sophos;i="5.04,714,1406592000"; d="scan'208";a="362790470" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-1.cisco.com with ESMTP; 14 Oct 2014 00:58:17 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s9E0wGHi007967 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Oct 2014 00:58:16 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.163]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Mon, 13 Oct 2014 19:58:16 -0500 From: "Alexander Clemm (alex)" To: Qin Wu , Juergen Schoenwaelder , "Jan Medved (jmedved)" Thread-Topic: [netmod] New revision of YANG mount draft Thread-Index: AQHP40Rf8kMXz8u2QICzU6EjzD0qC5wopeSAgAGEYAD//6x3sIACb4qAgAKFfoA= Date: Tue, 14 Oct 2014 00:58:15 +0000 Message-ID: References: <20141010210934.GB80385@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.218.195] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/6Hg787tYOi3QI9urmH_vscd_kUw Cc: "netmod@ietf.org" Subject: Re: [netmod] New revision of YANG mount draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2014 00:58:19 -0000 Hi Qin, ... [Qin] Interesting, Is this idea about datastore data synchronization in dif= ferent levels. One subset of datastore data in lower level can be nested in= to a datastore in higher level and inserted as mounting point. Datastore da= ta in lower level doesn't need to be unfolded or exposed to more higher lev= el client that is on top of the controller. Mounting point provide a refere= nce point in the remote datastore to retrieve the data. Network topo inform= ation gathering can be a good example for such data retrieving.=20 Exactly [Qin] But it is not clear to me how this can support multi-tenancy when different= tenant has different view of network topo. In addition, where to insert data from remote datastore in the local datast= ore is not very clear as well.=20 Where to insert data is specified by a YANG module, implemented by t= he client, which specifies the mount point i.e. data nodes in the datastore= structure where to "insert" the remote data. =20 Multi-tenancy is not specifically addressed here, although it constitutes a= valid use case (perhaps something to spell out in the requirement draft). = You can have different client systems, each in turn with their own datasto= re, and each implementing different YANG models with different mount points= , which therefore mount different information from a server (or incorporate= them in differen ways into their own respective datastore structure). --- Alex From nobody Tue Oct 14 03:12:38 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91A451A702E for ; Tue, 14 Oct 2014 03:12: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 n2_osZElFD4Q for ; Tue, 14 Oct 2014 03:12:33 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A5921A6FFB for ; Tue, 14 Oct 2014 03:12:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id B5CED5408EF; Tue, 14 Oct 2014 12:12:30 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIwITTLo+-tt; Tue, 14 Oct 2014 12:12:25 +0200 (CEST) Received: from localhost (unknown [172.29.2.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 798C654071C; Tue, 14 Oct 2014 12:12:25 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20141013141959.GC53210@elstar.local> References: <20141013110516.25281.32846.idtracker@ietfa.amsl.com> <0031A8ED-D33E-459C-A648-8595821EE6FB@nic.cz> <20141013141959.GC53210@elstar.local> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Tue, 14 Oct 2014 12:12:24 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Ol-e2Ou21cYJZZa9SSSwmEfhF3U Cc: NETMOD Working Group Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-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, 14 Oct 2014 10:12:36 -0000 Juergen Schoenwaelder writes: > Lada, > > thanks for the update. I think we still have open issues: > > - Namespace name. The YANG namespace statement declares a URI to be > used as a namespace while you propose to use module names in JSON. > This makes round-trip conversions more difficult that needed. I do > not think we resolved this issue. Lets not reiterate it but lets > also not declare it resolved. ;-) I believe you are the only one who wants to clutter JSON text with namespace URIs. Consider, for example, how awkward instance-identifiers would be. Namespace URI definition is in YANG only for the sake of XML. Round trip conversions are not difficult (see pyang), the only caveat being that you need access to the data model, but this is inevitable anyway. > > - The draft says YANG lists are always mapped to unordered arrays in > JSON. It is unclear how this works with lists ordered-by user, e.g. > a packet filter list where the order matters. I understand that > assuming no order is also an I-JSON requirement. Unfortunately, we > do seem to have ordered data to deal with. No, this is not what the draft says. JSON arrays are ordered, so user-ordered lists are supported. The draft just says that the order of members in a list *entry* is arbitrary. This means list keys needn't precede other siblings in the entry as it is required in XML. > > - I am not sure I understand this logic: > > This document defines no mapping between the contents of JSON- and > XML-encoded anyxml instances. It is not necessary because anyxml > contents are not subject to YANG-based validation (see sec. 7.10 in > [RFC6020]). > > Are you saying things outside of validation can be simply ignored? > It is not totally clear why this is the case. I have something like > Kent's configlets in mind for example. The central theme of the draft is no more XML-JSON translation, it just defines JSON encoding is a similar was as the "XML Mapping Rules" sections in RFC 6020 do for XML. So section 5.5 specifies the valid encoding of an anyxml instance. If we have "anyxml foo;", then we know "foo": [null, [1, 2, true]] is a valid instance. Why should the draft try to specify the translation to XML? In the case of configlets, Kent might provide a specification of their encoding in both XML and JSON. > > You maybe wanted to say that anyxml data should be rendered as much > as possible using the various JSON types but how this is done is > implementation specific. Since anyxml itself is essentially open > ended XML, this is no worse that using anyxml in the first place. I am not sure I understand, the draft just says that an anyxml instance is encoded as a name/value pair and that the value part has to be a valid JSON value. The sentence you cited is related to sec. 3 which relies on JSON->XML mapping for instance validation - and for this purpose it is really irrelevant how anyxml content is translated as long as we start with valid JSON and end up with valid XML. > > - It is not clear whether it is legal to encode everything into a > string. This was discussed some time ago since essentially YANG's > type system is based in literal string representations. What do you mean? For example, sec. 6.3 clearly says that boolean values are encoded as JSON literal names 'true' and 'false', i.e. no string. The same is true for numbers except for 64-bit ones. I don't agree that YANG type system requires string encoding of the values. > > - Related to the above: Do we really treat "bar": 13.5 as an encoding > error? What is gained by doing this in comparison to simply convert Yes. The client says it is a number so why should the server coerce it to a string on its own? > to a string? I heard that some implementations do kind of ignore the > JSON type in order to improve chances of interoperability. Do you have an example how this could lead to interoperability problems? > > Does it make sense to track issues somewhere? Any suggestion? The draft is now being developed as a project on github (https://github.com/yang-json), so we can track issues there but I think we agreed not do that. One general note: I think we need to clarify the purpose of this document. My aim has been to find an encoding of YANG concepts in a way that's appropriate and natural for JSON. Your preference seems to be to bend JSON encoding so that it is as close to XML as possible. The correspondence between JSON and XML encoding of the same data is important but it is not the primary goal. I assume some systems or deployments can use exclusively JSON without performing any translations. Lada > > /js > > On Mon, Oct 13, 2014 at 01:08:54PM +0200, Ladislav Lhotka wrote: >> Hi, >> >> this revision should address all issues and comments raised since -00. Major changes are: >> >> o Metadata encoding was moved to a separate I-D, draft-lhotka-netmod-yang-metadata. >> >> o JSON encoding is now defined directly rather than via XML-JSON >> mapping. >> >> o The rules for namespace encoding has changed. This affect both >> node instance names and instance-identifiers. >> >> o I-JSON-related changes. The most significant is the string >> encoding of 64-bit numbers. >> >> o When validating union type, the partial type info present in JSON >> encoding is taken into account. >> >> o Added section about I-JSON compliance. >> >> o Updated the example in appendix. >> >> o Wrote Security Considerations. >> >> o Removed IANA Considerations as there are none. >> > > -- > 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 Tue Oct 14 05:40:05 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E71A1A87A0 for ; Tue, 14 Oct 2014 05:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, 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 qoCOFgXSFrny for ; Tue, 14 Oct 2014 05:39:58 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id A3D821A879F for ; Tue, 14 Oct 2014 05:39:58 -0700 (PDT) Received: from [192.168.1.121] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id C071228C0B94; Tue, 14 Oct 2014 08:39:56 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_B6CA4D6E-91B4-4581-993B-34DC0B0BB4BB"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: <20141013192248.GA68615@elstar.local> Date: Tue, 14 Oct 2014 08:39:50 -0400 Message-Id: <51D3D2DB-14C3-49BB-AD88-365ADAD1BA43@lucidvision.com> References: <20141010210934.GB80385@elstar.local> <20141010215341.GD80385@elstar.local> <20141013192248.GA68615@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/78Eit6DE4mNsao-uvo20qply_vo Cc: "netmod@ietf.org" Subject: Re: [netmod] New revision of YANG mount draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2014 12:40:01 -0000 --Apple-Mail=_B6CA4D6E-91B4-4581-993B-34DC0B0BB4BB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii [netmod Chair hat off] > On Mon, Oct 13, 2014 at 04:26:55PM +0000, Eric Voit (evoit) wrote: >>> From: Juergen Schoenwaelder, October 10, 2014 5:54 PM >>>=20 >>> I still fail to see how all this falls out of RFC 6020. >>=20 >> If by falling out you mean 'in conflict with', then I would agree = that there are not backwards compatibility issues with RFC 6020 section = 6 syntax. This was by design. =20 >>=20 >> However I believe Alex' and Jan's concerns are with Section 5.1 of = RFC 6020. This section includes statements such as: "For a module or = submodule to reference definitions in an external module, the external = module MUST be imported." >>=20 >> Bringing in targeted nodes and subtrees need not require visibility = into the full submodule where the authoritative copy of the object might = reside. >>=20 >=20 > There is anyxml in YANG 1.0 and there is a proposal for anydata in > YANG 1.1. >=20 >>> I see protocol discussion in draft-clemm-netmod-mount-02.txt (which = is needed >>> for what you want to do and likely even incomplete) but then the = NETMOD WG >>> is not about protocol work but about the data modeling language YANG = and >>> data models. In fact, my reading of the I-D is that you do not = request to change >>> anything in YANG at all - all you propose is to define a few = extensions and a data >>> model. >>=20 >> The 'on-demand' Mount does not need any protocol work. It is the = easiest, and is looking to standardize needed several syntax extensions. = This type of Mount is what is implemented in OpenDaylight today. =20 >>=20 >=20 > I am not sure. Can I run all NETCONF protocol operations transparently > across these mount points? I doubt it. =20 >=20 > What you introduce is a "partitioning" of a datastore that does not > architecturally exist so far. That depends on what you define as architecture. This is = implemented, and in production now in a number of commercial products. = For full disclosure this is implemented in one of my products, and works = quite well. If that doesn't count as "running code" from the IETF = mantra, I don't know what is. We should use those implementations to = guide our lack of architecture rather than saying we should hold the = phone until such time as the Yang gods can construct an architectural = blueprint. Its exactly that sort of thing that has pushed people away = from the IETF. > Does this lead to a new type of > datastore or can I partition any datastore? How does this partitioning > interact with ephemeral datastores discussed in I2RS? I believe there > are serious _architectural_ questions that need to be discussed and > depending on how they are resolved, there may be more or less protocol > work needed. It does seem to do this, and we should discuss for sure. We = should also figure out a way to embrace these new ways of using Yang and = Netconf variants. We should not push them away just because they were = unforeseen by originators of Yang/Netconf. =20 > What triggered this discussions were statements of the form "YANG does > not allow to do X" which I think is not correct since YANG really is > not the issue. The mount work is extending/modifying/$(your-verb-here) > the _architecture_ of NETCONF and YANG. It is not clear which WG is > responsible for the underlying architecture. RFC 6244 was produced by > NETMOD but then it describes more the framework and not the underlying > architectural model (what Randy Presuhn I think calls the meta > model). Perhaps we need to work on an architecture at some point in > time, pretty much like we needed to define an architecture for SNMP at > some point in time. The work on JSON encoding and the mount proposal > clearly indicates that certain architectural assumptions are implicit > and that leads to discussions that are difficult to close until we > agree on an architecture. These are new use cases that people clearly want - they're = implemented in numerous places now and in many places, in code that you = and I can download and review (and run) right now. So rather than debate = which WG they go into, we should figure out how to move things forward = and embrace them or they will be "standardized" elsewhere. I will note = that the original mount draft and restconf drafts are over a year old = now. What have we been waiting for? I vote that we let Benoit worry about which WG these go into, = but ask that he find one soon. --Tom =09 >=20 > Who said history does not repeat? >=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 >=20 --Apple-Mail=_B6CA4D6E-91B4-4581-993B-34DC0B0BB4BB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUPRmXAAoJEPcO+I7eiUJZiVYP+QHbqHhn9vauuUbvKbth8lB/ Lof6CflyJ5rBhz8Ssd8GxE5xqkaHJGOhu3KmYJ5s5OmYX5ZzZbVs+Xo+ghRK/BfB 4QBoHwWEF3RCkDpWgQQSR4QMXXkAHoyUMTvH3ChDaVX/5mlTDDB5K3IACyY0Ngqf /rhzAoC2conaL7XHhjwAdif6UW2TyVgYzw7ma0kXFzZZBhvS41MdUjQacHtoH6oX LMy1mgoN/QA7NOdRLWAt4+Ff15/U9paw84fIIRVu7KQ+LH2lwN1DdKEOPKLZwbbz AQE5tujCZOHFUFhU9VXDtFcqlcYGRwjgp2KA8qKbU1w34xbUAkwqCMpiIjl4+bUp 4yVWcodR5lagrd/rpV/POfDoD13qHmg95vHIHAM9BJEhStIsf4O0Gre9do5Ic4TJ EEN5o7s0O/qghT/NFDdTw/uPkSfCOo5HFIa3chOmVYZNPf2sRdLe229PjYiOpruz LZahK5hfPphMCuZ0mWtu0giu6lYZoL9SJTzS8I/oO8nvW3Tnp8Gw38Crud+adDEF qtCYaWA0+s4GSex/9IxFXp3mZwDkOPaGiZpGRJ87sjw/s8C/B0QTEr+9DfBLvKYG 6rMRDcZJ/B09Yri3kTisHbaXzkqotHIitxHY1ctV9AOknHCiXN/5GvG0XuDV6H0D VmK1H2ni2ynhKnZxoLiH =dgHj -----END PGP SIGNATURE----- --Apple-Mail=_B6CA4D6E-91B4-4581-993B-34DC0B0BB4BB-- From nobody Tue Oct 14 05:46:34 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1216F1A87B3 for ; Tue, 14 Oct 2014 05:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, 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 fK2yDc_RbeoT for ; Tue, 14 Oct 2014 05:46:23 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id E8D811A879D for ; Tue, 14 Oct 2014 05:46:22 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 0BE601280457; Tue, 14 Oct 2014 14:46:22 +0200 (CEST) Date: Tue, 14 Oct 2014 14:46:21 +0200 (CEST) Message-Id: <20141014.144621.665517695967907814.mbj@tail-f.com> To: tnadeau@lucidvision.com From: Martin Bjorklund In-Reply-To: <51D3D2DB-14C3-49BB-AD88-365ADAD1BA43@lucidvision.com> References: <20141013192248.GA68615@elstar.local> <51D3D2DB-14C3-49BB-AD88-365ADAD1BA43@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: http://mailarchive.ietf.org/arch/msg/netmod/5K3gcubdDs5TtC3qEC-Ebnt2NA8 Cc: netmod@ietf.org Subject: Re: [netmod] New revision of YANG mount draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2014 12:46:26 -0000 "Thomas D. Nadeau" wrote: > > [netmod Chair hat off] > > > On Mon, Oct 13, 2014 at 04:26:55PM +0000, Eric Voit (evoit) wrote: > >>> From: Juergen Schoenwaelder, October 10, 2014 5:54 PM > > What you introduce is a "partitioning" of a datastore that does not > > architecturally exist so far. > > That depends on what you define as architecture. This is implemented, > and in production now in a number of commercial products. For full > disclosure this is implemented in one of my products, and works quite > well. Are you saying that your code uses the mount mechansim as described in this draft? If so, does your product implement read-write mount as described in the draft? /martin From nobody Tue Oct 14 06:28:12 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 332131A8848 for ; Tue, 14 Oct 2014 06:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, 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 zHZ-OjnEiwdK for ; Tue, 14 Oct 2014 06:28:08 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8821A8846 for ; Tue, 14 Oct 2014 06:28:08 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 736B01280098; Tue, 14 Oct 2014 15:28:07 +0200 (CEST) Date: Tue, 14 Oct 2014 15:28:07 +0200 (CEST) Message-Id: <20141014.152807.103014930228832956.mbj@tail-f.com> To: alex@cisco.com From: Martin Bjorklund In-Reply-To: References: <20141013192248.GA68615@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: http://mailarchive.ietf.org/arch/msg/netmod/c3i3E3o9XcYX8SAN0iU-vQMRUcU Cc: netmod@ietf.org Subject: Re: [netmod] New revision of YANG mount draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2014 13:28:10 -0000 Hi, "Alexander Clemm (alex)" wrote: > Hi Juergen, > (several threads to respond to; Eric already provided responses to a lot of the items, here just a few summary items from my perspective) > > Re: what technical details we think should be standardized: > > - The first aspect is the YANG extension that allows users to define > mountpoints (to logically incorporate subtrees from a remote > datastore under a data node). This can be done as part of a YANG > module, i.e. is data model related. I would generalize this one even more: a mechanism that allows users to logically incorporate subtrees from a module under a data node. I.e., what I think might be needed and would be useful to standardize is a mechansim to extended the *schema*. Note the difference; you talk about extending datastores (which I find problematic) and I talk about extending the schema. FWIW, we are using something like this in our controller application NCS. > - The second aspect is a YANG data model that allows to monitor and > manage a "mount topology". This addresses the system management > aspects of this concept, generally not of concern to the > applications that want to simply access the datastore, but > required for a "complete" solution. Again, this can be done as > part of a YANG module, i.e. is data model related. With the more general schema extension mechansim I described above, I would say that the second aspect of your proposal is a mechanism to implement these schema extensions by the concept of "mounting" (including a data model to monitor and manage this). This part seems to be pretty complex in all but the read-only use case. > - The third aspect concerns the ability to subscribe to updates to a > YANG datatree, and "push" those updates. This is more general than > mount itself and should presumably be separated into a separate > draft. Subscriptions can be represented as a configurable data > model. Likewise, push can occur through notifications, definable as > part of a data model related. So, that one too is data model > related. (It is conceivable to also introduce different transports > here, which would be discussion for a transport forum; however, our > intent was to address these within the existing framework.) Ok, but the draft doesn't actually propose a concrete mechansim. /martin From nobody Tue Oct 14 06:43:09 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DBFF1A878C for ; Tue, 14 Oct 2014 06:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CdtkPpPlTfyu for ; Tue, 14 Oct 2014 06:43: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 DFFE81A874D for ; Tue, 14 Oct 2014 06:43:05 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id AD6D48E9; Tue, 14 Oct 2014 15:43: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 1_1POI_TJGGO; Tue, 14 Oct 2014 15:43:02 +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, 14 Oct 2014 15:43:02 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4BBD220038; Tue, 14 Oct 2014 15:43:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 0YRHbs13Opox; Tue, 14 Oct 2014 15:43: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 238F420035; Tue, 14 Oct 2014 15:43:00 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 128022EF66B0; Tue, 14 Oct 2014 15:43:00 +0200 (CEST) Date: Tue, 14 Oct 2014 15:43:00 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20141014134259.GB70425@elstar.local> Mail-Followup-To: Ladislav Lhotka , NETMOD Working Group References: <20141013110516.25281.32846.idtracker@ietfa.amsl.com> <0031A8ED-D33E-459C-A648-8595821EE6FB@nic.cz> <20141013141959.GC53210@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: http://mailarchive.ietf.org/arch/msg/netmod/WbtHwez_sLwYXqiwWZsqwqcy9hc Cc: NETMOD Working Group Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-01.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, 14 Oct 2014 13:43:08 -0000 On Tue, Oct 14, 2014 at 12:12:24PM +0200, Ladislav Lhotka wrote: > Juergen Schoenwaelder writes: > > > Lada, > > > > thanks for the update. I think we still have open issues: > > > > - Namespace name. The YANG namespace statement declares a URI to be > > used as a namespace while you propose to use module names in JSON. > > This makes round-trip conversions more difficult that needed. I do > > not think we resolved this issue. Lets not reiterate it but lets > > also not declare it resolved. ;-) > > I believe you are the only one who wants to clutter JSON text with > namespace URIs. Consider, for example, how awkward instance-identifiers > would be. Namespace URI definition is in YANG only for the sake of > XML. Round trip conversions are not difficult (see pyang), the only > caveat being that you need access to the data model, but this is > inevitable anyway. Yes, I prefer to be able to do conversions without having to have the data model at hand. You like to design things such that it is required to have the data model available for any conversion. It seems everything else follows from this. > > - The draft says YANG lists are always mapped to unordered arrays in > > JSON. It is unclear how this works with lists ordered-by user, e.g. > > a packet filter list where the order matters. I understand that > > assuming no order is also an I-JSON requirement. Unfortunately, we > > do seem to have ordered data to deal with. > > No, this is not what the draft says. JSON arrays are ordered, so > user-ordered lists are supported. The draft just says that the order > of members in a list *entry* is arbitrary. This means list keys needn't > precede other siblings in the entry as it is required in XML. OK. > > - I am not sure I understand this logic: > > > > This document defines no mapping between the contents of JSON- and > > XML-encoded anyxml instances. It is not necessary because anyxml > > contents are not subject to YANG-based validation (see sec. 7.10 in > > [RFC6020]). > > > > Are you saying things outside of validation can be simply ignored? > > It is not totally clear why this is the case. I have something like > > Kent's configlets in mind for example. > > The central theme of the draft is no more XML-JSON translation, it just > defines JSON encoding is a similar was as the "XML Mapping Rules" > sections in RFC 6020 do for XML. So section 5.5 specifies the valid > encoding of an anyxml instance. > > If we have "anyxml foo;", then we know > > "foo": [null, [1, 2, true]] > > is a valid instance. Why should the draft try to specify the translation to XML? > > In the case of configlets, Kent might provide a specification of their > encoding in both XML and JSON. > > > You maybe wanted to say that anyxml data should be rendered as much > > as possible using the various JSON types but how this is done is > > implementation specific. Since anyxml itself is essentially open > > ended XML, this is no worse that using anyxml in the first place. > > I am not sure I understand, the draft just says that an anyxml instance > is encoded as a name/value pair and that the value part has to be a valid > JSON value. The sentence you cited is related to sec. 3 which relies on > JSON->XML mapping for instance validation - and for this purpose it is > really irrelevant how anyxml content is translated as long as we start > with valid JSON and end up with valid XML. I can agree on "the draft just says that an anyxml instance is encoded as a name/value pair and that the value part has to be a valid JSON value." - where I am having trouble is the reasoning given. Perhaps this does the job equally well: OLD An anyxml instance is translated to a name/value pair. The value can be of any valid JSON type, i.e. an object, array, number, string or any of the literals 'true', 'false' and 'null'. This document defines no mapping between the contents of JSON- and XML-encoded anyxml instances. It is not necessary because anyxml contents are not subject to YANG-based validation (see sec. 7.10 in [RFC6020]). NEW An anyxml instance is translated to a name/value pair. The value can be of any valid JSON type, i.e. an object, array, number, string or any of the literals 'true', 'false' and 'null'. How the anyxml content is mapped to JSON types is implementation specific. > > - It is not clear whether it is legal to encode everything into a > > string. This was discussed some time ago since essentially YANG's > > type system is based in literal string representations. > > What do you mean? For example, sec. 6.3 clearly says that boolean values > are encoded as JSON literal names 'true' and 'false', i.e. no > string. The same is true for numbers except for 64-bit ones. > > I don't agree that YANG type system requires string encoding of the > values. The question is whether you mandate that the encoder has type information available when rendering the JSON structure and whether you mandate that a receiver fails if the JSON type does not match its expectations (given the YANG data model it knows about). It again is a question whether we mandate type information to be available or whether a sender is allowed to send "1234" as "1234" in case no type information is available. > > > > - Related to the above: Do we really treat "bar": 13.5 as an encoding > > error? What is gained by doing this in comparison to simply convert > > Yes. The client says it is a number so why should the server coerce it > to a string on its own? Because the API used internally is not using the JSON type system but a type system that stems from YANG. JSON is an encoding, not more. And the union type shows that to follow what YANG does, you have to stringify values or you have to drop values because of type conflicts. I think I recall that at least one RESTCONF implementation converts to strings instead of raising encoding errors. > > to a string? I heard that some implementations do kind of ignore the > > JSON type in order to improve chances of interoperability. > > Do you have an example how this could lead to interoperability problems? There are implementations today where the lower layers doing the encoding/decoding work do not have access to YANG type information. If we require knowledge of data models by the encoder, we surely raise the bar for such implementations. The fact that pyang can do things easily (which is no surprise since it is a YANG compiler) does not mean all implementations can do this easily. > > Does it make sense to track issues somewhere? > > Any suggestion? The draft is now being developed as a project on github > (https://github.com/yang-json), so we can track issues there but I think > we agreed not do that. I do not care much _how_ issues are tracked. I am fine with letting those pick a format who will finally maintain the issue tracker. > One general note: I think we need to clarify the purpose of this > document. My aim has been to find an encoding of YANG concepts in a way > that's appropriate and natural for JSON. Your preference seems to be to > bend JSON encoding so that it is as close to XML as possible. > > The correspondence between JSON and XML encoding of the same data is > important but it is not the primary goal. I assume some systems or > deployments can use exclusively JSON without performing any > translations. The basic question is whether we require YANG type information to be present at all JSON encoders or not (and whether JSON type information has to be taken authoritative by the decoder). I think this is where we differ and the rest follows from that. /js PS: I just found that the I-D does not talk about uint32, likely simply an omission. -- 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 Oct 14 08:32:19 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0B81A891B for ; Tue, 14 Oct 2014 08:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 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, RP_MATCHES_RCVD=-0.786] 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 F69R26H1cw0i for ; Tue, 14 Oct 2014 08:32:13 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 297DD1A8916 for ; Tue, 14 Oct 2014 08:32:13 -0700 (PDT) Received: from [172.29.2.202] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id 8A84A140AA2; Tue, 14 Oct 2014 17:32:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1413300731; bh=mJZFNOLqWxuJyX83+p6kB+PrObazw2/OFS98d1Jg4vg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=kZFXKfRJEj0mIQ8c9gksdhItE2ycR9874TPVlP5fFK42MElb5wySik1rwPZaS/vKW pOdlU915l3Oqn3xG9d9h9kgMNqXpNmKgPsoRd/kyuSKoTcSu+tngkv31d5CoA3Mrvm LPde+aYWKibAgeIb2aquXRSDUPyrAwgUnM5r+dVk= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <20141014134259.GB70425@elstar.local> Date: Tue, 14 Oct 2014 17:32:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141013110516.25281.32846.idtracker@ietfa.amsl.com> <0031A8ED-D33E-459C-A648-8595821EE6FB@nic.cz> <20141013141959.GC53210@elstar.local> <20141014134259.GB70425@elstar.local> To: =?windows-1252?Q?J=FCrgen_Sch=F6nw=E4lder?= X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/1mY7QSOofrJYUdhA0ALDsF1g_cM Cc: NETMOD Working Group Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-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, 14 Oct 2014 15:32:15 -0000 On 14 Oct 2014, at 15:43, Juergen Schoenwaelder = wrote: > On Tue, Oct 14, 2014 at 12:12:24PM +0200, Ladislav Lhotka wrote: >> Juergen Schoenwaelder writes: >>=20 >>> Lada, >>>=20 >>> thanks for the update. I think we still have open issues: >>>=20 >>> - Namespace name. The YANG namespace statement declares a URI to be >>> used as a namespace while you propose to use module names in JSON. >>> This makes round-trip conversions more difficult that needed. I do >>> not think we resolved this issue. Lets not reiterate it but lets >>> also not declare it resolved. ;-) >>=20 >> I believe you are the only one who wants to clutter JSON text with >> namespace URIs. Consider, for example, how awkward = instance-identifiers >> would be. Namespace URI definition is in YANG only for the sake of >> XML. Round trip conversions are not difficult (see pyang), the only >> caveat being that you need access to the data model, but this is >> inevitable anyway. >=20 > Yes, I prefer to be able to do conversions without having to have the > data model at hand. You like to design things such that it is required > to have the data model available for any conversion. It seems > everything else follows from this. It is not about conversions, I can imagine an implementation that = doesn=92t touch XML at all. The right question for me is: If we have = YANG and forget about XML, what is the most natural representation of = instance data in JSON? The answer probably won=92t be that numbers be = encoded as strings. Actually, I think it is a testimony to YANG design = that the JSON encoding can be done quite nicely. >>> - I am not sure I understand this logic: >>>=20 >>> This document defines no mapping between the contents of JSON- = and >>> XML-encoded anyxml instances. It is not necessary because anyxml >>> contents are not subject to YANG-based validation (see sec. 7.10 = in >>> [RFC6020]). >>>=20 >>> Are you saying things outside of validation can be simply ignored? >>> It is not totally clear why this is the case. I have something like >>> Kent's configlets in mind for example. >>=20 >> The central theme of the draft is no more XML-JSON translation, it = just >> defines JSON encoding is a similar was as the "XML Mapping Rules" >> sections in RFC 6020 do for XML. So section 5.5 specifies the valid >> encoding of an anyxml instance. >>=20 >> If we have "anyxml foo;", then we know >>=20 >> "foo": [null, [1, 2, true]] >>=20 >> is a valid instance. Why should the draft try to specify the = translation to XML? >>=20 >> In the case of configlets, Kent might provide a specification of = their >> encoding in both XML and JSON. >>=20 >>> You maybe wanted to say that anyxml data should be rendered as much >>> as possible using the various JSON types but how this is done is >>> implementation specific. Since anyxml itself is essentially open >>> ended XML, this is no worse that using anyxml in the first place. >>=20 >> I am not sure I understand, the draft just says that an anyxml = instance >> is encoded as a name/value pair and that the value part has to be a = valid >> JSON value. The sentence you cited is related to sec. 3 which relies = on >> JSON->XML mapping for instance validation - and for this purpose it = is >> really irrelevant how anyxml content is translated as long as we = start >> with valid JSON and end up with valid XML.=20 >=20 > I can agree on "the draft just says that an anyxml instance is encoded > as a name/value pair and that the value part has to be a valid JSON > value." - where I am having trouble is the reasoning given. Perhaps > this does the job equally well: >=20 > OLD >=20 > An anyxml instance is translated to a name/value pair. The value = can > be of any valid JSON type, i.e. an object, array, number, string or > any of the literals 'true', 'false' and 'null'. >=20 > This document defines no mapping between the contents of JSON- and > XML-encoded anyxml instances. It is not necessary because anyxml > contents are not subject to YANG-based validation (see sec. 7.10 in > [RFC6020]). >=20 > NEW >=20 > An anyxml instance is translated to a name/value pair. The value = can > be of any valid JSON type, i.e. an object, array, number, string or > any of the literals 'true', 'false' and 'null'. How the anyxml = content > is mapped to JSON types is implementation specific. The problem with this is that there needn=92t be any mapping involved, = e.g., a client could just put a JSON value there and the server will = receive it without doing any conversion. So in fact anyxml has the = meaning of =93anyjson=94 or =93anydata=94 here. With respect to sec. 3, the text could perhaps say that the mapping of = anydata instances to XML *for validation purposes* is an empty element. = Nothing else is needed.=20 >=20 >>> - It is not clear whether it is legal to encode everything into a >>> string. This was discussed some time ago since essentially YANG's >>> type system is based in literal string representations. >>=20 >> What do you mean? For example, sec. 6.3 clearly says that boolean = values >> are encoded as JSON literal names 'true' and 'false', i.e. no >> string. The same is true for numbers except for 64-bit ones. >>=20 >> I don't agree that YANG type system requires string encoding of the >> values. >=20 > The question is whether you mandate that the encoder has type > information available when rendering the JSON structure and whether > you mandate that a receiver fails if the JSON type does not match its > expectations (given the YANG data model it knows about). It again is a > question whether we mandate type information to be available or > whether a sender is allowed to send "1234" as "1234" in case no type > information is available. My understanding is that even XML encoder has to use the data model in = order to be able to distinguish integers from decimal numbers and encode = them properly. And similarly for decoders - they have to know whether a = received (string) value is to be put into an integer or string variable. = =20 >=20 >>>=20 >>> - Related to the above: Do we really treat "bar": 13.5 as an = encoding >>> error? What is gained by doing this in comparison to simply convert >>=20 >> Yes. The client says it is a number so why should the server coerce = it >> to a string on its own? >=20 > Because the API used internally is not using the JSON type system but > a type system that stems from YANG. JSON is an encoding, not more. And > the union type shows that to follow what YANG does, you have to > stringify values or you have to drop values because of type conflicts. > I think I recall that at least one RESTCONF implementation converts to > strings instead of raising encoding errors. We can discuss this but I think at the root of the issues with unions is = the inability to indicate the actual type of an instance. I don=92t = agree though with introducing a hard rule that all union values be = encoded as strings.=20 >=20 >>> to a string? I heard that some implementations do kind of ignore = the >>> JSON type in order to improve chances of interoperability. >>=20 >> Do you have an example how this could lead to interoperability = problems? >=20 > There are implementations today where the lower layers doing the > encoding/decoding work do not have access to YANG type information. If > we require knowledge of data models by the encoder, we surely raise > the bar for such implementations. The fact that pyang can do things > easily (which is no surprise since it is a YANG compiler) does not > mean all implementations can do this easily. So in order to allow existing implementations that were designed for XML = to use JSON, you propose to force the JSON encoding into a mode that is = XML compatible. This however makes life harder for implementors of *new* = applications written specifically for JSON because they have to do the = work that=92s normally done by a JSON parser. For instance, if a number = encoded as a string is received, the JSON parser parses it as a string = and then another layer has to parse it as a number. >=20 >>> Does it make sense to track issues somewhere? >>=20 >> Any suggestion? The draft is now being developed as a project on = github >> (https://github.com/yang-json), so we can track issues there but I = think >> we agreed not do that. >=20 > I do not care much _how_ issues are tracked. I am fine with letting > those pick a format who will finally maintain the issue tracker. OK, so I propose to file the issues at https://github.com/yang-json/yang-json/issues and I will ocassionally report about the status of the issue tracker in = the mailing list. >=20 >> One general note: I think we need to clarify the purpose of this >> document. My aim has been to find an encoding of YANG concepts in a = way >> that's appropriate and natural for JSON. Your preference seems to be = to >> bend JSON encoding so that it is as close to XML as possible. >>=20 >> The correspondence between JSON and XML encoding of the same data is >> important but it is not the primary goal. I assume some systems or >> deployments can use exclusively JSON without performing any >> translations. >=20 > The basic question is whether we require YANG type information to be > present at all JSON encoders or not (and whether JSON type information > has to be taken authoritative by the decoder). I think this is where > we differ and the rest follows from that. I guess the dilemma really is this: Do we want to define an ultra restricted JSON profile where all scalar = values are strings, or not? I=92d suggest that folks who want to use the JSON encoding speak up. >=20 > /js >=20 > PS: I just found that the I-D does not talk about uint32, likely = simply > an omission. Oh yes, copy-and-paste error, fixed, thanks. Lada >=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 Tue Oct 14 08:40:36 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED9521A894C for ; Tue, 14 Oct 2014 08:40:32 -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 6HQJI10ZOmmn for ; Tue, 14 Oct 2014 08:40:29 -0700 (PDT) Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C398E1A8949 for ; Tue, 14 Oct 2014 08:40:28 -0700 (PDT) Received: by mail-qc0-f175.google.com with SMTP id b13so583733qcw.34 for ; Tue, 14 Oct 2014 08:40:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6rXZcaTF8T3XPr8Z1laTien1zVxhaPqhHLC7AOg5+0U=; b=igFe0MVLdQVq8iM8G9ssC/Ew7JD5Zp9jVmUNoY3mL7NVIvL3iIc3RCiWoVU4HO35kn pRwA4tNyaa8KJXCG5wfgOCaELetlpsJ//OOMMhlyxhnYcQ9fGibDn+SgrRyr75LjlqWe iRlSOYC+COSK0AsAlmal+1YmQ2xqYzyJr311++pGBLh0us99ecpeW+w9d7sO8vdCy6EE /GTTMAci2XPx23SIwki/3CgHt/QqQrF7dvq/jXl9GIJrXNun1SmigBJhp3O0Zaqr7Rcj 8MjMidYoYOIXllZE7yR75eNXQm+AGPowNtMK9ByXs/DOcKKqPp8c/aNvrKuxh81r0TBZ RAyg== X-Gm-Message-State: ALoCoQlzur6MCkq93mSKImD53ZC33bnJT/KhHp7dbnmv0gisnrx+ENmghTk6pyQkU4hm9HrkzH1Z MIME-Version: 1.0 X-Received: by 10.224.28.133 with SMTP id m5mr10337505qac.7.1413301227916; Tue, 14 Oct 2014 08:40:27 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Tue, 14 Oct 2014 08:40:27 -0700 (PDT) In-Reply-To: References: <20141010210934.GB80385@elstar.local> <20141010215341.GD80385@elstar.local> <20141013192248.GA68615@elstar.local> Date: Tue, 14 Oct 2014 08:40:27 -0700 Message-ID: From: Andy Bierman To: "Alexander Clemm (alex)" Content-Type: multipart/alternative; boundary=001a11c1db70a6a8a3050563d5a4 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/eWvCKgldoQnEK7HLEoHdyO7yFgQ Cc: "netmod@ietf.org" Subject: Re: [netmod] New revision of YANG mount draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2014 15:40:33 -0000 --001a11c1db70a6a8a3050563d5a4 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 13, 2014 at 5:52 PM, Alexander Clemm (alex) wrote: > Hi Juergen, > (several threads to respond to; Eric already provided responses to a lot > of the items, here just a few summary items from my perspective) > > Re: what technical details we think should be standardized: > > - The first aspect is the YANG extension that allows users to define > mountpoints (to logically incorporate subtrees from a remote datastore > under a data node). This can be done as part of a YANG module, i.e. is > data model related. > > - The second aspect is a YANG data model that allows to monitor and manage > a "mount topology". This addresses the system management aspects of this > concept, generally not of concern to the applications that want to simply > access the datastore, but required for a "complete" solution. Again, this > can be done as part of a YANG module, i.e. is data model related. > > - The third aspect concerns the ability to subscribe to updates to a YANG > datatree, and "push" those updates. This is more general than mount itself > and should presumably be separated into a separate draft. Subscriptions > can be represented as a configurable data model. Likewise, push can occur > through notifications, definable as part of a data model related. So, that > one too is data model related. (It is conceivable to also introduce > different transports here, which would be discussion for a transport forum; > however, our intent was to address these within the existing framework.) > > Re: overall architecture, you are bringing up an interesting point that > probably needs visiting. RFC 6244, in section 3.1, clearly depicts the > boundary of the server as one device. This is intentional and IMO the proper architecture for a NETCONF datastore. The datastore is intended to represent one device, whether that device is a giant network controller or a tiny access point. I don't agree that replication of subtrees from other servers is the proper architecture for a network-wide datastore. It doesn't matter for monitoring, but for editing the subtrees are all part of 1 configuration datastore, not isolated replicated subtrees. > It also suggests that the datastore does not reach beyond the device > boundaries (datastore is actually not depicted, but config database and > "system software components" - presumably for the config data). This is > why we believe the mount capability is needed - to allow the datastore to > reach beyond those boundaries. If this involves extending the > architecture, then so be it. Worth mentioning along the same lines, since > RFC 6244 assumes that YANG will be always used in conjunction with Netconf: > Really, we would like to consider Netconf just one particular transport / > set of services that can operate on / interact with a datastore, geared > towards configuration and fulfillment-related use cases. That should not > rule out the possibility to apply other transports and services - such as > RESTconf (the possi > bility for which is not considered in the RFC), and going forward > possibly other transports/ interfaces, that for example focus on pushing > datastore information and operational data for applications which today > might use SNMP. > > Regarding making this transparent for all Netconf operations: The > important aspect and primary focus of the use case lies in providing an > ability to retrieve remote information. The motivation behind all this is > not to provid "ACID" style management transactions across the network - in > fact, we believe that for many applications a "BASE" style of management is > preferrable and more appropriate, in which transactional guarantees, > ability to rollback,etc, are not provided as long as state becomes > eventually consistent. This is also reflected in the companion requirements > spec. We do not want to be bogged down in the aspects that would be > required to make ACID work. While we believe that "simple" configuration > (not including transactions spanning multiple items) is achievable, we are > happy to "scale down" the mount concept accordingly and leave > transactionality or even configuration as a whole out of scope. > > I don't see what is stopping you from implementing your controller. If you wrap the remote config in anyxml, then all the YANG validation problems go away. The controller can send NETCONF requests to the remote devices on behalf of the northbound client. This seems like just an implementation detail for the controller, not a standards issue. The request to have the devices push all their operational data to the controller is a different matter. That has a huge operational impact, and something that NETCONF is not designed for. I suggest using IPFIX for that. > --- Alex > > Andy > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, October 13, 2014 12:23 PM > To: Eric Voit (evoit) > Cc: Alexander Clemm (alex); netmod@ietf.org > Subject: Re: [netmod] New revision of YANG mount draft > > On Mon, Oct 13, 2014 at 04:26:55PM +0000, Eric Voit (evoit) wrote: > > > From: Juergen Schoenwaelder, October 10, 2014 5:54 PM > > > > > > I still fail to see how all this falls out of RFC 6020. > > > > If by falling out you mean 'in conflict with', then I would agree that > there are not backwards compatibility issues with RFC 6020 section 6 > syntax. This was by design. > > > > However I believe Alex' and Jan's concerns are with Section 5.1 of RFC > 6020. This section includes statements such as: "For a module or > submodule to reference definitions in an external module, the external > module MUST be imported." > > > > Bringing in targeted nodes and subtrees need not require visibility into > the full submodule where the authoritative copy of the object might reside. > > > > There is anyxml in YANG 1.0 and there is a proposal for anydata in YANG > 1.1. > > > > I see protocol discussion in draft-clemm-netmod-mount-02.txt (which > > > is needed for what you want to do and likely even incomplete) but > > > then the NETMOD WG is not about protocol work but about the data > > > modeling language YANG and data models. In fact, my reading of the > > > I-D is that you do not request to change anything in YANG at all - > > > all you propose is to define a few extensions and a data model. > > > > The 'on-demand' Mount does not need any protocol work. It is the > easiest, and is looking to standardize needed several syntax extensions. > This type of Mount is what is implemented in OpenDaylight today. > > > > I am not sure. Can I run all NETCONF protocol operations transparently > across these mount points? I doubt it. > > What you introduce is a "partitioning" of a datastore that does not > architecturally exist so far. Does this lead to a new type of datastore or > can I partition any datastore? How does this partitioning interact with > ephemeral datastores discussed in I2RS? I believe there are serious > _architectural_ questions that need to be discussed and depending on how > they are resolved, there may be more or less protocol work needed. > > What triggered this discussions were statements of the form "YANG does not > allow to do X" which I think is not correct since YANG really is not the > issue. The mount work is extending/modifying/$(your-verb-here) > the _architecture_ of NETCONF and YANG. It is not clear which WG is > responsible for the underlying architecture. RFC 6244 was produced by > NETMOD but then it describes more the framework and not the underlying > architectural model (what Randy Presuhn I think calls the meta model). > Perhaps we need to work on an architecture at some point in time, pretty > much like we needed to define an architecture for SNMP at some point in > time. The work on JSON encoding and the mount proposal clearly indicates > that certain architectural assumptions are implicit and that leads to > discussions that are difficult to close until we agree on an architecture. > > Who said history does not repeat? > > /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 > --001a11c1db70a6a8a3050563d5a4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mon, Oct 13, 2014 at 5:52 PM, Alexander Clemm (alex) <alex@cisco.com> wrote:
Hi Juergen,
(several threads to respond to; Eric already provided responses to a lot of= the items, here just a few summary items from my perspective)

Re: what technical details we think should be standardized:

- The first aspect is the YANG extension that allows users to define mountp= oints (to logically incorporate subtrees from a remote datastore under a da= ta node).=A0 This can be done as part of a YANG module, i.e. is data model = related.

- The second aspect is a YANG data model that allows to monitor and manage = a "mount topology".=A0 This addresses the system management aspec= ts of this concept, generally not of concern to the applications that want = to simply access the datastore, but required for a "complete" sol= ution.=A0 Again, this can be done as part of a YANG module, i.e. is data mo= del related.

- The third aspect concerns the ability to subscribe to updates to a YANG d= atatree, and "push" those updates.=A0 This is more general than m= ount itself and should presumably be separated into a separate draft.=A0 Su= bscriptions can be represented as a configurable data model.=A0 Likewise, p= ush can occur through notifications, definable as part of a data model rela= ted.=A0 So, that one too is data model related.=A0 (It is conceivable to al= so introduce different transports here, which would be discussion for a tra= nsport forum; however, our intent was to address these within the existing = framework.)

Re: overall architecture, you are bringing up an interesting point that pro= bably needs visiting.=A0 RFC 6244, in section 3.1, clearly depicts the boun= dary of the server as one device.=A0


This is intentional and IMO the proper architecture for a NETCONF = datastore.
The datastore is intended to represent one device, whe= ther that device is a giant
network controller or a tiny access p= oint.

I don't agree that replication of subtre= es from other servers is the proper architecture for
a network-wi= de datastore.=A0 It doesn't matter for monitoring, but for editing the = subtrees
are all part of 1 configuration datastore, not isolated = replicated subtrees. =A0


=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> It also suggests that the datastore does not= reach beyond the device boundaries (datastore is actually not depicted, bu= t config database and "system software components" - presumably f= or the config data).=A0 This is why we believe the mount capability is need= ed - to allow the datastore to reach beyond those boundaries.=A0 If this in= volves extending the architecture, then so be it.=A0 Worth mentioning along= the same lines, since RFC 6244 assumes that YANG will be always used in co= njunction with Netconf: Really, we would like to consider Netconf just one = particular transport / set of services that can operate on / interact with = a datastore, geared towards configuration and fulfillment-related use cases= .=A0 That should not rule out the possibility to apply other transports and= services - such as RESTconf (the possi
=A0bility for which is not considered in the RFC), and going forward possib= ly other transports/ interfaces, that for example focus on pushing datastor= e information and operational data for applications which today might use S= NMP.

Regarding making this transparent for all Netconf operations:=A0 The import= ant aspect and primary focus of the use case lies in providing an ability t= o retrieve remote information.=A0 The motivation behind all this is not to = provid "ACID" style management transactions across the network - = in fact, we believe that for many applications a "BASE" style of = management is preferrable and more appropriate, in which transactional guar= antees, ability to rollback,etc, are not provided as long as state becomes = eventually consistent. This is also reflected in the companion requirements= spec.=A0 We do not want to be bogged down in the aspects that would be req= uired to make ACID work.=A0 While we believe that "simple" config= uration (not including transactions spanning multiple items) is achievable,= we are happy to "scale down" the mount concept accordingly and l= eave transactionality or even configuration as a whole out of scope.


I don't see what is stopping you f= rom implementing your controller.
If you wrap the remote config i= n anyxml, then all the YANG validation
problems go away.=A0 The c= ontroller can send NETCONF requests to the remote devices
on beha= lf of the northbound client. =A0 This seems like just an implementation det= ail
for the controller, not a standards issue.

The request to have the devices push all their operational data to t= he controller
is a different matter.=A0 That has a huge operation= al impact, and something that
NETCONF is not designed for.=A0 I s= uggest using IPFIX for that.




--- Alex


Andy

=A0
-----Original Message-----
From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]
Sent: Monday, October 13, 2014 12:23 PM
To: Eric Voit (evoit)
Cc: Alexander Clemm (alex); netmod@ietf.= org
Subject: Re: [netmod] New revision of YANG mount draft

On Mon, Oct 13, 2014 at 04:26:55PM +0000, Eric Voit (evoit) wrote:
> > From: Juergen Schoenwaelder, October 10, 2014 5:54 PM
> >
> > I still fail to see how all this falls out of RFC 6020.
>
> If by falling out you mean 'in conflict with', then I would ag= ree that there are not backwards compatibility issues with RFC 6020 section= 6 syntax.=A0 This was by design.
>
> However I believe Alex' and Jan's concerns are with Section 5.= 1 of RFC 6020.=A0 =A0This section includes statements such as:=A0 "For= a module or submodule to reference definitions in an external module, the = external module MUST be imported."
>
> Bringing in targeted nodes and subtrees need not require visibility in= to the full submodule where the authoritative copy of the object might resi= de.
>

There is anyxml in YANG 1.0 and there is a proposal for anydata in YANG 1.1= .

> > I see protocol discussion in draft-clemm-netmod-mount-02.txt (whi= ch
> > is needed for what you want to do and likely even incomplete) but=
> > then the NETMOD WG is not about protocol work but about the data<= br> > > modeling language YANG and data models. In fact, my reading of th= e
> > I-D is that you do not request to change anything in YANG at all = -
> > all you propose is to define a few extensions and a data model. >
> The 'on-demand' Mount does not need any protocol work.=A0 It i= s the easiest, and is looking to standardize needed several syntax extensio= ns.=A0 This type of Mount is what is implemented in OpenDaylight today.
>

I am not sure. Can I run all NETCONF protocol operations transparently acro= ss these mount points? I doubt it.

What you introduce is a "partitioning" of a datastore that does n= ot architecturally exist so far. Does this lead to a new type of datastore = or can I partition any datastore? How does this partitioning interact with = ephemeral datastores discussed in I2RS? I believe there are serious _archit= ectural_ questions that need to be discussed and depending on how they are = resolved, there may be more or less protocol work needed.

What triggered this discussions were statements of the form "YANG does= not allow to do X" which I think is not correct since YANG really is = not the issue. The mount work is extending/modifying/$(your-verb-here)
the _architecture_ of NETCONF and YANG. It is not clear which WG is respons= ible for the underlying architecture. RFC 6244 was produced by NETMOD but t= hen it describes more the framework and not the underlying architectural mo= del (what Randy Presuhn I think calls the meta model). Perhaps we need to w= ork on an architecture at some point in time, pretty much like we needed to= define an architecture for SNMP at some point in time. The work on JSON en= coding and the mount proposal clearly indicates that certain architectural = assumptions are implicit and that leads to discussions that are difficult t= o close until we agree on an architecture.

Who said history does not repeat?

/js

--
Juergen Schoenwaelder=A0 =A0 =A0 =A0 =A0 =A0Jacobs University Bremen gGmbH<= br> Phone: +49 421 200 3587=A0 =A0 =A0 =A0 =A0Campus Ring 1, 28759 Bremen, Germ= any
Fax:=A0 =A0+49 421 200 3103=A0 =A0 =A0 =A0 =A0<http://www.jacobs-university.de/&= gt;

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

--001a11c1db70a6a8a3050563d5a4-- From nobody Tue Oct 14 12:44:08 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E52831ACF0A for ; Tue, 14 Oct 2014 12:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 od9TyUsAZ4D0 for ; Tue, 14 Oct 2014 12:44:02 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0706.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:706]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C79691ACF05 for ; Tue, 14 Oct 2014 12:44: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.0.1049.19; Tue, 14 Oct 2014 19:43:38 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.104]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.104]) with mapi id 15.00.1049.012; Tue, 14 Oct 2014 19:43:37 +0000 From: Kent Watsen To: Andy Bierman , "Alexander Clemm (alex)" Thread-Topic: [netmod] New revision of YANG mount draft Thread-Index: AQHP40RfcXk3qRma8kec20irC7AonJwoMIcAgAGl6wCAAANUgIAACQCAgARbsoCAADEkAIAAXAsAgAD4KoCAAADkAA== Date: Tue, 14 Oct 2014 19:43:37 +0000 Message-ID: References: <20141010210934.GB80385@elstar.local> <20141010215341.GD80385@elstar.local> <20141013192248.GA68615@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 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 03648EFF89 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(46034005)(51704005)(24454002)(199003)(189002)(164054003)(76176999)(54356999)(76482002)(2656002)(19580395003)(120916001)(50986999)(19580405001)(97736003)(87936001)(83506001)(561944003)(86362001)(4396001)(92566001)(101416001)(92726001)(15975445006)(19617315012)(85306004)(122556002)(85852003)(93886004)(15202345003)(77096002)(106356001)(66066001)(16236675004)(95666004)(36756003)(99286002)(31966008)(21056001)(99396003)(46102003)(20776003)(105586002)(106116001)(107046002)(64706001)(80022003)(40100003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_D062E75A852FBkwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Rn2L17h757XcZGRXtvzavePJ68g Cc: "netmod@ietf.org" Subject: Re: [netmod] New revision of YANG mount draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2014 19:44:07 -0000 --_000_D062E75A852FBkwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This conversation is going full-circle, so I'll go back to my original poin= t - that I don't understand the importance for IETF standardization and que= stion the effectiveness of the solution. EMS systems managing devices using NETCONF/YANG have been around for a few = years. It is pretty common for them to 1) provide a mechanism to get the Y= ANG module used by a device and 2) a low-level API to get/set device-specif= ic config (as modeled by its YANG) - all with clear separation of which sys= tem "owns" which data. This draft proposes to fulfill the same need, but= in a way that is unique to a Controller/EMS that itself presents a YANG-de= fined NETCONF/RESTCONF model. Under those circumstances, I can almost und= erstand the line of thinking that led to "mounting" idea (why not, right?),= but is this really how a higher-level OSS/BSS would want it presented. Wh= y wouldn't the higher-level system use NETCONF to the device directly? - w= hat semantics does "mounting" bring above and beyond a direct connection to= the device (approval-workflow or network-wide transactional-updates?) To Tom's point, it's not enough that some products implement an idea for th= ere to be a need to add it to a WG charter. I'd rather see pressing intero= perability considerations driving that. All that said, I do support the idea of enhancing NETCONF notifications, if= RFC6470's netconf-config-change event isn't sufficient. If there is a def= iciency there, then all NETCONF clients (not "mount clients") would benefit= . Thanks, Kent From: Andy Bierman > Date: Tuesday, October 14, 2014 at 11:40 AM To: "Alexander Clemm (alex)" > Cc: "netmod@ietf.org" > Subject: Re: [netmod] New revision of YANG mount draft On Mon, Oct 13, 2014 at 5:52 PM, Alexander Clemm (alex) > wrote: Hi Juergen, (several threads to respond to; Eric already provided responses to a lot of= the items, here just a few summary items from my perspective) Re: what technical details we think should be standardized: - The first aspect is the YANG extension that allows users to define mountp= oints (to logically incorporate subtrees from a remote datastore under a da= ta node). This can be done as part of a YANG module, i.e. is data model re= lated. - The second aspect is a YANG data model that allows to monitor and manage = a "mount topology". This addresses the system management aspects of this c= oncept, generally not of concern to the applications that want to simply ac= cess the datastore, but required for a "complete" solution. Again, this ca= n be done as part of a YANG module, i.e. is data model related. - The third aspect concerns the ability to subscribe to updates to a YANG d= atatree, and "push" those updates. This is more general than mount itself = and should presumably be separated into a separate draft. Subscriptions ca= n be represented as a configurable data model. Likewise, push can occur th= rough notifications, definable as part of a data model related. So, that o= ne too is data model related. (It is conceivable to also introduce differe= nt transports here, which would be discussion for a transport forum; howeve= r, our intent was to address these within the existing framework.) Re: overall architecture, you are bringing up an interesting point that pro= bably needs visiting. RFC 6244, in section 3.1, clearly depicts the bounda= ry of the server as one device. This is intentional and IMO the proper architecture for a NETCONF datastore= . The datastore is intended to represent one device, whether that device is a= giant network controller or a tiny access point. I don't agree that replication of subtrees from other servers is the proper= architecture for a network-wide datastore. It doesn't matter for monitoring, but for editin= g the subtrees are all part of 1 configuration datastore, not isolated replicated subtrees= . It also suggests that the datastore does not reach beyond the device bounda= ries (datastore is actually not depicted, but config database and "system s= oftware components" - presumably for the config data). This is why we beli= eve the mount capability is needed - to allow the datastore to reach beyond= those boundaries. If this involves extending the architecture, then so be= it. Worth mentioning along the same lines, since RFC 6244 assumes that YA= NG will be always used in conjunction with Netconf: Really, we would like t= o consider Netconf just one particular transport / set of services that can= operate on / interact with a datastore, geared towards configuration and f= ulfillment-related use cases. That should not rule out the possibility to = apply other transports and services - such as RESTconf (the possi bility for which is not considered in the RFC), and going forward possibly= other transports/ interfaces, that for example focus on pushing datastore = information and operational data for applications which today might use SNM= P. Regarding making this transparent for all Netconf operations: The importan= t aspect and primary focus of the use case lies in providing an ability to = retrieve remote information. The motivation behind all this is not to prov= id "ACID" style management transactions across the network - in fact, we be= lieve that for many applications a "BASE" style of management is preferrabl= e and more appropriate, in which transactional guarantees, ability to rollb= ack,etc, are not provided as long as state becomes eventually consistent. T= his is also reflected in the companion requirements spec. We do not want t= o be bogged down in the aspects that would be required to make ACID work. = While we believe that "simple" configuration (not including transactions sp= anning multiple items) is achievable, we are happy to "scale down" the moun= t concept accordingly and leave transactionality or even configuration as a= whole out of scope. I don't see what is stopping you from implementing your controller. If you wrap the remote config in anyxml, then all the YANG validation problems go away. The controller can send NETCONF requests to the remote d= evices on behalf of the northbound client. This seems like just an implementatio= n detail for the controller, not a standards issue. The request to have the devices push all their operational data to the cont= roller is a different matter. That has a huge operational impact, and something t= hat NETCONF is not designed for. I suggest using IPFIX for that. --- Alex Andy -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: Monday, October 13, 2014 12:23 PM To: Eric Voit (evoit) Cc: Alexander Clemm (alex); netmod@ietf.org Subject: Re: [netmod] New revision of YANG mount draft On Mon, Oct 13, 2014 at 04:26:55PM +0000, Eric Voit (evoit) wrote: > > From: Juergen Schoenwaelder, October 10, 2014 5:54 PM > > > > I still fail to see how all this falls out of RFC 6020. > > If by falling out you mean 'in conflict with', then I would agree that th= ere are not backwards compatibility issues with RFC 6020 section 6 syntax. = This was by design. > > However I believe Alex' and Jan's concerns are with Section 5.1 of RFC 60= 20. This section includes statements such as: "For a module or submodule= to reference definitions in an external module, the external module MUST b= e imported." > > Bringing in targeted nodes and subtrees need not require visibility into = the full submodule where the authoritative copy of the object might reside. > There is anyxml in YANG 1.0 and there is a proposal for anydata in YANG 1.1= . > > I see protocol discussion in draft-clemm-netmod-mount-02.txt (which > > is needed for what you want to do and likely even incomplete) but > > then the NETMOD WG is not about protocol work but about the data > > modeling language YANG and data models. In fact, my reading of the > > I-D is that you do not request to change anything in YANG at all - > > all you propose is to define a few extensions and a data model. > > The 'on-demand' Mount does not need any protocol work. It is the easiest= , and is looking to standardize needed several syntax extensions. This typ= e of Mount is what is implemented in OpenDaylight today. > I am not sure. Can I run all NETCONF protocol operations transparently acro= ss these mount points? I doubt it. What you introduce is a "partitioning" of a datastore that does not archite= cturally exist so far. Does this lead to a new type of datastore or can I p= artition any datastore? How does this partitioning interact with ephemeral = datastores discussed in I2RS? I believe there are serious _architectural_ q= uestions that need to be discussed and depending on how they are resolved, = there may be more or less protocol work needed. What triggered this discussions were statements of the form "YANG does not = allow to do X" which I think is not correct since YANG really is not the is= sue. The mount work is extending/modifying/$(your-verb-here) the _architecture_ of NETCONF and YANG. It is not clear which WG is respons= ible for the underlying architecture. RFC 6244 was produced by NETMOD but t= hen it describes more the framework and not the underlying architectural mo= del (what Randy Presuhn I think calls the meta model). Perhaps we need to w= ork on an architecture at some point in time, pretty much like we needed to= define an architecture for SNMP at some point in time. The work on JSON en= coding and the mount proposal clearly indicates that certain architectural = assumptions are implicit and that leads to discussions that are difficult t= o close until we agree on an architecture. Who said history does not repeat? /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 --_000_D062E75A852FBkwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

This conversation is going full-circle, so I'll go back to my original= point - that I don't understand the importance for IETF standardization an= d question the effectiveness of the solution.

EMS systems managing devices using NETCONF/YANG have been around for a= few years.  It is pretty common for them to 1) provide a mechanism to= get the YANG module used by a device and 2) a low-level API to get/set dev= ice-specific config (as modeled by its YANG) - all with clear separation of which system "owns" which d= ata.    This draft proposes to fulfill the same need, but in a wa= y that is unique to a Controller/EMS that itself presents a YANG-defined NE= TCONF/RESTCONF model.   Under those circumstances, I can almost understand the line of thinking that led to "mounting"= ; idea (why not, right?), but is this really how a higher-level OSS/BSS wou= ld want it presented.  Why wouldn't the higher-level system use NETCON= F to the device directly?  - what semantics does "mounting" bring above and beyond a direct connection to the dev= ice (approval-workflow or network-wide transactional-updates?) 

To Tom's point, it's not enough that some products implement an idea f= or there to be a need to add it to a WG charter.  I'd rather see press= ing interoperability considerations driving that.

All that said, I do support the idea of enhancing NETCONF notification= s, if RFC6470's netconf-config-change event isn't sufficient.  If ther= e is a deficiency there, then all NETCONF clients (not "mount clients&= quot;) would benefit.

Thanks,
Kent


From: Andy Bierman <andy@yumaworks.com>
Date: Tuesday, October 14, 2014 at = 11:40 AM
To: "Alexander Clemm (alex)&qu= ot; <alex@cisco.com>
Cc: "netmod@ietf.org" <= netmod@ietf.org>
Subject: Re: [netmod] New revision = of YANG mount draft



On Mon, Oct 13, 2014 at 5:52 PM, Alexander Clemm= (alex) <alex@cisco.com&= gt; wrote:
Hi Juergen,
(several threads to respond to; Eric already provided responses to a lot of= the items, here just a few summary items from my perspective)

Re: what technical details we think should be standardized:

- The first aspect is the YANG extension that allows users to define mountp= oints (to logically incorporate subtrees from a remote datastore under a da= ta node).  This can be done as part of a YANG module, i.e. is data mod= el related.

- The second aspect is a YANG data model that allows to monitor and manage = a "mount topology".  This addresses the system management as= pects of this concept, generally not of concern to the applications that wa= nt to simply access the datastore, but required for a "complete" solution.  Again, this can be done as part= of a YANG module, i.e. is data model related.

- The third aspect concerns the ability to subscribe to updates to a YANG d= atatree, and "push" those updates.  This is more general tha= n mount itself and should presumably be separated into a separate draft.&nb= sp; Subscriptions can be represented as a configurable data model.  Likewise, push can occur through notifications, definabl= e as part of a data model related.  So, that one too is data model rel= ated.  (It is conceivable to also introduce different transports here,= which would be discussion for a transport forum; however, our intent was to address these within the existing framework.)
Re: overall architecture, you are bringing up an interesting point that pro= bably needs visiting.  RFC 6244, in section 3.1, clearly depicts the b= oundary of the server as one device. 


This is intentional and IMO the proper architecture for a NETCONF data= store.
The datastore is intended to represent one device, whether that device= is a giant
network controller or a tiny access point.

I don't agree that replication of subtrees from other servers is the p= roper architecture for
a network-wide datastore.  It doesn't matter for monitoring, but = for editing the subtrees
are all part of 1 configuration datastore, not isolated replicated sub= trees.  


 
It also suggests that the datastore does not reach beyond the device bounda= ries (datastore is actually not depicted, but config database and "sys= tem software components" - presumably for the config data).  This= is why we believe the mount capability is needed - to allow the datastore to reach beyond those boundaries.  If this i= nvolves extending the architecture, then so be it.  Worth mentioning a= long the same lines, since RFC 6244 assumes that YANG will be always used i= n conjunction with Netconf: Really, we would like to consider Netconf just one particular transport / set of services t= hat can operate on / interact with a datastore, geared towards configuratio= n and fulfillment-related use cases.  That should not rule out the pos= sibility to apply other transports and services - such as RESTconf (the possi
 bility for which is not considered in the RFC), and going forward pos= sibly other transports/ interfaces, that for example focus on pushing datas= tore information and operational data for applications which today might us= e SNMP.

Regarding making this transparent for all Netconf operations:  The imp= ortant aspect and primary focus of the use case lies in providing an abilit= y to retrieve remote information.  The motivation behind all this is n= ot to provid "ACID" style management transactions across the network - in fact, we believe that for many applications a &quo= t;BASE" style of management is preferrable and more appropriate, in wh= ich transactional guarantees, ability to rollback,etc, are not provided as = long as state becomes eventually consistent. This is also reflected in the companion requirements spec.  We do not= want to be bogged down in the aspects that would be required to make ACID = work.  While we believe that "simple" configuration (not inc= luding transactions spanning multiple items) is achievable, we are happy to "scale down" the mount concept accordingly and l= eave transactionality or even configuration as a whole out of scope.


I don't see what is stopping you from implementing your controller.
If you wrap the remote config in anyxml, then all the YANG validation<= /div>
problems go away.  The controller can send NETCONF requests to th= e remote devices
on behalf of the northbound client.   This seems like just an imp= lementation detail
for the controller, not a standards issue.

The request to have the devices push all their operational data to the= controller
is a different matter.  That has a huge operational impact, and s= omething that
NETCONF is not designed for.  I suggest using IPFIX for that.




--- Alex


Andy

 
-----Original Message-----
From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]
Sent: Monday, October 13, 2014 12:23 PM
To: Eric Voit (evoit)
Cc: Alexander Clemm (alex); netmod@ietf.= org
Subject: Re: [netmod] New revision of YANG mount draft

On Mon, Oct 13, 2014 at 04:26:55PM +0000, Eric Voit (evoit) wrote:
> > From: Juergen Schoenwaelder, October 10, 2014 5:54 PM
> >
> > I still fail to see how all this falls out of RFC 6020.
>
> If by falling out you mean 'in conflict with', then I would agree that= there are not backwards compatibility issues with RFC 6020 section 6 synta= x.  This was by design.
>
> However I believe Alex' and Jan's concerns are with Section 5.1 of RFC= 6020.   This section includes statements such as:  "Fo= r a module or submodule to reference definitions in an external module, the= external module MUST be imported."
>
> Bringing in targeted nodes and subtrees need not require visibility in= to the full submodule where the authoritative copy of the object might resi= de.
>

There is anyxml in YANG 1.0 and there is a proposal for anydata in YANG 1.1= .

> > I see protocol discussion in draft-clemm-netmod-mount-02.txt (whi= ch
> > is needed for what you want to do and likely even incomplete) but=
> > then the NETMOD WG is not about protocol work but about the data<= br> > > modeling language YANG and data models. In fact, my reading of th= e
> > I-D is that you do not request to change anything in YANG at all = -
> > all you propose is to define a few extensions and a data model. >
> The 'on-demand' Mount does not need any protocol work.  It is the= easiest, and is looking to standardize needed several syntax extensions.&n= bsp; This type of Mount is what is implemented in OpenDaylight today.
>

I am not sure. Can I run all NETCONF protocol operations transparently acro= ss these mount points? I doubt it.

What you introduce is a "partitioning" of a datastore that does n= ot architecturally exist so far. Does this lead to a new type of datastore = or can I partition any datastore? How does this partitioning interact with = ephemeral datastores discussed in I2RS? I believe there are serious _architectural_ questions that need to be discus= sed and depending on how they are resolved, there may be more or less proto= col work needed.

What triggered this discussions were statements of the form "YANG does= not allow to do X" which I think is not correct since YANG really is = not the issue. The mount work is extending/modifying/$(your-verb-here)
the _architecture_ of NETCONF and YANG. It is not clear which WG is respons= ible for the underlying architecture. RFC 6244 was produced by NETMOD but t= hen it describes more the framework and not the underlying architectural mo= del (what Randy Presuhn I think calls the meta model). Perhaps we need to work on an architecture at some = point in time, pretty much like we needed to define an architecture for SNM= P at some point in time. The work on JSON encoding and the mount proposal c= learly indicates that certain architectural assumptions are implicit and that leads to discussions that are difficult = to close until we agree on an architecture.

Who said history does not repeat?

/js

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

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

--_000_D062E75A852FBkwatsenjunipernet_-- From nobody Tue Oct 14 13:22:29 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DFA51ACF08 for ; Tue, 14 Oct 2014 13:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UowXUpZzBVwT for ; Tue, 14 Oct 2014 13:22:23 -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 9F0D31A0009 for ; Tue, 14 Oct 2014 13:22:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2856; q=dns/txt; s=iport; t=1413318145; x=1414527745; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=9s654ng9u5410j7Y9bjosQsdT/yM6KUd55Kx7k3bPE4=; b=hlpGkDX16/zxjdHC5Qb/XaLXmfQl172YyFTsNh+ZPYxj611Sp2hQIM2m RtHv/ZrE73Aih62AjbBZ7b3fF1VsU6h7PsgezbssmhpcGCAmjHB4tzABC bfJG3SZ6nCdfQQ8CnEyxhmz41eKQ7XDXXcxTEqfVripX+5/u6sQFw0u0z U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAAOFPVStJA2B/2dsb2JhbABbgw6BL9QDAoEWFgF9hAMBAQQ6PxACAQgOFAISEDIlAgQODROII8cqAQEBAQEBAQEBAQEBAQEBAQEBAQEBF5AUMQeDLYEeAQSReY0AhnOJcoN+gXx4AYECgjSBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,719,1406592000"; d="scan'208";a="363432467" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-2.cisco.com with ESMTP; 14 Oct 2014 20:22:24 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s9EKMMaH030865 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Oct 2014 20:22:22 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.163]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Tue, 14 Oct 2014 15:22:22 -0500 From: "Alexander Clemm (alex)" To: Martin Bjorklund Thread-Topic: [netmod] New revision of YANG mount draft Thread-Index: AQHP40Rf8kMXz8u2QICzU6EjzD0qC5wopeSAgAGEYAD//6x3sIAAX9yAgARbs4CAADEkAP//+2DwgAEz3ICAABul8A== Date: Tue, 14 Oct 2014 20:22:22 +0000 Message-ID: References: <20141013192248.GA68615@elstar.local> <20141014.152807.103014930228832956.mbj@tail-f.com> In-Reply-To: <20141014.152807.103014930228832956.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.218.195] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ArsiaplFKD3rf6EVvZf7r7td_Bw Cc: "netmod@ietf.org" Subject: Re: [netmod] New revision of YANG mount draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2014 20:22:25 -0000 Hi Martin ... [Martin] I would generalize this one even more: a mechanism that allows use= rs to logically incorporate subtrees from a module under a data node. I.e., what I think might be needed and would be useful to standardize is a = mechansim to extended the *schema*. Note the difference; you talk about ex= tending datastores (which I find problematic) and I talk about extending th= e schema. Yes, they are different. I can see potentially the need for both. = I am not sure why extending the datastore itself would be problematic. I = assume with "extending" you mean having the scope extend beyond the boundar= y of the device".=20 FWIW, we are using something like this in our controller application NCS. > - The second aspect is a YANG data model that allows to monitor and=20 > manage a "mount topology". This addresses the system management=20 > aspects of this concept, generally not of concern to the applications=20 > that want to simply access the datastore, but required for a=20 > "complete" solution. Again, this can be done as part of a YANG=20 > module, i.e. is data model related. With the more general schema extension mechansim I described above, I would= say that the second aspect of your proposal is a mechanism to implement th= ese schema extensions by the concept of "mounting" (including a data model to monitor and manage this). This part seems to be pretty complex in all but the read-only use case. For the solution to be complete, this seems to be required because a= t the end of the day, we have "mount topology" which a system administrator= may want to have visibility into. That said, I certainly agree with your = implied sentiment that in general an implementation will and should bootstr= ap this topology on its own, instead of requiring administrator interventio= n. =20 > - The third aspect concerns the ability to subscribe to updates to a=20 > YANG datatree, and "push" those updates. This is more general than=20 > mount itself and should presumably be separated into a separate draft. =20 > Subscriptions can be represented as a configurable data model. =20 > Likewise, push can occur through notifications, definable as part of a=20 > data model related. So, that one too is data model related. (It is=20 > conceivable to also introduce different transports here, which would=20 > be discussion for a transport forum; however, our intent was to=20 > address these within the existing framework.) Ok, but the draft doesn't actually propose a concrete mechansim. True, at this point it just has the requirements for that; we were p= lanning for the next draft to have a proposal, although I think this should= better be separated out as this is more general Thanks, --- Alex From nobody Tue Oct 14 13:49:27 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2721ACF18 for ; Tue, 14 Oct 2014 13:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.286 X-Spam-Level: X-Spam-Status: No, score=-15.286 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uD6q1SEyC_DG for ; Tue, 14 Oct 2014 13:49:21 -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 371281ACF71 for ; Tue, 14 Oct 2014 13:49:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19942; q=dns/txt; s=iport; t=1413319762; x=1414529362; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=8/WNYgQd4wz8rKHs3b/jy/8AKEHdd+Fk0VzW6whNeYQ=; b=IWGArNiweYTQOXlaJoB1qiFyrG8vB93cO9cmhrXg1YSlwbJejzXx4Xfn iHwOsP6q74OIUmNGz8QKBLQK/o3AQqNcrJs/2FLxxW/1Ak6vwzNIeUNuH 80fDLOZs4WXjHshC9KkLqw1dXv9vdVzOkBVFZMHpbbzBEkJ9frtuU0wRA k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAJ+LPVStJA2H/2dsb2JhbABbgkhGU1zUAwKBFhYBfYQDAQEELUwQAgEIEhAkMhcOAgQODYg2xzABAQEBAQEBAQEBAQEBAQEBAQEBAQEXj20BJg0kBwKDK4EeBZF5jQCQZYN+g3eBcgEBHgYcgQIBAQE X-IronPort-AV: E=Sophos;i="5.04,719,1406592000"; d="scan'208,217";a="363267377" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-5.cisco.com with ESMTP; 14 Oct 2014 20:49:20 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s9EKnJpq029891 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Oct 2014 20:49:19 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.163]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Tue, 14 Oct 2014 15:49:19 -0500 From: "Alexander Clemm (alex)" To: Andy Bierman Thread-Topic: [netmod] New revision of YANG mount draft Thread-Index: AQHP40Rf8kMXz8u2QICzU6EjzD0qC5wopeSAgAGEYAD//6x3sIAAX9yAgARbs4CAADEkAP//+2DwgAFY1YD///sIkA== Date: Tue, 14 Oct 2014 20:49:18 +0000 Message-ID: References: <20141010210934.GB80385@elstar.local> <20141010215341.GD80385@elstar.local> <20141013192248.GA68615@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.218.195] Content-Type: multipart/alternative; boundary="_000_DBC595ED2346914F9F81D17DD5C32B571C81B61Fxmbrcdx05ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Fkxf6ykrWcz4iXvJKRE1PZ95-yg Cc: "netmod@ietf.org" Subject: Re: [netmod] New revision of YANG mount draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2014 20:49:25 -0000 --_000_DBC595ED2346914F9F81D17DD5C32B571C81B61Fxmbrcdx05ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Andy, ... Re: overall architecture, you are bringing up an interesting point that pro= bably needs visiting. RFC 6244, in section 3.1, clearly depicts the bounda= ry of the server as one device. This is intentional and IMO the proper architecture for a NETCONF datastore= . The datastore is intended to represent one device, whether that device is a= giant network controller or a tiny access point. I don't agree that replication of subtrees from other servers is the proper= architecture for a network-wide datastore. It doesn't matter for monitoring, but for editin= g the subtrees are all part of 1 configuration datastore, not isolated replicated subtrees= . Yes, the current architecture has a NETCONF datastore clearly delimi= ted within the boundaries of a device. This makes for a simple architectur= e, continuing what we have grown used to e.g. with SNMP, but also a bit lim= ited. For one, if you have to deal with a network with many devices, it me= ans that each of these devices exist purely in isolation; interdependencies= between devices have to be dealt with at a different layer. Also, with SD= N, NFV etc, boundaries between devices become increasingly "blurry" and mat= ter less than they have in the past; IMHO it would be good if the architect= ure would reflect that by not necessarily tieing itself to physical device = boundaries which may be increasingly constraining. Thirdly, the fact that = the architecture ties the datastore to Netconf is a problem as well; we see= with RESTconf alternative transports to emerge, and the fact that a datast= ore can contain operational data as well and given Netconf is not an ideal = match for service assurance applications may mean that it will be good to b= e able to support additional transports/services in the future. Either tha= t, or keep Netconf and YANG to a "niche" set of applications limited to dev= ice configuration - but I for one think that the opportunity is greater tha= n that. For that reason, I would like to see the architecture be able to al= low to accommodate straightforward extensions like the one proposed. It also suggests that the datastore does not reach beyond the device bounda= ries (datastore is actually not depicted, but config database and "system s= oftware components" - presumably for the config data). This is why we beli= eve the mount capability is needed - to allow the datastore to reach beyond= those boundaries. If this involves extending the architecture, then so be= it. Worth mentioning along the same lines, since RFC 6244 assumes that YA= NG will be always used in conjunction with Netconf: Really, we would like t= o consider Netconf just one particular transport / set of services that can= operate on / interact with a datastore, geared towards configuration and f= ulfillment-related use cases. That should not rule out the possibility to = apply other transports and services - such as RESTconf (the possi bility for which is not considered in the RFC), and going forward possibly= other transports/ interfaces, that for example focus on pushing datastore = information and operational data for applications which today might use SNM= P. Regarding making this transparent for all Netconf operations: The importan= t aspect and primary focus of the use case lies in providing an ability to = retrieve remote information. The motivation behind all this is not to prov= id "ACID" style management transactions across the network - in fact, we be= lieve that for many applications a "BASE" style of management is preferrabl= e and more appropriate, in which transactional guarantees, ability to rollb= ack,etc, are not provided as long as state becomes eventually consistent. T= his is also reflected in the companion requirements spec. We do not want t= o be bogged down in the aspects that would be required to make ACID work. = While we believe that "simple" configuration (not including transactions sp= anning multiple items) is achievable, we are happy to "scale down" the moun= t concept accordingly and leave transactionality or even configuration as a= whole out of scope. I don't see what is stopping you from implementing your controller. If you wrap the remote config in anyxml, then all the YANG validation problems go away. The controller can send NETCONF requests to the remote d= evices on behalf of the northbound client. This seems like just an implementatio= n detail for the controller, not a standards issue. As discussed earlier on the thread, the primary use cases revolve around in= formation retrieval more than the ability to configure stuff, so we are hap= py to limit the proposal to just that aspect. For retrieval, we want howev= er to do a bit better than anyxml, for analogous reasons for which YANG was= defined (which includes support for non-configuration data, not just simpl= y addressed through anyxml either). IPFIX is one option, although what we had in mind was more in line with the= Netconf/YANG framework itself. Either way, agree it is a separate matter = which needs to be addressed separately. Thanks --- Alex --_000_DBC595ED2346914F9F81D17DD5C32B571C81B61Fxmbrcdx05ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Andy,

 <= /p>

 <= /p>

...


Re: overall architecture, you are bringing up an interesting point that pro= bably needs visiting.  RFC 6244, in section 3.1, clearly depicts the b= oundary of the server as one device. 

 

This is intentional and IMO the proper architecture = for a NETCONF datastore.

The datastore is intended to represent one device, w= hether that device is a giant

network controller or a tiny access point.

 

I don't agree that replication of subtrees from othe= r servers is the proper architecture for

a network-wide datastore.  It doesn't matter fo= r monitoring, but for editing the subtrees

are all part of 1 configuration datastore, not isola= ted replicated subtrees.  

 

<ALEX> Yes, the = current architecture has a NETCONF datastore clearly delimited within the b= oundaries of a device.  This makes for a simple architecture, continui= ng what we have grown used to e.g. with SNMP, but also a bit limited.  For one, if you have to deal with a network with= many devices, it means that each of these devices exist purely in isolatio= n; interdependencies between devices have to be dealt with at a different l= ayer.  Also, with SDN, NFV etc, boundaries between devices become increasingly “blurry” and matter less t= han they have in the past; IMHO it would be good if the architecture would = reflect that by not necessarily tieing itself to physical device boundaries= which may be increasingly constraining.  Thirdly, the fact that the architecture ties the datastore to Netconf is a problem = as well; we see with RESTconf alternative transports to emerge, and the fac= t that a datastore can contain operational data as well and given Netconf i= s not an ideal match for service assurance applications may mean that it will be good to be able to support= additional transports/services in the future.  Either that, or keep N= etconf and YANG to a “niche” set of applications limited to dev= ice configuration – but I for one think that the opportunity is greater than that. For that reason, I would like to see the= architecture be able to allow to accommodate straightforward extensions li= ke the one proposed.   

</ALEX><= /span>

 

It also suggests that= the datastore does not reach beyond the device boundaries (datastore is ac= tually not depicted, but config database and "system software componen= ts" - presumably for the config data).  This is why we believe the mount capability is needed - to allow the datastore = to reach beyond those boundaries.  If this involves extending the arch= itecture, then so be it.  Worth mentioning along the same lines, since= RFC 6244 assumes that YANG will be always used in conjunction with Netconf: Really, we would like to consider Netcon= f just one particular transport / set of services that can operate on / int= eract with a datastore, geared towards configuration and fulfillment-relate= d use cases.  That should not rule out the possibility to apply other transports and services - such as RESTc= onf (the possi
 bility for which is not considered in the RFC), and going forward pos= sibly other transports/ interfaces, that for example focus on pushing datas= tore information and operational data for applications which today might us= e SNMP.

Regarding making this transparent for all Netconf operations:  The imp= ortant aspect and primary focus of the use case lies in providing an abilit= y to retrieve remote information.  The motivation behind all this is n= ot to provid "ACID" style management transactions across the network - in fact, we believe that for many applications a &quo= t;BASE" style of management is preferrable and more appropriate, in wh= ich transactional guarantees, ability to rollback,etc, are not provided as = long as state becomes eventually consistent. This is also reflected in the companion requirements spec.  We do not= want to be bogged down in the aspects that would be required to make ACID = work.  While we believe that "simple" configuration (not inc= luding transactions spanning multiple items) is achievable, we are happy to "scale down" the mount concept accordingly and l= eave transactionality or even configuration as a whole out of scope.

 

I don't see what is stopping you from implementing y= our controller.

If you wrap the remote config in anyxml, then all th= e YANG validation

problems go away.  The controller can send NETC= ONF requests to the remote devices

on behalf of the northbound client.   This seem= s like just an implementation detail

for the controller, not a standards issue.

 <= /p>

<ALEX>

As discussed earlier on t= he thread, the primary use cases revolve around information retrieval more = than the ability to configure stuff, so we are happy to limit the proposal to just that aspect.  For retrieval, we want howev= er to do a bit better than anyxml, for analogous reasons for which YANG was= defined (which includes support for non-configuration data, not just simpl= y addressed through anyxml either). 

</ALEX

 

The request to have the devices push all their opera= tional data to the controller

is a different matter.  That has a huge operati= onal impact, and something that

NETCONF is not designed for.  I suggest using I= PFIX for that.

 

<ALEX>

IPFIX is one option, alth= ough what we had in mind was more in line with the Netconf/YANG framework i= tself.  Either way, agree it is a separate matter which needs to be addressed separately. 

</ALEX><= /span>

 

Thanks


--- Alex

--_000_DBC595ED2346914F9F81D17DD5C32B571C81B61Fxmbrcdx05ciscoc_-- From nobody Tue Oct 14 15:20:00 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB811A0016 for ; Tue, 14 Oct 2014 15:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.286 X-Spam-Level: X-Spam-Status: No, score=-15.286 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4cxA5_wwSb8 for ; Tue, 14 Oct 2014 15:19:37 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 607EE1A0006 for ; Tue, 14 Oct 2014 15:19:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=46410; q=dns/txt; s=iport; t=1413325177; x=1414534777; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=M/0b61OZeYBMSFMssstP5cn8/2/pRmhhqFhWjJKTFco=; b=AErquR6ahiZnxSiiuLxhAc2TGAFtemumQmk7RCqVA/2mi1Eby6biAeRm lKpAS3wMQrupEgcIwvixJjkEpGn0fS59ZG1I7HDfVjKZBGkh57GxOZrhR 1zoxRz6dRE0ghAh88y2+GZ8APzyugVXc/JM+to3BpFmEP0SMzQcBfWkI0 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAOagPVStJA2I/2dsb2JhbABYA4JIRlNYBMwsAQmGeVQCgREWAX2EAgEBAQMBAQEBFxNBCwwCAgIBCA4CAQECAQEBAQoCFAEGBxsMCxQDBggCBAENBQgTiBsIDcclAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwSQECABDAQGAQYDCIMcgR4FkXmNAIZziXKDfoN3bIEIJByBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,719,1406592000"; d="scan'208,217";a="363296807" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-6.cisco.com with ESMTP; 14 Oct 2014 22:19:34 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s9EMJYgi015207 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Oct 2014 22:19:34 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.41]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Tue, 14 Oct 2014 17:19:34 -0500 From: "Eric Voit (evoit)" To: Kent Watsen , Andy Bierman , "Alexander Clemm (alex)" Thread-Topic: [netmod] New revision of YANG mount draft Thread-Index: AQHP5NSnXWBBH+aajkuz6A/yEBcVLJwuAk1QgAC+AACAAFwLAIAA+CqAgABD8YD//8hjEA== Date: Tue, 14 Oct 2014 22:19:33 +0000 Message-ID: References: <20141010210934.GB80385@elstar.local> <20141010215341.GD80385@elstar.local> <20141013192248.GA68615@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.134.135] Content-Type: multipart/alternative; boundary="_000_EF64FF31F4C4384DBCE5D513A791C2B120A46152xmbalnx11ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/IvyTpUCrD_LQeeduhXF-SEBHvQo Cc: "netmod@ietf.org" Subject: Re: [netmod] New revision of YANG mount draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2014 22:19:51 -0000 --_000_EF64FF31F4C4384DBCE5D513A791C2B120A46152xmbalnx11ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kent, There are multiple reasons why current NETCONF based solutions don't hit al= l the requirements discussed during the thread. Below is a short incomplet= e list... (1) New Service types require systems built upon Eventually Consistency. If= we want to distribute read-only data fast, we might choose transports othe= r than NETCONF. We might choose protocols which aren't connection oriented= . We might even choose to use Multicast distribution. (Imagine hundreds o= f VMs reacting to dynamic global config being delivered from a single defin= itive source.) Such alternative transports can remove the burden from the = single central system processing knowing and maintaining connections with e= ach of the devices. (2) There is nothing specific to YANG syntax which makes it only applicable= to EMS. Or specific to point-to-point connection oriented delivery. The= syntax is useful (and used) elsewhere. (3) Once we establish that Netconf is not optimal for all transport options= , using a common (YANG) syntax across multiple transports is demonstrably v= aluable. This allows transport optimizations to be abstracted away from lo= gical information model design. (4) There are already multiple types of controllers in the network. Each u= se their own specific protocol to exchange config and status. Why ignore t= hat there are already multi-device abstractions in the network? Why ignore= that treating aggregates only by device boundary units can and will drive = errors into a system? Configuring each device individually is error pron= e for some abstractions. (5) Providing visibility into a peer's persistent and running config data c= an be very useful. (6) Many of these new services can reside within network elements just as e= asily as within controllers. Why would we create unnecessary technology ba= rriers based on historic roles? (7) There is huge investment in multiple places on this type of technology = (e.g., OpenDaylight Mount, DDS). Why fight against trends proving successf= ul already? The IETF should incorporate these capabilities where advantag= eous. IMHO it is in the IETF interests to support fulfill these requirements. If= we don't ownership will go elsewhere. There are already implementations d= riven by the list of imperatives above. Eric From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Kent Watsen Sent: Tuesday, October 14, 2014 3:44 PM To: Andy Bierman; Alexander Clemm (alex) Cc: netmod@ietf.org Subject: Re: [netmod] New revision of YANG mount draft This conversation is going full-circle, so I'll go back to my original poin= t - that I don't understand the importance for IETF standardization and que= stion the effectiveness of the solution. EMS systems managing devices using NETCONF/YANG have been around for a few = years. It is pretty common for them to 1) provide a mechanism to get the Y= ANG module used by a device and 2) a low-level API to get/set device-specif= ic config (as modeled by its YANG) - all with clear separation of which sys= tem "owns" which data. This draft proposes to fulfill the same need, but= in a way that is unique to a Controller/EMS that itself presents a YANG-de= fined NETCONF/RESTCONF model. Under those circumstances, I can almost und= erstand the line of thinking that led to "mounting" idea (why not, right?),= but is this really how a higher-level OSS/BSS would want it presented. Wh= y wouldn't the higher-level system use NETCONF to the device directly? - w= hat semantics does "mounting" bring above and beyond a direct connection to= the device (approval-workflow or network-wide transactional-updates?) To Tom's point, it's not enough that some products implement an idea for th= ere to be a need to add it to a WG charter. I'd rather see pressing intero= perability considerations driving that. All that said, I do support the idea of enhancing NETCONF notifications, if= RFC6470's netconf-config-change event isn't sufficient. If there is a def= iciency there, then all NETCONF clients (not "mount clients") would benefit= . Thanks, Kent From: Andy Bierman > Date: Tuesday, October 14, 2014 at 11:40 AM To: "Alexander Clemm (alex)" > Cc: "netmod@ietf.org" > Subject: Re: [netmod] New revision of YANG mount draft On Mon, Oct 13, 2014 at 5:52 PM, Alexander Clemm (alex) > wrote: Hi Juergen, (several threads to respond to; Eric already provided responses to a lot of= the items, here just a few summary items from my perspective) Re: what technical details we think should be standardized: - The first aspect is the YANG extension that allows users to define mountp= oints (to logically incorporate subtrees from a remote datastore under a da= ta node). This can be done as part of a YANG module, i.e. is data model re= lated. - The second aspect is a YANG data model that allows to monitor and manage = a "mount topology". This addresses the system management aspects of this c= oncept, generally not of concern to the applications that want to simply ac= cess the datastore, but required for a "complete" solution. Again, this ca= n be done as part of a YANG module, i.e. is data model related. - The third aspect concerns the ability to subscribe to updates to a YANG d= atatree, and "push" those updates. This is more general than mount itself = and should presumably be separated into a separate draft. Subscriptions ca= n be represented as a configurable data model. Likewise, push can occur th= rough notifications, definable as part of a data model related. So, that o= ne too is data model related. (It is conceivable to also introduce differe= nt transports here, which would be discussion for a transport forum; howeve= r, our intent was to address these within the existing framework.) Re: overall architecture, you are bringing up an interesting point that pro= bably needs visiting. RFC 6244, in section 3.1, clearly depicts the bounda= ry of the server as one device. This is intentional and IMO the proper architecture for a NETCONF datastore= . The datastore is intended to represent one device, whether that device is a= giant network controller or a tiny access point. I don't agree that replication of subtrees from other servers is the proper= architecture for a network-wide datastore. It doesn't matter for monitoring, but for editin= g the subtrees are all part of 1 configuration datastore, not isolated replicated subtrees= . It also suggests that the datastore does not reach beyond the device bounda= ries (datastore is actually not depicted, but config database and "system s= oftware components" - presumably for the config data). This is why we beli= eve the mount capability is needed - to allow the datastore to reach beyond= those boundaries. If this involves extending the architecture, then so be= it. Worth mentioning along the same lines, since RFC 6244 assumes that YA= NG will be always used in conjunction with Netconf: Really, we would like t= o consider Netconf just one particular transport / set of services that can= operate on / interact with a datastore, geared towards configuration and f= ulfillment-related use cases. That should not rule out the possibility to = apply other transports and services - such as RESTconf (the possi bility for which is not considered in the RFC), and going forward possibly= other transports/ interfaces, that for example focus on pushing datastore = information and operational data for applications which today might use SNM= P. Regarding making this transparent for all Netconf operations: The importan= t aspect and primary focus of the use case lies in providing an ability to = retrieve remote information. The motivation behind all this is not to prov= id "ACID" style management transactions across the network - in fact, we be= lieve that for many applications a "BASE" style of management is preferrabl= e and more appropriate, in which transactional guarantees, ability to rollb= ack,etc, are not provided as long as state becomes eventually consistent. T= his is also reflected in the companion requirements spec. We do not want t= o be bogged down in the aspects that would be required to make ACID work. = While we believe that "simple" configuration (not including transactions sp= anning multiple items) is achievable, we are happy to "scale down" the moun= t concept accordingly and leave transactionality or even configuration as a= whole out of scope. I don't see what is stopping you from implementing your controller. If you wrap the remote config in anyxml, then all the YANG validation problems go away. The controller can send NETCONF requests to the remote d= evices on behalf of the northbound client. This seems like just an implementatio= n detail for the controller, not a standards issue. The request to have the devices push all their operational data to the cont= roller is a different matter. That has a huge operational impact, and something t= hat NETCONF is not designed for. I suggest using IPFIX for that. --- Alex Andy -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: Monday, October 13, 2014 12:23 PM To: Eric Voit (evoit) Cc: Alexander Clemm (alex); netmod@ietf.org Subject: Re: [netmod] New revision of YANG mount draft On Mon, Oct 13, 2014 at 04:26:55PM +0000, Eric Voit (evoit) wrote: > > From: Juergen Schoenwaelder, October 10, 2014 5:54 PM > > > > I still fail to see how all this falls out of RFC 6020. > > If by falling out you mean 'in conflict with', then I would agree that th= ere are not backwards compatibility issues with RFC 6020 section 6 syntax. = This was by design. > > However I believe Alex' and Jan's concerns are with Section 5.1 of RFC 60= 20. This section includes statements such as: "For a module or submodule= to reference definitions in an external module, the external module MUST b= e imported." > > Bringing in targeted nodes and subtrees need not require visibility into = the full submodule where the authoritative copy of the object might reside. > There is anyxml in YANG 1.0 and there is a proposal for anydata in YANG 1.1= . > > I see protocol discussion in draft-clemm-netmod-mount-02.txt (which > > is needed for what you want to do and likely even incomplete) but > > then the NETMOD WG is not about protocol work but about the data > > modeling language YANG and data models. In fact, my reading of the > > I-D is that you do not request to change anything in YANG at all - > > all you propose is to define a few extensions and a data model. > > The 'on-demand' Mount does not need any protocol work. It is the easiest= , and is looking to standardize needed several syntax extensions. This typ= e of Mount is what is implemented in OpenDaylight today. > I am not sure. Can I run all NETCONF protocol operations transparently acro= ss these mount points? I doubt it. What you introduce is a "partitioning" of a datastore that does not archite= cturally exist so far. Does this lead to a new type of datastore or can I p= artition any datastore? How does this partitioning interact with ephemeral = datastores discussed in I2RS? I believe there are serious _architectural_ q= uestions that need to be discussed and depending on how they are resolved, = there may be more or less protocol work needed. What triggered this discussions were statements of the form "YANG does not = allow to do X" which I think is not correct since YANG really is not the is= sue. The mount work is extending/modifying/$(your-verb-here) the _architecture_ of NETCONF and YANG. It is not clear which WG is respons= ible for the underlying architecture. RFC 6244 was produced by NETMOD but t= hen it describes more the framework and not the underlying architectural mo= del (what Randy Presuhn I think calls the meta model). Perhaps we need to w= ork on an architecture at some point in time, pretty much like we needed to= define an architecture for SNMP at some point in time. The work on JSON en= coding and the mount proposal clearly indicates that certain architectural = assumptions are implicit and that leads to discussions that are difficult t= o close until we agree on an architecture. Who said history does not repeat? /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 --_000_EF64FF31F4C4384DBCE5D513A791C2B120A46152xmbalnx11ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Kent,

 <= /p>

There are multiple reason= s why current NETCONF based solutions don’t hit all the requirements = discussed during the thread.  Below is a short incomplete list…<= o:p>

 <= /p>

(1) New Service types req= uire systems built upon Eventually Consistency. If we want to distribute re= ad-only data fast, we might choose transports other than NETCONF.  We might choose protocols which aren’t connection ori= ented.  We might even choose to use Multicast distribution.  (Ima= gine hundreds of VMs reacting to dynamic global config being delivered from= a single definitive source.)  Such alternative transports can remove the burden from the single central system processing knowing an= d maintaining connections with each of the devices.

 <= /p>

(2) There is nothing spec= ific to YANG syntax which makes it only applicable to EMS.   Or s= pecific to point-to-point connection oriented delivery.  The syntax is useful (and used) elsewhere.

 <= /p>

(3) Once we establish tha= t Netconf is not optimal for all transport options, using a common (YANG) s= yntax across multiple transports is demonstrably valuable.  This allows transport optimizations to be abstracted away from logical inf= ormation model design.

 <= /p>

(4) There are already mul= tiple types of controllers in the network.  Each use their own specifi= c protocol to exchange config and status.  Why ignore that there are already multi-device abstractions in the network?  Why ignore tha= t treating aggregates only by device boundary units can and will drive erro= rs into a system?    Configuring each device individually is= error prone for some abstractions. 

 <= /p>

(5) Providing visibility = into a peer’s persistent and running config data can be very useful.

 <= /p>

(6) Many of these new ser= vices can reside within network elements just as easily as within controlle= rs.  Why would we create unnecessary technology barriers based on historic roles?

 <= /p>

(7) There is huge investm= ent in multiple places on this type of technology (e.g., OpenDaylight Mount= , DDS).  Why fight against trends proving successful already? &nb= sp; The IETF should incorporate these capabilities where advantageous.

 <= /p>

IMHO it is in the IETF in= terests to support fulfill these requirements.  If we don’t owne= rship will go elsewhere.  There are already implementations driven by the list of imperatives above.

 <= /p>

Eric

 <= /p>

From: netmod [= mailto:netmod-bounces@ietf.org] On Behalf Of Kent Watsen
Sent: Tuesday, October 14, 2014 3:44 PM
To: Andy Bierman; Alexander Clemm (alex)
Cc: netmod@ietf.org
Subject: Re: [netmod] New revision of YANG mount draft

 

 

This conversation is going = full-circle, so I'll go back to my original point - that I don't understand= the importance for IETF standardization and question the effectiveness of the solution.

 

EMS systems managing device= s using NETCONF/YANG have been around for a few years.  It is pretty c= ommon for them to 1) provide a mechanism to get the YANG module used by a device and 2) a low-level API to get/set device-specific config = (as modeled by its YANG) - all with clear separation of which system "= owns" which data.    This draft proposes to fulfill the same= need, but in a way that is unique to a Controller/EMS that itself presents a YANG-defined NETCONF/RESTCONF model.   Under t= hose circumstances, I can almost understand the line of thinking that led t= o "mounting" idea (why not, right?), but is this really how a hig= her-level OSS/BSS would want it presented.  Why wouldn't the higher-level system use NETCONF to the device directly?  = ;- what semantics does "mounting" bring above and beyond a direct= connection to the device (approval-workflow or network-wide transactional-= updates?) 

 

To Tom's point, it's not en= ough that some products implement an idea for there to be a need to add it = to a WG charter.  I'd rather see pressing interoperability considerations driving that.

 

All that said, I do support= the idea of enhancing NETCONF notifications, if RFC6470's netconf-config-c= hange event isn't sufficient.  If there is a deficiency there, then all NETCONF clients (not "mount clients") would bene= fit.

 

Thanks,

Kent

 

 

From: Andy Bierman <andy@yumaworks.com>
Date: Tuesday, October 14, 2014 at 11:40 AM
To: "Alexander Clemm (alex)" <alex@cisco.com>
Cc: "netmod@ietf.org&quo= t; <netmod@ietf.org>
Subject: Re: [netmod] New revision of YANG mount draft

 

 

 

On Mon, Oct 13, 2014 at 5:5= 2 PM, Alexander Clemm (alex) <alex@cisco.com> wrote:

Hi Juergen,
(several threads to respond to; Eric already provided responses to a lot of= the items, here just a few summary items from my perspective)

Re: what technical details we think should be standardized:

- The first aspect is the YANG extension that allows users to define mountp= oints (to logically incorporate subtrees from a remote datastore under a da= ta node).  This can be done as part of a YANG module, i.e. is data mod= el related.

- The second aspect is a YANG data model that allows to monitor and manage = a "mount topology".  This addresses the system management as= pects of this concept, generally not of concern to the applications that wa= nt to simply access the datastore, but required for a "complete" solution.  Again, this can be done as part= of a YANG module, i.e. is data model related.

- The third aspect concerns the ability to subscribe to updates to a YANG d= atatree, and "push" those updates.  This is more general tha= n mount itself and should presumably be separated into a separate draft.&nb= sp; Subscriptions can be represented as a configurable data model.  Likewise, push can occur through notifications, definabl= e as part of a data model related.  So, that one too is data model rel= ated.  (It is conceivable to also introduce different transports here,= which would be discussion for a transport forum; however, our intent was to address these within the existing framework.)
Re: overall architecture, you are bringing up an interesting point that pro= bably needs visiting.  RFC 6244, in section 3.1, clearly depicts the b= oundary of the server as one device. 

 

 

This is intentional and IMO= the proper architecture for a NETCONF datastore.

The datastore is intended t= o represent one device, whether that device is a giant

network controller or a tin= y access point.

 

I don't agree that replicat= ion of subtrees from other servers is the proper architecture for

a network-wide datastore.&n= bsp; It doesn't matter for monitoring, but for editing the subtrees

are all part of 1 configura= tion datastore, not isolated replicated subtrees.  <= /p>

 

 

 

It also suggests that the datastore does not reach beyond the device bo= undaries (datastore is actually not depicted, but config database and "system software components" - presumably for the config dat= a).  This is why we believe the mount capability is needed - to allow = the datastore to reach beyond those boundaries.  If this involves exte= nding the architecture, then so be it.  Worth mentioning along the same lines, since RFC 6244 assumes that YANG will be always used= in conjunction with Netconf: Really, we would like to consider Netconf jus= t one particular transport / set of services that can operate on / interact= with a datastore, geared towards configuration and fulfillment-related use cases.  That should not rul= e out the possibility to apply other transports and services - such as REST= conf (the possi
 bility for which is not considered in the RFC), and going forward pos= sibly other transports/ interfaces, that for example focus on pushing datas= tore information and operational data for applications which today might us= e SNMP.

Regarding making this transparent for all Netconf operations:  The imp= ortant aspect and primary focus of the use case lies in providing an abilit= y to retrieve remote information.  The motivation behind all this is n= ot to provid "ACID" style management transactions across the network - in fact, we believe that for many applications a &quo= t;BASE" style of management is preferrable and more appropriate, in wh= ich transactional guarantees, ability to rollback,etc, are not provided as = long as state becomes eventually consistent. This is also reflected in the companion requirements spec.  We do not= want to be bogged down in the aspects that would be required to make ACID = work.  While we believe that "simple" configuration (not inc= luding transactions spanning multiple items) is achievable, we are happy to "scale down" the mount concept accordingly and l= eave transactionality or even configuration as a whole out of scope.

 

I don't see what is stoppin= g you from implementing your controller.

If you wrap the remote conf= ig in anyxml, then all the YANG validation

problems go away.  The= controller can send NETCONF requests to the remote devices

on behalf of the northbound= client.   This seems like just an implementation detail

for the controller, not a s= tandards issue.

 

The request to have the dev= ices push all their operational data to the controller

is a different matter. = ; That has a huge operational impact, and something that<= /p>

NETCONF is not designed for= .  I suggest using IPFIX for that.

 

 

 


--- Alex

 

Andy

 

 

-----Original Message-----<= br> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]
Sent: Monday, October 13, 2014 12:23 PM
To: Eric Voit (evoit)
Cc: Alexander Clemm (alex); netmod@ietf.= org
Subject: Re: [netmod] New revision of YANG mount draft

On Mon, Oct 13, 2014 at 04:26:55PM +0000, Eric Voit (evoit) wrote:
> > From: Juergen Schoenwaelder, October 10, 2014 5:54 PM
> >
> > I still fail to see how all this falls out of RFC 6020.
>
> If by falling out you mean 'in conflict with', then I would agree that= there are not backwards compatibility issues with RFC 6020 section 6 synta= x.  This was by design.
>
> However I believe Alex' and Jan's concerns are with Section 5.1 of RFC= 6020.   This section includes statements such as:  "Fo= r a module or submodule to reference definitions in an external module, the= external module MUST be imported."
>
> Bringing in targeted nodes and subtrees need not require visibility in= to the full submodule where the authoritative copy of the object might resi= de.
>

There is anyxml in YANG 1.0 and there is a proposal for anydata in YANG 1.1= .

> > I see protocol discussion in draft-clemm-netmod-mount-02.txt (whi= ch
> > is needed for what you want to do and likely even incomplete) but=
> > then the NETMOD WG is not about protocol work but about the data<= br> > > modeling language YANG and data models. In fact, my reading of th= e
> > I-D is that you do not request to change anything in YANG at all = -
> > all you propose is to define a few extensions and a data model. >
> The 'on-demand' Mount does not need any protocol work.  It is the= easiest, and is looking to standardize needed several syntax extensions.&n= bsp; This type of Mount is what is implemented in OpenDaylight today.
>

I am not sure. Can I run all NETCONF protocol operations transparently acro= ss these mount points? I doubt it.

What you introduce is a "partitioning" of a datastore that does n= ot architecturally exist so far. Does this lead to a new type of datastore = or can I partition any datastore? How does this partitioning interact with = ephemeral datastores discussed in I2RS? I believe there are serious _architectural_ questions that need to be discus= sed and depending on how they are resolved, there may be more or less proto= col work needed.

What triggered this discussions were statements of the form "YANG does= not allow to do X" which I think is not correct since YANG really is = not the issue. The mount work is extending/modifying/$(your-verb-here)
the _architecture_ of NETCONF and YANG. It is not clear which WG is respons= ible for the underlying architecture. RFC 6244 was produced by NETMOD but t= hen it describes more the framework and not the underlying architectural mo= del (what Randy Presuhn I think calls the meta model). Perhaps we need to work on an architecture at some = point in time, pretty much like we needed to define an architecture for SNM= P at some point in time. The work on JSON encoding and the mount proposal c= learly indicates that certain architectural assumptions are implicit and that leads to discussions that are difficult = to close until we agree on an architecture.

Who said history does not repeat?

/js

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

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

 

--_000_EF64FF31F4C4384DBCE5D513A791C2B120A46152xmbalnx11ciscoc_-- From nobody Tue Oct 14 15:47:49 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 919111A0043 for ; Tue, 14 Oct 2014 15:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTbf842ZJsDB for ; Tue, 14 Oct 2014 15:47:31 -0700 (PDT) Received: from mail-qg0-f54.google.com (mail-qg0-f54.google.com [209.85.192.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E2141A000C for ; Tue, 14 Oct 2014 15:47:31 -0700 (PDT) Received: by mail-qg0-f54.google.com with SMTP id z107so61360qgd.13 for ; Tue, 14 Oct 2014 15:47:30 -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=erI9Hauouhcf90AkUaLbJMndlzjKjZDd6X1rnJa1ppM=; b=LmWeK0Vx54eT4k5rw4QXap9nP/YZ55Cslj+tKgdqpdc40F45PFre1bz5giNHfXUPlc QMPQ8gCqRQsiEDD+GHOQoluCkxpEtHcVhuIJFUcrHm7hSz27M9jxP0QFkt/1x9ReBOm5 b7e80TX0OHAG8dLv3N9i8mpaRGYkfnIB/TsReQIBGOvfObdMsbodPINLOpVSi47SRnNl 9nota1okVK/nxI6piC2fc5tCGN+Hg+xUComRGnS39EnJICbIOEQMbwPnAiZaKYjBd6It egbywHyL/hda6pSaZ89J54vMIG7NlCu3qeLYPiyt5H/2s7zY2RTljXZ8N8fDjkE4vSPm RwSA== X-Gm-Message-State: ALoCoQmYqfA0vIgP1I/D6gWuBtd6jprt5jWRooCuDbtFBM0NS9yi+3V4Mzx6NhIbSwt4XagyqPUA MIME-Version: 1.0 X-Received: by 10.224.28.133 with SMTP id m5mr14191182qac.7.1413326850347; Tue, 14 Oct 2014 15:47:30 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Tue, 14 Oct 2014 15:47:30 -0700 (PDT) In-Reply-To: References: <20141010210934.GB80385@elstar.local> <20141010215341.GD80385@elstar.local> <20141013192248.GA68615@elstar.local> Date: Tue, 14 Oct 2014 15:47:30 -0700 Message-ID: From: Andy Bierman To: "Eric Voit (evoit)" Content-Type: multipart/alternative; boundary=001a11c1db70ddeb8b050569cc3b Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/jjNYoWEiT_gN3pY6pPC0-uj4h-U Cc: "netmod@ietf.org" Subject: Re: [netmod] New revision of YANG mount draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 14 Oct 2014 22:47:42 -0000 --001a11c1db70ddeb8b050569cc3b Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 14, 2014 at 3:19 PM, Eric Voit (evoit) wrote: > Hi Kent, > > > > There are multiple reasons why current NETCONF based solutions don't hit > all the requirements discussed during the thread. Below is a short > incomplete list... > > > > (1) New Service types require systems built upon Eventually Consistency. > If we want to distribute read-only data fast, we might choose transports > other than NETCONF. We might choose protocols which aren't connection > oriented. We might even choose to use Multicast distribution. (Imagine > hundreds of VMs reacting to dynamic global config being delivered from a > single definitive source.) Such alternative transports can remove the > burden from the single central system processing knowing and maintaining > connections with each of the devices. > > > > (2) There is nothing specific to YANG syntax which makes it only > applicable to EMS. Or specific to point-to-point connection oriented > delivery. The syntax is useful (and used) elsewhere. > > > > (3) Once we establish that Netconf is not optimal for all transport > options, using a common (YANG) syntax across multiple transports is > demonstrably valuable. This allows transport optimizations to be > abstracted away from logical information model design. > > > > (4) There are already multiple types of controllers in the network. Each > use their own specific protocol to exchange config and status. Why ignore > that there are already multi-device abstractions in the network? Why > ignore that treating aggregates only by device boundary units can and will > drive errors into a system? Configuring each device individually is > error prone for some abstractions. > > I don't see what (1) - (4) have to do with replicating subtrees from multiple devices into a controller. New transports for NETCONF can be defined, if there is enough interest. It's OK if other protocols use YANG. NETCONF does not have to solve every problem. > > (5) Providing visibility into a peer's persistent and running config data > can be very useful. > There are protocol-specific modules for that. Topology is a good example of what I mean by collection of devices vs. network-view. An EMS could collect the neighbor tables from all the devices and replicate them for its northbound clients. Or it could resolve the device data into one network-wide view, dealing with duplicates, mobility, etc. I do not agree that the "collection of device models" is a very interesting solution for network management at the network level. We have dabbled with "network-wide" configuration a couple times, only to drop the issue. IMO the models at this level describe the network, not the devices. There is some glue that tells the controller what devices are available, and how to talk to them, but the goal is to handle the device level details as part of the controller data model implementation. > > (6) Many of these new services can reside within network elements just as > easily as within controllers. Why would we create unnecessary technology > barriers based on historic roles? > > > > (7) There is huge investment in multiple places on this type of technology > (e.g., OpenDaylight Mount, DDS). Why fight against trends proving > successful already? The IETF should incorporate these capabilities where > advantageous. > > > > IMHO it is in the IETF interests to support fulfill these requirements. > If we don't ownership will go elsewhere. There are already implementations > driven by the list of imperatives above. > > > > Eric > Andy > > > *From:* netmod [mailto:netmod-bounces@ietf.org] *On Behalf Of *Kent Watsen > *Sent:* Tuesday, October 14, 2014 3:44 PM > *To:* Andy Bierman; Alexander Clemm (alex) > *Cc:* netmod@ietf.org > *Subject:* Re: [netmod] New revision of YANG mount draft > > > > > > This conversation is going full-circle, so I'll go back to my original > point - that I don't understand the importance for IETF standardization and > question the effectiveness of the solution. > > > > EMS systems managing devices using NETCONF/YANG have been around for a few > years. It is pretty common for them to 1) provide a mechanism to get the > YANG module used by a device and 2) a low-level API to get/set > device-specific config (as modeled by its YANG) - all with clear separation > of which system "owns" which data. This draft proposes to fulfill the > same need, but in a way that is unique to a Controller/EMS that itself > presents a YANG-defined NETCONF/RESTCONF model. Under those > circumstances, I can almost understand the line of thinking that led to > "mounting" idea (why not, right?), but is this really how a higher-level > OSS/BSS would want it presented. Why wouldn't the higher-level system use > NETCONF to the device directly? - what semantics does "mounting" bring > above and beyond a direct connection to the device (approval-workflow or > network-wide transactional-updates?) > > > > To Tom's point, it's not enough that some products implement an idea for > there to be a need to add it to a WG charter. I'd rather see pressing > interoperability considerations driving that. > > > > All that said, I do support the idea of enhancing NETCONF notifications, > if RFC6470's netconf-config-change event isn't sufficient. If there is a > deficiency there, then all NETCONF clients (not "mount clients") would > benefit. > > > > Thanks, > > Kent > > > > > > *From: *Andy Bierman > *Date: *Tuesday, October 14, 2014 at 11:40 AM > *To: *"Alexander Clemm (alex)" > *Cc: *"netmod@ietf.org" > *Subject: *Re: [netmod] New revision of YANG mount draft > > > > > > > > On Mon, Oct 13, 2014 at 5:52 PM, Alexander Clemm (alex) > wrote: > > Hi Juergen, > (several threads to respond to; Eric already provided responses to a lot > of the items, here just a few summary items from my perspective) > > Re: what technical details we think should be standardized: > > - The first aspect is the YANG extension that allows users to define > mountpoints (to logically incorporate subtrees from a remote datastore > under a data node). This can be done as part of a YANG module, i.e. is > data model related. > > - The second aspect is a YANG data model that allows to monitor and manage > a "mount topology". This addresses the system management aspects of this > concept, generally not of concern to the applications that want to simply > access the datastore, but required for a "complete" solution. Again, this > can be done as part of a YANG module, i.e. is data model related. > > - The third aspect concerns the ability to subscribe to updates to a YANG > datatree, and "push" those updates. This is more general than mount itself > and should presumably be separated into a separate draft. Subscriptions > can be represented as a configurable data model. Likewise, push can occur > through notifications, definable as part of a data model related. So, that > one too is data model related. (It is conceivable to also introduce > different transports here, which would be discussion for a transport forum; > however, our intent was to address these within the existing framework.) > > Re: overall architecture, you are bringing up an interesting point that > probably needs visiting. RFC 6244, in section 3.1, clearly depicts the > boundary of the server as one device. > > > > > > This is intentional and IMO the proper architecture for a NETCONF > datastore. > > The datastore is intended to represent one device, whether that device is > a giant > > network controller or a tiny access point. > > > > I don't agree that replication of subtrees from other servers is the > proper architecture for > > a network-wide datastore. It doesn't matter for monitoring, but for > editing the subtrees > > are all part of 1 configuration datastore, not isolated replicated > subtrees. > > > > > > > > It also suggests that the datastore does not reach beyond the device > boundaries (datastore is actually not depicted, but config database and > "system software components" - presumably for the config data). This is > why we believe the mount capability is needed - to allow the datastore to > reach beyond those boundaries. If this involves extending the > architecture, then so be it. Worth mentioning along the same lines, since > RFC 6244 assumes that YANG will be always used in conjunction with Netconf: > Really, we would like to consider Netconf just one particular transport / > set of services that can operate on / interact with a datastore, geared > towards configuration and fulfillment-related use cases. That should not > rule out the possibility to apply other transports and services - such as > RESTconf (the possi > bility for which is not considered in the RFC), and going forward > possibly other transports/ interfaces, that for example focus on pushing > datastore information and operational data for applications which today > might use SNMP. > > Regarding making this transparent for all Netconf operations: The > important aspect and primary focus of the use case lies in providing an > ability to retrieve remote information. The motivation behind all this is > not to provid "ACID" style management transactions across the network - in > fact, we believe that for many applications a "BASE" style of management is > preferrable and more appropriate, in which transactional guarantees, > ability to rollback,etc, are not provided as long as state becomes > eventually consistent. This is also reflected in the companion requirements > spec. We do not want to be bogged down in the aspects that would be > required to make ACID work. While we believe that "simple" configuration > (not including transactions spanning multiple items) is achievable, we are > happy to "scale down" the mount concept accordingly and leave > transactionality or even configuration as a whole out of scope. > > > > I don't see what is stopping you from implementing your controller. > > If you wrap the remote config in anyxml, then all the YANG validation > > problems go away. The controller can send NETCONF requests to the remote > devices > > on behalf of the northbound client. This seems like just an > implementation detail > > for the controller, not a standards issue. > > > > The request to have the devices push all their operational data to the > controller > > is a different matter. That has a huge operational impact, and something > that > > NETCONF is not designed for. I suggest using IPFIX for that. > > > > > > > > > --- Alex > > > > Andy > > > > > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, October 13, 2014 12:23 PM > To: Eric Voit (evoit) > Cc: Alexander Clemm (alex); netmod@ietf.org > Subject: Re: [netmod] New revision of YANG mount draft > > On Mon, Oct 13, 2014 at 04:26:55PM +0000, Eric Voit (evoit) wrote: > > > From: Juergen Schoenwaelder, October 10, 2014 5:54 PM > > > > > > I still fail to see how all this falls out of RFC 6020. > > > > If by falling out you mean 'in conflict with', then I would agree that > there are not backwards compatibility issues with RFC 6020 section 6 > syntax. This was by design. > > > > However I believe Alex' and Jan's concerns are with Section 5.1 of RFC > 6020. This section includes statements such as: "For a module or > submodule to reference definitions in an external module, the external > module MUST be imported." > > > > Bringing in targeted nodes and subtrees need not require visibility into > the full submodule where the authoritative copy of the object might reside. > > > > There is anyxml in YANG 1.0 and there is a proposal for anydata in YANG > 1.1. > > > > I see protocol discussion in draft-clemm-netmod-mount-02.txt (which > > > is needed for what you want to do and likely even incomplete) but > > > then the NETMOD WG is not about protocol work but about the data > > > modeling language YANG and data models. In fact, my reading of the > > > I-D is that you do not request to change anything in YANG at all - > > > all you propose is to define a few extensions and a data model. > > > > The 'on-demand' Mount does not need any protocol work. It is the > easiest, and is looking to standardize needed several syntax extensions. > This type of Mount is what is implemented in OpenDaylight today. > > > > I am not sure. Can I run all NETCONF protocol operations transparently > across these mount points? I doubt it. > > What you introduce is a "partitioning" of a datastore that does not > architecturally exist so far. Does this lead to a new type of datastore or > can I partition any datastore? How does this partitioning interact with > ephemeral datastores discussed in I2RS? I believe there are serious > _architectural_ questions that need to be discussed and depending on how > they are resolved, there may be more or less protocol work needed. > > What triggered this discussions were statements of the form "YANG does not > allow to do X" which I think is not correct since YANG really is not the > issue. The mount work is extending/modifying/$(your-verb-here) > the _architecture_ of NETCONF and YANG. It is not clear which WG is > responsible for the underlying architecture. RFC 6244 was produced by > NETMOD but then it describes more the framework and not the underlying > architectural model (what Randy Presuhn I think calls the meta model). > Perhaps we need to work on an architecture at some point in time, pretty > much like we needed to define an architecture for SNMP at some point in > time. The work on JSON encoding and the mount proposal clearly indicates > that certain architectural assumptions are implicit and that leads to > discussions that are difficult to close until we agree on an architecture. > > Who said history does not repeat? > > /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 > > > --001a11c1db70ddeb8b050569cc3b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Tue, Oct 14, 2014 at 3:19 PM, Eric Voit (evoit) &l= t;evoit@cisco.com&= gt; wrote:

Hi Kent,

 

There are multiple reason= s why current NETCONF based solutions don’t hit all the requirements = discussed during the thread.  Below is a short incomplete list…=

 

(1) New Service types req= uire systems built upon Eventually Consistency. If we want to distribute re= ad-only data fast, we might choose transports other than NETCONF.  We might choose protocols which aren’t connection ori= ented.  We might even choose to use Multicast distribution.  (Ima= gine hundreds of VMs reacting to dynamic global config being delivered from= a single definitive source.)  Such alternative transports can remove the burden from the single central system processing knowing an= d maintaining connections with each of the devices.

 

(2) There is nothing spec= ific to YANG syntax which makes it only applicable to EMS.   Or s= pecific to point-to-point connection oriented delivery.  The syntax is useful (and used) elsewhere.

 

(3) Once we establish tha= t Netconf is not optimal for all transport options, using a common (YANG) s= yntax across multiple transports is demonstrably valuable.  This allows transport optimizations to be abstracted away from logical inf= ormation model design.

 

(4) There are already mul= tiple types of controllers in the network.  Each use their own specifi= c protocol to exchange config and status.  Why ignore that there are already multi-device abstractions in the network?  Why ignore tha= t treating aggregates only by device boundary units can and will drive erro= rs into a system?    Configuring each device individually is= error prone for some abstractions. 

<= /div>

I don't see what (1) - (4) have t= o do with replicating subtrees from multiple devices into a controller.
New transports for NETCONF can be defined, if there is enough intere= st.
It's OK if other protocols use YANG.  NETCONF does n= ot have to solve every problem.

 

(5) Providing visibility = into a peer’s persistent and running config data can be very useful.<= /span>


There are protocol-s= pecific modules for that.
Topology is a good example of what I me= an by collection of devices vs. network-view.
An EMS could collec= t the neighbor tables from all the devices and replicate them for
its northbound clients.  Or it could resolve the device data into one= network-wide view,
dealing with duplicates, mobility, etc.
=

I do not agree that the "collection of device mode= ls" is a very interesting solution
for network management at= the network level.  We have dabbled with "network-wide"
configuration a couple times, only to drop the issue.  IMO the = models at this level
describe the network, not the devices. = There is some glue that tells the controller what devices are
av= ailable, and how to talk to them, but the goal is to handle the device leve= l details
as part of the controller data model implementation.&nb= sp;



 

(6) Many of these new ser= vices can reside within network elements just as easily as within controlle= rs.  Why would we create unnecessary technology barriers based on historic roles?

 

(7) There is huge investm= ent in multiple places on this type of technology (e.g., OpenDaylight Mount= , DDS).  Why fight against trends proving successful already? &nb= sp; The IETF should incorporate these capabilities where advantageous.<= u>

 

IMHO it is in the IETF in= terests to support fulfill these requirements.  If we don’t owne= rship will go elsewhere.  There are already implementations driven by the list of imperatives above.

 

Eric



Andy
 

<= /u>

 

From: netmod [= mailto:netmod-= bounces@ietf.org] On Behalf Of Kent Watsen
Sent: Tuesday, October 14, 2014 3:44 PM
To: Andy Bierman; Alexander Clemm (alex)
Cc: netmod@ietf= .org
Subject: Re: [netmod] New revision of YANG mount draft=

 

 =

This conversation is going = full-circle, so I'll go back to my original point - that I don't un= derstand the importance for IETF standardization and question the effectiveness of the solution.

 =

EMS systems managing device= s using NETCONF/YANG have been around for a few years.  It is pretty c= ommon for them to 1) provide a mechanism to get the YANG module used by a device and 2) a low-level API to get/set device-specific config = (as modeled by its YANG) - all with clear separation of which system "= owns" which data.    This draft proposes to fulfill the same= need, but in a way that is unique to a Controller/EMS that itself presents a YANG-defined NETCONF/RESTCONF model.   Under t= hose circumstances, I can almost understand the line of thinking that led t= o "mounting" idea (why not, right?), but is this really how a hig= her-level OSS/BSS would want it presented.  Why wouldn't the higher-level system use NETCONF to the device directly? &= nbsp;- what semantics does "mounting" bring above and beyond a di= rect connection to the device (approval-workflow or network-wide transactio= nal-updates?) 

 =

To Tom's point, it'= s not enough that some products implement an idea for there to be a need to= add it to a WG charter.  I'd rather see pressing interoperability considerations driving that.

 =

All that said, I do support= the idea of enhancing NETCONF notifications, if RFC6470's netconf-conf= ig-change event isn't sufficient.  If there is a deficiency there, then all NETCONF clients (not "mount clients") would bene= fit.

 =

Thanks,

Kent

 =

 =

From: Andy Bierman <andy@yumaworks.com>
Date: Tuesday, October 14, 2014 at 11:40 AM
To: "Alexander Clemm (alex)" <alex@cisco.com>
Cc: "netmo= d@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] New revision of YANG mount draft=

 =

 =

 =

On Mon, Oct 13, 2014 at 5:5= 2 PM, Alexander Clemm (alex) <alex@cisco.com> wrote:

Hi Juergen,
(several threads to respond to; Eric already provided responses to a lot of= the items, here just a few summary items from my perspective)

Re: what technical details we think should be standardized:

- The first aspect is the YANG extension that allows users to define mountp= oints (to logically incorporate subtrees from a remote datastore under a da= ta node).  This can be done as part of a YANG module, i.e. is data mod= el related.

- The second aspect is a YANG data model that allows to monitor and manage = a "mount topology".  This addresses the system management as= pects of this concept, generally not of concern to the applications that wa= nt to simply access the datastore, but required for a "complete" solution.  Again, this can be done as part= of a YANG module, i.e. is data model related.

- The third aspect concerns the ability to subscribe to updates to a YANG d= atatree, and "push" those updates.  This is more general tha= n mount itself and should presumably be separated into a separate draft.&nb= sp; Subscriptions can be represented as a configurable data model.  Likewise, push can occur through notifications, definabl= e as part of a data model related.  So, that one too is data model rel= ated.  (It is conceivable to also introduce different transports here,= which would be discussion for a transport forum; however, our intent was to address these within the existing framework.)
Re: overall architecture, you are bringing up an interesting point that pro= bably needs visiting.  RFC 6244, in section 3.1, clearly depicts the b= oundary of the server as one device. 

 =

 =

This is intentional and IMO= the proper architecture for a NETCONF datastore.

The datastore is intended t= o represent one device, whether that device is a giant=

network controller or a tin= y access point.

 =

I don't agree that repl= ication of subtrees from other servers is the proper architecture for

a network-wide datastore.&n= bsp; It doesn't matter for monitoring, but for editing the subtrees<= /u>

are all part of 1 configura= tion datastore, not isolated replicated subtrees.  

 =

 =

 =

It also suggests that the datastore does not reach beyond the device bo= undaries (datastore is actually not depicted, but config database and "system software components" - presumably for the config dat= a).  This is why we believe the mount capability is needed - to allow = the datastore to reach beyond those boundaries.  If this involves exte= nding the architecture, then so be it.  Worth mentioning along the same lines, since RFC 6244 assumes that YANG will be always used= in conjunction with Netconf: Really, we would like to consider Netconf jus= t one particular transport / set of services that can operate on / interact= with a datastore, geared towards configuration and fulfillment-related use cases.  That should not rul= e out the possibility to apply other transports and services - such as REST= conf (the possi
 bility for which is not considered in the RFC), and going forward pos= sibly other transports/ interfaces, that for example focus on pushing datas= tore information and operational data for applications which today might us= e SNMP.

Regarding making this transparent for all Netconf operations:  The imp= ortant aspect and primary focus of the use case lies in providing an abilit= y to retrieve remote information.  The motivation behind all this is n= ot to provid "ACID" style management transactions across the network - in fact, we believe that for many applications a &quo= t;BASE" style of management is preferrable and more appropriate, in wh= ich transactional guarantees, ability to rollback,etc, are not provided as = long as state becomes eventually consistent. This is also reflected in the companion requirements spec.  We do not= want to be bogged down in the aspects that would be required to make ACID = work.  While we believe that "simple" configuration (not inc= luding transactions spanning multiple items) is achievable, we are happy to "scale down" the mount concept accordingly and l= eave transactionality or even configuration as a whole out of scope.=

 =

I don't see what is sto= pping you from implementing your controller.

If you wrap the remote conf= ig in anyxml, then all the YANG validation

problems go away.  The= controller can send NETCONF requests to the remote devices

on behalf of the northbound= client.   This seems like just an implementation detail=

for the controller, not a s= tandards issue.

 =

The request to have the dev= ices push all their operational data to the controller=

is a different matter. = ; That has a huge operational impact, and something that

NETCONF is not designed for= .  I suggest using IPFIX for that.

 =

 =

 =


--- Alex

 =

Andy

 =

 =

-----Original Message-----<= br> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de= ]
Sent: Monday, October 13, 2014 12:23 PM
To: Eric Voit (evoit)
Cc: Alexander Clemm (alex); netmod@ietf.org
Subject: Re: [netmod] New revision of YANG mount draft

On Mon, Oct 13, 2014 at 04:26:55PM +0000, Eric Voit (evoit) wrote:
> > From: Juergen Schoenwaelder, October 10, 2014 5:54 PM
> >
> > I still fail to see how all this falls out of RFC 6020.
>
> If by falling out you mean 'in conflict with', then I would ag= ree that there are not backwards compatibility issues with RFC 6020 section= 6 syntax.  This was by design.
>
> However I believe Alex' and Jan's concerns are with Section 5.= 1 of RFC 6020.   This section includes statements such as:  = "For a module or submodule to reference definitions in an external mod= ule, the external module MUST be imported."
>
> Bringing in targeted nodes and subtrees need not require visibility in= to the full submodule where the authoritative copy of the object might resi= de.
>

There is anyxml in YANG 1.0 and there is a proposal for anydata in YANG 1.1= .

> > I see protocol discussion in draft-clemm-netmod-mount-02.txt (whi= ch
> > is needed for what you want to do and likely even incomplete) but=
> > then the NETMOD WG is not about protocol work but about the data<= br> > > modeling language YANG and data models. In fact, my reading of th= e
> > I-D is that you do not request to change anything in YANG at all = -
> > all you propose is to define a few extensions and a data model. >
> The 'on-demand' Mount does not need any protocol work.  I= t is the easiest, and is looking to standardize needed several syntax exten= sions.  This type of Mount is what is implemented in OpenDaylight toda= y.
>

I am not sure. Can I run all NETCONF protocol operations transparently acro= ss these mount points? I doubt it.

What you introduce is a "partitioning" of a datastore that does n= ot architecturally exist so far. Does this lead to a new type of datastore = or can I partition any datastore? How does this partitioning interact with = ephemeral datastores discussed in I2RS? I believe there are serious _architectural_ questions that need to be discus= sed and depending on how they are resolved, there may be more or less proto= col work needed.

What triggered this discussions were statements of the form "YANG does= not allow to do X" which I think is not correct since YANG really is = not the issue. The mount work is extending/modifying/$(your-verb-here)
the _architecture_ of NETCONF and YANG. It is not clear which WG is respons= ible for the underlying architecture. RFC 6244 was produced by NETMOD but t= hen it describes more the framework and not the underlying architectural mo= del (what Randy Presuhn I think calls the meta model). Perhaps we need to work on an architecture at some = point in time, pretty much like we needed to define an architecture for SNM= P at some point in time. The work on JSON encoding and the mount proposal c= learly indicates that certain architectural assumptions are implicit and that leads to discussions that are difficult = to close until we agree on an architecture.

Who said history does not repeat?

/js

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

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

 =


--001a11c1db70ddeb8b050569cc3b-- From nobody Tue Oct 14 17:02:03 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2CC61A008F for ; Tue, 14 Oct 2014 17:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4rH8SVRDRI2 for ; Tue, 14 Oct 2014 17:02:00 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39B3A1A0089 for ; Tue, 14 Oct 2014 17:02:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9489; q=dns/txt; s=iport; t=1413331320; x=1414540920; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=UQ2zKu2I7t1IQaKCnskxDvyFr7aFg3dB8fglELGC15k=; b=XzmPZ4R3q0usK6tw6nb6vm3nUe/OlkcVj4L1/qi0VQArEKLzTSaAMOpE mj0E0KVNXIhqe1XCA/MdY3NTrDXLvyJot52Zv4pjRGeanQ6WG8LsRxWfX FHuhUyrksI7dUHApOs+TCi7KcGtt89K8rAQCnebBjUxyfiC5D831sdyaY k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAJS4PVStJA2D/2dsb2JhbABYA4MOU1gEzC0KhnlUAoESFgF9hAIBAQEEAQEBaxcCAgIBCBABAwEBAQENGgcbDAsUCQgCBAESG4gjDccoAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwSPaUgXBguEOgWLIIZZi1KBLoZziXKDfoN3bIEGQoECAQEB X-IronPort-AV: E=Sophos;i="5.04,719,1406592000"; d="scan'208";a="87001174" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-2.cisco.com with ESMTP; 15 Oct 2014 00:01:59 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s9F01xLO012725 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Oct 2014 00:01:59 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.49]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Tue, 14 Oct 2014 19:01:58 -0500 From: "Jan Medved (jmedved)" To: Andy Bierman , Juergen Schoenwaelder , "Alexander Clemm (alex)" , Kent Watsen , "netmod@ietf.org" Thread-Topic: [netmod] New revision of YANG mount draft Thread-Index: AQHP40RfcXk3qRma8kec20irC7AonJwoMIcAgAH5vQCAAANUgIAACP+AgAAeuACAALPJAIAAdjsAgASvE4A= Date: Wed, 15 Oct 2014 00:01:57 +0000 Message-ID: References: <20141010210934.GB80385@elstar.local> <20141010215341.GD80385@elstar.local> <20141011102706.GA81740@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 x-originating-ip: [10.154.176.170] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <89A52A2C7DC19B45B74CD219EC4DA4C9@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Hd8OpKGrFihJetoGipn6iPDpIhc Subject: Re: [netmod] New revision of YANG mount draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 15 Oct 2014 00:02:02 -0000 From: Andy Bierman Date: Saturday, October 11, 2014 at 10:30 AM To: Juergen Schoenwaelder , "Alexander Clemm (alex)" , Jan Medved , Kent Watsen , "netmod@ietf.org" Subject: Re: [netmod] New revision of YANG mount draft > > >On Sat, Oct 11, 2014 at 3:27 AM, Juergen Schoenwaelder > wrote: > >Alex, > >we seem to talk past each other, I am not sure why. You wrote something >like this: > >> > > Today, Yang does not allow a controller application to work directly >> > > with device yang models. A controller has to re-define device models >> > > the redefined models to applications. > >So I am wondering what in RFC 6020 is leading to this statement. I did >not find anything so I need your help to understand this. I am also >getting confused when you say there is no protocol work needed, things >can be done within the existing framework, but then you say there is a >need for a push and/or pub/sub model for data subtrees (which is not >there today). > >It helps me if you focus on clearly explaining what the technical >details are you think should be standardized for your use case. There >is lots of text why your use case is important but what I am looking >for is a concise and clear description of the details that you think >need to be standardized. > >Note that we so far have a setup in the IETF where one WG does >protocol work and another takes care of the data modeling language and >some core data models. I try to understand which pieces of concrete >work you want to do so I can understand where things should be >discussed. > > > >Perhaps we are disagreeing on the problem to solve, so we won't agree on >the >specific solutions that need to be chartered and standardized either. > >I do not agree with the premise that the network-level data models need >to be >the same as the device -level data models. A collection of data from >several >devices is just passed through to the client of the controller. This does >not >seem like network-level management to me. Nobody is saying that the requirement is network-level management. There simply is a class of controller SDN apps that need to read/write data from devices. These apps can be a part of the controller (controller plugins ) or remote, in which case they use the controller REST APIs. > >The controller can use NETCONF as its southbound protocol to the devices. True. But the controller can also use NETCONF as the northbound protocol. Or RESTCONF, for that matter. >It should decide what data to collect and what northbound data models to >populate. Why should the controller be limited to a use case where it has different southbound and northbound models? The controller infrastructure should be a generic transparent plumbing that connects model providers with model consumers. Model consumers can be controller apps (we can call them extensions, plugins, ...) or external apps. Model providers are devices or controller apps or even external apps. Your use case where the controller has different northbound and southbound models could be (and in ODL would be) implemented by a set of plugins that are loaded into the controller. A plugin that understands a particular device model from a particular vendor (which is designed/compiled against that device model) can populate a northbound data model. Different vendors can provide plugins for their devices. A particular controller distribution is assembled from different vendors=B9 plugins at integration time; if desired, a controller user should be able to load a vendor=B9s new plugin into the controller at a later point when a new device is introduced into the network. The controller does not know a priori what models will be loaded into it during its lifetime (or in a particular controller config). Therefore, the controller needs a mechanism to extend the controller=B9s schemas (Martin's re-statement of the problem is IMO spot-on). =20 >I don't see why the devices need to be configured for this purpose. That would be a very limited (and limiting) view of SDN. I also disagree that the controller decides what data to collect and what northbound data models to populate. For both case, it=B9s the controller apps (and I count the controller plugins as apps) that decide what data they want want to collect from the network and what devices and how they want to program. > > > >/js > > > >Andy >=20 Thanks, Jan > > >On Fri, Oct 10, 2014 at 11:43:38PM +0000, Alexander Clemm (alex) wrote: >> Hi Juergen, >> >> I am not sure with what you mean with "this falls out of RFC 6020"? >> >> To your statement: "In fact, my reading of the I-D is that you do not >>request to change anything in YANG at all - all you propose is to define >>a few extensions and a data model." Yes, I agree; your understanding is >>correct. The proposal we are making addresses > the requirements within the existing framework. >> >> Regarding the "protocol portion", we are making the case that >>implementation of this will be facilitated by having a push and/or >>pub/sub model for data subtrees. This does not necessarily require >>actual protocol work (although such work could be defined) > but can be addressed again within the existing framework, using a >subscription configuration model, notifications etc as outlined in the >draft. >> >> --- Alex >> >> -----Original Message----- >> From: Juergen Schoenwaelder >>[mailto:j.schoenwaelder@jacobs-university.de] >> Sent: Friday, October 10, 2014 2:54 PM >> To: Alexander Clemm (alex) >> Cc: Jan Medved (jmedved); Kent Watsen; netmod@ietf.org >> Subject: Re: [netmod] New revision of YANG mount draft >> >> I still fail to see how all this falls out of RFC 6020. >> >> I see protocol discussion in draft-clemm-netmod-mount-02.txt (which is >>needed for what you want to do and likely even incomplete) but then the >>NETMOD WG is not about protocol work but about the data modeling >>language YANG and data models. In fact, my reading > of the I-D is that you do not request to change anything in YANG at all >- all you propose is to define a few extensions and a data model. >> >> Do you agree? Or where am I mis-understanding things? >> >> /js >> >> On Fri, Oct 10, 2014 at 09:21:29PM +0000, Alexander Clemm (alex) wrote: >> > What this refers to is the case of a hierarchy, where a system in a >>client role accesseses another system in a server role (e.g. a >>controller) which itself is a client to another server (e.g. a network >>device). One (straightforward) approach is to ignore > the fact that the server (e.g. the controller) can be a client, and >simply have it incorporate its own set of YANG models to represent the >other devices below it. The downside is that this requires the >controller to redefine and implement those models - they > cannot be simply reused as e.g. the "scope" is different, and the server >has to have a semantic "understanding" of everything in the devices >underneath it. This brings about the same situation that NMS has had for >decades, that integrating new devices into > an operational environment is held hostage by the NMS, which first needs >to support (and require corresponding development support for) all those >new parameters. In our case, we want to have the option to simply >incorpor > ate "subtrees" from the device and make them accessible to other >applications by mounting them, without requiring further development (or >requiring systems to "go around" the controller, which complicates >development of those other system and/or introduces > other issues such as synchronization). >> > --- Alex >> > >> > -----Original Message----- >> > From: Juergen Schoenwaelder >> > [mailto:j.schoenwaelder@jacobs-university.de] >> > Sent: Friday, October 10, 2014 2:10 PM >> > To: Jan Medved (jmedved) >> > Cc: Kent Watsen; Alexander Clemm (alex); netmod@ietf.org >> > Subject: Re: [netmod] New revision of YANG mount draft >> > >> > On Thu, Oct 09, 2014 at 09:59:31PM +0000, Jan Medved (jmedved) wrote: >> > > >> > > Today, Yang does not allow a controller application to work directly >> > > with device yang models. A controller has to re-define device models >> > > into controller-specific models inside the controller and present >> > > the redefined models to applications. >> > >> > How is this falling out of RFC 6020? >> > >> > /js >> > >> > -- >> > Juergen Schoenwaelder Jacobs University Bremen gGmbH >> > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> > Fax: +49 421 200 3103 >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 > >-- >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 Tue Oct 14 17:25:43 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F41541A00A3 for ; Tue, 14 Oct 2014 17:25:38 -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 4yF4jBLlYTtw for ; Tue, 14 Oct 2014 17:25:36 -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 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 272201A0086 for ; Tue, 14 Oct 2014 17:25:36 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB423.namprd05.prod.outlook.com (10.141.58.146) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Wed, 15 Oct 2014 00:25:13 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.226]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.226]) with mapi id 15.00.1049.012; Wed, 15 Oct 2014 00:25:13 +0000 From: Dean Bogdanovic To: "Acee Lindem (acee)" Thread-Topic: [netmod] Call for consensus to Accept ACL Model draft-bogdanovic-netmod-acl-model-02 as a WG draft Thread-Index: AQHP4wqZgoccLOXIYU6NUVXJCsIbYZwoiYSAgADJiwCAACBVgIAACzwAgABlWICABnLnAA== Date: Wed, 15 Oct 2014 00:25:12 +0000 Message-ID: <21FA6976-A2F1-4BC3-A019-44B9EE64FD79@juniper.net> References: <3E03501B-CA0B-433D-A18F-F77DD223EBE7@lucidvision.com> <2267A2CF-2103-47A9-99C8-E613017E252A@cisco.com> <2D34D6C8-4D51-44E0-8BF1-5EEC71059F6D@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB423; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 0365C0E14B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(51704005)(24454002)(164054003)(199003)(377454003)(479174003)(189002)(230783001)(15975445006)(66066001)(82746002)(92566001)(86362001)(15202345003)(89996001)(77096002)(93916002)(31966008)(33656002)(122556002)(106116001)(76482002)(107046002)(21056001)(87286001)(120916001)(92726001)(20776003)(14971765001)(83716003)(93886004)(87936001)(19580395003)(64706001)(88136002)(2656002)(19580405001)(50986999)(85852003)(97736003)(4396001)(36756003)(57306001)(106356001)(76176999)(85306004)(16236675004)(46102003)(110136001)(77156001)(62966002)(99396003)(80022003)(101416001)(104166001)(50226001)(19617315012)(105586002)(99286002)(40100003)(95666004)(104396001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB423; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_21FA6976A2F14BC3A01944B9EE64FD79junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/rtWwTpLtcS_Jgd-cm8aXyUYZPZo Cc: NETMOD Working Group Subject: Re: [netmod] Call for consensus to Accept ACL Model draft-bogdanovic-netmod-acl-model-02 as a WG draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 15 Oct 2014 00:25:39 -0000 --_000_21FA6976A2F14BC3A01944B9EE64FD79junipernet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Oct 10, 2014, at 5:56 PM, Acee Lindem (acee) > wrote: From: Andy Bierman > Date: Friday, October 10, 2014 at 11:53 AM To: Acee Lindem > Cc: Dean Bogdanovic >, NETMOD W= orking Group > Subject: Re: [netmod] Call for consensus to Accept ACL Model draft-bogdanov= ic-netmod-acl-model-02 as a WG draft On Fri, Oct 10, 2014 at 8:13 AM, Acee Lindem (acee) > wrote: Hi Dean, On 10/10/14, 9:17 AM, "Dean Bogdanovic" > wrote: > >On Oct 9, 2014, at 9:16 PM, Acee Lindem (acee) > wrote: > >> Authors, >> >> I have reviewed the document and have two rather fundamental comments >>that preclude me from supporting WG adoption. >> >> 1. I think you should change the rule-name (type string) to a >>sequence-number (type uint16 or int32). While using a string is >>ostensibly more flexible, network administrators have been using >>sequence numbers for over 30 years now and will be throughly >>disappointed when they discover that ACE =B310=B2 lexicographically prece= des >>ACE =B32=B2. This comment has broader significance than just access list= s >>since this model, if adopted and standardized, will set a precedent for >>future models. > >Well, this is something we posted on the mailing list to ask opinions. I=B9ll have to look in the archives. Was the rule-name string given support or simply no opposition? > Problem with the sequence number is that inserting new entries is a >problem if the space is exhausted between entries. The rule-name type >string is more flexible then a sequence number. Like I said, list based policies have used sequence numbers for over 30 years and this has not proved to be a serious problem. I don=B9t think we should change semantics with so little benefit when modeling existing constructs. For something completely new, these new ordering semantics could be explored. If I=B9m the only one who sees this as unwieldy, I=B9ll concede. I=B9ve auto-generated many configs with number based interface names or VRFs and been really annoyed at the sorted ordering. But this is YANG, not CLI. YANG has user-ordered lists so the keys do not have to be used to dictate an order (and should not be used). The keys can be used to describe the entry, so "9" and "10" are just labels. They sort correctly because the list is ordered-by user and the user knows that, and is expected to provide or insert entries in the desired ord= er. Okay =96 I missed this distinction but understand it now. Can we then add a= sequence-number to the model that an implementation knows how to order the= ACEs? Thanks, Acee You can easily make a proprietary extension based on the newco example. The= re is nothing preventing you to do that. Dean Andy > >> 2. Please remove section 5 from the draft. This draft should not mix >>packet filtering and route filtering. Though we may get to this >>hierarchy, I believe that prefix-lists have much greater affinity with >>other routing policies than access-lists. Note that there is a separate >>route-filtering model in >>https://datatracker.ietf.org/doc/draft-zhdankin-netmod-bgp-cfg/. >>Finally, the RTGWG is now chartered for YANG models that are not >>specific to other Routing area working groups. The discussion of route >>filters belongs there or in IDR (since BGP has the most rigorous routing >>policy requirements). > >This is just an example how to add standard extensions. We needed a basic >example how to extend standard features and as you can see it is a bare >minimum. Maybe enforcing language that this is solely an example would >help? I didn=B9t notice that it was an example. I think this needs to be more clear - maybe even moved to an appendix. However, I=B9m happy as long as it is not normative. Thanks, Acee > >Dean > >> >> Also, a comparably minor comment, leaf-list targets requires a better >>definition. It really isn=B9t very useful without some guidance as to how >>an implementation=B9s targets should be represented. >> >> Thanks, >> Acee >> >> >> >> On Oct 8, 2014, at 11:14 AM, Thomas D. Nadeau > >>wrote: >> >>> >>> The co-authors of draft-bogdanovic-netmod-acl-model-02 have asked t= he >>>NETMOD chairs to post a call to adopt the draft as a WG document. >>> >>> The draft can be found here: >>> >>> http://tools.ietf.org/html/draft-bogdanovic-netmod-acl-model-02 >>> >>> The model itself has been extracted and can be directly accessed he= re >>>using git: >>> >>> >>> https://github.com/YangModels/yang/blob/master/experimental/ietf/AC= L-MO >>>DEL/ >>> >>> Please comment by the close of business on Monday, October 13, 2014= . >>> >>> >>> --Tom (As NETMOD 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 > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --_000_21FA6976A2F14BC3A01944B9EE64FD79junipernet_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On Oct 10, 2014, at 5:56 PM, Acee Lindem (acee) <acee@cisco.com> wrote:



From: Andy Bierman <andy@yumaworks.com>
Date: Friday, October 10, 2014 at 1= 1:53 AM
To: Acee Lindem <acee@cisco.com>
Cc: Dean Bogdanovic <deanb@juniper.net>, NETMOD Working Group &= lt;netmod@ietf.org>
Subject: Re: [netmod] Call for cons= ensus to Accept ACL Model draft-bogdanovic-netmod-acl-model-02 as a WG draf= t



On Fri, Oct 10, 2014 at 8:13 AM, Acee Lindem (ac= ee) <acee@cisco.com&= gt; wrote:
Hi Dean,

On 10/10/14, 9:17 AM, "Dean Bogdanovic" <deanb@juniper.net> wrote:

>
>On Oct 9, 2014, at 9:16 PM, Acee Lindem (acee) <acee@cisco.com> wrote:
>
>> Authors,
>>
>> I have reviewed the document and have two rather fundamental comme= nts
>>that preclude me from supporting WG adoption.
>>
>>    1. I think you should change the rule-name (type stri= ng) to a
>>sequence-number (type uint16 or int32). While using a string is
>>ostensibly more flexible, network administrators have been using >>sequence numbers for over 30 years now and will be throughly
>>disappointed when they discover that ACE =B310=B2 lexicographically= precedes
>>ACE =B32=B2.  This comment has broader significance than just = access lists
>>since this model, if adopted and standardized, will set a precedent= for
>>future models.
>
>Well, this is something we posted on the mailing list to ask opinions.<= br>
I=B9ll have to look in the archives. Was the rule-name string given support=
or simply no opposition?

> Problem with the sequence number is that inserting new entries is a >problem if the space is exhausted between entries. The rule-name type >string is more flexible then a sequence number.

Like I said, list based policies have used sequence numbers for over 30
years and this has not proved to be a serious problem. I don=B9t think we should change semantics with so little benefit when modeling existing
constructs. For something completely new, these new ordering semantics
could be explored. If I=B9m the only one who sees this as unwieldy, I=B9ll<= br> concede. I=B9ve auto-generated many configs with number based interface
names or VRFs and been really annoyed at the sorted ordering.



But this is YANG, not CLI.
YANG has user-ordered lists so the keys do not have to be used
to dictate an order (and should not be used).  The keys can be
used to describe the entry, so "9" and "10" are ju= st labels.
They sort correctly because the list is ordered-by user and the user
knows that, and is expected to provide or insert entries in the desire= d order.

Okay =96 I missed this distinction but understand it now. Can we then = add a sequence-number to the model that an implementation knows how to orde= r the ACEs? 
Thanks,
Acee

You can easily make a proprietary extension based on the newco example. The= re is nothing preventing you to do that. 

Dean






Andy


 

>
>>    2. Please remove section 5 from the draft. This draft= should not mix
>>packet filtering and route filtering. Though we may get to this
>>hierarchy, I believe that prefix-lists have much greater affinity w= ith
>>other routing policies  than access-lists. Note that there is = a separate
>>route-filtering model in
>>https://datatracker.ietf.org/doc/draft-zhdankin-= netmod-bgp-cfg/.
>>Finally, the RTGWG is now chartered for YANG models that are not >>specific to other Routing area working groups. The discussion of ro= ute
>>filters belongs there or in IDR (since BGP has the most rigorous ro= uting
>>policy requirements).
>
>This is just an example how to add standard extensions. We needed a bas= ic
>example how to extend standard features and as you can see it is a bare=
>minimum.  Maybe enforcing language that this is solely an example = would
>help?

I didn=B9t notice that it was an example. I think this needs to be more
clear - maybe even moved to an appendix. However, I=B9m happy as long as it=
is not normative.

Thanks,
Acee


>
>Dean
>
>>
>> Also, a comparably minor comment, leaf-list targets requires a bet= ter
>>definition. It really isn=B9t very useful without some guidance as = to how
>>an implementation=B9s targets should be represented.
>>
>> Thanks,
>> Acee
>>
>>
>>
>> On Oct 8, 2014, at 11:14 AM, Thomas D. Nadeau <tnadeau@lucidvision.com>
>>wrote:
>>
>>>
>>>     The co-authors of draft-bogdanovic-netmod-a= cl-model-02 have asked the
>>>NETMOD chairs to post a call to adopt the draft as a WG documen= t.
>>>
>>>     The draft can be found here:
>>>
>>>     http://tools.ietf.org/ht= ml/draft-bogdanovic-netmod-acl-model-02
>>>
>>>     The model itself has been extracted and can= be directly accessed here
>>>using git:
>>>
>>>
>>>     https://github.c= om/YangModels/yang/blob/master/experimental/ietf/ACL-MO
>>>DEL/
>>>
>>>     Please comment by the close of business on = Monday, October 13, 2014.
>>>
>>>
>>>     --Tom (As NETMOD 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
>

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


--_000_21FA6976A2F14BC3A01944B9EE64FD79junipernet_-- From nobody Tue Oct 14 17:50:45 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C25C1A00CD for ; Tue, 14 Oct 2014 17:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.286 X-Spam-Level: X-Spam-Status: No, score=-15.286 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8V9PnGNvOaCK for ; Tue, 14 Oct 2014 17:50:32 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69B581A00A9 for ; Tue, 14 Oct 2014 17:50:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=62200; q=dns/txt; s=iport; t=1413334232; x=1414543832; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=1w0zOD0xGTqHonzOfzRTkY2XKuGgAq6XG4WP5+vfXX0=; b=WS0kSOPDHJwDUAto1KQKzFrI06nKQ27wIfBkB856SsTeyTeCb3N3aLqa JlzkZxUvt2FnUODwQuSP9dv191QHC1eldNmDv+r+/2oQQm1YWD7u0owll lz01yrAacDErno4kfwB/lI8crwRIUv4txXXJ78rYER9gWNIZsvMyyNaEY A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAEzEPVStJV2S/2dsb2JhbABYA4JIRlNczEYBCYZ5VAKBEhYBfYQCAQEBAwEBAQEXARJBCwwCAgIBCBABAQIBAQEBCgIUAQYHGwwLFAMGCAIEAQ0FCBOIGwgNxzIBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBI98HQYHEwEMBAYBAgQDCIMcgR4FkX2NBYZziXeDfoN3bIEIJByBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,720,1406592000"; d="scan'208,217";a="363325498" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-6.cisco.com with ESMTP; 15 Oct 2014 00:50:23 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s9F0oMpR032112 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Oct 2014 00:50:22 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.41]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Tue, 14 Oct 2014 19:50:22 -0500 From: "Eric Voit (evoit)" To: Andy Bierman , Kent Watsen Thread-Topic: [netmod] New revision of YANG mount draft Thread-Index: AQHP5NSnXWBBH+aajkuz6A/yEBcVLJwuAk1QgAC+AACAAFwLAIAA+CqAgABD8YD//8hjEIAAav0A//+27JA= Date: Wed, 15 Oct 2014 00:50:21 +0000 Message-ID: References: <20141010210934.GB80385@elstar.local> <20141010215341.GD80385@elstar.local> <20141013192248.GA68615@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.134.135] Content-Type: multipart/alternative; boundary="_000_EF64FF31F4C4384DBCE5D513A791C2B120A46249xmbalnx11ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/7DahqE6g5Hz-3UThVDv3rYYU59k Cc: "netmod@ietf.org" Subject: Re: [netmod] New revision of YANG mount draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 15 Oct 2014 00:50:43 -0000 --_000_EF64FF31F4C4384DBCE5D513A791C2B120A46249xmbalnx11ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Andy Bierman, October 14, 2014 6:47 PM On Tue, Oct 14, 2014 at 3:19 PM, Eric Voit (evoit) > wrote: Hi Kent, There are multiple reasons why current NETCONF based solutions don't hit al= l the requirements discussed during the thread. Below is a short incomplet= e list... (1) New Service types require systems built upon Eventually Consistency. If= we want to distribute read-only data fast, we might choose transports othe= r than NETCONF. We might choose protocols which aren't connection oriented= . We might even choose to use Multicast distribution. (Imagine hundreds o= f VMs reacting to dynamic global config being delivered from a single defin= itive source.) Such alternative transports can remove the burden from the = single central system processing knowing and maintaining connections with e= ach of the devices. (2) There is nothing specific to YANG syntax which makes it only applicable= to EMS. Or specific to point-to-point connection oriented delivery. The= syntax is useful (and used) elsewhere. (3) Once we establish that Netconf is not optimal for all transport options= , using a common (YANG) syntax across multiple transports is demonstrably v= aluable. This allows transport optimizations to be abstracted away from lo= gical information model design. (4) There are already multiple types of controllers in the network. Each u= se their own specific protocol to exchange config and status. Why ignore t= hat there are already multi-device abstractions in the network? Why ignore= that treating aggregates only by device boundary units can and will drive = errors into a system? Configuring each device individually is error pron= e for some abstractions. I don't see what (1) - (4) have to do with replicating subtrees from multip= le devices into a controller. This is a many-to-many configuration problem (not just a many device= s to one controller problem). Example 1: what if a central application wants to a push and maintain a gl= obal policy concurrently across devices. If hundred/thousands of VMs have = mounted that central policy, all devices get fast updates as well as knowin= g which copy is authoritative. Yes, this could be done with custom cod= e. Yes we could take managed objects and have application logic determine = where to push them. But why would you want to require this where it is unn= ecessary? Example 2: Why not let the remote device datastores decide what central inf= ormation they need to track? With VMs and new edge compute power we should= expect that remote devices will host a dynamic set of applications. These= applications could dynamically adjust their local object needs in ways a c= entral controller could never hope to support. Example 3: What if the remote device needs an object very rarely? Remote m= ounting provides a way to get the info only when necessary. And when you d= o on-demand mount, you know the info is current. New transports for NETCONF can be defined, if there is enough interest. It's OK if other protocols use YANG. NETCONF does not have to solve every = problem. Excellent (5) Providing visibility into a peer's persistent and running config data c= an be very useful. There are protocol-specific modules for that. Some protocol-specific modules exist, many do not. For example th= ere is no way for peer devices to know the Ethernet OAM timer of a neighbor= , or its Ethernet frame size. If would be great for a device to be able to= access (Mount) such peer config information. Local applets could then tak= e multi-box troubleshooting steps off of a human. Topology is a good example of what I mean by collection of devices vs. netw= ork-view. An EMS could collect the neighbor tables from all the devices and replicate= them for its northbound clients. Or it could resolve the device data into one netwo= rk-wide view, dealing with duplicates, mobility, etc. One EMS will not solve all needs. Topology is a function of protoc= ol. A spanning tree topology, an OSPF topology, a BGP topology all could = touch the same device. But they are unlikely to care about an identical se= t of devices. Nevertheless, they all might care to subscribe/mount the sta= te of particular line card (e.g., in case of failure). Since controllers= do traffic engineering, such speed is often critical. It is often network convergence timers which unify connectivity across topo= logies today. I do not agree that the "collection of device models" is a very interesting= solution for network management at the network level. We have dabbled with "network= -wide" configuration a couple times, only to drop the issue. IMO the models at th= is level describe the network, not the devices. There is some glue that tells the c= ontroller what devices are available, and how to talk to them, but the goal is to handle the device le= vel details as part of the controller data model implementation. We have a YANG model for Cloud Policer and DDoS Thresholding which e= xposes the interplay of domain and device view. I will strive to get it p= osted as a new draft before Oct 27th. (IETF 91 cut-off date.) Eric (6) Many of these new services can reside within network elements just as e= asily as within controllers. Why would we create unnecessary technology ba= rriers based on historic roles? (7) There is huge investment in multiple places on this type of technology = (e.g., OpenDaylight Mount, DDS). Why fight against trends proving successf= ul already? The IETF should incorporate these capabilities where advantag= eous. IMHO it is in the IETF interests to support fulfill these requirements. If= we don't ownership will go elsewhere. There are already implementations d= riven by the list of imperatives above. Eric Andy From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Kent Watsen Sent: Tuesday, October 14, 2014 3:44 PM To: Andy Bierman; Alexander Clemm (alex) Cc: netmod@ietf.org Subject: Re: [netmod] New revision of YANG mount draft This conversation is going full-circle, so I'll go back to my original poin= t - that I don't understand the importance for IETF standardization and que= stion the effectiveness of the solution. EMS systems managing devices using NETCONF/YANG have been around for a few = years. It is pretty common for them to 1) provide a mechanism to get the Y= ANG module used by a device and 2) a low-level API to get/set device-specif= ic config (as modeled by its YANG) - all with clear separation of which sys= tem "owns" which data. This draft proposes to fulfill the same need, but= in a way that is unique to a Controller/EMS that itself presents a YANG-de= fined NETCONF/RESTCONF model. Under those circumstances, I can almost und= erstand the line of thinking that led to "mounting" idea (why not, right?),= but is this really how a higher-level OSS/BSS would want it presented. Wh= y wouldn't the higher-level system use NETCONF to the device directly? - w= hat semantics does "mounting" bring above and beyond a direct connection to= the device (approval-workflow or network-wide transactional-updates?) To Tom's point, it's not enough that some products implement an idea for th= ere to be a need to add it to a WG charter. I'd rather see pressing intero= perability considerations driving that. All that said, I do support the idea of enhancing NETCONF notifications, if= RFC6470's netconf-config-change event isn't sufficient. If there is a def= iciency there, then all NETCONF clients (not "mount clients") would benefit= . Thanks, Kent From: Andy Bierman > Date: Tuesday, October 14, 2014 at 11:40 AM To: "Alexander Clemm (alex)" > Cc: "netmod@ietf.org" > Subject: Re: [netmod] New revision of YANG mount draft On Mon, Oct 13, 2014 at 5:52 PM, Alexander Clemm (alex) > wrote: Hi Juergen, (several threads to respond to; Eric already provided responses to a lot of= the items, here just a few summary items from my perspective) Re: what technical details we think should be standardized: - The first aspect is the YANG extension that allows users to define mountp= oints (to logically incorporate subtrees from a remote datastore under a da= ta node). This can be done as part of a YANG module, i.e. is data model re= lated. - The second aspect is a YANG data model that allows to monitor and manage = a "mount topology". This addresses the system management aspects of this c= oncept, generally not of concern to the applications that want to simply ac= cess the datastore, but required for a "complete" solution. Again, this ca= n be done as part of a YANG module, i.e. is data model related. - The third aspect concerns the ability to subscribe to updates to a YANG d= atatree, and "push" those updates. This is more general than mount itself = and should presumably be separated into a separate draft. Subscriptions ca= n be represented as a configurable data model. Likewise, push can occur th= rough notifications, definable as part of a data model related. So, that o= ne too is data model related. (It is conceivable to also introduce differe= nt transports here, which would be discussion for a transport forum; howeve= r, our intent was to address these within the existing framework.) Re: overall architecture, you are bringing up an interesting point that pro= bably needs visiting. RFC 6244, in section 3.1, clearly depicts the bounda= ry of the server as one device. This is intentional and IMO the proper architecture for a NETCONF datastore= . The datastore is intended to represent one device, whether that device is a= giant network controller or a tiny access point. I don't agree that replication of subtrees from other servers is the proper= architecture for a network-wide datastore. It doesn't matter for monitoring, but for editin= g the subtrees are all part of 1 configuration datastore, not isolated replicated subtrees= . It also suggests that the datastore does not reach beyond the device bounda= ries (datastore is actually not depicted, but config database and "system s= oftware components" - presumably for the config data). This is why we beli= eve the mount capability is needed - to allow the datastore to reach beyond= those boundaries. If this involves extending the architecture, then so be= it. Worth mentioning along the same lines, since RFC 6244 assumes that YA= NG will be always used in conjunction with Netconf: Really, we would like t= o consider Netconf just one particular transport / set of services that can= operate on / interact with a datastore, geared towards configuration and f= ulfillment-related use cases. That should not rule out the possibility to = apply other transports and services - such as RESTconf (the possi bility for which is not considered in the RFC), and going forward possibly= other transports/ interfaces, that for example focus on pushing datastore = information and operational data for applications which today might use SNM= P. Regarding making this transparent for all Netconf operations: The importan= t aspect and primary focus of the use case lies in providing an ability to = retrieve remote information. The motivation behind all this is not to prov= id "ACID" style management transactions across the network - in fact, we be= lieve that for many applications a "BASE" style of management is preferrabl= e and more appropriate, in which transactional guarantees, ability to rollb= ack,etc, are not provided as long as state becomes eventually consistent. T= his is also reflected in the companion requirements spec. We do not want t= o be bogged down in the aspects that would be required to make ACID work. = While we believe that "simple" configuration (not including transactions sp= anning multiple items) is achievable, we are happy to "scale down" the moun= t concept accordingly and leave transactionality or even configuration as a= whole out of scope. I don't see what is stopping you from implementing your controller. If you wrap the remote config in anyxml, then all the YANG validation problems go away. The controller can send NETCONF requests to the remote d= evices on behalf of the northbound client. This seems like just an implementatio= n detail for the controller, not a standards issue. The request to have the devices push all their operational data to the cont= roller is a different matter. That has a huge operational impact, and something t= hat NETCONF is not designed for. I suggest using IPFIX for that. --- Alex Andy -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: Monday, October 13, 2014 12:23 PM To: Eric Voit (evoit) Cc: Alexander Clemm (alex); netmod@ietf.org Subject: Re: [netmod] New revision of YANG mount draft On Mon, Oct 13, 2014 at 04:26:55PM +0000, Eric Voit (evoit) wrote: > > From: Juergen Schoenwaelder, October 10, 2014 5:54 PM > > > > I still fail to see how all this falls out of RFC 6020. > > If by falling out you mean 'in conflict with', then I would agree that th= ere are not backwards compatibility issues with RFC 6020 section 6 syntax. = This was by design. > > However I believe Alex' and Jan's concerns are with Section 5.1 of RFC 60= 20. This section includes statements such as: "For a module or submodule= to reference definitions in an external module, the external module MUST b= e imported." > > Bringing in targeted nodes and subtrees need not require visibility into = the full submodule where the authoritative copy of the object might reside. > There is anyxml in YANG 1.0 and there is a proposal for anydata in YANG 1.1= . > > I see protocol discussion in draft-clemm-netmod-mount-02.txt (which > > is needed for what you want to do and likely even incomplete) but > > then the NETMOD WG is not about protocol work but about the data > > modeling language YANG and data models. In fact, my reading of the > > I-D is that you do not request to change anything in YANG at all - > > all you propose is to define a few extensions and a data model. > > The 'on-demand' Mount does not need any protocol work. It is the easiest= , and is looking to standardize needed several syntax extensions. This typ= e of Mount is what is implemented in OpenDaylight today. > I am not sure. Can I run all NETCONF protocol operations transparently acro= ss these mount points? I doubt it. What you introduce is a "partitioning" of a datastore that does not archite= cturally exist so far. Does this lead to a new type of datastore or can I p= artition any datastore? How does this partitioning interact with ephemeral = datastores discussed in I2RS? I believe there are serious _architectural_ q= uestions that need to be discussed and depending on how they are resolved, = there may be more or less protocol work needed. What triggered this discussions were statements of the form "YANG does not = allow to do X" which I think is not correct since YANG really is not the is= sue. The mount work is extending/modifying/$(your-verb-here) the _architecture_ of NETCONF and YANG. It is not clear which WG is respons= ible for the underlying architecture. RFC 6244 was produced by NETMOD but t= hen it describes more the framework and not the underlying architectural mo= del (what Randy Presuhn I think calls the meta model). Perhaps we need to w= ork on an architecture at some point in time, pretty much like we needed to= define an architecture for SNMP at some point in time. The work on JSON en= coding and the mount proposal clearly indicates that certain architectural = assumptions are implicit and that leads to discussions that are difficult t= o close until we agree on an architecture. Who said history does not repeat? /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 --_000_EF64FF31F4C4384DBCE5D513A791C2B120A46249xmbalnx11ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From: Andy Bie= rman, October 14, 2014 6:47 PM

On Tue, Oct 14, 2014 at 3:19 PM, Eric Voit (evoit) &= lt;evoit@cisco.com= > wrote:

Hi Kent,

 

There are multiple reasons why current = NETCONF based solutions don’t hit all the requirements discussed during the thread.  Below is a short incomplete list…

 

(1) New Service types require systems b= uilt upon Eventually Consistency. If we want to distribute read-only data fast, we might choose transports other than NETCONF.  = We might choose protocols which aren’t connection oriented.  We = might even choose to use Multicast distribution.  (Imagine hundreds of= VMs reacting to dynamic global config being delivered from a single definitive source.)  Such alternative transports can re= move the burden from the single central system processing knowing and maint= aining connections with each of the devices.

 

(2) There is nothing specific to YANG s= yntax which makes it only applicable to EMS.   Or specific to point-to-point connection oriented delivery.  The syntax is useful= (and used) elsewhere.

 

(3) Once we establish that Netconf is n= ot optimal for all transport options, using a common (YANG) syntax across multiple transports is demonstrably valuable.  This all= ows transport optimizations to be abstracted away from logical information = model design.

 

(4) There are already multiple types of= controllers in the network.  Each use their own specific protocol to exchange config and status.  Why ignore that there are al= ready multi-device abstractions in the network?  Why ignore that treat= ing aggregates only by device boundary units can and will drive errors into= a system?    Configuring each device individually is error prone for some abstractions. 

 

I don't see what (1) - (4) have to do with replicati= ng subtrees from multiple devices into a controller.

 <= /p>

<Eric> This is a ma= ny-to-many configuration problem (not just a many devices to one controller= problem). 

 <= /p>

Example 1: what if a cent= ral application wants to a  push and maintain a global policy concurre= ntly across devices.  If hundred/thousands of VMs have mounted that central policy, all devices get fast updates as well as knowing which= copy is authoritative.      Yes, this could be do= ne with custom code.  Yes we could take managed objects and have appli= cation logic determine where to push them.  But why would you want to require this where it is unnecessary?

 <= /p>

Example 2: Why not let th= e remote device datastores decide what central information they need to tra= ck?  With VMs and new edge compute power we should expect that remote devices will host a dynamic set of applications.  These a= pplications could dynamically adjust their local object needs in ways a cen= tral controller could never hope to support.

 <= /p>

Example 3: What if the re= mote device needs an object very rarely?  Remote mounting provides a w= ay to get the info only when necessary.  And when you do on-demand mount, you know the info is current.

 <= /p>

New transports for NETCONF can be defined, if there = is enough interest.

It's OK if other protocols use YANG.  NETCONF d= oes not have to solve every problem.

 

<Eric> Excellent

 

(5) Providing visibility into a peer= 217;s persistent and running config data can be very useful.

 

There are protocol-specific modules for that.

 <= /p>

<Eric> Some protoco= l-specific modules exist,  many do not.   For example there = is no way for peer devices to know the Ethernet OAM timer of a neighbor, or= its Ethernet frame size.  If would be great for a device to be able to ac= cess (Mount) such peer config information.  Local applets could then t= ake multi-box troubleshooting steps off of a human.

 <= /p>

Topology is a good example of what I mean by collect= ion of devices vs. network-view.

An EMS could collect the neighbor tables from all th= e devices and replicate them for

its northbound clients.  Or it could resolve th= e device data into one network-wide view,

dealing with duplicates, mobility, etc.

 <= /p>

<Eric> One EMS will= not solve all needs.   Topology is a function of protocol. =  A spanning tree topology, an OSPF topology, a BGP topology all could= touch the same device.  But they are unlikely to care about an identical se= t of devices.  Nevertheless, they all might care to subscribe/mount th= e state of particular line card (e.g., in case of failure).   &nb= sp;Since controllers do traffic engineering, such speed is often critical.

 <= /p>

It is often network conve= rgence timers which unify connectivity across topologies today.

 

I do not agree that the "collection of device m= odels" is a very interesting solution

for network management at the network level.  W= e have dabbled with "network-wide"

configuration a couple times, only to drop the issue= .  IMO the models at this level

describe the network, not the devices.  There i= s some glue that tells the controller what devices are

available, and how to talk to them, but the goal is = to handle the device level details

as part of the controller data model implementation.=  

 

<Eric> We have a YA= NG model for Cloud Policer and DDoS Thresholding which exposes the interpla= y of domain and device view.   I will strive to get it posted as a new draft before Oct 27th.  (IETF 91 cut-off date.)

 <= /p>

Eric

 

 

(6) Many of these new services can resi= de within network elements just as easily as within controllers.  Why would we create unnecessary technology barriers based on historic role= s?

 

(7) There is huge investment in multipl= e places on this type of technology (e.g., OpenDaylight Mount, DDS).  Why fight against trends proving successful already? &nbs= p; The IETF should incorporate these capabilities where advantageous.

 

IMHO it is in the IETF interests to sup= port fulfill these requirements.  If we don’t ownership will go elsewhere.  There are already implementations driven by the list o= f imperatives above.

 

Eric

 

 

Andy

 

 

From: netmod [mailto:netmod-bounces@ietf.o= rg] On Behalf Of Kent Watsen
Sent: Tuesday, October 14, 2014 3:44 PM
To: Andy Bierman; Alexander Clemm (alex)
Cc: netmod@ietf= .org
Subject: Re: [netmod] New revision of YANG mount draft

 

 

This conversation is going full-circle, s= o I'll go back to my original point - that I don't understand the importance for IETF standardization and question the effectiveness of = the solution.

 

EMS systems managing devices using NETCON= F/YANG have been around for a few years.  It is pretty common for them to 1) provide a mechanism to get the YANG module used by a device= and 2) a low-level API to get/set device-specific config (as modeled by it= s YANG) - all with clear separation of which system "owns" which = data.    This draft proposes to fulfill the same need, but in a way that is unique to a Controller/EMS that itself pre= sents a YANG-defined NETCONF/RESTCONF model.   Under those circumstanc= es, I can almost understand the line of thinking that led to "mounting= " idea (why not, right?), but is this really how a higher-level OSS/BSS would want it presented.  Why wouldn't the= higher-level system use NETCONF to the device directly?  - what seman= tics does "mounting" bring above and beyond a direct connection t= o the device (approval-workflow or network-wide transactional-updates?)&nbs= p;

 

To Tom's point, it's not enough that some= products implement an idea for there to be a need to add it to a WG charter.  I'd rather see pressing interoperability conside= rations driving that.

 

All that said, I do support the idea of e= nhancing NETCONF notifications, if RFC6470's netconf-config-change event isn't sufficient.  If there is a deficiency there, then all NET= CONF clients (not "mount clients") would benefit.

 

Thanks,

Kent

 

 

From: Andy Bierman <andy@yumaworks.com>
Date: Tuesday, October 14, 2014 at 11:40 AM
To: "Alexander Clemm (alex)" <alex@cisco.com>
Cc: "netmo= d@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] New revision of YANG mount draft

 

 

 

On Mon, Oct 13, 2014 at 5:52 PM, Alexande= r Clemm (alex) <alex= @cisco.com> wrote:

Hi Juergen,
(several threads to respond to; Eric already provided responses to a lot of= the items, here just a few summary items from my perspective)

Re: what technical details we think should be standardized:

- The first aspect is the YANG extension that allows users to define mountp= oints (to logically incorporate subtrees from a remote datastore under a da= ta node).  This can be done as part of a YANG module, i.e. is data mod= el related.

- The second aspect is a YANG data model that allows to monitor and manage = a "mount topology".  This addresses the system management as= pects of this concept, generally not of concern to the applications that wa= nt to simply access the datastore, but required for a "complete" solution.  Again, this can be done as part= of a YANG module, i.e. is data model related.

- The third aspect concerns the ability to subscribe to updates to a YANG d= atatree, and "push" those updates.  This is more general tha= n mount itself and should presumably be separated into a separate draft.&nb= sp; Subscriptions can be represented as a configurable data model.  Likewise, push can occur through notifications, definabl= e as part of a data model related.  So, that one too is data model rel= ated.  (It is conceivable to also introduce different transports here,= which would be discussion for a transport forum; however, our intent was to address these within the existing framework.)
Re: overall architecture, you are bringing up an interesting point that pro= bably needs visiting.  RFC 6244, in section 3.1, clearly depicts the b= oundary of the server as one device. 

 

 

This is intentional and IMO the proper ar= chitecture for a NETCONF datastore.

The datastore is intended to represent on= e device, whether that device is a giant

network controller or a tiny access point= .

 

I don't agree that replication of subtree= s from other servers is the proper architecture for

a network-wide datastore.  It doesn'= t matter for monitoring, but for editing the subtrees

are all part of 1 configuration datastore= , not isolated replicated subtrees.  

 

 

 

It also suggests that the datastore does not re= ach beyond the device boundaries (datastore is actually not depicted, but config database and "system software components" -= presumably for the config data).  This is why we believe the mount ca= pability is needed - to allow the datastore to reach beyond those boundarie= s.  If this involves extending the architecture, then so be it.  Worth mentioning along the same lines, since RFC 6244= assumes that YANG will be always used in conjunction with Netconf: Really,= we would like to consider Netconf just one particular transport / set of s= ervices that can operate on / interact with a datastore, geared towards configuration and fulfillment-related use= cases.  That should not rule out the possibility to apply other trans= ports and services - such as RESTconf (the possi
 bility for which is not considered in the RFC), and going forward pos= sibly other transports/ interfaces, that for example focus on pushing datas= tore information and operational data for applications which today might us= e SNMP.

Regarding making this transparent for all Netconf operations:  The imp= ortant aspect and primary focus of the use case lies in providing an abilit= y to retrieve remote information.  The motivation behind all this is n= ot to provid "ACID" style management transactions across the network - in fact, we believe that for many applications a &quo= t;BASE" style of management is preferrable and more appropriate, in wh= ich transactional guarantees, ability to rollback,etc, are not provided as = long as state becomes eventually consistent. This is also reflected in the companion requirements spec.  We do not= want to be bogged down in the aspects that would be required to make ACID = work.  While we believe that "simple" configuration (not inc= luding transactions spanning multiple items) is achievable, we are happy to "scale down" the mount concept accordingly and l= eave transactionality or even configuration as a whole out of scope.=

 

I don't see what is stopping you from imp= lementing your controller.

If you wrap the remote config in anyxml, = then all the YANG validation

problems go away.  The controller ca= n send NETCONF requests to the remote devices

on behalf of the northbound client.  = ; This seems like just an implementation detail

for the controller, not a standards issue= .

 

The request to have the devices push all = their operational data to the controller

is a different matter.  That has a h= uge operational impact, and something that

NETCONF is not designed for.  I sugg= est using IPFIX for that.

 

 

 


--- Alex

 

Andy

 

 

-----Original Message-----
From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de= ]
Sent: Monday, October 13, 2014 12:23 PM
To: Eric Voit (evoit)
Cc: Alexander Clemm (alex); netmod@ietf.org
Subject: Re: [netmod] New revision of YANG mount draft

On Mon, Oct 13, 2014 at 04:26:55PM +0000, Eric Voit (evoit) wrote:
> > From: Juergen Schoenwaelder, October 10, 2014 5:54 PM
> >
> > I still fail to see how all this falls out of RFC 6020.
>
> If by falling out you mean 'in conflict with', then I would agree that= there are not backwards compatibility issues with RFC 6020 section 6 synta= x.  This was by design.
>
> However I believe Alex' and Jan's concerns are with Section 5.1 of RFC= 6020.   This section includes statements such as:  "Fo= r a module or submodule to reference definitions in an external module, the= external module MUST be imported."
>
> Bringing in targeted nodes and subtrees need not require visibility in= to the full submodule where the authoritative copy of the object might resi= de.
>

There is anyxml in YANG 1.0 and there is a proposal for anydata in YANG 1.1= .

> > I see protocol discussion in draft-clemm-netmod-mount-02.txt (whi= ch
> > is needed for what you want to do and likely even incomplete) but=
> > then the NETMOD WG is not about protocol work but about the data<= br> > > modeling language YANG and data models. In fact, my reading of th= e
> > I-D is that you do not request to change anything in YANG at all = -
> > all you propose is to define a few extensions and a data model. >
> The 'on-demand' Mount does not need any protocol work.  It is the= easiest, and is looking to standardize needed several syntax extensions.&n= bsp; This type of Mount is what is implemented in OpenDaylight today.
>

I am not sure. Can I run all NETCONF protocol operations transparently acro= ss these mount points? I doubt it.

What you introduce is a "partitioning" of a datastore that does n= ot architecturally exist so far. Does this lead to a new type of datastore = or can I partition any datastore? How does this partitioning interact with = ephemeral datastores discussed in I2RS? I believe there are serious _architectural_ questions that need to be discus= sed and depending on how they are resolved, there may be more or less proto= col work needed.

What triggered this discussions were statements of the form "YANG does= not allow to do X" which I think is not correct since YANG really is = not the issue. The mount work is extending/modifying/$(your-verb-here)
the _architecture_ of NETCONF and YANG. It is not clear which WG is respons= ible for the underlying architecture. RFC 6244 was produced by NETMOD but t= hen it describes more the framework and not the underlying architectural mo= del (what Randy Presuhn I think calls the meta model). Perhaps we need to work on an architecture at some = point in time, pretty much like we needed to define an architecture for SNM= P at some point in time. The work on JSON encoding and the mount proposal c= learly indicates that certain architectural assumptions are implicit and that leads to discussions that are difficult = to close until we agree on an architecture.

Who said history does not repeat?

/js

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

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

 

 

--_000_EF64FF31F4C4384DBCE5D513A791C2B120A46249xmbalnx11ciscoc_-- From nobody Wed Oct 15 01:58:01 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 592D41A19EB for ; Wed, 15 Oct 2014 01:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, 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 pdz_buVihETq for ; Wed, 15 Oct 2014 01:57: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 D16781A19E7 for ; Wed, 15 Oct 2014 01:57:56 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 30991758; Wed, 15 Oct 2014 10:57: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 0_uZWcCTuXnd; Wed, 15 Oct 2014 10:57:52 +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, 15 Oct 2014 10:57:53 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 112C620036; Wed, 15 Oct 2014 10:57:53 +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 8ip6s6-61BFO; Wed, 15 Oct 2014 10:57: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 940CF20035; Wed, 15 Oct 2014 10:57:50 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7C8F22EF82C8; Wed, 15 Oct 2014 10:57:50 +0200 (CEST) Date: Wed, 15 Oct 2014 10:57:50 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20141015085750.GB72751@elstar.local> Mail-Followup-To: Ladislav Lhotka , NETMOD Working Group References: <20141013110516.25281.32846.idtracker@ietfa.amsl.com> <0031A8ED-D33E-459C-A648-8595821EE6FB@nic.cz> <20141013141959.GC53210@elstar.local> <20141014134259.GB70425@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/qYTKAQ8k9u1X-J6ZjxCTRvwXJhY Cc: NETMOD Working Group Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-json-01.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, 15 Oct 2014 08:57:59 -0000 On Tue, Oct 14, 2014 at 05:32:09PM +0200, Ladislav Lhotka wrote: > > On 14 Oct 2014, at 15:43, Juergen Schoenwaelder wrote: > > > On Tue, Oct 14, 2014 at 12:12:24PM +0200, Ladislav Lhotka wrote: > >> Juergen Schoenwaelder writes: > >> > >>> Lada, > >>> > >>> thanks for the update. I think we still have open issues: > >>> > >>> - Namespace name. The YANG namespace statement declares a URI to be > >>> used as a namespace while you propose to use module names in JSON. > >>> This makes round-trip conversions more difficult that needed. I do > >>> not think we resolved this issue. Lets not reiterate it but lets > >>> also not declare it resolved. ;-) > >> > >> I believe you are the only one who wants to clutter JSON text with > >> namespace URIs. Consider, for example, how awkward instance-identifiers > >> would be. Namespace URI definition is in YANG only for the sake of > >> XML. Round trip conversions are not difficult (see pyang), the only > >> caveat being that you need access to the data model, but this is > >> inevitable anyway. > > > > Yes, I prefer to be able to do conversions without having to have the > > data model at hand. You like to design things such that it is required > > to have the data model available for any conversion. It seems > > everything else follows from this. > > It is not about conversions, I can imagine an implementation that doesn’t touch XML at all. The right question for me is: If we have YANG and forget about XML, what is the most natural representation of instance data in JSON? The answer probably won’t be that numbers be encoded as strings. Actually, I think it is a testimony to YANG design that the JSON encoding can be done quite nicely. > I can imagine many things as well. This discussion does not help. > >>> - I am not sure I understand this logic: > >>> > >>> This document defines no mapping between the contents of JSON- and > >>> XML-encoded anyxml instances. It is not necessary because anyxml > >>> contents are not subject to YANG-based validation (see sec. 7.10 in > >>> [RFC6020]). > >>> > >>> Are you saying things outside of validation can be simply ignored? > >>> It is not totally clear why this is the case. I have something like > >>> Kent's configlets in mind for example. > >> > >> The central theme of the draft is no more XML-JSON translation, it just > >> defines JSON encoding is a similar was as the "XML Mapping Rules" > >> sections in RFC 6020 do for XML. So section 5.5 specifies the valid > >> encoding of an anyxml instance. > >> > >> If we have "anyxml foo;", then we know > >> > >> "foo": [null, [1, 2, true]] > >> > >> is a valid instance. Why should the draft try to specify the translation to XML? > >> > >> In the case of configlets, Kent might provide a specification of their > >> encoding in both XML and JSON. > >> > >>> You maybe wanted to say that anyxml data should be rendered as much > >>> as possible using the various JSON types but how this is done is > >>> implementation specific. Since anyxml itself is essentially open > >>> ended XML, this is no worse that using anyxml in the first place. > >> > >> I am not sure I understand, the draft just says that an anyxml instance > >> is encoded as a name/value pair and that the value part has to be a valid > >> JSON value. The sentence you cited is related to sec. 3 which relies on > >> JSON->XML mapping for instance validation - and for this purpose it is > >> really irrelevant how anyxml content is translated as long as we start > >> with valid JSON and end up with valid XML. > > > > I can agree on "the draft just says that an anyxml instance is encoded > > as a name/value pair and that the value part has to be a valid JSON > > value." - where I am having trouble is the reasoning given. Perhaps > > this does the job equally well: > > > > OLD > > > > An anyxml instance is translated to a name/value pair. The value can > > be of any valid JSON type, i.e. an object, array, number, string or > > any of the literals 'true', 'false' and 'null'. > > > > This document defines no mapping between the contents of JSON- and > > XML-encoded anyxml instances. It is not necessary because anyxml > > contents are not subject to YANG-based validation (see sec. 7.10 in > > [RFC6020]). > > > > NEW > > > > An anyxml instance is translated to a name/value pair. The value can > > be of any valid JSON type, i.e. an object, array, number, string or > > any of the literals 'true', 'false' and 'null'. How the anyxml content > > is mapped to JSON types is implementation specific. > > The problem with this is that there needn’t be any mapping involved, e.g., a client could just put a JSON value there and the server will receive it without doing any conversion. So in fact anyxml has the meaning of “anyjson” or “anydata” here. > > With respect to sec. 3, the text could perhaps say that the mapping of anydata instances to XML *for validation purposes* is an empty element. Nothing else is needed. If you dislike 'mapped to' replace it with 'represented by'. > >>> - It is not clear whether it is legal to encode everything into a > >>> string. This was discussed some time ago since essentially YANG's > >>> type system is based in literal string representations. > >> > >> What do you mean? For example, sec. 6.3 clearly says that boolean values > >> are encoded as JSON literal names 'true' and 'false', i.e. no > >> string. The same is true for numbers except for 64-bit ones. > >> > >> I don't agree that YANG type system requires string encoding of the > >> values. > > > > The question is whether you mandate that the encoder has type > > information available when rendering the JSON structure and whether > > you mandate that a receiver fails if the JSON type does not match its > > expectations (given the YANG data model it knows about). It again is a > > question whether we mandate type information to be available or > > whether a sender is allowed to send "1234" as "1234" in case no type > > information is available. > > My understanding is that even XML encoder has to use the data model in order to be able to distinguish integers from decimal numbers and encode them properly. And similarly for decoders - they have to know whether a received (string) value is to be put into an integer or string variable. > I think I explained it before. I am familiar with one implementation that maintains a tree structure where all values are in string representation and the tree structure does not carry any type information. Serializing this tree structure to XML is straight forward. Serializing this tree structure to JSON is difficult since it is now required to know type information and namespace to module name mappings. Perhaps the concensus will be that this kind of implementation is wrong and needs to change for JSON (and perhaps other encodings) but please do not argue that this code does not exist. > >>> - Related to the above: Do we really treat "bar": 13.5 as an encoding > >>> error? What is gained by doing this in comparison to simply convert > >> > >> Yes. The client says it is a number so why should the server coerce it > >> to a string on its own? > > > > Because the API used internally is not using the JSON type system but > > a type system that stems from YANG. JSON is an encoding, not more. And > > the union type shows that to follow what YANG does, you have to > > stringify values or you have to drop values because of type conflicts. > > I think I recall that at least one RESTCONF implementation converts to > > strings instead of raising encoding errors. > > We can discuss this but I think at the root of the issues with unions is the inability to indicate the actual type of an instance. I don’t agree though with introducing a hard rule that all union values be encoded as strings. > Whether we/you like it or not, this is how things work today. Section 9.12. says: When a string representing a union data type is validated, the string is validated against each member type, in the order they are specified in the "type" statement, until a match is found. /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 Oct 15 02:43:41 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E32011A1A09 for ; Wed, 15 Oct 2014 02:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.039 X-Spam-Level: * X-Spam-Status: No, score=1.039 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 EhWli-a9E-ah for ; Wed, 15 Oct 2014 02:43:36 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 210DD1A1A04 for ; Wed, 15 Oct 2014 02:43:36 -0700 (PDT) Received: from [172.20.6.143] (unknown [172.20.6.143]) by mail.nic.cz (Postfix) with ESMTPSA id 80B1913F7B7; Wed, 15 Oct 2014 11:43:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1413366214; bh=QBnraCcIGYkwC4VA5gBRWYl9xKg906OR+I+E16h1xCQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=TbwJjF1T52Bi2d42J7SfoLtSjXVFE0GbASPkYlLOUF0nHU9yp/73UONZPrknyr+Pr SXTHibA53JqjmqLEOwphWO2KKxJLM00qXVgWWkZUBkCiwcYpuAjprj4Gs+vnX8HkBP 4psSPxec9emq2XVBkwX1LIORxVUwRjow7d/exFoA= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <20141015085750.GB72751@elstar.local> Date: Wed, 15 Oct 2014 11:43:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <304278F9-CB5B-4AAC-8E5D-79A7F6E9A889@nic.cz> References: <20141013110516.25281.32846.idtracker@ietfa.amsl.com> <0031A8ED-D33E-459C-A648-8595821EE6FB@nic.cz> <20141013141959.GC53210@elstar.local> <20141014134259.GB70425@elstar.local> <20141015085750.GB72751@elstar.local> To: =?windows-1252?Q?J=FCrgen_Sch=F6nw=E4lder?= X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/6abFclN-aNl7wMOlBRJYG-rtf3k Cc: NETMOD Working Group Subject: Re: [netmod] New Version Notification for draft-ietf-netmod-yang-json-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: Wed, 15 Oct 2014 09:43:39 -0000 On 15 Oct 2014, at 10:57, Juergen Schoenwaelder = wrote: > On Tue, Oct 14, 2014 at 05:32:09PM +0200, Ladislav Lhotka wrote: >>=20 >> On 14 Oct 2014, at 15:43, Juergen Schoenwaelder = wrote: >>=20 >>> On Tue, Oct 14, 2014 at 12:12:24PM +0200, Ladislav Lhotka wrote: >>>> Juergen Schoenwaelder = writes: >>>>=20 >>>>> Lada, >>>>>=20 >>>>> thanks for the update. I think we still have open issues: >>>>>=20 >>>>> - Namespace name. The YANG namespace statement declares a URI to = be >>>>> used as a namespace while you propose to use module names in JSON. >>>>> This makes round-trip conversions more difficult that needed. I do >>>>> not think we resolved this issue. Lets not reiterate it but lets >>>>> also not declare it resolved. ;-) >>>>=20 >>>> I believe you are the only one who wants to clutter JSON text with >>>> namespace URIs. Consider, for example, how awkward = instance-identifiers >>>> would be. Namespace URI definition is in YANG only for the sake of >>>> XML. Round trip conversions are not difficult (see pyang), the only >>>> caveat being that you need access to the data model, but this is >>>> inevitable anyway. >>>=20 >>> Yes, I prefer to be able to do conversions without having to have = the >>> data model at hand. You like to design things such that it is = required >>> to have the data model available for any conversion. It seems >>> everything else follows from this. >>=20 >> It is not about conversions, I can imagine an implementation that = doesn=92t touch XML at all. The right question for me is: If we have = YANG and forget about XML, what is the most natural representation of = instance data in JSON? The answer probably won=92t be that numbers be = encoded as strings. Actually, I think it is a testimony to YANG design = that the JSON encoding can be done quite nicely. >>=20 >=20 > I can imagine many things as well. This discussion does not help. Well, so what does help? I think it comes down to the role we assign to = JSON in the NETCONF/YANG ecosystem, i.e. whether the encoding provides a = first-class representation of YANG-modelled data, or just a dummy = intended for appeasing those malcontents that push JSON. Also, JSON is more than just another encoding in the sense of UTF-8 = versus UTF-16, it is a different API.=20 >=20 >>>>> - I am not sure I understand this logic: >>>>>=20 >>>>> This document defines no mapping between the contents of JSON- = and >>>>> XML-encoded anyxml instances. It is not necessary because = anyxml >>>>> contents are not subject to YANG-based validation (see sec. 7.10 = in >>>>> [RFC6020]). >>>>>=20 >>>>> Are you saying things outside of validation can be simply ignored? >>>>> It is not totally clear why this is the case. I have something = like >>>>> Kent's configlets in mind for example. >>>>=20 >>>> The central theme of the draft is no more XML-JSON translation, it = just >>>> defines JSON encoding is a similar was as the "XML Mapping Rules" >>>> sections in RFC 6020 do for XML. So section 5.5 specifies the valid >>>> encoding of an anyxml instance. >>>>=20 >>>> If we have "anyxml foo;", then we know >>>>=20 >>>> "foo": [null, [1, 2, true]] >>>>=20 >>>> is a valid instance. Why should the draft try to specify the = translation to XML? >>>>=20 >>>> In the case of configlets, Kent might provide a specification of = their >>>> encoding in both XML and JSON. >>>>=20 >>>>> You maybe wanted to say that anyxml data should be rendered as = much >>>>> as possible using the various JSON types but how this is done is >>>>> implementation specific. Since anyxml itself is essentially open >>>>> ended XML, this is no worse that using anyxml in the first place. >>>>=20 >>>> I am not sure I understand, the draft just says that an anyxml = instance >>>> is encoded as a name/value pair and that the value part has to be a = valid >>>> JSON value. The sentence you cited is related to sec. 3 which = relies on >>>> JSON->XML mapping for instance validation - and for this purpose it = is >>>> really irrelevant how anyxml content is translated as long as we = start >>>> with valid JSON and end up with valid XML.=20 >>>=20 >>> I can agree on "the draft just says that an anyxml instance is = encoded >>> as a name/value pair and that the value part has to be a valid JSON >>> value." - where I am having trouble is the reasoning given. Perhaps >>> this does the job equally well: >>>=20 >>> OLD >>>=20 >>> An anyxml instance is translated to a name/value pair. The value = can >>> be of any valid JSON type, i.e. an object, array, number, string or >>> any of the literals 'true', 'false' and 'null'. >>>=20 >>> This document defines no mapping between the contents of JSON- and >>> XML-encoded anyxml instances. It is not necessary because anyxml >>> contents are not subject to YANG-based validation (see sec. 7.10 in >>> [RFC6020]). >>>=20 >>> NEW >>>=20 >>> An anyxml instance is translated to a name/value pair. The value = can >>> be of any valid JSON type, i.e. an object, array, number, string or >>> any of the literals 'true', 'false' and 'null'. How the anyxml = content >>> is mapped to JSON types is implementation specific. >>=20 >> The problem with this is that there needn=92t be any mapping = involved, e.g., a client could just put a JSON value there and the = server will receive it without doing any conversion. So in fact anyxml = has the meaning of =93anyjson=94 or =93anydata=94 here. >>=20 >> With respect to sec. 3, the text could perhaps say that the mapping = of anydata instances to XML *for validation purposes* is an empty = element. Nothing else is needed.=20 >=20 > If you dislike 'mapped to' replace it with 'represented by=92. Then either the last sentence says the same as the preceding sentence = (any valid JSON value), or I don=92t understand what =93anyxml content=94 = means. >=20 >>>>> - It is not clear whether it is legal to encode everything into a >>>>> string. This was discussed some time ago since essentially YANG's >>>>> type system is based in literal string representations. >>>>=20 >>>> What do you mean? For example, sec. 6.3 clearly says that boolean = values >>>> are encoded as JSON literal names 'true' and 'false', i.e. no >>>> string. The same is true for numbers except for 64-bit ones. >>>>=20 >>>> I don't agree that YANG type system requires string encoding of the >>>> values. >>>=20 >>> The question is whether you mandate that the encoder has type >>> information available when rendering the JSON structure and whether >>> you mandate that a receiver fails if the JSON type does not match = its >>> expectations (given the YANG data model it knows about). It again is = a >>> question whether we mandate type information to be available or >>> whether a sender is allowed to send "1234" as "1234" in case no type >>> information is available. >>=20 >> My understanding is that even XML encoder has to use the data model = in order to be able to distinguish integers from decimal numbers and = encode them properly. And similarly for decoders - they have to know = whether a received (string) value is to be put into an integer or string = variable. =20 >>=20 >=20 > I think I explained it before. I am familiar with one implementation > that maintains a tree structure where all values are in string > representation and the tree structure does not carry any type > information. Serializing this tree structure to XML is straight > forward. Serializing this tree structure to JSON is difficult since it > is now required to know type information and namespace to module name > mappings. Perhaps the concensus will be that this kind of > implementation is wrong and needs to change for JSON (and perhaps > other encodings) but please do not argue that this code does not > exist. But this is all implementation detail, as Andy likes to say. I = understand that applications that were written only for XML may be = structured in a certain way. An application with support for JSON should = perhaps be structured in a different way but this doesn=92t mean it is = more difficult to write. The jsonxsl plugin in pyang represents the JSON encoding logic as an = XSLT stylesheet, so I guess any programming language should be able to = do the same. =20 >=20 >>>>> - Related to the above: Do we really treat "bar": 13.5 as an = encoding >>>>> error? What is gained by doing this in comparison to simply = convert >>>>=20 >>>> Yes. The client says it is a number so why should the server coerce = it >>>> to a string on its own? >>>=20 >>> Because the API used internally is not using the JSON type system = but >>> a type system that stems from YANG. JSON is an encoding, not more. = And >>> the union type shows that to follow what YANG does, you have to >>> stringify values or you have to drop values because of type = conflicts. >>> I think I recall that at least one RESTCONF implementation converts = to >>> strings instead of raising encoding errors. >>=20 >> We can discuss this but I think at the root of the issues with unions = is the inability to indicate the actual type of an instance. I don=92t = agree though with introducing a hard rule that all union values be = encoded as strings.=20 >>=20 >=20 > Whether we/you like it or not, this is how things work today. Section > 9.12. says: >=20 > When a string representing a union data type is validated, the = string > is validated against each member type, in the order they are > specified in the "type" statement, until a match is found. In our case we are validating a number representing union data type, not = string. 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 Oct 15 02:51:27 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42D4B1A19E7 for ; Wed, 15 Oct 2014 02:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.14 X-Spam-Level: * X-Spam-Status: No, score=1.14 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, 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 ZeWZ7nndFMt0 for ; Wed, 15 Oct 2014 02:51:22 -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 C66F51A1A04 for ; Wed, 15 Oct 2014 02:51:22 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 912A075A; Wed, 15 Oct 2014 11:51:21 +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 6rmSNFxMYkq5; Wed, 15 Oct 2014 11:51:20 +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, 15 Oct 2014 11:51:20 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id A399D20036; Wed, 15 Oct 2014 11:51:20 +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 ntt_O7wT8jRF; Wed, 15 Oct 2014 11:51:16 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C65C020035; Wed, 15 Oct 2014 11:51:19 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9E7E92EF85C4; Wed, 15 Oct 2014 11:51:19 +0200 (CEST) Date: Wed, 15 Oct 2014 11:51:19 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20141015095119.GB72972@elstar.local> Mail-Followup-To: Ladislav Lhotka , NETMOD Working Group References: <20141013110516.25281.32846.idtracker@ietfa.amsl.com> <0031A8ED-D33E-459C-A648-8595821EE6FB@nic.cz> <20141013141959.GC53210@elstar.local> <20141014134259.GB70425@elstar.local> <20141015085750.GB72751@elstar.local> <304278F9-CB5B-4AAC-8E5D-79A7F6E9A889@nic.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <304278F9-CB5B-4AAC-8E5D-79A7F6E9A889@nic.cz> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/FU2859ARs8r6ejVZF2WyesP-phY Cc: NETMOD Working Group Subject: Re: [netmod] New Version Notification for draft-ietf-netmod-yang-json-01.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, 15 Oct 2014 09:51:25 -0000 On Wed, Oct 15, 2014 at 11:43:32AM +0200, Ladislav Lhotka wrote: > > > > > I can imagine many things as well. This discussion does not help. > > Well, so what does help? > It helps if we two shut up and others who followed the discussion tell us their opinion. To be clear, I will not involve myself in determining consensus on this set of issues. I will ask my co-chair to do 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 Wed Oct 15 04:38:13 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBAD81A1B17 for ; Wed, 15 Oct 2014 04:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.339 X-Spam-Level: X-Spam-Status: No, score=0.339 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, 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 saJdvoybzb5f for ; Wed, 15 Oct 2014 04:38:10 -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 CA6131A1B29 for ; Wed, 15 Oct 2014 04:38: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 986DBAC1; Wed, 15 Oct 2014 13:38:08 +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 UL5qxvDSSeqb; Wed, 15 Oct 2014 13:38: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; Wed, 15 Oct 2014 13:38:02 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5C41420132; Wed, 15 Oct 2014 13:37:09 +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 WG59XYLSTaDd; Wed, 15 Oct 2014 13:37:04 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D9E3A200F1; Wed, 15 Oct 2014 13:36:49 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 75A642EF8B89; Wed, 15 Oct 2014 13:36:49 +0200 (CEST) Date: Wed, 15 Oct 2014 13:36:49 +0200 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20141015113649.GB73470@elstar.local> Mail-Followup-To: Balazs Lengyel , "netmod@ietf.org" References: <5436922D.3090107@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5436922D.3090107@ericsson.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/O2bL5y8MAf8IHTfbABZeJYXAIro Cc: "netmod@ietf.org" Subject: Re: [netmod] Additions to the issue list 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, 15 Oct 2014 11:38:11 -0000 On Thu, Oct 09, 2014 at 03:48:29PM +0200, Balazs Lengyel wrote: > Hello Jurgen, Martin, > Following the decisions of the new York interim could you please add > actions and nonUnique leaf-lists as separate issues to the YANG 1.1 > issue list please. Yes. I am also adding the noncharacters issue that Lada brought up so we can track that one as well. Should be online soon... /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 Oct 15 05:31:35 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 997A71A00C6 for ; Wed, 15 Oct 2014 05:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.151 X-Spam-Level: * X-Spam-Status: No, score=1.151 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, T_FILL_THIS_FORM_SHORT=0.01, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=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 Vz4QezRyypXA for ; Wed, 15 Oct 2014 05:31: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 4668C1A6F01 for ; Wed, 15 Oct 2014 05:31: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 1C3FE8E3 for ; Wed, 15 Oct 2014 14:31: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 62TevRdyZ-9p for ; Wed, 15 Oct 2014 14:31: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 for ; Wed, 15 Oct 2014 14:31:29 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id AE4CC20036 for ; Wed, 15 Oct 2014 14:31:29 +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 shISm34flLyN; Wed, 15 Oct 2014 14:31: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 24E4C20035; Wed, 15 Oct 2014 14:31:28 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 518D62EF8DBC; Wed, 15 Oct 2014 14:31:27 +0200 (CEST) Date: Wed, 15 Oct 2014 14:31:26 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20141015123126.GA73828@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="4Ckj6UjgE2iN1+kY" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/TiU1wk6JkACr9n0E_FsrsK2meVc Subject: [netmod] yang 1.1 virtual interim meeting today 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, 15 Oct 2014 12:31:34 -0000 --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, we will meet again virtually today (in about 90 minutes) to work on the YANG 1.1 issues. The webex information is attached and I will be using etherpad to take notes: http://etherpad.tools.ietf.org:9000/p/notes-ietf-netmod-virtual-interim-2014-10-15?useMonospaceFont=true I have updated the issues list. In particular, I added: * OPEN :Y56: UTF8 non-characters * OPEN :Y57: unique leaf-list * OPEN :Y58: associate an actions with a data node We right now have these issues left in the OPEN state: * OPEN :Y05: unprefixed path in top-level typedef * OPEN :Y09: introduce optional keys <> * OPEN :Y10: allow restrictions on enumerations * OPEN :Y13: allow multiple inheritance for identities * OPEN :Y16: module advertisement optimization <> * OPEN :Y18: fix "when" expression context node problem * OPEN :Y25: make enum numbering purely informative and optional * OPEN :Y26: allow mandatory nodes in augment * OPEN :Y28: support default values in leaf-lists * OPEN :Y34: remove/deprecate/replace the 'anyxml' statement * OPEN :Y42: a better model for configuration versus state data is needed * OPEN :Y45: better conformance mechanism <> * OPEN :Y49: clarify nested submodule behavior * OPEN :Y54: remove the advertisement of conformance information in NETCONF hello message * OPEN :Y56: UTF8 non-characters * OPEN :Y57: unique leaf-list * OPEN :Y58: associate an actions with a data node My proposal is to backwards through this list today, skipping any issues where actions are still pending. Note that we also have these issues in the REVIEW state: * REVIEW :Y01: allow boolean if-feature * REVIEW :Y03: allow if-feature in refine * REVIEW :Y06: escaped characters in double quoted strings * REVIEW :Y07: do not allow when or if-feature on keys * REVIEW :Y14: clarify the string value for identities when used in must/when * REVIEW :Y20: new set of built-in XPath functions * REVIEW :Y23: support negative patterns as string restrictions * REVIEW :Y29: allow choice as a short-hand case * REVIEW :Y30: allow leafref in union * REVIEW :Y31: allow require-instance in leafref * REVIEW :Y35: allow empty in union If people review the I-D and they are fine with the resolution, please let us know so we can eventually move things from REVIEW to DONE. For the sake of completeness, these issues are left in the EDIT state: * EDIT :Y02: allow must in input, output, and notification * EDIT :Y04: accessible tree in xpath in notifs and rpc * EDIT :Y11: allow if-feature on enums * EDIT :Y12: initialized-by system * EDIT :Y41: clarification of "must" in NP-container <> * EDIT :Y55: clarify type in union /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="webex.txt" Topic: NETMOD WG Date: Every Wednesday, from Wednesday, August 27, 2014 to Wednesday, October 22, 2014 Time: 4:00 pm, Europe Summer Time (Berlin, GMT+02:00) Meeting Number: 649 102 111 Meeting Password: 1234 ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/j.php?MTID=mbbe9c321c8e9f472df4ce74c1987a0f0 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: 1234 4. Click "Join". 5. Follow the instructions that appear on your screen. To view in other time zones or languages, please click the link: https://ietf.webex.com/ietf/j.php?MTID=me720293ef5473cc3bf963302b2f6a8f1 ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- Call-in toll number (US/Canada): 1-650-479-3208 Access code:649 102 111 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/mc 2. On the left navigation bar, click "Support". You can contact me at: cmorgan@amsl.com 1-510-492-4085 To update this meeting to your calendar program (for example Microsoft Outlook), click this link: https://ietf.webex.com/ietf/j.php?MTID=m4f877f2e629b841380e2d593e4e39b87 WebEx will automatically setup Meeting Manager for Windows the first time you join a meeting. To save time, you can setup prior to the meeting by clicking this link: https://ietf.webex.com/ietf/meetingcenter/mcsetup.php The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php. http://www.webex.com CCP:+16504793208x649102111# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. --4Ckj6UjgE2iN1+kY-- From nobody Wed Oct 15 07:49:33 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D00091A870C for ; Wed, 15 Oct 2014 07:49:29 -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, 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 UPD_mxIP385J for ; Wed, 15 Oct 2014 07:49:24 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 4FAC61A854B for ; Wed, 15 Oct 2014 07:49:24 -0700 (PDT) Received: from [192.168.1.121] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 9CB2F28C31E6; Wed, 15 Oct 2014 10:49:23 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_8E5D2903-EA8F-4DAA-A418-61286458D9D2"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: Date: Wed, 15 Oct 2014 10:49:18 -0400 Message-Id: <891D2E85-4CAE-4155-B69C-F013A49F0810@lucidvision.com> References: <20141010210934.GB80385@elstar.local> <20141010215341.GD80385@elstar.local> <20141013192248.GA68615@elstar.local> To: Voit Eric X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/tBTNt6nUtzqIk1bWUZRcyU0eO5I Cc: "netmod@ietf.org" Subject: Re: [netmod] New revision of YANG mount draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 15 Oct 2014 14:49:30 -0000 --Apple-Mail=_8E5D2903-EA8F-4DAA-A418-61286458D9D2 Content-Type: multipart/alternative; boundary="Apple-Mail=_7DB7815C-E0CA-4E05-ACB2-ACE1C4A92384" --Apple-Mail=_7DB7815C-E0CA-4E05-ACB2-ACE1C4A92384 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 14, 2014:6:19 PM, at 6:19 PM, Eric Voit (evoit) = wrote: > Hi Kent, > =20 > There are multiple reasons why current NETCONF based solutions don=92t = hit all the requirements discussed during the thread. Below is a short = incomplete list=85 > =20 > (1) New Service types require systems built upon Eventually = Consistency. If we want to distribute read-only data fast, we might = choose transports other than NETCONF. We might choose protocols which = aren=92t connection oriented. We might even choose to use Multicast = distribution. (Imagine hundreds of VMs reacting to dynamic global = config being delivered from a single definitive source.) Such = alternative transports can remove the burden from the single central = system processing knowing and maintaining connections with each of the = devices. > =20 > (2) There is nothing specific to YANG syntax which makes it only = applicable to EMS. Or specific to point-to-point connection oriented = delivery. The syntax is useful (and used) elsewhere. > =20 > (3) Once we establish that Netconf is not optimal for all transport = options, using a common (YANG) syntax across multiple transports is = demonstrably valuable. This allows transport optimizations to be = abstracted away from logical information model design. > =20 > (4) There are already multiple types of controllers in the network. = Each use their own specific protocol to exchange config and status. Why = ignore that there are already multi-device abstractions in the network? = Why ignore that treating aggregates only by device boundary units can = and will drive errors into a system? Configuring each device = individually is error prone for some abstractions.=20 > =20 > (5) Providing visibility into a peer=92s persistent and running config = data can be very useful. > =20 > (6) Many of these new services can reside within network elements just = as easily as within controllers. Why would we create unnecessary = technology barriers based on historic roles? > =20 > (7) There is huge investment in multiple places on this type of = technology (e.g., OpenDaylight Mount, DDS). Why fight against trends = proving successful already? The IETF should incorporate these = capabilities where advantageous. =09 [NETMOD Chair hat on] It might help to breakup the list above into the three areas = someone suggested the other day (maybe Kent?): yang extension, yang data model, update subscription > IMHO it is in the IETF interests to support fulfill these = requirements. If we don=92t ownership will go elsewhere. There are = already implementations driven by the list of imperatives above. I have discussed whether or not this fits into this WG or = another yesterday with Benoit. He agreed this goes somewhere at the = IETF, but specifically=20 where is up for debate. He has taken the action to chime in with a = direction ASAP. --Tom > =20 > Eric > =20 > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Kent Watsen > Sent: Tuesday, October 14, 2014 3:44 PM > To: Andy Bierman; Alexander Clemm (alex) > Cc: netmod@ietf.org > Subject: Re: [netmod] New revision of YANG mount draft > =20 > =20 > This conversation is going full-circle, so I'll go back to my original = point - that I don't understand the importance for IETF standardization = and question the effectiveness of the solution. > =20 > EMS systems managing devices using NETCONF/YANG have been around for a = few years. It is pretty common for them to 1) provide a mechanism to = get the YANG module used by a device and 2) a low-level API to get/set = device-specific config (as modeled by its YANG) - all with clear = separation of which system "owns" which data. This draft proposes to = fulfill the same need, but in a way that is unique to a Controller/EMS = that itself presents a YANG-defined NETCONF/RESTCONF model. Under = those circumstances, I can almost understand the line of thinking that = led to "mounting" idea (why not, right?), but is this really how a = higher-level OSS/BSS would want it presented. Why wouldn't the = higher-level system use NETCONF to the device directly? - what = semantics does "mounting" bring above and beyond a direct connection to = the device (approval-workflow or network-wide transactional-updates?)=20 > =20 > To Tom's point, it's not enough that some products implement an idea = for there to be a need to add it to a WG charter. I'd rather see = pressing interoperability considerations driving that. > =20 > All that said, I do support the idea of enhancing NETCONF = notifications, if RFC6470's netconf-config-change event isn't = sufficient. If there is a deficiency there, then all NETCONF clients = (not "mount clients") would benefit. > =20 > Thanks, > Kent > =20 > =20 > From: Andy Bierman > Date: Tuesday, October 14, 2014 at 11:40 AM > To: "Alexander Clemm (alex)" > Cc: "netmod@ietf.org" > Subject: Re: [netmod] New revision of YANG mount draft > =20 > =20 > =20 > On Mon, Oct 13, 2014 at 5:52 PM, Alexander Clemm (alex) = wrote: > Hi Juergen, > (several threads to respond to; Eric already provided responses to a = lot of the items, here just a few summary items from my perspective) >=20 > Re: what technical details we think should be standardized: >=20 > - The first aspect is the YANG extension that allows users to define = mountpoints (to logically incorporate subtrees from a remote datastore = under a data node). This can be done as part of a YANG module, i.e. is = data model related. >=20 > - The second aspect is a YANG data model that allows to monitor and = manage a "mount topology". This addresses the system management aspects = of this concept, generally not of concern to the applications that want = to simply access the datastore, but required for a "complete" solution. = Again, this can be done as part of a YANG module, i.e. is data model = related. >=20 > - The third aspect concerns the ability to subscribe to updates to a = YANG datatree, and "push" those updates. This is more general than = mount itself and should presumably be separated into a separate draft. = Subscriptions can be represented as a configurable data model. = Likewise, push can occur through notifications, definable as part of a = data model related. So, that one too is data model related. (It is = conceivable to also introduce different transports here, which would be = discussion for a transport forum; however, our intent was to address = these within the existing framework.) >=20 > Re: overall architecture, you are bringing up an interesting point = that probably needs visiting. RFC 6244, in section 3.1, clearly depicts = the boundary of the server as one device.=20 > =20 > =20 > This is intentional and IMO the proper architecture for a NETCONF = datastore. > The datastore is intended to represent one device, whether that device = is a giant > network controller or a tiny access point. > =20 > I don't agree that replication of subtrees from other servers is the = proper architecture for > a network-wide datastore. It doesn't matter for monitoring, but for = editing the subtrees > are all part of 1 configuration datastore, not isolated replicated = subtrees. =20 > =20 > =20 > =20 > It also suggests that the datastore does not reach beyond the device = boundaries (datastore is actually not depicted, but config database and = "system software components" - presumably for the config data). This is = why we believe the mount capability is needed - to allow the datastore = to reach beyond those boundaries. If this involves extending the = architecture, then so be it. Worth mentioning along the same lines, = since RFC 6244 assumes that YANG will be always used in conjunction with = Netconf: Really, we would like to consider Netconf just one particular = transport / set of services that can operate on / interact with a = datastore, geared towards configuration and fulfillment-related use = cases. That should not rule out the possibility to apply other = transports and services - such as RESTconf (the possi > bility for which is not considered in the RFC), and going forward = possibly other transports/ interfaces, that for example focus on pushing = datastore information and operational data for applications which today = might use SNMP. >=20 > Regarding making this transparent for all Netconf operations: The = important aspect and primary focus of the use case lies in providing an = ability to retrieve remote information. The motivation behind all this = is not to provid "ACID" style management transactions across the network = - in fact, we believe that for many applications a "BASE" style of = management is preferrable and more appropriate, in which transactional = guarantees, ability to rollback,etc, are not provided as long as state = becomes eventually consistent. This is also reflected in the companion = requirements spec. We do not want to be bogged down in the aspects that = would be required to make ACID work. While we believe that "simple" = configuration (not including transactions spanning multiple items) is = achievable, we are happy to "scale down" the mount concept accordingly = and leave transactionality or even configuration as a whole out of = scope. >=20 > =20 > I don't see what is stopping you from implementing your controller. > If you wrap the remote config in anyxml, then all the YANG validation > problems go away. The controller can send NETCONF requests to the = remote devices > on behalf of the northbound client. This seems like just an = implementation detail > for the controller, not a standards issue. > =20 > The request to have the devices push all their operational data to the = controller > is a different matter. That has a huge operational impact, and = something that > NETCONF is not designed for. I suggest using IPFIX for that. > =20 > =20 > =20 >=20 > --- Alex >=20 > =20 > Andy > =20 > =20 > -----Original Message----- > From: Juergen Schoenwaelder = [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, October 13, 2014 12:23 PM > To: Eric Voit (evoit) > Cc: Alexander Clemm (alex); netmod@ietf.org > Subject: Re: [netmod] New revision of YANG mount draft >=20 > On Mon, Oct 13, 2014 at 04:26:55PM +0000, Eric Voit (evoit) wrote: > > > From: Juergen Schoenwaelder, October 10, 2014 5:54 PM > > > > > > I still fail to see how all this falls out of RFC 6020. > > > > If by falling out you mean 'in conflict with', then I would agree = that there are not backwards compatibility issues with RFC 6020 section = 6 syntax. This was by design. > > > > However I believe Alex' and Jan's concerns are with Section 5.1 of = RFC 6020. This section includes statements such as: "For a module or = submodule to reference definitions in an external module, the external = module MUST be imported." > > > > Bringing in targeted nodes and subtrees need not require visibility = into the full submodule where the authoritative copy of the object might = reside. > > >=20 > There is anyxml in YANG 1.0 and there is a proposal for anydata in = YANG 1.1. >=20 > > > I see protocol discussion in draft-clemm-netmod-mount-02.txt = (which > > > is needed for what you want to do and likely even incomplete) but > > > then the NETMOD WG is not about protocol work but about the data > > > modeling language YANG and data models. In fact, my reading of the > > > I-D is that you do not request to change anything in YANG at all - > > > all you propose is to define a few extensions and a data model. > > > > The 'on-demand' Mount does not need any protocol work. It is the = easiest, and is looking to standardize needed several syntax extensions. = This type of Mount is what is implemented in OpenDaylight today. > > >=20 > I am not sure. Can I run all NETCONF protocol operations transparently = across these mount points? I doubt it. >=20 > What you introduce is a "partitioning" of a datastore that does not = architecturally exist so far. Does this lead to a new type of datastore = or can I partition any datastore? How does this partitioning interact = with ephemeral datastores discussed in I2RS? I believe there are serious = _architectural_ questions that need to be discussed and depending on how = they are resolved, there may be more or less protocol work needed. >=20 > What triggered this discussions were statements of the form "YANG does = not allow to do X" which I think is not correct since YANG really is not = the issue. The mount work is extending/modifying/$(your-verb-here) > the _architecture_ of NETCONF and YANG. It is not clear which WG is = responsible for the underlying architecture. RFC 6244 was produced by = NETMOD but then it describes more the framework and not the underlying = architectural model (what Randy Presuhn I think calls the meta model). = Perhaps we need to work on an architecture at some point in time, pretty = much like we needed to define an architecture for SNMP at some point in = time. The work on JSON encoding and the mount proposal clearly indicates = that certain architectural assumptions are implicit and that leads to = discussions that are difficult to close until we agree on an = architecture. >=20 > Who said history does not repeat? >=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 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --Apple-Mail=_7DB7815C-E0CA-4E05-ACB2-ACE1C4A92384 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252


On Oct = 14, 2014:6:19 PM, at 6:19 PM, Eric Voit (evoit) <evoit@cisco.com> wrote:

Hi Kent,
 
There are multiple = reasons why current NETCONF based solutions don=92t hit all the = requirements discussed during the thread.  Below is a short = incomplete list=85
 
(1) New Service types require systems built upon = Eventually Consistency. If we want to distribute read-only data fast, we = might choose transports other than NETCONF.  We might choose = protocols which aren=92t connection oriented.  We might even choose = to use Multicast distribution.  (Imagine hundreds of VMs reacting = to dynamic global config being delivered from a single definitive = source.)  Such alternative transports can remove the burden from = the single central system processing knowing and maintaining connections = with each of the devices.
 
(2) There is nothing = specific to YANG syntax which makes it only applicable to = EMS.   Or specific to point-to-point connection oriented = delivery.  The syntax is useful (and used) = elsewhere.
 
(3) Once we establish that Netconf is not optimal for = all transport options, using a common (YANG) syntax across multiple = transports is demonstrably valuable.  This allows transport = optimizations to be abstracted away from logical information model = design.
 
(4) There are already multiple types of controllers = in the network.  Each use their own specific protocol to exchange = config and status.  Why ignore that there are already multi-device = abstractions in the network?  Why ignore that treating aggregates = only by device boundary units can and will drive errors into a system? =    Configuring each device individually is error prone = for some abstractions. 
 
(5) Providing visibility = into a peer=92s persistent and running config data can be very = useful.
 
(6) Many of these new services can reside within = network elements just as easily as within controllers.  Why would = we create unnecessary technology barriers based on historic = roles?
 
(7) There is huge investment in multiple places on = this type of technology (e.g., OpenDaylight Mount, DDS).  Why fight = against trends proving successful already?   The IETF should = incorporate these capabilities where = advantageous.
=
[NETMOD Chair hat = on]

It might help to breakup the list = above into the three areas someone suggested the other day (maybe = Kent?):

yang extension, yang data model, = update subscription

IMHO it is in the IETF interests to support fulfill = these requirements.  If we don=92t ownership will go = elsewhere.  There are already implementations driven by the list of = imperatives = above.

I have = discussed whether or not this fits into this WG or another yesterday = with Benoit. He agreed this goes somewhere at the IETF, but = specifically 
where is up for debate. He has taken the = action to chime in with a direction ASAP.

= --Tom




 
Eric
 
From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Kent = Watsen
Sent: Tuesday, October 14, 2014 = 3:44 PM
To: Andy Bierman; Alexander = Clemm (alex)
Cc: netmod@ietf.org
Subject: Re: [netmod] New revision = of YANG mount draft
 
 
This = conversation is going full-circle, so I'll go back to my original point = - that I don't understand the importance for IETF standardization and = question the effectiveness of the = solution.
 
EMS systems managing devices using NETCONF/YANG have been = around for a few years.  It is pretty common for them to 1) provide = a mechanism to get the YANG module used by a device and 2) a low-level = API to get/set device-specific config (as modeled by its YANG) - all = with clear separation of which system "owns" which data.   =  This draft proposes to fulfill the same need, but in a way that is = unique to a Controller/EMS that itself presents a YANG-defined = NETCONF/RESTCONF model.   Under those circumstances, I can almost = understand the line of thinking that led to "mounting" idea (why not, = right?), but is this really how a higher-level OSS/BSS would want it = presented.  Why wouldn't the higher-level system use NETCONF to the = device directly?  - what semantics does "mounting" bring above and = beyond a direct connection to the device (approval-workflow or = network-wide = transactional-updates?) 
 
To Tom's point, it's not enough that some products = implement an idea for there to be a need to add it to a WG charter. =  I'd rather see pressing interoperability considerations driving = that.
 
All that = said, I do support the idea of enhancing NETCONF notifications, if = RFC6470's netconf-config-change event isn't sufficient.  If there = is a deficiency there, then all NETCONF clients (not "mount clients") = would benefit.
 
Thanks,
Kent
 
 
From: Andy = Bierman <andy@yumaworks.com>
Date: Tuesday, October 14, = 2014 at 11:40 AM
To: "Alexander Clemm = (alex)" <alex@cisco.com>
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] New = revision of YANG mount draft
 
 
 
On Mon, = Oct 13, 2014 at 5:52 PM, Alexander Clemm (alex) <alex@cisco.com> = wrote:
Hi = Juergen,
(several threads to respond to; Eric already provided = responses to a lot of the items, here just a few summary items from my = perspective)

Re: what technical details we think should be = standardized:

- The first aspect is the YANG extension that = allows users to define mountpoints (to logically incorporate subtrees = from a remote datastore under a data node).  This can be done as = part of a YANG module, i.e. is data model related.

- The second = aspect is a YANG data model that allows to monitor and manage a "mount = topology".  This addresses the system management aspects of this = concept, generally not of concern to the applications that want to = simply access the datastore, but required for a "complete" = solution.  Again, this can be done as part of a YANG module, i.e. = is data model related.

- The third aspect concerns the ability to = subscribe to updates to a YANG datatree, and "push" those updates.  = This is more general than mount itself and should presumably be = separated into a separate draft.  Subscriptions can be represented = as a configurable data model.  Likewise, push can occur through = notifications, definable as part of a data model related.  So, that = one too is data model related.  (It is conceivable to also = introduce different transports here, which would be discussion for a = transport forum; however, our intent was to address these within the = existing framework.)

Re: overall architecture, you are bringing = up an interesting point that probably needs visiting.  RFC 6244, in = section 3.1, clearly depicts the boundary of the server as one = device. 
 
 
This is = intentional and IMO the proper architecture for a NETCONF = datastore.
The datastore is intended to represent one device, whether = that device is a giant
network controller or a tiny access = point.
 
I don't = agree that replication of subtrees from other servers is the proper = architecture for
a network-wide datastore.  It doesn't matter for = monitoring, but for editing the = subtrees
are all = part of 1 configuration datastore, not isolated replicated subtrees. =  
 
 
 

It also suggests that the datastore does not reach beyond = the device boundaries (datastore is actually not depicted, but config = database and "system software components" - presumably for the config = data).  This is why we believe the mount capability is needed - to = allow the datastore to reach beyond those boundaries.  If this = involves extending the architecture, then so be it.  Worth = mentioning along the same lines, since RFC 6244 assumes that YANG will = be always used in conjunction with Netconf: Really, we would like to = consider Netconf just one particular transport / set of services that = can operate on / interact with a datastore, geared towards configuration = and fulfillment-related use cases.  That should not rule out the = possibility to apply other transports and services - such as RESTconf = (the possi
 bility for which is not considered in the RFC), and = going forward possibly other transports/ interfaces, that for example = focus on pushing datastore information and operational data for = applications which today might use SNMP.

Regarding making this = transparent for all Netconf operations:  The important aspect and = primary focus of the use case lies in providing an ability to retrieve = remote information.  The motivation behind all this is not to = provid "ACID" style management transactions across the network - in = fact, we believe that for many applications a "BASE" style of management = is preferrable and more appropriate, in which transactional guarantees, = ability to rollback,etc, are not provided as long as state becomes = eventually consistent. This is also reflected in the companion = requirements spec.  We do not want to be bogged down in the aspects = that would be required to make ACID work.  While we believe that = "simple" configuration (not including transactions spanning multiple = items) is achievable, we are happy to "scale down" the mount concept = accordingly and leave transactionality or even configuration as a whole = out of scope.

 
I don't = see what is stopping you from implementing your = controller.
If you wrap the remote config in anyxml, then all the YANG = validation
problems go away.  The controller can send NETCONF = requests to the remote devices
on behalf of the northbound client.   This = seems like just an implementation = detail
for the = controller, not a standards = issue.
 
The = request to have the devices push all their operational data to the = controller
is a different matter.  That has a huge operational = impact, and something that
NETCONF is not designed for.  I suggest using = IPFIX for that.
 
 
 


--- = Alex

 
Andy
 
 
-----Original Message-----
From: Juergen Schoenwaelder = [mailto:j.schoenwaelder@jacobs-university.de]
Sent: Monday, = October 13, 2014 12:23 PM
To: Eric Voit (evoit)
Cc: Alexander = Clemm (alex); netmod@ietf.org
Subject: Re: [netmod] New revision of = YANG mount draft

On Mon, Oct 13, 2014 at 04:26:55PM +0000, Eric = Voit (evoit) wrote:
> > From: Juergen Schoenwaelder, October = 10, 2014 5:54 PM
> >
> > I still fail to see how all = this falls out of RFC 6020.
>
> If by falling out you mean = 'in conflict with', then I would agree that there are not backwards = compatibility issues with RFC 6020 section 6 syntax.  This was by = design.
>
> However I believe Alex' and Jan's concerns are = with Section 5.1 of RFC 6020.   This section includes = statements such as:  "For a module or submodule to reference = definitions in an external module, the external module MUST be = imported."
>
> Bringing in targeted nodes and subtrees need = not require visibility into the full submodule where the authoritative = copy of the object might reside.
>

There is anyxml in YANG = 1.0 and there is a proposal for anydata in YANG 1.1.

> > I = see protocol discussion in draft-clemm-netmod-mount-02.txt = (which
> > is needed for what you want to do and likely even = incomplete) but
> > then the NETMOD WG is not about protocol = work but about the data
> > modeling language YANG and data = models. In fact, my reading of the
> > I-D is that you do not = request to change anything in YANG at all -
> > all you propose = is to define a few extensions and a data model.
>
> The = 'on-demand' Mount does not need any protocol work.  It is the = easiest, and is looking to standardize needed several syntax = extensions.  This type of Mount is what is implemented in = OpenDaylight today.
>

I am not sure. Can I run all NETCONF = protocol operations transparently across these mount points? I doubt = it.

What you introduce is a "partitioning" of a datastore that = does not architecturally exist so far. Does this lead to a new type of = datastore or can I partition any datastore? How does this partitioning = interact with ephemeral datastores discussed in I2RS? I believe there = are serious _architectural_ questions that need to be discussed and = depending on how they are resolved, there may be more or less protocol = work needed.

What triggered this discussions were statements of = the form "YANG does not allow to do X" which I think is not correct = since YANG really is not the issue. The mount work is = extending/modifying/$(your-verb-here)
the _architecture_ of NETCONF = and YANG. It is not clear which WG is responsible for the underlying = architecture. RFC 6244 was produced by NETMOD but then it describes more = the framework and not the underlying architectural model (what Randy = Presuhn I think calls the meta model). Perhaps we need to work on an = architecture at some point in time, pretty much like we needed to define = an architecture for SNMP at some point in time. The work on JSON = encoding and the mount proposal clearly indicates that certain = architectural assumptions are implicit and that leads to discussions = that are difficult to close until we agree on an = architecture.

Who said history does not = repeat?

/js

--
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=
 
__________________= _____________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

= --Apple-Mail=_7DB7815C-E0CA-4E05-ACB2-ACE1C4A92384-- --Apple-Mail=_8E5D2903-EA8F-4DAA-A418-61286458D9D2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUPoluAAoJEPcO+I7eiUJZt18P/2FP7alFZYiTioVNzWafms1E HQxb2VImviHY/DCXWoB8+2PUjIz5TTtNndWSq7y91AimyS3IZqZQLzLkQJfqN7rX 2cuUiNxWdL7dmLSaTNX/bDTsHsaiVFgYJ2vbTqBjbdqm/6VYn4rez40HxQbnTHWI 3lzKXXlMTw2yywx59lB4k/qetEOTVMMY7g6BvxNLr84NGiACG4qRY7gOgzAazKaq DCC237ceWtwF6l1gByAi20MpxQ2ZLDrHzee0ATcpGNvr1cfJO29Gva25UHFfkIYy Z9g95Yi9dNCo1lg6AnhtfNQqrE8+Dxl7X6TjFEo7W0Zq3pM/YajiWZzP1I6hyWmW DOmwlU9Rjqrkk+WPMEoP1qURLr8Dcv2LyxTwqxWOrAbGE4n804p9aNbvsxHFtYYq uxOLpyaYnTn+OFCDUX7jpGVJbDfUAP70LH4da2yxQYgrwvpXSPdwzNAiMEkXMRzt kuj8+e4tP24jC0rP2e0mvoVh/0gdTlkQpESLx4k4jgwoiKR2P3uDVevO5DsYF2GB lemJ6zs8ae4+yHdS5FmSIvJMAiBw7U2NgBLLcfyulpmSynX0prUfX27TUyjeyfRV HXid/HhW3unuLDkodXdXy3PI64I3IQlw/XzfjoJ5Szj4v1dBcW1GTbHrsFHo7CDx kAJnv2h6yGnHBZv658QB =z3HS -----END PGP SIGNATURE----- --Apple-Mail=_8E5D2903-EA8F-4DAA-A418-61286458D9D2-- From nobody Wed Oct 15 10:02:16 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B36911A8963 for ; Wed, 15 Oct 2014 10:02: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 0so4cGpsSLUb for ; Wed, 15 Oct 2014 10:02:10 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DEDF1A8A54 for ; Wed, 15 Oct 2014 10:01:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19956; q=dns/txt; s=iport; t=1413392487; x=1414602087; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=JfO5vNBGoiKlTXl14V7dOnAHuIpXNtpfVlXKF/Ujf+Y=; b=NTLqCTRZE7irYmUAD4FFVio2Ibw4itZ2QyVQZSx0UY+fRkgSU0R21elp 00VHwRE6QEolrzRwSlVX1PvT9gTSNQy2VgMdAJ2jjZw+7vDm5kcEHCADZ qPOnELELMoZgn32UZmNXVg3hRoIUYiuQV999u8OI7MSD2Yc71E4pKMDnJ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAC2nPlStJV2P/2dsb2JhbABbgkhGU1gEyhGBZAEJhnlUAoEWFgF9hAIBAQEDAQEBARpRCwULAgEIEQMBAgEjBAcnCxQJCAIEDgWINggNyFYBAQEBAQEBAwEBAQEBAQEBAQEBF5A9DQQHhEsFkX+ERIJCgX2CUoEwESuDCpEkgXw4gUNsgUiBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,725,1406592000"; d="scan'208,217";a="363317193" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-1.cisco.com with ESMTP; 15 Oct 2014 17:01:26 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s9FH1Qt2020306 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Oct 2014 17:01:26 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.175]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Wed, 15 Oct 2014 12:01:25 -0500 From: "Acee Lindem (acee)" To: Dean Bogdanovic Thread-Topic: [netmod] Call for consensus to Accept ACL Model draft-bogdanovic-netmod-acl-model-02 as a WG draft Thread-Index: AQHP4wqZOFU3Ld8VA0GsywXxS1v2spwo3UyAgADJlQD//91FAIAATkwAgAAiR4CABrX6AIAA00gA Date: Wed, 15 Oct 2014 17:01:25 +0000 Message-ID: References: <3E03501B-CA0B-433D-A18F-F77DD223EBE7@lucidvision.com> <2267A2CF-2103-47A9-99C8-E613017E252A@cisco.com> <2D34D6C8-4D51-44E0-8BF1-5EEC71059F6D@juniper.net> <21FA6976-A2F1-4BC3-A019-44B9EE64FD79@juniper.net> In-Reply-To: <21FA6976-A2F1-4BC3-A019-44B9EE64FD79@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.198] Content-Type: multipart/alternative; boundary="_000_D0641C4F53ECaceeciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/nF8cz9om4mwHkTTR7PF3NpEt29c Cc: NETMOD Working Group Subject: Re: [netmod] Call for consensus to Accept ACL Model draft-bogdanovic-netmod-acl-model-02 as a WG draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 15 Oct 2014 17:02:13 -0000 --_000_D0641C4F53ECaceeciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable From: Dean Bogdanovic > Date: Tuesday, October 14, 2014 at 8:25 PM To: Acee Lindem > Cc: Andy Bierman >, NETMOD Wo= rking Group > Subject: Re: [netmod] Call for consensus to Accept ACL Model draft-bogdanov= ic-netmod-acl-model-02 as a WG draft On Oct 10, 2014, at 5:56 PM, Acee Lindem (acee) > wrote: From: Andy Bierman > Date: Friday, October 10, 2014 at 11:53 AM To: Acee Lindem > Cc: Dean Bogdanovic >, NETMOD W= orking Group > Subject: Re: [netmod] Call for consensus to Accept ACL Model draft-bogdanov= ic-netmod-acl-model-02 as a WG draft On Fri, Oct 10, 2014 at 8:13 AM, Acee Lindem (acee) > wrote: Hi Dean, On 10/10/14, 9:17 AM, "Dean Bogdanovic" > wrote: > >On Oct 9, 2014, at 9:16 PM, Acee Lindem (acee) > wrote: > >> Authors, >> >> I have reviewed the document and have two rather fundamental comments >>that preclude me from supporting WG adoption. >> >> 1. I think you should change the rule-name (type string) to a >>sequence-number (type uint16 or int32). While using a string is >>ostensibly more flexible, network administrators have been using >>sequence numbers for over 30 years now and will be throughly >>disappointed when they discover that ACE =B310=B2 lexicographically prece= des >>ACE =B32=B2. This comment has broader significance than just access list= s >>since this model, if adopted and standardized, will set a precedent for >>future models. > >Well, this is something we posted on the mailing list to ask opinions. I=B9ll have to look in the archives. Was the rule-name string given support or simply no opposition? > Problem with the sequence number is that inserting new entries is a >problem if the space is exhausted between entries. The rule-name type >string is more flexible then a sequence number. Like I said, list based policies have used sequence numbers for over 30 years and this has not proved to be a serious problem. I don=B9t think we should change semantics with so little benefit when modeling existing constructs. For something completely new, these new ordering semantics could be explored. If I=B9m the only one who sees this as unwieldy, I=B9ll concede. I=B9ve auto-generated many configs with number based interface names or VRFs and been really annoyed at the sorted ordering. But this is YANG, not CLI. YANG has user-ordered lists so the keys do not have to be used to dictate an order (and should not be used). The keys can be used to describe the entry, so "9" and "10" are just labels. They sort correctly because the list is ordered-by user and the user knows that, and is expected to provide or insert entries in the desired ord= er. Okay =96 I missed this distinction but understand it now. Can we then add a= sequence-number to the model that an implementation knows how to order the= ACEs? Thanks, Acee You can easily make a proprietary extension based on the newco example. The= re is nothing preventing you to do that. Or we could make the IETF ACL model semantics match those of at least 90% o= f the world=92s extant access-lists. There is also nothing preventing the u= s from doing that. Why would we want to do anything different? In fact, we = could support both the real world ACL semantics and the current proposal. leaf rule-name-number { type union { type uint16; type string; } } Thanks, Acee Dean Andy > >> 2. Please remove section 5 from the draft. This draft should not mix >>packet filtering and route filtering. Though we may get to this >>hierarchy, I believe that prefix-lists have much greater affinity with >>other routing policies than access-lists. Note that there is a separate >>route-filtering model in >>https://datatracker.ietf.org/doc/draft-zhdankin-netmod-bgp-cfg/. >>Finally, the RTGWG is now chartered for YANG models that are not >>specific to other Routing area working groups. The discussion of route >>filters belongs there or in IDR (since BGP has the most rigorous routing >>policy requirements). > >This is just an example how to add standard extensions. We needed a basic >example how to extend standard features and as you can see it is a bare >minimum. Maybe enforcing language that this is solely an example would >help? I didn=B9t notice that it was an example. I think this needs to be more clear - maybe even moved to an appendix. However, I=B9m happy as long as it is not normative. Thanks, Acee > >Dean > >> >> Also, a comparably minor comment, leaf-list targets requires a better >>definition. It really isn=B9t very useful without some guidance as to how >>an implementation=B9s targets should be represented. >> >> Thanks, >> Acee >> >> >> >> On Oct 8, 2014, at 11:14 AM, Thomas D. Nadeau > >>wrote: >> >>> >>> The co-authors of draft-bogdanovic-netmod-acl-model-02 have asked t= he >>>NETMOD chairs to post a call to adopt the draft as a WG document. >>> >>> The draft can be found here: >>> >>> http://tools.ietf.org/html/draft-bogdanovic-netmod-acl-model-02 >>> >>> The model itself has been extracted and can be directly accessed he= re >>>using git: >>> >>> >>> https://github.com/YangModels/yang/blob/master/experimental/ietf/AC= L-MO >>>DEL/ >>> >>> Please comment by the close of business on Monday, October 13, 2014= . >>> >>> >>> --Tom (As NETMOD 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 > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --_000_D0641C4F53ECaceeciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <402867A4A45C834DA958131B57C7481E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable


From: Dean Bogdanovic <deanb@juniper.net>
Date: Tuesday, October 14, 2014 at = 8:25 PM
To: Acee Lindem <acee@cisco.com>
Cc: Andy Bierman <andy@yumaworks.com>, NETMOD Working Group &l= t;netmod@ietf.org>
Subject: Re: [netmod] Call for cons= ensus to Accept ACL Model draft-bogdanovic-netmod-acl-model-02 as a WG draf= t


On Oct 10, 2014, at 5:56 PM, Acee Lindem (acee) <acee@cisco.com> wrote:



From: Andy Bierman <andy@yumaworks.com>
Date: Friday, October 10, 2014 at 1= 1:53 AM
To: Acee Lindem <acee@cisco.com>
Cc: Dean Bogdanovic <deanb@juniper.net>, NETMOD Working Group &= lt;netmod@ietf.org>
Subject: Re: [netmod] Call for cons= ensus to Accept ACL Model draft-bogdanovic-netmod-acl-model-02 as a WG draf= t



On Fri, Oct 10, 2014 at 8:13 AM, Acee Lindem (ac= ee) <acee@cisco.com&= gt; wrote:
Hi Dean,

On 10/10/14, 9:17 AM, "Dean Bogdanovic" <deanb@juniper.net> wrote:

>
>On Oct 9, 2014, at 9:16 PM, Acee Lindem (acee) <acee@cisco.com> wrote:
>
>> Authors,
>>
>> I have reviewed the document and have two rather fundamental comme= nts
>>that preclude me from supporting WG adoption.
>>
>>    1. I think you should change the rule-name (type stri= ng) to a
>>sequence-number (type uint16 or int32). While using a string is
>>ostensibly more flexible, network administrators have been using >>sequence numbers for over 30 years now and will be throughly
>>disappointed when they discover that ACE =B310=B2 lexicographically= precedes
>>ACE =B32=B2.  This comment has broader significance than just = access lists
>>since this model, if adopted and standardized, will set a precedent= for
>>future models.
>
>Well, this is something we posted on the mailing list to ask opinions.<= br>
I=B9ll have to look in the archives. Was the rule-name string given support=
or simply no opposition?

> Problem with the sequence number is that inserting new entries is a >problem if the space is exhausted between entries. The rule-name type >string is more flexible then a sequence number.

Like I said, list based policies have used sequence numbers for over 30
years and this has not proved to be a serious problem. I don=B9t think we should change semantics with so little benefit when modeling existing
constructs. For something completely new, these new ordering semantics
could be explored. If I=B9m the only one who sees this as unwieldy, I=B9ll<= br> concede. I=B9ve auto-generated many configs with number based interface
names or VRFs and been really annoyed at the sorted ordering.



But this is YANG, not CLI.
YANG has user-ordered lists so the keys do not have to be used
to dictate an order (and should not be used).  The keys can be
used to describe the entry, so "9" and "10" are ju= st labels.
They sort correctly because the list is ordered-by user and the user
knows that, and is expected to provide or insert entries in the desire= d order.

Okay =96 I missed this distinction but understand it now. Can we then = add a sequence-number to the model that an implementation knows how to orde= r the ACEs? 
Thanks,
Acee

You can easily make a proprietary extension based on the newco example. The= re is nothing preventing you to do that. 

Or we could make the IETF ACL model semantics match those of at least = 90% of the world=92s extant access-lists. There is also nothing preventing = the us from doing that. Why would we want to do anything different? In fact= , we could support both the real world ACL semantics and the current proposal. 

     leaf rule-name-number { 
          type union {
                type uint16;
                type string; &= nbsp;
          }
     }

Thanks,
Acee 




Dean






Andy


 

>
>>    2. Please remove section 5 from the draft. This draft= should not mix
>>packet filtering and route filtering. Though we may get to this
>>hierarchy, I believe that prefix-lists have much greater affinity w= ith
>>other routing policies  than access-lists. Note that there is = a separate
>>route-filtering model in
>>https://datatracker.ietf.org/doc/draft-zhdankin-= netmod-bgp-cfg/.
>>Finally, the RTGWG is now chartered for YANG models that are not >>specific to other Routing area working groups. The discussion of ro= ute
>>filters belongs there or in IDR (since BGP has the most rigorous ro= uting
>>policy requirements).
>
>This is just an example how to add standard extensions. We needed a bas= ic
>example how to extend standard features and as you can see it is a bare=
>minimum.  Maybe enforcing language that this is solely an example = would
>help?

I didn=B9t notice that it was an example. I think this needs to be more
clear - maybe even moved to an appendix. However, I=B9m happy as long as it=
is not normative.

Thanks,
Acee


>
>Dean
>
>>
>> Also, a comparably minor comment, leaf-list targets requires a bet= ter
>>definition. It really isn=B9t very useful without some guidance as = to how
>>an implementation=B9s targets should be represented.
>>
>> Thanks,
>> Acee
>>
>>
>>
>> On Oct 8, 2014, at 11:14 AM, Thomas D. Nadeau <tnadeau@lucidvision.com>
>>wrote:
>>
>>>
>>>     The co-authors of draft-bogdanovic-netmod-a= cl-model-02 have asked the
>>>NETMOD chairs to post a call to adopt the draft as a WG documen= t.
>>>
>>>     The draft can be found here:
>>>
>>>     http://tools.ietf.org/ht= ml/draft-bogdanovic-netmod-acl-model-02
>>>
>>>     The model itself has been extracted and can= be directly accessed here
>>>using git:
>>>
>>>
>>>     https://github.c= om/YangModels/yang/blob/master/experimental/ietf/ACL-MO
>>>DEL/
>>>
>>>     Please comment by the close of business on = Monday, October 13, 2014.
>>>
>>>
>>>     --Tom (As NETMOD 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
>

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


 --_000_D0641C4F53ECaceeciscocom_-- From nobody Wed Oct 15 10:14:57 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D2DD1AC399 for ; Wed, 15 Oct 2014 10:14: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 51mlP1u4cfnt for ; Wed, 15 Oct 2014 10:14:36 -0700 (PDT) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 329741A90B0 for ; Wed, 15 Oct 2014 10:14:36 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id cm18so1135688qab.20 for ; Wed, 15 Oct 2014 10:14: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=yLRwpUcun7yqYedjwRM0h0KixfPpS3uL0Xfd08UAgAw=; b=ZjCZtRQMByzpYzXvvLFqrDB6CJ5NKWO/a2RWVlqUQTWk3mfsHfDJv10ycQiIQl4UFC YMXe0MPFvQE9faHOr/nkUvx6um0oHuGB8EMuiOrWfE5YVqx5TQahq9lB7+DeUIXs1JMO 2+PQxgbVbDWBD3h7orRXn1xtXUESS51MNowhitruF/GU9dOJw6HBaddJshETDMuj1hc1 iSBXGAgXlQNTsVK6xamxdGbFSJV9ygKp5vAaph0P5iqev8XMMF7aqrebk9VWn+0G9qCA /lmdXwgAwSCO+4zopzcfauClDEaCyRlfqcEXfZ+f//LlsoId2g1BL0XHgV2+k/KNbzFY aFoA== X-Gm-Message-State: ALoCoQlCL3TNGlRVM2B/olMWZGqDnzST3BMd12aHlmjgNs+uiTZktNiBBnotf9tK6UJNZ4UruiBX MIME-Version: 1.0 X-Received: by 10.140.109.53 with SMTP id k50mr21318387qgf.83.1413393275272; Wed, 15 Oct 2014 10:14:35 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Wed, 15 Oct 2014 10:14:35 -0700 (PDT) In-Reply-To: References: <3E03501B-CA0B-433D-A18F-F77DD223EBE7@lucidvision.com> <2267A2CF-2103-47A9-99C8-E613017E252A@cisco.com> <2D34D6C8-4D51-44E0-8BF1-5EEC71059F6D@juniper.net> <21FA6976-A2F1-4BC3-A019-44B9EE64FD79@juniper.net> Date: Wed, 15 Oct 2014 10:14:35 -0700 Message-ID: From: Andy Bierman To: "Acee Lindem (acee)" Content-Type: multipart/alternative; boundary=001a113a6bf619d951050579444c Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/eDPLw5P16HpT-9YOL3Z4FC5Fpu0 Cc: NETMOD Working Group Subject: Re: [netmod] Call for consensus to Accept ACL Model draft-bogdanovic-netmod-acl-model-02 as a WG draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 15 Oct 2014 17:14:44 -0000 --001a113a6bf619d951050579444c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Oct 15, 2014 at 10:01 AM, Acee Lindem (acee) wrote= : > > > From: Dean Bogdanovic > Date: Tuesday, October 14, 2014 at 8:25 PM > To: Acee Lindem > Cc: Andy Bierman , NETMOD Working Group < > netmod@ietf.org> > Subject: Re: [netmod] Call for consensus to Accept ACL Model > draft-bogdanovic-netmod-acl-model-02 as a WG draft > > > On Oct 10, 2014, at 5:56 PM, Acee Lindem (acee) wrote: > > > > From: Andy Bierman > Date: Friday, October 10, 2014 at 11:53 AM > To: Acee Lindem > Cc: Dean Bogdanovic , NETMOD Working Group < > netmod@ietf.org> > Subject: Re: [netmod] Call for consensus to Accept ACL Model > draft-bogdanovic-netmod-acl-model-02 as a WG draft > > > > On Fri, Oct 10, 2014 at 8:13 AM, Acee Lindem (acee) > wrote: > >> Hi Dean, >> >> On 10/10/14, 9:17 AM, "Dean Bogdanovic" wrote: >> >> > >> >On Oct 9, 2014, at 9:16 PM, Acee Lindem (acee) wrote: >> > >> >> Authors, >> >> >> >> I have reviewed the document and have two rather fundamental comments >> >>that preclude me from supporting WG adoption. >> >> >> >> 1. I think you should change the rule-name (type string) to a >> >>sequence-number (type uint16 or int32). While using a string is >> >>ostensibly more flexible, network administrators have been using >> >>sequence numbers for over 30 years now and will be throughly >> >>disappointed when they discover that ACE =B310=B2 lexicographically pr= ecedes >> >>ACE =B32=B2. This comment has broader significance than just access l= ists >> >>since this model, if adopted and standardized, will set a precedent fo= r >> >>future models. >> > >> >Well, this is something we posted on the mailing list to ask opinions. >> >> I=B9ll have to look in the archives. Was the rule-name string given supp= ort >> or simply no opposition? >> >> > Problem with the sequence number is that inserting new entries is a >> >problem if the space is exhausted between entries. The rule-name type >> >string is more flexible then a sequence number. >> >> Like I said, list based policies have used sequence numbers for over 30 >> years and this has not proved to be a serious problem. I don=B9t think w= e >> should change semantics with so little benefit when modeling existing >> constructs. For something completely new, these new ordering semantics >> could be explored. If I=B9m the only one who sees this as unwieldy, I=B9= ll >> concede. I=B9ve auto-generated many configs with number based interface >> names or VRFs and been really annoyed at the sorted ordering. >> >> > > But this is YANG, not CLI. > YANG has user-ordered lists so the keys do not have to be used > to dictate an order (and should not be used). The keys can be > used to describe the entry, so "9" and "10" are just labels. > They sort correctly because the list is ordered-by user and the user > knows that, and is expected to provide or insert entries in the desired > order. > > > Okay - I missed this distinction but understand it now. Can we then add > a sequence-number to the model that an implementation knows how to order > the ACEs? > Thanks, > Acee > > > You can easily make a proprietary extension based on the newco example. > There is nothing preventing you to do that. > > > Or we could make the IETF ACL model semantics match those of at least > 90% of the world's extant access-lists. There is also nothing preventing > the us from doing that. Why would we want to do anything different? In > fact, we could support both the real world ACL semantics and the current > proposal. > > leaf rule-name-number { > type union { > type uint16; > type string; > } > } > > The IETF data model cannot do both. Either the list is ordered-by user and there are no sequence numbers, or the list is ordered-by system and the sequence numbers determine the execution order. A leaf augmenting the standard data model cannot override the ordered-by user semantics. Keep in mind that NETCONF does not have a "rename" operation, so if this leaf is used in the key, then making room for a new entry means deleting the old entries and recreating them with new keys. An M2M API should be able to handle ordered-by user just fine, but if the CLI is also used to configure the same data model, then sequence numbers would be needed. In this case, I think backward compatibility with CLI is more important than more elegant YANG usage, so the 'rule-name-number' proposal is OK (w/ ordered-by system). Thanks, > Acee > > > > Andy > > Dean > > > > > > > Andy > > > > >> >> > >> >> 2. Please remove section 5 from the draft. This draft should not m= ix >> >>packet filtering and route filtering. Though we may get to this >> >>hierarchy, I believe that prefix-lists have much greater affinity with >> >>other routing policies than access-lists. Note that there is a separa= te >> >>route-filtering model in >> >>https://datatracker.ietf.org/doc/draft-zhdankin-netmod-bgp-cfg/. >> >>Finally, the RTGWG is now chartered for YANG models that are not >> >>specific to other Routing area working groups. The discussion of route >> >>filters belongs there or in IDR (since BGP has the most rigorous routi= ng >> >>policy requirements). >> > >> >This is just an example how to add standard extensions. We needed a bas= ic >> >example how to extend standard features and as you can see it is a bare >> >minimum. Maybe enforcing language that this is solely an example would >> >help? >> >> I didn=B9t notice that it was an example. I think this needs to be more >> clear - maybe even moved to an appendix. However, I=B9m happy as long as= it >> is not normative. >> >> Thanks, >> Acee >> >> >> > >> >Dean >> > >> >> >> >> Also, a comparably minor comment, leaf-list targets requires a better >> >>definition. It really isn=B9t very useful without some guidance as to = how >> >>an implementation=B9s targets should be represented. >> >> >> >> Thanks, >> >> Acee >> >> >> >> >> >> >> >> On Oct 8, 2014, at 11:14 AM, Thomas D. Nadeau > > >> >>wrote: >> >> >> >>> >> >>> The co-authors of draft-bogdanovic-netmod-acl-model-02 have aske= d >> the >> >>>NETMOD chairs to post a call to adopt the draft as a WG document. >> >>> >> >>> The draft can be found here: >> >>> >> >>> http://tools.ietf.org/html/draft-bogdanovic-netmod-acl-model-02 >> >>> >> >>> The model itself has been extracted and can be directly accessed >> here >> >>>using git: >> >>> >> >>> >> >>> >> https://github.com/YangModels/yang/blob/master/experimental/ietf/ACL-MO >> >>>DEL/ >> >>> >> >>> Please comment by the close of business on Monday, October 13, >> 2014. >> >>> >> >>> >> >>> --Tom (As NETMOD 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 >> > >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > > > --001a113a6bf619d951050579444c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Wed, Oct 15, 2014 at 10:01 AM, Acee Lindem (acee) = <acee@cisco.com&= gt; wrote:


From: Dean Bogdanovic <deanb@juniper.net> Date: Tuesday, October 14, 2014 at = 8:25 PM
To: Acee Lindem <acee@cisco.com>
Cc: Andy Bierman <andy@yumaworks.com>, NETMO= D Working Group <ne= tmod@ietf.org>
Subject: Re: [netmod] Call for cons= ensus to Accept ACL Model draft-bogdanovic-netmod-acl-model-02 as a WG draf= t


On Oct 10, 2014, at 5:56 PM, Acee Lindem (acee) <acee@cisco.com> wrote:



From: Andy Bierman <andy@yumaworks.com>
Date: Friday, October 10, 2014 at 1= 1:53 AM
To: Acee Lindem <acee@cisco.com>
Cc: Dean Bogdanovic <deanb@juniper.net>, NETM= OD Working Group <n= etmod@ietf.org>
Subject: Re: [netmod] Call for cons= ensus to Accept ACL Model draft-bogdanovic-netmod-acl-model-02 as a WG draf= t



On Fri, Oct 10, 2014 at 8:13 AM, Acee Lindem (ac= ee) <acee@cisco.com&= gt; wrote:
Hi Dean,

On 10/10/14, 9:17 AM, "Dean Bogdanovic" <deanb@juniper.net> wrote:

>
>On Oct 9, 2014, at 9:16 PM, Acee Lindem (acee) <acee@cisco.com> wrote:
>
>> Authors,
>>
>> I have reviewed the document and have two rather fundamental comme= nts
>>that preclude me from supporting WG adoption.
>>
>>    1. I think you should change the rule-name (type stri= ng) to a
>>sequence-number (type uint16 or int32). While using a string is
>>ostensibly more flexible, network administrators have been using >>sequence numbers for over 30 years now and will be throughly
>>disappointed when they discover that ACE =B310=B2 lexicographically= precedes
>>ACE =B32=B2.  This comment has broader significance than just = access lists
>>since this model, if adopted and standardized, will set a precedent= for
>>future models.
>
>Well, this is something we posted on the mailing list to ask opinions.<= br>
I=B9ll have to look in the archives. Was the rule-name string given support=
or simply no opposition?

> Problem with the sequence number is that inserting new entries is a >problem if the space is exhausted between entries. The rule-name type >string is more flexible then a sequence number.

Like I said, list based policies have used sequence numbers for over 30
years and this has not proved to be a serious problem. I don=B9t think we should change semantics with so little benefit when modeling existing
constructs. For something completely new, these new ordering semantics
could be explored. If I=B9m the only one who sees this as unwieldy, I=B9ll<= br> concede. I=B9ve auto-generated many configs with number based interface
names or VRFs and been really annoyed at the sorted ordering.



But this is YANG, not CLI.
YANG has user-ordered lists so the keys do not have to be used
to dictate an order (and should not be used).  The keys can be
used to describe the entry, so "9" and "10" are ju= st labels.
They sort correctly because the list is ordered-by user and the user
knows that, and is expected to provide or insert entries in the desire= d order.

Okay – I missed this distinction but understand it now. Can we t= hen add a sequence-number to the model that an implementation knows how to = order the ACEs? 
Thanks,
Acee

You can easily make a proprietary extension based on the newco example. The= re is nothing preventing you to do that. 

Or we could make the IETF ACL model semantics match those of at least = 90% of the world’s extant access-lists. There is also nothing prevent= ing the us from doing that. Why would we want to do anything different? In = fact, we could support both the real world ACL semantics and the current proposal. 

     leaf rule-name-number { 
          type union {
                type uint16;
                type string; &= nbsp;
          }
     }


The IETF data model c= annot do both.
Either the list is ordered-by user and there are n= o sequence numbers,
or the list is ordered-by system and the = sequence numbers determine the
execution order. A leaf augmenting= the standard data model cannot override
the ordered-by user sema= ntics.

Keep in mind that NETCONF does not have a &= quot;rename" operation, so
if this leaf is used in the key, = then making room for a new entry
means deleting the old entries a= nd recreating them with new keys.

An M2M API shoul= d be able to handle ordered-by user just fine,
but if the CLI is = also used to configure the same data model,
then sequence numbers= would be needed.  In this case, I think
backward compatibil= ity with CLI is more important than more elegant YANG
usage, so t= he 'rule-name-number' proposal is OK (w/ ordered-by system).
<= div>

Thanks,
Acee 





Andy
 

Dean






Andy


 

>
>>    2. Please remove section 5 from the draft. This draft= should not mix
>>packet filtering and route filtering. Though we may get to this
>>hierarchy, I believe that prefix-lists have much greater affinity w= ith
>>other routing policies  than access-lists. Note that there is = a separate
>>route-filtering model in
>>https://datatracker.ietf.org/doc/draft-zhdankin-= netmod-bgp-cfg/.
>>Finally, the RTGWG is now chartered for YANG models that are not >>specific to other Routing area working groups. The discussion of ro= ute
>>filters belongs there or in IDR (since BGP has the most rigorous ro= uting
>>policy requirements).
>
>This is just an example how to add standard extensions. We needed a bas= ic
>example how to extend standard features and as you can see it is a bare=
>minimum.  Maybe enforcing language that this is solely an example = would
>help?

I didn=B9t notice that it was an example. I think this needs to be more
clear - maybe even moved to an appendix. However, I=B9m happy as long as it=
is not normative.

Thanks,
Acee


>
>Dean
>
>>
>> Also, a comparably minor comment, leaf-list targets requires a bet= ter
>>definition. It really isn=B9t very useful without some guidance as = to how
>>an implementation=B9s targets should be represented.
>>
>> Thanks,
>> Acee
>>
>>
>>
>> On Oct 8, 2014, at 11:14 AM, Thomas D. Nadeau <tnadeau@lucidvision.com>= ;
>>wrote:
>>
>>>
>>>     The co-authors of draft-bogdanovic-netmod-a= cl-model-02 have asked the
>>>NETMOD chairs to post a call to adopt the draft as a WG documen= t.
>>>
>>>     The draft can be found here:
>>>
>>>     http://tools.ietf.org/ht= ml/draft-bogdanovic-netmod-acl-model-02
>>>
>>>     The model itself has been extracted and can= be directly accessed here
>>>using git:
>>>
>>>
>>>     https://github.c= om/YangModels/yang/blob/master/experimental/ietf/ACL-MO
>>>DEL/
>>>
>>>     Please comment by the close of business on = Monday, October 13, 2014.
>>>
>>>
>>>     --Tom (As NETMOD co-chair)
>>>
>>>
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ie= tf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.o= rg
>> https://www.ietf.org/mailman/listinfo/netmod
>

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

--001a113a6bf619d951050579444c-- From nobody Wed Oct 15 23:44:40 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8D8A1A0366 for ; Wed, 15 Oct 2014 23:44:38 -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 QNymFfras9y4 for ; Wed, 15 Oct 2014 23:44:36 -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 7B83F1A0364 for ; Wed, 15 Oct 2014 23:44:36 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNR92514; Thu, 16 Oct 2014 06:44:33 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 16 Oct 2014 07:44:32 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.21]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Thu, 16 Oct 2014 14:44:29 +0800 From: Qin Wu To: "Alexander Clemm (alex)" , Juergen Schoenwaelder , "Jan Medved (jmedved)" Thread-Topic: [netmod] New revision of YANG mount draft Thread-Index: AQHP40RfcXk3qRma8kec20irC7AonJwoMIcAgAEfzwCAAANUgIACcN1wgAKCsoCAA/m7gA== Date: Thu, 16 Oct 2014 06:44:27 +0000 Message-ID: References: <20141010210934.GB80385@elstar.local> In-Reply-To: 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: http://mailarchive.ietf.org/arch/msg/netmod/JPYpnCXlowrFLWggo_TfjqGud_Q Cc: "netmod@ietf.org" Subject: Re: [netmod] New revision of YANG mount draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 16 Oct 2014 06:44:39 -0000 SGksIEFsZXg6DQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogQWxleGFuZGVyIENsZW1tIChh bGV4KSBbbWFpbHRvOmFsZXhAY2lzY28uY29tXSANCreiy83KsbzkOiAyMDE0xOoxMNTCMTTI1SA4 OjU4DQrK1bz+yMs6IFFpbiBXdTsgSnVlcmdlbiBTY2hvZW53YWVsZGVyOyBKYW4gTWVkdmVkIChq bWVkdmVkKQ0Ks63LzTogbmV0bW9kQGlldGYub3JnDQrW98ziOiBSRTogW25ldG1vZF0gTmV3IHJl dmlzaW9uIG9mIFlBTkcgbW91bnQgZHJhZnQNCg0KSGkgUWluLA0KDQouLi4NCg0KW1Fpbl0gSW50 ZXJlc3RpbmcsIElzIHRoaXMgaWRlYSBhYm91dCBkYXRhc3RvcmUgZGF0YSBzeW5jaHJvbml6YXRp b24gaW4gZGlmZmVyZW50IGxldmVscy4gT25lIHN1YnNldCBvZiBkYXRhc3RvcmUgZGF0YSBpbiBs b3dlciBsZXZlbCBjYW4gYmUgbmVzdGVkIGludG8gYSBkYXRhc3RvcmUgaW4gaGlnaGVyIGxldmVs IGFuZCBpbnNlcnRlZCBhcyBtb3VudGluZyBwb2ludC4gRGF0YXN0b3JlIGRhdGEgaW4gbG93ZXIg bGV2ZWwgZG9lc24ndCBuZWVkIHRvIGJlIHVuZm9sZGVkIG9yIGV4cG9zZWQgdG8gbW9yZSBoaWdo ZXIgbGV2ZWwgY2xpZW50IHRoYXQgaXMgb24gdG9wIG9mIHRoZSBjb250cm9sbGVyLiBNb3VudGlu ZyBwb2ludCBwcm92aWRlIGEgcmVmZXJlbmNlIHBvaW50IGluIHRoZSByZW1vdGUgZGF0YXN0b3Jl IHRvIHJldHJpZXZlIHRoZSBkYXRhLiBOZXR3b3JrIHRvcG8gaW5mb3JtYXRpb24gZ2F0aGVyaW5n IGNhbiBiZSBhIGdvb2QgZXhhbXBsZSBmb3Igc3VjaCBkYXRhIHJldHJpZXZpbmcuIA0KDQo8QUxF WD4gIEV4YWN0bHkgPC9BTEVYPg0KDQpbUWluXQ0KQnV0IGl0IGlzIG5vdCBjbGVhciB0byBtZSBo b3cgdGhpcyBjYW4gc3VwcG9ydCBtdWx0aS10ZW5hbmN5IHdoZW4gZGlmZmVyZW50IHRlbmFudCBo YXMgZGlmZmVyZW50IHZpZXcgb2YgbmV0d29yayB0b3BvLg0KSW4gYWRkaXRpb24sIHdoZXJlIHRv IGluc2VydCBkYXRhIGZyb20gcmVtb3RlIGRhdGFzdG9yZSBpbiB0aGUgbG9jYWwgZGF0YXN0b3Jl IGlzIG5vdCB2ZXJ5IGNsZWFyIGFzIHdlbGwuIA0KDQo8QUxFWD4gV2hlcmUgdG8gaW5zZXJ0IGRh dGEgaXMgc3BlY2lmaWVkIGJ5IGEgWUFORyBtb2R1bGUsIGltcGxlbWVudGVkIGJ5IHRoZSBjbGll bnQsIHdoaWNoIHNwZWNpZmllcyB0aGUgbW91bnQgcG9pbnQgaS5lLiBkYXRhIG5vZGVzIGluIHRo ZSBkYXRhc3RvcmUgc3RydWN0dXJlIHdoZXJlIHRvICJpbnNlcnQiIHRoZSByZW1vdGUgZGF0YS4g IA0KDQpbUWluXTogSGF2ZSB5b3UgY29uc2lkZXJlZCByZXRyaWV2aW5nIHBvaW50IGluIHRoZSBy ZW1vdGUgZGF0YXN0b3JlIGlmIHlvdSBvbmx5IHJldHJpZXZlIGEgc3Vic2V0IG9mIHRoZSBkYXRh c3RvcmUgZGF0YT8NCg0KTXVsdGktdGVuYW5jeSBpcyBub3Qgc3BlY2lmaWNhbGx5IGFkZHJlc3Nl ZCBoZXJlLCBhbHRob3VnaCBpdCBjb25zdGl0dXRlcyBhIHZhbGlkIHVzZSBjYXNlIChwZXJoYXBz IHNvbWV0aGluZyB0byBzcGVsbCBvdXQgaW4gdGhlIHJlcXVpcmVtZW50IGRyYWZ0KS4gIFlvdSBj YW4gaGF2ZSBkaWZmZXJlbnQgY2xpZW50IHN5c3RlbXMsIGVhY2ggaW4gdHVybiB3aXRoIHRoZWly IG93biBkYXRhc3RvcmUsIGFuZCBlYWNoIGltcGxlbWVudGluZyBkaWZmZXJlbnQgWUFORyBtb2Rl bHMgd2l0aCBkaWZmZXJlbnQgbW91bnQgcG9pbnRzLCB3aGljaCB0aGVyZWZvcmUgbW91bnQgZGlm ZmVyZW50IGluZm9ybWF0aW9uIGZyb20gYSBzZXJ2ZXIgKG9yIGluY29ycG9yYXRlIHRoZW0gaW4g ZGlmZmVyZW4gd2F5cyBpbnRvIHRoZWlyIG93biByZXNwZWN0aXZlIGRhdGFzdG9yZSBzdHJ1Y3R1 cmUpLiAgPC9BTEVYPg0KDQpbUWluXTogVGhlIHVzZSBjYXNlIHlvdSBnaXZlIHNlZW1zIGFuIGdv b2QgZXhhbXBsZSwgYnV0IEkgYW0gbm90IHN1cmUgaXQgaXMgYWNoaWV2YWJsZSwgd2l0aG91dCBh YnN0cmFjdGlvbiBhbmQgYWdncmVnYXRpb24gb2YgZGF0YSByZXRyaWV2ZWQgZnJvbSByZW1vdGUg ZGF0YXN0b3JlLCB3aXRob3V0IGZpbHRlcmluZyBtZWNoYW5pc20sIEkgZG91YnQgbXVsdGktdGVu YW5jeSBjYW4gYmUgd2VsbCBzdXBwb3J0ZWQuDQoNCi0tLSBBbGV4DQo= From nobody Thu Oct 16 01:13:27 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45C551A03A4 for ; Thu, 16 Oct 2014 01:13:25 -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 VauOo3cEXYUT for ; Thu, 16 Oct 2014 01:13:23 -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 47AB91A039D for ; Thu, 16 Oct 2014 01:13:23 -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 BNS02445; Thu, 16 Oct 2014 08:13:20 +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.158.1; Thu, 16 Oct 2014 09:13:19 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.21]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Thu, 16 Oct 2014 16:13:15 +0800 From: Qin Wu To: "Alexander Clemm (alex)" , Juergen Schoenwaelder , "Eric Voit (evoit)" Thread-Topic: [netmod] New revision of YANG mount draft Thread-Index: AQHP40RfcXk3qRma8kec20irC7AonJwoMIcAgAEfzwCAAANUgIAACP+AgARbs4CAADEkAIAAXAsAgAQkJJA= Date: Thu, 16 Oct 2014 08:13:15 +0000 Message-ID: References: <20141010210934.GB80385@elstar.local> <20141010215341.GD80385@elstar.local> <20141013192248.GA68615@elstar.local> In-Reply-To: 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: http://mailarchive.ietf.org/arch/msg/netmod/H310W2HvqyvCP_9rxSiRXeNhtjE Cc: "netmod@ietf.org" Subject: Re: [netmod] New revision of YANG mount draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 16 Oct 2014 08:13:25 -0000 SGksDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogbmV0bW9kIFttYWlsdG86bmV0bW9kLWJv dW5jZXNAaWV0Zi5vcmddILT6se0gQWxleGFuZGVyIENsZW1tIChhbGV4KQ0Kt6LLzcqxvOQ6IDIw MTTE6jEw1MIxNMjVIDg6NTINCsrVvP7IyzogSnVlcmdlbiBTY2hvZW53YWVsZGVyOyBFcmljIFZv aXQgKGV2b2l0KQ0Ks63LzTogbmV0bW9kQGlldGYub3JnDQrW98ziOiBSZTogW25ldG1vZF0gTmV3 IHJldmlzaW9uIG9mIFlBTkcgbW91bnQgZHJhZnQNCg0KSGkgSnVlcmdlbiwNCihzZXZlcmFsIHRo cmVhZHMgdG8gcmVzcG9uZCB0bzsgRXJpYyBhbHJlYWR5IHByb3ZpZGVkIHJlc3BvbnNlcyB0byBh IGxvdCBvZiB0aGUgaXRlbXMsIGhlcmUganVzdCBhIGZldyBzdW1tYXJ5IGl0ZW1zIGZyb20gbXkg cGVyc3BlY3RpdmUpDQoNClJlOiB3aGF0IHRlY2huaWNhbCBkZXRhaWxzIHdlIHRoaW5rIHNob3Vs ZCBiZSBzdGFuZGFyZGl6ZWQ6DQoNCi0gVGhlIGZpcnN0IGFzcGVjdCBpcyB0aGUgWUFORyBleHRl bnNpb24gdGhhdCBhbGxvd3MgdXNlcnMgdG8gZGVmaW5lIG1vdW50cG9pbnRzICh0byBsb2dpY2Fs bHkgaW5jb3Jwb3JhdGUgc3VidHJlZXMgZnJvbSBhIHJlbW90ZSBkYXRhc3RvcmUgdW5kZXIgYSBk YXRhIG5vZGUpLiAgVGhpcyBjYW4gYmUgZG9uZSBhcyBwYXJ0IG9mIGEgWUFORyBtb2R1bGUsIGku ZS4gaXMgZGF0YSBtb2RlbCByZWxhdGVkLiAgDQoNCi0gVGhlIHNlY29uZCBhc3BlY3QgaXMgYSBZ QU5HIGRhdGEgbW9kZWwgdGhhdCBhbGxvd3MgdG8gbW9uaXRvciBhbmQgbWFuYWdlIGEgIm1vdW50 IHRvcG9sb2d5Ii4gIFRoaXMgYWRkcmVzc2VzIHRoZSBzeXN0ZW0gbWFuYWdlbWVudCBhc3BlY3Rz IG9mIHRoaXMgY29uY2VwdCwgZ2VuZXJhbGx5IG5vdCBvZiBjb25jZXJuIHRvIHRoZSBhcHBsaWNh dGlvbnMgdGhhdCB3YW50IHRvIHNpbXBseSBhY2Nlc3MgdGhlIGRhdGFzdG9yZSwgYnV0IHJlcXVp cmVkIGZvciBhICJjb21wbGV0ZSIgc29sdXRpb24uICBBZ2FpbiwgdGhpcyBjYW4gYmUgZG9uZSBh cyBwYXJ0IG9mIGEgWUFORyBtb2R1bGUsIGkuZS4gaXMgZGF0YSBtb2RlbCByZWxhdGVkLiAgDQoN CltRaW5dOiBNeSBpbnRlcnByZXRhdGlvbiB0byBmaXJzdCB0d28gYXNwZWN0cyBhcmUgb25lIGlz IHRvIGRlZmluZSBkYXRhIG1vZGVsLCB0aGUgb3RoZXIgaXMgdG8gbWFuaXB1bGF0ZSBkYXRhIG1v ZGVsLiBTbyB5ZXMgdGhleSBhcmUgYm90aCBkYXRhIG1vZGVsIHJlbGF0ZWQuDQoNCi0gVGhlIHRo aXJkIGFzcGVjdCBjb25jZXJucyB0aGUgYWJpbGl0eSB0byBzdWJzY3JpYmUgdG8gdXBkYXRlcyB0 byBhIFlBTkcgZGF0YXRyZWUsIGFuZCAicHVzaCIgdGhvc2UgdXBkYXRlcy4gIFRoaXMgaXMgbW9y ZSBnZW5lcmFsIHRoYW4gbW91bnQgaXRzZWxmIGFuZCBzaG91bGQgcHJlc3VtYWJseSBiZSBzZXBh cmF0ZWQgaW50byBhIHNlcGFyYXRlIGRyYWZ0LiAgU3Vic2NyaXB0aW9ucyBjYW4gYmUgcmVwcmVz ZW50ZWQgYXMgYSBjb25maWd1cmFibGUgZGF0YSBtb2RlbC4gIExpa2V3aXNlLCBwdXNoIGNhbiBv Y2N1ciB0aHJvdWdoIG5vdGlmaWNhdGlvbnMsIGRlZmluYWJsZSBhcyBwYXJ0IG9mIGEgZGF0YSBt b2RlbCByZWxhdGVkLiAgU28sIHRoYXQgb25lIHRvbyBpcyBkYXRhIG1vZGVsIHJlbGF0ZWQuICAo SXQgaXMgY29uY2VpdmFibGUgdG8gYWxzbyBpbnRyb2R1Y2UgZGlmZmVyZW50IHRyYW5zcG9ydHMg aGVyZSwgd2hpY2ggd291bGQgYmUgZGlzY3Vzc2lvbiBmb3IgYSB0cmFuc3BvcnQgZm9ydW07IGhv d2V2ZXIsIG91ciBpbnRlbnQgd2FzIHRvIGFkZHJlc3MgdGhlc2Ugd2l0aGluIHRoZSBleGlzdGlu ZyBmcmFtZXdvcmsuKSAgDQoNCltRaW5dOiBCZWZvcmUgc3VwcG9ydCBzdWJzY3JpYmluZywgaGF2 ZSB5b3UgY29uc2lkZXJlZCBob3cgdG8gZGlzY292ZXIgcmVtb3RlIGRhdGFzdG9yZSBvciByZW1v dGUgbm9kZSwgb3IgeW91IGFzc3VtZSB0aGlzIGhhcHBlbnMgdG8gYmUgcHJlY29uZmlndXJlZC4N Cg0K From nobody Thu Oct 16 01:24:17 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 779591A0687 for ; Thu, 16 Oct 2014 01:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.722 X-Spam-Level: X-Spam-Status: No, score=-11.722 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_CHARSET_FARAWAY=2.45, 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 9XbJPf7ZJfd2 for ; Thu, 16 Oct 2014 01:24:13 -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 496081A0398 for ; Thu, 16 Oct 2014 01:24:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5280; q=dns/txt; s=iport; t=1413447853; x=1414657453; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Xs2JRYs6CrvAspC/36F6aO+Mqav9EXwkvo7fHMJDumc=; b=j2watwRRPLri0tAii5Giwzc2Prbm6+fHZrGno9GOOlTm03EagGiu25FV 0DvL2+FeGjwNLniNN9P2RhT8gBu7EDZAKpunCHuPUT0IUzWE7wV6C2kpi U4jkBWhyXaJVGQVIFprIVaxcKQABqA75YsfdF8Nn3Jq/+4bmSTihUWZAB w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAPR/P1StJV2S/2dsb2JhbABRCoMOU1gEgwLJAgqGeVQCG3UWAX2EAgEBAQQBAQExOgsMBAIBBgIOAwQBAQUGAhsFAgIlCxQJCAIEAQ0FCBOIIw2XdpxJCJUSAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSBKI5KKwYQGwcCAgKCbTqBHgEEkX+hcYN3bIFIgQIBAQE X-IronPort-AV: E=Sophos;i="5.04,730,1406592000"; d="scan'208";a="87450744" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-6.cisco.com with ESMTP; 16 Oct 2014 08:24:12 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s9G8OCBk005193 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Oct 2014 08:24:12 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.10]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Thu, 16 Oct 2014 03:24:12 -0500 From: "Ambika Prasad Tripathy (ambtripa)" To: Qin Wu , "Alexander Clemm (alex)" , Juergen Schoenwaelder , "Eric Voit (evoit)" Thread-Topic: [netmod] New revision of YANG mount draft Thread-Index: AQHP40RfcOM1hwrcJEe1+2IHH3kQ9pwoMIcAgAEfzwCAAANUgIAACP+AgARbs4CAADEkAIAAXAsAgAQkJJCAAAK7kA== Date: Thu, 16 Oct 2014 08:24:11 +0000 Message-ID: <3B675C3A8DF102408C754E30986E43CF05CCEF65@xmb-aln-x08.cisco.com> References: <20141010210934.GB80385@elstar.local> <20141010215341.GD80385@elstar.local> <20141013192248.GA68615@elstar.local> In-Reply-To: Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.100.135] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/wcbVT1fywNF2ZHGVZNUBsw2K51o Cc: "netmod@ietf.org" Subject: Re: [netmod] New revision of YANG mount draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 16 Oct 2014 08:24:16 -0000 SGkgUWluLA0KDQo8U25hcD4NCi0gVGhlIHRoaXJkIGFzcGVjdCBjb25jZXJucyB0aGUgYWJpbGl0 eSB0byBzdWJzY3JpYmUgdG8gdXBkYXRlcyB0byBhIFlBTkcgZGF0YXRyZWUsIGFuZCAicHVzaCIg dGhvc2UgdXBkYXRlcy4gIFRoaXMgaXMgbW9yZSBnZW5lcmFsIHRoYW4gbW91bnQgaXRzZWxmIGFu ZCBzaG91bGQgcHJlc3VtYWJseSBiZSBzZXBhcmF0ZWQgaW50byBhIHNlcGFyYXRlIGRyYWZ0LiAg U3Vic2NyaXB0aW9ucyBjYW4gYmUgcmVwcmVzZW50ZWQgYXMgYSBjb25maWd1cmFibGUgZGF0YSBt b2RlbC4gIExpa2V3aXNlLCBwdXNoIGNhbiBvY2N1ciB0aHJvdWdoIG5vdGlmaWNhdGlvbnMsIGRl ZmluYWJsZSBhcyBwYXJ0IG9mIGEgZGF0YSBtb2RlbCByZWxhdGVkLiAgU28sIHRoYXQgb25lIHRv byBpcyBkYXRhIG1vZGVsIHJlbGF0ZWQuICAoSXQgaXMgY29uY2VpdmFibGUgdG8gYWxzbyBpbnRy b2R1Y2UgZGlmZmVyZW50IHRyYW5zcG9ydHMgaGVyZSwgd2hpY2ggd291bGQgYmUgZGlzY3Vzc2lv biBmb3IgYSB0cmFuc3BvcnQgZm9ydW07IGhvd2V2ZXIsIG91ciBpbnRlbnQgd2FzIHRvIGFkZHJl c3MgdGhlc2Ugd2l0aGluIHRoZSBleGlzdGluZyBmcmFtZXdvcmsuKSAgDQoNCltRaW5dOiBCZWZv cmUgc3VwcG9ydCBzdWJzY3JpYmluZywgaGF2ZSB5b3UgY29uc2lkZXJlZCBob3cgdG8gZGlzY292 ZXIgcmVtb3RlIGRhdGFzdG9yZSBvciByZW1vdGUgbm9kZSwgb3IgeW91IGFzc3VtZSB0aGlzIGhh cHBlbnMgdG8gYmUgcHJlY29uZmlndXJlZC4NCjwvU25hcD4NCg0KRGlzY292ZXJ5IGlzIGRpZmZl cmVudCBhc3BlY3QgZnJvbSBtb3VudCBpdHNlbGYuIFRoZXJlIGFyZSBkaWZmZXJlbnQgZGlzY292 ZXJ5IHByb3RvY29scyB0byBpZGVudGlmeSBuZXR3b3JrIG5vZGVzIG9yL2FuZCBjYXBhYmlsaXRp ZXMgYWxsIHRvZ2V0aGVyLiANCg0KTW91bnQgZHJhZnQgZGVmaW5lcyB0aGUgInRhcmdldCIgZXh0 ZW5zaW9uIHRvIGlkZW50aWZ5IHRoZSBzZXJ2ZXIgaW4gd2hpY2ggZGF0YXN0b3JlIHJlc2lkZXMg aW4gc2VjdGlvbiA1LjENCg0KIiAgIG8gIFRoZSBzZWNvbmQgZXh0ZW5zaW9uLCAidGFyZ2V0Iiwg c2VydmVzIGFzIGEgc3Vic3RhdGVtZW50DQogICAgICB1bmRlcm5lYXRoIGEgbW91bnRwb2ludCBz dGF0ZW1lbnQuICBJdCB0YWtlcyBhbiBhcmd1bWVudCB0aGF0DQogICAgICBpZGVudGlmaWVzIHRo ZSB0YXJnZXQgc3lzdGVtLiAgVGhlIGFyZ3VtZW50IGlzIGEgcmVmZXJlbmNlIHRvIGENCiAgICAg IGRhdGEgbm9kZSB0aGF0IGNvbnRhaW5zIHRoZSBpbmZvcm1hdGlvbiB0aGF0IGlzIG5lZWRlZCB0 byBpZGVudGlmeQ0KICAgICAgYW5kIGFkZHJlc3MgYSByZW1vdGUgc2VydmVyLCBzdWNoIGFzIGFu IElQIGFkZHJlc3MsIGEgaG9zdCBuYW1lLA0KICAgICAgb3IgYSBVUkkgW1JGQzM5ODZdLiINCg0K QnIsDQpBbWJpa2ENCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG5ldG1vZCBb bWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUWluIFd1DQpTZW50 OiBUaHVyc2RheSwgT2N0b2JlciAxNiwgMjAxNCAxOjQzIFBNDQpUbzogQWxleGFuZGVyIENsZW1t IChhbGV4KTsgSnVlcmdlbiBTY2hvZW53YWVsZGVyOyBFcmljIFZvaXQgKGV2b2l0KQ0KQ2M6IG5l dG1vZEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtuZXRtb2RdIE5ldyByZXZpc2lvbiBvZiBZQU5H IG1vdW50IGRyYWZ0DQoNCkhpLA0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IG5ldG1vZCBb bWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnXSC0+rHtIEFsZXhhbmRlciBDbGVtbSAoYWxl eCkNCreiy83KsbzkOiAyMDE0xOoxMNTCMTTI1SA4OjUyDQrK1bz+yMs6IEp1ZXJnZW4gU2Nob2Vu d2FlbGRlcjsgRXJpYyBWb2l0IChldm9pdCkNCrOty806IG5ldG1vZEBpZXRmLm9yZw0K1vfM4jog UmU6IFtuZXRtb2RdIE5ldyByZXZpc2lvbiBvZiBZQU5HIG1vdW50IGRyYWZ0DQoNCkhpIEp1ZXJn ZW4sDQooc2V2ZXJhbCB0aHJlYWRzIHRvIHJlc3BvbmQgdG87IEVyaWMgYWxyZWFkeSBwcm92aWRl ZCByZXNwb25zZXMgdG8gYSBsb3Qgb2YgdGhlIGl0ZW1zLCBoZXJlIGp1c3QgYSBmZXcgc3VtbWFy eSBpdGVtcyBmcm9tIG15IHBlcnNwZWN0aXZlKQ0KDQpSZTogd2hhdCB0ZWNobmljYWwgZGV0YWls cyB3ZSB0aGluayBzaG91bGQgYmUgc3RhbmRhcmRpemVkOg0KDQotIFRoZSBmaXJzdCBhc3BlY3Qg aXMgdGhlIFlBTkcgZXh0ZW5zaW9uIHRoYXQgYWxsb3dzIHVzZXJzIHRvIGRlZmluZSBtb3VudHBv aW50cyAodG8gbG9naWNhbGx5IGluY29ycG9yYXRlIHN1YnRyZWVzIGZyb20gYSByZW1vdGUgZGF0 YXN0b3JlIHVuZGVyIGEgZGF0YSBub2RlKS4gIFRoaXMgY2FuIGJlIGRvbmUgYXMgcGFydCBvZiBh IFlBTkcgbW9kdWxlLCBpLmUuIGlzIGRhdGEgbW9kZWwgcmVsYXRlZC4gIA0KDQotIFRoZSBzZWNv bmQgYXNwZWN0IGlzIGEgWUFORyBkYXRhIG1vZGVsIHRoYXQgYWxsb3dzIHRvIG1vbml0b3IgYW5k IG1hbmFnZSBhICJtb3VudCB0b3BvbG9neSIuICBUaGlzIGFkZHJlc3NlcyB0aGUgc3lzdGVtIG1h bmFnZW1lbnQgYXNwZWN0cyBvZiB0aGlzIGNvbmNlcHQsIGdlbmVyYWxseSBub3Qgb2YgY29uY2Vy biB0byB0aGUgYXBwbGljYXRpb25zIHRoYXQgd2FudCB0byBzaW1wbHkgYWNjZXNzIHRoZSBkYXRh c3RvcmUsIGJ1dCByZXF1aXJlZCBmb3IgYSAiY29tcGxldGUiIHNvbHV0aW9uLiAgQWdhaW4sIHRo aXMgY2FuIGJlIGRvbmUgYXMgcGFydCBvZiBhIFlBTkcgbW9kdWxlLCBpLmUuIGlzIGRhdGEgbW9k ZWwgcmVsYXRlZC4gIA0KDQpbUWluXTogTXkgaW50ZXJwcmV0YXRpb24gdG8gZmlyc3QgdHdvIGFz cGVjdHMgYXJlIG9uZSBpcyB0byBkZWZpbmUgZGF0YSBtb2RlbCwgdGhlIG90aGVyIGlzIHRvIG1h bmlwdWxhdGUgZGF0YSBtb2RlbC4gU28geWVzIHRoZXkgYXJlIGJvdGggZGF0YSBtb2RlbCByZWxh dGVkLg0KDQotIFRoZSB0aGlyZCBhc3BlY3QgY29uY2VybnMgdGhlIGFiaWxpdHkgdG8gc3Vic2Ny aWJlIHRvIHVwZGF0ZXMgdG8gYSBZQU5HIGRhdGF0cmVlLCBhbmQgInB1c2giIHRob3NlIHVwZGF0 ZXMuICBUaGlzIGlzIG1vcmUgZ2VuZXJhbCB0aGFuIG1vdW50IGl0c2VsZiBhbmQgc2hvdWxkIHBy ZXN1bWFibHkgYmUgc2VwYXJhdGVkIGludG8gYSBzZXBhcmF0ZSBkcmFmdC4gIFN1YnNjcmlwdGlv bnMgY2FuIGJlIHJlcHJlc2VudGVkIGFzIGEgY29uZmlndXJhYmxlIGRhdGEgbW9kZWwuICBMaWtl d2lzZSwgcHVzaCBjYW4gb2NjdXIgdGhyb3VnaCBub3RpZmljYXRpb25zLCBkZWZpbmFibGUgYXMg cGFydCBvZiBhIGRhdGEgbW9kZWwgcmVsYXRlZC4gIFNvLCB0aGF0IG9uZSB0b28gaXMgZGF0YSBt b2RlbCByZWxhdGVkLiAgKEl0IGlzIGNvbmNlaXZhYmxlIHRvIGFsc28gaW50cm9kdWNlIGRpZmZl cmVudCB0cmFuc3BvcnRzIGhlcmUsIHdoaWNoIHdvdWxkIGJlIGRpc2N1c3Npb24gZm9yIGEgdHJh bnNwb3J0IGZvcnVtOyBob3dldmVyLCBvdXIgaW50ZW50IHdhcyB0byBhZGRyZXNzIHRoZXNlIHdp dGhpbiB0aGUgZXhpc3RpbmcgZnJhbWV3b3JrLikgIA0KDQpbUWluXTogQmVmb3JlIHN1cHBvcnQg c3Vic2NyaWJpbmcsIGhhdmUgeW91IGNvbnNpZGVyZWQgaG93IHRvIGRpc2NvdmVyIHJlbW90ZSBk YXRhc3RvcmUgb3IgcmVtb3RlIG5vZGUsIG9yIHlvdSBhc3N1bWUgdGhpcyBoYXBwZW5zIHRvIGJl IHByZWNvbmZpZ3VyZWQuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRtb2RAaWV0Zi5vcmcNCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo= From nobody Thu Oct 16 06:31:39 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF1571A1BD7 for ; Thu, 16 Oct 2014 06:31:37 -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 aLS92RYQ-jwi for ; Thu, 16 Oct 2014 06:31:35 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B4271A1BCA for ; Thu, 16 Oct 2014 06:31:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 4BC6C540776; Thu, 16 Oct 2014 15:31:32 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NUzaSH5pahTL; Thu, 16 Oct 2014 15:31:27 +0200 (CEST) Received: from localhost (cst-prg-44-254.cust.vodafone.cz [46.135.44.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id B341C540364; Thu, 16 Oct 2014 15:31:25 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman , Juergen Schoenwaelder , Andy Bierman , NETMOD Working Group In-Reply-To: References: <3E03501B-CA0B-433D-A18F-F77DD223EBE7@lucidvision.com> <2267A2CF-2103-47A9-99C8-E613017E252A@cisco.com> <2D34D6C8-4D51-44E0-8BF1-5EEC71059F6D@juniper.net> <0DA310C9-D8A7-4CF4-8AA1-5EC4CF95FE61@gmail.com> <20141010213212.GC80385@elstar.local> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Thu, 16 Oct 2014 15:31:22 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/2YItu007f6mY0KVhc1BGiziDYw4 Subject: Re: [netmod] Call for consensus to Accept ACL Model draft-bogdanovic-netmod-acl-model-02 as a WG draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 16 Oct 2014 13:31:37 -0000 Andy Bierman writes: > On Fri, Oct 10, 2014 at 2:32 PM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > >> On Fri, Oct 10, 2014 at 11:59:46AM -0700, Andy Bierman wrote: >> >> > For a list that is ordered-by user, the order is totally up to the >> client. >> > By default, new user-ordered entries are added last (after existing >> > entries in the target datastore). The order these entries are provided >> > in XML instance documents (e.g. ) must be maintained by the >> > server. >> > In JSON the array order must be preserved. >> >> Are you sure draft-ietf-netmod-yang-json-00.txt says this? If not, >> make sure that Lada adds this as an open issue or an edit request. >> >> > I just checked sec 3.2.3 and 3.2.4. > There is no mention of 'ordered-by user' for leaf-list or list statements. > Lada, add as an open issue... Done: https://github.com/yang-json/yang-json/issues/1 Lada > > /js >> >> > Andy > > >> -- >> 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 Thu Oct 16 07:12:15 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 242D61A1A67 for ; Thu, 16 Oct 2014 07:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ah52unbJO4M for ; Thu, 16 Oct 2014 07:12:11 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBB641A03AB for ; Thu, 16 Oct 2014 07:12:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 037A4540776; Thu, 16 Oct 2014 16:12:09 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6FGQp8Yn81j; Thu, 16 Oct 2014 16:12:04 +0200 (CEST) Received: from localhost (cst-prg-60-3.cust.vodafone.cz [46.135.60.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 639865400EE; Thu, 16 Oct 2014 16:11:56 +0200 (CEST) From: Ladislav Lhotka To: "William Lupton \(wilupton\)" , "netmod\@ietf.org" In-Reply-To: References: User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Thu, 16 Oct 2014 16:11:53 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/U4fWfxfKIXGpC90Uxt_flTbY6Ao Subject: Re: [netmod] Mandatory and optional ranges X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 16 Oct 2014 14:12:13 -0000 Hello William, "William Lupton (wilupton)" writes: > All, > > Someone asked me whether a YANG definition can distinguish the parts of a > range that are mandatory and the parts that are optional, e.g an int leaf > XXX might be required to support 1..10 but 11..20 might be optional. It > seems that being able to associate 11..20 with a feature would be a nice > solution and would be equivalent to YANG 1.1 Y11 (allow if-feature on > enums)? But I don't think that range "1..10|11..20" can be split into > multiple range statements, so this would not be trivial? > > > A use case from the DSL world (I can't be too specific) is where the valid > values for two leaf nodes are coupled. If leaf WWW = 1 then XXX = 1..10 > but if leaf WWW = 2 then XXX = 11..20. A future module version might add > WWW = 3 and tie it to XXX = 21..30. > > I suppose that a "must" statement could be used (?) but I quite like the > feature approach, especially given the analogy with YANG 1.1 Y11. This could be solved by defining a choice with one case for each variant. A must or when statement can then indeed be used for making sure that each case only applies when WWW has the corresponding value. Something like choice XXX { leaf XXX1 { must "../WWW = 1"; type uint8 { range "1..10"; } } leaf XXX2 { must "../WWW = 2"; type uint8 { range "11..20"; } } } Also, you can make a case conditional by using if-feature. Hope this helps, Lada > > Comments? > > Thanks, > William Lupton > > _______________________________________________ > 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 Oct 16 08:27:29 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25CFD1A1BDA for ; Thu, 16 Oct 2014 08:27: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 dvYV2FFtJuvE for ; Thu, 16 Oct 2014 08:27:22 -0700 (PDT) Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 452971A1C00 for ; Thu, 16 Oct 2014 08:27:21 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id w8so2504043qac.37 for ; Thu, 16 Oct 2014 08:27: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=9v5QNWDbzvg5HCgXgEYgSPLvKUoAarLBvJCs9EvezVk=; b=JC09Z0txDdTIbv33qHVHfnVUNStzUmzhA4VwCf5IANfxSgxBNVof9hdBNNHleiNq+r Bi0AjrUjqZAXqvX2x8tn1Ys48sDFPjY3KVKIwvAJ95dXMsFg0OCFCzPPuPpSwMo6iKk4 kQZR0i4eBK2r/Xhh3TNf7EKv/xWtnsvShyL3mXqFl1iqHyb9zmWTk81Esw0Foq5ISH3y c853PEJkYqixZa0HZdsUOrNp38UaHZt8gelxrrzhf5OfUw3GupIAD1iSJ1jOLXSeF0QL gynr1lDdrbAUbC/807Fz7lT4BNarAUqVFipdq758wNB7vOO6ajAsUCxiK7dbeAPhE07Q F3BQ== X-Gm-Message-State: ALoCoQk6NEvCV+Zr1v+kbRX7wupsM/4g+LpEUO1yfRYtcYurF9H1gJV2Cl1be/65vDlj4DvcQw18 MIME-Version: 1.0 X-Received: by 10.224.125.68 with SMTP id x4mr3229592qar.78.1413473240315; Thu, 16 Oct 2014 08:27:20 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Thu, 16 Oct 2014 08:27:20 -0700 (PDT) In-Reply-To: References: <20141010210934.GB80385@elstar.local> <20141010215341.GD80385@elstar.local> <20141013192248.GA68615@elstar.local> Date: Thu, 16 Oct 2014 08:27:20 -0700 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: multipart/alternative; boundary=001a11c302c063b3e805058be2a5 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/NcQ7SJzP0O4PqFvk0ejFilHmW-Q Cc: "netmod@ietf.org" Subject: Re: [netmod] New revision of YANG mount draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 16 Oct 2014 15:27:27 -0000 --001a11c302c063b3e805058be2a5 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 14, 2014 at 12:43 PM, Kent Watsen wrote: > > This conversation is going full-circle, so I'll go back to my original > point - that I don't understand the importance for IETF standardization and > question the effectiveness of the solution. > > EMS systems managing devices using NETCONF/YANG have been around for a > few years. It is pretty common for them to 1) provide a mechanism to get > the YANG module used by a device and 2) a low-level API to get/set > device-specific config (as modeled by its YANG) - all with clear separation > of which system "owns" which data. This draft proposes to fulfill the > same need, but in a way that is unique to a Controller/EMS that itself > presents a YANG-defined NETCONF/RESTCONF model. Under those > circumstances, I can almost understand the line of thinking that led to > "mounting" idea (why not, right?), but is this really how a higher-level > OSS/BSS would want it presented. Why wouldn't the higher-level system use > NETCONF to the device directly? - what semantics does "mounting" bring > above and beyond a direct connection to the device (approval-workflow or > network-wide transactional-updates?) > Before debating the best way to re-architect NETCONF, it would help me to understand why the high level system doesn't just read the devices directly. What problems does this solve? Is the controller like a cache, to offload monitoring overhead from the devices? Since the high-level system is using NETCONF either way, getting the same data models either way, aware of the underlying devices either way, it is not clear to me why the controller is needed for this purpose. Andy > To Tom's point, it's not enough that some products implement an idea for > there to be a need to add it to a WG charter. I'd rather see pressing > interoperability considerations driving that. > > All that said, I do support the idea of enhancing NETCONF notifications, > if RFC6470's netconf-config-change event isn't sufficient. If there is a > deficiency there, then all NETCONF clients (not "mount clients") would > benefit. > > Thanks, > Kent > > > From: Andy Bierman > Date: Tuesday, October 14, 2014 at 11:40 AM > To: "Alexander Clemm (alex)" > Cc: "netmod@ietf.org" > Subject: Re: [netmod] New revision of YANG mount draft > > > > On Mon, Oct 13, 2014 at 5:52 PM, Alexander Clemm (alex) > wrote: > >> Hi Juergen, >> (several threads to respond to; Eric already provided responses to a lot >> of the items, here just a few summary items from my perspective) >> >> Re: what technical details we think should be standardized: >> >> - The first aspect is the YANG extension that allows users to define >> mountpoints (to logically incorporate subtrees from a remote datastore >> under a data node). This can be done as part of a YANG module, i.e. is >> data model related. >> >> - The second aspect is a YANG data model that allows to monitor and >> manage a "mount topology". This addresses the system management aspects of >> this concept, generally not of concern to the applications that want to >> simply access the datastore, but required for a "complete" solution. >> Again, this can be done as part of a YANG module, i.e. is data model >> related. >> >> - The third aspect concerns the ability to subscribe to updates to a YANG >> datatree, and "push" those updates. This is more general than mount itself >> and should presumably be separated into a separate draft. Subscriptions >> can be represented as a configurable data model. Likewise, push can occur >> through notifications, definable as part of a data model related. So, that >> one too is data model related. (It is conceivable to also introduce >> different transports here, which would be discussion for a transport forum; >> however, our intent was to address these within the existing framework.) >> >> Re: overall architecture, you are bringing up an interesting point that >> probably needs visiting. RFC 6244, in section 3.1, clearly depicts the >> boundary of the server as one device. > > > > This is intentional and IMO the proper architecture for a NETCONF > datastore. > The datastore is intended to represent one device, whether that device is > a giant > network controller or a tiny access point. > > I don't agree that replication of subtrees from other servers is the > proper architecture for > a network-wide datastore. It doesn't matter for monitoring, but for > editing the subtrees > are all part of 1 configuration datastore, not isolated replicated > subtrees. > > > > >> It also suggests that the datastore does not reach beyond the device >> boundaries (datastore is actually not depicted, but config database and >> "system software components" - presumably for the config data). This is >> why we believe the mount capability is needed - to allow the datastore to >> reach beyond those boundaries. If this involves extending the >> architecture, then so be it. Worth mentioning along the same lines, since >> RFC 6244 assumes that YANG will be always used in conjunction with Netconf: >> Really, we would like to consider Netconf just one particular transport / >> set of services that can operate on / interact with a datastore, geared >> towards configuration and fulfillment-related use cases. That should not >> rule out the possibility to apply other transports and services - such as >> RESTconf (the possi >> bility for which is not considered in the RFC), and going forward >> possibly other transports/ interfaces, that for example focus on pushing >> datastore information and operational data for applications which today >> might use SNMP. >> >> Regarding making this transparent for all Netconf operations: The >> important aspect and primary focus of the use case lies in providing an >> ability to retrieve remote information. The motivation behind all this is >> not to provid "ACID" style management transactions across the network - in >> fact, we believe that for many applications a "BASE" style of management is >> preferrable and more appropriate, in which transactional guarantees, >> ability to rollback,etc, are not provided as long as state becomes >> eventually consistent. This is also reflected in the companion requirements >> spec. We do not want to be bogged down in the aspects that would be >> required to make ACID work. While we believe that "simple" configuration >> (not including transactions spanning multiple items) is achievable, we are >> happy to "scale down" the mount concept accordingly and leave >> transactionality or even configuration as a whole out of scope. >> >> > I don't see what is stopping you from implementing your controller. > If you wrap the remote config in anyxml, then all the YANG validation > problems go away. The controller can send NETCONF requests to the remote > devices > on behalf of the northbound client. This seems like just an > implementation detail > for the controller, not a standards issue. > > The request to have the devices push all their operational data to the > controller > is a different matter. That has a huge operational impact, and something > that > NETCONF is not designed for. I suggest using IPFIX for that. > > > > >> --- Alex >> >> > Andy > > > >> -----Original Message----- >> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] >> Sent: Monday, October 13, 2014 12:23 PM >> To: Eric Voit (evoit) >> Cc: Alexander Clemm (alex); netmod@ietf.org >> Subject: Re: [netmod] New revision of YANG mount draft >> >> On Mon, Oct 13, 2014 at 04:26:55PM +0000, Eric Voit (evoit) wrote: >> > > From: Juergen Schoenwaelder, October 10, 2014 5:54 PM >> > > >> > > I still fail to see how all this falls out of RFC 6020. >> > >> > If by falling out you mean 'in conflict with', then I would agree that >> there are not backwards compatibility issues with RFC 6020 section 6 >> syntax. This was by design. >> > >> > However I believe Alex' and Jan's concerns are with Section 5.1 of RFC >> 6020. This section includes statements such as: "For a module or >> submodule to reference definitions in an external module, the external >> module MUST be imported." >> > >> > Bringing in targeted nodes and subtrees need not require visibility >> into the full submodule where the authoritative copy of the object might >> reside. >> > >> >> There is anyxml in YANG 1.0 and there is a proposal for anydata in YANG >> 1.1. >> >> > > I see protocol discussion in draft-clemm-netmod-mount-02.txt (which >> > > is needed for what you want to do and likely even incomplete) but >> > > then the NETMOD WG is not about protocol work but about the data >> > > modeling language YANG and data models. In fact, my reading of the >> > > I-D is that you do not request to change anything in YANG at all - >> > > all you propose is to define a few extensions and a data model. >> > >> > The 'on-demand' Mount does not need any protocol work. It is the >> easiest, and is looking to standardize needed several syntax extensions. >> This type of Mount is what is implemented in OpenDaylight today. >> > >> >> I am not sure. Can I run all NETCONF protocol operations transparently >> across these mount points? I doubt it. >> >> What you introduce is a "partitioning" of a datastore that does not >> architecturally exist so far. Does this lead to a new type of datastore or >> can I partition any datastore? How does this partitioning interact with >> ephemeral datastores discussed in I2RS? I believe there are serious >> _architectural_ questions that need to be discussed and depending on how >> they are resolved, there may be more or less protocol work needed. >> >> What triggered this discussions were statements of the form "YANG does >> not allow to do X" which I think is not correct since YANG really is not >> the issue. The mount work is extending/modifying/$(your-verb-here) >> the _architecture_ of NETCONF and YANG. It is not clear which WG is >> responsible for the underlying architecture. RFC 6244 was produced by >> NETMOD but then it describes more the framework and not the underlying >> architectural model (what Randy Presuhn I think calls the meta model). >> Perhaps we need to work on an architecture at some point in time, pretty >> much like we needed to define an architecture for SNMP at some point in >> time. The work on JSON encoding and the mount proposal clearly indicates >> that certain architectural assumptions are implicit and that leads to >> discussions that are difficult to close until we agree on an architecture. >> >> Who said history does not repeat? >> >> /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 >> > > --001a11c302c063b3e805058be2a5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Tue, Oct 14, 2014 at 12:43 PM, Kent Watsen <kwatsen@juniper.net> wrote:

This conversation is going full-circle, so I'll go back to my orig= inal point - that I don't understand the importance for IETF standardiz= ation and question the effectiveness of the solution.

EMS systems managing devices using NETCONF/YANG have been around for a= few years.=A0 It is pretty common for them to 1) provide a mechanism to ge= t the YANG module used by a device and 2) a low-level API to get/set device= -specific config (as modeled by its YANG) - all with clear separation of which system "owns" which d= ata. =A0 =A0This draft proposes to fulfill the same need, but in a way that= is unique to a Controller/EMS that itself presents a YANG-defined NETCONF/= RESTCONF model. =A0 Under those circumstances, I can almost understand the line of thinking that led to "mounting"= ; idea (why not, right?), but is this really how a higher-level OSS/BSS wou= ld want it presented.=A0 Why wouldn't the higher-level system use NETCO= NF to the device directly? =A0- what semantics does "mounting" bring above and beyond a direct connection to the dev= ice (approval-workflow or network-wide transactional-updates?)=A0


Before debating the= best way to re-architect NETCONF, it would help me to understand
why the high level system doesn't just read the devices directly. What= problems does




To Tom's point, it's not enough that some products implement a= n idea for there to be a need to add it to a WG charter.=A0 I'd rather = see pressing interoperability considerations driving that.

All that said, I do support the idea of enhancing NETCONF notification= s, if RFC6470's netconf-config-change event isn't sufficient.=A0 If= there is a deficiency there, then all NETCONF clients (not "mount cli= ents") would benefit.

Thanks,
Kent


From: Andy Bierman <andy@yumaworks.com>
Date: Tuesday, October 14, 2014 at = 11:40 AM
To: "Alexander Clemm (alex)&qu= ot; <alex@cisco.com<= /a>>
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] New revision = of YANG mount draft



On Mon, Oct 13, 2014 at 5:52 PM, Alexander Clemm= (alex) <alex@cisco.com&= gt; wrote:
Hi Juergen,
(several threads to respond to; Eric already provided responses to a lot of= the items, here just a few summary items from my perspective)

Re: what technical details we think should be standardized:

- The first aspect is the YANG extension that allows users to define mountp= oints (to logically incorporate subtrees from a remote datastore under a da= ta node).=A0 This can be done as part of a YANG module, i.e. is data model = related.

- The second aspect is a YANG data model that allows to monitor and manage = a "mount topology".=A0 This addresses the system management aspec= ts of this concept, generally not of concern to the applications that want = to simply access the datastore, but required for a "complete" solution.=A0 Again, this can be done as part of= a YANG module, i.e. is data model related.

- The third aspect concerns the ability to subscribe to updates to a YANG d= atatree, and "push" those updates.=A0 This is more general than m= ount itself and should presumably be separated into a separate draft.=A0 Su= bscriptions can be represented as a configurable data model.=A0 Likewise, push can occur through notifications, definable a= s part of a data model related.=A0 So, that one too is data model related.= =A0 (It is conceivable to also introduce different transports here, which w= ould be discussion for a transport forum; however, our intent was to address these within the existing framework.)
Re: overall architecture, you are bringing up an interesting point that pro= bably needs visiting.=A0 RFC 6244, in section 3.1, clearly depicts the boun= dary of the server as one device.=A0


This is intentional and IMO the proper architecture for a NETCONF data= store.
The datastore is intended to represent one device, whether that device= is a giant
network controller or a tiny access point.

I don't agree that replication of subtrees from other servers is t= he proper architecture for
a network-wide datastore.=A0 It doesn't matter for monitoring, but= for editing the subtrees
are all part of 1 configuration datastore, not isolated replicated sub= trees. =A0


=A0
It also suggests that the datastore does not reach beyond the device bounda= ries (datastore is actually not depicted, but config database and "sys= tem software components" - presumably for the config data).=A0 This is= why we believe the mount capability is needed - to allow the datastore to reach beyond those boundaries.=A0 If this invo= lves extending the architecture, then so be it.=A0 Worth mentioning along t= he same lines, since RFC 6244 assumes that YANG will be always used in conj= unction with Netconf: Really, we would like to consider Netconf just one particular transport / set of services t= hat can operate on / interact with a datastore, geared towards configuratio= n and fulfillment-related use cases.=A0 That should not rule out the possib= ility to apply other transports and services - such as RESTconf (the possi
=A0bility for which is not considered in the RFC), and going forward possib= ly other transports/ interfaces, that for example focus on pushing datastor= e information and operational data for applications which today might use S= NMP.

Regarding making this transparent for all Netconf operations:=A0 The import= ant aspect and primary focus of the use case lies in providing an ability t= o retrieve remote information.=A0 The motivation behind all this is not to = provid "ACID" style management transactions across the network - in fact, we believe that for many applications a &quo= t;BASE" style of management is preferrable and more appropriate, in wh= ich transactional guarantees, ability to rollback,etc, are not provided as = long as state becomes eventually consistent. This is also reflected in the companion requirements spec.=A0 We do not wa= nt to be bogged down in the aspects that would be required to make ACID wor= k.=A0 While we believe that "simple" configuration (not including= transactions spanning multiple items) is achievable, we are happy to "scale down" the mount concept accordingly and l= eave transactionality or even configuration as a whole out of scope.


I don't see what is stopping you from implementing your controller= .
If you wrap the remote config in anyxml, then all the YANG validation<= /div>
problems go away.=A0 The controller can send NETCONF requests to the r= emote devices
on behalf of the northbound client. =A0 This seems like just an implem= entation detail
for the controller, not a standards issue.

The request to have the devices push all their operational data to the= controller
is a different matter.=A0 That has a huge operational impact, and some= thing that
NETCONF is not designed for.=A0 I suggest using IPFIX for that.




--- Alex


Andy

=A0
-----Original Message-----
From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de= ]
Sent: Monday, October 13, 2014 12:23 PM
To: Eric Voit (evoit)
Cc: Alexander Clemm (alex); netmod@ietf.org
Subject: Re: [netmod] New revision of YANG mount draft

On Mon, Oct 13, 2014 at 04:26:55PM +0000, Eric Voit (evoit) wrote:
> > From: Juergen Schoenwaelder, October 10, 2014 5:54 PM
> >
> > I still fail to see how all this falls out of RFC 6020.
>
> If by falling out you mean 'in conflict with', then I would ag= ree that there are not backwards compatibility issues with RFC 6020 section= 6 syntax.=A0 This was by design.
>
> However I believe Alex' and Jan's concerns are with Section 5.= 1 of RFC 6020.=A0 =A0This section includes statements such as:=A0 "For= a module or submodule to reference definitions in an external module, the = external module MUST be imported."
>
> Bringing in targeted nodes and subtrees need not require visibility in= to the full submodule where the authoritative copy of the object might resi= de.
>

There is anyxml in YANG 1.0 and there is a proposal for anydata in YANG 1.1= .

> > I see protocol discussion in draft-clemm-netmod-mount-02.txt (whi= ch
> > is needed for what you want to do and likely even incomplete) but=
> > then the NETMOD WG is not about protocol work but about the data<= br> > > modeling language YANG and data models. In fact, my reading of th= e
> > I-D is that you do not request to change anything in YANG at all = -
> > all you propose is to define a few extensions and a data model. >
> The 'on-demand' Mount does not need any protocol work.=A0 It i= s the easiest, and is looking to standardize needed several syntax extensio= ns.=A0 This type of Mount is what is implemented in OpenDaylight today.
>

I am not sure. Can I run all NETCONF protocol operations transparently acro= ss these mount points? I doubt it.

What you introduce is a "partitioning" of a datastore that does n= ot architecturally exist so far. Does this lead to a new type of datastore = or can I partition any datastore? How does this partitioning interact with = ephemeral datastores discussed in I2RS? I believe there are serious _architectural_ questions that need to be discus= sed and depending on how they are resolved, there may be more or less proto= col work needed.

What triggered this discussions were statements of the form "YANG does= not allow to do X" which I think is not correct since YANG really is = not the issue. The mount work is extending/modifying/$(your-verb-here)
the _architecture_ of NETCONF and YANG. It is not clear which WG is respons= ible for the underlying architecture. RFC 6244 was produced by NETMOD but t= hen it describes more the framework and not the underlying architectural mo= del (what Randy Presuhn I think calls the meta model). Perhaps we need to work on an architecture at some = point in time, pretty much like we needed to define an architecture for SNM= P at some point in time. The work on JSON encoding and the mount proposal c= learly indicates that certain architectural assumptions are implicit and that leads to discussions that are difficult = to close until we agree on an architecture.

Who said history does not repeat?

/js

--
Juergen Schoenwaelder=A0 =A0 =A0 =A0 =A0 =A0Jacobs University Bremen gGmbH<= br> Phone: +49 421 200 3587=A0 =A0 =A0 =A0 =A0Campus Ring 1, 28759 Bremen, Germ= any
Fax:=A0 =A0+49 421 200 3103=A0 =A0 =A0 =A0 =A0<http://www.jacobs-university.de/&= gt;

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


--001a11c302c063b3e805058be2a5-- From nobody Fri Oct 17 01:02:53 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA841A9108 for ; Fri, 17 Oct 2014 01:02: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 3xjb0TrLk_CG for ; Fri, 17 Oct 2014 01:02:50 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEF3C1A9106 for ; Fri, 17 Oct 2014 01:02:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2700; q=dns/txt; s=iport; t=1413532970; x=1414742570; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Ddp/55jkTN3FbicfWdBk7HR3po3BbGnAJjp+U8G/Al4=; b=BRcUwTIvfrx/QxPZVG5+0gX+7t5y2FlabTh5MwClT9uBIjQU3c8lM41o L11M5Ql6F65k4mliSiYYlUigtJADvmQe9timLM3wblStKo6ot1/sDEsv8 B62cfLZnDIhwrruV+DL+GCv9ECJ7mqTcChpCA5qJ4qzEVxbf/kdwJV8gO o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAJzLQFStJV2P/2dsb2JhbABbgmsjU1gEzCUKhnpUAoEQFgF9hAMBAQQBAQE3NBsCAQg2ECcLJQIEARIbiCQBDMsNAQEBAQEBAQMBAQEBAQEcjgOCFzqESwWSAIRGhxOWHIN3bAEBAYFFgQMBAQE X-IronPort-AV: E=Sophos;i="5.04,737,1406592000"; d="scan'208";a="364003234" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-7.cisco.com with ESMTP; 17 Oct 2014 08:02:50 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s9H82npn001405 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Oct 2014 08:02:49 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Fri, 17 Oct 2014 03:02:49 -0500 From: "William Lupton (wilupton)" To: Ladislav Lhotka , "netmod@ietf.org" Thread-Topic: [netmod] Mandatory and optional ranges Thread-Index: AQHP3ih3IT74Ah1ZGECTWzsVHNUgK5wzLcaAgAE784A= Date: Fri, 17 Oct 2014 08:02:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [10.55.121.115] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/4jGA5QLlf3BhATCMsTOgbklvN9c Subject: Re: [netmod] Mandatory and optional ranges X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 17 Oct 2014 08:02:52 -0000 Thanks. Would there be any appetite for permitting the feature approach (it would need to be understood that multiple "range" statements are ORd)? leaf WWW { type uint8 { range "1..1" { if-feature A; } range "2..2" { if-feature B; } } } leaf XXX { type uint8 { range "1..10" { if-feature A; } range "11..20" { if-feature B; } } } Compare the above with http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-11, which also mentions "choice" as an option, and includes this example: type enumeration { enum tcp; enum ssh { if-feature ssh; } enum tls { if-feature tls; } } Cheers, William On 16/10/2014 15:11, "Ladislav Lhotka" wrote: >Hello William, > >"William Lupton (wilupton)" writes: > >> All, >> >> Someone asked me whether a YANG definition can distinguish the parts of >>a >> range that are mandatory and the parts that are optional, e.g an int >>leaf >> XXX might be required to support 1..10 but 11..20 might be optional. It >> seems that being able to associate 11..20 with a feature would be a nice >> solution and would be equivalent to YANG 1.1 Y11 (allow if-feature on >> enums)? But I don't think that range "1..10|11..20" can be split into >> multiple range statements, so this would not be trivial? >> >> A use case from the DSL world (I can't be too specific) is where the >>valid >> values for two leaf nodes are coupled. If leaf WWW =3D 1 then XXX =3D 1= ..10 >> but if leaf WWW =3D 2 then XXX =3D 11..20. A future module version migh= t >>add >> WWW =3D 3 and tie it to XXX =3D 21..30. >> >> I suppose that a "must" statement could be used (?) but I quite like the >> feature approach, especially given the analogy with YANG 1.1 Y11. > >This could be solved by defining a choice with one case for each >variant. A must or when statement can then indeed be used for making >sure that each case only applies when WWW has the corresponding value. > >Something like > >choice XXX { > leaf XXX1 { > must "../WWW =3D 1"; > type uint8 { > range "1..10"; > } > } > leaf XXX2 { > must "../WWW =3D 2"; > type uint8 { > range "11..20"; > } > } >} > >Also, you can make a case conditional by using if-feature. > >Hope this helps, > >Lada >=20 > >> >> Comments? >> >> Thanks, >> William Lupton >> >> _______________________________________________ >> 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 Oct 17 05:21:42 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92BEE1ACD27 for ; Fri, 17 Oct 2014 05:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 4Eibb_cyqR5v for ; Fri, 17 Oct 2014 05:21:36 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 147F11ACD29 for ; Fri, 17 Oct 2014 05:21:35 -0700 (PDT) Received: from [192.168.1.123] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 15D0928C6DB9; Fri, 17 Oct 2014 08:21:35 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_4C481B5A-E773-4E11-A27F-ACCD77B8893A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: Date: Fri, 17 Oct 2014 08:21:23 -0400 Message-Id: References: To: "William Lupton (wilupton)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/xDvPooZPyTKRC41ttLkrDti-p0c Cc: "netmod@ietf.org" Subject: Re: [netmod] Mandatory and optional ranges X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 17 Oct 2014 12:21:38 -0000 --Apple-Mail=_4C481B5A-E773-4E11-A27F-ACCD77B8893A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Yes, but perhaps taking this a little further would help too but = I am not sure if that is a Yang 1.1 or 2.0 thing. Let me explain. We = were just discussing a similar requirement for a provisioning use case = over in ODL. What you propose would definitely help, but would not = necessarily be the comoplete solution. The use case is simple: an = operational domain that wishes to constrain an operational store to = values that make sense in that operational domain. So using your = example, the second range statement would actually be useful in that = domain. Its not exactly an "if-feature" though; its an = "if-in-this-domain" or something. Also, these values need to be a = combination of run-time variables much like ultimately would be = considered a "policy statement". So today, in our object classes for we = have two stages of commit checks on an object: the first enforces what = is found in the Yang module's type/range statements, but the second is = essentially a manual augmentation to that which can further narrow the = statement, or as I said above, validate it against other operation = state. For example, if we had a definition for a VpnRoute leaf (forget = about the details for a moment), but you wanted to say, "in addition to = the syntactic constraints, only allow CurrentVpnRouteCount <=3D = MaxVpnRoutesAllowedOnThisRouter to be created." So using what you suggest below, but being able to augment that = at run-time would be ideal and making the statement more robust somehow. --Tom > Thanks. Would there be any appetite for permitting the feature = approach > (it would need to be understood that multiple "range" statements are = ORd)? >=20 > leaf WWW { > type uint8 { > range "1..1" { > if-feature A; > } > range "2..2" { > if-feature B; > } > } > } >=20 > leaf XXX { > type uint8 { > range "1..10" { > if-feature A; > } > range "11..20" { > if-feature B; > } > } > } >=20 > Compare the above with > http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-11, = which > also mentions "choice" as an option, and includes this example: >=20 > type enumeration { > enum tcp; > enum ssh { > if-feature ssh; > } > enum tls { > if-feature tls; > } > } >=20 >=20 > Cheers, > William >=20 > On 16/10/2014 15:11, "Ladislav Lhotka" wrote: >=20 >> Hello William, >>=20 >> "William Lupton (wilupton)" writes: >>=20 >>> All, >>>=20 >>> Someone asked me whether a YANG definition can distinguish the parts = of >>> a >>> range that are mandatory and the parts that are optional, e.g an int >>> leaf >>> XXX might be required to support 1..10 but 11..20 might be optional. = It >>> seems that being able to associate 11..20 with a feature would be a = nice >>> solution and would be equivalent to YANG 1.1 Y11 (allow if-feature = on >>> enums)? But I don't think that range "1..10|11..20" can be split = into >>> multiple range statements, so this would not be trivial? >>>=20 >>> A use case from the DSL world (I can't be too specific) is where the >>> valid >>> values for two leaf nodes are coupled. If leaf WWW =3D 1 then XXX =3D= 1..10 >>> but if leaf WWW =3D 2 then XXX =3D 11..20. A future module version = might >>> add >>> WWW =3D 3 and tie it to XXX =3D 21..30. >>>=20 >>> I suppose that a "must" statement could be used (?) but I quite like = the >>> feature approach, especially given the analogy with YANG 1.1 Y11. >>=20 >> This could be solved by defining a choice with one case for each >> variant. A must or when statement can then indeed be used for making >> sure that each case only applies when WWW has the corresponding = value. >>=20 >> Something like >>=20 >> choice XXX { >> leaf XXX1 { >> must "../WWW =3D 1"; >> type uint8 { >> range "1..10"; >> } >> } >> leaf XXX2 { >> must "../WWW =3D 2"; >> type uint8 { >> range "11..20"; >> } >> } >> } >>=20 >> Also, you can make a case conditional by using if-feature. >>=20 >> Hope this helps, >>=20 >> Lada >>=20 >>=20 >>>=20 >>> Comments? >>>=20 >>> Thanks, >>> William Lupton >>>=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 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 --Apple-Mail=_4C481B5A-E773-4E11-A27F-ACCD77B8893A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUQQnDAAoJEPcO+I7eiUJZgxoP/05qf5Fouwfh7v3k6J1I0350 j1q1n27OSM56A9lWwJMM/WjJLQZ8YulpPWT62so1AcPfo3ULmSzSv98r+Z7QvwMR vU8BvkgwyQDMWIMA9r7XLSsgHs6e+igOrqZY0ESluVaD3MH9r5w4kvQhWKFYmZL+ 9rlZAv6oMJR+YhBGHoLMD4s5vEeQpTkFA88y3qvpPdoWKckpUTZAKQjA9K0vIKcV lawMvZBni9PG/akgv3MsxxsFbuqcgnqcaunp6xBkmvBlookhJdM44UPyTx9R5JZ2 YVNvfQ29fBuyTmvKn9E2VFN9Mkccj7SxLQAf4eufAqbz4WPwsw+8bYaDDvnQ1a1c uSUkcce04xDIARketzmhAtt0UfWSq3SvEXari2Skg+nd9bUdA/NlbNfpP46dSqTR ruScVdVIeM1F6R1WtNrs+V5Voaurt3ROXwDLcK1jpeKeS0f31bb88F+/v7PKZOge 5ojhszHv1dHVstXFs9o6vNtm0KNfK0YeVNrTrbrsz9kTVupyI4UmlX7SUj04xHBw T2TV/Nj9gcPIpxIsGRRkArTIGbu2cwULGMarxNPUsPhlj3VDm5tqQlyuwwP/pail drMnqP15vPotwsSz1Q61aluVrl9WuE36qrGM8wUGESHVGZjUYByQ4aOWHmuxrDEy WIIuC+lM+kQakryIlP+l =Jq+k -----END PGP SIGNATURE----- --Apple-Mail=_4C481B5A-E773-4E11-A27F-ACCD77B8893A-- From nobody Fri Oct 17 08:49:26 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC441A1B91 for ; Fri, 17 Oct 2014 08:49:25 -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 3kiYKaaqnvqI for ; Fri, 17 Oct 2014 08:49:23 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D4071A1B87 for ; Fri, 17 Oct 2014 08:49:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5140; q=dns/txt; s=iport; t=1413560959; x=1414770559; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=af4lYh9JRM51P33k8dyOk1b4GG/Dp2go+NX7msxHEgo=; b=aHk/WdPdBT2HvJXRWee0NeJIKIQR8BV72yzv56Y7FUF0V8o4LJKa5DXU pFXluB4poomcy3x8Zd455X6OFKWFOwpZUpk8U9ifp36KK2Xdv2yAQeV9n NJNIVJg8Pga/2pIWh6Jed6shtVqF8qAC+h2MKrvy8g4Zrt7DaCUVhRZSi 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAAU6QVStJV2T/2dsb2JhbABSCYJrI1NYBMw0CoZ6VAKBERYBfYQCAQEBAwEBAQE3NAYFBQsCAQgYHhAnCyUCBA4FG4gcCAEMzQoBAQEBAQEBAQEBAQEBAQEBAQEBGY4DgW8oMweESwWSAIRGhxOBMJBxhASDd2wBAQGBBSQcgQMBAQE X-IronPort-AV: E=Sophos;i="5.04,740,1406592000"; d="scan'208";a="364156155" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-6.cisco.com with ESMTP; 17 Oct 2014 15:49:18 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s9HFnIQn032505 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Oct 2014 15:49:18 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Fri, 17 Oct 2014 10:49:18 -0500 From: "William Lupton (wilupton)" To: "Thomas D. Nadeau" Thread-Topic: [netmod] Mandatory and optional ranges Thread-Index: AQHP3ih3IT74Ah1ZGECTWzsVHNUgK5wzLcaAgAE784CAADeCgIAAStKA Date: Fri, 17 Oct 2014 15:49:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [10.55.121.115] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/5erkiqzCxYOwI3K4ZVVA9MZUOOA Cc: "netmod@ietf.org" Subject: Re: [netmod] Mandatory and optional ranges X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 17 Oct 2014 15:49:25 -0000 Thanks. When you say "run-time", does that refer to a "must" statement, or to something different and yet to be defined? Presumably such run-time checks would be relevant in general and not just in this case? So for example they would also be relevant to the YANG 1.1 issue #11 bits / enum / identity case? W. On 17/10/2014 13:21, "Thomas D. Nadeau" wrote: > Yes, but perhaps taking this a little further would help too but I am >not sure if that is a Yang 1.1 or 2.0 thing. Let me explain. We were just >discussing a similar requirement for a provisioning use case over in ODL. >What you propose would definitely help, but would not necessarily be the >comoplete solution. The use case is simple: an operational domain that >wishes to constrain an operational store to values that make sense in >that operational domain. So using your example, the second range >statement would actually be useful in that domain. Its not exactly an >"if-feature" though; its an "if-in-this-domain" or something. Also, >these values need to be a combination of run-time variables much like >ultimately would be considered a "policy statement". So today, in our >object classes for we have two stages of commit checks on an object: the >first enforces what is found in the Yang module's type/range statements, >but the second is essentially a manual augmentation to that which can >further narrow the statement, or as I said above, validate it against >other operation state. For example, if we had a definition for a VpnRoute >leaf (forget about the details for a moment), but you wanted to say, "in >addition to the syntactic constraints, only allow CurrentVpnRouteCount <= =3D >MaxVpnRoutesAllowedOnThisRouter to be created." > > So using what you suggest below, but being able to augment that at >run-time would be ideal and making the statement more robust somehow. > > --Tom > >> Thanks. Would there be any appetite for permitting the feature approach >> (it would need to be understood that multiple "range" statements are >>ORd)? >>=20 >> leaf WWW { >> type uint8 { >> range "1..1" { >> if-feature A; >> } >> range "2..2" { >> if-feature B; >> } >> } >> } >>=20 >> leaf XXX { >> type uint8 { >> range "1..10" { >> if-feature A; >> } >> range "11..20" { >> if-feature B; >> } >> } >> } >>=20 >> Compare the above with >> http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-11, >>which >> also mentions "choice" as an option, and includes this example: >>=20 >> type enumeration { >> enum tcp; >> enum ssh { >> if-feature ssh; >> } >> enum tls { >> if-feature tls; >> } >> } >>=20 >>=20 >> Cheers, >> William >>=20 >> On 16/10/2014 15:11, "Ladislav Lhotka" wrote: >>=20 >>> Hello William, >>>=20 >>> "William Lupton (wilupton)" writes: >>>=20 >>>> All, >>>>=20 >>>> Someone asked me whether a YANG definition can distinguish the parts >>>>of >>>> a >>>> range that are mandatory and the parts that are optional, e.g an int >>>> leaf >>>> XXX might be required to support 1..10 but 11..20 might be optional. >>>>It >>>> seems that being able to associate 11..20 with a feature would be a >>>>nice >>>> solution and would be equivalent to YANG 1.1 Y11 (allow if-feature on >>>> enums)? But I don't think that range "1..10|11..20" can be split into >>>> multiple range statements, so this would not be trivial? >>>>=20 >>>> A use case from the DSL world (I can't be too specific) is where the >>>> valid >>>> values for two leaf nodes are coupled. If leaf WWW =3D 1 then XXX =3D >>>>1..10 >>>> but if leaf WWW =3D 2 then XXX =3D 11..20. A future module version mi= ght >>>> add >>>> WWW =3D 3 and tie it to XXX =3D 21..30. >>>>=20 >>>> I suppose that a "must" statement could be used (?) but I quite like >>>>the >>>> feature approach, especially given the analogy with YANG 1.1 Y11. >>>=20 >>> This could be solved by defining a choice with one case for each >>> variant. A must or when statement can then indeed be used for making >>> sure that each case only applies when WWW has the corresponding value. >>>=20 >>> Something like >>>=20 >>> choice XXX { >>> leaf XXX1 { >>> must "../WWW =3D 1"; >>> type uint8 { >>> range "1..10"; >>> } >>> } >>> leaf XXX2 { >>> must "../WWW =3D 2"; >>> type uint8 { >>> range "11..20"; >>> } >>> } >>> } >>>=20 >>> Also, you can make a case conditional by using if-feature. >>>=20 >>> Hope this helps, >>>=20 >>> Lada >>>=20 >>>=20 >>>>=20 >>>> Comments? >>>>=20 >>>> Thanks, >>>> William Lupton >>>>=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 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >>=20 > From nobody Fri Oct 17 09:15:31 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38E5C1A1BA9 for ; Fri, 17 Oct 2014 09:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 9GUBal61jEFz for ; Fri, 17 Oct 2014 09:15:26 -0700 (PDT) Received: from mail-qg0-f41.google.com (mail-qg0-f41.google.com [209.85.192.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1FBF1A1B94 for ; Fri, 17 Oct 2014 09:15:21 -0700 (PDT) Received: by mail-qg0-f41.google.com with SMTP id a108so779199qge.14 for ; Fri, 17 Oct 2014 09:15: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=MYckRmbK/n3cLBI+wR2Vf/JuSAdT584BP8k1OSHrK8M=; b=GIRimsL6I8KFwQTD00WoMHp7knEkWaNNl6IbvGhsQv+uvPAA1PRoVUPU1nRFTfcOEb aJkt1JbG/guHoSzNH4KQvy/vW/HWTc4pSdsPLN7EmRGmSXEpWFqn8deJO9s86yeTtVQn zbzJUgkkYm4HuCOaUY2kQMPlFcKUNAKcGTp0HNIu/u6PWYohqorJTYWh9SGy/LzUS61d qn6ANvYPz3spLyAi7v3YLhmvwxQ0UEgaOrRQmSHURHl8LpdWNhHR/0HQwFT8HaBad0Ph oXn8ugvnRp7fqxQEET5QdmW6VpyQIZduZXM0smj2rS8BNknzfIKdSTU6fguUWGNd7haj oEHA== X-Gm-Message-State: ALoCoQlybVPjj6JULWMAibKoU1QcHdAYgG4knEPMef5OJXke/WxyTmSf43V3YuGn3jjjLBPTsfUh MIME-Version: 1.0 X-Received: by 10.224.64.71 with SMTP id d7mr13364923qai.16.1413562520819; Fri, 17 Oct 2014 09:15:20 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Fri, 17 Oct 2014 09:15:20 -0700 (PDT) In-Reply-To: References: Date: Fri, 17 Oct 2014 09:15:20 -0700 Message-ID: From: Andy Bierman To: "Thomas D. Nadeau" Content-Type: multipart/alternative; boundary=001a11c21caaebf6330505a0ab53 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Rg835mYpKOKPueagLLvHj1yy6wM Cc: "netmod@ietf.org" Subject: Re: [netmod] Mandatory and optional ranges X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 17 Oct 2014 16:15:30 -0000 --001a11c21caaebf6330505a0ab53 Content-Type: text/plain; charset=ISO-8859-1 Hi, I am concerned about overloading the YANG feature-stmt. Not only are the conformance mechanisms weak, but they are passed in the module advertisement. Not every type of classification should be a global YANG feature or advertised in the message. IMO static YANG schema definitions cannot express all run-time decisions that determine what values are valid for a given leaf at the moment. YANG 1.1 will allow complex if-feature statements, and allow if-feature in more places. This may help automation if used correctly. It might be easy to make mistakes with complex existence conditions on values. Another solution approach is described in the new YANG Conformance draft. Just ask the server what it supports for certain leafs. http://www.ietf.org/id/draft-bierman-netmod-yang-conformance-04.txt The and operations return the supported values for a given leaf instance. Consider a large open-ended identityref like interface-type. If would be quite difficult to markup all the identities with YANG if-feature-stmts (or if-whatever-stmts) so a client knows what a server will accept for a given "create" edit operation. Andy On Fri, Oct 17, 2014 at 5:21 AM, Thomas D. Nadeau wrote: > > Yes, but perhaps taking this a little further would help too but I > am not sure if that is a Yang 1.1 or 2.0 thing. Let me explain. We were > just discussing a similar requirement for a provisioning use case over in > ODL. What you propose would definitely help, but would not necessarily be > the comoplete solution. The use case is simple: an operational domain that > wishes to constrain an operational store to values that make sense in that > operational domain. So using your example, the second range statement would > actually be useful in that domain. Its not exactly an "if-feature" though; > its an "if-in-this-domain" or something. Also, these values need to be a > combination of run-time variables much like ultimately would be considered > a "policy statement". So today, in our object classes for we have two > stages of commit checks on an object: the first enforces what is found in > the Yang module's type/range statements, but the second is essentially a > manual augmentation to that which can further narrow the statement, or as I > said above, validate it against other operation state. For example, if we > had a definition for a VpnRoute leaf (forget about the details for a > moment), but you wanted to say, "in addition to the syntactic constraints, > only allow CurrentVpnRouteCount <= MaxVpnRoutesAllowedOnThisRouter to be > created." > > So using what you suggest below, but being able to augment that at > run-time would be ideal and making the statement more robust somehow. > > --Tom > > > > Thanks. Would there be any appetite for permitting the feature approach > > (it would need to be understood that multiple "range" statements are > ORd)? > > > > leaf WWW { > > type uint8 { > > range "1..1" { > > if-feature A; > > } > > range "2..2" { > > if-feature B; > > } > > } > > } > > > > leaf XXX { > > type uint8 { > > range "1..10" { > > if-feature A; > > } > > range "11..20" { > > if-feature B; > > } > > } > > } > > > > Compare the above with > > http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-11, > which > > also mentions "choice" as an option, and includes this example: > > > > type enumeration { > > enum tcp; > > enum ssh { > > if-feature ssh; > > } > > enum tls { > > if-feature tls; > > } > > } > > > > > > Cheers, > > William > > > > On 16/10/2014 15:11, "Ladislav Lhotka" wrote: > > > >> Hello William, > >> > >> "William Lupton (wilupton)" writes: > >> > >>> All, > >>> > >>> Someone asked me whether a YANG definition can distinguish the parts of > >>> a > >>> range that are mandatory and the parts that are optional, e.g an int > >>> leaf > >>> XXX might be required to support 1..10 but 11..20 might be optional. > It > >>> seems that being able to associate 11..20 with a feature would be a > nice > >>> solution and would be equivalent to YANG 1.1 Y11 (allow if-feature on > >>> enums)? But I don't think that range "1..10|11..20" can be split into > >>> multiple range statements, so this would not be trivial? > >>> > >>> A use case from the DSL world (I can't be too specific) is where the > >>> valid > >>> values for two leaf nodes are coupled. If leaf WWW = 1 then XXX = > 1..10 > >>> but if leaf WWW = 2 then XXX = 11..20. A future module version might > >>> add > >>> WWW = 3 and tie it to XXX = 21..30. > >>> > >>> I suppose that a "must" statement could be used (?) but I quite like > the > >>> feature approach, especially given the analogy with YANG 1.1 Y11. > >> > >> This could be solved by defining a choice with one case for each > >> variant. A must or when statement can then indeed be used for making > >> sure that each case only applies when WWW has the corresponding value. > >> > >> Something like > >> > >> choice XXX { > >> leaf XXX1 { > >> must "../WWW = 1"; > >> type uint8 { > >> range "1..10"; > >> } > >> } > >> leaf XXX2 { > >> must "../WWW = 2"; > >> type uint8 { > >> range "11..20"; > >> } > >> } > >> } > >> > >> Also, you can make a case conditional by using if-feature. > >> > >> Hope this helps, > >> > >> Lada > >> > >> > >>> > >>> Comments? > >>> > >>> Thanks, > >>> William Lupton > >>> > >>> _______________________________________________ > >>> 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 > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --001a11c21caaebf6330505a0ab53 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I am concerned about overloading th= e YANG feature-stmt.
Not only are the conformance mechanisms weak= , but they are
passed in the module advertisement.=A0 Not every t= ype of classification
should be a global YANG feature or advertis= ed in the <hello> message.

IMO static YANG s= chema definitions cannot express all run-time decisions
that dete= rmine what values are valid for a given leaf at the moment.
YANG = 1.1 will allow complex if-feature statements, and allow if-feature
in more places.=A0 This may help automation if used correctly.=A0 It migh= t
be easy to make mistakes with complex existence conditions on v= alues.

Another solution approach is described in t= he new YANG Conformance draft.
Just ask the server what it suppor= ts for certain leafs.


The <get-allowed-identities> and <get-allowed-leafrefs> oper= ations return the
supported values for a given leaf instance. Con= sider a large open-ended identityref
like interface-type.=A0 If w= ould be quite difficult to markup all the identities with
YANG if= -feature-stmts (or if-whatever-stmts) so a client knows what a server will<= /div>
accept for a given "create" edit operation.
<= br>


Andy

<= pre style=3D"color:rgb(0,0,0);word-wrap:break-word;white-space:pre-wrap">


On Fri, Oct 17, 2014 at 5:21 AM, Thomas D. Nadeau &= lt;tnadeau@luc= idvision.com> wrote:

=A0 =A0 =A0 =A0 Yes, but perhaps taking this a little further would help to= o but I am not sure if that is a Yang 1.1 or 2.0 thing. Let me explain. We = were just discussing a similar requirement for a provisioning use case over= in ODL. What you propose would definitely help, but would not necessarily = be the comoplete solution. The use case is simple: an operational domain th= at wishes to constrain an operational store to values that make sense in th= at operational domain. So using your example, the second range statement wo= uld actually be useful in that domain. Its not exactly an "if-feature&= quot; though; its an "if-in-this-domain" or something.=A0 =A0Also= , these values need to be a combination of run-time variables much like ult= imately would be considered a "policy statement". So today, in ou= r object classes for we have two stages of commit checks on an object: the = first enforces what is found in the Yang module's type/range statements= , but the second is essentially a manual augmentation to that which can fur= ther narrow the statement, or as I said above, validate it against other op= eration state. For example, if we had a definition for a VpnRoute leaf (for= get about the details for a moment), but you wanted to say, "in additi= on to the syntactic constraints, only allow CurrentVpnRouteCount <=3D Ma= xVpnRoutesAllowedOnThisRouter to be created."

=A0 =A0 =A0 =A0 So using what you suggest below, but being able to augment = that at run-time would be ideal and making the statement more robust someho= w.

=A0 =A0 =A0 =A0 --Tom


> Thanks.=A0 Would there be any appetite for permitting the feature appr= oach
> (it would need to be understood that multiple "range" statem= ents are ORd)?
>
> leaf WWW {
>=A0 type uint8 {
>=A0 =A0 range "1..1" {
>=A0 =A0 =A0 if-feature A;
>=A0 =A0 }
>=A0 =A0 range "2..2" {
>=A0 =A0 =A0 if-feature B;
>=A0 =A0 }
>=A0 }
> }
>
> leaf XXX {
>=A0 type uint8 {
>=A0 =A0 range "1..10" {
>=A0 =A0 =A0 if-feature A;
>=A0 =A0 }
>=A0 =A0 range "11..20" {
>=A0 =A0 =A0 if-feature B;
>=A0 =A0 }
>=A0 }
> }
>
> Compare the above with
> http://svn.tools.ietf.org/svn/wg/netmod/yang-1.= 1/issues.html#sec-11, which
> also mentions "choice" as an option, and includes this examp= le:
>
> type enumeration {
>=A0 enum tcp;
>=A0 enum ssh {
>=A0 =A0 if-feature ssh;
>=A0 }
>=A0 enum tls {
>=A0 =A0 if-feature tls;
>=A0 }
> }
>
>
> Cheers,
> William
>
> On 16/10/2014 15:11, "Ladislav Lhotka" <lhotka@nic.cz> wrote:
>
>> Hello William,
>>
>> "William Lupton (wilupton)" <wilupton@cisco.com> writes:
>>
>>> All,
>>>
>>> Someone asked me whether a YANG definition can distinguish the= parts of
>>> a
>>> range that are mandatory and the parts that are optional, e.g = an int
>>> leaf
>>> XXX might be required to support 1..10 but 11..20 might be opt= ional.=A0 It
>>> seems that being able to associate 11..20 with a feature would= be a nice
>>> solution and would be equivalent to YANG 1.1 Y11 (allow if-fea= ture on
>>> enums)?=A0 But I don't think that range "1..10|11..20= " can be split into
>>> multiple range statements, so this would not be trivial?
>>>
>>> A use case from the DSL world (I can't be too specific) is= where the
>>> valid
>>> values for two leaf nodes are coupled.=A0 If leaf WWW =3D 1 th= en XXX =3D 1..10
>>> but if leaf WWW =3D 2 then XXX =3D 11..20.=A0 A future module = version might
>>> add
>>> WWW =3D 3 and tie it to XXX =3D 21..30.
>>>
>>> I suppose that a "must" statement could be used (?) = but I quite like the
>>> feature approach, especially given the analogy with YANG 1.1 Y= 11.
>>
>> This could be solved by defining a choice with one case for each >> variant. A must or when statement can then indeed be used for maki= ng
>> sure that each case only applies when WWW has the corresponding va= lue.
>>
>> Something like
>>
>> choice XXX {
>> leaf XXX1 {
>>=A0 =A0must "../WWW =3D 1";
>>=A0 =A0type uint8 {
>>=A0 =A0 =A0 =A0range "1..10";
>>=A0 =A0}
>> }
>> leaf XXX2 {
>>=A0 =A0must "../WWW =3D 2";
>>=A0 =A0type uint8 {
>>=A0 =A0 =A0 =A0range "11..20";
>>=A0 =A0}
>> }
>> }
>>
>> Also, you can make a case conditional by using if-feature.
>>
>> Hope this helps,
>>
>> Lada
>>
>>
>>>
>>> Comments?
>>>
>>> Thanks,
>>> William Lupton
>>>
>>> _______________________________________________
>>> 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
>


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


--001a11c21caaebf6330505a0ab53-- From nobody Fri Oct 17 09:58:09 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4901A1B68 for ; Fri, 17 Oct 2014 09:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, 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 k8yXdM8lkpey for ; Fri, 17 Oct 2014 09:58:03 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94AA81A026E for ; Fri, 17 Oct 2014 09:58:03 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 1A1C2742; Fri, 17 Oct 2014 18:58: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 EHWK9uEspFk2; Fri, 17 Oct 2014 18:57:59 +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, 17 Oct 2014 18:58:00 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8FF1F20037; Fri, 17 Oct 2014 18:58: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 Q3IpjWQygjlr; Fri, 17 Oct 2014 18:57:49 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9C4FE20035; Fri, 17 Oct 2014 18:57:58 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A90792EFFBC9; Fri, 17 Oct 2014 18:57:57 +0200 (CEST) Date: Fri, 17 Oct 2014 18:57:57 +0200 From: Juergen Schoenwaelder To: "Thomas D. Nadeau" Message-ID: <20141017165757.GA81769@elstar.local> Mail-Followup-To: "Thomas D. Nadeau" , "William Lupton (wilupton)" , "netmod@ietf.org" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/qMkzg50O-2DCqGmw-iRZVhzip2U Cc: "netmod@ietf.org" Subject: Re: [netmod] Mandatory and optional ranges 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, 17 Oct 2014 16:58:06 -0000 Hi, I am confused since you talk about 'operation state' and 'operational store'. If we are talking about operational state, then what does validate mean? The operational state should document the real state of the device and there is no concept of rejecting or validating it - if the state is there, it is real operational state. You can reject a config change if the change leads to invalid config. I am not sure how to reject an operational state. Perhaps you are thinking about identifying undesirable operational states. But for me, this would not be the same thing as validation of config. And what is desirable or undesirable likely depends on deployment specifics and thus it is application and deployment domain specific and not generic. If the idea is, however, to express that the number of configured vpnRoutes (e.g. list entries) is smaller than some leaf value (say maxVpnRoutes) for a config to be valid, I think this is expressable using must constraints. /js On Fri, Oct 17, 2014 at 08:21:23AM -0400, Thomas D. Nadeau wrote: >=20 > Yes, but perhaps taking this a little further would help too but I am no= t sure if that is a Yang 1.1 or 2.0 thing. Let me explain. We were just dis= cussing a similar requirement for a provisioning use case over in ODL. What= you propose would definitely help, but would not necessarily be the comopl= ete solution. The use case is simple: an operational domain that wishes to = constrain an operational store to values that make sense in that operationa= l domain. So using your example, the second range statement would actually = be useful in that domain. Its not exactly an "if-feature" though; its an "i= f-in-this-domain" or something. Also, these values need to be a combinati= on of run-time variables much like ultimately would be considered a "policy= statement". So today, in our object classes for we have two stages of comm= it checks on an object: the first enforces what is found in the Yang module= 's type/range statements, but the second is essentially a manual augmentati= on to that which can further narrow the statement, or as I said above, vali= date it against other operation state. For example, if we had a definition = for a VpnRoute leaf (forget about the details for a moment), but you wanted= to say, "in addition to the syntactic constraints, only allow CurrentVpnRo= uteCount <=3D MaxVpnRoutesAllowedOnThisRouter to be created." >=20 > So using what you suggest below, but being able to augment that at run-t= ime would be ideal and making the statement more robust somehow. >=20 > --Tom >=20 >=20 > > Thanks. Would there be any appetite for permitting the feature approach > > (it would need to be understood that multiple "range" statements are OR= d)? > >=20 > > leaf WWW { > > type uint8 { > > range "1..1" { > > if-feature A; > > } > > range "2..2" { > > if-feature B; > > } > > } > > } > >=20 > > leaf XXX { > > type uint8 { > > range "1..10" { > > if-feature A; > > } > > range "11..20" { > > if-feature B; > > } > > } > > } > >=20 > > Compare the above with > > http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-11, wh= ich > > also mentions "choice" as an option, and includes this example: > >=20 > > type enumeration { > > enum tcp; > > enum ssh { > > if-feature ssh; > > } > > enum tls { > > if-feature tls; > > } > > } > >=20 > >=20 > > Cheers, > > William > >=20 > > On 16/10/2014 15:11, "Ladislav Lhotka" wrote: > >=20 > >> Hello William, > >>=20 > >> "William Lupton (wilupton)" writes: > >>=20 > >>> All, > >>>=20 > >>> Someone asked me whether a YANG definition can distinguish the parts = of > >>> a > >>> range that are mandatory and the parts that are optional, e.g an int > >>> leaf > >>> XXX might be required to support 1..10 but 11..20 might be optional. = It > >>> seems that being able to associate 11..20 with a feature would be a n= ice > >>> solution and would be equivalent to YANG 1.1 Y11 (allow if-feature on > >>> enums)? But I don't think that range "1..10|11..20" can be split into > >>> multiple range statements, so this would not be trivial? > >>>=20 > >>> A use case from the DSL world (I can't be too specific) is where the > >>> valid > >>> values for two leaf nodes are coupled. If leaf WWW =3D 1 then XXX = =3D 1..10 > >>> but if leaf WWW =3D 2 then XXX =3D 11..20. A future module version m= ight > >>> add > >>> WWW =3D 3 and tie it to XXX =3D 21..30. > >>>=20 > >>> I suppose that a "must" statement could be used (?) but I quite like = the > >>> feature approach, especially given the analogy with YANG 1.1 Y11. > >>=20 > >> This could be solved by defining a choice with one case for each > >> variant. A must or when statement can then indeed be used for making > >> sure that each case only applies when WWW has the corresponding value. > >>=20 > >> Something like > >>=20 > >> choice XXX { > >> leaf XXX1 { > >> must "../WWW =3D 1"; > >> type uint8 { > >> range "1..10"; > >> } > >> } > >> leaf XXX2 { > >> must "../WWW =3D 2"; > >> type uint8 { > >> range "11..20"; > >> } > >> } > >> } > >>=20 > >> Also, you can make a case conditional by using if-feature. > >>=20 > >> Hope this helps, > >>=20 > >> Lada > >>=20 > >>=20 > >>>=20 > >>> Comments? > >>>=20 > >>> Thanks, > >>> William Lupton > >>>=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 > >=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 --=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 Fri Oct 17 10:31:44 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FFDC1A0039 for ; Fri, 17 Oct 2014 10:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 l2avltwHg75d for ; Fri, 17 Oct 2014 10:31:36 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 74A061A004B for ; Fri, 17 Oct 2014 10:31:36 -0700 (PDT) Received: from [192.168.1.123] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 01C4A28C7863; Fri, 17 Oct 2014 13:31:36 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_054EAC0E-791E-40AC-8A57-8ADD92B81445"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: Date: Fri, 17 Oct 2014 13:31:22 -0400 Message-Id: <65782E1D-556B-4972-AF96-6FB93B5773A5@lucidvision.com> References: To: "William Lupton (wilupton)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/8EKOvTuURBr6110CZTOo0n29rkI Cc: "netmod@ietf.org" Subject: Re: [netmod] Mandatory and optional ranges X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 17 Oct 2014 17:31:42 -0000 --Apple-Mail=_054EAC0E-791E-40AC-8A57-8ADD92B81445 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 17, 2014:11:49 AM, at 11:49 AM, William Lupton (wilupton) = wrote: > Thanks. When you say "run-time", does that refer to a "must" = statement, > or to something different and yet to be defined? =20 It refers to the running state, and is defined per-domain, so = its not something you can just define in a standard model because its = different per domain. The example I gave is illustrative of that. For = instance, one operator might care about MaxVRFs when configuring service = X, but then another might care about MaxVRFs + . > Presumably such run-time > checks would be relevant in general and not just in this case? =20 Right! That was my point. *) This is perhaps a general thing = for Yang 2.0 whereby a model's constraints are augmented at run-time. = Its unclear if this is an "implementation detail", a Yang 2.0 thing, or = some combination of both.=20 > So for example they would also be relevant to the YANG 1.1 issue #11 = bits / enum > / identity case? W. Yes. So my point was that *some* of what I am describing above = can be handled in Yang 1.1 issues, but perhaps others elsewhere. --Tom >=20 > On 17/10/2014 13:21, "Thomas D. Nadeau" = wrote: >=20 >> Yes, but perhaps taking this a little further would help too but = I am >> not sure if that is a Yang 1.1 or 2.0 thing. Let me explain. We were = just >> discussing a similar requirement for a provisioning use case over in = ODL. >> What you propose would definitely help, but would not necessarily be = the >> comoplete solution. The use case is simple: an operational domain = that >> wishes to constrain an operational store to values that make sense in >> that operational domain. So using your example, the second range >> statement would actually be useful in that domain. Its not exactly an >> "if-feature" though; its an "if-in-this-domain" or something. Also, >> these values need to be a combination of run-time variables much like >> ultimately would be considered a "policy statement". So today, in our >> object classes for we have two stages of commit checks on an object: = the >> first enforces what is found in the Yang module's type/range = statements, >> but the second is essentially a manual augmentation to that which can >> further narrow the statement, or as I said above, validate it against >> other operation state. For example, if we had a definition for a = VpnRoute >> leaf (forget about the details for a moment), but you wanted to say, = "in >> addition to the syntactic constraints, only allow = CurrentVpnRouteCount <=3D >> MaxVpnRoutesAllowedOnThisRouter to be created." >>=20 >> So using what you suggest below, but being able to augment that = at >> run-time would be ideal and making the statement more robust somehow. >>=20 >> --Tom >>=20 >>> Thanks. Would there be any appetite for permitting the feature = approach >>> (it would need to be understood that multiple "range" statements are >>> ORd)? >>>=20 >>> leaf WWW { >>> type uint8 { >>> range "1..1" { >>> if-feature A; >>> } >>> range "2..2" { >>> if-feature B; >>> } >>> } >>> } >>>=20 >>> leaf XXX { >>> type uint8 { >>> range "1..10" { >>> if-feature A; >>> } >>> range "11..20" { >>> if-feature B; >>> } >>> } >>> } >>>=20 >>> Compare the above with >>> http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-11, >>> which >>> also mentions "choice" as an option, and includes this example: >>>=20 >>> type enumeration { >>> enum tcp; >>> enum ssh { >>> if-feature ssh; >>> } >>> enum tls { >>> if-feature tls; >>> } >>> } >>>=20 >>>=20 >>> Cheers, >>> William >>>=20 >>> On 16/10/2014 15:11, "Ladislav Lhotka" wrote: >>>=20 >>>> Hello William, >>>>=20 >>>> "William Lupton (wilupton)" writes: >>>>=20 >>>>> All, >>>>>=20 >>>>> Someone asked me whether a YANG definition can distinguish the = parts >>>>> of >>>>> a >>>>> range that are mandatory and the parts that are optional, e.g an = int >>>>> leaf >>>>> XXX might be required to support 1..10 but 11..20 might be = optional. >>>>> It >>>>> seems that being able to associate 11..20 with a feature would be = a >>>>> nice >>>>> solution and would be equivalent to YANG 1.1 Y11 (allow if-feature = on >>>>> enums)? But I don't think that range "1..10|11..20" can be split = into >>>>> multiple range statements, so this would not be trivial? >>>>>=20 >>>>> A use case from the DSL world (I can't be too specific) is where = the >>>>> valid >>>>> values for two leaf nodes are coupled. If leaf WWW =3D 1 then XXX = =3D >>>>> 1..10 >>>>> but if leaf WWW =3D 2 then XXX =3D 11..20. A future module = version might >>>>> add >>>>> WWW =3D 3 and tie it to XXX =3D 21..30. >>>>>=20 >>>>> I suppose that a "must" statement could be used (?) but I quite = like >>>>> the >>>>> feature approach, especially given the analogy with YANG 1.1 Y11. >>>>=20 >>>> This could be solved by defining a choice with one case for each >>>> variant. A must or when statement can then indeed be used for = making >>>> sure that each case only applies when WWW has the corresponding = value. >>>>=20 >>>> Something like >>>>=20 >>>> choice XXX { >>>> leaf XXX1 { >>>> must "../WWW =3D 1"; >>>> type uint8 { >>>> range "1..10"; >>>> } >>>> } >>>> leaf XXX2 { >>>> must "../WWW =3D 2"; >>>> type uint8 { >>>> range "11..20"; >>>> } >>>> } >>>> } >>>>=20 >>>> Also, you can make a case conditional by using if-feature. >>>>=20 >>>> Hope this helps, >>>>=20 >>>> Lada >>>>=20 >>>>=20 >>>>>=20 >>>>> Comments? >>>>>=20 >>>>> Thanks, >>>>> William Lupton >>>>>=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 >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>>=20 >>=20 >=20 >=20 --Apple-Mail=_054EAC0E-791E-40AC-8A57-8ADD92B81445 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUQVJrAAoJEPcO+I7eiUJZA7sP/0SJ/X7p0gyu2Qm5hzfnkzBI wEe1unKgObptDHXe73P4VXBfgEz5a6+jlq1Y/UAYF7PfoIX//GZ3i5SH0RN09wab 2AQYZdd0dTdPlB+BTZY+T21PbWKN2lbSOmSe21CJ9UCcGWR3mXjY5TUYMT4agvsb z6hng3L6ZnXL7HdeeoWupUOYfbQBErNT6Vk2Ob6FFVOVqM3y1KSJlY5Jh1IeYRR7 4jgPf87Kx8Ulz04ZSP+RdWn025P03mVhfdHI2RKFcBjizwpRaoa7TB4666/cVg24 8WCQ+2pqmT8xYWB812JvCn77szuQHaA9dO7oNoYfrxZ8n79Jj6ahZpdpC4i3gB8J 1sfEM8GUFkTLckqs8VF1rzkZo2/64XSeyv5zNtCmX21vQ7Sqc1lQfyRKvV5jsoH6 kZGSTYy9EMHE+CGM3Tg4n7h3q3SW18/NFoYPu2ifkz0n4fRmN1+6DyumTz5He2aq 7uttC4gQ11dF5L5HDusvUHSLE/s0P8oo7GTjJc6n68laNCekRJWVU9h04LZJ8mhD hoM1rIkvtJXHjH/hqgkMKzdlMUYbwiJ1lig69PF3y1Dif12Pfqg2/wfVA/ThrBpF DNtlID7q/sthv3In6Cj8hBCXUxtzlbua97RieGyAwOP1a5eZGMt2TlEU2zPIi6vT E634dnj/Sa1DvteGDoUZ =UOz1 -----END PGP SIGNATURE----- --Apple-Mail=_054EAC0E-791E-40AC-8A57-8ADD92B81445-- From nobody Fri Oct 17 10:35:20 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 249531A0039 for ; Fri, 17 Oct 2014 10:35:10 -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, 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 lMh49tYK0JkQ for ; Fri, 17 Oct 2014 10:35:06 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id B583E1A00A3 for ; Fri, 17 Oct 2014 10:35:05 -0700 (PDT) Received: from [192.168.1.123] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 4D3A628C7890; Fri, 17 Oct 2014 13:35:05 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_363B56BF-5181-4929-9DA3-C00BD228B239"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: Date: Fri, 17 Oct 2014 13:34:52 -0400 Message-Id: <1B41E3A3-2C9A-4FC1-A2F5-C892C1B1C634@lucidvision.com> References: To: Andy Bierman X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/B39PATG09iqJKZQKNGUjkJZ9iSQ Cc: "netmod@ietf.org" Subject: Re: [netmod] Mandatory and optional ranges X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 17 Oct 2014 17:35:10 -0000 --Apple-Mail=_363B56BF-5181-4929-9DA3-C00BD228B239 Content-Type: multipart/alternative; boundary="Apple-Mail=_EF9A6965-6D99-425E-85BE-DD00CE33D784" --Apple-Mail=_EF9A6965-6D99-425E-85BE-DD00CE33D784 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Oct 17, 2014:12:15 PM, at 12:15 PM, Andy Bierman = wrote: > Hi, >=20 > I am concerned about overloading the YANG feature-stmt. > Not only are the conformance mechanisms weak, but they are > passed in the module advertisement. Not every type of classification > should be a global YANG feature or advertised in the message. >=20 > IMO static YANG schema definitions cannot express all run-time = decisions > that determine what values are valid for a given leaf at the moment. > YANG 1.1 will allow complex if-feature statements, and allow = if-feature > in more places. This may help automation if used correctly. It might > be easy to make mistakes with complex existence conditions on values. That is fair. My questions is whether or not we need to augment = Yang... for this? > Another solution approach is described in the new YANG Conformance = draft. > Just ask the server what it supports for certain leafs. >=20 > http://www.ietf.org/id/draft-bierman-netmod-yang-conformance-04.txt >=20 > The and operations = return the > supported values for a given leaf instance. Consider a large = open-ended identityref > like interface-type. If would be quite difficult to markup all the = identities with > YANG if-feature-stmts (or if-whatever-stmts) so a client knows what a = server will > accept for a given "create" edit operation. Ah I'd forgotten about that. Yes, this is perhaps a place to = tackle this. I agree too that we don't want to augment models with = if-feature... in a particular Yang module; but instead, have a method by = which an agent can be programmed dynamically with perhaps a supplemental = yang module. What I am talking about is perhaps writing the conformance = at run time and plugging it in. --Tom >=20 > Andy >=20 >=20 >=20 >=20 > On Fri, Oct 17, 2014 at 5:21 AM, Thomas D. Nadeau = wrote: >=20 > Yes, but perhaps taking this a little further would help too = but I am not sure if that is a Yang 1.1 or 2.0 thing. Let me explain. We = were just discussing a similar requirement for a provisioning use case = over in ODL. What you propose would definitely help, but would not = necessarily be the comoplete solution. The use case is simple: an = operational domain that wishes to constrain an operational store to = values that make sense in that operational domain. So using your = example, the second range statement would actually be useful in that = domain. Its not exactly an "if-feature" though; its an = "if-in-this-domain" or something. Also, these values need to be a = combination of run-time variables much like ultimately would be = considered a "policy statement". So today, in our object classes for we = have two stages of commit checks on an object: the first enforces what = is found in the Yang module's type/range statements, but the second is = essentially a manual augmentation to that which can further narrow the = statement, or as I said above, validate it against other operation = state. For example, if we had a definition for a VpnRoute leaf (forget = about the details for a moment), but you wanted to say, "in addition to = the syntactic constraints, only allow CurrentVpnRouteCount <=3D = MaxVpnRoutesAllowedOnThisRouter to be created." >=20 > So using what you suggest below, but being able to augment = that at run-time would be ideal and making the statement more robust = somehow. >=20 > --Tom >=20 >=20 > > Thanks. Would there be any appetite for permitting the feature = approach > > (it would need to be understood that multiple "range" statements are = ORd)? > > > > leaf WWW { > > type uint8 { > > range "1..1" { > > if-feature A; > > } > > range "2..2" { > > if-feature B; > > } > > } > > } > > > > leaf XXX { > > type uint8 { > > range "1..10" { > > if-feature A; > > } > > range "11..20" { > > if-feature B; > > } > > } > > } > > > > Compare the above with > > http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-11, = which > > also mentions "choice" as an option, and includes this example: > > > > type enumeration { > > enum tcp; > > enum ssh { > > if-feature ssh; > > } > > enum tls { > > if-feature tls; > > } > > } > > > > > > Cheers, > > William > > > > On 16/10/2014 15:11, "Ladislav Lhotka" wrote: > > > >> Hello William, > >> > >> "William Lupton (wilupton)" writes: > >> > >>> All, > >>> > >>> Someone asked me whether a YANG definition can distinguish the = parts of > >>> a > >>> range that are mandatory and the parts that are optional, e.g an = int > >>> leaf > >>> XXX might be required to support 1..10 but 11..20 might be = optional. It > >>> seems that being able to associate 11..20 with a feature would be = a nice > >>> solution and would be equivalent to YANG 1.1 Y11 (allow if-feature = on > >>> enums)? But I don't think that range "1..10|11..20" can be split = into > >>> multiple range statements, so this would not be trivial? > >>> > >>> A use case from the DSL world (I can't be too specific) is where = the > >>> valid > >>> values for two leaf nodes are coupled. If leaf WWW =3D 1 then XXX = =3D 1..10 > >>> but if leaf WWW =3D 2 then XXX =3D 11..20. A future module = version might > >>> add > >>> WWW =3D 3 and tie it to XXX =3D 21..30. > >>> > >>> I suppose that a "must" statement could be used (?) but I quite = like the > >>> feature approach, especially given the analogy with YANG 1.1 Y11. > >> > >> This could be solved by defining a choice with one case for each > >> variant. A must or when statement can then indeed be used for = making > >> sure that each case only applies when WWW has the corresponding = value. > >> > >> Something like > >> > >> choice XXX { > >> leaf XXX1 { > >> must "../WWW =3D 1"; > >> type uint8 { > >> range "1..10"; > >> } > >> } > >> leaf XXX2 { > >> must "../WWW =3D 2"; > >> type uint8 { > >> range "11..20"; > >> } > >> } > >> } > >> > >> Also, you can make a case conditional by using if-feature. > >> > >> Hope this helps, > >> > >> Lada > >> > >> > >>> > >>> Comments? > >>> > >>> Thanks, > >>> William Lupton > >>> > >>> _______________________________________________ > >>> 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 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 >=20 --Apple-Mail=_EF9A6965-6D99-425E-85BE-DD00CE33D784 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Oct 17, 2014:12:15 PM, at 12:15 PM, = Andy Bierman <andy@yumaworks.com> = wrote:

Hi,

I am concerned = about overloading the YANG feature-stmt.
Not only are the = conformance mechanisms weak, but they are
passed in the module = advertisement.  Not every type of classification
should = be a global YANG feature or advertised in the <hello> = message.

IMO static YANG schema definitions = cannot express all run-time decisions
that determine what = values are valid for a given leaf at the moment.
YANG 1.1 will = allow complex if-feature statements, and allow if-feature
in = more places.  This may help automation if used correctly.  It = might
be easy to make mistakes with complex existence = conditions on values.

That is = fair. My questions is whether or not we need to augment Yang... for = this?

Another = solution approach is described in the new YANG Conformance = draft.
Just ask the server what it supports for certain = leafs.


The <get-allowed-identities> and = <get-allowed-leafrefs> operations return the
supported = values for a given leaf instance. Consider a large open-ended = identityref
like interface-type.  If would be quite = difficult to markup all the identities with
YANG = if-feature-stmts (or if-whatever-stmts) so a client knows what a server = will
accept for a given "create" edit = operation.

Ah I'd = forgotten about that.  Yes, this is perhaps a place to tackle this. = I agree too that we don't want to augment models with if-feature... in a = particular Yang module; but instead, have a method by which an agent can = be programmed dynamically with perhaps a supplemental yang module. =  What I am talking about is perhaps writing the conformance at run = time and plugging it in.

= --Tom




Andy




On Fri, Oct 17, 2014 at 5:21 AM, Thomas D. Nadeau = <tnadeau@lucidvision.com> = wrote:

        Yes, but perhaps taking this a little = further would help too but I am not sure if that is a Yang 1.1 or 2.0 = thing. Let me explain. We were just discussing a similar requirement for = a provisioning use case over in ODL. What you propose would definitely = help, but would not necessarily be the comoplete solution. The use case = is simple: an operational domain that wishes to constrain an operational = store to values that make sense in that operational domain. So using = your example, the second range statement would actually be useful in = that domain. Its not exactly an "if-feature" though; its an = "if-in-this-domain" or something.   Also, these values need to = be a combination of run-time variables much like ultimately would be = considered a "policy statement". So today, in our object classes for we = have two stages of commit checks on an object: the first enforces what = is found in the Yang module's type/range statements, but the second is = essentially a manual augmentation to that which can further narrow the = statement, or as I said above, validate it against other operation = state. For example, if we had a definition for a VpnRoute leaf (forget = about the details for a moment), but you wanted to say, "in addition to = the syntactic constraints, only allow CurrentVpnRouteCount <=3D = MaxVpnRoutesAllowedOnThisRouter to be created."

        So using what you suggest below, but being = able to augment that at run-time would be ideal and making the statement = more robust somehow.

        --Tom


> Thanks.  Would there be any appetite for permitting the = feature approach
> (it would need to be understood that multiple "range" statements = are ORd)?
>
> leaf WWW {
>  type uint8 {
>    range "1..1" {
>      if-feature A;
>    }
>    range "2..2" {
>      if-feature B;
>    }
>  }
> }
>
> leaf XXX {
>  type uint8 {
>    range "1..10" {
>      if-feature A;
>    }
>    range "11..20" {
>      if-feature B;
>    }
>  }
> }
>
> Compare the above with
> http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.= html#sec-11, which
> also mentions "choice" as an option, and includes this example:
>
> type enumeration {
>  enum tcp;
>  enum ssh {
>    if-feature ssh;
>  }
>  enum tls {
>    if-feature tls;
>  }
> }
>
>
> Cheers,
> William
>
> On 16/10/2014 15:11, "Ladislav Lhotka" <lhotka@nic.cz> wrote:
>
>> Hello William,
>>
>> "William Lupton (wilupton)" <wilupton@cisco.com> = writes:
>>
>>> All,
>>>
>>> Someone asked me whether a YANG definition can distinguish = the parts of
>>> a
>>> range that are mandatory and the parts that are optional, = e.g an int
>>> leaf
>>> XXX might be required to support 1..10 but 11..20 might be = optional.  It
>>> seems that being able to associate 11..20 with a feature = would be a nice
>>> solution and would be equivalent to YANG 1.1 Y11 (allow = if-feature on
>>> enums)?  But I don't think that range "1..10|11..20" = can be split into
>>> multiple range statements, so this would not be = trivial?
>>>
>>> A use case from the DSL world (I can't be too specific) is = where the
>>> valid
>>> values for two leaf nodes are coupled.  If leaf WWW =3D = 1 then XXX =3D 1..10
>>> but if leaf WWW =3D 2 then XXX =3D 11..20.  A future = module version might
>>> add
>>> WWW =3D 3 and tie it to XXX =3D 21..30.
>>>
>>> I suppose that a "must" statement could be used (?) but I = quite like the
>>> feature approach, especially given the analogy with YANG = 1.1 Y11.
>>
>> This could be solved by defining a choice with one case for = each
>> variant. A must or when statement can then indeed be used for = making
>> sure that each case only applies when WWW has the corresponding = value.
>>
>> Something like
>>
>> choice XXX {
>> leaf XXX1 {
>>   must "../WWW =3D 1";
>>   type uint8 {
>>       range "1..10";
>>   }
>> }
>> leaf XXX2 {
>>   must "../WWW =3D 2";
>>   type uint8 {
>>       range "11..20";
>>   }
>> }
>> }
>>
>> Also, you can make a case conditional by using if-feature.
>>
>> Hope this helps,
>>
>> Lada
>>
>>
>>>
>>> Comments?
>>>
>>> Thanks,
>>> William Lupton
>>>
>>> _______________________________________________
>>> 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
>


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



= --Apple-Mail=_EF9A6965-6D99-425E-85BE-DD00CE33D784-- --Apple-Mail=_363B56BF-5181-4929-9DA3-C00BD228B239 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUQVM8AAoJEPcO+I7eiUJZU1sQAJhVH7Z9xwQGrn5RY3dXAyO9 9eF/Vess7liw2y1V8wymXBq7pr6l2QALc9Mr1n67XO7JytZS1kIXqdIFoASfKOq6 YiNsQY9IIO3uTr3eSuMSc/BSWKPK6EEsy15MVqqmd1zBENKWSjYpKkzzzN8VKC+G 4x4Ss9w/wkYAvJICrR1vwlJWzClAh1RDqf5y02vW25q2zUMrRMNGkeDkC2l5pCtx p/zjGJjrsZD/EuXUNVbcxFun3wKn0lBHXR1BeiW4RWHY8dohhdHFzgIEgdjQDYYf jUzIQto1QoM6Fx5NyJOekJBPinoZDOK8GpGA0qdH8wNgm8OFsuUYtecuouYNTyA0 E0VLGivJ/ZWNXvEr64GVp2e5HnBb2l/AtXh85rHmlqZeiYbz8GhJpesaFF5y9xer VtHCsmMGM71uyI9+GrEunfsPQj/VpKbGkuOuCe3hpCQBTlTAxi4jiUhSmRbODF3L V64YRW3+u0miaG5xxXTTmvPJ9n0sXf+Z1/hgRMpYNGSvxWG7Tc1ByqKRPf25GcY7 8VU+TxpN6FEBEl0XTwvAMYmsaoUkjhJMq82xEzROxNZjwuTGFVoemSRJ7VPj00Df lpJZfM8pmW/qsGeeP2etwlqI5C2w9jtT56B51fsaHzAySHdAcmGd56Lpb7sraTIY k0DdY8UEEC91AIycLW5Z =Xnsu -----END PGP SIGNATURE----- --Apple-Mail=_363B56BF-5181-4929-9DA3-C00BD228B239-- From nobody Fri Oct 17 10:39:34 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA1F1A00AF for ; Fri, 17 Oct 2014 10:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 RkcCC3gCiun4 for ; Fri, 17 Oct 2014 10:39:29 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 94EAA1A0086 for ; Fri, 17 Oct 2014 10:39:29 -0700 (PDT) Received: from [192.168.1.123] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 1662528C78AF; Fri, 17 Oct 2014 13:39:29 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_C4990715-D7C0-4263-A76C-575D730482CF"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: <20141017165757.GA81769@elstar.local> Date: Fri, 17 Oct 2014 13:39:16 -0400 Message-Id: References: <20141017165757.GA81769@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/kffSBF2B70qP6tMbxFXH1N2vHvE Cc: "netmod@ietf.org" Subject: Re: [netmod] Mandatory and optional ranges X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 17 Oct 2014 17:39:32 -0000 --Apple-Mail=_C4990715-D7C0-4263-A76C-575D730482CF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 17, 2014:12:57 PM, at 12:57 PM, Juergen Schoenwaelder = wrote: > Hi, >=20 > I am confused since you talk about 'operation state' and 'operational > store'. If we are talking about operational state, then what does > validate mean? It means checking the running state of the system in addition to = static syntactic constraints. > The operational state should document the real state of > the device and there is no concept of rejecting or validating it - if > the state is there, it is real operational state. Right - and that is my point. Operationally there is a need to = do this from some of my customers. > You can reject a > config change if the change leads to invalid config. That is what I am asking for - to augment what "valid" means. = Right now its only based on some relatively static constraints. > I am not sure how > to reject an operational state. Perhaps you are thinking about > identifying undesirable operational states. But for me, this would not > be the same thing as validation of config. And what is desirable or > undesirable likely depends on deployment specifics and thus it is > application and deployment domain specific and not generic. I think it is the same as validating a config request; its just = making the constraints more complex. This is actually done today within = implementations, but its hidden from the Netconf server. For example, if = the Max configured VRFs on a system is 20, and you try to configure a = (syntactically correct VRF), but the config fails. That is a very = simplistic example. You can imagine an entire operationally policy = attached to the constraints validation phase. > If the idea is, however, to express that the number of configured > vpnRoutes (e.g. list entries) is smaller than some leaf value (say > maxVpnRoutes) for a config to be valid, I think this is expressable > using must constraints. I think it is fair to limit the constraints to things that can = be expressed in a Yang module. --Tom >=20 > /js >=20 > On Fri, Oct 17, 2014 at 08:21:23AM -0400, Thomas D. Nadeau wrote: >>=20 >> Yes, but perhaps taking this a little further would help too but = I am not sure if that is a Yang 1.1 or 2.0 thing. Let me explain. We = were just discussing a similar requirement for a provisioning use case = over in ODL. What you propose would definitely help, but would not = necessarily be the comoplete solution. The use case is simple: an = operational domain that wishes to constrain an operational store to = values that make sense in that operational domain. So using your = example, the second range statement would actually be useful in that = domain. Its not exactly an "if-feature" though; its an = "if-in-this-domain" or something. Also, these values need to be a = combination of run-time variables much like ultimately would be = considered a "policy statement". So today, in our object classes for we = have two stages of commit checks on an object: the first enforces what = is found in the Yang module's type/range statements, but the second is = essentially a manual augmentation to that which can further narrow the = statement, or as I said above, validate it against other operation = state. For example, if we had a definition for a VpnRoute leaf (forget = about the details for a moment), but you wanted to say, "in addition to = the syntactic constraints, only allow CurrentVpnRouteCount <=3D = MaxVpnRoutesAllowedOnThisRouter to be created." >>=20 >> So using what you suggest below, but being able to augment that = at run-time would be ideal and making the statement more robust somehow. >>=20 >> --Tom >>=20 >>=20 >>> Thanks. Would there be any appetite for permitting the feature = approach >>> (it would need to be understood that multiple "range" statements are = ORd)? >>>=20 >>> leaf WWW { >>> type uint8 { >>> range "1..1" { >>> if-feature A; >>> } >>> range "2..2" { >>> if-feature B; >>> } >>> } >>> } >>>=20 >>> leaf XXX { >>> type uint8 { >>> range "1..10" { >>> if-feature A; >>> } >>> range "11..20" { >>> if-feature B; >>> } >>> } >>> } >>>=20 >>> Compare the above with >>> http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-11, = which >>> also mentions "choice" as an option, and includes this example: >>>=20 >>> type enumeration { >>> enum tcp; >>> enum ssh { >>> if-feature ssh; >>> } >>> enum tls { >>> if-feature tls; >>> } >>> } >>>=20 >>>=20 >>> Cheers, >>> William >>>=20 >>> On 16/10/2014 15:11, "Ladislav Lhotka" wrote: >>>=20 >>>> Hello William, >>>>=20 >>>> "William Lupton (wilupton)" writes: >>>>=20 >>>>> All, >>>>>=20 >>>>> Someone asked me whether a YANG definition can distinguish the = parts of >>>>> a >>>>> range that are mandatory and the parts that are optional, e.g an = int >>>>> leaf >>>>> XXX might be required to support 1..10 but 11..20 might be = optional. It >>>>> seems that being able to associate 11..20 with a feature would be = a nice >>>>> solution and would be equivalent to YANG 1.1 Y11 (allow if-feature = on >>>>> enums)? But I don't think that range "1..10|11..20" can be split = into >>>>> multiple range statements, so this would not be trivial? >>>>>=20 >>>>> A use case from the DSL world (I can't be too specific) is where = the >>>>> valid >>>>> values for two leaf nodes are coupled. If leaf WWW =3D 1 then XXX = =3D 1..10 >>>>> but if leaf WWW =3D 2 then XXX =3D 11..20. A future module = version might >>>>> add >>>>> WWW =3D 3 and tie it to XXX =3D 21..30. >>>>>=20 >>>>> I suppose that a "must" statement could be used (?) but I quite = like the >>>>> feature approach, especially given the analogy with YANG 1.1 Y11. >>>>=20 >>>> This could be solved by defining a choice with one case for each >>>> variant. A must or when statement can then indeed be used for = making >>>> sure that each case only applies when WWW has the corresponding = value. >>>>=20 >>>> Something like >>>>=20 >>>> choice XXX { >>>> leaf XXX1 { >>>> must "../WWW =3D 1"; >>>> type uint8 { >>>> range "1..10"; >>>> } >>>> } >>>> leaf XXX2 { >>>> must "../WWW =3D 2"; >>>> type uint8 { >>>> range "11..20"; >>>> } >>>> } >>>> } >>>>=20 >>>> Also, you can make a case conditional by using if-feature. >>>>=20 >>>> Hope this helps, >>>>=20 >>>> Lada >>>>=20 >>>>=20 >>>>>=20 >>>>> Comments? >>>>>=20 >>>>> Thanks, >>>>> William Lupton >>>>>=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 >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>>=20 >>=20 >=20 >=20 >=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=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 --Apple-Mail=_C4990715-D7C0-4263-A76C-575D730482CF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUQVREAAoJEPcO+I7eiUJZGSYQAKIfV+9uL0bsmcc/pzrv0Zo9 RddgFG+LuNy+Tki0WCQ6OShpnH4jAeiBrExPuEwEflt5oJFVM0VN5+VBh4f9TZrp Ggx87Z5IEpe5/JcGIbMmlFHp/kFCGS0LvBLH6y2j9IrY0WcxngQPXhn159Jf4Yuj ExDdNC/AHRVnllM2qAPx9JUQi0b7+nMnbQAPunbUjKqdtQ2cIsGeyJj4bmZBR63o J/E3pvLKUen5o4oPNYuSCDT7rinKJsTO6MI+XExAjsoDv0/uH57T6FMAPQkv1XHA b/IdKBA1mIV0GARwV+A7Pww8ipDDcRg9W483a99LaOEyCsy8Lp9uciA4z7lDRnIF G6N9m1FDOn1+nIst3govm+8sfENpc46aGJIECevpc+opOaZGq1IZpL/CWcN91cJr iTNRdBwsA0x/VFJdC05ZSHWxHNDnxKdrTvHtKbB0DxPzJSRDM5kA/b+0St5a2wkq uoAY6SHBSYqfzniq067YsMZ2hMUdObI+DUq31V2Kh2nJnvEF1JBwecGc1TJKiXCs qzcxm0kvi1meF3dkA+5k7tT4K+QwtlRAnNRVcGv2rnWVI2VvisDT1+q2hOPLndrg SDNLVvLCeGlh1OrN+7gD5V63s02MNyzZhjHKfPb4/tU/xx9gPoOCBA83ACiZV2Nw Uy1VAIuwYZ+Pjg6lNHBV =1f4O -----END PGP SIGNATURE----- --Apple-Mail=_C4990715-D7C0-4263-A76C-575D730482CF-- From nobody Fri Oct 17 10:45:46 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 247E81A00BF for ; Fri, 17 Oct 2014 10:45:44 -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 YAmwcG7XAJca for ; Fri, 17 Oct 2014 10:45:41 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 474B91A00BE for ; Fri, 17 Oct 2014 10:45:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8028; q=dns/txt; s=iport; t=1413567941; x=1414777541; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=OsJlBBBGOxZwEOoMAuKJ0gffsZec3WsJSoj6fl/NIKk=; b=Ojb8hLSBMCUS21nBYTpnp5hJgv93DaQIdURTugTQY5Y/DM8FUyFxuI9/ 58qMUR4cbdSaJWmMCZEQJecUl3wu+CZ6ZjMCUGEy0nudUC8TQfPby0ov8 h+uJRocDGK2ntoZvxIX593ZI69EGdtj01Up3xpG5xpaJjVXp8dOG1nkhI c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAPdUQVStJA2B/2dsb2JhbABSBgOCayNTWATMNAqGelQCgRQWAX2EAwEBBAEBATc0BgUOAgIBCBAIHhAbDAslAgQBDQUbiCQBDM1KAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwSNf4FvBCQjEAcRhDoFkgCERocTgTCQcYQEg3dsAQEBgQQBHgYcgQMBAQE X-IronPort-AV: E=Sophos;i="5.04,740,1406592000"; d="scan'208";a="87918729" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-1.cisco.com with ESMTP; 17 Oct 2014 17:45:40 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s9HHje5k005652 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Oct 2014 17:45:40 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Fri, 17 Oct 2014 12:45:40 -0500 From: "William Lupton (wilupton)" To: "Thomas D. Nadeau" , Juergen Schoenwaelder Thread-Topic: [netmod] Mandatory and optional ranges Thread-Index: AQHP3ih3IT74Ah1ZGECTWzsVHNUgK5wzLcaAgAE784CAADeCgIAATUWAgAALjACAABKDAA== Date: Fri, 17 Oct 2014 17:45:39 +0000 Message-ID: References: <20141017165757.GA81769@elstar.local> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [10.55.121.115] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/9J7DhjuYx150Xv5QSTjw9RAypxQ Cc: "netmod@ietf.org" Subject: Re: [netmod] Mandatory and optional ranges X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 17 Oct 2014 17:45:44 -0000 So, setting aside the more recent discussion, is there some agreement that my original suggestion, which can be seen as extending YANG 1.1 issue #11 to apply not only to {bits, enum, identity} but also to range, has some merit? W. On 17/10/2014 18:39, "Thomas D. Nadeau" wrote: > >On Oct 17, 2014:12:57 PM, at 12:57 PM, Juergen Schoenwaelder > wrote: > >> Hi, >>=20 >> I am confused since you talk about 'operation state' and 'operational >> store'. If we are talking about operational state, then what does >> validate mean? > > It means checking the running state of the system in addition to static >syntactic constraints. > >> The operational state should document the real state of >> the device and there is no concept of rejecting or validating it - if >> the state is there, it is real operational state. > > Right - and that is my point. Operationally there is a need to do this >from some of my customers. > >> You can reject a >> config change if the change leads to invalid config. > > That is what I am asking for - to augment what "valid" means. Right now >its only based on some relatively static constraints. > >> I am not sure how >> to reject an operational state. Perhaps you are thinking about >> identifying undesirable operational states. But for me, this would not >> be the same thing as validation of config. And what is desirable or >> undesirable likely depends on deployment specifics and thus it is >> application and deployment domain specific and not generic. > > I think it is the same as validating a config request; its just making >the constraints more complex. This is actually done today within >implementations, but its hidden from the Netconf server. For example, if >the Max configured VRFs on a system is 20, and you try to configure a >(syntactically correct VRF), but the config fails. That is a very >simplistic example. You can imagine an entire operationally policy >attached to the constraints validation phase. > >> If the idea is, however, to express that the number of configured >> vpnRoutes (e.g. list entries) is smaller than some leaf value (say >> maxVpnRoutes) for a config to be valid, I think this is expressable >> using must constraints. > > I think it is fair to limit the constraints to things that can be >expressed in a Yang module. > > --Tom > > >>=20 >> /js >>=20 >> On Fri, Oct 17, 2014 at 08:21:23AM -0400, Thomas D. Nadeau wrote: >>>=20 >>> Yes, but perhaps taking this a little further would help too but I am >>>not sure if that is a Yang 1.1 or 2.0 thing. Let me explain. We were >>>just discussing a similar requirement for a provisioning use case over >>>in ODL. What you propose would definitely help, but would not >>>necessarily be the comoplete solution. The use case is simple: an >>>operational domain that wishes to constrain an operational store to >>>values that make sense in that operational domain. So using your >>>example, the second range statement would actually be useful in that >>>domain. Its not exactly an "if-feature" though; its an >>>"if-in-this-domain" or something. Also, these values need to be a >>>combination of run-time variables much like ultimately would be >>>considered a "policy statement". So today, in our object classes for we >>>have two stages of commit checks on an object: the first enforces what >>>is found in the Yang module's type/range statements, but the second is >>>essentially a manual augmentation to that which can further narrow the >>>statement, or as I said above, validate it against other operation >>>state. For example, if we had a definition for a VpnRoute leaf (forget >>>about the details for a moment), but you wanted to say, "in addition to >>>the syntactic constraints, only allow CurrentVpnRouteCount <=3D >>>MaxVpnRoutesAllowedOnThisRouter to be created." >>>=20 >>> So using what you suggest below, but being able to augment that at >>>run-time would be ideal and making the statement more robust somehow. >>>=20 >>> --Tom >>>=20 >>>=20 >>>> Thanks. Would there be any appetite for permitting the feature >>>>approach >>>> (it would need to be understood that multiple "range" statements are >>>>ORd)? >>>>=20 >>>> leaf WWW { >>>> type uint8 { >>>> range "1..1" { >>>> if-feature A; >>>> } >>>> range "2..2" { >>>> if-feature B; >>>> } >>>> } >>>> } >>>>=20 >>>> leaf XXX { >>>> type uint8 { >>>> range "1..10" { >>>> if-feature A; >>>> } >>>> range "11..20" { >>>> if-feature B; >>>> } >>>> } >>>> } >>>>=20 >>>> Compare the above with >>>> http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-11, >>>>which >>>> also mentions "choice" as an option, and includes this example: >>>>=20 >>>> type enumeration { >>>> enum tcp; >>>> enum ssh { >>>> if-feature ssh; >>>> } >>>> enum tls { >>>> if-feature tls; >>>> } >>>> } >>>>=20 >>>>=20 >>>> Cheers, >>>> William >>>>=20 >>>> On 16/10/2014 15:11, "Ladislav Lhotka" wrote: >>>>=20 >>>>> Hello William, >>>>>=20 >>>>> "William Lupton (wilupton)" writes: >>>>>=20 >>>>>> All, >>>>>>=20 >>>>>> Someone asked me whether a YANG definition can distinguish the >>>>>>parts of >>>>>> a >>>>>> range that are mandatory and the parts that are optional, e.g an int >>>>>> leaf >>>>>> XXX might be required to support 1..10 but 11..20 might be >>>>>>optional. It >>>>>> seems that being able to associate 11..20 with a feature would be a >>>>>>nice >>>>>> solution and would be equivalent to YANG 1.1 Y11 (allow if-feature >>>>>>on >>>>>> enums)? But I don't think that range "1..10|11..20" can be split >>>>>>into >>>>>> multiple range statements, so this would not be trivial? >>>>>>=20 >>>>>> A use case from the DSL world (I can't be too specific) is where the >>>>>> valid >>>>>> values for two leaf nodes are coupled. If leaf WWW =3D 1 then XXX = =3D >>>>>>1..10 >>>>>> but if leaf WWW =3D 2 then XXX =3D 11..20. A future module version >>>>>>might >>>>>> add >>>>>> WWW =3D 3 and tie it to XXX =3D 21..30. >>>>>>=20 >>>>>> I suppose that a "must" statement could be used (?) but I quite >>>>>>like the >>>>>> feature approach, especially given the analogy with YANG 1.1 Y11. >>>>>=20 >>>>> This could be solved by defining a choice with one case for each >>>>> variant. A must or when statement can then indeed be used for making >>>>> sure that each case only applies when WWW has the corresponding >>>>>value. >>>>>=20 >>>>> Something like >>>>>=20 >>>>> choice XXX { >>>>> leaf XXX1 { >>>>> must "../WWW =3D 1"; >>>>> type uint8 { >>>>> range "1..10"; >>>>> } >>>>> } >>>>> leaf XXX2 { >>>>> must "../WWW =3D 2"; >>>>> type uint8 { >>>>> range "11..20"; >>>>> } >>>>> } >>>>> } >>>>>=20 >>>>> Also, you can make a case conditional by using if-feature. >>>>>=20 >>>>> Hope this helps, >>>>>=20 >>>>> Lada >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Comments? >>>>>>=20 >>>>>> Thanks, >>>>>> William Lupton >>>>>>=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 >>>>=20 >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>>=20 >>>=20 >>=20 >>=20 >>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=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 > From nobody Fri Oct 17 10:46:00 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1B31A00E8 for ; Fri, 17 Oct 2014 10:45:57 -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 ZINdZyaDCZC4 for ; Fri, 17 Oct 2014 10:45:54 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9CEF51A00BF for ; Fri, 17 Oct 2014 10:45:53 -0700 (PDT) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 82E9D1280A6E; Fri, 17 Oct 2014 19:45:52 +0200 (CEST) Date: Fri, 17 Oct 2014 19:45:51 +0200 (CEST) Message-Id: <20141017.194551.304706324.mbj@tail-f.com> To: tnadeau@lucidvision.com From: Martin Bjorklund In-Reply-To: <65782E1D-556B-4972-AF96-6FB93B5773A5@lucidvision.com> References: <65782E1D-556B-4972-AF96-6FB93B5773A5@lucidvision.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: http://mailarchive.ietf.org/arch/msg/netmod/_e2ogSUpNNmcL3pMMK2d9V7Rh6E Cc: netmod@ietf.org Subject: Re: [netmod] Mandatory and optional ranges X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 17 Oct 2014 17:45:57 -0000 Hi, "Thomas D. Nadeau" wrote: > > On Oct 17, 2014:11:49 AM, at 11:49 AM, William Lupton (wilupton) > wrote: > > > Thanks. When you say "run-time", does that refer to a "must" statement, > > or to something different and yet to be defined? > > It refers to the running state, and is defined per-domain, so its not > something you can just define in a standard model because its different > per domain. The example I gave is illustrative of that. For instance, > one operator might care about MaxVRFs when configuring service X, but > then another might care about MaxVRFs + . We have something we call configuration policies for this. Here's the description from the module: description "This module defines configuration policies. A configuration policy enforces custom validation rules on the configuration data. These rules assert that the user-defined conditions are always true in committed data. If a configuration change is done such that a policy rule would evaluate to false, the configuration change is rejected by the system."; This works somewhat like "must" statements, but are defined by the operator. Is this what you had in mind? Note that this is a normal YANG module with no additional YANG extensions; works fine w/ YANG 1.0. /martin From nobody Fri Oct 17 10:49:40 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB1E01A0183 for ; Fri, 17 Oct 2014 10:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 pJ6EAQXkTw-R for ; Fri, 17 Oct 2014 10:49:36 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB321A010F for ; Fri, 17 Oct 2014 10:49:36 -0700 (PDT) Received: from [192.168.1.123] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 8F73028C78FD; Fri, 17 Oct 2014 13:49:35 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_CAF535A9-EDBF-4D5B-A073-87FB07321F15"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: Date: Fri, 17 Oct 2014 13:49:22 -0400 Message-Id: <14BDFC9E-8D7D-49E6-9F33-CBBB15290B97@lucidvision.com> References: <20141017165757.GA81769@elstar.local> To: "William Lupton (wilupton)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/mDiVXtS8MRMM_0ZdOpCBmdDV__Q Cc: "netmod@ietf.org" Subject: Re: [netmod] Mandatory and optional ranges X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 17 Oct 2014 17:49:39 -0000 --Apple-Mail=_CAF535A9-EDBF-4D5B-A073-87FB07321F15 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I personally think so. --Tom On Oct 17, 2014:1:45 PM, at 1:45 PM, William Lupton (wilupton) = wrote: > So, setting aside the more recent discussion, is there some agreement = that > my original suggestion, which can be seen as extending YANG 1.1 issue = #11 > to apply not only to {bits, enum, identity} but also to range, has = some > merit? W. >=20 > On 17/10/2014 18:39, "Thomas D. Nadeau" = wrote: >=20 >>=20 >> On Oct 17, 2014:12:57 PM, at 12:57 PM, Juergen Schoenwaelder >> wrote: >>=20 >>> Hi, >>>=20 >>> I am confused since you talk about 'operation state' and = 'operational >>> store'. If we are talking about operational state, then what does >>> validate mean? >>=20 >> It means checking the running state of the system in addition to = static >> syntactic constraints. >>=20 >>> The operational state should document the real state of >>> the device and there is no concept of rejecting or validating it - = if >>> the state is there, it is real operational state. >>=20 >> Right - and that is my point. Operationally there is a need to = do this >> from some of my customers. >>=20 >>> You can reject a >>> config change if the change leads to invalid config. >>=20 >> That is what I am asking for - to augment what "valid" means. = Right now >> its only based on some relatively static constraints. >>=20 >>> I am not sure how >>> to reject an operational state. Perhaps you are thinking about >>> identifying undesirable operational states. But for me, this would = not >>> be the same thing as validation of config. And what is desirable or >>> undesirable likely depends on deployment specifics and thus it is >>> application and deployment domain specific and not generic. >>=20 >> I think it is the same as validating a config request; its just = making >> the constraints more complex. This is actually done today within >> implementations, but its hidden from the Netconf server. For example, = if >> the Max configured VRFs on a system is 20, and you try to configure a >> (syntactically correct VRF), but the config fails. That is a very >> simplistic example. You can imagine an entire operationally policy >> attached to the constraints validation phase. >>=20 >>> If the idea is, however, to express that the number of configured >>> vpnRoutes (e.g. list entries) is smaller than some leaf value (say >>> maxVpnRoutes) for a config to be valid, I think this is expressable >>> using must constraints. >>=20 >> I think it is fair to limit the constraints to things that can = be >> expressed in a Yang module. >>=20 >> --Tom >>=20 >>=20 >>>=20 >>> /js >>>=20 >>> On Fri, Oct 17, 2014 at 08:21:23AM -0400, Thomas D. Nadeau wrote: >>>>=20 >>>> Yes, but perhaps taking this a little further would help too but = I am >>>> not sure if that is a Yang 1.1 or 2.0 thing. Let me explain. We = were >>>> just discussing a similar requirement for a provisioning use case = over >>>> in ODL. What you propose would definitely help, but would not >>>> necessarily be the comoplete solution. The use case is simple: an >>>> operational domain that wishes to constrain an operational store to >>>> values that make sense in that operational domain. So using your >>>> example, the second range statement would actually be useful in = that >>>> domain. Its not exactly an "if-feature" though; its an >>>> "if-in-this-domain" or something. Also, these values need to be a >>>> combination of run-time variables much like ultimately would be >>>> considered a "policy statement". So today, in our object classes = for we >>>> have two stages of commit checks on an object: the first enforces = what >>>> is found in the Yang module's type/range statements, but the second = is >>>> essentially a manual augmentation to that which can further narrow = the >>>> statement, or as I said above, validate it against other operation >>>> state. For example, if we had a definition for a VpnRoute leaf = (forget >>>> about the details for a moment), but you wanted to say, "in = addition to >>>> the syntactic constraints, only allow CurrentVpnRouteCount <=3D >>>> MaxVpnRoutesAllowedOnThisRouter to be created." >>>>=20 >>>> So using what you suggest below, but being able to augment that = at >>>> run-time would be ideal and making the statement more robust = somehow. >>>>=20 >>>> --Tom >>>>=20 >>>>=20 >>>>> Thanks. Would there be any appetite for permitting the feature >>>>> approach >>>>> (it would need to be understood that multiple "range" statements = are >>>>> ORd)? >>>>>=20 >>>>> leaf WWW { >>>>> type uint8 { >>>>> range "1..1" { >>>>> if-feature A; >>>>> } >>>>> range "2..2" { >>>>> if-feature B; >>>>> } >>>>> } >>>>> } >>>>>=20 >>>>> leaf XXX { >>>>> type uint8 { >>>>> range "1..10" { >>>>> if-feature A; >>>>> } >>>>> range "11..20" { >>>>> if-feature B; >>>>> } >>>>> } >>>>> } >>>>>=20 >>>>> Compare the above with >>>>> = http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-11, >>>>> which >>>>> also mentions "choice" as an option, and includes this example: >>>>>=20 >>>>> type enumeration { >>>>> enum tcp; >>>>> enum ssh { >>>>> if-feature ssh; >>>>> } >>>>> enum tls { >>>>> if-feature tls; >>>>> } >>>>> } >>>>>=20 >>>>>=20 >>>>> Cheers, >>>>> William >>>>>=20 >>>>> On 16/10/2014 15:11, "Ladislav Lhotka" wrote: >>>>>=20 >>>>>> Hello William, >>>>>>=20 >>>>>> "William Lupton (wilupton)" writes: >>>>>>=20 >>>>>>> All, >>>>>>>=20 >>>>>>> Someone asked me whether a YANG definition can distinguish the >>>>>>> parts of >>>>>>> a >>>>>>> range that are mandatory and the parts that are optional, e.g an = int >>>>>>> leaf >>>>>>> XXX might be required to support 1..10 but 11..20 might be >>>>>>> optional. It >>>>>>> seems that being able to associate 11..20 with a feature would = be a >>>>>>> nice >>>>>>> solution and would be equivalent to YANG 1.1 Y11 (allow = if-feature >>>>>>> on >>>>>>> enums)? But I don't think that range "1..10|11..20" can be = split >>>>>>> into >>>>>>> multiple range statements, so this would not be trivial? >>>>>>>=20 >>>>>>> A use case from the DSL world (I can't be too specific) is where = the >>>>>>> valid >>>>>>> values for two leaf nodes are coupled. If leaf WWW =3D 1 then = XXX =3D >>>>>>> 1..10 >>>>>>> but if leaf WWW =3D 2 then XXX =3D 11..20. A future module = version >>>>>>> might >>>>>>> add >>>>>>> WWW =3D 3 and tie it to XXX =3D 21..30. >>>>>>>=20 >>>>>>> I suppose that a "must" statement could be used (?) but I quite >>>>>>> like the >>>>>>> feature approach, especially given the analogy with YANG 1.1 = Y11. >>>>>>=20 >>>>>> This could be solved by defining a choice with one case for each >>>>>> variant. A must or when statement can then indeed be used for = making >>>>>> sure that each case only applies when WWW has the corresponding >>>>>> value. >>>>>>=20 >>>>>> Something like >>>>>>=20 >>>>>> choice XXX { >>>>>> leaf XXX1 { >>>>>> must "../WWW =3D 1"; >>>>>> type uint8 { >>>>>> range "1..10"; >>>>>> } >>>>>> } >>>>>> leaf XXX2 { >>>>>> must "../WWW =3D 2"; >>>>>> type uint8 { >>>>>> range "11..20"; >>>>>> } >>>>>> } >>>>>> } >>>>>>=20 >>>>>> Also, you can make a case conditional by using if-feature. >>>>>>=20 >>>>>> Hope this helps, >>>>>>=20 >>>>>> Lada >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> Comments? >>>>>>>=20 >>>>>>> Thanks, >>>>>>> William Lupton >>>>>>>=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 >>>>>=20 >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>=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 >>=20 >=20 >=20 --Apple-Mail=_CAF535A9-EDBF-4D5B-A073-87FB07321F15 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUQVajAAoJEPcO+I7eiUJZK9MQAI21lMbseHbbGEV4cU1NQYQC qPAFshREnBXLohY5Xya+Cnho4Qmrmi+CTKhEl/CHVOECX2JQ7xMXIwY72zZNAFgS IfNdQdZ9FtJPlO2HBZAL5kTBxVJk4bY4En1jpHueStrhEC2s/din4Bh2FklpqhGY l1l0mE/Fl0cDfZyVoTXL3RFg/zJGz1Zm7aVkjOXU3uXrQQsZ+7XZtpsdFaxZaGZq bBeIYDdopM+Q+cBw+qs34+sJMq2yBpc42r1yueQBVrAsETl4DSpeeu/6c9d6LidC 6pU5QLDFEAYBBVjqGN/u6OumXHVu3gNE9PY+qDRmkg1WeDKSWXnr59r/PyZu5LIs G1JjuvoDV9henS70HNU/ZH3ztloZ1T37gckw2dkLhf/ufqvKev2OD+6AeNgdKz2f FptskM+vKze+17aSOuZv+V2uAshdZ/TsX5rDxBDz7ZHB5T6ZMHZExSRqW/OYtOCh TqIP1BNYUP+hc/yERNp5fsUJzhL4WPQu3A6NmHh0mi8v2Qn6OS5kD7pZEvyFDeUO 7t2elH//vid7Vtrxb9KTtxzSvaoyjt44EfWuJjhbdVrXjl9SD0NxIhJlFmuEYYo8 k6n54gdS6t1QS2UnSYZbcM+w+YxMlvonwwo/CNn+yVnOmnWPjNb2kTT/QnTAcC68 HeKSNUUpntYRof9s028K =IKKU -----END PGP SIGNATURE----- --Apple-Mail=_CAF535A9-EDBF-4D5B-A073-87FB07321F15-- From nobody Fri Oct 17 10:51:31 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA7851A00E8 for ; Fri, 17 Oct 2014 10:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 TjiO0pTgQ-cl for ; Fri, 17 Oct 2014 10:51:27 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id A473C1A00BF for ; Fri, 17 Oct 2014 10:51:27 -0700 (PDT) Received: from [192.168.1.123] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 3BCB528C7916; Fri, 17 Oct 2014 13:51:27 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_F88CCD1B-9AB6-4E4A-B326-E68F7FB39770"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: <20141017.194551.304706324.mbj@tail-f.com> Date: Fri, 17 Oct 2014 13:51:14 -0400 Message-Id: <071942DC-EA95-455F-ABE3-91B2E8125ACE@lucidvision.com> References: <65782E1D-556B-4972-AF96-6FB93B5773A5@lucidvision.com> <20141017.194551.304706324.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Ol6BXYpvDKFT80_5sb1TNzoQA4M Cc: netmod@ietf.org Subject: Re: [netmod] Mandatory and optional ranges X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 17 Oct 2014 17:51:29 -0000 --Apple-Mail=_F88CCD1B-9AB6-4E4A-B326-E68F7FB39770 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 17, 2014:1:45 PM, at 1:45 PM, Martin Bjorklund = wrote: > Hi, >=20 > "Thomas D. Nadeau" wrote: >>=20 >> On Oct 17, 2014:11:49 AM, at 11:49 AM, William Lupton (wilupton) >> wrote: >>=20 >>> Thanks. When you say "run-time", does that refer to a "must" = statement, >>> or to something different and yet to be defined? =20 >>=20 >> It refers to the running state, and is defined per-domain, so = its not >> something you can just define in a standard model because its = different >> per domain. The example I gave is illustrative of that. For = instance, >> one operator might care about MaxVRFs when configuring service = X, but >> then another might care about MaxVRFs + . >=20 > We have something we call configuration policies for this. Here's the > description from the module: >=20 > description > "This module defines configuration policies. A configuration = policy > enforces custom validation rules on the configuration data. > These rules assert that the user-defined conditions are always > true in committed data. If a configuration change is done such > that a policy rule would evaluate to false, the configuration > change is rejected by the system."; >=20 > This works somewhat like "must" statements, but are defined by the > operator. Is this what you had in mind? The issue is that these need to be augmented, perhaps at = run-time (versus inside of say a standard yang module). We need to = combine/override/refine existing constraints. Its my understanding that = you cannot do this with the must statement. --Tom > Note that this is a normal YANG module with no additional YANG > extensions; works fine w/ YANG 1.0. >=20 >=20 > /martin >=20 --Apple-Mail=_F88CCD1B-9AB6-4E4A-B326-E68F7FB39770 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUQVcSAAoJEPcO+I7eiUJZWQ0QAI3KwBDtlSeEed5Uvz3fba3R Whf/ZzvfIECVKMLz8brx+6OQ4JS+1Yi2dvePltvIHeeKYFjACyoOn60XbjFRr0QL 9zp0kOWJjmbIYUsX/b8zz6X5fa+axJCa6GmJjnNvucYFCgJPWym6vF4NBKrO7LD9 wfPe+rSr67ImsfP6yg0l6d9hSvBSQ0PBooiaLvG3ckt5GcIvlwGJCUouVzsVNxGD t7/Yk5YY+Yco4IL8IwpbCeDlZYHB365FM2bB5gU0IfnX8CKRV/7hsZGOSWxExOQN /KUepfleVaYgdrc51hwLDgVAURF7RaIPNlrxBTwHAlPFLSZgagK5g6uWA1CWoVCj lbEm0Cwo6j7M2FqteCi43KZW3uAfrkSv8P6ejzsueBNvcXrxKesz/I+Ixk/klz1J 6E2xsKmtoxCL9AH6A7aCbx1Ldyxp4P1n6pNT7edGZjUtuYkjJG4CjG1UuuLwj6UT ytcEax30nwdQCnYCLU5BoCT4YHPXzMbzCZFtvEEWZJ9ogeSXMCpD2ziwAzh6je5R YENwr/zLXrLbSvzfOnf3mI9IXq+8qsOCpPAlh2LG50H36NLdwIgG3Y7207dZEBJG 3HzdNFJdVabpRJ4CQgd/+vDByRNhNUv8w+Z09NteDBjyFmpQIyocYOZw98GNsGlx ntqWPHjUo8mp5OxmkbPd =c5ca -----END PGP SIGNATURE----- --Apple-Mail=_F88CCD1B-9AB6-4E4A-B326-E68F7FB39770-- From nobody Fri Oct 17 11:05:42 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739A71A0258 for ; Fri, 17 Oct 2014 11:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, 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 XCQwdGVM3SJh for ; Fri, 17 Oct 2014 11:05:27 -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 02D811A00BE for ; Fri, 17 Oct 2014 11:05:26 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 4A160716; Fri, 17 Oct 2014 20:05:18 +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 hq1HKi2YwL_w; Fri, 17 Oct 2014 20:05: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; Fri, 17 Oct 2014 20:05:17 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2F17B20037; Fri, 17 Oct 2014 20:05:17 +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 mCHJCeflfRAV; Fri, 17 Oct 2014 20:05: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 3A10F20035; Fri, 17 Oct 2014 20:05:16 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3BD422EFFD98; Fri, 17 Oct 2014 20:05:14 +0200 (CEST) Date: Fri, 17 Oct 2014 20:05:13 +0200 From: Juergen Schoenwaelder To: "Thomas D. Nadeau" Message-ID: <20141017180512.GA81912@elstar.local> Mail-Followup-To: "Thomas D. Nadeau" , "William Lupton (wilupton)" , "netmod@ietf.org" References: <20141017165757.GA81769@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: http://mailarchive.ietf.org/arch/msg/netmod/JPoVwPH0dETXaWlMNNgNxko0P2s Cc: "netmod@ietf.org" Subject: Re: [netmod] Mandatory and optional ranges 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, 17 Oct 2014 18:05:30 -0000 On Fri, Oct 17, 2014 at 01:39:16PM -0400, Thomas D. Nadeau wrote: > > I think it is the same as validating a config request; its just making the constraints more complex. This is actually done today within implementations, but its hidden from the Netconf server. For example, if the Max configured VRFs on a system is 20, and you try to configure a (syntactically correct VRF), but the config fails. That is a very simplistic example. You can imagine an entire operationally policy attached to the constraints validation phase. > But operational state changes dynamically. So your config becomes invalid because say some I2RS client or a routing protocol injects some additional state? What does it mean to now have invalid config? There is no config change transaction to reject in this case. So what should the box do? Reboot or shutdown? Or is the idea that all config changes from now on fail until they bring the box back again into a valid config state? /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 Oct 17 11:10:16 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1BE1A002F for ; Fri, 17 Oct 2014 11:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 6eJI3UKX0rD6 for ; Fri, 17 Oct 2014 11:10:08 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 0E80D1A026C for ; Fri, 17 Oct 2014 11:09:27 -0700 (PDT) Received: from [192.168.1.123] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id EBC4728C798E; Fri, 17 Oct 2014 14:09:26 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_46171C54-2B92-4E2A-8099-E0A2BF5F606A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: <20141017180512.GA81912@elstar.local> Date: Fri, 17 Oct 2014 14:09:14 -0400 Message-Id: <51318135-6AED-4B07-B6B1-CDE5D5038B1E@lucidvision.com> References: <20141017165757.GA81769@elstar.local> <20141017180512.GA81912@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/wBzN1QZkMxVsWn5vFDvH-gI53-o Cc: "netmod@ietf.org" Subject: Re: [netmod] Mandatory and optional ranges X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 17 Oct 2014 18:10:10 -0000 --Apple-Mail=_46171C54-2B92-4E2A-8099-E0A2BF5F606A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 17, 2014:2:05 PM, at 2:05 PM, Juergen Schoenwaelder = wrote: > On Fri, Oct 17, 2014 at 01:39:16PM -0400, Thomas D. Nadeau wrote: >>=20 >> I think it is the same as validating a config request; its just = making the constraints more complex. This is actually done today within = implementations, but its hidden from the Netconf server. For example, if = the Max configured VRFs on a system is 20, and you try to configure a = (syntactically correct VRF), but the config fails. That is a very = simplistic example. You can imagine an entire operationally policy = attached to the constraints validation phase. >>=20 >=20 > But operational state changes dynamically. So your config becomes > invalid because say some I2RS client or a routing protocol injects > some additional state? Yep. That is my point. The static definition doesn't necessarily = work. Its also problematic because one static def doesn't apply across = different=20 operational domains. > What does it mean to now have invalid config? > There is no config change transaction to reject in this case. So what > should the box do? Reboot or shutdown? Or is the idea that all config > changes from now on fail until they bring the box back again into a > valid config state? If the box is out of (configured) space for say VRFs, then it = simply rejects the config request. This is the same as any Policy = operation. --Tom >=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 --Apple-Mail=_46171C54-2B92-4E2A-8099-E0A2BF5F606A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUQVtKAAoJEPcO+I7eiUJZGu4P/1W3OvradklmQ3UnpYzc1E+a +uPg1hZUN/nF/fqAmUfMwcQOgNmS6dLgYZwanyxNwii14gVOmBRYLtogpoiunou4 wGVOATCouVL4pQbfacfP0UeRXGPWjHSahf29XiSRM72T0qqQu9UZXpgWM4AEr80V dt5azSKAI/JZlZG13oyHgR0CtNTaKfwDwg6a7szlVY0RLLiVFqZ3zTQvI+lno9Lr DZRnc6YHru4sLC2gkVxjAg7NGHObNVv6vjczwx4o2biEsPOoBkyXeaNW8hhFk+Np Bpuy7rbmK1/pr+KZtqdv2KDNoWdVNEWz6f3jJ3CQR4p5XZGQCqb7qMMw/yak6j12 wX33cBQyOpBRfUCmqMQbwK4lMTbj0Min0AyEHhO5xvjsGzB6XCUxc2lGBWZYUZjR 8KLd+PmWURFWrC3kynvw8jvYE1WjUFaUprnfMb82a8MP3jmnbE1MDaC3aLNW13Gh EJ91ey99La4W/Up8o4PuaewDSz+0JOf4RG5+G8WNO64Lt+hCd4MsuQJuow0gGu05 98PTrDyd70LQ7ZOd8tAtKeaSoNgYn1hlFS98wWi2ryVLbFJ8gwiNIxyjmZilM2jk 5E8xeQ16LPDr3eJ57QbwqZTHDT55B3U3hq6UpiwH7r1kh9F7cAAr0KZIOzShCBR+ S1pf1aQeCwS1QAezlPw8 =1wro -----END PGP SIGNATURE----- --Apple-Mail=_46171C54-2B92-4E2A-8099-E0A2BF5F606A-- From nobody Fri Oct 17 11:12:31 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78A6A1A0007 for ; Fri, 17 Oct 2014 11:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tN_GLmCeLPT0 for ; Fri, 17 Oct 2014 11:12:27 -0700 (PDT) Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF58A1A002F for ; Fri, 17 Oct 2014 11:12:26 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id w8so856353qac.19 for ; Fri, 17 Oct 2014 11:12:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=3WxLA/sPVQ7yc+mWhwQgPqJwoljxCl+gRhFirweB5Ec=; b=l82rUKOxkedOU8eUz/S+TKcSmLwSs5TIxZTBO4rk5VF68IWw8yqjgvBo5aYJrJn/6H IN54qp3iHjlXybOO/xNi0dyw2JAQ37k88A0nS9tkjQSF2CM2eP+JBUMEN7aJ6/NaBM0N X4fKdN5GDjk11YfQhUmSKBi0D/qjQjIv0hs/xOzRa3ZM4flJuH9AmIzo8+z729LiZXSs pICeDGRL+NSoEgcsOjRgDcKnK4lf2Hz6wO/Y67NklRFmU0dL9NyPLIqzMSyw6863okdV 3eH3moeOwqoVmp9ryPrn6NKeCoLg9Ggctq+H/MrI/Gn7Fn/bsh9TVRq2l5CbKwyvzRYG FqBw== X-Gm-Message-State: ALoCoQnxVwrHF7pYU810OI/3sqkw9ihRuXbCQ8AFnnyO/UE+Gr/qROdywheWglrkNFuXDHtnItuU MIME-Version: 1.0 X-Received: by 10.224.130.198 with SMTP id u6mr14175243qas.99.1413569544291; Fri, 17 Oct 2014 11:12:24 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Fri, 17 Oct 2014 11:12:24 -0700 (PDT) In-Reply-To: <20141017180512.GA81912@elstar.local> References: <20141017165757.GA81769@elstar.local> <20141017180512.GA81912@elstar.local> Date: Fri, 17 Oct 2014 11:12:24 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , "Thomas D. Nadeau" , "William Lupton (wilupton)" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=089e0158b38c8da1730505a24e03 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Go_gx_Jud8NJKprajRBYoFwfTxY Subject: Re: [netmod] Mandatory and optional ranges X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 17 Oct 2014 18:12:28 -0000 --089e0158b38c8da1730505a24e03 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 17, 2014 at 11:05 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Fri, Oct 17, 2014 at 01:39:16PM -0400, Thomas D. Nadeau wrote: > > > > I think it is the same as validating a config request; its just > making the constraints more complex. This is actually done today within > implementations, but its hidden from the Netconf server. For example, if > the Max configured VRFs on a system is 20, and you try to configure a > (syntactically correct VRF), but the config fails. That is a very > simplistic example. You can imagine an entire operationally policy attached > to the constraints validation phase. > > > > But operational state changes dynamically. So your config becomes > invalid because say some I2RS client or a routing protocol injects > some additional state? What does it mean to now have invalid config? > There is no config change transaction to reject in this case. So what > should the box do? Reboot or shutdown? Or is the idea that all config > changes from now on fail until they bring the box back again into a > valid config state? > > Validating a config request is not the same as expressing constraints on non-config data. The server is checking an internal resource constraint. That is not operational state. YANG is quite clear about this detail. Datastore validation is only based on config=true data nodes. Any YANG constraints on config=false data nodes refer to what can possibly returned as a valid for a request. > /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 > --089e0158b38c8da1730505a24e03 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Fri, Oct 17, 2014 at 11:05 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Fri, Oct 17, 2014 at 01:39:16PM -0400, Thomas D.= Nadeau wrote:
>
>=A0 =A0 =A0 =A0I think it is the same as validating a config request; i= ts just making the constraints more complex.=A0 This is actually done today= within implementations, but its hidden from the Netconf server. For exampl= e, if the Max configured VRFs on a system is 20, and you try to configure a= (syntactically correct VRF), but the config fails.=A0 That is a very simpl= istic example. You can imagine an entire operationally policy attached to t= he constraints validation phase.
>

But operational state changes dynamically. So your config becomes
invalid because say some I2RS client or a routing protocol injects
some additional state?=A0 What does it mean to now have invalid config?
There is no config change transaction to reject in this case. So what
should the box do? Reboot or shutdown? Or is the idea that all config
changes from now on fail until they bring the box back again into a
valid config state?



Validating a config request is not th= e same as expressing constraints on non-config data.
The server i= s checking an internal resource constraint.=A0 That is not operational stat= e.

YANG is quite clear about this detail. Datastor= e validation is only based on config=3Dtrue data nodes.
Any YANG = constraints on config=3Dfalse data nodes refer to what can possibly returne= d
as a valid <rpc-reply> for a <get> request.


=A0
/js

Andy
=A0

--
Juergen Schoenwaelder=A0 =A0 =A0 =A0 =A0 =A0Jacobs University Bremen gGmbH<= br> Phone: +49 421 200 3587=A0 =A0 =A0 =A0 =A0Campus Ring 1, 28759 Bremen, Germ= any
Fax:=A0 =A0+49 421 200 3103=A0 =A0 =A0 =A0 =A0<http://www.jacobs-university.de/&= gt;

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

--089e0158b38c8da1730505a24e03-- From nobody Fri Oct 17 11:16:33 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 657E01A0069 for ; Fri, 17 Oct 2014 11:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id riL0Y2wKt90c for ; Fri, 17 Oct 2014 11:16:19 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id A22731A0068 for ; Fri, 17 Oct 2014 11:16:18 -0700 (PDT) Received: from [192.168.1.123] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 348D728C79D7; Fri, 17 Oct 2014 14:16:18 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_A95C7782-811E-4094-9272-D8C5823AC71E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: Date: Fri, 17 Oct 2014 14:16:03 -0400 Message-Id: <0B9805D2-75A5-4E77-A683-019832B35153@lucidvision.com> References: <20141017165757.GA81769@elstar.local> <20141017180512.GA81912@elstar.local> To: Andy Bierman X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/NFEVbD1xZNWGtmCRO6W2R2z3Pu0 Cc: "netmod@ietf.org" Subject: Re: [netmod] Mandatory and optional ranges X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 17 Oct 2014 18:16:20 -0000 --Apple-Mail=_A95C7782-811E-4094-9272-D8C5823AC71E Content-Type: multipart/alternative; boundary="Apple-Mail=_C279DA7A-EE94-4070-8A10-E226AA8A92CC" --Apple-Mail=_C279DA7A-EE94-4070-8A10-E226AA8A92CC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Oct 17, 2014:2:12 PM, at 2:12 PM, Andy Bierman = wrote: >=20 >=20 > On Fri, Oct 17, 2014 at 11:05 AM, Juergen Schoenwaelder = wrote: > On Fri, Oct 17, 2014 at 01:39:16PM -0400, Thomas D. Nadeau wrote: > > > > I think it is the same as validating a config request; its = just making the constraints more complex. This is actually done today = within implementations, but its hidden from the Netconf server. For = example, if the Max configured VRFs on a system is 20, and you try to = configure a (syntactically correct VRF), but the config fails. That is = a very simplistic example. You can imagine an entire operationally = policy attached to the constraints validation phase. > > >=20 > But operational state changes dynamically. So your config becomes > invalid because say some I2RS client or a routing protocol injects > some additional state? What does it mean to now have invalid config? > There is no config change transaction to reject in this case. So what > should the box do? Reboot or shutdown? Or is the idea that all config > changes from now on fail until they bring the box back again into a > valid config state? >=20 >=20 >=20 > Validating a config request is not the same as expressing constraints = on non-config data. Right. But its cool if you can express the same constraints = using Yang. > The server is checking an internal resource constraint. That is not = operational state. The value of a counter containing the number of configured Xs = surely is operational state, for example. That is not something I pre-configure in a Yang model, necessarily. > YANG is quite clear about this detail. Datastore validation is only = based on config=3Dtrue data nodes. > Any YANG constraints on config=3Dfalse data nodes refer to what can = possibly returned > as a valid for a request. The existing Yang does. That is my point in there being parts of = this that might belong in Yang 2.0. --Tom >=20 >=20 > =20 > /js >=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 >=20 --Apple-Mail=_C279DA7A-EE94-4070-8A10-E226AA8A92CC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Oct 17, 2014:2:12 PM, at 2:12 PM, = Andy Bierman <andy@yumaworks.com> = wrote:



On Fri, Oct 17, 2014 at 11:05 AM, Juergen = Schoenwaelder <j.schoenwaelder@jacobs-university.de> = wrote:
On Fri, Oct 17, 2014 = at 01:39:16PM -0400, Thomas D. Nadeau wrote:
>
>       I think it is the same as validating a = config request; its just making the constraints more complex.  This = is actually done today within implementations, but its hidden from the = Netconf server. For example, if the Max configured VRFs on a system is = 20, and you try to configure a (syntactically correct VRF), but the = config fails.  That is a very simplistic example. You can imagine = an entire operationally policy attached to the constraints validation = phase.
>

But operational state changes dynamically. So your config becomes
invalid because say some I2RS client or a routing protocol injects
some additional state?  What does it mean to now have invalid = config?
There is no config change transaction to reject in this case. So = what
should the box do? Reboot or shutdown? Or is the idea that all = config
changes from now on fail until they bring the box back again into a
valid config state?



<= /div>
Validating a config request is not the same as expressing = constraints on non-config = data.

Right. = But its cool if you can express the same constraints using = Yang.

The server is = checking an internal resource constraint.  That is not operational = state.

The value = of a counter containing the number of configured Xs surely is = operational state, for example.
That is not something I = pre-configure in a Yang model, necessarily.

YANG is quite clear about this detail. = Datastore validation is only based on config=3Dtrue data = nodes.
Any YANG constraints on config=3Dfalse data nodes refer = to what can possibly returned
as a valid <rpc-reply> for = a <get> = request.

The = existing Yang does. That is my point in there being parts of this that = might belong in Yang 2.0.

= --Tom



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


= --Apple-Mail=_C279DA7A-EE94-4070-8A10-E226AA8A92CC-- --Apple-Mail=_A95C7782-811E-4094-9272-D8C5823AC71E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUQVzjAAoJEPcO+I7eiUJZX/sP/RNXYlm+Y9916UcTXlcM+fe2 zshvi6HJB++5RjCAyCtEG2QepeA9y481nInA60PprGyialyXeOi5rIPC5B6VO0Nn CXgYTuNSKarjxAduE2JxVhxROSOoyWLD+trrJNDnqhwb4+bNT9tASo4Y3VQwjWJm TmvZmCcZ+pEbO312bPC7Da53CcldAeegM6y3RZzOtpnvBrFF9YPyxpXKYITdroXq B21iCb5qWA0WSBk8m2ayJCg4TVv7b9lRHnRGG9TK/KNTWWq5oV1t+fOpUjMsIbvF 3GO3/r7oriIMhby09vtRHpQu7YO4CCis5H6wUUpai8d4Ps9UZToYT/g37xhp8Av/ gVDVPoV8hMVd5MQUPxoeq8XIyaOyLqDHECre+nYM6NsFn+ARS49AKKgkP6bD4ub8 oIVN5k5NFnVf3N9pvyLDiIic0h1r1Ww5hdTlIPXaTudew6TH4FKDF991ejlanfbg XIu4VAXD4uIeiXOR7yJLQ6WQ+lCtPS1G7qsJqMPdDZdUmIXQ8es/y9lMmEfZibNa OrefF7N4Zt50BD3s8JaaO0u6Av+kM5Ch40fz7HyjlR27luSvrXT2lZ05i4b6OhBZ bvUTsEMGbMS/ViRWdLwx4bJ1uVGd3yU5ISVC1l6gz3rZCutM6TkiSrynwHt3fk3i gj2xhrNy6Akx6ffI6p79 =tvY4 -----END PGP SIGNATURE----- --Apple-Mail=_A95C7782-811E-4094-9272-D8C5823AC71E-- From nobody Fri Oct 17 14:19:53 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98BC21A19EC for ; Fri, 17 Oct 2014 14:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGWKQCiS1Anx for ; Fri, 17 Oct 2014 14:19:49 -0700 (PDT) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 750371A000F for ; Fri, 17 Oct 2014 14:19:49 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id dc16so1084389qab.7 for ; Fri, 17 Oct 2014 14:19: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:cc:content-type; bh=GMO0dyvay2op15TceEYbv8YGxdX39AdUzGhL8tDfAbw=; b=X4yYMxbV0kmT7Y6ufwG+vl5tCxUDADWsAK2vwAgvGt1jOEUBKjY/AVvdCzx3oeXvW5 cYVk1dDPm7S5XtdDSxV6A0dD6TKqyOMHdziFSzmAWyK9C2MPgysHH+S38fA1M9KBdicr TmCkRar4C1l36AoiLtBM9YFn9LbRyiT49trBjMOz+zpfjzc23FFpEB7Ldbwm4YNlwr0H 6VaCI4W/0w5mtAKY2GX61+2Nu26kW04ANxpC5RSNWnolxEzYw7/xCeJxrLn7YveuKr2M i7g6VSKNLuSzDfl+TDQfpHJin+ST8ogh/lBuNqkHPpLhf4PQJ5sjn51EIVFutLl4NU6P Cllg== X-Gm-Message-State: ALoCoQmPAaNVQH3LoMkgKFFP7HQCFy6KTDt7XrbUlHpoo+6L9ZJ/Nr/sun54YJxBs7GeiuE7FqcP MIME-Version: 1.0 X-Received: by 10.140.34.102 with SMTP id k93mr10620534qgk.21.1413580788520; Fri, 17 Oct 2014 14:19:48 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Fri, 17 Oct 2014 14:19:48 -0700 (PDT) In-Reply-To: <0B9805D2-75A5-4E77-A683-019832B35153@lucidvision.com> References: <20141017165757.GA81769@elstar.local> <20141017180512.GA81912@elstar.local> <0B9805D2-75A5-4E77-A683-019832B35153@lucidvision.com> Date: Fri, 17 Oct 2014 14:19:48 -0700 Message-ID: From: Andy Bierman To: "Thomas D. Nadeau" Content-Type: multipart/alternative; boundary=001a11c0d2d4c2eee70505a4ec37 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Zv7UlFbBPZas-CvcvqOx0XT9JqY Cc: "netmod@ietf.org" Subject: Re: [netmod] Mandatory and optional ranges X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 17 Oct 2014 21:19:51 -0000 --001a11c0d2d4c2eee70505a4ec37 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 17, 2014 at 11:16 AM, Thomas D. Nadeau wrote: > > On Oct 17, 2014:2:12 PM, at 2:12 PM, Andy Bierman > wrote: > > > > On Fri, Oct 17, 2014 at 11:05 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > >> On Fri, Oct 17, 2014 at 01:39:16PM -0400, Thomas D. Nadeau wrote: >> > >> > I think it is the same as validating a config request; its just >> making the constraints more complex. This is actually done today within >> implementations, but its hidden from the Netconf server. For example, if >> the Max configured VRFs on a system is 20, and you try to configure a >> (syntactically correct VRF), but the config fails. That is a very >> simplistic example. You can imagine an entire operationally policy attached >> to the constraints validation phase. >> > >> >> But operational state changes dynamically. So your config becomes >> invalid because say some I2RS client or a routing protocol injects >> some additional state? What does it mean to now have invalid config? >> There is no config change transaction to reject in this case. So what >> should the box do? Reboot or shutdown? Or is the idea that all config >> changes from now on fail until they bring the box back again into a >> valid config state? >> >> > > Validating a config request is not the same as expressing constraints on > non-config data. > > > Right. But its cool if you can express the same constraints using Yang. > > There is a fundamental design assumption in NETCONF, based on RFC 3535 requirements. A (issued by a client with full read access) will return a complete representation of the configuration, such that the YANG validation rules could be applied to this data. This data could also be used to completely restore a configuration via . The server is checking an internal resource constraint. That is not > operational state. > > > The value of a counter containing the number of configured Xs surely is > operational state, for example. > That is not something I pre-configure in a Yang model, necessarily. > The value of an counter is a representation of internal state data. The config validation can check this internal state as part of deciding between and "resource-denied". > > YANG is quite clear about this detail. Datastore validation is only based > on config=true data nodes. > Any YANG constraints on config=false data nodes refer to what can possibly > returned > as a valid for a request. > > > The existing Yang does. That is my point in there being parts of this that > might belong in Yang 2.0. > > --Tom > Andy > > > > > >> /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 >> > > > --001a11c0d2d4c2eee70505a4ec37 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Fri, Oct 17, 2014 at 11:16 AM, Thomas D. Nadeau &l= t;tnadeau@luci= dvision.com> wrote:

On Oct 17, 2014:2:12 PM, at 2:12 PM, Andy Bier= man <andy@yumawo= rks.com> wrote:

=

On Fri, Oct 1= 7, 2014 at 11:05 AM, Juergen Schoenwaelder <j.schoenwae= lder@jacobs-university.de> wrote:
On Fri,= Oct 17, 2014 at 01:39:16PM -0400, Thomas D. Nadeau wrote:
>
>=A0 =A0 =A0 =A0I think it is the same as validating a config request; i= ts just making the constraints more complex.=A0 This is actually done today= within implementations, but its hidden from the Netconf server. For exampl= e, if the Max configured VRFs on a system is 20, and you try to configure a= (syntactically correct VRF), but the config fails.=A0 That is a very simpl= istic example. You can imagine an entire operationally policy attached to t= he constraints validation phase.
>

But operational state changes dynamically. So your config becomes
invalid because say some I2RS client or a routing protocol injects
some additional state?=A0 What does it mean to now have invalid config?
There is no config change transaction to reject in this case. So what
should the box do? Reboot or shutdown? Or is the idea that all config
changes from now on fail until they bring the box back again into a
valid config state?



Validating a config request is not the same as express= ing constraints on non-config data.

Right. But it= s cool if you can express the same constraints using Yang.

<= /div>


There is a fundamental= design assumption in NETCONF, based on RFC 3535 requirements.
A = <get-config> (issued by a client with full read access) will return a= complete representation
of the configuration, such that the YANG= validation rules could be applied to this data.
This data could = also be used to completely restore a configuration via <copy-config>.=

<= div>
<= div class=3D"gmail_quote">
The server is checking an internal resource = constraint.=A0 That is not operational state.

The valu= e of a counter containing the number of configured Xs surely is operational= state, for example.
That is not something I pre-configure in a Y= ang model, necessarily.

The val= ue of an counter is a representation of internal state data.
The = config validation can check this internal state as part of deciding
between <ok> and "resource-denied".

=
=A0
YANG is quite clear about this detail. Datastor= e validation is only based on config=3Dtrue data nodes.
Any YANG = constraints on config=3Dfalse data nodes refer to what can possibly returne= d
as a valid <rpc-reply> for a <get> request.

The existing Yang does. That is my point in there being = parts of this that might belong in Yang 2.0.
=A0
<= /div>
--Tom


Andy
= =A0



=A0
/js

Andy
=A0

--
Juergen Schoenwaelder=A0 =A0 =A0 =A0 =A0 =A0Jacobs University Bremen gGmbH<= br> Phone: +49 421 200 3587=A0 =A0 =A0 =A0 =A0Campus Ring 1, 28759 Bremen, Germ= any
Fax:=A0 =A0+49 421 200 3103=A0 =A0 =A0 =A0 =A0<http://www.jacobs-university.de/&= gt;

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



--001a11c0d2d4c2eee70505a4ec37-- From nobody Sun Oct 19 09:50:44 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3D251A19F3 for ; Sun, 19 Oct 2014 09:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.079 X-Spam-Level: X-Spam-Status: No, score=-0.079 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 nBeVbncsPvgW for ; Sun, 19 Oct 2014 09:50:41 -0700 (PDT) Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59DAA1A0AF1 for ; Sun, 19 Oct 2014 09:50:41 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id w8so2418903qac.33 for ; Sun, 19 Oct 2014 09:50:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=rm2HRVBLi1GttLfqtQY9EVsXcHVAMtBx1PT/rtkMM5o=; b=h64oB41KoHOtrTlRvCS3vsSW8VkTmVQkvI8Bn4pUV1WbS552XTbu4gWVX5E1eC0u9m Mdil9XdQvgmUxCGhxn7vlw1dEcoMu1dJq8QeXKTIQKLFUpk7zXjHvnhd2DKgLlJChvdm azydVWpHcFkeA5OzJjAOfS1uOEQrmzdq7EAxMYiVZT55/Jqm8Adb/o8hDkxSY+pZhBic AAomWLd2BJVC3MjmBBmvgUHRm9KuRlKID2fOhfy+RpsKWpBWnIzLeNVE9snR/o+2m/od trwx+PkePx/UQ2UfLSlMO2BrAR03b8vGt8gDNDZ+AwK5mi+kfmO/zMEC6S7uYoieJ9JV T7Fg== X-Gm-Message-State: ALoCoQnAA4wOSUOkIoihhfs8ps8JYTYdLVmhpw46qQNXEzg3p3aBudDBbR152HZ8RUSc+fZXorA4 MIME-Version: 1.0 X-Received: by 10.140.34.102 with SMTP id k93mr22863036qgk.21.1413737440365; Sun, 19 Oct 2014 09:50:40 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Sun, 19 Oct 2014 09:50:40 -0700 (PDT) Date: Sun, 19 Oct 2014 09:50:40 -0700 Message-ID: From: Andy Bierman To: "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11c0d2d4f06cc10505c9659d Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ZM55_NSP31DiEz4dnxsQw-E4KAA Subject: [netmod] YANG Metadata Issue: leaf-list X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 19 Oct 2014 16:50:42 -0000 --001a11c0d2d4f06cc10505c9659d Content-Type: text/plain; charset=ISO-8859-1 Hi, I have run into some issues implementing draft-lhotka-netmod-yang-metadata-00. (1) The annotations for leaf-list nodes are expensive to implement in a constrained or streaming-based server. Every other node type is easy to stream because all the data can be rendered before moving on to the next node. But the leaf-list meta-data follows all the leaf-list nodes: For example, in the following leaf-list instance with four entries, the "inactive" annotation is added to the second and third entry in the following way: "folio": [6, 3, 7, 8], "@folio": [ null, {"example-inactive:inactive": true}, {"example-inactive:inactive": true} ] The server has to remember a lot of state and/or go through the leaf-list twice. It is possible that the last node is gone and the next node is unknown in a streaming server, This could take a lot of resources for large leaf-lists. (2) The module-name as prefix is not really needed unless there are annotations with the same name advertised by the server. (3) Multiple annotations can be rendered in any order within an array entry: This should be clarified (and maybe an example). "folio": [6, 3, 7, 8], "@folio": [ null, {"example-inactive:inactive": true, "example:foo":42 }, {"example:foo":53, example-inactive:inactive": true} ] Andy --001a11c0d2d4f06cc10505c9659d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I have run into some issues impleme= nting draft-lhotka-netmod-yang-metadata-00.

(1) Th= e annotations for leaf-list nodes are expensive to implement in
a= constrained or streaming-based server.=A0 Every other node type
= is easy to stream because all the data can be rendered before
mov= ing on to the next node.=A0 But the leaf-list meta-data follows
a= ll the leaf-list nodes:

=A0 =A0For examp= le, in the following leaf-list instance with four entries,
=A0 = =A0the "inactive" annotation is added to the second and third ent= ry in
=A0 =A0the following way:

= =A0 =A0 =A0 =A0"folio": [6, 3, 7, 8],
=A0 =A0 =A0 =A0&q= uot;@folio": [
=A0 =A0 =A0 =A0 =A0null,
=A0 =A0 = =A0 =A0 =A0{"example-inactive:inactive": true},
=A0 =A0= =A0 =A0 =A0{"example-inactive:inactive": true}
=A0 =A0= =A0 =A0]

The server has to remember a lot o= f state and/or go through the leaf-list
twice.=A0 It is possible = that the last node is gone and the next node is
unknown in a stre= aming server, This could take a lot of resources
for large leaf-l= ists.

(2) The module-name as prefix is not really = needed unless
there are annotations with the same name advertised= by the server.

(3) Multiple annotations can be re= ndered in any order within an array entry:
This should be clarifi= ed (and maybe an example).

=A0 =A0 =A0 = =A0"folio": [6, 3, 7, 8],
=A0 =A0 =A0 =A0"@folio&q= uot;: [
=A0 =A0 =A0 =A0 =A0null,
=A0 =A0 =A0 =A0 =A0{&q= uot;example-inactive:inactive": true,
=A0 =A0 =A0 =A0 =A0 = =A0"example:foo":42 },
=A0 =A0 =A0 =A0 =A0{"exampl= e:foo":53,
=A0 =A0 =A0 =A0 =A0 =A0example-inactive:inactive&= quot;: true}
=A0 =A0 =A0 =A0]


Andy

--001a11c0d2d4f06cc10505c9659d-- From nobody Sun Oct 19 23:05:42 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B60E1A6FA6; Sun, 19 Oct 2014 23:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.522 X-Spam-Level: X-Spam-Status: No, score=0.522 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUpWxrj36o41; Sun, 19 Oct 2014 23:05:35 -0700 (PDT) Received: from mail-yh0-x22e.google.com (mail-yh0-x22e.google.com [IPv6:2607:f8b0:4002:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 708871A6FA0; Sun, 19 Oct 2014 23:05:35 -0700 (PDT) Received: by mail-yh0-f46.google.com with SMTP id f73so2551482yha.19 for ; Sun, 19 Oct 2014 23:05:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:cc:content-type; bh=lTaTxiWmc5vUyeA+dHO046lBRzXgf7whsQez81T+2zc=; b=WISwMo7twlo3dtiZGDe1hU09DbEHC6r+q3cuq/y6MzmcgnG/xLSKnr/8yoj5fyJpu2 TC5kBpV9ULm6+Sm5+C3EZPYCD1dlBEIMbc5dbU88sdWkDwaTXMQEVSgUJEVccD5eN0nd T99roVNv5Ttnvx1uf1+IbKLa8IzdLSiLE1xLDpigYMPaLKvPDOSVXU+JGv8/q9+ronX2 5uxLhLhZNwOpHla2rJ6fwKcKLa1ohCJyBcRCmwheEUYoYId6P7KUPnwQLNZoDW4P5tYH 6+zqJeYjkD0NNLMPn55W/hT6grLUat3nT+gyZrQBzpp2xs0krQoNntLmJjesb+50n4Aw cpzw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yale.edu; s=googleprd; h=mime-version:sender:from:date:message-id:subject:to:cc:content-type; bh=lTaTxiWmc5vUyeA+dHO046lBRzXgf7whsQez81T+2zc=; b=lsV6NfGnf6G1vLqlX/baLpl4riHwG2J7tMw60lqfz9fxthPOpxR6bXezcjTGutlVc6 Fru97y7q7DyVcWgjkK5gLvkrWb9a3G2EhnqZMQypAdvdJX33k83+scgz2zgJY/X0N6Wy k/pStXW8zhhQ6PnFgshl4UizGcmagxviIbeTw= X-Received: by 10.236.34.167 with SMTP id s27mr35132810yha.53.1413785134619; Sun, 19 Oct 2014 23:05:34 -0700 (PDT) MIME-Version: 1.0 Sender: boxs.jq@gmail.com Received: by 10.170.97.10 with HTTP; Sun, 19 Oct 2014 23:05:14 -0700 (PDT) From: Xiao SHI Date: Mon, 20 Oct 2014 02:05:14 -0400 X-Google-Sender-Auth: nprBq1F3kzUIKvA64zhc-Jn4MHA Message-ID: To: IETF ALTO , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11c1c058bce7bd0505d480e7 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/IfDeHBeTLKtv_gnmRdV3KYIih2U Subject: [netmod] Modeling JSON based protocols using YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 20 Oct 2014 06:05:40 -0000 --001a11c1c058bce7bd0505d480e7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi folks, As a few of us were working on modeling the ALTO protocol using YANG, we were pondering on a more general question: can YANG model all JSON based protocols? What is the condition for a JSON based protocol (at least the message format) to have an syntactically equivalent, hence interoperable, YANG model with JSON encoding? Alternatively, in order to interoperate, semantic equivalence might be sufficient, is there any condition for semantic equivalence? tl;dr: A JSON based protocol carried by HTTP can have syntactically equivalent YANG model, if and only if all the keys in the key-value pairs in the JSON message are pre-defined keywords in the protocol. We've come up with a few ideas, and a few things below are work in progress, but we would love your feedback! Thank you! Xiao =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1. Introduction. JavaScript Object Notation (JSON) has been a popular choice as the message encoding for many network protocols such as the Application Layer Traffic Optimization (ALTO) protocol, the Content Delivery Networks Interconnection (CDNi) protocol, etc. Meanwhile, there are broad interests in the networking community to use YANG to define data model so that one can use YANG related tools such as OpenDayLight controller. Although YANG itself is XML based, there have been efforts to model JSON content using YANG [draft-ietf-netmod-yang-json-01]. A natural question rises: can YANG model all JSON based protocols? What is the condition for a JSON based protocol (at least the message format) to have an syntactically equivalent, hence interoperable, YANG model with JSON encoding? Alternatively, in order to interoperate, semantic equivalence might be sufficient, is there any condition for semantic equivalence? 2. Claim A JSON based protocol carried by HTTP can have syntactically equivalent YANG model, if and only if: (1) the message encoding condition is met; (2) the uri condition is met. 2.1. The message encoding condition The JSON message encoding MUST not contain a variable as a key in a JSON object key-value pair. In other words, the keys in the JSON message must be an already defined constant (or keyword) in the message format of the protocol. For example, if I have a protocol where =E2=80=9Cnetwork-map=E2=80=9D, =E2= =80=9Csrc=E2=80=9D, and =E2=80=9Cdsts=E2=80=9D are defined keywords, JSON text A meets the condition whereas B does not because =E2=80=9CPID1=E2=80=9D and =E2=80=9CPID2=E2=80=9D are not protocol = keywords (they are resource IDs). A: { =E2=80=9Cnetwork-map=E2=80=9D: [ { =E2=80=9Csrc=E2=80=9D: =E2=80=9CPID1=E2=80=9D, =E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID2=E2=80=9D, =E2=80=9CPID3=E2=80= =9D] }, { =E2=80=9Csrc=E2=80=9D: =E2=80=9CPID2=E2=80=9D, =E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID3=E2=80=9D, =E2=80=9CPID4=E2=80= =9D] } ] } B: { =E2=80=9Cnetwork-map=E2=80=9D: [ =E2=80=9CPID1: [=E2=80=9CPID2=E2=80=9D, =E2=80=9CPID3=E2=80=9D], =E2=80=9CPID2=E2=80=9D: [=E2=80=9CPID3=E2=80=9D, =E2=80=9CPID4=E2=80=9D] ] } >From this we know that since ALTO protocol uses encoding B, there cannot be a syntactically equivalent YANG model. 2.2 The URI condition Some of the YANG-related protocols might have URI constraints, e.g. RESTCONF. For now, we assume either that the JSON-based protocol URI could be conformed to RESTCONF compliant uri, or that the server could have a routing mapping between the protocol compliant uri and the RESTCONF compliant uri, hence this condition would not be an issue, which allows us to focus on the message encoding condition. 3. Proof 3.1. The message encoding condition is necessary. We first note that this condition is a necessary condition for a JSON based protocol to have a syntactically equivalent YANG model by proving its contrapositive. If one of the keys in the key-value pair in the JSON document is not pre-defined, the corresponding XML tags will not be pre-defined keywords. Therefore, it would not possible to model it in YANG without using YANG=E2=80=99s anyxml statement (which allows arbitrary XML content). However, using the anyxml statement would defeat our purpose of modeling the data as it allows arbitrary XML content, and will not be helpful in the subsequent parsing process. 3.2. The message encoding condition is sufficient. We prove this by providing a translation procedure from a JSON message that is compliant with the protocol we are trying to model, to a custom java class that can be used for Jackson data binding, then to a YANG model. We note that the middle step of translating to and from the custom parser class is not necessary, but it will be useful. 3.2.1. motivation JSON data binding is the process of binding data structures (objects, arrays, etc.) in JSON to the appropriate data structures in the server (e.g. java classes, database tables, etc.) in parsing the JSON text. In order to process JSON messages in a meaningful manner, data binding is necessary. Even if the binding is not explicit, the server would need to do it eventually. For example, one can read JSON content in a stream without binding it to the java classes, but eventually in order to make sense of the data, the server would eventually have to organize it, which is roughly analogous to data binding upfront. Popular choices for JSON parsing and data binding include jackson and gson. We use Jackson full data binding as our approach. Full data binding binds JSON content into plain old java objects (POJOs), i.e. this custom parser class can neither extend nor implement any other class. Jackson uses ObjectMapper with the custom parser class to parse JSON content into this class. 3.2.2. The message encoding condition The message encoding condition is that all keys in each key-value pair in the JSON text must be pre-defined keywords. As the keys will become either class names and instance variable names, or be keys in the java maps, it is easy to see that the condition is equivalent to =E2=80=9Cthere exists a ful= l data binding in Jackson custom parser class without using any map structures (Map).=E2=80=9D 3.2.3. Proof We provide a recursive binding process from a JSON object to the Jackson custom parser class to be used by Jackson ObjectMapper. Type determine_type(value) { if (value is of a primitive type, i.e. string, number, boolean, null) { return the corresponding java primitive type; } if (value is a JSON object) { return build_parser_class(value).class; } if (value is an array) { return ArrayList where T=3Ddetermine_type(value[0]); } // should not reach here. } Class build_parser_class(JSONObject obj) { create custom class C; for each key/value pair in the obj { add instance variable v in C; the name of variable v <- key; // (__known__ a/c to our assumption) the type of variable v <- determine_type(value); } return C.class; } Naming: --change everything into CamelCase (i.e. remove dashes, etc.) --for instance variables, use =E2=80=9Cmy=E2=80=9D prefix, (e.g. myVariable= , myNetworkMap, etc.) --for the custom class name, if the object is an element of the array, use =E2=80=9CElement=E2=80=9D suffix. This is just one convention so that the next step proceeds smoothly. As long as this naming translation is consistent with the naming stage in the next step, it will work just fine. Example (a modified ALTO protocol network map example): JSON object: { =E2=80=9Cmeta=E2=80=9D: { =E2=80=9Cresource-id=E2=80=9D: =E2=80=9Cmy-default-map=E2=80=9D, =E2=80=9Ctag=E2=80=9D: =E2=80=9Caab875ef69c87d012=E2=80=9D }, =E2=80=9Cnetwork-map=E2=80=9D: [ { =E2=80=9Csrc=E2=80=9D: =E2=80=9CPID1=E2=80=9D, =E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID1=E2=80=9D, =E2=80=9CPID2=E2=80= =9D, =E2=80=9CPID3=E2=80=9D] }, { =E2=80=9Csrc=E2=80=9D: =E2=80=9CPID2=E2=80=9D, =E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID1=E2=80=9D, =E2=80=9CPID3=E2=80= =9D] }, { =E2=80=9Csrc=E2=80=9D: =E2=80=9CPID3=E2=80=9D, =E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID2=E2=80=9D, =E2=80=9CPID3=E2=80= =9D] } ] } Result of build_parser_class(obj): Class JSONObject { Meta myMeta; ArrayList myNetworkMap; } Class Meta { String myResourceId; String myTag; } Class NetworkMapElement { String mySrc; ArrayList myDsts; } Now given the Jackson Parser Java Class, to get a syntactically equivalent YANG model: YANGModel build_yang_model(Class C) { for each instance variable (Type, Name) { if (Type is primitive type: string, number, boolean, null) { add the following to the YANG module: =E2=80=9Cleaf Name { type ; }=E2=80=9D } if (Type is an ArrayList) { if (TypeElement is primitive type) { add the following to the YANG module: =E2=80=9Cleaf-list Name { type ; }= =E2=80=9D } else { // TypeElement is a custom parser class add the following to the YANG module: =E2=80=9Clist Name { > }=E2=80=9D } } if (Type is a custom parser class) { add the following to the YANG module: =E2=80=9Ccontainer Name { > }= =E2=80=9D } } } Result from the previous example: container meta { leaf resource-id { type string; } leaf tag { type string; } } list network-map { leaf src { type string; } leaf-list dsts { type string; } } This does validate the JSON document with XML-JSON encoding. For your reference, this is the XML document which validates: my-default-map aab875ef69c87d012 PID1 PID1 PID2 PID3 PID2 PID1 PID3 PID3 PID2 PID3 This proves that the message encoding condition is a sufficient condition for the JSON object to have a YANG model. Note the model generated is very crude and lose almost all constraints and all inheritance features (if any), because it focuses on the syntax and is essentially converted from an JSON object compliant with a protocol instead of from the protocol itself. Hence this result is more useful in determining which JSON based protocols cannot have a syntactically equivalent YANG model, than in generating a good YANG model. 3.3. Conclusion Our claim holds. A JSON based protocol carried by HTTP can have syntactically equivalent YANG model, if and only if all the keys in the key-value pairs in the JSON message are pre-defined keywords. 4. Semantic equivalence For JSON based protocols that don=E2=80=99t satisfy the message encoding co= ndition, it is still possible to have a semantically equivalent YANG model. All that is required for the protocol compliant clients and the YANG model compliant server to interoperate is an adapter which does the following: 1) translate FROM YANG server compliant response msg TO alto compliant response msg 2) translate FROM alto compliant request msg TO YANG server compliant request msg 4.1. Claim This adapter needs to be protocol-aware. Ideally, given any YANG model, we would like to be able to automatically (or at least mechanically) generate this message adapter, which means not looking at the protocol or its compliant msgs. However, without knowing the specific protocol that we are working with (i.e. human intervention, i.e. looking at the protocol compliant msgs), such an adapter cannot be auto-generated. 4.2. Proof by Indistinguishability Suppose both the YANG server compliant msg m_y and the actually protocol compliant msg m_p are in JSON (or have been encoded into JSON). Looking at the differences between the two messages, call these differences {d1, d2, ..., dn}. The goal for the auto-generated adapter would be to identify and eliminate these differences. Construct a new JSON msg m' where all but one difference di is the same as m_p and di is the same as the m_y. Without looking at the protocol (or m_p), the auto-generated adapter would not be able to distinguish between m' and m_p in its translation process, which means, it won't be able to tell whether it should change di or not. Hence, such an adapter must be protocol-aware. A good example is the dependent-vtag in the ALTO protocol: "dependent-vtag" : [ { "resource-id" : "my-network-map", "tag" : "abcd1234" } ] It was specified this way in the alto protocol. However, it could conceivably be the case that it was originally the following map structure, and was converted into the above encoding because of the map->list+key issue. (This case is actually one of the few differences in the m_y and m_p where the adapter does not need to convert it back to a map structure.) "dependent-vtag" : { "my-network-map" : { "tag" : "abcd1234" } } Without knowing the protocol, there is no way to tell. 5. Ramifications We now understand the basic condition for a JSON based protocol to have a YANG Model. For the protocols that don=E2=80=99t meet this condition, there= can be a semantic equivalent YANG model, but there won=E2=80=99t be a generic proc= ess of generating the adapter for all such protocols. --001a11c1c058bce7bd0505d480e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

<= span style=3D"font-size:15px;font-family:'Ubuntu Mono';color:rgb(0,= 0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transpar= ent">Hi folks,


As a few of us were working on modeling th= e ALTO protocol using YANG, we were pondering on a more general question: c= an YANG model all JSON based protocols? What is the condition for a JSON ba= sed protocol (at least the message format) to have an syntactically equival= ent, hence interoperable, YANG model with JSON encoding? Alternatively, in = order to interoperate, semantic equivalence might be sufficient, is there a= ny condition for semantic equivalence?


tl;dr: A JSON based protocol carried by HTTP can have synta= ctically equivalent YANG model, if and only if all the keys in the key-valu= e pairs in the JSON message are pre-defined keywords in the protocol.


We've come up with a few ideas, an= d a few things below are work in progress, but we would love your feedback!=


Thank you!

Xiao=


=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

1. Introductio= n.

JavaScript Object Notation (JSON) has been a popular cho= ice as the message encoding for many network protocols such as the Applicat= ion Layer Traffic Optimization (ALTO) protocol, the Content Delivery Networ= ks Interconnection (CDNi) protocol, etc.


Meanwhile, the= re are broad interests in the networking community to use YANG to define da= ta model so that one can use YANG related tools such as OpenDayLight contro= ller. Although YANG itself is XML based, there have been efforts to model J= SON content using YANG [draft-ietf-netmod-yang-json-01].


A natural question rises: can YANG model all JSON based protocols? What = is the condition for a JSON based protocol (at least the message format) to= have an syntactically equivalent, hence interoperable, YANG model with JSO= N encoding? Alternatively, in order to interoperate, semantic equivalence m= ight be sufficient, is there any condition for semantic equivalence?=


2. Claim

A JSON based= protocol carried by HTTP can have syntactically equivalent YANG model, if = and only if:

(1) the message encoding condition is met;

(2) the uri condition is met.


2.1. The mes= sage encoding condition

The JSON message encoding MUST not = contain a variable as a key in a JSON object key-value pair. In other words= , the keys in the JSON message must be an already defined constant (or keyw= ord) in the message format of the protocol.


For example= , if I have a protocol where =E2=80=9Cnetwork-map=E2=80=9D, =E2=80=9Csrc=E2= =80=9D, and =E2=80=9Cdsts=E2=80=9D are defined keywords, JSON text A meets = the condition whereas B does not because =E2=80=9CPID1=E2=80=9D and =E2=80= =9CPID2=E2=80=9D are not protocol keywords (they are resource IDs).<= /p>

A:

{

=C2=A0=E2=80=9Cnetwork-map= =E2=80=9D: [

=C2=A0=C2=A0=C2=A0{

=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=E2=80=9Csrc=E2=80=9D: =E2=80=9CPID1=E2=80=9D,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=E2=80=9Cdsts=E2=80=9D: [=E2=80= =9CPID2=E2=80=9D, =E2=80=9CPID3=E2=80=9D]

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

=C2=A0=C2=A0=C2=A0{

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=E2=80=9Csrc=E2=80=9D: =E2=80=9CPID2=E2=80=9D,

=

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID3= =E2=80=9D, =E2=80=9CPID4=E2=80=9D]

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

=C2=A0]

}

B:


{

=C2=A0=E2=80=9Cnetwork-map=E2=80=9D: [

=C2=A0=C2=A0=C2=A0=E2=80=9CPID1: [=E2=80=9CPID2=E2=80=9D, =E2=80=9C= PID3=E2=80=9D],

=C2=A0=C2=A0=C2=A0=E2=80=9CPID2=E2=80=9D: = [=E2=80=9CPID3=E2=80=9D, =E2=80=9CPID4=E2=80=9D]

=C2=A0]

}


From this we know that since ALTO prot= ocol uses encoding B, there cannot be a syntactically equivalent YANG model= .


2.2 The URI condition

Some of the YA= NG-related protocols might have URI constraints, e.g. RESTCONF. For now, we= assume either that the JSON-based protocol URI could be conformed to RESTC= ONF compliant uri, or that the server could have a routing mapping between = the protocol compliant uri and the RESTCONF compliant uri, hence this condi= tion would not be an issue, which allows us to focus on the message encodin= g condition.


3. Proof

3.1. The message = encoding condition is necessary.

We first note that this co= ndition is a necessary condition for a JSON based protocol to have a syntac= tically equivalent YANG model by proving its contrapositive.


=

= If one of the keys in the key-value pair in the JSON document is not = pre-defined, the corresponding XML tags will not be pre-defined keywords. T= herefore, it would not possible to model it in YANG without using YANG=E2= =80=99s anyxml statement (which = allows arbitrary XML content).


However, using the anyxm= l statement would defeat our purpose of modeling the data as it allows arbi= trary XML content, and will not be helpful in the subsequent parsing proces= s.


3.2. The message encoding condition is sufficient.

We prove this by providing a translation procedure from a JS= ON message that is compliant with the protocol we are trying to model, to a= custom java class that can be used for Jackson data binding, then to a YAN= G model.


We note that the middle step of translating to= and from the custom parser class is not necessary, but it will be useful.<= /span>


3.2.1. motivation

JSON data binding is = the process of binding data structures (objects, arrays, etc.) in JSON to t= he appropriate data structures in the server (e.g. java classes, database t= ables, etc.) in parsing the JSON text. In order to process JSON messages in= a meaningful manner, data binding is necessary. Even if the binding is not= explicit, the server would need to do it eventually. For example, one can = read JSON content in a stream without binding it to the java classes, but e= ventually in order to make sense of the data, the server would eventually h= ave to organize it, which is roughly analogous to data binding upfront. Pop= ular choices for JSON parsing and data binding include jackson and gson.


We use Jackson full data binding as our approach. Full da= ta binding binds JSON content into plain old java objects (POJOs), i.e. thi= s custom parser class can neither extend nor implement any other class. Jac= kson uses ObjectMapper with the custom parser class to parse JSON content i= nto this class.


3.2.2. The message encoding condition

The message encoding condition is that all keys in each key-= value pair in the JSON text must be pre-defined keywords. As the keys will = become either class names and instance variable names, or be keys in the ja= va maps, it is easy to see that the condition is equivalent to =E2=80=9Cthe= re exists a full data binding in Jackson custom parser class without using = any map structures (Map<String, ?>).=E2=80=9D


= 3.2.3. Proof

We provide a recursive binding process from a = JSON object to the Jackson custom parser class to be used by Jackson Object= Mapper.


Type determine_type(value) {

= =C2=A0if (value is of a primitive type, i.e. string, number, boolean, null= ) {

=C2=A0=C2=A0=C2=A0return the corresponding java primit= ive type;

=C2=A0}

=C2=A0if (value is a JS= ON object) {

=C2=A0=C2=A0=C2=A0return build_parser_class(v= alue).class;

=C2=A0}

=C2=A0if (value is a= n array) {

=C2=A0=C2=A0=C2=A0return ArrayList<T> whe= re T=3Ddetermine_type(value[0]);

=C2=A0}

= =C2=A0// should not reach here.

}


Clas= s build_parser_class(JSONObject obj) {

=C2=A0create custom= class C;

=C2=A0for each key/value pair in the obj {

=C2=A0=C2=A0=C2=A0add instance variable v in C;

=C2=A0=C2=A0=C2=A0the name of variable v <- key; // (__known__ a/c to= our assumption)

=C2=A0=C2=A0=C2=A0the type of variable v = <- determine_type(value);

=C2=A0}

=C2= =A0return C.class;

}


Naming:

=

= --change everything into CamelCase (i.e. remove dashes, etc.)<= /p>

--for instance variables, use =E2=80=9Cmy=E2=80=9D prefix, (e.g. m= yVariable, myNetworkMap, etc.)

--for the custom class name,= if the object is an element of the array, use =E2=80=9CElement=E2=80=9D su= ffix.


This is just one convention so that the next step= proceeds smoothly. As long as this naming translation is consistent with t= he naming stage in the next step, it will work just fine.


Example (a modified ALTO prot= ocol network map example):

JSON object:

{

=C2=A0=E2=80=9Cm= eta=E2=80=9D: {

=C2=A0=C2=A0=C2=A0=E2=80=9Cresource-id=E2= =80=9D: =E2=80=9Cmy-default-map=E2=80=9D,

=C2=A0=C2=A0=C2= =A0=E2=80=9Ctag=E2=80=9D: =E2=80=9Caab875ef69c87d012=E2=80=9D

=C2=A0},

=C2=A0=E2=80=9Cnetwork-map=E2=80=9D: [=

=C2=A0=C2=A0=C2=A0{

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=E2=80=9Csrc=E2=80=9D: =E2=80=9CPID1=E2=80=9D,

=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID1=E2=80=9D, = =E2=80=9CPID2=E2=80=9D, =E2=80=9CPID3=E2=80=9D]

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

=C2=A0=C2=A0=C2=A0{

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=E2=80=9Csrc=E2=80=9D: =E2=80=9CPID2=E2=80=9D,<= /p>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=E2=80=9Cdsts=E2=80=9D: [=E2=80=9CP= ID1=E2=80=9D, =E2=80=9CPID3=E2=80=9D]

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

=C2=A0=C2=A0=C2=A0{

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=E2=80=9Csrc=E2=80=9D: =E2=80=9CPID3=E2=80=9D,

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID2=E2=80= =9D, =E2=80=9CPID3=E2=80=9D]

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

=C2=A0]

}


Result of build_parse= r_class(obj):

Class JSONObject {

=C2=A0Met= a myMeta;

=C2=A0ArrayList<NetworkMapElement> myNetwo= rkMap;

}

Class Meta {

=C2= =A0String myResourceId;

=C2=A0String myTag;

}

Class NetworkMapElement {

=C2=A0String= mySrc;

=C2=A0ArrayList<String> myDsts;

}


Now given the Jackson Parser Java Class, to get a= syntactically equivalent YANG model:

YANGModel build_yang_= model(Class C) {

=C2=A0for each instance variable (Type, N= ame) {

=C2=A0=C2=A0=C2=A0if (Type is primitive type: strin= g, number, boolean, null) {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= add the following to the YANG module:

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=E2=80=9Cleaf Name { type <YANG equivalent of Type>; }=E2= =80=9D

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

=C2=A0=C2=A0= =C2=A0if (Type is an ArrayList<TypeElement>) {

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0if (TypeElement is primitive type) {

<= p dir=3D"ltr" style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:15px;font-family:'Ubuntu Mono';color:rgb(0,= 0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transpar= ent"> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0add the following to the YA= NG module:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=E2= =80=9Cleaf-list Name { type <YANG equivalent of TypeElement>; }=E2=80= =9D

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0} else {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0// TypeElement is a custom pars= er class

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0add the= following to the YANG module:

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=E2=80=9Clist Name { <result from build_yang_model<Typ= eElement.class>> }=E2=80=9D

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

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

=C2=A0=C2=A0= =C2=A0if (Type is a custom parser class) {

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0add the following to the YANG module:

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=E2=80=9Ccontainer Name { <result from bui= ld_yang_model<Type.class>> }=E2=80=9D =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0

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

=C2= =A0}

}


Result from the previous example= :

container meta {

=C2=A0leaf resource-id = {

=C2=A0=C2=A0=C2=A0type string;

=C2=A0}<= /span>

=C2=A0leaf tag {

=C2=A0=C2=A0=C2=A0type s= tring;

=C2=A0}

}

list netw= ork-map {

=C2=A0leaf src {

=C2=A0=C2=A0= =C2=A0type string;

=C2=A0}

=C2=A0leaf-li= st dsts {

=C2=A0=C2=A0=C2=A0type string;

= =C2=A0}

}


This does validate the JSON = document with XML-JSON encoding. For your reference, this is the XML docume= nt which validates:

<?xml version=3D"1.0" enco= ding=3D"UTF-8" ?>

<meta>

=C2=A0<resource-id>my-default-map</resource-id>

=C2=A0<tag>aab875ef69c87d012</tag>

</met= a>

<network-map>

=C2=A0<src>= ;PID1</src>

=C2=A0<dsts>PID1</dsts>

=C2=A0<dsts>PID2</dsts>

=C2=A0<= ;dsts>PID3</dsts>

</network-map>

<= p dir=3D"ltr" style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:15px;font-family:'Ubuntu Mono';color:rgb(0,= 0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transpar= ent"><network-map>

=C2=A0<src>PID2</src>=

=C2=A0<dsts>PID1</dsts>

=C2= =A0<dsts>PID3</dsts>

</network-map>

<network-map>

=C2=A0<src>PID3</s= rc>

=C2=A0<dsts>PID2</dsts>

=C2=A0<dsts>PID3</dsts>

</network-map><= /span>


This proves that the message encoding condition is a su= fficient condition for the JSON object to have a YANG model.


=

= Note the model generated is very crude and lose almost all constraint= s and all inheritance features (if any), because it focuses on the syntax a= nd is essentially converted from an JSON object compliant with a protocol i= nstead of from the protocol itself. Hence this result is more useful in det= ermining which JSON based protocols cannot have a syntactically equivalent = YANG model, than in generating a good YANG model.


3.3. = Conclusion

Our claim holds. A JSON based protocol carried b= y HTTP can have syntactically equivalent YANG model, if and only if all the= keys in the key-value pairs in the JSON message are pre-defined keywords.<= /span>


4. Semantic equivalence

For JSON based= protocols that don=E2=80=99t satisfy the message encoding condition, it is= still possible to have a semantically equivalent YANG model. All that is r= equired for the protocol compliant clients and the YANG model compliant ser= ver to interoperate is an adapter which does the following:


<= p dir=3D"ltr" style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:15px;font-family:'Ubuntu Mono';color:rgb(0,= 0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transpar= ent">1) translate FROM YANG server compliant response msg TO alto compliant= response msg

2) translate FROM alto compliant request msg = TO YANG server compliant request msg


4.1. Claim<= /p>

This adapter needs to be protocol-aware.


Ideal= ly, given any YANG model, we would like to be able to automatically (or at = least mechanically) generate this message adapter, which means not looking = at the protocol or its compliant msgs. However, without knowing the specifi= c protocol that we are working with (i.e. human intervention, i.e. looking = at the protocol compliant msgs), such an adapter cannot be auto-generated.<= /span>


4.2. Proof by Indistinguishability

Supp= ose both the YANG server compliant msg m_y and the actually protocol compli= ant msg m_p are in JSON (or have been encoded into JSON). Looking at the di= fferences between the two messages, call these differences {d1, d2, ..., dn= }. The goal for the auto-generated adapter would be to identify and elimina= te these differences. Construct a new JSON msg m' where all but one dif= ference di is the same as m_p and di is the same as the m_y. Without lookin= g at the protocol (or m_p), the auto-generated adapter would not be able to= distinguish between m' and m_p in its translation process, which means= , it won't be able to tell whether it should change di or not. Hence, s= uch an adapter must be protocol-aware.


A good example= is the dependent-vtag in the ALTO protocol:

"dependen= t-vtag" : [

=C2=A0{

=C2=A0=C2=A0=C2= =A0"resource-id" : "my-network-map",

= =C2=A0=C2=A0=C2=A0"tag" : "abcd1234"

= =C2=A0}

]


It was specified this way in= the alto protocol. However, it could conceivably be the case that it was o= riginally the following map structure, and was converted into the above enc= oding because of the map->list+key issue. (This case is actually one of = the few differences in the m_y and m_p where the adapter does not need to c= onvert it back to a map structure.)

"dependent-vtag&qu= ot; : {

=C2=A0"my-network-map" : {

=C2=A0=C2=A0=C2=A0"tag" : "abcd1234"

=C2=A0}

}


Without knowing the protoc= ol, there is no way to tell.


5. Ramifications

We now understand the basic condition for a JSON based protocol to = have a YANG Model. For the protocols that don=E2=80=99t meet this condition= , there can be a semantic equivalent YANG model, but there won=E2=80=99t be= a generic process of generating the adapter for all such protocols.=


--001a11c1c058bce7bd0505d480e7-- From nobody Mon Oct 20 03:56:06 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B81E11A82E2 for ; Mon, 20 Oct 2014 03:56:04 -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 o8kioR2SOiTi for ; Mon, 20 Oct 2014 03:56:02 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EF381A8030 for ; Mon, 20 Oct 2014 03:56:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id E7BE7540A2A; Mon, 20 Oct 2014 12:55:58 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WX7hiWG3RPeG; Mon, 20 Oct 2014 12:55:54 +0200 (CEST) Received: from localhost (unknown [195.113.220.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 2151C5401C2; Mon, 20 Oct 2014 12:55:53 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman , "netmod\@ietf.org" In-Reply-To: References: User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Mon, 20 Oct 2014 12:55:52 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/fl-oEmnFi-sLS-HiuH0JGJ1zRP8 Subject: Re: [netmod] YANG Metadata Issue: leaf-list X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 20 Oct 2014 10:56:04 -0000 Andy Bierman writes: > Hi, > > I have run into some issues implementing > draft-lhotka-netmod-yang-metadata-00. > > (1) The annotations for leaf-list nodes are expensive to implement in > a constrained or streaming-based server. Every other node type > is easy to stream because all the data can be rendered before > moving on to the next node. But the leaf-list meta-data follows > all the leaf-list nodes: > > For example, in the following leaf-list instance with four entries, > the "inactive" annotation is added to the second and third entry in > the following way: > > "folio": [6, 3, 7, 8], > "@folio": [ > null, > {"example-inactive:inactive": true}, > {"example-inactive:inactive": true} > ] > > The server has to remember a lot of state and/or go through the leaf-list > twice. It is possible that the last node is gone and the next node is > unknown in a streaming server, This could take a lot of resources > for large leaf-lists. Do you have an alternative proposal? This encoding has an advantage that the receiving party may just ignore the annotation and nothing alse changes. If we somehow bundle annotations with each leaf-list entry, it will be no more the case. > > (2) The module-name as prefix is not really needed unless > there are annotations with the same name advertised by the server. This is true but if the namespace encoding is mandatory, the instance document needn't change as a side-effect of adding a new module to the data model. I think this is important because it it not only the server that potentially adds annotations. If an old client that only knows about one "foo" annotation always uses the namespace id, it can then safely ignore a new module advertised by the server, even if it defines a new annotation with colliding name. > > (3) Multiple annotations can be rendered in any order within an array entry: > This should be clarified (and maybe an example). I think this follows from the fact that JSON objects are unordered by definition. So the annotation object may precede or follow the annotated member, and also the order of its members is undefined. > > "folio": [6, 3, 7, 8], > "@folio": [ > null, > {"example-inactive:inactive": true, > "example:foo":42 }, > {"example:foo":53, > example-inactive:inactive": true} > ] > > > Andy Lada > _______________________________________________ > 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 Oct 20 04:18:25 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA0B71A86E8 for ; Mon, 20 Oct 2014 04:18: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 6cbYYG0gnE6d for ; Mon, 20 Oct 2014 04:18:21 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C6B11A7022 for ; Mon, 20 Oct 2014 04:18:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id D85AE540A2A; Mon, 20 Oct 2014 13:18:19 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HB1GHSE8I8CR; Mon, 20 Oct 2014 13:18:14 +0200 (CEST) Received: from localhost (unknown [195.113.220.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 57EC1540A28; Mon, 20 Oct 2014 13:18:14 +0200 (CEST) From: Ladislav Lhotka To: "William Lupton \(wilupton\)" , "netmod\@ietf.org" In-Reply-To: References: User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Mon, 20 Oct 2014 13:18:12 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/GDFo52M2QyWP3MazBZJLV_K5FSQ Subject: Re: [netmod] Mandatory and optional ranges X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 20 Oct 2014 11:18:24 -0000 "William Lupton (wilupton)" writes: > Thanks. Would there be any appetite for permitting the feature approach > (it would need to be understood that multiple "range" statements are ORd)? > > leaf WWW { > type uint8 { > range "1..1" { > if-feature A; > } > range "2..2" { > if-feature B; > } > } > } > > leaf XXX { > type uint8 { > range "1..10" { > if-feature A; > } > range "11..20" { > if-feature B; > } > } > } This is different from the enum case below. Features A and B needn't be mutually exclusive, and if both are active the data model would be ambiguous. For enums it is not the case because they are additive. The same is true for bits and identities. So I don't think your proposal is a simple extension of issue #11. Do you think a choice won't work for your use case? Lada > > Compare the above with > http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-11, which > also mentions "choice" as an option, and includes this example: > > type enumeration { > enum tcp; > enum ssh { > if-feature ssh; > } > enum tls { > if-feature tls; > } > } > > > Cheers, > William > > On 16/10/2014 15:11, "Ladislav Lhotka" wrote: > >>Hello William, >> >>"William Lupton (wilupton)" writes: >> >>> All, >>> >>> Someone asked me whether a YANG definition can distinguish the parts of >>>a >>> range that are mandatory and the parts that are optional, e.g an int >>>leaf >>> XXX might be required to support 1..10 but 11..20 might be optional. It >>> seems that being able to associate 11..20 with a feature would be a nice >>> solution and would be equivalent to YANG 1.1 Y11 (allow if-feature on >>> enums)? But I don't think that range "1..10|11..20" can be split into >>> multiple range statements, so this would not be trivial? >>> >>> A use case from the DSL world (I can't be too specific) is where the >>>valid >>> values for two leaf nodes are coupled. If leaf WWW = 1 then XXX = 1..10 >>> but if leaf WWW = 2 then XXX = 11..20. A future module version might >>>add >>> WWW = 3 and tie it to XXX = 21..30. >>> >>> I suppose that a "must" statement could be used (?) but I quite like the >>> feature approach, especially given the analogy with YANG 1.1 Y11. >> >>This could be solved by defining a choice with one case for each >>variant. A must or when statement can then indeed be used for making >>sure that each case only applies when WWW has the corresponding value. >> >>Something like >> >>choice XXX { >> leaf XXX1 { >> must "../WWW = 1"; >> type uint8 { >> range "1..10"; >> } >> } >> leaf XXX2 { >> must "../WWW = 2"; >> type uint8 { >> range "11..20"; >> } >> } >>} >> >>Also, you can make a case conditional by using if-feature. >> >>Hope this helps, >> >>Lada >> >> >>> >>> Comments? >>> >>> Thanks, >>> William Lupton >>> >>> _______________________________________________ >>> 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 Oct 20 04:25:44 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D19751A86EF for ; Mon, 20 Oct 2014 04:25:42 -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 PvNGokrGamm7 for ; Mon, 20 Oct 2014 04:25:40 -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 99E111A7022 for ; Mon, 20 Oct 2014 04:25:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3854; q=dns/txt; s=iport; t=1413804340; x=1415013940; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=A2IrPYDDZUcxIDBbqZixoF3BFN2+mwyhcz5lT7MqRyU=; b=J6AMxGcgtgeMdPOdxiwIDF9djowZBtnh/V0o5VHwDpqGamCwExlmuPx4 UmLEk5gX6FoMj4AzqOEam5UL5IcJUcwk5Ikbk1IgO0e4EtjLbI8q2ILNL qRIpEgJUFJuUoTVSoXu4uQgBguXXijvGMA3Py1AyOQ2FWl21ymD9h2LKp k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAGPwRFStJA2N/2dsb2JhbABcgmsjU1zMGgqGeVQCgRAWAX2EAwEBBAEBATc0GwIBCBgeECcLJQIEARIbiCQBDMI4AQEBAQEBBAEBAQEBARyOB4IXOoRLBZIAhEaHE4EwkHGEAYN3bAEBAYFFgQMBAQE X-IronPort-AV: E=Sophos;i="5.04,755,1406592000"; d="scan'208";a="364728578" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-5.cisco.com with ESMTP; 20 Oct 2014 11:25:40 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s9KBPdVh026194 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Oct 2014 11:25:39 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Mon, 20 Oct 2014 06:25:39 -0500 From: "William Lupton (wilupton)" To: Ladislav Lhotka , "netmod@ietf.org" Thread-Topic: [netmod] Mandatory and optional ranges Thread-Index: AQHP3ih3IT74Ah1ZGECTWzsVHNUgK5wzLcaAgAE784CABNzZAIAAEtSA Date: Mon, 20 Oct 2014 11:25:39 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [10.55.121.115] Content-Type: text/plain; charset="us-ascii" Content-ID: <381A625D626413448500071E4997762C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/IYRN8P2ROQeJzz4yMw2WE9j7Upc Subject: Re: [netmod] Mandatory and optional ranges X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 20 Oct 2014 11:25:43 -0000 I didn't assume that features A and B were mutually exclusive. I also don't see that there would be a problem even if the ranges overlapped. The actual supported range would simply be the union of the per-feature ranges. What is the ambiguity? Thanks, W. On 20/10/2014 12:18, "Ladislav Lhotka" wrote: >"William Lupton (wilupton)" writes: > >> Thanks. Would there be any appetite for permitting the feature approach >> (it would need to be understood that multiple "range" statements are >>ORd)? >> >> leaf WWW { >> type uint8 { >> range "1..1" { >> if-feature A; >> } >> range "2..2" { >> if-feature B; >> } >> } >> } >> >> leaf XXX { >> type uint8 { >> range "1..10" { >> if-feature A; >> } >> range "11..20" { >> if-feature B; >> } >> } >> } > >This is different from the enum case below. Features A and B needn't be >mutually exclusive, and if both are active the data model would be >ambiguous. For enums it is not the case because they are additive. The >same is true for bits and identities. > >So I don't think your proposal is a simple extension of issue #11. Do >you think a choice won't work for your use case? > >Lada >=20 > >> >> Compare the above with >> http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-11, >>which >> also mentions "choice" as an option, and includes this example: >> >> type enumeration { >> enum tcp; >> enum ssh { >> if-feature ssh; >> } >> enum tls { >> if-feature tls; >> } >> } >> >> >> Cheers, >> William >> >> On 16/10/2014 15:11, "Ladislav Lhotka" wrote: >> >>>Hello William, >>> >>>"William Lupton (wilupton)" writes: >>> >>>> All, >>>> >>>> Someone asked me whether a YANG definition can distinguish the parts >>>>of >>>>a >>>> range that are mandatory and the parts that are optional, e.g an int >>>>leaf >>>> XXX might be required to support 1..10 but 11..20 might be optional. >>>>It >>>> seems that being able to associate 11..20 with a feature would be a >>>>nice >>>> solution and would be equivalent to YANG 1.1 Y11 (allow if-feature on >>>> enums)? But I don't think that range "1..10|11..20" can be split into >>>> multiple range statements, so this would not be trivial? >>>> >>>> A use case from the DSL world (I can't be too specific) is where the >>>>valid >>>> values for two leaf nodes are coupled. If leaf WWW =3D 1 then XXX =3D >>>>1..10 >>>> but if leaf WWW =3D 2 then XXX =3D 11..20. A future module version mi= ght >>>>add >>>> WWW =3D 3 and tie it to XXX =3D 21..30. >>>> >>>> I suppose that a "must" statement could be used (?) but I quite like >>>>the >>>> feature approach, especially given the analogy with YANG 1.1 Y11. >>> >>>This could be solved by defining a choice with one case for each >>>variant. A must or when statement can then indeed be used for making >>>sure that each case only applies when WWW has the corresponding value. >>> >>>Something like >>> >>>choice XXX { >>> leaf XXX1 { >>> must "../WWW =3D 1"; >>> type uint8 { >>> range "1..10"; >>> } >>> } >>> leaf XXX2 { >>> must "../WWW =3D 2"; >>> type uint8 { >>> range "11..20"; >>> } >>> } >>>} >>> >>>Also, you can make a case conditional by using if-feature. >>> >>>Hope this helps, >>> >>>Lada >>>=20 >>> >>>> >>>> Comments? >>>> >>>> Thanks, >>>> William Lupton >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>> >>>--=20 >>>Ladislav Lhotka, CZ.NIC Labs >>>PGP Key ID: E74E8C0C >> > >--=20 >Ladislav Lhotka, CZ.NIC Labs >PGP Key ID: E74E8C0C From nobody Mon Oct 20 04:47:36 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F561A86EC for ; Mon, 20 Oct 2014 04:47:35 -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 iL7QDgORI6Be for ; Mon, 20 Oct 2014 04:47:33 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1370F1A6FED for ; Mon, 20 Oct 2014 04:47:32 -0700 (PDT) Received: from [192.168.1.108] (unknown [195.113.220.254]) by mail.nic.cz (Postfix) with ESMTPSA id 93E691405A5; Mon, 20 Oct 2014 13:47:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1413805650; bh=D/vA+Q9/wdvmcxzxMZYUqmk5IzLqinryYO5PPhAAlEo=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=GnZlhc7b/hrdh+PXAjoKmbTVh7XEEVlvv0inWLwlWmKS3NOVRSuwIO0o21Io6kfD/ jhMtbtqPLiEPU/0RgBuSGlrjt7DShvi/I9pahfKu2uehRdjYfAwvYjoqD33X+UdN/t NJt2bGFdqrNtm7U9knvje7G96yFgXP4YJtMjKeQY= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 20 Oct 2014 13:47:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "William Lupton (wilupton)" X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/TnAvnB-Ih2bWOAhb2-TmbdKnkEo Cc: "netmod@ietf.org" Subject: Re: [netmod] Mandatory and optional ranges X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 20 Oct 2014 11:47:35 -0000 On 20 Oct 2014, at 13:25, William Lupton (wilupton) = wrote: > I didn't assume that features A and B were mutually exclusive. I also > don't see that there would be a problem even if the ranges overlapped. > The actual supported range would simply be the union of the = per-feature > ranges. What is the ambiguity? Thanks, W. Currently the =93range=94 statement can appear only once, and sec. 9.2.4 = in RFC 6020 contains several restrictions - the ranges separated by | = must be disjoint and appear in ascending order. Maybe these restrictions are in the spec only to make parsing easier but = accepting your proposal would essentially mean to get rid of these = restrictions in the first place. Lada=20 >=20 > On 20/10/2014 12:18, "Ladislav Lhotka" wrote: >=20 >> "William Lupton (wilupton)" writes: >>=20 >>> Thanks. Would there be any appetite for permitting the feature = approach >>> (it would need to be understood that multiple "range" statements are >>> ORd)? >>>=20 >>> leaf WWW { >>> type uint8 { >>> range "1..1" { >>> if-feature A; >>> } >>> range "2..2" { >>> if-feature B; >>> } >>> } >>> } >>>=20 >>> leaf XXX { >>> type uint8 { >>> range "1..10" { >>> if-feature A; >>> } >>> range "11..20" { >>> if-feature B; >>> } >>> } >>> } >>=20 >> This is different from the enum case below. Features A and B needn't = be >> mutually exclusive, and if both are active the data model would be >> ambiguous. For enums it is not the case because they are additive. = The >> same is true for bits and identities. >>=20 >> So I don't think your proposal is a simple extension of issue #11. Do >> you think a choice won't work for your use case? >>=20 >> Lada >>=20 >>=20 >>>=20 >>> Compare the above with >>> http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-11, >>> which >>> also mentions "choice" as an option, and includes this example: >>>=20 >>> type enumeration { >>> enum tcp; >>> enum ssh { >>> if-feature ssh; >>> } >>> enum tls { >>> if-feature tls; >>> } >>> } >>>=20 >>>=20 >>> Cheers, >>> William >>>=20 >>> On 16/10/2014 15:11, "Ladislav Lhotka" wrote: >>>=20 >>>> Hello William, >>>>=20 >>>> "William Lupton (wilupton)" writes: >>>>=20 >>>>> All, >>>>>=20 >>>>> Someone asked me whether a YANG definition can distinguish the = parts >>>>> of >>>>> a >>>>> range that are mandatory and the parts that are optional, e.g an = int >>>>> leaf >>>>> XXX might be required to support 1..10 but 11..20 might be = optional. >>>>> It >>>>> seems that being able to associate 11..20 with a feature would be = a >>>>> nice >>>>> solution and would be equivalent to YANG 1.1 Y11 (allow if-feature = on >>>>> enums)? But I don't think that range "1..10|11..20" can be split = into >>>>> multiple range statements, so this would not be trivial? >>>>>=20 >>>>> A use case from the DSL world (I can't be too specific) is where = the >>>>> valid >>>>> values for two leaf nodes are coupled. If leaf WWW =3D 1 then XXX = =3D >>>>> 1..10 >>>>> but if leaf WWW =3D 2 then XXX =3D 11..20. A future module = version might >>>>> add >>>>> WWW =3D 3 and tie it to XXX =3D 21..30. >>>>>=20 >>>>> I suppose that a "must" statement could be used (?) but I quite = like >>>>> the >>>>> feature approach, especially given the analogy with YANG 1.1 Y11. >>>>=20 >>>> This could be solved by defining a choice with one case for each >>>> variant. A must or when statement can then indeed be used for = making >>>> sure that each case only applies when WWW has the corresponding = value. >>>>=20 >>>> Something like >>>>=20 >>>> choice XXX { >>>> leaf XXX1 { >>>> must "../WWW =3D 1"; >>>> type uint8 { >>>> range "1..10"; >>>> } >>>> } >>>> leaf XXX2 { >>>> must "../WWW =3D 2"; >>>> type uint8 { >>>> range "11..20"; >>>> } >>>> } >>>> } >>>>=20 >>>> Also, you can make a case conditional by using if-feature. >>>>=20 >>>> Hope this helps, >>>>=20 >>>> Lada >>>>=20 >>>>=20 >>>>>=20 >>>>> Comments? >>>>>=20 >>>>> Thanks, >>>>> William Lupton >>>>>=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 >>>=20 >>=20 >> --=20 >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Oct 20 06:09:23 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04BA11A8725 for ; Mon, 20 Oct 2014 06:09:18 -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 2Rju2hKfISbG for ; Mon, 20 Oct 2014 06:09:16 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BC1B1A8733 for ; Mon, 20 Oct 2014 06:09:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6903; q=dns/txt; s=iport; t=1413810552; x=1415020152; h=from:to:cc:subject:date:message-id:mime-version; bh=8oRSRj8/cHpERXLgZNaB2bo31OnOYoe4UcblyOX4RIQ=; b=dVtH08beMfGHcxRT9AiC6/xQ2q+zbfok46eu73pBVp/XzcUlEWrWMAYf 4ES7pbEdNQ3yRZd7nDYEFd/eP/spP6tF9rpMebi7FrUQldf0fG1KjuAnZ Aynw5YAYu0IP0gPAmtcCL5zfTX2UuDioognani10UlCMokXfGp56gQIVI 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8GAEoIRVStJA2D/2dsb2JhbABcgkhGgS/TdIETFgFyC4QDAgRyBxIBCHgnBA6IRMNrAQEBAQEFAQEBAQEBAQEakFGEUgWSAItZgTCQcYQBg3eCNIEDAQEB X-IronPort-AV: E=Sophos; i="5.04,756,1406592000"; d="scan'208,217"; a="88613660" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-5.cisco.com with ESMTP; 20 Oct 2014 13:09:11 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s9KD9BT3032125 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Oct 2014 13:09:11 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.151]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Mon, 20 Oct 2014 08:09:11 -0500 From: "Dana Blair (dblair)" To: "yangang@huawei.com" Thread-Topic: Some comments about ACL YANG model. Thread-Index: AQHP7GcJNvv6hgwmVkSOGKo7BQmMmQ== Date: Mon, 20 Oct 2014 13:09:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.21.117.2] Content-Type: multipart/alternative; boundary="_000_D06A81B321962Edblairciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/BlAfO3cjOZtPIm-ugjxSfE8nB4g Cc: "netmod@ietf.org" Subject: Re: [netmod] Some comments about ACL 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: Mon, 20 Oct 2014 13:09:18 -0000 --_000_D06A81B321962Edblairciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The draft authors met and here is the response. Look for DLB: The comments mention compilable option which means the proposal compiles wi= th pyang --ietf option. Hi, I am reviewing the ACL YANG model. And I got some doubts, maybe somebody ca= n help me to understand it. 1. There is one field: targets. In my understanding, maybe it is used = to record who reference this ACL. I don=92t know if Is it mandatory or not.= Or my understanding is wrong. DLB: Your understand is correct. It=92s not mandatory. To move beyond j= ust using string, we need a compilable augmentation. Since ACLs can be applied to interfaces, that might be a good place to start. 2. In packet-fields module, It looks the current definition is not so = sufficient. For example, no "!=3D" definition, and no mask in acl-ipv4-head= er-fields group, etc=85.. DLB: no =93not=94 definition. This is a good catch. Feel free to propos= e an augmentation or change to the existing model. 3. In this draft, there is acl-type and ace-type. It looks the IP pack= et match and Ethernet packet match can be configured together. But it looks= only "OR" relationship is at there, no "AND" relationship. DLB: What kind of =93AND=94 relationship are you expecting ? thanks, Dana Blair Thanks Yangang --_000_D06A81B321962Edblairciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <941D7F300B56664EBC54EC3D5CDF3B67@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

The draft authors met and here is the response. &nbs= p;Look for DLB:

The comments mention compilable option which means t= he proposal compiles with pyang --ietf option.


Hi, =

&nbs= p;

I am= reviewing the ACL YANG model. And I got some doubts, maybe somebody can he= lp me to understand it.

&nbs= p;

1.      There is one = field: targets. In my understanding, maybe it is used to record who referen= ce this ACL. I don=92t know if Is it mandatory or not. Or my understanding = is wrong.


DLB:=  Your understand is correct.  It=92s not mandatory.   To mo= ve beyond just using string, we need a compilable augmentation.  Since= ACLs can be

appl= ied to interfaces, that might be a good place to start.    

&nbs= p;

2.      In packet-fie= lds module, It looks the current definition is not so sufficient. For examp= le, no "!=3D" definition, and no mask in acl-ipv4-header-fields g= roup, etc=85..

DLB:  no =93not=94 def= inition.   This is a good catch.  Feel free to propose an augment= ation or change to the existing model.


3.      In this draft= , there is acl-type and ace-type. It looks the IP packet match and Ethernet= packet match can be configured together. But it looks only "OR" = relationship is at there, no "AND" relationship.

DLB:     What kin= d of =93AND=94 relationship are you expecting ?


thanks,

Dana Blair



&nbs= p;

Than= ks

Yang= ang

--_000_D06A81B321962Edblairciscocom_-- From nobody Mon Oct 20 06:25:24 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8F171A880E; Mon, 20 Oct 2014 06:25:20 -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 BkzRoUrwguqv; Mon, 20 Oct 2014 06:25:14 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C22971A878C; Mon, 20 Oct 2014 06:23:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id E7B42540A2A; Mon, 20 Oct 2014 15:23:17 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWefBbk6l6rr; Mon, 20 Oct 2014 15:23:08 +0200 (CEST) Received: from localhost (unknown [195.113.220.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 5FFC5540A28; Mon, 20 Oct 2014 15:23:07 +0200 (CEST) From: Ladislav Lhotka To: Xiao SHI , IETF ALTO , "netmod\@ietf.org" In-Reply-To: References: User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Mon, 20 Oct 2014 15:23:07 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/WfGSKSD4WE-Khm7XBiAlPgHqjVM Subject: Re: [netmod] Modeling JSON based protocols using YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 20 Oct 2014 13:25:20 -0000 Xiao SHI writes: > Hi folks, > > > As a few of us were working on modeling the ALTO protocol using YANG, we > were pondering on a more general question: can YANG model all JSON based > protocols? What is the condition for a JSON based protocol (at least the > message format) to have an syntactically equivalent, hence interoperable, > YANG model with JSON encoding? Alternatively, in order to interoperate, > semantic equivalence might be sufficient, is there any condition for > semantic equivalence? > > > tl;dr: A JSON based protocol carried by HTTP can have syntactically > equivalent YANG model, if and only if all the keys in the key-value pairs > in the JSON message are pre-defined keywords in the protocol. > Generating a YANG data model from existing instance data seems backwards to me, although Examplotron (http://examplotron.org) does something quite similar. In any case, it might be quite challenging because YANG isn't intended as a general schema language. Your observation above is true but it is just one aspect of the problem. For instance "foo": [ { "bar": 1 }, 2 ] or "foo": null cannot be modelled in YANG using the encoding of draft-ietf-netmod-yang-json. Lada > > We've come up with a few ideas, and a few things below are work in > progress, but we would love your feedback! > > > Thank you! > > Xiao > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > 1. Introduction. > > JavaScript Object Notation (JSON) has been a popular choice as the message > encoding for many network protocols such as the Application Layer Traffic > Optimization (ALTO) protocol, the Content Delivery Networks Interconnecti= on > (CDNi) protocol, etc. > > Meanwhile, there are broad interests in the networking community to use > YANG to define data model so that one can use YANG related tools such as > OpenDayLight controller. Although YANG itself is XML based, there have be= en > efforts to model JSON content using YANG [draft-ietf-netmod-yang-json-01]. > > A natural question rises: can YANG model all JSON based protocols? What is > the condition for a JSON based protocol (at least the message format) to > have an syntactically equivalent, hence interoperable, YANG model with JS= ON > encoding? Alternatively, in order to interoperate, semantic equivalence > might be sufficient, is there any condition for semantic equivalence? > > 2. Claim > > A JSON based protocol carried by HTTP can have syntactically equivalent > YANG model, if and only if: > > (1) the message encoding condition is met; > > (2) the uri condition is met. > > 2.1. The message encoding condition > > The JSON message encoding MUST not contain a variable as a key in a JSON > object key-value pair. In other words, the keys in the JSON message must = be > an already defined constant (or keyword) in the message format of the > protocol. > > For example, if I have a protocol where =E2=80=9Cnetwork-map=E2=80=9D, = =E2=80=9Csrc=E2=80=9D, and =E2=80=9Cdsts=E2=80=9D > are defined keywords, JSON text A meets the condition whereas B does not > because =E2=80=9CPID1=E2=80=9D and =E2=80=9CPID2=E2=80=9D are not protoco= l keywords (they are resource IDs). > > A: > > { > > =E2=80=9Cnetwork-map=E2=80=9D: [ > > { > > =E2=80=9Csrc=E2=80=9D: =E2=80=9CPID1=E2=80=9D, > > =E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID2=E2=80=9D, =E2=80=9CPID3=E2=80= =9D] > > }, > > { > > =E2=80=9Csrc=E2=80=9D: =E2=80=9CPID2=E2=80=9D, > > =E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID3=E2=80=9D, =E2=80=9CPID4=E2=80= =9D] > > } > > ] > > } > > B: > > > { > > =E2=80=9Cnetwork-map=E2=80=9D: [ > > =E2=80=9CPID1: [=E2=80=9CPID2=E2=80=9D, =E2=80=9CPID3=E2=80=9D], > > =E2=80=9CPID2=E2=80=9D: [=E2=80=9CPID3=E2=80=9D, =E2=80=9CPID4=E2=80= =9D] > > ] > > } > >>From this we know that since ALTO protocol uses encoding B, there cannot = be > a syntactically equivalent YANG model. > > 2.2 The URI condition > > Some of the YANG-related protocols might have URI constraints, e.g. > RESTCONF. For now, we assume either that the JSON-based protocol URI could > be conformed to RESTCONF compliant uri, or that the server could have a > routing mapping between the protocol compliant uri and the RESTCONF > compliant uri, hence this condition would not be an issue, which allows us > to focus on the message encoding condition. > > 3. Proof > > 3.1. The message encoding condition is necessary. > > We first note that this condition is a necessary condition for a JSON bas= ed > protocol to have a syntactically equivalent YANG model by proving its > contrapositive. > > If one of the keys in the key-value pair in the JSON document is not > pre-defined, the corresponding XML tags will not be pre-defined keywords. > Therefore, it would not possible to model it in YANG without using > YANG=E2=80=99s anyxml > statement (which allows arbitrary XML content). > > However, using the anyxml statement would defeat our purpose of modeling > the data as it allows arbitrary XML content, and will not be helpful in t= he > subsequent parsing process. > > 3.2. The message encoding condition is sufficient. > > We prove this by providing a translation procedure from a JSON message th= at > is compliant with the protocol we are trying to model, to a custom java > class that can be used for Jackson data binding, then to a YANG model. > > We note that the middle step of translating to and from the custom parser > class is not necessary, but it will be useful. > > 3.2.1. motivation > > JSON data binding is the process of binding data structures (objects, > arrays, etc.) in JSON to the appropriate data structures in the server > (e.g. java classes, database tables, etc.) in parsing the JSON text. In > order to process JSON messages in a meaningful manner, data binding is > necessary. Even if the binding is not explicit, the server would need to = do > it eventually. For example, one can read JSON content in a stream without > binding it to the java classes, but eventually in order to make sense of > the data, the server would eventually have to organize it, which is rough= ly > analogous to data binding upfront. Popular choices for JSON parsing and > data binding include jackson and gson. > > We use Jackson full data binding as our approach. Full data binding binds > JSON content into plain old java objects (POJOs), i.e. this custom parser > class can neither extend nor implement any other class. Jackson uses > ObjectMapper with the custom parser class to parse JSON content into this > class. > > 3.2.2. The message encoding condition > > The message encoding condition is that all keys in each key-value pair in > the JSON text must be pre-defined keywords. As the keys will become either > class names and instance variable names, or be keys in the java maps, it = is > easy to see that the condition is equivalent to =E2=80=9Cthere exists a f= ull data > binding in Jackson custom parser class without using any map structures > (Map).=E2=80=9D > > 3.2.3. Proof > > We provide a recursive binding process from a JSON object to the Jackson > custom parser class to be used by Jackson ObjectMapper. > > Type determine_type(value) { > > if (value is of a primitive type, i.e. string, number, boolean, null) { > > return the corresponding java primitive type; > > } > > if (value is a JSON object) { > > return build_parser_class(value).class; > > } > > if (value is an array) { > > return ArrayList where T=3Ddetermine_type(value[0]); > > } > > // should not reach here. > > } > > Class build_parser_class(JSONObject obj) { > > create custom class C; > > for each key/value pair in the obj { > > add instance variable v in C; > > the name of variable v <- key; // (__known__ a/c to our assumption) > > the type of variable v <- determine_type(value); > > } > > return C.class; > > } > > Naming: > > --change everything into CamelCase (i.e. remove dashes, etc.) > > --for instance variables, use =E2=80=9Cmy=E2=80=9D prefix, (e.g. myVariab= le, myNetworkMap, > etc.) > > --for the custom class name, if the object is an element of the array, use > =E2=80=9CElement=E2=80=9D suffix. > > This is just one convention so that the next step proceeds smoothly. As > long as this naming translation is consistent with the naming stage in the > next step, it will work just fine. > > Example (a modified ALTO protocol network map example): > > JSON object: > > { > > =E2=80=9Cmeta=E2=80=9D: { > > =E2=80=9Cresource-id=E2=80=9D: =E2=80=9Cmy-default-map=E2=80=9D, > > =E2=80=9Ctag=E2=80=9D: =E2=80=9Caab875ef69c87d012=E2=80=9D > > }, > > =E2=80=9Cnetwork-map=E2=80=9D: [ > > { > > =E2=80=9Csrc=E2=80=9D: =E2=80=9CPID1=E2=80=9D, > > =E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID1=E2=80=9D, =E2=80=9CPID2=E2=80= =9D, =E2=80=9CPID3=E2=80=9D] > > }, > > { > > =E2=80=9Csrc=E2=80=9D: =E2=80=9CPID2=E2=80=9D, > > =E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID1=E2=80=9D, =E2=80=9CPID3=E2=80= =9D] > > }, > > { > > =E2=80=9Csrc=E2=80=9D: =E2=80=9CPID3=E2=80=9D, > > =E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID2=E2=80=9D, =E2=80=9CPID3=E2=80= =9D] > > } > > ] > > } > > Result of build_parser_class(obj): > > Class JSONObject { > > Meta myMeta; > > ArrayList myNetworkMap; > > } > > Class Meta { > > String myResourceId; > > String myTag; > > } > > Class NetworkMapElement { > > String mySrc; > > ArrayList myDsts; > > } > > Now given the Jackson Parser Java Class, to get a syntactically equivalent > YANG model: > > YANGModel build_yang_model(Class C) { > > for each instance variable (Type, Name) { > > if (Type is primitive type: string, number, boolean, null) { > > add the following to the YANG module: > > =E2=80=9Cleaf Name { type ; }=E2=80=9D > > } > > if (Type is an ArrayList) { > > if (TypeElement is primitive type) { > > add the following to the YANG module: > > =E2=80=9Cleaf-list Name { type ; }= =E2=80=9D > > } else { > > // TypeElement is a custom parser class > > add the following to the YANG module: > > =E2=80=9Clist Name { > }=E2=80=9D > > } > > } > > if (Type is a custom parser class) { > > add the following to the YANG module: > > =E2=80=9Ccontainer Name { >= }=E2=80=9D > > } > > } > > } > > Result from the previous example: > > container meta { > > leaf resource-id { > > type string; > > } > > leaf tag { > > type string; > > } > > } > > list network-map { > > leaf src { > > type string; > > } > > leaf-list dsts { > > type string; > > } > > } > > This does validate the JSON document with XML-JSON encoding. For your > reference, this is the XML document which validates: > > > > > > my-default-map > > aab875ef69c87d012 > > > > > > PID1 > > PID1 > > PID2 > > PID3 > > > > > > PID2 > > PID1 > > PID3 > > > > > > PID3 > > PID2 > > PID3 > > > > This proves that the message encoding condition is a sufficient condition > for the JSON object to have a YANG model. > > Note the model generated is very crude and lose almost all constraints and > all inheritance features (if any), because it focuses on the syntax and is > essentially converted from an JSON object compliant with a protocol inste= ad > of from the protocol itself. Hence this result is more useful in > determining which JSON based protocols cannot have a syntactically > equivalent YANG model, than in generating a good YANG model. > > 3.3. Conclusion > > Our claim holds. A JSON based protocol carried by HTTP can have > syntactically equivalent YANG model, if and only if all the keys in the > key-value pairs in the JSON message are pre-defined keywords. > > 4. Semantic equivalence > > For JSON based protocols that don=E2=80=99t satisfy the message encoding = condition, > it is still possible to have a semantically equivalent YANG model. All th= at > is required for the protocol compliant clients and the YANG model complia= nt > server to interoperate is an adapter which does the following: > > 1) translate FROM YANG server compliant response msg TO alto compliant > response msg > > 2) translate FROM alto compliant request msg TO YANG server compliant > request msg > > 4.1. Claim > > This adapter needs to be protocol-aware. > > Ideally, given any YANG model, we would like to be able to automatically > (or at least mechanically) generate this message adapter, which means not > looking at the protocol or its compliant msgs. However, without knowing t= he > specific protocol that we are working with (i.e. human intervention, i.e. > looking at the protocol compliant msgs), such an adapter cannot be > auto-generated. > > 4.2. Proof by Indistinguishability > > Suppose both the YANG server compliant msg m_y and the actually protocol > compliant msg m_p are in JSON (or have been encoded into JSON). Looking at > the differences between the two messages, call these differences {d1, d2, > ..., dn}. The goal for the auto-generated adapter would be to identify and > eliminate these differences. Construct a new JSON msg m' where all but one > difference di is the same as m_p and di is the same as the m_y. Without > looking at the protocol (or m_p), the auto-generated adapter would not be > able to distinguish between m' and m_p in its translation process, which > means, it won't be able to tell whether it should change di or not. Hence, > such an adapter must be protocol-aware. > > A good example is the dependent-vtag in the ALTO protocol: > > "dependent-vtag" : [ > > { > > "resource-id" : "my-network-map", > > "tag" : "abcd1234" > > } > > ] > > It was specified this way in the alto protocol. However, it could > conceivably be the case that it was originally the following map structur= e, > and was converted into the above encoding because of the map->list+key > issue. (This case is actually one of the few differences in the m_y and m= _p > where the adapter does not need to convert it back to a map structure.) > > "dependent-vtag" : { > > "my-network-map" : { > > "tag" : "abcd1234" > > } > > } > > Without knowing the protocol, there is no way to tell. > > 5. Ramifications > > We now understand the basic condition for a JSON based protocol to have a > YANG Model. For the protocols that don=E2=80=99t meet this condition, the= re can be > a semantic equivalent YANG model, but there won=E2=80=99t be a generic pr= ocess of > generating the adapter for all such protocols. > _______________________________________________ > 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 Oct 20 06:36:32 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF9431A87A3 for ; Mon, 20 Oct 2014 06:36:09 -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 pTTK9WJqbqb7 for ; Mon, 20 Oct 2014 06:36:06 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED9EB1A802C for ; Mon, 20 Oct 2014 06:33:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9743; q=dns/txt; s=iport; t=1413812023; x=1415021623; h=from:to:cc:subject:date:message-id:mime-version; bh=nQLbRW7LvjIz82wK+a8/D5uNXgDKOzN85o+YPK+ItJk=; b=L17wCbfoUH7O53GEdcnXbQR87+xiwNggpDtULeb8izmdljQMAt+1Raff AdbVM+t/ToFtCxk4v00KpDAPhr9BHSU4a0RAwi9CJMtb4KFmh0Wq/kIaC K/5Sco9hWKPVw139BBRNVrnA6tLHZebSREhq7p9aFBfsTMP5Vp7AyNY8h Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FACMORVStJA2G/2dsb2JhbABcgkhGU00PzB0BC4Z3VIETFgF9hAIBAQEDAQEBARpRCxIBCBgjMgsnBA6IPAgNxB4BAQEBAQEEAQEBAQEBAQEakFEQhEIFkgCERocTgTA8gwqKEIccgXw4gUNsgUiBAwEBAQ X-IronPort-AV: E=Sophos; i="5.04,756,1406592000"; d="scan'208,217"; a="88623905" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-2.cisco.com with ESMTP; 20 Oct 2014 13:33:42 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s9KDXgQJ008102 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Oct 2014 13:33:42 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.151]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Mon, 20 Oct 2014 08:33:41 -0500 From: "Dana Blair (dblair)" To: "Acee Lindem (acee)" Thread-Topic: [netmod] Call for consensus to Accept ACL Model draft-bogdanovic-netmod-acl-model-02 as a WG draft Thread-Index: AQHP7Gp12qzsz05V60GbGaTvuUkcLQ== Date: Mon, 20 Oct 2014 13:33:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.21.117.2] Content-Type: multipart/alternative; boundary="_000_D06A8773219692dblairciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/quSqm2uTyDquaYfY7ztdefQ7DSk Cc: "netmod@ietf.org" Subject: Re: [netmod] Call for consensus to Accept ACL Model draft-bogdanovic-netmod-acl-model-02 as a WG draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 20 Oct 2014 13:36:10 -0000 --_000_D06A8773219692dblairciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The authors met and this is the their consolidated response. Look for DLB: Authors, I have reviewed the document and have two rather fundamental comments that = preclude me from supporting WG adoption. 1. I think you should change the rule-name (type string) to a sequence-= number (type uint16 or int32). While using a string is ostensibly more flex= ible, network administrators have been using sequence numbers for over 30 y= ears now and will be throughly disappointed when they discover that ACE =93= 10=94 lexicographically precedes ACE =932=94. This comment has broader sig= nificance than just access lists since this model, if adopted and standardi= zed, will set a precedent for future models. DLB: This was discuss extensively among the authors. The conclusion was n= ot to add sequence numbers since it would essentially result in making the = model unworkable with 2 mutually exclusive keys. See Andy=92s comment "The= IETF data model cannot do both.=94 on 10/15. The problem with sequence-number key is insertion. While the sequence numb= er is widely used, it has a historical problem of how to insert a new entry= between two adjacent sequence numbers. IOW, how to insert a new entry bet= ween sequence N and N+1. There is no sequence number between N and N+1 wh= ich can be used for the new entry. The options: A. A vendor can use a proprietary augmentation. There is no restriction h= ere. B. Propose a pyang =97ietf compilable augmentation. However, to be consid= ered for the draft and hopefully ultimate standardization, the augmentation= must solve the insertion problem mentioned above. 2. Please remove section 5 from the draft. This draft should not mix pa= cket filtering and route filtering. Though we may get to this hierarchy, I = believe that prefix-lists have much greater affinity with other routing pol= icies than access-lists. Note that there is a separate route-filtering mod= el in https://datatracker.ietf.org/doc/draft-zhdankin-netmod-bgp-cfg/. Fina= lly, the RTGWG is now chartered for YANG models that are not specific to ot= her Routing area working groups. The discussion of route filters belongs th= ere or in IDR (since BGP has the most rigorous routing policy requirements)= . DLB: We=92ll update the draft to mention this is an example. And also ta= ke a look at the route filter model. Also, a comparably minor comment, leaf-list targets requires a better defin= ition. It really isn=92t very useful without some guidance as to how an imp= lementation=92s targets should be represented. DLB: Agreed it needs a better definition. We=92ll look into this for the = next version. For example, A proposal for interface target would help move= this along. Thanks, Acee On Oct 8, 2014, at 11:14 AM, Thomas D. Nadeau = wrote: > > The co-authors of draft-bogdanovic-netmod-acl-model-02 have asked t= he NETMOD chairs to post a call to adopt the draft as a WG document. > > The draft can be found here: > > http://tools.ietf.org/html/draft-bogdanovic-netmod-acl-model-02 > > The model itself has been extracted and can be directly accessed he= re using git: > > https://github.com/YangModels/yang/blob/master/experimental/ietf/AC= L-MODEL/ > > Please comment by the close of business on Monday, October 13, 2014= . > > > --Tom (As NETMOD co-chair) > > > > _______________________________________________ > netmod mailing list > netmod at ietf.org > https://www.ietf.org/mailman/listinfo/netmod --_000_D06A8773219692dblairciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <33A12C829428D74D9D84A0FDA0F6BD8A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable 
The authors met and this is the their consolidated respons=
e.  Look for DLB:

Authors,=20

I have reviewed the document and have two rather fundamental comments that =
preclude me from supporting WG adoption.=20

    1. I think you should change the rule-name (type string) to a sequence-=
number (type uint16 or int32). While using a string is ostensibly more flex=
ible, network administrators have been using sequence numbers for over 30 y=
ears now and will be throughly disappointed when they discover that ACE =93=
10=94 lexicographically precedes ACE =932=94.  This comment has broader sig=
nificance than just access lists since this model, if adopted and standardi=
zed, will set a precedent for future models. 

DLB=
:  This was discuss extensively among the authors.  The conclusion was not =
to add sequence numbers since it would essentially result in making the mod=
el unworkable with 2 mutually exclusive keys. See Andy=92s comment  "<=
/span>The IETF data model cannot do both.=94 on 10/15.  
The=
 problem with sequence-number key is insertion.  While the sequence number =
is widely used, it has a historical problem of how to insert a new entry be=
tween two adjacent sequence numbers.  IOW, how to insert a new entry betwee=
n sequence N and N+1.   There is no sequence number between N and N+=
;1 which can be used for the new entry.
The options: =
 
A.  A vendor can use a proprietary augmentation.  There is no r=
estriction here.
B.  Propose a pyang =97ietf compilable augmentation.  However, =
to be considered for the draft and hopefully ultimate standardization, the =
augmentation must solve the insertion problem mentioned above.
    2. Please remove section 5 from the draft. This draft should not mix pa=
cket filtering and route filtering. Though we may get to this hierarchy, I =
believe that prefix-lists have much greater affinity with other routing pol=
icies  than access-lists. Note that there is a separate route-filtering mod=
el in https://datatracker.ietf.org/doc/draft-zhdankin-net=
mod-bgp-cfg/. Finally, the RTGWG is now chartered for YANG models that =
are not specific to other Routing area working groups. The discussion of ro=
ute filters belongs there or in IDR (since BGP has the most rigorous routin=
g policy requirements).=20

DLB:  We=92ll update the draft to mention this is an example.  =
 And also take a look at the route filter model.
Also, a comparably minor comment, leaf-list targets requires a better defin=
ition. It really isn=92t very useful without some guidance as to how an imp=
lementation=92s targets should be represented. 
DLB:  Agreed it needs a better definition.  We=92ll look into t=
his for the next version.  For example, A proposal for interface target wou=
ld help move this along.
Thanks,
Acee=20
   =20


On Oct 8, 2014, at 11:14 AM, Thomas D. Nadeau <tnadeau at lucidvision.co=
m> wrote:

>=20
> 	The co-authors of draft-bogdanovic-netmod-acl-model-02 have asked the=
 NETMOD chairs to post a call to adopt the draft as a WG document.=20
>=20
> 	The draft can be found here:
>=20
> 	http://tools.ietf.org/html/draft-bogdanovic-netmod-=
acl-model-02
>=20
> 	The model itself has been extracted and can be directly accessed here=
 using git:
>=20
> 	https://github.com/YangModels/yang/blob=
/master/experimental/ietf/ACL-MODEL/
>=20
> 	Please comment by the close of business on Monday, October 13, 2014.
>=20
>=20
> 	--Tom (As NETMOD co-chair)
>=20
>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod at ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
--_000_D06A8773219692dblairciscocom_-- From nobody Mon Oct 20 06:59:45 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF281A8892 for ; Mon, 20 Oct 2014 06:59: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=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZW0MuEPMlund for ; Mon, 20 Oct 2014 06:59:41 -0700 (PDT) Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C84961A872D for ; Mon, 20 Oct 2014 06:57:30 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id o8so3720475qcw.28 for ; Mon, 20 Oct 2014 06:57:30 -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=7BATUZ7VcD9Iyp3qHOIHVOH4Fdac7pk78hbKhutAW88=; b=Loty0oH9WvegEm10E7vsl3VWigOMkr6EeUPsJxFbWIjl/GFalzEj/zYD56RWZ6nDm6 LibodjR2X91E5PCYLn9kmXA8miJ9KxwRSXoQcJmuDlC23K6AF/n7ztpdrE8RXjjAjV3E zytrnKchw+5eYicV/2a/8ok9Ujcf1pw/X9zl5A2chJQvJiNxP+8D3j7Ok+vhKJ025CPT V67DBLcCPsTajP/9VlBApxecNUdRS4AtdN2DSeTQ9+xe/FyQssMXbYc+fapJxMTG2TFF bjgKwds3zBhv1dlU/yD1Qc4zYwsuEj+IZhXbovFwg6Q7dRisbupPhNx3egw6XyZa0gJy cBbw== X-Gm-Message-State: ALoCoQkwG01iDJoPBxg0w16+o9KrlwtyWfzPBWeeWH9nDQ0gey/cxChSsJaM19ctjGdGR4Tznj5V MIME-Version: 1.0 X-Received: by 10.224.50.196 with SMTP id a4mr11903214qag.88.1413813449856; Mon, 20 Oct 2014 06:57:29 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Mon, 20 Oct 2014 06:57:29 -0700 (PDT) In-Reply-To: References: Date: Mon, 20 Oct 2014 06:57:29 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=047d7bdca2167556400505db18ec Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/BU-dpYJRIaDOkiAiD741LzbLtQk Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG Metadata Issue: leaf-list X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 20 Oct 2014 13:59:44 -0000 --047d7bdca2167556400505db18ec Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 20, 2014 at 3:55 AM, Ladislav Lhotka wrote: > Andy Bierman writes: > > > Hi, > > > > I have run into some issues implementing > > draft-lhotka-netmod-yang-metadata-00. > > > > (1) The annotations for leaf-list nodes are expensive to implement in > > a constrained or streaming-based server. Every other node type > > is easy to stream because all the data can be rendered before > > moving on to the next node. But the leaf-list meta-data follows > > all the leaf-list nodes: > > > > For example, in the following leaf-list instance with four entries, > > the "inactive" annotation is added to the second and third entry in > > the following way: > > > > "folio": [6, 3, 7, 8], > > "@folio": [ > > null, > > {"example-inactive:inactive": true}, > > {"example-inactive:inactive": true} > > ] > > > > The server has to remember a lot of state and/or go through the leaf-list > > twice. It is possible that the last node is gone and the next node is > > unknown in a streaming server, This could take a lot of resources > > for large leaf-lists. > > Do you have an alternative proposal? This encoding has an advantage that > the receiving party may just ignore the annotation and nothing alse > changes. If we somehow bundle annotations with each leaf-list entry, it > will be no more the case. > > No, I cannot think of an alternative that preserves the original encoding and does not require any state to be maintained for previous entries. I guess my conclusion is that JSON s intended for applications where the complete data structure is held in memory. It is not meant to be streamed. > > > (2) The module-name as prefix is not really needed unless > > there are annotations with the same name advertised by the server. > > This is true but if the namespace encoding is mandatory, the instance > document needn't change as a side-effect of adding a new module to the > data model. I think this is important because it it not only the server > that potentially adds annotations. If an old client that only knows > about one "foo" annotation always uses the namespace id, it can then > safely ignore a new module advertised by the server, even if it defines > a new annotation with colliding name. > This is a trade-off. Unfortunately, it make the JSON more verbose. Why not just use XML if you don't care about verbosity? The rule is not mandatory for element names, is it? > > > > > (3) Multiple annotations can be rendered in any order within an array > entry: > > This should be clarified (and maybe an example). > > I think this follows from the fact that JSON objects are unordered by > definition. So the annotation object may precede or follow the annotated > member, and also the order of its members is undefined. > OK -- this is supposed to make output simpler I guess, but the unordered objects making parsing even more stateful. > > > > > "folio": [6, 3, 7, 8], > > "@folio": [ > > null, > > {"example-inactive:inactive": true, > > "example:foo":42 }, > > {"example:foo":53, > > example-inactive:inactive": true} > > ] > > > > > > Andy > > Lada > > Andy > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > --047d7bdca2167556400505db18ec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mon, Oct 20, 2014 at 3:55 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:
Andy Bierman <andy@yumaworks.com> writes:

> Hi,
>
> I have run into some issues implementing
> draft-lhotka-netmod-yang-metadata-00.
>
> (1) The annotations for leaf-list nodes are expensive to implement in<= br> > a constrained or streaming-based server.=A0 Every other node type
> is easy to stream because all the data can be rendered before
> moving on to the next node.=A0 But the leaf-list meta-data follows
> all the leaf-list nodes:
>
>=A0 =A0 For example, in the following leaf-list instance with four entr= ies,
>=A0 =A0 the "inactive" annotation is added to the second and = third entry in
>=A0 =A0 the following way:
>
>=A0 =A0 =A0 =A0 "folio": [6, 3, 7, 8],
>=A0 =A0 =A0 =A0 "@folio": [
>=A0 =A0 =A0 =A0 =A0 null,
>=A0 =A0 =A0 =A0 =A0 {"example-inactive:inactive": true},
>=A0 =A0 =A0 =A0 =A0 {"example-inactive:inactive": true}
>=A0 =A0 =A0 =A0 ]
>
> The server has to remember a lot of state and/or go through the leaf-l= ist
> twice.=A0 It is possible that the last node is gone and the next node = is
> unknown in a streaming server, This could take a lot of resources
> for large leaf-lists.

Do you have an alternative proposal? This encoding has an advantage that the receiving party may just ignore the annotation and nothing alse
changes. If we somehow bundle annotations with each leaf-list entry, it
will be no more the case.


No, I cannot think of an alternative t= hat preserves the original encoding
and does not require any stat= e to be maintained for previous entries.
I guess my conclusion is= that JSON s intended for applications where
the complete data st= ructure is held in memory. It is not meant to be streamed.


>
> (2) The module-name as prefix is not really needed unless
> there are annotations with the same name advertised by the server.

This is true but if the namespace encoding is mandatory, the instance
document needn't change as a side-effect of adding a new module to the<= br> data model. I think this is important because it it not only the server
that potentially adds annotations. If an old client that only knows
about one "foo" annotation always uses the namespace id, it can t= hen
safely ignore a new module advertised by the server, even if it defines
a new annotation with colliding name.

T= his is a trade-off. Unfortunately, it make the JSON more verbose.
Why not just use XML if you don't care about verbosity?
The = rule is not mandatory for element names, is it?

= =A0

>
> (3) Multiple annotations can be rendered in any order within an array = entry:
> This should be clarified (and maybe an example).

I think this follows from the fact that JSON objects are unordered by
definition. So the annotation object may precede or follow the annotated member, and also the order of its members is undefined.

OK -- this is supposed to make output simpler I guess, but= the unordered objects
making parsing even more stateful.

=A0

>
>=A0 =A0 =A0 =A0 "folio": [6, 3, 7, 8],
>=A0 =A0 =A0 =A0 "@folio": [
>=A0 =A0 =A0 =A0 =A0 null,
>=A0 =A0 =A0 =A0 =A0 {"example-inactive:inactive": true,
>=A0 =A0 =A0 =A0 =A0 =A0 "example:foo":42 },
>=A0 =A0 =A0 =A0 =A0 {"example:foo":53,
>=A0 =A0 =A0 =A0 =A0 =A0 example-inactive:inactive": true}
>=A0 =A0 =A0 =A0 ]
>
>
> Andy

Lada


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

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

--047d7bdca2167556400505db18ec-- From nobody Mon Oct 20 07:00:44 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C65DE1A88BB; Mon, 20 Oct 2014 07:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbZGHfyTnNUJ; Mon, 20 Oct 2014 07:00:09 -0700 (PDT) Received: from mail-yh0-x233.google.com (mail-yh0-x233.google.com [IPv6:2607:f8b0:4002:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B61CA1A87AD; Mon, 20 Oct 2014 06:57:39 -0700 (PDT) Received: by mail-yh0-f51.google.com with SMTP id t59so3189492yho.10 for ; Mon, 20 Oct 2014 06:57:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=bpSD3PG2q+dxL6we/q9xcFmRSf/de630JKSZVZ8+/Jc=; b=cFDLPjtjYZYWxy7ZouNPLNhpI9kxeTfkUMWlf66jA7Mka4gE8lEOfmzz/5s/8UK8x7 X0vNAs2pvSsCrA0t1nncTxrTwULIbmOOzaJikmkVhyIxVDj033Eof8mDFD4JMQsr5/jG /n+u1tH7HAFjihpYEryIH54VHsoSq11ldrNR8mU+pKw09Jp3VZcKmcst2CUOdewgD+Ew 1xwiOqwM48rQO6R7bRJNV+EfzNVfx6vj+cEYN0j8L8k3niSF4DgitiPwm4OBsManTPir lGpk5Ws8W+yhefcmE1pbbhJnGuVNE6dw3tK59ztQOF1isyrC81ZX0qxSco3olnI5E0lO 8Ttw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yale.edu; s=googleprd; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=bpSD3PG2q+dxL6we/q9xcFmRSf/de630JKSZVZ8+/Jc=; b=lm07pSlLiFHD1/L78lggSz6Zjzq+vkqeOLs/cFTaIWKKhED7T+zX+mq0aPBG8A1BPc N+FMz4nUzR5K7teaY7wEWWwixYYrt2BEYkmEqgxqmpKtAdQ5ppzOkUsrD2TJahdewERm QcWdsCdfe0BB69WtDF111jvpsf2cGiXNza0cE= X-Received: by 10.236.17.129 with SMTP id j1mr3295248yhj.143.1413813458992; Mon, 20 Oct 2014 06:57:38 -0700 (PDT) MIME-Version: 1.0 Sender: boxs.jq@gmail.com Received: by 10.170.97.10 with HTTP; Mon, 20 Oct 2014 06:57:18 -0700 (PDT) In-Reply-To: References: From: Xiao SHI Date: Mon, 20 Oct 2014 09:57:18 -0400 X-Google-Sender-Auth: 0zvX13JZCe841QZKaEe0nW5Gk4g Message-ID: To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c1e2dc0083860505db1943 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/59eUQko9PzaXi3ME3T3XeHzMK2A Cc: IETF ALTO , "netmod@ietf.org" Subject: Re: [netmod] Modeling JSON based protocols using YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 20 Oct 2014 14:00:17 -0000 --001a11c1e2dc0083860505db1943 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Lada, Thank you so much for your feedback! The motivation here is to produce a YANG model given a defined protocol, e.g. ALTO, CDNi, etc. This way, we may incorporate future protocols into ODL controllers or use other YANG related tools to handle those protocols. Hence the objective of the modeling is the protocol, not the messages. I am not suggesting to use YANG as a schema language. The conditions discussed in this process will be helpful in the following sense: 1) disprove the possibility to get a syntactically equivalent YANG model from a JSON based protocol; 2) generate a Jackson JSON parser class and YANG model from the protocols that meet the criteria; 3) for designers of future protocols who are thinking of using YANG related tools, set a guideline of what their messages should look like (or MUST not contain); 4) for the YANG/NETCONF WG, describing the compatibility issues that they might be interested in tackling for expanding YANG's usage. For this example, "foo": [ { "bar": 1 }, 2 ] is also not easy to do data-binding in the parser, because the elements of the array are not of the same type, which is indeed an assumption that I left out. For the {"foo=E2=80=9D:null} example, can't we model it using type empty? T= hat's equivalent to the XML element right? Cheers, Xiao On Mon, Oct 20, 2014 at 9:23 AM, Ladislav Lhotka wrote: > Xiao SHI writes: > > > Hi folks, > > > > > > As a few of us were working on modeling the ALTO protocol using YANG, w= e > > were pondering on a more general question: can YANG model all JSON base= d > > protocols? What is the condition for a JSON based protocol (at least th= e > > message format) to have an syntactically equivalent, hence interoperabl= e, > > YANG model with JSON encoding? Alternatively, in order to interoperate, > > semantic equivalence might be sufficient, is there any condition for > > semantic equivalence? > > > > > > tl;dr: A JSON based protocol carried by HTTP can have syntactically > > equivalent YANG model, if and only if all the keys in the key-value pai= rs > > in the JSON message are pre-defined keywords in the protocol. > > > > Generating a YANG data model from existing instance data seems backwards > to me, although Examplotron (http://examplotron.org) does something quite > similar. In any case, it might be quite challenging because YANG isn't > intended as a general schema language. Your observation above is true > but it is just one aspect of the problem. For instance > > "foo": [ { "bar": 1 }, 2 ] > > or > > "foo": null > > cannot be modelled in YANG using the encoding of > draft-ietf-netmod-yang-json. > > Lada > > > > > We've come up with a few ideas, and a few things below are work in > > progress, but we would love your feedback! > > > > > > Thank you! > > > > Xiao > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > 1. Introduction. > > > > JavaScript Object Notation (JSON) has been a popular choice as the > message > > encoding for many network protocols such as the Application Layer Traff= ic > > Optimization (ALTO) protocol, the Content Delivery Networks > Interconnection > > (CDNi) protocol, etc. > > > > Meanwhile, there are broad interests in the networking community to use > > YANG to define data model so that one can use YANG related tools such a= s > > OpenDayLight controller. Although YANG itself is XML based, there have > been > > efforts to model JSON content using YANG > [draft-ietf-netmod-yang-json-01]. > > > > A natural question rises: can YANG model all JSON based protocols? What > is > > the condition for a JSON based protocol (at least the message format) t= o > > have an syntactically equivalent, hence interoperable, YANG model with > JSON > > encoding? Alternatively, in order to interoperate, semantic equivalence > > might be sufficient, is there any condition for semantic equivalence? > > > > 2. Claim > > > > A JSON based protocol carried by HTTP can have syntactically equivalent > > YANG model, if and only if: > > > > (1) the message encoding condition is met; > > > > (2) the uri condition is met. > > > > 2.1. The message encoding condition > > > > The JSON message encoding MUST not contain a variable as a key in a JSO= N > > object key-value pair. In other words, the keys in the JSON message mus= t > be > > an already defined constant (or keyword) in the message format of the > > protocol. > > > > For example, if I have a protocol where =E2=80=9Cnetwork-map=E2=80=9D, = =E2=80=9Csrc=E2=80=9D, and =E2=80=9Cdsts=E2=80=9D > > are defined keywords, JSON text A meets the condition whereas B does no= t > > because =E2=80=9CPID1=E2=80=9D and =E2=80=9CPID2=E2=80=9D are not proto= col keywords (they are resource > IDs). > > > > A: > > > > { > > > > =E2=80=9Cnetwork-map=E2=80=9D: [ > > > > { > > > > =E2=80=9Csrc=E2=80=9D: =E2=80=9CPID1=E2=80=9D, > > > > =E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID2=E2=80=9D, =E2=80=9CPID3=E2= =80=9D] > > > > }, > > > > { > > > > =E2=80=9Csrc=E2=80=9D: =E2=80=9CPID2=E2=80=9D, > > > > =E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID3=E2=80=9D, =E2=80=9CPID4=E2= =80=9D] > > > > } > > > > ] > > > > } > > > > B: > > > > > > { > > > > =E2=80=9Cnetwork-map=E2=80=9D: [ > > > > =E2=80=9CPID1: [=E2=80=9CPID2=E2=80=9D, =E2=80=9CPID3=E2=80=9D], > > > > =E2=80=9CPID2=E2=80=9D: [=E2=80=9CPID3=E2=80=9D, =E2=80=9CPID4=E2=80= =9D] > > > > ] > > > > } > > > >>From this we know that since ALTO protocol uses encoding B, there canno= t > be > > a syntactically equivalent YANG model. > > > > 2.2 The URI condition > > > > Some of the YANG-related protocols might have URI constraints, e.g. > > RESTCONF. For now, we assume either that the JSON-based protocol URI > could > > be conformed to RESTCONF compliant uri, or that the server could have a > > routing mapping between the protocol compliant uri and the RESTCONF > > compliant uri, hence this condition would not be an issue, which allows > us > > to focus on the message encoding condition. > > > > 3. Proof > > > > 3.1. The message encoding condition is necessary. > > > > We first note that this condition is a necessary condition for a JSON > based > > protocol to have a syntactically equivalent YANG model by proving its > > contrapositive. > > > > If one of the keys in the key-value pair in the JSON document is not > > pre-defined, the corresponding XML tags will not be pre-defined keyword= s. > > Therefore, it would not possible to model it in YANG without using > > YANG=E2=80=99s anyxml > > statement (which allows arbitrary XML content). > > > > However, using the anyxml statement would defeat our purpose of modelin= g > > the data as it allows arbitrary XML content, and will not be helpful in > the > > subsequent parsing process. > > > > 3.2. The message encoding condition is sufficient. > > > > We prove this by providing a translation procedure from a JSON message > that > > is compliant with the protocol we are trying to model, to a custom java > > class that can be used for Jackson data binding, then to a YANG model. > > > > We note that the middle step of translating to and from the custom pars= er > > class is not necessary, but it will be useful. > > > > 3.2.1. motivation > > > > JSON data binding is the process of binding data structures (objects, > > arrays, etc.) in JSON to the appropriate data structures in the server > > (e.g. java classes, database tables, etc.) in parsing the JSON text. In > > order to process JSON messages in a meaningful manner, data binding is > > necessary. Even if the binding is not explicit, the server would need t= o > do > > it eventually. For example, one can read JSON content in a stream witho= ut > > binding it to the java classes, but eventually in order to make sense o= f > > the data, the server would eventually have to organize it, which is > roughly > > analogous to data binding upfront. Popular choices for JSON parsing and > > data binding include jackson and gson. > > > > We use Jackson full data binding as our approach. Full data binding bin= ds > > JSON content into plain old java objects (POJOs), i.e. this custom pars= er > > class can neither extend nor implement any other class. Jackson uses > > ObjectMapper with the custom parser class to parse JSON content into th= is > > class. > > > > 3.2.2. The message encoding condition > > > > The message encoding condition is that all keys in each key-value pair = in > > the JSON text must be pre-defined keywords. As the keys will become > either > > class names and instance variable names, or be keys in the java maps, i= t > is > > easy to see that the condition is equivalent to =E2=80=9Cthere exists a= full data > > binding in Jackson custom parser class without using any map structures > > (Map).=E2=80=9D > > > > 3.2.3. Proof > > > > We provide a recursive binding process from a JSON object to the Jackso= n > > custom parser class to be used by Jackson ObjectMapper. > > > > Type determine_type(value) { > > > > if (value is of a primitive type, i.e. string, number, boolean, null) = { > > > > return the corresponding java primitive type; > > > > } > > > > if (value is a JSON object) { > > > > return build_parser_class(value).class; > > > > } > > > > if (value is an array) { > > > > return ArrayList where T=3Ddetermine_type(value[0]); > > > > } > > > > // should not reach here. > > > > } > > > > Class build_parser_class(JSONObject obj) { > > > > create custom class C; > > > > for each key/value pair in the obj { > > > > add instance variable v in C; > > > > the name of variable v <- key; // (__known__ a/c to our assumption) > > > > the type of variable v <- determine_type(value); > > > > } > > > > return C.class; > > > > } > > > > Naming: > > > > --change everything into CamelCase (i.e. remove dashes, etc.) > > > > --for instance variables, use =E2=80=9Cmy=E2=80=9D prefix, (e.g. myVari= able, > myNetworkMap, > > etc.) > > > > --for the custom class name, if the object is an element of the array, > use > > =E2=80=9CElement=E2=80=9D suffix. > > > > This is just one convention so that the next step proceeds smoothly. As > > long as this naming translation is consistent with the naming stage in > the > > next step, it will work just fine. > > > > Example (a modified ALTO protocol network map example): > > > > JSON object: > > > > { > > > > =E2=80=9Cmeta=E2=80=9D: { > > > > =E2=80=9Cresource-id=E2=80=9D: =E2=80=9Cmy-default-map=E2=80=9D, > > > > =E2=80=9Ctag=E2=80=9D: =E2=80=9Caab875ef69c87d012=E2=80=9D > > > > }, > > > > =E2=80=9Cnetwork-map=E2=80=9D: [ > > > > { > > > > =E2=80=9Csrc=E2=80=9D: =E2=80=9CPID1=E2=80=9D, > > > > =E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID1=E2=80=9D, =E2=80=9CPID2=E2= =80=9D, =E2=80=9CPID3=E2=80=9D] > > > > }, > > > > { > > > > =E2=80=9Csrc=E2=80=9D: =E2=80=9CPID2=E2=80=9D, > > > > =E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID1=E2=80=9D, =E2=80=9CPID3=E2= =80=9D] > > > > }, > > > > { > > > > =E2=80=9Csrc=E2=80=9D: =E2=80=9CPID3=E2=80=9D, > > > > =E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID2=E2=80=9D, =E2=80=9CPID3=E2= =80=9D] > > > > } > > > > ] > > > > } > > > > Result of build_parser_class(obj): > > > > Class JSONObject { > > > > Meta myMeta; > > > > ArrayList myNetworkMap; > > > > } > > > > Class Meta { > > > > String myResourceId; > > > > String myTag; > > > > } > > > > Class NetworkMapElement { > > > > String mySrc; > > > > ArrayList myDsts; > > > > } > > > > Now given the Jackson Parser Java Class, to get a syntactically > equivalent > > YANG model: > > > > YANGModel build_yang_model(Class C) { > > > > for each instance variable (Type, Name) { > > > > if (Type is primitive type: string, number, boolean, null) { > > > > add the following to the YANG module: > > > > =E2=80=9Cleaf Name { type ; }=E2=80=9D > > > > } > > > > if (Type is an ArrayList) { > > > > if (TypeElement is primitive type) { > > > > add the following to the YANG module: > > > > =E2=80=9Cleaf-list Name { type ;= }=E2=80=9D > > > > } else { > > > > // TypeElement is a custom parser class > > > > add the following to the YANG module: > > > > =E2=80=9Clist Name { > }=E2=80=9D > > > > } > > > > } > > > > if (Type is a custom parser class) { > > > > add the following to the YANG module: > > > > =E2=80=9Ccontainer Name { > }=E2=80=9D > > > > } > > > > } > > > > } > > > > Result from the previous example: > > > > container meta { > > > > leaf resource-id { > > > > type string; > > > > } > > > > leaf tag { > > > > type string; > > > > } > > > > } > > > > list network-map { > > > > leaf src { > > > > type string; > > > > } > > > > leaf-list dsts { > > > > type string; > > > > } > > > > } > > > > This does validate the JSON document with XML-JSON encoding. For your > > reference, this is the XML document which validates: > > > > > > > > > > > > my-default-map > > > > aab875ef69c87d012 > > > > > > > > > > > > PID1 > > > > PID1 > > > > PID2 > > > > PID3 > > > > > > > > > > > > PID2 > > > > PID1 > > > > PID3 > > > > > > > > > > > > PID3 > > > > PID2 > > > > PID3 > > > > > > > > This proves that the message encoding condition is a sufficient conditi= on > > for the JSON object to have a YANG model. > > > > Note the model generated is very crude and lose almost all constraints > and > > all inheritance features (if any), because it focuses on the syntax and > is > > essentially converted from an JSON object compliant with a protocol > instead > > of from the protocol itself. Hence this result is more useful in > > determining which JSON based protocols cannot have a syntactically > > equivalent YANG model, than in generating a good YANG model. > > > > 3.3. Conclusion > > > > Our claim holds. A JSON based protocol carried by HTTP can have > > syntactically equivalent YANG model, if and only if all the keys in the > > key-value pairs in the JSON message are pre-defined keywords. > > > > 4. Semantic equivalence > > > > For JSON based protocols that don=E2=80=99t satisfy the message encodin= g > condition, > > it is still possible to have a semantically equivalent YANG model. All > that > > is required for the protocol compliant clients and the YANG model > compliant > > server to interoperate is an adapter which does the following: > > > > 1) translate FROM YANG server compliant response msg TO alto compliant > > response msg > > > > 2) translate FROM alto compliant request msg TO YANG server compliant > > request msg > > > > 4.1. Claim > > > > This adapter needs to be protocol-aware. > > > > Ideally, given any YANG model, we would like to be able to automaticall= y > > (or at least mechanically) generate this message adapter, which means n= ot > > looking at the protocol or its compliant msgs. However, without knowing > the > > specific protocol that we are working with (i.e. human intervention, i.= e. > > looking at the protocol compliant msgs), such an adapter cannot be > > auto-generated. > > > > 4.2. Proof by Indistinguishability > > > > Suppose both the YANG server compliant msg m_y and the actually protoco= l > > compliant msg m_p are in JSON (or have been encoded into JSON). Looking > at > > the differences between the two messages, call these differences {d1, d= 2, > > ..., dn}. The goal for the auto-generated adapter would be to identify > and > > eliminate these differences. Construct a new JSON msg m' where all but > one > > difference di is the same as m_p and di is the same as the m_y. Without > > looking at the protocol (or m_p), the auto-generated adapter would not = be > > able to distinguish between m' and m_p in its translation process, whic= h > > means, it won't be able to tell whether it should change di or not. > Hence, > > such an adapter must be protocol-aware. > > > > A good example is the dependent-vtag in the ALTO protocol: > > > > "dependent-vtag" : [ > > > > { > > > > "resource-id" : "my-network-map", > > > > "tag" : "abcd1234" > > > > } > > > > ] > > > > It was specified this way in the alto protocol. However, it could > > conceivably be the case that it was originally the following map > structure, > > and was converted into the above encoding because of the map->list+key > > issue. (This case is actually one of the few differences in the m_y and > m_p > > where the adapter does not need to convert it back to a map structure.) > > > > "dependent-vtag" : { > > > > "my-network-map" : { > > > > "tag" : "abcd1234" > > > > } > > > > } > > > > Without knowing the protocol, there is no way to tell. > > > > 5. Ramifications > > > > We now understand the basic condition for a JSON based protocol to have= a > > YANG Model. For the protocols that don=E2=80=99t meet this condition, t= here can > be > > a semantic equivalent YANG model, but there won=E2=80=99t be a generic = process of > > generating the adapter for all such protocols. > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > --001a11c1e2dc0083860505db1943 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Lada,

Thank you so much for your fee= dback!

The motivation here is to produce a YANG mode= l given a defined protocol, e.g. ALTO, CDNi, etc. This way, we may incorpor= ate future protocols into ODL controllers or use other YANG related tools t= o handle those protocols. Hence the objective of the modeling is the protoc= ol, not the messages. I am not suggesting to use YANG as a schema language.=

The conditions discussed in this process will be = helpful in the following sense:
1) disprove the possibility to ge= t a syntactically equivalent YANG model from a JSON based protocol;
2) generate a Jackson JSON parser class and YANG model from the protocol= s that meet the criteria;
3) for designers of future protocols wh= o are thinking of using YANG related tools, set a guideline of what their m= essages should look like (or MUST not contain);
4) for the YANG/N= ETCONF WG, describing the compatibility issues that they might be intereste= d in tackling for expanding YANG's usage.=C2=A0

For this exam= ple, "foo": [ { "bar": 1 }, 2 ] is also not easy to do = data-binding in the parser, because the elements of the array are not of th= e same type, which is indeed an assumption that I left out.

Fo= r the {"foo=E2=80=9D:null} example, can't we model it using type e= mpty? That's equivalent to the XML element <foo /> right?<= /div>

<= /span>
Cheers,
= Xiao

On Mon, Oct 20, 2014 at 9:23 A= M, Ladislav Lhotka <lhotka@nic.cz> wrote:
Xiao SHI <xiao.shi@yale.edu> writes:

> Hi folks,
>
>
> As a few of us were working on modeling the ALTO protocol using YANG, = we
> were pondering on a more general question: can YANG model all JSON bas= ed
> protocols? What is the condition for a JSON based protocol (at least t= he
> message format) to have an syntactically equivalent, hence interoperab= le,
> YANG model with JSON encoding? Alternatively, in order to interoperate= ,
> semantic equivalence might be sufficient, is there any condition for > semantic equivalence?
>
>
> tl;dr: A JSON based protocol carried by HTTP can have syntactically > equivalent YANG model, if and only if all the keys in the key-value pa= irs
> in the JSON message are pre-defined keywords in the protocol.
>

Generating a YANG data model from existing instance data seems backw= ards
to me, although Examplotron (http://examplotron.org) does something quite
similar. In any case, it might be quite challenging because YANG isn't<= br> intended as a general schema language. Your observation above is true
but it is just one aspect of the problem. For instance

"foo": [ { "bar": 1 }, 2 ]

or

"foo": null

cannot be modelled in YANG using the encoding of
draft-ietf-netmod-yang-json.

Lada

>
> We've come up with a few ideas, and a few things below are work in=
> progress, but we would love your feedback!
>
>
> Thank you!
>
> Xiao
>
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> 1. Introduction.
>
> JavaScript Object Notation (JSON) has been a popular choice as the mes= sage
> encoding for many network protocols such as the Application Layer Traf= fic
> Optimization (ALTO) protocol, the Content Delivery Networks Interconne= ction
> (CDNi) protocol, etc.
>
> Meanwhile, there are broad interests in the networking community to us= e
> YANG to define data model so that one can use YANG related tools such = as
> OpenDayLight controller. Although YANG itself is XML based, there have= been
> efforts to model JSON content using YANG [draft-ietf-netmod-yang-json-= 01].
>
> A natural question rises: can YANG model all JSON based protocols? Wha= t is
> the condition for a JSON based protocol (at least the message format) = to
> have an syntactically equivalent, hence interoperable, YANG model with= JSON
> encoding? Alternatively, in order to interoperate, semantic equivalenc= e
> might be sufficient, is there any condition for semantic equivalence?<= br> >
> 2. Claim
>
> A JSON based protocol carried by HTTP can have syntactically equivalen= t
> YANG model, if and only if:
>
> (1) the message encoding condition is met;
>
> (2) the uri condition is met.
>
> 2.1. The message encoding condition
>
> The JSON message encoding MUST not contain a variable as a key in a JS= ON
> object key-value pair. In other words, the keys in the JSON message mu= st be
> an already defined constant (or keyword) in the message format of the<= br> > protocol.
>
> For example, if I have a protocol where =E2=80=9Cnetwork-map=E2=80=9D,= =E2=80=9Csrc=E2=80=9D, and =E2=80=9Cdsts=E2=80=9D
> are defined keywords, JSON text A meets the condition whereas B does n= ot
> because =E2=80=9CPID1=E2=80=9D and =E2=80=9CPID2=E2=80=9D are not prot= ocol keywords (they are resource IDs).
>
> A:
>
> {
>
>=C2=A0 =E2=80=9Cnetwork-map=E2=80=9D: [
>
>=C2=A0 =C2=A0 {
>
>=C2=A0 =C2=A0 =C2=A0 =E2=80=9Csrc=E2=80=9D: =E2=80=9CPID1=E2=80=9D,
>
>=C2=A0 =C2=A0 =C2=A0 =E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID2=E2=80=9D, = =E2=80=9CPID3=E2=80=9D]
>
>=C2=A0 =C2=A0 },
>
>=C2=A0 =C2=A0 {
>
>=C2=A0 =C2=A0 =C2=A0 =E2=80=9Csrc=E2=80=9D: =E2=80=9CPID2=E2=80=9D,
>
>=C2=A0 =C2=A0 =C2=A0 =E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID3=E2=80=9D, = =E2=80=9CPID4=E2=80=9D]
>
>=C2=A0 =C2=A0 }
>
>=C2=A0 ]
>
> }
>
> B:
>
>
> {
>
>=C2=A0 =E2=80=9Cnetwork-map=E2=80=9D: [
>
>=C2=A0 =C2=A0 =E2=80=9CPID1: [=E2=80=9CPID2=E2=80=9D, =E2=80=9CPID3=E2= =80=9D],
>
>=C2=A0 =C2=A0 =E2=80=9CPID2=E2=80=9D: [=E2=80=9CPID3=E2=80=9D, =E2=80= =9CPID4=E2=80=9D]
>
>=C2=A0 ]
>
> }
>
>>From this we know that since ALTO protocol uses encoding B, there c= annot be
> a syntactically equivalent YANG model.
>
> 2.2 The URI condition
>
> Some of the YANG-related protocols might have URI constraints, e.g. > RESTCONF. For now, we assume either that the JSON-based protocol URI c= ould
> be conformed to RESTCONF compliant uri, or that the server could have = a
> routing mapping between the protocol compliant uri and the RESTCONF > compliant uri, hence this condition would not be an issue, which allow= s us
> to focus on the message encoding condition.
>
> 3. Proof
>
> 3.1. The message encoding condition is necessary.
>
> We first note that this condition is a necessary condition for a JSON = based
> protocol to have a syntactically equivalent YANG model by proving its<= br> > contrapositive.
>
> If one of the keys in the key-value pair in the JSON document is not > pre-defined, the corresponding XML tags will not be pre-defined keywor= ds.
> Therefore, it would not possible to model it in YANG without using
> YANG=E2=80=99s anyxml
> statement (which allows arbitrary XML content).
>
> However, using the anyxml statement would defeat our purpose of modeli= ng
> the data as it allows arbitrary XML content, and will not be helpful i= n the
> subsequent parsing process.
>
> 3.2. The message encoding condition is sufficient.
>
> We prove this by providing a translation procedure from a JSON message= that
> is compliant with the protocol we are trying to model, to a custom jav= a
> class that can be used for Jackson data binding, then to a YANG model.=
>
> We note that the middle step of translating to and from the custom par= ser
> class is not necessary, but it will be useful.
>
> 3.2.1. motivation
>
> JSON data binding is the process of binding data structures (objects,<= br> > arrays, etc.) in JSON to the appropriate data structures in the server=
> (e.g. java classes, database tables, etc.) in parsing the JSON text. I= n
> order to process JSON messages in a meaningful manner, data binding is=
> necessary. Even if the binding is not explicit, the server would need = to do
> it eventually. For example, one can read JSON content in a stream with= out
> binding it to the java classes, but eventually in order to make sense = of
> the data, the server would eventually have to organize it, which is ro= ughly
> analogous to data binding upfront. Popular choices for JSON parsing an= d
> data binding include jackson and gson.
>
> We use Jackson full data binding as our approach. Full data binding bi= nds
> JSON content into plain old java objects (POJOs), i.e. this custom par= ser
> class can neither extend nor implement any other class. Jackson uses > ObjectMapper with the custom parser class to parse JSON content into t= his
> class.
>
> 3.2.2. The message encoding condition
>
> The message encoding condition is that all keys in each key-value pair= in
> the JSON text must be pre-defined keywords. As the keys will become ei= ther
> class names and instance variable names, or be keys in the java maps, = it is
> easy to see that the condition is equivalent to =E2=80=9Cthere exists = a full data
> binding in Jackson custom parser class without using any map structure= s
> (Map<String, ?>).=E2=80=9D
>
> 3.2.3. Proof
>
> We provide a recursive binding process from a JSON object to the Jacks= on
> custom parser class to be used by Jackson ObjectMapper.
>
> Type determine_type(value) {
>
>=C2=A0 if (value is of a primitive type, i.e. string, number, boolean, = null) {
>
>=C2=A0 =C2=A0 return the corresponding java primitive type;
>
>=C2=A0 }
>
>=C2=A0 if (value is a JSON object) {
>
>=C2=A0 =C2=A0 return build_parser_class(value).class;
>
>=C2=A0 }
>
>=C2=A0 if (value is an array) {
>
>=C2=A0 =C2=A0 return ArrayList<T> where T=3Ddetermine_type(value[= 0]);
>
>=C2=A0 }
>
>=C2=A0 // should not reach here.
>
> }
>
> Class build_parser_class(JSONObject obj) {
>
>=C2=A0 create custom class C;
>
>=C2=A0 for each key/value pair in the obj {
>
>=C2=A0 =C2=A0 add instance variable v in C;
>
>=C2=A0 =C2=A0 the name of variable v <- key; // (__known__ a/c to ou= r assumption)
>
>=C2=A0 =C2=A0 the type of variable v <- determine_type(value);
>
>=C2=A0 }
>
>=C2=A0 return C.class;
>
> }
>
> Naming:
>
> --change everything into CamelCase (i.e. remove dashes, etc.)
>
> --for instance variables, use =E2=80=9Cmy=E2=80=9D prefix, (e.g. myVar= iable, myNetworkMap,
> etc.)
>
> --for the custom class name, if the object is an element of the array,= use
> =E2=80=9CElement=E2=80=9D suffix.
>
> This is just one convention so that the next step proceeds smoothly. A= s
> long as this naming translation is consistent with the naming stage in= the
> next step, it will work just fine.
>
> Example (a modified ALTO protocol network map example):
>
> JSON object:
>
> {
>
>=C2=A0 =E2=80=9Cmeta=E2=80=9D: {
>
>=C2=A0 =C2=A0 =E2=80=9Cresource-id=E2=80=9D: =E2=80=9Cmy-default-map=E2= =80=9D,
>
>=C2=A0 =C2=A0 =E2=80=9Ctag=E2=80=9D: =E2=80=9Caab875ef69c87d012=E2=80= =9D
>
>=C2=A0 },
>
>=C2=A0 =E2=80=9Cnetwork-map=E2=80=9D: [
>
>=C2=A0 =C2=A0 {
>
>=C2=A0 =C2=A0 =C2=A0 =E2=80=9Csrc=E2=80=9D: =E2=80=9CPID1=E2=80=9D,
>
>=C2=A0 =C2=A0 =C2=A0 =E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID1=E2=80=9D, = =E2=80=9CPID2=E2=80=9D, =E2=80=9CPID3=E2=80=9D]
>
>=C2=A0 =C2=A0 },
>
>=C2=A0 =C2=A0 {
>
>=C2=A0 =C2=A0 =C2=A0 =E2=80=9Csrc=E2=80=9D: =E2=80=9CPID2=E2=80=9D,
>
>=C2=A0 =C2=A0 =C2=A0 =E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID1=E2=80=9D, = =E2=80=9CPID3=E2=80=9D]
>
>=C2=A0 =C2=A0 },
>
>=C2=A0 =C2=A0 {
>
>=C2=A0 =C2=A0 =C2=A0 =E2=80=9Csrc=E2=80=9D: =E2=80=9CPID3=E2=80=9D,
>
>=C2=A0 =C2=A0 =C2=A0 =E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID2=E2=80=9D, = =E2=80=9CPID3=E2=80=9D]
>
>=C2=A0 =C2=A0 }
>
>=C2=A0 ]
>
> }
>
> Result of build_parser_class(obj):
>
> Class JSONObject {
>
>=C2=A0 Meta myMeta;
>
>=C2=A0 ArrayList<NetworkMapElement> myNetworkMap;
>
> }
>
> Class Meta {
>
>=C2=A0 String myResourceId;
>
>=C2=A0 String myTag;
>
> }
>
> Class NetworkMapElement {
>
>=C2=A0 String mySrc;
>
>=C2=A0 ArrayList<String> myDsts;
>
> }
>
> Now given the Jackson Parser Java Class, to get a syntactically equiva= lent
> YANG model:
>
> YANGModel build_yang_model(Class C) {
>
>=C2=A0 for each instance variable (Type, Name) {
>
>=C2=A0 =C2=A0 if (Type is primitive type: string, number, boolean, null= ) {
>
>=C2=A0 =C2=A0 =C2=A0 add the following to the YANG module:
>
>=C2=A0 =C2=A0 =C2=A0 =E2=80=9Cleaf Name { type <YANG equivalent of T= ype>; }=E2=80=9D
>
>=C2=A0 =C2=A0 }
>
>=C2=A0 =C2=A0 if (Type is an ArrayList<TypeElement>) {
>
>=C2=A0 =C2=A0 =C2=A0 if (TypeElement is primitive type) {
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 add the following to the YANG module:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=9Cleaf-list Name { type <YANG equ= ivalent of TypeElement>; }=E2=80=9D
>
>=C2=A0 =C2=A0 =C2=A0 } else {
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 // TypeElement is a custom parser class
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 add the following to the YANG module:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=9Clist Name { <result from build_= yang_model<TypeElement.class>> }=E2=80=9D
>
>=C2=A0 =C2=A0 =C2=A0 }
>
>=C2=A0 =C2=A0 }
>
>=C2=A0 =C2=A0 if (Type is a custom parser class) {
>
>=C2=A0 =C2=A0 =C2=A0 add the following to the YANG module:
>
>=C2=A0 =C2=A0 =C2=A0 =E2=80=9Ccontainer Name { <result from build_ya= ng_model<Type.class>> }=E2=80=9D
>
>=C2=A0 =C2=A0 }
>
>=C2=A0 }
>
> }
>
> Result from the previous example:
>
> container meta {
>
>=C2=A0 leaf resource-id {
>
>=C2=A0 =C2=A0 type string;
>
>=C2=A0 }
>
>=C2=A0 leaf tag {
>
>=C2=A0 =C2=A0 type string;
>
>=C2=A0 }
>
> }
>
> list network-map {
>
>=C2=A0 leaf src {
>
>=C2=A0 =C2=A0 type string;
>
>=C2=A0 }
>
>=C2=A0 leaf-list dsts {
>
>=C2=A0 =C2=A0 type string;
>
>=C2=A0 }
>
> }
>
> This does validate the JSON document with XML-JSON encoding. For your<= br> > reference, this is the XML document which validates:
>
> <?xml version=3D"1.0" encoding=3D"UTF-8" ?><= br> >
> <meta>
>
>=C2=A0 <resource-id>my-default-map</resource-id>
>
>=C2=A0 <tag>aab875ef69c87d012</tag>
>
> </meta>
>
> <network-map>
>
>=C2=A0 <src>PID1</src>
>
>=C2=A0 <dsts>PID1</dsts>
>
>=C2=A0 <dsts>PID2</dsts>
>
>=C2=A0 <dsts>PID3</dsts>
>
> </network-map>
>
> <network-map>
>
>=C2=A0 <src>PID2</src>
>
>=C2=A0 <dsts>PID1</dsts>
>
>=C2=A0 <dsts>PID3</dsts>
>
> </network-map>
>
> <network-map>
>
>=C2=A0 <src>PID3</src>
>
>=C2=A0 <dsts>PID2</dsts>
>
>=C2=A0 <dsts>PID3</dsts>
>
> </network-map>
>
> This proves that the message encoding condition is a sufficient condit= ion
> for the JSON object to have a YANG model.
>
> Note the model generated is very crude and lose almost all constraints= and
> all inheritance features (if any), because it focuses on the syntax an= d is
> essentially converted from an JSON object compliant with a protocol in= stead
> of from the protocol itself. Hence this result is more useful in
> determining which JSON based protocols cannot have a syntactically
> equivalent YANG model, than in generating a good YANG model.
>
> 3.3. Conclusion
>
> Our claim holds. A JSON based protocol carried by HTTP can have
> syntactically equivalent YANG model, if and only if all the keys in th= e
> key-value pairs in the JSON message are pre-defined keywords.
>
> 4. Semantic equivalence
>
> For JSON based protocols that don=E2=80=99t satisfy the message encodi= ng condition,
> it is still possible to have a semantically equivalent YANG model. All= that
> is required for the protocol compliant clients and the YANG model comp= liant
> server to interoperate is an adapter which does the following:
>
> 1) translate FROM YANG server compliant response msg TO alto compliant=
> response msg
>
> 2) translate FROM alto compliant request msg TO YANG server compliant<= br> > request msg
>
> 4.1. Claim
>
> This adapter needs to be protocol-aware.
>
> Ideally, given any YANG model, we would like to be able to automatical= ly
> (or at least mechanically) generate this message adapter, which means = not
> looking at the protocol or its compliant msgs. However, without knowin= g the
> specific protocol that we are working with (i.e. human intervention, i= .e.
> looking at the protocol compliant msgs), such an adapter cannot be
> auto-generated.
>
> 4.2. Proof by Indistinguishability
>
> Suppose both the YANG server compliant msg m_y and the actually protoc= ol
> compliant msg m_p are in JSON (or have been encoded into JSON). Lookin= g at
> the differences between the two messages, call these differences {d1, = d2,
> ..., dn}. The goal for the auto-generated adapter would be to identify= and
> eliminate these differences. Construct a new JSON msg m' where all= but one
> difference di is the same as m_p and di is the same as the m_y. Withou= t
> looking at the protocol (or m_p), the auto-generated adapter would not= be
> able to distinguish between m' and m_p in its translation process,= which
> means, it won't be able to tell whether it should change di or not= . Hence,
> such an adapter must be protocol-aware.
>
> A good example is the dependent-vtag in the ALTO protocol:
>
> "dependent-vtag" : [
>
>=C2=A0 {
>
>=C2=A0 =C2=A0 "resource-id" : "my-network-map",
>
>=C2=A0 =C2=A0 "tag" : "abcd1234"
>
>=C2=A0 }
>
> ]
>
> It was specified this way in the alto protocol. However, it could
> conceivably be the case that it was originally the following map struc= ture,
> and was converted into the above encoding because of the map->list+= key
> issue. (This case is actually one of the few differences in the m_y an= d m_p
> where the adapter does not need to convert it back to a map structure.= )
>
> "dependent-vtag" : {
>
>=C2=A0 "my-network-map" : {
>
>=C2=A0 =C2=A0 "tag" : "abcd1234"
>
>=C2=A0 }
>
> }
>
> Without knowing the protocol, there is no way to tell.
>
> 5. Ramifications
>
> We now understand the basic condition for a JSON based protocol to hav= e a
> YANG Model. For the protocols that don=E2=80=99t meet this condition, = there can be
> a semantic equivalent YANG model, but there won=E2=80=99t be a generic= process of
> generating the adapter for all such protocols.
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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

--001a11c1e2dc0083860505db1943-- From nobody Mon Oct 20 08:33:21 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78B211A01F9 for ; Mon, 20 Oct 2014 08:33: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 orrn7BEr810o for ; Mon, 20 Oct 2014 08:33:10 -0700 (PDT) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 021D01A1B55 for ; Mon, 20 Oct 2014 08:29:02 -0700 (PDT) Received: by mail-qc0-f170.google.com with SMTP id m20so3877369qcx.15 for ; Mon, 20 Oct 2014 08:29:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=uKZUcgls/pMkYS+V3KnkR+oTA68FHzcUR2IqVvnEYyo=; b=iJCTzGsp4L4CFC6jj1nXzrau/ErJvCoQj+CSAA2/HvHd/JKK6R49GmVn2V5gM5Flzb i7tx3bjA5l01ntZN2in+wsqWatPXji56MsX+C5c7eHNNWp6DapBJ5OJrE6MMBmBU9g0X 3IrKhzw0AF9Aq6o4m0ok0SSaoMKE8g/Nnn/+7stnrJrDQNVRJntsqXLMfRcq4kpzWLgB j2bkUsGKsRhhnfP5pQKFKUckDrZtJmqofHxss5GA3Z35drtkgpOB3jD0fCb0WpBrLwx3 21B26JEPVkU8lirjnKB7k2ABHHiV9hkF3M8Mu6hvRTRVxQm9d4yotVK7E/sXL9dygHGe 51WA== X-Gm-Message-State: ALoCoQlIV/ZEdufNw3cu1YwRhHcG8fJiUeHrpkdsRmQsaEtOYjSQQYo3OMkAAZFcXSWKOIcOgSZO MIME-Version: 1.0 X-Received: by 10.140.88.177 with SMTP id t46mr26420548qgd.36.1413818940469; Mon, 20 Oct 2014 08:29:00 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Mon, 20 Oct 2014 08:29:00 -0700 (PDT) In-Reply-To: References: Date: Mon, 20 Oct 2014 08:29:00 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c13e4ab941f80505dc5f08 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/lQ9Dr-1fd7WEn8Cr1AZ6RlMpNdc Cc: IETF ALTO , "netmod@ietf.org" Subject: Re: [netmod] Modeling JSON based protocols using YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 20 Oct 2014 15:33:19 -0000 --001a11c13e4ab941f80505dc5f08 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 20, 2014 at 6:23 AM, Ladislav Lhotka wrote: > Xiao SHI writes: > > > Hi folks, > > > > > > As a few of us were working on modeling the ALTO protocol using YANG, we > > were pondering on a more general question: can YANG model all JSON based > > protocols? What is the condition for a JSON based protocol (at least the > > message format) to have an syntactically equivalent, hence interoperable, > > YANG model with JSON encoding? Alternatively, in order to interoperate, > > semantic equivalence might be sufficient, is there any condition for > > semantic equivalence? > > > > > > tl;dr: A JSON based protocol carried by HTTP can have syntactically > > equivalent YANG model, if and only if all the keys in the key-value pairs > > in the JSON message are pre-defined keywords in the protocol. > > > > Generating a YANG data model from existing instance data seems backwards > to me, although Examplotron (http://examplotron.org) does something quite > similar. In any case, it might be quite challenging because YANG isn't > intended as a general schema language. Your observation above is true > but it is just one aspect of the problem. For instance > > "foo": [ { "bar": 1 }, 2 ] > > or > > "foo": null > > cannot be modelled in YANG using the encoding of > draft-ietf-netmod-yang-json. > > I think perhaps RESTCONF is overloading JSON and this has led to some confusion. RESTCONF uses JSON strictly as an encoding format, not a data structure. JSON is just the message encoding. The corresponding instance document must conform to the YANG definitions (not just be valid JSON). A protocol should pick between YANG data structures and JSON data structures, and not try to do both. > Lada > > Andy > > > > We've come up with a few ideas, and a few things below are work in > > progress, but we would love your feedback! > > > > > > Thank you! > > > > Xiao > > > > > > ====================== > > > > 1. Introduction. > > > > JavaScript Object Notation (JSON) has been a popular choice as the > message > > encoding for many network protocols such as the Application Layer Traffic > > Optimization (ALTO) protocol, the Content Delivery Networks > Interconnection > > (CDNi) protocol, etc. > > > > Meanwhile, there are broad interests in the networking community to use > > YANG to define data model so that one can use YANG related tools such as > > OpenDayLight controller. Although YANG itself is XML based, there have > been > > efforts to model JSON content using YANG > [draft-ietf-netmod-yang-json-01]. > > > > A natural question rises: can YANG model all JSON based protocols? What > is > > the condition for a JSON based protocol (at least the message format) to > > have an syntactically equivalent, hence interoperable, YANG model with > JSON > > encoding? Alternatively, in order to interoperate, semantic equivalence > > might be sufficient, is there any condition for semantic equivalence? > > > > 2. Claim > > > > A JSON based protocol carried by HTTP can have syntactically equivalent > > YANG model, if and only if: > > > > (1) the message encoding condition is met; > > > > (2) the uri condition is met. > > > > 2.1. The message encoding condition > > > > The JSON message encoding MUST not contain a variable as a key in a JSON > > object key-value pair. In other words, the keys in the JSON message must > be > > an already defined constant (or keyword) in the message format of the > > protocol. > > > > For example, if I have a protocol where "network-map", "src", and "dsts" > > are defined keywords, JSON text A meets the condition whereas B does not > > because "PID1" and "PID2" are not protocol keywords (they are resource > IDs). > > > > A: > > > > { > > > > "network-map": [ > > > > { > > > > "src": "PID1", > > > > "dsts": ["PID2", "PID3"] > > > > }, > > > > { > > > > "src": "PID2", > > > > "dsts": ["PID3", "PID4"] > > > > } > > > > ] > > > > } > > > > B: > > > > > > { > > > > "network-map": [ > > > > "PID1: ["PID2", "PID3"], > > > > "PID2": ["PID3", "PID4"] > > > > ] > > > > } > > > >>From this we know that since ALTO protocol uses encoding B, there cannot > be > > a syntactically equivalent YANG model. > > > > 2.2 The URI condition > > > > Some of the YANG-related protocols might have URI constraints, e.g. > > RESTCONF. For now, we assume either that the JSON-based protocol URI > could > > be conformed to RESTCONF compliant uri, or that the server could have a > > routing mapping between the protocol compliant uri and the RESTCONF > > compliant uri, hence this condition would not be an issue, which allows > us > > to focus on the message encoding condition. > > > > 3. Proof > > > > 3.1. The message encoding condition is necessary. > > > > We first note that this condition is a necessary condition for a JSON > based > > protocol to have a syntactically equivalent YANG model by proving its > > contrapositive. > > > > If one of the keys in the key-value pair in the JSON document is not > > pre-defined, the corresponding XML tags will not be pre-defined keywords. > > Therefore, it would not possible to model it in YANG without using > > YANG's anyxml > > statement (which allows arbitrary XML content). > > > > However, using the anyxml statement would defeat our purpose of modeling > > the data as it allows arbitrary XML content, and will not be helpful in > the > > subsequent parsing process. > > > > 3.2. The message encoding condition is sufficient. > > > > We prove this by providing a translation procedure from a JSON message > that > > is compliant with the protocol we are trying to model, to a custom java > > class that can be used for Jackson data binding, then to a YANG model. > > > > We note that the middle step of translating to and from the custom parser > > class is not necessary, but it will be useful. > > > > 3.2.1. motivation > > > > JSON data binding is the process of binding data structures (objects, > > arrays, etc.) in JSON to the appropriate data structures in the server > > (e.g. java classes, database tables, etc.) in parsing the JSON text. In > > order to process JSON messages in a meaningful manner, data binding is > > necessary. Even if the binding is not explicit, the server would need to > do > > it eventually. For example, one can read JSON content in a stream without > > binding it to the java classes, but eventually in order to make sense of > > the data, the server would eventually have to organize it, which is > roughly > > analogous to data binding upfront. Popular choices for JSON parsing and > > data binding include jackson and gson. > > > > We use Jackson full data binding as our approach. Full data binding binds > > JSON content into plain old java objects (POJOs), i.e. this custom parser > > class can neither extend nor implement any other class. Jackson uses > > ObjectMapper with the custom parser class to parse JSON content into this > > class. > > > > 3.2.2. The message encoding condition > > > > The message encoding condition is that all keys in each key-value pair in > > the JSON text must be pre-defined keywords. As the keys will become > either > > class names and instance variable names, or be keys in the java maps, it > is > > easy to see that the condition is equivalent to "there exists a full data > > binding in Jackson custom parser class without using any map structures > > (Map)." > > > > 3.2.3. Proof > > > > We provide a recursive binding process from a JSON object to the Jackson > > custom parser class to be used by Jackson ObjectMapper. > > > > Type determine_type(value) { > > > > if (value is of a primitive type, i.e. string, number, boolean, null) { > > > > return the corresponding java primitive type; > > > > } > > > > if (value is a JSON object) { > > > > return build_parser_class(value).class; > > > > } > > > > if (value is an array) { > > > > return ArrayList where T=determine_type(value[0]); > > > > } > > > > // should not reach here. > > > > } > > > > Class build_parser_class(JSONObject obj) { > > > > create custom class C; > > > > for each key/value pair in the obj { > > > > add instance variable v in C; > > > > the name of variable v <- key; // (__known__ a/c to our assumption) > > > > the type of variable v <- determine_type(value); > > > > } > > > > return C.class; > > > > } > > > > Naming: > > > > --change everything into CamelCase (i.e. remove dashes, etc.) > > > > --for instance variables, use "my" prefix, (e.g. myVariable, > myNetworkMap, > > etc.) > > > > --for the custom class name, if the object is an element of the array, > use > > "Element" suffix. > > > > This is just one convention so that the next step proceeds smoothly. As > > long as this naming translation is consistent with the naming stage in > the > > next step, it will work just fine. > > > > Example (a modified ALTO protocol network map example): > > > > JSON object: > > > > { > > > > "meta": { > > > > "resource-id": "my-default-map", > > > > "tag": "aab875ef69c87d012" > > > > }, > > > > "network-map": [ > > > > { > > > > "src": "PID1", > > > > "dsts": ["PID1", "PID2", "PID3"] > > > > }, > > > > { > > > > "src": "PID2", > > > > "dsts": ["PID1", "PID3"] > > > > }, > > > > { > > > > "src": "PID3", > > > > "dsts": ["PID2", "PID3"] > > > > } > > > > ] > > > > } > > > > Result of build_parser_class(obj): > > > > Class JSONObject { > > > > Meta myMeta; > > > > ArrayList myNetworkMap; > > > > } > > > > Class Meta { > > > > String myResourceId; > > > > String myTag; > > > > } > > > > Class NetworkMapElement { > > > > String mySrc; > > > > ArrayList myDsts; > > > > } > > > > Now given the Jackson Parser Java Class, to get a syntactically > equivalent > > YANG model: > > > > YANGModel build_yang_model(Class C) { > > > > for each instance variable (Type, Name) { > > > > if (Type is primitive type: string, number, boolean, null) { > > > > add the following to the YANG module: > > > > "leaf Name { type ; }" > > > > } > > > > if (Type is an ArrayList) { > > > > if (TypeElement is primitive type) { > > > > add the following to the YANG module: > > > > "leaf-list Name { type ; }" > > > > } else { > > > > // TypeElement is a custom parser class > > > > add the following to the YANG module: > > > > "list Name { > }" > > > > } > > > > } > > > > if (Type is a custom parser class) { > > > > add the following to the YANG module: > > > > "container Name { > }" > > > > } > > > > } > > > > } > > > > Result from the previous example: > > > > container meta { > > > > leaf resource-id { > > > > type string; > > > > } > > > > leaf tag { > > > > type string; > > > > } > > > > } > > > > list network-map { > > > > leaf src { > > > > type string; > > > > } > > > > leaf-list dsts { > > > > type string; > > > > } > > > > } > > > > This does validate the JSON document with XML-JSON encoding. For your > > reference, this is the XML document which validates: > > > > > > > > > > > > my-default-map > > > > aab875ef69c87d012 > > > > > > > > > > > > PID1 > > > > PID1 > > > > PID2 > > > > PID3 > > > > > > > > > > > > PID2 > > > > PID1 > > > > PID3 > > > > > > > > > > > > PID3 > > > > PID2 > > > > PID3 > > > > > > > > This proves that the message encoding condition is a sufficient condition > > for the JSON object to have a YANG model. > > > > Note the model generated is very crude and lose almost all constraints > and > > all inheritance features (if any), because it focuses on the syntax and > is > > essentially converted from an JSON object compliant with a protocol > instead > > of from the protocol itself. Hence this result is more useful in > > determining which JSON based protocols cannot have a syntactically > > equivalent YANG model, than in generating a good YANG model. > > > > 3.3. Conclusion > > > > Our claim holds. A JSON based protocol carried by HTTP can have > > syntactically equivalent YANG model, if and only if all the keys in the > > key-value pairs in the JSON message are pre-defined keywords. > > > > 4. Semantic equivalence > > > > For JSON based protocols that don't satisfy the message encoding > condition, > > it is still possible to have a semantically equivalent YANG model. All > that > > is required for the protocol compliant clients and the YANG model > compliant > > server to interoperate is an adapter which does the following: > > > > 1) translate FROM YANG server compliant response msg TO alto compliant > > response msg > > > > 2) translate FROM alto compliant request msg TO YANG server compliant > > request msg > > > > 4.1. Claim > > > > This adapter needs to be protocol-aware. > > > > Ideally, given any YANG model, we would like to be able to automatically > > (or at least mechanically) generate this message adapter, which means not > > looking at the protocol or its compliant msgs. However, without knowing > the > > specific protocol that we are working with (i.e. human intervention, i.e. > > looking at the protocol compliant msgs), such an adapter cannot be > > auto-generated. > > > > 4.2. Proof by Indistinguishability > > > > Suppose both the YANG server compliant msg m_y and the actually protocol > > compliant msg m_p are in JSON (or have been encoded into JSON). Looking > at > > the differences between the two messages, call these differences {d1, d2, > > ..., dn}. The goal for the auto-generated adapter would be to identify > and > > eliminate these differences. Construct a new JSON msg m' where all but > one > > difference di is the same as m_p and di is the same as the m_y. Without > > looking at the protocol (or m_p), the auto-generated adapter would not be > > able to distinguish between m' and m_p in its translation process, which > > means, it won't be able to tell whether it should change di or not. > Hence, > > such an adapter must be protocol-aware. > > > > A good example is the dependent-vtag in the ALTO protocol: > > > > "dependent-vtag" : [ > > > > { > > > > "resource-id" : "my-network-map", > > > > "tag" : "abcd1234" > > > > } > > > > ] > > > > It was specified this way in the alto protocol. However, it could > > conceivably be the case that it was originally the following map > structure, > > and was converted into the above encoding because of the map->list+key > > issue. (This case is actually one of the few differences in the m_y and > m_p > > where the adapter does not need to convert it back to a map structure.) > > > > "dependent-vtag" : { > > > > "my-network-map" : { > > > > "tag" : "abcd1234" > > > > } > > > > } > > > > Without knowing the protocol, there is no way to tell. > > > > 5. Ramifications > > > > We now understand the basic condition for a JSON based protocol to have a > > YANG Model. For the protocols that don't meet this condition, there can > be > > a semantic equivalent YANG model, but there won't be a generic process of > > generating the adapter for all such protocols. > > _______________________________________________ > > 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 > --001a11c13e4ab941f80505dc5f08 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mon, Oct 20, 2014 at 6:23 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:
Xiao SHI <xiao.shi@yale.edu> writes:

> Hi folks,
>
>
> As a few of us were working on modeling the ALTO protocol using YANG, = we
> were pondering on a more general question: can YANG model all JSON bas= ed
> protocols? What is the condition for a JSON based protocol (at least t= he
> message format) to have an syntactically equivalent, hence interoperab= le,
> YANG model with JSON encoding? Alternatively, in order to interoperate= ,
> semantic equivalence might be sufficient, is there any condition for > semantic equivalence?
>
>
> tl;dr: A JSON based protocol carried by HTTP can have syntactically > equivalent YANG model, if and only if all the keys in the key-value pa= irs
> in the JSON message are pre-defined keywords in the protocol.
>

Generating a YANG data model from existing instance data seems backwards to me, although Examplotron (http://examplotron.org) does something quite
similar. In any case, it might be quite challenging because YANG isn't<= br> intended as a general schema language. Your observation above is true
but it is just one aspect of the problem. For instance

"foo": [ { "bar": 1 }, 2 ]

or

"foo": null

cannot be modelled in YANG using the encoding of
draft-ietf-netmod-yang-json.



I think perhaps RESTCON= F is overloading JSON and this has led to some confusion.
RESTCON= F uses JSON strictly as an encoding format, not a data structure.  JSO= N is just
the message encoding. The corresponding instance docume= nt must conform to
the YANG definitions (not just be valid JSON).=

A protocol should pick between YANG data structur= es and JSON data structures,
and not try to do both.

 
Lada


Andy
 
>
> We've come up with a few ideas, and a few things below are work in=
> progress, but we would love your feedback!
>
>
> Thank you!
>
> Xiao
>
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> 1. Introduction.
>
> JavaScript Object Notation (JSON) has been a popular choice as the mes= sage
> encoding for many network protocols such as the Application Layer Traf= fic
> Optimization (ALTO) protocol, the Content Delivery Networks Interconne= ction
> (CDNi) protocol, etc.
>
> Meanwhile, there are broad interests in the networking community to us= e
> YANG to define data model so that one can use YANG related tools such = as
> OpenDayLight controller. Although YANG itself is XML based, there have= been
> efforts to model JSON content using YANG [draft-ietf-netmod-yang-json-= 01].
>
> A natural question rises: can YANG model all JSON based protocols? Wha= t is
> the condition for a JSON based protocol (at least the message format) = to
> have an syntactically equivalent, hence interoperable, YANG model with= JSON
> encoding? Alternatively, in order to interoperate, semantic equivalenc= e
> might be sufficient, is there any condition for semantic equivalence?<= br> >
> 2. Claim
>
> A JSON based protocol carried by HTTP can have syntactically equivalen= t
> YANG model, if and only if:
>
> (1) the message encoding condition is met;
>
> (2) the uri condition is met.
>
> 2.1. The message encoding condition
>
> The JSON message encoding MUST not contain a variable as a key in a JS= ON
> object key-value pair. In other words, the keys in the JSON message mu= st be
> an already defined constant (or keyword) in the message format of the<= br> > protocol.
>
> For example, if I have a protocol where “network-map”, &ld= quo;src”, and “dsts”
> are defined keywords, JSON text A meets the condition whereas B does n= ot
> because “PID1” and “PID2” are not protocol key= words (they are resource IDs).
>
> A:
>
> {
>
>  “network-map”: [
>
>    {
>
>      “src”: “PID1”,
>
>      “dsts”: [“PID2”, “PI= D3”]
>
>    },
>
>    {
>
>      “src”: “PID2”,
>
>      “dsts”: [“PID3”, “PI= D4”]
>
>    }
>
>  ]
>
> }
>
> B:
>
>
> {
>
>  “network-map”: [
>
>    “PID1: [“PID2”, “PID3”], >
>    “PID2”: [“PID3”, “PID4&rdqu= o;]
>
>  ]
>
> }
>
>>From this we know that since ALTO protocol uses encoding B, there c= annot be
> a syntactically equivalent YANG model.
>
> 2.2 The URI condition
>
> Some of the YANG-related protocols might have URI constraints, e.g. > RESTCONF. For now, we assume either that the JSON-based protocol URI c= ould
> be conformed to RESTCONF compliant uri, or that the server could have = a
> routing mapping between the protocol compliant uri and the RESTCONF > compliant uri, hence this condition would not be an issue, which allow= s us
> to focus on the message encoding condition.
>
> 3. Proof
>
> 3.1. The message encoding condition is necessary.
>
> We first note that this condition is a necessary condition for a JSON = based
> protocol to have a syntactically equivalent YANG model by proving its<= br> > contrapositive.
>
> If one of the keys in the key-value pair in the JSON document is not > pre-defined, the corresponding XML tags will not be pre-defined keywor= ds.
> Therefore, it would not possible to model it in YANG without using
> YANG’s anyxml
> statement (which allows arbitrary XML content).
>
> However, using the anyxml statement would defeat our purpose of modeli= ng
> the data as it allows arbitrary XML content, and will not be helpful i= n the
> subsequent parsing process.
>
> 3.2. The message encoding condition is sufficient.
>
> We prove this by providing a translation procedure from a JSON message= that
> is compliant with the protocol we are trying to model, to a custom jav= a
> class that can be used for Jackson data binding, then to a YANG model.=
>
> We note that the middle step of translating to and from the custom par= ser
> class is not necessary, but it will be useful.
>
> 3.2.1. motivation
>
> JSON data binding is the process of binding data structures (objects,<= br> > arrays, etc.) in JSON to the appropriate data structures in the server=
> (e.g. java classes, database tables, etc.) in parsing the JSON text. I= n
> order to process JSON messages in a meaningful manner, data binding is=
> necessary. Even if the binding is not explicit, the server would need = to do
> it eventually. For example, one can read JSON content in a stream with= out
> binding it to the java classes, but eventually in order to make sense = of
> the data, the server would eventually have to organize it, which is ro= ughly
> analogous to data binding upfront. Popular choices for JSON parsing an= d
> data binding include jackson and gson.
>
> We use Jackson full data binding as our approach. Full data binding bi= nds
> JSON content into plain old java objects (POJOs), i.e. this custom par= ser
> class can neither extend nor implement any other class. Jackson uses > ObjectMapper with the custom parser class to parse JSON content into t= his
> class.
>
> 3.2.2. The message encoding condition
>
> The message encoding condition is that all keys in each key-value pair= in
> the JSON text must be pre-defined keywords. As the keys will become ei= ther
> class names and instance variable names, or be keys in the java maps, = it is
> easy to see that the condition is equivalent to “there exists a = full data
> binding in Jackson custom parser class without using any map structure= s
> (Map<String, ?>).”
>
> 3.2.3. Proof
>
> We provide a recursive binding process from a JSON object to the Jacks= on
> custom parser class to be used by Jackson ObjectMapper.
>
> Type determine_type(value) {
>
>  if (value is of a primitive type, i.e. string, number, boolean, = null) {
>
>    return the corresponding java primitive type;
>
>  }
>
>  if (value is a JSON object) {
>
>    return build_parser_class(value).class;
>
>  }
>
>  if (value is an array) {
>
>    return ArrayList<T> where T=3Ddetermine_type(value[= 0]);
>
>  }
>
>  // should not reach here.
>
> }
>
> Class build_parser_class(JSONObject obj) {
>
>  create custom class C;
>
>  for each key/value pair in the obj {
>
>    add instance variable v in C;
>
>    the name of variable v <- key; // (__known__ a/c to ou= r assumption)
>
>    the type of variable v <- determine_type(value);
>
>  }
>
>  return C.class;
>
> }
>
> Naming:
>
> --change everything into CamelCase (i.e. remove dashes, etc.)
>
> --for instance variables, use “my” prefix, (e.g. myVariabl= e, myNetworkMap,
> etc.)
>
> --for the custom class name, if the object is an element of the array,= use
> “Element” suffix.
>
> This is just one convention so that the next step proceeds smoothly. A= s
> long as this naming translation is consistent with the naming stage in= the
> next step, it will work just fine.
>
> Example (a modified ALTO protocol network map example):
>
> JSON object:
>
> {
>
>  “meta”: {
>
>    “resource-id”: “my-default-map”,<= br> >
>    “tag”: “aab875ef69c87d012”
>
>  },
>
>  “network-map”: [
>
>    {
>
>      “src”: “PID1”,
>
>      “dsts”: [“PID1”, “PI= D2”, “PID3”]
>
>    },
>
>    {
>
>      “src”: “PID2”,
>
>      “dsts”: [“PID1”, “PI= D3”]
>
>    },
>
>    {
>
>      “src”: “PID3”,
>
>      “dsts”: [“PID2”, “PI= D3”]
>
>    }
>
>  ]
>
> }
>
> Result of build_parser_class(obj):
>
> Class JSONObject {
>
>  Meta myMeta;
>
>  ArrayList<NetworkMapElement> myNetworkMap;
>
> }
>
> Class Meta {
>
>  String myResourceId;
>
>  String myTag;
>
> }
>
> Class NetworkMapElement {
>
>  String mySrc;
>
>  ArrayList<String> myDsts;
>
> }
>
> Now given the Jackson Parser Java Class, to get a syntactically equiva= lent
> YANG model:
>
> YANGModel build_yang_model(Class C) {
>
>  for each instance variable (Type, Name) {
>
>    if (Type is primitive type: string, number, boolean, null= ) {
>
>      add the following to the YANG module:
>
>      “leaf Name { type <YANG equivalent of Typ= e>; }”
>
>    }
>
>    if (Type is an ArrayList<TypeElement>) {
>
>      if (TypeElement is primitive type) {
>
>        add the following to the YANG module:
>
>        “leaf-list Name { type <YANG equiv= alent of TypeElement>; }”
>
>      } else {
>
>        // TypeElement is a custom parser class
>
>        add the following to the YANG module:
>
>        “list Name { <result from build_ya= ng_model<TypeElement.class>> }”
>
>      }
>
>    }
>
>    if (Type is a custom parser class) {
>
>      add the following to the YANG module:
>
>      “container Name { <result from build_yang= _model<Type.class>> }”
>
>    }
>
>  }
>
> }
>
> Result from the previous example:
>
> container meta {
>
>  leaf resource-id {
>
>    type string;
>
>  }
>
>  leaf tag {
>
>    type string;
>
>  }
>
> }
>
> list network-map {
>
>  leaf src {
>
>    type string;
>
>  }
>
>  leaf-list dsts {
>
>    type string;
>
>  }
>
> }
>
> This does validate the JSON document with XML-JSON encoding. For your<= br> > reference, this is the XML document which validates:
>
> <?xml version=3D"1.0" encoding=3D"UTF-8" ?><= br> >
> <meta>
>
>  <resource-id>my-default-map</resource-id>
>
>  <tag>aab875ef69c87d012</tag>
>
> </meta>
>
> <network-map>
>
>  <src>PID1</src>
>
>  <dsts>PID1</dsts>
>
>  <dsts>PID2</dsts>
>
>  <dsts>PID3</dsts>
>
> </network-map>
>
> <network-map>
>
>  <src>PID2</src>
>
>  <dsts>PID1</dsts>
>
>  <dsts>PID3</dsts>
>
> </network-map>
>
> <network-map>
>
>  <src>PID3</src>
>
>  <dsts>PID2</dsts>
>
>  <dsts>PID3</dsts>
>
> </network-map>
>
> This proves that the message encoding condition is a sufficient condit= ion
> for the JSON object to have a YANG model.
>
> Note the model generated is very crude and lose almost all constraints= and
> all inheritance features (if any), because it focuses on the syntax an= d is
> essentially converted from an JSON object compliant with a protocol in= stead
> of from the protocol itself. Hence this result is more useful in
> determining which JSON based protocols cannot have a syntactically
> equivalent YANG model, than in generating a good YANG model.
>
> 3.3. Conclusion
>
> Our claim holds. A JSON based protocol carried by HTTP can have
> syntactically equivalent YANG model, if and only if all the keys in th= e
> key-value pairs in the JSON message are pre-defined keywords.
>
> 4. Semantic equivalence
>
> For JSON based protocols that don’t satisfy the message encoding= condition,
> it is still possible to have a semantically equivalent YANG model. All= that
> is required for the protocol compliant clients and the YANG model comp= liant
> server to interoperate is an adapter which does the following:
>
> 1) translate FROM YANG server compliant response msg TO alto compliant=
> response msg
>
> 2) translate FROM alto compliant request msg TO YANG server compliant<= br> > request msg
>
> 4.1. Claim
>
> This adapter needs to be protocol-aware.
>
> Ideally, given any YANG model, we would like to be able to automatical= ly
> (or at least mechanically) generate this message adapter, which means = not
> looking at the protocol or its compliant msgs. However, without knowin= g the
> specific protocol that we are working with (i.e. human intervention, i= .e.
> looking at the protocol compliant msgs), such an adapter cannot be
> auto-generated.
>
> 4.2. Proof by Indistinguishability
>
> Suppose both the YANG server compliant msg m_y and the actually protoc= ol
> compliant msg m_p are in JSON (or have been encoded into JSON). Lookin= g at
> the differences between the two messages, call these differences {d1, = d2,
> ..., dn}. The goal for the auto-generated adapter would be to identify= and
> eliminate these differences. Construct a new JSON msg m' where all= but one
> difference di is the same as m_p and di is the same as the m_y. Withou= t
> looking at the protocol (or m_p), the auto-generated adapter would not= be
> able to distinguish between m' and m_p in its translation process,= which
> means, it won't be able to tell whether it should change di or not= . Hence,
> such an adapter must be protocol-aware.
>
> A good example is the dependent-vtag in the ALTO protocol:
>
> "dependent-vtag" : [
>
>  {
>
>    "resource-id" : "my-network-map",
>
>    "tag" : "abcd1234"
>
>  }
>
> ]
>
> It was specified this way in the alto protocol. However, it could
> conceivably be the case that it was originally the following map struc= ture,
> and was converted into the above encoding because of the map->list+= key
> issue. (This case is actually one of the few differences in the m_y an= d m_p
> where the adapter does not need to convert it back to a map structure.= )
>
> "dependent-vtag" : {
>
>  "my-network-map" : {
>
>    "tag" : "abcd1234"
>
>  }
>
> }
>
> Without knowing the protocol, there is no way to tell.
>
> 5. Ramifications
>
> We now understand the basic condition for a JSON based protocol to hav= e a
> YANG Model. For the protocols that don’t meet this condition, th= ere can be
> a semantic equivalent YANG model, but there won’t be a generic p= rocess of
> generating the adapter for all such protocols.
> _______________________________________________
> 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

--001a11c13e4ab941f80505dc5f08-- From nobody Mon Oct 20 08:36:20 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52A5B1A1BB9; Mon, 20 Oct 2014 08:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7NhTY7LFPHV; Mon, 20 Oct 2014 08:36:06 -0700 (PDT) Received: from mail-yh0-x233.google.com (mail-yh0-x233.google.com [IPv6:2607:f8b0:4002:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4556F1A0394; Mon, 20 Oct 2014 08:34:17 -0700 (PDT) Received: by mail-yh0-f51.google.com with SMTP id t59so3323955yho.24 for ; Mon, 20 Oct 2014 08:34:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=LHk8ZCbtOrBnQhCUbTlcLXVCRu4HeiWShfcGc0UXG7Y=; b=t17zsFDZiYuwIsDuX3golkXuXnuV28hOVPHLEN+ds51solRFhZPdTZxMZNysZhB8Lf V48Qf70/oQMVg6K5yijnCVCskObWfRYxL2Rv2377Atx2LGHbbu6CKGbk+avZtO86/+yg aWPxzCBhl6ISCTeBjzrQklPA+LBmLtLMhRNpFGxVurbNle31ZMYXnJ1JU2wiw3ELxrA8 TQzsH2HtaMr5qSrk5Gac5bUUll3vxRcxYxwSrnYMbpGfGdM7BQLbFktdJBsKZEh5VCl/ cGBn4Ya/aoHrbEgfftO0L2APGT9P9Z1j/wMvHimfCqMH51UMpcG0EzOfQLJRpxapeOdM 4zYQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yale.edu; s=googleprd; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=LHk8ZCbtOrBnQhCUbTlcLXVCRu4HeiWShfcGc0UXG7Y=; b=18rEp1+GnV6j24VrMA3H/Gnhjt1TKx+VLShB6/GqMg3WgykN6bHTqycS0faea+Xnh3 ZEEe0fw1S+rchS/3k420WecFo91ZMcYtyoAf/tibY3M6SrnYVbRCTYXVOWwjqPpWsu45 K7ABUF8LARKYv3kDlvz9h6+IpTaF3s0ntCGMs= X-Received: by 10.236.25.166 with SMTP id z26mr38365055yhz.69.1413819256449; Mon, 20 Oct 2014 08:34:16 -0700 (PDT) MIME-Version: 1.0 Sender: boxs.jq@gmail.com Received: by 10.170.97.10 with HTTP; Mon, 20 Oct 2014 08:33:56 -0700 (PDT) In-Reply-To: References: From: Xiao SHI Date: Mon, 20 Oct 2014 11:33:56 -0400 X-Google-Sender-Auth: 5BxpoA8xntepbAUVif-_PzRF3rE Message-ID: To: Andy Bierman Content-Type: multipart/alternative; boundary=089e013d08908eaeef0505dc7288 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Qh--ed0lPbOwvjsvfVQirIRQaRU Cc: "netmod@ietf.org" , IETF ALTO Subject: Re: [netmod] Modeling JSON based protocols using YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 20 Oct 2014 15:36:11 -0000 --089e013d08908eaeef0505dc7288 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Andy, I agree with you. Just to clarify, what I am trying to do is to use YANG data structures for the protocol whose message encoding is JSON. I am not trying to use JSON as a data structure. Does this make sense? Best, Xiao On Mon, Oct 20, 2014 at 11:29 AM, Andy Bierman wrote: > > > On Mon, Oct 20, 2014 at 6:23 AM, Ladislav Lhotka wrote: > >> Xiao SHI writes: >> >> > Hi folks, >> > >> > >> > As a few of us were working on modeling the ALTO protocol using YANG, = we >> > were pondering on a more general question: can YANG model all JSON bas= ed >> > protocols? What is the condition for a JSON based protocol (at least t= he >> > message format) to have an syntactically equivalent, hence >> interoperable, >> > YANG model with JSON encoding? Alternatively, in order to interoperate= , >> > semantic equivalence might be sufficient, is there any condition for >> > semantic equivalence? >> > >> > >> > tl;dr: A JSON based protocol carried by HTTP can have syntactically >> > equivalent YANG model, if and only if all the keys in the key-value >> pairs >> > in the JSON message are pre-defined keywords in the protocol. >> > >> >> Generating a YANG data model from existing instance data seems backwards >> to me, although Examplotron (http://examplotron.org) does something quit= e >> similar. In any case, it might be quite challenging because YANG isn't >> intended as a general schema language. Your observation above is true >> but it is just one aspect of the problem. For instance >> >> "foo": [ { "bar": 1 }, 2 ] >> >> or >> >> "foo": null >> >> cannot be modelled in YANG using the encoding of >> draft-ietf-netmod-yang-json. >> >> > > I think perhaps RESTCONF is overloading JSON and this has led to some > confusion. > RESTCONF uses JSON strictly as an encoding format, not a data structure. > JSON is just > the message encoding. The corresponding instance document must conform to > the YANG definitions (not just be valid JSON). > > A protocol should pick between YANG data structures and JSON data > structures, > and not try to do both. > > > > >> Lada >> >> > Andy > > >> > >> > We've come up with a few ideas, and a few things below are work in >> > progress, but we would love your feedback! >> > >> > >> > Thank you! >> > >> > Xiao >> > >> > >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > >> > 1. Introduction. >> > >> > JavaScript Object Notation (JSON) has been a popular choice as the >> message >> > encoding for many network protocols such as the Application Layer >> Traffic >> > Optimization (ALTO) protocol, the Content Delivery Networks >> Interconnection >> > (CDNi) protocol, etc. >> > >> > Meanwhile, there are broad interests in the networking community to us= e >> > YANG to define data model so that one can use YANG related tools such = as >> > OpenDayLight controller. Although YANG itself is XML based, there have >> been >> > efforts to model JSON content using YANG >> [draft-ietf-netmod-yang-json-01]. >> > >> > A natural question rises: can YANG model all JSON based protocols? Wha= t >> is >> > the condition for a JSON based protocol (at least the message format) = to >> > have an syntactically equivalent, hence interoperable, YANG model with >> JSON >> > encoding? Alternatively, in order to interoperate, semantic equivalenc= e >> > might be sufficient, is there any condition for semantic equivalence? >> > >> > 2. Claim >> > >> > A JSON based protocol carried by HTTP can have syntactically equivalen= t >> > YANG model, if and only if: >> > >> > (1) the message encoding condition is met; >> > >> > (2) the uri condition is met. >> > >> > 2.1. The message encoding condition >> > >> > The JSON message encoding MUST not contain a variable as a key in a JS= ON >> > object key-value pair. In other words, the keys in the JSON message >> must be >> > an already defined constant (or keyword) in the message format of the >> > protocol. >> > >> > For example, if I have a protocol where =E2=80=9Cnetwork-map=E2=80=9D,= =E2=80=9Csrc=E2=80=9D, and =E2=80=9Cdsts=E2=80=9D >> > are defined keywords, JSON text A meets the condition whereas B does n= ot >> > because =E2=80=9CPID1=E2=80=9D and =E2=80=9CPID2=E2=80=9D are not prot= ocol keywords (they are resource >> IDs). >> > >> > A: >> > >> > { >> > >> > =E2=80=9Cnetwork-map=E2=80=9D: [ >> > >> > { >> > >> > =E2=80=9Csrc=E2=80=9D: =E2=80=9CPID1=E2=80=9D, >> > >> > =E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID2=E2=80=9D, =E2=80=9CPID3=E2= =80=9D] >> > >> > }, >> > >> > { >> > >> > =E2=80=9Csrc=E2=80=9D: =E2=80=9CPID2=E2=80=9D, >> > >> > =E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID3=E2=80=9D, =E2=80=9CPID4=E2= =80=9D] >> > >> > } >> > >> > ] >> > >> > } >> > >> > B: >> > >> > >> > { >> > >> > =E2=80=9Cnetwork-map=E2=80=9D: [ >> > >> > =E2=80=9CPID1: [=E2=80=9CPID2=E2=80=9D, =E2=80=9CPID3=E2=80=9D], >> > >> > =E2=80=9CPID2=E2=80=9D: [=E2=80=9CPID3=E2=80=9D, =E2=80=9CPID4=E2= =80=9D] >> > >> > ] >> > >> > } >> > >> >>From this we know that since ALTO protocol uses encoding B, there >> cannot be >> > a syntactically equivalent YANG model. >> > >> > 2.2 The URI condition >> > >> > Some of the YANG-related protocols might have URI constraints, e.g. >> > RESTCONF. For now, we assume either that the JSON-based protocol URI >> could >> > be conformed to RESTCONF compliant uri, or that the server could have = a >> > routing mapping between the protocol compliant uri and the RESTCONF >> > compliant uri, hence this condition would not be an issue, which allow= s >> us >> > to focus on the message encoding condition. >> > >> > 3. Proof >> > >> > 3.1. The message encoding condition is necessary. >> > >> > We first note that this condition is a necessary condition for a JSON >> based >> > protocol to have a syntactically equivalent YANG model by proving its >> > contrapositive. >> > >> > If one of the keys in the key-value pair in the JSON document is not >> > pre-defined, the corresponding XML tags will not be pre-defined >> keywords. >> > Therefore, it would not possible to model it in YANG without using >> > YANG=E2=80=99s anyxml >> > statement (which allows arbitrary XML content). >> > >> > However, using the anyxml statement would defeat our purpose of modeli= ng >> > the data as it allows arbitrary XML content, and will not be helpful i= n >> the >> > subsequent parsing process. >> > >> > 3.2. The message encoding condition is sufficient. >> > >> > We prove this by providing a translation procedure from a JSON message >> that >> > is compliant with the protocol we are trying to model, to a custom jav= a >> > class that can be used for Jackson data binding, then to a YANG model. >> > >> > We note that the middle step of translating to and from the custom >> parser >> > class is not necessary, but it will be useful. >> > >> > 3.2.1. motivation >> > >> > JSON data binding is the process of binding data structures (objects, >> > arrays, etc.) in JSON to the appropriate data structures in the server >> > (e.g. java classes, database tables, etc.) in parsing the JSON text. I= n >> > order to process JSON messages in a meaningful manner, data binding is >> > necessary. Even if the binding is not explicit, the server would need >> to do >> > it eventually. For example, one can read JSON content in a stream >> without >> > binding it to the java classes, but eventually in order to make sense = of >> > the data, the server would eventually have to organize it, which is >> roughly >> > analogous to data binding upfront. Popular choices for JSON parsing an= d >> > data binding include jackson and gson. >> > >> > We use Jackson full data binding as our approach. Full data binding >> binds >> > JSON content into plain old java objects (POJOs), i.e. this custom >> parser >> > class can neither extend nor implement any other class. Jackson uses >> > ObjectMapper with the custom parser class to parse JSON content into >> this >> > class. >> > >> > 3.2.2. The message encoding condition >> > >> > The message encoding condition is that all keys in each key-value pair >> in >> > the JSON text must be pre-defined keywords. As the keys will become >> either >> > class names and instance variable names, or be keys in the java maps, >> it is >> > easy to see that the condition is equivalent to =E2=80=9Cthere exists = a full >> data >> > binding in Jackson custom parser class without using any map structure= s >> > (Map).=E2=80=9D >> > >> > 3.2.3. Proof >> > >> > We provide a recursive binding process from a JSON object to the Jacks= on >> > custom parser class to be used by Jackson ObjectMapper. >> > >> > Type determine_type(value) { >> > >> > if (value is of a primitive type, i.e. string, number, boolean, null)= { >> > >> > return the corresponding java primitive type; >> > >> > } >> > >> > if (value is a JSON object) { >> > >> > return build_parser_class(value).class; >> > >> > } >> > >> > if (value is an array) { >> > >> > return ArrayList where T=3Ddetermine_type(value[0]); >> > >> > } >> > >> > // should not reach here. >> > >> > } >> > >> > Class build_parser_class(JSONObject obj) { >> > >> > create custom class C; >> > >> > for each key/value pair in the obj { >> > >> > add instance variable v in C; >> > >> > the name of variable v <- key; // (__known__ a/c to our assumption) >> > >> > the type of variable v <- determine_type(value); >> > >> > } >> > >> > return C.class; >> > >> > } >> > >> > Naming: >> > >> > --change everything into CamelCase (i.e. remove dashes, etc.) >> > >> > --for instance variables, use =E2=80=9Cmy=E2=80=9D prefix, (e.g. myVar= iable, >> myNetworkMap, >> > etc.) >> > >> > --for the custom class name, if the object is an element of the array, >> use >> > =E2=80=9CElement=E2=80=9D suffix. >> > >> > This is just one convention so that the next step proceeds smoothly. A= s >> > long as this naming translation is consistent with the naming stage in >> the >> > next step, it will work just fine. >> > >> > Example (a modified ALTO protocol network map example): >> > >> > JSON object: >> > >> > { >> > >> > =E2=80=9Cmeta=E2=80=9D: { >> > >> > =E2=80=9Cresource-id=E2=80=9D: =E2=80=9Cmy-default-map=E2=80=9D, >> > >> > =E2=80=9Ctag=E2=80=9D: =E2=80=9Caab875ef69c87d012=E2=80=9D >> > >> > }, >> > >> > =E2=80=9Cnetwork-map=E2=80=9D: [ >> > >> > { >> > >> > =E2=80=9Csrc=E2=80=9D: =E2=80=9CPID1=E2=80=9D, >> > >> > =E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID1=E2=80=9D, =E2=80=9CPID2=E2= =80=9D, =E2=80=9CPID3=E2=80=9D] >> > >> > }, >> > >> > { >> > >> > =E2=80=9Csrc=E2=80=9D: =E2=80=9CPID2=E2=80=9D, >> > >> > =E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID1=E2=80=9D, =E2=80=9CPID3=E2= =80=9D] >> > >> > }, >> > >> > { >> > >> > =E2=80=9Csrc=E2=80=9D: =E2=80=9CPID3=E2=80=9D, >> > >> > =E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID2=E2=80=9D, =E2=80=9CPID3=E2= =80=9D] >> > >> > } >> > >> > ] >> > >> > } >> > >> > Result of build_parser_class(obj): >> > >> > Class JSONObject { >> > >> > Meta myMeta; >> > >> > ArrayList myNetworkMap; >> > >> > } >> > >> > Class Meta { >> > >> > String myResourceId; >> > >> > String myTag; >> > >> > } >> > >> > Class NetworkMapElement { >> > >> > String mySrc; >> > >> > ArrayList myDsts; >> > >> > } >> > >> > Now given the Jackson Parser Java Class, to get a syntactically >> equivalent >> > YANG model: >> > >> > YANGModel build_yang_model(Class C) { >> > >> > for each instance variable (Type, Name) { >> > >> > if (Type is primitive type: string, number, boolean, null) { >> > >> > add the following to the YANG module: >> > >> > =E2=80=9Cleaf Name { type ; }=E2=80=9D >> > >> > } >> > >> > if (Type is an ArrayList) { >> > >> > if (TypeElement is primitive type) { >> > >> > add the following to the YANG module: >> > >> > =E2=80=9Cleaf-list Name { type = ; }=E2=80=9D >> > >> > } else { >> > >> > // TypeElement is a custom parser class >> > >> > add the following to the YANG module: >> > >> > =E2=80=9Clist Name { > }=E2=80=9D >> > >> > } >> > >> > } >> > >> > if (Type is a custom parser class) { >> > >> > add the following to the YANG module: >> > >> > =E2=80=9Ccontainer Name { > }=E2=80=9D >> > >> > } >> > >> > } >> > >> > } >> > >> > Result from the previous example: >> > >> > container meta { >> > >> > leaf resource-id { >> > >> > type string; >> > >> > } >> > >> > leaf tag { >> > >> > type string; >> > >> > } >> > >> > } >> > >> > list network-map { >> > >> > leaf src { >> > >> > type string; >> > >> > } >> > >> > leaf-list dsts { >> > >> > type string; >> > >> > } >> > >> > } >> > >> > This does validate the JSON document with XML-JSON encoding. For your >> > reference, this is the XML document which validates: >> > >> > >> > >> > >> > >> > my-default-map >> > >> > aab875ef69c87d012 >> > >> > >> > >> > >> > >> > PID1 >> > >> > PID1 >> > >> > PID2 >> > >> > PID3 >> > >> > >> > >> > >> > >> > PID2 >> > >> > PID1 >> > >> > PID3 >> > >> > >> > >> > >> > >> > PID3 >> > >> > PID2 >> > >> > PID3 >> > >> > >> > >> > This proves that the message encoding condition is a sufficient >> condition >> > for the JSON object to have a YANG model. >> > >> > Note the model generated is very crude and lose almost all constraints >> and >> > all inheritance features (if any), because it focuses on the syntax an= d >> is >> > essentially converted from an JSON object compliant with a protocol >> instead >> > of from the protocol itself. Hence this result is more useful in >> > determining which JSON based protocols cannot have a syntactically >> > equivalent YANG model, than in generating a good YANG model. >> > >> > 3.3. Conclusion >> > >> > Our claim holds. A JSON based protocol carried by HTTP can have >> > syntactically equivalent YANG model, if and only if all the keys in th= e >> > key-value pairs in the JSON message are pre-defined keywords. >> > >> > 4. Semantic equivalence >> > >> > For JSON based protocols that don=E2=80=99t satisfy the message encodi= ng >> condition, >> > it is still possible to have a semantically equivalent YANG model. All >> that >> > is required for the protocol compliant clients and the YANG model >> compliant >> > server to interoperate is an adapter which does the following: >> > >> > 1) translate FROM YANG server compliant response msg TO alto compliant >> > response msg >> > >> > 2) translate FROM alto compliant request msg TO YANG server compliant >> > request msg >> > >> > 4.1. Claim >> > >> > This adapter needs to be protocol-aware. >> > >> > Ideally, given any YANG model, we would like to be able to automatical= ly >> > (or at least mechanically) generate this message adapter, which means >> not >> > looking at the protocol or its compliant msgs. However, without knowin= g >> the >> > specific protocol that we are working with (i.e. human intervention, >> i.e. >> > looking at the protocol compliant msgs), such an adapter cannot be >> > auto-generated. >> > >> > 4.2. Proof by Indistinguishability >> > >> > Suppose both the YANG server compliant msg m_y and the actually protoc= ol >> > compliant msg m_p are in JSON (or have been encoded into JSON). Lookin= g >> at >> > the differences between the two messages, call these differences {d1, >> d2, >> > ..., dn}. The goal for the auto-generated adapter would be to identify >> and >> > eliminate these differences. Construct a new JSON msg m' where all but >> one >> > difference di is the same as m_p and di is the same as the m_y. Withou= t >> > looking at the protocol (or m_p), the auto-generated adapter would not >> be >> > able to distinguish between m' and m_p in its translation process, whi= ch >> > means, it won't be able to tell whether it should change di or not. >> Hence, >> > such an adapter must be protocol-aware. >> > >> > A good example is the dependent-vtag in the ALTO protocol: >> > >> > "dependent-vtag" : [ >> > >> > { >> > >> > "resource-id" : "my-network-map", >> > >> > "tag" : "abcd1234" >> > >> > } >> > >> > ] >> > >> > It was specified this way in the alto protocol. However, it could >> > conceivably be the case that it was originally the following map >> structure, >> > and was converted into the above encoding because of the map->list+key >> > issue. (This case is actually one of the few differences in the m_y an= d >> m_p >> > where the adapter does not need to convert it back to a map structure.= ) >> > >> > "dependent-vtag" : { >> > >> > "my-network-map" : { >> > >> > "tag" : "abcd1234" >> > >> > } >> > >> > } >> > >> > Without knowing the protocol, there is no way to tell. >> > >> > 5. Ramifications >> > >> > We now understand the basic condition for a JSON based protocol to hav= e >> a >> > YANG Model. For the protocols that don=E2=80=99t meet this condition, = there can >> be >> > a semantic equivalent YANG model, but there won=E2=80=99t be a generic= process >> of >> > generating the adapter for all such protocols. >> > _______________________________________________ >> > 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 >> > > --089e013d08908eaeef0505dc7288 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Andy,

I agree with you. Just to clar= ify, what I am trying to do is to use YANG data structures for the protocol= whose message encoding is JSON. I am not trying to use JSON as a data stru= cture. Does this make sense?

Best,
Xiao<= /div>

On Mon= , Oct 20, 2014 at 11:29 AM, Andy Bierman <andy@yumaworks.com> wrote:


On Mon, Oc= t 20, 2014 at 6:23 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
Xiao SHI <xiao.shi@yale.edu> = writes:

> Hi folks,
>
>
> As a few of us were working on modeling the ALTO protocol using YANG, = we
> were pondering on a more general question: can YANG model all JSON bas= ed
> protocols? What is the condition for a JSON based protocol (at least t= he
> message format) to have an syntactically equivalent, hence interoperab= le,
> YANG model with JSON encoding? Alternatively, in order to interoperate= ,
> semantic equivalence might be sufficient, is there any condition for > semantic equivalence?
>
>
> tl;dr: A JSON based protocol carried by HTTP can have syntactically > equivalent YANG model, if and only if all the keys in the key-value pa= irs
> in the JSON message are pre-defined keywords in the protocol.
>

Generating a YANG data model from existing instance data seems backwards to me, although Examplotron (http://examplotron.org) does something quite
similar. In any case, it might be quite challenging because YANG isn't<= br> intended as a general schema language. Your observation above is true
but it is just one aspect of the problem. For instance

"foo": [ { "bar": 1 }, 2 ]

or

"foo": null

cannot be modelled in YANG using the encoding of
draft-ietf-netmod-yang-json.



I think perhaps = RESTCONF is overloading JSON and this has led to some confusion.
= RESTCONF uses JSON strictly as an encoding format, not a data structure.=C2= =A0 JSON is just
the message encoding. The corresponding instance= document must conform to
the YANG definitions (not just be valid= JSON).

A protocol should pick between YANG data s= tructures and JSON data structures,
and not try to do both.
=


=C2=A0
Lada


Andy
=C2=A0
>
> We've come up with a few ideas, and a few things below are work in=
> progress, but we would love your feedback!
>
>
> Thank you!
>
> Xiao
>
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> 1. Introduction.
>
> JavaScript Object Notation (JSON) has been a popular choice as the mes= sage
> encoding for many network protocols such as the Application Layer Traf= fic
> Optimization (ALTO) protocol, the Content Delivery Networks Interconne= ction
> (CDNi) protocol, etc.
>
> Meanwhile, there are broad interests in the networking community to us= e
> YANG to define data model so that one can use YANG related tools such = as
> OpenDayLight controller. Although YANG itself is XML based, there have= been
> efforts to model JSON content using YANG [draft-ietf-netmod-yang-json-= 01].
>
> A natural question rises: can YANG model all JSON based protocols? Wha= t is
> the condition for a JSON based protocol (at least the message format) = to
> have an syntactically equivalent, hence interoperable, YANG model with= JSON
> encoding? Alternatively, in order to interoperate, semantic equivalenc= e
> might be sufficient, is there any condition for semantic equivalence?<= br> >
> 2. Claim
>
> A JSON based protocol carried by HTTP can have syntactically equivalen= t
> YANG model, if and only if:
>
> (1) the message encoding condition is met;
>
> (2) the uri condition is met.
>
> 2.1. The message encoding condition
>
> The JSON message encoding MUST not contain a variable as a key in a JS= ON
> object key-value pair. In other words, the keys in the JSON message mu= st be
> an already defined constant (or keyword) in the message format of the<= br> > protocol.
>
> For example, if I have a protocol where =E2=80=9Cnetwork-map=E2=80=9D,= =E2=80=9Csrc=E2=80=9D, and =E2=80=9Cdsts=E2=80=9D
> are defined keywords, JSON text A meets the condition whereas B does n= ot
> because =E2=80=9CPID1=E2=80=9D and =E2=80=9CPID2=E2=80=9D are not prot= ocol keywords (they are resource IDs).
>
> A:
>
> {
>
>=C2=A0 =E2=80=9Cnetwork-map=E2=80=9D: [
>
>=C2=A0 =C2=A0 {
>
>=C2=A0 =C2=A0 =C2=A0 =E2=80=9Csrc=E2=80=9D: =E2=80=9CPID1=E2=80=9D,
>
>=C2=A0 =C2=A0 =C2=A0 =E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID2=E2=80=9D, = =E2=80=9CPID3=E2=80=9D]
>
>=C2=A0 =C2=A0 },
>
>=C2=A0 =C2=A0 {
>
>=C2=A0 =C2=A0 =C2=A0 =E2=80=9Csrc=E2=80=9D: =E2=80=9CPID2=E2=80=9D,
>
>=C2=A0 =C2=A0 =C2=A0 =E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID3=E2=80=9D, = =E2=80=9CPID4=E2=80=9D]
>
>=C2=A0 =C2=A0 }
>
>=C2=A0 ]
>
> }
>
> B:
>
>
> {
>
>=C2=A0 =E2=80=9Cnetwork-map=E2=80=9D: [
>
>=C2=A0 =C2=A0 =E2=80=9CPID1: [=E2=80=9CPID2=E2=80=9D, =E2=80=9CPID3=E2= =80=9D],
>
>=C2=A0 =C2=A0 =E2=80=9CPID2=E2=80=9D: [=E2=80=9CPID3=E2=80=9D, =E2=80= =9CPID4=E2=80=9D]
>
>=C2=A0 ]
>
> }
>
>>From this we know that since ALTO protocol uses encoding B, there c= annot be
> a syntactically equivalent YANG model.
>
> 2.2 The URI condition
>
> Some of the YANG-related protocols might have URI constraints, e.g. > RESTCONF. For now, we assume either that the JSON-based protocol URI c= ould
> be conformed to RESTCONF compliant uri, or that the server could have = a
> routing mapping between the protocol compliant uri and the RESTCONF > compliant uri, hence this condition would not be an issue, which allow= s us
> to focus on the message encoding condition.
>
> 3. Proof
>
> 3.1. The message encoding condition is necessary.
>
> We first note that this condition is a necessary condition for a JSON = based
> protocol to have a syntactically equivalent YANG model by proving its<= br> > contrapositive.
>
> If one of the keys in the key-value pair in the JSON document is not > pre-defined, the corresponding XML tags will not be pre-defined keywor= ds.
> Therefore, it would not possible to model it in YANG without using
> YANG=E2=80=99s anyxml
> statement (which allows arbitrary XML content).
>
> However, using the anyxml statement would defeat our purpose of modeli= ng
> the data as it allows arbitrary XML content, and will not be helpful i= n the
> subsequent parsing process.
>
> 3.2. The message encoding condition is sufficient.
>
> We prove this by providing a translation procedure from a JSON message= that
> is compliant with the protocol we are trying to model, to a custom jav= a
> class that can be used for Jackson data binding, then to a YANG model.=
>
> We note that the middle step of translating to and from the custom par= ser
> class is not necessary, but it will be useful.
>
> 3.2.1. motivation
>
> JSON data binding is the process of binding data structures (objects,<= br> > arrays, etc.) in JSON to the appropriate data structures in the server=
> (e.g. java classes, database tables, etc.) in parsing the JSON text. I= n
> order to process JSON messages in a meaningful manner, data binding is=
> necessary. Even if the binding is not explicit, the server would need = to do
> it eventually. For example, one can read JSON content in a stream with= out
> binding it to the java classes, but eventually in order to make sense = of
> the data, the server would eventually have to organize it, which is ro= ughly
> analogous to data binding upfront. Popular choices for JSON parsing an= d
> data binding include jackson and gson.
>
> We use Jackson full data binding as our approach. Full data binding bi= nds
> JSON content into plain old java objects (POJOs), i.e. this custom par= ser
> class can neither extend nor implement any other class. Jackson uses > ObjectMapper with the custom parser class to parse JSON content into t= his
> class.
>
> 3.2.2. The message encoding condition
>
> The message encoding condition is that all keys in each key-value pair= in
> the JSON text must be pre-defined keywords. As the keys will become ei= ther
> class names and instance variable names, or be keys in the java maps, = it is
> easy to see that the condition is equivalent to =E2=80=9Cthere exists = a full data
> binding in Jackson custom parser class without using any map structure= s
> (Map<String, ?>).=E2=80=9D
>
> 3.2.3. Proof
>
> We provide a recursive binding process from a JSON object to the Jacks= on
> custom parser class to be used by Jackson ObjectMapper.
>
> Type determine_type(value) {
>
>=C2=A0 if (value is of a primitive type, i.e. string, number, boolean, = null) {
>
>=C2=A0 =C2=A0 return the corresponding java primitive type;
>
>=C2=A0 }
>
>=C2=A0 if (value is a JSON object) {
>
>=C2=A0 =C2=A0 return build_parser_class(value).class;
>
>=C2=A0 }
>
>=C2=A0 if (value is an array) {
>
>=C2=A0 =C2=A0 return ArrayList<T> where T=3Ddetermine_type(value[= 0]);
>
>=C2=A0 }
>
>=C2=A0 // should not reach here.
>
> }
>
> Class build_parser_class(JSONObject obj) {
>
>=C2=A0 create custom class C;
>
>=C2=A0 for each key/value pair in the obj {
>
>=C2=A0 =C2=A0 add instance variable v in C;
>
>=C2=A0 =C2=A0 the name of variable v <- key; // (__known__ a/c to ou= r assumption)
>
>=C2=A0 =C2=A0 the type of variable v <- determine_type(value);
>
>=C2=A0 }
>
>=C2=A0 return C.class;
>
> }
>
> Naming:
>
> --change everything into CamelCase (i.e. remove dashes, etc.)
>
> --for instance variables, use =E2=80=9Cmy=E2=80=9D prefix, (e.g. myVar= iable, myNetworkMap,
> etc.)
>
> --for the custom class name, if the object is an element of the array,= use
> =E2=80=9CElement=E2=80=9D suffix.
>
> This is just one convention so that the next step proceeds smoothly. A= s
> long as this naming translation is consistent with the naming stage in= the
> next step, it will work just fine.
>
> Example (a modified ALTO protocol network map example):
>
> JSON object:
>
> {
>
>=C2=A0 =E2=80=9Cmeta=E2=80=9D: {
>
>=C2=A0 =C2=A0 =E2=80=9Cresource-id=E2=80=9D: =E2=80=9Cmy-default-map=E2= =80=9D,
>
>=C2=A0 =C2=A0 =E2=80=9Ctag=E2=80=9D: =E2=80=9Caab875ef69c87d012=E2=80= =9D
>
>=C2=A0 },
>
>=C2=A0 =E2=80=9Cnetwork-map=E2=80=9D: [
>
>=C2=A0 =C2=A0 {
>
>=C2=A0 =C2=A0 =C2=A0 =E2=80=9Csrc=E2=80=9D: =E2=80=9CPID1=E2=80=9D,
>
>=C2=A0 =C2=A0 =C2=A0 =E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID1=E2=80=9D, = =E2=80=9CPID2=E2=80=9D, =E2=80=9CPID3=E2=80=9D]
>
>=C2=A0 =C2=A0 },
>
>=C2=A0 =C2=A0 {
>
>=C2=A0 =C2=A0 =C2=A0 =E2=80=9Csrc=E2=80=9D: =E2=80=9CPID2=E2=80=9D,
>
>=C2=A0 =C2=A0 =C2=A0 =E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID1=E2=80=9D, = =E2=80=9CPID3=E2=80=9D]
>
>=C2=A0 =C2=A0 },
>
>=C2=A0 =C2=A0 {
>
>=C2=A0 =C2=A0 =C2=A0 =E2=80=9Csrc=E2=80=9D: =E2=80=9CPID3=E2=80=9D,
>
>=C2=A0 =C2=A0 =C2=A0 =E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID2=E2=80=9D, = =E2=80=9CPID3=E2=80=9D]
>
>=C2=A0 =C2=A0 }
>
>=C2=A0 ]
>
> }
>
> Result of build_parser_class(obj):
>
> Class JSONObject {
>
>=C2=A0 Meta myMeta;
>
>=C2=A0 ArrayList<NetworkMapElement> myNetworkMap;
>
> }
>
> Class Meta {
>
>=C2=A0 String myResourceId;
>
>=C2=A0 String myTag;
>
> }
>
> Class NetworkMapElement {
>
>=C2=A0 String mySrc;
>
>=C2=A0 ArrayList<String> myDsts;
>
> }
>
> Now given the Jackson Parser Java Class, to get a syntactically equiva= lent
> YANG model:
>
> YANGModel build_yang_model(Class C) {
>
>=C2=A0 for each instance variable (Type, Name) {
>
>=C2=A0 =C2=A0 if (Type is primitive type: string, number, boolean, null= ) {
>
>=C2=A0 =C2=A0 =C2=A0 add the following to the YANG module:
>
>=C2=A0 =C2=A0 =C2=A0 =E2=80=9Cleaf Name { type <YANG equivalent of T= ype>; }=E2=80=9D
>
>=C2=A0 =C2=A0 }
>
>=C2=A0 =C2=A0 if (Type is an ArrayList<TypeElement>) {
>
>=C2=A0 =C2=A0 =C2=A0 if (TypeElement is primitive type) {
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 add the following to the YANG module:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=9Cleaf-list Name { type <YANG equ= ivalent of TypeElement>; }=E2=80=9D
>
>=C2=A0 =C2=A0 =C2=A0 } else {
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 // TypeElement is a custom parser class
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 add the following to the YANG module:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=9Clist Name { <result from build_= yang_model<TypeElement.class>> }=E2=80=9D
>
>=C2=A0 =C2=A0 =C2=A0 }
>
>=C2=A0 =C2=A0 }
>
>=C2=A0 =C2=A0 if (Type is a custom parser class) {
>
>=C2=A0 =C2=A0 =C2=A0 add the following to the YANG module:
>
>=C2=A0 =C2=A0 =C2=A0 =E2=80=9Ccontainer Name { <result from build_ya= ng_model<Type.class>> }=E2=80=9D
>
>=C2=A0 =C2=A0 }
>
>=C2=A0 }
>
> }
>
> Result from the previous example:
>
> container meta {
>
>=C2=A0 leaf resource-id {
>
>=C2=A0 =C2=A0 type string;
>
>=C2=A0 }
>
>=C2=A0 leaf tag {
>
>=C2=A0 =C2=A0 type string;
>
>=C2=A0 }
>
> }
>
> list network-map {
>
>=C2=A0 leaf src {
>
>=C2=A0 =C2=A0 type string;
>
>=C2=A0 }
>
>=C2=A0 leaf-list dsts {
>
>=C2=A0 =C2=A0 type string;
>
>=C2=A0 }
>
> }
>
> This does validate the JSON document with XML-JSON encoding. For your<= br> > reference, this is the XML document which validates:
>
> <?xml version=3D"1.0" encoding=3D"UTF-8" ?><= br> >
> <meta>
>
>=C2=A0 <resource-id>my-default-map</resource-id>
>
>=C2=A0 <tag>aab875ef69c87d012</tag>
>
> </meta>
>
> <network-map>
>
>=C2=A0 <src>PID1</src>
>
>=C2=A0 <dsts>PID1</dsts>
>
>=C2=A0 <dsts>PID2</dsts>
>
>=C2=A0 <dsts>PID3</dsts>
>
> </network-map>
>
> <network-map>
>
>=C2=A0 <src>PID2</src>
>
>=C2=A0 <dsts>PID1</dsts>
>
>=C2=A0 <dsts>PID3</dsts>
>
> </network-map>
>
> <network-map>
>
>=C2=A0 <src>PID3</src>
>
>=C2=A0 <dsts>PID2</dsts>
>
>=C2=A0 <dsts>PID3</dsts>
>
> </network-map>
>
> This proves that the message encoding condition is a sufficient condit= ion
> for the JSON object to have a YANG model.
>
> Note the model generated is very crude and lose almost all constraints= and
> all inheritance features (if any), because it focuses on the syntax an= d is
> essentially converted from an JSON object compliant with a protocol in= stead
> of from the protocol itself. Hence this result is more useful in
> determining which JSON based protocols cannot have a syntactically
> equivalent YANG model, than in generating a good YANG model.
>
> 3.3. Conclusion
>
> Our claim holds. A JSON based protocol carried by HTTP can have
> syntactically equivalent YANG model, if and only if all the keys in th= e
> key-value pairs in the JSON message are pre-defined keywords.
>
> 4. Semantic equivalence
>
> For JSON based protocols that don=E2=80=99t satisfy the message encodi= ng condition,
> it is still possible to have a semantically equivalent YANG model. All= that
> is required for the protocol compliant clients and the YANG model comp= liant
> server to interoperate is an adapter which does the following:
>
> 1) translate FROM YANG server compliant response msg TO alto compliant=
> response msg
>
> 2) translate FROM alto compliant request msg TO YANG server compliant<= br> > request msg
>
> 4.1. Claim
>
> This adapter needs to be protocol-aware.
>
> Ideally, given any YANG model, we would like to be able to automatical= ly
> (or at least mechanically) generate this message adapter, which means = not
> looking at the protocol or its compliant msgs. However, without knowin= g the
> specific protocol that we are working with (i.e. human intervention, i= .e.
> looking at the protocol compliant msgs), such an adapter cannot be
> auto-generated.
>
> 4.2. Proof by Indistinguishability
>
> Suppose both the YANG server compliant msg m_y and the actually protoc= ol
> compliant msg m_p are in JSON (or have been encoded into JSON). Lookin= g at
> the differences between the two messages, call these differences {d1, = d2,
> ..., dn}. The goal for the auto-generated adapter would be to identify= and
> eliminate these differences. Construct a new JSON msg m' where all= but one
> difference di is the same as m_p and di is the same as the m_y. Withou= t
> looking at the protocol (or m_p), the auto-generated adapter would not= be
> able to distinguish between m' and m_p in its translation process,= which
> means, it won't be able to tell whether it should change di or not= . Hence,
> such an adapter must be protocol-aware.
>
> A good example is the dependent-vtag in the ALTO protocol:
>
> "dependent-vtag" : [
>
>=C2=A0 {
>
>=C2=A0 =C2=A0 "resource-id" : "my-network-map",
>
>=C2=A0 =C2=A0 "tag" : "abcd1234"
>
>=C2=A0 }
>
> ]
>
> It was specified this way in the alto protocol. However, it could
> conceivably be the case that it was originally the following map struc= ture,
> and was converted into the above encoding because of the map->list+= key
> issue. (This case is actually one of the few differences in the m_y an= d m_p
> where the adapter does not need to convert it back to a map structure.= )
>
> "dependent-vtag" : {
>
>=C2=A0 "my-network-map" : {
>
>=C2=A0 =C2=A0 "tag" : "abcd1234"
>
>=C2=A0 }
>
> }
>
> Without knowing the protocol, there is no way to tell.
>
> 5. Ramifications
>
> We now understand the basic condition for a JSON based protocol to hav= e a
> YANG Model. For the protocols that don=E2=80=99t meet this condition, = there can be
> a semantic equivalent YANG model, but there won=E2=80=99t be a generic= process of
> generating the adapter for all such protocols.
> _______________________________________________
> 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


--089e013d08908eaeef0505dc7288-- From nobody Mon Oct 20 08:43:07 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 338E21A1B04 for ; Mon, 20 Oct 2014 08:43:04 -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 KbHTp1u2XHEC for ; Mon, 20 Oct 2014 08:43:00 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D22181A03A5 for ; Mon, 20 Oct 2014 08:41:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 848255404BC; Mon, 20 Oct 2014 17:41:09 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zatq2sZii2Y4; Mon, 20 Oct 2014 17:41:05 +0200 (CEST) Received: from localhost (unknown [172.29.2.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 58A545400EE; Mon, 20 Oct 2014 17:41:05 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: References: User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Mon, 20 Oct 2014 17:41:04 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/TrnoxNmiM6zf9dzi5MnxapiWWEA Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG Metadata Issue: leaf-list X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 20 Oct 2014 15:43:04 -0000 Andy Bierman writes: > On Mon, Oct 20, 2014 at 3:55 AM, Ladislav Lhotka wrote: > >> Andy Bierman writes: >> >> > Hi, >> > >> > I have run into some issues implementing >> > draft-lhotka-netmod-yang-metadata-00. >> > >> > (1) The annotations for leaf-list nodes are expensive to implement in >> > a constrained or streaming-based server. Every other node type >> > is easy to stream because all the data can be rendered before >> > moving on to the next node. But the leaf-list meta-data follows >> > all the leaf-list nodes: >> > >> > For example, in the following leaf-list instance with four entries, >> > the "inactive" annotation is added to the second and third entry in >> > the following way: >> > >> > "folio": [6, 3, 7, 8], >> > "@folio": [ >> > null, >> > {"example-inactive:inactive": true}, >> > {"example-inactive:inactive": true} >> > ] >> > >> > The server has to remember a lot of state and/or go through the leaf-list >> > twice. It is possible that the last node is gone and the next node is >> > unknown in a streaming server, This could take a lot of resources >> > for large leaf-lists. >> >> Do you have an alternative proposal? This encoding has an advantage that >> the receiving party may just ignore the annotation and nothing alse >> changes. If we somehow bundle annotations with each leaf-list entry, it >> will be no more the case. >> >> > No, I cannot think of an alternative that preserves the original encoding > and does not require any state to be maintained for previous entries. > I guess my conclusion is that JSON s intended for applications where > the complete data structure is held in memory. It is not meant to be > streamed. In general, that's my conclusion, too. On the other hand, I suspect that only limited parts of any data model are potential candidates for streaming, e.g. log messages. Perhaps we could think about providing some form of support for streaming such selected parts, in YANG and/or the protocol. > > >> >> > (2) The module-name as prefix is not really needed unless >> > there are annotations with the same name advertised by the server. >> >> This is true but if the namespace encoding is mandatory, the instance >> document needn't change as a side-effect of adding a new module to the >> data model. I think this is important because it it not only the server >> that potentially adds annotations. If an old client that only knows >> about one "foo" annotation always uses the namespace id, it can then >> safely ignore a new module advertised by the server, even if it defines >> a new annotation with colliding name. >> > > This is a trade-off. Unfortunately, it make the JSON more verbose. > Why not just use XML if you don't care about verbosity? > The rule is not mandatory for element names, is it? > For elements (data node instances) the rule has changed in -01 following Martin's suggestion: a namespace identifier is used if (and only if) the namespace changes wrt parent node. This encoding is also stable in the sense that adding a new module to the data model does not change the instance encoding. Lada > > >> >> > >> > (3) Multiple annotations can be rendered in any order within an array >> entry: >> > This should be clarified (and maybe an example). >> >> I think this follows from the fact that JSON objects are unordered by >> definition. So the annotation object may precede or follow the annotated >> member, and also the order of its members is undefined. >> > > OK -- this is supposed to make output simpler I guess, but the unordered > objects > making parsing even more stateful. > > > >> >> > >> > "folio": [6, 3, 7, 8], >> > "@folio": [ >> > null, >> > {"example-inactive:inactive": true, >> > "example:foo":42 }, >> > {"example:foo":53, >> > example-inactive:inactive": true} >> > ] >> > >> > >> > Andy >> >> Lada >> >> > Andy > > >> > _______________________________________________ >> > 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 Oct 20 08:47:08 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE5151A6EF8 for ; Mon, 20 Oct 2014 08:47: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=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 31on0GB1HruE for ; Mon, 20 Oct 2014 08:46:51 -0700 (PDT) Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1C881A6EDA for ; Mon, 20 Oct 2014 08:45:25 -0700 (PDT) Received: by mail-qg0-f44.google.com with SMTP id j5so3702139qga.31 for ; Mon, 20 Oct 2014 08:45:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wQyny0sEZ0OXmFXRVKVzciAmq0fB6KgQkg1IQGCGNP4=; b=X1IaWwYn3Chh1CRe1BLvhkTbhkrjlc8u4d8PvsSW2Jith03kXs4+kyA0Mus7d7hYZc EX+vu7OfB7dAbQpoTB/IBCWjeFnWeVLHZIuqUVjhOxrtolgmS6ZZBQMDhvqyiM8hsEWd 7xhqM1F7VQsyr71R7mawYMvyUHXVVPlJ789fjSjfaXu28xAeqwDiijKQyBODTvC3/JQN nQmLYZNIeatVaMm42f7nstaVyt1sh6sV+GjRikJaGWwbo3JKHrc97vLCVldc/LKydKP3 sdSrasJBjF/c2OZhP9E4fey5Cl8rgWVzOGgZUQZiwbAE1M31t7ddYCdjNs6a9O1CD1dV ka8w== X-Gm-Message-State: ALoCoQlwAoqg6WugkXjwhVypWtXsNWrewm2Ph0qD9WSt7QyXSDG3qBVT5YZDngTTgSqFUWFkr5P1 MIME-Version: 1.0 X-Received: by 10.229.28.196 with SMTP id n4mr37065793qcc.14.1413819923344; Mon, 20 Oct 2014 08:45:23 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Mon, 20 Oct 2014 08:45:23 -0700 (PDT) In-Reply-To: References: Date: Mon, 20 Oct 2014 08:45:23 -0700 Message-ID: From: Andy Bierman To: Xiao SHI Content-Type: multipart/alternative; boundary=001a1134a5364ec68f0505dc9acd Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/a1zu0amQd_-gfd4hO5oCOR2VR5M Cc: "netmod@ietf.org" , IETF ALTO Subject: Re: [netmod] Modeling JSON based protocols using YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 20 Oct 2014 15:47:03 -0000 --001a1134a5364ec68f0505dc9acd Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 20, 2014 at 8:33 AM, Xiao SHI wrote: > Hi Andy, > > I agree with you. Just to clarify, what I am trying to do is to use YANG > data structures for the protocol whose message encoding is JSON. I am not > trying to use JSON as a data structure. Does this make sense? > > yes -- so you want to write the YANG module that corresponds to the existing JSON usage. Not extend YANG to support all possible JSON usage. Good. > Best, > Xiao > Andy > > On Mon, Oct 20, 2014 at 11:29 AM, Andy Bierman wrote: > >> >> >> On Mon, Oct 20, 2014 at 6:23 AM, Ladislav Lhotka wrote: >> >>> Xiao SHI writes: >>> >>> > Hi folks, >>> > >>> > >>> > As a few of us were working on modeling the ALTO protocol using YANG, >>> we >>> > were pondering on a more general question: can YANG model all JSON >>> based >>> > protocols? What is the condition for a JSON based protocol (at least >>> the >>> > message format) to have an syntactically equivalent, hence >>> interoperable, >>> > YANG model with JSON encoding? Alternatively, in order to interoperate, >>> > semantic equivalence might be sufficient, is there any condition for >>> > semantic equivalence? >>> > >>> > >>> > tl;dr: A JSON based protocol carried by HTTP can have syntactically >>> > equivalent YANG model, if and only if all the keys in the key-value >>> pairs >>> > in the JSON message are pre-defined keywords in the protocol. >>> > >>> >>> Generating a YANG data model from existing instance data seems backwards >>> to me, although Examplotron (http://examplotron.org) does something >>> quite >>> similar. In any case, it might be quite challenging because YANG isn't >>> intended as a general schema language. Your observation above is true >>> but it is just one aspect of the problem. For instance >>> >>> "foo": [ { "bar": 1 }, 2 ] >>> >>> or >>> >>> "foo": null >>> >>> cannot be modelled in YANG using the encoding of >>> draft-ietf-netmod-yang-json. >>> >>> >> >> I think perhaps RESTCONF is overloading JSON and this has led to some >> confusion. >> RESTCONF uses JSON strictly as an encoding format, not a data structure. >> JSON is just >> the message encoding. The corresponding instance document must conform to >> the YANG definitions (not just be valid JSON). >> >> A protocol should pick between YANG data structures and JSON data >> structures, >> and not try to do both. >> >> >> >> >>> Lada >>> >>> >> Andy >> >> >>> > >>> > We've come up with a few ideas, and a few things below are work in >>> > progress, but we would love your feedback! >>> > >>> > >>> > Thank you! >>> > >>> > Xiao >>> > >>> > >>> > ====================== >>> > >>> > 1. Introduction. >>> > >>> > JavaScript Object Notation (JSON) has been a popular choice as the >>> message >>> > encoding for many network protocols such as the Application Layer >>> Traffic >>> > Optimization (ALTO) protocol, the Content Delivery Networks >>> Interconnection >>> > (CDNi) protocol, etc. >>> > >>> > Meanwhile, there are broad interests in the networking community to use >>> > YANG to define data model so that one can use YANG related tools such >>> as >>> > OpenDayLight controller. Although YANG itself is XML based, there have >>> been >>> > efforts to model JSON content using YANG >>> [draft-ietf-netmod-yang-json-01]. >>> > >>> > A natural question rises: can YANG model all JSON based protocols? >>> What is >>> > the condition for a JSON based protocol (at least the message format) >>> to >>> > have an syntactically equivalent, hence interoperable, YANG model with >>> JSON >>> > encoding? Alternatively, in order to interoperate, semantic equivalence >>> > might be sufficient, is there any condition for semantic equivalence? >>> > >>> > 2. Claim >>> > >>> > A JSON based protocol carried by HTTP can have syntactically equivalent >>> > YANG model, if and only if: >>> > >>> > (1) the message encoding condition is met; >>> > >>> > (2) the uri condition is met. >>> > >>> > 2.1. The message encoding condition >>> > >>> > The JSON message encoding MUST not contain a variable as a key in a >>> JSON >>> > object key-value pair. In other words, the keys in the JSON message >>> must be >>> > an already defined constant (or keyword) in the message format of the >>> > protocol. >>> > >>> > For example, if I have a protocol where "network-map", "src", and >>> "dsts" >>> > are defined keywords, JSON text A meets the condition whereas B does >>> not >>> > because "PID1" and "PID2" are not protocol keywords (they are resource >>> IDs). >>> > >>> > A: >>> > >>> > { >>> > >>> > "network-map": [ >>> > >>> > { >>> > >>> > "src": "PID1", >>> > >>> > "dsts": ["PID2", "PID3"] >>> > >>> > }, >>> > >>> > { >>> > >>> > "src": "PID2", >>> > >>> > "dsts": ["PID3", "PID4"] >>> > >>> > } >>> > >>> > ] >>> > >>> > } >>> > >>> > B: >>> > >>> > >>> > { >>> > >>> > "network-map": [ >>> > >>> > "PID1: ["PID2", "PID3"], >>> > >>> > "PID2": ["PID3", "PID4"] >>> > >>> > ] >>> > >>> > } >>> > >>> >>From this we know that since ALTO protocol uses encoding B, there >>> cannot be >>> > a syntactically equivalent YANG model. >>> > >>> > 2.2 The URI condition >>> > >>> > Some of the YANG-related protocols might have URI constraints, e.g. >>> > RESTCONF. For now, we assume either that the JSON-based protocol URI >>> could >>> > be conformed to RESTCONF compliant uri, or that the server could have a >>> > routing mapping between the protocol compliant uri and the RESTCONF >>> > compliant uri, hence this condition would not be an issue, which >>> allows us >>> > to focus on the message encoding condition. >>> > >>> > 3. Proof >>> > >>> > 3.1. The message encoding condition is necessary. >>> > >>> > We first note that this condition is a necessary condition for a JSON >>> based >>> > protocol to have a syntactically equivalent YANG model by proving its >>> > contrapositive. >>> > >>> > If one of the keys in the key-value pair in the JSON document is not >>> > pre-defined, the corresponding XML tags will not be pre-defined >>> keywords. >>> > Therefore, it would not possible to model it in YANG without using >>> > YANG's anyxml >>> > statement (which allows arbitrary XML content). >>> > >>> > However, using the anyxml statement would defeat our purpose of >>> modeling >>> > the data as it allows arbitrary XML content, and will not be helpful >>> in the >>> > subsequent parsing process. >>> > >>> > 3.2. The message encoding condition is sufficient. >>> > >>> > We prove this by providing a translation procedure from a JSON message >>> that >>> > is compliant with the protocol we are trying to model, to a custom java >>> > class that can be used for Jackson data binding, then to a YANG model. >>> > >>> > We note that the middle step of translating to and from the custom >>> parser >>> > class is not necessary, but it will be useful. >>> > >>> > 3.2.1. motivation >>> > >>> > JSON data binding is the process of binding data structures (objects, >>> > arrays, etc.) in JSON to the appropriate data structures in the server >>> > (e.g. java classes, database tables, etc.) in parsing the JSON text. In >>> > order to process JSON messages in a meaningful manner, data binding is >>> > necessary. Even if the binding is not explicit, the server would need >>> to do >>> > it eventually. For example, one can read JSON content in a stream >>> without >>> > binding it to the java classes, but eventually in order to make sense >>> of >>> > the data, the server would eventually have to organize it, which is >>> roughly >>> > analogous to data binding upfront. Popular choices for JSON parsing and >>> > data binding include jackson and gson. >>> > >>> > We use Jackson full data binding as our approach. Full data binding >>> binds >>> > JSON content into plain old java objects (POJOs), i.e. this custom >>> parser >>> > class can neither extend nor implement any other class. Jackson uses >>> > ObjectMapper with the custom parser class to parse JSON content into >>> this >>> > class. >>> > >>> > 3.2.2. The message encoding condition >>> > >>> > The message encoding condition is that all keys in each key-value pair >>> in >>> > the JSON text must be pre-defined keywords. As the keys will become >>> either >>> > class names and instance variable names, or be keys in the java maps, >>> it is >>> > easy to see that the condition is equivalent to "there exists a full >>> data >>> > binding in Jackson custom parser class without using any map structures >>> > (Map)." >>> > >>> > 3.2.3. Proof >>> > >>> > We provide a recursive binding process from a JSON object to the >>> Jackson >>> > custom parser class to be used by Jackson ObjectMapper. >>> > >>> > Type determine_type(value) { >>> > >>> > if (value is of a primitive type, i.e. string, number, boolean, null) >>> { >>> > >>> > return the corresponding java primitive type; >>> > >>> > } >>> > >>> > if (value is a JSON object) { >>> > >>> > return build_parser_class(value).class; >>> > >>> > } >>> > >>> > if (value is an array) { >>> > >>> > return ArrayList where T=determine_type(value[0]); >>> > >>> > } >>> > >>> > // should not reach here. >>> > >>> > } >>> > >>> > Class build_parser_class(JSONObject obj) { >>> > >>> > create custom class C; >>> > >>> > for each key/value pair in the obj { >>> > >>> > add instance variable v in C; >>> > >>> > the name of variable v <- key; // (__known__ a/c to our assumption) >>> > >>> > the type of variable v <- determine_type(value); >>> > >>> > } >>> > >>> > return C.class; >>> > >>> > } >>> > >>> > Naming: >>> > >>> > --change everything into CamelCase (i.e. remove dashes, etc.) >>> > >>> > --for instance variables, use "my" prefix, (e.g. myVariable, >>> myNetworkMap, >>> > etc.) >>> > >>> > --for the custom class name, if the object is an element of the array, >>> use >>> > "Element" suffix. >>> > >>> > This is just one convention so that the next step proceeds smoothly. As >>> > long as this naming translation is consistent with the naming stage in >>> the >>> > next step, it will work just fine. >>> > >>> > Example (a modified ALTO protocol network map example): >>> > >>> > JSON object: >>> > >>> > { >>> > >>> > "meta": { >>> > >>> > "resource-id": "my-default-map", >>> > >>> > "tag": "aab875ef69c87d012" >>> > >>> > }, >>> > >>> > "network-map": [ >>> > >>> > { >>> > >>> > "src": "PID1", >>> > >>> > "dsts": ["PID1", "PID2", "PID3"] >>> > >>> > }, >>> > >>> > { >>> > >>> > "src": "PID2", >>> > >>> > "dsts": ["PID1", "PID3"] >>> > >>> > }, >>> > >>> > { >>> > >>> > "src": "PID3", >>> > >>> > "dsts": ["PID2", "PID3"] >>> > >>> > } >>> > >>> > ] >>> > >>> > } >>> > >>> > Result of build_parser_class(obj): >>> > >>> > Class JSONObject { >>> > >>> > Meta myMeta; >>> > >>> > ArrayList myNetworkMap; >>> > >>> > } >>> > >>> > Class Meta { >>> > >>> > String myResourceId; >>> > >>> > String myTag; >>> > >>> > } >>> > >>> > Class NetworkMapElement { >>> > >>> > String mySrc; >>> > >>> > ArrayList myDsts; >>> > >>> > } >>> > >>> > Now given the Jackson Parser Java Class, to get a syntactically >>> equivalent >>> > YANG model: >>> > >>> > YANGModel build_yang_model(Class C) { >>> > >>> > for each instance variable (Type, Name) { >>> > >>> > if (Type is primitive type: string, number, boolean, null) { >>> > >>> > add the following to the YANG module: >>> > >>> > "leaf Name { type ; }" >>> > >>> > } >>> > >>> > if (Type is an ArrayList) { >>> > >>> > if (TypeElement is primitive type) { >>> > >>> > add the following to the YANG module: >>> > >>> > "leaf-list Name { type ; }" >>> > >>> > } else { >>> > >>> > // TypeElement is a custom parser class >>> > >>> > add the following to the YANG module: >>> > >>> > "list Name { > >>> }" >>> > >>> > } >>> > >>> > } >>> > >>> > if (Type is a custom parser class) { >>> > >>> > add the following to the YANG module: >>> > >>> > "container Name { > }" >>> > >>> > } >>> > >>> > } >>> > >>> > } >>> > >>> > Result from the previous example: >>> > >>> > container meta { >>> > >>> > leaf resource-id { >>> > >>> > type string; >>> > >>> > } >>> > >>> > leaf tag { >>> > >>> > type string; >>> > >>> > } >>> > >>> > } >>> > >>> > list network-map { >>> > >>> > leaf src { >>> > >>> > type string; >>> > >>> > } >>> > >>> > leaf-list dsts { >>> > >>> > type string; >>> > >>> > } >>> > >>> > } >>> > >>> > This does validate the JSON document with XML-JSON encoding. For your >>> > reference, this is the XML document which validates: >>> > >>> > >>> > >>> > >>> > >>> > my-default-map >>> > >>> > aab875ef69c87d012 >>> > >>> > >>> > >>> > >>> > >>> > PID1 >>> > >>> > PID1 >>> > >>> > PID2 >>> > >>> > PID3 >>> > >>> > >>> > >>> > >>> > >>> > PID2 >>> > >>> > PID1 >>> > >>> > PID3 >>> > >>> > >>> > >>> > >>> > >>> > PID3 >>> > >>> > PID2 >>> > >>> > PID3 >>> > >>> > >>> > >>> > This proves that the message encoding condition is a sufficient >>> condition >>> > for the JSON object to have a YANG model. >>> > >>> > Note the model generated is very crude and lose almost all constraints >>> and >>> > all inheritance features (if any), because it focuses on the syntax >>> and is >>> > essentially converted from an JSON object compliant with a protocol >>> instead >>> > of from the protocol itself. Hence this result is more useful in >>> > determining which JSON based protocols cannot have a syntactically >>> > equivalent YANG model, than in generating a good YANG model. >>> > >>> > 3.3. Conclusion >>> > >>> > Our claim holds. A JSON based protocol carried by HTTP can have >>> > syntactically equivalent YANG model, if and only if all the keys in the >>> > key-value pairs in the JSON message are pre-defined keywords. >>> > >>> > 4. Semantic equivalence >>> > >>> > For JSON based protocols that don't satisfy the message encoding >>> condition, >>> > it is still possible to have a semantically equivalent YANG model. All >>> that >>> > is required for the protocol compliant clients and the YANG model >>> compliant >>> > server to interoperate is an adapter which does the following: >>> > >>> > 1) translate FROM YANG server compliant response msg TO alto compliant >>> > response msg >>> > >>> > 2) translate FROM alto compliant request msg TO YANG server compliant >>> > request msg >>> > >>> > 4.1. Claim >>> > >>> > This adapter needs to be protocol-aware. >>> > >>> > Ideally, given any YANG model, we would like to be able to >>> automatically >>> > (or at least mechanically) generate this message adapter, which means >>> not >>> > looking at the protocol or its compliant msgs. However, without >>> knowing the >>> > specific protocol that we are working with (i.e. human intervention, >>> i.e. >>> > looking at the protocol compliant msgs), such an adapter cannot be >>> > auto-generated. >>> > >>> > 4.2. Proof by Indistinguishability >>> > >>> > Suppose both the YANG server compliant msg m_y and the actually >>> protocol >>> > compliant msg m_p are in JSON (or have been encoded into JSON). >>> Looking at >>> > the differences between the two messages, call these differences {d1, >>> d2, >>> > ..., dn}. The goal for the auto-generated adapter would be to identify >>> and >>> > eliminate these differences. Construct a new JSON msg m' where all but >>> one >>> > difference di is the same as m_p and di is the same as the m_y. Without >>> > looking at the protocol (or m_p), the auto-generated adapter would not >>> be >>> > able to distinguish between m' and m_p in its translation process, >>> which >>> > means, it won't be able to tell whether it should change di or not. >>> Hence, >>> > such an adapter must be protocol-aware. >>> > >>> > A good example is the dependent-vtag in the ALTO protocol: >>> > >>> > "dependent-vtag" : [ >>> > >>> > { >>> > >>> > "resource-id" : "my-network-map", >>> > >>> > "tag" : "abcd1234" >>> > >>> > } >>> > >>> > ] >>> > >>> > It was specified this way in the alto protocol. However, it could >>> > conceivably be the case that it was originally the following map >>> structure, >>> > and was converted into the above encoding because of the map->list+key >>> > issue. (This case is actually one of the few differences in the m_y >>> and m_p >>> > where the adapter does not need to convert it back to a map structure.) >>> > >>> > "dependent-vtag" : { >>> > >>> > "my-network-map" : { >>> > >>> > "tag" : "abcd1234" >>> > >>> > } >>> > >>> > } >>> > >>> > Without knowing the protocol, there is no way to tell. >>> > >>> > 5. Ramifications >>> > >>> > We now understand the basic condition for a JSON based protocol to >>> have a >>> > YANG Model. For the protocols that don't meet this condition, there >>> can be >>> > a semantic equivalent YANG model, but there won't be a generic process >>> of >>> > generating the adapter for all such protocols. >>> > _______________________________________________ >>> > 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 >>> >> >> > --001a1134a5364ec68f0505dc9acd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mon, Oct 20, 2014 at 8:33 AM, Xiao SHI <xiao.shi@yale.edu> wrote:
Hi Andy,
I agree with you. Just to clarify, what I am trying to do = is to use YANG data structures for the protocol whose message encoding is J= SON. I am not trying to use JSON as a data structure. Does this make sense?=


yes -- so you w= ant to write the YANG module that corresponds to the
existing JSO= N usage. Not extend YANG to support all possible JSON usage.
Good= .


 
Best,
Xiao
=

Andy
 

O= n Mon, Oct 20, 2014 at 11:29 AM, Andy Bierman <andy@yumaworks.com>= wrote:


On Mon, Oct 20, = 2014 at 6:23 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
Xiao SHI <xiao.shi@yale.edu> writes:

> Hi folks,
>
>
> As a few of us were working on modeling the ALTO protocol using YANG, = we
> were pondering on a more general question: can YANG model all JSON bas= ed
> protocols? What is the condition for a JSON based protocol (at least t= he
> message format) to have an syntactically equivalent, hence interoperab= le,
> YANG model with JSON encoding? Alternatively, in order to interoperate= ,
> semantic equivalence might be sufficient, is there any condition for > semantic equivalence?
>
>
> tl;dr: A JSON based protocol carried by HTTP can have syntactically > equivalent YANG model, if and only if all the keys in the key-value pa= irs
> in the JSON message are pre-defined keywords in the protocol.
>

Generating a YANG data model from existing instance data seems backwards to me, although Examplotron (http://examplotron.org) does something quite
similar. In any case, it might be quite challenging because YANG isn't<= br> intended as a general schema language. Your observation above is true
but it is just one aspect of the problem. For instance

"foo": [ { "bar": 1 }, 2 ]

or

"foo": null

cannot be modelled in YANG using the encoding of
draft-ietf-netmod-yang-json.



I think perhaps = RESTCONF is overloading JSON and this has led to some confusion.
= RESTCONF uses JSON strictly as an encoding format, not a data structure.&nb= sp; JSON is just
the message encoding. The corresponding instance= document must conform to
the YANG definitions (not just be valid= JSON).

A protocol should pick between YANG data s= tructures and JSON data structures,
and not try to do both.
=


 
Lada


Andy
 
>
> We've come up with a few ideas, and a few things below are work in=
> progress, but we would love your feedback!
>
>
> Thank you!
>
> Xiao
>
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> 1. Introduction.
>
> JavaScript Object Notation (JSON) has been a popular choice as the mes= sage
> encoding for many network protocols such as the Application Layer Traf= fic
> Optimization (ALTO) protocol, the Content Delivery Networks Interconne= ction
> (CDNi) protocol, etc.
>
> Meanwhile, there are broad interests in the networking community to us= e
> YANG to define data model so that one can use YANG related tools such = as
> OpenDayLight controller. Although YANG itself is XML based, there have= been
> efforts to model JSON content using YANG [draft-ietf-netmod-yang-json-= 01].
>
> A natural question rises: can YANG model all JSON based protocols? Wha= t is
> the condition for a JSON based protocol (at least the message format) = to
> have an syntactically equivalent, hence interoperable, YANG model with= JSON
> encoding? Alternatively, in order to interoperate, semantic equivalenc= e
> might be sufficient, is there any condition for semantic equivalence?<= br> >
> 2. Claim
>
> A JSON based protocol carried by HTTP can have syntactically equivalen= t
> YANG model, if and only if:
>
> (1) the message encoding condition is met;
>
> (2) the uri condition is met.
>
> 2.1. The message encoding condition
>
> The JSON message encoding MUST not contain a variable as a key in a JS= ON
> object key-value pair. In other words, the keys in the JSON message mu= st be
> an already defined constant (or keyword) in the message format of the<= br> > protocol.
>
> For example, if I have a protocol where “network-map”, &ld= quo;src”, and “dsts”
> are defined keywords, JSON text A meets the condition whereas B does n= ot
> because “PID1” and “PID2” are not protocol key= words (they are resource IDs).
>
> A:
>
> {
>
>  “network-map”: [
>
>    {
>
>      “src”: “PID1”,
>
>      “dsts”: [“PID2”, “PI= D3”]
>
>    },
>
>    {
>
>      “src”: “PID2”,
>
>      “dsts”: [“PID3”, “PI= D4”]
>
>    }
>
>  ]
>
> }
>
> B:
>
>
> {
>
>  “network-map”: [
>
>    “PID1: [“PID2”, “PID3”], >
>    “PID2”: [“PID3”, “PID4&rdqu= o;]
>
>  ]
>
> }
>
>>From this we know that since ALTO protocol uses encoding B, there c= annot be
> a syntactically equivalent YANG model.
>
> 2.2 The URI condition
>
> Some of the YANG-related protocols might have URI constraints, e.g. > RESTCONF. For now, we assume either that the JSON-based protocol URI c= ould
> be conformed to RESTCONF compliant uri, or that the server could have = a
> routing mapping between the protocol compliant uri and the RESTCONF > compliant uri, hence this condition would not be an issue, which allow= s us
> to focus on the message encoding condition.
>
> 3. Proof
>
> 3.1. The message encoding condition is necessary.
>
> We first note that this condition is a necessary condition for a JSON = based
> protocol to have a syntactically equivalent YANG model by proving its<= br> > contrapositive.
>
> If one of the keys in the key-value pair in the JSON document is not > pre-defined, the corresponding XML tags will not be pre-defined keywor= ds.
> Therefore, it would not possible to model it in YANG without using
> YANG’s anyxml
> statement (which allows arbitrary XML content).
>
> However, using the anyxml statement would defeat our purpose of modeli= ng
> the data as it allows arbitrary XML content, and will not be helpful i= n the
> subsequent parsing process.
>
> 3.2. The message encoding condition is sufficient.
>
> We prove this by providing a translation procedure from a JSON message= that
> is compliant with the protocol we are trying to model, to a custom jav= a
> class that can be used for Jackson data binding, then to a YANG model.=
>
> We note that the middle step of translating to and from the custom par= ser
> class is not necessary, but it will be useful.
>
> 3.2.1. motivation
>
> JSON data binding is the process of binding data structures (objects,<= br> > arrays, etc.) in JSON to the appropriate data structures in the server=
> (e.g. java classes, database tables, etc.) in parsing the JSON text. I= n
> order to process JSON messages in a meaningful manner, data binding is=
> necessary. Even if the binding is not explicit, the server would need = to do
> it eventually. For example, one can read JSON content in a stream with= out
> binding it to the java classes, but eventually in order to make sense = of
> the data, the server would eventually have to organize it, which is ro= ughly
> analogous to data binding upfront. Popular choices for JSON parsing an= d
> data binding include jackson and gson.
>
> We use Jackson full data binding as our approach. Full data binding bi= nds
> JSON content into plain old java objects (POJOs), i.e. this custom par= ser
> class can neither extend nor implement any other class. Jackson uses > ObjectMapper with the custom parser class to parse JSON content into t= his
> class.
>
> 3.2.2. The message encoding condition
>
> The message encoding condition is that all keys in each key-value pair= in
> the JSON text must be pre-defined keywords. As the keys will become ei= ther
> class names and instance variable names, or be keys in the java maps, = it is
> easy to see that the condition is equivalent to “there exists a = full data
> binding in Jackson custom parser class without using any map structure= s
> (Map<String, ?>).”
>
> 3.2.3. Proof
>
> We provide a recursive binding process from a JSON object to the Jacks= on
> custom parser class to be used by Jackson ObjectMapper.
>
> Type determine_type(value) {
>
>  if (value is of a primitive type, i.e. string, number, boolean, = null) {
>
>    return the corresponding java primitive type;
>
>  }
>
>  if (value is a JSON object) {
>
>    return build_parser_class(value).class;
>
>  }
>
>  if (value is an array) {
>
>    return ArrayList<T> where T=3Ddetermine_type(value[= 0]);
>
>  }
>
>  // should not reach here.
>
> }
>
> Class build_parser_class(JSONObject obj) {
>
>  create custom class C;
>
>  for each key/value pair in the obj {
>
>    add instance variable v in C;
>
>    the name of variable v <- key; // (__known__ a/c to ou= r assumption)
>
>    the type of variable v <- determine_type(value);
>
>  }
>
>  return C.class;
>
> }
>
> Naming:
>
> --change everything into CamelCase (i.e. remove dashes, etc.)
>
> --for instance variables, use “my” prefix, (e.g. myVariabl= e, myNetworkMap,
> etc.)
>
> --for the custom class name, if the object is an element of the array,= use
> “Element” suffix.
>
> This is just one convention so that the next step proceeds smoothly. A= s
> long as this naming translation is consistent with the naming stage in= the
> next step, it will work just fine.
>
> Example (a modified ALTO protocol network map example):
>
> JSON object:
>
> {
>
>  “meta”: {
>
>    “resource-id”: “my-default-map”,<= br> >
>    “tag”: “aab875ef69c87d012”
>
>  },
>
>  “network-map”: [
>
>    {
>
>      “src”: “PID1”,
>
>      “dsts”: [“PID1”, “PI= D2”, “PID3”]
>
>    },
>
>    {
>
>      “src”: “PID2”,
>
>      “dsts”: [“PID1”, “PI= D3”]
>
>    },
>
>    {
>
>      “src”: “PID3”,
>
>      “dsts”: [“PID2”, “PI= D3”]
>
>    }
>
>  ]
>
> }
>
> Result of build_parser_class(obj):
>
> Class JSONObject {
>
>  Meta myMeta;
>
>  ArrayList<NetworkMapElement> myNetworkMap;
>
> }
>
> Class Meta {
>
>  String myResourceId;
>
>  String myTag;
>
> }
>
> Class NetworkMapElement {
>
>  String mySrc;
>
>  ArrayList<String> myDsts;
>
> }
>
> Now given the Jackson Parser Java Class, to get a syntactically equiva= lent
> YANG model:
>
> YANGModel build_yang_model(Class C) {
>
>  for each instance variable (Type, Name) {
>
>    if (Type is primitive type: string, number, boolean, null= ) {
>
>      add the following to the YANG module:
>
>      “leaf Name { type <YANG equivalent of Typ= e>; }”
>
>    }
>
>    if (Type is an ArrayList<TypeElement>) {
>
>      if (TypeElement is primitive type) {
>
>        add the following to the YANG module:
>
>        “leaf-list Name { type <YANG equiv= alent of TypeElement>; }”
>
>      } else {
>
>        // TypeElement is a custom parser class
>
>        add the following to the YANG module:
>
>        “list Name { <result from build_ya= ng_model<TypeElement.class>> }”
>
>      }
>
>    }
>
>    if (Type is a custom parser class) {
>
>      add the following to the YANG module:
>
>      “container Name { <result from build_yang= _model<Type.class>> }”
>
>    }
>
>  }
>
> }
>
> Result from the previous example:
>
> container meta {
>
>  leaf resource-id {
>
>    type string;
>
>  }
>
>  leaf tag {
>
>    type string;
>
>  }
>
> }
>
> list network-map {
>
>  leaf src {
>
>    type string;
>
>  }
>
>  leaf-list dsts {
>
>    type string;
>
>  }
>
> }
>
> This does validate the JSON document with XML-JSON encoding. For your<= br> > reference, this is the XML document which validates:
>
> <?xml version=3D"1.0" encoding=3D"UTF-8" ?><= br> >
> <meta>
>
>  <resource-id>my-default-map</resource-id>
>
>  <tag>aab875ef69c87d012</tag>
>
> </meta>
>
> <network-map>
>
>  <src>PID1</src>
>
>  <dsts>PID1</dsts>
>
>  <dsts>PID2</dsts>
>
>  <dsts>PID3</dsts>
>
> </network-map>
>
> <network-map>
>
>  <src>PID2</src>
>
>  <dsts>PID1</dsts>
>
>  <dsts>PID3</dsts>
>
> </network-map>
>
> <network-map>
>
>  <src>PID3</src>
>
>  <dsts>PID2</dsts>
>
>  <dsts>PID3</dsts>
>
> </network-map>
>
> This proves that the message encoding condition is a sufficient condit= ion
> for the JSON object to have a YANG model.
>
> Note the model generated is very crude and lose almost all constraints= and
> all inheritance features (if any), because it focuses on the syntax an= d is
> essentially converted from an JSON object compliant with a protocol in= stead
> of from the protocol itself. Hence this result is more useful in
> determining which JSON based protocols cannot have a syntactically
> equivalent YANG model, than in generating a good YANG model.
>
> 3.3. Conclusion
>
> Our claim holds. A JSON based protocol carried by HTTP can have
> syntactically equivalent YANG model, if and only if all the keys in th= e
> key-value pairs in the JSON message are pre-defined keywords.
>
> 4. Semantic equivalence
>
> For JSON based protocols that don’t satisfy the message encoding= condition,
> it is still possible to have a semantically equivalent YANG model. All= that
> is required for the protocol compliant clients and the YANG model comp= liant
> server to interoperate is an adapter which does the following:
>
> 1) translate FROM YANG server compliant response msg TO alto compliant=
> response msg
>
> 2) translate FROM alto compliant request msg TO YANG server compliant<= br> > request msg
>
> 4.1. Claim
>
> This adapter needs to be protocol-aware.
>
> Ideally, given any YANG model, we would like to be able to automatical= ly
> (or at least mechanically) generate this message adapter, which means = not
> looking at the protocol or its compliant msgs. However, without knowin= g the
> specific protocol that we are working with (i.e. human intervention, i= .e.
> looking at the protocol compliant msgs), such an adapter cannot be
> auto-generated.
>
> 4.2. Proof by Indistinguishability
>
> Suppose both the YANG server compliant msg m_y and the actually protoc= ol
> compliant msg m_p are in JSON (or have been encoded into JSON). Lookin= g at
> the differences between the two messages, call these differences {d1, = d2,
> ..., dn}. The goal for the auto-generated adapter would be to identify= and
> eliminate these differences. Construct a new JSON msg m' where all= but one
> difference di is the same as m_p and di is the same as the m_y. Withou= t
> looking at the protocol (or m_p), the auto-generated adapter would not= be
> able to distinguish between m' and m_p in its translation process,= which
> means, it won't be able to tell whether it should change di or not= . Hence,
> such an adapter must be protocol-aware.
>
> A good example is the dependent-vtag in the ALTO protocol:
>
> "dependent-vtag" : [
>
>  {
>
>    "resource-id" : "my-network-map",
>
>    "tag" : "abcd1234"
>
>  }
>
> ]
>
> It was specified this way in the alto protocol. However, it could
> conceivably be the case that it was originally the following map struc= ture,
> and was converted into the above encoding because of the map->list+= key
> issue. (This case is actually one of the few differences in the m_y an= d m_p
> where the adapter does not need to convert it back to a map structure.= )
>
> "dependent-vtag" : {
>
>  "my-network-map" : {
>
>    "tag" : "abcd1234"
>
>  }
>
> }
>
> Without knowing the protocol, there is no way to tell.
>
> 5. Ramifications
>
> We now understand the basic condition for a JSON based protocol to hav= e a
> YANG Model. For the protocols that don’t meet this condition, th= ere can be
> a semantic equivalent YANG model, but there won’t be a generic p= rocess of
> generating the adapter for all such protocols.
> _______________________________________________
> 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



--001a1134a5364ec68f0505dc9acd-- From nobody Mon Oct 20 08:58:00 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD7D51A0264; Mon, 20 Oct 2014 08:57: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 qr2IS3LfOzn1; Mon, 20 Oct 2014 08:57:54 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0CD41A1B5F; Mon, 20 Oct 2014 08:56:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id A7CA35404BC; Mon, 20 Oct 2014 17:56:31 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4rBb5bWfg1xS; Mon, 20 Oct 2014 17:56:25 +0200 (CEST) Received: from localhost (unknown [172.29.2.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id A3A9E5400EE; Mon, 20 Oct 2014 17:56:25 +0200 (CEST) From: Ladislav Lhotka To: Xiao SHI In-Reply-To: References: User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Mon, 20 Oct 2014 17:56:23 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/KakKh0R_G8xlHE8WdBAlhUAW0SY Cc: IETF ALTO , "netmod@ietf.org" Subject: Re: [netmod] Modeling JSON based protocols using YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 20 Oct 2014 15:57:58 -0000 Xiao SHI writes: > Hi Lada, > > Thank you so much for your feedback! > > The motivation here is to produce a YANG model given a defined protocol, > e.g. ALTO, CDNi, etc. This way, we may incorporate future protocols into > ODL controllers or use other YANG related tools to handle those protocols. > Hence the objective of the modeling is the protocol, not the messages. I = am > not suggesting to use YANG as a schema language. Hmm, YANG was designed for modelling datastores and contents of protocol messages, not protocols as such. > > The conditions discussed in this process will be helpful in the following > sense: > 1) disprove the possibility to get a syntactically equivalent YANG model > from a JSON based protocol; > 2) generate a Jackson JSON parser class and YANG model from the protocols > that meet the criteria; > 3) for designers of future protocols who are thinking of using YANG relat= ed > tools, set a guideline of what their messages should look like (or MUST n= ot > contain); > 4) for the YANG/NETCONF WG, describing the compatibility issues that they > might be interested in tackling for expanding YANG's usage. > > For this example, "foo": [ { "bar": 1 }, 2 ] is also not easy to do > data-binding in the parser, because the elements of the array are not of > the same type, which is indeed an assumption that I left out. > > For the {"foo=E2=80=9D:null} example, can't we model it using type empty?= That's > equivalent to the XML element right? corresponds to "foo": [null] Section 6.9 in draft-ietf-netmod-yang-json-01 gives the reasoning, essentially it is because some software isn't able to distinguish "foo": null from "foo" being absent. Lada =20 > > Cheers, > Xiao > > On Mon, Oct 20, 2014 at 9:23 AM, Ladislav Lhotka wrote: > >> Xiao SHI writes: >> >> > Hi folks, >> > >> > >> > As a few of us were working on modeling the ALTO protocol using YANG, = we >> > were pondering on a more general question: can YANG model all JSON bas= ed >> > protocols? What is the condition for a JSON based protocol (at least t= he >> > message format) to have an syntactically equivalent, hence interoperab= le, >> > YANG model with JSON encoding? Alternatively, in order to interoperate, >> > semantic equivalence might be sufficient, is there any condition for >> > semantic equivalence? >> > >> > >> > tl;dr: A JSON based protocol carried by HTTP can have syntactically >> > equivalent YANG model, if and only if all the keys in the key-value pa= irs >> > in the JSON message are pre-defined keywords in the protocol. >> > >> >> Generating a YANG data model from existing instance data seems backwards >> to me, although Examplotron (http://examplotron.org) does something quite >> similar. In any case, it might be quite challenging because YANG isn't >> intended as a general schema language. Your observation above is true >> but it is just one aspect of the problem. For instance >> >> "foo": [ { "bar": 1 }, 2 ] >> >> or >> >> "foo": null >> >> cannot be modelled in YANG using the encoding of >> draft-ietf-netmod-yang-json. >> >> Lada >> >> > >> > We've come up with a few ideas, and a few things below are work in >> > progress, but we would love your feedback! >> > >> > >> > Thank you! >> > >> > Xiao >> > >> > >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > >> > 1. Introduction. >> > >> > JavaScript Object Notation (JSON) has been a popular choice as the >> message >> > encoding for many network protocols such as the Application Layer Traf= fic >> > Optimization (ALTO) protocol, the Content Delivery Networks >> Interconnection >> > (CDNi) protocol, etc. >> > >> > Meanwhile, there are broad interests in the networking community to use >> > YANG to define data model so that one can use YANG related tools such = as >> > OpenDayLight controller. Although YANG itself is XML based, there have >> been >> > efforts to model JSON content using YANG >> [draft-ietf-netmod-yang-json-01]. >> > >> > A natural question rises: can YANG model all JSON based protocols? What >> is >> > the condition for a JSON based protocol (at least the message format) = to >> > have an syntactically equivalent, hence interoperable, YANG model with >> JSON >> > encoding? Alternatively, in order to interoperate, semantic equivalence >> > might be sufficient, is there any condition for semantic equivalence? >> > >> > 2. Claim >> > >> > A JSON based protocol carried by HTTP can have syntactically equivalent >> > YANG model, if and only if: >> > >> > (1) the message encoding condition is met; >> > >> > (2) the uri condition is met. >> > >> > 2.1. The message encoding condition >> > >> > The JSON message encoding MUST not contain a variable as a key in a JS= ON >> > object key-value pair. In other words, the keys in the JSON message mu= st >> be >> > an already defined constant (or keyword) in the message format of the >> > protocol. >> > >> > For example, if I have a protocol where =E2=80=9Cnetwork-map=E2=80=9D,= =E2=80=9Csrc=E2=80=9D, and =E2=80=9Cdsts=E2=80=9D >> > are defined keywords, JSON text A meets the condition whereas B does n= ot >> > because =E2=80=9CPID1=E2=80=9D and =E2=80=9CPID2=E2=80=9D are not prot= ocol keywords (they are resource >> IDs). >> > >> > A: >> > >> > { >> > >> > =E2=80=9Cnetwork-map=E2=80=9D: [ >> > >> > { >> > >> > =E2=80=9Csrc=E2=80=9D: =E2=80=9CPID1=E2=80=9D, >> > >> > =E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID2=E2=80=9D, =E2=80=9CPID3=E2= =80=9D] >> > >> > }, >> > >> > { >> > >> > =E2=80=9Csrc=E2=80=9D: =E2=80=9CPID2=E2=80=9D, >> > >> > =E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID3=E2=80=9D, =E2=80=9CPID4=E2= =80=9D] >> > >> > } >> > >> > ] >> > >> > } >> > >> > B: >> > >> > >> > { >> > >> > =E2=80=9Cnetwork-map=E2=80=9D: [ >> > >> > =E2=80=9CPID1: [=E2=80=9CPID2=E2=80=9D, =E2=80=9CPID3=E2=80=9D], >> > >> > =E2=80=9CPID2=E2=80=9D: [=E2=80=9CPID3=E2=80=9D, =E2=80=9CPID4=E2= =80=9D] >> > >> > ] >> > >> > } >> > >> >>From this we know that since ALTO protocol uses encoding B, there cann= ot >> be >> > a syntactically equivalent YANG model. >> > >> > 2.2 The URI condition >> > >> > Some of the YANG-related protocols might have URI constraints, e.g. >> > RESTCONF. For now, we assume either that the JSON-based protocol URI >> could >> > be conformed to RESTCONF compliant uri, or that the server could have a >> > routing mapping between the protocol compliant uri and the RESTCONF >> > compliant uri, hence this condition would not be an issue, which allows >> us >> > to focus on the message encoding condition. >> > >> > 3. Proof >> > >> > 3.1. The message encoding condition is necessary. >> > >> > We first note that this condition is a necessary condition for a JSON >> based >> > protocol to have a syntactically equivalent YANG model by proving its >> > contrapositive. >> > >> > If one of the keys in the key-value pair in the JSON document is not >> > pre-defined, the corresponding XML tags will not be pre-defined keywor= ds. >> > Therefore, it would not possible to model it in YANG without using >> > YANG=E2=80=99s anyxml >> > statement (which allows arbitrary XML content). >> > >> > However, using the anyxml statement would defeat our purpose of modeli= ng >> > the data as it allows arbitrary XML content, and will not be helpful in >> the >> > subsequent parsing process. >> > >> > 3.2. The message encoding condition is sufficient. >> > >> > We prove this by providing a translation procedure from a JSON message >> that >> > is compliant with the protocol we are trying to model, to a custom java >> > class that can be used for Jackson data binding, then to a YANG model. >> > >> > We note that the middle step of translating to and from the custom par= ser >> > class is not necessary, but it will be useful. >> > >> > 3.2.1. motivation >> > >> > JSON data binding is the process of binding data structures (objects, >> > arrays, etc.) in JSON to the appropriate data structures in the server >> > (e.g. java classes, database tables, etc.) in parsing the JSON text. In >> > order to process JSON messages in a meaningful manner, data binding is >> > necessary. Even if the binding is not explicit, the server would need = to >> do >> > it eventually. For example, one can read JSON content in a stream with= out >> > binding it to the java classes, but eventually in order to make sense = of >> > the data, the server would eventually have to organize it, which is >> roughly >> > analogous to data binding upfront. Popular choices for JSON parsing and >> > data binding include jackson and gson. >> > >> > We use Jackson full data binding as our approach. Full data binding bi= nds >> > JSON content into plain old java objects (POJOs), i.e. this custom par= ser >> > class can neither extend nor implement any other class. Jackson uses >> > ObjectMapper with the custom parser class to parse JSON content into t= his >> > class. >> > >> > 3.2.2. The message encoding condition >> > >> > The message encoding condition is that all keys in each key-value pair= in >> > the JSON text must be pre-defined keywords. As the keys will become >> either >> > class names and instance variable names, or be keys in the java maps, = it >> is >> > easy to see that the condition is equivalent to =E2=80=9Cthere exists = a full data >> > binding in Jackson custom parser class without using any map structures >> > (Map).=E2=80=9D >> > >> > 3.2.3. Proof >> > >> > We provide a recursive binding process from a JSON object to the Jacks= on >> > custom parser class to be used by Jackson ObjectMapper. >> > >> > Type determine_type(value) { >> > >> > if (value is of a primitive type, i.e. string, number, boolean, null)= { >> > >> > return the corresponding java primitive type; >> > >> > } >> > >> > if (value is a JSON object) { >> > >> > return build_parser_class(value).class; >> > >> > } >> > >> > if (value is an array) { >> > >> > return ArrayList where T=3Ddetermine_type(value[0]); >> > >> > } >> > >> > // should not reach here. >> > >> > } >> > >> > Class build_parser_class(JSONObject obj) { >> > >> > create custom class C; >> > >> > for each key/value pair in the obj { >> > >> > add instance variable v in C; >> > >> > the name of variable v <- key; // (__known__ a/c to our assumption) >> > >> > the type of variable v <- determine_type(value); >> > >> > } >> > >> > return C.class; >> > >> > } >> > >> > Naming: >> > >> > --change everything into CamelCase (i.e. remove dashes, etc.) >> > >> > --for instance variables, use =E2=80=9Cmy=E2=80=9D prefix, (e.g. myVar= iable, >> myNetworkMap, >> > etc.) >> > >> > --for the custom class name, if the object is an element of the array, >> use >> > =E2=80=9CElement=E2=80=9D suffix. >> > >> > This is just one convention so that the next step proceeds smoothly. As >> > long as this naming translation is consistent with the naming stage in >> the >> > next step, it will work just fine. >> > >> > Example (a modified ALTO protocol network map example): >> > >> > JSON object: >> > >> > { >> > >> > =E2=80=9Cmeta=E2=80=9D: { >> > >> > =E2=80=9Cresource-id=E2=80=9D: =E2=80=9Cmy-default-map=E2=80=9D, >> > >> > =E2=80=9Ctag=E2=80=9D: =E2=80=9Caab875ef69c87d012=E2=80=9D >> > >> > }, >> > >> > =E2=80=9Cnetwork-map=E2=80=9D: [ >> > >> > { >> > >> > =E2=80=9Csrc=E2=80=9D: =E2=80=9CPID1=E2=80=9D, >> > >> > =E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID1=E2=80=9D, =E2=80=9CPID2=E2= =80=9D, =E2=80=9CPID3=E2=80=9D] >> > >> > }, >> > >> > { >> > >> > =E2=80=9Csrc=E2=80=9D: =E2=80=9CPID2=E2=80=9D, >> > >> > =E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID1=E2=80=9D, =E2=80=9CPID3=E2= =80=9D] >> > >> > }, >> > >> > { >> > >> > =E2=80=9Csrc=E2=80=9D: =E2=80=9CPID3=E2=80=9D, >> > >> > =E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID2=E2=80=9D, =E2=80=9CPID3=E2= =80=9D] >> > >> > } >> > >> > ] >> > >> > } >> > >> > Result of build_parser_class(obj): >> > >> > Class JSONObject { >> > >> > Meta myMeta; >> > >> > ArrayList myNetworkMap; >> > >> > } >> > >> > Class Meta { >> > >> > String myResourceId; >> > >> > String myTag; >> > >> > } >> > >> > Class NetworkMapElement { >> > >> > String mySrc; >> > >> > ArrayList myDsts; >> > >> > } >> > >> > Now given the Jackson Parser Java Class, to get a syntactically >> equivalent >> > YANG model: >> > >> > YANGModel build_yang_model(Class C) { >> > >> > for each instance variable (Type, Name) { >> > >> > if (Type is primitive type: string, number, boolean, null) { >> > >> > add the following to the YANG module: >> > >> > =E2=80=9Cleaf Name { type ; }=E2=80=9D >> > >> > } >> > >> > if (Type is an ArrayList) { >> > >> > if (TypeElement is primitive type) { >> > >> > add the following to the YANG module: >> > >> > =E2=80=9Cleaf-list Name { type = ; }=E2=80=9D >> > >> > } else { >> > >> > // TypeElement is a custom parser class >> > >> > add the following to the YANG module: >> > >> > =E2=80=9Clist Name { > }=E2=80=9D >> > >> > } >> > >> > } >> > >> > if (Type is a custom parser class) { >> > >> > add the following to the YANG module: >> > >> > =E2=80=9Ccontainer Name { > }=E2=80=9D >> > >> > } >> > >> > } >> > >> > } >> > >> > Result from the previous example: >> > >> > container meta { >> > >> > leaf resource-id { >> > >> > type string; >> > >> > } >> > >> > leaf tag { >> > >> > type string; >> > >> > } >> > >> > } >> > >> > list network-map { >> > >> > leaf src { >> > >> > type string; >> > >> > } >> > >> > leaf-list dsts { >> > >> > type string; >> > >> > } >> > >> > } >> > >> > This does validate the JSON document with XML-JSON encoding. For your >> > reference, this is the XML document which validates: >> > >> > >> > >> > >> > >> > my-default-map >> > >> > aab875ef69c87d012 >> > >> > >> > >> > >> > >> > PID1 >> > >> > PID1 >> > >> > PID2 >> > >> > PID3 >> > >> > >> > >> > >> > >> > PID2 >> > >> > PID1 >> > >> > PID3 >> > >> > >> > >> > >> > >> > PID3 >> > >> > PID2 >> > >> > PID3 >> > >> > >> > >> > This proves that the message encoding condition is a sufficient condit= ion >> > for the JSON object to have a YANG model. >> > >> > Note the model generated is very crude and lose almost all constraints >> and >> > all inheritance features (if any), because it focuses on the syntax and >> is >> > essentially converted from an JSON object compliant with a protocol >> instead >> > of from the protocol itself. Hence this result is more useful in >> > determining which JSON based protocols cannot have a syntactically >> > equivalent YANG model, than in generating a good YANG model. >> > >> > 3.3. Conclusion >> > >> > Our claim holds. A JSON based protocol carried by HTTP can have >> > syntactically equivalent YANG model, if and only if all the keys in the >> > key-value pairs in the JSON message are pre-defined keywords. >> > >> > 4. Semantic equivalence >> > >> > For JSON based protocols that don=E2=80=99t satisfy the message encodi= ng >> condition, >> > it is still possible to have a semantically equivalent YANG model. All >> that >> > is required for the protocol compliant clients and the YANG model >> compliant >> > server to interoperate is an adapter which does the following: >> > >> > 1) translate FROM YANG server compliant response msg TO alto compliant >> > response msg >> > >> > 2) translate FROM alto compliant request msg TO YANG server compliant >> > request msg >> > >> > 4.1. Claim >> > >> > This adapter needs to be protocol-aware. >> > >> > Ideally, given any YANG model, we would like to be able to automatical= ly >> > (or at least mechanically) generate this message adapter, which means = not >> > looking at the protocol or its compliant msgs. However, without knowing >> the >> > specific protocol that we are working with (i.e. human intervention, i= .e. >> > looking at the protocol compliant msgs), such an adapter cannot be >> > auto-generated. >> > >> > 4.2. Proof by Indistinguishability >> > >> > Suppose both the YANG server compliant msg m_y and the actually protoc= ol >> > compliant msg m_p are in JSON (or have been encoded into JSON). Looking >> at >> > the differences between the two messages, call these differences {d1, = d2, >> > ..., dn}. The goal for the auto-generated adapter would be to identify >> and >> > eliminate these differences. Construct a new JSON msg m' where all but >> one >> > difference di is the same as m_p and di is the same as the m_y. Without >> > looking at the protocol (or m_p), the auto-generated adapter would not= be >> > able to distinguish between m' and m_p in its translation process, whi= ch >> > means, it won't be able to tell whether it should change di or not. >> Hence, >> > such an adapter must be protocol-aware. >> > >> > A good example is the dependent-vtag in the ALTO protocol: >> > >> > "dependent-vtag" : [ >> > >> > { >> > >> > "resource-id" : "my-network-map", >> > >> > "tag" : "abcd1234" >> > >> > } >> > >> > ] >> > >> > It was specified this way in the alto protocol. However, it could >> > conceivably be the case that it was originally the following map >> structure, >> > and was converted into the above encoding because of the map->list+key >> > issue. (This case is actually one of the few differences in the m_y and >> m_p >> > where the adapter does not need to convert it back to a map structure.) >> > >> > "dependent-vtag" : { >> > >> > "my-network-map" : { >> > >> > "tag" : "abcd1234" >> > >> > } >> > >> > } >> > >> > Without knowing the protocol, there is no way to tell. >> > >> > 5. Ramifications >> > >> > We now understand the basic condition for a JSON based protocol to hav= e a >> > YANG Model. For the protocols that don=E2=80=99t meet this condition, = there can >> be >> > a semantic equivalent YANG model, but there won=E2=80=99t be a generic= process of >> > generating the adapter for all such protocols. >> > _______________________________________________ >> > netmod mailing list >> > netmod@ietf.org >> > https://www.ietf.org/mailman/listinfo/netmod >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Oct 20 09:09:04 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4B31A1B04 for ; Mon, 20 Oct 2014 09:09:00 -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 6yQfUWKicej7 for ; Mon, 20 Oct 2014 09:08:52 -0700 (PDT) Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EB8E1A1B09 for ; Mon, 20 Oct 2014 09:07:28 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id o8so3967126qcw.14 for ; Mon, 20 Oct 2014 09:07:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8eh4MUZ6oytigJT2XIw81iEna0pYNM4hrvojtwGhJEc=; b=JsCMadVOtrNAdLrjmsa3c/NVtd25SJaPxtJT2lTdr3zXltg6NJKXHLSjJ/bxMLxfHJ ke3Wh5JcIVmUOLgQRAErCHOnomljepDE6wa8erMEHBhFolN3W7KDyedB4cC1c8x9Qggb zsGQL6jEXFy2p23L++/fWiw82DDaoqM/861d98qStm9ypxgSAr0ttCNd1L8TWlQlhXU9 +ct38tQ6YUUEiyLs8Kfo1EfEkgEuKfttXSU8XHBTNiaQPTnmCNrDfoEDUZmaSaxuL+6U ujLAvPK4KH2jjK0gGcE+U+iXOHbeD38bZrXI14A9fCMT7drBUyqNaC/tyc1/Z6fWf48h Y0VQ== X-Gm-Message-State: ALoCoQn0CJu4By47x8T3VC8YQtsrXWQsXs2ibdLFEZE4zF/SzACnIieXsnM17M8XhjHhGystnaIH MIME-Version: 1.0 X-Received: by 10.229.28.196 with SMTP id n4mr37261127qcc.14.1413821247217; Mon, 20 Oct 2014 09:07:27 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Mon, 20 Oct 2014 09:07:27 -0700 (PDT) In-Reply-To: References: Date: Mon, 20 Oct 2014 09:07:27 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a1134a5363776c60505dce9c6 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/F5gn-GJQAVA_IhTS0BBBK6A3vGw Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG Metadata Issue: leaf-list X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 20 Oct 2014 16:09:00 -0000 --001a1134a5363776c60505dce9c6 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 20, 2014 at 8:41 AM, Ladislav Lhotka wrote: > Andy Bierman writes: > > > On Mon, Oct 20, 2014 at 3:55 AM, Ladislav Lhotka wrote: > > > >> Andy Bierman writes: > >> > >> > Hi, > >> > > >> > I have run into some issues implementing > >> > draft-lhotka-netmod-yang-metadata-00. > >> > > >> > (1) The annotations for leaf-list nodes are expensive to implement in > >> > a constrained or streaming-based server. Every other node type > >> > is easy to stream because all the data can be rendered before > >> > moving on to the next node. But the leaf-list meta-data follows > >> > all the leaf-list nodes: > >> > > >> > For example, in the following leaf-list instance with four entries, > >> > the "inactive" annotation is added to the second and third entry in > >> > the following way: > >> > > >> > "folio": [6, 3, 7, 8], > >> > "@folio": [ > >> > null, > >> > {"example-inactive:inactive": true}, > >> > {"example-inactive:inactive": true} > >> > ] > >> > > >> > The server has to remember a lot of state and/or go through the > leaf-list > >> > twice. It is possible that the last node is gone and the next node is > >> > unknown in a streaming server, This could take a lot of resources > >> > for large leaf-lists. > >> > >> Do you have an alternative proposal? This encoding has an advantage that > >> the receiving party may just ignore the annotation and nothing alse > >> changes. If we somehow bundle annotations with each leaf-list entry, it > >> will be no more the case. > >> > >> > > No, I cannot think of an alternative that preserves the original encoding > > and does not require any state to be maintained for previous entries. > > I guess my conclusion is that JSON s intended for applications where > > the complete data structure is held in memory. It is not meant to be > > streamed. > > In general, that's my conclusion, too. On the other hand, I suspect that > only limited parts of any data model are potential candidates for > streaming, e.g. log messages. Perhaps we could think about providing > some form of support for streaming such selected parts, in YANG and/or > the protocol. > > Streaming applies to way the server outputs the JSON to the client, not the same as an ever-changing log file. Almost all operational data, and even some config data is distributed across the system. Storing that data (after retrieving it) can have a high cost. > > > > >> > >> > (2) The module-name as prefix is not really needed unless > >> > there are annotations with the same name advertised by the server. > >> > >> This is true but if the namespace encoding is mandatory, the instance > >> document needn't change as a side-effect of adding a new module to the > >> data model. I think this is important because it it not only the server > >> that potentially adds annotations. If an old client that only knows > >> about one "foo" annotation always uses the namespace id, it can then > >> safely ignore a new module advertised by the server, even if it defines > >> a new annotation with colliding name. > >> > > > > This is a trade-off. Unfortunately, it make the JSON more verbose. > > Why not just use XML if you don't care about verbosity? > > The rule is not mandatory for element names, is it? > > > > For elements (data node instances) the rule has changed in -01 following > Martin's suggestion: a namespace identifier is used if (and only if) the > namespace changes wrt parent node. This encoding is also stable in the > sense that adding a new module to the data model does not change the > instance encoding. > I agree this is better than before. I wish we could have short module numbers instead of long module names as prefixes. > > Lada > > Andy > > > > > >> > >> > > >> > (3) Multiple annotations can be rendered in any order within an array > >> entry: > >> > This should be clarified (and maybe an example). > >> > >> I think this follows from the fact that JSON objects are unordered by > >> definition. So the annotation object may precede or follow the annotated > >> member, and also the order of its members is undefined. > >> > > > > OK -- this is supposed to make output simpler I guess, but the unordered > > objects > > making parsing even more stateful. > > > > > > > >> > >> > > >> > "folio": [6, 3, 7, 8], > >> > "@folio": [ > >> > null, > >> > {"example-inactive:inactive": true, > >> > "example:foo":42 }, > >> > {"example:foo":53, > >> > example-inactive:inactive": true} > >> > ] > >> > > >> > > >> > Andy > >> > >> Lada > >> > >> > > Andy > > > > > >> > _______________________________________________ > >> > 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 > --001a1134a5363776c60505dce9c6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mon, Oct 20, 2014 at 8:41 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:
Andy Bierman <andy@yumaworks.com> writes:

> On Mon, Oct 20, 2014 at 3:55 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
>> Andy Bierman <andy@yumawo= rks.com> writes:
>>
>> > Hi,
>> >
>> > I have run into some issues implementing
>> > draft-lhotka-netmod-yang-metadata-00.
>> >
>> > (1) The annotations for leaf-list nodes are expensive to impl= ement in
>> > a constrained or streaming-based server.=A0 Every other node = type
>> > is easy to stream because all the data can be rendered before=
>> > moving on to the next node.=A0 But the leaf-list meta-data fo= llows
>> > all the leaf-list nodes:
>> >
>> >=A0 =A0 For example, in the following leaf-list instance with = four entries,
>> >=A0 =A0 the "inactive" annotation is added to the se= cond and third entry in
>> >=A0 =A0 the following way:
>> >
>> >=A0 =A0 =A0 =A0 "folio": [6, 3, 7, 8],
>> >=A0 =A0 =A0 =A0 "@folio": [
>> >=A0 =A0 =A0 =A0 =A0 null,
>> >=A0 =A0 =A0 =A0 =A0 {"example-inactive:inactive": tr= ue},
>> >=A0 =A0 =A0 =A0 =A0 {"example-inactive:inactive": tr= ue}
>> >=A0 =A0 =A0 =A0 ]
>> >
>> > The server has to remember a lot of state and/or go through t= he leaf-list
>> > twice.=A0 It is possible that the last node is gone and the n= ext node is
>> > unknown in a streaming server, This could take a lot of resou= rces
>> > for large leaf-lists.
>>
>> Do you have an alternative proposal? This encoding has an advantag= e that
>> the receiving party may just ignore the annotation and nothing als= e
>> changes. If we somehow bundle annotations with each leaf-list entr= y, it
>> will be no more the case.
>>
>>
> No, I cannot think of an alternative that preserves the original encod= ing
> and does not require any state to be maintained for previous entries.<= br> > I guess my conclusion is that JSON s intended for applications where > the complete data structure is held in memory. It is not meant to be > streamed.

In general, that's my conclusion, too. On the other hand, I suspect tha= t
only limited parts of any data model are potential candidates for
streaming, e.g. log messages. Perhaps we could think about providing
some form of support for streaming such selected parts, in YANG and/or
the protocol.



Streaming applies to wa= y the server outputs the JSON to the client, not
the same as an e= ver-changing log file.=A0 Almost all operational data,
and even s= ome config data is distributed across the system.
Storing that da= ta (after retrieving it) can have a high cost.




>
>
>>
>> > (2) The module-name as prefix is not really needed unless
>> > there are annotations with the same name advertised by the se= rver.
>>
>> This is true but if the namespace encoding is mandatory, the insta= nce
>> document needn't change as a side-effect of adding a new modul= e to the
>> data model. I think this is important because it it not only the s= erver
>> that potentially adds annotations. If an old client that only know= s
>> about one "foo" annotation always uses the namespace id,= it can then
>> safely ignore a new module advertised by the server, even if it de= fines
>> a new annotation with colliding name.
>>
>
> This is a trade-off. Unfortunately, it make the JSON more verbose.
> Why not just use XML if you don't care about verbosity?
> The rule is not mandatory for element names, is it?
>

For elements (data node instances) the rule has changed in -01 following Martin's suggestion: a namespace identifier is used if (and only if) th= e
namespace changes wrt parent node. This encoding is also stable in the
sense that adding a new module to the data model does not change the
instance encoding.


I agr= ee this is better than before.
I wish we could have short module = numbers instead of long module names as prefixes.
=A0

Lada


Andy
=A0
>
>
>>
>> >
>> > (3) Multiple annotations can be rendered in any order within = an array
>> entry:
>> > This should be clarified (and maybe an example).
>>
>> I think this follows from the fact that JSON objects are unordered= by
>> definition. So the annotation object may precede or follow the ann= otated
>> member, and also the order of its members is undefined.
>>
>
> OK -- this is supposed to make output simpler I guess, but the unorder= ed
> objects
> making parsing even more stateful.
>
>
>
>>
>> >
>> >=A0 =A0 =A0 =A0 "folio": [6, 3, 7, 8],
>> >=A0 =A0 =A0 =A0 "@folio": [
>> >=A0 =A0 =A0 =A0 =A0 null,
>> >=A0 =A0 =A0 =A0 =A0 {"example-inactive:inactive": tr= ue,
>> >=A0 =A0 =A0 =A0 =A0 =A0 "example:foo":42 },
>> >=A0 =A0 =A0 =A0 =A0 {"example:foo":53,
>> >=A0 =A0 =A0 =A0 =A0 =A0 example-inactive:inactive": true}=
>> >=A0 =A0 =A0 =A0 ]
>> >
>> >
>> > Andy
>>
>> Lada
>>
>>
> Andy
>
>
>> > _______________________________________________
>> > 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

--001a1134a5363776c60505dce9c6-- From nobody Mon Oct 20 09:35:45 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33A041A9062 for ; Mon, 20 Oct 2014 09:35:43 -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 u37Yqmlj8tr4 for ; Mon, 20 Oct 2014 09:35:40 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BEF41A898F for ; Mon, 20 Oct 2014 09:25:04 -0700 (PDT) Received: from [172.29.2.202] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id 5298914010F; Mon, 20 Oct 2014 18:25:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1413822302; bh=gzWbuux2kbI1DkCHJ2D0qMVQhFWzbbVnUqAancHh3lU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=d+hSq4+cKDa1YDmCuOTvt4Q30lEO3Wyt6uQ7FOssL2vLBIjgA3afJKIf6vutGbpqv YgYQotSrOAsILx2tslb1cyh9TQNJR0k2pJzWLQCvfirZzqg/s3fnaxJ6CdpULDhtW8 l6Ibwljil11M/y/kr4E3KpzYGsRuZAPe7GLf5Qn0= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 20 Oct 2014 18:25:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Andy Bierman X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/lN0RNb3sEL8wXXVZk6FHxumGKoA Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG Metadata Issue: leaf-list X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 20 Oct 2014 16:35:43 -0000 On 20 Oct 2014, at 18:07, Andy Bierman wrote: >=20 > For elements (data node instances) the rule has changed in -01 = following > Martin's suggestion: a namespace identifier is used if (and only if) = the > namespace changes wrt parent node. This encoding is also stable in the > sense that adding a new module to the data model does not change the > instance encoding. >=20 >=20 > I agree this is better than before. > I wish we could have short module numbers instead of long module names = as prefixes. Module names are not that bad and, unlike URIs, they are YANG = identifiers. The URI/prefix duality used by XML has its share of = problems, too. Lada=20 > =20 >=20 > Lada >=20 >=20 > Andy > =20 > > > > > >> > >> > > >> > (3) Multiple annotations can be rendered in any order within an = array > >> entry: > >> > This should be clarified (and maybe an example). > >> > >> I think this follows from the fact that JSON objects are unordered = by > >> definition. So the annotation object may precede or follow the = annotated > >> member, and also the order of its members is undefined. > >> > > > > OK -- this is supposed to make output simpler I guess, but the = unordered > > objects > > making parsing even more stateful. > > > > > > > >> > >> > > >> > "folio": [6, 3, 7, 8], > >> > "@folio": [ > >> > null, > >> > {"example-inactive:inactive": true, > >> > "example:foo":42 }, > >> > {"example:foo":53, > >> > example-inactive:inactive": true} > >> > ] > >> > > >> > > >> > Andy > >> > >> Lada > >> > >> > > Andy > > > > > >> > _______________________________________________ > >> > netmod mailing list > >> > netmod@ietf.org > >> > https://www.ietf.org/mailman/listinfo/netmod > >> > >> -- > >> Ladislav Lhotka, CZ.NIC Labs > >> PGP Key ID: E74E8C0C > >> >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Oct 20 10:12:42 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0B041A6FD5 for ; Mon, 20 Oct 2014 10:12:36 -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 puP7MfycUn_M for ; Mon, 20 Oct 2014 10:12:34 -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 BC33D1A86E4 for ; Mon, 20 Oct 2014 10:01:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4052; q=dns/txt; s=iport; t=1413824514; x=1415034114; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=umKrgfAJWh3NHfVNFpTvann7CrQzXp2A1IvdXGD64eo=; b=k7L6sxY1vp11OlTwvDebako9xUBbrt7mVWHlxqjRFvbi6Nzh4TKLgei9 dGuRprs4fDbmHOpe2QvuAZaNiNm+Or3ZaTdaQF7pVGveEnkgRrB8DiOha 9ZYpRLRL7jsxZ+Wr3bA1VJG5eB1wU89JB97yCHrFGuJr6J2KyJc6I8Ndz A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFACU/RVStJA2F/2dsb2JhbABcgw5TTQsEzCAMhndUAoETFgF9hAMBAQQBAQEaUQsQAgEIGCMLJwslAgQOBYg/DcYDAQEBAQEBAQEBAQEBAQEBAQEBAQEYkB4zB4RLBZIBhEaCRIRPgTA8gwqKEIccgXw4gUNsgUiBAwEBAQ X-IronPort-AV: E=Sophos;i="5.04,757,1406592000"; d="scan'208";a="88686244" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-8.cisco.com with ESMTP; 20 Oct 2014 17:01:53 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s9KH1qAs019079 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Oct 2014 17:01:52 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.122]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Mon, 20 Oct 2014 12:01:52 -0500 From: "Acee Lindem (acee)" To: "Dana Blair (dblair)" Thread-Topic: [netmod] Call for consensus to Accept ACL Model draft-bogdanovic-netmod-acl-model-02 as a WG draft Thread-Index: AQHP7Gp12qzsz05V60GbGaTvuUkcLZw5RwIA Date: Mon, 20 Oct 2014 17:01:51 +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: [10.116.152.202] Content-Type: text/plain; charset="Windows-1252" Content-ID: <0F3B90C2D59FB84E9E54BDF4C8F7E936@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/vSzoQSgCTjrvg8VL0sS8sq3DEs8 Cc: "netmod@ietf.org" Subject: Re: [netmod] Call for consensus to Accept ACL Model draft-bogdanovic-netmod-acl-model-02 as a WG draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 20 Oct 2014 17:12:37 -0000 Hi Dana, et al,=20 Thank you for considering my comments. I now support adoption of the draft as a netmod WG document. With respect to #1, I can envision ways that the =B3order-by user=B2 could be implemented for sequence-number ordered ACLs b= ut they do not eliminate insertion complexities. Thanks, Acee=20 On 10/20/14, 9:33 AM, "Dana Blair (dblair)" wrote: >The authors met and this is the their consolidated response. Look for >DLB: > >Authors,=20 > >I have reviewed the document and have two rather fundamental comments >that preclude me from supporting WG adoption. > > 1. I think you should change the rule-name (type string) to a >sequence-number (type uint16 or int32). While using a string is >ostensibly more flexible, network administrators have been using sequence >numbers for over 30 years now and will be throughly disappointed when >they discover that ACE =B310=B2 lexicographically precedes ACE =B32=B2. T= his >comment has broader significance than just access lists since this model, >if adopted and standardized, will set a precedent for future models. > >DLB: This was discuss extensively among the authors. The conclusion was >not to add sequence numbers since it would essentially result in making >the model unworkable with 2 mutually exclusive keys. See Andy=B9s comment >"The IETF data model cannot do both.=B2 on 10/15. The problem with >sequence-number key is insertion. While the sequence number is widely >used, it has a historical problem of how to insert a new entry between >two adjacent sequence numbers. IOW, how to insert a new entry between >sequence N and N+1. There is no sequence number between N and N+1 which >can be used for the new entry.The options: A. A vendor can use a >proprietary augmentation. There is no restriction here.B. Propose a >pyang =8Bietf compilable augmentation. However, to be considered for the >draft and hopefully ultimate standardization, the augmentation must solve >the insertion problem mentioned above. 2. Please remove section 5 from >the draft. This draft should not mix packet filtering and route >filtering. Though we may get to this hierarchy, I believe that >prefix-lists have much greater affinity with other routing policies than >access-lists. Note that there is a separate route-filtering model in >https://datatracker.ietf.org/doc/draft-zhdankin-netmod-bgp-cfg/. Finally, >the RTGWG is now chartered for YANG models that are not specific to other >Routing area working groups. The discussion of route filters belongs >there or in IDR (since BGP has the most rigorous routing policy >requirements).=20 > >DLB: We=B9ll update the draft to mention this is an example. And also >take a look at the route filter model.Also, a comparably minor comment, >leaf-list targets requires a better definition. It really isn=B9t very >useful without some guidance as to how an implementation=B9s targets shoul= d >be represented. DLB: Agreed it needs a better definition. We=B9ll look >into this for the next version. For example, A proposal for interface >target would help move this along.Thanks, >Acee=20 > =20 > > >On Oct 8, 2014, at 11:14 AM, Thomas D. Nadeau lucidvision.com> wrote: > >>=20 >> The co-authors of draft-bogdanovic-netmod-acl-model-02 have asked the >>NETMOD chairs to post a call to adopt the draft as a WG document. >>=20 >> The draft can be found here: >>=20 >> http://tools.ietf.org/html/draft-bogdanovic-netmod-acl-model-02 >>=20 >> The model itself has been extracted and can be directly accessed here >>using git: >>=20 >>=20 >> https://github.com/YangModels/yang/blob/master/experimental/ietf/ACL-MOD >>EL/ >>=20 >> Please comment by the close of business on Monday, October 13, 2014. >>=20 >>=20 >> --Tom (As NETMOD co-chair) >>=20 >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod at ietf.org >> https://www.ietf.org/mailman/listinfo/netmod From nobody Mon Oct 20 10:28:56 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC691A8791 for ; Mon, 20 Oct 2014 10:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 PTVU2epe9C46 for ; Mon, 20 Oct 2014 10:28:51 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id CEC731A8722 for ; Mon, 20 Oct 2014 10:28:50 -0700 (PDT) Received: from [192.168.1.123] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id D62A328CC039 for ; Mon, 20 Oct 2014 13:28:49 -0400 (EDT) From: Thomas D. Nadeau Content-Type: multipart/signed; boundary="Apple-Mail=_2E2FA528-E6DD-46D1-88B3-6D4E56C5D406"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: <7EE701DB-3632-41E6-BB67-995E23CCEDAF@lucidvision.com> Date: Mon, 20 Oct 2014 13:28:48 -0400 To: NETMOD Working Group Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/3x9C5fzRlQzz9ECdhdyvKNe8wSI Subject: [netmod] NETMOD WG Poll to Adopt ACL Yang Model draft-wildes-netmod-syslog-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: Mon, 20 Oct 2014 17:28:52 -0000 --Apple-Mail=_2E2FA528-E6DD-46D1-88B3-6D4E56C5D406 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Since I have not heard anything during the poll either pro or = against this, I wanted to extent this call until Friday of this week.=20 --Tom The co-authors of draft-wildes-netmod-syslog-model-03.txt have = asked the NETMOD chairs to post a call to adopt the draft as a WG = document.=20 The draft can be found here: http://tools.ietf.org/html/draft-wildes-netmod-syslog-model-03 The model itself has been extracted and can be directly accessed = here using git: = https://github.com/YangModels/yang/tree/master/experimental/ietf/SYSLOG-MO= DEL Please comment by the close of business on Monday, October 13, = 2014. --Tom (As NETMOD co-chair) _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --Apple-Mail=_2E2FA528-E6DD-46D1-88B3-6D4E56C5D406 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJURUZQAAoJEPcO+I7eiUJZvHYP/0JYeajX1r+xNA19ds9pvH5V UDAAsWh6Cdc2jtLcZbwks3KvLoGAJdN2codukPVwQjagBzJEll+gQ+OBqM3mGj3d PDn9EQ1goDEx8m9trzrbPVAfrC5B+aLz+KrqiIt+/fMhxchUQVt56QBTonjZsU5Z OdFU9xzgeKKwLBvaHi1f5M9+wAeUd3ttRVZrC48fPPjo+MCN/p59aCy9Z/s9noKO pOa97Ve3452xAP1qK/GFX9o7W8+H0mfE+xwussOuoOO4bLmtuesc+xmb/Iu8dE/Q qGthFLqLy/E2UUTTIR5+gYmXFPXZn4u7mKzOEEJEwSYvxZ9HbNS8bI4OCDDVv65t lv4x0Cal0KZQ6Ohl/zQstzgsXPIONhgmSRepcN+DgRSfYpf3aVNPkLT4WIYb1mQR DB4yYbDTxSkk+Tkhr7Qtc2cEq0VDJyO1C92FW8Dd4cTMII997nOJ4n8q7gZmDAKH Xc4n07+0fEQIgJBaOE160fG5zk0fyNxeUiUg8y555RPTvjVCaDWzrfhqXHY3KDBs 2JVQyEmNu5/AWSbJC3QXPPTRRek7hfQ4kbPMIMSB9ChrLMMB70/o8wqzurBAEXd/ wXNDj0LJbjtem/XJUdwRu/VcZV4j/thdsUD6NyT+uyA0+ppzQMweHMvKRjWhBZau PXFwJMXO1vam87Ks11QX =ytW3 -----END PGP SIGNATURE----- --Apple-Mail=_2E2FA528-E6DD-46D1-88B3-6D4E56C5D406-- From nobody Mon Oct 20 10:34:05 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFA401A8784 for ; Mon, 20 Oct 2014 10:34:03 -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 vpgvmVPqN-a3 for ; Mon, 20 Oct 2014 10:34:02 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02D791A02BE for ; Mon, 20 Oct 2014 10:34:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1114; q=dns/txt; s=iport; t=1413826442; x=1415036042; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=yKvtFyh1UcwS8XOsfrq/WNOh312bjlJ0DG3w7mBR2oo=; b=SRtHDdiVvJKhz+OVpdQAemLixjXQ7rJcsajcyd27eBut2afcodKo3dML JQ/U7pd4oqLRR2qFC4vMsS92bUe4DEevKsgTmK+V8fKwZ9jZ15oFikg4S Id4UVIvt7LacCENW70py38up8mVqgU1W6bvxoiT8eanln6KseXL9jRoVq k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAGxGRVStJA2J/2dsb2JhbABcgw5TWATMIQyGd1QCgRMWAX2EAwEBAwEBAQFrHQEIbQslAgQBEog3CA3FagEBAQEBBQEBAQEBAQEBARmQWIRLBYskhl2ERocTgTA8gwqDLY1/gjSBQ2yBSIEDAQEB X-IronPort-AV: E=Sophos;i="5.04,757,1406592000"; d="scan'208";a="364624892" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-1.cisco.com with ESMTP; 20 Oct 2014 17:34:01 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s9KHY1d5006486 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Oct 2014 17:34:01 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.151]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Mon, 20 Oct 2014 12:33:37 -0500 From: "Dana Blair (dblair)" To: "Thomas D. Nadeau" , NETMOD Working Group Thread-Topic: [netmod] NETMOD WG Poll to Adopt ACL Yang Model draft-wildes-netmod-syslog-model-03 Thread-Index: AQHP7ItWgvqI3EggtUi/Z1Yl4CzYFJw5T5wA Date: Mon, 20 Oct 2014 17:33:36 +0000 Message-ID: In-Reply-To: <7EE701DB-3632-41E6-BB67-995E23CCEDAF@lucidvision.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.21.117.2] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <31B56A376410864C952E0F8E9A5A01AA@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Z8LNzEPSyDpeiPiAyFlcRD7XG28 Subject: Re: [netmod] NETMOD WG Poll to Adopt ACL Yang Model draft-wildes-netmod-syslog-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: Mon, 20 Oct 2014 17:34:03 -0000 Tom, The subject lines seems to be mixing ACL and Syslog. Should it read =B3NETMOD WG Poll to Adopt Syslog Yang Model draft-wildes-netmod-syslog-model-03 =B3 ? thanks, Dana On 10/20/14, 1:28 PM, "Thomas D. Nadeau" wrote: > > Since I have not heard anything during the poll either pro or against >this, I wanted to extent this call until Friday of this week. > > --Tom > > > > > The co-authors of draft-wildes-netmod-syslog-model-03.txt have asked the >NETMOD chairs to post a call to adopt the draft as a WG document. > > The draft can be found here: > > http://tools.ietf.org/html/draft-wildes-netmod-syslog-model-03 > > The model itself has been extracted and can be directly accessed here >using git: > > https://github.com/YangModels/yang/tree/master/experimental/ietf/SYSLOG-M >ODEL > > Please comment by the close of business on Monday, October 13, 2014. > > > --Tom (As NETMOD co-chair) > > > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From nobody Mon Oct 20 10:53:03 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 976181A8A4E for ; Mon, 20 Oct 2014 10:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 73-JocHyLzVy for ; Mon, 20 Oct 2014 10:52:59 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id B92B51A8A48 for ; Mon, 20 Oct 2014 10:52:59 -0700 (PDT) Received: from [192.168.1.123] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id B3D9228CC0DF; Mon, 20 Oct 2014 13:52:58 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_6183C46E-DD23-47D9-825E-95065E46AC59"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: Date: Mon, 20 Oct 2014 13:52:49 -0400 Message-Id: References: To: "Dana Blair (dblair)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/YGr1RgqfBDvZ9dQM2kJEEskKvdY Cc: NETMOD Working Group Subject: Re: [netmod] NETMOD WG Poll to Adopt ACL Yang Model draft-wildes-netmod-syslog-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: Mon, 20 Oct 2014 17:53:01 -0000 --Apple-Mail=_6183C46E-DD23-47D9-825E-95065E46AC59 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 True. We are asking for both so please respond for both drafts. --Tom > Tom, >=20 > The subject lines seems to be mixing ACL and Syslog. >=20 > Should it read =B3NETMOD WG Poll to Adopt Syslog Yang Model > draft-wildes-netmod-syslog-model-03 =B3 ? >=20 > thanks, > Dana >=20 >=20 >=20 > On 10/20/14, 1:28 PM, "Thomas D. Nadeau" = wrote: >=20 >>=20 >> Since I have not heard anything during the poll either pro or = against >> this, I wanted to extent this call until Friday of this week. >>=20 >> --Tom >>=20 >>=20 >>=20 >>=20 >> The co-authors of draft-wildes-netmod-syslog-model-03.txt have = asked the >> NETMOD chairs to post a call to adopt the draft as a WG document. >>=20 >> The draft can be found here: >>=20 >> http://tools.ietf.org/html/draft-wildes-netmod-syslog-model-03 >>=20 >> The model itself has been extracted and can be directly accessed = here >> using git: >>=20 >> = https://github.com/YangModels/yang/tree/master/experimental/ietf/SYSLOG-M >> ODEL >>=20 >> Please comment by the close of business on Monday, October 13, = 2014. >>=20 >>=20 >> --Tom (As NETMOD co-chair) >>=20 >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 >=20 --Apple-Mail=_6183C46E-DD23-47D9-825E-95065E46AC59 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJURUvxAAoJEPcO+I7eiUJZhX0QAIpoxNZOe9Ezk8+HrMVZU2qM 6UIoyAv8msoJV9XGcx5iwtKFsZ+bRkaIOwDGVYe6I1N3YXG6y844ekBm69gWHzna OwZg8JKyZAZnIBzAiln7sJRLovWHwnFaKkLMNKEeS6PtG/dGMwaF8ntyof+i9grw gcL8XNnZW1D0jSwHAk0+co+axAQLm3G6TeatCb9OB8cZPsNeT0eaipX2KC+pU6qr odRH7ApkTXdu8OVZjtGg7kE3FVbz0NrAaLqGToR0FlqKfKOYC077YRbcxsjT4nIM TrRKoidupYe+zF3+mXymr2YL3KvXhVTTqjWUlcDSLM9NkdMpBFqhVl48BdStexnX 2zbryPbvxfDLn2dZVw6m8AGsNY2GYkJ5waoEF+WvIfjPWP8Ry+CRzZmLhVJi8TeH ZT5DSXZpyJv1mQ7JHpTb6F6zN2d2WvP22VlTOZ5iNM9grF7mF92mYbKTcq6QCX1u 58GjCoy4+cVzG8ac6T9mq14qkx5atYikKZ0KS17UlAP93TqWf+3JFojGgFjT6Thn 5f9/iq0ke1toCviDwRWoOjItOj61bNM/kWGmyxNlRxvLsE/3x8y6PQqFgrrTLbvH 3E+gGwGCf2awNSK8mmtQ4Q6NB7cezgeoJwf4P8TLQKoFHjJm08wWedJaA31bFMgf VzQiuU0ziBOQTA5FXy5u =aWoG -----END PGP SIGNATURE----- --Apple-Mail=_6183C46E-DD23-47D9-825E-95065E46AC59-- From nobody Mon Oct 20 11:40:05 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17E021A9025 for ; Mon, 20 Oct 2014 11:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRJ_kPp4Fmvq for ; Mon, 20 Oct 2014 11:40:01 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3495D1A902F for ; Mon, 20 Oct 2014 11:40:01 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id AA31FC293; Mon, 20 Oct 2014 14:40:00 -0400 (EDT) Date: Mon, 20 Oct 2014 14:40:00 -0400 From: Jeffrey Haas To: "Thomas D. Nadeau" Message-ID: <20141020184000.GE20357@pfrc> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/66ZniGy0bvUTk-Wlovegjz8dRBQ Cc: NETMOD Working Group Subject: Re: [netmod] NETMOD WG Poll to Adopt ACL Yang Model draft-wildes-netmod-syslog-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: Mon, 20 Oct 2014 18:40:03 -0000 On Mon, Oct 20, 2014 at 01:52:49PM -0400, Thomas D. Nadeau wrote: > True. We are asking for both so please respond for both drafts. I support adoption of the ACL model, have read it and have supplied comments to the authors. It's not ready for prime time but the work is moving in a very positive direction. I would also recommend those who are interested in the ACL draft to read through the following documents that have gotten some work for I2RS: http://tools.ietf.org/html/draft-hares-i2rs-info-model-policy-03 https://tools.ietf.org/html/draft-hares-i2rs-bnp-info-model-00 The documents mostly are focused on info-model at the moment but are likely to be heading toward yang representations. Sue has already been in some discussions with Dean about where these documents intersect. The I2RS chairs don't have a strong opinion about where the general policy modeling work gets done. Some of it is solidly in I2RS in scope, but a significant portion of it has cross-WG scope. -- Jeff From nobody Mon Oct 20 19:29:48 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 335F41ACF03; Mon, 20 Oct 2014 19:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.777 X-Spam-Level: X-Spam-Status: No, score=-0.777 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_46=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 jmx-Lyijks6p; Mon, 20 Oct 2014 19:29:37 -0700 (PDT) Received: from mail-yh0-x22f.google.com (mail-yh0-x22f.google.com [IPv6:2607:f8b0:4002:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 749291ACED6; Mon, 20 Oct 2014 19:29:37 -0700 (PDT) Received: by mail-yh0-f47.google.com with SMTP id c41so455717yho.6 for ; Mon, 20 Oct 2014 19:29:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=lSsndNGMrYa+P9EFE0KILP8QNU//4FDyANwmwdbQFSw=; b=BQmHEL6CMhpwl5PlnY5/Dys1gKqcd4TznU8rRivQq+QR7sIFqXc8q+UnJbG8GTKqzH 8zjhjbMU1AZA97iR1cz8bOh68UZRRy2ZIPraRWKI2gus4LRiy//gaTqeOdYL28Hh/wJ/ DeJv6F8NYu9zrjmTkG34Xx/2tqb3sWCMuaR+t05IeDv2mPAzCaaHEZaAvXxJ6hR+E3yc kzqY1dkDPWCIhdMNPRybPwv8+QrrxCVu7g6AjVr1ZPAuy5E5qBXV2wQxoz3O4ArSp6kP w9I32gXeeoLNsaDKgJWdBlYCaaBy0PoaE7mukjZQTTJUZXB0fVhKVKjVmvOU87DB/zbA HtTw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yale.edu; s=googleprd; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=lSsndNGMrYa+P9EFE0KILP8QNU//4FDyANwmwdbQFSw=; b=z3W3aMXFqPOrap9Vx/IwyuZOZHW1Dfd9keSeeT5EOabckSg9phX3290klguePlu3YE 5CNLhnDr2GRnkoH0jgBJZeKf8v3KBtvQrSvS6FrOQQQ9hQ7weY3POR+DcxG5JN8v8oL+ VYqZXAWNdd/gSl9Am8kTxho3pl2vbPS0WUuek= X-Received: by 10.236.19.138 with SMTP id n10mr44744205yhn.55.1413858576684; Mon, 20 Oct 2014 19:29:36 -0700 (PDT) MIME-Version: 1.0 Sender: boxs.jq@gmail.com Received: by 10.170.97.10 with HTTP; Mon, 20 Oct 2014 19:29:16 -0700 (PDT) In-Reply-To: References: From: Xiao SHI Date: Mon, 20 Oct 2014 22:29:16 -0400 X-Google-Sender-Auth: MXji9V77CAiQBvXz-0apkpzOdX0 Message-ID: To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=089e0160befa39db590505e59adc Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/xNN8f39R4HUS-QMrnuVT-brZY-c Cc: IETF ALTO , "netmod@ietf.org" Subject: Re: [netmod] Modeling JSON based protocols using YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 21 Oct 2014 02:29:44 -0000 --089e0160befa39db590505e59adc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Lada, I agree with your statement that YANG is designed to model datastore and the protocol messages. Right now the question I am trying to answer is this scenario: we have the protocols (hence the protocol messages) first, and would like to know whether we would be able to use YANG to model the content messages (in order to use the YANG tools for this protocol, etc.). And the question is what are the conditions for JSON msgs to be able to be modeled by YANG. For JSON arrays: 0. a standalone non-object JSON value is not model-able in YANG: examples: --"foo" --14 --[1,2,3] which translates to the following in XML: <0>1 <1>2 <2>3 This is why your example "foo": [ { "bar": 1 }, 2 ] cannot be modeled--because 2 is a standalone value and {"bar": 1} is an object, otherwise there are following ways to model an array with a mix of elements= : 1. an array with only built-in types or derived types (standalone JSON values except for arrays and objects) can be modeled in YANG as the following: "foo" : [1, "abc", enum1] leaf-list foo { type union { type int64; type string; type enumeration { enum enum1; } } } 2. an array of all objects (1) This structure is model-able as well, right? "foo": [{"a": 1}, {"a": 1, "b": 2}] list foo { leaf a { type int; } leaf b { type int; } } (2) how about this? "foo": [{"a": 1, "b": 2, "c": 3}, {"c": 1, "b":3, "y": 2}] If the JSON-XML translate it to the following: 1 2 3 1 3 2 We can still model this using the choice statement, right? If the above statements about whether these JSON texts are model-able are correct, essentially the only JSON arrays that are not model-able are (a) those mixed with objects and a standalone non-object JSON value; and (b) those whose elements is an array. And this gap is caused by the difference between leaf-list modeling capabilities of handling arrays with non-object, non-array, standalone JSON values, and the list+choice modeling capabilities of modeling arrays with objects. Does this sound plausible? Cheers, Xiao On Mon, Oct 20, 2014 at 11:56 AM, Ladislav Lhotka wrote: > Xiao SHI writes: > > > Hi Lada, > > > > Thank you so much for your feedback! > > > > The motivation here is to produce a YANG model given a defined protocol= , > > e.g. ALTO, CDNi, etc. This way, we may incorporate future protocols int= o > > ODL controllers or use other YANG related tools to handle those > protocols. > > Hence the objective of the modeling is the protocol, not the messages. = I > am > > not suggesting to use YANG as a schema language. > > Hmm, YANG was designed for modelling datastores and contents of protocol > messages, not protocols as such. > > > > > The conditions discussed in this process will be helpful in the followi= ng > > sense: > > 1) disprove the possibility to get a syntactically equivalent YANG mode= l > > from a JSON based protocol; > > 2) generate a Jackson JSON parser class and YANG model from the protoco= ls > > that meet the criteria; > > 3) for designers of future protocols who are thinking of using YANG > related > > tools, set a guideline of what their messages should look like (or MUST > not > > contain); > > 4) for the YANG/NETCONF WG, describing the compatibility issues that th= ey > > might be interested in tackling for expanding YANG's usage. > > > > For this example, "foo": [ { "bar": 1 }, 2 ] is also not easy to do > > data-binding in the parser, because the elements of the array are not o= f > > the same type, which is indeed an assumption that I left out. > > > > For the {"foo=E2=80=9D:null} example, can't we model it using type empt= y? That's > > equivalent to the XML element right? > > corresponds to > > "foo": [null] > > Section 6.9 in draft-ietf-netmod-yang-json-01 gives the reasoning, > essentially it is because some software isn't able to distinguish > > "foo": null > > from "foo" being absent. > > Lada > > > > > Cheers, > > Xiao > > > > On Mon, Oct 20, 2014 at 9:23 AM, Ladislav Lhotka wrote: > > > >> Xiao SHI writes: > >> > >> > Hi folks, > >> > > >> > > >> > As a few of us were working on modeling the ALTO protocol using YANG= , > we > >> > were pondering on a more general question: can YANG model all JSON > based > >> > protocols? What is the condition for a JSON based protocol (at least > the > >> > message format) to have an syntactically equivalent, hence > interoperable, > >> > YANG model with JSON encoding? Alternatively, in order to > interoperate, > >> > semantic equivalence might be sufficient, is there any condition for > >> > semantic equivalence? > >> > > >> > > >> > tl;dr: A JSON based protocol carried by HTTP can have syntactically > >> > equivalent YANG model, if and only if all the keys in the key-value > pairs > >> > in the JSON message are pre-defined keywords in the protocol. > >> > > >> > >> Generating a YANG data model from existing instance data seems backwar= ds > >> to me, although Examplotron (http://examplotron.org) does something > quite > >> similar. In any case, it might be quite challenging because YANG isn't > >> intended as a general schema language. Your observation above is true > >> but it is just one aspect of the problem. For instance > >> > >> "foo": [ { "bar": 1 }, 2 ] > >> > >> or > >> > >> "foo": null > >> > >> cannot be modelled in YANG using the encoding of > >> draft-ietf-netmod-yang-json. > >> > >> Lada > >> > >> > > >> > We've come up with a few ideas, and a few things below are work in > >> > progress, but we would love your feedback! > >> > > >> > > >> > Thank you! > >> > > >> > Xiao > >> > > >> > > >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> > > >> > 1. Introduction. > >> > > >> > JavaScript Object Notation (JSON) has been a popular choice as the > >> message > >> > encoding for many network protocols such as the Application Layer > Traffic > >> > Optimization (ALTO) protocol, the Content Delivery Networks > >> Interconnection > >> > (CDNi) protocol, etc. > >> > > >> > Meanwhile, there are broad interests in the networking community to > use > >> > YANG to define data model so that one can use YANG related tools suc= h > as > >> > OpenDayLight controller. Although YANG itself is XML based, there ha= ve > >> been > >> > efforts to model JSON content using YANG > >> [draft-ietf-netmod-yang-json-01]. > >> > > >> > A natural question rises: can YANG model all JSON based protocols? > What > >> is > >> > the condition for a JSON based protocol (at least the message format= ) > to > >> > have an syntactically equivalent, hence interoperable, YANG model wi= th > >> JSON > >> > encoding? Alternatively, in order to interoperate, semantic > equivalence > >> > might be sufficient, is there any condition for semantic equivalence= ? > >> > > >> > 2. Claim > >> > > >> > A JSON based protocol carried by HTTP can have syntactically > equivalent > >> > YANG model, if and only if: > >> > > >> > (1) the message encoding condition is met; > >> > > >> > (2) the uri condition is met. > >> > > >> > 2.1. The message encoding condition > >> > > >> > The JSON message encoding MUST not contain a variable as a key in a > JSON > >> > object key-value pair. In other words, the keys in the JSON message > must > >> be > >> > an already defined constant (or keyword) in the message format of th= e > >> > protocol. > >> > > >> > For example, if I have a protocol where =E2=80=9Cnetwork-map=E2=80= =9D, =E2=80=9Csrc=E2=80=9D, and > =E2=80=9Cdsts=E2=80=9D > >> > are defined keywords, JSON text A meets the condition whereas B does > not > >> > because =E2=80=9CPID1=E2=80=9D and =E2=80=9CPID2=E2=80=9D are not pr= otocol keywords (they are resource > >> IDs). > >> > > >> > A: > >> > > >> > { > >> > > >> > =E2=80=9Cnetwork-map=E2=80=9D: [ > >> > > >> > { > >> > > >> > =E2=80=9Csrc=E2=80=9D: =E2=80=9CPID1=E2=80=9D, > >> > > >> > =E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID2=E2=80=9D, =E2=80=9CPID3= =E2=80=9D] > >> > > >> > }, > >> > > >> > { > >> > > >> > =E2=80=9Csrc=E2=80=9D: =E2=80=9CPID2=E2=80=9D, > >> > > >> > =E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID3=E2=80=9D, =E2=80=9CPID4= =E2=80=9D] > >> > > >> > } > >> > > >> > ] > >> > > >> > } > >> > > >> > B: > >> > > >> > > >> > { > >> > > >> > =E2=80=9Cnetwork-map=E2=80=9D: [ > >> > > >> > =E2=80=9CPID1: [=E2=80=9CPID2=E2=80=9D, =E2=80=9CPID3=E2=80=9D], > >> > > >> > =E2=80=9CPID2=E2=80=9D: [=E2=80=9CPID3=E2=80=9D, =E2=80=9CPID4=E2= =80=9D] > >> > > >> > ] > >> > > >> > } > >> > > >> >>From this we know that since ALTO protocol uses encoding B, there > cannot > >> be > >> > a syntactically equivalent YANG model. > >> > > >> > 2.2 The URI condition > >> > > >> > Some of the YANG-related protocols might have URI constraints, e.g. > >> > RESTCONF. For now, we assume either that the JSON-based protocol URI > >> could > >> > be conformed to RESTCONF compliant uri, or that the server could hav= e > a > >> > routing mapping between the protocol compliant uri and the RESTCONF > >> > compliant uri, hence this condition would not be an issue, which > allows > >> us > >> > to focus on the message encoding condition. > >> > > >> > 3. Proof > >> > > >> > 3.1. The message encoding condition is necessary. > >> > > >> > We first note that this condition is a necessary condition for a JSO= N > >> based > >> > protocol to have a syntactically equivalent YANG model by proving it= s > >> > contrapositive. > >> > > >> > If one of the keys in the key-value pair in the JSON document is not > >> > pre-defined, the corresponding XML tags will not be pre-defined > keywords. > >> > Therefore, it would not possible to model it in YANG without using > >> > YANG=E2=80=99s anyxml > >> > statement (which allows arbitrary XML content). > >> > > >> > However, using the anyxml statement would defeat our purpose of > modeling > >> > the data as it allows arbitrary XML content, and will not be helpful > in > >> the > >> > subsequent parsing process. > >> > > >> > 3.2. The message encoding condition is sufficient. > >> > > >> > We prove this by providing a translation procedure from a JSON messa= ge > >> that > >> > is compliant with the protocol we are trying to model, to a custom > java > >> > class that can be used for Jackson data binding, then to a YANG mode= l. > >> > > >> > We note that the middle step of translating to and from the custom > parser > >> > class is not necessary, but it will be useful. > >> > > >> > 3.2.1. motivation > >> > > >> > JSON data binding is the process of binding data structures (objects= , > >> > arrays, etc.) in JSON to the appropriate data structures in the serv= er > >> > (e.g. java classes, database tables, etc.) in parsing the JSON text. > In > >> > order to process JSON messages in a meaningful manner, data binding = is > >> > necessary. Even if the binding is not explicit, the server would nee= d > to > >> do > >> > it eventually. For example, one can read JSON content in a stream > without > >> > binding it to the java classes, but eventually in order to make sens= e > of > >> > the data, the server would eventually have to organize it, which is > >> roughly > >> > analogous to data binding upfront. Popular choices for JSON parsing > and > >> > data binding include jackson and gson. > >> > > >> > We use Jackson full data binding as our approach. Full data binding > binds > >> > JSON content into plain old java objects (POJOs), i.e. this custom > parser > >> > class can neither extend nor implement any other class. Jackson uses > >> > ObjectMapper with the custom parser class to parse JSON content into > this > >> > class. > >> > > >> > 3.2.2. The message encoding condition > >> > > >> > The message encoding condition is that all keys in each key-value > pair in > >> > the JSON text must be pre-defined keywords. As the keys will become > >> either > >> > class names and instance variable names, or be keys in the java maps= , > it > >> is > >> > easy to see that the condition is equivalent to =E2=80=9Cthere exist= s a full > data > >> > binding in Jackson custom parser class without using any map > structures > >> > (Map).=E2=80=9D > >> > > >> > 3.2.3. Proof > >> > > >> > We provide a recursive binding process from a JSON object to the > Jackson > >> > custom parser class to be used by Jackson ObjectMapper. > >> > > >> > Type determine_type(value) { > >> > > >> > if (value is of a primitive type, i.e. string, number, boolean, > null) { > >> > > >> > return the corresponding java primitive type; > >> > > >> > } > >> > > >> > if (value is a JSON object) { > >> > > >> > return build_parser_class(value).class; > >> > > >> > } > >> > > >> > if (value is an array) { > >> > > >> > return ArrayList where T=3Ddetermine_type(value[0]); > >> > > >> > } > >> > > >> > // should not reach here. > >> > > >> > } > >> > > >> > Class build_parser_class(JSONObject obj) { > >> > > >> > create custom class C; > >> > > >> > for each key/value pair in the obj { > >> > > >> > add instance variable v in C; > >> > > >> > the name of variable v <- key; // (__known__ a/c to our assumptio= n) > >> > > >> > the type of variable v <- determine_type(value); > >> > > >> > } > >> > > >> > return C.class; > >> > > >> > } > >> > > >> > Naming: > >> > > >> > --change everything into CamelCase (i.e. remove dashes, etc.) > >> > > >> > --for instance variables, use =E2=80=9Cmy=E2=80=9D prefix, (e.g. myV= ariable, > >> myNetworkMap, > >> > etc.) > >> > > >> > --for the custom class name, if the object is an element of the arra= y, > >> use > >> > =E2=80=9CElement=E2=80=9D suffix. > >> > > >> > This is just one convention so that the next step proceeds smoothly. > As > >> > long as this naming translation is consistent with the naming stage = in > >> the > >> > next step, it will work just fine. > >> > > >> > Example (a modified ALTO protocol network map example): > >> > > >> > JSON object: > >> > > >> > { > >> > > >> > =E2=80=9Cmeta=E2=80=9D: { > >> > > >> > =E2=80=9Cresource-id=E2=80=9D: =E2=80=9Cmy-default-map=E2=80=9D, > >> > > >> > =E2=80=9Ctag=E2=80=9D: =E2=80=9Caab875ef69c87d012=E2=80=9D > >> > > >> > }, > >> > > >> > =E2=80=9Cnetwork-map=E2=80=9D: [ > >> > > >> > { > >> > > >> > =E2=80=9Csrc=E2=80=9D: =E2=80=9CPID1=E2=80=9D, > >> > > >> > =E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID1=E2=80=9D, =E2=80=9CPID2= =E2=80=9D, =E2=80=9CPID3=E2=80=9D] > >> > > >> > }, > >> > > >> > { > >> > > >> > =E2=80=9Csrc=E2=80=9D: =E2=80=9CPID2=E2=80=9D, > >> > > >> > =E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID1=E2=80=9D, =E2=80=9CPID3= =E2=80=9D] > >> > > >> > }, > >> > > >> > { > >> > > >> > =E2=80=9Csrc=E2=80=9D: =E2=80=9CPID3=E2=80=9D, > >> > > >> > =E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID2=E2=80=9D, =E2=80=9CPID3= =E2=80=9D] > >> > > >> > } > >> > > >> > ] > >> > > >> > } > >> > > >> > Result of build_parser_class(obj): > >> > > >> > Class JSONObject { > >> > > >> > Meta myMeta; > >> > > >> > ArrayList myNetworkMap; > >> > > >> > } > >> > > >> > Class Meta { > >> > > >> > String myResourceId; > >> > > >> > String myTag; > >> > > >> > } > >> > > >> > Class NetworkMapElement { > >> > > >> > String mySrc; > >> > > >> > ArrayList myDsts; > >> > > >> > } > >> > > >> > Now given the Jackson Parser Java Class, to get a syntactically > >> equivalent > >> > YANG model: > >> > > >> > YANGModel build_yang_model(Class C) { > >> > > >> > for each instance variable (Type, Name) { > >> > > >> > if (Type is primitive type: string, number, boolean, null) { > >> > > >> > add the following to the YANG module: > >> > > >> > =E2=80=9Cleaf Name { type ; }=E2=80=9D > >> > > >> > } > >> > > >> > if (Type is an ArrayList) { > >> > > >> > if (TypeElement is primitive type) { > >> > > >> > add the following to the YANG module: > >> > > >> > =E2=80=9Cleaf-list Name { type ; }=E2=80=9D > >> > > >> > } else { > >> > > >> > // TypeElement is a custom parser class > >> > > >> > add the following to the YANG module: > >> > > >> > =E2=80=9Clist Name { > > }=E2=80=9D > >> > > >> > } > >> > > >> > } > >> > > >> > if (Type is a custom parser class) { > >> > > >> > add the following to the YANG module: > >> > > >> > =E2=80=9Ccontainer Name { > }=E2=80=9D > >> > > >> > } > >> > > >> > } > >> > > >> > } > >> > > >> > Result from the previous example: > >> > > >> > container meta { > >> > > >> > leaf resource-id { > >> > > >> > type string; > >> > > >> > } > >> > > >> > leaf tag { > >> > > >> > type string; > >> > > >> > } > >> > > >> > } > >> > > >> > list network-map { > >> > > >> > leaf src { > >> > > >> > type string; > >> > > >> > } > >> > > >> > leaf-list dsts { > >> > > >> > type string; > >> > > >> > } > >> > > >> > } > >> > > >> > This does validate the JSON document with XML-JSON encoding. For you= r > >> > reference, this is the XML document which validates: > >> > > >> > > >> > > >> > > >> > > >> > my-default-map > >> > > >> > aab875ef69c87d012 > >> > > >> > > >> > > >> > > >> > > >> > PID1 > >> > > >> > PID1 > >> > > >> > PID2 > >> > > >> > PID3 > >> > > >> > > >> > > >> > > >> > > >> > PID2 > >> > > >> > PID1 > >> > > >> > PID3 > >> > > >> > > >> > > >> > > >> > > >> > PID3 > >> > > >> > PID2 > >> > > >> > PID3 > >> > > >> > > >> > > >> > This proves that the message encoding condition is a sufficient > condition > >> > for the JSON object to have a YANG model. > >> > > >> > Note the model generated is very crude and lose almost all constrain= ts > >> and > >> > all inheritance features (if any), because it focuses on the syntax > and > >> is > >> > essentially converted from an JSON object compliant with a protocol > >> instead > >> > of from the protocol itself. Hence this result is more useful in > >> > determining which JSON based protocols cannot have a syntactically > >> > equivalent YANG model, than in generating a good YANG model. > >> > > >> > 3.3. Conclusion > >> > > >> > Our claim holds. A JSON based protocol carried by HTTP can have > >> > syntactically equivalent YANG model, if and only if all the keys in > the > >> > key-value pairs in the JSON message are pre-defined keywords. > >> > > >> > 4. Semantic equivalence > >> > > >> > For JSON based protocols that don=E2=80=99t satisfy the message enco= ding > >> condition, > >> > it is still possible to have a semantically equivalent YANG model. A= ll > >> that > >> > is required for the protocol compliant clients and the YANG model > >> compliant > >> > server to interoperate is an adapter which does the following: > >> > > >> > 1) translate FROM YANG server compliant response msg TO alto complia= nt > >> > response msg > >> > > >> > 2) translate FROM alto compliant request msg TO YANG server complian= t > >> > request msg > >> > > >> > 4.1. Claim > >> > > >> > This adapter needs to be protocol-aware. > >> > > >> > Ideally, given any YANG model, we would like to be able to > automatically > >> > (or at least mechanically) generate this message adapter, which mean= s > not > >> > looking at the protocol or its compliant msgs. However, without > knowing > >> the > >> > specific protocol that we are working with (i.e. human intervention, > i.e. > >> > looking at the protocol compliant msgs), such an adapter cannot be > >> > auto-generated. > >> > > >> > 4.2. Proof by Indistinguishability > >> > > >> > Suppose both the YANG server compliant msg m_y and the actually > protocol > >> > compliant msg m_p are in JSON (or have been encoded into JSON). > Looking > >> at > >> > the differences between the two messages, call these differences {d1= , > d2, > >> > ..., dn}. The goal for the auto-generated adapter would be to identi= fy > >> and > >> > eliminate these differences. Construct a new JSON msg m' where all b= ut > >> one > >> > difference di is the same as m_p and di is the same as the m_y. > Without > >> > looking at the protocol (or m_p), the auto-generated adapter would > not be > >> > able to distinguish between m' and m_p in its translation process, > which > >> > means, it won't be able to tell whether it should change di or not. > >> Hence, > >> > such an adapter must be protocol-aware. > >> > > >> > A good example is the dependent-vtag in the ALTO protocol: > >> > > >> > "dependent-vtag" : [ > >> > > >> > { > >> > > >> > "resource-id" : "my-network-map", > >> > > >> > "tag" : "abcd1234" > >> > > >> > } > >> > > >> > ] > >> > > >> > It was specified this way in the alto protocol. However, it could > >> > conceivably be the case that it was originally the following map > >> structure, > >> > and was converted into the above encoding because of the map->list+k= ey > >> > issue. (This case is actually one of the few differences in the m_y > and > >> m_p > >> > where the adapter does not need to convert it back to a map > structure.) > >> > > >> > "dependent-vtag" : { > >> > > >> > "my-network-map" : { > >> > > >> > "tag" : "abcd1234" > >> > > >> > } > >> > > >> > } > >> > > >> > Without knowing the protocol, there is no way to tell. > >> > > >> > 5. Ramifications > >> > > >> > We now understand the basic condition for a JSON based protocol to > have a > >> > YANG Model. For the protocols that don=E2=80=99t meet this condition= , there > can > >> be > >> > a semantic equivalent YANG model, but there won=E2=80=99t be a gener= ic > process of > >> > generating the adapter for all such protocols. > >> > _______________________________________________ > >> > 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 > --089e0160befa39db590505e59adc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Lada,

I agree with your statement th= at YANG is designed to model datastore and the protocol messages.

Right now the question I am trying to answer is this scenar= io: we have the protocols (hence the protocol messages) first, and would li= ke to know whether we would be able to use YANG to model the content messag= es (in order to use the YANG tools for this protocol, etc.). And the questi= on is what are the conditions for JSON msgs to be able to be modeled by YAN= G.=C2=A0

For JSON arrays:
0. a standalon= e non-object JSON value is not model-able in YANG:
examples:
--"foo"
--14
--[1,2,3]
which = translates to the following in XML:
<0>1</0>
<1>2</1>
<2>3</2>
=
This is why your example "foo": [ { "bar"= ;: 1 }, 2 ] cannot be modeled--because 2 is a standalone value and {"b= ar": 1} is an object, otherwise there are following ways to model an a= rray with a mix of elements:

1. an array with only= built-in types or derived types (standalone JSON values except for arrays = and objects) can be modeled in YANG as the following:
"foo&q= uot; : [1, "abc", enum1]

leaf-list foo {=
=C2=A0 type union {
=C2=A0 =C2=A0 type int64;
=C2=A0 =C2=A0 type string;
=C2=A0 =C2=A0 type enumeration {=
=C2=A0 =C2=A0 =C2=A0 enum enum1;
=C2=A0 =C2=A0 }
=
=C2=A0 }
}

2. an array of all objec= ts
(1) This structure is model-able as well, right?
&qu= ot;foo": [{"a": 1}, {"a": 1, "b": 2}]

list foo {
=C2=A0 leaf a {
=C2= =A0 =C2=A0 type int;
=C2=A0 }
=C2=A0 leaf b {
=C2=A0 =C2=A0 type int;
=C2=A0 }
}

(2) how about this?
"foo": [{"a": = 1, "b": 2, "c": 3}, {"c": 1, "b":3,= "y": 2}]

If the JSON-XML translate it t= o the following:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <foo&g= t;
<a>1= </a>
&l= t;b>2</b>
<= /span><c>3</c>
</foo>
<foo>
<c>1</c>
<b>3</b>
<y>2</y>
</foo>
We can still= model this using the choice statement, right?

If = the above statements about whether these JSON texts are model-able are corr= ect, essentially the only JSON arrays that are not model-able are (a) those= mixed with objects and a standalone non-object JSON value; and (b) those w= hose elements is an array. And this gap is caused by the difference between= leaf-list modeling capabilities of handling arrays with non-object, non-ar= ray, standalone JSON values, and the list+choice modeling capabilities of m= odeling arrays with objects. Does this sound plausible?

Cheers,
Xiao

On Mon, Oct 20, 2014 at 11:56 AM, Ladislav Lhotka <lhot= ka@nic.cz> wrote:
Xiao SHI <xiao.shi@yale.ed= u> writes:

> Hi Lada,
>
> Thank you so much for your feedback!
>
> The motivation here is to produce a YANG model given a defined protoco= l,
> e.g. ALTO, CDNi, etc. This way, we may incorporate future protocols in= to
> ODL controllers or use other YANG related tools to handle those protoc= ols.
> Hence the objective of the modeling is the protocol, not the messages.= I am
> not suggesting to use YANG as a schema language.

Hmm, YANG was designed for modelling datastores and contents of prot= ocol
messages, not protocols as such.

>
> The conditions discussed in this process will be helpful in the follow= ing
> sense:
> 1) disprove the possibility to get a syntactically equivalent YANG mod= el
> from a JSON based protocol;
> 2) generate a Jackson JSON parser class and YANG model from the protoc= ols
> that meet the criteria;
> 3) for designers of future protocols who are thinking of using YANG re= lated
> tools, set a guideline of what their messages should look like (or MUS= T not
> contain);
> 4) for the YANG/NETCONF WG, describing the compatibility issues that t= hey
> might be interested in tackling for expanding YANG's usage.
>
> For this example, "foo": [ { "bar": 1 }, 2 ] is al= so not easy to do
> data-binding in the parser, because the elements of the array are not = of
> the same type, which is indeed an assumption that I left out.
>
> For the {"foo=E2=80=9D:null} example, can't we model it using= type empty? That's
> equivalent to the XML element <foo /> right?

<foo/> corresponds to

"foo": [null]

Section 6.9 in draft-ietf-netmod-yang-json-01 gives the reasoning,
essentially it is because some software isn't able to distinguish

"foo": null

from "foo" being absent.

Lada

>
> Cheers,
> Xiao
>
> On Mon, Oct 20, 2014 at 9:23 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
>> Xiao SHI <xiao.shi@yale.ed= u> writes:
>>
>> > Hi folks,
>> >
>> >
>> > As a few of us were working on modeling the ALTO protocol usi= ng YANG, we
>> > were pondering on a more general question: can YANG model all= JSON based
>> > protocols? What is the condition for a JSON based protocol (a= t least the
>> > message format) to have an syntactically equivalent, hence in= teroperable,
>> > YANG model with JSON encoding? Alternatively, in order to int= eroperate,
>> > semantic equivalence might be sufficient, is there any condit= ion for
>> > semantic equivalence?
>> >
>> >
>> > tl;dr: A JSON based protocol carried by HTTP can have syntact= ically
>> > equivalent YANG model, if and only if all the keys in the key= -value pairs
>> > in the JSON message are pre-defined keywords in the protocol.=
>> >
>>
>> Generating a YANG data model from existing instance data seems bac= kwards
>> to me, although Examplotron (http://examplotron.org) does something quite
>> similar. In any case, it might be quite challenging because YANG i= sn't
>> intended as a general schema language. Your observation above is t= rue
>> but it is just one aspect of the problem. For instance
>>
>> "foo": [ { "bar": 1 }, 2 ]
>>
>> or
>>
>> "foo": null
>>
>> cannot be modelled in YANG using the encoding of
>> draft-ietf-netmod-yang-json.
>>
>> Lada
>>
>> >
>> > We've come up with a few ideas, and a few things below ar= e work in
>> > progress, but we would love your feedback!
>> >
>> >
>> > Thank you!
>> >
>> > Xiao
>> >
>> >
>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
>> >
>> > 1. Introduction.
>> >
>> > JavaScript Object Notation (JSON) has been a popular choice a= s the
>> message
>> > encoding for many network protocols such as the Application L= ayer Traffic
>> > Optimization (ALTO) protocol, the Content Delivery Networks >> Interconnection
>> > (CDNi) protocol, etc.
>> >
>> > Meanwhile, there are broad interests in the networking commun= ity to use
>> > YANG to define data model so that one can use YANG related to= ols such as
>> > OpenDayLight controller. Although YANG itself is XML based, t= here have
>> been
>> > efforts to model JSON content using YANG
>> [draft-ietf-netmod-yang-json-01].
>> >
>> > A natural question rises: can YANG model all JSON based proto= cols? What
>> is
>> > the condition for a JSON based protocol (at least the message= format) to
>> > have an syntactically equivalent, hence interoperable, YANG m= odel with
>> JSON
>> > encoding? Alternatively, in order to interoperate, semantic e= quivalence
>> > might be sufficient, is there any condition for semantic equi= valence?
>> >
>> > 2. Claim
>> >
>> > A JSON based protocol carried by HTTP can have syntactically = equivalent
>> > YANG model, if and only if:
>> >
>> > (1) the message encoding condition is met;
>> >
>> > (2) the uri condition is met.
>> >
>> > 2.1. The message encoding condition
>> >
>> > The JSON message encoding MUST not contain a variable as a ke= y in a JSON
>> > object key-value pair. In other words, the keys in the JSON m= essage must
>> be
>> > an already defined constant (or keyword) in the message forma= t of the
>> > protocol.
>> >
>> > For example, if I have a protocol where =E2=80=9Cnetwork-map= =E2=80=9D, =E2=80=9Csrc=E2=80=9D, and =E2=80=9Cdsts=E2=80=9D
>> > are defined keywords, JSON text A meets the condition whereas= B does not
>> > because =E2=80=9CPID1=E2=80=9D and =E2=80=9CPID2=E2=80=9D are= not protocol keywords (they are resource
>> IDs).
>> >
>> > A:
>> >
>> > {
>> >
>> >=C2=A0 =E2=80=9Cnetwork-map=E2=80=9D: [
>> >
>> >=C2=A0 =C2=A0 {
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =E2=80=9Csrc=E2=80=9D: =E2=80=9CPID1=E2= =80=9D,
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID2=E2= =80=9D, =E2=80=9CPID3=E2=80=9D]
>> >
>> >=C2=A0 =C2=A0 },
>> >
>> >=C2=A0 =C2=A0 {
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =E2=80=9Csrc=E2=80=9D: =E2=80=9CPID2=E2= =80=9D,
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID3=E2= =80=9D, =E2=80=9CPID4=E2=80=9D]
>> >
>> >=C2=A0 =C2=A0 }
>> >
>> >=C2=A0 ]
>> >
>> > }
>> >
>> > B:
>> >
>> >
>> > {
>> >
>> >=C2=A0 =E2=80=9Cnetwork-map=E2=80=9D: [
>> >
>> >=C2=A0 =C2=A0 =E2=80=9CPID1: [=E2=80=9CPID2=E2=80=9D, =E2=80= =9CPID3=E2=80=9D],
>> >
>> >=C2=A0 =C2=A0 =E2=80=9CPID2=E2=80=9D: [=E2=80=9CPID3=E2=80=9D,= =E2=80=9CPID4=E2=80=9D]
>> >
>> >=C2=A0 ]
>> >
>> > }
>> >
>> >>From this we know that since ALTO protocol uses encoding B= , there cannot
>> be
>> > a syntactically equivalent YANG model.
>> >
>> > 2.2 The URI condition
>> >
>> > Some of the YANG-related protocols might have URI constraints= , e.g.
>> > RESTCONF. For now, we assume either that the JSON-based proto= col URI
>> could
>> > be conformed to RESTCONF compliant uri, or that the server co= uld have a
>> > routing mapping between the protocol compliant uri and the RE= STCONF
>> > compliant uri, hence this condition would not be an issue, wh= ich allows
>> us
>> > to focus on the message encoding condition.
>> >
>> > 3. Proof
>> >
>> > 3.1. The message encoding condition is necessary.
>> >
>> > We first note that this condition is a necessary condition fo= r a JSON
>> based
>> > protocol to have a syntactically equivalent YANG model by pro= ving its
>> > contrapositive.
>> >
>> > If one of the keys in the key-value pair in the JSON document= is not
>> > pre-defined, the corresponding XML tags will not be pre-defin= ed keywords.
>> > Therefore, it would not possible to model it in YANG without = using
>> > YANG=E2=80=99s anyxml
>> > statement (which allows arbitrary XML content).
>> >
>> > However, using the anyxml statement would defeat our purpose = of modeling
>> > the data as it allows arbitrary XML content, and will not be = helpful in
>> the
>> > subsequent parsing process.
>> >
>> > 3.2. The message encoding condition is sufficient.
>> >
>> > We prove this by providing a translation procedure from a JSO= N message
>> that
>> > is compliant with the protocol we are trying to model, to a c= ustom java
>> > class that can be used for Jackson data binding, then to a YA= NG model.
>> >
>> > We note that the middle step of translating to and from the c= ustom parser
>> > class is not necessary, but it will be useful.
>> >
>> > 3.2.1. motivation
>> >
>> > JSON data binding is the process of binding data structures (= objects,
>> > arrays, etc.) in JSON to the appropriate data structures in t= he server
>> > (e.g. java classes, database tables, etc.) in parsing the JSO= N text. In
>> > order to process JSON messages in a meaningful manner, data b= inding is
>> > necessary. Even if the binding is not explicit, the server wo= uld need to
>> do
>> > it eventually. For example, one can read JSON content in a st= ream without
>> > binding it to the java classes, but eventually in order to ma= ke sense of
>> > the data, the server would eventually have to organize it, wh= ich is
>> roughly
>> > analogous to data binding upfront. Popular choices for JSON p= arsing and
>> > data binding include jackson and gson.
>> >
>> > We use Jackson full data binding as our approach. Full data b= inding binds
>> > JSON content into plain old java objects (POJOs), i.e. this c= ustom parser
>> > class can neither extend nor implement any other class. Jacks= on uses
>> > ObjectMapper with the custom parser class to parse JSON conte= nt into this
>> > class.
>> >
>> > 3.2.2. The message encoding condition
>> >
>> > The message encoding condition is that all keys in each key-v= alue pair in
>> > the JSON text must be pre-defined keywords. As the keys will = become
>> either
>> > class names and instance variable names, or be keys in the ja= va maps, it
>> is
>> > easy to see that the condition is equivalent to =E2=80=9Cther= e exists a full data
>> > binding in Jackson custom parser class without using any map = structures
>> > (Map<String, ?>).=E2=80=9D
>> >
>> > 3.2.3. Proof
>> >
>> > We provide a recursive binding process from a JSON object to = the Jackson
>> > custom parser class to be used by Jackson ObjectMapper.
>> >
>> > Type determine_type(value) {
>> >
>> >=C2=A0 if (value is of a primitive type, i.e. string, number, = boolean, null) {
>> >
>> >=C2=A0 =C2=A0 return the corresponding java primitive type; >> >
>> >=C2=A0 }
>> >
>> >=C2=A0 if (value is a JSON object) {
>> >
>> >=C2=A0 =C2=A0 return build_parser_class(value).class;
>> >
>> >=C2=A0 }
>> >
>> >=C2=A0 if (value is an array) {
>> >
>> >=C2=A0 =C2=A0 return ArrayList<T> where T=3Ddetermine_ty= pe(value[0]);
>> >
>> >=C2=A0 }
>> >
>> >=C2=A0 // should not reach here.
>> >
>> > }
>> >
>> > Class build_parser_class(JSONObject obj) {
>> >
>> >=C2=A0 create custom class C;
>> >
>> >=C2=A0 for each key/value pair in the obj {
>> >
>> >=C2=A0 =C2=A0 add instance variable v in C;
>> >
>> >=C2=A0 =C2=A0 the name of variable v <- key; // (__known__ = a/c to our assumption)
>> >
>> >=C2=A0 =C2=A0 the type of variable v <- determine_type(valu= e);
>> >
>> >=C2=A0 }
>> >
>> >=C2=A0 return C.class;
>> >
>> > }
>> >
>> > Naming:
>> >
>> > --change everything into CamelCase (i.e. remove dashes, etc.)=
>> >
>> > --for instance variables, use =E2=80=9Cmy=E2=80=9D prefix, (e= .g. myVariable,
>> myNetworkMap,
>> > etc.)
>> >
>> > --for the custom class name, if the object is an element of t= he array,
>> use
>> > =E2=80=9CElement=E2=80=9D suffix.
>> >
>> > This is just one convention so that the next step proceeds sm= oothly. As
>> > long as this naming translation is consistent with the naming= stage in
>> the
>> > next step, it will work just fine.
>> >
>> > Example (a modified ALTO protocol network map example):
>> >
>> > JSON object:
>> >
>> > {
>> >
>> >=C2=A0 =E2=80=9Cmeta=E2=80=9D: {
>> >
>> >=C2=A0 =C2=A0 =E2=80=9Cresource-id=E2=80=9D: =E2=80=9Cmy-defau= lt-map=E2=80=9D,
>> >
>> >=C2=A0 =C2=A0 =E2=80=9Ctag=E2=80=9D: =E2=80=9Caab875ef69c87d01= 2=E2=80=9D
>> >
>> >=C2=A0 },
>> >
>> >=C2=A0 =E2=80=9Cnetwork-map=E2=80=9D: [
>> >
>> >=C2=A0 =C2=A0 {
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =E2=80=9Csrc=E2=80=9D: =E2=80=9CPID1=E2= =80=9D,
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID1=E2= =80=9D, =E2=80=9CPID2=E2=80=9D, =E2=80=9CPID3=E2=80=9D]
>> >
>> >=C2=A0 =C2=A0 },
>> >
>> >=C2=A0 =C2=A0 {
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =E2=80=9Csrc=E2=80=9D: =E2=80=9CPID2=E2= =80=9D,
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID1=E2= =80=9D, =E2=80=9CPID3=E2=80=9D]
>> >
>> >=C2=A0 =C2=A0 },
>> >
>> >=C2=A0 =C2=A0 {
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =E2=80=9Csrc=E2=80=9D: =E2=80=9CPID3=E2= =80=9D,
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID2=E2= =80=9D, =E2=80=9CPID3=E2=80=9D]
>> >
>> >=C2=A0 =C2=A0 }
>> >
>> >=C2=A0 ]
>> >
>> > }
>> >
>> > Result of build_parser_class(obj):
>> >
>> > Class JSONObject {
>> >
>> >=C2=A0 Meta myMeta;
>> >
>> >=C2=A0 ArrayList<NetworkMapElement> myNetworkMap;
>> >
>> > }
>> >
>> > Class Meta {
>> >
>> >=C2=A0 String myResourceId;
>> >
>> >=C2=A0 String myTag;
>> >
>> > }
>> >
>> > Class NetworkMapElement {
>> >
>> >=C2=A0 String mySrc;
>> >
>> >=C2=A0 ArrayList<String> myDsts;
>> >
>> > }
>> >
>> > Now given the Jackson Parser Java Class, to get a syntactical= ly
>> equivalent
>> > YANG model:
>> >
>> > YANGModel build_yang_model(Class C) {
>> >
>> >=C2=A0 for each instance variable (Type, Name) {
>> >
>> >=C2=A0 =C2=A0 if (Type is primitive type: string, number, bool= ean, null) {
>> >
>> >=C2=A0 =C2=A0 =C2=A0 add the following to the YANG module:
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =E2=80=9Cleaf Name { type <YANG equiva= lent of Type>; }=E2=80=9D
>> >
>> >=C2=A0 =C2=A0 }
>> >
>> >=C2=A0 =C2=A0 if (Type is an ArrayList<TypeElement>) { >> >
>> >=C2=A0 =C2=A0 =C2=A0 if (TypeElement is primitive type) {
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 add the following to the YANG modu= le:
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=9Cleaf-list Name { type <= ;YANG equivalent of TypeElement>; }=E2=80=9D
>> >
>> >=C2=A0 =C2=A0 =C2=A0 } else {
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 // TypeElement is a custom parser = class
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 add the following to the YANG modu= le:
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=9Clist Name { <result fr= om build_yang_model<TypeElement.class>> }=E2=80=9D
>> >
>> >=C2=A0 =C2=A0 =C2=A0 }
>> >
>> >=C2=A0 =C2=A0 }
>> >
>> >=C2=A0 =C2=A0 if (Type is a custom parser class) {
>> >
>> >=C2=A0 =C2=A0 =C2=A0 add the following to the YANG module:
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =E2=80=9Ccontainer Name { <result from= build_yang_model<Type.class>> }=E2=80=9D
>> >
>> >=C2=A0 =C2=A0 }
>> >
>> >=C2=A0 }
>> >
>> > }
>> >
>> > Result from the previous example:
>> >
>> > container meta {
>> >
>> >=C2=A0 leaf resource-id {
>> >
>> >=C2=A0 =C2=A0 type string;
>> >
>> >=C2=A0 }
>> >
>> >=C2=A0 leaf tag {
>> >
>> >=C2=A0 =C2=A0 type string;
>> >
>> >=C2=A0 }
>> >
>> > }
>> >
>> > list network-map {
>> >
>> >=C2=A0 leaf src {
>> >
>> >=C2=A0 =C2=A0 type string;
>> >
>> >=C2=A0 }
>> >
>> >=C2=A0 leaf-list dsts {
>> >
>> >=C2=A0 =C2=A0 type string;
>> >
>> >=C2=A0 }
>> >
>> > }
>> >
>> > This does validate the JSON document with XML-JSON encoding. = For your
>> > reference, this is the XML document which validates:
>> >
>> > <?xml version=3D"1.0" encoding=3D"UTF-8&quo= t; ?>
>> >
>> > <meta>
>> >
>> >=C2=A0 <resource-id>my-default-map</resource-id> >> >
>> >=C2=A0 <tag>aab875ef69c87d012</tag>
>> >
>> > </meta>
>> >
>> > <network-map>
>> >
>> >=C2=A0 <src>PID1</src>
>> >
>> >=C2=A0 <dsts>PID1</dsts>
>> >
>> >=C2=A0 <dsts>PID2</dsts>
>> >
>> >=C2=A0 <dsts>PID3</dsts>
>> >
>> > </network-map>
>> >
>> > <network-map>
>> >
>> >=C2=A0 <src>PID2</src>
>> >
>> >=C2=A0 <dsts>PID1</dsts>
>> >
>> >=C2=A0 <dsts>PID3</dsts>
>> >
>> > </network-map>
>> >
>> > <network-map>
>> >
>> >=C2=A0 <src>PID3</src>
>> >
>> >=C2=A0 <dsts>PID2</dsts>
>> >
>> >=C2=A0 <dsts>PID3</dsts>
>> >
>> > </network-map>
>> >
>> > This proves that the message encoding condition is a sufficie= nt condition
>> > for the JSON object to have a YANG model.
>> >
>> > Note the model generated is very crude and lose almost all co= nstraints
>> and
>> > all inheritance features (if any), because it focuses on the = syntax and
>> is
>> > essentially converted from an JSON object compliant with a pr= otocol
>> instead
>> > of from the protocol itself. Hence this result is more useful= in
>> > determining which JSON based protocols cannot have a syntacti= cally
>> > equivalent YANG model, than in generating a good YANG model.<= br> >> >
>> > 3.3. Conclusion
>> >
>> > Our claim holds. A JSON based protocol carried by HTTP can ha= ve
>> > syntactically equivalent YANG model, if and only if all the k= eys in the
>> > key-value pairs in the JSON message are pre-defined keywords.=
>> >
>> > 4. Semantic equivalence
>> >
>> > For JSON based protocols that don=E2=80=99t satisfy the messa= ge encoding
>> condition,
>> > it is still possible to have a semantically equivalent YANG m= odel. All
>> that
>> > is required for the protocol compliant clients and the YANG m= odel
>> compliant
>> > server to interoperate is an adapter which does the following= :
>> >
>> > 1) translate FROM YANG server compliant response msg TO alto = compliant
>> > response msg
>> >
>> > 2) translate FROM alto compliant request msg TO YANG server c= ompliant
>> > request msg
>> >
>> > 4.1. Claim
>> >
>> > This adapter needs to be protocol-aware.
>> >
>> > Ideally, given any YANG model, we would like to be able to au= tomatically
>> > (or at least mechanically) generate this message adapter, whi= ch means not
>> > looking at the protocol or its compliant msgs. However, witho= ut knowing
>> the
>> > specific protocol that we are working with (i.e. human interv= ention, i.e.
>> > looking at the protocol compliant msgs), such an adapter cann= ot be
>> > auto-generated.
>> >
>> > 4.2. Proof by Indistinguishability
>> >
>> > Suppose both the YANG server compliant msg m_y and the actual= ly protocol
>> > compliant msg m_p are in JSON (or have been encoded into JSON= ). Looking
>> at
>> > the differences between the two messages, call these differen= ces {d1, d2,
>> > ..., dn}. The goal for the auto-generated adapter would be to= identify
>> and
>> > eliminate these differences. Construct a new JSON msg m' = where all but
>> one
>> > difference di is the same as m_p and di is the same as the m_= y. Without
>> > looking at the protocol (or m_p), the auto-generated adapter = would not be
>> > able to distinguish between m' and m_p in its translation= process, which
>> > means, it won't be able to tell whether it should change = di or not.
>> Hence,
>> > such an adapter must be protocol-aware.
>> >
>> > A good example is the dependent-vtag in the ALTO protocol: >> >
>> > "dependent-vtag" : [
>> >
>> >=C2=A0 {
>> >
>> >=C2=A0 =C2=A0 "resource-id" : "my-network-map&q= uot;,
>> >
>> >=C2=A0 =C2=A0 "tag" : "abcd1234"
>> >
>> >=C2=A0 }
>> >
>> > ]
>> >
>> > It was specified this way in the alto protocol. However, it c= ould
>> > conceivably be the case that it was originally the following = map
>> structure,
>> > and was converted into the above encoding because of the map-= >list+key
>> > issue. (This case is actually one of the few differences in t= he m_y and
>> m_p
>> > where the adapter does not need to convert it back to a map s= tructure.)
>> >
>> > "dependent-vtag" : {
>> >
>> >=C2=A0 "my-network-map" : {
>> >
>> >=C2=A0 =C2=A0 "tag" : "abcd1234"
>> >
>> >=C2=A0 }
>> >
>> > }
>> >
>> > Without knowing the protocol, there is no way to tell.
>> >
>> > 5. Ramifications
>> >
>> > We now understand the basic condition for a JSON based protoc= ol to have a
>> > YANG Model. For the protocols that don=E2=80=99t meet this co= ndition, there can
>> be
>> > a semantic equivalent YANG model, but there won=E2=80=99t be = a generic process of
>> > generating the adapter for all such protocols.
>> > _______________________________________________
>> > 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

--089e0160befa39db590505e59adc-- From nobody Mon Oct 20 23:00:54 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB14E1AD05F; Mon, 20 Oct 2014 23:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, 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 SLoLO6em7xZ6; Mon, 20 Oct 2014 23:00:51 -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 DB5AD1A6F9C; Mon, 20 Oct 2014 23:00: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 3F1D26F7; Tue, 21 Oct 2014 08:00:49 +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 wVB_nvcgizX0; Tue, 21 Oct 2014 08:00: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; Tue, 21 Oct 2014 08:00:48 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 46EDD20037; Tue, 21 Oct 2014 08:00:48 +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 U-349RVMiqCR; Tue, 21 Oct 2014 08:00: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 775B220038; Tue, 21 Oct 2014 08:00:46 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 64ED92F0641A; Tue, 21 Oct 2014 08:00:46 +0200 (CEST) Date: Tue, 21 Oct 2014 08:00:46 +0200 From: Juergen Schoenwaelder To: Xiao SHI Message-ID: <20141021060046.GB89879@elstar.local> Mail-Followup-To: Xiao SHI , Ladislav Lhotka , IETF ALTO , "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: http://mailarchive.ietf.org/arch/msg/netmod/H2EnSYFeL71wuOmPod7d-OgXWVo Cc: "netmod@ietf.org" , IETF ALTO Subject: Re: [netmod] Modeling JSON based protocols using YANG 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, 21 Oct 2014 06:00:53 -0000 On Mon, Oct 20, 2014 at 10:29:16PM -0400, Xiao SHI wrote: > Hi Lada, > > I agree with your statement that YANG is designed to model datastore and > the protocol messages. > YANG was designed to model datastores. It was _not_ designed to model arbtirary protocol messages. Here is the abstract of RFC 6020: YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. I think this describes the purpose quite clearly. I understand that people like to expand the scope in several directions and I think it is good if people experiment with new ideas. However, one important goal is also to keep YANG highly useful for the original purpose it was created for. /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 Oct 21 02:31:45 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05D6E1A03AA; Tue, 21 Oct 2014 02:31:39 -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_46=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 dXoziPKT2XY3; Tue, 21 Oct 2014 02:31:34 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 799561A064C; Tue, 21 Oct 2014 02:29:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id AA9FA54074A; Tue, 21 Oct 2014 11:29:35 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cd+O1HZqnj3a; Tue, 21 Oct 2014 11:29:29 +0200 (CEST) Received: from localhost (unknown [195.113.220.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 5704A540336; Tue, 21 Oct 2014 11:29:27 +0200 (CEST) From: Ladislav Lhotka To: Xiao SHI In-Reply-To: References: User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Tue, 21 Oct 2014 11:29:28 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/u-ANX6gMOWh1TdH5adQqYCbcvlE Cc: IETF ALTO , "netmod@ietf.org" Subject: Re: [netmod] Modeling JSON based protocols using YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 21 Oct 2014 09:31:39 -0000 Hi Xiao, see inline. Xiao SHI writes: > Hi Lada, > > I agree with your statement that YANG is designed to model datastore and > the protocol messages. > > Right now the question I am trying to answer is this scenario: we have the > protocols (hence the protocol messages) first, and would like to know > whether we would be able to use YANG to model the content messages (in > order to use the YANG tools for this protocol, etc.). And the question is > what are the conditions for JSON msgs to be able to be modeled by YANG. > > For JSON arrays: > 0. a standalone non-object JSON value is not model-able in YANG: > examples: > --"foo" > --14 > --[1,2,3] > which translates to the following in XML: > <0>1 > <1>2 > <2>3 > > This is why your example "foo": [ { "bar": 1 }, 2 ] cannot be > modeled--because 2 is a standalone value and {"bar": 1} is an object, Yes. > otherwise there are following ways to model an array with a mix of elemen= ts: > > 1. an array with only built-in types or derived types (standalone JSON > values except for arrays and objects) can be modeled in YANG as the > following: > "foo" : [1, "abc", enum1] It should be "foo" : [1, "abc", "enum1"] > > leaf-list foo { > type union { > type int64; > type string; > type enumeration { > enum enum1; > } > } > } Right. > > 2. an array of all objects > (1) This structure is model-able as well, right? > "foo": [{"a": 1}, {"a": 1, "b": 2}] > > list foo { > leaf a { > type int; > } > leaf b { > type int; > } > } Yes. > > (2) how about this? > "foo": [{"a": 1, "b": 2, "c": 3}, {"c": 1, "b":3, "y": 2}] > > If the JSON-XML translate it to the following: > > 1 > 2 > 3 > > > 1 > 3 > 2 > > We can still model this using the choice statement, right? Right. > > If the above statements about whether these JSON texts are model-able are > correct, essentially the only JSON arrays that are not model-able are (a) > those mixed with objects and a standalone non-object JSON value; and (b) > those whose elements is an array. And this gap is caused by the difference > between leaf-list modeling capabilities of handling arrays with non-objec= t, > non-array, standalone JSON values, and the list+choice modeling > capabilities of modeling arrays with objects. Does this sound > plausible? It does, I am not aware of any other issues. Cheers, Lada=20 > > Cheers, > Xiao > > On Mon, Oct 20, 2014 at 11:56 AM, Ladislav Lhotka wrote: > >> Xiao SHI writes: >> >> > Hi Lada, >> > >> > Thank you so much for your feedback! >> > >> > The motivation here is to produce a YANG model given a defined protoco= l, >> > e.g. ALTO, CDNi, etc. This way, we may incorporate future protocols in= to >> > ODL controllers or use other YANG related tools to handle those >> protocols. >> > Hence the objective of the modeling is the protocol, not the messages.= I >> am >> > not suggesting to use YANG as a schema language. >> >> Hmm, YANG was designed for modelling datastores and contents of protocol >> messages, not protocols as such. >> >> > >> > The conditions discussed in this process will be helpful in the follow= ing >> > sense: >> > 1) disprove the possibility to get a syntactically equivalent YANG mod= el >> > from a JSON based protocol; >> > 2) generate a Jackson JSON parser class and YANG model from the protoc= ols >> > that meet the criteria; >> > 3) for designers of future protocols who are thinking of using YANG >> related >> > tools, set a guideline of what their messages should look like (or MUST >> not >> > contain); >> > 4) for the YANG/NETCONF WG, describing the compatibility issues that t= hey >> > might be interested in tackling for expanding YANG's usage. >> > >> > For this example, "foo": [ { "bar": 1 }, 2 ] is also not easy to do >> > data-binding in the parser, because the elements of the array are not = of >> > the same type, which is indeed an assumption that I left out. >> > >> > For the {"foo=E2=80=9D:null} example, can't we model it using type emp= ty? That's >> > equivalent to the XML element right? >> >> corresponds to >> >> "foo": [null] >> >> Section 6.9 in draft-ietf-netmod-yang-json-01 gives the reasoning, >> essentially it is because some software isn't able to distinguish >> >> "foo": null >> >> from "foo" being absent. >> >> Lada >> >> > >> > Cheers, >> > Xiao >> > >> > On Mon, Oct 20, 2014 at 9:23 AM, Ladislav Lhotka wrote: >> > >> >> Xiao SHI writes: >> >> >> >> > Hi folks, >> >> > >> >> > >> >> > As a few of us were working on modeling the ALTO protocol using YAN= G, >> we >> >> > were pondering on a more general question: can YANG model all JSON >> based >> >> > protocols? What is the condition for a JSON based protocol (at least >> the >> >> > message format) to have an syntactically equivalent, hence >> interoperable, >> >> > YANG model with JSON encoding? Alternatively, in order to >> interoperate, >> >> > semantic equivalence might be sufficient, is there any condition for >> >> > semantic equivalence? >> >> > >> >> > >> >> > tl;dr: A JSON based protocol carried by HTTP can have syntactically >> >> > equivalent YANG model, if and only if all the keys in the key-value >> pairs >> >> > in the JSON message are pre-defined keywords in the protocol. >> >> > >> >> >> >> Generating a YANG data model from existing instance data seems backwa= rds >> >> to me, although Examplotron (http://examplotron.org) does something >> quite >> >> similar. In any case, it might be quite challenging because YANG isn't >> >> intended as a general schema language. Your observation above is true >> >> but it is just one aspect of the problem. For instance >> >> >> >> "foo": [ { "bar": 1 }, 2 ] >> >> >> >> or >> >> >> >> "foo": null >> >> >> >> cannot be modelled in YANG using the encoding of >> >> draft-ietf-netmod-yang-json. >> >> >> >> Lada >> >> >> >> > >> >> > We've come up with a few ideas, and a few things below are work in >> >> > progress, but we would love your feedback! >> >> > >> >> > >> >> > Thank you! >> >> > >> >> > Xiao >> >> > >> >> > >> >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> > >> >> > 1. Introduction. >> >> > >> >> > JavaScript Object Notation (JSON) has been a popular choice as the >> >> message >> >> > encoding for many network protocols such as the Application Layer >> Traffic >> >> > Optimization (ALTO) protocol, the Content Delivery Networks >> >> Interconnection >> >> > (CDNi) protocol, etc. >> >> > >> >> > Meanwhile, there are broad interests in the networking community to >> use >> >> > YANG to define data model so that one can use YANG related tools su= ch >> as >> >> > OpenDayLight controller. Although YANG itself is XML based, there h= ave >> >> been >> >> > efforts to model JSON content using YANG >> >> [draft-ietf-netmod-yang-json-01]. >> >> > >> >> > A natural question rises: can YANG model all JSON based protocols? >> What >> >> is >> >> > the condition for a JSON based protocol (at least the message forma= t) >> to >> >> > have an syntactically equivalent, hence interoperable, YANG model w= ith >> >> JSON >> >> > encoding? Alternatively, in order to interoperate, semantic >> equivalence >> >> > might be sufficient, is there any condition for semantic equivalenc= e? >> >> > >> >> > 2. Claim >> >> > >> >> > A JSON based protocol carried by HTTP can have syntactically >> equivalent >> >> > YANG model, if and only if: >> >> > >> >> > (1) the message encoding condition is met; >> >> > >> >> > (2) the uri condition is met. >> >> > >> >> > 2.1. The message encoding condition >> >> > >> >> > The JSON message encoding MUST not contain a variable as a key in a >> JSON >> >> > object key-value pair. In other words, the keys in the JSON message >> must >> >> be >> >> > an already defined constant (or keyword) in the message format of t= he >> >> > protocol. >> >> > >> >> > For example, if I have a protocol where =E2=80=9Cnetwork-map=E2=80= =9D, =E2=80=9Csrc=E2=80=9D, and >> =E2=80=9Cdsts=E2=80=9D >> >> > are defined keywords, JSON text A meets the condition whereas B does >> not >> >> > because =E2=80=9CPID1=E2=80=9D and =E2=80=9CPID2=E2=80=9D are not p= rotocol keywords (they are resource >> >> IDs). >> >> > >> >> > A: >> >> > >> >> > { >> >> > >> >> > =E2=80=9Cnetwork-map=E2=80=9D: [ >> >> > >> >> > { >> >> > >> >> > =E2=80=9Csrc=E2=80=9D: =E2=80=9CPID1=E2=80=9D, >> >> > >> >> > =E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID2=E2=80=9D, =E2=80=9CPID3= =E2=80=9D] >> >> > >> >> > }, >> >> > >> >> > { >> >> > >> >> > =E2=80=9Csrc=E2=80=9D: =E2=80=9CPID2=E2=80=9D, >> >> > >> >> > =E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID3=E2=80=9D, =E2=80=9CPID4= =E2=80=9D] >> >> > >> >> > } >> >> > >> >> > ] >> >> > >> >> > } >> >> > >> >> > B: >> >> > >> >> > >> >> > { >> >> > >> >> > =E2=80=9Cnetwork-map=E2=80=9D: [ >> >> > >> >> > =E2=80=9CPID1: [=E2=80=9CPID2=E2=80=9D, =E2=80=9CPID3=E2=80=9D], >> >> > >> >> > =E2=80=9CPID2=E2=80=9D: [=E2=80=9CPID3=E2=80=9D, =E2=80=9CPID4= =E2=80=9D] >> >> > >> >> > ] >> >> > >> >> > } >> >> > >> >> >>From this we know that since ALTO protocol uses encoding B, there >> cannot >> >> be >> >> > a syntactically equivalent YANG model. >> >> > >> >> > 2.2 The URI condition >> >> > >> >> > Some of the YANG-related protocols might have URI constraints, e.g. >> >> > RESTCONF. For now, we assume either that the JSON-based protocol URI >> >> could >> >> > be conformed to RESTCONF compliant uri, or that the server could ha= ve >> a >> >> > routing mapping between the protocol compliant uri and the RESTCONF >> >> > compliant uri, hence this condition would not be an issue, which >> allows >> >> us >> >> > to focus on the message encoding condition. >> >> > >> >> > 3. Proof >> >> > >> >> > 3.1. The message encoding condition is necessary. >> >> > >> >> > We first note that this condition is a necessary condition for a JS= ON >> >> based >> >> > protocol to have a syntactically equivalent YANG model by proving i= ts >> >> > contrapositive. >> >> > >> >> > If one of the keys in the key-value pair in the JSON document is not >> >> > pre-defined, the corresponding XML tags will not be pre-defined >> keywords. >> >> > Therefore, it would not possible to model it in YANG without using >> >> > YANG=E2=80=99s anyxml >> >> > statement (which allows arbitrary XML content). >> >> > >> >> > However, using the anyxml statement would defeat our purpose of >> modeling >> >> > the data as it allows arbitrary XML content, and will not be helpful >> in >> >> the >> >> > subsequent parsing process. >> >> > >> >> > 3.2. The message encoding condition is sufficient. >> >> > >> >> > We prove this by providing a translation procedure from a JSON mess= age >> >> that >> >> > is compliant with the protocol we are trying to model, to a custom >> java >> >> > class that can be used for Jackson data binding, then to a YANG mod= el. >> >> > >> >> > We note that the middle step of translating to and from the custom >> parser >> >> > class is not necessary, but it will be useful. >> >> > >> >> > 3.2.1. motivation >> >> > >> >> > JSON data binding is the process of binding data structures (object= s, >> >> > arrays, etc.) in JSON to the appropriate data structures in the ser= ver >> >> > (e.g. java classes, database tables, etc.) in parsing the JSON text. >> In >> >> > order to process JSON messages in a meaningful manner, data binding= is >> >> > necessary. Even if the binding is not explicit, the server would ne= ed >> to >> >> do >> >> > it eventually. For example, one can read JSON content in a stream >> without >> >> > binding it to the java classes, but eventually in order to make sen= se >> of >> >> > the data, the server would eventually have to organize it, which is >> >> roughly >> >> > analogous to data binding upfront. Popular choices for JSON parsing >> and >> >> > data binding include jackson and gson. >> >> > >> >> > We use Jackson full data binding as our approach. Full data binding >> binds >> >> > JSON content into plain old java objects (POJOs), i.e. this custom >> parser >> >> > class can neither extend nor implement any other class. Jackson uses >> >> > ObjectMapper with the custom parser class to parse JSON content into >> this >> >> > class. >> >> > >> >> > 3.2.2. The message encoding condition >> >> > >> >> > The message encoding condition is that all keys in each key-value >> pair in >> >> > the JSON text must be pre-defined keywords. As the keys will become >> >> either >> >> > class names and instance variable names, or be keys in the java map= s, >> it >> >> is >> >> > easy to see that the condition is equivalent to =E2=80=9Cthere exis= ts a full >> data >> >> > binding in Jackson custom parser class without using any map >> structures >> >> > (Map).=E2=80=9D >> >> > >> >> > 3.2.3. Proof >> >> > >> >> > We provide a recursive binding process from a JSON object to the >> Jackson >> >> > custom parser class to be used by Jackson ObjectMapper. >> >> > >> >> > Type determine_type(value) { >> >> > >> >> > if (value is of a primitive type, i.e. string, number, boolean, >> null) { >> >> > >> >> > return the corresponding java primitive type; >> >> > >> >> > } >> >> > >> >> > if (value is a JSON object) { >> >> > >> >> > return build_parser_class(value).class; >> >> > >> >> > } >> >> > >> >> > if (value is an array) { >> >> > >> >> > return ArrayList where T=3Ddetermine_type(value[0]); >> >> > >> >> > } >> >> > >> >> > // should not reach here. >> >> > >> >> > } >> >> > >> >> > Class build_parser_class(JSONObject obj) { >> >> > >> >> > create custom class C; >> >> > >> >> > for each key/value pair in the obj { >> >> > >> >> > add instance variable v in C; >> >> > >> >> > the name of variable v <- key; // (__known__ a/c to our assumpti= on) >> >> > >> >> > the type of variable v <- determine_type(value); >> >> > >> >> > } >> >> > >> >> > return C.class; >> >> > >> >> > } >> >> > >> >> > Naming: >> >> > >> >> > --change everything into CamelCase (i.e. remove dashes, etc.) >> >> > >> >> > --for instance variables, use =E2=80=9Cmy=E2=80=9D prefix, (e.g. my= Variable, >> >> myNetworkMap, >> >> > etc.) >> >> > >> >> > --for the custom class name, if the object is an element of the arr= ay, >> >> use >> >> > =E2=80=9CElement=E2=80=9D suffix. >> >> > >> >> > This is just one convention so that the next step proceeds smoothly. >> As >> >> > long as this naming translation is consistent with the naming stage= in >> >> the >> >> > next step, it will work just fine. >> >> > >> >> > Example (a modified ALTO protocol network map example): >> >> > >> >> > JSON object: >> >> > >> >> > { >> >> > >> >> > =E2=80=9Cmeta=E2=80=9D: { >> >> > >> >> > =E2=80=9Cresource-id=E2=80=9D: =E2=80=9Cmy-default-map=E2=80=9D, >> >> > >> >> > =E2=80=9Ctag=E2=80=9D: =E2=80=9Caab875ef69c87d012=E2=80=9D >> >> > >> >> > }, >> >> > >> >> > =E2=80=9Cnetwork-map=E2=80=9D: [ >> >> > >> >> > { >> >> > >> >> > =E2=80=9Csrc=E2=80=9D: =E2=80=9CPID1=E2=80=9D, >> >> > >> >> > =E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID1=E2=80=9D, =E2=80=9CPID2= =E2=80=9D, =E2=80=9CPID3=E2=80=9D] >> >> > >> >> > }, >> >> > >> >> > { >> >> > >> >> > =E2=80=9Csrc=E2=80=9D: =E2=80=9CPID2=E2=80=9D, >> >> > >> >> > =E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID1=E2=80=9D, =E2=80=9CPID3= =E2=80=9D] >> >> > >> >> > }, >> >> > >> >> > { >> >> > >> >> > =E2=80=9Csrc=E2=80=9D: =E2=80=9CPID3=E2=80=9D, >> >> > >> >> > =E2=80=9Cdsts=E2=80=9D: [=E2=80=9CPID2=E2=80=9D, =E2=80=9CPID3= =E2=80=9D] >> >> > >> >> > } >> >> > >> >> > ] >> >> > >> >> > } >> >> > >> >> > Result of build_parser_class(obj): >> >> > >> >> > Class JSONObject { >> >> > >> >> > Meta myMeta; >> >> > >> >> > ArrayList myNetworkMap; >> >> > >> >> > } >> >> > >> >> > Class Meta { >> >> > >> >> > String myResourceId; >> >> > >> >> > String myTag; >> >> > >> >> > } >> >> > >> >> > Class NetworkMapElement { >> >> > >> >> > String mySrc; >> >> > >> >> > ArrayList myDsts; >> >> > >> >> > } >> >> > >> >> > Now given the Jackson Parser Java Class, to get a syntactically >> >> equivalent >> >> > YANG model: >> >> > >> >> > YANGModel build_yang_model(Class C) { >> >> > >> >> > for each instance variable (Type, Name) { >> >> > >> >> > if (Type is primitive type: string, number, boolean, null) { >> >> > >> >> > add the following to the YANG module: >> >> > >> >> > =E2=80=9Cleaf Name { type ; }=E2=80=9D >> >> > >> >> > } >> >> > >> >> > if (Type is an ArrayList) { >> >> > >> >> > if (TypeElement is primitive type) { >> >> > >> >> > add the following to the YANG module: >> >> > >> >> > =E2=80=9Cleaf-list Name { type ; }=E2=80=9D >> >> > >> >> > } else { >> >> > >> >> > // TypeElement is a custom parser class >> >> > >> >> > add the following to the YANG module: >> >> > >> >> > =E2=80=9Clist Name { > >> }=E2=80=9D >> >> > >> >> > } >> >> > >> >> > } >> >> > >> >> > if (Type is a custom parser class) { >> >> > >> >> > add the following to the YANG module: >> >> > >> >> > =E2=80=9Ccontainer Name { > }=E2=80=9D >> >> > >> >> > } >> >> > >> >> > } >> >> > >> >> > } >> >> > >> >> > Result from the previous example: >> >> > >> >> > container meta { >> >> > >> >> > leaf resource-id { >> >> > >> >> > type string; >> >> > >> >> > } >> >> > >> >> > leaf tag { >> >> > >> >> > type string; >> >> > >> >> > } >> >> > >> >> > } >> >> > >> >> > list network-map { >> >> > >> >> > leaf src { >> >> > >> >> > type string; >> >> > >> >> > } >> >> > >> >> > leaf-list dsts { >> >> > >> >> > type string; >> >> > >> >> > } >> >> > >> >> > } >> >> > >> >> > This does validate the JSON document with XML-JSON encoding. For yo= ur >> >> > reference, this is the XML document which validates: >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > my-default-map >> >> > >> >> > aab875ef69c87d012 >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > PID1 >> >> > >> >> > PID1 >> >> > >> >> > PID2 >> >> > >> >> > PID3 >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > PID2 >> >> > >> >> > PID1 >> >> > >> >> > PID3 >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > PID3 >> >> > >> >> > PID2 >> >> > >> >> > PID3 >> >> > >> >> > >> >> > >> >> > This proves that the message encoding condition is a sufficient >> condition >> >> > for the JSON object to have a YANG model. >> >> > >> >> > Note the model generated is very crude and lose almost all constrai= nts >> >> and >> >> > all inheritance features (if any), because it focuses on the syntax >> and >> >> is >> >> > essentially converted from an JSON object compliant with a protocol >> >> instead >> >> > of from the protocol itself. Hence this result is more useful in >> >> > determining which JSON based protocols cannot have a syntactically >> >> > equivalent YANG model, than in generating a good YANG model. >> >> > >> >> > 3.3. Conclusion >> >> > >> >> > Our claim holds. A JSON based protocol carried by HTTP can have >> >> > syntactically equivalent YANG model, if and only if all the keys in >> the >> >> > key-value pairs in the JSON message are pre-defined keywords. >> >> > >> >> > 4. Semantic equivalence >> >> > >> >> > For JSON based protocols that don=E2=80=99t satisfy the message enc= oding >> >> condition, >> >> > it is still possible to have a semantically equivalent YANG model. = All >> >> that >> >> > is required for the protocol compliant clients and the YANG model >> >> compliant >> >> > server to interoperate is an adapter which does the following: >> >> > >> >> > 1) translate FROM YANG server compliant response msg TO alto compli= ant >> >> > response msg >> >> > >> >> > 2) translate FROM alto compliant request msg TO YANG server complia= nt >> >> > request msg >> >> > >> >> > 4.1. Claim >> >> > >> >> > This adapter needs to be protocol-aware. >> >> > >> >> > Ideally, given any YANG model, we would like to be able to >> automatically >> >> > (or at least mechanically) generate this message adapter, which mea= ns >> not >> >> > looking at the protocol or its compliant msgs. However, without >> knowing >> >> the >> >> > specific protocol that we are working with (i.e. human intervention, >> i.e. >> >> > looking at the protocol compliant msgs), such an adapter cannot be >> >> > auto-generated. >> >> > >> >> > 4.2. Proof by Indistinguishability >> >> > >> >> > Suppose both the YANG server compliant msg m_y and the actually >> protocol >> >> > compliant msg m_p are in JSON (or have been encoded into JSON). >> Looking >> >> at >> >> > the differences between the two messages, call these differences {d= 1, >> d2, >> >> > ..., dn}. The goal for the auto-generated adapter would be to ident= ify >> >> and >> >> > eliminate these differences. Construct a new JSON msg m' where all = but >> >> one >> >> > difference di is the same as m_p and di is the same as the m_y. >> Without >> >> > looking at the protocol (or m_p), the auto-generated adapter would >> not be >> >> > able to distinguish between m' and m_p in its translation process, >> which >> >> > means, it won't be able to tell whether it should change di or not. >> >> Hence, >> >> > such an adapter must be protocol-aware. >> >> > >> >> > A good example is the dependent-vtag in the ALTO protocol: >> >> > >> >> > "dependent-vtag" : [ >> >> > >> >> > { >> >> > >> >> > "resource-id" : "my-network-map", >> >> > >> >> > "tag" : "abcd1234" >> >> > >> >> > } >> >> > >> >> > ] >> >> > >> >> > It was specified this way in the alto protocol. However, it could >> >> > conceivably be the case that it was originally the following map >> >> structure, >> >> > and was converted into the above encoding because of the map->list+= key >> >> > issue. (This case is actually one of the few differences in the m_y >> and >> >> m_p >> >> > where the adapter does not need to convert it back to a map >> structure.) >> >> > >> >> > "dependent-vtag" : { >> >> > >> >> > "my-network-map" : { >> >> > >> >> > "tag" : "abcd1234" >> >> > >> >> > } >> >> > >> >> > } >> >> > >> >> > Without knowing the protocol, there is no way to tell. >> >> > >> >> > 5. Ramifications >> >> > >> >> > We now understand the basic condition for a JSON based protocol to >> have a >> >> > YANG Model. For the protocols that don=E2=80=99t meet this conditio= n, there >> can >> >> be >> >> > a semantic equivalent YANG model, but there won=E2=80=99t be a gene= ric >> process of >> >> > generating the adapter for all such protocols. >> >> > _______________________________________________ >> >> > 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 Tue Oct 21 04:04:07 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A80E1A0861 for ; Tue, 21 Oct 2014 04:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.74 X-Spam-Level: * X-Spam-Status: No, score=1.74 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 et1BsfGv_Hwe for ; Tue, 21 Oct 2014 04:04:00 -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 CDD841A0636 for ; Tue, 21 Oct 2014 04:03:49 -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 BKT87529; Tue, 21 Oct 2014 11:03:48 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 21 Oct 2014 12:03:47 +0100 Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.104]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Tue, 21 Oct 2014 19:03:41 +0800 From: Yangang To: "Dana Blair (dblair)" Thread-Topic: Some comments about ACL YANG model. Thread-Index: AQHP7GcJNvv6hgwmVkSOGKo7BQmMmZw6YA8Q Date: Tue, 21 Oct 2014 11:03:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.72.210] Content-Type: multipart/alternative; boundary="_000_D496C972D1A13540A730720631EC73413A41B06Ankgeml507mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/jNuZJUIW_l-m1VqDmDwMGRnnHUQ Cc: "netmod@ietf.org" Subject: [netmod] =?gb2312?b?tPC4tDogU29tZSBjb21tZW50cyBhYm91dCBBQ0wgWUFO?= =?gb2312?b?RyBtb2RlbC4=?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 21 Oct 2014 11:04:04 -0000 --_000_D496C972D1A13540A730720631EC73413A41B06Ankgeml507mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksDQogMi4gICAgICBJbiBwYWNrZXQtZmllbGRzIG1vZHVsZSwgSXQgbG9va3MgdGhlIGN1cnJl bnQgZGVmaW5pdGlvbiBpcyBub3Qgc28gc3VmZmljaWVudC4gRm9yIGV4YW1wbGUsIG5vICIhPSIg ZGVmaW5pdGlvbiwgYW5kIG5vIG1hc2sgaW4gYWNsLWlwdjQtaGVhZGVyLWZpZWxkcyBncm91cCwg ZXRjoa0uLg0KDQpETEI6ICBubyChsG5vdKGxIGRlZmluaXRpb24uICAgVGhpcyBpcyBhIGdvb2Qg Y2F0Y2guICBGZWVsIGZyZWUgdG8gcHJvcG9zZSBhbiBhdWdtZW50YXRpb24gb3IgY2hhbmdlIHRv IHRoZSBleGlzdGluZyBtb2RlbC4NCg0KWWFuZ2FuZzogT0ssIEkgd2lsbCBkbyBpdCwgSSB0cnkg dG8gcHJvdmlkZSBkYXRhIGFzIHNvb24gYXMgcG9zc2libGUuDQoNCjMuICAgICAgSW4gdGhpcyBk cmFmdCwgdGhlcmUgaXMgYWNsLXR5cGUgYW5kIGFjZS10eXBlLiBJdCBsb29rcyB0aGUgSVAgcGFj a2V0IG1hdGNoIGFuZCBFdGhlcm5ldCBwYWNrZXQgbWF0Y2ggY2FuIGJlIGNvbmZpZ3VyZWQgdG9n ZXRoZXIuIEJ1dCBpdCBsb29rcyBvbmx5ICJPUiIgcmVsYXRpb25zaGlwIGlzIGF0IHRoZXJlLCBu byAiQU5EIiByZWxhdGlvbnNoaXAuDQoNCkRMQjogICAgIFdoYXQga2luZCBvZiChsEFORKGxIHJl bGF0aW9uc2hpcCBhcmUgeW91IGV4cGVjdGluZyA/DQpZYW5nYW5nOiBJIHJlbWVtYmVyIHdlIGdv dCBvbmUgcmVxdWlyZW1lbnQgZnJvbSB0aGUgZW5kIHVzZXI6IFRoZXkgd2FudCB0aGUgQUNMIHRv IGNoZWNrIHRoZSBMMiBNQUMgYWRkcmVzcyBhbmQgTDMgSVAgYWRkcmVzcyB0b2dldGhlci4gQXQg dGhpcyB0aW1lLCB0aGUgcmVsYXRpb25zaGlwIG9mIFJVTEVzIGlzIKGwQU5EobEsIG5vdCChsE9S obEuDQoNCg0KVGhhbmtzDQpZYW5nYW5nLg0KDQq3orz+yMs6IERhbmEgQmxhaXIgKGRibGFpcikg W21haWx0bzpkYmxhaXJAY2lzY28uY29tXQ0Kt6LLzcqxvOQ6IDIwMTTE6jEw1MIyMMjVIDIxOjA5 DQrK1bz+yMs6IFlhbmdhbmcNCrOty806IERhbmEgQmxhaXIgKGRibGFpcik7IExpc2EgSHVhbmcg KHlpaHVhbik7IERlYW4gQm9nZGFub3ZpYzsgS2lyYW4gQWdyYWhhcmEgU3JlZW5pdmFzYTsgQmVu b2l0IENsYWlzZSAoYmNsYWlzZSk7IG5ldG1vZEBpZXRmLm9yZw0K1vfM4jogUkU6IFNvbWUgY29t bWVudHMgYWJvdXQgQUNMIFlBTkcgbW9kZWwuDQoNClRoZSBkcmFmdCBhdXRob3JzIG1ldCBhbmQg aGVyZSBpcyB0aGUgcmVzcG9uc2UuICBMb29rIGZvciBETEI6DQpUaGUgY29tbWVudHMgbWVudGlv biBjb21waWxhYmxlIG9wdGlvbiB3aGljaCBtZWFucyB0aGUgcHJvcG9zYWwgY29tcGlsZXMgd2l0 aCBweWFuZyAtLWlldGYgb3B0aW9uLg0KDQpIaSwNCg0KSSBhbSByZXZpZXdpbmcgdGhlIEFDTCBZ QU5HIG1vZGVsLiBBbmQgSSBnb3Qgc29tZSBkb3VidHMsIG1heWJlIHNvbWVib2R5IGNhbiBoZWxw IG1lIHRvIHVuZGVyc3RhbmQgaXQuDQoNCg0KMS4gICAgICBUaGVyZSBpcyBvbmUgZmllbGQ6IHRh cmdldHMuIEluIG15IHVuZGVyc3RhbmRpbmcsIG1heWJlIGl0IGlzIHVzZWQgdG8gcmVjb3JkIHdo byByZWZlcmVuY2UgdGhpcyBBQ0wuIEkgZG9uoa90IGtub3cgaWYgSXMgaXQgbWFuZGF0b3J5IG9y IG5vdC4gT3IgbXkgdW5kZXJzdGFuZGluZyBpcyB3cm9uZy4NCg0KRExCOiAgWW91ciB1bmRlcnN0 YW5kIGlzIGNvcnJlY3QuICBJdKGvcyBub3QgbWFuZGF0b3J5LiAgIFRvIG1vdmUgYmV5b25kIGp1 c3QgdXNpbmcgc3RyaW5nLCB3ZSBuZWVkIGEgY29tcGlsYWJsZSBhdWdtZW50YXRpb24uICBTaW5j ZSBBQ0xzIGNhbiBiZQ0KYXBwbGllZCB0byBpbnRlcmZhY2VzLCB0aGF0IG1pZ2h0IGJlIGEgZ29v ZCBwbGFjZSB0byBzdGFydC4NCg0KDQoyLiAgICAgIEluIHBhY2tldC1maWVsZHMgbW9kdWxlLCBJ dCBsb29rcyB0aGUgY3VycmVudCBkZWZpbml0aW9uIGlzIG5vdCBzbyBzdWZmaWNpZW50LiBGb3Ig ZXhhbXBsZSwgbm8gIiE9IiBkZWZpbml0aW9uLCBhbmQgbm8gbWFzayBpbiBhY2wtaXB2NC1oZWFk ZXItZmllbGRzIGdyb3VwLCBldGOhrS4uDQoNCkRMQjogIG5vIKGwbm90obEgZGVmaW5pdGlvbi4g ICBUaGlzIGlzIGEgZ29vZCBjYXRjaC4gIEZlZWwgZnJlZSB0byBwcm9wb3NlIGFuIGF1Z21lbnRh dGlvbiBvciBjaGFuZ2UgdG8gdGhlIGV4aXN0aW5nIG1vZGVsLg0KDQoNCg0KMy4gICAgICBJbiB0 aGlzIGRyYWZ0LCB0aGVyZSBpcyBhY2wtdHlwZSBhbmQgYWNlLXR5cGUuIEl0IGxvb2tzIHRoZSBJ UCBwYWNrZXQgbWF0Y2ggYW5kIEV0aGVybmV0IHBhY2tldCBtYXRjaCBjYW4gYmUgY29uZmlndXJl ZCB0b2dldGhlci4gQnV0IGl0IGxvb2tzIG9ubHkgIk9SIiByZWxhdGlvbnNoaXAgaXMgYXQgdGhl cmUsIG5vICJBTkQiIHJlbGF0aW9uc2hpcC4NCg0KRExCOiAgICAgV2hhdCBraW5kIG9mIKGwQU5E obEgcmVsYXRpb25zaGlwIGFyZSB5b3UgZXhwZWN0aW5nID8NCg0KDQoNCnRoYW5rcywNCg0KRGFu YSBCbGFpcg0KDQoNCg0KDQoNClRoYW5rcw0KWWFuZ2FuZw0K --_000_D496C972D1A13540A730720631EC73413A41B06Ankgeml507mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi,

 2.      In packet-fields module, It looks the current= definition is not so sufficient. For example, no "!=3D" definiti= on, and no mask in acl-ipv4-header-fields group, etc=A1=AD..

DLB:  no =A1=B0not=A1=B1 definition.  = This is a good catch.  Feel free to propose an augmentation or change= to the existing model.

Yangang: OK, I will do it, I tr= y to provide data as soon as possible.

= 3.      In this draft, there is acl-type and ace-type= . It looks the IP packet match and Ethernet packet match can be configured = together. But it looks only "OR" relationship is at there, no "AND" relationship.

= DLB:     What kind of =A1=B0AND=A1=B1 rela= tionship are you expecting ?=

Yangang: I remember we g= ot one requirement from the end user: They want the ACL to check the L2 MAC= address and L3 IP address together. At this time, the relationship of RULEs is =A1=B0AND=A1=B1, not =A1=B0OR=A1=B1.

 = ;

 = ;

Thanks=

Yangang.

 = ;

=B7=A2=BC=FE=C8=CB: Dana Bl= air (dblair) [mailto:dblair@cisco.com]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA10=D4=C220=C8=D5 21:09
=CA=D5=BC=FE=C8=CB: Yangang
=B3=AD=CB=CD: Dana Blair (dblair); Lisa Huang (yihuan); Dean Bogdanovic; Kiran Agrahara= Sreenivasa; Benoit Claise (bclaise); netmod@ietf.org
=D6=F7=CC=E2: RE: Some comments about ACL YANG model.

 

The draft authors met a= nd here is the response.  Look for DLB:

The comments mention co= mpilable option which means the proposal compiles with pyang --ietf option.=

 

Hi,

 

I am reviewing the ACL = YANG model. And I got some doubts, maybe somebody can help me to understand= it.

 

1.      There is one field: targets. In my understand= ing, maybe it is used to record who reference this ACL. I don=A1=AFt know i= f Is it mandatory or not. Or my understanding is wrong.

 

DLB:  Your underst= and is correct.  It=A1=AFs not mandatory.   To move beyond just u= sing string, we need a compilable augmentation.  Since ACLs can be

applied to interfaces, = that might be a good place to start.    

 

2.      In packet-fields module, It looks the current= definition is not so sufficient. For example, no "!=3D" definiti= on, and no mask in acl-ipv4-header-fields group, etc=A1=AD..

DLB:  no =A1=B0not=A1=B1 definition.  = This is a good catch.  Feel free to propose an augmentation or change= to the existing model.

 

= 3.      In this draft, there is acl-type and ace-type= . It looks the IP packet match and Ethernet packet match can be configured = together. But it looks only "OR" relationship is at there, no "AND" relationship.

= DLB:     What kind of =A1=B0AND=A1=B1 rela= tionship are you expecting ?=

=  

= thanks,= Dana Blair

=  

=  

 

Thanks

Yangang

--_000_D496C972D1A13540A730720631EC73413A41B06Ankgeml507mbschi_-- From nobody Tue Oct 21 04:07:08 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357931A03A8 for ; Tue, 21 Oct 2014 04:07: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 H3n3G34yyDJD for ; Tue, 21 Oct 2014 04:06:57 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF9B71A19E7 for ; Tue, 21 Oct 2014 04:06:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id AF5AE54074A; Tue, 21 Oct 2014 13:06:31 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JE32qiOHwS8e; Tue, 21 Oct 2014 13:06:27 +0200 (CEST) Received: from localhost (unknown [195.113.220.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 9CC935400EE; Tue, 21 Oct 2014 13:06:26 +0200 (CEST) From: Ladislav Lhotka To: "Thomas D. Nadeau" , "Dana Blair \(dblair\)" In-Reply-To: References: User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Tue, 21 Oct 2014 13:06:26 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/JtW-L6piDQDpv-Tu0dnlfiTL4Vs Cc: NETMOD Working Group Subject: Re: [netmod] NETMOD WG Poll to Adopt ACL Yang Model draft-wildes-netmod-syslog-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: Tue, 21 Oct 2014 11:07:03 -0000 Hi, I support adopting both drafts as WG documents. Lada =20=20 "Thomas D. Nadeau" writes: > True. We are asking for both so please respond for both drafts. > > --Tom > > >> Tom, >>=20 >> The subject lines seems to be mixing ACL and Syslog. >>=20 >> Should it read =C2=B3NETMOD WG Poll to Adopt Syslog Yang Model >> draft-wildes-netmod-syslog-model-03 =C2=B3 ? >>=20 >> thanks, >> Dana >>=20 >>=20 >>=20 >> On 10/20/14, 1:28 PM, "Thomas D. Nadeau" wrote: >>=20 >>>=20 >>> Since I have not heard anything during the poll either pro or against >>> this, I wanted to extent this call until Friday of this week. >>>=20 >>> --Tom >>>=20 >>>=20 >>>=20 >>>=20 >>> The co-authors of draft-wildes-netmod-syslog-model-03.txt have asked t= he >>> NETMOD chairs to post a call to adopt the draft as a WG document. >>>=20 >>> The draft can be found here: >>>=20 >>> http://tools.ietf.org/html/draft-wildes-netmod-syslog-model-03 >>>=20 >>> The model itself has been extracted and can be directly accessed here >>> using git: >>>=20 >>> https://github.com/YangModels/yang/tree/master/experimental/ietf/SYSLO= G-M >>> ODEL >>>=20 >>> Please comment by the close of business on Monday, October 13, 2014. >>>=20 >>>=20 >>> --Tom (As NETMOD co-chair) >>>=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 --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Oct 21 05:25:19 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 977551A1B39 for ; Tue, 21 Oct 2014 05:25: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 mMvieEs3yEbS for ; Tue, 21 Oct 2014 05:25:13 -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 8927B1A1B38 for ; Tue, 21 Oct 2014 05:25:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1696; q=dns/txt; s=iport; t=1413894313; x=1415103913; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=bMQL6h4v6l4fg5y/p+vuCHtYjUB65RPCRvUAvnZylVI=; b=OmbF6VlWY3eYyYcdBQ9T0uH1XrDNTGQGUpEHbDVZ1pknEwMbpLDr8bxp RCAw/NuC/E/ePIHd3W7k+40R7HqHewMwt/9OQKz532joPovy6iyKEfNoG LofusjvA39CLiLb2ZdQo9bqUrPyyJHkOhw78YxHsaX7cTcjUYCZMD/QYW M=; X-IronPort-AV: E=Sophos;i="5.04,762,1406592000"; d="scan'208";a="365286775" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-2.cisco.com with ESMTP; 21 Oct 2014 12:25:13 +0000 Received: from [10.21.89.15] (sjc-vpn5-271.cisco.com [10.21.89.15]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s9LCPCka016857; Tue, 21 Oct 2014 12:25:12 GMT Message-ID: <544650A8.5020404@cisco.com> Date: Tue, 21 Oct 2014 05:25:12 -0700 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Ladislav Lhotka , "Thomas D. Nadeau" , "Dana Blair (dblair)" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/hnFniIwuUDjrlrhnEJivlB8kTk4 Cc: NETMOD Working Group Subject: Re: [netmod] NETMOD WG Poll to Adopt ACL Yang Model draft-wildes-netmod-syslog-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: Tue, 21 Oct 2014 12:25:15 -0000 > Hi, > > I support adopting both drafts as WG documents. +1. Regards, Benoit (as an individual) > > Lada > > "Thomas D. Nadeau" writes: > >> True. We are asking for both so please respond for both drafts. >> >> --Tom >> >> >>> Tom, >>> >>> The subject lines seems to be mixing ACL and Syslog. >>> >>> Should it read ³NETMOD WG Poll to Adopt Syslog Yang Model >>> draft-wildes-netmod-syslog-model-03 ³ ? >>> >>> thanks, >>> Dana >>> >>> >>> >>> On 10/20/14, 1:28 PM, "Thomas D. Nadeau" wrote: >>> >>>> Since I have not heard anything during the poll either pro or against >>>> this, I wanted to extent this call until Friday of this week. >>>> >>>> --Tom >>>> >>>> >>>> >>>> >>>> The co-authors of draft-wildes-netmod-syslog-model-03.txt have asked the >>>> NETMOD chairs to post a call to adopt the draft as a WG document. >>>> >>>> The draft can be found here: >>>> >>>> http://tools.ietf.org/html/draft-wildes-netmod-syslog-model-03 >>>> >>>> The model itself has been extracted and can be directly accessed here >>>> using git: >>>> >>>> https://github.com/YangModels/yang/tree/master/experimental/ietf/SYSLOG-M >>>> ODEL >>>> >>>> Please comment by the close of business on Monday, October 13, 2014. >>>> >>>> >>>> --Tom (As NETMOD 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 Tue Oct 21 07:03:27 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7CD1A6F04 for ; Tue, 21 Oct 2014 07:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.56 X-Spam-Level: X-Spam-Status: No, score=-8.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, 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 gQ42QjMBB1Tq for ; Tue, 21 Oct 2014 07:03:02 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 033271A6D3F for ; Tue, 21 Oct 2014 07:03:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23706; q=dns/txt; s=iport; t=1413900183; x=1415109783; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=/oyCiIK2kICsjow3h+EkmMxwX/exF6bq1O+XF/QmmsE=; b=bCjTt4rbdSQUx4LZoQO6guiWDnXGiupO2IeUAxDBmZKMGYZ/mSFglmXQ Pa1w/PnNd7J7TrE//yPZ3yS9i2rdPMph0g7loT7MnTK1twydDqBjGBR9d lTZE+LFnXuox5r5M4Pum9xl4QdsiJXb0GUrRsulxb0kBcQ9AosaZA3J14 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAMRIRlStJV2P/2dsb2JhbABcgkhGU1gEgwLQZAIbcxYBfYQCAQIELUUHEgEGAhEDAQIhBwUEMBQGAwgCBA4FiD+RYpxJCJRpAQEBAQEBAQEBAQEBAQEBAQEBAQEBF5A2ChEGAYJzgVgFj2WCHItZgTCQcYQBg3dsgUiBAwEBAQ X-IronPort-AV: E=Sophos;i="5.04,762,1406592000"; d="scan'208,217";a="361989026" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-9.cisco.com with ESMTP; 21 Oct 2014 14:03:02 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s9LE318G017173 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Oct 2014 14:03:01 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.151]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Tue, 21 Oct 2014 09:03:00 -0500 From: "Dana Blair (dblair)" To: Yangang Thread-Topic: =?gb2312?B?tPC4tDogU29tZSBjb21tZW50cyBhYm91dCBBQ0wgWUFORyBtb2RlbC4=?= Thread-Index: AQHP7GcJNvv6hgwmVkSOGKo7BQmMmZw6YA8QgABHUIA= Date: Tue, 21 Oct 2014 14:03:00 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.21.90.96] Content-Type: multipart/alternative; boundary="_000_D06BDEDE21A008dblairciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/DNt9Y-i3sv3AGBZIPJQNyrWH4DE Cc: "netmod@ietf.org" Subject: Re: [netmod] =?gb2312?b?tPC4tDogU29tZSBjb21tZW50cyBhYm91dCBBQ0wgWUFO?= =?gb2312?b?RyBtb2RlbC4=?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 21 Oct 2014 14:03:17 -0000 --_000_D06BDEDE21A008dblairciscocom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RnJvbTogWWFuZ2FuZyA8eWFuZ2FuZ0BodWF3ZWkuY29tPG1haWx0bzp5YW5nYW5nQGh1YXdlaS5j b20+Pg0KRGF0ZTogVHVlc2RheSwgT2N0b2JlciAyMSwgMjAxNCBhdCA3OjAzIEFNDQpUbzogQ2lz Y28gRW1wbG95ZWUgPGRibGFpckBjaXNjby5jb208bWFpbHRvOmRibGFpckBjaXNjby5jb20+Pg0K Q2M6ICJMaXNhIEh1YW5nICh5aWh1YW4pIiA8eWlodWFuQGNpc2NvLmNvbTxtYWlsdG86eWlodWFu QGNpc2NvLmNvbT4+LCBEZWFuIEJvZ2Rhbm92aWMgPGRlYW5iQGp1bmlwZXIubmV0PG1haWx0bzpk ZWFuYkBqdW5pcGVyLm5ldD4+LCBLaXJhbiBBZ3JhaGFyYSBTcmVlbml2YXNhIDxra291c2hpa0BC cm9jYWRlLmNvbTxtYWlsdG86a2tvdXNoaWtAQnJvY2FkZS5jb20+PiwgIkJlbm9pdCBDbGFpc2Ug KGJjbGFpc2UpIiA8YmNsYWlzZUBjaXNjby5jb208bWFpbHRvOmJjbGFpc2VAY2lzY28uY29tPj4s ICJuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4iIDxuZXRtb2RAaWV0Zi5v cmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4+DQpTdWJqZWN0OiC08Li0OiBTb21lIGNvbW1lbnRz IGFib3V0IEFDTCBZQU5HIG1vZGVsLg0KDQpIaSwNCiAyLiAgICAgIEluIHBhY2tldC1maWVsZHMg bW9kdWxlLCBJdCBsb29rcyB0aGUgY3VycmVudCBkZWZpbml0aW9uIGlzIG5vdCBzbyBzdWZmaWNp ZW50LiBGb3IgZXhhbXBsZSwgbm8gIiE9IiBkZWZpbml0aW9uLCBhbmQgbm8gbWFzayBpbiBhY2wt aXB2NC1oZWFkZXItZmllbGRzIGdyb3VwLCBldGOhrS4uDQoNCkRMQjogIG5vIKGwbm90obEgZGVm aW5pdGlvbi4gICBUaGlzIGlzIGEgZ29vZCBjYXRjaC4gIEZlZWwgZnJlZSB0byBwcm9wb3NlIGFu IGF1Z21lbnRhdGlvbiBvciBjaGFuZ2UgdG8gdGhlIGV4aXN0aW5nIG1vZGVsLg0KDQpZYW5nYW5n OiBPSywgSSB3aWxsIGRvIGl0LCBJIHRyeSB0byBwcm92aWRlIGRhdGEgYXMgc29vbiBhcyBwb3Nz aWJsZS4NCg0KR3JlYXQuDQoNCg0KMy4gICAgICBJbiB0aGlzIGRyYWZ0LCB0aGVyZSBpcyBhY2wt dHlwZSBhbmQgYWNlLXR5cGUuIEl0IGxvb2tzIHRoZSBJUCBwYWNrZXQgbWF0Y2ggYW5kIEV0aGVy bmV0IHBhY2tldCBtYXRjaCBjYW4gYmUgY29uZmlndXJlZCB0b2dldGhlci4gQnV0IGl0IGxvb2tz IG9ubHkgIk9SIiByZWxhdGlvbnNoaXAgaXMgYXQgdGhlcmUsIG5vICJBTkQiIHJlbGF0aW9uc2hp cC4NCg0KRExCOiAgICAgV2hhdCBraW5kIG9mIKGwQU5EobEgcmVsYXRpb25zaGlwIGFyZSB5b3Ug ZXhwZWN0aW5nID8NCllhbmdhbmc6IEkgcmVtZW1iZXIgd2UgZ290IG9uZSByZXF1aXJlbWVudCBm cm9tIHRoZSBlbmQgdXNlcjogVGhleSB3YW50IHRoZSBBQ0wgdG8gY2hlY2sgdGhlIEwyIE1BQyBh ZGRyZXNzIGFuZCBMMyBJUCBhZGRyZXNzIHRvZ2V0aGVyLiBBdCB0aGlzIHRpbWUsIHRoZSByZWxh dGlvbnNoaXAgb2YgUlVMRXMgaXMgobBBTkShsSwgbm90IKGwT1KhsS4NCg0KU28gZG8gdGhleSB3 YW50IHRvIGRvIHRoaXM6DQptYXRjaCAoKElQIGFkZHJlc3MgPT0gMS4xLjEuMSkgQU5EIChNQUMg YWRkcmVzcyA9PSAweEFCQ0RFRikpIHBlcm1pdA0KDQpvciB0aGlzOg0KDQptYXRjaCAoKElQIGFk ZHJlc3MgPT0gMS4xLjEuMSkgT1IgKE1BQyBhZGRyZXNzID09IDB4QUJDREVGKSkgcGVybWl0DQoN Cm9yIHNvbWV0aGluZyBlbHNlID8NCg0KdGhhbmtzLA0KRGFuYQ0KDQoNCg0KDQpUaGFua3MNCllh bmdhbmcuDQoNCreivP7IyzogRGFuYSBCbGFpciAoZGJsYWlyKSBbbWFpbHRvOmRibGFpckBjaXNj by5jb21dDQq3osvNyrG85DogMjAxNMTqMTDUwjIwyNUgMjE6MDkNCsrVvP7IyzogWWFuZ2FuZw0K s63LzTogRGFuYSBCbGFpciAoZGJsYWlyKTsgTGlzYSBIdWFuZyAoeWlodWFuKTsgRGVhbiBCb2dk YW5vdmljOyBLaXJhbiBBZ3JhaGFyYSBTcmVlbml2YXNhOyBCZW5vaXQgQ2xhaXNlIChiY2xhaXNl KTsgbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQrW98ziOiBSRTogU29t ZSBjb21tZW50cyBhYm91dCBBQ0wgWUFORyBtb2RlbC4NCg0KVGhlIGRyYWZ0IGF1dGhvcnMgbWV0 IGFuZCBoZXJlIGlzIHRoZSByZXNwb25zZS4gIExvb2sgZm9yIERMQjoNClRoZSBjb21tZW50cyBt ZW50aW9uIGNvbXBpbGFibGUgb3B0aW9uIHdoaWNoIG1lYW5zIHRoZSBwcm9wb3NhbCBjb21waWxl cyB3aXRoIHB5YW5nIC0taWV0ZiBvcHRpb24uDQoNCkhpLA0KDQpJIGFtIHJldmlld2luZyB0aGUg QUNMIFlBTkcgbW9kZWwuIEFuZCBJIGdvdCBzb21lIGRvdWJ0cywgbWF5YmUgc29tZWJvZHkgY2Fu IGhlbHAgbWUgdG8gdW5kZXJzdGFuZCBpdC4NCg0KDQoxLiAgICAgIFRoZXJlIGlzIG9uZSBmaWVs ZDogdGFyZ2V0cy4gSW4gbXkgdW5kZXJzdGFuZGluZywgbWF5YmUgaXQgaXMgdXNlZCB0byByZWNv cmQgd2hvIHJlZmVyZW5jZSB0aGlzIEFDTC4gSSBkb26hr3Qga25vdyBpZiBJcyBpdCBtYW5kYXRv cnkgb3Igbm90LiBPciBteSB1bmRlcnN0YW5kaW5nIGlzIHdyb25nLg0KDQpETEI6ICBZb3VyIHVu ZGVyc3RhbmQgaXMgY29ycmVjdC4gIEl0oa9zIG5vdCBtYW5kYXRvcnkuICAgVG8gbW92ZSBiZXlv bmQganVzdCB1c2luZyBzdHJpbmcsIHdlIG5lZWQgYSBjb21waWxhYmxlIGF1Z21lbnRhdGlvbi4g IFNpbmNlIEFDTHMgY2FuIGJlDQphcHBsaWVkIHRvIGludGVyZmFjZXMsIHRoYXQgbWlnaHQgYmUg YSBnb29kIHBsYWNlIHRvIHN0YXJ0Lg0KDQoNCjIuICAgICAgSW4gcGFja2V0LWZpZWxkcyBtb2R1 bGUsIEl0IGxvb2tzIHRoZSBjdXJyZW50IGRlZmluaXRpb24gaXMgbm90IHNvIHN1ZmZpY2llbnQu IEZvciBleGFtcGxlLCBubyAiIT0iIGRlZmluaXRpb24sIGFuZCBubyBtYXNrIGluIGFjbC1pcHY0 LWhlYWRlci1maWVsZHMgZ3JvdXAsIGV0Y6GtLi4NCg0KRExCOiAgbm8gobBub3ShsSBkZWZpbml0 aW9uLiAgIFRoaXMgaXMgYSBnb29kIGNhdGNoLiAgRmVlbCBmcmVlIHRvIHByb3Bvc2UgYW4gYXVn bWVudGF0aW9uIG9yIGNoYW5nZSB0byB0aGUgZXhpc3RpbmcgbW9kZWwuDQoNCg0KDQozLiAgICAg IEluIHRoaXMgZHJhZnQsIHRoZXJlIGlzIGFjbC10eXBlIGFuZCBhY2UtdHlwZS4gSXQgbG9va3Mg dGhlIElQIHBhY2tldCBtYXRjaCBhbmQgRXRoZXJuZXQgcGFja2V0IG1hdGNoIGNhbiBiZSBjb25m aWd1cmVkIHRvZ2V0aGVyLiBCdXQgaXQgbG9va3Mgb25seSAiT1IiIHJlbGF0aW9uc2hpcCBpcyBh dCB0aGVyZSwgbm8gIkFORCIgcmVsYXRpb25zaGlwLg0KDQpETEI6ICAgICBXaGF0IGtpbmQgb2Yg obBBTkShsSByZWxhdGlvbnNoaXAgYXJlIHlvdSBleHBlY3RpbmcgPw0KDQoNCg0KdGhhbmtzLA0K DQpEYW5hIEJsYWlyDQoNCg0KDQoNCg0KVGhhbmtzDQpZYW5nYW5nDQo= --_000_D06BDEDE21A008dblairciscocom_ Content-Type: text/html; charset="gb2312" Content-ID: <865B983F25CD154ABD959BDE6DFF9C5E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
From: Yangang <<= /span>yangang@huawei.com>
Date: Tuesday, October 21, 2014 at = 7:03 AM
To: Cisco Employee <dblair@cisco.com>
Cc: "Lisa Huang (yihuan)"= <yihuan@cisco.com>, Dean Bog= danovic <deanb@juniper.net>,= Kiran Agrahara Sreenivasa <kkou= shik@Brocade.com>, "Benoit Claise (bclaise)" <bclaise@cisco.com>, "netm= od@ietf.org" <netmod@ietf.or= g>
Subject: =B4=F0=B8=B4: Some comment= s about ACL YANG model.

Hi,

 2.  &= nbsp;   In packet-fields module, It looks the current definition is not = so sufficient. For example, no "!=3D" definition, and no mask in = acl-ipv4-header-fields group, etc=A1=AD..

DLB:  no =A1=B0not=A1=B1 definition.   This is a good cat= ch.  Feel free to propose an augmentation or change to the existing model.

Yangang: OK, I will do it, I try to provide data= as soon as possible.

Great.

= 3.&nb= sp;     In this draft, there is acl-type and ace-type. It looks the IP p= acket match and Ethernet packet match can be configured together. But it lo= oks only "OR" relationship is at there, no "AND" relationship.<= /span>

= DLB:     What kind of =A1=B0AND=A1=B1 relationship are you ex= pecting ?

Yangang: I remember we got one requirement = from the end user: They want the ACL to check the L2 MAC address and L3 IP = address together. At this time, the relationship of RULEs is =A1=B0AND=A1=B1, not =A1=B0OR=A1=B1.

So do they want to do this:
match ((IP address =3D=3D 1.1.1.1) AND (MAC address =3D=3D 0xABCDEF)) = permit

or this:

match ((IP address =3D=3D 1.1.1.1) OR (MAC address =3D=3D 0xABCDEF)) p= ermit

or something else ?

thanks,
Dana


 <= /span>

 <= /span>

Thanks

Yangang.

 <= /span>

 

The draft authors met a= nd here is the response.  Look for DLB:

The comments mention co= mpilable option which means the proposal compiles with pyang --ietf option.=

 

Hi,

 

I am reviewing the ACL = YANG model. And I got some doubts, maybe somebody can help me to understand= it.

 

1.      There is one field: targets. In my understanding, maybe it is us= ed to record who reference this ACL. I don=A1=AFt know if Is it mandatory o= r not. Or my understanding is wrong.

 

DLB:  Your underst= and is correct.  It=A1=AFs not mandatory.   To move beyond just u= sing string, we need a compilable augmentation.  Since ACLs can be

applied to interfaces, = that might be a good place to start.    

 

2.      In packet-fields module, It looks the current definition is not = so sufficient. For example, no "!=3D" definition, and no mask in = acl-ipv4-header-fields group, etc=A1=AD..

DLB:  no =A1=B0not=A1=B1 definition.   This is a good cat= ch.  Feel free to propose an augmentation or change to the existing model.

 

= 3.&nb= sp;     In this draft, there is acl-type and ace-type. It looks the IP p= acket match and Ethernet packet match can be configured together. But it lo= oks only "OR" relationship is at there, no "AND" relationship.<= /span>

= DLB:     What kind of =A1=B0AND=A1=B1 relationship are you ex= pecting ?

=  

= thanks,

= Dana Blair

=  

=  

 

Thanks

Yangang

 --_000_D06BDEDE21A008dblairciscocom_-- From nobody Tue Oct 21 08:37:11 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD5271A883E for ; Tue, 21 Oct 2014 08:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.74 X-Spam-Level: * X-Spam-Status: No, score=1.74 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 zXlpLARr4CSR for ; Tue, 21 Oct 2014 08:37:06 -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 3A1121A87CE for ; Tue, 21 Oct 2014 08:37:05 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKU14607; Tue, 21 Oct 2014 15:37:03 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 21 Oct 2014 16:37:02 +0100 Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.104]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Tue, 21 Oct 2014 23:36:58 +0800 From: Yangang To: "Dana Blair (dblair)" Thread-Topic: =?gb2312?B?tPC4tDogU29tZSBjb21tZW50cyBhYm91dCBBQ0wgWUFORyBtb2RlbC4=?= Thread-Index: AQHP7GcJNvv6hgwmVkSOGKo7BQmMmZw6YA8QgABHUICAAAjl7A== Date: Tue, 21 Oct 2014 15:36:57 +0000 Message-ID: References: , In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.46.118.13] Content-Type: multipart/alternative; boundary="_000_D496C972D1A13540A730720631EC73413A41B09Cnkgeml507mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/411DUI02rdRp5wpZ4OP9ZqjIZ1g Cc: "netmod@ietf.org" Subject: [netmod] =?gb2312?b?tPC4tDogtPC4tDogU29tZSBjb21tZW50cyBhYm91dCBB?= =?gb2312?b?Q0wgWUFORyBtb2RlbC4=?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 21 Oct 2014 15:37:09 -0000 --_000_D496C972D1A13540A730720631EC73413A41B09Cnkgeml507mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 QWJvdXQgdGhlIE5PLjMsIGl0IGlzIGp1c3QgbGlrZSB5b3Ugc2FpZC4NCg0KDQoNCllhbmdhbmcu DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kt6K8/sjLOiBEYW5hIEJs YWlyIChkYmxhaXIpIFtkYmxhaXJAY2lzY28uY29tXQ0Kt6LLzcqxvOQ6IDIwMTTE6jEw1MIyMcjV IDIyOjAzDQrK1bz+yMs6IFlhbmdhbmcNCrOty806IExpc2EgSHVhbmcgKHlpaHVhbik7IERlYW4g Qm9nZGFub3ZpYzsgS2lyYW4gQWdyYWhhcmEgU3JlZW5pdmFzYTsgQmVub2l0IENsYWlzZSAoYmNs YWlzZSk7IG5ldG1vZEBpZXRmLm9yZw0K1vfM4jogUmU6ILTwuLQ6IFNvbWUgY29tbWVudHMgYWJv dXQgQUNMIFlBTkcgbW9kZWwuDQoNCkZyb206IFlhbmdhbmcgPHlhbmdhbmdAaHVhd2VpLmNvbTxt YWlsdG86eWFuZ2FuZ0BodWF3ZWkuY29tPj4NCkRhdGU6IFR1ZXNkYXksIE9jdG9iZXIgMjEsIDIw MTQgYXQgNzowMyBBTQ0KVG86IENpc2NvIEVtcGxveWVlIDxkYmxhaXJAY2lzY28uY29tPG1haWx0 bzpkYmxhaXJAY2lzY28uY29tPj4NCkNjOiAiTGlzYSBIdWFuZyAoeWlodWFuKSIgPHlpaHVhbkBj aXNjby5jb208bWFpbHRvOnlpaHVhbkBjaXNjby5jb20+PiwgRGVhbiBCb2dkYW5vdmljIDxkZWFu YkBqdW5pcGVyLm5ldDxtYWlsdG86ZGVhbmJAanVuaXBlci5uZXQ+PiwgS2lyYW4gQWdyYWhhcmEg U3JlZW5pdmFzYSA8a2tvdXNoaWtAQnJvY2FkZS5jb208bWFpbHRvOmtrb3VzaGlrQEJyb2NhZGUu Y29tPj4sICJCZW5vaXQgQ2xhaXNlIChiY2xhaXNlKSIgPGJjbGFpc2VAY2lzY28uY29tPG1haWx0 bzpiY2xhaXNlQGNpc2NvLmNvbT4+LCAibmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0 Zi5vcmc+IiA8bmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+Pg0KU3ViamVj dDogtPC4tDogU29tZSBjb21tZW50cyBhYm91dCBBQ0wgWUFORyBtb2RlbC4NCg0KSGksDQogMi4g ICAgICBJbiBwYWNrZXQtZmllbGRzIG1vZHVsZSwgSXQgbG9va3MgdGhlIGN1cnJlbnQgZGVmaW5p dGlvbiBpcyBub3Qgc28gc3VmZmljaWVudC4gRm9yIGV4YW1wbGUsIG5vICIhPSIgZGVmaW5pdGlv biwgYW5kIG5vIG1hc2sgaW4gYWNsLWlwdjQtaGVhZGVyLWZpZWxkcyBncm91cCwgZXRjoa0uLg0K DQpETEI6ICBubyChsG5vdKGxIGRlZmluaXRpb24uICAgVGhpcyBpcyBhIGdvb2QgY2F0Y2guICBG ZWVsIGZyZWUgdG8gcHJvcG9zZSBhbiBhdWdtZW50YXRpb24gb3IgY2hhbmdlIHRvIHRoZSBleGlz dGluZyBtb2RlbC4NCg0KWWFuZ2FuZzogT0ssIEkgd2lsbCBkbyBpdCwgSSB0cnkgdG8gcHJvdmlk ZSBkYXRhIGFzIHNvb24gYXMgcG9zc2libGUuDQoNCkdyZWF0Lg0KDQoNCjMuICAgICAgSW4gdGhp cyBkcmFmdCwgdGhlcmUgaXMgYWNsLXR5cGUgYW5kIGFjZS10eXBlLiBJdCBsb29rcyB0aGUgSVAg cGFja2V0IG1hdGNoIGFuZCBFdGhlcm5ldCBwYWNrZXQgbWF0Y2ggY2FuIGJlIGNvbmZpZ3VyZWQg dG9nZXRoZXIuIEJ1dCBpdCBsb29rcyBvbmx5ICJPUiIgcmVsYXRpb25zaGlwIGlzIGF0IHRoZXJl LCBubyAiQU5EIiByZWxhdGlvbnNoaXAuDQoNCkRMQjogICAgIFdoYXQga2luZCBvZiChsEFORKGx IHJlbGF0aW9uc2hpcCBhcmUgeW91IGV4cGVjdGluZyA/DQpZYW5nYW5nOiBJIHJlbWVtYmVyIHdl IGdvdCBvbmUgcmVxdWlyZW1lbnQgZnJvbSB0aGUgZW5kIHVzZXI6IFRoZXkgd2FudCB0aGUgQUNM IHRvIGNoZWNrIHRoZSBMMiBNQUMgYWRkcmVzcyBhbmQgTDMgSVAgYWRkcmVzcyB0b2dldGhlci4g QXQgdGhpcyB0aW1lLCB0aGUgcmVsYXRpb25zaGlwIG9mIFJVTEVzIGlzIKGwQU5EobEsIG5vdCCh sE9SobEuDQoNClNvIGRvIHRoZXkgd2FudCB0byBkbyB0aGlzOg0KbWF0Y2ggKChJUCBhZGRyZXNz ID09IDEuMS4xLjEpIEFORCAoTUFDIGFkZHJlc3MgPT0gMHhBQkNERUYpKSBwZXJtaXQNCg0Kb3Ig dGhpczoNCg0KbWF0Y2ggKChJUCBhZGRyZXNzID09IDEuMS4xLjEpIE9SIChNQUMgYWRkcmVzcyA9 PSAweEFCQ0RFRikpIHBlcm1pdA0KDQpvciBzb21ldGhpbmcgZWxzZSA/DQoNCnRoYW5rcywNCkRh bmENCg0KDQoNCg0KVGhhbmtzDQpZYW5nYW5nLg0KDQq3orz+yMs6IERhbmEgQmxhaXIgKGRibGFp cikgW21haWx0bzpkYmxhaXJAY2lzY28uY29tXQ0Kt6LLzcqxvOQ6IDIwMTTE6jEw1MIyMMjVIDIx OjA5DQrK1bz+yMs6IFlhbmdhbmcNCrOty806IERhbmEgQmxhaXIgKGRibGFpcik7IExpc2EgSHVh bmcgKHlpaHVhbik7IERlYW4gQm9nZGFub3ZpYzsgS2lyYW4gQWdyYWhhcmEgU3JlZW5pdmFzYTsg QmVub2l0IENsYWlzZSAoYmNsYWlzZSk7IG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGll dGYub3JnPg0K1vfM4jogUkU6IFNvbWUgY29tbWVudHMgYWJvdXQgQUNMIFlBTkcgbW9kZWwuDQoN ClRoZSBkcmFmdCBhdXRob3JzIG1ldCBhbmQgaGVyZSBpcyB0aGUgcmVzcG9uc2UuICBMb29rIGZv ciBETEI6DQpUaGUgY29tbWVudHMgbWVudGlvbiBjb21waWxhYmxlIG9wdGlvbiB3aGljaCBtZWFu cyB0aGUgcHJvcG9zYWwgY29tcGlsZXMgd2l0aCBweWFuZyAtLWlldGYgb3B0aW9uLg0KDQpIaSwN Cg0KSSBhbSByZXZpZXdpbmcgdGhlIEFDTCBZQU5HIG1vZGVsLiBBbmQgSSBnb3Qgc29tZSBkb3Vi dHMsIG1heWJlIHNvbWVib2R5IGNhbiBoZWxwIG1lIHRvIHVuZGVyc3RhbmQgaXQuDQoNCg0KMS4g ICAgICBUaGVyZSBpcyBvbmUgZmllbGQ6IHRhcmdldHMuIEluIG15IHVuZGVyc3RhbmRpbmcsIG1h eWJlIGl0IGlzIHVzZWQgdG8gcmVjb3JkIHdobyByZWZlcmVuY2UgdGhpcyBBQ0wuIEkgZG9uoa90 IGtub3cgaWYgSXMgaXQgbWFuZGF0b3J5IG9yIG5vdC4gT3IgbXkgdW5kZXJzdGFuZGluZyBpcyB3 cm9uZy4NCg0KRExCOiAgWW91ciB1bmRlcnN0YW5kIGlzIGNvcnJlY3QuICBJdKGvcyBub3QgbWFu ZGF0b3J5LiAgIFRvIG1vdmUgYmV5b25kIGp1c3QgdXNpbmcgc3RyaW5nLCB3ZSBuZWVkIGEgY29t cGlsYWJsZSBhdWdtZW50YXRpb24uICBTaW5jZSBBQ0xzIGNhbiBiZQ0KYXBwbGllZCB0byBpbnRl cmZhY2VzLCB0aGF0IG1pZ2h0IGJlIGEgZ29vZCBwbGFjZSB0byBzdGFydC4NCg0KDQoyLiAgICAg IEluIHBhY2tldC1maWVsZHMgbW9kdWxlLCBJdCBsb29rcyB0aGUgY3VycmVudCBkZWZpbml0aW9u IGlzIG5vdCBzbyBzdWZmaWNpZW50LiBGb3IgZXhhbXBsZSwgbm8gIiE9IiBkZWZpbml0aW9uLCBh bmQgbm8gbWFzayBpbiBhY2wtaXB2NC1oZWFkZXItZmllbGRzIGdyb3VwLCBldGOhrS4uDQoNCkRM QjogIG5vIKGwbm90obEgZGVmaW5pdGlvbi4gICBUaGlzIGlzIGEgZ29vZCBjYXRjaC4gIEZlZWwg ZnJlZSB0byBwcm9wb3NlIGFuIGF1Z21lbnRhdGlvbiBvciBjaGFuZ2UgdG8gdGhlIGV4aXN0aW5n IG1vZGVsLg0KDQoNCg0KMy4gICAgICBJbiB0aGlzIGRyYWZ0LCB0aGVyZSBpcyBhY2wtdHlwZSBh bmQgYWNlLXR5cGUuIEl0IGxvb2tzIHRoZSBJUCBwYWNrZXQgbWF0Y2ggYW5kIEV0aGVybmV0IHBh Y2tldCBtYXRjaCBjYW4gYmUgY29uZmlndXJlZCB0b2dldGhlci4gQnV0IGl0IGxvb2tzIG9ubHkg Ik9SIiByZWxhdGlvbnNoaXAgaXMgYXQgdGhlcmUsIG5vICJBTkQiIHJlbGF0aW9uc2hpcC4NCg0K RExCOiAgICAgV2hhdCBraW5kIG9mIKGwQU5EobEgcmVsYXRpb25zaGlwIGFyZSB5b3UgZXhwZWN0 aW5nID8NCg0KDQoNCnRoYW5rcywNCg0KRGFuYSBCbGFpcg0KDQoNCg0KDQoNClRoYW5rcw0KWWFu Z2FuZw0K --_000_D496C972D1A13540A730720631EC73413A41B09Cnkgeml507mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

About the NO.3, it is just like you said.

 

Yangang.

 

=B7=A2=BC=FE=C8=CB: Dana Blair (dblair) [dbl= air@cisco.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA10=D4=C221=C8=D5 22:03
=CA=D5=BC=FE=C8=CB: Yangang
=B3=AD=CB=CD: Lisa Huang (yihuan); Dean Bogdanovic; Kiran Agrahara S= reenivasa; Benoit Claise (bclaise); netmod@ietf.org
=D6=F7=CC=E2: Re: =B4=F0=B8=B4: Some comments about ACL YANG model.<= br>
From: Yangang <yangang@huawei.com>
Date: Tuesday, October 21, 2014 at= 7:03 AM
To: Cisco Employee <dblair@cisco.com>
Cc: "Lisa Huang (yihuan)"= ; <yihuan@cisco.co= m>, Dean Bogdanovic <deanb@juniper.net>, Kiran Agrahara Sreenivasa <kkoushik@Bro= cade.com>, "Benoit Claise (bclaise)" <bclaise@cisco.com>, "netmod@ietf.org" = <netmod@ietf.org>
Subject: =B4=F0=B8=B4: Some commen= ts about ACL YANG model.

Hi,

 2.      In packet-fields module, It looks the current definition is not = so sufficient. For example, no "!=3D" definition, and no mask in = acl-ipv4-header-fields group, etc=A1=AD..

DLB:  no =A1=B0not=A1=B1 definition.   This is a good catch.=  Feel free to propose an augmentation or change to the existing model.

Yangang: OK, I will do it, I try to provide data as= soon as possible.

Great.

<= span style=3D"FONT-FAMILY: Calibri,sans-serif; COLOR: black" lang=3D"EN-US"= >3. = ;     In this draft, there is acl-type and ace-type. It looks the IP p= acket match and Ethernet packet match can be configured together. But it lo= oks only "OR" relationship is at there, no "AND" relationship.

<= span style=3D"FONT-FAMILY: Calibri,sans-serif; COLOR: black" lang=3D"EN-US"= >DLB:     What kind of =A1=B0AND=A1=B1 relationship are you expec= ting ?

Yangang: I remember we got one requirement fr= om the end user: They want the ACL to check the L2 MAC address and L3 IP ad= dress together. At this time, the relationship of RULEs is =A1=B0AND=A1=B1, not =A1=B0OR=A1=B1.

So do they want to do this:
match ((IP address =3D=3D 1.1.1.1) AND (MAC address =3D=3D 0xABCDEF)) = permit

or this:

match ((IP address =3D=3D 1.1.1.1) OR (MAC address =3D=3D 0xABCDEF)) p= ermit

or something else ?

thanks,
Dana


 

 

Thanks

Yangang.

 

=B7=A2=BC=FE=C8=CB: Dana Bl= air (dblair) [mailto:= dblair@cisco.com]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA10=D4=C220=C8=D5 21:09
=CA=D5=BC=FE=C8=CB: Yangang
=B3=AD=CB=CD: Dana Blair (dblair); Lisa Huang (yihuan); Dean Bogdanovic; Kiran Agrahara= Sreenivasa; Benoit Claise (bclaise); netmod@ietf.org =D6=F7=CC=E2: RE: Some comments about ACL YANG model.

 

The draf= t authors met and here is the response.  Look for DLB:

The comm= ents mention compilable option which means the proposal compiles with pyang= --ietf option.

&= nbsp;

Hi,

&= nbsp;

I am rev= iewing the ACL YANG model. And I got some doubts, maybe somebody can help m= e to understand it.

&= nbsp;

1.&= nbsp;     There is one field: targets. In my understanding, maybe it is us= ed to record who reference this ACL. I don=A1=AFt know if Is it mandatory o= r not. Or my understanding is wrong.

&= nbsp;

DLB: &nb= sp;Your understand is correct.  It=A1=AFs not mandatory.   To mov= e beyond just using string, we need a compilable augmentation.  Since = ACLs can be

applied = to interfaces, that might be a good place to start.    

&= nbsp;

2.&= nbsp;     In packet-fields module, It looks the current definition is not = so sufficient. For example, no "!=3D" definition, and no mask in = acl-ipv4-header-fields group, etc=A1=AD..

DLB:  no =A1=B0not=A1=B1 definition.   This is a good catch.=  Feel free to propose an augmentation or change to the existing model.

 

<= span style=3D"FONT-FAMILY: Calibri,sans-serif; COLOR: black" lang=3D"EN-US"= >3. = ;     In this draft, there is acl-type and ace-type. It looks the IP p= acket match and Ethernet packet match can be configured together. But it lo= oks only "OR" relationship is at there, no "AND" relationship.

<= span style=3D"FONT-FAMILY: Calibri,sans-serif; COLOR: black" lang=3D"EN-US"= >DLB:     What kind of =A1=B0AND=A1=B1 relationship are you expec= ting ?

<= span style=3D"FONT-FAMILY: Calibri,sans-serif; COLOR: black; FONT-SIZE: 10.= 5pt" lang=3D"EN-US"> 

<= span style=3D"FONT-FAMILY: Calibri,sans-serif; COLOR: black" lang=3D"EN-US"= >thanks,

<= span style=3D"FONT-FAMILY: Calibri,sans-serif; COLOR: black" lang=3D"EN-US"= >Dana Blair

<= span style=3D"FONT-FAMILY: Calibri,sans-serif; COLOR: black; FONT-SIZE: 10.= 5pt" lang=3D"EN-US"> 

<= span style=3D"FONT-FAMILY: Calibri,sans-serif; COLOR: black; FONT-SIZE: 10.= 5pt" lang=3D"EN-US"> 

&= nbsp;

Thanks

Yangang<= /span>

--_000_D496C972D1A13540A730720631EC73413A41B09Cnkgeml507mbschi_-- From nobody Tue Oct 21 11:16:31 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1B201A6EF2 for ; Tue, 21 Oct 2014 11:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.56 X-Spam-Level: X-Spam-Status: No, score=-8.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, 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 IetVktqS4kdY for ; Tue, 21 Oct 2014 11:16:26 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61D721A3BA7 for ; Tue, 21 Oct 2014 11:16:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26752; q=dns/txt; s=iport; t=1413915386; x=1415124986; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=pNgRxiFrpQSljsGjsNf5Xln7d6Yixqb2qsRgHRmQjVQ=; b=LFHE3Gk2k6iyTcMlhVxCJgLNlWEeQ3VTTotWyos7ub9lKTivwQkjyYCp uhc3LdVW+Y/0xLRz2mDvq6P5pxxzmzdYiQ4TXYbCSC5xTQqSk0+ivdLiX K8jhBQNXSiHQOKt04wc00rVe1ldYLFasYv+yULlvtN+WgPWnuK2hYyQPp M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFADJxRlStJV2Z/2dsb2JhbABcgkhGgSsEgwLQbwIbdhYBfYQCAQIEcgcSAQYCEQMBAiEHBQQwFAYDCAIEDgWIP5I/nEkIlGcBAQEBAQEBAQEBAQEBAQEBAQEBAQEXkDYKEQYBgnOBWAWPZYIci1mBMJBxhAGDd2yBSIEDAQEB X-IronPort-AV: E=Sophos; i="5.04,763,1406592000"; d="scan'208,217"; a="89080145" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-5.cisco.com with ESMTP; 21 Oct 2014 18:16:25 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s9LIGPW2005385 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Oct 2014 18:16:25 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.151]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Tue, 21 Oct 2014 13:16:25 -0500 From: "Dana Blair (dblair)" To: Yangang Thread-Topic: =?gb2312?B?tPC4tDogILTwuLQ6IFNvbWUgY29tbWVudHMgYWJvdXQgQUNMIFlBTkcgbW9k?= =?gb2312?Q?el.?= Thread-Index: AQHP7GcJNvv6hgwmVkSOGKo7BQmMmZw6YA8QgABHUICAAAjl7IAAPeqA Date: Tue, 21 Oct 2014 18:16:24 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.21.90.96] Content-Type: multipart/alternative; boundary="_000_D06C1AE821A584dblairciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/F_JzZ3slALbDRxx6MGtTVnSRBck Cc: "netmod@ietf.org" Subject: Re: [netmod] =?gb2312?b?tPC4tDogILTwuLQ6IFNvbWUgY29tbWVudHMgYWJvdXQg?= =?gb2312?b?QUNMIFlBTkcgbW9kZWwu?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 21 Oct 2014 18:16:29 -0000 --_000_D06C1AE821A584dblairciscocom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RnJvbTogWWFuZ2FuZyA8eWFuZ2FuZ0BodWF3ZWkuY29tPG1haWx0bzp5YW5nYW5nQGh1YXdlaS5j b20+Pg0KRGF0ZTogVHVlc2RheSwgT2N0b2JlciAyMSwgMjAxNCBhdCAxMTozNiBBTQ0KVG86IENp c2NvIEVtcGxveWVlIDxkYmxhaXJAY2lzY28uY29tPG1haWx0bzpkYmxhaXJAY2lzY28uY29tPj4N CkNjOiAiTGlzYSBIdWFuZyAoeWlodWFuKSIgPHlpaHVhbkBjaXNjby5jb208bWFpbHRvOnlpaHVh bkBjaXNjby5jb20+PiwgRGVhbiBCb2dkYW5vdmljIDxkZWFuYkBqdW5pcGVyLm5ldDxtYWlsdG86 ZGVhbmJAanVuaXBlci5uZXQ+PiwgS2lyYW4gQWdyYWhhcmEgU3JlZW5pdmFzYSA8a2tvdXNoaWtA QnJvY2FkZS5jb208bWFpbHRvOmtrb3VzaGlrQEJyb2NhZGUuY29tPj4sICJCZW5vaXQgQ2xhaXNl IChiY2xhaXNlKSIgPGJjbGFpc2VAY2lzY28uY29tPG1haWx0bzpiY2xhaXNlQGNpc2NvLmNvbT4+ LCAibmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+IiA8bmV0bW9kQGlldGYu b3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+Pg0KU3ViamVjdDogtPC4tDogtPC4tDogU29tZSBj b21tZW50cyBhYm91dCBBQ0wgWUFORyBtb2RlbC4NCg0KDQpBYm91dCB0aGUgTk8uMywgaXQgaXMg anVzdCBsaWtlIHlvdSBzYWlkLg0KDQpZb3UgY2FuIGNvbnN0cnVjdCBib3RoIHRoZSBPUiBhbmQg dGhlIEFORCBleGFtcGxlIHVzaW5nIHRoZSBleGlzdGluZyBtb2RlbC9kcmFmdC4NCg0KRGFuYQ0K DQoNCg0KDQoNCllhbmdhbmcuDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0Kt6K8/sjLOiBEYW5hIEJsYWlyIChkYmxhaXIpIFtkYmxhaXJAY2lzY28uY29tPG1haWx0bzpk YmxhaXJAY2lzY28uY29tPl0NCreiy83KsbzkOiAyMDE0xOoxMNTCMjHI1SAyMjowMw0KytW8/sjL OiBZYW5nYW5nDQqzrcvNOiBMaXNhIEh1YW5nICh5aWh1YW4pOyBEZWFuIEJvZ2Rhbm92aWM7IEtp cmFuIEFncmFoYXJhIFNyZWVuaXZhc2E7IEJlbm9pdCBDbGFpc2UgKGJjbGFpc2UpOyBuZXRtb2RA aWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCtb3zOI6IFJlOiC08Li0OiBTb21lIGNv bW1lbnRzIGFib3V0IEFDTCBZQU5HIG1vZGVsLg0KDQpGcm9tOiBZYW5nYW5nIDx5YW5nYW5nQGh1 YXdlaS5jb208bWFpbHRvOnlhbmdhbmdAaHVhd2VpLmNvbT4+DQpEYXRlOiBUdWVzZGF5LCBPY3Rv YmVyIDIxLCAyMDE0IGF0IDc6MDMgQU0NClRvOiBDaXNjbyBFbXBsb3llZSA8ZGJsYWlyQGNpc2Nv LmNvbTxtYWlsdG86ZGJsYWlyQGNpc2NvLmNvbT4+DQpDYzogIkxpc2EgSHVhbmcgKHlpaHVhbiki IDx5aWh1YW5AY2lzY28uY29tPG1haWx0bzp5aWh1YW5AY2lzY28uY29tPj4sIERlYW4gQm9nZGFu b3ZpYyA8ZGVhbmJAanVuaXBlci5uZXQ8bWFpbHRvOmRlYW5iQGp1bmlwZXIubmV0Pj4sIEtpcmFu IEFncmFoYXJhIFNyZWVuaXZhc2EgPGtrb3VzaGlrQEJyb2NhZGUuY29tPG1haWx0bzpra291c2hp a0BCcm9jYWRlLmNvbT4+LCAiQmVub2l0IENsYWlzZSAoYmNsYWlzZSkiIDxiY2xhaXNlQGNpc2Nv LmNvbTxtYWlsdG86YmNsYWlzZUBjaXNjby5jb20+PiwgIm5ldG1vZEBpZXRmLm9yZzxtYWlsdG86 bmV0bW9kQGlldGYub3JnPiIgPG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3Jn Pj4NClN1YmplY3Q6ILTwuLQ6IFNvbWUgY29tbWVudHMgYWJvdXQgQUNMIFlBTkcgbW9kZWwuDQoN CkhpLA0KIDIuICAgICAgSW4gcGFja2V0LWZpZWxkcyBtb2R1bGUsIEl0IGxvb2tzIHRoZSBjdXJy ZW50IGRlZmluaXRpb24gaXMgbm90IHNvIHN1ZmZpY2llbnQuIEZvciBleGFtcGxlLCBubyAiIT0i IGRlZmluaXRpb24sIGFuZCBubyBtYXNrIGluIGFjbC1pcHY0LWhlYWRlci1maWVsZHMgZ3JvdXAs IGV0Y6GtLi4NCg0KRExCOiAgbm8gobBub3ShsSBkZWZpbml0aW9uLiAgIFRoaXMgaXMgYSBnb29k IGNhdGNoLiAgRmVlbCBmcmVlIHRvIHByb3Bvc2UgYW4gYXVnbWVudGF0aW9uIG9yIGNoYW5nZSB0 byB0aGUgZXhpc3RpbmcgbW9kZWwuDQoNCllhbmdhbmc6IE9LLCBJIHdpbGwgZG8gaXQsIEkgdHJ5 IHRvIHByb3ZpZGUgZGF0YSBhcyBzb29uIGFzIHBvc3NpYmxlLg0KDQpHcmVhdC4NCg0KDQozLiAg ICAgIEluIHRoaXMgZHJhZnQsIHRoZXJlIGlzIGFjbC10eXBlIGFuZCBhY2UtdHlwZS4gSXQgbG9v a3MgdGhlIElQIHBhY2tldCBtYXRjaCBhbmQgRXRoZXJuZXQgcGFja2V0IG1hdGNoIGNhbiBiZSBj b25maWd1cmVkIHRvZ2V0aGVyLiBCdXQgaXQgbG9va3Mgb25seSAiT1IiIHJlbGF0aW9uc2hpcCBp cyBhdCB0aGVyZSwgbm8gIkFORCIgcmVsYXRpb25zaGlwLg0KDQpETEI6ICAgICBXaGF0IGtpbmQg b2YgobBBTkShsSByZWxhdGlvbnNoaXAgYXJlIHlvdSBleHBlY3RpbmcgPw0KWWFuZ2FuZzogSSBy ZW1lbWJlciB3ZSBnb3Qgb25lIHJlcXVpcmVtZW50IGZyb20gdGhlIGVuZCB1c2VyOiBUaGV5IHdh bnQgdGhlIEFDTCB0byBjaGVjayB0aGUgTDIgTUFDIGFkZHJlc3MgYW5kIEwzIElQIGFkZHJlc3Mg dG9nZXRoZXIuIEF0IHRoaXMgdGltZSwgdGhlIHJlbGF0aW9uc2hpcCBvZiBSVUxFcyBpcyChsEFO RKGxLCBub3QgobBPUqGxLg0KDQpTbyBkbyB0aGV5IHdhbnQgdG8gZG8gdGhpczoNCm1hdGNoICgo SVAgYWRkcmVzcyA9PSAxLjEuMS4xKSBBTkQgKE1BQyBhZGRyZXNzID09IDB4QUJDREVGKSkgcGVy bWl0DQoNCm9yIHRoaXM6DQoNCm1hdGNoICgoSVAgYWRkcmVzcyA9PSAxLjEuMS4xKSBPUiAoTUFD IGFkZHJlc3MgPT0gMHhBQkNERUYpKSBwZXJtaXQNCg0Kb3Igc29tZXRoaW5nIGVsc2UgPw0KDQp0 aGFua3MsDQpEYW5hDQoNCg0KDQoNClRoYW5rcw0KWWFuZ2FuZy4NCg0Kt6K8/sjLOiBEYW5hIEJs YWlyIChkYmxhaXIpIFttYWlsdG86ZGJsYWlyQGNpc2NvLmNvbV0NCreiy83KsbzkOiAyMDE0xOox MNTCMjDI1SAyMTowOQ0KytW8/sjLOiBZYW5nYW5nDQqzrcvNOiBEYW5hIEJsYWlyIChkYmxhaXIp OyBMaXNhIEh1YW5nICh5aWh1YW4pOyBEZWFuIEJvZ2Rhbm92aWM7IEtpcmFuIEFncmFoYXJhIFNy ZWVuaXZhc2E7IEJlbm9pdCBDbGFpc2UgKGJjbGFpc2UpOyBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRv Om5ldG1vZEBpZXRmLm9yZz4NCtb3zOI6IFJFOiBTb21lIGNvbW1lbnRzIGFib3V0IEFDTCBZQU5H IG1vZGVsLg0KDQpUaGUgZHJhZnQgYXV0aG9ycyBtZXQgYW5kIGhlcmUgaXMgdGhlIHJlc3BvbnNl LiAgTG9vayBmb3IgRExCOg0KVGhlIGNvbW1lbnRzIG1lbnRpb24gY29tcGlsYWJsZSBvcHRpb24g d2hpY2ggbWVhbnMgdGhlIHByb3Bvc2FsIGNvbXBpbGVzIHdpdGggcHlhbmcgLS1pZXRmIG9wdGlv bi4NCg0KSGksDQoNCkkgYW0gcmV2aWV3aW5nIHRoZSBBQ0wgWUFORyBtb2RlbC4gQW5kIEkgZ290 IHNvbWUgZG91YnRzLCBtYXliZSBzb21lYm9keSBjYW4gaGVscCBtZSB0byB1bmRlcnN0YW5kIGl0 Lg0KDQoNCjEuICAgICAgVGhlcmUgaXMgb25lIGZpZWxkOiB0YXJnZXRzLiBJbiBteSB1bmRlcnN0 YW5kaW5nLCBtYXliZSBpdCBpcyB1c2VkIHRvIHJlY29yZCB3aG8gcmVmZXJlbmNlIHRoaXMgQUNM LiBJIGRvbqGvdCBrbm93IGlmIElzIGl0IG1hbmRhdG9yeSBvciBub3QuIE9yIG15IHVuZGVyc3Rh bmRpbmcgaXMgd3JvbmcuDQoNCkRMQjogIFlvdXIgdW5kZXJzdGFuZCBpcyBjb3JyZWN0LiAgSXSh r3Mgbm90IG1hbmRhdG9yeS4gICBUbyBtb3ZlIGJleW9uZCBqdXN0IHVzaW5nIHN0cmluZywgd2Ug bmVlZCBhIGNvbXBpbGFibGUgYXVnbWVudGF0aW9uLiAgU2luY2UgQUNMcyBjYW4gYmUNCmFwcGxp ZWQgdG8gaW50ZXJmYWNlcywgdGhhdCBtaWdodCBiZSBhIGdvb2QgcGxhY2UgdG8gc3RhcnQuDQoN Cg0KMi4gICAgICBJbiBwYWNrZXQtZmllbGRzIG1vZHVsZSwgSXQgbG9va3MgdGhlIGN1cnJlbnQg ZGVmaW5pdGlvbiBpcyBub3Qgc28gc3VmZmljaWVudC4gRm9yIGV4YW1wbGUsIG5vICIhPSIgZGVm aW5pdGlvbiwgYW5kIG5vIG1hc2sgaW4gYWNsLWlwdjQtaGVhZGVyLWZpZWxkcyBncm91cCwgZXRj oa0uLg0KDQpETEI6ICBubyChsG5vdKGxIGRlZmluaXRpb24uICAgVGhpcyBpcyBhIGdvb2QgY2F0 Y2guICBGZWVsIGZyZWUgdG8gcHJvcG9zZSBhbiBhdWdtZW50YXRpb24gb3IgY2hhbmdlIHRvIHRo ZSBleGlzdGluZyBtb2RlbC4NCg0KDQoNCjMuICAgICAgSW4gdGhpcyBkcmFmdCwgdGhlcmUgaXMg YWNsLXR5cGUgYW5kIGFjZS10eXBlLiBJdCBsb29rcyB0aGUgSVAgcGFja2V0IG1hdGNoIGFuZCBF dGhlcm5ldCBwYWNrZXQgbWF0Y2ggY2FuIGJlIGNvbmZpZ3VyZWQgdG9nZXRoZXIuIEJ1dCBpdCBs b29rcyBvbmx5ICJPUiIgcmVsYXRpb25zaGlwIGlzIGF0IHRoZXJlLCBubyAiQU5EIiByZWxhdGlv bnNoaXAuDQoNCkRMQjogICAgIFdoYXQga2luZCBvZiChsEFORKGxIHJlbGF0aW9uc2hpcCBhcmUg eW91IGV4cGVjdGluZyA/DQoNCg0KDQp0aGFua3MsDQoNCkRhbmEgQmxhaXINCg0KDQoNCg0KDQpU aGFua3MNCllhbmdhbmcNCg== --_000_D06C1AE821A584dblairciscocom_ Content-Type: text/html; charset="gb2312" Content-ID: <5D2A5DF5B7D764459ECF3AC2D9BF84D2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
From: Yangang <<= /span>yangang@huawei.com>
Date: Tuesday, October 21, 2014 at = 11:36 AM
To: Cisco Employee <dblair@cisco.com>
Cc: "Lisa Huang (yihuan)"= <yihuan@cisco.com>, Dean Bog= danovic <deanb@juniper.net>,= Kiran Agrahara Sreenivasa <kkou= shik@Brocade.com>, "Benoit Claise (bclaise)" <bclaise@cisco.com>, "netm= od@ietf.org" <netmod@ietf.or= g>
Subject: =B4=F0=B8=B4: =B4=F0=B8=B4= : Some comments about ACL YANG model.

About the NO.3, it is just like you said.

You can construct both the OR and the AND example using the existing m= odel/draft.

Dana


 

Yangang.

 

=B7=A2=BC=FE=C8=CB: Dana Blair (dblair) [dblair@cisco.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA10=D4=C221=C8=D5 22:03
=CA=D5=BC=FE=C8=CB: Yangang
=B3=AD=CB=CD: Lisa Huang (yihuan); Dean Bogdanovic; Kiran Agrahara S= reenivasa; Benoit Claise (bclaise); netmod@ietf.org
=D6=F7=CC=E2: Re: =B4=F0=B8=B4: Some comments about ACL YANG model.<= br>
From: Yangang <yangang@huawei.com>
Date: Tuesday, October 21, 2014 at= 7:03 AM
To: Cisco Employee <dblair@cisco.com>
Cc: "Lisa Huang (yihuan)"= ; <yihuan@cisco.co= m>, Dean Bogdanovic <deanb@juniper.net>, Kiran Agrahara Sreenivasa <kkoushik@Bro= cade.com>, "Benoit Claise (bclaise)" <bclaise@cisco.com>, "netmod@ietf.org" = <netmod@ietf.org>
Subject: =B4=F0=B8=B4: Some commen= ts about ACL YANG model.

Hi,

 2.      In packet-fields module, It looks the current definition is not = so sufficient. For example, no "!=3D" definition, and no mask in = acl-ipv4-header-fields group, etc=A1=AD..

DLB:  no =A1=B0not=A1=B1 definition.   This is a good catc= h.  Feel free to propose an augmentation or change to the existing model.

Yangang: OK, I will do it, I try to provide data = as soon as possible.

Great.

<= span style=3D"font-family: Calibri, sans-serif; color: black;" lang=3D"EN-U= S">3.&nb= sp;     In this draft, there is acl-type and ace-type. It looks the IP p= acket match and Ethernet packet match can be configured together. But it lo= oks only "OR" relationship is at there, no "AND" relationship.

<= span style=3D"font-family: Calibri, sans-serif; color: black;" lang=3D"EN-U= S">DLB:     What kind of =A1=B0AND=A1=B1 relationship are you exp= ecting ?

Yangang: I remember we got one requirement = from the end user: They want the ACL to check the L2 MAC address and L3 IP = address together. At this time, the relationship of RULEs is =A1=B0AND=A1=B1, not =A1=B0OR=A1=B1.

So do they want to do this:
match ((IP address =3D=3D 1.1.1.1) AND (MAC address =3D=3D 0xABCDEF)) = permit

or this:

match ((IP address =3D=3D 1.1.1.1) OR (MAC address =3D=3D 0xABCDEF)) p= ermit

or something else ?

thanks,
Dana


 

 

Thanks

Yangang.

 

=B7=A2=BC=FE=C8=CB: Dana Bl= air (dblair) [mailto:= dblair@cisco.com]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA10=D4=C220=C8=D5 21:09
=CA=D5=BC=FE=C8=CB: Yangang
=B3=AD=CB=CD: Dana Blair (dblair); Lisa Huang (yihuan); Dean Bogdanovic; Kiran Agrahara= Sreenivasa; Benoit Claise (bclaise); netmod@ietf.org =D6=F7=CC=E2: RE: Some comments about ACL YANG model.

 

The draf= t authors met and here is the response.  Look for DLB:

The comm= ents mention compilable option which means the proposal compiles with pyang= --ietf option.

&= nbsp;

Hi,

&= nbsp;

I am rev= iewing the ACL YANG model. And I got some doubts, maybe somebody can help m= e to understand it.

&= nbsp;

1.      There is one field: targets. In my understanding, maybe it is us= ed to record who reference this ACL. I don=A1=AFt know if Is it mandatory o= r not. Or my understanding is wrong.

&= nbsp;

DLB: &nb= sp;Your understand is correct.  It=A1=AFs not mandatory.   To mov= e beyond just using string, we need a compilable augmentation.  Since = ACLs can be

applied = to interfaces, that might be a good place to start.    

&= nbsp;

2.      In packet-fields module, It looks the current definition is not = so sufficient. For example, no "!=3D" definition, and no mask in = acl-ipv4-header-fields group, etc=A1=AD..

DLB:  no =A1=B0not=A1=B1 definition.   This is a good catc= h.  Feel free to propose an augmentation or change to the existing model.

 

<= span style=3D"font-family: Calibri, sans-serif; color: black;" lang=3D"EN-U= S">3.&nb= sp;     In this draft, there is acl-type and ace-type. It looks the IP p= acket match and Ethernet packet match can be configured together. But it lo= oks only "OR" relationship is at there, no "AND" relationship.

<= span style=3D"font-family: Calibri, sans-serif; color: black;" lang=3D"EN-U= S">DLB:     What kind of =A1=B0AND=A1=B1 relationship are you exp= ecting ?

<= span style=3D"font-family: Calibri, sans-serif; color: black; font-size: 10= .5pt;" lang=3D"EN-US"> 

<= span style=3D"font-family: Calibri, sans-serif; color: black;" lang=3D"EN-U= S">thanks,

<= span style=3D"font-family: Calibri, sans-serif; color: black;" lang=3D"EN-U= S">Dana Blair

<= span style=3D"font-family: Calibri, sans-serif; color: black; font-size: 10= .5pt;" lang=3D"EN-US"> 

<= span style=3D"font-family: Calibri, sans-serif; color: black; font-size: 10= .5pt;" lang=3D"EN-US"> 

&= nbsp;

Thanks

Yangang<= /span>

 --_000_D06C1AE821A584dblairciscocom_-- From nobody Tue Oct 21 14:32:31 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E801A8768 for ; Tue, 21 Oct 2014 14:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 Lvze0wXLcc-3 for ; Tue, 21 Oct 2014 14:32:28 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F066A1A8761 for ; Tue, 21 Oct 2014 14:32:27 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id 767BF193FC73D for ; Tue, 21 Oct 2014 21:32:22 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s9LLWQKm024463 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 21 Oct 2014 17:32:26 -0400 Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.170]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Tue, 21 Oct 2014 17:32:26 -0400 From: "Sterne, Jason (Jason)" To: "netmod@ietf.org" Thread-Topic: IETF91 NETMOD agenda ? Thread-Index: Ac/tdoGexyGw623TR4igNJSWn+KnzA== Date: Tue, 21 Oct 2014 21:32:26 +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_A125E53CE190A749957C19483DC79F9F5C977E5AUS70TWXCHMBA11z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/R0LejTTLr2YaAOH0cbP8tfC-fqM Subject: [netmod] IETF91 NETMOD 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, 21 Oct 2014 21:32:29 -0000 --_000_A125E53CE190A749957C19483DC79F9F5C977E5AUS70TWXCHMBA11z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Is there a preliminary agenda for the two NETMOD sessions at IETF91 ? Some thought about topics being split between the 1st (longer) and 2nd (sho= rter) sessions ? Thanks, Jason --_000_A125E53CE190A749957C19483DC79F9F5C977E5AUS70TWXCHMBA11z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi all,
 
Is there a preliminary agenda for the two NETMOD sessions at IETF91 ?&= nbsp;   
 
Some thought about topics being split between the 1st (longer) and 2nd= (shorter) sessions ?
 
Thanks,
Jason
 
--_000_A125E53CE190A749957C19483DC79F9F5C977E5AUS70TWXCHMBA11z_-- From nobody Tue Oct 21 14:34:50 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1331A8761 for ; Tue, 21 Oct 2014 14:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 slVhgMBpNv3y for ; Tue, 21 Oct 2014 14:34:38 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id ACD1D1A8788 for ; Tue, 21 Oct 2014 14:34:24 -0700 (PDT) Received: from [192.168.1.123] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id BFC1A28CF19A; Tue, 21 Oct 2014 17:34:23 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_148C0A98-A3B8-4B51-A3F9-060EB7B71336" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: "Thomas D. Nadeau" In-Reply-To: Date: Tue, 21 Oct 2014 17:34:23 -0400 Message-Id: References: To: "Sterne, Jason (Jason)" X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/-bzxl2kkIHMMIVBfxIrUTxPNT_c Cc: "netmod@ietf.org" Subject: Re: [netmod] IETF91 NETMOD 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, 21 Oct 2014 21:34:42 -0000 --Apple-Mail=_148C0A98-A3B8-4B51-A3F9-060EB7B71336 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Not yet. Please propose topics.=20 =E2=80=94Tom > On Oct 21, 2014:5:32 PM, at 5:32 PM, Sterne, Jason (Jason) = wrote: >=20 > Hi all, > =20 > Is there a preliminary agenda for the two NETMOD sessions at IETF91 ? = =20 > =20 > Some thought about topics being split between the 1st (longer) and 2nd = (shorter) sessions ? > =20 > Thanks, > Jason > =20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod = --Apple-Mail=_148C0A98-A3B8-4B51-A3F9-060EB7B71336 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Not yet. = Please propose topics. 

= =E2=80=94Tom


On Oct 21, 2014:5:32 PM, at 5:32 PM, Sterne, Jason (Jason) = <jason.sterne@alcatel-lucent.com> wrote:

Hi all,
 
Is there a preliminary agenda for = the two NETMOD sessions at IETF91 ?     
 
Some thought about topics being = split between the 1st (longer) and 2nd (shorter) sessions = ?
 
Thanks,
Jason
 
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

= --Apple-Mail=_148C0A98-A3B8-4B51-A3F9-060EB7B71336-- From nobody Tue Oct 21 14:45:03 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6535E1A87AE for ; Tue, 21 Oct 2014 14:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=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 I_pNKIe2K7vh for ; Tue, 21 Oct 2014 14:44:59 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id ED48B1A87A8 for ; Tue, 21 Oct 2014 14:44:57 -0700 (PDT) Received: from [192.168.1.123] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 661B728CF217 for ; Tue, 21 Oct 2014 17:44:57 -0400 (EDT) From: "Thomas D. Nadeau" Content-Type: multipart/mixed; boundary="Apple-Mail=_25E6DC31-DB01-43BA-BF86-65974C06E84E" Message-Id: Date: Tue, 21 Oct 2014 17:44:57 -0400 To: NETMOD Working Group Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/RiiiN7W2Lx5xNLwqhcLc-vEQCXI Subject: [netmod] interim meeting: yang model focus X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 21 Oct 2014 21:45:01 -0000 --Apple-Mail=_25E6DC31-DB01-43BA-BF86-65974C06E84E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Tomorrow's meeting will use the same WebEx from last time (and = the same as was used last week at the Yang 1.1-focused meeting).=20 Tomorrow's interim meeting has the following preliminary agenda: 0) Quickly how to use IRC/sign-in 1) Note Well 2) Agenda Bashing 3) OSPF Model - Kiran Agrahara Sreenivasa = ; myeung@cisco.com =09 Are there any other models people wish to discuss? --Tom --Apple-Mail=_25E6DC31-DB01-43BA-BF86-65974C06E84E Content-Disposition: attachment; filename=webex.txt Content-Type: text/plain; name="webex.txt" Content-Transfer-Encoding: quoted-printable Topic: NETMOD WG Date: Every Wednesday, from Wednesday, August 27, 2014 to Wednesday, = October 22, 2014 Time: 4:00 pm, Europe Summer Time (Berlin, GMT+02:00) Meeting Number: 649 102 111 Meeting Password: 1234 ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to = https://ietf.webex.com/ietf/j.php?MTID=3Dmbbe9c321c8e9f472df4ce74c1987a0f0= 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: 1234 4. Click "Join". 5. Follow the instructions that appear on your screen. To view in other time zones or languages, please click the link: https://ietf.webex.com/ietf/j.php?MTID=3Dme720293ef5473cc3bf963302b2f6a8f1= ------------------------------------------------------- To join the audio conference only=20 ------------------------------------------------------- Call-in toll number (US/Canada): 1-650-479-3208 Access code:649 102 111 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/mc 2. On the left navigation bar, click "Support". You can contact me at: cmorgan@amsl.com 1-510-492-4085 To update this meeting to your calendar program (for example Microsoft = Outlook), click this link: https://ietf.webex.com/ietf/j.php?MTID=3Dm4f877f2e629b841380e2d593e4e39b87= WebEx will automatically setup Meeting Manager for Windows the first = time you join a meeting. To save time, you can setup prior to the = meeting by clicking this link: https://ietf.webex.com/ietf/meetingcenter/mcsetup.php The playback of UCF (Universal Communications Format) rich media files = requires appropriate players. To view this type of rich media files in = the meeting, please check whether you have the players installed on your = computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php.=20 http://www.webex.com CCP:+16504793208x649102111#=20 IMPORTANT NOTICE: This WebEx service includes a feature that allows = audio and any documents and other materials exchanged or viewed during = the session to be recorded. By joining this session, you automatically = consent to such recordings. If you do not consent to the recording, = discuss your concerns with the meeting host prior to the start of the = recording or do not join the session. Please note that any such = recordings may be subject to discovery in the event of litigation. --Apple-Mail=_25E6DC31-DB01-43BA-BF86-65974C06E84E-- From nobody Tue Oct 21 14:55:43 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E00491A87CC; Tue, 21 Oct 2014 14:55: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, T_FILL_THIS_FORM_SHORT=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 oMR4aLUjk14r; Tue, 21 Oct 2014 14:55:40 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 109421A86E7; Tue, 21 Oct 2014 14:55:40 -0700 (PDT) Received: from [192.168.1.123] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 79B0B28CF2E4; Tue, 21 Oct 2014 17:55:39 -0400 (EDT) From: Thomas D. Nadeau Content-Type: multipart/mixed; boundary="Apple-Mail=_29A6B0A8-94BB-45D0-A108-38FF1C5F971B" Message-Id: <51ACD11B-3A23-4907-9970-D437103380F5@lucidvision.com> Date: Tue, 21 Oct 2014 17:55:39 -0400 To: NETMOD Working Group , rtg-yang-coord@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/8cGwEku9MIOprGqKR3TuKkLRCss Subject: [netmod] interim meeting: yang model focus X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 21 Oct 2014 21:55:42 -0000 --Apple-Mail=_29A6B0A8-94BB-45D0-A108-38FF1C5F971B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii [adding rtg-yang-coord] Tomorrow's meeting will use the same WebEx from last time (and = the same as was used last week at the Yang 1.1-focused meeting).=20 Tomorrow's interim meeting has the following preliminary agenda: 0) Quickly how to use IRC/sign-in 1) Note Well 2) Agenda Bashing 3) OSPF Model - Kiran Agrahara Sreenivasa = ; myeung@cisco.com =09 Are there any other models people wish to discuss? --Tom --Apple-Mail=_29A6B0A8-94BB-45D0-A108-38FF1C5F971B Content-Disposition: attachment; filename=webex.txt Content-Type: text/plain; name="webex.txt" Content-Transfer-Encoding: quoted-printable Topic: NETMOD WG Date: Every Wednesday, from Wednesday, August 27, 2014 to Wednesday, = October 22, 2014 Time: 4:00 pm, Europe Summer Time (Berlin, GMT+02:00) Meeting Number: 649 102 111 Meeting Password: 1234 ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to = https://ietf.webex.com/ietf/j.php?MTID=3Dmbbe9c321c8e9f472df4ce74c1987a0f0= 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: 1234 4. Click "Join". 5. Follow the instructions that appear on your screen. To view in other time zones or languages, please click the link: https://ietf.webex.com/ietf/j.php?MTID=3Dme720293ef5473cc3bf963302b2f6a8f1= ------------------------------------------------------- To join the audio conference only=20 ------------------------------------------------------- Call-in toll number (US/Canada): 1-650-479-3208 Access code:649 102 111 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/mc 2. On the left navigation bar, click "Support". You can contact me at: cmorgan@amsl.com 1-510-492-4085 To update this meeting to your calendar program (for example Microsoft = Outlook), click this link: https://ietf.webex.com/ietf/j.php?MTID=3Dm4f877f2e629b841380e2d593e4e39b87= WebEx will automatically setup Meeting Manager for Windows the first = time you join a meeting. To save time, you can setup prior to the = meeting by clicking this link: https://ietf.webex.com/ietf/meetingcenter/mcsetup.php The playback of UCF (Universal Communications Format) rich media files = requires appropriate players. To view this type of rich media files in = the meeting, please check whether you have the players installed on your = computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php.=20 http://www.webex.com CCP:+16504793208x649102111#=20 IMPORTANT NOTICE: This WebEx service includes a feature that allows = audio and any documents and other materials exchanged or viewed during = the session to be recorded. By joining this session, you automatically = consent to such recordings. If you do not consent to the recording, = discuss your concerns with the meeting host prior to the start of the = recording or do not join the session. Please note that any such = recordings may be subject to discovery in the event of litigation. --Apple-Mail=_29A6B0A8-94BB-45D0-A108-38FF1C5F971B-- From nobody Tue Oct 21 16:32:09 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5F01A8821; Tue, 21 Oct 2014 16:32:07 -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 hfIv5E0fqoD8; Tue, 21 Oct 2014 16:32:05 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03FAA1A87DB; Tue, 21 Oct 2014 16:32:04 -0700 (PDT) Received: by mail-oi0-f54.google.com with SMTP id v63so1862546oia.27 for ; Tue, 21 Oct 2014 16:32:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:subject:message-id:importance:from:to:reply-to:mime-version :content-type; bh=z5vj4qpFBRbUl7VyLVhCrvddWw5yZHTJKaaJ8zu4Vxw=; b=k/xqEZr8p6tuJFSRQ6/fDOkPBX6ZJofmegouqQfITuUsfvcCZzankOcKr8ZLZmXYIu 89vkIS0xktzwoKQt/IyKiySuYSuEVk277Uv+EieVvDbtFtD3GRvkuxMx0chRJflDjtP7 HGeU0UXt4uihhQH1mjZ23fUAMyM5YeRd3GHlCtTSPrYv3TwhHuSS+Ou4f0nFeqPHtVIA s94aL4rf4aNenoeSn0SF6ZxH1vCEAyBULB50jQhBT0u3n8E8EuyRRNymsfXSRAuSsKqY O1YXeGz5Lk6YtqQX0/BOFw1Zqf3iF9rBO6c0ynLEntXkIn17S+0Wth673EmkZYbL+OV6 qmeA== X-Received: by 10.182.165.36 with SMTP id yv4mr12107929obb.39.1413934324505; Tue, 21 Oct 2014 16:32:04 -0700 (PDT) Received: from [10.182.83.224] ([32.144.61.15]) by mx.google.com with ESMTPSA id e1sm1879723obn.11.2014.10.21.16.32.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 Oct 2014 16:32:03 -0700 (PDT) Date: Tue, 21 Oct 2014 16:31:56 -0700 Message-ID: Importance: normal From: rapenno To: tnadeau@lucidvision.com, netmod@ietf.org, rtg-yang-coord@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_499544408436670" Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/livluSIyS7r2Yw3tDozJzcITcNo Subject: Re: [netmod] interim meeting: yang model focus X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: rapenno List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 23:32:07 -0000 ----_com.android.email_499544408436670 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SSB3b3VsZCBsaWtlIHRvIGRpc2N1c3MgU0ZDIHlhbmcgbW9kZWxuaWYgdGltZSBwZXJtaXRzCgoK U2VudCBmcm9tIFNhbXN1bmcgTW9iaWxlCgotLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0t LS0tCkZyb206ICJUaG9tYXMgRC4gTmFkZWF1IiA8dG5hZGVhdUBsdWNpZHZpc2lvbi5jb20+IApE YXRlOiAgClRvOiBORVRNT0QgV29ya2luZyBHcm91cCA8bmV0bW9kQGlldGYub3JnPixydGcteWFu Zy1jb29yZEBpZXRmLm9yZyAKU3ViamVjdDogW25ldG1vZF0gaW50ZXJpbSBtZWV0aW5nOiB5YW5n IG1vZGVsIGZvY3VzIAogClthZGRpbmfCoCBydGcteWFuZy1jb29yZF0KCgpUb21vcnJvdydzIG1l ZXRpbmcgd2lsbCB1c2UgdGhlIHNhbWUgV2ViRXggZnJvbSBsYXN0IHRpbWUgKGFuZCB0aGUgc2Ft ZSBhcyB3YXMgdXNlZCBsYXN0IHdlZWsgYXQgdGhlIFlhbmcgMS4xLWZvY3VzZWQgbWVldGluZyku IAoKVG9tb3Jyb3cncyBpbnRlcmltIG1lZXRpbmcgaGFzIHRoZSBmb2xsb3dpbmcgcHJlbGltaW5h cnkgYWdlbmRhOgoKMCkgUXVpY2tseSBob3cgdG8gdXNlIElSQy9zaWduLWluCjEpIE5vdGUgV2Vs bAoyKSBBZ2VuZGEgQmFzaGluZwozKSBPU1BGIE1vZGVsIC0gS2lyYW4gQWdyYWhhcmEgU3JlZW5p dmFzYSA8a2tvdXNoaWtAQnJvY2FkZS5jb20+OyBteWV1bmdAY2lzY28uY29tCgoKQXJlIHRoZXJl IGFueSBvdGhlciBtb2RlbHMgcGVvcGxlIHdpc2ggdG8gZGlzY3Vzcz8KCi0tVG9tCgoKCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm5ldG1vZCBtYWlsaW5n IGxpc3QKbmV0bW9kQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbmV0bW9kCg== ----_com.android.email_499544408436670 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+PGRpdj48ZGl2PjwvZGl2PjxkaXY+ SSB3b3VsZCBsaWtlIHRvIGRpc2N1c3MgU0ZDIHlhbmcgbW9kZWxuaWYgdGltZSBwZXJtaXRzPC9k aXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJmb250LXNp emU6NzUlO2NvbG9yOiM1NzU3NTciPlNlbnQgZnJvbSBTYW1zdW5nIE1vYmlsZTwvZGl2PjwvZGl2 PjwvZGl2PiA8YnI+PGJyPjxicj4tLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tPGJy PkZyb206ICJUaG9tYXMgRC4gTmFkZWF1IiAmbHQ7dG5hZGVhdUBsdWNpZHZpc2lvbi5jb20mZ3Q7 IDxicj5EYXRlOiAgPGJyPlRvOiBORVRNT0QgV29ya2luZyBHcm91cCAmbHQ7bmV0bW9kQGlldGYu b3JnJmd0OyxydGcteWFuZy1jb29yZEBpZXRmLm9yZyA8YnI+U3ViamVjdDogW25ldG1vZF0gaW50 ZXJpbSBtZWV0aW5nOiB5YW5nIG1vZGVsIGZvY3VzIDxicj4gPGJyPjxicj5bYWRkaW5nJm5ic3A7 IHJ0Zy15YW5nLWNvb3JkXTxicj48YnI+PGJyPglUb21vcnJvdydzIG1lZXRpbmcgd2lsbCB1c2Ug dGhlIHNhbWUgV2ViRXggZnJvbSBsYXN0IHRpbWUgKGFuZCB0aGUgc2FtZSBhcyB3YXMgdXNlZCBs YXN0IHdlZWsgYXQgdGhlIFlhbmcgMS4xLWZvY3VzZWQgbWVldGluZykuIDxicj48YnI+CVRvbW9y cm93J3MgaW50ZXJpbSBtZWV0aW5nIGhhcyB0aGUgZm9sbG93aW5nIHByZWxpbWluYXJ5IGFnZW5k YTo8YnI+PGJyPgkwKSBRdWlja2x5IGhvdyB0byB1c2UgSVJDL3NpZ24taW48YnI+CTEpIE5vdGUg V2VsbDxicj4JMikgQWdlbmRhIEJhc2hpbmc8YnI+CTMpIE9TUEYgTW9kZWwgLSBLaXJhbiBBZ3Jh aGFyYSBTcmVlbml2YXNhICZsdDtra291c2hpa0BCcm9jYWRlLmNvbSZndDs7IG15ZXVuZ0BjaXNj by5jb208YnI+CTxicj48YnI+CUFyZSB0aGVyZSBhbnkgb3RoZXIgbW9kZWxzIHBlb3BsZSB3aXNo IHRvIGRpc2N1c3M/PGJyPjxicj4JLS1Ub208YnI+PGJyPjxicj48YnI+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+bmV0bW9kIG1haWxpbmcgbGlzdDxi cj5uZXRtb2RAaWV0Zi5vcmc8YnI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRtb2Q8YnI+PC9ib2R5Pg== ----_com.android.email_499544408436670-- From nobody Tue Oct 21 16:59:43 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7E01A8844 for ; Tue, 21 Oct 2014 16:59:42 -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 5If9EGF6_iJs for ; Tue, 21 Oct 2014 16:59:40 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E81C41A883D for ; Tue, 21 Oct 2014 16:59:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16064; q=dns/txt; s=iport; t=1413935980; x=1415145580; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=sid0QZHJ+Cj+dR4+jgjPo48BwPVP7UctYyAUnX3s+wc=; b=MveGDoSCvYfI9s/HJSbGXVRJj/i653XnxALPXv9qPcaijaXQ2klgLE2v +mv6WRcWYCqQH+SrZN3I0yWrtcCZaSYOowGSeDViGYTmL5jNBn6V/Hw7l HEpL/SHKimFwif5fxXanedqn2uggBn9q+xblK2R/mQKxBorxv8OsBKjgD M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An8FAJjyRlStJA2B/2dsb2JhbABcgkhGU1gEgwK5So5IgWYBC4Z3VAIbeBYBfYQCAQEBAgIBAQEgCkEbAgEIEQEDAQELHQMCAgIlCxQDBggCBAESCAGINg2xPpR2AQEBAQEBAQEBAQEBAQEBAQEBAQEBF5AmLQoBgnc2gR4FkgGERohDPIMMkS2DeGwBgUeBAwEBAQ X-IronPort-AV: E=Sophos;i="5.04,765,1406592000"; d="scan'208,217";a="365266943" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-6.cisco.com with ESMTP; 21 Oct 2014 23:59:39 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s9LNxdMl024627 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Oct 2014 23:59:39 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.189]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Tue, 21 Oct 2014 18:59:38 -0500 From: "Eric Voit (evoit)" To: "Thomas D. Nadeau" , "netmod@ietf.org" Thread-Topic: [netmod] IETF91 NETMOD agenda ? Thread-Index: AQHP7Xb3DvWoTPdbPEqKhstsfCTVD5w7Lt2g Date: Tue, 21 Oct 2014 23:59:38 +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: [10.116.134.135] Content-Type: multipart/alternative; boundary="_000_EF64FF31F4C4384DBCE5D513A791C2B120A55E7Axmbalnx11ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/--Doqyxxn571D7BfYm2dS2QN_m0 Subject: Re: [netmod] IETF91 NETMOD 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, 21 Oct 2014 23:59:42 -0000 --_000_EF64FF31F4C4384DBCE5D513A791C2B120A55E7Axmbalnx11ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB3b3VsZCBsaWtlIHRvIHRhbGsgYWJvdXQNCmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtdm9pdC1uZXRtb2QtcGVlci1tb3VudC1yZXF1aXJlbWVudHMvDQoNCldlIGNoYXR0 ZWQgYWJvdXQgdGhpcyBkb2N1bWVudCBpbiBhbiBJbnRlcmltIGNhbGwgdHdvIHdlZWtzIGFnby4g IFRoZSBpbnRybyBQUFQgaXMgaGVyZTxodHRwOi8vd3d3LnZvaXQub3JnL1BlZXItTW91bnQtTmV0 Y29uZi1XRy1PY3QyMDE0LnBkZj4uICBBIHJlc3VsdCBvZiB0aGUgY2FsbCB3YXMgdGhhdCB3ZSBo YWQgYSB3aWRlIHJhbmdpbmcgYWxpYXMgZGlzY3Vzc2lvbnMuICBBIHJldmlldyBpbiBIYXdhaWkg d291bGQgYWxsb3cgYSByZWNhcC9zdW1tYXJ5IG9mIG1haWxpbmcgbGlzdCBkaXNjdXNzaW9ucywg YXMgd2VsbCBhcyBhbiBpbnRyb2R1Y3Rpb24gdG8gdGhlIGNvbmNlcHRzIHRvIG90aGVyIHBhcnRp Y2lwYW50cy4NCg0KTm90ZSB0aGF0IHNldmVyYWwgZGlzY3Vzc2lvbnMgY2FtZSBvdXQgb2YgdGhl IGNhbGwuICBFYWNoIGhhcyBpbXBsaWNhdGlvbnMgdG8gcG9zc2libGUgY2hhcnRlcnMgYWNyb3Nz IHZhcmlvdXMgSUVURiBXRy4gIFdvcnRoeSBvZiBkaXNjdXNzaW9uIGFyZToNCg0KLSBSRkMgNjI0 NCBkZWZpbmVzIGEgc2luZ2xlLWJveCBhcmNoaXRlY3R1cmUuICBZQU5HIHN5bnRheCBpcyB1c2Vk IGZvciBtdWx0aS1kZXZpY2UgYWJzdHJhY3Rpb25zIGluIHRoZSBPcGVuRGF5bGlnaHQgY29udHJv bGxlci4gIFNob3VsZCB0aGUgSUVURiBjb25zaWRlciBhcmNoaXRlY3R1cmVzIHdoZXJlIFlBTkcg bW9kZWxzIHNwYW4gZGV2aWNlcz8NCg0KLSBSRkMgNTI3NyBvbiBOZXRjb25mIG5vdGlmaWNhdGlv bnMgZG9lc27igJl0IGluY2x1ZGUgaW5mb3JtYXRpb24gb24gaG93IHRvIGhhbmRsZSBQdWIvU3Vi LiAgVGhlcmUgaXMgYWxzbyBzb21lIGRlbWFuZCBmb3IgUHViL1N1YiB3aGljaCBpcyB0aWVkIHRv IFlBTkcgd2l0aCBubyByZXF1aXJlZCBsaW5rYWdlIHRvIGEgdHJhbnNwb3J0IHByb3RvY29sLiAg VGhlcmUgYXJlIGFsc28gbmVlZHMgZm9yIFB1Yi9TdWIgYmV5b25kIFlBTkcuICBIb3cgc2hvdWxk IHdlIGFwcHJvYWNoIHRoaXMgYXJlYT8NCg0KRXJpYw0KDQpGcm9tOiBuZXRtb2QgW21haWx0bzpu ZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRob21hcyBELiBOYWRlYXUNClNl bnQ6IFR1ZXNkYXksIE9jdG9iZXIgMjEsIDIwMTQgNTozNCBQTQ0KVG86IFN0ZXJuZSwgSmFzb24g KEphc29uKQ0KQ2M6IG5ldG1vZEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtuZXRtb2RdIElFVEY5 MSBORVRNT0QgYWdlbmRhID8NCg0KDQogICAgICAgICAgTm90IHlldC4gUGxlYXNlIHByb3Bvc2Ug dG9waWNzLg0KDQogICAgICAgICAg4oCUVG9tDQoNCg0KT24gT2N0IDIxLCAyMDE0OjU6MzIgUE0s IGF0IDU6MzIgUE0sIFN0ZXJuZSwgSmFzb24gKEphc29uKSA8amFzb24uc3Rlcm5lQGFsY2F0ZWwt bHVjZW50LmNvbTxtYWlsdG86amFzb24uc3Rlcm5lQGFsY2F0ZWwtbHVjZW50LmNvbT4+IHdyb3Rl Og0KDQpIaSBhbGwsDQoNCklzIHRoZXJlIGEgcHJlbGltaW5hcnkgYWdlbmRhIGZvciB0aGUgdHdv IE5FVE1PRCBzZXNzaW9ucyBhdCBJRVRGOTEgPw0KDQpTb21lIHRob3VnaHQgYWJvdXQgdG9waWNz IGJlaW5nIHNwbGl0IGJldHdlZW4gdGhlIDFzdCAobG9uZ2VyKSBhbmQgMm5kIChzaG9ydGVyKSBz ZXNzaW9ucyA/DQoNClRoYW5rcywNCkphc29uDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRtb2RAaWV0Zi5v cmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbmV0bW9kDQoNCg== --_000_EF64FF31F4C4384DBCE5D513A791C2B120A55E7Axmbalnx11ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkhlbHZldGlj YTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAx MSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNw YW4uYXBwbGUtdGFiLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtdGFiLXNwYW47fQ0Kc3Bh bi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVk LXNwYWNlO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi Pkkgd291bGQgbGlrZSB0byB0YWxrIGFib3V0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJodHRw Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXZvaXQtbmV0bW9kLXBlZXItbW91bnQt cmVxdWlyZW1lbnRzLyI+aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC12b2l0 LW5ldG1vZC1wZWVyLW1vdW50LXJlcXVpcmVtZW50cy88L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldlIGNoYXR0ZWQgYWJvdXQg dGhpcyBkb2N1bWVudCBpbiBhbiBJbnRlcmltIGNhbGwgdHdvIHdlZWtzIGFnby4mbmJzcDsgVGhl IGludHJvIFBQVCBpcw0KPGEgaHJlZj0iaHR0cDovL3d3dy52b2l0Lm9yZy9QZWVyLU1vdW50LU5l dGNvbmYtV0ctT2N0MjAxNC5wZGYiPmhlcmU8L2E+LiAmbmJzcDtBIHJlc3VsdCBvZiB0aGUgY2Fs bCB3YXMgdGhhdCB3ZSBoYWQgYSB3aWRlIHJhbmdpbmcgYWxpYXMgZGlzY3Vzc2lvbnMuJm5ic3A7 IEEgcmV2aWV3IGluIEhhd2FpaSB3b3VsZCBhbGxvdyBhIHJlY2FwL3N1bW1hcnkgb2YgbWFpbGlu ZyBsaXN0IGRpc2N1c3Npb25zLCBhcyB3ZWxsIGFzIGFuIGludHJvZHVjdGlvbiB0byB0aGUNCiBj b25jZXB0cyB0byBvdGhlciBwYXJ0aWNpcGFudHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Ob3RlIHRoYXQgc2V2ZXJh bCBkaXNjdXNzaW9ucyBjYW1lIG91dCBvZiB0aGUgY2FsbC4mbmJzcDsgRWFjaCBoYXMgaW1wbGlj YXRpb25zIHRvIHBvc3NpYmxlIGNoYXJ0ZXJzIGFjcm9zcyB2YXJpb3VzIElFVEYgV0cuJm5ic3A7 IFdvcnRoeSBvZiBkaXNjdXNzaW9uIGFyZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi0gUkZDIDYyNDQgZGVmaW5lcyBh IHNpbmdsZS1ib3ggYXJjaGl0ZWN0dXJlLiZuYnNwOyBZQU5HIHN5bnRheCBpcyB1c2VkIGZvciBt dWx0aS1kZXZpY2UgYWJzdHJhY3Rpb25zIGluIHRoZSBPcGVuRGF5bGlnaHQgY29udHJvbGxlci4m bmJzcDsgU2hvdWxkIHRoZSBJRVRGIGNvbnNpZGVyIGFyY2hpdGVjdHVyZXMNCiB3aGVyZSBZQU5H IG1vZGVscyBzcGFuIGRldmljZXM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tIFJGQyA1Mjc3IG9uIE5ldGNvbmYgbm90 aWZpY2F0aW9ucyBkb2VzbuKAmXQgaW5jbHVkZSBpbmZvcm1hdGlvbiBvbiBob3cgdG8gaGFuZGxl IFB1Yi9TdWIuJm5ic3A7IFRoZXJlIGlzIGFsc28gc29tZSBkZW1hbmQgZm9yIFB1Yi9TdWIgd2hp Y2ggaXMgdGllZCB0byBZQU5HIHdpdGgNCiBubyByZXF1aXJlZCBsaW5rYWdlIHRvIGEgdHJhbnNw b3J0IHByb3RvY29sLiZuYnNwOyBUaGVyZSBhcmUgYWxzbyBuZWVkcyBmb3IgUHViL1N1YiBiZXlv bmQgWUFORy4mbmJzcDsgSG93IHNob3VsZCB3ZSBhcHByb2FjaCB0aGlzIGFyZWE/ICZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48YnI+DQpFcmljPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBp biA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2Vz QGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5UaG9tYXMgRC4gTmFkZWF1PGJyPg0KPGI+ U2VudDo8L2I+IFR1ZXNkYXksIE9jdG9iZXIgMjEsIDIwMTQgNTozNCBQTTxicj4NCjxiPlRvOjwv Yj4gU3Rlcm5lLCBKYXNvbiAoSmFzb24pPGJyPg0KPGI+Q2M6PC9iPiBuZXRtb2RAaWV0Zi5vcmc8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtuZXRtb2RdIElFVEY5MSBORVRNT0QgYWdlbmRhID88 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNs YXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5Ob3QgeWV0LiBQbGVhc2UgcHJvcG9zZSB0b3BpY3Mu Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+4oCUVG9tPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE9jdCAyMSwgMjAxNDo1OjMy IFBNLCBhdCA1OjMyIFBNLCBTdGVybmUsIEphc29uIChKYXNvbikgJmx0OzxhIGhyZWY9Im1haWx0 bzpqYXNvbi5zdGVybmVAYWxjYXRlbC1sdWNlbnQuY29tIj5qYXNvbi5zdGVybmVAYWxjYXRlbC1s dWNlbnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkhpIGFsbCw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+SXMgdGhlcmUgYSBwcmVsaW1pbmFyeSBhZ2VuZGEgZm9yIHRoZSB0d28gTkVUTU9EIHNl c3Npb25zIGF0IElFVEY5MSA/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Tb21lIHRob3Vn aHQgYWJvdXQgdG9waWNzIGJlaW5nIHNwbGl0IGJldHdlZW4gdGhlIDE8L3NwYW4+PHN1cD48c3Bh biBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+c3Q8L3NwYW4+PC9zdXA+PHNwYW4gY2xhc3M9ImFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3Nw YW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+KGxvbmdlcikNCiBhbmQgMjwv c3Bhbj48c3VwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5uZDwvc3Bhbj48L3N1cD48c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4oc2hv cnRlcikNCiBzZXNzaW9ucyA/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkphc29uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQpuZXRtb2QgbWFpbGluZyBsaXN0PGJyPg0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpuZXRt b2RAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+bmV0bW9kQGlldGYub3JnPC9zcGFuPjwvYT48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPjxicj4NCjwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25ldG1vZCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL25ldG1vZDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_EF64FF31F4C4384DBCE5D513A791C2B120A55E7Axmbalnx11ciscoc_-- From nobody Tue Oct 21 17:04:54 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 037C21A8847 for ; Tue, 21 Oct 2014 17:04:52 -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 YTu2d79Oxs3v for ; Tue, 21 Oct 2014 17:04:49 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27C251A883F for ; Tue, 21 Oct 2014 17:04:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20116; q=dns/txt; s=iport; t=1413936289; x=1415145889; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=KMZW68xMmY9ib8A/zZv9SEeZUAT+ZnG2GNu271nwKGM=; b=N0MxieQcIpJ3oMMqERxC6QsGf4aAU26BSZBZeuqGwtEUjumoOWHpdli5 Go6EKeXjJpUKsu50J1ZY/cnp2TeS7CzQTN3wq2cOQG0aQNlQZCKMD3o5C FeOB09c7SIkI9MXSfzq47ygPMB3xohxP8XcCj0IY+vZCKXF4GoBTZcjHj o=; X-Files: ATT00002.txt : 133 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An8FAMXzRlStJA2D/2dsb2JhbABcgkhGU1gEgwK5So5IgWYBC4Z3VAIbeBYBfYQCAQEBAgIBAQEgCkEbAgEIEQEDAQELHQMCAgIlCxQDBAEBBQMCBAESCAEFiDENsT6UdgEBAQEBAQEBAQEBAQEBAQEBAQEBAReQJi0KAYJ3NoEeBZIBgg6BUGiIQzyDDJEtg3hsAYFHgQMBAQE X-IronPort-AV: E=Sophos;i="5.04,765,1406592000"; d="txt'?scan'208,217";a="89155209" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-3.cisco.com with ESMTP; 22 Oct 2014 00:04:48 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s9M04mwc030819 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Oct 2014 00:04:48 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.189]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Tue, 21 Oct 2014 19:04:48 -0500 From: "Eric Voit (evoit)" To: "netmod@ietf.org" , "Thomas D. Nadeau" Thread-Topic: [netmod] IETF91 NETMOD agenda ? Thread-Index: AQHP7Xb3DvWoTPdbPEqKhstsfCTVD5w7Lt2ggAANXAA= Date: Wed, 22 Oct 2014 00:04:47 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.116.134.135] Content-Type: multipart/mixed; boundary="_004_EF64FF31F4C4384DBCE5D513A791C2B120A55EB6xmbalnx11ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/-2P_D0HqYyYP6c3z29kva00JQa4 Subject: [netmod] FW: IETF91 NETMOD 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, 22 Oct 2014 00:04:52 -0000 --_004_EF64FF31F4C4384DBCE5D513A791C2B120A55EB6xmbalnx11ciscoc_ Content-Type: multipart/alternative; boundary="_000_EF64FF31F4C4384DBCE5D513A791C2B120A55EB6xmbalnx11ciscoc_" --_000_EF64FF31F4C4384DBCE5D513A791C2B120A55EB6xmbalnx11ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQgbWlnaHQgYWxzbyBiZSBnb29kIHRvcCBzdW1tYXJpemUgdGhlIHNldCBvZiB0b3BpY3MgYmVs b3cgZHVyaW5nIHRoZSBpbnRlcmltIGNhbGwgdG9tb3Jyb3cuICAgVGhhdCB3b3VsZCB0ZWUgdXAg ZXhhY3RseSB3aGF0IGNvdWxkIGJlIG9uIHRoZSBwbGF0ZSBmb3IgSGF3YWlpLg0KDQpFcmljDQoN CkZyb206IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgRXJpYyBWb2l0IChldm9pdCkNClNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMjEsIDIwMTQgODow MCBQTQ0KVG86IFRob21hcyBELiBOYWRlYXU7IG5ldG1vZEBpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFtuZXRtb2RdIElFVEY5MSBORVRNT0QgYWdlbmRhID8NCg0KSSB3b3VsZCBsaWtlIHRvIHRhbGsg YWJvdXQNCmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdm9pdC1uZXRtb2Qt cGVlci1tb3VudC1yZXF1aXJlbWVudHMvDQoNCldlIGNoYXR0ZWQgYWJvdXQgdGhpcyBkb2N1bWVu dCBpbiBhbiBJbnRlcmltIGNhbGwgdHdvIHdlZWtzIGFnby4gIFRoZSBpbnRybyBQUFQgaXMgaGVy ZTxodHRwOi8vd3d3LnZvaXQub3JnL1BlZXItTW91bnQtTmV0Y29uZi1XRy1PY3QyMDE0LnBkZj4u ICBBIHJlc3VsdCBvZiB0aGUgY2FsbCB3YXMgdGhhdCB3ZSBoYWQgYSB3aWRlIHJhbmdpbmcgYWxp YXMgZGlzY3Vzc2lvbnMuICBBIHJldmlldyBpbiBIYXdhaWkgd291bGQgYWxsb3cgYSByZWNhcC9z dW1tYXJ5IG9mIG1haWxpbmcgbGlzdCBkaXNjdXNzaW9ucywgYXMgd2VsbCBhcyBhbiBpbnRyb2R1 Y3Rpb24gdG8gdGhlIGNvbmNlcHRzIHRvIG90aGVyIHBhcnRpY2lwYW50cy4NCg0KTm90ZSB0aGF0 IHNldmVyYWwgZGlzY3Vzc2lvbnMgY2FtZSBvdXQgb2YgdGhlIGNhbGwuICBFYWNoIGhhcyBpbXBs aWNhdGlvbnMgdG8gcG9zc2libGUgY2hhcnRlcnMgYWNyb3NzIHZhcmlvdXMgSUVURiBXRy4gIFdv cnRoeSBvZiBkaXNjdXNzaW9uIGFyZToNCg0KLSBSRkMgNjI0NCBkZWZpbmVzIGEgc2luZ2xlLWJv eCBhcmNoaXRlY3R1cmUuICBZQU5HIHN5bnRheCBpcyB1c2VkIGZvciBtdWx0aS1kZXZpY2UgYWJz dHJhY3Rpb25zIGluIHRoZSBPcGVuRGF5bGlnaHQgY29udHJvbGxlci4gIFNob3VsZCB0aGUgSUVU RiBjb25zaWRlciBhcmNoaXRlY3R1cmVzIHdoZXJlIFlBTkcgbW9kZWxzIHNwYW4gZGV2aWNlcz8N Cg0KLSBSRkMgNTI3NyBvbiBOZXRjb25mIG5vdGlmaWNhdGlvbnMgZG9lc27igJl0IGluY2x1ZGUg aW5mb3JtYXRpb24gb24gaG93IHRvIGhhbmRsZSBQdWIvU3ViLiAgVGhlcmUgaXMgYWxzbyBzb21l IGRlbWFuZCBmb3IgUHViL1N1YiB3aGljaCBpcyB0aWVkIHRvIFlBTkcgd2l0aCBubyByZXF1aXJl ZCBsaW5rYWdlIHRvIGEgdHJhbnNwb3J0IHByb3RvY29sLiAgVGhlcmUgYXJlIGFsc28gbmVlZHMg Zm9yIFB1Yi9TdWIgYmV5b25kIFlBTkcuICBIb3cgc2hvdWxkIHdlIGFwcHJvYWNoIHRoaXMgYXJl YT8NCg0KRXJpYw0KDQpGcm9tOiBuZXRtb2QgW21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIFRob21hcyBELiBOYWRlYXUNClNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIg MjEsIDIwMTQgNTozNCBQTQ0KVG86IFN0ZXJuZSwgSmFzb24gKEphc29uKQ0KQ2M6IG5ldG1vZEBp ZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtuZXRtb2RdIElF VEY5MSBORVRNT0QgYWdlbmRhID8NCg0KDQogICAgICAgICAgTm90IHlldC4gUGxlYXNlIHByb3Bv c2UgdG9waWNzLg0KDQogICAgICAgICAg4oCUVG9tDQoNCg0KT24gT2N0IDIxLCAyMDE0OjU6MzIg UE0sIGF0IDU6MzIgUE0sIFN0ZXJuZSwgSmFzb24gKEphc29uKSA8amFzb24uc3Rlcm5lQGFsY2F0 ZWwtbHVjZW50LmNvbTxtYWlsdG86amFzb24uc3Rlcm5lQGFsY2F0ZWwtbHVjZW50LmNvbT4+IHdy b3RlOg0KDQpIaSBhbGwsDQoNCklzIHRoZXJlIGEgcHJlbGltaW5hcnkgYWdlbmRhIGZvciB0aGUg dHdvIE5FVE1PRCBzZXNzaW9ucyBhdCBJRVRGOTEgPw0KDQpTb21lIHRob3VnaHQgYWJvdXQgdG9w aWNzIGJlaW5nIHNwbGl0IGJldHdlZW4gdGhlIDFzdCAobG9uZ2VyKSBhbmQgMm5kIChzaG9ydGVy KSBzZXNzaW9ucyA/DQoNClRoYW5rcywNCkphc29uDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRtb2RAaWV0 Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbmV0bW9kDQoNCg== --_000_EF64FF31F4C4384DBCE5D513A791C2B120A55EB6xmbalnx11ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkhlbHZldGlj YTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAx MSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAu TXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2lu OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLmFwcGxlLXRhYi1zcGFuDQoJe21z by1zdHlsZS1uYW1lOmFwcGxlLXRhYi1zcGFuO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNl DQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5 bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWlu IDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkl0IG1pZ2h0IGFsc28gYmUgZ29vZCB0b3Agc3VtbWFyaXplIHRoZSBzZXQgb2Yg dG9waWNzIGJlbG93IGR1cmluZyB0aGUgaW50ZXJpbSBjYWxsIHRvbW9ycm93LiZuYnNwOyZuYnNw OyBUaGF0IHdvdWxkIHRlZSB1cCBleGFjdGx5IHdoYXQgY291bGQgYmUgb24gdGhlIHBsYXRlIGZv ciBIYXdhaWkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5FcmljPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gbmV0bW9kIFttYWls dG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkVyaWMgVm9p dCAoZXZvaXQpPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIE9jdG9iZXIgMjEsIDIwMTQgODow MCBQTTxicj4NCjxiPlRvOjwvYj4gVGhvbWFzIEQuIE5hZGVhdTsgbmV0bW9kQGlldGYub3JnPGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbmV0bW9kXSBJRVRGOTEgTkVUTU9EIGFnZW5kYSA/PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgd291bGQgbGlrZSB0byB0YWxrIGFib3V0 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LXZvaXQtbmV0bW9kLXBlZXItbW91bnQtcmVxdWlyZW1lbnRzLyI+aHR0cDovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC12b2l0LW5ldG1vZC1wZWVyLW1vdW50LXJlcXVpcmVt ZW50cy88L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPldlIGNoYXR0ZWQgYWJvdXQgdGhpcyBkb2N1bWVudCBpbiBhbiBJbnRlcmlt IGNhbGwgdHdvIHdlZWtzIGFnby4mbmJzcDsgVGhlIGludHJvIFBQVCBpcw0KPGEgaHJlZj0iaHR0 cDovL3d3dy52b2l0Lm9yZy9QZWVyLU1vdW50LU5ldGNvbmYtV0ctT2N0MjAxNC5wZGYiPmhlcmU8 L2E+LiAmbmJzcDtBIHJlc3VsdCBvZiB0aGUgY2FsbCB3YXMgdGhhdCB3ZSBoYWQgYSB3aWRlIHJh bmdpbmcgYWxpYXMgZGlzY3Vzc2lvbnMuJm5ic3A7IEEgcmV2aWV3IGluIEhhd2FpaSB3b3VsZCBh bGxvdyBhIHJlY2FwL3N1bW1hcnkgb2YgbWFpbGluZyBsaXN0IGRpc2N1c3Npb25zLCBhcyB3ZWxs IGFzIGFuIGludHJvZHVjdGlvbiB0byB0aGUNCiBjb25jZXB0cyB0byBvdGhlciBwYXJ0aWNpcGFu dHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5Ob3RlIHRoYXQgc2V2ZXJhbCBkaXNjdXNzaW9ucyBjYW1lIG91dCBvZiB0 aGUgY2FsbC4mbmJzcDsgRWFjaCBoYXMgaW1wbGljYXRpb25zIHRvIHBvc3NpYmxlIGNoYXJ0ZXJz IGFjcm9zcyB2YXJpb3VzIElFVEYgV0cuJm5ic3A7IFdvcnRoeSBvZiBkaXNjdXNzaW9uIGFyZTo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPi0gUkZDIDYyNDQgZGVmaW5lcyBhIHNpbmdsZS1ib3ggYXJjaGl0ZWN0dXJlLiZu YnNwOyBZQU5HIHN5bnRheCBpcyB1c2VkIGZvciBtdWx0aS1kZXZpY2UgYWJzdHJhY3Rpb25zIGlu IHRoZSBPcGVuRGF5bGlnaHQgY29udHJvbGxlci4mbmJzcDsgU2hvdWxkIHRoZSBJRVRGIGNvbnNp ZGVyIGFyY2hpdGVjdHVyZXMNCiB3aGVyZSBZQU5HIG1vZGVscyBzcGFuIGRldmljZXM/PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4tIFJGQyA1Mjc3IG9uIE5ldGNvbmYgbm90aWZpY2F0aW9ucyBkb2VzbuKAmXQgaW5jbHVk ZSBpbmZvcm1hdGlvbiBvbiBob3cgdG8gaGFuZGxlIFB1Yi9TdWIuJm5ic3A7IFRoZXJlIGlzIGFs c28gc29tZSBkZW1hbmQgZm9yIFB1Yi9TdWIgd2hpY2ggaXMgdGllZCB0byBZQU5HIHdpdGgNCiBu byByZXF1aXJlZCBsaW5rYWdlIHRvIGEgdHJhbnNwb3J0IHByb3RvY29sLiZuYnNwOyBUaGVyZSBh cmUgYWxzbyBuZWVkcyBmb3IgUHViL1N1YiBiZXlvbmQgWUFORy4mbmJzcDsgSG93IHNob3VsZCB3 ZSBhcHByb2FjaCB0aGlzIGFyZWE/ICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48YnI+DQpFcmljPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ IG5ldG1vZCBbPGEgaHJlZj0ibWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86 bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5UaG9tYXMg RC4gTmFkZWF1PGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIE9jdG9iZXIgMjEsIDIwMTQgNToz NCBQTTxicj4NCjxiPlRvOjwvYj4gU3Rlcm5lLCBKYXNvbiAoSmFzb24pPGJyPg0KPGI+Q2M6PC9i PiA8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIj5uZXRtb2RAaWV0Zi5vcmc8L2E+PGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbmV0bW9kXSBJRVRGOTEgTkVUTU9EIGFnZW5kYSA/PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFz cz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+Tm90IHlldC4gUGxlYXNlIHByb3Bvc2UgdG9waWNzLiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g Y2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPuKAlFRvbTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBPY3QgMjEsIDIwMTQ6NTozMiBQ TSwgYXQgNTozMiBQTSwgU3Rlcm5lLCBKYXNvbiAoSmFzb24pICZsdDs8YSBocmVmPSJtYWlsdG86 amFzb24uc3Rlcm5lQGFsY2F0ZWwtbHVjZW50LmNvbSI+amFzb24uc3Rlcm5lQGFsY2F0ZWwtbHVj ZW50LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5IaSBhbGwsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPklzIHRoZXJlIGEgcHJlbGltaW5hcnkgYWdlbmRhIGZvciB0aGUgdHdvIE5FVE1PRCBzZXNz aW9ucyBhdCBJRVRGOTEgPyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+U29tZSB0aG91Z2h0 IGFib3V0IHRvcGljcyBiZWluZyBzcGxpdCBiZXR3ZWVuIHRoZSAxPC9zcGFuPjxzdXA+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPnN0PC9zcGFuPjwvc3VwPjxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFu Pjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPihsb25nZXIpDQogYW5kIDI8L3Nw YW4+PHN1cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+bmQ8L3NwYW4+PC9zdXA+PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+KHNob3J0 ZXIpDQogc2Vzc2lvbnMgPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5KYXNvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KbmV0bW9kIG1haWxpbmcgbGlzdDxicj4NCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86bmV0bW9k QGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPm5ldG1vZEBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij48YnI+DQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9uZXRtb2QiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9uZXRtb2Q8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_EF64FF31F4C4384DBCE5D513A791C2B120A55EB6xmbalnx11ciscoc_-- --_004_EF64FF31F4C4384DBCE5D513A791C2B120A55EB6xmbalnx11ciscoc_ Content-Type: text/plain; name="ATT00002.txt" Content-Description: ATT00002.txt Content-Disposition: attachment; filename="ATT00002.txt"; size=133; creation-date="Tue, 21 Oct 2014 23:59:52 GMT"; modification-date="Tue, 21 Oct 2014 23:59:52 GMT" Content-ID: <97984BD49A555C4A8A2E98A955DD0047@emea.cisco.com> Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBt YWlsaW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9uZXRtb2QNCg== --_004_EF64FF31F4C4384DBCE5D513A791C2B120A55EB6xmbalnx11ciscoc_-- From nobody Wed Oct 22 04:29:54 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E55F1A901E for ; Wed, 22 Oct 2014 04:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 scxfu02RXx0F for ; Wed, 22 Oct 2014 04:29:50 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD6231A8F41 for ; Wed, 22 Oct 2014 04:29:49 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id E336E3247F9; Wed, 22 Oct 2014 13:29:47 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id C001E27C058; Wed, 22 Oct 2014 13:29:47 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.32]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0195.001; Wed, 22 Oct 2014 13:29:48 +0200 From: To: "Thomas D. Nadeau" , NETMOD Working Group Thread-Topic: [netmod] interim meeting: yang model focus Thread-Index: AQHP7XhH8G+WSW0okUyQ1+6kcE+zQ5w7++Uw Date: Wed, 22 Oct 2014 11:29:47 +0000 Message-ID: <1054_1413977387_5447952B_1054_8939_1_9E32478DFA9976438E7A22F69B08FF92142B21@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF92142B21OPEXCLILM34corpor_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.10.22.72121 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/z5ZWvBHciZzbq9H8fPAxliIO-G8 Subject: Re: [netmod] interim meeting: yang model focus X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2014 11:29:52 -0000 --_000_9E32478DFA9976438E7A22F69B08FF92142B21OPEXCLILM34corpor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tom, I will be available to present the updates on ISIS Yang draft. Thanks, From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Thomas D. Nadeau Sent: Tuesday, October 21, 2014 23:45 To: NETMOD Working Group Subject: [netmod] interim meeting: yang model focus Tomorrow's meeting will use the same WebEx from last time (and the = same as was used last week at the Yang 1.1-focused meeting). Tomorrow's interim meeting has the following preliminary agenda: 0) Quickly how to use IRC/sign-in 1) Note Well 2) Agenda Bashing 3) OSPF Model - Kiran Agrahara Sreenivasa >; myeung@cisco.com Are there any other models people wish to discuss? --Tom _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_9E32478DFA9976438E7A22F69B08FF92142B21OPEXCLILM34corpor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tom,=

 <= /p>

I will be available to pr= esent the updates on ISIS Yang draft.

 <= /p>

Thanks,=

 <= /p>

From: netmod [= mailto:netmod-bounces@ietf.org] On Behalf Of Thomas D. Nadeau
Sent: Tuesday, October 21, 2014 23:45
To: NETMOD Working Group
Subject: [netmod] interim meeting: yang model focus

 


        Tomorrow's meeting will use the = same WebEx from last time (and the same as was used last week at the Yang 1= .1-focused meeting).

        Tomorrow's interim meeting has t= he following preliminary agenda:

        0) Quickly how to use IRC/sign-i= n
        1) Note Well
        2) Agenda Bashing
        3) OSPF Model - Kiran Agrahara S= reenivasa <kkoushik@Brocade.com<= /a>>; myeung@cisco.com
       

        Are there any other models peopl= e wish to discuss?

        --Tom

___________________= ____________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.o= rg/mailman/listinfo/netmod

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_9E32478DFA9976438E7A22F69B08FF92142B21OPEXCLILM34corpor_-- From nobody Wed Oct 22 06:16:30 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEA381A911E; Wed, 22 Oct 2014 06:16:26 -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 pAMYSATCRzNC; Wed, 22 Oct 2014 06:16:24 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B52421A910A; Wed, 22 Oct 2014 06:16:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=428; q=dns/txt; s=iport; t=1413983785; x=1415193385; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=u9wWo45R3JRwOH0P05iEfoAMP61Hm75EM/cSTdMBM48=; b=j0qdwsJdNg3NdJYtf+D0Eu13XfV0TySHRiVlxxf/FXgbiQx3gIQ2TpMR YzpyhP9zGIfeqg0sT7yKxB9qJlAlajPQdWkE+ubgFQDreiZHD3+VSUyNc bUe0XN9KQnPiWYg9rFOu8/4kgHalRY1NzugMB1LmT1Th/zd2t/0ecJLQq M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFACqtR1StJA2L/2dsb2JhbABcgw7VUAqBDhYBfYRBQAE8FhgDAgECAUsBDAEHAQGIPMYSAQEBAQEBAQEBAQEBAQEBAQEbkFeEUgEEi2OReodsjj6EGB2BNQSBQQEBAQ X-IronPort-AV: E=Sophos;i="5.04,769,1406592000"; d="scan'208";a="89332636" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-7.cisco.com with ESMTP; 22 Oct 2014 13:16:24 +0000 Received: from [10.21.92.197] (sjc-vpn5-1221.cisco.com [10.21.92.197]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s9MDGN15015057; Wed, 22 Oct 2014 13:16:23 GMT Message-ID: <5447AE27.7060408@cisco.com> Date: Wed, 22 Oct 2014 06:16:23 -0700 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: NETMOD Working Group , Rtg-yang-coord@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/PPWRwsYbqnTe-snk4hysa08g1Sk Cc: "ops-ads@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: [netmod] NETMOD interim meeting canceled X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2014 13:16:27 -0000 Dear all, Today NETMOD interim meeting is canceled. I received some pushbacks from the routing ADs, on the ground that: 1. This interim appears to be meeting to discuss a non-WG draft for which there is no milestone in the working group and for which there is an obvious home outside the working group. 2. The agenda was not announced a week in advance on the IETF announce list as is required Regards, Benoit From nobody Wed Oct 22 06:29:33 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72F151A8AD7; Wed, 22 Oct 2014 06:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 wp6Uxh4BV2Rh; Wed, 22 Oct 2014 06:29:28 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id B3BE51A90E3; Wed, 22 Oct 2014 06:29:28 -0700 (PDT) Received: from [192.168.1.123] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id E6BA228D0736; Wed, 22 Oct 2014 09:29:27 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: "Thomas D. Nadeau" In-Reply-To: <5447AE27.7060408@cisco.com> Date: Wed, 22 Oct 2014 09:29:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> References: <5447AE27.7060408@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/FYpEl1JPDfFSGH5vfyHJrpZqL64 Cc: Rtg-yang-coord@ietf.org, "ops-ads@tools.ietf.org" , NETMOD Working Group , "rtg-ads@tools.ietf.org" Subject: Re: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2014 13:29:30 -0000 This is hugely disappointing. This is the kind of procedural = non-sense has and IS driving people away from the IETF to other places = where this work is going to get done. The simple effect of such = silliness will be a reduction in speed and quantity of model = development. If the goal of the IESG is to slow down the velocity of = model development and creation, then this approach is perfect. For the record, the interim NETMOD meeting cadence has one = meeting focused on Yang and the other on modeling; is not = NETMOD-specific per say, but to promote model creation because no other = bi-weekly forum exists to do so. It is also a place to bring in non-IETF = work such as the work done in ODL, other open source, or just the public = community that has explicitly wanted to avoid the IETF. We have found = it a convenient and fruitful place to discuss, and actually *build* = models - regardless of their ultimate WG home. The simple reason: its a = single place for many of the experts to gather. I think you will find it = very difficult to get those people onto a per-WG call every other week. =20= I hope the IESG considers this approach carefully because I do = not think it will have the affect the larger IETF community is = interested in. --Tom > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise = wrote: >=20 > Dear all, >=20 > Today NETMOD interim meeting is canceled. >=20 > I received some pushbacks from the routing ADs, on the ground that: > 1. This interim appears to be meeting to discuss a non-WG draft for = which there is no milestone in the working group and for which there is = an obvious home outside the working group. > 2. The agenda was not announced a week in advance on the IETF announce = list as is required >=20 > Regards, Benoit >=20 > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord >=20 From nobody Wed Oct 22 06:30:01 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B73FB1A9143 for ; Wed, 22 Oct 2014 06:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 6HRLvb_plnVH for ; Wed, 22 Oct 2014 06:29:51 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71D991A8AD7 for ; Wed, 22 Oct 2014 06:29:50 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id 77B54C1DFCA94; Wed, 22 Oct 2014 13:29:47 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s9MDTmNY014332 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Oct 2014 09:29:49 -0400 Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.170]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Wed, 22 Oct 2014 09:29:47 -0400 From: "Sterne, Jason (Jason)" To: "Thomas D. Nadeau" Thread-Topic: [netmod] IETF91 NETMOD agenda ? Thread-Index: Ac/tdoGexyGw623TR4igNJSWn+KnzAAIc0yAABjQLNA= Date: Wed, 22 Oct 2014 13:29:47 +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.18] Content-Type: multipart/alternative; boundary="_000_A125E53CE190A749957C19483DC79F9F5C9785ABUS70TWXCHMBA11z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/NYfIoYkgPoeYk1Dlx2TmeZxDLbM Cc: "netmod@ietf.org" Subject: Re: [netmod] IETF91 NETMOD 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, 22 Oct 2014 13:29:53 -0000 --_000_A125E53CE190A749957C19483DC79F9F5C9785ABUS70TWXCHMBA11z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T25lIGl0ZW0gdGhhdCBtaWdodCBiZSB1c2VmdWw6DQoNCg0KLSAgICAgICAgICDigJxEZXNpZ24g VGVhbXPigJ0gdXBkYXRlOg0KDQpvICAgTGlzdCBvZiBhbGwga25vd24g4oCcZGVzaWduIHRlYW1z 4oCdIHRoYXQgYXJlIHdvcmtpbmcgb24gWUFORyBtb2RlbHMgKGVzcGVjaWFsbHkgb25lcyB0aGF0 IG1heSBiZSBwcm9ncmVzc2luZyBvdXRzaWRlIG9mIHRoZSBJRVRGIG1haWxpbmcgbGlzdHMpDQoN Cm8gICBJZGVhbGx5IGEgYnJpZWYgc3RhdHVzIHVwZGF0ZSBmcm9tIG9uZSBvZiB0aGUgcHJpbWFy eSBsZWFkZXJzL2NvbnRyaWJ1dG9ycyAoaS5lLiBhIGZldyBidWxsZXQgcG9pbnRzIC8gMS0yIG1p bnV0ZXMpIGZvciBlYWNoIG9uZSAobm90IHRvIGRpc2N1c3MgdGhlIHRlY2huaWNhbCBkZXRhaWxz IG9mIHNwZWNpZmljIG1vZGVscyDigJMgdGhhdCBjb3VsZCBiZSBvdGhlciBhZ2VuZGEgaXRlbXMp DQoNClJlZ2FyZHMsDQpKYXNvbg0KDQpGcm9tOiBUaG9tYXMgRC4gTmFkZWF1IFttYWlsdG86dG5h ZGVhdUBsdWNpZHZpc2lvbi5jb21dDQpTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDIxLCAyMDE0IDU6 MzQgUE0NClRvOiBTdGVybmUsIEphc29uIChKYXNvbikNCkNjOiBuZXRtb2RAaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBbbmV0bW9kXSBJRVRGOTEgTkVUTU9EIGFnZW5kYSA/DQoNCg0KICAgICAgICAg ICAgTm90IHlldC4gUGxlYXNlIHByb3Bvc2UgdG9waWNzLg0KDQogICAgICAgICAgICDigJRUb20N Cg0KDQpPbiBPY3QgMjEsIDIwMTQ6NTozMiBQTSwgYXQgNTozMiBQTSwgU3Rlcm5lLCBKYXNvbiAo SmFzb24pIDxqYXNvbi5zdGVybmVAYWxjYXRlbC1sdWNlbnQuY29tPG1haWx0bzpqYXNvbi5zdGVy bmVAYWxjYXRlbC1sdWNlbnQuY29tPj4gd3JvdGU6DQoNCkhpIGFsbCwNCg0KSXMgdGhlcmUgYSBw cmVsaW1pbmFyeSBhZ2VuZGEgZm9yIHRoZSB0d28gTkVUTU9EIHNlc3Npb25zIGF0IElFVEY5MSA/ DQoNClNvbWUgdGhvdWdodCBhYm91dCB0b3BpY3MgYmVpbmcgc3BsaXQgYmV0d2VlbiB0aGUgMXN0 IChsb25nZXIpIGFuZCAybmQgKHNob3J0ZXIpIHNlc3Npb25zID8NCg0KVGhhbmtzLA0KSmFzb24N Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1v ZCBtYWlsaW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0K --_000_A125E53CE190A749957C19483DC79F9F5C9785ABUS70TWXCHMBA11z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkhlbHZldGlj YTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1 IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3Nl LTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhv bWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlv bnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2lu OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwg ZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10 b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2lu LWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uYXBwbGUtdGFi LXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtdGFiLXNwYW47fQ0Kc3Bhbi5hcHBsZS1jb252 ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNw YW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDox ODczMzAzMTcyOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlk czotNzA5ODU2MjI4IC03NzgwMTE0NjYgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2 OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwx DQoJe21zby1sZXZlbC1zdGFydC1hdDoyMDM4Ow0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1mb250LWZhbWls eTpDYWxpYnJpO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwN Cgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5PbmUgaXRlbSB0aGF0IG1pZ2h0IGJlIHVzZWZ1bDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm bzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZv bnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFu PjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+4oCc RGVzaWduIFRlYW1z4oCdIHVwZGF0ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluO3RleHQtaW5kZW50Oi0u MjVpbjttc28tbGlzdDpsMCBsZXZlbDIgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5vPHNwYW4g c3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJz cDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+TGlzdCBvZiBhbGwga25vd24g4oCcZGVzaWduIHRlYW1z4oCd IHRoYXQgYXJlIHdvcmtpbmcgb24gWUFORyBtb2RlbHMgKGVzcGVjaWFsbHkgb25lcyB0aGF0IG1h eSBiZSBwcm9ncmVzc2luZyBvdXRzaWRlIG9mIHRoZSBJRVRGIG1haWxpbmcgbGlzdHMpPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJn aW4tbGVmdDoxLjBpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzEi Pg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5 bGU9Im1zby1saXN0Oklnbm9yZSI+bzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtl bmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklkZWFsbHkg YSBicmllZiBzdGF0dXMgdXBkYXRlIGZyb20gb25lIG9mIHRoZSBwcmltYXJ5IGxlYWRlcnMvY29u dHJpYnV0b3JzIChpLmUuIGEgZmV3IGJ1bGxldCBwb2ludHMgLyAxLTIgbWludXRlcykgZm9yIGVh Y2ggb25lIChub3QgdG8gZGlzY3VzcyB0aGUNCiB0ZWNobmljYWwgZGV0YWlscyBvZiBzcGVjaWZp YyBtb2RlbHMg4oCTIHRoYXQgY291bGQgYmUgb3RoZXIgYWdlbmRhIGl0ZW1zKTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SmFzb248bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiBUaG9tYXMgRC4gTmFkZWF1IFttYWlsdG86dG5hZGVhdUBsdWNpZHZpc2lvbi5jb21d DQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgT2N0b2JlciAyMSwgMjAxNCA1OjM0IFBNPGJy Pg0KPGI+VG86PC9iPiBTdGVybmUsIEphc29uIChKYXNvbik8YnI+DQo8Yj5DYzo8L2I+IG5ldG1v ZEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW25ldG1vZF0gSUVURjkxIE5FVE1P RCBhZ2VuZGEgPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPk5vdCB5ZXQu IFBsZWFzZSBwcm9wb3NlIHRvcGljcy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDwvc3Bhbj7igJRUb208bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gT2N0IDIxLCAyMDE0OjU6MzIgUE0sIGF0IDU6MzIgUE0sIFN0ZXJu ZSwgSmFzb24gKEphc29uKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmphc29uLnN0ZXJuZUBhbGNhdGVs LWx1Y2VudC5jb20iPmphc29uLnN0ZXJuZUBhbGNhdGVsLWx1Y2VudC5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+SGkgYWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JcyB0aGVyZSBhIHByZWxp bWluYXJ5IGFnZW5kYSBmb3IgdGhlIHR3byBORVRNT0Qgc2Vzc2lvbnMgYXQgSUVURjkxID8mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlNvbWUgdGhvdWdodCBhYm91dCB0b3BpY3MgYmVpbmcg c3BsaXQgYmV0d2VlbiB0aGUgMTwvc3Bhbj48c3VwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5zdDwvc3Bhbj48L3N1cD48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4obG9uZ2VyKQ0KIGFuZCAyPC9zcGFuPjxzdXA+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPm5kPC9zcGFuPjwvc3VwPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPihzaG9ydGVyKQ0KIHNlc3Npb25zID88bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SmFzb248bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm5ldG1vZCBtYWlsaW5nIGxp c3Q8YnI+DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5uZXRtb2RAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPC9zcGFu PjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9k PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_A125E53CE190A749957C19483DC79F9F5C9785ABUS70TWXCHMBA11z_-- From nobody Wed Oct 22 06:34:49 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F27741A916E for ; Wed, 22 Oct 2014 06:34:45 -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, 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 9iKb6HUzVyKw for ; Wed, 22 Oct 2014 06:34:42 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1191A9174 for ; Wed, 22 Oct 2014 06:34:40 -0700 (PDT) Received: from [192.168.1.123] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id AAEC228D078B; Wed, 22 Oct 2014 09:34:39 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_E5160FB6-4AF9-499B-A132-CEAD6F526A29" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: "Thomas D. Nadeau" In-Reply-To: Date: Wed, 22 Oct 2014 09:34:39 -0400 Message-Id: <7AE50968-A834-4CA8-BC95-95253322E45B@lucidvision.com> References: To: "Sterne, Jason (Jason)" X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/AGj1BbzLEXufZEO9ybrHiw-Dfgc Cc: "netmod@ietf.org" Subject: Re: [netmod] IETF91 NETMOD 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, 22 Oct 2014 13:34:46 -0000 --Apple-Mail=_E5160FB6-4AF9-499B-A132-CEAD6F526A29 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Meeting is canceled. See previous note from Benoit.=20 =E2=80=94Tom > On Oct 22, 2014:9:29 AM, at 9:29 AM, Sterne, Jason (Jason) = wrote: >=20 > One item that might be useful: > =20 > - =E2=80=9CDesign Teams=E2=80=9D update: > o List of all known =E2=80=9Cdesign teams=E2=80=9D that are working = on YANG models (especially ones that may be progressing outside of the = IETF mailing lists) > o Ideally a brief status update from one of the primary = leaders/contributors (i.e. a few bullet points / 1-2 minutes) for each = one (not to discuss the technical details of specific models =E2=80=93 = that could be other agenda items) > =20 > Regards, > Jason > =20 > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com = ]=20 > Sent: Tuesday, October 21, 2014 5:34 PM > To: Sterne, Jason (Jason) > Cc: netmod@ietf.org > Subject: Re: [netmod] IETF91 NETMOD agenda ? > =20 > =20 > Not yet. Please propose topics.=20 > =20 > =E2=80=94Tom > =20 > =20 > On Oct 21, 2014:5:32 PM, at 5:32 PM, Sterne, Jason (Jason) = > wrote: > =20 > Hi all, > =20 > Is there a preliminary agenda for the two NETMOD sessions at IETF91 ? = =20 > =20 > Some thought about topics being split between the 1st (longer) and 2nd = (shorter) sessions ? > =20 > Thanks, > Jason > =20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod = --Apple-Mail=_E5160FB6-4AF9-499B-A132-CEAD6F526A29 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Meeting = is canceled. See previous note from Benoit. 

=E2=80=94Tom


On = Oct 22, 2014:9:29 AM, at 9:29 AM, Sterne, Jason (Jason) <jason.sterne@alcatel-lucent.com> wrote:

One item that might be useful:
 
-          =E2=80=9CDesign Teams=E2=80=9D update:
o   List of all known =E2=80=9Cdesign teams=E2=80= =9D that are working on YANG models (especially ones that may be = progressing outside of the IETF mailing lists)
o   Ideally a brief status update from one of = the primary leaders/contributors (i.e. a few bullet points / 1-2 = minutes) for each one (not to discuss the technical details of specific = models =E2=80=93 that could be other agenda items)
 
Regards,
Jason
 
From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com] 
Sent: Tuesday, October 21, 2014 = 5:34 PM
To: Sterne, Jason (Jason)
Cc: netmod@ietf.org
Subject: Re: [netmod] IETF91 NETMOD = agenda ?
 
 
        &= nbsp;   Not yet. Please = propose topics. 
 
        &= nbsp;   =E2=80=94Tom
 
 
On = Oct 21, 2014:5:32 PM, at 5:32 PM, Sterne, Jason (Jason) <jason.sterne@alcatel-lucent.com> wrote:
 
Hi all,
 
Is there a preliminary agenda for the two NETMOD = sessions at IETF91 ?     
 
Some thought about topics being split between = the 1st (longer) and 2nd (shorter) sessions ?
 
Thanks,
Jason
 
_______________________________________________netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

= --Apple-Mail=_E5160FB6-4AF9-499B-A132-CEAD6F526A29-- From nobody Wed Oct 22 06:42:51 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDC651A8BC4 for ; Wed, 22 Oct 2014 06:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 fcdpGDNIJFYk for ; Wed, 22 Oct 2014 06:42:46 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (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 3CB711A9235 for ; Wed, 22 Oct 2014 06:42:44 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 9C52375C8E8F6; Wed, 22 Oct 2014 13:42:41 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s9MDggxC020103 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Oct 2014 09:42:43 -0400 Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.170]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Wed, 22 Oct 2014 09:42:43 -0400 From: "Sterne, Jason (Jason)" To: "Thomas D. Nadeau" Thread-Topic: [netmod] IETF91 NETMOD agenda ? Thread-Index: Ac/tdoGexyGw623TR4igNJSWn+KnzAAIc0yAABjQLNAACLlIgAAIIG9A Date: Wed, 22 Oct 2014 13:42:42 +0000 Message-ID: References: <7AE50968-A834-4CA8-BC95-95253322E45B@lucidvision.com> In-Reply-To: <7AE50968-A834-4CA8-BC95-95253322E45B@lucidvision.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_A125E53CE190A749957C19483DC79F9F5C978655US70TWXCHMBA11z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/jVLC1GaI0sK5dPRLDu_NjkXqLV0 Cc: "netmod@ietf.org" Subject: Re: [netmod] IETF91 NETMOD 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, 22 Oct 2014 13:42:49 -0000 --_000_A125E53CE190A749957C19483DC79F9F5C978655US70TWXCHMBA11z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBlbWFpbCB0aHJlYWQgSSBzdGFydGVkIGlzIGFib3V0IHRoZSBJRVRGOTEgTkVUTU9EIG1l ZXRpbmdzIChub3QgdGhlIGludGVyaW0gbWVldGluZykuDQoNCkZyb206IFRob21hcyBELiBOYWRl YXUgW21haWx0bzp0bmFkZWF1QGx1Y2lkdmlzaW9uLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgT2N0 b2JlciAyMiwgMjAxNCA5OjM1IEFNDQpUbzogU3Rlcm5lLCBKYXNvbiAoSmFzb24pDQpDYzogbmV0 bW9kQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW25ldG1vZF0gSUVURjkxIE5FVE1PRCBhZ2VuZGEg Pw0KDQoNCiAgICAgICAgICAgIE1lZXRpbmcgaXMgY2FuY2VsZWQuIFNlZSBwcmV2aW91cyBub3Rl IGZyb20gQmVub2l0Lg0KDQogICAgICAgICAgICDigJRUb20NCg0KDQpPbiBPY3QgMjIsIDIwMTQ6 OToyOSBBTSwgYXQgOToyOSBBTSwgU3Rlcm5lLCBKYXNvbiAoSmFzb24pIDxqYXNvbi5zdGVybmVA YWxjYXRlbC1sdWNlbnQuY29tPG1haWx0bzpqYXNvbi5zdGVybmVAYWxjYXRlbC1sdWNlbnQuY29t Pj4gd3JvdGU6DQoNCk9uZSBpdGVtIHRoYXQgbWlnaHQgYmUgdXNlZnVsOg0KDQotICAgICAgICAg IOKAnERlc2lnbiBUZWFtc+KAnSB1cGRhdGU6DQpvICAgTGlzdCBvZiBhbGwga25vd24g4oCcZGVz aWduIHRlYW1z4oCdIHRoYXQgYXJlIHdvcmtpbmcgb24gWUFORyBtb2RlbHMgKGVzcGVjaWFsbHkg b25lcyB0aGF0IG1heSBiZSBwcm9ncmVzc2luZyBvdXRzaWRlIG9mIHRoZSBJRVRGIG1haWxpbmcg bGlzdHMpDQpvICAgSWRlYWxseSBhIGJyaWVmIHN0YXR1cyB1cGRhdGUgZnJvbSBvbmUgb2YgdGhl IHByaW1hcnkgbGVhZGVycy9jb250cmlidXRvcnMgKGkuZS4gYSBmZXcgYnVsbGV0IHBvaW50cyAv IDEtMiBtaW51dGVzKSBmb3IgZWFjaCBvbmUgKG5vdCB0byBkaXNjdXNzIHRoZSB0ZWNobmljYWwg ZGV0YWlscyBvZiBzcGVjaWZpYyBtb2RlbHMg4oCTIHRoYXQgY291bGQgYmUgb3RoZXIgYWdlbmRh IGl0ZW1zKQ0KDQpSZWdhcmRzLA0KSmFzb24NCg0KRnJvbTogVGhvbWFzIEQuIE5hZGVhdSBbbWFp bHRvOnRuYWRlYXVAbHVjaWR2aXNpb24uY29tXQ0KU2VudDogVHVlc2RheSwgT2N0b2JlciAyMSwg MjAxNCA1OjM0IFBNDQpUbzogU3Rlcm5lLCBKYXNvbiAoSmFzb24pDQpDYzogbmV0bW9kQGlldGYu b3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW25ldG1vZF0gSUVURjkx IE5FVE1PRCBhZ2VuZGEgPw0KDQoNCiAgICAgICAgICAgIE5vdCB5ZXQuIFBsZWFzZSBwcm9wb3Nl IHRvcGljcy4NCg0KICAgICAgICAgICAg4oCUVG9tDQoNCg0KT24gT2N0IDIxLCAyMDE0OjU6MzIg UE0sIGF0IDU6MzIgUE0sIFN0ZXJuZSwgSmFzb24gKEphc29uKSA8amFzb24uc3Rlcm5lQGFsY2F0 ZWwtbHVjZW50LmNvbTxtYWlsdG86amFzb24uc3Rlcm5lQGFsY2F0ZWwtbHVjZW50LmNvbT4+IHdy b3RlOg0KDQpIaSBhbGwsDQoNCklzIHRoZXJlIGEgcHJlbGltaW5hcnkgYWdlbmRhIGZvciB0aGUg dHdvIE5FVE1PRCBzZXNzaW9ucyBhdCBJRVRGOTEgPw0KDQpTb21lIHRob3VnaHQgYWJvdXQgdG9w aWNzIGJlaW5nIHNwbGl0IGJldHdlZW4gdGhlIDFzdCAobG9uZ2VyKSBhbmQgMm5kIChzaG9ydGVy KSBzZXNzaW9ucyA/DQoNClRoYW5rcywNCkphc29uDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRtb2RAaWV0 Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbmV0bW9kDQoNCg== --_000_A125E53CE190A749957C19483DC79F9F5C978655US70TWXCHMBA11z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkhlbHZldGlj YTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIg MiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0x OjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05v cm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1h cmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglm b250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5hcHBsZS10YWItc3Bhbg0K CXttc28tc3R5bGUtbmFtZTphcHBsZS10YWItc3Bhbjt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1z cGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRl eHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoaXMgZW1haWwgdGhyZWFkIEkgc3RhcnRlZCBpcyBh Ym91dCB0aGUgSUVURjkxIE5FVE1PRCBtZWV0aW5ncyAobm90IHRoZSBpbnRlcmltIG1lZXRpbmcp LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFRob21hcyBELiBOYWRlYXUgW21haWx0bzp0bmFkZWF1QGx1 Y2lkdmlzaW9uLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE9jdG9iZXIgMjIs IDIwMTQgOTozNSBBTTxicj4NCjxiPlRvOjwvYj4gU3Rlcm5lLCBKYXNvbiAoSmFzb24pPGJyPg0K PGI+Q2M6PC9iPiBuZXRtb2RAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtuZXRt b2RdIElFVEY5MSBORVRNT0QgYWdlbmRhID88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDwvc3Bhbj5NZWV0aW5nIGlzIGNhbmNlbGVkLiBTZWUgcHJldmlvdXMgbm90ZSBmcm9tIEJlbm9p dC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj7igJRUb208bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gT2N0 IDIyLCAyMDE0Ojk6MjkgQU0sIGF0IDk6MjkgQU0sIFN0ZXJuZSwgSmFzb24gKEphc29uKSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmphc29uLnN0ZXJuZUBhbGNhdGVsLWx1Y2VudC5jb20iPmphc29uLnN0 ZXJuZUBhbGNhdGVsLWx1Y2VudC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5PbmUgaXRlbSB0aGF0IG1pZ2h0IGJlIHVzZWZ1bDo8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW4iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4w cHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ 4oCcRGVzaWduDQogVGVhbXPigJ0gdXBkYXRlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+bzwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNw OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkxpc3QNCiBvZiBhbGwg a25vd24g4oCcZGVzaWduIHRlYW1z4oCdIHRoYXQgYXJlIHdvcmtpbmcgb24gWUFORyBtb2RlbHMg KGVzcGVjaWFsbHkgb25lcyB0aGF0IG1heSBiZSBwcm9ncmVzc2luZyBvdXRzaWRlIG9mIHRoZSBJ RVRGIG1haWxpbmcgbGlzdHMpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4 dC1pbmRlbnQ6LS4yNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5vPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SWRlYWxseQ0KIGEgYnJpZWYgc3RhdHVz IHVwZGF0ZSBmcm9tIG9uZSBvZiB0aGUgcHJpbWFyeSBsZWFkZXJzL2NvbnRyaWJ1dG9ycyAoaS5l LiBhIGZldyBidWxsZXQgcG9pbnRzIC8gMS0yIG1pbnV0ZXMpIGZvciBlYWNoIG9uZSAobm90IHRv IGRpc2N1c3MgdGhlIHRlY2huaWNhbCBkZXRhaWxzIG9mIHNwZWNpZmljIG1vZGVscyDigJMgdGhh dCBjb3VsZCBiZSBvdGhlciBhZ2VuZGEgaXRlbXMpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5SZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5KYXNvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFu Pjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhvbWFzDQogRC4gTmFkZWF1IFs8 YSBocmVmPSJtYWlsdG86dG5hZGVhdUBsdWNpZHZpc2lvbi5jb20iPjxzcGFuIHN0eWxlPSJjb2xv cjpwdXJwbGUiPm1haWx0bzp0bmFkZWF1QGx1Y2lkdmlzaW9uLmNvbTwvc3Bhbj48L2E+XTxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8Yj5TZW50 OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+VHVl c2RheSwgT2N0b2JlciAyMSwgMjAxNCA1OjM0IFBNPGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5TdGVybmUsIEphc29uIChKYXNv bik8YnI+DQo8Yj5DYzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJj b2xvcjpwdXJwbGUiPm5ldG1vZEBpZXRmLm9yZzwvc3Bhbj48L2E+PGJyPg0KPGI+U3ViamVjdDo8 L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBb bmV0bW9kXSBJRVRGOTEgTkVUTU9EIGFnZW5kYSA/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Tm90IHlldC4g UGxlYXNlIHByb3Bvc2UgdG9waWNzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xh c3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPuKAlFRvbTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBPY3QgMjEsIDIwMTQ6NTozMiBQTSwgYXQgNTozMiBQ TSwgU3Rlcm5lLCBKYXNvbiAoSmFzb24pICZsdDs8YSBocmVmPSJtYWlsdG86amFzb24uc3Rlcm5l QGFsY2F0ZWwtbHVjZW50LmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+amFzb24uc3Rl cm5lQGFsY2F0ZWwtbHVjZW50LmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SGkgYWxsLDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JcyB0aGVyZSBhIHByZWxpbWluYXJ5IGFnZW5k YSBmb3IgdGhlIHR3byBORVRNT0Qgc2Vzc2lvbnMgYXQgSUVURjkxID8mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlNvbWUgdGhvdWdodCBh Ym91dCB0b3BpY3MgYmVpbmcgc3BsaXQgYmV0d2VlbiB0aGUgMTwvc3Bhbj48c3VwPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5zdDwvc3Bhbj48L3N1cD48c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4obG9uZ2VyKQ0KIGFuZCAyPC9zcGFu PjxzdXA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPm5kPC9zcGFuPjwvc3VwPjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPihzaG9ydGVy KQ0KIHNlc3Npb25zID88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ VGhhbmtzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SmFz b248L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCm5ldG1vZCBtYWlsaW5nIGxpc3Q8YnI+DQo8L3NwYW4+PGEgaHJl Zj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnB1cnBsZSI+bmV0 bW9kQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCjwvc3Bhbj48YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u ZXRtb2Q8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_A125E53CE190A749957C19483DC79F9F5C978655US70TWXCHMBA11z_-- From nobody Wed Oct 22 06:44:59 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DACB11A9039; Wed, 22 Oct 2014 06:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 uvkDDUT4mZsT; Wed, 22 Oct 2014 06:44:56 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 374D81A8BC4; Wed, 22 Oct 2014 06:44:56 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 47D67264163; Wed, 22 Oct 2014 15:44:54 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.30]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 2329527C080; Wed, 22 Oct 2014 15:44:54 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.32]) by OPEXCLILH02.corporate.adroot.infra.ftgroup ([10.114.31.30]) with mapi id 14.03.0195.001; Wed, 22 Oct 2014 15:44:53 +0200 From: To: Benoit Claise Thread-Topic: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled Thread-Index: AQHP7fw5+PxAzPUz9k62C+BUuKxA2pw8HYRg Date: Wed, 22 Oct 2014 13:44:54 +0000 Message-ID: <19590_1413985494_5447B4D6_19590_2565_1_9E32478DFA9976438E7A22F69B08FF92142C87@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> In-Reply-To: <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.10.22.123024 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/cY6Mh8dn7hlZ9dNi4BUyZGyrlZU Cc: "Rtg-yang-coord@ietf.org" , "ops-ads@tools.ietf.org" , NETMOD Working Group , "rtg-ads@tools.ietf.org" Subject: Re: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2014 13:44:59 -0000 Hi, I also agree that this is a bad idea. I thought that IETF willing and espec= ially yours, Benoit, was to speed up availability of standard models. The p= rocess of having small teams working with weekly calls works almost good bu= t we still have some issue that are both technical (dedicated to the topic = addressed by the model) and also YANG writing, model consistencies ... that= requires discussion, and as often mailing list is not as good as meetings = (that's why the proposal of small teams was done). At the present time, I personally support the initiative of having interim = meetings in Netmod to discuss proposed Yang models : this will ensure consi= stency between models and will help to solve global issues in modeling. It'= s just the starting of Yang modeling, leaving only Yang models within home = WG (ISIS for my point of view) would be, IMO, a very bad idea and will for = sure slow down the availability of standards ... and I also think that it m= ay discourage people to work on because of the added overhead. It was just my opinion ... Best Regards, Stephane -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Thomas D. Nadeau Sent: Wednesday, October 22, 2014 15:29 To: Benoit Claise Cc: Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org; NETMOD Working Group; = rtg-ads@tools.ietf.org Subject: Re: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled This is hugely disappointing. This is the kind of procedural non-sense has= and IS driving people away from the IETF to other places where this work i= s going to get done. The simple effect of such silliness will be a reductio= n in speed and quantity of model development. If the goal of the IESG is t= o slow down the velocity of model development and creation, then this appro= ach is perfect. For the record, the interim NETMOD meeting cadence has one meeting focused= on Yang and the other on modeling; is not NETMOD-specific per say, but to = promote model creation because no other bi-weekly forum exists to do so. It= is also a place to bring in non-IETF work such as the work done in ODL, ot= her open source, or just the public community that has explicitly wanted to= avoid the IETF. We have found it a convenient and fruitful place to discu= ss, and actually *build* models - regardless of their ultimate WG home. Th= e simple reason: its a single place for many of the experts to gather. I th= ink you will find it very difficult to get those people onto a per-WG call = every other week.=20=20 I hope the IESG considers this approach carefully because I do not think i= t will have the affect the larger IETF community is interested in. --Tom > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise wr= ote: >=20 > Dear all, >=20 > Today NETMOD interim meeting is canceled. >=20 > I received some pushbacks from the routing ADs, on the ground that: > 1. This interim appears to be meeting to discuss a non-WG draft for which= there is no milestone in the working group and for which there is an obvio= us home outside the working group. > 2. The agenda was not announced a week in advance on the IETF announce li= st as is required >=20 > Regards, Benoit >=20 > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord >=20 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Oct 22 06:49:08 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A733B1A9022; Wed, 22 Oct 2014 06:49:06 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 SWYW6QFDBxQz; Wed, 22 Oct 2014 06:49:04 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F1471A9239; Wed, 22 Oct 2014 06:49:04 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s9MDmxwp030789; Wed, 22 Oct 2014 14:48:59 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s9MDmuBm030779 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 22 Oct 2014 14:48:57 +0100 From: "Adrian Farrel" To: "'Thomas D. Nadeau'" , "'Benoit Claise'" References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> In-Reply-To: <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> Date: Wed, 22 Oct 2014 14:48:56 +0100 Message-ID: <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIUX+ca9u4QKYuEX+hUMOEGGRuotgIuz+Vem6HEYOA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21042.006 X-TM-AS-Result: No--21.041-10.0-31-10 X-imss-scan-details: No--21.041-10.0-31-10 X-TMASE-MatchedRID: nI1cAR4k0HZCl9DEsHnSbVCi/xDHcDzf1kqyrcMalqVtgXN8SPjcGGhd vY2T9l+XVlPFrbdk9/QPu5VZvLINUsEElERnDJHCCFaAixm5eU/a7t0rt6KkQIie9XwPLRloGuv VcHRvn/zgTGfgubR6iKn9Hj5RZR6NCGqH67UhpHvDr0AjBcmfRt78NWlYojkrDpCUEeEFm7AlHD ysIsZQz/XwMuTsz/9TJYuIh9de7fnmH394WLwaPR3EEAbn+GRbNRv92EahEcGae6AcsiK/zUZqp KN3I/kCK5+n7D4m+weVeaEgHjNmGNcUNjoF7YuV+8AO9OcJ/m/429XtOfGeyrV5fSMRD1zqTQGT kMztYqWf3LpnL91w/JV+NZ72RHta4VtgA8SfpXlHpZCc205uwvi4nVERfgwduRjdZTD8Hxe9E+y WHMdHvHhlnpztBZmn0mOrCP/UIvFgVCr5L5DCrvAjkTMkRNNUfjJOgArMOCbvHbNVSAW5oAi9cm FBBPB+wEzzkYmyTN6qvXEQxA2/V0yHw6z9MyJZz4XVyhFFZHKbKpAlY2y6ScnaL1ri/ilX2zUIf ORoaiIRW3Fo+hK3sB5hmP6OM/PJTX7PJ/OU3vL+xOhjarOnHrHlqZYrZqdI+gtHj7OwNO0CpgET eT0ynA== Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Dba46h7SbwibL5eeTFn5zmXG6Cw Cc: Rtg-yang-coord@ietf.org, ospf-chairs@tools.ietf.org, ops-ads@tools.ietf.org, 'NETMOD Working Group' , rtg-ads@tools.ietf.org Subject: Re: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 13:49:07 -0000 I understand and appreciate your desire to get work done. The rules for IETF virtual interims are neither hard to discover, nor hard to comply with. The rules exist to ensure that people are included in the work, and I am sure that inclusion is what you want. I find it unfortunate that you scheduled a working group meeting to discuss only one of a pair of competing documents on the same topic, that you didn't make the information about the meeting available to the authors of the competing document or to the people who care about the protocol being modelled, and I find it upsetting (yes, I am actually upset) that you decided to discuss in Netmod a document that belongs in the OSPF working group. If, as it surely sounds, you wish that the Netmod working group had a different charter to enable it to take on models for protocols that already have a home in other working groups, then I suggest you need to recharter. But I doubt that your reasoning that [YANG] experts will not go to all the other working groups will carry much weight. Frankly, and without wanting to disrespect the YANG experts, it is easier to understand YANG than it is to understand OSPF. If this were not the case then the Netmod working group would have failed in its design of YANG! Conclusion: You want to work on a YANG model for OSPF. Go to the OSPF working group and discuss it (there are already some threads). Review and comment on the competing document. Try to get agreement between all of the authors of both documents, or try to identify the differences. Work with the chairs of the OSPF working group to advance the work. Adrian > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com] > Sent: 22 October 2014 14:29 > To: Benoit Claise > Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org; > rtg-ads@tools.ietf.org > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled > > > This is hugely disappointing. This is the kind of procedural non-sense has > and IS driving people away from the IETF to other places where this work is going > to get done. The simple effect of such silliness will be a reduction in speed and > quantity of model development. If the goal of the IESG is to slow down the > velocity of model development and creation, then this approach is perfect. > > For the record, the interim NETMOD meeting cadence has one meeting > focused on Yang and the other on modeling; is not NETMOD-specific per say, but > to promote model creation because no other bi-weekly forum exists to do so. It > is also a place to bring in non-IETF work such as the work done in ODL, other open > source, or just the public community that has explicitly wanted to avoid the IETF. > We have found it a convenient and fruitful place to discuss, and actually *build* > models - regardless of their ultimate WG home. The simple reason: its a single > place for many of the experts to gather. I think you will find it very difficult to get > those people onto a per-WG call every other week. > > I hope the IESG considers this approach carefully because I do not think it > will have the affect the larger IETF community is interested in. > > --Tom > > > > > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise wrote: > > > > Dear all, > > > > Today NETMOD interim meeting is canceled. > > > > I received some pushbacks from the routing ADs, on the ground that: > > 1. This interim appears to be meeting to discuss a non-WG draft for which there > is no milestone in the working group and for which there is an obvious home > outside the working group. > > 2. The agenda was not announced a week in advance on the IETF announce list > as is required > > > > Regards, Benoit > > > > _______________________________________________ > > Rtg-yang-coord mailing list > > Rtg-yang-coord@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > From nobody Wed Oct 22 06:50:35 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0ED1AC3A0 for ; Wed, 22 Oct 2014 06:50:33 -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, 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 6zfMYz44CV15 for ; Wed, 22 Oct 2014 06:50:28 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 58B4A1AC3A6 for ; Wed, 22 Oct 2014 06:50:28 -0700 (PDT) Received: from [192.168.1.123] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id CB48628D07F2; Wed, 22 Oct 2014 09:50:27 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_F68530A5-F61A-4849-8402-29F1BC00E292" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: "Thomas D. Nadeau" In-Reply-To: Date: Wed, 22 Oct 2014 09:50:27 -0400 Message-Id: References: <7AE50968-A834-4CA8-BC95-95253322E45B@lucidvision.com> To: "Sterne, Jason (Jason)" X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/c35WjVJfYqMuy9Y-f_jwcHTVaP0 Cc: "netmod@ietf.org" Subject: Re: [netmod] IETF91 NETMOD 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, 22 Oct 2014 13:50:34 -0000 --Apple-Mail=_F68530A5-F61A-4849-8402-29F1BC00E292 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 ah sorry. I=E2=80=99ll take note of this for the proposed agenda for = Hawaii.=20 > On Oct 22, 2014:9:42 AM, at 9:42 AM, Sterne, Jason (Jason) = wrote: >=20 > This email thread I started is about the IETF91 NETMOD meetings (not = the interim meeting). > =20 > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com = ]=20 > Sent: Wednesday, October 22, 2014 9:35 AM > To: Sterne, Jason (Jason) > Cc: netmod@ietf.org > Subject: Re: [netmod] IETF91 NETMOD agenda ? > =20 > =20 > Meeting is canceled. See previous note from Benoit.=20 > =20 > =E2=80=94Tom > =20 > =20 > On Oct 22, 2014:9:29 AM, at 9:29 AM, Sterne, Jason (Jason) = > wrote: > =20 > One item that might be useful: > =20 > - =E2=80=9CDesign Teams=E2=80=9D update: > o List of all known =E2=80=9Cdesign teams=E2=80=9D that are working = on YANG models (especially ones that may be progressing outside of the = IETF mailing lists) > o Ideally a brief status update from one of the primary = leaders/contributors (i.e. a few bullet points / 1-2 minutes) for each = one (not to discuss the technical details of specific models =E2=80=93 = that could be other agenda items) > =20 > Regards, > Jason > =20 > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com = ]=20 > Sent: Tuesday, October 21, 2014 5:34 PM > To: Sterne, Jason (Jason) > Cc: netmod@ietf.org > Subject: Re: [netmod] IETF91 NETMOD agenda ? > =20 > =20 > Not yet. Please propose topics.=20 > =20 > =E2=80=94Tom > =20 > =20 > On Oct 21, 2014:5:32 PM, at 5:32 PM, Sterne, Jason (Jason) = > wrote: > =20 > Hi all, > =20 > Is there a preliminary agenda for the two NETMOD sessions at IETF91 ? = =20 > =20 > Some thought about topics being split between the 1st (longer) and 2nd = (shorter) sessions ? > =20 > Thanks, > Jason > =20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod = --Apple-Mail=_F68530A5-F61A-4849-8402-29F1BC00E292 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 ah sorry. I=E2=80=99ll take note of this for the proposed = agenda for Hawaii. 

On Oct 22, 2014:9:42 AM, at = 9:42 AM, Sterne, Jason (Jason) <jason.sterne@alcatel-lucent.com> wrote:

This email thread I started is about the = IETF91 NETMOD meetings (not the interim meeting).
 
From: Thomas D. = Nadeau [mailto:tnadeau@lucidvision.com] 
Sent: Wednesday, October 22, 2014 = 9:35 AM
To: Sterne, Jason (Jason)
Cc: netmod@ietf.org
Subject: Re: [netmod] IETF91 NETMOD = agenda ?
 
 
        &= nbsp;   Meeting is canceled. = See previous note from Benoit. 
 
        &= nbsp;   =E2=80=94Tom
 
 
On = Oct 22, 2014:9:29 AM, at 9:29 AM, Sterne, Jason (Jason) <jason.sterne@alcatel-lucent.com> wrote:
 
One= item that might be useful:
 
-          =E2=80=9CDesign Teams=E2=80=9D = update:
o   List of all known =E2=80=9Cdesign teams=E2=80= =9D that are working on YANG models (especially ones that may be = progressing outside of the IETF mailing lists)
o   Ideally a brief status update from one of = the primary leaders/contributors (i.e. a few bullet points / 1-2 = minutes) for each one (not to discuss the technical details of specific = models =E2=80=93 that could be other agenda items)
 
Regards,
Jason
 
From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com] 
Sent: Tuesday, October 21, 2014 = 5:34 PM
To: Sterne, Jason (Jason)
Cc: netmod@ietf.org
Subject: Re: [netmod] IETF91 NETMOD = agenda ?
 
 
        &= nbsp;   Not yet. Please propose = topics. 
 
        &= nbsp;   =E2=80=94Tom
 
 
On = Oct 21, 2014:5:32 PM, at 5:32 PM, Sterne, Jason (Jason) <jason.sterne@alcatel-lucent.com> wrote:
 
Hi all,
 
Is there a preliminary = agenda for the two NETMOD sessions at IETF91 = ?     
 
Some thought about topics = being split between the 1st (longer) and 2nd (shorter) sessions ?
 
Thanks,
Jason
 
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

= --Apple-Mail=_F68530A5-F61A-4849-8402-29F1BC00E292-- From nobody Wed Oct 22 06:51:39 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74CC11AC3A7; Wed, 22 Oct 2014 06:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 zNQj958joaEo; Wed, 22 Oct 2014 06:51:33 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 3EEF01ABD3C; Wed, 22 Oct 2014 06:51:33 -0700 (PDT) Received: from [192.168.1.123] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id AF56B28D080C; Wed, 22 Oct 2014 09:51:32 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: "Thomas D. Nadeau" In-Reply-To: <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> Date: Wed, 22 Oct 2014 09:51:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> To: Farrel Adrian X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/TX0jvF18F-Lg20rWxz9_80aZO7Y Cc: Rtg-yang-coord@ietf.org, NETMOD Working Group , ospf-chairs@tools.ietf.org, ops-ads@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2014 13:51:35 -0000 Hide behind the rules all you like, but this is a simple example = of why people are going elsewhere to work on these things. --Tom > On Oct 22, 2014:9:48 AM, at 9:48 AM, Adrian Farrel = wrote: >=20 > I understand and appreciate your desire to get work done. >=20 > The rules for IETF virtual interims are neither hard to discover, nor = hard to > comply with. The rules exist to ensure that people are included in the = work, and > I am sure that inclusion is what you want. >=20 > I find it unfortunate that you scheduled a working group meeting to = discuss only > one of a pair of competing documents on the same topic, that you = didn't make the > information about the meeting available to the authors of the = competing document > or to the people who care about the protocol being modelled, and I = find it > upsetting (yes, I am actually upset) that you decided to discuss in = Netmod a > document that belongs in the OSPF working group. >=20 > If, as it surely sounds, you wish that the Netmod working group had a = different > charter to enable it to take on models for protocols that already have = a home in > other working groups, then I suggest you need to recharter. But I = doubt that > your reasoning that [YANG] experts will not go to all the other = working groups > will carry much weight. Frankly, and without wanting to disrespect the = YANG > experts, it is easier to understand YANG than it is to understand = OSPF. If this > were not the case then the Netmod working group would have failed in = its design > of YANG!=20 >=20 > Conclusion:=20 > You want to work on a YANG model for OSPF. Go to the OSPF working = group and > discuss it (there are already some threads). Review and comment on the = competing > document. Try to get agreement between all of the authors of both = documents, or > try to identify the differences. Work with the chairs of the OSPF = working group > to advance the work. >=20 > Adrian >=20 >> -----Original Message----- >> From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com] >> Sent: 22 October 2014 14:29 >> To: Benoit Claise >> Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; = ops-ads@tools.ietf.org; >> rtg-ads@tools.ietf.org >> Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled >>=20 >>=20 >> This is hugely disappointing. This is the kind of procedural = non-sense > has >> and IS driving people away from the IETF to other places where this = work is > going >> to get done. The simple effect of such silliness will be a reduction = in speed > and >> quantity of model development. If the goal of the IESG is to slow = down the >> velocity of model development and creation, then this approach is = perfect. >>=20 >> For the record, the interim NETMOD meeting cadence has one = meeting >> focused on Yang and the other on modeling; is not NETMOD-specific per = say, but >> to promote model creation because no other bi-weekly forum exists to = do so. It >> is also a place to bring in non-IETF work such as the work done in = ODL, other > open >> source, or just the public community that has explicitly wanted to = avoid the > IETF. >> We have found it a convenient and fruitful place to discuss, and = actually > *build* >> models - regardless of their ultimate WG home. The simple reason: = its a > single >> place for many of the experts to gather. I think you will find it = very > difficult to get >> those people onto a per-WG call every other week. >>=20 >> I hope the IESG considers this approach carefully because I do = not think > it >> will have the affect the larger IETF community is interested in. >>=20 >> --Tom >>=20 >>=20 >>=20 >>> On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise = > wrote: >>>=20 >>> Dear all, >>>=20 >>> Today NETMOD interim meeting is canceled. >>>=20 >>> I received some pushbacks from the routing ADs, on the ground that: >>> 1. This interim appears to be meeting to discuss a non-WG draft for = which > there >> is no milestone in the working group and for which there is an = obvious home >> outside the working group. >>> 2. The agenda was not announced a week in advance on the IETF = announce list >> as is required >>>=20 >>> Regards, Benoit >>>=20 >>> _______________________________________________ >>> Rtg-yang-coord mailing list >>> Rtg-yang-coord@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >>>=20 >=20 > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord >=20 From nobody Wed Oct 22 06:56:06 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A35451ABD3F; Wed, 22 Oct 2014 06:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vrbNdEvzA0p; Wed, 22 Oct 2014 06:51:00 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCEC41AC3A1; Wed, 22 Oct 2014 06:50:59 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id tr6so1445879ieb.4 for ; Wed, 22 Oct 2014 06:50:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=9FmnZuYVw/AGhX7nJBFg4v74OSCpbXRUMMGNIO1e/ZA=; b=Jo6J0o66R0pcubX/+X1YFzGBc8yX6McBC0ENlehb0SRekIAUdo+Ir2BszwQXP03D2Q 9Rm+w41T40vTzasq4O/aL2OJRmns0n+sfnU5Sx0DcAOS6SUxyXIeXhvKRHHLvzTpawTf IRrUjIgE7bcnDoAD+astSsjX7fuJSmji8i3dpzS4TNKcsPu9pGcMUVr0vwycJFi1508L 4cQrnYRgJtxJ3w5GFqP5wEJ+qYxOhlfScKugQNCm3v2M4qgtJ6O1sScZXat0H1Muiiih Zh0pwmlWLWtjUvFiq0rZWnUhmZVY2Cxnm/TwbFz7g5dw8Ht1THLbWovceVT4mlZivrQM IQgA== MIME-Version: 1.0 X-Received: by 10.107.133.5 with SMTP id h5mr25665361iod.47.1413985859044; Wed, 22 Oct 2014 06:50:59 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.107.156.208 with HTTP; Wed, 22 Oct 2014 06:50:58 -0700 (PDT) In-Reply-To: <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> Date: Wed, 22 Oct 2014 15:50:58 +0200 X-Google-Sender-Auth: O96-FcbPhhnhIZMbH7ayKPCo23w Message-ID: From: Robert Raszuk To: "Thomas D. Nadeau" Content-Type: multipart/alternative; boundary=001a113ea4f0d88b580506033c1d Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Arufy3vO5xc_4wRQiRMvJhZWfW4 X-Mailman-Approved-At: Wed, 22 Oct 2014 06:55:52 -0700 Cc: Rtg-yang-coord@ietf.org, "ops-ads@tools.ietf.org" , NETMOD Working Group , "rtg-ads@tools.ietf.org" Subject: Re: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2014 13:51:01 -0000 --001a113ea4f0d88b580506033c1d Content-Type: text/plain; charset=UTF-8 Hi Tom, I agree with you. Not longer then few days back I have received request from paying customers to add OSPF, BGP & BFD API to the product. All I could propose was few slowly moving drafts. I recommend you setup a meetup.com space for rtg-yang regular online discussions and turn those drafts which are in progress into OpenStack Neutron blueprints. I think the progress will be much faster and much wider in the community ;-) Cheers, R. On Wed, Oct 22, 2014 at 3:29 PM, Thomas D. Nadeau wrote: > > This is hugely disappointing. This is the kind of procedural > non-sense has and IS driving people away from the IETF to other places > where this work is going to get done. The simple effect of such silliness > will be a reduction in speed and quantity of model development. If the > goal of the IESG is to slow down the velocity of model development and > creation, then this approach is perfect. > > For the record, the interim NETMOD meeting cadence has one meeting > focused on Yang and the other on modeling; is not NETMOD-specific per say, > but to promote model creation because no other bi-weekly forum exists to do > so. It is also a place to bring in non-IETF work such as the work done in > ODL, other open source, or just the public community that has explicitly > wanted to avoid the IETF. We have found it a convenient and fruitful place > to discuss, and actually *build* models - regardless of their ultimate WG > home. The simple reason: its a single place for many of the experts to > gather. I think you will find it very difficult to get those people onto a > per-WG call every other week. > > I hope the IESG considers this approach carefully because I do not > think it will have the affect the larger IETF community is interested in. > > --Tom > > > > > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise > wrote: > > > > Dear all, > > > > Today NETMOD interim meeting is canceled. > > > > I received some pushbacks from the routing ADs, on the ground that: > > 1. This interim appears to be meeting to discuss a non-WG draft for > which there is no milestone in the working group and for which there is an > obvious home outside the working group. > > 2. The agenda was not announced a week in advance on the IETF announce > list as is required > > > > Regards, Benoit > > > > _______________________________________________ > > Rtg-yang-coord mailing list > > Rtg-yang-coord@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > --001a113ea4f0d88b580506033c1d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Tom,

I agree with you.=C2=A0

N= ot longer then few days back I have received request from paying customers = to add OSPF, BGP & BFD API to the product.=C2=A0
All I could propose was few slowly moving drafts.=C2= =A0

I recommend you setup a meetup.com space for rtg-yang regular online = discussions and turn those drafts which are in progress into OpenStack Neut= ron blueprints.=C2=A0

I think th= e progress will be much faster and much wider in the community ;-)

Cheers,
R.




=

On Wed, Oct= 22, 2014 at 3:29 PM, Thomas D. Nadeau <tnadeau@lucidvision.com&= gt; wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 This is hugely disappointing. This is the kind = of procedural non-sense has and IS driving people away from the IETF to oth= er places where this work is going to get done. The simple effect of such s= illiness will be a reduction in speed and quantity of model development.=C2= =A0 If the goal of the IESG is to slow down the velocity of model developme= nt and creation, then this approach is perfect.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 For the record, the interim NETMOD meeting cade= nce has one meeting focused on Yang and the other on modeling; is not NETMO= D-specific per say, but to promote model creation because no other bi-weekl= y forum exists to do so. It is also a place to bring in non-IETF work such = as the work done in ODL, other open source, or just the public community th= at has explicitly wanted to avoid the IETF.=C2=A0 We have found it a conven= ient and fruitful place to discuss, and actually *build* models - regardles= s of their ultimate WG home.=C2=A0 The simple reason: its a single place fo= r many of the experts to gather. I think you will find it very difficult to= get those people onto a per-WG call every other week.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I hope the IESG considers this approach careful= ly because I do not think it will have the affect the larger IETF community= is interested in.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 --Tom



> On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise <bclaise@cisco.com> wrote:
>
> Dear all,
>
> Today NETMOD interim meeting is canceled.
>
> I received some pushbacks from the routing ADs, on the ground that: > 1. This interim appears to be meeting to discuss a non-WG draft for wh= ich there is no milestone in the working group and for which there is an ob= vious home outside the working group.
> 2. The agenda was not announced a week in advance on the IETF announce= list as is required
>
> Regards, Benoit
>
> _______________________________________________
> Rtg-yang-coord mailing list
> Rtg-yang-coord@ietf.org=
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>

_______________________________________________
Rtg-yang-coord mailing list
Rtg-yang-coord@ietf.org
https://www.ietf.org/mailman/listinfo/rtg-yang-coord

--001a113ea4f0d88b580506033c1d-- From nobody Wed Oct 22 07:18:32 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 842291AC3AD for ; Wed, 22 Oct 2014 07:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AwvRNHkacT6B for ; Wed, 22 Oct 2014 07:18:17 -0700 (PDT) Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E8EA1AC3D0 for ; Wed, 22 Oct 2014 07:18:16 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id j7so2432573qaq.30 for ; Wed, 22 Oct 2014 07:18:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UY0VHpd+msgdFT8jBDnZq4x+yI4o134Ji4RPuiZAOhg=; b=RtfuCMD0AVAMKNi0RDSCyHw9q8gKdyRrt3n3OfzA+AtQUOAXXZRrDk6jA7JvSB/7m4 /8PtdOt6JZ9zV3kpmmQgS40mVmiVo3t0lR1kKFmnONd7uWuKzi78eiwWH88lGLoB0/D6 /H4YJ9mhukN0gEx78u7R+CVPb1bo/WB2BgeO2gzRupGT2gptTXgCGRiU5RkohsVsVPcR /P2WiDsWFDU4gVyGTKc6Cm08zpYvPDseKDB7X+mhD5mn9cedr6VLpxBXK6PTKSK/8KXw 8CX7OoexA4CVHL2kHLLlkYsEazA6P8igbSEPbUdJcNKsK5IeieHrLZI1797hQLyLGYvF oJmg== X-Gm-Message-State: ALoCoQl8UYFg1dBkWZy/TGp1U4bMKnzrX5nvQjXX67fox6cnjQWs0743TJGzVE7GNF+iwD6trxLL MIME-Version: 1.0 X-Received: by 10.224.130.198 with SMTP id u6mr30701761qas.99.1413987494486; Wed, 22 Oct 2014 07:18:14 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Wed, 22 Oct 2014 07:18:14 -0700 (PDT) In-Reply-To: <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> Date: Wed, 22 Oct 2014 07:18:14 -0700 Message-ID: From: Andy Bierman To: Adrian Farrel Content-Type: multipart/alternative; boundary=089e0158b38c53c7150506039e53 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/jJ3C8gJA5xPRkdw2fF32RMyTb_g Cc: Rtg-yang-coord@ietf.org, NETMOD Working Group , ospf-chairs@tools.ietf.org, ops-ads@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2014 14:18:21 -0000 --089e0158b38c53c7150506039e53 Content-Type: text/plain; charset=ISO-8859-1 Hi Adrian, I agree with you. The OSPF WG should be discussing OSPF data models, not the NETMOD WG. The domain experts need to reach consensus on a feature set (and maybe info model) and then get 1 or 2 YANG experts to help translate that to a data model. (Not the other way around -- a room full of YANG experts and 1 or 2 OSPF experts). I also prefer that virtual interim meetings be used to discuss open issues on chartered items, not as an additional forum to promote individual drafts. Andy On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel wrote: > I understand and appreciate your desire to get work done. > > The rules for IETF virtual interims are neither hard to discover, nor hard > to > comply with. The rules exist to ensure that people are included in the > work, and > I am sure that inclusion is what you want. > > I find it unfortunate that you scheduled a working group meeting to > discuss only > one of a pair of competing documents on the same topic, that you didn't > make the > information about the meeting available to the authors of the competing > document > or to the people who care about the protocol being modelled, and I find it > upsetting (yes, I am actually upset) that you decided to discuss in Netmod > a > document that belongs in the OSPF working group. > > If, as it surely sounds, you wish that the Netmod working group had a > different > charter to enable it to take on models for protocols that already have a > home in > other working groups, then I suggest you need to recharter. But I doubt > that > your reasoning that [YANG] experts will not go to all the other working > groups > will carry much weight. Frankly, and without wanting to disrespect the YANG > experts, it is easier to understand YANG than it is to understand OSPF. If > this > were not the case then the Netmod working group would have failed in its > design > of YANG! > > Conclusion: > You want to work on a YANG model for OSPF. Go to the OSPF working group and > discuss it (there are already some threads). Review and comment on the > competing > document. Try to get agreement between all of the authors of both > documents, or > try to identify the differences. Work with the chairs of the OSPF working > group > to advance the work. > > Adrian > > > -----Original Message----- > > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com] > > Sent: 22 October 2014 14:29 > > To: Benoit Claise > > Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; > ops-ads@tools.ietf.org; > > rtg-ads@tools.ietf.org > > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled > > > > > > This is hugely disappointing. This is the kind of procedural > non-sense > has > > and IS driving people away from the IETF to other places where this work > is > going > > to get done. The simple effect of such silliness will be a reduction in > speed > and > > quantity of model development. If the goal of the IESG is to slow down > the > > velocity of model development and creation, then this approach is > perfect. > > > > For the record, the interim NETMOD meeting cadence has one meeting > > focused on Yang and the other on modeling; is not NETMOD-specific per > say, but > > to promote model creation because no other bi-weekly forum exists to do > so. It > > is also a place to bring in non-IETF work such as the work done in ODL, > other > open > > source, or just the public community that has explicitly wanted to avoid > the > IETF. > > We have found it a convenient and fruitful place to discuss, and actually > *build* > > models - regardless of their ultimate WG home. The simple reason: its a > single > > place for many of the experts to gather. I think you will find it very > difficult to get > > those people onto a per-WG call every other week. > > > > I hope the IESG considers this approach carefully because I do not > think > it > > will have the affect the larger IETF community is interested in. > > > > --Tom > > > > > > > > > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise > wrote: > > > > > > Dear all, > > > > > > Today NETMOD interim meeting is canceled. > > > > > > I received some pushbacks from the routing ADs, on the ground that: > > > 1. This interim appears to be meeting to discuss a non-WG draft for > which > there > > is no milestone in the working group and for which there is an obvious > home > > outside the working group. > > > 2. The agenda was not announced a week in advance on the IETF announce > list > > as is required > > > > > > Regards, Benoit > > > > > > _______________________________________________ > > > Rtg-yang-coord mailing list > > > Rtg-yang-coord@ietf.org > > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --089e0158b38c53c7150506039e53 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Adrian,

I agree with you. The OSPF W= G should be discussing OSPF data models,
not the NETMOD WG. The d= omain experts need to reach consensus
on a feature set (and maybe= info model) and then get 1 or 2 YANG experts to
help translate t= hat to a data model. (Not the other way around -- a room
full of = YANG experts and 1 or 2 OSPF experts).

I also pref= er that virtual interim meetings be used to discuss open issues
o= n chartered items, not as an additional forum to promote individual drafts.=


Andy


On Wed, Oct 22, = 2014 at 6:48 AM, Adrian Farrel <adrian@olddog.co.uk> wrote= :
I understand and appreciate your desire= to get work done.

The rules for IETF virtual interims are neither hard to discover, nor hard = to
comply with. The rules exist to ensure that people are included in the work= , and
I am sure that inclusion is what you want.

I find it unfortunate that you scheduled a working group meeting to discuss= only
one of a pair of competing documents on the same topic, that you didn't= make the
information about the meeting available to the authors of the competing doc= ument
or to the people who care about the protocol being modelled, and I find it<= br> upsetting (yes, I am actually upset) that you decided to discuss in Netmod = a
document that belongs in the OSPF working group.

If, as it surely sounds, you wish that the Netmod working group had a diffe= rent
charter to enable it to take on models for protocols that already have a ho= me in
other working groups, then I suggest you need to recharter. But I doubt tha= t
your reasoning that [YANG] experts will not go to all the other working gro= ups
will carry much weight. Frankly, and without wanting to disrespect the YANG=
experts, it is easier to understand YANG than it is to understand OSPF. If = this
were not the case then the Netmod working group would have failed in its de= sign
of YANG!

Conclusion:
You want to work on a YANG model for OSPF. Go to the OSPF working group and=
discuss it (there are already some threads). Review and comment on the comp= eting
document. Try to get agreement between all of the authors of both documents= , or
try to identify the differences. Work with the chairs of the OSPF working g= roup
to advance the work.

Adrian

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com]
> Sent: 22 October 2014 14:29
> To: Benoit Claise
> Cc: NETMOD Working Group; R= tg-yang-coord@ietf.org; ops-a= ds@tools.ietf.org;
> rtg-ads@tools.ietf.org > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled
>
>
>=A0 =A0 =A0 =A0This is hugely disappointing. This is the kind of proced= ural non-sense
has
> and IS driving people away from the IETF to other places where this wo= rk is
going
> to get done. The simple effect of such silliness will be a reduction i= n speed
and
> quantity of model development.=A0 If the goal of the IESG is to slow d= own the
> velocity of model development and creation, then this approach is perf= ect.
>
>=A0 =A0 =A0 =A0For the record, the interim NETMOD meeting cadence has o= ne meeting
> focused on Yang and the other on modeling; is not NETMOD-specific per = say, but
> to promote model creation because no other bi-weekly forum exists to d= o so. It
> is also a place to bring in non-IETF work such as the work done in ODL= , other
open
> source, or just the public community that has explicitly wanted to avo= id the
IETF.
> We have found it a convenient and fruitful place to discuss, and actua= lly
*build*
> models - regardless of their ultimate WG home.=A0 The simple reason: i= ts a
single
> place for many of the experts to gather. I think you will find it very=
difficult to get
> those people onto a per-WG call every other week.
>
>=A0 =A0 =A0 =A0I hope the IESG considers this approach carefully becaus= e I do not think
it
> will have the affect the larger IETF community is interested in.
>
>=A0 =A0 =A0 =A0--Tom
>
>
>
> > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise <bclaise@cisco.com>
wrote:
> >
> > Dear all,
> >
> > Today NETMOD interim meeting is canceled.
> >
> > I received some pushbacks from the routing ADs, on the ground tha= t:
> > 1. This interim appears to be meeting to discuss a non-WG draft f= or which
there
> is no milestone in the working group and for which there is an obvious= home
> outside the working group.
> > 2. The agenda was not announced a week in advance on the IETF ann= ounce list
> as is required
> >
> > Regards, Benoit
> >
> > _______________________________________________
> > Rtg-yang-coord mailing list
> > Rtg-yang-coord@ietf.or= g
> > https://www.ietf.org/mailman/listinfo/rtg-yang-coord<= br> > >

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

--089e0158b38c53c7150506039e53-- From nobody Wed Oct 22 07:35:23 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBF61ACCF3; Wed, 22 Oct 2014 07:35:19 -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, 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 OSRo_mBRQpNZ; Wed, 22 Oct 2014 07:35:12 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 33A0E1ACCEB; Wed, 22 Oct 2014 07:35:11 -0700 (PDT) Received: from [192.168.1.123] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 31C3F28D09E0; Wed, 22 Oct 2014 10:35:11 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_CF902154-C073-41EB-82BB-0B11EF8638BD" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: "Thomas D. Nadeau" In-Reply-To: Date: Wed, 22 Oct 2014 10:35:10 -0400 Message-Id: References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> To: Andy Bierman X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/4ihWq2mAMyCCKSEJvFG_K1ihXko Cc: Rtg-yang-coord@ietf.org, NETMOD Working Group , ospf-chairs@tools.ietf.org, ops-ads@tools.ietf.org, rtg-ads@tools.ietf.org, Farrel Adrian Subject: Re: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2014 14:35:19 -0000 --Apple-Mail=_CF902154-C073-41EB-82BB-0B11EF8638BD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 No one said that OSPF experts could not attend to provide input. = The issue is that OSPF was not doing this. If they want to take over = doing all OSPF models, then great, but to date no one was. The = agreement in NETMOD (and our charter) is to facilitate the creation of = models when WGs don=92t want to do them, have the expertise to do them, = etc=85 Also, getting the right Yang experts in one place is not going = to happen for every WG in the IETF; its just not realistic. I = understand that ultimately the WG needs to have consensus, but quick = iteration to construct the model surely can happen in a small =93design = team=94 fashion, right? And in terms of today=92s meeting being canceled, really what = purpose was that other than to stall/slow-down work? The group that was = there to work on the OSPF model was indeed a bunch of folks from OSPF = (Acee Lindem for example was on the call). So now since we won=92t have = another interim meeting until after Hawaii, so the next time this group = can get together is possibly in Hawaii, but that is probably unlikely as = a large number of people are not going to Hawaii. So the net-net is a = slowing of progress in this area. Probably not the result the IETF = community wants. =97Tom > On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman = wrote: >=20 > Hi Adrian, >=20 > I agree with you. The OSPF WG should be discussing OSPF data models, > not the NETMOD WG. The domain experts need to reach consensus > on a feature set (and maybe info model) and then get 1 or 2 YANG = experts to > help translate that to a data model. (Not the other way around -- a = room > full of YANG experts and 1 or 2 OSPF experts). >=20 > I also prefer that virtual interim meetings be used to discuss open = issues > on chartered items, not as an additional forum to promote individual = drafts. >=20 >=20 > Andy >=20 >=20 > On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel > wrote: > I understand and appreciate your desire to get work done. >=20 > The rules for IETF virtual interims are neither hard to discover, nor = hard to > comply with. The rules exist to ensure that people are included in the = work, and > I am sure that inclusion is what you want. >=20 > I find it unfortunate that you scheduled a working group meeting to = discuss only > one of a pair of competing documents on the same topic, that you = didn't make the > information about the meeting available to the authors of the = competing document > or to the people who care about the protocol being modelled, and I = find it > upsetting (yes, I am actually upset) that you decided to discuss in = Netmod a > document that belongs in the OSPF working group. >=20 > If, as it surely sounds, you wish that the Netmod working group had a = different > charter to enable it to take on models for protocols that already have = a home in > other working groups, then I suggest you need to recharter. But I = doubt that > your reasoning that [YANG] experts will not go to all the other = working groups > will carry much weight. Frankly, and without wanting to disrespect the = YANG > experts, it is easier to understand YANG than it is to understand = OSPF. If this > were not the case then the Netmod working group would have failed in = its design > of YANG! >=20 > Conclusion: > You want to work on a YANG model for OSPF. Go to the OSPF working = group and > discuss it (there are already some threads). Review and comment on the = competing > document. Try to get agreement between all of the authors of both = documents, or > try to identify the differences. Work with the chairs of the OSPF = working group > to advance the work. >=20 > Adrian >=20 > > -----Original Message----- > > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com = ] > > Sent: 22 October 2014 14:29 > > To: Benoit Claise > > Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org = ; ops-ads@tools.ietf.org = ; > > rtg-ads@tools.ietf.org > > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled > > > > > > This is hugely disappointing. This is the kind of procedural = non-sense > has > > and IS driving people away from the IETF to other places where this = work is > going > > to get done. The simple effect of such silliness will be a reduction = in speed > and > > quantity of model development. If the goal of the IESG is to slow = down the > > velocity of model development and creation, then this approach is = perfect. > > > > For the record, the interim NETMOD meeting cadence has one = meeting > > focused on Yang and the other on modeling; is not NETMOD-specific = per say, but > > to promote model creation because no other bi-weekly forum exists to = do so. It > > is also a place to bring in non-IETF work such as the work done in = ODL, other > open > > source, or just the public community that has explicitly wanted to = avoid the > IETF. > > We have found it a convenient and fruitful place to discuss, and = actually > *build* > > models - regardless of their ultimate WG home. The simple reason: = its a > single > > place for many of the experts to gather. I think you will find it = very > difficult to get > > those people onto a per-WG call every other week. > > > > I hope the IESG considers this approach carefully because I do = not think > it > > will have the affect the larger IETF community is interested in. > > > > --Tom > > > > > > > > > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise = > > wrote: > > > > > > Dear all, > > > > > > Today NETMOD interim meeting is canceled. > > > > > > I received some pushbacks from the routing ADs, on the ground = that: > > > 1. This interim appears to be meeting to discuss a non-WG draft = for which > there > > is no milestone in the working group and for which there is an = obvious home > > outside the working group. > > > 2. The agenda was not announced a week in advance on the IETF = announce list > > as is required > > > > > > Regards, Benoit > > > > > > _______________________________________________ > > > Rtg-yang-coord mailing list > > > Rtg-yang-coord@ietf.org > > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord = > > > >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod = >=20 --Apple-Mail=_CF902154-C073-41EB-82BB-0B11EF8638BD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

No one = said that OSPF experts could not attend to provide input.   The = issue is that OSPF was not doing this. If they want to take over doing = all OSPF models, then great, but to date no one was.  The agreement = in NETMOD (and our charter) is to facilitate the creation of models when = WGs don=92t want to do them, have the expertise to do them, etc=85 =  Also, getting the right Yang experts in one place is not going to = happen for every WG in the IETF; its just not realistic.  I = understand that ultimately the WG needs to have consensus, but quick = iteration to construct the model surely can happen in a small =93design = team=94 fashion, right?

= And in terms of today=92s meeting being canceled, really what = purpose was that other than to stall/slow-down work?  The group = that was there to work on the OSPF model was indeed a bunch of folks = from OSPF (Acee Lindem for example was on the call).  So now since = we won=92t have another interim meeting until after Hawaii, so the next = time this group can get together is possibly in Hawaii, but that is = probably unlikely as a large number of people are not going to Hawaii. =  So the net-net is a slowing of progress in this area. =  Probably not the result the IETF community wants.

= =97Tom



On = Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman <andy@yumaworks.com> = wrote:

Hi Adrian,

I agree with you. The OSPF WG should be discussing OSPF data = models,
not the NETMOD WG. The domain experts need = to reach consensus
on a feature set (and maybe info = model) and then get 1 or 2 YANG experts to
help = translate that to a data model. (Not the other way around -- a = room
full of YANG experts and 1 or 2 OSPF = experts).

I = also prefer that virtual interim meetings be used to discuss open = issues
on chartered items, not as an additional = forum to promote individual drafts.


Andy


On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel = <adrian@olddog.co.uk> = wrote:
I understand and = appreciate your desire to get work done.

The rules for IETF virtual interims are neither hard to discover, nor = hard to
comply with. The rules exist to ensure that people are included in the = work, and
I am sure that inclusion is what you want.

I find it unfortunate that you scheduled a working group meeting to = discuss only
one of a pair of competing documents on the same topic, that you didn't = make the
information about the meeting available to the authors of the competing = document
or to the people who care about the protocol being modelled, and I find = it
upsetting (yes, I am actually upset) that you decided to discuss in = Netmod a
document that belongs in the OSPF working group.

If, as it surely sounds, you wish that the Netmod working group had a = different
charter to enable it to take on models for protocols that already have a = home in
other working groups, then I suggest you need to recharter. But I doubt = that
your reasoning that [YANG] experts will not go to all the other working = groups
will carry much weight. Frankly, and without wanting to disrespect the = YANG
experts, it is easier to understand YANG than it is to understand OSPF. = If this
were not the case then the Netmod working group would have failed in its = design
of YANG!

Conclusion:
You want to work on a YANG model for OSPF. Go to the OSPF working group = and
discuss it (there are already some threads). Review and comment on the = competing
document. Try to get agreement between all of the authors of both = documents, or
try to identify the differences. Work with the chairs of the OSPF = working group
to advance the work.

Adrian

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com]
> Sent: 22 October 2014 14:29
> To: Benoit Claise
> Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org;
> rtg-ads@tools.ietf.org
> Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled
>
>
>       This is hugely disappointing. This is the = kind of procedural non-sense
has
> and IS driving people away from the IETF to other places where this = work is
going
> to get done. The simple effect of such silliness will be a = reduction in speed
and
> quantity of model development.  If the goal of the IESG is to = slow down the
> velocity of model development and creation, then this approach is = perfect.
>
>       For the record, the interim NETMOD = meeting cadence has one meeting
> focused on Yang and the other on modeling; is not NETMOD-specific = per say, but
> to promote model creation because no other bi-weekly forum exists = to do so. It
> is also a place to bring in non-IETF work such as the work done in = ODL, other
open
> source, or just the public community that has explicitly wanted to = avoid the
IETF.
> We have found it a convenient and fruitful place to discuss, and = actually
*build*
> models - regardless of their ultimate WG home.  The simple = reason: its a
single
> place for many of the experts to gather. I think you will find it = very
difficult to get
> those people onto a per-WG call every other week.
>
>       I hope the IESG considers this approach = carefully because I do not think
it
> will have the affect the larger IETF community is interested in.
>
>       --Tom
>
>
>
> > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise <bclaise@cisco.com>
wrote:
> >
> > Dear all,
> >
> > Today NETMOD interim meeting is canceled.
> >
> > I received some pushbacks from the routing ADs, on the ground = that:
> > 1. This interim appears to be meeting to discuss a non-WG = draft for which
there
> is no milestone in the working group and for which there is an = obvious home
> outside the working group.
> > 2. The agenda was not announced a week in advance on the IETF = announce list
> as is required
> >
> > Regards, Benoit
> >
> > _______________________________________________
> > Rtg-yang-coord mailing list
> > Rtg-yang-coord@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtg-yang-coord
> >

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


= --Apple-Mail=_CF902154-C073-41EB-82BB-0B11EF8638BD-- From nobody Wed Oct 22 07:45:56 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6599E1ACD0B for ; Wed, 22 Oct 2014 07:45:47 -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 XxrCuZ3luits for ; Wed, 22 Oct 2014 07:45:40 -0700 (PDT) Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com [209.85.192.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 026DF1ACD01 for ; Wed, 22 Oct 2014 07:45:29 -0700 (PDT) Received: by mail-qg0-f46.google.com with SMTP id z60so2610903qgd.19 for ; Wed, 22 Oct 2014 07:45: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=X4DLzO+QCcv4g2ZikCTtny3Thme2eThQUEZ5QaRUzic=; b=YkxVK2y2WvXrLMI0KKg65/Ec00kG1LMHkbUJSir3Xz4P/3sXBgSBRxolCVCVMYgiAg sP0MA4lBQWsDS0ZUBnGxZ8p0BLLL8Q8Hrw/Ly0S/LdGryljJXVGf7/WO3WvdAeXc6gvB m6vT2VvzeIHJgBbMB/RkBbFakRAYflK/RKFq1imi0OChG0ydeUJrt0FqWkg/Y6AkE411 5Fc0Lb9MisIdwURjHRywdg7SdtUueZMNFbdxdIaBDSgs+2AzaBHvpzwQPsaUmDbM8pcv Zkpsfa8Bk//nBG2j9Wej4fkbMDXY1xQFu7ZeM/1+0Yx7vz0A8p+meARmrI+2ofuvYO2m NO1w== X-Gm-Message-State: ALoCoQnhEWYuecWI0U6DN4aOqVYYZa/OL5LwIgWnuM/SZVuHqoQAuX5UgcvwN7ZKNkod5I8GZJK6 MIME-Version: 1.0 X-Received: by 10.140.109.53 with SMTP id k50mr53981832qgf.83.1413989129005; Wed, 22 Oct 2014 07:45:29 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Wed, 22 Oct 2014 07:45:28 -0700 (PDT) In-Reply-To: References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> Date: Wed, 22 Oct 2014 07:45:28 -0700 Message-ID: From: Andy Bierman To: "Thomas D. Nadeau" Content-Type: multipart/alternative; boundary=001a113a6bf6c04804050603ffa4 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/4fztlWKWAU_bXAoGPPmpWY3oYHI Cc: Rtg-yang-coord@ietf.org, NETMOD Working Group , ospf-chairs@tools.ietf.org, ops-ads@tools.ietf.org, rtg-ads@tools.ietf.org, Farrel Adrian Subject: Re: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2014 14:45:47 -0000 --001a113a6bf6c04804050603ffa4 Content-Type: text/plain; charset=ISO-8859-1 Hi, I think the interim did not need to be cancelled. There are ACL, SYSLOG, and YANG Mount topics. I was going to call in for those, not OSPF. But I have been saying (for over a year now) that it is time to move domain-specific data models into the domain-specific WGs. I think NETMOD WG should focus on the YANG language and infrastructure modules. Andy On Wed, Oct 22, 2014 at 7:35 AM, Thomas D. Nadeau wrote: > > No one said that OSPF experts could not attend to provide input. The > issue is that OSPF was not doing this. If they want to take over doing all > OSPF models, then great, but to date no one was. The agreement in NETMOD > (and our charter) is to facilitate the creation of models when WGs don't > want to do them, have the expertise to do them, etc... Also, getting the > right Yang experts in one place is not going to happen for every WG in the > IETF; its just not realistic. I understand that ultimately the WG needs to > have consensus, but quick iteration to construct the model surely can > happen in a small "design team" fashion, right? > > And in terms of today's meeting being canceled, really what purpose was > that other than to stall/slow-down work? The group that was there to work > on the OSPF model was indeed a bunch of folks from OSPF (Acee Lindem for > example was on the call). So now since we won't have another interim > meeting until after Hawaii, so the next time this group can get together is > possibly in Hawaii, but that is probably unlikely as a large number of > people are not going to Hawaii. So the net-net is a slowing of progress in > this area. Probably not the result the IETF community wants. > > --Tom > > > > On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman > wrote: > > Hi Adrian, > > I agree with you. The OSPF WG should be discussing OSPF data models, > not the NETMOD WG. The domain experts need to reach consensus > on a feature set (and maybe info model) and then get 1 or 2 YANG experts to > help translate that to a data model. (Not the other way around -- a room > full of YANG experts and 1 or 2 OSPF experts). > > I also prefer that virtual interim meetings be used to discuss open issues > on chartered items, not as an additional forum to promote individual > drafts. > > > Andy > > > On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel > wrote: > >> I understand and appreciate your desire to get work done. >> >> The rules for IETF virtual interims are neither hard to discover, nor >> hard to >> comply with. The rules exist to ensure that people are included in the >> work, and >> I am sure that inclusion is what you want. >> >> I find it unfortunate that you scheduled a working group meeting to >> discuss only >> one of a pair of competing documents on the same topic, that you didn't >> make the >> information about the meeting available to the authors of the competing >> document >> or to the people who care about the protocol being modelled, and I find it >> upsetting (yes, I am actually upset) that you decided to discuss in >> Netmod a >> document that belongs in the OSPF working group. >> >> If, as it surely sounds, you wish that the Netmod working group had a >> different >> charter to enable it to take on models for protocols that already have a >> home in >> other working groups, then I suggest you need to recharter. But I doubt >> that >> your reasoning that [YANG] experts will not go to all the other working >> groups >> will carry much weight. Frankly, and without wanting to disrespect the >> YANG >> experts, it is easier to understand YANG than it is to understand OSPF. >> If this >> were not the case then the Netmod working group would have failed in its >> design >> of YANG! >> >> Conclusion: >> You want to work on a YANG model for OSPF. Go to the OSPF working group >> and >> discuss it (there are already some threads). Review and comment on the >> competing >> document. Try to get agreement between all of the authors of both >> documents, or >> try to identify the differences. Work with the chairs of the OSPF working >> group >> to advance the work. >> >> Adrian >> >> > -----Original Message----- >> > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com] >> > Sent: 22 October 2014 14:29 >> > To: Benoit Claise >> > Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; >> ops-ads@tools.ietf.org; >> > rtg-ads@tools.ietf.org >> > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled >> > >> > >> > This is hugely disappointing. This is the kind of procedural >> non-sense >> has >> > and IS driving people away from the IETF to other places where this >> work is >> going >> > to get done. The simple effect of such silliness will be a reduction in >> speed >> and >> > quantity of model development. If the goal of the IESG is to slow down >> the >> > velocity of model development and creation, then this approach is >> perfect. >> > >> > For the record, the interim NETMOD meeting cadence has one meeting >> > focused on Yang and the other on modeling; is not NETMOD-specific per >> say, but >> > to promote model creation because no other bi-weekly forum exists to do >> so. It >> > is also a place to bring in non-IETF work such as the work done in ODL, >> other >> open >> > source, or just the public community that has explicitly wanted to >> avoid the >> IETF. >> > We have found it a convenient and fruitful place to discuss, and >> actually >> *build* >> > models - regardless of their ultimate WG home. The simple reason: its a >> single >> > place for many of the experts to gather. I think you will find it very >> difficult to get >> > those people onto a per-WG call every other week. >> > >> > I hope the IESG considers this approach carefully because I do >> not think >> it >> > will have the affect the larger IETF community is interested in. >> > >> > --Tom >> > >> > >> > >> > > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise > > >> wrote: >> > > >> > > Dear all, >> > > >> > > Today NETMOD interim meeting is canceled. >> > > >> > > I received some pushbacks from the routing ADs, on the ground that: >> > > 1. This interim appears to be meeting to discuss a non-WG draft for >> which >> there >> > is no milestone in the working group and for which there is an obvious >> home >> > outside the working group. >> > > 2. The agenda was not announced a week in advance on the IETF >> announce list >> > as is required >> > > >> > > Regards, Benoit >> > > >> > > _______________________________________________ >> > > Rtg-yang-coord mailing list >> > > Rtg-yang-coord@ietf.org >> > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord >> > > >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > > > --001a113a6bf6c04804050603ffa4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I think the interim did not need to= be cancelled. There are ACL, SYSLOG,
and YANG Mount topics. I wa= s going to call in for those, not OSPF.
But I have been saying (f= or over a year now) that it is time to move
domain-specific data = models into the domain-specific WGs.
I think NETMOD WG should foc= us on the YANG language and
infrastructure modules.
Andy


On Wed, Oct 22, 2014 at 7:35 AM, Thomas D. Nadeau <t= nadeau@lucidvision.com> wrote:

No one said that OSPF experts could not attend to = provide input.   The issue is that OSPF was not doing this. If they wa= nt to take over doing all OSPF models, then great, but to date no one was.&= nbsp; The agreement in NETMOD (and our charter) is to facilitate the creati= on of models when WGs don’t want to do them, have the expertise to do= them, etc…  Also, getting the right Yang experts in one place = is not going to happen for every WG in the IETF; its just not realistic.&nb= sp; I understand that ultimately the WG needs to have consensus, but quick = iteration to construct the model surely can happen in a small “design= team” fashion, right?

And in terms of today’s meeting being canceled, rea= lly what purpose was that other than to stall/slow-down work?  The gro= up that was there to work on the OSPF model was indeed a bunch of folks fro= m OSPF (Acee Lindem for example was on the call).  So now since we won= ’t have another interim meeting until after Hawaii, so the next time = this group can get together is possibly in Hawaii, but that is probably unl= ikely as a large number of people are not going to Hawaii.  So the net= -net is a slowing of progress in this area.  Probably not the result t= he IETF community wants.

—Tom



On Oct 22, 2014:10:18 AM, at 10:18 AM, An= dy Bierman <andy= @yumaworks.com> wrote:

Hi Adrian,
I agree with you. The OSPF WG should be discussing OSPF dat= a models,
not the NETMOD WG. The domain experts need to reach con= sensus
on a feature set (and maybe info model) and then get 1 or = 2 YANG experts to
help translate that to a data model. (Not the o= ther way around -- a room
full of YANG experts and 1 or 2 OSPF ex= perts).

I also prefer that virtual interim meeting= s be used to discuss open issues
on chartered items, not as an ad= ditional forum to promote individual drafts.


<= /div>
Andy

On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel = <adrian@olddog.co.uk> wrote:
I understand and appreciate your desire to get work done.

The rules for IETF virtual interims are neither hard to discover, nor hard = to
comply with. The rules exist to ensure that people are included in the work= , and
I am sure that inclusion is what you want.

I find it unfortunate that you scheduled a working group meeting to discuss= only
one of a pair of competing documents on the same topic, that you didn't= make the
information about the meeting available to the authors of the competing doc= ument
or to the people who care about the protocol being modelled, and I find it<= br> upsetting (yes, I am actually upset) that you decided to discuss in Netmod = a
document that belongs in the OSPF working group.

If, as it surely sounds, you wish that the Netmod working group had a diffe= rent
charter to enable it to take on models for protocols that already have a ho= me in
other working groups, then I suggest you need to recharter. But I doubt tha= t
your reasoning that [YANG] experts will not go to all the other working gro= ups
will carry much weight. Frankly, and without wanting to disrespect the YANG=
experts, it is easier to understand YANG than it is to understand OSPF. If = this
were not the case then the Netmod working group would have failed in its de= sign
of YANG!

Conclusion:
You want to work on a YANG model for OSPF. Go to the OSPF working group and=
discuss it (there are already some threads). Review and comment on the comp= eting
document. Try to get agreement between all of the authors of both documents= , or
try to identify the differences. Work with the chairs of the OSPF working g= roup
to advance the work.

Adrian

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com]
> Sent: 22 October 2014 14:29
> To: Benoit Claise
> Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org;
> rtg-ads@to= ols.ietf.org
> Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled
>
>
>       This is hugely disappointing. This is the ki= nd of procedural non-sense
has
> and IS driving people away from the IETF to other places where this wo= rk is
going
> to get done. The simple effect of such silliness will be a reduction i= n speed
and
> quantity of model development.  If the goal of the IESG is to slo= w down the
> velocity of model development and creation, then this approach is perf= ect.
>
>       For the record, the interim NETMOD meeting c= adence has one meeting
> focused on Yang and the other on modeling; is not NETMOD-specific per = say, but
> to promote model creation because no other bi-weekly forum exists to d= o so. It
> is also a place to bring in non-IETF work such as the work done in ODL= , other
open
> source, or just the public community that has explicitly wanted to avo= id the
IETF.
> We have found it a convenient and fruitful place to discuss, and actua= lly
*build*
> models - regardless of their ultimate WG home.  The simple reason= : its a
single
> place for many of the experts to gather. I think you will find it very=
difficult to get
> those people onto a per-WG call every other week.
>
>       I hope the IESG considers this approach care= fully because I do not think
it
> will have the affect the larger IETF community is interested in.
>
>       --Tom
>
>
>
> > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise <bclaise@cisco.com>
wrote:
> >
> > Dear all,
> >
> > Today NETMOD interim meeting is canceled.
> >
> > I received some pushbacks from the routing ADs, on the ground tha= t:
> > 1. This interim appears to be meeting to discuss a non-WG draft f= or which
there
> is no milestone in the working group and for which there is an obvious= home
> outside the working group.
> > 2. The agenda was not announced a week in advance on the IETF ann= ounce list
> as is required
> >
> > Regards, Benoit
> >
> > _______________________________________________
> > Rtg-yang-coord mailing list
> > Rtg-= yang-coord@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtg-yang-coord<= br> > >

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



--001a113a6bf6c04804050603ffa4-- From nobody Wed Oct 22 07:52:24 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF301ACD12; Wed, 22 Oct 2014 07:52: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, 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 6RRXURlFACpR; Wed, 22 Oct 2014 07:52:12 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 292901ACD15; Wed, 22 Oct 2014 07:52:10 -0700 (PDT) Received: from [192.168.1.123] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 9C87428D0AA9; Wed, 22 Oct 2014 10:52:09 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_C74652FA-355E-4A63-A2A8-ABAB9D42EE76" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: "Thomas D. Nadeau" In-Reply-To: Date: Wed, 22 Oct 2014 10:52:09 -0400 Message-Id: References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> To: Andy Bierman X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/yeqjFmWaAic0Gjd00g2maX6v-DM Cc: Rtg-yang-coord@ietf.org, NETMOD Working Group , ospf-chairs@tools.ietf.org, ops-ads@tools.ietf.org, rtg-ads@tools.ietf.org, Farrel Adrian Subject: Re: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2014 14:52:17 -0000 --Apple-Mail=_C74652FA-355E-4A63-A2A8-ABAB9D42EE76 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 We are trying. The thing is that you cannot just hoist that onto = WGs and say =93here you go.=94 if they don=92t want to do it. Again, = the Netmod charter was specifically modified to accommodate that case. = And while some WGs in the routing area are not enthusiastic about = building models, others aren=92t, nor are other WGs at the IETF. So for = those, what do you do? Ignore them? The other point is that others = outside of the IETF are working on these models. It is squarely within = the IETF community=92s interest to bring these back into the fold. Many = of these folks are skittish about coming to the IETF altogether so we=92ve= tried to encourage them to participate in this way. If we want to push = these folks away with procedural reasons, then we have made our bed... =97tom > On Oct 22, 2014:10:45 AM, at 10:45 AM, Andy Bierman = wrote: >=20 > Hi, >=20 > I think the interim did not need to be cancelled. There are ACL, = SYSLOG, > and YANG Mount topics. I was going to call in for those, not OSPF. > But I have been saying (for over a year now) that it is time to move > domain-specific data models into the domain-specific WGs. > I think NETMOD WG should focus on the YANG language and > infrastructure modules. >=20 > Andy >=20 >=20 > On Wed, Oct 22, 2014 at 7:35 AM, Thomas D. Nadeau = > wrote: >=20 > No one said that OSPF experts could not attend to provide input. = The issue is that OSPF was not doing this. If they want to take over = doing all OSPF models, then great, but to date no one was. The = agreement in NETMOD (and our charter) is to facilitate the creation of = models when WGs don=92t want to do them, have the expertise to do them, = etc=85 Also, getting the right Yang experts in one place is not going = to happen for every WG in the IETF; its just not realistic. I = understand that ultimately the WG needs to have consensus, but quick = iteration to construct the model surely can happen in a small =93design = team=94 fashion, right? >=20 > And in terms of today=92s meeting being canceled, really what = purpose was that other than to stall/slow-down work? The group that was = there to work on the OSPF model was indeed a bunch of folks from OSPF = (Acee Lindem for example was on the call). So now since we won=92t have = another interim meeting until after Hawaii, so the next time this group = can get together is possibly in Hawaii, but that is probably unlikely as = a large number of people are not going to Hawaii. So the net-net is a = slowing of progress in this area. Probably not the result the IETF = community wants. >=20 > =97Tom >=20 >=20 >=20 >> On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman = > wrote: >>=20 >> Hi Adrian, >>=20 >> I agree with you. The OSPF WG should be discussing OSPF data models, >> not the NETMOD WG. The domain experts need to reach consensus >> on a feature set (and maybe info model) and then get 1 or 2 YANG = experts to >> help translate that to a data model. (Not the other way around -- a = room >> full of YANG experts and 1 or 2 OSPF experts). >>=20 >> I also prefer that virtual interim meetings be used to discuss open = issues >> on chartered items, not as an additional forum to promote individual = drafts. >>=20 >>=20 >> Andy >>=20 >>=20 >> On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel > wrote: >> I understand and appreciate your desire to get work done. >>=20 >> The rules for IETF virtual interims are neither hard to discover, nor = hard to >> comply with. The rules exist to ensure that people are included in = the work, and >> I am sure that inclusion is what you want. >>=20 >> I find it unfortunate that you scheduled a working group meeting to = discuss only >> one of a pair of competing documents on the same topic, that you = didn't make the >> information about the meeting available to the authors of the = competing document >> or to the people who care about the protocol being modelled, and I = find it >> upsetting (yes, I am actually upset) that you decided to discuss in = Netmod a >> document that belongs in the OSPF working group. >>=20 >> If, as it surely sounds, you wish that the Netmod working group had a = different >> charter to enable it to take on models for protocols that already = have a home in >> other working groups, then I suggest you need to recharter. But I = doubt that >> your reasoning that [YANG] experts will not go to all the other = working groups >> will carry much weight. Frankly, and without wanting to disrespect = the YANG >> experts, it is easier to understand YANG than it is to understand = OSPF. If this >> were not the case then the Netmod working group would have failed in = its design >> of YANG! >>=20 >> Conclusion: >> You want to work on a YANG model for OSPF. Go to the OSPF working = group and >> discuss it (there are already some threads). Review and comment on = the competing >> document. Try to get agreement between all of the authors of both = documents, or >> try to identify the differences. Work with the chairs of the OSPF = working group >> to advance the work. >>=20 >> Adrian >>=20 >> > -----Original Message----- >> > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com = ] >> > Sent: 22 October 2014 14:29 >> > To: Benoit Claise >> > Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org = ; ops-ads@tools.ietf.org = ; >> > rtg-ads@tools.ietf.org >> > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled >> > >> > >> > This is hugely disappointing. This is the kind of procedural = non-sense >> has >> > and IS driving people away from the IETF to other places where this = work is >> going >> > to get done. The simple effect of such silliness will be a = reduction in speed >> and >> > quantity of model development. If the goal of the IESG is to slow = down the >> > velocity of model development and creation, then this approach is = perfect. >> > >> > For the record, the interim NETMOD meeting cadence has one = meeting >> > focused on Yang and the other on modeling; is not NETMOD-specific = per say, but >> > to promote model creation because no other bi-weekly forum exists = to do so. It >> > is also a place to bring in non-IETF work such as the work done in = ODL, other >> open >> > source, or just the public community that has explicitly wanted to = avoid the >> IETF. >> > We have found it a convenient and fruitful place to discuss, and = actually >> *build* >> > models - regardless of their ultimate WG home. The simple reason: = its a >> single >> > place for many of the experts to gather. I think you will find it = very >> difficult to get >> > those people onto a per-WG call every other week. >> > >> > I hope the IESG considers this approach carefully because I = do not think >> it >> > will have the affect the larger IETF community is interested in. >> > >> > --Tom >> > >> > >> > >> > > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise = > >> wrote: >> > > >> > > Dear all, >> > > >> > > Today NETMOD interim meeting is canceled. >> > > >> > > I received some pushbacks from the routing ADs, on the ground = that: >> > > 1. This interim appears to be meeting to discuss a non-WG draft = for which >> there >> > is no milestone in the working group and for which there is an = obvious home >> > outside the working group. >> > > 2. The agenda was not announced a week in advance on the IETF = announce list >> > as is required >> > > >> > > Regards, Benoit >> > > >> > > _______________________________________________ >> > > Rtg-yang-coord mailing list >> > > Rtg-yang-coord@ietf.org >> > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord = >> > > >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod = >>=20 >=20 >=20 --Apple-Mail=_C74652FA-355E-4A63-A2A8-ABAB9D42EE76 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

We are = trying. The thing is that you cannot just hoist that onto WGs and say = =93here you go.=94 if they don=92t want to do it.  Again, the = Netmod charter was specifically modified to accommodate that case. =   And while some WGs in the routing area are not enthusiastic about = building models, others aren=92t, nor are other WGs at the IETF. So for = those, what do you do? Ignore them? The other point is that others = outside of the IETF are working on these models.  It is squarely = within the IETF community=92s interest to bring these back into the = fold.  Many of these folks are skittish about coming to the IETF = altogether so we=92ve tried to encourage them to participate in this = way. If we want to push these folks away with procedural reasons, then = we have made our bed...

= =97tom



On Oct 22, 2014:10:45 AM, at = 10:45 AM, Andy Bierman <andy@yumaworks.com> wrote:

Hi,

I = think the interim did not need to be cancelled. There are ACL, = SYSLOG,
and YANG Mount topics. I was going to call = in for those, not OSPF.
But I have been saying (for = over a year now) that it is time to move
domain-specific data models into the domain-specific = WGs.
I think NETMOD WG should focus on the YANG = language and
infrastructure modules.

Andy


On Wed, Oct 22, 2014 at 7:35 AM, Thomas D. Nadeau = <tnadeau@lucidvision.com> wrote:

= No one said that OSPF experts could not attend to provide input. =   The issue is that OSPF was not doing this. If they want to take = over doing all OSPF models, then great, but to date no one was.  = The agreement in NETMOD (and our charter) is to facilitate the creation = of models when WGs don=92t want to do them, have the expertise to do = them, etc=85  Also, getting the right Yang experts in one place is = not going to happen for every WG in the IETF; its just not = realistic.  I understand that ultimately the WG needs to have = consensus, but quick iteration to construct the model surely can happen = in a small =93design team=94 fashion, right?

And in terms of today=92s meeting being canceled, = really what purpose was that other than to stall/slow-down work?  = The group that was there to work on the OSPF model was indeed a bunch of = folks from OSPF (Acee Lindem for example was on the call).  So now = since we won=92t have another interim meeting until after Hawaii, so the = next time this group can get together is possibly in Hawaii, but that is = probably unlikely as a large number of people are not going to = Hawaii.  So the net-net is a slowing of progress in this = area.  Probably not the result the IETF community wants.

=97Tom



On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy = Bierman <andy@yumaworks.com> wrote:

Hi Adrian,

I agree with you. The OSPF WG should be = discussing OSPF data models,
not the NETMOD WG. The = domain experts need to reach consensus
on a feature = set (and maybe info model) and then get 1 or 2 YANG experts to
help translate that to a data model. (Not the other way = around -- a room
full of YANG experts and 1 or 2 = OSPF experts).

I= also prefer that virtual interim meetings be used to discuss open = issues
on chartered items, not as an additional = forum to promote individual drafts.


Andy


On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel = <adrian@olddog.co.uk> = wrote:
I understand and = appreciate your desire to get work done.

The rules for IETF virtual interims are neither hard to discover, nor = hard to
comply with. The rules exist to ensure that people are included in the = work, and
I am sure that inclusion is what you want.

I find it unfortunate that you scheduled a working group meeting to = discuss only
one of a pair of competing documents on the same topic, that you didn't = make the
information about the meeting available to the authors of the competing = document
or to the people who care about the protocol being modelled, and I find = it
upsetting (yes, I am actually upset) that you decided to discuss in = Netmod a
document that belongs in the OSPF working group.

If, as it surely sounds, you wish that the Netmod working group had a = different
charter to enable it to take on models for protocols that already have a = home in
other working groups, then I suggest you need to recharter. But I doubt = that
your reasoning that [YANG] experts will not go to all the other working = groups
will carry much weight. Frankly, and without wanting to disrespect the = YANG
experts, it is easier to understand YANG than it is to understand OSPF. = If this
were not the case then the Netmod working group would have failed in its = design
of YANG!

Conclusion:
You want to work on a YANG model for OSPF. Go to the OSPF working group = and
discuss it (there are already some threads). Review and comment on the = competing
document. Try to get agreement between all of the authors of both = documents, or
try to identify the differences. Work with the chairs of the OSPF = working group
to advance the work.

Adrian

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com]
> Sent: 22 October 2014 14:29
> To: Benoit Claise
> Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org;
> rtg-ads@tools.ietf.org
> Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled
>
>
>       This is hugely disappointing. This is the = kind of procedural non-sense
has
> and IS driving people away from the IETF to other places where this = work is
going
> to get done. The simple effect of such silliness will be a = reduction in speed
and
> quantity of model development.  If the goal of the IESG is to = slow down the
> velocity of model development and creation, then this approach is = perfect.
>
>       For the record, the interim NETMOD = meeting cadence has one meeting
> focused on Yang and the other on modeling; is not NETMOD-specific = per say, but
> to promote model creation because no other bi-weekly forum exists = to do so. It
> is also a place to bring in non-IETF work such as the work done in = ODL, other
open
> source, or just the public community that has explicitly wanted to = avoid the
IETF.
> We have found it a convenient and fruitful place to discuss, and = actually
*build*
> models - regardless of their ultimate WG home.  The simple = reason: its a
single
> place for many of the experts to gather. I think you will find it = very
difficult to get
> those people onto a per-WG call every other week.
>
>       I hope the IESG considers this approach = carefully because I do not think
it
> will have the affect the larger IETF community is interested in.
>
>       --Tom
>
>
>
> > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise <bclaise@cisco.com>
wrote:
> >
> > Dear all,
> >
> > Today NETMOD interim meeting is canceled.
> >
> > I received some pushbacks from the routing ADs, on the ground = that:
> > 1. This interim appears to be meeting to discuss a non-WG = draft for which
there
> is no milestone in the working group and for which there is an = obvious home
> outside the working group.
> > 2. The agenda was not announced a week in advance on the IETF = announce list
> as is required
> >
> > Regards, Benoit
> >
> > _______________________________________________
> > Rtg-yang-coord mailing list
> > Rtg-yang-coord@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtg-yang-coord
> >

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




= --Apple-Mail=_C74652FA-355E-4A63-A2A8-ABAB9D42EE76-- From nobody Wed Oct 22 08:00:01 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2D71ACD38 for ; Wed, 22 Oct 2014 07:59: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 9Io8y_07GBrG for ; Wed, 22 Oct 2014 07:59:52 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE6D41ACD4B for ; Wed, 22 Oct 2014 07:59:27 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id k15so2493328qaq.24 for ; Wed, 22 Oct 2014 07:59:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Cj3iGMcMU1VSzipn6wkc6g/zNkij9oG3/SQEhvc1fZE=; b=lZGu2FmCIbkmOiTLZKynVwCbrKE9YT5DPrpctIQRBAoAXfxL2mmjmuQt4OoJLsfwuq wUV8AGhy6eMfGtOIEZ1owxMSVr5zWW8OZqpfkMbLov4HFwVMoTxyIVlQ98GgF7jOFdQM DfxyYzvo7X1MUpTZpECaGDsqM4wNXttV6O4ziY3DzMIBsKEGIPI+0wg7HPbhkSm+rnvE L4QMZPHKT7VQA7aJFuv5/9HyREbI9LHeKfi76JEiyP05u6n8OZ9PZj1be50I6xxGhpjw cNjSgRuCbVvGZc0O4H4y2lbMvSfgDIwiT6jUgdGZgDcLIZwI0PPlyImk+CrG8W3923VB W8fQ== X-Gm-Message-State: ALoCoQlj1SiPq5f/C4EPpp2glwsDcPV+Dm75jyjBa2kMHkBFXK2VA8BAs8/kCB0JJoY7cF6RSKXx MIME-Version: 1.0 X-Received: by 10.140.88.177 with SMTP id t46mr45031595qgd.36.1413989967045; Wed, 22 Oct 2014 07:59:27 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Wed, 22 Oct 2014 07:59:26 -0700 (PDT) In-Reply-To: References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> Date: Wed, 22 Oct 2014 07:59:26 -0700 Message-ID: From: Andy Bierman To: "Thomas D. Nadeau" Content-Type: multipart/alternative; boundary=001a11c13e4ab3c26605060431fa Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/T0UXRPay6D83fW0-XAY57UHMxRg Cc: Rtg-yang-coord@ietf.org, NETMOD Working Group , ospf-chairs@tools.ietf.org, ops-ads@tools.ietf.org, rtg-ads@tools.ietf.org, Farrel Adrian Subject: Re: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2014 14:59:58 -0000 --001a11c13e4ab3c26605060431fa Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 22, 2014 at 7:52 AM, Thomas D. Nadeau wrote: > > We are trying. The thing is that you cannot just hoist that onto WGs and > say "here you go." if they don't want to do it. Again, the Netmod charter > was specifically modified to accommodate that case. And while some WGs in > the routing area are not enthusiastic about building models, others aren't, > nor are other WGs at the IETF. So for those, what do you do? Ignore them? > The other point is that others outside of the IETF are working on these > models. It is squarely within the IETF community's interest to bring these > back into the fold. Many of these folks are skittish about coming to the > IETF altogether so we've tried to encourage them to participate in this > way. If we want to push these folks away with procedural reasons, then we > have made our bed... > > This "network management scope" discussion has been going on since the early days of SNMP. It's up to the people approving WG charters to ask for configuration, not just monitoring. It's up to the WG members to agree on a common subset of configuration parameters. NETMOD WG can help with the YANG details. --tom > > Andy > > > On Oct 22, 2014:10:45 AM, at 10:45 AM, Andy Bierman > wrote: > > Hi, > > I think the interim did not need to be cancelled. There are ACL, SYSLOG, > and YANG Mount topics. I was going to call in for those, not OSPF. > But I have been saying (for over a year now) that it is time to move > domain-specific data models into the domain-specific WGs. > I think NETMOD WG should focus on the YANG language and > infrastructure modules. > > Andy > > > On Wed, Oct 22, 2014 at 7:35 AM, Thomas D. Nadeau > wrote: > >> >> No one said that OSPF experts could not attend to provide input. The >> issue is that OSPF was not doing this. If they want to take over doing all >> OSPF models, then great, but to date no one was. The agreement in NETMOD >> (and our charter) is to facilitate the creation of models when WGs don't >> want to do them, have the expertise to do them, etc... Also, getting the >> right Yang experts in one place is not going to happen for every WG in the >> IETF; its just not realistic. I understand that ultimately the WG needs to >> have consensus, but quick iteration to construct the model surely can >> happen in a small "design team" fashion, right? >> >> And in terms of today's meeting being canceled, really what purpose was >> that other than to stall/slow-down work? The group that was there to work >> on the OSPF model was indeed a bunch of folks from OSPF (Acee Lindem for >> example was on the call). So now since we won't have another interim >> meeting until after Hawaii, so the next time this group can get together is >> possibly in Hawaii, but that is probably unlikely as a large number of >> people are not going to Hawaii. So the net-net is a slowing of progress in >> this area. Probably not the result the IETF community wants. >> >> --Tom >> >> >> >> On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman >> wrote: >> >> Hi Adrian, >> >> I agree with you. The OSPF WG should be discussing OSPF data models, >> not the NETMOD WG. The domain experts need to reach consensus >> on a feature set (and maybe info model) and then get 1 or 2 YANG experts >> to >> help translate that to a data model. (Not the other way around -- a room >> full of YANG experts and 1 or 2 OSPF experts). >> >> I also prefer that virtual interim meetings be used to discuss open issues >> on chartered items, not as an additional forum to promote individual >> drafts. >> >> >> Andy >> >> >> On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel >> wrote: >> >>> I understand and appreciate your desire to get work done. >>> >>> The rules for IETF virtual interims are neither hard to discover, nor >>> hard to >>> comply with. The rules exist to ensure that people are included in the >>> work, and >>> I am sure that inclusion is what you want. >>> >>> I find it unfortunate that you scheduled a working group meeting to >>> discuss only >>> one of a pair of competing documents on the same topic, that you didn't >>> make the >>> information about the meeting available to the authors of the competing >>> document >>> or to the people who care about the protocol being modelled, and I find >>> it >>> upsetting (yes, I am actually upset) that you decided to discuss in >>> Netmod a >>> document that belongs in the OSPF working group. >>> >>> If, as it surely sounds, you wish that the Netmod working group had a >>> different >>> charter to enable it to take on models for protocols that already have a >>> home in >>> other working groups, then I suggest you need to recharter. But I doubt >>> that >>> your reasoning that [YANG] experts will not go to all the other working >>> groups >>> will carry much weight. Frankly, and without wanting to disrespect the >>> YANG >>> experts, it is easier to understand YANG than it is to understand OSPF. >>> If this >>> were not the case then the Netmod working group would have failed in its >>> design >>> of YANG! >>> >>> Conclusion: >>> You want to work on a YANG model for OSPF. Go to the OSPF working group >>> and >>> discuss it (there are already some threads). Review and comment on the >>> competing >>> document. Try to get agreement between all of the authors of both >>> documents, or >>> try to identify the differences. Work with the chairs of the OSPF >>> working group >>> to advance the work. >>> >>> Adrian >>> >>> > -----Original Message----- >>> > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com] >>> > Sent: 22 October 2014 14:29 >>> > To: Benoit Claise >>> > Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; >>> ops-ads@tools.ietf.org; >>> > rtg-ads@tools.ietf.org >>> > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled >>> > >>> > >>> > This is hugely disappointing. This is the kind of procedural >>> non-sense >>> has >>> > and IS driving people away from the IETF to other places where this >>> work is >>> going >>> > to get done. The simple effect of such silliness will be a reduction >>> in speed >>> and >>> > quantity of model development. If the goal of the IESG is to slow >>> down the >>> > velocity of model development and creation, then this approach is >>> perfect. >>> > >>> > For the record, the interim NETMOD meeting cadence has one >>> meeting >>> > focused on Yang and the other on modeling; is not NETMOD-specific per >>> say, but >>> > to promote model creation because no other bi-weekly forum exists to >>> do so. It >>> > is also a place to bring in non-IETF work such as the work done in >>> ODL, other >>> open >>> > source, or just the public community that has explicitly wanted to >>> avoid the >>> IETF. >>> > We have found it a convenient and fruitful place to discuss, and >>> actually >>> *build* >>> > models - regardless of their ultimate WG home. The simple reason: its >>> a >>> single >>> > place for many of the experts to gather. I think you will find it very >>> difficult to get >>> > those people onto a per-WG call every other week. >>> > >>> > I hope the IESG considers this approach carefully because I do >>> not think >>> it >>> > will have the affect the larger IETF community is interested in. >>> > >>> > --Tom >>> > >>> > >>> > >>> > > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise < >>> bclaise@cisco.com> >>> wrote: >>> > > >>> > > Dear all, >>> > > >>> > > Today NETMOD interim meeting is canceled. >>> > > >>> > > I received some pushbacks from the routing ADs, on the ground that: >>> > > 1. This interim appears to be meeting to discuss a non-WG draft for >>> which >>> there >>> > is no milestone in the working group and for which there is an obvious >>> home >>> > outside the working group. >>> > > 2. The agenda was not announced a week in advance on the IETF >>> announce list >>> > as is required >>> > > >>> > > Regards, Benoit >>> > > >>> > > _______________________________________________ >>> > > Rtg-yang-coord mailing list >>> > > Rtg-yang-coord@ietf.org >>> > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord >>> > > >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> >> >> >> > > --001a11c13e4ab3c26605060431fa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Wed, Oct 22, 2014 at 7:52 AM, Thomas D. Nadeau <= ;tnadeau@lucid= vision.com> wrote:

We are trying. The thing is that you cannot just hoist th= at onto WGs and say “here you go.” if they don’t want to = do it.  Again, the Netmod charter was specifically modified to accommo= date that case.   And while some WGs in the routing area are not enthu= siastic about building models, others aren’t, nor are other WGs at th= e IETF. So for those, what do you do? Ignore them? The other point is that = others outside of the IETF are working on these models.  It is squarel= y within the IETF community’s interest to bring these back into the f= old.  Many of these folks are skittish about coming to the IETF altoge= ther so we’ve tried to encourage them to participate in this way. If = we want to push these folks away with procedural reasons, then we have made= our bed...


This= "network management scope" discussion has been going on since
the early days of SNMP.  It's up to the people approving W= G charters
to ask for configuration, not just monitoring. It'= s up to the WG members
to agree on a common subset of configurati= on parameters. NETMOD WG
can help with the YANG details.


—tom


= Andy
 


On Oct 22, 2014:10:45 AM, at 10:45 AM, Andy Bierman <andy@yumaworks.com>= wrote:

Hi,

I think the i= nterim did not need to be cancelled. There are ACL, SYSLOG,
and Y= ANG Mount topics. I was going to call in for those, not OSPF.
But= I have been saying (for over a year now) that it is time to move
domain-specific data models into the domain-specific WGs.
I thin= k NETMOD WG should focus on the YANG language and
infrastructure = modules.

Andy


On Wed, Oct 22, 2014 at 7:35 AM, Thomas= D. Nadeau <tnadeau@lucidvision.com> wrote:

= No one said that OSPF experts = could not attend to provide input.   The issue is that OSPF was not do= ing this. If they want to take over doing all OSPF models, then great, but = to date no one was.  The agreement in NETMOD (and our charter) is to f= acilitate the creation of models when WGs don’t want to do them, have= the expertise to do them, etc…  Also, getting the right Yang e= xperts in one place is not going to happen for every WG in the IETF; its ju= st not realistic.  I understand that ultimately the WG needs to have c= onsensus, but quick iteration to construct the model surely can happen in a= small “design team” fashion, right?

And in terms of today’s meeting= being canceled, really what purpose was that other than to stall/slow-down= work?  The group that was there to work on the OSPF model was indeed = a bunch of folks from OSPF (Acee Lindem for example was on the call). = So now since we won’t have another interim meeting until after Hawai= i, so the next time this group can get together is possibly in Hawaii, but = that is probably unlikely as a large number of people are not going to Hawa= ii.  So the net-net is a slowing of progress in this area.  Proba= bly not the result the IETF community wants.

—Tom

<= br>

On Oct 22, 2014:10:18= AM, at 10:18 AM, Andy Bierman <andy@yumaworks.com> wrote:

Hi Adrian,

I agree with you. The OSPF WG should be= discussing OSPF data models,
not the NETMOD WG. The domain exper= ts need to reach consensus
on a feature set (and maybe info model= ) and then get 1 or 2 YANG experts to
help translate that to a da= ta model. (Not the other way around -- a room
full of YANG expert= s and 1 or 2 OSPF experts).

I also prefer that vir= tual interim meetings be used to discuss open issues
on chartered= items, not as an additional forum to promote individual drafts.
=

Andy


On Wed, Oct 22, 2014 at 6:4= 8 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:
I understand and appreciate your desire to get wor= k done.

The rules for IETF virtual interims are neither hard to discover, nor hard = to
comply with. The rules exist to ensure that people are included in the work= , and
I am sure that inclusion is what you want.

I find it unfortunate that you scheduled a working group meeting to discuss= only
one of a pair of competing documents on the same topic, that you didn't= make the
information about the meeting available to the authors of the competing doc= ument
or to the people who care about the protocol being modelled, and I find it<= br> upsetting (yes, I am actually upset) that you decided to discuss in Netmod = a
document that belongs in the OSPF working group.

If, as it surely sounds, you wish that the Netmod working group had a diffe= rent
charter to enable it to take on models for protocols that already have a ho= me in
other working groups, then I suggest you need to recharter. But I doubt tha= t
your reasoning that [YANG] experts will not go to all the other working gro= ups
will carry much weight. Frankly, and without wanting to disrespect the YANG=
experts, it is easier to understand YANG than it is to understand OSPF. If = this
were not the case then the Netmod working group would have failed in its de= sign
of YANG!

Conclusion:
You want to work on a YANG model for OSPF. Go to the OSPF working group and=
discuss it (there are already some threads). Review and comment on the comp= eting
document. Try to get agreement between all of the authors of both documents= , or
try to identify the differences. Work with the chairs of the OSPF working g= roup
to advance the work.

Adrian

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com]
> Sent: 22 October 2014 14:29
> To: Benoit Claise
> Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org;
> rtg-ads@to= ols.ietf.org
> Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled
>
>
>       This is hugely disappointing. This is the ki= nd of procedural non-sense
has
> and IS driving people away from the IETF to other places where this wo= rk is
going
> to get done. The simple effect of such silliness will be a reduction i= n speed
and
> quantity of model development.  If the goal of the IESG is to slo= w down the
> velocity of model development and creation, then this approach is perf= ect.
>
>       For the record, the interim NETMOD meeting c= adence has one meeting
> focused on Yang and the other on modeling; is not NETMOD-specific per = say, but
> to promote model creation because no other bi-weekly forum exists to d= o so. It
> is also a place to bring in non-IETF work such as the work done in ODL= , other
open
> source, or just the public community that has explicitly wanted to avo= id the
IETF.
> We have found it a convenient and fruitful place to discuss, and actua= lly
*build*
> models - regardless of their ultimate WG home.  The simple reason= : its a
single
> place for many of the experts to gather. I think you will find it very=
difficult to get
> those people onto a per-WG call every other week.
>
>       I hope the IESG considers this approach care= fully because I do not think
it
> will have the affect the larger IETF community is interested in.
>
>       --Tom
>
>
>
> > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise <bclaise@cisco.com>
wrote:
> >
> > Dear all,
> >
> > Today NETMOD interim meeting is canceled.
> >
> > I received some pushbacks from the routing ADs, on the ground tha= t:
> > 1. This interim appears to be meeting to discuss a non-WG draft f= or which
there
> is no milestone in the working group and for which there is an obvious= home
> outside the working group.
> > 2. The agenda was not announced a week in advance on the IETF ann= ounce list
> as is required
> >
> > Regards, Benoit
> >
> > _______________________________________________
> > Rtg-yang-coord mailing list
> > Rtg-= yang-coord@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtg-yang-coord<= br> > >

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





--001a11c13e4ab3c26605060431fa-- From nobody Wed Oct 22 08:06:23 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAC911ACD1E; Wed, 22 Oct 2014 08:03:16 -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 YRHDWUaWCG-n; Wed, 22 Oct 2014 08:03:10 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0105.outbound.protection.outlook.com [65.55.169.105]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2BE61ACD2A; Wed, 22 Oct 2014 08:03:09 -0700 (PDT) Received: from BN1PR05MB156.namprd05.prod.outlook.com (10.255.205.20) by BN1PR05MB076.namprd05.prod.outlook.com (10.255.199.26) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Wed, 22 Oct 2014 15:03:08 +0000 Received: from [172.29.33.235] (66.129.241.14) by BN1PR05MB156.namprd05.prod.outlook.com (10.255.205.20) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Wed, 22 Oct 2014 15:03:03 +0000 MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset="windows-1252" From: Jeff Haas In-Reply-To: Date: Wed, 22 Oct 2014 11:02:40 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> To: "Thomas D. Nadeau" X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: CY1PR00CA0040.namprd00.prod.outlook.com (25.160.142.178) To BN1PR05MB156.namprd05.prod.outlook.com (10.255.205.20) X-Microsoft-Antispam: UriScan:;UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB156; X-Exchange-Antispam-Report-Test: UriScan:; X-Forefront-PRVS: 037291602B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(199003)(51704005)(377454003)(189002)(24454002)(40100003)(76176999)(82746002)(21056001)(50466002)(102836001)(31966008)(50986999)(97736003)(101416001)(110136001)(46102003)(80022003)(87976001)(62966002)(50226001)(122386002)(85306004)(19580405001)(57306001)(92726001)(86362001)(92566001)(93916002)(33656002)(87286001)(42186005)(105586002)(104166001)(20776003)(76482002)(66066001)(77156001)(89996001)(83716003)(4396001)(47776003)(85852003)(23746002)(107046002)(19580395003)(230783001)(93886004)(77096002)(36756003)(99396003)(106356001)(120916001)(95666004)(64706001)(104396001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB156; H:[172.29.33.235]; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB076; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/gfaP4WHkP7HRmdL3GlyGUjrtiZ4 X-Mailman-Approved-At: Wed, 22 Oct 2014 08:06:09 -0700 Cc: Rtg-yang-coord@ietf.org, NETMOD Working Group , ospf-chairs@tools.ietf.org, ops-ads@tools.ietf.org, rtg-ads@tools.ietf.org, Farrel Adrian Subject: Re: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2014 15:03:17 -0000 On Oct 22, 2014, at 10:52 AM, Thomas D. Nadeau = wrote: >=20 > We are trying. The thing is that you cannot just hoist that onto = WGs and say =93here you go.=94 if they don=92t want to do it. Again, = the Netmod charter was specifically modified to accommodate that case. = And while some WGs in the routing area are not enthusiastic about = building models, others aren=92t, nor are other WGs at the IETF. So for = those, what do you do? Ignore them? The other point is that others = outside of the IETF are working on these models. It is squarely within = the IETF community=92s interest to bring these back into the fold. Many = of these folks are skittish about coming to the IETF altogether so we=92ve= tried to encourage them to participate in this way. If we want to push = these folks away with procedural reasons, then we have made our bed... I've had part of this conversation with Alia recently and with many = others at the prior IETF, including Benoit. That was part of the = motivation to form the rtg-yang-coord list. Simply put, modeling work = needs to happen but the subset of people who actively care about it in = any particular WG is usually a fraction of the participants. = Additionally, the danger of doing it in netmod is overloading people who = are wanting to work on the language but don't necessarily want to = contribute to a given bit of modeling effort. I don't know that the "coord" efforts need a full WG, but the semantics = of managing that at an IETF process perspective are something the IESG = cares more about than I think I do. Basically, coord is likely to be a = bunch of dynamically spun design teams, hopefully reporting back their = lessons to someplace like this list. -- Jeff From nobody Wed Oct 22 08:09:11 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B158F1ACD26; Wed, 22 Oct 2014 08:09: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 4j_Eunw1Ry4c; Wed, 22 Oct 2014 08:09:02 -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 6DBAC1ACD41; Wed, 22 Oct 2014 08:08:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16397; q=dns/txt; s=iport; t=1413990532; x=1415200132; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=8JaLiMzXeZSJIl6+mHVQ0Ix8R+ft/MNW4vUkzgEQNGM=; b=HRZkRwYVTySyJKflXNDzvZ1lTQ1bVSH1UXhkUbRqjoJSg/SJgPRAsh0w RDQpmDePoQ1/G3+SEmzWkM/Wmza+MEePv2rvbqO2t0ZTqsGtj3sd//w6B N9oh06boeR1vW6tWE57abj2LmpxexOSDePqLnplyHNrGZykgP7C3lvKFt 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFABnIR1StJA2I/2dsb2JhbABSCoJIRlRYBMxTAQmGeVQCgQwWAX2EAgEBAQQBAQFoAwsMBAIBCBEDAQEBAScHJwsUCQgCBAENBRSILA3GDQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEj3sxGg0EBwIEhEUFkgSLWYExkHiEAYN4bIEGBD6BAwEBAQ X-IronPort-AV: E=Sophos;i="5.04,769,1406592000"; d="scan'208,217";a="365687555" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-2.cisco.com with ESMTP; 22 Oct 2014 15:08:50 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s9MF8osT006549 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Oct 2014 15:08:50 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.122]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Wed, 22 Oct 2014 10:08:50 -0500 From: "Acee Lindem (acee)" To: Andy Bierman , Adrian Farrel Thread-Topic: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled Thread-Index: AQHP7f741i3foC0Vi02jGmQDSDEWupw8fdwA///LCoA= Date: Wed, 22 Oct 2014 15:08:43 +0000 Message-ID: References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.202] Content-Type: multipart/alternative; boundary="_000_D06D40766103aceeciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/foDDGIp6lpuKjjnAwMBLGdd4AWA Cc: "Rtg-yang-coord@ietf.org" , NETMOD Working Group , "ospf-chairs@tools.ietf.org" , "ops-ads@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2014 15:09:05 -0000 --_000_D06D40766103aceeciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FWIW, The OSPF YANG model is on the agenda for IETF 91. We do plan to more = forward and poll for OSPF WG adoption as well. Thanks, Acee From: Andy Bierman > Date: Wednesday, October 22, 2014 at 10:18 AM To: Adrian Farrel > Cc: "Thomas D. Nadeau" >, "Benoit Claise (bclaise)" >, "Rtg-yang-coord@ietf.org" >, "ospf-chairs@tools.ietf.org<= mailto:ospf-chairs@tools.ietf.org>" >, "ops-ads@tools.ietf.org" >, NETMOD Work= ing Group >, Routing ADs > Subject: Re: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled Resent-From: > Resent-To: Acee Lindem >, > Resent-Date: Wednesday, October 22, 2014 at 10:18 AM Hi Adrian, I agree with you. The OSPF WG should be discussing OSPF data models, not the NETMOD WG. The domain experts need to reach consensus on a feature set (and maybe info model) and then get 1 or 2 YANG experts to help translate that to a data model. (Not the other way around -- a room full of YANG experts and 1 or 2 OSPF experts). I also prefer that virtual interim meetings be used to discuss open issues on chartered items, not as an additional forum to promote individual drafts= . Andy On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel > wrote: I understand and appreciate your desire to get work done. The rules for IETF virtual interims are neither hard to discover, nor hard = to comply with. The rules exist to ensure that people are included in the work= , and I am sure that inclusion is what you want. I find it unfortunate that you scheduled a working group meeting to discuss= only one of a pair of competing documents on the same topic, that you didn't mak= e the information about the meeting available to the authors of the competing doc= ument or to the people who care about the protocol being modelled, and I find it upsetting (yes, I am actually upset) that you decided to discuss in Netmod = a document that belongs in the OSPF working group. If, as it surely sounds, you wish that the Netmod working group had a diffe= rent charter to enable it to take on models for protocols that already have a ho= me in other working groups, then I suggest you need to recharter. But I doubt tha= t your reasoning that [YANG] experts will not go to all the other working gro= ups will carry much weight. Frankly, and without wanting to disrespect the YANG experts, it is easier to understand YANG than it is to understand OSPF. If = this were not the case then the Netmod working group would have failed in its de= sign of YANG! Conclusion: You want to work on a YANG model for OSPF. Go to the OSPF working group and discuss it (there are already some threads). Review and comment on the comp= eting document. Try to get agreement between all of the authors of both documents= , or try to identify the differences. Work with the chairs of the OSPF working g= roup to advance the work. Adrian > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com] > Sent: 22 October 2014 14:29 > To: Benoit Claise > Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org; > rtg-ads@tools.ietf.org > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled > > > This is hugely disappointing. This is the kind of procedural non-se= nse has > and IS driving people away from the IETF to other places where this work = is going > to get done. The simple effect of such silliness will be a reduction in s= peed and > quantity of model development. If the goal of the IESG is to slow down t= he > velocity of model development and creation, then this approach is perfect= . > > For the record, the interim NETMOD meeting cadence has one meeting > focused on Yang and the other on modeling; is not NETMOD-specific per say= , but > to promote model creation because no other bi-weekly forum exists to do s= o. It > is also a place to bring in non-IETF work such as the work done in ODL, o= ther open > source, or just the public community that has explicitly wanted to avoid = the IETF. > We have found it a convenient and fruitful place to discuss, and actually *build* > models - regardless of their ultimate WG home. The simple reason: its a single > place for many of the experts to gather. I think you will find it very difficult to get > those people onto a per-WG call every other week. > > I hope the IESG considers this approach carefully because I do not = think it > will have the affect the larger IETF community is interested in. > > --Tom > > > > > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise > wrote: > > > > Dear all, > > > > Today NETMOD interim meeting is canceled. > > > > I received some pushbacks from the routing ADs, on the ground that: > > 1. This interim appears to be meeting to discuss a non-WG draft for whi= ch there > is no milestone in the working group and for which there is an obvious ho= me > outside the working group. > > 2. The agenda was not announced a week in advance on the IETF announce = list > as is required > > > > Regards, Benoit > > > > _______________________________________________ > > Rtg-yang-coord mailing list > > Rtg-yang-coord@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --_000_D06D40766103aceeciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <8F0FCEF5437440489CB5A66E95971934@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
FWIW, The OSPF YANG model is on the agenda for IETF 91. We do plan to = more forward and poll for OSPF WG adoption as well. 

Thanks,
Acee 

From: Andy Bierman <andy@yumaworks.com>
Date: Wednesday, October 22, 2014 a= t 10:18 AM
To: Adrian Farrel <adrian@olddog.co.uk>
Cc: "Thomas D. Nadeau" &l= t;tnadeau@lucidvision.com>= ;, "Benoit Claise (bclaise)" <bclaise@cisco.com>, "Rtg-yang-coord@ietf.org" <Rtg-yang-coord@ietf.org= >, "ospf-chairs@tools= .ietf.org" <ospf-= chairs@tools.ietf.org>, "ops-ads@tools.ietf.org" <ops-ads@tools.ietf.org&g= t;, NETMOD Working Group <netmod@ietf= .org>, Routing ADs <rtg= -ads@tools.ietf.org>
Subject: Re: [netmod] [Rtg-yang-coo= rd] NETMOD interim meeting canceled
Resent-From: <wg-alias-bounces@tools.ietf.org> Resent-To: Acee Lindem <acee@cisco.com>, <akr@cisco.com>
Resent-Date: Wednesday, October 22,= 2014 at 10:18 AM

Hi Adrian,

I agree with you. The OSPF WG should be discussing OSPF data models,
not the NETMOD WG. The domain experts need to reach consensus
on a feature set (and maybe info model) and then get 1 or 2 YANG exper= ts to
help translate that to a data model. (Not the other way around -- a ro= om
full of YANG experts and 1 or 2 OSPF experts).

I also prefer that virtual interim meetings be used to discuss open is= sues
on chartered items, not as an additional forum to promote individual d= rafts.


Andy


On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel <= span dir=3D"ltr"> <adrian@olddog.= co.uk> wrote:
I understand and appreciate your desire to get work done.

The rules for IETF virtual interims are neither hard to discover, nor hard = to
comply with. The rules exist to ensure that people are included in the work= , and
I am sure that inclusion is what you want.

I find it unfortunate that you scheduled a working group meeting to discuss= only
one of a pair of competing documents on the same topic, that you didn't mak= e the
information about the meeting available to the authors of the competing doc= ument
or to the people who care about the protocol being modelled, and I find it<= br> upsetting (yes, I am actually upset) that you decided to discuss in Netmod = a
document that belongs in the OSPF working group.

If, as it surely sounds, you wish that the Netmod working group had a diffe= rent
charter to enable it to take on models for protocols that already have a ho= me in
other working groups, then I suggest you need to recharter. But I doubt tha= t
your reasoning that [YANG] experts will not go to all the other working gro= ups
will carry much weight. Frankly, and without wanting to disrespect the YANG=
experts, it is easier to understand YANG than it is to understand OSPF. If = this
were not the case then the Netmod working group would have failed in its de= sign
of YANG!

Conclusion:
You want to work on a YANG model for OSPF. Go to the OSPF working group and=
discuss it (there are already some threads). Review and comment on the comp= eting
document. Try to get agreement between all of the authors of both documents= , or
try to identify the differences. Work with the chairs of the OSPF working g= roup
to advance the work.

Adrian

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com]
> Sent: 22 October 2014 14:29
> To: Benoit Claise
> Cc: NETMOD Working Group; R= tg-yang-coord@ietf.org; ops-ads@tools.ietf.org;
> rtg-ads@tools.ietf.org > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled
>
>
>       This is hugely disappointing. This is the ki= nd of procedural non-sense
has
> and IS driving people away from the IETF to other places where this wo= rk is
going
> to get done. The simple effect of such silliness will be a reduction i= n speed
and
> quantity of model development.  If the goal of the IESG is to slo= w down the
> velocity of model development and creation, then this approach is perf= ect.
>
>       For the record, the interim NETMOD meeting c= adence has one meeting
> focused on Yang and the other on modeling; is not NETMOD-specific per = say, but
> to promote model creation because no other bi-weekly forum exists to d= o so. It
> is also a place to bring in non-IETF work such as the work done in ODL= , other
open
> source, or just the public community that has explicitly wanted to avo= id the
IETF.
> We have found it a convenient and fruitful place to discuss, and actua= lly
*build*
> models - regardless of their ultimate WG home.  The simple reason= : its a
single
> place for many of the experts to gather. I think you will find it very=
difficult to get
> those people onto a per-WG call every other week.
>
>       I hope the IESG considers this approach care= fully because I do not think
it
> will have the affect the larger IETF community is interested in.
>
>       --Tom
>
>
>
> > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise <bclaise@cisco.com>
wrote:
> >
> > Dear all,
> >
> > Today NETMOD interim meeting is canceled.
> >
> > I received some pushbacks from the routing ADs, on the ground tha= t:
> > 1. This interim appears to be meeting to discuss a non-WG draft f= or which
there
> is no milestone in the working group and for which there is an obvious= home
> outside the working group.
> > 2. The agenda was not announced a week in advance on the IETF ann= ounce list
> as is required
> >
> > Regards, Benoit
> >
> > _______________________________________________
> > Rtg-yang-coord mailing list
> > Rtg-yang-coord@ietf.or= g
> > https://www.ietf.org/mailman/listinfo/rtg-yang-coord
> >

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

 --_000_D06D40766103aceeciscocom_-- From nobody Wed Oct 22 08:20:33 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7889A1ACD4E; Wed, 22 Oct 2014 08:20:25 -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 l-kjSorJUC-d; Wed, 22 Oct 2014 08:20:18 -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 E13C01ACD5D; Wed, 22 Oct 2014 08:20:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26159; q=dns/txt; s=iport; t=1413991217; x=1415200817; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=/7fCZJ3P5Qv1a4X7kECSHMXQ4CQgQKjreQx8brnhbvs=; b=VWXjwyVNSo9HTrf7Jk71ldv8Oj/McV1sbMWAUG8Og+/ENY2Bnbt0gfiQ mzVVur79qctyao5a8lNwRWPmmZPiGLDvKIoCntKYIVXY07N6NuA5m+sk9 OOZyNFhbGrN7f9mKAyC2/6Uw6daFhG/+qAREzkWQ164phoVq1vNI2K5CO 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFADzKR1StJA2F/2dsb2JhbABSCoJIRlRYBMxTAQmGeVQCgQwWAX2EAgEBAQQBAQEqPgMLDAQCAQgRBAEBAQoWBwcnCxQJCAIEAQ0FCAwLiCENxhABAQEBAQEBAQEBAQEBAQEBAQEBAQETBIpWhSUrLQQGAQaDJ4EeBY9mgh6NCpB4hAGDeGyBBgQ+gQMBAQE X-IronPort-AV: E=Sophos; i="5.04,769,1406592000"; d="scan'208,217"; a="89367887" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-4.cisco.com with ESMTP; 22 Oct 2014 15:20:14 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s9MFKE5M006119 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Oct 2014 15:20:14 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.189]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Wed, 22 Oct 2014 10:20:14 -0500 From: "Eric Voit (evoit)" To: "Thomas D. Nadeau" , Andy Bierman Thread-Topic: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled Thread-Index: AQHP7gfB9u4QKYuEX+hUMOEGGRuotpw8OMTQ Date: Wed, 22 Oct 2014 15:20:13 +0000 Message-ID: References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.134.135] Content-Type: multipart/alternative; boundary="_000_EF64FF31F4C4384DBCE5D513A791C2B120A5635Exmbalnx11ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ATwZwMCZN-h8QkdeQqnXHzCROGc Cc: "Rtg-yang-coord@ietf.org" , NETMOD Working Group , "ospf-chairs@tools.ietf.org" , "ops-ads@tools.ietf.org" , "rtg-ads@tools.ietf.org" , Farrel Adrian Subject: Re: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2014 15:20:25 -0000 --_000_EF64FF31F4C4384DBCE5D513A791C2B120A5635Exmbalnx11ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As Tom and others note, today's Netmod interim was to have topics beyond OS= PF. These included OpenDaylight related work. The IETF should be encoura= ging venues for Open Source developer audiences. Cancelling full meetings = via IETF procedural mechanisms signals the opposite. I *like* the idea of each WG being the owner for their domain models. This= scales well for the reasons pointed out below. And I do have sympathy fo= r a WG wanting to close on a definitive answer for a YANG model before impl= ications are discussed elsewhere. But I am worried that we are enforcing = an overly serial process. Or of constraining communication. The market wi= ll work around this. In the controller space, YANG technology is not static. Some degree of par= allelism is needed across IETF WGs. Clueful Open Source/YANG developers ca= nnot extend themselves across all WG where YANG modeling might occur. Eric From: Thomas D. Nadeau, October 22, 2014 10:52 AM We are trying. The thing is that you cannot just hoist that onto = WGs and say "here you go." if they don't want to do it. Again, the Netmod = charter was specifically modified to accommodate that case. And while som= e WGs in the routing area are not enthusiastic about building models, other= s aren't, nor are other WGs at the IETF. So for those, what do you do? Igno= re them? The other point is that others outside of the IETF are working on = these models. It is squarely within the IETF community's interest to bring= these back into the fold. Many of these folks are skittish about coming t= o the IETF altogether so we've tried to encourage them to participate in th= is way. If we want to push these folks away with procedural reasons, then w= e have made our bed... -tom On Oct 22, 2014:10:45 AM, at 10:45 AM, Andy Bierman > wrote: Hi, I think the interim did not need to be cancelled. There are ACL, SYSLOG, and YANG Mount topics. I was going to call in for those, not OSPF. But I have been saying (for over a year now) that it is time to move domain-specific data models into the domain-specific WGs. I think NETMOD WG should focus on the YANG language and infrastructure modules. Andy On Wed, Oct 22, 2014 at 7:35 AM, Thomas D. Nadeau > wrote: No one said that OSPF experts could not attend to provide input. The issu= e is that OSPF was not doing this. If they want to take over doing all OSPF= models, then great, but to date no one was. The agreement in NETMOD (and = our charter) is to facilitate the creation of models when WGs don't want to= do them, have the expertise to do them, etc... Also, getting the right Ya= ng experts in one place is not going to happen for every WG in the IETF; it= s just not realistic. I understand that ultimately the WG needs to have co= nsensus, but quick iteration to construct the model surely can happen in a = small "design team" fashion, right? And in terms of today's meeting being canceled, really what purpose was tha= t other than to stall/slow-down work? The group that was there to work on = the OSPF model was indeed a bunch of folks from OSPF (Acee Lindem for examp= le was on the call). So now since we won't have another interim meeting un= til after Hawaii, so the next time this group can get together is possibly = in Hawaii, but that is probably unlikely as a large number of people are no= t going to Hawaii. So the net-net is a slowing of progress in this area. = Probably not the result the IETF community wants. -Tom On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman > wrote: Hi Adrian, I agree with you. The OSPF WG should be discussing OSPF data models, not the NETMOD WG. The domain experts need to reach consensus on a feature set (and maybe info model) and then get 1 or 2 YANG experts to help translate that to a data model. (Not the other way around -- a room full of YANG experts and 1 or 2 OSPF experts). I also prefer that virtual interim meetings be used to discuss open issues on chartered items, not as an additional forum to promote individual drafts= . Andy On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel > wrote: I understand and appreciate your desire to get work done. The rules for IETF virtual interims are neither hard to discover, nor hard = to comply with. The rules exist to ensure that people are included in the work= , and I am sure that inclusion is what you want. I find it unfortunate that you scheduled a working group meeting to discuss= only one of a pair of competing documents on the same topic, that you didn't mak= e the information about the meeting available to the authors of the competing doc= ument or to the people who care about the protocol being modelled, and I find it upsetting (yes, I am actually upset) that you decided to discuss in Netmod = a document that belongs in the OSPF working group. If, as it surely sounds, you wish that the Netmod working group had a diffe= rent charter to enable it to take on models for protocols that already have a ho= me in other working groups, then I suggest you need to recharter. But I doubt tha= t your reasoning that [YANG] experts will not go to all the other working gro= ups will carry much weight. Frankly, and without wanting to disrespect the YANG experts, it is easier to understand YANG than it is to understand OSPF. If = this were not the case then the Netmod working group would have failed in its de= sign of YANG! Conclusion: You want to work on a YANG model for OSPF. Go to the OSPF working group and discuss it (there are already some threads). Review and comment on the comp= eting document. Try to get agreement between all of the authors of both documents= , or try to identify the differences. Work with the chairs of the OSPF working g= roup to advance the work. Adrian > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com] > Sent: 22 October 2014 14:29 > To: Benoit Claise > Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org; > rtg-ads@tools.ietf.org > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled > > > This is hugely disappointing. This is the kind of procedural non-se= nse has > and IS driving people away from the IETF to other places where this work = is going > to get done. The simple effect of such silliness will be a reduction in s= peed and > quantity of model development. If the goal of the IESG is to slow down t= he > velocity of model development and creation, then this approach is perfect= . > > For the record, the interim NETMOD meeting cadence has one meeting > focused on Yang and the other on modeling; is not NETMOD-specific per say= , but > to promote model creation because no other bi-weekly forum exists to do s= o. It > is also a place to bring in non-IETF work such as the work done in ODL, o= ther open > source, or just the public community that has explicitly wanted to avoid = the IETF. > We have found it a convenient and fruitful place to discuss, and actually *build* > models - regardless of their ultimate WG home. The simple reason: its a single > place for many of the experts to gather. I think you will find it very difficult to get > those people onto a per-WG call every other week. > > I hope the IESG considers this approach carefully because I do not = think it > will have the affect the larger IETF community is interested in. > > --Tom > > > > > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise > wrote: > > > > Dear all, > > > > Today NETMOD interim meeting is canceled. > > > > I received some pushbacks from the routing ADs, on the ground that: > > 1. This interim appears to be meeting to discuss a non-WG draft for whi= ch there > is no milestone in the working group and for which there is an obvious ho= me > outside the working group. > > 2. The agenda was not announced a week in advance on the IETF announce = list > as is required > > > > Regards, Benoit > > > > _______________________________________________ > > Rtg-yang-coord mailing list > > Rtg-yang-coord@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --_000_EF64FF31F4C4384DBCE5D513A791C2B120A5635Exmbalnx11ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As Tom and others note, today’s Netmod inte= rim was to have topics beyond OSPF.  These included OpenDaylight relat= ed work.   The IETF should be encouraging venues for Open Source = developer audiences.  Cancelling full meetings via IETF procedural mechanisms signals the opposite. 

 

I *like* the idea of each WG being the owner for = their domain models.  This scales well for the reasons  pointed o= ut below.  And I do have sympathy for a WG wanting to close on a defin= itive answer for a YANG model before implications are discussed elsewhere.   But I am worried that we are enforcin= g an overly serial process.  Or of constraining communication.  T= he market will work around this.  

 

In the controller space, YANG technology is not s= tatic.  Some degree of parallelism is needed across IETF WGs.  Cl= ueful Open Source/YANG developers cannot extend themselves across all WG wh= ere YANG modeling might occur.

 

Eric

 <= /p>

 <= /p>

From: Thomas D= . Nadeau, October 22, 2014 10:52 AM

   &nb= sp;      We are trying. The thing is that y= ou cannot just hoist that onto WGs and say “here you go.” if th= ey don’t want to do it.  Again, the Netmod charter was specifica= lly modified to accommodate that case.   And while some WGs in the routing area are not enthusiastic a= bout building models, others aren’t, nor are other WGs at the IETF. S= o for those, what do you do? Ignore them? The other point is that others ou= tside of the IETF are working on these models.  It is squarely within the IETF community’s interest to bring t= hese back into the fold.  Many of these folks are skittish about comin= g to the IETF altogether so we’ve tried to encourage them to particip= ate in this way. If we want to push these folks away with procedural reasons, then we have made our bed...

 

   &nb= sp;      —tom

 

 

 

On Oct 22, 2014:10:45 AM, at 10:45 AM, Andy Bierman = <andy@yumaworks.com> wrote:=

 

Hi,

 

I think the interim did not need to be cancelled. Th= ere are ACL, SYSLOG,

and YANG Mount topics. I was going to call in for th= ose, not OSPF.

But I have been saying (for over a year now) that it= is time to move

domain-specific data models into the domain-specific= WGs.

I think NETMOD WG should focus on the YANG language = and

infrastructure modules.

 

Andy

 

 

On Wed, Oct 22, 2014 at 7:35 AM, Thomas D. Nadeau &l= t;tnadeau@luci= dvision.com> wrote:

 

No one said that OSPF experts could not attend to pr= ovide input.   The issue is that OSPF was not doing this. If they want= to take over doing all OSPF models, then great, but to date no one was.&nb= sp; The agreement in NETMOD (and our charter) is to facilitate the creation of models when WGs don’t want to do th= em, have the expertise to do them, etc…  Also, getting the right= Yang experts in one place is not going to happen for every WG in the IETF;= its just not realistic.  I understand that ultimately the WG needs to have consensus, but quick iteration to construct the model= surely can happen in a small “design team” fashion, right?

 

And in terms of today’s meeting being canceled= , really what purpose was that other than to stall/slow-down work?  Th= e group that was there to work on the OSPF model was indeed a bunch of folk= s from OSPF (Acee Lindem for example was on the call).  So now since we won’t have another interim meeting unti= l after Hawaii, so the next time this group can get together is possibly in= Hawaii, but that is probably unlikely as a large number of people are not = going to Hawaii.  So the net-net is a slowing of progress in this area.  Probably not the result the IETF community= wants.

 

—Tom

 

 

 

On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman = <andy@yumaworks.= com> wrote:

 

Hi Adrian,

 

I agree with you. The OSPF WG should be discussing O= SPF data models,

not the NETMOD WG. The domain experts need to reach = consensus

on a feature set (and maybe info model) and then get= 1 or 2 YANG experts to

help translate that to a data model. (Not the other = way around -- a room

full of YANG experts and 1 or 2 OSPF experts).<= /o:p>

 

I also prefer that virtual interim meetings be used = to discuss open issues

on chartered items, not as an additional forum to pr= omote individual drafts.

 

 

Andy

 

 

On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel <<= a href=3D"mailto:adrian@olddog.co.uk" target=3D"_blank">adrian@olddog.co.uk= > wrote:

I understand and appreciate your desire to get work = done.

The rules for IETF virtual interims are neither hard to discover, nor hard = to
comply with. The rules exist to ensure that people are included in the work= , and
I am sure that inclusion is what you want.

I find it unfortunate that you scheduled a working group meeting to discuss= only
one of a pair of competing documents on the same topic, that you didn't mak= e the
information about the meeting available to the authors of the competing doc= ument
or to the people who care about the protocol being modelled, and I find it<= br> upsetting (yes, I am actually upset) that you decided to discuss in Netmod = a
document that belongs in the OSPF working group.

If, as it surely sounds, you wish that the Netmod working group had a diffe= rent
charter to enable it to take on models for protocols that already have a ho= me in
other working groups, then I suggest you need to recharter. But I doubt tha= t
your reasoning that [YANG] experts will not go to all the other working gro= ups
will carry much weight. Frankly, and without wanting to disrespect the YANG=
experts, it is easier to understand YANG than it is to understand OSPF. If = this
were not the case then the Netmod working group would have failed in its de= sign
of YANG!

Conclusion:
You want to work on a YANG model for OSPF. Go to the OSPF working group and=
discuss it (there are already some threads). Review and comment on the comp= eting
document. Try to get agreement between all of the authors of both documents= , or
try to identify the differences. Work with the chairs of the OSPF working g= roup
to advance the work.

Adrian

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com]
> Sent: 22 October 2014 14:29
> To: Benoit Claise
> Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org;
> rtg-ads@to= ols.ietf.org
> Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled
>
>
>       This is hugely disappointing. This is the ki= nd of procedural non-sense
has
> and IS driving people away from the IETF to other places where this wo= rk is
going
> to get done. The simple effect of such silliness will be a reduction i= n speed
and
> quantity of model development.  If the goal of the IESG is to slo= w down the
> velocity of model development and creation, then this approach is perf= ect.
>
>       For the record, the interim NETMOD meeting c= adence has one meeting
> focused on Yang and the other on modeling; is not NETMOD-specific per = say, but
> to promote model creation because no other bi-weekly forum exists to d= o so. It
> is also a place to bring in non-IETF work such as the work done in ODL= , other
open
> source, or just the public community that has explicitly wanted to avo= id the
IETF.
> We have found it a convenient and fruitful place to discuss, and actua= lly
*build*
> models - regardless of their ultimate WG home.  The simple reason= : its a
single
> place for many of the experts to gather. I think you will find it very=
difficult to get
> those people onto a per-WG call every other week.
>
>       I hope the IESG considers this approach care= fully because I do not think
it
> will have the affect the larger IETF community is interested in.
>
>       --Tom
>
>
>
> > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise <bclaise@cisco.com>
wrote:
> >
> > Dear all,
> >
> > Today NETMOD interim meeting is canceled.
> >
> > I received some pushbacks from the routing ADs, on the ground tha= t:
> > 1. This interim appears to be meeting to discuss a non-WG draft f= or which
there
> is no milestone in the working group and for which there is an obvious= home
> outside the working group.
> > 2. The agenda was not announced a week in advance on the IETF ann= ounce list
> as is required
> >
> > Regards, Benoit
> >
> > _______________________________________________
> > Rtg-yang-coord mailing list
> > Rtg-= yang-coord@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtg-yang-coord
> >

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

 

 

 

 

--_000_EF64FF31F4C4384DBCE5D513A791C2B120A5635Exmbalnx11ciscoc_-- From nobody Wed Oct 22 08:31:45 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BEDF1ACD7E; Wed, 22 Oct 2014 08:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 T1PNurjK22Ag; Wed, 22 Oct 2014 08:31:29 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CDD51ACD5C; Wed, 22 Oct 2014 08:31:28 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s9MFVKw9018389; Wed, 22 Oct 2014 16:31:20 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s9MFVGDF018364 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 22 Oct 2014 16:31:16 +0100 From: "Adrian Farrel" To: "'Eric Voit \(evoit\)'" , "'Thomas D. Nadeau'" , "'Andy Bierman'" References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> In-Reply-To: Date: Wed, 22 Oct 2014 16:31:15 +0100 Message-ID: <033001cfee0d$39f4be00$adde3a00$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0331_01CFEE15.9BBD92D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIUX+ca9u4QKYuEX+hUMOEGGRuotgIuz+VeAfQkGdcB/lG70gLMEl+3Ae5R6RAAvWtNfQFaI9Swm0u/KfA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21042.006 X-TM-AS-Result: No--22.087-10.0-31-10 X-imss-scan-details: No--22.087-10.0-31-10 X-TMASE-MatchedRID: IeZYkn8zfFoZ7jQwc54lYnS5xmwU5i7OVBDQSDMig9GqvcIF1TcLYCSO mrPBOTFp4xJtic9fIFDbZy9r8jP7KQcSBA/LYDiht1AhvyEKdj6D30L3uxcHwH3hz57t9YhwCL1 yYUEE8H569CHTEoBTSOAfgNq2Dmd+7K35r0y1/56uJZEHbH9COkpFpc3bJiMeHF5gWd5iOUkQde WzncsvdsNNU5+etg4IxgZLkcFnBTi6pWIxX/wmnJJEUO2qIzlLkTwrUbGAkwsAIXlMppp3X0mtg rB9FRL4E5k0SQVbD8C9v2NH67oMPsvpn96tHcQm4pdq9sdj8LXv6kiVCTIVSnp8t2HNMtxXAYKi oM2eCbXZ/QsAS8dPpVBfggEXkT8rSJvHZYIIxMjAzkaoCiomKtFqG4/BpDVaV6KWY8jugmVoM2t bPC4VOF0X5Tuj0fDnW/LiKbIDyB0tSlTGuzyOlhes/RxhysDbh8Ytn75ClDMJmdXzOhEMdki1wh buw4TinqyoyJhbUB54inx+MCALBgzLAh0XmJaQhrs6JAEL1u4F15s6prCIu2LM/ReBSwUwidXgU qJvtIsQodlG8zH2T6xKY/YhJ7+KKGCbvjyH7UVn+WBSNyyzIcmSB8xSIlHVVfOB6z8Qn2wYAGI3 BL87IDBYuLCOM+B33qfXafL74u+s/r1De3um7kg5Iem1vm3HX5TqQagR07ciuBun2kJCuhOYxNl db2puYHEXFWMmW7/LUUKzD12wiEBhLuZbkW2NUKL/EMdwPN/WSrKtwxqWpRub2KZpME0Zkl0fPY WeWR0KAL6wjvnzMWYyyBKbvyUxgNVHXM3C8e6eAiCmPx4NwGmRqNBHmBvevqq8s2MNhPDPPeN6H N6d7DDmMp5UGBhvIAcCikR3vq98BjoDgPVWLqYmnuDEvXMO4qV+pM01IKYEplsyW5C2ipJQyOLS ake4 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/HDwP98N8CrWrIjPoHWkAqEb3qu8 Cc: Rtg-yang-coord@ietf.org, ospf-chairs@tools.ietf.org, ops-ads@tools.ietf.org, 'NETMOD Working Group' , rtg-ads@tools.ietf.org Subject: Re: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 15:31:37 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0331_01CFEE15.9BBD92D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Eric, I cannot speak to why the meeting was cancelled. My disquiet was simply that an item on the agenda was out of scope and not properly announced to achieve the correct participation. The text I sent to Benoit read... > In summary: if this meeting does not have material to discuss under > the agenda for which the meeting was called, then it must be cancelled. You appear to be saying that there was work to be done that was in scope for the WG and was part of the agenda that was published. So I'm a bit puzzled. Adrian From: Eric Voit (evoit) [mailto:evoit@cisco.com] Sent: 22 October 2014 16:20 To: Thomas D. Nadeau; Andy Bierman Cc: Rtg-yang-coord@ietf.org; NETMOD Working Group; ospf-chairs@tools.ietf.org; ops-ads@tools.ietf.org; rtg-ads@tools.ietf.org; Farrel Adrian Subject: RE: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled As Tom and others note, today's Netmod interim was to have topics beyond OSPF. These included OpenDaylight related work. The IETF should be encouraging venues for Open Source developer audiences. Cancelling full meetings via IETF procedural mechanisms signals the opposite. I *like* the idea of each WG being the owner for their domain models. This scales well for the reasons pointed out below. And I do have sympathy for a WG wanting to close on a definitive answer for a YANG model before implications are discussed elsewhere. But I am worried that we are enforcing an overly serial process. Or of constraining communication. The market will work around this. In the controller space, YANG technology is not static. Some degree of parallelism is needed across IETF WGs. Clueful Open Source/YANG developers cannot extend themselves across all WG where YANG modeling might occur. Eric From: Thomas D. Nadeau, October 22, 2014 10:52 AM We are trying. The thing is that you cannot just hoist that onto WGs and say "here you go." if they don't want to do it. Again, the Netmod charter was specifically modified to accommodate that case. And while some WGs in the routing area are not enthusiastic about building models, others aren't, nor are other WGs at the IETF. So for those, what do you do? Ignore them? The other point is that others outside of the IETF are working on these models. It is squarely within the IETF community's interest to bring these back into the fold. Many of these folks are skittish about coming to the IETF altogether so we've tried to encourage them to participate in this way. If we want to push these folks away with procedural reasons, then we have made our bed... -tom On Oct 22, 2014:10:45 AM, at 10:45 AM, Andy Bierman wrote: Hi, I think the interim did not need to be cancelled. There are ACL, SYSLOG, and YANG Mount topics. I was going to call in for those, not OSPF. But I have been saying (for over a year now) that it is time to move domain-specific data models into the domain-specific WGs. I think NETMOD WG should focus on the YANG language and infrastructure modules. Andy On Wed, Oct 22, 2014 at 7:35 AM, Thomas D. Nadeau wrote: No one said that OSPF experts could not attend to provide input. The issue is that OSPF was not doing this. If they want to take over doing all OSPF models, then great, but to date no one was. The agreement in NETMOD (and our charter) is to facilitate the creation of models when WGs don't want to do them, have the expertise to do them, etc. Also, getting the right Yang experts in one place is not going to happen for every WG in the IETF; its just not realistic. I understand that ultimately the WG needs to have consensus, but quick iteration to construct the model surely can happen in a small "design team" fashion, right? And in terms of today's meeting being canceled, really what purpose was that other than to stall/slow-down work? The group that was there to work on the OSPF model was indeed a bunch of folks from OSPF (Acee Lindem for example was on the call). So now since we won't have another interim meeting until after Hawaii, so the next time this group can get together is possibly in Hawaii, but that is probably unlikely as a large number of people are not going to Hawaii. So the net-net is a slowing of progress in this area. Probably not the result the IETF community wants. -Tom On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman wrote: Hi Adrian, I agree with you. The OSPF WG should be discussing OSPF data models, not the NETMOD WG. The domain experts need to reach consensus on a feature set (and maybe info model) and then get 1 or 2 YANG experts to help translate that to a data model. (Not the other way around -- a room full of YANG experts and 1 or 2 OSPF experts). I also prefer that virtual interim meetings be used to discuss open issues on chartered items, not as an additional forum to promote individual drafts. Andy On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel wrote: I understand and appreciate your desire to get work done. The rules for IETF virtual interims are neither hard to discover, nor hard to comply with. The rules exist to ensure that people are included in the work, and I am sure that inclusion is what you want. I find it unfortunate that you scheduled a working group meeting to discuss only one of a pair of competing documents on the same topic, that you didn't make the information about the meeting available to the authors of the competing document or to the people who care about the protocol being modelled, and I find it upsetting (yes, I am actually upset) that you decided to discuss in Netmod a document that belongs in the OSPF working group. If, as it surely sounds, you wish that the Netmod working group had a different charter to enable it to take on models for protocols that already have a home in other working groups, then I suggest you need to recharter. But I doubt that your reasoning that [YANG] experts will not go to all the other working groups will carry much weight. Frankly, and without wanting to disrespect the YANG experts, it is easier to understand YANG than it is to understand OSPF. If this were not the case then the Netmod working group would have failed in its design of YANG! Conclusion: You want to work on a YANG model for OSPF. Go to the OSPF working group and discuss it (there are already some threads). Review and comment on the competing document. Try to get agreement between all of the authors of both documents, or try to identify the differences. Work with the chairs of the OSPF working group to advance the work. Adrian > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com] > Sent: 22 October 2014 14:29 > To: Benoit Claise > Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org; > rtg-ads@tools.ietf.org > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled > > > This is hugely disappointing. This is the kind of procedural non-sense has > and IS driving people away from the IETF to other places where this work is going > to get done. The simple effect of such silliness will be a reduction in speed and > quantity of model development. If the goal of the IESG is to slow down the > velocity of model development and creation, then this approach is perfect. > > For the record, the interim NETMOD meeting cadence has one meeting > focused on Yang and the other on modeling; is not NETMOD-specific per say, but > to promote model creation because no other bi-weekly forum exists to do so. It > is also a place to bring in non-IETF work such as the work done in ODL, other open > source, or just the public community that has explicitly wanted to avoid the IETF. > We have found it a convenient and fruitful place to discuss, and actually *build* > models - regardless of their ultimate WG home. The simple reason: its a single > place for many of the experts to gather. I think you will find it very difficult to get > those people onto a per-WG call every other week. > > I hope the IESG considers this approach carefully because I do not think it > will have the affect the larger IETF community is interested in. > > --Tom > > > > > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise wrote: > > > > Dear all, > > > > Today NETMOD interim meeting is canceled. > > > > I received some pushbacks from the routing ADs, on the ground that: > > 1. This interim appears to be meeting to discuss a non-WG draft for which there > is no milestone in the working group and for which there is an obvious home > outside the working group. > > 2. The agenda was not announced a week in advance on the IETF announce list > as is required > > > > Regards, Benoit > > > > _______________________________________________ > > Rtg-yang-coord mailing list > > Rtg-yang-coord@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ------=_NextPart_000_0331_01CFEE15.9BBD92D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Eric,

 

I cannot speak to why the = meeting was cancelled.

My disquiet was simply that an = item on the agenda was out of scope and not properly announced to = achieve the correct participation.

 

The text I sent to Benoit = read...

 

> In summary: if this = meeting does not have material to discuss under

> the agenda for which the = meeting was called, then it must be cancelled.

 

You appear to be saying that = there was work to be done that was in scope for the WG and was part of = the agenda that was published.

 

So I'm a bit puzzled. =

 

Adrian

 

 

From: Eric Voit (evoit) = [mailto:evoit@cisco.com]
Sent: 22 October 2014 = 16:20
To: Thomas D. Nadeau; Andy Bierman
Cc: = Rtg-yang-coord@ietf.org; NETMOD Working Group; = ospf-chairs@tools.ietf.org; ops-ads@tools.ietf.org; = rtg-ads@tools.ietf.org; Farrel Adrian
Subject: RE: [netmod] = [Rtg-yang-coord] NETMOD interim meeting = canceled

 

As Tom and others note, = today’s Netmod interim was to have topics beyond OSPF.  These = included OpenDaylight related work.   The IETF should be = encouraging venues for Open Source developer audiences.  Cancelling = full meetings via IETF procedural mechanisms signals the opposite.  =

 

I *like* the idea of each WG being the = owner for their domain models.  This scales well for the reasons =  pointed out below.  And I do have sympathy for a WG wanting = to close on a definitive answer for a YANG model before implications are = discussed elsewhere.   But I am worried that we are enforcing = an overly serial process.  Or of constraining communication.  = The market will work around this.  

 

In the controller space, YANG = technology is not static.  Some degree of parallelism is needed = across IETF WGs.  Clueful Open Source/YANG developers cannot extend = themselves across all WG where YANG modeling might occur. =

 

Eric

 

 

From: Thomas D. Nadeau, October 22, 2014 10:52 AM

      &nb= sp;   We are trying. The thing is that you = cannot just hoist that onto WGs and say “here you go.” if = they don’t want to do it.  Again, the Netmod charter was = specifically modified to accommodate that case.   And while some = WGs in the routing area are not enthusiastic about building models, = others aren’t, nor are other WGs at the IETF. So for those, what = do you do? Ignore them? The other point is that others outside of the = IETF are working on these models.  It is squarely within the IETF = community’s interest to bring these back into the fold.  Many = of these folks are skittish about coming to the IETF altogether so = we’ve tried to encourage them to participate in this way. If we = want to push these folks away with procedural reasons, then we have made = our bed...

 

=

      &nb= sp;   —tom

<= div>

 

=

 

 

On Oct 22, 2014:10:45 AM, at 10:45 AM, = Andy Bierman <andy@yumaworks.com> = wrote:

 

<= p class=3DMsoNormal>Hi,

 

=

I think the interim did not need to be = cancelled. There are ACL, SYSLOG,

and YANG Mount topics. I was going to = call in for those, not OSPF.

But I have been saying (for over a = year now) that it is time to move

domain-specific data models into the = domain-specific WGs.

I = think NETMOD WG should focus on the YANG language = and

infrastructure = modules.

 

=

Andy

 

 

On Wed, Oct 22, 2014 at 7:35 AM, = Thomas D. Nadeau <tnadeau@lucidvision.com> = wrote:

 

No one said that OSPF experts could = not attend to provide input.   The issue is that OSPF was not doing = this. If they want to take over doing all OSPF models, then great, but = to date no one was.  The agreement in NETMOD (and our charter) is = to facilitate the creation of models when WGs don’t want to do = them, have the expertise to do them, etc…  Also, getting the = right Yang experts in one place is not going to happen for every WG in = the IETF; its just not realistic.  I understand that ultimately the = WG needs to have consensus, but quick iteration to construct the model = surely can happen in a small “design team” fashion, = right?

 

=

And in terms of today’s meeting = being canceled, really what purpose was that other than to = stall/slow-down work?  The group that was there to work on the OSPF = model was indeed a bunch of folks from OSPF (Acee Lindem for example was = on the call).  So now since we won’t have another interim = meeting until after Hawaii, so the next time this group can get together = is possibly in Hawaii, but that is probably unlikely as a large number = of people are not going to Hawaii.  So the net-net is a slowing of = progress in this area.  Probably not the result the IETF community = wants.

 

=

—Tom

<= div>

 

=

 

=

 

On Oct 22, 2014:10:18 AM, at 10:18 AM, = Andy Bierman <andy@yumaworks.com> = wrote:

 

<= p class=3DMsoNormal>Hi = Adrian,

 

=

I agree with you. The OSPF WG should = be discussing OSPF data models,

not the NETMOD WG. The domain experts = need to reach consensus

on a feature set (and maybe info = model) and then get 1 or 2 YANG experts = to

help translate that to a = data model. (Not the other way around -- a = room

full of YANG experts and = 1 or 2 OSPF experts).

 

=

I also prefer that virtual interim = meetings be used to discuss open = issues

on chartered items, not = as an additional forum to promote individual = drafts.

 

=

 

=

Andy

 

=

 

On Wed, Oct 22, 2014 at 6:48 AM, = Adrian Farrel <adrian@olddog.co.uk> = wrote:

I understand and appreciate your = desire to get work done.

The rules for IETF virtual interims are = neither hard to discover, nor hard to
comply with. The rules exist to = ensure that people are included in the work, and
I am sure that = inclusion is what you want.

I find it unfortunate that you = scheduled a working group meeting to discuss only
one of a pair of = competing documents on the same topic, that you didn't make = the
information about the meeting available to the authors of the = competing document
or to the people who care about the protocol being = modelled, and I find it
upsetting (yes, I am actually upset) that you = decided to discuss in Netmod a
document that belongs in the OSPF = working group.

If, as it surely sounds, you wish that the Netmod = working group had a different
charter to enable it to take on models = for protocols that already have a home in
other working groups, then = I suggest you need to recharter. But I doubt that
your reasoning that = [YANG] experts will not go to all the other working groups
will carry = much weight. Frankly, and without wanting to disrespect the = YANG
experts, it is easier to understand YANG than it is to = understand OSPF. If this
were not the case then the Netmod working = group would have failed in its design
of = YANG!

Conclusion:
You want to work on a YANG model for OSPF. = Go to the OSPF working group and
discuss it (there are already some = threads). Review and comment on the competing
document. Try to get = agreement between all of the authors of both documents, or
try to = identify the differences. Work with the chairs of the OSPF working = group
to advance the work.

Adrian

> -----Original = Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com]
> Sent: 22 October = 2014 14:29
> To: Benoit Claise
> Cc: NETMOD Working Group; = Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org;
> rtg-ads@tools.ietf.org
> Subject: Re: = [Rtg-yang-coord] NETMOD interim meeting = canceled
>
>
>       This is = hugely disappointing. This is the kind of procedural = non-sense
has
> and IS driving people away from the IETF to = other places where this work is
going
> to get done. The simple = effect of such silliness will be a reduction in speed
and
> = quantity of model development.  If the goal of the IESG is to slow = down the
> velocity of model development and creation, then this = approach is perfect.
>
>       For the = record, the interim NETMOD meeting cadence has one meeting
> = focused on Yang and the other on modeling; is not NETMOD-specific per = say, but
> to promote model creation because no other bi-weekly = forum exists to do so. It
> is also a place to bring in non-IETF = work such as the work done in ODL, other
open
> source, or just = the public community that has explicitly wanted to avoid = the
IETF.
> We have found it a convenient and fruitful place to = discuss, and actually
*build*
> models - regardless of their = ultimate WG home.  The simple reason: its a
single
> place = for many of the experts to gather. I think you will find it = very
difficult to get
> those people onto a per-WG call every = other week.
>
>       I hope the IESG = considers this approach carefully because I do not think
it
> = will have the affect the larger IETF community is interested = in.
>
>      =  --Tom
>
>
>
> > On Oct 22, 2014:9:16 = AM, at 9:16 AM, Benoit Claise <bclaise@cisco.com>
wrote:
> = >
> > Dear all,
> >
> > Today NETMOD = interim meeting is canceled.
> >
> > I received some = pushbacks from the routing ADs, on the ground that:
> > 1. This = interim appears to be meeting to discuss a non-WG draft for = which
there
> is no milestone in the working group and for = which there is an obvious home
> outside the working = group.
> > 2. The agenda was not announced a week in advance on = the IETF announce list
> as is required
> >
> > = Regards, Benoit
> >
> > = _______________________________________________
> > = Rtg-yang-coord mailing list
> > Rtg-yang-coord@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtg-yang-coord
> = >

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

 

 

 

 

------=_NextPart_000_0331_01CFEE15.9BBD92D0-- From nobody Wed Oct 22 10:05:31 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D17851ACE75; Wed, 22 Oct 2014 10:05:11 -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 eU6joU-g8z5q; Wed, 22 Oct 2014 10:04:59 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE6931ACE56; Wed, 22 Oct 2014 10:04:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=42674; q=dns/txt; s=iport; t=1413997497; x=1415207097; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=kv/QXqnr2NeGqQ94TCMXjINvGuB/+h5MOyz6PqeEPlM=; b=kGq3FCNq/aLEERdn2m2UGPWX5iifE3BAjOkuP63NxnzjNZ7hQqxwxCtJ vFBp+jPeQz6VLHpx5kGN332qK+o1AirWOqVgjCl+O7FQIJJN2NECRGURM JWHpEU3Nv9GoVAqRIDyOQp2ueSODXFqFXzef+uS0rVQx/keizhHDT/F5Z I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigFABPjR1StJV2c/2dsb2JhbABSCoJIRlRYBMxTAQmGeVQCgQwWAX2EAgEBAQMBAQEBFxM+AwsFBwQCAQgRBAEBAQoWAQYHJwsUCQgCBAENBQgMBwSIGQgNxgoBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIpWhSUrLQQGAQaDJ4EeBY9mgh6NCoZ2igKEAYN4bIEGBD6BAwEBAQ X-IronPort-AV: E=Sophos;i="5.04,769,1406592000"; d="scan'208,217";a="365509101" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 22 Oct 2014 17:04:54 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s9MH4sbD029061 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Oct 2014 17:04:54 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.189]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Wed, 22 Oct 2014 12:04:53 -0500 From: "Eric Voit (evoit)" To: "adrian@olddog.co.uk" , "'Thomas D. Nadeau'" , "'Andy Bierman'" Thread-Topic: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled Thread-Index: AQHP7gfB9u4QKYuEX+hUMOEGGRuotpw8OMTQgABZbYD//7OAoA== Date: Wed, 22 Oct 2014 17:04:52 +0000 Message-ID: References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> <033001cfee0d$39f4be00$adde3a00$@olddog.co.uk> In-Reply-To: <033001cfee0d$39f4be00$adde3a00$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.134.135] Content-Type: multipart/alternative; boundary="_000_EF64FF31F4C4384DBCE5D513A791C2B120A5649Fxmbalnx11ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/VM-1f39AMYb3_l6soVl2KKQ3Y5A Cc: "Rtg-yang-coord@ietf.org" , "ospf-chairs@tools.ietf.org" , "ops-ads@tools.ietf.org" , 'NETMOD Working Group' , "rtg-ads@tools.ietf.org" Subject: Re: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2014 17:05:12 -0000 --_000_EF64FF31F4C4384DBCE5D513A791C2B120A5649Fxmbalnx11ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It is true I wish the meeting had run today to address other things. Putti= ng that aside I had a larger point. OpenDaylight is seeing new YANG technologies which are being implemented fo= r a set of new topics. I have listed a few below to provide context. Many= of these topics have implications to multiple IETF Working Groups. Awaiti= ng charter changes before having discussions in or between WG slows these d= iscussions. Enforcing a process so that YANG modeling discussions must go = through distributed WGs serially slows these discussions. I am not offeri= ng a solution here. I am just observing that the industry is moving faster= than the IETF. Some YANG OpenDaylight Topics which I would love to see the IETF take on: (1) Multi-device YANG Abstractions YANG syntax is used for multi-device abstractions in OpenDaylight MD-SAL. = This conflicts with RFC 6244 which defines a single-box boundaries. Should= the IETF consider architectures where YANG models span devices? What abou= t for multi-box protocols like VRRP? What about Anycast interfaces into cl= usters of devices acting as one? How about cloud abstraction into a Design= ated Router? (2) Generic Pub/Sub Mechanisms RFC 5277 on Netconf notifications doesn't include information on how to han= dle Pub/Sub so that one device is immediately informed about object changes= in another. I believe there is some demand for Pub/Sub which is tied to Y= ANG and with no required linkage to a transport protocol. There are also n= eeds for Pub/Sub beyond YANG. How should we approach this area? (3) Maintaining Consistency in a Multi-Controller world There will not be one controller for a network. There will be many. How d= o you determine precedence when conflicting config information is being sen= t from multiple sources? How does this change the information encoded in t= he model? In summary I would assert that handling solutions to the problems above ind= ependently across all WGs is not viable. Eric From: Adrian Farrel, October 22, 2014 11:31 AM Eric, I cannot speak to why the meeting was cancelled. My disquiet was simply that an item on the agenda was out of scope and not = properly announced to achieve the correct participation. The text I sent to Benoit read... > In summary: if this meeting does not have material to discuss under > the agenda for which the meeting was called, then it must be cancelled. You appear to be saying that there was work to be done that was in scope fo= r the WG and was part of the agenda that was published. So I'm a bit puzzled. Adrian From: Eric Voit (evoit) [mailto:evoit@cisco.com] Sent: 22 October 2014 16:20 To: Thomas D. Nadeau; Andy Bierman Cc: Rtg-yang-coord@ietf.org; NETMOD Working= Group; ospf-chairs@tools.ietf.org; ops-= ads@tools.ietf.org; rtg-ads@tools.ietf.org; Farrel Adrian Subject: RE: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled As Tom and others note, today's Netmod interim was to have topics beyond OS= PF. These included OpenDaylight related work. The IETF should be encoura= ging venues for Open Source developer audiences. Cancelling full meetings = via IETF procedural mechanisms signals the opposite. I *like* the idea of each WG being the owner for their domain models. This= scales well for the reasons pointed out below. And I do have sympathy fo= r a WG wanting to close on a definitive answer for a YANG model before impl= ications are discussed elsewhere. But I am worried that we are enforcing = an overly serial process. Or of constraining communication. The market wi= ll work around this. In the controller space, YANG technology is not static. Some degree of par= allelism is needed across IETF WGs. Clueful Open Source/YANG developers ca= nnot extend themselves across all WG where YANG modeling might occur. Eric From: Thomas D. Nadeau, October 22, 2014 10:52 AM We are trying. The thing is that you cannot just hoist that onto = WGs and say "here you go." if they don't want to do it. Again, the Netmod = charter was specifically modified to accommodate that case. And while som= e WGs in the routing area are not enthusiastic about building models, other= s aren't, nor are other WGs at the IETF. So for those, what do you do? Igno= re them? The other point is that others outside of the IETF are working on = these models. It is squarely within the IETF community's interest to bring= these back into the fold. Many of these folks are skittish about coming t= o the IETF altogether so we've tried to encourage them to participate in th= is way. If we want to push these folks away with procedural reasons, then w= e have made our bed... -tom On Oct 22, 2014:10:45 AM, at 10:45 AM, Andy Bierman > wrote: Hi, I think the interim did not need to be cancelled. There are ACL, SYSLOG, and YANG Mount topics. I was going to call in for those, not OSPF. But I have been saying (for over a year now) that it is time to move domain-specific data models into the domain-specific WGs. I think NETMOD WG should focus on the YANG language and infrastructure modules. Andy On Wed, Oct 22, 2014 at 7:35 AM, Thomas D. Nadeau > wrote: No one said that OSPF experts could not attend to provide input. The issu= e is that OSPF was not doing this. If they want to take over doing all OSPF= models, then great, but to date no one was. The agreement in NETMOD (and = our charter) is to facilitate the creation of models when WGs don't want to= do them, have the expertise to do them, etc... Also, getting the right Ya= ng experts in one place is not going to happen for every WG in the IETF; it= s just not realistic. I understand that ultimately the WG needs to have co= nsensus, but quick iteration to construct the model surely can happen in a = small "design team" fashion, right? And in terms of today's meeting being canceled, really what purpose was tha= t other than to stall/slow-down work? The group that was there to work on = the OSPF model was indeed a bunch of folks from OSPF (Acee Lindem for examp= le was on the call). So now since we won't have another interim meeting un= til after Hawaii, so the next time this group can get together is possibly = in Hawaii, but that is probably unlikely as a large number of people are no= t going to Hawaii. So the net-net is a slowing of progress in this area. = Probably not the result the IETF community wants. -Tom On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman > wrote: Hi Adrian, I agree with you. The OSPF WG should be discussing OSPF data models, not the NETMOD WG. The domain experts need to reach consensus on a feature set (and maybe info model) and then get 1 or 2 YANG experts to help translate that to a data model. (Not the other way around -- a room full of YANG experts and 1 or 2 OSPF experts). I also prefer that virtual interim meetings be used to discuss open issues on chartered items, not as an additional forum to promote individual drafts= . Andy On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel > wrote: I understand and appreciate your desire to get work done. The rules for IETF virtual interims are neither hard to discover, nor hard = to comply with. The rules exist to ensure that people are included in the work= , and I am sure that inclusion is what you want. I find it unfortunate that you scheduled a working group meeting to discuss= only one of a pair of competing documents on the same topic, that you didn't mak= e the information about the meeting available to the authors of the competing doc= ument or to the people who care about the protocol being modelled, and I find it upsetting (yes, I am actually upset) that you decided to discuss in Netmod = a document that belongs in the OSPF working group. If, as it surely sounds, you wish that the Netmod working group had a diffe= rent charter to enable it to take on models for protocols that already have a ho= me in other working groups, then I suggest you need to recharter. But I doubt tha= t your reasoning that [YANG] experts will not go to all the other working gro= ups will carry much weight. Frankly, and without wanting to disrespect the YANG experts, it is easier to understand YANG than it is to understand OSPF. If = this were not the case then the Netmod working group would have failed in its de= sign of YANG! Conclusion: You want to work on a YANG model for OSPF. Go to the OSPF working group and discuss it (there are already some threads). Review and comment on the comp= eting document. Try to get agreement between all of the authors of both documents= , or try to identify the differences. Work with the chairs of the OSPF working g= roup to advance the work. Adrian > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com] > Sent: 22 October 2014 14:29 > To: Benoit Claise > Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org; > rtg-ads@tools.ietf.org > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled > > > This is hugely disappointing. This is the kind of procedural non-se= nse has > and IS driving people away from the IETF to other places where this work = is going > to get done. The simple effect of such silliness will be a reduction in s= peed and > quantity of model development. If the goal of the IESG is to slow down t= he > velocity of model development and creation, then this approach is perfect= . > > For the record, the interim NETMOD meeting cadence has one meeting > focused on Yang and the other on modeling; is not NETMOD-specific per say= , but > to promote model creation because no other bi-weekly forum exists to do s= o. It > is also a place to bring in non-IETF work such as the work done in ODL, o= ther open > source, or just the public community that has explicitly wanted to avoid = the IETF. > We have found it a convenient and fruitful place to discuss, and actually *build* > models - regardless of their ultimate WG home. The simple reason: its a single > place for many of the experts to gather. I think you will find it very difficult to get > those people onto a per-WG call every other week. > > I hope the IESG considers this approach carefully because I do not = think it > will have the affect the larger IETF community is interested in. > > --Tom > > > > > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise > wrote: > > > > Dear all, > > > > Today NETMOD interim meeting is canceled. > > > > I received some pushbacks from the routing ADs, on the ground that: > > 1. This interim appears to be meeting to discuss a non-WG draft for whi= ch there > is no milestone in the working group and for which there is an obvious ho= me > outside the working group. > > 2. The agenda was not announced a week in advance on the IETF announce = list > as is required > > > > Regards, Benoit > > > > _______________________________________________ > > Rtg-yang-coord mailing list > > Rtg-yang-coord@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --_000_EF64FF31F4C4384DBCE5D513A791C2B120A5649Fxmbalnx11ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It is true I wish the mee= ting had run today to address other things.  Putting that aside I had = a larger point.

 <= /p>

OpenDaylight is seeing ne= w YANG technologies which are being implemented for a set of new topics.&nb= sp; I have listed a few below to provide context.  Many of these topics have implications to multiple IETF Working Groups.  Awaiting c= harter changes before having discussions in or between WG slows these discu= ssions.  Enforcing a process so that YANG modeling discussions must go= through distributed WGs serially slows these discussions.   I am not offering a solution here.  I am jus= t observing that the industry is moving faster than the IETF. 

 <= /p>

Some YANG OpenDaylight To= pics which I would love to see the IETF take on:

 <= /p>

(1) Multi-device YANG Abs= tractions 

YANG syntax is used for m= ulti-device abstractions in OpenDaylight MD-SAL.  This conflicts with RFC 6244 which defines a single-box bound= aries.  Should the IETF consider architectures where YANG models span = devices?  What about for multi-box protocols like VRRP?  What about Anycast interfaces into clusters of devices acting as one?  How= about cloud abstraction into a Designated Router?

 <= /p>

(2) Generic Pub/Sub Mecha= nisms

RFC 5277 on Netconf notif= ications doesn’t include information on how to handle Pub/Sub so that= one device is immediately informed about object changes in another.  I believe there is some demand for Pub/Sub which is tied to YANG and with = no required linkage to a transport protocol.  There are also needs for= Pub/Sub beyond YANG.  How should we approach this area?  

 <= /p>

(3) Maintaining Consisten= cy in a Multi-Controller world

There will not be one con= troller for a network.  There will be many.  How do you determine= precedence when conflicting config information is being sent from multiple sources?  How does this change the information encoded in th= e model?

 <= /p>

In summary I would assert= that handling solutions to the problems above independently across all WGs= is not viable.


Eric

 <= /p>

From: Adrian F= arrel, October 22, 2014 11:31 AM

 

Eric,=

 = ;

I cannot s= peak to why the meeting was cancelled.

My disquie= t was simply that an item on the agenda was out of scope and not properly a= nnounced to achieve the correct participation.

 = ;

The text I= sent to Benoit read...

 = ;

> In su= mmary: if this meeting does not have material to discuss under

> the a= genda for which the meeting was called, then it must be cancelled.

 = ;

You appear= to be saying that there was work to be done that was in scope for the WG a= nd was part of the agenda that was published.

 = ;

So I'm a b= it puzzled.

 = ;

Adrian

 = ;

 = ;

From: Eric Voi= t (evoit) [mailto:evoit@cisco.com]
Sent: 22 October 2014 16:20
To: Thomas D. Nadeau; Andy Bierman
Cc: Rtg-yang-coord@ietf.o= rg; NETMOD Working Group; ospf-chairs@tools.ietf.org; ops-ads@tools.ietf.org; rtg-a= ds@tools.ietf.org; Farrel Adrian
Subject: RE: [netmod] [Rtg-yang-coord] NETMOD interim meeting cancel= ed

 

As Tom and others note, today’s Netmod inte= rim was to have topics beyond OSPF.  These included OpenDaylight relat= ed work.   The IETF should be encouraging venues for Open Source = developer audiences.  Cancelling full meetings via IETF procedural mechanisms signals the opposite. 

 

I *like* the idea of each WG being the owner for = their domain models.  This scales well for the reasons  pointed o= ut below.  And I do have sympathy for a WG wanting to close on a defin= itive answer for a YANG model before implications are discussed elsewhere.   But I am worried that we are enforcin= g an overly serial process.  Or of constraining communication.  T= he market will work around this.  

 

In the controller space, YANG technology is not s= tatic.  Some degree of parallelism is needed across IETF WGs.  Cl= ueful Open Source/YANG developers cannot extend themselves across all WG wh= ere YANG modeling might occur.

 

Eric

 <= /p>

 <= /p>

From:<= /span> Thomas D. Nadeau, October 22, 2014 10:52 AM

   &nb= sp;      We are trying. The thing is that y= ou cannot just hoist that onto WGs and say “here you go.” if th= ey don’t want to do it.  Again, the Netmod charter was specifica= lly modified to accommodate that case.   And while some WGs in the routing area are not enthusiastic a= bout building models, others aren’t, nor are other WGs at the IETF. S= o for those, what do you do? Ignore them? The other point is that others ou= tside of the IETF are working on these models.  It is squarely within the IETF community’s interest to bring t= hese back into the fold.  Many of these folks are skittish about comin= g to the IETF altogether so we’ve tried to encourage them to particip= ate in this way. If we want to push these folks away with procedural reasons, then we have made our bed...

 

   &nb= sp;      —tom

 

 

 

On Oct 22, 2014:10:45 AM, at 10:45 AM, Andy Bierman = <andy@yumaworks.com> wrote:=

 

Hi,

 

I think the interim did not need to be cancelled. Th= ere are ACL, SYSLOG,

and YANG Mount topics. I was going to call in for th= ose, not OSPF.

But I have been saying (for over a year now) that it= is time to move

domain-specific data models into the domain-specific= WGs.

I think NETMOD WG should focus on the YANG language = and

infrastructure modules.

 

Andy

 

 

On Wed, Oct 22, 2014 at 7:35 AM, Thomas D. Nadeau &l= t;tnadeau@luci= dvision.com> wrote:

 

No one said that OSPF experts could not attend to pr= ovide input.   The issue is that OSPF was not doing this. If they want= to take over doing all OSPF models, then great, but to date no one was.&nb= sp; The agreement in NETMOD (and our charter) is to facilitate the creation of models when WGs don’t want to do th= em, have the expertise to do them, etc…  Also, getting the right= Yang experts in one place is not going to happen for every WG in the IETF;= its just not realistic.  I understand that ultimately the WG needs to have consensus, but quick iteration to construct the model= surely can happen in a small “design team” fashion, right?

 

And in terms of today’s meeting being canceled= , really what purpose was that other than to stall/slow-down work?  Th= e group that was there to work on the OSPF model was indeed a bunch of folk= s from OSPF (Acee Lindem for example was on the call).  So now since we won’t have another interim meeting unti= l after Hawaii, so the next time this group can get together is possibly in= Hawaii, but that is probably unlikely as a large number of people are not = going to Hawaii.  So the net-net is a slowing of progress in this area.  Probably not the result the IETF community= wants.

 

—Tom

 

 

 

On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman = <andy@yumaworks.= com> wrote:

 

Hi Adrian,

 

I agree with you. The OSPF WG should be discussing O= SPF data models,

not the NETMOD WG. The domain experts need to reach = consensus

on a feature set (and maybe info model) and then get= 1 or 2 YANG experts to

help translate that to a data model. (Not the other = way around -- a room

full of YANG experts and 1 or 2 OSPF experts).<= /o:p>

 

I also prefer that virtual interim meetings be used = to discuss open issues

on chartered items, not as an additional forum to pr= omote individual drafts.

 

 

Andy

 

 

On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel <<= a href=3D"mailto:adrian@olddog.co.uk" target=3D"_blank">adrian@olddog.co.uk= > wrote:

I understand and appreciate your desire to get work = done.

The rules for IETF virtual interims are neither hard to discover, nor hard = to
comply with. The rules exist to ensure that people are included in the work= , and
I am sure that inclusion is what you want.

I find it unfortunate that you scheduled a working group meeting to discuss= only
one of a pair of competing documents on the same topic, that you didn't mak= e the
information about the meeting available to the authors of the competing doc= ument
or to the people who care about the protocol being modelled, and I find it<= br> upsetting (yes, I am actually upset) that you decided to discuss in Netmod = a
document that belongs in the OSPF working group.

If, as it surely sounds, you wish that the Netmod working group had a diffe= rent
charter to enable it to take on models for protocols that already have a ho= me in
other working groups, then I suggest you need to recharter. But I doubt tha= t
your reasoning that [YANG] experts will not go to all the other working gro= ups
will carry much weight. Frankly, and without wanting to disrespect the YANG=
experts, it is easier to understand YANG than it is to understand OSPF. If = this
were not the case then the Netmod working group would have failed in its de= sign
of YANG!

Conclusion:
You want to work on a YANG model for OSPF. Go to the OSPF working group and=
discuss it (there are already some threads). Review and comment on the comp= eting
document. Try to get agreement between all of the authors of both documents= , or
try to identify the differences. Work with the chairs of the OSPF working g= roup
to advance the work.

Adrian

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com]
> Sent: 22 October 2014 14:29
> To: Benoit Claise
> Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org;
> rtg-ads@to= ols.ietf.org
> Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled
>
>
>       This is hugely disappointing. This is the ki= nd of procedural non-sense
has
> and IS driving people away from the IETF to other places where this wo= rk is
going
> to get done. The simple effect of such silliness will be a reduction i= n speed
and
> quantity of model development.  If the goal of the IESG is to slo= w down the
> velocity of model development and creation, then this approach is perf= ect.
>
>       For the record, the interim NETMOD meeting c= adence has one meeting
> focused on Yang and the other on modeling; is not NETMOD-specific per = say, but
> to promote model creation because no other bi-weekly forum exists to d= o so. It
> is also a place to bring in non-IETF work such as the work done in ODL= , other
open
> source, or just the public community that has explicitly wanted to avo= id the
IETF.
> We have found it a convenient and fruitful place to discuss, and actua= lly
*build*
> models - regardless of their ultimate WG home.  The simple reason= : its a
single
> place for many of the experts to gather. I think you will find it very=
difficult to get
> those people onto a per-WG call every other week.
>
>       I hope the IESG considers this approach care= fully because I do not think
it
> will have the affect the larger IETF community is interested in.
>
>       --Tom
>
>
>
> > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise <bclaise@cisco.com>
wrote:
> >
> > Dear all,
> >
> > Today NETMOD interim meeting is canceled.
> >
> > I received some pushbacks from the routing ADs, on the ground tha= t:
> > 1. This interim appears to be meeting to discuss a non-WG draft f= or which
there
> is no milestone in the working group and for which there is an obvious= home
> outside the working group.
> > 2. The agenda was not announced a week in advance on the IETF ann= ounce list
> as is required
> >
> > Regards, Benoit
> >
> > _______________________________________________
> > Rtg-yang-coord mailing list
> > Rtg-= yang-coord@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtg-yang-coord
> >

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

 

 

 

 

--_000_EF64FF31F4C4384DBCE5D513A791C2B120A5649Fxmbalnx11ciscoc_-- From nobody Wed Oct 22 10:16:07 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A34741ACD43; Wed, 22 Oct 2014 08:14:49 -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 fyppdtmT_B7o; Wed, 22 Oct 2014 08:14:47 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0135.outbound.protection.outlook.com [65.55.169.135]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCBE41ACD41; Wed, 22 Oct 2014 08:14:46 -0700 (PDT) Received: from BN1PR05MB156.namprd05.prod.outlook.com (10.255.205.20) by BN1PR05MB375.namprd05.prod.outlook.com (10.141.61.20) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Wed, 22 Oct 2014 15:14:44 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB156.namprd05.prod.outlook.com (10.255.205.20) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Wed, 22 Oct 2014 15:14:42 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.93]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.93]) with mapi id 15.00.1049.012; Wed, 22 Oct 2014 15:14:42 +0000 From: Dean Bogdanovic To: Jeff Haas Thread-Topic: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled Thread-Index: AQHP7gVrfUczFMowvkyLdK/qmvzsppw8MZkAgAAB3oCAAALwAIAAA1mA Date: Wed, 22 Oct 2014 15:14:41 +0000 Message-ID: References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.11] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB156;UriScan:; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 037291602B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(51704005)(377454003)(189002)(51444003)(24454002)(40100003)(15975445006)(76176999)(82746002)(21056001)(561944003)(31966008)(50986999)(97736003)(101416001)(110136001)(46102003)(87936001)(80022003)(62966002)(50226001)(85306004)(19580405001)(57306001)(92726001)(1941001)(86362001)(92566001)(93916002)(33656002)(87286001)(105586002)(104166001)(2656002)(20776003)(76482002)(99286002)(66066001)(106116001)(77156001)(89996001)(83716003)(4396001)(85852003)(107046002)(19580395003)(230783001)(93886004)(122556002)(77096002)(36756003)(99396003)(106356001)(120916001)(95666004)(64706001)(104396001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB156; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-ID: <6BDEB33396187D4CA9AB41DCE6BCEBA6@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB375; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ZGMiFyszf94yp2Q9tJt-mQD2X7s X-Mailman-Approved-At: Wed, 22 Oct 2014 10:16:05 -0700 Cc: "Rtg-yang-coord@ietf.org" , NETMOD Working Group , "ospf-chairs@tools.ietf.org" , "ops-ads@tools.ietf.org" , "rtg-ads@tools.ietf.org" , Farrel Adrian Subject: Re: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2014 15:14:49 -0000 On Oct 22, 2014, at 11:02 AM, Jeff Haas wrote: >=20 > On Oct 22, 2014, at 10:52 AM, Thomas D. Nadeau = wrote: >=20 >>=20 >> We are trying. The thing is that you cannot just hoist that onto WGs an= d say =93here you go.=94 if they don=92t want to do it. Again, the Netmod = charter was specifically modified to accommodate that case. And while som= e WGs in the routing area are not enthusiastic about building models, other= s aren=92t, nor are other WGs at the IETF. So for those, what do you do? Ig= nore them? The other point is that others outside of the IETF are working o= n these models. It is squarely within the IETF community=92s interest to b= ring these back into the fold. Many of these folks are skittish about comi= ng to the IETF altogether so we=92ve tried to encourage them to participate= in this way. If we want to push these folks away with procedural reasons, = then we have made our bed... >=20 > I've had part of this conversation with Alia recently and with many other= s at the prior IETF, including Benoit. That was part of the motivation to = form the rtg-yang-coord list. Simply put, modeling work needs to happen bu= t the subset of people who actively care about it in any particular WG is u= sually a fraction of the participants. Additionally, the danger of doing i= t in netmod is overloading people who are wanting to work on the language b= ut don't necessarily want to contribute to a given bit of modeling effort. >=20 > I don't know that the "coord" efforts need a full WG, but the semantics o= f managing that at an IETF process perspective are something the IESG cares= more about than I think I do. Basically, coord is likely to be a bunch of= dynamically spun design teams, hopefully reporting back their lessons to s= omeplace like this list. This is a good proposal. We need to be more dynamic with model creations an= d need people who are experts in the area. But absolutely have to be better= coordinated. I think that rtg-yang-coord is a good start, but we need such= a alias for other areas too. Since I was part of a (call it experiment/try= ) for ACL and OSPF models, I think it was a good way to create vendor neutr= al models. It might be not the fastest way, but it was very productive. Cou= ld have we been faster with the models? Yes, but then our paying day job wo= uld suffer, so we are running into same problems as all other volunteering = based projects. It is obvious that we need a more flexibility within IETF, = but also the efforts have to be better coordinated. Dean >=20 > -- Jeff >=20 > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord From nobody Wed Oct 22 11:32:12 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 561BB1ACF01; Wed, 22 Oct 2014 11:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NyqvQw2Uj_ID; Wed, 22 Oct 2014 11:32:02 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5801A8721; Wed, 22 Oct 2014 11:32:01 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Thomas D. Nadeau'" , "'Andy Bierman'" References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> In-Reply-To: Date: Wed, 22 Oct 2014 14:31:54 -0400 Message-ID: <057901cfee26$754ecc20$5fec6460$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_057A_01CFEE04.EE423530" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIUX+ca9u4QKYuEX+hUMOEGGRuotgIuz+VeAfQkGdcB/lG70gLMEl+3m2weNfA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/AgoYr51CfeOeB4pD49CSXgDyYP4 Cc: Rtg-yang-coord@ietf.org, 'NETMOD Working Group' , ospf-chairs@tools.ietf.org, ops-ads@tools.ietf.org, rtg-ads@tools.ietf.org, 'Farrel Adrian' Subject: Re: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2014 18:32:09 -0000 This is a multipart message in MIME format. ------=_NextPart_000_057A_01CFEE04.EE423530 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Tom: Acee indicated earlier on the i2rs list (September discussion) that the OSPF yang model was going to be standardized in OSPF. I'm glad we've got the rtg-yang-coord list to sort out these issues. IDR will pick up all BGP related yang modules. A charter addition has been made. IDR will gladly accept input from the netmod WG or hold joint interim session to make this effort go fast. The configuration drafts for bgp (draft-zhdankin-netmod-bgp-cfg-00.txt) and the I2rs drafts for bgp (draft-i2rs-hares-bgp-dm-00) have only a 5% functional overlap. I will be releasing a draft that compares these two drafts, and looks at how these drafts fulfill the I2RS BGP use case requirements. IDR will sponsor a design team in IDR to push the rapid development of bgp configuration or bgp i2rs. If you could suggest a few netmod people to help this effort it would help. My understanding of IETF best practices indicate that joint interims need 2 weeks announcement of topics. Sue From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of Thomas D. Nadeau Sent: Wednesday, October 22, 2014 10:35 AM To: Andy Bierman Cc: Rtg-yang-coord@ietf.org; NETMOD Working Group; ospf-chairs@tools.ietf.org; ops-ads@tools.ietf.org; rtg-ads@tools.ietf.org; Benoit Claise; Farrel Adrian Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled No one said that OSPF experts could not attend to provide input. The issue is that OSPF was not doing this. If they want to take over doing all OSPF models, then great, but to date no one was. The agreement in NETMOD (and our charter) is to facilitate the creation of models when WGs don't want to do them, have the expertise to do them, etc. Also, getting the right Yang experts in one place is not going to happen for every WG in the IETF; its just not realistic. I understand that ultimately the WG needs to have consensus, but quick iteration to construct the model surely can happen in a small "design team" fashion, right? And in terms of today's meeting being canceled, really what purpose was that other than to stall/slow-down work? The group that was there to work on the OSPF model was indeed a bunch of folks from OSPF (Acee Lindem for example was on the call). So now since we won't have another interim meeting until after Hawaii, so the next time this group can get together is possibly in Hawaii, but that is probably unlikely as a large number of people are not going to Hawaii. So the net-net is a slowing of progress in this area. Probably not the result the IETF community wants. -Tom On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman wrote: Hi Adrian, I agree with you. The OSPF WG should be discussing OSPF data models, not the NETMOD WG. The domain experts need to reach consensus on a feature set (and maybe info model) and then get 1 or 2 YANG experts to help translate that to a data model. (Not the other way around -- a room full of YANG experts and 1 or 2 OSPF experts). I also prefer that virtual interim meetings be used to discuss open issues on chartered items, not as an additional forum to promote individual drafts. Andy On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel wrote: I understand and appreciate your desire to get work done. The rules for IETF virtual interims are neither hard to discover, nor hard to comply with. The rules exist to ensure that people are included in the work, and I am sure that inclusion is what you want. I find it unfortunate that you scheduled a working group meeting to discuss only one of a pair of competing documents on the same topic, that you didn't make the information about the meeting available to the authors of the competing document or to the people who care about the protocol being modelled, and I find it upsetting (yes, I am actually upset) that you decided to discuss in Netmod a document that belongs in the OSPF working group. If, as it surely sounds, you wish that the Netmod working group had a different charter to enable it to take on models for protocols that already have a home in other working groups, then I suggest you need to recharter. But I doubt that your reasoning that [YANG] experts will not go to all the other working groups will carry much weight. Frankly, and without wanting to disrespect the YANG experts, it is easier to understand YANG than it is to understand OSPF. If this were not the case then the Netmod working group would have failed in its design of YANG! Conclusion: You want to work on a YANG model for OSPF. Go to the OSPF working group and discuss it (there are already some threads). Review and comment on the competing document. Try to get agreement between all of the authors of both documents, or try to identify the differences. Work with the chairs of the OSPF working group to advance the work. Adrian > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com] > Sent: 22 October 2014 14:29 > To: Benoit Claise > Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org; > rtg-ads@tools.ietf.org > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled > > > This is hugely disappointing. This is the kind of procedural non-sense has > and IS driving people away from the IETF to other places where this work is going > to get done. The simple effect of such silliness will be a reduction in speed and > quantity of model development. If the goal of the IESG is to slow down the > velocity of model development and creation, then this approach is perfect. > > For the record, the interim NETMOD meeting cadence has one meeting > focused on Yang and the other on modeling; is not NETMOD-specific per say, but > to promote model creation because no other bi-weekly forum exists to do so. It > is also a place to bring in non-IETF work such as the work done in ODL, other open > source, or just the public community that has explicitly wanted to avoid the IETF. > We have found it a convenient and fruitful place to discuss, and actually *build* > models - regardless of their ultimate WG home. The simple reason: its a single > place for many of the experts to gather. I think you will find it very difficult to get > those people onto a per-WG call every other week. > > I hope the IESG considers this approach carefully because I do not think it > will have the affect the larger IETF community is interested in. > > --Tom > > > > > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise wrote: > > > > Dear all, > > > > Today NETMOD interim meeting is canceled. > > > > I received some pushbacks from the routing ADs, on the ground that: > > 1. This interim appears to be meeting to discuss a non-WG draft for which there > is no milestone in the working group and for which there is an obvious home > outside the working group. > > 2. The agenda was not announced a week in advance on the IETF announce list > as is required > > > > Regards, Benoit > > > > _______________________________________________ > > Rtg-yang-coord mailing list > > Rtg-yang-coord@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ------=_NextPart_000_057A_01CFEE04.EE423530 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tom:

 

Acee indicated earlier on the i2rs list (September discussion) that = the OSPF yang model was going to be standardized in OSPF.  = I’m glad we’ve got the rtg-yang-coord list to sort out these = issues.

 

IDR will pick up all BGP related yang modules.  A charter = addition has been made.  IDR will gladly accept input from the = netmod WG or hold joint interim session to make this effort go fast. =  The configuration drafts for bgp = (draft-zhdankin-netmod-bgp-cfg-00.txt) and the I2rs drafts for bgp = (draft-i2rs-hares-bgp-dm-00) have only a 5% functional overlap.  I = will be releasing a draft that compares these two drafts, and looks at = how these drafts fulfill the I2RS BGP use case requirements. =

 

IDR will sponsor a design team in IDR to push the rapid development = of bgp configuration or bgp i2rs.  If you could suggest a few = netmod people to help this effort it would help. =  

 

My understanding of IETF best practices indicate that joint interims = need 2 weeks announcement of topics.

 

Sue

 

From:= = Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of = Thomas D. Nadeau
Sent: Wednesday, October 22, 2014 10:35 = AM
To: Andy Bierman
Cc: Rtg-yang-coord@ietf.org; = NETMOD Working Group; ospf-chairs@tools.ietf.org; = ops-ads@tools.ietf.org; rtg-ads@tools.ietf.org; Benoit Claise; Farrel = Adrian
Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim = meeting canceled

 

 

        &n= bsp;   No one said that OSPF experts could not attend = to provide input.   The issue is that OSPF was not doing this. If = they want to take over doing all OSPF models, then great, but to date no = one was.  The agreement in NETMOD (and our charter) is to = facilitate the creation of models when WGs don’t want to do them, = have the expertise to do them, etc…  Also, getting the right = Yang experts in one place is not going to happen for every WG in the = IETF; its just not realistic.  I understand that ultimately the WG = needs to have consensus, but quick iteration to construct the model = surely can happen in a small “design team” fashion, = right?

 

        &n= bsp;   And in terms of today’s meeting being = canceled, really what purpose was that other than to stall/slow-down = work?  The group that was there to work on the OSPF model was = indeed a bunch of folks from OSPF (Acee Lindem for example was on the = call).  So now since we won’t have another interim meeting = until after Hawaii, so the next time this group can get together is = possibly in Hawaii, but that is probably unlikely as a large number of = people are not going to Hawaii.  So the net-net is a slowing of = progress in this area.  Probably not the result the IETF community = wants.

 

        &n= bsp;   —Tom

 

 

 

On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman = <andy@yumaworks.com> = wrote:

 

Hi = Adrian,

 

I = agree with you. The OSPF WG should be discussing OSPF data = models,

not the NETMOD WG. = The domain experts need to reach consensus

on a feature set (and maybe info model) and then get 1 = or 2 YANG experts to

help = translate that to a data model. (Not the other way around -- a = room

full of YANG experts = and 1 or 2 OSPF experts).

 

I = also prefer that virtual interim meetings be used to discuss open = issues

on chartered items, = not as an additional forum to promote individual = drafts.

 

 

Andy

 

 

On Wed, = Oct 22, 2014 at 6:48 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:

I understand and appreciate your desire to get work = done.

The rules for IETF virtual interims are neither hard to = discover, nor hard to
comply with. The rules exist to ensure that = people are included in the work, and
I am sure that inclusion is what = you want.

I find it unfortunate that you scheduled a working = group meeting to discuss only
one of a pair of competing documents on = the same topic, that you didn't make the
information about the = meeting available to the authors of the competing document
or to the = people who care about the protocol being modelled, and I find = it
upsetting (yes, I am actually upset) that you decided to discuss = in Netmod a
document that belongs in the OSPF working = group.

If, as it surely sounds, you wish that the Netmod working = group had a different
charter to enable it to take on models for = protocols that already have a home in
other working groups, then I = suggest you need to recharter. But I doubt that
your reasoning that = [YANG] experts will not go to all the other working groups
will carry = much weight. Frankly, and without wanting to disrespect the = YANG
experts, it is easier to understand YANG than it is to = understand OSPF. If this
were not the case then the Netmod working = group would have failed in its design
of = YANG!

Conclusion:
You want to work on a YANG model for OSPF. = Go to the OSPF working group and
discuss it (there are already some = threads). Review and comment on the competing
document. Try to get = agreement between all of the authors of both documents, or
try to = identify the differences. Work with the chairs of the OSPF working = group
to advance the work.

Adrian

> -----Original = Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com]
&= gt; Sent: 22 October 2014 14:29
> To: Benoit Claise
> Cc: = NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org;
>= ; rtg-ads@tools.ietf.org
>= Subject: Re: [Rtg-yang-coord] NETMOD interim meeting = canceled
>
>
>       This is = hugely disappointing. This is the kind of procedural = non-sense
has
> and IS driving people away from the IETF to = other places where this work is
going
> to get done. The simple = effect of such silliness will be a reduction in speed
and
> = quantity of model development.  If the goal of the IESG is to slow = down the
> velocity of model development and creation, then this = approach is perfect.
>
>       For the = record, the interim NETMOD meeting cadence has one meeting
> = focused on Yang and the other on modeling; is not NETMOD-specific per = say, but
> to promote model creation because no other bi-weekly = forum exists to do so. It
> is also a place to bring in non-IETF = work such as the work done in ODL, other
open
> source, or just = the public community that has explicitly wanted to avoid = the
IETF.
> We have found it a convenient and fruitful place to = discuss, and actually
*build*
> models - regardless of their = ultimate WG home.  The simple reason: its a
single
> place = for many of the experts to gather. I think you will find it = very
difficult to get
> those people onto a per-WG call every = other week.
>
>       I hope the IESG = considers this approach carefully because I do not think
it
> = will have the affect the larger IETF community is interested = in.
>
>      =  --Tom
>
>
>
> > On Oct 22, 2014:9:16 = AM, at 9:16 AM, Benoit Claise <bclaise@cisco.com>
wrote:
= > >
> > Dear all,
> >
> > Today NETMOD = interim meeting is canceled.
> >
> > I received some = pushbacks from the routing ADs, on the ground that:
> > 1. This = interim appears to be meeting to discuss a non-WG draft for = which
there
> is no milestone in the working group and for = which there is an obvious home
> outside the working = group.
> > 2. The agenda was not announced a week in advance on = the IETF announce list
> as is required
> >
> > = Regards, Benoit
> >
> > = _______________________________________________
> > = Rtg-yang-coord mailing list
> > Rtg-yang-coord@ietf.org
&g= t; > https://www.ietf.org/mailman/listinfo/rtg-yang-coord
> = >

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

 

 

------=_NextPart_000_057A_01CFEE04.EE423530-- From nobody Wed Oct 22 11:49:16 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 543901A90FB; Wed, 22 Oct 2014 11:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3v8QEgsAC3YL; Wed, 22 Oct 2014 11:49:12 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA491ACF08; Wed, 22 Oct 2014 11:48:44 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'rapenno'" , , , References: In-Reply-To: Date: Wed, 22 Oct 2014 14:48:39 -0400 Message-ID: <05d901cfee28$cba9d040$62fd70c0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_05DA_01CFEE07.44991AA0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJlznl6EaXzdWJBjKvNLlfL9/Ql/JsQtETA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/z-cObcfJH2A8iCH-a272nusxfz8 Subject: Re: [netmod] [Rtg-yang-coord] interim meeting: yang model focus X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2014 18:49:13 -0000 This is a multipart message in MIME format. ------=_NextPart_000_05DA_01CFEE07.44991AA0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Tom:=20 =20 I have an I2RS related SFC yang model (state and policy) to discuss as = well. May this get added to the next interim if time allows.=20 =20 Sue=20 =20 From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf = Of rapenno Sent: Tuesday, October 21, 2014 7:32 PM To: tnadeau@lucidvision.com; netmod@ietf.org; rtg-yang-coord@ietf.org Subject: Re: [Rtg-yang-coord] [netmod] interim meeting: yang model focus =20 I would like to discuss SFC yang modelnif time permits =20 =20 Sent from Samsung Mobile -------- Original message -------- From: "Thomas D. Nadeau" =20 Date:=20 To: NETMOD Working Group ,rtg-yang-coord@ietf.org=20 Subject: [netmod] interim meeting: yang model focus=20 [adding rtg-yang-coord] Tomorrow's meeting will use the same WebEx from last time (and the same = as was used last week at the Yang 1.1-focused meeting).=20 Tomorrow's interim meeting has the following preliminary agenda: 0) Quickly how to use IRC/sign-in 1) Note Well 2) Agenda Bashing 3) OSPF Model - Kiran Agrahara Sreenivasa ; = myeung@cisco.com Are there any other models people wish to discuss? --Tom _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ------=_NextPart_000_05DA_01CFEE07.44991AA0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Tom:

 

I have an I2RS related SFC yang model (state and policy) to discuss = as well.=C2=A0 May this get added to the next interim if time allows. =

 

Sue

 

From:= = Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of = rapenno
Sent: Tuesday, October 21, 2014 7:32 = PM
To: tnadeau@lucidvision.com; netmod@ietf.org; = rtg-yang-coord@ietf.org
Subject: Re: [Rtg-yang-coord] [netmod] = interim meeting: yang model focus

 

I = would like to discuss SFC yang modelnif time = permits

 

 

Sent = from Samsung Mobile




-------- Original message = --------
From: "Thomas D. Nadeau" <tnadeau@lucidvision.com> =
Date:
To: NETMOD Working Group <netmod@ietf.org>,rtg-yang-coord@ie= tf.org
Subject: [netmod] interim meeting: yang model focus =


[adding  rtg-yang-coord]


Tomorrow's meeting = will use the same WebEx from last time (and the same as was used last = week at the Yang 1.1-focused meeting).

Tomorrow's interim = meeting has the following preliminary agenda:

0) Quickly how to = use IRC/sign-in
1) Note Well
2) Agenda Bashing
3) OSPF Model - = Kiran Agrahara Sreenivasa <kkoushik@Brocade.com>; myeung@cisco.com


Are = there any other models people wish to = discuss?

--Tom



____________________________________= ___________
netmod mailing list
netmod@ietf.org
https://www.ietf.or= g/mailman/listinfo/netmod

------=_NextPart_000_05DA_01CFEE07.44991AA0-- From nobody Wed Oct 22 11:51:03 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A80541ACF9F; Wed, 22 Oct 2014 11:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNeaWAZPF-4Q; Wed, 22 Oct 2014 11:50:59 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id F39441A87BB; Wed, 22 Oct 2014 11:50:58 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: , "'Benoit Claise'" References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <19590_1413985494_5447B4D6_19590_2565_1_9E32478DFA9976438E7A22F69B08FF92142C87@OPEXCLILM34.corporate.adroot.infra.ftgroup> In-Reply-To: <19590_1413985494_5447B4D6_19590_2565_1_9E32478DFA9976438E7A22F69B08FF92142C87@OPEXCLILM34.corporate.adroot.infra.ftgroup> Date: Wed, 22 Oct 2014 14:50:52 -0400 Message-ID: <05f101cfee29$1b45e8f0$51d1bad0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIUX+ca9u4QKYuEX+hUMOEGGRuotgIuz+VeAiRwUfGbkPfe0A== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Y9rgDaf3ZIQdHLLdKmlhVSuDIJs Cc: Rtg-yang-coord@ietf.org, ops-ads@tools.ietf.org, 'NETMOD Working Group' , rtg-ads@tools.ietf.org Subject: Re: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2014 18:51:01 -0000 Stephane: I think it is important to receive both the wisdom from the netmod WG and the protocol WG. I find that there are yang model consistencies and limitations that require aid in the yang models I've worked on. This is especially true for the state and ephemeral state. Sue -----Original Message----- From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of stephane.litkowski@orange.com Sent: Wednesday, October 22, 2014 9:45 AM To: Benoit Claise Cc: Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org; NETMOD Working Group; rtg-ads@tools.ietf.org Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled Hi, I also agree that this is a bad idea. I thought that IETF willing and especially yours, Benoit, was to speed up availability of standard models. The process of having small teams working with weekly calls works almost good but we still have some issue that are both technical (dedicated to the topic addressed by the model) and also YANG writing, model consistencies ... that requires discussion, and as often mailing list is not as good as meetings (that's why the proposal of small teams was done). At the present time, I personally support the initiative of having interim meetings in Netmod to discuss proposed Yang models : this will ensure consistency between models and will help to solve global issues in modeling. It's just the starting of Yang modeling, leaving only Yang models within home WG (ISIS for my point of view) would be, IMO, a very bad idea and will for sure slow down the availability of standards ... and I also think that it may discourage people to work on because of the added overhead. It was just my opinion ... Best Regards, Stephane -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Thomas D. Nadeau Sent: Wednesday, October 22, 2014 15:29 To: Benoit Claise Cc: Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org; NETMOD Working Group; rtg-ads@tools.ietf.org Subject: Re: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled This is hugely disappointing. This is the kind of procedural non-sense has and IS driving people away from the IETF to other places where this work is going to get done. The simple effect of such silliness will be a reduction in speed and quantity of model development. If the goal of the IESG is to slow down the velocity of model development and creation, then this approach is perfect. For the record, the interim NETMOD meeting cadence has one meeting focused on Yang and the other on modeling; is not NETMOD-specific per say, but to promote model creation because no other bi-weekly forum exists to do so. It is also a place to bring in non-IETF work such as the work done in ODL, other open source, or just the public community that has explicitly wanted to avoid the IETF. We have found it a convenient and fruitful place to discuss, and actually *build* models - regardless of their ultimate WG home. The simple reason: its a single place for many of the experts to gather. I think you will find it very difficult to get those people onto a per-WG call every other week. I hope the IESG considers this approach carefully because I do not think it will have the affect the larger IETF community is interested in. --Tom > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise wrote: > > Dear all, > > Today NETMOD interim meeting is canceled. > > I received some pushbacks from the routing ADs, on the ground that: > 1. This interim appears to be meeting to discuss a non-WG draft for which there is no milestone in the working group and for which there is an obvious home outside the working group. > 2. The agenda was not announced a week in advance on the IETF announce > list as is required > > Regards, Benoit > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ____________________________________________________________________________ _____________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ Rtg-yang-coord mailing list Rtg-yang-coord@ietf.org https://www.ietf.org/mailman/listinfo/rtg-yang-coord From nobody Wed Oct 22 11:56:26 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E14D1ACFEB; Wed, 22 Oct 2014 11:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UuZFCn0YhB20; Wed, 22 Oct 2014 11:56:16 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6101D1ACFF1; Wed, 22 Oct 2014 11:56:16 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Eric Voit \(evoit\)'" , "'Thomas D. Nadeau'" , "'Andy Bierman'" References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> In-Reply-To: Date: Wed, 22 Oct 2014 14:56:09 -0400 Message-ID: <061201cfee29$d87b9000$8972b000$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0613_01CFEE08.516F4730" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIUX+ca9u4QKYuEX+hUMOEGGRuotgIuz+VeAfQkGdcB/lG70gLMEl+3Ae5R6RAAvWtNfQFaI9Swm0v53gA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/l1RXzVAGKqr-ttBwfLG7W8-IYuI Cc: Rtg-yang-coord@ietf.org, 'NETMOD Working Group' , ospf-chairs@tools.ietf.org, ops-ads@tools.ietf.org, rtg-ads@tools.ietf.org, 'Farrel Adrian' Subject: Re: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2014 18:56:22 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0613_01CFEE08.516F4730 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Eric: What were the OpenDaylight topics for the call? Sue From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of Eric Voit (evoit) Sent: Wednesday, October 22, 2014 11:20 AM To: Thomas D. Nadeau; Andy Bierman Cc: Rtg-yang-coord@ietf.org; NETMOD Working Group; ospf-chairs@tools.ietf.org; ops-ads@tools.ietf.org; rtg-ads@tools.ietf.org; Farrel Adrian Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled As Tom and others note, today's Netmod interim was to have topics beyond OSPF. These included OpenDaylight related work. The IETF should be encouraging venues for Open Source developer audiences. Cancelling full meetings via IETF procedural mechanisms signals the opposite. I *like* the idea of each WG being the owner for their domain models. This scales well for the reasons pointed out below. And I do have sympathy for a WG wanting to close on a definitive answer for a YANG model before implications are discussed elsewhere. But I am worried that we are enforcing an overly serial process. Or of constraining communication. The market will work around this. In the controller space, YANG technology is not static. Some degree of parallelism is needed across IETF WGs. Clueful Open Source/YANG developers cannot extend themselves across all WG where YANG modeling might occur. Eric From: Thomas D. Nadeau, October 22, 2014 10:52 AM We are trying. The thing is that you cannot just hoist that onto WGs and say "here you go." if they don't want to do it. Again, the Netmod charter was specifically modified to accommodate that case. And while some WGs in the routing area are not enthusiastic about building models, others aren't, nor are other WGs at the IETF. So for those, what do you do? Ignore them? The other point is that others outside of the IETF are working on these models. It is squarely within the IETF community's interest to bring these back into the fold. Many of these folks are skittish about coming to the IETF altogether so we've tried to encourage them to participate in this way. If we want to push these folks away with procedural reasons, then we have made our bed... -tom On Oct 22, 2014:10:45 AM, at 10:45 AM, Andy Bierman wrote: Hi, I think the interim did not need to be cancelled. There are ACL, SYSLOG, and YANG Mount topics. I was going to call in for those, not OSPF. But I have been saying (for over a year now) that it is time to move domain-specific data models into the domain-specific WGs. I think NETMOD WG should focus on the YANG language and infrastructure modules. Andy On Wed, Oct 22, 2014 at 7:35 AM, Thomas D. Nadeau wrote: No one said that OSPF experts could not attend to provide input. The issue is that OSPF was not doing this. If they want to take over doing all OSPF models, then great, but to date no one was. The agreement in NETMOD (and our charter) is to facilitate the creation of models when WGs don't want to do them, have the expertise to do them, etc. Also, getting the right Yang experts in one place is not going to happen for every WG in the IETF; its just not realistic. I understand that ultimately the WG needs to have consensus, but quick iteration to construct the model surely can happen in a small "design team" fashion, right? And in terms of today's meeting being canceled, really what purpose was that other than to stall/slow-down work? The group that was there to work on the OSPF model was indeed a bunch of folks from OSPF (Acee Lindem for example was on the call). So now since we won't have another interim meeting until after Hawaii, so the next time this group can get together is possibly in Hawaii, but that is probably unlikely as a large number of people are not going to Hawaii. So the net-net is a slowing of progress in this area. Probably not the result the IETF community wants. -Tom On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman wrote: Hi Adrian, I agree with you. The OSPF WG should be discussing OSPF data models, not the NETMOD WG. The domain experts need to reach consensus on a feature set (and maybe info model) and then get 1 or 2 YANG experts to help translate that to a data model. (Not the other way around -- a room full of YANG experts and 1 or 2 OSPF experts). I also prefer that virtual interim meetings be used to discuss open issues on chartered items, not as an additional forum to promote individual drafts. Andy On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel wrote: I understand and appreciate your desire to get work done. The rules for IETF virtual interims are neither hard to discover, nor hard to comply with. The rules exist to ensure that people are included in the work, and I am sure that inclusion is what you want. I find it unfortunate that you scheduled a working group meeting to discuss only one of a pair of competing documents on the same topic, that you didn't make the information about the meeting available to the authors of the competing document or to the people who care about the protocol being modelled, and I find it upsetting (yes, I am actually upset) that you decided to discuss in Netmod a document that belongs in the OSPF working group. If, as it surely sounds, you wish that the Netmod working group had a different charter to enable it to take on models for protocols that already have a home in other working groups, then I suggest you need to recharter. But I doubt that your reasoning that [YANG] experts will not go to all the other working groups will carry much weight. Frankly, and without wanting to disrespect the YANG experts, it is easier to understand YANG than it is to understand OSPF. If this were not the case then the Netmod working group would have failed in its design of YANG! Conclusion: You want to work on a YANG model for OSPF. Go to the OSPF working group and discuss it (there are already some threads). Review and comment on the competing document. Try to get agreement between all of the authors of both documents, or try to identify the differences. Work with the chairs of the OSPF working group to advance the work. Adrian > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com] > Sent: 22 October 2014 14:29 > To: Benoit Claise > Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org; > rtg-ads@tools.ietf.org > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled > > > This is hugely disappointing. This is the kind of procedural non-sense has > and IS driving people away from the IETF to other places where this work is going > to get done. The simple effect of such silliness will be a reduction in speed and > quantity of model development. If the goal of the IESG is to slow down the > velocity of model development and creation, then this approach is perfect. > > For the record, the interim NETMOD meeting cadence has one meeting > focused on Yang and the other on modeling; is not NETMOD-specific per say, but > to promote model creation because no other bi-weekly forum exists to do so. It > is also a place to bring in non-IETF work such as the work done in ODL, other open > source, or just the public community that has explicitly wanted to avoid the IETF. > We have found it a convenient and fruitful place to discuss, and actually *build* > models - regardless of their ultimate WG home. The simple reason: its a single > place for many of the experts to gather. I think you will find it very difficult to get > those people onto a per-WG call every other week. > > I hope the IESG considers this approach carefully because I do not think it > will have the affect the larger IETF community is interested in. > > --Tom > > > > > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise wrote: > > > > Dear all, > > > > Today NETMOD interim meeting is canceled. > > > > I received some pushbacks from the routing ADs, on the ground that: > > 1. This interim appears to be meeting to discuss a non-WG draft for which there > is no milestone in the working group and for which there is an obvious home > outside the working group. > > 2. The agenda was not announced a week in advance on the IETF announce list > as is required > > > > Regards, Benoit > > > > _______________________________________________ > > Rtg-yang-coord mailing list > > Rtg-yang-coord@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ------=_NextPart_000_0613_01CFEE08.516F4730 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Eric:

 

What were the OpenDaylight topics for the call?  =

 

Sue

 

From:= = Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of = Eric Voit (evoit)
Sent: Wednesday, October 22, 2014 11:20 = AM
To: Thomas D. Nadeau; Andy Bierman
Cc: = Rtg-yang-coord@ietf.org; NETMOD Working Group; = ospf-chairs@tools.ietf.org; ops-ads@tools.ietf.org; = rtg-ads@tools.ietf.org; Farrel Adrian
Subject: Re: = [Rtg-yang-coord] [netmod] NETMOD interim meeting = canceled

 

As Tom = and others note, today’s Netmod interim was to have topics beyond = OSPF.  These included OpenDaylight related work.   The = IETF should be encouraging venues for Open Source developer = audiences.  Cancelling full meetings via IETF procedural mechanisms = signals the opposite. 

 

I = *like* the idea of each WG being the owner for their domain = models.  This scales well for the reasons  pointed out = below.  And I do have sympathy for a WG wanting to close on a = definitive answer for a YANG model before implications are discussed = elsewhere.   But I am worried that we are enforcing an overly = serial process.  Or of constraining communication.  The market = will work around this.  

 

In the = controller space, YANG technology is not static.  Some degree of = parallelism is needed across IETF WGs.  Clueful Open Source/YANG = developers cannot extend themselves across all WG where YANG modeling = might occur.

 

Eric

 

 

From:= = Thomas D. Nadeau, October 22, 2014 10:52 AM

        &n= bsp; We are trying. The thing is that you cannot just hoist that = onto WGs and say “here you go.” if they don’t want to = do it.  Again, the Netmod charter was specifically modified to = accommodate that case.   And while some WGs in the routing area are = not enthusiastic about building models, others aren’t, nor are = other WGs at the IETF. So for those, what do you do? Ignore them? The = other point is that others outside of the IETF are working on these = models.  It is squarely within the IETF community’s interest = to bring these back into the fold.  Many of these folks are = skittish about coming to the IETF altogether so we’ve tried to = encourage them to participate in this way. If we want to push these = folks away with procedural reasons, then we have made our = bed...

 

        &n= bsp; —tom

 

 

 

On Oct 22, 2014:10:45 AM, at 10:45 AM, Andy Bierman = <andy@yumaworks.com> = wrote:

 

Hi,

 

I = think the interim did not need to be cancelled. There are ACL, = SYSLOG,

and YANG Mount = topics. I was going to call in for those, not = OSPF.

But I have been = saying (for over a year now) that it is time to = move

domain-specific data = models into the domain-specific WGs.

I think NETMOD WG should focus on the YANG language = and

infrastructure = modules.

 

Andy

 

 

On Wed, = Oct 22, 2014 at 7:35 AM, Thomas D. Nadeau <tnadeau@lucidvision.com> = wrote:

 

No one = said that OSPF experts could not attend to provide input.   The = issue is that OSPF was not doing this. If they want to take over doing = all OSPF models, then great, but to date no one was.  The agreement = in NETMOD (and our charter) is to facilitate the creation of models when = WGs don’t want to do them, have the expertise to do them, = etc…  Also, getting the right Yang experts in one place is = not going to happen for every WG in the IETF; its just not = realistic.  I understand that ultimately the WG needs to have = consensus, but quick iteration to construct the model surely can happen = in a small “design team” fashion, = right?

 

And in terms of today’s meeting being canceled, = really what purpose was that other than to stall/slow-down work?  = The group that was there to work on the OSPF model was indeed a bunch of = folks from OSPF (Acee Lindem for example was on the call).  So now = since we won’t have another interim meeting until after Hawaii, so = the next time this group can get together is possibly in Hawaii, but = that is probably unlikely as a large number of people are not going to = Hawaii.  So the net-net is a slowing of progress in this = area.  Probably not the result the IETF community = wants.

 

—Tom

 

 

 

On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman = <andy@yumaworks.com> = wrote:

 

Hi = Adrian,

 

I = agree with you. The OSPF WG should be discussing OSPF data = models,

not the NETMOD WG. = The domain experts need to reach consensus

on a feature set (and maybe info model) and then get 1 = or 2 YANG experts to

help = translate that to a data model. (Not the other way around -- a = room

full of YANG experts = and 1 or 2 OSPF experts).

 

I = also prefer that virtual interim meetings be used to discuss open = issues

on chartered items, = not as an additional forum to promote individual = drafts.

 

 

Andy

 

 

On Wed, = Oct 22, 2014 at 6:48 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:

I understand and appreciate your desire to get work = done.

The rules for IETF virtual interims are neither hard to = discover, nor hard to
comply with. The rules exist to ensure that = people are included in the work, and
I am sure that inclusion is what = you want.

I find it unfortunate that you scheduled a working = group meeting to discuss only
one of a pair of competing documents on = the same topic, that you didn't make the
information about the = meeting available to the authors of the competing document
or to the = people who care about the protocol being modelled, and I find = it
upsetting (yes, I am actually upset) that you decided to discuss = in Netmod a
document that belongs in the OSPF working = group.

If, as it surely sounds, you wish that the Netmod working = group had a different
charter to enable it to take on models for = protocols that already have a home in
other working groups, then I = suggest you need to recharter. But I doubt that
your reasoning that = [YANG] experts will not go to all the other working groups
will carry = much weight. Frankly, and without wanting to disrespect the = YANG
experts, it is easier to understand YANG than it is to = understand OSPF. If this
were not the case then the Netmod working = group would have failed in its design
of = YANG!

Conclusion:
You want to work on a YANG model for OSPF. = Go to the OSPF working group and
discuss it (there are already some = threads). Review and comment on the competing
document. Try to get = agreement between all of the authors of both documents, or
try to = identify the differences. Work with the chairs of the OSPF working = group
to advance the work.

Adrian

> -----Original = Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com]
> Sent: 22 October = 2014 14:29
> To: Benoit Claise
> Cc: NETMOD Working Group; = Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org;
> rtg-ads@tools.ietf.org
> Subject: Re: = [Rtg-yang-coord] NETMOD interim meeting = canceled
>
>
>       This is = hugely disappointing. This is the kind of procedural = non-sense
has
> and IS driving people away from the IETF to = other places where this work is
going
> to get done. The simple = effect of such silliness will be a reduction in speed
and
> = quantity of model development.  If the goal of the IESG is to slow = down the
> velocity of model development and creation, then this = approach is perfect.
>
>       For the = record, the interim NETMOD meeting cadence has one meeting
> = focused on Yang and the other on modeling; is not NETMOD-specific per = say, but
> to promote model creation because no other bi-weekly = forum exists to do so. It
> is also a place to bring in non-IETF = work such as the work done in ODL, other
open
> source, or just = the public community that has explicitly wanted to avoid = the
IETF.
> We have found it a convenient and fruitful place to = discuss, and actually
*build*
> models - regardless of their = ultimate WG home.  The simple reason: its a
single
> place = for many of the experts to gather. I think you will find it = very
difficult to get
> those people onto a per-WG call every = other week.
>
>       I hope the IESG = considers this approach carefully because I do not think
it
> = will have the affect the larger IETF community is interested = in.
>
>      =  --Tom
>
>
>
> > On Oct 22, 2014:9:16 = AM, at 9:16 AM, Benoit Claise <bclaise@cisco.com>
wrote:
> = >
> > Dear all,
> >
> > Today NETMOD = interim meeting is canceled.
> >
> > I received some = pushbacks from the routing ADs, on the ground that:
> > 1. This = interim appears to be meeting to discuss a non-WG draft for = which
there
> is no milestone in the working group and for = which there is an obvious home
> outside the working = group.
> > 2. The agenda was not announced a week in advance on = the IETF announce list
> as is required
> >
> > = Regards, Benoit
> >
> > = _______________________________________________
> > = Rtg-yang-coord mailing list
> > Rtg-yang-coord@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtg-yang-coord
> = >

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

 

 

 

 

------=_NextPart_000_0613_01CFEE08.516F4730-- From nobody Wed Oct 22 12:13:49 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09D631ACFEA; Wed, 22 Oct 2014 12:13:27 -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 Dcvgae9OlgaK; Wed, 22 Oct 2014 12:13:15 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A04D1ACF8B; Wed, 22 Oct 2014 12:13:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33071; q=dns/txt; s=iport; t=1414005195; x=1415214795; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Odlc9ScreNuzCTuo07KVItUZCWbjWBn+BxXEXqY1B5o=; b=Mu/LDebut9pjEVoXNqRVQ+W715s0jc0xTI2o4qnRV/n2pxhXDpXgezg1 RMBiw1Inzdyfr3eKwmD/5VHxhrGVTT+MGe5bNaihQHiK61XJ39bkKw5Vy DoOu1JgqDuV7gZXfMYSkLgoCqOG6B35mUXfeuZ0xDpS1Z7v/jb4+TPJAG A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnMFAGgASFStJA2N/2dsb2JhbABSCoJIRlRYBLwfjk6BZgELhndUAoEOFgF9hAIBAQECAgEBASo+AwsMBAIBCA4DBAEBAQoWAQYHJwsUCQgCBAENBQgBCwuIIQ3FfQEBAQEBAQEBAQEBAQEBAQEBAQEBAReKVoUlKy0EBgEGgyeBHgWPZoIehEaIRDyQPIQBg3hsAYEFBD6BAwEBAQ X-IronPort-AV: E=Sophos;i="5.04,770,1406592000"; d="scan'208,217";a="365546372" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-3.cisco.com with ESMTP; 22 Oct 2014 19:13:11 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s9MJDB16025467 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Oct 2014 19:13:11 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.58]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Wed, 22 Oct 2014 14:13:11 -0500 From: "Eric Voit (evoit)" To: Susan Hares , "'Thomas D. Nadeau'" , "'Andy Bierman'" Thread-Topic: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled Thread-Index: AQHP7ingTtZBL8o2rEqTZTZCzObUr5w8eSrA Date: Wed, 22 Oct 2014 19:13:10 +0000 Message-ID: References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> <061201cfee29$d87b9000$8972b000$@ndzh.com> In-Reply-To: <061201cfee29$d87b9000$8972b000$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.134.135] Content-Type: multipart/alternative; boundary="_000_EF64FF31F4C4384DBCE5D513A791C2B120A566CDxmbalnx11ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/XehjJBIzYGwvB5Cu5R2jmO9FVUo Cc: "Rtg-yang-coord@ietf.org" , 'NETMOD Working Group' , "ospf-chairs@tools.ietf.org" , "ops-ads@tools.ietf.org" , "rtg-ads@tools.ietf.org" , 'Farrel Adrian' Subject: Re: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2014 19:13:28 -0000 --_000_EF64FF31F4C4384DBCE5D513A791C2B120A566CDxmbalnx11ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Two weeks ago at the Netmod Interim, we discussed: http://datatracker.ietf.org/doc/draft-voit-netmod-peer-mount-requirements= / http://datatracker.ietf.org/doc/draft-clemm-netmod-mount/ We used these slides= to introduce the topics. On the Netmod interim agenda today was to be a recap/summary of the resulti= ng mailing list discussions, as well the teeing up of exactly what could be= on the plate for Hawaii Netmod face-to-face. Thanks, Eric From: Susan Hares, October 22, 2014 2:56 PM Eric: What were the OpenDaylight topics for the call? Sue From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of = Eric Voit (evoit) Sent: Wednesday, October 22, 2014 11:20 AM To: Thomas D. Nadeau; Andy Bierman Cc: Rtg-yang-coord@ietf.org; NETMOD Working= Group; ospf-chairs@tools.ietf.org; ops-= ads@tools.ietf.org; rtg-ads@tools.ietf.org; Farrel Adrian Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled As Tom and others note, today's Netmod interim was to have topics beyond OS= PF. These included OpenDaylight related work. The IETF should be encoura= ging venues for Open Source developer audiences. Cancelling full meetings = via IETF procedural mechanisms signals the opposite. I *like* the idea of each WG being the owner for their domain models. This= scales well for the reasons pointed out below. And I do have sympathy fo= r a WG wanting to close on a definitive answer for a YANG model before impl= ications are discussed elsewhere. But I am worried that we are enforcing = an overly serial process. Or of constraining communication. The market wi= ll work around this. In the controller space, YANG technology is not static. Some degree of par= allelism is needed across IETF WGs. Clueful Open Source/YANG developers ca= nnot extend themselves across all WG where YANG modeling might occur. Eric From: Thomas D. Nadeau, October 22, 2014 10:52 AM We are trying. The thing is that you cannot just hoist that onto = WGs and say "here you go." if they don't want to do it. Again, the Netmod = charter was specifically modified to accommodate that case. And while som= e WGs in the routing area are not enthusiastic about building models, other= s aren't, nor are other WGs at the IETF. So for those, what do you do? Igno= re them? The other point is that others outside of the IETF are working on = these models. It is squarely within the IETF community's interest to bring= these back into the fold. Many of these folks are skittish about coming t= o the IETF altogether so we've tried to encourage them to participate in th= is way. If we want to push these folks away with procedural reasons, then w= e have made our bed... -tom On Oct 22, 2014:10:45 AM, at 10:45 AM, Andy Bierman > wrote: Hi, I think the interim did not need to be cancelled. There are ACL, SYSLOG, and YANG Mount topics. I was going to call in for those, not OSPF. But I have been saying (for over a year now) that it is time to move domain-specific data models into the domain-specific WGs. I think NETMOD WG should focus on the YANG language and infrastructure modules. Andy On Wed, Oct 22, 2014 at 7:35 AM, Thomas D. Nadeau > wrote: No one said that OSPF experts could not attend to provide input. The issu= e is that OSPF was not doing this. If they want to take over doing all OSPF= models, then great, but to date no one was. The agreement in NETMOD (and = our charter) is to facilitate the creation of models when WGs don't want to= do them, have the expertise to do them, etc... Also, getting the right Ya= ng experts in one place is not going to happen for every WG in the IETF; it= s just not realistic. I understand that ultimately the WG needs to have co= nsensus, but quick iteration to construct the model surely can happen in a = small "design team" fashion, right? And in terms of today's meeting being canceled, really what purpose was tha= t other than to stall/slow-down work? The group that was there to work on = the OSPF model was indeed a bunch of folks from OSPF (Acee Lindem for examp= le was on the call). So now since we won't have another interim meeting un= til after Hawaii, so the next time this group can get together is possibly = in Hawaii, but that is probably unlikely as a large number of people are no= t going to Hawaii. So the net-net is a slowing of progress in this area. = Probably not the result the IETF community wants. -Tom On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman > wrote: Hi Adrian, I agree with you. The OSPF WG should be discussing OSPF data models, not the NETMOD WG. The domain experts need to reach consensus on a feature set (and maybe info model) and then get 1 or 2 YANG experts to help translate that to a data model. (Not the other way around -- a room full of YANG experts and 1 or 2 OSPF experts). I also prefer that virtual interim meetings be used to discuss open issues on chartered items, not as an additional forum to promote individual drafts= . Andy On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel > wrote: I understand and appreciate your desire to get work done. The rules for IETF virtual interims are neither hard to discover, nor hard = to comply with. The rules exist to ensure that people are included in the work= , and I am sure that inclusion is what you want. I find it unfortunate that you scheduled a working group meeting to discuss= only one of a pair of competing documents on the same topic, that you didn't mak= e the information about the meeting available to the authors of the competing doc= ument or to the people who care about the protocol being modelled, and I find it upsetting (yes, I am actually upset) that you decided to discuss in Netmod = a document that belongs in the OSPF working group. If, as it surely sounds, you wish that the Netmod working group had a diffe= rent charter to enable it to take on models for protocols that already have a ho= me in other working groups, then I suggest you need to recharter. But I doubt tha= t your reasoning that [YANG] experts will not go to all the other working gro= ups will carry much weight. Frankly, and without wanting to disrespect the YANG experts, it is easier to understand YANG than it is to understand OSPF. If = this were not the case then the Netmod working group would have failed in its de= sign of YANG! Conclusion: You want to work on a YANG model for OSPF. Go to the OSPF working group and discuss it (there are already some threads). Review and comment on the comp= eting document. Try to get agreement between all of the authors of both documents= , or try to identify the differences. Work with the chairs of the OSPF working g= roup to advance the work. Adrian > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com] > Sent: 22 October 2014 14:29 > To: Benoit Claise > Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org; > rtg-ads@tools.ietf.org > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled > > > This is hugely disappointing. This is the kind of procedural non-se= nse has > and IS driving people away from the IETF to other places where this work = is going > to get done. The simple effect of such silliness will be a reduction in s= peed and > quantity of model development. If the goal of the IESG is to slow down t= he > velocity of model development and creation, then this approach is perfect= . > > For the record, the interim NETMOD meeting cadence has one meeting > focused on Yang and the other on modeling; is not NETMOD-specific per say= , but > to promote model creation because no other bi-weekly forum exists to do s= o. It > is also a place to bring in non-IETF work such as the work done in ODL, o= ther open > source, or just the public community that has explicitly wanted to avoid = the IETF. > We have found it a convenient and fruitful place to discuss, and actually *build* > models - regardless of their ultimate WG home. The simple reason: its a single > place for many of the experts to gather. I think you will find it very difficult to get > those people onto a per-WG call every other week. > > I hope the IESG considers this approach carefully because I do not = think it > will have the affect the larger IETF community is interested in. > > --Tom > > > > > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise > wrote: > > > > Dear all, > > > > Today NETMOD interim meeting is canceled. > > > > I received some pushbacks from the routing ADs, on the ground that: > > 1. This interim appears to be meeting to discuss a non-WG draft for whi= ch there > is no milestone in the working group and for which there is an obvious ho= me > outside the working group. > > 2. The agenda was not announced a week in advance on the IETF announce = list > as is required > > > > Regards, Benoit > > > > _______________________________________________ > > Rtg-yang-coord mailing list > > Rtg-yang-coord@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --_000_EF64FF31F4C4384DBCE5D513A791C2B120A566CDxmbalnx11ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Two weeks ago at the Netm= od Interim, we discussed:

  http://datatracker.ietf.org/doc/draft-voit-netmod-peer-mount-requirements/<= /a>

  http://datatracker.ietf.org/doc/draft-clemm-ne= tmod-mount/

We used these sli= des to introduce the topics.  

 <= /p>

On the Netmod interim age= nda today was to be a recap/summary of the resulting mailing list discussio= ns, as well the teeing up of exactly what could be on the plate for Hawaii Netmod face-to-face.

 <= /p>

Thanks,=

Eric

 <= /p>

 <= /p>

From: Susan Ha= res, October 22, 2014 2:56 PM

Eric:

 <= /p>

What were the OpenDayligh= t topics for the call? 

 <= /p>

Sue

 <= /p>

From: Rtg-yang= -coord [mailto:rtg-yang-= coord-bounces@ietf.org] On Behalf Of Eric Voit (evoit)
Sent: Wednesday, October 22, 2014 11:20 AM
To: Thomas D. Nadeau; Andy Bierman
Cc: Rtg-yang-coord@ietf.o= rg; NETMOD Working Group; ospf-chairs@tools.ietf.org; ops-ads@tools.ietf.org; rtg-a= ds@tools.ietf.org; Farrel Adrian
Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting cancel= ed

 

As Tom and others note, today’s Netmod inte= rim was to have topics beyond OSPF.  These included OpenDaylight relat= ed work.   The IETF should be encouraging venues for Open Source = developer audiences.  Cancelling full meetings via IETF procedural mechanisms signals the opposite. 

 

I *like* the idea of each WG being the owner for = their domain models.  This scales well for the reasons  pointed o= ut below.  And I do have sympathy for a WG wanting to close on a defin= itive answer for a YANG model before implications are discussed elsewhere.   But I am worried that we are enforcin= g an overly serial process.  Or of constraining communication.  T= he market will work around this.  

 

In the controller space, YANG technology is not s= tatic.  Some degree of parallelism is needed across IETF WGs.  Cl= ueful Open Source/YANG developers cannot extend themselves across all WG wh= ere YANG modeling might occur.

 

Eric

 <= /p>

 <= /p>

From:<= /span> Thomas D. Nadeau, October 22, 2014 10:52 AM

   &nb= sp;      We are trying. The thing is that y= ou cannot just hoist that onto WGs and say “here you go.” if th= ey don’t want to do it.  Again, the Netmod charter was specifica= lly modified to accommodate that case.   And while some WGs in the routing area are not enthusiastic a= bout building models, others aren’t, nor are other WGs at the IETF. S= o for those, what do you do? Ignore them? The other point is that others ou= tside of the IETF are working on these models.  It is squarely within the IETF community’s interest to bring t= hese back into the fold.  Many of these folks are skittish about comin= g to the IETF altogether so we’ve tried to encourage them to particip= ate in this way. If we want to push these folks away with procedural reasons, then we have made our bed...

 

   &nb= sp;      —tom

 

 

 

On Oct 22, 2014:10:45 AM, at 10:45 AM, Andy Bierman = <andy@yumaworks.com> wrote:=

 

Hi,

 

I think the interim did not need to be cancelled. Th= ere are ACL, SYSLOG,

and YANG Mount topics. I was going to call in for th= ose, not OSPF.

But I have been saying (for over a year now) that it= is time to move

domain-specific data models into the domain-specific= WGs.

I think NETMOD WG should focus on the YANG language = and

infrastructure modules.

 

Andy

 

 

On Wed, Oct 22, 2014 at 7:35 AM, Thomas D. Nadeau &l= t;tnadeau@luci= dvision.com> wrote:

 

No one said that OSPF experts could not attend to pr= ovide input.   The issue is that OSPF was not doing this. If they want= to take over doing all OSPF models, then great, but to date no one was.&nb= sp; The agreement in NETMOD (and our charter) is to facilitate the creation of models when WGs don’t want to do th= em, have the expertise to do them, etc…  Also, getting the right= Yang experts in one place is not going to happen for every WG in the IETF;= its just not realistic.  I understand that ultimately the WG needs to have consensus, but quick iteration to construct the model= surely can happen in a small “design team” fashion, right?

 

And in terms of today’s meeting being canceled= , really what purpose was that other than to stall/slow-down work?  Th= e group that was there to work on the OSPF model was indeed a bunch of folk= s from OSPF (Acee Lindem for example was on the call).  So now since we won’t have another interim meeting unti= l after Hawaii, so the next time this group can get together is possibly in= Hawaii, but that is probably unlikely as a large number of people are not = going to Hawaii.  So the net-net is a slowing of progress in this area.  Probably not the result the IETF community= wants.

 

—Tom

 

 

 

On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman = <andy@yumaworks.= com> wrote:

 

Hi Adrian,

 

I agree with you. The OSPF WG should be discussing O= SPF data models,

not the NETMOD WG. The domain experts need to reach = consensus

on a feature set (and maybe info model) and then get= 1 or 2 YANG experts to

help translate that to a data model. (Not the other = way around -- a room

full of YANG experts and 1 or 2 OSPF experts).<= /o:p>

 

I also prefer that virtual interim meetings be used = to discuss open issues

on chartered items, not as an additional forum to pr= omote individual drafts.

 

 

Andy

 

 

On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel <<= a href=3D"mailto:adrian@olddog.co.uk" target=3D"_blank">adrian@olddog.co.uk= > wrote:

I understand and appreciate your desire to get work = done.

The rules for IETF virtual interims are neither hard to discover, nor hard = to
comply with. The rules exist to ensure that people are included in the work= , and
I am sure that inclusion is what you want.

I find it unfortunate that you scheduled a working group meeting to discuss= only
one of a pair of competing documents on the same topic, that you didn't mak= e the
information about the meeting available to the authors of the competing doc= ument
or to the people who care about the protocol being modelled, and I find it<= br> upsetting (yes, I am actually upset) that you decided to discuss in Netmod = a
document that belongs in the OSPF working group.

If, as it surely sounds, you wish that the Netmod working group had a diffe= rent
charter to enable it to take on models for protocols that already have a ho= me in
other working groups, then I suggest you need to recharter. But I doubt tha= t
your reasoning that [YANG] experts will not go to all the other working gro= ups
will carry much weight. Frankly, and without wanting to disrespect the YANG=
experts, it is easier to understand YANG than it is to understand OSPF. If = this
were not the case then the Netmod working group would have failed in its de= sign
of YANG!

Conclusion:
You want to work on a YANG model for OSPF. Go to the OSPF working group and=
discuss it (there are already some threads). Review and comment on the comp= eting
document. Try to get agreement between all of the authors of both documents= , or
try to identify the differences. Work with the chairs of the OSPF working g= roup
to advance the work.

Adrian

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com]
> Sent: 22 October 2014 14:29
> To: Benoit Claise
> Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org;
> rtg-ads@to= ols.ietf.org
> Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled
>
>
>       This is hugely disappointing. This is the ki= nd of procedural non-sense
has
> and IS driving people away from the IETF to other places where this wo= rk is
going
> to get done. The simple effect of such silliness will be a reduction i= n speed
and
> quantity of model development.  If the goal of the IESG is to slo= w down the
> velocity of model development and creation, then this approach is perf= ect.
>
>       For the record, the interim NETMOD meeting c= adence has one meeting
> focused on Yang and the other on modeling; is not NETMOD-specific per = say, but
> to promote model creation because no other bi-weekly forum exists to d= o so. It
> is also a place to bring in non-IETF work such as the work done in ODL= , other
open
> source, or just the public community that has explicitly wanted to avo= id the
IETF.
> We have found it a convenient and fruitful place to discuss, and actua= lly
*build*
> models - regardless of their ultimate WG home.  The simple reason= : its a
single
> place for many of the experts to gather. I think you will find it very=
difficult to get
> those people onto a per-WG call every other week.
>
>       I hope the IESG considers this approach care= fully because I do not think
it
> will have the affect the larger IETF community is interested in.
>
>       --Tom
>
>
>
> > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise <bclaise@cisco.com>
wrote:
> >
> > Dear all,
> >
> > Today NETMOD interim meeting is canceled.
> >
> > I received some pushbacks from the routing ADs, on the ground tha= t:
> > 1. This interim appears to be meeting to discuss a non-WG draft f= or which
there
> is no milestone in the working group and for which there is an obvious= home
> outside the working group.
> > 2. The agenda was not announced a week in advance on the IETF ann= ounce list
> as is required
> >
> > Regards, Benoit
> >
> > _______________________________________________
> > Rtg-yang-coord mailing list
> > Rtg-= yang-coord@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtg-yang-coord
> >

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

 

 

 

 

--_000_EF64FF31F4C4384DBCE5D513A791C2B120A566CDxmbalnx11ciscoc_-- From nobody Wed Oct 22 12:23:58 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F12A51AD2DF; Wed, 22 Oct 2014 12:23: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, 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 yk0D5ysyDVcB; Wed, 22 Oct 2014 12:23:53 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 406A81AD361; Wed, 22 Oct 2014 12:23:52 -0700 (PDT) Received: from [192.168.1.123] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 5D05028D13DF; Wed, 22 Oct 2014 15:23:51 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_72ED1F21-D2E0-459D-9A38-9DC956CF68AC" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: "Thomas D. Nadeau" In-Reply-To: <05d901cfee28$cba9d040$62fd70c0$@ndzh.com> Date: Wed, 22 Oct 2014 15:23:50 -0400 Message-Id: References: <05d901cfee28$cba9d040$62fd70c0$@ndzh.com> To: Susan Hares X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/qjZaJPB5ELyXsQ7Sodepg25ffJU Cc: rtg-yang-coord@ietf.org, netmod@ietf.org Subject: Re: [netmod] [Rtg-yang-coord] interim meeting: yang model focus X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2014 19:23:56 -0000 --Apple-Mail=_72ED1F21-D2E0-459D-9A38-9DC956CF68AC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 That depends on whether or not it offends the Routing Area ADs. =E2=80=94Tom > On Oct 22, 2014:2:48 PM, at 2:48 PM, Susan Hares = wrote: >=20 > Tom:=20 > =20 > I have an I2RS related SFC yang model (state and policy) to discuss as = well. May this get added to the next interim if time allows.=20 > =20 > Sue=20 > =20 > From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org = ] On Behalf Of rapenno > Sent: Tuesday, October 21, 2014 7:32 PM > To: tnadeau@lucidvision.com ; = netmod@ietf.org ; rtg-yang-coord@ietf.org = > Subject: Re: [Rtg-yang-coord] [netmod] interim meeting: yang model = focus > =20 > I would like to discuss SFC yang modelnif time permits > =20 > =20 > Sent from Samsung Mobile >=20 >=20 >=20 > -------- Original message -------- > From: "Thomas D. Nadeau" >=20 > Date:=20 > To: NETMOD Working Group >,rtg-yang-coord@ietf.org = =20 > Subject: [netmod] interim meeting: yang model focus=20 >=20 >=20 > [adding rtg-yang-coord] >=20 >=20 > Tomorrow's meeting will use the same WebEx from last time (and the = same as was used last week at the Yang 1.1-focused meeting).=20 >=20 > Tomorrow's interim meeting has the following preliminary agenda: >=20 > 0) Quickly how to use IRC/sign-in > 1) Note Well > 2) Agenda Bashing > 3) OSPF Model - Kiran Agrahara Sreenivasa >; myeung@cisco.com = >=20 >=20 > Are there any other models people wish to discuss? >=20 > --Tom >=20 >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod = --Apple-Mail=_72ED1F21-D2E0-459D-9A38-9DC956CF68AC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

That = depends on whether or not it offends the Routing Area ADs.

= =E2=80=94Tom


On Oct 22, 2014:2:48 PM, at 2:48 PM, Susan Hares <shares@ndzh.com> = wrote:

Tom: 
 
I have an I2RS related = SFC yang model (state and policy) to discuss as well.  May this get = added to the next interim if time allows. 
 
Sue 
 
From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf = Of rapenno
Sent: Tuesday, October 21, 2014 = 7:32 PM
To: tnadeau@lucidvision.com; netmod@ietf.org; rtg-yang-coord@ietf.org
Subject: Re: [Rtg-yang-coord] = [netmod] interim meeting: yang model focus
 
I would like to = discuss SFC yang modelnif time permits
 
 
Sent from Samsung Mobile



-------- = Original message --------
From: "Thomas D. Nadeau" <tnadeau@lucidvision.com> 
Date: 
To: NETMOD = Working Group <netmod@ietf.org>,rtg-yang-coord@ietf.org 
Subject: = [netmod] interim meeting: yang model focus 


[adding  rtg-yang-coord]


Tomorrow's meeting will use the same WebEx = from last time (and the same as was used last week at the Yang = 1.1-focused meeting). 

Tomorrow's interim meeting has the following preliminary = agenda:

0) Quickly how to use = IRC/sign-in
1) Note Well
2) Agenda = Bashing
3) OSPF Model - Kiran Agrahara Sreenivasa <kkoushik@Brocade.com>; myeung@cisco.com


Are there any other models = people wish to discuss?

--Tom



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

= --Apple-Mail=_72ED1F21-D2E0-459D-9A38-9DC956CF68AC-- From nobody Wed Oct 22 12:25:22 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA3161AD376; Wed, 22 Oct 2014 12:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oS-NLwgUvEn; Wed, 22 Oct 2014 12:25:02 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 605AE1AD2DF; Wed, 22 Oct 2014 12:25:02 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Eric Voit \(evoit\)'" , "'Thomas D. Nadeau'" , "'Andy Bierman'" References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> <061201cfee29$d87b9000$8972b000$@ndzh.com> In-Reply-To: Date: Wed, 22 Oct 2014 15:24:55 -0400 Message-ID: <06c301cfee2d$dd3e9980$97bbcc80$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_06C4_01CFEE0C.56347390" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIUX+ca9u4QKYuEX+hUMOEGGRuotgIuz+VeAfQkGdcB/lG70gLMEl+3Ae5R6RAAvWtNfQFaI9SwAhiAM4ICGsuFupsqZ37Q Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/_Kis1SQ0Ai_euo-y-iXJ8dEodwI Cc: Rtg-yang-coord@ietf.org, 'NETMOD Working Group' , ospf-chairs@tools.ietf.org, ops-ads@tools.ietf.org, rtg-ads@tools.ietf.org, 'Farrel Adrian' Subject: Re: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2014 19:25:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_06C4_01CFEE0C.56347390 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Very helpful slides. Will this be reschedule to November 5th? Sue From: Eric Voit (evoit) [mailto:evoit@cisco.com] Sent: Wednesday, October 22, 2014 3:13 PM To: Susan Hares; 'Thomas D. Nadeau'; 'Andy Bierman' Cc: Rtg-yang-coord@ietf.org; 'NETMOD Working Group'; ospf-chairs@tools.ietf.org; ops-ads@tools.ietf.org; rtg-ads@tools.ietf.org; 'Farrel Adrian' Subject: RE: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled Two weeks ago at the Netmod Interim, we discussed: http://datatracker.ietf.org/doc/draft-voit-netmod-peer-mount-requirements/ http://datatracker.ietf.org/doc/draft-clemm-netmod-mount/ We used these slides to introduce the topics. On the Netmod interim agenda today was to be a recap/summary of the resulting mailing list discussions, as well the teeing up of exactly what could be on the plate for Hawaii Netmod face-to-face. Thanks, Eric From: Susan Hares, October 22, 2014 2:56 PM Eric: What were the OpenDaylight topics for the call? Sue From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of Eric Voit (evoit) Sent: Wednesday, October 22, 2014 11:20 AM To: Thomas D. Nadeau; Andy Bierman Cc: Rtg-yang-coord@ietf.org; NETMOD Working Group; ospf-chairs@tools.ietf.org; ops-ads@tools.ietf.org; rtg-ads@tools.ietf.org; Farrel Adrian Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled As Tom and others note, today's Netmod interim was to have topics beyond OSPF. These included OpenDaylight related work. The IETF should be encouraging venues for Open Source developer audiences. Cancelling full meetings via IETF procedural mechanisms signals the opposite. I *like* the idea of each WG being the owner for their domain models. This scales well for the reasons pointed out below. And I do have sympathy for a WG wanting to close on a definitive answer for a YANG model before implications are discussed elsewhere. But I am worried that we are enforcing an overly serial process. Or of constraining communication. The market will work around this. In the controller space, YANG technology is not static. Some degree of parallelism is needed across IETF WGs. Clueful Open Source/YANG developers cannot extend themselves across all WG where YANG modeling might occur. Eric From: Thomas D. Nadeau, October 22, 2014 10:52 AM We are trying. The thing is that you cannot just hoist that onto WGs and say "here you go." if they don't want to do it. Again, the Netmod charter was specifically modified to accommodate that case. And while some WGs in the routing area are not enthusiastic about building models, others aren't, nor are other WGs at the IETF. So for those, what do you do? Ignore them? The other point is that others outside of the IETF are working on these models. It is squarely within the IETF community's interest to bring these back into the fold. Many of these folks are skittish about coming to the IETF altogether so we've tried to encourage them to participate in this way. If we want to push these folks away with procedural reasons, then we have made our bed... -tom On Oct 22, 2014:10:45 AM, at 10:45 AM, Andy Bierman wrote: Hi, I think the interim did not need to be cancelled. There are ACL, SYSLOG, and YANG Mount topics. I was going to call in for those, not OSPF. But I have been saying (for over a year now) that it is time to move domain-specific data models into the domain-specific WGs. I think NETMOD WG should focus on the YANG language and infrastructure modules. Andy On Wed, Oct 22, 2014 at 7:35 AM, Thomas D. Nadeau wrote: No one said that OSPF experts could not attend to provide input. The issue is that OSPF was not doing this. If they want to take over doing all OSPF models, then great, but to date no one was. The agreement in NETMOD (and our charter) is to facilitate the creation of models when WGs don't want to do them, have the expertise to do them, etc. Also, getting the right Yang experts in one place is not going to happen for every WG in the IETF; its just not realistic. I understand that ultimately the WG needs to have consensus, but quick iteration to construct the model surely can happen in a small "design team" fashion, right? And in terms of today's meeting being canceled, really what purpose was that other than to stall/slow-down work? The group that was there to work on the OSPF model was indeed a bunch of folks from OSPF (Acee Lindem for example was on the call). So now since we won't have another interim meeting until after Hawaii, so the next time this group can get together is possibly in Hawaii, but that is probably unlikely as a large number of people are not going to Hawaii. So the net-net is a slowing of progress in this area. Probably not the result the IETF community wants. -Tom On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman wrote: Hi Adrian, I agree with you. The OSPF WG should be discussing OSPF data models, not the NETMOD WG. The domain experts need to reach consensus on a feature set (and maybe info model) and then get 1 or 2 YANG experts to help translate that to a data model. (Not the other way around -- a room full of YANG experts and 1 or 2 OSPF experts). I also prefer that virtual interim meetings be used to discuss open issues on chartered items, not as an additional forum to promote individual drafts. Andy On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel wrote: I understand and appreciate your desire to get work done. The rules for IETF virtual interims are neither hard to discover, nor hard to comply with. The rules exist to ensure that people are included in the work, and I am sure that inclusion is what you want. I find it unfortunate that you scheduled a working group meeting to discuss only one of a pair of competing documents on the same topic, that you didn't make the information about the meeting available to the authors of the competing document or to the people who care about the protocol being modelled, and I find it upsetting (yes, I am actually upset) that you decided to discuss in Netmod a document that belongs in the OSPF working group. If, as it surely sounds, you wish that the Netmod working group had a different charter to enable it to take on models for protocols that already have a home in other working groups, then I suggest you need to recharter. But I doubt that your reasoning that [YANG] experts will not go to all the other working groups will carry much weight. Frankly, and without wanting to disrespect the YANG experts, it is easier to understand YANG than it is to understand OSPF. If this were not the case then the Netmod working group would have failed in its design of YANG! Conclusion: You want to work on a YANG model for OSPF. Go to the OSPF working group and discuss it (there are already some threads). Review and comment on the competing document. Try to get agreement between all of the authors of both documents, or try to identify the differences. Work with the chairs of the OSPF working group to advance the work. Adrian > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com] > Sent: 22 October 2014 14:29 > To: Benoit Claise > Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org; > rtg-ads@tools.ietf.org > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled > > > This is hugely disappointing. This is the kind of procedural non-sense has > and IS driving people away from the IETF to other places where this work is going > to get done. The simple effect of such silliness will be a reduction in speed and > quantity of model development. If the goal of the IESG is to slow down the > velocity of model development and creation, then this approach is perfect. > > For the record, the interim NETMOD meeting cadence has one meeting > focused on Yang and the other on modeling; is not NETMOD-specific per say, but > to promote model creation because no other bi-weekly forum exists to do so. It > is also a place to bring in non-IETF work such as the work done in ODL, other open > source, or just the public community that has explicitly wanted to avoid the IETF. > We have found it a convenient and fruitful place to discuss, and actually *build* > models - regardless of their ultimate WG home. The simple reason: its a single > place for many of the experts to gather. I think you will find it very difficult to get > those people onto a per-WG call every other week. > > I hope the IESG considers this approach carefully because I do not think it > will have the affect the larger IETF community is interested in. > > --Tom > > > > > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise wrote: > > > > Dear all, > > > > Today NETMOD interim meeting is canceled. > > > > I received some pushbacks from the routing ADs, on the ground that: > > 1. This interim appears to be meeting to discuss a non-WG draft for which there > is no milestone in the working group and for which there is an obvious home > outside the working group. > > 2. The agenda was not announced a week in advance on the IETF announce list > as is required > > > > Regards, Benoit > > > > _______________________________________________ > > Rtg-yang-coord mailing list > > Rtg-yang-coord@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ------=_NextPart_000_06C4_01CFEE0C.56347390 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Very helpful slides.  Will this be reschedule to November = 5th?

 

Sue

 

From:= = Eric Voit (evoit) [mailto:evoit@cisco.com]
Sent: Wednesday, = October 22, 2014 3:13 PM
To: Susan Hares; 'Thomas D. Nadeau'; = 'Andy Bierman'
Cc: Rtg-yang-coord@ietf.org; 'NETMOD Working = Group'; ospf-chairs@tools.ietf.org; ops-ads@tools.ietf.org; = rtg-ads@tools.ietf.org; 'Farrel Adrian'
Subject: RE: = [Rtg-yang-coord] [netmod] NETMOD interim meeting = canceled

 

Two weeks ago at the Netmod Interim, we = discussed:

  http://datatracker.ietf.org/doc/draft-voit-netmod-peer-mount-r= equirements/

  http:/= /datatracker.ietf.org/doc/draft-clemm-netmod-mount/ =

We used these = slides to introduce the topics.  

 

On the Netmod interim agenda today was to be a recap/summary of the = resulting mailing list discussions, as well the teeing up of exactly = what could be on the plate for Hawaii Netmod = face-to-face.

 

Thanks,

Eric

 

 

From:= = Susan Hares, October 22, 2014 2:56 PM

Eric:

 

What were the OpenDaylight topics for the call?  =

 

Sue

 

From:= = Rtg-yang-coord [mailto:rtg-yang-coord-bou= nces@ietf.org] On Behalf Of Eric Voit (evoit)
Sent: = Wednesday, October 22, 2014 11:20 AM
To: Thomas D. Nadeau; = Andy Bierman
Cc: Rtg-yang-coord@ietf.org; = NETMOD Working Group; ospf-chairs@tools.ietf.org= ; ops-ads@tools.ietf.org; = rtg-ads@tools.ietf.org; = Farrel Adrian
Subject: Re: [Rtg-yang-coord] [netmod] NETMOD = interim meeting canceled

 

As Tom = and others note, today’s Netmod interim was to have topics beyond = OSPF.  These included OpenDaylight related work.   The = IETF should be encouraging venues for Open Source developer = audiences.  Cancelling full meetings via IETF procedural mechanisms = signals the opposite. 

 

I = *like* the idea of each WG being the owner for their domain = models.  This scales well for the reasons  pointed out = below.  And I do have sympathy for a WG wanting to close on a = definitive answer for a YANG model before implications are discussed = elsewhere.   But I am worried that we are enforcing an overly = serial process.  Or of constraining communication.  The market = will work around this.  

 

In the = controller space, YANG technology is not static.  Some degree of = parallelism is needed across IETF WGs.  Clueful Open Source/YANG = developers cannot extend themselves across all WG where YANG modeling = might occur.

 

Eric

 

 

From:= = Thomas D. Nadeau, October 22, 2014 10:52 AM

        &n= bsp; We are trying. The thing is that you cannot just hoist that = onto WGs and say “here you go.” if they don’t want to = do it.  Again, the Netmod charter was specifically modified to = accommodate that case.   And while some WGs in the routing area are = not enthusiastic about building models, others aren’t, nor are = other WGs at the IETF. So for those, what do you do? Ignore them? The = other point is that others outside of the IETF are working on these = models.  It is squarely within the IETF community’s interest = to bring these back into the fold.  Many of these folks are = skittish about coming to the IETF altogether so we’ve tried to = encourage them to participate in this way. If we want to push these = folks away with procedural reasons, then we have made our = bed...

 

        &n= bsp; —tom

 

 

 

On Oct 22, 2014:10:45 AM, at 10:45 AM, Andy Bierman = <andy@yumaworks.com> = wrote:

 

Hi,

 

I = think the interim did not need to be cancelled. There are ACL, = SYSLOG,

and YANG Mount = topics. I was going to call in for those, not = OSPF.

But I have been = saying (for over a year now) that it is time to = move

domain-specific data = models into the domain-specific WGs.

I think NETMOD WG should focus on the YANG language = and

infrastructure = modules.

 

Andy

 

 

On Wed, = Oct 22, 2014 at 7:35 AM, Thomas D. Nadeau <tnadeau@lucidvision.com> = wrote:

 

No one = said that OSPF experts could not attend to provide input.   The = issue is that OSPF was not doing this. If they want to take over doing = all OSPF models, then great, but to date no one was.  The agreement = in NETMOD (and our charter) is to facilitate the creation of models when = WGs don’t want to do them, have the expertise to do them, = etc…  Also, getting the right Yang experts in one place is = not going to happen for every WG in the IETF; its just not = realistic.  I understand that ultimately the WG needs to have = consensus, but quick iteration to construct the model surely can happen = in a small “design team” fashion, = right?

 

And in terms of today’s meeting being canceled, = really what purpose was that other than to stall/slow-down work?  = The group that was there to work on the OSPF model was indeed a bunch of = folks from OSPF (Acee Lindem for example was on the call).  So now = since we won’t have another interim meeting until after Hawaii, so = the next time this group can get together is possibly in Hawaii, but = that is probably unlikely as a large number of people are not going to = Hawaii.  So the net-net is a slowing of progress in this = area.  Probably not the result the IETF community = wants.

 

—Tom

 

 

 

On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman = <andy@yumaworks.com> = wrote:

 

Hi = Adrian,

 

I = agree with you. The OSPF WG should be discussing OSPF data = models,

not the NETMOD WG. = The domain experts need to reach consensus

on a feature set (and maybe info model) and then get 1 = or 2 YANG experts to

help = translate that to a data model. (Not the other way around -- a = room

full of YANG experts = and 1 or 2 OSPF experts).

 

I = also prefer that virtual interim meetings be used to discuss open = issues

on chartered items, = not as an additional forum to promote individual = drafts.

 

 

Andy

 

 

On Wed, = Oct 22, 2014 at 6:48 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:

I understand and appreciate your desire to get work = done.

The rules for IETF virtual interims are neither hard to = discover, nor hard to
comply with. The rules exist to ensure that = people are included in the work, and
I am sure that inclusion is what = you want.

I find it unfortunate that you scheduled a working = group meeting to discuss only
one of a pair of competing documents on = the same topic, that you didn't make the
information about the = meeting available to the authors of the competing document
or to the = people who care about the protocol being modelled, and I find = it
upsetting (yes, I am actually upset) that you decided to discuss = in Netmod a
document that belongs in the OSPF working = group.

If, as it surely sounds, you wish that the Netmod working = group had a different
charter to enable it to take on models for = protocols that already have a home in
other working groups, then I = suggest you need to recharter. But I doubt that
your reasoning that = [YANG] experts will not go to all the other working groups
will carry = much weight. Frankly, and without wanting to disrespect the = YANG
experts, it is easier to understand YANG than it is to = understand OSPF. If this
were not the case then the Netmod working = group would have failed in its design
of = YANG!

Conclusion:
You want to work on a YANG model for OSPF. = Go to the OSPF working group and
discuss it (there are already some = threads). Review and comment on the competing
document. Try to get = agreement between all of the authors of both documents, or
try to = identify the differences. Work with the chairs of the OSPF working = group
to advance the work.

Adrian

> -----Original = Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com]
> Sent: 22 October = 2014 14:29
> To: Benoit Claise
> Cc: NETMOD Working Group; = Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org;
> rtg-ads@tools.ietf.org
> Subject: Re: = [Rtg-yang-coord] NETMOD interim meeting = canceled
>
>
>       This is = hugely disappointing. This is the kind of procedural = non-sense
has
> and IS driving people away from the IETF to = other places where this work is
going
> to get done. The simple = effect of such silliness will be a reduction in speed
and
> = quantity of model development.  If the goal of the IESG is to slow = down the
> velocity of model development and creation, then this = approach is perfect.
>
>       For the = record, the interim NETMOD meeting cadence has one meeting
> = focused on Yang and the other on modeling; is not NETMOD-specific per = say, but
> to promote model creation because no other bi-weekly = forum exists to do so. It
> is also a place to bring in non-IETF = work such as the work done in ODL, other
open
> source, or just = the public community that has explicitly wanted to avoid = the
IETF.
> We have found it a convenient and fruitful place to = discuss, and actually
*build*
> models - regardless of their = ultimate WG home.  The simple reason: its a
single
> place = for many of the experts to gather. I think you will find it = very
difficult to get
> those people onto a per-WG call every = other week.
>
>       I hope the IESG = considers this approach carefully because I do not think
it
> = will have the affect the larger IETF community is interested = in.
>
>      =  --Tom
>
>
>
> > On Oct 22, 2014:9:16 = AM, at 9:16 AM, Benoit Claise <bclaise@cisco.com>
wrote:
> = >
> > Dear all,
> >
> > Today NETMOD = interim meeting is canceled.
> >
> > I received some = pushbacks from the routing ADs, on the ground that:
> > 1. This = interim appears to be meeting to discuss a non-WG draft for = which
there
> is no milestone in the working group and for = which there is an obvious home
> outside the working = group.
> > 2. The agenda was not announced a week in advance on = the IETF announce list
> as is required
> >
> > = Regards, Benoit
> >
> > = _______________________________________________
> > = Rtg-yang-coord mailing list
> > Rtg-yang-coord@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtg-yang-coord
> = >

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

 

 

 

 

------=_NextPart_000_06C4_01CFEE0C.56347390-- From nobody Wed Oct 22 12:28:18 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECA61AD391; Wed, 22 Oct 2014 12:28:14 -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 9_7kOSYc9j_U; Wed, 22 Oct 2014 12:28:11 -0700 (PDT) Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C1C91AD372; Wed, 22 Oct 2014 12:28:10 -0700 (PDT) Received: by mail-yh0-f44.google.com with SMTP id i57so4073210yha.17 for ; Wed, 22 Oct 2014 12:28:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TVwdd0Mq5W+tn5I4qgvlbYmrlHbGlHgsg1gmGvN9dwY=; b=XlQR7KW2ixy0/3MoEYxcPIcIb6sB/CQaC+ysf5aD4rQQoFwNJbr0KV9p7aVHSL/Cj+ mnPDz54K8t1qoKGXE8M2/ervfgASe2aaN5UUVd2A4XsKeZPvW4NBUVwbIx71nFZL5OqX yTzZvdgrjjbd5qQe5V/SCe6DJGzUqFo2LM4XTGg8Rqwoy91iudXA9q7Qx2pbvXpadZo4 gzTfyW2XIEenaIAPDwPBVtB+nm99QLH9I7bz8PgUJ52UUKI0P6+AXwgNvSx7BnlQY/aB qQdCLghNn7QL6vWo1rRYkpCobKnAMFF/HyLBVZJAoQHwH0rw7VVfAGwKnymX+TWYq0G6 oW3w== MIME-Version: 1.0 X-Received: by 10.236.223.198 with SMTP id v66mr347436yhp.38.1414006089692; Wed, 22 Oct 2014 12:28:09 -0700 (PDT) Received: by 10.170.113.132 with HTTP; Wed, 22 Oct 2014 12:28:09 -0700 (PDT) In-Reply-To: References: <05d901cfee28$cba9d040$62fd70c0$@ndzh.com> Date: Wed, 22 Oct 2014 15:28:09 -0400 Message-ID: From: Alia Atlas To: "Thomas D. Nadeau" , "sfc-chairs@tools.ietf.org" Content-Type: multipart/alternative; boundary=001a11c1e9eeafbb7a050607f2fa Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/kGCD1cKfAiI43wXaAy33cXx6a_I Cc: rtg-yang-coord@ietf.org, "netmod@ietf.org" , Susan Hares Subject: Re: [netmod] [Rtg-yang-coord] interim meeting: yang model focus X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2014 19:28:14 -0000 --001a11c1e9eeafbb7a050607f2fa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Tom, Coordinate with the SFC chairs so that they know it is happening. Have a clear agenda sent out a week ahead of time so that SFC participants can call in. Have fun, Alia On Wed, Oct 22, 2014 at 3:23 PM, Thomas D. Nadeau wrote: > > That depends on whether or not it offends the Routing Area ADs. > > =E2=80=94Tom > > > On Oct 22, 2014:2:48 PM, at 2:48 PM, Susan Hares wrote: > > Tom: > > I have an I2RS related SFC yang model (state and policy) to discuss as > well. May this get added to the next interim if time allows. > > Sue > > *From:* Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org > ] *On Behalf Of *rapenno > *Sent:* Tuesday, October 21, 2014 7:32 PM > *To:* tnadeau@lucidvision.com; netmod@ietf.org; rtg-yang-coord@ietf.org > *Subject:* Re: [Rtg-yang-coord] [netmod] interim meeting: yang model focu= s > > I would like to discuss SFC yang modelnif time permits > > > Sent from Samsung Mobile > > > > -------- Original message -------- > From: "Thomas D. Nadeau" > Date: > To: NETMOD Working Group ,rtg-yang-coord@ietf.org > Subject: [netmod] interim meeting: yang model focus > > > [adding rtg-yang-coord] > > > Tomorrow's meeting will use the same WebEx from last time (and the same a= s > was used last week at the Yang 1.1-focused meeting). > > Tomorrow's interim meeting has the following preliminary agenda: > > 0) Quickly how to use IRC/sign-in > 1) Note Well > 2) Agenda Bashing > 3) OSPF Model - Kiran Agrahara Sreenivasa ; > myeung@cisco.com > > > Are there any other models people wish to discuss? > > --Tom > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > --001a11c1e9eeafbb7a050607f2fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Tom,

Coordinate with the SFC chairs so = that they know it is happening.
Have a clear agenda sent out a we= ek ahead of time so that SFC participants
can call in.
=
Have fun,
Alia

On Wed, Oct 22, 2014 at 3:23 PM, Thomas D= . Nadeau <tnadeau@lucidvision.com> wrote:

That depends on whether or not i= t offends the Routing Area ADs.

=E2=80=94Tom


On Oct 22, 2014:2:48 PM, at = 2:48 PM, Susan Hares <shares@ndzh.com> wrote:

Tom:=C2=A0
=C2=A0
I= have an I2RS related SFC yang model (state and policy) to discuss as well.= =C2=A0 May this get added to the next interim if time allows.=C2=A0
=C2=A0
Sue=C2=A0<= /span>
=C2=A0
From:=C2=A0Rtg-= yang-coord [mailto:rtg-yang-coor= d-bounces@ietf.org]=C2=A0On Behalf Of=C2=A0rapenno
Sent:=C2=A0Tuesday, October 21, 2014 7:= 32 PM
To:=C2=A0tn= adeau@lucidvision.com;=C2=A0net= mod@ietf.org;=C2=A0rtg-= yang-coord@ietf.org
Subject:=C2=A0Re: [Rtg-yang-= coord] [netmod] interim meeting: yang model focus
=C2=A0
I would like to discuss SFC yang modelnif time permits<= u>
=C2=A0
=C2=A0
=
Sent from Samsung Mobile



-------- Original message --------
From:= "Thomas D. Nadeau" <tnadea= u@lucidvision.com>=C2=A0
Date:=C2=A0To: NETMOD Working Group <netmod@ietf.org>,rtg-yang-coord@ietf.org= =C2=A0
Subject: [netmod] interim meeting: yang model focus= =C2=A0


[adding=C2=A0 rtg-yang-coord]


Tomorrow&= #39;s meeting will use the same WebEx from last time (and the same as was u= sed last week at the Yang 1.1-focused meeting).=C2=A0

T= omorrow's interim meeting has the following preliminary agenda:

= 0) Quickly how to use IRC/sign-in
1) Note Well
2) Agenda Bashing
3= ) OSPF Model - Kiran Agrahara Sreenivasa <kkoushik@Brocade.com>;=C2=A0myeung@cisco.com


Are there any other models people wish t= o discuss?

--Tom



____________________________________= ___________
netmod mailing list
netmod@iet= f.org
https://www.i= etf.org/mailman/listinfo/netmod

______________________________________________= _
Rtg-yang-coord mailing list
Rtg-yang-coord@ietf.org
https://www.ietf.org/mailman/listinfo/rtg-yang-coord


--001a11c1e9eeafbb7a050607f2fa-- From nobody Wed Oct 22 14:09:12 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E641A1B3B; Wed, 22 Oct 2014 14:09:06 -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 w7XEZaACv7RT; Wed, 22 Oct 2014 14:09:01 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0672C1A1B38; Wed, 22 Oct 2014 14:09:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34199; q=dns/txt; s=iport; t=1414012141; x=1415221741; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=NR5Dvy614Y3X+PcegquSss4srCSPpd4byj//NGTlNvY=; b=B26KQcPKk8VoVWs8+YPHb5L6yKZBJ93Y2k6ngIVW/ZXa9QTu2Yp7pWfx jP9KrU5/evRewk42aFf61QnPnNG3iVPlhh5gE0JW5RKSkJfkVf0P7b0vb bDuh7xioE8yzJRPg9YCaXTv3+FRnVuY1YTZsEZEIbqpDSNjd8iqu3TaJh Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAHkcSFStJA2K/2dsb2JhbABSCoJIRlRYzFYBCYZ5VAKBDxYBfYQCAQEBAwEBAQEqPgMLBQcECw4DBAEBAQkXAQYHDwIWHwkIBgEMAQUCAQEQC4gZCA3FbwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEilaFJVwGAQaERQWLY5F6gTGGO4o9hAGEGB0vgQYEgUEBAQE X-IronPort-AV: E=Sophos; i="5.04,771,1406592000"; d="scan'208,217"; a="89458637" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-3.cisco.com with ESMTP; 22 Oct 2014 21:08:58 +0000 Received: from [10.154.182.28] ([10.154.182.28]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s9ML8uAU018908; Wed, 22 Oct 2014 21:08:56 GMT Message-ID: <54481CE8.808@cisco.com> Date: Wed, 22 Oct 2014 14:08:56 -0700 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Susan Hares , "'Thomas D. Nadeau'" , "'Andy Bierman'" References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> <057901cfee26$754ecc20$5fec6460$@ndzh.com> In-Reply-To: <057901cfee26$754ecc20$5fec6460$@ndzh.com> Content-Type: multipart/alternative; boundary="------------080204070205080802080900" Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/AJOX3cQxrBZ8uiNWV2kzkB2H99Q Cc: Rtg-yang-coord@ietf.org, 'NETMOD Working Group' , ospf-chairs@tools.ietf.org, ops-ads@tools.ietf.org, rtg-ads@tools.ietf.org, 'Farrel Adrian' Subject: Re: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2014 21:09:07 -0000 This is a multi-part message in MIME format. --------------080204070205080802080900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, > > Tom: > > Acee indicated earlier on the i2rs list (September discussion) that > the OSPF yang model was going to be standardized in OSPF. I'm glad > we've got the rtg-yang-coord list to sort out these issues. > > IDR will pick up all BGP related yang modules. A charter addition has > been made. IDR will gladly accept input from the netmod WG or hold > joint interim session to make this effort go fast. > Exactly. The YANG modules should be standardized in the respective WGs. To have good YANG modules, you need: 1. the technology experts, i.e. the respective WG 2. YANG review I don't understand all this fuss about: "oh, but you can't speak about an OSPF module in a NETMOD WG". We want to do what's right by providing YANG review of the documents, nothing else. I don't understand all this fuss about: "oh, but if you speak about one OSPF YANG model, then you must include all the other ones". People who want feedback on their YANG modules are welcome to join. This was the goal. Regards, Benoit > The configuration drafts for bgp > (draft-zhdankin-netmod-bgp-cfg-00.txt) and the I2rs drafts for bgp > (draft-i2rs-hares-bgp-dm-00) have only a 5% functional overlap. I > will be releasing a draft that compares these two drafts, and looks at > how these drafts fulfill the I2RS BGP use case requirements. > > IDR will sponsor a design team in IDR to push the rapid development of > bgp configuration or bgp i2rs. If you could suggest a few netmod > people to help this effort it would help. > > My understanding of IETF best practices indicate that joint interims > need 2 weeks announcement of topics. > > Sue > > *From:*Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] *On > Behalf Of *Thomas D. Nadeau > *Sent:* Wednesday, October 22, 2014 10:35 AM > *To:* Andy Bierman > *Cc:* Rtg-yang-coord@ietf.org; NETMOD Working Group; > ospf-chairs@tools.ietf.org; ops-ads@tools.ietf.org; > rtg-ads@tools.ietf.org; Benoit Claise; Farrel Adrian > *Subject:* Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled > > No one said that OSPF experts could not attend to provide input. The > issue is that OSPF was not doing this. If they want to take over doing > all OSPF models, then great, but to date no one was. The agreement in > NETMOD (and our charter) is to facilitate the creation of models when > WGs don't want to do them, have the expertise to do them, etc... > Also, getting the right Yang experts in one place is not going to > happen for every WG in the IETF; its just not realistic. I understand > that ultimately the WG needs to have consensus, but quick iteration to > construct the model surely can happen in a small "design team" > fashion, right? > > And in terms of today's meeting being canceled, really what purpose > was that other than to stall/slow-down work? The group that was there > to work on the OSPF model was indeed a bunch of folks from OSPF (Acee > Lindem for example was on the call). So now since we won't have > another interim meeting until after Hawaii, so the next time this > group can get together is possibly in Hawaii, but that is probably > unlikely as a large number of people are not going to Hawaii. So the > net-net is a slowing of progress in this area. Probably not the > result the IETF community wants. > > ---Tom > > On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman > > wrote: > > Hi Adrian, > > I agree with you. The OSPF WG should be discussing OSPF data models, > > not the NETMOD WG. The domain experts need to reach consensus > > on a feature set (and maybe info model) and then get 1 or 2 YANG > experts to > > help translate that to a data model. (Not the other way around -- > a room > > full of YANG experts and 1 or 2 OSPF experts). > > I also prefer that virtual interim meetings be used to discuss > open issues > > on chartered items, not as an additional forum to promote > individual drafts. > > Andy > > On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel > > wrote: > > I understand and appreciate your desire to get work done. > > The rules for IETF virtual interims are neither hard to discover, > nor hard to > comply with. The rules exist to ensure that people are included in > the work, and > I am sure that inclusion is what you want. > > I find it unfortunate that you scheduled a working group meeting > to discuss only > one of a pair of competing documents on the same topic, that you > didn't make the > information about the meeting available to the authors of the > competing document > or to the people who care about the protocol being modelled, and I > find it > upsetting (yes, I am actually upset) that you decided to discuss > in Netmod a > document that belongs in the OSPF working group. > > If, as it surely sounds, you wish that the Netmod working group > had a different > charter to enable it to take on models for protocols that already > have a home in > other working groups, then I suggest you need to recharter. But I > doubt that > your reasoning that [YANG] experts will not go to all the other > working groups > will carry much weight. Frankly, and without wanting to disrespect > the YANG > experts, it is easier to understand YANG than it is to understand > OSPF. If this > were not the case then the Netmod working group would have failed > in its design > of YANG! > > Conclusion: > You want to work on a YANG model for OSPF. Go to the OSPF working > group and > discuss it (there are already some threads). Review and comment on > the competing > document. Try to get agreement between all of the authors of both > documents, or > try to identify the differences. Work with the chairs of the OSPF > working group > to advance the work. > > Adrian > > > -----Original Message----- > > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com > ] > > Sent: 22 October 2014 14:29 > > To: Benoit Claise > > Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org > ; ops-ads@tools.ietf.org > ; > > rtg-ads@tools.ietf.org > > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled > > > > > > This is hugely disappointing. This is the kind of > procedural non-sense > has > > and IS driving people away from the IETF to other places where > this work is > going > > to get done. The simple effect of such silliness will be a > reduction in speed > and > > quantity of model development. If the goal of the IESG is to > slow down the > > velocity of model development and creation, then this approach > is perfect. > > > > For the record, the interim NETMOD meeting cadence has one > meeting > > focused on Yang and the other on modeling; is not > NETMOD-specific per say, but > > to promote model creation because no other bi-weekly forum > exists to do so. It > > is also a place to bring in non-IETF work such as the work done > in ODL, other > open > > source, or just the public community that has explicitly wanted > to avoid the > IETF. > > We have found it a convenient and fruitful place to discuss, and > actually > *build* > > models - regardless of their ultimate WG home. The simple > reason: its a > single > > place for many of the experts to gather. I think you will find > it very > difficult to get > > those people onto a per-WG call every other week. > > > > I hope the IESG considers this approach carefully because > I do not think > it > > will have the affect the larger IETF community is interested in. > > > > --Tom > > > > > > > > > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise > > > wrote: > > > > > > Dear all, > > > > > > Today NETMOD interim meeting is canceled. > > > > > > I received some pushbacks from the routing ADs, on the ground > that: > > > 1. This interim appears to be meeting to discuss a non-WG > draft for which > there > > is no milestone in the working group and for which there is an > obvious home > > outside the working group. > > > 2. The agenda was not announced a week in advance on the IETF > announce list > > as is required > > > > > > Regards, Benoit > > > > > > _______________________________________________ > > > Rtg-yang-coord mailing list > > > Rtg-yang-coord@ietf.org > > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --------------080204070205080802080900 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear all,

Tom:

 

Acee indicated earlier on the i2rs list (September discussion) that the OSPF yang model was going to be standardized in OSPF.  I’m glad we’ve got the rtg-yang-coord list to sort out these issues.

 

IDR will pick up all BGP related yang modules.  A charter addition has been made.  IDR will gladly accept input from the netmod WG or hold joint interim session to make this effort go fast. 

Exactly. The YANG modules should be standardized in the respective WGs.
To have good YANG modules, you need:
1. the technology experts, i.e. the respective WG
2. YANG review

I don't understand all this fuss about: "oh, but you can't speak about an OSPF module in a NETMOD WG".
We want to do what's right by providing YANG review of the documents, nothing else.

I don't understand all this fuss about: "oh, but if you speak about one OSPF YANG model, then you must include all the other ones".
People who want feedback on their YANG modules are welcome to join. This was the goal.

Regards, Benoit

The configuration drafts for bgp (draft-zhdankin-netmod-bgp-cfg-00.txt) and the I2rs drafts for bgp (draft-i2rs-hares-bgp-dm-00) have only a 5% functional overlap.  I will be releasing a draft that compares these two drafts, and looks at how these drafts fulfill the I2RS BGP use case requirements.

 

IDR will sponsor a design team in IDR to push the rapid development of bgp configuration or bgp i2rs.  If you could suggest a few netmod people to help this effort it would help.  

 

My understanding of IETF best practices indicate that joint interims need 2 weeks announcement of topics.

 

Sue

 

From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of Thomas D. Nadeau
Sent: Wednesday, October 22, 2014 10:35 AM
To: Andy Bierman
Cc: Rtg-yang-coord@ietf.org; NETMOD Working Group; ospf-chairs@tools.ietf.org; ops-ads@tools.ietf.org; rtg-ads@tools.ietf.org; Benoit Claise; Farrel Adrian
Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled

 

 

            No one said that OSPF experts could not attend to provide input.   The issue is that OSPF was not doing this. If they want to take over doing all OSPF models, then great, but to date no one was.  The agreement in NETMOD (and our charter) is to facilitate the creation of models when WGs don’t want to do them, have the expertise to do them, etc…  Also, getting the right Yang experts in one place is not going to happen for every WG in the IETF; its just not realistic.  I understand that ultimately the WG needs to have consensus, but quick iteration to construct the model surely can happen in a small “design team” fashion, right?

 

            And in terms of today’s meeting being canceled, really what purpose was that other than to stall/slow-down work?  The group that was there to work on the OSPF model was indeed a bunch of folks from OSPF (Acee Lindem for example was on the call).  So now since we won’t have another interim meeting until after Hawaii, so the next time this group can get together is possibly in Hawaii, but that is probably unlikely as a large number of people are not going to Hawaii.  So the net-net is a slowing of progress in this area.  Probably not the result the IETF community wants.

 

            —Tom

 

 

 

On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman <andy@yumaworks.com> wrote:

 

Hi Adrian,

 

I agree with you. The OSPF WG should be discussing OSPF data models,

not the NETMOD WG. The domain experts need to reach consensus

on a feature set (and maybe info model) and then get 1 or 2 YANG experts to

help translate that to a data model. (Not the other way around -- a room

full of YANG experts and 1 or 2 OSPF experts).

 

I also prefer that virtual interim meetings be used to discuss open issues

on chartered items, not as an additional forum to promote individual drafts.

 

 

Andy

 

 

On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:

I understand and appreciate your desire to get work done.

The rules for IETF virtual interims are neither hard to discover, nor hard to
comply with. The rules exist to ensure that people are included in the work, and
I am sure that inclusion is what you want.

I find it unfortunate that you scheduled a working group meeting to discuss only
one of a pair of competing documents on the same topic, that you didn't make the
information about the meeting available to the authors of the competing document
or to the people who care about the protocol being modelled, and I find it
upsetting (yes, I am actually upset) that you decided to discuss in Netmod a
document that belongs in the OSPF working group.

If, as it surely sounds, you wish that the Netmod working group had a different
charter to enable it to take on models for protocols that already have a home in
other working groups, then I suggest you need to recharter. But I doubt that
your reasoning that [YANG] experts will not go to all the other working groups
will carry much weight. Frankly, and without wanting to disrespect the YANG
experts, it is easier to understand YANG than it is to understand OSPF. If this
were not the case then the Netmod working group would have failed in its design
of YANG!

Conclusion:
You want to work on a YANG model for OSPF. Go to the OSPF working group and
discuss it (there are already some threads). Review and comment on the competing
document. Try to get agreement between all of the authors of both documents, or
try to identify the differences. Work with the chairs of the OSPF working group
to advance the work.

Adrian

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com]
> Sent: 22 October 2014 14:29
> To: Benoit Claise
> Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org;
> rtg-ads@tools.ietf.org
> Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled
>
>
>       This is hugely disappointing. This is the kind of procedural non-sense
has
> and IS driving people away from the IETF to other places where this work is
going
> to get done. The simple effect of such silliness will be a reduction in speed
and
> quantity of model development.  If the goal of the IESG is to slow down the
> velocity of model development and creation, then this approach is perfect.
>
>       For the record, the interim NETMOD meeting cadence has one meeting
> focused on Yang and the other on modeling; is not NETMOD-specific per say, but
> to promote model creation because no other bi-weekly forum exists to do so. It
> is also a place to bring in non-IETF work such as the work done in ODL, other
open
> source, or just the public community that has explicitly wanted to avoid the
IETF.
> We have found it a convenient and fruitful place to discuss, and actually
*build*
> models - regardless of their ultimate WG home.  The simple reason: its a
single
> place for many of the experts to gather. I think you will find it very
difficult to get
> those people onto a per-WG call every other week.
>
>       I hope the IESG considers this approach carefully because I do not think
it
> will have the affect the larger IETF community is interested in.
>
>       --Tom
>
>
>
> > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise <bclaise@cisco.com>
wrote:
> >
> > Dear all,
> >
> > Today NETMOD interim meeting is canceled.
> >
> > I received some pushbacks from the routing ADs, on the ground that:
> > 1. This interim appears to be meeting to discuss a non-WG draft for which
there
> is no milestone in the working group and for which there is an obvious home
> outside the working group.
> > 2. The agenda was not announced a week in advance on the IETF announce list
> as is required
> >
> > Regards, Benoit
> >
> > _______________________________________________
> > Rtg-yang-coord mailing list
> > Rtg-yang-coord@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtg-yang-coord
> >

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

 

 


--------------080204070205080802080900-- From nobody Wed Oct 22 14:13:11 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B13641A1B39; Wed, 22 Oct 2014 14:12:53 -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 s3a6Io6jvI05; Wed, 22 Oct 2014 14:12:42 -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 22F901A01F9; Wed, 22 Oct 2014 14:12:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=84502; q=dns/txt; s=iport; t=1414012358; x=1415221958; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=7NUXipr5hnKVh6MR95fCw+KLnXzXAswDGf0KNg58OqU=; b=a6t/JYBNacgbYhtmI/muM5v2fjTGUThItQtF/KlZlKgIZTSz/7Hzu7Sf WalPEZxPW60xqqT8vU0LixJPKX1pFVbim2CVbnEMxKWgND+J0dvRDKgvp fPCgwDiSbhkNy6MypnF59mjpAn59/7XbCIhpYnAp/fdBp0yY5Z+xnIO1f c=; X-IronPort-AV: E=Sophos; i="5.04,771,1406592000"; d="scan'208,217"; a="89470135" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-6.cisco.com with ESMTP; 22 Oct 2014 21:12:37 +0000 Received: from [10.154.182.28] ([10.154.182.28]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s9MLCagO026533; Wed, 22 Oct 2014 21:12:36 GMT Message-ID: <54481DC4.70800@cisco.com> Date: Wed, 22 Oct 2014 14:12:36 -0700 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, "'Eric Voit (evoit)'" , "'Thomas D. Nadeau'" , "'Andy Bierman'" References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> <033001cfee0d$39f4be00$adde3a00$@olddog.co.uk> In-Reply-To: <033001cfee0d$39f4be00$adde3a00$@olddog.co.uk> Content-Type: multipart/alternative; boundary="------------090409060209050203010309" Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/IloC4YTPiNNX2bROfiDFzSjRGss Cc: Rtg-yang-coord@ietf.org, ospf-chairs@tools.ietf.org, ops-ads@tools.ietf.org, 'NETMOD Working Group' , rtg-ads@tools.ietf.org Subject: Re: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2014 21:12:54 -0000 This is a multi-part message in MIME format. --------------090409060209050203010309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Adrian, > > Eric, > > I cannot speak to why the meeting was cancelled. > > My disquiet was simply that an item on the agenda was out of scope and > not properly announced to achieve the correct participation. > > The text I sent to Benoit read... > > > In summary: if this meeting does not have material to discuss under > > > the agenda for which the meeting was called, then it must be cancelled. > > You appear to be saying that there was work to be done that was in > scope for the WG and was part of the agenda that was published. > > So I'm a bit puzzled. > You raised the "violation of IETF" process flag + the issue that we should not be discussing non NETMOD documents in NETMOD, and now, you're puzzled... Really? Regards, Benoit > Adrian > > *From:*Eric Voit (evoit) [mailto:evoit@cisco.com] > *Sent:* 22 October 2014 16:20 > *To:* Thomas D. Nadeau; Andy Bierman > *Cc:* Rtg-yang-coord@ietf.org; NETMOD Working Group; > ospf-chairs@tools.ietf.org; ops-ads@tools.ietf.org; > rtg-ads@tools.ietf.org; Farrel Adrian > *Subject:* RE: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled > > As Tom and others note, today's Netmod interim was to have topics > beyond OSPF. These included OpenDaylight related work. The IETF > should be encouraging venues for Open Source developer audiences. > Cancelling full meetings via IETF procedural mechanisms signals the > opposite. > > I *like* the idea of each WG being the owner for their domain models. > This scales well for the reasons pointed out below. And I do have > sympathy for a WG wanting to close on a definitive answer for a YANG > model before implications are discussed elsewhere. But I am worried > that we are enforcing an overly serial process. Or of constraining > communication. The market will work around this. > > In the controller space, YANG technology is not static. Some degree > of parallelism is needed across IETF WGs. Clueful Open Source/YANG > developers cannot extend themselves across all WG where YANG modeling > might occur. > > Eric > > *From:*Thomas D. Nadeau, October 22, 2014 10:52 AM > > We are trying. The thing is that you cannot just hoist that onto WGs > and say "here you go." if they don't want to do it. Again, the Netmod > charter was specifically modified to accommodate that case. And > while some WGs in the routing area are not enthusiastic about building > models, others aren't, nor are other WGs at the IETF. So for those, > what do you do? Ignore them? The other point is that others outside of > the IETF are working on these models. It is squarely within the IETF > community's interest to bring these back into the fold. Many of these > folks are skittish about coming to the IETF altogether so we've tried > to encourage them to participate in this way. If we want to push these > folks away with procedural reasons, then we have made our bed... > > ---tom > > On Oct 22, 2014:10:45 AM, at 10:45 AM, Andy Bierman > > wrote: > > Hi, > > I think the interim did not need to be cancelled. There are ACL, > SYSLOG, > > and YANG Mount topics. I was going to call in for those, not OSPF. > > But I have been saying (for over a year now) that it is time to move > > domain-specific data models into the domain-specific WGs. > > I think NETMOD WG should focus on the YANG language and > > infrastructure modules. > > Andy > > On Wed, Oct 22, 2014 at 7:35 AM, Thomas D. Nadeau > > wrote: > > No one said that OSPF experts could not attend to provide input. > The issue is that OSPF was not doing this. If they want to take > over doing all OSPF models, then great, but to date no one was. > The agreement in NETMOD (and our charter) is to facilitate the > creation of models when WGs don't want to do them, have the > expertise to do them, etc... Also, getting the right Yang experts > in one place is not going to happen for every WG in the IETF; its > just not realistic. I understand that ultimately the WG needs to > have consensus, but quick iteration to construct the model surely > can happen in a small "design team" fashion, right? > > And in terms of today's meeting being canceled, really what > purpose was that other than to stall/slow-down work? The group > that was there to work on the OSPF model was indeed a bunch of > folks from OSPF (Acee Lindem for example was on the call). So now > since we won't have another interim meeting until after Hawaii, so > the next time this group can get together is possibly in Hawaii, > but that is probably unlikely as a large number of people are not > going to Hawaii. So the net-net is a slowing of progress in this > area. Probably not the result the IETF community wants. > > ---Tom > > On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman > > wrote: > > Hi Adrian, > > I agree with you. The OSPF WG should be discussing OSPF data > models, > > not the NETMOD WG. The domain experts need to reach consensus > > on a feature set (and maybe info model) and then get 1 or 2 > YANG experts to > > help translate that to a data model. (Not the other way around > -- a room > > full of YANG experts and 1 or 2 OSPF experts). > > I also prefer that virtual interim meetings be used to discuss > open issues > > on chartered items, not as an additional forum to promote > individual drafts. > > Andy > > On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel > > wrote: > > I understand and appreciate your desire to get work done. > > The rules for IETF virtual interims are neither hard to > discover, nor hard to > comply with. The rules exist to ensure that people are > included in the work, and > I am sure that inclusion is what you want. > > I find it unfortunate that you scheduled a working group > meeting to discuss only > one of a pair of competing documents on the same topic, that > you didn't make the > information about the meeting available to the authors of the > competing document > or to the people who care about the protocol being modelled, > and I find it > upsetting (yes, I am actually upset) that you decided to > discuss in Netmod a > document that belongs in the OSPF working group. > > If, as it surely sounds, you wish that the Netmod working > group had a different > charter to enable it to take on models for protocols that > already have a home in > other working groups, then I suggest you need to recharter. > But I doubt that > your reasoning that [YANG] experts will not go to all the > other working groups > will carry much weight. Frankly, and without wanting to > disrespect the YANG > experts, it is easier to understand YANG than it is to > understand OSPF. If this > were not the case then the Netmod working group would have > failed in its design > of YANG! > > Conclusion: > You want to work on a YANG model for OSPF. Go to the OSPF > working group and > discuss it (there are already some threads). Review and > comment on the competing > document. Try to get agreement between all of the authors of > both documents, or > try to identify the differences. Work with the chairs of the > OSPF working group > to advance the work. > > Adrian > > > -----Original Message----- > > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com > ] > > Sent: 22 October 2014 14:29 > > To: Benoit Claise > > Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org > ; ops-ads@tools.ietf.org > ; > > rtg-ads@tools.ietf.org > > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled > > > > > > This is hugely disappointing. This is the kind of > procedural non-sense > has > > and IS driving people away from the IETF to other places > where this work is > going > > to get done. The simple effect of such silliness will be a > reduction in speed > and > > quantity of model development. If the goal of the IESG is to > slow down the > > velocity of model development and creation, then this > approach is perfect. > > > > For the record, the interim NETMOD meeting cadence has > one meeting > > focused on Yang and the other on modeling; is not > NETMOD-specific per say, but > > to promote model creation because no other bi-weekly forum > exists to do so. It > > is also a place to bring in non-IETF work such as the work > done in ODL, other > open > > source, or just the public community that has explicitly > wanted to avoid the > IETF. > > We have found it a convenient and fruitful place to discuss, > and actually > *build* > > models - regardless of their ultimate WG home. The simple > reason: its a > single > > place for many of the experts to gather. I think you will > find it very > difficult to get > > those people onto a per-WG call every other week. > > > > I hope the IESG considers this approach carefully > because I do not think > it > > will have the affect the larger IETF community is interested in. > > > > --Tom > > > > > > > > > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise > > > wrote: > > > > > > Dear all, > > > > > > Today NETMOD interim meeting is canceled. > > > > > > I received some pushbacks from the routing ADs, on the > ground that: > > > 1. This interim appears to be meeting to discuss a non-WG > draft for which > there > > is no milestone in the working group and for which there is > an obvious home > > outside the working group. > > > 2. The agenda was not announced a week in advance on the > IETF announce list > > as is required > > > > > > Regards, Benoit > > > > > > _______________________________________________ > > > Rtg-yang-coord mailing list > > > Rtg-yang-coord@ietf.org > > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord --------------090409060209050203010309 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Adrian,

Eric,

 

I cannot speak to why the meeting was cancelled.

My disquiet was simply that an item on the agenda was out of scope and not properly announced to achieve the correct participation.

 

The text I sent to Benoit read...

 

> In summary: if this meeting does not have material to discuss under

> the agenda for which the meeting was called, then it must be cancelled.

 

You appear to be saying that there was work to be done that was in scope for the WG and was part of the agenda that was published.

 

So I'm a bit puzzled.

You raised the "violation of IETF" process flag + the issue that we should not be discussing non NETMOD documents in NETMOD, and now, you're puzzled... Really?

Regards, Benoit

 

Adrian

 

 

From: Eric Voit (evoit) [mailto:evoit@cisco.com]
Sent: 22 October 2014 16:20
To: Thomas D. Nadeau; Andy Bierman
Cc: Rtg-yang-coord@ietf.org; NETMOD Working Group; ospf-chairs@tools.ietf.org; ops-ads@tools.ietf.org; rtg-ads@tools.ietf.org; Farrel Adrian
Subject: RE: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled

 

As Tom and others note, today’s Netmod interim was to have topics beyond OSPF.  These included OpenDaylight related work.   The IETF should be encouraging venues for Open Source developer audiences.  Cancelling full meetings via IETF procedural mechanisms signals the opposite. 

 

I *like* the idea of each WG being the owner for their domain models.  This scales well for the reasons  pointed out below.  And I do have sympathy for a WG wanting to close on a definitive answer for a YANG model before implications are discussed elsewhere.   But I am worried that we are enforcing an overly serial process.  Or of constraining communication.  The market will work around this.  

 

In the controller space, YANG technology is not static.  Some degree of parallelism is needed across IETF WGs.  Clueful Open Source/YANG developers cannot extend themselves across all WG where YANG modeling might occur.

 

Eric

 

 

From: Thomas D. Nadeau, October 22, 2014 10:52 AM

          We are trying. The thing is that you cannot just hoist that onto WGs and say “here you go.” if they don’t want to do it.  Again, the Netmod charter was specifically modified to accommodate that case.   And while some WGs in the routing area are not enthusiastic about building models, others aren’t, nor are other WGs at the IETF. So for those, what do you do? Ignore them? The other point is that others outside of the IETF are working on these models.  It is squarely within the IETF community’s interest to bring these back into the fold.  Many of these folks are skittish about coming to the IETF altogether so we’ve tried to encourage them to participate in this way. If we want to push these folks away with procedural reasons, then we have made our bed...

 

          —tom

 

 

 

On Oct 22, 2014:10:45 AM, at 10:45 AM, Andy Bierman <andy@yumaworks.com> wrote:

 

Hi,

 

I think the interim did not need to be cancelled. There are ACL, SYSLOG,

and YANG Mount topics. I was going to call in for those, not OSPF.

But I have been saying (for over a year now) that it is time to move

domain-specific data models into the domain-specific WGs.

I think NETMOD WG should focus on the YANG language and

infrastructure modules.

 

Andy

 

 

On Wed, Oct 22, 2014 at 7:35 AM, Thomas D. Nadeau <tnadeau@lucidvision.com> wrote:

 

No one said that OSPF experts could not attend to provide input.   The issue is that OSPF was not doing this. If they want to take over doing all OSPF models, then great, but to date no one was.  The agreement in NETMOD (and our charter) is to facilitate the creation of models when WGs don’t want to do them, have the expertise to do them, etc…  Also, getting the right Yang experts in one place is not going to happen for every WG in the IETF; its just not realistic.  I understand that ultimately the WG needs to have consensus, but quick iteration to construct the model surely can happen in a small “design team” fashion, right?

 

And in terms of today’s meeting being canceled, really what purpose was that other than to stall/slow-down work?  The group that was there to work on the OSPF model was indeed a bunch of folks from OSPF (Acee Lindem for example was on the call).  So now since we won’t have another interim meeting until after Hawaii, so the next time this group can get together is possibly in Hawaii, but that is probably unlikely as a large number of people are not going to Hawaii.  So the net-net is a slowing of progress in this area.  Probably not the result the IETF community wants.

 

—Tom

 

 

 

On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman <andy@yumaworks.com> wrote:

 

Hi Adrian,

 

I agree with you. The OSPF WG should be discussing OSPF data models,

not the NETMOD WG. The domain experts need to reach consensus

on a feature set (and maybe info model) and then get 1 or 2 YANG experts to

help translate that to a data model. (Not the other way around -- a room

full of YANG experts and 1 or 2 OSPF experts).

 

I also prefer that virtual interim meetings be used to discuss open issues

on chartered items, not as an additional forum to promote individual drafts.

 

 

Andy

 

 

On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:

I understand and appreciate your desire to get work done.

The rules for IETF virtual interims are neither hard to discover, nor hard to
comply with. The rules exist to ensure that people are included in the work, and
I am sure that inclusion is what you want.

I find it unfortunate that you scheduled a working group meeting to discuss only
one of a pair of competing documents on the same topic, that you didn't make the
information about the meeting available to the authors of the competing document
or to the people who care about the protocol being modelled, and I find it
upsetting (yes, I am actually upset) that you decided to discuss in Netmod a
document that belongs in the OSPF working group.

If, as it surely sounds, you wish that the Netmod working group had a different
charter to enable it to take on models for protocols that already have a home in
other working groups, then I suggest you need to recharter. But I doubt that
your reasoning that [YANG] experts will not go to all the other working groups
will carry much weight. Frankly, and without wanting to disrespect the YANG
experts, it is easier to understand YANG than it is to understand OSPF. If this
were not the case then the Netmod working group would have failed in its design
of YANG!

Conclusion:
You want to work on a YANG model for OSPF. Go to the OSPF working group and
discuss it (there are already some threads). Review and comment on the competing
document. Try to get agreement between all of the authors of both documents, or
try to identify the differences. Work with the chairs of the OSPF working group
to advance the work.

Adrian

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com]
> Sent: 22 October 2014 14:29
> To: Benoit Claise
> Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org;
> rtg-ads@tools.ietf.org
> Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled
>
>
>       This is hugely disappointing. This is the kind of procedural non-sense
has
> and IS driving people away from the IETF to other places where this work is
going
> to get done. The simple effect of such silliness will be a reduction in speed
and
> quantity of model development.  If the goal of the IESG is to slow down the
> velocity of model development and creation, then this approach is perfect.
>
>       For the record, the interim NETMOD meeting cadence has one meeting
> focused on Yang and the other on modeling; is not NETMOD-specific per say, but
> to promote model creation because no other bi-weekly forum exists to do so. It
> is also a place to bring in non-IETF work such as the work done in ODL, other
open
> source, or just the public community that has explicitly wanted to avoid the
IETF.
> We have found it a convenient and fruitful place to discuss, and actually
*build*
> models - regardless of their ultimate WG home.  The simple reason: its a
single
> place for many of the experts to gather. I think you will find it very
difficult to get
> those people onto a per-WG call every other week.
>
>       I hope the IESG considers this approach carefully because I do not think
it
> will have the affect the larger IETF community is interested in.
>
>       --Tom
>
>
>
> > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise <bclaise@cisco.com>
wrote:
> >
> > Dear all,
> >
> > Today NETMOD interim meeting is canceled.
> >
> > I received some pushbacks from the routing ADs, on the ground that:
> > 1. This interim appears to be meeting to discuss a non-WG draft for which
there
> is no milestone in the working group and for which there is an obvious home
> outside the working group.
> > 2. The agenda was not announced a week in advance on the IETF announce list
> as is required
> >
> > Regards, Benoit
> >
> > _______________________________________________
> > Rtg-yang-coord mailing list
> > Rtg-yang-coord@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtg-yang-coord
> >

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

 

 

 

 



_______________________________________________
Rtg-yang-coord mailing list
Rtg-yang-coord@ietf.org
https://www.ietf.org/mailman/listinfo/rtg-yang-coord

--------------090409060209050203010309-- From nobody Wed Oct 22 14:33:05 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F1051A6EEC; Wed, 22 Oct 2014 14:32:59 -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, MIME_QP_LONG_LINE=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 HYNhOLYlv8za; Wed, 22 Oct 2014 14:32:52 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 579841A6EFF; Wed, 22 Oct 2014 14:32:41 -0700 (PDT) Received: from [10.254.210.149] (23-25-240-189-static.hfc.comcastbusiness.net [23.25.240.189]) by lucidvision.com (Postfix) with ESMTP id 1A9A328D17DF; Wed, 22 Oct 2014 17:32:40 -0400 (EDT) Content-Type: multipart/alternative; boundary=Apple-Mail-3F814C92-4193-4045-9655-3680D895D829 Mime-Version: 1.0 (1.0) From: Thomas Nadeau X-Mailer: iPhone Mail (12B411) In-Reply-To: <54481CE8.808@cisco.com> Date: Wed, 22 Oct 2014 17:32:38 -0400 Content-Transfer-Encoding: 7bit Message-Id: <8990373F-3F69-4560-B863-C1248FD65B03@lucidvision.com> References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> <057901cfee26$754ecc20$5fec6460$@ndzh.com> <54481CE8.808@cisco.com> To: Benoit Claise Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/hk65cD32K6JPAbGL5m12xxUVk3A Cc: "Rtg-yang-coord@ietf.org" , NETMOD Working Group , "ospf-chairs@tools.ietf.org" , "ops-ads@tools.ietf.org" , "rtg-ads@tools.ietf.org" , Farrel Adrian , Susan Hares Subject: Re: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2014 21:33:00 -0000 --Apple-Mail-3F814C92-4193-4045-9655-3680D895D829 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1 > On Oct 22, 2014, at 5:08 PM, Benoit Claise wrote: >=20 > Dear all, >> Tom: >> =20 >> Acee indicated earlier on the i2rs list (September discussion) that the O= SPF yang model was going to be standardized in OSPF. I=E2=80=99m glad we=E2= =80=99ve got the rtg-yang-coord list to sort out these issues. >> =20 >> IDR will pick up all BGP related yang modules. A charter addition has be= en made. IDR will gladly accept input from the netmod WG or hold joint inte= rim session to make this effort go fast.=20 > Exactly. The YANG modules should be standardized in the respective WGs. > To have good YANG modules, you need: > 1. the technology experts, i.e. the respective WG > 2. YANG review >=20 > I don't understand all this fuss about: "oh, but you can't speak about an O= SPF module in a NETMOD WG". > We want to do what's right by providing YANG review of the documents, noth= ing else. >=20 > I don't understand all this fuss about: "oh, but if you speak about one OS= PF YANG model, then you must include all the other ones". > People who want feedback on their YANG modules are welcome to join. This w= as the goal. >=20 > Regards, Benoit >=20 >> The configuration drafts for bgp (draft-zhdankin-netmod-bgp-cfg-00.txt) a= nd the I2rs drafts for bgp (draft-i2rs-hares-bgp-dm-00) have only a 5% funct= ional overlap. I will be releasing a draft that compares these two drafts, a= nd looks at how these drafts fulfill the I2RS BGP use case requirements. >> =20 >> IDR will sponsor a design team in IDR to push the rapid development of bg= p configuration or bgp i2rs. If you could suggest a few netmod people to he= lp this effort it would help. =20 >> =20 >> My understanding of IETF best practices indicate that joint interims need= 2 weeks announcement of topics.=20 >> =20 >> Sue >> =20 >> From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf O= f Thomas D. Nadeau >> Sent: Wednesday, October 22, 2014 10:35 AM >> To: Andy Bierman >> Cc: Rtg-yang-coord@ietf.org; NETMOD Working Group; ospf-chairs@tools.ietf= .org; ops-ads@tools.ietf.org; rtg-ads@tools.ietf.org; Benoit Claise; Farrel A= drian >> Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled >> =20 >> =20 >> No one said that OSPF experts could not attend to provide inp= ut. The issue is that OSPF was not doing this. If they want to take over d= oing all OSPF models, then great, but to date no one was. The agreement in N= ETMOD (and our charter) is to facilitate the creation of models when WGs don= =E2=80=99t want to do them, have the expertise to do them, etc=E2=80=A6 Als= o, getting the right Yang experts in one place is not going to happen for ev= ery WG in the IETF; its just not realistic. I understand that ultimately th= e WG needs to have consensus, but quick iteration to construct the model sur= ely can happen in a small =E2=80=9Cdesign team=E2=80=9D fashion, right? >> =20 >> And in terms of today=E2=80=99s meeting being canceled, reall= y what purpose was that other than to stall/slow-down work? The group that w= as there to work on the OSPF model was indeed a bunch of folks from OSPF (Ac= ee Lindem for example was on the call). So now since we won=E2=80=99t have a= nother interim meeting until after Hawaii, so the next time this group can g= et together is possibly in Hawaii, but that is probably unlikely as a large n= umber of people are not going to Hawaii. So the net-net is a slowing of pro= gress in this area. Probably not the result the IETF community wants. >> =20 >> =E2=80=94Tom >> =20 >> =20 >> =20 >> On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman w= rote: >> =20 >> Hi Adrian, >> =20 >> I agree with you. The OSPF WG should be discussing OSPF data models, >> not the NETMOD WG. The domain experts need to reach consensus >> on a feature set (and maybe info model) and then get 1 or 2 YANG experts t= o >> help translate that to a data model. (Not the other way around -- a room >> full of YANG experts and 1 or 2 OSPF experts). >> =20 >> I also prefer that virtual interim meetings be used to discuss open issue= s >> on chartered items, not as an additional forum to promote individual draf= ts. >> =20 >> =20 >> Andy >> =20 >> =20 >> On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel wrot= e: >> I understand and appreciate your desire to get work done. >>=20 >> The rules for IETF virtual interims are neither hard to discover, nor har= d to >> comply with. The rules exist to ensure that people are included in the wo= rk, and >> I am sure that inclusion is what you want. >>=20 >> I find it unfortunate that you scheduled a working group meeting to discu= ss only >> one of a pair of competing documents on the same topic, that you didn't m= ake the >> information about the meeting available to the authors of the competing d= ocument >> or to the people who care about the protocol being modelled, and I find i= t >> upsetting (yes, I am actually upset) that y= ou decided to discuss in Netmod a >> document that belongs in the OSPF working group. >>=20 >> If, as it surely sounds, you wish that the Netmod working group had a dif= ferent >> charter to enable it to take on models for protocols that already have a h= ome in >> other working groups, then I suggest you need to recharter. But I doubt t= hat >> your reasoning that [YANG] experts will not go to all the other working g= roups >> will carry much weight. Frankly, and without wanting to disrespect the YA= NG >> experts, it is easier to understand YANG than it is to understand OSPF. I= f this >> were not the case then the Netmod working group would have failed in its d= esign >> of YANG! >>=20 >> Conclusion: >> You want to work on a YANG model for OSPF. Go to the OSPF working group a= nd >> discuss it (there are already some threads). Review and comment on the co= mpeting >> document. Try to get agreement between all of the authors of both documen= ts, or >> try to identify the differences. Work with the chairs of the OSPF working= group >> to advance the work. >>=20 >> Adrian >>=20 >> > -----Original Message----- >> > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com] >> > Sent: 22 October 2014 14:29 >> > To: Benoit Claise >> > Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.o= rg; >> > rtg-ads@tools.ietf.org >> > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled >> > >> > >> > This is hugely disappointing. This is the kind of procedural non-= sense >> has >> > and IS driving people away from the IETF to other places where this wor= k is >> going >> > to get done. The simple effect of such silliness will be a reduction in= speed >> and >> > quantity of model development. If the goal of the IESG is to slow down= the >> > velocity of model development and creation, then this approach is perfe= ct. >> > >> > For the record, the interim NETMOD meeting cadence has one meetin= g >> > focused on Yang and the other on modeling; is not NETMOD-specific per s= ay, but >> > to promote model creation because no other bi-weekly forum exists to do= so. It >> > is also a place to bring in non-IETF work such as the work done in ODL,= other >> open >> > source, or just the public community that has explicitly wanted to avoi= d the >> IETF. >> > We have found it a convenient and fruitful place to discuss, and actual= ly >> *build* >> > models - regardless of their ultimate WG home. The simple reason: its a= >> single >> > place for many of the experts to gather. I think you will find it very >> difficult to get >> > those people onto a per-WG call every other week. >> > >> > I hope the IESG considers this approach carefully because I do no= t think >> it >> > will have the affect the larger IETF community is interested in. >> > >> > --Tom >> > >> > >> > >> > > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise >> wrote: >> > > >> > > Dear all, >> > > >> > > Today NETMOD interim meeting is canceled. >> > > >> > > I received some pushbacks from the routing ADs, on the ground that: >> > > 1. This interim appears to be meeting to discuss a non-WG draft for w= hich >> there >> > is no milestone in the working group and for which there is an obvious h= ome >> > outside the working group. >> > > 2. The agenda was not announced a week in advance on the IETF announc= e list >> > as is required >> > > >> > > Regards, Benoit >> > > >> > > _______________________________________________ >> > > Rtg-yang-coord mailing list >> > > Rtg-yang-coord@ietf.org >> > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord >> > > >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 --Apple-Mail-3F814C92-4193-4045-9655-3680D895D829 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
+1



On Oct 22= , 2014, at 5:08 PM, Benoit Claise <b= claise@cisco.com> wrote:

= =20 =20 =20
Dear all,

Tom:

 

Acee indicated earlier on the i2rs list (September discussion) that the OSPF yang model was going to be standardized in OSPF.  I=E2=80=99m glad we=E2=80=99ve got the rtg-yang-coor= d list to sort out these issues.

 

IDR will pick up all BGP related yang modules.  A charter addition has been made.  IDR will gladly accept input from the netmod WG or hold joint interim session to make this effort go fast. 

Exactly. The YANG modules should be standardized in the respective WGs.
To have good YANG modules, you need:
1. the technology experts, i.e. the respective WG
2. YANG review

I don't understand all this fuss about: "oh, but you can't speak about an OSPF module in a NETMOD WG".
We want to do what's right by providing YANG review of the documents, nothing else.

I don't understand all this fuss about: "oh, but if you speak about one OSPF YANG model, then you must include all the other ones".
People who want feedback on their YANG modules are welcome to join. This was the goal.

Regards, Benoit

The configuration drafts for bgp (draft-zhdankin-netmod-bgp-cfg-00.txt) and the I2rs drafts for bgp (draft-i2rs-hares-bgp-dm-00) have only a 5% functional overlap.  I will be releasing a draft that compares these two drafts, and looks at how these drafts fulfill the I2RS BGP use case requirements.

 

IDR will sponsor a design team in IDR to push the rapid development of bgp configuration or bgp i2rs.  If you could= suggest a few netmod people to help this effort it would help.  

 

My understanding of IETF best practices indicate that joint interims need 2 weeks announcement of topics. =

 

Sue

 

From:= Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.or= g] On Behalf Of Thomas D. Nadeau
Sent: Wednesday, October 22, 2014 10:35 AM
To: Andy Bierman
Cc: Rtg-yang-coord@ietf.org; NETMOD Working Group; ospf-chairs@tools.ietf.org; ops-ads@tools.ietf.org; rtg-ads@tools.ietf.org; Be= noit Claise; Farrel Adrian
Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled

 

 

  &n= bsp;         No one said that OSPF experts could not attend to provide input.   The issue is that OSPF was not doing this. If they want to take over doing all OSPF models, then great, but to date no one was.  The agreement in NETMOD (and our charter) is to facilitate the creation of models when WGs don=E2=80=99t want to d= o them, have the expertise to do them, etc=E2=80=A6  Also, gett= ing the right Yang experts in one place is not going to happen for every WG in the IETF; its just not realistic.  I understand that ultimately the WG needs to have consensus, but quick iteration to construct the model surely can happen in a small =E2=80=9Cdesign team=E2=80=9D fashion, right?

 

  =           And in terms of today=E2=80=99s meeting being canceled, really what purpose was that other than to stall/slow-down work?  The group that was there to work on the OSPF model was indeed a bunch of folks from OSPF (Acee Lindem for example was on the call).  So now since we won=E2=80=99t ha= ve another interim meeting until after Hawaii, so the next time this group can get together is possibly in Hawaii, but that is probably unlikely as a large number of people are not going to Hawaii.  So the net-net is a slowing of progress i= n this area.  Probably not the result the IETF community wants.

 

 &nbs= p;          =E2=80=94Tom

 

 

 

On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman <andy@yumaworks.com> wrote:

 

Hi Adrian,

 

I agree with you. The OSPF WG should be discussing OSPF data models,

not the NETMOD WG. The domain experts need to reach consensus

on a feature set (and maybe info model) and then get 1 or 2 YANG experts to=

help translate that to a data model. (Not the other way around -- a room

full of YANG experts and 1 or 2 OSPF experts).

 

I also prefer that virtual interim meetings be used to discuss open issues=

on chartered items, not as an additional forum to promote individual drafts.<= /o:p>

 

 

Andy

 

 

On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel <adrian@olddog.c= o.uk> wrote:

I understand and appreciate your desire to get work done.

The rules for IETF virtual interims are neither hard to discover, nor hard to
comply with. The rules exist to ensure that people are included in the work, and
I am sure that inclusion is what you want.
=
I find it unfortunate that you scheduled a working group meeting to discuss only
one of a pair of competing documents on the same topic, that you didn't make the
information about the meeting available to the authors of the competing document
or to the people who care about the protocol being modelled, and I find it
upsetting (yes, I am actually upset) that you decided to discuss in Netmod a
document that belongs in the OSPF working group.

If, as it surely sounds, you wish that the Netmod working group had a different
charter to enable it to take on models for protocols that already have a home in
other working groups, then I suggest you need to recharter. But I doubt that
your reasoning that [YANG] experts will not go to all the other working groups
will carry much weight. Frankly, and without wanting to disrespect the YANG
experts, it is easier to understand YANG than it is to understand OSPF. If this
were not the case then the Netmod working group would have failed in its design
of YANG!

Conclusion:
You want to work on a YANG model for OSPF. Go to the OSPF working group and
discuss it (there are already some threads). Review and comment on the competing
document. Try to get agreement between all of the authors of both documents, or
try to identify the differences. Work with the chairs of the OSPF working group
to advance the work.

Adrian

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@lucidvisio= n.com]
> Sent: 22 October 2014 14:29
> To: Benoit Claise
> Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org= ; ops-ads@tools.ietf.org;
> rtg-ads@tools.ietf.org
> Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled
>
>
>       This is hugely d= isappointing. This is the kind of procedural non-sense
has
> and IS driving people away from the IETF to other places where this work is
going
> to get done. The simple effect of such silliness will be a reduction in speed
and
> quantity of model development.  If the goal of the IESG is to slow down the
> velocity of model development and creation, then this approach is perfect.
>
>       For the record,= the interim NETMOD meeting cadence has one meeting
> focused on Yang and the other on modeling; is not NETMOD-specific per say, but
> to promote model creation because no other bi-weekly forum exists to do so. It
> is also a place to bring in non-IETF work such as the work done in ODL, other
open
> source, or just the public community that has explicitly wanted to avoid the
IETF.
> We have found it a convenient and fruitful place to discuss, and actually
*build*
> models - regardless of their ultimate WG home.  The simple reason: its a
single
> place for many of the experts to gather. I think you will find it very
difficult to get
> those people onto a per-WG call every other week.
>
>       I hope the IESG= considers this approach carefully because I do not think
it
> will have the affect the larger IETF community is interested in.
>
>       --Tom
>
>
>
> > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise <bclaise@cisco.com>
wrote:
> >
> > Dear all,
> >
> > Today NETMOD interim meeting is canceled.
> >
> > I received some pushbacks from the routing ADs, on the ground that:
> > 1. This interim appears to be meeting to discuss a non-WG draft for which
there
> is no milestone in the working group and for which there is an obvious home
> outside the working group.
> > 2. The agenda was not announced a week in advance on the IETF announce list
> as is required
> >
> > Regards, Benoit
> >
> > ______________________________________________= _
> > Rtg-yang-coord mailing list
> > Rtg-yang-coord@ietf.org
> > http= s://www.ietf.org/mailman/listinfo/rtg-yang-coord
> >

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

 

 


=20
= --Apple-Mail-3F814C92-4193-4045-9655-3680D895D829-- From nobody Wed Oct 22 17:14:52 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC9331A1AF7 for ; Wed, 22 Oct 2014 17:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 52yUtctrBlhp for ; Wed, 22 Oct 2014 17:14:48 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0113.outbound.protection.outlook.com [65.55.169.113]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C5EB1A1AA6 for ; Wed, 22 Oct 2014 17:14:47 -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.0.1049.19; Thu, 23 Oct 2014 00:14:45 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.50]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.50]) with mapi id 15.00.1049.012; Thu, 23 Oct 2014 00:14:45 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: inability to Thread-Index: AQHP7lZZqY8bTA8e4E60+FoKILvI6A== Date: Thu, 23 Oct 2014 00:14:45 +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 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.13] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 0373D94D15 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(164054003)(199003)(110136001)(99286002)(101416001)(105586002)(107886001)(86362001)(92726001)(122556002)(99396003)(50986999)(2656002)(87936001)(54356999)(106116001)(92566001)(106356001)(4396001)(66066001)(19580395003)(77096002)(107046002)(20776003)(229853001)(83506001)(120916001)(76482002)(64706001)(2351001)(36756003)(97736003)(40100003)(31966008)(85306004)(85852003)(95666004)(80022003)(21056001)(46102003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/-cJxlbWkiHnoHEe8u1jmf2gYLA8 Subject: [netmod] inability to X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 23 Oct 2014 00:14:51 -0000 I'm trying to flatten the netconf-server model from: +--rw netconf-server +--rw listen +--rw endpoint* [name] +--rw name string +--rw (transport) +--:(ssh) {ssh-listen}? | +--rw ssh | +--rw address inet:ip-address | +--rw port? inet:port-number +--:(tls) {tls-listen}? +--rw tls +--rw address inet:ip-address +--rw port? inet:port-number To: +--rw netconf-server +--rw listen +--rw endpoint* [name] +--rw name string +--rw transport enumeration +--rw address inet:ip-address +--rw port? inet:port-number The reason I used the first construct was only so that a grouping could be used under each "transport" choice, which then could "refine" the port's default value to the transport-specific value: uses listen-per-transport-config { refine port { default 830; } } Or uses listen-per-transport-config { refine port { default 6513; } } I'm trying again now and still can't find a way to do it. What I want, is something like: leaf port { type inet:port-number; default { 830: when "transport =3D=3D 'ssh'"; 6513: when "transport =3D=3D 'tls'"; } } I did try some wild options, for instance: grouping port-grouping { leaf port { type inet:port-number; } } uses port-grouping { when "transport =3D=3D 'ssh'"; refine port { default 830; } } uses port-grouping { when "transport =3D=3D 'tls'"; refine port { default 6513; } } Which failed:=20 ietf-netconf-server.yang:178: error: there is already a child node to "endpoint" at ../ietf-netconf-server.yang:145 with the name "port" defined at ../ietf-netconf-server.yang:172 (at ../ietf-netconf-server.yang:130) Any ideas? Thanks, Kent From nobody Wed Oct 22 18:11:27 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CDA61A8844 for ; Wed, 22 Oct 2014 18:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWa4xvC0psAl for ; Wed, 22 Oct 2014 18:11:20 -0700 (PDT) Received: from mail-yh0-x22e.google.com (mail-yh0-x22e.google.com [IPv6:2607:f8b0:4002:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1098C1A883D for ; Wed, 22 Oct 2014 18:11:19 -0700 (PDT) Received: by mail-yh0-f46.google.com with SMTP id f10so30433yha.19 for ; Wed, 22 Oct 2014 18:11:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=liAAcLsOKkvsmVjWMSksbThJWsypDMZ6LCKV5aTfHzU=; b=ItZLG3Hdy4vSSJyv+nHzhCTA/VzpZPTYu9NfpuqfUXf5qOAw8ix20uTbAlstlbL/Qf KgHHGt/9xHWoZpdw/w9vffhvUjGL/djn3LnzVWZmR7pxXHR3UVtQEzpL+M40oYrCT1Sv K5lyL8I3M6GeGktjfgqxARRp8txJWiF1DOr2XwEdycRa7Q666UdlghawIskTuLWeFdog sQasEmipkmEc5pE0CETbC5BRsw9wWZ3ok0UcTeYZvhE4cXtXGBlnf9RSmX7934zigvOS 5x9TFl0YTpf0w0Yn73uU0BChE94wYrVAtmCJqamXnSCTK16LaN46pftu3mrFb+79+K/d dYQQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yale.edu; s=googleprd; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=liAAcLsOKkvsmVjWMSksbThJWsypDMZ6LCKV5aTfHzU=; b=x6h3lTDir2xyx6XIfzQ65iuSLDLtUXWIjT9nPc6IO9tk3/T+exAstdEcEfThAo1I5m jeRZUlomDgHYPeHN5CfM2MQAbFTJ2xbkRhmcj8rjEfENHkUeTzBwL6gO7kSLTO2uiuvu fNPUZiKpjBwLvKY+6zrwCscaLXMp6DEeXBh/o= X-Received: by 10.236.63.163 with SMTP id a23mr2116216yhd.41.1414026679230; Wed, 22 Oct 2014 18:11:19 -0700 (PDT) MIME-Version: 1.0 Sender: boxs.jq@gmail.com Received: by 10.170.221.193 with HTTP; Wed, 22 Oct 2014 18:10:59 -0700 (PDT) In-Reply-To: References: From: Xiao SHI Date: Wed, 22 Oct 2014 21:10:59 -0400 X-Google-Sender-Auth: gAF03ZZm6OiDisz8_dkjykMwS_U Message-ID: To: Kent Watsen Content-Type: multipart/alternative; boundary=089e0115ee9ceb27bd05060cbd66 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/FlPIwccqoK14nht-VlJtkkffiwM Cc: "netmod@ietf.org" Subject: Re: [netmod] inability to X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 23 Oct 2014 01:11:25 -0000 --089e0115ee9ceb27bd05060cbd66 Content-Type: text/plain; charset=UTF-8 Hi Kent, I ran into similar issues before trying to use YANG. Essentially the caveat is that the yang validator doesn't check that the when statements are logically disjoint (if there was one, it should be in semantic check stage anyway). e.g. uses groupingA { when "condition1"; leaf node1 {...} } uses groupingA { when "condition2"; leaf node1 {...} } By doing this, you are essentially creating two nodes of the same name instead of branching the condition. Similar situations happen when you try to augment a node with leafs that have the same name but different structure under different conditions. One possible solution is to use choice/case on a higher level (which was what you started with). Using augment and choice, you might be able to flatten it out to this extent: +--rw netconf-server +--rw listen +--rw endpoint* [name] +--rw name string +--rw address inet:ip-address +--rw (transport) +--:(ssh) {ssh-listen}? | +--rw ssh | +--rw port? inet:port-number +--:(tls) {tls-listen}? +--rw tls +--rw port? inet:port-number But that's not much of an improvement either. Since the only conditioning substatement of refine is the must statement (and mandatory statement which is not very helpful here), uses doesn't have choice as a substatement, I think this flattening might be difficult to accomplish. Another foreseeable solution with future extensions is to allow when statements to take on enum values. But that's complicating the issues at hand. Best, Xiao On Wed, Oct 22, 2014 at 8:14 PM, Kent Watsen wrote: > > I'm trying to flatten the netconf-server model from: > > +--rw netconf-server > +--rw listen > +--rw endpoint* [name] > +--rw name string > +--rw (transport) > +--:(ssh) {ssh-listen}? > | +--rw ssh > | +--rw address inet:ip-address > | +--rw port? inet:port-number > +--:(tls) {tls-listen}? > +--rw tls > +--rw address inet:ip-address > +--rw port? inet:port-number > > > To: > > +--rw netconf-server > +--rw listen > +--rw endpoint* [name] > +--rw name string > +--rw transport enumeration > +--rw address inet:ip-address > +--rw port? inet:port-number > > > > The reason I used the first construct was only so that a grouping could be > used under each "transport" choice, which then could "refine" the port's > default value to the transport-specific value: > > > uses listen-per-transport-config { > refine port { > default 830; > } > } > > Or > > uses listen-per-transport-config { > refine port { > default 6513; > } > } > > > > I'm trying again now and still can't find a way to do it. What I want, > is something like: > > > leaf port { > type inet:port-number; > default { > 830: when "transport == 'ssh'"; > 6513: when "transport == 'tls'"; > > } > } > > > > > I did try some wild options, for instance: > > grouping port-grouping { > leaf port { > type inet:port-number; > } > } > > > > uses port-grouping { > when "transport == 'ssh'"; > refine port { > default 830; > } > } > uses port-grouping { > when "transport == 'tls'"; > refine port { > default 6513; > } > } > > > Which failed: > > ietf-netconf-server.yang:178: error: there is already a child node to > "endpoint" at ../ietf-netconf-server.yang:145 with the name "port" defined > at ../ietf-netconf-server.yang:172 (at ../ietf-netconf-server.yang:130) > > > Any ideas? > > > Thanks, > Kent > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --089e0115ee9ceb27bd05060cbd66 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --001a11c13e4ae3149e0506193074-- From nobody Thu Oct 23 09:13:55 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2DAF1ACD37 for ; Thu, 23 Oct 2014 09:13:50 -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 jO83jLlB_7ql for ; Thu, 23 Oct 2014 09:13:49 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 113661ACD5E for ; Thu, 23 Oct 2014 09:13:49 -0700 (PDT) Received: from [172.29.2.202] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id 5F2B913F8BA; Thu, 23 Oct 2014 18:13:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1414080827; bh=KxJmKR5ImB+yqMnOAmJtT60X0ZPW57VAQzNIiHuv7+A=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=fQeth2dSuJaAla/vG9ROranyFH1bNOSVGy9ia158X3iOaHP+Td3H3aeh6DMFzZrqS GD/cwQ4TzVM8oYbeQDdxW94h+0rwD5OJFmiuQjYBFjtx1rndZJ/xSmRLBb8LGBP4dA FVB5hYAnJG1U2WsH2948lL5mwiU9WbGQDQa+3fDg= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: Date: Thu, 23 Oct 2014 18:13:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <79054E89-2D09-4461-8D35-8F6FA025B71F@nic.cz> References: To: Andy Bierman X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/9CCELe1iHeuhoxcH80tz_JfwfDk Cc: "netmod@ietf.org" Subject: Re: [netmod] IETF91 NETMOD 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, 23 Oct 2014 16:13:51 -0000 Hi, apart from the two WG items draft-ietf-netmod-routing-cfg-16 (to be = submitted) and draft-ietf-netmod-yang-json-01, I=92d like to discuss the = draft and draft-lhotka-netmod-yang-metadata-00. I think 5 minutes would = be enough for the latter, I could even do it together with yang-json. Thanks, Lada On 23 Oct 2014, at 18:02, Andy Bierman wrote: >=20 >=20 > On Tue, Oct 21, 2014 at 2:34 PM, Thomas D. Nadeau = wrote: >=20 > Not yet. Please propose topics.=20 >=20 >=20 > I would like 15 min. to discuss YANG conformance issues, specified in = this draft: > http://www.ietf.org/id/draft-bierman-netmod-yang-conformance-04.txt >=20 > These issues may get resolved in the NETCONF YANG 1.1 virtual interim > meeting next week. If not, this topic should be discussed at the IETF = meeting. >=20 >=20 > =97Tom >=20 > Andy > =20 >=20 >=20 >> On Oct 21, 2014:5:32 PM, at 5:32 PM, Sterne, Jason (Jason) = wrote: >>=20 >> Hi all, >> =20 >> Is there a preliminary agenda for the two NETMOD sessions at IETF91 ? = =20 >> =20 >> Some thought about topics being split between the 1st (longer) and = 2nd (shorter) sessions ? >> =20 >> Thanks, >> Jason >> =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 >=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 Thu Oct 23 10:43:45 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6E271A8AD2 for ; Thu, 23 Oct 2014 10:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 1z98yaxpGuz1 for ; Thu, 23 Oct 2014 10:43:42 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 466491A8AA9 for ; Thu, 23 Oct 2014 10:43:42 -0700 (PDT) Received: from [192.168.1.123] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 6995D28D3795; Thu, 23 Oct 2014 13:43:41 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: "Thomas D. Nadeau" In-Reply-To: <79054E89-2D09-4461-8D35-8F6FA025B71F@nic.cz> Date: Thu, 23 Oct 2014 13:43:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <43060BE7-53EA-4B9D-B778-2FED58C0D60C@lucidvision.com> References: <79054E89-2D09-4461-8D35-8F6FA025B71F@nic.cz> To: Ladislav Lhotka X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/12D_RWOjnlK0A2lwdu-qW6-xgmw Cc: "netmod@ietf.org" Subject: Re: [netmod] IETF91 NETMOD 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, 23 Oct 2014 17:43:44 -0000 We have plenty of runway in the agenda right now so I will put = it down as two items. We reserved two slots because I feel its important = to encourage discussion during the face2face meetings so insofar as I = can, I want to give you enough runway to discuss this in detail.=20 --Tom > On Oct 23, 2014:12:13 PM, at 12:13 PM, Ladislav Lhotka = wrote: >=20 > Hi, >=20 > apart from the two WG items draft-ietf-netmod-routing-cfg-16 (to be = submitted) and draft-ietf-netmod-yang-json-01, I=92d like to discuss the = draft and draft-lhotka-netmod-yang-metadata-00. I think 5 minutes would = be enough for the latter, I could even do it together with yang-json. >=20 > Thanks, Lada >=20 > On 23 Oct 2014, at 18:02, Andy Bierman wrote: >=20 >>=20 >>=20 >> On Tue, Oct 21, 2014 at 2:34 PM, Thomas D. Nadeau = wrote: >>=20 >> Not yet. Please propose topics.=20 >>=20 >>=20 >> I would like 15 min. to discuss YANG conformance issues, specified in = this draft: >> http://www.ietf.org/id/draft-bierman-netmod-yang-conformance-04.txt >>=20 >> These issues may get resolved in the NETCONF YANG 1.1 virtual interim >> meeting next week. If not, this topic should be discussed at the IETF = meeting. >>=20 >>=20 >> =97Tom >>=20 >> Andy >>=20 >>=20 >>=20 >>> On Oct 21, 2014:5:32 PM, at 5:32 PM, Sterne, Jason (Jason) = wrote: >>>=20 >>> Hi all, >>>=20 >>> Is there a preliminary agenda for the two NETMOD sessions at IETF91 = ? =20 >>>=20 >>> Some thought about topics being split between the 1st (longer) and = 2nd (shorter) sessions ? >>>=20 >>> Thanks, >>> Jason >>>=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 >>=20 >>=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 >=20 From nobody Thu Oct 23 12:26:34 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8437F1ACEC1 for ; Thu, 23 Oct 2014 12:26:33 -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 hiB0-XL5zS_C for ; Thu, 23 Oct 2014 12:26:32 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 065501ACEBE for ; Thu, 23 Oct 2014 12:26:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2655; q=dns/txt; s=iport; t=1414092392; x=1415301992; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=KCfuXRFvK7EFNSsqVuJ9q6r7kj/R/aoIeJXAPv2yZyg=; b=EhJkyh1dhW+i7dtGv/fBth/lLbawVYONcmJYBAqcn+4HQPZpcfSjqrzS m2Wf7JuHD7d1kv9IQGnaZ5cCYCcktkDcVESYjS+L27zlsIfzk2qr/MxCd dGHmEEDEkPl35srd68Gyx91ynmAmchWoNfiwrYofi1f2l2ZinXM1Nbv4y o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAONVSVStJV2d/2dsb2JhbABcgw5UXMx0CoZ5VAKBExYBfYQCAQEBAwEBAQFrCxIBCBhVCyUBAQQOBQmIMAgNyEUBAQEBAQEBAQIBAQEBAQEBAQEZkFgHhEsFkgWGPYUbgTGDSZEzg3hsAYFHgQMBAQE X-IronPort-AV: E=Sophos;i="5.04,776,1406592000"; d="scan'208";a="89785983" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-2.cisco.com with ESMTP; 23 Oct 2014 19:26:31 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s9NJQVT2001000 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Oct 2014 19:26:31 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.151]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Thu, 23 Oct 2014 14:26:30 -0500 From: "Dana Blair (dblair)" To: "Thomas D. Nadeau" Thread-Topic: [netmod] IETF91 NETMOD agenda ? Thread-Index: Ac/tdoGexyGw623TR4igNJSWn+KnzAAKi72AAFj9fYAAAGUuAAADI+uA///ZpYA= Date: Thu, 23 Oct 2014 19:26:30 +0000 Message-ID: In-Reply-To: <43060BE7-53EA-4B9D-B778-2FED58C0D60C@lucidvision.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.21.123.53] Content-Type: text/plain; charset="Windows-1252" Content-ID: <9406EC633E5B734FB554267F88E7EE5A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ACq2iopoI4JQVmQpZ_2_ZN12vjA Cc: "netmod@ietf.org" Subject: Re: [netmod] IETF91 NETMOD 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, 23 Oct 2014 19:26:33 -0000 Need about 10 minutes to discuss the ACL Yang draft thanks, Dana On 10/23/14, 1:43 PM, "Thomas D. Nadeau" wrote: > > We have plenty of runway in the agenda right now so I will put it down >as two items. We reserved two slots because I feel its important to >encourage discussion during the face2face meetings so insofar as I can, I >want to give you enough runway to discuss this in detail. > > --Tom > > >> On Oct 23, 2014:12:13 PM, at 12:13 PM, Ladislav Lhotka >>wrote: >>=20 >> Hi, >>=20 >> apart from the two WG items draft-ietf-netmod-routing-cfg-16 (to be >>submitted) and draft-ietf-netmod-yang-json-01, I=B9d like to discuss the >>draft and draft-lhotka-netmod-yang-metadata-00. I think 5 minutes would >>be enough for the latter, I could even do it together with yang-json. >>=20 >> Thanks, Lada >>=20 >> On 23 Oct 2014, at 18:02, Andy Bierman wrote: >>=20 >>>=20 >>>=20 >>> On Tue, Oct 21, 2014 at 2:34 PM, Thomas D. Nadeau >>> wrote: >>>=20 >>> Not yet. Please propose topics. >>>=20 >>>=20 >>> I would like 15 min. to discuss YANG conformance issues, specified in >>>this draft: >>> http://www.ietf.org/id/draft-bierman-netmod-yang-conformance-04.txt >>>=20 >>> These issues may get resolved in the NETCONF YANG 1.1 virtual interim >>> meeting next week. If not, this topic should be discussed at the IETF >>>meeting. >>>=20 >>>=20 >>> =8BTom >>>=20 >>> Andy >>>=20 >>>=20 >>>=20 >>>> On Oct 21, 2014:5:32 PM, at 5:32 PM, Sterne, Jason (Jason) >>>> wrote: >>>>=20 >>>> Hi all, >>>>=20 >>>> Is there a preliminary agenda for the two NETMOD sessions at IETF91 ? >>>> =20 >>>>=20 >>>> Some thought about topics being split between the 1st (longer) and >>>>2nd (shorter) sessions ? >>>>=20 >>>> Thanks, >>>> Jason >>>>=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 >>>=20 >>>=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 >>=20 > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Oct 23 16:30:24 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A15BA1A1C05; Thu, 23 Oct 2014 16:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3aoScr-E5CF; Thu, 23 Oct 2014 16:30:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6D21A86DD; Thu, 23 Oct 2014 16:30:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141023233014.23083.56508.idtracker@ietfa.amsl.com> Date: Thu, 23 Oct 2014 16:30:14 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/nPmsywZcL4SsDgU3dcQ-1-ojME8 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-rfc6087bis-01.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, 23 Oct 2014 23:30:20 -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 : Guidelines for Authors and Reviewers of YANG Data Model Documents Author : Andy Bierman Filename : draft-ietf-netmod-rfc6087bis-01.txt Pages : 36 Date : 2014-10-23 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: http://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6087bis-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/ From nobody Thu Oct 23 18:52:46 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 880A81AD6E8; Thu, 23 Oct 2014 18:52:44 -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 V3qAzLl-ok2t; Thu, 23 Oct 2014 18:52:41 -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 4E4181AD6D5; Thu, 23 Oct 2014 18:52:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7375; q=dns/txt; s=iport; t=1414115561; x=1415325161; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=nam3TEuZPM2lqfTEJ0oBmdN4e7ryvrnp79h25Uotx1E=; b=I7zuII7mZZQQd2KFJudDYJ2+iBk5wUd2jqQJcZQ4dDCYbpaiYbRk5Asx UFQ90JoreFQ6T8c0zK9vKwNGevH5j7T0tc0wCY28fHGHnD9V72knWzLzf rGo4fXKAGXzrBC4/73YrJSYBjLl09no7WBkL3TuwD6C1+YZcBgXeG+XL+ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAHCwSVStJV2P/2dsb2JhbABcgw5UWIMGygCHTQKBDhYBfYQDAQEEIw8BBUABEAsUBAICBRYLAgIJAwIBAgFFBgEMAQUCAQGIPQ21M5RvAQEBAQEBAQEBAQEBAQEBAQEBARmBLIkrg3OBI2sHgneBVAEEi2ODb4Z5hECCUoExESuDDYJygQ2GFIMfhACEGB0vAYJKAQEB X-IronPort-AV: E=Sophos;i="5.04,778,1406592000"; d="scan'208";a="365960407" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-5.cisco.com with ESMTP; 24 Oct 2014 01:52:40 +0000 Received: from [10.154.176.109] ([10.154.176.109]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s9O1qdHv031960; Fri, 24 Oct 2014 01:52:39 GMT Message-ID: <5449B0E6.8060000@cisco.com> Date: Thu, 23 Oct 2014 18:52:38 -0700 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Ladislav Lhotka , Acee Lindem References: <1C413D11-4390-4027-8635-A88D215689C5@lindem.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/eVhxfzIRyPtCiNy70j4yqleFHM4 Cc: "rtg-dir@ietf.org" , netmod@ietf.org, "rtg-ads@tools.ietf.org" Subject: Re: [netmod] Routing Directorate Comments on draft-ietf-netmod-routing-cfg-15 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 24 Oct 2014 01:52:44 -0000 Hi Lada, When can we expect the v16 of the draft? Hopefully before this deadline. Regards, Benoit > Acee Lindem writes: > >> Hi Lada, Thanks for your responses. It seems that you will publish a >> new revision that covers most of my comments.I will await that update > Yes. Thanks, Lada > >> and review. With respect to only supporting the forwarding model where >> none of the backup paths are used until all the primaries are >> unavailable, I will discuss the with a few more people and get back to >> you. Thanks, Acee >> >> On Jul 8, 2014, at 6:34 AM, Ladislav Lhotka wrote: >> >>> Hi Acee, >>> >>> thank you for the review, my comments are inline. >>> >>> Acee Lindem writes: >>> >>>> Hello, >>>> >>>> I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >>>> >>>> Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. >>>> >>>> Document: draft-ietf-netmod-routing-cfg-15 >>>> Reviewer: Acee Lindem >>>> Review Date: July 8th, 2014 >>>> IETF LC End Date: TBD >>>> Intended Status: Proposed Standard >>>> >>>> Summary: There some issues with the model in the document that need to be addressed prior to publication of this draft. >>>> >>>> Fundamental Question: Going forward, how will this YANG data model >>>> relate to the I2RS RIB information model proposed in >>>> draft-ietf-i2rs-rib-info-model-03.txt? >>> After IETF 87, the relevant parts of two models were compared, and this >>> resulted in several changes and additions in the NETMOD model. Since >>> then, the I2RS model underwent some changes but the only parameter that >>> needs to be included in the NETMOD model is route-preference. Other >>> parameters such as ENABLE_IP_RPF_CHECK or nexthop chains can be added >>> later via augmentation. >>> >>> On the other hand, one of the results of the alignment with I2RS RIB >>> info model, was the addition of the "id" key to every single route. In >>> the discussion with I2RS folks, I raised objections against this unique >>> "id" because it could mean considerable bookkeeping for a RIB containing >>> ~200K routes, but we eventually agreed to add it to the NETMOD >>> model. Later, several people repeated my concerns, and I think this "id" >>> should be removed from the NETMOD model. >>> >>>> Major Issues: >>>> >>>> Section 4 & 5.4: These sections appear to restrict a routing >>>> protocol instance to exactly one RIB for each address family >>>> that the routing protocol instance supports. RFC 4915, et al, >>>> support a single routing protocol instance which may populate >>>> multiple RIBs per address family. >>> This issue was brought up in a recent discussion with people working on >>> data models for OSPF and ISIS, and the rough consensus is that this >>> restriction should be lifted. By default, routes from a routing protocol >>> instance will be installed in all connected RIBs of the corresponding >>> address family (subject to operator-defined route filters), but data >>> models for particular protocols can state other rules how connected RIBs >>> are populated, e.g. using MT-ID. >>> >>>> Section 7: What are the backup next-hops? I guess these are >>>> IP-FRR next-hops that are installed by the same source protocol >>>> as the primaries? If so, do you have to restrict the forwarding >>>> paradigm to not use any backup next-hops as long as primary >>>> next-hops are accessible? This would imply that forwarding >>>> plane would need to do a fast rehash of the primaries and only >>>> use after all primaries are expired. There are other lower >>>> overhead forwarding paradigms in use. >>> In this case we only followed suit of the I2RS RIB info model, see >>> sections 2.4.2 and 7.2.4 (protection lists) in >>> draft-ietf-i2rs-rib-info-model-03. >>> >>>> Missing: There is no concept of administrative distance (Cisco, >>>> et al) or route preference (gated and Juniper). In my opinion, >>>> this is very important since it determine which route is active >>>> when the same route is available from multiple protocols. >>> Yes, route-preference will be added, see above. >>> >>>> Missing: How does one get the best route for a given protocol >>>> (which is not necessarily the active route)? Should each >>>> protocol have a local RIB as part of its model? I notice that >>>> this is not included in the RIP example in Appendix C. Would >>>> that need to be part of the run state for the protocol? >>> Yes, data models for each routing protocol should include necessary >>> protocol-internal data structures as state data - for example BGP RIB or >>> link-state database. >>> >>>> Minor issues: >>>> >>>> Section 9: Should there be checking to assure the router >>>> advertisement mtu does not exceed the ipv6 MTU from RFC 7277? >>> >>> Yes, the description of the "link-mtu" leaf should mention this >>> constraint. It cannot be done using the "must" statement though because >>> the "ip:mtu" leaf is optional and the ietf-ip module defines no default >>> for it (the default depends on interface type). >>> >>>> >>>> Questions: >>>> I guess the list routing protocol instances is independent in >>>> routing-protocols is independent of definition of the routing >>>> protocol itself? Or, would it be expected that the YANG model >>>> for the routing protocol itself would be here? If the former, >>>> wouldn’t this configuration be better grouped with the routing >>>> protocol themselves? >>> I am not sure I understand the question but data models for individual >>> routing protocols will be defined in separate YANG modules and will >>> augment the "routing-protocol" list, both in configuration and state >>> data. So, configuration parameters for a routing protocol will >>> eventually appear under "routing-protocol" but will be defined >>> separately. >>> >>>> In section 9, the placement of the router advertisement >>>> configuration seems rather arbitrary and I would have expected >>>> it to be grouped with the other interface configuration in RFC >>>> 7277. I guess placement here is the consensus of the netmod WG. >>> The advertisements should be sent only by routers, so I think it is >>> appropriate to have it as a part of router interfaces' config and state >>> data. Quite often (even at IETF meetings) we can see misconfigured hosts >>> sending these advertisements. >>> >>> Thanks, Lada >>> >>>> >>>> Thanks, >>>> Acee >>>> >>>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C From nobody Fri Oct 24 00:54:19 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 375BD1A890A; Fri, 24 Oct 2014 00:54:18 -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 LXQ4lWZAexlm; Fri, 24 Oct 2014 00:54:16 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF7411A88F0; Fri, 24 Oct 2014 00:54:15 -0700 (PDT) Received: from [192.168.1.108] (unknown [195.113.220.254]) by mail.nic.cz (Postfix) with ESMTPSA id A529814014D; Fri, 24 Oct 2014 09:54:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1414137252; bh=qTPSCcbdshkOmNbBKfBc2AYpPLl+CqrFrlalSkvLzU0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=f5O4KQSDAwIAizWUcbCX3UG5uFzLkmXo+mws4XBS2zhlsczTPY/3/8hUj4qMVlXMK EHgNU32PzI1Lo9VTaCmx+joSKdcfnNHBh0sGRPE5UWLnhuq1aNo0d+j/NSh90kXMdy gqcgy7kqC7wQSOv5zQqmpj1QIlXYAAxFPzfYQgfE= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <5449B0E6.8060000@cisco.com> Date: Fri, 24 Oct 2014 09:54:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <26AD73C7-779B-4073-97BC-A6D67FFA1209@nic.cz> References: <1C413D11-4390-4027-8635-A88D215689C5@lindem.com> <5449B0E6.8060000@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/F965s6_2Cw63-DiSKJ4FQKlRjXQ Cc: Acee Lindem , "rtg-ads@tools.ietf.org" , netmod@ietf.org, "rtg-dir@ietf.org" Subject: Re: [netmod] Routing Directorate Comments on draft-ietf-netmod-routing-cfg-15 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 24 Oct 2014 07:54:18 -0000 Hi Benoit, On 24 Oct 2014, at 03:52, Benoit Claise wrote: > Hi Lada, >=20 > When can we expect the v16 of the draft? > Hopefully before this deadline. Yes, I am aware of the deadline on Monday. We=92ve been clarifying a = couple of things with the routing guys. Cheers, Lada >=20 > Regards, Benoit >> Acee Lindem writes: >>=20 >>> Hi Lada, Thanks for your responses. It seems that you will publish a >>> new revision that covers most of my comments.I will await that = update >> Yes. Thanks, Lada >>=20 >>> and review. With respect to only supporting the forwarding model = where >>> none of the backup paths are used until all the primaries are >>> unavailable, I will discuss the with a few more people and get back = to >>> you. Thanks, Acee >>>=20 >>> On Jul 8, 2014, at 6:34 AM, Ladislav Lhotka wrote: >>>=20 >>>> Hi Acee, >>>>=20 >>>> thank you for the review, my comments are inline. >>>>=20 >>>> Acee Lindem writes: >>>>=20 >>>>> Hello, >>>>>=20 >>>>> I have been selected as the Routing Directorate reviewer for this = draft. The Routing Directorate seeks to review all routing or = routing-related drafts as they pass through IETF last call and IESG = review, and sometimes on special request. The purpose of the review is = to provide assistance to the Routing ADs. For more information about the = Routing Directorate, please see = http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >>>>>=20 >>>>> Although these comments are primarily for the use of the Routing = ADs, it would be helpful if you could consider them along with any other = IETF Last Call comments that you receive, and strive to resolve them = through discussion or by updating the draft. >>>>>=20 >>>>> Document: draft-ietf-netmod-routing-cfg-15 >>>>> Reviewer: Acee Lindem >>>>> Review Date: July 8th, 2014 >>>>> IETF LC End Date: TBD >>>>> Intended Status: Proposed Standard >>>>>=20 >>>>> Summary: There some issues with the model in the document that = need to be addressed prior to publication of this draft. >>>>>=20 >>>>> Fundamental Question: Going forward, how will this YANG data model >>>>> relate to the I2RS RIB information model proposed in >>>>> draft-ietf-i2rs-rib-info-model-03.txt? >>>> After IETF 87, the relevant parts of two models were compared, and = this >>>> resulted in several changes and additions in the NETMOD model. = Since >>>> then, the I2RS model underwent some changes but the only parameter = that >>>> needs to be included in the NETMOD model is route-preference. Other >>>> parameters such as ENABLE_IP_RPF_CHECK or nexthop chains can be = added >>>> later via augmentation. >>>>=20 >>>> On the other hand, one of the results of the alignment with I2RS = RIB >>>> info model, was the addition of the "id" key to every single route. = In >>>> the discussion with I2RS folks, I raised objections against this = unique >>>> "id" because it could mean considerable bookkeeping for a RIB = containing >>>> ~200K routes, but we eventually agreed to add it to the NETMOD >>>> model. Later, several people repeated my concerns, and I think this = "id" >>>> should be removed from the NETMOD model. >>>>=20 >>>>> Major Issues: >>>>>=20 >>>>> Section 4 & 5.4: These sections appear to restrict a = routing >>>>> protocol instance to exactly one RIB for each address family >>>>> that the routing protocol instance supports. RFC 4915, et = al, >>>>> support a single routing protocol instance which may = populate >>>>> multiple RIBs per address family. >>>> This issue was brought up in a recent discussion with people = working on >>>> data models for OSPF and ISIS, and the rough consensus is that this >>>> restriction should be lifted. By default, routes from a routing = protocol >>>> instance will be installed in all connected RIBs of the = corresponding >>>> address family (subject to operator-defined route filters), but = data >>>> models for particular protocols can state other rules how connected = RIBs >>>> are populated, e.g. using MT-ID. >>>>=20 >>>>> Section 7: What are the backup next-hops? I guess these are >>>>> IP-FRR next-hops that are installed by the same source = protocol >>>>> as the primaries? If so, do you have to restrict the = forwarding >>>>> paradigm to not use any backup next-hops as long as primary >>>>> next-hops are accessible? This would imply that forwarding >>>>> plane would need to do a fast rehash of the primaries and = only >>>>> use after all primaries are expired. There are other lower >>>>> overhead forwarding paradigms in use. >>>> In this case we only followed suit of the I2RS RIB info model, see >>>> sections 2.4.2 and 7.2.4 (protection lists) in >>>> draft-ietf-i2rs-rib-info-model-03. >>>>=20 >>>>> Missing: There is no concept of administrative distance = (Cisco, >>>>> et al) or route preference (gated and Juniper). In my = opinion, >>>>> this is very important since it determine which route is = active >>>>> when the same route is available from multiple protocols. >>>> Yes, route-preference will be added, see above. >>>>=20 >>>>> Missing: How does one get the best route for a given protocol >>>>> (which is not necessarily the active route)? Should each >>>>> protocol have a local RIB as part of its model? I notice that >>>>> this is not included in the RIP example in Appendix C. Would >>>>> that need to be part of the run state for the protocol? >>>> Yes, data models for each routing protocol should include necessary >>>> protocol-internal data structures as state data - for example BGP = RIB or >>>> link-state database. >>>>=20 >>>>> Minor issues: >>>>>=20 >>>>> Section 9: Should there be checking to assure the router >>>>> advertisement mtu does not exceed the ipv6 MTU from RFC 7277? >>>>=20 >>>> Yes, the description of the "link-mtu" leaf should mention this >>>> constraint. It cannot be done using the "must" statement though = because >>>> the "ip:mtu" leaf is optional and the ietf-ip module defines no = default >>>> for it (the default depends on interface type). >>>>=20 >>>>>=20 >>>>> Questions: >>>>> I guess the list routing protocol instances is independent = in >>>>> routing-protocols is independent of definition of the = routing >>>>> protocol itself? Or, would it be expected that the YANG = model >>>>> for the routing protocol itself would be here? If the = former, >>>>> wouldn=92t this configuration be better grouped with the = routing >>>>> protocol themselves? >>>> I am not sure I understand the question but data models for = individual >>>> routing protocols will be defined in separate YANG modules and will >>>> augment the "routing-protocol" list, both in configuration and = state >>>> data. So, configuration parameters for a routing protocol will >>>> eventually appear under "routing-protocol" but will be defined >>>> separately. >>>>=20 >>>>> In section 9, the placement of the router advertisement >>>>> configuration seems rather arbitrary and I would have = expected >>>>> it to be grouped with the other interface configuration in = RFC >>>>> 7277. I guess placement here is the consensus of the netmod = WG. >>>> The advertisements should be sent only by routers, so I think it is >>>> appropriate to have it as a part of router interfaces' config and = state >>>> data. Quite often (even at IETF meetings) we can see misconfigured = hosts >>>> sending these advertisements. >>>>=20 >>>> Thanks, Lada >>>>=20 >>>>>=20 >>>>> Thanks, >>>>> Acee >>>>>=20 >>>>>=20 >>>> --=20 >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Oct 24 04:12:13 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9787E1A8A25 for ; Fri, 24 Oct 2014 04:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.74 X-Spam-Level: * X-Spam-Status: No, score=1.74 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 ZfulIpp4kOMP for ; Fri, 24 Oct 2014 04:11:34 -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 ED7931A038B for ; Fri, 24 Oct 2014 04:11:32 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNZ74586; Fri, 24 Oct 2014 11:11:31 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 24 Oct 2014 12:11:28 +0100 Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.104]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Fri, 24 Oct 2014 19:11:22 +0800 From: Yangang To: "Dana Blair (dblair)" Thread-Topic: =?gb2312?B?tPC4tDogU29tZSBjb21tZW50cyBhYm91dCBBQ0wgWUFORyBtb2RlbC4=?= Thread-Index: AQHP7GcJNvv6hgwmVkSOGKo7BQmMmZw6YA8QgABHUICABHNsoA== Date: Fri, 24 Oct 2014 11:11:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.111.72.210] Content-Type: multipart/mixed; boundary="_005_D496C972D1A13540A730720631EC73413A41B50Cnkgeml507mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Iny3KnLH2xbvpl_zpj2WCqYfhqE Cc: "netmod@ietf.org" Subject: [netmod] =?gb2312?b?tPC4tDogtPC4tDogU29tZSBjb21tZW50cyBhYm91dCBB?= =?gb2312?b?Q0wgWUFORyBtb2RlbC4=?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 24 Oct 2014 11:11:41 -0000 --_005_D496C972D1A13540A730720631EC73413A41B50Cnkgeml507mbschi_ Content-Type: multipart/alternative; boundary="_000_D496C972D1A13540A730720631EC73413A41B50Cnkgeml507mbschi_" --_000_D496C972D1A13540A730720631EC73413A41B50Cnkgeml507mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksDQoNCkkgdXBkYXRlIHRoZSBtb2RlbC4gIFBsZWFzZSBjaGVjayBhdHRhY2hlZCBmaWxlLCBJ IG1hcmsgbXkgbW9kaWZpY2F0aW9uIHdpdGggcmVkIGNvbG9yLg0KDQpBYm91dCB0aGUgdGhpcmQg aXNzdWVzLCBJIGNhbqGvdCBmaW5kIGEgbWV0aG9kIHRvIHJlcHJlc2VudCB0aGUgobBCb29sZWFu IGFsZ2VicmGhsSBpbiBhIHNob3J0IHRpbWUgYWZ0ZXIgSSBkaXNjdXNzIHNvbWVib2R5IGlzIGF0 IGhlcmUuIEluIG9yZGVyIHRvIG1ha2Ugc3VyZSBuZXcgZHJhZnQgY2FuIGJlIGRlbGl2ZXJlZCBv biB0aW1lLCBJIGp1c3QgZGVmaW5lIGEgc2ltcGxlIG1ldGhvZC4gUGxlYXNlIGNoZWNrIGl0Lg0K DQpUaGFua3MNCllhbmdhbmcuDQoNCreivP7IyzogRGFuYSBCbGFpciAoZGJsYWlyKSBbbWFpbHRv OmRibGFpckBjaXNjby5jb21dDQq3osvNyrG85DogMjAxNMTqMTDUwjIxyNUgMjI6MDMNCsrVvP7I yzogWWFuZ2FuZw0Ks63LzTogTGlzYSBIdWFuZyAoeWlodWFuKTsgRGVhbiBCb2dkYW5vdmljOyBL aXJhbiBBZ3JhaGFyYSBTcmVlbml2YXNhOyBCZW5vaXQgQ2xhaXNlIChiY2xhaXNlKTsgbmV0bW9k QGlldGYub3JnDQrW98ziOiBSZTogtPC4tDogU29tZSBjb21tZW50cyBhYm91dCBBQ0wgWUFORyBt b2RlbC4NCg0KRnJvbTogWWFuZ2FuZyA8eWFuZ2FuZ0BodWF3ZWkuY29tPG1haWx0bzp5YW5nYW5n QGh1YXdlaS5jb20+Pg0KRGF0ZTogVHVlc2RheSwgT2N0b2JlciAyMSwgMjAxNCBhdCA3OjAzIEFN DQpUbzogQ2lzY28gRW1wbG95ZWUgPGRibGFpckBjaXNjby5jb208bWFpbHRvOmRibGFpckBjaXNj by5jb20+Pg0KQ2M6ICJMaXNhIEh1YW5nICh5aWh1YW4pIiA8eWlodWFuQGNpc2NvLmNvbTxtYWls dG86eWlodWFuQGNpc2NvLmNvbT4+LCBEZWFuIEJvZ2Rhbm92aWMgPGRlYW5iQGp1bmlwZXIubmV0 PG1haWx0bzpkZWFuYkBqdW5pcGVyLm5ldD4+LCBLaXJhbiBBZ3JhaGFyYSBTcmVlbml2YXNhIDxr a291c2hpa0BCcm9jYWRlLmNvbTxtYWlsdG86a2tvdXNoaWtAQnJvY2FkZS5jb20+PiwgIkJlbm9p dCBDbGFpc2UgKGJjbGFpc2UpIiA8YmNsYWlzZUBjaXNjby5jb208bWFpbHRvOmJjbGFpc2VAY2lz Y28uY29tPj4sICJuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4iIDxuZXRt b2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4+DQpTdWJqZWN0OiC08Li0OiBTb21l IGNvbW1lbnRzIGFib3V0IEFDTCBZQU5HIG1vZGVsLg0KDQpIaSwNCiAyLiAgICAgIEluIHBhY2tl dC1maWVsZHMgbW9kdWxlLCBJdCBsb29rcyB0aGUgY3VycmVudCBkZWZpbml0aW9uIGlzIG5vdCBz byBzdWZmaWNpZW50LiBGb3IgZXhhbXBsZSwgbm8gIiE9IiBkZWZpbml0aW9uLCBhbmQgbm8gbWFz ayBpbiBhY2wtaXB2NC1oZWFkZXItZmllbGRzIGdyb3VwLCBldGOhrS4uDQoNCkRMQjogIG5vIKGw bm90obEgZGVmaW5pdGlvbi4gICBUaGlzIGlzIGEgZ29vZCBjYXRjaC4gIEZlZWwgZnJlZSB0byBw cm9wb3NlIGFuIGF1Z21lbnRhdGlvbiBvciBjaGFuZ2UgdG8gdGhlIGV4aXN0aW5nIG1vZGVsLg0K DQpZYW5nYW5nOiBPSywgSSB3aWxsIGRvIGl0LCBJIHRyeSB0byBwcm92aWRlIGRhdGEgYXMgc29v biBhcyBwb3NzaWJsZS4NCg0KR3JlYXQuDQoNCg0KMy4gICAgICBJbiB0aGlzIGRyYWZ0LCB0aGVy ZSBpcyBhY2wtdHlwZSBhbmQgYWNlLXR5cGUuIEl0IGxvb2tzIHRoZSBJUCBwYWNrZXQgbWF0Y2gg YW5kIEV0aGVybmV0IHBhY2tldCBtYXRjaCBjYW4gYmUgY29uZmlndXJlZCB0b2dldGhlci4gQnV0 IGl0IGxvb2tzIG9ubHkgIk9SIiByZWxhdGlvbnNoaXAgaXMgYXQgdGhlcmUsIG5vICJBTkQiIHJl bGF0aW9uc2hpcC4NCg0KRExCOiAgICAgV2hhdCBraW5kIG9mIKGwQU5EobEgcmVsYXRpb25zaGlw IGFyZSB5b3UgZXhwZWN0aW5nID8NCllhbmdhbmc6IEkgcmVtZW1iZXIgd2UgZ290IG9uZSByZXF1 aXJlbWVudCBmcm9tIHRoZSBlbmQgdXNlcjogVGhleSB3YW50IHRoZSBBQ0wgdG8gY2hlY2sgdGhl IEwyIE1BQyBhZGRyZXNzIGFuZCBMMyBJUCBhZGRyZXNzIHRvZ2V0aGVyLiBBdCB0aGlzIHRpbWUs IHRoZSByZWxhdGlvbnNoaXAgb2YgUlVMRXMgaXMgobBBTkShsSwgbm90IKGwT1KhsS4NCg0KU28g ZG8gdGhleSB3YW50IHRvIGRvIHRoaXM6DQptYXRjaCAoKElQIGFkZHJlc3MgPT0gMS4xLjEuMSkg QU5EIChNQUMgYWRkcmVzcyA9PSAweEFCQ0RFRikpIHBlcm1pdA0KDQpvciB0aGlzOg0KDQptYXRj aCAoKElQIGFkZHJlc3MgPT0gMS4xLjEuMSkgT1IgKE1BQyBhZGRyZXNzID09IDB4QUJDREVGKSkg cGVybWl0DQoNCm9yIHNvbWV0aGluZyBlbHNlID8NCg0KdGhhbmtzLA0KRGFuYQ0KDQoNCg0KDQpU aGFua3MNCllhbmdhbmcuDQoNCreivP7IyzogRGFuYSBCbGFpciAoZGJsYWlyKSBbbWFpbHRvOmRi bGFpckBjaXNjby5jb21dDQq3osvNyrG85DogMjAxNMTqMTDUwjIwyNUgMjE6MDkNCsrVvP7Iyzog WWFuZ2FuZw0Ks63LzTogRGFuYSBCbGFpciAoZGJsYWlyKTsgTGlzYSBIdWFuZyAoeWlodWFuKTsg RGVhbiBCb2dkYW5vdmljOyBLaXJhbiBBZ3JhaGFyYSBTcmVlbml2YXNhOyBCZW5vaXQgQ2xhaXNl IChiY2xhaXNlKTsgbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQrW98zi OiBSRTogU29tZSBjb21tZW50cyBhYm91dCBBQ0wgWUFORyBtb2RlbC4NCg0KVGhlIGRyYWZ0IGF1 dGhvcnMgbWV0IGFuZCBoZXJlIGlzIHRoZSByZXNwb25zZS4gIExvb2sgZm9yIERMQjoNClRoZSBj b21tZW50cyBtZW50aW9uIGNvbXBpbGFibGUgb3B0aW9uIHdoaWNoIG1lYW5zIHRoZSBwcm9wb3Nh bCBjb21waWxlcyB3aXRoIHB5YW5nIC0taWV0ZiBvcHRpb24uDQoNCkhpLA0KDQpJIGFtIHJldmll d2luZyB0aGUgQUNMIFlBTkcgbW9kZWwuIEFuZCBJIGdvdCBzb21lIGRvdWJ0cywgbWF5YmUgc29t ZWJvZHkgY2FuIGhlbHAgbWUgdG8gdW5kZXJzdGFuZCBpdC4NCg0KDQoxLiAgICAgIFRoZXJlIGlz IG9uZSBmaWVsZDogdGFyZ2V0cy4gSW4gbXkgdW5kZXJzdGFuZGluZywgbWF5YmUgaXQgaXMgdXNl ZCB0byByZWNvcmQgd2hvIHJlZmVyZW5jZSB0aGlzIEFDTC4gSSBkb26hr3Qga25vdyBpZiBJcyBp dCBtYW5kYXRvcnkgb3Igbm90LiBPciBteSB1bmRlcnN0YW5kaW5nIGlzIHdyb25nLg0KDQpETEI6 ICBZb3VyIHVuZGVyc3RhbmQgaXMgY29ycmVjdC4gIEl0oa9zIG5vdCBtYW5kYXRvcnkuICAgVG8g bW92ZSBiZXlvbmQganVzdCB1c2luZyBzdHJpbmcsIHdlIG5lZWQgYSBjb21waWxhYmxlIGF1Z21l bnRhdGlvbi4gIFNpbmNlIEFDTHMgY2FuIGJlDQphcHBsaWVkIHRvIGludGVyZmFjZXMsIHRoYXQg bWlnaHQgYmUgYSBnb29kIHBsYWNlIHRvIHN0YXJ0Lg0KDQoNCjIuICAgICAgSW4gcGFja2V0LWZp ZWxkcyBtb2R1bGUsIEl0IGxvb2tzIHRoZSBjdXJyZW50IGRlZmluaXRpb24gaXMgbm90IHNvIHN1 ZmZpY2llbnQuIEZvciBleGFtcGxlLCBubyAiIT0iIGRlZmluaXRpb24sIGFuZCBubyBtYXNrIGlu IGFjbC1pcHY0LWhlYWRlci1maWVsZHMgZ3JvdXAsIGV0Y6GtLi4NCg0KRExCOiAgbm8gobBub3Sh sSBkZWZpbml0aW9uLiAgIFRoaXMgaXMgYSBnb29kIGNhdGNoLiAgRmVlbCBmcmVlIHRvIHByb3Bv c2UgYW4gYXVnbWVudGF0aW9uIG9yIGNoYW5nZSB0byB0aGUgZXhpc3RpbmcgbW9kZWwuDQoNCg0K DQozLiAgICAgIEluIHRoaXMgZHJhZnQsIHRoZXJlIGlzIGFjbC10eXBlIGFuZCBhY2UtdHlwZS4g SXQgbG9va3MgdGhlIElQIHBhY2tldCBtYXRjaCBhbmQgRXRoZXJuZXQgcGFja2V0IG1hdGNoIGNh biBiZSBjb25maWd1cmVkIHRvZ2V0aGVyLiBCdXQgaXQgbG9va3Mgb25seSAiT1IiIHJlbGF0aW9u c2hpcCBpcyBhdCB0aGVyZSwgbm8gIkFORCIgcmVsYXRpb25zaGlwLg0KDQpETEI6ICAgICBXaGF0 IGtpbmQgb2YgobBBTkShsSByZWxhdGlvbnNoaXAgYXJlIHlvdSBleHBlY3RpbmcgPw0KDQoNCg0K dGhhbmtzLA0KDQpEYW5hIEJsYWlyDQoNCg0KDQoNCg0KVGhhbmtzDQpZYW5nYW5nDQo= --_000_D496C972D1A13540A730720631EC73413A41B50Cnkgeml507mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi,

 = ;

I update t= he model.  Please check attached file, I mark my modification with red= color.

 = ;

About the = third issues, I can=A1=AFt find a method to represent the =A1=B0Boolean alg= ebra=A1=B1 in a short time after I discuss somebody is at here. In order to make sure new draft can be delivered on time, I just define a simple me= thod. Please check it.

 = ;

Thanks

Yangang.

 = ;

=B7=A2=BC=FE=C8=CB: Dana Bl= air (dblair) [mailto:dblair@cisco.com]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA10=D4=C221=C8=D5 22:03
=CA=D5=BC=FE=C8=CB: Yangang
=B3=AD=CB=CD: Lisa Huang (yihuan); Dean Bogdanovic; Kiran Agrahara Sreenivasa; Benoit C= laise (bclaise); netmod@ietf.org
=D6=F7=CC=E2: Re: =B4=F0=B8=B4: Some comments about ACL YAN= G model.

 

From: Yangang <yangang@huawei.com>

Date: Tuesday, October 21, 201= 4 at 7:03 AM
To: Cisco Employee <dblair@ci= sco.com>
Cc: "Lisa Huang (yihuan)" <yihuan@cisco.com>, Dean Bogdanovic <deanb@juniper.net>, Kiran Agrahara Sreenivasa <kkoushik@Brocade.com>, "Benoit Claise (bclaise)" <bclaise@cisco.com>, "netm= od@ietf.org" <netmod@ietf.or= g>
Subject: =B4=F0=B8=B4: Some comments about ACL YANG model.

 <= /o:p>

Hi,

 2.      In packet-fields module, It looks the current= definition is not so sufficient. For example, no "!=3D" definiti= on, and no mask in acl-ipv4-header-fields group, etc=A1=AD..

DLB:  no =A1=B0not=A1=B1 definition.  = This is a good catch.  Feel free to propose an augmentation or change= to the existing model.=

Yangang: OK, I will do it, I tr= y to provide data as soon as possible.

 <= /o:p>

Great.<= /o:p>

 <= /o:p>

= 3.      In this draft, there is acl-type and ace-type= . It looks the IP packet match and Ethernet packet match can be configured = together. But it looks only "OR" relationship is at there, no "AND" relationship.

= DLB:     What kind of =A1=B0AND=A1=B1 rela= tionship are you expecting ?

Yangang: I r= emember we got one requirement from the end user: They want the ACL to chec= k the L2 MAC address and L3 IP address together. At this time, the relationship of RULEs is =A1=B0AND=A1=B1, not =A1=B0OR=A1=B1.

 <= /o:p>

So do they w= ant to do this:

match ((IP a= ddress =3D=3D 1.1.1.1) AND (MAC address =3D=3D 0xABCDEF)) permit=

 <= /o:p>

or this:

 <= /o:p>

match ((IP a= ddress =3D=3D 1.1.1.1) OR (MAC address =3D=3D 0xABCDEF)) permit<= /span>

 <= /o:p>

or something= else ?

 <= /o:p>

thanks,=

Dana

 <= /o:p>

 <= /o:p>

 

 

Thanks

Yangang.

 

=B7=A2=BC=FE=C8=CB: Dana Blair (dblair) [= mailto:dblair@cisco.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA10=D4=C22= 0=C8=D5 21:09
=CA=D5=BC=FE=C8=CB: Yangang
=B3=AD=CB=CD: Dana Blair (dblair); Lisa Huang (yihuan); Dean Bogdanovic; Kiran Agrahara= Sreenivasa; Benoit Claise (bclaise); netmod@ietf.org
=D6=F7=CC=E2: RE: Some comments about ACL YANG model.

 

The draft authors met a= nd here is the response.  Look for DLB:

The comments mention co= mpilable option which means the proposal compiles with pyang --ietf option.=

 

Hi,

 

I am reviewing the ACL = YANG model. And I got some doubts, maybe somebody can help me to understand= it.

 

1.      There is one field: targets. In my understand= ing, maybe it is used to record who reference this ACL. I don=A1=AFt know i= f Is it mandatory or not. Or my understanding is wrong.

 

DLB:  Your underst= and is correct.  It=A1=AFs not mandatory.   To move beyond just u= sing string, we need a compilable augmentation.  Since ACLs can be

applied to interfaces, = that might be a good place to start.    

 

2.      In packet-fields module, It looks the current= definition is not so sufficient. For example, no "!=3D" definiti= on, and no mask in acl-ipv4-header-fields group, etc=A1=AD..

DLB:  no =A1=B0not=A1=B1 definition.  = This is a good catch.  Feel free to propose an augmentation or change= to the existing model.=

 

= 3.      In this draft, there is acl-type and ace-type= . It looks the IP packet match and Ethernet packet match can be configured = together. But it looks only "OR" relationship is at there, no "AND" relationship.

= DLB:     What kind of =A1=B0AND=A1=B1 rela= tionship are you expecting ?

=  

= thanks,

= Dana Blair

=  

=  

 

Thanks

Yangang

--_000_D496C972D1A13540A730720631EC73413A41B50Cnkgeml507mbschi_-- --_005_D496C972D1A13540A730720631EC73413A41B50Cnkgeml507mbschi_ Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="ACL model update.docx" Content-Description: ACL model update.docx Content-Disposition: attachment; filename="ACL model update.docx"; size=66451; creation-date="Fri, 24 Oct 2014 09:47:47 GMT"; modification-date="Fri, 24 Oct 2014 10:58:02 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQCMimiR9gEAAOIKAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADE Vstu2zAQvBfoPwi8FhadFCiKwnIOfRzbAHWBXmlyZTMRHyDXSfz3XUmRGtiO5JoQehEgCDs7nJld cXHzZKrsAULUzhbsKp+zDKx0SttNwX6tvs0+siyisEpUzkLB9hDZzfLtm8Vq7yFmVG1jwbaI/hPn UW7BiJg7D5a+lC4YgfQaNtwLeS82wK/n8w9cOotgcYY1BlsufhCBoBVktyLgd2GoD390QfHSObQO IeYEx7LPbV3dumDC+0pLgUScP1h10HTmylJLUE7uDLXKazgfnIQY6WimynvodzU0P01C7iI689tU XCOY2+B8vEqm0oPWeBBQQ+w4fIFS7CrMvj6RPq0ldx42ByfXplay+UC8T9QEqOJBzYhaz/bkVNko GrfaD7EatmNA0cbW3pVhmAtc7ZGN0LZT9dV42Z1ZQ6A8JHt6FK8eepRExH01RcBb3NH2YNVEE9Yh D1Egv5qp4pTPZBOgnhoFakaDfjBYr0YgAiIFYIIF0yEPHb9fchCuk49/lMF6xUE4s//7/9G/t7/d ickUWph/8b/VKH2pXyo+0h8TePNMJ9HAjPq9BaEmyVsLfGb/CfJ2Zv+SbhErsa4gOW4nTH+GHhXh EdY/J1s9L8BHibSipWfvSItxN/5OvwsXmNHdWSRVnxh53txQl38AAAD//wMAUEsDBBQABgAIAAAA IQCZVX4FBAEAAOECAAALAAgCX3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArJLPSsNAEMbvgu+wzL2ZtIqINOlF hN5E4gMMu9MkmP3D7lTbt3ctiAZq0oPHnfnmm9987HpzsIN655h67ypYFiUodtqb3rUVvDZPi3tQ ScgZGrzjCo6cYFNfX61feCDJQ6nrQ1LZxaUKOpHwgJh0x5ZS4QO73Nn5aEnyM7YYSL9Ry7gqyzuM vz2gHnmqrakgbs0NqOYY8uZ5b7/b9Zofvd5bdnJmBfJB2Bk2ixAzW5Q+X6Maii1LBcbr51xOSCEU GRvwPNHqcqK/r0XLQoaEUPvI0zxfiimg5eVA8xGNFT/pfPhoMEd0ynaK5vY/afQ+ibcz8Zw030g4 +pj1JwAAAP//AwBQSwMEFAAGAAgAAAAhAG8BpR95AQAAUggAABwACAF3b3JkL19yZWxzL2RvY3Vt ZW50LnhtbC5yZWxzIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArFbLTsMwELwj 8Q+R78R1C+Whpr0gpF6hSFzdZPMQiR3ZW6B/z9KqadpG5rKXSDtRdiazs05mi5+mjr7A+cqaRKh4 JCIwqc0qUyTiffVy8yAij9pkurYGErEFLxbz66vZK9Qa6SFfVq2PqIvxiSgR2ycpfVpCo31sWzB0 J7eu0UilK2Sr009dgByPRlPp+j3E/KRntMwS4ZYZ8a+2LTH/39vmeZXCs003DRgcoJAl6AwcddSu AKSeu1rFJFLIYX414RSQW4t9Aft6EhLAyu9xW9MEOwP2dYj+nvP1wWSGDOgJOCAhCWrMqWE4A8ER sPKbTbMGR/t1nEIHBV3gNCHdeLTNB8W+i0Icyw6VFUITXIspp5q/LTjLRQcFLVHcKi53cxwScMfJ /w3rN0CkZPT2oweGhChWJUjHNxyTsSvl7hrMhKKPB99ZPXxUBgXccvL7i1kckNAgHjklDB9VwUQq Vg9ya3Cl13UvDB10cEGe/AnMfwEAAP//AwBQSwMEFAAGAAgAAAAhAJO1x6hHHAAAu44CABEAAAB3 b3JkL2RvY3VtZW50LnhtbOxd63LbRpb+v1X7Dl34ZVeFEiUrcsKJMJYlOZvdxFbJ3krNzxbQFBGD AAcAxchTWzUPsvty8yR7ugFQuBItCpdu6KSSyAJpsi+nz/nOdy7901//XLrkngWh43tnxtHB1CDM s3zb8e7OjP/+8mHyg0HCiHo2dX2PnRkPLDT+av77v/20mdm+tV4yLyLwEV44u4dXF1G0mh0ehtaC LWl44K+YBy/O/WBJI/g1uDtc0uDrejWx/OWKRs6t4zrRw+HxdHpqJB/jnxnrwJslHzFZOlbgh/48 4n9l5s/njsWSH+nfCGS+N/6bl8mQxTceBsyFMfheuHBWYfppy30/Daa4SD/kftck7pdu+r7NSubb 7IBuYD+WbjzsjR/Yq8C3WBjC08v4xe0nHk13fXeygPwjtn9DZgj570xHsqSOt/0YLh2F/d9u3gFs 3mH83Yf8ox4nAmthgizd+vYD/7kimxnIon1zZkynl6dvzqeXRvroGja69PCSzenajcqvXGceiU++ DviPIPnxwfeiED6ZhpbjnBkX/jpwWEA+sg3/vsW5F5afWmH+jYfmT4fJJ8LPVfLJlcPt8Ks3M3EC Z+GKWrAFq4CFLLhnhkkI4eOL4lGKNQh8f34VBDDE6GEFb74L6PJzRIPIgLnAVAYYu7n07bXLZEZ6 5dnDjZOrp4o1bhp3uGKuO/QSOyyaT6jlSg1WxVX+R27k/LAJcU7FNXPU00eoLB4VWkZP7VIWeqiL B+rdTRLAkpMKEIoq9aaiOB/9JTfyscjzWOYxjCGsMTBgxbUw4x5dMgFBcqKt0aE0mgauhCnnvhE3 57MVBewWzjgqAeeLa0XxXA8zbxqoAXO+Dbox+iMT8Lzmzp9NWoS7XCpikqZxK6H9tPBhTNRtqNs2 nKkAQJzwTfUUjR7ozlmu/CBq0hGo2/akDzlLx1Fd0wILJTyo9TAnwgHn9GFIkJZpiT7eDX50cQH1 BkB6+H+aaImR+nfKMUP/k7MYMgTckJ4mkPMLx4NgHaNhdB46NAuS+OB5CK1yEm8uTt5fvi2EAgsP MzPLvyJCgckjETeII3Ubx/Y3FxAHDHxXhL8iehvy1+EnjPSeumeGy+YR/9aVD7G/H49O4/hT3RuO fnhzvPsdx29Pftj9jjenpye733Hy/Q/T3e/4/uTHhpGenhw1jPTtm+OGkf5wfNIwUliwhpEeTadv G4Z6NP3xx4axHh39OG0Y7NExDHf3qh29eXvSNNyT0+/FcEFIU2mh68j/zGOvl1dCih5//xj/bv+x DqMb524R/eLZ4hHnSSF0D3LlOjxsfgzfm/xyA7HQM4N/RjzYluPVm1no0dUX/+fAiYdi+a4fpNL+ 4cMU/om/OPyWPk3XLfx2wSPm4lzEz2AVxPjSo1tSj5lDp8VEduGwnKaFmYqAeYvZBLC0ZeXYzX7t mGZhlqWQWpEGKr1hd0qBhgJhcl/HZk/0zSrXpc5z03BVaqJVBfHR/JCYQTkzhStLkaEUZxhouHXm ZGy7lMnjK05tBLvF9Y8M1ZKIYuWM04eIkWElBJhHjFzybxAjC9a+G8z1EjByUfm+CIisPyCowXLP jUzpCI24rS1I8QtF8syD4o5A1Ecg+MiygEjQFWhRJOh46URLBSUIPmAx65nGHcxVyVxpTj7UWeWC eRox/GjMe36BZCQ3ywUJKAGUfJZI6eVdWToaYraac1JYJM2VgXn+8bI4o5TT0ZeIlEiURFLrMf6M gd9iRB4Dv7KFyogr98eViCx5ge14oAHiynz6BjhVJuJKkR2UZrTU+5lFFKY3x21+uilO6CXCSgyL Yli0Nu0Tw6JxT5xS5i5iyn0xZVHn6m1EahiYIswaMVMpkYaPRAYSGYAqa0oLkMhAIqOVVPx6xwVZ DE1ZDPPp1mW3P5P0VeSgI21a2HUdQ+pXp1lw/Kf4/tTbzOxN+igX10gf7p5ZhqNKZoZFXnyZ68wO FnlVlPkdYZEXFnkl9V0vwjErZQi8wLwKLPLiZai89DM11fVIkldFja2GCLp3W4siLZOCjhwSaVsl xBXBHVTlwgaaEyweKuYMYP4u5u9igX2+331FZ/tuyP16o1Jii9vWs6DM1auvHzEnXjCmJZA5zkYB MrMefxsALB6q4fkRfCD4QPChHvjA4EiGgG8beXXp4dblHpQ2tIQ/XiDJhUmekgxXE4oryo7+MN50 G7s758vKRjBlLD/KNLdEZIrIFJGpisi0BGU0r2Wtg2wFo6u/gZGcKCJTLD+Sjr0WDkmj7Oh/ikz2 d6lJj4hVlblBCPPJMZ+8PrEP88kxn7zzfHJ+L83LDNs2mt3SG8YX7UQyEcnEqjxhnnZ2h2Qi1jeI sE9d5QH2MirmJSJkQ8jWB2QrONNIJsYroHT/Vvm0yRLwLIYqS29AZAq1iIHvz68CTpbxhPkz40X2 yCytQlF2RkAmesgmYunt7nsAEZoiNL3IB4IXCE27h6YITEfVZLNEDTfCi9IbEJq+WGgaUO+OPT1B D9uDgAuD99vdwiqU7+/GRo7YyHGf663l2Rck0/Qm08jTW23lekOA2hF3A6MZQjNU23QLzRBesxq3 2tn3pjP0lLX0lPdo5Bhbl6Rho5x16ba7Y6ZB1M5ejoUhN80j//ZrXoza+zzAdqcrnBtuB+WwzT22 KlLrnkiPZNYvaLG9Z0YAeKaPs1z5QWO2z65wWi/jrCnFWFHrK4smc4e5dihzzW1eTm9ycpIKTwb8 5d+OYi0yRnUR7VXA5s6fBVtbeQjrSg+GFG0jJ9uGBJWWF1aU7UwIKK/0apQJl2sJ/1HDZa7s1qzh PNDCe6FzZhSCmxXN3zL4xPSDO+o538RN8E9Qhigz5COL+VbZ4HFm1XeoGEKMX66+fCAfr7789umS vIKfF58+fiCXNKLkN99mruPdkV8hfrKmd+w1+d0PvvInPwf+ejVSO4DC1pGwyRz4zxENojilZggH yrR8L6LWU3wQFJeOxAV00+8/k9/Z7Ywsomg1OzyMfN8NDxwWzQ/AkBxu7g49Fi19+zAnWbghnW0I 7MevThjNSLzu79KtGOX6oxx1KUcXC+oEM/KfaxbcMY98thY+8zYUuBMWjFKclPMXCPnjIMwu+7s/ qOXfhpO159wzCD1GDwc2G+Ve4NHu4Wh/8ZfkI7UZXY9ShhQ8z5Enlvudu7Yc+94JHd87sPzlKJcf j3BnR/jKdiIfbPMlox5579/Z1PPvHWuUYqTgKQaN6d2++wOs8IoFB4C0R7nweH47P7//5UDiMzmH eOmCBpR8DhgDZEdDOkqBUvAkf/3qr8OF8/XdbeBbYJrRGKeJGBjeBv2XZFJEO/n51BgD70LJf6yB icfTG1pOOfIkXVYnu/IPzgKW+53lhJaPJxdPrrDX0sF7QtKTe0k9St67QHfhye3n5Nq3fLUfTy4G Kk/fnE8vDbS6cro/d05rqiaHDlTaLLQCZxUBxyMz3CSrDL2uzrwu48vCCcnfzj/+TCAkCbfaEhtS /jwWEkqAhFv5HvMiEi1oBC/wvbvliRTRYpwMu4LemMwxGfpUQ/rB3LlbB09NkFJquf05ObcsFobk ArIpAt8VQeOQvDq/+DV8fYDWGK0xJLNJI2kdzm3A4nCLzFhVTPA+nh6dTI6m8C/5R24OCBg6Awy5 dR4VylTKGhkXAQNzCljrloaMYzPmkrkfFJuNl4oxGhrW9VKPYcaJVk2isvM2tX4GOlazPogsuzSM bpgHqVDMvobE6/cgwl/BYO5oHiGqoZrkZHcPpH4EBQqhYFqelfd7avQfuq2F+orWWW7Isr35cEFO p8fTWey9Tsh5Tf6/UJvosW5mtB8ekwD2iDZQcsEdqUe/kFwHfuRDD71tvcbrkfpUgyjfXfE4LMlD InlkrqtjAy8Jub4y2EFF17Vp3ErAeGq5UuMcdIHNifCQkADoybw3SYQKaH2/MJNSdtt4z/3+psVG NcGClOraXcRdk67E7zoQDgJ1XQJMPxEPYusCPVGCEBmCnhwHBKkIUhGkKmWDtLA+zmqiBU6tMUCI WxG3pinVJvdkmg6dqo3kjKaBq4JVZ1qoi9itRYa0L9a6SXrRrX1a06wac2e49AFctjdbXwslvB8J H6d7pRRchmC2DlpEd+qcRYtJ0zqrgjWkxjkofV6jp9EtQbcE3ZJ8D/ZkPYKW7knOVPWY4JKgW5Ip 9sI+4SIzTg9AMYZoW+yWHKNbMutAvdVgDC7i43RLsP4gDcq2nPkphacz5XCl9HgVaBweYoYqS6m5 bH2DyplsXx2i63DNqZaaVmaLhhg6x1tS4xx0gc2JSEZAVwxdsa0rxiWiSXJVjRA1jVsJ0iZlx6Dg Q2q8g2qIGhWMGqMnjaGHf4ZRZaPbC+x0gRNcEDDe1k+8bayurWoRN02CbvtxZMgjdMQjcOopbn0U 53uHZB0ym0Q+EYW+/A+8CW25H0wOE+L2dLg9vO/Oa5GOjyarH5OFXCxm4LeYgV905ysZzKGJQORi 3aG3QBMuFoABQWKlJ2IlB7NquqwMLbdIxXbMqriMzpGGvblkc7p2o7PHZKSkI/ILSpLZt7WUHgTt ikYLGY2nYqzByF9jWqGrizhwqIAvJNjx9q5NCy2GO+hKmxMXrisNcWG9KARV1x7kiBdWp3XVIkvB o0sMK7QppzVhXU5aYliht4VuMhQqpJLtF1ZQKoZTQcPfPhCbRjTuehuK2wdym4G8e2e8e26dK8Cc CkLvMWbLjHNQEFejw9MIE28la/MYU9NEVEHPUuMcdMVNjBO1iJVr5He8CASNSkdGpUlzqGBS4Aab iMK1R/nL7mrs36BaruZcxtxGTBxgmKIfPagHubifi4DasCNtyA2okSQWca3DL5oSdN+BDnqyALF2 K8ixyNBY5qGU28/PgR4KlJ9OmbOpOCxAVNAXKtBDrL8ybJ6fXmbfQc27LjUhPHjzl5x6Q3PXIfTL rXQNfBo6sSnjMZDGrp6ZYlMUnA4Fh5Bzj8RevvAXyKsmUULmWPZuAPM1gUuwgYz3A3F5XbzAfr4A GKW7U+lukmYVWEK5BKKMRlTK4+J+DIFbkwIHbnd/RS32+oBcUWsBWoWRBYUDkNsDlPcXL+8h+/v6 iXdeKiXx3np5CzYAYq7QbgfYfcgkYLGO/06oeJT3vm6E1MMlLlj8GniuIs+zpBEocitwIhY49DvA MpBckMIYUPCR43thnmFG/d6pfv/sQIYHVzgBIxT+C9k9C6hLvjqeHRJ/rk3ix5MSplGoOhWqnMGq UE9Fl0/JkktnuXLZEoAoNMFrzOPKZ+NXzkdFfbxxogWxnbm4NDwiNALUfbuOAHjP/XyOAZ6YQU+M Cm4lAyes6WSr6lRyoPEo5yDchM+G3DPP9oPvwP45efuB4v7ixX3p26yxrkVVeW86p0ULPFCxm+XD KlOwN1LjVdGCWusw8pfON8e7GydUVoopQVTSW1mRLmkvOqMS7mQLDqQASJABaa+YtiYRWaR1if8V cgXHgvzGMg+l7E8qNU1wRQV3jbclkRmniqiqadyKwNdG9yBPCw0Csic8cwqTKvtLqtQjhqRzV6gQ WErvDrMBewRJTQpZBYOXyQeUGa6Kdg+aDDAiFDZE3jK1cugQ9Cjr55CGce9AVPS3879Bn2WubaxI 5GS4zLuDgAknk++pu4YkjTzCQsz94lnjUiShIvypKmnMFc93ZOWHoXPrPpBwxTPuuLADjLUcmke7 KOvPkPX9+wTqgS6tBQ0gm4cFjcS+qmeB58J4PoTEXdffMPtgpCyRkuwKNnjHBu9PaPCuS6QCCbmO GzFr0qFdXOWCLdp79Ohk6IChqxl1JuSa1hfpeukSP3GXLlKbqBz4mdpepzsKahOuBOYFBXBfFjpT /YWj0JlCZ2qEzpT2nRARM1mOc2Zc+Gso9A6ewaVG5kSLtfRXzW07VcgXES3N0T1VCIEW3afK8rKh /VdQyHPnTuokbiPvlRPZvjpEulRNtuicuuFI209hHO85tqdGXtI8UT2idWPwLj+JsnWXe5eEW1rK WwlAHTu3Zuhu9udu6iHxOodiRA+NieWvoTI9wMTePkVbD+HWOZLgsGg+S2T79AR58B69ED2EewxY 5YsfATJJeiFxPc67bSAv3vItmo3QHJlxZMafyIzroSM5uhVX7DSxMaomX0Y0uGOgDpCFRPt/aHIp 3kbCdQa3WLfW9k3ZjTZeD4U9BlD7K2/bDOkdqe7eiJaSnI7jPctXK9dhNhJxfbIV48S3WLHwE5SU XQcd5lLzkBD/AgwNdRgaksHmCsR0R3Pd6CS9UgCdih6dCh2kfAzoi/cNyPQL2Ar7Nk2OJH/KF2Si hu9Qw+tSl5a/T0WjenVxU0y+UYYQ/IdX5xdXr8dasotnFs+sOZLLXuPjijxvn7SALmZJ44tfg7XL RN89TGBozdd4TssUXUQ+uddxcqvtlcfrkAXjFHqEXR3DLgzV9BQdM9JQTfaa3oQdE54ThmkQj7Fi Zoypc870FpChq9G3aOuh1jGtBOKqoWPfXLI5XbvRmTGdXp5m8wOvM4947LGfEKSS0d60uguDGyHp 4T4a4wouA38QbZHHyukqLOYSWSRvLk7eX741QBaKKiT/Sg8qBMawcDxQX4yG0XnoUCOTP8hduNq8 htOjt1cnj5O4Dri+y48/qxzzbxczSx5llCO/3mczmztBGP0K93pfQFfU8Mw4mk75Wm0fnxnHR1M+ Tli/JK/jg9+KL7CBUhoXSgs2M2hXfWZ8+DCFf6pWpCR/ycSHGNNmFnWe1jfs9J4NpYcdfs3uFKxh oXq/oyFXnvdGsQcRM6G3dXHEA0l7qX9J67ld+69SwFxRSR0unFVxueBThb7Pqcq213D/oYtOeoOM WajyBs1br+Uk8pPyxucmtwHprmSAfP7tNbYKTQ8X3TrTM4gc7S37Kmno5x2G1NWKfxZ2obJ9TH3O ZEcmSHKC5nMphmGHv5dIZRBx6+ol9Ojqi/9z4Ni7NmAzC7/BMRLw9/gkBtnhtwvut2aegWOQjC8y BVWYNXvK2xFTIuCWNwFoMbyw3HvOAt8s245ul1xlJKbmZOQ1F4E7hUIrcFa8LQ0xCopMcaxcPUMA GODTinuRitNpGwRK7oT5r3/+7/nHy3/98/+6HlDblhl89K6H/IQ17Hooe6+e+emm67HJL5N2QpY1 auSWRRvGPHF8IVs2nxauGB1kygSk0cLt1UdVhiup1v+lwJ6WVqykd0E5dc9qSGqZuoV/xBYS7Hzl wcjH9hqI7eTN3Kr3E/XDXCvMtQKKdlu8VDD6lX6/im1jRYsnhn1MeggSP6rENqiijMZrmbjIOI5m xiXUVcKNxAtMmpkFDvSkhKCrBCOR0Fmpuc3Q1flXBF2d4b4SCzRoaLXSgUl3lhuv2ihzfm6NPEz+ 7SouhQySSVdEMbeiGV2BKpE5mMpSzs9N2cwcu5bV4DPcjsKOKO51VMWZU52Xi9sNxZlNNFvPuP1x RTClH0GQ0Xf1YUSJ2G5e5bdjIfo+vHopfL0OQJ3VGmQWzzsNBcxemEGll6esqa1QSJUTqHNT0dSm t0AJmeo0ulsQtL7Srbqak7CIxTn1hzG6mtYo4u5ozTEqAUexJv26HigW/U4dwG3enBcUUqUxVNaa t8TMKWnUNUs+MTN5JtuLnQiHW/FlwlfxRQoFcVPqvJhSZUtoKno3FcNo2Ur2+BmE2DCzaM31kwhh F45GJlaQj2MLgjwTu+kgWl25eUXqv0R0Z8bUMheTfrUslODUjAjkpw5Cpqw3fRTzkvmlzaYI5F9R NCqRLgyfcFJVVzm/DnjX9Kt37EkOKxVs1xOhUi+yZVoL3ylVTFWOtI7h6GWcNewYFHsJdxLbP/Tf /uG5MbRe5GYUsfgvCSgGaZdCnHk9noQaCg+HtLUAMVJVqoEW5ypdC01Ow2Llq1Z6vGmNi7elF1zB ftRJqVq2tMRimCraSokYZUFH7IEXM7uQorN2Wx9opjj0UB3Q3bFYKFCSa1XvlFtR6yuLitkOpeEr oT3mDnPtcEYtV0rZDapFSt0L1FxSHRSyOVkwarNgEu+/RBIlKuIgzZSvqN5MbYCsHx475U1Hjiu4 +sBFxrB1x/SMwBtvWmUl9LAeSuOeQcESVBUjcGut2XhdG5Acbbf9pUmWVdAYLUU0e1FvNSSecSE4 SB72++WaJFKPRMcAxTUaGUrNyQ5ndX+Cir090vq5t0hsdb4WVN8I/PVHV3jCzwJ6SHG2aksNQvfz kAiRiNmja9q+a6oHS2jpb3NP0ea2Z3Of5kzpIeOjs6ynaFnRss6ClnGFJmF7BDSDkAiIIgcgLHUg K3VHkCxaIIAcBkDqIN4jAI9Ny6xE+O6RO5Ia7sBpFKA0EIMPjsERk/SOSXDJe1/yJn2oQsQarWQv wXYzsZJLFlGbRrRJNIbPW5a57wCjD+1FH8apnzk11UEhZObMvvDE9iZFooKN0b7DMLX4hSLYYbh3 /lIH6R5Dzl/S/SOWcwI36Eg3GEYI0B4E0CMoq3eNelKgtKCe7TreHRLI/RPIeij1OV27kcxQByU0 a5K4beY9jLOwCR2KtBRrcS55vd7T0w9lxH7o4qwxwK5rUS1LtsYoxl9YbNG7n6EJ8tI45ZNbJARb /YMtPST7uVdoZPjA7uqBd2AtlOwhJFsP2X5uz/ohZZstV9FIHQm1ukc+Vrxt/4QgnN8f33nQHu5W A2SCyLvlnPSndAMZZ+hTaQWDS965Ytkq8uQPOuhznVPCVyxYOhEi8e5NZlGy9cDhOvuYKNu+F/UC B8uyrYd0o5c5g/5cdkMD/YwvPeK8sXbar+iAV0YRBIpxC3qg6IG25JNoUQ+OHmhLuy3LtOCC97rg 41xuTL/pOP1GB9Q1gnx+NmlaaCVqq/lVjFIDHTQJ0ZzwkjZk3vpm3qQkI5OnV7ozQJHioLlzJzWV rZBXTmT76hBX0dTkhsypGzJMxH1zPr000nsB8a4rWcTedChUOL4jYWAgAQBuOgZrS3mlH3UJt2jG OE+uwoFpHSRe5zjSkkbWYmL5aw8K/BCw9Q3YMJQUWo5zZlz4671uIW+uZHFYNJ8l8n16gvq7V8qL x0510OBjwCwf18tbUOFwS4vQ6Swkcz8g1ONABnFL34p9nGSvskARl7tHvf4yF/v/BQAAAP//7FVf b4IwEP8qpF9AEAQxw4TotuxhC9FPgHBIE6RNW2Qu2XfflbLFBed8cMsexgPpXe/P7369Xm/ambhj tZJWO0tlRmlEFqwRFIT1BC1BbRnXcqjN5GfD0fxmhKESMceIynreVTPJ0wwiwgVIEHsgc+v9e9W2 ynh0f669OCYTkuariNj20ndje6nzd6pEnFAuoUibSg13kiNVF9nA6tFdu16shfcJTsLVCH4o9XdU /xP9Kz19Ac1B4N/G0yv1s/hLfXa6eAmZSj5w6vt4AQNrdNKmsetN4gXRF6eENAexggIE1Blg4erA carAHmpiiRnNIyIe8inBAfS1dW4mxZFDaBwKxtQF4R37vPkwvuOcR1RQIdURHmd8PsPA3jX2fLt+ QVLaiDhOaPu6wUpc+1O3p4RvH1N9Dopx1LuYBwVBtyUy7UxtW4sbphTboex5nVxBcbRrjiAiQRBq Y0NZRMKwC7VtFDKIp2bwZKzST0k/+73xxKhzlt0LmuOOOb6K1iB1NL1IqMoQtMZmnhHTPN3LsGH5 oVtghGYHtZq/AQAA//8DAFBLAwQUAAYACAAAACEACnvB4VQBAAD/AgAAEAAAAHdvcmQvZm9vdGVy My54bWycUstOwzAQvCPxD5HvrV0KFYqaVhUVJw6IxwcYx24s/JLtJPTvWecF5VBVXLzyjmdm17vr 7ZdWWcN9kNYUaDEnKOOG2VKaQ4He3x5n9ygLkZqSKmt4gY48oO3m+mrd5iL6DNgm5A0AVYwuxziw imsa5tZxA6CwXtMIV3/AmvrP2s2Y1Y5G+SGVjEd8Q8gKDTK2QLU3+SAx05J5G6yIiZJbISTjQxgZ /hLfnrm3rNbcxM4Re66gBmtCJV0Y1fR/1aDFahRpzjXRaDW+a90lbqWnLYxCq77s1vrSect4CJDd 9+CkuCDnvIcPTBIT45ISTj3HSjSVZpJJi/Fn/tPw5jA83HvjJPXTCPzFBtbIZW0O61e+FIiQ3fL2 bveAxtSeC1qr+AvpGM++C6/xqDg8bagqEKUIp6w0JaSE9CE+yVTYckUSgsEp8VLsTljfzTcAAAD/ /wMAUEsDBBQABgAIAAAAIQCSCNtKcQMAAPIJAAAQAAAAd29yZC9mb290ZXIyLnhtbLxWQU/UQBS+ m/gfmh48GJa2y7IL1V1c2IWYsEoA44VLaafsaNupM7Nb1xsxGj2IJ29yUBMTDcZ4MDF68M/gEv+F b2baYmHBRaIcmM70ve9773vvTffq3P0w0PqIMkyium5NmrqGIpd4ONqq67fWF0szusa4E3lOQCJU 1weI6XONixeuJrbPqQbeEbP78KLLeWwbBnO7KHTYJIlRBC99QkOHw5ZuGaFD7/bikkvC2OF4EweY D4yyaVb1FIbU9R6N7BSiFGKXEkZ8Llxs4vvYRemSedBxeJVni7i9EEVcMhoUBRADiVgXxyxDC/8W DVLsZiD905Loh0Fml8TjsHnUSaAUYaDCTgj1YkpcxBicttTLHNEyT+NOBRQQucc4IRQ5s0hCB0c5 jGiMI/XPizcJxTMUtyGgDhMBLRrQRnwzSJcVmj7c1hI7qevTpgntCBaDGAhil+tGajAPQNCzckdi MOk7QV0XmgRIeLAHdb0iH2LHBV8J45KAQMM4PU4EkCGpf0faDJYJuZuhmVbbPLTLY1ui2BO8W7Au kACsIdIpEakMrnBcni1bo46rpjxWEWSAME2JDXPorUK8ZnOqMt1cUAK5Mk83DcFN1bFq1ePqCMjU UMhyFC47aiHf6QVcEM2btVmrLYlixRCv8UGAwFSK6jgqAxx5cORjyvgyFgWfAnolY+rnB94aDmPp iiPGQWtt/XqnrW1c0y7d6xF+ZQB/pU7JUztNkhayblWnmmZLnatgIrJCCfEVEU0laJRNq1KyzFK5 Issoi0nl/zwIuYtVmVMBT5DRkp1SaLKzy2g2zdnqzJ9kBNxULIgWyqPyoYsk4gzU7eIIaoIcxpsM S93BIU/6x7Od/S9f97/v/vj4eP/7q+H2x0LyYHl2zInzQwxfvj/49ny482S4+/Dg7fbww+vh03fD F28KyCLxMWoxXa6Jqf0vtUjsk1o6se+4WftTvNWV9865Snewt1eQAwbp+LCsNJfUHBZGomrV2pWa bKy0E0aPRLVAANHmDLIrzt4aP199LkCm/cXFx9pm6l6NKWKI9pHemNBGGZ+xwR99OgKS5wDlyK6U G7c6Qqk1Tdu4rDWps4ld+dhpry61F2+udprrI26WcWWcKUTwD2QsTAJsOEytWNRXcMxL+7evwymX tqASN0xOCb/YGr8AAAD//wMAUEsDBBQABgAIAAAAIQDL9aDIGwUAAKQRAAAQAAAAd29yZC9oZWFk ZXIyLnhtbOxYzW4bNxC+F+g7LPZuS7ItR15EDmQ7dgLYrWE7zdGguFwtYS65IKkf5wEa9FCgp1xy KnrIsT330LdJ/RqdIbkryXJlxcqtPVg7S3Jmvvnn+vmLSSGiEdOGK9mNW5vNOGKSqpTLQTd+c3W8 0YkjY4lMiVCSdeNbZuIX+99+83yc5KmOgFuaZAQbubVl0mgYmrOCmE1VMgmbmdIFsfCqB42C6Jth uUFVURLL+1xwe9vYajZ34yBGdeOhlkkQsVFwqpVRmUWWRGUZpyw8Kg69il7PeaTosGDSOo0NzQRg UNLkvDSVtOKp0sDEvBIyWmbEqBDVuXG5irZUkzGEohAe9ljptNSKMmNg9chv1hJbzWW6gwNRRM2x CoR5nRWSgnBZi8HEuBf/OnibELyG191AUVNDwBf7kEa2L8LjXAfibTROxt243WxCOsKJ2xIUlNTG jXDgAARBzuJbX1mrCjg1IqIbo1sEQybzrhvvOKIkFNidJKqEgpwhQ6tQVsNpnxEGWA6ZEGfEIREs swHJsymOdEI8Ds0H+b/ve9kz0kD2qVI3FVKwrTnFUJt+onmKZg3geaiEV9/Z2fIq51bbnb2dB5Zb ux237AFU8qwGUVDl6QW4otnb3mn3Dr37tddNibSXJdSk97F+xYJ5+cVQgP/YhEAAKvTPOg4R6gj8 lrrY0GAJncZw6roQQuQK58oHUFVLRywjQ2ERb7PX3NvtOLylV1Be2lvBKjikE0LiN/WxktbAJjGU 8258pOywQBiMGNsznMws5T1p6iM+J5xFADKocrkQrFxH8jiR6lwrlTkPG0nKK4XhmVE6TkLBgy/L hEvBJYtSbuyVS2CkDmrqtKYwpuicMmETCz0uohNI/tZeC+uH3tY0KoYzWcaofelPQs209pptOIeO jiOoDvjt468/nSoIVcRTOBdHkhSQCp8//nX30/sI3lNmKHC8ent9/v3l9cXJwfUPTFtOiQjc9LvR iSZlzumxBl4MD4Hcnq6cKnpjQv+HsNzrIg9MkXsd0fchqQ5zIgesZ0owDaE6p5bJMv3rap0x5YhY Eg015NEXG1ByaoeaQfiASuAvwAJqbWlydM5doaFocEUIJATYBxJ2Uffjkaz4vTSCMH3gFh0f1Uta q3HOSGqqeMxLaeDrHMK+4OUxFzAOSIJ0pBNW9Bmknn6dupCSxGh6ASGG8AJtNbM0RzIDtrDemNlw OqZiUaOBqo764zOVQia7QYD8k0wX+IRBFUHtgIegalwJEKypJQUF6irmUht7wmAYIQGgASeElSRk dGoQMRytjuCyVGiss0TICObdXnur7RhmdgpumY4Eh7tJB0dGwIR+fSmxdZDEEi48DQqEBD2VnYGE V6c81B0m6+w70HWzQXrag4CGgsVOiL19xV49M1uqBvr1u7LHBL/V2EGA1VCx1fDZhhvEwvSBm0JP 8AF43F8Z/AXCN4xaxIq2PjqX+q4PQidPQV3GIS9OoaV34+1d31+TrzBXMEroYfRJ8DR6Y13JADjn EvK4GprBRUGu3f/7w3vUaZ1m0O+S5Uv0nl1Gb15HJ8rCeMAwhVG8sLwcxa+/rYeivhzM3QQetf7z Lz+vp3fBTH8RWVheav3dpz/mUGAOuHgsrQu4F/xfF0+9Iz6aGf/xuvj9x7mMXLErPKn27/78NKdr LvuxNfmuGL4wV+zpi/Pr3rdG6OnL+uth7r5Bq84ZPjfC6myfwSW8GYS2iQZUrdytwv9Y9v8BAAD/ /wMAUEsDBBQABgAIAAAAIQB4GgzKVAEAAP8CAAAQAAAAd29yZC9oZWFkZXIxLnhtbJxSyW7DIBC9 V+o/WNwTSNNGlRUnihr11EPV5QMI4BiVTYDt5u87eOtyiKJeGDGP994MM+vtp1ZZI3yQ1hRoMSco E4ZZLs2xQO9vj7N7lIVIDafKGlGgkwhou7m+Wrd5xX0GbBPyBoAqRpdjHFglNA1z64QBsLRe0whX f8Sa+o/azZjVjkZ5kErGE74hZIUGGVug2pt8kJhpybwNtoyJktuylEwMYWT4S3x75t6yWgsTO0fs hYIarAmVdGFU0/9VgxarUaQ510Sj1fiudZe4cU9bGIVWfdmt9dx5y0QIkN334KS4IOe8hw9MEhPj khJ+e46VaCrNJJMW48/8p+HNYXi498ZJ6rsR+IsNrJHL2hzWj78UiJDd8vZu94DG1F6UtFbxB9Ix nn0XXuNJCXjaUFUgekA4ZaXhkCqlD/FJpsKWK5IQDE6Jl2J3wvpuvgAAAP//AwBQSwMEFAAGAAgA AAAhAG+k5BdqAQAAswMAABEAAAB3b3JkL2VuZG5vdGVzLnhtbKST226DMAyG7yftHVDuaehOnVCh N9UeYIcHyEIo0YgdJQHWt5+hQLdqqqrtJhA7/vw7dtabT1NHrXJeI2RsuUhYpEBioWGXsbfXp/iR RT4IKESNoDK2V55t8uurdZcqKACD8hEhwKcteasQbMq5l5Uywi/QKiBnic6IQFu340a4j8bGEo0V Qb/rWoc9v0mSBzZiMGONg3RExEZLhx7L0IekWJZaqvEzRbhL8h4itygboyAMGblTNWlA8JW2fqKZ v9KoxGqCtOeKaE09nevsJdkKJzrqh6kPsjt0hXUolfdk3R6cM3GZnMs9XmCPmCMukfAz56TECA0z pp+Ok/7PzVtQ8/ghN+9Rx0LoLvLjLEVdGvaWQF5Z4URAx8iki4zFy+GcpS3NavGcsSS5vV/drWhw RtNWlaKpwzdPT3b9MuN4vuaDjVY7/I9T/JsIiRA0NMOMvJwKSv6j51fyGW2kdnpt+RcAAAD//wMA UEsDBBQABgAIAAAAIQDQarQAaQEAALkDAAASAAAAd29yZC9mb290bm90ZXMueG1spJJLbsMgEIb3 lXoHi72D01cqK3Y2UQ/QxwEoxjEqMAiw3dy+42fTKIqidIPNDPPND/OvN99aRY1wXoLJyHKRkEgY DoU0u4x8vL/EzyTygZmCKTAiI3vhySa/vVm3aQkQDAThI2QYnzaYrkKwKaWeV0IzvwArDCZLcJoF 3Lod1cx91TbmoC0L8lMqGfb0LkmeyIiBjNTOpCMi1pI78FCGriSFspRcjJ+pwl3Sd6jcAq+1MKHv SJ1QqAGMr6T1E01fS8MrVhOkOXeJRqvpXGsv6VY41uJAtBpkt+AK64AL7zG6HZIzcZmc6z0+YIeY Ky6R8LfnpEQzaWZMZ4+j+c/DW+Dw6NCbdqjfi+Bb5Admito07C2SvLDMsQCOYEgWGYmX/UGLW3Rr 8ZqRJLl/XD2s0DljaCtKVqtwkOnQrltmHM3XtI/havv/yccnZXAwQZq6t8nbsaTkP4pOks+pQ8GT VJ//AAAA//8DAFBLAwQUAAYACAAAACEAWGCzG7oAAAAiAQAAGwAAAHdvcmQvX3JlbHMvaGVhZGVy Mi54bWwucmVsc4SPywrCMBBF94L/EGZv07oQkaZuRHAr9QOGZJpGmwdJFPv3BtwoCC7nXu45TLt/ 2ok9KCbjnYCmqoGRk14ZpwVc+uNqCyxldAon70jATAn23XLRnmnCXEZpNCGxQnFJwJhz2HGe5EgW U+UDudIMPlrM5YyaB5Q31MTXdb3h8ZMB3ReTnZSAeFINsH4Oxfyf7YfBSDp4ebfk8g8FN7a4CxCj pizAkjL4DpvqGkgD71r+9Vn3AgAA//8DAFBLAwQUAAYACAAAACEAeBoMylQBAAD/AgAAEAAAAHdv cmQvaGVhZGVyMy54bWycUsluwyAQvVfqP1jcE0jTRpUVJ4oa9dRD1eUDCOAYlU2A7ebvO3jrcoii Xhgxj/feDDPr7adWWSN8kNYUaDEnKBOGWS7NsUDvb4+ze5SFSA2nyhpRoJMIaLu5vlq3ecV9BmwT 8gaAKkaXYxxYJTQNc+uEAbC0XtMIV3/EmvqP2s2Y1Y5GeZBKxhO+IWSFBhlboNqbfJCYacm8DbaM iZLbspRMDGFk+Et8e+besloLEztH7IWCGqwJlXRhVNP/VYMWq1GkOddEo9X4rnWXuHFPWxiFVn3Z rfXcectECJDd9+CkuCDnvIcPTBIT45ISfnuOlWgqzSSTFuPP/KfhzWF4uPfGSeq7EfiLDayRy9oc 1o+/FIiQ3fL2bveAxtRelLRW8QfSMZ59F17jSQl42lBVIHpAOGWl4ZAqpQ/xSabCliuSEAxOiZdi d8L6br4AAAD//wMAUEsDBBQABgAIAAAAIQAKe8HhVAEAAP8CAAAQAAAAd29yZC9mb290ZXIxLnht bJxSy07DMBC8I/EPke+tXQoVippWFRUnDojHBxjHbiz8ku0k9O9Z5wXlUFVcvPKOZ2bXu+vtl1ZZ w32Q1hRoMSco44bZUppDgd7fHmf3KAuRmpIqa3iBjjyg7eb6at3mIvoM2CbkDQBVjC7HOLCKaxrm 1nEDoLBe0whXf8Ca+s/azZjVjkb5IZWMR3xDyAoNMrZAtTf5IDHTknkbrIiJklshJONDGBn+Et+e ubes1tzEzhF7rqAGa0IlXRjV9H/VoMVqFGnONdFoNb5r3SVupactjEKrvuzW+tJ5y3gIkN334KS4 IOe8hw9MEhPjkhJOPcdKNJVmkkmL8Wf+0/DmMDzce+Mk9dMI/MUG1shlbQ7rV74UiJDd8vZu94DG 1J4LWqv4C+kYz74Lr/GoODxtqCoQpQinrDQlpIT0IT7JVNhyRRKCwSnxUuxOWN/NNwAAAP//AwBQ SwMEFAAGAAgAAAAhAMccbRScBgAAURsAABUAAAB3b3JkL3RoZW1lL3RoZW1lMS54bWzsWU1vG0UY viPxH0Z7b2MndhpHdarYsRto00axW9TjeD3enXp2ZzUzTuobao9ISIiCeqAS4sIBAZVaCSTKr0kp KkXqX+Cdmd31TrwmSRtBBfUh8c4+7/fHvDO+eOlOxNA+EZLyuOlVz1c8RGKfD2kcNL0b/e65NQ9J heMhZjwmTW9KpHdp4/33LuJ1FZKIIKCP5TpueqFSyfrSkvRhGcvzPCExvBtxEWEFjyJYGgp8AHwj trRcqawuRZjGHopxBGyvj0bUJ+jZz7+8+OaBt5Fx7zAQESupF3wmepo3cUgMdjiuaoScyjYTaB+z pgeChvygT+4oDzEsFbxoehXz8ZY2Li7h9ZSIqQW0Bbqu+aR0KcFwvGxkimCQC612a40LWzl/A2Bq HtfpdNqdas7PALDvg6VWlyLPWnet2sp4FkD26zzvdqVeqbn4Av+VOZ0brVar3kh1sUwNyH6tzeHX Kqu1zWUHb0AWX5/D11qb7faqgzcgi1+dw3cvNFZrLt6AQkbj8RxaB7TbTbnnkBFn26XwNYCvVVL4 DAXZkGeXFjHisVqUaxG+zUUXABrIsKIxUtOEjLAPadzG0UBQrAXgdYILb+ySL+eWtCwkfUET1fQ+ TDCUxIzfq6ffv3r6GB3efXJ496fDe/cO7/5oGTlU2zgOilQvv/3sz4cfoz8ef/3y/hfleFnE//bD J89+/bwcCOUzU+f5l49+f/Lo+YNPX3x3vwS+KfCgCO/TiEh0jRygPR6BYcYrruZkIE5H0Q8xLVJs xoHEMdZSSvh3VOigr00xS6Pj6NEirgdvCmgfZcDLk9uOwr1QTBQtkXwljBzgDuesxUWpF65oWQU3 9ydxUC5cTIq4PYz3y2S3cezEtzNJoG9maekY3g6Jo+Yuw7HCAYmJQvodHxNSYt0tSh2/7lBfcMlH Ct2iqIVpqUv6dOBk04xom0YQl2mZzRBvxzc7N1GLszKrt8i+i4SqwKxE+T5hjhsv44nCURnLPo5Y 0eFXsQrLlOxNhV/EdaSCSAeEcdQZEinLaK4LsLcQ9CsYOlZp2HfYNHKRQtFxGc+rmPMicouP2yGO kjJsj8ZhEfuBHEOKYrTLVRl8h7sVop8hDjheGO6blDjhPr4b3KCBo9IsQfSbidCxhFbtdOCIxn/X jhmFfmxz4OzaMTTA5189LMmst7URb8KeVFYJ20fa7yLc0abb5mJI3/6eu4Un8S6BNJ/feN613Hct 1/vPt9xF9XzSRjvrrdB29dxgh2IzIkcLJ+QRZaynpoxclWZIlrBPDLuwqOnM8ZDkJ6YkhK9pX3dw gcCGBgmuPqIq7IU4gQG76mkmgUxZBxIlXMLBziyX8tZ4GNKVPRbW9YHB9gOJ1Q4f2uUVvZydC3I2 ZrcJzOEzE7SiGZxU2MqFlCmY/TrCqlqpE0urGtVMq3Ok5SZDDOdNg8XcmzCAIBhbwMurcEDXouFg ghkZar/bvTcLi4nCWYZIhnhI0hhpu+djVDVBynLF3ARA7pTESB/yjvFaQVpDs30DaScJUlFcbYG4 LHpvEqUsg2dR0nV7pBxZXCxOFqODpteoL9c95OOk6Y3gTAtfowSiLvXMh1kAN0O+Ejbtjy1mU+Wz aDYyw9wiqMI1hfX7nMFOH0iEVFtYhjY1zKs0BVisJVn9l+vg1rMywGb6a2ixsgbJ8K9pAX50Q0tG I+KrYrALK9p39jFtpXyiiOiFwwM0YBOxhyH8OlXBniGVcDVhOoJ+gHs07W3zym3OadEVb68Mzq5j loQ4bbe6RLNKtnBTx7kO5qmgHthWqrsx7vSmmJI/I1OKafw/M0XvJ3BTsDLUEfDhHldgpOu16XGh Qg5dKAmp3xUwOJjeAdkCd7HwGpIKbpPNf0H29X9bc5aHKWs48Kk9GiBBYT9SoSBkF9qSyb5jmFXT vcuyZCkjk1EFdWVi1R6QfcL6ugeu6r3dQyGkuukmaRswuKP55z6nFTQI9JBTrDenh+R7r62Bf3ry scUMRrl92Aw0mf9zFUt2VUtvyLO9t2iIfjEbs2pZVYCwwlbQSMv+NVU45VZrO9acxcv1TDmI4rzF sJgPRAnc9yD9B/Y/KnxGTBrrDbXP96C3IvihQTODtIGsPmcHD6QbpF0cwOBkF20yaVbWtenopL2W bdZnPOnmco84W2t2knif0tn5cOaKc2rxLJ2detjxtV1b6GqI7NEShaVRdpAxgTG/aRV/deKD2xDo LbjfnzAlTTLBb0oCw+jZM3UAxW8lGtKNvwAAAP//AwBQSwMECgAAAAAAAAAhAMcZ/uonjQAAJ40A ABYAAAB3b3JkL21lZGlhL2ltYWdlMS5qcGVn/9j/4AAQSkZJRgABAgEBLAEsAAD/4RpKRXhpZgAA TU0AKgAAAAgABwESAAMAAAABAAEAAAEaAAUAAAABAAAAYgEbAAUAAAABAAAAagEoAAMAAAABAAIA AAExAAIAAAAUAAAAcgEyAAIAAAAUAAAAhodpAAQAAAABAAAAnAAAAMgAAAEsAAAAAQAAASwAAAAB QWRvYmUgUGhvdG9zaG9wIDcuMAAyMDA2OjA0OjI4IDEzOjUxOjAxAAAAAAOgAQADAAAAAf//AACg AgAEAAAAAQAAASygAwAEAAAAAQAAASwAAAAAAAAABgEDAAMAAAABAAYAAAEaAAUAAAABAAABFgEb AAUAAAABAAABHgEoAAMAAAABAAIAAAIBAAQAAAABAAABJgICAAQAAAABAAAZHAAAAAAAAABIAAAA AQAAAEgAAAAB/9j/4AAQSkZJRgABAgEASABIAAD/7QAMQWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAA AAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwM DAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwMDAwMEREMDAwMDAwRDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIAIAAgAMBIgACEQEDEQH/3QAEAAj/xAE/AAABBQEB AQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQB AwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQVUsFiMzRygtFDByWSU/Dh8WNz NRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3 R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMFMoGRFKGxQiPBUtHw MyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1 xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/APVUkkklKSSSSUxssrqrdba4 MrYC573GAGgS5znH6LWrges/4wcq699HR4px2naMl7ZsfH59bH+ypn/GM9T/AIv6Ctf4yeruqop6 RUYN/wCmv/qNMUs/tWtc/wD6yuDo5VLmeYkJcEDVfMXpvgnwjFLCOa5iInx37WOXyCI/TlH9Lidg Z/Usixtt2XdZYxwfWX2OcGuB3tc2ufT9rh+4vT+k546j06jMA2m1vvb2D2nZa0f1bGuXleP2Xd/U nJ34V+IeaLN7f6tgn/z4y1N5SZ9wgn5h+IV8dwROATjER9qXQcP6ufpl/wA/gd/KyGY2PZe/6NbS Y8T2b/acuWpflb3Wi17LLHF79jiAXE7ne36K2vrDcGYjKe91gEeTf0h/6TWrKo2907mpnjEQflH/ ADi5fJQ4cMpkXxn/AJsW7jdYyqXBuV+lq4LgIeP5Xt9r1tV2MtrbZW4OY8S1w4IK5y7bGitdBynC 2zDOrINtflqBY3+1u3/56PL5pcQhI2DsT3W8xy8TA5IR4THWQGxi7aSSSuOepJJJJT//0PVUPIyK cWizIvcGU0tL7Hns1olx0RFwn+MnrL2+j0el8NePWygO4n9BW7+011mz/iUzLkGOBl9nm2uQ5SXN 8xDCDQkbnL93HH5i18b/ABg3n6wG64FvSrYqFR5Yyfbknbu/S/nWt/63+ZWvQWPZYxtlbg9jwHNc 0yCDq1zXBeErvP8AF99Y+OiZbhpJw3H/AD7KC7/wSr/M/wBEqnLcwTLhmb4jof63Z3vjXwbHHAM/ LQ4fZiI5ID9LFH/Kf34fpuf/AIyp/b1M/wDcVkf59y5ikwfmu6/xmdOLqsTqbG/QJotOsw79JT/Z a4Xf9uLgmGD8VDzIIyyvrq6nwbJHJ8Ow8P6MTCX96EnUx3cLrPqTaR1OyudLKCSPNj2bf/Pj1xlF i6b6nXR12hv+kZY3/o+p/wCi0MBrJDzH4sHxTFfLZvCEpf4nrd/6zX/r1FPZlZf/AJ7tv/opUa74 Cb603x1ot/dprH3mxyz236J2Y3ln5/k5nLYP6Ni03jf+N6nSffI5VnoL93VhHap5P3sWK7I05W39 UaXWX5GYfoMaKWHxJi2z/Nb6KOEXlj539i3msYx8tlkf3eH/AB/S9MSAJPC4fqf10yWdXZbha4OM XVurJEXgmLLJ/M+j+qO/75d6SvfXTrnpsPSMckPsaDlPB4rd/gNPzrv8J/wH/HLhb7FLzPMES4IG uE+o+PZPwb4XGcDmzwEvcBjjhL9yX+U/wv0H17CzMfOxKsvGdvpuaHsPx/Nd/Lb9F6OvP/8AF51k szLukWvOy+bcdp7PaJuaP+MrHqf9aXoCs4cnuQEvofNyfiPJy5TmZ4TrH5scv3scvl/7x//R9VXj n1rufd9ZOoPs+kLiwf1awKmf9Bi9jXmP+MTpL8TrA6g0TRnAEmNG2MDa3s/tt2Wf9uKtzkScYI6H V2/+LmWEOclGWksmMxh5gifC8qpMe+t7bGEte0hzXAwQRqHNKinWc9kNQ+oYeZV9cvqvfjuLasst 2WtB0ba2LKbfzneha9jf/Bal5jbW+qx9Vg22VuLXtPIIO1wWn9WeuP6J1SvJO52M/wBmTW08sP53 9ap36Rv/AG3+etT6+dIqx82vq2J78TqQ9TczVgsgO3Bzfb+sNPrfy/0ysZD7uMT/AE4emf8Ad/Rk 5HJ4/uPOT5bbl+avNy3aGWP87h/xHm6rIXQfVG7/ALIsCO73j76rQuZW59Tnk/WXAH8t3/UPUWL+ ch/ej+bd5+APK8wf9Vk/9Jydj613R9Yslv7rah/0N3/flnNyET65W7frRmjyq/8APTFkjI80cp/W T/vS/Np8pgvlOXPfFjP/AI3F0nZGncnsByT4BdqcgfVf6tVuuAdlHRrOQ6+3dbslv+Dq93v/ANFU uW+p/T29R6n9pucG4vT9t9hJ0L9TQ0mRta3Z6z/+LVL6z9f/AGt1N9tbicWma8Uagbfz7tp/Ovd/ 4F6akxy9uByfpS9MP+6k1eY5b71zMOVH81hrNzP94/zOH/C/6DSvyHvc59ji+x5LrHnlznGXvd/W VK22VGy6UIknlV7dzHiEXQ+rz3s6/wBOc0wTlVAkeDnta4f2muXs68r+ofSHdQ62zIcP0GBFzz/L /wC07P8APHq/9ZXqi0OSBECT1Ojyv/GbJCXNY4R1ljh6/DjPFGL/AP/Su4H+M++nOyWZ9P2nCde8 0Pr2ttrrLnbK49teRtZs/wBE/wD4R67Jz+hfWrpj6WWsyqHgE7SPUqcdwY/a730XN92zez/wNeJ5 dDsPOyMN/wBLGtfU7vqxzq/++qxgZ2Vg5DMrDtdTfWZa9p/A/muY789jvYqXvyjYmOKL00vhWHKI 5OXl7GWIEoyj8hI+U/1f8B2Ov/VrqHQr9t49TGeYpymiGu/ku59O3/g1kyu36T/jBxcvFdgfWSkW MsAY69jZa5p5dfS36O36e/H/AO2kHrf1FD6z1D6uWNy8RwLvQa7c4R/3Hsl3r/nezd6v/GqKeESu WI8Q6x/Ti6HLfEcmIxw8/H2sh9MM/wD4Hzf4f+Tm8cu1+q2VV17o2T9Ws94NzG7+nvfqRA9oZp/2 mf8Ay9/oWWVfzNa4tzXNcWPBa4aEHQg+aP0/Nv6fm05tH87Q8PaDMGPpMdH5j2+x6ixz4Ja/KfTI d4lvc7y/3jCYxPDlgRkwZP3M0PVCX/cyR5GPdjX2Y97dl1LiyxuhhzTtcNFs/Uhu760YI87D91Vp Wx9demUZ+FR9aOnNJrvY37UJ1AIayqwtbubvr/mL/wBJ/o/+EWZ9Qai/6zY7v9Eyxx+bHV/+jE8Y zDPGO44omJ7xa0+bjzHwzPlrhmMWWGWH+bzRhKM4f4yvr60t+s2SeN7Kj/0Gt/76sGpt1tjKqmmy ywhrGNEkuJ2ta0D95dL/AIxmbfrCD+/Qw/i9v/fVY+o3SKaq7/rH1BpGNhtc7HkcloJtua38/wBL 6Ff/AAv/AAlSMsZnnlEfvEk9oowc3Hl/hWDNIcRGKEIQ65MtcEIBP9YLv+bX1cx+gY5b9szWl+bY 06wYFv7vttd+r1v/ANBS9cQSSrXVuo29T6lkZ9ujr3lwbztaPbVXIDf5usNYqoBcQ1oknQAckqPL Pilp8o9MR/VDZ5Hljgw+s3myE5c8/wB7Lk+b/Bh8kVlqdB+r2d1zKFOO0spaf02S4exg/wC/2/uV f+i/0i2+ifUS1zG5/XnjCwmje6pztjyO3rOd7cdn73+G/wCKVzqP16wOn4jenfVugNZUCxtz2wxo /fqYffc930/Uv/P+n629PhhAHFlPDHpH9ObW5j4jPJI4Ph8ffy/LLN/4G5f+9k/Tn/Uenx2dF+q/ TGUvtrxqWAlz3mH2vA/SWbf5y6137rP6i5Tqf+Me+66uvplJopD2l9tkF7mgt3MFfuZV+d+db/1t chm52Zn5DsnMtdfc/lzj252tH0WM/kMQ6KzdfXS3V1j2sA83Hanz5qRqOMcEdh+8wct8CwwMs3Ny +85pXKRl/NiX6R4f0/8Aqj//03/xndAtxepjrNLP1XM2tucPzbwNurY9rbqmMd/xvqrjWPXv+bhY ufi2YeZU27HubtsrdwR/31zXe5j2/QXln1i/xcdV6bYbulB/UcMydrQPWZr7WOrH9I9v+Epb/wBZ rVXNhNmQF27vwz4jERjiyS4ZR0iTtKP/AHzzTXLS6P1zqXR7/XwbSwuj1Kzqx4H5tjPzv+rWVYy7 HtdTkVuptYYdXY0scD/KY+HKTXjxVQgxNjQh6GM8eWBjMRnCQ1jL1Rk+hVdX+rH1tZXT1pgwOpAB rchh2h350NueHM26e2rJ/wCs2eosXrf1K6x0kPua37XiMlxvq5a0T7rafp1+0bn/AM5Uz/Srmw4L o/q/9dup9HimwnMwxA9Gxx3MAG0Ciz3em3/g/wCbT+OE9Moo/wCcj/3cWv8Ad+Y5X1clPjx9eUzH 0f8Apvl/yX912P8AF71Oq6vJ6BmHfVe1zqK3cEEFuVSNfzmfpNjf+GVn6t9As6N9cr8Y7nUDGfbj WuiXML6me7b+fXu9N/8AnrQxMH6tdfto6v0h4xc3Hey1/ogMeDO51eXjj6XqfpGep/hP9LbWun2t 3B0DcAQD3g8/kVnHiuMLIPtm4TH6Uezh878Q4cnMe3CWP73Dg5nl8g4Tizx/ysf7zw31t6Lf1n63 YeJX7WOxWuus/drZZb6j+/7zWV/8Io/X/qFeBgYn1ewztq2Ndc3UkV1w3GZuP7z2b3/n/omLu9rd 26BuiJ7wuaz+nfVzpGTkda61YMrKyHOfU26HGG6Mpxcb891TPRr9R/0P+BSyYqEyCB7h9Uz+jBHJ fEBLJy0ckJZI8pGsGDGOOWfmTtk/q8DxXRPqd1jq+y1rPs+I4ici3QFv71Vf07vb9D/Bf8Kt5+d9 VvqiLK+nN/aHV2yx1jzIYfzt1jR6bGt/Oro/S/4K16yfrB9eOo9VmjF3YWHqCxjjveD7f01jY9u3 /BM/656q5qVV44Y9MY4pf5yX/cRegHK8zzfq52XtYj/4Ewn5v/OnN/lP7kHR6x17qfWbhbm2y1v8 3S321t/qV/vfy3fpFnppUqqrbrG1UsdbY4w1jAXOJ/ktaoSTI2TZLowjjxQEIRjjhEaRj6YxYrqP qD0R+f1VufbWTiYR3h/DTcINVf8AK9P+e9v/AAe/+cTdC+ofVeoWCzPa7AxQRu3iLXfvNrqd9D/j Lf8AwVek4ODi4GLXiYlYqoqENaPxc4/nOcrXL8vIyE5CojUA/pOF8Z+M44Yp8vgkJ5ZjhnKJ9OKJ +b1fvv8A/9T1VYn1o+sV31exa8wYL8zGcS26xjw0VE7fS9T2v9lsub6n7/8Axta20HLxcfMxrcTJ YLKL2Gu1hkS1w2uEthzf7KButDRXYzETBnHijfqjto8Bb/jZxrBDukGweD7m/wDpFyEP8aWIf+8O v/t5v/vKsb60/UTqfRLbMjGY7L6aXHZYwF1lbY3bcpjR7dv0fXb+i/4n1PSXLSPFVZZMoNE19A72 DlORyREoR4on+vP/AL59DP8AjOod9Do1TfjaD/7rtSZ/jEzMixtOJ0ih9zzDGAOscT4NZW1rnLC+ r31G671nbcWfY8MmDkXggkaSaaPbZbz/AMHT/wAKvT+g/VjpPQqz9jrm97Q23JeZe4DX+rWzd+ZU jGOaW8uEeQWcxl+G4BUcXu5f3ePJwj+/LjTdFb1X7ObeqVY+PdZBbTjtMtH7t1jnvbY//i/+mtFJ JWQKFOJknxyMqEb/AEY/KPJSo9Xb1E4vqdNqouya5IqyAYcI1rre1zPTsd/L/Rq8kkRYpUJ8EhKh KjtL5T5vndn+MDOxbXUZnSaWXVmH1ncxw7/Re1ydv+Muv87pFZ+FoH/ohy7HrP1e6X1qoMzqpewE V3MO2xk/uu/75ZvrXm/XfqP1npINtbftuIP8LSDuaPG6j3PZ/WZ6taqZBzENRLij5C3oeSyfCeZA jkwjDl/dOTJGEv8AZz4/+a7P/jmY/wD5Ts/7eH/vOiM/xoYzNB0wtnnbaP8A0k1eel4W/wDVv6n9 S63ay17HY/TwQbL3jaXNn3DG3NPqP/l/zSjhlzyNA39ItvmPh/wvFAzyQ4Yjvky/9++i/Vr6xu6/ Vde3DfjUVENbY524PcZ3tZDW/wA3+d/XW2gYWHjYGLVh4rBVRS3axg8P+/Od9J7kdX4ggDiNnqXl c8scskjih7eO/RC+Ko+Jk//V9VSXC/UX/GLl/WnrF3TrsKvGbTjuv3seXElr6qtvua3/AEy7DqeW 7C6bl5jGh7saiy5rCYDjW11gaXa/S2pKbSh6NPqersb6sRvgbo8N30lyP1C+vWT9ax1A3YjMb7C2 ot2OLtxs9bncP+BVb6if4xMv61dVuwLsKvGbTjm/ex7nEkPrq27XN/4VJT3SSzfrH1Wzo3Q8zqlV Yufi1+o2txIB1A1cFj/UL65ZH1sxcu+/GZi/ZrGsaGOLp3N3a7g1JT1SS5b6+fXUfVPDxbK6BlZO XYW11OcWtDGAG6zc0O+i59TNv/CKH1D+vdX1sqyWW1Nxc3GcCaGu3B1Tvo3M3bX+2z2W/ufov9Kk p6xJcL1b/GLl9G+uFfQeoYVbMO2ysNzN5b+iuhrLyHjZtpsP6b/irV1/Vs9vTOl5nUXN3jDosv2T G702us2bv5e3YkptpLzf6q/42retddxel5mFVi15RcxtzbCYs2l1Tdr2/wCFe30f69i7X6y9br6D 0PL6rY3f9mZLK+N1jiK6Wf2rXs3JKb5ooNouNbDaNBZtG6P6/wBJEXJfVP67nq/Qczr/AFdlPTcH FsNYfucZ2tY57zub7t77q6qWV/pLLf0awP8Ax3eo5+VbT0DoF2cyrXcC97yzhtj6Mamz0f8At2xJ Vl9MSXn2B9ffrpk5+Nj3/VbIoputrrtudXeAxjnNbZa4upDfYw7lZ+vn+MPL+qvU8fCpw68ll9Au L3vc0g7317drWn9xJT//1uQ+of1gy+gdbvzMTp1nVLLMd9JoqLmua02U2et7Ksj2t9LZ9D/CLtOp /wCMzreX03LxX/VbKpZfRZW60vsIYHMc11jv1Nv8233/AElj/wCJhrm/WzL3NLZwbYkR/hsVesfW Gf2B1KOfsl8R/wAW9JT5v/iQ465/Vxv/AHaWf/iT/wDFLmf+Enf+fcdaX+I5pDutBwiRi8+B+1LG 6KOqf4tfrRbd1TCtyMKyt2Ocipp2vrc6u1t2O922p9jfSb+hfYkp9P8Ar/8A+I3q3/hc/lauU/xI f8mdT/4+v/qCqX1s/wAZ2F9YeiX9G6Hg5bsnN2sc6xjNGBzXv2MofkutdZs9L/BqGFVm/Uf/ABdZ hzWmnq3XLCzFoaSLWMfWGb7Gj31W01evd7f5p78euz07UlNd3UKvrZ/jObkX5VVPSekWB1Vj7Gem a8Z42em922u37dl/pP8AwvZ/wKBk9QxPqd/jLOfhWMs6VmnfZ6L2Ob6OQf1hv6Lc1n2bLY66uj/g Kld+pf8Aip6d1joFPU+r3ZNN2UXPprocxoFP0anWNuot99m19vtf/MvqS+uv+Krp3RugXdT6RblX 3Yrmvurucx49H6Nr2Npoqdurc5ljvds9H1UlN7/HV0L1cXD69U2XY5+y5MST6bybMd/7rWV2+qz/ ANCGKX1v+tjcj/Ffg2ssL8nq7a8e1xMP3Vf098fnM9bH9F3/AIYVv6q3H66f4u8noeW/9ex2fZS5 5gyzbd03Is2Df6e5ldb/APTfZ7l5d07G6h1LN6d9XL97KRmmsAt91br3U05f/bbcbds/4xJTtde6 L/zb6b9U+u4o/T21Nvt9sD1Wvb1Ch1jx9Kz08n0P+LxV1P8Aje+sGNlfV/pOLiOLx1Nzc1pBAPot Z+iFlf0v0z8n2f8Ahd66X/GT0NnU/qdlVUsAs6eBlY7QYAFIPqtgfS/VHXtYz9/YvK/qV0/L+sn1 m6ThZkvxenMkyIiil78oVO/fa/Iv9H+pakp6769dOf8AVv8AxY9P6PXAc++qvMIMhz3Nuzb/AHfn N+01ez+Qsj6j/XHM+r/RRj4P1bvzjdY59udW54FhB2tb7cW/+Zb+j2+r/wCfF6R9efq5Z9Y/q7f0 +gtGUHMuxnPMND2HuRP06nW1f21539Vvrt1j6lUWdB650u99NNjjTHsfXuO61jdw9LIofZ+lqsY/ 8/8AwtdlfppT0uB/jM61lZ2Ni2fVfJoZkWsqdc59hDA9zWGx04bPobt30lzH+O3/AMUGD/4TH/ny 1dPg/wCN7p2bnY2G3puSx2VdXS17iyAbHNqDj/nLmv8AHWx7vrBg7Wk/qY4E/wCEtSU//9n/7R74 UGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAAAAAAAAAAAAAAOEJJTQPtAAAAAAAQASwA AAABAAIBLAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAAAAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhC SU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAAAAEAOEJJTQQKAAAAAAABAAA4QklNJxAA AAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgABAGxmZgAGAAAAAAABAC9mZgABAKGZmgAG AAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0AAAAGAAAAAAABOEJJTQP4AAAAAABwAAD/ ////////////////////////////A+gAAAAA/////////////////////////////wPoAAAAAP// //////////////////////////8D6AAAAAD/////////////////////////////A+gAADhCSU0E CAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4AAAAAAAQAAAAAOEJJTQQaAAAAAANbAAAABgAA AAAAAAAAAAABLAAAASwAAAATAEgAVwBfAFAATwBTAF8AUgBHAEIAXwBWAGUAcgB0AGkAYwBhAGwA AAABAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAASwAAAEsAAAAAAAAAAAAAAAAAAAAAAEA AAAAAAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAA AAAAAFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcA AAEsAAAAAFJnaHRsb25nAAABLAAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UA AAASAAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAA AAxFU2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBl AAAAAEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAA AAAATGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAABLAAAAABSZ2h0bG9uZwAAASwAAAADdXJsVEVY VAAAAAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhU AAAAAQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhv cnpBbGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51 bQAAAA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNs aWNlQkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0 bG9uZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4 QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAE4QklNBAwAAAAAGTgAAAABAAAAgAAAAIAAAAGA AADAAAAAGRwAGAAB/9j/4AAQSkZJRgABAgEASABIAAD/7QAMQWRvYmVfQ00AAv/uAA5BZG9iZQBk gAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwMDAwMEQwMDAwMDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwMDAwMEREMDAwMDAwRDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIAIAAgAMBIgACEQEDEQH/3QAEAAj/xAE/AAAB BQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEAAgMEBQYHCAkKCxAA AQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQVUsFiMzRygtFDByWSU/Dh 8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW 5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMFMoGRFKGxQiPB UtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPTdePzRpSkhbSVxNTk 9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/APVUkkklKSSSSUxssrqr dba4MrYC573GAGgS5znH6LWrges/4wcq699HR4px2naMl7ZsfH59bH+ypn/GM9T/AIv6Ctf4yeru qop6RUYN/wCmv/qNMUs/tWtc/wD6yuDo5VLmeYkJcEDVfMXpvgnwjFLCOa5iInx37WOXyCI/TlH9 LidgZ/Usixtt2XdZYxwfWX2OcGuB3tc2ufT9rh+4vT+k546j06jMA2m1vvb2D2nZa0f1bGuXleP2 Xd/UnJ34V+IeaLN7f6tgn/z4y1N5SZ9wgn5h+IV8dwROATjER9qXQcP6ufpl/wA/gd/KyGY2PZe/ 6NbSY8T2b/acuWpflb3Wi17LLHF79jiAXE7ne36K2vrDcGYjKe91gEeTf0h/6TWrKo2907mpnjEQ flH/ADi5fJQ4cMpkXxn/AJsW7jdYyqXBuV+lq4LgIeP5Xt9r1tV2MtrbZW4OY8S1w4IK5y7bGitd BynC2zDOrINtflqBY3+1u3/56PL5pcQhI2DsT3W8xy8TA5IR4THWQGxi7aSSSuOepJJJJT//0PVU PIyKcWizIvcGU0tL7Hns1olx0RFwn+MnrL2+j0el8NePWygO4n9BW7+011mz/iUzLkGOBl9nm2uQ 5SXN8xDCDQkbnL93HH5i18b/ABg3n6wG64FvSrYqFR5Yyfbknbu/S/nWt/63+ZWvQWPZYxtlbg9j wHNc0yCDq1zXBeErvP8AF99Y+OiZbhpJw3H/AD7KC7/wSr/M/wBEqnLcwTLhmb4jof63Z3vjXwbH HAM/LQ4fZiI5ID9LFH/Kf34fpuf/AIyp/b1M/wDcVkf59y5ikwfmu6/xmdOLqsTqbG/QJotOsw79 JT/Za4Xf9uLgmGD8VDzIIyyvrq6nwbJHJ8Ow8P6MTCX96EnUx3cLrPqTaR1OyudLKCSPNj2bf/Pj 1xlFi6b6nXR12hv+kZY3/o+p/wCi0MBrJDzH4sHxTFfLZvCEpf4nrd/6zX/r1FPZlZf/AJ7tv/op Ua74Cb603x1ot/dprH3mxyz236J2Y3ln5/k5nLYP6Ni03jf+N6nSffI5VnoL93VhHap5P3sWK7I0 5W39UaXWX5GYfoMaKWHxJi2z/Nb6KOEXlj539i3msYx8tlkf3eH/AB/S9MSAJPC4fqf10yWdXZbh a4OMXVurJEXgmLLJ/M+j+qO/75d6SvfXTrnpsPSMckPsaDlPB4rd/gNPzrv8J/wH/HLhb7FLzPME S4IGuE+o+PZPwb4XGcDmzwEvcBjjhL9yX+U/wv0H17CzMfOxKsvGdvpuaHsPx/Nd/Lb9F6OvP/8A F51kszLukWvOy+bcdp7PaJuaP+MrHqf9aXoCs4cnuQEvofNyfiPJy5TmZ4TrH5scv3scvl/7x//R 9VXjn1rufd9ZOoPs+kLiwf1awKmf9Bi9jXmP+MTpL8TrA6g0TRnAEmNG2MDa3s/tt2Wf9uKtzkSc YI6HV2/+LmWEOclGWksmMxh5gifC8qpMe+t7bGEte0hzXAwQRqHNKinWc9kNQ+oYeZV9cvqvfjuL asst2WtB0ba2LKbfzneha9jf/Bal5jbW+qx9Vg22VuLXtPIIO1wWn9WeuP6J1SvJO52M/wBmTW08 sP539ap36Rv/AG3+etT6+dIqx82vq2J78TqQ9TczVgsgO3Bzfb+sNPrfy/0ysZD7uMT/AE4emf8A d/Rk5HJ4/uPOT5bbl+avNy3aGWP87h/xHm6rIXQfVG7/ALIsCO73j76rQuZW59Tnk/WXAH8t3/UP UWL+ch/ej+bd5+APK8wf9Vk/9Jydj613R9Yslv7rah/0N3/flnNyET65W7frRmjyq/8APTFkjI80 cp/WT/vS/Np8pgvlOXPfFjP/AI3F0nZGncnsByT4BdqcgfVf6tVuuAdlHRrOQ6+3dbslv+Dq93v/ ANFUuW+p/T29R6n9pucG4vT9t9hJ0L9TQ0mRta3Z6z/+LVL6z9f/AGt1N9tbicWma8Uagbfz7tp/ Ovd/4F6akxy9uByfpS9MP+6k1eY5b71zMOVH81hrNzP94/zOH/C/6DSvyHvc59ji+x5LrHnlznGX vd/WVK22VGy6UIknlV7dzHiEXQ+rz3s6/wBOc0wTlVAkeDnta4f2muXs68r+ofSHdQ62zIcP0GBF zz/L/wC07P8APHq/9ZXqi0OSBECT1Ojyv/GbJCXNY4R1ljh6/DjPFGL/AP/Su4H+M++nOyWZ9P2n Cde80Pr2ttrrLnbK49teRtZs/wBE/wD4R67Jz+hfWrpj6WWsyqHgE7SPUqcdwY/a730XN92zez/w NeJ5dDsPOyMN/wBLGtfU7vqxzq/++qxgZ2Vg5DMrDtdTfWZa9p/A/muY789jvYqXvyjYmOKL00vh WHKI5OXl7GWIEoyj8hI+U/1f8B2Ov/VrqHQr9t49TGeYpymiGu/ku59O3/g1kyu36T/jBxcvFdgf WSkWMsAY69jZa5p5dfS36O36e/H/AO2kHrf1FD6z1D6uWNy8RwLvQa7c4R/3Hsl3r/nezd6v/GqK eESuWI8Q6x/Ti6HLfEcmIxw8/H2sh9MM/wD4Hzf4f+Tm8cu1+q2VV17o2T9Ws94NzG7+nvfqRA9o Zp/2mf8Ay9/oWWVfzNa4tzXNcWPBa4aEHQg+aP0/Nv6fm05tH87Q8PaDMGPpMdH5j2+x6ixz4Ja/ KfTId4lvc7y/3jCYxPDlgRkwZP3M0PVCX/cyR5GPdjX2Y97dl1LiyxuhhzTtcNFs/Uhu760YI87D 91VpWx9demUZ+FR9aOnNJrvY37UJ1AIayqwtbubvr/mL/wBJ/o/+EWZ9Qai/6zY7v9Eyxx+bHV/+ jE8YzDPGO44omJ7xa0+bjzHwzPlrhmMWWGWH+bzRhKM4f4yvr60t+s2SeN7Kj/0Gt/76sGpt1tjK qmmyywhrGNEkuJ2ta0D95dL/AIxmbfrCD+/Qw/i9v/fVY+o3SKaq7/rH1BpGNhtc7HkcloJtua38 /wBL6Ff/AAv/AAlSMsZnnlEfvEk9oowc3Hl/hWDNIcRGKEIQ65MtcEIBP9YLv+bX1cx+gY5b9szW l+bY06wYFv7vttd+r1v/ANBS9cQSSrXVuo29T6lkZ9ujr3lwbztaPbVXIDf5usNYqoBcQ1oknQAc kqPLPilp8o9MR/VDZ5Hljgw+s3myE5c8/wB7Lk+b/Bh8kVlqdB+r2d1zKFOO0spaf02S4exg/wC/ 2/uVf+i/0i2+ifUS1zG5/XnjCwmje6pztjyO3rOd7cdn73+G/wCKVzqP16wOn4jenfVugNZUCxtz 2wxo/fqYffc930/Uv/P+n629PhhAHFlPDHpH9ObW5j4jPJI4Ph8ffy/LLN/4G5f+9k/Tn/Uenx2d F+q/TGUvtrxqWAlz3mH2vA/SWbf5y6137rP6i5Tqf+Me+66uvplJopD2l9tkF7mgt3MFfuZV+d+d b/1tchm52Zn5DsnMtdfc/lzj252tH0WM/kMQ6KzdfXS3V1j2sA83Hanz5qRqOMcEdh+8wct8CwwM s3Ny+85pXKRl/NiX6R4f0/8Aqj//03/xndAtxepjrNLP1XM2tucPzbwNurY9rbqmMd/xvqrjWPXv +bhYufi2YeZU27HubtsrdwR/31zXe5j2/QXln1i/xcdV6bYbulB/UcMydrQPWZr7WOrH9I9v+Epb /wBZrVXNhNmQF27vwz4jERjiyS4ZR0iTtKP/AHzzTXLS6P1zqXR7/XwbSwuj1Kzqx4H5tjPzv+rW VYy7HtdTkVuptYYdXY0scD/KY+HKTXjxVQgxNjQh6GM8eWBjMRnCQ1jL1Rk+hVdX+rH1tZXT1pgw OpABrchh2h350NueHM26e2rJ/wCs2eosXrf1K6x0kPua37XiMlxvq5a0T7rafp1+0bn/AM5Uz/Sr mw4Lo/q/9dup9HimwnMwxA9Gxx3MAG0Ciz3em3/g/wCbT+OE9Moo/wCcj/3cWv8Ad+Y5X1clPjx9 eUzH0f8Apvl/yX912P8AF71Oq6vJ6BmHfVe1zqK3cEEFuVSNfzmfpNjf+GVn6t9As6N9cr8Y7nUD GfbjWuiXML6me7b+fXu9N/8AnrQxMH6tdfto6v0h4xc3Hey1/ogMeDO51eXjj6XqfpGep/hP9LbW un2t3B0DcAQD3g8/kVnHiuMLIPtm4TH6Uezh878Q4cnMe3CWP73Dg5nl8g4Tizx/ysf7zw31t6Lf 1n63YeJX7WOxWuus/drZZb6j+/7zWV/8Io/X/qFeBgYn1ewztq2Ndc3UkV1w3GZuP7z2b3/n/omL u9rd26BuiJ7wuaz+nfVzpGTkda61YMrKyHOfU26HGG6Mpxcb891TPRr9R/0P+BSyYqEyCB7h9Uz+ jBHJfEBLJy0ckJZI8pGsGDGOOWfmTtk/q8DxXRPqd1jq+y1rPs+I4ici3QFv71Vf07vb9D/Bf8Kt 5+d9VvqiLK+nN/aHV2yx1jzIYfzt1jR6bGt/Oro/S/4K16yfrB9eOo9VmjF3YWHqCxjjveD7f01j Y9u3/BM/656q5qVV44Y9MY4pf5yX/cRegHK8zzfq52XtYj/4Ewn5v/OnN/lP7kHR6x17qfWbhbm2 y1v83S321t/qV/vfy3fpFnppUqqrbrG1UsdbY4w1jAXOJ/ktaoSTI2TZLowjjxQEIRjjhEaRj6Yx YrqPqD0R+f1VufbWTiYR3h/DTcINVf8AK9P+e9v/AAe/+cTdC+ofVeoWCzPa7AxQRu3iLXfvNrqd 9D/jLf8AwVek4ODi4GLXiYlYqoqENaPxc4/nOcrXL8vIyE5CojUA/pOF8Z+M44Yp8vgkJ5ZjhnKJ 9OKJ+b1fvv8A/9T1VYn1o+sV31exa8wYL8zGcS26xjw0VE7fS9T2v9lsub6n7/8Axta20HLxcfMx rcTJYLKL2Gu1hkS1w2uEthzf7KButDRXYzETBnHijfqjto8Bb/jZxrBDukGweD7m/wDpFyEP8aWI f+8Ov/t5v/vKsb60/UTqfRLbMjGY7L6aXHZYwF1lbY3bcpjR7dv0fXb+i/4n1PSXLSPFVZZMoNE1 9A72DlORyREoR4on+vP/AL59DP8AjOod9Do1TfjaD/7rtSZ/jEzMixtOJ0ih9zzDGAOscT4NZW1r nLC+r31G671nbcWfY8MmDkXggkaSaaPbZbz/AMHT/wAKvT+g/VjpPQqz9jrm97Q23JeZe4DX+rWz d+ZUjGOaW8uEeQWcxl+G4BUcXu5f3ePJwj+/LjTdFb1X7ObeqVY+PdZBbTjtMtH7t1jnvbY//i/+ mtFJJWQKFOJknxyMqEb/AEY/KPJSo9Xb1E4vqdNqouya5IqyAYcI1rre1zPTsd/L/Rq8kkRYpUJ8 EhKhKjtL5T5vndn+MDOxbXUZnSaWXVmH1ncxw7/Re1ydv+Muv87pFZ+FoH/ohy7HrP1e6X1qoMzq pewEV3MO2xk/uu/75ZvrXm/XfqP1npINtbftuIP8LSDuaPG6j3PZ/WZ6taqZBzENRLij5C3oeSyf CeZAjkwjDl/dOTJGEv8AZz4/+a7P/jmY/wD5Ts/7eH/vOiM/xoYzNB0wtnnbaP8A0k1eel4W/wDV v6n9S63ay17HY/TwQbL3jaXNn3DG3NPqP/l/zSjhlzyNA39ItvmPh/wvFAzyQ4Yjvky/9++i/Vr6 xu6/Vde3DfjUVENbY524PcZ3tZDW/wA3+d/XW2gYWHjYGLVh4rBVRS3axg8P+/Od9J7kdX4ggDiN nqXlc8scskjih7eO/RC+Ko+Jk//V9VSXC/UX/GLl/WnrF3TrsKvGbTjuv3seXElr6qtvua3/AEy7 DqeW7C6bl5jGh7saiy5rCYDjW11gaXa/S2pKbSh6NPqersb6sRvgbo8N30lyP1C+vWT9ax1A3YjM b7C2ot2OLtxs9bncP+BVb6if4xMv61dVuwLsKvGbTjm/ex7nEkPrq27XN/4VJT3SSzfrH1Wzo3Q8 zqlVYufi1+o2txIB1A1cFj/UL65ZH1sxcu+/GZi/ZrGsaGOLp3N3a7g1JT1SS5b6+fXUfVPDxbK6 BlZOXYW11OcWtDGAG6zc0O+i59TNv/CKH1D+vdX1sqyWW1Nxc3GcCaGu3B1Tvo3M3bX+2z2W/ufo v9Kkp6xJcL1b/GLl9G+uFfQeoYVbMO2ysNzN5b+iuhrLyHjZtpsP6b/irV1/Vs9vTOl5nUXN3jDo sv2TG702us2bv5e3YkptpLzf6q/42retddxel5mFVi15RcxtzbCYs2l1Tdr2/wCFe30f69i7X6y9 br6D0PL6rY3f9mZLK+N1jiK6Wf2rXs3JKb5ooNouNbDaNBZtG6P6/wBJEXJfVP67nq/Qczr/AFdl PTcHFsNYfucZ2tY57zub7t77q6qWV/pLLf0awP8Ax3eo5+VbT0DoF2cyrXcC97yzhtj6Mamz0f8A t2xJVl9MSXn2B9ffrpk5+Nj3/VbIoputrrtudXeAxjnNbZa4upDfYw7lZ+vn+MPL+qvU8fCpw68l l9AuL3vc0g7317drWn9xJT//1uQ+of1gy+gdbvzMTp1nVLLMd9JoqLmua02U2et7Ksj2t9LZ9D/C LtOp/wCMzreX03LxX/VbKpZfRZW60vsIYHMc11jv1Nv8233/AElj/wCJhrm/WzL3NLZwbYkR/hsV esfWGf2B1KOfsl8R/wAW9JT5v/iQ465/Vxv/AHaWf/iT/wDFLmf+Enf+fcdaX+I5pDutBwiRi8+B +1LG6KOqf4tfrRbd1TCtyMKyt2Ocipp2vrc6u1t2O922p9jfSb+hfYkp9P8Ar/8A+I3q3/hc/lau U/xIf8mdT/4+v/qCqX1s/wAZ2F9YeiX9G6Hg5bsnN2sc6xjNGBzXv2MofkutdZs9L/BqGFVm/Uf/ ABdZhzWmnq3XLCzFoaSLWMfWGb7Gj31W01evd7f5p78euz07UlNd3UKvrZ/jObkX5VVPSekWB1Vj 7Gema8Z42em922u37dl/pP8AwvZ/wKBk9QxPqd/jLOfhWMs6VmnfZ6L2Ob6OQf1hv6Lc1n2bLY66 uj/gKld+pf8Aip6d1joFPU+r3ZNN2UXPprocxoFP0anWNuot99m19vtf/MvqS+uv+Krp3RugXdT6 RblX3Yrmvurucx49H6Nr2Npoqdurc5ljvds9H1UlN7/HV0L1cXD69U2XY5+y5MST6bybMd/7rWV2 +qz/ANCGKX1v+tjcj/Ffg2ssL8nq7a8e1xMP3Vf098fnM9bH9F3/AIYVv6q3H66f4u8noeW/9ex2 fZS55gyzbd03Is2Df6e5ldb/APTfZ7l5d07G6h1LN6d9XL97KRmmsAt91br3U05f/bbcbds/4xJT tde6L/zb6b9U+u4o/T21Nvt9sD1Wvb1Ch1jx9Kz08n0P+LxV1P8Aje+sGNlfV/pOLiOLx1Nzc1pB APotZ+iFlf0v0z8n2f8Ahd66X/GT0NnU/qdlVUsAs6eBlY7QYAFIPqtgfS/VHXtYz9/YvK/qV0/L +sn1m6ThZkvxenMkyIiil78oVO/fa/Iv9H+pakp6769dOf8AVv8AxY9P6PXAc++qvMIMhz3Nuzb/ AHfnN+01ez+Qsj6j/XHM+r/RRj4P1bvzjdY59udW54FhB2tb7cW/+Zb+j2+r/wCfF6R9efq5Z9Y/ q7f0+gtGUHMuxnPMND2HuRP06nW1f21539Vvrt1j6lUWdB650u99NNjjTHsfXuO61jdw9LIofZ+l qsY/8/8AwtdlfppT0uB/jM61lZ2Ni2fVfJoZkWsqdc59hDA9zWGx04bPobt30lzH+O3/AMUGD/4T H/ny1dPg/wCN7p2bnY2G3puSx2VdXS17iyAbHNqDj/nLmv8AHWx7vrBg7Wk/qY4E/wCEtSU//9k4 QklNBCEAAAAAAFUAAAABAQAAAA8AQQBkAG8AYgBlACAAUABoAG8AdABvAHMAaABvAHAAAAATAEEA ZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwACAANwAuADAAAAABADhCSU0EBgAAAAAABwABAAAA AQEA/+ESSGh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8APD94cGFja2V0IGJlZ2luPSfvu78n IGlkPSdXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQnPz4KPD9hZG9iZS14YXAtZmlsdGVycyBlc2M9 IkNSIj8+Cjx4OnhhcG1ldGEgeG1sbnM6eD0nYWRvYmU6bnM6bWV0YS8nIHg6eGFwdGs9J1hNUCB0 b29sa2l0IDIuOC4yLTMzLCBmcmFtZXdvcmsgMS41Jz4KPHJkZjpSREYgeG1sbnM6cmRmPSdodHRw Oi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjJyB4bWxuczppWD0naHR0cDov L25zLmFkb2JlLmNvbS9pWC8xLjAvJz4KCiA8cmRmOkRlc2NyaXB0aW9uIGFib3V0PSd1dWlkOmU2 NTBlYTY0LWQ2N2EtMTFkYS1iYjVhLWUyZmVhOGI3NjFlMycKICB4bWxuczp4YXBNTT0naHR0cDov L25zLmFkb2JlLmNvbS94YXAvMS4wL21tLyc+CiAgPHhhcE1NOkRvY3VtZW50SUQ+YWRvYmU6ZG9j aWQ6cGhvdG9zaG9wOmU2NTBlYTYyLWQ2N2EtMTFkYS1iYjVhLWUyZmVhOGI3NjFlMzwveGFwTU06 RG9jdW1lbnRJRD4KIDwvcmRmOkRlc2NyaXB0aW9uPgoKPC9yZGY6UkRGPgo8L3g6eGFwbWV0YT4K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCjw/eHBhY2tl dCBlbmQ9J3cnPz7/7gAOQWRvYmUAZIAAAAAB/9sAhAAMCAgICQgMCQkMEQsKCxEVDwwMDxUYExMV ExMYEQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAQ0LCw0ODRAODhAUDg4OFBQO Dg4OFBEMDAwMDBERDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz/wAARCAEsASwD ASIAAhEBAxEB/90ABAAT/8QBPwAAAQUBAQEBAQEAAAAAAAAAAwABAgQFBgcICQoLAQABBQEBAQEB AQAAAAAAAAABAAIDBAUGBwgJCgsQAAEEAQMCBAIFBwYIBQMMMwEAAhEDBCESMQVBUWETInGBMgYU kaGxQiMkFVLBYjM0coLRQwclklPw4fFjczUWorKDJkSTVGRFwqN0NhfSVeJl8rOEw9N14/NGJ5Sk hbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2N0dXZ3eHl6e3x9fn9xEAAgIBAgQEAwQFBgcHBgU1AQAC EQMhMRIEQVFhcSITBTKBkRShsUIjwVLR8DMkYuFygpJDUxVjczTxJQYWorKDByY1wtJEk1SjF2RF VTZ0ZeLys4TD03Xj80aUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9ic3R1dnd4eXp7fH/9oADAMB AAIRAxEAPwD1VJJJJSkkkklKSSSSUpJJJJSkkkklKSSWb13ruH0TDOTknc92lNI+k93gP5P770CR EEk0AvxYp5Zxx44mc5moxHVu5GTj4tLr8mxtNTBLnvIAH3rleo/4xMKpxr6bS7JI09V/sZ/Zb/OP /wCguK6v17qHWsg3Zb/YD+ioboxg/kt/e/lqqwKjl5yRNY/SO/6T1HJ/8XcWOIlzR9yf+bieHHH/ AAvmm9HkfXTr+TIbc3Hae1TQCP7b97lRtz8/KJORk22zyHPJH+bO1UmBHYFXlknL5pE/V0I8tgxf zeKEP7sQD/jPof1S6o7O6aKrXTfiwxxPJb/gn/8AfFuLz36q5pw+rVAmK8j9E/5/zZ/z16EtHlsn HjF7x9JeT+K8uMPMy4RUMn6yP1+aP+MpJJJTNBS5PqWbZlZrrGOLWM9lcGNB+dp+8t/rGScfBeWm H2exvz5/6K5hjFU5ue0B/eP7HS+HYgBLKR/Uj/3TYp6h1CqNt7iB2d7h/wBJXqOv5LdLq22Dxb7T /Fqz2sUtirxy5I7SLZyYsM/mhH6DhP8AzXosXqWLlaMdtf8AuO0P/mStLkiwjUaEcFanTuruBFGU ZB0ZafyP/wDJK1i5kE1PQ9+jRz8lQMsR4h1ifm+jspJJKy0lJJJJKUkkkkpSSSSSlJJJJKUkkkkp /9D1VJJJJSkkkklKSSSSUpJJJJSkkkklIcvKow8a3KyHbKaWl73eQXj3Xes5PWeoPy7iQz6NNfZj PzWf+TXYf4yuqurox+l1uj1v0twH7rTFTf7T9zv+trz5Z/OZSZcA2jv/AHnrv+LnIxhh+9TH6zLY x/1MQ/79IxHYgMR2Kq7k2wxWGKuxWGItWbYrJaQ5ujmmQfML07CyRlYdOQP8KxrvmR7l5ixdz9Uc j1el+kTrQ8tjyP6Rv/VK1ycqmY/vD/ouD8cxcWGGTrjlX+DN3EkklfedcD6w3bsiqgcVt3H4u/8A OVnsClnXetnXWTI3Fo+DfaPyJMWZllxTkfF28UODDCPYa+cvUUrGogYmYjCITVkpG2u5qC9qtPhV 3oL4F1ui55tacW0y9glhPdvh/ZWquQrudRcy5n0mGf7wutre2xjbG6teA4fAq9y2TijwneP5Ofzu EQmJx+Wf/S6skkklYaikkkklKSSSSUpJJJJSkkkklP8A/9H1VJJJJSkkkklKSULba6a3W2uDK2Au e92gAGpcV5f9Zfrjl9Rz2HBsdRiYjw6iNC57f8O//vjFFlzRxizqTsG98P8AhubnchjD0xiLnkl8 sf3Y/wB6T6mksf6s/WCnrmALdGZNUNyKvB377f8Ag7FsKSMhICQNgtXNhnhySxZBwzgeGQUkkkix vkv13yjk/WTK19tO2pv9lo3f9PesFaf1lJP1g6hP/ciz/qlmLHyG5yP9Yvo3JREOVwRGwxwH/MSM R2KuxHYU1km2WKwxVmFHYUWrMNli6n6l3kZGRR2exrx8Wnb/AN/XKsK3Pqrd6fWKhMCxrmH7tw/6 lS4DWSJ8a/xnM+I4+Plso/qmX+J6/wDuXu0O+z0qLLf3Gl33CURUOt2+n0u8zBcA0f2iGrSmajI9 gS8rijx5IR/ekI/a8ux06nk6lWGFVGORmuWW9BOLba5E3qq16nvSYDBK56C9yYvQ3PSXRgxeV0nQ 7TZ02ueWEs+4rl3uXR/Vsz08/wDGO/76p+VP6z6Fh+IR/o4PaQdVJJJX3HUkm41K4P6z/WO3Lym0 4VhZj4ztzbGmC6xv+E/qM/MUeXLHHGzr2Da5LksnNZOCHpAFymflj2e9SWH9WfrEzq1Ho3ENzqh+ kbwHj/Ss/wC/rcToTE4iUTYLFnwZMGSWLIOGUf5cUVJJJJzEpJJJJT//0vVUkkklKSSWH9buu/sb pTn1mMrImvHHgY91v/WmoSkIxMjsGTBhnmywxYxc8h4Q8x9fvrMb7XdGw3/oaj+tPH5zx/gf6lf5 /wDwi4pIuLiXOJLiZJPJJSWTkyHJIyL6DyXKY+VwRw4/0fml1nP9KZdDonWcno3UGZlBkDS2vs9h +kw/99XsGBnY3UMSrMxXb6bm7mnuPFrv5TV4eun+pP1l/ZWZ9jynxg5J1J4rsOjbP6jvo2Kblc/A eGXyy/5pc3478M+84/fxD9fiGoH+Vx/u/wB+P6D6ikmTrReMfH/rfS6n6yZ7T+dZvHweBZ/35Y66 7/GTh+l1enLA9uTUAT/KrO0/9B1a5FZGaPDkmPE/i+h/Dcoy8ly8x/m4xP8Aeh6Jf86K7eUdhQEV hTGzIaNlhVhhVVhR2FFrTDaYVo9IuFXUsWw8C1k/Anb/ABWWxysUWbLGP/dcD9xlGJog9i1M0OKE o/vAx+19VWL9abduBWzu+0fgHFbIIIBHB1C5z64WADFrnWXuj/NC0+YNYpeX5vI8hHi5rGPEn/Fj xOI1yK16qNeites16CUG0HqXqKsHp96TGYJy9Dc9DL1EvSSIMnOXVfV1hb0utx/Pc534x/31cc56 7zp9H2fBopiCxjQfjHu/6Ss8mLmT2H5tL4qeHDCP70r/AMUf+hNhJJZvXusV9KwjYIORZLaGHu79 8/yGK7KQiDI7ByMWOeWcccBcpGgHJ+t/XTQw9NxXRbYP1h4/Naf8H/Ws/wCoXEPKLfa+2x1lji97 yXOceSTyVXeVl5chySMj9B2D2XI8pHlsQxx1O85fvzXx8zIwsmvKxnbLqjua78rXfyXfnL1LonV6 Or9PZl1e130ba+7Hj6TP/IryV5Wr9U+unpHVWix0YmURXeOwP+Du/sO/6Cfy2bglR+WW/wDFj+Lf DvvOAzgP1+IXH+vD9LH/AN4+qJJJLSeOUkkkkp//0/VUkkklKXkv116uep9ctax04+JNNQ7e0/pX /wBqxem9azfsHScvM701OLf60bWf9NeJkkmSZJ5Kp87PSMO+pej/AOLPLAzy8wR8n6uH96XzqTpk 6ovVBSSSSSX0n6hfWT7bjDpWU6cnHb+hcTq+sfm/16v/AD2uvXhuJlX4eTVlY7tl1Lg5jvML2HoX WKOs9OrzKva4+22v9x4+mz/yK0OVzcUeCXzR28YvHfH/AIb7GX7xiH6rKfUB/k8v/e5HG/xidPOT 0RuU0S/DsDj/AFH/AKN//S9NeYr3LMxa8zEuxbRNd7HVu+DhtXieZi2YmVdi2iLKHurd8Wnaoedh UhP94V9Q6P8AxZ5njwZOXJ9WKXHH/Z5P/Q0KmwqCcaKq9A2GOR2OVRjkdjkmGcW2xyKHaFVWuRWu Ra8ovrWE7fh0P/erYfvaFzH1zs/XcdvhUT97v/MV0PRLPU6Rhv8AGln/AFIXKfXO3/K7G/u0t/Ev K0OYP6gePC8n8Nx/0+Q/c9z/AL1zGvUw9VWvUw9UHflBtB6feqwen3pLOBOXqJeg70xekkQb/S6D mdRoo5aXhz/6rfe78i79ct9TMTcb85w/4Kv/AKuw/wDULqVocrCsd/vG/o8/8Wy8XMcA2xDh/wAO XqkjyL6sah99ztldYLnOPgF5t1nqtvU81+S/Rv0amfusHA/8mtb64dc+0Xfs7Hd+hpP6Zw/OePzP 6tX/AFa5dzlBzWbiPAPljv4ydX4NyHtQ9/IP1mQekfuY/wDvprPcgvcne5Be5VXdhFi9yA8qb3IL jJQbEA+sfUrqx6n0Sv1Hbr8X9Db4naP0b/7Va315v/i2zTV1W/DJ9uTVuA/lVmf+oc9ekLU5efHi iTuPSfo8L8Z5YcvzuWMRUJ/rYeWT/wBD4lJJJKZzn//U9VSSSSU85/jAscz6s3gGN762n4bg7/vq 8oC9Z+vtLrfqxk7RJrNbz8A9s/lXkwWfzn84P7r1/wDxbI+5yrf3ZX/iwXTpklVd0LpJJJLlLd+q P1gd0XqQ9Qn7HkQzIb4fu3f9b/6hYSSMJGMhIbhiz4IZ8U8WQXCY4T/H/Bfd2ua5oc0gtcJBHBBX nH+MbpP2fqFfUqxFeWNtkdrGD/v9f/ULV/xffWH7TjnpGS6bqBOMTy6sc1/9a/8APf8AUXQfWPpI 6v0i/DA/Skb6T4WN9zP876C0Z1nw2N9x/eHR43ljP4X8SEch9F8E5dJ4Mny5P+7fGkk7muY4scC1 zTDgeQQmWa9uyaYRWuQFJroSQRbaa5Ga5VGuRWvSYZQfWfqy7d0DBP8AwQ/Bcl9cn/5dePCqv8hX U/VMz9XcE/8AB/8AfnLj/ro+PrDcPBlf/Uq/zH+54f4P/ReV+GR/4U5gdvd/9KuaHqQeqoeph6ou +YNkPT71W3p96S322xvTNLnvaxg3PeQ1o8SdAEDet/6mdOOX1E5bxNOJqPA2H6H+Z9NPhEzkIjqW LmJxwYZ5ZbQF+cv0Y/4T2fS8JuBgU4o5rb7z4uPue7/OWf8AWjrY6XhbKj+t5Etq/kj8+3+z+b/L WrlZNOJj2ZN7tlVTS57vILyzq3Vbup51mXbpuMVs/dYPoMV7mMoxwEY7kUP6sXn/AIXycub5iWbL rjgeOd/5TJL1cH/ftdz55Mk8lCc9Rc9Dc9Zz10YLucguck5yE5yDNGKnOUEkkmV2/qZY6v6y4JaY 3Pc0/BzHheuryT6k0ut+s2HtGjC57vg1jl62tDkv5s/3nj/+M9fe8ff2hf8AjzUkkkrTgv8A/9X1 VJJJJTW6jhszsDIw38X1ur+bhAK8QtqsotfTaNtlbix7T2LTtcF7wvNv8YnQTi5o6vQ39BlHbfH5 toH0v+ut/wCmqvN47iJj9Hfyd7/i7zYx5p8vI0M2sP8AaQ/R/wAOLxydME6oPWhdJMnQXKSSSSSm w8u/CyqsvHdsupcHsPmF7J0bqtHV+nVZ1OnqCLGfuvH85Wf6q8VXTfUbr/7M6l9kvdGJmENdPDbO K7P++PVjlc3BPhPyy/Nx/jvw/wC88v7sB+uwAyH9fH+nD/uoM/r/ANF+w9V+21NjHzZdpwLB/Ot/ t/zi5Zey/WLpDOsdKuxDHqxvod4WN+h/nfQXjljH1vdXYC17CWuaeQRoQhzWLgnY+WWv16p+A899 45UQkf1uCoS/rQ/yc/8AuWKSSSgddkHQiNegpwYSQRb6/wDVDX6tYH/Fn/qnLivru6PrJeP5FX/U rtPqh/4msD/iz/1Tlw/17MfWW/zrq/6lXuY/3PD/AAf+i8p8JF/F+aH+2/8AS0XID1IPVYPUg9UX pDBs70t6r70t6K3gbAc5xDWgucTDQOSTwF6l0Dpg6X0urGI/Skb7j4vd9L/N+guL+ovSft3UTnWt mjCgt8Dafof9tt/Sf5i6/wCs/W29G6Y+9pH2m39HjtPd5/P/AKtf01c5WIhGWWX08nnfjWWWbPj5 HD6pWDP/AGkvkj/gQ9cnmvr1131rx0rHd+ipIdkEd7Pza/8ArX/VrkS9Dfa57i97i5ziS5x1JJ1J KgXqrkyGcjI9Xe5Pk4cthhij+iPVL9+f6UkjnobnqBeoEkpjbEGTnKCSSS9SSSLjY92VkV41DS+2 1wYxo7kpIJABJNAakl7L/Fp04uycnqTm+2toprP8p3vs/wA1rW/569BVDofSqukdMpwa9SwTY/8A eedbHq+tbBj4MYj13Pm+f/E+b+9c3kyj5L4cf+zh6Y/43zqSSSUjSf/W7i/65dFxus29IyrPQtq2 /pnfzZc4b9hf/g3N3fnrca5r2h7CHNcJDgZBB8F4R1zLdmdazslxn1L7CPhuLW/9FXehfWvrHRXA Y1u/H/OxrJdWf6o/wf8A1tVhzNSIkNL0IdyfwTixQlhlWThHFCfyylXq4ZfovtaBm4ePnYtmJksF lNzdr2n/AF+k1YXQfr10fq22m132PLOnpWn2uP8AwVv0Xf2l0inEozGhBDkZMWbl8gE4yxzibH0/ SjJ8c+sn1by+g5ZY8GzFsJ+z3xo4fuP/AHbWrIXuWdgYnUMV+Jl1i2mwQWn/AKpp/Ne1eW/Wf6o5 nQ7DdXN+A4+y4ctn8y+Po/11Rz8uYeqOsf8AovV/CfjMeYAw5iI5xoDtHN5f6z+q4CdRTqq7gXSS SSXKSSSSU+q/Unr37V6WKbnTl4kMsnlzf8Fb/wB9eub/AMYfQ/suY3qtDYpyjtuA4FoH0v8ArrVg fV/rFvRuqVZjZNc7b2D86s/TH/f2r1nPw8TrXS347iH0ZVYLLBrE+6q1v9X6SvQPv4TA/PH+UXle ZifhXxKPMQH9Gz3xRHQS/nYf4H85jfFEkfOwr8DLtw8hu22lxa4fD84fyXfSQFRIo0XqYyEgJRNx kLBHUFSSSSSX2H6piPq5gf8AFA/eSuD/AMYOn1ksPjVWfwXoH1Zbt+r3Tx/wDD94lcF/jFbH1hn9 6is/i8fwV/mP9zx/wfyeS+DH/hfP4+9/6UeZDinD1BJUHraSb0Siu3IuropaX22uDGNHdzjDVXXc /wCLroO97utZDfaya8UHx4tt/s/zbf7afixnJMRH18mpz/NQ5Tl55pfoioR/fyH5IvYdG6ZT0fpd WI0j9G3dbZxuefdbYV5l9auvHrHVX2MdOLTNeOP5IPus/wCuuXX/AOMDrv2LAHTaHRkZg/SEctq/ O/7d+h/24vNFY5vIBWKO0d/2ByPgHJylx8/m9WTMZe3fY/zmT/D+VkXppKZJVHolJJJJKUkki42N flXsx8et1t1hhjGiSSkgkAEk0BqSUbWue4MYC5zjDWjUknsF6Z9S/qmel1/tDOb+vWiGMP8Agmn/ ANGv/PU/qp9TKekhuZm7bc8j2jltU/ufvWf8IuoV/luW4anP5ug/deT+M/GveEuW5Y/qtsmX/O/1 If6v/pqSVXqHU8DptBvzbm0s7buSfBjB7n/2VwnXP8YmVkbqOkMOPUdDkPg2H+o36FSnyZoY/mOv 7o+Zy+S+G8zzZ/VQ9HXLL044/wCF+l/gPadW6/0vo9e7NuDXkS2lvusd/Vr/AO/OVb/nRh/83v27 sPpf6GRu3b/S9Of3l5JbdbfY6257rLHmXPcSST5uK1v2i/8A5p/s+dPtm6P5OzdH/biqjnTxE8Pp A26793cl/wAWcYxQiMpOaUvVkI9AjwT9Mcf9/gf/1+M3lzi52pcZPxKm0qfUaTjdRysciPSusZH9 VzmoTSs6Qe0xTsA90oK6XoP146v0nbVY77ZiDT0bTq0f8Fb9Jv8A1C5gFTBTBKUTcTTPPFizw4Ms BOJ6H/uf3X2non1p6R1poGNbsyIl2PZ7Xj+r/pP7C1rK67a3V2ND2PEOa4SCD2IK8EY97HB7HFrm mWuBgg+RXYdB/wAYmfh7aOqA5mONPVGlrR8fo3f2/wDPVrHzQOmQV49HD5z4BON5OVlxga+3I/rB /cn+k3frN/i/cwuzOiNLmcvw51H/ABBP0v8Ai1w7muY4seC1zTDmkQQR2IXtfTOsdO6rR62De21v 5zRo5vlZWfcxZ/1g+qPTettNhH2fMj25DBz/AMcz/Cf9Wm5eVEhxY616fon+6ych8dyYJexzolUf T7hH62H+1j+n/wBN8jTrR6z9X+p9Fu9PMr/RkxXe3Wt3wd+9/Ics1UpRMTRFF6fFlhlgJ45CcJbS ibC6SSSDIpeh/wCLrrnrY7+kXu/SUDfjzyWH6df/AFty88Vnp2ff07OpzccxZQ4OHgR+cw/yXt9q kw5DjmJdNpeTT+JcmOb5aeL9P5sZ/dyR+X/vXu/8YfQfXx29Yx2zbQNuSB3r/Ns/61/1H9Redr2/ EycXqfT68iuLMfKrnaddHCHsd/1D15P9Z+hv6L1R+OAfs9nvxnnuw/mz+9X9BT83i1GSO0t/4uV/ xe54mMuSzaZMN+3xb8A+fH/exuQkkkqj0L7Z0ZmzpGE3wx6h/wBBq4L/ABlsjrGO/wDexx+D3r0P CZsw6Gcba2D7mhcF/jOZGdgv8anj7nf+ZLR5kfqPLheL+Bzv4oD+/wC7+Rk8Ukkks57RvdG6Vf1b qNODTp6hl7/3WD+cs/stXr4GF0jpukVYmHX9zWj/AKpyw/qN0D9mdO+13tjMzAHOB5ZXzXX/AGvp vWX/AIx+twK+jUO5i3Kjw/wVX/oz/ttXsURgwnJL5pfyjF5TnssvinxCHKYj+oxE8Uh/V/nsv/qP G8f1fqd3Veo3Z130rXe1v7rRpXWP6rVSSSVEkkkncvUwhGEYwgOGMAIxA6RipJJJJcpJSYx9jwxj S97jDWtEknyAXZ/V7/F9dftyuszTVy3FGjz/AMa7/B/1f5z+on48cshqIv8AJrc3zuDlYceaYj+7 Hec/7kXneifV7qXWrvTxGRU0xZe7Rjf7X5zv5DV6d0H6tdP6HTFDfUyHCLch30j/ACW/6Ov+QtLH x8bDobTQxtNFY0a0Q0ALmuu/X7p2BuowIzckaSD+iaf5Vg/nP+tq9DFjwDimRxd/+9Dy3M89zvxX J7PLwlHD+5H/AKWfI9NkZFGNS6/IsbVUwS57yAB8yuL67/jFrZuo6Mz1HcHJsHtH/FV/nf8AXFx3 VeudT6vb6mdcXgfRrGjG/wBSsKgoMvOSOkPSO/6Tp8h/xcxY6nzR96f+bH8zHz/zifMzszOvN+Zc 6+0/nPM/Jv7qAkkqpJOpd6MYxAjECMRoANAFIu532Xb+b6k/OEJaH2R37A+2R7ftfpT/ANb3ogbo lIAxHc0P8WRf/9DN/wAYfT3YX1oyXR+jyw3IYf6w22f+CseucaV6t/jO6G7O6SzqVLZu6eSXxyan fzn/AG273/8Abi8nVLNGpnx1el+H5/c5eBv1QHBL/BTNKmCgtKICoSHUxzSgqQKGCpAphDZjJtYm ZlYd7cjFtdTa3h7DBXddB/xkNdtx+tM2ngZVY0/67UP+qr/7bXnoKkCnQyzxn0n6dGLmuR5fm41l hZ/RnH05I+Un3ScHqWJp6eVi3DyexwXFdf8A8XRG7J6K6RycR5/882u/6iz/ALcXIdJ671Po93q4 NxYD9Oo6sd/XrXonQfr70zqW2jMjCyjoA4/o3H+RYfo/1bFZGTFmHDMcMv5fLJw5cl8Q+GSOXlZH Nh3lGr0/1uH/ANSY3zK+i/GtdTkVuqtYYcx4IIPwKgvaOrdC6X1mn082oPIHstbo9v8AUsXnvXfq H1Ppu6/EnNxRrLB+kaP5dX53/W1Bl5WcNR6o+G7qch8d5fmKhk/UZf3ZH9XL+5P/AL55lJLUGDoQ kq7sPdf4uOtbX2dHudo6bcafH/C1j/z5/wBuLpfrV0JvWulvqaB9qpl+M7+UP8H/AFbforybDy7s PKqyqDttpeHsPmCvaOmZ9PUsCjOp+hewOjwPD2f2H+1X+WkMmM4pa1/0f/QXlPjmCfKc3j57D6eM 2f6ueP8A6th/6kfE3sfW9zHgte0lrmnQgjkFSx2b8ipn7z2j7yuy/wAYX1e9K39s4rf0dpDcpo7P 4bd/1z6L/wCWuW6LV63WMKr9++sH/Oaqk8Zhk4D30eg5bnYcxyn3iGnpJnH9ycB64vtQECPBcP8A 4z6/0XT7PB1rfvFZ/gu5XH/4zKt3Sca39y+P85rv/ILQ5kXhn5PHfBZcPxHAe8pR/wAaEovm66X6 j/V/9qdR+1XtnDxCHOnh7+a6v+/2LCwMHI6hmVYeM3dbc4NaOw8XO/ktb7l7H0jpdHSun1YNA9tY 9zu7nn6djv6zlT5XDxy4j8sfxL0nx34j92we1jP67MKHfHj/AEp/9zBJ1LPp6dg3Zt383QwuI8T+ awf13e1eL5uZdnZd2Xed1t7i9x+PYf1V2P8AjH61vtq6PS721xbkR3cR+iZ/Zb71w6PN5eKfANo/ 9JZ/xe5L2eXOeY/WZ9R/Vwj5f8f51JJK503pPUOqX+hg0utd+cRo1o8XvPtYqwBJoCy7U5xhEynI RjHUykeGI+rTWz0P6q9U604OpZ6WNPuybBDf7H+ld/VXYdC/xfYWHtv6oRl3jUVD+aafP863+17F 0XUOqdN6RjC3LtbRWBDGDkx+bVW36St4+U04sp4R2/iXA5z/AIwXL2eRgc2SXpGSrjf+rx/ptPoX 1V6X0VodSz1sqIdk2CXf9b/0Tf6qbrn1r6V0YFlr/Wyu2PXq7/rh+jV/aXHde/xgZ+duo6aDh450 Nk/pXD+sP5r+x/nrkyS4lzjJOpJ5JTp81GA4cIHn0YuW+BZ+Yn7/AMQySJlr7d3P/Dn/AJOP9TG7 XXPrb1XrJNb3+hinjHrJAI/4V30rViJJKnKUpG5Gy9FhwYsMBjxQGOA/RipJJJBkUkkmSQpeg/sN /wD43fp7T6237bEa87//AG3XH/V/pNnV+rUYTR7HHdc7wrbrYf8Avq9l9Kv0vS2j09uzZ22xt2qa EP1WSflEf40XN5nmh9/5PlgdScmWfkMOWMP+7f/R9TexljHV2NDmPBa5p1BB0c0rxT64/Vm3oHVH MY0nByCX4tnOnelx/fqXtqoda6NhdawLMHNbNb9WvH0mOH0bKz+81MyY+MeI2bXJc2eXyWdYS0mP +6fAwVNpWl9Yvq31DoGYcfKbuqcT6GQ0ex48v3X/AL9aygYVKUSDRelxZYyAlE8UTsQmBUwUFpRA UwhtwmlBTgoYKkCmENiMkgKdQBUgU2mUSei6B9dOq9ILanu+1YY09Gw6tH/A2fSZ/wBQvRui/WTp fWq5xLYuAl+O/Sxv9n89v8ti8YlTputpsbbS91djDLXtJBB8nBTYuZnDQ+qPY/sc3nvg3L81c4j2 cx/TiPTL/aQfW+t/U/pHWN1jmfZ8o/8AaioAEn/hGfRsXn/W/qh1jo82Pr9fGH+HqkgD/hG/SrW5 9X/8Ytle3G60PUZwMpg9w/46sfT/AK7F3eNk42ZQ2/GsbdS8aPYQQVYMMOcXH0y/H/Ci5Eea+JfC pDHmHu4No8Xqxkf6rL+h/c/5j4au4/xb9Z22W9Hud7Xzbjz+8P51n9pvvW31v6i9I6lutxx9iyTr vrHsJ/l0/R/zNi4nK6F176s51Waai9mO8PZkV+6swfz/AM6vd/wigGPJgmJ1cRuY/uupLneT+Kct PlxL280hcIZPTL3Y/JwS/TfVsjHpyqLMe9ofVa0se08EFebYPQL+lfXbEwny6sW+rRYfzq2h1jT/ AFm7Nr16Pg5dWdh05lP83ewPb8xwiOppfYy1zGusrn03kAubu+lsd+buVzJijk4ZfukSB/qvOcnz 2XkxnxEExywnjlA/oZa4Iz/wf0ma5r/GFUbPq493+itrefv9P/0YulULqab6zVcxtlbvpMeA4GNf ouT5x4oSj3FNflc/scxizVxe3OM6/eEejyv1D+rn2DE/aWUyMrKb+jaRqyo6/wCfb9JdJ1LPp6dg 35tx9lDC6PE/ms/tu9qsriP8YOdk5NuP0LCY+2x8XXMYC4n82pvt/tPUcqw4vT00H9aRbeL3PiXP g5TQmeLJr6cWDHvH/F9LwmZlXZmVblXndbc8vefMlLEw8rMuFGLU6613DGCSuv6L/i5yLdt3V7PQ Zz9nrILz/Xs+hX/Z3ruOn9L6f0yn0cGhtLO8D3Hze8+96qY+UnPWfpB/xnoOc+P8ry49vlwM04jh HDpghX9f9L/AeO6J/i4Ptv6zZ5jGqP8A59t/9J/9uLtKaMHpuLspZXi41QkxDWgfvOd/5JZfXvrd 0vozTW532jL7Y9ZEg/8ACu/wX/Vrzjrf1l6p1p/61ZtoBlmOzRg+X57v5T1MZ4cAqA4p/wAvmk5u PlfiPxWQyZ5nFy+4scMP+o4f0v8AaTet69/jEpp3Y/Rmi6zg5Lx7B/xbP8J/a9i4TMzcvOvORl2u utdy55n5D91ASVTJmnkPqOnbo9FyXw7luUjWKHqPzZJerJL/AAlJJJKNuKSSSSQpJMkkq1JAEkAC SdAAkASQAJJ0AC9B+pf1MdjuZ1TqjIuHux8d35n/AAto/wBJ+4z8xSYsUskqH1PZp89z2LlMRyZD r+hD9LJLsHU+pP1cPR8A35LYzsoA2A8sZ+ZT/wB+sXSJJLS9qPt+3+jVPE/f8/3v73f63i4v6tfL 7f8Ac4PQ/wD/0vVUkkklNbqHTsLqWK/Ezqm30P5Y7x/eafzHt/eavNPrF/iyz8RzsjoxOZj8+g6B c0fyeG3f+fF6okmTxxlv9rY5fm8uA+g+nrA/KX53tqux7DVex1VjdHMeC1w+LXJBy99z+k9M6kz0 8/GryG9t7QSP6r/ptXOZn+LH6t3kuo9bEceBW/c0f2bhZ/1Sgly8uhBdbD8Zxf5SMoHw9cXygFTB Xojv8U2HPs6jYB51tP8A35qQ/wAU+P8A+WT/APtof+lFGeXydvxbsfjPJ9ch/wAWf/evnoKkCvQf /Gpo/wDLJ/8A20P/AEqn/wDGqx//ACxf/wBtD/0om/dsv7v4hlHxvkf86f8AEyf96+fAp5XoP/jV 4/8A5Yv/AO2h/wClE4/xWY//AJYv/wC2h/6UQ+65f3fxDIPjvIf50/4mT/vXz6Vo9H691Lo1/q4V paD9Op2rHf12f9+XYf8AjW43/lg//tsf+TT/APjXYv8A5YWf9tj/AMmkOWzA2BR80T+NfDMkTDJP jhLQxljmR/0XY+r31z6b1kNpsIxc0/4F50cf+Bf+d/U+mugIDgQRIOhBXED/ABX4oMjqFkjgisf+ TXXdNw7MLBqxbb35T6hHrWfScJ03f1foq5iOWqyR/wAJ5vn4ciJcfJ5SQTrilGY4PGM5/othrGsa GMAa1ugaBAAUkklK0FJJJJKUo7Gb9+0byI3RrHhKkkkpBmZuJg0Oycu1tNLOXOMfIfvOXn31h/xg 5WXuxukzjY50N5/nXf1P9C3/AMEXR9e+po63mnJvz7WMAAro2hzGQIds1b9JZv8A42GJ/wBz7P8A ttv/AJJVs3vyuMBwx736pO38NPwnCI5eZyHLm34Djn7WI/4v6yT585xcS5xJJ1JPJKS9B/8AGwxP +59n/bbf/JJf+Nhif9z7P+22/wDklV+65v3fxDu/6f8Ah3+dP/heT/vXz5Jeg/8AjYYn/c+z/Mb/ AOSS/wDGvxP+59n/AG23/wAkl91zfu/iFf6f+Hf50/4mT/vXz1Jehf8AjX4n/c+z/ttv/kkv/Gvx P+59n+Y3/wAkl91zfu/iFf6f+H/50/4mT/vXz1Jehf8AjX4f/c63/Mb/AHo1P+LLpLHTdk32j90b W/8AfXI/dMvYfatP/GD4eBpkkfAQm+bLT6T9XOsdXeBiY7vTPN7/AG1j+276X9henYH1Q+r2AQ6r DY94/Ptmw/8Agkt/6K2AABAEAcAKWHJfvy+kf4ufzP8AxmFEcviN/v5f/VcP+/ec+rv1J6f0ctyL iMrNGoscPaw/8Cz/ANGOXSJJK3GEYCoig89n5jLzEzkzTM5HqfyiP0VJJJJzE//T9VSSSSUpZHXf rR0zoBqHUPVaLwfTcxhc0lv0m7v3tVrrL+snQsfr3SrcG2GvPuot/csH0H/99f8AyEJXRrdkxe37 kfcvgv1cO7iO/wAaP1YHAyHfCsfxehu/xq/V0cU5Lv7DP/Sq8tzcLJwMu3DymGu+hxZY0+I/7678 1AVU55+Dtj4XypAI4iD/AFn1R3+Nnog+jiZLviGD/wBGIR/xtdP/ADen3H4vaP8AyS8wSS9+ff8A BePhfKjeJP8AhSfTD/jax/zemvPxtA/9FqB/xsH83pv32/8AqJecBymHJpzZP3vwDND4ZyX+av8A wp/989+7/GtmH6GBUPjY4/8AfWqJ/wAafUzxh0D4l5/78uEDlIFMObL+82I/DOR/zI+2f/fPbO/x odaP0cbGHyef/RiC7/GV9YXfRbjs+DCf+qsK5EEkwNSeAuy+rX+L7MztmV1Xdi4pgtp4tePP/Qs/ rfpEozzTNRkUZuX+GctDjy4scR0BHFKXhGLZ6R9aPrt1vI9DBFUD+ctNYDGD+W87v81eiViwVtFh DrABvIEAuj3FoQsLBxMDHbjYdTaaWcMaI+Z/ecjq5jhKI9UjInu83zvM4s0x7OGGDHH5REeuXjkk pJJJSNRSSSSSlJJJJKcH60X/AFmxam5PRRXZVW0+vUW7rP67B+c3+S1cYP8AGL9YmmHCgkcg1n+D wvUVzf1j+pXT+sB2RRGLnHX1Wj2vP/DMH/nz6agzY8h9WOZH9W/+i63w3nOSiBi5vl4Sj0z8NzH+ 1/e/vPMN/wAZnWh9KjGd/ZeP/RimP8Z3VO+JQfhvH/flzPVekdR6TkehnUmt35ruWOH71b/ouVKV TObMDRkQfF6OPwz4bkiJxw45RlqJRJ4T/iye3H+NDO/Owaj8HuH96K3/ABo2fn9PHytP/pNcHKUp feM3734BB+DfDj/kB9JZP+/fQG/40qvzunO+Vo/9JqY/xo4f52BYPg9p/wC+hedylKP3nN+9+AWH 4H8P/wA0R/h5P++fSW/4z+lH6eJePhsP/f2ojf8AGZ0I805A/ss/9KLzGUpTvvWXuPsYz8C5DpGQ /wAMvqQ/xk/V48tyB/YH/k0Rn+MX6tuIAddJ0A9Mkk/2SV5RK7P/ABe/Vk5eQOsZbP1bHd+rtP59 g/P/AKlP/nxPx58s5CIr7Gpzfwn4fy+GWWZyAR2HH88v0Yj0vpLHbmh0Fu4AwdCJ8VJJJXXmVJJJ JKf/1PVUkkklKSSSSU8r9d/qbX13H+14gDOp0thp4FrR/gbD+9/onryG+i7HufRex1V1ZLX1uEOB HZwX0Que+tH1M6b9YGeq79XzmiGZLRzH0WXN/wAIz/pqHLi4tY7/AJulyPxD2qx5dcf6MusP/QXx RJbHW/qn1vojz9roLqAfbk1y6sj+t/g/+uLHVYgg0RTtwnGcRKEhIHqFJwUyudN6R1Pql3o9Pxn5 D+5aPaP69h9jP7SFWuMhEWSIgdS1g5avRPq/1Xrd3p4NJcwGH3u0rZ/Xs/7433rs/q//AIraai3I 65Z6zxr9lqJDP+u26Of/ANbXeY+Nj4tLaMattNNYhlbAGtA+AU0OXJ1loO3Vz+Y+MxgDHCOOX75+ Qf8AfPP/AFc+o3TOiht9oGXnDX1nj2tP/A1/m/1/prpUklZjERFAU4mbNkzTM8kjOR7/ALFJJJIs akkkklKSSSSUpJJJJSkkkklNfO6fh9Qx3Y2ZU26p3LXDg/vNP0mO/qrzz6w/4vMzE3ZPSS7Kx+TQ f51o/k/6b/z4vS0lHkwwyDUa9+rc5P4hzHKSvHK4H5sctccv+9fA3BzHFrgWuaYIOhBTSvY+u/VL pHWwX31+lkxpk1QH/wBv823+2vPOt/UXrfSy6ytn23GH+FpBLgP+Ep+m3/pqlk5acNR6h3D03J/G eX5gCMj7WT9yZ0/wJvPSlKiTBg6EchNKip0DNlKaU9NV2RYKqK3W2O0axgLnH+y1dr9Xf8W+Ve5u T1sminkYzT+kd/xjh/NN/wDBP6ifDFKZoBrczzuHl48WWYHaP6cv7sXJ+qf1UyevZIssDq+nVH9N dxuj/A1fy/8Az2vXMfHpxaGY+OwV01NDWMboAAmxsajFoZj41baqaxtZW0QAEVX8WIYx3J3LyfP8 /k5vJZ9OOPyQ/wC6l/XUkkkpGkpJJJJT/9X1VJJJJSkkkklKSSSSUsQCCCJB5BWVl/VT6uZji/I6 dQ57uXNbsJ/tVbFrJIEA7i10ZyibjIx/unhcOj6k/VWgyzp1Tj/L3P8Awsc9bFNFNFYrorbVWOGM AaB/ZaiJJAAbABM8k5/PKUv7x4lJJJIrFJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkk kpz876v9F6i7dmYdVr/3y2Hf9uM2vVGv6jfVat24YDXHwc57h/muet5JNMInUxH2MseZzxHDHLOM ewnIBrYfTsDBZsw8evHb4VtDfv2qykknVTGZGRskknqVJJJJIUkkkkpSSSSSn//W9VSXjjv8dvXA 4j9n4uhjmz/ya7v6gfWvL+tPS783LprofTeamtq3QQGsfuO8u/fSU9QkkkkpSS4j/GD9fM/6qZWH TiY1OQ3KY97jbukFpa327HN/eWH9Xf8AG31fq3XMLptuFj115dzanvaX7gHd27nJKfU0kLKtNONb c0Sa2OeAeCWguXkP/j3dc/8AK/F++z/yaSn2NJc99RvrJk/WXoY6nlVMosNr69lc7YZt195d+8uh SUpJJeafW/8AxpdV6B9YcrpWPh49tWPs22PL9x31stO7a4N/PSU+lpLz/wCon+MfqX1n6y/p2Vi0 UVtodbvrL90tcxu33ud++vQElKSSXIf4wPr076qVYteLVXkZmUS707CYbU3QvOyPpP8Aaz+2kp69 JeOf+Pd1z/yvxfvs/wDJr0n6o/WKv6ydCo6m1oZa6WZFTdQyxv026/8AbjP5D0lO0kkvKuvf42Pr D0brGX0y3AxS7FscwO/SDc3mqz6f59e16Sn1VJcD9Qv8ZOT9Zuq29NzserGeKjbQai73FpHqMPqO d+a7eu+SUpJJeZfWv/Gzn9G6/l9MwcSi+nFcGepYX7i/a02j2Oa32POxJT6akvHWf47us727+n42 yRug2TH5233r17HvryKK8io7q7mNsYfFrhuakpIkksL66fWQ/VroNvUmMbbfvZXRU8kNc5x77fd7 aw96SndSXjn/AI93XP8Ayvxfvs/8mvV+j5GZldKxMrOrbTlX1NstqZO1pcN+z3S72ykpuJLO611/ pHQsb7T1TJbjsM7GnV7yPzaqm++z+yuB6l/juxGOczpnTn3AH22XvFYP/Wqxb/58SU+npLxw/wCO 7rU+3p2MB5mw/wDfkv8Ax7uuf+V+L99n/k0lPsaS8p6J/jf6x1LrGF0+zBxmV5d9dL3tL5Ae4MLm y7zXqySlJLyPP/xzdaxc7Jxm4GM5tFr62uJskhjiyT7/ACQP/Hu65/5X4v32f+TSU//X8rf9N3xK 9m/xKf8AidzP/DZ/891Lxl/03fEr1b/FJ1/onTOhZVPUM6jFtflFzWWvDSW7Kxuh3wSU+ppLF/55 /VP/AMt8T/t1v96X/PP6p/8Alvif9ut/vSU+d/48P+UOlf8AE2/9Uxch9Rf/ABYdI/8ADLPyrpP8 cHV+l9Uzumv6dlVZba6rBYaXB4aS5sbtq5v6i/8Aiw6R/wCGWflSU/QvUP8Ak/J/4mz/AKly+XV9 RdQ/5Pyf+Js/6ly+XUlPuf8Aie/8Rzf/AAzb/wB8XbriP8T3/iOb/wCGbf8Avi7dJSl8/wD+NH/x cdR/6z/55qX0Avn/APxo/wDi46j/ANZ/881JKdL/ABM/+Ku3/wAKWf8AV1L25eI/4mf/ABV2/wDh Sz/q6l7ckpZzmtaXOIDWiSTwAF85fXXr5+sH1jys9pJxw70sUeFTPaz/ALc/nf8Ari9b/wAan1h/ ZH1afjUu25XUyaK4Oorj9Zs/zP0X/XV4n0npt/Vep4vTsf8AncqxtbT4bj7n/wBhvvSUtldMzMTF xMu+vZTnsdZju/eaxxqf/wBJq7b/ABPfWH7B1qzo97ox+pD9FPAvYJZ/27XvZ/20ux/xi/VOjI+p bKsKuH9EYH44A19Jjdl7P+2m+r/1peJY2Rdi5FWTQ4supe2yt45Dmnc13+ckp+pl4/8A46ei+j1L E61WPZls9C4/8JXrWf7dTv8AwJem/VvrNXXeiYnVKoH2hgNjR+bYPZcz+zY1yz/8YHRf2z9Vc3Ha 3ddS37RR476vfA/4yv1K/wC2kp8N+q3Vj0b6w4PUZhlNrfV863fo7h/209y+lAQ4BzTIOoI4IXys vof/ABfdX/a/1Twb3GbaWfZrv61X6P8A6dfp2JKd3Lya8TEuyrdK8et1r/6rAXu/6lfMOdl2Zubf mWmbMix9rz5vJefyr3f/ABo9U/Z/1PymtMWZpbis+Dzut/8AAWWLwrpuFZn9QxsGoTZk2sqb8XuD P4pKa697/wAVvVx1L6o41bjNuATivHeGe6n/AMBexeY/4z+h19H+tDxQz08XKqZdS0CAIHo2NH/X Kt39tbH+Jbq/2frOV0l7oZm1epWCdPUq8P61T3/9tpKfZV5L/jt6sH5OB0dh0qa7JtHm79FT/wBF tq9aXzj9durftj60dQzQ7dV6prpPI9Or9DXH9bZvSUw+p3Rz1r6y4GARuqfaH3d/0df6W2f6zWbF 9CdY6pjdH6Xk9SydKcWsvLRoSR9Ctv8AKsf7GrzP/En0fdbndasbowDFoPmYtv8A+j6K1v8AHT1B 1H1fxcFhj7ZkS/zZU3ft/wC3H1JKfKev9e6h1/qVvUc95dZYfYz82tn5lVTfzWNV/wCqn1H6z9aL HHDDacWo7bcq2QwH9xm33W2fyVz698+qvW/ql0j6u4GA3qmIx1dLTaDawH1Hj1Li7X6XqOckp5qv /EbVtHq9Xdu77aBH/SuUv/GNxv8Ay3f/ANsD/wBLLuf+eH1V/wDLbE/7eZ/5JL/nh9Vf/LbE/wC3 mf8AkklPI9J/xO4/TOqYnUW9UfYcS5lwrNIG7Y4P2bvVdt3QvRllUfWr6t5FzKKOp4tl1rgyuttr S5zjo1rWg/nLVSU/MPWv+Wc//wAM3f8AVuVNXOtf8s5//hm7/q3Kmkp//9Dyt/03fEo2P0/PymF+ NjW3sBgurY54B8JYCgv+m74lezf4lP8AxO5n/hs/+e6klPkn7F6x/wBwMn/tl/8A5FL9i9Y/7gZP /bL/APyK+nkklPy1kYeXiloyaLKC7VosY5kgfu7w1bH1F/8AFh0j/wAMs/Kuv/x4f8odK/4m3/qm LkPqL/4sOkf+GWflSU/QvUP+T8n/AImz/qXL5dX1Jl1mzEurHL63N+8EL5bcC0lp0IMFJT7n/ie/ 8Rzf/DNv/fF264D/ABMZdVv1YvxQR6uPkuL29w2xrHMd/a2vXfpKUvn/APxo/wDi46j/ANZ/881L 6AXzv/jDy68z659UtqO5jbRVI8amMof/ANOtJTtf4mf/ABV2/wDhSz/q6l7cvFv8StDn/WTKu/Nq xHA/Fz6o/wCpXon+MH6xfsD6tZF9btuXkfq+L473j3WD/ia99iSnyP8AxkfWL9u/WW41O3YeF+r4 0cHaf0to/wCNt/8AA/TWz/ifwMEdTyOs511VQxG+ljC17Wk2WD9JY0PP5lXt/wCurz1LafApKfp1 /VujPaWPzcZzXAhwNrIIPI+kvnb60dKq6R13LwaLG247Hl2PYxwcDW/31e5n5zWu2PWXtPgUoPgk p9N/xMfWI1ZWR9X73ezIm/Fns9o/TsH9esb/APrS9cIBEHhfL/TOoZHTOoY/UMY7bsWxtjPPafon +S/6K+luldRx+q9Nxuo4xmnKrbYzykasP8pjvY5JT89/XTop6J9Zc7ADdtIsNmP/AMVZ+kq/zN3p rtP8SfWNmVndFsdpc0ZNIP7zP0d0f1mOr/7bVn/HZ0XdVg9brbqwnFyHDwM245P9r1lwH1O6uejf WXAz521stDLv+Ls/RW/9B6SntP8AHb1Tfm9P6Sw6UsdkWj+VYfTrn+xW/wDz1i/4pul/b/rdVe5s 14Fb8h08bv5qr/p27/7Cy/r71QdV+tnUclrg+ptvo1OHBZV+haW/1tm9ehf4k+mel0rO6m4e7JuF LD/IqG4x/wBcu/6CSmf+OnpPr9FxeqMbL8K307Hd/Tt0/wDPzK/89eWfVzqruj9dwepDjGua5/mw nZcP+2nPX0P9Y+lt6v0LO6aRJyKXNZ5PA3VH/t1rF80PY5jix42uaSHA8ghJT9IfWzrDOlfVjO6k xw3NpPoHxfZ+jo/6b2r5uXc/Wb62/tD6gdD6aLJyC5zcsTrGL+ho3/8AGtsZZ/YWB9TejnrX1lwM AjdU60Pu/wCLr/S2/wCc1mxJT7j9ROj/ALG+q2BiOEWvr9a/+vb+ld/mbvTXF/48Z9PpH7s3/fFK 9SAAEDhef/45+mvyPq9jZzBJwb/f5MtHpl3/AG62lJT4srjei9YcA5uDklpEgil5BB/sqmvpH6n9 Vo6t9Wun5dLg79Cyu0TJbZWBXax39pqSn57/AGJ1n/uBk/8AbNn/AJBL9idZ/wC4GT/2zZ/5BfTq SSn53+qnSOrVfWfpVlmFkMYzLpLnOqeAAHt9znFq+iEkklPzD1r/AJZz/wDwzd/1blTVzrX/ACzn /wDhm7/q3Kmkp//R8rf9N3xK9m/xKf8AidzP/DZ/891Lyp3/ADe3Gftkyf8ARL1v/E99i/YOX9j9 X0/tRn1tsz6dX0fT/NSU96kkkkp8h/x4f8odK/4m3/qmLkPqL/4sOkf+GWflXc/45f2b9v6b9t9e fSs2ejsiNzfpeouU+pf7E/519K9D7V6v2lmzf6e2Z/O2+5JT7+vn76//AFRzPq91m60Vl3Tcqx1m LeBLRuO80PP5tlX/AE2L6BVTqv7L/Z937X9H7Bt/T/aNvpx/K9T2pKfnb6t/Wfqv1azvtnTnj3jb dS8TXY392xoLf7L2r0Cj/HizYPtHSDv7mu7T7n1LmPrR/wCNt67/ANi/bd8mfSj0P7H2r9OuSs9P efS3bO26J/BJT6J1r/HP1XLx30dLxGYBeC03uf6tgB/0XtrYx/8AK968699j+77Hn4kk/wDVOcrW D+yd4/aH2jZ39DZP/gq9Y/xff+Np69f7Kn9q6bPt/wDPT/wH/afd/wAR+kSU3v8AFV9U8noXS7s7 PYas3qBafSd9JlTZ9Nr/AN2x7n73tXDf42vrF+1PrD+z6XTi9LBq04NzoOQ7+zDaf+tr23K9b7Nd 6H89sd6XH0oOz6Xt+kvm7I/Ynr2faPtvr73eru9Pdvn37v5W5JTsf4sugjrP1poNrd2Ngj7VcDqC WEeiz+1cWf2F719no/0bP80Lz7/E3+xfsHUfsHqfafVZ6/rbd2zafQ2+n+Zu9ZeipKR/Z6P9Gz/N CqdV6PhdU6bk9PuraK8mt1ZcAJBI9r2/ymO96vpJKflzOw78DNvwshu27GsdVYP5TTtK9T/xMfWL 1MfI+r97vdTORiz3Y4/p6x/Us/Sf9cXP/wCMz/m5/wA7sqfX9fbX9p9HZs9TaP3/AM70/T3qn9Rv sP8Azr6d+yvtf2r1R9L09vpwftHqR/g/Q9RJT7N9aujt639X83ppEvuqJp8rG/pKT/241q+bHNcx xY4FrmmHA6EEL6pXz39a/wDmz/zk6l6X2rb9psn0/T2bt36X093u2erv2pKeZX0f9Sul/sr6rdOw y3bYKRZaO++39PZ/0rF4Pg/82ftuP632v0vVZ6m70427hu3R+btX0k3btG36MaR4JKXXzz/jD6T+ yvrdn0taG1Xv+01Acbbf0hj+rZ6jF9DLyj/HJ+xP2n0/7X632r0Hz6Oz+b3fo9/qfy/VSU+WL1L/ ABJ9HmzP61Y3RoGLQSO5i2+P/AV59/2Pf93P/Al7f/iy/Zv/ADQxP2du9PdZ6vqRv9Te7f6mz2/R 2f8AW0lPVKt1Lp+N1PAv6flt34+Sw12DvDhy3+U36TVZSSU/OH1q+qnUvqz1B2NlsLsdxJxsoD2W N+P5tn+krQ/q/wDWvrn1ctc/peQa2Wa2UuG+txHd1bvzv5bPevoTrf7F/Ztv7c9H7BH6T7RGzy+l +f8AubPevFPrD/42Pru/ZX7QmTPo7fR/sfa/06SnRZ/jq+srWgPxcN5/e22D/wBHJ/8Ax6/rH/3D w/8ANs/9LLjj/wA3Z0+2R/1pL/se/wC7n/gSSnv+hf43evdS6zg9PuxMVtWVfXS9zRZuDXuDHFs2 u92q9aXz19Vf2H/zm6V6P2v1ftdOzd6e2d7Y3R+avoVJT8w9a/5Zz/8Awzd/1blTW51f9gftbN3/ AGvf9ot3R6cTvdMKp/2Pf93P/AklP//ZUEsDBBQABgAIAAAAIQCIjZmhWwQAACkKAAARAAAAd29y ZC9zZXR0aW5ncy54bWycVttu2zgQfV9g/8HQ8zqWbcVuhTiFr00KpxtUye4zJY0tbihSICkrztfv kBSrOHWKok+m5nLIuZ3x1afnkvUOIBUVfBYML8KgBzwTOeX7WfD4sOl/CHpKE54TJjjMgiOo4NP1 n39cNbECrdFM9RCCq1jMglryWGUFlET1S5pJocRO9zNRxmK3oxm0P0HrIWdBoXUVDwat04WogCPa TsiSaHUh5H7gPFciq0vgejAKw8lAAiMaH6wKWimPVv4uGl5VeJDDz4I4lMzbNcPwZ5ZtuI2Q+XeP X3mecaikyEApzGzJXLglodzDKPYrOC6fW5pKIo+vQK6xbC9ClL0mrkBmmFCs+TQMBkaRi69Cr6iq GDnekz0sRI1llxSUVaf4NuyTlbFKaimN9gYIyt5Vb4TQrRqjErtEEw14t6qAMdthGQOCsTXxXpKy JNgRTmIhlT4yuCccNrYfNpQhGtoeCCZhvAmH7bthR2qmH0iaaFF5fTTyYUnS4F2fJc3/AalpRlhS kQxF3nR4OWmRXPA3QtIXwTVhq853jUNy9B4e2tl72PesRw49K4gkGYbQXr/EK6RgHhPHpJJY+Pua Z7q2/e38ilwmBalg5eJU11ciVkaQt4LeIYZnrCTkVOO0VjQvyTMWNhxF9upBE/+I0cQ7rA7HAt1L U33/hc+h+Szot8l9I7aBI54XO1/geQfUfrzBOZV6mBNHkwCizVsU1scU/XHrWoswwjNIsGQMFkcN K1Gn7vQvzXVhjWz3boEcYEGyJ8WIKuaGsqyyZg+SUFt3J7DW6+cKiS0p6E5/A43kZW1J/l+t9JZy uAG6L/Qtx85iLY6CzXpLjqLWaIt56N6MDJpjaZrYHL5han1dw3A+ji7nS1dMo+004Tz8OPlwTjO+ nEbTti1PfcbLaLGanvOJoul4EZ3TTIbTdXTWZ7IaTYZtO5/eM51O1vOzb3s/nkU4/Thcn3vBajKe hyujwayZizBXZWyo17SQO21wIHqlG+8lKVNJSe/OkDN6lXEqnxaUe30KuCTgtSapU6/s951ClYSx DQ6dVyAvO02Ok4vzZIHZHZH7Dtkmo4zlWSmO3JfvaIY/QX5GJqwcaiNJdctzFPsLh1HU4lGOPVV6 uarTxHtx5OhXqprnfx+kARx0CWpijWsVZwJRSMdcwPuPiaFPIErPFSWz4KXoL78ab2xOJhOzjeGO VJXju3Q/nAXMtPXQuGn8Qop/sh/pftTqRlaHX0ZnP0hmgkXr9mAM3BGt2kMnG3vZuJNFXhZ1sksv u+xkEy+bGFlxxD2Fq+IJt54/GvlOMCYayG+8cBb8IHJJsJN+yzNW54AtkotM3XKziNxWs0T628za EjEuTGSEExo2JG14uDqR9nKisUaWlUUsYW96Rxt6OTEzzphu3DccGiTyoCcYcrLtpMGpH3bJySPs fL0JClc7ZBRnITmWabdwLlyCGFU6gQp3kxYSU2u361+2/7r/eNf/AwAA//8DAFBLAwQUAAYACAAA ACEA/1DQi9EMAACPTAAADwAAAHdvcmQvc3R5bGVzLnhtbOxcX2/cxhF/L9DvcLh3R/dPJ8mIHEiy HRuQFcWS28eCx9vTMeKRV5Jn2X7qQ5A/aIqgLWC0SB/sJC1coPVLCiR11PbLWLL9lK/Q2dnlco9D Lrmnc1Kg8YMl8jg/7s7Mb2Z2d05vvnVv4jfusij2wmCz2X6j1WywwA2HXnC02bxzeP3SerMRJ04w dPwwYJvN+yxuvnXlpz958+RynNz3WdwAgCC+HG02x0kyvbyyErtjNnHiN8IpC+CzURhNnAQuo6OV cDTyXHY1dGcTFiQrnVarvxIx30ng5fHYm8ZNiXZSB+0kjIbTKHRZHMNoJ77Amzhe0LwCwxuG7lU2 cmZ+EvPLaD+Sl/IKf1wPgyRunFx2YtfzNpuH3gRmtMdOGrfDiRM04RPmxMlW7DmbzbOnv37+r9/z e+OtIC5+2o0pyAp/k+8ERyB51/E3myy4dOdgHvvB+NLOHr818IaA7ESXDraaILiCA09/ahOYqumI p3KzBZ2Chg+EhUAXbLQbusdseJDAB5tNsDLevHNzP/LCyEvuZ/cO2MS74Q2HDPxBPReMvSH7+ZgF d2I2zO6/ex2tK2+44SxINpud/hoawI+H1+65bMqtC68LnAm8eY8L+Pz1v0xl23yioKGix8fM4a7Y aFtLdKwlutYSPS4Ra/rCYc5yyrIf++prwu2/Jty114QLsee16Hdjybiug06+ZNRDL/EZx6zFlIPZ ILETSKIwOKqNf20yHTuxByG65oBuHN7abexHTCSAhA255MzLAs7GhoH4+77jsnHoD1nUOGT3Ei5M mVYXbS9sHEwdFyJJfhD1ybnrHY2TxsEYA1Iept8yzEVI7noxzkJXQd8U+4TY25FHNNfvGN52iw29 2SQdqIicc+/s1hfGIDon3KsW5hMteO1qTUn6zn61JNdSwTvXakrSd67XlMSkMachk1dfdaLjRpEj rJn8Zyf0w2g081Ob5p1vzeRFSrjwtSZHUpJFLrhm8qI5qjS2XBdqkQLrmOaccaZc3jTtjDzl8qbJ 51lUjmJSRA6lU45Sm1flECaC3WZ3PV7iXyyMIrP3ncg5ipzpOO+G3R6/UytZvTsLE0xtOnM6mJZr yd8MoLyNWaMQp4tVay0caR+cl8E4tQNQuXFqR6JyiNohqRyiVmwqFbcKUuUoJtqqmIMmKYscaybm KgjMCaUQJtoWxi+aI+ziF5U3KYLGLypv0kIu8rRTc1AUkyJyKIoiFMU6flEIU/wqJCqFsCYqhbAm KoWwJiqFsCIqEV+IqBTF5J+KZTpRKYTJRRWETlQKYfLPQqLSksyOqFTepAhKVCpv0kKOYoqoFMWk iByKIipFsSYqhbAmKoWwJiqFsCYqhbAmKoWwIioRX4ioFMXkn4plOlEphMlFFYROVAph8s9ComK9 qFeANVfRaS6j8iZFUKJSeZMWchRTRKUoJkXkUBRRKYo1USmENVEphDVRKYQ1USmENVEphBVRifhC RKUoJv9ULNOJSiFMLqogdKJSCJN/FhIV96MvQFQqb1IEJSqVN2khRzFFVIpiUkQORRGVolgTlUJY E5VCWBOVQlgTlUJYE5VCWBGViC9EVIpi8k/FMp2oFMLkogpCJyqFMPlnIVHxgOcCRKXyJkVQolJ5 kxZyFFNEpSgmReRQFFEpijVRKYQ1USmENVEphDVRKYQ1USmEFVGJ+EJEpSgm/1Qs04lKIUwuqiB0 olIIk3/ygzmfNfTzM52hbftdzzKoTv3DLDmo22zEIuj3YGQvtz5UuhdbjoVr+lr7sdtheNxQ5566 mrq43qgH4g18L8Qt6vuV+91dPLumR/blLQmH7+w0boi2hGp0NC5FJ/vk0Oeht2zwfghsr4EHk/tT 6JuY6rvu0M7B+1qgXwdHwLs8bkJXhtPGvgveaAFy2Goi2y1wNlJ5+Dv0+wzTZ1qtrW5vdWtHnHhB Ywl/+4k3DE92oDsmCn31oHjCmSUhP01lV6+VfrKX/2T43ixObvMj1JtB9mYBGIujWRDxPd5j1IV1 oLy4PfPhBn8jfxS0JIcH3Tyoo8CZHobITTlhudUTP0gHAKTAGccPdnijD2pF3NN6a1DXFUrHZ7ia qZazLhV8VQDn1epV4u1Wuj9mbLoHGAJsNhFzDWaTm0pzXUxEMAO4K1WhlDjgR+6gtU4P1eiMEgbd WfwKAd9z07ENwmQs7oWzhKt+9+68rYm+o1y/1FbkiWaerEvq1be/ne+SEs/gqwf4f2abrgy9um3E vUVt0yEMSG0jX6XbBviCA1qCcTw/U51E/X7thS9dtr0yS3Vk7aRbStxb1FLdUkvJZDpwoNXsHd45 hpxNjbVcA3Kq7YLnx+gIiky6OVPHMdNPC4oIlV3vieu5AIi3srCnGCsCX8rYLAxuNnttrDo4S+dj 4snleoTGaZQ7CCEwDnGwIxRzzCJlCMXZ1DJFvlGXxe4Y8poLAYoH/LK0RkktGyEb6iy6wQOTYHNW NaQDTDOAatTDuc1nZbgFyinJA4kzEJ1YZSOkziwSb+MQJcX7VLNSOq60ASrrayoemDpUx4+TgS8i Pvwicil0y2KkF5XC8J4jFAGf7zDfv+VgqkzCKby35FGfjXjGgk/bLWy6y0FBpkjCSbl8hL1RpQCg WX0w4pJPolzlQMUBi2TDVpnaeySGQKMXL/bLPKGuxsvHNVeHuVDThJMDXn+RWqxFxvby8ZPzR6ev Pv/D+VdPxACLYlllZVYjZMnF3VwGqiwYMAxyB5B1god1GvcM9AqsZMfQxQw24SWaXP1lwYc3+QCP BZHmy7TSskE2UmslQpZy2nIWesoR98A6WP8twUqrJVY6f/jh+Z/+JqxUaREID9hiDj9Tag+Z68k+ 52kIPeGoUxiveBR+WVhBQbgfheEIQ0GmrKVVuSaX7hcp6+zLf1gpa9kOM1iiJsA6Is6btCCa2/VF FhL767PTT4W/5AsXWc9UulGmmbQwJ36SGbyaHRhza2eKbfgyBXwLhK+BRKbAoot/sUJoJH4ANQiu NvnKTzX8Q2NitjyD9ZvIIwvJqhyzkHSagRYS9uDrHEN2IyWv7ayF+M8WE+dBYeDr6v/fT9swZFeu OsdqSer6zMEyzuXtqtIrQCcjz4fvvKRLeKjmt3zvSFWTc1lDoIJGSuqw2smXBKrzT3939tm/L5x7 CxcIcje2brbF6v7/MtmuE7OATc4flUdOWbhXRs65DRN950rkBrIzsq5vjMAFPpaF3zmfxES9BJfc IJPnafPxF+ePPgS3LM4cdedfUIDwSMzDdUH1AfQiGulC1QdPy5Unv6rUiSzC4MfFNoWynNaVRyN6 xSfugf5tKj61Vec4ROujEFqPsUwFzKpd0ALFSudIVdtbbUtdwbNwE/MPJiOl/Y1WZ3nlX6at6gqg ptdm2hoQbfHds2Vqq70qq6FSba13W+gGMPhU+3HZLm9G2dKKqdQ5f/Clh0uUff73LyAmfHf60au/ PHz5+JPn3/zmxelfX/7ns+9OP14oPtS0v6nYHdJBfvXkxZfPoOpfaEhq4TPdHka1i0085pBlRQv/ 8ZfD9FKUizgC2fkCFlc7B7zcJiKZdMxKdKwvq/JrirqZIVVQ3eK6UtNiV2DkRXHCaxhxWJPLFfZk zGxw/uev4fjgF29vd7ptPDesNgXkM+1sZ+lbBCNinhenD88++OPZt89ePn16MRYQbfZUqlhkgwA8 l38BXdtO8dA0SJ00OXH+XL8uCVThwxCB5fJPnTGO6MbWIX+qwU/hirVRdwGsV25qtAIy207/4c4c YZn243K6zi7Aj8vpwm10XtFoa3txad4FnzseMeWQET2UFgur59/8qpiU8hinvATG0ECre/JXMOQN DDQD8b88NSJhJ11WZEVs3fK+viLoYZFUxLNPihUBqsNRl2kC7FRnOyKrokf0NGjb8f0Q/goGfpNd 6Kj4dBPO947T0LcDZ2PmoalqKlvQAUB29M8v5k8LYTLziSUzxUXWE3XNg1PiZZ++fXr+8T/hROT8 8Qei4Glk885XPdJndSU5oG2j+WSdBkYsW0UsRwVze1PKGfgfQSD1A/3LCHVdgktm6qEnnen5Fjnb zK91uzu97aty40o6hJ59cTzp8gt+pi45t6uwAUfS6YOFD7TXxTEwruQKn+is9eQpT9lLuv1+z/yW 3mq6g1OGsdrbqBhpvwfFpnEua91OxUjXO72KkYLC6F7BnErh8G2tYqjt1sZGxVjb7Q04xTVOp92B 4VY80l1LW4bKFNvu9VdxuDyXyUMwrVLDEWTXNRohbKNXfnVflpzA+XhhrKeqLBzgMLMgkOpFX1SI ezDLinq5bhxUPM7HQgwNrz5//+VT2Bg9hSMlu2jIxYVVy2PDfJ7TA4Flxi9SatZ2J72rjhbTDBtf +S8AAAD//wMAUEsDBBQABgAIAAAAIQB+JZw04QAAAFUBAAAYACgAY3VzdG9tWG1sL2l0ZW1Qcm9w czEueG1sIKIkACigIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJyQwWrDMAyG74O+ g9HdtbcGtylxSpos0OvYoFfXcRJDbAfbGRtj7z6HnbrjTuKTkL4fFacPM6F35YN2lsPjlgJSVrpO 24HD22uLD4BCFLYTk7OKg3VwKjcPRReOnYgiROfVJSqDUkOnemk4fOW0qs4s2+PqOWM4o+yMc1Y3 +FA3bZ3tWL5v2TegpLbpTOAwxjgfCQlyVEaErZuVTcPeeSNiQj8Q1/daqsbJxSgbyROljMgl6c3V TFCueX63X1Qf7nGNtnj9X8tN3ybtBi/m8RNIWZA/qpXvXlH+AAAA//8DAFBLAwQUAAYACAAAACEA 5snCcmgKAABkgQAAEgAAAHdvcmQvbnVtYmVyaW5nLnhtbOxdzW7ruBXeF+g7BAa86OLa+pcdTO7A iW1giotOMXP7AIot3wi1JENSkrmz7qbLouiimFV3fYd2+jQzQGfVV+ghKUpkIh1LMpM4sTY31+KP yI+H5MdzDo+++PK7cHt25ydpEEcXA32kDc78aBWvg+jTxeAPH5fvJoOzNPOitbeNI/9i8NlPB1++ //Wvvrg/j27Daz+BjGdQR5Se30HyTZbtzsfjdHXjh146ind+BImbOAm9DH4mn8ahl/zxdvduFYc7 Lwuug22QfR4bmuYM8mrii8FtEp3nVbwLg1USp/EmI0XO480mWPn5H14iafJeVnIer25DP8roG8eJ v4U2xFF6E+xSXlvYtTbo4g2v5A7rxF245fnud03etk68e8A53LJm38fJepfEKz9N4emcJRY16hr2 7hxAUkVRokkT5HfyloReEBXVEPF4MP7F4I1g8Mbs3WNSVdkRwOI9CJN3nWaJt8p+dxueSb++Wl8M NJolSoM1pN15W3gyM+eua5iDMSkc3m6z4IN/528/ft75PA99uiVPWa4s3G152qU5164s12Ep2zuS EMAf/i4Q+STjmXWWC+R9GRYP1/4qCL28aij50f+uSBvmJeDxb1e8lq2/yVhFu98npNUZ9Dn/y/PA Kwbw/12cXgws0yDZx2XGICL9J/WwVPhx40Wf6FQtc+e1J+wlyTKOspTkDCIo5ntpNksDL6+ZZoI3 QENJS+AP5GQ46BTzQ3EYDWknaNXdobDZQNVAQVJFKMrciqAwVEExGuYCe5BguIaGCAZJFdEocytC w1SBhjViU+EgIGzHRYCYmrJYOBMOmyIgLBVA2P/7959fPxR2Qyi28b2ffPCzzE+KTksLp/Mm4HDa wPFNHHpRNRpUvA9dO59ikqz9jQd7bj77kF3EbYgEvpvCLgJL52hojYb2aOiMhu5oOCkg676v6JbF 1wS+GYt7LE0W11Ihv6I1ZPJ0+IyGUxUQ2RMrH+ZKiEiyBFGZvzNEsM8LdJAQE+EnvEz4RdghYyoS O7x0rmxtSce2CzvUrelsPrNL6gIvbccOb3c7dKH75e9/+vnHvynhiboxoayihh3RZHGE3jRT1C0D 4wQ0WQTjrXNF3XbpWaROOEiyiMcbZou6pdM9ow4Kd+JKULxpvvjiYBwbY3xxQI6JMz4RGG+ENRrG FFtTabK4pp4gazQs00ZYI02WIHp+1siUOiJrNDTLNhfdWeNSNxzNMa4K1g09PFrWWLLAKlpPUsXx KXN3JvW9dpGocisUrb12UVQ799rFfM3otYvF8nlsXPGF9c7HxBSfBIo3whMF3le1x/baRVDdlbyv EqIj0C6yDUnkiaZ2NTH02YzxvPa2Z1szZmC87m3PCbVuV1Ci3vZc7H09O+zZYcUM6dlhMUN6dij5 7fTskGtdetszKBwQ23xve2budRJEAJlgXt5re2brsMQOiS+rzfwKutier5aG5i6uDrA9474UhXay u9tEqQ2sIu0KdIf359ewvDNHT9be4MHv9Hv+ALy8qA9o+v0VcXOkhdgzXPpPimO2AjR3m5AA5W4y 0lyRVbqnxlTbYGpQH5r7cxFT9gwX0hPShraCk9rfHsDJbXKIiJ4Ua34OQE+Oez8HqKfE4J8Dz/4c 0AZl5iQlr62F4xSytvanCUpDmxPX5kC3PJOwRVk6k0yMS3eqL7pqrDVLm2qaPi/ODkC023k2PP2Z xMAcTixIhTaXt6WK3NSfAQCu0LEd0wlB1y2sf9Op7K9RmuWQ/h0ZYdenJqdwVcdK6pMmjmGjPioh 0Hpx/6CYAN0Pz4ar0xMryFxlN6cPHOpdjXutIkOphNiW3YRrFgp6atoaNqCGbcu+xxObnzKRnjZl nPiCUwwou1CioLOWMcGG1QTXMGkF0nWT36tAetuUCrbqLVyfUdBhW0M9y80JOOKL01U3ikucSIeP m6vZExsbZMucPrgMU7qcI30+eubkOBZVR9YsWbauybuP7mqVM7klj2HCL/IYy1gubFebMfFtb3nX 9eXicjHPNYaiYZHdMG952zm93WxAxKnKMYozuGH9qZhY0q1G/eysSEB2DvHuGV0tNkGSZh8CcrFe AjRX68MffrvbS1dBcDGYJQFcSYc28XveF4Nf/vWXn378K52KM8BSyMNuhAvONm2OCc+qdm0ONCzs z471jVJc6UDLxy+TDz5y/OpE5lrhCjcwXze0z6qEbQstXG595ehSricLrsH5HyK4SqirrSKcgEDJ Kpk5YWwiozF1vivSzX3/oqx0oWDYtsdbCYF2ftNkP+Mowt9imxQCnJwG3k0p/N7QCG4v4yTyT5M1 pesp4htfYoD5Vrz7Nvu8LaIKeUzyxfU93Xkrv5gQIvP7+Yf/VAYqWEEIKh4CI188XhP5a666lE3E XU86jcaFEyeBlNcPzH//8c/K8AgnMzAtz2JsRolnMduwdNue52E42p/FZjNnBtftyjAesEW00ylH EJCuctax4AqzsyIROXPt2aOI4hgJwoWrlR8zgpcIwjWDM5ECJIiKuR6JPQrow5HodL6BE764Gg9z DacCNPbdkCaKH5ErPlBWH47H8Sm2daK5rpcQmixC8kCxfTgkSk4SqpXgVMtdj8o+JfjhqCjh+xIq EIFJwQyiGvF6YPYqzA9HpikzfwHlOtWeI+DsU64fDk5XCl213qoP3EU17fX47FXEH45PVyrbAB81 gbuoVr4eor1K+y4QtSSVDEORVDqmbYGxIQ9c1p5ULheWY5uzku+0JpXSZJdPfrmC6xGpULAYPrlH NYwMooPr5Okgg1NC/kjCFeBThunifF08Lh9nAFgZnzLw6yN8+qiwuQ0N4juqkJWnCHjJ7Wmkffhc UsJC+6iw0izpo8KKwcWVeG88xSQRTMn4HDluctnHbShd0+pMN8cft2FKI+uK5BI+F2C5C2fG9pj2 5HI+teGTAcy1RdZrN/UeecaosK+RUT5i1mo0l6+RPFZB0fPEnic+UGj3PLHnif3XAwaS0qZm6VSv hOx54lvgifrjj0u5C21hXmqLrkRx4RiL5WRZqsRaayF703bxLS1sbvembZAs6n4+1AkWahhib9tm Hv2iq2Jv2+b3HARUett2jXqkt20j3zXsbdsQYArBp7dt76WVx2Hbho91wvYL/5YfoRJCh31FvtVJ NxJqzQaFOOQkwy4VY25trYsx76/WxZhtqrIYv9dY1UjmQlRfjCpDv4aPCCfBmvhJP3LjFNIoIvxa CBzVeBJBRvhZ1CKYpnlWjmuLWgTvwQNqEXzuDqhFMBAeUIvg1nVALYIL1AG1COacA2oRPGoa1VIz o1iXKoUVm4isD62LsUa3LsaME62L5WfVynLcO7dqAutsFrUvhyxP6PuQ9Yn7iFa2E1mguB92ZTlk heJ3JyvLIcLCv6lXWQ6RFv75ucpyiLig5RB5wcrBp4DJulo57iBLzJehqqFwyaZjQURi8DciIoMX RGQGxQaRGbQcIjN4QxGhwQsiUoMXRMSGb55Vow/3jWtHH4MG4rd0K9dVaExEaHjUlMoOIjKDlkNk RirH9qZrP4GQAO//DwAA//8DAFBLAwQUAAYACAAAACEAdD85esIAAAAoAQAAHgAIAWN1c3RvbVht bC9fcmVscy9pdGVtMS54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AITPwYoCMQwG4LvgO5Tcnc54EJHpeFkWvIm44LV0MjPFaVOaKPr2Fk8rLOwxCfn+pN0/wqzumNlT NNBUNSiMjnofRwM/5+/VFhSLjb2dKaKBJzLsu+WiPeFspSzx5BOrokQ2MImkndbsJgyWK0oYy2Sg HKyUMo86WXe1I+p1XW90/m1A92GqQ28gH/oG1PmZSvL/Ng2Dd/hF7hYwyh8R2t1YKFzCfMyUuMg2 jygGvGB4t5qq3Au6a/XHf90LAAD//wMAUEsDBBQABgAIAAAAIQCpyFyqjAAAANoAAAATACgAY3Vz dG9tWG1sL2l0ZW0xLnhtbCCiJAAooCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACy SbIKzi8tSk4tVghOzUlNLklNCS6pzEm1VYpxDHDUiwj2UVIAC/gl5gIFgWJKChW5OXnFVkm2Shkl JQVW+vrFyRmpuYnFevkFqXlAubT8otzEEiC3KF0/Py0tMznVJT+5NDc1r0TfyMDATD8pMyknMz+9 KLEgoxJqGFWMsrPRh3vGjpcLAAAA//8DAFBLAwQUAAYACAAAACEASS7+CpoBAADsAgAAEAAIAWRv Y1Byb3BzL2FwcC54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACckkFP3DAQ he+V+A9RziXObils0awRWlRxoAVpA5wte5JYdWzL9lL233dM2GwQt+bkeTN5fv5suHodTPGCIWpn 1+WiqssCrXRK225dPjY/T1dlEZOwShhncV3uMZZX/OQLPATnMSSNsSALG9dln5K/ZCzKHgcRK2pb 6rQuDCJRGTrm2lZLvHFyN6BNbFnX5wxfE1qF6tRPhuXoePmS/tdUOZnzxadm7ykwhwYHb0RC/jvH MZVyaQA2qdC4JEyjB+QXZ6RPFTyIDiNfARsX8OyCivzHkqbGJWx6EYRMhJB/X14sgM0EuPbeaCkS 0eW/tAwuujYV928cimwAbD4CxGaLchd02vMa2LyEO20pytk3YOOKsgXRBeH7yBfLnHAqYSuFwQ0h 4K0wEYEdBdi4wQu757c78Rd10aDsrTOuy1e5cdXXu6QqOsX7VN72T3z0jbvJ/N7tPoozBs869Vsv JCU9X6wo65HGrAVbgoaKjncwPApwS3cWTN6V/rUdqsPM50bm+zQ+XkJQ1fS9AT1oBGV6VfwfAAAA //8DAFBLAwQUAAYACAAAACEAat14NH8BAADVAgAAEQAIAWRvY1Byb3BzL2NvcmUueG1sIKIEASig AAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAfJJNb8IwDIbvk/YfqtxLUmBoqqBoH+IE0qQx 7eOWOQYy2iRKAoV/v7SFjk7TpB5q+/VT+3XH00ORR3u0Tmo1IUmPkQgVaCHVekJelrP4lkTOcyV4 rhVOyBEdmWbXV2MwKWiLT1YbtF6iiwJJuRTMhGy8NymlDjZYcNcLChWKK20L7kNo19Rw2PI10j5j I1qg54J7TitgbFoiOSEFtEizs3kNEEAxxwKVdzTpJfRH69EW7s+GunKhLKQ/mrDTadxLtoCm2KoP TrbCsix75aAeI8yf0LfF/LleNZaq8gqQZGMBqdt9fiH4bEwvg/AOFrnXNnvnah2eun7OVcZu8Vhq K1zo7EShVaADK40P52q4nURQ59z5RbjfSqK4P2ZzDTy/A9A75Wvar3r1OYt7Wd0/G9WKNgw71JY1 86KIgglpY9m58jp4eFzOSNZnCYvZKO4nSzZMByxl7KNaq9NfmdIkitOA/xOHcYD2h8uEpTe3XeIZ 0DjU/RGzbwAAAP//AwBQSwMEFAAGAAgAAAAhANc9zKIMAwAAgAwAABIAAAB3b3JkL2ZvbnRUYWJs ZS54bWzEVkFv0zAUviPxHyLfWZw0a9Nq2dSmy+DADmw7Iy91F0txXMXput2474AQR85cuXJA/BtA QvAjeLaTqlsa2gxtJIrUvtgvz5+/7/PbO7jiqXVJc8lEFiBnByOLZrGYsOwiQGen0TMfWbIg2YSk IqMBuqYSHew/fbK3GExFVkgL5mdykAcoKYrZwLZlnFBO5I6Y0QzeTUXOSQF/8wtbTKcspmMRzznN CtvFuGvnNCUFfFsmbCZRmW2xTbaFyCezXMRUSiiWpyYfJyxD+2V11mKQEQ5VnzJOpXVMF9YrwYkZ MCOZkNSBMZckDRB24e7iDt7FHjwu/PKQrTLFCcklLZYDsQlPCWfpdRXNdV49fsaKOKnilyRn5Dyl Zo5kF/BiLs9xgA4xxu4wipCJOAEKIdLzPaeMuFCUufplpLOMwDZBYTqPHuKYPBCBPOUsXadt9qmG yBDKSjVQdRxGgIOn8VCYuK1wkAsmpVnsv+LQeQwcfn559+3rew0ESYtjYEu1cyeMP6esXEqNKw5g 1IfHqW4z8A5X/K4J3+YKFxOaZ2tAmrIrOjHxVab4akPd0QpTOn4Y9cJoeBchp7uBKR5k0vzaninf P900I3Qyr9axFiEMKroPQmReiDX4NIuppHxFGRCB6/uRij4GRD8+fgaIXh+N3I7jai49CA/KRVb+ oJTuY2Uj9UVWkSbHUDyoPGRLxwjFPGc0Vy7a4Bs92O2+dgzln14r32iriUb3rCjwoO45FsWcrzON X29vfn94U1K3JgllrOraIAnHzL9tGu2NdaQ+BSdMqQDY5m5/3APbGN3VRGcTXcCB+jrP9rbx8sQ6 e2EdiSJhcQNfDBw94MouELnpnPHXnrft4dBCcVfP2+4w7EXjOhygYXMmN6kHOpe2cGjGhAn9CxT9 ezKjrXT+Ly9Cws+h92jAQbVepgVTrVgTJcC6dKd1WyHtW7ChVsjhikK0L2KvppClxTZRAkTdlhIh SRlA0YBEpJtQ3X61RuIe4nCUV6yKQyExDJeRVna6EYmyK5X7fwAAAP//AwBQSwMEFAAGAAgAAAAh ADoYbEluAQAA3QUAABQAAAB3b3JkL3dlYlNldHRpbmdzLnhtbOxUTU/CQBC9m/gfmr1LF5FSGwoJ IXjBjyh6X9ot3WR3p9ldWuHXO7SooB7swXjh1Pl60zfz2hmOX5X0Sm6sAB2TbocSj+sEUqFXMXle zC5C4lnHdMokaB6TDbdkPDo/G1ZRxZdP3DmstB520TYyMcmdKyLft0nOFbMdKLjGXAZGMYeuWfmQ ZSLhU0jWimvnX1Ia+IZL5pCBzUVhyb5b9ZtuFZi0MJBwa5GIkk0/xYQmI+SYitLun14ViRRHpF06 6PWv6vQS0s1UlJgqmcQc8XfFipk5z9x7lH5EH8Uq/yG8gOJ77QScA/UljnQmqdm9w31iNC6WYKHd xgTXj0bBElx1bScgAdfK1g4aGvKAWTvk8ohRO6w5nLwN1K81qIduzGM1Qtof0H6vG57kaPMR/JUc 3TAMgkGPXgcnPf5Lj+Y3qa8WFE4oseUzMBMDleWmvk94LTf3+uV2XntMSqge7m7QQejBUR69AQAA //8DAFBLAwQUAAYACAAAACEA1DKhry8DAABYBQAAEwAIAWRvY1Byb3BzL2N1c3RvbS54bWwgogQB KKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0lFuPolgQgN9N/A+Gp90Qh/ut0/ZEQBRE BQEVXjpHPCAKB+QmONn/vnZmZzedzL7sZnKeKlX5TtVXSb1+7bJ01MKySnI0wagvJDaCKMxPCYon mOdqYxEbVTVAJ5DmCE6wHlbY17fh4NUq8wKWdQKr0ROBqgl2ruvihSCq8AwzUH15ptEzE+VlBupn WMZEHkVJCNU8bDKIaoImSZ4Im6rOs3HxNw77zntp6/+KPOXhR3fVzu2LZ7tvr3/B+1GU1clpgn1T OUVVOZIb0zNJGVMkJY8lRhLGpEiStEwrmjSd/YGNio9iGhshkD1Hf8+q90JX3wWaY1jmiW3rl7S4 V3X59hvz+7W+k313s1WHxoF6jfmpGUtM3bvzc6MXMTwseMpzQs7xndIPrt3DPF0yD0Qbo4M0PNQb uqDXM7IdDpB+IKtjwTM+rlkCJfaHi0DI/N22YsfNjZUZhH4JMs5KTRv3DsFidVzWjfhYPOASRyuT imgbyXA7HMz93GXxQ1boYRTuHVYSuRZcOapOdivZ2SjHtu0jKEey4tz0xznY79COKD3OSRnXOogM cJnjoQii4eB61jdsHXHEbNoFhg76tUJpr8Q/Bl6JH5L/p27m57qpT75j9jnt0Y/Sy+y8shIkVKTc +Uph2eo8lI+FNyW4IvLZR5KIwtl5xGI8HMwUR7O3C3AzjtW05XuBwYvgACpbJZqbFi+94z0obtk+ 5joglo0tndh2XWuL653207tC+DZjClpzHQ6gYPK1c0G7nbffL0WFE9xEziXOWEznjJzeStFpkSo1 Upryz4UYKDnxeqyDTRKBDT9dlGR0zB4XcThI16QbSn6aCCI+M9gQ6tN+Ks6Dx4aJV8qJ5z0frdDK 0ra/RDb7c9n0J9m+rYEZ3bFNELfJ9uIt1TvebLt92uSP1h4OqPZSBjjYlWlzoaQkxJM1T9I2RxgQ yqkAFbc6FSg91Ov4bNhWYu1lk0JCaN885+ab2kXvISCO7nAga+nOMKSsM5wH7pp75gSIC7vdi6K1 Q+ukC3uWX1ECsZzfJ7/EB/fDRxWlIP5kgWI/Hi+K0r/9THwcne8n8e1PAAAA//8DAFBLAQItABQA BgAIAAAAIQCMimiR9gEAAOIKAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1s UEsBAi0AFAAGAAgAAAAhAJlVfgUEAQAA4QIAAAsAAAAAAAAAAAAAAAAALwQAAF9yZWxzLy5yZWxz UEsBAi0AFAAGAAgAAAAhAG8BpR95AQAAUggAABwAAAAAAAAAAAAAAAAAZAcAAHdvcmQvX3JlbHMv ZG9jdW1lbnQueG1sLnJlbHNQSwECLQAUAAYACAAAACEAk7XHqEccAAC7jgIAEQAAAAAAAAAAAAAA AAAfCgAAd29yZC9kb2N1bWVudC54bWxQSwECLQAUAAYACAAAACEACnvB4VQBAAD/AgAAEAAAAAAA AAAAAAAAAACVJgAAd29yZC9mb290ZXIzLnhtbFBLAQItABQABgAIAAAAIQCSCNtKcQMAAPIJAAAQ AAAAAAAAAAAAAAAAABcoAAB3b3JkL2Zvb3RlcjIueG1sUEsBAi0AFAAGAAgAAAAhAMv1oMgbBQAA pBEAABAAAAAAAAAAAAAAAAAAtisAAHdvcmQvaGVhZGVyMi54bWxQSwECLQAUAAYACAAAACEAeBoM ylQBAAD/AgAAEAAAAAAAAAAAAAAAAAD/MAAAd29yZC9oZWFkZXIxLnhtbFBLAQItABQABgAIAAAA IQBvpOQXagEAALMDAAARAAAAAAAAAAAAAAAAAIEyAAB3b3JkL2VuZG5vdGVzLnhtbFBLAQItABQA BgAIAAAAIQDQarQAaQEAALkDAAASAAAAAAAAAAAAAAAAABo0AAB3b3JkL2Zvb3Rub3Rlcy54bWxQ SwECLQAUAAYACAAAACEAWGCzG7oAAAAiAQAAGwAAAAAAAAAAAAAAAACzNQAAd29yZC9fcmVscy9o ZWFkZXIyLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAHgaDMpUAQAA/wIAABAAAAAAAAAAAAAAAAAA pjYAAHdvcmQvaGVhZGVyMy54bWxQSwECLQAUAAYACAAAACEACnvB4VQBAAD/AgAAEAAAAAAAAAAA AAAAAAAoOAAAd29yZC9mb290ZXIxLnhtbFBLAQItABQABgAIAAAAIQDHHG0UnAYAAFEbAAAVAAAA AAAAAAAAAAAAAKo5AAB3b3JkL3RoZW1lL3RoZW1lMS54bWxQSwECLQAKAAAAAAAAACEAxxn+6ieN AAAnjQAAFgAAAAAAAAAAAAAAAAB5QAAAd29yZC9tZWRpYS9pbWFnZTEuanBlZ1BLAQItABQABgAI AAAAIQCIjZmhWwQAACkKAAARAAAAAAAAAAAAAAAAANTNAAB3b3JkL3NldHRpbmdzLnhtbFBLAQIt ABQABgAIAAAAIQD/UNCL0QwAAI9MAAAPAAAAAAAAAAAAAAAAAF7SAAB3b3JkL3N0eWxlcy54bWxQ SwECLQAUAAYACAAAACEAfiWcNOEAAABVAQAAGAAAAAAAAAAAAAAAAABc3wAAY3VzdG9tWG1sL2l0 ZW1Qcm9wczEueG1sUEsBAi0AFAAGAAgAAAAhAObJwnJoCgAAZIEAABIAAAAAAAAAAAAAAAAAm+AA AHdvcmQvbnVtYmVyaW5nLnhtbFBLAQItABQABgAIAAAAIQB0Pzl6wgAAACgBAAAeAAAAAAAAAAAA AAAAADPrAABjdXN0b21YbWwvX3JlbHMvaXRlbTEueG1sLnJlbHNQSwECLQAUAAYACAAAACEAqchc qowAAADaAAAAEwAAAAAAAAAAAAAAAAA57QAAY3VzdG9tWG1sL2l0ZW0xLnhtbFBLAQItABQABgAI AAAAIQBJLv4KmgEAAOwCAAAQAAAAAAAAAAAAAAAAAB7uAABkb2NQcm9wcy9hcHAueG1sUEsBAi0A FAAGAAgAAAAhAGrdeDR/AQAA1QIAABEAAAAAAAAAAAAAAAAA7vAAAGRvY1Byb3BzL2NvcmUueG1s UEsBAi0AFAAGAAgAAAAhANc9zKIMAwAAgAwAABIAAAAAAAAAAAAAAAAApPMAAHdvcmQvZm9udFRh YmxlLnhtbFBLAQItABQABgAIAAAAIQA6GGxJbgEAAN0FAAAUAAAAAAAAAAAAAAAAAOD2AAB3b3Jk L3dlYlNldHRpbmdzLnhtbFBLAQItABQABgAIAAAAIQDUMqGvLwMAAFgFAAATAAAAAAAAAAAAAAAA AID4AABkb2NQcm9wcy9jdXN0b20ueG1sUEsFBgAAAAAaABoAlQYAAOj8AAAAAA== --_005_D496C972D1A13540A730720631EC73413A41B50Cnkgeml507mbschi_ Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="packet-fields model update.docx" Content-Description: packet-fields model update.docx Content-Disposition: attachment; filename="packet-fields model update.docx"; size=65421; creation-date="Fri, 24 Oct 2014 10:34:38 GMT"; modification-date="Fri, 24 Oct 2014 11:00:49 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQCMimiR9gEAAOIKAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADE Vstu2zAQvBfoPwi8FhadFCiKwnIOfRzbAHWBXmlyZTMRHyDXSfz3XUmRGtiO5JoQehEgCDs7nJld cXHzZKrsAULUzhbsKp+zDKx0SttNwX6tvs0+siyisEpUzkLB9hDZzfLtm8Vq7yFmVG1jwbaI/hPn UW7BiJg7D5a+lC4YgfQaNtwLeS82wK/n8w9cOotgcYY1BlsufhCBoBVktyLgd2GoD390QfHSObQO IeYEx7LPbV3dumDC+0pLgUScP1h10HTmylJLUE7uDLXKazgfnIQY6WimynvodzU0P01C7iI689tU XCOY2+B8vEqm0oPWeBBQQ+w4fIFS7CrMvj6RPq0ldx42ByfXplay+UC8T9QEqOJBzYhaz/bkVNko GrfaD7EatmNA0cbW3pVhmAtc7ZGN0LZT9dV42Z1ZQ6A8JHt6FK8eepRExH01RcBb3NH2YNVEE9Yh D1Egv5qp4pTPZBOgnhoFakaDfjBYr0YgAiIFYIIF0yEPHb9fchCuk49/lMF6xUE4s//7/9G/t7/d ickUWph/8b/VKH2pXyo+0h8TePNMJ9HAjPq9BaEmyVsLfGb/CfJ2Zv+SbhErsa4gOW4nTH+GHhXh EdY/J1s9L8BHibSipWfvSItxN/5OvwsXmNHdWSRVnxh53txQl38AAAD//wMAUEsDBBQABgAIAAAA IQCZVX4FBAEAAOECAAALAAgCX3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArJLPSsNAEMbvgu+wzL2ZtIqINOlF hN5E4gMMu9MkmP3D7lTbt3ctiAZq0oPHnfnmm9987HpzsIN655h67ypYFiUodtqb3rUVvDZPi3tQ ScgZGrzjCo6cYFNfX61feCDJQ6nrQ1LZxaUKOpHwgJh0x5ZS4QO73Nn5aEnyM7YYSL9Ry7gqyzuM vz2gHnmqrakgbs0NqOYY8uZ5b7/b9Zofvd5bdnJmBfJB2Bk2ixAzW5Q+X6Maii1LBcbr51xOSCEU GRvwPNHqcqK/r0XLQoaEUPvI0zxfiimg5eVA8xGNFT/pfPhoMEd0ynaK5vY/afQ+ibcz8Zw030g4 +pj1JwAAAP//AwBQSwMEFAAGAAgAAAAhAG8BpR95AQAAUggAABwACAF3b3JkL19yZWxzL2RvY3Vt ZW50LnhtbC5yZWxzIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArFbLTsMwELwj 8Q+R78R1C+Whpr0gpF6hSFzdZPMQiR3ZW6B/z9KqadpG5rKXSDtRdiazs05mi5+mjr7A+cqaRKh4 JCIwqc0qUyTiffVy8yAij9pkurYGErEFLxbz66vZK9Qa6SFfVq2PqIvxiSgR2ycpfVpCo31sWzB0 J7eu0UilK2Sr009dgByPRlPp+j3E/KRntMwS4ZYZ8a+2LTH/39vmeZXCs003DRgcoJAl6AwcddSu AKSeu1rFJFLIYX414RSQW4t9Aft6EhLAyu9xW9MEOwP2dYj+nvP1wWSGDOgJOCAhCWrMqWE4A8ER sPKbTbMGR/t1nEIHBV3gNCHdeLTNB8W+i0Icyw6VFUITXIspp5q/LTjLRQcFLVHcKi53cxwScMfJ /w3rN0CkZPT2oweGhChWJUjHNxyTsSvl7hrMhKKPB99ZPXxUBgXccvL7i1kckNAgHjklDB9VwUQq Vg9ya3Cl13UvDB10cEGe/AnMfwEAAP//AwBQSwMEFAAGAAgAAAAhAFORhn0ZGgAAQssCABEAAAB3 b3JkL2RvY3VtZW50LnhtbOxdXXOjSJZ934j5DwTPo7Ls8tpeT4uJ6q6q2X7YCYe7NvaxIy1SMlEI GEB2Ozrmv+9NRMpgGWWKEpCJjqKjVZYxykzux7nfP/39j1XoPPE0C+Jo5p5/mLoOj+axH0TLmfu/ 375Oblwny1nkszCO+Mx94Zn7d+8v//HT860fz9crHuUO3SLKbp/ot495ntyenWXzR75i2Yc44RH9 chGnK5bTj+nybMXS7+tkMo9XCcuDhyAM8pezi+n0yi1vE8/cdRrdlreYrIJ5GmfxIhd/chsvFsGc l2/yL1Kd79385edyycU3nqU8pDXEUfYYJJm826rt3WiLj/ImT/s28bQK5XXPic63+Sl7puexCjfL fo5TP0njOc8y+vTz5pfbO55P9313eYDiFtu/0FlC/TvlSlYsiLa3EdTx5vlvH94Henhnm+8+E7d6 3QidhUe09BD7L+I9cZ5viRb9+5k7nV5fX335RPRXfnRHD5oI5fPF1TlRafnhZ75g6zDfvfyu8lFx 57tUvKXl29c4yjO6CcvmQTBzf4nXacBT55/8Wdz68VOU7X46z+oXnnk/nZV3pPdkc2d6MvHiS5rS XfKXhM5kmbLVbzlLc5eup8vlymvb6XBptA5vFfvrkIvV5ps1Fyfy3kq/RP5w6xQi4DZL2JyOLUl5 xtMn7noOffCd55NFwEM/c/6sbUMcfLEZeayVxy4/qp20/NA4whmCMBoO3HGc2iHTGb9HK0NT9QuL lpNSd+ms10TaPv9bbeVjIeex7GMYeW03W0ZsxQshXqPsBhliIk+6qoVnCQ/DoaWfQMkBzxe3CSOE kd0K3UkwXAhF+khoTK1tDPoAvFKpu5CCZqNagJM69CcUuccaEDCb8Osi+EPFgsI4GJQDG1RNDXKD OcGcz8IqJFRX2s+F0+cdU80SyyFYJXGq1I+mMqdKqBgBTwQ00VrooOLPm2itcWisF0R2oDnh8YKH 5mheRcIRDfqZ5Kx4qYjXBN+j3UDIDlvQEvkwUjPPNCfRv2tiYSyuuLHswzRqqRFLg5ducPwDvF6E STuKXgp/hS14vQj6AGceNXoNnFlNLeg2Ft8A6F1B18BHx8rH2EvRwEfwZ47Ln5nyp0Bk8OlguUH9 bQ3S72J6fjk5n9J/SO/pRQTa4jzyeTZPg0RkadpK2+6vUZAHbJtl68SLMqPNKTPa1hn3nYcXh81F TuckDLI8AxTohQ8ABQAFxgUFlmm8Tigv3FZxqVq3EcFNNg+11jko1vImecqiTES6J4+c+TxFCvWR 0/73mpnAWL2dtvtNUrqzofQSWo0URSEU0rpQZxQcO6fiJSq94qlKCZmawZRRudWcTwrVRJy75DD7 ezF3hEoqXjqEM3TQbwy2fxDNw3UWPHFnQ+Zk+29o3xG0Dyu/v1Qpa8g+5EyZOGmqXA/jZ7IyBGlD oPcr0AV52yDUV6KVQB6nLzqLHdR8bghV5Omaj7MgwrTEpEJiy//pkMvQgEVkpeis00SyVq3bCLeb SHO9FdpFa7WDHrM3idarB55CVBypw4bScC8kxTjjOYNI5pBl+T2PyG3M/Tu25D+nnH0vWpgoihKK B6HiUBMqE2xG2uskAdLuzb8sUYh8t4G6gUa6TeT0gEZ2enQN1XTLrPYEUko4QCN9gb9xnjTifIjz WR3noxBOHkRFk00E+0Tzx0EQqw1odaTBvgoDIOJ33Jareg4hG2jfZj8EIn5DSXVhZdhA3Yj4Gdyt 2lDD2Rbaho8NPjbZEQ8Rv0GMm3F6fgaJ+CGuV5sU0K1oa0gvQlwPeLp5zAjZvB4wR7eMibje7ggV xPW2MT3xD2AOxPWoA/xj+ylRZtnd46RnRE+7iZ7a4HREFwQxJK9joGRJFwQVvZqR2p5oLXPgnHa0 kdgMkezb06WiDROyqccQwf/vok2K7MtFQ0tXceTksRMkT5cOVa6Jf1yhqYThI1jNAte2xLKoC12m I2cGVUENXlPVuo1Q8ZbApYamUeMsZION2I2NaIvQszn1ygqh52dzCyybBrXyZ+2IISu6kxW2yAsE 3zr2KRVFdXYIDW+ckMjE1BMEKNCmWb9Nsy3KBOCza2ViAfT0Jkka5/E8DtEyrdeWaTVsb+jcO5vh 5jqI8htAJGTK/EimjK029/MtCfRYBCKeWDhzv36d0sul7km0oaJgQGzsbhNMpIvSLPDvu04+Vq5J WVFpqsjU2ZlnLtrSWX6Dh2qRsuWKR2Npt6o8CSvZxtgyTeVxm51vrrP8Br7h1J2Rp0VjipHAbuVh 2Mk6St55G9olaypefEmF6hXoeeYOlRujfCCCuQQdqrRqscNt1P3d/W1/21vqg87uGnhPa79D9PLV 2ZMnNe7v2foh4//S2oxVj2ccQS/ls7RUHJrb80F54kLeGZ8kqLOLBrnmaskCCLZ5EMzcX2gCUMDT gyPKOs/HG0mGpnKvlsqwcUTzxvp0DpVi7wJSY6XcKQJuCVlh6W4S1zuIOiqFAYGfBtggotXlS8V6 Rpuyo4Z2koWALIxmISCLIk/IUAGnEm9w5aVsZZWv6NAnapR70ovi6Hcp2LV2YtWzgR/PZFkIP57o MnRlIpqw3I83EqkGJ56RzCFN1ZH0wFLa7Za6WLXgTMVJByee6Sl4hz5R86A2AubvZnrKDz/zBVuH +VDNF8cqCQG0AbS7iTILoG29TAPMBsyeXl9fffl0U7QLlEUJZW3CkRqdjVW5HArKALMBs7tMfJLe 7N8plPL7IkizXItC4dcW4q8E4v30Oh+rRATcBtzuBm6PSrYBdgN2A3a/WxmtzJRDko+pge1xPBkK +QxVoi+/ei8PjPOURaBN5K0l0h++6wivd0iQ1w3sN5ePTKy/54YO8qv3UovKABwqp7iyeM/2aR3U 2XkiWsRPMB8B8xG2ZW2Vbi/EoeaXPlY4sqFUwV0EPPQzJ4icX+9oIsKG3EeSEy+3T++FIBfvUEjC K3bwnLO9CklkENmglMztFyQptfmYqRYnD6KivclGMTHfT3mWjaQCTB6AZFUTW9baQuY2txgsmkUX wCtJ+SL4A90GDeo2WDr4pJlW624nP6zYbvXLiyBMxUVYmlZZwuZBtKQ/D+nZz9yLy6lQUOKH+3VI H7B1Hos2e6UJT29Hi2BnEUu+xf9IA7+4v4n9/fYtcTq9edOCsFl9lEm+pmrp59t9G93ttSjQt7na vMVuGuB5k9afrFj2XUf113lQ6W6pXw6WbdPN5FBKDlmW3/PI5yn379iS/5xy9r0QSFbXlx96DLln Lm45HkO3wDd1njwOCxfe8OOp0gHR+/EeTaki4YvHYAoMprjtrdhEyo5m7JpRft2cw+sxjCMeXo/u Z1i0QAVlgrc0u1W2eP3yfhIiJWeb7NPT0PZd4C94PWRG4Tyrd44sDJ99tgO8HgsdL84QCeD7Htu7 PpwGr8c7Ch8ODzt9lIc89tIAMxlwtLA24dYQ4mo37t6FWoVbQwALCppQ8Czj6RN3PclUGkCnjhGV jqb65cNAyncpq74wK/ZhWrgb1AInmL4TTAePVjrTDOFaGktC6hUSUo9bxy6dFM3ux1KD2kDkxjds Vp92PSH1Cgmp8Oy9jhUh55CagiziV3NTWNTH/CY15WqChNQjJaapz14adfRug1oyN7FDfdQyNHNF Q92RkJpRvGlUCamlr6CoCimBZTf4kiituQalC18YQkwIMQmyPjgoc4qJtVv0gjgT4kxGTBo+nG3N RVkthFBDZHgdRPmNxhgMKNSeGxcc7xFXbBuDzZsW+/VSFi25jr1mc+6Ge+58+OCcX9zo1JB3waaI ASMGPJWNuJAeSV0pdzPs1G6PUgrrSKuhI3s2O1FfM922FohOVR8yHLaFeT9C3YLIbaBwc5G9WpDA f9oRIFEGrDVyeH4cf8F/isYEwstY652AFP0TStHfAhe4TuE6hev0yNq+hZ8JrtOAb8wDZS3ZbnWK DNP2mJB9vEdcGu2G2+4t9gvXaZGgIL1ZlXkU8iNVlmAd6Tc09jmy7JLG4Rh4SsOYstApI57MDmVZ uI8epbUkaqX5bYNjyWbX6SKMnyche+AhPKa95eTBY9r9Ub96TF9JHG1QDco6tVBBQtHLZNDjdj4H LESdLOpkTWoWp4LdNEY1DIdOWaDpMlrr7D8RrGLeeBOeP55EuTG0Yzfa0RZrYVxl01qSZWgJSKKF pxE3dZh1RQw2hFMwKCl9xw1dmf5Qt5KGaQ8Ev2CrSU8GV4CpGbNal26FKFyxudY6BwaDKO9Hef9r XL3ChwY3OKysskGNa3He0GDphQqHbu0SE3BYw2FNuQkHe1uJY5vbJNQh5b0q56F+ORCoTA9SyTwT 5kfbHJkGAj3ajL6KAvdkgyntPOM6/0Nc0BiVSmZk5WgbsJGUF/Rug8iwuUpKdb5GRC0AQ923hcUA FVJIIBKOSLh+JFxQjUrmAYb+WJFzWVuuOmYjVItdzg0knHafBSn1iiWCAuBT1BF0VEBCufYewCfA JxobvbU/4NRo6dRQoSKAT4DPSjF7AZLNCMDD/RnlfbYht8VUBQIFAt00fc23oRJE4RGFtyIKn7OH TLAvvdN6n1g4c0O+yF36IYmpf+Xk+mLqFu08mq5Q/Fr59+eXl4pbXJxfqa64uVFc8fFqqrji8uNm pxSek4eCSQ6yPOGdZo/7u4lMi5egHO1wp6mWwf6N7nayEU4Tc7MoWuymIUqtel6D+bdbbNF7Cln0 q6+1pf6tkRYbanhmGh38u0jekAK1SYdAy0RL0rghdSCYuRekD8sf7tchfcDWebzRwUd28x5KVyTK ixzBHqs7Dl0iCd8G0q/ENYyNgLbYrcFJ4C120/DsxPSR86uhon+QXtIaAEZ+FqJZO7n6eBxQlV7m ZnC02O8pdRi8nP7XpTuQawhCDELsNQ25WyEWsiy/55HPU+7fsSX/OeXs+8aJ1KDgq+JtoIRGMAgY pC8GUdgo4IBGfzR8wW9GPuz6H6WVLt576TELyQnJaYjkVDlwh8ouamMYnUIM4WZ6cZ7Ar9Mcf4W+ 09Z38EpfnU/dDnJx2ggvc5OiWuymwWgtZmJDeEF4VYq7D6UuCdatF15wStMjzAK/XhhghjRukF+b ieHX8EhDgkGCOc5AXrcj53SQQinuOAbFgifSRxb14adsWLPZdx2d9blrda1M7rpCVVf2Ub+8YUwb HJ0jc3QmaRwvvrwtN6t0ndy5wCYHorDBfa6ciFwvsXt3xzanvC5CtswmPnvRsdTrYgBS47UQ5AIl FnYnv44pNHIK3sWHgKptNfL1IbIIlhEu2a1dg8iyPl9/TEKLGFpnOzZjrd/WEUQWvIkn7k3U4fKK jZlKd0StrboZkQOPisCDPIgjnT3ZLLmmGmn5QFpAWgXKbM65tDeMq+EFBv2D/kdL/zoKzhalfQKW xv/EsDT2tO1B2uhJpI2OSWidiqVxDksD1V2v8xxPL2EUlgbo/5Tpf0xK+wQsjW9rjpgGYhqIaVBb SyG60qKm/G3inE15cadiaVzA0gDSOmWkBUsD9H/K9A9Lw6p6zP/jPiwNWBqwNGBpWFZJ/hGWBpDW KSMtWBqg/1Omf1gaVlka3x7XsDRgacDSgKVhmaVxCUsDSOuUkRYsDdD/KdM/LA2rLI2vaQBLA5YG LA1YGpZZGv8JSwNI65SRFiwN0P8p0z8sDassjd9YDksDlgYsDVgallkaV7A0gLROGWnB0gD9ny79 D0T9mDuTJWzOZ26S8oynT9z1tGYA/XgXvOvrqy+fbopJjcldUU7b8bN4d0BKuYp3m4/KDysDUuqX FwNSet9Hj90VRaHz5tnsmdVuqoegsnhvmcbrJIiWOmvtv4FrZaUNQ+pU6y6mlwzRmK+ydC8PVjxl 0ZJrrdbEY/6ztnLaWz+j4zsWfKYJDIdetYOmczalk0KVnn2ezdMgMbfxc2WxDXLDJd0VRNwRrOkU vOnwKE8Dnjl57JDKp3/P6w35QfXOP/mzS8r/8VOUBTP3l3hNB5bKT+dZ/aOzTT8QpZoUVC9eNlB+ /qiU4aLViYkinM3nPMs+ON8ea1QfZE7gE+kHi4Dqix9eHOZEbFXfJShf0ngLyg9Zlt/zyOcp9+/Y kv+ccvadeIN88Q2yacMO1vAEi3wd1jWRJ4idIxL2C3o20VyS/2IdzYVq+6uTxU7+SHGj/DHOwBF9 DBuVpK9DUCagep11mkj4EuAQmWcOS7kTrKjtFXEA9c0mpnAkDzg0ZYyHiw+uRgyi7gK4r40rMdRj AMX2A4pNob50WGNoFp7HUc7IDEh1FmsiH7OHLA7XuVYLSgv500QDXagoHXIZmrbbGemQiN1JRAlu 3E+SawvvA+Fnx2fEwwJr1igLD6P7h1E7cEP9bTZ7HbIsngdE3f4rpsxyluZZ7eBB6aB0coh4y9ji WFQQkeuYLxZ8nsNgehMHR6h4NP6+kLNFTXg3aE0T7aVC9ejkgcNYOlpcxxaDKX9J6k5ei+haxY9G pEG8UArErbB0tFY7qPjwJmSVTYR5Nk7Hp6mOFVtkBZwrREFZDwVgZBiqE+2kY0W8u4XfbZPXIT0r I41emMrEGhnLgFdHg1cqZTrU6J0K53o2mwyc3LNIf+wz+G8LCIDBILKYOsrRFd5AGAz5zJ1O68oS tRVVuGeLrGhnMBiF8F7DlkIl1kKXANi3fSpIAOw+TxsAO9hN9m+RCN2UL8Yo2/YJGUzPvYoQW/Qm MHbHGPshjsk6j1RCrgggDOuShye+T61ni4Dw+YKtw3renEWBOzdP1xzwGbpPlFbWKya9djYjUum6 T6UTwtH9LeHzYPFS1Muw3TTHmkbFQ+nnodQOvUENDJ2Yv7F3dFY6KN5qKE6NUyeISpONsqkobf2Z iihruwGxg9jLqn+vSLir53o3sKWJxF6kIxO9b/N6gdR6RWpwdPZl8v3bOTtztuWQjqwrHEau5/T1 RYME9kCFw08snLkhX+Si9QhVKc/cyfXFVIBlihE2XKH4tfLvzy8vFbe4OL9SXXFzo7ji49VUccXl x81OSaXKQxFt6ahIgs4ipMrVmXtBKy1/uF+H9AFb5/HmdI4cmn2+zSKWfIv/kQZ+cfrzOCQ4UD6h r1+n9KraMAIHlA3s6KJe0sX2L1EssL7E/Un5NervMRa3fxe7B71vF2/2YEw/qRZ79LbySWdT/eOJ FltqANkJT4N4sLQjKWmahCvEL8QvCfR3+n0djwOEh6V86TD7EDZ9i82a7tID5xNdFxATwOuwTn8t mKFB90m2L9/du40urOQbCZfrUJ0SwCHgkFrXS+1EmMM55Ic6Bwr2GZPmNLYHxuHPtTERajeI5Lzj P+3NvQ5ZB1nXl6xr4ok3aGBMEs3gXifHk2mV2MlgPVEgx0Ylx6D/KqEQhCHIEWVZGOIwB/5WA45J 95lbEHw81VdA96FKh6HzRqXzLA0+bmWX+MeY5Je5ZSnHlF8p5RkMVHUB+QX5Bd/Dbt3lcYKuiEOq EsiQAHYESjMuAayl5SXQS6Wv2FBJwNCJ0IkG6cSBkrPBBeACg7hgTFbtKXjl+HDt/CC5ILkMklzw yRE5GlCVcohRIsZSwye3p/AL8dCTiYeOTX61a/dhZWTIpeKs1w6SKgg92PCKFrEUz2cvps63aLMd +Lqai4yha05G18DX1VhqDy44GS5QKeqhRk20UWyn4OsiLJIhAQ0KPOCbaTNF0w7Le3gc4i0RFmLl NSbxdQoJaIuQLbMJCTHkoAF9QYQJSTYmEWZ05+YWkLKhn8GgHZ4RckTIESFHpNGijyL6KJIk7LBZ iWYBvwAxZnZOh6qEqjRMVY4N8Zvc+f54gN+kDvkQahBqEGpdwh6jJxwcT6gZMwkBEg0SzSCJNlBi yJE7+1OhZnHHMRRsvplksWmlXvOb99ZAajxPSRLIvkkDjjj5ZRqvEzGeonbi74z8GSyps7IVTzQV Tlm0PChjcyzkM5Z99JgBXaGdhmiPwTG6yuI9yaYqLhUZXf0P0qistOGYVzxnPsvZUNlNJybZTXZE VYilZVsTowSI+zXgoZ85lYmiz0H+6DCH5j5957nzsM6dKM5pKl0xefSRM5+nQ6Xpd8wH9GwTMeYr IZunqNSbudPp9fXVl083YubVbvGe/PDzZir07uV3lY+KO5cDqsq3r3GUZ3STI41dE+vveQJWhR0a ZKdgZnrpiP4hxqpUNuCZm6RbWWXDMQdRss4n1P+Ypws259BUx2KqvTbIhrYtIW/jK/7UVO7ebbTS M8uclM958MR9JxaqKcjE4NQN8Y9UPRkFHLaUbwnxqzKY/18AAAAA///sVu1umzAUfRXkFygkKQnZ QIrabNqPTah5AoovxBJg69o066S9+65tUlGxdvmxKNMUpBD7+vj6+OCPoyBlNRbttuPsJvt4WGNA Py34Q44pC8P4fhZHIXMtObq/T7IzmlCFLoVI2Z3sUQAG3+DAKLrfdHoaLfVrIA11Q+P4jCb43jZr rYqSyCgEDfgELAu0QdHVHyzSeLx7K8tCHWlakstlvN2s7OhT5sfgPVRF35gpPB+FXOZhmueZLc1F DZmPzC4vdOCfn1elz72kB6VfCU0rAqWstmi3nnk+7sidKdBcbk9mvQZ9Cs9/8eT4E2+toGkuLbAR LWDR1XAS24vKnF0P4bPfdnQ0XA/gv6dy9n+Kaf2DdSkaSpO/eLWRhfmtqxiCO+pkoZv54nZz50zd HgoO+AAVIHQlvNxA8AQdC3AteMrwC1/5i+gtNPfmatQh8R0qKc0J6clhOvP5FnyaP4reZ1QJ1GbE J5q9P8IEP/d4Ve9+kCiHlEVREsbO4VI5Xs0HSVT9tXAXt1QUn9M4VmxR70npaBWGtvoojZEt1RcL V2+gGrV6UVO2XCYW7DVIWZK4VHVvSEH6ap5PKRvrvQezvJjd+jCX5WcUnFq8gWhEB9pms4VcmHKf MsvN+26/eJyZfpT82RUoQ99CZ7JfAAAA//8DAFBLAwQUAAYACAAAACEACnvB4VQBAAD/AgAAEAAA AHdvcmQvZm9vdGVyMy54bWycUstOwzAQvCPxD5HvrV0KFYqaVhUVJw6IxwcYx24s/JLtJPTvWecF 5VBVXLzyjmdm17vr7ZdWWcN9kNYUaDEnKOOG2VKaQ4He3x5n9ygLkZqSKmt4gY48oO3m+mrd5iL6 DNgm5A0AVYwuxziwimsa5tZxA6CwXtMIV3/AmvrP2s2Y1Y5G+SGVjEd8Q8gKDTK2QLU3+SAx05J5 G6yIiZJbISTjQxgZ/hLfnrm3rNbcxM4Re66gBmtCJV0Y1fR/1aDFahRpzjXRaDW+a90lbqWnLYxC q77s1vrSect4CJDd9+CkuCDnvIcPTBIT45ISTj3HSjSVZpJJi/Fn/tPw5jA83HvjJPXTCPzFBtbI ZW0O61e+FIiQ3fL2bveAxtSeC1qr+AvpGM++C6/xqDg8bagqEKUIp6w0JaSE9CE+yVTYckUSgsEp 8VLsTljfzTcAAAD//wMAUEsDBBQABgAIAAAAIQBpx4YiYQMAAPIJAAAQAAAAd29yZC9mb290ZXIy LnhtbLxWTW/TQBC9I/EfLB84IFLbaZIW06QYmlZIDVT9EBcurr1ultpes7uJCbcKgeBAOXGDQ0FC AoEqDkgIDv0zbSr+BbO7tlsXKAkV5BB71zPvzbyZWXtm9n4Uan1EGSZxU7cmTF1DsUd8HG809bXV +cq0rjHuxr4bkhg19QFi+mzr/LmZ1A441cA7ZnYfHnQ5T2zDYF4XRS6bIAmK4WFAaORyWNINI3Lp Zi+peCRKXI7XcYj5wKiaZkPPYEhT79HYziAqEfYoYSTgwsUmQYA9lF1yDzoKr/KcI14vQjGXjAZF IcRAYtbFCcvRor9FgxS7OUj/tCT6UZjbpckobD51UyhFFKqwU0L9hBIPMQa7c+phgWiZp3FnAgqI wmOUEMqceSSRi+MCRjTGifoXxZuA4hmK2xBQR4mAFi1oI74eZpclmt3c1lI7bep104R2BItBAgSJ x3UjM7gGQNCzckUSMOm7YVMXmoRIeLAHTb0mbxLXA18J45GQQMO4PU4EkCGpjyOth4uEbOZoptU2 j+yK2BYo9gXvBlyvkxCsIdJJEakMrrRdvVy1frXdMOW2iiAHhGlKbZhDfxniNZ3JWt25rgTyZJ5e FoKXqWNNNX5WR0BmhkKWk3D51hwK3F7IBdHUnHnNmZZEiWJIVvggRGAqRXVdlQGOfdgKMGV8EYuC TwK9kjHzC0J/BUeJdMUx46C1tnqj09buXNUu3OsRfmUAv0qn4quVJklLWVtWo16fVPsqmJgsUUIC RUQzCVpV06pVLLNSrckyymJS+V8EIVeJKnMm4G9ktGSnlJpsfBlNx7zc+KOMgJuJBdFCeVQ+dJ7E nIG6XRxDTZDLuMOw1B0ciqQPnm3vf/m6v/fqYPfx/t7OcGu3lDxYjo956ewQw5fvD789H24/Gb56 ePh2a/jx9fDpu+GLNyVkkfgItahXp8TU/pdapPbvWjq173p5+1O80ZXnzplKd/jhQ0kOGKSfh2XJ WWir1gfyYnJHHYnpEgFEWzDIrhi/Nb7vfC5BZv3FxcvaZupcTShiiPaR3rqk/cp4zAZ/9OkESJED KJIfKTfXOkKpFU27c1FzqLuOPXnbaS8vtOdvLXec1TOcLP9cxtIkwIKrcyt7C454aB97O5xyaOct W1DCF1vrBwAAAP//AwBQSwMEFAAGAAgAAAAhAMv1oMgbBQAApBEAABAAAAB3b3JkL2hlYWRlcjIu eG1s7FjNbhs3EL4X6Dss9m5Lsi1HXkQOZDt2AtitYTvN0aC4XC1hLrkgqR/nARr0UKCnXHIqesix PffQt0n9Gp0huSvJcmXFyq09WDtLcma++ef6+YtJIaIR04Yr2Y1bm804YpKqlMtBN35zdbzRiSNj iUyJUJJ141tm4hf7337zfJzkqY6AW5pkBBu5tWXSaBias4KYTVUyCZuZ0gWx8KoHjYLom2G5QVVR Esv7XHB729hqNnfjIEZ146GWSRCxUXCqlVGZRZZEZRmnLDwqDr2KXs95pOiwYNI6jQ3NBGBQ0uS8 NJW04qnSwMS8EjJaZsSoENW5cbmKtlSTMYSiEB72WOm01IoyY2D1yG/WElvNZbqDA1FEzbEKhHmd FZKCcFmLwcS4F/86eJsQvIbX3UBRU0PAF/uQRrYvwuNcB+JtNE7G3bjdbEI6wonbEhSU1MaNcOAA BEHO4ltfWasKODUiohujWwRDJvOuG+84oiQU2J0kqoSCnCFDq1BWw2mfEQZYDpkQZ8QhESyzAcmz KY50QjwOzQf5v+972TPSQPapUjcVUrCtOcVQm36ieYpmDeB5qIRX39nZ8irnVtudvZ0Hllu7Hbfs AVTyrAZRUOXpBbii2dveafcOvfu1102JtJcl1KT3sX7Fgnn5xVCA/9iEQAAq9M86DhHqCPyWutjQ YAmdxnDquhBC5ArnygdQVUtHLCNDYRFvs9fc2+04vKVXUF7aW8EqOKQTQuI39bGS1sAmMZTzbnyk 7LBAGIwY2zOczCzlPWnqIz4nnEUAMqhyuRCsXEfyOJHqXCuVOQ8bScorheGZUTpOQsGDL8uES8El i1Ju7JVLYKQOauq0pjCm6JwyYRMLPS6iE0j+1l4L64fe1jQqhjNZxqh96U9CzbT2mm04h46OI6gO +O3jrz+dKghVxFM4F0eSFJAKnz/+dffT+wjeU2YocLx6e33+/eX1xcnB9Q9MW06JCNz0u9GJJmXO 6bEGXgwPgdyerpwqemNC/4ew3OsiD0yRex3R9yGpDnMiB6xnSjANoTqnlsky/etqnTHliFgSDTXk 0RcbUHJqh5pB+IBK4C/AAmptaXJ0zl2hoWhwRQgkBNgHEnZR9+ORrPi9NIIwfeAWHR/VS1qrcc5I aqp4zEtp4Oscwr7g5TEXMA5IgnSkE1b0GaSefp26kJLEaHoBIYbwAm01szRHMgO2sN6Y2XA6pmJR o4GqjvrjM5VCJrtBgPyTTBf4hEEVQe2Ah6BqXAkQrKklBQXqKuZSG3vCYBghAaABJ4SVJGR0ahAx HK2O4LJUaKyzRMgI5t1ee6vtGGZ2Cm6ZjgSHu0kHR0bAhH59KbF1kMQSLjwNCoQEPZWdgYRXpzzU HSbr7DvQdbNBetqDgIaCxU6IvX3FXj0zW6oG+vW7sscEv9XYQYDVULHV8NmGG8TC9IGbQk/wAXjc Xxn8BcI3jFrEirY+Opf6rg9CJ09BXcYhL06hpXfj7V3fX5OvMFcwSuhh9EnwNHpjXckAOOcS8rga msFFQa7d//vDe9RpnWbQ75LlS/SeXUZvXkcnysJ4wDCFUbywvBzFr7+th6K+HMzdBB61/vMvP6+n d8FMfxFZWF5q/d2nP+ZQYA64eCytC7gX/F8XT70jPpoZ//G6+P3HuYxcsSs8qfbv/vw0p2su+7E1 +a4YvjBX7OmL8+vet0bo6cv662HuvkGrzhk+N8LqbJ/BJbwZhLaJBlSt3K3C/1j2/wEAAP//AwBQ SwMEFAAGAAgAAAAhAHgaDMpUAQAA/wIAABAAAAB3b3JkL2hlYWRlcjEueG1snFLJbsMgEL1X6j9Y 3BNI00aVFSeKGvXUQ9XlAwjgGJVNgO3m7zt463KIol4YMY/33gwz6+2nVlkjfJDWFGgxJygThlku zbFA72+Ps3uUhUgNp8oaUaCTCGi7ub5at3nFfQZsE/IGgCpGl2McWCU0DXPrhAGwtF7TCFd/xJr6 j9rNmNWORnmQSsYTviFkhQYZW6Dam3yQmGnJvA22jImS27KUTAxhZPhLfHvm3rJaCxM7R+yFghqs CZV0YVTT/1WDFqtRpDnXRKPV+K51l7hxT1sYhVZ92a313HnLRAiQ3ffgpLgg57yHD0wSE+OSEn57 jpVoKs0kkxbjz/yn4c1heLj3xknquxH4iw2skcvaHNaPvxSIkN3y9m73gMbUXpS0VvEH0jGefRde 40kJeNpQVSB6QDhlpeGQKqUP8UmmwpYrkhAMTomXYnfC+m6+AAAA//8DAFBLAwQUAAYACAAAACEA l+MWnGsBAACzAwAAEQAAAHdvcmQvZW5kbm90ZXMueG1spJPbbsMgDIbvJ+0dIu5TaFVtU9SkF+v2 ADs8ACOkQQsYAUnWt59z7FZVVbXdkGDjz7+x2Wy/dBU10nkFJiXLBSORNAJyZfYpeX97jh9I5AM3 Oa/AyJQcpCfb7PZm0ybS5AaC9BEijE8a9JYh2IRSL0qpuV+AlQadBTjNA27dnmruPmsbC9CWB/Wh KhUOdMXYHRkxkJLamWRExFoJBx6K0IUkUBRKyPEzRbhr8g6ROxC1lib0GamTFWoA40tl/UTTf6Vh ieUEaS4V0ehqOtfaa7LljrfYD10NsltwuXUgpPdo3Q3Ombhkl3KPF9gh5ohrJPzOOSnRXJkZ003H Sf/n5i2weXTITTvUsRC8i+w4S1GbhINFkJeWOx7AETSpPCXxsj9ncYuzmr+khLHV+v7pcd2d6E07 WfC6Cj88Hdl1y4yj2Yb2Nlxt/z9O8TkRAkxQpu5n5PVUEPuPnrPkC9pQ7fTasm8AAAD//wMAUEsD BBQABgAIAAAAIQAh688JagEAALkDAAASAAAAd29yZC9mb290bm90ZXMueG1spJJLTsMwEIb3SNwh 8j51WlWAoiZdUDgAjwMYx2ksbI9lOwm9PZMnpaqqCjZOPI9v/vHMZvulVdQI5yWYjCwXCYmE4VBI s8/I+9tz/EAiH5gpmAIjMnIQnmzz25tNm5YAwUAQPkKG8WmD7ioEm1LqeSU08wuwwqCzBKdZwKvb U83cZ21jDtqyID+kkuFAV0lyR0YMZKR2Jh0RsZbcgYcydCkplKXkYvxMGe6aukPmDnithQl9ReqE Qg1gfCWtn2j6rzRssZogzaUmGq2muNZeU61wrMWBaDXIbsEV1gEX3qN1Nzhn4jK5VHt8wA4xZ1wj 4XfNSYlm0syYbj1O5j8Pb4HDo0Nt2qF+GsG3yI+WKWrTcLBI8sIyxwI4giZZZCRe9oEWr7itxUtG kmS1vn96XHcRvWknSlarcOTp0K47ZhzNN7S34Wn7/2mPz8rgYII0db8mr6eSkv8oOku+pA4FT1J9 /g0AAP//AwBQSwMEFAAGAAgAAAAhAFhgsxu6AAAAIgEAABsAAAB3b3JkL19yZWxzL2hlYWRlcjIu eG1sLnJlbHOEj8sKwjAQRfeC/xBmb9O6EJGmbkRwK/UDhmSaRpsHSRT79wbcKAgu517uOUy7f9qJ PSgm452ApqqBkZNeGacFXPrjagssZXQKJ+9IwEwJ9t1y0Z5pwlxGaTQhsUJxScCYc9hxnuRIFlPl A7nSDD5azOWMmgeUN9TE13W94fGTAd0Xk52UgHhSDbB+DsX8n+2HwUg6eHm35PIPBTe2uAsQo6Ys wJIy+A6b6hpIA+9a/vVZ9wIAAP//AwBQSwMEFAAGAAgAAAAhAHgaDMpUAQAA/wIAABAAAAB3b3Jk L2hlYWRlcjMueG1snFLJbsMgEL1X6j9Y3BNI00aVFSeKGvXUQ9XlAwjgGJVNgO3m7zt463KIol4Y MY/33gwz6+2nVlkjfJDWFGgxJygThlkuzbFA72+Ps3uUhUgNp8oaUaCTCGi7ub5at3nFfQZsE/IG gCpGl2McWCU0DXPrhAGwtF7TCFd/xJr6j9rNmNWORnmQSsYTviFkhQYZW6Dam3yQmGnJvA22jImS 27KUTAxhZPhLfHvm3rJaCxM7R+yFghqsCZV0YVTT/1WDFqtRpDnXRKPV+K51l7hxT1sYhVZ92a31 3HnLRAiQ3ffgpLgg57yHD0wSE+OSEn57jpVoKs0kkxbjz/yn4c1heLj3xknquxH4iw2skcvaHNaP vxSIkN3y9m73gMbUXpS0VvEH0jGefRde40kJeNpQVSB6QDhlpeGQKqUP8UmmwpYrkhAMTomXYnfC +m6+AAAA//8DAFBLAwQUAAYACAAAACEACnvB4VQBAAD/AgAAEAAAAHdvcmQvZm9vdGVyMS54bWyc UstOwzAQvCPxD5HvrV0KFYqaVhUVJw6IxwcYx24s/JLtJPTvWecF5VBVXLzyjmdm17vr7ZdWWcN9 kNYUaDEnKOOG2VKaQ4He3x5n9ygLkZqSKmt4gY48oO3m+mrd5iL6DNgm5A0AVYwuxziwimsa5tZx A6CwXtMIV3/AmvrP2s2Y1Y5G+SGVjEd8Q8gKDTK2QLU3+SAx05J5G6yIiZJbISTjQxgZ/hLfnrm3 rNbcxM4Re66gBmtCJV0Y1fR/1aDFahRpzjXRaDW+a90lbqWnLYxCq77s1vrSect4CJDd9+CkuCDn vIcPTBIT45ISTj3HSjSVZpJJi/Fn/tPw5jA83HvjJPXTCPzFBtbIZW0O61e+FIiQ3fL2bveAxtSe C1qr+AvpGM++C6/xqDg8bagqEKUIp6w0JaSE9CE+yVTYckUSgsEp8VLsTljfzTcAAAD//wMAUEsD BBQABgAIAAAAIQDHHG0UnAYAAFEbAAAVAAAAd29yZC90aGVtZS90aGVtZTEueG1s7FlNbxtFGL4j 8R9Ge29jJ3YaR3Wq2LEbaNNGsVvU43g93p16dmc1M07qG2qPSEiIgnqgEuLCAQGVWgkkyq9JKSpF 6l/gnZnd9U68JkkbQQX1IfHOPu/3x7wzvnjpTsTQPhGS8rjpVc9XPERinw9pHDS9G/3uuTUPSYXj IWY8Jk1vSqR3aeP99y7idRWSiCCgj+U6bnqhUsn60pL0YRnL8zwhMbwbcRFhBY8iWBoKfAB8I7a0 XKmsLkWYxh6KcQRsr49G1Cfo2c+/vPjmgbeRce8wEBErqRd8JnqaN3FIDHY4rmqEnMo2E2gfs6YH gob8oE/uKA8xLBW8aHoV8/GWNi4u4fWUiKkFtAW6rvmkdCnBcLxsZIpgkAutdmuNC1s5fwNgah7X 6XTanWrOzwCw74OlVpciz1p3rdrKeBZA9us873alXqm5+AL/lTmdG61Wq95IdbFMDch+rc3h1yqr tc1lB29AFl+fw9dam+32qoM3IItfncN3LzRWay7egEJG4/EcWge0202555ARZ9ul8DWAr1VS+AwF 2ZBnlxYx4rFalGsRvs1FFwAayLCiMVLThIywD2ncxtFAUKwF4HWCC2/ski/nlrQsJH1BE9X0Pkww lMSM36un3796+hgd3n1yePenw3v3Du/+aBk5VNs4DopUL7/97M+HH6M/Hn/98v4X5XhZxP/2wyfP fv28HAjlM1Pn+ZePfn/y6PmDT198d78EvinwoAjv04hIdI0coD0egWHGK67mZCBOR9EPMS1SbMaB xDHWUkr4d1TooK9NMUuj4+jRIq4HbwpoH2XAy5PbjsK9UEwULZF8JYwc4A7nrMVFqReuaFkFN/cn cVAuXEyKuD2M98tkt3HsxLczSaBvZmnpGN4OiaPmLsOxwgGJiUL6HR8TUmLdLUodv+5QX3DJRwrd oqiFaalL+nTgZNOMaJtGEJdpmc0Qb8c3OzdRi7Myq7fIvouEqsCsRPk+YY4bL+OJwlEZyz6OWNHh V7EKy5TsTYVfxHWkgkgHhHHUGRIpy2iuC7C3EPQrGDpWadh32DRykULRcRnPq5jzInKLj9shjpIy bI/GYRH7gRxDimK0y1UZfIe7FaKfIQ44Xhjum5Q44T6+G9yggaPSLEH0m4nQsYRW7XTgiMZ/144Z hX5sc+Ds2jE0wOdfPSzJrLe1EW/CnlRWCdtH2u8i3NGm2+ZiSN/+nruFJ/EugTSf33jetdx3Ldf7 z7fcRfV80kY7663QdvXcYIdiMyJHCyfkEWWsp6aMXJVmSJawTwy7sKjpzPGQ5CemJISvaV93cIHA hgYJrj6iKuyFOIEBu+ppJoFMWQcSJVzCwc4sl/LWeBjSlT0W1vWBwfYDidUOH9rlFb2cnQtyNma3 CczhMxO0ohmcVNjKhZQpmP06wqpaqRNLqxrVTKtzpOUmQwznTYPF3JswgCAYW8DLq3BA16LhYIIZ GWq/2703C4uJwlmGSIZ4SNIYabvnY1Q1QcpyxdwEQO6UxEgf8o7xWkFaQ7N9A2knCVJRXG2BuCx6 bxKlLINnUdJ1e6QcWVwsThajg6bXqC/XPeTjpOmN4EwLX6MEoi71zIdZADdDvhI27Y8tZlPls2g2 MsPcIqjCNYX1+5zBTh9IhFRbWIY2NcyrNAVYrCVZ/Zfr4NazMsBm+mtosbIGyfCvaQF+dENLRiPi q2KwCyvad/YxbaV8oojohcMDNGATsYch/DpVwZ4hlXA1YTqCfoB7NO1t88ptzmnRFW+vDM6uY5aE OG23ukSzSrZwU8e5DuapoB7YVqq7Me70ppiSPyNTimn8PzNF7ydwU7Ay1BHw4R5XYKTrtelxoUIO XSgJqd8VMDiY3gHZAnex8BqSCm6TzX9B9vV/W3OWhylrOPCpPRogQWE/UqEgZBfaksm+Y5hV073L smQpI5NRBXVlYtUekH3C+roHruq93UMhpLrpJmkbMLij+ec+pxU0CPSQU6w3p4fke6+tgX968rHF DEa5fdgMNJn/cxVLdlVLb8izvbdoiH4xG7NqWVWAsMJW0EjL/jVVOOVWazvWnMXL9Uw5iOK8xbCY D0QJ3Pcg/Qf2Pyp8Rkwa6w21z/egtyL4oUEzg7SBrD5nBw+kG6RdHMDgZBdtMmlW1rXp6KS9lm3W Zzzp5nKPOFtrdpJ4n9LZ+XDminNq8SydnXrY8bVdW+hqiOzREoWlUXaQMYExv2kVf3Xig9sQ6C24 358wJU0ywW9KAsPo2TN1AMVvJRrSjb8AAAD//wMAUEsDBAoAAAAAAAAAIQDHGf7qJ40AACeNAAAW AAAAd29yZC9tZWRpYS9pbWFnZTEuanBlZ//Y/+AAEEpGSUYAAQIBASwBLAAA/+EaSkV4aWYAAE1N ACoAAAAIAAcBEgADAAAAAQABAAABGgAFAAAAAQAAAGIBGwAFAAAAAQAAAGoBKAADAAAAAQACAAAB MQACAAAAFAAAAHIBMgACAAAAFAAAAIaHaQAEAAAAAQAAAJwAAADIAAABLAAAAAEAAAEsAAAAAUFk b2JlIFBob3Rvc2hvcCA3LjAAMjAwNjowNDoyOCAxMzo1MTowMQAAAAADoAEAAwAAAAH//wAAoAIA BAAAAAEAAAEsoAMABAAAAAEAAAEsAAAAAAAAAAYBAwADAAAAAQAGAAABGgAFAAAAAQAAARYBGwAF AAAAAQAAAR4BKAADAAAAAQACAAACAQAEAAAAAQAAASYCAgAEAAAAAQAAGRwAAAAAAAAASAAAAAEA AABIAAAAAf/Y/+AAEEpGSUYAAQIBAEgASAAA/+0ADEFkb2JlX0NNAAL/7gAOQWRvYmUAZIAAAAAB /9sAhAAMCAgICQgMCQkMEQsKCxEVDwwMDxUYExMVExMYEQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwM DAwMDAwMDAwMDAwMAQ0LCw0ODRAODhAUDg4OFBQODg4OFBEMDAwMDBERDAwMDAwMEQwMDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAz/wAARCACAAIADASIAAhEBAxEB/90ABAAI/8QBPwAAAQUBAQEB AQEAAAAAAAAAAwABAgQFBgcICQoLAQABBQEBAQEBAQAAAAAAAAABAAIDBAUGBwgJCgsQAAEEAQMC BAIFBwYIBQMMMwEAAhEDBCESMQVBUWETInGBMgYUkaGxQiMkFVLBYjM0coLRQwclklPw4fFjczUW orKDJkSTVGRFwqN0NhfSVeJl8rOEw9N14/NGJ5SkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2N0dX Z3eHl6e3x9fn9xEAAgIBAgQEAwQFBgcHBgU1AQACEQMhMRIEQVFhcSITBTKBkRShsUIjwVLR8DMk YuFygpJDUxVjczTxJQYWorKDByY1wtJEk1SjF2RFVTZ0ZeLys4TD03Xj80aUpIW0lcTU5PSltcXV 5fVWZnaGlqa2xtbm9ic3R1dnd4eXp7fH/9oADAMBAAIRAxEAPwD1VJJJJSkkkklMbLK6q3W2uDK2 Aue9xgBoEuc5x+i1q4HrP+MHKuvfR0eKcdp2jJe2bHx+fWx/sqZ/xjPU/wCL+grX+Mnq7qqKekVG Df8Apr/6jTFLP7VrXP8A+srg6OVS5nmJCXBA1XzF6b4J8IxSwjmuYiJ8d+1jl8giP05R/S4nYGf1 LIsbbdl3WWMcH1l9jnBrgd7XNrn0/a4fuL0/pOeOo9OozANptb729g9p2WtH9Wxrl5Xj9l3f1Jyd +FfiHmize3+rYJ/8+MtTeUmfcIJ+YfiFfHcETgE4xEfal0HD+rn6Zf8AP4HfyshmNj2Xv+jW0mPE 9m/2nLlqX5W91oteyyxxe/Y4gFxO53t+itr6w3BmIynvdYBHk39If+k1qyqNvdO5qZ4xEH5R/wA4 uXyUOHDKZF8Z/wCbFu43WMqlwblfpauC4CHj+V7fa9bVdjLa22VuDmPEtcOCCucu2xorXQcpwtsw zqyDbX5agWN/tbt/+ejy+aXEISNg7E91vMcvEwOSEeEx1kBsYu2kkkrjnqSSSSU//9D1VDyMinFo syL3BlNLS+x57NaJcdERcJ/jJ6y9vo9HpfDXj1soDuJ/QVu/tNdZs/4lMy5BjgZfZ5trkOUlzfMQ wg0JG5y/dxx+YtfG/wAYN5+sBuuBb0q2KhUeWMn25J27v0v51rf+t/mVr0Fj2WMbZW4PY8BzXNMg g6tc1wXhK7z/ABffWPjomW4aScNx/wA+ygu/8Eq/zP8ARKpy3MEy4Zm+I6H+t2d7418GxxwDPy0O H2YiOSA/SxR/yn9+H6bn/wCMqf29TP8A3FZH+fcuYpMH5ruv8ZnTi6rE6mxv0CaLTrMO/SU/2WuF 3/bi4Jhg/FQ8yCMsr66up8GyRyfDsPD+jEwl/ehJ1Md3C6z6k2kdTsrnSygkjzY9m3/z49cZRYum +p10ddob/pGWN/6Pqf8AotDAayQ8x+LB8UxXy2bwhKX+J63f+s1/69RT2ZWX/wCe7b/6KVGu+Am+ tN8daLf3aax95scs9t+idmN5Z+f5OZy2D+jYtN43/jep0n3yOVZ6C/d1YR2qeT97FiuyNOVt/VGl 1l+RmH6DGilh8SYts/zW+ijhF5Y+d/Yt5rGMfLZZH93h/wAf0vTEgCTwuH6n9dMlnV2W4WuDjF1b qyRF4JiyyfzPo/qjv++Xekr310656bD0jHJD7Gg5TweK3f4DT867/Cf8B/xy4W+xS8zzBEuCBrhP qPj2T8G+FxnA5s8BL3AY44S/cl/lP8L9B9ewszHzsSrLxnb6bmh7D8fzXfy2/Rejrz//ABedZLMy 7pFrzsvm3Haez2ibmj/jKx6n/Wl6ArOHJ7kBL6Hzcn4jycuU5meE6x+bHL97HL5f+8f/0fVV459a 7n3fWTqD7PpC4sH9WsCpn/QYvY15j/jE6S/E6wOoNE0ZwBJjRtjA2t7P7bdln/birc5EnGCOh1dv /i5lhDnJRlpLJjMYeYInwvKqTHvre2xhLXtIc1wMEEahzSop1nPZDUPqGHmVfXL6r347i2rLLdlr QdG2tiym3853oWvY3/wWpeY21vqsfVYNtlbi17TyCDtcFp/Vnrj+idUryTudjP8AZk1tPLD+d/Wq d+kb/wBt/nrU+vnSKsfNr6tie/E6kPU3M1YLIDtwc32/rDT638v9MrGQ+7jE/wBOHpn/AHf0ZORy eP7jzk+W25fmrzct2hlj/O4f8R5uqyF0H1Ru/wCyLAju94++q0LmVufU55P1lwB/Ld/1D1Fi/nIf 3o/m3efgDyvMH/VZP/ScnY+td0fWLJb+62of9Dd/35ZzchE+uVu360Zo8qv/AD0xZIyPNHKf1k/7 0vzafKYL5Tlz3xYz/wCNxdJ2Rp3J7Ack+AXanIH1X+rVbrgHZR0azkOvt3W7Jb/g6vd7/wDRVLlv qf09vUep/abnBuL0/bfYSdC/U0NJkbWt2es//i1S+s/X/wBrdTfbW4nFpmvFGoG38+7afzr3f+Be mpMcvbgcn6UvTD/upNXmOW+9czDlR/NYazcz/eP8zh/wv+g0r8h73OfY4vseS6x55c5xl73f1lSt tlRsulCJJ5Ve3cx4hF0Pq897Ov8ATnNME5VQJHg57WuH9prl7OvK/qH0h3UOtsyHD9BgRc8/y/8A tOz/ADx6v/WV6otDkgRAk9To8r/xmyQlzWOEdZY4evw4zxRi/wD/0ruB/jPvpzslmfT9pwnXvND6 9rba6y52yuPbXkbWbP8ARP8A+Eeuyc/oX1q6Y+llrMqh4BO0j1KnHcGP2u99Fzfds3s/8DXieXQ7 DzsjDf8ASxrX1O76sc6v/vqsYGdlYOQzKw7XU31mWvafwP5rmO/PY72Kl78o2Jjii9NL4VhyiOTl 5exliBKMo/ISPlP9X/Adjr/1a6h0K/bePUxnmKcpohrv5LufTt/4NZMrt+k/4wcXLxXYH1kpFjLA GOvY2WuaeXX0t+jt+nvx/wDtpB639RQ+s9Q+rljcvEcC70Gu3OEf9x7Jd6/53s3er/xqinhErliP EOsf04uhy3xHJiMcPPx9rIfTDP8A+B83+H/k5vHLtfqtlVde6Nk/VrPeDcxu/p736kQPaGaf9pn/ AMvf6FllX8zWuLc1zXFjwWuGhB0IPmj9Pzb+n5tObR/O0PD2gzBj6THR+Y9vseosc+CWvyn0yHeJ b3O8v94wmMTw5YEZMGT9zND1Ql/3MkeRj3Y19mPe3ZdS4ssboYc07XDRbP1Ibu+tGCPOw/dVaVsf XXplGfhUfWjpzSa72N+1CdQCGsqsLW7m76/5i/8ASf6P/hFmfUGov+s2O7/RMscfmx1f/oxPGMwz xjuOKJie8WtPm48x8Mz5a4ZjFlhlh/m80YSjOH+Mr6+tLfrNknjeyo/9Brf++rBqbdbYyqppsssI axjRJLidrWtA/eXS/wCMZm36wg/v0MP4vb/31WPqN0imqu/6x9QaRjYbXOx5HJaCbbmt/P8AS+hX /wAL/wAJUjLGZ55RH7xJPaKMHNx5f4VgzSHERihCEOuTLXBCAT/WC7/m19XMfoGOW/bM1pfm2NOs GBb+77bXfq9b/wDQUvXEEkq11bqNvU+pZGfbo695cG87Wj21VyA3+brDWKqAXENaJJ0AHJKjyz4p afKPTEf1Q2eR5Y4MPrN5shOXPP8Aey5Pm/wYfJFZanQfq9ndcyhTjtLKWn9NkuHsYP8Av9v7lX/o v9Itvon1Etcxuf154wsJo3uqc7Y8jt6zne3HZ+9/hv8Ailc6j9esDp+I3p31boDWVAsbc9sMaP36 mH33Pd9P1L/z/p+tvT4YQBxZTwx6R/Tm1uY+IzySOD4fH38vyyzf+BuX/vZP05/1Hp8dnRfqv0xl L7a8algJc95h9rwP0lm3+cutd+6z+ouU6n/jHvuurr6ZSaKQ9pfbZBe5oLdzBX7mVfnfnW/9bXIZ udmZ+Q7JzLXX3P5c49udrR9FjP5DEOis3X10t1dY9rAPNx2p8+akajjHBHYfvMHLfAsMDLNzcvvO aVykZfzYl+keH9P/AKo//9N/8Z3QLcXqY6zSz9VzNrbnD828Dbq2Pa26pjHf8b6q41j17/m4WLn4 tmHmVNux7m7bK3cEf99c13uY9v0F5Z9Yv8XHVem2G7pQf1HDMna0D1ma+1jqx/SPb/hKW/8AWa1V zYTZkBdu78M+IxEY4skuGUdIk7Sj/wB8801y0uj9c6l0e/18G0sLo9Ss6seB+bYz87/q1lWMux7X U5FbqbWGHV2NLHA/ymPhyk148VUIMTY0IehjPHlgYzEZwkNYy9UZPoVXV/qx9bWV09aYMDqQAa3I Ydod+dDbnhzNuntqyf8ArNnqLF639SusdJD7mt+14jJcb6uWtE+62n6dftG5/wDOVM/0q5sOC6P6 v/XbqfR4psJzMMQPRscdzABtAos93pt/4P8Am0/jhPTKKP8AnI/93Fr/AHfmOV9XJT48fXlMx9H/ AKb5f8l/ddj/ABe9TquryegZh31Xtc6it3BBBblUjX85n6TY3/hlZ+rfQLOjfXK/GO51Axn241ro lzC+pnu2/n17vTf/AJ60MTB+rXX7aOr9IeMXNx3stf6IDHgzudXl44+l6n6Rnqf4T/S21rp9rdwd A3AEA94PP5FZx4rjCyD7ZuEx+lHs4fO/EOHJzHtwlj+9w4OZ5fIOE4s8f8rH+88N9bei39Z+t2Hi V+1jsVrrrP3a2WW+o/v+81lf/CKP1/6hXgYGJ9XsM7atjXXN1JFdcNxmbj+89m9/5/6Ji7va3dug boie8Lms/p31c6Rk5HWutWDKyshzn1NuhxhujKcXG/PdUz0a/Uf9D/gUsmKhMgge4fVM/owRyXxA SyctHJCWSPKRrBgxjjln5k7ZP6vA8V0T6ndY6vstaz7PiOInIt0Bb+9VX9O72/Q/wX/CrefnfVb6 oiyvpzf2h1dssdY8yGH87dY0emxrfzq6P0v+Ctesn6wfXjqPVZoxd2Fh6gsY473g+39NY2Pbt/wT P+uequalVeOGPTGOKX+cl/3EXoByvM836udl7WI/+BMJ+b/zpzf5T+5B0esde6n1m4W5tstb/N0t 9tbf6lf738t36RZ6aVKqq26xtVLHW2OMNYwFzif5LWqEkyNk2S6MI48UBCEY44RGkY+mMWK6j6g9 Efn9Vbn21k4mEd4fw03CDVX/ACvT/nvb/wAHv/nE3QvqH1XqFgsz2uwMUEbt4i137za6nfQ/4y3/ AMFXpODg4uBi14mJWKqKhDWj8XOP5znK1y/LyMhOQqI1AP6ThfGfjOOGKfL4JCeWY4ZyifTiifm9 X77/AP/U9VWJ9aPrFd9XsWvMGC/MxnEtusY8NFRO30vU9r/ZbLm+p+//AMbWttBy8XHzMa3EyWCy i9hrtYZEtcNrhLYc3+ygbrQ0V2MxEwZx4o36o7aPAW/42cawQ7pBsHg+5v8A6RchD/GliH/vDr/7 eb/7yrG+tP1E6n0S2zIxmOy+mlx2WMBdZW2N23KY0e3b9H12/ov+J9T0ly0jxVWWTKDRNfQO9g5T kckRKEeKJ/rz/wC+fQz/AIzqHfQ6NU342g/+67Umf4xMzIsbTidIofc8wxgDrHE+DWVta5ywvq99 Ruu9Z23Fn2PDJg5F4IJGkmmj22W8/wDB0/8ACr0/oP1Y6T0Ks/Y65ve0NtyXmXuA1/q1s3fmVIxj mlvLhHkFnMZfhuAVHF7uX93jycI/vy403RW9V+zm3qlWPj3WQW047TLR+7dY5722P/4v/prRSSVk ChTiZJ8cjKhG/wBGPyjyUqPV29ROL6nTaqLsmuSKsgGHCNa63tcz07Hfy/0avJJEWKVCfBISoSo7 S+U+b53Z/jAzsW11GZ0mll1Zh9Z3McO/0Xtcnb/jLr/O6RWfhaB/6Icux6z9Xul9aqDM6qXsBFdz DtsZP7rv++Wb615v136j9Z6SDbW37biD/C0g7mjxuo9z2f1merWqmQcxDUS4o+Qt6HksnwnmQI5M Iw5f3TkyRhL/AGc+P/muz/45mP8A+U7P+3h/7zojP8aGMzQdMLZ522j/ANJNXnpeFv8A1b+p/Uut 2stex2P08EGy942lzZ9wxtzT6j/5f80o4Zc8jQN/SLb5j4f8LxQM8kOGI75Mv/fvov1a+sbuv1XX tw341FRDW2OduD3Gd7WQ1v8AN/nf11toGFh42Bi1YeKwVUUt2sYPD/vznfSe5HV+IIA4jZ6l5XPL HLJI4oe3jv0QviqPiZP/1fVUlwv1F/xi5f1p6xd067Crxm047r97HlxJa+qrb7mt/wBMuw6nluwu m5eYxoe7GosuawmA41tdYGl2v0tqSm0oejT6nq7G+rEb4G6PDd9Jcj9Qvr1k/WsdQN2IzG+wtqLd ji7cbPW53D/gVW+on+MTL+tXVbsC7Crxm045v3se5xJD66tu1zf+FSU90ks36x9Vs6N0PM6pVWLn 4tfqNrcSAdQNXBY/1C+uWR9bMXLvvxmYv2axrGhji6dzd2u4NSU9UkuW+vn11H1Tw8WyugZWTl2F tdTnFrQxgBus3NDvoufUzb/wih9Q/r3V9bKslltTcXNxnAmhrtwdU76NzN21/ts9lv7n6L/SpKes SXC9W/xi5fRvrhX0HqGFWzDtsrDczeW/oroay8h42babD+m/4q1df1bPb0zpeZ1Fzd4w6LL9kxu9 NrrNm7+Xt2JKbaS83+qv+Nq3rXXcXpeZhVYteUXMbc2wmLNpdU3a9v8AhXt9H+vYu1+svW6+g9Dy +q2N3/ZmSyvjdY4iuln9q17NySm+aKDaLjWw2jQWbRuj+v8ASRFyX1T+u56v0HM6/wBXZT03BxbD WH7nGdrWOe87m+7e+6uqllf6Sy39GsD/AMd3qOflW09A6BdnMq13Ave8s4bY+jGps9H/ALdsSVZf TEl59gfX366ZOfjY9/1WyKKbra67bnV3gMY5zW2WuLqQ32MO5Wfr5/jDy/qr1PHwqcOvJZfQLi97 3NIO99e3a1p/cSU//9bkPqH9YMvoHW78zE6dZ1SyzHfSaKi5rmtNlNnreyrI9rfS2fQ/wi7Tqf8A jM63l9Ny8V/1WyqWX0WVutL7CGBzHNdY79Tb/Nt9/wBJY/8AiYa5v1sy9zS2cG2JEf4bFXrH1hn9 gdSjn7JfEf8AFvSU+b/4kOOuf1cb/wB2ln/4k/8AxS5n/hJ3/n3HWl/iOaQ7rQcIkYvPgftSxuij qn+LX60W3dUwrcjCsrdjnIqadr63OrtbdjvdtqfY30m/oX2JKfT/AK//APiN6t/4XP5WrlP8SH/J nU/+Pr/6gql9bP8AGdhfWHol/Ruh4OW7JzdrHOsYzRgc179jKH5LrXWbPS/wahhVZv1H/wAXWYc1 pp6t1ywsxaGki1jH1hm+xo99VtNXr3e3+ae/Hrs9O1JTXd1Cr62f4zm5F+VVT0npFgdVY+xnpmvG eNnpvdtrt+3Zf6T/AML2f8CgZPUMT6nf4yzn4VjLOlZp32ei9jm+jkH9Yb+i3NZ9my2Ouro/4CpX fqX/AIqendY6BT1Pq92TTdlFz6a6HMaBT9Gp1jbqLffZtfb7X/zL6kvrr/iq6d0boF3U+kW5V92K 5r7q7nMePR+ja9jaaKnbq3OZY73bPR9VJTe/x1dC9XFw+vVNl2OfsuTEk+m8mzHf+61ldvqs/wDQ hil9b/rY3I/xX4NrLC/J6u2vHtcTD91X9PfH5zPWx/Rd/wCGFb+qtx+un+LvJ6Hlv/Xsdn2UueYM s23dNyLNg3+nuZXW/wD032e5eXdOxuodSzenfVy/eykZprALfdW691NOX/223G3bP+MSU7XXui/8 2+m/VPruKP09tTb7fbA9Vr29QodY8fSs9PJ9D/i8VdT/AI3vrBjZX1f6Ti4ji8dTc3NaQQD6LWfo hZX9L9M/J9n/AIXeul/xk9DZ1P6nZVVLALOngZWO0GABSD6rYH0v1R17WM/f2Lyv6ldPy/rJ9Zuk 4WZL8XpzJMiIope/KFTv32vyL/R/qWpKeu+vXTn/AFb/AMWPT+j1wHPvqrzCDIc9zbs2/wB35zft NXs/kLI+o/1xzPq/0UY+D9W7843WOfbnVueBYQdrW+3Fv/mW/o9vq/8AnxekfXn6uWfWP6u39PoL RlBzLsZzzDQ9h7kT9Op1tX9ted/Vb67dY+pVFnQeudLvfTTY40x7H17jutY3cPSyKH2fparGP/P/ AMLXZX6aU9Lgf4zOtZWdjYtn1XyaGZFrKnXOfYQwPc1hsdOGz6G7d9Jcx/jt/wDFBg/+Ex/58tXT 4P8Aje6dm52Nht6bksdlXV0te4sgGxzag4/5y5r/AB1se76wYO1pP6mOBP8AhLUlP//Z/+0e+FBo b3Rvc2hvcCAzLjAAOEJJTQQlAAAAAAAQAAAAAAAAAAAAAAAAAAAAADhCSU0D7QAAAAAAEAEsAAAA AQACASwAAAABAAI4QklNBCYAAAAAAA4AAAAAAAAAAAAAP4AAADhCSU0EDQAAAAAABAAAAB44QklN BBkAAAAAAAQAAAAeOEJJTQPzAAAAAAAJAAAAAAAAAAABADhCSU0ECgAAAAAAAQAAOEJJTScQAAAA AAAKAAEAAAAAAAAAAjhCSU0D9QAAAAAASAAvZmYAAQBsZmYABgAAAAAAAQAvZmYAAQChmZoABgAA AAAAAQAyAAAAAQBaAAAABgAAAAAAAQA1AAAAAQAtAAAABgAAAAAAAThCSU0D+AAAAAAAcAAA//// /////////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///// ////////////////////////A+gAAAAA/////////////////////////////wPoAAA4QklNBAgA AAAAABAAAAABAAACQAAAAkAAAAAAOEJJTQQeAAAAAAAEAAAAADhCSU0EGgAAAAADWwAAAAYAAAAA AAAAAAAAASwAAAEsAAAAEwBIAFcAXwBQAE8AUwBfAFIARwBCAF8AVgBlAHIAdABpAGMAYQBsAAAA AQAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAEsAAABLAAAAAAAAAAAAAAAAAAAAAABAAAA AAAAAAAAAAAAAAAAAAAAABAAAAABAAAAAAAAbnVsbAAAAAIAAAAGYm91bmRzT2JqYwAAAAEAAAAA AABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAATGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAB LAAAAABSZ2h0bG9uZwAAASwAAAAGc2xpY2VzVmxMcwAAAAFPYmpjAAAAAQAAAAAABXNsaWNlAAAA EgAAAAdzbGljZUlEbG9uZwAAAAAAAAAHZ3JvdXBJRGxvbmcAAAAAAAAABm9yaWdpbmVudW0AAAAM RVNsaWNlT3JpZ2luAAAADWF1dG9HZW5lcmF0ZWQAAAAAVHlwZWVudW0AAAAKRVNsaWNlVHlwZQAA AABJbWcgAAAABmJvdW5kc09iamMAAAABAAAAAAAAUmN0MQAAAAQAAAAAVG9wIGxvbmcAAAAAAAAA AExlZnRsb25nAAAAAAAAAABCdG9tbG9uZwAAASwAAAAAUmdodGxvbmcAAAEsAAAAA3VybFRFWFQA AAABAAAAAAAAbnVsbFRFWFQAAAABAAAAAAAATXNnZVRFWFQAAAABAAAAAAAGYWx0VGFnVEVYVAAA AAEAAAAAAA5jZWxsVGV4dElzSFRNTGJvb2wBAAAACGNlbGxUZXh0VEVYVAAAAAEAAAAAAAlob3J6 QWxpZ25lbnVtAAAAD0VTbGljZUhvcnpBbGlnbgAAAAdkZWZhdWx0AAAACXZlcnRBbGlnbmVudW0A AAAPRVNsaWNlVmVydEFsaWduAAAAB2RlZmF1bHQAAAALYmdDb2xvclR5cGVlbnVtAAAAEUVTbGlj ZUJHQ29sb3JUeXBlAAAAAE5vbmUAAAAJdG9wT3V0c2V0bG9uZwAAAAAAAAAKbGVmdE91dHNldGxv bmcAAAAAAAAADGJvdHRvbU91dHNldGxvbmcAAAAAAAAAC3JpZ2h0T3V0c2V0bG9uZwAAAAAAOEJJ TQQRAAAAAAABAQA4QklNBBQAAAAAAAQAAAABOEJJTQQMAAAAABk4AAAAAQAAAIAAAACAAAABgAAA wAAAABkcABgAAf/Y/+AAEEpGSUYAAQIBAEgASAAA/+0ADEFkb2JlX0NNAAL/7gAOQWRvYmUAZIAA AAAB/9sAhAAMCAgICQgMCQkMEQsKCxEVDwwMDxUYExMVExMYEQwMDAwMDBEMDAwMDAwMDAwMDAwM DAwMDAwMDAwMDAwMDAwMAQ0LCw0ODRAODhAUDg4OFBQODg4OFBEMDAwMDBERDAwMDAwMEQwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz/wAARCACAAIADASIAAhEBAxEB/90ABAAI/8QBPwAAAQUB AQEBAQEAAAAAAAAAAwABAgQFBgcICQoLAQABBQEBAQEBAQAAAAAAAAABAAIDBAUGBwgJCgsQAAEE AQMCBAIFBwYIBQMMMwEAAhEDBCESMQVBUWETInGBMgYUkaGxQiMkFVLBYjM0coLRQwclklPw4fFj czUWorKDJkSTVGRFwqN0NhfSVeJl8rOEw9N14/NGJ5SkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2 N0dXZ3eHl6e3x9fn9xEAAgIBAgQEAwQFBgcHBgU1AQACEQMhMRIEQVFhcSITBTKBkRShsUIjwVLR 8DMkYuFygpJDUxVjczTxJQYWorKDByY1wtJEk1SjF2RFVTZ0ZeLys4TD03Xj80aUpIW0lcTU5PSl tcXV5fVWZnaGlqa2xtbm9ic3R1dnd4eXp7fH/9oADAMBAAIRAxEAPwD1VJJJJSkkkklMbLK6q3W2 uDK2Aue9xgBoEuc5x+i1q4HrP+MHKuvfR0eKcdp2jJe2bHx+fWx/sqZ/xjPU/wCL+grX+Mnq7qqK ekVGDf8Apr/6jTFLP7VrXP8A+srg6OVS5nmJCXBA1XzF6b4J8IxSwjmuYiJ8d+1jl8giP05R/S4n YGf1LIsbbdl3WWMcH1l9jnBrgd7XNrn0/a4fuL0/pOeOo9OozANptb729g9p2WtH9Wxrl5Xj9l3f 1Jyd+FfiHmize3+rYJ/8+MtTeUmfcIJ+YfiFfHcETgE4xEfal0HD+rn6Zf8AP4HfyshmNj2Xv+jW 0mPE9m/2nLlqX5W91oteyyxxe/Y4gFxO53t+itr6w3BmIynvdYBHk39If+k1qyqNvdO5qZ4xEH5R /wA4uXyUOHDKZF8Z/wCbFu43WMqlwblfpauC4CHj+V7fa9bVdjLa22VuDmPEtcOCCucu2xorXQcp wtswzqyDbX5agWN/tbt/+ejy+aXEISNg7E91vMcvEwOSEeEx1kBsYu2kkkrjnqSSSSU//9D1VDyM inFosyL3BlNLS+x57NaJcdERcJ/jJ6y9vo9HpfDXj1soDuJ/QVu/tNdZs/4lMy5BjgZfZ5trkOUl zfMQwg0JG5y/dxx+YtfG/wAYN5+sBuuBb0q2KhUeWMn25J27v0v51rf+t/mVr0Fj2WMbZW4PY8Bz XNMgg6tc1wXhK7z/ABffWPjomW4aScNx/wA+ygu/8Eq/zP8ARKpy3MEy4Zm+I6H+t2d7418GxxwD Py0OH2YiOSA/SxR/yn9+H6bn/wCMqf29TP8A3FZH+fcuYpMH5ruv8ZnTi6rE6mxv0CaLTrMO/SU/ 2WuF3/bi4Jhg/FQ8yCMsr66up8GyRyfDsPD+jEwl/ehJ1Md3C6z6k2kdTsrnSygkjzY9m3/z49cZ RYum+p10ddob/pGWN/6Pqf8AotDAayQ8x+LB8UxXy2bwhKX+J63f+s1/69RT2ZWX/wCe7b/6KVGu +Am+tN8daLf3aax95scs9t+idmN5Z+f5OZy2D+jYtN43/jep0n3yOVZ6C/d1YR2qeT97FiuyNOVt /VGl1l+RmH6DGilh8SYts/zW+ijhF5Y+d/Yt5rGMfLZZH93h/wAf0vTEgCTwuH6n9dMlnV2W4WuD jF1bqyRF4JiyyfzPo/qjv++Xekr310656bD0jHJD7Gg5TweK3f4DT867/Cf8B/xy4W+xS8zzBEuC BrhPqPj2T8G+FxnA5s8BL3AY44S/cl/lP8L9B9ewszHzsSrLxnb6bmh7D8fzXfy2/Rejrz//ABed ZLMy7pFrzsvm3Haez2ibmj/jKx6n/Wl6ArOHJ7kBL6Hzcn4jycuU5meE6x+bHL97HL5f+8f/0fVV 459a7n3fWTqD7PpC4sH9WsCpn/QYvY15j/jE6S/E6wOoNE0ZwBJjRtjA2t7P7bdln/birc5EnGCO h1dv/i5lhDnJRlpLJjMYeYInwvKqTHvre2xhLXtIc1wMEEahzSop1nPZDUPqGHmVfXL6r347i2rL LdlrQdG2tiym3853oWvY3/wWpeY21vqsfVYNtlbi17TyCDtcFp/Vnrj+idUryTudjP8AZk1tPLD+ d/Wqd+kb/wBt/nrU+vnSKsfNr6tie/E6kPU3M1YLIDtwc32/rDT638v9MrGQ+7jE/wBOHpn/AHf0 ZORyeP7jzk+W25fmrzct2hlj/O4f8R5uqyF0H1Ru/wCyLAju94++q0LmVufU55P1lwB/Ld/1D1Fi /nIf3o/m3efgDyvMH/VZP/ScnY+td0fWLJb+62of9Dd/35ZzchE+uVu360Zo8qv/AD0xZIyPNHKf 1k/70vzafKYL5Tlz3xYz/wCNxdJ2Rp3J7Ack+AXanIH1X+rVbrgHZR0azkOvt3W7Jb/g6vd7/wDR VLlvqf09vUep/abnBuL0/bfYSdC/U0NJkbWt2es//i1S+s/X/wBrdTfbW4nFpmvFGoG38+7afzr3 f+BempMcvbgcn6UvTD/upNXmOW+9czDlR/NYazcz/eP8zh/wv+g0r8h73OfY4vseS6x55c5xl73f 1lSttlRsulCJJ5Ve3cx4hF0Pq897Ov8ATnNME5VQJHg57WuH9prl7OvK/qH0h3UOtsyHD9BgRc8/ y/8AtOz/ADx6v/WV6otDkgRAk9To8r/xmyQlzWOEdZY4evw4zxRi/wD/0ruB/jPvpzslmfT9pwnX vND69rba6y52yuPbXkbWbP8ARP8A+Eeuyc/oX1q6Y+llrMqh4BO0j1KnHcGP2u99Fzfds3s/8DXi eXQ7DzsjDf8ASxrX1O76sc6v/vqsYGdlYOQzKw7XU31mWvafwP5rmO/PY72Kl78o2Jjii9NL4Vhy iOTl5exliBKMo/ISPlP9X/Adjr/1a6h0K/bePUxnmKcpohrv5LufTt/4NZMrt+k/4wcXLxXYH1kp FjLAGOvY2WuaeXX0t+jt+nvx/wDtpB639RQ+s9Q+rljcvEcC70Gu3OEf9x7Jd6/53s3er/xqinhE rliPEOsf04uhy3xHJiMcPPx9rIfTDP8A+B83+H/k5vHLtfqtlVde6Nk/VrPeDcxu/p736kQPaGaf 9pn/AMvf6FllX8zWuLc1zXFjwWuGhB0IPmj9Pzb+n5tObR/O0PD2gzBj6THR+Y9vseosc+CWvyn0 yHeJb3O8v94wmMTw5YEZMGT9zND1Ql/3MkeRj3Y19mPe3ZdS4ssboYc07XDRbP1Ibu+tGCPOw/dV aVsfXXplGfhUfWjpzSa72N+1CdQCGsqsLW7m76/5i/8ASf6P/hFmfUGov+s2O7/RMscfmx1f/oxP GMwzxjuOKJie8WtPm48x8Mz5a4ZjFlhlh/m80YSjOH+Mr6+tLfrNknjeyo/9Brf++rBqbdbYyqpp sssIaxjRJLidrWtA/eXS/wCMZm36wg/v0MP4vb/31WPqN0imqu/6x9QaRjYbXOx5HJaCbbmt/P8A S+hX/wAL/wAJUjLGZ55RH7xJPaKMHNx5f4VgzSHERihCEOuTLXBCAT/WC7/m19XMfoGOW/bM1pfm 2NOsGBb+77bXfq9b/wDQUvXEEkq11bqNvU+pZGfbo695cG87Wj21VyA3+brDWKqAXENaJJ0AHJKj yz4pafKPTEf1Q2eR5Y4MPrN5shOXPP8Aey5Pm/wYfJFZanQfq9ndcyhTjtLKWn9NkuHsYP8Av9v7 lX/ov9Itvon1Etcxuf154wsJo3uqc7Y8jt6zne3HZ+9/hv8Ailc6j9esDp+I3p31boDWVAsbc9sM aP36mH33Pd9P1L/z/p+tvT4YQBxZTwx6R/Tm1uY+IzySOD4fH38vyyzf+BuX/vZP05/1Hp8dnRfq v0xlL7a8algJc95h9rwP0lm3+cutd+6z+ouU6n/jHvuurr6ZSaKQ9pfbZBe5oLdzBX7mVfnfnW/9 bXIZudmZ+Q7JzLXX3P5c49udrR9FjP5DEOis3X10t1dY9rAPNx2p8+akajjHBHYfvMHLfAsMDLNz cvvOaVykZfzYl+keH9P/AKo//9N/8Z3QLcXqY6zSz9VzNrbnD828Dbq2Pa26pjHf8b6q41j17/m4 WLn4tmHmVNux7m7bK3cEf99c13uY9v0F5Z9Yv8XHVem2G7pQf1HDMna0D1ma+1jqx/SPb/hKW/8A Wa1VzYTZkBdu78M+IxEY4skuGUdIk7Sj/wB8801y0uj9c6l0e/18G0sLo9Ss6seB+bYz87/q1lWM ux7XU5FbqbWGHV2NLHA/ymPhyk148VUIMTY0IehjPHlgYzEZwkNYy9UZPoVXV/qx9bWV09aYMDqQ Aa3IYdod+dDbnhzNuntqyf8ArNnqLF639SusdJD7mt+14jJcb6uWtE+62n6dftG5/wDOVM/0q5sO C6P6v/XbqfR4psJzMMQPRscdzABtAos93pt/4P8Am0/jhPTKKP8AnI/93Fr/AHfmOV9XJT48fXlM x9H/AKb5f8l/ddj/ABe9TquryegZh31Xtc6it3BBBblUjX85n6TY3/hlZ+rfQLOjfXK/GO51Axn2 41rolzC+pnu2/n17vTf/AJ60MTB+rXX7aOr9IeMXNx3stf6IDHgzudXl44+l6n6Rnqf4T/S21rp9 rdwdA3AEA94PP5FZx4rjCyD7ZuEx+lHs4fO/EOHJzHtwlj+9w4OZ5fIOE4s8f8rH+88N9bei39Z+ t2HiV+1jsVrrrP3a2WW+o/v+81lf/CKP1/6hXgYGJ9XsM7atjXXN1JFdcNxmbj+89m9/5/6Ji7va 3dugboie8Lms/p31c6Rk5HWutWDKyshzn1NuhxhujKcXG/PdUz0a/Uf9D/gUsmKhMgge4fVM/owR yXxASyctHJCWSPKRrBgxjjln5k7ZP6vA8V0T6ndY6vstaz7PiOInIt0Bb+9VX9O72/Q/wX/Crefn fVb6oiyvpzf2h1dssdY8yGH87dY0emxrfzq6P0v+Ctesn6wfXjqPVZoxd2Fh6gsY473g+39NY2Pb t/wTP+uequalVeOGPTGOKX+cl/3EXoByvM836udl7WI/+BMJ+b/zpzf5T+5B0esde6n1m4W5tstb /N0t9tbf6lf738t36RZ6aVKqq26xtVLHW2OMNYwFzif5LWqEkyNk2S6MI48UBCEY44RGkY+mMWK6 j6g9Efn9Vbn21k4mEd4fw03CDVX/ACvT/nvb/wAHv/nE3QvqH1XqFgsz2uwMUEbt4i137za6nfQ/ 4y3/AMFXpODg4uBi14mJWKqKhDWj8XOP5znK1y/LyMhOQqI1AP6ThfGfjOOGKfL4JCeWY4ZyifTi ifm9X77/AP/U9VWJ9aPrFd9XsWvMGC/MxnEtusY8NFRO30vU9r/ZbLm+p+//AMbWttBy8XHzMa3E yWCyi9hrtYZEtcNrhLYc3+ygbrQ0V2MxEwZx4o36o7aPAW/42cawQ7pBsHg+5v8A6RchD/GliH/v Dr/7eb/7yrG+tP1E6n0S2zIxmOy+mlx2WMBdZW2N23KY0e3b9H12/ov+J9T0ly0jxVWWTKDRNfQO 9g5TkckRKEeKJ/rz/wC+fQz/AIzqHfQ6NU342g/+67Umf4xMzIsbTidIofc8wxgDrHE+DWVta5yw vq99Ruu9Z23Fn2PDJg5F4IJGkmmj22W8/wDB0/8ACr0/oP1Y6T0Ks/Y65ve0NtyXmXuA1/q1s3fm VIxjmlvLhHkFnMZfhuAVHF7uX93jycI/vy403RW9V+zm3qlWPj3WQW047TLR+7dY5722P/4v/prR SSVkChTiZJ8cjKhG/wBGPyjyUqPV29ROL6nTaqLsmuSKsgGHCNa63tcz07Hfy/0avJJEWKVCfBIS oSo7S+U+b53Z/jAzsW11GZ0mll1Zh9Z3McO/0Xtcnb/jLr/O6RWfhaB/6Icux6z9Xul9aqDM6qXs BFdzDtsZP7rv++Wb615v136j9Z6SDbW37biD/C0g7mjxuo9z2f1merWqmQcxDUS4o+Qt6Hksnwnm QI5MIw5f3TkyRhL/AGc+P/muz/45mP8A+U7P+3h/7zojP8aGMzQdMLZ522j/ANJNXnpeFv8A1b+p /Uut2stex2P08EGy942lzZ9wxtzT6j/5f80o4Zc8jQN/SLb5j4f8LxQM8kOGI75Mv/fvov1a+sbu v1XXtw341FRDW2OduD3Gd7WQ1v8AN/nf11toGFh42Bi1YeKwVUUt2sYPD/vznfSe5HV+IIA4jZ6l 5XPLHLJI4oe3jv0QviqPiZP/1fVUlwv1F/xi5f1p6xd067Crxm047r97HlxJa+qrb7mt/wBMuw6n luwum5eYxoe7GosuawmA41tdYGl2v0tqSm0oejT6nq7G+rEb4G6PDd9Jcj9Qvr1k/WsdQN2IzG+w tqLdji7cbPW53D/gVW+on+MTL+tXVbsC7Crxm045v3se5xJD66tu1zf+FSU90ks36x9Vs6N0PM6p VWLn4tfqNrcSAdQNXBY/1C+uWR9bMXLvvxmYv2axrGhji6dzd2u4NSU9UkuW+vn11H1Tw8WyugZW Tl2FtdTnFrQxgBus3NDvoufUzb/wih9Q/r3V9bKslltTcXNxnAmhrtwdU76NzN21/ts9lv7n6L/S pKesSXC9W/xi5fRvrhX0HqGFWzDtsrDczeW/oroay8h42babD+m/4q1df1bPb0zpeZ1Fzd4w6LL9 kxu9NrrNm7+Xt2JKbaS83+qv+Nq3rXXcXpeZhVYteUXMbc2wmLNpdU3a9v8AhXt9H+vYu1+svW6+ g9Dy+q2N3/ZmSyvjdY4iuln9q17NySm+aKDaLjWw2jQWbRuj+v8ASRFyX1T+u56v0HM6/wBXZT03 BxbDWH7nGdrWOe87m+7e+6uqllf6Sy39GsD/AMd3qOflW09A6BdnMq13Ave8s4bY+jGps9H/ALds SVZfTEl59gfX366ZOfjY9/1WyKKbra67bnV3gMY5zW2WuLqQ32MO5Wfr5/jDy/qr1PHwqcOvJZfQ Li973NIO99e3a1p/cSU//9bkPqH9YMvoHW78zE6dZ1SyzHfSaKi5rmtNlNnreyrI9rfS2fQ/wi7T qf8AjM63l9Ny8V/1WyqWX0WVutL7CGBzHNdY79Tb/Nt9/wBJY/8AiYa5v1sy9zS2cG2JEf4bFXrH 1hn9gdSjn7JfEf8AFvSU+b/4kOOuf1cb/wB2ln/4k/8AxS5n/hJ3/n3HWl/iOaQ7rQcIkYvPgftS xuijqn+LX60W3dUwrcjCsrdjnIqadr63OrtbdjvdtqfY30m/oX2JKfT/AK//APiN6t/4XP5WrlP8 SH/JnU/+Pr/6gql9bP8AGdhfWHol/Ruh4OW7JzdrHOsYzRgc179jKH5LrXWbPS/wahhVZv1H/wAX WYc1pp6t1ywsxaGki1jH1hm+xo99VtNXr3e3+ae/Hrs9O1JTXd1Cr62f4zm5F+VVT0npFgdVY+xn pmvGeNnpvdtrt+3Zf6T/AML2f8CgZPUMT6nf4yzn4VjLOlZp32ei9jm+jkH9Yb+i3NZ9my2Ouro/ 4CpXfqX/AIqendY6BT1Pq92TTdlFz6a6HMaBT9Gp1jbqLffZtfb7X/zL6kvrr/iq6d0boF3U+kW5 V92K5r7q7nMePR+ja9jaaKnbq3OZY73bPR9VJTe/x1dC9XFw+vVNl2OfsuTEk+m8mzHf+61ldvqs /wDQhil9b/rY3I/xX4NrLC/J6u2vHtcTD91X9PfH5zPWx/Rd/wCGFb+qtx+un+LvJ6Hlv/Xsdn2U ueYMs23dNyLNg3+nuZXW/wD032e5eXdOxuodSzenfVy/eykZprALfdW691NOX/223G3bP+MSU7XX ui/82+m/VPruKP09tTb7fbA9Vr29QodY8fSs9PJ9D/i8VdT/AI3vrBjZX1f6Ti4ji8dTc3NaQQD6 LWfohZX9L9M/J9n/AIXeul/xk9DZ1P6nZVVLALOngZWO0GABSD6rYH0v1R17WM/f2Lyv6ldPy/rJ 9Zuk4WZL8XpzJMiIope/KFTv32vyL/R/qWpKeu+vXTn/AFb/AMWPT+j1wHPvqrzCDIc9zbs2/wB3 5zftNXs/kLI+o/1xzPq/0UY+D9W7843WOfbnVueBYQdrW+3Fv/mW/o9vq/8AnxekfXn6uWfWP6u3 9PoLRlBzLsZzzDQ9h7kT9Op1tX9ted/Vb67dY+pVFnQeudLvfTTY40x7H17jutY3cPSyKH2fparG P/P/AMLXZX6aU9Lgf4zOtZWdjYtn1XyaGZFrKnXOfYQwPc1hsdOGz6G7d9Jcx/jt/wDFBg/+Ex/5 8tXT4P8Aje6dm52Nht6bksdlXV0te4sgGxzag4/5y5r/AB1se76wYO1pP6mOBP8AhLUlP//ZOEJJ TQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBBAGQA bwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgADcALgAwAAAAAQA4QklNBAYAAAAAAAcAAQAAAAEB AP/hEkhodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvADw/eHBhY2tldCBiZWdpbj0n77u/JyBp ZD0nVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkJz8+Cjw/YWRvYmUteGFwLWZpbHRlcnMgZXNjPSJD UiI/Pgo8eDp4YXBtZXRhIHhtbG5zOng9J2Fkb2JlOm5zOm1ldGEvJyB4OnhhcHRrPSdYTVAgdG9v bGtpdCAyLjguMi0zMywgZnJhbWV3b3JrIDEuNSc+CjxyZGY6UkRGIHhtbG5zOnJkZj0naHR0cDov L3d3dy53My5vcmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIycgeG1sbnM6aVg9J2h0dHA6Ly9u cy5hZG9iZS5jb20vaVgvMS4wLyc+CgogPHJkZjpEZXNjcmlwdGlvbiBhYm91dD0ndXVpZDplNjUw ZWE2NC1kNjdhLTExZGEtYmI1YS1lMmZlYThiNzYxZTMnCiAgeG1sbnM6eGFwTU09J2h0dHA6Ly9u cy5hZG9iZS5jb20veGFwLzEuMC9tbS8nPgogIDx4YXBNTTpEb2N1bWVudElEPmFkb2JlOmRvY2lk OnBob3Rvc2hvcDplNjUwZWE2Mi1kNjdhLTExZGEtYmI1YS1lMmZlYThiNzYxZTM8L3hhcE1NOkRv Y3VtZW50SUQ+CiA8L3JkZjpEZXNjcmlwdGlvbj4KCjwvcmRmOlJERj4KPC94OnhhcG1ldGE+CiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAo8P3hwYWNrZXQg ZW5kPSd3Jz8+/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBELCgsRFQ8MDA8VGBMTFRMT GBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsNDg0QDg4QFA4ODhQUDg4O DhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgBLAEsAwEi AAIRAQMRAf/dAAQAE//EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUBAQEBAQEA AAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJxgTIGFJGh sUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePzRieUpIW0 lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYFNQEAAhED ITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNUoxdkRVU2 dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//aAAwDAQAC EQMRAD8A9VSSSSUpJJJJSkkkklKSSSSUpJJJJSkklm9d67h9Ewzk5J3PdpTSPpPd4D+T++9AkRBJ NAL8WKeWcceOJnOZqMR1buRk4+LS6/JsbTUwS57yAB965XqP+MTCqca+m0uySNPVf7Gf2W/zj/8A oLiur9e6h1rIN2W/2A/oqG6MYP5Lf3v5aqsCo5eckTWP0jv+k9Ryf/F3FjiJc0fcn/m4nhxx/wAL 5pvR5H106/kyG3Nx2ntU0Aj+2/e5Ubc/PyiTkZNts8hzyR/mztVJgR2BV5ZJy+aRP1dCPLYMX83i hD+7EA/4z6H9UuqOzumiq1034sMcTyW/4J//AHxbi89+quacPq1QJivI/RP+f82f89ehLR5bJx4x e8fSXk/ivLjDzMuEVDJ+sj9fmj/jKSSSUzQUuT6lm2ZWa6xji1jPZXBjQfnafvLf6xknHwXlph9n sb8+f+iuYYxVObntAf3j+x0vh2IASykf1I/902KeodQqjbe4gdne4f8ASV6jr+S3S6ttg8W+0/xa s9rFLYq8cuSO0i2cmLDP5oR+g4T/AM16LF6li5WjHbX/ALjtD/5krS5IsI1GhHBWp07q7gRRlGQd GWn8j/8AyStYuZBNT0Pfo0c/JUDLEeIdYn5vo7KSSSstJSSSSSlJJJJKUkkkkpSSSSSlJJJJKf/Q 9VSSSSUpJJJJSkkkklKSSSSUpJJJJSHLyqMPGtysh2ymlpe93kF4913rOT1nqD8u4kM+jTX2Yz81 n/k12H+Mrqrq6Mfpdbo9b9LcB+60xU3+0/c7/ra8+WfzmUmXANo7/wB567/i5yMYYfvUx+sy2Mf9 TEP+/SMR2IDEdiqu5NsMVhirsVhiLVm2KyWkObo5pkHzC9OwskZWHTkD/Csa75ke5eYsXc/VHI9X pfpE60PLY8j+kb/1StcnKpmP7w/6Lg/HMXFhhk645V/gzdxJJJX3nXA+sN27IqoHFbdx+Lv/ADlZ 7ApZ13rZ11kyNxaPg32j8iTFmZZcU5HxdvFDgwwj2GvnL1FKxqIGJmIwiE1ZKRtruagvarT4Vd6C +BdbouebWnFtMvYJYT3b4f2VqrkK7nUXMuZ9Jhn+8Lra3tsY2xurXgOHwKvctk4o8J3j+Tn87hEJ icfln/0urJJJJWGopJJJJSkkkklKSSSSUpJJJJT/AP/R9VSSSSUpJJJJSklC22umt1trgytgLnvd oABqXFeX/WX645fUc9hwbHUYmI8OojQue3/Dv/74xRZc0cYs6k7BvfD/AIbm53IYw9MYi55JfLH9 2P8Aek+ppLH+rP1gp65gC3RmTVDcirwd++3/AIOxbCkjISAkDYLVzYZ4cksWQcM4HhkFJJJIsb5L 9d8o5P1kytfbTtqb/ZaN3/T3rBWn9ZST9YOoT/3Is/6pZix8hucj/WL6NyURDlcERsMcB/zEjEdi rsR2FNZJtlisMVZhR2FFqzDZYup+pd5GRkUdnsa8fFp2/wDf1yrCtz6q3en1ioTAsa5h+7cP+pUu A1kifGv8ZzPiOPj5bKP6pl/iev8A7l7tDvs9Kiy39xpd9wlEVDrdvp9LvMwXANH9ohq0pmoyPYEv K4o8eSEf3pCP2vLsdOp5OpVhhVRjkZrllvQTi22uRN6qtep70mAwSuegvcmL0Nz0l0YMXldJ0O02 dNrnlhLPuK5d7l0f1bM9PP8Axjv++qflT+s+hYfiEf6OD2kHVSSSV9x1JJuNSuD+s/1jty8ptOFY WY+M7c2xpgusb/hP6jPzFHlyxxxs69g2uS5LJzWTgh6QBcpn5Y9nvUlh/Vn6xM6tR6NxDc6ofpG8 B4/0rP8Av63E6ExOIlE2CxZ8GTBkliyDhlH+XFFSSSScxKSSSSU//9L1VJJJJSkklh/W7rv7G6U5 9ZjKyJrxx4GPdb/1pqEpCMTI7BkwYZ5ssMWMXPIeEPMfX76zG+13RsN/6Go/rTx+c8f4H+pX+f8A 8IuKSLi4lziS4mSTySUlk5MhySMi+g8lymPlcEcOP9H5pdZz/SmXQ6J1nJ6N1BmZQZA0tr7PYfpM P/fV7BgZ2N1DEqzMV2+m5u5p7jxa7+U1eHrp/qT9Zf2VmfY8p8YOSdSeK7Do2z+o76Nim5XPwHhl 8sv+aXN+O/DPvOP38Q/X4hqB/lcf7v8Afj+g+opJk60XjHx/630up+sme0/nWbx8HgWf9+WOuu/x k4fpdXpywPbk1AE/yqztP/QdWuRWRmjw5JjxP4vofw3KMvJcvMf5uMT/AHoeiX/Oiu3lHYUBFYUx syGjZYVYYVVYUdhRa0w2mFaPSLhV1LFsPAtZPwJ2/wAVlscrFFmyxj/3XA/cZRiaIPYtTNDihKP7 wMftfVVi/Wm3bgVs7vtH4BxWyCCARwdQuc+uFgAxa51l7o/zQtPmDWKXl+byPIR4uaxjxJ/xY8Ti NciteqjXorXrNeglBtB6l6irB6fekxmCcvQ3PQy9RL0kiDJzl1X1dYW9Lrcfz3Od+Mf99XHOeu86 fR9nwaKYgsY0H4x7v+krPJi5k9h+bS+Knhwwj+9K/wDFH/oTYSSWb17rFfSsI2CDkWS2hh7u/fP8 hiuykIgyOwcjFjnlnHHAXKRoByfrf100MPTcV0W2D9YePzWn/B/1rP8AqFxDyi32vtsdZY4ve8lz nHkk8lV3lZeXIckjI/Qdg9lyPKR5bEMcdTvOX7818fMyMLJrysZ2y6o7mu/K138l35y9S6J1ejq/ T2ZdXtd9G2vux4+kz/yK8leVq/VPrp6R1VosdGJlEV3jsD/g7v7Dv+gn8tm4JUfllv8AxY/i3w77 zgM4D9fiFx/rw/Sx/wDePqiSSS0njlJJJJKf/9P1VJJJJSl5L9dernqfXLWsdOPiTTUO3tP6V/8A asXpvWs37B0nLzO9NTi3+tG1n/TXiZJJkmSeSqfOz0jDvqXo/wDizywM8vMEfJ+rh/el86k6ZOqL 1QUkkkkl9J+oX1k+24w6VlOnJx2/oXE6vrH5v9er/wA9rr14biZV+Hk1ZWO7ZdS4OY7zC9h6F1ij rPTq8yr2uPttr/cePps/8itDlc3FHgl80dvGLx3x/wCG+xl+8Yh+qyn1Af5PL/3uRxv8YnTzk9Eb lNEvw7A4/wBR/wCjf/0vTXmK9yzMWvMxLsW0TXex1bvg4bV4nmYtmJlXYtoiyh7q3fFp2qHnYVIT /eFfUOj/AMWeZ48GTlyfVilxx/2eT/0NCpsKgnGiqvQNhjkdjlUY5HY5JhnFtscih2hVVrkVrkWv KL61hO34dD/3q2H72hcx9c7P13Hb4VE/e7/zFdD0Sz1OkYb/ABpZ/wBSFyn1zt/yuxv7tLfxLytD mD+oHjwvJ/Dcf9PkP3Pc/wC9cxr1MPVVr1MPVB35QbQen3qsHp96SzgTl6iXoO9MXpJEG/0ug5nU aKOWl4c/+q33u/Iu/XLfUzE3G/OcP+Cr/wCrsP8A1C6laHKwrHf7xv6PP/FsvFzHANsQ4f8ADl6p I8i+rGoffc7ZXWC5zj4BebdZ6rb1PNfkv0b9Gpn7rBwP/JrW+uHXPtF37Ox3foaT+mcPznj8z+rV /wBWuXc5Qc1m4jwD5Y7+MnV+Dch7UPfyD9ZkHpH7mP8A76az3IL3J3uQXuVV3YRYvcgPKm9yC4yU GxAPrH1K6sep9Er9R26/F/Q2+J2j9G/+1Wt9eb/4ts01dVvwyfbk1bgP5VZn/qHPXpC1OXnx4ok7 j0n6PC/GeWHL87ljEVCf62Hlk/8AQ+JSSSSmc5//1PVUkkklPOf4wLHM+rN4Bje+tp+G4O/76vKA vWfr7S636sZO0SazW8/APbP5V5MFn85/OD+69f8A8WyPucq392V/4sF06ZJVXdC6SSSS5S3fqj9Y HdF6kPUJ+x5EMyG+H7t3/W/+oWEkjCRjISG4Ys+CGfFPFkFwmOE/x/wX3drmuaHNILXCQRwQV5x/ jG6T9n6hX1KsRXljbZHaxg/7/X/1C1f8X31h+0456Rkum6gTjE8urHNf/Wv/AD3/AFF0H1j6SOr9 IvwwP0pG+k+Fjfcz/O+gtGdZ8Njfcf3h0eN5Yz+F/EhHIfRfBOXSeDJ8uT/u3xpJO5rmOLHAtc0w 4HkEJlmvbsmmEVrkBSa6EkEW2muRmuVRrkVr0mGUH1n6su3dAwT/AMEPwXJfXJ/+XXjwqr/IV1P1 TM/V3BP/AAf/AH5y4/66Pj6w3DwZX/1Kv8x/ueH+D/0Xlfhkf+FOYHb3f/Srmh6kHqqHqYeqLvmD ZD0+9Vt6fekt9tsb0zS572sYNz3kNaPEnQBA3rf+pnTjl9ROW8TTiajwNh+h/mfTT4RM5CI6li5i ccGGeWW0BfnL9GP+E9n0vCbgYFOKOa2+8+Lj7nu/zln/AFo62Ol4Wyo/reRLav5I/Pt/s/m/y1q5 WTTiY9mTe7ZVU0ue7yC8s6t1W7qedZl26bjFbP3WD6DFe5jKMcBGO5FD+rF5/wCF8nLm+Ylmy644 Hjnf+UyS9XB/37Xc+eTJPJQnPUXPQ3PWc9dGC7nILnJOchOcgzRipzlBJJJldv6mWOr+suCWmNz3 NPwcx4Xrq8k+pNLrfrNh7Rowue74NY5etrQ5L+bP954//jPX3vH39oX/AI81JJJK04L/AP/V9VSS SSU1uo4bM7AyMN/F9bq/m4QCvELarKLX02jbZW4se09i07XBe8Lzb/GJ0E4uaOr0N/QZR23x+baB 9L/rrf8ApqrzeO4iY/R38ne/4u82MeafLyNDNrD/AGkP0f8ADi8cnTBOqD1oXSTJ0FykkkkkpsPL vwsqrLx3bLqXB7D5heydG6rR1fp1WdTp6gixn7rx/OVn+qvFV031G6/+zOpfZL3RiZhDXTw2ziuz /vj1Y5XNwT4T8svzcf478P8AvPL+7AfrsAMh/Xx/pw/7qDP6/wDRfsPVfttTYx82XacCwfzrf7f8 4uWXsv1i6QzrHSrsQx6sb6HeFjfof530F45Yx9b3V2AtewlrmnkEaEIc1i4J2Pllr9eqfgPPfeOV EJH9bgqEv60P8nP/ALlikkkoHXZB0IjXoKcGEkEW+v8A1Q1+rWB/xZ/6py4r67uj6yXj+RV/1K7T 6of+JrA/4s/9U5cP9ezH1lv866v+pV7mP9zw/wAH/ovKfCRfxfmh/tv/AEtFyA9SD1WD1IPVF6Qw bO9Leq+9Leit4GwHOcQ1oLnEw0Dkk8BepdA6YOl9LqxiP0pG+4+L3fS/zfoLi/qL0n7d1E51rZow oLfA2n6H/bbf0n+Yuv8ArP1tvRumPvaR9pt/R47T3efz/wCrX9NXOViIRlll9PJ5341llmz4+Rw+ qVgz/wBpL5I/4EPXJ5r69dd9a8dKx3foqSHZBHez82v/AK1/1a5EvQ32ue4ve4uc4kucdSSdSSoF 6q5MhnIyPV3uT5OHLYYYo/oj1S/fn+lJI56G56gXqBJKY2xBk5ygkkkvUkki42PdlZFeNQ0vttcG MaO5KSCQASTQGpJey/xadOLsnJ6k5vtraKaz/Kd77P8ANa1v+evQVQ6H0qrpHTKcGvUsE2P/AHnn Wx6vrWwY+DGI9dz5vn/xPm/vXN5Mo+S+HH/s4emP+N86kkklI0n/1u4v+uXRcbrNvSMqz0Latv6Z 382XOG/YX/4Nzd3563Gua9oewhzXCQ4GQQfBeEdcy3ZnWs7JcZ9S+wj4bi1v/RV3oX1r6x0VwGNb vx/zsayXVn+qP8H/ANbVYczUiJDS9CHcn8E4sUJYZVk4RxQn8spV6uGX6L7WgZuHj52LZiZLBZTc 3a9p/wBfpNWF0H69dH6ttptd9jyzp6Vp9rj/AMFb9F39pdIpxKMxoQQ5GTFm5fIBOMsc4mx9P0oy fHPrJ9W8voOWWPBsxbCfs98aOH7j/wB21qyF7lnYGJ1DFfiZdYtpsEFp/wCqafzXtXlv1n+qOZ0O w3VzfgOPsuHLZ/Mvj6P9dUc/LmHqjrH/AKL1fwn4zHmAMOYiOcaA7RzeX+s/quAnUU6qu4F0kkkl ykkkklPqv1J69+1elim505eJDLJ5c3/BW/8AfXrm/wDGH0P7LmN6rQ2Kco7bgOBaB9L/AK61YH1f 6xb0bqlWY2TXO29g/OrP0x/39q9Zz8PE610t+O4h9GVWCywaxPuqtb/V+kr0D7+EwPzx/lF5XmYn 4V8SjzEB/Rs98UR0Ev52H+B/OY3xRJHzsK/Ay7cPIbttpcWuHw/OH8l30kBUSKNF6mMhICUTcZCw R1BUkkkkl9h+qYj6uYH/ABQP3krg/wDGDp9ZLD41Vn8F6B9WW7fq908f8Aw/eJXBf4xWx9YZ/eor P4vH8Ff5j/c8f8H8nkvgx/4Xz+Pvf+lHmQ4pw9QSVB62km9EortyLq6KWl9trgxjR3c4w1V13P8A i66Dve7rWQ32smvFB8eLbf7P823+2n4sZyTER9fJqc/zUOU5eeaX6IqEf38h+SL2HRumU9H6XViN I/Rt3W2cbnn3W2FeZfWrrx6x1V9jHTi0zXjj+SD7rP8Arrl1/wDjA679iwB02h0ZGYP0hHLavzv+ 3fof9uLzRWObyAVijtHf9gcj4BycpcfP5vVkzGXt32P85k/w/lZF6aSmSVR6JSSSSSlJJIuNjX5V 7MfHrdbdYYYxokkpIJABJNAaklG1rnuDGAuc4w1o1JJ7BemfUv6pnpdf7Qzm/r1ohjD/AIJp/wDR r/z1P6qfUynpIbmZu23PI9o5bVP7n71n/CLqFf5bluGpz+boP3Xk/jPxr3hLluWP6rbJl/zv9SH+ r/6aklV6h1PA6bQb825tLO27knwYwe5/9lcJ1z/GJlZG6jpDDj1HQ5D4Nh/qN+hUp8maGP5jr+6P mcvkvhvM82f1UPR1yy9OOP8Ahfpf4D2nVuv9L6PXuzbg15Etpb7rHf1a/wDvzlW/50Yf/N79u7D6 X+hkbt2/0vTn95eSW3W32Otue6yx5lz3Ekk+bitb9ov/AOaf7PnT7Zuj+Ts3R/24qo508RPD6QNu u/d3Jf8AFnGMUIjKTmlL1ZCPQI8E/THH/f4H/9fjN5c4udqXGT8SptKn1Gk43UcrHIj0rrGR/Vc5 qE0rOkHtMU7APdKCul6D9eOr9J21WO+2Yg09G06tH/BW/Sb/ANQuYBUwUwSlE3E0zzxYs8ODLATi eh/7n919p6J9aekdaaBjW7MiJdj2e14/q/6T+wtayuu2t1djQ9jxDmuEgg9iCvBGPexwexxa5plr gYIPkV2HQf8AGJn4e2jqgOZjjT1Rpa0fH6N39v8Az1ax80DpkFePRw+c+ATjeTlZcYGvtyP6wf3J /pN36zf4v3MLszojS5nL8OdR/wAQT9L/AItcO5rmOLHgtc0w5pEEEdiF7X0zrHTuq0etg3ttb+c0 aOb5WVn3MWf9YPqj03rbTYR9nzI9uQwc/wDHM/wn/VpuXlRIcWOten6J/usnIfHcmCXsc6JVH0+4 R+th/tY/p/8ATfI060es/V/qfRbvTzK/0ZMV3t1rd8HfvfyHLNVKUTE0RRenxZYZYCeOQnCW0omw ukkkgyKXof8Ai66562O/pF7v0lA3488lh+nX/wBbcvPFZ6dn39Ozqc3HMWUODh4EfnMP8l7fapMO Q45iXTaXk0/iXJjm+Wni/T+bGf3ckfl/717v/GH0H18dvWMds20Dbkgd6/zbP+tf9R/UXna9vxMn F6n0+vIrizHyq52nXRwh7Hf9Q9eT/Wfob+i9UfjgH7PZ78Z57sP5s/vV/QU/N4tRkjtLf+Llf8Xu eJjLks2mTDft8W/APnx/3sbkJJJKo9C+2dGZs6RhN8Meof8AQauC/wAZbI6xjv8A3scfg969Dwmb MOhnG2tg+5oXBf4zmRnYL/Gp4+53/mS0eZH6jy4Xi/gc7+KA/v8Au/kZPFJJJLOe0b3RulX9W6jT g06eoZe/91g/nLP7LV6+BhdI6bpFWJh1/c1o/wCqcsP6jdA/ZnTvtd7YzMwBzgeWV811/wBr6b1l /wCMfrcCvo1DuYtyo8P8FV/6M/7bV7FEYMJyS+aX8oxeU57LL4p8QhymI/qMRPFIf1f57L/6jxvH 9X6nd1XqN2dd9K13tb+60aV1j+q1UkklRJJJJ3L1MIRhGMIDhjACMQOkYqSSSSXKSUmMfY8MY0ve 4w1rRJJ8gF2f1e/xfXX7crrM01ctxRo8/wDGu/wf9X+c/qJ+PHLIaiL/ACa3N87g5WHHmmI/ux3n P+5F53on1e6l1q708RkVNMWXu0Y3+1+c7+Q1endB+rXT+h0xQ31Mhwi3Id9I/wAlv+jr/kLSx8fG w6G00MbTRWNGtENAC5rrv1+6dgbqMCM3JGkg/omn+VYP5z/ravQxY8A4pkcXf/vQ8tzPPc78Vyez y8JRw/uR/wClnyPTZGRRjUuvyLG1VMEue8gAfMri+u/4xa2bqOjM9R3BybB7R/xVf53/AFxcd1Xr nU+r2+pnXF4H0axoxv8AUrCoKDLzkjpD0jv+k6fIf8XMWOp80fen/mx/Mx8/84nzM7MzrzfmXOvt P5zzPyb+6gJJKqSTqXejGMQIxAjEaADQBSLud9l2/m+pPzhCWh9kd+wPtke37X6U/wDW96IG6JSA MR3ND/FkX//Qzf8AGH092F9aMl0fo8sNyGH+sNtn/grHrnGlerf4zuhuzuks6lS2bunkl8cmp385 /wBtu9//AG4vJ1SzRqZ8dXpfh+f3OXgb9UBwS/wUzSpgoLSiAqEh1Mc0oKkChgqQKYQ2YybWJmZW He3IxbXU2t4ewwV3XQf8ZDXbcfrTNp4GVWNP+u1D/qq/+2156CpAp0Ms8Z9J+nRi5rkeX5uNZYWf 0Zx9OSPlJ90nB6liaenlYtw8nscFxXX/APF0RuyeiukcnEef/PNrv+os/wC3FyHSeu9T6Pd6uDcW A/TqOrHf1616J0H6+9M6ltozIwso6AOP6Nx/kWH6P9WxWRkxZhwzHDL+XyycOXJfEPhkjl5WRzYd 5Rq9P9bh/wDUmN8yvovxrXU5FbqrWGHMeCCD8CoL2jq3Qul9Zp9PNqDyB7LW6Pb/AFLF57136h9T 6buvxJzcUaywfpGj+XV+d/1tQZeVnDUeqPhu6nIfHeX5ioZP1GX92R/Vy/uT/wC+eZSS1Bg6EJKu 7D3X+LjrW19nR7naOm3Gnx/wtY/8+f8Abi6X61dCb1rpb6mgfaqZfjO/lD/B/wBW36K8mw8u7Dyq sqg7baXh7D5gr2jpmfT1LAozqfoXsDo8Dw9n9h/tV/lpDJjOKWtf9H/0F5T45gnynN4+ew+njNn+ rnj/AOrYf+pHxN7H1vcx4LXtJa5p0II5BUsdm/IqZ+89o+8rsv8AGF9XvSt/bOK39HaQ3KaOz+G3 f9c+i/8Alrlui1et1jCq/fvrB/zmqpPGYZOA99HoOW52HMcp94hp6SZx/cnAeuL7UBAjwXD/AOM+ v9F0+zwda37xWf4LuVx/+Myrd0nGt/cvj/Oa7/yC0OZF4Z+Tx3wWXD8RwHvKUf8AGhKL5uul+o/1 f/anUftV7Zw8Qhzp4e/mur/v9iwsDByOoZlWHjN3W3ODWjsPFzv5LW+5ex9I6XR0rp9WDQPbWPc7 u55+nY7+s5U+Vw8cuI/LH8S9J8d+I/dsHtYz+uzCh3x4/wBKf/cwSdSz6enYN2bd/N0MLiPE/msH 9d3tXi+bmXZ2Xdl3ndbe4vcfj2H9Vdj/AIx+tb7auj0u9tcW5Ed3Efomf2W+9cOjzeXinwDaP/SW f8XuS9nlznmP1mfUf1cI+X/H+dSSSudN6T1Dql/oYNLrXfnEaNaPF7z7WKsASaAsu1OcYRMpyEYx 1MpHhiPq01s9D+qvVOtODqWeljT7smwQ3+x/pXf1V2HQv8X2Fh7b+qEZd41FQ/mmnz/Ot/texdF1 DqnTekYwty7W0VgQxg5Mfm1Vt+krePlNOLKeEdv4lwOc/wCMFy9nkYHNkl6Rkq43/q8f6bT6F9Ve l9FaHUs9bKiHZNgl3/W/9E3+qm659a+ldGBZa/1srtj16u/64fo1f2lx3Xv8YGfnbqOmg4eOdDZP 6Vw/rD+a/sf565MkuJc4yTqSeSU6fNRgOHCB59GLlvgWfmJ+/wDEMkiZa+3dz/w5/wCTj/Uxu11z 629V6yTW9/oYp4x6yQCP+Fd9K1YiSSpylKRuRsvRYcGLDAY8UBjgP0YqSSSQZFJJJkkKXoP7Df8A +N36e0+tt+2xGvO//wBt1x/1f6TZ1fq1GE0exx3XO8K262H/AL6vZfSr9L0to9Pbs2dtsbdqmhD9 Vkn5RH+NFzeZ5off+T5YHUnJln5DDljD/u3/0fU3sZYx1djQ5jwWuadQQdHNK8U+uP1Zt6B1RzGN Jwcgl+LZzp3pcf36l7aqHWujYXWsCzBzWzW/Vrx9Jjh9Gys/vNTMmPjHiNm1yXNnl8lnWEtJj/un wMFTaVpfWL6t9Q6BmHHym7qnE+hkNHsePL91/wC/WsoGFSlEg0XpcWWMgJRPFE7EJgVMFBaUQFMI bcJpQU4KGCpAphDYjJICnUAVIFNplEnougfXTqvSC2p7vtWGNPRsOrR/wNn0mf8AUL0bov1k6X1q ucS2LgJfjv0sb/Z/Pb/LYvGJU6brabG20vdXYwy17SQQfJwU2LmZw0Pqj2P7HN574Ny/NXOI9nMf 04j0y/2kH1vrf1P6R1jdY5n2fKP/AGoqABJ/4Rn0bF5/1v6odY6PNj6/Xxh/h6pIA/4Rv0q1ufV/ /GLZXtxutD1GcDKYPcP+OrH0/wCuxd3jZONmUNvxrG3UvGj2EEFWDDDnFx9Mvx/wouRHmviXwqQx 5h7uDaPF6sZH+qy/of3P+Y+GruP8W/WdtlvR7ne18248/vD+dZ/ab71t9b+ovSOpbrccfYsk676x 7Cf5dP0f8zYuJyuhde+rOdVmmovZjvD2ZFfurMH8/wDOr3f8IoBjyYJidXEbmP7rqS53k/inLT5c S9vNIXCGT0y92PycEv031bIx6cqizHvaH1WtLHtPBBXm2D0C/pX12xMJ8urFvq0WH86todY0/wBZ uza9ej4OXVnYdOZT/N3sD2/McIjqaX2MtcxrrK59N5ALm7vpbHfm7lcyYo5OGX7pEgf6rznJ89l5 MZ8RBMcsJ45QP6GWuCM/8H9Jmua/xhVGz6uPd/ora3n7/T/9GLpVC6mm+s1XMbZW76THgOBjX6Lk +ceKEo9xTX5XP7HMYs1cXtzjOv3hHo8r9Q/q59gxP2llMjKym/o2kasqOv8An2/SXSdSz6enYN+b cfZQwujxP5rP7bvarK4j/GDnZOTbj9CwmPtsfF1zGAuJ/Nqb7f7T1HKsOL09NB/WkW3i9z4lz4OU 0Jniya+nFgx7x/xfS8JmZV2ZlW5V53W3PL3nzJSxMPKzLhRi1Outdwxgkrr+i/4uci3bd1ez0Gc/ Z6yC8/17PoV/2d67jp/S+n9Mp9HBobSzvA9x83vPveqmPlJz1n6Qf8Z6DnPj/K8uPb5cDNOI4Rw6 YIV/X/S/wHjuif4uD7b+s2eYxqj/AOfbf/Sf/bi7SmjB6bi7KWV4uNUJMQ1oH7znf+SWX1763dL6 M01ud9oy+2PWRIP/AArv8F/1a84639Zeqdaf+tWbaAZZjs0YPl+e7+U9TGeHAKgOKf8AL5pObj5X 4j8VkMmeZxcvuLHDD/qOH9L/AGk3revf4xKad2P0Zous4OS8ewf8Wz/Cf2vYuEzM3LzrzkZdrrrX cueZ+Q/dQElUyZp5D6jp26PRcl8O5blI1ih6j82SXqyS/wAJSSSSjbikkkkkKSTJJKtSQBJAAknQ AJAEkACSdAAvQfqX9THY7mdU6oyLh7sfHd+Z/wALaP8ASfuM/MUmLFLJKh9T2afPc9i5TEcmQ6/o Q/SyS7B1PqT9XD0fAN+S2M7KANgPLGfmU/8AfrF0iSS0vaj7ft/o1TxP3/P97+93+t4uL+rXy+3/ AHOD0P8A/9L1VJJJJTW6h07C6livxM6pt9D+WO8f3mn8x7f3mrzT6xf4ss/Ec7I6MTmY/PoOgXNH 8nht3/nxeqJJk8cZb/a2OX5vLgPoPp6wPyl+d7arsew1XsdVY3RzHgtcPi1yQcvfc/pPTOpM9PPx q8hvbe0Ej+q/6bVzmZ/ix+rd5LqPWxHHgVv3NH9m4Wf9UoJcvLoQXWw/GcX+UjKB8PXF8oBUwV6I 7/FNhz7Oo2AedbT/AN+akP8AFPj/APlk/wD7aH/pRRnl8nb8W7H4zyfXIf8AFn/3r56CpAr0H/xq aP8Ayyf/ANtD/wBKp/8Axqsf/wAsX/8AbQ/9KJv3bL+7+IZR8b5H/On/ABMn/evnwKeV6D/41eP/ AOWL/wDtof8ApROP8VmP/wCWL/8Atof+lEPuuX938QyD47yH+dP+Jk/718+laPR+vdS6Nf6uFaWg /Tqdqx39dn/fl2H/AI1uN/5YP/7bH/k0/wD412L/AOWFn/bY/wDJpDlswNgUfNE/jXwzJEwyT44S 0MZY5kf9F2Pq99c+m9ZDabCMXNP+BedHH/gX/nf1PproCA4EESDoQVxA/wAV+KDI6hZI4IrH/k11 3TcOzCwasW29+U+oR61n0nCdN39X6KuYjlqskf8ACeb5+HIiXHyeUkE64pRmODxjOf6LYaxrGhjA GtboGgQAFJJJStBSSSSSlKOxm/ftG8iN0ax4SpJJKQZmbiYNDsnLtbTSzlzjHyH7zl599Yf8YOVl 7sbpM42OdDef5139T/Qt/wDBF0fXvqaOt5pyb8+1jAAK6NocxkCHbNW/SWb/AONhif8Ac+z/ALbb /wCSVbN78rjAcMe9+qTt/DT8JwiOXmchy5t+A45+1iP+L+sk+fOcXEucSSdSTySkvQf/ABsMT/uf Z/223/ySX/jYYn/c+z/ttv8A5JVfuub938Q7v+n/AId/nT/4Xk/718+SXoP/AI2GJ/3Ps/zG/wDk kv8Axr8T/ufZ/wBtt/8AJJfdc37v4hX+n/h3+dP+Jk/7189SXoX/AI1+J/3Ps/7bb/5JL/xr8T/u fZ/mN/8AJJfdc37v4hX+n/h/+dP+Jk/7189SXoX/AI1+H/3Ot/zG/wB6NT/iy6Sx03ZN9o/dG1v/ AH1yP3TL2H2rT/xg+HgaZJHwEJvmy0+k/VzrHV3gYmO70zze/wBtY/tu+l/YXp2B9UPq9gEOqw2P ePz7ZsP/AIJLf+itgAAQBAHAClhyX78vpH+Ln8z/AMZhRHL4jf7+X/1XD/v3nPq79Sen9HLci4jK zRqLHD2sP/As/wDRjl0iSStxhGAqIoPPZ+Yy8xM5M0zOR6n8oj9FSSSScxP/0/VUkkklKWR1360d M6Aah1D1Wi8H03MYXNJb9Ju797Va6y/rJ0LH690q3Bthrz7qLf3LB9B//fX/AMhCV0a3ZMXt+5H3 L4L9XDu4jv8AGj9WBwMh3wrH8Xobv8av1dHFOS7+wz/0qvLc3CycDLtw8phrvocWWNPiP++u/NQF VOefg7Y+F8qQCOIg/wBZ9Ud/jZ6IPo4mS74hg/8ARiEf8bXT/wA3p9x+L2j/AMkvMEkvfn3/AAXj 4Xyo3iT/AIUn0w/42sf83prz8bQP/Ragf8bB/N6b99v/AKiXnAcphyac2T978AzQ+Gcl/mr/AMKf /fPfu/xrZh+hgVD42OP/AH1qif8AGn1M8YdA+Jef+/LhA5SBTDmy/vNiPwzkf8yPtn/3z2zv8aHW j9HGxh8nn/0Ygu/xlfWF30W47Pgwn/qrCuRBJMDUngLsvq1/i+zM7ZldV3YuKYLaeLXjz/0LP636 RKM80zUZFGbl/hnLQ48uLHEdARxSl4Ri2ekfWj67dbyPQwRVA/nLTWAxg/lvO7/NXolYsFbRYQ6w AbyBALo9xaELCwcTAx242HU2mlnDGiPmf3nI6uY4SiPVIyJ7vN87zOLNMezhhgxx+URHrl45JKSS SUjUUkkkkpSSSSSnB+tF/wBZsWpuT0UV2VVtPr1Fu6z+uwfnN/ktXGD/ABi/WJphwoJHINZ/g8L1 Fc39Y/qV0/rAdkURi5x19Vo9rz/wzB/58+moM2PIfVjmR/Vv/out8N5zkogYub5eEo9M/Dcx/tf3 v7zzDf8AGZ1ofSoxnf2Xj/0Ypj/Gd1TviUH4bx/35cz1XpHUek5HoZ1Jrd+a7ljh+9W/6LlSlUzm zA0ZEHxejj8M+G5IiccOOUZaiUSeE/4sntx/jQzvzsGo/B7h/eit/wAaNn5/Tx8rT/6TXBylKX3j N+9+AQfg3w4/5AfSWT/v30Bv+NKr87pzvlaP/SamP8aOH+dgWD4Paf8AvoXncpSj95zfvfgFh+B/ D/8ANEf4eT/vn0lv+M/pR+niXj4bD/39qI3/ABmdCPNOQP7LP/Si8xlKU771l7j7GM/AuQ6RkP8A DL6kP8ZP1ePLcgf2B/5NEZ/jF+rbiAHXSdAPTJJP9kleUSuz/wAXv1ZOXkDrGWz9Wx3fq7T+fYPz /wCpT/58T8efLOQiK+xqc38J+H8vhllmcgEdhx/PL9GI9L6Sx25odBbuAMHQifFSSSV15lSSSSSn /9T1VJJJJSkkkklPK/Xf6m19dx/teIAzqdLYaeBa0f4Gw/vf6J68hvoux7n0XsdVdWS19bhDgR2c F9ELnvrR9TOm/WBnqu/V85ohmS0cx9Flzf8ACM/6ahy4uLWO/wCbpcj8Q9qseXXH+jLrD/0F8USW x1v6p9b6I8/a6C6gH25NcurI/rf4P/rix1WIINEU7cJxnEShISB6hScFMrnTekdT6pd6PT8Z+Q/u Wj2j+vYfYz+0hVrjIRFkiIHUtYOWr0T6v9V63d6eDSXMBh97tK2f17P++N967P6v/wCK2motyOuW es8a/ZaiQz/rtujn/wDW13mPjY+LS2jGrbTTWIZWwBrQPgFNDlydZaDt1c/mPjMYAxwjjl++fkH/ AHzz/wBXPqN0zoobfaBl5w19Z49rT/wNf5v9f6a6VJJWYxERQFOJmzZM0zPJIzke/wCxSSSSLGpJ JJJSkkkklKSSSSUpJJJJTXzun4fUMd2NmVNuqdy1w4P7zT9Jjv6q88+sP+LzMxN2T0kuysfk0H+d aP5P+m/8+L0tJR5MMMg1Gvfq3OT+IcxykrxyuB+bHLXHL/vXwNwcxxa4FrmmCDoQU0r2Prv1S6R1 sF99fpZMaZNUB/8Ab/Nt/trzzrf1F630susrZ9txh/haQS4D/hKfpt/6apZOWnDUeodw9Nyfxnl+ YAjI+1k/cmdP8Cbz0pSokwYOhHITSoqdAzZSmlPTVdkWCqit1tjtGsYC5x/stXa/V3/FvlXubk9b Jop5GM0/pHf8Y4fzTf8AwT+onwxSmaAa3M87h5ePFlmB2j+nL+7Fyfqn9VMnr2SLLA6vp1R/TXcb o/wNX8v/AM9r1zHx6cWhmPjsFdNTQ1jG6AAJsbGoxaGY+NW2qmsbWVtEABFV/FiGMdydy8nz/P5O byWfTjj8kP8Aupf11JJJKRpKSSSSU//V9VSSSSUpJJJJSkkkklLEAggiQeQVlZf1U+rmY4vyOnUO e7lzW7Cf7VWxaySBAO4tdGcom4yMf7p4XDo+pP1VoMs6dU4/y9z/AMLHPWxTRTRWK6K21VjhjAGg f2WoiSQAGwATPJOfzylL+8eJSSSSKxSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKc /O+r/Reou3ZmHVa/98th3/bjNr1Rr+o31WrduGA1x8HOe4f5rnreSTTCJ1MR9jLHmc8RwxyzjHsJ yAa2H07AwWbMPHrx2+FbQ379qspJJ1UxmRkbJJJ6lSSSSSFJJJJKUkkkkp//1vVUl447/Hb1wOI/ Z+LoY5s/8mu7+oH1ry/rT0u/Ny6a6H03mprat0EBrH7jvLv30lPUJJJJKUkuI/xg/XzP+qmVh04m NTkNymPe427pBaWt9uxzf3lh/V3/ABt9X6t1zC6bbhY9deXc2p72l+4B3du5ySn1NJCyrTTjW3NE mtjngHgloLl5D/493XP/ACvxfvs/8mkp9jSXPfUb6yZP1l6GOp5VTKLDa+vZXO2GbdfeXfvLoUlK SSXmn1v/AMaXVegfWHK6Vj4ePbVj7Ntjy/cd9bLTu2uDfz0lPpaS8/8AqJ/jH6l9Z+sv6dlYtFFb aHW76y/dLXMbt97nfvr0BJSkklyH+MD69O+qlWLXi1V5GZlEu9OwmG1N0Lzsj6T/AGs/tpKevSXj n/j3dc/8r8X77P8Aya9J+qP1ir+snQqOptaGWulmRU3UMsb9Nuv/AG4z+Q9JTtJJLyrr3+Nj6w9G 6xl9MtwMUuxbHMDv0g3N5qs+n+fXtekp9VSXA/UL/GTk/WbqtvTc7Hqxnio20Gou9xaR6jD6jnfm u3rvklKSSXmX1r/xs5/Ruv5fTMHEovpxXBnqWF+4v2tNo9jmt9jzsSU+mpLx1n+O7rO9u/p+Nskb oNkx+dt969ex768iivIqO6u5jbGHxa4bmpKSJJLC+un1kP1a6Db1JjG2372V0VPJDXOce+33e2sP ekp3Ul45/wCPd1z/AMr8X77P/Jr1fo+RmZXSsTKzq205V9TbLamTtaXDfs90u9spKbiSzutdf6R0 LG+09UyW47DOxp1e8j82qpvvs/srgepf47sRjnM6Z059wB9tl7xWD/1qsW/+fElPp6S8cP8Aju61 Pt6djAeZsP8A35L/AMe7rn/lfi/fZ/5NJT7GkvKeif43+sdS6xhdPswcZleXfXS97S+QHuDC5su8 16skpSS8jz/8c3WsXOycZuBjObRa+tribJIY4sk+/wAkD/x7uuf+V+L99n/k0lP/1/K3/Td8SvZv 8Sn/AIncz/w2f/PdS8Zf9N3xK9W/xSdf6J0zoWVT1DOoxbX5Rc1lrw0luysbod8ElPqaSxf+ef1T /wDLfE/7db/el/zz+qf/AJb4n/brf70lPnf+PD/lDpX/ABNv/VMXIfUX/wAWHSP/AAyz8q6T/HB1 fpfVM7pr+nZVWW2uqwWGlweGkubG7aub+ov/AIsOkf8Ahln5UlP0L1D/AJPyf+Js/wCpcvl1fUXU P+T8n/ibP+pcvl1JT7n/AInv/Ec3/wAM2/8AfF264j/E9/4jm/8Ahm3/AL4u3SUpfP8A/jR/8XHU f+s/+eal9AL5/wD8aP8A4uOo/wDWf/PNSSnS/wATP/irt/8ACln/AFdS9uXiP+Jn/wAVdv8A4Us/ 6upe3JKWc5rWlziA1okk8ABfOX116+frB9Y8rPaSccO9LFHhUz2s/wC3P53/AK4vW/8AGp9Yf2R9 Wn41LtuV1MmiuDqK4/WbP8z9F/11eJ9J6bf1XqeL07H/AJ3KsbW0+G4+5/8AYb70lLZXTMzExcTL vr2U57HWY7v3mscan/8ASau2/wAT31h+wdas6Pe6MfqQ/RTwL2CWf9u172f9tLsf8Yv1ToyPqWyr Crh/RGB+OANfSY3Zez/tpvq/9aXiWNkXYuRVk0OLLqXtsreOQ5p3Nd/nJKfqZeP/AOOnovo9SxOt Vj2ZbPQuP/CV61n+3U7/AMCXpv1b6zV13omJ1SqB9oYDY0fm2D2XM/s2Ncs//GB0X9s/VXNx2t3X Ut+0UeO+r3wP+Mr9Sv8AtpKfDfqt1Y9G+sOD1GYZTa31fOt36O4f9tPcvpQEOAc0yDqCOCF8rL6H /wAX3V/2v9U8G9xm2ln2a7+tV+j/AOnX6diSndy8mvExLsq3SvHrda/+qwF7v+pXzDnZdmbm35lp mzIsfa8+byXn8q93/wAaPVP2f9T8prTFmaW4rPg87rf/AAFli8K6bhWZ/UMbBqE2ZNrKm/F7gz+K Smuve/8AFb1cdS+qONW4zbgE4rx3hnup/wDAXsXmP+M/odfR/rQ8UM9PFyqmXUtAgCB6NjR/1yrd /bWx/iW6v9n6zldJe6GZtXqVgnT1KvD+tU9//baSn2VeS/47erB+TgdHYdKmuybR5u/RU/8ARbav Wl84/Xbq37Y+tHUM0O3Veqa6TyPTq/Q1x/W2b0lMPqd0c9a+suBgEbqn2h93f9HX+ltn+s1mxfQn WOqY3R+l5PUsnSnFrLy0aEkfQrb/ACrH+xq8z/xJ9H3W53WrG6MAxaD5mLb/APo+itb/AB09QdR9 X8XBYY+2ZEv82VN37f8Atx9SSnynr/Xuodf6lb1HPeXWWH2M/NrZ+ZVU381jVf8Aqp9R+s/Wixxw w2nFqO23KtkMB/cZt91tn8lc+vfPqr1v6pdI+ruBgN6piMdXS02g2sB9R49S4u1+l6jnJKear/xG 1bR6vV3bu+2gR/0rlL/xjcb/AMt3/wDbA/8ASy7n/nh9Vf8Ay2xP+3mf+SS/54fVX/y2xP8At5n/ AJJJTyPSf8TuP0zqmJ1FvVH2HEuZcKzSBu2OD9m71Xbd0L0ZZVH1q+reRcyijqeLZda4Mrrba0uc 46Na1oP5y1UlPzD1r/lnP/8ADN3/AFblTVzrX/LOf/4Zu/6typpKf//Q8rf9N3xKNj9Pz8phfjY1 t7AYLq2OeAfCWAoL/pu+JXs3+JT/AMTuZ/4bP/nupJT5J+xesf8AcDJ/7Zf/AORS/YvWP+4GT/2y /wD8ivp5JJT8tZGHl4paMmiygu1aLGOZIH7u8NWx9Rf/ABYdI/8ADLPyrr/8eH/KHSv+Jt/6pi5D 6i/+LDpH/hln5UlP0L1D/k/J/wCJs/6ly+XV9SZdZsxLqxy+tzfvBC+W3AtJadCDBSU+5/4nv/Ec 3/wzb/3xduuA/wATGXVb9WL8UEerj5Li9vcNsaxzHf2tr136SlL5/wD8aP8A4uOo/wDWf/PNS+gF 87/4w8uvM+ufVLajuY20VSPGpjKH/wDTrSU7X+Jn/wAVdv8A4Us/6upe3Lxb/ErQ5/1kyrvzasRw Pxc+qP8AqV6J/jB+sX7A+rWRfW7bl5H6vi+O9491g/4mvfYkp8j/AMZH1i/bv1luNTt2Hhfq+NHB 2n9LaP8Ajbf/AAP01s/4n8DBHU8jrOddVUMRvpYwte1pNlg/SWNDz+ZV7f8Arq89S2nwKSn6df1b oz2lj83Gc1wIcDayCDyPpL52+tHSqukddy8GixtuOx5dj2McHA1v99XuZ+c1rtj1l7T4FKD4JKfT f8TH1iNWVkfV+93syJvxZ7PaP07B/XrG/wD60vXCARB4Xy/0zqGR0zqGP1DGO27FsbYzz2n6J/kv +ivpbpXUcfqvTcbqOMZpyq22M8pGrD/KY72OSU/Pf106KeifWXOwA3bSLDZj/wDFWfpKv8zd6a7T /En1jZlZ3RbHaXNGTSD+8z9HdH9Zjq/+21Z/x2dF3VYPW626sJxchw8DNuOT/a9ZcB9Turno31lw M+dtbLQy7/i7P0Vv/Qekp7T/AB29U35vT+ksOlLHZFo/lWH065/sVv8A89Yv+Kbpf2/63VXubNeB W/IdPG7+aq/6du/+wsv6+9UHVfrZ1HJa4Pqbb6NThwWVfoWlv9bZvXoX+JPpnpdKzupuHuybhSw/ yKhuMf8AXLv+gkpn/jp6T6/RcXqjGy/Ct9Ox3f07dP8Az8yv/PXln1c6q7o/XcHqQ4xrmuf5sJ2X D/tpz19D/WPpber9CzumkScilzWeTwN1R/7daxfND2OY4seNrmkhwPIISU/SH1s6wzpX1YzupMcN zaT6B8X2fo6P+m9q+bl3P1m+tv7Q+oHQ+miycguc3LE6xi/oaN//ABrbGWf2FgfU3o5619ZcDAI3 VOtD7v8Ai6/0tv8AnNZsSU+4/UTo/wCxvqtgYjhFr6/Wv/r2/pXf5m701xf+PGfT6R+7N/3xSvUg ABA4Xn/+Ofpr8j6vY2cwScG/3+TLR6Zd/wButpSU+LK43ovWHAObg5JaRIIpeQQf7Kpr6R+p/VaO rfVrp+XS4O/QsrtEyW2VgV2sd/aakp+e/wBidZ/7gZP/AGzZ/wCQS/YnWf8AuBk/9s2f+QX06kkp +d/qp0jq1X1n6VZZhZDGMy6S5zqngAB7fc5xavohJJJT8w9a/wCWc/8A8M3f9W5U1c61/wAs5/8A 4Zu/6typpKf/0fK3/Td8SvZv8Sn/AIncz/w2f/PdS8qd/wA3txn7ZMn/AES9b/xPfYv2Dl/Y/V9P 7UZ9bbM+nV9H0/zUlPepJJJKfIf8eH/KHSv+Jt/6pi5D6i/+LDpH/hln5V3P+OX9m/b+m/bfXn0r Nno7Ijc36XqLlPqX+xP+dfSvQ+1er9pZs3+ntmfztvuSU+/r5++v/wBUcz6vdZutFZd03KsdZi3g S0bjvNDz+bZV/wBNi+gVU6r+y/2fd+1/R+wbf0/2jb6cfyvU9qSn52+rf1n6r9Ws77Z0549423Uv E12N/dsaC3+y9q9Ao/x4s2D7R0g7+5ru0+59S5j60f8Ajbeu/wDYv23fJn0o9D+x9q/TrkrPT3n0 t2ztuifwSU+ida/xz9Vy8d9HS8RmAXgtN7n+rYAf9F7a2Mf/ACvevOvfY/u+x5+JJP8A1TnK1g/s neP2h9o2d/Q2T/4KvWP8X3/jaevX+yp/aumz7f8Az0/8B/2n3f8AEfpElN7/ABVfVPJ6F0u7Oz2G rN6gWn0nfSZU2fTa/wDdse5+97Vw3+Nr6xftT6w/s+l04vSwatODc6DkO/sw2n/ra9tyvW+zXeh/ PbHelx9KDs+l7fpL5uyP2J69n2j7b6+93q7vT3b59+7+VuSU7H+LLoI6z9aaDa3djYI+1XA6glhH os/tXFn9he9fZ6P9Gz/NC8+/xN/sX7B1H7B6n2n1Wev623ds2n0Nvp/mbvWXoqSkf2ej/Rs/zQqn Vej4XVOm5PT7q2ivJrdWXACQSPa9v8pjver6SSn5czsO/Azb8LIbtuxrHVWD+U07SvU/8TH1i9TH yPq/e73UzkYs92OP6esf1LP0n/XFz/8AjM/5uf8AO7Kn1/X21/afR2bPU2j9/wDO9P096p/Ub7D/ AM6+nfsr7X9q9UfS9Pb6cH7R6kf4P0PUSU+zfWro7et/V/N6aRL7qiafKxv6Sk/9uNavmxzXMcWO Ba5phwOhBC+qV89/Wv8A5s/85Opel9q2/abJ9P09m7d+l9Pd7tnq79qSnmV9H/Urpf7K+q3TsMt2 2CkWWjvvt/T2f9KxeD4P/Nn7bj+t9r9L1Wepu9ONu4bt0fm7V9JN27Rt+jGkeCSl188/4w+k/sr6 3Z9LWhtV7/tNQHG239IY/q2eoxfQy8o/xyfsT9p9P+1+t9q9B8+js/m936Pf6n8v1UlPli9S/wAS fR5sz+tWN0aBi0EjuYtvj/wFeff9j3/dz/wJe3/4sv2b/wA0MT9nbvT3Wer6kb/U3u3+ps9v0dn/ AFtJT1SrdS6fjdTwL+n5bd+PksNdg7w4ct/lN+k1WUklPzh9avqp1L6s9QdjZbC7HcScbKA9ljfj +bZ/pK0P6v8A1r659XLXP6XkGtlmtlLhvrcR3dW787+Wz3r6E63+xf2bb+3PR+wR+k+0Rs8vpfn/ ALmz3rxT6w/+Nj67v2V+0Jkz6O30f7H2v9Okp0Wf46vrK1oD8XDef3ttg/8ARyf/AMev6x/9w8P/ ADbP/Sy44/8AN2dPtkf9aS/7Hv8Au5/4Ekp7/oX+N3r3Uus4PT7sTFbVlX10vc0Wbg17gxxbNrvd qvWl89fVX9h/85ulej9r9X7XTs3entne2N0fmr6FSU/MPWv+Wc//AMM3f9W5U1udX/YH7Wzd/wBr 3/aLd0enE73TCqf9j3/dz/wJJT//2VBLAwQUAAYACAAAACEAD1EEizsEAADWCQAAEQAAAHdvcmQv c2V0dGluZ3MueG1snFZdc9o4FH3fmf0PjJ+XYMBA1xPSISE02Um6mTrZfb62BNZGljySjEN+/V5J Vh1S2un0Cfnce490P3TE+ceXig/2VGkmxTIan8XRgIpCEiZ2y+jpcTP8EA20AUGAS0GX0YHq6OPF 77+dt6mmxqCbHiCF0KlcRo0SqS5KWoEeVqxQUsutGRaySuV2ywra/URdhFpGpTF1Ohp1QWeypgLZ tlJVYPSZVLuRj1zLoqmoMKNJHM9HinIweGBdsloHtupX2XCrMpDsf5TEvuLBrx3HP/Ls0m2lIl8j fuZ4NqBWsqBaY2Ur7tOtgIlAo/nP8Ph63rFcgTq8IbnAtr1KWQ3atKaqwIJiz6dxNLKGHDfHQVjL z9JkjVKyEeSGAmLfNW+kNJ0Zjy23mQFDkVzXlHM3QgWngIdv052CqgJsuUccpTYHTh9A0I1r+IZx ZEPfPWCW00089gcjdAsNN4+QZ0bWwZ5MunMTBS3u9Ukx8g9VhhXAsxoKhILreDbvmJiuORxupGKv Uhjg6z72Gm/BIUQEau8faL/nPfHsRQkKCkyh2/4Kt1CSB068B7XCzj40ojCNG2AfVxKVlVDTtc9T X5zLVFugS1wP9il9wVZRwgxex5qRCl6wc/EkcVuP2vRbjjbdYncENuhB2faGLzwOI8to2BX3HewS R74A+1gqSE/UfbzjOUYDzVGgLQAYexaN/bFNf7rzowUcREEzbBmnlwdD17LJ/epfRkzpnIidyzsK e3oJxbPmoMuV1SRnbPijAub67gHnff1So3JlJduaL9SgOjlfIP812twxQW8o25XmVuBk8Y5H0831 HRxkY9AX69CfGSWSYGva1C6+YGlDX+N4NU1mqyvfTGvtLfEq/nP+4ZRlPJ7PZtNTlkmyuL5KTlmS ZDG9PGmZryfzcTe0xydYLObXq5MnWKzjy9OWPh+sQJd3lVqdtOPgVxsc7kHlr+oVVLliMLi3Sop1 q9JcPV8yEew5RUWnby1ZkwfjcOgNugLON3iBggFF1FsI3kK8G46Y34Pa9cwu5SpVJ1G8Pn99ZbNi R9UnVLXas7YK6ltBEA4bjpOk42MC56MKuG7yLEQJFNQ3pkaQv/fKEo76ArWpwTcQ5xtZoFchKoZP mZVCCtqsNINl9FoOrz7baBw0rjL7dNJ7qGuvXfluvIy4HdGxDTP4RUA9u498N+lsE2fDL2tzH1DY ZNG7W1gHv0SvbtFj04BNeywJWNJjs4DNemwesLnFygM+Kij7z/hEhaXFt5Jz2VJyE8Bl9A3ki+Bu 7a0oeEMojgiRhb4V9lHRrkZOFH9ZJTtRRf3H230kqVZwrabWR+iAgMEeOYWVqaI7OzvGSsWRmw3G cuPbIWiLohwNJEd9dZM0Oo7DKTk6hFOYd0m1KaEFw7uQHaq8fzzOfIE40yajNb4zRiosrXsp/3Dz 1/8hu/gfAAD//wMAUEsDBBQABgAIAAAAIQAEPt4EyQsAAAZHAAAPAAAAd29yZC9zdHlsZXMueG1s 7Fxfb9zGEX8v0O9A3Luj+6M/lhE5kGQ7FuAoiiW3jwWP3NMx4pFXkmfZfupT0iAJgraA0SJ9sJu0 cIHWLymQ1FHbL2Od7ad8hc7OLpd7HHKPezonBRo/WD4e57e7M/Obmd0d+c237o1C5y5L0iCOtlqd N9oth0Ve7AfR8VbrztGNS5dbTpq5ke+GccS2WvdZ2nrr6k9/8ubplTS7H7LUAYAovZJstYZZNr6y spJ6QzZy0zfiMYvgu0GcjNwMPibHK/FgEHjsWuxNRizKVrrt9vpKwkI3g8HTYTBOWxLttAnaaZz4 4yT2WJrCbEehwBu5QdS6CtPzY+8aG7iTMEv5x+QgkR/lJ/xxI46y1Dm94qZeEGy1joIRrGifnTq3 45EbteAb5qbZdhq4W63zpx8//9fv+LPhdpRWv+2lFGSFjxS60TFI3nXDrRaLLt05nMV+MLy0u88f 9QMfkN3k0uF2CwRXcOL5T20BY7Uc8VZptaBT0PChsBDogg1uxd4J8w8z+GKrBVbGh3f2DpIgToLs fvHskI2Cm4HvM/AH9V40DHz28yGL7qTML56/dwOtKx948STKtlrd9Q00QJj61+95bMytC8NF7ghG 3ucCIR/+l7lshy8UNFT1+pC53BWdjrVE11qiZy2xyiVSTV84zUlJWfZzX3tNuOuvCXfjNeFC7Hkt +t1cMq7nopMvGfUoyELGMRsx5XDSz+wEsiSOjhvjXx+Nh24aQIhuOKGD0PXYMA59ljhH7F5WrZ2g CECbm4ZAsB87h2PXg1jAcSaaWHN63QqOh5lzOMSQUoZZbxtGF5K3ghRXoY++bopeQuztJPDJaF3D aO8wP5iM8omK2DczZq+5MIbBGeHV+cJ8oRXDrjWUpGOuz5fkWqoYc6OhJB3zckNJDPszGjL54TU3 OXGqHGHD5D+7cRgng0mY27TsDhsmL1LClcOaHElJVrnghsmLZqjibHseVBMV1jGtueBMvbxp2QV5 6uVNiy+zqB7FpIgSSrcepTGv6iFMBLvN7ga8SOeuQ0sOLR4awygy+8BN3OPEHQ/LbtjDgqZRunlv EmeYnHTmdDGxNpLfi6BATZlTidPDurMRjrQPrstgnMYBqN44jSNRPUTjkFQP0Sg21YpbBal6FBNt VcxBk9RFjg0TcxUE5oRaCBNtK+MXzRF28YvKmxRB4xeVN2mhFHk6uTkoikkRJRRFEYpiHb8ohCl+ VRKVQlgTlUJYE5VCWBOVQlgRlYgvRFSKYvJPxTKdqBTC5KIKQicqhTD5ZyVRaUlmR1Qqb1IEJSqV N2mhRDFFVIpiUkQJRRGVolgTlUJYE5VCWBOVQlgTlUJYE5VCWBGViC9EVIpi8k/FMp2oFMLkogpC JyqFMPlnJVGxXtQrwIa76DyXUXmTIihRqbxJCyWKKaJSFJMiSiiKqBTFmqgUwpqoFMKaqBTCmqgU wpqoFMKKqER8IaJSFJN/KpbpRKUQJhdVEDpRKYTJPyuJiifKFyAqlTcpghKVypu0UKKYIipFMSmi hKKISlGsiUohrIlKIayJSiGsiUohrIlKIayISsQXIipFMfmnYplOVAphclEFoROVQpj8s5KoeEVz AaJSeZMiKFGpvEkLJYopolIUkyJKKIqoFMWaqBTCmqgUwpqoFMKaqBTCmqgUwoqoRHwholIUk38q lulEpRAmF1UQOlEphMk/+dVayBz9BkxnaMf+1LMOqtv8MktO6jYbsAQ6Nhg5y20OlZ/F1mPhnr7R eexOHJ846uZSV1MP9xvNQIJ+GMR4RH1/7nl3D2+f6aV7fVPB0bu7zk3RWDAfHY1L0cktKHRq6E0X vKMBG2Tgxez+GDofxvqpOzRk8M4U6LjBGfA+jT3oq3A72DnBWyVADptFZMMErkYqD/8NHTt+/k67 vd1bXdveFTde0BrCRz8N/Ph0F/pbkjhUL4o33EkW89tUdu167Tf75W/89ydpdptfoe5FxcgCMBVX syASBrxLqAf7QPnh9iSEB3xE/ipoSU4P+nFQR5E7PoqRm3LB8qgnfZBPAEiBK04f7PJWHdSKeKZ1 x6Cu5ygd3+Fqplou+kxwqAjuq9VQYnQr3Z8wNt4HDAE2GYm1RpPRntJcDxMRrACeSlUoJfYZdE2B 1rqrqEZ3kDHor+KfEPB9L59bP86G4lk8ybjqb92dtTXRd1LqeNpOAtGOU/Q5vfr2N7N9TuIdHLqP fxe26cnQq9tGPFvUNl3CgNw2cijdNsAXnNASjBOEheok6vdrLxx02fYqLNWVtZNuKfFsUUv1ai0l k2nfhWaxd3nvF3I2N9ZyDcipdgs8P0VHUGTSzZk7jpl+WlBEqOLzvvg8EwDxURH2FGNF4MsZW4TB rdZqB6sOztLZmHh6pRmhcRn1DkIIjFPs7wrFnLBEGUJxNrdMlW80ZbE3hLzmQYDiAb8urVFSy1ZG R91FOzwwCTYXVUM+wTwDqFY7XNtsVoZHoJyaPJC5fdFLVTdD6swi8TpHKCnGU7fs+bzyu/biQr56 YqplCr/O+qGI+PAPkUuh3xUjvagU/HuuUAR8v8vC8B0XU2UWj2HcmldDNuAZC77ttLFtrgQFmSKL R/XyCfZG1QKAZvXJiI98EfUqByr2WSIbturUvkpiCDR68WK/zhOaarx+XjN1mAc1TTw65PUXqcXa ZG4vHz+ZPjp79affT796IiZYFcvmVmYNQpbc3M1koLkFA4ZB7gCyTgiwTuOegV6BlewQ+pDBJrxE k7u/IvjwJh/gsSDSbJlWWzbIVmitRChSTkeuQk854hlYB+u/JVhprcZK04cfTv/4N2GluRaB8IBN 4vAzp7bPvEB2Ko9j6OpGncJ8xavwj4UVFMUHSRwPMBQUylpalWty6fUqZZ1/+Q8rZS3bYfpL1ARY R8R5kxZEe7q+yUJif31+9pnwl3LhIuuZuW5UaCYvzImfFAafzw6MuY0zxQ78OgT8HgffA4lMgUUX /9UIoZH0AdQguNvkOz/Vsg+NicX2DPZvIo8sJKtyzELSeQZaSDiAX8jw2c2cvLarFuI/W0ycB4V+ qKv/fz9tw5Q9uescqi2pFzIXyziPt6tKrwCdDIIQfmsl38JDNb8dBseqmpzJGgIVNFJThzVOviRQ TT/77fnn/75w7q3cIMjT2KbZFqv7/8tke5mYBWwyfVQfOWXhPjdyzhyY6CdXIjeQk5HL+sEIfMDX ivA745OYqJfgkptk8TxtPv5i+uhDcMvqzNF0/RUFCI/EPFxXVB9AL6KRHlR98LbcefJPc3UiizD4 cbFDoSKn9eTViF7xiWegf5uKTx3VuS7R+iCG1mMsUwFz3ilohWKlc+SqXV3rSF3Bu/AQ8w8mI6X9 zXZ3eeVfoa35FUBDry201Sfa4qdny9RWZ01WQ7XautxroxvA5HPtp3WnvAVlayumWuf8wbceHlH2 9O9fQEz47uzXr/7y8OXjT55/8+mLs7++/M/n3519tFB8aGh/U7Hr00l+9eTFl8+g6l9oSmrjM97x k8bFJl5zyLKijX/44LC8HOUijkBOvoDF850DBreJSCYdsxod69uq8p6iaWbIFdS0uJ6raXEqMAiS NOM1jLisKeUKezIWNpj++Wu4PvjF2zvdXgfvDeebAvKZdrez9COCATHPi7OH5x/84fzbZy+fPr0Y C4g2V1WqWOSAADyX/wq5dpwSoGmQOnly4vy5cUMSaI4PQwSW2z91xzigB1tH/C2H38JVa6PpBliv 3NRsBWRxnP7D3TnCNu3H7XSTU4Aft9OVx+i8otH29uKj+RR85nrElEMG9FJabKyef/OralLKa5z6 EhhDA63uyf9jIR9goOmLv+WtEQk7+baiKGKblvfNFUEvi6Qinn1SrQhQHc66ThNgpybHEUUVPaC3 QTtuGMbw/1jgb7ILHVXfbsL93kke+nbhbsw8NVVNFRs6ACiu/vmH2dtCWMxsYilMcZH9RFPz4JJ4 2acfn04/+ifciEwffyAKHqdYd7nqkT6rK8kFbRvNJ+s0MGLdLmIxFeRukV79LwAAAP//AwBQSwME FAAGAAgAAAAhAAjXTSLhAAAAVQEAABgAKABjdXN0b21YbWwvaXRlbVByb3BzMS54bWwgoiQAKKAg AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnJDBaoQwEIbvhb5DmHs27hpWXYyLRYW9 lhZ6zcaoAZNIEpctpe/eSE/bY0/DN8PM9zPl+a5ndJPOK2sY7HcJIGmE7ZUZGby/dTgH5AM3PZ+t kQyMhXP1/FT2/tTzwH2wTl6C1Cg2VKyXhsEXzWjW0a7Fh3rfYlpkNS7yLsVF06QvdXssUpp/A4pq E894BlMIy4kQLyapud/ZRZo4HKzTPER0I7HDoIRsrFi1NIEckuRIxBr1+kPPUG15frdf5eAfcYu2 OvVfy1VdZ2VHx5fpE0hVkj+qjR9eUf0AAAD//wMAUEsDBBQABgAIAAAAIQDmycJyaAoAAGSBAAAS AAAAd29yZC9udW1iZXJpbmcueG1s7F3Nbuu4Fd4X6DsEBrzo4tr6lx1M7sCJbWCKi04xc/sAii3f CLUkQ1KSubPupsui6KKYVXd9h3b6NDNAZ9VX6CEpSmQiHUsykzixNjfX4o/Ij4fkx3MOj7748rtw e3bnJ2kQRxcDfaQNzvxoFa+D6NPF4A8fl+8mg7M086K1t40j/2Lw2U8HX77/9a++uD+PbsNrP4GM Z1BHlJ7fQfJNlu3Ox+N0deOHXjqKd34EiZs4Cb0MfiafxqGX/PF2924VhzsvC66DbZB9Hhua5gzy auKLwW0SnedVvAuDVRKn8SYjRc7jzSZY+fkfXiJp8l5Wch6vbkM/yugbx4m/hTbEUXoT7FJeW9i1 NujiDa/kDuvEXbjl+e53Td62Trx7wDncsmbfx8l6l8QrP03h6ZwlFjXqGvbuHEBSRVGiSRPkd/KW hF4QFdUQ8Xgw/sXgjWDwxuzdY1JV2RHA4j0Ik3edZom3yn53G55Jv75aXww0miVKgzWk3XlbeDIz 565rmIMxKRzebrPgg3/nbz9+3vk8D326JU9ZrizcbXnapTnXrizXYSnbO5IQwB/+LhD5JOOZdZYL 5H0ZFg/X/ioIvbxqKPnR/65IG+Yl4PFvV7yWrb/JWEW73yek1Rn0Of/L88ArBvD/XZxeDCzTINnH ZcYgIv0n9bBU+HHjRZ/oVC1z57Un7CXJMo6ylOQMIijme2k2SwMvr5lmgjdAQ0lL4A/kZDjoFPND cRgNaSdo1d2hsNlA1UBBUkUoytyKoDBUQTEa5gJ7kGC4hoYIBkkV0ShzK0LDVIGGNWJT4SAgbMdF gJiaslg4Ew6bIiAsFUDY//v3n18/FHZDKLbxvZ988LPMT4pOSwun8ybgcNrA8U0celE1GlS8D107 n2KSrP2NB3tuPvuQXcRtiAS+m8IuAkvnaGiNhvZo6IyG7mg4KSDrvq/olsXXBL4Zi3ssTRbXUiG/ ojVk8nT4jIZTFRDZEysf5kqISLIEUZm/M0Swzwt0kBAT4Se8TPhF2CFjKhI7vHSubG1Jx7YLO9St 6Ww+s0vqAi9txw5vdzt0ofvl73/6+ce/KeGJujGhrKKGHdFkcYTeNFPULQPjBDRZBOOtc0XddulZ pE44SLKIxxtmi7ql0z2jDgp34kpQvGm++OJgHBtjfHFAjokzPhEYb4Q1GsYUW1NpsrimniBrNCzT RlgjTZYgen7WyJQ6Ims0NMs2F91Z41I3HM0xrgrWDT08WtZYssAqWk9SxfEpc3cm9b12kahyKxSt vXZRVDv32sV8zei1i8XyeWxc8YX1zsfEFJ8EijfCEwXeV7XH9tpFUN2VvK8SoiPQLrINSeSJpnY1 MfTZjPG89rZnWzNmYLzubc8JtW5XUKLe9lzsfT077NlhxQzp2WExQ3p2KPnt9OyQa1162zMoHBDb fG97Zu51EkQAmWBe3mt7ZuuwxA6JL6vN/Aq62J6vlobmLq4OsD3jvhSFdrK720SpDawi7Qp0h/fn 17C8M0dP1t7gwe/0e/4AvLyoD2j6/RVxc6SF2DNc+k+KY7YCNHebkADlbjLSXJFVuqfGVNtgalAf mvtzEVP2DBfSE9KGtoKT2t8ewMltcoiInhRrfg5AT457Pweop8TgnwPP/hzQBmXmJCWvrYXjFLK2 9qcJSkObE9fmQLc8k7BFWTqTTIxLd6ovumqsNUubapo+L84OQLTbeTY8/ZnEwBxOLEiFNpe3pYrc 1J8BAK7QsR3TCUHXLax/06nsr1Ga5ZD+HRlh16cmp3BVx0rqkyaOYaM+KiHQenH/oJgA3Q/PhqvT EyvIXGU3pw8c6l2Ne60iQ6mE2JbdhGsWCnpq2ho2oIZty77HE5ufMpGeNmWc+IJTDCi7UKKgs5Yx wYbVBNcwaQXSdZPfq0B625QKtuotXJ9R0GFbQz3LzQk44ovTVTeKS5xIh4+bq9kTGxtky5w+uAxT upwjfT565uQ4FlVH1ixZtq7Ju4/uapUzuSWPYcIv8hjLWC5sV5sx8W1vedf15eJyMc81hqJhkd0w b3nbOb3dbEDEqcoxijO4Yf2pmFjSrUb97KxIQHYO8e4ZXS02QZJmHwJysV4CNFfrwx9+u9tLV0Fw MZglAVxJhzbxe94Xg1/+9ZeffvwrnYozwFLIw26EC842bY4Jz6p2bQ40LOzPjvWNUlzpQMvHL5MP PnL86kTmWuEKNzBfN7TPqoRtCy1cbn3l6FKuJwuuwfkfIrhKqKutIpyAQMkqmTlhbCKjMXW+K9LN ff+irHShYNi2x1sJgXZ+02Q/4yjC32KbFAKcnAbeTSn83tAIbi/jJPJPkzWl6yniG19igPlWvPs2 +7wtogp5TPLF9T3deSu/mBAi8/v5h/9UBipYQQgqHgIjXzxeE/lrrrqUTcRdTzqNxoUTJ4GU1w/M f//xz8rwCCczMC3PYmxGiWcx27B0257nYTjan8VmM2cG1+3KMB6wRbTTKUcQkK5y1rHgCrOzIhE5 c+3Zo4jiGAnChauVHzOClwjCNYMzkQIkiIq5Hok9CujDkeh0voETvrgaD3MNpwI09t2QJoofkSs+ UFYfjsfxKbZ1ormulxCaLELyQLF9OCRKThKqleBUy12Pyj4l+OGoKOH7EioQgUnBDKIa8Xpg9irM D0emKTN/AeU61Z4j4OxTrh8OTlcKXbXeqg/cRTXt9fjsVcQfjk9XKtsAHzWBu6hWvh6ivUr7LhC1 JJUMQ5FUOqZtgbEhD1zWnlQuF5Zjm7OS77QmldJkl09+uYLrEalQsBg+uUc1jAyig+vk6SCDU0L+ SMIV4FOG6eJ8XTwuH2cAWBmfMvDrI3z6qLC5DQ3iO6qQlacIeMntaaR9+FxSwkL7qLDSLOmjworB xZV4bzzFJBFMyfgcOW5y2cdtKF3T6kw3xx+3YUoj64rkEj4XYLkLZ8b2mPbkcj614ZMBzLVF1ms3 9R55xqiwr5FRPmLWajSXr5E8VkHR88SeJz5QaPc8seeJ/dcDBpLSpmbpVK+E7HniW+CJ+uOPS7kL bWFeaouuRHHhGIvlZFmqxFprIXvTdvEtLWxu96ZtkCzqfj7UCRZqGGJv22Ye/aKrYm/b5vccBFR6 23aNeqS3bSPfNext2xBgCsGnt23vpZXHYduGj3XC9gv/lh+hEkKHfUW+1Uk3EmrNBoU45CTDLhVj bm2tizHvr9bFmG2qshi/11jVSOZCVF+MKkO/ho8IJ8Ga+Ek/cuMU0igi/FoIHNV4EkFG+FnUIpim eVaOa4taBO/BA2oRfO4OqEUwEB5Qi+DWdUAtggvUAbUI5pwDahE8ahrVUjOjWJcqhRWbiKwPrYux RrcuxowTrYvlZ9XKctw7t2oC62wWtS+HLE/o+5D1ifuIVrYTWaC4H3ZlOWSF4ncnK8shwsK/qVdZ DpEW/vm5ynKIuKDlEHnBysGngMm6WjnuIEvMl6GqoXDJpmNBRGLwNyIigxdEZAbFBpEZtBwiM3hD EaHBCyJSgxdExIZvnlWjD/eNa0cfgwbit3Qr11VoTERoeNSUyg4iMoOWQ2RGKsf2pms/gZAA7/8P AAD//wMAUEsDBBQABgAIAAAAIQB0Pzl6wgAAACgBAAAeAAgBY3VzdG9tWG1sL19yZWxzL2l0ZW0x LnhtbC5yZWxzIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhM/BigIxDAbgu+A7 lNydzngQkel4WRa8ibjgtXQyM8VpU5oo+vYWTyss7DEJ+f6k3T/CrO6Y2VM00FQ1KIyOeh9HAz/n 79UWFIuNvZ0pooEnMuy75aI94WylLPHkE6uiRDYwiaSd1uwmDJYrShjLZKAcrJQyjzpZd7Uj6nVd b3T+bUD3YapDbyAf+gbU+ZlK8v82DYN3+EXuFjDKHxHa3VgoXMJ8zJS4yDaPKAa8YHi3mqrcC7pr 9cd/3QsAAP//AwBQSwMEFAAGAAgAAAAhAKnIXKqMAAAA2gAAABMAKABjdXN0b21YbWwvaXRlbTEu eG1sIKIkACigIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALJJsgrOLy1KTi1WCE7N SU0uSU0JLqnMSbVVinEMcNSLCPZRUgAL+CXmAgWBYkoKFbk5ecVWSbZKGSUlBVb6+sXJGam5icV6 +QWpeUC5tPyi3MQSILcoXT8/LS0zOdUlP7k0NzWvRN/IwMBMPykzKSczP70osSCjEmoYVYyys9GH e8aOlwsAAAD//wMAUEsDBBQABgAIAAAAIQAIO/xWmQEAAOwCAAAQAAgBZG9jUHJvcHMvYXBwLnht bCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJySQW/bMAyF7wP2HwyfV8tJlyIr GBVDiqGHbisQtz0LEm0Lk0VBUrrm34+um8TDbvOJfJSfnj4Jbl4HV7xgTJb8plxUdVmg12Ss7zbl Y/PtYl0WKStvlCOPm/KAqbyRHz/AQ6SAMVtMBVv4tCn7nMO1EEn3OKhU8djzpKU4qMxt7AS1rdV4 S3o/oM9iWddXAl8zeoPmIpwMy8nx+iX/r6khPeZLT80hcGAJDQ7BqYzyxxjHVYbyAOKkQkNZucYO KFdL1k8dPKgOk1yDmAp4pmi4X1+CmErY9ioqnRmhXNWXVyBmAnwNwVmtMtOV362OlKjNxc83DsVo AGK+BJjNDvU+2nyQNYh5C/fWc5TPCxBTxdmi6qIKfZILVmct7LRyuGUEslUuIYizAFsagvIHebdX v9EWDerek6NuvMotVZ/us6n4FO+rxm1/pcfQ0O3I793ub3HG4NnmfheU5qSrLzVzO9OYjWDH0NDw 8Y6GZwHu+M6iG3flf32H5rjm38HI92l6vHKxrGr+3oAeNYZyelXyDwAAAP//AwBQSwMEFAAGAAgA AAAhAKnofFp9AQAA1QIAABEACAFkb2NQcm9wcy9jb3JlLnhtbCCiBAEooAABAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAHySTU/DMAyG70j8hyr3Luk2IVRtnfgQJ5CQGOLjFhxvC7RJlGSU/Xvc disrQkg91Pbrp/brzhZfVZl8og/amjnLRoIlaMAqbdZz9ri8Sc9ZEqI0SpbW4JztMLBFcXoyA5eD 9XjvrUMfNYaESCbk4OZsE6PLOQ+wwUqGESkMFVfWVzJS6NfcSfiQa+RjIc54hVEqGSVvgKnriWyP VNAj3daXLUABxxIrNDHwbJTxH21EX4U/G9rKkbLScedop/24x2wFXbFXfwXdC+u6HtWTdgyaP+PP d7cP7aqpNo1XgKyYKcjD9u0dIRYzfhzQO3iU0friRZo1PW39kGuM/cBdbb0K1DmIqFVhAK9dpHN1 3EGC1KUM8Y7ut9KoLnfFrQVZXgDYrYkt7Ve9+ZzHT93cv5i2ij6kHVrLunlRJWRC3ll2qDxNrq6X N6wYi0yk4iwdZ0sxzSciF+K1WWvQ35jSJar9gP8TpylBx9NllhFuSDwAOoeGP2LxDQAA//8DAFBL AwQUAAYACAAAACEA1z3MogwDAACADAAAEgAAAHdvcmQvZm9udFRhYmxlLnhtbMRWQW/TMBS+I/Ef It9ZnDRr02rZ1KbL4MAObDsjL3UXS3Fcxem63bjvgBBHzly5ckD8G0BC8CN4tpOqWxraDG0kitS+ 2C/Pn7/v89s7uOKpdUlzyUQWIGcHI4tmsZiw7CJAZ6fRMx9ZsiDZhKQiowG6phId7D99srcYTEVW SAvmZ3KQBygpitnAtmWcUE7kjpjRDN5NRc5JAX/zC1tMpyymYxHPOc0K28W4a+c0JQV8WyZsJlGZ bbFNtoXIJ7NcxFRKKJanJh8nLEP7ZXXWYpARDlWfMk6ldUwX1ivBiRkwI5mQ1IExlyQNEHbh7uIO 3sUePC788pCtMsUJySUtlgOxCU8JZ+l1Fc11Xj1+xoo4qeKXJGfkPKVmjmQX8GIuz3GADjHG7jCK kIk4AQoh0vM9p4y4UJS5+mWks4zANkFhOo8e4pg8EIE85Sxdp232qYbIEMpKNVB1HEaAg6fxUJi4 rXCQCyalWey/4tB5DBx+fnn37et7DQRJi2NgS7VzJ4w/p6xcSo0rDmDUh8epbjPwDlf8rgnf5goX E5pna0Casis6MfFVpvhqQ93RClM6fhj1wmh4FyGnu4EpHmTS/NqeKd8/3TQjdDKv1rEWIQwqug9C ZF6INfg0i6mkfEUZEIHr+5GKPgZEPz5+BoheH43cjuNqLj0ID8pFVv6glO5jZSP1RVaRJsdQPKg8 ZEvHCMU8ZzRXLtrgGz3Y7b52DOWfXivfaKuJRvesKPCg7jkWxZyvM41fb29+f3hTUrcmCWWs6tog CcfMv20a7Y11pD4FJ0ypANjmbn/cA9sY3dVEZxNdwIH6Os/2tvHyxDp7YR2JImFxA18MHD3gyi4Q uemc8deet+3h0EJxV8/b7jDsReM6HKBhcyY3qQc6l7ZwaMaECf0LFP17MqOtdP4vL0LCz6H3aMBB tV6mBVOtWBMlwLp0p3VbIe1bsKFWyOGKQrQvYq+mkKXFNlECRN2WEiFJGUDRgESkm1DdfrVG4h7i cJRXrIpDITEMl5FWdroRibIrlft/AAAA//8DAFBLAwQUAAYACAAAACEAKIdxpc8AAAAfAQAAFAAA AHdvcmQvd2ViU2V0dGluZ3MueG1sjI/LTgMxDEX3SPzDKHuagUWFRp2phFDZUKjEY59mPJ1IiR3Z gdB+PeaxYcfy2lfHx6v1R4rNO7AEwt5cLlrTAHoaAx568/K8ubg2jRSHo4uE0JsjiFkP52er2lXY P0Ep2pRGKSgd92YuJXfWip8hOVlQBtTdRJxc0cgHS9MUPNySf0uAxV617dIyRFfUQOaQxfzS6n9o lXjMTB5EVCTFH15yAc2gjpRLSOEEG+IbpirA9mus946P+Lq9/04uRqq7hzsN9s9bwycAAAD//wMA UEsDBBQABgAIAAAAIQBZG907LwMAAFgFAAATAAgBZG9jUHJvcHMvY3VzdG9tLnhtbCCiBAEooAAB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALSUW4+iWBCA3038D4an3RCH+63T9kRAFEQFARVe Okc8IAoH5CY42f++dmZnN53Mvuxmcp4qVflO1VdJvX7tsnTUwrJKcjTBqC8kNoIozE8JiieY52pj ERtVNUAnkOYITrAeVtjXt+Hg1SrzApZ1AqvRE4GqCXau6+KFIKrwDDNQfXmm0TMT5WUG6mdYxkQe RUkI1TxsMohqgiZJngibqs6zcfE3DvvOe2nr/4o85eFHd9XO7Ytnu2+vf8H7UZTVyWmCfVM5RVU5 khvTM0kZUyQljyVGEsakSJK0TCuaNJ39gY2Kj2IaGyGQPUd/z6r3QlffBZpjWOaJbeuXtLhXdfn2 G/P7tb6TfXezVYfGgXqN+akZS0zdu/NzoxcxPCx4ynNCzvGd0g+u3cM8XTIPRBujgzQ81Bu6oNcz sh0OkH4gq2PBMz6uWQIl9oeLQMj83bZix82NlRmEfgkyzkpNG/cOwWJ1XNaN+Fg84BJHK5OKaBvJ cDsczP3cZfFDVuhhFO4dVhK5Flw5qk52K9nZKMe27SMoR7Li3PTHOdjv0I4oPc5JGdc6iAxwmeOh CKLh4HrWN2wdccRs2gWGDvq1QmmvxD8GXokfkv+nbubnuqlPvmP2Oe3Rj9LL7LyyEiRUpNz5SmHZ 6jyUj4U3Jbgi8tlHkojC2XnEYjwczBRHs7cLcDOO1bTle4HBi+AAKlslmpsWL73jPShu2T7mOiCW jS2d2HZda4vrnfbTu0L4NmMKWnMdDqBg8rVzQbudt98vRYUT3ETOJc5YTOeMnN5K0WmRKjVSmvLP hRgoOfF6rINNEoENP12UZHTMHhdxOEjXpBtKfpoIIj4z2BDq034qzoPHholXyonnPR+t0MrStr9E Nvtz2fQn2b6tgRndsU0Qt8n24i3VO95su33a5I/WHg6o9lIGONiVaXOhpCTEkzVP0jZHGBDKqQAV tzoVKD3U6/hs2FZi7WWTQkJo3zzn5pvaRe8hII7ucCBr6c4wpKwznAfumnvmBIgLu92LorVD66QL e5ZfUQKxnN8nv8QH98NHFaUg/mSBYj+eyNDMv/1MfByd7yfx7U8AAAD//wMAUEsBAi0AFAAGAAgA AAAhAIyKaJH2AQAA4goAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwEC LQAUAAYACAAAACEAmVV+BQQBAADhAgAACwAAAAAAAAAAAAAAAAAvBAAAX3JlbHMvLnJlbHNQSwEC LQAUAAYACAAAACEAbwGlH3kBAABSCAAAHAAAAAAAAAAAAAAAAABkBwAAd29yZC9fcmVscy9kb2N1 bWVudC54bWwucmVsc1BLAQItABQABgAIAAAAIQBTkYZ9GRoAAELLAgARAAAAAAAAAAAAAAAAAB8K AAB3b3JkL2RvY3VtZW50LnhtbFBLAQItABQABgAIAAAAIQAKe8HhVAEAAP8CAAAQAAAAAAAAAAAA AAAAAGckAAB3b3JkL2Zvb3RlcjMueG1sUEsBAi0AFAAGAAgAAAAhAGnHhiJhAwAA8gkAABAAAAAA AAAAAAAAAAAA6SUAAHdvcmQvZm9vdGVyMi54bWxQSwECLQAUAAYACAAAACEAy/WgyBsFAACkEQAA EAAAAAAAAAAAAAAAAAB4KQAAd29yZC9oZWFkZXIyLnhtbFBLAQItABQABgAIAAAAIQB4GgzKVAEA AP8CAAAQAAAAAAAAAAAAAAAAAMEuAAB3b3JkL2hlYWRlcjEueG1sUEsBAi0AFAAGAAgAAAAhAJfj FpxrAQAAswMAABEAAAAAAAAAAAAAAAAAQzAAAHdvcmQvZW5kbm90ZXMueG1sUEsBAi0AFAAGAAgA AAAhACHrzwlqAQAAuQMAABIAAAAAAAAAAAAAAAAA3TEAAHdvcmQvZm9vdG5vdGVzLnhtbFBLAQIt ABQABgAIAAAAIQBYYLMbugAAACIBAAAbAAAAAAAAAAAAAAAAAHczAAB3b3JkL19yZWxzL2hlYWRl cjIueG1sLnJlbHNQSwECLQAUAAYACAAAACEAeBoMylQBAAD/AgAAEAAAAAAAAAAAAAAAAABqNAAA d29yZC9oZWFkZXIzLnhtbFBLAQItABQABgAIAAAAIQAKe8HhVAEAAP8CAAAQAAAAAAAAAAAAAAAA AOw1AAB3b3JkL2Zvb3RlcjEueG1sUEsBAi0AFAAGAAgAAAAhAMccbRScBgAAURsAABUAAAAAAAAA AAAAAAAAbjcAAHdvcmQvdGhlbWUvdGhlbWUxLnhtbFBLAQItAAoAAAAAAAAAIQDHGf7qJ40AACeN AAAWAAAAAAAAAAAAAAAAAD0+AAB3b3JkL21lZGlhL2ltYWdlMS5qcGVnUEsBAi0AFAAGAAgAAAAh AA9RBIs7BAAA1gkAABEAAAAAAAAAAAAAAAAAmMsAAHdvcmQvc2V0dGluZ3MueG1sUEsBAi0AFAAG AAgAAAAhAAQ+3gTJCwAABkcAAA8AAAAAAAAAAAAAAAAAAtAAAHdvcmQvc3R5bGVzLnhtbFBLAQIt ABQABgAIAAAAIQAI100i4QAAAFUBAAAYAAAAAAAAAAAAAAAAAPjbAABjdXN0b21YbWwvaXRlbVBy b3BzMS54bWxQSwECLQAUAAYACAAAACEA5snCcmgKAABkgQAAEgAAAAAAAAAAAAAAAAA33QAAd29y ZC9udW1iZXJpbmcueG1sUEsBAi0AFAAGAAgAAAAhAHQ/OXrCAAAAKAEAAB4AAAAAAAAAAAAAAAAA z+cAAGN1c3RvbVhtbC9fcmVscy9pdGVtMS54bWwucmVsc1BLAQItABQABgAIAAAAIQCpyFyqjAAA ANoAAAATAAAAAAAAAAAAAAAAANXpAABjdXN0b21YbWwvaXRlbTEueG1sUEsBAi0AFAAGAAgAAAAh AAg7/FaZAQAA7AIAABAAAAAAAAAAAAAAAAAAuuoAAGRvY1Byb3BzL2FwcC54bWxQSwECLQAUAAYA CAAAACEAqeh8Wn0BAADVAgAAEQAAAAAAAAAAAAAAAACJ7QAAZG9jUHJvcHMvY29yZS54bWxQSwEC LQAUAAYACAAAACEA1z3MogwDAACADAAAEgAAAAAAAAAAAAAAAAA98AAAd29yZC9mb250VGFibGUu eG1sUEsBAi0AFAAGAAgAAAAhACiHcaXPAAAAHwEAABQAAAAAAAAAAAAAAAAAefMAAHdvcmQvd2Vi U2V0dGluZ3MueG1sUEsBAi0AFAAGAAgAAAAhAFkb3TsvAwAAWAUAABMAAAAAAAAAAAAAAAAAevQA AGRvY1Byb3BzL2N1c3RvbS54bWxQSwUGAAAAABoAGgCVBgAA4vgAAAAA --_005_D496C972D1A13540A730720631EC73413A41B50Cnkgeml507mbschi_-- From nobody Fri Oct 24 12:34:41 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4D31A1AEE; Fri, 24 Oct 2014 12:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.511 X-Spam-Level: X-Spam-Status: No, score=-13.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_AFFORDABLE=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 pPwVRS4JjxaI; Fri, 24 Oct 2014 12:34:36 -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 6BBC01A03C7; Fri, 24 Oct 2014 12:34:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4644; q=dns/txt; s=iport; t=1414179276; x=1415388876; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=C5aIYC9F23WW7Q+BrtqUyYBnKUxR7KYsWghgbFDOzgA=; b=Q8AyufDWN37sRA/QWiYT60gR1L/EmDPUaEJVKkLZwGj4wM/Po42dNjh0 wcF24BTSRqUU68pXMonAPXa/x2G901ClB8Fklyu5pi5XvEj0MTUfS7Rwz zIpJxIpnyW3KXUJKq8a9GMc+rLpWBOy/GCF1ZX+fqXWsx9j66jRBFbjdm o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvIMAMqoSlStJV2P/2dsb2JhbABcgw5UUwUEgwLKLYdLAhttFgF9BIN+AQEBBCMRQwIMBAIBCBEEAQEDAgYdAwICAjAUAQYBAQUDAgQBDQUIARKIJggFthSVCgEBAQEBAQEBAQEBAQEBAQEBAQEBAReBLI57DyIHBoJxNoEeBZIFhEaIQzyDDZEygjSBRGwBgUeBAwEBAQ X-IronPort-AV: E=Sophos;i="5.04,781,1406592000"; d="scan'208";a="366450867" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-2.cisco.com with ESMTP; 24 Oct 2014 19:34:35 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s9OJYZYD002351 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 Oct 2014 19:34:35 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.58]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Fri, 24 Oct 2014 14:34:35 -0500 From: "Eric Voit (evoit)" To: "netmod@ietf.org" , "Rtg-yang-coord@ietf.org" Thread-Topic: New Version Notification for draft-voit-netmod-peer-mount-requirements-01.txt Thread-Index: AQHP775gVnjO1X3jmkOoWhWQAQ2mfJw/nilQ Date: Fri, 24 Oct 2014 19:34:34 +0000 Message-ID: References: <20141024191151.7453.42820.idtracker@ietfa.amsl.com> In-Reply-To: <20141024191151.7453.42820.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.134.135] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/taID1C0HLTYzl3Q7tHT7k7vP6Og Cc: Spiros Motsenigos , Angelo Corsaro , "Sander Mertens \(sander.mertens8@gmail.com\)" Subject: [netmod] FW: New Version Notification for draft-voit-netmod-peer-mount-requirements-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: Fri, 24 Oct 2014 19:34:38 -0000 QSBuZXcgdmVyc2lvbiBvZiAiUGVlciBNb3VudCBSZXF1aXJlbWVudHMiIGhhcyBiZWVuIHVwbG9h ZGVkLiAgDQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC12b2l0LW5l dG1vZC1wZWVyLW1vdW50LXJlcXVpcmVtZW50cy0wMS50eHQgDQoNCktleSBjaGFuZ2VzIGluY2x1 ZGU6DQoNCkFkZGl0aW9uYWwgQXV0aG9yOiANCiAgICAgU2FuZGVyIE1lcnRlbnMgZnJvbSBQcmlz bXRlY2gNCg0KTmV3IENvbnRlbnQ6DQogICAgIDUuNC4gIE1vdW50IEZpbHRlciANCiAgICAgNS41 LiAgQXV0by1OZWdvdGlhdGlvbiBvZiBQZWVyIE1vdW50IENsaWVudCBRb1MgDQogICAgIDUuNi4g IERhdGFzdG9yZSBRdWFsaWZpY2F0aW9uDQogICAgIDUuNy4gIExvY2FsIE1vdW50aW5nDQogICAg IDUuOC4gIE1vdW50IENhc2NhZGVzIA0KICAgICA1LjExLiBIaWdoIEF2YWlsYWJpbGl0eSANCiAg ICAgICA1LjExLjEuICBSZWxpYWJpbGl0eSAgDQogICAgICAgNS4xMS4yLiAgQWxpZ25tZW50IHRv IGxhdGUgam9pbmluZyBwZWVycyAgDQogICAgICAgNS4xMS4zLiAgTGl2ZWxpbmVzcyANCiAgICAg ICA1LjExLjQuICBNZXJnaW5nIG9mIGRhdGFzZXRzICANCiAgICAgICA1LjExLjUuICBEaXN0cmli dXRlZCBNb3VudCBTZXJ2ZXJzIA0KDQpFeHBlY3QgdHdvIGFkZGl0aW9uYWwgZHJhZnRzIGluIHRo aXMgYXJlYSB0byBiZSBzdWJtaXR0ZWQgYmVmb3JlIGNsb3NlIG9mIGJ1c2luZXNzIE1vbmRheToN CiAgKDEpICBDbG91ZCBTTEEgWUFORyBNb2RlbCBpbmNvcnBvcmF0aW5nIFBlZXIgTW91bnQgU2Vt YW50aWNzIChBLiBUcmlwYXRoeSBldCBhbC4pDQogICgyKSAgU3Vic2NyaWJpbmcgdG8gWUFORyBk YXRhc3RvcmUgcHVzaCB1cGRhdGVzIChBLiBDbGVtbSBldCBhbC4pDQoNClRoYW5rcyENCkVyaWMN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBGcmlkYXksIE9j dG9iZXIgMjQsIDIwMTQgMzoxMiBQTQ0KVG86IFNhbmRlciBNZXJ0ZW5zOyBBbGV4YW5kZXIgQ2xl bW0gKGFsZXgpOyBFcmljIFZvaXQgKGV2b2l0KTsgQWxleGFuZGVyIENsZW1tIChhbGV4KTsgRXJp YyBWb2l0IChldm9pdCk7IFNhbmRlciBNZXJ0ZW5zDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3Rp ZmljYXRpb24gZm9yIGRyYWZ0LXZvaXQtbmV0bW9kLXBlZXItbW91bnQtcmVxdWlyZW1lbnRzLTAx LnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC12b2l0LW5ldG1vZC1wZWVyLW1v dW50LXJlcXVpcmVtZW50cy0wMS50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQg YnkgRXJpYyBWb2l0IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJ CWRyYWZ0LXZvaXQtbmV0bW9kLXBlZXItbW91bnQtcmVxdWlyZW1lbnRzDQpSZXZpc2lvbjoJMDEN ClRpdGxlOgkJUmVxdWlyZW1lbnRzIGZvciBQZWVyIE1vdW50aW5nIG9mIFlBTkcgc3VidHJlZXMg ZnJvbSBSZW1vdGUgRGF0YXN0b3Jlcw0KRG9jdW1lbnQgZGF0ZToJMjAxNC0xMC0yNA0KR3JvdXA6 CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMjQNClVSTDogICAgICAgICAgICBodHRw Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC12b2l0LW5ldG1vZC1wZWVyLW1v dW50LXJlcXVpcmVtZW50cy0wMS50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC12b2l0LW5ldG1vZC1wZWVyLW1vdW50LXJlcXVpcmVtZW50 cy8NCkh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC12b2l0 LW5ldG1vZC1wZWVyLW1vdW50LXJlcXVpcmVtZW50cy0wMQ0KRGlmZjogICAgICAgICAgIGh0dHA6 Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXZvaXQtbmV0bW9kLXBlZXItbW91bnQt cmVxdWlyZW1lbnRzLTAxDQoNCkFic3RyYWN0Og0KICAgTmV0d29yayBpbnRlZ3JhdGVkIGFwcGxp Y2F0aW9ucyB3YW50IHNpbXBsZSB3YXlzIHRvIGFjY2VzcyBZQU5HDQogICBvYmplY3RzIGFuZCBz dWJ0cmVlcyB3aGljaCBtaWdodCBiZSBkaXN0cmlidXRlZCBhY3Jvc3MgbmV0d29yay4NCiAgIFBl cmZvcm1hbmNlIHJlcXVpcmVtZW50cyBtYXkgZGljdGF0ZSB0aGF0IGl0IGlzIHVuYWZmb3JkYWJs ZSBmb3IgYQ0KICAgc3Vic2V0IG9mIHRoZXNlIGFwcGxpY2F0aW9ucyB0byBnbyB0aHJvdWdoIGV4 aXN0aW5nIGNlbnRyYWxpemVkDQogICBtYW5hZ2VtZW50IGJyb2tlcnMuICBGb3Igc3VjaCBhcHBs aWNhdGlvbnMsIGRldmVsb3BtZW50IGNvbXBsZXhpdHkNCiAgIG11c3QgYmUgbWluaW1pemVkLiAg U3BlY2lmaWMgYXNwZWN0cyBvZiBjb21wbGV4aXR5IGRldmVsb3BlcnMgd2FudCB0bw0KICAgaWdu b3JlIGluY2x1ZGU6DQoNCiAgIG8gIHdoZXRoZXIgYXV0aG9yaXRhdGl2ZSBpbmZvcm1hdGlvbiBp cyBhY3R1YWxseSBzb3VyY2VkIGZyb20gcmVtb3RlDQogICAgICBkYXRhc3RvcmVzIChhcyB3ZWxs IGFzIGhvdyB0byBnZXQgdG8gdGhvc2UgZGF0YXN0b3JlcyksDQoNCiAgIG8gIHdoZXRoZXIgc3Vj aCBpbmZvcm1hdGlvbiBoYXMgYmVlbiBsb2NhbGx5IGNhY2hlZCBvciBub3QsDQoNCiAgIG8gIHdo ZXRoZXIgdGhlcmUgYXJlIHplcm8sIG9uZSwgb3IgbW9yZSBjb250cm9sbGVycyBhc3NlcnRpbmcN CiAgICAgIG93bmVyc2hpcCBvZiBpbmZvcm1hdGlvbiwgYW5kDQoNCiAgIG8gIHdoZXRoZXIgdGhl cmUgYXJlIGludGVyYWN0aW9ucyB3aXRoIG90aGVyIGFwcGxpY2F0aW9ucw0KICAgICAgY29uY3Vy cmVudGx5IHJ1bm5pbmcgZWxzZXdoZXJlDQoNCiAgIFRoZSBzb2x1dGlvbiByZXF1aXJlbWVudHMg ZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQgZGV0YWlsIHdoYXQgaXMNCiAgIG5lZWRlZCB0byBz dXBwb3J0IGFwcGxpY2F0aW9uIGFjY2VzcyB0byBhdXRob3JpdGF0aXZlIG5ldHdvcmsgWUFORw0K ICAgb2JqZWN0cyBmcm9tIGNvbnRyb2xsZXJzIChzdGFyKSBvciBwZWVyaW5nIG5ldHdvcmsgZGV2 aWNlcyAobWVzaCkgaW4NCiAgIHN1Y2ggYSB3YXkgdG8gbWVldCB0aGVzZSBnb2Fscy4NCg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2Ug YSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhl IGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9y Zy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Fri Oct 24 13:22:49 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 264D11A9115 for ; Fri, 24 Oct 2014 13:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[BAYES_40=-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 J_weOn4QN-Ex for ; Fri, 24 Oct 2014 13:22:45 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id DF0791A9108 for ; Fri, 24 Oct 2014 13:22:44 -0700 (PDT) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id D48AE1280096 for ; Fri, 24 Oct 2014 22:22:43 +0200 (CEST) Date: Fri, 24 Oct 2014 22:22:43 +0200 (CEST) Message-Id: <20141024.222243.307660275.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/zGSE8vxMc9igpTlaRYIJvXGY66I Subject: [netmod] issue Y56 UTF8 non-characters X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 24 Oct 2014 20:22:48 -0000 Hi, When I was looking at issue Y56, I realized that 6020 doesn't define any rules for characters in YANG modules. This impacts even things like enum names - there are no rules for them at all. I think we should have the same rules for the YANG module as for the "string" built-in type. So I propose the following changes: ------------------------------------------------ In section 6: OLD: YANG modules use the UTF-8 [RFC3629] character encoding. NEW: YANG modules use the UTF-8 [RFC3629] character encoding. Legal characters in YANG modules are the Unicode and ISO/IEC 10646 [ISO.10646] characters, excluding the surrogate blocks, the noncharacters, and the C0 control characters except tab, carriage return, and line feed. The character syntax is formally defined by the rule "yang-char" in Section 13. (yes I know, double negation in there... any suggestions? s/except/but including/ ?) ------------------------------------------------ In 9.4. The string Built-In Type OLD: The string built-in type represents human-readable strings in YANG. Legal characters are tab, carriage return, line feed, and the legal characters of Unicode and ISO/IEC 10646 [ISO.10646]: ;; any Unicode character, excluding the surrogate blocks, ;; FFFE, and FFFF. string = *char char = %x9 / %xA / %xD / %x20-D7FF / %xE000-FFFD / %x10000-10FFFF NEW: The string built-in type represents human-readable strings in YANG. Legal characters are the Unicode and ISO/IEC 10646 [ISO.10646] characters, excluding the surrogate blocks, the noncharacters, and the C0 control characters except tab, carriage return, and line feed. The string syntax is formally defined by the rule "yang-string" in Section 13. ------------------------------------------------ In the grammar: OLD: string = < an unquoted string as returned by the scanner > NEW: string = < an unquoted string as returned by the scanner, that matches the rule yang-string > yang-string = *yang-char ;; any Unicode character, excluding the surrogate blocks, the ;; noncharacters, and the C0 control characters except ;; tab, carriage return, and line feed. yang-char = %x9 / %xA / %xD / %x20-D7FF / ; exclude surrogate blocks %xD800-DFFF %xE000-FDCF / ; exclude noncharacters %xFDD0-FDEF %xFDF0-FFFD / ; exclude noncharacters %xFFFE-FFFF %x10000-1FFFD / ; exclude noncharacters %x1FFFE-1FFFF %x20000-2FFFD / ; exclude noncharacters %x2FFFE-2FFFF %x30000-3FFFD / ; exclude noncharacters %x3FFFE-3FFFF %x40000-4FFFD / ; exclude noncharacters %x4FFFE-4FFFF %x50000-5FFFD / ; exclude noncharacters %x5FFFE-5FFFF %x60000-6FFFD / ; exclude noncharacters %x6FFFE-6FFFF %x70000-7FFFD / ; exclude noncharacters %x7FFFE-7FFFF %x80000-8FFFD / ; exclude noncharacters %x8FFFE-8FFFF %x90000-9FFFD / ; exclude noncharacters %x9FFFE-9FFFF %xA0000-AFFFD / ; exclude noncharacters %xAFFFE-AFFFF %xB0000-BFFFD / ; exclude noncharacters %xBFFFE-BFFFF %xC0000-CFFFD / ; exclude noncharacters %xCFFFE-CFFFF %xD0000-DFFFD / ; exclude noncharacters %xDFFFE-DFFFF %xE0000-EFFFD / ; exclude noncharacters %xEFFFE-EFFFF %xF0000-FFFFD / ; exclude noncharacters %xFFFFE-FFFFF %x100000-10FFFD ; exclude noncharacters %x10FFFE-10FFFF /martin From nobody Fri Oct 24 13:41:35 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4781A90F0 for ; Fri, 24 Oct 2014 13:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s85yFrlnQlf7 for ; Fri, 24 Oct 2014 13:41:27 -0700 (PDT) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 525E21A9116 for ; Fri, 24 Oct 2014 13:41:20 -0700 (PDT) Received: by mail-yh0-f53.google.com with SMTP id z6so1586911yhz.12 for ; Fri, 24 Oct 2014 13:41:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ifYcbQlcf6hbLmDypX5OT2gZeX/ju/9tJIsoMy+SOhA=; b=q7aqxoSTFIa+CUbcFMshOk3iXyu/cX6MTeXmj3D7tAse4u3q9PR+URhWXjFjRqgPeU 8Nf0hrzLcnDuDC1OXi8XhiEx8+VXgAd624N3C+vLnmkHfkSvLy8RQO+eNYpksSx83QUv TfexzBT9Iv+eTsznr4hQ3LdLJLek7JtIRDOy+A5PA5VD285h9ZKa37M5Tig748OOT+ey 1y1F88O5T4Yhu0n4axdcncKfzjZATbNYNGW5UZYjR4A4Zf5Gsa7A3xgECNd75uy49qnr zhnwQDwtqDFW/410V4rhqP8v2XM0kgPwBtGlI/kqZFG+WmkMNOziKP2YtXC3r4l3x1r6 kvhQ== MIME-Version: 1.0 X-Received: by 10.170.79.65 with SMTP id v62mr9892390ykv.18.1414183279568; Fri, 24 Oct 2014 13:41:19 -0700 (PDT) Sender: chelliot@gmail.com Received: by 10.170.222.86 with HTTP; Fri, 24 Oct 2014 13:41:19 -0700 (PDT) In-Reply-To: <20141024.222243.307660275.mbj@tail-f.com> References: <20141024.222243.307660275.mbj@tail-f.com> Date: Fri, 24 Oct 2014 16:41:19 -0400 X-Google-Sender-Auth: 4Z8rNf55ribm4t1KLXD8B0E8Y_s Message-ID: From: Chris Elliott To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a113968a606afad05063134fc Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/u-LVhOOUpjPCbs0LB_yIXwbF0Bk Cc: "netmod@ietf.org" Subject: Re: [netmod] issue Y56 UTF8 non-characters X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: chelliot@pobox.com List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 20:41:30 -0000 --001a113968a606afad05063134fc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Friday, October 24, 2014, Martin Bjorklund wrote: > Hi, > > When I was looking at issue Y56, I realized that 6020 doesn't define > any rules for characters in YANG modules. This impacts even things > like enum names - there are no rules for them at all. > > I think we should have the same rules for the YANG module as for the > "string" built-in type. > > So I propose the following changes: > > ------------------------------------------------ > In section 6: > > OLD: > > YANG modules use the UTF-8 [RFC3629] character encoding. > > NEW: > > YANG modules use the UTF-8 [RFC3629] character encoding. > > Legal characters in YANG modules are the Unicode and ISO/IEC 10646 > [ISO.10646] characters, excluding the surrogate blocks, the > noncharacters, and the C0 control characters except tab, carriage > return, and line feed. The character syntax is formally defined by > the rule "yang-char" in Section 13. ...[ISO.10646] characters, including tab, carriage return, and line feed, but excluding the other C0 control characters, surrogate blocks and non-characters. > (yes I know, double negation in there... any suggestions? > s/except/but including/ ?) Hope this helps. Chris. > ------------------------------------------------ > In 9.4. The string Built-In Type > > OLD: > > The string built-in type represents human-readable strings in YANG. > Legal characters are tab, carriage return, line feed, and the legal > characters of Unicode and ISO/IEC 10646 [ISO.10646]: > > ;; any Unicode character, excluding the surrogate blocks, > ;; FFFE, and FFFF. > string =3D *char > char =3D %x9 / %xA / %xD / %x20-D7FF / %xE000-FFFD / > %x10000-10FFFF > > NEW: > > The string built-in type represents human-readable strings in YANG. > Legal characters are the Unicode and ISO/IEC 10646 [ISO.10646] > characters, excluding the surrogate blocks, the noncharacters, and > the C0 control characters except tab, carriage return, and line feed. > The string syntax is formally defined by the rule "yang-string" in > Section 13. > > > ------------------------------------------------ > In the grammar: > > OLD: > > string =3D < an unquoted string as returned by > the scanner > > > NEW: > > string =3D < an unquoted string as returned by > the scanner, that matches the rule > yang-string > > > yang-string =3D *yang-char > > ;; any Unicode character, excluding the surrogate blocks, the > ;; noncharacters, and the C0 control characters except > ;; tab, carriage return, and line feed. > yang-char =3D %x9 / %xA / %xD / %x20-D7FF / > ; exclude surrogate blocks %xD800-DFFF > %xE000-FDCF / ; exclude noncharacters %xFDD0-FDEF > %xFDF0-FFFD / ; exclude noncharacters %xFFFE-FFFF > %x10000-1FFFD / ; exclude noncharacters %x1FFFE-1FFFF > %x20000-2FFFD / ; exclude noncharacters %x2FFFE-2FFFF > %x30000-3FFFD / ; exclude noncharacters %x3FFFE-3FFFF > %x40000-4FFFD / ; exclude noncharacters %x4FFFE-4FFFF > %x50000-5FFFD / ; exclude noncharacters %x5FFFE-5FFFF > %x60000-6FFFD / ; exclude noncharacters %x6FFFE-6FFFF > %x70000-7FFFD / ; exclude noncharacters %x7FFFE-7FFFF > %x80000-8FFFD / ; exclude noncharacters %x8FFFE-8FFFF > %x90000-9FFFD / ; exclude noncharacters %x9FFFE-9FFFF > %xA0000-AFFFD / ; exclude noncharacters %xAFFFE-AFFFF > %xB0000-BFFFD / ; exclude noncharacters %xBFFFE-BFFFF > %xC0000-CFFFD / ; exclude noncharacters %xCFFFE-CFFFF > %xD0000-DFFFD / ; exclude noncharacters %xDFFFE-DFFFF > %xE0000-EFFFD / ; exclude noncharacters %xEFFFE-EFFFF > %xF0000-FFFFD / ; exclude noncharacters %xFFFFE-FFFFF > %x100000-10FFFD ; exclude noncharacters %x10FFFE-10FFFF > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --=20 Chris Elliott CCIE # 2013 =E2=80=9CYou and I are mirages that perceive themselves=E2=80=9D --Douglas Hofstadter --001a113968a606afad05063134fc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Friday, October 24, 2014, Martin Bjorklund <mbj@tail-f.com> wrote:
Hi,

When I was looking at issue Y56, I realized that 6020 doesn't define any rules for characters in YANG modules.=C2=A0 This impacts even things like enum names - there are no rules for them at all.

I think we should have the same rules for the YANG module as for the
"string" built-in type.

So I propose the following changes:

------------------------------------------------
In section 6:

OLD:

=C2=A0 =C2=A0YANG modules use the UTF-8 [RFC3629] character encoding.

NEW:

=C2=A0 =C2=A0YANG modules use the UTF-8 [RFC3629] character encoding.

=C2=A0 =C2=A0Legal characters in YANG modules are the Unicode and ISO/IEC 1= 0646
=C2=A0 =C2=A0[ISO.10646] characters, excluding the surrogate blocks, the =C2=A0 =C2=A0noncharacters, and the C0 control characters except tab, carri= age
=C2=A0 =C2=A0return, and line feed.=C2=A0 The character syntax is formally = defined by
=C2=A0 =C2=A0the rule "yang-char" in Section 13.

Hi Kent,

I ran into similar issues befo= re trying to use YANG. Essentially the caveat is that the yang validator do= esn't check that the when statements are logically disjoint (if there w= as one, it should be in semantic check stage anyway). e.g.
uses g= roupingA {
=C2=A0 when "condition1";
=C2=A0 l= eaf node1 {...}
}

uses groupingA {
=
=C2=A0 when "condition2";
=C2=A0 leaf node1 {...}<= /div>
}

By doing this, you are essentially cre= ating two nodes of the same name instead of branching the condition. Simila= r situations happen when you try to augment a node with leafs that have the= same name but different structure under different conditions. One possible= solution is to use choice/case on a higher level (which was what you start= ed with).=C2=A0

Using augment and choice, you= might be able to flatten it out to this extent:
=C2=A0 =C2=A0+--rw netconf-serv= er
=C2=A0 =C2=A0 =C2=A0 +--rw listen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw endpoint* [name]
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 +--rw name=C2=A0 =C2=A0 string
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 +--rw address=C2=A0 =C2=A0 inet:ip-address
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 +--rw (transport)
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--:(ssh) {ssh-listen}?=
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw ssh
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0+--rw port?=C2=A0 =C2=A0 =C2=A0 inet:port-number
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--:(tls) {tls-listen}?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 +--rw tls
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0+--rw port?=C2=A0 =C2=A0 =C2=A0 inet:port-number
Bu= t that's not much of an improvement either.

Since the only conditioning substatement of refine is the must stat= ement (and mandatory statement which is not very helpful here), uses doesn&= #39;t have choice as a substatement, I think this flattening might be diffi= cult to accomplish.

Another foreseeable solution w= ith future extensions is to allow when statements to take on enum values. B= ut that's complicating the issues at hand.

Bes= t,
Xiao

On Wed, Oct 22, 2014 at 8:14 PM, Kent Watsen = <kwatsen@junipe= r.net> wrote:

I'm trying to flatten the netconf-server model from:

=C2=A0 =C2=A0+--rw netconf-server
=C2=A0 =C2=A0 =C2=A0 +--rw listen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw endpoint* [name]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw name=C2=A0 =C2=A0 string =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw (transport)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--:(ssh) {ssh-liste= n}?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw ssh =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0+--rw address=C2=A0 =C2=A0 inet:ip-address
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0+--rw port?=C2=A0 =C2=A0 =C2=A0 inet:port-number
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--:(tls) {tls-liste= n}?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw tls =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0+--rw address=C2=A0 =C2=A0 inet:ip-address
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0+--rw port?=C2=A0 =C2=A0 =C2=A0 inet:port-number


To:

=C2=A0 =C2=A0+--rw netconf-server
=C2=A0 =C2=A0 =C2=A0 +--rw listen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw endpoint* [name]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw name=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0string
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw transport=C2=A0 =C2=A0 enum= eration
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw address=C2=A0 =C2=A0 =C2=A0= inet:ip-address
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw port?=C2=A0 =C2=A0 =C2=A0 = =C2=A0 inet:port-number



The reason I used the first construct was only so that a grouping could be<= br> used under each "transport" choice, which then could "refine= " the port's
default value to the transport-specific value:


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uses listen-per-transport-c= onfig {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0refine port {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0default 830;<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}

Or

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uses listen-per-transport-c= onfig {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0refine port {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0default 6513;=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}



I'm trying again now and still can't find a way to do it.=C2=A0 =C2= =A0What I want,
is something like:


=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf port {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type inet:port-number;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 default {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 830: when "transport =3D=3D = 'ssh'";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6513: when "transport =3D=3D= 'tls'";

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




I did try some wild options, for instance:

=C2=A0 =C2=A0 =C2=A0 grouping port-grouping {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf port {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type inet:port-number;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 }


<snip/>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 uses port-grouping {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 when "transport =3D=3D 'ssh'= ;";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 refine port {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 default 830;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 uses port-grouping {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 when "transport =3D=3D 'tls'= ;";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 refine port {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 default 6513;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }


Which failed:

ietf-netconf-server.yang:178: error: there is already a child node to
"endpoint" at ../ietf-netconf-server.yang:145 with the name "= ;port" defined
at ../ietf-netconf-server.yang:172 (at ../ietf-netconf-server.yang:130)


Any ideas?


Thanks,
Kent


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

--089e0115ee9ceb27bd05060cbd66-- From nobody Wed Oct 22 23:17:50 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8FF91A6F04; Wed, 22 Oct 2014 14:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0gRNAxPSehS; Wed, 22 Oct 2014 14:34:23 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 367621A6F11; Wed, 22 Oct 2014 14:34:21 -0700 (PDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id s9ML2g0r030102; Wed, 22 Oct 2014 14:34:17 -0700 Received: from brmwp-exchub01.corp.brocade.com ([208.47.132.227]) by mx0b-000f0801.pphosted.com with ESMTP id 1q5v85kcj2-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 22 Oct 2014 14:34:17 -0700 Received: from brm-excashub-2.corp.brocade.com (172.16.187.49) by BRMWP-EXCHUB01.corp.brocade.com (172.16.186.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 22 Oct 2014 15:34:04 -0600 Received: from brm-exch-3.corp.brocade.com ([169.254.1.49]) by brm-excashub-2.corp.brocade.com ([172.16.187.74]) with mapi; Wed, 22 Oct 2014 15:34:01 -0600 From: Kiran Agrahara Sreenivasa To: Benoit Claise , Susan Hares , "'Thomas D. Nadeau'" , "'Andy Bierman'" Date: Wed, 22 Oct 2014 15:34:00 -0600 Thread-Topic: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled Thread-Index: Ac/uPHDV6VmzCUSZRhi/QwwN5ARvRwAAyEXA Message-ID: References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> <057901cfee26$754ecc20$5fec6460$@ndzh.com> <54481CE8.808@cisco.com> In-Reply-To: <54481CE8.808@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C051D5C82AA58D49B08200C1A16C643106EDD1EA3EBRMEXCH3corpb_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.28, 0.0.0000 definitions=2014-10-22_07:2014-10-22,2014-10-22,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1410220190 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/eTIYBP0XTnmH-YbLav9ixQJVlGI X-Mailman-Approved-At: Wed, 22 Oct 2014 23:17:48 -0700 Cc: "Rtg-yang-coord@ietf.org" , 'NETMOD Working Group' , "ospf-chairs@tools.ietf.org" , "ops-ads@tools.ietf.org" , "rtg-ads@tools.ietf.org" , 'Farrel Adrian' Subject: Re: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 22 Oct 2014 21:34:29 -0000 --_000_C051D5C82AA58D49B08200C1A16C643106EDD1EA3EBRMEXCH3corpb_ Content-Type: text/plain; charset="us-ascii" +1 -OSPF + ISIS + TE YANG model authors were waiting for this opportunity to discuss the open issues and present an update. Many of those even logged in to the meeting before I had to begrudgingly announce cancelation :( From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Benoit Claise Sent: Wednesday, October 22, 2014 4:09 PM To: Susan Hares; 'Thomas D. Nadeau'; 'Andy Bierman' Cc: Rtg-yang-coord@ietf.org; 'NETMOD Working Group'; ospf-chairs@tools.ietf.org; ops-ads@tools.ietf.org; rtg-ads@tools.ietf.org; 'Farrel Adrian' Subject: Re: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled Dear all, Tom: Acee indicated earlier on the i2rs list (September discussion) that the OSPF yang model was going to be standardized in OSPF. I'm glad we've got the rtg-yang-coord list to sort out these issues. IDR will pick up all BGP related yang modules. A charter addition has been made. IDR will gladly accept input from the netmod WG or hold joint interim session to make this effort go fast. Exactly. The YANG modules should be standardized in the respective WGs. To have good YANG modules, you need: 1. the technology experts, i.e. the respective WG 2. YANG review I don't understand all this fuss about: "oh, but you can't speak about an OSPF module in a NETMOD WG". We want to do what's right by providing YANG review of the documents, nothing else. I don't understand all this fuss about: "oh, but if you speak about one OSPF YANG model, then you must include all the other ones". People who want feedback on their YANG modules are welcome to join. This was the goal. Regards, Benoit The configuration drafts for bgp (draft-zhdankin-netmod-bgp-cfg-00.txt) and the I2rs drafts for bgp (draft-i2rs-hares-bgp-dm-00) have only a 5% functional overlap. I will be releasing a draft that compares these two drafts, and looks at how these drafts fulfill the I2RS BGP use case requirements. IDR will sponsor a design team in IDR to push the rapid development of bgp configuration or bgp i2rs. If you could suggest a few netmod people to help this effort it would help. My understanding of IETF best practices indicate that joint interims need 2 weeks announcement of topics. Sue From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of Thomas D. Nadeau Sent: Wednesday, October 22, 2014 10:35 AM To: Andy Bierman Cc: Rtg-yang-coord@ietf.org; NETMOD Working Group; ospf-chairs@tools.ietf.org; ops-ads@tools.ietf.org; rtg-ads@tools.ietf.org; Benoit Claise; Farrel Adrian Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled No one said that OSPF experts could not attend to provide input. The issue is that OSPF was not doing this. If they want to take over doing all OSPF models, then great, but to date no one was. The agreement in NETMOD (and our charter) is to facilitate the creation of models when WGs don't want to do them, have the expertise to do them, etc... Also, getting the right Yang experts in one place is not going to happen for every WG in the IETF; its just not realistic. I understand that ultimately the WG needs to have consensus, but quick iteration to construct the model surely can happen in a small "design team" fashion, right? And in terms of today's meeting being canceled, really what purpose was that other than to stall/slow-down work? The group that was there to work on the OSPF model was indeed a bunch of folks from OSPF (Acee Lindem for example was on the call). So now since we won't have another interim meeting until after Hawaii, so the next time this group can get together is possibly in Hawaii, but that is probably unlikely as a large number of people are not going to Hawaii. So the net-net is a slowing of progress in this area. Probably not the result the IETF community wants. -Tom On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman > wrote: Hi Adrian, I agree with you. The OSPF WG should be discussing OSPF data models, not the NETMOD WG. The domain experts need to reach consensus on a feature set (and maybe info model) and then get 1 or 2 YANG experts to help translate that to a data model. (Not the other way around -- a room full of YANG experts and 1 or 2 OSPF experts). I also prefer that virtual interim meetings be used to discuss open issues on chartered items, not as an additional forum to promote individual drafts. Andy On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel > wrote: I understand and appreciate your desire to get work done. The rules for IETF virtual interims are neither hard to discover, nor hard to comply with. The rules exist to ensure that people are included in the work, and I am sure that inclusion is what you want. I find it unfortunate that you scheduled a working group meeting to discuss only one of a pair of competing documents on the same topic, that you didn't make the information about the meeting available to the authors of the competing document or to the people who care about the protocol being modelled, and I find it upsetting (yes, I am actually upset) that you decided to discuss in Netmod a document that belongs in the OSPF working group. If, as it surely sounds, you wish that the Netmod working group had a different charter to enable it to take on models for protocols that already have a home in other working groups, then I suggest you need to recharter. But I doubt that your reasoning that [YANG] experts will not go to all the other working groups will carry much weight. Frankly, and without wanting to disrespect the YANG experts, it is easier to understand YANG than it is to understand OSPF. If this were not the case then the Netmod working group would have failed in its design of YANG! Conclusion: You want to work on a YANG model for OSPF. Go to the OSPF working group and discuss it (there are already some threads). Review and comment on the competing document. Try to get agreement between all of the authors of both documents, or try to identify the differences. Work with the chairs of the OSPF working group to advance the work. Adrian > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com] > Sent: 22 October 2014 14:29 > To: Benoit Claise > Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org; > rtg-ads@tools.ietf.org > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled > > > This is hugely disappointing. This is the kind of procedural non-sense has > and IS driving people away from the IETF to other places where this work is going > to get done. The simple effect of such silliness will be a reduction in speed and > quantity of model development. If the goal of the IESG is to slow down the > velocity of model development and creation, then this approach is perfect. > > For the record, the interim NETMOD meeting cadence has one meeting > focused on Yang and the other on modeling; is not NETMOD-specific per say, but > to promote model creation because no other bi-weekly forum exists to do so. It > is also a place to bring in non-IETF work such as the work done in ODL, other open > source, or just the public community that has explicitly wanted to avoid the IETF. > We have found it a convenient and fruitful place to discuss, and actually *build* > models - regardless of their ultimate WG home. The simple reason: its a single > place for many of the experts to gather. I think you will find it very difficult to get > those people onto a per-WG call every other week. > > I hope the IESG considers this approach carefully because I do not think it > will have the affect the larger IETF community is interested in. > > --Tom > > > > > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise > wrote: > > > > Dear all, > > > > Today NETMOD interim meeting is canceled. > > > > I received some pushbacks from the routing ADs, on the ground that: > > 1. This interim appears to be meeting to discuss a non-WG draft for which there > is no milestone in the working group and for which there is an obvious home > outside the working group. > > 2. The agenda was not announced a week in advance on the IETF announce list > as is required > > > > Regards, Benoit > > > > _______________________________________________ > > Rtg-yang-coord mailing list > > Rtg-yang-coord@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --_000_C051D5C82AA58D49B08200C1A16C643106EDD1EA3EBRMEXCH3corpb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= +1 –OSPF + ISIS + TE YANG model authors were waiting for this = opportunity to discuss the open issues and present an update.

 

Many of those even logged in to the meeting before I had t= o begrudgingly announce cancelation L

<= p class=3DMsoNormal>

 

From: netmod [mailto:netmod-bounces@ietf.org] O= n Behalf Of Benoit Claise
Sent: Wednesday, October 22, 2014 4= :09 PM
To: Susan Hares; 'Thomas D. Nadeau'; 'Andy Bierman'
= Cc: Rtg-yang-coord@ietf.org; 'NETMOD Working Group'; ospf-chairs@tools.= ietf.org; ops-ads@tools.ietf.org; rtg-ads@tools.ietf.org; 'Farrel Adrian'Subject: Re: [netmod] [Rtg-yang-coord] NETMOD interim meeting canc= eled

 

Dear all,

To= m:

 

Acee indicated earlier on the i2rs list (= September discussion) that the OSPF yang model was going to be standardized= in OSPF.  I’m glad we’ve got the rtg-yang-coord list to s= ort out these issues.

&nb= sp;

IDR will pick up all B= GP related yang modules.  A charter addition has been made.  IDR = will gladly accept input from the netmod WG or hold joint interim session t= o make this effort go fast. 

Exactly. The YANG modules should be standardized in the resp= ective WGs.
To have good YANG modules, you need:
1. the technology ex= perts, i.e. the respective WG
2. YANG review

I don't understand a= ll this fuss about: "oh, but you can't speak about an OSPF module in a= NETMOD WG".
We want to do what's right by providing YANG review of= the documents, nothing else.

I don't understand all this fuss about= : "oh, but if you speak about one OSPF YANG model, then you must inclu= de all the other ones".
People who want feedback on their YANG modu= les are welcome to join. This was the goal.

Regards, Benoit

<= br>

The configuration drafts for bgp (draft-zhdan= kin-netmod-bgp-cfg-00.txt) and the I2rs drafts for bgp (draft-i2rs-hares-bg= p-dm-00) have only a 5% functional overlap.  I will be releasing a dra= ft that compares these two drafts, and looks at how these drafts fulfill th= e I2RS BGP use case requirements.

 

IDR will s= ponsor a design team in IDR to push the rapid development of bgp configurat= ion or bgp i2rs.  If you could suggest a few netmod people to help thi= s effort it would help.  

 

My understandi= ng of IETF best practices indicate that joint interims need 2 weeks announc= ement of topics.

 

Sue

<= p class=3DMsoNormal> 

From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of = Thomas D. Nadeau
Sent: Wednesday, October 22, 2014 10:35 AM
To: Andy Bierman
Cc: Rtg-yang-coord@ietf.org; NETMOD Working Group; ospf-chairs@tools.ietf.org; ops-ads@tools.ietf.org; rtg-ads@tools.ietf.org; Benoit Claise; Farrel Adria= n
Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting c= anceled

 

 

      &nb= sp;     No one said that OSPF experts could not = attend to provide input.   The issue is that OSPF was not doing this. = If they want to take over doing all OSPF models, then great, but to date no= one was.  The agreement in NETMOD (and our charter) is to facilitate = the creation of models when WGs don’t want to do them, have the exper= tise to do them, etc…  Also, getting the right Yang experts in o= ne place is not going to happen for every WG in the IETF; its just not real= istic.  I understand that ultimately the WG needs to have consensus, b= ut quick iteration to construct the model surely can happen in a small R= 20;design team” fashion, right?

 

           = ; And in terms of today’s meeting being canceled, really what = purpose was that other than to stall/slow-down work?  The group that w= as there to work on the OSPF model was indeed a bunch of folks from OSPF (A= cee Lindem for example was on the call).  So now since we won’t = have another interim meeting until after Hawaii, so the next time this grou= p can get together is possibly in Hawaii, but that is probably unlikely as = a large number of people are not going to Hawaii.  So the net-net is a= slowing of progress in this area.  Probably not the result the IETF c= ommunity wants.

 

  =           —Tom

 

 

=  

On Oct 22, 2014:10:18 AM, at 10:18 AM, = Andy Bierman <andy@yumaworks.com> wrote:

 

Hi Adrian,

=

not the NETMOD WG. The domain experts need to rea= ch consensus

on a feature set= (and maybe info model) and then get 1 or 2 YANG experts to

<= /div>

help translate that to a data model. (Not th= e other way around -- a room

= full of YANG experts and 1 or 2 OSPF experts).

 

I al= so prefer that virtual interim meetings be used to discuss open issues=

on chartered items, not as an add= itional forum to promote individual drafts.

 

 <= o:p>

Andy

 

 

On Wed, Oct 22, 20= 14 at 6:48 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:

I understand and appreciate your desire to get work done.

= The rules for IETF virtual interims are neither hard to discover, nor hard = to
comply with. The rules exist to ensure that people are included in th= e work, and
I am sure that inclusion is what you want.

I find it = unfortunate that you scheduled a working group meeting to discuss only
o= ne of a pair of competing documents on the same topic, that you didn't make= the
information about the meeting available to the authors of the compe= ting document
or to the people who care about the protocol being modelle= d, and I find it
upsetting (yes, I am actually upset) that you decided t= o discuss in Netmod a
document that belongs in the OSPF working group.
If, as it surely sounds, you wish that the Netmod working group had a= different
charter to enable it to take on models for protocols that alr= eady have a home in
other working groups, then I suggest you need to rec= harter. But I doubt that
your reasoning that [YANG] experts will not go = to all the other working groups
will carry much weight. Frankly, and wit= hout wanting to disrespect the YANG
experts, it is easier to understand = YANG than it is to understand OSPF. If this
were not the case then the N= etmod working group would have failed in its design
of YANG!

Conc= lusion:
You want to work on a YANG model for OSPF. Go to the OSPF workin= g group and
discuss it (there are already some threads). Review and comm= ent on the competing
document. Try to get agreement between all of the a= uthors of both documents, or
try to identify the differences. Work with = the chairs of the OSPF working group
to advance the work.

Adrian<= br>
> -----Original Message-----
> From: Thomas D. Nadeau [mail= to:tnadeau@lucidvision.com]<= br>> Sent: 22 October 2014 14:29
> To: Benoit Claise
> Cc: N= ETMOD Working Group; Rtg-yang-co= ord@ietf.org; ops-ads@tools.i= etf.org;
> rtg-ads@tool= s.ietf.org
> Subject: Re: [Rtg-yang-coord] NETMOD interim meeting= canceled
>
>
>       This is hugely = disappointing. This is the kind of procedural non-sense
has
> and = IS driving people away from the IETF to other places where this work is
= going
> to get done. The simple effect of such silliness will be a re= duction in speed
and
> quantity of model development.  If the= goal of the IESG is to slow down the
> velocity of model development= and creation, then this approach is perfect.
>
>    =    For the record, the interim NETMOD meeting cadence has one mee= ting
> focused on Yang and the other on modeling; is not NETMOD-speci= fic per say, but
> to promote model creation because no other bi-week= ly forum exists to do so. It
> is also a place to bring in non-IETF w= ork such as the work done in ODL, other
open
> source, or just the= public community that has explicitly wanted to avoid the
IETF.
> = We have found it a convenient and fruitful place to discuss, and actually*build*
> models - regardless of their ultimate WG home.  The = simple reason: its a
single
> place for many of the experts to gat= her. I think you will find it very
difficult to get
> those people= onto a per-WG call every other week.
>
>      &= nbsp;I hope the IESG considers this approach carefully because I do not thi= nk
it
> will have the affect the larger IETF community is interest= ed in.
>
>       --Tom
>
>
&= gt;
> > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise <bclaise@cisco.com>
wrote:
&g= t; >
> > Dear all,
> >
> > Today NETMOD inter= im meeting is canceled.
> >
> > I received some pushbacks= from the routing ADs, on the ground that:
> > 1. This interim app= ears to be meeting to discuss a non-WG draft for which
there
> is = no milestone in the working group and for which there is an obvious home> outside the working group.
> > 2. The agenda was not announc= ed a week in advance on the IETF announce list
> as is required
&g= t; >
> > Regards, Benoit
> >
> > ____________= ___________________________________
> > Rtg-yang-coord mailing lis= t
> > Rtg-yang-coord@ie= tf.org
> > https://www.ietf.org/mailman/listinfo/rtg-y= ang-coord
> >

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

 

 

<= /div>

 

= --_000_C051D5C82AA58D49B08200C1A16C643106EDD1EA3EBRMEXCH3corpb_-- From nobody Thu Oct 23 00:00:33 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02B6F1A8906 for ; Thu, 23 Oct 2014 00:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, 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 ncfdlsiwBN3R for ; Thu, 23 Oct 2014 00:00: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 530401A88D8 for ; Thu, 23 Oct 2014 00:00:29 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6EE94E4F; Thu, 23 Oct 2014 09:00: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 X1gj--TvPtST; Thu, 23 Oct 2014 09:00:17 +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, 23 Oct 2014 09:00:22 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id BCBFF20037; Thu, 23 Oct 2014 09:00:22 +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 USPK8Lb386k8; Thu, 23 Oct 2014 09:00: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 C1CF720035; Thu, 23 Oct 2014 09:00:01 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B27502F0B1AB; Thu, 23 Oct 2014 09:00:01 +0200 (CEST) Date: Thu, 23 Oct 2014 09:00:01 +0200 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20141023070001.GB96182@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: http://mailarchive.ietf.org/arch/msg/netmod/soEIUn_jJYAbHPVyDRKFjJe_sFA Cc: "netmod@ietf.org" Subject: Re: [netmod] inability to 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, 23 Oct 2014 07:00:32 -0000 Kent, please take a look at the discussion in this I-D: http://www.ietf.org/id/draft-schoenw-netmod-yang-pattern-00.txt I believe having a choice is a good thing and it is a feature to keep transport specific leafs separate. /js On Thu, Oct 23, 2014 at 12:14:45AM +0000, Kent Watsen wrote: > > I'm trying to flatten the netconf-server model from: > > +--rw netconf-server > +--rw listen > +--rw endpoint* [name] > +--rw name string > +--rw (transport) > +--:(ssh) {ssh-listen}? > | +--rw ssh > | +--rw address inet:ip-address > | +--rw port? inet:port-number > +--:(tls) {tls-listen}? > +--rw tls > +--rw address inet:ip-address > +--rw port? inet:port-number > > > To: > > +--rw netconf-server > +--rw listen > +--rw endpoint* [name] > +--rw name string > +--rw transport enumeration > +--rw address inet:ip-address > +--rw port? inet:port-number > > > > The reason I used the first construct was only so that a grouping could be > used under each "transport" choice, which then could "refine" the port's > default value to the transport-specific value: > > > uses listen-per-transport-config { > refine port { > default 830; > } > } > > Or > > uses listen-per-transport-config { > refine port { > default 6513; > } > } > > > > I'm trying again now and still can't find a way to do it. What I want, > is something like: > > > leaf port { > type inet:port-number; > default { > 830: when "transport == 'ssh'"; > 6513: when "transport == 'tls'"; > > } > } > > > > > I did try some wild options, for instance: > > grouping port-grouping { > leaf port { > type inet:port-number; > } > } > > > > uses port-grouping { > when "transport == 'ssh'"; > refine port { > default 830; > } > } > uses port-grouping { > when "transport == 'tls'"; > refine port { > default 6513; > } > } > > > Which failed: > > ietf-netconf-server.yang:178: error: there is already a child node to > "endpoint" at ../ietf-netconf-server.yang:145 with the name "port" defined > at ../ietf-netconf-server.yang:172 (at ../ietf-netconf-server.yang:130) > > > Any ideas? > > > Thanks, > Kent > > > _______________________________________________ > 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 Oct 23 00:13:14 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A37401A890D for ; Thu, 23 Oct 2014 00:13:12 -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 HqgVDVb6ax6j for ; Thu, 23 Oct 2014 00:13:11 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id EFB8D1A8906 for ; Thu, 23 Oct 2014 00:13:10 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 71AEA1280096; Thu, 23 Oct 2014 09:13:09 +0200 (CEST) Date: Thu, 23 Oct 2014 09:13:09 +0200 (CEST) Message-Id: <20141023.091309.1845717459816913610.mbj@tail-f.com> To: kwatsen@juniper.net 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: http://mailarchive.ietf.org/arch/msg/netmod/AHQCPBkZNzCNNav1rafflzSPcpE Cc: netmod@ietf.org Subject: Re: [netmod] inability to X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 23 Oct 2014 07:13:12 -0000 Kent Watsen wrote: > > I'm trying to flatten the netconf-server model from: > > +--rw netconf-server > +--rw listen > +--rw endpoint* [name] > +--rw name string > +--rw (transport) > +--:(ssh) {ssh-listen}? > | +--rw ssh > | +--rw address inet:ip-address > | +--rw port? inet:port-number > +--:(tls) {tls-listen}? > +--rw tls > +--rw address inet:ip-address > +--rw port? inet:port-number > > > To: > > +--rw netconf-server > +--rw listen > +--rw endpoint* [name] > +--rw name string > +--rw transport enumeration > +--rw address inet:ip-address > +--rw port? inet:port-number I don't think this is a good idea. Transports are different and may have very different configuration parameters; even if they don't have that currently we want to design for future extensibility, both in what we configure per protocol and for future protocols. (This pattern is described in draft-schoenw-netmod-yang-pattern-00; we should also discuss your suggested design there). > The reason I used the first construct was only so that a grouping could be > used under each "transport" choice, which then could "refine" the port's > default value to the transport-specific value: > > > uses listen-per-transport-config { > refine port { > default 830; > } > } > > Or > > uses listen-per-transport-config { > refine port { > default 6513; > } > } > > > > I'm trying again now and still can't find a way to do it. What I want, > is something like: > > > leaf port { > type inet:port-number; > default { > 830: when "transport == 'ssh'"; > 6513: when "transport == 'tls'"; > > } > } Not possible. defaults in YANG are static. If you want something else you have to describe it in text. (This one does come up every now and then. Variants include "default ref" where the default value is configured in some other static leaf, e.g. "if the timeout isn't set for a particular instance, use the globally defined value: "default-ref ../../global-params/timeout", or even dynamic default refs such as "if the timeout isn't set for a particualr instance, use the value from the configured profile") /martin From nobody Thu Oct 23 00:44:15 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E877D1A8907; Thu, 23 Oct 2014 00:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 xSpzfIODn1-a; Thu, 23 Oct 2014 00:44:10 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7D031A88FE; Thu, 23 Oct 2014 00:44:09 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 0764C3243D1; Thu, 23 Oct 2014 09:44:08 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.30]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id ACDE3238048; Thu, 23 Oct 2014 09:44:07 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.230]) by OPEXCLILH02.corporate.adroot.infra.ftgroup ([10.114.31.30]) with mapi id 14.03.0195.001; Thu, 23 Oct 2014 09:44:03 +0200 From: To: Susan Hares , 'Benoit Claise' Thread-Topic: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled Thread-Index: AQHP7ikeXWdPBW/eoUydZkWpY8T+I5w9TSww Date: Thu, 23 Oct 2014 07:44:03 +0000 Message-ID: <23211_1414050247_5448B1C7_23211_523_2_9E32478DFA9976438E7A22F69B08FF92145304@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <19590_1413985494_5447B4D6_19590_2565_1_9E32478DFA9976438E7A22F69B08FF92142C87@OPEXCLILM34.corporate.adroot.infra.ftgroup> <05f101cfee29$1b45e8f0$51d1bad0$@ndzh.com> In-Reply-To: <05f101cfee29$1b45e8f0$51d1bad0$@ndzh.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.10.8.100919 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/-nnV0-c38IEe70ytp892fPGWkl8 Cc: "Rtg-yang-coord@ietf.org" , "ops-ads@tools.ietf.org" , 'NETMOD Working Group' , "rtg-ads@tools.ietf.org" Subject: Re: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 23 Oct 2014 07:44:13 -0000 Susan, I completely agree that bits and bytes in the model should be discussed in = the protocol WG but for modeling, limitations, and all stuffs related to Ya= ng, it's still good to discuss it in Netmod. Best Regards, Stephane -----Original Message----- From: Susan Hares [mailto:shares@ndzh.com]=20 Sent: Wednesday, October 22, 2014 20:51 To: LITKOWSKI Stephane SCE/IBNF; 'Benoit Claise' Cc: Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org; 'NETMOD Working Group'= ; rtg-ads@tools.ietf.org Subject: RE: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled Stephane:=20 I think it is important to receive both the wisdom from the netmod WG and t= he protocol WG. I find that there are yang model consistencies and limitat= ions that require aid in the yang models I've worked on. This is especiall= y true for the state and ephemeral state.=20 Sue=20 -----Original Message----- From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of = stephane.litkowski@orange.com Sent: Wednesday, October 22, 2014 9:45 AM To: Benoit Claise Cc: Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org; NETMOD Working Group; = rtg-ads@tools.ietf.org Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled Hi, I also agree that this is a bad idea. I thought that IETF willing and espec= ially yours, Benoit, was to speed up availability of standard models. The process of having small teams working with weekly calls works almost go= od but we still have some issue that are both technical (dedicated to the t= opic addressed by the model) and also YANG writing, model consistencies ... that requires discussion, and as often mailing list is not as good as meeti= ngs (that's why the proposal of small teams was done). At the present time, I personally support the initiative of having interim = meetings in Netmod to discuss proposed Yang models : this will ensure consi= stency between models and will help to solve global issues in modeling. It's just the starting of Yang modeling, leaving only Yang models within ho= me WG (ISIS for my point of view) would be, IMO, a very bad idea and will f= or sure slow down the availability of standards ... and I also think that i= t may discourage people to work on because of the added overhead. It was just my opinion ... Best Regards, Stephane -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Thomas D. Nadeau Sent: Wednesday, October 22, 2014 15:29 To: Benoit Claise Cc: Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org; NETMOD Working Group; = rtg-ads@tools.ietf.org Subject: Re: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled This is hugely disappointing. This is the kind of procedural non-sense has= and IS driving people away from the IETF to other places where this work i= s going to get done. The simple effect of such silliness will be a reductio= n in speed and quantity of model development. If the goal of the IESG is t= o slow down the velocity of model development and creation, then this appro= ach is perfect. For the record, the interim NETMOD meeting cadence has one meeting focused= on Yang and the other on modeling; is not NETMOD-specific per say, but to = promote model creation because no other bi-weekly forum exists to do so. It= is also a place to bring in non-IETF work such as the work done in ODL, ot= her open source, or just the public community that has explicitly wanted to= avoid the IETF. We have found it a convenient and fruitful place to discu= ss, and actually *build* models - regardless of their ultimate WG home. Th= e simple reason: its a single place for many of the experts to gather. I th= ink you will find it very difficult to get those people onto a per-WG call = every other week.=20=20 I hope the IESG considers this approach carefully because I do not think i= t will have the affect the larger IETF community is interested in. --Tom > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise wrote: >=20 > Dear all, >=20 > Today NETMOD interim meeting is canceled. >=20 > I received some pushbacks from the routing ADs, on the ground that: > 1. This interim appears to be meeting to discuss a non-WG draft for=20 > which there is no milestone in the working group and for which there is an obviou= s home outside the working group. > 2. The agenda was not announced a week in advance on the IETF announce=20 > list as is required >=20 > Regards, Benoit >=20 > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord >=20 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ____________________________________________________________________________ _____________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, veuillez= le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ Rtg-yang-coord mailing list Rtg-yang-coord@ietf.org https://www.ietf.org/mailman/listinfo/rtg-yang-coord ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Oct 23 01:32:40 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69D6F1A1A3D; Thu, 23 Oct 2014 01:32:36 -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 KYg7WfeJny7w; Thu, 23 Oct 2014 01:32:34 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACACF1A6F4C; Thu, 23 Oct 2014 01:32:33 -0700 (PDT) Received: from [192.168.1.108] (unknown [195.113.220.254]) by mail.nic.cz (Postfix) with ESMTPSA id 7B83313F8BA; Thu, 23 Oct 2014 10:32:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1414053150; bh=UdxxlTJ6/QOUevUTne/40FsYteZSqu1L7knCI6oMJy4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=SyZliQXTr6SxzjG8nouFuytnaIertivp/ImUGQaHmuhSdLNX3dlZxhNPX27cSBULh 5/Lt45bu8iFAaaJ8C/sZ6NYedU6e/gXlqPU1Bttlb4AuxdXEA83EL8X2to0oTydl12 SbNcu4+vzFN7i0998WESUkWOLYXQAeP7OzQL5N+s= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <23211_1414050247_5448B1C7_23211_523_2_9E32478DFA9976438E7A22F69B08FF92145304@OPEXCLILM34.corporate.adroot.infra.ftgroup> Date: Thu, 23 Oct 2014 10:32:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <711B5DC5-2C6E-4CB4-B3B5-C61FEA1FBD7A@nic.cz> References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <19590_1413985494_5447B4D6_19590_2565_1_9E32478DFA9976438E7A22F69B08FF92142C87@OPEXCLILM34.corporate.adroot.infra.ftgroup> <05f101cfee29$1b45e8f0$51d1bad0$@ndzh.com> <23211_1414050247_5448B1C7_23211_523_2_9E32478DFA9976438E7A22F69B08FF92145304@OPEXCLILM34.corporate.adroot.infra.ftgroup> To: stephane.litkowski@orange.com X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/RlZp-gJV3czb-bz1hdgN5DrERr4 Cc: "Rtg-yang-coord@ietf.org" , NETMOD Working Group , "ops-ads@tools.ietf.org" , "rtg-ads@tools.ietf.org" , Susan Hares Subject: Re: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 23 Oct 2014 08:32:36 -0000 On 23 Oct 2014, at 09:44, = wrote: > Susan, >=20 > I completely agree that bits and bytes in the model should be = discussed in the protocol WG but for modeling, limitations, and all = stuffs related to Yang, it's still good to discuss it in Netmod. >=20 Actually, there is also the group of =93YANG Doctors=94, and it might be = more appropriate to discuss the YANG parts with them and not in the = NETMOD group. At any rate, I think we should clarify (and document) the = workflow for the development of YANG modules whose primary home is = outside the NETMOD working group. This email thread proves it is needed. Lada > Best Regards, >=20 > Stephane >=20 >=20 > -----Original Message----- > From: Susan Hares [mailto:shares@ndzh.com]=20 > Sent: Wednesday, October 22, 2014 20:51 > To: LITKOWSKI Stephane SCE/IBNF; 'Benoit Claise' > Cc: Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org; 'NETMOD Working = Group'; rtg-ads@tools.ietf.org > Subject: RE: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled >=20 > Stephane:=20 >=20 > I think it is important to receive both the wisdom from the netmod WG = and the protocol WG. I find that there are yang model consistencies and = limitations that require aid in the yang models I've worked on. This is = especially true for the state and ephemeral state.=20 >=20 > Sue=20 >=20 > -----Original Message----- > From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On = Behalf Of stephane.litkowski@orange.com > Sent: Wednesday, October 22, 2014 9:45 AM > To: Benoit Claise > Cc: Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org; NETMOD Working = Group; rtg-ads@tools.ietf.org > Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled >=20 > Hi, >=20 > I also agree that this is a bad idea. I thought that IETF willing and = especially yours, Benoit, was to speed up availability of standard = models. > The process of having small teams working with weekly calls works = almost good but we still have some issue that are both technical = (dedicated to the topic addressed by the model) and also YANG writing, = model consistencies ... > that requires discussion, and as often mailing list is not as good as = meetings (that's why the proposal of small teams was done). >=20 > At the present time, I personally support the initiative of having = interim meetings in Netmod to discuss proposed Yang models : this will = ensure consistency between models and will help to solve global issues = in modeling. > It's just the starting of Yang modeling, leaving only Yang models = within home WG (ISIS for my point of view) would be, IMO, a very bad = idea and will for sure slow down the availability of standards ... and I = also think that it may discourage people to work on because of the added = overhead. >=20 > It was just my opinion ... >=20 > Best Regards, >=20 > Stephane >=20 > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Thomas D. = Nadeau > Sent: Wednesday, October 22, 2014 15:29 > To: Benoit Claise > Cc: Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org; NETMOD Working = Group; rtg-ads@tools.ietf.org > Subject: Re: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled >=20 >=20 > This is hugely disappointing. This is the kind of procedural = non-sense has and IS driving people away from the IETF to other places = where this work is going to get done. The simple effect of such = silliness will be a reduction in speed and quantity of model = development. If the goal of the IESG is to slow down the velocity of = model development and creation, then this approach is perfect. >=20 > For the record, the interim NETMOD meeting cadence has one = meeting focused on Yang and the other on modeling; is not = NETMOD-specific per say, but to promote model creation because no other = bi-weekly forum exists to do so. It is also a place to bring in non-IETF = work such as the work done in ODL, other open source, or just the public = community that has explicitly wanted to avoid the IETF. We have found = it a convenient and fruitful place to discuss, and actually *build* = models - regardless of their ultimate WG home. The simple reason: its a = single place for many of the experts to gather. I think you will find it = very difficult to get those people onto a per-WG call every other week. =20= >=20 > I hope the IESG considers this approach carefully because I do = not think it will have the affect the larger IETF community is = interested in. >=20 > --Tom >=20 >=20 >=20 >> On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise = > wrote: >>=20 >> Dear all, >>=20 >> Today NETMOD interim meeting is canceled. >>=20 >> I received some pushbacks from the routing ADs, on the ground that: >> 1. This interim appears to be meeting to discuss a non-WG draft for=20= >> which > there is no milestone in the working group and for which there is an = obvious home outside the working group. >> 2. The agenda was not announced a week in advance on the IETF = announce=20 >> list as is required >>=20 >> Regards, Benoit >>=20 >> _______________________________________________ >> Rtg-yang-coord mailing list >> Rtg-yang-coord@ietf.org >> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >>=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 > = __________________________________________________________________________= __ > _____________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc pas etre diffuses, = exploites ou copies sans autorisation. Si vous avez recu ce message par = erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les = pieces jointes. Les messages electroniques etant susceptibles = d'alteration, Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; they should not be = distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord >=20 >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Oct 23 02:20:17 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC2DF1A8968; Thu, 23 Oct 2014 02:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 qtZLSHrRcf3t; Thu, 23 Oct 2014 02:20:11 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A6D71A8969; Thu, 23 Oct 2014 02:20:11 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 6B1B51B82B2; Thu, 23 Oct 2014 11:20:09 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 38AFC1580A1; Thu, 23 Oct 2014 11:20:09 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.230]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0195.001; Thu, 23 Oct 2014 11:20:08 +0200 From: To: Ladislav Lhotka Thread-Topic: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled Thread-Index: AQHP7pvkyJwDL5Pz9kCYeFdlN0MGIJw9Z0eg Date: Thu, 23 Oct 2014 09:20:08 +0000 Message-ID: <21811_1414056009_5448C849_21811_1363_1_9E32478DFA9976438E7A22F69B08FF921465E4@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <19590_1413985494_5447B4D6_19590_2565_1_9E32478DFA9976438E7A22F69B08FF92142C87@OPEXCLILM34.corporate.adroot.infra.ftgroup> <05f101cfee29$1b45e8f0$51d1bad0$@ndzh.com> <23211_1414050247_5448B1C7_23211_523_2_9E32478DFA9976438E7A22F69B08FF92145304@OPEXCLILM34.corporate.adroot.infra.ftgroup> <711B5DC5-2C6E-4CB4-B3B5-C61FEA1FBD7A@nic.cz> In-Reply-To: <711B5DC5-2C6E-4CB4-B3B5-C61FEA1FBD7A@nic.cz> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.9.24.114819 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/xtEhcZzvNDU5f4k5nH9xWgfV3Eo Cc: "Rtg-yang-coord@ietf.org" , NETMOD Working Group , "ops-ads@tools.ietf.org" , "rtg-ads@tools.ietf.org" , Susan Hares Subject: Re: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 23 Oct 2014 09:20:15 -0000 > At any rate, I think we should clarify (and document) the workflow for th= e development of YANG modules Right, currently, as modeling is just starting, there is a lack of guidelin= es that's why more babysitting is needed at this time. But it's hard to def= ine guidelines now, without gathering experiences from Yang writing people. -----Original Message----- From: Ladislav Lhotka [mailto:lhotka@nic.cz]=20 Sent: Thursday, October 23, 2014 10:33 To: LITKOWSKI Stephane SCE/IBNF Cc: Susan Hares; Benoit Claise; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf= .org; NETMOD Working Group; rtg-ads@tools.ietf.org Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled On 23 Oct 2014, at 09:44, wrote: > Susan, >=20 > I completely agree that bits and bytes in the model should be discussed i= n the protocol WG but for modeling, limitations, and all stuffs related to = Yang, it's still good to discuss it in Netmod. >=20 Actually, there is also the group of "YANG Doctors", and it might be more a= ppropriate to discuss the YANG parts with them and not in the NETMOD group.= At any rate, I think we should clarify (and document) the workflow for the= development of YANG modules whose primary home is outside the NETMOD worki= ng group. This email thread proves it is needed. Lada > Best Regards, >=20 > Stephane >=20 >=20 > -----Original Message----- > From: Susan Hares [mailto:shares@ndzh.com] > Sent: Wednesday, October 22, 2014 20:51 > To: LITKOWSKI Stephane SCE/IBNF; 'Benoit Claise' > Cc: Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org; 'NETMOD Working=20 > Group'; rtg-ads@tools.ietf.org > Subject: RE: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled >=20 > Stephane:=20 >=20 > I think it is important to receive both the wisdom from the netmod WG and= the protocol WG. I find that there are yang model consistencies and limit= ations that require aid in the yang models I've worked on. This is especia= lly true for the state and ephemeral state.=20 >=20 > Sue >=20 > -----Original Message----- > From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On=20 > Behalf Of stephane.litkowski@orange.com > Sent: Wednesday, October 22, 2014 9:45 AM > To: Benoit Claise > Cc: Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org; NETMOD Working=20 > Group; rtg-ads@tools.ietf.org > Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled >=20 > Hi, >=20 > I also agree that this is a bad idea. I thought that IETF willing and esp= ecially yours, Benoit, was to speed up availability of standard models. > The process of having small teams working with weekly calls works almost = good but we still have some issue that are both technical (dedicated to the= topic addressed by the model) and also YANG writing, model consistencies .= .. > that requires discussion, and as often mailing list is not as good as mee= tings (that's why the proposal of small teams was done). >=20 > At the present time, I personally support the initiative of having interi= m meetings in Netmod to discuss proposed Yang models : this will ensure con= sistency between models and will help to solve global issues in modeling. > It's just the starting of Yang modeling, leaving only Yang models within = home WG (ISIS for my point of view) would be, IMO, a very bad idea and will= for sure slow down the availability of standards ... and I also think that= it may discourage people to work on because of the added overhead. >=20 > It was just my opinion ... >=20 > Best Regards, >=20 > Stephane >=20 > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Thomas D.=20 > Nadeau > Sent: Wednesday, October 22, 2014 15:29 > To: Benoit Claise > Cc: Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org; NETMOD Working=20 > Group; rtg-ads@tools.ietf.org > Subject: Re: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled >=20 >=20 > This is hugely disappointing. This is the kind of procedural non-sense h= as and IS driving people away from the IETF to other places where this work= is going to get done. The simple effect of such silliness will be a reduct= ion in speed and quantity of model development. If the goal of the IESG is= to slow down the velocity of model development and creation, then this app= roach is perfect. >=20 > For the record, the interim NETMOD meeting cadence has one meeting focus= ed on Yang and the other on modeling; is not NETMOD-specific per say, but t= o promote model creation because no other bi-weekly forum exists to do so. = It is also a place to bring in non-IETF work such as the work done in ODL, = other open source, or just the public community that has explicitly wanted = to avoid the IETF. We have found it a convenient and fruitful place to dis= cuss, and actually *build* models - regardless of their ultimate WG home. = The simple reason: its a single place for many of the experts to gather. I = think you will find it very difficult to get those people onto a per-WG cal= l every other week.=20=20 >=20 > I hope the IESG considers this approach carefully because I do not think= it will have the affect the larger IETF community is interested in. >=20 > --Tom >=20 >=20 >=20 >> On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise=20 >> > wrote: >>=20 >> Dear all, >>=20 >> Today NETMOD interim meeting is canceled. >>=20 >> I received some pushbacks from the routing ADs, on the ground that: >> 1. This interim appears to be meeting to discuss a non-WG draft for=20 >> which > there is no milestone in the working group and for which there is an obvi= ous home outside the working group. >> 2. The agenda was not announced a week in advance on the IETF=20 >> announce list as is required >>=20 >> Regards, Benoit >>=20 >> _______________________________________________ >> Rtg-yang-coord mailing list >> Rtg-yang-coord@ietf.org >> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >>=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 > ______________________________________________________________________ > ______ _____________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc pas etre diffuses, exploites o= u copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. = Les messages electroniques etant susceptibles d'alteration, Orange decline = toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; they should not be distributed, us= ed or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord >=20 >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Oct 23 08:22:39 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B241AC41F for ; Thu, 23 Oct 2014 08:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 TaAypKg4TANV for ; Thu, 23 Oct 2014 08:22:24 -0700 (PDT) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79E281A8F49 for ; Thu, 23 Oct 2014 08:21:48 -0700 (PDT) Received: by mail-qa0-f54.google.com with SMTP id i13so825217qae.27 for ; Thu, 23 Oct 2014 08:21:47 -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=82eCh+Hl9buOysJTV32YxrH1/fXYkaB7/bgqucSZSzg=; b=SEZDMb1L44WeLatdgGTEZJKvzN0Yy5OABdwoJKhURHnJFlAWJyPdtNhhif5DPc00s0 OeYCY1txdoksKY2BCc1O87XHYsx9r8KxFOEMO9neaEh2xZW/RMDBht2uGReeuz1WrwQM M1sjex6kcZ8WfI0y0Fegjd5X35T5u6yR88D9CKtdLfCbFa74IlsAGLi40RtFnYWs768f GtrSycej7YlBfhdokIiymxaHLFQx7axx8SxhszlbOw3LxsZNly+792r5ScJ4s5NJ+04s +uHtEH+avrpIJIqiNwq6KI4L3vrwizfIthf5YKeJSLRWhWl22u7mMbshhFRAPoBK5YGT hnEQ== X-Gm-Message-State: ALoCoQkXVoG/S4JINN159IuUhKfa8R9B3WlygFqU0qmqztETqtxdo60S4mAy3CzBfxoAZidypnSV MIME-Version: 1.0 X-Received: by 10.140.34.102 with SMTP id k93mr7880765qgk.21.1414077707608; Thu, 23 Oct 2014 08:21:47 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Thu, 23 Oct 2014 08:21:47 -0700 (PDT) In-Reply-To: <54481CE8.808@cisco.com> References: <5447AE27.7060408@cisco.com> <5A80916B-D586-4D2F-B682-471B9211103E@lucidvision.com> <026001cfedfe$ee5a5fd0$cb0f1f70$@olddog.co.uk> <057901cfee26$754ecc20$5fec6460$@ndzh.com> <54481CE8.808@cisco.com> Date: Thu, 23 Oct 2014 08:21:47 -0700 Message-ID: From: Andy Bierman To: Benoit Claise Content-Type: multipart/alternative; boundary=001a11c0d2d4729cd50506189f1f Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/L4QFmG1pcSML99fuZF69gfKT4qo Cc: Rtg-yang-coord@ietf.org, NETMOD Working Group , ospf-chairs@tools.ietf.org, ops-ads@tools.ietf.org, rtg-ads@tools.ietf.org, Farrel Adrian , Susan Hares Subject: Re: [netmod] [Rtg-yang-coord] NETMOD interim meeting canceled X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 23 Oct 2014 15:22:30 -0000 --001a11c0d2d4729cd50506189f1f Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 22, 2014 at 2:08 PM, Benoit Claise wrote: > Dear all, > > Tom: > > > > Acee indicated earlier on the i2rs list (September discussion) that the > OSPF yang model was going to be standardized in OSPF. I'm glad we've got > the rtg-yang-coord list to sort out these issues. > > > > IDR will pick up all BGP related yang modules. A charter addition has > been made. IDR will gladly accept input from the netmod WG or hold joint > interim session to make this effort go fast. > > Exactly. The YANG modules should be standardized in the respective WGs. > To have good YANG modules, you need: > 1. the technology experts, i.e. the respective WG > 2. YANG review > > I don't understand all this fuss about: "oh, but you can't speak about an > OSPF module in a NETMOD WG". > We want to do what's right by providing YANG review of the documents, > nothing else. > There is a difference between discussing a YANG module wrt/ its usage of YANG language constructs, and discussing a module wrt/ the proper set of knobs for a particular protocol (or feature). My objections are to the latter discussion. We saw with the ietf-routing module that wide review from routing experts happened rather late in the process. IMO if that module was done in a routing WG instead of netmod, the process would have been faster. > I don't understand all this fuss about: "oh, but if you speak about one > OSPF YANG model, then you must include all the other ones". > People who want feedback on their YANG modules are welcome to join. This > was the goal. > > Regards, Benoit > > Andy > The configuration drafts for bgp (draft-zhdankin-netmod-bgp-cfg-00.txt) > and the I2rs drafts for bgp (draft-i2rs-hares-bgp-dm-00) have only a 5% > functional overlap. I will be releasing a draft that compares these two > drafts, and looks at how these drafts fulfill the I2RS BGP use case > requirements. > > > > IDR will sponsor a design team in IDR to push the rapid development of bgp > configuration or bgp i2rs. If you could suggest a few netmod people to > help this effort it would help. > > > > My understanding of IETF best practices indicate that joint interims need > 2 weeks announcement of topics. > > > > Sue > > > > *From:* Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org > ] *On Behalf Of *Thomas D. Nadeau > *Sent:* Wednesday, October 22, 2014 10:35 AM > *To:* Andy Bierman > *Cc:* Rtg-yang-coord@ietf.org; NETMOD Working Group; > ospf-chairs@tools.ietf.org; ops-ads@tools.ietf.org; rtg-ads@tools.ietf.org; > Benoit Claise; Farrel Adrian > *Subject:* Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled > > > > > > No one said that OSPF experts could not attend to provide > input. The issue is that OSPF was not doing this. If they want to take > over doing all OSPF models, then great, but to date no one was. The > agreement in NETMOD (and our charter) is to facilitate the creation of > models when WGs don't want to do them, have the expertise to do them, etc... > Also, getting the right Yang experts in one place is not going to happen > for every WG in the IETF; its just not realistic. I understand that > ultimately the WG needs to have consensus, but quick iteration to construct > the model surely can happen in a small "design team" fashion, right? > > > > And in terms of today's meeting being canceled, really what > purpose was that other than to stall/slow-down work? The group that was > there to work on the OSPF model was indeed a bunch of folks from OSPF (Acee > Lindem for example was on the call). So now since we won't have another > interim meeting until after Hawaii, so the next time this group can get > together is possibly in Hawaii, but that is probably unlikely as a large > number of people are not going to Hawaii. So the net-net is a slowing of > progress in this area. Probably not the result the IETF community wants. > > > > --Tom > > > > > > > > On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman > wrote: > > > > Hi Adrian, > > > > I agree with you. The OSPF WG should be discussing OSPF data models, > > not the NETMOD WG. The domain experts need to reach consensus > > on a feature set (and maybe info model) and then get 1 or 2 YANG experts to > > help translate that to a data model. (Not the other way around -- a room > > full of YANG experts and 1 or 2 OSPF experts). > > > > I also prefer that virtual interim meetings be used to discuss open issues > > on chartered items, not as an additional forum to promote individual > drafts. > > > > > > Andy > > > > > > On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel > wrote: > > I understand and appreciate your desire to get work done. > > The rules for IETF virtual interims are neither hard to discover, nor hard > to > comply with. The rules exist to ensure that people are included in the > work, and > I am sure that inclusion is what you want. > > I find it unfortunate that you scheduled a working group meeting to > discuss only > one of a pair of competing documents on the same topic, that you didn't > make the > information about the meeting available to the authors of the competing > document > or to the people who care about the protocol being modelled, and I find it > upsetting (yes, I am actually upset) that you decided to discuss in Netmod > a > document that belongs in the OSPF working group. > > If, as it surely sounds, you wish that the Netmod working group had a > different > charter to enable it to take on models for protocols that already have a > home in > other working groups, then I suggest you need to recharter. But I doubt > that > your reasoning that [YANG] experts will not go to all the other working > groups > will carry much weight. Frankly, and without wanting to disrespect the YANG > experts, it is easier to understand YANG than it is to understand OSPF. If > this > were not the case then the Netmod working group would have failed in its > design > of YANG! > > Conclusion: > You want to work on a YANG model for OSPF. Go to the OSPF working group and > discuss it (there are already some threads). Review and comment on the > competing > document. Try to get agreement between all of the authors of both > documents, or > try to identify the differences. Work with the chairs of the OSPF working > group > to advance the work. > > Adrian > > > -----Original Message----- > > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com] > > Sent: 22 October 2014 14:29 > > To: Benoit Claise > > Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; > ops-ads@tools.ietf.org; > > rtg-ads@tools.ietf.org > > Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled > > > > > > This is hugely disappointing. This is the kind of procedural > non-sense > has > > and IS driving people away from the IETF to other places where this work > is > going > > to get done. The simple effect of such silliness will be a reduction in > speed > and > > quantity of model development. If the goal of the IESG is to slow down > the > > velocity of model development and creation, then this approach is > perfect. > > > > For the record, the interim NETMOD meeting cadence has one meeting > > focused on Yang and the other on modeling; is not NETMOD-specific per > say, but > > to promote model creation because no other bi-weekly forum exists to do > so. It > > is also a place to bring in non-IETF work such as the work done in ODL, > other > open > > source, or just the public community that has explicitly wanted to avoid > the > IETF. > > We have found it a convenient and fruitful place to discuss, and actually > *build* > > models - regardless of their ultimate WG home. The simple reason: its a > single > > place for many of the experts to gather. I think you will find it very > difficult to get > > those people onto a per-WG call every other week. > > > > I hope the IESG considers this approach carefully because I do not > think > it > > will have the affect the larger IETF community is interested in. > > > > --Tom > > > > > > > > > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise > wrote: > > > > > > Dear all, > > > > > > Today NETMOD interim meeting is canceled. > > > > > > I received some pushbacks from the routing ADs, on the ground that: > > > 1. This interim appears to be meeting to discuss a non-WG draft for > which > there > > is no milestone in the working group and for which there is an obvious > home > > outside the working group. > > > 2. The agenda was not announced a week in advance on the IETF announce > list > > as is required > > > > > > Regards, Benoit > > > > > > _______________________________________________ > > > Rtg-yang-coord mailing list > > > Rtg-yang-coord@ietf.org > > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > --001a11c0d2d4729cd50506189f1f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Wed, Oct 22, 2014 at 2:08 PM, Benoit Claise <bclaise@cisco.com&= gt; wrote:
=20 =20 =20
Dear all,
=20 =20 =20

Tom:

 <= /u>

Acee indicated earlier on the i2rs list (September discussion) that the OSPF yang model was going to be standardized in OSPF.  I’m glad we’ve got the rtg-yang-coord l= ist to sort out these issues.

 <= /u>

IDR will pick up all BGP related yang modules.  A charter addition has been made.  IDR will gladly accept input from the netmod WG or hold joint interim session to make this effort go fast. 

Exactly. The YANG modules should be standardized in the respective WGs.
To have good YANG modules, you need:
1. the technology experts, i.e. the respective WG
2. YANG review

I don't understand all this fuss about: "oh, but you can't= speak about an OSPF module in a NETMOD WG".
We want to do what's right by providing YANG review of the documents, nothing else.

Ther= e is a difference between discussing a YANG module wrt/ its usage of YANG
language constructs, and discussing a module wrt/ the proper set o= f knobs for
a particular protocol (or feature).

My objections are to the latter discussion.
We saw with t= he ietf-routing module that wide review
from routing experts happ= ened rather late in the process.
IMO if that module was done in a= routing WG instead of netmod,
the process would have been faster= .


I don't understand all this fuss about: "oh, but if you speak = about one OSPF YANG model, then you must include all the other ones". People who want feedback on their YANG modules are welcome to join. This was the goal.

Regards, Benoit


Andy
 
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

The configuration drafts for bgp (draft-zhdankin-netmod-bgp-cfg-00.txt) and the I2rs drafts for bgp (draft-i2rs-hares-bgp-dm-00) have only a 5% functional overlap.  I will be releasing a draft that compares these two drafts, and looks at how these drafts fulfill the I2RS BGP use case requirements.

 <= /u>

IDR will sponsor a design team in IDR to push the rapid development of bgp configuration or bgp i2rs.  If you coul= d suggest a few netmod people to help this effort it would help.  

 <= /u>

My understanding of IETF best practices indicate that joint interims need 2 weeks announcement of topics.

 <= /u>

Sue

 <= /u>

From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of Thomas D. Nadeau
Sent: Wednesday, October 22, 2014 10:35 AM
To: Andy Bierman
Cc: Rtg-yang-coord@ietf.org; NETMOD Working Group; ospf-chairs@tools.ietf.org; ops-ads@tools.ietf.org; rtg-ads@tools.ietf.org; Benoit Claise; Farrel Adrian
Subject: Re: [Rtg-yang-coord] [netmod] NETMOD interim meeting canceled

 

 

      &n= bsp;     No one said that OSPF experts could not attend to provide input.   The issue is that OSPF was not doing this. If they want to take over doing all OSPF models, then great, but to date no one was.  The agreement in NETMOD (and our charter) is to facilitate the creation of models when WGs don’t want to do them, have the expertise to do them, etc…  Also, gett= ing the right Yang experts in one place is not going to happen for every WG in the IETF; its just not realistic.  I understand that ultimately the WG needs to have consensus, but quick iteration to construct the model surely can happen in a small “design team” fashion, right?

 

      =       And in terms of today’s meeting being canceled, really what purpose was that other than to stall/slow-down work?  The group that was there to work on the OSPF model was indeed a bunch of folks from OSPF (Acee Lindem for example was on the call).  So now since we won’t hav= e another interim meeting until after Hawaii, so the next time this group can get together is possibly in Hawaii, but that is probably unlikely as a large number of people are not going to Hawaii.  So the net-net is a slowing of progress = in this area.  Probably not the result the IETF community wants.

 

     &nbs= p;      —Tom

 

 

 

On Oct 22, 2014:10:18 AM, at 10:18 AM, Andy Bierman <andy@yumaworks.com> wrote:

 

Hi Adrian,

 

I agree with you. The OSPF WG should be discussing OSPF data models,

not the NETMOD WG. The domain experts need to reach consensus

on a feature set (and maybe info model) and then get 1 or 2 YANG experts to<= /u>

help translate that to a data model. (Not the other way around -- a room

full of YANG experts and 1 or 2 OSPF experts).

 

I also prefer that virtual interim meetings be used to discuss open issues<= /u>

on chartered items, not as an additional forum to promote individual drafts.

 

 

Andy

 

 

On Wed, Oct 22, 2014 at 6:48 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:

I understand and appreciate your desire to get work done.

The rules for IETF virtual interims are neither hard to discover, nor hard to
comply with. The rules exist to ensure that people are included in the work, and
I am sure that inclusion is what you want.
I find it unfortunate that you scheduled a working group meeting to discuss only
one of a pair of competing documents on the same topic, that you didn't make the<= br> information about the meeting available to the authors of the competing document
or to the people who care about the protocol being modelled, and I find it
upsetting (yes, I am actually upset) that you decided to discuss in Netmod a
document that belongs in the OSPF working group.

If, as it surely sounds, you wish that the Netmod working group had a different
charter to enable it to take on models for protocols that already have a home in
other working groups, then I suggest you need to recharter. But I doubt that
your reasoning that [YANG] experts will not go to all the other working groups
will carry much weight. Frankly, and without wanting to disrespect the YANG
experts, it is easier to understand YANG than it is to understand OSPF. If this
were not the case then the Netmod working group would have failed in its design
of YANG!

Conclusion:
You want to work on a YANG model for OSPF. Go to the OSPF working group and
discuss it (there are already some threads). Review and comment on the competing
document. Try to get agreement between all of the authors of both documents, or
try to identify the differences. Work with the chairs of the OSPF working group
to advance the work.

Adrian

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.c= om]
> Sent: 22 October 2014 14:29
> To: Benoit Claise
> Cc: NETMOD Working Group; Rtg-yang-coord@ietf.org; ops-ads@tools.ietf.org;
> rtg-ads@tools.ietf.org
> Subject: Re: [Rtg-yang-coord] NETMOD interim meeting canceled
>
>
>       This is hugely= disappointing. This is the kind of procedural non-sense
has
> and IS driving people away from the IETF to other places where this work is
going
> to get done. The simple effect of such silliness will be a reduction in speed
and
> quantity of model development.  If the goal of the IESG is to slow down the
> velocity of model development and creation, then this approach is perfect.
>
>       For the record= , the interim NETMOD meeting cadence has one meeting
> focused on Yang and the other on modeling; is not NETMOD-specific per say, but
> to promote model creation because no other bi-weekly forum exists to do so. It
> is also a place to bring in non-IETF work such as the work done in ODL, other
open
> source, or just the public community that has explicitly wanted to avoid the
IETF.
> We have found it a convenient and fruitful place to discuss, and actually
*build*
> models - regardless of their ultimate WG home.  The simple reason: its a
single
> place for many of the experts to gather. I think you will find it very
difficult to get
> those people onto a per-WG call every other week.
>
>       I hope the IES= G considers this approach carefully because I do not think
it
> will have the affect the larger IETF community is interested in.
>
>       --Tom
>
>
>
> > On Oct 22, 2014:9:16 AM, at 9:16 AM, Benoit Claise <bclaise@cisco.com>
wrote:
> >
> > Dear all,
> >
> > Today NETMOD interim meeting is canceled.
> >
> > I received some pushbacks from the routing ADs, on the ground that:
> > 1. This interim appears to be meeting to discuss a non-WG draft for which
there
> is no milestone in the working group and for which there is an obvious home
> outside the working group.
> > 2. The agenda was not announced a week in advance on the IETF announce list
> as is required
> >
> > Regards, Benoit
> >
> > _____________________________________________= __
> > Rtg-yang-coord mailing list
> > Rtg-yang-coord@ietf.org
> > https://www.ietf.org/mailma= n/listinfo/rtg-yang-coord
> >

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

 

 



--001a11c0d2d4729cd50506189f1f-- From nobody Thu Oct 23 08:36:45 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18CE01AC445 for ; Thu, 23 Oct 2014 08:36:44 -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 A12-_bJQqzyO for ; Thu, 23 Oct 2014 08:36:40 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0119.outbound.protection.outlook.com [65.55.169.119]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03EE11AC3D3 for ; Thu, 23 Oct 2014 08:36:39 -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.0.1049.19; Thu, 23 Oct 2014 15:36:37 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.50]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.50]) with mapi id 15.00.1049.012; Thu, 23 Oct 2014 15:36:37 +0000 From: Kent Watsen To: Juergen Schoenwaelder Thread-Topic: [netmod] inability to Thread-Index: AQHP7o8Jsddiu04H4kSTsgR89VZpzpw9jhMA Date: Thu, 23 Oct 2014 15:36:36 +0000 Message-ID: References: <20141023070001.GB96182@elstar.local> In-Reply-To: <20141023070001.GB96182@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.13] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 0373D94D15 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(199003)(189002)(51704005)(95666004)(31966008)(77096002)(21056001)(110136001)(87936001)(97736003)(50986999)(99286002)(76482002)(46102003)(86362001)(106116001)(106356001)(15975445006)(85306004)(15202345003)(83506001)(107046002)(92566001)(76176999)(36756003)(80022003)(92726001)(85852003)(64706001)(19580395003)(66066001)(122556002)(101416001)(120916001)(40100003)(99396003)(20776003)(4396001)(54356999)(2656002)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <516FC49A58A3294B91922EF13C7CFECF@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/47S944hFjRZuDFC1vkix_g3uHSw Cc: NETMOD Working Group Subject: Re: [netmod] inability to X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 23 Oct 2014 15:36:44 -0000 >please take a look at the discussion in this I-D: > >http://www.ietf.org/id/draft-schoenw-netmod-yang-pattern-00.txt > >I believe having a choice is a good thing and it is a feature to >keep transport specific leafs separate. I got the original design from that draft, of course. Flattening it as described earlier still preserves the outlined goals (leafrefs, future VRF augmentation, etc.). That said, I'm overlooking that not all transports are IP based, and thus you're right about needing to isolate them, even if both case statements are currently identical, they may not always be - e.g., configuring the host-keys / certificates the server should advertise... Maybe update your draft to highlight this goal more clearly? In the meanwhile, I'll go back to the original model. Thanks, Kent =20 From nobody Thu Oct 23 08:54:53 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A92841ACD24 for ; Thu, 23 Oct 2014 08:54: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 fVtpK0A3MK0T for ; Thu, 23 Oct 2014 08:54:48 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D7B81ACD1A for ; Thu, 23 Oct 2014 08:54:48 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id w8so842300qac.17 for ; Thu, 23 Oct 2014 08:54:46 -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=WNZfz22kNCw6bbRe8t4aloK8DQsjp0WDVxHF9Iq+aoE=; b=CsemjqUJ8sK4U00tWh7o3cKHjj+WaXeqZ7IEhKtkDlbbrDwFoiCeMdinkPDn+ps9MY zZaCGkViuiumKqhXwDypjJTHmRcG1f3vwPAFrLZ7v3Gglw4Xxo/UwcroLQp6geBhPG1q tOnLK//4mJ+IRZMt7wHbuV+QRT7AzvhtKJqGe6aWuW687zViK+UwdcPIS2KKHLijBB8O s4vPUoNtvcNXtln2lmisBxzdHDa4Vi59NGmPT90S2L5Z152qCGUueebUQ4sCYOcUCKOe +hTbCXBn6g16UiqBsTYjC/hY7YHR9DV/lx2yyn7Eeqc9X7B2pK7C0xTTUBSYVDdQwZAt oNwA== X-Gm-Message-State: ALoCoQmy7ykZv87cIQjtc0ZEbTTyErDq80k7VwiVPbSehm3GP3COgiXff8iab56DkZ1RgvQ7I5ie MIME-Version: 1.0 X-Received: by 10.140.88.177 with SMTP id t46mr8424327qgd.36.1414079686797; Thu, 23 Oct 2014 08:54:46 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Thu, 23 Oct 2014 08:54:46 -0700 (PDT) In-Reply-To: <20141023.091309.1845717459816913610.mbj@tail-f.com> References: <20141023.091309.1845717459816913610.mbj@tail-f.com> Date: Thu, 23 Oct 2014 08:54:46 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11c13e4a6a8d37050619153c Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/b2vYqzUfdf2weftLSxSyPiZXY4E Cc: "netmod@ietf.org" Subject: Re: [netmod] inability to X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 23 Oct 2014 15:54:50 -0000 --001a11c13e4a6a8d37050619153c Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 23, 2014 at 12:13 AM, Martin Bjorklund wrote: > Kent Watsen wrote: > > > > I'm trying to flatten the netconf-server model from: > > > > +--rw netconf-server > > +--rw listen > > +--rw endpoint* [name] > > +--rw name string > > +--rw (transport) > > +--:(ssh) {ssh-listen}? > > | +--rw ssh > > | +--rw address inet:ip-address > > | +--rw port? inet:port-number > > +--:(tls) {tls-listen}? > > +--rw tls > > +--rw address inet:ip-address > > +--rw port? inet:port-number > > > > > > To: > > > > +--rw netconf-server > > +--rw listen > > +--rw endpoint* [name] > > +--rw name string > > +--rw transport enumeration > > +--rw address inet:ip-address > > +--rw port? inet:port-number > > I don't think this is a good idea. Transports are different and may > have very different configuration parameters; even if they don't have > that currently we want to design for future extensibility, both in > what we configure per protocol and for future protocols. > > +1 I like the old design better > (This pattern is described in draft-schoenw-netmod-yang-pattern-00; we > should also discuss your suggested design there). > > > > The reason I used the first construct was only so that a grouping could > be > > used under each "transport" choice, which then could "refine" the port's > > default value to the transport-specific value: > > > > > > uses listen-per-transport-config { > > refine port { > > default 830; > > } > > } > > > > Or > > > > uses listen-per-transport-config { > > refine port { > > default 6513; > > } > > } > > > > > > > > I'm trying again now and still can't find a way to do it. What I want, > > is something like: > > > > > > leaf port { > > type inet:port-number; > > default { > > 830: when "transport == 'ssh'"; > > 6513: when "transport == 'tls'"; > > > > } > > } > > Not possible. defaults in YANG are static. If you want something > else you have to describe it in text. > > Maybe something for YANG 2.0? uses listen-per-transport-config { if "transport = 'ssh'" { refine port { default 830; } } elif "transport = 'tls'" { refine port { default 830; } } // else no port default } > (This one does come up every now and then. Variants include "default > ref" where the default value is configured in some other static leaf, > e.g. "if the timeout isn't set for a particular instance, use the > globally defined value: "default-ref ../../global-params/timeout", or > even dynamic default refs such as "if the timeout isn't set for a > particualr instance, use the value from the configured profile") > > > > /martin > > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a11c13e4a6a8d37050619153c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Thu, Oct 23, 2014 at 12:13 AM, Martin Bjorklund &l= t;mbj@tail-f.com>= ; wrote:
Kent Watsen <kwatsen@juniper.net> wrote:
>
> I'm trying to flatten the netconf-server model from:
>
>=A0 =A0 +--rw netconf-server
>=A0 =A0 =A0 =A0+--rw listen
>=A0 =A0 =A0 =A0 =A0 +--rw endpoint* [name]
>=A0 =A0 =A0 =A0 =A0 =A0 =A0+--rw name=A0 =A0 string
>=A0 =A0 =A0 =A0 =A0 =A0 =A0+--rw (transport)
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +--:(ssh) {ssh-listen}?
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 +--rw ssh
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0+--rw address=A0 =A0 inet:i= p-address
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0+--rw port?=A0 =A0 =A0 inet= :port-number
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +--:(tls) {tls-listen}?
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+--rw tls
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +--rw address=A0 =A0 inet:i= p-address
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +--rw port?=A0 =A0 =A0 inet= :port-number
>
>
> To:
>
>=A0 =A0 +--rw netconf-server
>=A0 =A0 =A0 =A0+--rw listen
>=A0 =A0 =A0 =A0 =A0 +--rw endpoint* [name]
>=A0 =A0 =A0 =A0 =A0 =A0 =A0+--rw name=A0 =A0 =A0 =A0 =A0string
>=A0 =A0 =A0 =A0 =A0 =A0 =A0+--rw transport=A0 =A0 enumeration
>=A0 =A0 =A0 =A0 =A0 =A0 =A0+--rw address=A0 =A0 =A0 inet:ip-address
>=A0 =A0 =A0 =A0 =A0 =A0 =A0+--rw port?=A0 =A0 =A0 =A0 inet:port-number<= br>
I don't think this is a good idea.=A0 Transports are different and may<= br> have very different configuration parameters; even if they don't have that currently we want to design for future extensibility, both in
what we configure per protocol and for future protocols.


+1
I like the old design bet= ter
=A0
(This pattern is described in draft-schoenw-netmod-yang-pattern-00; we
should also discuss your suggested design there).


> The reason I used the first construct was only so that a grouping coul= d be
> used under each "transport" choice, which then could "r= efine" the port's
> default value to the transport-specific value:
>
>
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 uses listen-per-transport-config {
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 refine port {
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 default 830;
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 }
>
> Or
>
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 uses listen-per-transport-config {
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 refine port {
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 default 6513;
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 }
>
>
>=
> I'm trying again now and still can't find a way to do it.=A0 = =A0What I want,
> is something like:
>
>
>=A0 =A0 =A0 =A0 =A0leaf port {
>=A0 =A0 =A0 =A0 =A0 =A0type inet:port-number;
>=A0 =A0 =A0 =A0 =A0 =A0default {
>=A0 =A0 =A0 =A0 =A0 =A0 =A0830: when "transport =3D=3D 'ssh= 9;";
>=A0 =A0 =A0 =A0 =A0 =A0 =A06513: when "transport =3D=3D 'tls&#= 39;";
>
>=A0 =A0 =A0 =A0 =A0 =A0}
>=A0 =A0 =A0 =A0 =A0}

Not possible.=A0 defaults in YANG are static.=A0 If you want something
else you have to describe it in text.



Maybe something for YANG 2.0?
=A0
=A0 =A0 =A0 =A0 = uses listen-per-transport-config {
=A0 =A0 = =A0 =A0 =A0 =A0 if "transport =3D 'ssh'" {
=A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0refine port {
=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0default 830;
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0}
=A0 =A0 =A0 =A0 =A0 =A0 = =A0}
=A0 =A0 =A0 =A0 =A0 =A0 =A0elif "= transport =3D 'tls'" {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0refine port {
<= div class=3D"gmail_quote">=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0defaul= t 830;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
=A0 =A0 =A0 =A0 =A0 =A0 =A0}
=A0 = =A0 =A0 =A0 =A0 =A0 =A0// else no port default
=A0 =A0 =A0 =A0 =A0}

=A0
(This one does come up every now and then.=A0 Variants include "defaul= t
ref" where the default value is configured in some other static leaf,<= br> e.g. "if the timeout isn't set for a particular instance, use the<= br> globally defined value:=A0 "default-ref ../../global-params/timeout&qu= ot;, or
even dynamic default refs such as "if the timeout isn't set for a<= br> particualr instance, use the value from the configured profile")



/martin



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

--001a11c13e4a6a8d37050619153c-- From nobody Thu Oct 23 08:56:38 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AAD11ACD39 for ; Thu, 23 Oct 2014 08:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 Q3gZimk-dhOl for ; Thu, 23 Oct 2014 08:56:25 -0700 (PDT) Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EA1A1ACD28 for ; Thu, 23 Oct 2014 08:56:18 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id dc16so474580qab.4 for ; Thu, 23 Oct 2014 08:56:17 -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=2ckjpf3h8ozf8F3zD8YrBopHuRZTk8rGR96BpnBD1Xs=; b=j8OOjYRCw97FQ5XzLmUGn0nn3vq19gDpy10luugUsAuqh25DoVA77qGLAL3q68rpkG ic1SV9IVILSFRpvjh0/1PLPzAC9nFYVHfpasfpznuhX2Wj0x5t4jc/ceqWNY+xh/ql89 LZkxEjN9LYmJXoSPcbatScCQbWCdI3yEWTjRZws04urcHZCu2rwyTst13ApdRkPrVX77 E8geUbXG5+rpcdvjD9UnBXIN4qlUO9YnJVbmGweIHVq4Xmu9Uvpro8ivCrDM3y0IBqMA 8pLVN+TLTmcE5I7bR3ULPu7MhZ9jHiJI/ioJ/MlsZjxtOA317z3mEZr2Nqhftakr//+H 05Gw== X-Gm-Message-State: ALoCoQkC+c7riQ2X6l/FBFEjwwbzP4lZt8BQPd6WiTw0ir13E12pudY5WUOFGwYLC96tUhSp725N MIME-Version: 1.0 X-Received: by 10.140.92.172 with SMTP id b41mr8349879qge.35.1414079773416; Thu, 23 Oct 2014 08:56:13 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Thu, 23 Oct 2014 08:56:13 -0700 (PDT) In-Reply-To: References: <20141023.091309.1845717459816913610.mbj@tail-f.com> Date: Thu, 23 Oct 2014 08:56:13 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11396ba4944ddd0506191a82 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/6wo6pjjdLnXU65-ob1oswXzQ8-s Cc: "netmod@ietf.org" Subject: Re: [netmod] inability to X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 23 Oct 2014 15:56:37 -0000 --001a11396ba4944ddd0506191a82 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 23, 2014 at 8:54 AM, Andy Bierman wrote: > > > On Thu, Oct 23, 2014 at 12:13 AM, Martin Bjorklund wrote: > >> Kent Watsen wrote: >> > >> > I'm trying to flatten the netconf-server model from: >> > >> > +--rw netconf-server >> > +--rw listen >> > +--rw endpoint* [name] >> > +--rw name string >> > +--rw (transport) >> > +--:(ssh) {ssh-listen}? >> > | +--rw ssh >> > | +--rw address inet:ip-address >> > | +--rw port? inet:port-number >> > +--:(tls) {tls-listen}? >> > +--rw tls >> > +--rw address inet:ip-address >> > +--rw port? inet:port-number >> > >> > >> > To: >> > >> > +--rw netconf-server >> > +--rw listen >> > +--rw endpoint* [name] >> > +--rw name string >> > +--rw transport enumeration >> > +--rw address inet:ip-address >> > +--rw port? inet:port-number >> >> I don't think this is a good idea. Transports are different and may >> have very different configuration parameters; even if they don't have >> that currently we want to design for future extensibility, both in >> what we configure per protocol and for future protocols. >> >> > +1 > I like the old design better > > >> (This pattern is described in draft-schoenw-netmod-yang-pattern-00; we >> should also discuss your suggested design there). >> >> >> > The reason I used the first construct was only so that a grouping could >> be >> > used under each "transport" choice, which then could "refine" the port's >> > default value to the transport-specific value: >> > >> > >> > uses listen-per-transport-config { >> > refine port { >> > default 830; >> > } >> > } >> > >> > Or >> > >> > uses listen-per-transport-config { >> > refine port { >> > default 6513; >> > } >> > } >> > >> > >> > > >> > I'm trying again now and still can't find a way to do it. What I want, >> > is something like: >> > >> > >> > leaf port { >> > type inet:port-number; >> > default { >> > 830: when "transport == 'ssh'"; >> > 6513: when "transport == 'tls'"; >> > >> > } >> > } >> >> Not possible. defaults in YANG are static. If you want something >> else you have to describe it in text. >> >> > > Maybe something for YANG 2.0? > > uses listen-per-transport-config { > if "transport = 'ssh'" { > refine port { > default 830; > } > } > elif "transport = 'tls'" { > refine port { > default 830; > oops -- supposed to be 6513 here! > } > } > // else no port default > } > > > > >> (This one does come up every now and then. Variants include "default >> ref" where the default value is configured in some other static leaf, >> e.g. "if the timeout isn't set for a particular instance, use the >> globally defined value: "default-ref ../../global-params/timeout", or >> even dynamic default refs such as "if the timeout isn't set for a >> particualr instance, use the value from the configured profile") >> >> >> >> /martin >> >> > > Andy > > >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > > --001a11396ba4944ddd0506191a82 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Thu, Oct 23, 2014 at 8:54 AM, Andy Bierman <andy@yumaworks.com= > wrote:

<= div class=3D"gmail_extra">
On Thu, Oct 23, 20= 14 at 12:13 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
Kent Watsen <kwatsen@juniper.net> wrote:
>
> I'm trying to flatten the netconf-server model from:
>
>=A0 =A0 +--rw netconf-server
>=A0 =A0 =A0 =A0+--rw listen
>=A0 =A0 =A0 =A0 =A0 +--rw endpoint* [name]
>=A0 =A0 =A0 =A0 =A0 =A0 =A0+--rw name=A0 =A0 string
>=A0 =A0 =A0 =A0 =A0 =A0 =A0+--rw (transport)
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +--:(ssh) {ssh-listen}?
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 +--rw ssh
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0+--rw address=A0 =A0 inet:i= p-address
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0+--rw port?=A0 =A0 =A0 inet= :port-number
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +--:(tls) {tls-listen}?
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+--rw tls
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +--rw address=A0 =A0 inet:i= p-address
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +--rw port?=A0 =A0 =A0 inet= :port-number
>
>
> To:
>
>=A0 =A0 +--rw netconf-server
>=A0 =A0 =A0 =A0+--rw listen
>=A0 =A0 =A0 =A0 =A0 +--rw endpoint* [name]
>=A0 =A0 =A0 =A0 =A0 =A0 =A0+--rw name=A0 =A0 =A0 =A0 =A0string
>=A0 =A0 =A0 =A0 =A0 =A0 =A0+--rw transport=A0 =A0 enumeration
>=A0 =A0 =A0 =A0 =A0 =A0 =A0+--rw address=A0 =A0 =A0 inet:ip-address
>=A0 =A0 =A0 =A0 =A0 =A0 =A0+--rw port?=A0 =A0 =A0 =A0 inet:port-number<= br>
I don't think this is a good idea.=A0 Transports are different and may<= br> have very different configuration parameters; even if they don't have that currently we want to design for future extensibility, both in
what we configure per protocol and for future protocols.


+1
I like the old design bet= ter
=A0
(This pattern is described in draft-schoenw-netmod-yang-pattern-00; we
should also discuss your suggested design there).


> The reason I used the first construct was only so that a grouping coul= d be
> used under each "transport" choice, which then could "r= efine" the port's
> default value to the transport-specific value:
>
>
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 uses listen-per-transport-config {
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 refine port {
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 default 830;
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 }
>
> Or
>
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 uses listen-per-transport-config {
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 refine port {
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 default 6513;
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 }
>
>
>=
> I'm trying again now and still can't find a way to do it.=A0 = =A0What I want,
> is something like:
>
>
>=A0 =A0 =A0 =A0 =A0leaf port {
>=A0 =A0 =A0 =A0 =A0 =A0type inet:port-number;
>=A0 =A0 =A0 =A0 =A0 =A0default {
>=A0 =A0 =A0 =A0 =A0 =A0 =A0830: when "transport =3D=3D 'ssh= 9;";
>=A0 =A0 =A0 =A0 =A0 =A0 =A06513: when "transport =3D=3D 'tls&#= 39;";
>
>=A0 =A0 =A0 =A0 =A0 =A0}
>=A0 =A0 =A0 =A0 =A0}

Not possible.=A0 defaults in YANG are static.=A0 If you want something
else you have to describe it in text.



Maybe s= omething for YANG 2.0?
=A0
=A0 =A0 =A0 =A0 uses listen-p= er-transport-config {
=A0 =A0 =A0 =A0 =A0 = =A0 if "transport =3D 'ssh'" {
=A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0refine port {
=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0default 830;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0}
=A0 =A0 =A0 =A0 =A0 =A0 =A0}
=A0 =A0 =A0 =A0 =A0 =A0 =A0elif "transport =3D = 'tls'" {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0refine port {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0default 830;

oops =A0 -- supp= osed to be 6513 here!
=A0
=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0}
=A0 =A0 =A0 =A0 =A0 =A0 =A0}=
=A0 =A0 =A0 =A0 =A0 =A0 =A0// else no port= default
=A0 =A0 =A0 =A0 =A0}


=A0
(This one does come up every now and then.=A0 Variants include "defaul= t
ref" where the default value is configured in some other static leaf,<= br> e.g. "if the timeout isn't set for a particular instance, use the<= br> globally defined value:=A0 "default-ref ../../global-params/timeout&qu= ot;, or
even dynamic default refs such as "if the timeout isn't set for a<= br> particualr instance, use the value from the configured profile")



/martin



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


--001a11396ba4944ddd0506191a82-- From nobody Thu Oct 23 09:02:33 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEBD31ACD49 for ; Thu, 23 Oct 2014 09:02:31 -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 Z87Hh22-Tq2O for ; Thu, 23 Oct 2014 09:02:28 -0700 (PDT) Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8725F1ACD3B for ; Thu, 23 Oct 2014 09:02:28 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id b13so1065615qcw.37 for ; Thu, 23 Oct 2014 09:02:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=uwxkWzDPxELg9os93luBGDDrclP5GAyIepXR6q8DCWQ=; b=OSo0F1AhTus9Zpekh6uLHzWeEAEX0OuX92wplUCo90xPY1x3Dr0WUEDMmlMVnhhj1J 7br+z9kGJi9brx0mppffJSj1ZGCnvE1sZJsCUc00/1P9gofYkFeLRcC5MptJvb6yc8zI A3Z77PAEknHxyT4A/CCWjrFTWGOOC8Rt96UU04AznEfznE08+tXvcPe6YiLhldgElUND i/v5yzJI5E91LqrPLzBbEBmpt+WgExY4wgwjLmLGlpidThVdsMXG96x4fq4q6GrS++7j LJBi/Vi8nazCKgX9EXEYYn5nRFmseD6YLFWUVAtQWtWJjALLXfrAZoxi0+fhG1lxP5Xo cElw== X-Gm-Message-State: ALoCoQnNOd3P5DN4d61ZB4+AKpdVGhbk8QmP+r+YHBeYZ6egUuHWbjr6wfttgwnvspkKrLaXizbD MIME-Version: 1.0 X-Received: by 10.140.88.177 with SMTP id t46mr8490363qgd.36.1414080147686; Thu, 23 Oct 2014 09:02:27 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Thu, 23 Oct 2014 09:02:27 -0700 (PDT) In-Reply-To: References: Date: Thu, 23 Oct 2014 09:02:27 -0700 Message-ID: From: Andy Bierman To: "Thomas D. Nadeau" Content-Type: multipart/alternative; boundary=001a11c13e4ae3149e0506193074 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/SLvGuzbrkUcfr0Muq_yIgVHYMSA Cc: "netmod@ietf.org" Subject: Re: [netmod] IETF91 NETMOD 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, 23 Oct 2014 16:02:32 -0000 --001a11c13e4ae3149e0506193074 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 21, 2014 at 2:34 PM, Thomas D. Nadeau wrote: > > Not yet. Please propose topics. > > I would like 15 min. to discuss YANG conformance issues, specified in this draft: http://www.ietf.org/id/draft-bierman-netmod-yang-conformance-04.txt These issues may get resolved in the NETCONF YANG 1.1 virtual interim meeting next week. If not, this topic should be discussed at the IETF meeting. --Tom > Andy > > > On Oct 21, 2014:5:32 PM, at 5:32 PM, Sterne, Jason (Jason) < > jason.sterne@alcatel-lucent.com> wrote: > > Hi all, > > Is there a preliminary agenda for the two NETMOD sessions at IETF91 ? > > Some thought about topics being split between the 1st (longer) and 2nd (shorter) > sessions ? > > Thanks, > 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 > > --001a11c13e4ae3149e0506193074 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Tue, Oct 21, 2014 at 2:34 PM, Thomas D. Nadeau <= ;tnadeau@lucid= vision.com> wrote:

N= ot yet. Please propose topics. 

=
I would like 15 min. to discuss YANG conformance issues, spe= cified in this draft:

These issues may= get resolved in the NETCONF YANG 1.1 virtual interim
meeting nex= t week. If not, this topic should be discussed at the IETF meeting.


—T= om

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

On Oct 21, 2014:5:32 PM, at 5:32 PM, S= terne, Jason (Jason) <jason.sterne@alcatel-lucent.com> wrote:

=
=
Hi all,
 
Is t= here a preliminary agenda for the two NETMOD sessions at IETF91 ? &nbs= p;   
 
Some thought a= bout topics being split between the 1st (longer) and 2nd (shorter) sessions ?
 
Thanks,
Jason
 
_______________________________________________
netmod = mailing list
netmod@ietf.org
https://www.iet= f.org/mailman/listinfo/netmod

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


...[ISO.10646]=C2=A0characters, including tab, carriage return, and line fe= ed, but excluding the other C0 control characters, surrogate blocks and non= -characters.
=C2=A0
(yes I know, double negation in there...=C2=A0 any suggestions?
s/except/but including/ ?)

Hope this helps.=
Chris.
=C2=A0
------------------------------------------------
In 9.4.=C2=A0 The string Built-In Type

OLD:

=C2=A0 =C2=A0The string built-in type represents human-readable strings in = YANG.
=C2=A0 =C2=A0Legal characters are tab, carriage return, line feed, and the = legal
=C2=A0 =C2=A0characters of Unicode and ISO/IEC 10646 [ISO.10646]:

=C2=A0 =C2=A0 =C2=A0;; any Unicode character, excluding the surrogate block= s,
=C2=A0 =C2=A0 =C2=A0;; FFFE, and FFFF.
=C2=A0 =C2=A0 =C2=A0string =3D *char
=C2=A0 =C2=A0 =C2=A0char =3D %x9 / %xA / %xD / %x20-D7FF / %xE000-FFFD / =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 %x10000-10FFFF

NEW:

=C2=A0 =C2=A0The string built-in type represents human-readable strings in = YANG.
=C2=A0 =C2=A0Legal characters are the Unicode and ISO/IEC 10646 [ISO.10646]=
=C2=A0 =C2=A0characters, excluding the surrogate blocks, the noncharacters,= and
=C2=A0 =C2=A0the C0 control characters except tab, carriage return, and lin= e feed.
=C2=A0 =C2=A0The string syntax is formally defined by the rule "yang-s= tring" in
=C2=A0 =C2=A0Section 13.


------------------------------------------------
In the grammar:

OLD:

=C2=A0 =C2=A0string=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D <= ; an unquoted string as returned by
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0the scanner >

NEW:

=C2=A0 =C2=A0string=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D <= ; an unquoted string as returned by
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0the scanner, that matches the rule
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0yang-string >

=C2=A0 =C2=A0yang-string=C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D *yang-char

=C2=A0 =C2=A0;; any Unicode character, excluding the surrogate blocks, the<= br> =C2=A0 =C2=A0;; noncharacters, and the C0 control characters except
=C2=A0 =C2=A0;; tab, carriage return, and line feed.
=C2=A0 =C2=A0yang-char =3D %x9 / %xA / %xD / %x20-D7FF /
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0; exclude surrogate blocks %xD800-DFF= F
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 %xE000-FDCF /=C2=A0 =C2=A0= ; exclude noncharacters %xFDD0-FDEF
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 %xFDF0-FFFD /=C2=A0 =C2=A0= ; exclude noncharacters %xFFFE-FFFF
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 %x10000-1FFFD /=C2=A0 ; ex= clude noncharacters %x1FFFE-1FFFF
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 %x20000-2FFFD /=C2=A0 ; ex= clude noncharacters %x2FFFE-2FFFF
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 %x30000-3FFFD /=C2=A0 ; ex= clude noncharacters %x3FFFE-3FFFF
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 %x40000-4FFFD /=C2=A0 ; ex= clude noncharacters %x4FFFE-4FFFF
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 %x50000-5FFFD /=C2=A0 ; ex= clude noncharacters %x5FFFE-5FFFF
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 %x60000-6FFFD /=C2=A0 ; ex= clude noncharacters %x6FFFE-6FFFF
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 %x70000-7FFFD /=C2=A0 ; ex= clude noncharacters %x7FFFE-7FFFF
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 %x80000-8FFFD /=C2=A0 ; ex= clude noncharacters %x8FFFE-8FFFF
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 %x90000-9FFFD /=C2=A0 ; ex= clude noncharacters %x9FFFE-9FFFF
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 %xA0000-AFFFD /=C2=A0 ; ex= clude noncharacters %xAFFFE-AFFFF
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 %xB0000-BFFFD /=C2=A0 ; ex= clude noncharacters %xBFFFE-BFFFF
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 %xC0000-CFFFD /=C2=A0 ; ex= clude noncharacters %xCFFFE-CFFFF
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 %xD0000-DFFFD /=C2=A0 ; ex= clude noncharacters %xDFFFE-DFFFF
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 %xE0000-EFFFD /=C2=A0 ; ex= clude noncharacters %xEFFFE-EFFFF
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 %xF0000-FFFFD /=C2=A0 ; ex= clude noncharacters %xFFFFE-FFFFF
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 %x100000-10FFFD=C2=A0 ; ex= clude noncharacters %x10FFFE-10FFFF


/martin

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


--
Chris Elliott
CCIE # 2013

=E2=80=9CYou and= I are mirages that perceive themselves=E2=80=9D
--Douglas Hofstadter

--001a113968a606afad05063134fc-- From nobody Fri Oct 24 15:02:31 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0DA1A9081 for ; Fri, 24 Oct 2014 15:02: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 ZKnqWtb0iUrD for ; Fri, 24 Oct 2014 15:02:11 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AF451A8F4F for ; Fri, 24 Oct 2014 15:02:10 -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=1414188131; x=1415397731; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Agoa6oE1W88646WJkDd+u6whd1rskePtca49QPlh3v0=; b=bzkKeKRZ3/on/1EMPuGmMZjGwcgv4+sCUNdg3V2dsw+Vu3yAyar14FSd DZ6Jq3hQ7g+hXUEU8gaggQHqjpP5mPj5ZbeAqiI5aaALtwbw3bwrVdZhv MHdagZuFtqhKlEkJNNV3ogmDAuTGxdiz5E9cbtb1v981W4X4ObpkdR7PY k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAAHLSlStJV2b/2dsb2JhbABcgmsjVFMFBM0wh0sCgQgWAXILhAMBAQQ6PRICAQg2EDIbAQYDAgQTCYg4AQcFywQBAQEBAQEEAQEBAQEBARuQX4RLBZIFhEaHEoExPIMNkTKDeGwBgUeBAwEBAQ X-IronPort-AV: E=Sophos;i="5.04,782,1406592000"; d="scan'208";a="90149380" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-7.cisco.com with ESMTP; 24 Oct 2014 22:02:10 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s9OM29I9028363 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 24 Oct 2014 22:02:09 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Fri, 24 Oct 2014 17:02:09 -0500 From: "Clyde Wildes (cwildes)" To: "netmod@ietf.org" Thread-Topic: New Version Notification for draft-wildes-netmod-syslog-model-04.txt Thread-Index: AQHP79Tug4bke/5G5Um5T3UA4u6loJw/qxyA Date: Fri, 24 Oct 2014 22:02:08 +0000 Message-ID: References: <20141024215315.18683.41870.idtracker@ietfa.amsl.com> In-Reply-To: <20141024215315.18683.41870.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.27.7.183] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/oOVW8pXaVvDwh8hgIYf8k0yxtGY Subject: [netmod] FW: New Version Notification for draft-wildes-netmod-syslog-model-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: Fri, 24 Oct 2014 22:02:15 -0000 A new version of "draft-wildes-netmod-syslog-model" has been uploaded. Key changes include: - support for signed syslog message configuration was added to the remote-logging-action leaf - minor typos corrected in the model description fields and the Syslog Example Thanks, Clyde On 10/24/14, 2:53 PM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-wildes-netmod-syslog-model-04.txt >has been successfully submitted by Clyde Wildes and posted to the >IETF repository. > >Name: draft-wildes-netmod-syslog-model >Revision: 04 >Title: SYSLOG YANG model >Document date: 2014-10-24 >Group: Individual Submission >Pages: 21 >URL: =20 >http://www.ietf.org/internet-drafts/draft-wildes-netmod-syslog-model-04.tx >t >Status: =20 >https://datatracker.ietf.org/doc/draft-wildes-netmod-syslog-model/ >Htmlized: =20 >http://tools.ietf.org/html/draft-wildes-netmod-syslog-model-04 >Diff: =20 >http://www.ietf.org/rfcdiff?url2=3Ddraft-wildes-netmod-syslog-model-04 > >Abstract: > This document describes a data model for Syslog > protocol which is used to convey event notification messages. > > =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 Oct 24 16:35:07 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F66A1A1B60 for ; Fri, 24 Oct 2014 16:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 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_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 IJZfpjWPO4-4 for ; Fri, 24 Oct 2014 16:35:03 -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 9E5911A1B4F for ; Fri, 24 Oct 2014 16:35:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=GwNjZP0N4+knzkbR8ujkoeV1yg5xK76d8hCQOWietpxGpG8Z31Fb/cukWUd5KFob; 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-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1XhoNl-0006Bp-Jj; Fri, 24 Oct 2014 19:34:57 -0400 Received: from 76.254.52.158 by webmail.earthlink.net with HTTP; Fri, 24 Oct 2014 19:34:56 -0400 Message-ID: <5445443.1414193697563.JavaMail.root@mswamui-cedar.atl.sa.earthlink.net> Date: Fri, 24 Oct 2014 16:34:57 -0700 (GMT-07:00) From: Randy Presuhn To: Martin Bjorklund , netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88825aa8a2065c9591fd6099719933e28ba304700f49d7a2d21350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.29 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/FS3jHLx9Fb_mc6cvCfcKxUmtEV0 Subject: Re: [netmod] issue Y56 UTF8 non-characters 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, 24 Oct 2014 23:35:05 -0000 Hi - >From: Martin Bjorklund >Sent: Oct 24, 2014 4:22 PM >To: netmod@ietf.org >Subject: [netmod] issue Y56 UTF8 non-characters ... >I think we should have the same rules for the YANG module as for the >"string" built-in type. ... I'd question that. For the YANG module itself I think it would probably be a good idea to specify a normalization form, in order to avoid headaches due to, for example, the various ways of "spelling" =E1=BA=A7, =E1=BA=BF, =E1=BB=9D, =C3=A9, =C3=B1, =C3=A4,= =C3=BC, and =C3=B6, to name just a few. For the string built-in type, requiring a specific normalization form would probably be problematic if the data to be modeled has been subjected to a different normalization form. Randy From nobody Fri Oct 24 16:40:48 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1DF71A1ACA for ; Fri, 24 Oct 2014 16:40:47 -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 tShpWquuWGN1 for ; Fri, 24 Oct 2014 16:40:45 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6C801A1A34 for ; Fri, 24 Oct 2014 16:40:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1144; q=dns/txt; s=iport; t=1414194045; x=1415403645; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=1JcOKY/PUjQWjYjIUNI97aAEYM8Tpr52+rBu1w0lFtY=; b=DJ44vnTdVxUPnXMhUueEen3sYw37MLiCj9FE4qqUvPlAy9BGSTmZ/uWV kobZZPgyQjIVmqlZfDTvLuRlUkxGyqJW66TBocF5iDQgPw6wA18lMelRq /9u85t/vhNLF6mXzACBtBzacGNDrABNNNlwQ+XF+ILHhM7g2TYWWZYmNz 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAKXiSlStJA2B/2dsb2JhbABcgw5UWATNL4dLAoEGFgFyC4QDAgQ6PRQBCDZCGwEGAwIEEwmIOA2ldaRNAQEBAQYBAQEBAQEckF+ESwWSBYRGhxKBMTyDDY0yhACDeGyBSIEDAQEB X-IronPort-AV: E=Sophos;i="5.04,783,1406592000"; d="scan'208";a="366228020" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-7.cisco.com with ESMTP; 24 Oct 2014 23:40:45 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s9ONejH1013901 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 24 Oct 2014 23:40:45 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.56]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Fri, 24 Oct 2014 18:40:44 -0500 From: "Aseem Choudhary (asechoud)" To: "netmod@ietf.org" Thread-Topic: New Version Notification for draft-asechoud-netmod-diffserv-model-00.txt Thread-Index: AQHP7mGP2vm6fmJfZEiR5Hqt7yYxy5w/yY2A Date: Fri, 24 Oct 2014 23:40:44 +0000 Message-ID: In-Reply-To: <20141023013450.26477.17744.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.2.3.120616 x-originating-ip: [10.154.208.174] Content-Type: text/plain; charset="us-ascii" Content-ID: <7245CDF908E7454A80C4D77FBD85263C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/37CLaDEHZ7vanUvKi3visZ7yUzA Subject: [netmod] FW: New Version Notification for draft-asechoud-netmod-diffserv-model-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, 24 Oct 2014 23:40:48 -0000 Hi, For everyone reference. Please provide your comments. -thanks, Aseem On 10/22/14, 6:34 PM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-asechoud-netmod-diffserv-model-00.txt >has been successfully submitted by Aseem Choudhary and posted to the >IETF repository. > >Name: draft-asechoud-netmod-diffserv-model >Revision: 00 >Title: YANG Model for Diffserv >Document date: 2014-10-22 >Group: Individual Submission >Pages: 27 >URL: =20 >http://www.ietf.org/internet-drafts/draft-asechoud-netmod-diffserv-model-0 >0.txt >Status: =20 >https://datatracker.ietf.org/doc/draft-asechoud-netmod-diffserv-model/ >Htmlized: =20 >http://tools.ietf.org/html/draft-asechoud-netmod-diffserv-model-00 > > >Abstract: > This document describes a YANG model of Differentiated Services for > configuration and operations. > > =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 Sun Oct 26 08:29:05 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8927C1A000B; Sun, 26 Oct 2014 08:29: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 cved_GaD3NML; Sun, 26 Oct 2014 08:29:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0945A1A005B; Sun, 26 Oct 2014 08:28:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141026152858.21687.9670.idtracker@ietfa.amsl.com> Date: Sun, 26 Oct 2014 08:28:58 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/EbIgj3vTXLCHFS2pjwWztt0Bjuo Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-16.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: Sun, 26 Oct 2014 15:29:01 -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 : A YANG Data Model for Routing Management Author : Ladislav Lhotka Filename : draft-ietf-netmod-routing-cfg-16.txt Pages : 88 Date : 2014-10-26 Abstract: This document contains a specification of three YANG modules. Together they form the core routing data model which serves as a framework for configuring and managing a routing subsystem. It is expected that these modules will be augmented by additional YANG modules defining data models for routing protocols and other functions. The core routing data model provides common building blocks for such extensions - routing instances, routes, routing information bases (RIB), routing protocols and route filters. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-routing-cfg-16 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 Sun Oct 26 08:40:27 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8B31A8972 for ; Sun, 26 Oct 2014 08:40:26 -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 RrF_nhTJ4ToL for ; Sun, 26 Oct 2014 08:40:24 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E8B51A8982 for ; Sun, 26 Oct 2014 08:39:56 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id 9993313FD88 for ; Sun, 26 Oct 2014 16:39:54 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1414337994; bh=lcrVgAfyXds1g/CpbJ+wn2n1zKJEEUDmH8CiXOhVrog=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Date: References:To:Message-Id:Mime-Version; b=b9yDgTcRJaHAqclKVXYBDW1dk6I97fV/gUpE1Om0M4dVhasH22+SS0QigGk4lyvix K4Y8mFn1koi85w1bwMHbccS01vSPRKDCoBS33RuA76MHacZUg3F3ZJuQDAfT6TSFNj 8P5mM26rVgi+OTJG22Fv3lWbiGPRPQFec5VNTGEk= From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 26 Oct 2014 16:40:00 +0100 References: <20141026152858.21687.9670.idtracker@ietfa.amsl.com> To: NETMOD Working Group Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/elkG85aYK_KcKkihEiU18yDLGs8 Subject: [netmod] Fwd: I-D Action: draft-ietf-netmod-routing-cfg-16.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: Sun, 26 Oct 2014 15:40:26 -0000 Hi, this revision of the routing draft is a result of synchronisation with = the group of routing experts working on the OSPF and ISIS modules. The sources for the draft, YANG modules and examples are available from = this GitHub repo: https://github.com/yang-routing/yang-routing Lada Begin forwarded message: > From: internet-drafts@ietf.org > Subject: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-16.txt > Date: 26 Oct 2014 16:28:58 GMT+1 > To: i-d-announce@ietf.org > Cc: netmod@ietf.org >=20 >=20 > 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 : A YANG Data Model for Routing Management > Author : Ladislav Lhotka > Filename : draft-ietf-netmod-routing-cfg-16.txt > Pages : 88 > Date : 2014-10-26 >=20 > Abstract: > This document contains a specification of three YANG modules. > Together they form the core routing data model which serves as a > framework for configuring and managing a routing subsystem. It is > expected that these modules will be augmented by additional YANG > modules defining data models for routing protocols and other > functions. The core routing data model provides common building > blocks for such extensions - routing instances, routes, routing > information bases (RIB), routing protocols and route filters. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-16 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-routing-cfg-16 >=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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Sun Oct 26 10:43:37 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 611A81A0072 for ; Sun, 26 Oct 2014 10:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, 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 sIdk-wBi91kh for ; Sun, 26 Oct 2014 10:43:34 -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 AEF741A0252 for ; Sun, 26 Oct 2014 10:43:34 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 301628ED; Sun, 26 Oct 2014 18:43:33 +0100 (CET) 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 BkJuy9Fu0oyN; Sun, 26 Oct 2014 18:43:06 +0100 (CET) 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; Sun, 26 Oct 2014 18:43:32 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id A54E120037; Sun, 26 Oct 2014 18:43:32 +0100 (CET) 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 MJrdzpsTJ57J; Sun, 26 Oct 2014 18:43:32 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D721120035; Sun, 26 Oct 2014 18:43:31 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id AFD352F11EB0; Sun, 26 Oct 2014 18:43:30 +0100 (CET) Date: Sun, 26 Oct 2014 18:43:30 +0100 From: Juergen Schoenwaelder To: Alia Atlas , Adrian Farrel Message-ID: <20141026174330.GB6059@elstar.local> Mail-Followup-To: Alia Atlas , Adrian Farrel , Benoit Claise , 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: http://mailarchive.ietf.org/arch/msg/netmod/uS7a9ueN7drKs9pzwX7vTxCNm8o Cc: netmod@ietf.org Subject: [netmod] routing data model review 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: Sun, 26 Oct 2014 17:43:36 -0000 Alia and Adrian, Lada Lhotka has posted a new version of the core routing data model. https://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-16 Can you please make sure that this revision gets reviewed by the interested routing people? Lada has been working with some OSPF and ISIS people and he believes issues that came up have been resolved. If there are any issues left, it would be nice to receive them ideally before or if that is not possible during the Honolulu IETF meeting. /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 Sun Oct 26 17:34:29 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64FD61A1B2A; Sun, 26 Oct 2014 17:34:25 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 8yIesRPyB_pV; Sun, 26 Oct 2014 17:34:23 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C7081A1AE6; Sun, 26 Oct 2014 17:34:22 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s9R0YJUs023855; Mon, 27 Oct 2014 00:34:19 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s9R0YI1r023839 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 27 Oct 2014 00:34:18 GMT From: "Adrian Farrel" To: "'Tom Taylor'" References: <544CC985.9060808@pi.nu> <7347100B5761DC41A166AC17F22DF1121B86EE25@eusaamb103.ericsson.se> <000601cff179$707a8c10$516fa430$@olddog.co.uk> <544D8EAA.9090909@gmail.com> In-Reply-To: <544D8EAA.9090909@gmail.com> Date: Mon, 27 Oct 2014 00:34:15 -0000 Message-ID: <000e01cff17d$bd0d5f90$37281eb0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGuTtmLR0JtP8jl1thBqlYiJvncbQIIekC6Ajjl9XEBAQsSKpxcR6yg Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21056.003 X-TM-AS-Result: No--30.210-10.0-31-10 X-imss-scan-details: No--30.210-10.0-31-10 X-TMASE-MatchedRID: TmlY9+XBoTm31G6CKdUG1cnUTf2MoOKYEtdrY/Wb3fMNht78/JfyBMKA qDfnmQ42htCDYfkeWUJo3hk6V6hjRT75vUIBy/bgU+OjsPhIWDhbUMPBWMyEThtDdc/8nLiysIz dcvB968pNYvDaO9t+nDYdkK1ORHHU9R7dwXny/bdhHpATwph+yOHQ21j8RtplCjPgYJbiyuAIZJ R7eWK/XCloEzX3fCKax+Qz1C8nOE6k0F4/j+0gRppWgCLYjjT9IpFOMUBYG+7HkH7uosEn7K0Ro mhWPJaQB153D9DJzyUNAALOfBOeCgmUwwEM0RbQ6/xAZojbl7c7ikpJrsu/6E/N5GQtssoCM+p+ NpswZmrPVbpsm8zN9R6i22jnAC+aCBmrdSPkjFwOrlBkQa9qFp20dShmm+V5feHPnu31iHAuaJN NszYALx05bc4Zz97z5pxeinsKVObGkynrj1kccqm4PbloS2C3QZXZg2I8JabnU40jhQv76qPFjJ EFr+olfeZdJ1XsorhYoPZAqTBHwi/tubwHkCSX+gD2vYtOFhgqtq5d3cxkNQP90fJP9eHt Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/fGJKL_22iE9V86kUaS1z6e3SLCE Cc: Rtg-yang-coord@ietf.org, lime@ietf.org, netmod@ietf.org, david.sinicrope@ericsson.com Subject: Re: [netmod] [Rtg-yang-coord] hopefully a simple question X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 00:34:25 -0000 [Adding Netmod, but removing MPLS] A good pointer, Tom, thanks. The liaison seems to request review and feedback, but I don't see a response from Netmod and it looks like the MEF Technical Committee is meeting today and in the next few days. I think that if LIME had existed at the time the liaison arrived, it is probable that it would also have been a recipient. We should certainly strive to work with MEF and build on existing work. Adrian > -----Original Message----- > From: Tom Taylor [mailto:tom.taylor.stds@gmail.com] > Sent: 27 October 2014 00:16 > To: adrian@olddog.co.uk; 'Gregory Mirsky'; 'Loa Andersson'; lime@ietf.org; Rtg- > yang-coord@ietf.org > Cc: mpls@ietf.org > Subject: Re: [Rtg-yang-coord] hopefully a simple question > > This might be a good time to remind/alert people about the liaison > statement received from the MEF regarding > draft-tissa-lime-yang-oam-model. It can be found at > > https://datatracker.ietf.org/documents/LIAISON/liaison-2014-07-31-mef- > netmod-liaison-to-ietf-on-yang-service-oam-models-attachment-1.pdf > > Tom Taylor > > On 26/10/2014 8:03 PM, Adrian Farrel wrote: > > The intention of LIME (who knows whether it is achievable?) is to produce a > > single YANG module that provides a generic way in to OAM across all IETF > > technologies. > > > > There are certainly a number of core concepts, configurable items, and > > reportable things that can be stated in a technology independent way. > > > > LIME has as a deliverable a set of applicability statements showing how the > > generic module is applied to different IETF OAM technologies. > > > > I should not be surprised if technology-specific modules are also required. I > > think LIME hopes that these will build on the generic module and not reinvent. I > > assume this will be through augmentation. And I assume the work will be done > by > > the WGs that own the technologies (where those WGs exist). > > > > I don't think I understand your tree. Why would "RSVP-TE OAM" live under > rsvp-te > > under mpls? The OAM is going to be standard mpls oam, but the concepts > (MIPs, > > MEPs, on/off, failure found, etc.) are general. > > > > Adrian > > > >> -----Original Message----- > >> From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of > >> Gregory Mirsky > >> Sent: 26 October 2014 18:51 > >> To: Loa Andersson; lime@ietf.org; Rtg-yang-coord@ietf.org > >> Cc: mpls@ietf.org > >> Subject: Re: [Rtg-yang-coord] hopefully a simple question > >> > >> Hi Loa, > >> I think that your question is not simple at all and it would be a great to > > discuss > >> how Generic OAM proposal is related to MPLS OAM at the meeting. > >> Personally, I think that there's no separate LDP, RSVP-TE or EVPN, Segment > >> Routing (as far as transport layer for the latter two) OAMs but one MPLS OAM > >> with extensions/special cases for IP/MPLS, MPLS-TP and Segment Routing > >> networks. > >> > >> Regards, > >> Greg > >> -----Original Message----- > >> From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of > >> Loa Andersson > >> Sent: Sunday, October 26, 2014 3:14 AM > >> To: lime@ietf.org; Rtg-yang-coord@ietf.org > >> Subject: [Rtg-yang-coord] hopefully a simple question > >> > >> Folks, > >> > >> I have what I hope is a simple question, and that it will only reveal that I'm > > not up > >> to speed on yang. > >> > >> I trying to figure out the relationship between the generic yang models in > > e.g. > >> draft-tissa-lime-yang-oam-model and the specific models we do for different > >> variants of e.g. mpls oam. > >> > >> I guess we have a structure more or less like this > >> > >> mpls > >> | > >> |- ldp > >> | |-ldp oam > >> | > >> |- rsvp-te > >> | | > >> | |- rsvp-te oam > >> | > >> |- lsp ping > >> | | > >> | |- lsp ping oam > >> | > >> |- etc > >> > >> > >> Where does the generic work fit in? > >> > >> /Loa > >> -- > >> > >> > >> Loa Andersson email: loa@mail01.huawei.com > >> Senior MPLS Expert loa@pi.nu > >> Huawei Technologies (consultant) phone: +46 739 81 21 64 > >> > >> _______________________________________________ > >> Rtg-yang-coord mailing list > >> Rtg-yang-coord@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtg-yang-coord > >> > >> _______________________________________________ > >> Rtg-yang-coord mailing list > >> Rtg-yang-coord@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > > > _______________________________________________ > > Rtg-yang-coord mailing list > > Rtg-yang-coord@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > From nobody Sun Oct 26 19:13:54 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3099D1A3B9E; Sun, 26 Oct 2014 19:13:47 -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 T_jDggbrAU3u; Sun, 26 Oct 2014 19:13:44 -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 947C81A6EDB; Sun, 26 Oct 2014 19:13:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKY65246; Mon, 27 Oct 2014 02:13:38 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 27 Oct 2014 02:13:37 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.21]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Mon, 27 Oct 2014 10:13:31 +0800 From: Qin Wu To: "adrian@olddog.co.uk" , "'Tom Taylor'" Thread-Topic: [Lime] [Rtg-yang-coord] hopefully a simple question Thread-Index: AQHP8Xst52xKZrqdBUqVuDTnIZNWM5xCkmaAgACeQDA= Date: Mon, 27 Oct 2014 02:13:31 +0000 Message-ID: References: <544CC985.9060808@pi.nu> <7347100B5761DC41A166AC17F22DF1121B86EE25@eusaamb103.ericsson.se> <000601cff179$707a8c10$516fa430$@olddog.co.uk> <544D8EAA.9090909@gmail.com> <000e01cff17d$bd0d5f90$37281eb0$@olddog.co.uk> In-Reply-To: <000e01cff17d$bd0d5f90$37281eb0$@olddog.co.uk> 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: http://mailarchive.ietf.org/arch/msg/netmod/Xkf4q0dT4l9s8ak8GpsvX5OaHiM Cc: "Rtg-yang-coord@ietf.org" , "lime@ietf.org" , "netmod@ietf.org" , "david.sinicrope@ericsson.com" Subject: Re: [netmod] [Lime] [Rtg-yang-coord] hopefully a simple question X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 27 Oct 2014 02:13:47 -0000 QW5vdGhlciBsaWFpc29uIHN0YXRlbWVudCBzZW50IHRvIElFVEYgT1BTYXJlYSBvbiBBcHJpbCAy MDE0IGJlZm9yZSBMSU1FIGlzIGZvcm1lZA0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2N1bWVudHMvTElBSVNPTi9saWFpc29uLTIwMTQtMDQtMjMtaXR1LXQtc2ctMTUtb3BzLWxzLW9u LW5ldy13b3JrLWl0ZW0tb24tZ2VuZXJpYy1pbmZvcm1hdGlvbi1tb2RlbC1mb3ItbWFuYWdlbWVu dC1vZi10cmFuc3BvcnQtbmUtYXR0YWNobWVudC0xLnBkZg0KSXQgaXMgcmVsYXRlZCB0byBJVFUt VCBHLmdpbTogZ2VuZXJpYyBwcm90b2NvbC1uZXV0cmFsIGluZm9ybWF0aW9uIG1vZGVsIGZvciB0 cmFuc3BvcnQgbmV0d29yayBtYW5hZ2VtZW50Lg0KQWx0aG91Z2ggaXQgaXMgbm90IGRpcmVjdGx5 IHJlbGF0ZWQgdG8gWUFORyBkYXRhIG1vZGVsIHdvcmsgd2UgYXJlIGZvY3VzaW5nIG9uLCBJIHRo aW5rIHdlIGFsc28gbmVlZCB0byBjb25zaWRlciB0aGlzIGV4aXN0aW5nIHdvcmsuDQoNClJlZ2Fy ZHMhDQotUWluDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogTGltZSBbbWFpbHRvOmxpbWUt Ym91bmNlc0BpZXRmLm9yZ10gtPqx7SBBZHJpYW4gRmFycmVsDQq3osvNyrG85DogMjAxNMTqMTDU wjI3yNUgODozNA0KytW8/sjLOiAnVG9tIFRheWxvcicNCrOty806IFJ0Zy15YW5nLWNvb3JkQGll dGYub3JnOyBsaW1lQGlldGYub3JnOyBuZXRtb2RAaWV0Zi5vcmc7IGRhdmlkLnNpbmljcm9wZUBl cmljc3Nvbi5jb20NCtb3zOI6IFJlOiBbTGltZV0gW1J0Zy15YW5nLWNvb3JkXSBob3BlZnVsbHkg YSBzaW1wbGUgcXVlc3Rpb24NCg0KW0FkZGluZyBOZXRtb2QsIGJ1dCByZW1vdmluZyBNUExTXQ0K DQpBIGdvb2QgcG9pbnRlciwgVG9tLCB0aGFua3MuDQoNClRoZSBsaWFpc29uIHNlZW1zIHRvIHJl cXVlc3QgcmV2aWV3IGFuZCBmZWVkYmFjaywgYnV0IEkgZG9uJ3Qgc2VlIGEgcmVzcG9uc2UgZnJv bSBOZXRtb2QgYW5kIGl0IGxvb2tzIGxpa2UgdGhlIE1FRiBUZWNobmljYWwgQ29tbWl0dGVlIGlz IG1lZXRpbmcgdG9kYXkgYW5kIGluIHRoZSBuZXh0IGZldyBkYXlzLiANCg0KSSB0aGluayB0aGF0 IGlmIExJTUUgaGFkIGV4aXN0ZWQgYXQgdGhlIHRpbWUgdGhlIGxpYWlzb24gYXJyaXZlZCwgaXQg aXMgcHJvYmFibGUgdGhhdCBpdCB3b3VsZCBhbHNvIGhhdmUgYmVlbiBhIHJlY2lwaWVudC4gDQoN CldlIHNob3VsZCBjZXJ0YWlubHkgc3RyaXZlIHRvIHdvcmsgd2l0aCBNRUYgYW5kIGJ1aWxkIG9u IGV4aXN0aW5nIHdvcmsuDQoNCkFkcmlhbg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IFRvbSBUYXlsb3IgW21haWx0bzp0b20udGF5bG9yLnN0ZHNAZ21haWwuY29tXQ0K PiBTZW50OiAyNyBPY3RvYmVyIDIwMTQgMDA6MTYNCj4gVG86IGFkcmlhbkBvbGRkb2cuY28udWs7 ICdHcmVnb3J5IE1pcnNreSc7ICdMb2EgQW5kZXJzc29uJzsgDQo+IGxpbWVAaWV0Zi5vcmc7DQpS dGctDQo+IHlhbmctY29vcmRAaWV0Zi5vcmcNCj4gQ2M6IG1wbHNAaWV0Zi5vcmcNCj4gU3ViamVj dDogUmU6IFtSdGcteWFuZy1jb29yZF0gaG9wZWZ1bGx5IGEgc2ltcGxlIHF1ZXN0aW9uDQo+IA0K PiBUaGlzIG1pZ2h0IGJlIGEgZ29vZCB0aW1lIHRvIHJlbWluZC9hbGVydCBwZW9wbGUgYWJvdXQg dGhlIGxpYWlzb24gDQo+IHN0YXRlbWVudCByZWNlaXZlZCBmcm9tIHRoZSBNRUYgcmVnYXJkaW5n IA0KPiBkcmFmdC10aXNzYS1saW1lLXlhbmctb2FtLW1vZGVsLiAgSXQgY2FuIGJlIGZvdW5kIGF0 DQo+IA0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvY3VtZW50cy9MSUFJU09OL2xp YWlzb24tMjAxNC0wNy0zMS1tZWYtDQo+IG5ldG1vZC1saWFpc29uLXRvLWlldGYtb24teWFuZy1z ZXJ2aWNlLW9hbS1tb2RlbHMtYXR0YWNobWVudC0xLnBkZg0KPiANCj4gICBUb20gVGF5bG9yDQo+ IA0KPiBPbiAyNi8xMC8yMDE0IDg6MDMgUE0sIEFkcmlhbiBGYXJyZWwgd3JvdGU6DQo+ID4gVGhl IGludGVudGlvbiBvZiBMSU1FICh3aG8ga25vd3Mgd2hldGhlciBpdCBpcyBhY2hpZXZhYmxlPykg aXMgdG8gDQo+ID4gcHJvZHVjZSBhIHNpbmdsZSBZQU5HIG1vZHVsZSB0aGF0IHByb3ZpZGVzIGEg Z2VuZXJpYyB3YXkgaW4gdG8gT0FNIA0KPiA+IGFjcm9zcyBhbGwgSUVURiB0ZWNobm9sb2dpZXMu DQo+ID4NCj4gPiBUaGVyZSBhcmUgY2VydGFpbmx5IGEgbnVtYmVyIG9mIGNvcmUgY29uY2VwdHMs IGNvbmZpZ3VyYWJsZSBpdGVtcywgDQo+ID4gYW5kIHJlcG9ydGFibGUgdGhpbmdzIHRoYXQgY2Fu IGJlIHN0YXRlZCBpbiBhIHRlY2hub2xvZ3kgaW5kZXBlbmRlbnQgd2F5Lg0KPiA+DQo+ID4gTElN RSBoYXMgYXMgYSBkZWxpdmVyYWJsZSBhIHNldCBvZiBhcHBsaWNhYmlsaXR5IHN0YXRlbWVudHMg c2hvd2luZyANCj4gPiBob3cgdGhlIGdlbmVyaWMgbW9kdWxlIGlzIGFwcGxpZWQgdG8gZGlmZmVy ZW50IElFVEYgT0FNIHRlY2hub2xvZ2llcy4NCj4gPg0KPiA+IEkgc2hvdWxkIG5vdCBiZSBzdXJw cmlzZWQgaWYgdGVjaG5vbG9neS1zcGVjaWZpYyBtb2R1bGVzIGFyZSBhbHNvIHJlcXVpcmVkLg0K SQ0KPiA+IHRoaW5rIExJTUUgaG9wZXMgdGhhdCB0aGVzZSB3aWxsIGJ1aWxkIG9uIHRoZSBnZW5l cmljIG1vZHVsZSBhbmQgbm90DQpyZWludmVudC4gSQ0KPiA+IGFzc3VtZSB0aGlzIHdpbGwgYmUg dGhyb3VnaCBhdWdtZW50YXRpb24uIEFuZCBJIGFzc3VtZSB0aGUgd29yayB3aWxsIA0KPiA+IGJl IGRvbmUNCj4gYnkNCj4gPiB0aGUgV0dzIHRoYXQgb3duIHRoZSB0ZWNobm9sb2dpZXMgKHdoZXJl IHRob3NlIFdHcyBleGlzdCkuDQo+ID4NCj4gPiBJIGRvbid0IHRoaW5rIEkgdW5kZXJzdGFuZCB5 b3VyIHRyZWUuIFdoeSB3b3VsZCAiUlNWUC1URSBPQU0iIGxpdmUgDQo+ID4gdW5kZXINCj4gcnN2 cC10ZQ0KPiA+IHVuZGVyIG1wbHM/IFRoZSBPQU0gaXMgZ29pbmcgdG8gYmUgc3RhbmRhcmQgbXBs cyBvYW0sIGJ1dCB0aGUgDQo+ID4gY29uY2VwdHMNCj4gKE1JUHMsDQo+ID4gTUVQcywgb24vb2Zm LCBmYWlsdXJlIGZvdW5kLCBldGMuKSBhcmUgZ2VuZXJhbC4NCj4gPg0KPiA+IEFkcmlhbg0KPiA+ DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IFJ0Zy15YW5nLWNv b3JkIFttYWlsdG86cnRnLXlhbmctY29vcmQtYm91bmNlc0BpZXRmLm9yZ10gT24gDQo+ID4+IEJl aGFsZiBPZiBHcmVnb3J5IE1pcnNreQ0KPiA+PiBTZW50OiAyNiBPY3RvYmVyIDIwMTQgMTg6NTEN Cj4gPj4gVG86IExvYSBBbmRlcnNzb247IGxpbWVAaWV0Zi5vcmc7IFJ0Zy15YW5nLWNvb3JkQGll dGYub3JnDQo+ID4+IENjOiBtcGxzQGlldGYub3JnDQo+ID4+IFN1YmplY3Q6IFJlOiBbUnRnLXlh bmctY29vcmRdIGhvcGVmdWxseSBhIHNpbXBsZSBxdWVzdGlvbg0KPiA+Pg0KPiA+PiBIaSBMb2Es DQo+ID4+IEkgdGhpbmsgdGhhdCB5b3VyIHF1ZXN0aW9uIGlzIG5vdCBzaW1wbGUgYXQgYWxsIGFu ZCBpdCB3b3VsZCBiZSBhIA0KPiA+PiBncmVhdCB0bw0KPiA+IGRpc2N1c3MNCj4gPj4gaG93IEdl bmVyaWMgT0FNIHByb3Bvc2FsIGlzIHJlbGF0ZWQgdG8gTVBMUyBPQU0gYXQgdGhlIG1lZXRpbmcu DQo+ID4+IFBlcnNvbmFsbHksIEkgdGhpbmsgdGhhdCB0aGVyZSdzIG5vIHNlcGFyYXRlIExEUCwg UlNWUC1URSBvciBFVlBOLCANCj4gPj4gU2VnbWVudCBSb3V0aW5nIChhcyBmYXIgYXMgdHJhbnNw b3J0IGxheWVyIGZvciB0aGUgbGF0dGVyIHR3bykgT0FNcyANCj4gPj4gYnV0IG9uZSBNUExTDQpP QU0NCj4gPj4gd2l0aCBleHRlbnNpb25zL3NwZWNpYWwgY2FzZXMgZm9yIElQL01QTFMsIE1QTFMt VFAgYW5kIFNlZ21lbnQgDQo+ID4+IFJvdXRpbmcgbmV0d29ya3MuDQo+ID4+DQo+ID4+IAlSZWdh cmRzLA0KPiA+PiAJCUdyZWcNCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4g RnJvbTogUnRnLXlhbmctY29vcmQgW21haWx0bzpydGcteWFuZy1jb29yZC1ib3VuY2VzQGlldGYu b3JnXSBPbiANCj4gPj4gQmVoYWxmIE9mIExvYSBBbmRlcnNzb24NCj4gPj4gU2VudDogU3VuZGF5 LCBPY3RvYmVyIDI2LCAyMDE0IDM6MTQgQU0NCj4gPj4gVG86IGxpbWVAaWV0Zi5vcmc7IFJ0Zy15 YW5nLWNvb3JkQGlldGYub3JnDQo+ID4+IFN1YmplY3Q6IFtSdGcteWFuZy1jb29yZF0gaG9wZWZ1 bGx5IGEgc2ltcGxlIHF1ZXN0aW9uDQo+ID4+DQo+ID4+IEZvbGtzLA0KPiA+Pg0KPiA+PiBJIGhh dmUgd2hhdCBJIGhvcGUgaXMgYSBzaW1wbGUgcXVlc3Rpb24sIGFuZCB0aGF0IGl0IHdpbGwgb25s eSANCj4gPj4gcmV2ZWFsIHRoYXQNCkknbQ0KPiA+IG5vdCB1cA0KPiA+PiB0byBzcGVlZCBvbiB5 YW5nLg0KPiA+Pg0KPiA+PiBJIHRyeWluZyB0byBmaWd1cmUgb3V0IHRoZSByZWxhdGlvbnNoaXAg YmV0d2VlbiB0aGUgZ2VuZXJpYyB5YW5nIA0KPiA+PiBtb2RlbHMgaW4NCj4gPiBlLmcuDQo+ID4+ IGRyYWZ0LXRpc3NhLWxpbWUteWFuZy1vYW0tbW9kZWwgYW5kIHRoZSBzcGVjaWZpYyBtb2RlbHMg d2UgZG8gZm9yIA0KPiA+PiBkaWZmZXJlbnQgdmFyaWFudHMgb2YgZS5nLiBtcGxzIG9hbS4NCj4g Pj4NCj4gPj4gSSBndWVzcyB3ZSBoYXZlIGEgc3RydWN0dXJlIG1vcmUgb3IgbGVzcyBsaWtlIHRo aXMNCj4gPj4NCj4gPj4gbXBscw0KPiA+PiAgICB8DQo+ID4+ICAgIHwtIGxkcA0KPiA+PiAgICB8 ICAgfC1sZHAgb2FtDQo+ID4+ICAgIHwNCj4gPj4gICAgfC0gcnN2cC10ZQ0KPiA+PiAgICB8ICAg fA0KPiA+PiAgICB8ICAgfC0gcnN2cC10ZSBvYW0NCj4gPj4gICAgfA0KPiA+PiAgICB8LSBsc3Ag cGluZw0KPiA+PiAgICB8ICAgfA0KPiA+PiAgICB8ICAgfC0gbHNwIHBpbmcgb2FtDQo+ID4+ICAg IHwNCj4gPj4gICAgfC0gZXRjDQo+ID4+DQo+ID4+DQo+ID4+IFdoZXJlIGRvZXMgdGhlIGdlbmVy aWMgd29yayBmaXQgaW4/DQo+ID4+DQo+ID4+IC9Mb2ENCj4gPj4gLS0NCj4gPj4NCj4gPj4NCj4g Pj4gTG9hIEFuZGVyc3NvbiAgICAgICAgICAgICAgICAgICAgICAgIGVtYWlsOiBsb2FAbWFpbDAx Lmh1YXdlaS5jb20NCj4gPj4gU2VuaW9yIE1QTFMgRXhwZXJ0ICAgICAgICAgICAgICAgICAgICAg ICAgICBsb2FAcGkubnUNCj4gPj4gSHVhd2VpIFRlY2hub2xvZ2llcyAoY29uc3VsdGFudCkgICAg IHBob25lOiArNDYgNzM5IDgxIDIxIDY0DQo+ID4+DQo+ID4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IFJ0Zy15YW5nLWNvb3JkIG1haWxpbmcg bGlzdA0KPiA+PiBSdGcteWFuZy1jb29yZEBpZXRmLm9yZw0KPiA+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Zy15YW5nLWNvb3JkDQo+ID4+DQo+ID4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IFJ0Zy15YW5nLWNv b3JkIG1haWxpbmcgbGlzdA0KPiA+PiBSdGcteWFuZy1jb29yZEBpZXRmLm9yZw0KPiA+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Zy15YW5nLWNvb3JkDQo+ID4NCj4g PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IFJ0 Zy15YW5nLWNvb3JkIG1haWxpbmcgbGlzdA0KPiA+IFJ0Zy15YW5nLWNvb3JkQGlldGYub3JnDQo+ ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGcteWFuZy1jb29yZA0K PiA+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpM aW1lIG1haWxpbmcgbGlzdA0KTGltZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9saW1lDQo= From nobody Sun Oct 26 21:13:21 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1B421A1A93; Sun, 26 Oct 2014 21:13:18 -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 jfZTNRK7Rh2e; Sun, 26 Oct 2014 21:13:16 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EEB61A038C; Sun, 26 Oct 2014 21:13:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5933; q=dns/txt; s=iport; t=1414383197; x=1415592797; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=xo6D1SC2L0WcejSVSiDVjnyXs7pxhYcZ6YVEJn1I1wQ=; b=PHpsdbUQppFQ7uhLC4F71YsqvkJU1bpZCm2JT+jPnuSXkNg1qmWpDO0x Ge/ybmbXi+HRp+8joz1o/5fdokrk74TJTWbsqL9fWf+DmYRZSpwcdkYbV 4h0eBKPadboqdyr7AytlKlAWwI1iFzJ9QhVoOw31xaW0V4W6KLABwk7RS A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAGbFTVStJA2F/2dsb2JhbABcgw5UWATMeAqGeVQCgQ0WAX2EAgEBAQMBAQEBNzEDBAcMAgICAQgRBAEBAQoUCQcbBgYLFAkIAgQBDQUIiCQDCQkNwXYNhjgBAQEBAQEBAQEBAQEBAQEBAQEBAQETBASOSoFYEQEfMQcGgyeBHgWPaYIehEiFAYNCjiCCXYQAg3hsAYEOOYEDAQEB X-IronPort-AV: E=Sophos;i="5.04,792,1406592000"; d="scan'208";a="90526441" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-3.cisco.com with ESMTP; 27 Oct 2014 04:13:16 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s9R4DF5Y006827 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Oct 2014 04:13:15 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.180]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Sun, 26 Oct 2014 23:13:15 -0500 From: "Tissa Senevirathne (tsenevir)" To: "adrian@olddog.co.uk" , "'Tom Taylor'" Thread-Topic: [Lime] [Rtg-yang-coord] hopefully a simple question Thread-Index: AQHP8XszPy1WMZvrkEeOuB7qmsPVxpxDbFOA///nrxA= Date: Mon, 27 Oct 2014 04:13:14 +0000 Message-ID: References: <544CC985.9060808@pi.nu> <7347100B5761DC41A166AC17F22DF1121B86EE25@eusaamb103.ericsson.se> <000601cff179$707a8c10$516fa430$@olddog.co.uk> <544D8EAA.9090909@gmail.com> <000e01cff17d$bd0d5f90$37281eb0$@olddog.co.uk> In-Reply-To: <000e01cff17d$bd0d5f90$37281eb0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.91.179] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/AY0eCpLKaPbncvYCYnYpPNNBgn0 Cc: "Rtg-yang-coord@ietf.org" , "lime@ietf.org" , "netmod@ietf.org" , "david.sinicrope@ericsson.com" Subject: Re: [netmod] [Lime] [Rtg-yang-coord] hopefully a simple question X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 27 Oct 2014 04:13:19 -0000 Thanks Adrian. It is good to see MEF is interested, both MEF and what is presented are us= ing the same root model. However, what is presented in Tissa-yang differs in, 1. It is not tied to Ethernet 2. All of the YANG structures have been revised to be augmentable So, two YANG models are no longer identical, except they share the same roo= t model. When doing TRILL OAM we did a Liaison with IEEE 8021 committee and it was e= xtremely productive and I am sure it will be like that with Liaison with t= he MEF. -----Original Message----- From: Lime [mailto:lime-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Sunday, October 26, 2014 5:34 PM To: 'Tom Taylor' Cc: Rtg-yang-coord@ietf.org; lime@ietf.org; netmod@ietf.org; david.sinicrop= e@ericsson.com Subject: Re: [Lime] [Rtg-yang-coord] hopefully a simple question [Adding Netmod, but removing MPLS] A good pointer, Tom, thanks. The liaison seems to request review and feedback, but I don't see a respons= e from Netmod and it looks like the MEF Technical Committee is meeting toda= y and in the next few days.=20 I think that if LIME had existed at the time the liaison arrived, it is pro= bable that it would also have been a recipient.=20 We should certainly strive to work with MEF and build on existing work. Adrian > -----Original Message----- > From: Tom Taylor [mailto:tom.taylor.stds@gmail.com] > Sent: 27 October 2014 00:16 > To: adrian@olddog.co.uk; 'Gregory Mirsky'; 'Loa Andersson';=20 > lime@ietf.org; Rtg- > yang-coord@ietf.org > Cc: mpls@ietf.org > Subject: Re: [Rtg-yang-coord] hopefully a simple question >=20 > This might be a good time to remind/alert people about the liaison=20 > statement received from the MEF regarding=20 > draft-tissa-lime-yang-oam-model. It can be found at >=20 > https://datatracker.ietf.org/documents/LIAISON/liaison-2014-07-31-mef- > netmod-liaison-to-ietf-on-yang-service-oam-models-attachment-1.pdf >=20 > Tom Taylor >=20 > On 26/10/2014 8:03 PM, Adrian Farrel wrote: > > The intention of LIME (who knows whether it is achievable?) is to=20 > > produce a single YANG module that provides a generic way in to OAM=20 > > across all IETF technologies. > > > > There are certainly a number of core concepts, configurable items,=20 > > and reportable things that can be stated in a technology independent wa= y. > > > > LIME has as a deliverable a set of applicability statements showing=20 > > how the generic module is applied to different IETF OAM technologies. > > > > I should not be surprised if technology-specific modules are also requi= red. I > > think LIME hopes that these will build on the generic module and not reinvent. I > > assume this will be through augmentation. And I assume the work will=20 > > be done > by > > the WGs that own the technologies (where those WGs exist). > > > > I don't think I understand your tree. Why would "RSVP-TE OAM" live=20 > > under > rsvp-te > > under mpls? The OAM is going to be standard mpls oam, but the=20 > > concepts > (MIPs, > > MEPs, on/off, failure found, etc.) are general. > > > > Adrian > > > >> -----Original Message----- > >> From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On=20 > >> Behalf Of Gregory Mirsky > >> Sent: 26 October 2014 18:51 > >> To: Loa Andersson; lime@ietf.org; Rtg-yang-coord@ietf.org > >> Cc: mpls@ietf.org > >> Subject: Re: [Rtg-yang-coord] hopefully a simple question > >> > >> Hi Loa, > >> I think that your question is not simple at all and it would be a=20 > >> great to > > discuss > >> how Generic OAM proposal is related to MPLS OAM at the meeting. > >> Personally, I think that there's no separate LDP, RSVP-TE or EVPN,=20 > >> Segment Routing (as far as transport layer for the latter two) OAMs=20 > >> but one MPLS OAM > >> with extensions/special cases for IP/MPLS, MPLS-TP and Segment=20 > >> Routing networks. > >> > >> Regards, > >> Greg > >> -----Original Message----- > >> From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On=20 > >> Behalf Of Loa Andersson > >> Sent: Sunday, October 26, 2014 3:14 AM > >> To: lime@ietf.org; Rtg-yang-coord@ietf.org > >> Subject: [Rtg-yang-coord] hopefully a simple question > >> > >> Folks, > >> > >> I have what I hope is a simple question, and that it will only=20 > >> reveal that I'm > > not up > >> to speed on yang. > >> > >> I trying to figure out the relationship between the generic yang=20 > >> models in > > e.g. > >> draft-tissa-lime-yang-oam-model and the specific models we do for=20 > >> different variants of e.g. mpls oam. > >> > >> I guess we have a structure more or less like this > >> > >> mpls > >> | > >> |- ldp > >> | |-ldp oam > >> | > >> |- rsvp-te > >> | | > >> | |- rsvp-te oam > >> | > >> |- lsp ping > >> | | > >> | |- lsp ping oam > >> | > >> |- etc > >> > >> > >> Where does the generic work fit in? > >> > >> /Loa > >> -- > >> > >> > >> Loa Andersson email: loa@mail01.huawei.com > >> Senior MPLS Expert loa@pi.nu > >> Huawei Technologies (consultant) phone: +46 739 81 21 64 > >> > >> _______________________________________________ > >> Rtg-yang-coord mailing list > >> Rtg-yang-coord@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtg-yang-coord > >> > >> _______________________________________________ > >> Rtg-yang-coord mailing list > >> Rtg-yang-coord@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > > > _______________________________________________ > > Rtg-yang-coord mailing list > > Rtg-yang-coord@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > _______________________________________________ Lime mailing list Lime@ietf.org https://www.ietf.org/mailman/listinfo/lime From nobody Mon Oct 27 08:19:55 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD5861A906D; Mon, 27 Oct 2014 05:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 nOxGmwOtLL2C; Mon, 27 Oct 2014 05:43:32 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5F21A8AD9; Mon, 27 Oct 2014 05:43:32 -0700 (PDT) Received: from [192.168.1.123] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id CD9C928DB4DC; Mon, 27 Oct 2014 08:43:30 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: "Thomas D. Nadeau" In-Reply-To: <000e01cff17d$bd0d5f90$37281eb0$@olddog.co.uk> Date: Mon, 27 Oct 2014 08:43:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <544CC985.9060808@pi.nu> <7347100B5761DC41A166AC17F22DF1121B86EE25@eusaamb103.ericsson.se> <000601cff179$707a8c10$516fa430$@olddog.co.uk> <544D8EAA.9090909@gmail.com> <000e01cff17d$bd0d5f90$37281eb0$@olddog.co.uk> To: Farrel Adrian X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/OSA3GO13JU5tTTqUOQk5BxAWXas Cc: Rtg-yang-coord@ietf.org, david.sinicrope@ericsson.com, lime@ietf.org, netmod@ietf.org, Tom Taylor Subject: Re: [netmod] [Rtg-yang-coord] hopefully a simple question X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 27 Oct 2014 12:43:35 -0000 > On Oct 26, 2014:8:34 PM, at 8:34 PM, Adrian Farrel = wrote: >=20 > [Adding Netmod, but removing MPLS] >=20 > A good pointer, Tom, thanks. >=20 > The liaison seems to request review and feedback, but I don't see a = response > from Netmod and it looks like the MEF Technical Committee is meeting = today and > in the next few days.=20 We have a draft response that we crafted and posted to the = mailing list, but it seems never was sent out. I will post now to the = list to see if there are any more comments. > I think that if LIME had existed at the time the liaison arrived, it = is probable > that it would also have been a recipient.=20 Should NETMOD respond since it was addressed to us or will LIME = respond? --Tom >=20 > We should certainly strive to work with MEF and build on existing = work. >=20 > Adrian >=20 >> -----Original Message----- >> From: Tom Taylor [mailto:tom.taylor.stds@gmail.com] >> Sent: 27 October 2014 00:16 >> To: adrian@olddog.co.uk; 'Gregory Mirsky'; 'Loa Andersson'; = lime@ietf.org; > Rtg- >> yang-coord@ietf.org >> Cc: mpls@ietf.org >> Subject: Re: [Rtg-yang-coord] hopefully a simple question >>=20 >> This might be a good time to remind/alert people about the liaison >> statement received from the MEF regarding >> draft-tissa-lime-yang-oam-model. It can be found at >>=20 >> = https://datatracker.ietf.org/documents/LIAISON/liaison-2014-07-31-mef- >> netmod-liaison-to-ietf-on-yang-service-oam-models-attachment-1.pdf >>=20 >> Tom Taylor >>=20 >> On 26/10/2014 8:03 PM, Adrian Farrel wrote: >>> The intention of LIME (who knows whether it is achievable?) is to = produce a >>> single YANG module that provides a generic way in to OAM across all = IETF >>> technologies. >>>=20 >>> There are certainly a number of core concepts, configurable items, = and >>> reportable things that can be stated in a technology independent = way. >>>=20 >>> LIME has as a deliverable a set of applicability statements showing = how the >>> generic module is applied to different IETF OAM technologies. >>>=20 >>> I should not be surprised if technology-specific modules are also = required. > I >>> think LIME hopes that these will build on the generic module and not > reinvent. I >>> assume this will be through augmentation. And I assume the work will = be done >> by >>> the WGs that own the technologies (where those WGs exist). >>>=20 >>> I don't think I understand your tree. Why would "RSVP-TE OAM" live = under >> rsvp-te >>> under mpls? The OAM is going to be standard mpls oam, but the = concepts >> (MIPs, >>> MEPs, on/off, failure found, etc.) are general. >>>=20 >>> Adrian >>>=20 >>>> -----Original Message----- >>>> From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On = Behalf Of >>>> Gregory Mirsky >>>> Sent: 26 October 2014 18:51 >>>> To: Loa Andersson; lime@ietf.org; Rtg-yang-coord@ietf.org >>>> Cc: mpls@ietf.org >>>> Subject: Re: [Rtg-yang-coord] hopefully a simple question >>>>=20 >>>> Hi Loa, >>>> I think that your question is not simple at all and it would be a = great to >>> discuss >>>> how Generic OAM proposal is related to MPLS OAM at the meeting. >>>> Personally, I think that there's no separate LDP, RSVP-TE or EVPN, = Segment >>>> Routing (as far as transport layer for the latter two) OAMs but one = MPLS > OAM >>>> with extensions/special cases for IP/MPLS, MPLS-TP and Segment = Routing >>>> networks. >>>>=20 >>>> Regards, >>>> Greg >>>> -----Original Message----- >>>> From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On = Behalf Of >>>> Loa Andersson >>>> Sent: Sunday, October 26, 2014 3:14 AM >>>> To: lime@ietf.org; Rtg-yang-coord@ietf.org >>>> Subject: [Rtg-yang-coord] hopefully a simple question >>>>=20 >>>> Folks, >>>>=20 >>>> I have what I hope is a simple question, and that it will only = reveal that > I'm >>> not up >>>> to speed on yang. >>>>=20 >>>> I trying to figure out the relationship between the generic yang = models in >>> e.g. >>>> draft-tissa-lime-yang-oam-model and the specific models we do for = different >>>> variants of e.g. mpls oam. >>>>=20 >>>> I guess we have a structure more or less like this >>>>=20 >>>> mpls >>>> | >>>> |- ldp >>>> | |-ldp oam >>>> | >>>> |- rsvp-te >>>> | | >>>> | |- rsvp-te oam >>>> | >>>> |- lsp ping >>>> | | >>>> | |- lsp ping oam >>>> | >>>> |- etc >>>>=20 >>>>=20 >>>> Where does the generic work fit in? >>>>=20 >>>> /Loa >>>> -- >>>>=20 >>>>=20 >>>> Loa Andersson email: loa@mail01.huawei.com >>>> Senior MPLS Expert loa@pi.nu >>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>>>=20 >>>> _______________________________________________ >>>> Rtg-yang-coord mailing list >>>> Rtg-yang-coord@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >>>>=20 >>>> _______________________________________________ >>>> Rtg-yang-coord mailing list >>>> Rtg-yang-coord@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >>>=20 >>> _______________________________________________ >>> Rtg-yang-coord mailing list >>> Rtg-yang-coord@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >>>=20 >=20 > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord >=20 From nobody Mon Oct 27 08:19:58 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D50381ACD6D for ; Mon, 27 Oct 2014 07:12: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 tYEwLUNDs5Qu for ; Mon, 27 Oct 2014 07:11:53 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id C7C6D1ACD68 for ; Mon, 27 Oct 2014 07:11:49 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 62BAC128048B; Mon, 27 Oct 2014 15:11:48 +0100 (CET) Date: Mon, 27 Oct 2014 15:11:48 +0100 (CET) Message-Id: <20141027.151148.1950096784827722550.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <5445443.1414193697563.JavaMail.root@mswamui-cedar.atl.sa.earthlink.net> References: <5445443.1414193697563.JavaMail.root@mswamui-cedar.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: http://mailarchive.ietf.org/arch/msg/netmod/he_Jcx2tz_I1YnuqovSyr0ikFT8 Cc: netmod@ietf.org Subject: Re: [netmod] issue Y56 UTF8 non-characters X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 27 Oct 2014 14:12:05 -0000 Randy Presuhn wrote: > Hi - > > >From: Martin Bjorklund > >Sent: Oct 24, 2014 4:22 PM > >To: netmod@ietf.org > >Subject: [netmod] issue Y56 UTF8 non-characters > ... > >I think we should have the same rules for the YANG module as for the > >"string" built-in type. > ... > > I'd question that. For the YANG module itself I think it > would probably be a good idea to specify a normalization form, Ok. What is you suggestion? A YANG module MUST be normalized according to NFC (or which one?) /martin From nobody Mon Oct 27 09:15:13 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3E091A0027; Mon, 27 Oct 2014 09:15: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 Szy2y9ZqHCEu; Mon, 27 Oct 2014 09:15:00 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 920F41A00B0; Mon, 27 Oct 2014 09:14:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=571; q=dns/txt; s=iport; t=1414426479; x=1415636079; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=AlEZ5DLEL+EFbo6hjmfOPZo+R/cPmnC78PC0ZuqjfxM=; b=FcZnNmTR+S4v5rQ69/u6ByB/MgeJizfCxUc9gSMmWkLJqrs2D+RC/sgj KdBCfixwe6EHFQeIPLEWS4Z58u22EL94RfQgcDHkGTLqY/5m6QxtNuAek D5RMDujsJhUlnbUo4ar2OVvsebHTrJfgsDKhkaFz+2sPIdXHYByec5zmh 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAJ1uTlStJA2D/2dsb2JhbABcgw5UWATNPodLAoEdFgF9hAQBBCcTUQEqFEImAQQBGgGIOA3LUgEBAQEGAQEBAR6QV4NlgR4FkgeHC5p9g3hsAYFHgQMBAQE X-IronPort-AV: E=Sophos;i="5.04,796,1406592000"; d="scan'208";a="366773741" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-7.cisco.com with ESMTP; 27 Oct 2014 16:14:38 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s9RGEcmd025043 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Oct 2014 16:14:38 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.58]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Mon, 27 Oct 2014 11:14:38 -0500 From: "Eric Voit (evoit)" To: "netmod@ietf.org" , "Rtg-yang-coord@ietf.org" Thread-Topic: Cloud SLA YANG Model -> incorporating Peer Mount Semantics Thread-Index: Ac/yARgOU8G3L44cRoude7ZtRrZKuQ== Date: Mon, 27 Oct 2014 16:14:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.134.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/FZCAGx5ya3n4wZQNlHxGr1wodbY Subject: [netmod] Cloud SLA YANG Model -> incorporating Peer Mount Semantics X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 27 Oct 2014 16:15:02 -0000 As promised, here is a link to a YANG model which incorporates Mount Semant= ics discussed in previous threads. =20 http://www.ietf.org/internet-drafts/draft-tripathy-cloud-sla-yang-model-00.= txt=20 The goal of this YANG model is to expose both Global and Device config in o= rder to simplify application design for a new class of service offerings. Also of interest in this model is that it shows how to append centrally cal= culated objects to remotely interface objects. (In this case, the remote i= nfo are YANG object from RFC 7223.) Thanks, Eric From nobody Mon Oct 27 10:21:10 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E872B1A6FBF for ; Mon, 27 Oct 2014 10:20:59 -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 bp4SHgMO3vM2 for ; Mon, 27 Oct 2014 10:20:53 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D61721A1BC6 for ; Mon, 27 Oct 2014 10:20:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4156; q=dns/txt; s=iport; t=1414430449; x=1415640049; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=gmg610RaDN47S3dR3VXf/lZnrrYOVAk51KLtKZ1T/wA=; b=VjSXgKUOOyv94syfCSs5w2dlEIextfONyPV7TaNtMkxrBb6fN+vX49M4 Fn+7k9jajm8wp1rkEslzaL9B8KRy28wqxpq8i1d6AXyLhPRDGa7KZqWxi LTr3mapY1yCDJ8MbcjWIuwgDBqNniRxWQsfeDtlNMcWAvkUTxKTTUGXsh 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoQGANh9TlStJA2B/2dsb2JhbABcgw5UWASDAsovCoZ5VAIbgQIWAX2EAwEBBAEBASAROgsSAQgYAgImAgQlCxUQAgQBDQUJiDgNtnuUZAEBAQEBAQEBAQEBAQEBAQEBAQEBAReBLI9BGweCd4FUBZIHhj+FG4Exg0mRNIN4bAGBR4EDAQEB X-IronPort-AV: E=Sophos;i="5.04,797,1406592000"; d="scan'208";a="366842030" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-3.cisco.com with ESMTP; 27 Oct 2014 17:20:48 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s9RHKm1I019201 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Oct 2014 17:20:48 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.11]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Mon, 27 Oct 2014 12:20:47 -0500 From: "Lisa Huang (yihuan)" To: "Dana Blair (dblair)" , "Thomas D. Nadeau" Thread-Topic: [netmod] IETF91 NETMOD agenda ? Thread-Index: Ac/tdoGexyGw623TR4igNJSWn+KnzAAKi72AAFj9fYAAAGUuAAADI+uA///ZpYCAATCsAA== Date: Mon, 27 Oct 2014 17:20:46 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.154.204.124] Content-Type: text/plain; charset="utf-8" Content-ID: <9E5930EF0B43C645BBA2B9C82B2BC840@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/qaNHnxsh6ZWnGz5DTJm_1drqxj8 Cc: "netmod@ietf.org" Subject: Re: [netmod] IETF91 NETMOD 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: Mon, 27 Oct 2014 17:21:00 -0000 VG9tLA0KDQpJcyBpdCBwb3NzaWJsZSB0byBhbGxvY2F0ZSBlYWNoIHRpbWUgc2xvdCB0byBpbmNs dWRlIGJvdGggcHJlc2VudGF0aW9uDQp0aW1lIGFuZCBkaXNjdXNzaW9uIHRpbWUgaW4gYWdlbmRh PyBUaGFua3MsDQoNCkxpc2ENCg0KT24gMTAvMjMvMTQsIDEyOjI2IFBNLCAiRGFuYSBCbGFpciAo ZGJsYWlyKSIgPGRibGFpckBjaXNjby5jb20+IHdyb3RlOg0KDQo+TmVlZCBhYm91dCAxMCBtaW51 dGVzIHRvIGRpc2N1c3MgdGhlIEFDTCBZYW5nIGRyYWZ0DQo+DQo+dGhhbmtzLA0KPkRhbmENCj4N Cj5PbiAxMC8yMy8xNCwgMTo0MyBQTSwgIlRob21hcyBELiBOYWRlYXUiIDx0bmFkZWF1QGx1Y2lk dmlzaW9uLmNvbT4gd3JvdGU6DQo+DQo+Pg0KPj4JV2UgaGF2ZSBwbGVudHkgb2YgcnVud2F5IGlu IHRoZSBhZ2VuZGEgcmlnaHQgbm93IHNvIEkgd2lsbCBwdXQgaXQgZG93bg0KPj5hcyB0d28gaXRl bXMuIFdlIHJlc2VydmVkIHR3byBzbG90cyBiZWNhdXNlIEkgZmVlbCBpdHMgaW1wb3J0YW50IHRv DQo+PmVuY291cmFnZSBkaXNjdXNzaW9uIGR1cmluZyB0aGUgZmFjZTJmYWNlIG1lZXRpbmdzIHNv IGluc29mYXIgYXMgSSBjYW4sIEkNCj4+d2FudCB0byBnaXZlIHlvdSBlbm91Z2ggcnVud2F5IHRv IGRpc2N1c3MgdGhpcyBpbiBkZXRhaWwuDQo+Pg0KPj4JLS1Ub20NCj4+DQo+Pg0KPj4+IE9uIE9j dCAyMywgMjAxNDoxMjoxMyBQTSwgYXQgMTI6MTMgUE0sIExhZGlzbGF2IExob3RrYSA8bGhvdGth QG5pYy5jej4NCj4+Pndyb3RlOg0KPj4+IA0KPj4+IEhpLA0KPj4+IA0KPj4+IGFwYXJ0IGZyb20g dGhlIHR3byBXRyBpdGVtcyBkcmFmdC1pZXRmLW5ldG1vZC1yb3V0aW5nLWNmZy0xNiAodG8gYmUN Cj4+PnN1Ym1pdHRlZCkgYW5kIGRyYWZ0LWlldGYtbmV0bW9kLXlhbmctanNvbi0wMSwgScK5ZCBs aWtlIHRvIGRpc2N1c3MgdGhlDQo+Pj5kcmFmdCBhbmQgZHJhZnQtbGhvdGthLW5ldG1vZC15YW5n LW1ldGFkYXRhLTAwLiBJIHRoaW5rIDUgbWludXRlcyB3b3VsZA0KPj4+YmUgZW5vdWdoIGZvciB0 aGUgbGF0dGVyLCBJIGNvdWxkIGV2ZW4gZG8gaXQgdG9nZXRoZXIgd2l0aCB5YW5nLWpzb24uDQo+ Pj4gDQo+Pj4gVGhhbmtzLCBMYWRhDQo+Pj4gDQo+Pj4gT24gMjMgT2N0IDIwMTQsIGF0IDE4OjAy LCBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbT4gd3JvdGU6DQo+Pj4gDQo+Pj4+IA0K Pj4+PiANCj4+Pj4gT24gVHVlLCBPY3QgMjEsIDIwMTQgYXQgMjozNCBQTSwgVGhvbWFzIEQuIE5h ZGVhdQ0KPj4+Pjx0bmFkZWF1QGx1Y2lkdmlzaW9uLmNvbT4gd3JvdGU6DQo+Pj4+IA0KPj4+PiAJ Tm90IHlldC4gUGxlYXNlIHByb3Bvc2UgdG9waWNzLg0KPj4+PiANCj4+Pj4gDQo+Pj4+IEkgd291 bGQgbGlrZSAxNSBtaW4uIHRvIGRpc2N1c3MgWUFORyBjb25mb3JtYW5jZSBpc3N1ZXMsIHNwZWNp ZmllZCBpbg0KPj4+PnRoaXMgZHJhZnQ6DQo+Pj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJh ZnQtYmllcm1hbi1uZXRtb2QteWFuZy1jb25mb3JtYW5jZS0wNC50eHQNCj4+Pj4gDQo+Pj4+IFRo ZXNlIGlzc3VlcyBtYXkgZ2V0IHJlc29sdmVkIGluIHRoZSBORVRDT05GIFlBTkcgMS4xIHZpcnR1 YWwgaW50ZXJpbQ0KPj4+PiBtZWV0aW5nIG5leHQgd2Vlay4gSWYgbm90LCB0aGlzIHRvcGljIHNo b3VsZCBiZSBkaXNjdXNzZWQgYXQgdGhlIElFVEYNCj4+Pj5tZWV0aW5nLg0KPj4+PiANCj4+Pj4g DQo+Pj4+IAnigLlUb20NCj4+Pj4gDQo+Pj4+IEFuZHkNCj4+Pj4gDQo+Pj4+IA0KPj4+PiANCj4+ Pj4+IE9uIE9jdCAyMSwgMjAxNDo1OjMyIFBNLCBhdCA1OjMyIFBNLCBTdGVybmUsIEphc29uIChK YXNvbikNCj4+Pj4+PGphc29uLnN0ZXJuZUBhbGNhdGVsLWx1Y2VudC5jb20+IHdyb3RlOg0KPj4+ Pj4gDQo+Pj4+PiBIaSBhbGwsDQo+Pj4+PiANCj4+Pj4+IElzIHRoZXJlIGEgcHJlbGltaW5hcnkg YWdlbmRhIGZvciB0aGUgdHdvIE5FVE1PRCBzZXNzaW9ucyBhdCBJRVRGOTEgPw0KPj4+Pj4gICAg DQo+Pj4+PiANCj4+Pj4+IFNvbWUgdGhvdWdodCBhYm91dCB0b3BpY3MgYmVpbmcgc3BsaXQgYmV0 d2VlbiB0aGUgMXN0IChsb25nZXIpIGFuZA0KPj4+Pj4ybmQgKHNob3J0ZXIpIHNlc3Npb25zID8N Cj4+Pj4+IA0KPj4+Pj4gVGhhbmtzLA0KPj4+Pj4gSmFzb24NCj4+Pj4+IA0KPj4+Pj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+IG5ldG1vZCBt YWlsaW5nIGxpc3QNCj4+Pj4+IG5ldG1vZEBpZXRmLm9yZw0KPj4+Pj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4+Pj4gDQo+Pj4+IA0KPj4+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBuZXRtb2QgbWFp bGluZyBsaXN0DQo+Pj4+IG5ldG1vZEBpZXRmLm9yZw0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPj4+PiANCj4+Pj4gDQo+Pj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+IG5ldG1vZCBtYWlsaW5n IGxpc3QNCj4+Pj4gbmV0bW9kQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+Pj4gDQo+Pj4gLS0NCj4+PiBMYWRpc2xhdiBMaG90a2Es IENaLk5JQyBMYWJzDQo+Pj4gUEdQIEtleSBJRDogRTc0RThDMEMNCj4+PiANCj4+PiANCj4+PiAN Cj4+PiANCj4+PiANCj4+DQo+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+Pm5ldG1vZCBtYWlsaW5nIGxpc3QNCj4+bmV0bW9kQGlldGYub3JnDQo+Pmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+DQo+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5uZXRtb2QgbWFpbGluZyBs aXN0DQo+bmV0bW9kQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9uZXRtb2QNCg0K From nobody Mon Oct 27 10:42:03 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42C5C1A802A for ; Mon, 27 Oct 2014 10:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 fwduspSQqbI3 for ; Mon, 27 Oct 2014 10:41:46 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 8BEAF1A7D85 for ; Mon, 27 Oct 2014 10:41:46 -0700 (PDT) Received: from [192.168.1.123] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 9680028DC321; Mon, 27 Oct 2014 13:41:45 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: "Thomas D. Nadeau" In-Reply-To: Date: Mon, 27 Oct 2014 13:41:45 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <06900899-7561-468C-A38A-CC95F1777FCE@lucidvision.com> References: To: "Lisa Huang (yihuan)" X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/rKXw6UMI1p1iJVKEPHEfApjRTq4 Cc: "netmod@ietf.org" Subject: Re: [netmod] IETF91 NETMOD 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: Mon, 27 Oct 2014 17:41:49 -0000 Yes. The idea is to discuss as part of the slot.=20 --tom > On Oct 27, 2014:1:20 PM, at 1:20 PM, Lisa Huang (yihuan) = wrote: >=20 > Tom, >=20 > Is it possible to allocate each time slot to include both presentation > time and discussion time in agenda? Thanks, >=20 > Lisa >=20 > On 10/23/14, 12:26 PM, "Dana Blair (dblair)" wrote: >=20 >> Need about 10 minutes to discuss the ACL Yang draft >>=20 >> thanks, >> Dana >>=20 >> On 10/23/14, 1:43 PM, "Thomas D. Nadeau" = wrote: >>=20 >>>=20 >>> We have plenty of runway in the agenda right now so I will put = it down >>> as two items. We reserved two slots because I feel its important to >>> encourage discussion during the face2face meetings so insofar as I = can, I >>> want to give you enough runway to discuss this in detail. >>>=20 >>> --Tom >>>=20 >>>=20 >>>> On Oct 23, 2014:12:13 PM, at 12:13 PM, Ladislav Lhotka = >>>> wrote: >>>>=20 >>>> Hi, >>>>=20 >>>> apart from the two WG items draft-ietf-netmod-routing-cfg-16 (to be >>>> submitted) and draft-ietf-netmod-yang-json-01, I=C2=B9d like to = discuss the >>>> draft and draft-lhotka-netmod-yang-metadata-00. I think 5 minutes = would >>>> be enough for the latter, I could even do it together with = yang-json. >>>>=20 >>>> Thanks, Lada >>>>=20 >>>> On 23 Oct 2014, at 18:02, Andy Bierman wrote: >>>>=20 >>>>>=20 >>>>>=20 >>>>> On Tue, Oct 21, 2014 at 2:34 PM, Thomas D. Nadeau >>>>> wrote: >>>>>=20 >>>>> Not yet. Please propose topics. >>>>>=20 >>>>>=20 >>>>> I would like 15 min. to discuss YANG conformance issues, specified = in >>>>> this draft: >>>>> = http://www.ietf.org/id/draft-bierman-netmod-yang-conformance-04.txt >>>>>=20 >>>>> These issues may get resolved in the NETCONF YANG 1.1 virtual = interim >>>>> meeting next week. If not, this topic should be discussed at the = IETF >>>>> meeting. >>>>>=20 >>>>>=20 >>>>> =E2=80=B9Tom >>>>>=20 >>>>> Andy >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> On Oct 21, 2014:5:32 PM, at 5:32 PM, Sterne, Jason (Jason) >>>>>> wrote: >>>>>>=20 >>>>>> Hi all, >>>>>>=20 >>>>>> Is there a preliminary agenda for the two NETMOD sessions at = IETF91 ? >>>>>>=20 >>>>>>=20 >>>>>> Some thought about topics being split between the 1st (longer) = and >>>>>> 2nd (shorter) sessions ? >>>>>>=20 >>>>>> Thanks, >>>>>> Jason >>>>>>=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 >>>>>=20 >>>>>=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 >>>>=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 From nobody Mon Oct 27 11:46:49 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 860421ACE51 for ; Mon, 27 Oct 2014 11:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, 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 GREeKfZc-wc9 for ; Mon, 27 Oct 2014 11:46:31 -0700 (PDT) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 389421ACE96 for ; Mon, 27 Oct 2014 11:44:23 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id dc16so4264254qab.18 for ; Mon, 27 Oct 2014 11:44:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=8pgJjMkS4F5zRz1KTCK2jNbY74c2TpvRYzDGSbuHksY=; b=ZHjdkQ3dPsJkZ1WjJr2ATuLXpPgN87Il9Gx2c+5WFCzscwN6/dZxfiiRUEzdY785Za IBIeUEovNgbRZKE32WwPK0vorU4E/RR+YytfXeHO4xj4Fw1shozA0LXySH6odYV7g7DB w8GItdqpJ6GKQw/ysOjcrOoMYhhMnb2yNW15A56yFfXY2tkJKtkB6gvvg8n14iH0wP8H wCDhay86K71xnZoI3iJjVA1+g1nQT3LzOhCHgf7sKwHws97OfJneYtvSdRoc2YOvO/CJ rPFLo1YKMcWrBY6DsJJVwdHTmp6vjQf59VFM1ISzqqk16XKd2+wGr7eajsLQxrUgHGhF Nfow== X-Received: by 10.224.129.195 with SMTP id p3mr35118319qas.66.1414435456739; Mon, 27 Oct 2014 11:44:16 -0700 (PDT) Received: from [10.10.4.191] (50-201-180-2-static.hfc.comcastbusiness.net. [50.201.180.2]) by mx.google.com with ESMTPSA id z32sm11772395qgd.40.2014.10.27.11.44.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Oct 2014 11:44:16 -0700 (PDT) References: <79054E89-2D09-4461-8D35-8F6FA025B71F@nic.cz> <43060BE7-53EA-4B9D-B778-2FED58C0D60C@lucidvision.com> Mime-Version: 1.0 (1.0) In-Reply-To: <43060BE7-53EA-4B9D-B778-2FED58C0D60C@lucidvision.com> Content-Type: multipart/alternative; boundary=Apple-Mail-07A48C5D-5C68-4678-AE88-DD5681658900 Content-Transfer-Encoding: 7bit Message-Id: <52AE09CB-D4AB-4421-BBA4-1D9C45EA6957@gmail.com> X-Mailer: iPad Mail (11D257) From: Mahesh Jethanandani Date: Mon, 27 Oct 2014 14:44:15 -0400 To: "Thomas D. Nadeau" Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Qc_6k2zhG8VchuF7aTffqcqslR4 Cc: "netmod@ietf.org" Subject: Re: [netmod] IETF91 NETMOD 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: Mon, 27 Oct 2014 18:46:34 -0000 --Apple-Mail-07A48C5D-5C68-4678-AE88-DD5681658900 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Tom, I am giving an update on the BFD YANG model in the BFD WG. I can give a quic= k update (~1-2min) in NETMOD if such an update is desired. Mahesh Jethanandani mjethanandani@gmail.com > On Oct 23, 2014, at 1:43 PM, "Thomas D. Nadeau" w= rote: >=20 >=20 > We have plenty of runway in the agenda right now so I will put it down a= s two items. We reserved two slots because I feel its important to encourage= discussion during the face2face meetings so insofar as I can, I want to giv= e you enough runway to discuss this in detail.=20 >=20 > --Tom >=20 >=20 >> On Oct 23, 2014:12:13 PM, at 12:13 PM, Ladislav Lhotka wr= ote: >>=20 >> Hi, >>=20 >> apart from the two WG items draft-ietf-netmod-routing-cfg-16 (to be submi= tted) and draft-ietf-netmod-yang-json-01, I=E2=80=99d like to discuss the dr= aft and draft-lhotka-netmod-yang-metadata-00. I think 5 minutes would be eno= ugh for the latter, I could even do it together with yang-json. >>=20 >> Thanks, Lada >>=20 >>> On 23 Oct 2014, at 18:02, Andy Bierman wrote: >>>=20 >>>=20 >>>=20 >>> On Tue, Oct 21, 2014 at 2:34 PM, Thomas D. Nadeau wrote: >>>=20 >>> Not yet. Please propose topics.=20 >>>=20 >>>=20 >>> I would like 15 min. to discuss YANG conformance issues, specified in th= is draft: >>> http://www.ietf.org/id/draft-bierman-netmod-yang-conformance-04.txt >>>=20 >>> These issues may get resolved in the NETCONF YANG 1.1 virtual interim >>> meeting next week. If not, this topic should be discussed at the IETF me= eting. >>>=20 >>>=20 >>> =E2=80=94Tom >>>=20 >>> Andy >>>=20 >>>=20 >>>=20 >>>> On Oct 21, 2014:5:32 PM, at 5:32 PM, Sterne, Jason (Jason) wrote: >>>>=20 >>>> Hi all, >>>>=20 >>>> Is there a preliminary agenda for the two NETMOD sessions at IETF91 ? = =20 >>>>=20 >>>> Some thought about topics being split between the 1st (longer) and 2nd (= shorter) sessions ? >>>>=20 >>>> Thanks, >>>> Jason >>>>=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 >>>=20 >>>=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 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --Apple-Mail-07A48C5D-5C68-4678-AE88-DD5681658900 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Tom,

I am giv= ing an update on the BFD YANG model in the BFD WG. I can give a quick update= (~1-2min) in NETMOD if such an update is desired.

Mahesh Jethanandani

On Oct 23, 2014, at 1:43 PM,= "Thomas D. Nadeau" <tnadeau@l= ucidvision.com> wrote:


   We have plenty of runway in the agenda ri= ght now so I will put it down as two items. We reserved two slots because I f= eel its important to encourage discussion during the face2face meetings so i= nsofar as I can, I want to give you enough runway to discuss this in detail.=

   --Tom


On Oct 23, 2014:12:13= PM, at 12:13 PM, Ladislav Lhotka <lhotk= a@nic.cz> wrote:

Hi,

apart from the two WG items draft-ietf-netmod-routing-= cfg-16 (to be submitted) and draft-ietf-netmod-yang-json-01, I=E2=80=99d lik= e to discuss the draft and draft-lhotka-netmod-yang-metadata-00. I think 5 m= inutes would be enough for the latter, I could even do it together with yang= -json.

Thanks, Lada

On 23 Oct 2014, at 18:02, Andy Bierman <andy@yumaworks.com> wrote:
<= blockquote type=3D"cite">


O= n Tue, Oct 21, 2014 at 2:34 PM, Thomas D. Nadeau <tnadeau@lucidvision.com> wrote:

   Not yet. Please propose topics.
=


I would like 15 min. to discuss= YANG conformance issues, specified in this draft:
htt= p://www.ietf.org/id/draft-bierman-netmod-yang-conformance-04.txt<= br>

These issues may get resolved in the NETCONF Y= ANG 1.1 virtual interim
meeting next week. If not, this to= pic should be discussed at the IETF meeting.

=
   =E2=80=94Tom
<= /blockquote>

Andy



On Oct 21, 2014:5:32 PM, at 5:32 P= M, Sterne, Jason (Jason) <jason.sterne@alcatel-lucent.com> wrote:
=

Hi all,

Is there a preli= minary agenda for the two NETMOD sessions at IETF91 ?    &nbs= p;

Some thought about topics being sp= lit between the 1st (longer) and 2nd (shorter) sessions ?

=
Thanks,
Jason

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


________= _______________________________________
=
netmod mailing lis= t
netmod@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/netmod

<= /blockquote>

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

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





=
_______________________________________________
ne= tmod mailing list
netmod@= ietf.org
https://www.ietf.org/mailman/listinfo/netmod
<= /blockquote>= --Apple-Mail-07A48C5D-5C68-4678-AE88-DD5681658900-- From nobody Mon Oct 27 12:15:44 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3201A03A7 for ; Mon, 27 Oct 2014 12:15: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, 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 YKmxUR0Un_m9 for ; Mon, 27 Oct 2014 12:15:04 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9601A1BF5 for ; Mon, 27 Oct 2014 12:14:36 -0700 (PDT) Received: from [192.168.1.123] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 6032728DC6E8; Mon, 27 Oct 2014 15:14:35 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_27CBFE5F-00C0-4E3A-9C71-AB44AE004E33" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: "Thomas D. Nadeau" In-Reply-To: <52AE09CB-D4AB-4421-BBA4-1D9C45EA6957@gmail.com> Date: Mon, 27 Oct 2014 15:14:35 -0400 Message-Id: <6070B212-8F30-4090-8CEA-F2C9DC65EDBF@lucidvision.com> References: <79054E89-2D09-4461-8D35-8F6FA025B71F@nic.cz> <43060BE7-53EA-4B9D-B778-2FED58C0D60C@lucidvision.com> <52AE09CB-D4AB-4421-BBA4-1D9C45EA6957@gmail.com> To: Mahesh Jethanandani X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/7aLKttVz-dQibg2ZlO6w9b4Wp_o Cc: "netmod@ietf.org" Subject: Re: [netmod] IETF91 NETMOD 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: Mon, 27 Oct 2014 19:15:14 -0000 --Apple-Mail=_27CBFE5F-00C0-4E3A-9C71-AB44AE004E33 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 ack > On Oct 27, 2014:2:44 PM, at 2:44 PM, Mahesh Jethanandani = wrote: >=20 > Tom, >=20 > I am giving an update on the BFD YANG model in the BFD WG. I can give = a quick update (~1-2min) in NETMOD if such an update is desired. >=20 > Mahesh Jethanandani > mjethanandani@gmail.com >=20 > On Oct 23, 2014, at 1:43 PM, "Thomas D. Nadeau" = > wrote: >=20 >>=20 >> We have plenty of runway in the agenda right now so I will put it = down as two items. We reserved two slots because I feel its important to = encourage discussion during the face2face meetings so insofar as I can, = I want to give you enough runway to discuss this in detail.=20 >>=20 >> --Tom >>=20 >>=20 >>> On Oct 23, 2014:12:13 PM, at 12:13 PM, Ladislav Lhotka = > wrote: >>>=20 >>> Hi, >>>=20 >>> apart from the two WG items draft-ietf-netmod-routing-cfg-16 (to be = submitted) and draft-ietf-netmod-yang-json-01, I=E2=80=99d like to = discuss the draft and draft-lhotka-netmod-yang-metadata-00. I think 5 = minutes would be enough for the latter, I could even do it together with = yang-json. >>>=20 >>> Thanks, Lada >>>=20 >>> On 23 Oct 2014, at 18:02, Andy Bierman > wrote: >>>=20 >>>>=20 >>>>=20 >>>> On Tue, Oct 21, 2014 at 2:34 PM, Thomas D. Nadeau = > wrote: >>>>=20 >>>> Not yet. Please propose topics.=20 >>>>=20 >>>>=20 >>>> I would like 15 min. to discuss YANG conformance issues, specified = in this draft: >>>> http://www.ietf.org/id/draft-bierman-netmod-yang-conformance-04.txt = >>>>=20 >>>> These issues may get resolved in the NETCONF YANG 1.1 virtual = interim >>>> meeting next week. If not, this topic should be discussed at the = IETF meeting. >>>>=20 >>>>=20 >>>> =E2=80=94Tom >>>>=20 >>>> Andy >>>>=20 >>>>=20 >>>>=20 >>>>> On Oct 21, 2014:5:32 PM, at 5:32 PM, Sterne, Jason (Jason) = > wrote: >>>>>=20 >>>>> Hi all, >>>>>=20 >>>>> Is there a preliminary agenda for the two NETMOD sessions at = IETF91 ? =20 >>>>>=20 >>>>> Some thought about topics being split between the 1st (longer) and = 2nd (shorter) sessions ? >>>>>=20 >>>>> Thanks, >>>>> Jason >>>>>=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 = >>>>=20 >>>>=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 >>>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod = --Apple-Mail=_27CBFE5F-00C0-4E3A-9C71-AB44AE004E33 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 ack

On Oct 27, 2014:2:44 PM, at = 2:44 PM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:

Tom,

I am giving an update on = the BFD YANG model in the BFD WG. I can give a quick update (~1-2min) in = NETMOD if such an update is desired.

Mahesh Jethanandani
mjethanandani@gmail.com

On Oct 23, 2014, at 1:43 PM, "Thomas D. = Nadeau" <tnadeau@lucidvision.com> wrote:


=    We have plenty of runway in the agenda right now so I will = put it down as two items. We reserved two slots because I feel its = important to encourage discussion during the face2face meetings so = insofar as I can, I want to give you enough runway to discuss this in = detail.

   --Tom


On Oct = 23, 2014:12:13 PM, at 12:13 PM, Ladislav Lhotka <lhotka@nic.cz> = wrote:

Hi,

apart from the two WG items = draft-ietf-netmod-routing-cfg-16 (to be submitted) and = draft-ietf-netmod-yang-json-01, I=E2=80=99d like to discuss the draft = and draft-lhotka-netmod-yang-metadata-00. I think 5 minutes would be = enough for the latter, I could even do it together with = yang-json.

Thanks, Lada

On 23 Oct 2014, at 18:02, Andy Bierman = <andy@yumaworks.com> wrote:



On Tue, Oct 21, 2014 at 2:34 PM, Thomas D. Nadeau <tnadeau@lucidvision.com> wrote:

   Not yet. Please propose topics.


I would like 15 min. to discuss YANG conformance issues, = specified in this draft:
http://www.ietf.org/id/draft-bierman-netmod-yang-conformance-04= .txt

These issues may get resolved in the NETCONF YANG 1.1 virtual = interim
meeting next week. If not, this topic should be discussed at = the IETF meeting.


   =E2=80=94Tom

Andy



On Oct 21, 2014:5:32 PM, at = 5:32 PM, Sterne, Jason (Jason) <jason.sterne@alcatel-lucent.com> wrote:

Hi all,

Is there a preliminary agenda = for the two NETMOD sessions at IETF91 ? =     

Some thought about topics = being split between the 1st (longer) and 2nd (shorter) sessions = ?

Thanks,
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

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






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

= --Apple-Mail=_27CBFE5F-00C0-4E3A-9C71-AB44AE004E33-- From nobody Mon Oct 27 12:21:20 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 303FA1AD09B for ; Mon, 27 Oct 2014 12:20: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 sW_NNW2fKrud for ; Mon, 27 Oct 2014 12:20:52 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F8801AD045 for ; Mon, 27 Oct 2014 12:20:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1591; q=dns/txt; s=iport; t=1414437605; x=1415647205; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=h7aPFPvUNSabm7msFerYO68QZeNnr2Zk2PaIAgVV4pk=; b=KKjxGIF30mFZ3gCertnTwYA1nZmKqSOKnUzqGh1wuRVImkT+F2Qj6SQk DoMGv5cIu9BH8K5MPHaGgn/ZYFxnl6AEKg3wJjoPcIQI7Zba4LyfwYsok ggYZHIPfeORyelDV84xUGmrq9n4kQ8zIPoRjhb39umkrH3LnvMi/y4mSo k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwFAAOaTlStJA2H/2dsb2JhbABcgmsjVFMFBM08h0sCgR0WAXILhAMBAQR3EgIBCEYyGwEGAwIEEwmIOAEHBctgAQEBAQEBBAEBAQEBARyRD4RLBYsmhmGESIcSgTE8gw2RNIN4bAGBR4EDAQEB X-IronPort-AV: E=Sophos;i="5.04,797,1406592000"; d="scan'208";a="90775034" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-2.cisco.com with ESMTP; 27 Oct 2014 19:20:04 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s9RJK4Oa029257 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 27 Oct 2014 19:20:04 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Mon, 27 Oct 2014 14:20:04 -0500 From: "Clyde Wildes (cwildes)" To: "netmod@ietf.org" Thread-Topic: New Version Notification for draft-wildes-netmod-syslog-model-05.txt Thread-Index: AQHP8g4pptAmm5QTEk6rOjhPf228QZxEMF6A Date: Mon, 27 Oct 2014 19:20:03 +0000 Message-ID: References: <20141027174619.6452.90477.idtracker@ietfa.amsl.com> In-Reply-To: <20141027174619.6452.90477.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.27.7.183] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/xQuePPjBXevpTxD3j3EIl3A47WI Subject: [netmod] FW: New Version Notification for draft-wildes-netmod-syslog-model-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, 27 Oct 2014 19:20:54 -0000 A new version of "draft-wildes-netmod-syslog-model" has been uploaded. Key changes include: - updated "section 5 =AD implementation status" to reflect the new leaf nam= es - updated "section 8 =AD acknowledgements" to thank Alex Clemm from Cisco - updated "section 10 =AD References" to add several references that were missing - fixed some minor typos in the ietf-syslog.yang model description fields Thanks, Clyde On 10/27/14, 10:46 AM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-wildes-netmod-syslog-model-05.txt >has been successfully submitted by Kiran Agrahara Sreenivasa and posted >to the >IETF repository. > >Name: draft-wildes-netmod-syslog-model >Revision: 05 >Title: SYSLOG YANG model >Document date: 2014-10-27 >Group: Individual Submission >Pages: 21 >URL: =20 >http://www.ietf.org/internet-drafts/draft-wildes-netmod-syslog-model-05.tx >t >Status: =20 >https://datatracker.ietf.org/doc/draft-wildes-netmod-syslog-model/ >Htmlized: =20 >http://tools.ietf.org/html/draft-wildes-netmod-syslog-model-05 >Diff: =20 >http://www.ietf.org/rfcdiff?url2=3Ddraft-wildes-netmod-syslog-model-05 > >Abstract: > This document describes a data model for Syslog > protocol which is used to convey event notification messages. > > =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 Mon Oct 27 15:06:51 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34DD01A0140 for ; Mon, 27 Oct 2014 15:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.14 X-Spam-Level: * X-Spam-Status: No, score=1.14 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, 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 Sl-kO05cUyM6 for ; Mon, 27 Oct 2014 15:06:36 -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 192E41A039A for ; Mon, 27 Oct 2014 15:06:21 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B7F6D8F2 for ; Mon, 27 Oct 2014 23:06:19 +0100 (CET) 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 34bNKSmITssn for ; Mon, 27 Oct 2014 23:06:14 +0100 (CET) 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, 27 Oct 2014 23:06:18 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id D4CF220037 for ; Mon, 27 Oct 2014 23:06:18 +0100 (CET) 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 8Ws2FbzBRFz4; Mon, 27 Oct 2014 23:06:18 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B2DA320035; Mon, 27 Oct 2014 23:06:17 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0B0FA2F14F62; Mon, 27 Oct 2014 23:06:15 +0100 (CET) Date: Mon, 27 Oct 2014 23:06:15 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20141027220615.GB10028@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="gBBFr7Ir9EOA20Yy" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/vwznJyeYKomlIYCUz6IiGK31JBc Subject: [netmod] yang 1.1 webex on wednesday october 29th 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, 27 Oct 2014 22:06:38 -0000 --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline During the last YANG 1.1 virtual interim meeting, we discussed to have another meeting to talk about the conformance related issues. Unfortunately, the series of virtual interim meetings allocated for YANG 1.1 work did end last Wednesday and since scheduling a virtual interim meeting requires two weeks of advance notice, we can't have an official virtual interim meeting on Wednesday. However, in order to not loose traction, I like to invite all people interested in this topic to an inofficial webex meeting taking place on Wednesday at 16:00 CET, which will run for at most two hours. While I will write the usual minutes, this is not an official virtual interim meeting. But hopefully this ad-hoc webex helps to come to a clearer view on how to move forward with the conformance related issues. I am attaching the webex information. The webex information is different from the previous virtual interim meeting webex info - so please make sure to join the correct webex meeting. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="webex.txt" ******* DO NOT DELETE OR CHANGE ANY OF THE TEXT BELOW THIS LINE ******* ----------------------------------------------------------------------- JOIN USING WebEx Go To: https://cisco.webex.com/cisco/j.php?MTID=m6ea214f8e097453994e88aa706a7bcad Meeting Password ----- 1234 Meeting Number ----- 201 602 421 ---------------------------------------------------------------- ALERT - PLEASE READ: DO NOT DIAL THE TOLL FREE NUMBERS FROM WITHIN THE (408) OR (919) AREA CODES ---------------------------------------------------------------- Please dial the local access number for your area from the list below: - San Jose/Milpitas (408) area: 525-6800 - RTP (919) area: 392-3330 Dialing the WebEx toll free numbers from within 408 or 919 area codes is not enabled (non-Cisco phones). " If you dial the toll-free numbers within the 408 or 919 area codes you will be instructed to hang up and dial the local access number." Please use the call-back option whenever possible and otherwise dial local numbers only. The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpitas area and (866) 349-3520 for the RTP area. ------------------------------------------------------- To join the teleconference only ------------------------------------------------------- 1. Dial into Cisco WebEx (view all Global Access Numbers at http://cisco.com/en/US/about/doing_business/conferencing/index.html 2. Follow the prompts to enter the Meeting Number (listed above) or Access Code followed by the # sign. San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 India: +91.80.4350.1111 Germany: +49.619.6773.9002 Japan: +81.3.5763.9394 China: +86.10.8515.5666 IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. --gBBFr7Ir9EOA20Yy-- From nobody Mon Oct 27 17:21:27 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ECBB1A87CA for ; Mon, 27 Oct 2014 17:21:23 -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 o8rrkk67ePhi for ; Mon, 27 Oct 2014 17:21:21 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EA1F1A87BD for ; Mon, 27 Oct 2014 17:21:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2964; q=dns/txt; s=iport; t=1414455681; x=1415665281; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=vJ/H1ZyDVB6/E86gp2d0EcGMHljm3QLjCw7DnO2iuiA=; b=QJtm0Z3lA4mMD/j+jGsq/0/CQ+8XZD5CBrNlV34hTyKx+XMjdKC9wZEg Y7gJ5fTyTPyBEtE4YlzXl7zuGaZh21ATP0EhTi+2BWxSX61VETA9uae6N 3VOKgqbsK1JJgZZyVE6g3fCf+wO8t58yOYsbRMlXct5932Gum8wSjMxB6 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArMGAIjgTlStJV2c/2dsb2JhbABcgw5UWASDAspXh0sCG30WAXILhAIBAQEEIxFDAgwEAgEIEQQBAQMCBgIBGgMCAgIwFAEGAQEFAwIEDgUIAYg4DbYtlQQBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSyPKzEHBoJxNoEeBZIHhEiIQzyDDZE0g3hsAYFHgQMBAQE X-IronPort-AV: E=Sophos;i="5.04,799,1406592000"; d="scan'208";a="366908289" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 28 Oct 2014 00:21:20 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s9S0LKg0003329 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 28 Oct 2014 00:21:20 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.195]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Mon, 27 Oct 2014 19:21:20 -0500 From: "Alexander Clemm (alex)" To: "netmod@ietf.org" Thread-Topic: New Version Notification for draft-netmod-clemm-datastore-push-00.txt Thread-Index: AQHP8jjUrJbP6cVOcUSmrTGxPz/z8pxEpE5A Date: Tue, 28 Oct 2014 00:21:19 +0000 Message-ID: References: <20141027225317.30318.57199.idtracker@ietfa.amsl.com> In-Reply-To: <20141027225317.30318.57199.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.205.76] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/md8rDYqyfbocJOeRlg68_VebpRs Cc: "Alberto Gonzalez Prieto \(albertgo\)" Subject: [netmod] FW: New Version Notification for draft-netmod-clemm-datastore-push-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: Tue, 28 Oct 2014 00:21:23 -0000 SGksDQoNCmFzIGluZGljYXRlZCBvbiBGcmlkYXkgYnkgRXJpYywgd2UgaGF2ZSBwb3N0ZWQgYSBk cmFmdCBlYXJsaWVyIHRvZGF5IHJlZ2FyZGluZyB0aGUgYWJpbGl0eSB0byBzdWJzY3JpYmUgdG8g WUFORyBkYXRhc3RvcmUgcHVzaCB1cGRhdGVzLiAgVGhlIGlkZWEgaGVyZSBpcyB0byBhbGxvdyBj bGllbnRzIHRvIHN1YnNjcmliZSB0byBkYXRhc3RvcmUgdXBkYXRlcyB0aGF0IGNvbmNlcm4gbm90 IGp1c3QgY29uZmlndXJhdGlvbiwgYnV0IHNwZWNpZmljYWxseSBvcGVyYXRpb25hbCBkYXRhLCB3 aGljaCBpcyB0aGVuICJwdXNoZWQiIChvciAic3RyZWFtZWQiKSBmcm9tIHNlcnZlcnMgdG8gY2xp ZW50cy4gIFRoaXMgY2FwYWJpbGl0eSBpcyBuZWVkZWQgaW4gaW1wbGVtZW50YXRpb25zIG9mIHBl ZXIgbW91bnQgdGhhdCBhaW0gdG8gY2FjaGUgaW5mb3JtYXRpb24gYXQgdGhlIGNsaWVudCwgYnV0 IGlzIGFwcGxpY2FibGUgYmV5b25kIHRoYXQsIGZvciBleGFtcGxlIHRvIGFwcGxpY2F0aW9ucyB0 aGF0IHJlbGF0ZWQgdG8gc2VydmljZSBhc3N1cmFuY2UsIHRoYXQgbWlnaHQgb3RoZXJ3aXNlIGhh dmUgdG8gcmV2ZXJ0IHRvIHBvbGxpbmcuICANCg0KS2luZCByZWdhcmRzDQotLS0gQWxleA0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn IFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IE1vbmRheSwgT2N0b2Jl ciAyNywgMjAxNCAzOjUzIFBNDQpUbzogQWxleGFuZGVyIENsZW1tIChhbGV4KTsgQWxiZXJ0byBH b256YWxleiBQcmlldG8gKGFsYmVydGdvKTsgQWxiZXJ0byBHb256YWxleiBQcmlldG8gKGFsYmVy dGdvKTsgRXJpYyBWb2l0IChldm9pdCk7IEFsZXhhbmRlciBDbGVtbSAoYWxleCk7IEVyaWMgVm9p dCAoZXZvaXQpDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LW5l dG1vZC1jbGVtbS1kYXRhc3RvcmUtcHVzaC0wMC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEkt RCwgZHJhZnQtbmV0bW9kLWNsZW1tLWRhdGFzdG9yZS1wdXNoLTAwLnR4dA0KaGFzIGJlZW4gc3Vj Y2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBBbGV4YW5kZXIgQ2xlbW0gYW5kIHBvc3RlZCB0byB0aGUg SUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtbmV0bW9kLWNsZW1tLWRhdGFzdG9yZS1w dXNoDQpSZXZpc2lvbjoJMDANClRpdGxlOgkJU3Vic2NyaWJpbmcgdG8gZGF0YXN0b3JlIHB1c2gg dXBkYXRlcw0KRG9jdW1lbnQgZGF0ZToJMjAxNC0xMC0yNw0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1 Ym1pc3Npb24NClBhZ2VzOgkJMTgNClVSTDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1uZXRtb2QtY2xlbW0tZGF0YXN0b3JlLXB1c2gtMDAudHh0 DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt bmV0bW9kLWNsZW1tLWRhdGFzdG9yZS1wdXNoLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LW5ldG1vZC1jbGVtbS1kYXRhc3RvcmUtcHVzaC0wMA0KDQoN CkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgc3Vic2NyaXB0aW9uIGFuZCBw dXNoIG1lY2hhbmlzbSBmb3INCiAgIGRhdGFzdG9yZXMuICBUaGlzIG1lY2hhbmlzbSBhbGxvd3Mg Y2xpZW50IGFwcGxpY2F0aW9ucyB0byByZXF1ZXN0DQogICB1cGRhdGVzIGZyb20gYSBkYXRhc3Rv cmUsIHdoaWNoIGFyZSB0aGVuIHB1c2hlZCBieSB0aGUgc2VydmVyIHRvIHRoZQ0KICAgY2xpZW50 IHBlciBhIHN1YnNjcmlwdGlvbiBwb2xpY3ksIHdpdGhvdXQgcmVxdWlyaW5nIGFkZGl0aW9uYWwg Y2xpZW50DQogICByZXF1ZXN0cy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBs ZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0 aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJl IGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Tue Oct 28 13:29:26 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3931ACE87 for ; Tue, 28 Oct 2014 13:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 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_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 o2PlU0pIzcx1 for ; Tue, 28 Oct 2014 13:29:21 -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 5D5D71ACED3 for ; Tue, 28 Oct 2014 13:24:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=sNhs4kGyeCOoGtfCqP2WRnQRYGcSikRgw4VCm6eQO4sdQGvhC+ok7yn+/c/+magR; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.39] (helo=elwamui-little.atl.sa.earthlink.net) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1XjDJZ-00047M-EO; Tue, 28 Oct 2014 16:24:25 -0400 Received: from 76.254.52.158 by webmail.earthlink.net with HTTP; Tue, 28 Oct 2014 16:24:24 -0400 Message-ID: <12967085.1414527865425.JavaMail.root@elwamui-little.atl.sa.earthlink.net> Date: Tue, 28 Oct 2014 13:24:24 -0700 (GMT-07:00) From: Randy Presuhn To: Martin Bjorklund 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88825aa8a2065c9591ffed6e142525a78e138ed2f974449ca5f350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.39 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/6je0mU-S294ibavGoLdolcyaK-Q Cc: netmod@ietf.org Subject: Re: [netmod] issue Y56 UTF8 non-characters 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, 28 Oct 2014 20:29:23 -0000 Hi - >From: Martin Bjorklund >Sent: Oct 27, 2014 7:11 AM >To: randy_presuhn@mindspring.com >Cc: netmod@ietf.org >Subject: Re: [netmod] issue Y56 UTF8 non-characters > >Randy Presuhn wrote: >> Hi - >> >> >From: Martin Bjorklund >> >Sent: Oct 24, 2014 4:22 PM >> >To: netmod@ietf.org >> >Subject: [netmod] issue Y56 UTF8 non-characters >> ... >> >I think we should have the same rules for the YANG module as for the >> >"string" built-in type. >> ... >> >> I'd question that. For the YANG module itself I think it >> would probably be a good idea to specify a normalization form, > >Ok. What is you suggestion? A YANG module MUST be normalized >according to NFC (or which one?) I'd have a *very* slight preference for NFD, since it looks a bit easier to generate according to http://www.unicode.org/reports/tr15/ but I think it would be good to ask an expert. Probably the most important thing is to just *pick* *one*. In any case, this needs to be in narrower terms than "YANG module". It would not be good to break RFC 6020 section 9.4.2. Randy From nobody Tue Oct 28 13:43:51 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BADF51A8A04 for ; Tue, 28 Oct 2014 13:43: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 nM8RbdanBDr8 for ; Tue, 28 Oct 2014 13:43:43 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5D11A89C6 for ; Tue, 28 Oct 2014 13:43:43 -0700 (PDT) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id E4FCF1280382; Tue, 28 Oct 2014 21:43:41 +0100 (CET) Date: Tue, 28 Oct 2014 21:43:41 +0100 (CET) Message-Id: <20141028.214341.185747851.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <12967085.1414527865425.JavaMail.root@elwamui-little.atl.sa.earthlink.net> References: <12967085.1414527865425.JavaMail.root@elwamui-little.atl.sa.earthlink.net> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ApEUqd97PVHI9AEWKi_RykL0eZo Cc: netmod@ietf.org Subject: Re: [netmod] issue Y56 UTF8 non-characters X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 28 Oct 2014 20:43:47 -0000 Randy Presuhn wrote: > Hi - > > >From: Martin Bjorklund > >Sent: Oct 27, 2014 7:11 AM > >To: randy_presuhn@mindspring.com > >Cc: netmod@ietf.org > >Subject: Re: [netmod] issue Y56 UTF8 non-characters > > > >Randy Presuhn wrote: > >> Hi - > >> > >> >From: Martin Bjorklund > >> >Sent: Oct 24, 2014 4:22 PM > >> >To: netmod@ietf.org > >> >Subject: [netmod] issue Y56 UTF8 non-characters > >> ... > >> >I think we should have the same rules for the YANG module as for the > >> >"string" built-in type. > >> ... > >> > >> I'd question that. For the YANG module itself I think it > >> would probably be a good idea to specify a normalization form, > > > >Ok. What is you suggestion? A YANG module MUST be normalized > >according to NFC (or which one?) > > I'd have a *very* slight preference for NFD, since it looks a bit > easier to generate according to http://www.unicode.org/reports/tr15/ > but I think it would be good to ask an expert. Probably the most > important thing is to just *pick* *one*. Ok. > In any case, this needs to be in narrower terms than "YANG module". Can you elaborate, I do not understand what you mean. > It would not be good to break RFC 6020 section 9.4.2. ... specifically I do not understand how this section would be affected? /martin From nobody Tue Oct 28 13:46:50 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40FF51A8A71 for ; Tue, 28 Oct 2014 13:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, 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 WiYu-bM4dXTH for ; Tue, 28 Oct 2014 13:46:46 -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 4980C1A8F3F for ; Tue, 28 Oct 2014 13:46: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 9E7B81022; Tue, 28 Oct 2014 21:46:44 +0100 (CET) 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 PR9uErYTWK40; Tue, 28 Oct 2014 21:46:33 +0100 (CET) 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, 28 Oct 2014 21:46:44 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id EE5A720038; Tue, 28 Oct 2014 21:46:43 +0100 (CET) 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 orOeZo-B26Et; Tue, 28 Oct 2014 21:45:59 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7564820035; Tue, 28 Oct 2014 21:46:42 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 330DA2F17B54; Tue, 28 Oct 2014 21:46:39 +0100 (CET) Date: Tue, 28 Oct 2014 21:46:38 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20141028204635.GE15070@elstar.local> Mail-Followup-To: Martin Bjorklund , randy_presuhn@mindspring.com, netmod@ietf.org References: <12967085.1414527865425.JavaMail.root@elwamui-little.atl.sa.earthlink.net> <20141028.214341.185747851.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141028.214341.185747851.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/quZK7vJncnsHwS5LFboDTaYey30 Cc: randy_presuhn@mindspring.com, netmod@ietf.org Subject: Re: [netmod] issue Y56 UTF8 non-characters 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, 28 Oct 2014 20:46:48 -0000 On Tue, Oct 28, 2014 at 09:43:41PM +0100, Martin Bjorklund wrote: > Randy Presuhn wrote: > > Hi - > > > > >From: Martin Bjorklund > > >Sent: Oct 27, 2014 7:11 AM > > >To: randy_presuhn@mindspring.com > > >Cc: netmod@ietf.org > > >Subject: Re: [netmod] issue Y56 UTF8 non-characters > > > > > >Randy Presuhn wrote: > > >> Hi - > > >> > > >> >From: Martin Bjorklund > > >> >Sent: Oct 24, 2014 4:22 PM > > >> >To: netmod@ietf.org > > >> >Subject: [netmod] issue Y56 UTF8 non-characters > > >> ... > > >> >I think we should have the same rules for the YANG module as for the > > >> >"string" built-in type. > > >> ... > > >> > > >> I'd question that. For the YANG module itself I think it > > >> would probably be a good idea to specify a normalization form, > > > > > >Ok. What is you suggestion? A YANG module MUST be normalized > > >according to NFC (or which one?) > > > > I'd have a *very* slight preference for NFD, since it looks a bit > > easier to generate according to http://www.unicode.org/reports/tr15/ > > but I think it would be good to ask an expert. Probably the most > > important thing is to just *pick* *one*. > > Ok. > > > > In any case, this needs to be in narrower terms than "YANG module". > > Can you elaborate, I do not understand what you mean. > > > It would not be good to break RFC 6020 section 9.4.2. > > ... specifically I do not understand how this section would be > affected? > Perhaps Randy asks what happens to default values? /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 Oct 28 14:21:50 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D80611AD00D for ; Tue, 28 Oct 2014 14:21: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 SU0SLS9i67hW for ; Tue, 28 Oct 2014 14:21:38 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD131ACFE6 for ; Tue, 28 Oct 2014 14:21:37 -0700 (PDT) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 0D6141280471; Tue, 28 Oct 2014 22:21:31 +0100 (CET) Date: Tue, 28 Oct 2014 22:21:31 +0100 (CET) Message-Id: <20141028.222131.469506234.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20141028204635.GE15070@elstar.local> References: <12967085.1414527865425.JavaMail.root@elwamui-little.atl.sa.earthlink.net> <20141028.214341.185747851.mbj@tail-f.com> <20141028204635.GE15070@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=utf-8 Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/EkU6VaQ72fZmm1jExgeCTzA4cBw Cc: randy_presuhn@mindspring.com, netmod@ietf.org Subject: Re: [netmod] issue Y56 UTF8 non-characters X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 28 Oct 2014 21:21:43 -0000 SnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHku ZGU+IHdyb3RlOg0KPiBPbiBUdWUsIE9jdCAyOCwgMjAxNCBhdCAwOTo0Mzo0MVBNICswMTAwLCBN YXJ0aW4gQmpvcmtsdW5kIHdyb3RlOg0KPiA+IFJhbmR5IFByZXN1aG4gPHJhbmR5X3ByZXN1aG5A bWluZHNwcmluZy5jb20+IHdyb3RlOg0KPiA+ID4gSGkgLQ0KPiA+ID4gDQo+ID4gPiA+RnJvbTog TWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb20+DQo+ID4gPiA+U2VudDogT2N0IDI3LCAy MDE0IDc6MTEgQU0NCj4gPiA+ID5UbzogcmFuZHlfcHJlc3VobkBtaW5kc3ByaW5nLmNvbQ0KPiA+ ID4gPkNjOiBuZXRtb2RAaWV0Zi5vcmcNCj4gPiA+ID5TdWJqZWN0OiBSZTogW25ldG1vZF0gaXNz dWUgWTU2IFVURjggbm9uLWNoYXJhY3RlcnMNCj4gPiA+ID4NCj4gPiA+ID5SYW5keSBQcmVzdWhu IDxyYW5keV9wcmVzdWhuQG1pbmRzcHJpbmcuY29tPiB3cm90ZToNCj4gPiA+ID4+IEhpIC0NCj4g PiA+ID4+IA0KPiA+ID4gPj4gPkZyb206IE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29t Pg0KPiA+ID4gPj4gPlNlbnQ6IE9jdCAyNCwgMjAxNCA0OjIyIFBNDQo+ID4gPiA+PiA+VG86IG5l dG1vZEBpZXRmLm9yZw0KPiA+ID4gPj4gPlN1YmplY3Q6IFtuZXRtb2RdIGlzc3VlIFk1NiBVVEY4 IG5vbi1jaGFyYWN0ZXJzDQo+ID4gPiA+PiAuLi4NCj4gPiA+ID4+ID5JIHRoaW5rIHdlIHNob3Vs ZCBoYXZlIHRoZSBzYW1lIHJ1bGVzIGZvciB0aGUgWUFORyBtb2R1bGUgYXMgZm9yIHRoZQ0KPiA+ ID4gPj4gPiJzdHJpbmciIGJ1aWx0LWluIHR5cGUuDQo+ID4gPiA+PiAuLi4NCj4gPiA+ID4+IA0K PiA+ID4gPj4gSSdkIHF1ZXN0aW9uIHRoYXQuICBGb3IgdGhlIFlBTkcgbW9kdWxlIGl0c2VsZiBJ IHRoaW5rIGl0DQo+ID4gPiA+PiB3b3VsZCBwcm9iYWJseSBiZSBhIGdvb2QgaWRlYSB0byBzcGVj aWZ5IGEgbm9ybWFsaXphdGlvbiBmb3JtLA0KPiA+ID4gPg0KPiA+ID4gPk9rLiAgV2hhdCBpcyB5 b3Ugc3VnZ2VzdGlvbj8gIEEgWUFORyBtb2R1bGUgTVVTVCBiZSBub3JtYWxpemVkDQo+ID4gPiA+ YWNjb3JkaW5nIHRvIE5GQyAob3Igd2hpY2ggb25lPykNCj4gPiA+IA0KPiA+ID4gSSdkIGhhdmUg YSAqdmVyeSogc2xpZ2h0IHByZWZlcmVuY2UgZm9yIE5GRCwgc2luY2UgaXQgbG9va3MgYSBiaXQN Cj4gPiA+IGVhc2llciB0byBnZW5lcmF0ZSBhY2NvcmRpbmcgdG8gaHR0cDovL3d3dy51bmljb2Rl Lm9yZy9yZXBvcnRzL3RyMTUvDQo+ID4gPiBidXQgSSB0aGluayBpdCB3b3VsZCBiZSBnb29kIHRv IGFzayBhbiBleHBlcnQuICBQcm9iYWJseSB0aGUgbW9zdA0KPiA+ID4gaW1wb3J0YW50IHRoaW5n IGlzIHRvIGp1c3QgKnBpY2sqICpvbmUqLg0KPiA+IA0KPiA+IE9rLg0KPiA+IA0KPiA+IA0KPiA+ ID4gSW4gYW55IGNhc2UsIHRoaXMgbmVlZHMgdG8gYmUgaW4gbmFycm93ZXIgdGVybXMgdGhhbiAi WUFORyBtb2R1bGUiLg0KPiA+IA0KPiA+IENhbiB5b3UgZWxhYm9yYXRlLCBJIGRvIG5vdCB1bmRl cnN0YW5kIHdoYXQgeW91IG1lYW4uDQo+ID4gDQo+ID4gPiBJdCB3b3VsZCBub3QgYmUgZ29vZCB0 byBicmVhayBSRkMgNjAyMCBzZWN0aW9uIDkuNC4yLg0KPiA+IA0KPiA+IC4uLiBzcGVjaWZpY2Fs bHkgSSBkbyBub3QgdW5kZXJzdGFuZCBob3cgdGhpcyBzZWN0aW9uIHdvdWxkIGJlDQo+ID4gYWZm ZWN0ZWQ/DQo+ID4gDQo+IA0KPiBQZXJoYXBzIFJhbmR5IGFza3Mgd2hhdCBoYXBwZW5zIHRvIGRl ZmF1bHQgdmFsdWVzPw0KDQpJIHdhcyB0aGlua2luZyBhYm91dCB0aGlzIGFzIHdlbGwuICBJc24n dCB0aGlzIGEgcmVhc29uIGZvciBub3QgZG9pbmcNCm5vcm1hbGl6YXRpb24gb2YgWUFORyBtb2R1 bGVzPw0KDQpXaGF0IHByb2JsZW0gaXMgc29sdmVkIGJ5IGRvaW5nIG5vcm1hbGl6YXRpb24gb2Yg YSBZQU5HIG1vZHVsZT8NCg0KKEkgY2FuIHRoaW5rIG9mIGEgZmV3LCBidXQgdGhleSBkb24ndCBz ZWVtIHZlcnkgcmVhbGlzdGljLCBlLmcuIHRoaXMNCndvdWxkIGJlIGxlZ2FsIGJ1dCBjb25mdXNp bmc6DQoNCiAgbGVhZiBzd2VkaXNoLWZpc2ggew0KICAgIHR5cGUgZW51bWVyYXRpb24gew0KICAg ICAgLi4uDQogICAgICBlbnVtIMOFTDsNCiAgICAgIGVudW0g4oSrTDsNCiAgICAgIC4uLg0KICAg IH0NCiAgfQ0KKQ0KDQoNCi9tYXJ0aW4NCg== From nobody Tue Oct 28 16:55:12 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 314F61A1B6B for ; Tue, 28 Oct 2014 16:55:10 -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, 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 L3DGTyLCJrWV for ; Tue, 28 Oct 2014 16:55:07 -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 C502D1A1B54 for ; Tue, 28 Oct 2014 16:55:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=hT85spIp7h051MqOZ2pGSROel540PgZC7abqDQYASxui0SssrzktmWJhtqVl1hbD; 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.26] (helo=mswamui-bichon.atl.sa.earthlink.net) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1XjGbS-0006AV-NH for netmod@ietf.org; Tue, 28 Oct 2014 18:55:06 -0500 Received: from 76.254.52.158 by webmail.earthlink.net with HTTP; Tue, 28 Oct 2014 19:55:06 -0400 Message-ID: <14508866.1414540506554.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> Date: Tue, 28 Oct 2014 16:55:06 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88825aa8a2065c9591fa779a525883f9edc04d448c60f8a7e75350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.26 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/hinjQfo2_jx_SCMOSegB_zIW_o8 Subject: Re: [netmod] issue Y56 UTF8 non-characters 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, 28 Oct 2014 23:55:10 -0000 Hi - >From: Juergen Schoenwaelder >Sent: Oct 28, 2014 1:46 PM >To: Martin Bjorklund >Cc: randy_presuhn@mindspring.com, netmod@ietf.org >Subject: Re: [netmod] issue Y56 UTF8 non-characters ... >> > In any case, this needs to be in narrower terms than "YANG module". >> >> Can you elaborate, I do not understand what you mean. >> >> > It would not be good to break RFC 6020 section 9.4.2. >> >> ... specifically I do not understand how this section would be >> affected? >> > >Perhaps Randy asks what happens to default values? String literals in general, but default values are a good example of something which IMO should *not* be "touched" by normalization of things like enum labels. Randy From nobody Tue Oct 28 17:14:16 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 564B91A1B87 for ; Tue, 28 Oct 2014 17:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 8hjTraZEecrI for ; Tue, 28 Oct 2014 17:14:13 -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 C150B1A1B7C for ; Tue, 28 Oct 2014 17:14:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=HtyvqZA/WnTBkJZZ+uadgWW9InwXEOZOUGz0yW/Yc2qmF53JxMPhWwhmpSejzr4a; 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.26] (helo=mswamui-bichon.atl.sa.earthlink.net) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1XjGtx-0007Qg-34 for netmod@ietf.org; Tue, 28 Oct 2014 20:14:13 -0400 Received: from 76.254.52.158 by webmail.earthlink.net with HTTP; Tue, 28 Oct 2014 20:14:12 -0400 Message-ID: <11812655.1414541653038.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> Date: Tue, 28 Oct 2014 17:14:12 -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: quoted-printable X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88825aa8a2065c9591f301cb2fd84b5ba9e9e6989466fe80f54350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.26 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/sSOYhHiA-vj2ub0CJ_jYACUWmdQ Subject: Re: [netmod] issue Y56 UTF8 non-characters 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, 29 Oct 2014 00:14:15 -0000 Hi - >From: Martin Bjorklund >Sent: Oct 28, 2014 2:21 PM >To: j.schoenwaelder@jacobs-university.de >Cc: randy_presuhn@mindspring.com, netmod@ietf.org >Subject: Re: [netmod] issue Y56 UTF8 non-characters ... >What problem is solved by doing normalization of a YANG module? > >(I can think of a few, but they don't seem very realistic, e.g. this >would be legal but confusing: > > leaf swedish-fish { > type enumeration { > ... > enum =C3=85L; > enum =E2=84=ABL; > ... > } > } >) In addition to =E2=84=ABL, there's a third "spelling" for =C3=85L. It gets *much* worse in Vietnamese. A common word like "=C4=91=C6=B0=E1=BB= =9Dng" ("street") can literally be "spelled" 20 different ways in Unicode, depending on one's choice of precomposed and "combining" options. The situation is similarly painful in Korean. My concern is mostly for operators using text-based tools and printed documentation. When typing in a request, how much does "spelling" matter? How does an operator know whether to type "=E2=84=ABL" or "=C3=85L= ", or which way to "spell" "=C4=91=C6=B0=E1=BB=9Dng"? But it's also a question for module writers. Do they have to "spell" their labels consistently in those cases where there are references to them from within or between modules? Randy From nobody Wed Oct 29 00:15:49 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28A821A6F5B for ; Wed, 29 Oct 2014 00:15: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 WV6SqA5lPydy for ; Wed, 29 Oct 2014 00:15:43 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC181A6F44 for ; Wed, 29 Oct 2014 00:15:43 -0700 (PDT) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id B6A5A12801AB; Wed, 29 Oct 2014 08:15:41 +0100 (CET) Date: Wed, 29 Oct 2014 08:15:41 +0100 (CET) Message-Id: <20141029.081541.176107414.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <11812655.1414541653038.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> References: <11812655.1414541653038.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> 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: http://mailarchive.ietf.org/arch/msg/netmod/qOe70kxLoJRE2CQjKdoKHvWDI5w Cc: netmod@ietf.org Subject: Re: [netmod] issue Y56 UTF8 non-characters X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 29 Oct 2014 07:15:47 -0000 UmFuZHkgUHJlc3VobiA8cmFuZHlfcHJlc3VobkBtaW5kc3ByaW5nLmNvbT4gd3JvdGU6DQo+IEhp IC0NCj4gDQo+ID5Gcm9tOiBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4NCj4gPlNl bnQ6IE9jdCAyOCwgMjAxNCAyOjIxIFBNDQo+ID5Ubzogai5zY2hvZW53YWVsZGVyQGphY29icy11 bml2ZXJzaXR5LmRlDQo+ID5DYzogcmFuZHlfcHJlc3VobkBtaW5kc3ByaW5nLmNvbSwgbmV0bW9k QGlldGYub3JnDQo+ID5TdWJqZWN0OiBSZTogW25ldG1vZF0gaXNzdWUgWTU2IFVURjggbm9uLWNo YXJhY3RlcnMNCj4gLi4uDQo+ID5XaGF0IHByb2JsZW0gaXMgc29sdmVkIGJ5IGRvaW5nIG5vcm1h bGl6YXRpb24gb2YgYSBZQU5HIG1vZHVsZT8NCj4gPg0KPiA+KEkgY2FuIHRoaW5rIG9mIGEgZmV3 LCBidXQgdGhleSBkb24ndCBzZWVtIHZlcnkgcmVhbGlzdGljLCBlLmcuIHRoaXMNCj4gPndvdWxk IGJlIGxlZ2FsIGJ1dCBjb25mdXNpbmc6DQo+ID4NCj4gPiAgbGVhZiBzd2VkaXNoLWZpc2ggew0K PiA+ICAgIHR5cGUgZW51bWVyYXRpb24gew0KPiA+ICAgICAgLi4uDQo+ID4gICAgICBlbnVtIMOF TDsNCj4gPiAgICAgIGVudW0g4oSrTDsNCj4gPiAgICAgIC4uLg0KPiA+ICAgIH0NCj4gPiAgfQ0K PiA+KQ0KPiANCj4gSW4gYWRkaXRpb24gdG8g4oSrTCwgdGhlcmUncyBhIHRoaXJkICJzcGVsbGlu ZyIgZm9yIMOFTC4NCj4NCj4gSXQgZ2V0cyAqbXVjaCogd29yc2UgaW4gVmlldG5hbWVzZS4gIEEg Y29tbW9uIHdvcmQgbGlrZSAixJHGsOG7nW5nIiAoInN0cmVldCIpDQo+IGNhbiBsaXRlcmFsbHkg YmUgInNwZWxsZWQiIDIwIGRpZmZlcmVudCB3YXlzIGluIFVuaWNvZGUsIGRlcGVuZGluZyBvbiBv bmUncw0KPiBjaG9pY2Ugb2YgcHJlY29tcG9zZWQgYW5kICJjb21iaW5pbmciIG9wdGlvbnMuICBU aGUgc2l0dWF0aW9uIGlzIHNpbWlsYXJseQ0KPiBwYWluZnVsIGluIEtvcmVhbi4NCj4gDQo+IE15 IGNvbmNlcm4gaXMgbW9zdGx5IGZvciBvcGVyYXRvcnMgdXNpbmcgdGV4dC1iYXNlZCB0b29scyBh bmQgcHJpbnRlZA0KPiBkb2N1bWVudGF0aW9uLiAgV2hlbiB0eXBpbmcgaW4gYSByZXF1ZXN0LCBo b3cgbXVjaCBkb2VzICJzcGVsbGluZyINCj4gbWF0dGVyPyAgSG93IGRvZXMgYW4gb3BlcmF0b3Ig a25vdyB3aGV0aGVyIHRvIHR5cGUgIuKEq0wiIG9yICLDhUwiLA0KPiBvciB3aGljaCB3YXkgdG8g InNwZWxsIiAixJHGsOG7nW5nIj8NCg0KQnV0IGlzbid0IHRoaXMgYSBiaWdnZXIgcHJvYmxlbSBm b3IgaW5zdGFuY2UgZGF0YSwgaS5lLiwgc3RyaW5ncz8NCg0KPiBCdXQgaXQncyBhbHNvIGEgcXVl c3Rpb24gZm9yIG1vZHVsZSB3cml0ZXJzLiAgRG8gdGhleSBoYXZlIHRvICJzcGVsbCINCj4gdGhl aXIgbGFiZWxzIGNvbnNpc3RlbnRseSBpbiB0aG9zZSBjYXNlcyB3aGVyZSB0aGVyZSBhcmUgcmVm ZXJlbmNlcyB0bw0KPiB0aGVtIGZyb20gd2l0aGluIG9yIGJldHdlZW4gbW9kdWxlcz8NCg0KSWYg aXQgY29tZXMgZG93biB0byB0aGlzLCBJIHRoaW5rIEkgY2FuIGxpdmUgd2l0aCB0aGlzLg0KDQoN Ci9tYXJ0aW4NCg== From nobody Wed Oct 29 02:06:48 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04C4A1A7001 for ; Wed, 29 Oct 2014 02:06:47 -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_50=0.8, J_CHICKENPOX_24=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 ReIm-0VNnN1p for ; Wed, 29 Oct 2014 02:06:45 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC83A1A6FF3 for ; Wed, 29 Oct 2014 02:06:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 5CF845408C3 for ; Wed, 29 Oct 2014 10:06:42 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YHhoGuX4h-C for ; Wed, 29 Oct 2014 10:06:37 +0100 (CET) Received: from localhost (unknown [195.113.220.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id CDA8C54003C for ; Wed, 29 Oct 2014 10:06:37 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-apple-darwin13.4.0) Date: Wed, 29 Oct 2014 10:06:42 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/-LSgd3WX_mxfMhUr0SSd7KaAOH4 Subject: [netmod] LL review of draft-yeung-netmod-ospf-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 29 Oct 2014 09:06:47 -0000 Hi, I reviewed the OSPF data model and I-D, concentrating mainly on YANG issues and the integration with teh core routing data model. Lada *** General comments The "ospf" module is the result of an intensive cooperation of a multi-vendor expert group. On the one hand, it demonstrates that it is possible to design a YANG module for a relatively complicated routing protocol so as to be applicable to devices of different vendors. On the other hand, it also shows that the need to accommodate disparate configuration logics stemming from each vendor's CLI adds significant complexity to the data model. It is clear that the "ietf-routing" module is a nice fit for the "routing-instance-centric" design but the integration of the "protocol-centric" design is IMO quite awkward. While the (big) vendors participating in the module design may consider the result an acceptable compromise, I suspect it is not that much attractive for those who want to write a new implementation. This is not meant as a criticism of the "ospf" module but rather a reflection of reality that's by no means unique to OSPF. I think it is necessary to evaluate pros and cons of having one complex module that fits all versus multiple concurrent but cleaner modules. *** Module design **** Protocol-centric v. instance-centric model - The dichotomy of protocol-centric and instance-centric models should be better explained in the draft, maybe with examples. - In the protocol-centric case, do all routing protocols (not only OSPF) have to be defined in the default routing-instance? What are then the contents of non-default routing-instances? - References to interfaces use the "if:interface-ref" type, but I think they should always be confined to an appropriate routing-instance, i.e. refer to an entry of /rt:routing-instance/rt:interfaces/rt:interface and not to /if:interfaces/if:interface. **** Inheritance In the "ietf-routing" module, the intent was to have different instances of the same routing protocol as entries of "rt:routing-protocol" list. The "ospf" module models OSPF instances as entries of "rt:routing-protocol/ospf:ospf/ospf:instance". I understand the main purpose of this organization is to allow instances to share data that are defined in "all-instances-inherit". Another way of achieving the same would be to define a special routing protocol type, e.g. "ospf:ospfv2-proto". An instance of this type would be a prototype and its data would be shared by all OSPFv2 instances. The advantages of this are: - parameters that may be inherited can be defined just once, e.g., for "ospf:ospfv2" and "ospf:ospfv2-proto" at the same time. - leafrefs can refer to the same parameter no matter whether it is in the prototype or real instance; - in state data, the prototype instance needn't be present, the inherited parameters will appear as normal parameters of real instances. **** Identities The "ospf:ospfv2" and "ospf:ospfv3" identities are defined with "rt:routing-protocol" as their base. I'd suggest to add a generic "ospf:ospf" identity. Taking into account the previous item, the identity hierarchy could be: rt:routing-protocol ospf:ospf ospf:ospf-proto ospf:ospfv2 ospf:ospfv2-proto ospf:ospfv3 ospf:ospfv3-proto Advantages: - Parameters from the "ospf:ospf" instance could be inherited by *both* OSPFv2 and OSPFv3 instances. - Using the new XPath function "derived-from()" (see sec. 10.4.1 in draft-ietf-netmod-rfc6020bis-01), it will be possible to replace XPath expressions like "rt:type = 'ospf:ospfv2' or rt:type = 'ospf:ospfv3'" with "derived-from(rt:type, "ospf", "ospf")" *** YANG issues - The module should be named "ietf-ospf". - In the definition list neighbor { description "List of neighbors."; leaf neighbor-id { type leafref { path "../../neighbor/neighbor-id"; } description "Neighbor."; } } the "neighbor-id" leafref points to itself. This is is not allowed in YANG, the path should probably be something else. - Several augments have target nodes in the "ospf" module, for example augment "/rt:routing/rt:routing-instance/rt:routing-protocols/" + "rt:routing-protocol/ospf:ospf/ospf:instance" { ... } What is the purpose of doing so? The nodes defined inside such an augment can be put straight under "ospf:instance". Moreover, "when" expressions used for these augments are wrong, for example the above augment has when "../rt:type = 'ospf:ospfv2' or ../rt:type = 'ospf:ospfv3'" but it should be when "../../rt:type = 'ospf:ospfv2'" + "or ../../rt:type = 'ospf:ospfv3'" - some descriptions are extremely terse and should be expanded. *** I-D text - The standard text explaining symbols in tree diagrams should be included. - An example instance document would be helpful, e.g. an extension of the example in appendix D of draft-ietf-netmod-routing-cfg-16. -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Oct 29 04:26:01 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 076E51A0010 for ; Wed, 29 Oct 2014 04:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.35 X-Spam-Level: ** X-Spam-Status: No, score=2.35 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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, T_FILL_THIS_FORM_SHORT=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 gMCFB_rV7vVg for ; Wed, 29 Oct 2014 04:25:55 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 738181A0005 for ; Wed, 29 Oct 2014 04:25:55 -0700 (PDT) Received: from krejci.liberouter.org (pckrejci.fit.vutbr.cz [147.229.12.223]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id BC274ECB353; Wed, 29 Oct 2014 12:25:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2; t=1414581952; bh=mPrGPhHeLLVM+ULUrtrNZhX6bv6JzO6L08aqspDnPTs=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type; b=s4uSpIdV9UfLwnPSvNchC9HI1Pd5dpsj0LdPh4yaS9/PUSt6gV5JvB+57mg/oxTYy rTX1QYc2jNqxslFeYfNb/koUvnxiszVnXqaCRbHI0tMgrSyBnfpEH1gPIUlk53VjzS Yqs91FDGtPhOJ8rIVWq/W2CXNitqJ3PsflYYEZ4g= Message-ID: <5450CD52.1010303@cesnet.cz> Date: Wed, 29 Oct 2014 12:19:46 +0100 From: =?UTF-8?B?UmFkZWsgS3JlasSNw60=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Balazs Lengyel , "netmod@ietf.org" References: <542E9D57.7010108@ericsson.com> In-Reply-To: <542E9D57.7010108@ericsson.com> Content-Type: multipart/alternative; boundary="------------030700090005000900050402" Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Wlpf6LmbVMsA-s6y9YI2vhkVfbo Subject: Re: [netmod] replace a value in a leaf list - what does it mean? X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 29 Oct 2014 11:25:59 -0000 This is a multi-part message in MIME format. --------------030700090005000900050402 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Balazs, IMHO it depends on the ordered-by attribute of the leaf-list (by default,= leaf-list is system-ordered): a) ordered-by system - then the 1) applies b) ordered-by user - the result should be [a,c,d,b] - as you stated, inse= rt defaults to 'last'. But in that case replace works as "move" of the ex= isting item. The value of the leaf-list item works as a key to identify t= he item to move. Regards, Radek Dne 3.10.2014 v 14:57 Balazs Lengyel napsal(a): > Hello, > I am trying to formulate my proposal about non-Unique values in a leaf-= list, and during this I found, I do not understand what an edit-config: r= eplace operation means in YANG 1.0 for a leaf-list. > > If I have a leaf-list [a,b,c,d] and I issue an edit-config opertion whe= re the value "b" of the leaf-list is replaced by "b" > what is the result: > 1) [a,b,c,d] - seems natural as replacing something with itself should= not modified the data > > or > > 2) [a,b,c,d,b] - according to RFC6020 chapter 7.7.7 > In an "ordered-by user" leaf-list, the attributes "insert" and > "value" in the YANG XML namespace (Section 5.3.1 ) can be used to > control where in the leaf-list the entry is inserted. These can be > used during "create" operations to insert a new leaf-list entry, or > during "merge" or "replace" operations to insert a new leaf-list > entry or move an existing one. > > ... > > If no "insert" attribute is present in the "create" operation, it > defaults to "last". > So replace can be used on a leaf-list. Insert defaults to last. This wo= uld point at 2) as the solution. > > Opinions? > regards balazs > > > > --=20 > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > ECN: 831 7320 Tel: +36-1-437-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 --=20 Radek Krejci mobile : +420 732 212 714 office : +420 234 680 256 e-mail : rkrejci@cesnet.cz LinkedIn: http://www.linkedin.com/in/radekkrejci CESNET Association of Legal Entities 160 00 Praha 6, Zikova 4 Czech Republic --------------030700090005000900050402 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Balazs,

IMHO it depends on the ordered-by attribute of the leaf-list (by default, leaf-list is system-ordered):

a) ordered-by system - then the 1) applies

b) ordered-by user - the result should be [a,c,d,b] - as you stated, insert defaults to 'last'. But in that case replace works as "move" of the existing item. The value of the leaf-list item works as a key to identify the item to move.

Regards,
Radek


Dne 3.10.2014 v 14:57 Balazs Lengyel napsal(a):
Hello,
I am trying to formulate my proposal about non-Unique values in a leaf-list, and during this I found, I do not understand what an edit-config: replace operation means in YANG 1.0 for a leaf-list.

If I have a leaf-list [a,b,c,d] and I issue an edit-config opertion where the value "b" of the leaf-list is replaced by "b"
what is the result:
1) [a,b,c,d]  - seems natural as replacing something with itself should not modified the data

or

2) [a,b,c,d,b] - according to RFC6020 chapter 7.7.7
   In an "ordered-by user" leaf-list, the attributes "insert" and
   "value" in the YANG XML namespace (Section 5.3.1) can be used to
   control where in the leaf-list the entry is inserted.  These can be
   used during "create" operations to insert a new leaf-list entry, or
   during "merge" or "replace" operations to insert a new leaf-list
   entry or move an existing one.

	...

   If no "insert" attribute is present in the "create" operation, it
   defaults to "last".
So replace can be used on a leaf-list. Insert defaults to last. This would point at 2) as the solution.

Opinions?
regards balazs



-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320                        Tel: +36-1-437-7320
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com 



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


-- 
Radek Krejci
mobile  : +420 732 212 714
office  : +420 234 680 256
e-mail  : rkrejci@cesnet.cz
LinkedIn: http://www.linkedin.com/in/radekkrejci

CESNET
Association of Legal Entities
160 00 Praha 6, Zikova 4
Czech Republic
--------------030700090005000900050402-- From nobody Wed Oct 29 04:49:56 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76AE41A000E; Wed, 29 Oct 2014 04:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.013 X-Spam-Level: X-Spam-Status: No, score=-0.013 tagged_above=-999 required=5 tests=[BAYES_40=-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 qhi6Su5SZn7H; Wed, 29 Oct 2014 04:49:44 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id C8D891A0019; Wed, 29 Oct 2014 04:49:44 -0700 (PDT) Received: from [192.168.1.123] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 432CC28E4175; Wed, 29 Oct 2014 07:49:44 -0400 (EDT) From: "Thomas D. Nadeau" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Oct 2014 07:49:43 -0400 Message-Id: <88F56A4D-804E-44CB-A2EF-28892985EC50@lucidvision.com> To: NETMOD Working Group , rtg-yang-coord@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ChGZmJz88zTjU9Yuy_JVOICPs_Q Subject: [netmod] open config pushes open routing 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, 29 Oct 2014 11:49:48 -0000 FYI. = https://www.sdncentral.com/news/google-openconfig-pushes-open-routing-mode= l/2014/10/ =E2=80=94Tom From nobody Wed Oct 29 06:56:08 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4B81A00F9 for ; Wed, 29 Oct 2014 06:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, THIS_AD=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 GxmYO0214Dd9 for ; Wed, 29 Oct 2014 06:56:03 -0700 (PDT) Received: from mail-qg0-f51.google.com (mail-qg0-f51.google.com [209.85.192.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9485A1A00C5 for ; Wed, 29 Oct 2014 06:56:03 -0700 (PDT) Received: by mail-qg0-f51.google.com with SMTP id j5so2222984qga.24 for ; Wed, 29 Oct 2014 06:56:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=QO7I1tCIlE5NjBNPX6dYJ/deyQ8QTIYQeCHl/n4YU0c=; b=DuL7MkhY5FJCEofI9hoPQcOu0wTcfKG1YSnN6g0A+2ngSQTwKYCugWxBVqHTK2X7u7 /Ga3IYyrQXjBvgbQbs98WxCV2ZNq1q/wO6OS5sHpWzlgilPJP5qhgx8RVFu/GQ5GzZkK 2y7PxCCqBuE8pkSJU96x0nVahHlTiF6gxIcSqkDaavdIuc89+ILP/DBSrO3RzqJNON8U VK17baRN86rdRSmGx0DxMBk4SvJaEHHdxalbLzICITEO31/rTUcumNU4FJtERpCmi3ds T8fkU0MisXoPXG7ImE1KpPsnW0SQJjZvWNCyWQlMIfn3j8TZ1ynVaqcDh5fhL724eZ4V tBYw== X-Gm-Message-State: ALoCoQnnRC3VNZS8uTDBQFQtHrRxVFYzJM7TmG2yDeKtu8D/OtxX+Nj27RFp4yvNrB026cVXFuKH MIME-Version: 1.0 X-Received: by 10.140.30.98 with SMTP id c89mr15040364qgc.90.1414590959722; Wed, 29 Oct 2014 06:55:59 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Wed, 29 Oct 2014 06:55:59 -0700 (PDT) In-Reply-To: <20141027220615.GB10028@elstar.local> References: <20141027220615.GB10028@elstar.local> Date: Wed, 29 Oct 2014 06:55:59 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , "netmod@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/HzEWH-nCbNe__lef43-fIKOG4hU Subject: Re: [netmod] yang 1.1 webex on wednesday october 29th X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 29 Oct 2014 13:56:05 -0000 Hi, I just noticed this is an hour later than the usual NETMOD conf-call. 16:00 CET is 8:00AM PDT. Andy On Mon, Oct 27, 2014 at 3:06 PM, Juergen Schoenwaelder wrote: > During the last YANG 1.1 virtual interim meeting, we discussed to have > another meeting to talk about the conformance related issues. > Unfortunately, the series of virtual interim meetings allocated for > YANG 1.1 work did end last Wednesday and since scheduling a virtual > interim meeting requires two weeks of advance notice, we can't have an > official virtual interim meeting on Wednesday. > > However, in order to not loose traction, I like to invite all people > interested in this topic to an inofficial webex meeting taking place > on Wednesday at 16:00 CET, which will run for at most two hours. While > I will write the usual minutes, this is not an official virtual > interim meeting. But hopefully this ad-hoc webex helps to come to a > clearer view on how to move forward with the conformance related > issues. > > I am attaching the webex information. The webex information is > different from the previous virtual interim meeting webex info - so > please make sure to join the correct webex meeting. > > /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 Oct 29 06:57:37 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8621A00F9; Wed, 29 Oct 2014 06:57:33 -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 TLF1Imw1hg1J; Wed, 29 Oct 2014 06:57:29 -0700 (PDT) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 932891A00C5; Wed, 29 Oct 2014 06:57:29 -0700 (PDT) Received: by mail-yh0-f54.google.com with SMTP id 29so620250yhl.41 for ; Wed, 29 Oct 2014 06:57:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=BwnTZECvvNx90SFa8DAr6GYoKbKePaGi2Tljee1FNSE=; b=ejPcU02K3h6nXB75q5f0yt4+l9WuY24COqQpk/HxuH4LcBHCSVPQjD+Nhzo8/1eR2G lMy4cbMZGcdtU1HPv2txhW/i+T8Qrk5WgjOSLD8AUtdOWbuv6FyRStSjW26LNMxY1IbL BrVSrrQQpelvyDgZsjeDg2i7cjBNbW+/7uMOcREY+vPmLQ1tln6OQSKtSijodumUgqm8 72X897EvA00A5AdWqsJW3uFx5XEx1gRkefJTVHmSXMmrGO5MnPwQ/VmG86kWNepTwuLp YDJpicN/ytw+RUX6hbuaKT0RhckTWhqqfOi6PODgcXhnauvPQb4QVwl564tXEmQQJdmS qyDA== MIME-Version: 1.0 X-Received: by 10.236.23.231 with SMTP id v67mr1925171yhv.48.1414591048880; Wed, 29 Oct 2014 06:57:28 -0700 (PDT) Received: by 10.170.113.10 with HTTP; Wed, 29 Oct 2014 06:57:28 -0700 (PDT) Date: Wed, 29 Oct 2014 09:57:28 -0400 Message-ID: From: Alia Atlas To: "netmod@ietf.org" , "Rtg-yang-coord@ietf.org" , "routing-discussion@ietf.org" Content-Type: multipart/alternative; boundary=089e0122a6caf8966a05069024f8 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/hZCeAu_OzlInzKsP9G17IaRmLH0 Subject: [netmod] AD statement on development of IETF-standard routing-related YANG 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, 29 Oct 2014 13:57:33 -0000 --089e0122a6caf8966a05069024f8 Content-Type: text/plain; charset=UTF-8 Development of standardized YANG models has seriously increased this year. Of course, this is a good problem to have. There are close to 30 different drafts related to YANG models for routing; coordination between these drafts is necessary. NETMOD is also hard at work on a backwards-compatible YANG 1.1. From the IETF's experience with developing MIBs, it was critical to have the domain-area experts involved in writing and reviewing MIBs and we believe that it is similarly critical to situate the work on YANG models in the working groups where the appropriate domain-experts can be easily found. Actively encouraging and cultivating the review of those with the expertise in modeling with YANG and deep understanding of its features is also critical to the success of standardized YANG models. This expertise is found in the NETMOD working group and among the YANG doctors ( https://www.ietf.org/iesg/directorate/yang-doctors.html). We, as the Routing and Ops and Management Area Directors, would like to see work proceed as follows. 1) The mailing list, rtg-yang-coord@ietf.org, has been created to coordinate among the different routing YANG models and drafts. For instance, there may be common groupings to be defined, interactions between models to be determined, and so on. To facilitate this coordination work, we are developing a job description for a secretary for the mailing list and hope to appoint someone to that role. 2) Routing-related YANG models must be targeted for adoption at the appropriate WGs in the Routing Area. If the appropriate WG is unclear, please bring the question to the RTGWG and the rtg-yang-coord@ietf.org mailing list. RTGWG can either direct where the work goes or, if there is no appropriate other WG, make a decision about adopting the draft. 3) The NETMOD charter has been open to accept work item that don't fall under the responsibility of an existing WGs: The NETMOD WG may also develop any additional data models written in YANG that the WG considers core building blocks and that do not fall under the charters of other active IETF working groups. The NETMOD WG may simply add such milestones as it sees fit, with the advice and consent of the responsible AD. In case of routing-related YANG models, even if there are no responsible existing WG, it's expected that the standardization happens in the RTGWG. 4) It is common and expected that sometimes work needs to be discussed in multiple WGs, even though it is only adopted in one. Examples would include NETMOD discussing a model for OSPF to consider how it relates to draft-ietf-netmod-routing-cfg, RTGWG discussing draft-ietf-netmod-routing-cfg to encourage review and discussion about its use as a base for routing-related models, etc. 5) We have heard a strong desire from the community to rapidly encourage development of standardized YANG models. Towards that end, we expect and encourage more and frequent virtual interims (some probably joint between WGs). To have such a pace work well, we need authors, reviewers, and contributors to expect to spend time on this work on an on-going basis. 6) Since many YANG doctors also participate in NETMOD and since NETMOD is having weekly virtual interims, it may prove convenient to provide feedback on YANG models in this forum. When done so, to ensure the interested parties are aware of the relevant models to be discussed and can arrange their schedules to call in, the agenda should be forwarded with at least a week's to the rtg-yang-coord@ietf.org and to the relevant WGs. When the virtual interim is used to provide YANG doctor feedback, preference should be given to drafts already adopted by a WG; discussing one model does not imply partiality or a request to the WG appropriate to consider adopting the draft. 7) To provide a common location to find proposed YANG models and be able to verify their accuracy, Tom Nadeau, one of the NETMOD chairs, has set up a GitHub repository at: https://github.com/YangModels/yang. All work contributed to it is subject to the IETF Contributions policy, as summarized via the very very familiar IETF Note Well. 8) For the second IETF meeting in a row, a "YANG Advice and Editing Session" (http://www.ietf.org/meeting/91/tutorials/yang-session.html) is organized on the Sunday before the IETF meeting. This is your chance to sit down with a YANG doctor and to get feedback on your YANG module. If you have any questions, please let us know. Regards, Alia, Benoit, Adrian, & Joel --089e0122a6caf8966a05069024f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Development of standardized YANG models has seriou= sly increased this year.=C2=A0 Of course, this is a good problem to have. T= here are close to 30 different drafts related to YANG models for routing; c= oordination between these drafts is necessary.=C2=A0 NETMOD is also hard at= work on a backwards-compatible YANG 1.1.=C2=A0 From the IETF's experie= nce with developing MIBs, it was critical to have the domain-area experts i= nvolved in writing and reviewing MIBs and we believe that it is similarly c= ritical to situate the work on YANG models in the working groups where the = appropriate domain-experts can be easily found.=C2=A0 Actively encouraging = and cultivating the review of those with the expertise in modeling with YAN= G and deep understanding of its features is also critical to the success of= standardized YANG models.=C2=A0 This expertise is found in the NETMOD work= ing group and among the YANG doctors (https://www.ietf.org/iesg/= directorate/yang-doctors.html).

<= div class=3D"gmail_quote" style=3D"font-size:13px">We, as the Routing and Op= s and Management Area Directors, would like to see work proceed as follows.=

1) The mailing list,=C2=A0rtg-yang-coord@ietf.org, has been cre= ated to coordinate among the different routing YANG models and drafts.=C2= =A0 For instance, there may be common groupings to be defined, interactions= between models to be determined, and so on.=C2=A0 To facilitate this coord= ination work, we are developing a job description for a secretary for the m= ailing list and hope to appoint someone to that role.

2) Routing-rel= ated YANG models must be targeted for adoption at the appropriate WGs in th= e Routing Area.=C2=A0 If the appropriate WG is unclear, please bring the qu= estion to the RTGWG and the=C2=A0rtg-yang-coord@ietf.org=C2=A0mailing list.=C2=A0 RTG= WG can either direct where the work goes or, if there is no appropriate oth= er WG, make a decision about adopting the draft.

3)=C2= =A0The NETMOD charter has been open to accept work item that don't fall= under the responsibility of an existing WGs:
The NETMOD WG may also develop any additional = data models written in YANG that the WG considers core building blocks and = that do not fall under the charters of other active IETF working groups. Th= e NETMOD WG may simply add such milestones as it sees fit, with the advice = and consent of the responsible AD.
In case of routing-related YANG models, even if there are no respons= ible existing WG, it's expected that the standardization happens in the= RTGWG.

4) It is common and expected that somet= imes work needs to be discussed in multiple WGs, even though it is only ado= pted in one.=C2=A0 Examples would include NETMOD discussing a model for OSP= F to consider how it relates to draft-ietf-netmod-routing-cfg, RTGWG discus= sing draft-ietf-netmod-routing-cfg to encourage review and discussion about= its use as a base for routing-related models, etc. =C2=A0

5) We hav= e heard a strong desire from the community to rapidly encourage development= of standardized YANG models.=C2=A0 Towards that end, we expect and encoura= ge more and frequent virtual interims (some probably joint between WGs).=C2= =A0 To have such a pace work well, we need authors, reviewers, and contribu= tors to expect to spend time on this work on an on-going basis.

6) Since many YANG doctors also participate in NETMOD and sinc= e NETMOD is having weekly virtual interims, it may prove convenient to prov= ide feedback on YANG models in this forum.=C2=A0 When done so, to ensure th= e interested parties are aware of the relevant models to be discussed and c= an arrange their schedules to call in, the agenda should be forwarded with = at least a week's to the=C2=A0rtg-yang-coord@ietf.org=C2=A0and to the relevant WG= s. When the virtual interim is used to provide YANG doctor feedback, prefer= ence should be given to drafts already adopted by a WG; discussing one mode= l does not imply partiality or a request to the WG appropriate to consider = adopting the draft.

7) To provide a common location= to find proposed YANG models and be able to verify their accuracy, Tom Nad= eau, one of the NETMOD chairs, has set up a GitHub repository at:=C2=A0https://github= .com/YangModels/yang.=C2=A0 All work contributed to it is subject to th= e IETF Contributions policy, as summarized via the very very familiar IETF = Note Well.
8) For the second IETF meeting in a row, a "YANG Advice and Editing S= ession" (http://www.ietf.org/meeting/91/tutorials= /yang-session.html) is organized on the Sunday = before the IETF meeting. This is your chance to sit down with a YANG doctor= and to get feedback on your YANG module.

If you have any questions, please let us kn= ow.

Regards,
Alia, Benoit, Adrian, & Joel
--089e0122a6caf8966a05069024f8-- From nobody Wed Oct 29 08:06:50 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E66C1A03A0 for ; Wed, 29 Oct 2014 08:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.141 X-Spam-Level: * X-Spam-Status: No, score=1.141 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=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 Mcjy7oAOnifc for ; Wed, 29 Oct 2014 08:06:38 -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 3A9E11A0393 for ; Wed, 29 Oct 2014 08:06: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 10325E7C for ; Wed, 29 Oct 2014 16:06:36 +0100 (CET) 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 ozahwffXY_y0 for ; Wed, 29 Oct 2014 16:06:20 +0100 (CET) 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, 29 Oct 2014 16:06:35 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8B6022003B for ; Wed, 29 Oct 2014 16:06:34 +0100 (CET) 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 E0KST6UuIKoj; Wed, 29 Oct 2014 16:06:33 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B2A5720038; Wed, 29 Oct 2014 16:06:32 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 5A99D2F1954F; Wed, 29 Oct 2014 16:06:30 +0100 (CET) Date: Wed, 29 Oct 2014 16:06:30 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20141029150630.GA17776@elstar.local> Mail-Followup-To: netmod@ietf.org References: <20141027220615.GB10028@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141027220615.GB10028@elstar.local> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/s07DGxGFqA9O6un-16TSIgeVuGs Subject: Re: [netmod] yang 1.1 webex on wednesday october 29th 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, 29 Oct 2014 15:06:45 -0000 Hi, we are using this etherpad for note taking: http://etherpad.tools.ietf.org:9000/p/notes-ietf-netmod-virtual-interim-2014-10-29 /js On Mon, Oct 27, 2014 at 11:06:15PM +0100, Juergen Schoenwaelder wrote: > During the last YANG 1.1 virtual interim meeting, we discussed to have > another meeting to talk about the conformance related issues. > Unfortunately, the series of virtual interim meetings allocated for > YANG 1.1 work did end last Wednesday and since scheduling a virtual > interim meeting requires two weeks of advance notice, we can't have an > official virtual interim meeting on Wednesday. > > However, in order to not loose traction, I like to invite all people > interested in this topic to an inofficial webex meeting taking place > on Wednesday at 16:00 CET, which will run for at most two hours. While > I will write the usual minutes, this is not an official virtual > interim meeting. But hopefully this ad-hoc webex helps to come to a > clearer view on how to move forward with the conformance related > issues. > > I am attaching the webex information. The webex information is > different from the previous virtual interim meeting webex info - so > please make sure to join the correct webex meeting. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > ******* DO NOT DELETE OR CHANGE ANY OF THE TEXT BELOW THIS LINE ******* > > ----------------------------------------------------------------------- > JOIN USING WebEx > > Go To: > https://cisco.webex.com/cisco/j.php?MTID=m6ea214f8e097453994e88aa706a7bcad > > Meeting Password ----- 1234 > Meeting Number ----- 201 602 421 > > ---------------------------------------------------------------- > ALERT - PLEASE READ: DO NOT DIAL THE TOLL FREE NUMBERS FROM WITHIN THE (408) OR (919) AREA CODES > ---------------------------------------------------------------- > Please dial the local access number for your area from the list below: > - San Jose/Milpitas (408) area: 525-6800 > - RTP (919) area: 392-3330 > > Dialing the WebEx toll free numbers from within 408 or 919 area codes is not enabled (non-Cisco phones). " If you dial the toll-free numbers within the 408 or 919 area codes you will be instructed to hang up and dial the local access number." Please use the call-back option whenever possible and otherwise dial local numbers only. The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpitas area and (866) 349-3520 for the RTP area. > > ------------------------------------------------------- > To join the teleconference only > ------------------------------------------------------- > 1. Dial into Cisco WebEx (view all Global Access Numbers at > http://cisco.com/en/US/about/doing_business/conferencing/index.html > 2. Follow the prompts to enter the Meeting Number (listed above) or Access Code followed by the # sign. > > San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 > > US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 > > India: +91.80.4350.1111 Germany: +49.619.6773.9002 > > Japan: +81.3.5763.9394 China: +86.10.8515.5666 > > IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. > -- 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 Oct 29 10:03:43 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 064E71A6F07 for ; Wed, 29 Oct 2014 10:03: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, 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 CarOpvHUBkYL for ; Wed, 29 Oct 2014 10:03:39 -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 618AC1A3B9E for ; Wed, 29 Oct 2014 10:03:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=K2FhKAfwXFoBxxV1R/yhGxxD0S7yOigti/XbeO/S3nD+r8yxJbtfW3fmGRzajjfV; 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.27] (helo=mswamui-billy.atl.sa.earthlink.net) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1XjWeJ-0006mM-MT for netmod@ietf.org; Wed, 29 Oct 2014 13:03:07 -0400 Received: from 76.254.52.158 by webmail.earthlink.net with HTTP; Wed, 29 Oct 2014 13:03:07 -0400 Message-ID: <8770654.1414602187573.JavaMail.root@mswamui-billy.atl.sa.earthlink.net> Date: Wed, 29 Oct 2014 10:03:07 -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: quoted-printable X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88825aa8a2065c9591f93d2b6da7d98f7e36409ac659325613c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.27 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/2FfyTzpUKmLeQmnpOIO4-LnqrWo Subject: Re: [netmod] issue Y56 UTF8 non-characters 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, 29 Oct 2014 17:03:41 -0000 Hi - >From: Martin Bjorklund >Sent: Oct 29, 2014 12:15 AM >To: randy_presuhn@mindspring.com >Cc: netmod@ietf.org >Subject: Re: [netmod] issue Y56 UTF8 non-characters > >Randy Presuhn wrote: >> Hi - >>=20 >> >From: Martin Bjorklund >> >Sent: Oct 28, 2014 2:21 PM >> >To: j.schoenwaelder@jacobs-university.de >> >Cc: randy_presuhn@mindspring.com, netmod@ietf.org >> >Subject: Re: [netmod] issue Y56 UTF8 non-characters >> ... >> >What problem is solved by doing normalization of a YANG module? >> > >> >(I can think of a few, but they don't seem very realistic, e.g. this >> >would be legal but confusing: >> > >> > leaf swedish-fish { >> > type enumeration { >> > ... >> > enum =C3=85L; >> > enum =E2=84=ABL; >> > ... >> > } >> > } >> >) >>=20 >> In addition to =E2=84=ABL, there's a third "spelling" for =C3=85L. >> >> It gets *much* worse in Vietnamese. A common word like "=C4=91=C6=B0=E1= =BB=9Dng" ("street") >> can literally be "spelled" 20 different ways in Unicode, depending on on= e's >> choice of precomposed and "combining" options. The situation is similar= ly >> painful in Korean. >>=20 >> My concern is mostly for operators using text-based tools and printed >> documentation. When typing in a request, how much does "spelling" >> matter? How does an operator know whether to type "=E2=84=ABL" or "=C3= =85L", >> or which way to "spell" "=C4=91=C6=B0=E1=BB=9Dng"? > >But isn't this a bigger problem for instance data, i.e., strings? Yes, that's a big problem, but it's a *separate* problem, and involves considerations that don't exist in the case of, say, enum labels. Instance data strings are subject to the quirks of whatever resource is being managed. Unless you're willing at the level of the metamodel to require all managed resources' implementations to conform to a particular normalization form for instance data, you're stuck with permitting the protocol to carry them all (including *none*), and to the extent that specific models represent values that may be manifested by implementations, the modeling language has to be able to represent those values. I think that horse has already left the barn, though in the future it might be useful to define normalized string subtypes, particularly for keys. >> But it's also a question for module writers. Do they have to "spell" >> their labels consistently in those cases where there are references to >> them from within or between modules? > >If it comes down to this, I think I can live with this. How does an operator with printed documentation know how the module writer has chosen to spell something? How does the writer of another module hoping to import something know? What does it mean if someone (inadvertently) changes the spelling from one version to the next? Randy From nobody Wed Oct 29 13:19:26 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 262991A88B5 for ; Wed, 29 Oct 2014 13:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, THIS_AD=0.001, 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 DHP2EgnKn3GL for ; Wed, 29 Oct 2014 13:19:14 -0700 (PDT) Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8D701A1AF0 for ; Wed, 29 Oct 2014 13:19:13 -0700 (PDT) Received: by mail-qc0-f180.google.com with SMTP id o8so3040001qcw.39 for ; Wed, 29 Oct 2014 13:19: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:content-type:content-transfer-encoding; bh=+q3uq7uQEkyCorzaqN5jrihxaYdlMQKEGdoNRMVA9bI=; b=fT2F52RZ21ga8LCHSwMzFA6ag26SGZckrJosxHFgId1hdDbbdtnW5rr+h1Rs8HNhUw 9T+IWmy9VH+HKm0NUaQucluu/1JeTAMbPOp8ajSyylVq6/rBcJpCMQKWWhXl82ZPQCWk Rq/1BTF+6i79R0Py2DgSBr7dBcfx9NijxA2/rpvpDD8ZyLhNjhROpt/kDJL312f1SHWy qzSXN5ueb84LMGKT+zbHVv4MriAU9cV+8tEP4omNw1UNwS+ZyC3f6U3M4lzqwRoviU5I 4gEpk6VUHC5+FMe0na4RSxxB67IEgYKJC30LxbYEd/0MC7gy208TnWm/s25ml2CxbV6f T2Sg== X-Gm-Message-State: ALoCoQkpn7VIcQhWz4o4N3sYgKxX88FrvrArW8eB/Tn9UUlZYPDQzhY5ModyYt4Hk+yux/KQyQpf MIME-Version: 1.0 X-Received: by 10.140.34.102 with SMTP id k93mr18142445qgk.21.1414613952816; Wed, 29 Oct 2014 13:19:12 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Wed, 29 Oct 2014 13:19:12 -0700 (PDT) In-Reply-To: <20141029150630.GA17776@elstar.local> References: <20141027220615.GB10028@elstar.local> <20141029150630.GA17776@elstar.local> Date: Wed, 29 Oct 2014 13:19:12 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , "netmod@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/mkgpVZdGv8S9pmHIxFREbMIDTjg Subject: Re: [netmod] yang 1.1 webex on wednesday october 29th X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 29 Oct 2014 20:19:18 -0000 Hi, Thanks for running this meeting. I think we made some progress on conformance. There is still 1 major detail we have not addressed, which is changing a status-stmt to 'obsolete' in the revision of a module supported by the server. This is why the draft originally had "min-revision" and "max-revision". In SMIv2 conformance, a "current" MODULE-COMPLIANCE macro cannot reference any deprecated or obsolete definitions. Does YANG need similar guidelines or rules? So what does it mean if the server uses some modules that reference external meta-data (or augment an object) that was current when written, but later changes to obsolete: Start: module A { revision 2014-01-01; import B { prefix B; revision-date 2014-01-01; } leaf broken { type B:t1; } } module B { revision 2014-01-01; typedef t1 { type string; } } Later: module B { revision 2014-10-01; typedef t1 { type string; status obsolete; } typedef t2 { type int32; } } The vendor want to implement a new module that imports type t2 from the updated module B. So what happens to a server implementing module A? Does import-by-revision make any difference? According to the meeting today, the server must pick 1 revision of module B to advertise (which must be >=3D 2014-10-01). That means the leaf "A:broken" cannot be implemented with its current defin= ition and module A needs to be updated in order to change module B in the server. IMO, the server vendor is responsible for providing a cohesive module set. This doesn't happen automatically and it is a huge problem for open systems= , but clearly no implemented object can use an obsolete typedef. The new YANG guidelines draft says a module should stay in "deprecated" sta= tus for at least a year. That just delays this problem. Andy On Wed, Oct 29, 2014 at 8:06 AM, Juergen Schoenwaelder wrote: > Hi, > > we are using this etherpad for note taking: > > http://etherpad.tools.ietf.org:9000/p/notes-ietf-netmod-virtual-interim-2= 014-10-29 > > /js > > On Mon, Oct 27, 2014 at 11:06:15PM +0100, Juergen Schoenwaelder wrote: >> During the last YANG 1.1 virtual interim meeting, we discussed to have >> another meeting to talk about the conformance related issues. >> Unfortunately, the series of virtual interim meetings allocated for >> YANG 1.1 work did end last Wednesday and since scheduling a virtual >> interim meeting requires two weeks of advance notice, we can't have an >> official virtual interim meeting on Wednesday. >> >> However, in order to not loose traction, I like to invite all people >> interested in this topic to an inofficial webex meeting taking place >> on Wednesday at 16:00 CET, which will run for at most two hours. While >> I will write the usual minutes, this is not an official virtual >> interim meeting. But hopefully this ad-hoc webex helps to come to a >> clearer view on how to move forward with the conformance related >> issues. >> >> I am attaching the webex information. The webex information is >> different from the previous virtual interim meeting webex info - so >> please make sure to join the correct webex meeting. >> >> /js >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 > >> ******* DO NOT DELETE OR CHANGE ANY OF THE TEXT BELOW THIS LINE ******* >> >> ----------------------------------------------------------------------- >> JOIN USING WebEx >> >> Go To: >> https://cisco.webex.com/cisco/j.php?MTID=3Dm6ea214f8e097453994e88aa706a7= bcad >> >> Meeting Password ----- 1234 >> Meeting Number ----- 201 602 421 >> >> ---------------------------------------------------------------- >> ALERT - PLEASE READ: DO NOT DIAL THE TOLL FREE NUMBERS FROM WITHIN THE (= 408) OR (919) AREA CODES >> ---------------------------------------------------------------- >> Please dial the local access number for your area from the list below: >> - San Jose/Milpitas (408) area: 525-6800 >> - RTP (919) area: 392-3330 >> >> Dialing the WebEx toll free numbers from within 408 or 919 area codes is= not enabled (non-Cisco phones). " If you dial the toll-free numbers withi= n the 408 or 919 area codes you will be instructed to hang up and dial the = local access number." Please use the call-back option whenever possible and= otherwise dial local numbers only. The affected toll free numbers are: (8= 66) 432-9903 for the San Jose/Milpitas area and (866) 349-3520 for the RTP = area. >> >> ------------------------------------------------------- >> To join the teleconference only >> ------------------------------------------------------- >> 1. Dial into Cisco WebEx (view all Global Access Numbers at >> http://cisco.com/en/US/about/doing_business/conferencing/index.html >> 2. Follow the prompts to enter the Meeting Number (listed above) or Acce= ss Code followed by the # sign. >> >> San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 >> >> US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 >> >> India: +91.80.4350.1111 Germany: +49.619.6773.9002 >> >> Japan: +81.3.5763.9394 China: +86.10.8515.5666 >> >> IMPORTANT NOTICE: This WebEx service includes a feature that allows audi= o and any documents and other materials exchanged or viewed during the sess= ion to be recorded. By joining this session, you automatically consent to s= uch recordings. If you do not consent to the recording, discuss your concer= ns with the meeting host prior to the start of the recording or do not join= the session. Please note that any such recordings may be subject to discov= ery in the event of litigation. >> > > > -- > 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 Oct 29 16:32:47 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5045A1ACD0D for ; Wed, 29 Oct 2014 16:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, 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 zWAhsXx3gqLD for ; Wed, 29 Oct 2014 16:32: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 6ADD21A016A for ; Wed, 29 Oct 2014 16:32: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 E5CCF89D; Thu, 30 Oct 2014 00:32:40 +0100 (CET) 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 nOcxXZm7sQ30; Thu, 30 Oct 2014 00:32:23 +0100 (CET) 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, 30 Oct 2014 00:32:40 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 491B120038; Thu, 30 Oct 2014 00:32:40 +0100 (CET) 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 UY934QM6qi6j; Thu, 30 Oct 2014 00:32:39 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6622220035; Thu, 30 Oct 2014 00:32:38 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 5D7352F1A170; Thu, 30 Oct 2014 00:32:37 +0100 (CET) Date: Thu, 30 Oct 2014 00:32:36 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20141029233236.GA19176@elstar.local> Mail-Followup-To: Andy Bierman , "netmod@ietf.org" References: <20141027220615.GB10028@elstar.local> <20141029150630.GA17776@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: http://mailarchive.ietf.org/arch/msg/netmod/uzj2jQyuj6jqLkIjsBePUMR5338 Cc: "netmod@ietf.org" Subject: Re: [netmod] yang 1.1 webex on wednesday october 29th 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, 29 Oct 2014 23:32:44 -0000 On Wed, Oct 29, 2014 at 01:19:12PM -0700, Andy Bierman wrote: > > IMO, the server vendor is responsible for providing a cohesive module set. > This doesn't happen automatically and it is a huge problem for open systems, > but clearly no implemented object can use an obsolete typedef. > The new YANG guidelines draft says a module should stay in "deprecated" status > for at least a year. That just delays this problem. > As long as you control all your modules, this may be achievable. If you, however, implement a mix of modules, some under your control and some not, then I assume you may have a hard time. Suppose the IETF updates a common module like lets say ietf-yang-types by adding a new type and deprecating / obsoleting an old type. Lets further assume that the IETF manages to update all modules that used the now obsolete type definition - so all IETF modules are fine using the new version of ietf-yang-types. Lets further assume that some other organization, say IEEE, uses ietf-yang-types as well in their modules but they do not update as quickly as the IETF does it in the future. Your customers now want both IETF and IEEE modules to be implemented. What do you do? /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 Oct 29 17:04:37 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 934131ACDA8 for ; Wed, 29 Oct 2014 17:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 v47sD8xpxV4s for ; Wed, 29 Oct 2014 17:04:33 -0700 (PDT) Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D50901ACDA3 for ; Wed, 29 Oct 2014 17:04:32 -0700 (PDT) Received: by mail-qg0-f45.google.com with SMTP id z107so3205158qgd.18 for ; Wed, 29 Oct 2014 17:04:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=yUksee3Fe+LU53swJJvjsH3vuf1Vhoe8b1YTH9m0KVE=; b=Lawr5TR960BJLsL3PWBehhfqnlnqPG0bMmqPBB6sUdB1oI1l1Be3pNU3HHQDvGV9wY nHtAHDV0+e6tLVGWvR7pbQg7uw+5pm/kFgLHliz2Av0H2BrUfG78fKUm00ap3cMTJSwV 4oHzBDyU5kKCSUDO/5ADBLXQN0pnuCi107B1+W8UfMtRhIVoR5E0ZTb0srLap2LxFwS5 muZ+pRKGgXbAFzjKMfifIEdBpRAhsFzSujJuUi9KH+8KwnRM31E5uWK8GzsXJvQgU94C W12UPBKVD211jumYkVs7V/Es7u0v7HNMKRlwFiFXIgsDEmhMqLwjN6aF6/9HDvvTeZPU sqLQ== X-Gm-Message-State: ALoCoQmYOIrqtMHyWihIUxCOZ7weE1+S8mryRm+QgNbGCxLtH/C3YpHYKxyI11nq7WuKBL0CkQJe MIME-Version: 1.0 X-Received: by 10.224.66.200 with SMTP id o8mr21483596qai.88.1414627471795; Wed, 29 Oct 2014 17:04:31 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Wed, 29 Oct 2014 17:04:31 -0700 (PDT) In-Reply-To: <20141029233236.GA19176@elstar.local> References: <20141027220615.GB10028@elstar.local> <20141029150630.GA17776@elstar.local> <20141029233236.GA19176@elstar.local> Date: Wed, 29 Oct 2014 17:04:31 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , "netmod@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/NlxOZGiLQCCEddbd7y4TFIWHrew Subject: Re: [netmod] yang 1.1 webex on wednesday october 29th X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 30 Oct 2014 00:04:35 -0000 On Wed, Oct 29, 2014 at 4:32 PM, Juergen Schoenwaelder wrote: > On Wed, Oct 29, 2014 at 01:19:12PM -0700, Andy Bierman wrote: >> >> IMO, the server vendor is responsible for providing a cohesive module set. >> This doesn't happen automatically and it is a huge problem for open systems, >> but clearly no implemented object can use an obsolete typedef. >> The new YANG guidelines draft says a module should stay in "deprecated" status >> for at least a year. That just delays this problem. >> > > As long as you control all your modules, this may be achievable. If > you, however, implement a mix of modules, some under your control and > some not, then I assume you may have a hard time. > > Suppose the IETF updates a common module like lets say ietf-yang-types > by adding a new type and deprecating / obsoleting an old type. Lets > further assume that the IETF manages to update all modules that used > the now obsolete type definition - so all IETF modules are fine using > the new version of ietf-yang-types. Lets further assume that some > other organization, say IEEE, uses ietf-yang-types as well in their > modules but they do not update as quickly as the IETF does it in the > future. Your customers now want both IETF and IEEE modules to be > implemented. What do you do? > I was going to add to the last email that I don't see any way the IETF can set a status-stmt in reusable definitions to obsolete. Maybe for objects, but not typedefs or groupings. Deprecated just means the definition might go away someday. Even if we use the old definition of import-by-revision, what does it mean to honor status=current in ver. 1 and status = obsolete in ver. 2, at the same time? The tree of dependency trees gets complicated very fast. None of the SNMP server code I worked on supported multiple revisions of any module in the agent. There was 1 module loaded for each module name. SMIv2 has no way to import a specific revision of a definition. > /js Andy > > -- > 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 Oct 29 19:29:37 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 321661ACFDD for ; Wed, 29 Oct 2014 19:29:36 -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, 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 wCOhzOeOVT2T for ; Wed, 29 Oct 2014 19:29:35 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id E47DE1ACFE0 for ; Wed, 29 Oct 2014 19:29:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=owVygbHtbAM5ku/aREw6yc3LsBLfaAK3HqDEG1ZlPvCp3GiaUgUdWMzZngxHV77b; 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.46] (helo=elwamui-royal.atl.sa.earthlink.net) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1XjfUU-00005v-2F for netmod@ietf.org; Wed, 29 Oct 2014 22:29:34 -0400 Received: from 76.254.52.158 by webmail.earthlink.net with HTTP; Wed, 29 Oct 2014 22:29:33 -0400 Message-ID: <23182626.1414636173858.JavaMail.root@elwamui-royal.atl.sa.earthlink.net> Date: Wed, 29 Oct 2014 19:29:33 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88825aa8a2065c9591ffd3ca9f39cef43ac54a45d0e55721a04350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.46 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/hW5sQZ8RKKNa3EhntTDBa543vl0 Subject: Re: [netmod] yang 1.1 webex on wednesday october 29th 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, 30 Oct 2014 02:29:36 -0000 Hi - >From: Andy Bierman >Sent: Oct 29, 2014 5:04 PM >To: Juergen Schoenwaelder , Andy Bierman , "netmod@ietf.org" >Subject: Re: [netmod] yang 1.1 webex on wednesday october 29th ... >None of the SNMP server code I worked on supported multiple revisions >of any module in the agent. There was 1 module loaded for each module name. >SMIv2 has no way to import a specific revision of a definition. FWIW, though, it's really easy to support this in systems using subagent technology, in part due to the SMI's restrictive rules for revising modules. It's not terribly likely in single vendor single processor boxes where all the firmware is kept in synch. In "open" systems, and ones in which subagent soft/firmware resides on more-or-less independently updated line cards or similar modules, it can very easily happen. Coping with this gracefully is one of the big plusses of subagent technologies. Randy From nobody Thu Oct 30 00:35:43 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E2B1AD045 for ; Thu, 30 Oct 2014 00:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, 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 uuDOxKb7kGXZ for ; Thu, 30 Oct 2014 00:35:40 -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 CDB511AD044 for ; Thu, 30 Oct 2014 00:35: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 5C3A4FA9; Thu, 30 Oct 2014 08:35:37 +0100 (CET) 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 uS7_Yz2JXyzw; Thu, 30 Oct 2014 08:35:17 +0100 (CET) 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, 30 Oct 2014 08:35:36 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A13CB20038; Thu, 30 Oct 2014 08:35:36 +0100 (CET) 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 3KRkxNnad0xO; Thu, 30 Oct 2014 08:35:36 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9359C20035; Thu, 30 Oct 2014 08:35:35 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 5FB092F1A9F3; Thu, 30 Oct 2014 08:35:32 +0100 (CET) Date: Thu, 30 Oct 2014 08:35:32 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20141030073532.GA20289@elstar.local> Mail-Followup-To: Andy Bierman , "netmod@ietf.org" References: <20141027220615.GB10028@elstar.local> <20141029150630.GA17776@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: http://mailarchive.ietf.org/arch/msg/netmod/tdosEmzD04QA-XhINm4dmUlRnYA Cc: "netmod@ietf.org" Subject: Re: [netmod] yang 1.1 webex on wednesday october 29th 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, 30 Oct 2014 07:35:41 -0000 On Wed, Oct 29, 2014 at 01:19:12PM -0700, Andy Bierman wrote: > > There is still 1 major detail we have not addressed, > which is changing a status-stmt to 'obsolete' in the > revision of a module supported by the server. > > This is why the draft originally had "min-revision" and "max-revision". > > In SMIv2 conformance, a "current" MODULE-COMPLIANCE macro cannot > reference any deprecated or obsolete definitions. Does YANG need > similar guidelines or rules? > In SMIv2, you explicitly declare the set of objects that are required for a certain compliance level. With YANG, the current idea is that this can be avoided by having compliance fall out of the modules themself. This is tricky, in particular when (a) a device implements modules not under change control of the device manufacturer and (b) a device that allows to plugin data model implementations maintained by 3rd parties. Concerning deprecated and obsolete, there is also a difference between what a module maintainer wants to see happening and what the real world is going to do. For example, a bunch of basic SNMP counters became 'obsolete' in SNMPv2-MIB (RFC 3418 - published ~12 years ago) and it is likely that your SNMP agents still implements them. Now, this is monitoring but then updating instrumentation for configuration is even more effort. /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 Oct 30 01:14:06 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D50701AD041 for ; Thu, 30 Oct 2014 01:14: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 ouTn6v9d0R7P for ; Thu, 30 Oct 2014 01:14:02 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 472761AD036 for ; Thu, 30 Oct 2014 01:14:02 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 90FC11280098; Thu, 30 Oct 2014 09:14:00 +0100 (CET) Date: Thu, 30 Oct 2014 09:14:00 +0100 (CET) Message-Id: <20141030.091400.1184673521211377996.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <23182626.1414636173858.JavaMail.root@elwamui-royal.atl.sa.earthlink.net> References: <23182626.1414636173858.JavaMail.root@elwamui-royal.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: http://mailarchive.ietf.org/arch/msg/netmod/w1yX57Mksl4ISZDiucle77UrV_0 Cc: netmod@ietf.org Subject: Re: [netmod] yang 1.1 webex on wednesday october 29th X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 30 Oct 2014 08:14:05 -0000 Randy Presuhn wrote: > Hi - > > >From: Andy Bierman > >Sent: Oct 29, 2014 5:04 PM > >To: Juergen Schoenwaelder , Andy Bierman , "netmod@ietf.org" > >Subject: Re: [netmod] yang 1.1 webex on wednesday october 29th > ... > >None of the SNMP server code I worked on supported multiple revisions > >of any module in the agent. There was 1 module loaded for each module name. > >SMIv2 has no way to import a specific revision of a definition. > > FWIW, though, it's really easy to support this in systems using > subagent technology, in part due to the SMI's restrictive rules > for revising modules. It's not terribly likely in single vendor > single processor boxes where all the firmware is kept in synch. > In "open" systems, and ones in which subagent soft/firmware > resides on more-or-less independently updated line cards or similar > modules, it can very easily happen. Coping with this gracefully > is one of the big plusses of subagent technologies. I don't think the subagent mechanism solves the problem. Suppose you have a column in some table in v1 of a MIB. In v2 this column's syntax has an expanded range. Now, suppose subagent A implements v1 of the MIB, and registers for one row in the table, and subagent B implements v2 of the MIB and registers for another row. How does the SNMP manager know which instances of column C support the new values introduced in v2, and which don't? /martin From nobody Thu Oct 30 04:02:11 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9CBE1AD0B8 for ; Thu, 30 Oct 2014 04:02:09 -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 P2Ar8oevcP02 for ; Thu, 30 Oct 2014 04:02:03 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 643D41AD0B1 for ; Thu, 30 Oct 2014 04:02:03 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 69A421280098; Thu, 30 Oct 2014 12:01:59 +0100 (CET) Date: Thu, 30 Oct 2014 12:01:59 +0100 (CET) Message-Id: <20141030.120159.198377535691531775.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20141029233236.GA19176@elstar.local> References: <20141029150630.GA17776@elstar.local> <20141029233236.GA19176@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: http://mailarchive.ietf.org/arch/msg/netmod/aosdttxtqhyfhT5fqwF3nJMllz8 Cc: netmod@ietf.org Subject: Re: [netmod] yang 1.1 webex on wednesday october 29th X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 30 Oct 2014 11:02:09 -0000 Juergen Schoenwaelder wrote: > On Wed, Oct 29, 2014 at 01:19:12PM -0700, Andy Bierman wrote: > > > > IMO, the server vendor is responsible for providing a cohesive module set. > > This doesn't happen automatically and it is a huge problem for open systems, > > but clearly no implemented object can use an obsolete typedef. > > The new YANG guidelines draft says a module should stay in "deprecated" status > > for at least a year. That just delays this problem. > > > > As long as you control all your modules, this may be achievable. If > you, however, implement a mix of modules, some under your control and > some not, then I assume you may have a hard time. Yes, but consider the alternative. Suppose we have two versions of a typedef, one with an expanded range. We also have a bunch of leafs in various data models that reference this typedef. If we also have something like the proposed mount mechanism (or some subagent mechanism), then it means that potentially the client somehow needs to figure out which version of the type is used for every single instance of these leafs in the *data store*. I.e., it is not sufficient to say that a certain module uses a certain revision of a typedef; it can be different for different data instances as well. The only (?) 100% safe thing to do would be to never allow any changes in the value space for a typedef or grouping. Then we'll see constructs like this: typedef foo { ... } typedef foo-v2 { ... } typedef foo-v3 { ... } /martin From nobody Thu Oct 30 04:53:16 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A84FC1AD0A2 for ; Thu, 30 Oct 2014 04:53: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 O6zueYj1Qsqa for ; Thu, 30 Oct 2014 04:53:13 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id DC3771AD0A9 for ; Thu, 30 Oct 2014 04:53:12 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 0A0AA128099A for ; Thu, 30 Oct 2014 12:53:09 +0100 (CET) Date: Thu, 30 Oct 2014 12:53:08 +0100 (CET) Message-Id: <20141030.125308.1037916628144270920.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <20141002093053.GB40545@elstar.local> References: <20141002083148.1436.15021.idtracker@ietfa.amsl.com> <20141002.103643.614023022702737829.mbj@tail-f.com> <20141002093053.GB40545@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: http://mailarchive.ietf.org/arch/msg/netmod/m8Hi5WwCbBywsCGh9f-B66ZBE0s Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-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: Thu, 30 Oct 2014 11:53:14 -0000 Hi, A gentle reminder of a draft in the need of review! Number of reviews so far: 0 Juergen Schoenwaelder wrote: > On Thu, Oct 02, 2014 at 10:36:43AM +0200, Martin Bjorklund wrote: > > Hi, > > > > I have posted draft-ietf-netmod-rfc6020bis-01.txt, which addresses 11 > > of our issues. These issues are now in the REVIEW state in the issues > > list (https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html) > > > > Please review the draft or the diff to make sure that these issues are > > properly addressed. When these are reviewed, I will post a new > > version with a new set of issues addressed. > > > > WG members, > > once you have reviewed the changes, send a short note to the list so > that we can track that reviews of the edits have been done. > > /js /martin From nobody Thu Oct 30 08:57:45 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41CF01AD50E for ; Thu, 30 Oct 2014 08:57:39 -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 BGjpwidccf-D for ; Thu, 30 Oct 2014 08:57:37 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1D391AD4ED for ; Thu, 30 Oct 2014 08:57:36 -0700 (PDT) Received: from [192.168.1.108] (unknown [195.113.220.254]) by mail.nic.cz (Postfix) with ESMTPSA id 4BD2613F680; Thu, 30 Oct 2014 16:57:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1414684655; bh=gbsPwS3erGOxyaPnVYYKSp7JhWjoocEKXfTvh/H1gBI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=eSKEFkw1jaUr4DE2w7nS18GVWT5rAQjfJxEriHuljNjoCe2zdJw8uI0EbgPNCpCTt aGPnMPcactmiJEs/r9N7XcQKS3eZmrIF2OqXmMhPstcug79K2IpZU+ImbSOQR7Vtks 3g+Ld2+MRYZVvdKKwX1C84LMoyxoYdR94KeC136I= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <20141030.120159.198377535691531775.mbj@tail-f.com> Date: Thu, 30 Oct 2014 16:57:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141029150630.GA17776@elstar.local> <20141029233236.GA19176@elstar.local> <20141030.120159.198377535691531775.mbj@tail-f.com> To: =?windows-1252?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/uKMbWf9EUNeRM60sCqQ793VTuRg Cc: netmod@ietf.org Subject: Re: [netmod] yang 1.1 webex on wednesday october 29th X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 30 Oct 2014 15:57:39 -0000 On 30 Oct 2014, at 12:01, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: >> On Wed, Oct 29, 2014 at 01:19:12PM -0700, Andy Bierman wrote: >>>=20 >>> IMO, the server vendor is responsible for providing a cohesive = module set. >>> This doesn't happen automatically and it is a huge problem for open = systems, >>> but clearly no implemented object can use an obsolete typedef. >>> The new YANG guidelines draft says a module should stay in = "deprecated" status >>> for at least a year. That just delays this problem. >>>=20 >>=20 >> As long as you control all your modules, this may be achievable. If >> you, however, implement a mix of modules, some under your control and >> some not, then I assume you may have a hard time. >=20 > Yes, but consider the alternative. Suppose we have two versions of a > typedef, one with an expanded range. We also have a bunch of leafs in > various data models that reference this typedef. If we also have > something like the proposed mount mechanism (or some subagent > mechanism), then it means that potentially the client somehow needs to > figure out which version of the type is used for every single instance > of these leafs in the *data store*. I.e., it is not sufficient to say > that a certain module uses a certain revision of a typedef; it can be > different for different data instances as well. In the case of mount, I think the only reasonable solution is to forward = somehow to the client the information about exact versions of modules = used for mounted subtrees. Perhaps this could be attached as metadata to = each mount point. The format of capabilities in hello doesn=92t scale well for complex = data model specifications. Lada >=20 > The only (?) 100% safe thing to do would be to never allow any changes > in the value space for a typedef or grouping. Then we'll see > constructs like this: >=20 > typedef foo { ... } > typedef foo-v2 { ... } > typedef foo-v3 { ... } >=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 Oct 30 10:09:05 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDCEE1A066C for ; Thu, 30 Oct 2014 10:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 8MklKKk2OPpx for ; Thu, 30 Oct 2014 10:08:54 -0700 (PDT) Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07BDC1A039B for ; Thu, 30 Oct 2014 10:00:36 -0700 (PDT) Received: by mail-qc0-f175.google.com with SMTP id b13so5060029qcw.34 for ; Thu, 30 Oct 2014 10:00: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 :content-transfer-encoding; bh=3gCmxxJ4PwYuznPKL4sA4OhO2Z+Uy3QuSxh0XtVcQwY=; b=dEsA+l+kywPRYsMoWi7qJe2wFzv5x+jV12ceSv+ysAVrVVCLdkBwv7MnMqXI6JHwTO UNNrW57m+fR1KSomT9NUXxDaS0RTJ/7G39I/k9i+fbfA0rKMtHh0e5xj05UvQiJ26sIK UNlv6ZY0sesdxLo0iOnnOMQFBmmfye9izullvN3TWJfzf2F/loLHo4QCAxXK270L7zPs Dc5gVL2DCEPjyxXN5nxzimBlj3du7fj5IUuBMFzPNdXo7tnMHCZzn74BiGmr9GR/QMJo CFyJPdKwRv5INwyQfA3R5aAFowAdI1VXXo+creav1wD8YO1yU+F0HzuL/5ja6JLwOT8+ aRrA== X-Gm-Message-State: ALoCoQkFwKum3g7wjTgb+I/BpYBDyAtadUZlZtueZup0GwzySbd+AcJsyFhIkLaUNMF8/LOkx592 MIME-Version: 1.0 X-Received: by 10.224.132.70 with SMTP id a6mr27919367qat.16.1414688435366; Thu, 30 Oct 2014 10:00:35 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Thu, 30 Oct 2014 10:00:35 -0700 (PDT) In-Reply-To: References: <20141029150630.GA17776@elstar.local> <20141029233236.GA19176@elstar.local> <20141030.120159.198377535691531775.mbj@tail-f.com> Date: Thu, 30 Oct 2014 10:00:35 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/X5SE89TYmR7xv3klICONugXGYIg Cc: "netmod@ietf.org" Subject: Re: [netmod] yang 1.1 webex on wednesday october 29th X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 30 Oct 2014 17:09:00 -0000 On Thu, Oct 30, 2014 at 8:57 AM, Ladislav Lhotka wrote: > > On 30 Oct 2014, at 12:01, Martin Bjorklund wrote: > >> Juergen Schoenwaelder wrote: >>> On Wed, Oct 29, 2014 at 01:19:12PM -0700, Andy Bierman wrote: >>>> >>>> IMO, the server vendor is responsible for providing a cohesive module = set. >>>> This doesn't happen automatically and it is a huge problem for open sy= stems, >>>> but clearly no implemented object can use an obsolete typedef. >>>> The new YANG guidelines draft says a module should stay in "deprecated= " status >>>> for at least a year. That just delays this problem. >>>> >>> >>> As long as you control all your modules, this may be achievable. If >>> you, however, implement a mix of modules, some under your control and >>> some not, then I assume you may have a hard time. >> >> Yes, but consider the alternative. Suppose we have two versions of a >> typedef, one with an expanded range. We also have a bunch of leafs in >> various data models that reference this typedef. If we also have >> something like the proposed mount mechanism (or some subagent >> mechanism), then it means that potentially the client somehow needs to >> figure out which version of the type is used for every single instance >> of these leafs in the *data store*. I.e., it is not sufficient to say >> that a certain module uses a certain revision of a typedef; it can be >> different for different data instances as well. > > In the case of mount, I think the only reasonable solution is to forward = somehow to the client the information about exact versions of modules used = for mounted subtrees. Perhaps this could be attached as metadata to each mo= unt point. > > The format of capabilities in hello doesn=E2=80=99t scale well for comple= x data model specifications. > I don't agree that the message scales are worse than retrieving the same information with a operation. I don't understand the value of replicating all the server data models in a controller (or is it a glorified cache?), but that is a different issue. > Lada Andy > >> >> The only (?) 100% safe thing to do would be to never allow any changes >> in the value space for a typedef or grouping. Then we'll see >> constructs like this: >> >> typedef foo { ... } >> typedef foo-v2 { ... } >> typedef foo-v3 { ... } >> >> >> /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 Thu Oct 30 10:16:25 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85BB11A038B for ; Thu, 30 Oct 2014 10:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 GFgHDUO-6T8c for ; Thu, 30 Oct 2014 10:16:19 -0700 (PDT) Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B58A21A036B for ; Thu, 30 Oct 2014 10:14:13 -0700 (PDT) Received: by mail-qa0-f53.google.com with SMTP id n8so4100338qaq.12 for ; Thu, 30 Oct 2014 10:14:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=eyP2ctTEQYELM5qTd2jTibqZDxyEQB4vbzVsCNaHxtc=; b=ft+3YOkbiTcoPWQ+SEjhgnmn1HmJD09Gz/jSYm4YhWfCKqnIfH8A0RMY2a912k+sSM mbwdgztiZ+9b/n24uQNJcUxfSy74wVwRVURoT+kUukl295vIYshSA7C9dRUj9smwxcll F8Qp+KV8MlYok50vydnC7mWo4CDSSwkp+sTlnegVeP0sRZdMf0Wh5cSqDX28jKYDjR3U pTW4zpiQ7Fn4VytaaQaO013GpHE2HthnYVpPoRtBAbevGdaXjnN2N/CMU2FhiIpRR//d 9hVCiKJGwVPi/6nP2gd+F3sZMXUNpg0WuA3cb7anY5Q9lYLkCl8zHx5I4YvK88JLCZzE Y3dA== X-Gm-Message-State: ALoCoQmgLDnLnR/7PUHBAVUIQ2AXH/Td4GZPlPMVDh1sk+yg49FfB2/qR9IVB7UxHnxP2E+Ib3ap MIME-Version: 1.0 X-Received: by 10.229.252.196 with SMTP id mx4mr28476308qcb.4.1414689252492; Thu, 30 Oct 2014 10:14:12 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Thu, 30 Oct 2014 10:14:12 -0700 (PDT) In-Reply-To: <20141030.120159.198377535691531775.mbj@tail-f.com> References: <20141029150630.GA17776@elstar.local> <20141029233236.GA19176@elstar.local> <20141030.120159.198377535691531775.mbj@tail-f.com> Date: Thu, 30 Oct 2014 10:14:12 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/EQoza7DPAZyPc8q-ENa2D7C3xj4 Cc: "netmod@ietf.org" Subject: Re: [netmod] yang 1.1 webex on wednesday october 29th X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 30 Oct 2014 17:16:24 -0000 On Thu, Oct 30, 2014 at 4:01 AM, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: >> On Wed, Oct 29, 2014 at 01:19:12PM -0700, Andy Bierman wrote: >> > >> > IMO, the server vendor is responsible for providing a cohesive module set. >> > This doesn't happen automatically and it is a huge problem for open systems, >> > but clearly no implemented object can use an obsolete typedef. >> > The new YANG guidelines draft says a module should stay in "deprecated" status >> > for at least a year. That just delays this problem. >> > >> >> As long as you control all your modules, this may be achievable. If >> you, however, implement a mix of modules, some under your control and >> some not, then I assume you may have a hard time. > > Yes, but consider the alternative. Suppose we have two versions of a > typedef, one with an expanded range. We also have a bunch of leafs in > various data models that reference this typedef. If we also have > something like the proposed mount mechanism (or some subagent > mechanism), then it means that potentially the client somehow needs to > figure out which version of the type is used for every single instance > of these leafs in the *data store*. I.e., it is not sufficient to say > that a certain module uses a certain revision of a typedef; it can be > different for different data instances as well. > Consider the possibility that we never really experienced lifecycle complexity before, because monitoring is trivial compared to configuration. The notion that an application writer can code to a set of fixed modules and that set will never change over the years is flawed. It was never achievable in SNMP, but we didn't really notice because it was 98% monitoring. The equipment or systems vendor is providing a system, not some random collection of sub-agents. It is their responsibility to maintain a cohesive system even if that means some code needs to be touched. > The only (?) 100% safe thing to do would be to never allow any changes > in the value space for a typedef or grouping. Then we'll see > constructs like this: > > typedef foo { ... } > typedef foo-v2 { ... } > typedef foo-v3 { ... } > Sometimes this is the best approach -- I do it all the time in C code, because it is safer and less work than re-coding and retesting all the components using the existing definition. This approach preserves the original API contract until it is updated manually and intentionally. > > /martin Andy From nobody Thu Oct 30 10:44:14 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 106E51A01AE for ; Thu, 30 Oct 2014 10:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 rKkyloAynM2M for ; Thu, 30 Oct 2014 10:44:11 -0700 (PDT) Received: from mail-qc0-f174.google.com (mail-qc0-f174.google.com [209.85.216.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBBE61A040C for ; Thu, 30 Oct 2014 10:44:09 -0700 (PDT) Received: by mail-qc0-f174.google.com with SMTP id r5so4571974qcx.33 for ; Thu, 30 Oct 2014 10:44: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=gMrDP4t3RBGqbMBZgsZy36TmzEv2MPbjpR6Lu+BRL9A=; b=cDGsd5usVLXIfTfgWZc0TfD490cMYGDhwVjwtWK7XPWQZMNnq6gE59bAo9N1ebhoaV OPTJFhXck6uyvWymhT62soD9mD1Fi1hbc7xIOFBefVconsgiscdw5IUhbJm1IJJd8dfN mrcQER/TuYd+UAdoXQZAy3M4aa1zaHtddm9ETyaT0kCLFwa34tFb4rAfBoBt9QiXt2Mz PtZXnigVnpv6ZN8F+RUKZT3NUNn+E16AqLlGdLaX2nRHYrjcanORrhg0n6Sw+9J2uE+0 SejSDyuGSh6v0Ai5EZ9fImzpYyaFLX24FvDwnyQ8VcK4rUFahavkZpyG1oWxma2vAAXO 7jeg== X-Gm-Message-State: ALoCoQm8QmE5/I+Crwfh4q0pvVBrqyZdJ/1cqAgv1bGap79VWiKpWSsC5GqCjv5v0Xsc35DmK7F6 MIME-Version: 1.0 X-Received: by 10.140.92.148 with SMTP id b20mr27281544qge.35.1414691049081; Thu, 30 Oct 2014 10:44:09 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Thu, 30 Oct 2014 10:44:08 -0700 (PDT) In-Reply-To: <20141030.120159.198377535691531775.mbj@tail-f.com> References: <20141029150630.GA17776@elstar.local> <20141029233236.GA19176@elstar.local> <20141030.120159.198377535691531775.mbj@tail-f.com> Date: Thu, 30 Oct 2014 10:44:08 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/rkE3La9u3WJF0PrETcoJKSNd_Ws Cc: "netmod@ietf.org" Subject: Re: [netmod] yang 1.1 webex on wednesday october 29th X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 30 Oct 2014 17:44:13 -0000 On Thu, Oct 30, 2014 at 4:01 AM, Martin Bjorklund wrote: ... > The only (?) 100% safe thing to do would be to never allow any changes > in the value space for a typedef or grouping. Then we'll see > constructs like this: > > typedef foo { ... } > typedef foo-v2 { ... } > typedef foo-v3 { ... } > Let's think about why one would ever change a typedef or grouping. 1) defect: The definition needs to be corrected. In this case, we don't want the old definition used at all. Forcing all modules to upgrade at once is not unreasonable. 2) enhancement: New functionality is being added. It may be OK for existing usage to continue unchanged. If so, then a new typedef or grouping is needed, so the old usage remains valid and represented correctly in the schema. If not, then the old functionality is somehow obsolete and we don't want the old definition used anymore. > /martin Andy From nobody Thu Oct 30 12:17:03 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7410D1A1B62 for ; Thu, 30 Oct 2014 12:17:01 -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 YqvjOavDpuBL for ; Thu, 30 Oct 2014 12:16:58 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C44C31A1B66 for ; Thu, 30 Oct 2014 12:16:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=214548; q=dns/txt; s=iport; t=1414696617; x=1415906217; h=from:to:cc:subject:date:message-id:mime-version; bh=4FQX6AxEjrh6h4wMX2vQ//KSu29+rSyfIqXmDDNhGps=; b=jnioRfZTcS6Ce1Hgxp9WRrUF6znLrQttZlfQNtrdwz60EH3c2YskqyYd kwSQW24O8C1q/ynpYLNC84uEr1IaE494qmpILHP8PEp1k/NOvnJdMRyAm kLkwm+LUC9yoXlii+MnLvycC+Kxi4jyzC3lVD1Ifa1OX/twE+faBczEEL E=; X-Files: image003.png : 148588 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAE6OUlStJV2R/2dsb2JhbABcgkhGVFgEzR2HSwKBJBYBAQEBAX2EBAEEBSAIAUsSAR0IAQEBAhkNBRABDgwmAQQBDQQBBgIBBQ2IJg3KWAEBAQEBAQEBAQEBAQEBAQEBAQEBAReQXg0kC4MpgR4FkhCDYgGeQYI0gURsAYFHgQMBAQE X-IronPort-AV: E=Sophos;i="5.07,288,1413244800"; d="png'150?scan'150,208,217,150";a="91819175" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-1.cisco.com with ESMTP; 30 Oct 2014 19:16:55 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s9UJGshv001772 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Oct 2014 19:16:54 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.58]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Thu, 30 Oct 2014 14:16:54 -0500 From: "Eric Voit (evoit)" To: Andy Bierman , Kent Watsen Thread-Topic: YANG model containing both device and domain config (was RE: [netmod] New revision of YANG mount draft) Thread-Index: Ac/0dgOg0IIxE7lQS6W0YT3SwyQ17g== Date: Thu, 30 Oct 2014 19:16:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.154.208.25] Content-Type: multipart/related; boundary="_004_EF64FF31F4C4384DBCE5D513A791C2B120A5A84Cxmbalnx11ciscoc_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/mIfBbv00gzKAyajHPZENYhpj1Es Cc: "netmod@ietf.org" Subject: [netmod] YANG model containing both device and domain config (was RE: New revision of YANG mount draft) X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 30 Oct 2014 19:17:01 -0000 --_004_EF64FF31F4C4384DBCE5D513A791C2B120A5A84Cxmbalnx11ciscoc_ Content-Type: multipart/alternative; boundary="_000_EF64FF31F4C4384DBCE5D513A791C2B120A5A84Cxmbalnx11ciscoc_" --_000_EF64FF31F4C4384DBCE5D513A791C2B120A5A84Cxmbalnx11ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Andy, Two weeks ago I promised a useful YANG model which exposes both device and = domain config. The model is here: http://www.ietf.org/internet-drafts/draft-tripathy-cloud-sla-yang-model-00.= txt A simple "Cloud Policer" application can sit completely upon the model. Th= e algorithm might be: (1) The Operator enters a maximum data rate across a federation (Cloud) of = devices (2) Sum the current bandwidth across the collection of devices in the feder= ation (via RFC 7223 YANG device interface statistics) (3) Policed Bandwidth rate each device =3D (current traffic to the device /= current federation traffic) * Operator established Federation Max rate (4) Go back to step (2) If we set the federation bandwidth to 100MB/s, and then vary the offered to= two devices, the result looks like this. [cid:image003.png@01CFF452.DF63A9A0] Effectively we are showing the config of domain and device upon one graph. = And the device config is varying over time based on Peer Mounted RFC 7223 = YANG interface statistics. This is running code. The code is portable so that it can run on a control= ler, or it can run upon a designated router within the federation. Eric From: Andy Bierman, October 14, 2014 6:47 PM I do not agree that the "collection of device models" is a very interesting= solution for network management at the network level. We have dabbled with "network= -wide" configuration a couple times, only to drop the issue. IMO the models at th= is level describe the network, not the devices. There is some glue that tells the c= ontroller what devices are available, and how to talk to them, but the goal is to handle the device le= vel details as part of the controller data model implementation. We have a YANG model for Cloud Policer and DDoS Thresholding which e= xposes the interplay of domain and device view. I will strive to get it p= osted as a new draft before Oct 27th. (IETF 91 cut-off date.) Eric Eric Voit Principal Engineer - CSG --_000_EF64FF31F4C4384DBCE5D513A791C2B120A5A84Cxmbalnx11ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Andy,

 

Two weeks ago I promised a useful YANG model which e= xposes both device and domain config.  The model is here:

http://www.ietf.org/internet-draf= ts/draft-tripathy-cloud-sla-yang-model-00.txt

 

A simple “Cloud Policer” application can= sit completely upon the model.  The algorithm might be:

 

(1) The Operator enters a maximum data rate across a= federation (Cloud) of devices

 

(2) Sum the current bandwidth across the collection = of devices in the federation (via RFC 7223 YANG device interface statistics= )

 

(3) Policed Bandwidth rate each device =3D (current = traffic to the device / current federation traffic) * Operator established = Federation Max rate

 <= /p>

(4) Go back to ste= p (2)

 <= /p>

If we set the fede= ration bandwidth to 100MB/s, and then vary the offered to two devices, the = result looks like this.

 <= /p>

Effectively we are= showing the config of domain and device upon one graph.  And the devi= ce config is varying over time based on Peer Mounted RFC 7223 YANG interfac= e statistics. 

 <= /p>

This is running co= de.  The code is portable so that it can run on a controller, or it ca= n run upon a designated router within the federation.

 <= /p>

Eric

 <= /p>

 <= /p>

From:<= /span> Andy Bierman, October 14, 2014 6:47 PM

<snip>

 

I do not agree that the "collection of device m= odels" is a very interesting solution

for network management at the network level.  W= e have dabbled with "network-wide"

configuration a couple times, only to drop the issue= .  IMO the models at this level

describe the network, not the devices.  There i= s some glue that tells the controller what devices are

available, and how to talk to them, but the goal is = to handle the device level details

as part of the controller data model implementation.=  

 

<Eric> We have a= YANG model for Cloud Policer and DDoS Thresholding which exposes the inter= play of domain and device view.   I will strive to get it posted = as a new draft before Oct 27th.  (IETF 91 cut-off date.)

 

Eric=

 

 

 

 

Eric Voit

Principal Engineer - CSG

 

--_000_EF64FF31F4C4384DBCE5D513A791C2B120A5A84Cxmbalnx11ciscoc_-- --_004_EF64FF31F4C4384DBCE5D513A791C2B120A5A84Cxmbalnx11ciscoc_ Content-Type: image/png; name="image003.png" Content-Description: image003.png Content-Disposition: inline; filename="image003.png"; size=148588; creation-date="Thu, 30 Oct 2014 19:16:53 GMT"; modification-date="Thu, 30 Oct 2014 19:16:53 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAegAAAFdCAIAAABHNWmdAAAAAXNSR0IArs4c6QAA/8pJREFUeF7s vQe4bMtR3zuzJ+yZnc4+59ykhBCIKDBJJhgEEhkJDELCNjkasJ8fGPSBMfb3MNHIGGwM5olgHg8e JtkmGwyYLARISAIFJCEhCaV77wk7Tw7v969aq6fXmrB6S+gA9lnaOnfvmV7d1VXV1dVV1VX13/3d 3200GvP5vHb3uYuBuxi4i4G7GFiFgTspIRHI9Xp9Op0yaLPZ5N/xeNxut/mcX/jzwQcfrD/vec+7 //77d3Z27iRkd3njLgbuYuAuBu5iYB0GENwukP0XHn7hz62trX6//9M//dP13/u933vHd3zHw8PD 2Wx2F493MXAXA3cxcBcDf00w4MI6PIhvBPfJycn/8//8P40v/MIvRGqjh9/VuP+aUOuvORic3eAe WCre6TnE/U3Z+IF8Gf63Bed0yPTp0zUjV4v8k78pOHlbpn/33bcfBiaTCSyEzYR/nZdgtl6v99rX vnbr7Tfq3Z7/pmAg3tj53f9cuZHDPX/6p3/653/+52984xuRTT5BGOt1r3vdX6KQChLwLx2BTO30 9PShhx6C9VkVb3v/3iE4+bM/+7PRaOS7wq1bt17xilfwCZhJGSLg338JJCi9e1e1SkHm/zJtWF+v f/3rX/nKV/7Jn/zJ7//+7/Pv+fk53MUEYd27gvt/GUK/NRNBfW61WsiXIDvgDP7E57G/v1+SFLRB Nn3P93zPl37pl7785S/nXR+Sz3FxowiUTnbpAPEiZz6e7e1t4OHfYOOLO+Grt1F40cNrXvOaz/mc z/md3/kdXwNv40Mnt2/f/q7v+q4v+IIvYJmBE9bbq1/96mc/+9lf+ZVfiStp5SgumpmvY489D4R3 u13A4xc6YWUuH5OdWG81kt/Gmd59/Q5jgGX4Du/wDo9//OPvueceXxoeReIuyszGfXBw8DYuiTs8 q7vDve0YgBV+4Rd+4fj4+M1vfvPXfu3Xwig/+ZM/+Ru/8RsopEjt933f933Ws56FOHZh4ec1fkGy /J//5//5D/7BP/jbf/tvu45JAxiLlkHphrdcH+ctd467kPJPaIY4c7nvYui5z33uD/3QDwEJv7/X e70X5rvHPe5xdOic6udExkXvQFP+zM/8TPwziDYfxfnYJR2/uxfexy2hiAa7u7s//MM/TGPkLPqL j+5mDT50Td8Bc+MPPS/j2dVqmvkxlt87nc5nfdZnfc3XfA3LjH74E+DZHv7f//f/dXjiTtxMyf73 kR/5kR/+4R/On9/0Td/0ru/6rv/lv/wXogVwOIF/1up//s//mWkGNNIJ+Pmpn/opPvmwD/uwd3/3 d/9LOTG87Vx0t4e3EwZgjLe85S0w0sXFBUuVhygSdnc+YbH8JSgdbye473b79sYAIuAv/uIvEAe/ /du/7VLvTW9606Mf/ej/7//7//6P/+P/QER+3/d9397e3ktf+tLf+q3fQrgjpl20IfJ4y9VG2IhD 3M///M8HqY2Mfvjhh5///OcTsMRbdMs28MIXvvBFL3oRLdFPkWWYF5DCPP/jf/wPZN9gMKDbn/iJ n0BRfad3eqcv+qIvQirR8o/+6I9e9apXMQSvoCnjkwGSX/7lX4ahAezo6OhlL3sZ8g5Jx5+gC8H3 K7/yKy94wQsAoKSZ8icL4CUveQmyj04w9QAnnwyHQ4ZguwKMmzdv8iETp8Nf+qVfovGy/Yd+gJb+ GYjRARLIgTY+DSDuz87O2CRWascsSHoADLZJcEsbpslA991338/+7M/+63/9r3/wB3/w27/925nd jRs3QCPhA4DEKAzBZEEaMN/Vu9/eq+OvvH/nNFiL5XP9+nU43MMEpW6jOvyVw3cXgL8qDEB+BGgw TyMa2NU5nXH8er/3ez/UaiQ4p36O/IQfoX2/+MUvdic2yi9SyX3cyLj/+B//4z//5/8c9dCdckjV //v//r//gz0/8iM/gvqJvP6BH/iB7/3e7/2xH/sxOuETZPpHfdRHff/3f//P/MzPYLVAJD3mMY9h dP59l3d5l6tXryLI/ut//a+8/i3f8i3oyAhu+kT0s9OgxiLpQBq7xXOe85z/+T//J/0wKJL9G7/x GxHB3/Ed3/Ev/sW/8NMAL7o31ZVo9gY+xwYNMK5cA9jXf/3X/7f/9t++/Mu/HMCY4D/5J/+E8wQt 0WtcoY474U/kKSP++I//OBNnA+BbBkKJji1ODAdug64dIOEXxxti+lGPehTj0pLoALZM1ue1a9fY OHke8YhHsDH8X//X/4UQBwm/+qu/ylt06C5Qn9pfFdvcHfeOYcDPWyhJMDwrETnOn64i3BXcd4wK f+0GQtSi2/6rf/WvvvVbv9V13itXriCJsF+j1vH5N3zDN3zbt33b133d13Guf+Yzn4nYdbMJyiAa pVvDkbNYeJ/0pCe5corgQ4mmDeIGyfspn/IpfIj++IEf+IFf9VVfxZaANZxPkE0f8REfgeBDLmMb QVNGgD71qU/9mI/5mH/0j/4RMpR+MDv8/b//9z/v8z4PQwpjIY6/4iu+gn4A4xnPeAabATL6Mz7j MzDy0Cf+UkQn+u/f+lt/i+HYSFza4jZkOkhqQGJjwCjx0R/90U972tMQ8cyXXYczATP97u/+brDB 3IGNbQPZ/aM/+qNIf3pAwcFBxMOsXW6ynNh1eAvhi0HDFxI7Wck44/oRHbqyz75CJ44316/ZEVGl 0es5wXAE/vVf//UP/uAPfsITngAePvdzP5fp0AP2FrDx/u///rwC0tjDmNo7v/M7r7Th/LXjsLsA vQ0YgJ0eeOABiM6+jpGEf12Ou4nsruB+G1D7N/xVZAGSGnGGsHCTMXorJoJ//+//Paf4937v98YI i3zEnMpE3cTGLwipRz7ykfzpnjc64RPEn6u0CCm6QrLwLw0wlKMe8i3KMtIf7R6dmpZIUuQywg41 k24R6NiIkUqo1Z/2aZ+GIAYM5DKaPhsA4RkuMVE9YF9eZ1DEJVoqcCL6MYijqzILLNcIR/YhlGgA AEg0VrYEV+qdXMhfNGu31yNGMTswU77FrPyGN7yBBgDDBBG1IAfBjVUEwAAeaw/bCcvpv//3/44y zv6BUsxbLpqR+xxm3ZTvZg02ABr7hTf8lmjobA9Em7hxnD2GgwsbHpYfGtx7773v9m7vhg0H5RqY 2WA+/dM//eM//uMZC0n9B3/wB75iEffgDcBKdvO/4Zx4F/wVGIDnw4GYleLc6Me1u4L7f3eOcb+f 7+H8An/g+sO0/Z3f+Z3/7J/9Mz5EBf7FX/xFzBFISdcfaYa0RcQgqlAVEXzokohU/5cGCBcsIRhn sR1jyUV6IoCwvXz+538+6jMaBG3cNIzAci8iAKByIgTR3zGvYztGcMOpaL5PfOIT3XPuWuof//Ef YxdmLKTkh3zIhyDd8GR+6qd+KmBwaKDbL/7iL8Z356cBjONo38zl6U9/Og0ceDpxe4XvW4yL7QWp ylywXThswIPAdd8jQhy7M6cKVHU2IWQ9EpzzB7rwYx/7WOS7d8v2hghm4vTs3ktWHeZpAOZbNpV/ +S//JScMTgzsZ3Tr2hO7FHvYz/3czzE6ew+/AzOj8DpbHXvGl33Zl4E3TsrMjm4dV3el9v8O69aP tr7Bwy1oP+7bcJ0ju4DD6vrfARd357gBA+znSBk4AWsDLOIHfwQulm4ENzL9Ez/xE1EM4RsaoG9i TECCI2L+7b/9t6jquAQ52aE2ohQjhvCz/eZv/qaLVwQcOiOKJKYJtGNkHJKXNk9+8pORYjAlmjjy 6AM+4AP4EzZFawYMGmNs4ReAQcDxFXKWfrBO0Bh7Ai2BDUs3GjSSEW5GdLLr0JKu3ud93sfFt4e1 +MSZIwIRYY19hk7oAYH4a7/2a8hirDrov2jKCF++RYgHz2TcievUaPHM7j3e4z3oisgQumIbYzPj Q8wdwMkrLDks+OxeNGDc0Ilr+qDrkz/5k13oY+cBS0wEMNhCOGoAJG9hdOLMwZaJZYYJrowsvMvS /6tiAHK7dQ7PJAzM72g2HlUin7Zfeb8bDvi/KvkvNS+3J7j91IUdUhVR5Soq4sl1c/+QTzy2z60B /IKq6CYX9we6Vuv6Iz37J96Jxzu7Fuzy1N3l/ieCOHa+8TvMyuf04BoG47rE9xf90EDnAVT34K3U TOM58i5/hpA7z+DD6GGmy9iLX3Gx67OgHz/JMq7rRADjpqRlSPicb4Ovye1OIXCQThxRPjv/c910 LkXfu43/BmEgOJM8tgQRzWER5sT5gc50V3D/DSLlnQbVT/2lUVd+uAGyy7a/05OMxvsbBOpfIZbu Dn3HMOAKBHu2m0qI+OKMiAkOx89d5+Qdo8LfvIFWxpxdNhDtsu3/CtH0NwjUv0Is3R36zmAAbkS5 xomCxo2w5tCJEOfDLLPCnQHi7ih3MXAXA3cxcBcD6RhwXzQhqtwL48En5PZArCWKLUnv6G1pibmU m3lbrTZ2yreln7vv3sXAXQzcxcD/DhjAO0JEE2FIBAjg8SbEFs8kE3ef+Z0Qo0jtrUbz+A2vf/B5 vzs7Pb0ru/93YLu7c7yLgbsYeFswgMZNeCjxV9xjIB7Us7C5w1/xpm9L15vezQOw+G+9Vt+ajM9e +crn/sqvvOGXfnlrO8s39PYa+m6/dzFwFwN3MfA3HANIZwKWePwyFxG3RJHyITFI1aYSj1vyKCvw 4Ck3PZaLh989FCxGES1p0GrzP/3oPaK4Brd//4XP/aEf/IE//pM/qb3s1cR/hVfmxDvVkypezglR I6KsltaYlond0nIrrU9ATWvJ7C4BKvNKnNSluk2GVqCmIVbEaiThKsNAIgmSQU1HbMYtafTS9BNB NSZMlAlC12Uom9ptGrSXxkDavNQtSRsT5/V2WN3CahoG0rlFLetasykkuJQgSulwZRsEKT5JjxP1 e178wr/cGKi4gINQ5i4A1ytIFsEVAKzjpPjhhjHpTrhGwQ7AfVxy8SC+yejm9zU8ixvZhZ74oR/2 HT/wPa95w8s+4L2e2Gx2fuEX/sP/+MWfnp+Mxq+5eM9HPmHvg95lNrY09lu15lFza7g125lVcAJ6 +7S+/eb29CAhOf1WbftGc2uyNe1U1WNr1Lbf3GqeNidXppUANE4b7duNyUEVqDavzuvas+5s3qxi hXqtAWmmjWnT56WdbvWqsMC89sP12U69msO2aq1bzcb51nSvCtqtWvumMDDdmXI42vQA6sVW+42t yfUqXBkG2m9p1xrzWasKA/DA6VbrRn1yNUEagNgH2zOOjJsRC7dM6p0b7XqvnoSBh1pbo9p0pwqA em1rVN9+U3tydQ0GQGDAISQ4V2qXWcNql9gXayhb3xpOW0fNalDpAo59A76i+Wy7CrEkKrjRbpxt Tfer6AUJHm6qZSVvM41ZvfP69vTKLIkJb4JYOLaKCUHstN6+0Z7uVa1umPB8a/uoVZvVWF8Va7Zh y7Azm6cw4RGyqMG8qrekeq39Juu2anVLaNXICDYD6phaziPy/G1ccAT/8T2KNuYRbtu4jRsZi+Vk Uxw36jbCmttcZE7gdhk+Te4Tc9uNzDjcGfOkPFyl49obCYBoKbHSbtP+U5/+9C/7p1/z33/xV+9/ xMGP/+gPD8eT46O3vOa3nzv5i9O/9RlP77Q6W/dQm3gG1GyendftzEa14bteaHZLfJ1NzP7TGDU7 f9buvWdfe+NG7G4167d/e773wHb7XViOdSlTIscCdfUtdSHx0pyfP5eqAbX6e/fmE19ci+IvC7Qi TrfmW2/pjB7aar0/LTcNTy91BNbzdraeMJrv0ZSxsqGt/CesbxLa/9mqdW90aqPa+T3nAJlREjo3 G1sNq4Y1mwOtOpAwqnV/cdr7+Nasu3Yp+hzqjVr9z7q1SW32Hj3+9ae00K2dBEHrj3e2prXhew94 iyfcGAxMpfMWELC8b7ZnL2vOP7I3566MbTHFXNOGUsMtPL3zRzvDR02m94408FqCcUCrTf+sOXlt o/NxQyHWjGvrHhBb/+Pd+jtPZjtjG97/v5haRtl6bXZRH7+ss31vrf7OGygrbNFn7eU7SO3GO/bn G0WcZnzRrL2sXf/g3nya8UoBsYZik971WrO285Lu+Np4cG3glAUHrKmtZqPeqENWhY07H1IJ7qFZ 9w07Zx/Ug8Rr524Yp9utP+zO32E6u29YMym3LL8zyk7r3Zd0R83a7H37WgX2xJ1nzfisWWu/cmfU r9XfL6OsyFXsFx7QbSA+HW4NfmZ7+1P6dXaOVVIuX7NSL3ZfuzPt1IaP6NVm9u76udV6zdaft6fv 1Xd5JlCtub+jmYsJsbrOh29oN241m4+Y1e4fzBEa3iafmo8O/ll29eZ89tyd2ntM6le4jbV2cLVv 1Kevbs2Omu0P7MOEhR5t5Ew0OHVrtZ3/3u1/yHB6BbR6LYysd1/U/Dubzvkfy3vSPxsNBrtX78U4 nX8ZoDUg18DlGjc5yBDfLEn+5QYyF5gxnvyn//SfKi7gYBshAQUJ2wj55h0S3HD7mZQ9KN1EqHzS J30Sfs+/9/f+HjnYguDm2vSXffmXP+Gx7/+yP/izp3/ax3/1s7/irH/RftPpQ89/9e0/u7jn6jvX Tpsy03CnbDrpjjoX9V673+rWupKNxCly50OrcUtCnf9yI4+cPM1ZvV3rjXsnWyeHzYNmp9W91aYx 1Fmata6ajbenF1vn8+3Z9lZ3cj5t7jTa5+0a6fvHrBj1P+xcbG1vTab1EQi+XpugmL9lvrO1XR9P 64PZTmd/MhBOGZ2f6dZ0LP0NjYzEReOto8beaKcxxj2wihfm9fHO9Kx23npUY/pmQOjAB+15sz6F NbY4NLBUx6fAMpu2Z+POZLQ7mtRGj3zio5uPo+vh7LA2v5h2Htq58ccPHz10u3PavbJ1cDHrtfdQ yMf9SW/cHT8wPOyOtlce7QF62BqPrk5Hp6Pm9cZsXGudknRjMXq2VmvTGeDb7EbD8Xh/NGwOt6Zb rSvN+lHt8ORAy2yrNmvYDDtbvf6wvdOeDqbD3fG0OWwcNSjYMplMMZl1WtuT08nWjAXFvrLF3I/v Pa+P6u1x86LR2z3rys6GKs/caTBDsZLKJoWR0bfQWWbzvdr52dloOty7d685bLbOuBspmbzMz8zu tD2+2D/annZQeEZb4+6k2xiA1QZ91jWl6aRzXm81uOA5as5qh/VRbdy4sbXb2p71R1ChWe/Oxls6 6dvoo9movrs1QXG4dz7oD7rDnZ2LbYG3ShgC0Hh3cto4697fHr16trMHmaftRrsOUzE6QniMyjaH suPODET198dng5N3+qh3azy+PW5Meq1Rc1DbfXn39uvffPrms73B3l5zp98assWMp6Px3qhxsHX1 jVc0i5VczZbRHsyu1oa3h9uPaY9vTHbGe2ip2egAIInBVsA+z64JYqfDi9H4njGIbTdatV3OH629 0z2zcoiyNZiiNh9OJ61Oe9Qbcooa9wbb/e3uXnfUH+3sd+r9+nw4gysEzqw+Ohz0WhfNaYvdfXwx 2qnt0oMmLsVIYrI+kVqbmd2a09m2tqbbs9tbjfr+9n5zsrV96nm+ligLKzfmF83B2f7Z/mhfbLI1 6ww7WyM0F4i7xSgzjiSdQX2rOZrMJoTDXalxS7dzhCRoTc+G3XanNm7rCCCjH/o1Gd6HrXtbQ1IN P6bef6h/pXalddb0nXZZYvDKeH98PkcwNedvaewd7Ex702a9zaLfmmnNTpqTC/iKefpTr+/VducX 2obR5Yej8ay+Q/aZGXkN2pNxZzxpD6++w+Hu++02W8zq+GRyduX67sw2mXkDAVDrn19w7bfR3Z7v tteZ6OicrGf8S3ofTCVceefuO0o3GWxIy14huJGwvIDgJmsEAJOKkwxnhIWTAwgF/hM+4RPIVkEy NgqpuOBG0CO4v/u7vvtzPvWLbr769C/e8qqv/o6vPL04PTg/uPHC1/3Oj/9O41Zrfru53Wu923Cv 1hsCyu033tzr7Hfa27PBpDGj5AnIkBUN7mO5T7fmk+Z4Mh/NW7NGt3Hz1s2rj7zSOx3cc/6YbUhl NimfuWPV3q1Nr18Md24N+8NWY5tXx+eT3fbu1rTVALsIJKz+o6PW/vak2zyvT2b11gT9pza+2t6Z 3j6fnPcO9x4YjVrwD6NPt8hbPm7sYOyv9Ub9wbgPTg5OH2ghOtcIl/FB70bzjTv1zmA8vrZ3dTaY TwZsPa3mrLnFBGdbr7s+GrQmo+a43+qfb59Pr8w/4rOfsvfh19C70X0ktW7W3vzDb3rpC18yv127 vnP94vRs73B73B2d1Y5AyXu97h3uO74Kc2uzj+YuyTjfOu+c1B5JxP5JGyHVY6Pe5d9GNjrbIXwz qbFrGm6nW8M6U2vUj05v13bqe1d2pjdHVy+u6JBSr023UNRq9U7r+Pzs2n33TurzwXA4GfRbO7W9 7pWz2yfw9EH3YHzWb7E3gFaWV2f80PYRZ4W9vf1br3n4/kc+wF7TmNaac+YuxYUtWOqJ5Mts0hgh 6ufbNXZMlLdRfTg7b+733wE2EBlde4mJO9kaPvbkdW9+9ZWrhzvt3fPbFwedK9C3MWs3Z2zJ8Mx4 Nr3VOtiFehdsEY3twRgemF9tdPo3j1rjRmf7Kvmj5qQwYePcGg9rw72ruxfjM8Y57h3ds3/v9sPX AHUlZflwer33ltHrDjvXLvq9+68+cHHrokGmLKS3+LbBZjdi12xNztujk27/Rves8didv/MPP7Lz fl2NVJvvIaX/aH77Z179qj96BRr+ldY+dyuae7N+42K43Tuo7T3yzx7ZQYkocnWmQs5rJzu3th6Y Ht0+utK82jvvXd2/NroYI0kRGOxFpgtOwKoo25hN6oM2HD4dH53d7l7vbLUbzRu1q70DOgejKlnY 2BptzQeT8eG918ESIcLDwQnyutvaPXr41l53vwl/DCaGWAiHfeJ2v3vR7XQ5lDQnTZDcu3XWQA9h dFt5W9Muh7JZfSLcwtvDi/37928f3UZt6R50pm/ZumfyCNe6Xc0M3AvjTGuTwSOP3/Cm1z/i0Y+c 9qcT+La5gx7A1GBdyePJ2bzZa+7v9AAK09NWazgZdqnRMW+dP3xzv7Vbn2Pj4DhGNUaNPpj0rz1w 9dbZTeTjUe/WY3bfaetGl1ksC26dY7HmPHDy8PEbdlr7zOTK/n39W6fNGWTFhglu6/3tya0rF/wS hP5R75ipIkbx8J1d9I73rl50sHeyrgf99vlou/+BH/vEJ3zie9Yo74H+vj8bzy+y07wp6AhiHSG2 21udLGnlsppCz8STEFjiBZUQO6Rg4+I7kpa0aJsEN29iDCGdEJmCya9G5h3yWKK0s5F+0Ad9EJo4 yXE86zEpm2PB/U3f/E0/97M/93u/9Ic/8H3f/4P/7fvPL863Oluv/s1XT18/e7/Pel+JJztM+jm9 9kL281rtA9FnckNBaRLZYQmVo1Z7Qa32YRbEuO6A4e+Cjf9Rqz2yVntPlLBcgSu9Ig7CClirkcse cflJtQywZU3aWwLqa2q1v6jVPtqIseHxxj9bq304XBAOe9EL3qF2G4Pt9fPadr32zsUe/7hWI1cd Ri1v47Z65vLb1m1ntbqfdUEzInfAFc8TDdp16KJzWv6S9f8UA9vpEj8BAL5l+n9Yq316rUZK99Bs JWLp9hcoRFarvUMO/DqMgfBXGW6ftp4H/F1nGBD7d0ibHdtHVgF8Wqv9Tq12rVZ7klF2OX4qkABu eS7pXA3aKp9I7di6/ZQI1JXTp3NGfPms9vit2mEEHv2/vFZ7XJEZaPlwrfbnRtkVtdLyxtJ8jfS/ WKs9gaTm9udKyjrJoDurANnxUTX2jRWrJlAWDPy+DQ0Ajquw6JY5AdKjxT3TINkMAP3AxthpH7+R XRmClrdrtefVak8tkmAZtzDAKw1X4JB8w8xxJWV9yfjq/pBa7d4EAF4qhan2kbkciNmbKR8VGR42 ALH0j+gAJF9izp/Ac16bd2r1+4S72fFkawdTVIFFucbe7w/qbHnLB4C8IfKdfR0tGamNi5IMbtg8 ELZozNg/Nglu1Oc//MM/JAsVGwu+RzJ8kuwNXRu79lOe8hT6InsZHZFz2fMvC/9bW9ypJyMamTxf 9sqXPnjzwQ95PxZZrdVs/elLXnn05pOnfDLLqPAMsawhPWR2r3iY4/lxbT9eBuvf6J/Ump1aKyHp IToBUZGW57niGY1qg17tIKElHZ3cqu1dqzU2bzA2oPJ8jiednQQU0PqV89q7rjeMRTPon2teHbk3 Kp7+cW00q11BxlU92F4ubtf2lZe7+rk4qXX3COGvbol1dXRa20vr9uhYJKjsFW65dbO2u1PrJmDg 4oyzQC2FAuyJ57dqV65XT0ot3jSp7ddrB5XAauXPj2t1Jfeufs5u17oHcWTW2lcAlYPrPtpD1TM6 x8xU6ybwNojtv7G2o+y81U8PJmzWuoj4qkeIPaldSQCVXGTHp7XDK0iVqk4pH3NTy9APBZsflvb4 oraPiE94zo4udq/ucHivbDucKD/adrPAheQLxke4XmirV/RmvIlo3JglUJeRtGQHxNKNikyC+Gob d8gN7/nJPAic3wWNRRSWUqnJ+9JsemIU/Guj8YijVq8z/JOXveQNr/6Lz3vmZ7uriiO3XA21+hmu mXl9X+vbnA8LTGSbPqc/PsNChDfzaF67xolF2cSxcK/WjnRVdDx7eDDGsnkAbc2vYT27FqSHLiYz lTYHxDcORs124/4tGf/MCcgjk4LvsDIaWjo6kr+dT2cXs+n9TXxJE8wMbtrLjtUOt8E/xR5Qazw8 Qdueb2OZ4DjJpzZZ2nMqbDETc2DQA1aMMaVvZ8OtvS5ydktnTzyb2IvMbAoQagw8jINTYDy4edp+ xL7t1WW6+wF0VsPAyfF2foI9vVE/MMeKje7buyYZFH46ZcBbWHlJVN1il2EMjqYLH7z0NrrMtI35 sL51Mhnep9Mztjr5u+Rvw+qZnSI10qQ+FOT12q15Y3de7xAt6mNmj5m6c2TpOsF83gOx8/m9Mrew xtaGmgm308ZbZo17Gngo6lPzCBlyhSt1qZ6nkxmWC9nS39QfHO5uXzG3mAFAG6OswFT8H0ylFbLV uI27oza7aiX9xAPmjFo46DLi0ntjWGscTWr3yqKvaxA+qoxUovt8YGZemdAJe0F1e8tD7e1Wc7dr rCTbszQ0NXHfOPTGGoWpeVobjLBD1R61OzWQSo9v1Jh+ZEKczW/O6vuNupxC2egOhSvk/hgO6/WH sRygbmIjZPXM4Jo4tgEOzqjC+xckwZgMDlU2mVHkHNxicxTjZUsG18wcLq1tjWfz2+P5NdYDpX80 arZkbbUIGT668drsGKDrtX16wqymA+NqYQUmL0b1k1rjgZa4BZYQdguz47MJABOKfDGb3RqM7t3r dNSf0zWirI3OfDWTev2No8nVRm0HI0oNU1++ZB1U5wj7D/bxM1bBhHnRFLpCGKeZE04m/Ph00zvu t3dbmKlZB+gmcy0SeJBR6Xgq5zOG1vlkPJ+cT04ak+Y97QeYlYY11hoO+mPcTBpm7ZaC+MSVSJJk kgK6nYN/Pc/7HcoOiInqje2HX/mqV9z4iwc/4cM/+rCzNzg973ANh7kioASSgsKRLPKIucQETfXM dCI5jbybmv+FfxVrUcMttuHa52TUH/ZPO9udaWcPTm9O8TKAIZdbtsa2apMpgk1FEnu9czJ7Nrc7 kGdEjlJxGK3cMcc/CqegnAtR6TOKukzG261tyIVFExtgf2u6O2FvWCw0STqst4RmkCOUdUl+U7hf 1jWclJImbVaqnDoSzLASX/YmF5PZuEHe0xbrBi9fcz5BHNWbQ4+CZwC4QzJ1OhoNRsPd7uFWfYVp bIQTRSZs2+SQaoyjgHuEhRZi5hjX/OUf1N45b7eQU8iqEdm3qU2OUjBnhq221V+36Ws6FuiJpCYa szE/n4wvtpogrNXkEzYvcW5LVlBNCXnGZz2tZvw6smW3mg0ILSOpCU3kwZCQOjr2kNnpzOu+T6az aaNJHlTQsOnkMRoNmRjawxjKYc61jrTJ2SQNYCq+0xW29Hnv4my3u0vEAPJsMm/hekaoenCCNUUS CCL0jAn5x+czHC0NSIYjbgsb8XxHpvb4gV4zVijbJ7KeyfJAPuTcyG4Dswc/ZKatVm3eJloPb/Lp McN3mxDLwnLY0RsthEQP6+Zsqog23h8jUifzyQhU1K4capsuDKrAjXF92mYzpp2RFpngUUeS/AsB JAXDdm78Bo02rtLa1nDYp7ftbZ2YGcZWTfYKEwfvxq64c1iHPShbb27r7gUz0fW8liYnyso90ZwO tqYoj+YO4njd2G51dm1I0C/bMSs5QK4AMeBmiMkYVubitGRhZmIuzS8ToIPBBS0b7Q4CknAEMZBU tLyxtlFQNG80W/Bqf3C+v0tAIjse6N9qIS60KWYPi2A8IikucntrNOihWGy38TmDLRyu+Drr2+5G WDwImPF0ony80Ah5L5nPtGvz8zpG/RHNhxL9i+d4cN5ttGmK+5HGM7Z7pzCek/YIfODVHc/HrOvR FK9H+9rWPbGi5RXsPBVwkdqLv2iAxk1ud27fhHCgOyq4gaXT2H7Bq1/0loff8PSPekYJ0PORrgPt tlSle/MD5+HnPNw9rGqo7/v94ya8lWCCuXn+ZnTow51HVHY7HA97w8HVvSuVLWlw++z4YO8Ahq1s fDEbsa4OiKxJePpnp509qdGVz0X/Asmz365G7MngJhvSPXvVGBjNh2e9N1/ffVzl6DQ46t/c3T5o 49Wtevojyq2f35Nmgrl1dnS4e4UtrpJbbpy88WD3sNvEel3xnPXOWax7CXYlhN3xxcn1/atVXer7 8/45m0GToI6qh2P6rdrsMTKaVj9H50c73d1tdsSq59bFWxr11uFOtQnmYnoyHfUOutU8wP5yevTn h1ffqWpwfX/WP2OD2dmuNlexcZ6cn15LsIRyWD++eOj6/gPNrWp03Ty9dWXvSmur2qoyxp866u/t JlgMa7U/qB29T+0QO3YlEgjFQnDtNAqrm5C+/qDflFK16fEU9nEQZxDc1WKlErLKBjrks3lxFeLI PC+KlVW8ris+ezU2bqOrn+DDT+g3/4TQnIM5kWp+zEG5oLeVP+zZMwINW9PtYofF3v0vvFyz/YOC /2hpQnnL7fn2IcFrenx0Bgo/MSQ6sV6bHxIClQFQ7LI0xea43Zp0V0w8f0tnR1f9p/NWn93cBw0j lsCw2No5PqGd/dnuGurkU7Kv92v718BAAazoDz/4Gr3Q+w7reN751slQ6CcbKz8oX60ftGcms8pk Lb+4PW9fqWNY8pNvPLVl+tauza4oNGjN4Nlw0iu3rs8OukStbXh8HmCAYr8zI0GBpiVIFN9LUNA1 gtHWjU5v/uMa3XB3MmpNoZsrw/Fb2e8KheZnZ9h6zAl6a4mrY8pqdO/5sHYIxlIoe7V2eOAcmxGq CEFE2d359m7m8g6UXeJa2VvmRNEezg91VtqMWF/d871uhtjNlJ00JvUCYldxlmN1e96EB5qbN7mc BNfnh60p5ikffd2ClThqjVq7o44wzNScfAFx/AllAnFntQ842u+MzPbjn8cc7r/7h7NaZ7jdGZV1 Mqn1Ooc5T6x93EKy/LVMEPgeiet+O5cfZZ1tv/CFL3jjG1/7qZ/yicSlA+9k5EZki+qf6/CdGbUc TH2T402z41Ckw/5wNmwTX8lvbdzka6IlOLNczGdn81ani/GBwFN1pJWeXVaWVQ5JaNF0MkBPJxZH l22euvaioDnb0gxpGpyT13aLkyo/GAnmWz1ZcuzwxHHZO1pQek7stgrCcqqkNxm8AiPIHqTTGh/4 C/w6UKLdGWaS7baZzBo6trlZnP9jiSXJgOJJMZih8w+Hjau0WSwbXdGJ+KwOQ0+2ZSphFlTv5XyY T82HxFaYXXIxC0pm2YdXZUyye7/bi7kLVX7H1bGBYYKwPZm4uQdC0BlWH06KHsNoTWSKHGd+BVlI ueIUuc4NTYr+spnJWoGiRSSacblM+Vg4thHW/L3yQD0fnctMLFNN0zx+ufU6NMeSIMoa+cAj1u6F 0cec5xmbGcbMFo/9ajoZTkB9q0uQ2ZHfMvGnZILEfIJBJLs7w2GaUPfsVoW1lnvBJmvcCwjn5yOM eq0O/wcMttoJ5gkDVQPIfoS9Z8Lw09kQokzbaHtaHTkyC5QF2m5t2pS5BG6Fr2SDyMxDDi3caXg0 3DplM7uqX10hiM45wP4RWy8u8Mi3MhmJW8ywA0hYw2TpzYEhzA/XloSS0Cu7QGsHU4nhyuaroVwP 9P7hBNM3vAGmljoOgtWPDG6DE1lUmjI/qJeMRYWmHFpQrSkJwwCD3ScbyRosEm84ZTGMWEVTKIs1 o7mNBf8kHjyirOBujDvESMr0olXDarOrRTmlNDGFvi+e0VkfVx6rFYBZ4ASXh+/8phL9yzyF9UX2 nVprrxUWKd8SK8K33U4Hw9QanJhkzE/W4U5cwVRCYQVM4CtF+7pOL/s5bPHKV7ySW/JPferT/HI8 xkq35tm4sjNuCJWQYd6cNn6NEJSa6XbNQ7ej8fx8gKhttHAEcoFpjrWXcXRFw3UsrJsZz1vxTa2C wuEj3kWMw6cYpPgXXyumc9sInWHFJgtxkEPEUMSKaPHK20NkaUE9ibO7GLBjeY0lZGmOSMb2qmt5 7vdhG9mCC21/o1LsuDdsXt3HKZBxrZarb8vZRmdc44Zj88/QbVEIRu1dfMhpams9kxeFHdQcswu7 qxlG3e1saFFm93g67kLJKOtVTVlgkdKg6eSC0dCHc9vKQtIt5kLmVUx9E9OY3gbDASN4VTDbiss1 egxae8m+XU6kE3eIYd05aohjkLi1nR2ZgqM9uPQ6Q2NT4n+yMJuNO2cBExZET5kn1h9IdnZ6ZmXe 8FWIu9w7lj1ygIg8WtlWlZihd7rcKF4gq0RZHZyhNkATqQwERcTSra2sfPLGlo5pp2yJrDGlDF1l yopzIpOc9gEV7xR98fXgmfQ4hWw6FioQm4EFvO0O7lzRWlgfYMRAvX6PtUJ6I3l5ltTMHNqcsrrI UpCkpdlN4ExzLxO8YcmWpMqso6wuEcjNIBqwd5jTWU4lG8zvDNe5h7DgnHlNhg7YlfVtWGKfW+z2 tovwYU5W3YXwOA7vga+IFeEXTwMVM2T4nTY4IQkgcVM4haQlRmxFYx/PnJN3QHAjl1/xilc8+OCD hAmWAPXy1SnVipk5OxV7zMqplj6c3Dqtd9qN3epAJBAEeJ4WYPMDqDyJAFArlnNMaeWv7J8+/Upr 1fj6fvzQSfPefVOFKh6oDmKJ/axqWEOLBwDPhLD5YTeiW7wlVQ31PYilT6/xuPnB4Dc87x3cm2Re 5AIB1xA2uON9LLgFALi8kMJaLG9eScEAa5tuEzHQPzlrdbZx+FUhoMaZi3Bd5lXZkgbciYOs69Z8 3APzAlEpGGB0eIB430oAQOzxQzeuPkDc3KpTUfF9bpqwBKBCZbeMjkhiyVS2JGKNJcN62eDZC51A rMSW48FwPBrtHGAJrH4QRBCrtFusfE1hf/N5aXU7uTfwMD2z0EAIk3WtEeZkREjpgrt6/VdPIq1F STWLX3IdvPLR9r3RJBT3oJZpjdcZkpbhuRQAb6duq9dKDnc6tOktXSBWUsobLOc8Wfeinagu0W0K DK6jpbQEqpQVmDjrt7pZIqiXIkE6ZS/V0pTppIleqttEDKT3mQTiYr1covmlYEicV0l8sTfff//9 qAjIawQ9W6CXLvNmsnHfAY2bXfeVr3wld3Oe+tSn+nr2kt7hQBEyx65EXkCTzjIe0rRZ5cQScjYg qIQi3rKjwmV2rnRTiVgusl3Qp5sU4iVRMpV4ALxMJaORlw6KiRFbowL8Xt3cn1iE8WJsWuFdD5B3 9UFGT2w7FvvophL9qz9leuVEPT7vt65hKlnsuCuB0XmWGF6LqS+hdLm9T9xn4b/Er5SABwlxEXed KyNaxJ3HiA0dMotYWdD5W5ZIouqnre22ThLR1JaZQZeVplP0DgdyM7QOapjOysZ+/ESD41vUotIa K7EZ3wIA9HIddtlEpqi3HGjGPTs55eiNTcExakRdzMlR57uLmUqmaFUxACVKyfThlgorAL98mCvt lIGaK8la6px3ncnDKKXZZaYSrJWzOZ6WNumdowswbsqOTSXeP306X61cIwuusFuCtHE5sCzpYmi9 282UDbogim0oQRCzU0xZX1lcgpNuK7tWMbxaNvCFD8w7QY9GC/bVTfuS6ukfOmX9ZmLJVMKZia82 hwNmAtpYB66jvWJ77ebknTOVMOrzn/98bNzPeMYzfJIuuCVC7U+k4Qatx0lFM7AACoL4Xl7Y+gSr 1GA8Oe1td7Znex1FbIJAu8JYsHHby4505wOXnvy5LIwYV7HDBDkbAA6MN3PxVAKerrA/uNx0Esbt izZusayfhnw1wv1Yvc1Bk9m4yaGjZTPDozsaXvS3DnfkSMyfkl7pkPjydkovC+LSwmB0n7uLtpJE KDEl3QKq9+m4WmHjNuSALgcgJpMEd6Sseci5SGBrRq5e9zquecAqctMtML7Cl+cSXnXIhdJcnS/b bXMKKmeImcvcZhKeZRO5y+6A1Rg5snFjeA1WX+y2F+cED8CH5mng0pk2qNC5s4eLbN+QsFTE01lH WRoz/dJcwlKK4XcdzTHgUiZ8G9aUcyZjORM6Vn2JFaSboqZ1ZUesZTZusvGHY5KuktnSi9mS3wMA /F7aBQtcYek76Bk1M0i9uEGA1kH1/cD3GG9WZrOcsghu5xY4Zy1l0eu4dmDOFnYju4Kg0ILFbMBJ UZ9AeiIHAMDFtwvWIBB8/2PuTlk+L23JmPt8l0qxYsVg0+0dFdzMhAyCGIae/OQnl5ZkunkR1GCx SrGCMcToxgnhoyk2bg+GT7EFIzJ4UuyAAJBuBYOlIHCijbv3xhvdR17DKbJeuGXfwLL8ltItJPA1 U9kncNI4EQOXMi8q9SW3mBMeEAsAKc4DAGBtpBhYwRUdpqwiEJVoimUqZ7dub+/stBNufINYYCBl WwIC5DxItNsiDeHtFNu921JTWrIMz28e7ac5JNIBSEcsAhEmBNREGzeMncItw4veeDjau3aYSAKI tUHXDJ2sdCCBbaaQAlUJmCC475yNGwiWT0C+D2/Yiku7rmuFKZg1h3Zay0rDSz5eeof+Runoug7s ZbVxQ0tDYzoCkpq6Xpwyu5Q2AbhlZX/TvBJntaRbbcZq4tq4LAmSCGCNEjGWDoD3mdItbVZaVFYC n9hnNrqF7KQgIR0AeksRxAGlKUIzHVcpcynJordldadjOwyKrI9HvEOCGyz7PrmMILdUpCDOT9+J BFNEWsr9Qhu4ZA1YB0zq0Pn7l21fiQTvMHFaNE4EIBzoKgG4VAM/P6a8kgind5XIAz59tzD+JT6X AtWIleROTmwWJpLS3tdLOgZS+lzMKG1eMg6lrW6nbCKlYjtP5SuXmVcSsXzExG5Xtkxcm96Mhy2N +gcx598h5yRDvvSlL+WM+WEf9mEQkgOsV05jVm6ocqvQOhrQgA1HM+CaAAHt8/nm8++8P6QmAfGz umFHagUSRZs9bmrXICyMnFwo2WgCgFZ5DQsHqQSMc78jcZkRS9ZGNxHi7pQfZ5XkKmkWCqjIjfiM 4uZC3XzIbdwtvKuAxxUk3d/Yqu+1lcskR5ZbqEtL2oF0wEocVmrPu3blgYs+mSF+g5bq0y8Ydpds 3J6AzNFI49j+AJT4XpVsO2N92UBlBnVnDiZprit1Nt1j9rUdFBY3MsZsE8spkUAXABbIWUmpwITL xCpRSqjTRSWKa6yIg4Ii2yTlyK/dQaHBEFSIuEIp/6WWxhrJ4GQqcd0yZV0W+yyWPSvLMtrCRjPe 3ny0pUNejzFQwhUR7HNbNQYovC0XsfMdc9KNFXP+h/kBJ9QPi2vZ21Fa7PIJ4ZnPEeu249DG11SQ mIBQUlpXUMqAW7cMQ3u5HllbI+7TmSNNzgCZ9xfgiWvJOl5I9OnuhxS9ZJlSfOIB2jwbYjq9mS83 fic3N/m4CeheJJlKjCrh5bAIg4eKfks6vNsK3YHDt+4T4MM/+ZM/wTn5KZ/yKQ5H8NdNQBk54QhE 36idCUf4hYYjAmMrtzu4Z3zrBBHQ2LEIEHjL7jf6dQn5vkOpoXq93+uR5otuN5CBr8TZln91e6fg +l8NTL3WP7toK8/6itsEsSTl9xFh1BQM6QrUbB041+S3Ky1+wj6ZzQe3jrbvvapbKhG6lgU3bSn/ wSLrFAMVso6Lgh63jPi1MuCa1TKdcleFDLRhxNKu4FLVcTIaUM+GeyIFI0xJcHnjKUVEhqMOIbT8 uYjLKC3t7E+qWRAZLZG0FAATj87KGvZJP9/ZIvhhPWs5ZQkkZ/ci/KPEA8uz0204DKz7u/F+kAmU ohamjHe3KRpCuabFVrTyAMIo3OCADXb2dksArKRs7/y8vd2JgzqWySqZpTSZusUqym5cXBlvT6bt aBWU564FaFw5nw1OzrqHB+ZoWUyoNLVsybCLozBWsZZjAN87Hons0tCSRh/4igtQ0zEtu1xZ3BCV KAC26rYMyVC5cFAH6R/Yy6RCbdLrT7hed0A+A2XWKk6neInNVjdyIPaOrmRWW92U7psvVrcxyaDf VwAC0mH9wYXOKYeA29x9YLz1mMc8hujAywluYXY6/d7v/V7kL2lhv+zLvowiwq9//etxEXz91389 xYJ9t2effPGLX/yd3/mdz3rWsyiaw12Vr/zKr2Rsr4wDBE960pNKMxwfc0+k1rxSHfmvrHe3z7fu SXLgTI6O4FcKsaxe/dGnk1tnbLWte6s9Y5S/mvYGretJtyT6D97avvdQVwGrnskZhf6mBPlVNZRM HLzpTZ1HPFI346ue8Qnp3Gutw2oMTC/wlQy691TPaw67HV207z+sGlzfDx+83by6R2a2ysZzovG4 j3At6QLO8C232vccKNCz6hm85VZnf6+2V52KaAITEtGzV30Fift1oxvH249ISsg9ecvDjb2dOjBU PTMKyB2dbT+QhIHRw0eN/d1GtxqxgxsnzV2KyVTjanrWV2BPArewWCYPP9y8//7lXW15lvPTPol6 6zvVJLgEYiezi4du7eIdbVcvrvHDx43DfQoAVVGgNjk7o+LZ9r1JCbnPbx3v0G3K6j4h/8a8dbXA A4S99Qa9kha/DKEH9vCgBFMgmHrBOFpdcFev/7BB4SCmpvuXfumXIqbpBZsLEpzqCmjvQS9gDJoR G04BeB7qCPuRBBrzOZcJl4Hz9BWVaPWtngSkKS3VONF7ovzNZBhOM8VKHUwCVQBYwbwUaJMaWUdS DVKxlR1qUwCAPJXJ9rJ+LE1F4qMzdRJe5WMYkeEk7ckD3Ktaz7DDUAywqpl9v0jJUdk85J+ubCmC mfKW9mxI+bBi1aT1qmQ1iS2TfSe2uFIfhcQluxlSMYBTLCQ2qAJElE3DQLbAqjr079sjKxOc8GgV LDXj5oJyjm983U0l3H3BSMK1c+wicY6BVBu3j/61X/u1HreEpH7mM59JhB/imD+f/exnh2LByPR/ 9s/+GUWECTJ/4hOf+M3f/M00uHHjxgte8AKoyAWc07NT0t1cJQG3GzFQHpGyGz0YStTbaA5JG401 3K7w6gCydt58MaHuhnW76k6mqgBQk6dDmG13Z7c/HLCjdVtt5zAZ2mSTIZVKhldlB6emapMyqdrn sAC0OaqH0xQmac7PZdFPXVNqLZiNmyhRndZzKpHRnbRNEfCWtF1WCGuhrFdxEkpGJzFCxtNK1qPC laQnCnfXSNoQitYrhp181TZrzwUvq3jxidvr1DYckPWCuzq949PuThcvgM6VAdwi8PIx0GVIO7WR 8yhnrlz9hcoAXkVhQRSPPLnoqQwSubTa291hH+RsYmmIZQHFq9aNQcvLRHt393aJllV+Ag5qirVX 2hQuz4jK1r0MZmYxk17TVEIicmbJL7KeUnqLR5mhjFVk7I0Ct/FNjIfRZmU1hC0Ni8ZjobY6dWoy 5QaxQKm8W0KJC+xaomxgM7PblhArbo/ZDDDFNkDY7VKBlCF2ikazMvANxR2vX4ZaU8rknmEAEhQM 4nZ7Aq02N55w1Gu12DipAQpgbWUFa8g/sZ6wOWKV5mkFW1Hdr9PhGgMTx+xwdHx07d77uCsBBUVZ wrQveoFpnbLwqhAIZXGSUzx5/Rqk/XiKhV1zU7UG0qm32p7ryh/VA1DmoYVAUO6jiAnXUWp5GTrr HR0fk16KYsGNK7vrNEyU4De96U1IUdYIqMO28ahHPYow0MuZShgNqzRGDxyM3/AN3/CEJzzhq7/6 q/nwRS960T/8h/8QoVwoFvzd3421hEqV1DZ7znOe42HCv//7v8+7n/qpn+q+0azABDagMzKd1zhR VprhkBeD2yc7913l7c1uAVktT4+xrjZ21uFFfAJUyKzejdu4IzrXr+RcK9yW+5ftlWzqo+lg3Lyy 4/kAI7qWOU2OqVsn7St7LHLj9UKDgszBBnXRR2hsHwT7ZklLM3+AsY2S5ty40b1+bymOO+4/Ewt4 sc57MpXsl28DluCh/YyqxpgX93d8lNIBKOq8rhxL573tawfLFt4SClg2YKC1193iWk1hJRb+UOf1 reHFGbkbdu+9392OG05gslrePAZXVGhYucAdWjohAdDxmx+6cu1avYvlWgmGtNV69xHpDBtbslYh vXeo5rGeUr6GsfKfnHevH+Ym12Jn9B6WN/cybtzg6kUjv5ApCCJsxjsExVdArDHhEn7yETLKgtjb Jy0MrNslxK5gM0AlyYUqInBUW0oNv4AFJuwNsDK3sd2vPX3mgFEI5/j29lWMRctiePGJB0ANjs+Q gHRbGRgJYkcn58LAGk1W5zd3n0xmxzduXr3/PrtVJ27xtVwinRG2Prp91qS2lIoqbKQsBTguzqfj YefwOtxiLtiYS4o273ptGK1ub7e8Bv3T6XmfTZbFFbuF+ufniEGWxoakQ2x1WCyQq8hrJCe67+Mf /3husVzOVAIMmFe+4iu+4t/9u3/Hyx/yIR/y7//9v/+iL/oi/uQyZIwSAPIsPJhQPPweiFHyuXFP 8TRa+hVBdBx+VM4Gf7Sq/2DI0SfrfrR7tps4TzybYmVjFdJhbClTjLX8o6FJRycrAdZSFRiTJmU/ 2qnL/StxnfRiDkg6fgryxc8yMHyrvKqmytk017d3DDD+YlAmGP+QX1PeU6W+baogvZTuIqKWgdHh wGp4rMRVqb3yATBpcyQargpUiBor5axEoKxum4ilKRNS4i1zJOSvFGihmdIZBb64xa4iaE6v9Wyg bnViWuq2gGo6gfoN9gyWn53XrMSU9x//CBgxobLZSn3eRKmclBkAy5Rl1uj7dGg/DKfE8LATM8Ld wqVEjbWKbSwxJKrpMmJXUNaT66/CwDLwyh9gfA4LreTS7BWrlGdLYANlM8IRbo0kWreswiiOc9zI TcST1lQVw6AaoyavbxZgU8+g15ZMTlkOuMuUNayqlp8mVUFZFCzjWEWUaK0V1mCZ2ZTTUQlH40HX UJbiQaXVLbTgWUWabU4Vx1aEzETY+lWdxz3ucXFKhsYXfuEX8l3K7TI6QvK+27u92yd8wie8+7u/ O31h7P7wD//wj/qojwqbIRzFYIh1/uVm0Yd+6If6XU/WL6kBH3roofd8T+quZzqRbUgKQrKSRRxR NxmNtLdiwRiNm51qnwzdjsZ90vs2WuU4gbJiaFFoyNjNUSUOqhYMLvIqUL0x+gt5ZaFN5eHAM4uy tDa3dLSRBpU71KSC3pzmxwGAZVUYsDKiwAL4JOY2Pq6ycvxthQCY9e2NslyMVqbWagBUuGvc2l5x OFim12g4hliViPVDExGU1awlfU3hm7LtVOGKBroaviYGybU052PpgdMJSV2RMpXd8qJwVdUyYy26 RRBXIZbG+G/kbUngAbMnUd6ter1wMMWXraCOhIMv3OI6QSUGdMccg2Q3CzFcx1mmXCvPsMvx6m6x kpEqNmEZzqg1VgMD5ZixMgfa4UWX/i20SSJhvdFfpgWphoVV4EKPAPvNghuYsfW94Q1vQGyiCnNh GG0YKzEhHi95yUtSbdwOvUcd+pUZj7z2MMP4nCJYLYOH/+LJClDDiSpBAf/gD/5gzI60752rxBws rmhNyUOlxBZfesiRn9hNOMlipROq0tqiM2kLxZzHluiBfUuv8AI2FQyWaPZGMEV+qwCd96wuvbhl VkUun4WVZVAbAaNE9UVI9LIUc8sJvvRVBLAlWmabpVrIFNMxCg/RqZYduDipBfClbqWoabK5CJhj XpeLxx5QtU3qkrzm5BK6stHxCckIoXgjsoEXRl9GL3q0wFMQ6xqU5hRRmWSuVFisK+8gF2Tmdf+z 4SSnlNEFTRbMewhzNndlzFLB5PxkqSTOSkid7dmW06PtmFpBXN3RmIg0di6VVELTMk5YnhSviw91 ASQ3X1jEulsMSq94tKgWYdRVqZlF+FrIv4T3zPx+FCpQqU0fHXw0+VNmV32CEkvlU8ZmTJJXo58h w8b2nTG29Gvow1qwrOBKA1LE1WJS9puPzqwdA1lx0bW48pVjcdzKo20Yz3aUVdwLMPh1hFkLfod/ 5NSJl+QWvKc1AgCMjh9Fnp41a4qRJRYMZkeYpAEYW4de1iw6mdLUoB756OjLZmZcsQx1lJPlOpuP sIOevFIgCGk5e61bthqDkgcW88+/khp5uEhmeFPJ2AKbyfhmty2MhqpbbcXMs+YqIgyixNd2jcBY MRpdSWz0iU5ia9VQGjz88MNYSzBRvOu7viuRHejNIarkcoJbDPRWPSzIl7/85ewexHEbHbOFCjlD rpIsfnPlIrRB4XBEf57PwdS/lYLbLLVn50d4GLa3F0U6CmRzEa6GAoCewUhh97bYhYL4MJnFo9OJ wb9ydHtJG8zZ+TkVLvwyS7YtrxTc1GkhPHw2pT6DdWuLuji6djjDGdxx++ihw6sUms/8h8syy1Q9 AYFDgl9JR10avSzj5MVSbjygtd1FM1jJ4uJF0kta2ugirqRz5Gs44w+AAAOMrgsyDoF3WxIfBu5g 1CPH8sHetZU8EAEsgqF9ePaJDAY7CpUnpdovMyJgQUWXcq+xHr3MM5hiB8Rxo5pn8c7B318QNIqo UVBsr9/fJxuUsY/+XZYshgOY4PTWQ+0OBReVBMZJKkj8NVfJLU0/j98rPtgHsegFOa5yHjNGdCO9 OmIVoHkpS8Gq0fPXNQiU5S0oa6JzreCma25joAPulvIjLiDJ2VKJNcnWcutg/7oJ5WiN5GvKCe0T 9KzTnlCzxNUxm5mYm170WN0HC1/XarVMy5CoVKsyXzhNGhcWUEe3AACu3N++VnAbbgejC1w9+7t5 Zd64K8Ea2Ez65un56e6OMaHtjza5PEzEKZU/nnhSSWByLgUqj84uXXEKr/gv4I3IPWS3rOEWkUHE B9Lv0jbuUr+X+tNVb7+M45q4P8KG8a+dKVQ02/6x/9vv/mt4XI3KXo2axa/ocCINUlbLrFtrWejZ O7emUplMiYvGWQGJg5qttyKQJYClb5sks/ENhpWT8jlmfdoyDpMuQhtwhlrB5ReVgl+PLvvSMZD9 Uxq9jF7HFdD66KuoEHCls4p1XMRVeG/xsaFLJqDF/L1vJ0OYYD6XrNv1oztw1q2E4gKGDG8lnlEL K/GVXTKMIFtmhsxvl5Mg66rEM86udkw0/dFhWOLYfH7S6zs7Hcvpamp+jokFY5tn1h9OLZ3drkTb Kq72NWDg6R8rbu9/lddL9Lp+lazK6VXGfIRq68tE3tIqiDjC2ZVeGywZO3KtXlPxBNVtceIBwhh4 xzyLywfIl/jqZUiHgbViPlxGnePKMbwBVxll7Uwc8VWBS53hbAj1JVBdaGSzyxd5oFRG2DrnEjxz PsGwjnLZs5Dvy+IUcU8yNbRs7NI8SO04xWBqHPelxPRyY7/6HOef0wnRi/dZa1dG1j1+vVRvmO6Z 3TZd3z7r0Hq2448dg+wX/z0bOj9reZZUwbABkvzIp5YbHw8NBFSrpGiQb2hvG3FWiNCnWQTVLixL 25YNkOKXCkKqRIAAYHR3tG9unU88u0O8eWqOH+/T8GhkjJ7sQ68zJ7V3+cmokNPCp5adwCqnpqFN dDo/lEYvoNoA8NPrZsoarkwdTmFCo+x6HsgQ40GQnsfVUeB9B4Rkv+QjKpLdgiw3LwHrJ18vVXxo o7qWWcGxNMij8DIgY8zmMIdVI5+MT8WJmHNsAXZ/i9g6rYJKunqDfHWvoGvoO5v+CsouM5stwwqy Zh1brU/nliAuYolRpkt+5z58vkTZ7BvS9XKUKbwOtkUa54q1D8IddZtLjkRdc+2Rfzk9IP/9hTtk KoES3KhE8/+4j/s4nS9mpD0YmX1TIgvKe8VFAbTq4CmXHE4GM0GosmyFjbs+GfZxoGCRp1v6U81J XT23fNx2xMXXjgAwfsIWLDPVYkHk1sAFJBItJgPNuGo2TCnV60wlvgsTYOeJATDYyBYc2biztZef xcwMJiL6Fo+VFEjdqiA/N66FRpN87JyYsANC8s7untWcNPotoct8JZlLwE4SqAe+kaxuj63O1S23 cbvSF3frkeD+uumNYrtM87StFA5bQGL7kO2xUl8w30rljGzc5mNf8KvWNpGzxsLSIxWDQYC/yZoV No0a8ftZSImNYopPwXIqPPvw1gHnaTVzbjdbd9ytMlOYXdt1KNmRHRW5JlQylcAnGAoUnYyFt0Vi kiaulIWNm1iP+VRW8BxX5xcXIiJJIJQ/u0WS9bFJ/cySYBqYlZtUTnIg3rbQyZWmEucHpoW1ym5K 52e1dbhS/nYr0Mp0PJbfT6KBZ2y/DBOE5lkUufELSNPVuai9CKeylKoMoDU1ne7uFpzJU1wlEZNr Tl4zxFJ4i7PX27gZZ9AfhKsStPcDVoDWPD4yf9lK1B8s7Wy/X8XYKkdvmEGsqFyt5PwKr1VGKeza OIKsTArYkoKcl6jN+FJUK7CZcgmItLr0oCHYnhRs5GyWnfOgLMZ6K3POtZGFiZy+VC6R4BVymq+3 cdPxq1/9avpzwyDGbsIB35pcJS4p3roHEP/wD//wNa95zed93uf55hO2Drdx63ZAVdfQjOs+ewkX iKHS8KGjZne7uY990wm96rGviJHku/2D/RBCa0xSeMcBlugcj1MyXNOYyPm9vV0Ex+ZpMQz2LnyP m9Jhm1ARrPN5/803Ow9c21xtwBv7/lyZYZmJglWWyp7ycbstqACy5u49mpUf8xyGts3KguGv7snm K2pO2rS4cD/uD/auX114eNZgDUiOT04AwHeLDY9sphcXXh4hQBu4LrzolFVtxgaJyCpuZjM6yzur ObmBr6x3uj29eYvoi21sIM6Fq/hQWjGuufEYyXVw5aACsSaLrZZmdTFPugIDgAFl1W2JrqYI5/qb FaChpi3RMu76Wf9Ao5Mbtw7uuR5fUVnXPL3opVv5UzKSe81J7OaFm4SrZgeTnIGrhMzdYGl61hv1 h517D32pbX6SksIbzr2ibOxCYyzWJnZjhMMS1IVheTHkifOcIvx5R2tOwiJ4tCih5gydGezMDCSV lGCV3CS06b8yrwW78cYXMC9utz1MO7NCrWxuncEBKvxh1kV/zBRbeALAMeQbIGCa5hLRtcDNDxBS +cVrca19MsuwQqC63Y4iRiuezAQcqL4RVDNbRpbnFXN3tNjjnFUFgJqFKi0VU3Ozpl1UW8Z86V0G rsBV/gIim00rJNLLKLsESma0DEbHzWxl39Kt/lPFiUwH66ZVVHH75uquHa9KzZZnT9uILtmMzb5c /ThZ5R53AFbOPef2gIC1gOav04AlY1p/9ePZNqrbGQa8blnlA2UBYEG4iDnjd31r12k6AQBr2ZR/ PoGyzgPV3dq4mXyLlozLX3u9YnugjawCeYJAegsv3CEbN+O5RXIZ0vSUwcyhVH9ow7y54peYZZsN PLFb4F/OnLkOhpDdtII4FlGQnomYyl0eelH5eJbtymY0oBndprR0NkppSRuvpZnSmD4Jakhp6d2m tGRoWibSSyk1kitWJ3ILQCpZShq6HNqUeV0KsZA1kQc8YioFABRyDFaJOVgUMZWG2HTKGreoXk8K tOnEwuqViIF0UI0HVncbS+GUiZTa3CEbN1ASx01a10/6pE/yyYSjrifarjhQ596VUKd187SJq5wc X7Q67YZliZQ1G3tZni8YwROScfiC4d8sYilHT6l/F0CyRlql2kpEMzvuqoYykptXrzxYlqM86zYK 23J7aFY206Tm+KxHyr1SBbwYHoecDr3oZVyldB3YtKTvMK+Vc/d3ffNP6ZPGnhXSAyLDo+mY4cUf YKVP+QPG487uruyQG/UQ4PRjsisjsc0tHsW/8nrNlQdq5utMWFmyhzZM3+tmuQofU9YiOMyMbqCg UF2cnam2EIqkFC67n7naWqLt0PNRbNjqGN03TjDApErBcMvEdUWHt5xey0smtiCFZbjOrKTZWUAq Zu7+xQXRTRyVs/BNm7J+otn5iHG3m9esC7jNGGCOdAsJaFmqrbOSafnQmdC143X8zxdNbNR9lTNt 7O7IFG+3KC3aKmfUogYCD4ST32Zp4BgoMSGmEmbBFFKK/jjkThcm4qaSS9ycrJRWmxtw/weL23u9 13sBgTN9aO80Xo4Q8OUXIHa4nQZMO3xb/oVJsjGMZ5IaBNNbJBb7vpjenFH8RtYb0SUf1C8ThXOW S6i42/Bt9eh5MWbXdBBbgMHv66D1sXQ+s0dZ+rbqmRvaQMDLwq1hIQvdDZYlLdl2Uw6+IoQlaB2l 8pw0GvImrX9Cs8Dc6+bu+HEeWve4+NtAWcu372Ey/ouZXu3aEFeVeFGXUdY/cls5ovL9IOYEXg/i TOS27TCQ1ckdz845yjnBjSqb+Cov9+F6mQuOAmV9XmF27By4UmXf4mDMnQw508wJmT0xrpzJN68C nwgtffqV0PqkfDfyF5fnHmga879/WMIV64hN2MKkRCBZbKCcLymjmMfTxLPzfkK08uYFzrfOrt6+ PHo+ZUeUEzqmbIlwYV784iTeMDpwb2+1agQAKTtbnS1R3ldzroafODbLAQiyCID9EmKYu88iSFtv HzdA7tM4NFsnOQHeq1PSvxOIf/nk0jcn32rZDZYJZ2GvWM7HnV4smJmn12mlWPDWznZzt1MJM34G MIIJvrLlpYoFc12VPuP9aV3/lyoW3H/Tzc4jrwNwJbRvj2LB7px8uxQL7vd3rx5WTooGSX4h64jL ZngmU9I5oFKwilJasoQy52QCrGe3j0lll1gsGBhSmNAxwLwqD6m0TK/Vu7Km7copIrrPbhwdJBcL TkQsgiyxFDhM6HkfU9TVdG7hatmsP27fcyWBsCJBioecrhYXcKJ+dY0riu1bOSJrHPJxaZEe5ALZ 3n70ox/N0vMLOHdI40bmYie5desWqU7i6lNQK3hLN22JtpfRwI9IvuuubW/fTS90F45LpRZBZJe5 Ld7NHotXsx0S7PhxEtVsXYdhLN9XvbLPBq3QwfObUb7rlp4YeH53jZjG3ixs8tlbRB+6moMGgF1v OFa6Ow+G2/g4niuhpY2bC9ljKifFxP2Il4IBv/HFU1D0CmM4IZQnln5JAqM/Nk4NOL121wbEity5 scj14kpoIYGrMxso5WR1z4GffFdQNldIrXGd2Gy7s2L3I50D16DYrXDI4kpQ6UAnevNulTTo5Xfp 03Xezd06unjW8oDFFFqaYhahStUQy6aTUvF4tDy7dYhdxnMwgKxjQofQSQAG/CxVOa913FJYg9AK yowmTI2cix6Y7qRaaNzRVDczYQl+PwrEJOB1tFU3F2/QwPgWKwXy/bGPfawXvmFffytzlTCkj+RM HP8ebxp+Lgvf8guAkguceHISVGH8RbVxGgR5sXkO9OYsSDOXMps3W6s5abmVLSh1Rc1J3EYjLT8e 39A2q8a+u4QjZGmHDIfB8LkD6QccP0nFr5SAz+R1jhDMapYFQSZFcE0Y6m6ro/QNJF/FiTiZda7v TZXTI3ucM0L/jnZHrwNWYo5Se5+7r4HSvJb/9GbxdFwuhJZOqZiyhW/f5pqTzgaOMadI3D+fuJsR /mZSUHazOT5AGwRWacrLlHJJwRCO2wLmizUnQeqJJcImhlcm6WZzNJuOlDJ0xeNkKjHhMmVp45LI G5coW/Kt+Uk84GozcenKFYjQrMTVxZqTSgCyueakAx8Qu0ypEjyMHq+U0uh05a4gN4JDWX7ZwLEB dUFirqMsE8bj1eiPZaSrzUABuavIzkZ+H/dJeEZg8nPHPYQNI2XJLFOKE4NueNizrgcGRflD3w16 1SMe8Yi3Jh83+HJ578Rwa4svjBiDjjIGALng2hsAH5d/SClLIYUSoP8Lm0o4TJXEykoigSgMaqQ+ qGQCSeQbJ/V7riRYSmrpphKSb0DCTYHkOWQQlPQXZOpIAfX07Iz4qpQT/Ziqun/ZphK4jlD67s4O MFRCS5YMzNCJphLE8bWrVyv7pMHw7IIccpVpF2nJqnk7mUoQ8FySqIRW9rrZLKUliD27+ZdvKkGG JBpCYUIsFSQ8ZS+snFe6qYRUKdM7ZSpxy3WKcHjta1+LvouF5IEHHsA6xGq6XBw3Yhpd/Rd+4RdI 7/eN3/iNbPtsGl/+5V/++Z//+dysCQEJ9EsyqR/6oR/CfP6f7HGdxWX3ahOeNvmkoDFdSYpVgo1E IyWaPCcJD/ex/G5h9SMAqlt5C7+XndJaIQdJkAqP57oskxS25XcYUwBA48CBmxJlqBNAUpcaFmJt KuYaQyZdJ7VfT9BXOS/dfgCAtG7Bf7XTwIc0Jqwc3Rv0exeJxfY4k6cC4LdDEkAAT5zbdHU44UEV SJyXDtNW2SihVz84JrU0xKZ0aek5k9dsIrcYYZP4ynEvUFPntaJllkho43QR69yWpAgOZwsylrzq Va+KzeKpcdzshxRioNjNC1/4QtJw/8iP/AiFgxHiX/zFX0wthVirQjpTb+H5z38+9czQ812mA4Rf O1wGtVtrdmvVxUwlCBqN/dZuIn+3iQVcmBM2Yeigu7/fTlIh2/VGV7fmk569yRaZ0lOabtcbO6q0 lvDU69Lii6e2da915o0OaQISnjaWvaGy8VS2Rb5vD5PiZ+lqj3CYuAjb+t65grWb4Eb2DvbI0Vt1 bVLcslW/ur3XaVWr2zTu1hrbaZTlfvP+LI1YtdrhYVKmewBgRnvzpFUgDJCOO+HMBUE7k632OEkp aFPsj3zUCQ863J4KylRzixDb7Gw3q8NnRa86GEhCLDfjr3X2E1lrjyJXCYxtMgq7fXWuf1oy870a IYbVBYhp3Kk1EHElvDbJwSEnSAW6EZtuHqGKQhxQKBgo7EsZSpTwzVso1MJH/03f9E3uwUA6I/7J 0cpJ5Nu//dvpJNScxCTyOZ/zOU95ylOoVYZFm1doiZX9la98Jf9+/Md/PKLn/Oz8amdXiWrYjUak PphvUQ9i4zzcMUgx7C0ksrm8Nkxa7q7BhaKwzIWyZOeV7YpqOr3zcw6S44v+drfb3u1iR1b2BufI aDsFw1gzlCuZfrEDNnT2jBnXEmMsmB7HBmnSp9jZO1aaEvaN43PJ9TGNDJ1E/BDuM5lSDd3pCLXg oEWH1KjEwm7qgKyrgxGghtG1+SssK4SbkgR8RnFOTKAzu9JCTZZt6qzn0C21tySZFDljXIO2bLMm tXxTHjMenGyUCRlSH7JN2bCsx5JlNuNGy1pOSXg5ZZRkOTxeczJ7lz6U+Hg+752f4cfrXjmAOye6 27GWo1Untj8gYkuZbVbFlboRz2O9B6fnO4dX2D3NfJe5ZGJK0RvKBP5LmFDlV1qNQmHGEqXsvrv8 qMNRg7LlFsJYtKGjiJKUJn9w7ZyeYoPHwm0MMoMU/BEAAFS/dCNjI6CMxruHiyvvKyhld9VAjliL XPMQJo68FOdkeVZFdwthnvSHIMprj7ijeEEKsm+Q589M9opCJXs4KViVLCWjzpJlVt5Jh5bL6diV ig4Aj3kuxPhqxao2bB3e9mDbDWtWGWBGE5aM2EPFowp7g4sdOTCnEzIu9s4u9q9fU34Rc8y4nzbu nXtHYg9yy/RHXgGHtMkLEbdEWdrLiE9IopWSUEFI+HaxahYJb3wKvZMzEtD4fVT+LNztUJ56RZoL V/h0mRSh9LtRacZ67eToWN6v7vZWd+2uRs+IXOYFk6A0U8v3Xd7lXULpstSoEt5HXf/oj/5o3kRp B1AkNbF9dEqc36d/+qc7CwINWjbqPbKb4jgYTDBquwuYkBLwTrFKNhClsLD6QO4Ys5JRWVpJhfUu /ai4L8V+DEkEV7GLqwqGZY5Z3V7Vx2pEKaDKWdEmeYqjlrXm9g73kWFzRKRKU1phJ7G7p9X0gq95 5wgsoOViurJWWRpgLQCrdpb9ODEX7bdoqvps1G1Se0vWE/9IvC0+YVK05bqQxsCrVkIF9YHbymek gFzuGYNklcXSfpTtSB63EEantoDGJnU//28hNTzPiP+YCyxur3Bc8t1w35riI8h43pXHImqvOiMm a4NYx2greQzeLP49xhXAc3HYKGul3pr6J6KUQ5LBow5pyOZq0ra9s8P1f2VEWkNWPhcVhCVVcVMk b2l0KEVlFmiqQkXaCLUdcvPFErEuTIp5/4IW0uoyixIk8BNjUmAUKaVJm0NJeqTfnsjnks3LE1ll qCaV8WibXCXdHSrLqLFYyxBiP4xOAjLFvTi6+MRdVWsoxUp3ygoAMbbtiAXKLjoHDEFLjONOR2RF dHoVmIhPlHktZ3o4Xu0jyhrhov4pvsag6lJ7LfeabC4RJ1sKsvDDiL6vAHGbC1NwkUoKrF2zpD8V FWzdLE7weXsNSwIDtistB+1DkMBWnWc5K0xN2rtwK0TxD5OShIkX7BJlHam+XlSKCG06BjVe4BZO bYJom57bVN1jY/b7CBG0Tlkemou2vsU6ZX2bgRlUzW6tAiopZOEoQIYIxdJ9zz33oI5crgIOveA8 +ZZv+RbU85//+Z/Hiv285z3vD/7gD0AZfVHKPWjcfP6f//N/xpDyq7/6qz/+4z/OL3556WUvexnO IuqclXZdKoRO2xCl2n/C7jo8Ot25frhh3w5fXdx8uEUamr3q6Oz5BTpebWun+pSEvj8dDFtXkuwq w4ePWtcPQimNDTCPz/vocZ2r+ynzOn3Dg3uPvC8lv08oFlzZ7fj0ghWsgtNVD0kaIUHn3qtVDfV9 /+Hb7Su7BKBWNgars0GvdZjU7Zjyr9RrLl7IXDHEvDa8edw+PLBSuRXP9KxP5dnmTrVdhZCa0a3T zn1JoPZuPtTa2WsluJ05cIyOzrr3X6uCVN9Tqba5t4PGt7kxQnl6+1Tb2H714ppRymI4TGFC5O/Z W96w/6h3qDroC7rRCQffLcr1Vs4L1Wp6fNG8lrAKxtP+8Vn3nsNKUwODjm+dwtiulm1+cLuzwNuH CQCgcT94q3vv1Uzd3Ngvy3A2mW0fFoTGfDzpDfq6d7f+XUQrnkmEp1d6oSF1cC5dLBjZzzsf+ZEf SUTh93zP9yCsn/nMZ3INkk+e9axneQADDzo1RpmnP/3pjIQ5Bb072LUdgmU4lfEwzVrELFPkoA9h qms1tWhJZCAnsCqy6nsmRdOUlmJZ+kyyGZomm2aOp9v2TsfTXVY+U8JS09yzKMiW0bX6keq9idkK PeiAnGbjlrcrSx5eDcOI2oApLkcdZBpwZHWP8IAKjybZgpWRONE5DLFM00wBQEhdr3yVerC8KtXQ iksIDE+jrBUcSIFU5hDmldrWCoIn9TuvkfcgqSWA0qfnqq16WIaJflTsXAoITHtSJ+W9YQYuPpi8 MKdsRjjShjyuyNi//bf/NsV7Eb+xKzHVxu3jenisJ44BHR5KyZ9xOKBHj6Lb+11bF9z8Qj5uTCh/ 7+/9PYWL6t6zx7izz1q+XBVH1IG8nIuZKXuGYuX6tZqGfkA0DK/OMc2gk+F40udEbbnZZPiz2oDZ K5wXW422biZboL2K6iqlJ2WQstE99H4ZEru4YwZBE7RhdC/LIKhc+tlZipBrWV3sBOx5wEJ7gv8W KaqtaBPD6VK0TnNuqCmWWaJjyxcsE994qqg1xrexNKJlnguj62Mrs4l2TDMlpDbhFUa3AvCL9hnw edbPbAYBV5IndtvFz826AyR0cVgu5KrO576gSMi4opfD6FmoxwJayzGNdwF+qGM9E6qaa4lb81hj S2agCGXPeR9DInuI3ew23iIaVYknlSTER9Q3hrgCcYVeRXUYIheTpRnyPEomDpeqoiQ3cFTj3M68 onWOK7tNpPDfbLhafdjv6djuJZMlvyx+Z8EngsqMzFoFyl2Oc0zzyaANlPJX/HKPpoZHRMd5AbPg 6hKlFpO1NK3mfCgSV/aECHjQNTXT0xJ+wmsaUGH8KumBXQdPQ1iGKoJgISQ58CJ7WNGrqqYVqEAU uaUHwAgGvTTVIqXMQq/hlTVAhU2JMyYN0UIIlCiVcSx8zioww6beX1DKKJtzNY0xAY2oJjYaQCt6 zgyAOaV0cQ/+9Nc1qTpXkFRY0nIrZln+FkwuCZBdt5J8obSxzJse4MTrkIPSv3APvgd5s9Y8dPzG N77RC72DGXJzk1013Jy8nOBeN0bl5wxcSjKV1UUlrcgYXpchrELl04KYU2wOc2GFDqFLIpNe/5Si uligpCRaMpAYSFRcyUaTtko3QVILizePnHxLKgUixvyjfr1tkUzIBHUBA2YD6/fFBPKxqJ7A+vbm ymBoXUVzE6Rfn/EuDSlWUtbX7BwP0u7+nkbMlpN5ixa/m/5u1jFtmVu48dqy74eHbuVLtcc2Rd+J ac86DCPG08nQYqBJL51SJdZwtfEBBm3e7r1YtBU18v0tH02gksaPFEu7Nq/1KqplaKFSDOIYoWNp /cueTLummMk45sUUZYKMXKnLUGt1U31Gtn6cdV5tIWu1xDYS8fh+lWDIfAwFSrnUynZvEaJ3cSa7 dMtcc7oLxusu2AwN9hiRtdOGSw/52BGl7COXJogQdAIZo6k7WqRCoFRGXrQHrm5aBrdlepkUyRie mWCqUU6VyCNXQpSVsrErqcrB0lfGWqtSsnhMcMcfMDncqTpPru82A1UeePGWiWPtT6XRDVHafAxX KlAANuRVNvQJo6vUVzEhaa/lCwHz+er29sYn4RGooGA89gKVhhtvZ02CZzsDtwYJbO+0LLt5kanQ mzuBtQXrWpPCenBxLGi1Ve8TM84dLtnz1wbS8BXuQ0vrr2vuaMmE8xFF4lfe75DgdiDe/OY3P+1p TyuRRBncLYFZ6fPlP1kkiSH6vHt2fpu9s9OptttiwEHEsK1VAnDZXCWJF3AktqazlHsiQHh0++jK 4ZVCeMAauHsXPdgupewDhVpYDCmJMhCFmMVScAVQp2enFOpNuYAzGHAH6OzqVaVrr3zwpnCtRtm4 Nj4sG91smk5TMqu8nXKVnJzd6mzvbLerLbzAidMphVhMOj1XCYscPxsFPSqxmp7VBMSent28cnBv ZZ80SEcs3dI4hVjscOTxgwFSLkyBq909wherDVbDwQALRgoAzItVQH2G6ozalvqC9iX5xt4/HOgm 4wYcsn8gM5HX+CSRkH/+53+Of/HSNu4UIm1uo7POKkClRCQazKSypAKi001aY1qivyT1exkArGxM hVrqg/oJLAUAqRu5QlfZXsbNtMZ+tTcFAitAlWaydLKmkUCn+MSWGbckAGvJIHHJVyJK2L8EqGsu ra8ZpvJokvFAVq0uBVhRKmH+xlVpZKUlamkia0kjTu7WzB5Jj9m8klr6wSLRg5W+DK3mZBqwTqy0 1b2St+3kVDEWezneSCK4cSuiaPN7XEYndREmYXR9I3YMNn/iuMVM/uQnfPxCHHwWn2dfr/yP1StM eOiNzZOeo27Nnu75Y6LMODQYovGac1J2kKzN6jEy+2ho6eHNemvpsVNlntPKMymF1oXmApXgYDdD 50/UNOs+S3YzmwNtaUCbmIMRJpidIN0xVwKu0N7zMdkd03V4DcDTQBbeVX2uQoAq8K7KqbSA0y3U wCqQsm5XvRH1TiusKu5SWA1w/jFtBqTbtzSqq1Gfv+/bpoeXb6CUNw88kP0Z0J4xwmJ2BirUknMs m2kAxH+J+JCbo7hlSsRaUCriMqOXJRldQkABeLfyG3FXLq6s82xFzFXU2LbZ6uWFtUppQwyxq9ZU 6IHe6NTlU2W3dEi3lc1ogIldq8CwF5bVyheFK/NBZDzg0K5asgKVROfcPPDG0dTyfFMxF87J0RBz aoaHJXlAt2DKna4xWpRQR4NsEqseWs1Nxl/7tV/7rd/6LX73dHj+zh0ylTAjYroR3B/zMR8DQMoZ htnLiC+rppWcLXjYcheHzFpuBLTis5yPXBxvKNeLuYtiwfMxweNypcoQCe0s29SiWHC9OR/LySYD tOctcnS49mvOjMh/hUduZhY9c07S2P0Muf0L90Ts7rO4C60XZUSycwYWTM0ib+8XJXIXlgsLLURF RatYsG7c+J0aN2rudLrcDqDagIzR3IjZ6aouRA6wODgGXk62LfdZox67wTtAKwdd1J4v7KZDZo8T n01JWlaoixoDb4G7ShJnicNxTUneyv0bUJdRSgBp4gT8ujjICMp/l4oFhyRZSI6qYsH4j7BsKnU3 l0dMHhbcg+bDBu1+LMByLTOosY7RVe7HsmMWDGRJAWdocR6rEFQ/3E8x6qQ9ufieTXV/tegeBM/w SFDaZONWtBUmZkUJ6/IwhmzboMzTyGjEbbd0VUOOZ3EBl0Ri52SgVAY8ZJnXKTytg797Mope1hKb 4WERZ8jyroK58rdHlAqFkn2Ccv1BV7/FY14Zu9dliMvM/lNaSG4aimhAFT3bQL0JrFAoFuzAawH6 dqeFWCjXu+AZG4eSm0r45+vFPIHBz6lJCNUCGWKx/vEPyysWLcMSpeT/99sxpm3A0bEjl6FL7dUt Ufd2GcUrJGi46GHgSCBQWFkiXkXkbCXoJpCLKuHCboeYlEN9lPe5LkdLcOTS6uT4mOB9nB/d9SZi YEBSU2Adaw/AYDChUjCwea6SOyS44VpymBBV8nf/7t91Yvu/ANcf9MEIVsvABDG+4t9ZkD2sYAcK tHS5tvYhsOThYy4mNfZy3ir6LrKxVKZ5y/Jxcxd0UwFc2sNP2Ex5Km+Z+rzI5YK9rDKPDC0x7dG/ 5XiyBb3kZrHJ2lf48W6eNq/vK65j06NePEaT3FW50rP6BZcvMNnBvhC77O5bvGZ+VPgGDOQfZltG gcVNTtLt2fk5fOZp6dc+5o8d9fr49PevHYouG4Ok6Fbumv197aO265fMMYGv+IKWno97HWv551CW SfFvfBRdBzCIwsjO6VXCpQrU89vH3Bejarj3towHEyz6yp0Hlazl6HFXVYrzAFAReXu7ezbTIFrK k5MTzyrwhlq9htulJaZO2DympySZun5N/uEqyjIpRJuV01w7uvow/zDQOmutHD0QC1x5jlM2xHW8 7T3wcPmQZYjcrLRskOmM/aDrRcOL8mV5mrDWFbLtZ6bzTVPzKGxgCEwooWd+NQtIWSvHnNWRTiDk vvvug/E8CfvlkkxtFBPVX/ou6nHcjlA3ees3886Hz/3blY971a2U76Jazeqm1p1fbvSQnVIzH90i EBdravPQDqG33tDSv/Jm2QQ3ti72tgJUx1A2Helo3J+srBW7mK9hd9OzIJ5pWJtgtp7KAC/RwvBq EYcWslIxvJPGnR9OrARovZGBupqyMRU20Mu5INA0hbKmQiYRl0Z2L3dxB295ZoGVwnXBzdPPVkwa a2XE8lAXQ9i6zpe5ejUb2MqzLAXEt2Va/1qA89WdD7uRspy1TAh6bytHD8QKTLiBt4NMdJXLNYnK J1NDMrG0uAm58kXdxsyeTVNbpizT1KVfezaLTprhjUSfYKPi8ZzGGbESc5VUy+aNLUAfF+VRQslL hRaGEHdnK3D4RuSpCVZqRv55SMTsf+qgtM5ExNyoNtAbKXAQpWBem9RnJGFQJzAbFgy64Fw0VkEA TmdSCqzC04bR2e5AIv/y8Iq2kPUGKrpngiEf8YapOQY80TC/WOygju6m9soSod1nVqOuEoGrypLB kXo83TrocFBfp0FocnkhJeDcPLpjPuSw5k8PwF+HChqgl9Gt7vLmudEtpDo7PzmlYsoWerPphIKf jiifPi9q6dJpey1lae+H2ZWjx8h0GkFZP/aum47TiN78LoLn5l9HWf/KKeu7cgG3Ri+L/cw0axqg QtKGbl0qka/SwsKzpeKSyJHvSGCJlk7oYVU5rvjTk2AkUtZvUXiREE94vYGynmjUZYovtwWf8zu2 D4vtcwzwSzjK6DyIuYCZWeC2E8JxG8O/bnRv73y1cnTHvIXwK7M0/3rZT15cNx1LQaN7JN5tKUNT QVaJZPKhcu8Be5VvGjGobuSc5FNzaN3c7FTwvSGGJCO3kdW5JT720Rgp7Ot9UWl2SX7SDNsyqbCx ltx7773w0nu+53tyzrij4YBASZKUBx988FM/9VPDAnBQA29t3hvACw/48higTZuVuGY2OTpvksOl o2s1LCW/6eRWM3GTOSlcAIEIMLi5SimN/VYRT0reakZAaviK3byvOm85R2bzym5LZLZFySnMqVou uv0yPDpvUV2JW3brdw7noVAodjNiQYKHzfm8YLWghJZe9EWLYcdbBhlXmmAQ4srMZXknCgs4N8t6 505WFQsmyRRRa+xU+d2iZbAdABALsUCsC7Ll0fncw2ODSWGdLPbPmW9ICr9hP3Z4QBTz8ri90tBS 6zL2Uku6Pbl9m5wV1NWV1mmu2vgeo6982bYtkRAwYMRcJ7gDuviFlkqbU5WN2rcuRgFaH2UdK/I5 dPd5eRvwUJ6deXicBP2z887eboGyxrSxScEx6QYBB3XDQuCreHEtj64la7s7XUECpJjbIdfRy1e3 SHBygsTYJLiNavxwaQ9B63XmyqBaOYXw8C2sBa5MyK/Qmv1z1598dZdMJSwiEK40NevjFOkEOw+y G8FNphDkJxEm2LLuqOCGxmQN5CIQt+FLC/LtVEhhfPOEzFuNhGSh2IwAKVj3Nog5RCFkSIxi5niR GMfN6oK0ifvB/PZ5/XDXkkxVPOmFFLyQUgoGaAa6sPBWDa7vacmaSTHFjvqDUX+4d+1KSreJiAWl vmhTon0BlSWUEkbNaixa+TeBPDw75x5eYiEFWCuRB9LjuGXjrtdTuoW3EZ0pPABiT2/cOriX4OJq cqXHcYPYxGKezoSyXCfEeiL70FIrNzlmMu4PCQLqHiRlIpKN+0rSdQoQC8ZKTOgehXUakqOVb738 DZMlN99LX/pS4riD4L5D4YC+VeIYrSb1X1ILD5ZIeVB1U+jq+3ClszHeljfr2qGlH/xTQM1UmrR5 MXoiAH5ErVQ2HcKU1eItXaNMmZed0JNyMdObH4FTuk0RxGGRJIJK+w3H2xJUHrKXAuql2iSC6osu nV6Jq4BuZdC4FMQJjaFpIgB0luJG9jHTFyxad3rjlAuDDsDK0wMfbj5ahRWkALN6/TWveQ37RAxe alrXBMxvagKgoViwG+n84MMv/qefejY8ftbz84W/uLn9hBzTBAGR+lJpOwphv7IgR0GwrvK75Fr3 BPOiH8Md+PCsBCbUBiw1LgHPu2y/7KvZTXqbV/xKZhKx1CpYeMbngzr1TKN49uX+NyN2GXgA8Hn5 jDbgVgabpWLB69r7nVg3/xXQpbnkP0ZGlS4bDlsdmS8rHzfFuqFm+QnA+CmVlssAxG8FyvquXElZ GQr6fbe0lijFnxJn+ezYXPoXfXkpMBR44FqRsjGqYWxUs9Dtys4DdUIV5tL0lzkhUNanuQG3vr5i DJTbe9i0TWFw0SNrq3bPfLIrg8p9dQfEbgbA7476NrOZB+gzpEJa1zKIl3XLsDQKU1GCRu7HZ4kf LIqwwLUFqDhJuDl+JaUCrX11u2MsdBaWfKVq5cYWxsJWQSfI7kundXWpHLZ6p7HDHXAUdgn/PMyK XzjccWXzjhULrpE9vU9Wk5YyDqtYcG1rW7kC5JyEmWpzMvs62O7xqNQ3fXdxRC9vlSVDNh0qEUEu BZY3tJJmEZyTma+jrjsmlrBH0OIU2mlukwfSbr9o/c12WtPosm3JCxSGc2K5RI5hWG4fWvocN+gd Pn33twRyL7d3DNCAZRMn7EV6NSLnpA1nOSLI50ASGAAl0/rGe8Re8tQJ4WjnRVfAGdTNqc7u/rhf bpkE/kmAMwj3UssYdd4/nbsn0xOuOWNkqCgWCwYqQl3FXZbEm66G08lQWagKqHMYHMiSLr+Bsi70 S5iPgYkXrHe+2d0CtL4WwnTi9orm4i6CUibJQQ5fwgS7WZShuJQbEkoc50H79gTnvAuszXxFe/eI rIST14O0cSC9txjaEuEC6tYtw0BZhfLN5p1ma0TdU0KTpc5jLSF/DluOc4mivrnHEabGuIhjV0oc sBKlwocuZGhQSOxXr2PCchP8htMbb2E7wjDIvwwHv8VX3i8Rx80wjOdSBisnxiNUDz6kwEKw/YtZ ++RB6tHAsx/4ocZt3HeyWPDk1gkJUIjjXrdow+eXsANyBWY0SsxmwF6FQSrlVAvGWLh75vGrfCYP HTfuOUjJKpnuPEg3srsLKxED6eHGrJhhf0Acd+X0aZBo44ZLmZf2gpRiwRcXLLaUljLFYuVfRLJv Avni6IRjhPu7Nj+XTAKTWoWZNciSTDEZWbHg6U5XTtfNDwrE2a2j/XuvVdylsF7SbdzQi+Q2h1eq eQBc+ekkxQqkXCW7uylGGGzc9LtzWJ3Bn3kdHR8rjjvBEuhx3CU3g3vLNltm6PwNb3iDEqXV66w4 OsFYjxp0uThuegEFP/zDP/xP/+k/paQk2U8onvAlX/Il3/qt34oeHSYAKl/0ohdRhZKyCf/iX/yL n/qpnwpnH4T7mmLBVZwSfZ+YS4A30L0S81ZvU18mrTgkGmySydYAVvhQmnlTFXgSkuD45s9RLnFe UtjTAFCVHirzJTyKjUjrk85kuU/gbFpKaKaV+6Mx4RSuYm9+wFKnTQ6/pEdxBWlNada1Ciwpj6K4 03LNgyjkUEqfYq2Nd1niTqTsVwWfeHuZdBJzhaA/iluS8KWrFImzwlyZhiuMX1SdWXWfacVIOrmm kRaGSaw5yTDigbSJAW26/yaeAJKaKMDHPOYxj33sY/mFnK6xYT3Vxg1joS9/53d+53d8x3cQtPTc 5z6XIBX2MbL9veM7viOqZTiOsSFQQfg93uM9qINDy0/6pE9Cz0fpJp8s+8w7v/M7O3Cc/TnGc75q Ek+t2+xcy5tt+uHe6nTW5qIpkXC8uLkxBpz+UFd1PeF66Uc2B2VNV5Us4D7rtwGACwXcR7ZPFLcV v2LtdRQcTRpj0kYrOK/8Ux5lvtUb6ZKCurKs9/Erhc7ntcG4PppSxEh3yZWdPLMkemYFRS76hzr6 Ty3q3BLAhk6WgHFo6xS7I20yGCihy5KhL36wAPTGDeaOkPXPl9CVN55vMf3+SBW2NuDfO+GYNZBF R3HLVZSdUQGnN6LoZUVL+qHbPgGLdo1/GdqcsnJsYM847ZHwWOkBjLIWjleenfPA1mBixVuVHXwt paxljSSdF0NdC/BJbWgP0+OQoFcAMMous43zofohAUNvTAx7xoRrOnde2hqMlJRBdtnidAqcoIk0 6JP+WTI++nrKNkbT+ZD61s1KEijPOxjAmRwz4apVZqt7RhYAQ+zm1T1jdbeoQx0W11KHvjp0g3w4 qfWGrYZdm7RmFua9krLzrYuR8h+IWyooO8e+SklbfF2rKFVebmcDXUQyQZEJh+ICzyiLMOlP6pOZ CjblM1Ji7uFEAhBP1UbDoHtoJC3tsf1VcZOkD7mEqQR1/au/+qu5sEP1SIrgoEFzCiAHygte8IL/ +l//q5cuQ7+mKPBnfMZnULsBCU5mkq/5mq/huMTzu7/7u/xL1UoSg3Mk6QzzvMtuirU8Uxsev/1k lS/UEvJVtCdJhUK4M/tmrPxqj1An2Y6JaEMtUfi99Wz2KZkyQ/+hvZetw7pHPmhZ8F1VkTlPMjVo Li54ke/iALslLKdTHuQqI7vsdFn3umBo957V2HY0ZUUg/DyaXmS7VGrjxnCqKzp5AzO0ZZePZW20 0hYisRnl6NasgYvuUPBLwNsVU5MC9pRwa5jPHylmdS3d6CkdLBbttWdo19lAqcxtYAhgDmZE3tRe nVu34TgTQ1ugrFK1WDIQ1f2QHdy8r7I6lihluMpSamymlChrdwIkJgDYo3ECbmTTL5RSUqHFiAmV 2SLLeGF24ZxSxkaWrad4SitRym/qqCl7vJVQyDawHAA0uxgYOUScdimU1TI0fSV/ls+LmeYqA7Mp GRvXYMYG1q37ZjevWYlX2+GWmdDEvtZUtmYtRSXrYDKS2dYcG1wiKyzY0N71IcTjZkrpKGm3fL3q yBKlMp/NgnNYs1rdtmJr85JACJQSYXW9V4qG49NxeHxyQiqIrZ3trQOKCG9YH+WvmOzlcpW4gZuy 7j/3cz9HLZv/8l/+y3Oe8xx6RRx/13d910/8xE8Ewc1u8G3f9m18goh/9rOf/TM/8zPIa9aDS3wu 4JRgmZ6qSkgjpSod2+qNk9Z9hykTHR+dUUSgmRDHPXjoiANtk1stVc+0N6RAwzbF7hKewVtubt9H VbrqRMCTM6rSTdpXk4xrZzdu7V2/lmItGZ+ewxMpFTKnx2dIohQMcHducnzWTqs5SSi9yv0lxPlR uH181k8s5EgWmua1gw1VVjPiEPzw8FF7p6u1UfWMjk7l1tyvbqk7UA8fdR6RFNg6IrHM7qZK3gEu Qhqopdl54FoVpPoeAJoq5lltsZncPEHINhLKmU7P+2yxrZS6o7jmHrrdfuB6iqlgenKBBrOVsAyR g5Nbpymrmwqlk5MLikMSXlWJLpYh7JpSQG5yMZgPR61rSctQq/t+lmG16XRy2kN5aRVLWVJxsjca 6OSaaE7N5xkEd/XA/gr7BSr2B33QB6FN/8t/+S8/8AM/8Ou+7uue/OQnI7WxisToQz184IEH+AS9 D+uMa4vuF155cQOcJqbWRcVITZytdI6pIbTN7SY3Tys5gAZKBZaYuRsLr9ZVCm8rs7COqEmPb/FJ ezTX+BO7RRc1HqqGQObCNH8AfRGbnZJpnpY6xVYPnrWABClGS9nJuPieRi+Vq0+z8kPTRG7RvMgj mTYvdLIUQeydgdhEuy1krSdsnOqTIKgUDhBPKyO5p5ysfNi2U6Sb+uEgkUYsKdwEI6blhSepRdIi NMU5kVgAq0rzSQggGFQnghKiqH0j50caDlciOdVU4uEi6M4o6pQDRohzFxObNVZsNoFg4+Z3Pifq kJwkOC0JAMACzsCIb0qX4d7E5M3pRpWH8pMDSXD5tbnj+cNyl0MIxMmh1tkYa9LFoGklqzOfR9ws +h1oh+c9mRC6WVawRaUia7Y4v2MzOr3Q1dPdrgygecyf5+MzfrKjnn1F1SxShbT28soXa0bnPQUM HZ/TUic1CqhnSZSsw/g0awNQXppMJDT2EyUcXLBO2JnaZ8zWxW3jLqXL/AS6Cl0anfZEd/UGvKJ7 /6qjWKjblG0oeQdqyc7a7bhALOFqcSJmyU5m495g+8pu/GEmRPJ5hTPhlChmLv1jtwUFa3DlGCaO e9Ifd6/uaU4x5pcnSN7HswviP7LyyjK1rKCU3uMe+UVfgSKEvRsCjQi5syyHVrgFVxd9iEQwYrbT hLUeeMAg0XF9MiWXYefAkr05pYptMp4xRhqe9DBbNywUVRQIF6RzzDO6D0W3sEH36hWjXcQnESSZ oXOrTul0yhWyJ20Y3ewT82mPQPI6lGVAu3Vf4MBFOB0GQBJMc+pCNc6liW3SK9rz1vj0on3FmDBb xUsA+80jEEudF+aN90JVpou4KhBX9jf40Fe3cFUcXSaqXK6StGc6GJFIYNYyo5mb2wyEAPACV6S+ 2Otafci1lNKA4Gqg6xTtvR35h0pzL1KEIYe3T1r7u2JCM9pZLtyl0W0tc5oExs7+TrZkLOnbxanC 81BBUo4CPjN/Lm0qMRiyrF0enEgXfJJJtChU1mMb/Y4ADcCFC32ubCL0P/zDP3x3b5e8vqPzCygq PzatZIuzJBWMYruestX474YykEPCW3cQSy/gSlhDp4xFs+Ir2DTJU27FdzGcGrRYrvOeQR13WxVq zelYCYZIpyAngJJHW9pMz3a9gERF9sbYpHAM6fqJyvrKarxudLNqKj8vRyRLd7dFdt5Ce5M1/jqu fJkuqU+Qy3fHciCVdjWi92WBt4YoRwqryL5fRpeNrjztmdkOx0PDbtYElMa4YppWXBx5geCSDKVK ITbwiArKHpS/ArTm1ZWOLtxK8GRJLZxYGaVclil/9BzeXDu6LSXZSjWEZDbqiRZhiQei0THVeLY5 200JKLbrdn69xfYysoMClC5HNKg3OML4aNZFSREF8eeldhxa45Mp+BG+5jgDdIc1UKrMjZbK3G3k MpuK0S2b43poh7AWcpPADmKcVFVAl8ECY2vuTGGuRWRXwthiDNolSukVH13p91lQQoH+DwBrRlfG K0LahSJ8k7oyJrdNtKz8DtdiUeDX0WUZXUxlOFUDLq4pU0eU9Qcw+Ip/FYMRMF9auUZP5w0rE6mE +EJ/zFfRK3xjN2W0xBmGxS4G853W+UqFSTm7z6mhyges2Y7lqhM6rfyuFkS0psh9I+xsKThd4kKn tLV8pWXoRT9MO1SMGVCbD2slevluNCb2wYsIiO2kPgfWsk0LQolk2MEl4jh4LLgUaM/Ij8T1wHaD jAhhpaf88tYI7pR+17Vxp+XrXvc68nGX2vR7fWi6bbm+Nj8g9fzkbP/wSlVDfX9063anu93dqQ6O Pj0+gab7V6ptW/hUqY14JS2Gl9D5PbIZJJzqB6TDns739qtBZV7HD908uPd6SSVfiRAKkrL4UmJ4 CaNGIFKDuBKxCILT28dX77le2ZIGZ6dnOzsoO9VWIPZ1TnPX0jIinByfkDq88qTMKjy+fZvpbyeE UV+cn3H+TsEVAvD0+PTw2tUUDBzdvNXZ3aXgQGVjhCboSuz27Pi0s0tq5gTEqu5ovbtTvbiUPeOi d3D1sBJUBNzNBx+67xEyh1Y+lEdADrakcVc8COGL09OU1c3eTJX0QyqvJrDW8a1be4dXmgl2MG4S DEZkIqrGgJbhzVvKSJ6yuvu2uotlP4VtLsEkOMBKWLu0jbsK7dXfE8fmV0LKTzHz1oaOpEsuNNEq Kb+wDlS1zLfKyjkokqCyUd5AjaODyIb3zECT1jFaOfFSaVCkG+yUbjTRvnc5ElRVZ8qR4hEDqU9q wUMvjZiE2KoYpQVoFlaSDGl0Ntr8jiIVk7u14pBJ81K4UzJqU0lgoC7MLBsn5oka0vCVigFptIrb TMKAxk5q6DXekmmguvVJ/fqZpISBPMYkDTGrWqXauN/6EexNVNpXvOIVpCsh7lurNOMnHXlJSga2 uAWzSWQbn/DegKtNnW5msFv/Ag0u+hecqvgx+1WZIB4p7Vad03OrftJdW4JHq4TGpHXVja3Rvm7E Vj/nvQsmZVWmgmF1JQXqg+GAI1VW5d0aY7GJSW2WAS8NgyVuXN/GprGJw3xRgSu/hLIZVhmyhgPS k3PTV0dg1axa67JGCqCXgKvMCCg4C7DaMVELAABpyUlLh8TNHG48wEk5uzu6sTH9s/9juUaPM/O0 CmvEE7QEExYBmZeZx8a1DgC3onBoveirWtAOx76qxUjlPPSPPdUVEhE23S8hYe9oiBdKEceW5mOZ ZoY7Mw5MJv3R8MrexjJMBhxdgQFYq/JmDTSACfl319K6ZobjldxApPuUxLoTygVlc3IjdekxEx88 cNHrwQNZfPQa9jLBSh7mEfSxZWipbdc9Ktc3JWGNlqHZK2LDtUs+XWWgrrfZtc7Oz5R6My9qsdyr bHgyZtWPT084c7Vwe66nrOTJVl1VaqeTxXrZwAn12snpKbWlrH6fkLLMBmFdMClQEYsXpgYFWXFW 9iw1PMTneKdNJeDkhS98ISGD2Lg9dSQs5YWnAkDBwbBMBhOzi8hredLWn5LoFBogCBAaFsKsXQIu jwkhg7HVRmBVg0SaWUnJ1Q+je5oY/vW3KtGtdWIWOOOe1Ul7fTCg9YKDwYWAVG4VHfwqiCfNCROp 5Xrv6MLQhkf7Yu6H2Dy6swK4Yl7K9U5kMTNdX2wMIEnEA7M6EgAnE9I5NGVK4X9fj1i9ZJk6NDuL O5JDYOP50QOZVSUySx1OvGU5Ewv9Ka7WsmxvzuLmiGIuYMDfqtwR/RWZf23VbWBavhoMYC3dXTRL 7wpR6MIx65PALctdtY6y2mZAF0bbqIDUBjbIiMVd0+1tS6YhI/5ayQm0/b58PlmaJwneeHa2IZrj RjdOpszdU2Kt61BUVVYTd1LJybQpB44FoUEycGpX1pTqJ15lPnG+8ooEZNXYUOyQIVEEPOkmV8uZ RXsb58GmJSMDuOWwk08Cem1U042ySsrqj1bx0p7kxPJlyLcKsc8B4E9PRQB8XBDbBNbSd3dacLM2 iCr5i7/4i2c+85klYC4Gfabe7VSb4djsT7ADHlxJmerZ0QnU2k6w7qFxg/mDvWo9ejQa9ofDK/vV 1nAgPD4hH/dBFk+yEWI0biQXe3LKvM4fvLl7X1IAKbYp/Ll7nepuz/s9lsqV3f3KkyL6JhlIrh0m WXiPz073ul0kQeW8sIT2ehfXrieZzm+fnlzZrS7myYIBABSo7CizEYjzi3MkC4e5SlBZinR7Lc0S evsWRnZYu7pb8H/WuzhMYy3UPXJW6CRR9ZxeKB/3foKnZ4BXmrKfplRtfhBAt27duOeee6sa6vuz i3N27pTVDWJZiSmrG/F61jtnUimsdfv46GCPfNzV1ynYZfFmcz0wZV4o8siBDdt26ERVSqRxF3iA gwjZeRLTIcTw3Gkbt+tTK3OVyG+bZgSTp7vqJBsmSa0BJT9NeBQlkhabrLiftJbahO0InDC+2UYq RaZ3NK/ttpLzb6CXJWOABCBJ5uDZPF1HkMEnCQHy6W+n5akAB6p8ltAvbbabqWmj00kgTk4kFraX VlvVixIeuk1kQjqz2Ivqhz45chLVU91U4RNK3p3SEj2yy9pKIIGBGgLrKveDS6zu7SZJH5N4yxZs Wst5vZWciwiy2sEr6VlRGcD08aSX1zS6nIXlrR6JrYmjkBcMLD06ZKSw4arzyAZ4sFclui8MhUlI TNlgY5AS28tWEN2w34RkMr6OSNeS+qThldrtmJaUNzm137R26d1dduQUUGWdeNvWxspZpgwdXiSZ ZCplLXFzGl7TmNXWC2Q149Jf5oN9CCa8FB5Shr9Uh25/SOmWNqktFQKY2GVWFzClNaB6dcaCZFgE 1af0saLNHXJOAjrhgNgc3+/93o+NHe07MLSvrs3Jgt1aRLNAsE0ZEcE+OVzOBxQLHneaqBL6oQSt ZQ3moaPYnu0AOHXdeLdM6Rja5W9Lr8S2rZVkKQHv+Z3dqMejyqQEv1ukif/bIRTa0+tg6R9Na/tK Wh16djva8kBhXqXhltvHGHBT+wZuKkmiUvtAqUCs0uhKSBIBGzatjLK4GrnHvH5rcnNwIMFmaON5 rZzRMl+Vmq1E3TqpAUnIbxcOhcGU6cm4dblhNuUnDOHAOww8oKJU+HQDZXl3ee7LpPFV46NUejvY vmPeLrX3dSQ4Z1P2A6YTQ6swD3PSldgy4CqFr2LEboa2UnAH1K1rGVPW8mgqT4svf+f/wpoi10jx oiaizG3oDmeJUuFDJysNYn+AM4YLvcRTTsDqnbZxgwUu4Lhz0heeswj/phQLtoOFHk8o7ry4QbiA yPlpn6tlpCsRRepzS/ezKBYcv+wAbM7t6zB7LvLlwqNhOg6SkxzbllcNX4azBHwoMe5MJi+WQ+qC GwLbBWP9X0EVw9p+JxbcjpnSKAGxXqcj/rbUnm/Nc7U4KW/QUJg+0MYYWJ57EJeE4NgNp8IB3Hej 0vKW3wmvr5eB3miOpPMYsaXRS9N0SbRhbTgqaBNq2pYwWaKUC1kax0W740FjcwfdDkhJj9uba992 X4awy/gUGPDs3QJtSXCvo6wjdlnXKR3enWMdA5WSznfQuKJIGbeWXc9drFjD253tOEDAmLZwdHZM JhYLpiWjh9XtkmEdH7o0hDQbtLdA2XXLsEBZ40nSxcCH5E/3cQucwCfFKq9erzkAWWKb0IMvQ/4t FVLA/1Q5hZXy7U4Lbljn5S9/OYlhP+7jPq4EUHpNW7kvTk8P0+6/zI4uatuNrZ3quw/sfuA9pThA ekFV5sh1f2z6mzcYR4WXLosrxWzYk2a3zrau7W0OfvDX0xHLvMBtCgAIArpdnVd9CejLFFKg+khv L+1WC4iFWJWqCjOCsjRLmdfl8v0nM+Hw7IKUNSn5bWCA9GLB6YhFviA1UgpEwAMQN6WsMJvPxdHx 3vUkB/XbA7GIQnCVWIc6kVu0DPsDYtF2Dqrds7644KsNKk5YDSuLBacUUtgsuO+QjRv5xUIC3GVo FOqb4B/3TTiFBX0I3QZO8wv57fwNsjJ8ZRFNSb4mXkmcFC0ZvVIMBRh06zjNyJ1+EHMVJgUD4SCZ 0hiVJBFdytKZEHzig7qyWQkAoLoKWdmSBpstdXEPJe1pc+ccvhMdLZv1x9IofkhPmZcbYVJaplM2 SzmQ0qmtgnTeTiSWnxETu03HVYoUXizDxEVorLVMrEqzVSV274SNG4yw75F5igs4JJlyGeFF2xw+ FN7lE30Muk5nduII7TdV2sbc1h9RHgEbN/JA1jcy/WIzyW3cDI/B26uI8rhe5sdJ718H22hh+PEc Ew2Qexx3fDLi95JAl3HGHv/KJciGyXo5Ue+ExgBMMLUsZwYOFuHGlPQV8rWRXmc8HLWv79NvwI+P Ffr3X8Loy7YCN/iE0xyDeg+OUtBS2h1jSnkD32l8XiWJU0mpso0bs+94bEVoZYRVKrWNmRpdf3Fc rTxsOo0AjwlCWVchA71KC8ZRQeNgrdpMKd/hguFYJMp5BlrxB3V8Yhs3yXkYMQT+UzYU34UzcTbf 3MbtkHCSiFkrppSzZUzZZVlfWlOgyHtw1uXdWDKWKOVLMpi2HC2xLFMCEcs27psB4psbKIvpL9m4 GXrx7dIaKQkmJ5aTld/pvyTv6MrnogTrdjrxal6hn9Je7tYkuuIX32tLlI0FiJKKAG3Jxh0JaWmB xQQDXhXPgeRfZ8t4Tfks3AJGm9gI5pN1gqaoIDGugqkkad8Ob4Isf/yc4r+XMjz45/CKf+uUftSj HsU8lfDFVn5c8jXwn5ul1j2+5MK/9LmhsddPoLmSV+lujZWQ1xWW7NHlLHuct7xn5xtnnbhzSU/7 1rUShyE8/mepvZMkQBu/ItG89AQqihtwcOVD6EKKZkDKJO7lWKoqLXq7nhjmYuCVQAoAZ3OP2gc0 +i+lpzQXly/xZAMG/BeXQfET2nuD+KsM/7rfbT9mtbdETUZZy9OzmQ34NuxwG0YvTSpQtgStUzbg qkTcZUqF9o6QAmZUuCJjM59ddreIRBW6jKqIT/Wfo9LH8jtiYQMozb00RPgzsOI6zMeUDT60DZQK /B+/WGoPdeBLMaeXaWafCnR0uhZXZFhW6/ikwBh2jTkmxEpKlTg2kHUdk5fYILDxcvsgCrzalBZd +DHOLKHadR1XgAJU4Xf6D+dCPnQZWJpvaeu67J+X0Li9Ag71K4HgMz/zMyk5/K//9b8mxevjHve4 f/JP/olbVGFEnJDPetazqKXwYz/2YyDuW77lW9jJ+fyP/uiPKPT+WZ/1WSUQ3X6y+RZWmDyjBGO0 y9wVj7VWFn8KTOQ2bhrzoa6mmuPPKeG8RbJZEF2ycced++g8Sg0zHJLhaHnQ5fZoW2xp63bU0J7O L1EseF7rvenhziOus43EPaxEQ7BvlhAVphPeAqvsplfyqwcb2sOseJhDS+9hJa74nG7Ra+KjjLcX IfKxHRicXVgYd6/q7sNasuYqJxZe9OiA2HWj8/nR0RFkLR3OVra/6F2wf6y0hpfagwHUpXVW/ozN fJpU6b55mytgfgtMX62PYEOnoVsQu246MYnPzs/JjVc6+fmIJU6ACflw5ZIpNWYZKutA8RraSmAQ 0Oe3j/axcecHjuwMURzb+0c15hcPKNhM2WXErkMFcMKEkKC0uFa2p9YMqRSW7SrLjYONeyWlSssN 1loGYN0y5F1EQdwD2HbldeUrGz7klcsVC6YvMEs5m3/7b/8tkSHcX//1X//193//93/605/+vOc9 L0Dgew7FzBDfCG7w5csGoJkn9S5XwuQ0Dvvh8i/+lusroYe17b0xxs3osoxetP9n/0Zua/uozPFx 52FEZbtfg9Tl9up2PWFCe/qzm/dJdx8AX4nhzXYf97AGqxlblBBVySub2jsOl5boSmC0APILwQX8 RH9kPUXdVrKBgm0ixK6klOHHk8QkQStL1BqpWurfklCvRWHGZvYOjWTlz4Nk1vUfeNtXyrrpxEPq Ao5nHi4+GxaXf7Whc75avuW7sn1WfSlas4br8hMoGzJZbqaszpZF1lpPWZt7Mcxj3ewsUfOKyK4V C9ZORd7PMiZLHM4l20QrB8lVfNuIe8jygyeHoq+Ah4pi6M6EamzYD3mNb7kO+7mf+7n8gnbwOZ/z OdSZRGqzb/yH//AffuM3fsNLl7G1/vZv/zYVy+677z4ARVhTIsfq2zZ+6Zd+iV8+7dM+DXs3hof9 JjmmM2sFlkM/gq1ZEXbZv9li98bGS8IaDDUT9PQVqV2yCaooorKby0qi0lmkMRoMQmoUO58rQYed zbaACskp5AYbtwK9F9H4kFFGHqcnQGJoK8b56Rxk+fg1vOXPI+jaC1GyGPzcFKMeDAbgdTiYKI5b FoPcGhOzDkgZEVnYQcNqT0bUBiDBEAVw873aU40HDmAKWCe2lHcCQzmIIv+GzjQOu9Fx1m7oKJgD xNTYkv3ArjO4ssQrhsxp4a8E4FktHDoITwQDbkNUJN9i7lYGURYdWfnBswpEFDOfyGQf+sPuQZGa rToZNXmFPqntMhz0l6VtJnc49CjRuFmu7BisgeIkNgawHAYmLqHsjm57L+5X6bwfpfcTNiyfhhBo 0wSGmFKeGCSMjpHaU3gYUqzmZORTlZmb8Ls8mJlWpNlydqUHDkBzXdJdcIIDrx7gT1N4d7apY5CP v0RZiqtDKk+xub0tW6XnjXEyqWJuq6naNHkHfqPHKStkUW6bisDRdIqU3SKtK0QlsYmLJEIs1CDj 6jmkqW03Iav7AzApkIQl3sPEOeEsZXlXuHFHiiVGRyzQ52w4XkdZhhtNJ8pvbjmuBawtqjzAEI5W uh6F62GtnnkEzl6cfdOzPYUnLElxMpgkJrLopo4pCzX9JiQ9i0OMt0LYqnDrbBaNwDGdSWmvNfdb e5fiKgv1Wf0wYkNp0EmgRsddxF0OHB2enJ7wLakAmgfVec1ihgwad6qpBDhYD9ScxCrypje9iZMC iUc++7M/G3qgg//sz/6sC25m8vu///s/+IM/+PVf//XYRn7lV36F0pR8xQT+5E/+BCX/Ez7hE9xL QPHpbCYSstRGJE1iDGHxd1NfJQwGIwwg2ho3+srpiSIdLBIae/610iOPJXxsttXxWU9Y3iV5TdZK zUt2GP2J03CqYqZdD1SIOy2CLlNtfXLe5y4JXLC8gZfLPrGcqGZLtwtQo85VllQFGXSAQNCcXmxR JaS8Vxfaa3dRARjJX2CAHws8XdRsMiFrcdwmv2qs8AK64lMO2zaI3ffsgGvu9LvQZ0gWKgI0VB6J GHfRv2Uuok4KDE55TBcx6/nA4tvZV7hO5bvo8gE8o6xGHZ712PBqKsETKFu8JKvPTTYNxiqC3FKd 6OLoBVTIv42lYDCmzKtxiEn86ClQFvcUPGDyTsPAOaYql/r3HlRiYTzb2i6tgiLjak6KKsL33uSa EhtkRCnlsLVTRnhcxxJvu8bHRNdRlvfGswmXSnZ3soDlMv/r9rqzEezUOz3vHshaFbfiy1jzQgCD oPlgpKXrl6pUrWYtbUUYLpd1WlZSwuhSZEP1Zh4OZjXqDZCVbOChu/KaCpS9GNKnWpaXTFncUDxe ndA4EgP57+XGs9NeHTOsV8BhCy9nUrMV4AthrOIX1FJZzNyqU0ldazZmK67Db2D/RXbAVCMLQLCx vNM7vdP//J//81WvetW7vMu7YK3+gR/4gZ/+6Z9+0pOeFG/dSFfUB6pNom4jqd3zy+6Elcctg+5a QVKjQfBjQgsVrslqXPvD3k6hFitiLfcuv7Ma1//QD/xNeTS1YdkstaSTBlKVrqy2NEhExDg8/GgX Kb0C5203wTIVTfOvaBN+ikMwlyY5YEcATPqv0O2i/1LnlGaEAwqgRp0DEnno+ba1NW9voUcjX5Zm VGgPfjS1LarVWFmdImLNWbt4WNXQyCMK9Cl4KBEiRwvwo9YR7KoirYJnGQzDg7dX4e2J9sYlyhaA 325tddsU4iLYuUGVNZ/pBsq2lNXTqnYLsRqrDK1TtkECUGTZaDIFkoiyxc7hDZsLTChdS7/HZC1P UGNxAXIyRtNW5bAl4hYgF2+jeplSIiLqOtgSM8DMDf9RKSKoVph7ERg10AmS06C6LVKKz5cp6zE2 mTt3A2Wb3OpkDcy0WFbzP5+rhKl+IMFkzNFExdWVtTb7UXnJiBY2owYMoDuHTJBuV63ExXyJ7YG1 rKVhqSwNrAhcS2u/saXVjSEu4sylBZtRVucGXtHQmyjL60xfa3aB//ULvN3sET3ErWw4rdMS00aQ ZMBLTAkDcr77egk/NObswiwuKbVjid74wi/8QlwilfHRiGYeigVTCPjd3/3dP/RDP5RfkM7v8z7v 8wEf8AEh2AURgHR+7/d+73vuuYcP3/d935cCwToFt1po6JzyEP3lDQUVjyNSQulP7WAUq0ysKErp Ji4NJmQFs1uJlB+tDviVTsE+CgESHjRJLl8sq9srXtXhXwWmKntldKojNneTIv+l4CgOoDrk2b0x KVG0AAB3NxOuNUllIo+oPA3rtaygz6BvTqYI7koMZN3CA1XdilswQBGkk+A/kDbK2SiBBHbOqKXc qQHUaX8ItyQBIHVVu2wSBti50orwOmVTQp6lHFK1K6FUjU4Zsxr1OVNANWuhbHCVjbVSCHtNWFx+ zNJ91AR0obwgWyu5RXyF0Yxu0+bVJl7XDlKVT3YyLFrkoTV5hJfN9NW92S3fl7zkJammEu/Rt25+ 8SBNZwjZhqLrGxCANh69yOO/3Lx5E8FNPMBTn/pUj5smi6RS+3re++kUL7lRN8sQ5nbC/NCkQwdN iehgIN6VS92KcOQxsQacywc7v5LPisYWZil7CdJLOMpK8arVlIKEiuOWlkluXw4FdkLPTmdknMCp lLXn41kd65r6duxbEFs8orym8FD+OUHX1IZQruq8VkOMH17t1Ej4G4Dn/KqEWDKume1GpmFT1HwI /qsDvB1L+/0eEQXXr12TqTQLDVR4t7QPm7vscSjazS2sxnRC5k9dzHVLdYZSzsSyPgcW8agmj/0Q wWSsyOIOPfxGkbBeHdTqg2Jwx5JKiQoUPDeJaG9YzL0+mEFZSW03csvKLPmRERQTczY1Pw/L9DrD YwEjcAdHheFlDCgSNCcuYPTGQ6K+FZUm0OQUUDChoSJ3eehoqE2ojo27rxqSammQcgBjuXuJ2+wD mVL1pScYKlKWj9EwM7TaABPifesWAu+VT7OOM1zCKWihwSAAZDdu3gD/O7u7GLKpAzrm4kjAu1kO QJJbqDyW/+rOvjlLnJPh+QWlVGu13RiRq0ZRWCq9CGllrnc0GqUwE4fu/Yjsi9QpSwJ1M9TkxRTn yl7gthXTHOqj8x5s39re1loALZYdPSwKeW4A1wKTdYzWZWPKPiwiqT1EPRAalHp9DD6UMbjZkgku pqxxrDM50J4MekZOWZP4VxS2JelCgAZaTpMpuZplq+n3lWHfl4BGre00t00Dy1FnsYret8bxrxa4 UmnoBWVh7EZr0L84v+ix1g6uHJqKqHxB/ors7jC5CxAzWJEHuN1kTsqyjSOHyqpxnhZLXK6an6AR ukLI/U5eLNhkyK0bN+V+62xbkfRLPJe2cV+i7zVNCT7BWfSxH/ux2rHdlKmSmhleJaHyte2cJHwF 8WLhzHYNTXG/zLmOuZlvXUFx5gm/q5qGHG5yR3h8sPcXNRvZJ2JNbFAj3cTxPdn4VONqdwrtoQ03 TSQr5XLkQAoDaeFmQCqnflZ03F6h2ihyl0VnxYLZHbYoLqJeMwjn25SODcBb0VsNCgRe3ZiDMOzu otj+QaJ5JMl0zLIddLa72XDGWB6OvkAXVpcWNwLoAVAphNtwH04meZlLMSmVNFN7XIJoo2Wry1lc LzLZHHgDTiYoHZklv8xXZ1WeHV3MXXlUJAGl7JnTNUxEiOWUmykf3h4RYcd5KTvyJFO4e4mgEXEn Xs45sy5LmhWEl9VnkfHLDKwck1laul5hDMJrgtx+10dZ+StCX8jhxRwRVQ27YyLc2zJXvZWYzaYs Xk1MMctiYEsH5kuWURvkvNV+n7EifeDdUWCViUKGGLOPGTq8BC1gmqSSaFIyS26ct6llkYNopWZV nTfjSSwDTWQJSomUaPO7a8MOwohCycUsUS6vnb6+6ApLzKwNkCMDHjBYCGyJ7nI0i3x2XnRKmUjV zG2n57/MKxe9QubEuCAbgrcxBdhtCaGdFaK4bzQgn7jToEBodnvIJilti104zndXdWvk4D16Yr2g rpKzV4VKMkqCfBMX3rOtKS0Z2ECsJZUT3SusKRhUNSWi9vAzi459Bnq0t1VRhGo4tp8vKBUEghQI tE8WthaBZIZ2J4fPiKsgcNUH0lrzcYE2KIK8fnGuPOkKXUgwCeTIMszl4YCX07jjLi71O+z76le/ +rWvfS03J0svXgwHyKQO/vSqhy337OLicC8pmcDpyakiKsyhv/kBALhkLyGJPhcXIW1K6VVGJN8/ xRlS0jFTRgDZtZtQyYFu2asPr19Lqc9wMeixCFLmhXxBM8KoVYUqiQbUKEphVbakwXHvfG+7k1Sn Fa2+NziwOO7K5/jibL+7U5mEHpoenZ2oikFV8TZG5CDDmtjBNVf1IEyPzk+vpxVSuDg9I3MWp5Oq XnVXlppQV9OKhFDJATukZEHV41c3UzKQUL4OOYc+W9WlNq6zG7cP7kuqenHO+ayOZlndLTJOpSQS Vjd6/MWov9fdQSuphPaEgtEHB5Vl3uiHQ+pwPErMw9M/v+js7RR8wWtA6VFIYTYt1bJAnlP+zY8H l3qC4E6yqV2q65WN2V6wk/Cs/DaxTKp2taXgzbWwJdcgpjBgirGMgaj/IvdF2oMZNLE8gvSRtBz2 jJwbBKqBkLKfYFukoxBuX91pY4s8ftXNshYyHSc2zo4jCa3jincbm9eJeU9ErPxsiboPnrYEd4gD RlmZxHTYOown2OK9W/kD0/LwpCcCAgNsHgnoV5Mkz431JY9AGgukr25WK2SVEp/wwANR7OvGF9Jl i0SBzhwJ4+tYv8xaWbRiyvtr2qQ6J9+GIbJXb9++jSHv3d7t3dwmjj0OOcg2O8REJDOuPMXZHVpP +6vjjo6K/qHKSBKvMptw5uJFibD8ka3An/zWLe/1B33LhqPDLItHB9KoPQkcbQi9gNkUbQszgWIA sLfKQFW4n+rXW3kbAORPb7U9AH0x7HJ70pvMMFboCztYqox66H8Bukw/dMs5WUf3bAqqLRnPSc5u Rxpu996QrCnZnSafkL5aIMCskJZRYzgbmxFW9oT4crJf6o0fj8zVcd7eNWvm4hUwL8htFLCmbC0c PO3hOClbScCspRXIKEtlZ4y6LFurIrj4sbvg4VF+iAnbITUfJxz+3RkQfV/+lfY9dWsVAs2NwOqJ +6crP6FDxwF0t2DEgHk7f8eja3h6GE0wByuUPkYmvxenJrrgIRhy7YBTsOEkpqyAiR6EFhWrPTzf CCJuh+UCJ4jZ/EO6pVbvbNpptKzL7ClRlsbgXzGx+d5ZoKxRNaZs4FtQqnE8lDCnBQwdU5Z5kWYb EtigAreEes/Dzb8YoAjPViC93L8L0uL1ivu3dScSyNpj/C+T0PoHOaDVjbEOQBhG5eEjaA1FMnPb MgRXsqvkywpal7o2zpStZTBB05J5qrRml9ujyPOWBYxnlIyXVQw4KEI3RyBr9RlIAOByY7HMnbIs Qyxk+HLNVuNrBXL0Bv3FBYLLyFZ3h1zaOXmZIQptWZgvetGLsHF/2Id9mOrazWs3+ieGzyw4AHv0 YhvHygeNsLQi0Cz+kdl6Ah1Zupn5bL4TV/AyqWf7u+JD+I3jPM5JXHMycKv5vNtdhGljse7XZ20M bviFbZFriNxfJ5cU5sTojiSyCi6nL0yGnmTK5bhrEmZAKwRrI92HcrlpnUubtmsFAR0KFa2rGqk/ /IJcZgQ3R5r13zyS4bFEOVY0TwZohuZectyhr8nQIUHyU67FiPMVXqrAueIVmMZoGsfzMq7EpieZ ms+RSs29KKSdEOf+YOGUr9e2MQ+a25kRWflAEuv1jNqbQCnNzKyrynAUR/tiiywVUrBtQ4GLhqsG 9q11mgy99pF15hdUG5tgoQy0VUAnIZ0Nrco+7qX0h0/a8oAvaCHjOhmpWi1HrG5mR7CKE4onoRHr E/uqLeJlygIXlI3opmQGskfnPnx2BuqexY/2HYIp3Hkzmx/gwooAKFEWWym+EzNki1fQ4zL/sDMS CCRyP8edvHm5K1R98vl2gxs6i9Gh9Qg/Z4YN/iO2tPuTkkRK1FWIamcxqj6JRRSI31Q8fpFkis1+ gHk/P8A7bwC/b5zyFtQaHfdmr3zwJCNhszv0egGiWLxAtkYQqe6Lkh5g3GJ0z/ub17bjNcXVp/5A ToCtLeQAoEJZoA6EL1HWJYYrIooRsCcsQ1nCLTpgATiqxnzKjNiLfO3zp/m4I+zaxuc6BGHkXK3C fRKC3LA9wBUoQOmFAL3rO23jZv2Qj5s8J3/37/7dEuH6rHOYplltBQMxJ8Pe4Xa1IZIh+kqFrKCK dawSPj8+P4O9ruxUFwseKFnJINEKdvP85NrOfmC+DWBQgBj6plSqpZPT28f7V6lSWm3jOufMUa/t bldXqiXOB+mZkugcO8np+cW1NFPs6bC30+ooiqPqQdnhLtxBWirko/75lc5OfFFtZfdwy83TI0ow s8dXjU9NW3xNXGSr9oiwGd/und27l2SO535dp9P1E9Lmh33jbNC7Sr3mhOf2xSlW/pRikuk27t4I lXeSUlYYAM9vHSXm4+Y4yxLgJFE5LcTc8bB3taNsjpuf4WR82r843N0n+quqbe3W8RElmFNshiwB jmuJ/pvbJyeHZNuvikkFPDDAxrxfdKFJs+z3U6AqTfBO27gZ3ssFLCOa7Yi7IpUEUAMU7Vq1O8K7 6hLoGRSAqkVDmEcKANohE3YC72qvgQKb0iuB+Qr+SGpK4gF0l6QEy9IuFZ2W8LCtbk7yFfpooDcl +MS8PRpcGl0Vw9NJkO/erdVtq7abKskq0G5Viwz1qaSMScCyVvehbNpDuWpP6OhGgg0vMfpus3qD 8R52ttq6XJTwePbBhIY1lkCKHNRc8hDDlG7bGOTTQEUz7aY5Okhh0eEqYoLUBkJc00mYsugpxaol PGAAhvHD2WayirXqze7S6jZTQyJcqwG6Q1ElTO/FL36x5+N2K55ffA9AhZzFK8HklVKu4U03huyq MRfZt626koLSCBDrtHV2tnMyxCE5N5ue7gk2mxhw/JAehi4d/4GWNkqQYs9yPu7S8tCZy2Jdefya aDxZUZ2g9Xzu/MKB2pOD+91FHLAq+KTTfhbB1pxaaBbdjghjHnXvPYzzcTtUcYdMxI05PnrpZg2d 69joUXq2CB1aL0gGJAQhxOzoCd4CchS6Z4mxPFrfwQ7fbqaUzEoWEeiPPBCcOkcK4pbxgXMEh39u 96wRcYARF+vzKwKlHNOODQ9tDPm4A3glo1YgqOMEusSYLFHKseq4ctyaQSaDVQdqookxtuSz46x9 asn5MNkp+AzdBb7QvfEM8wAPnB5H7zHXHOZizMeUMnTpRce/H+dLlpyYUk5Z79bzcfsv6yhF51jk 6NPxqQN+ZKwQq2ABVlSrkMD8IdbePlHn+fQJ68zj4XyIZTbbcA+I0TkchBmtGN040w16svIrV0mB S0uUpYEzvycf5a1SrGSMChYasYCKJJVXA9zKmBf5HucK2yx6pD3/UlizLOHSmmJot7/x0KyUHZA4 LjeNJm6rgWp32lQCfK+x55M/+ZOhKDx0qQ1nuX1FD9zS6FEWr6M7xIq3nSuYMxLcpUIKWb6YHD3L +4obQFcK7pU7DbPz5W3WYLm8Vu+b9qn7BlkncLYaa41khRRYqRZ6bBnpWC+WWLZ5dRfb+boOHbHx 6KU9svSi7yuZjTvPpr8ZWmdZn1dJ49hMl0xwR3LZJHbmURMT64b0Jk3EhXUYPayWmLM3CO4SwPzp 0tOFQig4sAG3Di0NfOHF05eVObp8wLcnxyc48ejWZRbSLg6gcvM3vTG0L4p1pSwdHqesH1tT+Aos eZ6pUAMkFhPLlArag0C1J+DBCeeuEd8D+KWwZS4VUij1X7nkXbB6n6XR47m7CPZCCjGEpdM8f/rG Q0sn8YY1qEh/bhTKJZoVC/aNP0wfek+LIWJsM56y2NdsaXRnUd/m43kFOr7thRTukMYNEskE+/rX v/4f/IN/UFoVnu0spTAgqAdfpWTQ69bY6MYxV6gbe9UWXgyRECnFcs3uDbQptmCgSi92R59QVz7b qoflcvEXD+486t6Ui+wwB/MqlblYOQJYZdFeu3atanype/hVUlrSFd0mFgZUCO1F/+Ceq5UA0IAE Z+Bqg/rmncAtt27domVlOgcH1dWiSgDAAI1TYt7V7a3jzm6X+rOV3XqO6cRu4VjWS4rVzjJxbqXw 9iWYcDY/4TLB/fcEx+aG2aXXnETMwVopGGAZQgKWYSUPABg8wPRT0jmQFJ50hok1JyEB3aZon+jm sGIp0TnkBuEpDrASbu+0jZu9EVZbKXNdfavkbN91U0jlXTW5rpbWrR97UwDwrTulJW02G3/iTpSP O810Li/uzm6lXy7DQFptRhqHA3Ll1JYNLxtecb24sk8BAGKTo5hdx6ns1tW3RHol9smgl+IBu16a ZMqk2xTdJVA2BQNaBfZU4sp5IHEVYOlRKto0y3U6YoO6XQmtkyARA+nLUPp7mlPKV3clnN5g5eou nVMTu4qb3QmN241rXHknYwmJYf2MyRHGZbEboUpc6wercLzy8yn/8pZbi0qHvjClbJ1w5jm6aJK4 q0ssmiJIMSbZ5Wg1lAXDTBluY0IrgQ9KJrMYR37IojHaFtCixJVO3HwVr08HG13DD1NuNok7jHnO UUEDVww1awtfNTuorKFm+NBtYH7BMzA6uWhe24+zEZXOlQ5MsDXHtjyHodTej5OoAK7yu0luefoO G9+iKYArH8X5rzT38CHdMv0Si5fv5HiQ/pBA6nF3b9eM+puEMvOKK+CUMO9guwGEX6AsoAJDWCfL lOIrGvjpBCZcPvOWFpVjwHXzkhEM2IlWi1nx9OiICyDbXZI1Z3e4Y8kQ4zCwVsFAUbRXMJzTDsQ6 a5VgK7EZdPRky16eUWxfrKQaowUG4PHK5SspK1+cmUroinuDECsGQEZhscICIu/cXVPOAzGflCDn Kz/OhlDXZcr63JkUcC6fvEtyHDK5NQluYWW5ZXzdGrQL9cotDBW8XFEZVHbf6HoOYACqe6oCumLC xTgM8i2Y9fgWhZ326a7jAHnQuC9xAYfxXIcKBiDfz5cFgVPUEedSDKBv3LgB7ih1xregnvm4dW+Z U/kEDPKv41qS17w3PnO3HAUm9m8dhsVDJuixCSBdkLAcWHZZgDBYHkUf504e+ncPmzPrysf9Ub4q HAb/058AZHjXPUJBRIbphPbxWP5heFeik+w/Nn2L6FdqCKUTZs0Q7Q3WBkNuECPXwysAEMPjCHHE Ov+VJhW3d+B9aiCBX9wkF7/itAhwOrTeZhnz3oN/5W0Kk+VP0mnltzbs5owudDgAIafKOkKIdjlu w9DLEwxuKOeTDZRy434gKI3jyfpXMTAxGwScxKwgQ2g+O96UdmJJtXz31RWW6I6MM0lMrNJwJcr6 QO6c9KeEqGXgnQrMK8w0vBJTyvEfRNtKysrFwu0AmM0S6AM7u5TfkNGUdRem8PiIDqcTaxngGBg5 5HOvycrGYe4ay+RyTNkS6pTcKnIJ8PsGysotaVHnNg2KoFgQkK8+/9HdogW2XSD4dPzf5TXlH/rn LscdJMetF3pkCqmnnJzi9HC5Czi8ABeiMmPueOihh9jEKDVJRYU/+7M/e8ITnoBlymcCKJggsWW/ 67u+K/oOY5D6FVjZW7iAQ66ST//0Tw9s57+E0oilz5f/pB/2z0Qb9+TWKeq2Et5XPStrTq58iem4 xl3Vpb5HKUDdSznQ0ScETjGw0u3gzTfbD1xL6daNaMsa9zLwpZqTG2YHnG5eTMEAaix8ksKaMi/2 BztpuUq4ggsPVHYLt8CKgJqCK48sSrGGw+de8DAFA4PTcwzcKTlgQSwwJLIWAABqig2E9cK8SgbW dbztAUWV8wKxxHHv31PtERG7mm8wxRIIBhJt3JdytCCFwGoltwDqeEDM1mDnShJlARWsprAWGABj JYvCnbNxI7iRL5S/+biP+7gv+IIvwNP4tKc97fM///MpdhMHIYGgN77xjd/0Td+EcKdMMN8GwQHx VhqGfDuqZBdvkGi2pqXdskzq1U8GKU1deUlpKVDttJHYeEN1ylIP29vdRAjSEXupnT9lDWTESsaV AgMTrhRdtlsiOlghSSS4HBMmUkAm5kSGgVUSWxpvpy6ZdDdDOgcqeMbTvSY8TCpxdacvLnDlGnTC +DpHJi5D48EkyjJzq0iVJF/WESsJfetnmAQor6NooLz86q/+6h//8R8//vGPR90GI2wjFFJwTgqL iqVCecmf/Mmf/IVf+AX3DvFtiNxwxVz7m/JTYBIw7JtZ1yxNflch+yV8IguUslkoSwa/UHrR31r9 47H0niuZC9Lc+1Hub+s5f0OhgUoQkp0SPINdOLgtdUs6TsGpe8ZeP8wzT+Q/gjgGxvrSlVw7Z61o HwOvpM/KAGlWEUu5wJFUpo6sf2VVBTlcNmYuKAUTxY0tpm8vxsBoROtKt4OV46cImyUL9UNcOMwG oxY9k4ylgFtLc6GM3/rRtV7LuqCkEZqET7BAC9WZNOBJWpmvmRJZeSP8qGQXCYtJcLDFL+Sh2ExZ CEH4MkN4oJXltCiwgY6oylAgFCm9z7ITKSAkm5rg120ON1yUKFtmM/EI3YajcYxJZZ+Ip8atuYve sNdnXi7lZKyLHjcguKmEBpngXvDoSsqK95TW2Myypbk75mPKBsGdjVKk1IKyeAXMRawpqFuBVehf qJEJT2mqLVnudGSTiudbXAIqxoZBwyrw2kAlPikuXlnDdZVBcZlG3Fgg+DTDFNg2QgXehWSLsQFc XhCRxeV5tMX2xTVboiwSQ8mct8ifLXqx1ugh/BSBR9ghiJTe1hdCTsSAeU9a4/l9JDd8PyhSlh48 1fhb91zOOYn6/EM/9ENYSP7xP/7H7tH6wz/8wx/90R9FRodiwb/+67/+r/7Vv6JEjk+DUsKcATmw PPe5z+WXZzzjGZwyYP09qmeajcqMQbqoYtJ/MZGopKz2N1YgV1IlDrgj0G57Ovk1czZDkoUD+4aP a08VjKINEqE2GapYMEZ78ivqLMAKz/vjv+RWjjwt2t6zzYlOZipra/utv+C5twMwbsay0qL6TIme 8FBF0NZ1D2MBTJaBxIFRzjMskvhy8v5kIVW9TSQq/1Pdrr1OZ6HyeOmWeO+3vMzKnQQjIg491Vbe nTxM241JrjC56c0DePld65zyVUoPHj9R7zp4Dfgbp6OMjB5TbBUwnDXRG5vUMjbSOmVLZJXoj/LC cIeE3sgIRmOVBmi3yai3XpWpSzSKqNn/GSTbaXJ4bUbKs8EHFxe9PRye0aNcyQu2USoV27yz9Nua 12ZKSRoZYY3cAAEeYsqSoSPoogB5dn4Gq3PlnWbOk4V0+5kd1ZeBtkArFrzgwiJllc+aBSVdx+oM 5Mps1l5aCtX1cmHgtk06dtkNwtqkOmL7L6iJERfW66R5oSkLgXcZyJZOPhveI2uQrgs5EyoNk3LA 5tBK6kV98zHElKg1jcczERFst46yvAplrYSHHleog5KnNWb5v/gQ8LxY8H6xjIN8JwtCL/K0eGJ1 VTopUqq0Bj3BmxcL1iLMjkoZbs2MH3yb6nE4tNRJZqTWpND8olwlWmV6kNxmjm9sdblAmosLmt+6 fRvFbnt/lzqrC4oniHBGxFaJyL2E4OYdzIuYQZ75zGe+//u/P8G88CI2E4oF/9iP/VgoFkyN4O/9 3u+luPtv/MZvINC/7/u+j6+YHsWC+eWjPuqjMvDC7VIv37J07CjmbLFgA9YYnEe2VDy8Ehlrjypc ncVFDa0QIkb1wkUJLTlTf3SKIRt9j5uBGDgXgtv29xIWISGDznAdqnhdiQGXTSKANqA6pbcU40Ti QqI/4jFOH6Y2tq0yi9rnJRfyRllSJQvAmPQHpL8oHD+XV4OfWYZcuLRSlkXwlsWHND7f5JQfb3Gz MRs/7p+TytnF1l4nT5aSbV2F6QT/O/NiTkXwzFsai1ITmqMxpXLrO7Ydbs6WSedwjpde9WLFJeTz IZS1w8b4YtBCuMQFrlwvKzxGWfrkBTaRDZTSJmyMgSJGtWLbkst2gBh4ShGdXFCWMLt0J+KWE/2G /V4KpsryFeqmrziM64V5vT8WWdmcSpS1+hzhsY3TCnNbzYdNlIUE0/mE+i+qimeYzaXMojsyZKnW kGklZAfcVrrUhbZiN8VWUBYe0H7oNZLW65e+lFlcVkhDPFKirEEkgxLU5JDWH7S6lMyOZltmGxuL ybAM4RZVKIm37OIadF4ihRb6WZdYEZlCCjhYZrNhWN0Gw1JKWE9yIOY2b2ehhqJhG9WTqiA6kpT4 ceOfQXCnmkoMCQpxw+VFJUmk9jd8wzdQzua7v/u73/M93zOMxS7DlohRxWPmHv3oR7sxxLW5go/C a5JSf1ZlcObLZYJV3zP+oTgQxY8wkiANVf3Timev+aFWyHA0Zv/0SqacrOKqpqpWx4cU+oT7bVUr y7bXM81+lnvWcOwHHBRXFB5dBoP6s4AKF3o5WtXVzX+8amr4QQSw3qCeigV7UVHVGI1/sqqsnAu2 20TOqVhwoYdSFVT/tjVRHMBM4xbBEzaix31crsuoqAfx1KXpxFVWt9COBypenLUBLUVCuECxn+Gg L74sFvPNaiIvpi+ccy1NirMXIF5PVi9li8qvolJSAK2q7FKxYFGWb1V4m1PvOCKrFf8t9y/4ZdlB Cm2m1DblayHlFskSVEmSyr8OcPxT4FjyME5kg/AqsV6JuNh+ATwsDQAl8Mr1bYUcdgJwpQPlMmUL hNWFeNdSFfu1mbLUViZnMvlyUV8ygi5RFlRbxRY4EyFA3S6VJ44qBa+krBW5MnG8BO3yKhj0e4vS ySXKWu1gbYFWflfaLCrwOsz7ovMy0FxJbZHT0mtbr1mDVsWY9aLU/I4Bp5S391+KbKMNNCZWiQ2s 2LFziHY7iFVc8pRmHqp+7uWkdizSLyG42b0J5kNe406Fcp/92Z/9zd/8zd/4jd/4rGc9y29wasuc TgkjoQAxnsy/83f+DjEkHsboZx+/gFt6sEVhAUnbdTgPJbbkjoC4OKVbbHVWBi3huYwPTQRL6NLV gvVmn3IXyX4paQ2JWbbcrJECrDSPjVfS407yupnVHdtJOQkA7TFlJX5d/5BV+a+rhxcNMjJUN1bZ q1QlSVGbiWuz6qQRA6ZycGndutumelJK4GPnwoSHoTP7UkJjcVYaCdJ5gPOp4noTRte6Yhmm4UqF 2RKqD/uwppUnQaDpL7WUhVAZl5N6WNnoEqYSf1+WzTzs138vLXs/moUzmh/D4Z7nP//52LiJRcFG o+hvxfOawLb3sW9ahmdDiowFOnkFyWel5XTuExdSFS9PDFaooWdve8wsGSrxcfALuqpjWCPmnUv6 bMm2i2THzTLo9XXhxWpgakbzGcm42/JW6YXszg7OCnVnItaCkQW4VfdQsTveta8cYFm4lJrYzpUO lbe3dYEa3MYuFsrvyulo8zLPJ8SEKa2uQvbw5nabJEHyxXnAdreNjTtbDWBJhjT7K0OXmQhpTp9m qsuaBlwNeCPnGLdmZqdpD70HwXnKbLcFkB1F51TDo8oycJ9JNQ9bMJ5IJxu3TsnZ3LE6WOFA+YI4 SisrUFaZUC099YqBG4iLLwodFqxBIzV2r3KO+fh3XuzjuJUwNC+xn+qX2B8TrFziW/X+BZkzRaSs Pi5KkmplRtAapcyLoENPoGwwl3qhGf8TU8MYq77hxDMQOZjBqCCVnTTuwGeEBj5FGaqOJgTngF+j WHDupjTiYni1KouyrQoh865qDeevi7ILb4OAtAAJKMvUzLSqd2P8DFBvV1HWNvt6cyYzdMC8UuJQ YtHnYDsBXsHsCqsIh8VZUw185cWCZazzNFszigXvSiznjxZsDryjVC2tYi/udzhG6I0ou1gvZi1T fQxfg6LZCrJqkaj+tUznOEWUi9yJYAzTbbYBwBlbdv7MaS4q6A9nqGh0QJIcCKLTiqdIi7eiB4Gu GZeaTXXxukIb8OHL0ySzPAKnLudHJqBlEtMidMGoZVirx/IEkI6PjnhROQY5vF7meWts3Jfpv9wW 6KnaQBg4+bjFLpas3axAclO7u88XoGREjoGCCc180yT1397tsigzPcLxHkRy/jv8M8RgBwuQas7K eBt6s8Ymg7LbjEBCxAtLCw+SWdBUWlfJ1INoNIC0V6nys0JatvP0dQxrJWKNyyJInD1GFwOo4gFG /qW4ykyNWet8n8JiiK8HoWUyQbMpaUkcdLMAhKnm1dnfsbpNQW74cgxau+0uRNYMRrjJmVk+TjZ9 CxcoPO7FIpDc5+HvZ8RAF5Y3LGdwzItc29vNWtp+k08nf0XTNHsmATBWkEvuuzCiLekC1fgOowq+ YtJEmP99IQqXicvqHY4pkcE274jVIg39ZXiWjVu75vHJyT7BtnBLtp6zMvahW0O1yA2uEF4tzshF XipQyuzbCFPqD5A8XVMKyz7HloXxZJ8jWHv44TFwQQLryPbnCPcSWJmjk+1TYdRcyAxecfdshCGs W8fjhAh9lU23m5MRwKovED3Q1MOoPYg4o2z+irjX9ovsDe64DUftHbs56RxY4mqD1neOgSou7lrE zmLEbEvIiSHFHEFLbQeUG7manC0CXxV4gJ6VDnwyseqUJQZxjGbSmOmoPufF+cFeFnAt4rLrszeE leaixdbl8Jwb1Mp+YbPKR7fJ5RyeIYDpU2IK8bIQwBF6s5WZDzFCJ9jW6s4oWzxVeOe+ihWQSvqw 4Ha29UL2MShupfWSrAKBqndacGM/RXAT4s2V96LQqJ2RILFe2+lW5/eBEc+OT65cu1rqYeWffe4+ tFvQrLIxVX1pk1IcQFlVh8Pd/eqSC3R4cXre3UPCVh8/6RStmaq2laDS4PTG7f3rhykBp6P+AJ7e TigOgGLImkm5VMLG1TvvJVb1vUW5ZMoYJOTv5mLTqD/cS7v78ODtW/ccXKm8fsKquXl8e6fb3U0o A82pC/0p8QLOSe/8ai41NpPs9Pik0+1YNfSKh/3gotenunRVQ33fPzvHNeeRM5ufSxRS4HBABZ+E csnIo4tbx3tpGcEoZ45I9Xvkmx8wcOv4+L5r1TWIEdyUgT7cO2BPrOq1dg4J9vdcid78sAwHw9F+ WjWP89PT3f395dPe8hCU4GEDK5VJYbn1+r3EpENxn3dUcENp3JJ//ud/zjVLNG7fDO3etHZhlE3f Y7MDTQ4mmmysP8hgbdFbfgfHLTArHx36xhOYG5mFIu++7/g8zbioAaovZ9E8p+dnlD7B/hCGs1Dq rH/fp913ZwF545ClM4zuV7/Dn7yi/BujcRbctHSxNQYeaFXlfaacoh65pZzh8czxSxNkan1Kbl6c 73Eb0A6ePqLFgix0P+lEZlMCZotXk7GojMkIcbREL+MV18t8prHKX3IVEJuMrmdRW5nRLEQXaCD+ bwTiv5yoLUdHIUDHjWBB9bFL75a+3IwqMgLoDFs6EmTgiltk454pw7WOLn4YLfQvO5UCsAQDlL16 5dDMEdmjwE2PyTUlzkwUuqPBxsHqchLETFWglEUtE2BMXhU0JQjn8ZsFJsTulEPPV1zdBJlZt7J1 UP1uQSlp5zrMydaF+4dutR+Y9cmfEjBulgz+RllLNlLWNW76YUNyTJVwG/cvcWzZdfxDX51+fsjQ xbzMqqY469EIbZFwwMAnZmgqJJ4ya4FlBALVdhnNTazLj7GNVXytzTsqV2TyoRBiq5c0g9lMCTMk 9frXD6XABfDgoRA65lYaj3BFKeGVOAO+A1Bagx5nydTQ9hS/axweQI2Bd/qRad1vBfualdV0aWL0 CSsOdQVMRemCiACqvsyzWTaClThZ9+EdFdyG9BkR329+85uf/vSnaz6QoLkFj2fHFSQ7yfwiTLF2 F3Hc9rqcnH6IsyOIsuGsmxxm1t6QlDGSsDjTdWo2U0mOWrA8bmBTG5n/stnv9bQIFbGkHvmHI5Bs UvnDeCyrrJDCVHLNsydn31vIamlLl3XSIvCtpqplcw/gotd0CKfL/67XkBrgxA3u/IM4GZ/3Q3uG EdsZEnx5dw/247L0usUEc+RHVBlVm6qKCXguXgt6AcP1lSUmzC7E7fq9VkZodym9GNarWD8CVsNo d7GSMT5KvP4R1j0c5tnBXFlJ4hTyNMbSGos63VGQJVRUBU6vo7iWsJwx++cINsWnW75jxR2rVObi DduxxsRN2/JgjykoZZyZsbOF1h7ypJqTeZJ+Sbo1lLK7JioLqydPc2ZJlDK2wSKzz4l4gbk6VxbY ipQQyiZF5dwxfjVrAMh8iD7u14h0oJ7Nr3SjmpN1LEhGqfwFT3TnVwpWUbY+OO/F1hvnWMbyHNbA HKdgzNdUBq6HNvI4G0jgGuv410C7hb2dSzem8dhHXONeQItZH5+Sq2J6cuCD0cBCc9cryPX67bNT v1fjoy8nYLIodu3uyFh0HSRGtAbnO1A8mjxxYqwCpqALH9hqGk3/JRCHIrQx23gOHBFW/GzbDBt8 jvlSRBxtehcX4lQL1+F/p5xZMwO7th0MI0Td2GUixbxTEyCO0AcnXkhBF/rS6vgEuO+04GaCVMDh 5g4XcBwIeeRseY/MdYSsLGxZlpM+ftzeh1zg5OWLvPh9qXFteHauxHTkYzIJWxJeWoTqRDLoxvlJ t93dw+mRU1JdF62LkBTika8XN9q+l94oKsUx0zgoZ/0eZZPklXLGj58YGsxwoyFuRxVP0cA2scL1 n8XrsNP5ydne4YEE92LjiG3IC6Ml5z5klKkwS5iMPpDKPxiwsD2jhc40RS1ysTwMvLPexb7lxnOz o/8S+uNvs2/ro0F91ppvoZoWURXfVDCrJzZuEDseHVjZz82UhWpn89Eutbuy2PxlxHsct9QvKHtt 75AFHauNMd/41JjvOVZj7HWdblkrjKDxTibz6eloQOFT1zliCzt/x5WIeRVh1IEH5Z7NYAiiLdvb rKgxXxIf1puMr20Xqro4chZPprfULgZ9Siovl7uLz0mOSc96SAYSn1cJtzFl+Ro1cBcbd+4bLh5T bQK2BuVqOrvoHuzpWLPAbJnHHXiP6hFaNtMVfQIfdX2+W7fizmZhL/Gt260h1mAyPutfXD+4qhxX eSOPSgiPrW7dPaOiLEKTSNeorVGu2D+wUlGW8/R+d9dJU3pK7U97Fzto3Lmjxf1GYUvWBpjbuFUE mYqDbZwiGbBSKYZEHlInPjUfQAAmCO5qC+zSFN7KD9C84uREyF+CQ/hXrjmqiKHyxj+uUUSPq3Un /Qupe1md8aVG+Qd8z24rvFjkqYJP8TaGH7ugpXJS0sNF3v5kAAoDAADjN7j8UR9eEcNcd2jQ0vfi p9A8e4v4AXsXWIqNS9Cb+pQ18rM3j2mUix+bgkWjtzqakl8dXIBXAsbflDwwRl/GZAF2Z75cifP0 GvGzaAyxdPNdJ26/uRd+KeAqp+zgos9RuURZRc5ET4YcPiTmIT94LsMcPgEHo/M+q1Tdin+KbGMs JMpCI7syOpwOYgBisgp+e3xN2jLPKnxHUy7imVd0RYkbBWIeRs9/ETPzE0NObxTS5IKc96bDFATM Xsx+sVnYRMz2Eqjg/SyxWfaJSaUVSCrxmdgkf1biNqbskJrdNqKN65Qt8UHGlioHCA8QWG3rK/tZ ZjPDbh/5ZFaLcm+l9qJXgxNDRlA7GJV/wLBRix/iDSbT8QbKCuluq/EqVDJrFVdJeXK6++hMWLzn kL1Vnp+xX+D/IM2yX4z9jEOMwfwSav74ijdxskn73Cxn75DgdrVuZRw3RSETK59KFyje7t4wN+Uc yK2ZFShITh0lsZ2MahJwJLZGG9pgsi8BP+1rA0/ZPP0adUpLF1gpLSXeEtyt3hXJZwvK9voBOG01 N1+YjN7V1pVCBjtOJa+NFcG2a+DNYzsS8DWjhB5XBxMevxud0FBNOMWXlOt1L7qsSOlWwmXp+t/q F/Mb/yndKjIybcmwsjuJRcPtxn9ar4IxtSWGTS5mpz3Yi9JWIcZ0mdbKvSa+vB6YS8dxp82r0Mql 9ite8QqMPu/xHu/hDpDAeTAWvxfWGCesLWJmF53QQFf+PUJc5mMKXZd9bovWEOpi2BzKzzBRGK/F 6sqRkhULxhjHCW4wpJwoLpaWQlZt++MYu4UlUIfwehb1bZ3Sn6fwdvWlRAYzikmUOM1pRh9E7LKp mslswQo6zdnRukv3OTf5kSr2fvACdEaO+umPq6Xd5rb8dzqakOanppqTef10GmTh7fn8ffkpitqt z6ZJRidauTpj0e/KUDYvwzzpNtbxr0jA9CIR40I/OrEqx5PD4pSNtwThKo8mFq5ULFiPqyTKfIL0 2MG6tU5ikJtsovwrJrg9rnQRXgJut2pEqWPOUuoZDP2m64VFY8gUYgOl5GvJnQEW+1sYmD+UKSwn q8cCjqU86ORRApFmmO93KWyfW9yYEy4segUG908O6vM+YfqrJgf/Mat2JLnWUFZZd/yU4DboAmVl g1707rqicxdznjRkhl73qEd0nQj1Uijj/seTGfe83RYOZa22sjenV7itTwh7vmYFPOuUAiAW38mK pdY7fqN1fKVVY0mmnA/d5bPgHJbwVq1n0bhKMop/EjZosdcv+muZ7yQQKywKMcDS/bKYsmJU+h9C WA8yAGatiUj66MrVzLMsBGawpr6O+D9EVVFK88zxS/zIkM19kogwfCIbN0doHcj+esdxQz/CAUk1 RVZYF3zB9Bwc3/FsZU+LtkqjB+Snenv/YGdXkQlVOtf45mmz267tKmuPuNvist3C6NSVV9ci5Y96 Z4iLK91d3R6AxdxyUGRws7ArSw5SpuRtM84ttBfw9doJ4R+drlvBMnqbIIbGhYyQuRsHd2tYNvHc tWHwP/+OhO+3zhrXzcadP2Xly0DnFTzv/NolEqu4XJYtofhO+dCD4bxtDMACE8hZvOTD4V7sQ1tj OQUlHqWwnMs3VsN9Y1MFnOGwazXOK/W+87OzHUt0HlgoppXlV7TqDRjWLs6xBe+2JV98RmWyGiPS OOQuX0bOAs/223g2PR/0r+4WKtVmbYwtw+yYyMXxifI85DGpzhgrH2oVY1W4ulPodh1lVcyz21mO s1xWwyEWEHlq5dKaKoABE+I3nUy7251FJ6XTim8ACuWe9U/Odg4PJJRz1vKpFdesVtv5EOfB1o5d wlrhjoiAQNR6BZwAQDy+AS8A6G00m5B5Y5eqm5g31lE292ydnZ8TM6Zw6eIqCJ0HmEe9PpvHzpX9 ldxf8qrRLZGmIeQhXCVgWRbqQbMMR0MARxTEiB30+5gffKNazRBrPgXnnmQq6Rh1qa5XNvYjWxzq 4Duq63quPcSPzMqZrc1MzG4H5HzEVR0ZBCssZtatYoxkraOxIiByA17eLb4d9UMb3fjS3TEZ7fTR it4dVr+Vo55KzzLwrFpSlRIlkds03drFP8BfNIWauctDNfIntrLp7gADZ2ZuxRWUOlgCJjdAG6/F 1nAHcxl2E19ZQXqbZgH5/ol+MsW4jIEy7XLKhj5LDWJ/Q2YntO1NhlWn1MZHKy1PzOYsFD8yMurC qIykyBiIaz6JbEbLbJb1YDcyViInvOJI4Fatus0tmDF9nS3D7KzHjOjB01FoH/GGeM/9adGzjrKm uKzAUbl9fq7N6L6OrE5ZC9MsYGCZrhZD4Vo8v8Q2breOF9dsFizJoc+N5pvJ6t3GABRQYRIAymoU iz1Eh3VflA+6jgm56ac+1y/Z8K7JUAvxLHmY3AFVGoBufT3bk5HVPigseYbWVfqFD0nd2CHV5d5b LVrvkOB2EN8WQE2LLMQIVs45ESvOsimPSlemtLM2ikZOhCAZAFDAXr0uHrYEWqaqJwOc0pA+kS8p Ld+ubRIZCd9JIgU0rzSItRcmI2BEPqw0R4sASDKGZ6y11piVNovlVhZfn4atrFVSY7CaiNhLAS6v WBoVTGhequ+kxuo2qaGmv8yuy4e/tM4WrS5n42a38FfdcOZ/+u/xwHy+OPWbHoE9hLSuRAR//Md/ vCcJCedc91hyoCyfUuMelQ9XYWqyR5MymqBAU3wWl51drgsa0Unm7NMLJegiJNkPcfZt9q9ZtdwA xxZ+dnqGUY17UOEqR2bK8DktutXlbxK0N+nTjaH5VwsaGjkxtjBnLuNxRl6mGW9Kx8/FOufHGYkM a/Mml30tpzC2FCU6sbnwyHFHcKu5OJQrYjCx9KcZdhbxaHl7t0KCm0l/iAalgEj3jeSvlC4L0NhN JaFWUdmesCAuZugJV/l396nqm3myFkZ8mzuQu/xxoivOtViCpFQ4REdgm5cQ2yFFu6XNcNOYwWGW wwx4fsPRQZ4KuCVmxcApboCFjlJrahhAesCOVSFjNu/GSZdFMoo+/M/SA5ChplWgrGCzC9UGiV7R OWpO+ObCrlUyKkVWcrqmJJtnpvSs6DbP8i12xxYcqHLJWKsUMpIPF1Miv6UNFMTVwISwruYVcWnJ fO4k4F8zRq+QyrFRgjDn+WjatWQGmWUuTM25GrY0cwdz4HYbV95LlC2lNpXDQCfUzEDJa0abBWU1 0AL4OgHyIDZcXi1LA5e+5jAAi2QplRNDmd8z7ggOJGuWsydR5+f9RpdgY3NtRLiKKSsCEPFNseDx pKMr76tUzGKilWlvKDmQZygq2bVjhvQr75jsMg+K8ejZySkeZqXESLj+GnrTcngr8nGDI88C6DWC sV16pT4PlQ+Ihq7A6oKYX1wc0P73fu/3MJWQMpDGfIt5PhZqdoBY8KlvaMFcqIsPqrtBtkR8Y0iP cYc0ULlBNsjPIJ0kYXGk4JmUE8/SKsLleZonJAt+JFwdmkOrNVSmjsy06utZh7t8ny5Kb19lVl8j Gt1NCGF0JCP+vSx9j1heoa9BEvFn20zUyz37RPCSEEZncGeHjO7uPplnyVBBbBV5xvevHore+d7h 90HC6ACOtJSiZ5mz2Jt0JS0abgA4kZm5hHlpXjnmfa0r42kkRjFGMzmPGtS88jgTB56e+wUrX2EN ACVhunFSat2p0H08X5XCfJZ0IgfYnQSOK34DM6WEfzHb0A2x89xZ5cxKbyp6abkvgigMmcsyVovO qz5ERql8rbgrJVCKm6CeGtDxB4p1USUXRqJXzMOWvx5E4RRBHoEypWC22ysZ+r0eRPS6EpZFw+lK ZQj+lSnJfHchebrFui2Uhzruu0WSKaFr1ZoKozMsTqPApRBl0sNdT8QpKf8Vzi/MR1yN94c4LZkV ddVTUhj3RayvZWpcvuvIn2+syIjyP5O8abHZ2+rW5mp0l6AsAx9jkgZK6oGtFSHQbHKphfvili5G 42szscxoMeps+4mWpDkeY0ERU1adNLj3pocXgz6ac4EnR8tI61P2VGWBLQdeTDifewjRceLaaSZS 87jPadIPhydJesMoKb9cWnA7HrmwTljIb/3Wb5HT9clPfvK/+Tf/5r777nuv93qvL/3SL/W6xUjk 5z3veRRb+Lqv+zos6PDrt33bt7Htww2UXOAG8FOf+tQSfHgk+KRUTHPlHNiyBsen3WtXUmY4unVC FpjGXnWShNFZD9G2jVOi8sFrz8/e4nbchjcmZ5aWPiXEasCtuVktoa6xOOzGaf2e/ZTj3/yCS4D1 ekK3K+uZrp7adHpx83j3/uqEEryOFwWyViYVoeVoMBhe9PevX62kAA1ICoYLCxFT0Xheg1s4xzRJ Clb59HQ64bZSZUM0Ylxjzf3q1Dp01T89a+MZs2oemx8lhOwPGntJ3c6OVctCmamrnktU4h6M+xcX O9cPq7oUDx4/dPPw/nsTWtZG59LtUkjAcYSzb0opcOrbSeXf31Xu+MrnuFc7IM6w2mBD1BZOci4W VXapBnR7hUoO8Zlo9XucI1Sdx47+i2c8vehfsDfGjvqUcYPgrp6Pd+eGEWQxlRNA7kd/9Ef/9E// NKVwPuIjPgI5Hs6ttER2k8H1137t16g8GWpRKw+AJTqggW1s2eNmFn8Kn7tZIPoRBKiRlBNUiF1W 9KnUJvxpBzRrk7eMO89sDiozoGM923imQSs6zH/Ko9snymRI2T11rrqO/m/2y9Irc3VrFZ6ydxd9 FvvnL7q1SCzB43YDQeGadFa10vuhpTL5WRXKxWRXAQOQJGzhVLESV96Z9a/H7syPF0QpTz9Hi4Ln rPRljH9DY+EnykoRhojJXGwvnUSE9UPMAreyjsXTdOQ4N3q3qzrPCv2pHyqFmW3NoF38eLf5j2cq Vf4RsZZGD2R1yhZ+6EcHBLsenc8ipmZxILJ9cnvVsiMIgAyMgKuY0xSVOB0pTLPA80uUFQagLAWD ijyQvZWzTcCPl3XNcLWCq2PKUt2pDMCKhSAesFWjK/SF+S4vARkn4G2rqJkjtoj5HCQR2roNfFIm Ln+riKVfUSQXIJQVvQJllyiVLRyvkymhsZmyWi+6oR7hqkDZQv/WmBCroqxYxRJWAVW8HVHWKDgi P7FOTCnSelWby9m4kbwo1L/8y7+MHv0Zn/EZX/zFX4zF49u//dt/8zd/00uXoVmTSYp77Z/4iZ+o RA31+nOe8xy2ffTx3/7t3+bPD/mQD0GaYz8J5bdd6LuZNUDIwaeVp5zUCZqibd0ubZgpq5E0BYNT Dbf2kS1MoZNZomHqtlBjl6RCdiUZBulOCfeVPYeHki5KvKFUsdYfLVSibIWryM9flmOaJLTZZklz z5TtwHj/WDrwZNutfnUaclJncod7GdFkTStXRUG9TjbUVn2yQ72fhalE9wKUz0IBrjQ1T/Vi6nJq 55HUGj3PmEwLD8WNb3ZoQ+u2p9H1hRDxytLQK1hyOM3n/QOmrgvnlAFUkqghu0msqqgNW14BFNmg m/XZDpZHfQZg2mtCuU5rpzrOwRBMeK/Z2bhsLeZpEsDZmQ2ovJEPj9GJnTL8xdR2qCrS8lXt69yP t/rd/HtNcilYniz46hwVkly1USx9wRENe9ixX2i3cGPWoZuDAykNdREwJi2MsorWBgOFYEfubUeJ UoGKE73CHlSfU1fbuRypNOL5A+SsgswmoCM6RvEolsxSs8VsJtlluZAISnDbXEC+eBaA9jqxHSl0 LnSBXpATz8YD8HPqMSmSteqyolKZK0y7IFX0PjmCZR/w3qxmcXTbAWSSwTWfGjgE89rk7NaFyIGN ZYg3y60JC8xnC86AZ227IYjHSRwoi22Twy5QuQ22N+jv7e75FuKP+42yR5UNszKwzMvN2W4CWkfZ gQS8XVijcYOkuXbXJG9PaEpDF6kWnKDUeLZzGU/Pt7BWR9q3kSkzALrQaLDPhdEtjhtu58rC1n45 WjfMaOUvlzaVCL8G2ad92qf983/+z5/0pCd95Vd+5ROe8ATKmGEYQfsONScR0D//8z//nd/5nb/z O79DLcrv+Z7v4cjMeiCOG1H+lKc8xenhc+YXt5svB0eXDiG0hAtOT04Or14FkGDdWz1PkvbeON7q bDfAi7mDYkHpvMLwbmjjgMbX+1cOXHSufVhW2ChH4+5yWteljZNuSelJuLEFkC45tuP2qlQwgAWV UXMhIAuzF8YElqbRf8ut7QeuIpEXjeVdK0JtIw4ulHKouxPlLcrsiYXWIBbasU48V4kjp/g4tkQt +HHYH+yAAUefCc+l5uqAbgnbh6yFXIPuOI4emvGML/rT/rBzz6FrXPH3pf5B7O2jI7JsBwtMYQu0 gR02UHpxdkYKKiLZS9RfBhhcscIxa5S/KgFjmRpJMHRweCXjltJhubAfb53eur1NuLHyGekLx0th CG+PD21M4qQ+OUUDqGpfbixs8yGuLZIAq55qifGK7enKkxmRqyRbbuspyx0FjmjGhOsom7EZEz+/ fUJu4SwMIOszZxL704EXa52esXV19zy9zxKrBHhMveC+0tXDw/BZgbLBDaJlyIoZkPszrla8kmPh FqV13d0hQLSSspNz0qONO/dAWQs5X15TYab12sXJKZOSCpUvjSJZ83VhuT+ZiF2nCOpPHb8apzGl 4kgwtsQ9X9pUwstsQWjTj3zkI++//37+JD7kp37qp77/+7//vd/7vSP8K5mc27spm+D5yQDOtbkg rH1hO9Du6pTCUXzMwL/40QtkIFHycu1gcrxs+Ml4x0WzBlru3HuwZUNtb6spvLlPqxbvVaPKz9KL tsKsHIONvam97mmSe8EQEvopvpBP1gqe5jOKoF0FD30Cre328bzcYRU/dOgnj4ClJTzkPVhvGQa8 G92kXCJETlnXpgvIXyaE8YCo41xdhHa5f0Fr2nSYQkzZDNWOdRzAhNViBi33uQJgK2ZUSVlrgAbn u6hPvPTEHOuagXO6Qbm2vWHSbocv8LlMKceGSEC/Gf6Lc1maQTplQT8Kb0bT1ZRd9O77h88r/1nB Zlrd7ZYqIPt637C+DENQNp5BgbJhOCMBP9ycXN9nNhbj6oiaRlmFV2svctmy9E48U5WpEtcu+LPM BoslI3lVIpahwo0B5e0k+e9UGzcdIoIf97jHYRhBdqMmEx+CyZuyk3HNSawZOC2f/exnI7s/8iM/ EhelX4x01l2ZjcFlesqjPT3dKJS7lVN6ToRh89Wv5YHeerKsAfpSlDapkfSYmluRcDF0lNintq6y +rwRmOR+00F1GJJQkNwoGcy8x/QX/pIh1aK7FAlSIfV2aULHFO1U5F6KWOmNU1dN6vyz6aQ3X9ky /fWV6LucjdtFcEBZiJspGyIiS4gvM+T4q171KqJKuPLuOc49UzBfWUZjhZpuxq/7WGgc4gs3sQOW y5OewiRVjEq1gD1+zuOjzbeSm6QNAHqOA8ld2Yn7d8nu7rtSnQGfRdzescEe5qmul+GMfbk0cMfg ottwddhjIv1qhjQiOVjGZ73m9T08xaHb0uL0EfnQTZzMqwTA8mL2ZMRurvUtdh1uvdsYA6W582Kg rEcTxVZjAZbjw4MdrRI91Rj5mTS625rl9sLwugwGiMJl4ucDh7YUXhLvwe5HiaEtUTbsWI4rFSYt CvoSKvjWDdOlSQU4Lft7HiWGGfDsTPdzYQOzK22oH03P4I0TagzASsoCAByrXCxLx/+S/uHEAjbn 7WWuLnF4qYZGmashk/sPiVgdDLmjIHS5DHf2jIgrwpq12ld3SDm5jq9ow3oJ0cM087PaSiZ3Wz/T iaOQS2wQKLtuGRbWIEuMJTgkSIFLEiaIdFo1Omax5kpJGAPvvF25JdAgpEQPlHV5WM7HskmcLb4L ppIGFdmJEkkp2rTcc+J+DqCYud2E8vjHPx68M7wLYucnX4EublY+LjFpELaKoE2sfgFPw5DtwSKS 7V1v74ks5FRwl3QembDMJSVg3Nex7nHMxN+Gs8XKV0rAux8mPB4BkQMqYU11ELnscXXK2UPCLLlq Fu1tgqWBHODAWIX+i+0dqysl2oYpx1/Fc3dK+bfhsF/oR5dazNzpNZeJNjJ3ZZaXmpebur217gmx Sd5gmW1KlFqWbqWeA2utZL+VlFrHqJLM4rdsdqx7eVbNM+GeT54ynYrQLA93KcqW5u57cCyhNhO0 NFaZq3HAW+CNNlrbdM2f7xlE9B/zFy9GcMQ6D+ibpTWyTIjQeCVlY/BcspckUtyhj+5Co5KycoNB KcXJ+IUrgSuNIgTdmL5R6n+DvAotHeYSl/Kix2JsVpJWSnJeYS/EX3hpjTttYyi3Ys9nMDRu4ghL 361MMrVyFKaKs2V/PyHgmq3+xglO2yZJpqoeXKZwTHDNbWiuAjSjUUpLOsE1B6jV4cYUHLDKYXiQ qiDV9yevffP+O9wv52TV454G3INVDQUAuE0JpWe7pXEiBiBWiAfdDAOeSeJa2zgnEx6UACaVglj4 jZbhRuiGvjH90WGK+iIf2unp1atXEyCt3X7o4e7eHtcRKxvTLTCklP0UD5ycuNe3stv0OG6FbM1m KTwAq5zdvH1wb1Isf8jeVQlq+uqGCeEBcJXCA6lR/0jqi960P27fc6USVCcBq3vD2TR0snJxcbZg eabAXwImaNyXsHGnzGddG9/6wsYbN8s27ITebbNPNYgn9Jc1eTt1S++VJ6l0IEPLPS4lX7LcUeUo bycMuLpROfplGyTygPNVYuNLwZA+qZ3uLhaNlM7T+0zpLbR5O5EgHYZ0AC5FLMUZvh1EQfq83vaW b6NwuEMaN/MkV8nDDz/M3Usv3+mcGmxAleqD04nN1g+/5TwJMSKxumAqOR00O4r5FUMowbZGzG3c Fiw2VTUyekMx5Jd1VksH0k/ozi7LNu6VG69n6vCzaonJYuDp1k3MCwNrycY9r5GWQqc+Un8Sjncx aF0/IAAgRBeVdr5wLvN01cuILbV38PgwZf+nmZMgCJqSJRR0+WR9Xg5AQSpFs5PHwY0/GE/H0y1y pvPtdtnQXNrmOfRkBYmWvAsxjfgdynpl5w1iEWidCfl3mamWP9FFGcpympE9NgJoyroJvQjTxFBB LXClXW61rUKncgZbaewVDxDSc9kfYKQKrZ2yYgRzM5To5XOPu9aI9slmDAQOp3HcssDVDI3xjbtX Zs9WsWCupDZR+XMbiJE13qUd8lAhc5lPiktWJHAA/PPlNeWGIDDvpxOOfSX8l/iExs6EJUOoN4sp q0id8XSOjRt04RizOJCCjRszfRwmbklgKkVWQCy/lNxCnBicLimLrkTTO5rWNYzt+6rLjniPDZ9s /oV+kluak8jN2qssiwEMh62y2yB8Y/hXvuWrC6apbBnL0NB4YVlb9O4Xz+wmYcGQqLWxEoZ11r2V 7RMxEIhYmtfKPjeYFwsA5xZ9de4XR9c/PlDJELyBdonzCsfBdHqtxrnL2ejHWNwv1IkbL8Xbm+dV ya4xa6U0dlxtwoAoY3Zf23tKMy3NzRsExAZgLoWBdY0ryRpQVwJgE2uZ4d6B9su0wSeRc2RhiikS wzEgRC0t0pLwiUVz4u93SONmw8HGTc6dj/3Yjy1Blp6rhNmy26RkM2CI0cPHjZ3tlFwlmKuQBSnm xb8ONu7ZjZP6PVdSYrFk46ZUUIKBlYuLcGuKkV027v5gb/kK0ip2OzvVPZEUxUQ27vN++97DFK5N tFqyYGTj7pKMqNrPcSkbNwBcu3YtBdTh2QWaaUquEhALvVKYkHHTbdzMCxeibn9UPbJxT2cpLUFs uo07HbHpqxtcnRwfXzk8TEmDk8gtoGd63psO3j42bpwHRVcT1524sJ1iIi/R7U7buCG22yWW+cdD +av4St/rSktCshjvakpUWWLjy0R8l3JXbgBbBRfTLLyWDr7a2ej79slk6Nn+Uh6r5pPwcAM+sr1s nJSyCCT0aPQS/pMaY8Kacik67ZGZKO0Jl2Uqm4sD05hQARXJAJDOkfwXlaPTQAEGadZw9ZZWy1Ps p1tISSRQ2EQiXunWIn9S5gUAqaub9Z22YBmagtCpACQvQwIMJ3lFwMqp6XpX2iPpvBRKwHk8DX1r x0gdPg3Ita0gHlYhbNzLLTAbrzP8lRpjqaZqUSIkw635KC3jvS7XJSRa07jQIE3CanFZiZAUaBHc cGJSS6yxHS6MJXVr0Ca1dHNFouQiYUQKqLTBZGhV46ofiNoj72faY6IwSRiRPjixNoAEXCpWbZNL e+ZtKJu0JXNQH6WJeLFWmjSUsc4pm/CAKGUVSXjQSPrzLGFcZXNWdzLDJK9uvBGUo0tiAQzJRGAn 0YtERsO1RTHLE/VLKJXTpwHTX65Q6hGiKa+va3OHTCWcbjCVYOh44hOfiK0DjwGZEfwiolwBVjOJ Z+1UuEow0RUJzn0yD9XmJDla1xh8elY2Oaa4p2C5wq3e+WpEK3pUYZvVgkNqmcqcbca4yuIxLwbF 7+aVwnAqhtGZ7dgK6dCLa6SEx2IOt6IOOpbwAVWBF9ByNaZN3Vv5xPyqDqFg63GVje5eKbll5KFa K+myiQcznK4yK/X/uhl6yiq8SI5KmnlxuEV7p5Sh2t2ecXKfEhdq7pAmjxBw9+AGNqB9qNTHiKQ0 zJyfq7hbGqQV9Kiil1727MxVLYVbWaotc6O7vDbxlXlHRYUmNalV4tZZIuIE/Qo26c2vNZDcZr0i mVGWluJYY9oNo/MtaemcEDYvq4G7fokpw5U5yR2X/McrsUWckNt+LUMhj1ypa+SKRicnvqWEcxKU +aT4IujHBOdXWmgMZd37urJ/ux+TSlnGNYmx6dEqMM+n/vWJFwslL/Mtaqh4z2qqAqdi/rIkL2pr hwzPCyiPq2IfqGeSA8F3J6cnqtPX5I5gMd1rlSwPppI7JLgB/U//9E8ffPBB8nG7YT47QBEAMsqv t23cgpQtneIjwyHJZcyzXUGL4ZCgDl0vMy4U76yU26qTYpfyKT5S2adSfrnrv2p0CNe76NFSye/d kxPvGpG2YAtMTCNQbSNT87h/djXZMTLfCBggt44pERtWjehvhWJr25R/ZaVtUg5UBFkAECnhfLO2 MVJbrEh6xzC4AVGAJEsMwF04v11miffWMaRthapcTvpRCyJeS6kcNB3dWAZgwL1k6x4ozu4No6v4 SBVrgSuFf0RhEiu7BVblzaZSrYLumZRx4lrhVR8Mh0gBWQh9KdsToTe3IiiVrG4D2ia3gbEzwmAN 3yaoQ8n5Nq0CxmJxMQYbf9ZwDWWZ12g84t9FyxVLLDNpwk7Uod6ptptrdg5Afsdy09SYP1xgOdH8 Ks86PhQTwi6qf5lAL92z3aZeUp4NaiWxTHEUD04XvL0Zt71en1Wgap0mpwus6PU0nDU8vaVt3oFV ZH7oD1BBZCJNOw0EqO+0jdvx4kEw/O6KlZ76FqRlMejDrHCs73flH7U1WeBvbm5sxTKUYdmDkFQu VkOu7haFfFFRdBMMllTGqspUji56kAoyn2d59Oh9JaXjx9LAZhgp9S/Rb7MwvFEBx8sZr4chr+3r GXNMjd0IcDbsokLxWiRoUJXjinJ2LUOSU7aOz5NFvhFUm7PlfRz2KAe+iVI+BZqzI5LDVPPayDDS iL1YcBW9HAbUuM2g+uimhZr+WEEFNaQonQyy3n9OwZj4WYomU58pb1QFak7ZvFjwZgwg2ZxSi1K5 azDmK5FKAkXKlthGs9BEtrb6RNAqt2wVX9W32BHJHu54q2TCQa+nc5J8PuLZNe2RwUqSS/LZqj5F AixwftTYNLodntBJSNAYMLB5dlayvJUv2SIrunDL84qpRMZsGgPAV15777JSO9507pDGDewvf/nL b9269ZSnPEWZE9hTOW7bjsS8oBZHek9FXKhKl+/QoSaQchSYPXq52aJukMK4p5SJUuJHtEgrfKdC Sq4cLo3iGRjkyNrYbaa5e+zwmq7yFN3SMsekJ/bFatmN46Gbme1ipo2AklET1ZxUhUyTDZxGUMG9 3JaVZZq3tilFyE7E7MfDwQjN1F5cgy5TjFS6jEHdjlEcvYwECjmogSqXe5eu4K/ElVSL6QwSlHC1 TBFgkEXFcofroL6GuJIEWMOJu+euO+q5FRRdh14oxCkdLHA+hQx2vLWtaQlaB54+fc9bN/qiuqPO gGXKrpiUJIYi2e0kLSEGI6+F1opeQgDPKwImZGTKs64boiVRlBKcCGmdq1H3lKtkBYsaZ4roOnhl VxB4fdPoqnghkcGslGdDr5visYbJNaxVYV23DD0Tnkc3YumU4MKVZ2eedei1MH3KMWoRLHcbo1dm H7m6YHVKpIrEYgtPR7PMinZ00SUAz5OxhrUsNyvswirLEzqukwBWikwK90yB5EBLt243W0lcuqXC QKulempqT+al8UiBxzkkOmeDGyYkkrN519skTcpxRe9SYaEIfJFQHSmW18B26TjuXG9Q8nh+B2J+ 8d8LW4GdjPjENk0Tsna/HnsfHI99VpUqzYAg7EAuKgb1VSFBrBnMQHFadOdaLe8xlZCm3NTIT5sr XwHhsCjMSs/op/0Lsq73wxnRX/E/tRlOp+SPpwCK/rSKM9rzc4JllLOikQIV0vYJ6sgTVK0BmE44 H00H0FIdIpcdPwFasgSRzwboMGSwF0Pc2QhtAzgHeN5AXzgBG0LqQ75SJdMRUHBNwA2R69BlI6rw DanhsYujR5RGL72L6WOkdNhqacnzF+fZ8hBCkcqvyNilizP6kXAs4kH5OrxaUX80GQzDBrOSuHSI fIdAvTOxh/e2DmC+QcpRBBkfBj8g2URzob2b1IxYYwpcsWPrdybJDQszrcTQmiPCTMyDkbTjkHrM mWQJEgSKlTMdK42+9tFF8c6V7etW5YT+EQqyR1n70C3LWoYnk6+SxqozUOCTAK2/ovtfU0zhNQAQ g3GgLM699PqEmJbeAD4EUkU0G23D6NnccyJSBgHKqsolNPUPEURRe2FJBi3mMRr3+pgrNlBKXiu7 xzDuwebwgORsqX38p0QBJKLxABvCUEyr9DUFEiB9jbLT8WA0PL+ggdBh9bt1xaG0xEz8CwAiTTFW bOQrBpL3SOlKZLQEt7oUtmZ187nWn1XCEvdCiiErPcOtJsWvUrHEK6IsSB2jNeZmSDcCqVmWpimn 4eX+m6pxI53f8IY3UGESpeClL33pox71KAQN6TgwOL7jO74jYa0e646MRkC/5S1vIUn3a1/7Wj58 9KMfzb9ei5K9gso4JQBnfeUPq6eU+2PO5/06tRESHko+ohh6lffNz5DqlOxDV6tToCC14a3O9YOq LvV9/8Fb2/cepiQV0f51erR1kJT8YXL7rHG4Z0VzKp7RGcxda19JSIHSM5mSgFjpWscXnbSA69lp f4uC9AkROzOES3/YTiABcx7dOm1d2aOocMX8qVB662R7fzeFtUbHZ8DZTij5CKL6N4930qpujo5O t7odPFBVtKrpNuTJxXZatpb+jaP2wS4lVSu7rZ0P5E3arV4F84EqLravVFdc1GZ3dN68Vr1eAG/e H6MHpZTERSRPjs65FVw5KbiFyhsqElvJA7YM29evKHKs6uFOMjdCO1erAaCnwcNH21ynSIjaokIp 2wD0isdHp+kP+5ct8U4Pl9a4Eb4k4/7hH/5h7qx//dd//W/8xm982Zd92Td8wzf85E/+5KL8kt3s fMUrXvG5n/u5v/iLv/gFX/AF3/It3+IpfnidnCyHUXmLMA2liEuLQ6JZekZsdjnfSyofLFVxQalN 7QXAJndQ/K4ka9L4UiOTyp5a7x6wUjkpGqCfpEJrFpukma128a4GB40rqU97G5NlyqSEVCsyVdkY HHEpm5v0lS3VwGrbpzyMnBZlapPSkbN6ixWxODcroCjpMR5Iaond3s9nlY9KIFY28gae1jGtWxWo SMOANGjz41U+7ES4vFV1M+GRxSUVWfN0ymIlScQA2xbGlxKk8pVFh5+EeZSbJLKrJD2XoBDcX/Il X0Khss/8zM8kQRpx2XDmC17wgvh2HMo1Holf+ZVfwWCCuu2GFLiHnGpo6Pyuk2F+qZQ/dfTWUswv m+b1Q7O7p/mffht12h/oWFTZWId6GQ41tMeyFrsN11fVgEOhH7Xyy8rLwDiR5OhwLsxb+i9L/esg ZGfDLBak0N5I8NKf/+/f+rmf/1XPeMbXfvZnft2X/MM/fdGLDVQDNDvVLi5PZ1OQqoNNRQkhixAu WmbwBFuKL7Slucfw6GA3HFEPUBhbhfyosWHA5UDAVRm3GUJogv6iAq8VxFJ3qohmsT1VjS0rOudo T7KbUbbwywLa/NQfeGA1pYIpsziv1ZSVQc+sq0s8kLeP6iYzHZJ75OnVJECXfhYfKo+JuDAmwXL7 jA91il+xCspsiSmBMLW1iyvjI5fsWB08DmLx6Sr0qjGnfzMOLC+rIv9Yt6xuCxuraOzmLZn1YmrG Rahz7JkEEa5UzTJrvEogZFuLiGXmi6U1W6xFrm5zi/ZKSi2WhmHIKyCvXOD2veNRfAJVi6vA+RCM yOpii+mteFJNJXRNVheUbvKyUpPssz/7s5/2tKdhEnnxi19MYcmf+ImfCDUnX/SiF33VV33Vx3zM x2Aqwa7yH//jf8SogikKUc4vlKyEQOdnZ/d3r8SJKRR3vH4Pxy1CTI9HhmI7IyzWHdDrHnYz/AZC HCgzD4dFvGYPyMIrIIliMViEIhMVLudIHvtMAyXHWerdC0dBs9IVUA8CLTXnHJQXpVY2mcW37HU3 H/qRn/jxX/q+5zz5GU9/+Ph258r+J/39Zz723d6ZM0L3yu7RQ6fXuvd5f/xjW6uVEtbSnun2RzEu 1dyfiw3YmEo7ll/wC3ZbB4AOcajEVweEVTyTqIYwk0cHR7mKHFcL4P1OR243X8Y/KKKUc7aAaWzW 0nVkUucCBhcITg793txuYeXccLVBlG01rFavTIXIRftlgXw8L7bEPEkEkdF77tVVYIOV78DyuIKy HnCJg7R4fdGz4BcewMWPbTqBfo0uxQGE7KThIZWZ1D1B5+EHK++MZHqMTSM4b1ZSKrAZM/EdLgas TClsSlRRMO+4zl7yZIrHfe6mh3oZ6Ax1zATXCzti7v8RPiKe1lQ1rmtddAlZ199AoVsV8LRazPTT gigECAwxiq7jBamGgkGI1bD2/8X4jmq5K3zW2Fa7XdxEckpx86DVRFlcKUB8GTJsgVLKA19gAy0V 9zbjzlV1coWuBFj9tkH4U4TW/m33XYurL56eh/m6cI4py5/EUyoQgcohe+2F12EtbhZfBFPJ/0/d X4DJVWT///ht9/FM3AhBQiC4u3twX9xlcZYVFlsWWWBhcVvc3d01EByixG182l3+r1PV09PTI32z n++P5/nf7R063bfrVp06derUkfcxK7gZycqVK//2t7/9/e9/p8o7IpsawdissVw/9NBDzz33XElw f/HFF2+++SbVy7CWUJSSb/kKNRx0wPb29r322oteMAE65UF53hLIJWqqDnX20pkvuWwiGvPW1mgH 1BDDlGLk4HF7nDafuOmVKtGfZVQLlCkJhiCHt6am7ABeebM4agj/SFMsOOsO+AZikfKfSCRnPBR2 USxYB6uU91VFhj1y7gW/fvzB9T/8INQAVISKgx6SL4QL1eqq/EUxzINiwS1d7uF1cHGZsBqIFD3F gt2e/mDQfe4Xuck5hpVGZK4KP+hH29L9MgUUC5ZyyX3oX9FbPbGWeDgidVIEHXDQudLBA4Bx5+Ip wSrpUVMG+wEzm+6MOgJuLAvS1cFVFpZWiHrNXj+xRcURaZWyz1XkgWQ0ToyERO9U3lHBCeLxSsVi PkpLDzSqPhNntUTbu6gU7PAKWIo6GvcnRLFP7C4CAlNHxeryewYgnLiRYC23KhZceVXez8yy0Bwq 5lptcH0a7wk2VinBkW4jazVqawSXTV+VUrZ4O7I70RnyNNbKBjb0zBqWZFzAUmCtHgk28MRKHBTu /HjcFwioJisXTc8n8iX+QEoL1dTWECChOyBsO9DMQiuq+rooFjwAfn3lGgePO5/KipF94JyPPveH wyGfz69Ktai5HXxmUwnZUShY3LtHSrYRHnaKBYvWMoQc6//V/2LjxjZywAEHXHfddVixqRT8r3/9 6/TTT3/llVd22WWXcmuydkXySHq29tpr44NWTNNnRYqGKEHGwgrEiEjsj2xeg7/UnXhhJRVMvR/q ZrVVFvUFtSf2lPWsaL9YvDVrtcjmK22WVz7tc7OKuaROrhXe1kF+/V7l98vWTZvsqT3RnGX3q6ny +wPaOMBFhGNSaUI6N1ei+vu2L4RSUJOywODQYlRw6Yn9O6N0B1UseCBC9bmfxumqhAhoHhqAtr1k wdOVq6h8WiyZ2vug4syywETTqzKzxYgu4YeisKg6sxJuoELbhQ4DTETv6LI2C5PbO6IBqFHkgTzn jeK3FcSs5BnmVHHLwI/umaZiWWcwWKQCr+rkIL0ttoOfjT4I+fusggFmVvY5USCrzywPZQpIYy3J 4YrGixylj2tgxWgeQ8bpl4ZM6H0Vaa7ATwpynhtyzRZXN3qJrnBd7WYaJFBDUUnTpP9q7aGVmoLi kUfdNlBPFM0Vbw9O+T6P0Kwo/eyZsr7cVXmzXt09XR1QIKg+2Cx5YdfemZVncHbRyQP/62VW41YC RdJM0bKRy4QSE2inIacrII85XeKuJLVMDi/KXal/qyvgIPH1zqP/0nUz6ID6ZrYE7Oy6Ak6VMVtA BwxRw9Dmdxf3Yq1LlgjVs0HTsRI64BBavKjtKqhRD20Aw0jZHOibselzp4RRVygDigEeO+/C7z7+ 8Obvv2Ms6XhCjCRle3L5bPaZ27xo3K4R9eXBKgOrfqquHe30r4BTcT9d1UU6sGtV5SQml2mtoED5 r8rUiiIcdgU6YK/2rgepLB6E6+TJeG7EeiZLdyhmBs+gM+6ocUkseZGFpJXen+hwKwUt1B0Mejx+ DwfS8kN3mTZXYkIJUbVaK0o+DshmGgwaGL/ByF7qC9Mc6exyuj1ONG7N84MMTLb5bJaFUNHsYI+A tViAAyKtVzyBmaVxqeyjmLKkx4qJXESUiGAJKLLZky3L3Da3MWxYZOXKn956O0VMs6WAc9Xj821x +OHSrIoVFf0pn092ht1K4y5fU5Vnk55isyXCDs1d/Qk7GF9BKygArYZAByzNLHeyBPojkpcaL9EE dEDiLIUJB5qsis4Purr7TkBpcVWUFmJeWEeSI7aasnu1TSWl/mjxrWWTfmqFNq3ZXd+gv+UnuDGx rtDXddddF7kPHUtKum5QVNohTWYqJl/0V23AHRrRsZBIWVM5cATEGEeQJtonIP1YvJWPX34v8agZ esIFEXWG4xDyQts69ZD7B6tUTADD0QAFRUNr33ZhlLqa2ntPPmW21XHuueeOHDculYrTPUk/UH4U fVJF/dLx5phaHJjdxMWBqolx12rxO1EkS+ukwsKuyag7qTtWQdiK+/XYBxxXf4Lo2/QU6ItP+loP ixZ2vtIz2+eUquo166XC6CSNR4LNs5IFB88gLDglBFyDwBMo6ZGiJiUJgbyVmGIstygGUg5aMKrE 7JhPY77MO9zAuTiiyYzd48oVbEgmRUsLNlS08JLtSs9Uqav9BeWAzgxGVE6BXlIYUvKCjmgBzTyw OrWxVojAjmJTyvJAl56mCibsP7PcU6oM0H/JVFjkdSJFcXliYrbZMmz4hDAV8g6McoRDJ1N1dQFS NmGvru7uBm+94XD++MknJx5//NjRoxWjWzacNu3K224Dc9burcmkcpBYjlyiHedtCn+DNaWZ1tEX DUh3vlxcDGSv6KVFaVyawUpZIPoOmhJnjCquxnvWLG+GCBsrkW6wZViaWToPc9gIWxSsOyCxCpLi ZxelXtajdlRQdLsvWFgxvGJIg21pgVTMFK1hPdbG8f61vAfmj55P/3fBPXS7g30L+bTGTZX3PupP mWI4oH5R3qB4NaNRM5jFkCal8LjtfmVcG/ziTjMat5ZQuhA1TtqqXdXNcucA+4GSow+cec7cr764 4btvaVlr3F7/EABDPQMoFOIrOj2j6lGRhvDl6t6iGPJmwPNBOT24E10P2latTsmdgsetak6aoQCH M05jusT4UGzD2T+ezMeS2LjNNBvrjnkCbqR30b7Zr2ntkEAYJTo77D6/w1uFsJpWsGh/jbt/tzUT ApRmpqvhji6X18Or6s0DatyDiXhYC7FVnbA4wfDhWyzMbP8O8HmwdUVk1Uqc0fFQ6JOPP3z6yefj cTlMjBk16l933VO/5uR/Hn/cqta22958U7TyEuAUNu72oGdYvdhMqkysWcLSGUStmdWtty4owBT0 r0VVQTG9DPXBd2jBJbwdQeNOU/i06mTRFBr3wKu772NolvWiF1epWf2hNlesrjhdbRv36j6g4n69 vegdUisX+ir9s+Lz8nsGvH+wG0rNApejZ6vqnbpvZu7UHa56Z5XbVAtNTU3xUDCjooxL+v7QXVXf WpGEYlYzMa4KCg9BUoZf0s2H6EOFuK9K2NKpq8q4xLArPTBJWGVi6723aFIvukyUuRNXgVjAbZQF IK+3arOrNa7V4oFSbaqqM6unoGpXV3fJlPTW/h3gWR+89/4+e+2zw9bbHjz9wMuuvH6fg/b/87X/ OPGs0w8+5qj6USO4gUVEjJD0SuLRey5gs1wuhVVQdWJ7SVuVW8qHNjQT8m1JUa3arPkFq3FYzEwB 95lZL6URVYiXcqH3P8vV1bBx/8/P4Id0HY2bOG407oqDtq7yrk9AQz+CH6IbanWvtH4G+0mmI2xz Oax+sPGk3XLg83KPNe2UjOxDdEA/ERu3ztqvuHPAzqA+MKj+Nm7hDqv13lPPXPjLT9d98RlNSV4y pRY9/eAJe0Jher3/KJOhuKXWW1HNYEB9ShN2wMrlFYceKMAnJTPcELRlCjh2VKgPFVOgG6cR1FgF ezkk1Lg6yZM2mY+nSEUTc9HQaNcSJxD3UNtIgSYQh4MD6Ks3X3nsoQc7Wlu7OjqGBWoBj3D4vMls bp1pG1xy+RXOhiYxz6rAA1nnfburZ7ZUjLzqzGomxNEy4Dm9zIIlJEiGo5S/IXpVEUQ6UB5YwnNL nAxfwV39j0cDzuxghK2YVv6pq7wXF5eMXYza0hlIYbM+fved77zw/NWX/33ceusRLdQWCo9aa70i eVTNv3+cfNKHH3w4qnlEbSCQcrj+fuO/x05di0iVeEfQN7wRfL7Sii1fU+UENl/lvXx1a/4ZbGlL Pnkmw6ZYxV6qDDUc+1gCQ9i4i5IdusRTQF/Y6ogZExoVZ6qkqvXtjQJohAkVPnM/waVnVo9Cu/rK D3Oa30oAxaslV39XUwkdRYjMnTuXvk6ZMoXFrA1PusfaCtbfYFc+Hm5YLRu3kUhj46ZGK63zGEAo rBITVrRxY+Mst8fp/XAIexnf/j+3cd9/6qk/5yznnn/e6AkTk/GoIRVyJcWKDjPhYuMr2bjzhgcA T5XKIXkHWJk99iFs3CW6lcZVNeq8nAJamxiMmfj2/7GNG4M0q0UK10tosNi4/c7BbdxgHKugFqFP 1o7RP5+lJPSnH3989h+OOeu0Uxs8HisAHQRTOxwtkcjDTz/73mcfuwMBWyCQs9ri6QyIbuC6lUan +arEhP1X4P/Nxg2sq3h92UgINCZ8njIg1AcrCSS9hXNDyRdSsckNmB9Q6i1vKmaqf9R5+cwC62Al 5bAA6fIORennHn/sw7ffvu3+e6FpOhq0NtSSmx5r6/DV1DEj4ALNmzV31udfxCOxmkDNvx948J4n npqy0Uarli8bOXpUNJ1kT/p/aONW0F29zoOhHXcl0/kQwl3PpkkbtysjoFyAnsAN0IlJyiCQB7dx I8q0sq8FV4U3q/RhycZQzkjc//83Nm44klQd0AHB466gtZmoEv0TbQUzW3OyQ0WV+EzVG6RxMxUX SzZuM5vk0MXunrjg4m/ffvOmX3+hqWQsTqy+v8YM+EMhtbLbMRwIlOopr+YJCxfCYWgQVc8xJRu3 GQpoZcdkzclCIm0S/iIUpMK3mwSrUh9evvXfD91774s//mQIQHPxmvvKi0cdd+zH3//gnzCpam/N l0ZcLSYMd3QSgEUMb9UOaNBjk6UsTRIWySXBwoN7wB6+7dYn77jzuY8/8Q8fbuSSsWCXr3HUgF1N zJ2/7Tbb3vH4U1vusRP7TPeyVfXjRlXlFpr6/4KwOrSp+mFOjUTbuM1Yk3OxJAhuJpmQJETCo6ua zukAujk8o2PhShf91zERVRmj4obf28YND1W4iVe3x9xvhlFKzYpyOnjOXvnT9c5ppj8VeTHVfjKU Pcfj9YGvplsQXEhzBa6gAdlufc7j1Tph5vvSsc7MzatxTzXbV6kp0uEAnTPbsgqKLb/ZarFnOJD2 YPvpr2rq69OJBLWCzTZr7j6TrKIbI2PQ5OKk2T4ZqkN3xhxhdVeHMABi8mqoq8drIk9TlTQGe6y9 ro4SEhwa1DIkbtIztFvSHC373LVahF3NlWiqO+I3MnWj3CR40eaEBqLWzLZh+snFG6srbqvb4oD3 6zOpNvcoq6ZGVNXYoJLGyltJRh76pcCFq9+GCYzoPbejYLfLI9QlIJi9jQsscumfqhtiBS32RAEk S9Whvp2R21TEnr6//NX3Tn4oEB15i0NBbxaTdMVqpsEf1dXW3pqvqdXvOfAbVnJ9VTM6SbyHLDrH V1snVIB8Om3nSFfeN/2Tyv7oMWE6l6J/fcYywP1Ep6eknsWA9Fe06umGpIVLmbdqM6Uf32NXGWzK SrMjUSBup5qhSrL3+62cabN5oGVBHyVjQwxuTp8X/FojpTbCng/x/9rdXiACFIkF0zULipHKf6+c WZqSgDZh0X6U7NMf3eEiD+h/lFGeEZeTWr6yCii2rl9V0XLPPzVzyrds4H0J22+m9J2qvJb6ecVA emeqtKaYVia3585skf3E1q74MCtFggQ/gAs3g80uvKR4HwhXuQfVh1FR0szl4U4nYZf8DouTQhoA ZUgDwOpZGGDJSNFRyQ4vW3oDcw43cOZQjRQJ1W9Nqc/VJfdIqwq8t+fV/+lFqmJXK4qaijXSZxGx XglwTMIhkEsxb3nj/QRCFg9BsSdy94CTWxypCDslNEoj4j1nXNh3aPPs0IL3d3JO0sUff/yRUG4Q TtiCBHmZhCKFKaFFOX+r72DKojQE9kVxqAQM4UXMZChwpauWFPENyjIgSoUopSyAslIpRu7xtQzi JdW6ufS5/9bc+xMM9tTKwtMIdDTlATFxqthxC6BXaT5isLVO/31nn/Ob23XF5Zf76gIhlRquoJrJ W5MUK0l3U8XJVIKEBK2r1aRYSmXKVE5qWX80GblRYsB1XcT+J4++/deVOAZlo76Nc7MsHBPXgIbI Ep1KrRaBqNRgRT8dQpFhEWYAsAeul6qdBEXzrySh01+9/+k//3rZ2+9+mEzHC3VuoGcorhWNJ7ff YuuPP/+kefzYFLDJdkuCGUnnHQZhEpUT3NvVSt9ln3GqohzCriKTFWuVYzk+ymgAAP/0SURBVODo ySpd4tpJgSUgXhxl48avo9yTPZeOytCUV99QWLhYwqKsld63UJ4fw9hF+69EPPYdSCVb6jIVxZnN WjJELLsx30aTtnTe5/Y+8d+H3v/w/VvuuMPhcVlczjR7p8KH4DF2VYQjFY4EGpuCq1prGho2GDfu rVdfG7flluBuZFettI8ZbSSiaJ6U9gh1d9Y2NMQQRf3WsBBWayxV5JAgYlOaQNYiMfkK4aR8lnQk lRpLsaaxGK/LQSIHeYLGVxkAbKDv/VooSZo36wtPifgeyjpd0bgCLCrG1KiOiXQukx4SIiW/V3ER /YQbRCKakHvcDqdHBe2Yv35X5yTdwtAJVsmKFStImq/opQQ/WNG3qg8AUoQiEbJXzIwzHAnDB1SS rHpzLBGHacw0S10+9I6ArzpmMQ9tDWUa/SzXgY9fz/7tr18++9zNc+dyZzZNBETG7TFj4zY6ujsb axvM4HHHJIbX8A6AVVJJkmg8hiyuDVRHIoYC4OOYoRXPCEUjPtCobdUL2MMDNNtQX191srghHO30 e+tUFcHi9e7jT1953oWfLV1keHqf9f277x99+OEzfvg+MG5s1WajiRhGDZezOregXgXD4cY6U10N hkNwoMsEb0P/RCrp95oATzeMYAgMFq+UAap2hSJhaoz5/QM3+/htdz7/0MNPf/S+I+BPhyN5h9Xt GfjOFbN/23Prbf56wYWAWMSSseUtrbWNdV4CvBrqRoweM3rKuoN1JJ6I4e02swyRcpF4tMZffRVI zHs6iYHRg8Wm2sUUsGDNGKygP5tiwEQHeGYkHiMlV4cPDn1RSALpXSHfECNg/pjxVFU0/nvbuNlC iUmqsNCX+mTStNRXX6lCL7N2a4VkgDZUjf7yffm2WvV+jkdDwEZLUz3uNY3KULVB3QHc/UMgK/Vp RJmkzDSLrmASYVIDQ5hqU6JihiBAZU/NNqrqylckH1nwSbJBUh2q7EInAm7QZFk/GX51iO8iD5iH cytiipqjl0keoDHztCpL7x+gEz4vZeV9Qk/MTQGibAftaFNj07pT1r3trjumH37gMccdf/0N1597 7nmnnnb6wQce9OWnHw8xPpMMKLzdWzyvCr3oph1ThUm30ACgaQO3r068pkirlqGkZJu6+hbzKv5E GV3/L1f1HeP/0nrpt2wUnA5IfO/fmk7mNvMUREZv4Gi1H2DOHDq3sNQAKdelwkJDt1pefqna81ld UnNysNvQgwBK1t+qYlGmxIbYPaiyZm7KiyBeVTvaE3doplU6YLIygMgX09UJZJc1xQIyGCkEVdHX aAwHUL47WD5W9jeOvuK0NHFJ0Ki5Syooml2yUo6rLwTvoM+QPc5cGQFNWDOTxZ0CPTr40CgBRg/j YEMSMhuJCCLYIBeleZ558/XPly9ZGk8uLqS/X7liXjQ0t7Nj9MhR4c4+ZK9oQBteTF5DwAX3aUGl v/fBJh78Aao6qilqAViMQdJMV+HWXMpUzQfFr0WDcN+WK5UPM88tv+d3snEjuMHpXrhwIUDehKlJ XVQpGSxWblU5sIARUNO3aGxWpO6tztfzT06UVoXn2f+23pqhUqYWcIWEx8UBhaqyYjcUZ6E2Y6um ijZu8XDkqOrLJ6q4kZS5UxOtcMjK7tfwPNohAmo09mYxbGl+kI1awMxKHcYlVbA6OA05LABrWOgB BUWxTYY7O5csWkjR5KzVNeuZpzKBmhsee8xwOhKRMAk1NjDBURtVXWocJBouTyPSOp0u7V9hXAL+ 6ad0WXHHpWNiSuvJqtCdJ1ROHDFwobKu6l2hRB+x+Kux6cGiuYitUCqXi0zWq6x87Dy5Z7BCAr6D AhJ1Xkaf/hPHZGKSRy/SGnrv7FS8V6qW8AAo56qyc0mID/iTbIFg6IzXgffCYWDZYCxO2+ePPPWX y/723oyvrC5QTwQyHOjnjuUr9951t3c+/KB58hrEwGdsBiU7wUt02BxCpfLJFQhyqZGhzfelmWWM UhyprMOqXC8BMBmpa6zYFY+Tngk9Uzo6SPecjoA7L8WCSVyQ2roSpEyssBhxi5SXeANZAwoYHh+G 2yVpaP1nSq3/osdCwaFndU1bySsqGwgzLmk+PWxJrBKuDsgPuovYWvNp/AHxcPiHr79dsmDR8OZh 77z2xoplS+997mm6A/HTLgrLyHhlx1Uv/sl4ICYznk/FGa2ztpZ882QqE6ByWD6/3eab/+nKq/bc Y3fhMKBL+GnZygXYRHxIKtmnP1+V84xwC+Da0oZLQWCKXb7E1XIno2VlCK0UEXNZTCVqFRRTqypm Ss8CzUqJWgEyFHeu7kT/mdICQaehE2PjcrlVykTvTMkKLxMIDJFoPiyxKuNXzPLiWe2ZOGYKcvG5 RqUXf57U+wbxv/h0ehUOhekTYC8i91bn+l9s3Dxex4QKx4irOaPLkvGmPPIfcxL3YObX2Uo6Up3I U+oqgFWi47jFG5NSeJOsBLgNnHeH1K4aQpVRDiH5lc2t6DW4ikazECyTzAjsopMFpuZKprhIIT5B UtBP6nw6Pd5sLA5rOTxOLaEUN/TifauEtwJDlOWmClGzcxDmpcSbXrKlP8XP2LVBSSUChHVCsoOw C0yQyXQtX3bMQQc01tdZ/U2xTHafvfc6/KQTvA312XBIlB2VziDV3aVUQA+8uhIHgrGpJDd/UrGE N+AXtigNp29PWMxSBUJhNsmPKaVoF1FVutQO09tzbsa0p7quvrFKVn1v4wKU3OOMVZTNJJJ2t1tW jaie4sBRnpxS80q/0GAhdAPGhg2GZE2xUhDrkck5ZGaV3B7sBzJPllhXBztYjbf2hvMuWvLbwsZh w2b+9KO7xvvAC8/VjyYMuZCLkK/oWjJr7n677PLjr79YGhs40wmGEMKe//UUqJLRqNgM0UqZX8FO YmbVQupR0fo4G1UmgbiH8TmDha2qE+DE6NnrFBuU9ZyBRIMhSkNQUkCcqdrbVuYFL86UJo7I4xzI 0eXWrd6ZKrKZxLgKzTkjCqKDcqqXP1E3VZxcEn2TeT13arE4sBxxdzIzfedd69xeB4kmTsfmO2xz +Ckn+Uhwz6RAYGDnkGaVnFPIdT07ue65KjIgoSZJ6lw7QZ7cdu11Lr7gguknnyR+UrVwythMQnly LHM87hI8JyrFYDPLtxKakc5ZSJpThJIlrhDi9IB0fAG8JXqJyxXt7vbX1kmgECYHMTXKAilRQu6X eWLslnwyw14NbpSYQ4u7R/+ZUlWwpVQyM+tkGDy9fI0IGcqkB++pry3lBoubthLa0gvhISGZVHm3 EG0uP6PjxKtKzYriIoOLyT4VNUyEtykjbYmqqy24xayD98blevXVV6mHMHz48O222+7ll1/mw/XW W498SC27+SceyPfff5/oEbyRWNC22GILvkKUz5gxg3BACuhUrGLi3mXMXhPOyXyeQrFU4B1SDhS/ jHUGBWmBogfVrkwwBkmdpLpWu6SmbTLlBFDNxNXR3dFQ2yAc0HMt/v67Cw4/+K83/XujPfZJJuKy rfi84vWOxxActtpaE60akRVtvpGNZgx8AlPJcjVTADcKyFTBVlM9T4TNINbe5R85zExXs8GYzeci PrnqzSyDTCzuazZVLjnW3uYb1ty5ZPkVx5wEwt20jablnfYxa6+x+1FHeBobSs+a8/YHJ/7h2I+/ meEYP7pqBzKhqMhgE+laUCAVjLjNVfWNtHQ4A17EcdUOwADZcNxpolQuTWUoGA3MlgnnZC4MXK3F 4u914gUXLz1ip90vvPrK3Q47OCYOfNZIQIRUPgcKbn1D9SmQajBLV9jHjzUSyV2nbXzySScd8acL BxtgJhxD3bb7qnsRJbIwnLDVm/D8Z/PRriB+UTPFgtPtQeqAC+BftSsdiWeSKR/gWSauVHvQ2VBT BZ5BtUOREDlMO/t0IJekvkJKsNpNPKv8ltV2TiJb0aAvueSSxx57TKvSb7zxxtdff7148WLK35QC 1BDcLS0tDz/8MF9de+21vCklzvETnctXeZn3oYm1wqwxUgP2mCILbZprVrQhs8+XoKkK3xy+9Qbw DewO9DVvba27JlCE1VZFpUx1FeBQcrZN+LJpTRQOc62qAnimDLfmrauKZ80WC2aeKmo7DUGNPDCk Eq6dsWcLx1/4xzPuveWs22+cfs6Z5VKbG1BqYuFo/zqtA7cs2tDQB4Oe36E5mnNI8AMmizOzqZll Ckw3K0XLTMysMo9UFDgDW8HltTrcKB9Ou6+xwUm+bnGV9FTSqN5dZYPgcjixBWWTQ2ZO9QmAHLpp FWNn7jI/BZXjH7x9MXuYExi0geXNtHcRv1QliVTt0iF8CtWpYNbGLW6xfP6YY4454YQTtt566+bm 5uOPP/6II47gDTXMXnjhBV26DJX8888/P+WUU1C0f/nlFwqVIb75ip9/88032lTCPVlKiMaSupqi llnKxDwo2bT1Q44/WKwI4xW70qA+DzFsyZ048ahGp+KiS4iUiiDcgNeK7UesGT4fup4cJF1iKuFb dUbDPlW+jIsGH2VMllMc0EmD9Zaupq3ZtDVHmgjWHyeHO8KNQxFnc/OKDz+49ILzb7jj7pFbbV+I g/4jsOJS1ThLUkkhJ4duLPEYuu1OO8aKIjX02EWu6B2OE78cJwemVdFMlOF8qrC7ZTwWCD6kDapk FC0Kr3Lailmpt+6i2I3I1QGkQoF4KxOqCvMoI1YPHrf8EiM7h8QhS5dp540kMeThAXVAGZwNMD4k I1S4qm0aEVm86pJDjz7o6KN3O/NUAypi/M8lXMCSgBlNwfJMbuX8BYfss+9n339nbahRR/8MEfVW lJyiqVMZQFXGT5FWilEUVurAy0aTQmLYiZGXMg7ij1DIooPez4EApUyXPy2epnv4tjRTyiuhJjeb Ly9wNVCjxZQTCCvnA9Eih14yfWaWUzl2uNCsOUcfethf/375VvvuIxprJkHEaMGJhTcRl+RJlzYp 4CfA46GdHjK7YirBnJ/DiwtfWfFJQK3Gxp3XnvLniy/Z7aADk8Gge/jwvpQQHVr7GwUhRiFaDiaQ tPVSdnoZlDSjAvh6loAqbKZERV7MU05XrLvbV1vLylGGZVnm5Qu2Z6awq8AYUlSW1pS6OYRAFPki TgKSBJQIGHobTxNrS1d7jD/8gvO9QZpu6YAdz+TSKZ7KuCijSuhkyQhGr4Dbk0gHj5M46OpCuuyO 1da4+QH6MtUmyaNBdiOpMYPwCcZrXI6llukc2jfGk+nTpyO1+VbciVYrspuSlQAX8AnoAYQDyyrF hI+nUUlvvHPIrMFeUoRR1SqFuPyE93wy6P1KloA1JGIFW7BV0Ov73Iw0k0bEQolkUWmOealXBGer ik0C5IRBu+dXyuqMdVT8UfCHYOvIDYN2QKku1kQS+wPjokG7s6HBcLktLuzoFoGyIS1NakSpYlEs G4dgXolxDS8WHg8cQYiznvbFAwCL6F4RQBoMSaTCIE9npKXearbHvFjeWkW3JacLWLRolIkhZwnw Q6FaWeMKc0fNlJ4sK4RNsbfIfKldgVdf8rKKivdLNxXI1xC04is6jDyU6vVFyg8xs4Dc2112qeyM i7K+rk665GYbU0vUboe7xBlEVHgq3tXaIgZQqK3ozETQm3Jm0Lu0nlklK1h8fShf2W0lToQJkZto D3hl+s5UJW2pORmJCg6MWHmLrFWiVWmmZCGIg0d8WVUIhTxBAtFJpkhGZB36/gwu+nAkGY2mc6R+ 5dLEjcSjNq87ANztiGZjeC3lmYGtg09g7CSuqgz5Yr24piIo9Uuc7VJfEORGFjPPjqcSBaW74Nzo 7mjHPeMeM0aObWWcIw4xtDGR+JzWofyQveUuPOr4D8UeLfwjabel1pDlygPBPdoorDWGIlUVNFvF AhdhDWFJxWKbUZXYhuZDusfwSdOQnX0I2aK+UpmQbN4ycTxFXF5+34qly56+896b/nz57Vde+5/L r/nms89tdX66TXlJUHCRBOXNysagrP6rJbXLbzarcet4PgpOnnzyyZi2Eb58QjkbaA161K233lrS uD/44APs4Lfffvvbb79NAfgHH3wQeY1iQqVK3qCtV/Q1FaNUruHymrAD5vPxYFhsWyauXFfU4rJb TVgt8baxH7gGSVIofxSxZRSW9phCgzI6g90kquggWX0tmjHz8sOPvPSeu6bs0cfQn0smUTid5pIv spRkG1ajQxqGvoSwnIFMGFgBtMQpLhW2ql3oOGDF+etMmeMBNaVKrBnzYiGZ4WWtq84DdLDQFrY0 1yQ7u4/ccodT/37pXn84asBeL3j/g/33mf7t7FnuidUTcBKRmHiETaRrwfDA5rlrTJhigQ/rCtup 5uGu7r9Bo8wkEm6qMJu4WAVOn4ejTNV7s5GQLZO2NPT6JHItrQdsttV5/75xl0MOKv95nA0mmzGT AYRRLdzdUafa3GPkuDPOPeeASy8erCfJWIzNkUS4ql1lm09FIh6qFVe70OQxRsuxzwQFsIZ7agNm EnCwAQBQYK01xYSJcNQV8JWH3n/79rt/OfU07J+tnd21w5qOPf20o884jaEQBubuN3y0Hwo/ypnJ nH2uRJLV1rhRnIcNG3bYYYchkclcp0ww9u6ZM2diy8b6oXEGuLgNhLMNNtiA96TbbL/99qWDNvcg +vtPiq5pW22yit/nzFuhBqnV3P9BaZzT5pwEulSuya4aVpi1z81s0ZxF+xevwq6RGfwUWfE48yHP UmPQHGFBaUibMZqKWUMip0xSIM35xBxjohsCl0Kz0da2X99796e33/r06ac/eerJ71555esXXvxG vWbK64XPX3q185dZ3IkWmXHb6oYP6ibFEUAZT5Nee0IoBCLAxMWZEjgrEzfKLdT/NWkJRV2FD002 CwyuyfWOHmlRukvL3Dk/f/DBZy+8MPODD9P5tM1V6TFWwMqmZhaeStoVsQiJKxjeIZO20dNR2E1d lgL55mbuxD5SLBZs4u7VkBhi9zA7BUnhgT695djY7Pfdcc9dX61c+vaP3x15wnG6dxxTMv0z/vXC NDXcgQdpVuPWFjosgBqngr/aZKPsp4S+FQU3n6josj7Fgvkh8SSzZ88mAWfffffVMPDlyBg6ZGUI LVJioHpQTfRtQ22h3JDKFKJJzNaENPBbsbQ4xSipeYgBEM4mgVUK/oaL1srDP/qTqoTOoenAMbX8 HjGzqF7picCqhwKLT4DKfgSrOyBVLG5rbIj8Nv/4Aw/+57XXrTl9X46uJRADjaqq+yDmeDEOq8DE npqTLrLGs5KHKcGlJBb5Xbpytr4U0MUALCCLG3lAmemykCMajwJoZSk4c4JHQTVLMhQkkpqH2i0Z Dp2GxTfkUqsAKpGIoH7lOvV8qfjFYpHAUm/pgJye1eiwEQJpS/oeefToULUjh3/z0ivXnXvmaKLS mppAziSru1xEMYVBu3f4hEmbbbv1yvbWN95644+XXrLf0Udi9SaySgV/ZcEJLMSSdod7ZUfn3ltt 980PPzrqG9I2S4zuOGxuCRzrpVV/vmJmtagV4kkVHZFlEomsPmGgGMU1ViqHSAhbHgjLPYB9lzoM ZWB1/mL9VNFoLOAcrxIpNOl0HzS5KsqJDDazRSbsS3mJDVfZBdihBbbMyLudjnQkiF0PG9zTt976 zCOP+jhT1NR1RkN/u/66aVttDcpfympDayEWktHZJHK3l69Fkvf8m29d3JQ1IrZcwpZhwddmKX4S OHKjTc+8+PzN9tjRWh8o2LwYHCvYUneVDwfkk3JSaAQ6vQr6iwL9oV6wmixDQ+6VSFfqQMWiLl8U kM5lsVPKI5VO4HbCkgR6GeBbwquKXe0Fi1steVaGsnEZ8WQCPUzi07HHsGQKluWffH7BOefceMft 4zbbjAhjyqGmrTZvIACcRTQeaaipKSGraMbQg11d4MCSxm1WcAsrl82BlhSalP3FXOlz/UYsaMnk /PnzW1tbsX0DUFsqSMFXWugPXTRTyVi5kHE6eHxoOSv4dcEo0Ys2jxQ8hIt1CkDPmixAcpUKK5cG xh26A3rb0Ewju07fvVKdmMokqdobEumEl0BZpof9NpOxBgKtP/90wv77X3frrRtMP6B8q4NlaVbD YQvFlCyWJnWCHMWCsc+KvVySbbKRhAWTQhketx5Fn41EGRaJUudDAkhZ4PprGT6ZDjIlBWx+Ijol udEixm3uxCCoEFPJGOo/p6VNgp6XVzvUfa64X/cHF4gOIS3/Vu0mSnCrF6Yn0ouSkaiRznpHNn31 7Av3/e3PVzz8MGDHkuWky931BBMT3vnFB59+9PHH3V1d8XRy/JqTDj3uD1O32QqvvVgeaRAjKbG9 qazN5V788y/77LjLD7PnOEYMJ/w+JalTVtwU5VuuJh39h6/gqPI6KeLz0qK6h22UodWK0xsG1rWN +GG5/iHULmueb6OhMEsTBDG9JUscfplOV5xu1QdYCzbgkFo+lf1nVi867tRF0fpQXvhGKI17RiWS UUbZlurucDnctkDdTWecPv+nn6994EFfTQ3M4xw2DA1LnosGI3ZbK7qDFfw/Z68Hr3xmRXgxDyAw WgspSxYIryaHz5HN7z9lg3MvPn/nE/+QQ4W3OPEilOZaD0QTVne1P5+UMwZ8xc0QdsA7S7/VO5yO MB5CCJRmltXNFtv/zj6f4JXFfI/BMJW0+jyEAkFIYB01jwpfFWRRKJFX3NEj0YjL7ZHUHs4paLTZ /Oy33rny0j/d+dxzDetNAUBROMduQ80KhqMWu6WmLEKfsWiQbk2ZwdbagJ//L4J7tR5QcTO0+/XX X/Gl7rzzzhVfmcf7Z87wPpkspJDvpqyMw0x4eKmaZ9UBwlhcJC5WvZMbuqPdNd6acqDtBd9/e9nJ x//pplum7bhLeQtacJcqhw3deKEzYiHW1YTFxjxhSQNDxfCZgOxZrUIKpeJtVcmVIdaVrdXr/OHl 12466fhHOzqG+EnHtz/5J4131QRUbclBb1zy6ceHHXzEx9/MdJuI414tvH9dP6/qoLghGY7gmLJr wOshr9UirNlCCigQoRa7O4Cj48bTT4t2tl/x7AuD9SKBHGfvNOPnKOQ7ot3NgUY0iQPHrXnmny7a 7ewzBmvWPGFZAmaKBfMgSRkT3E1TJdKHrmdS3u1CPA0KhUkbdzgSAbqrPDB35qtv/POPZ9/8/PMT Nt6oz4aE3bxfTOj/3xRSYCTsMIKa+HtdQAqbtFhpnev/eb+ykVgFmiW6Qld3OxE1Fc8aULEarD8c 54ppztV6bL5Zzh9mw42rPfR/+55Fi7NGmAQPFSeF3gDEAdprmrwGLiBJcB1y0ojo6A52lzuH/7e+ VfxqtVgF6IKKw9BgfeivvA/RW7NtQs+e0xjGt65w91DB+qbtrb2as6qdmOjs/P0JK/En/Qx0/8du yHnWtI2b804F2hqKh8+L8lOZaqRqG0modPlV9fxRdSyrYSqp2tYQNyC1Cevu6uoicxLxjQJeYSod +sgg5o6+KSr9q3/2Pl28J+lcNOl0EQ/NEQcTHiYxiaXFWcSBRzAI+gL69Kdj+frkfbkpU0yfGBVs BTk95QtO3nGCTmHUAiEatSFuqQlgtMWyKaG+HM4jYWL+iPiNL5h/xkkn/emC8yfvfziR2yUbt44O 1sdJBI2uftDHxm0Bb0TOhwSlYtVw1PvBQCn9vORvKFKAQDEVroSpk8Rbt8WWF3MEsB5YbLIGEKMJ 3mDeBsMCE5WtYANbB4znYuyX5Pv2gsRUTik9rHic9Jnkzx5bTdWZqrBxQyjJyCfADkiWmsDX77x3 wR+OeX/efJffU0hJSq2kWWMH7gEllEQhsXz1+FIlSqwXIQr7tSQ/d4Zs/sDKlS37br3djG+/d9TW pezWCHEbLrsXc0jZdlrRWyjnsueFIt1hw+YiT0XgzyIRw+PEXFVwOkUvJoh+kHhgpsxpsxMBrWWg nGrDYUn6V6ZMZpZjjcoZL16MrtzGDYdXlJTtT+oSK2rbSzmXMnH5DGTC0160cRMOl4uEWQOYMO65 6h9L21Zcc9ft+MokOFIm2SYg8ZRfFWLCe/wSlaK3e33atxiOFJbKQtyZTzogUd4bS/sCDYest/6Z V1y2wy7bWIfXE99PGLZuoSqf9Bdk5UtMU698dP35qkJwa0rqZvs/vb9oKhcgQotkRmpOSjYBtg95 4S8o2bglI0QkdVFlYoEJQkFKrEBul5uV6bZYlnz40XnnnXvjzTdP2nV34n3pDEEHmPCYdMzjbnG2 FT2fdE87P7SnZLXkaslUYtLju1qND3CzXttcWKYwetJd/nLBqZoFdQW5wS79K21a1T8c4mbJ4vV6 cAdJeCwI8W4HQMvETkkGvPzHAbKLbkR3gO6yZvhc143m6t+4vpmvIDfYVUSl2nK2PGgrOK1Z4ViM ORChuBNijMEhC+yGx6bK++KptATqMSkbDk9ndyQR7CbWgW/LH6EdMvSEAfJsCAE4Fmg7MmRGiu2b uEY3iW4eu98rvn89DHXRJU2c3ov9yumSTopJ18rY8aJIKAiynhdrllAAzM5sEFi4sUzCkMpwKE0V Rz/wXJSsinS19DjpcxnFSp3RhO1PTJrWL+k8//d6iCbGZSe+KaeNrEgfIcpAg4kRn5AFt0E4IyDR bm9BvQyvDxwYmMDq8VrdXqvLY3G6iePTL4vDRZ5N3ldj+Gvy8bi4/BBlAS9EABncD536Tq7uLV3V 249sbxgzAaJxeyz0vz2M28moH2XUNRk5d74TaARhYJiwnAK9pMCngjmVMLWelyBMMYc+LxGBVni2 zzwJP+tJ1Lytl/FQM6tu0yY1Pe997ucfbpyytCYwSS5BHSHgnaSZnNEwLJ5MAiFNhk/B5YUVAT0i wMnqdKPZSAco363kSNnE9nZPP8Xqcdr8Lqmg6XDLMgQW32nH+JnsaLfVNeISppmKzpcIqwc44Moq /aR8dev7y0dXzuTaoceUaf7vv2ZLi0JvhJrCFVcF6QhvB9JEMrD8XofXzXzhmRDe4MVihE/gVrXs lBSxJ3Cq+3wKXBYcN9EOo5nMsIZG/6hRkoPDcqOKC214Ba9IVmLfSw/h/3Jo+J0ENx0lYUfAf6n7 oArIMhN6brTgHnpS9f381aK/ChPQlujaIrhZLVbei+BWS5b/2yG8MH2pA6VlUC6M+i8h7tfHAr4i icHtCrg9NS5PgCoInZ3BYDTR0tG9qqWtMxzpCIXbg8F5v85atXxlVxRsj2CCvRa50tQ0ssafZ+VI NcKi8NVeJv04PUY4Q7FtTw9dLDAg7p3UPrb7PSwwubuvrCwNR9NU1q8IAkFFA7XHUec3wBTyu4x6 n1HjMhrdRrPHaEYkeeRzlAH8Z6Sj6Y1CNo8Bti69SEoUKH9iBVOWCMtkDbARCv21zBawLrfXg1xz +wUZGj0auWCJRwtouCDV1dfhsyZuiZfFif5bfGWJ3HOyKtxwkvwFKbDnZXV6bIF6B1UObPZYVyeG F4GhZb7dqmav0LZyW9Y0L6o/jN3lszjc1oYGS42/+5X3ntlt+pNb7fbwBjs+u+dhtpaws6GeBrQs 6EPznn9IOkaP1FY5eAINiAhANMJzMrV9r/KFoBXzCmnVn858MuCOKL9kXwLTSqQMLxdpMf6mRruu j4GYI0nP5bcyQJfPxgtaKRkkk0Fii0rDKR9Wn2mleKbLYQOVkS0QoZ/P29k/UomGujofO5y/xumv p7XivJYxsyZsiSUqWKX0Tz3w0urWkzIgX+m1z4B0m6U1OyDpdJtajldc5fczftYXCoSkZbLKAO2T FagutRiFqDBZkXVlswv4/RDYT6YuLCV4W56EyxXs6srCroTtc8JmM1RSSNU+kkTX8sEiCYX/V9Mz Wa4R/06Cm0dCQZMgG4Op92YLCOjjUk+tIzOHBZOGywFti2/cfdthm2x47MYbn7zxJodPXOP4yVOO mzz1sIlrXXvKGUdvvNkRa6x55mab/ueIQz+86/b3H3mobdny/om3q2PwIm6SLDQzYxKFtXJ2l3SH X/oieOfrydvfWHn7i4lXvy4W2C0P4zLXtqm7TDsOilWjFNIkeaaqbNugV9Ycz9bW1Un9QIwT/9uV zc1/+8MRNs8+u0zffYtdGzrjRmtQ2Hh1gm81gJ+Z54uAM3enmdZK92SjsUyX2KAxvlELZkjKieg2 07iCfVAXhw/DEhvSk2yuSbVgh8iI79utoi3GnI2bZs3xi/meSm9CJDBjIklnvv1yxnsvv/bmfx/6 6tVXOa+wBVbQcMCZNemlGGI6TA7KzIQOdQ8xjGLqE5ANcZhwNMauq0uoyj95qQSEZDYbJ1cd2ADW MFYkSWzGsCvQTgUgH/k0L5F+VIoVY28mRc1QAoApWQqcM9OJ34+PZXXBpwLSqGqqCoElrFOeRFPy 0rAEUoxVcyEFVblDV2ItXv3L70p4kBixVfFT8CSZNnnWypa2MWPG337PvU+9/Mrzb7/9zJtvvPjJ R8+/897l11//4Zdfvfrhh0eefOrclvYn7rn343ffX2ODjf2q6lWpyKn0q1jMtFijlIixDInb6iXd lN7LLVLAleEJhjtlWin/oO6nNi7j1XH0jESNDluNyuIvxJGEBu6+VEHXE5jf+tIF13z0jztn3fPs Z1ffM+fu54xomtHEjGRbLhkFFlvoKoQrf4kLX02Xqr6qyrTi+FWhbUJGKC3GT8meAMVSZq1Y9Jjn C5yAgjaWX8gsq9uowxg3ClGjEOM9KNESYA3kqEoJsduBIkWVU/HSuCs1mK+0IsgE6onY6tUEFivz lneVmwRXCd+mgOLnSY7PaQgkPlHSRqGiVBaNFaO0KkIN0ZLZJJWI1U8yfp/fPa655o6zR1xzcra1 u+BQoYEq/l4KK6vqh8WCvgxPvcpqPZOUTW9k1qRMhnpxg3gX1HzyQ2glbA/dJFoxl7YYYLBBGV4J RSU+l6LIinz8SqL4FT1V3KNGey42rd8Q0id8TI6F6lYam3XAb6uro9vo4jU19TJ9yAyZRsXArC6p nqyKWvMbXfpX00eFvvZhA6nBXSx5i1dBgH1S6Ugy7hg5XJNLDU3NtdTdltXLJzbYU3WHsehBybjU C57Rb/QrnEnFKNfLigYLVn3Ce27mVxCEig+yUHg+aBkC3p2MRyWbLy1VPYVrY/lsMJ2M53PxXJYg Laiq2jGSNkuIJSMz1XuVShL3DlBkjsytiAo18NL9+o2isCaIDM5f4+NpuUTszhtvvODU0x68/T9f z5w5bNIku0sshGKRL6uHLn4Zvcw1KxOCTA62zKtJFWwA0fp7OCfZ9BL57JzZs7tCoY232NTnDWQg bEJChsUxYreQYkfUFCqHxGemMzj7UCux0zpIOYrEKW+KTzGXSjt83nA6bvW5krmsH39hOuP2OuN5 /vpBSfQ4XcBFuXKYRlzJzmguQ006V9ZjlyQrwK456+QKxGcKCAJcYk0ncik5Abmc5KQqGGgxqkr8 q0oXqDA/4VDVRh6MegG/L9LVPqymFscauT2vP/P8Aw888M4XnxeyKUvAmwSEKZPnlMqpsyeQxoJX Nk5ly3SmpqYW24BArfYoN/xX6nAT3iTnKTFHwO+JfFIhaxTx7KVDoK+wvMn1zWaGu4cDvoCYhoPF UxaOLP7s01H1w1NLVtU5vcb4sekmTw5nkSWVrXHhEXMbdveKkLU9Z4Qy/51+6A73/mPS1KkrH3ut 9YdfN7rlukJN5McJzhVGboRhXztScAezyaaA5B6oi/+I9blHGeQY40rh7lQo2yATAWJsM7IYqa2F rLg3La50wRtNi4lGqpZjR89jOc5S/Rg4I+X/xK6eshphmwgpl2GpTWUDXckGh48aof4Rw9595+UH /vbXp9983er3pil+4PWBBiDwxnhjqYFQsHdlwuJWUEWgWQNMmz4464tSBc5M2oltN5rsjCcP3Wqb Nz/9xFVfRzp5zuuAprCSuBx7LhYYxf/EFGtYQuFwXS2pQN2ubM5Hoc5lkV//9fiKQmj3G6/MfvHz 28dcuNf7d1vXWTNq2JniuCXvwGwt5QXSbiw3OH1Fs88n/eLZ0Lqj8kHF6apUN7aJ184TtzmS9rzd iDqMlN1IAVLtFC+9SEuBbSrwYIVlTuy/EMeeyrmyBbJB3GkBesy6LHGonRMoea3HCS6ozqhAclos XfasO1sIgGwOtLU9H7KkSFgI2G3+7ugj19w8r6XtynvvgnBA6SMFMQgQCy+6iA5VhsYZ8dJow5GK MtaLonihR+QotSxw5gWqcVszSX993Q6bbXrRBRfut8+ewiGWprzLEXQVUtRjzlk80YwHE6HVmnQZ Qao3e0gbJj+1gIcFpRTRzxh1EQpxxFstkUSczBdCEtlwvDiKSEQgn4q8MGA2LfBJstmwpWKxcGf3 yMlrxdvb8Ur5fYF4W6vXH0jEovHmxkgmHcBVCAK4WMjsoUzC4fWFLelwNjHWGvACC1V2XCpnGy1q dYwAgyYyRNS4stAmorVxNOXhOFQRyZ7O4xVJdXXVeL1H7rXPnnvuvfcpp7ans34vfgCMSmI0wrqg 6nvLForFrBzjnseRiMAK+r8UCza++OKL5cuXE0FJcOj/dxex0jNmfPXUs89oF2X5FU4lI9TTNHFB ypbWdrmR+ApUxXASAF/292R3uP+v093RbMJUs90ce6hBY+IChaa9q7Pixkevu3GfKRv0/3U2hljX 6ZlVLlALorFotbuK37d2rBQdruxa+MBLj9RvMWPiPu8b6y8Zvmfi3FsKiUwhnMh/PQutQ65ErhDN FELxwtuLXjQ26n78Sz7rOuHGRaMO4zYhZzi4PNEmSkK1iykIt3dXu6v4fRSAY0SEmaszWfhhOTd+ /uQL60sqdXKIH3WFgqywqq3Of+fDaY5A6IfZVe/kBgorI7j73JkptG11/pKDL5UPF6xsMzbPv/iV 0CqbbY9GzLTJPcFIRzIF6F71S9TjNtPNBsNoEtUbLRQWhRdHMl3cecvJJ5+/735D/CSWioXCQTNt oueDTKDZZv9NNn7y2quG+FU+kkwnTHUVpbow39QyzC1vK3zzW2FJZyEYL4RThe4hKbwiDBSPmXHF knFYy8yd3LN8+UKWC9Dwh26y4RPX/3OIX8U5G8RjFTckU8ApBv8HeUs4CrjZN9100+9kKmGTURBe AxwNJCXXnH0JHUOhjVHoO7nqD/8w1j3OMvU4Y93jv735ITmm9b0EwMWk0VAqTpmigxyp+4+A+tzx AXDGUeTL0+QGOO30fKQdOEPcUP6VqEN9AVu8Luc6Iydsft0lO796r6Oh8d2Hn/ly33M+Ofj8X657 yJDYaCNxzXMzdj1z9s5/7L7pAa/L68wK+FRuZF1Xk6ugtNWEw5Ki7ocJC6ecVkzcpjssByUTiUJy q70QdonKGnLkPDhjh5w4KS5iog/shdgiasxVjhcDa0WjNmJKEx3xiHSP8CTDzRlPBmW1SDUXc5fS WU3NLCFJjv4oNoM+RSefVr98fj8RLdzH+dxLiMXgv1BF5sxdnPOUJo5SCvRdFb5RTk9T7dIkRyUT V+u73/1626PvHHbBD3udO+vAS40H3x/iRwk7pXlMdUD0dNOmC6eVdkmidtTX1kk9oMEvkXv9Jkvc WuYYY7CGbSeddBK5iKVKCCbo9r/cgoLQvrIFgKUxtY2cMi2JbDTFXpzMJ5JOTnZxDGRWI479JCu1 usPp/LJ2S4Jjks2Ix6PJaNKS6wx35yKJWqABIjljeejX6x7wjltz2bpr/pgNdnW0rLnGOtbmJrIV jURK7LzL2izprBULBFFQ6XhXJh515IOFVNhIRwtprGDZWDIRiXI2YiPAdCzg+Jjw0qg9aNXk3iqM S/1eUnEzccAHxFpiTyUSHE4TwS4nvwT3OZVbNnvujz/+cNRhRxYEkTyfj0XSSc4BAi2bT2dAcWX1 ijk/mca0wjkO83YKO75uWT+FhJNMlpIY2O/4n4XiOOGIJZ7IJzCixQHiSFHbLJWkDkU2EuaA2RYO OomYSeeNVTEj65731pftKxZOnn6YMXKMe8pIZ1P98JETYp3hhe99OmWDXYxgTfihx4MLl47edPOw Je9ZZ+KIo/eytnfNmzfnt3D7etO2wFTT7Te6bbmkJWMDijYYRUmmG8WxZzLJOLYB8n74fwrFUAqN gTtIP1OAqqfopyWRMWJpeUXSWO/I9U8A0kqHLWJel4M5SUNoiAnmN22Jg3GUDhfSXdZ0hINxMpUL x6xeR6s3H3R5Z7cvWPzuJ8cceyx2omzrigwcglmQB6Vy8IwlYURiEalkiI1ZpUjTJTHBq95CUaiU iccx7hiJjCMQeOqxR9cYP27x9z/N//Z77N2Ez5ADlhI7ac/kptOxaBRbNUubN8DuWLtDBi8qnc1f 2T53Qas1NnHXXfJf//bVU09NOOMwIvQ50mO+YIiJTCqaS0ayiSgGVxCX08kMKI+5ZDadyGQBScWm xYSKVyKDVwIoFoDy+BlumHiSlyWStEaSimgpI5IAn52YUnHHMKKM8Ae0DmWSnflEh5FqMZItmBvT aXcoib8RMGJrJl1IpS1Y8HteZBK0ULCPaOpIyhJLwG0RazISDlEy2ZNKzf3sq5bOzp332IOAy0I0 zLCxQ6ToezrOmSCVjmODpb8QlE5AWtQOYcoSi+JQYnxgTJMhwUEWkoVCzqbGp+6+Z5uddlpr5Ajq VnB7yJJps6U7LNJ5eyTl6E4AjG7JpqPQJ4vpS8YVz3MrhkqWYTrJC7TqbNpGt1tV+d1I1uiKSPg8 iwIuyqRjoDHiHAmG7am8pT1hrEwv/eT7RQ+/sPnmOw83PMtmfks8afqXztjM3xJzVnoDTTjDsLYk jExLKpx2GDFMRvEIgUexSAzqCGMqXhYPSc8aFFZKCaox9E8lU2K9BLUkQY0auZ9XliyNlOAiICDk H+kEITtOTEvx2L3/vmXdzTebts22iAjBRJaCmNBYOBP7u2hvqhxliUs1RcPdQYQQOnuFxaaqbEXg 04uff/55NWzc/KYU9ayTaMQgS84bNXjKrOza7KhsZLIta1MR73/99ofOpSv3PPIQwbkXkARxJ0rN 7GBUrFzD6xY8/OKCYPvuD39P/FZoXIPn0N2ch25rJBHD4CHZMBVhnhZRNbHe+K17yeTdhj13l/fg zdrvf9N5ylXONdfwNDQu2G0tz+6bj9p+cwmWWNhheBxGc0Aq5YnVsCdNQ2FQKBAeqVaHyzTaHaIn /tqa8rwpjVQhGpaCqtDF7vhJOBSqa2xgMlS4gNgoX/r37Xfccuu7S+Yjs+Qp4vDEwuYgbY+QW+Lz xd7bc7TX6QkS1d5rNrbEI1HI5VdosbIRE6iv4YY1Rof0QOmD/AOz7uIV1slj0ys65r783vwPZ7hY 7sGoNZPa575/GWuPVM5IYPFswYe++vRvf193ykbRcCKx4LfR66097qN/g30l9kXasRkfX3bLqq9+ OOKNhwwHFb5DoVzMX9OEYR33KwZsPZ/KUitB3j38xA6EYIzW1NapGAApy1skkuQTqZALei9YGaKa RqPdbhR8p0sIrm/UtyF5cTwoTVRaAGIsmVre1TJq/OTH3njqoaNPf2/xEhvUSIH4kCeUS6mXMnzZ X408QVeB2hpxZsJ2Ku292Ak1TZhBVbKLrXXWnLPOOHP2L7NGjxq5dMWKPxxx5F/vuFUYUcpF9oaG 8BOAZ7Gq4RWv46HkKDF4gKqjqVlH/LW12b7TIzclv5v72SaH7PrT68bkcQbOzkjMGKZ0Q7wy0gc9 Qeqv1Lkt6lfMZFd7q9vr9XjIj1cfQxv4qEQKNd+KCgUEYyQRqWscLjA1PYwntqsecAw+1bhg0npn 2KAaGRFsfTXElML/BxtHMS2QU4XW2KpGYi1djbedcPKK9vZ/vvCs8BfcqNw4mgyKxyypBI69PPZi 3adioV41FLlZ2EDXzBQmTLW1e4c3FULh/Xbc8Y9nn7HHaWewZVIQByVFYzBJhoAY7Q2jNSqA6fXE U8thReZfJ08VMUCKbIZKtPLmZxd88U0+4FoebB+78QZbnHm0q7GWr5XvIIf3AjAd0ckcll8veSz/ /Ovrv/ekQS3b06597bvPgqk4EnXslCkH3HWdscVE5DDIXmk2D5s9Ee7Eq+Fz+3CWFlV/1S+p/aux gPQFMF0C3SrNMtT1bBXofW8/UZx1+o2qCmvpXrnUV1vvTKbPPvTQ7Xfa6YjLrxDoMVm9cnRRy0cL xUIiGmMe4VhdFFN7P4C/RzASSmj+qK27udoJOFrSP/PMM0Bsv/nmm/z+s88+u/fee/knlprSMZM3 /JNiC+gvv82bv+C3BfpYy4Dqa2pqHJRwBovGarjEgE9YpMKwtxkeCTXNh7ObnncbxzAjFF7x5sfh 97+WnrrtFjfQXaxfV2rxqtjMuSt/mtUya06NkV8xQloetv1GH2w32dPYZFCl4Zn3v5sxs23RspWz 5idnzDFsXvYAIA0l/pIoM/3C/SJR4zQokQx0OOALkJoBwfln6cViFkA3RIDELiOH5Wamzg8IDsGe JIBQ/1QgpAQmiSADGSP95DaXWxytNlIW+S95i1LzVGrQEvzJNq0SanT5ElqWlxXMcIlj1o+W2GtE EpGhvOQRABzKX6LHgas3PC5ruoYMEWfME7v0ofWWpicutU1IBHbZZl+D6poIZTf3SEBS7brNYw/b bYE7ER/ptu+5eeOhCiKG/sqBVN6u15LfcpkRe/vL7s9+sL0xv2lJnVtSRxzQWaX6FcfOex11rcN9 JVaYGilCQofk9dAledFhu6xPj53cGbyRKlbeDpQDv4CscieY+rz0naqGhjShwve52ZLzj02NoV97 2kakguEckbCIQOL93V6Bq2eaCDRGmNKYww7EnZBPRcby+96ZUvHw3ro6wmvtXu/oTTd+6Zuv5ibC HyyYe8Ypp65cuMROIoyHvCQ1pz0v5oUpwKjjxyFJXC2PBj2ZHByvb9zS/NS42Bncw5p2dq1x92Z7 3rnWto9suOvnJ19YHHixD0IXcUqRlEB4jE3+8sKk1RCo8biAImJahQ7CfZCLMyUvZooX1OCFi9Ln jnkk01X4TL2E8JBGxahTX9ILLekVP5d0D4UYXKKqpi3xxFJlAQQpeJ4kBubAWU+EtXLeUp8gg6as ij9QDRpnGTewBvUypGV4k0frJyv6KG4svpfyEeI4lxvlr495oYXmYZ2trdS/kIIGXuLfGbssMVmu VsUbDNPwGNEsfZaByzxCimLTMvs9I6WHrmueGf3GnIlfdOzW5g///YHca1/FZvya/WaO7edlyhVv T/28MPbzvOCXP9cuXdZCZYJ6w5gQCDz9zyPbPjkjPPPsm+8b+f0cY3E8+Pn3hVlLjdnLvDCiYa3t 8AZyLhahBKvrBwoh6UYPh+tlyL+oVyX/AQCiOF6hphIVUjQDNilKA5zuNtzXDo/fWlsXDVGSSSKX iCiXaG8YVfhJ58tKawRNeCTyQgohFVe9zYpGB8+srtTu2WSUBC//xxDvEXDsINQko1Iw6Kyo3nfd ddfcuXOxlHOmKPWAhT1v3rzzzz//159+Pue0Mx598CGPrpDAJmxYPOyZ/S+8/Govmrwy1cB/Prkt O/th/4h6328rF1xya/t1jyTvfMGY3cI3X11y/SvXXWufdoxr+plf7LGho1aV911rxP5v3Wt8dWv2 81snHbDbRpfcm1/jEMcGR6bue9ZYtNTM6NKxuGClmrgkmKffnSgXzFj/X6ujRl+NaJBHkMXOojLx fHUL4Qhc6fSajrrRf5g+5bub1//oFveVRxij+yDQWzaZuOEFJ+7x2H+2fvaGzR64wnfyvhXt19TV LIl0fnnwJd/u9sf3z/lL/LWhDIWl36JzcPg32VUrJouKOortQePfL6XPuWP5yf9sOf/WzovvXHnq 9S1n/iv1z/8aX8+UYXUGGwN1Q8dxo+WatJomVq4oJMX9EI/FGvxDIfRL7GVFwUOnJWUpRDLKS0B+ 71GHHnzRHw8/9JBd195gZLZ6+WNNomQsQQydGXIRi+LrX/LiuRnZP94RPf76/Ek3G39+0ljUgwoS An3UVKo0xgGtVbB4SSTpi43Yt18D+m8G6Tr4i/qbUcNHfvXOOw9e/vcnrrp69uPP5YPKJVC6lrYZ Dz73263//eZPN3Zecodx85tDkMKSSa5x8MHjfryr+aIT1ps06dPT/j5z9zNm7Hpa17l3G6mCsTKy 4JhrPtjptDd2O2XGz18t9WJTVY3VFQ84aXss5fK9e/yJb2975MfTz1l09vXFZ7GyTIP4m6zRKi2r IDTsCcT3UP5wiHFJLKGAb/a5BOvTdJnZARs3K7j5MVsIJW8+/fRTSkcinbGMU0WBiBTKKSCvdevI d84FVCl78vEnutvbBWFCxfUTzJcMRX9686PodwsMoGgjBWwgBvgAbd3GNz8lP/git3B5LBlpDzQb i1fYE5nwHhtbVrRPevWXwPVPf3jlLfmvFxbmLW20udYZOar5p7fqP35ss7+fNWHiRBGMiSRhenAn IBOBQ3Yf/e0rI35+rXD5eYSKGOGMeOfiOSNdMKJxIxE3kvFCKg6gkZTvlMpOSczQ2Lck/heLU1oA 0vgckDAKumOK1i92VO5kCIRPI7gxy3KKxyNRiCf5m+Ee5oDIxVgiG47QnyzGaMzBBJPKt/JSwbJI vOKr1DJveCI3s8CkffVQbJfIZR6BTRDTsBgxqc0RkQDK4GUPzrro0qXjDlp+wGnfujqiNYSrcihN Z5zppCWL7AfXKsahVcKWs0kCYTNB4qTzOeynYpsmximZiOVh5WTaeepBOzz5711ff2DXNx/ravas IK46mjFYkNChbOzQAesBJ3lMqPyV0o15bKGcTDElJxisEUvJD2N5ie+D2nQiHDVA1eHkmEhbY1HO T0Z7lxFKGqFE8qdF719/64LPvgjPW7Di628XfPL5qu9+7vpu1jMP3bts4c/wT9zDw1PZ1jZaxqaf i8WIQJe5UCVycIFALpZKgTmSycKoTcd6ZyrPpGBMx5SaZGZTMSzsaufA/oNLwyDuP5ZkIH1mNiGU l0AdRoeMe+6rudOOfnvzQ97Z7JCfWn6KrkWhhkLBZzHuOrLh6hMabzqPRM/wqhYZMi8gTYQHEkIK edE4r5R+EVyPkRMTvyBXiP0dsmeNcNaYu8L47jfjh0XGT4uNnxcZXXGhIcaHRCYSDWYSkQL1RmDX jPHDAw9/9OBjy77+YcFnMz75z20zdz7+l62Pw2jTcv8TRkvYCMHSabmTmmSY/rFA47SBMkwitBLH DOZ38QNAgRq3F9usgXMC7mKwmHTxqAOHK+Zo/BBpbHxYllkOfehZRluaxXwM2ZkLYpoNft4V3Gbr rbs6O+d/NfPZe+69/fIr4stWGHRevgoZyYIxb9WMx59Z/M5HiU+/X/DU6x33PG78ttL4rUX+didw ZRnd8fzPvxnzVhgt3b+Mtq7MLxZxPME38emb9/jwqR2eu8u5zZS53QuNmb8W3p9h7wjtffLJR73z 6sGP3X383f8oMHjM5RilxXGUte6z4fZfP73b6/89/NtPJ2yyrndss+DiRzHgsApwFCWKDAPPqFf5 AldDFt4m0lFTAL7StxVf8Ay42uCfsUhFDuBdSIKuK5gWuQLF4aBw3/aFURWnEflMYoBeQUVG5T0h Z8JsEur6P15mdQcxvVks77///rJly6hMhs3k/vvv7+zsnDFjxkMPPXTooYfq57OxU8t86222GT6s +aLzLvzyu2/YbzgmUM1++fxFy5Yv/+359yb5f0mGw57Nx/qnTDFmLVj02puzv5iJKOnIJgIbjjkw mjeWdk898jBjz7jh9LmWrqz9y5Xzrv4X8qjVa6y381aGPWeMbWr2eHMLltvGjM61tdqahxshnDCG 0VhHyDLQFjG3a/GCeaPf/DT31cwuv1E/bU3XWuOxumVV/Cy6hSNH4Q5/OhyWhFZOtZyVowQlK4sH Aa04E1KpHrVODDI4FORULiCtllRHtyAbsOVicWvvbG5qXnPNNY1VnYIEwuptqGUZEM7GcUwCvdXM 4H0unyF7j8JS3OxAii6gbIZ1eImU2bGLHVBshYS7ouBafUZnDDFhbYvlggnvblvnnNmNahwNY0fm lyzPBFy5utpQMm4l2Llg9bCvkOtAkLvVIU43XG0+D9jYIsJ4gGigzmxX0NbYaBnlN5KYDn3Ls9H1 R9XJimoCAlTKOChgZW2okzOgTssQpB2nwK92xVsCOZsfMZ3Ge2wxflse+vIHazwfcPjydU7rrusY Y7G2pyzAWSBWiNkPpwR9KO9yt2RcTYF1/3CwMW2qkYgZHLaYr8WLlz9yr2NYnbFkKXHCo8aMtS5Y KmBYnI+x/nt8UpWXgGSB3AbpibKTZBbhVinym2y6xUtcJxIAglM0l/HWkN6NAyltS5B7UmtvTBrd pPYQXUytg6JVXCVDgDMnR2NxKy3rtsZsy5KhtXbdMRTsnrjljunJw3Jty2yMscOVn5i1dTstw+pG WCYYP64wRjYY4ZXGsADYL4CXZSRQmyrUZaBxADNhe2HbZh+l77m8nen7fNaSNz8Ifv2rLZL2er1j J09w33ylMabO14Xcz3Vl2rwjRlk6I4a1Bn5uTUbWPeHQcfvuh7PU9cwzgQQpRb5l8+es/GH2iKAa szUmywHvHWLV5UwEmp1ZiyctWUj0KhjrqBvRgN8v/9s8H2nbaFfsoESU1wZwgMOc9roAXjNx0ItR hDoahSzu/UGOiZhmMBaQ14SNHMuPqFwNdedecBGOQFdt7Q+ffPT4fQ+5YNvuLoNAi8UthiORmr8K 1K5dL77QGNbQ/tp7nU+/tmqr4+ONvi5XbpdTjnduvVVm/m9vXPmPBqs32Na+crRnzOZjZVcLKKEU zxp1Da51Jiz55Y2fz7zS25mxZSw2t6vAgcuRafVb/a5cOItzPufJWTByRaIrmpsajdqRRtYZ7w51 LG8ddsUDyYCtfZR3zNQ1nSNHFhy+kidOUOYyRIeXC00V/UI8hKKAAMaVfy343CxL/CESyo2VHvej S+p5iY4ux5qYqBdl6GPiDUD0aWeBZAyVEZaWM3GxUginek0F0vSX7mYFNxIZlHeM16NHj9bx+ajV 5JUgx+G/8naxnBBeftVjj733wqvW7xV0XC7vGd28/nZb2D7/ddS/nkoB2B9Pdu2/if/5bY1GR8fN t49eb61pfzxFEs1ScWPtEUbAbazdXFThf/VvfefVooFSviCbsA5rMNYdqb+yjRBvnq1hgvyjoQ+a 4vjdpyVfmtz60Ue++as6vcb8M3ffbre/cBejLR+wt0alOUVRKjNGnbd0+sDYajP6HH+K1GVbTqSc zSOKfeM/w2qXPfTIr9//aIwbBhvoxrmZF8XufI31psxY6E3kbTDqsqsycxZ0EZxSN66qdTY0PXBR +Z36yEheT/FDf0877UEiGpzDpWNc+q++yTqmSF75R0tmbNha15YxNizWZux/CFcEkYuziCsda/St Ud6BlY8+PeuVD4bn7d6M5ZuupWtFDtj4ikuN7iD+PWPsGO7MPfPuL48/X2fzO+JZ26pQHqSsXdYq a2Hi5Ctuci9oMcaPq/nimyUL5lq32xz5IvRsqqxMxhzlqbrZ6Bd79OCXRsv2BIgqyjo8rqVLlxQ6 wsYIRj9IoS1CIFhezc78x9+tPS829phjjI2Ks1x8yARxEBiNRmTpgoVdLSO2maA+L5pf6NWAZSWd IAtquBV9DTNs64xdY8oYMfvG05lH3//qpaemXvef1niXZ0x9887bNxy5q/HlrBUPPJVo6arxNdh/ WWL3jzZ2n8xPx+11RbGN426Z9cyDzf+4pq0Qd4watu4xB9i32JgOaK4rv0Y11kUiqzCKW9dcq43p QOZMkOlQHS/aZUozSwgTEtleK2uq+rWy25gwitvsUyZrng9+ap2zcE6bxzl6/IRsZ4d90mh8lamF ro5IlzHSYey27jCvc9i22xjRoNHZ+v2/7gGzyth4pPHqe81tia3+dTFAYOF0d83ktYx1Rvc+vWBs sNeeG2yyBVE34p9paDQ2HWdZoxHGsEZa7VbPGKe/NGbP2o2lH05zjl058+vgktdXFqKzLKHmj550 jRhZERLYf77kPJFIDYHHXc5wjkw6P3wE1e5xENciEHwum6+yyeKSQevHxxzoI6ACSR+wX6gp5gMQ KybFrKmE7fr777+/8sorjznmGELHKRl88803//3vf6cE8Hbbbaf2FrmQ75i/dUXgUD45dbNNqPWg v2hrbXXusom767XAkhc/vHCfcV+tML5cmX/z59a8pXb/XYzt1zN23MDYY8sK+WWsN8o4ZFvjqJ35 az1iN2ODSdW5inmdtvYaD/6l7sVrbR2vrrfJpk0Luof6FfEtaLz0cUW78dmvxqdzjc9+M17/yvhu ceWvBARQag6VX676gL1hAHZXycWmTkLkhpFVONjVpwki9erdYvkxcWW9Lqup4rNp28haCbUrv3jC jPnG+z8aL3xqvPO98fEsI1y0OVg4ofe9PPXjkitXrf/m3ZPeunvEJlMT9707f/0j5m98bPeR1xh3 f2E89mPwtleSn8+pSxrtLatqDt4tvsnafZ9VaLTXeb0iBFM4sbwBMfUMfsWIMDIxfMJsO3NJj6KA M+DyTRAHymBXtqMrp0CTC3W+7vE1Og9ywCswdgraXuVXizuMH9tyr35nvPOL8e4vxnfLtdum0J3I VcT4o/BuO83YcxPjoK2SJ+45/LSj5oc7OHl889zH6VkhaXZ254wn34+GMh2JuH+HzX27by6beunK 5t37rT/q2H0XGMlILDX3vS8XvvbxEOMK2P2kmwphDVuW8J7BbyXhnixzE3QVTIGYgJX2udfnCmzs HhHgDBqKx/56/xfbnvj1psd8e/Ft1obhKe3Z2mGSceTGxik75y490l7rS332nfHx0nxrR2p4IH/C rsYhW9cctY8xrqlPo3R3t2nG0Tsap+9lnL6rcdhGxhoinYmwJIOemvCD9vbRi0bNfaJ51iMb3npV fdxr51hZ9UIBf3umdcac/NtfG1/MMb6aayxoG+JHdqtfIIPw1NqcYYUGMyhr2dVprO9FCTR8uv+z 1Kax1QgHxFZQCvcmt630Hqmti63oSwOekeHDERt9k69kgAXLgh9nxbq6tth3DywMXz72QtftL6z3 /Vzyon/ccMIGl50x6aAdxASJ+UElRgtgcF/O0FIQm75AahNvO2T4Oikq3aHlNQWOh7XB4/8ec7tH P3qV0UXuMCGwrCemXEIMZT8RMIlCZsUq91oT21/84Mvzr9toaSs2+fk1/k0v/mPgnKMMiY/CKJ9Q P8R0GCdy0HCq/VOsVLmX773/jjvueGfer7LAVIQVvjPO4BgcJVdGZSdXSPCKXA9BP5C6Wup0RjCl HLPw1GtyWrKzl7a+9FV8UShLMcUfvnStOXz9B6/IAfLXI74G3B4ksU0wvpV1p+8lFdCkYWLLMOpZ yYN/5ICjN9tt73XPOkJMM5hpEJvJ/G/nXTXjhZfHNg0DDpRJPOSnr4yJtcayVsOdMxrrjWA0fv/r mZgt8sNsihAGWxZs9t7DWFpWvPC6f25Xrd2bX7ri46efx9xZ8Lo67flNj5g+8drzcJAVZQdjDCUz wGPjMeuILxpz4PBLjvBedcKvzz5z/qmnvb5kiSPgw1QNoANxILr0puqyRbDDsXjhke+hajkxBVkX b4WUnuRgy1Eq6otl/PXDrj7uD8F45KZnX5Ko/Z4QNxpU5eCkYTwC5Ar4bR7LUx+/ePHlh732sDF1 YjoepYISrEYAGC1LPKnD2nHCv2f89PU+3z4pIdg6RpOo0wfee++cK70ogs5CVy6990kn1F51moF4 X94tcIw+Oy4ejvmwHDzCYNATJCCUUJCe6+v1jmsaMdo9YnIhE13x1Webfv6gdWzPQZZkd9wKkrMh MpgwE6MlZIyoNVojX+13YmNdk2P8RKLUUy5jwlUnJQNIZ0z62LUk/ynb3ukCCLCu5q4zLpyzdOlN zz3GwlEgKwXCRHTgoc6oIowPI6wQVldr61ddROxL/E4RTQBDiKJh+FlqpQoG7/xX3//yr9ftsNYG zklTW958y1Pwjt97z3iNM17nqt1945opI/GwEPjudHoLrd3fHXVhaPbiXGcwNMxvXWvEgU/fC1ZE WiCwCYeRk1b/p+su6YXPasF5AJJMqYpjMRxTRy5KzJwNb4eAYc9c+tIR5+73yL9tO69bPBMl6T6O mqRVom81wIWK5VweWXLyXz/88F1QcEdNmBBPJfe/+Tpjl00Uxq/VIGeilKEm2fpG/LeF1pHDQK+Z vvOO+x184GkX/b0CT7y06rVSq3EKi0taFaDQRXwqREHFUu3/z1I4oFlTCU3wJDLjS22Vvy9/gM4r 4RNd/VNfVGnEYplE+yB9Jp3afMcdwt4xhs+X9zp2TsVqx402WpLkpmFrSDtF/USAUMe2FGaJXCMY UQ9Sj59dYbAxy4pIJxxdMQfooCtaZztSc977ZO3tV+Ar8owbsfn+exuTJxjrjMVXmevowhZsq2+y OeuMbiM+Z0WqNuD++Hrf0pz7Pze9dd99ze+9G7EVaiaP2/7CPxpSMMxhpMGYyGcWLqJInTF8OPEK 44aPAuCVrAEYU5J4cll7wA9fK7AaqdOB7C6dSDQ1yjvPKDiUaBu6LBtJ8slgFE5TxBUujuWy85a9 fuO/1w+MbBzW1JYOrzt5U8ozShx5j2NDV3IqkVovPJ4oi1NtGxoItMg0GA9xL6I1WQq+XNYXI/Ok YI2ngWY2VmXEoN7RUXDWW8JRHDXb7LPfuFNPT/3808c33vDByWc77ba6hpr6qZNHn3SiEXN/decD HqurobFpVTravNX6he9nW9YdV7vhmu0bZRyNw7zpwuZ/3CsRJr2FzuYcw2rzzlQw2eXJePNWNx8G lkcy4zFPZW2/LE37FYr/ohbSHrCBWHFOGo1ZcqcotukgNBixiWGb3cxOcWEixQXahQWscgVKjnHY Qmof4+qzphJ+G4kC5KE4idRq6fSnqAXrMjpWJdyOdpHusloJJAdHxGP3dmdD0VQcGb1OIueavQJ5 Z3TEjY5oLhUybIEUALkFqyNndZIjFjV+c4S7RnqMn1ep8Eds9B5jZSq2shPU3K0v+kt+eOOP99z+ /huv1sz7ZVG4beLG6255+IH+DdcFp59hgasT1SUj8BxkDDcqTY50MxgdA3rzDwvmu2b/Ah60f8Iw y8IY+ayGNW3UEkWXi2fjBY+g9Vowp6Yj4mCcHcq1dLunrDH7i2+9P/wwbcz4Oe0rfFcf0ZlNeBy0 nbFm8w0OfyQTH+b127oEUMGHqCLHjfBH2a4k1joR5/hoybEyReBZ8MuxZjU9Yd2SEC9yjnZLSs1S bC4Faz5ZE6gtkDoHd6WzjYGGeFvXMttix7xFHd1d+1z0Z2P3nT1GupHIc6KL5rcbDUTGZQsdcRLr Nrz4nGx3Iu/xghNrrXEASmKEIiDYZN0u4vb100sYwvrp9B8JwIyzdnSZt/LyHZxv3IDnCECOkjbo TEigUN6oqY01e9++8J/gpbS50rsdsv+kww4wPJZcuJuNhLwysqjwctRiTWu3xbOFnXbba/ypZ4S+ /vzF665rfeHNVXc91B4Jb7XV1v5jjzImNBHaoCJuRQ+1D69Hw0pkE+3OfK7eA2lIryq5B3TnJdOm p0YKOK7lglvXmxZ17X9Fdl0NjbtcOq/eezTYRHrVoiULZ8/b+5jDC5S7FdeTylVAyABPD54DLiM3 KgApCrL583HFOULPEzOnh1qWFdKvLxJznrKxx7hI4sgZH/+0/LOvf1vVjtfN+el3Decc1TV+pLXZ 47c5Jm+/tRHKtb32YUtLl7+2ruvbbyd+NbfhhgssG21gvP7pbx9/lKnxty5baP3k+4YzDvJutH4k lgA2vm7MiITfR8rGpEmT6tdf852bb//3bbe9uWyupHvp45sqIcrc6AoJeobKe1n+T/FUKGxCXVNC bpNSNUoL0O6Rr5e9Nf34PZ++y9huLWMFhuOosebwLPt/2QZevoeVtje9pcNDFboA5mOtajlwOEPr 9tSbB5+w/p7Tx5x+UOHN91/4xw0ty1c11tbhRt/t2KOHXXW+8cvC9Ec/fPf1F4HG2tY5s7zRzJYn nkqx1B/uuGPbSy+0nLWPRJKgHTL8bJJQbkl1Ry3D6RXBM1kwGhvQcQqJWM5JeXCqyzukBh9uO+oc EK0BGFh3bsUWp/mP2r726pO/ffyxy84975UFC0EeJ+XPcHmI4pFANZW8AV+Iyt1TKBZ+UN7F3qOZ 5HNJYRcSNtCLgD0M+XCf1gfu3vuIgNNx9EuPCmHxCRV9k/QZWzMLNm9DQyVw3u/JPfjOR9fesstT dxlYopFgoGipJyuNWwJ937n0uvYVq46+9xYjXuh+73PSWknJSf40u+PL7za773qjtsl47u3ffv0x 7rWRjNrQXLPW/ru6pk5Wa57EKEqlFxV+Mc6JuxULBb5Btk88vWIEl75pW5ScHaS4hAR64/emGxLy lJZUaZQ4VgGnJVxb3Ey4zv1vP/v3M48qLA4aFB0X8D6+xjGb7uquq2mwF6zXn3NBdzz+j/vuJiRZ 55YQtV9MwFGJFhBBKiWpU7Im6QC0lQrKTCmuuRRaBqoDUROEj6PiLn/vi8WX3rztA7cZ64wR3VY0 NzYoyqGDXFWw+EhEAA0ylCPt0xMw3D7pvFCAMaIusBskCz4XlCjVAKp8ulJOtaTTR/yKsp8EGol4 V9k9sjWT2QtvL+9e/OGM9nlLfVl7+POvQ5HObS78I5moroaakdtuaAzHsdyzLud3LjrqoubNpvlu Ps94c96yd97qisesJD62rMyGujf862Ud3RFSTZ1kSzjB/kmO8zjsW65Lt0/Yb7/9jzrswD/9WaD+ +i1JyccmoEhVEajQuCVqY3WwLnRHSxr37yK4eZ7d1rFs1awfftjz0IMqBW04GQoGa8f19QUNtDMw bZT+pP63mW0jt2y5zeuXOBMWPhdr4/1Z3zz40ORXfsxHYqHR9XOmb7TXHVfB929seWjayO/5S3eK +LnLTnKfdYBreCNqtaw0uxH7etY35/1j069XwvHfjnWvmty077vLyA1etPHYUZedMnz6Ti/++Zq7 Hrj3nbYlFb3Cc0vKkZmUVn1uwvfbpwWlMkvqyltz3zjgxB1/fdo7STxLmbmLbZPHmfF56iNR9bK2 K8Mv73v8xhtvP/b+8+IPvfr13U9sevIxKOBWLBITRth2niaWJZaZ2lOi1z458/Hn8TG2hjvd44bv eOn53sO2GXQ6flwp0eVN1evqrhp9WO3xO3uvOf3bJx+/+ORT3+rqQoIM1iyxTISiViUsB+pw66p6 L5EG7qd3OyrTHTxm5htaGvW2rM9wpGfMbrE0+IzhNZl3Znx48l93f+tBY0rRVVvRje8uv33xjB8O eut+OOfldXa3gaBPqKjXNXHihM0fu9pCsh/hEOQKSXCLYbSlDDYnxFbVC9iA1owxoY+ff7AfhUmk qK2hMEvphs6Ln/j2xn/uXvil8ifEFGH7qvVdf/JZS1e13PH684O1CTgfnmc4tmpPoWB3W1vj8OZy EJIFL3/Qeso1W797nzGtj+OawHyScmy11cfFEmB1Nzb2+hgH6wkqkZYDpcPW4H0uGL+2GeMajIDD uOLZj+540OF1BYGg6eo47sW7jL03M779ben9L0UAsojHun+eP3brDde57zIjljF8RYke+dM9jz7+ 6EhfvT3hQdFnkabSsRXtK7fecZupT1yDjnLptC22OGS/A2+4erA+cJ6G6SqWIacHDg1mVnFFs6ud OVl1Ooe+AS4GzEGKPfa/mNYx1aW23m1MlkKXh/h9BuipWmSL3cwwtp4y9dJTala+XJ/4YOJZx2z6 0i+JT37MvTzDCMY22noHd/4D/5JXas862IWGyOUSqc3lW3/NHZ+42bn4aU/nW9t8+OghV/3VE3vX NuvRCbPamznn8hyvz0PSXb+Lrpo8B+kKHRUNzPzTTS9uf+z7ax30GdkxbgnCExGDwapW8G/NTIeu 4FH9ThLo6gJzv/l8xqR93rvkWvxO3n029x67i/vEPURqc2Gi6PFh+4/ZZ8d/X7XNF08d9MMbe754 t2evzYdqv7GGYJfqHUDjFBRvZe3hpFKtojRKmRnCoqF5JEtFuj6+pokY8Bc22OPTtQ+YvcaRv6x5 xC+Tjvhx8hHfTz7827UOn7n2EXNOvMK4503jiwXtn83MEd6TGTQfqnZFbMQK5aAm/nNZ9y677Xfo p08d8dFTW/z3Gkudknpekhh7ahJYCJk0lYAjsh78VnOXg4x/lbVbujzD+MRtvDMn98H3qQ++T374 feTj71e9PyP+01IjKRQgpa8sWG2Ax0hYrDnYI3RfKYlbEUxnQfsnk67SYZir8ZGTamZYZBWaXN3I AV0ix0SzlsIIXF1qvZyy147fv7jNhw/t89Rt49Zbu03VOE61d39x9+P5n5cIesnU8cO32lDu7JHa vA1cetKZ37194NsP7ffhfw/86JFd37xnn/ceOvSv54LzI4cep3W5M9PuGmridJmeiq6Kw8JkFtkg g/ydQKZIXVm8cCHJLqOGNZNhSvx/AsMu2ACCEoRlDZeBHMEE4B3zJ/AvxMAru7Y2j3DcwNspGC8g z/RsViVcdG1L0pfYlXP5WDwWBEAHaUDOS0oyYsSlackCi4MUyridLc+9v2jZqvY3v1z5yZcd6diE w6cHmputbmu0xrLKCpZ3yitY7lmMdyzBRK2HAllxe87p8kq+PtHH8zpf/fSd9XbdxWJ3r1z42+c/ fnvkySdxgGVc+fauOM4MIGbSColIoJAkQ6eIKaX+owdVugS8Ji2AN3L2Z3mRbreqw501mnz1kyet NWzi+PWm7+YePRpsijzgNOkEqfQC695z6UeUt89mriFyNOl0+Gbv/alcMpONGtlEPuVIYAy1DHd5 GgKB8ZttNHKtNdY5aE8HMZcUeCTtBawr6BYEGDNZIAkIsC+npTCsJu+zYhfMNXjiziwR0xgc7KSW EOIWkqSDFmsklBPQJWChyVgA/VHST8iXIYdQ8PoLEehTyLs6MxGgr61Zx7yuzgde9G22jnOLqW2/ zf7m8y+P+MNxVjllhwH0wdPIzfCBKiRgAX0YzxgTLUBIxPopcV8+unyKXqRiNmC+Mq4YQdyUuojF ZswMtbTuffgRoyeu1zxiYtOak4etObl50uTmNSaNnDhpRGNTvLN7zkdftLz+0eLFc2wjGiZturFR W2tQ5VmsPNIBno4T2xa2Gl/81jbju1GLYtbPf42sWF672UZughfj4YIfD6dkMIG9pTKVOKrnutIh AJIIqo9JrDV5XNS/EJs/8EYwBARhXTBNUhASjJVC1oedI0WSCwaEnKSowvDC3FIfhF/ZYjlLmAjg FPBMCVWywgmLYl7HmDtr9tI585LPfNL5zMctL3684uWPF7/2cduMH2e+/8GkyWtRV2zup58lLPnt d9kV+oPsJojHmC5YU0AgCkiW8CumD1WxQi5tnJXFVGIzgKvCMTJQgGESDCX8B5mclew21i5o823d 4S++HTV1cwNgFtLcnIQCRDokE0ks45ZY1o4ai91SwsazcUs2ZgV0Chi4rA1cOTgnkY9EgkLnnpnV ppL+y0RPt2Z4wYtSVxqsOvJMpJZFsQgERMMdQuYFIOJ8K55BL26hOIuI0PWvP/vE1h6xfTo7+vEP WMs2u+POsUftueaOm3nGj84XkE558TwTxscxCEh5nAJeJ3VfFUQBm5OxatWyX377ddIe2wLP//AH r6yx1bRNN90ymeizBnX3ULe5GBTKGeyqO8/QSD7nQzpV9eDYX+KvNsiUif1t0FvY8n768Sey5ffZ Zx8iLXQlEg24Am/yX3U0Lh5ilYGN82sxeqTc4kan9fZVck1oy1fpwfr0AdMFo2GpAusiYl8UVfGA a1c+bePRmt8hIGQAyTMZy4PG2uONSY3YBmOOAvyNrT2AA1+5qCXJW8Xd59F6c4Ugp7mm5iSLd7OD t3/4JstBW3x4091X3fnvD2f9LAVkrNZoV7e3eZh2OUr1hoEs8uUKIx3GpsE0477QBnE5HnC8xWSH oZD3vMFoDN4ZvQdvvqPdzR5DZXSNoK+GX2E01x5t7c7VjtBeQ7A4AAR1i3IV1IEn7A18eCNELign ekJuqM/rIsTC4vHI8siT1eFETKqq4AqfKpfvzCRq8CoLnJD4giSCGNR/KXQiyiVkC7kFJwlTdyiX Aj+F4oYym/RVecCwv0otcnw8VIvwYDm2ubpSrRsd7zxq+/prz5rx1GPnHXP8Z8GgzcfOEQfVTLZi mQYxiWKYZWfnVKtPM3pQJZusUEN6SP6mWmzYT1e1+zMEWzTPPOicGqt9rf/eoAA0eoIPSkxD+tv8 RR3BrgL1L8gpBRlr8iQxLtOC084wxZupsEFxGGeuembpp5+kO0KAnHRbMxufeZL9qO2BK8x7iVLM kqMCrcR2rXrWGu0CU99HKIUu0wEMoQpqkZcCDiNLS1fSATMPlKvR3joF5qRwzSSDQ8x8JRxdB85m ONFKFkTGBrIMAUNsZeIOcUjU/Mp2I6jKMIiDSMW6zPztmbtu3+PKP9cevs2N+x8b9tiufOQ+MZFL 5RyscDbZ9oo4vcBcSpofORlaGSz3HAid+EgVv+bn7GRACLjcHqBRII0+0yx5/8s55165x23XGsR6 WjMZjz3lpNQGSdAZd87m42EaHkvKa0ttBJhO8n6IKqPUvBokCawAKpY78cpnVkSCupB0CEQAkTCq lHfSqThE12WXvBgV1kV6XTgYwlPoUyc/4EIl12JlaMHNDy77/Dtnd6K5pgn8qZH/vNjYdmSeDZTC F1IfQ4BZsJRKv9RLfCd0WuKxpEbIygee//LJZ/Z77R5nMnn0/nvvf9qxh59xAdtHyTmpnVs6QEDL a0wlUFszLV9h7qOHps8NvXL197Zxc6758ecfFy1cfPhhh1VI93gYoE4LwMFVNwaGiuG4qalvsOcg P0t0Ry1Om5ukwWpXpjNms2SsDXXVbjTwaneFQyPqG1KgvPr39j91lXH49s9c9s9bnnrwi/nzK37O pmrODCdpmQyt/3lq4P60dhnNDaV4myH6jB2Q5WbGamkQiIqWMbIy26V/4yg6LbHwuPrqhkh+29XR 7a/xc6gdmrBsBu1rHOk6bqfaq07/9Y2XLz7+lJdXrBjiIAw8Dou26kmZ00t01aqAq8Fo9Hw2/Ywm q2udF28ZrCfMq5VsWPD2ql4kamM23WK0KMVcBJUObrnqiHf5KFNM5Em1C820KxkfqYLZq17hVSFv PTjbVQibe3/utfsedOGHb3i2HP/wsefN6Wz5x+tPDZYwEAacIJur4ZxR7ULst61saR4zqtxg99Nz b/z2jzsOePZO6+Tx5Q10xsNOwx7om6M34BOQs2TPDydSq9qFRkIqicnFFezs8gIiV2EzVJuQPIdg WTRIl1AFdFukKkCC1Z5vtP/53nlvf7XNd/8l+uvSDTZf86A9Tr75hsF+JfHQqPt9KVARQl31iaUb fm8bNycX8vLdfh+bKgpfksqQsD2vvOH1+n1en+yQouLlQJcg95w3uiRl6RIiW6m+XUyj0Ee5AS++ 4FDmYSHaPGyX6IIcl6lwSBo6QA6SvcIxEXQIgAg4iBayQXuiu8YGHpJ0iFnk+MlxVU6iUiRRylly yuewKiGrFG4mjNmwz+tYPmmYOLAjmUBzY7I3AkZMPphz6C1dLWnW5cac/j1Xkaf4ApWpB485iOH0 moBjgreQp/lcNJ8koz9KIjeHdyAgwEwoG3nJTKTf8I2eZpQX7RIpf6LUqIyDKwLAdS5EIi6Qrvlk 1J7hpG9kosl0EBgF8uA5LYoGJpqgVGAUe4SK4AXOcZjNR8BJkYx0jxeGDEWoNIUlNfin+sPSwhRL vJV8TkFDRUleYD8naEti3AibyFmWdwQjYS9dlWB2a4RMYnJhpMgvCjxUx9KUFWuJcIjg2pZLbTnL l3ECkCPMIa5eqllychLfA8oyafP1tR3xkNGRMGLgeMAe/GWWGQX6OUQGPpb3BNFlMHqI3SMazMVD 6UQEo12REXVtTbrhyRfWq02mYzFARYhMpDJmKAhsuoQzYjfKcb+8OKEXsukml9cjxmWBFJLSiOT+ cp/wU8/ThV9UNIQVB15AIFN0XUf1B5sh+fIU4eRX8kN9JCXILVCLHV3YmBIw0Xg+SYkjKolIQyrO UTF51rA2+pKNnjwptXmC8dwC7CBgI4BrCKZ2ceNRnlr+wCwwYSmCrcRLmtEEBUGMHJICgErf0Ngg IB6QDkMH1pJ4joKW8UYPJWkIIzGilAwltEf6U+dFaIsHSFA9sNKoNSXdUy/eC7ZKXl6sgsae1c39 xaf28LmqNyl2P2YcdQRcDa29li5WnQSW0EnmVF5ZweTJF8DdRPdmMsJ5YB9S0RjGJtZTQoAqOVQR uiNSW6gguIw90F0MV7BGcnkq54FkFC7kl7MAIQPcDvuOaGgB5QqcGVDWR9XlasQbVr4My0/AHPs5 IFZIKh0BXFqq5gV36c7fycYNanlrWxt9HdY8DPqI3S5IhYME7lwM3HHghKTOKShaiHUxfoms6aUE lsBMOEphUrHbxjgqA95P7L8g6qhyjeriTfE9aOjBSKKtE0ui8L28pACu1B3GZs3sZnKJDPhSqagl E8lkWrIRckyAkwdJyh6J28JxmJuYXVk30rj8n+JDkviRk0MilUosS6JPPnjnxocfbGtoXLlw3oyf fzj46MOCkZDdakmEw6AkxTggpaiEF0uQKiDmboz2IO3LX5Cn4Da1LKXzTF4YW0k0Cjw70dWcyXh8 MBPzsvxiSZC8uyPdKb8rmAd9nhjHFIglObc9RRVHsd9LlVcMlDxFWsb0qLwGuhYasUzKICnrXd/M S0RbNEUcbLiQCUKBXAIcyjDqViJq8zipDCD1DoMgYYs+ifghEyFM2ISg7QPhn8yx4bGCsORmAcjP A2aErZZFlcK8Ap0L1BHIRBlPMhWlD5lUOJWgQh+zIH4LVcUV6RszkG1ZX2c65CYzoDMQ92Y/+CHT 7PduMuW3H7/9/rsfjzjqSFIUIt2dOG1lTDJ1an7zuVg4wmLRls14MkFHpcCrfK9GxxKNZ7szgFFh a6Y8QBwEWNBU2l54q6FpeMO0KUakS8KWE0BQCSAUINSIbHipKxqOJWJugOC7WiVIC0xWO7xApKAq iKy2PpiWHOX5rYu7GK7VkmYPkpq9UjpWWJrOIBlkZhWlUQlyufZVrYloHBuAAupKA3pFXUSAn7KY u5OkA9AA8IUJkg27osFwOOR1OLXoVOSi3AIlKYRteIklOpVNUAwgDKpSktB7iXgT4HuSSQqRfKoz E21Nh5l48oaSiagrkkjMX9I9e4EfgEOX/91nnqhdY+w622wBpikcKHxniN2PR1BTRDKsZA0iodk6 ZLwwkhScEIeTdiBR+CCGhULiL+R2rAoxEHKlhgbSvCuWbO+e9eLrG220sZxcBbsDNwt3J3PwdSQV pIqEUEvqCchejIIiq0mmDc6R9IdCPhzsFruwMqHHKTkikhhm6Xk6AJqsKYgG98HwaSl3QCdxA0Ac cQZI/WURAALqJERBulCKxYizHOAlawaEALvDE7dmohSEwDBF8KPVWJboasnH2tIxovw6lrd1dXdK 5GfewrMoyCnlMEidwkieTUfYKLNZH+FCrdHg4qUrFs2dsvkmEUfqhkdu3/uYQ8dNWCPKkHsWuPjq qHseT1ATkYMvLjcKn0j5DplZWbQdHR1IJCkzK8VIV+MSS+fqFlJYjeb73crzwIBtbWvda8+9Kr5E lWG/I2FLx2mpUFFlDlUm5p6rCHqEJ5M0BLlNYuV6bEr6Nh3lVYyTJVMhKaUetIlZfa3bVPdKapmE 86pDLrOCQUs3qy/RW0rNq6eIcc1m00VBSLeJL2qdufae2z/zH+OA7Z698to7nnj4o7lzWA+YR7OJ NBC8NBJNJSkYrBMXtZ222EMJ01C9UB2GMiKyOaMR2158ujjEtFlZG9iUhVT9X2CXYmKILAtGFktf z9i1XZ7wNn5KfgEiiHGpKuZltNLZ2EVDqlj/6QCM5vMIPAuaMYDEmgK6f4qomrToQWi+WU8PjG3J yFicC3VfqVAT5EKL0QH5Pc8XpH9dooty7jkigBl/MDNn1L7jzznIc/3pPz/93KmnnvnJyiUObFzI FmWQ1YZLpfEXSEehWTKTSlgNxdHpHkqJDMkoEaKjgyJknDmPu3bJTmc5uqKjfnhYFPmy2AllEpaA eWjFcIFOFtw7lf2qGVHXlyrnL/4VSyV8PaF4ogAKNYuFMdT9ejKEDtFEQqIfdDljKfWtWtWMLQ6L nlB9VSGDskEBt5culcilZ1avCDUVCgZJADGTIAljR9WTpIgjjCL0Eb9IAYYme8cyY/kzOx+0MpB7 rPW7yWMmTNhum788eD/ldHVKbWl16e7gyaBlisHr3vfMvl6KejiKF+VR+Uw84nCTjybl3eSvzd75 xiezzrp6u+fvMjaeqFT+LBlJQlqOdxT9rZWEGI4eOh26nFvln2pU/Cmtbn1Pbx80gSXmSLoiR3Pk gNMljqueS9NN8wAXXKGDZNgUmSzU86zkferpVo8TTpR/Ktu7pB7ImUo1q+ezVFZFY71hzedEhmYG dFjyX0/Meu6NjZ+72Rgd2GXDtU8+7sQjL75CskpLcdxqavU8Ujuc5QxrFVep0BO1B88zhYRU5sfq hJf83qYSXRMnAuppv4v9E11SOEMVrpY6hcVqhfKm56UmAysKKlKPvFPZFuqlb+t5L3NjYdcX7VM/ jQkstanjcJDCktIoTGe1iF7RB2Nas4hoXrpx1C+1AZCZoE1jjuH+7Yetccdf/375drs/9/xzbpcY MZHa/NVSmwtvNl3VXCIP46CqAdbFf9rbYVnCaoMu8pPqKmmZAkWoUOvIKIEmPF7uBJ4WUD38G2Xj 7W1ZP0JtC3KzFJhW5Yd6RlF8o1yg3AlyPMdnmkKtQRtQK4jISRmppoC6v+jr0ksE7RJneWkOtSNL CKX7o8ZV+jZFITSpAt87pzIK8VuqSEtR2AQgzfDbJtXUu5Vxkx9L6SctlmXc7EIsT8QM/yC3Wn4n yLRqXMXJLTGAlmxaaqtZRzdzkuuB0abGX0uwmoxKE7L4krQW1WEpaqxMTFBbGEOXz5CqFjIiLdz1 ewl0EF2t+E8B5C9i8pfuh6Ty4ikS2MPRRLegZgeal5hBdbfYFSKqNHJ36YnCsaWf8EbNlL5fzqUa E7GH+IqTEdZIFUHxIweH2/KhMJv2uX+97OUPP3r4xecvuewyv9pvGFuv/OqZXwkXUKtAP6J3ZfVO q94r0ZstnDvVrFpIKVL5Qdi90g5Ubz9TpDKGCKnU8gijRBZyiUtYflBaVmVv9JLn+bK6e64+fRBS 9FYaxciuDK59EEhKM6IfUQptVJXDZHMlMV+KqLCyWFDCUQxASKoTxrhE10+Kkq4erdZszzKR2yml QB0McqfBAE0npXwnMftkXfr9qPvCreqhpQWu2+ESDzO5Nj0zq9eU4FiyU66m1C4RR/HJ73Vpa1T/ p0k9CXN5n1KjhnCLXskwVNdVtQpTxxARFObuFMGp8Z25P5OZOHb81EmTN9xg2jFHH9W/KxSlMxlg r4tymJkHOJK6IWq9V78khR5ZZ+Ki0oobzBATlJV+DjSJAz6E7Eit+1e5bFYQ3gvBbm6rqatlGx26 I/CAKcLCLm5nOEpIn9He3oGxfohuSMEec6UJWJqunrNRtYFhhpF0vqq3cYNUxzHHA9wMGpBUbqt2 WUeNRE1O+X2jd9zBuenG9euuPQTfUAinspTEIO1L4BP839cli5ECu5YE7VRc9LMfWs6ADUthKVa3 iYv1QnEfk4F0aNCIDROtsuNgNRwc7K2sCQZLtIzKb7DhG0gqeLLBLhWiMkgHzC3kgcn1xRdfjBs3 rq6ubkCpambAZu7BuPPLL78QxLPlllviMeOASQypiq1WvyY5lvpVqlAFJx04XaLvVOBRsZ40Drk0 iQSiKMiBRDAIPRKypH4uJw6tLqpdnXuUnTch/K0hPfDqAmPZc5tydOC7kXRwPuT4rzUZOcRodR55 o+K6VLNU95Z8YPZTNlVOlH6HJ//m12/868YD/nyxsfPWAiwp0cwpq9ODZRdPXLaWmo2imanwKdHb 9BFP95CzmZRHUum58k/0MgXCwBsxAMjBrEgH/RNoxGg0QLDY20lvCwREC9dnavFFScyrNNRzDuUD 7fdQwyBbgXTjnsdJiWPtQOwZrAxK8CeYAj7iYOcmvqJEUqlGmKRDOspK6CS6o1y8h4yiSApf6oJ8 ckTlCKUVOqmarfDZy58OaHgUvANUlbZstImjQ847N7Hy6Mu7m3NA6f8Ubv1p0dIXP/6IMmP5UDBj KTjcLkBFoA5/JaE5qSuHyOPk6C4l8CT3ukhefErxbMJvrckYXpRAgoVrbL4uS9fJ/6COXeN/TsOP lPLXCbCCIoDYRHNZrBkYS9F5HT34eSW2FJTq0kzJri32X8E2UkFdcmaDGkU+EXoqDaBIatgV46am j1BDmEGVFO2hvDxF2QdVbKxYUvCkFW2A6p7STPVMlhjUobkcB9XTpXs9BkYYIJW11lJb15lvq8nX Z63+DxY9u+/R+739tHutADh2YIN0FzJo7swILgxCZcEt0CckiXcUC5vo+PC5+GAo4Q2KlLYUKVpJ 3AD5FviWVE1UwvMDdY1GZ0jqqKUywe9+mf2nG7e69k8CDgzGOlVGhjniTktDzGqN21rIf/JaR9Bx bbXs2UBKpJM1C5up1a3ZCKQ6OfD0PF38BhnS6+WsIAxPEnlPRKw20/WZKWxf5CWqmDz0aH4CF8kK GGSmeDqx3nJAxeEhgPyiSAkdembKljY8GXfUHeRzV1su/+S7Pzzz4kYf3Z9rXXLcOSfvt8vuR1z4 FxxA+gHFhUCfVGaKPJdChm4XooO6bgIAILUywyIXpPSeqU1FaKKu/yUcELISqMCPEQo6X1PVY7Pr YPhS0wwbRyoOAQHgV6WE1Yq3gAq7atUqSi7ISJSJXds00ErkHFGGlCZTq+7Rf3XLYiZmVsHfcIgZ ro/O1SOwiqJF/ZyQTCkBx81qUZffLx8IXIOsIy5q9Uq1PQ59ZbpkuVYrQa/ySItOl6iprwsvWPHt mrvu+NJ9lr23kl/xVTZjdRDbT3yzVaEkWPCw2F2idMua6KvqlDcupMBXBqd6KKorrNJf3xQzr0QT yxZF7VFfwCeVH3pUuf47rv4E/wwLET1Ibxulq+J+yEBXOdF7wGFQhFEG0N5LVWAo/lO2o2yOWAnV 0Z6Y477tK5e6mlmcb4pLyrVOyYNSfXdSIkasoAV7Z3LJpMNb1ql7N7UkOMyXqam94eEHXcCxqswU NxG4erdWhOE/eVyjnMeLW4PMYNnYJAsqh4VX6gLls/FYocnnsLiC0/+SXtba/PU9UDAnWlVRCxax SYy5zUqtc0SSC9CovueJysMNspuZxpmh4oKrzaw1GgpRo5No4qLdvJys+r2mo1QBlxroVD8tn53K me0J2MlS9UmXN+xLeSSHA1OrpZCkOCV0/2zJewcct9Wd1/r221CM0S6XSD6d6JDJsjqQhT0zKwzM 1FB6UjQYZeHtw6XSxyIsjKQixaPYuCUiEysBarLD3vrKh3NPu3r7V+40Np2sfEpAfDH9hjOat6St yQbCzw33UGceNgY8ynmA1YoLto/VTVY0fKW9AlJPSmK0xUNSomgFKYplQ6wW1GG728Xhc+iZFU1L +UGZL23YKp8rYk9sFJGyAXoG/Rzx6x777ZnXxl58tGXD8YcdOf38U8/a66yLIGmf05X2lLDNkISE XdDrEW+kapbmpThRNi8Ai+ayVUudWW0bNyNBOl9//fWnn376fffdBxEpoUDV4H/+85/ffPNNKagW qb1o0aJrrrmGNw8//PC7776rIyg1JKwO0tREkeBzp1RZFZsZwqKsUK8Ky9HBOaXSqVQ0FTcP6QZI IlWUs7ewr9T0VAVAS/VApbKtUocEcI/f9b1fdhvVmirOa2Nnxxuozsqlqri9z+UecS/RVZ6oTVyc VZv861vroYhkKhNXhNXQLXWBrVL4VfDq6IklTTUWebT8tqzl8kHpDnCYpFH1lAFuVgV65XMZisvp pRytKutaokBF42rIQiIOK+gMepjlr36dEQrgw9Sf84iK+6WOrGpQvVxUdRLbVk9B1YrhCLl6ZhYJ q6qu9nZVxksxYSmkYyM1XE2AAzDYGpdvs+n7/u3Hz298751bX3hWpDaXy+WtrWU7JNsIvAvOx8wV zRMfSJN6WiufDgndAP7JQMC2x1wuThMuglggs1TXFXlXGqDQVI1XCCUf9+GB/kMTNsOiQnSJpnCV mYWxlKm0WKC2kg2E4LoFFgP3ZNlC+tCqcmZlyIKZjM4p5vJ+M0uxZ4ubWsAOr+hBFtD/0OXthGYT FllfB/yAhp8UnqewNaWce2dW6MJGq8vmiibft3Gp6yvFh4GPxS1Kyfa8HURM6Ol1C0oiBYComUke fJ1fbNyE2XF+hlcwCrPWKfctlaP7MGEFj6kyxQ6KyPQu2FJtX8W9ijNpT2ZcAAKTGVVNeeAFK23J 0FQt6WxBuYerzKyMV/kr4X/NV30alxrcGLNwy4gfARkwf+HCfxx7ysHbbUvUCJFyIuJE/pT9SvEn fdD2dDka9pAUSni9Psi5ulK7fC8xYYJUtyPpUTaRyHvuuSeoeICtUMbsnXfe4UP+lpJHmPRwOEz1 90cfffSxxx57/vnn9VlAFNt4nPSZAXQOqR5V1ID6f1v+CSo3mfJD39P7rTp9mrkZqT00cn/vdgf1 lTkepQYv3dDuYFaCSVARC9LLnB2QR8dCYZNGLXGxmWtWyqUPVO94AOoxWabKGKif6tJNVS8ACjuW Jyl5Ze5SseImLuXk7wpKs0RfEYkxxG9ECpijFXMquB/mLso8ap9n1Qv9cjVs3Cat/BZLKBzOhoJV ny4szSoQnHoTF2YrQbbrc6cE6VLup7eMXM+3uOhBAjBxiX5qkrUkdgi93xQXMFmmHC1isCIe2VRX oerY5uEXv/nM/Z99+dgbH6+/14FDjE9U9H5qtSoF2HuQNUGeylvMogNqNXm33XZDEI8cOfKEE054 6aWXDj/88FGjRh1wwAGzZ8/WWHSoA5Q3QyufMmUK1vMDDzzwxhtvxJyNaQXFnDfcrKvCuzhAaCOv MhIq33X5mVeMxGVGA4vNRc2sGGck0WY5quu8tZ6LE3CZmBaxqozWosIUgwL60UZiYONxgG2I1+Qe NkgdqyBWCHrSV+hL+9qIgQqXtyS/X/TWny7d8/QT3TttS2YPJfWwPVIMEUOsMtuLE1NU82LgnZSw G2JudExXuYir2IoJ5u2hjdh3sAOo6ShaiFTUSV9jSKm3siLFvFpGKbHhld/PGVlkse61mgghWqk3 PKvMDCcHrzRB5JyPVU6wRAMPun5E4+c41dfzjEMh5AbNudDQlg01Fexuu+/rlu4/XO07dT/n9C2M RlceNImewfE4AgjKjEdQie0QTCpFMc09fWnL2Y1qBvZoym9xRhPdtjq3O2SLnH1DJpRq/O9FRi35 +URWlPosJ3A1s+qREkY/lCpTrMzNCb1HagxxP11j4hTllatCgCn6bA/yPP10GYjyIJRLeTrTd6Z6 64Lr3paIoJ+BcYxUj1g+48x3+fO1oJ5/sOjV6X/Y7eVH3etK/EPe4cI11Dv2vqSDrzIsTMbDYYUl 2WdBqREAl4trQhATsjbBn0HOGbYUCE4cQYy2T79sv+XJ9a65xNhgpOSFh+KFifVha9bXAY6NrXu0 N++w1JOb02t0q1jgmvV4bnEtVI6dteywgxgOEchKj3Z3BxoagZfV1lRO1hUbZC+teiZrqJmS2Fny ghQZlehAWed4XVw1EDuetYYz4SYS7q0eClk/+PLc9z/a6P7rjQlu0MbDLR2+2lEWB+l+Rb7qU8Fd L81e37j8GzxUMaO7HAVPT2mRIQRE2VerbSrRWh6y+JNPPtl4442RwkhwlGh0mbFjewEwdejIeuut t9NOOyG+NUoUhC0VVZAQdJWbIElQKTB31Evj8pS9+GfxK/0tP5GC2VjBqF4BJA15j5RC7/2J3N/T GkdpydgBvYo3qrJy+Z28x8SRpgpthMg6Sp4nM+AuYognQU9VZe65ufdX4m6Lxnil1V9+CAII5I90 knhI+eeUEY/izZE0TIwnMq6UvpmdhjeZWFyMKn0HWP7PHJkyqmX9AhKL3Irybojk6glmFqusZBnI GPWrgnT0p6e38XQ0zntSEnqJ2e9+AX5SeXHi+dIwPWWNiw7S9wVJBSOJvUTNWons5Y/omVaph913 mhRqkkLjgVDcxtOI9JONhTvJpyWcn6BymuVbKAmelIZkUiMtMgxzOgjb0KtolJzGGOkh1FwHkAnF DEOcPKq1VdrnSWVdUpQXEumZSledKTJAAGYaeKb6TzFjJ01HHB5q6ZGbSkZfGdPKTMnTi6wVqTJT eJaKN+veku/TM7NQRiONST4U+SgS6CwUlmXLw2FvKTZP/POgK46OZcjI1XXNgXjrO7MQVk8cS0H/ JUUHKSsk5ZLcMSNKWi+qD3IfWSlFZhCG4vLluWCN4dEYdIHryZUnCsMMzNU4DyNRGXU8Tv4UORNC W36SlL9qTvtwWi+tIG8sxj+HWIDyFeINLZ4QPakSoYpblbM9YkECfFOyuaLo4KiNxY22duCmYFGR 9dzcKzroVZ8VLXxYminkDHOhUOLEX9334GJOeitmMh9VgpH6jTfegD2Q3VOnTkVxlsgQmw3cgGuv vVZr3IJJ8uOP/PPFF1/ElnLPPfdQD56v0MR/+OEHBP2OO+5Y0bk8OWD0w0y1Y1SUUMJSVx35QXY4 7sSKBNRO1SsmMILWWhPNMp2kSgdciUgoUbNH/ZNXWyiDOchF+q8FGGIzE0PuNVmIZlCbcSut7LRT X9zMhFODGBY0Q1hOP9xJiaZql6QGBaO2xr7Q4YP8KheMW/1uDEHVWjVWevZsOGs/941nVb1TZrY7 bqXKc18P6oA/zAYjSa/F7/Qv2+lM29L2UQueHbR90ODoJy6KqhekCsctddUBpmkpsarTWeO1mQDM QV4UoimLGSZEKwwnZb1UJezbP710wMl7PHmn54BNqw4LPAUUDluNqXGlQp2u2j54Ncteen/h8Zfv 8OUTxrrj+jwrAlCi1agzEWaH/AsmrPUmOoBpsytK4coiXPPQYwsmDLjFBBJyLpYgCcrRVFuVVsF/ PrTi2bfX+/pxwTKreiExULcrliHAD1TgouKDKXtP7zNWW+PmBytWrPjggw8+++yzzTffHIX64IMP FteOy3XQQQeVFGqclpi/sYfwKEJQjjvuOF0sWCvshOv2HyZSEySBqsNXjeRBGzBzJ/egcVek1Qz2 w5AE8ZnqADFJcYq8EHQooQkETg21K5BWW8ySqNbjVI78a32mrn5RR8akjZvcD/KJq7fIORFNJhYy 4xIgHC4q4CWmLpQsdBgzt6ZH11hGjzdzJ/egPvUWGxziNyh90aiOuSbXdGhoclLGwUo10wHmlJvN 3Mk9WZcVUEkzN2PzjCnWMnNxQsTvWvXOgt/f6XHkVXZY1YtDGaAoVW/jBtZ4BJW8r/dCwqIkcqNf AyCb981uG+wREiIsiAvVL9Z1NEvZN1MW+UhWUvmrN4pCjbGo6l6oGuqyWVZYsp03P9p525PBWx83 ZrcP0b6sbqCP+14cbbD6rq7ULm9jNTRuZLfGi9FoL4gPXWdII0GXGpUoSIcDo7a4dImjVOCiaOXz 589HQ99qq63Aq+NXxervyu3JdOvIvFIjPELXKNK5ORKsoyr9KLOphCWVxz+WCzJphFciZQUOGhOS xBRK9ViyJgTmpxhiAOwnPnRqJok3G8AK2qWvEhmmDaeSONK7l0oct47bZTggT5LX8clvb176591O O8mx2/aGX6LPCAHMewlo8HFAz2SJlZS6TkTOqXDbypqTFcGbgpQkKfgqPJdHi7O0D6vJ5+ChAlDO eTiX8foD5RqEhrsskU4CEFXsOcq+LkBcGSnV934N1sMxGgRXgRLJZNiMy0kqTfVcNC5FkNXRSpwT RbN478TpmdK3M3KxSJbZuJkZd1oKp8Wpumhk/cmCtStjrAh/8+e/1xn2Rn8dNrDR3mGFO07MD8vZ onYj7Mg1WdpqbO6svR70Oqc9komKr0fINMDTcTDY8o5Oe7Iua/cK7HgMaEDnqnTiwv8QfFV73XHp Ya5woKZYrlNMysySoGsq9KKcy+HC/qMKPhevipnCXiUwsxInz7ikG+VuOtYhrrDSb6GPBEoTiaSi GrQVsZywmqNKFOOHOFrKb6iY2eJM6SKzEm/dR43F7uyOEDpNwWKCrLMNEWshlPnnJtuc/eKzteOa 8+5kss6R8LiACqFjTDGxTOQ6iLtC87zibR3jO/DMil9afBqkJ0gVt1yu1leX7wxR3YQA8vCPs+Zc eO3m11xkbDFeglhy1tAwW8iSHxmxOkLWzmZ71Gs0kf4+yC6mgxekcJpi1/58VRICEBOy4GoGsbmc 7ctnSttmJYSGkArlH3ITypQUGaVrkQOKQA4dxddZNpwHoIA9kWUFi8dTwmHlKp8Iu8UOIESytdtN rXJnzfKXX33m2n/tOGFtezC6+JfZu557tvfCw4MBge3VfMPPxT2jJJVEMarQKtaRXgt8BYCJhKAo UWlmUylfgGTDPP7446shuFfrARU301ccmMuXL0cZ14PRN2gS87dCIdKWcf1X36mZnv1Al8moEEb9 +5btiiBgrSo6W8hZdlaSD7T7UeUxBENByOd1e+RxPZG15baIEhvpigdsPMmFK5dO2m+tF243DtwK /CAal0h7Ef+IKomC5W0sFiFLqLTxlPewvPO8Z1AQhHH1jrcymlgwIsS6nc93t7fXDWsql4blHKYp o9uhWb1EK4hTcT8UYENlSeraaeU0L1G+NFncxs1DQ8WWyIUxTcus8g7o06FOgGHBiP03W3hm6h6j m4c3DG9IzV1unzVvSuhrK8XRwd1HTrgAwZbbwG5WFsECjKuxywdkSIkTt7BBA7eYo+Jitys7vH7k nE2PrbV4Rn5zD65OJG5R0xEW0KxhDSXjaMZ+l7ePW2kgNhMKJOM1vkAv9ERZP8pnlh4SRqUw4XsL W/efLP1rVjXzxRSU31Bxc4ntsT3SZv81D04LHCwlW6VOtDX/4ex7Dz/12Ice8O66Rh4zqwsscqey q6rELAnNUFlaql3s1qKUqESNgS8hlUoXAi83HAkEpCwfRmHB/3ZYlzz7Xtt5N2328m3GhhNE7cCE 67ajtjgwGKbt2WEu1KbePW2gBwiyVSo1VAcUc4rqgMYdjVK+brA1VWJjLSJRN4lo0O7BYsqeGrL8 vFR/FHgVVfxksFJ/UjmeWhaM3+X4+Jo7fnv2rROeup3Y9Lf3PWHs3rtP+c95iP3SmVWzgV5KDIo3 rG6BtdFx3Gpt8iytYw1K8IG+WG1TyWq13v9m5hhyay2bvuo9TWKBB7n0V+U3lN4P/cNSexLaLjgf VpI1JDq17NIP1n8hm8BHqBxD+UD3qm/HSk/UfWAIjubaNdz1RhhgVPwz+UJrF6VXCfKVJaHaUDPS +8jSePt3vvy+3vHqPvS8dMadYIk57H5fQAGtDNV4Oa36E7iiM3RAn4301X9Sqk5WxSPKx9i/NYXp UER1UBgkJGlYVhWS6x6827ov/GfDyy9pMvwSCExsMMkgVB5BKxF8CSnJLopmtYvGia2UiVXaTVN9 M39Hjxldq/IJhIIl0Bg5ZilMGIAE5JQlCEJDzFSRPvxEuq9xZCpu7zMvPA4xhIStYOPy31SMpg/T aBbte5XmqD9hhToyNobPKFTOodNJyQt0TiINrXUBu4cYb5WsJ1AEIjGKM6XYSY1pyKu4ZviR8Dk6 pGynxIsrO6+UzmBp+FwS3A1oD5jKxD3LngienqA0APNRpXmlpZq5R/peTB3tpU5/JpRB9TSo8YZE FJQmTeOKwAPqpQen+X/AS8glVThEQU44jFWJUGF0kzFxeMFHRRDR5XvJ07M8dYO6t1ro6U7yXh9Y V1dql8tVE8b1/6PMVj9nt2Erq9gkdcN6MCYfshp3KuY00yxyoRTdNfT9il+kzWw89fm6Nanzb8s2 T2/Z6A+f3/lY/x+uRlfNb7wqjdbMoPQGaZICmr/NNGv+Tt0BM22SJLI0Feoi2gzPxIrF3UZ3j+2v wo5abEyzvomWZVQJsM2JvgqFowPlEJQaURuymTZFWInE6nf11465Ba3KJOay+clajZm15lo6W/Ir VxZen1X4ujP5W6cgHw5yQStzVJXBI4NKB2HdHnkrEsddMvGVjozCV6YISyM0a2Jai4xdbicZ4lcm Gbski8x0IJID5VVMoUaI4lUJVbNq0GvAJVMSegOyjZk+/E6mEjiYlHcK9uy1117aKlLyZzIweq+V vsF6zA1F8I0e+1fFAbzPDzn+UMwiniZ7SnQ1zuKcIZ1YD8W2JVfBcBHDkwJ/laoIBWzcoEyhiqBE cBJTufVSOK3UJk+n/5x5FS5x1kfNyc9/eejsC9bYdSe2nY4VqzrbO8/4zy3GyOYcp08qc7msKYfk RtOU3r0rVm9F5zUEc69ii3ROY8dU1nnB782x50mquboEpcHr0bWD9cVX5dOvRYA2TJf2/HL6VNxP Z7Bp6J2VX2EJYX8tb7Dcxq1b1ooJf3mvVYlyWpUGW5pZ/S0ygyG5kmI5SXgKMUeWgPRAMmuLZ/90 4KFbbrXlgZf9Kfb6V8Gj/zJ61hvGWIfRTrFGb26kbXlAjJANGUuEKYpG3ZQFVBYYvXRL4kY8JWKH tYUdGX/Wio2b+MF0wOKLejuO/gtg2KOe+FsmYItjyC7CVih0X0CjHE6wmzHgkc/GGVykkpp9bb/q 035WqpJxERJHF9gZOCCzzbCIPX5/Mh7n4MUdxeg/5dqhNRrR1hI90SVaaTJqiH1tzuZQX075oWdW 95CWpW5rNuvyukM54hSs3mzWk8nbBW265fpDj91+2Lil3321lmX4sIuPq7nkaLgXw6rA5SnwdDF9 qKh9ukfUHl3S5njtXipfkgQUwYKAy4ACJqgsuUIA5MVIEkRkIxzv+uHXuedevdUdVxvbTpY6BgVr qNEas1qao1Z7xNo9zBZzFprw/g5u44byKr1RDNMla1s5X2kS6XlnvNrBNpjEoP96IBCHREqAiAFA V/HpGDUhmpMZZIAaStrlcsMsCvNHZesrQdTHZsWJ3O7Eziapk5nsG08+9c7Dj990139tDu/zp5+1 4c47Tzr/eFwLRd+JShTXK4UG6QkNVpiCWWVaoA8lxwYaGz/RNm5TetZg1DH/OeyFOIDWpaJ2ut/l R4mhWyupJPrNkNqBNK3vkUOheBp1Go7KclDWLfHJOFwSgp3KOL0+HDtApqgFpGoNCA5kL4uV9kz9 UBrMNdd+veCX7bfZZufL/77LXvvbQ3Fj7CiWETCpckoHdUTBHZSPrtTtis7rNjUpihfGASD9VTa2 y+fz1NTotmQwrHPtHijbVypaLidsuVwrkbfifi1ZVNI1VYhdFXBj/btdOlGWOLtiLsonqHywivIK QksnAOEYoMaClM1IkXRjJRCt1udIxbzOOqlHUwSPpVorILeYMgSsFZ9/CRpUE6380WpyRa6qXH8W JPJdoCdxpXsCAV9dHRikpHFRjNwjBRPdYC35yFghR97h9PJPpxAd8z0bmL40r5bRTVn5eGwB14nb Ycd5gLQr4FKTSipJApzFD18umkomfomBVjWjh5is/ixdcXPFYmG+mDj9V2wyDmeN09VAvjt4eDg2 arxdkfaQNTn2rJMOee7VtaZtMHfujx67W/icwnsxgp6ysvOoZ2CLpWcKD614uh+AcwRhV27X6rZk YPEfIh35l9tBuU4fkQsYSVDLOBSiWwi2kqIH/1HQ90Mfk/ToSougPzX0jGvZql2U5Ve59NC/1Tui SE/RoSj+IVNAn8BPYBPCnkYOEZWAqJuMm0py9noEtx57+QVRRAdUHMtgcx7SxBwZmNLjJKTcCWsp M2n/laVHVEFMPizV8jYvQivu/J00bthr1qxZVAvce++9K3owoHNywPEgKcinH9De0v/+XFeExCSr iQpy4cUrPQ11DhMRrHQVrwIdCLa2nrfWRjfcfXfzkfsbZ94647EXtgh/XNEHtC18TWZOf7Sp3Rdm ZpGsH399rRmUA72rVxS7G/ARAqaYSCCyq3aAZYBmZOZOmkI10JJl6GaRJCdusPH+hx58yBV/Tz3x +tyjL5ya+gkVZbBf4W6CsNWPwPjHurrSdfTAu2yHM3zdiYafHhqszVgwhCTy+Ad3zfX8ktXftWTl 8MkTqtKKG2BXlJWhIxF1OxCWKdD+4aoXrIWkrhqQkJg9d+/1N3r+oScbjplu7P/nn125tZ69odJV 3fMw6uAguPze6hTgQNrV3tE4bFj5FrXw+Xcj59w07a07jA0mlfe/EIpbAP1qqF7MEykMa5kpkcou yJKBsc0sLrgFWlVlQvos1eLTaTNTcO+NN3759Et3fPiGt+B6YueD191hx41uvGiwWRtwdTPdOPyq 83C/Rn9vjZsOwGcwcf/h6YNPVWblhpLBxMzN+vRp5k7AcSoiqwb7ld7DZZlRRd6Zt/qVqPVQFnoA 2aQjJs10wPy4JEsGNCtz9uhSb6v2AfluslSx+cnSwsjcFJD36/arfcvm9QHSN3SEboUBYdDRqb5q iGevx+MYcl8EP8kkAgls3Nxoqlw1zx1QbRyww+Z5gJ9r00rVaaWYWWFkIL++SNJQOkp64hC2WDHZ moNVYR1iMayI+hewG8HvreyUZKKbC6M2TwFtfzBDgdWdgqok1TfIKcfnleOdze73+m1D4rPr3pps 2fxtv5OphFnROgU9U9GS5KkWL73tiPV48EsnyvM9Gpz+2RA3y1cYsFQxHYGdTEnCtxAP+7RYQgjc MzId4ZU/z2+du6ht4dJlS5YBV6LL24GZS7Q8hbzU7b0veisQ4QqaTDYhp7XLIJE1BkpDpNa9gtqt rKOYFD+V1HG1tNjnpRHV1Z6xyn/Z1SsGq89T2gAqUqnfmqQfnHClsFIClMqoBHOXXZo4pUs3wj8F +s7h6E+oivuFV9QBuMQ0gjrdZ+yq5KN6YQvlWC71AqVHgixQMRelxnmjzxAVHZAqsaRVE1JmZCmO kk0nrMEIx3ySv4UNQsG8xV0IRzOZCC5Foz0Ko0gNFWhCeidZ3Ji2nE69yPVBuLx91SeytKSvRBM6 PN5EMibVyohMB5CdNOX+gEdK1giIiMKmIC+ifPGI7azskhtCsYULFy37bdHy3xatWLAk1hUiZjEb jkuR4nBUNose0un3OoS0fIL6zJQqTqhHoa23A86snmBdApU3ogBJmLDGuJGLbtOrrsXLYr8tzc5d kpm3OLp8eUukY0k+1tW+SGY44KJcpTVGJd+UEU7mI0mcQJRgleayUpoV5QNLUZGerBh4rO+KlF6q boBT4PV6+I9Um2Q2E5QeJSTQRh63ESVPkqKmceoBpnKpqJG2AF6WtyepflXJCH34goHzRLQHkcgD re0yvsrArYRY8lezQM+rz89KZFfIUawbqtglBGuBvLxUZvnCJSsWLF61YMnSWfO7l6xkFAIVq7YC qZsl89XL87JcESNJQIkobCzs4XF7gBgodIaNbg4JEb/DxexrxPBy6aT7rI1L5TPLew6j5h3XA0rz 38lUggXpm69ngMd98MEHqehRS4ZMULFJSpg6HOgSnMneXaRYZKBnAye8oOgFKnon8Jz0UXLlRq1O iAsMuP0UZW1BVaTUu9jXYCYscSptgSc63N5n/3nzC088RTY2BsLuROTya/6x0fbbAdiRBraUig1k o9jwnBVlGuY/5QxxCdMmk/76hqVzfv7j4cfceNX1Ew/eb8Gl//notbdOffU5KQHmI8w/bq+rkZKl HCOwpCsPj5bFkkVjEYdeEVlfdZi45lRGnEu421StDOA1LewJ330xY8nihSTFELw1dtyYCWuv1Th8 GJG2XV0dvvphvcBPOs6kDClN7HsKv40dqhjdqKNK1ePEk6byAiCSWCrlv7mfvvtuyYKFUp4tn28a 3rzDLrsIhH8xuUaKMpdbJ4H1wKinnbfwt6DyEhMmraungOCoFGYIzQYDy6pCB728R6ll6JlwFNKk ymALjSVdBdvF0w/bbvsd9r/2b9E7n1lx3q1r//p8odFuCWeNjDPXZOv2Wd1pmz9pSbhtgHQgD11u igBL9J6MRQCc1MxLZDJoGeS/5X2ZgpuS0EQSY9aOuzqPvzy4aJnzvL1n5RMRtskyvhJvGJOiyi7T bCgemTBp4nobTGN/Emhr7KGq2KKCMrJ4CtZHbr/rtddfCwfFXMMm+pc//WnHIw9NLGvxjByR7GiH ScR9KVhJEulIWV2IYwOVl3YE5UIXkysqvto3pbcfBAV7UcBXxOMWZBqp/6lA6ItFU5XTjCQPpiOf w3hPJDfzlYyEa5qbP33tlX9cfiVWfHsu7wKWm8LN9nx3jb3DSL7x+LNNzpGJ069Z7LdNvv1ynIoS 5k37DouUKybtTFhBnJWFbEGqmslT8EPmBO+7t5CC5C0LariK48YojM1XvPR4Nwt2IxLv/HbW/HOu 2vLu64xt1zFiUcNfE3OlYnZLbdxwJazdtdaU0xJA0A9yQVsCNKC2Bwh7ZQHRbsNSbqGCEO2pK6kD 8AUGv1fvV4UUiog+SgjIWpf6wdEkkyLWKlJq0hkOBu1Ll153+ZWzf/7FjQzJFzZYf4Pz//Sn2nUn sn/B28DVSvacMnhrthend87izELXtOF22iy5V597/sW7773jqWc9tsAjex+089HHjTn7kBA4/OL/ El7CycpkKbVN+IptTZSYnnIfxC91dnXifcFH6u4pXjoYZSo+L5lKfifBjf/nu5lfAkG/3Y57VHQF 3zYjAkS5ateZvFA4Vl+rwJqrXdFgBAb149krXdGgQDcCbtc0/O4zz/7l+x//cNllNbnsWSefeO1N N224yy74TyX4tyJFWOp9AFGCQKbegtSuxQWJWn76/oecdvJpW5x+jHHJ/V/d9ciWkU8qetQVCdX5 ayqKGAzYa8q0o5YHyDcru+488dzXXn21ua42QmHzeOjxn74bNm4cD4+0z6kZvq6ZEKsocDwWo6LZ AToQj5+46y6ZaDzassrrdtU21P/7nfdczRL+PMAV6pAiBVL31QJCkw1QZn+fPIjyn3SFOn1uf1Uj DIvw2LW3OPaEE3b78xmpe95cefpfJqa+EZTzQa7OULDOX915IFXM492BpMXZUN+6z8UzP//ik/yK 5TVGguIWPS2jWkkhmEhk2IgRUhA1R/3WvNvn/e8773nHTxzw+f86+6yFv80/5vyLRns9++y663XX XrffCccLoDors79dPpyQzURVqBj6Yu+m9qndX90WTDuhYNTvIzikl0Qz7v/Pn08595YXX0k21bMT oDe6s0Y4lWwY37zmWpM9/obkDpescmVGv/PvwR7AwYbDotdtAirEKGRaWh0jRpSPqPuZ9xaeefMm nz5grDuy/PNUJMGawiNcjQCo74VVifhYE0Z2VkuUTBmcwiagQrIdSaufCjQOI5YQDCwqhq5Yef5x x2+44/Zb77//vC+/evSWW599/137hDEiosHkGDOhalefvOGGH15689oP3rAWPK/seOjITTff7I6L B/tVgkIKeQVWXnalpCRLgnyGgSNeB+/B723jVsmEGqC58qIel0k4bLZXlVJsynAMHrq7L8Z0MhE9 65DpB+2w1a5jGh9/9ulho0dtsfde6+64w5gx4267+ZYjtt/xsM23vPzIoyItLdLFHvN0608/n7rN dsftvNNhO+186K67H7Xf9P222XrXzTf/ZdbsInyS10Ux8wHGpXTbqkygn6ULUJVfZ9538+st8x+a //19Tz9e4ylm9KFFeAlLMmc0lKBGM7SyWVH5999/nxfb2s68+upgd9fXzz6x6sN3Vn35ScfMr8pJ wftHL//7gVtttf3aE3aeOvmMIw9Z9O03QwwwQI2CIayqPb8UDAPQwALC2UgOAWobuj6k4I6aoKuK eNf1VDKx2HqTJ18fXvzo4t+enTf3meJr3ouLFj45e/brq1aBhfbYB++/uHTFRf++BUNMJjUoaMaY kSM6VrVss8fuE7bbrrmh4b777j1g8y2O3H6Hq446JtzW1q9bclI00Vcp9WAe6JwDVQV0dQ3BEhZj gwP223zbbbfaYYetdt9to7132+HA/dbfeFMMfHTAXdeUEzS3QdeOqLAmXTISAVk5R8TRpimDXlbE uThqXUjA1EVkiqk4bgnrlRRKU40mQt0itQ3j/UcePmiDaQdsuNGR++//0+xZa2688dQdth+/0bQl ne2n/uEPB02deshG01584vGKRoNffRL+/uslr7y86qPPV332+bKPPlr+ycdeEC2xbSrwbolgHBLB Sh0OKsku+rwg2JoSZQOO09zoTZFoqJsEkFqhmvS/ib6XFw4fohXxBqiCZ2a6Q8noaDhcficHvw8/ +3zv/aZfcOlfL/3nNQeccKxICqvltAvOm37ssUeff8GOu+7etrJVSuoZxrwXX7njvAseuvyK/15/ w6KWVVtsu+2JF154/PnnHnz4Ycefc87frrziwcce2WT7baSFRIJs5f5dUgFvprrKbwe4T0pRCx9T DmZOyzKwVtQjgGHpqepSjQo6zqvaXSIy2ro7RkwSBdPXUB/Lpk49+/z99t5r3x12+PBjCZXJBLu/ f+rRuy44++bzzvpx7tymhmHX/+f28y+65Ieffw1jNR78sgPPaKKuLlu6nQxJlZNm8blSkjM51PEL c6QpHlDHfwu4LuRPNg9vpASMCmLDHkX+pHpR1UXKCaHFuIcP842QQ4YFs4aU0Rk0wqe7o0vi3mi6 re2OBx448dxzz7z00nU3nPbdzz+RZl5JDKKhsa2buPCd4N0zcaPcQvJHhdhyxrBYAxtdyYed4a6C kobRcBf+16HkhKSum+AWIaKYmip6kDTwKNj7T5xE4rHNmLoommkK50ssOOguJnbE7hUtn335xUP/ uuuWc//01DNPY8M84ewzjz/vj9f8975NNt+MTk2cPPmu++7d+5CDTjz1NF9NzYqVSmkrux7/74Pb brHVQQcfuNdOO+6588577bXngQcdePGf/wQPSDYToZXdQU9t/RDjkwSkfnJAQh/NrM0hFpcpkpbd pDNlsMrpXF72E+Jd5HTWc+lEEnYU7XVUIFPWYOsKqhYge2Irf/MFamSnsdcJvgubJ3tPKpXpBHVF KmnKXg7si4ajKdkigTJWIhseTHV2SxFI4HIkbUCeKjeXDNwKeiLZ1U3wbw1H1472V55//t133+rq 6PD7fICxH3zkMY3rry+hpjbH4h+/aapr2Oagg41gyBg58onLrkhEEvlVwVXzFv33oYe+/vabrTff qjsc2mnXXc+88GKjrtZIxCkj4GhopISc0dJlOH3GiuiKSU2/bjl+xx9WSolrrLZ+b8GeixFpYljj 0ZhGP+ktiqqSUHSJbj1xLAJd/JQDu9iC1UgRJm4+x/7rD0RCXWtPmnz1EUeGgh0EF++25+7Tz7kA W3wP40oWCVSDaGJblu1CWCUv1sgCHB6LkgbRa+PmcUmQkUHzQM018pQotNfV5ew2zDVGqGXDzTZ8 /N13KBIFzPGfL7541syZ8WULv3zt9SuuuGKttdaqr61N541td9p5qz32Ziquve7G6665pnDNtVh6 tttm+zNOP93dPELqyVIPGO9NOBzs6mpdtapp5BgcxXX1DS5i3fASuwpx8ofyQio7XJMVXJFYJtHW 1oJrK7RsUbY+YLw9yxg7nN4Z6Whq3UDYaWsK2yxJS8cwmyWF8bYQYUtWvCEwAFJ4XjEfpLMYUYtl eCxvw0vsyVnctnxHpy3uD3Z2JqxGYF6HQaaFT2y4xZ9AtkAN6VWYn+OhLt/IUf7O9nAyZW1ZQRWu TCKFaCd1C0iljNhTLUwHgBrgDRnLl2MfnrLDDlPYsxvqm5oaFi5a6OloJzvgjdtuffO9D0jpagmF p2ww7aSzzh49aVIKiDS7A2+gZGYIuqQB9AoLCV8r/m1C6FfOn4/ulgs4LYmkv7bG21AHolshGUe1 lhK7qsuGFUefw5JNk0tG1cJU66p7brhh8axfYt1dwwJ+T40nHwmuimfzbnsglq9L2Qp1vlXhjlHu MUZHxukmfNDiWBESS6sbG3ja0hBIE0GvtEVl9MfXh3yPFGmJSlss7FksFmzJJoGJV74M3ET2QkeH BXM9khZvp79umMU9s5B4b98T5qZCuRF1ax+81x6nnADMF8Xr8hmKmiZIX3FL3jn1NyjvpypACvZ3 Gs0JbySmg6yHTwEOIm+WOhvQRIVGq7XDCymJ70RbscVNhT4BBdS0c67E0eIl3L/HdcMQiPSQQqXJ 1BWXXLL2xEmBel/aYTn29FP3PfVUI9SdiMU9tXWZFcvqfO4tjj5iC5pIx+cuXNDd2Z6dP2v2T7+8 /MpLlGBEcNG3Pfbe61/33BNv6wYBnagAqZ5HAe604V0VNYLdOAkE+yaYidhwXyo27PG4KJZUl9WS AO2j5ImRmpMSqouQrBrTOZh8rm5ZLv8lj1m4cCE+xvXXX/+5557jDdGIYLdSE0fLbkQ2SFKrVq5s HNbcHQwD2b3FZpuiO3r8tQRkcLjwjZpUSMXSK5a/9cHrTtY31Wy8rjU33sjX0IzEUlJO4UEVZXLP w3FE4OPi00SKsuHiWhHxVJTrmjolQY989zU3gcwGmidUnPn5Z8sWLj7skIPmzJ93xeVX+jBkgxSP D8drnzBNdt04tl2P6GVrTJkaeeSp/TbZvHHU8JiRO+uscw++6HywZ/AvCOCZyEUfxf4MnMickhr4 ic1ocNWlCnVzVxpTRxlINVBM6Zi1ALR1Op4goUXvXj2CRfGZrlxcUn7oLuKMKQQASI2akrWYROBa e00tW/qIddc64OADXflcJhJZuGDhzI8+m/6nv0m56KLBhM2sKIfU6utJM3IaAjZPnS28vn0VLcAj pNS07HYFkDqS7R21DXUhUsNrRxjuuH/YyHRnt3d83fiJkx557NEPP/2cUbl9gatu/c/ojTcTeBYQ Ne1eDFxnn3U26mvrqpZfZ8369YdvLU0NRmON1eAlV/eSxZee+8e2FasQf7jdTjvxpAPPO9c+rIF1 7MGyh+NU1DalvpEJ4rAMHzXc8Dt848eQzmdMGWk01IiiZvVjGQqw4CVK0CJv3J5cgVK57MuKAeQ/ vXoi/ileVp9AfgIKZORjVnrlcuKj8vvrjUlNxKeAE6e8jcqJLamArDyS3hJgkBhOb9yF/LAZdQ2G r9bBnEsZJrnkOKB22kljJ8z95VdjzBgb5EW0UV84l0+kknN+m/feB+/7bM4nX3iBIPRdd98tkkh7 Ghr9jXU2LP0o42QSZaVuMtOh0LXQ7ovHKJp9/E8PfPrF58FgKyJ+l113+fNNNwYaGyySK1IQ3LIi u6C3MGCXhX3L5yda4odvvxvVUL/ltA0pi7zXvvtb6xuG2UXKu302qJdPJUY0j8Z+YTQ5LDWeeHtH vt7LJiqAxKrKKtZ+7YCTTR+ys5eTQaPli3bHlmjLXRiUgYoSxQNk24gRqIXEMke1WdJwYtYciMcT 151aU+t54v2XrUsW7lEXcAFdT1gBdWpgaJEPTCJ7T/6XD9+nYi1CPOD1jRgzZtIWW0KXbDKBj5bD jpZ96um9i5oeFnuGvGP15dJWlwdfqkJyKooLzef61MOvOcejOIxorP/nnf8eM229aFeHR9xXVqO+ yVNv5KIRx8hRPIAM6ry4JePBWOy1N974fMY31OJgjEcfdRQqVHPz8Fqi++savcNH9xydIILVWLwy 76UMZc7ndLnx93odLPliDfuSOFLrkfJ1/EUZ6jWYMAQVTFRRHGowGT3g56shuAlQR7u55ZZbPv/8 82+//fbOO+/caKONpk2bhsgunQUQSSQd7D99+t333f+fO+7edKMNdttlZ0JmHD5/fX39L/Pm42lz 22x33nX3K0++OLx5RCgSDkUjdzz2WMP4sdq3M9hpTX+eWbrCsdakqic68cZHwvHu7mxtbbSza+rU 9Y/6y9/Lx1+ehkC2IzGCEGKLXXe+59mnw91BSk2zsTY1NiKmLX5fiUao6RaJFrBpACN9+aOZsWHU J5XYZxSHwL+SybDd70clrDofJGbjNJX6tv0vxErziD9cf73+5vYTTrKAuYE2j8e/yKI9/+n/W+pI I8j6xZhXnOftLjehkJxf5HIJczqbh7PY/nDWWfv/4VgFROfksDJq0mS5AfS4LipU4Igzjrr0Mv3M tx6476arropl0rauzg8ef+LDTz6ub2iYP2eePZs996ILJ42feN3f/rZw7hwrwOuRsN3lQM3yKGuD vgoE8KSToWg3762JaCjSlR9TVyr2puCmZNXyUrNmxYlGULYUeu938ZEQUX0D3dPhEBXPRVgwHStW yuc2ZXHqYSAmWrdB7gVYkrwh4V2iv1hnGmwdVDl1e4nl5s+da6GeBhcyTl9Wo3HkyKkbTrvtztuH ef0Uhjnr1JO2P/lU+SoUUcmExadQO7a8y8u+mnHH7bc3Bxra21oXzfttr912O+CEIz587fWHH7h/ VWurp14O4MgyZ21diYeQp5HOrvyqdmt9TXd3VyqW2Oa44/Y67fRSs8UH0F1RbX3pVKeHyRKxGJMR 9ToJJQajCEalfiw4f4RsDYUyWhyF7CLkK7FjFS+9qRUaanzr33YZR6Vvdpz98dtvZM7Pz2tpmYLt +MhjRq6xhpoYuUhSvOLCi2KpJGmrwVBoRHPzYzPEU2J3e9PtLfZBfN3lU8C+GF7aVjOSQgqVS6Zc MoBJsOZmmy6YO6czFcPz6G/oE31v8xfDFlAFSNp3B/wnnnX2QUcfQ1lEAi9Hjxo9fOJ4wzdgPpTM RhTg0eZ6zoqJCDU4AEpjfAMDtErZJoo792VXcEMTyThxZuX8sFrvV0NwE5j86quvUqiM0BaE+D77 7DNz5kzyl4iLWmONNST6TW10bIGs83fee3dFy4pNjQ2kN4TTBbuWzp3/y7czX33iseaauh9/+nmD tdf61/3/7Q52nXz44fHOdrXPUy4onYrHxeiIhkvwkNhNcoVwBHhObPnUxBu1xpoSJRqNZNnL8aol 0c8ytTV1iUjUms5IfV6MGLU1y2d+d+t5f2zr7KpraJjx4w+n/PEcgREOx1DzkL2Is6ygzdnYk+Ge AouZSMCOkN3laZq2QRMiEapI3JPExxaIW5S6wAhrIqfyYHPkwlEXGHSRmOH2o3QsS4ZCG4zDZoJu LkGHkquZy6ASY1DCBCx19FTpy54NV4LWVDnNHjUcswaBg4V0JC6fKUCVgjj1xG7EjwnuRbkgDdHw +jPRsF8VlVfuXCFOPhJFbUaKqSg0+Q1WEH6k4FJVrlAsqR9VehwxqxxdJTO/NmC4qNFtpCIxOwpU KkJJBT4hwpeT5rC11h2mdx02D12UknpgRM1a7IVoxFZEBLUAEx/r7CRu/KL99/O4HLPmzm0cPWK9 dafajew6U9fZZe897aNHr/3wpI8++GDODjsQWT964/WOPOvUdbbZQdokPBYM6Fze73EPrwlkly8F 5qLZXWeZucQYSeVs1oI16xfvuz9ptaQtoRoLwhJAGdKU1VFG6aKCT6BEDwHiNiNpszUgGxLpvF+U XAE5XRZ219SG6PzCFqPBB2J17xFEx5yR/cxvCXGzZ5obaglv8LEHR4ISXwTCHf2Mowxm0Tlqa2rq fAEgTYxwVMSxyuXFp7bWBlP/ddONtpqAldpahPA3NhW6Ophjq8K/4EghGjahUy479OpcvjyE+uJ2 f/DOW++89touO+2UjCfX33jqJptNG7npphuvXP7sY47L/3B0Y2MjSN6HHHrw9kceZWCphwFcHhJh 573z3n//+99Vy5evs+akYDAk4YedXSJ4kymOaECCQAQvgID4ClFNrSmZwpiF00QoFBy1uMVApaW6 AqX2YFK/VwoyoLOqXHIK12Uica3dF0mqCKvew1iChCLHBRCrWQ7BqJhugjg57Jw1nW3pZDphzFrM qWWznbZv/yy1Yt78hUsXL5o1a/+995MG2JAXL+D01rKqhXVxwTln7XDgQR+9+NJ/bvn3V88+gxCB +pMnTjRqidrX2T1WmByad61cRWB1XX0dm71v5HDOQMrdB/MkcmlMSRIVKLCOrBVC67CSW22hRUta Wlol4D2X83qcPlU4EBYtHuNlbXFqKBlYZW2wUU+csn4hnbIM5xF5WV+csznZICjEpi/h4ALuL54A ogMNP5v3ym4jZfU21idbVhnhTA6zowr4U3i5xUOShKqKS8Yorm590gPWlWo78C3xyoNHTw0tx1dD cMNqWEWOP/74n376CQl+2WWX0b/33nvv5ptvPvroo/VjoCkq3s4777z1lltutPnm836dpaV5PBKb OG78k/MWTpm64cQ11thj/+mT1phsoTRENDp6xPD3Xnxxzncz3X7vmDFjdzjs0EhLa6ABoKikxedb /uVXRx5xxAhij3K5lvb26dOnX/SPfxg+L9VdEFdICrT9RHeX0+m2DRsmgiAaQ/p3zZkb7+g8+5yz ifY6Y/gIcRAhZ7H7ivUMu6bIbhWtSn8LtMAKwWzP1BJggXS2AI1NKTl1EkcrsducyUxaooYFdl1K 5CoYHZpwAHUS6gpK4iX2egFCRrirIxOV65hBzlACPCPtlJkrdIHa4iXRNhL0qxKTtBxRwhIBLGGr MBh3hzoxQrO6Rk8YN/ubb1/4y9+Wd3SOnzB+x/328TbU291AZqoDo7L3iREzL9VchaV1s+UsgFaF kcjulnw2+tjVbcQimVgCj58RDOJssARqhaWpJZgRbA2OdO6aGqCnMPuw31gdTgmolxhxtbnksjaf b69DDm0cMZwkh4DXQ5MT1l171KQ1OXHI8uNwEAqe9KcLt99nL8DvqcV31+235ElXYYcIhdBDLFRw ikRi7R3pSARlPI9oTBYsbSH2DwP7VY6dmLBkq5hTJWRc4IfUHlikoagJPQMUAkBy2WYkt1VZ/VWR 1gQHcABp/DJrjE1iInTJKKGRahD6sRilNiWBe+2dnY/deTuGBO7daNMtp+62G8ve7nbX1ruMOo/f 7bHgP+Dkm04l2ls9o0ZYYjHG6W5s9AT8KasN3F1EiYQMYxBnWyXQXCJLYAcrm33bnFn33XzTNz/8 4KsJoFbvs8euV99+u1T7lBQYG7vFOttt/7err+4OhWpr6+77981zfvx5sx1WEl790oMPegM17R2h 1996c/To0SeeemreZt1il12n4mSDzqokCKMWL5AObAflpUAWGEYluFQySCXICjKiF4pzTwpzCB+q qH5sVyKPZG0UQaXLeUZbbnFdKI7hh4pdWWuYLNgRcCxwroskxowcKa3Eopsfecjmp/4BRN322XP+ ctY5nT/PHl8z/Nl7b3v4kf9idgAixkjE1l9zTWdD49imhga36/nbbu0KhdoL+bPPO3f3/Q5AnYon krXNw0m2vv+G6998/sWRTcO6g6FYKnHVDddvufNOnINz8ZhRQEYoEc8Scti729saGhrToYjT5nz5 vvvffPV1gs1B2d9s42kezOmdHbZAndadlJFMF/LW0R4S8Y1uCEFIozA6OrCQOEEUIB9KcnrIRUBV ggGB1pJoGmFq3QwJYhks3jYUPla6ELGnOLhwnX6W9pDztmd1qy2QdYYmIjkesu39T9dq/AyEhKef fhrl+rXXXlt77bXb2towZ8+bN6+5LOYXQQd4PP08+YQTZv466/033pTeE8Y4elR9TYCidrsdfsS0 7bYtdbUm4N9k6tQ33377l+++C6biZK18fORRgTXWLAS7LY3DYIJkPBEOdd97zz31W2x22znnxhE0 Y0fz85Ktg/objlrVHvsq5UptLmquQxC2hC0OONAYyyGp96oYrVd5/LM4OZj6xrKIb2WNKz92eQw5 b+KFwzflrSkPJLdNHb5G+IvnjXE01Xv8Z3WkVnU66gODnejLe5WLxMkUcAwRn94TB+yqq+kMdr3+ wgvdiRRw/r4119j1sMN0U/0NB4Wo5KladF5+5YXGJJluEoWdyU4aNaaBFT98rB5yiUpFywOfqChU UXHRd5JpZ72mePHyruHfcY0+CBXFLxbPMoaPM4gibmjaYqNN+XDprF9sN9+Q7gzKgg/UgydfyEQx VY2qb4gTRj1sZGHRO35Ezp4byKmiOC6PTIyigNgO2CziIUojDkhYyC43egxLrVvMn5TfRaNfqynS 0W5DyqwjnDNgkEc6BDin3eJ15zz+bbbY/OnHHwtFY7X1w0PJ7NQDp+NwLg22dfnKArs7EWbUO9Kc 4MEAr/hD/BNFyhSZpxC1+VxW4FKKv/cM23rL4wNXHJ5JgWoFKhVoqMaw4dycT8RymbgIF8PY5Mii GvTsIw+3LlnitLsSHW1PPviwy+Opq23MhyK7H77d3qefJub1fleRC7GY+BRLdK4E+s4Y6eeQ6kKx WLMUfE0xVqFr71k9Frc6cnYzSRJou+FWY2wdE2V0kTCaADDQFWjsnL/YWGOEsUZvHHc4naW3rz35 zNuPPTt73q/rrbvu6bf+B5M9JqMR48Zhpm/cfMsrH38SNcBfW3fkLjt1rWiBGo5srra9jaOkdcxo TreTx0+44oH7ly1aePNFl1jr6i1jx+ZAAUpw4qGsjafE9g30ByufT/5++uGHk8ePP/5f16EVNGWy zZtszBT0p1X5J6w+wsPYbq21NSV7lhU0856bKjFeOpcYa48xwrl8NO7EF1U/qObM6kas26iQWXbV qnAANO7+kYJD97P07WoYWVCl99xzTyq4o2tj3T733HOvvPJKQkpOOukkQkd0i+zfDQ0NYLfyvqu9 ba999k4kVIhSodDR3rH7HnvWNTaW98w/auQpl/3thQW/PTt3zgUXni9+IZWU/Jejjtx3/NgpjfVn nnLSxBEj19x1lxETJtT4fbX1tTNuv+OnV19766n7Q8HW8qY6ly+7+qwztxo9Ymu785w/HAO2T0Ws 62AUYa9ErTVDLxQ1nF6Vd3aHnAMFvalt1lSzyiJk5vnG9L9e/p/XXn1gzqwXZn41dviwslQSIXGf JlD00A0Hltpy44u337PXmlOmuuy7rL3up19/oy2hVS8VlmxuUHQo4K8IGmuoq2usa7jk1NN39vu3 9vu3a2rae/2pR2673eyffx2mYqpsI8dmjZBoc4NfKsygeh+QhoD2Ck4eWqYNN99QOSA6dIFr7W13 uO7tj15f2vpZV3TbLbdcuXw5H4KlN+f51z+5+9FfH33O5fVGUffMXUqp69NVOTZNW3/NTTcdO3W9 NTfaaNyU9XRL2OoK+cpgvsmTJn366afTN99s3+13aKipvf6ZZ+768bvnVy7d+6ADK6d7wP4UDJ+d 4gki3IhpcdlJnRqCbibDuJWeqtk1lP3ikNNe2GDnz6bt/cZpp7jHDDf6VqXx1tbut+feE8ZPsDfU 7nLAAZvtssvE9TcYt8GGI9adgtSmgebJa03ceJM1N918xOS1Jo0fDzwjH0bn/Hr8PnvvsN66W3k8 b772ysRJazROWWfcOutg3Wn55uuPb/n3L2+9vjwcLPcz8at497If33rxq6cf+/mZp9cYPXbt8ePX 2HDa1K22GjF1ipxdTVxkY4UV7oKpi9JaYlFR9RSHhCJRqIOVZNc1BU1TfIAe/S+Zk9i4kde6yBDP 1vgbpbaR71zcQAE9gkw4IMvKcTq//fSzEHjchx1a2QsCFYjT8LgfuPIfTz7y6LSNNvLZHV/MmLHT brvuPX06oJker2edddexNNT+54JLnnryKZhvZcvyKRPGXf3ww5tuv2Nva+RA7rfn8HHjDj344Gwq G/DUTNh6qwG1kooOxMPYm9jzqydk4rVgrAA19Gnh6ue+ufyGzfJfVzRbaAtbGvzVS3GL40jiLoDF /P+19x5wkhVV43b3dJjunrw7m2CXnESiiKhIUAETICrBiIpKVgHFVxTlVV4QjICCEiQLKAoIgoBk ULKAomTYwMbJqeNM9/ecOt01d26HW7PAun7/vb9l6L5dt+6pU6dOnTrRhWLGl7waXTD/1SeeOPnz n2+bM2vTTTchQG6Xt79t1wM+1jprMpht1b+euf9Pf/rH00/Dabu6Z+ywww7v/fznvf2f+82THrjr 7mO+etzMBfNzoyNb7bhDgqNu0EUqFsyVbXhGOlz5nqWx9hlhTyQqJacWP/nkCA4/xvtFjp6kiKDM Y6G49Zu3bd5m8+Lld/Z/9hsz8w9RI6TeG9IDQ8n2tuCwDlbLi5lQVzQ0Kz666wkv9y/b7plr6vWZ x8JENUFjn7TXNz6075wNN/jaeeetWrrsS3vuTgrHx156ebMNNt7lbTufc+1vHRBADpORpkQCh6jA xiTRCGVGY+1TxJolTz7Ru2IF+ZtYTZ0dHRtss03cWCxDPT0hpLxJn5S63fcMLkWB0xrpGH//Sc8M 9Gzx8IXNdcz/yJtkpEbrHQiq7BnLVobWmwv7vn/mPut/4N0zPrQ7aU5DnaUZu71FXP28F6pLdCO1 LMm+F31hj70yo2Nbbr/tyiWvPvvSi9/831NmzuomEwba7fk77DCybNnRH/rgk08+RYEfslm9ebtt LrvjLrxnbCcv3H3vJw/+xPDgAFs0Frivn3DCET85g18nBvrCLa1NDvEEmNAymVz7jE4HDITSry5J zV8Q6knf/r7Pbrb7ezc5a9I+7Gcv43m4ZAoW57nGCVSl1K1b4Qjvg2s65B3m/sSTT46lx9759ndo xueB7CgLlzhI/J2lIF1+4smH//7IvfetenUZbpKh1sReH9v/HXvuiZaQcgfp4WEsExhSegcH20nn WCwetvtuP/jpTzbYe+9/XHv1/51+GtWDhgpZrHvfP/P0Dx70scwolt4kxhZJoWtilMTl3CBAjqVS Ftjoos0dTfKrxlW9NClw9fxpOm5+GHzhpbnrbRzKETLQ9MTPz3nxxZcO+v7poVREfOES4V6cFjvb UaDjLttcxP0M56tyhgoRwfAN8jk7Gqec8vZrAFM1nPqno1KMo1iQPFOSKhwI4uNjo709N9/4xxdf eAHDB8U8cQa45LLLYjO6JI11Zxeq7sVPPnXUwQfv/PZdZs3qvv3Ou/beZ69jzzhTfmWBjY6wkC67 +NIn/vHkWeddgDaZQsXZAn7JYnpFPMN6V/EJ9+NAvKyMKVUzajKtmnDDttP0T2U0knYFdx0vdZJh IxqXesimTAS6UnzaYqTIwG7EQ+l8/tZHBr70nTl3XxLaOBHKc2ZqK80YX9WFM3B01lh4pDlCIWYC 1dSLyfd2kJbKFpqGw5mJwdD6nc2PL15xzM//EuvZaEl2wUh45kf36Djt2GLrRDpZqTnpGZx2CLSg n0xL8dxEeCx9/rnnrnz5lVMuPr9v8Svv3Xnnu/56T+eW2/QWqAiG9Co5RljoNmsub2e+wJxoipXS sL5kM/yV0mgIMRirMRgbNbG+WWfcaOk1YRRH5ynKPFTzxqwtXam9AeSqG5lmIjf5NKQ3HsZxMJGN DyeLuEx3ZSfiI/iJjAyun4B+Op/pC3336pdL6Y0vPi3CiRaNbaw0EWvK471qzC94TmKsRlHpPU7Z ghIGVshS7AzYlKJZTPuRIUyRqdSKzo9u+d0TIsfuhd632B5NSx6VsnQJfsSWoGZ5TD5TC254CYsH WpOpa396/sqlywcG+mKpZKy95bCjjujacB45c/C4IpV2BzbC5ctD7FvNiTt/85vzzj77D48+Glq+ 7NJf/vLW225bvGjxzO6NCa2/5MorujbcINSdKIxkyL8da031p0dQNLcRw5GFJ3jVn1NoW2ZB7SWm rOWU2iBkYxmPJnKJdPPESLJEHAEurV25Uuui3tBg6C9fPWnjd+6x2bcPL8QzYePxqDwCA3k2XMxh m2wiYCKMBGffByqQfpTJuKT89QK6phk374O/LFu2bL/99hN7kNjcZIJhnoVsjmCQmOZzgHKYePZn jiFY9sX8JeGlhtEaNpYu4BuaWdn7oa22/vghB22901tvvvGGFxa98snPf6Z/dBgv1F333muDzbeR 4JNCSdKdJZrV1OuTM+zRRSy8lXTYjU8utNTcaWQmE5pgC4UUUs0Tv7jp5tN+uv/Su03VYKFx0WnF mp8LjS0Q9zpuiRFMSUYYN/pQcSopX8IKpcS4lDKpCYBwcAihjLViflVfYs5M0Y7JChTp5k+XXPz7 iy649JbbOKg+fvVVLyxbiurmmccf//Mttzzw+OOhBRt87QMfeGXRok8ffkQxnabUz4cO/mhs481/ 9PWvPv7YY7++/qYkNrR8lsgKVKiKpnqB0eZQSBxV2hZULVtTp64He1PqdsPkplYut3jQSTHZmMLh sVwY3t3dkrvy/oWf+fyWQ0+H2vEQIPo9gh6LhP/gj4Adk+yqNDY2yplPUnepLde+HabJZokfULHA 8SV/1xO3vPeIbU8/urWv2JZJxLeeF/nCria5kniDeBcDPSCjlVM+URMHAmTbHp/4vy9+idPe1y44 f/mz/95vxzf//tZbN9rjfSzt3t6eWbNm1cxn4GUMUoO4rw/xMJ4k9EQ4rVisPK8u81xzBxoAXbjM Nk6ToOdrNgwtfDGlN9k5wpI0Ck4BI5bds7g4/Sr1kubG5xb2O+kfQ73b3XMBaBSkm9IG9nH2EnJi khCJGILJm342Z0o7AyyHuMHB8Ay209i/o+/Z7Mufi599qPhfRbzJxMoIZnG5sCfZ3nAWev7V6Bbz y+YaY5hXHYf4AeBbhdQCZ4jGrjr91AvOv+Bb3/5WX28vjsVvfvPWH953/0y61Jrq2OdTh+ASJFZ0 LBbCQMIre3sgVwpfVCfdrKYBZqFmtWJETMADsZgJTJ3rEhQLZYdWjt3z4aMWvHPXTc89li0ZNqUK N4mLrGzM1EWCZlpQG1amXnZ0zjeUHq7UWpqyhzT8sqZzlQCikqauNLY0TjT8U9Cxj5ehBdcUiuUb 3v66CMoeabjoEW5WkkyqiISpxPvFGfHx887+2dIVKz7KdexxX/zOqZ878eTNd3h7c0tr0mjQ9E1S KbhSJNSW352sE2bWvza0N2t+sGI4TWMYfBCuUnL8iVDbATWiRAhQOJV/MZzxW0Lht6wqzSo0YSJq IYxE/so/PrThX+t5Ad3qAq4HgMhcUvpWfP4izXgwJyUbH1fFiXUok1myZOmKhYuW/vOfv/n1ZRf8 7Jzrb7ruxd4VO+72ztAcnOpC79tr7zdtusV151/0z7898tPvnbZSvMdI30Y6qS6K34hHjRk93VdQ VRsTFlT7s6rFfK3tTRVefOOaUmKXlxKIa2aWtJ4ys03hzlBXMW7mniB4OB6agnAED1G4qckCYBxL zOV/uxTKjeLrpkqnUnp8bteMTffde86PD0ud+8noMe8OU2eH9ClVE62nKxUJsZsh50rF2+b4YP/A mFpokim8XUjhKN1iW4vHtXH15S3xzKwlk5SjaZZkkJCxYnnq1Ns79Kll0gKJUIXBmohl1TCD5O0T mmEdxWPdnd2dcdFrATb8S9xB2AXJH2LKZ0+uAsCTY4y8XbFaPa1KHVIqGYYl0b+SMWZW9+y4CkZx xljjsogNHBd7QnT++pNGdomTLl9S0JnXicpFJJU5m2++6+67X3DRr2+8+Zaddtrp0C9+6QPHfvmj 3/jKPsd+NtSVIM9ChBJUWMvMskpRG4hIIwfEGgTUmVb4EmGdphAzWUzxBo6PZQXDJQKBm2JGKkNz IBRqLi3ko59bIom2uMgZk9g2h1R9nTvL9rWchnFytd9h6KbEobJeNRb2MZcLghRvXNZYKvn1C847 5y+3XnDv3RfccfvH/+d/YJe+HiTqyw0v08JgjT5R6FP9qOqa4ETuGZfKeDVtQ9MCQFIpTrV1bLjR xiOZ7ClfPeGY/Q989ulnP3fU0Rfd9OdfXHXtF44/QbN37XPsMd+7+jfn/+2+Q790RKypOT8wxE1i cClIpMd2yTbrlrPHEaWKDPfGFgNoTvpDsq+89guH82UDS4nbc+mqxhSEw10zunDbkoEgkCLxldUp RUoLufRJG9csYxWFiWO37s2GRofGxkVaApKsbEJ1V5rbWpn65vz4op6F6cEBd3gatCwWCqPLlrh0 9fbd9zz+xBOv/vOtF9x8yxlX/GaX/fZv8JSRiZz4izu5soqllATn4GhUMv1PVXD5geF88wYUUlgd 46QLcn1tsF4SbMmB9J3vfCc6blZC//CAcXsWbQl/pf5IXhRk7Pi4rBeIj0lJUVe0Y1LBIBZNj40i m0lZe3JHZLPNopeITmTxoGoVNR2p9qOonvJyRIrF8FwMI52iTjUCu7heeiZPMiOLmF2GUQVJn5qi 5leZWnMej/QP4gwW6h8Nda//5OWXP3Dvvcee/sPQ7JmSfQMxvL831D0TR+nxplJmIkdalUKpSFrq ieE0egn4JiEyco6rcHGjBSmf+gFG8iNL6I24g6umG8sGGmiS28PXUPmVumJZPEhRblAZtrll4TPP L3/xFaI8+lf2vXmzLVPzu+ObzsW1OyUBO2PkOW5KtDahCiHDRl/fPjvvcspZp+56yEfO/NbJK3tW /ehn5+QnipG2NhyAibNExy1HbbHCT24xvtO9QquMXoNmvUxfZqwSSStjMfnTvT1gahAFmFHHMEij 4w7FCV9AUsyO529/NHfkGW1PXh2aFw71ZCkWXJwbWYl7p+i4QyPNUXLii47czJdoe436WPtnQltz paZl2VBrc6h3VWG85YFdD9z9uWsRlsJZajAWh2ZMZAj2iaS8zhVefQuQS3oGzjYUbRgc/PEPzuhf teL0Ky/vf+rx9+z1ngcfezi54ebpCDWjpTiGlrX1ZukRZbHRi9l9a5SUFCYPhKqMcByBEuzSsDhU EwuQIHT7CK96rdFSxW0f0YLYVC4+mEDHPTEjW2weKZYSxWWJDHU3Z69oKn7j188Mrdjy8jMowQmU eYpZx8KaOV3qr4o+EiWTnPZ94FW+EvpARSd03KEYBoBQUzYy0dY976nw7puc/NW2I3B1zxRmJDLY lCrDF8V9JWGRfmggHEjRzuF0a3d3trcv3tbK0TzaHOUgrrFVWH1QIxKuGU+m4O8YSET8j0SxdccJ bx4dgWuIQyzpEUjbnE0343ksdUtL2BhIIkbWE1EPSfaeupdStbE1yHnOB2pY1EDJXISwBch3onli PDGSb86ECfe647CjN3nr2zc58rOkFsqN55rnzwtlh6mjjNxGhnUMQpLLk1LD5FbyqEooqKaHm5pF wRrACWBaLHgNMW7e99RTTy1duvTAAw9U1YSsOhFmyBqEjQ+TQ8XqKtEqZV2wGulEr2k+YO5DYUSc jiyGshVAfyuzGZu1gBcM9fVLPViKmZpnfZemaTfvJ35CBCh0Wz4O5X1EYZZqIePj1MEiU4ewOHZd dNw/vPbvl1y98xnfCs3uDvX34UUe6h8MzVt/6NVFre0tkc620IyO9JKlnJrDOOSu6o3N7QxvRWXh SQBUya6FwA1MfskcPi+widavmF01GJvTafi+KNQkkq0qqF3TTuXG0vFwKZZqE7mP1Z5MDD72r0P2 /XC6aewtb9vxznvve9eee5xz5W8pE5MjBgfGTlYjIyX7sOUlOAkHz+d9uPLh1rJC1XFXx9x7x8di YVwTQ+lYZrxpwczCxXes+MKJ8/sfIEMY3sGEOEkZZ5McFr2tJtaoq+M2PIh4QdGEYnm7/onbPvr5 Dzx7fXTLjTF7QjFEoYi2dGpWNp1ZVcWSNV6HL3q6iYn/OfDgRGvL9666snfRKx99yza/u/XWuTvv xvAhGEoj6oO+sXu/s6EN9fRKvT5xQyq3rXnkohMXxAqdm5eydOm1Oj8RYVcsKshCAmpk851YnF7G 22fH5xT3//aTQz3b3PFLtFDioGbibO0ltI1rk8mTU3/nENYm51issitXJuavH8nkF88+cObXDm/5 /ofFeF7LNgJi6TwwJzuwmCrGmTj+1BUC8uKWBaB8QLYryi7TLYmAxIJVZsdaHkPaCPvQQBlRKJmc DUZb1YAdqiXZ6J3r15ykfzN7ukBW9IfbW5r6M9d9/JjskhUbtq6XbG3PzWp7x/mnhObEJaJLI5mx uBdygNNKZpWpPId3acK+hnD5f1zTjBsie/LJJxctWnRwJWDEQoQYDtqoURE4AEaeHku3OFR0pavM 0IgoLGsFKfhepJp3l6K6WmXKt0k+fup5QxffmFy4yNAKUnKxRbTdmUd23nmLx15KkvUvlEmEKBYS bQsl5m71ltQvvx7ZcysvDHafD8SArPCeoSixQg6nv3yG6KywpA2qXKPLVj3614d6+pdLUC45LTfZ ZOf37IXybTyNFw4SerArGMN3r2kLYjWFZOC4CkNj0ZFceP6MicvuXvS5YzZKP0Ed9XpPwTfVONm4 2/xVDz942Dd2efbKxEYLAgGoaUM75eCPU1ThpEsuHl340iF7vusnF16w1d77MVkA4FJS1hAhuVma sZAHAgBta/WywJZm6xoDsS6N+yd6ExHmNVU84OTnMiOb3HZ2PVDGJUHfOKUUAwGAV2aWLk0tWEAW 2d6NDk0e9IGWcz9f7yn3UuAgFooF4YEAiP8TGRyplePgZ+lILbwUcoWZOtYiJ7Ao3JbijNj3tycG lixrX5UPP/zSv+9+eI97fhnaXuK87JUVP6ISCTq8N3UduStn7LOWcU+P3wfitF4DPdjqudIeSXQL kvtls4+eV+peTG2OjAEOF92ibikbpVVWrXNJy4ofeuOOFVRNKS5nKlN1kc/bH3TADjdesOHtl258 zzUbP37TJvf/bv4jf5j3xJ3v++6xW/zjd+v9+5bNnrp9g+funv/0HREOqitWjHcZ01nlkuWdySAX eG/6IBGs6i3WTJrjvobrNroEWg70JpJFnZwAuXW92e8+aP+Djzji4MOP+vjhR+2y1/sqhRalVJ7u Hw0uutLzbwNQveOSMomVGW/cr1VE0kySwqhswrO4FQiVyNM6YG4j8zYAVbyPyn5EkVHyUOp60dfX wZl5lVzlhjpAslsUi/f95c5TPnLAd770RWKy+3v7FAMatRBIhgbUMgbK58L6z9An2dmcu5Wio9WN vTCJsDdRpM+xgpAWPiPpNJG0BrFVYChtqygZMC6zlkQJJh0hpWbFS8fgpfpBea8bDShiEU6DXi+E j/YhS0SFAx2agUsGN4duy4ipj4HJPhj7cNGkMk01z9zr7Zt9/qOz/+fjsz69T6KzVSda/lbIdWI0 kyfHw9Qlj6BQsziBIVanaw2pSoDy6aefhj3tvPPOHLTN7porHzRZp4CKbtUcQqxiwxYGlDEb1yBV p5rYPfRQSOhmvZsDjOjp1Dna/C2QBSU0IYpFcxgxOsRK4UTjPiya4sqJXUXCKcrKqXpb+6soFk0l wPFijtcRm9siKZIxUTSLI6O4n5NeYyI0OByKJ/Oo6sU/yFQnWNbT0tJdWrj82h/9ZJ/dD4h99q3j pBeuHJulPqShQj06lXXcRlsqSqFiiCpVsu/BW4kh5jWpBNUk9Wl74BWKNuMn3RTKVElFi1pAHH7F sZg0ICNDI+2dbRTo6ojkxa8pFstn0uRkIzYBo1WxKUrXVDbFUk7KVK+yxocZgGxgc9MdQkkPxFot pyXGqTpuioUVouOl5DheAHGy7o3f/nj2iB+0PnBhaL2mEBqsUmdxxvjyLmY9OiuNH3eUesl4RKuo oq73VvCUk36xmEQhik/cssGJgaYHPvCJzRdenpzX3bmc1ObhsdZoKVeKF6d4nSu0Kr+zG+NU0oQu KJ4sDQ4/9+RT995xeyGDnnpiRnfnJ75yLEHK6XirtMNrcKq3L4+Xddz0V9Z4UU1UWDwaU85+aGUR JXLFSUu8jkL3QuV6Wge5wcI1AgM6Xslz4ZPXSJTVko0PJEvouLuyxdRoMVMYzm3SiUmm5Z8rI//3 +4XF9PzzTmZKSMhESu9CjDyL5MqXQ6KoVqDtSATarvv2CCtIPO7jKKNC4bFSIdrStqTtgNnfPGrG obuGOnj5RBYdd+V5HVQFseXFW69zlmS2QHbfch1RZGrxVTLZj8vprcsld6R7sSQbX8ayp69QfqmE q0tFJyqso5IbBGcXneLGEVuKf5VwqnXcTZQRmkDHTdpZcniBQZIa5WfiZZ8bjyFKD2ZCKzpC9z/y 22t+dchJXwvtTFwoVSrzBAVozkWSs+cT5QWr8Pf19aGE4NikBbXdrzWtKgEXMG78uMkSpVCWsRki 9MPouKnSW9FW19NGgVUSzbRNlsWr3VDvZqVEZDSCC5Hp19vUuzJAIgkNmHMUBY3XjOjljfxAlhyT JKzcJXuCUD8egQh63OMLM4YO+umloU1nS8CLvh5LxmMvTrz7K6kbfxp691Zer1Jduj5/Z+9c6oZk /pSwbcY72+V15vKORT/TWJKKSKZ5lmU4ltK6J6qek8SEarA198r2hDyHRHzeyn7cdRkHoyRGJ5vN SUmKhvxFqXMsk05A3BVQ7YimbAumaWlojCrL4bld+SvvefkzR2058Fi4s0XAE6dZDFvyqOw/smSp 1Y6Gt4VVXRMG4RQG4fnfPX7/IUe9Y/H1yQXro5bV1G413XpUx41QQBEamdcyAsIoLyYzorARigWM lTgBwbS1ttXDwCSlYb8ZGZFKwRI1V+60HnLhQQWKIMcCGLcidnQMvW0CocQHg2QmM8pgEWLkTaXe sRUtzalkc1f2wFNeGejd/C+/kEIO+ljl/0oYoQxpsydQiDeaWZXJSYnV14enKYx/4cyPzDz8E21n fVpeVhXZLYjFQT5MyFLwuLDcUoe+o5l4DgGh1tou36OoDkXWpaBBbJIbGmr2PyWrG7USwatBijVp mR7Lj+c727tqYkDCfFWJb6Agf30rdbDVJZeF39TUd+Nfr/vOmV+4+hdNW29gSh1rW0JPRIQqEp1X mXveJbXkTZ6p6WpL1rSqBPiQjEhjYldv2TKOX4FUly57UosUoz/UvjBpiqRTuVhrNf4JNprCWHhJ t242Z7m87bx98zvHTmz9lYb13w3XIw4KiWlq8n7xY2FJQ/riqyv+sBrmPrqgo9hsbKgSgmNYT0eU DJPFFrHKel+DdEz59gYACPCImcYDeTCcwRlDx2jc+Cb/mSbyVQIACIRrwqNFkrirZ6RheiIFl7cR +cFAhmEK873ArniqjwHxdAkjMQbiSjqiW04SU0damfSprxDTKwkXjeOdJLDrFA9u5SbgT9I6yD8Z vomZJD+4jLM8sX5ozYMG26GJBVQqov4PX9S1ts7gZEuWshSShdCE4us/8nt49JKmcqPARNkaD7lW I2tyPrB3jWckHFWmozxP9ZDLrpQmNWOdQfkoFiWOMKmqxmQVpqXgSqpDSOLijkIsOSzI7B0vtseb RSAW4jPE432cz+NQxtSbtcamNEeKAuiFYNf2VGu8EnFcjV2hASSFhuiyLyFagbzwStR1mEAZi2xK WcrxSFLHKcu6+ilhkSb/cAOqLtMkTWGtLPE6U0Ai5/IqpKHsSNT2gSSMRGZ2hdZEdBN8Zzhmy/vK M86HLK5lnAE92FEs65q0/HC6H9aQjhuJEmkVJxjZn/RAIhu0fJCs0xX1GN+r/5nG5h9+geIqV36w ZmM9c7K5IXcZkUIDimu0VTnXrPCyqa9Bh5XDrEyUBV4hsQddfbwMLfpNgoBN2kz5ZzSS1FkZS0Zy ZG+QTbo8KLu9l49q5ZOz6bnqH2p1kabtW8ofFAYLTBk/tDP+ORWQJsGb0r4ifuGKqfNS959BrMRw TGLAvNc+Vf6gN8XZrzIDXsxUBlV+j1F8CUc2drmh6MT9oRFOymVBpsppXebrqaUhwh+4JGO7eLDJ Ab8yxXJTs2vmxwdCPZo+jHeKp41iyIN5JSohQj2mVMjSItOLkDLaDRGaGayaoKlkRhtM7hJE58Ho 5Ex5HteeK91OEkaFurwzKy3VxdVHBnzVEVaGKZQnihAEGKTk5iiJsE064nKieY1GVmwYadVMr3E5 qU3VArp5g6llI20z6Z6+lTlycVQIeipuBbHWxNCYuhTzmrBXJ8XXvjw1qlMibbGEJtYlV9vYsFC7 XjzzVWZBk6g23ZpcyJW3++bXS+RCMPCXCh8TzyjW+9DocF8vGh/BBptVeUmac4ARvy1/4JvJXiDw T5df2/avScfNjuHybpphsX3uuefIBEviQDTdOGZojmKDWVkyKgPUG4YQZcVlWKgHVYQELtdpjq4i myHxuTh9m9Mxc+ApPsLTpF3gEIeMgYNtrBJbUX/3w+8bVmIEWS5/3W5JhjxF4cji4GCA3xW5SpLj ExFWC+5o8baxBx686dcX7X/Ap8Nf2AcVvIW/sgRNMK3ggnpaU1SNQFbZ60QiiMcIsZtU1BqWVDlb VjzWEXYZu4hfVRu7r70J6BLRW7exxpeZcTEYlA+lvFZE4UnJVGdKf0UCgral9sfkTJXG0aOGKTSK olXKTjblJiS/M/p16odls0sefuqeH57/2fPOD81uD0XGQ22YEARRhVV9ucHRVtKwvDgWQouC7iGd CC1cEnrnhqPzx7OR0MyR0BD6m1BT14tkjCmFRnqKvfFFe35ygyeuLM1PsdD7woWZFI6MJ7LUMqzA Y6FVIhQW5r2qyAzUmW0mIh+qLlBDMlmb5gVcDeNShBaeiFcUJtEohFCYTFUy5XkjfYmo6aXqWjPL obNgTBcitnmXDOLPaCmLT3tSTlkhfCj7Robmpzojheaml0cXn3vp4LLF2534ZSkRudnGIYpqbrNB qbkw0hLnCEke8VixaTSSk7htvaqpeiJLnARphRJyhIhiwgl1zBhY7xNtx30x9eEdQzM7xzvGM0QW VlCowCPPqhLFRyc+5DF4DLkE4YrezOjxjaLZc+JhDRozjzqY4pcrJWrrZ9+0qIM4hYX6mMXUmRUP wwKigFj9Zf8w1gsvKUhApdTwKF9AW5bXTLcJynwuGw/9+f57rrl6z68eH9pi09CMaKktlE5GC+EI 9ijaU7ROUotWdDkEmhDYgYe5xM1P5wKfq+/HzcPAzV/oXk1VXvuVbEcmLEIt9bYZ5Rd6enqom+Pl 9crTmdtEkIpZFgR255FRSqkGjpRuRwd6RQ+YmkwRUPMpaSnW/HBre12tpZ0uUrznC1QvDOiT9rJo h0ZbUokK2xKGGnphcf6th0/c8P3ku99mkSCnOer4UDbFQXEM0+zvW9E5Yy7BtX5anDo8QSyiPWH5 Qd3KsS9NfkTKiQXYSYQdTLAnZls9iRfqzQXdYghNJog3DtBvyl44NMxG2jRnVu8f7nzoy2fu+62T iTDGd4C6t6H21szChU/e97dX//VcMZ3dON08lgovzg7tGJuFi9XGZx2b+sR7hOSMFlnUu5ropylc uPyvT372izv9686mrddTeWpSfV0LV0SLI08ECiIYpsfSo+0dHYEtGVeeKDMYjSkI1/giVEP8LDva XbodHhxCGV2tOPYpeZnT/NhAcyjV1JZ89ugfPnntDa3JeDqd7Zw7Z8czvzbrQ7urslu1Lpgy80Xc ARtHAJk3IEKt6C3NnxvuGXx+9gFzjzi0/VeHiaxeJUnRLd545ClIpAIQy4whahBk19oesLrZ3nAY S4/iFpxCyd0YXUKE4Irqg0E+qbSkokeukOvs6A6cAqZydGg41dZqtiW5hI1cf/d9x37/gzdeFNqJ 3PRGzjY2pNIIxexQKhFQUjGesOJImkrZa6OdCiKNKb9bxj09VQkWPMqVnXvuubBgBOeTTz75xBNP JLLG5riCjz/77LPXXHPNiy++eNVVV11xxRXW6E8b9X5VGdBKgmVvkKn3vW28rSX3WO3fptyVt1R2 2cbNaYnEp/mdAzpWhqBuUEFXuVvVlorSWfCMvi+WLxKJ4+2hPPFmToN6FZ2eaJakaUBjAcBoiQO7 lQZGWxX4elHwSuWw4D4ZiHZb/tBwYLTEwQtpig+d402bLR9e/uWTnjzymGXHn/3IYV9/6MCjn/j6 mRve+vwB+370U6d/Z5uzT3jLoZ95z1nf3vToA1ticcq36wAVeLEYo3HQyuWx2JzQLA23kZ/kx3pk Zc0QgTiQV6m/U+BkyYxLwl45JDldzt2aJVMel7dnPRHaC8kxI3EFgtgND//I3pecsdNPTtrn68fE spQDMbomRZqZJHRwykIagloW9EULR9NksrtrNvHJ5rEaDyoR6iGiMQaUUsWNKuiSF5mE7CraB3Sr fQY1UyqVEG4XPqDEZuz69u0CSTTSTKZrMpSCbwxBkotQ+pUcn0a54G3MOUCY/jS5tpmf8jUNxo0v PfsnhcouuugisqP96le/6u7u3m233X7+859bxg1wOCccd9xxBLj/4Ac/gH3rT0DpzZvqhSBKPGh1 dQJvCwtrhFiCVscdKkU1xaBtVjtOplpTnsS+td5cvoecS4rxBg28P5VtRJ5bkiyCusBsv1MvUgM1 O56YSFDZnBLLhsNlEgI5QUv1JeISHRGLqsjh5QaxkpbICYB4SyraLpt69P27bLXs7jmLb9926YPz F//+7Svv33XVfbutun+DV/+QPOtLoc+9p/2z+8w8bL+ND/1Qx2f2GZ9FSFPduC2JTQ4RkuoELCVC oUOXpqjjSTfk0lIw0N4h+cgcLtYx2bEcGkoTjLNSrN3hIt3ChOk1ucPmM/fdfd5B7+s8ZL/cSKa6 xMdUjVbDruFvpjwFdZAxquOC2aB1glOvQy5seoCVkfDMYUyoSWOtLa3QrEtjOfM6RKsJ7UVMdTeH C9SnJHHV1JgaEuWmYjd96vBrt9337J33f+Ka68o90boqDFBs1Q4vatDEVccNR0ZTcfnll6OdoVzZ r3/96yOPPPKTn/wkHv5nnnnmgw8+qCEksOl//vOfhEdSK+euu+76yEc+cvrpp8PuqWeGJL6SInsf +hAH0rGxdDv1WcQcIBmZGRpRjrrElB69n/Wr1F4h+0cmF00l4Fzi4zm12ZTH0cOOjTATHFTtXufF wgS7RZRjY5odBWshIJFCXhQ+KtGLnrLsIS3dUrMunxOvZFwECnnO/gToy6Zb3vONQWfSU0jcpTCl m24ljxw8UTKUNqcm/vHsS18+bb2Tjmo9+L2hbMYc7aXiJacmXMFIOy6ZGfBJCeO4Xc4ZrYdfFBTl Uy1lK9KjiZYOwC/7Gxkts2zdquU22jfUhYhGGsQcAwaczCrnNAmRR2r3tBftx8gYxzrcxmToyKyV zUnHrtow1YCB9OxouikZL79OhXrNrqcTJzpuMw5UQOlMFB2eLPIy/+S+qZ5SOTNqe+aVcpS5XHN7 u/BPjcYWK7QnLJsn6LZYJL/f+NJl4TkzYy+P3PGJ4zY95uCNjzlI6keDThYd87AqG5rbGcqPjt/1 yqJPHb3J368Pb9bJW3Jkl8vjPNREpg8LLa/GesHSHs9KiVGIUPJ/TqqxhOqARMHlMXBFewL8kq04 j4o4QoUQHZxROBC8bxI56MXMYo2XmoTGJ5VjDYkOkU9VXJWZkiIkBidYqyYmcvnWLkAtK269MyVv R5KTSDVRMOdHSeURlywcFb8XQydkEoHYSuTLEZqhnHUx118YTU40zY60oG0NDYyFSIbWk77uoEN3 PeWEOQd+METO82iRlBtMFtQi2W8o+6lUzT+lK53ZEiK52CU5b+F3T/HM8dZEU+uMp5vfufkRh7ee eggDL7ZENQWNPmKsMsVCVoq1RiiLqpcSicVQ5at4mhbyrO4YuhojJou6377dEBCDBUtk6+EUNTY6 2j1ntuQxMmIEDEH8aydnyqRKlmgPVncaN08wJftHZaakpWdmRQedJ+l3Dg5AOhSaoUBH5tDVpwAb b7LyZ8AbGxxiwUoBWjyhyETU3JJ97Pm+Wx/I9fRjOhtuKix4/zvnvHdXSi9GKP5JOsaE5CbWrhgY yi6IgGqxeItaenH5MG1VCbOAbveHP/zhK6+8AvvmYpCEhyJfe2tOqp3tXe9611577XXqqadKOLu5 NEYZts5fPrehdSLHBuwn3MQuJxsd3I4KHLX+4STEr6LKJ70nu21ThPZELTZoj1MOOy3SMWxATA2s VSIeK/9YLiTrFTU8+RUBIEFbym9LUVexmMN0pwLDei2DGo+3JFJi0SZHHwY6bWxKHHiBoSv0ejg7 E3QhhwnmimTT5G7KT6ycyOYpBZml0KqYJ+HqwthMBiKx3nAxTIEWo7P8Yz3gOUzYOFEnWFox84mv sYBXfqPgAUgMMLJdyIci40Lex988lYBeIjhpWPBoLwGfnvZAm2xubkmlIG86hx942/N2CV+UngUS MCN2Ns6FxinK1F8i9Xl5LsozBbQI+01Nps847kQe5AAJ/RT0nxSEpLin+OqFiVGhNwmuwXwygbmS SCJ4UOUfGdvlMBrBIzvckhDMwGaJpwexWNQk1EEKckhd9vGIYHssjx1SODR8KIchTepEsH1SLAAU WXgYO7gC9S3JZAJvOQ61/GqmVf4ZDY53dLAMTGNk5Wd+GaChBCluUH6kQNTF+CSlwWTZDqmZJrMq xIaZzIt5DuYJ8UWGSpuomAAReHHlnSlRAGPvJsoEig0ZxELdQFvBfAgPQWbW0AzmSwx5RUILyV7X kmyi2iFuqQyO+u64W2bEaN/aOkPKW4/l4cLkIyOVbWeqLYEUaWZWJ3fKkuTtUktX8uvKr81xBl7I ZSVHOu7/MGxRDkihD0UX2IYG+CeWRFwA5PDXZIm2euUycHyiscfIIyxzRAfPGqQ3sWALIsV8CaLY X0V0gDeXke+bKcG8rm6WIbgSKjUzW54p38zm2eZI+svqFv6qUUDl1WdQKs96GQ78XSK1ZFAJyYAb Cw2NJubPXf+zB21y/JFbnPjlt37rhDl7vIv9hDVVikPIMu+To4aGjb+NNeS6sGxfG1eJG3aM9Yx8 IyhJDjjggBtvvPHmm29esmQJIgAC9TnnnGMlbqRvklddcMEFSNyXXnrpJZdcgtUFWqGQAnI3BeB9 EJAVjEkmu00g9Ix/vG843t0Z2JIG46t6wnBkcwBvfJUoWwULbQk+plEltpTJN+HV4HAVVo3EZpKC e/JIVHj6xdh2h4/f+6Pobjt5OyiM4gMz3twRDCpPjVEzab31XbQlRaqUsr23BVvGikNp0dt2BreE QRQGRmKznaaghIjXSmbk4CMtMZyFkZEWCnu7XC+tDG06J/T88mc//M3k4e/f8PhP1HyoeNXjyz51 1PpP/TG8nUNJtpEsyvGwSbAecMEh+4ajbhgYX7Ey0t4aTgUTDG4NhYHR+JyuoNfL7+O9w1IuuW59 2sk+Xin1kaB6XshDWs+u+NO7P/7W8787d/8pKzFN8jI4ogNty/lyyauRDSUDzMLo+9c/7ODYBYfV A3tiaExyf7cEr24RmQfTUu0v8JKQ8zQ+5C4qq2LfiGxdJrSi8UU2iRIHa1P7NPCiFHgzk+WgtMyO 5UgrE2bv9F75iXQuw9Y5Xd49bYkb0QoGTaXgBQsWnHLKKWRHO/TQQ5HBt9lmm5NOOknzNHEhhqP4 3nvvvfmM+HjQQQfZkHwet828QxDjq5O+Th5yYVjauch8bnrAEnpnSoA7XJJjVl2MHS5cl3zuSlLM ifPxqiGRwfH3zCB1lntz08TKc2VbkAMAcvo22VQCL+Rd95TBLjZ3fSN5i7wBog3AEA2Nw9Iq95A1 XKDUNKPU3DpmBogmikPM1KkhkyRVOSqn8wAcUEtUM88EXpzNKRgY2EwbROPNEmPrdrmvYYHWLcUz wjHJRae8Px7PUrVi8UqxoQ1nIUJVIKSIBXXwB6UlR/5y5eU8WYvxc2102Jf6Ea7DL0EwTm2JmOMo 72ZrQbfi4ufKeyU9IYd7t0tYrpv9hIhUTU7rvWAOcBL3Ga8GylXi9j5JiL3m2UHpYTSqkvTHNtA8 syhJNGGxaku4iTsgaV0pVqPqFDnmqJc6hwh8J01VkQZIEz0UWcHy4xw/fCme/U+hPWQlp7Nk5JZq HUZvq/ov3SEkNyWmfuPOKFJ8RvTXZNFrMBPydrKdUDUqnWmRepJaea18mYA7r25Tvo8Nj5Si5MtG O0TUOwk0QqUH//n3I07pLxUf2yL2ruicLedvOvv7h4U6WlGdjI1PEC+IOpQ9HHX5RAmVa9kgLmlY 0LiIkpeDIVnFspzVvdXTNYTCXmrsFosAlAE/rFKi+drzoOxGVLYkAToeyibJtRelklDYWi7BERli UaiU9eCCMx/ejPZfEItaiCAcAo69DTjzThEzgDzSlBkbw4rQ3imFu3S7rU3T8ks89Nyy0EZzSv94 +f4TTu/r622fP4cqI3M33mirr34htMHMiYnRoWRTLlzs+MtzD+5z9B5P/z705g3R/Eo4UEbidIrw 0gq6jOVGplLCw0jY295OBa/JwTJtU42r0DO7b3ZklNR0ovcjuYc4w1TQZTIdeGeCzLpCWiSxM/2Y mA7v7yhcpM4WQMk2j35vqp+lb6bEOGGCZoq5PJolcWT29iYKOeEF6vQCkROuh5qbMXbFUvIkLvOl eGjFwI1fPG7o8ee332BrIik7d33LnCMPKr1p5vB4OlFAKpDSOKp1N+mDJCkOy25kdHBG55yxbJpF jfJtdPGy9vU3DI2NX7bJHm/7wqffdNpRogrAQ98jgQoRcrHJoXwwOtKG6wtvvLSUV21Jqet3NV0J VZgwAsi1kMuTyFBMNXUuie4s5MF9lpT00Sg2CdkVJttPmVnjItJUymYKZPdFW4IiSAuQSqEynV3R PXpfhVkI9sL0SQwHAMPlJODJ4J1/FMeJkmSIgpmiuodfwbS8VDc4MMAI0aCh/G3A9Kp/ek1+3NN6 kzYGyieeeGL58uXqx42CxXqhMgtMEoUcG3drPN5lfamivBGXB9P5ifHBMexyoowT5xxKFkoYiGa9 EPSis6sYS9KZjGQ0r1PyUaFSR3XeOzQ8TMUvSXtvzFE6Nh88YrAIc5hLS8WlOJrFplLfSCKcDPWN 9j7xz/CqkWc7h7a65u/hJSPtfzsnP9izsj1WakvNzycldVApSvTNKCY0Y7TiD/QOO5foDDF9jWNs iXa1ljwamEp8QdmOokHbsAMpaheV1LY+xPraI26TUIKeUYXpYvMlYjUBNWUjFawHUyracw0ULu/B fkZfTh8o9TDQnzKzHgZjOYtAJT7B4unPdogze9fMGWJ8q0/KYs/JE1sz1NnZSiaUvn+9WHhmUaxv OPvo80+99NR+l/481FoqbtA92tZEmcqWvy1/Yo8j3vrYpcVtNxjPEaTT1JrHrICyfMpq542MF7Mf Cr2uzi6RSOxwKjWRLQIVP1rykUULCVnkyGiYKRa43RXgm8MjcDotdSZUBNORnydnSvNwgUa2DUkG PTVEoPbMkqkql2fj8IV9lam0Ary+I4cjk/Hll51rcAS3DUygix58IvLCig3DHenf3zs4ml7vFycW 3jZ3BVUQMvFWFP3CuSUcVWJYEMspsBBBi5CeleoqjYEsiauPDeXFSJOJXHrEsdt/5pM7HvDewuhA af4szyZWjldEAwQk6lrWYM3yE8dxgJRk97XYsWJJFxp9ctVraSeLNqCegz7P4Iis6aPLv06dWeYE NlHMMgV5ol3ZEYmFIwuCbgwyn+IyMIVxj4yOkF5JK5Dpdu7ZQxESZHXITVzpjYzrTYUk2ot0mh1I 9l433xg7qDXNuIHvhRdegHHvs88+Pj7CwBhJdVb4mnycZECONSOKA2Niya2f1tn2D8UAgEuaLqYB LxrHjL1UP2lpoeZDbaFgxWfPGL75/i16bwaM0VIuEyrMohK0wzXeMxyd2eZyAIW/0J/LuDSFPOqv wPfD5shbMHPmzMCWNKBbDmc2SKHBI7g04ILSOqPTpdtCfzbaVSk6YR7o+8FNd537o4OeuiM0c3KX Kl5w3+Ijjt/oqZtD280N7Jbhs7BtEeQG7eEgjKtmSdnqp7LDoyTjZvMMBEAE+WzWsVuIEEbgsubV 8lRvXOnTrl78ixu2euSi0IK2AsE6w4SfOBlaQv8eDm3dHuot3brnwXPf994dfnJkvQGK24zJUxSI ARYX0LokOocImSzHjOSsbrEMO7haltBecqpuDVbHy5odHVVBJ3BcqnLwlZJgrrnvkqre1/+0ddyB 8K1r4MMAJ6VJv6cq7OBBIg4G5tLaUesuRwyMN/vPW+mJXO9wv7hzeK7CzNByvjotQ8c3//+tWR8F x7qS1PllYDGKBjWwtORzY/98Pn3PU4P3PjF831OD1909eP+TY7c9mBotdDR3/P8NL/8N41kdHfdq jKuBqkSr7QUWN5q2qmRoLIavq6hK8JUWV0rRD9ZSlSBAiRLKTVWCsNOlqpJKWKA9wVm0sADw3R7J pPHLo7QPChMcb1vizeNDaan3jL67KZP95mU9f/7bgkfPL+ayfclSoSUxq5As4g1nYtklnZg4eYu8 7lGViLcvatNoZ5WqxAOM+ssiwYmqxFQ79M2XdcrmvgLP5s+IGqhKrGQh+tVcjkOPk6qkUKCZD7Gv RVUCNgq58ZGxTNuM9qip+xcpREK5Us+N9zxw8fkfueLCUGKiMC/Z3x7JRcLdjy+7Z7ejdn/0kqat Ngin8T1uSoHWaDGXEBdGe5VVJaYiCTOr5z/9VbSQU+OtvKoSPSZrCh1pbFQleLNNqjKbyKYgqhIO 7F5ViR7ClH6sqkRrdPiyKfhmys4sQIqupioltwXGjg7Jjs+SAR81zlgmTN21RIRyiB1opHKxRb+4 ZvGdj+z2k1NC67eSAm2gmYKbYpNBVRJFKRKNjw/0x1rbQ6OZibHhGz5wxKyXh2KtHYNt0YFSLjkR nsjmJpLxPb7x1bn7v3OkmEms3y0+25V3qxpNfRMcVSW011L31RzGqyoxmpJCvZb2WVWroiqhQ1WV 1JtZj6okh2xsVSXGM1/0/TJTPlXJyIiK/JOqkqkMIUBVMiaRE2IwcDiLeLGxplUlapwkHzchOTqj eqnaWhl34LmDlpAsXCPAOAmu8+NSxjDZjMu3LCgo0VCDMG5J8ixh7qqiBQCIO5Bx86xqrFjeqBS8 uVn4SVfUJOM2JefGxkYmUHkmMPdQcWG8JRoncIN6xyZmKl847Ecr73pi/nO/xY6RyY9kmiZmlFpK 4iFN4cBSviiaQe1R2EHEJPWWgI1xrCKxGW1eL8NqoznAiL3LVJWtPiRWt1c1nPizo+2tMk562QEY UPuEcjS+2r92+LxdEatM0JcAZArjNqsCIEmaTOlRdNyiV63vYkVj1ILLVva1z2wn/Xl4kBCnDnwc Xj378qdvuOH9F50bWq8Dg1ConUT3xfEHl//1PQe/5+k/Fd+8Ef7gZeMkZkgqAlZgVc7LN2ObHGdm GzNuXY3wAtVcgwRVBVhmheFuio57aFhaoi8y6MK5WpLHet4O4dGhrgIAqGbc3kWrL9LG4j1cXWu0 sovYp+BWwCw1iGWQkoqdMhJZaoyUwtFS7KVzfvfy1Tfv/csfhzbupsxarjNJQl0pZC3xNhjTw6GR MUqCQK2Fl5bd9rEj9z3mm6ED3hHKjUnStHmdoq/LZkJ4RpJVBm/aCKrhyVWguFV2qRozpZaaF23Q adAAFZBtWd3eEjbdNtZU0AlTyQTRLX9p3GBmmTIc88mEg2c6dSwR+GARTFaFcYtuvB7jNsmwMIRO nvYAWxm6rkGNGPeVgUb+49eak1gPRXp/TatKGAZQqgpP9yh1PlFLo4k7kc2n8aVSuZYxbNwylkqQ MwiGJyHRCSkMj/VWoneIykG45q/EPZQBUGYU2KduLfqguBR4Lh/wvFrOnaVQK1YhRHniO0w+Bwpg NkkcBF5qCWaSZPySeJpFjYcA/iS4PMcjEk8dlVgA47Ygl0Qe4qwQo9I1bRLE/nB68A7fB4w8Yopr KOlUI6q6vRKfUlv1RNCVfYSWKimoxM3XarxZxPJ25W5eGJgFHJDtPykbyMzwDrxfJFRDIjbqXUwg aEwZ22iSeMTuGaHWCD7KvaGmvhUrQzNaQrNTEjaZ6ogluiI9oY3IrTuREkWAZm9MNRGq7KUzO5W6 bymLsYNVkcp76ZBpBiUrErztmbQmz+ikZjHbEgFVzDIzyKbNZE4lG10X3NNDjA9X1WSmM6sG5Gos TQVGntaZlZ75J2BIlu4UyhETt59NYe4uhGZFQl3UtpHklM2Y0zW1Dgc12hMz0d4c6m5typV6e1Zl Np8VelNbaIe5ofltoY3bQxu2hbacHeqKh2a2NyUwfE5ZwopbpSu73OrNrPJWZXn16IqflFFw6Xbb gFToxNZTVtm8wcyKa0c0XETawu5K3AOxNfjXGErgP1mMhNtUUYKEW1fOPd6ZUgalA1cps3qZsEOv hrjt5emuTqaN94HAX0GcysuBLdfmBoFnAi/wjZ3TqbXRt2JFSMoAiusbAewuV9m3w6WpaeMOcANp yPltr6mhOwBRk7bUe5HWYFZbV4hzieeKFNLREAFQbpitnB5e0xhe28PuGHB/T+M+8ZpNERxklADo 9MbrK7kjLd04yeXHB/XVg/FRNydmd0in3dKdth27djA0Ova0JpqtIR03Ii25Sji2UHNStyPdM1Uq 5IMKMvVGrEdvfuWvqODKlVzqI4i46pFcDD0J5Z3EJVUEH1E2VHTcnOLwy1ZZQDJPmp28Ab4VWlXv qNTpbQxIXuAFWpO6X45XxqtPnjWDEy9PRJ/sUPrEy0dufnjBc1dzgCUXEpk0UhPxTCwsygWpkmTc QcvugMJ8JJaHZAx4nWcLkU4KK07uuKr+s/AoJNxRT7tqxPraKz5prx8aX9qtd7B6frJP2ZnSk7JK lFNw5XHjBlB0I6gKVGsm+gSkvfo+GCClOYNLXSnTEslFJ2Ak7ZS9y0f/dfH1r/zqon1/+9vQvA5x GJyJz1p+4uFlf93t829/4ff5BV2JPKqTiXg2Uko2ZZPlxHI6arBhibCaAsGeF3hFHX+raUCIGROf V8dt6mZJ7mxzydukiFJdBNOtjwhrziw3QZlKpj6AfRo8GihhlCeIeP7wRM74tbWnQ5Fc8tWLr3v6 mhve/6sfhbaaVcBXG62I+DMXY5TuLJTCw5nQUDbUNS+0cjjUk79iv/d++I+Xte++w9DwqnBXCtVO KwkG0KlEQqMxKqiGu/JNUV1g5lLgFQAh6ql0Uo0FtRsxLsVwBWnlhkp4/EW25S9rtrEHjjUP6Cqo fp13ZvmZvPDir84rOI1I/SAylJV9ssV6IWkApnSCGOqyXpTGeNz7Or4Cv86Lb3UErb81rioBRLUu KsUr+1MOrsRnz3Q6YdWXNvA+WK+l3I+abUASvpMrhuMfKqzJ5vLRnDS1T0VWYwAstMyhfvZeNaHl 5GkAkcQL8k9COSMx8jAw5OYEJEK6HJPTqsQmJgYrA6Q0qqggyi9lSzNDkFQ1UpQAM9uUqxoevVMP sdXtles3wqfnN8VVg+Hbn2r2adRk5UpsWoxN0rcZKhDPaPnc6JJ3j+MCEZYMeeiX4PItzV3ROLay 5af/dMUpZ6/6xk9fOfPXj/7k0oWXXjMRGqNkBoolKXUG6lBSCbvzY09pQFdX4NC8ROhvbGIxtMic /jMYIMrGEKH5V+9SGHxEWK+xhbZ6LL55UdrWZlIADiUhGZ9YfBSFgxWls6jyQs3hiXi4n+IQKOqg WKaHgaA9aGvp+/vTL/zswuVn/Cp3/mXtsRYpV4bSETP74Gi0FEGF11yKpCYokBbtLApte+FRSLyI DSQwu7rLlF+LzmUgGlXQsMybxYNKJI1nVmYN8jBJtUS1VZkvfcqwCT9Z1uu2+kUKbfVM6RACOXW9 BmtI4kaUIGtgb28vWQN9oLi7G8P3qf7g6Ead7xkibDHqkCQBx2Qw6OLFjKqHy8XblzHSLbZsuzH4 R/3FM0b//PdZL14Tws0kTfB7Id4S7EZNJ+lXexLrzaiuwFs9wZpgAGtPIHEwBRCiS0vEImy5jhgY GR5OJElWGuzFjB93Hi/mTifHsuLysfCshLcgZPrcW1+65IqeVxa/qaW7c8ngws7YK6mJTZraNqLd LaeFtpkdiAE9dbmECEyLCEf6+ptTKWwbgQDgLyQ1iE3C+sAL0mKyXBDbOEZhyY9/8/LVf9njrG/n t5mTbYtzlOlEiPZc/zr2/x676o87xLrWyzUtn9u21dknx9+3PVJ2euGi5EYbuPCdNwKx+N8QB8eC dcEAuIJcdQtpfI2PpakmEe92IsLGq9v7ItYLi8sXToFxlfsuUPlghp9oBRwVCoLPyEGjDvhd99Ka p5vIREhcnp2uUmyy4FfAAxRPKRe8C+q5rTmZcksEjC+KozKadwJqddZjC0sy0jyrbxiuzR2J62xw hPbAj2gc6UyZ7KrBV1Q8B5y2dErJNJdLwwd0K+a24DeXW0hlMrfGUnKyXI03+IG8lCibcjUf8/5t H/vNe/run7v4+ubS3W8auP2DS+/caskNkcUXFrbqCu4RM1clUjy4MaGXrgktsPCJnSq4T2PnIEuf S0vaNCNEOk1DiWllcut1m53XsfjVl+/Y6/OLZ+zbH3tv56X3+lpGFy0nb+v2K2+fNXjLds9eG3nf djSQZAbtHU6ENR3E0iExxi4YQP/Y3pyU3AkOl0yWmz4eNU2IfMVuFxzDMdMIa5D0k75eTS5aJ/jr geOEKbexNGoF40YrhBMMjVRVYvVfhhWUvcq8P1V/LgeZN25UUavhF6uJIQL6xDUvn5dqsw4ty4AG tVS9XiUevur9ZrBEX+eTUUlAKtrAgqRpqHTbAGIWTSFP7ipJVR04LkfEAoDJ84yGMahTeWUlFUbQ LAg+K4l4AkElvY8aroN6FXRJodWpl+VMLH5L0IIl8iOatEGBAFjadQGg7sxOfZg+1clPAWgMBFlE 1aXMBQBLKkGNTZ1GUuBWui1rnQ0w3Nx4550OPu+c3c/8381+dkZ2wwX3/ey8RZ/89sJ9j8t8/aLQ I0toEE91JsdUqjISnk6oMcC4XF6OEESvotcu550P4gK6xJXtBc+s2paCLmlDMlqTPiyorfyey+dc mgm5Uv3WVHey7YU3yAjMElndS1QlG220EeeOclf1O+JkpA5SGtxhPa85aHutIuoEw0EAM4J6SfNg X1/f4sWLbbFgqkGSnF+ShogimlgTccSReti13g7mpUCyyZjB4UCsfjyHsbHepo8PZlYS/uEWp4cJ kISrkmffFXdgLSMNYfM/OXP5K8VOgoImigUoOnPzn+Slos9JDuG3rNIiXJhAU2YgrRoT2UPzpV// +nzcuo/67DGhjmQm09fX3TwWC5GspGUikqRGHY4TJvpG5xvBDWOqmAhw+UUX3BzzpteZUlIWkZy6 u4pYs88bk9fk2NUeOFlc2IxScy5KcrhK8d96BAUGCmSBtqVyq4oF69gVcpPeHjlGQp/qXYJblP2y y5K6QVLGSBH1uq/HS7tAtm5DCGIRwIphrNY1SMHYOEw2lTqimYeuykTI+H0zO6UmtWT7J+wE6zIz W0Pq9pEZuMpQLkPc8MUGTleGjQsh6ZrVDOym9ri4cjMMMut7D591Z9aMi2402b9elkq9qPbO7ARy AvVwiuHmiVCcnIDkG0kXw/EZoVGyw0dyd93Z9+xT4ZcXIRj0LVnSXAr1Dg3m57RvsPMOWx79pdDc GaHOGKUWMLBAipoMx4RW1Z5YS2ai6DdTUKJE85Sy0VMehP4KRDlgjRAFgJRCbsDSyjOrBd/rcAyL Okn/Q0JHKpZ4ZVRfsWDiSKIxaj4wXwDQ0kLyCQTNqTNVQbXxNoBxS7CR0VyLhUYMp96C3WI8k5sy sQCJvQnfygqwEMbo2KhqzatTCTXm5FZV4sq4ZcUWCrfffjvptt/2trftsssuf/zjHwcGBoip+drX vgbrt56VlCujttmXv/zlO+64A00cmV01EuTpp5+Gce+7775ix7fOFqSMSWewzZEyJvBAAxrI9dWi KbaD9PqUqMCKEk9J8ZFye+8se1Z6bmQUX4bm9pa6RaNlriRxFAnG0K9Re9RHMX5ln1mT6YGh5tYW 8en2DcxY2DNf+lHohvuTr96AH3deAuyKnc0dWvJFnEl8BMlgy4eHUJoqpR1t3vS2fmAq67hgfA1j WgJ4cn1XnRyZ2bE0Y4+1klmlwgPqbKFsdJlsLjUVA1OGb+A080N+xFFioNg+G82seSU0QABO+4zO YAkEV43+QRArvre0NsuoxgXCkODSObLFshk0lGxkZvNjaWx3QBswsyb5J7WNUl0dtZOglmfKUByR k/2D4rnNFEyCOhVcbU+yrUIhO5Y2FXAmG9Se2aZwdlAQW06BUn9m+aUwyrjCsRap6qKCjk6xSXVl 8tixX7Btw9Se6SPmJLRVZ2jJ0MQlt0xQNSnWVMym4/NnR770wRBJ1aQiiOAKlp0ZGkl1thuRqw6f MUsGGkDJLvVPSBlkVlADrgRiSbvYAmIbEwEgUwooV6D6g2Cgnqyn3izEdg0MUdwKu3ejmTULNi8B ODnGVQayatmW32UGMdY/mGxvM6tbidC/Yss3DX9ja060tto2svwzGc1V4mIn8CJtio67MY+3vyI7 L1y4EOviX//6V5jyPffcA+PefvvtvdZC+iX9CrpzCuVQtOxf//qXRs0AIh86Ozv5bAzcRsI2BmI+ Gbc5U7W04T+xzhupu/KgebrOZXz+tbZppb23c89TFCKjpa602v+0E71qmbP9IFRSEIt13gKgYFRs 4sl8JDlAfK28Nx5LtIk0QsQa3mQGO7bxFOBldyd3Wbnbylt9Buva+LFDqwUPISAaTlIbV1OfNbkP pzi2TBl+ZWZV4BfENp5Z8zBhiBQnLHuNNZpVwT8+nFKxSLut17lQlTog1G9THpfxUqj05kdmFTAa A6lMocY/Dzwys8QTmXh3D6hTn7LvpcCZyePofWHtmTX8b3Js9WeWNibKg9JJekQpLzyZGXgu3TBD RAapKDq7LTQzwck0tEl35NRD49/9ePNJBye/9znh2lyIwjqz/DH10iq03WjJiAuWoZTyKmg4s8bN i8jhID5QJr6GM2vaWOHGSPBTKNZDGWXyMCMiXbGErVVoptZMVShKomyM61plZn3EoN1Kawmwik0W UBRiM6FD8qNrrvIaHNpV4lbmC6emgvtzzz2HOzblbB5++OF58+Ztsskmxx9/vHomMh50L4cffjgi OXlcSeJ6xhlnwMp5lvuYYsnHjeSOYTQVa5YjojliSD5usxTrbSH8BAnSD8fq5iR1tlokllf3Oi7d 7SY/h6UoFmHBuPKYQEfmyRuTqojjPjADMN1qBLMeGtSapG7j5SUq6gWcqEWzp3d43NSb17dLXaRy fUTzOwZUtHXewajzabm7aFNyRfGB8y7peeSxj5z/C8LSSsMrw+t1DaYHgam1pSOzqq+pvRWVgxUm Gb46UwqmjLfv5LHPiE729M0XSedtCuTZNzL+KYcND55pBmY0Eq+8uj0PKsBgz3Yl3Qpkpj8v2itf RcFjXD8FVBPN3TgJDGOhJcYP2mL9x/hOSeXy6GpMbjg/IepCXXj61ztT/CQKOjLtmYQqkKjKCupR zhgVgXZmdaK9uJoys+I3bxpXJhq6sqjgg3LGejIyv7JeKJ3V2tFBH9mxMVMFcUoQgG9mAd5DV6qa qwBbClNES+RmM0Fy2zAH71h8M5XP5fSNOvYiZ/elBcoHAABEUElEQVSmCdGkcXY3+jQpoKHaYvrB m95k4EYXZP5WSiTqr7wnGc4lo0anIxOrS7KBfpV5Z5GqWwteCdA2kfNlQpwclAHfSEOifDCXzqzo QTxiLDdBDoYQju+8l5mdPWs2OjZFCLOmtgR76eN2ZoVJggdbT1MUg4Z8K5BABEIZFX2sb5qEuqfK 1BpPr6B60a4A6Lyo47nSGzB73h4eHR0R90wyR6JCmc61OqoSqBBVNcz60Ucf3WGHHY455hjeiGR9 4IEHUtPdli576KGHfvKTn3z729+mzhm8mxrwsAZKKJCrhFk85JBDxF6Cggz5wuAin5VsBpx8656Q 7NwUChlOqe1tUt01L2XlVNWrioXySVB7aQrnMhmJcW9mrxN5CkY+eVKrJBMAEjj76OCQ0FZ7m6JY J1uYuF0VLFEmyRQcwDKGd5esmAq4cl8YlWhayzdhPJyGRkabqfiHamxqriLqUcZW5Z/81W9bfvab zbfZllDrJ2ePzzj+Exu8fccCuoUwCajy8fZWLzaUaGSFkSA5nUU202g3M3ZgM8JF5QETrCMkK1VC oBgTIe0di+yRHlqBy5NSVfJU47VmkDXlSGtwNbkeJoooCjh7ysHXg/bKLBhpHCHO/JQbywAqsDWY Wd1WSfdMavzWzg6WgmT/MHPpndDKZ1hOE0dacqWaepdSIlZmrbJxAbpWK2fIiJp9Pb3tHR1Sh9rM LC/SxCDe9iIWQYSZHOc+yffv0XWIBoMMjpNkJqwa0mBcybY2k/NG1u0kcozh1GKPrvp7+9AWtpjy CKow9Lb3sgMpVpQtiEqhUqbazKyUTi5PtBEIlBnBDgVUk8vbR9VeJkA+dKiFYYMuWWtCliWdDLJR 0rM4whtTIz/kJvK5bL6lOcUI5VBlCK78T0SIMHnMyQthOFgxn86JWqkBx6mQDQsWHCVEWWRCtzwz 6125RkgpwQoQynTEKqSUR1fhACI/AV4o3N/XN7O7W1yxzNIAq2JdL6st5Kbg2ZyjsiOSs0iqlU41 hMhMGUOSuShoGSVXLKVaFADfjuhnCEYjT5oC8dbXZTh1By0vWF2GWN0pncqaNTKAmq5E6Yq1g2Cf SrnnBrj0/jRtxs3D7HinnXYaRSOpJPmmN70JbTXqbNTWaL0p+u5l3BdeeOEVV1xx2WWXPfDAA3zm J7bff//730i473znO30gUhlA4kscfF1hSLnh0USnk69rZniEyaByeSBGUNixalpndga2FHfjTK6l y8nherinD5Wlniurr6GLb3/1nr/19g0sGulLz07tefSnt3rP7oEA0CA3ONyMlt/hkEU6Kton2hwK Hkrt4/Em8roEXdgGx0cz8RlOGEgPouVvFU4adEHH4DbplgxajAdtTt0yBbAMiqoEvR/LwQhwsmgD W6KKHR0YbJ/llJF8PJ1BGnTKx400M5qNdzrlZB/tH2gmWYpDgXAK1HKmEMtY0DVcGINdd8SCMcAy zGBo6ZJjROCFhhexIuqQFh82Lapzh245zw71DWARIVgmEABogD5dAhSxc+RzhdYZTuPKDI5gFfNt wzWBgcUja1O12ftrMZtLI1d5yqEEDkQbWMbt6g7IHgLj3myzzVCVvP3tbyfJH/z6uuuu48zy1a9+ VbNHciECkBuTQpR83m677Whp3bzQk3BVw6fh3I6X1VsFtm9wiPM969stg3p2hVUKiUw5yHo6LpY6 Pvi2N59z0h7Xn33ofVce+dsLtnrXO4LeK7/zbhPe7giDikzB1ziWQcIEghuaKXardijQyvsde/XL LI1gcRwWIqaju7PbwLUVyMeXw/EJtFA+zUyDB90p1vHt4CmPEcwtQZDovwpO8RR68nOjLKR8o0x3 uxwZgaqIpoMuJyJ0alQZCMcBRwyYRVDVd+27bmgyrVx13HpG02xY0KLm9jSLU05AXg2y8kHVD1gV D3cee+wxVNv77befJqW0RnkOU4CRbEUwbHz2os8iUqTIZebY1+gKh4f7B3EqQVmhp3+fA5wOh4EA ydigpFik/IqypJp8XFCvXiUUu2vHQFyXJyt75Qw1MjCI8qFmRTRhKEYjY86+JQpDDeTTM2fMke+S TrNWTeTK6Wu0f6itq6PBBmbWlDlQj+FVUgqUImUGs+LbJFXDjd6gwSUTP5ROdHc2KCxr9FeCrtG+ ARwqJG4wiH1zRuagmhJd8GQikZpgwF+G+waYAnRcNUE1eBJlF5bsAaQtJNNUQg/d9dqbA/UYZyNR gjVcvsLdiqVhYmI7O0Sp0pgGm5r6V65KJFOpNnEv00VR74nxfB4Y2rtnNkKsziyeEnhMEZIaVFhH tEh4X3CcB1cGWNIwSFpdQ6NljYSqpKiylhuLZ5tSlDOdCmVZFaBaE4MdXNxw2cL9w0XezJMEnPcL DTRaMqrMpExr24zOOgtQ+L+ChiZnoK+/Y0YXq0wXpjJyL24V3eAK94/mNjTsU9SDNWYhHEJhiF9q S2ebMofGkzvU298KBowGtd6lfjQ4C+GugyfYJF5xNRkey00UyFo6Xfvk6qhKXMZTcwxgASXJU089 hRPMXnvtRT8YjtLDI6ITLhv9NJa//qohl82EFLGlkYgwkn+yrtQj7rY4o5J6QRJfGFdf3oMXkXBl BVCoRPGYSqaQNs3LiYEp67hVze0dS3mz0fQ3sLgGMpcxU0oyY2NvQdMqCbinTi/ZW6nm22SibybQ mVLgjvT2pNIkyI2VBt9BDW0YsKwpcUJvpoYCScY1mAKLWIONizHgZ62TZTw7kBAbxdmBLh24WLpR yU018vgmVLrEOGmymetcmJUz2YqvuAibDUm8dNjUpxhmTSCHb5qNr6scuoAEU3KD9U2DLMmoixOJ GGaGsl3RByG6S7oTL6ZEM1Qn2cANlMavXQxu9rwC1GpqsxIGiKoOcvP2L3Y7eB8zm8vjr1E9s97R yX6Ayxe+uiTaNQlpsawCnA9g2bkNBmifjMTqHadEMYrAJF6Oko1L9LDGsaXBRqMzS7eiKGBe0PKQ jhubJF7MxtWelFBAQ80OylEwsEi2FJe0Ok0YJsX72CwBfsHeLWSEK7QsCwQ1dkE5eCEXWWjFsdAz MMUtsKqEIRISWUDq0yGgprE0RsL4ahgCkRdZ7imgEqFkvN3x0MAjXuoCplJoOM1qEzx4wzC4I/VO K7ZruoqhNq0fHqCikinlLCtcrY5eDgAivKHN9C+JhmS/U6dzP/fWx9WKq80SEcl2V+Y+ofDwyAhq d1zEqDrdeIfw/bo6jHtaL/A1hnSef/75RYsWIXH7fnqDcpVkVw5EyVVCdt2gyz1XCVZyoFVHhcBr cHCQsKbGUonhViGpHIrIj6dn0AU1ZJf1Nc+b4SLsuOcqYVzwa/wfgt4vRj/QNWPGjMCWNOCAZXMi N26fxY97LN3hpjjGZKLp9hv3Ca4wpyPvcuwJhBZQWa5O2VomJvCBoWB0YJ80GOrpp764S64S8D86 MoKa0anb1ylXifddqDRJltLZEUzbcKSBFT1dc+cESaXS/Vh6DM2SSxIYuHLWrZinxmC3d7Trdtj4 6uvvl6wmDoVmxI87n3NMmIObBpMVSITApkWQfYtLOAn1W9zSIXgHOG0ddxB+An5nC2IAykrWzGWE uGmprV5/uBocjfVlulOrb6jL62kmIVkuTafTRsSbKkmwXgdviNK2ykuvAfiBWJ3ybJCWZjp4mpwy x6dcFna5q9cbTu3WnCicNNc0dlQxA2ntkOCaSHFegkasdgVVXuXYcznwKHjGTDJmx07LTsPBnWqL WpP7Gldx5Atf+AIiZGDJR1cQ67fDjIkNc8stt9RDhF58VgdMVZ0LB6l/qW4d4T2wpZx9CjgvibeN HIA04bOseDM78rd8ijHHXinvhKNlg26VpNSRUUP5G4NKY0QYPawFtkSCkLOkCe4yOgaFdfKbMUoW ObHyVyqbRZs4sHvb1HyFGh4C0aWgqtHCTkrNDpUR8JM68NrLhw3vzHo1KnZwvs5FeSF+wSF86c3a CcCtTaumfrK+y7Iq7jOzWnslcGYdcUWfatGpRwNqtCiP1OBLE2fLmBoSjda4QjINJC06t07EgaSl JcYDKZY2NvK53rQK99HfJFlFERuD4UiTk1Vz2kyI/6Rfdj2A6UoLrShpKTD1ZhYUadVN0dvVWYl6 X7RVJgmfVevVAwDtBz+hpZSI3HIqoCkD8n4BNi1UWw1kdf/VpKUrTn3hHSU2y1Zpz7NkWnU1Tr5G xg30+HQjcb/jHe9gn2B4HHgVaCFr43fZYAw6l0oBlsLqgQSXa8oVIjloC2ubKL9Ir4EdAMKbMBpU IQpyUJHMxFx2aut2aDJkaYSOxqoEpnxTIKEekZGDAltpVtaFGSzgJKTZN9TZFt0bTstULDNp2VDq hScSEfSSDXbssrdypTxFY8QqSllgbN5AoiOthwq60m1Gq1Ip2N7+7aqzM+vFFVOjASAq2DAEw7RF Hapf8QEvEpBWn9p0l9XtkAf57IO2HCVgihwys4E1oBmLlsLSravxQjJcS+YUJCgZ2PZCdRLSIn/L o6PGg0m3L07ExnrGRopa2Ts67U3nS1o2PNFbQccbLdVgYSqcNGCAtkxBvfa8HWZEz5orVRnQ1NGV MMwoBtT0Z3OVlNXlphi3HZ1uq7q6tavGq4a3S5RKpVSj+kFYaOlB0gpR4UFyY0jpV/RaKk7VvHQP UDZHgwYkrROHvYLwJtTorDINibRSsowOq5VnaCrtKYWrgaT6aKWTpRDS3juzfIX7qUzTALCa41rT Om6QSDwOOu6DDz7YB9AbpOPO9QxEcLxvDdZxoy8DlS6pkDWLrmNCcBcdt6LCPR02jceWrEqu3+1y BnfXcWPEY5m5ZCR/o3TcKPxGxzrddNwc3ZiCwL2TZYM6HhnWRcGqwb2+pMk1Vw5LEYJxtXOs6k20 pPjXgL3qTyAWGBxJCwBgWy6+yejuoW0X8wkMDtp2oQEQ27981cz15gQOSsh1OonOWTIu5hM4OOPS so2BMEAtDMoFV+j480SBOTiS81JAZbJc5OWaqxts6zYZCL+vwZrWcTPZYNnR9lJvMHTiPk4MFy7c jQ41/N2xZ/eWKhW6dBsokk92UiJ1GSVvnfRj7gcxSafgDcqvDzQjcpcRHIfP2zgIUS/ZBVfSuKp0 XM0HpwWqO668cmggwMmk1IoNbEYDunVsqb254FYXnQt30w7dW5LaJtDF02XU3jYA4L64Gh+kvN26 9yluR24RMYqrBvK+F4CaRw09hUwXRd72rgE4r+UdPKtnFj1frPblsr/Zzs3Bygk17kicFgA6apfB 6unepSUcGweQ193oCgASaO4GrROc023khKfJTl1Add84pwWsy6tth/m85IFx7P91L6WtqhJfEg9H YBo0E8QaP/3X3pWPwbl3OK3t03HKHJvputZs1S4AA2rNmXV8vN4r1pCOG/J95plnOLyTElYVQ5ag deMKFDeszki30EZiFwjFX3YoE0/ECklyu5hEqTETDWSEVVaSdapUDaN2yF+ovHqLtm1UaVXdoKaG SzWwNafHC7xuaTTW/Hw8gDpQclSJucSofXFab4qi0JUtmszC2UKoPSnFfSq7Ur2NRxFr1XCWAqrb ezHQQPZUPazm3LC9Vbe3kohiQI2utj1OxOIUbL4zRKPelURjglhaarHg+sKI6jotYhtLyqpBVjUr L/JBoiAptBZXvnXiIzMlgJo0oA+SudGes/DexcPP5JwTdS0XXJwqGHa5W9jUyMG4UIB4cVVvZhWx PuqyVOodgndm6x1AFUs8pd1OzpTX4RKyJG0L/0x0Ff7oogvHkGhmUm6J63c5vYz2oMBbxDaeKX5V FbZdXI2Py3ZmrXHIN3EWdfWW4ZQ1aBaaZIvFgqXu+ZUzDaptTDKyV01NE6/56ewsKHfyoo5HlFR0 45R4gkoDfoIT8jXQquEblC7nydJl1T+/7nfsMFQOUrwr4eq79GvjSxsrvQa2RP9BosbmYhOZIiWZ jLxsMrmm93ELgCw8Y9CoeVlQHQHQiXFsbNU1JuyGB8ugKtjiBmM+YN8RvY5JoGYROC1oq+FRzm6v BgDbzdXXpuYjiq4asJmSrHrJB5MsVNgBLFtzy9efWsWnSlu2Yb23S/8e0lI9QANcefus10zb6MxW tym7dU6OTsQRSTcogScmQsROW6WNLmYdl7T0XPUw4UVsY+ryTiuf6zVW2lN0NehQRmzSmWnWMGlZ wUEZrR6UaD8WVPu1/twaenBY3dqnncoyhqf266UNbdkYUZrM2RChaWm+6j9J5wYLNqmW7UtoUxaz ynVazO7luSzf1ynwzWyZ+J1P5DW58RqSuBknLiw9PT0f+MAHfHC8QcbJ0uAYZS2aHLLbsHmCSpfg i9exWLAXCZpY1cWGJk/1j4ZmECkTfExzRyzjYit1AQDxYRrFgkdGMPcFnqUYE/HuxEanZnS6SAyO 5V/hicg1LBuXcWlLF6dYEOVesTo3MkZRG4TTwHHRLYh1IUK6AgBHxNInXMbFLIEaExhczLOIFsM9 /Y5ptt4IxEKEQCvxqA6IdaQWsFrIkCExn3DMdJZOgysrHDSYX9UP+0iLSB+yyNSoshJEKMymStxr iHGzimDcK1asIB+3OjjbA5oqgBqvGRVMeAQsKG0FoIxl0DNIxFqslcYiseKoJX6oJqeiONt58mGq O6CXuKs1aAqtdTXzolcbe+FRaOGbepjyzYXKa/YmD2rtN120fBWhW5PEqmRRTi6hJ89Srm+4eXYH mh3bg/eM5n0XuKK3asT6DuMAE+gyZbsFDzT29ekbu8UeiGVp+Ri3PU+KFkgm1QwrV8B1DhcgGTtZ YRte8AIvYn2UYOmKbtUdsIF5Sg/U9GB9+X0z65s+PSxaIvSDqZJ4xQTB5/5VvUTek6JSKYRf1NGz +oIAQCx5q32zU92SBkpa1TuiHbt9St0BXRi3jVHQZ2tQNaoQs2pkukYzibaULZxm3DorSpPKu3Ug XsQ2XrNgwCK25pqydEVLxsV+3KBDi8aay9C/BpkUfAEzWVRAUbJpCmmaXAKeKHlvahrei1cJk2VP KvXWIH2IWCb8jfBdQjAk2w30jU/JRC6DOiAclzoz7teaZtzgmlwl7H577LEHnzUiwAuunmXqDQC8 8JRtwNdGchzdZArFsVy8WVIUwLLH4dUm3zc6bi7wSHiO17qiNGGxr0dXLzAaR1ATPJ6y82eJ3jc6 HzvwAc/QRLlmeLFsaegQJRagrOPmXBqRHBn6z6jSWhOc3WyfPv2awqk3dSDVrM2OtBr4QBqqfp0X V76Zojcf39QqDKq7lyM3ekUUpgQ+VPJTFFspOlEXisZv5zHfTPlWVPVMeenK99ZqMvO93Q8lrs2k 2qgAD9q1uohkzEEdgdu7JrGpj2IfrmrOrA1pqZ5Z79inO7Mql1jQalA1iUFYNcLOZAT8J55Ilk2b XCXesQXOlA8NXituzTXlmynfzPrWVOOZ8s2s2F2yBVOoAjMOtBjBr1sqSWhxNyNOeZPY2J1e92Ou BuudYbIOi5F4U2gCLRvWKgIIl726ZEZLkoTr4c7uafnnrA7j5hl7OmBvZPB6CAWheirXCwxynwbq sqO0q6qS3t5eKp/5Jsz9RD+tU2q+ZxA/7ohI3AHXtHxdEYtcvGJ5JbsUvuHVEnc1NOCKNcMGHgSp /J5b3hefM8MlqZi7HzdTAG5dAJiWqgR3YwjG5Tw7wSl1LBPv7nTBgPvhFwBgLi6qkmm5G7urSoZ7 SZydbHbINc8iAgYXN2olLakp4+BoSJ+6bAMR664qYVGP9LqqSt4IxCLDQrGOpOVOLVDgRCYf7+4I xNW0VjfHPmQoaupO6bZA7s5srLWds8OEyVfleFnG7eoOyAPkVTnzzDMpYXPiiSe+8MIL1L459thj v/vd76JwsZQBMZFM6lOf+tTLL7/8gx/84Ic//KHN/spPLjrEBgNocB6pfsqFtdmnGpymvT1PCwAe dG/vwt8FEqRvEcydUjrwdncApgWtI5G5NxM4nVw3y126jEuH7ziz0wPVubXYkd0au4xouqT4RvQ5 SSevzQ25GivTghYh13XJOC9DA4ArFbq/vfbKorRCU9M9V16y6olHKZvoXmbA4s2VcesDZBr5xS9+ AQv+wx/+cPfdd8+aNYuKNhQO9jrxIJTddNNNFDOjDSVyVMuJ1APXrinTwfRdZCLe7mhoUlBjyZaI Q/kbWjpmsKMlQ3ARXhQAdNaOXGMa3YZD0VSKOAEXbgAAjsYuBsXUNFZB6huZymlhwEXclm6TibiD VKgwONrlGA7DdwRgWkTojgGipVxSAypiHVeBkpbLuBQDjtBChI7UYkT4lKMf97QQ6wgAYwdXjovL kVoMESY5nbmsLNpw7Hbk3YDaUk3bmD5a2/58ww0Xn3fu/Zecn+1Z5bioLXjTME4iO1O1/fvf/z5z fNRRR1EK533vex9H7LPOOuu+++7T0mX8xGfE8AULFuhXCphRbRInbmRwji0weg1Ehr8zAWB/5cqV cA3w69UTsft5v6o6T7MZcFACa5o/iEutOlw8oqqJ4eGhJHmVMwWMtm1dnWJG6GwfHh3J5HLdc2bx N4s5dHyCfL4av85pTu14wKCZbujHp3HTl3JGpjEffETj0zaqCoxhcvKlMWD7eKLvcX2pJk7hMyET pN6XAOR0pjkW62zvoFAT5SYWrD+fg5X01tqMFwgI11hetf+oawoI5+KzWMb6+7nD5uotc1FNl7Sn K6AlrpXPajr2NaMfdZTkVyn0bC51Pa4p+ygmKWvX3d3NoFBZ8CE9lh4cHsQ5CtVBLpvpaOugWjvl Jro6Ook2nsgX2tra0/lsz9jwrDmzEVQ54amOHnQxTejZAA98vvrqq9DPzJkzNZjYp2FXAxePSJ5S Y8ZUZwk+09IXcacu4dyESHTeG+sfaAyieAVvp6VmGtIkNmoYLObymgxa8qOGwyuWL2eO6HZVz6qO 9g6KRhJPMEQVgpYWcLLxxhszRgBjUNAVQHqpjinw0ZXOAn9BBS8lOtwX2eGjKxrTkolgZvlJqcI7 s3oo0SBAflUXFGZKC1qpIpjPDJYXLX916Zu22HLZsmWMCC8DkMYsqCsh4wWTY/kcn0kGQFea7wH8 0CH96Bbi06H79MJ0BcHwLjtZ3lWjdiDeSId0q14lNFDq1fuTTM0EyNAPN/Fk468mWNZlorFmPAjy N9xwQz4vX7ZsRqK1lC+AcerMkfU+0doymssyR7EkPvgIxxHJ0xIqMQqGxnzxE72pgZQZ9ALAHQ3P UY2xLKhINBFFVUKl5lKkRMKkIhjPZ8auv+aahS++uO322xxx/Imb7b4HxTQCtw1eOm2vEhC9ZMkS IP7zn/8M5aEtOfTQQ5mVH/3oR3/6059szUmqCV9yySVHH300RSYpHHzeeefBsnnZSy+9xLMUM7PZ 3ehQjUWa2Mg3kb6jky5RWorbv/H0Ur7PpRs13YIjjWJINSdWPP8KdVKouMhdcaSME9whie3hNq1t bVjDSG8mvDGdlvTKM2bQuSbiURncB4zNWaOsSi8vofjWA1+VF6tFxbdglJq9j2tZTnX5JNMNoQDJ RDNR+/KWCXz/TclR3CQy2RWvLJq92YYcXgh2VA829Tfis3qn6LsUq4qfQGpQ7wuGrIzMJ82pnYee dZWCLjiRXYS6HnyvUB2Fjp3H7Sriwf6BfuQ1Ik4y6YxkyiZBPt5do2ncATvndAM4jkBwMfoHe6wQ HYjq1hkpd/jMBOlu5Hs1jQFS51F9D6AF/vKVm/ykxKPQ0ljZgQ1fBlRvA9+gtL3uyip5ACHcAYQo Nba1tpH8e2R4hLGT1Aaza8+KlVQKXn/+fLqiwareXiZXE62wInRQMEp+opo2Y9H8aw3oSo3YOl86 BC+QXrpSaCFC3YpUTvKiS2Uj5d1KqDTTJclfWqrfp2SOJqNTS4oMTHik85nJ6Fm+YpMtNhc7FtwT d8NYPJFK5MdBuMgbdMhAeLViXoGsSSQ+DPNeof9aafOUzHSDtJxXKZ+bGuLknVnGS0tdHdqncg/+ wruYPt2cmDs+Q5bpoeHs4Ai5Stpmz6RxJpdta29PtaZGKHZMJfHWFvJnK7Wo6UjpRL3IFTDfRCj+ VSZrSbUYu22JhHF4HbH4Y5Gm3pWrrr/wl3O7Z+/3/n06tt2+efZccsgFLtXVYdxg5+STT0aUxsxI VUnkBfg1ZMfIv/Od71jGTYHg888//7e//e0f//jHG2+8kc/KbZG7IdZ3vetdPgEQzHJBzT5e6SNK Jb7ly5erLG+vakIXWok0DS9cnuxsi3a0lp1FzHrQPvURJSnmmy2Uv9Co7cq3Z+iDXEwzoM6ePbvx HqONEQyRdmt6YvlgVqOrLlqByryvDGRlnHoTd7LBl5Z2bLw+Nc5VHWcXhm8ZAwCyBuNiT6oejheB tET00CNtNc59LWGpiEWbbrqpj1KrCU7Rpada/VXAMGVxFB4ayAfZ1sLpgeHcwPCMTRdIomdvUjpF iLoxmIsPQGuTTNUbGi2VLfIXebPezNqewRUzVU2EvnHRnnUIBiBCnSwLmH71QstJoX/ZSkTsjpld kn2hcjiwT+mzSkt06zt0WkK1MFgOiPzEtPrCLH3tFb2cD1QHEkgDyObwIN/OocMpz5SBg8mivNSq V5fN22gDQ5CVtVR2tZ2yxOAyIJZumYJqvwsfscEWoC47WQ1mVm3pANNgzXpxxTL0nrR806RfkZiG lq+iWvHcrTeTGFFTo87Opo8Ilbbps8E2r7MGBsQ62tICMRgzTmWjJQdoJPrCzTfHE83r77a7paXq deS7szqMG3BRZ6vIicaDLv7617+yLCFiigirCMZNKABhfM8993zuuecgcWLcdRtH381C2nbbbb0n JgXLSxmNQad/SwE8pTseHcJHGLzKFBJOQi7moZFoczxSqQwE4pAOJByAw1AzDmeSQMC7hBpTtoWz ejnVA9gLauB8+DCgsqFKmvTDF8DjK2PP9A9RtVpiuozxgPuMnWZg2CqOpgutO/51GVcvwpoD9HUr AzHBgSoR6xlLD/tU8qR+fFyKeZZLmyqLlBVlTiF2iqdFLbp63+iZ1YMI71JJsKzv4jNrYcXKRDLZ 2t7GkoX8wIA6b/BBs3qp/KjYs9whkFrcSWtaM+vFFQ/qcU2pS9WSeqKV/PYI8gkR+ZU48XRU4uSO jms1Ftd0Z9ZlWhVCL7nqoLhUtQj7UrmYCcqNjhWQuGeabZ55NMwEgRkh3/IZy7umhdh6oHJehpmL V4mzpdcy7ukVUnjTm9601VZbYaJU1R5fN9lkEzZJOx5A5CSCMA6BIhRssMEGKppxH3EGBVYgUTZu YFEA4pBSn332WaR+pSpAQkvzyCOPzJs7N4naIdEMsy73hlfi4NDV11zDfjM8NvLHm/+0fOnS9ddb z0WNsNoAOxJWdf+A/dIrr/zp5j+1trSuN2/e8MDAo/f/rXfpsk0XbISfKZoEuBHj5dzD4QYMgIc5 c+YsXrwYFRanB2ansVJ7tUdk+ctq9ADBAdujjz76/IsvtHV0sLD/dNOfRoeGN9xgAcpDSVkNIzCn DZbKPffeS2lppAFVlN9yyy1qPn1D58t9UN6ZBSTcqCA8JqJ7ZveyV5f+9sorW5Op7tmzZC20tYmU wHE+n7/j1tseevChDTfaUPWknEeRRhHc1ltvPeUsPgm0ATyrTVqOY9TFhVyPZMaygrpYVn+++ZZk jAP9HN4u4RGGJ/YtX/H3Rx574N77WOxogbhz/fXXo/Zh4bsPxxGq1WvmmyzUtszXvffeC8vmeHH5 5ZdDinAw2AcxeIRKKddumig++LeHHnnk4bnrr8e+++KLL915xx1qslo9MGo+JQmInHOQaQ8q0LD2 p8e4dftViUllPdU6ecHS+8qsvT/xymo912pjQSUClOkoT1jYnJ5QTVx11VWco4n0ef/7P2ClLQQ2 Ci3/+Kc/++GPf/Q///M/OC/efedd6N9Xrlq18847OwqPqw3ndB9knTAruO4sfXXp73//+y223PKu u+667vobHn7sUZSNW2+3bTKRVCUvg73iiitAwvrrr7/RRhudc845Tz/9NIsNZsfmGqjKmC5gr7E9 50q8jJipu+++q7enh9VBYY0zzjzjyCOOgq+pRKPq5nvuvufqa67mfMaEYjv62te+RulInJQ233xz zrxr23wxEaeeeioQQnULX3kFMe3vTz5x3Q3XH/q5z7HAkLJ1IaDyZjc666yzN918s+233/7+++8H FTjUMmX77ruvz8b4GlH92h9nnaL5VOsUghEqYHjx2WedtfGmm+z4lrcwTWpphPYWLlx4+1/+8uLL L1126aU77rQTelFa/uUvf5k3bx777lpIhPjC3XbbbYANkG95y1v+9re/feUrXzn88MNFLDAnQmCG Vq+//ro77r6rp7f39ttvy2dzt91+22OPPsqDECHL7T9IhJZxT88d8LXTxOvVA4sBKYzMJ2efffb+ ++/PBLB4qNLwmc985u9//zuqJPgai5+ZoALpnffcjZv7BkY5/vBDDx1x+OE0Q6ZzP5y+XmAH9gPd wIVPO/X/Lrrwwve85z2XXnrp3ffee+ZPf/zlE4575pWXOJbiHa86PhYGKwetFFsXRSoQ4r761a9i QsCrx2ddDHzpGmgAbwK2iy+++KrfXHXXHXdtu8023/72t6WivNH5MGVIoCwYhv+H66/70pe+xNaF UQTx7cADDzzyyCM52OHPsJZI3F50Ma4jjjjif//3f4kse+TRR/c74MNf/8Y30saOCk9nZ4XMADvV 2nr817/2gX0/yMrnccYF0R522GFsSGsA+dN9BeuChcNqYhYIdb799ts/+9nPHvzxQ1DI6lH9lFNO USPknPXmHfLJT5z7q1/utMvbbvnzLbyIQRHeIck03LKeThe219IemWaHHXaAY+AIx6oB/u9973so dXGSQX8AvV133XV8YO4+euCBH/nIR9AozOqexb7Vu6rnyiuvxLCHUKXG3v/49d/KuEEc07DLLrug H+Dgc9xxx7EGYGfgHUGGXyE4DqF8QAa/6KKLOJaifOfoB+qRJtTl6D+O/WoAICYObqiwOUwAKrwY dtazahXCJt7xLIZPfOIT3GHZfOhDH7r22msJcWKLgqmBDZRR8BE1ta9tF1OzxRZbIGmeccYZ++2/ H6dUpDaWhDrwIFnvuOOOqktVpzS4A4NiLCww2lA7SXOBrYXjQjfF9sl5AicrNh4WNuKbOmXuvffe /GpPpcgW6sxAAwgVynQp+LLmhwwRAhhVBjnGoVj44he/CAxqdGEKAP7zn/+8OqLMnTsXRQrri7Gw xeIuDAUieXCSWAulBwDmMIq+7ic/+cmuu+6qZYwAWE2yqHc4gqvWl+lDJMcpDp9aNdojD0Gu6syz Nlz/xYwb5qtxm8jd8Oj58+fjEo7T4dZbb60+QGpA4MMnP/lJ5omVz09spGywiKgo4t0tDGtsqtS6 i7M8khrHAt6rvjQIpHzVcxw3gRySQv/LSLH3Mka0pSwbWAPC6X/wKFcPUYDNEDhKs+AR5WABbEsM B9U8ZwWYuOZXAnJcVlgkKFXf+973Ip/yK1yb9nDAarP2GpuXBuNCLGV/3WuvvZgIXAhY8NAhMKs7 mqoHGRqiA7/C0eBxaEsffPBBULG2KUl0mMDMGvnVr34FX+Y8ASOGJtlymDJIUfkaFAjVsdxggkwW XBtODe+DApnoffbZZy0cGgjn9IDszNqBD2hMALodqIvZse43oq+75x5UWAcddBBMgwbqFYNIjp5k LdH/TE/H/R9fJ14AQDQLBubF2mYmPv3pT8PEcWVBY8WCZ3rYSDGHwhF22mkn9lLUW5zBIThmBWmO vRdt4xtt55kuxlgMBCsxEABjAXzwgx/cbrvtrr76am7ic6lqfcBm08Ig9s1vfhPxAU4HT2ffQvQG Dxw+1sINiTUDO4Zbsf45kDIjHLdZ2+xP6hXOpDBHjBonJVqiPOHMxPpn4JyTOOHinrQWqkogQo7e CGVMBzwLBsfcMYloh9/61rfCxFn5TBC2B9JFcBaEIWJfIWkEqGB+P/7xjyNMrJ0bEmTGOmIRKY/G sM8wsbigoyOqjhMSY2cdITxB5Jx3aU8b+Dg3ie2A/akH2nSXwBvXHiK88847UVXDfDmmQ2kcKZB4 0ONzbgBgJpFRwKO5yRiRhIg74SDFzsSDbMwHHHDAf1YqsjruaUROvnEIXe2ekdQYidpIWfPqlaX+ PZAaKPZiWQOZ1L1Mhbs31PtitQcFhCpWK4S6bPirnmRqP9HBWpcytRSpcGcds1YbgDfoQRaGugBy qR0SmNXWzR2dOF6t3nU6fG3GT4qKtW2XVUQxWUpsOi/W5VHZllIaH9T3SZvxV8fIr2+cZPoa9+96 j6uXAUMQ9xITPaiTpePVcamz3VpoQ9JZ0ElRvZZ1efQSoXIJJTzV4Ck2rJvjG7RGArtdHT/uwE7X ngZrIcWsPchZmyFZN3Fr1ew0Zv2NJ6vmr9qht1vvnde407xBqFuraNIy7tdHx71WHYiYv7UNnjeI pGy3juP1NnN85LVDPq0XTavxa4dtXQ/1MKAToUecmpPCzcaTVU1sPn6tPesrvH/rUam9v8bIGKjs IW9tO+2tPuP2om9tG9X/CwvSHf9rnhu6w/b/wkz9N47RK2Z62bed2QY8vVqe8ErZdkuoJ197mUm9 z/oK24OPwl8vgtfNSXtz36XWzHQHMO64ycfmu1BV1kP6a0fZf2QPaPxS76+a+ciXslXjSKc1YZpS alqPeBs74l/JruYas4Na7SmDDKppA9WgI2yrMfb/CG00htMLEhMKQnwRnmqKmNZgfbnupvWsY+N6 k17NKL2cWmc2cFf2MXcFySu6euXraoADWWRNMgiEyguDfSkrV5MIuuPNAt94U3HscLWbNTJOwrXv uuMvDz/0cG5cTA1o6HFaWH/uvD33fPf2O+5Q75Wq/sc6oaY/NbXpINW85n1QQ+ZAHA0wAthsDzyl STu9jdViQGMmSQ3xyvs084DPf5nVoiYj9ZzVPVNvqqew2ijss16KtOYmnlKo9Fcex22cYB/cnvB5 0FxLdIifEM4t7i5Q9IlHM15Wb37zm+lWcaIv8mGVNSypV6YizXGyfQy0AT9dDYYI137kwQfv/NMt 8VQyn8lRHK5vcGD+3HkHfeoT660vyfBqXmqfZKZ0+jRRga6o6mFa2qCBkpNOQT3aUAsSjdVupibo mrShdlElCYVEG/OVt/AKxRWTW22MUq6qM6JmcH2QDvEkOf300/GNwTVQaYObeCbgUoLTvaMRkq6I mMXDlfRtdsoAsvpxqJT7q+GdpuY4Hb6XnzbgmL7t34oCLpRj2f20ngok8mqJZLr911sRga/2oo6X KvsKfOq1vM527mScxLf2ygt+dfyRR289u5vkqCyKZLz5/pU9i194rnOuxLbUvG6++WaiQsgjuN9+ +2muiW984xuQHcEyVArGBceSGusHZy/a49NGwAWuUV/4whcY3re+9S08ivArQrC1PAtqwz0WN0yc qEAT8U6INrBRNkycSYlbY81ohkIuHiTQg1+JgMBdifsMGH6NexaBvOQsJEfBDTfcQFQLwa+stJ// /Of2WTrkK/EUOLEShoAzEB5CLFedG/yE8FQ75phj8BBSHwnNU6MZE633vq4BZUa6W+jaU9bDwImK /N3vfoeP0WmnnQb7ZnR4MRJbCJzqdQDqGAVoBABcszXDr/IUNdnXw79PJgqkJ+WbjcWc6k4SLak/ nnfRNcf97wdLM8nFSB7awuy2k1Y89PzChS31M9Iwd0wT3twQA06cuMfhBM2r8TDDXxhx1U43KMLl GT8tsA3jg4Tw/gaHF154IWGHsDbddxUwpQ0SxOOej/vdbrvtxqRAV1AI84tDLmi0jI9OmDtcEqEx XPE+9rGPgdtf/vKXNIAeiOckhJ2AGvonYgifRejBvggIiZDG91xTCX75y18mGkADNJgRxBp6Zh4B xqanx3ebkar/L810z7AbldIGE8rb+aA7GQtB/QXxSGO90B7k4GmnOdCVqBgavrDEKEIbmvBdj31a KbDBRTNcEtkVXAhD20yLPOqJC4733aFyb1lz13F/3NdyWtgIfIsXLV441cWl+nGnJFPRWPyFZ/71 j3vv3S3Vsl4iOb85sUGs+dWhwaNO/HqMEhh1LnXXh1533313qIQloaFWECJUjruxZToQImsYuiQ0 Cy9sHKtZGPBreD0r8HOf+5ySuL6HTn76058Sxf7jH/8Yrk1YFxEZsD/4GhyQLQGfU+sPyyvw/OVZ aJRqD0rrgMSOQgSBPg6vhyOzvE866SRciS2aEGSIiAUeFgbLD/aBcA3HwQ8fwJC1gRNfXYJ6dKmw DcDliQDSjFrATA5FnpJ0V/Pm0TMfeJz+8RUF7wjsiGbcBELEMSKD4A4EZcCMWKXsK8AMAkEU6SzY e+gKlPIso4PRs9Xx0gbFCafLgsHtajwSaY4tfuyfvbc99M3x9XeYSO5Uatk5n/xdU+8RXzuOPHj1 aAM5VOMhwT/DYbDsdvBZwvPgOEyHnUFo49xzz6Wfr3/967BsHuQzSGPnhj/CbdUVUl+kbBpEweBw aYfh4ifOLDP1uIQTG0Jkpm3MFODsD7/DqR+SYDpglwQ30wyswtCZRD4z+xCwN3EoL9IjF91CPPA+ HOeJ0QAkEpUw0UwfRMjsQ43Ko+kcx2f4MiCp/xn7EIcttnkIBhdpRBY2J2gGeJhZjm74FzP7EDbu xmw5RJBDCUDFHoMLP234yl6Caz/5A3gFn9kVNN/9BRdcAH9vzCwAwx44AtmKNvBqEiyp+GimJgl5 OZFXJq133xGe6mYuwDTofFq8WN9lpfvVhrnxg/WWJPc1yVRj5Y4kkCXzCgd4zpPyLxwiCycJeRu8 FeqH0WjBJF5D9ARrANEVqQqZyKfvg0Hjug/nJSkHi4QwdGBi2UDHWsPX+yItYgLzZW0APSuH9Uw6 CLgA0RlePQPUyaqAxAl5ogf1FCYyhbgAmCmcl19ZOXAQRD+e9QqwTAkrwRZnIKSKVyCqs2Jh0Fra WCPLlf40jTI8iKHB9FnGJO1jQcJf4Ox8hgHBl3H1pyt6QIyiDUsUbgLMiIR0yMLmcfYJ1ie8hjY8 iKTJRgVaVC5j0TJwFjbveoPIZVrdUhs7JgoDrdRXTJMhvpCbGG6USADuxvFClVcMCi7GBsk0secx WJ/SHxzCzTn9gC7Vk4BJ+DKirkqvFloeZEtjS0A4AM8QG0TIvg4t8TqYsu+AQlgTvJW86swL80if qCbAPBuzeiUz4+SEAdvwUB9UmqOD/QamDxkQ5wUP1VkGAO4wy0r5OkY2aWQXFaUR5KFzdmtVixHu wVQSvMcBjt54F0IAmwq98RYegZwgVy2RA35og7APKydqScswEfKjBZEhJwDgFRxN6k2ixRg9u0y0 V4tiWZXvpu2H+9XqgpqNvTKmi4ahAaheGvB+9m0S2gMNqrmh3lwNwWW6T1VvePaOF0v6uSYyfXgI 0MqjLZwYL3rZJ5/zWTny10Mo1INUq7VLaAP/BQ6+sn4sBu1igA8iHBGPBHXC1knWo278UL8WqOay jVmHrEnEc40thF55igwebAx6yvZik5fyK4uBl8IvWDCsKw6t0DpnbX5llbJOVMpT9ahqz/lLG+Lc EPnJYMcuQqgbewOZBYljZp3QIWdq+LJycIQvwEZm5Cv9sBUhSqOfQVRk1fEu3ks/sCFeqlsFMZDs bap+QbBCJYp2iKMDvIahwcqRH0EjJ3F2Jg7O3AcquBIyOP3DpAITrbzGJeGysMnkNeGhAlCXjCSo 8SH59etcDEqTP/A7zBQ6YQdlA1YFkU6fle+YUPY2nQV4HDoWGBncFgULrA1Ue2kD9vfhD38YmReG +Otf/5qWzC8xjWwMHFZ8PfMg4jnKNICBiQMMNIDShjlCZkf/wE/khEE0JgsHGzOPWyJkBmnJr4R6 Mo8cAhD/gQ0GzXBoBkkAm7Jm4u5gyuw0vAKQ2I+R4umcnE0MDVkbkRxOzRqBgGG+7N/oaojQU2MA Gh4UL2iHoChOqywWksdq7j1eCiFxkIV4mGukH/Z7cmswasV9AzYaOLlWnNQl7JMufWzFfvXypgb8 4fWiTF7hBaxmt7ZNPW7owiID0eXSoHoPs3eq8eayKwQw7qYQDQhHlMoN+k/kq1KIBMoNwEXegfJU zYfIg6xK6DlckjMmdyAvWI+K3kguhHRDgmgMWCdQJ0yKlhAoNA2to6BAh8AHljFrDO4PWcNMlUBh 3wjOdK6KY6RR4tq1Z5YQSw49NZ9VGEeqQnZjnehXVinsj6L1rDQa8yKSM6j4zF8WJ+uKdYveGbEd jg8M7CXaOcuS1Ug/sACWEwwdIV3vs/aQ1GgPJ+IrAJMVgd2FkyzHCA1rVE0uDJr3slBhQ/AaVECo 3VGPsjI58GoGHPsWuuLIwnKFX8B0YHY1KVUJkWs1hAgX+rNtwqVQtqk00MxAlE3LGumlflwhG65D G7RQdqaTAiYx57KhogSD7YI3boIBJlGRzN7Gps6lsjMYhq4Qb8G22oT5gA5Bo0yhItQUKC7glfBQ 5pTpg7rAP9gGz/TA7GtjqAtuyE0MDGRE4VDIUYwp+9nPfsZc8wgXWzUTB6p1poBTBVWIDc7Lzoqe BJg5LrCXAwnCAVIFkEtxL3M+0E3IclLAoFt2ca1MBCqgdnTZHMKAhynTcyGv4BygjBuVHeNFCOBo AmZ4BS9lUDq5Kt0jm/MUKOLcwJBpr3M0XQLwsjCfMOjryrKVapatr14z3NDLCuttBnrf+2t1Sxcu OUn204zgt6ho8GFa6842DvKDCTeN54uDFJMdHRkcGR4eHeWUG4uyrmpIVaCAFYWIhDIaeZMPvIbi kzBiUt+y0lA70gAdrua6hL5h5bAtGDd0yRmQxpApyhDETAQoRstig5dpY6QVDpvQKA1YomwMyLn0 wK/QLouE9U9jPsALEIJI5YzGHHGelkjlyMWIMAjIXCw2nmW3sGyOcyh3VNzjXVpBmAf5i4WTTQVN K4xGM6lzh7M2B2o0KrwCaOELLGOWJZ3zdu6gGWdBoqbkJmkrEJoQqdh7tCstd4mopc4wDIGBcBxm NfKglnPjPnhDAGS5spJh3MiqaITZupBAGWn1lCsV1ly0r5ekU34plTtamodmJoqhoUGOVaGRvlx6 ZbEw0ZZEhVLzAi3gjRM9exWbKIyJ6YbRvPvd7+YzmgqegnnBdsEGw0f4ZWNGkQXvow3nD3QOpN8C t3BnGoNJLSgM0kAsxxHszJgTMHEzlQjmyMUqPdAGqmNvpmfoEM7LJo38y64MoXLUg2VDaZjTjz/+ eF7EZHEUo/weJyEoFvDYd1XfonXTLW0g8ELASL4QJ0yfOaUHmD7jYrxAy08ILswakDBqjoA8whRz cmJQHOYgfsCGsD/1qU8xIvgv44U8OPbBqZk1DhlsWgwHUQNR3c4vQJ5wwgnoahgUmUMgYHYvhrN6 jMCRf3mpqAGxrR4Mb8RTPiGmeml4t5nALWe6IpHFaoMPqzfqxu6A8UfueODcH/+8pbtzND3a1tZa zJbGhodOPf3787ffnIq2NV/J8RPuhsCoKmlVlUB8MBo0DFA8IommUlTlBmuVm7SxhiA+00Bt6LxC S83yQeu8sYpoCXHzQQvG64N0BbflEa3oDBNXMw5LQq2Cyh/hC4hm9MkSYmmxNlTMUeul1uhRJax6 MdItX4GWDnmR5kXjYhQ8rhCqHwgD0QKPfGXU6gECeEDFWAAY8VmlMIQ7/tInKmzeCMA8wtuBlh5U Wle3M2UQcG2e5QOv8PqM+9Sv9ShgutTmQkng4bbb/3zNFZdFmqKFwaH2eGo8FlnR3/t/P/vpVluQ NamGFYSx60SDGbgSJMG4QBTj0jyovJevDFyd81QCBRX8quVxucmQYcGgjmZwbf6q1weN+UBXbLrg k69cOgX8CiYhS3rjpELnvAW081UT/AIGoisfdN6ZZeaCm7yFWaM3+tSqLrwd4ZpOvK4mSpl0qMcp HgRC5gvYVLLmJqDSgJ9oo04g+itrRMkYJY/CwNsBFYD5zH31CleXJGWadIWoTj/QiabfUVUM3QIw e/+0PEZc5tq9jWL7jaA3dxhe35ZrYCy6l9gX6Yd6Ypb1KglIMkXFTNQkyBiyZsSnDcclXL/G8QCr hyBlkfpiBULh4K/VY/LZOn7Zvcje4UEv6Paz3S3t2HiXd5O0KFAeTYe61L22KfvV96zKZQqDtx8L jO1QB+5tbAHTFyl3VsCUa+hN27m21yO8Aqkdetvbxvoii0l9u0Vv9SzoiyxIXpp4fWmaQ5f4rzVF igUpjElZNak8JgXp69qurf4a8NSBBAwowDqiaszb2bekbDFfcwYVsT4SUvTqT3ZGvJi0gHnRpWjU 91qy8ZGBvshLz17as78q8duvFkhLG2DDLhw7Li/l2wnlV0WdhdlLtDIRQdWwfEi2VNGAX9SjnDXA 115noq0sH98CsbS3eiOth9LVBr7eXLgy7lg81hwv5w7XKsWszXQ2XRyfEkdj14lFh+VN7qCr7wSk oJ4bNS+6VdHMhtXUbKYWebpCovEueO5Pq84AknJ1HJD7iLSlzsFqrAqXF3lXjpfFKwOyALh0tRpt ZFCe2tViAnGIRFiNF6175HXHwOvLc737rhdUL+XbhfC6j6UBu/CKOF4AXt/hVzNAXYBehu7dhq24 aRt4N5IG+HFi3NFY9Lm/P3P91X9onduqh/dINLJq0arjjzshPidVmijzblUC2oMtXSOVAJlakKoB 8onACiUsFbsilkMYLspx68/rHQNdwUaxnnPCRcddT7KgK9SO9MYhF19dYFMhC6M/97FG1uy8Gllw bdwS0FF6Yz2qm9kB1uRZehM8sGE07meNUfO6F/0/ggEv43DkC2sGM68701xtsOvtN4EdvvYhNH51 oMTdyDgZiUWWPLf03gv+OvO02W0/7CieHI5+M3712VcP5gbI/axjgwujB8TUg10elRz2Oi0SiP8D RnnsRaqF1FIg/IXn0hJFnh704Kr2VzTgNMYBw3rpwu94RNXKNEbfh0kHK7z6gai+2yb90P71RWi3 seDhcqB6dt0Y8D9Bu23ZK3cUNt0t1S9FtaI8wgf+YrZSr0T9SWPk+ABPV1WsapyJoOEOnxUn/KS/ amPMrXjR4IegZ4V11zoMrBkM+I6/a+alvrfUlGasmPm6nM+s9LoaAwSSap2JSz+vfSP0vno18NCo Ak40Hl385NLBu4e+Ff7WzpG3vSP2jrfGd747e/ceX9mzq2OGatZgoEiyWP9xmcJcjvUcdwssOfhy 4fuBowXmeNg3FhX4JrZ+fPvghrA5fFGxpRBXhgStlkZ19cMxDo9mHQnOWFI8e+FCTDc8gk80Dip8 oFsuvLgwMGoJFYRrDER0xetgshi+cEPETwBglJ8ia8M68e5QSz1teBDvV5wOcTjD1IOXNBsP1kKc 1TBe4QGC+I9jH6I9GwZBE/SMpxoQ8ghgMGpV7LCRYNlX+6fml2DDwMlEayrCrDH0s5EgceML4Y0S cqGPdW3WYeC/GgMNGJyPaa72MF+vflSAW20ZfLXh1wcddwKauUROor8sFUKFSS9uPCgInxQjVPmC fcN/iTLggsHBELVaGAyLD3AuXOJgbTBrfKKxg2NwR9zmg/p+YATHmE4UAy6rfPUqoOkKCz7+s/jb sQeg3wCnWtEcsZ3+8YViw8B3FUbJeHCWQvBHYOcRWKoG8mh6EICkZ5gpRZ1VcCbsBR87LQbKHfxk YcdoV2DBsG+c7YgnvvXWW9mB4L90gqsW3XIfnk7PCPLwcRKe4LKC9obhaDgc78V5hmb4rhDyx9DY sXA1w1cMFzHHNEOvkQLWPb4OA+swsNoYqJbBrZbcqy63Yv5rkfctkPUUIw1GEejHjauAxy9XInEi TcXJp+CJiLc4ROOGjCsbWg4u9eRTzTISNEwQH2rYGfwLFkwzos9VD456BOYID9XEFNyB96lTNnwQ EZtAGMReYlLgvChh0DijhMFRl6/Ku0ngwMYAP0W+hi+T/ARPXvYGALDbAHghPRvpgTTukVfA7vGl RWmjIcK49LIHEHmPxA3w7AG0xxtdQ2Zoj7MtsRJ49bInMV52I+R3Tg+I2MS24WGNtoQTAy1x4GVX QDfCxevY1XDXxeUWH1tH3fpq09y6B9dhYB0GXl8MWD7u/aACssrINTUeXl7vZfE+2KyGZDVUJQ0Z N/I2XJuACk1HYf5FCKQsTXkKPqu5O6xbEhIxqmEdGPIsAinqDoCjGfcRQvmgNkykaRgoIjNqFsUC N9VpV22PaFdwoKYTJHT6h0HzuI4fLslnsjegdeErvxLqAudFVFevLw1M1wBrLnpADaK+z2g2cCVG olcg+YkgOvg13JaDArDxUkRp+ldXYhoDEi+CrbMVATPiNpxak/bxCsDQ8E6calH1aPAnSVEUM3D/ dVz79V1R63pbh4G1DQNW3eHl6T6O74XZ295RVWIfb8S44WlwnNHi2CuFV54qPPVE9onFpcWjoZHo RNTw8tqXhjlo+la4FX4dWOdIpkPAGwwRnk74AHZL1fbyAXkZMVy/wvuwHyI4o/uGRRLDRiA4oi7W Tg2gQPdCfBpMWdOfw/HJ0kesGoItviiEuhGVh9JGrYu0QZAnbo3PBN3REr02IjZaDjTXSPrI4PRM tzxFMxxO+EqIGr+yAcB/ORyoQRIFPb0xHLg58XXEedIhHBmOz4g0Yg2xnZZo1dGWcKQgwRuKFGux XNuIbB086zCwDgP/vRhoFIDTnIzffsmdN116U1+4N9WWHCN4srPt5X++cu3117Zu2Vos+F25FQsw L9TEsF3N3IS4reKwunCgHYbfITjD3DVETfk7vFVjKbE38hQcHB6tEjo8nc/0psI4XJvOYc2oIFBW 0Ab2yk+05CcaoM1QbouYrF3xXtTNGt/IHV7ETVgwb6c9ig7uW/kaHq1fNSZNNwmUHsCgA+GiZ/5y nxcBGP3QjFEg0avnOKI6L0LkV2fE/176WAf5Ogysw8DagwEnP27AxSOQhJQ4yFnQReORDajJomK/ MiwbG6bqC37iDn+tEtw2Vk2LjR/Txnrps7orKCTwa2Rk/DRw2ICz12zs7YrP9qv2Zu/YODRt4I1w U/2UNlbwFAZtqXxcf+UmH+wQFE4L9toz8esgWYeBdRj478WAK+OuMULNEPifvlSU1goJ/2lY1r1/ HQbWYWAdBtYEBizjDvIqqQZmLeDaAKVakXVce00Qy7p3rMPAOgysZRgIa0UxVeauZbCtA2cdBtZh YB0G1goMrCXsUSVuAtSltBhc25emcq1A1Tog1mFgHQbWYWAtwIDXrPWfBQfGjaaBIJIwwS/Wl+M/ C9O6t6/DwDoMrMPAWoiBtYdxgxx4N65r/x9QFmMl/+TwmgAAAABJRU5ErkJggg== --_004_EF64FF31F4C4384DBCE5D513A791C2B120A5A84Cxmbalnx11ciscoc_-- From nobody Thu Oct 30 13:18:19 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACB181A6FA0 for ; Thu, 30 Oct 2014 13:18: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 Xs9jY48EGfNi for ; Thu, 30 Oct 2014 13:18:14 -0700 (PDT) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59A291A6FA3 for ; Thu, 30 Oct 2014 13:17:58 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id m20so4940506qcx.27 for ; Thu, 30 Oct 2014 13:17:57 -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=TY1zYi4O3LNnsUGUes1mqNTvwaUbnVTMXG+dtl28Dks=; b=AGtvTqHPX5IFnIvcQjRa8yZAkGPX9J0jIiWNgRXcFzAXA/IlwbQl7YWiNaZ3kF4Nvv /UEMaxIFABT3hC1X76M+6WmmyVdeOapiq5TOLYDHq9BqFwNyXexL2a4S1jgduuKeez8p ChBtSZ9pvOIp3OebEhp8xNkEN3OWPZynPh5L/SayID9VxFNrt7hcY2PFGa3VNS/+xJ5i xG2OxUHxtl4zvWCFki2RcsbHUPFcolwHzNMlbBwoltlELSCyh9uEwXd5Oc5renKOSWGK +IahOvTzTjREZS/ZEY5KGOYnoier5t8XLALCb/DsmrhkXm2ZFjWVjhnHh//3vf1o8Q3z U1dw== X-Gm-Message-State: ALoCoQkAX4peWsovM8DALTXzPzjjk5E29IXd4UUNQjX+RCEPPRtujfo/xdOIfYTd6/V7VnsJywp6 MIME-Version: 1.0 X-Received: by 10.229.176.70 with SMTP id bd6mr30149023qcb.12.1414700277421; Thu, 30 Oct 2014 13:17:57 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Thu, 30 Oct 2014 13:17:57 -0700 (PDT) In-Reply-To: References: Date: Thu, 30 Oct 2014 13:17:57 -0700 Message-ID: From: Andy Bierman To: "Eric Voit (evoit)" Content-Type: multipart/related; boundary=001a11c2d8ba804bf30506a993ee Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Y-qW83cBCXzhcww3ISJf_uVmcCY Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG model containing both device and domain config (was RE: New revision of YANG mount draft) X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 30 Oct 2014 20:18:17 -0000 --001a11c2d8ba804bf30506a993ee Content-Type: multipart/alternative; boundary=001a11c2d8ba804bf10506a993ed --001a11c2d8ba804bf10506a993ed Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Oct 30, 2014 at 12:16 PM, Eric Voit (evoit) wrote= : > Andy, > > > > Two weeks ago I promised a useful YANG model which exposes both device an= d > domain config. The model is here: > > > http://www.ietf.org/internet-drafts/draft-tripathy-cloud-sla-yang-model-0= 0.txt > > > > A simple =E2=80=9CCloud Policer=E2=80=9D application can sit completely u= pon the model. > The algorithm might be: > > > > (1) The Operator enters a maximum data rate across a federation (Cloud) o= f > devices > > > > (2) Sum the current bandwidth across the collection of devices in the > federation (via RFC 7223 YANG device interface statistics) > > > > (3) Policed Bandwidth rate each device =3D (current traffic to the device= / > current federation traffic) * Operator established Federation Max rate > > > > (4) Go back to step (2) > > > > If we set the federation bandwidth to 100MB/s, and then vary the offered > to two devices, the result looks like this. > > > > Effectively we are showing the config of domain and device upon one > graph. And the device config is varying over time based on Peer Mounted > RFC 7223 YANG interface statistics. > > > > This is running code. The code is portable so that it can run on a > controller, or it can run upon a designated router within the federation. > I don't think the application needs YANG Mount to accomplish its task. This has nothing to do with the issue of device-configured vs. controller-configured data collection. Any controller can collect some subtrees from each device and use the data somehow. Just use NETCONF or RESTCONF as-is. It really complicates the architecture to use mount points= , especially if every controller is going to replicate data from every server in different ways, and force the devices to do all the work. > > > Eric > Andy > > > > > *From:* Andy Bierman, October 14, 2014 6:47 PM > > > > > > I do not agree that the "collection of device models" is a very > interesting solution > > for network management at the network level. We have dabbled with > "network-wide" > > configuration a couple times, only to drop the issue. IMO the models at > this level > > describe the network, not the devices. There is some glue that tells the > controller what devices are > > available, and how to talk to them, but the goal is to handle the device > level details > > as part of the controller data model implementation. > > > > We have a YANG model for Cloud Policer and DDoS Thresholding which > exposes the interplay of domain and device view. I will strive to get i= t > posted as a new draft before Oct 27th. (IETF 91 cut-off date.) > > > > Eric > > > > > > > > > > Eric Voit > > Principal Engineer - CSG > > > --001a11c2d8ba804bf10506a993ed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Oct 30, 2014 at 12:16 PM, Eric Voit (evoit) &= lt;evoit@cisco.com= > wrote:

Andy,

=C2=A0

Two weeks ago I promised a useful YANG model which e= xposes both device and domain config.=C2=A0 The model is here:

http://www.ietf.org/internet-drafts/dr= aft-tripathy-cloud-sla-yang-model-00.txt

=C2=A0

A simple =E2=80=9CCloud Policer=E2=80=9D application= can sit completely upon the model.=C2=A0 The algorithm might be:=

=C2=A0

(1) The Operator enters a maximum data rate across a= federation (Cloud) of devices

=C2=A0

(2) Sum the current bandwidth across the collection = of devices in the federation (via RFC 7223 YANG device interface statistics= )

=C2=A0

(3) Policed Bandwidth rate each device =3D (current = traffic to the device / current federation traffic) * Operator established = Federation Max rate

=C2=A0

(4) Go back to ste= p (2)

=C2=A0

If we set the fede= ration bandwidth to 100MB/s, and then vary the offered to two devices, the = result looks like this.

=

=C2=A0

Effectively we are= showing the config of domain and device upon one graph.=C2=A0 And the devi= ce config is varying over time based on Peer Mounted RFC 7223 YANG interfac= e statistics.=C2=A0

=C2=A0

This is running co= de.=C2=A0 The code is portable so that it can run on a controller, or it ca= n run upon a designated router within the federation.

=



I don't = think the application needs YANG Mount to accomplish its task.
Th= is has nothing to do with the issue of device-configured vs.
cont= roller-configured data collection.=C2=A0 Any controller can collect some su= btrees
from each device and use the data somehow.=C2=A0 Just use = NETCONF or
RESTCONF as-is.=C2=A0 It really complicates the archit= ecture to use mount points,
especially if every controller is goi= ng to replicate data from every server in
different ways, and for= ce the devices to do all the work.


= =C2=A0

=C2=A0

Eric



Andy
=C2= =A0

=C2=A0

=C2=A0

From:<= /span> Andy Bierman, October 14, 2014 6:47 PM=

<snip>=

=C2=A0

I do not agree that the "collection of device m= odels" is a very interesting solution

for network management at the network level.=C2=A0 W= e have dabbled with "network-wide"

configuration a couple times, only to drop the issue= .=C2=A0 IMO the models at this level

describe the network, not the devices.=C2=A0 There i= s some glue that tells the controller what devices are

available, and how to talk to them, but the goal is = to handle the device level details

as part of the controller data model implementation.= =C2=A0

=C2=A0

<Eric> We have a= YANG model for Cloud Policer and DDoS Thresholding which exposes the inter= play of domain and device view.=C2=A0=C2=A0 I will strive to get it posted = as a new draft before Oct 27th.=C2=A0 (IETF 91 cut-off date.)=

=C2=A0

Eric

=C2=A0

=C2=A0

=C2=A0

=C2=A0

Eric Voit

Principal Engineer - CSG

=C2=A0


--001a11c2d8ba804bf10506a993ed-- --001a11c2d8ba804bf30506a993ee Content-Type: image/png; name="image003.png" Content-Disposition: inline; filename="image003.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 254cf6a6a62886cb_0.1 iVBORw0KGgoAAAANSUhEUgAAAegAAAFdCAIAAABHNWmdAAAAAXNSR0IArs4c6QAA/8pJREFUeF7s vQe4bMtR3zuzJ+yZnc4+59ykhBCIKDBJJhgEEhkJDELCNjkasJ8fGPSBMfb3MNHIGGwM5olgHg8e JtkmGwyYLARISAIFJCEhCaV77wk7Tw7v969aq6fXmrB6S+gA9lnaOnfvmV7d1VXV1dVV1VX13/3d 3200GvP5vHb3uYuBuxi4i4G7GFiFgTspIRHI9Xp9Op0yaLPZ5N/xeNxut/mcX/jzwQcfrD/vec+7 //77d3Z27iRkd3njLgbuYuAuBu5iYB0GENwukP0XHn7hz62trX6//9M//dP13/u933vHd3zHw8PD 2Wx2F493MXAXA3cxcBcDf00w4MI6PIhvBPfJycn/8//8P40v/MIvRGqjh9/VuP+aUOuvORic3eAe WCre6TnE/U3Z+IF8Gf63Bed0yPTp0zUjV4v8k78pOHlbpn/33bcfBiaTCSyEzYR/nZdgtl6v99rX vnbr7Tfq3Z7/pmAg3tj53f9cuZHDPX/6p3/653/+52984xuRTT5BGOt1r3vdX6KQChLwLx2BTO30 9PShhx6C9VkVb3v/3iE4+bM/+7PRaOS7wq1bt17xilfwCZhJGSLg338JJCi9e1e1SkHm/zJtWF+v f/3rX/nKV/7Jn/zJ7//+7/Pv+fk53MUEYd27gvt/GUK/NRNBfW61WsiXIDvgDP7E57G/v1+SFLRB Nn3P93zPl37pl7785S/nXR+Sz3FxowiUTnbpAPEiZz6e7e1t4OHfYOOLO+Grt1F40cNrXvOaz/mc z/md3/kdXwNv40Mnt2/f/q7v+q4v+IIvYJmBE9bbq1/96mc/+9lf+ZVfiStp5SgumpmvY489D4R3 u13A4xc6YWUuH5OdWG81kt/Gmd59/Q5jgGX4Du/wDo9//OPvueceXxoeReIuyszGfXBw8DYuiTs8 q7vDve0YgBV+4Rd+4fj4+M1vfvPXfu3Xwig/+ZM/+Ru/8RsopEjt933f933Ws56FOHZh4ec1fkGy /J//5//5D/7BP/jbf/tvu45JAxiLlkHphrdcH+ctd467kPJPaIY4c7nvYui5z33uD/3QDwEJv7/X e70X5rvHPe5xdOic6udExkXvQFP+zM/8TPwziDYfxfnYJR2/uxfexy2hiAa7u7s//MM/TGPkLPqL j+5mDT50Td8Bc+MPPS/j2dVqmvkxlt87nc5nfdZnfc3XfA3LjH74E+DZHv7f//f/dXjiTtxMyf73 kR/5kR/+4R/On9/0Td/0ru/6rv/lv/wXogVwOIF/1up//s//mWkGNNIJ+Pmpn/opPvmwD/uwd3/3 d/9LOTG87Vx0t4e3EwZgjLe85S0w0sXFBUuVhygSdnc+YbH8JSgdbye473b79sYAIuAv/uIvEAe/ /du/7VLvTW9606Mf/ej/7//7//6P/+P/QER+3/d9397e3ktf+tLf+q3fQrgjpl20IfJ4y9VG2IhD 3M///M8HqY2Mfvjhh5///OcTsMRbdMs28MIXvvBFL3oRLdFPkWWYF5DCPP/jf/wPZN9gMKDbn/iJ n0BRfad3eqcv+qIvQirR8o/+6I9e9apXMQSvoCnjkwGSX/7lX4ahAezo6OhlL3sZ8g5Jx5+gC8H3 K7/yKy94wQsAoKSZ8icL4CUveQmyj04w9QAnnwyHQ4ZguwKMmzdv8iETp8Nf+qVfovGy/Yd+gJb+ GYjRARLIgTY+DSDuz87O2CRWascsSHoADLZJcEsbpslA991338/+7M/+63/9r3/wB3/w27/925nd jRs3QCPhA4DEKAzBZEEaMN/Vu9/eq+OvvH/nNFiL5XP9+nU43MMEpW6jOvyVw3cXgL8qDEB+BGgw TyMa2NU5nXH8er/3ez/UaiQ4p36O/IQfoX2/+MUvdic2yi9SyX3cyLj/+B//4z//5/8c9dCdckjV //v//r//gz0/8iM/gvqJvP6BH/iB7/3e7/2xH/sxOuETZPpHfdRHff/3f//P/MzPYLVAJD3mMY9h dP59l3d5l6tXryLI/ut//a+8/i3f8i3oyAhu+kT0s9OgxiLpQBq7xXOe85z/+T//J/0wKJL9G7/x GxHB3/Ed3/Ev/sW/8NMAL7o31ZVo9gY+xwYNMK5cA9jXf/3X/7f/9t++/Mu/HMCY4D/5J/+E8wQt 0WtcoY474U/kKSP++I//OBNnA+BbBkKJji1ODAdug64dIOEXxxti+lGPehTj0pLoALZM1ue1a9fY OHke8YhHsDH8X//X/4UQBwm/+qu/ylt06C5Qn9pfFdvcHfeOYcDPWyhJMDwrETnOn64i3BXcd4wK f+0GQtSi2/6rf/WvvvVbv9V13itXriCJsF+j1vH5N3zDN3zbt33b133d13Guf+Yzn4nYdbMJyiAa pVvDkbNYeJ/0pCe5corgQ4mmDeIGyfspn/IpfIj++IEf+IFf9VVfxZaANZxPkE0f8REfgeBDLmMb QVNGgD71qU/9mI/5mH/0j/4RMpR+MDv8/b//9z/v8z4PQwpjIY6/4iu+gn4A4xnPeAabATL6Mz7j MzDy0Cf+UkQn+u/f+lt/i+HYSFza4jZkOkhqQGJjwCjx0R/90U972tMQ8cyXXYczATP97u/+brDB 3IGNbQPZ/aM/+qNIf3pAwcFBxMOsXW6ynNh1eAvhi0HDFxI7Wck44/oRHbqyz75CJ44316/ZEVGl 0es5wXAE/vVf//UP/uAPfsITngAePvdzP5fp0AP2FrDx/u///rwC0tjDmNo7v/M7r7Th/LXjsLsA vQ0YgJ0eeOABiM6+jpGEf12Ou4nsruB+G1D7N/xVZAGSGnGGsHCTMXorJoJ//+//Paf4937v98YI i3zEnMpE3cTGLwipRz7ykfzpnjc64RPEn6u0CCm6QrLwLw0wlKMe8i3KMtIf7R6dmpZIUuQywg41 k24R6NiIkUqo1Z/2aZ+GIAYM5DKaPhsA4RkuMVE9YF9eZ1DEJVoqcCL6MYijqzILLNcIR/YhlGgA AEg0VrYEV+qdXMhfNGu31yNGMTswU77FrPyGN7yBBgDDBBG1IAfBjVUEwAAeaw/bCcvpv//3/44y zv6BUsxbLpqR+xxm3ZTvZg02ABr7hTf8lmjobA9Em7hxnD2GgwsbHpYfGtx7773v9m7vhg0H5RqY 2WA+/dM//eM//uMZC0n9B3/wB75iEffgDcBKdvO/4Zx4F/wVGIDnw4GYleLc6Me1u4L7f3eOcb+f 7+H8An/g+sO0/Z3f+Z3/7J/9Mz5EBf7FX/xFzBFISdcfaYa0RcQgqlAVEXzokohU/5cGCBcsIRhn sR1jyUV6IoCwvXz+538+6jMaBG3cNIzAci8iAKByIgTR3zGvYztGcMOpaL5PfOIT3XPuWuof//Ef YxdmLKTkh3zIhyDd8GR+6qd+KmBwaKDbL/7iL8Z356cBjONo38zl6U9/Og0ceDpxe4XvW4yL7QWp ylywXThswIPAdd8jQhy7M6cKVHU2IWQ9EpzzB7rwYx/7WOS7d8v2hghm4vTs3ktWHeZpAOZbNpV/ +S//JScMTgzsZ3Tr2hO7FHvYz/3czzE6ew+/AzOj8DpbHXvGl33Zl4E3TsrMjm4dV3el9v8O69aP tr7Bwy1oP+7bcJ0ju4DD6vrfARd357gBA+znSBk4AWsDLOIHfwQulm4ENzL9Ez/xE1EM4RsaoG9i TECCI2L+7b/9t6jquAQ52aE2ohQjhvCz/eZv/qaLVwQcOiOKJKYJtGNkHJKXNk9+8pORYjAlmjjy 6AM+4AP4EzZFawYMGmNs4ReAQcDxFXKWfrBO0Bh7Ai2BDUs3GjSSEW5GdLLr0JKu3ud93sfFt4e1 +MSZIwIRYY19hk7oAYH4a7/2a8hirDrov2jKCF++RYgHz2TcievUaPHM7j3e4z3oisgQumIbYzPj Q8wdwMkrLDks+OxeNGDc0Ilr+qDrkz/5k13oY+cBS0wEMNhCOGoAJG9hdOLMwZaJZYYJrowsvMvS /6tiAHK7dQ7PJAzM72g2HlUin7Zfeb8bDvi/KvkvNS+3J7j91IUdUhVR5Soq4sl1c/+QTzy2z60B /IKq6CYX9we6Vuv6Iz37J96Jxzu7Fuzy1N3l/ieCOHa+8TvMyuf04BoG47rE9xf90EDnAVT34K3U TOM58i5/hpA7z+DD6GGmy9iLX3Gx67OgHz/JMq7rRADjpqRlSPicb4Ovye1OIXCQThxRPjv/c910 LkXfu43/BmEgOJM8tgQRzWER5sT5gc50V3D/DSLlnQbVT/2lUVd+uAGyy7a/05OMxvsbBOpfIZbu Dn3HMOAKBHu2m0qI+OKMiAkOx89d5+Qdo8LfvIFWxpxdNhDtsu3/CtH0NwjUv0Is3R36zmAAbkS5 xomCxo2w5tCJEOfDLLPCnQHi7ih3MXAXA3cxcBcD6RhwXzQhqtwL48En5PZArCWKLUnv6G1pibmU m3lbrTZ2yreln7vv3sXAXQzcxcD/DhjAO0JEE2FIBAjg8SbEFs8kE3ef+Z0Qo0jtrUbz+A2vf/B5 vzs7Pb0ru/93YLu7c7yLgbsYeFswgMZNeCjxV9xjIB7Us7C5w1/xpm9L15vezQOw+G+9Vt+ajM9e +crn/sqvvOGXfnlrO8s39PYa+m6/dzFwFwN3MfA3HANIZwKWePwyFxG3RJHyITFI1aYSj1vyKCvw 4Ck3PZaLh989FCxGES1p0GrzP/3oPaK4Brd//4XP/aEf/IE//pM/qb3s1cR/hVfmxDvVkypezglR I6KsltaYlond0nIrrU9ATWvJ7C4BKvNKnNSluk2GVqCmIVbEaiThKsNAIgmSQU1HbMYtafTS9BNB NSZMlAlC12Uom9ptGrSXxkDavNQtSRsT5/V2WN3CahoG0rlFLetasykkuJQgSulwZRsEKT5JjxP1 e178wr/cGKi4gINQ5i4A1ytIFsEVAKzjpPjhhjHpTrhGwQ7AfVxy8SC+yejm9zU8ixvZhZ74oR/2 HT/wPa95w8s+4L2e2Gx2fuEX/sP/+MWfnp+Mxq+5eM9HPmHvg95lNrY09lu15lFza7g125lVcAJ6 +7S+/eb29CAhOf1WbftGc2uyNe1U1WNr1Lbf3GqeNidXppUANE4b7duNyUEVqDavzuvas+5s3qxi hXqtAWmmjWnT56WdbvWqsMC89sP12U69msO2aq1bzcb51nSvCtqtWvumMDDdmXI42vQA6sVW+42t yfUqXBkG2m9p1xrzWasKA/DA6VbrRn1yNUEagNgH2zOOjJsRC7dM6p0b7XqvnoSBh1pbo9p0pwqA em1rVN9+U3tydQ0GQGDAISQ4V2qXWcNql9gXayhb3xpOW0fNalDpAo59A76i+Wy7CrEkKrjRbpxt Tfer6AUJHm6qZSVvM41ZvfP69vTKLIkJb4JYOLaKCUHstN6+0Z7uVa1umPB8a/uoVZvVWF8Va7Zh y7Azm6cw4RGyqMG8qrekeq39Juu2anVLaNXICDYD6phaziPy/G1ccAT/8T2KNuYRbtu4jRsZi+Vk Uxw36jbCmttcZE7gdhk+Te4Tc9uNzDjcGfOkPFyl49obCYBoKbHSbtP+U5/+9C/7p1/z33/xV+9/ xMGP/+gPD8eT46O3vOa3nzv5i9O/9RlP77Q6W/dQm3gG1GyendftzEa14bteaHZLfJ1NzP7TGDU7 f9buvWdfe+NG7G4167d/e773wHb7XViOdSlTIscCdfUtdSHx0pyfP5eqAbX6e/fmE19ci+IvC7Qi TrfmW2/pjB7aar0/LTcNTy91BNbzdraeMJrv0ZSxsqGt/CesbxLa/9mqdW90aqPa+T3nAJlREjo3 G1sNq4Y1mwOtOpAwqnV/cdr7+Nasu3Yp+hzqjVr9z7q1SW32Hj3+9ae00K2dBEHrj3e2prXhew94 iyfcGAxMpfMWELC8b7ZnL2vOP7I3566MbTHFXNOGUsMtPL3zRzvDR02m94408FqCcUCrTf+sOXlt o/NxQyHWjGvrHhBb/+Pd+jtPZjtjG97/v5haRtl6bXZRH7+ss31vrf7OGygrbNFn7eU7SO3GO/bn G0WcZnzRrL2sXf/g3nya8UoBsYZik971WrO285Lu+Np4cG3glAUHrKmtZqPeqENWhY07H1IJ7qFZ 9w07Zx/Ug8Rr524Yp9utP+zO32E6u29YMym3LL8zyk7r3Zd0R83a7H37WgX2xJ1nzfisWWu/cmfU r9XfL6OsyFXsFx7QbSA+HW4NfmZ7+1P6dXaOVVIuX7NSL3ZfuzPt1IaP6NVm9u76udV6zdaft6fv 1Xd5JlCtub+jmYsJsbrOh29oN241m4+Y1e4fzBEa3iafmo8O/ll29eZ89tyd2ntM6le4jbV2cLVv 1Kevbs2Omu0P7MOEhR5t5Ew0OHVrtZ3/3u1/yHB6BbR6LYysd1/U/Dubzvkfy3vSPxsNBrtX78U4 nX8ZoDUg18DlGjc5yBDfLEn+5QYyF5gxnvyn//SfKi7gYBshAQUJ2wj55h0S3HD7mZQ9KN1EqHzS J30Sfs+/9/f+HjnYguDm2vSXffmXP+Gx7/+yP/izp3/ax3/1s7/irH/RftPpQ89/9e0/u7jn6jvX Tpsy03CnbDrpjjoX9V673+rWupKNxCly50OrcUtCnf9yI4+cPM1ZvV3rjXsnWyeHzYNmp9W91aYx 1Fmata6ajbenF1vn8+3Z9lZ3cj5t7jTa5+0a6fvHrBj1P+xcbG1vTab1EQi+XpugmL9lvrO1XR9P 64PZTmd/MhBOGZ2f6dZ0LP0NjYzEReOto8beaKcxxj2wihfm9fHO9Kx23npUY/pmQOjAB+15sz6F NbY4NLBUx6fAMpu2Z+POZLQ7mtRGj3zio5uPo+vh7LA2v5h2Htq58ccPHz10u3PavbJ1cDHrtfdQ yMf9SW/cHT8wPOyOtlce7QF62BqPrk5Hp6Pm9cZsXGudknRjMXq2VmvTGeDb7EbD8Xh/NGwOt6Zb rSvN+lHt8ORAy2yrNmvYDDtbvf6wvdOeDqbD3fG0OWwcNSjYMplMMZl1WtuT08nWjAXFvrLF3I/v Pa+P6u1x86LR2z3rys6GKs/caTBDsZLKJoWR0bfQWWbzvdr52dloOty7d685bLbOuBspmbzMz8zu tD2+2D/annZQeEZb4+6k2xiA1QZ91jWl6aRzXm81uOA5as5qh/VRbdy4sbXb2p71R1ChWe/Oxls6 6dvoo9movrs1QXG4dz7oD7rDnZ2LbYG3ShgC0Hh3cto4697fHr16trMHmaftRrsOUzE6QniMyjaH suPODET198dng5N3+qh3azy+PW5Meq1Rc1DbfXn39uvffPrms73B3l5zp98assWMp6Px3qhxsHX1 jVc0i5VczZbRHsyu1oa3h9uPaY9vTHbGe2ip2egAIInBVsA+z64JYqfDi9H4njGIbTdatV3OH629 0z2zcoiyNZiiNh9OJ61Oe9Qbcooa9wbb/e3uXnfUH+3sd+r9+nw4gysEzqw+Ohz0WhfNaYvdfXwx 2qnt0oMmLsVIYrI+kVqbmd2a09m2tqbbs9tbjfr+9n5zsrV96nm+ligLKzfmF83B2f7Z/mhfbLI1 6ww7WyM0F4i7xSgzjiSdQX2rOZrMJoTDXalxS7dzhCRoTc+G3XanNm7rCCCjH/o1Gd6HrXtbQ1IN P6bef6h/pXalddb0nXZZYvDKeH98PkcwNedvaewd7Ex702a9zaLfmmnNTpqTC/iKefpTr+/VducX 2obR5Yej8ay+Q/aZGXkN2pNxZzxpD6++w+Hu++02W8zq+GRyduX67sw2mXkDAVDrn19w7bfR3Z7v tteZ6OicrGf8S3ofTCVceefuO0o3GWxIy14huJGwvIDgJmsEAJOKkwxnhIWTAwgF/hM+4RPIVkEy NgqpuOBG0CO4v/u7vvtzPvWLbr769C/e8qqv/o6vPL04PTg/uPHC1/3Oj/9O41Zrfru53Wu923Cv 1hsCyu033tzr7Hfa27PBpDGj5AnIkBUN7mO5T7fmk+Z4Mh/NW7NGt3Hz1s2rj7zSOx3cc/6YbUhl NimfuWPV3q1Nr18Md24N+8NWY5tXx+eT3fbu1rTVALsIJKz+o6PW/vak2zyvT2b11gT9pza+2t6Z 3j6fnPcO9x4YjVrwD6NPt8hbPm7sYOyv9Ub9wbgPTg5OH2ghOtcIl/FB70bzjTv1zmA8vrZ3dTaY TwZsPa3mrLnFBGdbr7s+GrQmo+a43+qfb59Pr8w/4rOfsvfh19C70X0ktW7W3vzDb3rpC18yv127 vnP94vRs73B73B2d1Y5AyXu97h3uO74Kc2uzj+YuyTjfOu+c1B5JxP5JGyHVY6Pe5d9GNjrbIXwz qbFrGm6nW8M6U2vUj05v13bqe1d2pjdHVy+u6JBSr023UNRq9U7r+Pzs2n33TurzwXA4GfRbO7W9 7pWz2yfw9EH3YHzWb7E3gFaWV2f80PYRZ4W9vf1br3n4/kc+wF7TmNaac+YuxYUtWOqJ5Mts0hgh 6ufbNXZMlLdRfTg7b+733wE2EBlde4mJO9kaPvbkdW9+9ZWrhzvt3fPbFwedK9C3MWs3Z2zJ8Mx4 Nr3VOtiFehdsEY3twRgemF9tdPo3j1rjRmf7Kvmj5qQwYePcGg9rw72ruxfjM8Y57h3ds3/v9sPX AHUlZflwer33ltHrDjvXLvq9+68+cHHrokGmLKS3+LbBZjdi12xNztujk27/Rves8didv/MPP7Lz fl2NVJvvIaX/aH77Z179qj96BRr+ldY+dyuae7N+42K43Tuo7T3yzx7ZQYkocnWmQs5rJzu3th6Y Ht0+utK82jvvXd2/NroYI0kRGOxFpgtOwKoo25hN6oM2HD4dH53d7l7vbLUbzRu1q70DOgejKlnY 2BptzQeT8eG918ESIcLDwQnyutvaPXr41l53vwl/DCaGWAiHfeJ2v3vR7XQ5lDQnTZDcu3XWQA9h dFt5W9Muh7JZfSLcwtvDi/37928f3UZt6R50pm/ZumfyCNe6Xc0M3AvjTGuTwSOP3/Cm1z/i0Y+c 9qcT+La5gx7A1GBdyePJ2bzZa+7v9AAK09NWazgZdqnRMW+dP3xzv7Vbn2Pj4DhGNUaNPpj0rz1w 9dbZTeTjUe/WY3bfaetGl1ksC26dY7HmPHDy8PEbdlr7zOTK/n39W6fNGWTFhglu6/3tya0rF/wS hP5R75ipIkbx8J1d9I73rl50sHeyrgf99vlou/+BH/vEJ3zie9Yo74H+vj8bzy+y07wp6AhiHSG2 21udLGnlsppCz8STEFjiBZUQO6Rg4+I7kpa0aJsEN29iDCGdEJmCya9G5h3yWKK0s5F+0Ad9EJo4 yXE86zEpm2PB/U3f/E0/97M/93u/9Ic/8H3f/4P/7fvPL863Oluv/s1XT18/e7/Pel+JJztM+jm9 9kL281rtA9FnckNBaRLZYQmVo1Z7Qa32YRbEuO6A4e+Cjf9Rqz2yVntPlLBcgSu9Ig7CClirkcse cflJtQywZU3aWwLqa2q1v6jVPtqIseHxxj9bq304XBAOe9EL3qF2G4Pt9fPadr32zsUe/7hWI1cd Ri1v47Z65vLb1m1ntbqfdUEzInfAFc8TDdp16KJzWv6S9f8UA9vpEj8BAL5l+n9Yq316rUZK99Bs JWLp9hcoRFarvUMO/DqMgfBXGW6ftp4H/F1nGBD7d0ibHdtHVgF8Wqv9Tq12rVZ7klF2OX4qkABu eS7pXA3aKp9I7di6/ZQI1JXTp3NGfPms9vit2mEEHv2/vFZ7XJEZaPlwrfbnRtkVtdLyxtJ8jfS/ WKs9gaTm9udKyjrJoDurANnxUTX2jRWrJlAWDPy+DQ0Ajquw6JY5AdKjxT3TINkMAP3AxthpH7+R XRmClrdrtefVak8tkmAZtzDAKw1X4JB8w8xxJWV9yfjq/pBa7d4EAF4qhan2kbkciNmbKR8VGR42 ALH0j+gAJF9izp/Ac16bd2r1+4S72fFkawdTVIFFucbe7w/qbHnLB4C8IfKdfR0tGamNi5IMbtg8 ELZozNg/Nglu1Oc//MM/JAsVGwu+RzJ8kuwNXRu79lOe8hT6InsZHZFz2fMvC/9bW9ypJyMamTxf 9sqXPnjzwQ95PxZZrdVs/elLXnn05pOnfDLLqPAMsawhPWR2r3iY4/lxbT9eBuvf6J/Ump1aKyHp IToBUZGW57niGY1qg17tIKElHZ3cqu1dqzU2bzA2oPJ8jiednQQU0PqV89q7rjeMRTPon2teHbk3 Kp7+cW00q11BxlU92F4ubtf2lZe7+rk4qXX3COGvbol1dXRa20vr9uhYJKjsFW65dbO2u1PrJmDg 4oyzQC2FAuyJ57dqV65XT0ot3jSp7ddrB5XAauXPj2t1Jfeufs5u17oHcWTW2lcAlYPrPtpD1TM6 x8xU6ybwNojtv7G2o+y81U8PJmzWuoj4qkeIPaldSQCVXGTHp7XDK0iVqk4pH3NTy9APBZsflvb4 oraPiE94zo4udq/ucHivbDucKD/adrPAheQLxke4XmirV/RmvIlo3JglUJeRtGQHxNKNikyC+Gob d8gN7/nJPAic3wWNRRSWUqnJ+9JsemIU/Guj8YijVq8z/JOXveQNr/6Lz3vmZ7uriiO3XA21+hmu mXl9X+vbnA8LTGSbPqc/PsNChDfzaF67xolF2cSxcK/WjnRVdDx7eDDGsnkAbc2vYT27FqSHLiYz lTYHxDcORs124/4tGf/MCcgjk4LvsDIaWjo6kr+dT2cXs+n9TXxJE8wMbtrLjtUOt8E/xR5Qazw8 Qdueb2OZ4DjJpzZZ2nMqbDETc2DQA1aMMaVvZ8OtvS5ydktnTzyb2IvMbAoQagw8jINTYDy4edp+ xL7t1WW6+wF0VsPAyfF2foI9vVE/MMeKje7buyYZFH46ZcBbWHlJVN1il2EMjqYLH7z0NrrMtI35 sL51Mhnep9Mztjr5u+Rvw+qZnSI10qQ+FOT12q15Y3de7xAt6mNmj5m6c2TpOsF83gOx8/m9Mrew xtaGmgm308ZbZo17Gngo6lPzCBlyhSt1qZ6nkxmWC9nS39QfHO5uXzG3mAFAG6OswFT8H0ylFbLV uI27oza7aiX9xAPmjFo46DLi0ntjWGscTWr3yqKvaxA+qoxUovt8YGZemdAJe0F1e8tD7e1Wc7dr rCTbszQ0NXHfOPTGGoWpeVobjLBD1R61OzWQSo9v1Jh+ZEKczW/O6vuNupxC2egOhSvk/hgO6/WH sRygbmIjZPXM4Jo4tgEOzqjC+xckwZgMDlU2mVHkHNxicxTjZUsG18wcLq1tjWfz2+P5NdYDpX80 arZkbbUIGT668drsGKDrtX16wqymA+NqYQUmL0b1k1rjgZa4BZYQdguz47MJABOKfDGb3RqM7t3r dNSf0zWirI3OfDWTev2No8nVRm0HI0oNU1++ZB1U5wj7D/bxM1bBhHnRFLpCGKeZE04m/Ph00zvu t3dbmKlZB+gmcy0SeJBR6Xgq5zOG1vlkPJ+cT04ak+Y97QeYlYY11hoO+mPcTBpm7ZaC+MSVSJJk kgK6nYN/Pc/7HcoOiInqje2HX/mqV9z4iwc/4cM/+rCzNzg973ANh7kioASSgsKRLPKIucQETfXM dCI5jbybmv+FfxVrUcMttuHa52TUH/ZPO9udaWcPTm9O8TKAIZdbtsa2apMpgk1FEnu9czJ7Nrc7 kGdEjlJxGK3cMcc/CqegnAtR6TOKukzG261tyIVFExtgf2u6O2FvWCw0STqst4RmkCOUdUl+U7hf 1jWclJImbVaqnDoSzLASX/YmF5PZuEHe0xbrBi9fcz5BHNWbQ4+CZwC4QzJ1OhoNRsPd7uFWfYVp bIQTRSZs2+SQaoyjgHuEhRZi5hjX/OUf1N45b7eQU8iqEdm3qU2OUjBnhq221V+36Ws6FuiJpCYa szE/n4wvtpogrNXkEzYvcW5LVlBNCXnGZz2tZvw6smW3mg0ILSOpCU3kwZCQOjr2kNnpzOu+T6az aaNJHlTQsOnkMRoNmRjawxjKYc61jrTJ2SQNYCq+0xW29Hnv4my3u0vEAPJsMm/hekaoenCCNUUS CCL0jAn5x+czHC0NSIYjbgsb8XxHpvb4gV4zVijbJ7KeyfJAPuTcyG4Dswc/ZKatVm3eJloPb/Lp McN3mxDLwnLY0RsthEQP6+Zsqog23h8jUifzyQhU1K4capsuDKrAjXF92mYzpp2RFpngUUeS/AsB JAXDdm78Bo02rtLa1nDYp7ftbZ2YGcZWTfYKEwfvxq64c1iHPShbb27r7gUz0fW8liYnyso90ZwO tqYoj+YO4njd2G51dm1I0C/bMSs5QK4AMeBmiMkYVubitGRhZmIuzS8ToIPBBS0b7Q4CknAEMZBU tLyxtlFQNG80W/Bqf3C+v0tAIjse6N9qIS60KWYPi2A8IikucntrNOihWGy38TmDLRyu+Drr2+5G WDwImPF0ony80Ah5L5nPtGvz8zpG/RHNhxL9i+d4cN5ttGmK+5HGM7Z7pzCek/YIfODVHc/HrOvR FK9H+9rWPbGi5RXsPBVwkdqLv2iAxk1ud27fhHCgOyq4gaXT2H7Bq1/0loff8PSPekYJ0PORrgPt tlSle/MD5+HnPNw9rGqo7/v94ya8lWCCuXn+ZnTow51HVHY7HA97w8HVvSuVLWlw++z4YO8Ahq1s fDEbsa4OiKxJePpnp509qdGVz0X/Asmz365G7MngJhvSPXvVGBjNh2e9N1/ffVzl6DQ46t/c3T5o 49Wtevojyq2f35Nmgrl1dnS4e4UtrpJbbpy88WD3sNvEel3xnPXOWax7CXYlhN3xxcn1/atVXer7 8/45m0GToI6qh2P6rdrsMTKaVj9H50c73d1tdsSq59bFWxr11uFOtQnmYnoyHfUOutU8wP5yevTn h1ffqWpwfX/WP2OD2dmuNlexcZ6cn15LsIRyWD++eOj6/gPNrWp03Ty9dWXvSmur2qoyxp866u/t JlgMa7U/qB29T+0QO3YlEgjFQnDtNAqrm5C+/qDflFK16fEU9nEQZxDc1WKlErLKBjrks3lxFeLI PC+KlVW8ris+ezU2bqOrn+DDT+g3/4TQnIM5kWp+zEG5oLeVP+zZMwINW9PtYofF3v0vvFyz/YOC /2hpQnnL7fn2IcFrenx0Bgo/MSQ6sV6bHxIClQFQ7LI0xea43Zp0V0w8f0tnR1f9p/NWn93cBw0j lsCw2No5PqGd/dnuGurkU7Kv92v718BAAazoDz/4Gr3Q+w7reN751slQ6CcbKz8oX60ftGcms8pk Lb+4PW9fqWNY8pNvPLVl+tauza4oNGjN4Nlw0iu3rs8OukStbXh8HmCAYr8zI0GBpiVIFN9LUNA1 gtHWjU5v/uMa3XB3MmpNoZsrw/Fb2e8KheZnZ9h6zAl6a4mrY8pqdO/5sHYIxlIoe7V2eOAcmxGq CEFE2d359m7m8g6UXeJa2VvmRNEezg91VtqMWF/d871uhtjNlJ00JvUCYldxlmN1e96EB5qbN7mc BNfnh60p5ikffd2ClThqjVq7o44wzNScfAFx/AllAnFntQ842u+MzPbjn8cc7r/7h7NaZ7jdGZV1 Mqn1Ooc5T6x93EKy/LVMEPgeiet+O5cfZZ1tv/CFL3jjG1/7qZ/yicSlA+9k5EZki+qf6/CdGbUc TH2T402z41Ckw/5wNmwTX8lvbdzka6IlOLNczGdn81ani/GBwFN1pJWeXVaWVQ5JaNF0MkBPJxZH l22euvaioDnb0gxpGpyT13aLkyo/GAnmWz1ZcuzwxHHZO1pQek7stgrCcqqkNxm8AiPIHqTTGh/4 C/w6UKLdGWaS7baZzBo6trlZnP9jiSXJgOJJMZih8w+Hjau0WSwbXdGJ+KwOQ0+2ZSphFlTv5XyY T82HxFaYXXIxC0pm2YdXZUyye7/bi7kLVX7H1bGBYYKwPZm4uQdC0BlWH06KHsNoTWSKHGd+BVlI ueIUuc4NTYr+spnJWoGiRSSacblM+Vg4thHW/L3yQD0fnctMLFNN0zx+ufU6NMeSIMoa+cAj1u6F 0cec5xmbGcbMFo/9ajoZTkB9q0uQ2ZHfMvGnZILEfIJBJLs7w2GaUPfsVoW1lnvBJmvcCwjn5yOM eq0O/wcMttoJ5gkDVQPIfoS9Z8Lw09kQokzbaHtaHTkyC5QF2m5t2pS5BG6Fr2SDyMxDDi3caXg0 3DplM7uqX10hiM45wP4RWy8u8Mi3MhmJW8ywA0hYw2TpzYEhzA/XloSS0Cu7QGsHU4nhyuaroVwP 9P7hBNM3vAGmljoOgtWPDG6DE1lUmjI/qJeMRYWmHFpQrSkJwwCD3ScbyRosEm84ZTGMWEVTKIs1 o7mNBf8kHjyirOBujDvESMr0olXDarOrRTmlNDGFvi+e0VkfVx6rFYBZ4ASXh+/8phL9yzyF9UX2 nVprrxUWKd8SK8K33U4Hw9QanJhkzE/W4U5cwVRCYQVM4CtF+7pOL/s5bPHKV7ySW/JPferT/HI8 xkq35tm4sjNuCJWQYd6cNn6NEJSa6XbNQ7ej8fx8gKhttHAEcoFpjrWXcXRFw3UsrJsZz1vxTa2C wuEj3kWMw6cYpPgXXyumc9sInWHFJgtxkEPEUMSKaPHK20NkaUE9ibO7GLBjeY0lZGmOSMb2qmt5 7vdhG9mCC21/o1LsuDdsXt3HKZBxrZarb8vZRmdc44Zj88/QbVEIRu1dfMhpams9kxeFHdQcswu7 qxlG3e1saFFm93g67kLJKOtVTVlgkdKg6eSC0dCHc9vKQtIt5kLmVUx9E9OY3gbDASN4VTDbiss1 egxae8m+XU6kE3eIYd05aohjkLi1nR2ZgqM9uPQ6Q2NT4n+yMJuNO2cBExZET5kn1h9IdnZ6ZmXe 8FWIu9w7lj1ygIg8WtlWlZihd7rcKF4gq0RZHZyhNkATqQwERcTSra2sfPLGlo5pp2yJrDGlDF1l yopzIpOc9gEV7xR98fXgmfQ4hWw6FioQm4EFvO0O7lzRWlgfYMRAvX6PtUJ6I3l5ltTMHNqcsrrI UpCkpdlN4ExzLxO8YcmWpMqso6wuEcjNIBqwd5jTWU4lG8zvDNe5h7DgnHlNhg7YlfVtWGKfW+z2 tovwYU5W3YXwOA7vga+IFeEXTwMVM2T4nTY4IQkgcVM4haQlRmxFYx/PnJN3QHAjl1/xilc8+OCD hAmWAPXy1SnVipk5OxV7zMqplj6c3Dqtd9qN3epAJBAEeJ4WYPMDqDyJAFArlnNMaeWv7J8+/Upr 1fj6fvzQSfPefVOFKh6oDmKJ/axqWEOLBwDPhLD5YTeiW7wlVQ31PYilT6/xuPnB4Dc87x3cm2Re 5AIB1xA2uON9LLgFALi8kMJaLG9eScEAa5tuEzHQPzlrdbZx+FUhoMaZi3Bd5lXZkgbciYOs69Z8 3APzAlEpGGB0eIB430oAQOzxQzeuPkDc3KpTUfF9bpqwBKBCZbeMjkhiyVS2JGKNJcN62eDZC51A rMSW48FwPBrtHGAJrH4QRBCrtFusfE1hf/N5aXU7uTfwMD2z0EAIk3WtEeZkREjpgrt6/VdPIq1F STWLX3IdvPLR9r3RJBT3oJZpjdcZkpbhuRQAb6duq9dKDnc6tOktXSBWUsobLOc8Wfeinagu0W0K DK6jpbQEqpQVmDjrt7pZIqiXIkE6ZS/V0pTppIleqttEDKT3mQTiYr1covmlYEicV0l8sTfff//9 qAjIawQ9W6CXLvNmsnHfAY2bXfeVr3wld3Oe+tSn+nr2kt7hQBEyx65EXkCTzjIe0rRZ5cQScjYg qIQi3rKjwmV2rnRTiVgusl3Qp5sU4iVRMpV4ALxMJaORlw6KiRFbowL8Xt3cn1iE8WJsWuFdD5B3 9UFGT2w7FvvophL9qz9leuVEPT7vt65hKlnsuCuB0XmWGF6LqS+hdLm9T9xn4b/Er5SABwlxEXed KyNaxJ3HiA0dMotYWdD5W5ZIouqnre22ThLR1JaZQZeVplP0DgdyM7QOapjOysZ+/ESD41vUotIa K7EZ3wIA9HIddtlEpqi3HGjGPTs55eiNTcExakRdzMlR57uLmUqmaFUxACVKyfThlgorAL98mCvt lIGaK8la6px3ncnDKKXZZaYSrJWzOZ6WNumdowswbsqOTSXeP306X61cIwuusFuCtHE5sCzpYmi9 282UDbogim0oQRCzU0xZX1lcgpNuK7tWMbxaNvCFD8w7QY9GC/bVTfuS6ukfOmX9ZmLJVMKZia82 hwNmAtpYB66jvWJ77ebknTOVMOrzn/98bNzPeMYzfJIuuCVC7U+k4Qatx0lFM7AACoL4Xl7Y+gSr 1GA8Oe1td7Znex1FbIJAu8JYsHHby4505wOXnvy5LIwYV7HDBDkbAA6MN3PxVAKerrA/uNx0Esbt izZusayfhnw1wv1Yvc1Bk9m4yaGjZTPDozsaXvS3DnfkSMyfkl7pkPjydkovC+LSwmB0n7uLtpJE KDEl3QKq9+m4WmHjNuSALgcgJpMEd6Sseci5SGBrRq5e9zquecAqctMtML7Cl+cSXnXIhdJcnS/b bXMKKmeImcvcZhKeZRO5y+6A1Rg5snFjeA1WX+y2F+cED8CH5mng0pk2qNC5s4eLbN+QsFTE01lH WRoz/dJcwlKK4XcdzTHgUiZ8G9aUcyZjORM6Vn2JFaSboqZ1ZUesZTZusvGHY5KuktnSi9mS3wMA /F7aBQtcYek76Bk1M0i9uEGA1kH1/cD3GG9WZrOcsghu5xY4Zy1l0eu4dmDOFnYju4Kg0ILFbMBJ UZ9AeiIHAMDFtwvWIBB8/2PuTlk+L23JmPt8l0qxYsVg0+0dFdzMhAyCGIae/OQnl5ZkunkR1GCx SrGCMcToxgnhoyk2bg+GT7EFIzJ4UuyAAJBuBYOlIHCijbv3xhvdR17DKbJeuGXfwLL8ltItJPA1 U9kncNI4EQOXMi8q9SW3mBMeEAsAKc4DAGBtpBhYwRUdpqwiEJVoimUqZ7dub+/stBNufINYYCBl WwIC5DxItNsiDeHtFNu921JTWrIMz28e7ac5JNIBSEcsAhEmBNREGzeMncItw4veeDjau3aYSAKI tUHXDJ2sdCCBbaaQAlUJmCC475yNGwiWT0C+D2/Yiku7rmuFKZg1h3Zay0rDSz5eeof+Runoug7s ZbVxQ0tDYzoCkpq6Xpwyu5Q2AbhlZX/TvBJntaRbbcZq4tq4LAmSCGCNEjGWDoD3mdItbVZaVFYC n9hnNrqF7KQgIR0AeksRxAGlKUIzHVcpcynJordldadjOwyKrI9HvEOCGyz7PrmMILdUpCDOT9+J BFNEWsr9Qhu4ZA1YB0zq0Pn7l21fiQTvMHFaNE4EIBzoKgG4VAM/P6a8kgind5XIAz59tzD+JT6X AtWIleROTmwWJpLS3tdLOgZS+lzMKG1eMg6lrW6nbCKlYjtP5SuXmVcSsXzExG5Xtkxcm96Mhy2N +gcx598h5yRDvvSlL+WM+WEf9mEQkgOsV05jVm6ocqvQOhrQgA1HM+CaAAHt8/nm8++8P6QmAfGz umFHagUSRZs9bmrXICyMnFwo2WgCgFZ5DQsHqQSMc78jcZkRS9ZGNxHi7pQfZ5XkKmkWCqjIjfiM 4uZC3XzIbdwtvKuAxxUk3d/Yqu+1lcskR5ZbqEtL2oF0wEocVmrPu3blgYs+mSF+g5bq0y8Ydpds 3J6AzNFI49j+AJT4XpVsO2N92UBlBnVnDiZprit1Nt1j9rUdFBY3MsZsE8spkUAXABbIWUmpwITL xCpRSqjTRSWKa6yIg4Ii2yTlyK/dQaHBEFSIuEIp/6WWxhrJ4GQqcd0yZV0W+yyWPSvLMtrCRjPe 3ny0pUNejzFQwhUR7HNbNQYovC0XsfMdc9KNFXP+h/kBJ9QPi2vZ21Fa7PIJ4ZnPEeu249DG11SQ mIBQUlpXUMqAW7cMQ3u5HllbI+7TmSNNzgCZ9xfgiWvJOl5I9OnuhxS9ZJlSfOIB2jwbYjq9mS83 fic3N/m4CeheJJlKjCrh5bAIg4eKfks6vNsK3YHDt+4T4MM/+ZM/wTn5KZ/yKQ5H8NdNQBk54QhE 36idCUf4hYYjAmMrtzu4Z3zrBBHQ2LEIEHjL7jf6dQn5vkOpoXq93+uR5otuN5CBr8TZln91e6fg +l8NTL3WP7toK8/6itsEsSTl9xFh1BQM6QrUbB041+S3Ky1+wj6ZzQe3jrbvvapbKhG6lgU3bSn/ wSLrFAMVso6Lgh63jPi1MuCa1TKdcleFDLRhxNKu4FLVcTIaUM+GeyIFI0xJcHnjKUVEhqMOIbT8 uYjLKC3t7E+qWRAZLZG0FAATj87KGvZJP9/ZIvhhPWs5ZQkkZ/ci/KPEA8uz0204DKz7u/F+kAmU ohamjHe3KRpCuabFVrTyAMIo3OCADXb2dksArKRs7/y8vd2JgzqWySqZpTSZusUqym5cXBlvT6bt aBWU564FaFw5nw1OzrqHB+ZoWUyoNLVsybCLozBWsZZjAN87Hons0tCSRh/4igtQ0zEtu1xZ3BCV KAC26rYMyVC5cFAH6R/Yy6RCbdLrT7hed0A+A2XWKk6neInNVjdyIPaOrmRWW92U7psvVrcxyaDf VwAC0mH9wYXOKYeA29x9YLz1mMc8hujAywluYXY6/d7v/V7kL2lhv+zLvowiwq9//etxEXz91389 xYJ9t2effPGLX/yd3/mdz3rWsyiaw12Vr/zKr2Rsr4wDBE960pNKMxwfc0+k1rxSHfmvrHe3z7fu SXLgTI6O4FcKsaxe/dGnk1tnbLWte6s9Y5S/mvYGretJtyT6D97avvdQVwGrnskZhf6mBPlVNZRM HLzpTZ1HPFI346ue8Qnp3Gutw2oMTC/wlQy691TPaw67HV207z+sGlzfDx+83by6R2a2ysZzovG4 j3At6QLO8C232vccKNCz6hm85VZnf6+2V52KaAITEtGzV30Fift1oxvH249ISsg9ecvDjb2dOjBU PTMKyB2dbT+QhIHRw0eN/d1GtxqxgxsnzV2KyVTjanrWV2BPArewWCYPP9y8//7lXW15lvPTPol6 6zvVJLgEYiezi4du7eIdbVcvrvHDx43DfQoAVVGgNjk7o+LZ9r1JCbnPbx3v0G3K6j4h/8a8dbXA A4S99Qa9kha/DKEH9vCgBFMgmHrBOFpdcFev/7BB4SCmpvuXfumXIqbpBZsLEpzqCmjvQS9gDJoR G04BeB7qCPuRBBrzOZcJl4Hz9BWVaPWtngSkKS3VONF7ovzNZBhOM8VKHUwCVQBYwbwUaJMaWUdS DVKxlR1qUwCAPJXJ9rJ+LE1F4qMzdRJe5WMYkeEk7ckD3Ktaz7DDUAywqpl9v0jJUdk85J+ubCmC mfKW9mxI+bBi1aT1qmQ1iS2TfSe2uFIfhcQluxlSMYBTLCQ2qAJElE3DQLbAqjr079sjKxOc8GgV LDXj5oJyjm983U0l3H3BSMK1c+wicY6BVBu3j/61X/u1HreEpH7mM59JhB/imD+f/exnh2LByPR/ 9s/+GUWECTJ/4hOf+M3f/M00uHHjxgte8AKoyAWc07NT0t1cJQG3GzFQHpGyGz0YStTbaA5JG401 3K7w6gCydt58MaHuhnW76k6mqgBQk6dDmG13Z7c/HLCjdVtt5zAZ2mSTIZVKhldlB6emapMyqdrn sAC0OaqH0xQmac7PZdFPXVNqLZiNmyhRndZzKpHRnbRNEfCWtF1WCGuhrFdxEkpGJzFCxtNK1qPC laQnCnfXSNoQitYrhp181TZrzwUvq3jxidvr1DYckPWCuzq949PuThcvgM6VAdwi8PIx0GVIO7WR 8yhnrlz9hcoAXkVhQRSPPLnoqQwSubTa291hH+RsYmmIZQHFq9aNQcvLRHt393aJllV+Ag5qirVX 2hQuz4jK1r0MZmYxk17TVEIicmbJL7KeUnqLR5mhjFVk7I0Ct/FNjIfRZmU1hC0Ni8ZjobY6dWoy 5QaxQKm8W0KJC+xaomxgM7PblhArbo/ZDDDFNkDY7VKBlCF2ikazMvANxR2vX4ZaU8rknmEAEhQM 4nZ7Aq02N55w1Gu12DipAQpgbWUFa8g/sZ6wOWKV5mkFW1Hdr9PhGgMTx+xwdHx07d77uCsBBUVZ wrQveoFpnbLwqhAIZXGSUzx5/Rqk/XiKhV1zU7UG0qm32p7ryh/VA1DmoYVAUO6jiAnXUWp5GTrr HR0fk16KYsGNK7vrNEyU4De96U1IUdYIqMO28ahHPYow0MuZShgNqzRGDxyM3/AN3/CEJzzhq7/6 q/nwRS960T/8h/8QoVwoFvzd3421hEqV1DZ7znOe42HCv//7v8+7n/qpn+q+0azABDagMzKd1zhR VprhkBeD2yc7913l7c1uAVktT4+xrjZ21uFFfAJUyKzejdu4IzrXr+RcK9yW+5ftlWzqo+lg3Lyy 4/kAI7qWOU2OqVsn7St7LHLj9UKDgszBBnXRR2hsHwT7ZklLM3+AsY2S5ty40b1+bymOO+4/Ewt4 sc57MpXsl28DluCh/YyqxpgX93d8lNIBKOq8rhxL573tawfLFt4SClg2YKC1193iWk1hJRb+UOf1 reHFGbkbdu+9392OG05gslrePAZXVGhYucAdWjohAdDxmx+6cu1avYvlWgmGtNV69xHpDBtbslYh vXeo5rGeUr6GsfKfnHevH+Ym12Jn9B6WN/cybtzg6kUjv5ApCCJsxjsExVdArDHhEn7yETLKgtjb Jy0MrNslxK5gM0AlyYUqInBUW0oNv4AFJuwNsDK3sd2vPX3mgFEI5/j29lWMRctiePGJB0ANjs+Q gHRbGRgJYkcn58LAGk1W5zd3n0xmxzduXr3/PrtVJ27xtVwinRG2Prp91qS2lIoqbKQsBTguzqfj YefwOtxiLtiYS4o273ptGK1ub7e8Bv3T6XmfTZbFFbuF+ufniEGWxoakQ2x1WCyQq8hrJCe67+Mf /3husVzOVAIMmFe+4iu+4t/9u3/Hyx/yIR/y7//9v/+iL/oi/uQyZIwSAPIsPJhQPPweiFHyuXFP 8TRa+hVBdBx+VM4Gf7Sq/2DI0SfrfrR7tps4TzybYmVjFdJhbClTjLX8o6FJRycrAdZSFRiTJmU/ 2qnL/StxnfRiDkg6fgryxc8yMHyrvKqmytk017d3DDD+YlAmGP+QX1PeU6W+baogvZTuIqKWgdHh wGp4rMRVqb3yATBpcyQargpUiBor5axEoKxum4ilKRNS4i1zJOSvFGihmdIZBb64xa4iaE6v9Wyg bnViWuq2gGo6gfoN9gyWn53XrMSU9x//CBgxobLZSn3eRKmclBkAy5Rl1uj7dGg/DKfE8LATM8Ld wqVEjbWKbSwxJKrpMmJXUNaT66/CwDLwyh9gfA4LreTS7BWrlGdLYANlM8IRbo0kWreswiiOc9zI TcST1lQVw6AaoyavbxZgU8+g15ZMTlkOuMuUNayqlp8mVUFZFCzjWEWUaK0V1mCZ2ZTTUQlH40HX UJbiQaXVLbTgWUWabU4Vx1aEzETY+lWdxz3ucXFKhsYXfuEX8l3K7TI6QvK+27u92yd8wie8+7u/ O31h7P7wD//wj/qojwqbIRzFYIh1/uVm0Yd+6If6XU/WL6kBH3roofd8T+quZzqRbUgKQrKSRRxR NxmNtLdiwRiNm51qnwzdjsZ90vs2WuU4gbJiaFFoyNjNUSUOqhYMLvIqUL0x+gt5ZaFN5eHAM4uy tDa3dLSRBpU71KSC3pzmxwGAZVUYsDKiwAL4JOY2Pq6ycvxthQCY9e2NslyMVqbWagBUuGvc2l5x OFim12g4hliViPVDExGU1awlfU3hm7LtVOGKBroaviYGybU052PpgdMJSV2RMpXd8qJwVdUyYy26 RRBXIZbG+G/kbUngAbMnUd6ter1wMMWXraCOhIMv3OI6QSUGdMccg2Q3CzFcx1mmXCvPsMvx6m6x kpEqNmEZzqg1VgMD5ZixMgfa4UWX/i20SSJhvdFfpgWphoVV4EKPAPvNghuYsfW94Q1vQGyiCnNh GG0YKzEhHi95yUtSbdwOvUcd+pUZj7z2MMP4nCJYLYOH/+LJClDDiSpBAf/gD/5gzI60752rxBws rmhNyUOlxBZfesiRn9hNOMlipROq0tqiM2kLxZzHluiBfUuv8AI2FQyWaPZGMEV+qwCd96wuvbhl VkUun4WVZVAbAaNE9UVI9LIUc8sJvvRVBLAlWmabpVrIFNMxCg/RqZYduDipBfClbqWoabK5CJhj XpeLxx5QtU3qkrzm5BK6stHxCckIoXgjsoEXRl9GL3q0wFMQ6xqU5hRRmWSuVFisK+8gF2Tmdf+z 4SSnlNEFTRbMewhzNndlzFLB5PxkqSTOSkid7dmW06PtmFpBXN3RmIg0di6VVELTMk5YnhSviw91 ASQ3X1jEulsMSq94tKgWYdRVqZlF+FrIv4T3zPx+FCpQqU0fHXw0+VNmV32CEkvlU8ZmTJJXo58h w8b2nTG29Gvow1qwrOBKA1LE1WJS9puPzqwdA1lx0bW48pVjcdzKo20Yz3aUVdwLMPh1hFkLfod/ 5NSJl+QWvKc1AgCMjh9Fnp41a4qRJRYMZkeYpAEYW4de1iw6mdLUoB756OjLZmZcsQx1lJPlOpuP sIOevFIgCGk5e61bthqDkgcW88+/khp5uEhmeFPJ2AKbyfhmty2MhqpbbcXMs+YqIgyixNd2jcBY MRpdSWz0iU5ia9VQGjz88MNYSzBRvOu7viuRHejNIarkcoJbDPRWPSzIl7/85ewexHEbHbOFCjlD rpIsfnPlIrRB4XBEf57PwdS/lYLbLLVn50d4GLa3F0U6CmRzEa6GAoCewUhh97bYhYL4MJnFo9OJ wb9ydHtJG8zZ+TkVLvwyS7YtrxTc1GkhPHw2pT6DdWuLuji6djjDGdxx++ihw6sUms/8h8syy1Q9 AYFDgl9JR10avSzj5MVSbjygtd1FM1jJ4uJF0kta2ugirqRz5Gs44w+AAAOMrgsyDoF3WxIfBu5g 1CPH8sHetZU8EAEsgqF9ePaJDAY7CpUnpdovMyJgQUWXcq+xHr3MM5hiB8Rxo5pn8c7B318QNIqo UVBsr9/fJxuUsY/+XZYshgOY4PTWQ+0OBReVBMZJKkj8NVfJLU0/j98rPtgHsegFOa5yHjNGdCO9 OmIVoHkpS8Gq0fPXNQiU5S0oa6JzreCma25joAPulvIjLiDJ2VKJNcnWcutg/7oJ5WiN5GvKCe0T 9KzTnlCzxNUxm5mYm170WN0HC1/XarVMy5CoVKsyXzhNGhcWUEe3AACu3N++VnAbbgejC1w9+7t5 Zd64K8Ea2Ez65un56e6OMaHtjza5PEzEKZU/nnhSSWByLgUqj84uXXEKr/gv4I3IPWS3rOEWkUHE B9Lv0jbuUr+X+tNVb7+M45q4P8KG8a+dKVQ02/6x/9vv/mt4XI3KXo2axa/ocCINUlbLrFtrWejZ O7emUplMiYvGWQGJg5qttyKQJYClb5sks/ENhpWT8jlmfdoyDpMuQhtwhlrB5ReVgl+PLvvSMZD9 Uxq9jF7HFdD66KuoEHCls4p1XMRVeG/xsaFLJqDF/L1vJ0OYYD6XrNv1oztw1q2E4gKGDG8lnlEL K/GVXTKMIFtmhsxvl5Mg66rEM86udkw0/dFhWOLYfH7S6zs7Hcvpamp+jokFY5tn1h9OLZ3drkTb Kq72NWDg6R8rbu9/lddL9Lp+lazK6VXGfIRq68tE3tIqiDjC2ZVeGywZO3KtXlPxBNVtceIBwhh4 xzyLywfIl/jqZUiHgbViPlxGnePKMbwBVxll7Uwc8VWBS53hbAj1JVBdaGSzyxd5oFRG2DrnEjxz PsGwjnLZs5Dvy+IUcU8yNbRs7NI8SO04xWBqHPelxPRyY7/6HOef0wnRi/dZa1dG1j1+vVRvmO6Z 3TZd3z7r0Hq2448dg+wX/z0bOj9reZZUwbABkvzIp5YbHw8NBFSrpGiQb2hvG3FWiNCnWQTVLixL 25YNkOKXCkKqRIAAYHR3tG9unU88u0O8eWqOH+/T8GhkjJ7sQ68zJ7V3+cmokNPCp5adwCqnpqFN dDo/lEYvoNoA8NPrZsoarkwdTmFCo+x6HsgQ40GQnsfVUeB9B4Rkv+QjKpLdgiw3LwHrJ18vVXxo o7qWWcGxNMij8DIgY8zmMIdVI5+MT8WJmHNsAXZ/i9g6rYJKunqDfHWvoGvoO5v+CsouM5stwwqy Zh1brU/nliAuYolRpkt+5z58vkTZ7BvS9XKUKbwOtkUa54q1D8IddZtLjkRdc+2Rfzk9IP/9hTtk KoES3KhE8/+4j/s4nS9mpD0YmX1TIgvKe8VFAbTq4CmXHE4GM0GosmyFjbs+GfZxoGCRp1v6U81J XT23fNx2xMXXjgAwfsIWLDPVYkHk1sAFJBItJgPNuGo2TCnV60wlvgsTYOeJATDYyBYc2biztZef xcwMJiL6Fo+VFEjdqiA/N66FRpN87JyYsANC8s7untWcNPotoct8JZlLwE4SqAe+kaxuj63O1S23 cbvSF3frkeD+uumNYrtM87StFA5bQGL7kO2xUl8w30rljGzc5mNf8KvWNpGzxsLSIxWDQYC/yZoV No0a8ftZSImNYopPwXIqPPvw1gHnaTVzbjdbd9ytMlOYXdt1KNmRHRW5JlQylcAnGAoUnYyFt0Vi kiaulIWNm1iP+VRW8BxX5xcXIiJJIJQ/u0WS9bFJ/cySYBqYlZtUTnIg3rbQyZWmEucHpoW1ym5K 52e1dbhS/nYr0Mp0PJbfT6KBZ2y/DBOE5lkUufELSNPVuai9CKeylKoMoDU1ne7uFpzJU1wlEZNr Tl4zxFJ4i7PX27gZZ9AfhKsStPcDVoDWPD4yf9lK1B8s7Wy/X8XYKkdvmEGsqFyt5PwKr1VGKeza OIKsTArYkoKcl6jN+FJUK7CZcgmItLr0oCHYnhRs5GyWnfOgLMZ6K3POtZGFiZy+VC6R4BVymq+3 cdPxq1/9avpzwyDGbsIB35pcJS4p3roHEP/wD//wNa95zed93uf55hO2Drdx63ZAVdfQjOs+ewkX iKHS8KGjZne7uY990wm96rGviJHku/2D/RBCa0xSeMcBlugcj1MyXNOYyPm9vV0Ex+ZpMQz2LnyP m9Jhm1ARrPN5/803Ow9c21xtwBv7/lyZYZmJglWWyp7ycbstqACy5u49mpUf8xyGts3KguGv7snm K2pO2rS4cD/uD/auX114eNZgDUiOT04AwHeLDY9sphcXXh4hQBu4LrzolFVtxgaJyCpuZjM6yzur ObmBr6x3uj29eYvoi21sIM6Fq/hQWjGuufEYyXVw5aACsSaLrZZmdTFPugIDgAFl1W2JrqYI5/qb FaChpi3RMu76Wf9Ao5Mbtw7uuR5fUVnXPL3opVv5UzKSe81J7OaFm4SrZgeTnIGrhMzdYGl61hv1 h517D32pbX6SksIbzr2ibOxCYyzWJnZjhMMS1IVheTHkifOcIvx5R2tOwiJ4tCih5gydGezMDCSV lGCV3CS06b8yrwW78cYXMC9utz1MO7NCrWxuncEBKvxh1kV/zBRbeALAMeQbIGCa5hLRtcDNDxBS +cVrca19MsuwQqC63Y4iRiuezAQcqL4RVDNbRpbnFXN3tNjjnFUFgJqFKi0VU3Ozpl1UW8Z86V0G rsBV/gIim00rJNLLKLsESma0DEbHzWxl39Kt/lPFiUwH66ZVVHH75uquHa9KzZZnT9uILtmMzb5c /ThZ5R53AFbOPef2gIC1gOav04AlY1p/9ePZNqrbGQa8blnlA2UBYEG4iDnjd31r12k6AQBr2ZR/ PoGyzgPV3dq4mXyLlozLX3u9YnugjawCeYJAegsv3CEbN+O5RXIZ0vSUwcyhVH9ow7y54peYZZsN PLFb4F/OnLkOhpDdtII4FlGQnomYyl0eelH5eJbtymY0oBndprR0NkppSRuvpZnSmD4Jakhp6d2m tGRoWibSSyk1kitWJ3ILQCpZShq6HNqUeV0KsZA1kQc8YioFABRyDFaJOVgUMZWG2HTKGreoXk8K tOnEwuqViIF0UI0HVncbS+GUiZTa3CEbN1ASx01a10/6pE/yyYSjrifarjhQ596VUKd187SJq5wc X7Q67YZliZQ1G3tZni8YwROScfiC4d8sYilHT6l/F0CyRlql2kpEMzvuqoYykptXrzxYlqM86zYK 23J7aFY206Tm+KxHyr1SBbwYHoecDr3oZVyldB3YtKTvMK+Vc/d3ffNP6ZPGnhXSAyLDo+mY4cUf YKVP+QPG487uruyQG/UQ4PRjsisjsc0tHsW/8nrNlQdq5utMWFmyhzZM3+tmuQofU9YiOMyMbqCg UF2cnam2EIqkFC67n7naWqLt0PNRbNjqGN03TjDApErBcMvEdUWHt5xey0smtiCFZbjOrKTZWUAq Zu7+xQXRTRyVs/BNm7J+otn5iHG3m9esC7jNGGCOdAsJaFmqrbOSafnQmdC143X8zxdNbNR9lTNt 7O7IFG+3KC3aKmfUogYCD4ST32Zp4BgoMSGmEmbBFFKK/jjkThcm4qaSS9ycrJRWmxtw/weL23u9 13sBgTN9aO80Xo4Q8OUXIHa4nQZMO3xb/oVJsjGMZ5IaBNNbJBb7vpjenFH8RtYb0SUf1C8ThXOW S6i42/Bt9eh5MWbXdBBbgMHv66D1sXQ+s0dZ+rbqmRvaQMDLwq1hIQvdDZYlLdl2Uw6+IoQlaB2l 8pw0GvImrX9Cs8Dc6+bu+HEeWve4+NtAWcu372Ey/ouZXu3aEFeVeFGXUdY/cls5ovL9IOYEXg/i TOS27TCQ1ckdz845yjnBjSqb+Cov9+F6mQuOAmV9XmF27By4UmXf4mDMnQw508wJmT0xrpzJN68C nwgtffqV0PqkfDfyF5fnHmga879/WMIV64hN2MKkRCBZbKCcLymjmMfTxLPzfkK08uYFzrfOrt6+ PHo+ZUeUEzqmbIlwYV784iTeMDpwb2+1agQAKTtbnS1R3ldzroafODbLAQiyCID9EmKYu88iSFtv HzdA7tM4NFsnOQHeq1PSvxOIf/nk0jcn32rZDZYJZ2GvWM7HnV4smJmn12mlWPDWznZzt1MJM34G MIIJvrLlpYoFc12VPuP9aV3/lyoW3H/Tzc4jrwNwJbRvj2LB7px8uxQL7vd3rx5WTooGSX4h64jL ZngmU9I5oFKwilJasoQy52QCrGe3j0lll1gsGBhSmNAxwLwqD6m0TK/Vu7Km7copIrrPbhwdJBcL TkQsgiyxFDhM6HkfU9TVdG7hatmsP27fcyWBsCJBioecrhYXcKJ+dY0riu1bOSJrHPJxaZEe5ALZ 3n70ox/N0vMLOHdI40bmYie5desWqU7i6lNQK3hLN22JtpfRwI9IvuuubW/fTS90F45LpRZBZJe5 Ld7NHotXsx0S7PhxEtVsXYdhLN9XvbLPBq3QwfObUb7rlp4YeH53jZjG3ixs8tlbRB+6moMGgF1v OFa6Ow+G2/g4niuhpY2bC9ljKifFxP2Il4IBv/HFU1D0CmM4IZQnln5JAqM/Nk4NOL121wbEity5 scj14kpoIYGrMxso5WR1z4GffFdQNldIrXGd2Gy7s2L3I50D16DYrXDI4kpQ6UAnevNulTTo5Xfp 03Xezd06unjW8oDFFFqaYhahStUQy6aTUvF4tDy7dYhdxnMwgKxjQofQSQAG/CxVOa913FJYg9AK yowmTI2cix6Y7qRaaNzRVDczYQl+PwrEJOB1tFU3F2/QwPgWKwXy/bGPfawXvmFffytzlTCkj+RM HP8ebxp+Lgvf8guAkguceHISVGH8RbVxGgR5sXkO9OYsSDOXMps3W6s5abmVLSh1Rc1J3EYjLT8e 39A2q8a+u4QjZGmHDIfB8LkD6QccP0nFr5SAz+R1jhDMapYFQSZFcE0Y6m6ro/QNJF/FiTiZda7v TZXTI3ucM0L/jnZHrwNWYo5Se5+7r4HSvJb/9GbxdFwuhJZOqZiyhW/f5pqTzgaOMadI3D+fuJsR /mZSUHazOT5AGwRWacrLlHJJwRCO2wLmizUnQeqJJcImhlcm6WZzNJuOlDJ0xeNkKjHhMmVp45LI G5coW/Kt+Uk84GozcenKFYjQrMTVxZqTSgCyueakAx8Qu0ypEjyMHq+U0uh05a4gN4JDWX7ZwLEB dUFirqMsE8bj1eiPZaSrzUABuavIzkZ+H/dJeEZg8nPHPYQNI2XJLFOKE4NueNizrgcGRflD3w16 1SMe8Yi3Jh83+HJ578Rwa4svjBiDjjIGALng2hsAH5d/SClLIYUSoP8Lm0o4TJXEykoigSgMaqQ+ qGQCSeQbJ/V7riRYSmrpphKSb0DCTYHkOWQQlPQXZOpIAfX07Iz4qpQT/Ziqun/ZphK4jlD67s4O MFRCS5YMzNCJphLE8bWrVyv7pMHw7IIccpVpF2nJqnk7mUoQ8FySqIRW9rrZLKUliD27+ZdvKkGG JBpCYUIsFSQ8ZS+snFe6qYRUKdM7ZSpxy3WKcHjta1+LvouF5IEHHsA6xGq6XBw3Yhpd/Rd+4RdI 7/eN3/iNbPtsGl/+5V/++Z//+dysCQEJ9EsyqR/6oR/CfP6f7HGdxWX3ahOeNvmkoDFdSYpVgo1E IyWaPCcJD/ex/G5h9SMAqlt5C7+XndJaIQdJkAqP57oskxS25XcYUwBA48CBmxJlqBNAUpcaFmJt KuYaQyZdJ7VfT9BXOS/dfgCAtG7Bf7XTwIc0Jqwc3Rv0exeJxfY4k6cC4LdDEkAAT5zbdHU44UEV SJyXDtNW2SihVz84JrU0xKZ0aek5k9dsIrcYYZP4ynEvUFPntaJllkho43QR69yWpAgOZwsylrzq Va+KzeKpcdzshxRioNjNC1/4QtJw/8iP/AiFgxHiX/zFX0wthVirQjpTb+H5z38+9czQ812mA4Rf O1wGtVtrdmvVxUwlCBqN/dZuIn+3iQVcmBM2Yeigu7/fTlIh2/VGV7fmk569yRaZ0lOabtcbO6q0 lvDU69Lii6e2da915o0OaQISnjaWvaGy8VS2Rb5vD5PiZ+lqj3CYuAjb+t65grWb4Eb2DvbI0Vt1 bVLcslW/ur3XaVWr2zTu1hrbaZTlfvP+LI1YtdrhYVKmewBgRnvzpFUgDJCOO+HMBUE7k632OEkp aFPsj3zUCQ863J4KylRzixDb7Gw3q8NnRa86GEhCLDfjr3X2E1lrjyJXCYxtMgq7fXWuf1oy870a IYbVBYhp3Kk1EHElvDbJwSEnSAW6EZtuHqGKQhxQKBgo7EsZSpTwzVso1MJH/03f9E3uwUA6I/7J 0cpJ5Nu//dvpJNScxCTyOZ/zOU95ylOoVYZFm1doiZX9la98Jf9+/Md/PKLn/Oz8amdXiWrYjUak PphvUQ9i4zzcMUgx7C0ksrm8Nkxa7q7BhaKwzIWyZOeV7YpqOr3zcw6S44v+drfb3u1iR1b2BufI aDsFw1gzlCuZfrEDNnT2jBnXEmMsmB7HBmnSp9jZO1aaEvaN43PJ9TGNDJ1E/BDuM5lSDd3pCLXg oEWH1KjEwm7qgKyrgxGghtG1+SssK4SbkgR8RnFOTKAzu9JCTZZt6qzn0C21tySZFDljXIO2bLMm tXxTHjMenGyUCRlSH7JN2bCsx5JlNuNGy1pOSXg5ZZRkOTxeczJ7lz6U+Hg+752f4cfrXjmAOye6 27GWo1Untj8gYkuZbVbFlboRz2O9B6fnO4dX2D3NfJe5ZGJK0RvKBP5LmFDlV1qNQmHGEqXsvrv8 qMNRg7LlFsJYtKGjiJKUJn9w7ZyeYoPHwm0MMoMU/BEAAFS/dCNjI6CMxruHiyvvKyhld9VAjliL XPMQJo68FOdkeVZFdwthnvSHIMprj7ijeEEKsm+Q589M9opCJXs4KViVLCWjzpJlVt5Jh5bL6diV ig4Aj3kuxPhqxao2bB3e9mDbDWtWGWBGE5aM2EPFowp7g4sdOTCnEzIu9s4u9q9fU34Rc8y4nzbu nXtHYg9yy/RHXgGHtMkLEbdEWdrLiE9IopWSUEFI+HaxahYJb3wKvZMzEtD4fVT+LNztUJ56RZoL V/h0mRSh9LtRacZ67eToWN6v7vZWd+2uRs+IXOYFk6A0U8v3Xd7lXULpstSoEt5HXf/oj/5o3kRp B1AkNbF9dEqc36d/+qc7CwINWjbqPbKb4jgYTDBquwuYkBLwTrFKNhClsLD6QO4Ys5JRWVpJhfUu /ai4L8V+DEkEV7GLqwqGZY5Z3V7Vx2pEKaDKWdEmeYqjlrXm9g73kWFzRKRKU1phJ7G7p9X0gq95 5wgsoOViurJWWRpgLQCrdpb9ODEX7bdoqvps1G1Se0vWE/9IvC0+YVK05bqQxsCrVkIF9YHbymek gFzuGYNklcXSfpTtSB63EEantoDGJnU//28hNTzPiP+YCyxur3Bc8t1w35riI8h43pXHImqvOiMm a4NYx2greQzeLP49xhXAc3HYKGul3pr6J6KUQ5LBow5pyOZq0ra9s8P1f2VEWkNWPhcVhCVVcVMk b2l0KEVlFmiqQkXaCLUdcvPFErEuTIp5/4IW0uoyixIk8BNjUmAUKaVJm0NJeqTfnsjnks3LE1ll qCaV8WibXCXdHSrLqLFYyxBiP4xOAjLFvTi6+MRdVWsoxUp3ygoAMbbtiAXKLjoHDEFLjONOR2RF dHoVmIhPlHktZ3o4Xu0jyhrhov4pvsag6lJ7LfeabC4RJ1sKsvDDiL6vAHGbC1NwkUoKrF2zpD8V FWzdLE7weXsNSwIDtistB+1DkMBWnWc5K0xN2rtwK0TxD5OShIkX7BJlHam+XlSKCG06BjVe4BZO bYJom57bVN1jY/b7CBG0Tlkemou2vsU6ZX2bgRlUzW6tAiopZOEoQIYIxdJ9zz33oI5crgIOveA8 +ZZv+RbU85//+Z/Hiv285z3vD/7gD0AZfVHKPWjcfP6f//N/xpDyq7/6qz/+4z/OL3556WUvexnO IuqclXZdKoRO2xCl2n/C7jo8Ot25frhh3w5fXdx8uEUamr3q6Oz5BTpebWun+pSEvj8dDFtXkuwq w4ePWtcPQimNDTCPz/vocZ2r+ynzOn3Dg3uPvC8lv08oFlzZ7fj0ghWsgtNVD0kaIUHn3qtVDfV9 /+Hb7Su7BKBWNgars0GvdZjU7Zjyr9RrLl7IXDHEvDa8edw+PLBSuRXP9KxP5dnmTrVdhZCa0a3T zn1JoPZuPtTa2WsluJ05cIyOzrr3X6uCVN9Tqba5t4PGt7kxQnl6+1Tb2H714ppRymI4TGFC5O/Z W96w/6h3qDroC7rRCQffLcr1Vs4L1Wp6fNG8lrAKxtP+8Vn3nsNKUwODjm+dwtiulm1+cLuzwNuH CQCgcT94q3vv1Uzd3Ngvy3A2mW0fFoTGfDzpDfq6d7f+XUQrnkmEp1d6oSF1cC5dLBjZzzsf+ZEf SUTh93zP9yCsn/nMZ3INkk+e9axneQADDzo1RpmnP/3pjIQ5Bb072LUdgmU4lfEwzVrELFPkoA9h qms1tWhJZCAnsCqy6nsmRdOUlmJZ+kyyGZomm2aOp9v2TsfTXVY+U8JS09yzKMiW0bX6keq9idkK PeiAnGbjlrcrSx5eDcOI2oApLkcdZBpwZHWP8IAKjybZgpWRONE5DLFM00wBQEhdr3yVerC8KtXQ iksIDE+jrBUcSIFU5hDmldrWCoIn9TuvkfcgqSWA0qfnqq16WIaJflTsXAoITHtSJ+W9YQYuPpi8 MKdsRjjShjyuyNi//bf/NsV7Eb+xKzHVxu3jenisJ44BHR5KyZ9xOKBHj6Lb+11bF9z8Qj5uTCh/ 7+/9PYWL6t6zx7izz1q+XBVH1IG8nIuZKXuGYuX6tZqGfkA0DK/OMc2gk+F40udEbbnZZPiz2oDZ K5wXW422biZboL2K6iqlJ2WQstE99H4ZEru4YwZBE7RhdC/LIKhc+tlZipBrWV3sBOx5wEJ7gv8W KaqtaBPD6VK0TnNuqCmWWaJjyxcsE994qqg1xrexNKJlnguj62Mrs4l2TDMlpDbhFUa3AvCL9hnw edbPbAYBV5IndtvFz826AyR0cVgu5KrO576gSMi4opfD6FmoxwJayzGNdwF+qGM9E6qaa4lb81hj S2agCGXPeR9DInuI3ew23iIaVYknlSTER9Q3hrgCcYVeRXUYIheTpRnyPEomDpeqoiQ3cFTj3M68 onWOK7tNpPDfbLhafdjv6djuJZMlvyx+Z8EngsqMzFoFyl2Oc0zzyaANlPJX/HKPpoZHRMd5AbPg 6hKlFpO1NK3mfCgSV/aECHjQNTXT0xJ+wmsaUGH8KumBXQdPQ1iGKoJgISQ58CJ7WNGrqqYVqEAU uaUHwAgGvTTVIqXMQq/hlTVAhU2JMyYN0UIIlCiVcSx8zioww6beX1DKKJtzNY0xAY2oJjYaQCt6 zgyAOaV0cQ/+9Nc1qTpXkFRY0nIrZln+FkwuCZBdt5J8obSxzJse4MTrkIPSv3APvgd5s9Y8dPzG N77RC72DGXJzk1013Jy8nOBeN0bl5wxcSjKV1UUlrcgYXpchrELl04KYU2wOc2GFDqFLIpNe/5Si uligpCRaMpAYSFRcyUaTtko3QVILizePnHxLKgUixvyjfr1tkUzIBHUBA2YD6/fFBPKxqJ7A+vbm ymBoXUVzE6Rfn/EuDSlWUtbX7BwP0u7+nkbMlpN5ixa/m/5u1jFtmVu48dqy74eHbuVLtcc2Rd+J ac86DCPG08nQYqBJL51SJdZwtfEBBm3e7r1YtBU18v0tH02gksaPFEu7Nq/1KqplaKFSDOIYoWNp /cueTLummMk45sUUZYKMXKnLUGt1U31Gtn6cdV5tIWu1xDYS8fh+lWDIfAwFSrnUynZvEaJ3cSa7 dMtcc7oLxusu2AwN9hiRtdOGSw/52BGl7COXJogQdAIZo6k7WqRCoFRGXrQHrm5aBrdlepkUyRie mWCqUU6VyCNXQpSVsrErqcrB0lfGWqtSsnhMcMcfMDncqTpPru82A1UeePGWiWPtT6XRDVHafAxX KlAANuRVNvQJo6vUVzEhaa/lCwHz+er29sYn4RGooGA89gKVhhtvZ02CZzsDtwYJbO+0LLt5kanQ mzuBtQXrWpPCenBxLGi1Ve8TM84dLtnz1wbS8BXuQ0vrr2vuaMmE8xFF4lfe75DgdiDe/OY3P+1p TyuRRBncLYFZ6fPlP1kkiSH6vHt2fpu9s9OptttiwEHEsK1VAnDZXCWJF3AktqazlHsiQHh0++jK 4ZVCeMAauHsXPdgupewDhVpYDCmJMhCFmMVScAVQp2enFOpNuYAzGHAH6OzqVaVrr3zwpnCtRtm4 Nj4sG91smk5TMqu8nXKVnJzd6mzvbLerLbzAidMphVhMOj1XCYscPxsFPSqxmp7VBMSent28cnBv ZZ80SEcs3dI4hVjscOTxgwFSLkyBq909wherDVbDwQALRgoAzItVQH2G6ozalvqC9iX5xt4/HOgm 4wYcsn8gM5HX+CSRkH/+53+Of/HSNu4UIm1uo7POKkClRCQazKSypAKi001aY1qivyT1exkArGxM hVrqg/oJLAUAqRu5QlfZXsbNtMZ+tTcFAitAlWaydLKmkUCn+MSWGbckAGvJIHHJVyJK2L8EqGsu ra8ZpvJokvFAVq0uBVhRKmH+xlVpZKUlamkia0kjTu7WzB5Jj9m8klr6wSLRg5W+DK3mZBqwTqy0 1b2St+3kVDEWezneSCK4cSuiaPN7XEYndREmYXR9I3YMNn/iuMVM/uQnfPxCHHwWn2dfr/yP1StM eOiNzZOeo27Nnu75Y6LMODQYovGac1J2kKzN6jEy+2ho6eHNemvpsVNlntPKMymF1oXmApXgYDdD 50/UNOs+S3YzmwNtaUCbmIMRJpidIN0xVwKu0N7zMdkd03V4DcDTQBbeVX2uQoAq8K7KqbSA0y3U wCqQsm5XvRH1TiusKu5SWA1w/jFtBqTbtzSqq1Gfv+/bpoeXb6CUNw88kP0Z0J4xwmJ2BirUknMs m2kAxH+J+JCbo7hlSsRaUCriMqOXJRldQkABeLfyG3FXLq6s82xFzFXU2LbZ6uWFtUppQwyxq9ZU 6IHe6NTlU2W3dEi3lc1ogIldq8CwF5bVyheFK/NBZDzg0K5asgKVROfcPPDG0dTyfFMxF87J0RBz aoaHJXlAt2DKna4xWpRQR4NsEqseWs1Nxl/7tV/7rd/6LX73dHj+zh0ylTAjYroR3B/zMR8DQMoZ htnLiC+rppWcLXjYcheHzFpuBLTis5yPXBxvKNeLuYtiwfMxweNypcoQCe0s29SiWHC9OR/LySYD tOctcnS49mvOjMh/hUduZhY9c07S2P0Muf0L90Ts7rO4C60XZUSycwYWTM0ib+8XJXIXlgsLLURF RatYsG7c+J0aN2rudLrcDqDagIzR3IjZ6aouRA6wODgGXk62LfdZox67wTtAKwdd1J4v7KZDZo8T n01JWlaoixoDb4G7ShJnicNxTUneyv0bUJdRSgBp4gT8ujjICMp/l4oFhyRZSI6qYsH4j7BsKnU3 l0dMHhbcg+bDBu1+LMByLTOosY7RVe7HsmMWDGRJAWdocR6rEFQ/3E8x6qQ9ufieTXV/tegeBM/w SFDaZONWtBUmZkUJ6/IwhmzboMzTyGjEbbd0VUOOZ3EBl0Ri52SgVAY8ZJnXKTytg797Mope1hKb 4WERZ8jyroK58rdHlAqFkn2Ccv1BV7/FY14Zu9dliMvM/lNaSG4aimhAFT3bQL0JrFAoFuzAawH6 dqeFWCjXu+AZG4eSm0r45+vFPIHBz6lJCNUCGWKx/vEPyysWLcMSpeT/99sxpm3A0bEjl6FL7dUt Ufd2GcUrJGi46GHgSCBQWFkiXkXkbCXoJpCLKuHCboeYlEN9lPe5LkdLcOTS6uT4mOB9nB/d9SZi YEBSU2Adaw/AYDChUjCwea6SOyS44VpymBBV8nf/7t91Yvu/ANcf9MEIVsvABDG+4t9ZkD2sYAcK tHS5tvYhsOThYy4mNfZy3ir6LrKxVKZ5y/Jxcxd0UwFc2sNP2Ex5Km+Z+rzI5YK9rDKPDC0x7dG/ 5XiyBb3kZrHJ2lf48W6eNq/vK65j06NePEaT3FW50rP6BZcvMNnBvhC77O5bvGZ+VPgGDOQfZltG gcVNTtLt2fk5fOZp6dc+5o8d9fr49PevHYouG4Ok6Fbumv197aO265fMMYGv+IKWno97HWv551CW SfFvfBRdBzCIwsjO6VXCpQrU89vH3Bejarj3towHEyz6yp0Hlazl6HFXVYrzAFAReXu7ezbTIFrK k5MTzyrwhlq9htulJaZO2DympySZun5N/uEqyjIpRJuV01w7uvow/zDQOmutHD0QC1x5jlM2xHW8 7T3wcPmQZYjcrLRskOmM/aDrRcOL8mV5mrDWFbLtZ6bzTVPzKGxgCEwooWd+NQtIWSvHnNWRTiDk vvvug/E8CfvlkkxtFBPVX/ou6nHcjlA3ees3886Hz/3blY971a2U76Jazeqm1p1fbvSQnVIzH90i EBdravPQDqG33tDSv/Jm2QQ3ti72tgJUx1A2Helo3J+srBW7mK9hd9OzIJ5pWJtgtp7KAC/RwvBq EYcWslIxvJPGnR9OrARovZGBupqyMRU20Mu5INA0hbKmQiYRl0Z2L3dxB295ZoGVwnXBzdPPVkwa a2XE8lAXQ9i6zpe5ejUb2MqzLAXEt2Va/1qA89WdD7uRspy1TAh6bytHD8QKTLiBt4NMdJXLNYnK J1NDMrG0uAm58kXdxsyeTVNbpizT1KVfezaLTprhjUSfYKPi8ZzGGbESc5VUy+aNLUAfF+VRQslL hRaGEHdnK3D4RuSpCVZqRv55SMTsf+qgtM5ExNyoNtAbKXAQpWBem9RnJGFQJzAbFgy64Fw0VkEA TmdSCqzC04bR2e5AIv/y8Iq2kPUGKrpngiEf8YapOQY80TC/WOygju6m9soSod1nVqOuEoGrypLB kXo83TrocFBfp0FocnkhJeDcPLpjPuSw5k8PwF+HChqgl9Gt7vLmudEtpDo7PzmlYsoWerPphIKf jiifPi9q6dJpey1lae+H2ZWjx8h0GkFZP/aum47TiN78LoLn5l9HWf/KKeu7cgG3Ri+L/cw0axqg QtKGbl0qka/SwsKzpeKSyJHvSGCJlk7oYVU5rvjTk2AkUtZvUXiREE94vYGynmjUZYovtwWf8zu2 D4vtcwzwSzjK6DyIuYCZWeC2E8JxG8O/bnRv73y1cnTHvIXwK7M0/3rZT15cNx1LQaN7JN5tKUNT QVaJZPKhcu8Be5VvGjGobuSc5FNzaN3c7FTwvSGGJCO3kdW5JT720Rgp7Ot9UWl2SX7SDNsyqbCx ltx7773w0nu+53tyzrij4YBASZKUBx988FM/9VPDAnBQA29t3hvACw/48higTZuVuGY2OTpvksOl o2s1LCW/6eRWM3GTOSlcAIEIMLi5SimN/VYRT0reakZAaviK3byvOm85R2bzym5LZLZFySnMqVou uv0yPDpvUV2JW3brdw7noVAodjNiQYKHzfm8YLWghJZe9EWLYcdbBhlXmmAQ4srMZXknCgs4N8t6 505WFQsmyRRRa+xU+d2iZbAdABALsUCsC7Ll0fncw2ODSWGdLPbPmW9ICr9hP3Z4QBTz8ri90tBS 6zL2Uku6Pbl9m5wV1NWV1mmu2vgeo6982bYtkRAwYMRcJ7gDuviFlkqbU5WN2rcuRgFaH2UdK/I5 dPd5eRvwUJ6deXicBP2z887eboGyxrSxScEx6QYBB3XDQuCreHEtj64la7s7XUECpJjbIdfRy1e3 SHBygsTYJLiNavxwaQ9B63XmyqBaOYXw8C2sBa5MyK/Qmv1z1598dZdMJSwiEK40NevjFOkEOw+y G8FNphDkJxEm2LLuqOCGxmQN5CIQt+FLC/LtVEhhfPOEzFuNhGSh2IwAKVj3Nog5RCFkSIxi5niR GMfN6oK0ifvB/PZ5/XDXkkxVPOmFFLyQUgoGaAa6sPBWDa7vacmaSTHFjvqDUX+4d+1KSreJiAWl vmhTon0BlSWUEkbNaixa+TeBPDw75x5eYiEFWCuRB9LjuGXjrtdTuoW3EZ0pPABiT2/cOriX4OJq cqXHcYPYxGKezoSyXCfEeiL70FIrNzlmMu4PCQLqHiRlIpKN+0rSdQoQC8ZKTOgehXUakqOVb738 DZMlN99LX/pS4riD4L5D4YC+VeIYrSb1X1ILD5ZIeVB1U+jq+3ClszHeljfr2qGlH/xTQM1UmrR5 MXoiAH5ErVQ2HcKU1eItXaNMmZed0JNyMdObH4FTuk0RxGGRJIJK+w3H2xJUHrKXAuql2iSC6osu nV6Jq4BuZdC4FMQJjaFpIgB0luJG9jHTFyxad3rjlAuDDsDK0wMfbj5ahRWkALN6/TWveQ37RAxe alrXBMxvagKgoViwG+n84MMv/qefejY8ftbz84W/uLn9hBzTBAGR+lJpOwphv7IgR0GwrvK75Fr3 BPOiH8Md+PCsBCbUBiw1LgHPu2y/7KvZTXqbV/xKZhKx1CpYeMbngzr1TKN49uX+NyN2GXgA8Hn5 jDbgVgabpWLB69r7nVg3/xXQpbnkP0ZGlS4bDlsdmS8rHzfFuqFm+QnA+CmVlssAxG8FyvquXElZ GQr6fbe0lijFnxJn+ezYXPoXfXkpMBR44FqRsjGqYWxUs9Dtys4DdUIV5tL0lzkhUNanuQG3vr5i DJTbe9i0TWFw0SNrq3bPfLIrg8p9dQfEbgbA7476NrOZB+gzpEJa1zKIl3XLsDQKU1GCRu7HZ4kf LIqwwLUFqDhJuDl+JaUCrX11u2MsdBaWfKVq5cYWxsJWQSfI7kundXWpHLZ6p7HDHXAUdgn/PMyK XzjccWXzjhULrpE9vU9Wk5YyDqtYcG1rW7kC5JyEmWpzMvs62O7xqNQ3fXdxRC9vlSVDNh0qEUEu BZY3tJJmEZyTma+jrjsmlrBH0OIU2mlukwfSbr9o/c12WtPosm3JCxSGc2K5RI5hWG4fWvocN+gd Pn33twRyL7d3DNCAZRMn7EV6NSLnpA1nOSLI50ASGAAl0/rGe8Re8tQJ4WjnRVfAGdTNqc7u/rhf bpkE/kmAMwj3UssYdd4/nbsn0xOuOWNkqCgWCwYqQl3FXZbEm66G08lQWagKqHMYHMiSLr+Bsi70 S5iPgYkXrHe+2d0CtL4WwnTi9orm4i6CUibJQQ5fwgS7WZShuJQbEkoc50H79gTnvAuszXxFe/eI rIST14O0cSC9txjaEuEC6tYtw0BZhfLN5p1ma0TdU0KTpc5jLSF/DluOc4mivrnHEabGuIhjV0oc sBKlwocuZGhQSOxXr2PCchP8htMbb2E7wjDIvwwHv8VX3i8Rx80wjOdSBisnxiNUDz6kwEKw/YtZ ++RB6tHAsx/4ocZt3HeyWPDk1gkJUIjjXrdow+eXsANyBWY0SsxmwF6FQSrlVAvGWLh75vGrfCYP HTfuOUjJKpnuPEg3srsLKxED6eHGrJhhf0Acd+X0aZBo44ZLmZf2gpRiwRcXLLaUljLFYuVfRLJv Avni6IRjhPu7Nj+XTAKTWoWZNciSTDEZWbHg6U5XTtfNDwrE2a2j/XuvVdylsF7SbdzQi+Q2h1eq eQBc+ekkxQqkXCW7uylGGGzc9LtzWJ3Bn3kdHR8rjjvBEuhx3CU3g3vLNltm6PwNb3iDEqXV66w4 OsFYjxp0uThuegEFP/zDP/xP/+k/paQk2U8onvAlX/Il3/qt34oeHSYAKl/0ohdRhZKyCf/iX/yL n/qpnwpnH4T7mmLBVZwSfZ+YS4A30L0S81ZvU18mrTgkGmySydYAVvhQmnlTFXgSkuD45s9RLnFe UtjTAFCVHirzJTyKjUjrk85kuU/gbFpKaKaV+6Mx4RSuYm9+wFKnTQ6/pEdxBWlNada1Ciwpj6K4 03LNgyjkUEqfYq2Nd1niTqTsVwWfeHuZdBJzhaA/iluS8KWrFImzwlyZhiuMX1SdWXWfacVIOrmm kRaGSaw5yTDigbSJAW26/yaeAJKaKMDHPOYxj33sY/mFnK6xYT3Vxg1joS9/53d+53d8x3cQtPTc 5z6XIBX2MbL9veM7viOqZTiOsSFQQfg93uM9qINDy0/6pE9Cz0fpJp8s+8w7v/M7O3Cc/TnGc75q Ek+t2+xcy5tt+uHe6nTW5qIpkXC8uLkxBpz+UFd1PeF66Uc2B2VNV5Us4D7rtwGACwXcR7ZPFLcV v2LtdRQcTRpj0kYrOK/8Ux5lvtUb6ZKCurKs9/Erhc7ntcG4PppSxEh3yZWdPLMkemYFRS76hzr6 Ty3q3BLAhk6WgHFo6xS7I20yGCihy5KhL36wAPTGDeaOkPXPl9CVN55vMf3+SBW2NuDfO+GYNZBF R3HLVZSdUQGnN6LoZUVL+qHbPgGLdo1/GdqcsnJsYM847ZHwWOkBjLIWjleenfPA1mBixVuVHXwt paxljSSdF0NdC/BJbWgP0+OQoFcAMMous43zofohAUNvTAx7xoRrOnde2hqMlJRBdtnidAqcoIk0 6JP+WTI++nrKNkbT+ZD61s1KEijPOxjAmRwz4apVZqt7RhYAQ+zm1T1jdbeoQx0W11KHvjp0g3w4 qfWGrYZdm7RmFua9krLzrYuR8h+IWyooO8e+SklbfF2rKFVebmcDXUQyQZEJh+ICzyiLMOlP6pOZ CjblM1Ji7uFEAhBP1UbDoHtoJC3tsf1VcZOkD7mEqQR1/au/+qu5sEP1SIrgoEFzCiAHygte8IL/ +l//q5cuQ7+mKPBnfMZnULsBCU5mkq/5mq/huMTzu7/7u/xL1UoSg3Mk6QzzvMtuirU8Uxsev/1k lS/UEvJVtCdJhUK4M/tmrPxqj1An2Y6JaEMtUfi99Wz2KZkyQ/+hvZetw7pHPmhZ8F1VkTlPMjVo Li54ke/iALslLKdTHuQqI7vsdFn3umBo957V2HY0ZUUg/DyaXmS7VGrjxnCqKzp5AzO0ZZePZW20 0hYisRnl6NasgYvuUPBLwNsVU5MC9pRwa5jPHylmdS3d6CkdLBbttWdo19lAqcxtYAhgDmZE3tRe nVu34TgTQ1ugrFK1WDIQ1f2QHdy8r7I6lihluMpSamymlChrdwIkJgDYo3ECbmTTL5RSUqHFiAmV 2SLLeGF24ZxSxkaWrad4SitRym/qqCl7vJVQyDawHAA0uxgYOUScdimU1TI0fSV/ls+LmeYqA7Mp GRvXYMYG1q37ZjevWYlX2+GWmdDEvtZUtmYtRSXrYDKS2dYcG1wiKyzY0N71IcTjZkrpKGm3fL3q yBKlMp/NgnNYs1rdtmJr85JACJQSYXW9V4qG49NxeHxyQiqIrZ3trQOKCG9YH+WvmOzlcpW4gZuy 7j/3cz9HLZv/8l/+y3Oe8xx6RRx/13d910/8xE8Ewc1u8G3f9m18goh/9rOf/TM/8zPIa9aDS3wu 4JRgmZ6qSkgjpSod2+qNk9Z9hykTHR+dUUSgmRDHPXjoiANtk1stVc+0N6RAwzbF7hKewVtubt9H VbrqRMCTM6rSTdpXk4xrZzdu7V2/lmItGZ+ewxMpFTKnx2dIohQMcHducnzWTqs5SSi9yv0lxPlR uH181k8s5EgWmua1gw1VVjPiEPzw8FF7p6u1UfWMjk7l1tyvbqk7UA8fdR6RFNg6IrHM7qZK3gEu Qhqopdl54FoVpPoeAJoq5lltsZncPEHINhLKmU7P+2yxrZS6o7jmHrrdfuB6iqlgenKBBrOVsAyR g5Nbpymrmwqlk5MLikMSXlWJLpYh7JpSQG5yMZgPR61rSctQq/t+lmG16XRy2kN5aRVLWVJxsjca 6OSaaE7N5xkEd/XA/gr7BSr2B33QB6FN/8t/+S8/8AM/8Ou+7uue/OQnI7WxisToQz184IEH+AS9 D+uMa4vuF155cQOcJqbWRcVITZytdI6pIbTN7SY3Tys5gAZKBZaYuRsLr9ZVCm8rs7COqEmPb/FJ ezTX+BO7RRc1HqqGQObCNH8AfRGbnZJpnpY6xVYPnrWABClGS9nJuPieRi+Vq0+z8kPTRG7RvMgj mTYvdLIUQeydgdhEuy1krSdsnOqTIKgUDhBPKyO5p5ysfNi2U6Sb+uEgkUYsKdwEI6blhSepRdIi NMU5kVgAq0rzSQggGFQnghKiqH0j50caDlciOdVU4uEi6M4o6pQDRohzFxObNVZsNoFg4+Z3Pifq kJwkOC0JAMACzsCIb0qX4d7E5M3pRpWH8pMDSXD5tbnj+cNyl0MIxMmh1tkYa9LFoGklqzOfR9ws +h1oh+c9mRC6WVawRaUia7Y4v2MzOr3Q1dPdrgygecyf5+MzfrKjnn1F1SxShbT28soXa0bnPQUM HZ/TUic1CqhnSZSsw/g0awNQXppMJDT2EyUcXLBO2JnaZ8zWxW3jLqXL/AS6Cl0anfZEd/UGvKJ7 /6qjWKjblG0oeQdqyc7a7bhALOFqcSJmyU5m495g+8pu/GEmRPJ5hTPhlChmLv1jtwUFa3DlGCaO e9Ifd6/uaU4x5pcnSN7HswviP7LyyjK1rKCU3uMe+UVfgSKEvRsCjQi5syyHVrgFVxd9iEQwYrbT hLUeeMAg0XF9MiWXYefAkr05pYptMp4xRhqe9DBbNywUVRQIF6RzzDO6D0W3sEH36hWjXcQnESSZ oXOrTul0yhWyJ20Y3ewT82mPQPI6lGVAu3Vf4MBFOB0GQBJMc+pCNc6liW3SK9rz1vj0on3FmDBb xUsA+80jEEudF+aN90JVpou4KhBX9jf40Fe3cFUcXSaqXK6StGc6GJFIYNYyo5mb2wyEAPACV6S+ 2Otafci1lNKA4Gqg6xTtvR35h0pzL1KEIYe3T1r7u2JCM9pZLtyl0W0tc5oExs7+TrZkLOnbxanC 81BBUo4CPjN/Lm0qMRiyrF0enEgXfJJJtChU1mMb/Y4ADcCFC32ubCL0P/zDP3x3b5e8vqPzCygq PzatZIuzJBWMYruestX474YykEPCW3cQSy/gSlhDp4xFs+Ir2DTJU27FdzGcGrRYrvOeQR13WxVq zelYCYZIpyAngJJHW9pMz3a9gERF9sbYpHAM6fqJyvrKarxudLNqKj8vRyRLd7dFdt5Ce5M1/jqu fJkuqU+Qy3fHciCVdjWi92WBt4YoRwqryL5fRpeNrjztmdkOx0PDbtYElMa4YppWXBx5geCSDKVK ITbwiArKHpS/ArTm1ZWOLtxK8GRJLZxYGaVclil/9BzeXDu6LSXZSjWEZDbqiRZhiQei0THVeLY5 200JKLbrdn69xfYysoMClC5HNKg3OML4aNZFSREF8eeldhxa45Mp+BG+5jgDdIc1UKrMjZbK3G3k MpuK0S2b43poh7AWcpPADmKcVFVAl8ECY2vuTGGuRWRXwthiDNolSukVH13p91lQQoH+DwBrRlfG K0LahSJ8k7oyJrdNtKz8DtdiUeDX0WUZXUxlOFUDLq4pU0eU9Qcw+Ip/FYMRMF9auUZP5w0rE6mE +EJ/zFfRK3xjN2W0xBmGxS4G853W+UqFSTm7z6mhyges2Y7lqhM6rfyuFkS0psh9I+xsKThd4kKn tLV8pWXoRT9MO1SMGVCbD2slevluNCb2wYsIiO2kPgfWsk0LQolk2MEl4jh4LLgUaM/Ij8T1wHaD jAhhpaf88tYI7pR+17Vxp+XrXvc68nGX2vR7fWi6bbm+Nj8g9fzkbP/wSlVDfX9063anu93dqQ6O Pj0+gab7V6ptW/hUqY14JS2Gl9D5PbIZJJzqB6TDns739qtBZV7HD908uPd6SSVfiRAKkrL4UmJ4 CaNGIFKDuBKxCILT28dX77le2ZIGZ6dnOzsoO9VWIPZ1TnPX0jIinByfkDq88qTMKjy+fZvpbyeE UV+cn3H+TsEVAvD0+PTw2tUUDBzdvNXZ3aXgQGVjhCboSuz27Pi0s0tq5gTEqu5ovbtTvbiUPeOi d3D1sBJUBNzNBx+67xEyh1Y+lEdADrakcVc8COGL09OU1c3eTJX0QyqvJrDW8a1be4dXmgl2MG4S DEZkIqrGgJbhzVvKSJ6yuvu2uotlP4VtLsEkOMBKWLu0jbsK7dXfE8fmV0LKTzHz1oaOpEsuNNEq Kb+wDlS1zLfKyjkokqCyUd5AjaODyIb3zECT1jFaOfFSaVCkG+yUbjTRvnc5ElRVZ8qR4hEDqU9q wUMvjZiE2KoYpQVoFlaSDGl0Ntr8jiIVk7u14pBJ81K4UzJqU0lgoC7MLBsn5oka0vCVigFptIrb TMKAxk5q6DXekmmguvVJ/fqZpISBPMYkDTGrWqXauN/6EexNVNpXvOIVpCsh7lurNOMnHXlJSga2 uAWzSWQbn/DegKtNnW5msFv/Ag0u+hecqvgx+1WZIB4p7Vad03OrftJdW4JHq4TGpHXVja3Rvm7E Vj/nvQsmZVWmgmF1JQXqg+GAI1VW5d0aY7GJSW2WAS8NgyVuXN/GprGJw3xRgSu/hLIZVhmyhgPS k3PTV0dg1axa67JGCqCXgKvMCCg4C7DaMVELAABpyUlLh8TNHG48wEk5uzu6sTH9s/9juUaPM/O0 CmvEE7QEExYBmZeZx8a1DgC3onBoveirWtAOx76qxUjlPPSPPdUVEhE23S8hYe9oiBdKEceW5mOZ ZoY7Mw5MJv3R8MrexjJMBhxdgQFYq/JmDTSACfl319K6ZobjldxApPuUxLoTygVlc3IjdekxEx88 cNHrwQNZfPQa9jLBSh7mEfSxZWipbdc9Ktc3JWGNlqHZK2LDtUs+XWWgrrfZtc7Oz5R6My9qsdyr bHgyZtWPT084c7Vwe66nrOTJVl1VaqeTxXrZwAn12snpKbWlrH6fkLLMBmFdMClQEYsXpgYFWXFW 9iw1PMTneKdNJeDkhS98ISGD2Lg9dSQs5YWnAkDBwbBMBhOzi8hredLWn5LoFBogCBAaFsKsXQIu jwkhg7HVRmBVg0SaWUnJ1Q+je5oY/vW3KtGtdWIWOOOe1Ul7fTCg9YKDwYWAVG4VHfwqiCfNCROp 5Xrv6MLQhkf7Yu6H2Dy6swK4Yl7K9U5kMTNdX2wMIEnEA7M6EgAnE9I5NGVK4X9fj1i9ZJk6NDuL O5JDYOP50QOZVSUySx1OvGU5Ewv9Ka7WsmxvzuLmiGIuYMDfqtwR/RWZf23VbWBavhoMYC3dXTRL 7wpR6MIx65PALctdtY6y2mZAF0bbqIDUBjbIiMVd0+1tS6YhI/5ayQm0/b58PlmaJwneeHa2IZrj RjdOpszdU2Kt61BUVVYTd1LJybQpB44FoUEycGpX1pTqJ15lPnG+8ooEZNXYUOyQIVEEPOkmV8uZ RXsb58GmJSMDuOWwk08Cem1U042ySsrqj1bx0p7kxPJlyLcKsc8B4E9PRQB8XBDbBNbSd3dacLM2 iCr5i7/4i2c+85klYC4Gfabe7VSb4djsT7ADHlxJmerZ0QnU2k6w7qFxg/mDvWo9ejQa9ofDK/vV 1nAgPD4hH/dBFk+yEWI0biQXe3LKvM4fvLl7X1IAKbYp/Ll7nepuz/s9lsqV3f3KkyL6JhlIrh0m WXiPz073ul0kQeW8sIT2ehfXrieZzm+fnlzZrS7myYIBABSo7CizEYjzi3MkC4e5SlBZinR7Lc0S evsWRnZYu7pb8H/WuzhMYy3UPXJW6CRR9ZxeKB/3foKnZ4BXmrKfplRtfhBAt27duOeee6sa6vuz i3N27pTVDWJZiSmrG/F61jtnUimsdfv46GCPfNzV1ynYZfFmcz0wZV4o8siBDdt26ERVSqRxF3iA gwjZeRLTIcTw3Gkbt+tTK3OVyG+bZgSTp7vqJBsmSa0BJT9NeBQlkhabrLiftJbahO0InDC+2UYq RaZ3NK/ttpLzb6CXJWOABCBJ5uDZPF1HkMEnCQHy6W+n5akAB6p8ltAvbbabqWmj00kgTk4kFraX VlvVixIeuk1kQjqz2Ivqhz45chLVU91U4RNK3p3SEj2yy9pKIIGBGgLrKveDS6zu7SZJH5N4yxZs Wst5vZWciwiy2sEr6VlRGcD08aSX1zS6nIXlrR6JrYmjkBcMLD06ZKSw4arzyAZ4sFclui8MhUlI TNlgY5AS28tWEN2w34RkMr6OSNeS+qThldrtmJaUNzm137R26d1dduQUUGWdeNvWxspZpgwdXiSZ ZCplLXFzGl7TmNXWC2Q149Jf5oN9CCa8FB5Shr9Uh25/SOmWNqktFQKY2GVWFzClNaB6dcaCZFgE 1af0saLNHXJOAjrhgNgc3+/93o+NHe07MLSvrs3Jgt1aRLNAsE0ZEcE+OVzOBxQLHneaqBL6oQSt ZQ3moaPYnu0AOHXdeLdM6Rja5W9Lr8S2rZVkKQHv+Z3dqMejyqQEv1ukif/bIRTa0+tg6R9Na/tK Wh16djva8kBhXqXhltvHGHBT+wZuKkmiUvtAqUCs0uhKSBIBGzatjLK4GrnHvH5rcnNwIMFmaON5 rZzRMl+Vmq1E3TqpAUnIbxcOhcGU6cm4dblhNuUnDOHAOww8oKJU+HQDZXl3ee7LpPFV46NUejvY vmPeLrX3dSQ4Z1P2A6YTQ6swD3PSldgy4CqFr2LEboa2UnAH1K1rGVPW8mgqT4svf+f/wpoi10jx oiaizG3oDmeJUuFDJysNYn+AM4YLvcRTTsDqnbZxgwUu4Lhz0heeswj/phQLtoOFHk8o7ry4QbiA yPlpn6tlpCsRRepzS/ezKBYcv+wAbM7t6zB7LvLlwqNhOg6SkxzbllcNX4azBHwoMe5MJi+WQ+qC GwLbBWP9X0EVw9p+JxbcjpnSKAGxXqcj/rbUnm/Nc7U4KW/QUJg+0MYYWJ57EJeE4NgNp8IB3Hej 0vKW3wmvr5eB3miOpPMYsaXRS9N0SbRhbTgqaBNq2pYwWaKUC1kax0W740FjcwfdDkhJj9uba992 X4awy/gUGPDs3QJtSXCvo6wjdlnXKR3enWMdA5WSznfQuKJIGbeWXc9drFjD253tOEDAmLZwdHZM JhYLpiWjh9XtkmEdH7o0hDQbtLdA2XXLsEBZ40nSxcCH5E/3cQucwCfFKq9erzkAWWKb0IMvQ/4t FVLA/1Q5hZXy7U4Lbljn5S9/OYlhP+7jPq4EUHpNW7kvTk8P0+6/zI4uatuNrZ3quw/sfuA9pThA ekFV5sh1f2z6mzcYR4WXLosrxWzYk2a3zrau7W0OfvDX0xHLvMBtCgAIArpdnVd9CejLFFKg+khv L+1WC4iFWJWqCjOCsjRLmdfl8v0nM+Hw7IKUNSn5bWCA9GLB6YhFviA1UgpEwAMQN6WsMJvPxdHx 3vUkB/XbA7GIQnCVWIc6kVu0DPsDYtF2Dqrds7644KsNKk5YDSuLBacUUtgsuO+QjRv5xUIC3GVo FOqb4B/3TTiFBX0I3QZO8wv57fwNsjJ8ZRFNSb4mXkmcFC0ZvVIMBRh06zjNyJ1+EHMVJgUD4SCZ 0hiVJBFdytKZEHzig7qyWQkAoLoKWdmSBpstdXEPJe1pc+ccvhMdLZv1x9IofkhPmZcbYVJaplM2 SzmQ0qmtgnTeTiSWnxETu03HVYoUXizDxEVorLVMrEqzVSV274SNG4yw75F5igs4JJlyGeFF2xw+ FN7lE30Muk5nduII7TdV2sbc1h9RHgEbN/JA1jcy/WIzyW3cDI/B26uI8rhe5sdJ718H22hh+PEc Ew2Qexx3fDLi95JAl3HGHv/KJciGyXo5Ue+ExgBMMLUsZwYOFuHGlPQV8rWRXmc8HLWv79NvwI+P Ffr3X8Loy7YCN/iE0xyDeg+OUtBS2h1jSnkD32l8XiWJU0mpso0bs+94bEVoZYRVKrWNmRpdf3Fc rTxsOo0AjwlCWVchA71KC8ZRQeNgrdpMKd/hguFYJMp5BlrxB3V8Yhs3yXkYMQT+UzYU34UzcTbf 3MbtkHCSiFkrppSzZUzZZVlfWlOgyHtw1uXdWDKWKOVLMpi2HC2xLFMCEcs27psB4psbKIvpL9m4 GXrx7dIaKQkmJ5aTld/pvyTv6MrnogTrdjrxal6hn9Je7tYkuuIX32tLlI0FiJKKAG3Jxh0JaWmB xQQDXhXPgeRfZ8t4Tfks3AJGm9gI5pN1gqaoIDGugqkkad8Ob4Isf/yc4r+XMjz45/CKf+uUftSj HsU8lfDFVn5c8jXwn5ul1j2+5MK/9LmhsddPoLmSV+lujZWQ1xWW7NHlLHuct7xn5xtnnbhzSU/7 1rUShyE8/mepvZMkQBu/ItG89AQqihtwcOVD6EKKZkDKJO7lWKoqLXq7nhjmYuCVQAoAZ3OP2gc0 +i+lpzQXly/xZAMG/BeXQfET2nuD+KsM/7rfbT9mtbdETUZZy9OzmQ34NuxwG0YvTSpQtgStUzbg qkTcZUqF9o6QAmZUuCJjM59ddreIRBW6jKqIT/Wfo9LH8jtiYQMozb00RPgzsOI6zMeUDT60DZQK /B+/WGoPdeBLMaeXaWafCnR0uhZXZFhW6/ikwBh2jTkmxEpKlTg2kHUdk5fYILDxcvsgCrzalBZd +DHOLKHadR1XgAJU4Xf6D+dCPnQZWJpvaeu67J+X0Li9Ag71K4HgMz/zMyk5/K//9b8mxevjHve4 f/JP/olbVGFEnJDPetazqKXwYz/2YyDuW77lW9jJ+fyP/uiPKPT+WZ/1WSUQ3X6y+RZWmDyjBGO0 y9wVj7VWFn8KTOQ2bhrzoa6mmuPPKeG8RbJZEF2ycced++g8Sg0zHJLhaHnQ5fZoW2xp63bU0J7O L1EseF7rvenhziOus43EPaxEQ7BvlhAVphPeAqvsplfyqwcb2sOseJhDS+9hJa74nG7Ra+KjjLcX IfKxHRicXVgYd6/q7sNasuYqJxZe9OiA2HWj8/nR0RFkLR3OVra/6F2wf6y0hpfagwHUpXVW/ozN fJpU6b55mytgfgtMX62PYEOnoVsQu246MYnPzs/JjVc6+fmIJU6ACflw5ZIpNWYZKutA8RraSmAQ 0Oe3j/axcecHjuwMURzb+0c15hcPKNhM2WXErkMFcMKEkKC0uFa2p9YMqRSW7SrLjYONeyWlSssN 1loGYN0y5F1EQdwD2HbldeUrGz7klcsVC6YvMEs5m3/7b/8tkSHcX//1X//193//93/605/+vOc9 L0Dgew7FzBDfCG7w5csGoJkn9S5XwuQ0Dvvh8i/+lusroYe17b0xxs3osoxetP9n/0Zua/uozPFx 52FEZbtfg9Tl9up2PWFCe/qzm/dJdx8AX4nhzXYf97AGqxlblBBVySub2jsOl5boSmC0APILwQX8 RH9kPUXdVrKBgm0ixK6klOHHk8QkQStL1BqpWurfklCvRWHGZvYOjWTlz4Nk1vUfeNtXyrrpxEPq Ao5nHi4+GxaXf7Whc75avuW7sn1WfSlas4br8hMoGzJZbqaszpZF1lpPWZt7Mcxj3ewsUfOKyK4V C9ZORd7PMiZLHM4l20QrB8lVfNuIe8jygyeHoq+Ah4pi6M6EamzYD3mNb7kO+7mf+7n8gnbwOZ/z OdSZRGqzb/yH//AffuM3fsNLl7G1/vZv/zYVy+677z4ARVhTIsfq2zZ+6Zd+iV8+7dM+DXs3hof9 JjmmM2sFlkM/gq1ZEXbZv9li98bGS8IaDDUT9PQVqV2yCaooorKby0qi0lmkMRoMQmoUO58rQYed zbaACskp5AYbtwK9F9H4kFFGHqcnQGJoK8b56Rxk+fg1vOXPI+jaC1GyGPzcFKMeDAbgdTiYKI5b FoPcGhOzDkgZEVnYQcNqT0bUBiDBEAVw873aU40HDmAKWCe2lHcCQzmIIv+GzjQOu9Fx1m7oKJgD xNTYkv3ArjO4ssQrhsxp4a8E4FktHDoITwQDbkNUJN9i7lYGURYdWfnBswpEFDOfyGQf+sPuQZGa rToZNXmFPqntMhz0l6VtJnc49CjRuFmu7BisgeIkNgawHAYmLqHsjm57L+5X6bwfpfcTNiyfhhBo 0wSGmFKeGCSMjpHaU3gYUqzmZORTlZmb8Ls8mJlWpNlydqUHDkBzXdJdcIIDrx7gT1N4d7apY5CP v0RZiqtDKk+xub0tW6XnjXEyqWJuq6naNHkHfqPHKStkUW6bisDRdIqU3SKtK0QlsYmLJEIs1CDj 6jmkqW03Iav7AzApkIQl3sPEOeEsZXlXuHFHiiVGRyzQ52w4XkdZhhtNJ8pvbjmuBawtqjzAEI5W uh6F62GtnnkEzl6cfdOzPYUnLElxMpgkJrLopo4pCzX9JiQ9i0OMt0LYqnDrbBaNwDGdSWmvNfdb e5fiKgv1Wf0wYkNp0EmgRsddxF0OHB2enJ7wLakAmgfVec1ihgwad6qpBDhYD9ScxCrypje9iZMC iUc++7M/G3qgg//sz/6sC25m8vu///s/+IM/+PVf//XYRn7lV36F0pR8xQT+5E/+BCX/Ez7hE9xL QPHpbCYSstRGJE1iDGHxd1NfJQwGIwwg2ho3+srpiSIdLBIae/610iOPJXxsttXxWU9Y3iV5TdZK zUt2GP2J03CqYqZdD1SIOy2CLlNtfXLe5y4JXLC8gZfLPrGcqGZLtwtQo85VllQFGXSAQNCcXmxR JaS8Vxfaa3dRARjJX2CAHws8XdRsMiFrcdwmv2qs8AK64lMO2zaI3ffsgGvu9LvQZ0gWKgI0VB6J GHfRv2Uuok4KDE55TBcx6/nA4tvZV7hO5bvo8gE8o6xGHZ712PBqKsETKFu8JKvPTTYNxiqC3FKd 6OLoBVTIv42lYDCmzKtxiEn86ClQFvcUPGDyTsPAOaYql/r3HlRiYTzb2i6tgiLjak6KKsL33uSa EhtkRCnlsLVTRnhcxxJvu8bHRNdRlvfGswmXSnZ3soDlMv/r9rqzEezUOz3vHshaFbfiy1jzQgCD oPlgpKXrl6pUrWYtbUUYLpd1WlZSwuhSZEP1Zh4OZjXqDZCVbOChu/KaCpS9GNKnWpaXTFncUDxe ndA4EgP57+XGs9NeHTOsV8BhCy9nUrMV4AthrOIX1FJZzNyqU0ldazZmK67Db2D/RXbAVCMLQLCx vNM7vdP//J//81WvetW7vMu7YK3+gR/4gZ/+6Z9+0pOeFG/dSFfUB6pNom4jqd3zy+6Elcctg+5a QVKjQfBjQgsVrslqXPvD3k6hFitiLfcuv7Ma1//QD/xNeTS1YdkstaSTBlKVrqy2NEhExDg8/GgX Kb0C5203wTIVTfOvaBN+ikMwlyY5YEcATPqv0O2i/1LnlGaEAwqgRp0DEnno+ba1NW9voUcjX5Zm VGgPfjS1LarVWFmdImLNWbt4WNXQyCMK9Cl4KBEiRwvwo9YR7KoirYJnGQzDg7dX4e2J9sYlyhaA 325tddsU4iLYuUGVNZ/pBsq2lNXTqnYLsRqrDK1TtkECUGTZaDIFkoiyxc7hDZsLTChdS7/HZC1P UGNxAXIyRtNW5bAl4hYgF2+jeplSIiLqOtgSM8DMDf9RKSKoVph7ERg10AmS06C6LVKKz5cp6zE2 mTt3A2Wb3OpkDcy0WFbzP5+rhKl+IMFkzNFExdWVtTb7UXnJiBY2owYMoDuHTJBuV63ExXyJ7YG1 rKVhqSwNrAhcS2u/saXVjSEu4sylBZtRVucGXtHQmyjL60xfa3aB//ULvN3sET3ErWw4rdMS00aQ ZMBLTAkDcr77egk/NObswiwuKbVjid74wi/8QlwilfHRiGYeigVTCPjd3/3dP/RDP5RfkM7v8z7v 8wEf8AEh2AURgHR+7/d+73vuuYcP3/d935cCwToFt1po6JzyEP3lDQUVjyNSQulP7WAUq0ysKErp Ji4NJmQFs1uJlB+tDviVTsE+CgESHjRJLl8sq9srXtXhXwWmKntldKojNneTIv+l4CgOoDrk2b0x KVG0AAB3NxOuNUllIo+oPA3rtaygz6BvTqYI7koMZN3CA1XdilswQBGkk+A/kDbK2SiBBHbOqKXc qQHUaX8ItyQBIHVVu2wSBti50orwOmVTQp6lHFK1K6FUjU4Zsxr1OVNANWuhbHCVjbVSCHtNWFx+ zNJ91AR0obwgWyu5RXyF0Yxu0+bVJl7XDlKVT3YyLFrkoTV5hJfN9NW92S3fl7zkJammEu/Rt25+ 8SBNZwjZhqLrGxCANh69yOO/3Lx5E8FNPMBTn/pUj5smi6RS+3re++kUL7lRN8sQ5nbC/NCkQwdN iehgIN6VS92KcOQxsQacywc7v5LPisYWZil7CdJLOMpK8arVlIKEiuOWlkluXw4FdkLPTmdknMCp lLXn41kd65r6duxbEFs8orym8FD+OUHX1IZQruq8VkOMH17t1Ej4G4Dn/KqEWDKume1GpmFT1HwI /qsDvB1L+/0eEQXXr12TqTQLDVR4t7QPm7vscSjazS2sxnRC5k9dzHVLdYZSzsSyPgcW8agmj/0Q wWSsyOIOPfxGkbBeHdTqg2Jwx5JKiQoUPDeJaG9YzL0+mEFZSW03csvKLPmRERQTczY1Pw/L9DrD YwEjcAdHheFlDCgSNCcuYPTGQ6K+FZUm0OQUUDChoSJ3eehoqE2ojo27rxqSammQcgBjuXuJ2+wD mVL1pScYKlKWj9EwM7TaABPifesWAu+VT7OOM1zCKWihwSAAZDdu3gD/O7u7GLKpAzrm4kjAu1kO QJJbqDyW/+rOvjlLnJPh+QWlVGu13RiRq0ZRWCq9CGllrnc0GqUwE4fu/Yjsi9QpSwJ1M9TkxRTn yl7gthXTHOqj8x5s39re1loALZYdPSwKeW4A1wKTdYzWZWPKPiwiqT1EPRAalHp9DD6UMbjZkgku pqxxrDM50J4MekZOWZP4VxS2JelCgAZaTpMpuZplq+n3lWHfl4BGre00t00Dy1FnsYret8bxrxa4 UmnoBWVh7EZr0L84v+ix1g6uHJqKqHxB/ors7jC5CxAzWJEHuN1kTsqyjSOHyqpxnhZLXK6an6AR ukLI/U5eLNhkyK0bN+V+62xbkfRLPJe2cV+i7zVNCT7BWfSxH/ux2rHdlKmSmhleJaHyte2cJHwF 8WLhzHYNTXG/zLmOuZlvXUFx5gm/q5qGHG5yR3h8sPcXNRvZJ2JNbFAj3cTxPdn4VONqdwrtoQ03 TSQr5XLkQAoDaeFmQCqnflZ03F6h2ihyl0VnxYLZHbYoLqJeMwjn25SODcBb0VsNCgRe3ZiDMOzu otj+QaJ5JMl0zLIddLa72XDGWB6OvkAXVpcWNwLoAVAphNtwH04meZlLMSmVNFN7XIJoo2Wry1lc LzLZHHgDTiYoHZklv8xXZ1WeHV3MXXlUJAGl7JnTNUxEiOWUmykf3h4RYcd5KTvyJFO4e4mgEXEn Xs45sy5LmhWEl9VnkfHLDKwck1laul5hDMJrgtx+10dZ+StCX8jhxRwRVQ27YyLc2zJXvZWYzaYs Xk1MMctiYEsH5kuWURvkvNV+n7EifeDdUWCViUKGGLOPGTq8BC1gmqSSaFIyS26ct6llkYNopWZV nTfjSSwDTWQJSomUaPO7a8MOwohCycUsUS6vnb6+6ApLzKwNkCMDHjBYCGyJ7nI0i3x2XnRKmUjV zG2n57/MKxe9QubEuCAbgrcxBdhtCaGdFaK4bzQgn7jToEBodnvIJilti104zndXdWvk4D16Yr2g rpKzV4VKMkqCfBMX3rOtKS0Z2ECsJZUT3SusKRhUNSWi9vAzi459Bnq0t1VRhGo4tp8vKBUEghQI tE8WthaBZIZ2J4fPiKsgcNUH0lrzcYE2KIK8fnGuPOkKXUgwCeTIMszl4YCX07jjLi71O+z76le/ +rWvfS03J0svXgwHyKQO/vSqhy337OLicC8pmcDpyakiKsyhv/kBALhkLyGJPhcXIW1K6VVGJN8/ xRlS0jFTRgDZtZtQyYFu2asPr19Lqc9wMeixCFLmhXxBM8KoVYUqiQbUKEphVbakwXHvfG+7k1Sn Fa2+NziwOO7K5/jibL+7U5mEHpoenZ2oikFV8TZG5CDDmtjBNVf1IEyPzk+vpxVSuDg9I3MWp5Oq XnVXlppQV9OKhFDJATukZEHV41c3UzKQUL4OOYc+W9WlNq6zG7cP7kuqenHO+ayOZlndLTJOpSQS Vjd6/MWov9fdQSuphPaEgtEHB5Vl3uiHQ+pwPErMw9M/v+js7RR8wWtA6VFIYTYt1bJAnlP+zY8H l3qC4E6yqV2q65WN2V6wk/Cs/DaxTKp2taXgzbWwJdcgpjBgirGMgaj/IvdF2oMZNLE8gvSRtBz2 jJwbBKqBkLKfYFukoxBuX91pY4s8ftXNshYyHSc2zo4jCa3jincbm9eJeU9ErPxsiboPnrYEd4gD RlmZxHTYOown2OK9W/kD0/LwpCcCAgNsHgnoV5Mkz431JY9AGgukr25WK2SVEp/wwANR7OvGF9Jl i0SBzhwJ4+tYv8xaWbRiyvtr2qQ6J9+GIbJXb9++jSHv3d7t3dwmjj0OOcg2O8REJDOuPMXZHVpP +6vjjo6K/qHKSBKvMptw5uJFibD8ka3An/zWLe/1B33LhqPDLItHB9KoPQkcbQi9gNkUbQszgWIA sLfKQFW4n+rXW3kbAORPb7U9AH0x7HJ70pvMMFboCztYqox66H8Bukw/dMs5WUf3bAqqLRnPSc5u Rxpu996QrCnZnSafkL5aIMCskJZRYzgbmxFW9oT4crJf6o0fj8zVcd7eNWvm4hUwL8htFLCmbC0c PO3hOClbScCspRXIKEtlZ4y6LFurIrj4sbvg4VF+iAnbITUfJxz+3RkQfV/+lfY9dWsVAs2NwOqJ +6crP6FDxwF0t2DEgHk7f8eja3h6GE0wByuUPkYmvxenJrrgIRhy7YBTsOEkpqyAiR6EFhWrPTzf CCJuh+UCJ4jZ/EO6pVbvbNpptKzL7ClRlsbgXzGx+d5ZoKxRNaZs4FtQqnE8lDCnBQwdU5Z5kWYb EtigAreEes/Dzb8YoAjPViC93L8L0uL1ivu3dScSyNpj/C+T0PoHOaDVjbEOQBhG5eEjaA1FMnPb MgRXsqvkywpal7o2zpStZTBB05J5qrRml9ujyPOWBYxnlIyXVQw4KEI3RyBr9RlIAOByY7HMnbIs Qyxk+HLNVuNrBXL0Bv3FBYLLyFZ3h1zaOXmZIQptWZgvetGLsHF/2Id9mOrazWs3+ieGzyw4AHv0 YhvHygeNsLQi0Cz+kdl6Ah1Zupn5bL4TV/AyqWf7u+JD+I3jPM5JXHMycKv5vNtdhGljse7XZ20M bviFbZFriNxfJ5cU5sTojiSyCi6nL0yGnmTK5bhrEmZAKwRrI92HcrlpnUubtmsFAR0KFa2rGqk/ /IJcZgQ3R5r13zyS4bFEOVY0TwZohuZectyhr8nQIUHyU67FiPMVXqrAueIVmMZoGsfzMq7EpieZ ms+RSs29KKSdEOf+YOGUr9e2MQ+a25kRWflAEuv1jNqbQCnNzKyrynAUR/tiiywVUrBtQ4GLhqsG 9q11mgy99pF15hdUG5tgoQy0VUAnIZ0Nrco+7qX0h0/a8oAvaCHjOhmpWi1HrG5mR7CKE4onoRHr E/uqLeJlygIXlI3opmQGskfnPnx2BuqexY/2HYIp3Hkzmx/gwooAKFEWWym+EzNki1fQ4zL/sDMS CCRyP8edvHm5K1R98vl2gxs6i9Gh9Qg/Z4YN/iO2tPuTkkRK1FWIamcxqj6JRRSI31Q8fpFkis1+ gHk/P8A7bwC/b5zyFtQaHfdmr3zwJCNhszv0egGiWLxAtkYQqe6Lkh5g3GJ0z/ub17bjNcXVp/5A ToCtLeQAoEJZoA6EL1HWJYYrIooRsCcsQ1nCLTpgATiqxnzKjNiLfO3zp/m4I+zaxuc6BGHkXK3C fRKC3LA9wBUoQOmFAL3rO23jZv2Qj5s8J3/37/7dEuH6rHOYplltBQMxJ8Pe4Xa1IZIh+kqFrKCK dawSPj8+P4O9ruxUFwseKFnJINEKdvP85NrOfmC+DWBQgBj6plSqpZPT28f7V6lSWm3jOufMUa/t bldXqiXOB+mZkugcO8np+cW1NFPs6bC30+ooiqPqQdnhLtxBWirko/75lc5OfFFtZfdwy83TI0ow s8dXjU9NW3xNXGSr9oiwGd/und27l2SO535dp9P1E9Lmh33jbNC7Sr3mhOf2xSlW/pRikuk27t4I lXeSUlYYAM9vHSXm4+Y4yxLgJFE5LcTc8bB3taNsjpuf4WR82r843N0n+quqbe3W8RElmFNshiwB jmuJ/pvbJyeHZNuvikkFPDDAxrxfdKFJs+z3U6AqTfBO27gZ3ssFLCOa7Yi7IpUEUAMU7Vq1O8K7 6hLoGRSAqkVDmEcKANohE3YC72qvgQKb0iuB+Qr+SGpK4gF0l6QEy9IuFZ2W8LCtbk7yFfpooDcl +MS8PRpcGl0Vw9NJkO/erdVtq7abKskq0G5Viwz1qaSMScCyVvehbNpDuWpP6OhGgg0vMfpus3qD 8R52ttq6XJTwePbBhIY1lkCKHNRc8hDDlG7bGOTTQEUz7aY5Okhh0eEqYoLUBkJc00mYsugpxaol PGAAhvHD2WayirXqze7S6jZTQyJcqwG6Q1ElTO/FL36x5+N2K55ffA9AhZzFK8HklVKu4U03huyq MRfZt626koLSCBDrtHV2tnMyxCE5N5ue7gk2mxhw/JAehi4d/4GWNkqQYs9yPu7S8tCZy2Jdefya aDxZUZ2g9Xzu/MKB2pOD+91FHLAq+KTTfhbB1pxaaBbdjghjHnXvPYzzcTtUcYdMxI05PnrpZg2d 69joUXq2CB1aL0gGJAQhxOzoCd4CchS6Z4mxPFrfwQ7fbqaUzEoWEeiPPBCcOkcK4pbxgXMEh39u 96wRcYARF+vzKwKlHNOODQ9tDPm4A3glo1YgqOMEusSYLFHKseq4ctyaQSaDVQdqookxtuSz46x9 asn5MNkp+AzdBb7QvfEM8wAPnB5H7zHXHOZizMeUMnTpRce/H+dLlpyYUk5Z79bzcfsv6yhF51jk 6NPxqQN+ZKwQq2ABVlSrkMD8IdbePlHn+fQJ68zj4XyIZTbbcA+I0TkchBmtGN040w16svIrV0mB S0uUpYEzvycf5a1SrGSMChYasYCKJJVXA9zKmBf5HucK2yx6pD3/UlizLOHSmmJot7/x0KyUHZA4 LjeNJm6rgWp32lQCfK+x55M/+ZOhKDx0qQ1nuX1FD9zS6FEWr6M7xIq3nSuYMxLcpUIKWb6YHD3L +4obQFcK7pU7DbPz5W3WYLm8Vu+b9qn7BlkncLYaa41khRRYqRZ6bBnpWC+WWLZ5dRfb+boOHbHx 6KU9svSi7yuZjTvPpr8ZWmdZn1dJ49hMl0xwR3LZJHbmURMT64b0Jk3EhXUYPayWmLM3CO4SwPzp 0tOFQig4sAG3Di0NfOHF05eVObp8wLcnxyc48ejWZRbSLg6gcvM3vTG0L4p1pSwdHqesH1tT+Aos eZ6pUAMkFhPLlArag0C1J+DBCeeuEd8D+KWwZS4VUij1X7nkXbB6n6XR47m7CPZCCjGEpdM8f/rG Q0sn8YY1qEh/bhTKJZoVC/aNP0wfek+LIWJsM56y2NdsaXRnUd/m43kFOr7thRTukMYNEskE+/rX v/4f/IN/UFoVnu0spTAgqAdfpWTQ69bY6MYxV6gbe9UWXgyRECnFcs3uDbQptmCgSi92R59QVz7b qoflcvEXD+486t6Ui+wwB/MqlblYOQJYZdFeu3atanype/hVUlrSFd0mFgZUCO1F/+Ceq5UA0IAE Z+Bqg/rmncAtt27domVlOgcH1dWiSgDAAI1TYt7V7a3jzm6X+rOV3XqO6cRu4VjWS4rVzjJxbqXw 9iWYcDY/4TLB/fcEx+aG2aXXnETMwVopGGAZQgKWYSUPABg8wPRT0jmQFJ50hok1JyEB3aZon+jm sGIp0TnkBuEpDrASbu+0jZu9EVZbKXNdfavkbN91U0jlXTW5rpbWrR97UwDwrTulJW02G3/iTpSP O810Li/uzm6lXy7DQFptRhqHA3Ll1JYNLxtecb24sk8BAGKTo5hdx6ns1tW3RHol9smgl+IBu16a ZMqk2xTdJVA2BQNaBfZU4sp5IHEVYOlRKto0y3U6YoO6XQmtkyARA+nLUPp7mlPKV3clnN5g5eou nVMTu4qb3QmN241rXHknYwmJYf2MyRHGZbEboUpc6wercLzy8yn/8pZbi0qHvjClbJ1w5jm6aJK4 q0ssmiJIMSbZ5Wg1lAXDTBluY0IrgQ9KJrMYR37IojHaFtCixJVO3HwVr08HG13DD1NuNok7jHnO UUEDVww1awtfNTuorKFm+NBtYH7BMzA6uWhe24+zEZXOlQ5MsDXHtjyHodTej5OoAK7yu0luefoO G9+iKYArH8X5rzT38CHdMv0Si5fv5HiQ/pBA6nF3b9eM+puEMvOKK+CUMO9guwGEX6AsoAJDWCfL lOIrGvjpBCZcPvOWFpVjwHXzkhEM2IlWi1nx9OiICyDbXZI1Z3e4Y8kQ4zCwVsFAUbRXMJzTDsQ6 a5VgK7EZdPRky16eUWxfrKQaowUG4PHK5SspK1+cmUroinuDECsGQEZhscICIu/cXVPOAzGflCDn Kz/OhlDXZcr63JkUcC6fvEtyHDK5NQluYWW5ZXzdGrQL9cotDBW8XFEZVHbf6HoOYACqe6oCumLC xTgM8i2Y9fgWhZ326a7jAHnQuC9xAYfxXIcKBiDfz5cFgVPUEedSDKBv3LgB7ih1xregnvm4dW+Z U/kEDPKv41qS17w3PnO3HAUm9m8dhsVDJuixCSBdkLAcWHZZgDBYHkUf504e+ncPmzPrysf9Ub4q HAb/058AZHjXPUJBRIbphPbxWP5heFeik+w/Nn2L6FdqCKUTZs0Q7Q3WBkNuECPXwysAEMPjCHHE Ov+VJhW3d+B9aiCBX9wkF7/itAhwOrTeZhnz3oN/5W0Kk+VP0mnltzbs5owudDgAIafKOkKIdjlu w9DLEwxuKOeTDZRy434gKI3jyfpXMTAxGwScxKwgQ2g+O96UdmJJtXz31RWW6I6MM0lMrNJwJcr6 QO6c9KeEqGXgnQrMK8w0vBJTyvEfRNtKysrFwu0AmM0S6AM7u5TfkNGUdRem8PiIDqcTaxngGBg5 5HOvycrGYe4ay+RyTNkS6pTcKnIJ8PsGysotaVHnNg2KoFgQkK8+/9HdogW2XSD4dPzf5TXlH/rn LscdJMetF3pkCqmnnJzi9HC5Czi8ABeiMmPueOihh9jEKDVJRYU/+7M/e8ITnoBlymcCKJggsWW/ 67u+K/oOY5D6FVjZW7iAQ66ST//0Tw9s57+E0oilz5f/pB/2z0Qb9+TWKeq2Et5XPStrTq58iem4 xl3Vpb5HKUDdSznQ0ScETjGw0u3gzTfbD1xL6daNaMsa9zLwpZqTG2YHnG5eTMEAaix8ksKaMi/2 BztpuUq4ggsPVHYLt8CKgJqCK48sSrGGw+de8DAFA4PTcwzcKTlgQSwwJLIWAABqig2E9cK8SgbW dbztAUWV8wKxxHHv31PtERG7mm8wxRIIBhJt3JdytCCFwGoltwDqeEDM1mDnShJlARWsprAWGABj JYvCnbNxI7iRL5S/+biP+7gv+IIvwNP4tKc97fM///MpdhMHIYGgN77xjd/0Td+EcKdMMN8GwQHx VhqGfDuqZBdvkGi2pqXdskzq1U8GKU1deUlpKVDttJHYeEN1ylIP29vdRAjSEXupnT9lDWTESsaV AgMTrhRdtlsiOlghSSS4HBMmUkAm5kSGgVUSWxpvpy6ZdDdDOgcqeMbTvSY8TCpxdacvLnDlGnTC +DpHJi5D48EkyjJzq0iVJF/WESsJfetnmAQor6NooLz86q/+6h//8R8//vGPR90GI2wjFFJwTgqL iqVCecmf/Mmf/IVf+AX3DvFtiNxwxVz7m/JTYBIw7JtZ1yxNflch+yV8IguUslkoSwa/UHrR31r9 47H0niuZC9Lc+1Hub+s5f0OhgUoQkp0SPINdOLgtdUs6TsGpe8ZeP8wzT+Q/gjgGxvrSlVw7Z61o HwOvpM/KAGlWEUu5wJFUpo6sf2VVBTlcNmYuKAUTxY0tpm8vxsBoROtKt4OV46cImyUL9UNcOMwG oxY9k4ylgFtLc6GM3/rRtV7LuqCkEZqET7BAC9WZNOBJWpmvmRJZeSP8qGQXCYtJcLDFL+Sh2ExZ CEH4MkN4oJXltCiwgY6oylAgFCm9z7ITKSAkm5rg120ON1yUKFtmM/EI3YajcYxJZZ+Ip8atuYve sNdnXi7lZKyLHjcguKmEBpngXvDoSsqK95TW2Myypbk75mPKBsGdjVKk1IKyeAXMRawpqFuBVehf qJEJT2mqLVnudGSTiudbXAIqxoZBwyrw2kAlPikuXlnDdZVBcZlG3Fgg+DTDFNg2QgXehWSLsQFc XhCRxeV5tMX2xTVboiwSQ8mct8ifLXqx1ugh/BSBR9ghiJTe1hdCTsSAeU9a4/l9JDd8PyhSlh48 1fhb91zOOYn6/EM/9ENYSP7xP/7H7tH6wz/8wx/90R9FRodiwb/+67/+r/7Vv6JEjk+DUsKcATmw PPe5z+WXZzzjGZwyYP09qmeajcqMQbqoYtJ/MZGopKz2N1YgV1IlDrgj0G57Ovk1czZDkoUD+4aP a08VjKINEqE2GapYMEZ78ivqLMAKz/vjv+RWjjwt2t6zzYlOZipra/utv+C5twMwbsay0qL6TIme 8FBF0NZ1D2MBTJaBxIFRzjMskvhy8v5kIVW9TSQq/1Pdrr1OZ6HyeOmWeO+3vMzKnQQjIg491Vbe nTxM241JrjC56c0DePld65zyVUoPHj9R7zp4Dfgbp6OMjB5TbBUwnDXRG5vUMjbSOmVLZJXoj/LC cIeE3sgIRmOVBmi3yai3XpWpSzSKqNn/GSTbaXJ4bUbKs8EHFxe9PRye0aNcyQu2USoV27yz9Nua 12ZKSRoZYY3cAAEeYsqSoSPoogB5dn4Gq3PlnWbOk4V0+5kd1ZeBtkArFrzgwiJllc+aBSVdx+oM 5Mps1l5aCtX1cmHgtk06dtkNwtqkOmL7L6iJERfW66R5oSkLgXcZyJZOPhveI2uQrgs5EyoNk3LA 5tBK6kV98zHElKg1jcczERFst46yvAplrYSHHleog5KnNWb5v/gQ8LxY8H6xjIN8JwtCL/K0eGJ1 VTopUqq0Bj3BmxcL1iLMjkoZbs2MH3yb6nE4tNRJZqTWpND8olwlWmV6kNxmjm9sdblAmosLmt+6 fRvFbnt/lzqrC4oniHBGxFaJyL2E4OYdzIuYQZ75zGe+//u/P8G88CI2E4oF/9iP/VgoFkyN4O/9 3u+luPtv/MZvINC/7/u+j6+YHsWC+eWjPuqjMvDC7VIv37J07CjmbLFgA9YYnEe2VDy8Ehlrjypc ncVFDa0QIkb1wkUJLTlTf3SKIRt9j5uBGDgXgtv29xIWISGDznAdqnhdiQGXTSKANqA6pbcU40Ti QqI/4jFOH6Y2tq0yi9rnJRfyRllSJQvAmPQHpL8oHD+XV4OfWYZcuLRSlkXwlsWHND7f5JQfb3Gz MRs/7p+TytnF1l4nT5aSbV2F6QT/O/NiTkXwzFsai1ITmqMxpXLrO7Ydbs6WSedwjpde9WLFJeTz IZS1w8b4YtBCuMQFrlwvKzxGWfrkBTaRDZTSJmyMgSJGtWLbkst2gBh4ShGdXFCWMLt0J+KWE/2G /V4KpsryFeqmrziM64V5vT8WWdmcSpS1+hzhsY3TCnNbzYdNlIUE0/mE+i+qimeYzaXMojsyZKnW kGklZAfcVrrUhbZiN8VWUBYe0H7oNZLW65e+lFlcVkhDPFKirEEkgxLU5JDWH7S6lMyOZltmGxuL ybAM4RZVKIm37OIadF4ihRb6WZdYEZlCCjhYZrNhWN0Gw1JKWE9yIOY2b2ehhqJhG9WTqiA6kpT4 ceOfQXCnmkoMCQpxw+VFJUmk9jd8wzdQzua7v/u73/M93zOMxS7DlohRxWPmHv3oR7sxxLW5go/C a5JSf1ZlcObLZYJV3zP+oTgQxY8wkiANVf3Timev+aFWyHA0Zv/0SqacrOKqpqpWx4cU+oT7bVUr y7bXM81+lnvWcOwHHBRXFB5dBoP6s4AKF3o5WtXVzX+8amr4QQSw3qCeigV7UVHVGI1/sqqsnAu2 20TOqVhwoYdSFVT/tjVRHMBM4xbBEzaix31crsuoqAfx1KXpxFVWt9COBypenLUBLUVCuECxn+Gg L74sFvPNaiIvpi+ccy1NirMXIF5PVi9li8qvolJSAK2q7FKxYFGWb1V4m1PvOCKrFf8t9y/4ZdlB Cm2m1DblayHlFskSVEmSyr8OcPxT4FjyME5kg/AqsV6JuNh+ATwsDQAl8Mr1bYUcdgJwpQPlMmUL hNWFeNdSFfu1mbLUViZnMvlyUV8ygi5RFlRbxRY4EyFA3S6VJ44qBa+krBW5MnG8BO3yKhj0e4vS ySXKWu1gbYFWflfaLCrwOsz7ovMy0FxJbZHT0mtbr1mDVsWY9aLU/I4Bp5S391+KbKMNNCZWiQ2s 2LFziHY7iFVc8pRmHqp+7uWkdizSLyG42b0J5kNe406Fcp/92Z/9zd/8zd/4jd/4rGc9y29wasuc TgkjoQAxnsy/83f+DjEkHsboZx+/gFt6sEVhAUnbdTgPJbbkjoC4OKVbbHVWBi3huYwPTQRL6NLV gvVmn3IXyX4paQ2JWbbcrJECrDSPjVfS407yupnVHdtJOQkA7TFlJX5d/5BV+a+rhxcNMjJUN1bZ q1QlSVGbiWuz6qQRA6ZycGndutumelJK4GPnwoSHoTP7UkJjcVYaCdJ5gPOp4noTRte6Yhmm4UqF 2RKqD/uwppUnQaDpL7WUhVAZl5N6WNnoEqYSf1+WzTzs138vLXs/moUzmh/D4Z7nP//52LiJRcFG o+hvxfOawLb3sW9ahmdDiowFOnkFyWel5XTuExdSFS9PDFaooWdve8wsGSrxcfALuqpjWCPmnUv6 bMm2i2THzTLo9XXhxWpgakbzGcm42/JW6YXszg7OCnVnItaCkQW4VfdQsTveta8cYFm4lJrYzpUO lbe3dYEa3MYuFsrvyulo8zLPJ8SEKa2uQvbw5nabJEHyxXnAdreNjTtbDWBJhjT7K0OXmQhpTp9m qsuaBlwNeCPnGLdmZqdpD70HwXnKbLcFkB1F51TDo8oycJ9JNQ9bMJ5IJxu3TsnZ3LE6WOFA+YI4 SisrUFaZUC099YqBG4iLLwodFqxBIzV2r3KO+fh3XuzjuJUwNC+xn+qX2B8TrFziW/X+BZkzRaSs Pi5KkmplRtAapcyLoENPoGwwl3qhGf8TU8MYq77hxDMQOZjBqCCVnTTuwGeEBj5FGaqOJgTngF+j WHDupjTiYni1KouyrQoh865qDeevi7ILb4OAtAAJKMvUzLSqd2P8DFBvV1HWNvt6cyYzdMC8UuJQ YtHnYDsBXsHsCqsIh8VZUw185cWCZazzNFszigXvSiznjxZsDryjVC2tYi/udzhG6I0ou1gvZi1T fQxfg6LZCrJqkaj+tUznOEWUi9yJYAzTbbYBwBlbdv7MaS4q6A9nqGh0QJIcCKLTiqdIi7eiB4Gu GZeaTXXxukIb8OHL0ySzPAKnLudHJqBlEtMidMGoZVirx/IEkI6PjnhROQY5vF7meWts3Jfpv9wW 6KnaQBg4+bjFLpas3axAclO7u88XoGREjoGCCc180yT1397tsigzPcLxHkRy/jv8M8RgBwuQas7K eBt6s8Ymg7LbjEBCxAtLCw+SWdBUWlfJ1INoNIC0V6nys0JatvP0dQxrJWKNyyJInD1GFwOo4gFG /qW4ykyNWet8n8JiiK8HoWUyQbMpaUkcdLMAhKnm1dnfsbpNQW74cgxau+0uRNYMRrjJmVk+TjZ9 CxcoPO7FIpDc5+HvZ8RAF5Y3LGdwzItc29vNWtp+k08nf0XTNHsmATBWkEvuuzCiLekC1fgOowq+ YtJEmP99IQqXicvqHY4pkcE274jVIg39ZXiWjVu75vHJyT7BtnBLtp6zMvahW0O1yA2uEF4tzshF XipQyuzbCFPqD5A8XVMKyz7HloXxZJ8jWHv44TFwQQLryPbnCPcSWJmjk+1TYdRcyAxecfdshCGs W8fjhAh9lU23m5MRwKovED3Q1MOoPYg4o2z+irjX9ovsDe64DUftHbs56RxY4mqD1neOgSou7lrE zmLEbEvIiSHFHEFLbQeUG7manC0CXxV4gJ6VDnwyseqUJQZxjGbSmOmoPufF+cFeFnAt4rLrszeE leaixdbl8Jwb1Mp+YbPKR7fJ5RyeIYDpU2IK8bIQwBF6s5WZDzFCJ9jW6s4oWzxVeOe+ihWQSvqw 4Ha29UL2MShupfWSrAKBqndacGM/RXAT4s2V96LQqJ2RILFe2+lW5/eBEc+OT65cu1rqYeWffe4+ tFvQrLIxVX1pk1IcQFlVh8Pd/eqSC3R4cXre3UPCVh8/6RStmaq2laDS4PTG7f3rhykBp6P+AJ7e TigOgGLImkm5VMLG1TvvJVb1vUW5ZMoYJOTv5mLTqD/cS7v78ODtW/ccXKm8fsKquXl8e6fb3U0o A82pC/0p8QLOSe/8ai41NpPs9Pik0+1YNfSKh/3gotenunRVQ33fPzvHNeeRM5ufSxRS4HBABZ+E csnIo4tbx3tpGcEoZ45I9Xvkmx8wcOv4+L5r1TWIEdyUgT7cO2BPrOq1dg4J9vdcid78sAwHw9F+ WjWP89PT3f395dPe8hCU4GEDK5VJYbn1+r3EpENxn3dUcENp3JJ//ud/zjVLNG7fDO3etHZhlE3f Y7MDTQ4mmmysP8hgbdFbfgfHLTArHx36xhOYG5mFIu++7/g8zbioAaovZ9E8p+dnlD7B/hCGs1Dq rH/fp913ZwF545ClM4zuV7/Dn7yi/BujcRbctHSxNQYeaFXlfaacoh65pZzh8czxSxNkan1Kbl6c 73Eb0A6ePqLFgix0P+lEZlMCZotXk7GojMkIcbREL+MV18t8prHKX3IVEJuMrmdRW5nRLEQXaCD+ bwTiv5yoLUdHIUDHjWBB9bFL75a+3IwqMgLoDFs6EmTgiltk454pw7WOLn4YLfQvO5UCsAQDlL16 5dDMEdmjwE2PyTUlzkwUuqPBxsHqchLETFWglEUtE2BMXhU0JQjn8ZsFJsTulEPPV1zdBJlZt7J1 UP1uQSlp5zrMydaF+4dutR+Y9cmfEjBulgz+RllLNlLWNW76YUNyTJVwG/cvcWzZdfxDX51+fsjQ xbzMqqY469EIbZFwwMAnZmgqJJ4ya4FlBALVdhnNTazLj7GNVXytzTsqV2TyoRBiq5c0g9lMCTMk 9frXD6XABfDgoRA65lYaj3BFKeGVOAO+A1Bagx5nydTQ9hS/axweQI2Bd/qRad1vBfualdV0aWL0 CSsOdQVMRemCiACqvsyzWTaClThZ9+EdFdyG9BkR329+85uf/vSnaz6QoLkFj2fHFSQ7yfwiTLF2 F3Hc9rqcnH6IsyOIsuGsmxxm1t6QlDGSsDjTdWo2U0mOWrA8bmBTG5n/stnv9bQIFbGkHvmHI5Bs UvnDeCyrrJDCVHLNsydn31vIamlLl3XSIvCtpqplcw/gotd0CKfL/67XkBrgxA3u/IM4GZ/3Q3uG EdsZEnx5dw/247L0usUEc+RHVBlVm6qKCXguXgt6AcP1lSUmzC7E7fq9VkZodym9GNarWD8CVsNo d7GSMT5KvP4R1j0c5tnBXFlJ4hTyNMbSGos63VGQJVRUBU6vo7iWsJwx++cINsWnW75jxR2rVObi DduxxsRN2/JgjykoZZyZsbOF1h7ypJqTeZJ+Sbo1lLK7JioLqydPc2ZJlDK2wSKzz4l4gbk6VxbY ipQQyiZF5dwxfjVrAMh8iD7u14h0oJ7Nr3SjmpN1LEhGqfwFT3TnVwpWUbY+OO/F1hvnWMbyHNbA HKdgzNdUBq6HNvI4G0jgGuv410C7hb2dSzem8dhHXONeQItZH5+Sq2J6cuCD0cBCc9cryPX67bNT v1fjoy8nYLIodu3uyFh0HSRGtAbnO1A8mjxxYqwCpqALH9hqGk3/JRCHIrQx23gOHBFW/GzbDBt8 jvlSRBxtehcX4lQL1+F/p5xZMwO7th0MI0Td2GUixbxTEyCO0AcnXkhBF/rS6vgEuO+04GaCVMDh 5g4XcBwIeeRseY/MdYSsLGxZlpM+ftzeh1zg5OWLvPh9qXFteHauxHTkYzIJWxJeWoTqRDLoxvlJ t93dw+mRU1JdF62LkBTika8XN9q+l94oKsUx0zgoZ/0eZZPklXLGj58YGsxwoyFuRxVP0cA2scL1 n8XrsNP5ydne4YEE92LjiG3IC6Ml5z5klKkwS5iMPpDKPxiwsD2jhc40RS1ysTwMvLPexb7lxnOz o/8S+uNvs2/ro0F91ppvoZoWURXfVDCrJzZuEDseHVjZz82UhWpn89Eutbuy2PxlxHsct9QvKHtt 75AFHauNMd/41JjvOVZj7HWdblkrjKDxTibz6eloQOFT1zliCzt/x5WIeRVh1IEH5Z7NYAiiLdvb rKgxXxIf1puMr20Xqro4chZPprfULgZ9Siovl7uLz0mOSc96SAYSn1cJtzFl+Ro1cBcbd+4bLh5T bQK2BuVqOrvoHuzpWLPAbJnHHXiP6hFaNtMVfQIfdX2+W7fizmZhL/Gt260h1mAyPutfXD+4qhxX eSOPSgiPrW7dPaOiLEKTSNeorVGu2D+wUlGW8/R+d9dJU3pK7U97Fzto3Lmjxf1GYUvWBpjbuFUE mYqDbZwiGbBSKYZEHlInPjUfQAAmCO5qC+zSFN7KD9C84uREyF+CQ/hXrjmqiKHyxj+uUUSPq3Un /Qupe1md8aVG+Qd8z24rvFjkqYJP8TaGH7ugpXJS0sNF3v5kAAoDAADjN7j8UR9eEcNcd2jQ0vfi p9A8e4v4AXsXWIqNS9Cb+pQ18rM3j2mUix+bgkWjtzqakl8dXIBXAsbflDwwRl/GZAF2Z75cifP0 GvGzaAyxdPNdJ26/uRd+KeAqp+zgos9RuURZRc5ET4YcPiTmIT94LsMcPgEHo/M+q1Tdin+KbGMs JMpCI7syOpwOYgBisgp+e3xN2jLPKnxHUy7imVd0RYkbBWIeRs9/ETPzE0NObxTS5IKc96bDFATM Xsx+sVnYRMz2Eqjg/SyxWfaJSaUVSCrxmdgkf1biNqbskJrdNqKN65Qt8UHGlioHCA8QWG3rK/tZ ZjPDbh/5ZFaLcm+l9qJXgxNDRlA7GJV/wLBRix/iDSbT8QbKCuluq/EqVDJrFVdJeXK6++hMWLzn kL1Vnp+xX+D/IM2yX4z9jEOMwfwSav74ijdxskn73Cxn75DgdrVuZRw3RSETK59KFyje7t4wN+Uc yK2ZFShITh0lsZ2MahJwJLZGG9pgsi8BP+1rA0/ZPP0adUpLF1gpLSXeEtyt3hXJZwvK9voBOG01 N1+YjN7V1pVCBjtOJa+NFcG2a+DNYzsS8DWjhB5XBxMevxud0FBNOMWXlOt1L7qsSOlWwmXp+t/q F/Mb/yndKjIybcmwsjuJRcPtxn9ar4IxtSWGTS5mpz3Yi9JWIcZ0mdbKvSa+vB6YS8dxp82r0Mql 9ite8QqMPu/xHu/hDpDAeTAWvxfWGCesLWJmF53QQFf+PUJc5mMKXZd9bovWEOpi2BzKzzBRGK/F 6sqRkhULxhjHCW4wpJwoLpaWQlZt++MYu4UlUIfwehb1bZ3Sn6fwdvWlRAYzikmUOM1pRh9E7LKp mslswQo6zdnRukv3OTf5kSr2fvACdEaO+umPq6Xd5rb8dzqakOanppqTef10GmTh7fn8ffkpitqt z6ZJRidauTpj0e/KUDYvwzzpNtbxr0jA9CIR40I/OrEqx5PD4pSNtwThKo8mFq5ULFiPqyTKfIL0 2MG6tU5ikJtsovwrJrg9rnQRXgJut2pEqWPOUuoZDP2m64VFY8gUYgOl5GvJnQEW+1sYmD+UKSwn q8cCjqU86ORRApFmmO93KWyfW9yYEy4segUG908O6vM+YfqrJgf/Mat2JLnWUFZZd/yU4DboAmVl g1707rqicxdznjRkhl73qEd0nQj1Uijj/seTGfe83RYOZa22sjenV7itTwh7vmYFPOuUAiAW38mK pdY7fqN1fKVVY0mmnA/d5bPgHJbwVq1n0bhKMop/EjZosdcv+muZ7yQQKywKMcDS/bKYsmJU+h9C WA8yAGatiUj66MrVzLMsBGawpr6O+D9EVVFK88zxS/zIkM19kogwfCIbN0doHcj+esdxQz/CAUk1 RVZYF3zB9Bwc3/FsZU+LtkqjB+Snenv/YGdXkQlVOtf45mmz267tKmuPuNvist3C6NSVV9ci5Y96 Z4iLK91d3R6AxdxyUGRws7ArSw5SpuRtM84ttBfw9doJ4R+drlvBMnqbIIbGhYyQuRsHd2tYNvHc tWHwP/+OhO+3zhrXzcadP2Xly0DnFTzv/NolEqu4XJYtofhO+dCD4bxtDMACE8hZvOTD4V7sQ1tj OQUlHqWwnMs3VsN9Y1MFnOGwazXOK/W+87OzHUt0HlgoppXlV7TqDRjWLs6xBe+2JV98RmWyGiPS OOQuX0bOAs/223g2PR/0r+4WKtVmbYwtw+yYyMXxifI85DGpzhgrH2oVY1W4ulPodh1lVcyz21mO s1xWwyEWEHlq5dKaKoABE+I3nUy7251FJ6XTim8ACuWe9U/Odg4PJJRz1vKpFdesVtv5EOfB1o5d wlrhjoiAQNR6BZwAQDy+AS8A6G00m5B5Y5eqm5g31lE292ydnZ8TM6Zw6eIqCJ0HmEe9PpvHzpX9 ldxf8qrRLZGmIeQhXCVgWRbqQbMMR0MARxTEiB30+5gffKNazRBrPgXnnmQq6Rh1qa5XNvYjWxzq 4Duq63quPcSPzMqZrc1MzG4H5HzEVR0ZBCssZtatYoxkraOxIiByA17eLb4d9UMb3fjS3TEZ7fTR it4dVr+Vo55KzzLwrFpSlRIlkds03drFP8BfNIWauctDNfIntrLp7gADZ2ZuxRWUOlgCJjdAG6/F 1nAHcxl2E19ZQXqbZgH5/ol+MsW4jIEy7XLKhj5LDWJ/Q2YntO1NhlWn1MZHKy1PzOYsFD8yMurC qIykyBiIaz6JbEbLbJb1YDcyViInvOJI4Fatus0tmDF9nS3D7KzHjOjB01FoH/GGeM/9adGzjrKm uKzAUbl9fq7N6L6OrE5ZC9MsYGCZrhZD4Vo8v8Q2breOF9dsFizJoc+N5pvJ6t3GABRQYRIAymoU iz1Eh3VflA+6jgm56ac+1y/Z8K7JUAvxLHmY3AFVGoBufT3bk5HVPigseYbWVfqFD0nd2CHV5d5b LVrvkOB2EN8WQE2LLMQIVs45ESvOsimPSlemtLM2ikZOhCAZAFDAXr0uHrYEWqaqJwOc0pA+kS8p Ld+ubRIZCd9JIgU0rzSItRcmI2BEPqw0R4sASDKGZ6y11piVNovlVhZfn4atrFVSY7CaiNhLAS6v WBoVTGhequ+kxuo2qaGmv8yuy4e/tM4WrS5n42a38FfdcOZ/+u/xwHy+OPWbHoE9hLSuRAR//Md/ vCcJCedc91hyoCyfUuMelQ9XYWqyR5MymqBAU3wWl51drgsa0Unm7NMLJegiJNkPcfZt9q9ZtdwA xxZ+dnqGUY17UOEqR2bK8DktutXlbxK0N+nTjaH5VwsaGjkxtjBnLuNxRl6mGW9Kx8/FOufHGYkM a/Mml30tpzC2FCU6sbnwyHFHcKu5OJQrYjCx9KcZdhbxaHl7t0KCm0l/iAalgEj3jeSvlC4L0NhN JaFWUdmesCAuZugJV/l396nqm3myFkZ8mzuQu/xxoivOtViCpFQ4REdgm5cQ2yFFu6XNcNOYwWGW wwx4fsPRQZ4KuCVmxcApboCFjlJrahhAesCOVSFjNu/GSZdFMoo+/M/SA5ChplWgrGCzC9UGiV7R OWpO+ObCrlUyKkVWcrqmJJtnpvSs6DbP8i12xxYcqHLJWKsUMpIPF1Miv6UNFMTVwISwruYVcWnJ fO4k4F8zRq+QyrFRgjDn+WjatWQGmWUuTM25GrY0cwdz4HYbV95LlC2lNpXDQCfUzEDJa0abBWU1 0AL4OgHyIDZcXi1LA5e+5jAAi2QplRNDmd8z7ggOJGuWsydR5+f9RpdgY3NtRLiKKSsCEPFNseDx pKMr76tUzGKilWlvKDmQZygq2bVjhvQr75jsMg+K8ejZySkeZqXESLj+GnrTcngr8nGDI88C6DWC sV16pT4PlQ+Ihq7A6oKYX1wc0P73fu/3MJWQMpDGfIt5PhZqdoBY8KlvaMFcqIsPqrtBtkR8Y0iP cYc0ULlBNsjPIJ0kYXGk4JmUE8/SKsLleZonJAt+JFwdmkOrNVSmjsy06utZh7t8ny5Kb19lVl8j Gt1NCGF0JCP+vSx9j1heoa9BEvFn20zUyz37RPCSEEZncGeHjO7uPplnyVBBbBV5xvevHore+d7h 90HC6ACOtJSiZ5mz2Jt0JS0abgA4kZm5hHlpXjnmfa0r42kkRjFGMzmPGtS88jgTB56e+wUrX2EN ACVhunFSat2p0H08X5XCfJZ0IgfYnQSOK34DM6WEfzHb0A2x89xZ5cxKbyp6abkvgigMmcsyVovO qz5ERql8rbgrJVCKm6CeGtDxB4p1USUXRqJXzMOWvx5E4RRBHoEypWC22ysZ+r0eRPS6EpZFw+lK ZQj+lSnJfHchebrFui2Uhzruu0WSKaFr1ZoKozMsTqPApRBl0sNdT8QpKf8Vzi/MR1yN94c4LZkV ddVTUhj3RayvZWpcvuvIn2+syIjyP5O8abHZ2+rW5mp0l6AsAx9jkgZK6oGtFSHQbHKphfvili5G 42szscxoMeps+4mWpDkeY0ERU1adNLj3pocXgz6ac4EnR8tI61P2VGWBLQdeTDifewjRceLaaSZS 87jPadIPhydJesMoKb9cWnA7HrmwTljIb/3Wb5HT9clPfvK/+Tf/5r777nuv93qvL/3SL/W6xUjk 5z3veRRb+Lqv+zos6PDrt33bt7Htww2UXOAG8FOf+tQSfHgk+KRUTHPlHNiyBsen3WtXUmY4unVC FpjGXnWShNFZD9G2jVOi8sFrz8/e4nbchjcmZ5aWPiXEasCtuVktoa6xOOzGaf2e/ZTj3/yCS4D1 ekK3K+uZrp7adHpx83j3/uqEEryOFwWyViYVoeVoMBhe9PevX62kAA1ICoYLCxFT0Xheg1s4xzRJ Clb59HQ64bZSZUM0Ylxjzf3q1Dp01T89a+MZs2oemx8lhOwPGntJ3c6OVctCmamrnktU4h6M+xcX O9cPq7oUDx4/dPPw/nsTWtZG59LtUkjAcYSzb0opcOrbSeXf31Xu+MrnuFc7IM6w2mBD1BZOci4W VXapBnR7hUoO8Zlo9XucI1Sdx47+i2c8vehfsDfGjvqUcYPgrp6Pd+eGEWQxlRNA7kd/9Ef/9E// NKVwPuIjPgI5Hs6ttER2k8H1137t16g8GWpRKw+AJTqggW1s2eNmFn8Kn7tZIPoRBKiRlBNUiF1W 9KnUJvxpBzRrk7eMO89sDiozoGM923imQSs6zH/Ko9snymRI2T11rrqO/m/2y9Irc3VrFZ6ydxd9 FvvnL7q1SCzB43YDQeGadFa10vuhpTL5WRXKxWRXAQOQJGzhVLESV96Z9a/H7syPF0QpTz9Hi4Ln rPRljH9DY+EnykoRhojJXGwvnUSE9UPMAreyjsXTdOQ4N3q3qzrPCv2pHyqFmW3NoF38eLf5j2cq Vf4RsZZGD2R1yhZ+6EcHBLsenc8ipmZxILJ9cnvVsiMIgAyMgKuY0xSVOB0pTLPA80uUFQagLAWD ijyQvZWzTcCPl3XNcLWCq2PKUt2pDMCKhSAesFWjK/SF+S4vARkn4G2rqJkjtoj5HCQR2roNfFIm Ln+riKVfUSQXIJQVvQJllyiVLRyvkymhsZmyWi+6oR7hqkDZQv/WmBCroqxYxRJWAVW8HVHWKDgi P7FOTCnSelWby9m4kbwo1L/8y7+MHv0Zn/EZX/zFX4zF49u//dt/8zd/00uXoVmTSYp77Z/4iZ+o RA31+nOe8xy2ffTx3/7t3+bPD/mQD0GaYz8J5bdd6LuZNUDIwaeVp5zUCZqibd0ubZgpq5E0BYNT Dbf2kS1MoZNZomHqtlBjl6RCdiUZBulOCfeVPYeHki5KvKFUsdYfLVSibIWryM9flmOaJLTZZklz z5TtwHj/WDrwZNutfnUaclJncod7GdFkTStXRUG9TjbUVn2yQ72fhalE9wKUz0IBrjQ1T/Vi6nJq 55HUGj3PmEwLD8WNb3ZoQ+u2p9H1hRDxytLQK1hyOM3n/QOmrgvnlAFUkqghu0msqqgNW14BFNmg m/XZDpZHfQZg2mtCuU5rpzrOwRBMeK/Z2bhsLeZpEsDZmQ2ovJEPj9GJnTL8xdR2qCrS8lXt69yP t/rd/HtNcilYniz46hwVkly1USx9wRENe9ixX2i3cGPWoZuDAykNdREwJi2MsorWBgOFYEfubUeJ UoGKE73CHlSfU1fbuRypNOL5A+SsgswmoCM6RvEolsxSs8VsJtlluZAISnDbXEC+eBaA9jqxHSl0 LnSBXpATz8YD8HPqMSmSteqyolKZK0y7IFX0PjmCZR/w3qxmcXTbAWSSwTWfGjgE89rk7NaFyIGN ZYg3y60JC8xnC86AZ227IYjHSRwoi22Twy5QuQ22N+jv7e75FuKP+42yR5UNszKwzMvN2W4CWkfZ gQS8XVijcYOkuXbXJG9PaEpDF6kWnKDUeLZzGU/Pt7BWR9q3kSkzALrQaLDPhdEtjhtu58rC1n45 WjfMaOUvlzaVCL8G2ad92qf983/+z5/0pCd95Vd+5ROe8ATKmGEYQfsONScR0D//8z//nd/5nb/z O79DLcrv+Z7v4cjMeiCOG1H+lKc8xenhc+YXt5svB0eXDiG0hAtOT04Or14FkGDdWz1PkvbeON7q bDfAi7mDYkHpvMLwbmjjgMbX+1cOXHSufVhW2ChH4+5yWteljZNuSelJuLEFkC45tuP2qlQwgAWV UXMhIAuzF8YElqbRf8ut7QeuIpEXjeVdK0JtIw4ulHKouxPlLcrsiYXWIBbasU48V4kjp/g4tkQt +HHYH+yAAUefCc+l5uqAbgnbh6yFXIPuOI4emvGML/rT/rBzz6FrXPH3pf5B7O2jI7JsBwtMYQu0 gR02UHpxdkYKKiLZS9RfBhhcscIxa5S/KgFjmRpJMHRweCXjltJhubAfb53eur1NuLHyGekLx0th CG+PD21M4qQ+OUUDqGpfbixs8yGuLZIAq55qifGK7enKkxmRqyRbbuspyx0FjmjGhOsom7EZEz+/ fUJu4SwMIOszZxL704EXa52esXV19zy9zxKrBHhMveC+0tXDw/BZgbLBDaJlyIoZkPszrla8kmPh FqV13d0hQLSSspNz0qONO/dAWQs5X15TYab12sXJKZOSCpUvjSJZ83VhuT+ZiF2nCOpPHb8apzGl 4kgwtsQ9X9pUwstsQWjTj3zkI++//37+JD7kp37qp77/+7//vd/7vSP8K5mc27spm+D5yQDOtbkg rH1hO9Du6pTCUXzMwL/40QtkIFHycu1gcrxs+Ml4x0WzBlru3HuwZUNtb6spvLlPqxbvVaPKz9KL tsKsHIONvam97mmSe8EQEvopvpBP1gqe5jOKoF0FD30Cre328bzcYRU/dOgnj4ClJTzkPVhvGQa8 G92kXCJETlnXpgvIXyaE8YCo41xdhHa5f0Fr2nSYQkzZDNWOdRzAhNViBi33uQJgK2ZUSVlrgAbn u6hPvPTEHOuagXO6Qbm2vWHSbocv8LlMKceGSEC/Gf6Lc1maQTplQT8Kb0bT1ZRd9O77h88r/1nB Zlrd7ZYqIPt637C+DENQNp5BgbJhOCMBP9ycXN9nNhbj6oiaRlmFV2svctmy9E48U5WpEtcu+LPM BoslI3lVIpahwo0B5e0k+e9UGzcdIoIf97jHYRhBdqMmEx+CyZuyk3HNSawZOC2f/exnI7s/8iM/ EhelX4x01l2ZjcFlesqjPT3dKJS7lVN6ToRh89Wv5YHeerKsAfpSlDapkfSYmluRcDF0lNintq6y +rwRmOR+00F1GJJQkNwoGcy8x/QX/pIh1aK7FAlSIfV2aULHFO1U5F6KWOmNU1dN6vyz6aQ3X9ky /fWV6LucjdtFcEBZiJspGyIiS4gvM+T4q171KqJKuPLuOc49UzBfWUZjhZpuxq/7WGgc4gs3sQOW y5OewiRVjEq1gD1+zuOjzbeSm6QNAHqOA8ld2Yn7d8nu7rtSnQGfRdzescEe5qmul+GMfbk0cMfg ottwddhjIv1qhjQiOVjGZ73m9T08xaHb0uL0EfnQTZzMqwTA8mL2ZMRurvUtdh1uvdsYA6W582Kg rEcTxVZjAZbjw4MdrRI91Rj5mTS625rl9sLwugwGiMJl4ucDh7YUXhLvwe5HiaEtUTbsWI4rFSYt CvoSKvjWDdOlSQU4Lft7HiWGGfDsTPdzYQOzK22oH03P4I0TagzASsoCAByrXCxLx/+S/uHEAjbn 7WWuLnF4qYZGmashk/sPiVgdDLmjIHS5DHf2jIgrwpq12ld3SDm5jq9ow3oJ0cM087PaSiZ3Wz/T iaOQS2wQKLtuGRbWIEuMJTgkSIFLEiaIdFo1Omax5kpJGAPvvF25JdAgpEQPlHV5WM7HskmcLb4L ppIGFdmJEkkp2rTcc+J+DqCYud2E8vjHPx68M7wLYucnX4EublY+LjFpELaKoE2sfgFPw5DtwSKS 7V1v74ks5FRwl3QembDMJSVg3Nex7nHMxN+Gs8XKV0rAux8mPB4BkQMqYU11ELnscXXK2UPCLLlq Fu1tgqWBHODAWIX+i+0dqysl2oYpx1/Fc3dK+bfhsF/oR5dazNzpNZeJNjJ3ZZaXmpebur217gmx Sd5gmW1KlFqWbqWeA2utZL+VlFrHqJLM4rdsdqx7eVbNM+GeT54ynYrQLA93KcqW5u57cCyhNhO0 NFaZq3HAW+CNNlrbdM2f7xlE9B/zFy9GcMQ6D+ibpTWyTIjQeCVlY/BcspckUtyhj+5Co5KycoNB KcXJ+IUrgSuNIgTdmL5R6n+DvAotHeYSl/Kix2JsVpJWSnJeYS/EX3hpjTttYyi3Ys9nMDRu4ghL 361MMrVyFKaKs2V/PyHgmq3+xglO2yZJpqoeXKZwTHDNbWiuAjSjUUpLOsE1B6jV4cYUHLDKYXiQ qiDV9yevffP+O9wv52TV454G3INVDQUAuE0JpWe7pXEiBiBWiAfdDAOeSeJa2zgnEx6UACaVglj4 jZbhRuiGvjH90WGK+iIf2unp1atXEyCt3X7o4e7eHtcRKxvTLTCklP0UD5ycuNe3stv0OG6FbM1m KTwAq5zdvH1wb1Isf8jeVQlq+uqGCeEBcJXCA6lR/0jqi960P27fc6USVCcBq3vD2TR0snJxcbZg eabAXwImaNyXsHGnzGddG9/6wsYbN8s27ITebbNPNYgn9Jc1eTt1S++VJ6l0IEPLPS4lX7LcUeUo bycMuLpROfplGyTygPNVYuNLwZA+qZ3uLhaNlM7T+0zpLbR5O5EgHYZ0AC5FLMUZvh1EQfq83vaW b6NwuEMaN/MkV8nDDz/M3Usv3+mcGmxAleqD04nN1g+/5TwJMSKxumAqOR00O4r5FUMowbZGzG3c Fiw2VTUyekMx5Jd1VksH0k/ozi7LNu6VG69n6vCzaonJYuDp1k3MCwNrycY9r5GWQqc+Un8Sjncx aF0/IAAgRBeVdr5wLvN01cuILbV38PgwZf+nmZMgCJqSJRR0+WR9Xg5AQSpFs5PHwY0/GE/H0y1y pvPtdtnQXNrmOfRkBYmWvAsxjfgdynpl5w1iEWidCfl3mamWP9FFGcpympE9NgJoyroJvQjTxFBB LXClXW61rUKncgZbaewVDxDSc9kfYKQKrZ2yYgRzM5To5XOPu9aI9slmDAQOp3HcssDVDI3xjbtX Zs9WsWCupDZR+XMbiJE13qUd8lAhc5lPiktWJHAA/PPlNeWGIDDvpxOOfSX8l/iExs6EJUOoN4sp q0id8XSOjRt04RizOJCCjRszfRwmbklgKkVWQCy/lNxCnBicLimLrkTTO5rWNYzt+6rLjniPDZ9s /oV+kluak8jN2qssiwEMh62y2yB8Y/hXvuWrC6apbBnL0NB4YVlb9O4Xz+wmYcGQqLWxEoZ11r2V 7RMxEIhYmtfKPjeYFwsA5xZ9de4XR9c/PlDJELyBdonzCsfBdHqtxrnL2ejHWNwv1IkbL8Xbm+dV ya4xa6U0dlxtwoAoY3Zf23tKMy3NzRsExAZgLoWBdY0ryRpQVwJgE2uZ4d6B9su0wSeRc2RhiikS wzEgRC0t0pLwiUVz4u93SONmw8HGTc6dj/3Yjy1Blp6rhNmy26RkM2CI0cPHjZ3tlFwlmKuQBSnm xb8ONu7ZjZP6PVdSYrFk46ZUUIKBlYuLcGuKkV027v5gb/kK0ip2OzvVPZEUxUQ27vN++97DFK5N tFqyYGTj7pKMqNrPcSkbNwBcu3YtBdTh2QWaaUquEhALvVKYkHHTbdzMCxeibn9UPbJxT2cpLUFs uo07HbHpqxtcnRwfXzk8TEmDk8gtoGd63psO3j42bpwHRVcT1524sJ1iIi/R7U7buCG22yWW+cdD +av4St/rSktCshjvakpUWWLjy0R8l3JXbgBbBRfTLLyWDr7a2ej79slk6Nn+Uh6r5pPwcAM+sr1s nJSyCCT0aPQS/pMaY8Kacik67ZGZKO0Jl2Uqm4sD05hQARXJAJDOkfwXlaPTQAEGadZw9ZZWy1Ps p1tISSRQ2EQiXunWIn9S5gUAqaub9Z22YBmagtCpACQvQwIMJ3lFwMqp6XpX2iPpvBRKwHk8DX1r x0gdPg3Ita0gHlYhbNzLLTAbrzP8lRpjqaZqUSIkw635KC3jvS7XJSRa07jQIE3CanFZiZAUaBHc cGJSS6yxHS6MJXVr0Ca1dHNFouQiYUQKqLTBZGhV46ofiNoj72faY6IwSRiRPjixNoAEXCpWbZNL e+ZtKJu0JXNQH6WJeLFWmjSUsc4pm/CAKGUVSXjQSPrzLGFcZXNWdzLDJK9uvBGUo0tiAQzJRGAn 0YtERsO1RTHLE/VLKJXTpwHTX65Q6hGiKa+va3OHTCWcbjCVYOh44hOfiK0DjwGZEfwiolwBVjOJ Z+1UuEow0RUJzn0yD9XmJDla1xh8elY2Oaa4p2C5wq3e+WpEK3pUYZvVgkNqmcqcbca4yuIxLwbF 7+aVwnAqhtGZ7dgK6dCLa6SEx2IOt6IOOpbwAVWBF9ByNaZN3Vv5xPyqDqFg63GVje5eKbll5KFa K+myiQcznK4yK/X/uhl6yiq8SI5KmnlxuEV7p5Sh2t2ecXKfEhdq7pAmjxBw9+AGNqB9qNTHiKQ0 zJyfq7hbGqQV9Kiil1727MxVLYVbWaotc6O7vDbxlXlHRYUmNalV4tZZIuIE/Qo26c2vNZDcZr0i mVGWluJYY9oNo/MtaemcEDYvq4G7fokpw5U5yR2X/McrsUWckNt+LUMhj1ypa+SKRicnvqWEcxKU +aT4IujHBOdXWmgMZd37urJ/ux+TSlnGNYmx6dEqMM+n/vWJFwslL/Mtaqh4z2qqAqdi/rIkL2pr hwzPCyiPq2IfqGeSA8F3J6cnqtPX5I5gMd1rlSwPppI7JLgB/U//9E8ffPBB8nG7YT47QBEAMsqv t23cgpQtneIjwyHJZcyzXUGL4ZCgDl0vMy4U76yU26qTYpfyKT5S2adSfrnrv2p0CNe76NFSye/d kxPvGpG2YAtMTCNQbSNT87h/djXZMTLfCBggt44pERtWjehvhWJr25R/ZaVtUg5UBFkAECnhfLO2 MVJbrEh6xzC4AVGAJEsMwF04v11miffWMaRthapcTvpRCyJeS6kcNB3dWAZgwL1k6x4ozu4No6v4 SBVrgSuFf0RhEiu7BVblzaZSrYLumZRx4lrhVR8Mh0gBWQh9KdsToTe3IiiVrG4D2ia3gbEzwmAN 3yaoQ8n5Nq0CxmJxMQYbf9ZwDWWZ12g84t9FyxVLLDNpwk7Uod6ptptrdg5Afsdy09SYP1xgOdH8 Ks86PhQTwi6qf5lAL92z3aZeUp4NaiWxTHEUD04XvL0Zt71en1Wgap0mpwus6PU0nDU8vaVt3oFV ZH7oD1BBZCJNOw0EqO+0jdvx4kEw/O6KlZ76FqRlMejDrHCs73flH7U1WeBvbm5sxTKUYdmDkFQu VkOu7haFfFFRdBMMllTGqspUji56kAoyn2d59Oh9JaXjx9LAZhgp9S/Rb7MwvFEBx8sZr4chr+3r GXNMjd0IcDbsokLxWiRoUJXjinJ2LUOSU7aOz5NFvhFUm7PlfRz2KAe+iVI+BZqzI5LDVPPayDDS iL1YcBW9HAbUuM2g+uimhZr+WEEFNaQonQyy3n9OwZj4WYomU58pb1QFak7ZvFjwZgwg2ZxSi1K5 azDmK5FKAkXKlthGs9BEtrb6RNAqt2wVX9W32BHJHu54q2TCQa+nc5J8PuLZNe2RwUqSS/LZqj5F AixwftTYNLodntBJSNAYMLB5dlayvJUv2SIrunDL84qpRMZsGgPAV15777JSO9507pDGDewvf/nL b9269ZSnPEWZE9hTOW7bjsS8oBZHek9FXKhKl+/QoSaQchSYPXq52aJukMK4p5SJUuJHtEgrfKdC Sq4cLo3iGRjkyNrYbaa5e+zwmq7yFN3SMsekJ/bFatmN46Gbme1ipo2AklET1ZxUhUyTDZxGUMG9 3JaVZZq3tilFyE7E7MfDwQjN1F5cgy5TjFS6jEHdjlEcvYwECjmogSqXe5eu4K/ElVSL6QwSlHC1 TBFgkEXFcofroL6GuJIEWMOJu+euO+q5FRRdh14oxCkdLHA+hQx2vLWtaQlaB54+fc9bN/qiuqPO gGXKrpiUJIYi2e0kLSEGI6+F1opeQgDPKwImZGTKs64boiVRlBKcCGmdq1H3lKtkBYsaZ4roOnhl VxB4fdPoqnghkcGslGdDr5visYbJNaxVYV23DD0Tnkc3YumU4MKVZ2eedei1MH3KMWoRLHcbo1dm H7m6YHVKpIrEYgtPR7PMinZ00SUAz5OxhrUsNyvswirLEzqukwBWikwK90yB5EBLt243W0lcuqXC QKulempqT+al8UiBxzkkOmeDGyYkkrN519skTcpxRe9SYaEIfJFQHSmW18B26TjuXG9Q8nh+B2J+ 8d8LW4GdjPjENk0Tsna/HnsfHI99VpUqzYAg7EAuKgb1VSFBrBnMQHFadOdaLe8xlZCm3NTIT5sr XwHhsCjMSs/op/0Lsq73wxnRX/E/tRlOp+SPpwCK/rSKM9rzc4JllLOikQIV0vYJ6sgTVK0BmE44 H00H0FIdIpcdPwFasgSRzwboMGSwF0Pc2QhtAzgHeN5AXzgBG0LqQ75SJdMRUHBNwA2R69BlI6rw DanhsYujR5RGL72L6WOkdNhqacnzF+fZ8hBCkcqvyNilizP6kXAs4kH5OrxaUX80GQzDBrOSuHSI fIdAvTOxh/e2DmC+QcpRBBkfBj8g2URzob2b1IxYYwpcsWPrdybJDQszrcTQmiPCTMyDkbTjkHrM mWQJEgSKlTMdK42+9tFF8c6V7etW5YT+EQqyR1n70C3LWoYnk6+SxqozUOCTAK2/ovtfU0zhNQAQ g3GgLM699PqEmJbeAD4EUkU0G23D6NnccyJSBgHKqsolNPUPEURRe2FJBi3mMRr3+pgrNlBKXiu7 xzDuwebwgORsqX38p0QBJKLxABvCUEyr9DUFEiB9jbLT8WA0PL+ggdBh9bt1xaG0xEz8CwAiTTFW bOQrBpL3SOlKZLQEt7oUtmZ187nWn1XCEvdCiiErPcOtJsWvUrHEK6IsSB2jNeZmSDcCqVmWpimn 4eX+m6pxI53f8IY3UGESpeClL33pox71KAQN6TgwOL7jO74jYa0e646MRkC/5S1vIUn3a1/7Wj58 9KMfzb9ei5K9gso4JQBnfeUPq6eU+2PO5/06tRESHko+ohh6lffNz5DqlOxDV6tToCC14a3O9YOq LvV9/8Fb2/cepiQV0f51erR1kJT8YXL7rHG4Z0VzKp7RGcxda19JSIHSM5mSgFjpWscXnbSA69lp f4uC9AkROzOES3/YTiABcx7dOm1d2aOocMX8qVB662R7fzeFtUbHZ8DZTij5CKL6N4930qpujo5O t7odPFBVtKrpNuTJxXZatpb+jaP2wS4lVSu7rZ0P5E3arV4F84EqLravVFdc1GZ3dN68Vr1eAG/e H6MHpZTERSRPjs65FVw5KbiFyhsqElvJA7YM29evKHKs6uFOMjdCO1erAaCnwcNH21ynSIjaokIp 2wD0isdHp+kP+5ct8U4Pl9a4Eb4k4/7hH/5h7qx//dd//W/8xm982Zd92Td8wzf85E/+5KL8kt3s fMUrXvG5n/u5v/iLv/gFX/AF3/It3+IpfnidnCyHUXmLMA2liEuLQ6JZekZsdjnfSyofLFVxQalN 7QXAJndQ/K4ka9L4UiOTyp5a7x6wUjkpGqCfpEJrFpukma128a4GB40rqU97G5NlyqSEVCsyVdkY HHEpm5v0lS3VwGrbpzyMnBZlapPSkbN6ixWxODcroCjpMR5Iaond3s9nlY9KIFY28gae1jGtWxWo SMOANGjz41U+7ES4vFV1M+GRxSUVWfN0ymIlScQA2xbGlxKk8pVFh5+EeZSbJLKrJD2XoBDcX/Il X0Khss/8zM8kQRpx2XDmC17wgvh2HMo1Holf+ZVfwWCCuu2GFLiHnGpo6Pyuk2F+qZQ/dfTWUswv m+b1Q7O7p/mffht12h/oWFTZWId6GQ41tMeyFrsN11fVgEOhH7Xyy8rLwDiR5OhwLsxb+i9L/esg ZGfDLBak0N5I8NKf/+/f+rmf/1XPeMbXfvZnft2X/MM/fdGLDVQDNDvVLi5PZ1OQqoNNRQkhixAu WmbwBFuKL7Slucfw6GA3HFEPUBhbhfyosWHA5UDAVRm3GUJogv6iAq8VxFJ3qohmsT1VjS0rOudo T7KbUbbwywLa/NQfeGA1pYIpsziv1ZSVQc+sq0s8kLeP6iYzHZJ75OnVJECXfhYfKo+JuDAmwXL7 jA91il+xCspsiSmBMLW1iyvjI5fsWB08DmLx6Sr0qjGnfzMOLC+rIv9Yt6xuCxuraOzmLZn1YmrG Rahz7JkEEa5UzTJrvEogZFuLiGXmi6U1W6xFrm5zi/ZKSi2WhmHIKyCvXOD2veNRfAJVi6vA+RCM yOpii+mteFJNJXRNVheUbvKyUpPssz/7s5/2tKdhEnnxi19MYcmf+ImfCDUnX/SiF33VV33Vx3zM x2Aqwa7yH//jf8SogikKUc4vlKyEQOdnZ/d3r8SJKRR3vH4Pxy1CTI9HhmI7IyzWHdDrHnYz/AZC HCgzD4dFvGYPyMIrIIliMViEIhMVLudIHvtMAyXHWerdC0dBs9IVUA8CLTXnHJQXpVY2mcW37HU3 H/qRn/jxX/q+5zz5GU9/+Ph258r+J/39Zz723d6ZM0L3yu7RQ6fXuvd5f/xjW6uVEtbSnun2RzEu 1dyfiw3YmEo7ll/wC3ZbB4AOcajEVweEVTyTqIYwk0cHR7mKHFcL4P1OR243X8Y/KKKUc7aAaWzW 0nVkUucCBhcITg793txuYeXccLVBlG01rFavTIXIRftlgXw8L7bEPEkEkdF77tVVYIOV78DyuIKy HnCJg7R4fdGz4BcewMWPbTqBfo0uxQGE7KThIZWZ1D1B5+EHK++MZHqMTSM4b1ZSKrAZM/EdLgas TClsSlRRMO+4zl7yZIrHfe6mh3oZ6Ax1zATXCzti7v8RPiKe1lQ1rmtddAlZ199AoVsV8LRazPTT gigECAwxiq7jBamGgkGI1bD2/8X4jmq5K3zW2Fa7XdxEckpx86DVRFlcKUB8GTJsgVLKA19gAy0V 9zbjzlV1coWuBFj9tkH4U4TW/m33XYurL56eh/m6cI4py5/EUyoQgcohe+2F12EtbhZfBFPJ/0/d X4DJVWT///ht9/FM3AhBQiC4u3twX9xlcZYVFlsWWWBhcVvc3d01EByixG182l3+r1PV09PTI32z n++P5/nf7R063bfrVp06derUkfcxK7gZycqVK//2t7/9/e9/p8o7IpsawdissVw/9NBDzz33XElw f/HFF2+++SbVy7CWUJSSb/kKNRx0wPb29r322oteMAE65UF53hLIJWqqDnX20pkvuWwiGvPW1mgH 1BDDlGLk4HF7nDafuOmVKtGfZVQLlCkJhiCHt6am7ABeebM4agj/SFMsOOsO+AZikfKfSCRnPBR2 USxYB6uU91VFhj1y7gW/fvzB9T/8INQAVISKgx6SL4QL1eqq/EUxzINiwS1d7uF1cHGZsBqIFD3F gt2e/mDQfe4Xuck5hpVGZK4KP+hH29L9MgUUC5ZyyX3oX9FbPbGWeDgidVIEHXDQudLBA4Bx5+Ip wSrpUVMG+wEzm+6MOgJuLAvS1cFVFpZWiHrNXj+xRcURaZWyz1XkgWQ0ToyERO9U3lHBCeLxSsVi PkpLDzSqPhNntUTbu6gU7PAKWIo6GvcnRLFP7C4CAlNHxeryewYgnLiRYC23KhZceVXez8yy0Bwq 5lptcH0a7wk2VinBkW4jazVqawSXTV+VUrZ4O7I70RnyNNbKBjb0zBqWZFzAUmCtHgk28MRKHBTu /HjcFwioJisXTc8n8iX+QEoL1dTWECChOyBsO9DMQiuq+rooFjwAfn3lGgePO5/KipF94JyPPveH wyGfz69Ktai5HXxmUwnZUShY3LtHSrYRHnaKBYvWMoQc6//V/2LjxjZywAEHXHfddVixqRT8r3/9 6/TTT3/llVd22WWXcmuydkXySHq29tpr44NWTNNnRYqGKEHGwgrEiEjsj2xeg7/UnXhhJRVMvR/q ZrVVFvUFtSf2lPWsaL9YvDVrtcjmK22WVz7tc7OKuaROrhXe1kF+/V7l98vWTZvsqT3RnGX3q6ny +wPaOMBFhGNSaUI6N1ei+vu2L4RSUJOywODQYlRw6Yn9O6N0B1UseCBC9bmfxumqhAhoHhqAtr1k wdOVq6h8WiyZ2vug4syywETTqzKzxYgu4YeisKg6sxJuoELbhQ4DTETv6LI2C5PbO6IBqFHkgTzn jeK3FcSs5BnmVHHLwI/umaZiWWcwWKQCr+rkIL0ttoOfjT4I+fusggFmVvY5USCrzywPZQpIYy3J 4YrGixylj2tgxWgeQ8bpl4ZM6H0Vaa7ATwpynhtyzRZXN3qJrnBd7WYaJFBDUUnTpP9q7aGVmoLi kUfdNlBPFM0Vbw9O+T6P0Kwo/eyZsr7cVXmzXt09XR1QIKg+2Cx5YdfemZVncHbRyQP/62VW41YC RdJM0bKRy4QSE2inIacrII85XeKuJLVMDi/KXal/qyvgIPH1zqP/0nUz6ID6ZrYE7Oy6Ak6VMVtA BwxRw9Dmdxf3Yq1LlgjVs0HTsRI64BBavKjtKqhRD20Aw0jZHOibselzp4RRVygDigEeO+/C7z7+ 8Obvv2Ms6XhCjCRle3L5bPaZ27xo3K4R9eXBKgOrfqquHe30r4BTcT9d1UU6sGtV5SQml2mtoED5 r8rUiiIcdgU6YK/2rgepLB6E6+TJeG7EeiZLdyhmBs+gM+6ocUkseZGFpJXen+hwKwUt1B0Mejx+ DwfS8kN3mTZXYkIJUbVaK0o+DshmGgwaGL/ByF7qC9Mc6exyuj1ONG7N84MMTLb5bJaFUNHsYI+A tViAAyKtVzyBmaVxqeyjmLKkx4qJXESUiGAJKLLZky3L3Da3MWxYZOXKn956O0VMs6WAc9Xj821x +OHSrIoVFf0pn092ht1K4y5fU5Vnk55isyXCDs1d/Qk7GF9BKygArYZAByzNLHeyBPojkpcaL9EE dEDiLIUJB5qsis4Purr7TkBpcVWUFmJeWEeSI7aasnu1TSWl/mjxrWWTfmqFNq3ZXd+gv+UnuDGx rtDXddddF7kPHUtKum5QVNohTWYqJl/0V23AHRrRsZBIWVM5cATEGEeQJtonIP1YvJWPX34v8agZ esIFEXWG4xDyQts69ZD7B6tUTADD0QAFRUNr33ZhlLqa2ntPPmW21XHuueeOHDculYrTPUk/UH4U fVJF/dLx5phaHJjdxMWBqolx12rxO1EkS+ukwsKuyag7qTtWQdiK+/XYBxxXf4Lo2/QU6ItP+loP ixZ2vtIz2+eUquo166XC6CSNR4LNs5IFB88gLDglBFyDwBMo6ZGiJiUJgbyVmGIstygGUg5aMKrE 7JhPY77MO9zAuTiiyYzd48oVbEgmRUsLNlS08JLtSs9Uqav9BeWAzgxGVE6BXlIYUvKCjmgBzTyw OrWxVojAjmJTyvJAl56mCibsP7PcU6oM0H/JVFjkdSJFcXliYrbZMmz4hDAV8g6McoRDJ1N1dQFS NmGvru7uBm+94XD++MknJx5//NjRoxWjWzacNu3K224Dc9burcmkcpBYjlyiHedtCn+DNaWZ1tEX DUh3vlxcDGSv6KVFaVyawUpZIPoOmhJnjCquxnvWLG+GCBsrkW6wZViaWToPc9gIWxSsOyCxCpLi ZxelXtajdlRQdLsvWFgxvGJIg21pgVTMFK1hPdbG8f61vAfmj55P/3fBPXS7g30L+bTGTZX3PupP mWI4oH5R3qB4NaNRM5jFkCal8LjtfmVcG/ziTjMat5ZQuhA1TtqqXdXNcucA+4GSow+cec7cr764 4btvaVlr3F7/EABDPQMoFOIrOj2j6lGRhvDl6t6iGPJmwPNBOT24E10P2latTsmdgsetak6aoQCH M05jusT4UGzD2T+ezMeS2LjNNBvrjnkCbqR30b7Zr2ntkEAYJTo77D6/w1uFsJpWsGh/jbt/tzUT ApRmpqvhji6X18Or6s0DatyDiXhYC7FVnbA4wfDhWyzMbP8O8HmwdUVk1Uqc0fFQ6JOPP3z6yefj cTlMjBk16l933VO/5uR/Hn/cqta22958U7TyEuAUNu72oGdYvdhMqkysWcLSGUStmdWtty4owBT0 r0VVQTG9DPXBd2jBJbwdQeNOU/i06mTRFBr3wKu772NolvWiF1epWf2hNlesrjhdbRv36j6g4n69 vegdUisX+ir9s+Lz8nsGvH+wG0rNApejZ6vqnbpvZu7UHa56Z5XbVAtNTU3xUDCjooxL+v7QXVXf WpGEYlYzMa4KCg9BUoZf0s2H6EOFuK9K2NKpq8q4xLArPTBJWGVi6723aFIvukyUuRNXgVjAbZQF IK+3arOrNa7V4oFSbaqqM6unoGpXV3fJlPTW/h3gWR+89/4+e+2zw9bbHjz9wMuuvH6fg/b/87X/ OPGs0w8+5qj6USO4gUVEjJD0SuLRey5gs1wuhVVQdWJ7SVuVW8qHNjQT8m1JUa3arPkFq3FYzEwB 95lZL6URVYiXcqH3P8vV1bBx/8/P4Id0HY2bOG407oqDtq7yrk9AQz+CH6IbanWvtH4G+0mmI2xz Oax+sPGk3XLg83KPNe2UjOxDdEA/ERu3ztqvuHPAzqA+MKj+Nm7hDqv13lPPXPjLT9d98RlNSV4y pRY9/eAJe0Jher3/KJOhuKXWW1HNYEB9ShN2wMrlFYceKMAnJTPcELRlCjh2VKgPFVOgG6cR1FgF ezkk1Lg6yZM2mY+nSEUTc9HQaNcSJxD3UNtIgSYQh4MD6Ks3X3nsoQc7Wlu7OjqGBWoBj3D4vMls bp1pG1xy+RXOhiYxz6rAA1nnfburZ7ZUjLzqzGomxNEy4Dm9zIIlJEiGo5S/IXpVEUQ6UB5YwnNL nAxfwV39j0cDzuxghK2YVv6pq7wXF5eMXYza0hlIYbM+fved77zw/NWX/33ceusRLdQWCo9aa70i eVTNv3+cfNKHH3w4qnlEbSCQcrj+fuO/x05di0iVeEfQN7wRfL7Sii1fU+UENl/lvXx1a/4ZbGlL Pnkmw6ZYxV6qDDUc+1gCQ9i4i5IdusRTQF/Y6ogZExoVZ6qkqvXtjQJohAkVPnM/waVnVo9Cu/rK D3Oa30oAxaslV39XUwkdRYjMnTuXvk6ZMoXFrA1PusfaCtbfYFc+Hm5YLRu3kUhj46ZGK63zGEAo rBITVrRxY+Mst8fp/XAIexnf/j+3cd9/6qk/5yznnn/e6AkTk/GoIRVyJcWKDjPhYuMr2bjzhgcA T5XKIXkHWJk99iFs3CW6lcZVNeq8nAJamxiMmfj2/7GNG4M0q0UK10tosNi4/c7BbdxgHKugFqFP 1o7RP5+lJPSnH3989h+OOeu0Uxs8HisAHQRTOxwtkcjDTz/73mcfuwMBWyCQs9ri6QyIbuC6lUan +arEhP1X4P/Nxg2sq3h92UgINCZ8njIg1AcrCSS9hXNDyRdSsckNmB9Q6i1vKmaqf9R5+cwC62Al 5bAA6fIORennHn/sw7ffvu3+e6FpOhq0NtSSmx5r6/DV1DEj4ALNmzV31udfxCOxmkDNvx948J4n npqy0Uarli8bOXpUNJ1kT/p/aONW0F29zoOhHXcl0/kQwl3PpkkbtysjoFyAnsAN0IlJyiCQB7dx I8q0sq8FV4U3q/RhycZQzkjc//83Nm44klQd0AHB466gtZmoEv0TbQUzW3OyQ0WV+EzVG6RxMxUX SzZuM5vk0MXunrjg4m/ffvOmX3+hqWQsTqy+v8YM+EMhtbLbMRwIlOopr+YJCxfCYWgQVc8xJRu3 GQpoZcdkzclCIm0S/iIUpMK3mwSrUh9evvXfD91774s//mQIQHPxmvvKi0cdd+zH3//gnzCpam/N l0ZcLSYMd3QSgEUMb9UOaNBjk6UsTRIWySXBwoN7wB6+7dYn77jzuY8/8Q8fbuSSsWCXr3HUgF1N zJ2/7Tbb3vH4U1vusRP7TPeyVfXjRlXlFpr6/4KwOrSp+mFOjUTbuM1Yk3OxJAhuJpmQJETCo6ua zukAujk8o2PhShf91zERVRmj4obf28YND1W4iVe3x9xvhlFKzYpyOnjOXvnT9c5ppj8VeTHVfjKU Pcfj9YGvplsQXEhzBa6gAdlufc7j1Tph5vvSsc7MzatxTzXbV6kp0uEAnTPbsgqKLb/ZarFnOJD2 YPvpr2rq69OJBLWCzTZr7j6TrKIbI2PQ5OKk2T4ZqkN3xhxhdVeHMABi8mqoq8drIk9TlTQGe6y9 ro4SEhwa1DIkbtIztFvSHC373LVahF3NlWiqO+I3MnWj3CR40eaEBqLWzLZh+snFG6srbqvb4oD3 6zOpNvcoq6ZGVNXYoJLGyltJRh76pcCFq9+GCYzoPbejYLfLI9QlIJi9jQsscumfqhtiBS32RAEk S9Whvp2R21TEnr6//NX3Tn4oEB15i0NBbxaTdMVqpsEf1dXW3pqvqdXvOfAbVnJ9VTM6SbyHLDrH V1snVIB8Om3nSFfeN/2Tyv7oMWE6l6J/fcYywP1Ep6eknsWA9Fe06umGpIVLmbdqM6Uf32NXGWzK SrMjUSBup5qhSrL3+62cabN5oGVBHyVjQwxuTp8X/FojpTbCng/x/9rdXiACFIkF0zULipHKf6+c WZqSgDZh0X6U7NMf3eEiD+h/lFGeEZeTWr6yCii2rl9V0XLPPzVzyrds4H0J22+m9J2qvJb6ecVA emeqtKaYVia3585skf3E1q74MCtFggQ/gAs3g80uvKR4HwhXuQfVh1FR0szl4U4nYZf8DouTQhoA ZUgDwOpZGGDJSNFRyQ4vW3oDcw43cOZQjRQJ1W9Nqc/VJfdIqwq8t+fV/+lFqmJXK4qaijXSZxGx XglwTMIhkEsxb3nj/QRCFg9BsSdy94CTWxypCDslNEoj4j1nXNh3aPPs0IL3d3JO0sUff/yRUG4Q TtiCBHmZhCKFKaFFOX+r72DKojQE9kVxqAQM4UXMZChwpauWFPENyjIgSoUopSyAslIpRu7xtQzi JdW6ufS5/9bc+xMM9tTKwtMIdDTlATFxqthxC6BXaT5isLVO/31nn/Ob23XF5Zf76gIhlRquoJrJ W5MUK0l3U8XJVIKEBK2r1aRYSmXKVE5qWX80GblRYsB1XcT+J4++/deVOAZlo76Nc7MsHBPXgIbI Ep1KrRaBqNRgRT8dQpFhEWYAsAeul6qdBEXzrySh01+9/+k//3rZ2+9+mEzHC3VuoGcorhWNJ7ff YuuPP/+kefzYFLDJdkuCGUnnHQZhEpUT3NvVSt9ln3GqohzCriKTFWuVYzk+ymgAAP/0SURBVODo ySpd4tpJgSUgXhxl48avo9yTPZeOytCUV99QWLhYwqKsld63UJ4fw9hF+69EPPYdSCVb6jIVxZnN WjJELLsx30aTtnTe5/Y+8d+H3v/w/VvuuMPhcVlczjR7p8KH4DF2VYQjFY4EGpuCq1prGho2GDfu rVdfG7flluBuZFettI8ZbSSiaJ6U9gh1d9Y2NMQQRf3WsBBWayxV5JAgYlOaQNYiMfkK4aR8lnQk lRpLsaaxGK/LQSIHeYLGVxkAbKDv/VooSZo36wtPifgeyjpd0bgCLCrG1KiOiXQukx4SIiW/V3ER /YQbRCKakHvcDqdHBe2Yv35X5yTdwtAJVsmKFStImq/opQQ/WNG3qg8AUoQiEbJXzIwzHAnDB1SS rHpzLBGHacw0S10+9I6ArzpmMQ9tDWUa/SzXgY9fz/7tr18++9zNc+dyZzZNBETG7TFj4zY6ujsb axvM4HHHJIbX8A6AVVJJkmg8hiyuDVRHIoYC4OOYoRXPCEUjPtCobdUL2MMDNNtQX191srghHO30 e+tUFcHi9e7jT1953oWfLV1keHqf9f277x99+OEzfvg+MG5s1WajiRhGDZezOregXgXD4cY6U10N hkNwoMsEb0P/RCrp95oATzeMYAgMFq+UAap2hSJhaoz5/QM3+/htdz7/0MNPf/S+I+BPhyN5h9Xt GfjOFbN/23Prbf56wYWAWMSSseUtrbWNdV4CvBrqRoweM3rKuoN1JJ6I4e02swyRcpF4tMZffRVI zHs6iYHRg8Wm2sUUsGDNGKygP5tiwEQHeGYkHiMlV4cPDn1RSALpXSHfECNg/pjxVFU0/nvbuNlC iUmqsNCX+mTStNRXX6lCL7N2a4VkgDZUjf7yffm2WvV+jkdDwEZLUz3uNY3KULVB3QHc/UMgK/Vp RJmkzDSLrmASYVIDQ5hqU6JihiBAZU/NNqrqylckH1nwSbJBUh2q7EInAm7QZFk/GX51iO8iD5iH cytiipqjl0keoDHztCpL7x+gEz4vZeV9Qk/MTQGibAftaFNj07pT1r3trjumH37gMccdf/0N1597 7nmnnnb6wQce9OWnHw8xPpMMKLzdWzyvCr3oph1ThUm30ACgaQO3r068pkirlqGkZJu6+hbzKv5E GV3/L1f1HeP/0nrpt2wUnA5IfO/fmk7mNvMUREZv4Gi1H2DOHDq3sNQAKdelwkJDt1pefqna81ld UnNysNvQgwBK1t+qYlGmxIbYPaiyZm7KiyBeVTvaE3doplU6YLIygMgX09UJZJc1xQIyGCkEVdHX aAwHUL47WD5W9jeOvuK0NHFJ0Ki5Syooml2yUo6rLwTvoM+QPc5cGQFNWDOTxZ0CPTr40CgBRg/j YEMSMhuJCCLYIBeleZ558/XPly9ZGk8uLqS/X7liXjQ0t7Nj9MhR4c4+ZK9oQBteTF5DwAX3aUGl v/fBJh78Aao6qilqAViMQdJMV+HWXMpUzQfFr0WDcN+WK5UPM88tv+d3snEjuMHpXrhwIUDehKlJ XVQpGSxWblU5sIARUNO3aGxWpO6tztfzT06UVoXn2f+23pqhUqYWcIWEx8UBhaqyYjcUZ6E2Y6um ijZu8XDkqOrLJ6q4kZS5UxOtcMjK7tfwPNohAmo09mYxbGl+kI1awMxKHcYlVbA6OA05LABrWOgB BUWxTYY7O5csWkjR5KzVNeuZpzKBmhsee8xwOhKRMAk1NjDBURtVXWocJBouTyPSOp0u7V9hXAL+ 6ad0WXHHpWNiSuvJqtCdJ1ROHDFwobKu6l2hRB+x+Kux6cGiuYitUCqXi0zWq6x87Dy5Z7BCAr6D AhJ1Xkaf/hPHZGKSRy/SGnrv7FS8V6qW8AAo56qyc0mID/iTbIFg6IzXgffCYWDZYCxO2+ePPPWX y/723oyvrC5QTwQyHOjnjuUr9951t3c+/KB58hrEwGdsBiU7wUt02BxCpfLJFQhyqZGhzfelmWWM UhyprMOqXC8BMBmpa6zYFY+Tngk9Uzo6SPecjoA7L8WCSVyQ2roSpEyssBhxi5SXeANZAwoYHh+G 2yVpaP1nSq3/osdCwaFndU1bySsqGwgzLmk+PWxJrBKuDsgPuovYWvNp/AHxcPiHr79dsmDR8OZh 77z2xoplS+997mm6A/HTLgrLyHhlx1Uv/sl4ICYznk/FGa2ztpZ882QqE6ByWD6/3eab/+nKq/bc Y3fhMKBL+GnZygXYRHxIKtmnP1+V84xwC+Da0oZLQWCKXb7E1XIno2VlCK0UEXNZTCVqFRRTqypm Ss8CzUqJWgEyFHeu7kT/mdICQaehE2PjcrlVykTvTMkKLxMIDJFoPiyxKuNXzPLiWe2ZOGYKcvG5 RqUXf57U+wbxv/h0ehUOhekTYC8i91bn+l9s3Dxex4QKx4irOaPLkvGmPPIfcxL3YObX2Uo6Up3I U+oqgFWi47jFG5NSeJOsBLgNnHeH1K4aQpVRDiH5lc2t6DW4ikazECyTzAjsopMFpuZKprhIIT5B UtBP6nw6Pd5sLA5rOTxOLaEUN/TifauEtwJDlOWmClGzcxDmpcSbXrKlP8XP2LVBSSUChHVCsoOw C0yQyXQtX3bMQQc01tdZ/U2xTHafvfc6/KQTvA312XBIlB2VziDV3aVUQA+8uhIHgrGpJDd/UrGE N+AXtigNp29PWMxSBUJhNsmPKaVoF1FVutQO09tzbsa0p7quvrFKVn1v4wKU3OOMVZTNJJJ2t1tW jaie4sBRnpxS80q/0GAhdAPGhg2GZE2xUhDrkck5ZGaV3B7sBzJPllhXBztYjbf2hvMuWvLbwsZh w2b+9KO7xvvAC8/VjyYMuZCLkK/oWjJr7n677PLjr79YGhs40wmGEMKe//UUqJLRqNgM0UqZX8FO YmbVQupR0fo4G1UmgbiH8TmDha2qE+DE6NnrFBuU9ZyBRIMhSkNQUkCcqdrbVuYFL86UJo7I4xzI 0eXWrd6ZKrKZxLgKzTkjCqKDcqqXP1E3VZxcEn2TeT13arE4sBxxdzIzfedd69xeB4kmTsfmO2xz +Ckn+Uhwz6RAYGDnkGaVnFPIdT07ue65KjIgoSZJ6lw7QZ7cdu11Lr7gguknnyR+UrVwythMQnly LHM87hI8JyrFYDPLtxKakc5ZSJpThJIlrhDi9IB0fAG8JXqJyxXt7vbX1kmgECYHMTXKAilRQu6X eWLslnwyw14NbpSYQ4u7R/+ZUlWwpVQyM+tkGDy9fI0IGcqkB++pry3lBoubthLa0gvhISGZVHm3 EG0uP6PjxKtKzYriIoOLyT4VNUyEtykjbYmqqy24xayD98blevXVV6mHMHz48O222+7ll1/mw/XW W498SC27+SceyPfff5/oEbyRWNC22GILvkKUz5gxg3BACuhUrGLi3mXMXhPOyXyeQrFU4B1SDhS/ jHUGBWmBogfVrkwwBkmdpLpWu6SmbTLlBFDNxNXR3dFQ2yAc0HMt/v67Cw4/+K83/XujPfZJJuKy rfi84vWOxxActtpaE60akRVtvpGNZgx8AlPJcjVTADcKyFTBVlM9T4TNINbe5R85zExXs8GYzeci PrnqzSyDTCzuazZVLjnW3uYb1ty5ZPkVx5wEwt20jablnfYxa6+x+1FHeBobSs+a8/YHJ/7h2I+/ meEYP7pqBzKhqMhgE+laUCAVjLjNVfWNtHQ4A17EcdUOwADZcNxpolQuTWUoGA3MlgnnZC4MXK3F 4u914gUXLz1ip90vvPrK3Q47OCYOfNZIQIRUPgcKbn1D9SmQajBLV9jHjzUSyV2nbXzySScd8acL BxtgJhxD3bb7qnsRJbIwnLDVm/D8Z/PRriB+UTPFgtPtQeqAC+BftSsdiWeSKR/gWSauVHvQ2VBT BZ5BtUOREDlMO/t0IJekvkJKsNpNPKv8ltV2TiJb0aAvueSSxx57TKvSb7zxxtdff7148WLK35QC 1BDcLS0tDz/8MF9de+21vCklzvETnctXeZn3oYm1wqwxUgP2mCILbZprVrQhs8+XoKkK3xy+9Qbw DewO9DVvba27JlCE1VZFpUx1FeBQcrZN+LJpTRQOc62qAnimDLfmrauKZ80WC2aeKmo7DUGNPDCk Eq6dsWcLx1/4xzPuveWs22+cfs6Z5VKbG1BqYuFo/zqtA7cs2tDQB4Oe36E5mnNI8AMmizOzqZll Ckw3K0XLTMysMo9UFDgDW8HltTrcKB9Ou6+xwUm+bnGV9FTSqN5dZYPgcjixBWWTQ2ZO9QmAHLpp FWNn7jI/BZXjH7x9MXuYExi0geXNtHcRv1QliVTt0iF8CtWpYNbGLW6xfP6YY4454YQTtt566+bm 5uOPP/6II47gDTXMXnjhBV26DJX8888/P+WUU1C0f/nlFwqVIb75ip9/88032lTCPVlKiMaSupqi llnKxDwo2bT1Q44/WKwI4xW70qA+DzFsyZ048ahGp+KiS4iUiiDcgNeK7UesGT4fup4cJF1iKuFb dUbDPlW+jIsGH2VMllMc0EmD9Zaupq3ZtDVHmgjWHyeHO8KNQxFnc/OKDz+49ILzb7jj7pFbbV+I g/4jsOJS1ThLUkkhJ4duLPEYuu1OO8aKIjX02EWu6B2OE78cJwemVdFMlOF8qrC7ZTwWCD6kDapk FC0Kr3Lailmpt+6i2I3I1QGkQoF4KxOqCvMoI1YPHrf8EiM7h8QhS5dp540kMeThAXVAGZwNMD4k I1S4qm0aEVm86pJDjz7o6KN3O/NUAypi/M8lXMCSgBlNwfJMbuX8BYfss+9n339nbahRR/8MEfVW lJyiqVMZQFXGT5FWilEUVurAy0aTQmLYiZGXMg7ij1DIooPez4EApUyXPy2epnv4tjRTyiuhJjeb Ly9wNVCjxZQTCCvnA9Eih14yfWaWUzl2uNCsOUcfethf/375VvvuIxprJkHEaMGJhTcRl+RJlzYp 4CfA46GdHjK7YirBnJ/DiwtfWfFJQK3Gxp3XnvLniy/Z7aADk8Gge/jwvpQQHVr7GwUhRiFaDiaQ tPVSdnoZlDSjAvh6loAqbKZERV7MU05XrLvbV1vLylGGZVnm5Qu2Z6awq8AYUlSW1pS6OYRAFPki TgKSBJQIGHobTxNrS1d7jD/8gvO9QZpu6YAdz+TSKZ7KuCijSuhkyQhGr4Dbk0gHj5M46OpCuuyO 1da4+QH6MtUmyaNBdiOpMYPwCcZrXI6llukc2jfGk+nTpyO1+VbciVYrspuSlQAX8AnoAYQDyyrF hI+nUUlvvHPIrMFeUoRR1SqFuPyE93wy6P1KloA1JGIFW7BV0Ov73Iw0k0bEQolkUWmOealXBGer ik0C5IRBu+dXyuqMdVT8UfCHYOvIDYN2QKku1kQS+wPjokG7s6HBcLktLuzoFoGyIS1NakSpYlEs G4dgXolxDS8WHg8cQYiznvbFAwCL6F4RQBoMSaTCIE9npKXearbHvFjeWkW3JacLWLRolIkhZwnw Q6FaWeMKc0fNlJ4sK4RNsbfIfKldgVdf8rKKivdLNxXI1xC04is6jDyU6vVFyg8xs4Dc2112qeyM i7K+rk665GYbU0vUboe7xBlEVHgq3tXaIgZQqK3ozETQm3Jm0Lu0nlklK1h8fShf2W0lToQJkZto D3hl+s5UJW2pORmJCg6MWHmLrFWiVWmmZCGIg0d8WVUIhTxBAtFJpkhGZB36/gwu+nAkGY2mc6R+ 5dLEjcSjNq87ANztiGZjeC3lmYGtg09g7CSuqgz5Yr24piIo9Uuc7VJfEORGFjPPjqcSBaW74Nzo 7mjHPeMeM0aObWWcIw4xtDGR+JzWofyQveUuPOr4D8UeLfwjabel1pDlygPBPdoorDWGIlUVNFvF AhdhDWFJxWKbUZXYhuZDusfwSdOQnX0I2aK+UpmQbN4ycTxFXF5+34qly56+896b/nz57Vde+5/L r/nms89tdX66TXlJUHCRBOXNysagrP6rJbXLbzarcet4PgpOnnzyyZi2Eb58QjkbaA161K233lrS uD/44APs4Lfffvvbb79NAfgHH3wQeY1iQqVK3qCtV/Q1FaNUruHymrAD5vPxYFhsWyauXFfU4rJb TVgt8baxH7gGSVIofxSxZRSW9phCgzI6g90kquggWX0tmjHz8sOPvPSeu6bs0cfQn0smUTid5pIv spRkG1ajQxqGvoSwnIFMGFgBtMQpLhW2ql3oOGDF+etMmeMBNaVKrBnzYiGZ4WWtq84DdLDQFrY0 1yQ7u4/ccodT/37pXn84asBeL3j/g/33mf7t7FnuidUTcBKRmHiETaRrwfDA5rlrTJhigQ/rCtup 5uGu7r9Bo8wkEm6qMJu4WAVOn4ejTNV7s5GQLZO2NPT6JHItrQdsttV5/75xl0MOKv95nA0mmzGT AYRRLdzdUafa3GPkuDPOPeeASy8erCfJWIzNkUS4ql1lm09FIh6qFVe70OQxRsuxzwQFsIZ7agNm EnCwAQBQYK01xYSJcNQV8JWH3n/79rt/OfU07J+tnd21w5qOPf20o884jaEQBubuN3y0Hwo/ypnJ nH2uRJLV1rhRnIcNG3bYYYchkclcp0ww9u6ZM2diy8b6oXEGuLgNhLMNNtiA96TbbL/99qWDNvcg +vtPiq5pW22yit/nzFuhBqnV3P9BaZzT5pwEulSuya4aVpi1z81s0ZxF+xevwq6RGfwUWfE48yHP UmPQHGFBaUibMZqKWUMip0xSIM35xBxjohsCl0Kz0da2X99796e33/r06ac/eerJ71555esXXvxG vWbK64XPX3q185dZ3IkWmXHb6oYP6ibFEUAZT5Nee0IoBCLAxMWZEjgrEzfKLdT/NWkJRV2FD002 CwyuyfWOHmlRukvL3Dk/f/DBZy+8MPODD9P5tM1V6TFWwMqmZhaeStoVsQiJKxjeIZO20dNR2E1d lgL55mbuxD5SLBZs4u7VkBhi9zA7BUnhgT695djY7Pfdcc9dX61c+vaP3x15wnG6dxxTMv0z/vXC NDXcgQdpVuPWFjosgBqngr/aZKPsp4S+FQU3n6josj7Fgvkh8SSzZ88mAWfffffVMPDlyBg6ZGUI LVJioHpQTfRtQ22h3JDKFKJJzNaENPBbsbQ4xSipeYgBEM4mgVUK/oaL1srDP/qTqoTOoenAMbX8 HjGzqF7picCqhwKLT4DKfgSrOyBVLG5rbIj8Nv/4Aw/+57XXrTl9X46uJRADjaqq+yDmeDEOq8DE npqTLrLGs5KHKcGlJBb5Xbpytr4U0MUALCCLG3lAmemykCMajwJoZSk4c4JHQTVLMhQkkpqH2i0Z Dp2GxTfkUqsAKpGIoH7lOvV8qfjFYpHAUm/pgJye1eiwEQJpS/oeefToULUjh3/z0ivXnXvmaKLS mppAziSru1xEMYVBu3f4hEmbbbv1yvbWN95644+XXrLf0Udi9SaySgV/ZcEJLMSSdod7ZUfn3ltt 980PPzrqG9I2S4zuOGxuCRzrpVV/vmJmtagV4kkVHZFlEomsPmGgGMU1ViqHSAhbHgjLPYB9lzoM ZWB1/mL9VNFoLOAcrxIpNOl0HzS5KsqJDDazRSbsS3mJDVfZBdihBbbMyLudjnQkiF0PG9zTt976 zCOP+jhT1NR1RkN/u/66aVttDcpfympDayEWktHZJHK3l69Fkvf8m29d3JQ1IrZcwpZhwddmKX4S OHKjTc+8+PzN9tjRWh8o2LwYHCvYUneVDwfkk3JSaAQ6vQr6iwL9oV6wmixDQ+6VSFfqQMWiLl8U kM5lsVPKI5VO4HbCkgR6GeBbwquKXe0Fi1steVaGsnEZ8WQCPUzi07HHsGQKluWffH7BOefceMft 4zbbjAhjyqGmrTZvIACcRTQeaaipKSGraMbQg11d4MCSxm1WcAsrl82BlhSalP3FXOlz/UYsaMnk /PnzW1tbsX0DUFsqSMFXWugPXTRTyVi5kHE6eHxoOSv4dcEo0Ys2jxQ8hIt1CkDPmixAcpUKK5cG xh26A3rb0Ewju07fvVKdmMokqdobEumEl0BZpof9NpOxBgKtP/90wv77X3frrRtMP6B8q4NlaVbD YQvFlCyWJnWCHMWCsc+KvVySbbKRhAWTQhketx5Fn41EGRaJUudDAkhZ4PprGT6ZDjIlBWx+Ijol udEixm3uxCCoEFPJGOo/p6VNgp6XVzvUfa64X/cHF4gOIS3/Vu0mSnCrF6Yn0ouSkaiRznpHNn31 7Av3/e3PVzz8MGDHkuWky931BBMT3vnFB59+9PHH3V1d8XRy/JqTDj3uD1O32QqvvVgeaRAjKbG9 qazN5V788y/77LjLD7PnOEYMJ/w+JalTVtwU5VuuJh39h6/gqPI6KeLz0qK6h22UodWK0xsG1rWN +GG5/iHULmueb6OhMEsTBDG9JUscfplOV5xu1QdYCzbgkFo+lf1nVi867tRF0fpQXvhGKI17RiWS UUbZlurucDnctkDdTWecPv+nn6994EFfTQ3M4xw2DA1LnosGI3ZbK7qDFfw/Z68Hr3xmRXgxDyAw WgspSxYIryaHz5HN7z9lg3MvPn/nE/+QQ4W3OPEilOZaD0QTVne1P5+UMwZ8xc0QdsA7S7/VO5yO MB5CCJRmltXNFtv/zj6f4JXFfI/BMJW0+jyEAkFIYB01jwpfFWRRKJFX3NEj0YjL7ZHUHs4paLTZ /Oy33rny0j/d+dxzDetNAUBROMduQ80KhqMWu6WmLEKfsWiQbk2ZwdbagJ//L4J7tR5QcTO0+/XX X/Gl7rzzzhVfmcf7Z87wPpkspJDvpqyMw0x4eKmaZ9UBwlhcJC5WvZMbuqPdNd6acqDtBd9/e9nJ x//pplum7bhLeQtacJcqhw3deKEzYiHW1YTFxjxhSQNDxfCZgOxZrUIKpeJtVcmVIdaVrdXr/OHl 12466fhHOzqG+EnHtz/5J4131QRUbclBb1zy6ceHHXzEx9/MdJuI414tvH9dP6/qoLghGY7gmLJr wOshr9UirNlCCigQoRa7O4Cj48bTT4t2tl/x7AuD9SKBHGfvNOPnKOQ7ot3NgUY0iQPHrXnmny7a 7ewzBmvWPGFZAmaKBfMgSRkT3E1TJdKHrmdS3u1CPA0KhUkbdzgSAbqrPDB35qtv/POPZ9/8/PMT Nt6oz4aE3bxfTOj/3xRSYCTsMIKa+HtdQAqbtFhpnev/eb+ykVgFmiW6Qld3OxE1Fc8aULEarD8c 54ppztV6bL5Zzh9mw42rPfR/+55Fi7NGmAQPFSeF3gDEAdprmrwGLiBJcB1y0ojo6A52lzuH/7e+ VfxqtVgF6IKKw9BgfeivvA/RW7NtQs+e0xjGt65w91DB+qbtrb2as6qdmOjs/P0JK/En/Qx0/8du yHnWtI2b804F2hqKh8+L8lOZaqRqG0modPlV9fxRdSyrYSqp2tYQNyC1Cevu6uoicxLxjQJeYSod +sgg5o6+KSr9q3/2Pl28J+lcNOl0EQ/NEQcTHiYxiaXFWcSBRzAI+gL69Kdj+frkfbkpU0yfGBVs BTk95QtO3nGCTmHUAiEatSFuqQlgtMWyKaG+HM4jYWL+iPiNL5h/xkkn/emC8yfvfziR2yUbt44O 1sdJBI2uftDHxm0Bb0TOhwSlYtVw1PvBQCn9vORvKFKAQDEVroSpk8Rbt8WWF3MEsB5YbLIGEKMJ 3mDeBsMCE5WtYANbB4znYuyX5Pv2gsRUTik9rHic9Jnkzx5bTdWZqrBxQyjJyCfADkiWmsDX77x3 wR+OeX/efJffU0hJSq2kWWMH7gEllEQhsXz1+FIlSqwXIQr7tSQ/d4Zs/sDKlS37br3djG+/d9TW pezWCHEbLrsXc0jZdlrRWyjnsueFIt1hw+YiT0XgzyIRw+PEXFVwOkUvJoh+kHhgpsxpsxMBrWWg nGrDYUn6V6ZMZpZjjcoZL16MrtzGDYdXlJTtT+oSK2rbSzmXMnH5DGTC0160cRMOl4uEWQOYMO65 6h9L21Zcc9ft+MokOFIm2SYg8ZRfFWLCe/wSlaK3e33atxiOFJbKQtyZTzogUd4bS/sCDYest/6Z V1y2wy7bWIfXE99PGLZuoSqf9Bdk5UtMU698dP35qkJwa0rqZvs/vb9oKhcgQotkRmpOSjYBtg95 4S8o2bglI0QkdVFlYoEJQkFKrEBul5uV6bZYlnz40XnnnXvjzTdP2nV34n3pDEEHmPCYdMzjbnG2 FT2fdE87P7SnZLXkaslUYtLju1qND3CzXttcWKYwetJd/nLBqZoFdQW5wS79K21a1T8c4mbJ4vV6 cAdJeCwI8W4HQMvETkkGvPzHAbKLbkR3gO6yZvhc143m6t+4vpmvIDfYVUSl2nK2PGgrOK1Z4ViM ORChuBNijMEhC+yGx6bK++KptATqMSkbDk9ndyQR7CbWgW/LH6EdMvSEAfJsCAE4Fmg7MmRGiu2b uEY3iW4eu98rvn89DHXRJU2c3ov9yumSTopJ18rY8aJIKAiynhdrllAAzM5sEFi4sUzCkMpwKE0V Rz/wXJSsinS19DjpcxnFSp3RhO1PTJrWL+k8//d6iCbGZSe+KaeNrEgfIcpAg4kRn5AFt0E4IyDR bm9BvQyvDxwYmMDq8VrdXqvLY3G6iePTL4vDRZ5N3ldj+Gvy8bi4/BBlAS9EABncD536Tq7uLV3V 249sbxgzAaJxeyz0vz2M28moH2XUNRk5d74TaARhYJiwnAK9pMCngjmVMLWelyBMMYc+LxGBVni2 zzwJP+tJ1Lytl/FQM6tu0yY1Pe997ucfbpyytCYwSS5BHSHgnaSZnNEwLJ5MAiFNhk/B5YUVAT0i wMnqdKPZSAco363kSNnE9nZPP8Xqcdr8Lqmg6XDLMgQW32nH+JnsaLfVNeISppmKzpcIqwc44Moq /aR8dev7y0dXzuTaoceUaf7vv2ZLi0JvhJrCFVcF6QhvB9JEMrD8XofXzXzhmRDe4MVihE/gVrXs lBSxJ3Cq+3wKXBYcN9EOo5nMsIZG/6hRkoPDcqOKC214Ba9IVmLfSw/h/3Jo+J0ENx0lYUfAf6n7 oArIMhN6brTgHnpS9f381aK/ChPQlujaIrhZLVbei+BWS5b/2yG8MH2pA6VlUC6M+i8h7tfHAr4i icHtCrg9NS5PgCoInZ3BYDTR0tG9qqWtMxzpCIXbg8F5v85atXxlVxRsj2CCvRa50tQ0ssafZ+VI NcKi8NVeJv04PUY4Q7FtTw9dLDAg7p3UPrb7PSwwubuvrCwNR9NU1q8IAkFFA7XHUec3wBTyu4x6 n1HjMhrdRrPHaEYkeeRzlAH8Z6Sj6Y1CNo8Bti69SEoUKH9iBVOWCMtkDbARCv21zBawLrfXg1xz +wUZGj0auWCJRwtouCDV1dfhsyZuiZfFif5bfGWJ3HOyKtxwkvwFKbDnZXV6bIF6B1UObPZYVyeG F4GhZb7dqmav0LZyW9Y0L6o/jN3lszjc1oYGS42/+5X3ntlt+pNb7fbwBjs+u+dhtpaws6GeBrQs 6EPznn9IOkaP1FY5eAINiAhANMJzMrV9r/KFoBXzCmnVn858MuCOKL9kXwLTSqQMLxdpMf6mRruu j4GYI0nP5bcyQJfPxgtaKRkkk0Fii0rDKR9Wn2mleKbLYQOVkS0QoZ/P29k/UomGujofO5y/xumv p7XivJYxsyZsiSUqWKX0Tz3w0urWkzIgX+m1z4B0m6U1OyDpdJtajldc5fczftYXCoSkZbLKAO2T FagutRiFqDBZkXVlswv4/RDYT6YuLCV4W56EyxXs6srCroTtc8JmM1RSSNU+kkTX8sEiCYX/V9Mz Wa4R/06Cm0dCQZMgG4Op92YLCOjjUk+tIzOHBZOGywFti2/cfdthm2x47MYbn7zxJodPXOP4yVOO mzz1sIlrXXvKGUdvvNkRa6x55mab/ueIQz+86/b3H3mobdny/om3q2PwIm6SLDQzYxKFtXJ2l3SH X/oieOfrydvfWHn7i4lXvy4W2C0P4zLXtqm7TDsOilWjFNIkeaaqbNugV9Ycz9bW1Un9QIwT/9uV zc1/+8MRNs8+u0zffYtdGzrjRmtQ2Hh1gm81gJ+Z54uAM3enmdZK92SjsUyX2KAxvlELZkjKieg2 07iCfVAXhw/DEhvSk2yuSbVgh8iI79utoi3GnI2bZs3xi/meSm9CJDBjIklnvv1yxnsvv/bmfx/6 6tVXOa+wBVbQcMCZNemlGGI6TA7KzIQOdQ8xjGLqE5ANcZhwNMauq0uoyj95qQSEZDYbJ1cd2ADW MFYkSWzGsCvQTgUgH/k0L5F+VIoVY28mRc1QAoApWQqcM9OJ34+PZXXBpwLSqGqqCoElrFOeRFPy 0rAEUoxVcyEFVblDV2ItXv3L70p4kBixVfFT8CSZNnnWypa2MWPG337PvU+9/Mrzb7/9zJtvvPjJ R8+/897l11//4Zdfvfrhh0eefOrclvYn7rn343ffX2ODjf2q6lWpyKn0q1jMtFijlIixDInb6iXd lN7LLVLAleEJhjtlWin/oO6nNi7j1XH0jESNDluNyuIvxJGEBu6+VEHXE5jf+tIF13z0jztn3fPs Z1ffM+fu54xomtHEjGRbLhkFFlvoKoQrf4kLX02Xqr6qyrTi+FWhbUJGKC3GT8meAMVSZq1Y9Jjn C5yAgjaWX8gsq9uowxg3ClGjEOM9KNESYA3kqEoJsduBIkWVU/HSuCs1mK+0IsgE6onY6tUEFivz lneVmwRXCd+mgOLnSY7PaQgkPlHSRqGiVBaNFaO0KkIN0ZLZJJWI1U8yfp/fPa655o6zR1xzcra1 u+BQoYEq/l4KK6vqh8WCvgxPvcpqPZOUTW9k1qRMhnpxg3gX1HzyQ2glbA/dJFoxl7YYYLBBGV4J RSU+l6LIinz8SqL4FT1V3KNGey42rd8Q0id8TI6F6lYam3XAb6uro9vo4jU19TJ9yAyZRsXArC6p nqyKWvMbXfpX00eFvvZhA6nBXSx5i1dBgH1S6Ugy7hg5XJNLDU3NtdTdltXLJzbYU3WHsehBybjU C57Rb/QrnEnFKNfLigYLVn3Ce27mVxCEig+yUHg+aBkC3p2MRyWbLy1VPYVrY/lsMJ2M53PxXJYg Laiq2jGSNkuIJSMz1XuVShL3DlBkjsytiAo18NL9+o2isCaIDM5f4+NpuUTszhtvvODU0x68/T9f z5w5bNIku0sshGKRL6uHLn4Zvcw1KxOCTA62zKtJFWwA0fp7OCfZ9BL57JzZs7tCoY232NTnDWQg bEJChsUxYreQYkfUFCqHxGemMzj7UCux0zpIOYrEKW+KTzGXSjt83nA6bvW5krmsH39hOuP2OuN5 /vpBSfQ4XcBFuXKYRlzJzmguQ006V9ZjlyQrwK456+QKxGcKCAJcYk0ncik5Abmc5KQqGGgxqkr8 q0oXqDA/4VDVRh6MegG/L9LVPqymFscauT2vP/P8Aw888M4XnxeyKUvAmwSEKZPnlMqpsyeQxoJX Nk5ly3SmpqYW24BArfYoN/xX6nAT3iTnKTFHwO+JfFIhaxTx7KVDoK+wvMn1zWaGu4cDvoCYhoPF UxaOLP7s01H1w1NLVtU5vcb4sekmTw5nkSWVrXHhEXMbdveKkLU9Z4Qy/51+6A73/mPS1KkrH3ut 9YdfN7rlukJN5McJzhVGboRhXztScAezyaaA5B6oi/+I9blHGeQY40rh7lQo2yATAWJsM7IYqa2F rLg3La50wRtNi4lGqpZjR89jOc5S/Rg4I+X/xK6eshphmwgpl2GpTWUDXckGh48aof4Rw9595+UH /vbXp9983er3pil+4PWBBiDwxnhjqYFQsHdlwuJWUEWgWQNMmz4464tSBc5M2oltN5rsjCcP3Wqb Nz/9xFVfRzp5zuuAprCSuBx7LhYYxf/EFGtYQuFwXS2pQN2ubM5Hoc5lkV//9fiKQmj3G6/MfvHz 28dcuNf7d1vXWTNq2JniuCXvwGwt5QXSbiw3OH1Fs88n/eLZ0Lqj8kHF6apUN7aJ184TtzmS9rzd iDqMlN1IAVLtFC+9SEuBbSrwYIVlTuy/EMeeyrmyBbJB3GkBesy6LHGonRMoea3HCS6ozqhAclos XfasO1sIgGwOtLU9H7KkSFgI2G3+7ugj19w8r6XtynvvgnBA6SMFMQgQCy+6iA5VhsYZ8dJow5GK MtaLonihR+QotSxw5gWqcVszSX993Q6bbXrRBRfut8+ewiGWprzLEXQVUtRjzlk80YwHE6HVmnQZ Qao3e0gbJj+1gIcFpRTRzxh1EQpxxFstkUSczBdCEtlwvDiKSEQgn4q8MGA2LfBJstmwpWKxcGf3 yMlrxdvb8Ur5fYF4W6vXH0jEovHmxkgmHcBVCAK4WMjsoUzC4fWFLelwNjHWGvACC1V2XCpnGy1q dYwAgyYyRNS4stAmorVxNOXhOFQRyZ7O4xVJdXXVeL1H7rXPnnvuvfcpp7ans34vfgCMSmI0wrqg 6nvLForFrBzjnseRiMAK+r8UCza++OKL5cuXE0FJcOj/dxex0jNmfPXUs89oF2X5FU4lI9TTNHFB ypbWdrmR+ApUxXASAF/292R3uP+v093RbMJUs90ce6hBY+IChaa9q7Pixkevu3GfKRv0/3U2hljX 6ZlVLlALorFotbuK37d2rBQdruxa+MBLj9RvMWPiPu8b6y8Zvmfi3FsKiUwhnMh/PQutQ65ErhDN FELxwtuLXjQ26n78Sz7rOuHGRaMO4zYhZzi4PNEmSkK1iykIt3dXu6v4fRSAY0SEmaszWfhhOTd+ /uQL60sqdXKIH3WFgqywqq3Of+fDaY5A6IfZVe/kBgorI7j73JkptG11/pKDL5UPF6xsMzbPv/iV 0CqbbY9GzLTJPcFIRzIF6F71S9TjNtPNBsNoEtUbLRQWhRdHMl3cecvJJ5+/735D/CSWioXCQTNt oueDTKDZZv9NNn7y2quG+FU+kkwnTHUVpbow39QyzC1vK3zzW2FJZyEYL4RThe4hKbwiDBSPmXHF knFYy8yd3LN8+UKWC9Dwh26y4RPX/3OIX8U5G8RjFTckU8ApBv8HeUs4CrjZN9100+9kKmGTURBe AxwNJCXXnH0JHUOhjVHoO7nqD/8w1j3OMvU4Y93jv735ITmm9b0EwMWk0VAqTpmigxyp+4+A+tzx AXDGUeTL0+QGOO30fKQdOEPcUP6VqEN9AVu8Luc6Iydsft0lO796r6Oh8d2Hn/ly33M+Ofj8X657 yJDYaCNxzXMzdj1z9s5/7L7pAa/L68wK+FRuZF1Xk6ugtNWEw5Ki7ocJC6ecVkzcpjssByUTiUJy q70QdonKGnLkPDhjh5w4KS5iog/shdgiasxVjhcDa0WjNmJKEx3xiHSP8CTDzRlPBmW1SDUXc5fS WU3NLCFJjv4oNoM+RSefVr98fj8RLdzH+dxLiMXgv1BF5sxdnPOUJo5SCvRdFb5RTk9T7dIkRyUT V+u73/1626PvHHbBD3udO+vAS40H3x/iRwk7pXlMdUD0dNOmC6eVdkmidtTX1kk9oMEvkXv9Jkvc WuYYY7CGbSeddBK5iKVKCCbo9r/cgoLQvrIFgKUxtY2cMi2JbDTFXpzMJ5JOTnZxDGRWI479JCu1 usPp/LJ2S4Jjks2Ix6PJaNKS6wx35yKJWqABIjljeejX6x7wjltz2bpr/pgNdnW0rLnGOtbmJrIV jURK7LzL2izprBULBFFQ6XhXJh515IOFVNhIRwtprGDZWDIRiXI2YiPAdCzg+Jjw0qg9aNXk3iqM S/1eUnEzccAHxFpiTyUSHE4TwS4nvwT3OZVbNnvujz/+cNRhRxYEkTyfj0XSSc4BAi2bT2dAcWX1 ijk/mca0wjkO83YKO75uWT+FhJNMlpIY2O/4n4XiOOGIJZ7IJzCixQHiSFHbLJWkDkU2EuaA2RYO OomYSeeNVTEj65731pftKxZOnn6YMXKMe8pIZ1P98JETYp3hhe99OmWDXYxgTfihx4MLl47edPOw Je9ZZ+KIo/eytnfNmzfnt3D7etO2wFTT7Te6bbmkJWMDijYYRUmmG8WxZzLJOLYB8n74fwrFUAqN gTtIP1OAqqfopyWRMWJpeUXSWO/I9U8A0kqHLWJel4M5SUNoiAnmN22Jg3GUDhfSXdZ0hINxMpUL x6xeR6s3H3R5Z7cvWPzuJ8cceyx2omzrigwcglmQB6Vy8IwlYURiEalkiI1ZpUjTJTHBq95CUaiU iccx7hiJjCMQeOqxR9cYP27x9z/N//Z77N2Ez5ADlhI7ac/kptOxaBRbNUubN8DuWLtDBi8qnc1f 2T53Qas1NnHXXfJf//bVU09NOOMwIvQ50mO+YIiJTCqaS0ayiSgGVxCX08kMKI+5ZDadyGQBScWm xYSKVyKDVwIoFoDy+BlumHiSlyWStEaSimgpI5IAn52YUnHHMKKM8Ae0DmWSnflEh5FqMZItmBvT aXcoib8RMGJrJl1IpS1Y8HteZBK0ULCPaOpIyhJLwG0RazISDlEy2ZNKzf3sq5bOzp332IOAy0I0 zLCxQ6ToezrOmSCVjmODpb8QlE5AWtQOYcoSi+JQYnxgTJMhwUEWkoVCzqbGp+6+Z5uddlpr5Ajq VnB7yJJps6U7LNJ5eyTl6E4AjG7JpqPQJ4vpS8YVz3MrhkqWYTrJC7TqbNpGt1tV+d1I1uiKSPg8 iwIuyqRjoDHiHAmG7am8pT1hrEwv/eT7RQ+/sPnmOw83PMtmfks8afqXztjM3xJzVnoDTTjDsLYk jExLKpx2GDFMRvEIgUexSAzqCGMqXhYPSc8aFFZKCaox9E8lU2K9BLUkQY0auZ9XliyNlOAiICDk H+kEITtOTEvx2L3/vmXdzTebts22iAjBRJaCmNBYOBP7u2hvqhxliUs1RcPdQYQQOnuFxaaqbEXg 04uff/55NWzc/KYU9ayTaMQgS84bNXjKrOza7KhsZLIta1MR73/99ofOpSv3PPIQwbkXkARxJ0rN 7GBUrFzD6xY8/OKCYPvuD39P/FZoXIPn0N2ch25rJBHD4CHZMBVhnhZRNbHe+K17yeTdhj13l/fg zdrvf9N5ylXONdfwNDQu2G0tz+6bj9p+cwmWWNhheBxGc0Aq5YnVsCdNQ2FQKBAeqVaHyzTaHaIn /tqa8rwpjVQhGpaCqtDF7vhJOBSqa2xgMlS4gNgoX/r37Xfccuu7S+Yjs+Qp4vDEwuYgbY+QW+Lz xd7bc7TX6QkS1d5rNrbEI1HI5VdosbIRE6iv4YY1Rof0QOmD/AOz7uIV1slj0ys65r783vwPZ7hY 7sGoNZPa575/GWuPVM5IYPFswYe++vRvf193ykbRcCKx4LfR66097qN/g30l9kXasRkfX3bLqq9+ OOKNhwwHFb5DoVzMX9OEYR33KwZsPZ/KUitB3j38xA6EYIzW1NapGAApy1skkuQTqZALei9YGaKa RqPdbhR8p0sIrm/UtyF5cTwoTVRaAGIsmVre1TJq/OTH3njqoaNPf2/xEhvUSIH4kCeUS6mXMnzZ X408QVeB2hpxZsJ2Ku292Ak1TZhBVbKLrXXWnLPOOHP2L7NGjxq5dMWKPxxx5F/vuFUYUcpF9oaG 8BOAZ7Gq4RWv46HkKDF4gKqjqVlH/LW12b7TIzclv5v72SaH7PrT68bkcQbOzkjMGKZ0Q7wy0gc9 Qeqv1Lkt6lfMZFd7q9vr9XjIj1cfQxv4qEQKNd+KCgUEYyQRqWscLjA1PYwntqsecAw+1bhg0npn 2KAaGRFsfTXElML/BxtHMS2QU4XW2KpGYi1djbedcPKK9vZ/vvCs8BfcqNw4mgyKxyypBI69PPZi 3adioV41FLlZ2EDXzBQmTLW1e4c3FULh/Xbc8Y9nn7HHaWewZVIQByVFYzBJhoAY7Q2jNSqA6fXE U8thReZfJ08VMUCKbIZKtPLmZxd88U0+4FoebB+78QZbnHm0q7GWr5XvIIf3AjAd0ckcll8veSz/ /Ovrv/ekQS3b06597bvPgqk4EnXslCkH3HWdscVE5DDIXmk2D5s9Ee7Eq+Fz+3CWFlV/1S+p/aux gPQFMF0C3SrNMtT1bBXofW8/UZx1+o2qCmvpXrnUV1vvTKbPPvTQ7Xfa6YjLrxDoMVm9cnRRy0cL xUIiGmMe4VhdFFN7P4C/RzASSmj+qK27udoJOFrSP/PMM0Bsv/nmm/z+s88+u/fee/knlprSMZM3 /JNiC+gvv82bv+C3BfpYy4Dqa2pqHJRwBovGarjEgE9YpMKwtxkeCTXNh7ObnncbxzAjFF7x5sfh 97+WnrrtFjfQXaxfV2rxqtjMuSt/mtUya06NkV8xQloetv1GH2w32dPYZFCl4Zn3v5sxs23RspWz 5idnzDFsXvYAIA0l/pIoM/3C/SJR4zQokQx0OOALkJoBwfln6cViFkA3RIDELiOH5Wamzg8IDsGe JIBQ/1QgpAQmiSADGSP95DaXWxytNlIW+S95i1LzVGrQEvzJNq0SanT5ElqWlxXMcIlj1o+W2GtE EpGhvOQRABzKX6LHgas3PC5ruoYMEWfME7v0ofWWpicutU1IBHbZZl+D6poIZTf3SEBS7brNYw/b bYE7ER/ptu+5eeOhCiKG/sqBVN6u15LfcpkRe/vL7s9+sL0xv2lJnVtSRxzQWaX6FcfOex11rcN9 JVaYGilCQofk9dAledFhu6xPj53cGbyRKlbeDpQDv4CscieY+rz0naqGhjShwve52ZLzj02NoV97 2kakguEckbCIQOL93V6Bq2eaCDRGmNKYww7EnZBPRcby+96ZUvHw3ro6wmvtXu/oTTd+6Zuv5ibC HyyYe8Ypp65cuMROIoyHvCQ1pz0v5oUpwKjjxyFJXC2PBj2ZHByvb9zS/NS42Bncw5p2dq1x92Z7 3rnWto9suOvnJ19YHHixD0IXcUqRlEB4jE3+8sKk1RCo8biAImJahQ7CfZCLMyUvZooX1OCFi9Ln jnkk01X4TL2E8JBGxahTX9ILLekVP5d0D4UYXKKqpi3xxFJlAQQpeJ4kBubAWU+EtXLeUp8gg6as ij9QDRpnGTewBvUypGV4k0frJyv6KG4svpfyEeI4lxvlr495oYXmYZ2trdS/kIIGXuLfGbssMVmu VsUbDNPwGNEsfZaByzxCimLTMvs9I6WHrmueGf3GnIlfdOzW5g///YHca1/FZvya/WaO7edlyhVv T/28MPbzvOCXP9cuXdZCZYJ6w5gQCDz9zyPbPjkjPPPsm+8b+f0cY3E8+Pn3hVlLjdnLvDCiYa3t 8AZyLhahBKvrBwoh6UYPh+tlyL+oVyX/AQCiOF6hphIVUjQDNilKA5zuNtzXDo/fWlsXDVGSSSKX iCiXaG8YVfhJ58tKawRNeCTyQgohFVe9zYpGB8+srtTu2WSUBC//xxDvEXDsINQko1Iw6Kyo3nfd ddfcuXOxlHOmKPWAhT1v3rzzzz//159+Pue0Mx598CGPrpDAJmxYPOyZ/S+8/Govmrwy1cB/Prkt O/th/4h6328rF1xya/t1jyTvfMGY3cI3X11y/SvXXWufdoxr+plf7LGho1aV911rxP5v3Wt8dWv2 81snHbDbRpfcm1/jEMcGR6bue9ZYtNTM6NKxuGClmrgkmKffnSgXzFj/X6ujRl+NaJBHkMXOojLx fHUL4Qhc6fSajrrRf5g+5bub1//oFveVRxij+yDQWzaZuOEFJ+7x2H+2fvaGzR64wnfyvhXt19TV LIl0fnnwJd/u9sf3z/lL/LWhDIWl36JzcPg32VUrJouKOortQePfL6XPuWP5yf9sOf/WzovvXHnq 9S1n/iv1z/8aX8+UYXUGGwN1Q8dxo+WatJomVq4oJMX9EI/FGvxDIfRL7GVFwUOnJWUpRDLKS0B+ 71GHHnzRHw8/9JBd195gZLZ6+WNNomQsQQydGXIRi+LrX/LiuRnZP94RPf76/Ek3G39+0ljUgwoS An3UVKo0xgGtVbB4SSTpi43Yt18D+m8G6Tr4i/qbUcNHfvXOOw9e/vcnrrp69uPP5YPKJVC6lrYZ Dz73263//eZPN3Zecodx85tDkMKSSa5x8MHjfryr+aIT1ps06dPT/j5z9zNm7Hpa17l3G6mCsTKy 4JhrPtjptDd2O2XGz18t9WJTVY3VFQ84aXss5fK9e/yJb2975MfTz1l09vXFZ7GyTIP4m6zRKi2r IDTsCcT3UP5wiHFJLKGAb/a5BOvTdJnZARs3K7j5MVsIJW8+/fRTSkcinbGMU0WBiBTKKSCvdevI d84FVCl78vEnutvbBWFCxfUTzJcMRX9686PodwsMoGgjBWwgBvgAbd3GNz8lP/git3B5LBlpDzQb i1fYE5nwHhtbVrRPevWXwPVPf3jlLfmvFxbmLW20udYZOar5p7fqP35ss7+fNWHiRBGMiSRhenAn IBOBQ3Yf/e0rI35+rXD5eYSKGOGMeOfiOSNdMKJxIxE3kvFCKg6gkZTvlMpOSczQ2Lck/heLU1oA 0vgckDAKumOK1i92VO5kCIRPI7gxy3KKxyNRiCf5m+Ee5oDIxVgiG47QnyzGaMzBBJPKt/JSwbJI vOKr1DJveCI3s8CkffVQbJfIZR6BTRDTsBgxqc0RkQDK4GUPzrro0qXjDlp+wGnfujqiNYSrcihN Z5zppCWL7AfXKsahVcKWs0kCYTNB4qTzOeynYpsmximZiOVh5WTaeepBOzz5711ff2DXNx/ravas IK46mjFYkNChbOzQAesBJ3lMqPyV0o15bKGcTDElJxisEUvJD2N5ie+D2nQiHDVA1eHkmEhbY1HO T0Z7lxFKGqFE8qdF719/64LPvgjPW7Di628XfPL5qu9+7vpu1jMP3bts4c/wT9zDw1PZ1jZaxqaf i8WIQJe5UCVycIFALpZKgTmSycKoTcd6ZyrPpGBMx5SaZGZTMSzsaufA/oNLwyDuP5ZkIH1mNiGU l0AdRoeMe+6rudOOfnvzQ97Z7JCfWn6KrkWhhkLBZzHuOrLh6hMabzqPRM/wqhYZMi8gTYQHEkIK edE4r5R+EVyPkRMTvyBXiP0dsmeNcNaYu8L47jfjh0XGT4uNnxcZXXGhIcaHRCYSDWYSkQL1RmDX jPHDAw9/9OBjy77+YcFnMz75z20zdz7+l62Pw2jTcv8TRkvYCMHSabmTmmSY/rFA47SBMkwitBLH DOZ38QNAgRq3F9usgXMC7mKwmHTxqAOHK+Zo/BBpbHxYllkOfehZRluaxXwM2ZkLYpoNft4V3Gbr rbs6O+d/NfPZe+69/fIr4stWGHRevgoZyYIxb9WMx59Z/M5HiU+/X/DU6x33PG78ttL4rUX+didw ZRnd8fzPvxnzVhgt3b+Mtq7MLxZxPME38emb9/jwqR2eu8u5zZS53QuNmb8W3p9h7wjtffLJR73z 6sGP3X383f8oMHjM5RilxXGUte6z4fZfP73b6/89/NtPJ2yyrndss+DiRzHgsApwFCWKDAPPqFf5 AldDFt4m0lFTAL7StxVf8Ay42uCfsUhFDuBdSIKuK5gWuQLF4aBw3/aFURWnEflMYoBeQUVG5T0h Z8JsEur6P15mdQcxvVks77///rJly6hMhs3k/vvv7+zsnDFjxkMPPXTooYfq57OxU8t86222GT6s +aLzLvzyu2/YbzgmUM1++fxFy5Yv/+359yb5f0mGw57Nx/qnTDFmLVj02puzv5iJKOnIJgIbjjkw mjeWdk898jBjz7jh9LmWrqz9y5Xzrv4X8qjVa6y381aGPWeMbWr2eHMLltvGjM61tdqahxshnDCG 0VhHyDLQFjG3a/GCeaPf/DT31cwuv1E/bU3XWuOxumVV/Cy6hSNH4Q5/OhyWhFZOtZyVowQlK4sH Aa04E1KpHrVODDI4FORULiCtllRHtyAbsOVicWvvbG5qXnPNNY1VnYIEwuptqGUZEM7GcUwCvdXM 4H0unyF7j8JS3OxAii6gbIZ1eImU2bGLHVBshYS7ouBafUZnDDFhbYvlggnvblvnnNmNahwNY0fm lyzPBFy5utpQMm4l2Llg9bCvkOtAkLvVIU43XG0+D9jYIsJ4gGigzmxX0NbYaBnlN5KYDn3Ls9H1 R9XJimoCAlTKOChgZW2okzOgTssQpB2nwK92xVsCOZsfMZ3Ge2wxflse+vIHazwfcPjydU7rrusY Y7G2pyzAWSBWiNkPpwR9KO9yt2RcTYF1/3CwMW2qkYgZHLaYr8WLlz9yr2NYnbFkKXHCo8aMtS5Y KmBYnI+x/nt8UpWXgGSB3AbpibKTZBbhVinym2y6xUtcJxIAglM0l/HWkN6NAyltS5B7UmtvTBrd pPYQXUytg6JVXCVDgDMnR2NxKy3rtsZsy5KhtXbdMRTsnrjljunJw3Jty2yMscOVn5i1dTstw+pG WCYYP64wRjYY4ZXGsADYL4CXZSRQmyrUZaBxADNhe2HbZh+l77m8nen7fNaSNz8Ifv2rLZL2er1j J09w33ylMabO14Xcz3Vl2rwjRlk6I4a1Bn5uTUbWPeHQcfvuh7PU9cwzgQQpRb5l8+es/GH2iKAa szUmywHvHWLV5UwEmp1ZiyctWUj0KhjrqBvRgN8v/9s8H2nbaFfsoESU1wZwgMOc9roAXjNx0ItR hDoahSzu/UGOiZhmMBaQ14SNHMuPqFwNdedecBGOQFdt7Q+ffPT4fQ+5YNvuLoNAi8UthiORmr8K 1K5dL77QGNbQ/tp7nU+/tmqr4+ONvi5XbpdTjnduvVVm/m9vXPmPBqs32Na+crRnzOZjZVcLKKEU zxp1Da51Jiz55Y2fz7zS25mxZSw2t6vAgcuRafVb/a5cOItzPufJWTByRaIrmpsajdqRRtYZ7w51 LG8ddsUDyYCtfZR3zNQ1nSNHFhy+kidOUOYyRIeXC00V/UI8hKKAAMaVfy343CxL/CESyo2VHvej S+p5iY4ux5qYqBdl6GPiDUD0aWeBZAyVEZaWM3GxUginek0F0vSX7mYFNxIZlHeM16NHj9bx+ajV 5JUgx+G/8naxnBBeftVjj733wqvW7xV0XC7vGd28/nZb2D7/ddS/nkoB2B9Pdu2/if/5bY1GR8fN t49eb61pfzxFEs1ScWPtEUbAbazdXFThf/VvfefVooFSviCbsA5rMNYdqb+yjRBvnq1hgvyjoQ+a 4vjdpyVfmtz60Ue++as6vcb8M3ffbre/cBejLR+wt0alOUVRKjNGnbd0+sDYajP6HH+K1GVbTqSc zSOKfeM/w2qXPfTIr9//aIwbBhvoxrmZF8XufI31psxY6E3kbTDqsqsycxZ0EZxSN66qdTY0PXBR +Z36yEheT/FDf0877UEiGpzDpWNc+q++yTqmSF75R0tmbNha15YxNizWZux/CFcEkYuziCsda/St Ud6BlY8+PeuVD4bn7d6M5ZuupWtFDtj4ikuN7iD+PWPsGO7MPfPuL48/X2fzO+JZ26pQHqSsXdYq a2Hi5Ctuci9oMcaPq/nimyUL5lq32xz5IvRsqqxMxhzlqbrZ6Bd79OCXRsv2BIgqyjo8rqVLlxQ6 wsYIRj9IoS1CIFhezc78x9+tPS829phjjI2Ks1x8yARxEBiNRmTpgoVdLSO2maA+L5pf6NWAZSWd IAtquBV9DTNs64xdY8oYMfvG05lH3//qpaemXvef1niXZ0x9887bNxy5q/HlrBUPPJVo6arxNdh/ WWL3jzZ2n8xPx+11RbGN426Z9cyDzf+4pq0Qd4watu4xB9i32JgOaK4rv0Y11kUiqzCKW9dcq43p QOZMkOlQHS/aZUozSwgTEtleK2uq+rWy25gwitvsUyZrng9+ap2zcE6bxzl6/IRsZ4d90mh8lamF ro5IlzHSYey27jCvc9i22xjRoNHZ+v2/7gGzyth4pPHqe81tia3+dTFAYOF0d83ktYx1Rvc+vWBs sNeeG2yyBVE34p9paDQ2HWdZoxHGsEZa7VbPGKe/NGbP2o2lH05zjl058+vgktdXFqKzLKHmj550 jRhZERLYf77kPJFIDYHHXc5wjkw6P3wE1e5xENciEHwum6+yyeKSQevHxxzoI6ACSR+wX6gp5gMQ KybFrKmE7fr777+/8sorjznmGELHKRl88803//3vf6cE8Hbbbaf2FrmQ75i/dUXgUD45dbNNqPWg v2hrbXXusom767XAkhc/vHCfcV+tML5cmX/z59a8pXb/XYzt1zN23MDYY8sK+WWsN8o4ZFvjqJ35 az1iN2ODSdW5inmdtvYaD/6l7sVrbR2vrrfJpk0Luof6FfEtaLz0cUW78dmvxqdzjc9+M17/yvhu ceWvBARQag6VX676gL1hAHZXycWmTkLkhpFVONjVpwki9erdYvkxcWW9Lqup4rNp28haCbUrv3jC jPnG+z8aL3xqvPO98fEsI1y0OVg4ofe9PPXjkitXrf/m3ZPeunvEJlMT9707f/0j5m98bPeR1xh3 f2E89mPwtleSn8+pSxrtLatqDt4tvsnafZ9VaLTXeb0iBFM4sbwBMfUMfsWIMDIxfMJsO3NJj6KA M+DyTRAHymBXtqMrp0CTC3W+7vE1Og9ywCswdgraXuVXizuMH9tyr35nvPOL8e4vxnfLtdum0J3I VcT4o/BuO83YcxPjoK2SJ+45/LSj5oc7OHl889zH6VkhaXZ254wn34+GMh2JuH+HzX27by6beunK 5t37rT/q2H0XGMlILDX3vS8XvvbxEOMK2P2kmwphDVuW8J7BbyXhnixzE3QVTIGYgJX2udfnCmzs HhHgDBqKx/56/xfbnvj1psd8e/Ft1obhKe3Z2mGSceTGxik75y490l7rS332nfHx0nxrR2p4IH/C rsYhW9cctY8xrqlPo3R3t2nG0Tsap+9lnL6rcdhGxhoinYmwJIOemvCD9vbRi0bNfaJ51iMb3npV fdxr51hZ9UIBf3umdcac/NtfG1/MMb6aayxoG+JHdqtfIIPw1NqcYYUGMyhr2dVprO9FCTR8uv+z 1Kax1QgHxFZQCvcmt630Hqmti63oSwOekeHDERt9k69kgAXLgh9nxbq6tth3DywMXz72QtftL6z3 /Vzyon/ccMIGl50x6aAdxASJ+UElRgtgcF/O0FIQm75AahNvO2T4Oikq3aHlNQWOh7XB4/8ec7tH P3qV0UXuMCGwrCemXEIMZT8RMIlCZsUq91oT21/84Mvzr9toaSs2+fk1/k0v/mPgnKMMiY/CKJ9Q P8R0GCdy0HCq/VOsVLmX773/jjvueGfer7LAVIQVvjPO4BgcJVdGZSdXSPCKXA9BP5C6Wup0RjCl HLPw1GtyWrKzl7a+9FV8UShLMcUfvnStOXz9B6/IAfLXI74G3B4ksU0wvpV1p+8lFdCkYWLLMOpZ yYN/5ICjN9tt73XPOkJMM5hpEJvJ/G/nXTXjhZfHNg0DDpRJPOSnr4yJtcayVsOdMxrrjWA0fv/r mZgt8sNsihAGWxZs9t7DWFpWvPC6f25Xrd2bX7ri46efx9xZ8Lo67flNj5g+8drzcJAVZQdjDCUz wGPjMeuILxpz4PBLjvBedcKvzz5z/qmnvb5kiSPgw1QNoANxILr0puqyRbDDsXjhke+hajkxBVkX b4WUnuRgy1Eq6otl/PXDrj7uD8F45KZnX5Ko/Z4QNxpU5eCkYTwC5Ar4bR7LUx+/ePHlh732sDF1 YjoepYISrEYAGC1LPKnD2nHCv2f89PU+3z4pIdg6RpOo0wfee++cK70ogs5CVy6990kn1F51moF4 X94tcIw+Oy4ejvmwHDzCYNATJCCUUJCe6+v1jmsaMdo9YnIhE13x1Webfv6gdWzPQZZkd9wKkrMh MpgwE6MlZIyoNVojX+13YmNdk2P8RKLUUy5jwlUnJQNIZ0z62LUk/ynb3ukCCLCu5q4zLpyzdOlN zz3GwlEgKwXCRHTgoc6oIowPI6wQVldr61ddROxL/E4RTQBDiKJh+FlqpQoG7/xX3//yr9ftsNYG zklTW958y1Pwjt97z3iNM17nqt1945opI/GwEPjudHoLrd3fHXVhaPbiXGcwNMxvXWvEgU/fC1ZE WiCwCYeRk1b/p+su6YXPasF5AJJMqYpjMRxTRy5KzJwNb4eAYc9c+tIR5+73yL9tO69bPBMl6T6O mqRVom81wIWK5VweWXLyXz/88F1QcEdNmBBPJfe/+Tpjl00Uxq/VIGeilKEm2fpG/LeF1pHDQK+Z vvOO+x184GkX/b0CT7y06rVSq3EKi0taFaDQRXwqREHFUu3/z1I4oFlTCU3wJDLjS22Vvy9/gM4r 4RNd/VNfVGnEYplE+yB9Jp3afMcdwt4xhs+X9zp2TsVqx402WpLkpmFrSDtF/USAUMe2FGaJXCMY UQ9Sj59dYbAxy4pIJxxdMQfooCtaZztSc977ZO3tV+Ar8owbsfn+exuTJxjrjMVXmevowhZsq2+y OeuMbiM+Z0WqNuD++Hrf0pz7Pze9dd99ze+9G7EVaiaP2/7CPxpSMMxhpMGYyGcWLqJInTF8OPEK 44aPAuCVrAEYU5J4cll7wA9fK7AaqdOB7C6dSDQ1yjvPKDiUaBu6LBtJ8slgFE5TxBUujuWy85a9 fuO/1w+MbBzW1JYOrzt5U8ozShx5j2NDV3IqkVovPJ4oi1NtGxoItMg0GA9xL6I1WQq+XNYXI/Ok YI2ngWY2VmXEoN7RUXDWW8JRHDXb7LPfuFNPT/3808c33vDByWc77ba6hpr6qZNHn3SiEXN/decD HqurobFpVTravNX6he9nW9YdV7vhmu0bZRyNw7zpwuZ/3CsRJr2FzuYcw2rzzlQw2eXJePNWNx8G lkcy4zFPZW2/LE37FYr/ohbSHrCBWHFOGo1ZcqcotukgNBixiWGb3cxOcWEixQXahQWscgVKjnHY Qmof4+qzphJ+G4kC5KE4idRq6fSnqAXrMjpWJdyOdpHusloJJAdHxGP3dmdD0VQcGb1OIueavQJ5 Z3TEjY5oLhUybIEUALkFqyNndZIjFjV+c4S7RnqMn1ep8Eds9B5jZSq2shPU3K0v+kt+eOOP99z+ /huv1sz7ZVG4beLG6255+IH+DdcFp59hgasT1SUj8BxkDDcqTY50MxgdA3rzDwvmu2b/Ah60f8Iw y8IY+ayGNW3UEkWXi2fjBY+g9Vowp6Yj4mCcHcq1dLunrDH7i2+9P/wwbcz4Oe0rfFcf0ZlNeBy0 nbFm8w0OfyQTH+b127oEUMGHqCLHjfBH2a4k1joR5/hoybEyReBZ8MuxZjU9Yd2SEC9yjnZLSs1S bC4Faz5ZE6gtkDoHd6WzjYGGeFvXMttix7xFHd1d+1z0Z2P3nT1GupHIc6KL5rcbDUTGZQsdcRLr Nrz4nGx3Iu/xghNrrXEASmKEIiDYZN0u4vb100sYwvrp9B8JwIyzdnSZt/LyHZxv3IDnCECOkjbo TEigUN6oqY01e9++8J/gpbS50rsdsv+kww4wPJZcuJuNhLwysqjwctRiTWu3xbOFnXbba/ypZ4S+ /vzF665rfeHNVXc91B4Jb7XV1v5jjzImNBHaoCJuRQ+1D69Hw0pkE+3OfK7eA2lIryq5B3TnJdOm p0YKOK7lglvXmxZ17X9Fdl0NjbtcOq/eezTYRHrVoiULZ8/b+5jDC5S7FdeTylVAyABPD54DLiM3 KgApCrL583HFOULPEzOnh1qWFdKvLxJznrKxx7hI4sgZH/+0/LOvf1vVjtfN+el3Decc1TV+pLXZ 47c5Jm+/tRHKtb32YUtLl7+2ruvbbyd+NbfhhgssG21gvP7pbx9/lKnxty5baP3k+4YzDvJutH4k lgA2vm7MiITfR8rGpEmT6tdf852bb//3bbe9uWyupHvp45sqIcrc6AoJeobKe1n+T/FUKGxCXVNC bpNSNUoL0O6Rr5e9Nf34PZ++y9huLWMFhuOosebwLPt/2QZevoeVtje9pcNDFboA5mOtajlwOEPr 9tSbB5+w/p7Tx5x+UOHN91/4xw0ty1c11tbhRt/t2KOHXXW+8cvC9Ec/fPf1F4HG2tY5s7zRzJYn nkqx1B/uuGPbSy+0nLWPRJKgHTL8bJJQbkl1Ry3D6RXBM1kwGhvQcQqJWM5JeXCqyzukBh9uO+oc EK0BGFh3bsUWp/mP2r726pO/ffyxy84975UFC0EeJ+XPcHmI4pFANZW8AV+Iyt1TKBZ+UN7F3qOZ 5HNJYRcSNtCLgD0M+XCf1gfu3vuIgNNx9EuPCmHxCRV9k/QZWzMLNm9DQyVw3u/JPfjOR9fesstT dxlYopFgoGipJyuNWwJ937n0uvYVq46+9xYjXuh+73PSWknJSf40u+PL7za773qjtsl47u3ffv0x 7rWRjNrQXLPW/ru6pk5Wa57EKEqlFxV+Mc6JuxULBb5Btk88vWIEl75pW5ScHaS4hAR64/emGxLy lJZUaZQ4VgGnJVxb3Ey4zv1vP/v3M48qLA4aFB0X8D6+xjGb7uquq2mwF6zXn3NBdzz+j/vuJiRZ 55YQtV9MwFGJFhBBKiWpU7Im6QC0lQrKTCmuuRRaBqoDUROEj6PiLn/vi8WX3rztA7cZ64wR3VY0 NzYoyqGDXFWw+EhEAA0ylCPt0xMw3D7pvFCAMaIusBskCz4XlCjVAKp8ulJOtaTTR/yKsp8EGol4 V9k9sjWT2QtvL+9e/OGM9nlLfVl7+POvQ5HObS78I5moroaakdtuaAzHsdyzLud3LjrqoubNpvlu Ps94c96yd97qisesJD62rMyGujf862Ud3RFSTZ1kSzjB/kmO8zjsW65Lt0/Yb7/9jzrswD/9WaD+ +i1JyccmoEhVEajQuCVqY3WwLnRHSxr37yK4eZ7d1rFs1awfftjz0IMqBW04GQoGa8f19QUNtDMw bZT+pP63mW0jt2y5zeuXOBMWPhdr4/1Z3zz40ORXfsxHYqHR9XOmb7TXHVfB929seWjayO/5S3eK +LnLTnKfdYBreCNqtaw0uxH7etY35/1j069XwvHfjnWvmty077vLyA1etPHYUZedMnz6Ti/++Zq7 Hrj3nbYlFb3Cc0vKkZmUVn1uwvfbpwWlMkvqyltz3zjgxB1/fdo7STxLmbmLbZPHmfF56iNR9bK2 K8Mv73v8xhtvP/b+8+IPvfr13U9sevIxKOBWLBITRth2niaWJZaZ2lOi1z458/Hn8TG2hjvd44bv eOn53sO2GXQ6flwp0eVN1evqrhp9WO3xO3uvOf3bJx+/+ORT3+rqQoIM1iyxTISiViUsB+pw66p6 L5EG7qd3OyrTHTxm5htaGvW2rM9wpGfMbrE0+IzhNZl3Znx48l93f+tBY0rRVVvRje8uv33xjB8O eut+OOfldXa3gaBPqKjXNXHihM0fu9pCsh/hEOQKSXCLYbSlDDYnxFbVC9iA1owxoY+ff7AfhUmk qK2hMEvphs6Ln/j2xn/uXvil8ifEFGH7qvVdf/JZS1e13PH684O1CTgfnmc4tmpPoWB3W1vj8OZy EJIFL3/Qeso1W797nzGtj+OawHyScmy11cfFEmB1Nzb2+hgH6wkqkZYDpcPW4H0uGL+2GeMajIDD uOLZj+540OF1BYGg6eo47sW7jL03M779ben9L0UAsojHun+eP3brDde57zIjljF8RYke+dM9jz7+ 6EhfvT3hQdFnkabSsRXtK7fecZupT1yDjnLptC22OGS/A2+4erA+cJ6G6SqWIacHDg1mVnFFs6ud OVl1Ooe+AS4GzEGKPfa/mNYx1aW23m1MlkKXh/h9BuipWmSL3cwwtp4y9dJTala+XJ/4YOJZx2z6 0i+JT37MvTzDCMY22noHd/4D/5JXas862IWGyOUSqc3lW3/NHZ+42bn4aU/nW9t8+OghV/3VE3vX NuvRCbPamznn8hyvz0PSXb+Lrpo8B+kKHRUNzPzTTS9uf+z7ax30GdkxbgnCExGDwapW8G/NTIeu 4FH9ThLo6gJzv/l8xqR93rvkWvxO3n029x67i/vEPURqc2Gi6PFh+4/ZZ8d/X7XNF08d9MMbe754 t2evzYdqv7GGYJfqHUDjFBRvZe3hpFKtojRKmRnCoqF5JEtFuj6+pokY8Bc22OPTtQ+YvcaRv6x5 xC+Tjvhx8hHfTz7827UOn7n2EXNOvMK4503jiwXtn83MEd6TGTQfqnZFbMQK5aAm/nNZ9y677Xfo p08d8dFTW/z3Gkudknpekhh7ahJYCJk0lYAjsh78VnOXg4x/lbVbujzD+MRtvDMn98H3qQ++T374 feTj71e9PyP+01IjKRQgpa8sWG2Ax0hYrDnYI3RfKYlbEUxnQfsnk67SYZir8ZGTamZYZBWaXN3I AV0ix0SzlsIIXF1qvZyy147fv7jNhw/t89Rt49Zbu03VOE61d39x9+P5n5cIesnU8cO32lDu7JHa vA1cetKZ37194NsP7ffhfw/86JFd37xnn/ceOvSv54LzI4cep3W5M9PuGmridJmeiq6Kw8JkFtkg g/ydQKZIXVm8cCHJLqOGNZNhSvx/AsMu2ACCEoRlDZeBHMEE4B3zJ/AvxMAru7Y2j3DcwNspGC8g z/RsViVcdG1L0pfYlXP5WDwWBEAHaUDOS0oyYsSlackCi4MUyridLc+9v2jZqvY3v1z5yZcd6diE w6cHmputbmu0xrLKCpZ3yitY7lmMdyzBRK2HAllxe87p8kq+PtHH8zpf/fSd9XbdxWJ3r1z42+c/ fnvkySdxgGVc+fauOM4MIGbSColIoJAkQ6eIKaX+owdVugS8Ji2AN3L2Z3mRbreqw501mnz1kyet NWzi+PWm7+YePRpsijzgNOkEqfQC695z6UeUt89mriFyNOl0+Gbv/alcMpONGtlEPuVIYAy1DHd5 GgKB8ZttNHKtNdY5aE8HMZcUeCTtBawr6BYEGDNZIAkIsC+npTCsJu+zYhfMNXjiziwR0xgc7KSW EOIWkqSDFmsklBPQJWChyVgA/VHST8iXIYdQ8PoLEehTyLs6MxGgr61Zx7yuzgde9G22jnOLqW2/ zf7m8y+P+MNxVjllhwH0wdPIzfCBKiRgAX0YzxgTLUBIxPopcV8+unyKXqRiNmC+Mq4YQdyUuojF ZswMtbTuffgRoyeu1zxiYtOak4etObl50uTmNSaNnDhpRGNTvLN7zkdftLz+0eLFc2wjGiZturFR W2tQ5VmsPNIBno4T2xa2Gl/81jbju1GLYtbPf42sWF672UZughfj4YIfD6dkMIG9pTKVOKrnutIh AJIIqo9JrDV5XNS/EJs/8EYwBARhXTBNUhASjJVC1oedI0WSCwaEnKSowvDC3FIfhF/ZYjlLmAjg FPBMCVWywgmLYl7HmDtr9tI585LPfNL5zMctL3684uWPF7/2cduMH2e+/8GkyWtRV2zup58lLPnt d9kV+oPsJojHmC5YU0AgCkiW8CumD1WxQi5tnJXFVGIzgKvCMTJQgGESDCX8B5mclew21i5o823d 4S++HTV1cwNgFtLcnIQCRDokE0ks45ZY1o4ai91SwsazcUs2ZgV0Chi4rA1cOTgnkY9EgkLnnpnV ppL+y0RPt2Z4wYtSVxqsOvJMpJZFsQgERMMdQuYFIOJ8K55BL26hOIuI0PWvP/vE1h6xfTo7+vEP WMs2u+POsUftueaOm3nGj84XkE558TwTxscxCEh5nAJeJ3VfFUQBm5OxatWyX377ddIe2wLP//AH r6yx1bRNN90ymeizBnX3ULe5GBTKGeyqO8/QSD7nQzpV9eDYX+KvNsiUif1t0FvY8n768Sey5ffZ Zx8iLXQlEg24Am/yX3U0Lh5ilYGN82sxeqTc4kan9fZVck1oy1fpwfr0AdMFo2GpAusiYl8UVfGA a1c+bePRmt8hIGQAyTMZy4PG2uONSY3YBmOOAvyNrT2AA1+5qCXJW8Xd59F6c4Ugp7mm5iSLd7OD t3/4JstBW3x4091X3fnvD2f9LAVkrNZoV7e3eZh2OUr1hoEs8uUKIx3GpsE0477QBnE5HnC8xWSH oZD3vMFoDN4ZvQdvvqPdzR5DZXSNoK+GX2E01x5t7c7VjtBeQ7A4AAR1i3IV1IEn7A18eCNELign ekJuqM/rIsTC4vHI8siT1eFETKqq4AqfKpfvzCRq8CoLnJD4giSCGNR/KXQiyiVkC7kFJwlTdyiX Aj+F4oYym/RVecCwv0otcnw8VIvwYDm2ubpSrRsd7zxq+/prz5rx1GPnHXP8Z8GgzcfOEQfVTLZi mQYxiWKYZWfnVKtPM3pQJZusUEN6SP6mWmzYT1e1+zMEWzTPPOicGqt9rf/eoAA0eoIPSkxD+tv8 RR3BrgL1L8gpBRlr8iQxLtOC084wxZupsEFxGGeuembpp5+kO0KAnHRbMxufeZL9qO2BK8x7iVLM kqMCrcR2rXrWGu0CU99HKIUu0wEMoQpqkZcCDiNLS1fSATMPlKvR3joF5qRwzSSDQ8x8JRxdB85m ONFKFkTGBrIMAUNsZeIOcUjU/Mp2I6jKMIiDSMW6zPztmbtu3+PKP9cevs2N+x8b9tiufOQ+MZFL 5RyscDbZ9oo4vcBcSpofORlaGSz3HAid+EgVv+bn7GRACLjcHqBRII0+0yx5/8s55165x23XGsR6 WjMZjz3lpNQGSdAZd87m42EaHkvKa0ttBJhO8n6IKqPUvBokCawAKpY78cpnVkSCupB0CEQAkTCq lHfSqThE12WXvBgV1kV6XTgYwlPoUyc/4EIl12JlaMHNDy77/Dtnd6K5pgn8qZH/vNjYdmSeDZTC F1IfQ4BZsJRKv9RLfCd0WuKxpEbIygee//LJZ/Z77R5nMnn0/nvvf9qxh59xAdtHyTmpnVs6QEDL a0wlUFszLV9h7qOHps8NvXL197Zxc6758ecfFy1cfPhhh1VI93gYoE4LwMFVNwaGiuG4qalvsOcg P0t0Ry1Om5ukwWpXpjNms2SsDXXVbjTwaneFQyPqG1KgvPr39j91lXH49s9c9s9bnnrwi/nzK37O pmrODCdpmQyt/3lq4P60dhnNDaV4myH6jB2Q5WbGamkQiIqWMbIy26V/4yg6LbHwuPrqhkh+29XR 7a/xc6gdmrBsBu1rHOk6bqfaq07/9Y2XLz7+lJdXrBjiIAw8Dou26kmZ00t01aqAq8Fo9Hw2/Ywm q2udF28ZrCfMq5VsWPD2ql4kamM23WK0KMVcBJUObrnqiHf5KFNM5Em1C820KxkfqYLZq17hVSFv PTjbVQibe3/utfsedOGHb3i2HP/wsefN6Wz5x+tPDZYwEAacIJur4ZxR7ULst61saR4zqtxg99Nz b/z2jzsOePZO6+Tx5Q10xsNOwx7om6M34BOQs2TPDydSq9qFRkIqicnFFezs8gIiV2EzVJuQPIdg WTRIl1AFdFukKkCC1Z5vtP/53nlvf7XNd/8l+uvSDTZf86A9Tr75hsF+JfHQqPt9KVARQl31iaUb fm8bNycX8vLdfh+bKgpfksqQsD2vvOH1+n1en+yQouLlQJcg95w3uiRl6RIiW6m+XUyj0Ee5AS++ 4FDmYSHaPGyX6IIcl6lwSBo6QA6SvcIxEXQIgAg4iBayQXuiu8YGHpJ0iFnk+MlxVU6iUiRRylly yuewKiGrFG4mjNmwz+tYPmmYOLAjmUBzY7I3AkZMPphz6C1dLWnW5cac/j1Xkaf4ApWpB485iOH0 moBjgreQp/lcNJ8koz9KIjeHdyAgwEwoG3nJTKTf8I2eZpQX7RIpf6LUqIyDKwLAdS5EIi6Qrvlk 1J7hpG9kosl0EBgF8uA5LYoGJpqgVGAUe4SK4AXOcZjNR8BJkYx0jxeGDEWoNIUlNfin+sPSwhRL vJV8TkFDRUleYD8naEti3AibyFmWdwQjYS9dlWB2a4RMYnJhpMgvCjxUx9KUFWuJcIjg2pZLbTnL l3ECkCPMIa5eqllychLfA8oyafP1tR3xkNGRMGLgeMAe/GWWGQX6OUQGPpb3BNFlMHqI3SMazMVD 6UQEo12REXVtTbrhyRfWq02mYzFARYhMpDJmKAhsuoQzYjfKcb+8OKEXsukml9cjxmWBFJLSiOT+ cp/wU8/ThV9UNIQVB15AIFN0XUf1B5sh+fIU4eRX8kN9JCXILVCLHV3YmBIw0Xg+SYkjKolIQyrO UTF51rA2+pKNnjwptXmC8dwC7CBgI4BrCKZ2ceNRnlr+wCwwYSmCrcRLmtEEBUGMHJICgErf0Ngg IB6QDkMH1pJ4joKW8UYPJWkIIzGilAwltEf6U+dFaIsHSFA9sNKoNSXdUy/eC7ZKXl6sgsae1c39 xaf28LmqNyl2P2YcdQRcDa29li5WnQSW0EnmVF5ZweTJF8DdRPdmMsJ5YB9S0RjGJtZTQoAqOVQR uiNSW6gguIw90F0MV7BGcnkq54FkFC7kl7MAIQPcDvuOaGgB5QqcGVDWR9XlasQbVr4My0/AHPs5 IFZIKh0BXFqq5gV36c7fycYNanlrWxt9HdY8DPqI3S5IhYME7lwM3HHghKTOKShaiHUxfoms6aUE lsBMOEphUrHbxjgqA95P7L8g6qhyjeriTfE9aOjBSKKtE0ui8L28pACu1B3GZs3sZnKJDPhSqagl E8lkWrIRckyAkwdJyh6J28JxmJuYXVk30rj8n+JDkviRk0MilUosS6JPPnjnxocfbGtoXLlw3oyf fzj46MOCkZDdakmEw6AkxTggpaiEF0uQKiDmboz2IO3LX5Cn4Da1LKXzTF4YW0k0Cjw70dWcyXh8 MBPzsvxiSZC8uyPdKb8rmAd9nhjHFIglObc9RRVHsd9LlVcMlDxFWsb0qLwGuhYasUzKICnrXd/M S0RbNEUcbLiQCUKBXAIcyjDqViJq8zipDCD1DoMgYYs+ifghEyFM2ISg7QPhn8yx4bGCsORmAcjP A2aErZZFlcK8Ap0L1BHIRBlPMhWlD5lUOJWgQh+zIH4LVcUV6RszkG1ZX2c65CYzoDMQ92Y/+CHT 7PduMuW3H7/9/rsfjzjqSFIUIt2dOG1lTDJ1an7zuVg4wmLRls14MkFHpcCrfK9GxxKNZ7szgFFh a6Y8QBwEWNBU2l54q6FpeMO0KUakS8KWE0BQCSAUINSIbHipKxqOJWJugOC7WiVIC0xWO7xApKAq iKy2PpiWHOX5rYu7GK7VkmYPkpq9UjpWWJrOIBlkZhWlUQlyufZVrYloHBuAAupKA3pFXUSAn7KY u5OkA9AA8IUJkg27osFwOOR1OLXoVOSi3AIlKYRteIklOpVNUAwgDKpSktB7iXgT4HuSSQqRfKoz E21Nh5l48oaSiagrkkjMX9I9e4EfgEOX/91nnqhdY+w622wBpikcKHxniN2PR1BTRDKsZA0iodk6 ZLwwkhScEIeTdiBR+CCGhULiL+R2rAoxEHKlhgbSvCuWbO+e9eLrG220sZxcBbsDNwt3J3PwdSQV pIqEUEvqCchejIIiq0mmDc6R9IdCPhzsFruwMqHHKTkikhhm6Xk6AJqsKYgG98HwaSl3QCdxA0Ac cQZI/WURAALqJERBulCKxYizHOAlawaEALvDE7dmohSEwDBF8KPVWJboasnH2tIxovw6lrd1dXdK 5GfewrMoyCnlMEidwkieTUfYKLNZH+FCrdHg4qUrFs2dsvkmEUfqhkdu3/uYQ8dNWCPKkHsWuPjq qHseT1ATkYMvLjcKn0j5DplZWbQdHR1IJCkzK8VIV+MSS+fqFlJYjeb73crzwIBtbWvda8+9Kr5E lWG/I2FLx2mpUFFlDlUm5p6rCHqEJ5M0BLlNYuV6bEr6Nh3lVYyTJVMhKaUetIlZfa3bVPdKapmE 86pDLrOCQUs3qy/RW0rNq6eIcc1m00VBSLeJL2qdufae2z/zH+OA7Z698to7nnj4o7lzWA+YR7OJ NBC8NBJNJSkYrBMXtZ222EMJ01C9UB2GMiKyOaMR2158ujjEtFlZG9iUhVT9X2CXYmKILAtGFktf z9i1XZ7wNn5KfgEiiHGpKuZltNLZ2EVDqlj/6QCM5vMIPAuaMYDEmgK6f4qomrToQWi+WU8PjG3J yFicC3VfqVAT5EKL0QH5Pc8XpH9dooty7jkigBl/MDNn1L7jzznIc/3pPz/93KmnnvnJyiUObFzI FmWQ1YZLpfEXSEehWTKTSlgNxdHpHkqJDMkoEaKjgyJknDmPu3bJTmc5uqKjfnhYFPmy2AllEpaA eWjFcIFOFtw7lf2qGVHXlyrnL/4VSyV8PaF4ogAKNYuFMdT9ejKEDtFEQqIfdDljKfWtWtWMLQ6L nlB9VSGDskEBt5culcilZ1avCDUVCgZJADGTIAljR9WTpIgjjCL0Eb9IAYYme8cyY/kzOx+0MpB7 rPW7yWMmTNhum788eD/ldHVKbWl16e7gyaBlisHr3vfMvl6KejiKF+VR+Uw84nCTjybl3eSvzd75 xiezzrp6u+fvMjaeqFT+LBlJQlqOdxT9rZWEGI4eOh26nFvln2pU/Cmtbn1Pbx80gSXmSLoiR3Pk gNMljqueS9NN8wAXXKGDZNgUmSzU86zkferpVo8TTpR/Ktu7pB7ImUo1q+ezVFZFY71hzedEhmYG dFjyX0/Meu6NjZ+72Rgd2GXDtU8+7sQjL75CskpLcdxqavU8Ujuc5QxrFVep0BO1B88zhYRU5sfq hJf83qYSXRMnAuppv4v9E11SOEMVrpY6hcVqhfKm56UmAysKKlKPvFPZFuqlb+t5L3NjYdcX7VM/ jQkstanjcJDCktIoTGe1iF7RB2Nas4hoXrpx1C+1AZCZoE1jjuH+7Yetccdf/375drs/9/xzbpcY MZHa/NVSmwtvNl3VXCIP46CqAdbFf9rbYVnCaoMu8pPqKmmZAkWoUOvIKIEmPF7uBJ4WUD38G2Xj 7W1ZP0JtC3KzFJhW5Yd6RlF8o1yg3AlyPMdnmkKtQRtQK4jISRmppoC6v+jr0ksE7RJneWkOtSNL CKX7o8ZV+jZFITSpAt87pzIK8VuqSEtR2AQgzfDbJtXUu5Vxkx9L6SctlmXc7EIsT8QM/yC3Wn4n yLRqXMXJLTGAlmxaaqtZRzdzkuuB0abGX0uwmoxKE7L4krQW1WEpaqxMTFBbGEOXz5CqFjIiLdz1 ewl0EF2t+E8B5C9i8pfuh6Ty4ikS2MPRRLegZgeal5hBdbfYFSKqNHJ36YnCsaWf8EbNlL5fzqUa E7GH+IqTEdZIFUHxIweH2/KhMJv2uX+97OUPP3r4xecvuewyv9pvGFuv/OqZXwkXUKtAP6J3ZfVO q94r0ZstnDvVrFpIKVL5Qdi90g5Ubz9TpDKGCKnU8gijRBZyiUtYflBaVmVv9JLn+bK6e64+fRBS 9FYaxciuDK59EEhKM6IfUQptVJXDZHMlMV+KqLCyWFDCUQxASKoTxrhE10+Kkq4erdZszzKR2yml QB0McqfBAE0npXwnMftkXfr9qPvCreqhpQWu2+ESDzO5Nj0zq9eU4FiyU66m1C4RR/HJ73Vpa1T/ p0k9CXN5n1KjhnCLXskwVNdVtQpTxxARFObuFMGp8Z25P5OZOHb81EmTN9xg2jFHH9W/KxSlMxlg r4tymJkHOJK6IWq9V78khR5ZZ+Ki0oobzBATlJV+DjSJAz6E7Eit+1e5bFYQ3gvBbm6rqatlGx26 I/CAKcLCLm5nOEpIn9He3oGxfohuSMEec6UJWJqunrNRtYFhhpF0vqq3cYNUxzHHA9wMGpBUbqt2 WUeNRE1O+X2jd9zBuenG9euuPQTfUAinspTEIO1L4BP839cli5ECu5YE7VRc9LMfWs6ADUthKVa3 iYv1QnEfk4F0aNCIDROtsuNgNRwc7K2sCQZLtIzKb7DhG0gqeLLBLhWiMkgHzC3kgcn1xRdfjBs3 rq6ubkCpambAZu7BuPPLL78QxLPlllviMeOASQypiq1WvyY5lvpVqlAFJx04XaLvVOBRsZ40Drk0 iQSiKMiBRDAIPRKypH4uJw6tLqpdnXuUnTch/K0hPfDqAmPZc5tydOC7kXRwPuT4rzUZOcRodR55 o+K6VLNU95Z8YPZTNlVOlH6HJ//m12/868YD/nyxsfPWAiwp0cwpq9ODZRdPXLaWmo2imanwKdHb 9BFP95CzmZRHUum58k/0MgXCwBsxAMjBrEgH/RNoxGg0QLDY20lvCwREC9dnavFFScyrNNRzDuUD 7fdQwyBbgXTjnsdJiWPtQOwZrAxK8CeYAj7iYOcmvqJEUqlGmKRDOspK6CS6o1y8h4yiSApf6oJ8 ckTlCKUVOqmarfDZy58OaHgUvANUlbZstImjQ847N7Hy6Mu7m3NA6f8Ubv1p0dIXP/6IMmP5UDBj KTjcLkBFoA5/JaE5qSuHyOPk6C4l8CT3ukhefErxbMJvrckYXpRAgoVrbL4uS9fJ/6COXeN/TsOP lPLXCbCCIoDYRHNZrBkYS9F5HT34eSW2FJTq0kzJri32X8E2UkFdcmaDGkU+EXoqDaBIatgV46am j1BDmEGVFO2hvDxF2QdVbKxYUvCkFW2A6p7STPVMlhjUobkcB9XTpXs9BkYYIJW11lJb15lvq8nX Z63+DxY9u+/R+739tHutADh2YIN0FzJo7swILgxCZcEt0CckiXcUC5vo+PC5+GAo4Q2KlLYUKVpJ 3AD5FviWVE1UwvMDdY1GZ0jqqKUywe9+mf2nG7e69k8CDgzGOlVGhjniTktDzGqN21rIf/JaR9Bx bbXs2UBKpJM1C5up1a3ZCKQ6OfD0PF38BhnS6+WsIAxPEnlPRKw20/WZKWxf5CWqmDz0aH4CF8kK GGSmeDqx3nJAxeEhgPyiSAkdembKljY8GXfUHeRzV1su/+S7Pzzz4kYf3Z9rXXLcOSfvt8vuR1z4 FxxA+gHFhUCfVGaKPJdChm4XooO6bgIAILUywyIXpPSeqU1FaKKu/yUcELISqMCPEQo6X1PVY7Pr YPhS0wwbRyoOAQHgV6WE1Yq3gAq7atUqSi7ISJSJXds00ErkHFGGlCZTq+7Rf3XLYiZmVsHfcIgZ ro/O1SOwiqJF/ZyQTCkBx81qUZffLx8IXIOsIy5q9Uq1PQ59ZbpkuVYrQa/ySItOl6iprwsvWPHt mrvu+NJ9lr23kl/xVTZjdRDbT3yzVaEkWPCw2F2idMua6KvqlDcupMBXBqd6KKorrNJf3xQzr0QT yxZF7VFfwCeVH3pUuf47rv4E/wwLET1Ibxulq+J+yEBXOdF7wGFQhFEG0N5LVWAo/lO2o2yOWAnV 0Z6Y477tK5e6mlmcb4pLyrVOyYNSfXdSIkasoAV7Z3LJpMNb1ql7N7UkOMyXqam94eEHXcCxqswU NxG4erdWhOE/eVyjnMeLW4PMYNnYJAsqh4VX6gLls/FYocnnsLiC0/+SXtba/PU9UDAnWlVRCxax SYy5zUqtc0SSC9CovueJysMNspuZxpmh4oKrzaw1GgpRo5No4qLdvJys+r2mo1QBlxroVD8tn53K me0J2MlS9UmXN+xLeSSHA1OrpZCkOCV0/2zJewcct9Wd1/r221CM0S6XSD6d6JDJsjqQhT0zKwzM 1FB6UjQYZeHtw6XSxyIsjKQixaPYuCUiEysBarLD3vrKh3NPu3r7V+40Np2sfEpAfDH9hjOat6St yQbCzw33UGceNgY8ynmA1YoLto/VTVY0fKW9AlJPSmK0xUNSomgFKYplQ6wW1GG728Xhc+iZFU1L +UGZL23YKp8rYk9sFJGyAXoG/Rzx6x777ZnXxl58tGXD8YcdOf38U8/a66yLIGmf05X2lLDNkISE XdDrEW+kapbmpThRNi8Ai+ayVUudWW0bNyNBOl9//fWnn376fffdBxEpoUDV4H/+85/ffPNNKagW qb1o0aJrrrmGNw8//PC7776rIyg1JKwO0tREkeBzp1RZFZsZwqKsUK8Ky9HBOaXSqVQ0FTcP6QZI IlWUs7ewr9T0VAVAS/VApbKtUocEcI/f9b1fdhvVmirOa2Nnxxuozsqlqri9z+UecS/RVZ6oTVyc VZv861vroYhkKhNXhNXQLXWBrVL4VfDq6IklTTUWebT8tqzl8kHpDnCYpFH1lAFuVgV65XMZisvp pRytKutaokBF42rIQiIOK+gMepjlr36dEQrgw9Sf84iK+6WOrGpQvVxUdRLbVk9B1YrhCLl6ZhYJ q6qu9nZVxksxYSmkYyM1XE2AAzDYGpdvs+n7/u3Hz298751bX3hWpDaXy+WtrWU7JNsIvAvOx8wV zRMfSJN6WiufDgndAP7JQMC2x1wuThMuglggs1TXFXlXGqDQVI1XCCUf9+GB/kMTNsOiQnSJpnCV mYWxlKm0WKC2kg2E4LoFFgP3ZNlC+tCqcmZlyIKZjM4p5vJ+M0uxZ4ubWsAOr+hBFtD/0OXthGYT FllfB/yAhp8UnqewNaWce2dW6MJGq8vmiibft3Gp6yvFh4GPxS1Kyfa8HURM6Ol1C0oiBYComUke fJ1fbNyE2XF+hlcwCrPWKfctlaP7MGEFj6kyxQ6KyPQu2FJtX8W9ijNpT2ZcAAKTGVVNeeAFK23J 0FQt6WxBuYerzKyMV/kr4X/NV30alxrcGLNwy4gfARkwf+HCfxx7ysHbbUvUCJFyIuJE/pT9SvEn fdD2dDka9pAUSni9Psi5ulK7fC8xYYJUtyPpUTaRyHvuuSeoeICtUMbsnXfe4UP+lpJHmPRwOEz1 90cfffSxxx57/vnn9VlAFNt4nPSZAXQOqR5V1ID6f1v+CSo3mfJD39P7rTp9mrkZqT00cn/vdgf1 lTkepQYv3dDuYFaCSVARC9LLnB2QR8dCYZNGLXGxmWtWyqUPVO94AOoxWabKGKif6tJNVS8ACjuW Jyl5Ze5SseImLuXk7wpKs0RfEYkxxG9ECpijFXMquB/mLso8ap9n1Qv9cjVs3Cat/BZLKBzOhoJV ny4szSoQnHoTF2YrQbbrc6cE6VLup7eMXM+3uOhBAjBxiX5qkrUkdgi93xQXMFmmHC1isCIe2VRX oerY5uEXv/nM/Z99+dgbH6+/14FDjE9U9H5qtSoF2HuQNUGeylvMogNqNXm33XZDEI8cOfKEE054 6aWXDj/88FGjRh1wwAGzZ8/WWHSoA5Q3QyufMmUK1vMDDzzwxhtvxJyNaQXFnDfcrKvCuzhAaCOv MhIq33X5mVeMxGVGA4vNRc2sGGck0WY5quu8tZ6LE3CZmBaxqozWosIUgwL60UZiYONxgG2I1+Qe NkgdqyBWCHrSV+hL+9qIgQqXtyS/X/TWny7d8/QT3TttS2YPJfWwPVIMEUOsMtuLE1NU82LgnZSw G2JudExXuYir2IoJ5u2hjdh3sAOo6ShaiFTUSV9jSKm3siLFvFpGKbHhld/PGVlkse61mgghWqk3 PKvMDCcHrzRB5JyPVU6wRAMPun5E4+c41dfzjEMh5AbNudDQlg01Fexuu+/rlu4/XO07dT/n9C2M RlceNImewfE4AgjKjEdQie0QTCpFMc09fWnL2Y1qBvZoym9xRhPdtjq3O2SLnH1DJpRq/O9FRi35 +URWlPosJ3A1s+qREkY/lCpTrMzNCb1HagxxP11j4hTllatCgCn6bA/yPP10GYjyIJRLeTrTd6Z6 64Lr3paIoJ+BcYxUj1g+48x3+fO1oJ5/sOjV6X/Y7eVH3etK/EPe4cI11Dv2vqSDrzIsTMbDYYUl 2WdBqREAl4trQhATsjbBn0HOGbYUCE4cQYy2T79sv+XJ9a65xNhgpOSFh+KFifVha9bXAY6NrXu0 N++w1JOb02t0q1jgmvV4bnEtVI6dteywgxgOEchKj3Z3BxoagZfV1lRO1hUbZC+teiZrqJmS2Fny ghQZlehAWed4XVw1EDuetYYz4SYS7q0eClk/+PLc9z/a6P7rjQlu0MbDLR2+2lEWB+l+Rb7qU8Fd L81e37j8GzxUMaO7HAVPT2mRIQRE2VerbSrRWh6y+JNPPtl4442RwkhwlGh0mbFjewEwdejIeuut t9NOOyG+NUoUhC0VVZAQdJWbIElQKTB31Evj8pS9+GfxK/0tP5GC2VjBqF4BJA15j5RC7/2J3N/T GkdpydgBvYo3qrJy+Z28x8SRpgpthMg6Sp4nM+AuYognQU9VZe65ufdX4m6Lxnil1V9+CAII5I90 knhI+eeUEY/izZE0TIwnMq6UvpmdhjeZWFyMKn0HWP7PHJkyqmX9AhKL3Irybojk6glmFqusZBnI GPWrgnT0p6e38XQ0zntSEnqJ2e9+AX5SeXHi+dIwPWWNiw7S9wVJBSOJvUTNWons5Y/omVaph913 mhRqkkLjgVDcxtOI9JONhTvJpyWcn6BymuVbKAmelIZkUiMtMgxzOgjb0KtolJzGGOkh1FwHkAnF DEOcPKq1VdrnSWVdUpQXEumZSledKTJAAGYaeKb6TzFjJ01HHB5q6ZGbSkZfGdPKTMnTi6wVqTJT eJaKN+veku/TM7NQRiONST4U+SgS6CwUlmXLw2FvKTZP/POgK46OZcjI1XXNgXjrO7MQVk8cS0H/ JUUHKSsk5ZLcMSNKWi+qD3IfWSlFZhCG4vLluWCN4dEYdIHryZUnCsMMzNU4DyNRGXU8Tv4UORNC W36SlL9qTvtwWi+tIG8sxj+HWIDyFeINLZ4QPakSoYpblbM9YkECfFOyuaLo4KiNxY22duCmYFGR 9dzcKzroVZ8VLXxYminkDHOhUOLEX9334GJOeitmMh9VgpH6jTfegD2Q3VOnTkVxlsgQmw3cgGuv vVZr3IJJ8uOP/PPFF1/ElnLPPfdQD56v0MR/+OEHBP2OO+5Y0bk8OWD0w0y1Y1SUUMJSVx35QXY4 7sSKBNRO1SsmMILWWhPNMp2kSgdciUgoUbNH/ZNXWyiDOchF+q8FGGIzE0PuNVmIZlCbcSut7LRT X9zMhFODGBY0Q1hOP9xJiaZql6QGBaO2xr7Q4YP8KheMW/1uDEHVWjVWevZsOGs/941nVb1TZrY7 bqXKc18P6oA/zAYjSa/F7/Qv2+lM29L2UQueHbR90ODoJy6KqhekCsctddUBpmkpsarTWeO1mQDM QV4UoimLGSZEKwwnZb1UJezbP710wMl7PHmn54BNqw4LPAUUDluNqXGlQp2u2j54Ncteen/h8Zfv 8OUTxrrj+jwrAlCi1agzEWaH/AsmrPUmOoBpsytK4coiXPPQYwsmDLjFBBJyLpYgCcrRVFuVVsF/ PrTi2bfX+/pxwTKreiExULcrliHAD1TgouKDKXtP7zNWW+PmBytWrPjggw8+++yzzTffHIX64IMP FteOy3XQQQeVFGqclpi/sYfwKEJQjjvuOF0sWCvshOv2HyZSEySBqsNXjeRBGzBzJ/egcVek1Qz2 w5AE8ZnqADFJcYq8EHQooQkETg21K5BWW8ySqNbjVI78a32mrn5RR8akjZvcD/KJq7fIORFNJhYy 4xIgHC4q4CWmLpQsdBgzt6ZH11hGjzdzJ/egPvUWGxziNyh90aiOuSbXdGhoclLGwUo10wHmlJvN 3Mk9WZcVUEkzN2PzjCnWMnNxQsTvWvXOgt/f6XHkVXZY1YtDGaAoVW/jBtZ4BJW8r/dCwqIkcqNf AyCb981uG+wREiIsiAvVL9Z1NEvZN1MW+UhWUvmrN4pCjbGo6l6oGuqyWVZYsp03P9p525PBWx83 ZrcP0b6sbqCP+14cbbD6rq7ULm9jNTRuZLfGi9FoL4gPXWdII0GXGpUoSIcDo7a4dImjVOCiaOXz 589HQ99qq63Aq+NXxervyu3JdOvIvFIjPELXKNK5ORKsoyr9KLOphCWVxz+WCzJphFciZQUOGhOS xBRK9ViyJgTmpxhiAOwnPnRqJok3G8AK2qWvEhmmDaeSONK7l0oct47bZTggT5LX8clvb176591O O8mx2/aGX6LPCAHMewlo8HFAz2SJlZS6TkTOqXDbypqTFcGbgpQkKfgqPJdHi7O0D6vJ5+ChAlDO eTiX8foD5RqEhrsskU4CEFXsOcq+LkBcGSnV934N1sMxGgRXgRLJZNiMy0kqTfVcNC5FkNXRSpwT RbN478TpmdK3M3KxSJbZuJkZd1oKp8Wpumhk/cmCtStjrAh/8+e/1xn2Rn8dNrDR3mGFO07MD8vZ onYj7Mg1WdpqbO6svR70Oqc9komKr0fINMDTcTDY8o5Oe7Iua/cK7HgMaEDnqnTiwv8QfFV73XHp Ya5woKZYrlNMysySoGsq9KKcy+HC/qMKPhevipnCXiUwsxInz7ikG+VuOtYhrrDSb6GPBEoTiaSi GrQVsZywmqNKFOOHOFrKb6iY2eJM6SKzEm/dR43F7uyOEDpNwWKCrLMNEWshlPnnJtuc/eKzteOa 8+5kss6R8LiACqFjTDGxTOQ6iLtC87zibR3jO/DMil9afBqkJ0gVt1yu1leX7wxR3YQA8vCPs+Zc eO3m11xkbDFeglhy1tAwW8iSHxmxOkLWzmZ71Gs0kf4+yC6mgxekcJpi1/58VRICEBOy4GoGsbmc 7ctnSttmJYSGkArlH3ITypQUGaVrkQOKQA4dxddZNpwHoIA9kWUFi8dTwmHlKp8Iu8UOIESytdtN rXJnzfKXX33m2n/tOGFtezC6+JfZu557tvfCw4MBge3VfMPPxT2jJJVEMarQKtaRXgt8BYCJhKAo UWlmUylfgGTDPP7446shuFfrARU301ccmMuXL0cZ14PRN2gS87dCIdKWcf1X36mZnv1Al8moEEb9 +5btiiBgrSo6W8hZdlaSD7T7UeUxBENByOd1e+RxPZG15baIEhvpigdsPMmFK5dO2m+tF243DtwK /CAal0h7Ef+IKomC5W0sFiFLqLTxlPewvPO8Z1AQhHH1jrcymlgwIsS6nc93t7fXDWsql4blHKYp o9uhWb1EK4hTcT8UYENlSeraaeU0L1G+NFncxs1DQ8WWyIUxTcus8g7o06FOgGHBiP03W3hm6h6j m4c3DG9IzV1unzVvSuhrK8XRwd1HTrgAwZbbwG5WFsECjKuxywdkSIkTt7BBA7eYo+Jitys7vH7k nE2PrbV4Rn5zD65OJG5R0xEW0KxhDSXjaMZ+l7ePW2kgNhMKJOM1vkAv9ERZP8pnlh4SRqUw4XsL W/efLP1rVjXzxRSU31Bxc4ntsT3SZv81D04LHCwlW6VOtDX/4ex7Dz/12Ice8O66Rh4zqwsscqey q6rELAnNUFlaql3s1qKUqESNgS8hlUoXAi83HAkEpCwfRmHB/3ZYlzz7Xtt5N2328m3GhhNE7cCE 67ajtjgwGKbt2WEu1KbePW2gBwiyVSo1VAcUc4rqgMYdjVK+brA1VWJjLSJRN4lo0O7BYsqeGrL8 vFR/FHgVVfxksFJ/UjmeWhaM3+X4+Jo7fnv2rROeup3Y9Lf3PWHs3rtP+c95iP3SmVWzgV5KDIo3 rG6BtdFx3Gpt8iytYw1K8IG+WG1TyWq13v9m5hhyay2bvuo9TWKBB7n0V+U3lN4P/cNSexLaLjgf VpI1JDq17NIP1n8hm8BHqBxD+UD3qm/HSk/UfWAIjubaNdz1RhhgVPwz+UJrF6VXCfKVJaHaUDPS +8jSePt3vvy+3vHqPvS8dMadYIk57H5fQAGtDNV4Oa36E7iiM3RAn4301X9Sqk5WxSPKx9i/NYXp UER1UBgkJGlYVhWS6x6827ov/GfDyy9pMvwSCExsMMkgVB5BKxF8CSnJLopmtYvGia2UiVXaTVN9 M39Hjxldq/IJhIIl0Bg5ZilMGIAE5JQlCEJDzFSRPvxEuq9xZCpu7zMvPA4xhIStYOPy31SMpg/T aBbte5XmqD9hhToyNobPKFTOodNJyQt0TiINrXUBu4cYb5WsJ1AEIjGKM6XYSY1pyKu4ZviR8Dk6 pGynxIsrO6+UzmBp+FwS3A1oD5jKxD3LngienqA0APNRpXmlpZq5R/peTB3tpU5/JpRB9TSo8YZE FJQmTeOKwAPqpQen+X/AS8glVThEQU44jFWJUGF0kzFxeMFHRRDR5XvJ07M8dYO6t1ro6U7yXh9Y V1dql8tVE8b1/6PMVj9nt2Erq9gkdcN6MCYfshp3KuY00yxyoRTdNfT9il+kzWw89fm6Nanzb8s2 T2/Z6A+f3/lY/x+uRlfNb7wqjdbMoPQGaZICmr/NNGv+Tt0BM22SJLI0Feoi2gzPxIrF3UZ3j+2v wo5abEyzvomWZVQJsM2JvgqFowPlEJQaURuymTZFWInE6nf11465Ba3KJOay+clajZm15lo6W/Ir VxZen1X4ujP5W6cgHw5yQStzVJXBI4NKB2HdHnkrEsddMvGVjozCV6YISyM0a2Jai4xdbicZ4lcm Gbski8x0IJID5VVMoUaI4lUJVbNq0GvAJVMSegOyjZk+/E6mEjiYlHcK9uy1117aKlLyZzIweq+V vsF6zA1F8I0e+1fFAbzPDzn+UMwiniZ7SnQ1zuKcIZ1YD8W2JVfBcBHDkwJ/laoIBWzcoEyhiqBE cBJTufVSOK3UJk+n/5x5FS5x1kfNyc9/eejsC9bYdSe2nY4VqzrbO8/4zy3GyOYcp08qc7msKYfk RtOU3r0rVm9F5zUEc69ii3ROY8dU1nnB782x50mquboEpcHr0bWD9cVX5dOvRYA2TJf2/HL6VNxP Z7Bp6J2VX2EJYX8tb7Dcxq1b1ooJf3mvVYlyWpUGW5pZ/S0ygyG5kmI5SXgKMUeWgPRAMmuLZ/90 4KFbbrXlgZf9Kfb6V8Gj/zJ61hvGWIfRTrFGb26kbXlAjJANGUuEKYpG3ZQFVBYYvXRL4kY8JWKH tYUdGX/Wio2b+MF0wOKLejuO/gtg2KOe+FsmYItjyC7CVih0X0CjHE6wmzHgkc/GGVykkpp9bb/q 035WqpJxERJHF9gZOCCzzbCIPX5/Mh7n4MUdxeg/5dqhNRrR1hI90SVaaTJqiH1tzuZQX075oWdW 95CWpW5rNuvyukM54hSs3mzWk8nbBW265fpDj91+2Lil3321lmX4sIuPq7nkaLgXw6rA5SnwdDF9 qKh9ukfUHl3S5njtXipfkgQUwYKAy4ACJqgsuUIA5MVIEkRkIxzv+uHXuedevdUdVxvbTpY6BgVr qNEas1qao1Z7xNo9zBZzFprw/g5u44byKr1RDNMla1s5X2kS6XlnvNrBNpjEoP96IBCHREqAiAFA V/HpGDUhmpMZZIAaStrlcsMsCvNHZesrQdTHZsWJ3O7Eziapk5nsG08+9c7Dj990139tDu/zp5+1 4c47Tzr/eFwLRd+JShTXK4UG6QkNVpiCWWVaoA8lxwYaGz/RNm5TetZg1DH/OeyFOIDWpaJ2ut/l R4mhWyupJPrNkNqBNK3vkUOheBp1Go7KclDWLfHJOFwSgp3KOL0+HDtApqgFpGoNCA5kL4uV9kz9 UBrMNdd+veCX7bfZZufL/77LXvvbQ3Fj7CiWETCpckoHdUTBHZSPrtTtis7rNjUpihfGASD9VTa2 y+fz1NTotmQwrHPtHijbVypaLidsuVwrkbfifi1ZVNI1VYhdFXBj/btdOlGWOLtiLsonqHywivIK QksnAOEYoMaClM1IkXRjJRCt1udIxbzOOqlHUwSPpVorILeYMgSsFZ9/CRpUE6380WpyRa6qXH8W JPJdoCdxpXsCAV9dHRikpHFRjNwjBRPdYC35yFghR97h9PJPpxAd8z0bmL40r5bRTVn5eGwB14nb Ycd5gLQr4FKTSipJApzFD18umkomfomBVjWjh5is/ixdcXPFYmG+mDj9V2wyDmeN09VAvjt4eDg2 arxdkfaQNTn2rJMOee7VtaZtMHfujx67W/icwnsxgp6ysvOoZ2CLpWcKD614uh+AcwRhV27X6rZk YPEfIh35l9tBuU4fkQsYSVDLOBSiWwi2kqIH/1HQ90Mfk/ToSougPzX0jGvZql2U5Ve59NC/1Tui SE/RoSj+IVNAn8BPYBPCnkYOEZWAqJuMm0py9noEtx57+QVRRAdUHMtgcx7SxBwZmNLjJKTcCWsp M2n/laVHVEFMPizV8jYvQivu/J00bthr1qxZVAvce++9K3owoHNywPEgKcinH9De0v/+XFeExCSr iQpy4cUrPQ11DhMRrHQVrwIdCLa2nrfWRjfcfXfzkfsbZ94647EXtgh/XNEHtC18TWZOf7Sp3Rdm ZpGsH399rRmUA72rVxS7G/ARAqaYSCCyq3aAZYBmZOZOmkI10JJl6GaRJCdusPH+hx58yBV/Tz3x +tyjL5ya+gkVZbBf4W6CsNWPwPjHurrSdfTAu2yHM3zdiYafHhqszVgwhCTy+Ad3zfX8ktXftWTl 8MkTqtKKG2BXlJWhIxF1OxCWKdD+4aoXrIWkrhqQkJg9d+/1N3r+oScbjplu7P/nn125tZ69odJV 3fMw6uAguPze6hTgQNrV3tE4bFj5FrXw+Xcj59w07a07jA0mlfe/EIpbAP1qqF7MEykMa5kpkcou yJKBsc0sLrgFWlVlQvos1eLTaTNTcO+NN3759Et3fPiGt+B6YueD191hx41uvGiwWRtwdTPdOPyq 83C/Rn9vjZsOwGcwcf/h6YNPVWblhpLBxMzN+vRp5k7AcSoiqwb7ld7DZZlRRd6Zt/qVqPVQFnoA 2aQjJs10wPy4JEsGNCtz9uhSb6v2AfluslSx+cnSwsjcFJD36/arfcvm9QHSN3SEboUBYdDRqb5q iGevx+MYcl8EP8kkAgls3Nxoqlw1zx1QbRyww+Z5gJ9r00rVaaWYWWFkIL++SNJQOkp64hC2WDHZ moNVYR1iMayI+hewG8HvreyUZKKbC6M2TwFtfzBDgdWdgqok1TfIKcfnleOdze73+m1D4rPr3pps 2fxtv5OphFnROgU9U9GS5KkWL73tiPV48EsnyvM9Gpz+2RA3y1cYsFQxHYGdTEnCtxAP+7RYQgjc MzId4ZU/z2+du6ht4dJlS5YBV6LL24GZS7Q8hbzU7b0veisQ4QqaTDYhp7XLIJE1BkpDpNa9gtqt rKOYFD+V1HG1tNjnpRHV1Z6xyn/Z1SsGq89T2gAqUqnfmqQfnHClsFIClMqoBHOXXZo4pUs3wj8F +s7h6E+oivuFV9QBuMQ0gjrdZ+yq5KN6YQvlWC71AqVHgixQMRelxnmjzxAVHZAqsaRVE1JmZCmO kk0nrMEIx3ySv4UNQsG8xV0IRzOZCC5Foz0Ko0gNFWhCeidZ3Ji2nE69yPVBuLx91SeytKSvRBM6 PN5EMibVyohMB5CdNOX+gEdK1giIiMKmIC+ifPGI7azskhtCsYULFy37bdHy3xatWLAk1hUiZjEb jkuR4nBUNose0un3OoS0fIL6zJQqTqhHoa23A86snmBdApU3ogBJmLDGuJGLbtOrrsXLYr8tzc5d kpm3OLp8eUukY0k+1tW+SGY44KJcpTVGJd+UEU7mI0mcQJRgleayUpoV5QNLUZGerBh4rO+KlF6q boBT4PV6+I9Um2Q2E5QeJSTQRh63ESVPkqKmceoBpnKpqJG2AF6WtyepflXJCH34goHzRLQHkcgD re0yvsrArYRY8lezQM+rz89KZFfIUawbqtglBGuBvLxUZvnCJSsWLF61YMnSWfO7l6xkFAIVq7YC qZsl89XL87JcESNJQIkobCzs4XF7gBgodIaNbg4JEb/DxexrxPBy6aT7rI1L5TPLew6j5h3XA0rz 38lUggXpm69ngMd98MEHqehRS4ZMULFJSpg6HOgSnMneXaRYZKBnAye8oOgFKnon8Jz0UXLlRq1O iAsMuP0UZW1BVaTUu9jXYCYscSptgSc63N5n/3nzC088RTY2BsLuROTya/6x0fbbAdiRBraUig1k o9jwnBVlGuY/5QxxCdMmk/76hqVzfv7j4cfceNX1Ew/eb8Gl//notbdOffU5KQHmI8w/bq+rkZKl HCOwpCsPj5bFkkVjEYdeEVlfdZi45lRGnEu421StDOA1LewJ330xY8nihSTFELw1dtyYCWuv1Th8 GJG2XV0dvvphvcBPOs6kDClN7HsKv40dqhjdqKNK1ePEk6byAiCSWCrlv7mfvvtuyYKFUp4tn28a 3rzDLrsIhH8xuUaKMpdbJ4H1wKinnbfwt6DyEhMmraungOCoFGYIzQYDy6pCB728R6ll6JlwFNKk ymALjSVdBdvF0w/bbvsd9r/2b9E7n1lx3q1r//p8odFuCWeNjDPXZOv2Wd1pmz9pSbhtgHQgD11u igBL9J6MRQCc1MxLZDJoGeS/5X2ZgpuS0EQSY9aOuzqPvzy4aJnzvL1n5RMRtskyvhJvGJOiyi7T bCgemTBp4nobTGN/Emhr7KGq2KKCMrJ4CtZHbr/rtddfCwfFXMMm+pc//WnHIw9NLGvxjByR7GiH ScR9KVhJEulIWV2IYwOVl3YE5UIXkysqvto3pbcfBAV7UcBXxOMWZBqp/6lA6ItFU5XTjCQPpiOf w3hPJDfzlYyEa5qbP33tlX9cfiVWfHsu7wKWm8LN9nx3jb3DSL7x+LNNzpGJ069Z7LdNvv1ynIoS 5k37DouUKybtTFhBnJWFbEGqmslT8EPmBO+7t5CC5C0LariK48YojM1XvPR4Nwt2IxLv/HbW/HOu 2vLu64xt1zFiUcNfE3OlYnZLbdxwJazdtdaU0xJA0A9yQVsCNKC2Bwh7ZQHRbsNSbqGCEO2pK6kD 8AUGv1fvV4UUiog+SgjIWpf6wdEkkyLWKlJq0hkOBu1Ll153+ZWzf/7FjQzJFzZYf4Pz//Sn2nUn sn/B28DVSvacMnhrthend87izELXtOF22iy5V597/sW7773jqWc9tsAjex+089HHjTn7kBA4/OL/ El7CycpkKbVN+IptTZSYnnIfxC91dnXifcFH6u4pXjoYZSo+L5lKfifBjf/nu5lfAkG/3Y57VHQF 3zYjAkS5ateZvFA4Vl+rwJqrXdFgBAb149krXdGgQDcCbtc0/O4zz/7l+x//cNllNbnsWSefeO1N N224yy74TyX4tyJFWOp9AFGCQKbegtSuxQWJWn76/oecdvJpW5x+jHHJ/V/d9ciWkU8qetQVCdX5 ayqKGAzYa8q0o5YHyDcru+488dzXXn21ua42QmHzeOjxn74bNm4cD4+0z6kZvq6ZEKsocDwWo6LZ AToQj5+46y6ZaDzassrrdtU21P/7nfdczRL+PMAV6pAiBVL31QJCkw1QZn+fPIjyn3SFOn1uf1Uj DIvw2LW3OPaEE3b78xmpe95cefpfJqa+EZTzQa7OULDOX915IFXM492BpMXZUN+6z8UzP//ik/yK 5TVGguIWPS2jWkkhmEhk2IgRUhA1R/3WvNvn/e8773nHTxzw+f86+6yFv80/5vyLRns9++y663XX XrffCccLoDors79dPpyQzURVqBj6Yu+m9qndX90WTDuhYNTvIzikl0Qz7v/Pn08595YXX0k21bMT oDe6s0Y4lWwY37zmWpM9/obkDpescmVGv/PvwR7AwYbDotdtAirEKGRaWh0jRpSPqPuZ9xaeefMm nz5grDuy/PNUJMGawiNcjQCo74VVifhYE0Z2VkuUTBmcwiagQrIdSaufCjQOI5YQDCwqhq5Yef5x x2+44/Zb77//vC+/evSWW599/137hDEiosHkGDOhalefvOGGH15689oP3rAWPK/seOjITTff7I6L B/tVgkIKeQVWXnalpCRLgnyGgSNeB+/B723jVsmEGqC58qIel0k4bLZXlVJsynAMHrq7L8Z0MhE9 65DpB+2w1a5jGh9/9ulho0dtsfde6+64w5gx4267+ZYjtt/xsM23vPzIoyItLdLFHvN0608/n7rN dsftvNNhO+186K67H7Xf9P222XrXzTf/ZdbsInyS10Ux8wHGpXTbqkygn6ULUJVfZ9538+st8x+a //19Tz9e4ylm9KFFeAlLMmc0lKBGM7SyWVH5999/nxfb2s68+upgd9fXzz6x6sN3Vn35ScfMr8pJ wftHL//7gVtttf3aE3aeOvmMIw9Z9O03QwwwQI2CIayqPb8UDAPQwALC2UgOAWobuj6k4I6aoKuK eNf1VDKx2HqTJ18fXvzo4t+enTf3meJr3ouLFj45e/brq1aBhfbYB++/uHTFRf++BUNMJjUoaMaY kSM6VrVss8fuE7bbrrmh4b777j1g8y2O3H6Hq446JtzW1q9bclI00Vcp9WAe6JwDVQV0dQ3BEhZj gwP223zbbbfaYYetdt9to7132+HA/dbfeFMMfHTAXdeUEzS3QdeOqLAmXTISAVk5R8TRpimDXlbE uThqXUjA1EVkiqk4bgnrlRRKU40mQt0itQ3j/UcePmiDaQdsuNGR++//0+xZa2688dQdth+/0bQl ne2n/uEPB02deshG01584vGKRoNffRL+/uslr7y86qPPV332+bKPPlr+ycdeEC2xbSrwbolgHBLB Sh0OKsku+rwg2JoSZQOO09zoTZFoqJsEkFqhmvS/ib6XFw4fohXxBqiCZ2a6Q8noaDhcficHvw8/ +3zv/aZfcOlfL/3nNQeccKxICqvltAvOm37ssUeff8GOu+7etrJVSuoZxrwXX7njvAseuvyK/15/ w6KWVVtsu+2JF154/PnnHnz4Ycefc87frrziwcce2WT7baSFRIJs5f5dUgFvprrKbwe4T0pRCx9T DmZOyzKwVtQjgGHpqepSjQo6zqvaXSIy2ro7RkwSBdPXUB/Lpk49+/z99t5r3x12+PBjCZXJBLu/ f+rRuy44++bzzvpx7tymhmHX/+f28y+65Ieffw1jNR78sgPPaKKuLlu6nQxJlZNm8blSkjM51PEL c6QpHlDHfwu4LuRPNg9vpASMCmLDHkX+pHpR1UXKCaHFuIcP842QQ4YFs4aU0Rk0wqe7o0vi3mi6 re2OBx448dxzz7z00nU3nPbdzz+RZl5JDKKhsa2buPCd4N0zcaPcQvJHhdhyxrBYAxtdyYed4a6C kobRcBf+16HkhKSum+AWIaKYmip6kDTwKNj7T5xE4rHNmLoommkK50ssOOguJnbE7hUtn335xUP/ uuuWc//01DNPY8M84ewzjz/vj9f8975NNt+MTk2cPPmu++7d+5CDTjz1NF9NzYqVSmkrux7/74Pb brHVQQcfuNdOO+6588577bXngQcdePGf/wQPSDYToZXdQU9t/RDjkwSkfnJAQh/NrM0hFpcpkpbd pDNlsMrpXF72E+Jd5HTWc+lEEnYU7XVUIFPWYOsKqhYge2Irf/MFamSnsdcJvgubJ3tPKpXpBHVF KmnKXg7si4ajKdkigTJWIhseTHV2SxFI4HIkbUCeKjeXDNwKeiLZ1U3wbw1H1472V55//t133+rq 6PD7fICxH3zkMY3rry+hpjbH4h+/aapr2Oagg41gyBg58onLrkhEEvlVwVXzFv33oYe+/vabrTff qjsc2mnXXc+88GKjrtZIxCkj4GhopISc0dJlOH3GiuiKSU2/bjl+xx9WSolrrLZ+b8GeixFpYljj 0ZhGP+ktiqqSUHSJbj1xLAJd/JQDu9iC1UgRJm4+x/7rD0RCXWtPmnz1EUeGgh0EF++25+7Tz7kA W3wP40oWCVSDaGJblu1CWCUv1sgCHB6LkgbRa+PmcUmQkUHzQM018pQotNfV5ew2zDVGqGXDzTZ8 /N13KBIFzPGfL7541syZ8WULv3zt9SuuuGKttdaqr61N541td9p5qz32Ziquve7G6665pnDNtVh6 tttm+zNOP93dPELqyVIPGO9NOBzs6mpdtapp5BgcxXX1DS5i3fASuwpx8ofyQio7XJMVXJFYJtHW 1oJrK7RsUbY+YLw9yxg7nN4Z6Whq3UDYaWsK2yxJS8cwmyWF8bYQYUtWvCEwAFJ4XjEfpLMYUYtl eCxvw0vsyVnctnxHpy3uD3Z2JqxGYF6HQaaFT2y4xZ9AtkAN6VWYn+OhLt/IUf7O9nAyZW1ZQRWu TCKFaCd1C0iljNhTLUwHgBrgDRnLl2MfnrLDDlPYsxvqm5oaFi5a6OloJzvgjdtuffO9D0jpagmF p2ww7aSzzh49aVIKiDS7A2+gZGYIuqQB9AoLCV8r/m1C6FfOn4/ulgs4LYmkv7bG21AHolshGUe1 lhK7qsuGFUefw5JNk0tG1cJU66p7brhh8axfYt1dwwJ+T40nHwmuimfzbnsglq9L2Qp1vlXhjlHu MUZHxukmfNDiWBESS6sbG3ja0hBIE0GvtEVl9MfXh3yPFGmJSlss7FksFmzJJoGJV74M3ET2QkeH BXM9khZvp79umMU9s5B4b98T5qZCuRF1ax+81x6nnADMF8Xr8hmKmiZIX3FL3jn1NyjvpypACvZ3 Gs0JbySmg6yHTwEOIm+WOhvQRIVGq7XDCymJ70RbscVNhT4BBdS0c67E0eIl3L/HdcMQiPSQQqXJ 1BWXXLL2xEmBel/aYTn29FP3PfVUI9SdiMU9tXWZFcvqfO4tjj5iC5pIx+cuXNDd2Z6dP2v2T7+8 /MpLlGBEcNG3Pfbe61/33BNv6wYBnagAqZ5HAe604V0VNYLdOAkE+yaYidhwXyo27PG4KJZUl9WS AO2j5ImRmpMSqouQrBrTOZh8rm5ZLv8lj1m4cCE+xvXXX/+5557jDdGIYLdSE0fLbkQ2SFKrVq5s HNbcHQwD2b3FZpuiO3r8tQRkcLjwjZpUSMXSK5a/9cHrTtY31Wy8rjU33sjX0IzEUlJO4UEVZXLP w3FE4OPi00SKsuHiWhHxVJTrmjolQY989zU3gcwGmidUnPn5Z8sWLj7skIPmzJ93xeVX+jBkgxSP D8drnzBNdt04tl2P6GVrTJkaeeSp/TbZvHHU8JiRO+uscw++6HywZ/AvCOCZyEUfxf4MnMickhr4 ic1ocNWlCnVzVxpTRxlINVBM6Zi1ALR1Op4goUXvXj2CRfGZrlxcUn7oLuKMKQQASI2akrWYROBa e00tW/qIddc64OADXflcJhJZuGDhzI8+m/6nv0m56KLBhM2sKIfU6utJM3IaAjZPnS28vn0VLcAj pNS07HYFkDqS7R21DXUhUsNrRxjuuH/YyHRnt3d83fiJkx557NEPP/2cUbl9gatu/c/ojTcTeBYQ Ne1eDFxnn3U26mvrqpZfZ8369YdvLU0NRmON1eAlV/eSxZee+8e2FasQf7jdTjvxpAPPO9c+rIF1 7MGyh+NU1DalvpEJ4rAMHzXc8Dt848eQzmdMGWk01IiiZvVjGQqw4CVK0CJv3J5cgVK57MuKAeQ/ vXoi/ileVp9AfgIKZORjVnrlcuKj8vvrjUlNxKeAE6e8jcqJLamArDyS3hJgkBhOb9yF/LAZdQ2G r9bBnEsZJrnkOKB22kljJ8z95VdjzBgb5EW0UV84l0+kknN+m/feB+/7bM4nX3iBIPRdd98tkkh7 Ghr9jXU2LP0o42QSZaVuMtOh0LXQ7ovHKJp9/E8PfPrF58FgKyJ+l113+fNNNwYaGyySK1IQ3LIi u6C3MGCXhX3L5yda4odvvxvVUL/ltA0pi7zXvvtb6xuG2UXKu302qJdPJUY0j8Z+YTQ5LDWeeHtH vt7LJiqAxKrKKtZ+7YCTTR+ys5eTQaPli3bHlmjLXRiUgYoSxQNk24gRqIXEMke1WdJwYtYciMcT 151aU+t54v2XrUsW7lEXcAFdT1gBdWpgaJEPTCJ7T/6XD9+nYi1CPOD1jRgzZtIWW0KXbDKBj5bD jpZ96um9i5oeFnuGvGP15dJWlwdfqkJyKooLzef61MOvOcejOIxorP/nnf8eM229aFeHR9xXVqO+ yVNv5KIRx8hRPIAM6ry4JePBWOy1N974fMY31OJgjEcfdRQqVHPz8Fqi++savcNH9xydIILVWLwy 76UMZc7ndLnx93odLPliDfuSOFLrkfJ1/EUZ6jWYMAQVTFRRHGowGT3g56shuAlQR7u55ZZbPv/8 82+//fbOO+/caKONpk2bhsgunQUQSSQd7D99+t333f+fO+7edKMNdttlZ0JmHD5/fX39L/Pm42lz 22x33nX3K0++OLx5RCgSDkUjdzz2WMP4sdq3M9hpTX+eWbrCsdakqic68cZHwvHu7mxtbbSza+rU 9Y/6y9/Lx1+ehkC2IzGCEGKLXXe+59mnw91BSk2zsTY1NiKmLX5fiUao6RaJFrBpACN9+aOZsWHU J5XYZxSHwL+SybDd70clrDofJGbjNJX6tv0vxErziD9cf73+5vYTTrKAuYE2j8e/yKI9/+n/W+pI I8j6xZhXnOftLjehkJxf5HIJczqbh7PY/nDWWfv/4VgFROfksDJq0mS5AfS4LipU4Igzjrr0Mv3M tx6476arropl0rauzg8ef+LDTz6ub2iYP2eePZs996ILJ42feN3f/rZw7hwrwOuRsN3lQM3yKGuD vgoE8KSToWg3762JaCjSlR9TVyr2puCmZNXyUrNmxYlGULYUeu938ZEQUX0D3dPhEBXPRVgwHStW yuc2ZXHqYSAmWrdB7gVYkrwh4V2iv1hnGmwdVDl1e4nl5s+da6GeBhcyTl9Wo3HkyKkbTrvtztuH ef0Uhjnr1JO2P/lU+SoUUcmExadQO7a8y8u+mnHH7bc3Bxra21oXzfttr912O+CEIz587fWHH7h/ VWurp14O4MgyZ21diYeQp5HOrvyqdmt9TXd3VyqW2Oa44/Y67fRSs8UH0F1RbX3pVKeHyRKxGJMR 9ToJJQajCEalfiw4f4RsDYUyWhyF7CLkK7FjFS+9qRUaanzr33YZR6Vvdpz98dtvZM7Pz2tpmYLt +MhjRq6xhpoYuUhSvOLCi2KpJGmrwVBoRHPzYzPEU2J3e9PtLfZBfN3lU8C+GF7aVjOSQgqVS6Zc MoBJsOZmmy6YO6czFcPz6G/oE31v8xfDFlAFSNp3B/wnnnX2QUcfQ1lEAi9Hjxo9fOJ4wzdgPpTM RhTg0eZ6zoqJCDU4AEpjfAMDtErZJoo792VXcEMTyThxZuX8sFrvV0NwE5j86quvUqiM0BaE+D77 7DNz5kzyl4iLWmONNST6TW10bIGs83fee3dFy4pNjQ2kN4TTBbuWzp3/y7czX33iseaauh9/+nmD tdf61/3/7Q52nXz44fHOdrXPUy4onYrHxeiIhkvwkNhNcoVwBHhObPnUxBu1xpoSJRqNZNnL8aol 0c8ytTV1iUjUms5IfV6MGLU1y2d+d+t5f2zr7KpraJjx4w+n/PEcgREOx1DzkL2Is6ygzdnYk+Ge AouZSMCOkN3laZq2QRMiEapI3JPExxaIW5S6wAhrIqfyYHPkwlEXGHSRmOH2o3QsS4ZCG4zDZoJu LkGHkquZy6ASY1DCBCx19FTpy54NV4LWVDnNHjUcswaBg4V0JC6fKUCVgjj1xG7EjwnuRbkgDdHw +jPRsF8VlVfuXCFOPhJFbUaKqSg0+Q1WEH6k4FJVrlAsqR9VehwxqxxdJTO/NmC4qNFtpCIxOwpU KkJJBT4hwpeT5rC11h2mdx02D12UknpgRM1a7IVoxFZEBLUAEx/r7CRu/KL99/O4HLPmzm0cPWK9 dafajew6U9fZZe897aNHr/3wpI8++GDODjsQWT964/WOPOvUdbbZQdokPBYM6Fze73EPrwlkly8F 5qLZXWeZucQYSeVs1oI16xfvuz9ptaQtoRoLwhJAGdKU1VFG6aKCT6BEDwHiNiNpszUgGxLpvF+U XAE5XRZ219SG6PzCFqPBB2J17xFEx5yR/cxvCXGzZ5obaglv8LEHR4ISXwTCHf2Mowxm0Tlqa2rq fAEgTYxwVMSxyuXFp7bWBlP/ddONtpqAldpahPA3NhW6Ophjq8K/4EghGjahUy479OpcvjyE+uJ2 f/DOW++89touO+2UjCfX33jqJptNG7npphuvXP7sY47L/3B0Y2MjSN6HHHrw9kceZWCphwFcHhJh 573z3n//+99Vy5evs+akYDAk4YedXSJ4kymOaECCQAQvgID4ClFNrSmZwpiF00QoFBy1uMVApaW6 AqX2YFK/VwoyoLOqXHIK12Uica3dF0mqCKvew1iChCLHBRCrWQ7BqJhugjg57Jw1nW3pZDphzFrM qWWznbZv/yy1Yt78hUsXL5o1a/+995MG2JAXL+D01rKqhXVxwTln7XDgQR+9+NJ/bvn3V88+gxCB +pMnTjRqidrX2T1WmByad61cRWB1XX0dm71v5HDOQMrdB/MkcmlMSRIVKLCOrBVC67CSW22hRUta Wlol4D2X83qcPlU4EBYtHuNlbXFqKBlYZW2wUU+csn4hnbIM5xF5WV+csznZICjEpi/h4ALuL54A ogMNP5v3ym4jZfU21idbVhnhTA6zowr4U3i5xUOShKqKS8Yorm590gPWlWo78C3xyoNHTw0tx1dD cMNqWEWOP/74n376CQl+2WWX0b/33nvv5ptvPvroo/VjoCkq3s4777z1lltutPnm836dpaV5PBKb OG78k/MWTpm64cQ11thj/+mT1phsoTRENDp6xPD3Xnxxzncz3X7vmDFjdzjs0EhLa6ABoKikxedb /uVXRx5xxAhij3K5lvb26dOnX/SPfxg+L9VdEFdICrT9RHeX0+m2DRsmgiAaQ/p3zZkb7+g8+5yz ifY6Y/gIcRAhZ7H7ivUMu6bIbhWtSn8LtMAKwWzP1BJggXS2AI1NKTl1EkcrsducyUxaooYFdl1K 5CoYHZpwAHUS6gpK4iX2egFCRrirIxOV65hBzlACPCPtlJkrdIHa4iXRNhL0qxKTtBxRwhIBLGGr MBh3hzoxQrO6Rk8YN/ubb1/4y9+Wd3SOnzB+x/328TbU291AZqoDo7L3iREzL9VchaV1s+UsgFaF kcjulnw2+tjVbcQimVgCj58RDOJssARqhaWpJZgRbA2OdO6aGqCnMPuw31gdTgmolxhxtbnksjaf b69DDm0cMZwkh4DXQ5MT1l171KQ1OXHI8uNwEAqe9KcLt99nL8DvqcV31+235ElXYYcIhdBDLFRw ikRi7R3pSARlPI9oTBYsbSH2DwP7VY6dmLBkq5hTJWRc4IfUHlikoagJPQMUAkBy2WYkt1VZ/VWR 1gQHcABp/DJrjE1iInTJKKGRahD6sRilNiWBe+2dnY/deTuGBO7daNMtp+62G8ve7nbX1ruMOo/f 7bHgP+Dkm04l2ls9o0ZYYjHG6W5s9AT8KasN3F1EiYQMYxBnWyXQXCJLYAcrm33bnFn33XzTNz/8 4KsJoFbvs8euV99+u1T7lBQYG7vFOttt/7err+4OhWpr6+77981zfvx5sx1WEl790oMPegM17R2h 1996c/To0SeeemreZt1il12n4mSDzqokCKMWL5AObAflpUAWGEYluFQySCXICjKiF4pzTwpzCB+q qH5sVyKPZG0UQaXLeUZbbnFdKI7hh4pdWWuYLNgRcCxwroskxowcKa3Eopsfecjmp/4BRN322XP+ ctY5nT/PHl8z/Nl7b3v4kf9idgAixkjE1l9zTWdD49imhga36/nbbu0KhdoL+bPPO3f3/Q5AnYon krXNw0m2vv+G6998/sWRTcO6g6FYKnHVDddvufNOnINz8ZhRQEYoEc8Scti729saGhrToYjT5nz5 vvvffPV1gs1B2d9s42kezOmdHbZAndadlJFMF/LW0R4S8Y1uCEFIozA6OrCQOEEUIB9KcnrIRUBV ggGB1pJoGmFq3QwJYhks3jYUPla6ELGnOLhwnX6W9pDztmd1qy2QdYYmIjkesu39T9dq/AyEhKef fhrl+rXXXlt77bXb2towZ8+bN6+5LOYXQQd4PP08+YQTZv466/033pTeE8Y4elR9TYCidrsdfsS0 7bYtdbUm4N9k6tQ33377l+++C6biZK18fORRgTXWLAS7LY3DYIJkPBEOdd97zz31W2x22znnxhE0 Y0fz85Ktg/objlrVHvsq5UptLmquQxC2hC0OONAYyyGp96oYrVd5/LM4OZj6xrKIb2WNKz92eQw5 b+KFwzflrSkPJLdNHb5G+IvnjXE01Xv8Z3WkVnU66gODnejLe5WLxMkUcAwRn94TB+yqq+kMdr3+ wgvdiRRw/r4119j1sMN0U/0NB4Wo5KladF5+5YXGJJluEoWdyU4aNaaBFT98rB5yiUpFywOfqChU UXHRd5JpZ72mePHyruHfcY0+CBXFLxbPMoaPM4gibmjaYqNN+XDprF9sN9+Q7gzKgg/UgydfyEQx VY2qb4gTRj1sZGHRO35Ezp4byKmiOC6PTIyigNgO2CziIUojDkhYyC43egxLrVvMn5TfRaNfqynS 0W5DyqwjnDNgkEc6BDin3eJ15zz+bbbY/OnHHwtFY7X1w0PJ7NQDp+NwLg22dfnKArs7EWbUO9Kc 4MEAr/hD/BNFyhSZpxC1+VxW4FKKv/cM23rL4wNXHJ5JgWoFKhVoqMaw4dycT8RymbgIF8PY5Mii GvTsIw+3LlnitLsSHW1PPviwy+Opq23MhyK7H77d3qefJub1fleRC7GY+BRLdK4E+s4Y6eeQ6kKx WLMUfE0xVqFr71k9Frc6cnYzSRJou+FWY2wdE2V0kTCaADDQFWjsnL/YWGOEsUZvHHc4naW3rz35 zNuPPTt73q/rrbvu6bf+B5M9JqMR48Zhpm/cfMsrH38SNcBfW3fkLjt1rWiBGo5srra9jaOkdcxo TreTx0+44oH7ly1aePNFl1jr6i1jx+ZAAUpw4qGsjafE9g30ByufT/5++uGHk8ePP/5f16EVNGWy zZtszBT0p1X5J6w+wsPYbq21NSV7lhU0856bKjFeOpcYa48xwrl8NO7EF1U/qObM6kas26iQWXbV qnAANO7+kYJD97P07WoYWVCl99xzTyq4o2tj3T733HOvvPJKQkpOOukkQkd0i+zfDQ0NYLfyvqu9 ba999k4kVIhSodDR3rH7HnvWNTaW98w/auQpl/3thQW/PTt3zgUXni9+IZWU/Jejjtx3/NgpjfVn nnLSxBEj19x1lxETJtT4fbX1tTNuv+OnV19766n7Q8HW8qY6ly+7+qwztxo9Ymu785w/HAO2T0Ws 62AUYa9ErTVDLxQ1nF6Vd3aHnAMFvalt1lSzyiJk5vnG9L9e/p/XXn1gzqwXZn41dviwslQSIXGf JlD00A0Hltpy44u337PXmlOmuuy7rL3up19/oy2hVS8VlmxuUHQo4K8IGmuoq2usa7jk1NN39vu3 9vu3a2rae/2pR2673eyffx2mYqpsI8dmjZBoc4NfKsygeh+QhoD2Ck4eWqYNN99QOSA6dIFr7W13 uO7tj15f2vpZV3TbLbdcuXw5H4KlN+f51z+5+9FfH33O5fVGUffMXUqp69NVOTZNW3/NTTcdO3W9 NTfaaNyU9XRL2OoK+cpgvsmTJn366afTN99s3+13aKipvf6ZZ+768bvnVy7d+6ADK6d7wP4UDJ+d 4gki3IhpcdlJnRqCbibDuJWeqtk1lP3ikNNe2GDnz6bt/cZpp7jHDDf6VqXx1tbut+feE8ZPsDfU 7nLAAZvtssvE9TcYt8GGI9adgtSmgebJa03ceJM1N918xOS1Jo0fDzwjH0bn/Hr8PnvvsN66W3k8 b772ysRJazROWWfcOutg3Wn55uuPb/n3L2+9vjwcLPcz8at497If33rxq6cf+/mZp9cYPXbt8ePX 2HDa1K22GjF1ipxdTVxkY4UV7oKpi9JaYlFR9RSHhCJRqIOVZNc1BU1TfIAe/S+Zk9i4kde6yBDP 1vgbpbaR71zcQAE9gkw4IMvKcTq//fSzEHjchx1a2QsCFYjT8LgfuPIfTz7y6LSNNvLZHV/MmLHT brvuPX06oJker2edddexNNT+54JLnnryKZhvZcvyKRPGXf3ww5tuv2Nva+RA7rfn8HHjDj344Gwq G/DUTNh6qwG1kooOxMPYm9jzqydk4rVgrAA19Gnh6ue+ufyGzfJfVzRbaAtbGvzVS3GL40jiLoDF /P+19x5wkhVV43b3dJjunrw7m2CXnESiiKhIUAETICrBiIpKVgHFVxTlVV4QjICCEiQLKAoIgoBk ULKAomTYwMbJqeNM9/ecOt01d26HW7PAun7/vb9l6L5dt+6pU6dOnTrRhWLGl7waXTD/1SeeOPnz n2+bM2vTTTchQG6Xt79t1wM+1jprMpht1b+euf9Pf/rH00/Dabu6Z+ywww7v/fznvf2f+82THrjr 7mO+etzMBfNzoyNb7bhDgqNu0EUqFsyVbXhGOlz5nqWx9hlhTyQqJacWP/nkCA4/xvtFjp6kiKDM Y6G49Zu3bd5m8+Lld/Z/9hsz8w9RI6TeG9IDQ8n2tuCwDlbLi5lQVzQ0Kz666wkv9y/b7plr6vWZ x8JENUFjn7TXNz6075wNN/jaeeetWrrsS3vuTgrHx156ebMNNt7lbTufc+1vHRBADpORpkQCh6jA xiTRCGVGY+1TxJolTz7Ru2IF+ZtYTZ0dHRtss03cWCxDPT0hpLxJn5S63fcMLkWB0xrpGH//Sc8M 9Gzx8IXNdcz/yJtkpEbrHQiq7BnLVobWmwv7vn/mPut/4N0zPrQ7aU5DnaUZu71FXP28F6pLdCO1 LMm+F31hj70yo2Nbbr/tyiWvPvvSi9/831NmzuomEwba7fk77DCybNnRH/rgk08+RYEfslm9ebtt LrvjLrxnbCcv3H3vJw/+xPDgAFs0Frivn3DCET85g18nBvrCLa1NDvEEmNAymVz7jE4HDITSry5J zV8Q6knf/r7Pbrb7ezc5a9I+7Gcv43m4ZAoW57nGCVSl1K1b4Qjvg2s65B3m/sSTT46lx9759ndo xueB7CgLlzhI/J2lIF1+4smH//7IvfetenUZbpKh1sReH9v/HXvuiZaQcgfp4WEsExhSegcH20nn WCwetvtuP/jpTzbYe+9/XHv1/51+GtWDhgpZrHvfP/P0Dx70scwolt4kxhZJoWtilMTl3CBAjqVS Ftjoos0dTfKrxlW9NClw9fxpOm5+GHzhpbnrbRzKETLQ9MTPz3nxxZcO+v7poVREfOES4V6cFjvb UaDjLttcxP0M56tyhgoRwfAN8jk7Gqec8vZrAFM1nPqno1KMo1iQPFOSKhwI4uNjo709N9/4xxdf eAHDB8U8cQa45LLLYjO6JI11Zxeq7sVPPnXUwQfv/PZdZs3qvv3Ou/beZ69jzzhTfmWBjY6wkC67 +NIn/vHkWeddgDaZQsXZAn7JYnpFPMN6V/EJ9+NAvKyMKVUzajKtmnDDttP0T2U0knYFdx0vdZJh IxqXesimTAS6UnzaYqTIwG7EQ+l8/tZHBr70nTl3XxLaOBHKc2ZqK80YX9WFM3B01lh4pDlCIWYC 1dSLyfd2kJbKFpqGw5mJwdD6nc2PL15xzM//EuvZaEl2wUh45kf36Djt2GLrRDpZqTnpGZx2CLSg n0xL8dxEeCx9/rnnrnz5lVMuPr9v8Svv3Xnnu/56T+eW2/QWqAiG9Co5RljoNmsub2e+wJxoipXS sL5kM/yV0mgIMRirMRgbNbG+WWfcaOk1YRRH5ynKPFTzxqwtXam9AeSqG5lmIjf5NKQ3HsZxMJGN DyeLuEx3ZSfiI/iJjAyun4B+Op/pC3336pdL6Y0vPi3CiRaNbaw0EWvK471qzC94TmKsRlHpPU7Z ghIGVshS7AzYlKJZTPuRIUyRqdSKzo9u+d0TIsfuhd632B5NSx6VsnQJfsSWoGZ5TD5TC254CYsH WpOpa396/sqlywcG+mKpZKy95bCjjujacB45c/C4IpV2BzbC5ctD7FvNiTt/85vzzj77D48+Glq+ 7NJf/vLW225bvGjxzO6NCa2/5MorujbcINSdKIxkyL8da031p0dQNLcRw5GFJ3jVn1NoW2ZB7SWm rOWU2iBkYxmPJnKJdPPESLJEHAEurV25Uuui3tBg6C9fPWnjd+6x2bcPL8QzYePxqDwCA3k2XMxh m2wiYCKMBGffByqQfpTJuKT89QK6phk374O/LFu2bL/99hN7kNjcZIJhnoVsjmCQmOZzgHKYePZn jiFY9sX8JeGlhtEaNpYu4BuaWdn7oa22/vghB22901tvvvGGFxa98snPf6Z/dBgv1F333muDzbeR 4JNCSdKdJZrV1OuTM+zRRSy8lXTYjU8utNTcaWQmE5pgC4UUUs0Tv7jp5tN+uv/Su03VYKFx0WnF mp8LjS0Q9zpuiRFMSUYYN/pQcSopX8IKpcS4lDKpCYBwcAihjLViflVfYs5M0Y7JChTp5k+XXPz7 iy649JbbOKg+fvVVLyxbiurmmccf//Mttzzw+OOhBRt87QMfeGXRok8ffkQxnabUz4cO/mhs481/ 9PWvPv7YY7++/qYkNrR8lsgKVKiKpnqB0eZQSBxV2hZULVtTp64He1PqdsPkplYut3jQSTHZmMLh sVwY3t3dkrvy/oWf+fyWQ0+H2vEQIPo9gh6LhP/gj4Adk+yqNDY2yplPUnepLde+HabJZokfULHA 8SV/1xO3vPeIbU8/urWv2JZJxLeeF/nCria5kniDeBcDPSCjlVM+URMHAmTbHp/4vy9+idPe1y44 f/mz/95vxzf//tZbN9rjfSzt3t6eWbNm1cxn4GUMUoO4rw/xMJ4k9EQ4rVisPK8u81xzBxoAXbjM Nk6ToOdrNgwtfDGlN9k5wpI0Ck4BI5bds7g4/Sr1kubG5xb2O+kfQ73b3XMBaBSkm9IG9nH2EnJi khCJGILJm342Z0o7AyyHuMHB8Ay209i/o+/Z7Mufi599qPhfRbzJxMoIZnG5sCfZ3nAWev7V6Bbz y+YaY5hXHYf4AeBbhdQCZ4jGrjr91AvOv+Bb3/5WX28vjsVvfvPWH953/0y61Jrq2OdTh+ASJFZ0 LBbCQMIre3sgVwpfVCfdrKYBZqFmtWJETMADsZgJTJ3rEhQLZYdWjt3z4aMWvHPXTc89li0ZNqUK N4mLrGzM1EWCZlpQG1amXnZ0zjeUHq7UWpqyhzT8sqZzlQCikqauNLY0TjT8U9Cxj5ehBdcUiuUb 3v66CMoeabjoEW5WkkyqiISpxPvFGfHx887+2dIVKz7KdexxX/zOqZ878eTNd3h7c0tr0mjQ9E1S KbhSJNSW352sE2bWvza0N2t+sGI4TWMYfBCuUnL8iVDbATWiRAhQOJV/MZzxW0Lht6wqzSo0YSJq IYxE/so/PrThX+t5Ad3qAq4HgMhcUvpWfP4izXgwJyUbH1fFiXUok1myZOmKhYuW/vOfv/n1ZRf8 7Jzrb7ruxd4VO+72ztAcnOpC79tr7zdtusV151/0z7898tPvnbZSvMdI30Y6qS6K34hHjRk93VdQ VRsTFlT7s6rFfK3tTRVefOOaUmKXlxKIa2aWtJ4ys03hzlBXMW7mniB4OB6agnAED1G4qckCYBxL zOV/uxTKjeLrpkqnUnp8bteMTffde86PD0ud+8noMe8OU2eH9ClVE62nKxUJsZsh50rF2+b4YP/A mFpokim8XUjhKN1iW4vHtXH15S3xzKwlk5SjaZZkkJCxYnnq1Ns79Kll0gKJUIXBmohl1TCD5O0T mmEdxWPdnd2dcdFrATb8S9xB2AXJH2LKZ0+uAsCTY4y8XbFaPa1KHVIqGYYl0b+SMWZW9+y4CkZx xljjsogNHBd7QnT++pNGdomTLl9S0JnXicpFJJU5m2++6+67X3DRr2+8+Zaddtrp0C9+6QPHfvmj 3/jKPsd+NtSVIM9ChBJUWMvMskpRG4hIIwfEGgTUmVb4EmGdphAzWUzxBo6PZQXDJQKBm2JGKkNz IBRqLi3ko59bIom2uMgZk9g2h1R9nTvL9rWchnFytd9h6KbEobJeNRb2MZcLghRvXNZYKvn1C847 5y+3XnDv3RfccfvH/+d/YJe+HiTqyw0v08JgjT5R6FP9qOqa4ETuGZfKeDVtQ9MCQFIpTrV1bLjR xiOZ7ClfPeGY/Q989ulnP3fU0Rfd9OdfXHXtF44/QbN37XPsMd+7+jfn/+2+Q790RKypOT8wxE1i cClIpMd2yTbrlrPHEaWKDPfGFgNoTvpDsq+89guH82UDS4nbc+mqxhSEw10zunDbkoEgkCLxldUp RUoLufRJG9csYxWFiWO37s2GRofGxkVaApKsbEJ1V5rbWpn65vz4op6F6cEBd3gatCwWCqPLlrh0 9fbd9zz+xBOv/vOtF9x8yxlX/GaX/fZv8JSRiZz4izu5soqllATn4GhUMv1PVXD5geF88wYUUlgd 46QLcn1tsF4SbMmB9J3vfCc6blZC//CAcXsWbQl/pf5IXhRk7Pi4rBeIj0lJUVe0Y1LBIBZNj40i m0lZe3JHZLPNopeITmTxoGoVNR2p9qOonvJyRIrF8FwMI52iTjUCu7heeiZPMiOLmF2GUQVJn5qi 5leZWnMej/QP4gwW6h8Nda//5OWXP3Dvvcee/sPQ7JmSfQMxvL831D0TR+nxplJmIkdalUKpSFrq ieE0egn4JiEyco6rcHGjBSmf+gFG8iNL6I24g6umG8sGGmiS28PXUPmVumJZPEhRblAZtrll4TPP L3/xFaI8+lf2vXmzLVPzu+ObzsW1OyUBO2PkOW5KtDahCiHDRl/fPjvvcspZp+56yEfO/NbJK3tW /ehn5+QnipG2NhyAibNExy1HbbHCT24xvtO9QquMXoNmvUxfZqwSSStjMfnTvT1gahAFmFHHMEij 4w7FCV9AUsyO529/NHfkGW1PXh2aFw71ZCkWXJwbWYl7p+i4QyPNUXLii47czJdoe436WPtnQltz paZl2VBrc6h3VWG85YFdD9z9uWsRlsJZajAWh2ZMZAj2iaS8zhVefQuQS3oGzjYUbRgc/PEPzuhf teL0Ky/vf+rx9+z1ngcfezi54ebpCDWjpTiGlrX1ZukRZbHRi9l9a5SUFCYPhKqMcByBEuzSsDhU EwuQIHT7CK96rdFSxW0f0YLYVC4+mEDHPTEjW2weKZYSxWWJDHU3Z69oKn7j188Mrdjy8jMowQmU eYpZx8KaOV3qr4o+EiWTnPZ94FW+EvpARSd03KEYBoBQUzYy0dY976nw7puc/NW2I3B1zxRmJDLY lCrDF8V9JWGRfmggHEjRzuF0a3d3trcv3tbK0TzaHOUgrrFVWH1QIxKuGU+m4O8YSET8j0SxdccJ bx4dgWuIQyzpEUjbnE0343ksdUtL2BhIIkbWE1EPSfaeupdStbE1yHnOB2pY1EDJXISwBch3onli PDGSb86ECfe647CjN3nr2zc58rOkFsqN55rnzwtlh6mjjNxGhnUMQpLLk1LD5FbyqEooqKaHm5pF wRrACWBaLHgNMW7e99RTTy1duvTAAw9U1YSsOhFmyBqEjQ+TQ8XqKtEqZV2wGulEr2k+YO5DYUSc jiyGshVAfyuzGZu1gBcM9fVLPViKmZpnfZemaTfvJ35CBCh0Wz4O5X1EYZZqIePj1MEiU4ewOHZd dNw/vPbvl1y98xnfCs3uDvX34UUe6h8MzVt/6NVFre0tkc620IyO9JKlnJrDOOSu6o3N7QxvRWXh SQBUya6FwA1MfskcPi+widavmF01GJvTafi+KNQkkq0qqF3TTuXG0vFwKZZqE7mP1Z5MDD72r0P2 /XC6aewtb9vxznvve9eee5xz5W8pE5MjBgfGTlYjIyX7sOUlOAkHz+d9uPLh1rJC1XFXx9x7x8di YVwTQ+lYZrxpwczCxXes+MKJ8/sfIEMY3sGEOEkZZ5McFr2tJtaoq+M2PIh4QdGEYnm7/onbPvr5 Dzx7fXTLjTF7QjFEoYi2dGpWNp1ZVcWSNV6HL3q6iYn/OfDgRGvL9666snfRKx99yza/u/XWuTvv xvAhGEoj6oO+sXu/s6EN9fRKvT5xQyq3rXnkohMXxAqdm5eydOm1Oj8RYVcsKshCAmpk851YnF7G 22fH5xT3//aTQz3b3PFLtFDioGbibO0ltI1rk8mTU3/nENYm51issitXJuavH8nkF88+cObXDm/5 /ofFeF7LNgJi6TwwJzuwmCrGmTj+1BUC8uKWBaB8QLYryi7TLYmAxIJVZsdaHkPaCPvQQBlRKJmc DUZb1YAdqiXZ6J3r15ykfzN7ukBW9IfbW5r6M9d9/JjskhUbtq6XbG3PzWp7x/mnhObEJaJLI5mx uBdygNNKZpWpPId3acK+hnD5f1zTjBsie/LJJxctWnRwJWDEQoQYDtqoURE4AEaeHku3OFR0pavM 0IgoLGsFKfhepJp3l6K6WmXKt0k+fup5QxffmFy4yNAKUnKxRbTdmUd23nmLx15KkvUvlEmEKBYS bQsl5m71ltQvvx7ZcysvDHafD8SArPCeoSixQg6nv3yG6KywpA2qXKPLVj3614d6+pdLUC45LTfZ ZOf37IXybTyNFw4SerArGMN3r2kLYjWFZOC4CkNj0ZFceP6MicvuXvS5YzZKP0Ed9XpPwTfVONm4 2/xVDz942Dd2efbKxEYLAgGoaUM75eCPU1ThpEsuHl340iF7vusnF16w1d77MVkA4FJS1hAhuVma sZAHAgBta/WywJZm6xoDsS6N+yd6ExHmNVU84OTnMiOb3HZ2PVDGJUHfOKUUAwGAV2aWLk0tWEAW 2d6NDk0e9IGWcz9f7yn3UuAgFooF4YEAiP8TGRyplePgZ+lILbwUcoWZOtYiJ7Ao3JbijNj3tycG lixrX5UPP/zSv+9+eI97fhnaXuK87JUVP6ISCTq8N3UduStn7LOWcU+P3wfitF4DPdjqudIeSXQL kvtls4+eV+peTG2OjAEOF92ibikbpVVWrXNJy4ofeuOOFVRNKS5nKlN1kc/bH3TADjdesOHtl258 zzUbP37TJvf/bv4jf5j3xJ3v++6xW/zjd+v9+5bNnrp9g+funv/0HREOqitWjHcZ01nlkuWdySAX eG/6IBGs6i3WTJrjvobrNroEWg70JpJFnZwAuXW92e8+aP+Djzji4MOP+vjhR+2y1/sqhRalVJ7u Hw0uutLzbwNQveOSMomVGW/cr1VE0kySwqhswrO4FQiVyNM6YG4j8zYAVbyPyn5EkVHyUOp60dfX wZl5lVzlhjpAslsUi/f95c5TPnLAd770RWKy+3v7FAMatRBIhgbUMgbK58L6z9An2dmcu5Wio9WN vTCJsDdRpM+xgpAWPiPpNJG0BrFVYChtqygZMC6zlkQJJh0hpWbFS8fgpfpBea8bDShiEU6DXi+E j/YhS0SFAx2agUsGN4duy4ipj4HJPhj7cNGkMk01z9zr7Zt9/qOz/+fjsz69T6KzVSda/lbIdWI0 kyfHw9Qlj6BQsziBIVanaw2pSoDy6aefhj3tvPPOHLTN7porHzRZp4CKbtUcQqxiwxYGlDEb1yBV p5rYPfRQSOhmvZsDjOjp1Dna/C2QBSU0IYpFcxgxOsRK4UTjPiya4sqJXUXCKcrKqXpb+6soFk0l wPFijtcRm9siKZIxUTSLI6O4n5NeYyI0OByKJ/Oo6sU/yFQnWNbT0tJdWrj82h/9ZJ/dD4h99q3j pBeuHJulPqShQj06lXXcRlsqSqFiiCpVsu/BW4kh5jWpBNUk9Wl74BWKNuMn3RTKVElFi1pAHH7F sZg0ICNDI+2dbRTo6ojkxa8pFstn0uRkIzYBo1WxKUrXVDbFUk7KVK+yxocZgGxgc9MdQkkPxFot pyXGqTpuioUVouOl5DheAHGy7o3f/nj2iB+0PnBhaL2mEBqsUmdxxvjyLmY9OiuNH3eUesl4RKuo oq73VvCUk36xmEQhik/cssGJgaYHPvCJzRdenpzX3bmc1ObhsdZoKVeKF6d4nSu0Kr+zG+NU0oQu KJ4sDQ4/9+RT995xeyGDnnpiRnfnJ75yLEHK6XirtMNrcKq3L4+Xddz0V9Z4UU1UWDwaU85+aGUR JXLFSUu8jkL3QuV6Wge5wcI1AgM6Xslz4ZPXSJTVko0PJEvouLuyxdRoMVMYzm3SiUmm5Z8rI//3 +4XF9PzzTmZKSMhESu9CjDyL5MqXQ6KoVqDtSATarvv2CCtIPO7jKKNC4bFSIdrStqTtgNnfPGrG obuGOnj5RBYdd+V5HVQFseXFW69zlmS2QHbfch1RZGrxVTLZj8vprcsld6R7sSQbX8ayp69QfqmE q0tFJyqso5IbBGcXneLGEVuKf5VwqnXcTZQRmkDHTdpZcniBQZIa5WfiZZ8bjyFKD2ZCKzpC9z/y 22t+dchJXwvtTFwoVSrzBAVozkWSs+cT5QWr8Pf19aGE4NikBbXdrzWtKgEXMG78uMkSpVCWsRki 9MPouKnSW9FW19NGgVUSzbRNlsWr3VDvZqVEZDSCC5Hp19vUuzJAIgkNmHMUBY3XjOjljfxAlhyT JKzcJXuCUD8egQh63OMLM4YO+umloU1nS8CLvh5LxmMvTrz7K6kbfxp691Zer1Jduj5/Z+9c6oZk /pSwbcY72+V15vKORT/TWJKKSKZ5lmU4ltK6J6qek8SEarA198r2hDyHRHzeyn7cdRkHoyRGJ5vN SUmKhvxFqXMsk05A3BVQ7YimbAumaWlojCrL4bld+SvvefkzR2058Fi4s0XAE6dZDFvyqOw/smSp 1Y6Gt4VVXRMG4RQG4fnfPX7/IUe9Y/H1yQXro5bV1G413XpUx41QQBEamdcyAsIoLyYzorARigWM lTgBwbS1ttXDwCSlYb8ZGZFKwRI1V+60HnLhQQWKIMcCGLcidnQMvW0CocQHg2QmM8pgEWLkTaXe sRUtzalkc1f2wFNeGejd/C+/kEIO+ljl/0oYoQxpsydQiDeaWZXJSYnV14enKYx/4cyPzDz8E21n fVpeVhXZLYjFQT5MyFLwuLDcUoe+o5l4DgGh1tou36OoDkXWpaBBbJIbGmr2PyWrG7USwatBijVp mR7Lj+c727tqYkDCfFWJb6Agf30rdbDVJZeF39TUd+Nfr/vOmV+4+hdNW29gSh1rW0JPRIQqEp1X mXveJbXkTZ6p6WpL1rSqBPiQjEhjYldv2TKOX4FUly57UosUoz/UvjBpiqRTuVhrNf4JNprCWHhJ t242Z7m87bx98zvHTmz9lYb13w3XIw4KiWlq8n7xY2FJQ/riqyv+sBrmPrqgo9hsbKgSgmNYT0eU DJPFFrHKel+DdEz59gYACPCImcYDeTCcwRlDx2jc+Cb/mSbyVQIACIRrwqNFkrirZ6RheiIFl7cR +cFAhmEK873ArniqjwHxdAkjMQbiSjqiW04SU0damfSprxDTKwkXjeOdJLDrFA9u5SbgT9I6yD8Z vomZJD+4jLM8sX5ozYMG26GJBVQqov4PX9S1ts7gZEuWshSShdCE4us/8nt49JKmcqPARNkaD7lW I2tyPrB3jWckHFWmozxP9ZDLrpQmNWOdQfkoFiWOMKmqxmQVpqXgSqpDSOLijkIsOSzI7B0vtseb RSAW4jPE432cz+NQxtSbtcamNEeKAuiFYNf2VGu8EnFcjV2hASSFhuiyLyFagbzwStR1mEAZi2xK WcrxSFLHKcu6+ilhkSb/cAOqLtMkTWGtLPE6U0Ai5/IqpKHsSNT2gSSMRGZ2hdZEdBN8Zzhmy/vK M86HLK5lnAE92FEs65q0/HC6H9aQjhuJEmkVJxjZn/RAIhu0fJCs0xX1GN+r/5nG5h9+geIqV36w ZmM9c7K5IXcZkUIDimu0VTnXrPCyqa9Bh5XDrEyUBV4hsQddfbwMLfpNgoBN2kz5ZzSS1FkZS0Zy ZG+QTbo8KLu9l49q5ZOz6bnqH2p1kabtW8ofFAYLTBk/tDP+ORWQJsGb0r4ifuGKqfNS959BrMRw TGLAvNc+Vf6gN8XZrzIDXsxUBlV+j1F8CUc2drmh6MT9oRFOymVBpsppXebrqaUhwh+4JGO7eLDJ Ab8yxXJTs2vmxwdCPZo+jHeKp41iyIN5JSohQj2mVMjSItOLkDLaDRGaGayaoKlkRhtM7hJE58Ho 5Ex5HteeK91OEkaFurwzKy3VxdVHBnzVEVaGKZQnihAEGKTk5iiJsE064nKieY1GVmwYadVMr3E5 qU3VArp5g6llI20z6Z6+lTlycVQIeipuBbHWxNCYuhTzmrBXJ8XXvjw1qlMibbGEJtYlV9vYsFC7 XjzzVWZBk6g23ZpcyJW3++bXS+RCMPCXCh8TzyjW+9DocF8vGh/BBptVeUmac4ARvy1/4JvJXiDw T5df2/avScfNjuHybpphsX3uuefIBEviQDTdOGZojmKDWVkyKgPUG4YQZcVlWKgHVYQELtdpjq4i myHxuTh9m9Mxc+ApPsLTpF3gEIeMgYNtrBJbUX/3w+8bVmIEWS5/3W5JhjxF4cji4GCA3xW5SpLj ExFWC+5o8baxBx686dcX7X/Ap8Nf2AcVvIW/sgRNMK3ggnpaU1SNQFbZ60QiiMcIsZtU1BqWVDlb VjzWEXYZu4hfVRu7r70J6BLRW7exxpeZcTEYlA+lvFZE4UnJVGdKf0UCgral9sfkTJXG0aOGKTSK olXKTjblJiS/M/p16odls0sefuqeH57/2fPOD81uD0XGQ22YEARRhVV9ucHRVtKwvDgWQouC7iGd CC1cEnrnhqPzx7OR0MyR0BD6m1BT14tkjCmFRnqKvfFFe35ygyeuLM1PsdD7woWZFI6MJ7LUMqzA Y6FVIhQW5r2qyAzUmW0mIh+qLlBDMlmb5gVcDeNShBaeiFcUJtEohFCYTFUy5XkjfYmo6aXqWjPL obNgTBcitnmXDOLPaCmLT3tSTlkhfCj7Robmpzojheaml0cXn3vp4LLF2534ZSkRudnGIYpqbrNB qbkw0hLnCEke8VixaTSSk7htvaqpeiJLnARphRJyhIhiwgl1zBhY7xNtx30x9eEdQzM7xzvGM0QW VlCowCPPqhLFRyc+5DF4DLkE4YrezOjxjaLZc+JhDRozjzqY4pcrJWrrZ9+0qIM4hYX6mMXUmRUP wwKigFj9Zf8w1gsvKUhApdTwKF9AW5bXTLcJynwuGw/9+f57rrl6z68eH9pi09CMaKktlE5GC+EI 9ijaU7ROUotWdDkEmhDYgYe5xM1P5wKfq+/HzcPAzV/oXk1VXvuVbEcmLEIt9bYZ5Rd6enqom+Pl 9crTmdtEkIpZFgR255FRSqkGjpRuRwd6RQ+YmkwRUPMpaSnW/HBre12tpZ0uUrznC1QvDOiT9rJo h0ZbUokK2xKGGnphcf6th0/c8P3ku99mkSCnOer4UDbFQXEM0+zvW9E5Yy7BtX5anDo8QSyiPWH5 Qd3KsS9NfkTKiQXYSYQdTLAnZls9iRfqzQXdYghNJog3DtBvyl44NMxG2jRnVu8f7nzoy2fu+62T iTDGd4C6t6H21szChU/e97dX//VcMZ3dON08lgovzg7tGJuFi9XGZx2b+sR7hOSMFlnUu5ropylc uPyvT372izv9686mrddTeWpSfV0LV0SLI08ECiIYpsfSo+0dHYEtGVeeKDMYjSkI1/giVEP8LDva XbodHhxCGV2tOPYpeZnT/NhAcyjV1JZ89ugfPnntDa3JeDqd7Zw7Z8czvzbrQ7urslu1Lpgy80Xc ARtHAJk3IEKt6C3NnxvuGXx+9gFzjzi0/VeHiaxeJUnRLd545ClIpAIQy4whahBk19oesLrZ3nAY S4/iFpxCyd0YXUKE4Irqg0E+qbSkokeukOvs6A6cAqZydGg41dZqtiW5hI1cf/d9x37/gzdeFNqJ 3PRGzjY2pNIIxexQKhFQUjGesOJImkrZa6OdCiKNKb9bxj09VQkWPMqVnXvuubBgBOeTTz75xBNP JLLG5riCjz/77LPXXHPNiy++eNVVV11xxRXW6E8b9X5VGdBKgmVvkKn3vW28rSX3WO3fptyVt1R2 2cbNaYnEp/mdAzpWhqBuUEFXuVvVlorSWfCMvi+WLxKJ4+2hPPFmToN6FZ2eaJakaUBjAcBoiQO7 lQZGWxX4elHwSuWw4D4ZiHZb/tBwYLTEwQtpig+d402bLR9e/uWTnjzymGXHn/3IYV9/6MCjn/j6 mRve+vwB+370U6d/Z5uzT3jLoZ95z1nf3vToA1ticcq36wAVeLEYo3HQyuWx2JzQLA23kZ/kx3pk Zc0QgTiQV6m/U+BkyYxLwl45JDldzt2aJVMel7dnPRHaC8kxI3EFgtgND//I3pecsdNPTtrn68fE spQDMbomRZqZJHRwykIagloW9EULR9NksrtrNvHJ5rEaDyoR6iGiMQaUUsWNKuiSF5mE7CraB3Sr fQY1UyqVEG4XPqDEZuz69u0CSTTSTKZrMpSCbwxBkotQ+pUcn0a54G3MOUCY/jS5tpmf8jUNxo0v PfsnhcouuugisqP96le/6u7u3m233X7+859bxg1wOCccd9xxBLj/4Ac/gH3rT0DpzZvqhSBKPGh1 dQJvCwtrhFiCVscdKkU1xaBtVjtOplpTnsS+td5cvoecS4rxBg28P5VtRJ5bkiyCusBsv1MvUgM1 O56YSFDZnBLLhsNlEgI5QUv1JeISHRGLqsjh5QaxkpbICYB4SyraLpt69P27bLXs7jmLb9926YPz F//+7Svv33XVfbutun+DV/+QPOtLoc+9p/2z+8w8bL+ND/1Qx2f2GZ9FSFPduC2JTQ4RkuoELCVC oUOXpqjjSTfk0lIw0N4h+cgcLtYx2bEcGkoTjLNSrN3hIt3ChOk1ucPmM/fdfd5B7+s8ZL/cSKa6 xMdUjVbDruFvpjwFdZAxquOC2aB1glOvQy5seoCVkfDMYUyoSWOtLa3QrEtjOfM6RKsJ7UVMdTeH C9SnJHHV1JgaEuWmYjd96vBrt9337J33f+Ka68o90boqDFBs1Q4vatDEVccNR0ZTcfnll6OdoVzZ r3/96yOPPPKTn/wkHv5nnnnmgw8+qCEksOl//vOfhEdSK+euu+76yEc+cvrpp8PuqWeGJL6SInsf +hAH0rGxdDv1WcQcIBmZGRpRjrrElB69n/Wr1F4h+0cmF00l4Fzi4zm12ZTH0cOOjTATHFTtXufF wgS7RZRjY5odBWshIJFCXhQ+KtGLnrLsIS3dUrMunxOvZFwECnnO/gToy6Zb3vONQWfSU0jcpTCl m24ljxw8UTKUNqcm/vHsS18+bb2Tjmo9+L2hbMYc7aXiJacmXMFIOy6ZGfBJCeO4Xc4ZrYdfFBTl Uy1lK9KjiZYOwC/7Gxkts2zdquU22jfUhYhGGsQcAwaczCrnNAmRR2r3tBftx8gYxzrcxmToyKyV zUnHrtow1YCB9OxouikZL79OhXrNrqcTJzpuMw5UQOlMFB2eLPIy/+S+qZ5SOTNqe+aVcpS5XHN7 u/BPjcYWK7QnLJsn6LZYJL/f+NJl4TkzYy+P3PGJ4zY95uCNjzlI6keDThYd87AqG5rbGcqPjt/1 yqJPHb3J368Pb9bJW3Jkl8vjPNREpg8LLa/GesHSHs9KiVGIUPJ/TqqxhOqARMHlMXBFewL8kq04 j4o4QoUQHZxROBC8bxI56MXMYo2XmoTGJ5VjDYkOkU9VXJWZkiIkBidYqyYmcvnWLkAtK269MyVv R5KTSDVRMOdHSeURlywcFb8XQydkEoHYSuTLEZqhnHUx118YTU40zY60oG0NDYyFSIbWk77uoEN3 PeWEOQd+METO82iRlBtMFtQi2W8o+6lUzT+lK53ZEiK52CU5b+F3T/HM8dZEU+uMp5vfufkRh7ee eggDL7ZENQWNPmKsMsVCVoq1RiiLqpcSicVQ5at4mhbyrO4YuhojJou6377dEBCDBUtk6+EUNTY6 2j1ntuQxMmIEDEH8aydnyqRKlmgPVncaN08wJftHZaakpWdmRQedJ+l3Dg5AOhSaoUBH5tDVpwAb b7LyZ8AbGxxiwUoBWjyhyETU3JJ97Pm+Wx/I9fRjOhtuKix4/zvnvHdXSi9GKP5JOsaE5CbWrhgY yi6IgGqxeItaenH5MG1VCbOAbveHP/zhK6+8AvvmYpCEhyJfe2tOqp3tXe9611577XXqqadKOLu5 NEYZts5fPrehdSLHBuwn3MQuJxsd3I4KHLX+4STEr6LKJ70nu21ThPZELTZoj1MOOy3SMWxATA2s VSIeK/9YLiTrFTU8+RUBIEFbym9LUVexmMN0pwLDei2DGo+3JFJi0SZHHwY6bWxKHHiBoSv0ejg7 E3QhhwnmimTT5G7KT6ycyOYpBZml0KqYJ+HqwthMBiKx3nAxTIEWo7P8Yz3gOUzYOFEnWFox84mv sYBXfqPgAUgMMLJdyIci40Lex988lYBeIjhpWPBoLwGfnvZAm2xubkmlIG86hx942/N2CV+UngUS MCN2Ns6FxinK1F8i9Xl5LsozBbQI+01Nps847kQe5AAJ/RT0nxSEpLin+OqFiVGhNwmuwXwygbmS SCJ4UOUfGdvlMBrBIzvckhDMwGaJpwexWNQk1EEKckhd9vGIYHssjx1SODR8KIchTepEsH1SLAAU WXgYO7gC9S3JZAJvOQ61/GqmVf4ZDY53dLAMTGNk5Wd+GaChBCluUH6kQNTF+CSlwWTZDqmZJrMq xIaZzIt5DuYJ8UWGSpuomAAReHHlnSlRAGPvJsoEig0ZxELdQFvBfAgPQWbW0AzmSwx5RUILyV7X kmyi2iFuqQyO+u64W2bEaN/aOkPKW4/l4cLkIyOVbWeqLYEUaWZWJ3fKkuTtUktX8uvKr81xBl7I ZSVHOu7/MGxRDkihD0UX2IYG+CeWRFwA5PDXZIm2euUycHyiscfIIyxzRAfPGqQ3sWALIsV8CaLY X0V0gDeXke+bKcG8rm6WIbgSKjUzW54p38zm2eZI+svqFv6qUUDl1WdQKs96GQ78XSK1ZFAJyYAb Cw2NJubPXf+zB21y/JFbnPjlt37rhDl7vIv9hDVVikPIMu+To4aGjb+NNeS6sGxfG1eJG3aM9Yx8 IyhJDjjggBtvvPHmm29esmQJIgAC9TnnnGMlbqRvklddcMEFSNyXXnrpJZdcgtUFWqGQAnI3BeB9 EJAVjEkmu00g9Ix/vG843t0Z2JIG46t6wnBkcwBvfJUoWwULbQk+plEltpTJN+HV4HAVVo3EZpKC e/JIVHj6xdh2h4/f+6Pobjt5OyiM4gMz3twRDCpPjVEzab31XbQlRaqUsr23BVvGikNp0dt2BreE QRQGRmKznaaghIjXSmbk4CMtMZyFkZEWCnu7XC+tDG06J/T88mc//M3k4e/f8PhP1HyoeNXjyz51 1PpP/TG8nUNJtpEsyvGwSbAecMEh+4ajbhgYX7Ey0t4aTgUTDG4NhYHR+JyuoNfL7+O9w1IuuW59 2sk+Xin1kaB6XshDWs+u+NO7P/7W8787d/8pKzFN8jI4ogNty/lyyauRDSUDzMLo+9c/7ODYBYfV A3tiaExyf7cEr24RmQfTUu0v8JKQ8zQ+5C4qq2LfiGxdJrSi8UU2iRIHa1P7NPCiFHgzk+WgtMyO 5UgrE2bv9F75iXQuw9Y5Xd49bYkb0QoGTaXgBQsWnHLKKWRHO/TQQ5HBt9lmm5NOOknzNHEhhqP4 3nvvvfmM+HjQQQfZkHwet828QxDjq5O+Th5yYVjauch8bnrAEnpnSoA7XJJjVl2MHS5cl3zuSlLM ifPxqiGRwfH3zCB1lntz08TKc2VbkAMAcvo22VQCL+Rd95TBLjZ3fSN5i7wBog3AEA2Nw9Iq95A1 XKDUNKPU3DpmBogmikPM1KkhkyRVOSqn8wAcUEtUM88EXpzNKRgY2EwbROPNEmPrdrmvYYHWLcUz wjHJRae8Px7PUrVi8UqxoQ1nIUJVIKSIBXXwB6UlR/5y5eU8WYvxc2102Jf6Ea7DL0EwTm2JmOMo 72ZrQbfi4ufKeyU9IYd7t0tYrpv9hIhUTU7rvWAOcBL3Ga8GylXi9j5JiL3m2UHpYTSqkvTHNtA8 syhJNGGxaku4iTsgaV0pVqPqFDnmqJc6hwh8J01VkQZIEz0UWcHy4xw/fCme/U+hPWQlp7Nk5JZq HUZvq/ov3SEkNyWmfuPOKFJ8RvTXZNFrMBPydrKdUDUqnWmRepJaea18mYA7r25Tvo8Nj5Si5MtG O0TUOwk0QqUH//n3I07pLxUf2yL2ruicLedvOvv7h4U6WlGdjI1PEC+IOpQ9HHX5RAmVa9kgLmlY 0LiIkpeDIVnFspzVvdXTNYTCXmrsFosAlAE/rFKi+drzoOxGVLYkAToeyibJtRelklDYWi7BERli UaiU9eCCMx/ejPZfEItaiCAcAo69DTjzThEzgDzSlBkbw4rQ3imFu3S7rU3T8ks89Nyy0EZzSv94 +f4TTu/r622fP4cqI3M33mirr34htMHMiYnRoWRTLlzs+MtzD+5z9B5P/z705g3R/Eo4UEbidIrw 0gq6jOVGplLCw0jY295OBa/JwTJtU42r0DO7b3ZklNR0ovcjuYc4w1TQZTIdeGeCzLpCWiSxM/2Y mA7v7yhcpM4WQMk2j35vqp+lb6bEOGGCZoq5PJolcWT29iYKOeEF6vQCkROuh5qbMXbFUvIkLvOl eGjFwI1fPG7o8ee332BrIik7d33LnCMPKr1p5vB4OlFAKpDSOKp1N+mDJCkOy25kdHBG55yxbJpF jfJtdPGy9vU3DI2NX7bJHm/7wqffdNpRogrAQ98jgQoRcrHJoXwwOtKG6wtvvLSUV21Jqet3NV0J VZgwAsi1kMuTyFBMNXUuie4s5MF9lpT00Sg2CdkVJttPmVnjItJUymYKZPdFW4IiSAuQSqEynV3R PXpfhVkI9sL0SQwHAMPlJODJ4J1/FMeJkmSIgpmiuodfwbS8VDc4MMAI0aCh/G3A9Kp/ek1+3NN6 kzYGyieeeGL58uXqx42CxXqhMgtMEoUcG3drPN5lfamivBGXB9P5ifHBMexyoowT5xxKFkoYiGa9 EPSis6sYS9KZjGQ0r1PyUaFSR3XeOzQ8TMUvSXtvzFE6Nh88YrAIc5hLS8WlOJrFplLfSCKcDPWN 9j7xz/CqkWc7h7a65u/hJSPtfzsnP9izsj1WakvNzycldVApSvTNKCY0Y7TiD/QOO5foDDF9jWNs iXa1ljwamEp8QdmOokHbsAMpaheV1LY+xPraI26TUIKeUYXpYvMlYjUBNWUjFawHUyracw0ULu/B fkZfTh8o9TDQnzKzHgZjOYtAJT7B4unPdogze9fMGWJ8q0/KYs/JE1sz1NnZSiaUvn+9WHhmUaxv OPvo80+99NR+l/481FoqbtA92tZEmcqWvy1/Yo8j3vrYpcVtNxjPEaTT1JrHrICyfMpq542MF7Mf Cr2uzi6RSOxwKjWRLQIVP1rykUULCVnkyGiYKRa43RXgm8MjcDotdSZUBNORnydnSvNwgUa2DUkG PTVEoPbMkqkql2fj8IV9lam0Ary+I4cjk/Hll51rcAS3DUygix58IvLCig3DHenf3zs4ml7vFycW 3jZ3BVUQMvFWFP3CuSUcVWJYEMspsBBBi5CeleoqjYEsiauPDeXFSJOJXHrEsdt/5pM7HvDewuhA af4szyZWjldEAwQk6lrWYM3yE8dxgJRk97XYsWJJFxp9ctVraSeLNqCegz7P4Iis6aPLv06dWeYE NlHMMgV5ol3ZEYmFIwuCbgwyn+IyMIVxj4yOkF5JK5Dpdu7ZQxESZHXITVzpjYzrTYUk2ot0mh1I 9l433xg7qDXNuIHvhRdegHHvs88+Pj7CwBhJdVb4mnycZECONSOKA2Niya2f1tn2D8UAgEuaLqYB LxrHjL1UP2lpoeZDbaFgxWfPGL75/i16bwaM0VIuEyrMohK0wzXeMxyd2eZyAIW/0J/LuDSFPOqv wPfD5shbMHPmzMCWNKBbDmc2SKHBI7g04ILSOqPTpdtCfzbaVSk6YR7o+8FNd537o4OeuiM0c3KX Kl5w3+Ijjt/oqZtD280N7Jbhs7BtEeQG7eEgjKtmSdnqp7LDoyTjZvMMBEAE+WzWsVuIEEbgsubV 8lRvXOnTrl78ixu2euSi0IK2AsE6w4SfOBlaQv8eDm3dHuot3brnwXPf994dfnJkvQGK24zJUxSI ARYX0LokOocImSzHjOSsbrEMO7haltBecqpuDVbHy5odHVVBJ3BcqnLwlZJgrrnvkqre1/+0ddyB 8K1r4MMAJ6VJv6cq7OBBIg4G5tLaUesuRwyMN/vPW+mJXO9wv7hzeK7CzNByvjotQ8c3//+tWR8F x7qS1PllYDGKBjWwtORzY/98Pn3PU4P3PjF831OD1909eP+TY7c9mBotdDR3/P8NL/8N41kdHfdq jKuBqkSr7QUWN5q2qmRoLIavq6hK8JUWV0rRD9ZSlSBAiRLKTVWCsNOlqpJKWKA9wVm0sADw3R7J pPHLo7QPChMcb1vizeNDaan3jL67KZP95mU9f/7bgkfPL+ayfclSoSUxq5As4g1nYtklnZg4eYu8 7lGViLcvatNoZ5WqxAOM+ssiwYmqxFQ79M2XdcrmvgLP5s+IGqhKrGQh+tVcjkOPk6qkUKCZD7Gv RVUCNgq58ZGxTNuM9qip+xcpREK5Us+N9zxw8fkfueLCUGKiMC/Z3x7JRcLdjy+7Z7ejdn/0kqat Ngin8T1uSoHWaDGXEBdGe5VVJaYiCTOr5z/9VbSQU+OtvKoSPSZrCh1pbFQleLNNqjKbyKYgqhIO 7F5ViR7ClH6sqkRrdPiyKfhmys4sQIqupioltwXGjg7Jjs+SAR81zlgmTN21RIRyiB1opHKxRb+4 ZvGdj+z2k1NC67eSAm2gmYKbYpNBVRJFKRKNjw/0x1rbQ6OZibHhGz5wxKyXh2KtHYNt0YFSLjkR nsjmJpLxPb7x1bn7v3OkmEms3y0+25V3qxpNfRMcVSW011L31RzGqyoxmpJCvZb2WVWroiqhQ1WV 1JtZj6okh2xsVSXGM1/0/TJTPlXJyIiK/JOqkqkMIUBVMiaRE2IwcDiLeLGxplUlapwkHzchOTqj eqnaWhl34LmDlpAsXCPAOAmu8+NSxjDZjMu3LCgo0VCDMG5J8ixh7qqiBQCIO5Bx86xqrFjeqBS8 uVn4SVfUJOM2JefGxkYmUHkmMPdQcWG8JRoncIN6xyZmKl847Ecr73pi/nO/xY6RyY9kmiZmlFpK 4iFN4cBSviiaQe1R2EHEJPWWgI1xrCKxGW1eL8NqoznAiL3LVJWtPiRWt1c1nPizo+2tMk562QEY UPuEcjS+2r92+LxdEatM0JcAZArjNqsCIEmaTOlRdNyiV63vYkVj1ILLVva1z2wn/Xl4kBCnDnwc Xj378qdvuOH9F50bWq8Dg1ConUT3xfEHl//1PQe/5+k/Fd+8Ef7gZeMkZkgqAlZgVc7LN2ObHGdm GzNuXY3wAtVcgwRVBVhmheFuio57aFhaoi8y6MK5WpLHet4O4dGhrgIAqGbc3kWrL9LG4j1cXWu0 sovYp+BWwCw1iGWQkoqdMhJZaoyUwtFS7KVzfvfy1Tfv/csfhzbupsxarjNJQl0pZC3xNhjTw6GR MUqCQK2Fl5bd9rEj9z3mm6ED3hHKjUnStHmdoq/LZkJ4RpJVBm/aCKrhyVWguFV2qRozpZaaF23Q adAAFZBtWd3eEjbdNtZU0AlTyQTRLX9p3GBmmTIc88mEg2c6dSwR+GARTFaFcYtuvB7jNsmwMIRO nvYAWxm6rkGNGPeVgUb+49eak1gPRXp/TatKGAZQqgpP9yh1PlFLo4k7kc2n8aVSuZYxbNwylkqQ MwiGJyHRCSkMj/VWoneIykG45q/EPZQBUGYU2KduLfqguBR4Lh/wvFrOnaVQK1YhRHniO0w+Bwpg NkkcBF5qCWaSZPySeJpFjYcA/iS4PMcjEk8dlVgA47Ygl0Qe4qwQo9I1bRLE/nB68A7fB4w8Yopr KOlUI6q6vRKfUlv1RNCVfYSWKimoxM3XarxZxPJ25W5eGJgFHJDtPykbyMzwDrxfJFRDIjbqXUwg aEwZ22iSeMTuGaHWCD7KvaGmvhUrQzNaQrNTEjaZ6ogluiI9oY3IrTuREkWAZm9MNRGq7KUzO5W6 bymLsYNVkcp76ZBpBiUrErztmbQmz+ikZjHbEgFVzDIzyKbNZE4lG10X3NNDjA9X1WSmM6sG5Gos TQVGntaZlZ75J2BIlu4UyhETt59NYe4uhGZFQl3UtpHklM2Y0zW1Dgc12hMz0d4c6m5typV6e1Zl Np8VelNbaIe5ofltoY3bQxu2hbacHeqKh2a2NyUwfE5ZwopbpSu73OrNrPJWZXn16IqflFFw6Xbb gFToxNZTVtm8wcyKa0c0XETawu5K3AOxNfjXGErgP1mMhNtUUYKEW1fOPd6ZUgalA1cps3qZsEOv hrjt5emuTqaN94HAX0GcysuBLdfmBoFnAi/wjZ3TqbXRt2JFSMoAiusbAewuV9m3w6WpaeMOcANp yPltr6mhOwBRk7bUe5HWYFZbV4hzieeKFNLREAFQbpitnB5e0xhe28PuGHB/T+M+8ZpNERxklADo 9MbrK7kjLd04yeXHB/XVg/FRNydmd0in3dKdth27djA0Ova0JpqtIR03Ii25Sji2UHNStyPdM1Uq 5IMKMvVGrEdvfuWvqODKlVzqI4i46pFcDD0J5Z3EJVUEH1E2VHTcnOLwy1ZZQDJPmp28Ab4VWlXv qNTpbQxIXuAFWpO6X45XxqtPnjWDEy9PRJ/sUPrEy0dufnjBc1dzgCUXEpk0UhPxTCwsygWpkmTc QcvugMJ8JJaHZAx4nWcLkU4KK07uuKr+s/AoJNxRT7tqxPraKz5prx8aX9qtd7B6frJP2ZnSk7JK lFNw5XHjBlB0I6gKVGsm+gSkvfo+GCClOYNLXSnTEslFJ2Ak7ZS9y0f/dfH1r/zqon1/+9vQvA5x GJyJz1p+4uFlf93t829/4ff5BV2JPKqTiXg2Uko2ZZPlxHI6arBhibCaAsGeF3hFHX+raUCIGROf V8dt6mZJ7mxzydukiFJdBNOtjwhrziw3QZlKpj6AfRo8GihhlCeIeP7wRM74tbWnQ5Fc8tWLr3v6 mhve/6sfhbaaVcBXG62I+DMXY5TuLJTCw5nQUDbUNS+0cjjUk79iv/d++I+Xte++w9DwqnBXCtVO KwkG0KlEQqMxKqiGu/JNUV1g5lLgFQAh6ql0Uo0FtRsxLsVwBWnlhkp4/EW25S9rtrEHjjUP6Cqo fp13ZvmZvPDir84rOI1I/SAylJV9ssV6IWkApnSCGOqyXpTGeNz7Or4Cv86Lb3UErb81rioBRLUu KsUr+1MOrsRnz3Q6YdWXNvA+WK+l3I+abUASvpMrhuMfKqzJ5vLRnDS1T0VWYwAstMyhfvZeNaHl 5GkAkcQL8k9COSMx8jAw5OYEJEK6HJPTqsQmJgYrA6Q0qqggyi9lSzNDkFQ1UpQAM9uUqxoevVMP sdXtles3wqfnN8VVg+Hbn2r2adRk5UpsWoxN0rcZKhDPaPnc6JJ3j+MCEZYMeeiX4PItzV3ROLay 5af/dMUpZ6/6xk9fOfPXj/7k0oWXXjMRGqNkBoolKXUG6lBSCbvzY09pQFdX4NC8ROhvbGIxtMic /jMYIMrGEKH5V+9SGHxEWK+xhbZ6LL55UdrWZlIADiUhGZ9YfBSFgxWls6jyQs3hiXi4n+IQKOqg WKaHgaA9aGvp+/vTL/zswuVn/Cp3/mXtsRYpV4bSETP74Gi0FEGF11yKpCYokBbtLApte+FRSLyI DSQwu7rLlF+LzmUgGlXQsMybxYNKJI1nVmYN8jBJtUS1VZkvfcqwCT9Z1uu2+kUKbfVM6RACOXW9 BmtI4kaUIGtgb28vWQN9oLi7G8P3qf7g6Ead7xkibDHqkCQBx2Qw6OLFjKqHy8XblzHSLbZsuzH4 R/3FM0b//PdZL14Tws0kTfB7Id4S7EZNJ+lXexLrzaiuwFs9wZpgAGtPIHEwBRCiS0vEImy5jhgY GR5OJElWGuzFjB93Hi/mTifHsuLysfCshLcgZPrcW1+65IqeVxa/qaW7c8ngws7YK6mJTZraNqLd LaeFtpkdiAE9dbmECEyLCEf6+ptTKWwbgQDgLyQ1iE3C+sAL0mKyXBDbOEZhyY9/8/LVf9njrG/n t5mTbYtzlOlEiPZc/zr2/x676o87xLrWyzUtn9u21dknx9+3PVJ2euGi5EYbuPCdNwKx+N8QB8eC dcEAuIJcdQtpfI2PpakmEe92IsLGq9v7ItYLi8sXToFxlfsuUPlghp9oBRwVCoLPyEGjDvhd99Ka p5vIREhcnp2uUmyy4FfAAxRPKRe8C+q5rTmZcksEjC+KozKadwJqddZjC0sy0jyrbxiuzR2J62xw hPbAj2gc6UyZ7KrBV1Q8B5y2dErJNJdLwwd0K+a24DeXW0hlMrfGUnKyXI03+IG8lCibcjUf8/5t H/vNe/run7v4+ubS3W8auP2DS+/caskNkcUXFrbqCu4RM1clUjy4MaGXrgktsPCJnSq4T2PnIEuf S0vaNCNEOk1DiWllcut1m53XsfjVl+/Y6/OLZ+zbH3tv56X3+lpGFy0nb+v2K2+fNXjLds9eG3nf djSQZAbtHU6ENR3E0iExxi4YQP/Y3pyU3AkOl0yWmz4eNU2IfMVuFxzDMdMIa5D0k75eTS5aJ/jr geOEKbexNGoF40YrhBMMjVRVYvVfhhWUvcq8P1V/LgeZN25UUavhF6uJIQL6xDUvn5dqsw4ty4AG tVS9XiUevur9ZrBEX+eTUUlAKtrAgqRpqHTbAGIWTSFP7ipJVR04LkfEAoDJ84yGMahTeWUlFUbQ LAg+K4l4AkElvY8aroN6FXRJodWpl+VMLH5L0IIl8iOatEGBAFjadQGg7sxOfZg+1clPAWgMBFlE 1aXMBQBLKkGNTZ1GUuBWui1rnQ0w3Nx4550OPu+c3c/8381+dkZ2wwX3/ey8RZ/89sJ9j8t8/aLQ I0toEE91JsdUqjISnk6oMcC4XF6OEESvotcu550P4gK6xJXtBc+s2paCLmlDMlqTPiyorfyey+dc mgm5Uv3WVHey7YU3yAjMElndS1QlG220EeeOclf1O+JkpA5SGtxhPa85aHutIuoEw0EAM4J6SfNg X1/f4sWLbbFgqkGSnF+ShogimlgTccSReti13g7mpUCyyZjB4UCsfjyHsbHepo8PZlYS/uEWp4cJ kISrkmffFXdgLSMNYfM/OXP5K8VOgoImigUoOnPzn+Slos9JDuG3rNIiXJhAU2YgrRoT2UPzpV// +nzcuo/67DGhjmQm09fX3TwWC5GspGUikqRGHY4TJvpG5xvBDWOqmAhw+UUX3BzzpteZUlIWkZy6 u4pYs88bk9fk2NUeOFlc2IxScy5KcrhK8d96BAUGCmSBtqVyq4oF69gVcpPeHjlGQp/qXYJblP2y y5K6QVLGSBH1uq/HS7tAtm5DCGIRwIphrNY1SMHYOEw2lTqimYeuykTI+H0zO6UmtWT7J+wE6zIz W0Pq9pEZuMpQLkPc8MUGTleGjQsh6ZrVDOym9ri4cjMMMut7D591Z9aMi2402b9elkq9qPbO7ARy AvVwiuHmiVCcnIDkG0kXw/EZoVGyw0dyd93Z9+xT4ZcXIRj0LVnSXAr1Dg3m57RvsPMOWx79pdDc GaHOGKUWMLBAipoMx4RW1Z5YS2ai6DdTUKJE85Sy0VMehP4KRDlgjRAFgJRCbsDSyjOrBd/rcAyL Okn/Q0JHKpZ4ZVRfsWDiSKIxaj4wXwDQ0kLyCQTNqTNVQbXxNoBxS7CR0VyLhUYMp96C3WI8k5sy sQCJvQnfygqwEMbo2KhqzatTCTXm5FZV4sq4ZcUWCrfffjvptt/2trftsssuf/zjHwcGBoip+drX vgbrt56VlCujttmXv/zlO+64A00cmV01EuTpp5+Gce+7775ix7fOFqSMSWewzZEyJvBAAxrI9dWi KbaD9PqUqMCKEk9J8ZFye+8se1Z6bmQUX4bm9pa6RaNlriRxFAnG0K9Re9RHMX5ln1mT6YGh5tYW 8en2DcxY2DNf+lHohvuTr96AH3deAuyKnc0dWvJFnEl8BMlgy4eHUJoqpR1t3vS2fmAq67hgfA1j WgJ4cn1XnRyZ2bE0Y4+1klmlwgPqbKFsdJlsLjUVA1OGb+A080N+xFFioNg+G82seSU0QABO+4zO YAkEV43+QRArvre0NsuoxgXCkODSObLFshk0lGxkZvNjaWx3QBswsyb5J7WNUl0dtZOglmfKUByR k/2D4rnNFEyCOhVcbU+yrUIhO5Y2FXAmG9Se2aZwdlAQW06BUn9m+aUwyrjCsRap6qKCjk6xSXVl 8tixX7Btw9Se6SPmJLRVZ2jJ0MQlt0xQNSnWVMym4/NnR770wRBJ1aQiiOAKlp0ZGkl1thuRqw6f MUsGGkDJLvVPSBlkVlADrgRiSbvYAmIbEwEgUwooV6D6g2Cgnqyn3izEdg0MUdwKu3ejmTULNi8B ODnGVQayatmW32UGMdY/mGxvM6tbidC/Yss3DX9ja060tto2svwzGc1V4mIn8CJtio67MY+3vyI7 L1y4EOviX//6V5jyPffcA+PefvvtvdZC+iX9CrpzCuVQtOxf//qXRs0AIh86Ozv5bAzcRsI2BmI+ Gbc5U7W04T+xzhupu/KgebrOZXz+tbZppb23c89TFCKjpa602v+0E71qmbP9IFRSEIt13gKgYFRs 4sl8JDlAfK28Nx5LtIk0QsQa3mQGO7bxFOBldyd3Wbnbylt9Buva+LFDqwUPISAaTlIbV1OfNbkP pzi2TBl+ZWZV4BfENp5Z8zBhiBQnLHuNNZpVwT8+nFKxSLut17lQlTog1G9THpfxUqj05kdmFTAa A6lMocY/Dzwys8QTmXh3D6hTn7LvpcCZyePofWHtmTX8b3Js9WeWNibKg9JJekQpLzyZGXgu3TBD RAapKDq7LTQzwck0tEl35NRD49/9ePNJBye/9znh2lyIwjqz/DH10iq03WjJiAuWoZTyKmg4s8bN i8jhID5QJr6GM2vaWOHGSPBTKNZDGWXyMCMiXbGErVVoptZMVShKomyM61plZn3EoN1Kawmwik0W UBRiM6FD8qNrrvIaHNpV4lbmC6emgvtzzz2HOzblbB5++OF58+Ztsskmxx9/vHomMh50L4cffjgi OXlcSeJ6xhlnwMp5lvuYYsnHjeSOYTQVa5YjojliSD5usxTrbSH8BAnSD8fq5iR1tlokllf3Oi7d 7SY/h6UoFmHBuPKYQEfmyRuTqojjPjADMN1qBLMeGtSapG7j5SUq6gWcqEWzp3d43NSb17dLXaRy fUTzOwZUtHXewajzabm7aFNyRfGB8y7peeSxj5z/C8LSSsMrw+t1DaYHgam1pSOzqq+pvRWVgxUm Gb46UwqmjLfv5LHPiE729M0XSedtCuTZNzL+KYcND55pBmY0Eq+8uj0PKsBgz3Yl3Qpkpj8v2itf RcFjXD8FVBPN3TgJDGOhJcYP2mL9x/hOSeXy6GpMbjg/IepCXXj61ztT/CQKOjLtmYQqkKjKCupR zhgVgXZmdaK9uJoys+I3bxpXJhq6sqjgg3LGejIyv7JeKJ3V2tFBH9mxMVMFcUoQgG9mAd5DV6qa qwBbClNES+RmM0Fy2zAH71h8M5XP5fSNOvYiZ/elBcoHAABEUElEQVSmCdGkcXY3+jQpoKHaYvrB m95k4EYXZP5WSiTqr7wnGc4lo0anIxOrS7KBfpV5Z5GqWwteCdA2kfNlQpwclAHfSEOifDCXzqzo QTxiLDdBDoYQju+8l5mdPWs2OjZFCLOmtgR76eN2ZoVJggdbT1MUg4Z8K5BABEIZFX2sb5qEuqfK 1BpPr6B60a4A6Lyo47nSGzB73h4eHR0R90wyR6JCmc61OqoSqBBVNcz60Ucf3WGHHY455hjeiGR9 4IEHUtPdli576KGHfvKTn3z729+mzhm8mxrwsAZKKJCrhFk85JBDxF6Cggz5wuAin5VsBpx8656Q 7NwUChlOqe1tUt01L2XlVNWrioXySVB7aQrnMhmJcW9mrxN5CkY+eVKrJBMAEjj76OCQ0FZ7m6JY J1uYuF0VLFEmyRQcwDKGd5esmAq4cl8YlWhayzdhPJyGRkabqfiHamxqriLqUcZW5Z/81W9bfvab zbfZllDrJ2ePzzj+Exu8fccCuoUwCajy8fZWLzaUaGSFkSA5nUU202g3M3ZgM8JF5QETrCMkK1VC oBgTIe0di+yRHlqBy5NSVfJU47VmkDXlSGtwNbkeJoooCjh7ysHXg/bKLBhpHCHO/JQbywAqsDWY Wd1WSfdMavzWzg6WgmT/MHPpndDKZ1hOE0dacqWaepdSIlZmrbJxAbpWK2fIiJp9Pb3tHR1Sh9rM LC/SxCDe9iIWQYSZHOc+yffv0XWIBoMMjpNkJqwa0mBcybY2k/NG1u0kcozh1GKPrvp7+9AWtpjy CKow9Lb3sgMpVpQtiEqhUqbazKyUTi5PtBEIlBnBDgVUk8vbR9VeJkA+dKiFYYMuWWtCliWdDLJR 0rM4whtTIz/kJvK5bL6lOcUI5VBlCK78T0SIMHnMyQthOFgxn86JWqkBx6mQDQsWHCVEWWRCtzwz 6125RkgpwQoQynTEKqSUR1fhACI/AV4o3N/XN7O7W1yxzNIAq2JdL6st5Kbg2ZyjsiOSs0iqlU41 hMhMGUOSuShoGSVXLKVaFADfjuhnCEYjT5oC8dbXZTh1By0vWF2GWN0pncqaNTKAmq5E6Yq1g2Cf SrnnBrj0/jRtxs3D7HinnXYaRSOpJPmmN70JbTXqbNTWaL0p+u5l3BdeeOEVV1xx2WWXPfDAA3zm J7bff//730i473znO30gUhlA4kscfF1hSLnh0USnk69rZniEyaByeSBGUNixalpndga2FHfjTK6l y8nherinD5Wlniurr6GLb3/1nr/19g0sGulLz07tefSnt3rP7oEA0CA3ONyMlt/hkEU6Kton2hwK Hkrt4/Em8roEXdgGx0cz8RlOGEgPouVvFU4adEHH4DbplgxajAdtTt0yBbAMiqoEvR/LwQhwsmgD W6KKHR0YbJ/llJF8PJ1BGnTKx400M5qNdzrlZB/tH2gmWYpDgXAK1HKmEMtY0DVcGINdd8SCMcAy zGBo6ZJjROCFhhexIuqQFh82Lapzh245zw71DWARIVgmEABogD5dAhSxc+RzhdYZTuPKDI5gFfNt wzWBgcUja1O12ftrMZtLI1d5yqEEDkQbWMbt6g7IHgLj3myzzVCVvP3tbyfJH/z6uuuu48zy1a9+ VbNHciECkBuTQpR83m677Whp3bzQk3BVw6fh3I6X1VsFtm9wiPM969stg3p2hVUKiUw5yHo6LpY6 Pvi2N59z0h7Xn33ofVce+dsLtnrXO4LeK7/zbhPe7giDikzB1ziWQcIEghuaKXardijQyvsde/XL LI1gcRwWIqaju7PbwLUVyMeXw/EJtFA+zUyDB90p1vHt4CmPEcwtQZDovwpO8RR68nOjLKR8o0x3 uxwZgaqIpoMuJyJ0alQZCMcBRwyYRVDVd+27bmgyrVx13HpG02xY0KLm9jSLU05AXg2y8kHVD1gV D3cee+wxVNv77befJqW0RnkOU4CRbEUwbHz2os8iUqTIZebY1+gKh4f7B3EqQVmhp3+fA5wOh4EA ydigpFik/IqypJp8XFCvXiUUu2vHQFyXJyt75Qw1MjCI8qFmRTRhKEYjY86+JQpDDeTTM2fMke+S TrNWTeTK6Wu0f6itq6PBBmbWlDlQj+FVUgqUImUGs+LbJFXDjd6gwSUTP5ROdHc2KCxr9FeCrtG+ ARwqJG4wiH1zRuagmhJd8GQikZpgwF+G+waYAnRcNUE1eBJlF5bsAaQtJNNUQg/d9dqbA/UYZyNR gjVcvsLdiqVhYmI7O0Sp0pgGm5r6V65KJFOpNnEv00VR74nxfB4Y2rtnNkKsziyeEnhMEZIaVFhH tEh4X3CcB1cGWNIwSFpdQ6NljYSqpKiylhuLZ5tSlDOdCmVZFaBaE4MdXNxw2cL9w0XezJMEnPcL DTRaMqrMpExr24zOOgtQ+L+ChiZnoK+/Y0YXq0wXpjJyL24V3eAK94/mNjTsU9SDNWYhHEJhiF9q S2ebMofGkzvU298KBowGtd6lfjQ4C+GugyfYJF5xNRkey00UyFo6Xfvk6qhKXMZTcwxgASXJU089 hRPMXnvtRT8YjtLDI6ITLhv9NJa//qohl82EFLGlkYgwkn+yrtQj7rY4o5J6QRJfGFdf3oMXkXBl BVCoRPGYSqaQNs3LiYEp67hVze0dS3mz0fQ3sLgGMpcxU0oyY2NvQdMqCbinTi/ZW6nm22SibybQ mVLgjvT2pNIkyI2VBt9BDW0YsKwpcUJvpoYCScY1mAKLWIONizHgZ62TZTw7kBAbxdmBLh24WLpR yU018vgmVLrEOGmymetcmJUz2YqvuAibDUm8dNjUpxhmTSCHb5qNr6scuoAEU3KD9U2DLMmoixOJ GGaGsl3RByG6S7oTL6ZEM1Qn2cANlMavXQxu9rwC1GpqsxIGiKoOcvP2L3Y7eB8zm8vjr1E9s97R yX6Ayxe+uiTaNQlpsawCnA9g2bkNBmifjMTqHadEMYrAJF6Oko1L9LDGsaXBRqMzS7eiKGBe0PKQ jhubJF7MxtWelFBAQ80OylEwsEi2FJe0Ok0YJsX72CwBfsHeLWSEK7QsCwQ1dkE5eCEXWWjFsdAz MMUtsKqEIRISWUDq0yGgprE0RsL4ahgCkRdZ7imgEqFkvN3x0MAjXuoCplJoOM1qEzx4wzC4I/VO K7ZruoqhNq0fHqCikinlLCtcrY5eDgAivKHN9C+JhmS/U6dzP/fWx9WKq80SEcl2V+Y+ofDwyAhq d1zEqDrdeIfw/bo6jHtaL/A1hnSef/75RYsWIXH7fnqDcpVkVw5EyVVCdt2gyz1XCVZyoFVHhcBr cHCQsKbGUonhViGpHIrIj6dn0AU1ZJf1Nc+b4SLsuOcqYVzwa/wfgt4vRj/QNWPGjMCWNOCAZXMi N26fxY97LN3hpjjGZKLp9hv3Ca4wpyPvcuwJhBZQWa5O2VomJvCBoWB0YJ80GOrpp764S64S8D86 MoKa0anb1ylXifddqDRJltLZEUzbcKSBFT1dc+cESaXS/Vh6DM2SSxIYuHLWrZinxmC3d7Trdtj4 6uvvl6wmDoVmxI87n3NMmIObBpMVSITApkWQfYtLOAn1W9zSIXgHOG0ddxB+An5nC2IAykrWzGWE uGmprV5/uBocjfVlulOrb6jL62kmIVkuTafTRsSbKkmwXgdviNK2ykuvAfiBWJ3ybJCWZjp4mpwy x6dcFna5q9cbTu3WnCicNNc0dlQxA2ntkOCaSHFegkasdgVVXuXYcznwKHjGTDJmx07LTsPBnWqL WpP7Gldx5Atf+AIiZGDJR1cQ67fDjIkNc8stt9RDhF58VgdMVZ0LB6l/qW4d4T2wpZx9CjgvibeN HIA04bOseDM78rd8ijHHXinvhKNlg26VpNSRUUP5G4NKY0QYPawFtkSCkLOkCe4yOgaFdfKbMUoW ObHyVyqbRZs4sHvb1HyFGh4C0aWgqtHCTkrNDpUR8JM68NrLhw3vzHo1KnZwvs5FeSF+wSF86c3a CcCtTaumfrK+y7Iq7jOzWnslcGYdcUWfatGpRwNqtCiP1OBLE2fLmBoSjda4QjINJC06t07EgaSl JcYDKZY2NvK53rQK99HfJFlFERuD4UiTk1Vz2kyI/6Rfdj2A6UoLrShpKTD1ZhYUadVN0dvVWYl6 X7RVJgmfVevVAwDtBz+hpZSI3HIqoCkD8n4BNi1UWw1kdf/VpKUrTn3hHSU2y1Zpz7NkWnU1Tr5G xg30+HQjcb/jHe9gn2B4HHgVaCFr43fZYAw6l0oBlsLqgQSXa8oVIjloC2ubKL9Ir4EdAMKbMBpU IQpyUJHMxFx2aut2aDJkaYSOxqoEpnxTIKEekZGDAltpVtaFGSzgJKTZN9TZFt0bTstULDNp2VDq hScSEfSSDXbssrdypTxFY8QqSllgbN5AoiOthwq60m1Gq1Ip2N7+7aqzM+vFFVOjASAq2DAEw7RF Hapf8QEvEpBWn9p0l9XtkAf57IO2HCVgihwys4E1oBmLlsLSravxQjJcS+YUJCgZ2PZCdRLSIn/L o6PGg0m3L07ExnrGRopa2Ts67U3nS1o2PNFbQccbLdVgYSqcNGCAtkxBvfa8HWZEz5orVRnQ1NGV MMwoBtT0Z3OVlNXlphi3HZ1uq7q6tavGq4a3S5RKpVSj+kFYaOlB0gpR4UFyY0jpV/RaKk7VvHQP UDZHgwYkrROHvYLwJtTorDINibRSsowOq5VnaCrtKYWrgaT6aKWTpRDS3juzfIX7qUzTALCa41rT Om6QSDwOOu6DDz7YB9AbpOPO9QxEcLxvDdZxoy8DlS6pkDWLrmNCcBcdt6LCPR02jceWrEqu3+1y BnfXcWPEY5m5ZCR/o3TcKPxGxzrddNwc3ZiCwL2TZYM6HhnWRcGqwb2+pMk1Vw5LEYJxtXOs6k20 pPjXgL3qTyAWGBxJCwBgWy6+yejuoW0X8wkMDtp2oQEQ27981cz15gQOSsh1OonOWTIu5hM4OOPS so2BMEAtDMoFV+j480SBOTiS81JAZbJc5OWaqxts6zYZCL+vwZrWcTPZYNnR9lJvMHTiPk4MFy7c jQ41/N2xZ/eWKhW6dBsokk92UiJ1GSVvnfRj7gcxSafgDcqvDzQjcpcRHIfP2zgIUS/ZBVfSuKp0 XM0HpwWqO668cmggwMmk1IoNbEYDunVsqb254FYXnQt30w7dW5LaJtDF02XU3jYA4L64Gh+kvN26 9yluR24RMYqrBvK+F4CaRw09hUwXRd72rgE4r+UdPKtnFj1frPblsr/Zzs3Bygk17kicFgA6apfB 6unepSUcGweQ193oCgASaO4GrROc023khKfJTl1Add84pwWsy6tth/m85IFx7P91L6WtqhJfEg9H YBo0E8QaP/3X3pWPwbl3OK3t03HKHJvputZs1S4AA2rNmXV8vN4r1pCOG/J95plnOLyTElYVQ5ag deMKFDeszki30EZiFwjFX3YoE0/ECklyu5hEqTETDWSEVVaSdapUDaN2yF+ovHqLtm1UaVXdoKaG SzWwNafHC7xuaTTW/Hw8gDpQclSJucSofXFab4qi0JUtmszC2UKoPSnFfSq7Ur2NRxFr1XCWAqrb ezHQQPZUPazm3LC9Vbe3kohiQI2utj1OxOIUbL4zRKPelURjglhaarHg+sKI6jotYhtLyqpBVjUr L/JBoiAptBZXvnXiIzMlgJo0oA+SudGes/DexcPP5JwTdS0XXJwqGHa5W9jUyMG4UIB4cVVvZhWx PuqyVOodgndm6x1AFUs8pd1OzpTX4RKyJG0L/0x0Ff7oogvHkGhmUm6J63c5vYz2oMBbxDaeKX5V FbZdXI2Py3ZmrXHIN3EWdfWW4ZQ1aBaaZIvFgqXu+ZUzDaptTDKyV01NE6/56ewsKHfyoo5HlFR0 45R4gkoDfoIT8jXQquEblC7nydJl1T+/7nfsMFQOUrwr4eq79GvjSxsrvQa2RP9BosbmYhOZIiWZ jLxsMrmm93ELgCw8Y9CoeVlQHQHQiXFsbNU1JuyGB8ugKtjiBmM+YN8RvY5JoGYROC1oq+FRzm6v BgDbzdXXpuYjiq4asJmSrHrJB5MsVNgBLFtzy9efWsWnSlu2Yb23S/8e0lI9QANcefus10zb6MxW tym7dU6OTsQRSTcogScmQsROW6WNLmYdl7T0XPUw4UVsY+ryTiuf6zVW2lN0NehQRmzSmWnWMGlZ wUEZrR6UaD8WVPu1/twaenBY3dqnncoyhqf266UNbdkYUZrM2RChaWm+6j9J5wYLNqmW7UtoUxaz ynVazO7luSzf1ynwzWyZ+J1P5DW58RqSuBknLiw9PT0f+MAHfHC8QcbJ0uAYZS2aHLLbsHmCSpfg i9exWLAXCZpY1cWGJk/1j4ZmECkTfExzRyzjYit1AQDxYRrFgkdGMPcFnqUYE/HuxEanZnS6SAyO 5V/hicg1LBuXcWlLF6dYEOVesTo3MkZRG4TTwHHRLYh1IUK6AgBHxNInXMbFLIEaExhczLOIFsM9 /Y5ptt4IxEKEQCvxqA6IdaQWsFrIkCExn3DMdJZOgysrHDSYX9UP+0iLSB+yyNSoshJEKMymStxr iHGzimDcK1asIB+3OjjbA5oqgBqvGRVMeAQsKG0FoIxl0DNIxFqslcYiseKoJX6oJqeiONt58mGq O6CXuKs1aAqtdTXzolcbe+FRaOGbepjyzYXKa/YmD2rtN120fBWhW5PEqmRRTi6hJ89Srm+4eXYH mh3bg/eM5n0XuKK3asT6DuMAE+gyZbsFDzT29ekbu8UeiGVp+Ri3PU+KFkgm1QwrV8B1DhcgGTtZ YRte8AIvYn2UYOmKbtUdsIF5Sg/U9GB9+X0z65s+PSxaIvSDqZJ4xQTB5/5VvUTek6JSKYRf1NGz +oIAQCx5q32zU92SBkpa1TuiHbt9St0BXRi3jVHQZ2tQNaoQs2pkukYzibaULZxm3DorSpPKu3Ug XsQ2XrNgwCK25pqydEVLxsV+3KBDi8aay9C/BpkUfAEzWVRAUbJpCmmaXAKeKHlvahrei1cJk2VP KvXWIH2IWCb8jfBdQjAk2w30jU/JRC6DOiAclzoz7teaZtzgmlwl7H577LEHnzUiwAuunmXqDQC8 8JRtwNdGchzdZArFsVy8WVIUwLLH4dUm3zc6bi7wSHiO17qiNGGxr0dXLzAaR1ATPJ6y82eJ3jc6 HzvwAc/QRLlmeLFsaegQJRagrOPmXBqRHBn6z6jSWhOc3WyfPv2awqk3dSDVrM2OtBr4QBqqfp0X V76Zojcf39QqDKq7lyM3ekUUpgQ+VPJTFFspOlEXisZv5zHfTPlWVPVMeenK99ZqMvO93Q8lrs2k 2qgAD9q1uohkzEEdgdu7JrGpj2IfrmrOrA1pqZ5Z79inO7Mql1jQalA1iUFYNcLOZAT8J55Ilk2b XCXesQXOlA8NXituzTXlmynfzPrWVOOZ8s2s2F2yBVOoAjMOtBjBr1sqSWhxNyNOeZPY2J1e92Ou BuudYbIOi5F4U2gCLRvWKgIIl726ZEZLkoTr4c7uafnnrA7j5hl7OmBvZPB6CAWheirXCwxynwbq sqO0q6qS3t5eKp/5Jsz9RD+tU2q+ZxA/7ohI3AHXtHxdEYtcvGJ5JbsUvuHVEnc1NOCKNcMGHgSp /J5b3hefM8MlqZi7HzdTAG5dAJiWqgR3YwjG5Tw7wSl1LBPv7nTBgPvhFwBgLi6qkmm5G7urSoZ7 SZydbHbINc8iAgYXN2olLakp4+BoSJ+6bAMR664qYVGP9LqqSt4IxCLDQrGOpOVOLVDgRCYf7+4I xNW0VjfHPmQoaupO6bZA7s5srLWds8OEyVfleFnG7eoOyAPkVTnzzDMpYXPiiSe+8MIL1L459thj v/vd76JwsZQBMZFM6lOf+tTLL7/8gx/84Ic//KHN/spPLjrEBgNocB6pfsqFtdmnGpymvT1PCwAe dG/vwt8FEqRvEcydUjrwdncApgWtI5G5NxM4nVw3y126jEuH7ziz0wPVubXYkd0au4xouqT4RvQ5 SSevzQ25GivTghYh13XJOC9DA4ArFbq/vfbKorRCU9M9V16y6olHKZvoXmbA4s2VcesDZBr5xS9+ AQv+wx/+cPfdd8+aNYuKNhQO9jrxIJTddNNNFDOjDSVyVMuJ1APXrinTwfRdZCLe7mhoUlBjyZaI Q/kbWjpmsKMlQ3ARXhQAdNaOXGMa3YZD0VSKOAEXbgAAjsYuBsXUNFZB6huZymlhwEXclm6TibiD VKgwONrlGA7DdwRgWkTojgGipVxSAypiHVeBkpbLuBQDjtBChI7UYkT4lKMf97QQ6wgAYwdXjovL kVoMESY5nbmsLNpw7Hbk3YDaUk3bmD5a2/58ww0Xn3fu/Zecn+1Z5bioLXjTME4iO1O1/fvf/z5z fNRRR1EK533vex9H7LPOOuu+++7T0mX8xGfE8AULFuhXCphRbRInbmRwji0weg1Ehr8zAWB/5cqV cA3w69UTsft5v6o6T7MZcFACa5o/iEutOlw8oqqJ4eGhJHmVMwWMtm1dnWJG6GwfHh3J5HLdc2bx N4s5dHyCfL4av85pTu14wKCZbujHp3HTl3JGpjEffETj0zaqCoxhcvKlMWD7eKLvcX2pJk7hMyET pN6XAOR0pjkW62zvoFAT5SYWrD+fg5X01tqMFwgI11hetf+oawoI5+KzWMb6+7nD5uotc1FNl7Sn K6AlrpXPajr2NaMfdZTkVyn0bC51Pa4p+ygmKWvX3d3NoFBZ8CE9lh4cHsQ5CtVBLpvpaOugWjvl Jro6Ook2nsgX2tra0/lsz9jwrDmzEVQ54amOHnQxTejZAA98vvrqq9DPzJkzNZjYp2FXAxePSJ5S Y8ZUZwk+09IXcacu4dyESHTeG+sfaAyieAVvp6VmGtIkNmoYLObymgxa8qOGwyuWL2eO6HZVz6qO 9g6KRhJPMEQVgpYWcLLxxhszRgBjUNAVQHqpjinw0ZXOAn9BBS8lOtwX2eGjKxrTkolgZvlJqcI7 s3oo0SBAflUXFGZKC1qpIpjPDJYXLX916Zu22HLZsmWMCC8DkMYsqCsh4wWTY/kcn0kGQFea7wH8 0CH96Bbi06H79MJ0BcHwLjtZ3lWjdiDeSId0q14lNFDq1fuTTM0EyNAPN/Fk468mWNZlorFmPAjy N9xwQz4vX7ZsRqK1lC+AcerMkfU+0doymssyR7EkPvgIxxHJ0xIqMQqGxnzxE72pgZQZ9ALAHQ3P UY2xLKhINBFFVUKl5lKkRMKkIhjPZ8auv+aahS++uO322xxx/Imb7b4HxTQCtw1eOm2vEhC9ZMkS IP7zn/8M5aEtOfTQQ5mVH/3oR3/6059szUmqCV9yySVHH300RSYpHHzeeefBsnnZSy+9xLMUM7PZ 3ehQjUWa2Mg3kb6jky5RWorbv/H0Ur7PpRs13YIjjWJINSdWPP8KdVKouMhdcaSME9whie3hNq1t bVjDSG8mvDGdlvTKM2bQuSbiURncB4zNWaOsSi8vofjWA1+VF6tFxbdglJq9j2tZTnX5JNMNoQDJ RDNR+/KWCXz/TclR3CQy2RWvLJq92YYcXgh2VA829Tfis3qn6LsUq4qfQGpQ7wuGrIzMJ82pnYee dZWCLjiRXYS6HnyvUB2Fjp3H7Sriwf6BfuQ1Ik4y6YxkyiZBPt5do2ncATvndAM4jkBwMfoHe6wQ HYjq1hkpd/jMBOlu5Hs1jQFS51F9D6AF/vKVm/ykxKPQ0ljZgQ1fBlRvA9+gtL3uyip5ACHcAYQo Nba1tpH8e2R4hLGT1Aaza8+KlVQKXn/+fLqiwareXiZXE62wInRQMEp+opo2Y9H8aw3oSo3YOl86 BC+QXrpSaCFC3YpUTvKiS2Uj5d1KqDTTJclfWqrfp2SOJqNTS4oMTHik85nJ6Fm+YpMtNhc7FtwT d8NYPJFK5MdBuMgbdMhAeLViXoGsSSQ+DPNeof9aafOUzHSDtJxXKZ+bGuLknVnGS0tdHdqncg/+ wruYPt2cmDs+Q5bpoeHs4Ai5Stpmz6RxJpdta29PtaZGKHZMJfHWFvJnK7Wo6UjpRL3IFTDfRCj+ VSZrSbUYu22JhHF4HbH4Y5Gm3pWrrr/wl3O7Z+/3/n06tt2+efZccsgFLtXVYdxg5+STT0aUxsxI VUnkBfg1ZMfIv/Od71jGTYHg888//7e//e0f//jHG2+8kc/KbZG7IdZ3vetdPgEQzHJBzT5e6SNK Jb7ly5erLG+vakIXWok0DS9cnuxsi3a0lp1FzHrQPvURJSnmmy2Uv9Co7cq3Z+iDXEwzoM6ePbvx HqONEQyRdmt6YvlgVqOrLlqByryvDGRlnHoTd7LBl5Z2bLw+Nc5VHWcXhm8ZAwCyBuNiT6oejheB tET00CNtNc59LWGpiEWbbrqpj1KrCU7Rpada/VXAMGVxFB4ayAfZ1sLpgeHcwPCMTRdIomdvUjpF iLoxmIsPQGuTTNUbGi2VLfIXebPezNqewRUzVU2EvnHRnnUIBiBCnSwLmH71QstJoX/ZSkTsjpld kn2hcjiwT+mzSkt06zt0WkK1MFgOiPzEtPrCLH3tFb2cD1QHEkgDyObwIN/OocMpz5SBg8mivNSq V5fN22gDQ5CVtVR2tZ2yxOAyIJZumYJqvwsfscEWoC47WQ1mVm3pANNgzXpxxTL0nrR806RfkZiG lq+iWvHcrTeTGFFTo87Opo8Ilbbps8E2r7MGBsQ62tICMRgzTmWjJQdoJPrCzTfHE83r77a7paXq deS7szqMG3BRZ6vIicaDLv7617+yLCFiigirCMZNKABhfM8993zuuecgcWLcdRtH381C2nbbbb0n JgXLSxmNQad/SwE8pTseHcJHGLzKFBJOQi7moZFoczxSqQwE4pAOJByAw1AzDmeSQMC7hBpTtoWz ejnVA9gLauB8+DCgsqFKmvTDF8DjK2PP9A9RtVpiuozxgPuMnWZg2CqOpgutO/51GVcvwpoD9HUr AzHBgSoR6xlLD/tU8qR+fFyKeZZLmyqLlBVlTiF2iqdFLbp63+iZ1YMI71JJsKzv4jNrYcXKRDLZ 2t7GkoX8wIA6b/BBs3qp/KjYs9whkFrcSWtaM+vFFQ/qcU2pS9WSeqKV/PYI8gkR+ZU48XRU4uSO jms1Ftd0Z9ZlWhVCL7nqoLhUtQj7UrmYCcqNjhWQuGeabZ55NMwEgRkh3/IZy7umhdh6oHJehpmL V4mzpdcy7ukVUnjTm9601VZbYaJU1R5fN9lkEzZJOx5A5CSCMA6BIhRssMEGKppxH3EGBVYgUTZu YFEA4pBSn332WaR+pSpAQkvzyCOPzJs7N4naIdEMsy73hlfi4NDV11zDfjM8NvLHm/+0fOnS9ddb z0WNsNoAOxJWdf+A/dIrr/zp5j+1trSuN2/e8MDAo/f/rXfpsk0XbISfKZoEuBHj5dzD4QYMgIc5 c+YsXrwYFRanB2ansVJ7tUdk+ctq9ADBAdujjz76/IsvtHV0sLD/dNOfRoeGN9xgAcpDSVkNIzCn DZbKPffeS2lppAFVlN9yyy1qPn1D58t9UN6ZBSTcqCA8JqJ7ZveyV5f+9sorW5Op7tmzZC20tYmU wHE+n7/j1tseevChDTfaUPWknEeRRhHc1ltvPeUsPgm0ATyrTVqOY9TFhVyPZMaygrpYVn+++ZZk jAP9HN4u4RGGJ/YtX/H3Rx574N77WOxogbhz/fXXo/Zh4bsPxxGq1WvmmyzUtszXvffeC8vmeHH5 5ZdDinAw2AcxeIRKKddumig++LeHHnnk4bnrr8e+++KLL915xx1qslo9MGo+JQmInHOQaQ8q0LD2 p8e4dftViUllPdU6ecHS+8qsvT/xymo912pjQSUClOkoT1jYnJ5QTVx11VWco4n0ef/7P2ClLQQ2 Ci3/+Kc/++GPf/Q///M/OC/efedd6N9Xrlq18847OwqPqw3ndB9knTAruO4sfXXp73//+y223PKu u+667vobHn7sUZSNW2+3bTKRVCUvg73iiitAwvrrr7/RRhudc845Tz/9NIsNZsfmGqjKmC5gr7E9 50q8jJipu+++q7enh9VBYY0zzjzjyCOOgq+pRKPq5nvuvufqa67mfMaEYjv62te+RulInJQ233xz zrxr23wxEaeeeioQQnULX3kFMe3vTz5x3Q3XH/q5z7HAkLJ1IaDyZjc666yzN918s+233/7+++8H FTjUMmX77ruvz8b4GlH92h9nnaL5VOsUghEqYHjx2WedtfGmm+z4lrcwTWpphPYWLlx4+1/+8uLL L1126aU77rQTelFa/uUvf5k3bx777lpIhPjC3XbbbYANkG95y1v+9re/feUrXzn88MNFLDAnQmCG Vq+//ro77r6rp7f39ttvy2dzt91+22OPPsqDECHL7T9IhJZxT88d8LXTxOvVA4sBKYzMJ2efffb+ ++/PBLB4qNLwmc985u9//zuqJPgai5+ZoALpnffcjZv7BkY5/vBDDx1x+OE0Q6ZzP5y+XmAH9gPd wIVPO/X/Lrrwwve85z2XXnrp3ffee+ZPf/zlE4575pWXOJbiHa86PhYGKwetFFsXRSoQ4r761a9i QsCrx2ddDHzpGmgAbwK2iy+++KrfXHXXHXdtu8023/72t6WivNH5MGVIoCwYhv+H66/70pe+xNaF UQTx7cADDzzyyCM52OHPsJZI3F50Ma4jjjjif//3f4kse+TRR/c74MNf/8Y30saOCk9nZ4XMADvV 2nr817/2gX0/yMrnccYF0R522GFsSGsA+dN9BeuChcNqYhYIdb799ts/+9nPHvzxQ1DI6lH9lFNO USPknPXmHfLJT5z7q1/utMvbbvnzLbyIQRHeIck03LKeThe219IemWaHHXaAY+AIx6oB/u9973so dXGSQX8AvV133XV8YO4+euCBH/nIR9AozOqexb7Vu6rnyiuvxLCHUKXG3v/49d/KuEEc07DLLrug H+Dgc9xxx7EGYGfgHUGGXyE4DqF8QAa/6KKLOJaifOfoB+qRJtTl6D+O/WoAICYObqiwOUwAKrwY dtazahXCJt7xLIZPfOIT3GHZfOhDH7r22msJcWKLgqmBDZRR8BE1ta9tF1OzxRZbIGmeccYZ++2/ H6dUpDaWhDrwIFnvuOOOqktVpzS4A4NiLCww2lA7SXOBrYXjQjfF9sl5AicrNh4WNuKbOmXuvffe /GpPpcgW6sxAAwgVynQp+LLmhwwRAhhVBjnGoVj44he/CAxqdGEKAP7zn/+8OqLMnTsXRQrri7Gw xeIuDAUieXCSWAulBwDmMIq+7ic/+cmuu+6qZYwAWE2yqHc4gqvWl+lDJMcpDp9aNdojD0Gu6syz Nlz/xYwb5qtxm8jd8Oj58+fjEo7T4dZbb60+QGpA4MMnP/lJ5omVz09spGywiKgo4t0tDGtsqtS6 i7M8khrHAt6rvjQIpHzVcxw3gRySQv/LSLH3Mka0pSwbWAPC6X/wKFcPUYDNEDhKs+AR5WABbEsM B9U8ZwWYuOZXAnJcVlgkKFXf+973Ip/yK1yb9nDAarP2GpuXBuNCLGV/3WuvvZgIXAhY8NAhMKs7 mqoHGRqiA7/C0eBxaEsffPBBULG2KUl0mMDMGvnVr34FX+Y8ASOGJtlymDJIUfkaFAjVsdxggkwW XBtODe+DApnoffbZZy0cGgjn9IDszNqBD2hMALodqIvZse43oq+75x5UWAcddBBMgwbqFYNIjp5k LdH/TE/H/R9fJ14AQDQLBubF2mYmPv3pT8PEcWVBY8WCZ3rYSDGHwhF22mkn9lLUW5zBIThmBWmO vRdt4xtt55kuxlgMBCsxEABjAXzwgx/cbrvtrr76am7ic6lqfcBm08Ig9s1vfhPxAU4HT2ffQvQG Dxw+1sINiTUDO4Zbsf45kDIjHLdZ2+xP6hXOpDBHjBonJVqiPOHMxPpn4JyTOOHinrQWqkogQo7e CGVMBzwLBsfcMYloh9/61rfCxFn5TBC2B9JFcBaEIWJfIWkEqGB+P/7xjyNMrJ0bEmTGOmIRKY/G sM8wsbigoyOqjhMSY2cdITxB5Jx3aU8b+Dg3ie2A/akH2nSXwBvXHiK88847UVXDfDmmQ2kcKZB4 0ONzbgBgJpFRwKO5yRiRhIg74SDFzsSDbMwHHHDAf1YqsjruaUROvnEIXe2ekdQYidpIWfPqlaX+ PZAaKPZiWQOZ1L1Mhbs31PtitQcFhCpWK4S6bPirnmRqP9HBWpcytRSpcGcds1YbgDfoQRaGugBy qR0SmNXWzR2dOF6t3nU6fG3GT4qKtW2XVUQxWUpsOi/W5VHZllIaH9T3SZvxV8fIr2+cZPoa9+96 j6uXAUMQ9xITPaiTpePVcamz3VpoQ9JZ0ElRvZZ1efQSoXIJJTzV4Ck2rJvjG7RGArtdHT/uwE7X ngZrIcWsPchZmyFZN3Fr1ew0Zv2NJ6vmr9qht1vvnde407xBqFuraNIy7tdHx71WHYiYv7UNnjeI pGy3juP1NnN85LVDPq0XTavxa4dtXQ/1MKAToUecmpPCzcaTVU1sPn6tPesrvH/rUam9v8bIGKjs IW9tO+2tPuP2om9tG9X/CwvSHf9rnhu6w/b/wkz9N47RK2Z62bed2QY8vVqe8ErZdkuoJ197mUm9 z/oK24OPwl8vgtfNSXtz36XWzHQHMO64ycfmu1BV1kP6a0fZf2QPaPxS76+a+ciXslXjSKc1YZpS alqPeBs74l/JruYas4Na7SmDDKppA9WgI2yrMfb/CG00htMLEhMKQnwRnmqKmNZgfbnupvWsY+N6 k17NKL2cWmc2cFf2MXcFySu6euXraoADWWRNMgiEyguDfSkrV5MIuuPNAt94U3HscLWbNTJOwrXv uuMvDz/0cG5cTA1o6HFaWH/uvD33fPf2O+5Q75Wq/sc6oaY/NbXpINW85n1QQ+ZAHA0wAthsDzyl STu9jdViQGMmSQ3xyvs084DPf5nVoiYj9ZzVPVNvqqew2ijss16KtOYmnlKo9Fcex22cYB/cnvB5 0FxLdIifEM4t7i5Q9IlHM15Wb37zm+lWcaIv8mGVNSypV6YizXGyfQy0AT9dDYYI137kwQfv/NMt 8VQyn8lRHK5vcGD+3HkHfeoT660vyfBqXmqfZKZ0+jRRga6o6mFa2qCBkpNOQT3aUAsSjdVupibo mrShdlElCYVEG/OVt/AKxRWTW22MUq6qM6JmcH2QDvEkOf300/GNwTVQaYObeCbgUoLTvaMRkq6I mMXDlfRtdsoAsvpxqJT7q+GdpuY4Hb6XnzbgmL7t34oCLpRj2f20ngok8mqJZLr911sRga/2oo6X KvsKfOq1vM527mScxLf2ygt+dfyRR289u5vkqCyKZLz5/pU9i194rnOuxLbUvG6++WaiQsgjuN9+ +2muiW984xuQHcEyVArGBceSGusHZy/a49NGwAWuUV/4whcY3re+9S08ivArQrC1PAtqwz0WN0yc qEAT8U6INrBRNkycSYlbY81ohkIuHiTQg1+JgMBdifsMGH6NexaBvOQsJEfBDTfcQFQLwa+stJ// /Of2WTrkK/EUOLEShoAzEB5CLFedG/yE8FQ75phj8BBSHwnNU6MZE633vq4BZUa6W+jaU9bDwImK /N3vfoeP0WmnnQb7ZnR4MRJbCJzqdQDqGAVoBABcszXDr/IUNdnXw79PJgqkJ+WbjcWc6k4SLak/ nnfRNcf97wdLM8nFSB7awuy2k1Y89PzChS31M9Iwd0wT3twQA06cuMfhBM2r8TDDXxhx1U43KMLl GT8tsA3jg4Tw/gaHF154IWGHsDbddxUwpQ0SxOOej/vdbrvtxqRAV1AI84tDLmi0jI9OmDtcEqEx XPE+9rGPgdtf/vKXNIAeiOckhJ2AGvonYgifRejBvggIiZDG91xTCX75y18mGkADNJgRxBp6Zh4B xqanx3ebkar/L810z7AbldIGE8rb+aA7GQtB/QXxSGO90B7k4GmnOdCVqBgavrDEKEIbmvBdj31a KbDBRTNcEtkVXAhD20yLPOqJC4733aFyb1lz13F/3NdyWtgIfIsXLV441cWl+nGnJFPRWPyFZ/71 j3vv3S3Vsl4iOb85sUGs+dWhwaNO/HqMEhh1LnXXh1533313qIQloaFWECJUjruxZToQImsYuiQ0 Cy9sHKtZGPBreD0r8HOf+5ySuL6HTn76058Sxf7jH/8Yrk1YFxEZsD/4GhyQLQGfU+sPyyvw/OVZ aJRqD0rrgMSOQgSBPg6vhyOzvE866SRciS2aEGSIiAUeFgbLD/aBcA3HwQ8fwJC1gRNfXYJ6dKmw DcDliQDSjFrATA5FnpJ0V/Pm0TMfeJz+8RUF7wjsiGbcBELEMSKD4A4EZcCMWKXsK8AMAkEU6SzY e+gKlPIso4PRs9Xx0gbFCafLgsHtajwSaY4tfuyfvbc99M3x9XeYSO5Uatk5n/xdU+8RXzuOPHj1 aAM5VOMhwT/DYbDsdvBZwvPgOEyHnUFo49xzz6Wfr3/967BsHuQzSGPnhj/CbdUVUl+kbBpEweBw aYfh4ifOLDP1uIQTG0Jkpm3MFODsD7/DqR+SYDpglwQ30wyswtCZRD4z+xCwN3EoL9IjF91CPPA+ HOeJ0QAkEpUw0UwfRMjsQ43Ko+kcx2f4MiCp/xn7EIcttnkIBhdpRBY2J2gGeJhZjm74FzP7EDbu xmw5RJBDCUDFHoMLP234yl6Caz/5A3gFn9kVNN/9BRdcAH9vzCwAwx44AtmKNvBqEiyp+GimJgl5 OZFXJq133xGe6mYuwDTofFq8WN9lpfvVhrnxg/WWJPc1yVRj5Y4kkCXzCgd4zpPyLxwiCycJeRu8 FeqH0WjBJF5D9ARrANEVqQqZyKfvg0Hjug/nJSkHi4QwdGBi2UDHWsPX+yItYgLzZW0APSuH9Uw6 CLgA0RlePQPUyaqAxAl5ogf1FCYyhbgAmCmcl19ZOXAQRD+e9QqwTAkrwRZnIKSKVyCqs2Jh0Fra WCPLlf40jTI8iKHB9FnGJO1jQcJf4Ox8hgHBl3H1pyt6QIyiDUsUbgLMiIR0yMLmcfYJ1ie8hjY8 iKTJRgVaVC5j0TJwFjbveoPIZVrdUhs7JgoDrdRXTJMhvpCbGG6USADuxvFClVcMCi7GBsk0secx WJ/SHxzCzTn9gC7Vk4BJ+DKirkqvFloeZEtjS0A4AM8QG0TIvg4t8TqYsu+AQlgTvJW86swL80if qCbAPBuzeiUz4+SEAdvwUB9UmqOD/QamDxkQ5wUP1VkGAO4wy0r5OkY2aWQXFaUR5KFzdmtVixHu wVQSvMcBjt54F0IAmwq98RYegZwgVy2RA35og7APKydqScswEfKjBZEhJwDgFRxN6k2ixRg9u0y0 V4tiWZXvpu2H+9XqgpqNvTKmi4ahAaheGvB+9m0S2gMNqrmh3lwNwWW6T1VvePaOF0v6uSYyfXgI 0MqjLZwYL3rZJ5/zWTny10Mo1INUq7VLaAP/BQ6+sn4sBu1igA8iHBGPBHXC1knWo278UL8WqOay jVmHrEnEc40thF55igwebAx6yvZik5fyK4uBl8IvWDCsKw6t0DpnbX5llbJOVMpT9ahqz/lLG+Lc EPnJYMcuQqgbewOZBYljZp3QIWdq+LJycIQvwEZm5Cv9sBUhSqOfQVRk1fEu3ks/sCFeqlsFMZDs bap+QbBCJYp2iKMDvIahwcqRH0EjJ3F2Jg7O3AcquBIyOP3DpAITrbzGJeGysMnkNeGhAlCXjCSo 8SH59etcDEqTP/A7zBQ6YQdlA1YFkU6fle+YUPY2nQV4HDoWGBncFgULrA1Ue2kD9vfhD38YmReG +Otf/5qWzC8xjWwMHFZ8PfMg4jnKNICBiQMMNIDShjlCZkf/wE/khEE0JgsHGzOPWyJkBmnJr4R6 Mo8cAhD/gQ0GzXBoBkkAm7Jm4u5gyuw0vAKQ2I+R4umcnE0MDVkbkRxOzRqBgGG+7N/oaojQU2MA Gh4UL2iHoChOqywWksdq7j1eCiFxkIV4mGukH/Z7cmswasV9AzYaOLlWnNQl7JMufWzFfvXypgb8 4fWiTF7hBaxmt7ZNPW7owiID0eXSoHoPs3eq8eayKwQw7qYQDQhHlMoN+k/kq1KIBMoNwEXegfJU zYfIg6xK6DlckjMmdyAvWI+K3kguhHRDgmgMWCdQJ0yKlhAoNA2to6BAh8AHljFrDO4PWcNMlUBh 3wjOdK6KY6RR4tq1Z5YQSw49NZ9VGEeqQnZjnehXVinsj6L1rDQa8yKSM6j4zF8WJ+uKdYveGbEd jg8M7CXaOcuS1Ug/sACWEwwdIV3vs/aQ1GgPJ+IrAJMVgd2FkyzHCA1rVE0uDJr3slBhQ/AaVECo 3VGPsjI58GoGHPsWuuLIwnKFX8B0YHY1KVUJkWs1hAgX+rNtwqVQtqk00MxAlE3LGumlflwhG65D G7RQdqaTAiYx57KhogSD7YI3boIBJlGRzN7Gps6lsjMYhq4Qb8G22oT5gA5Bo0yhItQUKC7glfBQ 5pTpg7rAP9gGz/TA7GtjqAtuyE0MDGRE4VDIUYwp+9nPfsZc8wgXWzUTB6p1poBTBVWIDc7Lzoqe BJg5LrCXAwnCAVIFkEtxL3M+0E3IclLAoFt2ca1MBCqgdnTZHMKAhynTcyGv4BygjBuVHeNFCOBo AmZ4BS9lUDq5Kt0jm/MUKOLcwJBpr3M0XQLwsjCfMOjryrKVapatr14z3NDLCuttBnrf+2t1Sxcu OUn204zgt6ho8GFa6842DvKDCTeN54uDFJMdHRkcGR4eHeWUG4uyrmpIVaCAFYWIhDIaeZMPvIbi kzBiUt+y0lA70gAdrua6hL5h5bAtGDd0yRmQxpApyhDETAQoRstig5dpY6QVDpvQKA1YomwMyLn0 wK/QLouE9U9jPsALEIJI5YzGHHGelkjlyMWIMAjIXCw2nmW3sGyOcyh3VNzjXVpBmAf5i4WTTQVN K4xGM6lzh7M2B2o0KrwCaOELLGOWJZ3zdu6gGWdBoqbkJmkrEJoQqdh7tCstd4mopc4wDIGBcBxm NfKglnPjPnhDAGS5spJh3MiqaITZupBAGWn1lCsV1ly0r5ekU34plTtamodmJoqhoUGOVaGRvlx6 ZbEw0ZZEhVLzAi3gjRM9exWbKIyJ6YbRvPvd7+YzmgqegnnBdsEGw0f4ZWNGkQXvow3nD3QOpN8C t3BnGoNJLSgM0kAsxxHszJgTMHEzlQjmyMUqPdAGqmNvpmfoEM7LJo38y64MoXLUg2VDaZjTjz/+ eF7EZHEUo/weJyEoFvDYd1XfonXTLW0g8ELASL4QJ0yfOaUHmD7jYrxAy08ILswakDBqjoA8whRz cmJQHOYgfsCGsD/1qU8xIvgv44U8OPbBqZk1DhlsWgwHUQNR3c4vQJ5wwgnoahgUmUMgYHYvhrN6 jMCRf3mpqAGxrR4Mb8RTPiGmeml4t5nALWe6IpHFaoMPqzfqxu6A8UfueODcH/+8pbtzND3a1tZa zJbGhodOPf3787ffnIq2NV/J8RPuhsCoKmlVlUB8MBo0DFA8IommUlTlBmuVm7SxhiA+00Bt6LxC S83yQeu8sYpoCXHzQQvG64N0BbflEa3oDBNXMw5LQq2Cyh/hC4hm9MkSYmmxNlTMUeul1uhRJax6 MdItX4GWDnmR5kXjYhQ8rhCqHwgD0QKPfGXU6gECeEDFWAAY8VmlMIQ7/tInKmzeCMA8wtuBlh5U Wle3M2UQcG2e5QOv8PqM+9Sv9ShgutTmQkng4bbb/3zNFZdFmqKFwaH2eGo8FlnR3/t/P/vpVluQ NamGFYSx60SDGbgSJMG4QBTj0jyovJevDFyd81QCBRX8quVxucmQYcGgjmZwbf6q1weN+UBXbLrg k69cOgX8CiYhS3rjpELnvAW081UT/AIGoisfdN6ZZeaCm7yFWaM3+tSqLrwd4ZpOvK4mSpl0qMcp HgRC5gvYVLLmJqDSgJ9oo04g+itrRMkYJY/CwNsBFYD5zH31CleXJGWadIWoTj/QiabfUVUM3QIw e/+0PEZc5tq9jWL7jaA3dxhe35ZrYCy6l9gX6Yd6Ypb1KglIMkXFTNQkyBiyZsSnDcclXL/G8QCr hyBlkfpiBULh4K/VY/LZOn7Zvcje4UEv6Paz3S3t2HiXd5O0KFAeTYe61L22KfvV96zKZQqDtx8L jO1QB+5tbAHTFyl3VsCUa+hN27m21yO8Aqkdetvbxvoii0l9u0Vv9SzoiyxIXpp4fWmaQ5f4rzVF igUpjElZNak8JgXp69qurf4a8NSBBAwowDqiaszb2bekbDFfcwYVsT4SUvTqT3ZGvJi0gHnRpWjU 91qy8ZGBvshLz17as78q8duvFkhLG2DDLhw7Li/l2wnlV0WdhdlLtDIRQdWwfEi2VNGAX9SjnDXA 115noq0sH98CsbS3eiOth9LVBr7eXLgy7lg81hwv5w7XKsWszXQ2XRyfEkdj14lFh+VN7qCr7wSk oJ4bNS+6VdHMhtXUbKYWebpCovEueO5Pq84AknJ1HJD7iLSlzsFqrAqXF3lXjpfFKwOyALh0tRpt ZFCe2tViAnGIRFiNF6175HXHwOvLc737rhdUL+XbhfC6j6UBu/CKOF4AXt/hVzNAXYBehu7dhq24 aRt4N5IG+HFi3NFY9Lm/P3P91X9onduqh/dINLJq0arjjzshPidVmijzblUC2oMtXSOVAJlakKoB 8onACiUsFbsilkMYLspx68/rHQNdwUaxnnPCRcddT7KgK9SO9MYhF19dYFMhC6M/97FG1uy8Gllw bdwS0FF6Yz2qm9kB1uRZehM8sGE07meNUfO6F/0/ggEv43DkC2sGM68701xtsOvtN4EdvvYhNH51 oMTdyDgZiUWWPLf03gv+OvO02W0/7CieHI5+M3712VcP5gbI/axjgwujB8TUg10elRz2Oi0SiP8D RnnsRaqF1FIg/IXn0hJFnh704Kr2VzTgNMYBw3rpwu94RNXKNEbfh0kHK7z6gai+2yb90P71RWi3 seDhcqB6dt0Y8D9Bu23ZK3cUNt0t1S9FtaI8wgf+YrZSr0T9SWPk+ABPV1WsapyJoOEOnxUn/KS/ amPMrXjR4IegZ4V11zoMrBkM+I6/a+alvrfUlGasmPm6nM+s9LoaAwSSap2JSz+vfSP0vno18NCo Ak40Hl385NLBu4e+Ff7WzpG3vSP2jrfGd747e/ceX9mzq2OGatZgoEiyWP9xmcJcjvUcdwssOfhy 4fuBowXmeNg3FhX4JrZ+fPvghrA5fFGxpRBXhgStlkZ19cMxDo9mHQnOWFI8e+FCTDc8gk80Dip8 oFsuvLgwMGoJFYRrDER0xetgshi+cEPETwBglJ8ia8M68e5QSz1teBDvV5wOcTjD1IOXNBsP1kKc 1TBe4QGC+I9jH6I9GwZBE/SMpxoQ8ghgMGpV7LCRYNlX+6fml2DDwMlEayrCrDH0s5EgceML4Y0S cqGPdW3WYeC/GgMNGJyPaa72MF+vflSAW20ZfLXh1wcddwKauUROor8sFUKFSS9uPCgInxQjVPmC fcN/iTLggsHBELVaGAyLD3AuXOJgbTBrfKKxg2NwR9zmg/p+YATHmE4UAy6rfPUqoOkKCz7+s/jb sQeg3wCnWtEcsZ3+8YViw8B3FUbJeHCWQvBHYOcRWKoG8mh6EICkZ5gpRZ1VcCbsBR87LQbKHfxk YcdoV2DBsG+c7YgnvvXWW9mB4L90gqsW3XIfnk7PCPLwcRKe4LKC9obhaDgc78V5hmb4rhDyx9DY sXA1w1cMFzHHNEOvkQLWPb4OA+swsNoYqJbBrZbcqy63Yv5rkfctkPUUIw1GEejHjauAxy9XInEi TcXJp+CJiLc4ROOGjCsbWg4u9eRTzTISNEwQH2rYGfwLFkwzos9VD456BOYID9XEFNyB96lTNnwQ EZtAGMReYlLgvChh0DijhMFRl6/Ku0ngwMYAP0W+hi+T/ARPXvYGALDbAHghPRvpgTTukVfA7vGl RWmjIcK49LIHEHmPxA3w7AG0xxtdQ2Zoj7MtsRJ49bInMV52I+R3Tg+I2MS24WGNtoQTAy1x4GVX QDfCxevY1XDXxeUWH1tH3fpq09y6B9dhYB0GXl8MWD7u/aACssrINTUeXl7vZfE+2KyGZDVUJQ0Z N/I2XJuACk1HYf5FCKQsTXkKPqu5O6xbEhIxqmEdGPIsAinqDoCjGfcRQvmgNkykaRgoIjNqFsUC N9VpV22PaFdwoKYTJHT6h0HzuI4fLslnsjegdeErvxLqAudFVFevLw1M1wBrLnpADaK+z2g2cCVG olcg+YkgOvg13JaDArDxUkRp+ldXYhoDEi+CrbMVATPiNpxak/bxCsDQ8E6calH1aPAnSVEUM3D/ dVz79V1R63pbh4G1DQNW3eHl6T6O74XZ295RVWIfb8S44WlwnNHi2CuFV54qPPVE9onFpcWjoZHo RNTw8tqXhjlo+la4FX4dWOdIpkPAGwwRnk74AHZL1fbyAXkZMVy/wvuwHyI4o/uGRRLDRiA4oi7W Tg2gQPdCfBpMWdOfw/HJ0kesGoItviiEuhGVh9JGrYu0QZAnbo3PBN3REr02IjZaDjTXSPrI4PRM tzxFMxxO+EqIGr+yAcB/ORyoQRIFPb0xHLg58XXEedIhHBmOz4g0Yg2xnZZo1dGWcKQgwRuKFGux XNuIbB086zCwDgP/vRhoFIDTnIzffsmdN116U1+4N9WWHCN4srPt5X++cu3117Zu2Vos+F25FQsw L9TEsF3N3IS4reKwunCgHYbfITjD3DVETfk7vFVjKbE38hQcHB6tEjo8nc/0psI4XJvOYc2oIFBW 0Ab2yk+05CcaoM1QbouYrF3xXtTNGt/IHV7ETVgwb6c9ig7uW/kaHq1fNSZNNwmUHsCgA+GiZ/5y nxcBGP3QjFEg0avnOKI6L0LkV2fE/176WAf5Ogysw8DagwEnP27AxSOQhJQ4yFnQReORDajJomK/ MiwbG6bqC37iDn+tEtw2Vk2LjR/Txnrps7orKCTwa2Rk/DRw2ICz12zs7YrP9qv2Zu/YODRt4I1w U/2UNlbwFAZtqXxcf+UmH+wQFE4L9toz8esgWYeBdRj478WAK+OuMULNEPifvlSU1goJ/2lY1r1/ HQbWYWAdBtYEBizjDvIqqQZmLeDaAKVakXVce00Qy7p3rMPAOgysZRgIa0UxVeauZbCtA2cdBtZh YB0G1goMrCXsUSVuAtSltBhc25emcq1A1Tog1mFgHQbWYWAtwIDXrPWfBQfGjaaBIJIwwS/Wl+M/ C9O6t6/DwDoMrMPAWoiBtYdxgxx4N65r/x9QFmMl/+TwmgAAAABJRU5ErkJggg== --001a11c2d8ba804bf30506a993ee-- From nobody Thu Oct 30 13:31:33 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 064931A6F3D for ; Thu, 30 Oct 2014 13:31:31 -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, 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 tcl9o53hxAyB for ; Thu, 30 Oct 2014 13:31:28 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id E826D1A1A7C for ; Thu, 30 Oct 2014 13:31:27 -0700 (PDT) Received: from [192.168.1.123] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 08E2F28EA236; Thu, 30 Oct 2014 16:31:27 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_302EA0BB-E759-4FBE-AC3A-C21CAABA19F9" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: "Thomas D. Nadeau" In-Reply-To: Date: Thu, 30 Oct 2014 16:31:26 -0400 Message-Id: References: To: Andy Bierman X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/sY6EWEP9C-YFETSPWFivsXiibi8 Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG model containing both device and domain config (was RE: New revision of YANG mount draft) X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 30 Oct 2014 20:31:31 -0000 --Apple-Mail=_302EA0BB-E759-4FBE-AC3A-C21CAABA19F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 30, 2014:4:17 PM, at 4:17 PM, Andy Bierman = wrote: >=20 >=20 >=20 > On Thu, Oct 30, 2014 at 12:16 PM, Eric Voit (evoit) > wrote: > Andy, >=20 > =20 >=20 > Two weeks ago I promised a useful YANG model which exposes both device = and domain config. The model is here: >=20 > = http://www.ietf.org/internet-drafts/draft-tripathy-cloud-sla-yang-model-00= .txt = > =20 >=20 > A simple =E2=80=9CCloud Policer=E2=80=9D application can sit = completely upon the model. The algorithm might be: >=20 > =20 >=20 > (1) The Operator enters a maximum data rate across a federation = (Cloud) of devices >=20 > =20 >=20 > (2) Sum the current bandwidth across the collection of devices in the = federation (via RFC 7223 YANG device interface statistics) >=20 > =20 >=20 > (3) Policed Bandwidth rate each device =3D (current traffic to the = device / current federation traffic) * Operator established Federation = Max rate >=20 > =20 >=20 > (4) Go back to step (2) >=20 > =20 >=20 > If we set the federation bandwidth to 100MB/s, and then vary the = offered to two devices, the result looks like this. >=20 > >=20 > =20 >=20 > Effectively we are showing the config of domain and device upon one = graph. And the device config is varying over time based on Peer Mounted = RFC 7223 YANG interface statistics. =20 >=20 > =20 >=20 > This is running code. The code is portable so that it can run on a = controller, or it can run upon a designated router within the = federation. >=20 >=20 >=20 >=20 > I don't think the application needs YANG Mount to accomplish its task. > This has nothing to do with the issue of device-configured vs. > controller-configured data collection. Any controller can collect = some subtrees > from each device and use the data somehow.=20 The point of mount isn=E2=80=99t for the controller=E2=80=99s = convenience per se; its for the app that wants to get at those stats. = The app only needs to talk to a single controller. > Just use NETCONF or > RESTCONF as-is. It really complicates the architecture to use mount = points, > especially if every controller is going to replicate data from every = server in > different ways, and force the devices to do all the work. It complicates it for the controller but has the advantage of = simplifying it for potentially many, many more applications that rely on = the controller=E2=80=99s abstraction of the universe. =E2=80=94Tom >=20 >=20 > =20 >=20 > =20 >=20 > Eric >=20 >=20 >=20 > Andy > =20 >=20 > =20 >=20 > =20 >=20 > From: Andy Bierman, October 14, 2014 6:47 PM >=20 > >=20 > =20 >=20 > I do not agree that the "collection of device models" is a very = interesting solution >=20 > for network management at the network level. We have dabbled with = "network-wide" >=20 > configuration a couple times, only to drop the issue. IMO the models = at this level >=20 > describe the network, not the devices. There is some glue that tells = the controller what devices are >=20 > available, and how to talk to them, but the goal is to handle the = device level details >=20 > as part of the controller data model implementation.=20 >=20 > =20 >=20 > We have a YANG model for Cloud Policer and DDoS Thresholding = which exposes the interplay of domain and device view. I will strive = to get it posted as a new draft before Oct 27th. (IETF 91 cut-off = date.) >=20 > =20 >=20 > Eric >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > Eric Voit >=20 > Principal Engineer - CSG >=20 > =20 >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --Apple-Mail=_302EA0BB-E759-4FBE-AC3A-C21CAABA19F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Oct 30, 2014:4:17 PM, at 4:17 PM, Andy Bierman <andy@yumaworks.com> = wrote:



On Thu, Oct 30, 2014 at 12:16 PM, = Eric Voit (evoit) <evoit@cisco.com> wrote:

Andy,

 

Two weeks ago I promised a = useful YANG model which exposes both device and domain config.  The = model is here:

http://www.ietf.org/internet-drafts/draft-tripathy-cloud-sla-ya= ng-model-00.txt

 

A = simple =E2=80=9CCloud Policer=E2=80=9D application can sit completely = upon the model.  The algorithm might be:

 

(1) The Operator enters a = maximum data rate across a federation (Cloud) of devices

 

(2) = Sum the current bandwidth across the collection of devices in the = federation (via RFC 7223 YANG device interface statistics)

 

(3) = Policed Bandwidth rate each device =3D (current traffic to the device / = current federation traffic) * Operator established Federation Max rate

 

(4) Go back to step (2)

 

If we set the federation bandwidth to = 100MB/s, and then vary the offered to two devices, the result looks like = this.

<image003.png>

 

Effectively we are showing the config = of domain and device upon one graph.  And the device config is = varying over time based on Peer Mounted RFC 7223 YANG interface = statistics. 

 

This is running code.  The code = is portable so that it can run on a controller, or it can run upon a = designated router within the = federation.




I don't think the application needs = YANG Mount to accomplish its task.
This has nothing = to do with the issue of device-configured vs.
controller-configured data collection.  Any controller = can collect some subtrees
from each device and use = the data = somehow. 

The point of mount isn=E2=80=99t = for the controller=E2=80=99s convenience per se; its for the app that = wants to get at those stats. The app only needs to talk to a single = controller.

Just use NETCONF or
RESTCONF as-is.  It really complicates the architecture = to use mount points,
especially if every controller = is going to replicate data from every server in
different ways, and force the devices to do all the = work.

It complicates it for the = controller but has the advantage of simplifying it for potentially many, = many more applications that rely on the controller=E2=80=99s abstraction = of the universe.

= =E2=80=94Tom




 

 

Eric

<= div class=3D"">

Andy
 

 

 

From: Andy Bierman, October 14, 2014 6:47 PM

<snip>

 

I do not agree that the = "collection of device models" is a very interesting solution

for network = management at the network level.  We have dabbled with = "network-wide"

configuration a couple times, only to drop the = issue.  IMO the models at this level

describe the network, not the = devices.  There is some glue that tells the controller what devices = are

available, and how to talk to them, but the goal is = to handle the device level details

as part of the controller data = model implementation. 

 

<Eric> = We have a YANG model for Cloud Policer and DDoS Thresholding which = exposes the interplay of domain and device view.   I will = strive to get it posted as a new draft before Oct 27th.  (IETF 91 = cut-off date.)

 

Eric

 

 

 

 

Eric Voit

Principal Engineer - CSG

 


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

= --Apple-Mail=_302EA0BB-E759-4FBE-AC3A-C21CAABA19F9-- From nobody Thu Oct 30 13:48:35 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7E91A8770 for ; Thu, 30 Oct 2014 13:48: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 zivBSuBpMziE for ; Thu, 30 Oct 2014 13:48: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 D71001A876C for ; Thu, 30 Oct 2014 13:48:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29908; q=dns/txt; s=iport; t=1414702110; x=1415911710; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dT95/ryLsrQ27lq9h68SKPr9fGKRAkjtYz95gbdjOpM=; b=K0BAeJyvhVwmB78pu40PoG1Bho7oiPJFTT8g/lF+DP7AEL4txoI8ft1K GHVYHFF4PMZtezkqrx6eCD2gCKmC3qHK7yFNyd6zcye5M6vPvLWAesM39 Xzluz1gSim+tDgV2Sqx40KXDnRlezXASzDwtRV8HLSrmGnEQdzWf07Hmc s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al0GAFijUlStJV2Z/2dsb2JhbABcgkhGVFgEgwLKDwELhndUAhyBCRYBAQEBAX2EAwEBBAEBASAKQQsQAgEIEgMNFgMEAwICAiULFAMOAgQBDQUIARACiCYNtgyUbQEBAQEBAQEBAQEBAQEBAQEBAQEBAReQXg0gBAYBgnc2gR4FkhCiJII0gURsAYFHgQMBAQE X-IronPort-AV: E=Sophos; i="5.07,288,1413244800"; d="scan'208,217"; a="91893959" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-6.cisco.com with ESMTP; 30 Oct 2014 20:48:29 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s9UKmS5n015461 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Oct 2014 20:48:28 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.58]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Thu, 30 Oct 2014 15:48:28 -0500 From: "Eric Voit (evoit)" To: "Thomas D. Nadeau" , Andy Bierman Thread-Topic: [netmod] YANG model containing both device and domain config (was RE: New revision of YANG mount draft) Thread-Index: AQHP9IB8AYuY9U0/8UKg51uu0KCQYZxJGGvg Date: Thu, 30 Oct 2014 20:48:27 +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: [10.154.208.25] Content-Type: multipart/alternative; boundary="_000_EF64FF31F4C4384DBCE5D513A791C2B120A5A8BDxmbalnx11ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/vAyaX_noxa2vs45vPqTWLkgbpkA Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG model containing both device and domain config (was RE: New revision of YANG mount draft) X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 30 Oct 2014 20:48:33 -0000 --_000_EF64FF31F4C4384DBCE5D513A791C2B120A5A8BDxmbalnx11ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogVGhvbWFzIEQuIE5hZGVhdSwgT2N0b2JlciAzMCwgMjAxNCA0OjMxIFBNDQoNCk9uIE9j dCAzMCwgMjAxNDo0OjE3IFBNLCBhdCA0OjE3IFBNLCBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdv cmtzLmNvbTxtYWlsdG86YW5keUB5dW1hd29ya3MuY29tPj4gd3JvdGU6DQoNCk9uIFRodSwgT2N0 IDMwLCAyMDE0IGF0IDEyOjE2IFBNLCBFcmljIFZvaXQgKGV2b2l0KSA8ZXZvaXRAY2lzY28uY29t PG1haWx0bzpldm9pdEBjaXNjby5jb20+PiB3cm90ZToNCkFuZHksDQoNClR3byB3ZWVrcyBhZ28g SSBwcm9taXNlZCBhIHVzZWZ1bCBZQU5HIG1vZGVsIHdoaWNoIGV4cG9zZXMgYm90aCBkZXZpY2Ug YW5kIGRvbWFpbiBjb25maWcuICBUaGUgbW9kZWwgaXMgaGVyZToNCmh0dHA6Ly93d3cuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXRyaXBhdGh5LWNsb3VkLXNsYS15YW5nLW1vZGVsLTAw LnR4dA0KDQpBIHNpbXBsZSDigJxDbG91ZCBQb2xpY2Vy4oCdIGFwcGxpY2F0aW9uIGNhbiBzaXQg Y29tcGxldGVseSB1cG9uIHRoZSBtb2RlbC4gIFRoZSBhbGdvcml0aG0gbWlnaHQgYmU6DQoNCigx KSBUaGUgT3BlcmF0b3IgZW50ZXJzIGEgbWF4aW11bSBkYXRhIHJhdGUgYWNyb3NzIGEgZmVkZXJh dGlvbiAoQ2xvdWQpIG9mIGRldmljZXMNCg0KKDIpIFN1bSB0aGUgY3VycmVudCBiYW5kd2lkdGgg YWNyb3NzIHRoZSBjb2xsZWN0aW9uIG9mIGRldmljZXMgaW4gdGhlIGZlZGVyYXRpb24gKHZpYSBS RkMgNzIyMyBZQU5HIGRldmljZSBpbnRlcmZhY2Ugc3RhdGlzdGljcykNCg0KKDMpIFBvbGljZWQg QmFuZHdpZHRoIHJhdGUgZWFjaCBkZXZpY2UgPSAoY3VycmVudCB0cmFmZmljIHRvIHRoZSBkZXZp Y2UgLyBjdXJyZW50IGZlZGVyYXRpb24gdHJhZmZpYykgKiBPcGVyYXRvciBlc3RhYmxpc2hlZCBG ZWRlcmF0aW9uIE1heCByYXRlDQoNCig0KSBHbyBiYWNrIHRvIHN0ZXAgKDIpDQoNCklmIHdlIHNl dCB0aGUgZmVkZXJhdGlvbiBiYW5kd2lkdGggdG8gMTAwTUIvcywgYW5kIHRoZW4gdmFyeSB0aGUg b2ZmZXJlZCB0byB0d28gZGV2aWNlcywgdGhlIHJlc3VsdCBsb29rcyBsaWtlIHRoaXMuDQo8aW1h Z2UwMDMucG5nPg0KDQpFZmZlY3RpdmVseSB3ZSBhcmUgc2hvd2luZyB0aGUgY29uZmlnIG9mIGRv bWFpbiBhbmQgZGV2aWNlIHVwb24gb25lIGdyYXBoLiAgQW5kIHRoZSBkZXZpY2UgY29uZmlnIGlz IHZhcnlpbmcgb3ZlciB0aW1lIGJhc2VkIG9uIFBlZXIgTW91bnRlZCBSRkMgNzIyMyBZQU5HIGlu dGVyZmFjZSBzdGF0aXN0aWNzLg0KDQpUaGlzIGlzIHJ1bm5pbmcgY29kZS4gIFRoZSBjb2RlIGlz IHBvcnRhYmxlIHNvIHRoYXQgaXQgY2FuIHJ1biBvbiBhIGNvbnRyb2xsZXIsIG9yIGl0IGNhbiBy dW4gdXBvbiBhIGRlc2lnbmF0ZWQgcm91dGVyIHdpdGhpbiB0aGUgZmVkZXJhdGlvbi4NCg0KDQoN CkkgZG9uJ3QgdGhpbmsgdGhlIGFwcGxpY2F0aW9uIG5lZWRzIFlBTkcgTW91bnQgdG8gYWNjb21w bGlzaCBpdHMgdGFzay4NClRoaXMgaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCB0aGUgaXNzdWUgb2Yg ZGV2aWNlLWNvbmZpZ3VyZWQgdnMuDQpjb250cm9sbGVyLWNvbmZpZ3VyZWQgZGF0YSBjb2xsZWN0 aW9uLiAgQW55IGNvbnRyb2xsZXIgY2FuIGNvbGxlY3Qgc29tZSBzdWJ0cmVlcw0KZnJvbSBlYWNo IGRldmljZSBhbmQgdXNlIHRoZSBkYXRhIHNvbWVob3cuDQoNCiAgICAgICAgICBUaGUgcG9pbnQg b2YgbW91bnQgaXNu4oCZdCBmb3IgdGhlIGNvbnRyb2xsZXLigJlzIGNvbnZlbmllbmNlIHBlciBz ZTsgaXRzIGZvciB0aGUgYXBwIHRoYXQgd2FudHMgdG8gZ2V0IGF0IHRob3NlIHN0YXRzLiBUaGUg YXBwIG9ubHkgbmVlZHMgdG8gdGFsayB0byBhIHNpbmdsZSBjb250cm9sbGVyLg0KDQo8RXJpYz4g IEFncmVlLiAgIEl0IGlzICpwb3NzaWJsZSogdG8gZG8gc29tZSBvZiB0aGlzIHdpdGggZXhpc3Rp bmcgTmV0Y29uZi4gIEJ1dCBpdCBnZXRzIHVnbHkuICBBcHBsaWNhdGlvbiBkZXZlbG9wZXJzIGxv c2UgdGhlIGZvbGxvd2luZyBiZW5lZml0czoNCg0KDQpBcHBsaWNhdGlvbiBTaW1wbGlmaWNhdGlv bg0KDQrigKIgTWFqb3IgY29kZSBzaXplIHJlZHVjdGlvbiDihpIgZGF0YSBhY2Nlc3Mgb25seSB0 byBsb2NhbCBEYXRhc3RvcmUNCg0K4oCiIENhY2hpbmcgYW5kIHBvbGxpbmcgYmVjb21lcyBoaWRk ZW4gaW5mcmFzdHJ1Y3R1cmUNCg0KDQoNCkFwcGxpY2F0aW9uIFJvYnVzdG5lc3MNCg0K4oCiIERp c3RyaWJ1dGVkIFlBTkcgb2JqZWN0cyBhdmFpbGFibGUgdG8gYXBwbGljYXRpb25zIHdpdGhvdXQg bmVlZGluZyB0byBhY3F1aXJlIHRoZSBkYXRhIHRoZW1zZWx2ZXMNCg0K4oCiIENhbiBydW4gYmV0 d2VlbiBOZXR3b3JrIEVsZW1lbnRzLCB3aGVyZSBzb21lIGNvbnRyb2xsZXJzIGFscmVhZHkgcmVz aWRlDQoNCg0KDQpBcHBsaWNhdGlvbiBQZXJmb3JtYW5jZQ0KDQrigKIgT24tY2hhbmdlICYgUGVy aW9kaWMgb2JqZWN0IFB1Yi9TdWIgd2l0aCB0cmFuc3BhcmVudCBjYWNoaW5nDQoNCuKAoiBTY2Fs aW5nIGJlbmVmaXRzOiBhYmlsaXR5IHRvIGNhc2NhZGUgdXBkYXRlcyBhY3Jvc3MgbXVsdGlwbGUg dGllcnMgb2YgTW91bnQNCg0KTWlzY29uZmlndXJhdGlvbiBUeXBlcyBFbGltaW5hdGVkDQoNCuKA oiBBdXRob3JpdGF0aXZlIGNvcHkgaW4gRmVkZXJhdGlvbiB0cmFuc3BhcmVudGx5IHVzZWQNCg0K 4oCiIE1vdW50ICYgbW9uaXRvciB0aGUgYWN0dWFsIHN0YXRlIG9mIHRoZSBuZXR3b3JrIChhcHBz IGRvbuKAmXQganVzdCBnZXQgb25lLXRpbWUg4oCcQUNL4oCdKS4NCkluIG90aGVyIHdvcmRzLCB3 ZSBhcmUgdHJ5aW5nIHRvIG1ha2UgbGlmZSBlYXNpZXIgZm9yIEFwcGxpY2F0aW9uIERldmVsb3Bl cnMuICBFc3BlY2lhbGx5IGRldmVsb3BlcnMgb2YgYXBwbGljYXRpb25zIHdoaWNoIHNwYW4gZmVk ZXJhdGlvbnMgb2YgbmV0d29yayBkZXZpY2VzLg0KDQpFcmljDQoNCg0KSnVzdCB1c2UgTkVUQ09O RiBvcg0KUkVTVENPTkYgYXMtaXMuICBJdCByZWFsbHkgY29tcGxpY2F0ZXMgdGhlIGFyY2hpdGVj dHVyZSB0byB1c2UgbW91bnQgcG9pbnRzLA0KZXNwZWNpYWxseSBpZiBldmVyeSBjb250cm9sbGVy IGlzIGdvaW5nIHRvIHJlcGxpY2F0ZSBkYXRhIGZyb20gZXZlcnkgc2VydmVyIGluDQpkaWZmZXJl bnQgd2F5cywgYW5kIGZvcmNlIHRoZSBkZXZpY2VzIHRvIGRvIGFsbCB0aGUgd29yay4NCg0KICAg ICAgICAgIEl0IGNvbXBsaWNhdGVzIGl0IGZvciB0aGUgY29udHJvbGxlciBidXQgaGFzIHRoZSBh ZHZhbnRhZ2Ugb2Ygc2ltcGxpZnlpbmcgaXQgZm9yIHBvdGVudGlhbGx5IG1hbnksIG1hbnkgbW9y ZSBhcHBsaWNhdGlvbnMgdGhhdCByZWx5IG9uIHRoZSBjb250cm9sbGVy4oCZcyBhYnN0cmFjdGlv biBvZiB0aGUgdW5pdmVyc2UuDQoNCiAgICAgICAgICDigJRUb20NCg0KDQoNCg0KDQoNCg0KRXJp Yw0KDQoNCkFuZHkNCg0KDQoNCkZyb206IEFuZHkgQmllcm1hbiwgT2N0b2JlciAxNCwgMjAxNCA2 OjQ3IFBNDQo8c25pcD4NCg0KSSBkbyBub3QgYWdyZWUgdGhhdCB0aGUgImNvbGxlY3Rpb24gb2Yg ZGV2aWNlIG1vZGVscyIgaXMgYSB2ZXJ5IGludGVyZXN0aW5nIHNvbHV0aW9uDQpmb3IgbmV0d29y ayBtYW5hZ2VtZW50IGF0IHRoZSBuZXR3b3JrIGxldmVsLiAgV2UgaGF2ZSBkYWJibGVkIHdpdGgg Im5ldHdvcmstd2lkZSINCmNvbmZpZ3VyYXRpb24gYSBjb3VwbGUgdGltZXMsIG9ubHkgdG8gZHJv cCB0aGUgaXNzdWUuICBJTU8gdGhlIG1vZGVscyBhdCB0aGlzIGxldmVsDQpkZXNjcmliZSB0aGUg bmV0d29yaywgbm90IHRoZSBkZXZpY2VzLiAgVGhlcmUgaXMgc29tZSBnbHVlIHRoYXQgdGVsbHMg dGhlIGNvbnRyb2xsZXIgd2hhdCBkZXZpY2VzIGFyZQ0KYXZhaWxhYmxlLCBhbmQgaG93IHRvIHRh bGsgdG8gdGhlbSwgYnV0IHRoZSBnb2FsIGlzIHRvIGhhbmRsZSB0aGUgZGV2aWNlIGxldmVsIGRl dGFpbHMNCmFzIHBhcnQgb2YgdGhlIGNvbnRyb2xsZXIgZGF0YSBtb2RlbCBpbXBsZW1lbnRhdGlv bi4NCg0KPEVyaWM+IFdlIGhhdmUgYSBZQU5HIG1vZGVsIGZvciBDbG91ZCBQb2xpY2VyIGFuZCBE RG9TIFRocmVzaG9sZGluZyB3aGljaCBleHBvc2VzIHRoZSBpbnRlcnBsYXkgb2YgZG9tYWluIGFu ZCBkZXZpY2Ugdmlldy4gICBJIHdpbGwgc3RyaXZlIHRvIGdldCBpdCBwb3N0ZWQgYXMgYSBuZXcg ZHJhZnQgYmVmb3JlIE9jdCAyN3RoLiAgKElFVEYgOTEgY3V0LW9mZiBkYXRlLikNCg0KRXJpYw0K DQoNCg0KDQpFcmljIFZvaXQNClByaW5jaXBhbCBFbmdpbmVlciAtIENTRw0KDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBs aXN0DQpuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCg== --_000_EF64FF31F4C4384DBCE5D513A791C2B120A5A8BDxmbalnx11ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1Bs YWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRh dGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRl eHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLmFw cGxlLXRhYi1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXRhYi1zcGFuO30NCnNwYW4uRW1h aWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkJhbGxvb25U ZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFRob21hcyBELiBOYWRlYXUs IE9jdG9iZXIgMzAsIDIwMTQgNDozMSBQTTxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBPY3QgMzAsIDIwMTQ6 NDoxNyBQTSwgYXQgNDoxNyBQTSwgQW5keSBCaWVybWFuICZsdDs8YSBocmVmPSJtYWlsdG86YW5k eUB5dW1hd29ya3MuY29tIj5hbmR5QHl1bWF3b3Jrcy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g VGh1LCBPY3QgMzAsIDIwMTQgYXQgMTI6MTYgUE0sIEVyaWMgVm9pdCAoZXZvaXQpICZsdDs8YSBo cmVmPSJtYWlsdG86ZXZvaXRAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZXZvaXRAY2lzY28u Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+QW5keSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlR3byB3ZWVr cyBhZ28gSSBwcm9taXNlZCBhIHVzZWZ1bCBZQU5HIG1vZGVsIHdoaWNoIGV4cG9zZXMgYm90aCBk ZXZpY2UgYW5kIGRvbWFpbiBjb25maWcuJm5ic3A7IFRoZSBtb2RlbCBpcyBoZXJlOjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBocmVmPSJodHRwOi8vd3d3LmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC10cmlwYXRoeS1jbG91ZC1zbGEteWFuZy1tb2RlbC0w MC50eHQiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC10cmlwYXRoeS1jbG91ZC1zbGEteWFuZy1tb2RlbC0wMC50eHQ8L2E+DQo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkEgc2ltcGxlIOKAnENsb3VkIFBvbGljZXLigJ0gYXBwbGlj YXRpb24gY2FuIHNpdCBjb21wbGV0ZWx5IHVwb24gdGhlIG1vZGVsLiZuYnNwOyBUaGUgYWxnb3Jp dGhtIG1pZ2h0IGJlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+KDEpIFRoZSBPcGVyYXRv ciBlbnRlcnMgYSBtYXhpbXVtIGRhdGEgcmF0ZSBhY3Jvc3MgYSBmZWRlcmF0aW9uIChDbG91ZCkg b2YgZGV2aWNlcw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4oMikgU3VtIHRoZSBjdXJy ZW50IGJhbmR3aWR0aCBhY3Jvc3MgdGhlIGNvbGxlY3Rpb24gb2YgZGV2aWNlcyBpbiB0aGUgZmVk ZXJhdGlvbiAodmlhIFJGQyA3MjIzIFlBTkcgZGV2aWNlIGludGVyZmFjZSBzdGF0aXN0aWNzKQ0K PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4oMykgUG9saWNlZCBCYW5kd2lkdGggcmF0ZSBl YWNoIGRldmljZSA9IChjdXJyZW50IHRyYWZmaWMgdG8gdGhlIGRldmljZSAvIGN1cnJlbnQgZmVk ZXJhdGlvbiB0cmFmZmljKSAqIE9wZXJhdG9yIGVzdGFibGlzaGVkIEZlZGVyYXRpb24gTWF4IHJh dGU8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1ib3R0b206 c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMS4wcHQgMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPig0KSBHbyBiYWNrIHRvIHN0ZXAgKDIpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5JZiB3ZSBzZXQgdGhlIGZlZGVyYXRpb24gYmFuZHdpZHRoIHRvIDEwME1CL3MsIGFuZCB0aGVu IHZhcnkgdGhlIG9mZmVyZWQgdG8gdHdvIGRldmljZXMsIHRoZSByZXN1bHQgbG9va3MgbGlrZSB0 aGlzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbHQ7aW1hZ2UwMDMu cG5nJmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+RWZmZWN0aXZlbHkgd2UgYXJlIHNo b3dpbmcgdGhlIGNvbmZpZyBvZiBkb21haW4gYW5kIGRldmljZSB1cG9uIG9uZSBncmFwaC4mbmJz cDsgQW5kIHRoZSBkZXZpY2UgY29uZmlnIGlzIHZhcnlpbmcgb3ZlciB0aW1lIGJhc2VkIG9uIFBl ZXIgTW91bnRlZCBSRkMgNzIyMyBZQU5HIGludGVyZmFjZSBzdGF0aXN0aWNzLiZuYnNwOw0KPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGlzIGlzIHJ1bm5pbmcgY29kZS4mbmJzcDsgVGhl IGNvZGUgaXMgcG9ydGFibGUgc28gdGhhdCBpdCBjYW4gcnVuIG9uIGEgY29udHJvbGxlciwgb3Ig aXQgY2FuIHJ1biB1cG9uIGEgZGVzaWduYXRlZCByb3V0ZXIgd2l0aGluIHRoZSBmZWRlcmF0aW9u LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9uJ3QgdGhpbmsgdGhlIGFwcGxpY2F0aW9uIG5lZWRzIFlB TkcgTW91bnQgdG8gYWNjb21wbGlzaCBpdHMgdGFzay48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCB0 aGUgaXNzdWUgb2YgZGV2aWNlLWNvbmZpZ3VyZWQgdnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5jb250cm9sbGVyLWNvbmZpZ3VyZWQgZGF0YSBj b2xsZWN0aW9uLiZuYnNwOyBBbnkgY29udHJvbGxlciBjYW4gY29sbGVjdCBzb21lIHN1YnRyZWVz PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5mcm9t IGVhY2ggZGV2aWNlIGFuZCB1c2UgdGhlIGRhdGEgc29tZWhvdy4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNw YW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyA8L3NwYW4+VGhlIHBvaW50IG9mIG1vdW50IGlzbuKAmXQgZm9yIHRoZSBjb250cm9sbGVy4oCZ cyBjb252ZW5pZW5jZSBwZXIgc2U7IGl0cyBmb3IgdGhlIGFwcCB0aGF0IHdhbnRzIHRvIGdldCBh dCB0aG9zZSBzdGF0cy4gVGhlIGFwcCBvbmx5IG5lZWRzIHRvIHRhbGsgdG8gYSBzaW5nbGUgY29u dHJvbGxlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNEY4 MUJEIj4mbHQ7RXJpYyZndDsmbmJzcDsgQWdyZWUuJm5ic3A7Jm5ic3A7IEl0IGlzICpwb3NzaWJs ZSogdG8gZG8gc29tZSBvZiB0aGlzIHdpdGggZXhpc3RpbmcgTmV0Y29uZi4mbmJzcDsgQnV0IGl0 IGdldHMgdWdseS4mbmJzcDsgQXBwbGljYXRpb24gZGV2ZWxvcGVycyBsb3NlIHRoZSBmb2xsb3dp bmcgYmVuZWZpdHM6DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzRGODFCRCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNv bG9yOiM0RjgxQkQiPkFwcGxpY2F0aW9uIFNpbXBsaWZpY2F0aW9uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM0RjgxQkQi PuKAoiBNYWpvciBjb2RlIHNpemUgcmVkdWN0aW9uIOKGkiBkYXRhIGFjY2VzcyBvbmx5IHRvIGxv Y2FsIERhdGFzdG9yZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojNEY4MUJEIj7igKIgQ2FjaGluZyBhbmQgcG9sbGluZyBi ZWNvbWVzIGhpZGRlbiBpbmZyYXN0cnVjdHVyZQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM0RjgxQkQiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxl PSJjb2xvcjojNEY4MUJEIj5BcHBsaWNhdGlvbiBSb2J1c3RuZXNzIDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojNEY4MUJE Ij7igKIgRGlzdHJpYnV0ZWQgWUFORyBvYmplY3RzIGF2YWlsYWJsZSB0byBhcHBsaWNhdGlvbnMg d2l0aG91dCBuZWVkaW5nIHRvIGFjcXVpcmUgdGhlIGRhdGEgdGhlbXNlbHZlczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjoj NEY4MUJEIj7igKIgQ2FuIHJ1biBiZXR3ZWVuIE5ldHdvcmsgRWxlbWVudHMsIHdoZXJlIHNvbWUg Y29udHJvbGxlcnMgYWxyZWFkeSByZXNpZGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzRGODFCRCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNv bG9yOiM0RjgxQkQiPkFwcGxpY2F0aW9uIFBlcmZvcm1hbmNlPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM0RjgxQkQiPuKA oiBPbi1jaGFuZ2UgJmFtcDsgUGVyaW9kaWMgb2JqZWN0IFB1Yi9TdWIgd2l0aCB0cmFuc3BhcmVu dCBjYWNoaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiM0RjgxQkQiPuKAoiBTY2FsaW5nIGJlbmVmaXRzOiBhYmlsaXR5 IHRvIGNhc2NhZGUgdXBkYXRlcyBhY3Jvc3MgbXVsdGlwbGUgdGllcnMgb2YgTW91bnQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29s b3I6IzRGODFCRCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM0RjgxQkQiPk1pc2NvbmZpZ3VyYXRpb24gVHlwZXMgRWxp bWluYXRlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJjb2xvcjojNEY4MUJEIj7igKIgQXV0aG9yaXRhdGl2ZSBjb3B5IGluIEZlZGVy YXRpb24gdHJhbnNwYXJlbnRseSB1c2VkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM0RjgxQkQiPuKAoiBNb3VudCAmYW1w OyBtb25pdG9yIHRoZSBhY3R1YWwgc3RhdGUgb2YgdGhlIG5ldHdvcmsgKGFwcHMgZG9u4oCZdCBq dXN0IGdldCBvbmUtdGltZSDigJxBQ0vigJ0pLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM0RjgxQkQiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojNEY4MUJEIj5JbiBvdGhlciB3b3Jkcywgd2UgYXJlIHRyeWluZyB0byBt YWtlIGxpZmUgZWFzaWVyIGZvciBBcHBsaWNhdGlvbiBEZXZlbG9wZXJzLiZuYnNwOyBFc3BlY2lh bGx5IGRldmVsb3BlcnMgb2YgYXBwbGljYXRpb25zIHdoaWNoIHNwYW4gZmVkZXJhdGlvbnMgb2Yg bmV0d29yayBkZXZpY2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNEY4MUJEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzRGODFCRCI+RXJpYzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KdXN0IHVzZSBO RVRDT05GIG9yPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5SRVNUQ09ORiBhcy1pcy4mbmJzcDsgSXQgcmVhbGx5IGNvbXBsaWNhdGVzIHRoZSBhcmNo aXRlY3R1cmUgdG8gdXNlIG1vdW50IHBvaW50cyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmVzcGVjaWFsbHkgaWYgZXZlcnkgY29udHJvbGxlciBp cyBnb2luZyB0byByZXBsaWNhdGUgZGF0YSBmcm9tIGV2ZXJ5IHNlcnZlciBpbjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZGlmZmVyZW50IHdheXMs IGFuZCBmb3JjZSB0aGUgZGV2aWNlcyB0byBkbyBhbGwgdGhlIHdvcmsuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPkl0IGNvbXBs aWNhdGVzIGl0IGZvciB0aGUgY29udHJvbGxlciBidXQgaGFzIHRoZSBhZHZhbnRhZ2Ugb2Ygc2lt cGxpZnlpbmcgaXQgZm9yIHBvdGVudGlhbGx5IG1hbnksIG1hbnkgbW9yZSBhcHBsaWNhdGlvbnMg dGhhdCByZWx5IG9uIHRoZSBjb250cm9sbGVy4oCZcyBhYnN0cmFjdGlvbiBvZiB0aGUgdW5pdmVy c2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj7igJRUb208bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItYm90dG9tOnNvbGlkIHdpbmRv d3RleHQgMS4wcHQ7cGFkZGluZzowaW4gMGluIDEuMHB0IDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Fcmlj PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItYm90dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4gMGluIDEuMHB0 IDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0 b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQW5keSBCaWVybWFuLCBPY3RvYmVyIDE0LCAy MDE0IDY6NDcNCiBQTTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZsdDtzbmlwJmd0Ozwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgZG8gbm90IGFncmVlIHRoYXQgdGhlICZxdW90O2NvbGxl Y3Rpb24gb2YgZGV2aWNlIG1vZGVscyZxdW90OyBpcyBhIHZlcnkgaW50ZXJlc3Rpbmcgc29sdXRp b248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Zm9yIG5ldHdvcmsgbWFu YWdlbWVudCBhdCB0aGUgbmV0d29yayBsZXZlbC4mbmJzcDsgV2UgaGF2ZSBkYWJibGVkIHdpdGgg JnF1b3Q7bmV0d29yay13aWRlJnF1b3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPmNvbmZpZ3VyYXRpb24gYSBjb3VwbGUgdGltZXMsIG9ubHkgdG8gZHJvcCB0aGUgaXNz dWUuJm5ic3A7IElNTyB0aGUgbW9kZWxzIGF0IHRoaXMgbGV2ZWw8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+ZGVzY3JpYmUgdGhlIG5ldHdvcmssIG5vdCB0aGUgZGV2aWNl cy4mbmJzcDsgVGhlcmUgaXMgc29tZSBnbHVlIHRoYXQgdGVsbHMgdGhlIGNvbnRyb2xsZXIgd2hh dCBkZXZpY2VzIGFyZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5hdmFp bGFibGUsIGFuZCBob3cgdG8gdGFsayB0byB0aGVtLCBidXQgdGhlIGdvYWwgaXMgdG8gaGFuZGxl IHRoZSBkZXZpY2UgbGV2ZWwgZGV0YWlsczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5hcyBwYXJ0IG9mIHRoZSBjb250cm9sbGVyIGRhdGEgbW9kZWwgaW1wbGVtZW50YXRp b24uJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+Jmx0O0VyaWMmZ3Q7IFdlIGhhdmUgYSBZQU5HIG1vZGVsIGZvciBDbG91ZCBQb2xp Y2VyIGFuZCBERG9TIFRocmVzaG9sZGluZyB3aGljaCBleHBvc2VzIHRoZSBpbnRlcnBsYXkgb2Yg ZG9tYWluIGFuZCBkZXZpY2Ugdmlldy4mbmJzcDsmbmJzcDsgSSB3aWxsIHN0cml2ZSB0byBnZXQg aXQNCiBwb3N0ZWQgYXMgYSBuZXcgZHJhZnQgYmVmb3JlIE9jdCAyN3RoLiZuYnNwOyAoSUVURiA5 MSBjdXQtb2ZmIGRhdGUuKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PkVyaWM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+RXJpYyBWb2l0PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzdGN0Y3RiI+UHJpbmNpcGFsIEVuZ2luZWVyIC0gQ1NHPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K bmV0bW9kIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmci Pm5ldG1vZEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL25ldG1vZCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9uZXRtb2Q8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_EF64FF31F4C4384DBCE5D513A791C2B120A5A8BDxmbalnx11ciscoc_-- From nobody Thu Oct 30 14:23:01 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E75E1A87E9 for ; Thu, 30 Oct 2014 14:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 LQaQyDm-pE3U for ; Thu, 30 Oct 2014 14:22:57 -0700 (PDT) Received: from mail-vc0-f179.google.com (mail-vc0-f179.google.com [209.85.220.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5E9E1A6FBA for ; Thu, 30 Oct 2014 14:22:56 -0700 (PDT) Received: by mail-vc0-f179.google.com with SMTP id ij19so3217247vcb.38 for ; Thu, 30 Oct 2014 14:22: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 :content-transfer-encoding; bh=wDOcqbqvlqH39EKPrZGum7VSRId9HzAWUoIHiDO46U0=; b=HgJo6gNMyQrAmO/jtc0vNgT+MEmdILTNaFHuNEInoQqknS+pmgYumcZ0gbqpJLWc8N ljn1nwZUb28OEkoKwHhGSFVVmWsZwq5MD+UWYr92jk6ifZoee0nklYpL0Yz7/PsvB3fR RnnsT7CUVbjC1fuiiSkx3pVWGxTWLv8AqmGxhY1cj+HaUiE43P/5I67sPngmr7vbwK6w JUOrI+8eB0KQBSqN/8Vaz4Us3BuDeKkdH4X+4lNL7w00VfR9iWLGreQ0OSojpQ0w3AKw 7Erq8cVjUdOedefYe1JFZIFvVumj//SGHANy5WU29Bjh8XqDJmgs/c34Qa7lEz/k5Piq vaTw== X-Gm-Message-State: ALoCoQlsFmRmSxrdYEH30lOVRzj6Z7Y6ttRBnjx/EZDiPOTXycpoZ43WGknvrJBWsEAbra46RaMk MIME-Version: 1.0 X-Received: by 10.52.111.33 with SMTP id if1mr1546757vdb.47.1414704175882; Thu, 30 Oct 2014 14:22:55 -0700 (PDT) Received: by 10.31.10.8 with HTTP; Thu, 30 Oct 2014 14:22:55 -0700 (PDT) In-Reply-To: References: Date: Thu, 30 Oct 2014 14:22:55 -0700 Message-ID: From: Andy Bierman To: "Eric Voit (evoit)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/U7nnCTNz3LPAPVGZzh0wznnIQeE Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG model containing both device and domain config (was RE: New revision of YANG mount draft) X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 30 Oct 2014 21:22:59 -0000 Hi, I guess you are not really understanding my point. I am concerned on the complexity pushed on the devices to somehow be configured to find each controller, register some data subtrees to mount, and then push data to each controller. I don't see that it saves work as much as moves it from a relatively small number of controllers to a large number of servers. Are operators going to configure the devices or are the controllers going to configure themselv= es in each server? Seems too complicated to me. I think the polling can be optimized (If-Match, If-Modified-Since, etc.). This approach (already in RESTCONF, but really only for config=3Dtrue) could be applied to operational state as well. There needs to be a minimum update interval or the controllers can get over= run with pushed data. IMO the controllers should be polling for changes at the rate they want data. If the operational state changes in someway that is interesting to the oper= ator, then the traditional approach of defining and sending a notification event works fine. Andy On Thu, Oct 30, 2014 at 1:48 PM, Eric Voit (evoit) wrote: > From: Thomas D. Nadeau, October 30, 2014 4:31 PM > > On Oct 30, 2014:4:17 PM, at 4:17 PM, Andy Bierman > wrote: > > > > On Thu, Oct 30, 2014 at 12:16 PM, Eric Voit (evoit) wro= te: > > Andy, > > > > Two weeks ago I promised a useful YANG model which exposes both device an= d > domain config. The model is here: > > http://www.ietf.org/internet-drafts/draft-tripathy-cloud-sla-yang-model-0= 0.txt > > > > A simple =E2=80=9CCloud Policer=E2=80=9D application can sit completely u= pon the model. The > algorithm might be: > > > > (1) The Operator enters a maximum data rate across a federation (Cloud) o= f > devices > > > > (2) Sum the current bandwidth across the collection of devices in the > federation (via RFC 7223 YANG device interface statistics) > > > > (3) Policed Bandwidth rate each device =3D (current traffic to the device= / > current federation traffic) * Operator established Federation Max rate > > > > (4) Go back to step (2) > > > > If we set the federation bandwidth to 100MB/s, and then vary the offered = to > two devices, the result looks like this. > > > > > > Effectively we are showing the config of domain and device upon one graph= . > And the device config is varying over time based on Peer Mounted RFC 7223 > YANG interface statistics. > > > > This is running code. The code is portable so that it can run on a > controller, or it can run upon a designated router within the federation. > > > > > > > > I don't think the application needs YANG Mount to accomplish its task. > > This has nothing to do with the issue of device-configured vs. > > controller-configured data collection. Any controller can collect some > subtrees > > from each device and use the data somehow. > > > > The point of mount isn=E2=80=99t for the controller=E2=80=99s c= onvenience per se; > its for the app that wants to get at those stats. The app only needs to t= alk > to a single controller. > > > > Agree. It is *possible* to do some of this with existing Netcon= f. > But it gets ugly. Application developers lose the following benefits: > > > > Application Simplification > > =E2=80=A2 Major code size reduction =E2=86=92 data access only to local D= atastore > > =E2=80=A2 Caching and polling becomes hidden infrastructure > > > > Application Robustness > > =E2=80=A2 Distributed YANG objects available to applications without need= ing to > acquire the data themselves > > =E2=80=A2 Can run between Network Elements, where some controllers alread= y reside > > > > Application Performance > > =E2=80=A2 On-change & Periodic object Pub/Sub with transparent caching > > =E2=80=A2 Scaling benefits: ability to cascade updates across multiple ti= ers of > Mount > > Misconfiguration Types Eliminated > > =E2=80=A2 Authoritative copy in Federation transparently used > > =E2=80=A2 Mount & monitor the actual state of the network (apps don=E2=80= =99t just get > one-time =E2=80=9CACK=E2=80=9D). > > In other words, we are trying to make life easier for Application > Developers. Especially developers of applications which span federations= of > network devices. > > > > Eric > > > > Just use NETCONF or > > RESTCONF as-is. It really complicates the architecture to use mount poin= ts, > > especially if every controller is going to replicate data from every serv= er > in > > different ways, and force the devices to do all the work. > > > > It complicates it for the controller but has the advantage of > simplifying it for potentially many, many more applications that rely on = the > controller=E2=80=99s abstraction of the universe. > > > > =E2=80=94Tom > > > > > > > > > > > > > > Eric > > > > > > Andy > > > > > > > > From: Andy Bierman, October 14, 2014 6:47 PM > > > > > > I do not agree that the "collection of device models" is a very interesti= ng > solution > > for network management at the network level. We have dabbled with > "network-wide" > > configuration a couple times, only to drop the issue. IMO the models at > this level > > describe the network, not the devices. There is some glue that tells the > controller what devices are > > available, and how to talk to them, but the goal is to handle the device > level details > > as part of the controller data model implementation. > > > > We have a YANG model for Cloud Policer and DDoS Thresholding which > exposes the interplay of domain and device view. I will strive to get i= t > posted as a new draft before Oct 27th. (IETF 91 cut-off date.) > > > > Eric > > > > > > > > > > Eric Voit > > Principal Engineer - CSG > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > From nobody Thu Oct 30 14:42:38 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 946501A8839 for ; Thu, 30 Oct 2014 14:42:36 -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, 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 DXKGPcGWcbp9 for ; Thu, 30 Oct 2014 14:42:34 -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 1FD921A8830 for ; Thu, 30 Oct 2014 14:42:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=HLR1bx9TCiyr+FjP4h+mMAHa9w6O7gz9M8jDI0kKUg/ajkC5rnDlaiAd2XirDG4E; 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.51] (helo=mswamui-thinleaf.atl.sa.earthlink.net) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1XjxUG-0000T4-EB for netmod@ietf.org; Thu, 30 Oct 2014 17:42:32 -0400 Received: from 76.254.54.88 by webmail.earthlink.net with HTTP; Thu, 30 Oct 2014 17:42:32 -0400 Message-ID: <32898127.1414705352290.JavaMail.root@mswamui-thinleaf.atl.sa.earthlink.net> Date: Thu, 30 Oct 2014 14:42:32 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88825aa8a2065c9591f6ee8fa65f107fe8bfd2cf0ca54047aec350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.51 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/1jnwh1HJgDS3pCpb3EuOjpDNxh8 Subject: Re: [netmod] yang 1.1 webex on wednesday october 29th 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, 30 Oct 2014 21:42:36 -0000 Hi - >From: Martin Bjorklund >Sent: Oct 30, 2014 1:14 AM >To: randy_presuhn@mindspring.com >Cc: netmod@ietf.org >Subject: Re: [netmod] yang 1.1 webex on wednesday october 29th > >Randy Presuhn wrote: >> Hi - >> >> >From: Andy Bierman >> >Sent: Oct 29, 2014 5:04 PM >> >To: Juergen Schoenwaelder , Andy Bierman , "netmod@ietf.org" >> >Subject: Re: [netmod] yang 1.1 webex on wednesday october 29th >> ... >> >None of the SNMP server code I worked on supported multiple revisions >> >of any module in the agent. There was 1 module loaded for each module name. >> >SMIv2 has no way to import a specific revision of a definition. >> >> FWIW, though, it's really easy to support this in systems using >> subagent technology, in part due to the SMI's restrictive rules >> for revising modules. It's not terribly likely in single vendor >> single processor boxes where all the firmware is kept in synch. >> In "open" systems, and ones in which subagent soft/firmware >> resides on more-or-less independently updated line cards or similar >> modules, it can very easily happen. Coping with this gracefully >> is one of the big plusses of subagent technologies. > >I don't think the subagent mechanism solves the problem. Suppose you >have a column in some table in v1 of a MIB. In v2 this column's >syntax has an expanded range. Prohibited by SMIv2's extensibility rules, except for the very special cases of adding BITS or enumerations. See RFC 2578 section 10.2. But anyway... > Now, suppose subagent A implements v1 >of the MIB, and registers for one row in the table, and subagent B >implements v2 of the MIB and registers for another row. How does the >SNMP manager know which instances of column C support the new values >introduced in v2, and which don't? In SNMP, in general and independently of whether subagent technologies are in play, the manager doesn't know whether an attempt to set something to a particular value will succeed until a response arrives from the agent indicating success or failure, or it decides that no response is coming. When there are multiple instances of an object, success or failure attempting to set one instance generally doesn't give the manager reliable information about the likelihood of success or failure for any other instance. One *could* use smuxPidentity or agentxSessionObjectID to point to AGENT-CAPABILITIES statements, but I'm not aware of anyone bothering to do much of anything with that information. I guess that's largely because building robust SNMP management applications requires tolerating / working around managed systems' sometimes enigmatic refusals to do what they are told, and adding version-specific logic would add complexity without commensurate value. Randy From nobody Thu Oct 30 14:58:46 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53D781A8848 for ; Thu, 30 Oct 2014 14:58:45 -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 IegFHlPsN50k for ; Thu, 30 Oct 2014 14:58:43 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0911A8840 for ; Thu, 30 Oct 2014 14:58:43 -0700 (PDT) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 2922E12801AB; Thu, 30 Oct 2014 22:58:42 +0100 (CET) Date: Thu, 30 Oct 2014 22:58:41 +0100 (CET) Message-Id: <20141030.225841.372086162.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <32898127.1414705352290.JavaMail.root@mswamui-thinleaf.atl.sa.earthlink.net> References: <32898127.1414705352290.JavaMail.root@mswamui-thinleaf.atl.sa.earthlink.net> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/G1gIKxSHtTc86-PdAldO_dQlxRo Cc: netmod@ietf.org Subject: Re: [netmod] yang 1.1 webex on wednesday october 29th X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 30 Oct 2014 21:58:45 -0000 Randy Presuhn wrote: > Hi - > > >From: Martin Bjorklund > >Sent: Oct 30, 2014 1:14 AM > >To: randy_presuhn@mindspring.com > >Cc: netmod@ietf.org > >Subject: Re: [netmod] yang 1.1 webex on wednesday october 29th > > > >Randy Presuhn wrote: > >> Hi - > >> > >> >From: Andy Bierman > >> >Sent: Oct 29, 2014 5:04 PM > >> >To: Juergen Schoenwaelder , Andy > >> >Bierman , "netmod@ietf.org" > >> >Subject: Re: [netmod] yang 1.1 webex on wednesday october 29th > >> ... > >> >None of the SNMP server code I worked on supported multiple revisions > >> >of any module in the agent. There was 1 module loaded for each module > >> >name. > >> >SMIv2 has no way to import a specific revision of a definition. > >> > >> FWIW, though, it's really easy to support this in systems using > >> subagent technology, in part due to the SMI's restrictive rules > >> for revising modules. It's not terribly likely in single vendor > >> single processor boxes where all the firmware is kept in synch. > >> In "open" systems, and ones in which subagent soft/firmware > >> resides on more-or-less independently updated line cards or similar > >> modules, it can very easily happen. Coping with this gracefully > >> is one of the big plusses of subagent technologies. > > > >I don't think the subagent mechanism solves the problem. Suppose you > >have a column in some table in v1 of a MIB. In v2 this column's > >syntax has an expanded range. > > Prohibited by SMIv2's extensibility rules, except for the > very special cases of adding BITS or enumerations. ... and thus is not prohibited. I should have been more explicit: Suppose you have an enumeration column in some table in v1 of a MIB. In v2 this column's syntax has an expanded range. > > Now, suppose subagent A implements v1 > >of the MIB, and registers for one row in the table, and subagent B > >implements v2 of the MIB and registers for another row. How does the > >SNMP manager know which instances of column C support the new values > >introduced in v2, and which don't? > > In SNMP, in general and independently of whether subagent technologies > are in play, the manager doesn't know whether an attempt to set > something to a particular value will succeed until a response > arrives from the agent indicating success or failure, or it > decides that no response is coming. When there are multiple > instances of an object, success or failure attempting > to set one instance generally doesn't give the manager reliable > information about the likelihood of success or failure for any other > instance. > > One *could* use smuxPidentity or agentxSessionObjectID > to point to AGENT-CAPABILITIES statements, but I'm not > aware of anyone bothering to do much of anything with that > information. I guess that's largely because building robust > SNMP management applications requires tolerating / working > around managed systems' sometimes enigmatic refusals to > do what they are told, and adding version-specific logic > would add complexity without commensurate value. My point was that your statement: it's really easy to support this in systems using subagent technology, isn't quite correct. It seems you are saying that a manager cannot really know what to expect from the agent. Of course, as Andy noted, things are simpler when we're doing monitoring rather than configuration. /martin From nobody Thu Oct 30 17:17:55 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDC431A8A16 for ; Thu, 30 Oct 2014 17:17:37 -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 XeP4IlQzHsxh for ; Thu, 30 Oct 2014 17:17:34 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FD231A8A20 for ; Thu, 30 Oct 2014 17:17:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10452; q=dns/txt; s=iport; t=1414714647; x=1415924247; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=qX2Y8CS/eY+Oi/5z/W2wynOvJdVZZ2bBHXnBmnKytUk=; b=iMvzRsYC+0lkhB9anWar0oe6E8+HxVLvubfUHHtnDyEzWB9DrloEvdXy Wlrm04yu0npaVT9t86/7m0W5/s94yOl3Tya9zNQp1fKKe43ahii/VhZlj XIoDcXRhxvFFhw7yoCrRzjGLGWESf5rcCC4e6ljgTu2SmZS9kH0FMe7Zu s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al0GAJDUUlStJA2G/2dsb2JhbABcgw5UWASDAsoPCoZ5VAIcgQkWAQEBAQF9hAIBAQEEAQEBIBE6CwwEAgEIEQEDAQEBAgIGAhcEAwICAiULFAECBggBAQQBDQUIARACiCYNtVmUbgEBAQEBAQEBAQEBAQEBAQEBAQEBAReBLI8MJgYrBwQCgnE2gR4FkhCNEY1mhy2CNIFEbIEHQYEDAQEB X-IronPort-AV: E=Sophos;i="5.07,290,1413244800"; d="scan'208";a="91930407" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-3.cisco.com with ESMTP; 31 Oct 2014 00:17:26 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s9V0HQ8w020176 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 Oct 2014 00:17:26 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.195]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Thu, 30 Oct 2014 19:17:25 -0500 From: "Alexander Clemm (alex)" To: Andy Bierman , "Eric Voit (evoit)" Thread-Topic: [netmod] YANG model containing both device and domain config (was RE: New revision of YANG mount draft) Thread-Index: Ac/0dgOg0IIxE7lQS6W0YT3SwyQ17gAMn0yAAAB4jQAAAJgkgAABNCiAAATV4OA= Date: Fri, 31 Oct 2014 00:17:25 +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: [10.21.85.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/llCEJyEho3rgMHVKNLPVOlwZx3E Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG model containing both device and domain config (was RE: New revision of YANG mount draft) X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 31 Oct 2014 00:17:37 -0000 SGkgQW5keSwNCg0KY29udHJvbGxlcnMgLyBtb3VudCBjbGllbnRzIGhhdmUgdGhlIG9wdGlvbiB0 byBzdWJzY3JpYmUgdG8gdXBkYXRlcyBpbiBhbnkgd2F5IHRoZXkgZGVlbSBmaXQuICBJbiBmYWN0 LCBvbi1kZW1hbmQgd2lsbCB1c3VhbGx5IGJlIHRoZSBkZWZhdWx0LiAgUG9sbGluZyBvcHRpbWl6 YXRpb25zIGFsb25nIHRoZSBsaW5lcyB0aGF0IHlvdSBzdWdnZXN0IChpZi1tb2RpZmllZC1zaW5j ZSkgbWFrZSBzZW5zZSBhcyB3ZWxsLCBhbHRob3VnaCBwcmVzdW1hYmx5IGFkZGluZyBjb21wbGV4 aXR5IHRvIHRoZSBzZXJ2ZXIgaW1wbGVtZW50YXRpb24gYXMgd2VsbC4gIA0KDQpGb3IgcHVzaGlu ZyBkYXRhLCBpdCBpcyBkZWZpbml0ZWx5IGNvbmNlaXZhYmxlIHRvIGFkZCBhIHRocm90dGxlIG1l Y2hhbmlzbSB0aGF0IHRoZSBjbGllbnQgY2FuIHVzZS4gIFRoZSBzaW1wbGVzdCBtZWNoYW5pc20g b2YgY291cnNlIGlzIHRvIGRpbWVuc2lvbiB0aGUgbWluaW11bSBpbnRlcnZhbCBiZXR3ZWVuIHVw ZGF0ZXMgYXMgbmVlZGVkLiAgDQoNClRvIGFkZCB0byB0aGUgRXJpYydzIGVhcmxpZXIgcG9pbnQs IHRoZSBpc3N1ZSBpcyBub3QgdGhhdCB5b3UgY291bGQgbm90IGFjaGlldmUgdGhlIHNhbWUgYXBw bGljYXRpb24gZ29pbmcgdG8gdGhlIGRpZmZlcmVudCBkZXZpY2VzIGRpcmVjdGx5LiAgVGhlIGlz c3VlIGlzIHRoYXQgaW4gdGhhdCBjYXNlIHlvdSBwdXNoIHRoZSBjb21wbGV4aXR5IHRvIHRoZSBh cHBsaWNhdGlvbiBkZXZlbG9wZXIgb2YgaGF2aW5nIHRvIGRlYWwgd2l0aCB0aGUgY29tcGxleGl0 eSBvZiBkZWFsaW5nIHdpdGggZWFjaCBkZXZpY2UgaW5kaXZpZHVhbGx5LiAgTm90IGV2ZXJ5IHN5 c3RlbSBtYXkgc3VwcG9ydCBtb3VudCBwb2ludHMsIGp1c3QgbGlrZSBub3QgZXZlcnkgc3lzdGVt IG1heSBzdXBwb3J0IGFueSBvdGhlciBZQU5HIG1vZHVsZS4gIEJ1dCB3aHkgbGltaXQgdGhvc2Ug dGhhdCBhcmUgYWJsZSB0byBzdXBwb3J0IGl0IGZyb20gZG9pbmcgc28sIGluIHBhcnRpY3VsYXIg YXMgdGhlcmUgYXJlIGNsZWFybHkgYXBwbGljYXRpb25zIGFuZCBkZXBsb3ltZW50IHNjZW5hcmlv cyB3aGVyZSB0aGlzIGlzIG5lZWRlZCBhbmQgbWFrZXMgc2Vuc2UuICAgIA0KDQotLS0gQWxleA0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbmV0bW9kIFttYWlsdG86bmV0bW9k LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbmR5IEJpZXJtYW4NClNlbnQ6IFRodXJz ZGF5LCBPY3RvYmVyIDMwLCAyMDE0IDI6MjMgUE0NClRvOiBFcmljIFZvaXQgKGV2b2l0KQ0KQ2M6 IG5ldG1vZEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtuZXRtb2RdIFlBTkcgbW9kZWwgY29udGFp bmluZyBib3RoIGRldmljZSBhbmQgZG9tYWluIGNvbmZpZyAod2FzIFJFOiBOZXcgcmV2aXNpb24g b2YgWUFORyBtb3VudCBkcmFmdCkNCg0KSGksDQoNCkkgZ3Vlc3MgeW91IGFyZSBub3QgcmVhbGx5 IHVuZGVyc3RhbmRpbmcgbXkgcG9pbnQuDQpJIGFtIGNvbmNlcm5lZCBvbiB0aGUgY29tcGxleGl0 eSBwdXNoZWQgb24gdGhlIGRldmljZXMgdG8gc29tZWhvdyBiZSBjb25maWd1cmVkIHRvIGZpbmQg ZWFjaCBjb250cm9sbGVyLCByZWdpc3RlciBzb21lIGRhdGEgc3VidHJlZXMgdG8gbW91bnQsIGFu ZCB0aGVuIHB1c2ggZGF0YSB0byBlYWNoIGNvbnRyb2xsZXIuDQoNCkkgZG9uJ3Qgc2VlIHRoYXQg aXQgc2F2ZXMgd29yayBhcyBtdWNoIGFzIG1vdmVzIGl0IGZyb20gYSByZWxhdGl2ZWx5IHNtYWxs IG51bWJlciBvZiBjb250cm9sbGVycyB0byBhIGxhcmdlIG51bWJlciBvZiBzZXJ2ZXJzLiAgQXJl IG9wZXJhdG9ycyBnb2luZyB0byBjb25maWd1cmUgdGhlIGRldmljZXMgb3IgYXJlIHRoZSBjb250 cm9sbGVycyBnb2luZyB0byBjb25maWd1cmUgdGhlbXNlbHZlcyBpbiBlYWNoIHNlcnZlcj8gU2Vl bXMgdG9vIGNvbXBsaWNhdGVkIHRvIG1lLg0KDQpJIHRoaW5rIHRoZSBwb2xsaW5nIGNhbiBiZSBv cHRpbWl6ZWQgKElmLU1hdGNoLCBJZi1Nb2RpZmllZC1TaW5jZSwgZXRjLikuDQpUaGlzIGFwcHJv YWNoIChhbHJlYWR5IGluIFJFU1RDT05GLCBidXQgcmVhbGx5IG9ubHkgZm9yIGNvbmZpZz10cnVl KSBjb3VsZCBiZSBhcHBsaWVkIHRvIG9wZXJhdGlvbmFsIHN0YXRlIGFzIHdlbGwuDQoNClRoZXJl IG5lZWRzIHRvIGJlIGEgbWluaW11bSB1cGRhdGUgaW50ZXJ2YWwgb3IgdGhlIGNvbnRyb2xsZXJz IGNhbiBnZXQgb3ZlcnJ1biB3aXRoIHB1c2hlZCBkYXRhLiAgSU1PIHRoZSBjb250cm9sbGVycyBz aG91bGQgYmUgcG9sbGluZyBmb3IgY2hhbmdlcyBhdCB0aGUgcmF0ZSB0aGV5IHdhbnQgZGF0YS4N Cg0KSWYgdGhlIG9wZXJhdGlvbmFsIHN0YXRlIGNoYW5nZXMgaW4gc29tZXdheSB0aGF0IGlzIGlu dGVyZXN0aW5nIHRvIHRoZSBvcGVyYXRvciwgdGhlbiB0aGUgdHJhZGl0aW9uYWwgYXBwcm9hY2gg b2YgZGVmaW5pbmcgYW5kIHNlbmRpbmcgYSBub3RpZmljYXRpb24gZXZlbnQgd29ya3MgZmluZS4N Cg0KDQpBbmR5DQoNCg0KDQoNCg0KT24gVGh1LCBPY3QgMzAsIDIwMTQgYXQgMTo0OCBQTSwgRXJp YyBWb2l0IChldm9pdCkgPGV2b2l0QGNpc2NvLmNvbT4gd3JvdGU6DQo+IEZyb206IFRob21hcyBE LiBOYWRlYXUsIE9jdG9iZXIgMzAsIDIwMTQgNDozMSBQTQ0KPg0KPiBPbiBPY3QgMzAsIDIwMTQ6 NDoxNyBQTSwgYXQgNDoxNyBQTSwgQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+DQo+ IHdyb3RlOg0KPg0KPg0KPg0KPiBPbiBUaHUsIE9jdCAzMCwgMjAxNCBhdCAxMjoxNiBQTSwgRXJp YyBWb2l0IChldm9pdCkgPGV2b2l0QGNpc2NvLmNvbT4gd3JvdGU6DQo+DQo+IEFuZHksDQo+DQo+ DQo+DQo+IFR3byB3ZWVrcyBhZ28gSSBwcm9taXNlZCBhIHVzZWZ1bCBZQU5HIG1vZGVsIHdoaWNo IGV4cG9zZXMgYm90aCBkZXZpY2UgDQo+IGFuZCBkb21haW4gY29uZmlnLiAgVGhlIG1vZGVsIGlz IGhlcmU6DQo+DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXRy aXBhdGh5LWNsb3VkLXNsYS15YW5nLW1vZGUNCj4gbC0wMC50eHQNCj4NCj4NCj4NCj4gQSBzaW1w bGUg4oCcQ2xvdWQgUG9saWNlcuKAnSBhcHBsaWNhdGlvbiBjYW4gc2l0IGNvbXBsZXRlbHkgdXBv biB0aGUgDQo+IG1vZGVsLiAgVGhlIGFsZ29yaXRobSBtaWdodCBiZToNCj4NCj4NCj4NCj4gKDEp IFRoZSBPcGVyYXRvciBlbnRlcnMgYSBtYXhpbXVtIGRhdGEgcmF0ZSBhY3Jvc3MgYSBmZWRlcmF0 aW9uIA0KPiAoQ2xvdWQpIG9mIGRldmljZXMNCj4NCj4NCj4NCj4gKDIpIFN1bSB0aGUgY3VycmVu dCBiYW5kd2lkdGggYWNyb3NzIHRoZSBjb2xsZWN0aW9uIG9mIGRldmljZXMgaW4gdGhlIA0KPiBm ZWRlcmF0aW9uICh2aWEgUkZDIDcyMjMgWUFORyBkZXZpY2UgaW50ZXJmYWNlIHN0YXRpc3RpY3Mp DQo+DQo+DQo+DQo+ICgzKSBQb2xpY2VkIEJhbmR3aWR0aCByYXRlIGVhY2ggZGV2aWNlID0gKGN1 cnJlbnQgdHJhZmZpYyB0byB0aGUgDQo+IGRldmljZSAvIGN1cnJlbnQgZmVkZXJhdGlvbiB0cmFm ZmljKSAqIE9wZXJhdG9yIGVzdGFibGlzaGVkIEZlZGVyYXRpb24gDQo+IE1heCByYXRlDQo+DQo+ DQo+DQo+ICg0KSBHbyBiYWNrIHRvIHN0ZXAgKDIpDQo+DQo+DQo+DQo+IElmIHdlIHNldCB0aGUg ZmVkZXJhdGlvbiBiYW5kd2lkdGggdG8gMTAwTUIvcywgYW5kIHRoZW4gdmFyeSB0aGUgDQo+IG9m ZmVyZWQgdG8gdHdvIGRldmljZXMsIHRoZSByZXN1bHQgbG9va3MgbGlrZSB0aGlzLg0KPg0KPiA8 aW1hZ2UwMDMucG5nPg0KPg0KPg0KPg0KPiBFZmZlY3RpdmVseSB3ZSBhcmUgc2hvd2luZyB0aGUg Y29uZmlnIG9mIGRvbWFpbiBhbmQgZGV2aWNlIHVwb24gb25lIGdyYXBoLg0KPiBBbmQgdGhlIGRl dmljZSBjb25maWcgaXMgdmFyeWluZyBvdmVyIHRpbWUgYmFzZWQgb24gUGVlciBNb3VudGVkIFJG QyANCj4gNzIyMyBZQU5HIGludGVyZmFjZSBzdGF0aXN0aWNzLg0KPg0KPg0KPg0KPiBUaGlzIGlz IHJ1bm5pbmcgY29kZS4gIFRoZSBjb2RlIGlzIHBvcnRhYmxlIHNvIHRoYXQgaXQgY2FuIHJ1biBv biBhIA0KPiBjb250cm9sbGVyLCBvciBpdCBjYW4gcnVuIHVwb24gYSBkZXNpZ25hdGVkIHJvdXRl ciB3aXRoaW4gdGhlIGZlZGVyYXRpb24uDQo+DQo+DQo+DQo+DQo+DQo+DQo+DQo+IEkgZG9uJ3Qg dGhpbmsgdGhlIGFwcGxpY2F0aW9uIG5lZWRzIFlBTkcgTW91bnQgdG8gYWNjb21wbGlzaCBpdHMg dGFzay4NCj4NCj4gVGhpcyBoYXMgbm90aGluZyB0byBkbyB3aXRoIHRoZSBpc3N1ZSBvZiBkZXZp Y2UtY29uZmlndXJlZCB2cy4NCj4NCj4gY29udHJvbGxlci1jb25maWd1cmVkIGRhdGEgY29sbGVj dGlvbi4gIEFueSBjb250cm9sbGVyIGNhbiBjb2xsZWN0IA0KPiBzb21lIHN1YnRyZWVzDQo+DQo+ IGZyb20gZWFjaCBkZXZpY2UgYW5kIHVzZSB0aGUgZGF0YSBzb21laG93Lg0KPg0KPg0KPg0KPiAg ICAgICAgICAgVGhlIHBvaW50IG9mIG1vdW50IGlzbuKAmXQgZm9yIHRoZSBjb250cm9sbGVy4oCZ cyBjb252ZW5pZW5jZSANCj4gcGVyIHNlOyBpdHMgZm9yIHRoZSBhcHAgdGhhdCB3YW50cyB0byBn ZXQgYXQgdGhvc2Ugc3RhdHMuIFRoZSBhcHAgb25seSANCj4gbmVlZHMgdG8gdGFsayB0byBhIHNp bmdsZSBjb250cm9sbGVyLg0KPg0KPg0KPg0KPiA8RXJpYz4gIEFncmVlLiAgIEl0IGlzICpwb3Nz aWJsZSogdG8gZG8gc29tZSBvZiB0aGlzIHdpdGggZXhpc3RpbmcgTmV0Y29uZi4NCj4gQnV0IGl0 IGdldHMgdWdseS4gIEFwcGxpY2F0aW9uIGRldmVsb3BlcnMgbG9zZSB0aGUgZm9sbG93aW5nIGJl bmVmaXRzOg0KPg0KPg0KPg0KPiBBcHBsaWNhdGlvbiBTaW1wbGlmaWNhdGlvbg0KPg0KPiDigKIg TWFqb3IgY29kZSBzaXplIHJlZHVjdGlvbiDihpIgZGF0YSBhY2Nlc3Mgb25seSB0byBsb2NhbCBE YXRhc3RvcmUNCj4NCj4g4oCiIENhY2hpbmcgYW5kIHBvbGxpbmcgYmVjb21lcyBoaWRkZW4gaW5m cmFzdHJ1Y3R1cmUNCj4NCj4NCj4NCj4gQXBwbGljYXRpb24gUm9idXN0bmVzcw0KPg0KPiDigKIg RGlzdHJpYnV0ZWQgWUFORyBvYmplY3RzIGF2YWlsYWJsZSB0byBhcHBsaWNhdGlvbnMgd2l0aG91 dCBuZWVkaW5nIA0KPiB0byBhY3F1aXJlIHRoZSBkYXRhIHRoZW1zZWx2ZXMNCj4NCj4g4oCiIENh biBydW4gYmV0d2VlbiBOZXR3b3JrIEVsZW1lbnRzLCB3aGVyZSBzb21lIGNvbnRyb2xsZXJzIGFs cmVhZHkgDQo+IHJlc2lkZQ0KPg0KPg0KPg0KPiBBcHBsaWNhdGlvbiBQZXJmb3JtYW5jZQ0KPg0K PiDigKIgT24tY2hhbmdlICYgUGVyaW9kaWMgb2JqZWN0IFB1Yi9TdWIgd2l0aCB0cmFuc3BhcmVu dCBjYWNoaW5nDQo+DQo+IOKAoiBTY2FsaW5nIGJlbmVmaXRzOiBhYmlsaXR5IHRvIGNhc2NhZGUg dXBkYXRlcyBhY3Jvc3MgbXVsdGlwbGUgdGllcnMgDQo+IG9mIE1vdW50DQo+DQo+IE1pc2NvbmZp Z3VyYXRpb24gVHlwZXMgRWxpbWluYXRlZA0KPg0KPiDigKIgQXV0aG9yaXRhdGl2ZSBjb3B5IGlu IEZlZGVyYXRpb24gdHJhbnNwYXJlbnRseSB1c2VkDQo+DQo+IOKAoiBNb3VudCAmIG1vbml0b3Ig dGhlIGFjdHVhbCBzdGF0ZSBvZiB0aGUgbmV0d29yayAoYXBwcyBkb27igJl0IGp1c3QgZ2V0IA0K PiBvbmUtdGltZSDigJxBQ0vigJ0pLg0KPg0KPiBJbiBvdGhlciB3b3Jkcywgd2UgYXJlIHRyeWlu ZyB0byBtYWtlIGxpZmUgZWFzaWVyIGZvciBBcHBsaWNhdGlvbiANCj4gRGV2ZWxvcGVycy4gIEVz cGVjaWFsbHkgZGV2ZWxvcGVycyBvZiBhcHBsaWNhdGlvbnMgd2hpY2ggc3BhbiANCj4gZmVkZXJh dGlvbnMgb2YgbmV0d29yayBkZXZpY2VzLg0KPg0KPg0KPg0KPiBFcmljDQo+DQo+DQo+DQo+IEp1 c3QgdXNlIE5FVENPTkYgb3INCj4NCj4gUkVTVENPTkYgYXMtaXMuICBJdCByZWFsbHkgY29tcGxp Y2F0ZXMgdGhlIGFyY2hpdGVjdHVyZSB0byB1c2UgbW91bnQgDQo+IHBvaW50cywNCj4NCj4gZXNw ZWNpYWxseSBpZiBldmVyeSBjb250cm9sbGVyIGlzIGdvaW5nIHRvIHJlcGxpY2F0ZSBkYXRhIGZy b20gZXZlcnkgDQo+IHNlcnZlciBpbg0KPg0KPiBkaWZmZXJlbnQgd2F5cywgYW5kIGZvcmNlIHRo ZSBkZXZpY2VzIHRvIGRvIGFsbCB0aGUgd29yay4NCj4NCj4NCj4NCj4gICAgICAgICAgIEl0IGNv bXBsaWNhdGVzIGl0IGZvciB0aGUgY29udHJvbGxlciBidXQgaGFzIHRoZSBhZHZhbnRhZ2UgDQo+ IG9mIHNpbXBsaWZ5aW5nIGl0IGZvciBwb3RlbnRpYWxseSBtYW55LCBtYW55IG1vcmUgYXBwbGlj YXRpb25zIHRoYXQgDQo+IHJlbHkgb24gdGhlIGNvbnRyb2xsZXLigJlzIGFic3RyYWN0aW9uIG9m IHRoZSB1bml2ZXJzZS4NCj4NCj4NCj4NCj4gICAgICAgICAgIOKAlFRvbQ0KPg0KPg0KPg0KPg0K Pg0KPg0KPg0KPg0KPg0KPg0KPg0KPg0KPg0KPiBFcmljDQo+DQo+DQo+DQo+DQo+DQo+IEFuZHkN Cj4NCj4NCj4NCj4NCj4NCj4NCj4NCj4gRnJvbTogQW5keSBCaWVybWFuLCBPY3RvYmVyIDE0LCAy MDE0IDY6NDcgUE0NCj4NCj4gPHNuaXA+DQo+DQo+DQo+DQo+IEkgZG8gbm90IGFncmVlIHRoYXQg dGhlICJjb2xsZWN0aW9uIG9mIGRldmljZSBtb2RlbHMiIGlzIGEgdmVyeSANCj4gaW50ZXJlc3Rp bmcgc29sdXRpb24NCj4NCj4gZm9yIG5ldHdvcmsgbWFuYWdlbWVudCBhdCB0aGUgbmV0d29yayBs ZXZlbC4gIFdlIGhhdmUgZGFiYmxlZCB3aXRoIA0KPiAibmV0d29yay13aWRlIg0KPg0KPiBjb25m aWd1cmF0aW9uIGEgY291cGxlIHRpbWVzLCBvbmx5IHRvIGRyb3AgdGhlIGlzc3VlLiAgSU1PIHRo ZSBtb2RlbHMgDQo+IGF0IHRoaXMgbGV2ZWwNCj4NCj4gZGVzY3JpYmUgdGhlIG5ldHdvcmssIG5v dCB0aGUgZGV2aWNlcy4gIFRoZXJlIGlzIHNvbWUgZ2x1ZSB0aGF0IHRlbGxzIA0KPiB0aGUgY29u dHJvbGxlciB3aGF0IGRldmljZXMgYXJlDQo+DQo+IGF2YWlsYWJsZSwgYW5kIGhvdyB0byB0YWxr IHRvIHRoZW0sIGJ1dCB0aGUgZ29hbCBpcyB0byBoYW5kbGUgdGhlIA0KPiBkZXZpY2UgbGV2ZWwg ZGV0YWlscw0KPg0KPiBhcyBwYXJ0IG9mIHRoZSBjb250cm9sbGVyIGRhdGEgbW9kZWwgaW1wbGVt ZW50YXRpb24uDQo+DQo+DQo+DQo+IDxFcmljPiBXZSBoYXZlIGEgWUFORyBtb2RlbCBmb3IgQ2xv dWQgUG9saWNlciBhbmQgRERvUyBUaHJlc2hvbGRpbmcgd2hpY2gNCj4gZXhwb3NlcyB0aGUgaW50 ZXJwbGF5IG9mIGRvbWFpbiBhbmQgZGV2aWNlIHZpZXcuICAgSSB3aWxsIHN0cml2ZSB0byBnZXQg aXQNCj4gcG9zdGVkIGFzIGEgbmV3IGRyYWZ0IGJlZm9yZSBPY3QgMjd0aC4gIChJRVRGIDkxIGN1 dC1vZmYgZGF0ZS4pDQo+DQo+DQo+DQo+IEVyaWMNCj4NCj4NCj4NCj4NCj4NCj4NCj4NCj4NCj4N Cj4gRXJpYyBWb2l0DQo+DQo+IFByaW5jaXBhbCBFbmdpbmVlciAtIENTRw0KPg0KPg0KPg0KPg0K Pg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBu ZXRtb2QgbWFpbGluZyBsaXN0DQo+IG5ldG1vZEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPg0KPg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9k QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0K From nobody Thu Oct 30 17:41:57 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2611A8A1A for ; Thu, 30 Oct 2014 17:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 Yc0Eyb1kDec7 for ; Thu, 30 Oct 2014 17:41:52 -0700 (PDT) Received: from mail-qg0-f54.google.com (mail-qg0-f54.google.com [209.85.192.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 938D71A8A1B for ; Thu, 30 Oct 2014 17:41:52 -0700 (PDT) Received: by mail-qg0-f54.google.com with SMTP id q108so4952360qgd.13 for ; Thu, 30 Oct 2014 17:41: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 :content-transfer-encoding; bh=CyvfrL17YPJ6Dl+gPO0GOrB2hjieZHjWkFQ3dGj7irw=; b=KpEBdpN81Q58zGJ5znqJzrIol0Q1bR1XbIjZuMTrRNIm4bhngkNQraxWto7LmfiDwG aodJVK3YiiDl0UcMz0g3+bVAjxvTf83DrHxX0nCrXg+lYdTR4fE8NVZviBGaUxH/pDpp NDcfzsbXyKuZoZ4TFlISPUxP6iCjWyJI9mnx4imQm0EfSyTJmyrQfqsGc6bJhdOcajEF jQy0qX3EZwDv41W/TAhWe0npTinRwaVPAuKRgkdQvAEbFbuzeO+Aua+zTYRblHCUEdpb eDyYA4FoTZOEqngRubTrJskKZN9J/o056quu6VFcz0OWb4UraMMIWiNGgczoxcqXiinJ Xt2A== X-Gm-Message-State: ALoCoQm0dk19dc/Epvwiep0LvfcDZi049YwW4OLn2D2jNMbCXC9aP9ieSmwAPD8piYaE1M9bk2g3 MIME-Version: 1.0 X-Received: by 10.224.132.70 with SMTP id a6mr31453426qat.16.1414716111736; Thu, 30 Oct 2014 17:41:51 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Thu, 30 Oct 2014 17:41:51 -0700 (PDT) In-Reply-To: References: Date: Thu, 30 Oct 2014 17:41:51 -0700 Message-ID: From: Andy Bierman To: "Alexander Clemm (alex)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/zO01adl0tv7f71KwITd0Izsj790 Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG model containing both device and domain config (was RE: New revision of YANG mount draft) X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 31 Oct 2014 00:41:55 -0000 On Thu, Oct 30, 2014 at 5:17 PM, Alexander Clemm (alex) wr= ote: > Hi Andy, > > controllers / mount clients have the option to subscribe to updates in an= y way they deem fit. Does this mean the servers have to implement several ways to do the same thing, so the client can choose? I think we disagree on where the system complexity belongs. In fact, on-demand will usually be the default. Polling optimizations along the lines that you suggest (if-modified-since) make sense as well, although presumably adding complexity to the server implementation as well. > > For pushing data, it is definitely conceivable to add a throttle mechanis= m that the client can use. The simplest mechanism of course is to dimensio= n the minimum interval between updates as needed. > > To add to the Eric's earlier point, the issue is not that you could not a= chieve the same application going to the different devices directly. The i= ssue is that in that case you push the complexity to the application develo= per of having to deal with the complexity of dealing with each device indiv= idually. Not every system may support mount points, just like not every sy= stem may support any other YANG module. But why limit those that are able = to support it from doing so, in particular as there are clearly application= s and deployment scenarios where this is needed and makes sense. The application developer still needs to understand YANG data to do aggrega= tion and other useful tasks. Blind data replication is not very important, compared to all the other stuff a controller could be doing. > > --- Alex Andy > > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Andy Bierman > Sent: Thursday, October 30, 2014 2:23 PM > To: Eric Voit (evoit) > Cc: netmod@ietf.org > Subject: Re: [netmod] YANG model containing both device and domain config= (was RE: New revision of YANG mount draft) > > Hi, > > I guess you are not really understanding my point. > I am concerned on the complexity pushed on the devices to somehow be conf= igured to find each controller, register some data subtrees to mount, and t= hen push data to each controller. > > I don't see that it saves work as much as moves it from a relatively smal= l number of controllers to a large number of servers. Are operators going = to configure the devices or are the controllers going to configure themselv= es in each server? Seems too complicated to me. > > I think the polling can be optimized (If-Match, If-Modified-Since, etc.). > This approach (already in RESTCONF, but really only for config=3Dtrue) co= uld be applied to operational state as well. > > There needs to be a minimum update interval or the controllers can get ov= errun with pushed data. IMO the controllers should be polling for changes = at the rate they want data. > > If the operational state changes in someway that is interesting to the op= erator, then the traditional approach of defining and sending a notificatio= n event works fine. > > > Andy > > > > > > On Thu, Oct 30, 2014 at 1:48 PM, Eric Voit (evoit) wrot= e: >> From: Thomas D. Nadeau, October 30, 2014 4:31 PM >> >> On Oct 30, 2014:4:17 PM, at 4:17 PM, Andy Bierman >> wrote: >> >> >> >> On Thu, Oct 30, 2014 at 12:16 PM, Eric Voit (evoit) wr= ote: >> >> Andy, >> >> >> >> Two weeks ago I promised a useful YANG model which exposes both device >> and domain config. The model is here: >> >> http://www.ietf.org/internet-drafts/draft-tripathy-cloud-sla-yang-mode >> l-00.txt >> >> >> >> A simple =E2=80=9CCloud Policer=E2=80=9D application can sit completely = upon the >> model. The algorithm might be: >> >> >> >> (1) The Operator enters a maximum data rate across a federation >> (Cloud) of devices >> >> >> >> (2) Sum the current bandwidth across the collection of devices in the >> federation (via RFC 7223 YANG device interface statistics) >> >> >> >> (3) Policed Bandwidth rate each device =3D (current traffic to the >> device / current federation traffic) * Operator established Federation >> Max rate >> >> >> >> (4) Go back to step (2) >> >> >> >> If we set the federation bandwidth to 100MB/s, and then vary the >> offered to two devices, the result looks like this. >> >> >> >> >> >> Effectively we are showing the config of domain and device upon one grap= h. >> And the device config is varying over time based on Peer Mounted RFC >> 7223 YANG interface statistics. >> >> >> >> This is running code. The code is portable so that it can run on a >> controller, or it can run upon a designated router within the federation= . >> >> >> >> >> >> >> >> I don't think the application needs YANG Mount to accomplish its task. >> >> This has nothing to do with the issue of device-configured vs. >> >> controller-configured data collection. Any controller can collect >> some subtrees >> >> from each device and use the data somehow. >> >> >> >> The point of mount isn=E2=80=99t for the controller=E2=80=99s = convenience >> per se; its for the app that wants to get at those stats. The app only >> needs to talk to a single controller. >> >> >> >> Agree. It is *possible* to do some of this with existing Netco= nf. >> But it gets ugly. Application developers lose the following benefits: >> >> >> >> Application Simplification >> >> =E2=80=A2 Major code size reduction =E2=86=92 data access only to local = Datastore >> >> =E2=80=A2 Caching and polling becomes hidden infrastructure >> >> >> >> Application Robustness >> >> =E2=80=A2 Distributed YANG objects available to applications without nee= ding >> to acquire the data themselves >> >> =E2=80=A2 Can run between Network Elements, where some controllers alrea= dy >> reside >> >> >> >> Application Performance >> >> =E2=80=A2 On-change & Periodic object Pub/Sub with transparent caching >> >> =E2=80=A2 Scaling benefits: ability to cascade updates across multiple t= iers >> of Mount >> >> Misconfiguration Types Eliminated >> >> =E2=80=A2 Authoritative copy in Federation transparently used >> >> =E2=80=A2 Mount & monitor the actual state of the network (apps don=E2= =80=99t just get >> one-time =E2=80=9CACK=E2=80=9D). >> >> In other words, we are trying to make life easier for Application >> Developers. Especially developers of applications which span >> federations of network devices. >> >> >> >> Eric >> >> >> >> Just use NETCONF or >> >> RESTCONF as-is. It really complicates the architecture to use mount >> points, >> >> especially if every controller is going to replicate data from every >> server in >> >> different ways, and force the devices to do all the work. >> >> >> >> It complicates it for the controller but has the advantage >> of simplifying it for potentially many, many more applications that >> rely on the controller=E2=80=99s abstraction of the universe. >> >> >> >> =E2=80=94Tom >> >> >> >> >> >> >> >> >> >> >> >> >> >> Eric >> >> >> >> >> >> Andy >> >> >> >> >> >> >> >> From: Andy Bierman, October 14, 2014 6:47 PM >> >> >> >> >> >> I do not agree that the "collection of device models" is a very >> interesting solution >> >> for network management at the network level. We have dabbled with >> "network-wide" >> >> configuration a couple times, only to drop the issue. IMO the models >> at this level >> >> describe the network, not the devices. There is some glue that tells >> the controller what devices are >> >> available, and how to talk to them, but the goal is to handle the >> device level details >> >> as part of the controller data model implementation. >> >> >> >> We have a YANG model for Cloud Policer and DDoS Thresholding whic= h >> exposes the interplay of domain and device view. I will strive to get = it >> posted as a new draft before Oct 27th. (IETF 91 cut-off date.) >> >> >> >> Eric >> >> >> >> >> >> >> >> >> >> Eric Voit >> >> Principal Engineer - CSG >> >> >> >> >> >> _______________________________________________ >> 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 Oct 30 19:39:33 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 745CD1A8A8D for ; Thu, 30 Oct 2014 19:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.56 X-Spam-Level: X-Spam-Status: No, score=-8.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, 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 QlZZJLJgGE2h for ; Thu, 30 Oct 2014 19:39:20 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3CC21A8A8C for ; Thu, 30 Oct 2014 19:39:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34821; q=dns/txt; s=iport; t=1414723160; x=1415932760; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=tv7QZYM8p3k6aI+wR2CiVlQHtgtfMLs4b+sAWKfoi5A=; b=ckkt1KC3pGJ926HDkZLBQOusxqjqkJVyv3vUOHkJBjMf+JVf7YEY4Fi3 Cv4SnI8siolxCbhbUiz+j1Z+xCz0ttZVwRi9Yktd7DVCaLO//uy2HhK9X PAaR4QKqF7IzKxrPig/Hp+7XiOCa2BBKO6dQMVRnOxH6Jqn1Lhk8y4sxA Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlcGAOf0UlStJV2b/2dsb2JhbABcgkhGVFgEgwLRaAIcgQAWAQEBAQF9hAIBAgQtRQcSAQYCEQMBAiEBBgUEMBQGAwgCBA4FiEGYZZxZCJRkAQEBAQEBAQEBAQEBAQEBAQEBAQEBF5B0ChEGAYJzgVgFj3GCH4cNhFOBMYNKihyDJYQIg3hsgUiBAwEBAQ X-IronPort-AV: E=Sophos;i="5.07,291,1413244800"; d="scan'208,217";a="364953986" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 31 Oct 2014 02:39:19 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s9V2dIik002944 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 Oct 2014 02:39:19 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.151]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Thu, 30 Oct 2014 21:39:18 -0500 From: "Dana Blair (dblair)" To: Yangang Thread-Topic: =?gb2312?B?tPC4tDogILTwuLQ6IFNvbWUgY29tbWVudHMgYWJvdXQgQUNMIFlBTkcgbW9k?= =?gb2312?Q?el.?= Thread-Index: AQHP7GcJNvv6hgwmVkSOGKo7BQmMmZw6YA8QgABHUICABHNsoIAKSzQA Date: Fri, 31 Oct 2014 02:39:18 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.21.146.48] Content-Type: multipart/alternative; boundary="_000_D0783DCF21DE59dblairciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/OuAnNWskQL_m4xTVrBU8ejKI6DU Cc: "netmod@ietf.org" Subject: Re: [netmod] =?gb2312?b?tPC4tDogILTwuLQ6IFNvbWUgY29tbWVudHMgYWJvdXQg?= =?gb2312?b?QUNMIFlBTkcgbW9kZWwu?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 31 Oct 2014 02:39:31 -0000 --_000_D0783DCF21DE59dblairciscocom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RnJvbTogWWFuZ2FuZyA8eWFuZ2FuZ0BodWF3ZWkuY29tPG1haWx0bzp5YW5nYW5nQGh1YXdlaS5j b20+Pg0KRGF0ZTogRnJpZGF5LCBPY3RvYmVyIDI0LCAyMDE0IGF0IDc6MTEgQU0NClRvOiBDaXNj byBFbXBsb3llZSA8ZGJsYWlyQGNpc2NvLmNvbTxtYWlsdG86ZGJsYWlyQGNpc2NvLmNvbT4+DQpD YzogIkxpc2EgSHVhbmcgKHlpaHVhbikiIDx5aWh1YW5AY2lzY28uY29tPG1haWx0bzp5aWh1YW5A Y2lzY28uY29tPj4sIERlYW4gQm9nZGFub3ZpYyA8ZGVhbmJAanVuaXBlci5uZXQ8bWFpbHRvOmRl YW5iQGp1bmlwZXIubmV0Pj4sIEtpcmFuIEFncmFoYXJhIFNyZWVuaXZhc2EgPGtrb3VzaGlrQEJy b2NhZGUuY29tPG1haWx0bzpra291c2hpa0BCcm9jYWRlLmNvbT4+LCAiQmVub2l0IENsYWlzZSAo YmNsYWlzZSkiIDxiY2xhaXNlQGNpc2NvLmNvbTxtYWlsdG86YmNsYWlzZUBjaXNjby5jb20+Piwg Im5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPiIgPG5ldG1vZEBpZXRmLm9y ZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPj4NClN1YmplY3Q6ILTwuLQ6ILTwuLQ6IFNvbWUgY29t bWVudHMgYWJvdXQgQUNMIFlBTkcgbW9kZWwuDQoNCkhpLA0KDQpJIHVwZGF0ZSB0aGUgbW9kZWwu ICBQbGVhc2UgY2hlY2sgYXR0YWNoZWQgZmlsZSwgSSBtYXJrIG15IG1vZGlmaWNhdGlvbiB3aXRo IHJlZCBjb2xvci4NCg0KQWJvdXQgdGhlIHRoaXJkIGlzc3VlcywgSSBjYW6hr3QgZmluZCBhIG1l dGhvZCB0byByZXByZXNlbnQgdGhlIKGwQm9vbGVhbiBhbGdlYnJhobEgaW4gYSBzaG9ydCB0aW1l IGFmdGVyIEkgZGlzY3VzcyBzb21lYm9keSBpcyBhdCBoZXJlLiBJbiBvcmRlciB0byBtYWtlIHN1 cmUgbmV3IGRyYWZ0IGNhbiBiZSBkZWxpdmVyZWQgb24gdGltZSwgSSBqdXN0IGRlZmluZSBhIHNp bXBsZSBtZXRob2QuIFBsZWFzZSBjaGVjayBpdC4NCg0KVGhhbmtzIGZvciB0aGUgY29udHJpYnV0 aW9uLiAgVGhlIGF1dGhvcnMgbm9ybWFsbHkgbWVldCBldmVyeSBjb3VwbGUgd2Vla3MgdG8gZGlz Y3VzcyBjb250cmlidXRpb25zIGFuZCBvdGhlciB0aGluZ3MgdGhhdCBjb21lIHVwLg0Kb3VyIG5l eHQgZGlzY3Vzc2lvbiB3aWxsIGJlIGF0IHRoZSBJRVRGLiAgQXJlIHlwdSBwbGFubmluZyBvbiBh dHRlbmRpbmcgPyAgQ2FuIHdlIGRpc2N1c3MgdGhpcyB0aGVyZSA/DQoNCnRoYW5rcywNCkRhbmEN Cg0KDQpUaGFua3MNCllhbmdhbmcuDQoNCreivP7IyzogRGFuYSBCbGFpciAoZGJsYWlyKSBbbWFp bHRvOmRibGFpckBjaXNjby5jb21dDQq3osvNyrG85DogMjAxNMTqMTDUwjIxyNUgMjI6MDMNCsrV vP7IyzogWWFuZ2FuZw0Ks63LzTogTGlzYSBIdWFuZyAoeWlodWFuKTsgRGVhbiBCb2dkYW5vdmlj OyBLaXJhbiBBZ3JhaGFyYSBTcmVlbml2YXNhOyBCZW5vaXQgQ2xhaXNlIChiY2xhaXNlKTsgbmV0 bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQrW98ziOiBSZTogtPC4tDogU29t ZSBjb21tZW50cyBhYm91dCBBQ0wgWUFORyBtb2RlbC4NCg0KRnJvbTogWWFuZ2FuZyA8eWFuZ2Fu Z0BodWF3ZWkuY29tPG1haWx0bzp5YW5nYW5nQGh1YXdlaS5jb20+Pg0KRGF0ZTogVHVlc2RheSwg T2N0b2JlciAyMSwgMjAxNCBhdCA3OjAzIEFNDQpUbzogQ2lzY28gRW1wbG95ZWUgPGRibGFpckBj aXNjby5jb208bWFpbHRvOmRibGFpckBjaXNjby5jb20+Pg0KQ2M6ICJMaXNhIEh1YW5nICh5aWh1 YW4pIiA8eWlodWFuQGNpc2NvLmNvbTxtYWlsdG86eWlodWFuQGNpc2NvLmNvbT4+LCBEZWFuIEJv Z2Rhbm92aWMgPGRlYW5iQGp1bmlwZXIubmV0PG1haWx0bzpkZWFuYkBqdW5pcGVyLm5ldD4+LCBL aXJhbiBBZ3JhaGFyYSBTcmVlbml2YXNhIDxra291c2hpa0BCcm9jYWRlLmNvbTxtYWlsdG86a2tv dXNoaWtAQnJvY2FkZS5jb20+PiwgIkJlbm9pdCBDbGFpc2UgKGJjbGFpc2UpIiA8YmNsYWlzZUBj aXNjby5jb208bWFpbHRvOmJjbGFpc2VAY2lzY28uY29tPj4sICJuZXRtb2RAaWV0Zi5vcmc8bWFp bHRvOm5ldG1vZEBpZXRmLm9yZz4iIDxuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRm Lm9yZz4+DQpTdWJqZWN0OiC08Li0OiBTb21lIGNvbW1lbnRzIGFib3V0IEFDTCBZQU5HIG1vZGVs Lg0KDQpIaSwNCiAyLiAgICAgIEluIHBhY2tldC1maWVsZHMgbW9kdWxlLCBJdCBsb29rcyB0aGUg Y3VycmVudCBkZWZpbml0aW9uIGlzIG5vdCBzbyBzdWZmaWNpZW50LiBGb3IgZXhhbXBsZSwgbm8g IiE9IiBkZWZpbml0aW9uLCBhbmQgbm8gbWFzayBpbiBhY2wtaXB2NC1oZWFkZXItZmllbGRzIGdy b3VwLCBldGOhrS4uDQoNCkRMQjogIG5vIKGwbm90obEgZGVmaW5pdGlvbi4gICBUaGlzIGlzIGEg Z29vZCBjYXRjaC4gIEZlZWwgZnJlZSB0byBwcm9wb3NlIGFuIGF1Z21lbnRhdGlvbiBvciBjaGFu Z2UgdG8gdGhlIGV4aXN0aW5nIG1vZGVsLg0KDQpZYW5nYW5nOiBPSywgSSB3aWxsIGRvIGl0LCBJ IHRyeSB0byBwcm92aWRlIGRhdGEgYXMgc29vbiBhcyBwb3NzaWJsZS4NCg0KR3JlYXQuDQoNCg0K My4gICAgICBJbiB0aGlzIGRyYWZ0LCB0aGVyZSBpcyBhY2wtdHlwZSBhbmQgYWNlLXR5cGUuIEl0 IGxvb2tzIHRoZSBJUCBwYWNrZXQgbWF0Y2ggYW5kIEV0aGVybmV0IHBhY2tldCBtYXRjaCBjYW4g YmUgY29uZmlndXJlZCB0b2dldGhlci4gQnV0IGl0IGxvb2tzIG9ubHkgIk9SIiByZWxhdGlvbnNo aXAgaXMgYXQgdGhlcmUsIG5vICJBTkQiIHJlbGF0aW9uc2hpcC4NCg0KRExCOiAgICAgV2hhdCBr aW5kIG9mIKGwQU5EobEgcmVsYXRpb25zaGlwIGFyZSB5b3UgZXhwZWN0aW5nID8NCllhbmdhbmc6 IEkgcmVtZW1iZXIgd2UgZ290IG9uZSByZXF1aXJlbWVudCBmcm9tIHRoZSBlbmQgdXNlcjogVGhl eSB3YW50IHRoZSBBQ0wgdG8gY2hlY2sgdGhlIEwyIE1BQyBhZGRyZXNzIGFuZCBMMyBJUCBhZGRy ZXNzIHRvZ2V0aGVyLiBBdCB0aGlzIHRpbWUsIHRoZSByZWxhdGlvbnNoaXAgb2YgUlVMRXMgaXMg obBBTkShsSwgbm90IKGwT1KhsS4NCg0KU28gZG8gdGhleSB3YW50IHRvIGRvIHRoaXM6DQptYXRj aCAoKElQIGFkZHJlc3MgPT0gMS4xLjEuMSkgQU5EIChNQUMgYWRkcmVzcyA9PSAweEFCQ0RFRikp IHBlcm1pdA0KDQpvciB0aGlzOg0KDQptYXRjaCAoKElQIGFkZHJlc3MgPT0gMS4xLjEuMSkgT1Ig KE1BQyBhZGRyZXNzID09IDB4QUJDREVGKSkgcGVybWl0DQoNCm9yIHNvbWV0aGluZyBlbHNlID8N Cg0KdGhhbmtzLA0KRGFuYQ0KDQoNCg0KDQpUaGFua3MNCllhbmdhbmcuDQoNCreivP7IyzogRGFu YSBCbGFpciAoZGJsYWlyKSBbbWFpbHRvOmRibGFpckBjaXNjby5jb21dDQq3osvNyrG85DogMjAx NMTqMTDUwjIwyNUgMjE6MDkNCsrVvP7IyzogWWFuZ2FuZw0Ks63LzTogRGFuYSBCbGFpciAoZGJs YWlyKTsgTGlzYSBIdWFuZyAoeWlodWFuKTsgRGVhbiBCb2dkYW5vdmljOyBLaXJhbiBBZ3JhaGFy YSBTcmVlbml2YXNhOyBCZW5vaXQgQ2xhaXNlIChiY2xhaXNlKTsgbmV0bW9kQGlldGYub3JnPG1h aWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQrW98ziOiBSRTogU29tZSBjb21tZW50cyBhYm91dCBBQ0wg WUFORyBtb2RlbC4NCg0KVGhlIGRyYWZ0IGF1dGhvcnMgbWV0IGFuZCBoZXJlIGlzIHRoZSByZXNw b25zZS4gIExvb2sgZm9yIERMQjoNClRoZSBjb21tZW50cyBtZW50aW9uIGNvbXBpbGFibGUgb3B0 aW9uIHdoaWNoIG1lYW5zIHRoZSBwcm9wb3NhbCBjb21waWxlcyB3aXRoIHB5YW5nIC0taWV0ZiBv cHRpb24uDQoNCkhpLA0KDQpJIGFtIHJldmlld2luZyB0aGUgQUNMIFlBTkcgbW9kZWwuIEFuZCBJ IGdvdCBzb21lIGRvdWJ0cywgbWF5YmUgc29tZWJvZHkgY2FuIGhlbHAgbWUgdG8gdW5kZXJzdGFu ZCBpdC4NCg0KDQoxLiAgICAgIFRoZXJlIGlzIG9uZSBmaWVsZDogdGFyZ2V0cy4gSW4gbXkgdW5k ZXJzdGFuZGluZywgbWF5YmUgaXQgaXMgdXNlZCB0byByZWNvcmQgd2hvIHJlZmVyZW5jZSB0aGlz IEFDTC4gSSBkb26hr3Qga25vdyBpZiBJcyBpdCBtYW5kYXRvcnkgb3Igbm90LiBPciBteSB1bmRl cnN0YW5kaW5nIGlzIHdyb25nLg0KDQpETEI6ICBZb3VyIHVuZGVyc3RhbmQgaXMgY29ycmVjdC4g IEl0oa9zIG5vdCBtYW5kYXRvcnkuICAgVG8gbW92ZSBiZXlvbmQganVzdCB1c2luZyBzdHJpbmcs IHdlIG5lZWQgYSBjb21waWxhYmxlIGF1Z21lbnRhdGlvbi4gIFNpbmNlIEFDTHMgY2FuIGJlDQph cHBsaWVkIHRvIGludGVyZmFjZXMsIHRoYXQgbWlnaHQgYmUgYSBnb29kIHBsYWNlIHRvIHN0YXJ0 Lg0KDQoNCjIuICAgICAgSW4gcGFja2V0LWZpZWxkcyBtb2R1bGUsIEl0IGxvb2tzIHRoZSBjdXJy ZW50IGRlZmluaXRpb24gaXMgbm90IHNvIHN1ZmZpY2llbnQuIEZvciBleGFtcGxlLCBubyAiIT0i IGRlZmluaXRpb24sIGFuZCBubyBtYXNrIGluIGFjbC1pcHY0LWhlYWRlci1maWVsZHMgZ3JvdXAs IGV0Y6GtLi4NCg0KRExCOiAgbm8gobBub3ShsSBkZWZpbml0aW9uLiAgIFRoaXMgaXMgYSBnb29k IGNhdGNoLiAgRmVlbCBmcmVlIHRvIHByb3Bvc2UgYW4gYXVnbWVudGF0aW9uIG9yIGNoYW5nZSB0 byB0aGUgZXhpc3RpbmcgbW9kZWwuDQoNCg0KDQozLiAgICAgIEluIHRoaXMgZHJhZnQsIHRoZXJl IGlzIGFjbC10eXBlIGFuZCBhY2UtdHlwZS4gSXQgbG9va3MgdGhlIElQIHBhY2tldCBtYXRjaCBh bmQgRXRoZXJuZXQgcGFja2V0IG1hdGNoIGNhbiBiZSBjb25maWd1cmVkIHRvZ2V0aGVyLiBCdXQg aXQgbG9va3Mgb25seSAiT1IiIHJlbGF0aW9uc2hpcCBpcyBhdCB0aGVyZSwgbm8gIkFORCIgcmVs YXRpb25zaGlwLg0KDQpETEI6ICAgICBXaGF0IGtpbmQgb2YgobBBTkShsSByZWxhdGlvbnNoaXAg YXJlIHlvdSBleHBlY3RpbmcgPw0KDQoNCg0KdGhhbmtzLA0KDQpEYW5hIEJsYWlyDQoNCg0KDQoN Cg0KVGhhbmtzDQpZYW5nYW5nDQo= --_000_D0783DCF21DE59dblairciscocom_ Content-Type: text/html; charset="gb2312" Content-ID: <64073C29A91ADD4DA512AD90421AD861@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
From: Yangang <<= /span>yangang@huawei.com>
Date: Friday, October 24, 2014 at 7= :11 AM
To: Cisco Employee <dblair@cisco.com>
Cc: "Lisa Huang (yihuan)"= <yihuan@cisco.com>, Dean Bog= danovic <deanb@juniper.net>,= Kiran Agrahara Sreenivasa <kkou= shik@Brocade.com>, "Benoit Claise (bclaise)" <bclaise@cisco.com>, "netm= od@ietf.org" <netmod@ietf.or= g>
Subject: =B4=F0=B8=B4: =B4=F0=B8=B4= : Some comments about ACL YANG model.

Hi,

 <= /span>

I update the model= .  Please check attached file, I mark my modification with red color.<= o:p>

 <= /span>

About the third is= sues, I can=A1=AFt find a method to represent the =A1=B0Boolean algebra=A1= =B1 in a short time after I discuss somebody is at here. In order to make sure new draft can be delivered on time, I just define a = simple method. Please check it.

Thanks for the contribution.  The authors normally meet every cou= ple weeks to discuss contributions and other things that come up.
our next discussion will be at the IETF.  Are ypu planning on att= ending ?  Can we discuss this there ?

thanks,
Dana

=

 <= /span>

Thanks<= /span>

Yangang.

 <= /span>

 

From: Yangang <yangang@huawei.com><= /span>

Date: Tuesday, October 21, 2014 at 7:03 AM
To: Cisco Employee <dblair@ci= sco.com>
Cc: "Lisa Huang (yihuan)" <yihuan@cisco.com>, Dean Bogdanovic <deanb@juniper.net>, Kiran Agrahara Sreenivasa <kkoushik@Brocade.com>, "Benoit Claise (bclaise)" <bclaise@cisco.com>, "netm= od@ietf.org" <netmod@ietf.or= g>
Subject: =B4=F0=B8=B4: Some comments= about ACL YANG model.

 

Hi,

 2.  &= nbsp;   In packet-fields module, It looks the current definition is not = so sufficient. For example, no "!=3D" definition, and no mask in = acl-ipv4-header-fields group, etc=A1=AD..

DLB:  no =A1=B0not=A1=B1 definition.   This is a good cat= ch.  Feel free to propose an augmentation or change to the existing model.=

Yangang: OK, I will do it, I try to provide data= as soon as possible.

 

Great.

 

= 3.&nb= sp;     In this draft, there is acl-type and ace-type. It looks the IP p= acket match and Ethernet packet match can be configured together. But it lo= oks only "OR" relationship is at there, no "AND" relationship.

= DLB:     What kind of =A1=B0AND=A1=B1 relationship are you ex= pecting ?

Yangang: I remember we got on= e requirement from the end user: They want the ACL to check the L2 MAC addr= ess and L3 IP address together. At this time, the relationship of RULEs is =A1=B0AND=A1=B1, not =A1=B0OR=A1=B1.

 

So do they want to do this:

match ((IP address =3D=3D 1.1= .1.1) AND (MAC address =3D=3D 0xABCDEF)) permit

 

or this:

 

match ((IP address =3D=3D 1.1= .1.1) OR (MAC address =3D=3D 0xABCDEF)) permit

 

or something else ?

 

thanks,

Dana

 

 

 

 

Thanks

Yangang.

 

=B7=A2=BC=FE=C8=CB: Dana Blair (dblair) [= mailto:dblair@cisco.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA10=D4=C22= 0=C8=D5 21:09
=CA=D5=BC=FE=C8=CB: Yangang
=B3=AD=CB=CD: Dana Blair (dblair); Lisa Huang (yihuan); Dean Bogdanovic; Kiran Agrahara= Sreenivasa; Benoit Claise (bclaise); netmod@ietf.org
=D6=F7=CC=E2: RE: Some comments about ACL YANG model.

 

The draft authors met a= nd here is the response.  Look for DLB:

The comments mention co= mpilable option which means the proposal compiles with pyang --ietf option.=

 

Hi,

 

I am reviewing the ACL = YANG model. And I got some doubts, maybe somebody can help me to understand= it.

 

1.      There is one field: targets. In my understanding, maybe it is us= ed to record who reference this ACL. I don=A1=AFt know if Is it mandatory o= r not. Or my understanding is wrong.

 

DLB:  Your underst= and is correct.  It=A1=AFs not mandatory.   To move beyond just u= sing string, we need a compilable augmentation.  Since ACLs can be

applied to interfaces, = that might be a good place to start.    

 

2.      In packet-fields module, It looks the current definition is not = so sufficient. For example, no "!=3D" definition, and no mask in = acl-ipv4-header-fields group, etc=A1=AD..

DLB:  no =A1=B0not=A1=B1 definition.   This is a good cat= ch.  Feel free to propose an augmentation or change to the existing model.=

 

= 3.&nb= sp;     In this draft, there is acl-type and ace-type. It looks the IP p= acket match and Ethernet packet match can be configured together. But it lo= oks only "OR" relationship is at there, no "AND" relationship.

= DLB:     What kind of =A1=B0AND=A1=B1 relationship are you ex= pecting ?

=  

= thanks,

= Dana Blair=

=  

=  

 

Thanks

Yangang

 --_000_D0783DCF21DE59dblairciscocom_-- From nobody Thu Oct 30 20:29:02 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B12B71A8A94 for ; Thu, 30 Oct 2014 20:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.74 X-Spam-Level: * X-Spam-Status: No, score=1.74 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 hYWljeVwAJZK for ; Thu, 30 Oct 2014 20:28: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 B5C481A8A08 for ; Thu, 30 Oct 2014 20:28:56 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLD04394; Fri, 31 Oct 2014 03:28:55 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 31 Oct 2014 03:28:54 +0000 Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.104]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Fri, 31 Oct 2014 11:28:49 +0800 From: Yangang To: "Dana Blair (dblair)" Thread-Topic: =?gb2312?B?tPC4tDogILTwuLQ6IFNvbWUgY29tbWVudHMgYWJvdXQgQUNMIFlBTkcgbW9k?= =?gb2312?Q?el.?= Thread-Index: AQHP7GcJNvv6hgwmVkSOGKo7BQmMmZw6YA8QgABHUICABHNsoIAKSzQAgAAzEVA= Date: Fri, 31 Oct 2014 03:28:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.72.210] Content-Type: multipart/alternative; boundary="_000_D496C972D1A13540A730720631EC73413A41C09Ankgeml507mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/z3qIr6C7xGMDMPk57Pp4aZTqJcg Cc: "netmod@ietf.org" Subject: [netmod] =?gb2312?b?tPC4tDogtPC4tDogILTwuLQ6IFNvbWUgY29tbWVudHMg?= =?gb2312?b?YWJvdXQgQUNMIFlBTkcgbW9kZWwu?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 31 Oct 2014 03:29:00 -0000 --_000_D496C972D1A13540A730720631EC73413A41C09Ankgeml507mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIERhbmE6DQoNCkkgYW0gZ2xhZCB0byBhdHRlbmQgeW91ciBtZWV0aW5nLiBBbmQgSSB3aWxs IGFycml2ZSBhdCB0aGVyZSBOb3YgOCBhZnRlcm5vb24uDQoNClRoYW5rcw0KWWFuZ2FuZy4NCg0K t6K8/sjLOiBEYW5hIEJsYWlyIChkYmxhaXIpIFttYWlsdG86ZGJsYWlyQGNpc2NvLmNvbV0NCrei y83KsbzkOiAyMDE0xOoxMNTCMzHI1SAxMDozOQ0KytW8/sjLOiBZYW5nYW5nDQqzrcvNOiBMaXNh IEh1YW5nICh5aWh1YW4pOyBEZWFuIEJvZ2Rhbm92aWM7IEtpcmFuIEFncmFoYXJhIFNyZWVuaXZh c2E7IEJlbm9pdCBDbGFpc2UgKGJjbGFpc2UpOyBuZXRtb2RAaWV0Zi5vcmcNCtb3zOI6IFJlOiC0 8Li0OiC08Li0OiBTb21lIGNvbW1lbnRzIGFib3V0IEFDTCBZQU5HIG1vZGVsLg0KDQpGcm9tOiBZ YW5nYW5nIDx5YW5nYW5nQGh1YXdlaS5jb208bWFpbHRvOnlhbmdhbmdAaHVhd2VpLmNvbT4+DQpE YXRlOiBGcmlkYXksIE9jdG9iZXIgMjQsIDIwMTQgYXQgNzoxMSBBTQ0KVG86IENpc2NvIEVtcGxv eWVlIDxkYmxhaXJAY2lzY28uY29tPG1haWx0bzpkYmxhaXJAY2lzY28uY29tPj4NCkNjOiAiTGlz YSBIdWFuZyAoeWlodWFuKSIgPHlpaHVhbkBjaXNjby5jb208bWFpbHRvOnlpaHVhbkBjaXNjby5j b20+PiwgRGVhbiBCb2dkYW5vdmljIDxkZWFuYkBqdW5pcGVyLm5ldDxtYWlsdG86ZGVhbmJAanVu aXBlci5uZXQ+PiwgS2lyYW4gQWdyYWhhcmEgU3JlZW5pdmFzYSA8a2tvdXNoaWtAQnJvY2FkZS5j b208bWFpbHRvOmtrb3VzaGlrQEJyb2NhZGUuY29tPj4sICJCZW5vaXQgQ2xhaXNlIChiY2xhaXNl KSIgPGJjbGFpc2VAY2lzY28uY29tPG1haWx0bzpiY2xhaXNlQGNpc2NvLmNvbT4+LCAibmV0bW9k QGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+IiA8bmV0bW9kQGlldGYub3JnPG1haWx0 bzpuZXRtb2RAaWV0Zi5vcmc+Pg0KU3ViamVjdDogtPC4tDogtPC4tDogU29tZSBjb21tZW50cyBh Ym91dCBBQ0wgWUFORyBtb2RlbC4NCg0KSGksDQoNCkkgdXBkYXRlIHRoZSBtb2RlbC4gIFBsZWFz ZSBjaGVjayBhdHRhY2hlZCBmaWxlLCBJIG1hcmsgbXkgbW9kaWZpY2F0aW9uIHdpdGggcmVkIGNv bG9yLg0KDQpBYm91dCB0aGUgdGhpcmQgaXNzdWVzLCBJIGNhbqGvdCBmaW5kIGEgbWV0aG9kIHRv IHJlcHJlc2VudCB0aGUgobBCb29sZWFuIGFsZ2VicmGhsSBpbiBhIHNob3J0IHRpbWUgYWZ0ZXIg SSBkaXNjdXNzIHNvbWVib2R5IGlzIGF0IGhlcmUuIEluIG9yZGVyIHRvIG1ha2Ugc3VyZSBuZXcg ZHJhZnQgY2FuIGJlIGRlbGl2ZXJlZCBvbiB0aW1lLCBJIGp1c3QgZGVmaW5lIGEgc2ltcGxlIG1l dGhvZC4gUGxlYXNlIGNoZWNrIGl0Lg0KDQpUaGFua3MgZm9yIHRoZSBjb250cmlidXRpb24uICBU aGUgYXV0aG9ycyBub3JtYWxseSBtZWV0IGV2ZXJ5IGNvdXBsZSB3ZWVrcyB0byBkaXNjdXNzIGNv bnRyaWJ1dGlvbnMgYW5kIG90aGVyIHRoaW5ncyB0aGF0IGNvbWUgdXAuDQpvdXIgbmV4dCBkaXNj dXNzaW9uIHdpbGwgYmUgYXQgdGhlIElFVEYuICBBcmUgeXB1IHBsYW5uaW5nIG9uIGF0dGVuZGlu ZyA/ICBDYW4gd2UgZGlzY3VzcyB0aGlzIHRoZXJlID8NCg0KdGhhbmtzLA0KRGFuYQ0KDQoNClRo YW5rcw0KWWFuZ2FuZy4NCg0Kt6K8/sjLOiBEYW5hIEJsYWlyIChkYmxhaXIpIFttYWlsdG86ZGJs YWlyQGNpc2NvLmNvbV0NCreiy83KsbzkOiAyMDE0xOoxMNTCMjHI1SAyMjowMw0KytW8/sjLOiBZ YW5nYW5nDQqzrcvNOiBMaXNhIEh1YW5nICh5aWh1YW4pOyBEZWFuIEJvZ2Rhbm92aWM7IEtpcmFu IEFncmFoYXJhIFNyZWVuaXZhc2E7IEJlbm9pdCBDbGFpc2UgKGJjbGFpc2UpOyBuZXRtb2RAaWV0 Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCtb3zOI6IFJlOiC08Li0OiBTb21lIGNvbW1l bnRzIGFib3V0IEFDTCBZQU5HIG1vZGVsLg0KDQpGcm9tOiBZYW5nYW5nIDx5YW5nYW5nQGh1YXdl aS5jb208bWFpbHRvOnlhbmdhbmdAaHVhd2VpLmNvbT4+DQpEYXRlOiBUdWVzZGF5LCBPY3RvYmVy IDIxLCAyMDE0IGF0IDc6MDMgQU0NClRvOiBDaXNjbyBFbXBsb3llZSA8ZGJsYWlyQGNpc2NvLmNv bTxtYWlsdG86ZGJsYWlyQGNpc2NvLmNvbT4+DQpDYzogIkxpc2EgSHVhbmcgKHlpaHVhbikiIDx5 aWh1YW5AY2lzY28uY29tPG1haWx0bzp5aWh1YW5AY2lzY28uY29tPj4sIERlYW4gQm9nZGFub3Zp YyA8ZGVhbmJAanVuaXBlci5uZXQ8bWFpbHRvOmRlYW5iQGp1bmlwZXIubmV0Pj4sIEtpcmFuIEFn cmFoYXJhIFNyZWVuaXZhc2EgPGtrb3VzaGlrQEJyb2NhZGUuY29tPG1haWx0bzpra291c2hpa0BC cm9jYWRlLmNvbT4+LCAiQmVub2l0IENsYWlzZSAoYmNsYWlzZSkiIDxiY2xhaXNlQGNpc2NvLmNv bTxtYWlsdG86YmNsYWlzZUBjaXNjby5jb20+PiwgIm5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0 bW9kQGlldGYub3JnPiIgPG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPj4N ClN1YmplY3Q6ILTwuLQ6IFNvbWUgY29tbWVudHMgYWJvdXQgQUNMIFlBTkcgbW9kZWwuDQoNCkhp LA0KIDIuICAgICAgSW4gcGFja2V0LWZpZWxkcyBtb2R1bGUsIEl0IGxvb2tzIHRoZSBjdXJyZW50 IGRlZmluaXRpb24gaXMgbm90IHNvIHN1ZmZpY2llbnQuIEZvciBleGFtcGxlLCBubyAiIT0iIGRl ZmluaXRpb24sIGFuZCBubyBtYXNrIGluIGFjbC1pcHY0LWhlYWRlci1maWVsZHMgZ3JvdXAsIGV0 Y6GtLi4NCg0KRExCOiAgbm8gobBub3ShsSBkZWZpbml0aW9uLiAgIFRoaXMgaXMgYSBnb29kIGNh dGNoLiAgRmVlbCBmcmVlIHRvIHByb3Bvc2UgYW4gYXVnbWVudGF0aW9uIG9yIGNoYW5nZSB0byB0 aGUgZXhpc3RpbmcgbW9kZWwuDQoNCllhbmdhbmc6IE9LLCBJIHdpbGwgZG8gaXQsIEkgdHJ5IHRv IHByb3ZpZGUgZGF0YSBhcyBzb29uIGFzIHBvc3NpYmxlLg0KDQpHcmVhdC4NCg0KDQozLiAgICAg IEluIHRoaXMgZHJhZnQsIHRoZXJlIGlzIGFjbC10eXBlIGFuZCBhY2UtdHlwZS4gSXQgbG9va3Mg dGhlIElQIHBhY2tldCBtYXRjaCBhbmQgRXRoZXJuZXQgcGFja2V0IG1hdGNoIGNhbiBiZSBjb25m aWd1cmVkIHRvZ2V0aGVyLiBCdXQgaXQgbG9va3Mgb25seSAiT1IiIHJlbGF0aW9uc2hpcCBpcyBh dCB0aGVyZSwgbm8gIkFORCIgcmVsYXRpb25zaGlwLg0KDQpETEI6ICAgICBXaGF0IGtpbmQgb2Yg obBBTkShsSByZWxhdGlvbnNoaXAgYXJlIHlvdSBleHBlY3RpbmcgPw0KWWFuZ2FuZzogSSByZW1l bWJlciB3ZSBnb3Qgb25lIHJlcXVpcmVtZW50IGZyb20gdGhlIGVuZCB1c2VyOiBUaGV5IHdhbnQg dGhlIEFDTCB0byBjaGVjayB0aGUgTDIgTUFDIGFkZHJlc3MgYW5kIEwzIElQIGFkZHJlc3MgdG9n ZXRoZXIuIEF0IHRoaXMgdGltZSwgdGhlIHJlbGF0aW9uc2hpcCBvZiBSVUxFcyBpcyChsEFORKGx LCBub3QgobBPUqGxLg0KDQpTbyBkbyB0aGV5IHdhbnQgdG8gZG8gdGhpczoNCm1hdGNoICgoSVAg YWRkcmVzcyA9PSAxLjEuMS4xKSBBTkQgKE1BQyBhZGRyZXNzID09IDB4QUJDREVGKSkgcGVybWl0 DQoNCm9yIHRoaXM6DQoNCm1hdGNoICgoSVAgYWRkcmVzcyA9PSAxLjEuMS4xKSBPUiAoTUFDIGFk ZHJlc3MgPT0gMHhBQkNERUYpKSBwZXJtaXQNCg0Kb3Igc29tZXRoaW5nIGVsc2UgPw0KDQp0aGFu a3MsDQpEYW5hDQoNCg0KDQoNClRoYW5rcw0KWWFuZ2FuZy4NCg0Kt6K8/sjLOiBEYW5hIEJsYWly IChkYmxhaXIpIFttYWlsdG86ZGJsYWlyQGNpc2NvLmNvbV0NCreiy83KsbzkOiAyMDE0xOoxMNTC MjDI1SAyMTowOQ0KytW8/sjLOiBZYW5nYW5nDQqzrcvNOiBEYW5hIEJsYWlyIChkYmxhaXIpOyBM aXNhIEh1YW5nICh5aWh1YW4pOyBEZWFuIEJvZ2Rhbm92aWM7IEtpcmFuIEFncmFoYXJhIFNyZWVu aXZhc2E7IEJlbm9pdCBDbGFpc2UgKGJjbGFpc2UpOyBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5l dG1vZEBpZXRmLm9yZz4NCtb3zOI6IFJFOiBTb21lIGNvbW1lbnRzIGFib3V0IEFDTCBZQU5HIG1v ZGVsLg0KDQpUaGUgZHJhZnQgYXV0aG9ycyBtZXQgYW5kIGhlcmUgaXMgdGhlIHJlc3BvbnNlLiAg TG9vayBmb3IgRExCOg0KVGhlIGNvbW1lbnRzIG1lbnRpb24gY29tcGlsYWJsZSBvcHRpb24gd2hp Y2ggbWVhbnMgdGhlIHByb3Bvc2FsIGNvbXBpbGVzIHdpdGggcHlhbmcgLS1pZXRmIG9wdGlvbi4N Cg0KSGksDQoNCkkgYW0gcmV2aWV3aW5nIHRoZSBBQ0wgWUFORyBtb2RlbC4gQW5kIEkgZ290IHNv bWUgZG91YnRzLCBtYXliZSBzb21lYm9keSBjYW4gaGVscCBtZSB0byB1bmRlcnN0YW5kIGl0Lg0K DQoNCjEuICAgICAgVGhlcmUgaXMgb25lIGZpZWxkOiB0YXJnZXRzLiBJbiBteSB1bmRlcnN0YW5k aW5nLCBtYXliZSBpdCBpcyB1c2VkIHRvIHJlY29yZCB3aG8gcmVmZXJlbmNlIHRoaXMgQUNMLiBJ IGRvbqGvdCBrbm93IGlmIElzIGl0IG1hbmRhdG9yeSBvciBub3QuIE9yIG15IHVuZGVyc3RhbmRp bmcgaXMgd3JvbmcuDQoNCkRMQjogIFlvdXIgdW5kZXJzdGFuZCBpcyBjb3JyZWN0LiAgSXShr3Mg bm90IG1hbmRhdG9yeS4gICBUbyBtb3ZlIGJleW9uZCBqdXN0IHVzaW5nIHN0cmluZywgd2UgbmVl ZCBhIGNvbXBpbGFibGUgYXVnbWVudGF0aW9uLiAgU2luY2UgQUNMcyBjYW4gYmUNCmFwcGxpZWQg dG8gaW50ZXJmYWNlcywgdGhhdCBtaWdodCBiZSBhIGdvb2QgcGxhY2UgdG8gc3RhcnQuDQoNCg0K Mi4gICAgICBJbiBwYWNrZXQtZmllbGRzIG1vZHVsZSwgSXQgbG9va3MgdGhlIGN1cnJlbnQgZGVm aW5pdGlvbiBpcyBub3Qgc28gc3VmZmljaWVudC4gRm9yIGV4YW1wbGUsIG5vICIhPSIgZGVmaW5p dGlvbiwgYW5kIG5vIG1hc2sgaW4gYWNsLWlwdjQtaGVhZGVyLWZpZWxkcyBncm91cCwgZXRjoa0u Lg0KDQpETEI6ICBubyChsG5vdKGxIGRlZmluaXRpb24uICAgVGhpcyBpcyBhIGdvb2QgY2F0Y2gu ICBGZWVsIGZyZWUgdG8gcHJvcG9zZSBhbiBhdWdtZW50YXRpb24gb3IgY2hhbmdlIHRvIHRoZSBl eGlzdGluZyBtb2RlbC4NCg0KDQoNCjMuICAgICAgSW4gdGhpcyBkcmFmdCwgdGhlcmUgaXMgYWNs LXR5cGUgYW5kIGFjZS10eXBlLiBJdCBsb29rcyB0aGUgSVAgcGFja2V0IG1hdGNoIGFuZCBFdGhl cm5ldCBwYWNrZXQgbWF0Y2ggY2FuIGJlIGNvbmZpZ3VyZWQgdG9nZXRoZXIuIEJ1dCBpdCBsb29r cyBvbmx5ICJPUiIgcmVsYXRpb25zaGlwIGlzIGF0IHRoZXJlLCBubyAiQU5EIiByZWxhdGlvbnNo aXAuDQoNCkRMQjogICAgIFdoYXQga2luZCBvZiChsEFORKGxIHJlbGF0aW9uc2hpcCBhcmUgeW91 IGV4cGVjdGluZyA/DQoNCg0KDQp0aGFua3MsDQoNCkRhbmEgQmxhaXINCg0KDQoNCg0KDQpUaGFu a3MNCllhbmdhbmcNCg== --_000_D496C972D1A13540A730720631EC73413A41C09Ankgeml507mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, Dana:<= o:p>

 = ;

I am glad = to attend your meeting. And I will arrive at there Nov 8 afternoon.

 = ;

Thanks

Yangang.

 = ;

=B7=A2=BC=FE=C8=CB: Dana Bl= air (dblair) [mailto:dblair@cisco.com]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA10=D4=C231=C8=D5 10:39
=CA=D5=BC=FE=C8=CB: Yangang
=B3=AD=CB=CD: Lisa Huang (yihuan); Dean Bogdanovic; Kiran Agrahara Sreenivasa; Benoit C= laise (bclaise); netmod@ietf.org
=D6=F7=CC=E2: Re: =B4=F0=B8=B4: =B4=F0=B8=B4: Some comments about ACL YANG mode= l.

 

From: Yangang <yangang@huawei.com>

Date: Friday, October 24, 2014= at 7:11 AM
To: Cisco Employee <dblair@ci= sco.com>
Cc: "Lisa Huang (yihuan)" <yihuan@cisco.com>, Dean Bogdanovic <deanb@juniper.net>, Kiran Agrahara Sreenivasa <kkoushik@Brocade.com>, "Benoit Claise (bclaise)" <bclaise@cisco.com>, "netm= od@ietf.org" <netmod@ietf.or= g>
Subject: =B4=F0=B8=B4: =B4=F0=B8=B4: Some comment= s about ACL YANG model.

 <= /o:p>

Hi,

 

I update t= he model.  Please check attached file, I mark my modification with red= color.=

 

About the = third issues, I can=A1=AFt find a method to represent the =A1=B0Boolean alg= ebra=A1=B1 in a short time after I discuss somebody is at here. In order to make sure new draft can be delivered on time, I just define a simple me= thod. Please check it.

 <= /o:p>

Thanks for t= he contribution.  The authors normally meet every couple weeks to disc= uss contributions and other things that come up.

our next dis= cussion will be at the IETF.  Are ypu planning on attending ?  Ca= n we discuss this there ?

 <= /o:p>

thanks,=

Dana

 <= /o:p>

 

Thanks

Yangang.

 

=B7=A2=BC=FE=C8=CB: Dana Blair (dblair) [= mailto:dblair@cisco.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA10=D4=C22= 1=C8=D5 22:03
=CA=D5=BC=FE=C8=CB: Yangang
=B3=AD=CB=CD: Lisa Huang (yihuan); Dean Bogdanovic; Kiran Agrahara Sreenivasa; Benoit C= laise (bclaise); netmod@ietf.org
=D6=F7=CC=E2: Re: =B4=F0=B8=B4: Some comments about ACL YAN= G model.

 

From: Yangang <yangang@huawei.com>

Date: Tuesday, October 21, 201= 4 at 7:03 AM
To: Cisco Employee <dblair@ci= sco.com>
Cc: "Lisa Huang (yihuan)" <yihuan@cisco.com>, Dean Bogdanovic <deanb@juniper.net>, Kiran Agrahara Sreenivasa <kkoushik@Brocade.com>, "Benoit Claise (bclaise)" <bclaise@cisco.com>, "netm= od@ietf.org" <netmod@ietf.or= g>
Subject: =B4=F0=B8=B4: Some comments about ACL YANG model.

 

Hi,

 2.      In packet-fields module, It looks the current= definition is not so sufficient. For example, no "!=3D" definiti= on, and no mask in acl-ipv4-header-fields group, etc=A1=AD..

DLB:  no =A1=B0not=A1=B1 definition.  = This is a good catch.  Feel free to propose an augmentation or change= to the existing model.=

Yangang: OK, I will do it, I tr= y to provide data as soon as possible.

 

Great.

 

= 3.      In this draft, there is acl-type and ace-type= . It looks the IP packet match and Ethernet packet match can be configured = together. But it looks only "OR" relationship is at there, no "AND" relationship.

= DLB:     What kind of =A1=B0AND=A1=B1 rela= tionship are you expecting ?

Yangang: I r= emember we got one requirement from the end user: They want the ACL to chec= k the L2 MAC address and L3 IP address together. At this time, the relationship of RULEs is =A1=B0AND=A1=B1, not =A1=B0OR=A1=B1.

 

So do they w= ant to do this:

match ((IP a= ddress =3D=3D 1.1.1.1) AND (MAC address =3D=3D 0xABCDEF)) permit

 

or this:

 

match ((IP a= ddress =3D=3D 1.1.1.1) OR (MAC address =3D=3D 0xABCDEF)) permit

 

or something= else ?=

 

thanks,

Dana<= span lang=3D"EN-US" style=3D"color:black">

 

 

 

 

Thanks

Yangang.

 

=B7=A2=BC=FE=C8=CB: Dana Blair (dblair) [= mailto:dblair@cisco.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA10=D4=C22= 0=C8=D5 21:09
=CA=D5=BC=FE=C8=CB: Yangang
=B3=AD=CB=CD: Dana Blair (dblair); Lisa Huang (yihuan); Dean Bogdanovic; Kiran Agrahara= Sreenivasa; Benoit Claise (bclaise); netmod@ietf.org
=D6=F7=CC=E2: RE: Some comments about ACL YANG model.

 

The draft authors met a= nd here is the response.  Look for DLB:

The comments mention co= mpilable option which means the proposal compiles with pyang --ietf option.=

 

Hi,

 

I am reviewing the ACL = YANG model. And I got some doubts, maybe somebody can help me to understand= it.

 

1.      There is one field: targets. In my understand= ing, maybe it is used to record who reference this ACL. I don=A1=AFt know i= f Is it mandatory or not. Or my understanding is wrong.

 

DLB:  Your underst= and is correct.  It=A1=AFs not mandatory.   To move beyond just u= sing string, we need a compilable augmentation.  Since ACLs can be

applied to interfaces, = that might be a good place to start.    

 

2.      In packet-fields module, It looks the current= definition is not so sufficient. For example, no "!=3D" definiti= on, and no mask in acl-ipv4-header-fields group, etc=A1=AD..

DLB:  no =A1=B0not=A1=B1 definition.  = This is a good catch.  Feel free to propose an augmentation or change= to the existing model.=

 

= 3.      In this draft, there is acl-type and ace-type= . It looks the IP packet match and Ethernet packet match can be configured = together. But it looks only "OR" relationship is at there, no "AND" relationship.

= DLB:     What kind of =A1=B0AND=A1=B1 rela= tionship are you expecting ?

=  

= thanks,

= Dana Blair

=  

=  

 

Thanks

Yangang

--_000_D496C972D1A13540A730720631EC73413A41C09Ankgeml507mbschi_-- From nobody Thu Oct 30 20:29:55 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCBAC1A8A96 for ; Thu, 30 Oct 2014 20:29: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 I3rBsgPduE73 for ; Thu, 30 Oct 2014 20:29:46 -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 E10711A8A08 for ; Thu, 30 Oct 2014 20:29:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=49728; q=dns/txt; s=iport; t=1414726186; x=1415935786; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=rU9Xf7invsTbWb4muetg/5zFFv5EayJ4ouGqne4fDe0=; b=PEWG1sz7EmAkE78qePdhOxQL93DgVZTFuP23YY8cf174+mQJn5AkHbPS GGJdtRzvldTFcVQgTT0e9W8Vqrevf1xCCnwARFHwTHiqHid6+6uE/hDou UrD5t09zYjegUuLFZbvpd2vf5z0emyPo+dF1hZUnjYTS0QbK8RqHEi+4t A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmcGAFQBU1StJV2a/2dsb2JhbABcgkhGVFgEgwK6BZAMAQmGeVQCHIEAFgEBAQEBfYQCAQEBAwEBAQEgCkELBQcEAgEIEQEDAQELAhQBAgQDAgICJQsUAwYIAgQBDQUIARACiB0JDbU5lGkBAQEBAQEBAQEBAQEBAQEBAQEBAQEXkDgmBgcgBAcGgnE2gR4FkhCESohHPI0qhy2CNIFEbIEHQYEDAQEB X-IronPort-AV: E=Sophos; i="5.07,291,1413244800"; d="scan'208,217"; a="91980790" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-4.cisco.com with ESMTP; 31 Oct 2014 03:29:45 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s9V3TiDG012129 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 Oct 2014 03:29:44 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.58]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Thu, 30 Oct 2014 22:29:44 -0500 From: "Eric Voit (evoit)" To: Andy Bierman , "Alexander Clemm (alex)" Thread-Topic: [netmod] YANG model containing both device and domain config (was RE: New revision of YANG mount draft) Thread-Index: AQHP9IB8AYuY9U0/8UKg51uu0KCQYZxJGGvggABhvICAADDBgIAABtSA///RK4A= Date: Fri, 31 Oct 2014 03:29:44 +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: [10.21.122.238] Content-Type: multipart/alternative; boundary="_000_EF64FF31F4C4384DBCE5D513A791C2B120A5AC8Exmbalnx11ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/scNxTzqqA1fqhrWRNWq1HUU6vo8 Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG model containing both device and domain config (was RE: New revision of YANG mount draft) X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 31 Oct 2014 03:29:51 -0000 --_000_EF64FF31F4C4384DBCE5D513A791C2B120A5AC8Exmbalnx11ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBGcm9tOiBBbmR5IEJpZXJtYW4sIE9jdG9iZXIgMzAsIDIwMTQgODo0MiBQTQ0KDQo+DQoNCj4g T24gVGh1LCBPY3QgMzAsIDIwMTQgYXQgNToxNyBQTSwgQWxleGFuZGVyIENsZW1tIChhbGV4KSA8 YWxleEBjaXNjby5jb208bWFpbHRvOmFsZXhAY2lzY28uY29tPj4NCg0KPiB3cm90ZToNCg0KPiA+ IEhpIEFuZHksDQoNCj4gPg0KDQo+ID4gY29udHJvbGxlcnMgLyBtb3VudCBjbGllbnRzIGhhdmUg dGhlIG9wdGlvbiB0byBzdWJzY3JpYmUgdG8gdXBkYXRlcyBpbiBhbnkgd2F5DQoNCj4gdGhleSBk ZWVtIGZpdC4NCg0KPg0KDQo+IERvZXMgdGhpcyBtZWFuIHRoZSBzZXJ2ZXJzIGhhdmUgdG8gaW1w bGVtZW50IHNldmVyYWwgd2F5cyB0byBkbyB0aGUgc2FtZQ0KDQo+IHRoaW5nLCBzbyB0aGUgY2xp ZW50IGNhbiBjaG9vc2U/DQoNCj4NCg0KPiBJIHRoaW5rIHdlIGRpc2FncmVlIG9uIHdoZXJlIHRo ZSBzeXN0ZW0gY29tcGxleGl0eSBiZWxvbmdzLg0KDQoNCg0KV2UgYXJlIHJlbW92aW5nIGNvbXBs ZXhpdHkgZnJvbSB0aGUgYXBwbGljYXRpb24gZGV2ZWxvcGVyIChzZWUgbXkgZWlnaHQgYnVsbGV0 cyBmcm9tIGVhcmxpZXIgdG9kYXkpLiAgV2UgYXJlIGFsbG93aW5nIGxheWVyZWQgYWJzdHJhY3Rp b25zIChhcyBzaG93biB2aWEgZHJhZnQtdHJpcGF0aHkpLiAgQm90aCBhcmUgd29ydGh5IGdvYWxz LiAgIElmIHlvdSB3YW50IHRvIGxlYXZlIHN1Y2ggY29tcGxleGl0eSBleHBvc2VkLCBub2JvZHkg aXMgc2F5aW5nIHlvdSBjYW5ub3QgZG8gdGhhdC4NCg0KPiAgSW4gZmFjdCwgb24tZGVtYW5kIHdp bGwgdXN1YWxseSBiZSB0aGUgZGVmYXVsdC4gIFBvbGxpbmcgb3B0aW1pemF0aW9ucyBhbG9uZyB0 aGUNCg0KPiBsaW5lcyB0aGF0IHlvdSBzdWdnZXN0IChpZi1tb2RpZmllZC1zaW5jZSkgbWFrZSBz ZW5zZSBhcyB3ZWxsLCBhbHRob3VnaA0KDQo+IHByZXN1bWFibHkgYWRkaW5nIGNvbXBsZXhpdHkg dG8gdGhlIHNlcnZlciBpbXBsZW1lbnRhdGlvbiBhcyB3ZWxsLg0KDQo+ID4NCg0KPiA+IEZvciBw dXNoaW5nIGRhdGEsIGl0IGlzIGRlZmluaXRlbHkgY29uY2VpdmFibGUgdG8gYWRkIGEgdGhyb3R0 bGUgbWVjaGFuaXNtIHRoYXQNCg0KPiB0aGUgY2xpZW50IGNhbiB1c2UuICBUaGUgc2ltcGxlc3Qg bWVjaGFuaXNtIG9mIGNvdXJzZSBpcyB0byBkaW1lbnNpb24gdGhlDQoNCj4gbWluaW11bSBpbnRl cnZhbCBiZXR3ZWVuIHVwZGF0ZXMgYXMgbmVlZGVkLg0KDQo+ID4NCg0KPiA+IFRvIGFkZCB0byB0 aGUgRXJpYydzIGVhcmxpZXIgcG9pbnQsIHRoZSBpc3N1ZSBpcyBub3QgdGhhdCB5b3UgY291bGQg bm90IGFjaGlldmUgdGhlDQoNCj4gc2FtZSBhcHBsaWNhdGlvbiBnb2luZyB0byB0aGUgZGlmZmVy ZW50IGRldmljZXMgZGlyZWN0bHkuICBUaGUgaXNzdWUgaXMgdGhhdCBpbiB0aGF0DQoNCj4gY2Fz ZSB5b3UgcHVzaCB0aGUgY29tcGxleGl0eSB0byB0aGUgYXBwbGljYXRpb24gZGV2ZWxvcGVyIG9m IGhhdmluZyB0byBkZWFsIHdpdGgNCg0KPiB0aGUgY29tcGxleGl0eSBvZiBkZWFsaW5nIHdpdGgg ZWFjaCBkZXZpY2UgaW5kaXZpZHVhbGx5LiAgTm90IGV2ZXJ5IHN5c3RlbSBtYXkNCg0KPiBzdXBw b3J0IG1vdW50IHBvaW50cywganVzdCBsaWtlIG5vdCBldmVyeSBzeXN0ZW0gbWF5IHN1cHBvcnQg YW55IG90aGVyIFlBTkcNCg0KPiBtb2R1bGUuICBCdXQgd2h5IGxpbWl0IHRob3NlIHRoYXQgYXJl IGFibGUgdG8gc3VwcG9ydCBpdCBmcm9tIGRvaW5nIHNvLCBpbg0KDQo+IHBhcnRpY3VsYXIgYXMg dGhlcmUgYXJlIGNsZWFybHkgYXBwbGljYXRpb25zIGFuZCBkZXBsb3ltZW50IHNjZW5hcmlvcyB3 aGVyZSB0aGlzDQoNCj4gaXMgbmVlZGVkIGFuZCBtYWtlcyBzZW5zZS4NCg0KPg0KDQo+DQoNCj4g VGhlIGFwcGxpY2F0aW9uIGRldmVsb3BlciBzdGlsbCBuZWVkcyB0byB1bmRlcnN0YW5kIFlBTkcg ZGF0YSB0byBkbyBhZ2dyZWdhdGlvbg0KDQo+IGFuZCBvdGhlciB1c2VmdWwgdGFza3MuICBCbGlu ZCBkYXRhIHJlcGxpY2F0aW9uIGlzIG5vdCB2ZXJ5IGltcG9ydGFudCwgY29tcGFyZWQgdG8NCg0K PiBhbGwgdGhlIG90aGVyIHN0dWZmIGEgY29udHJvbGxlciBjb3VsZCBiZSBkb2luZy4NCg0KDQoN ClRoZSBPcGVuRGF5bGlnaHQgY29udHJvbGxlciBoYXMgYWxyZWFkeSBpbXBsZW1lbnRlZDxodHRw Oi8vc2RudHV0b3JpYWxzLmNvbS9ob3ctdG8tYWNjZXNzLWRhdGEtaW4tbWQtc2FsLWZyb20tbW91 bnQtcG9pbnQvPiBNb3VudCBhcyBvbmUgb2YgaXRzIG1vc3QgZXNzZW50aWFsIGJhc2ljIGZ1bmN0 aW9ucy4gIElmIGl0IHdhc24ndCBpbXBvcnRhbnQsIGl0IHdvdWxkbid0IGhhdmUgYmVlbiBkb25l Lg0KDQoNCg0KVGhlIHF1ZXN0aW9uIGlzIG5vdCB3aGV0aGVyIFlhbmcgTW91bnQgaXMgZ29pbmcg dG8gaGFwcGVuLiAgSXQgaXMgd2hldGhlciB0aGUgSUVURiB3YW50cyB0byBiZSBpbnZvbHZlZC4N Cg0KDQoNCkVyaWMNCg0KPiA+DQoNCj4gPiAtLS0gQWxleA0KDQo+DQoNCj4NCg0KPiBBbmR5DQoN Cj4NCg0KPiA+DQoNCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQo+ID4gRnJvbTog bmV0bW9kIFttYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbmR5 DQoNCj4gPiBCaWVybWFuDQoNCj4gPiBTZW50OiBUaHVyc2RheSwgT2N0b2JlciAzMCwgMjAxNCAy OjIzIFBNDQoNCj4gPiBUbzogRXJpYyBWb2l0IChldm9pdCkNCg0KPiA+IENjOiBuZXRtb2RAaWV0 Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCg0KPiA+IFN1YmplY3Q6IFJlOiBbbmV0bW9k XSBZQU5HIG1vZGVsIGNvbnRhaW5pbmcgYm90aCBkZXZpY2UgYW5kIGRvbWFpbg0KDQo+ID4gY29u ZmlnICh3YXMgUkU6IE5ldyByZXZpc2lvbiBvZiBZQU5HIG1vdW50IGRyYWZ0KQ0KDQo+ID4NCg0K PiA+IEhpLA0KDQo+ID4NCg0KPiA+IEkgZ3Vlc3MgeW91IGFyZSBub3QgcmVhbGx5IHVuZGVyc3Rh bmRpbmcgbXkgcG9pbnQuDQoNCj4gPiBJIGFtIGNvbmNlcm5lZCBvbiB0aGUgY29tcGxleGl0eSBw dXNoZWQgb24gdGhlIGRldmljZXMgdG8gc29tZWhvdyBiZQ0KDQo+IGNvbmZpZ3VyZWQgdG8gZmlu ZCBlYWNoIGNvbnRyb2xsZXIsIHJlZ2lzdGVyIHNvbWUgZGF0YSBzdWJ0cmVlcyB0byBtb3VudCwg YW5kDQoNCj4gdGhlbiBwdXNoIGRhdGEgdG8gZWFjaCBjb250cm9sbGVyLg0KDQo+ID4NCg0KPiA+ IEkgZG9uJ3Qgc2VlIHRoYXQgaXQgc2F2ZXMgd29yayBhcyBtdWNoIGFzIG1vdmVzIGl0IGZyb20g YSByZWxhdGl2ZWx5IHNtYWxsDQoNCj4gbnVtYmVyIG9mIGNvbnRyb2xsZXJzIHRvIGEgbGFyZ2Ug bnVtYmVyIG9mIHNlcnZlcnMuICBBcmUgb3BlcmF0b3JzIGdvaW5nIHRvDQoNCj4gY29uZmlndXJl IHRoZSBkZXZpY2VzIG9yIGFyZSB0aGUgY29udHJvbGxlcnMgZ29pbmcgdG8gY29uZmlndXJlIHRo ZW1zZWx2ZXMgaW4NCg0KPiBlYWNoIHNlcnZlcj8gU2VlbXMgdG9vIGNvbXBsaWNhdGVkIHRvIG1l Lg0KDQo+ID4NCg0KPiA+IEkgdGhpbmsgdGhlIHBvbGxpbmcgY2FuIGJlIG9wdGltaXplZCAoSWYt TWF0Y2gsIElmLU1vZGlmaWVkLVNpbmNlLCBldGMuKS4NCg0KPiA+IFRoaXMgYXBwcm9hY2ggKGFs cmVhZHkgaW4gUkVTVENPTkYsIGJ1dCByZWFsbHkgb25seSBmb3IgY29uZmlnPXRydWUpIGNvdWxk IGJlDQoNCj4gYXBwbGllZCB0byBvcGVyYXRpb25hbCBzdGF0ZSBhcyB3ZWxsLg0KDQo+ID4NCg0K PiA+IFRoZXJlIG5lZWRzIHRvIGJlIGEgbWluaW11bSB1cGRhdGUgaW50ZXJ2YWwgb3IgdGhlIGNv bnRyb2xsZXJzIGNhbiBnZXQNCg0KPiBvdmVycnVuIHdpdGggcHVzaGVkIGRhdGEuICBJTU8gdGhl IGNvbnRyb2xsZXJzIHNob3VsZCBiZSBwb2xsaW5nIGZvciBjaGFuZ2VzIGF0DQoNCj4gdGhlIHJh dGUgdGhleSB3YW50IGRhdGEuDQoNCj4gPg0KDQo+ID4gSWYgdGhlIG9wZXJhdGlvbmFsIHN0YXRl IGNoYW5nZXMgaW4gc29tZXdheSB0aGF0IGlzIGludGVyZXN0aW5nIHRvIHRoZSBvcGVyYXRvciwN Cg0KPiB0aGVuIHRoZSB0cmFkaXRpb25hbCBhcHByb2FjaCBvZiBkZWZpbmluZyBhbmQgc2VuZGlu ZyBhIG5vdGlmaWNhdGlvbiBldmVudCB3b3Jrcw0KDQo+IGZpbmUuDQoNCj4gPg0KDQo+ID4NCg0K PiA+IEFuZHkNCg0KPiA+DQoNCj4gPg0KDQo+ID4NCg0KPiA+DQoNCj4gPg0KDQo+ID4gT24gVGh1 LCBPY3QgMzAsIDIwMTQgYXQgMTo0OCBQTSwgRXJpYyBWb2l0IChldm9pdCkgPGV2b2l0QGNpc2Nv LmNvbTxtYWlsdG86ZXZvaXRAY2lzY28uY29tPj4gd3JvdGU6DQoNCj4gPj4gRnJvbTogVGhvbWFz IEQuIE5hZGVhdSwgT2N0b2JlciAzMCwgMjAxNCA0OjMxIFBNDQoNCj4gPj4NCg0KPiA+PiBPbiBP Y3QgMzAsIDIwMTQ6NDoxNyBQTSwgYXQgNDoxNyBQTSwgQW5keSBCaWVybWFuDQoNCj4gPj4gPGFu ZHlAeXVtYXdvcmtzLmNvbTxtYWlsdG86YW5keUB5dW1hd29ya3MuY29tPj4NCg0KPiA+PiB3cm90 ZToNCg0KPiA+Pg0KDQo+ID4+DQoNCj4gPj4NCg0KPiA+PiBPbiBUaHUsIE9jdCAzMCwgMjAxNCBh dCAxMjoxNiBQTSwgRXJpYyBWb2l0IChldm9pdCkgPGV2b2l0QGNpc2NvLmNvbTxtYWlsdG86ZXZv aXRAY2lzY28uY29tPj4gd3JvdGU6DQoNCj4gPj4NCg0KPiA+PiBBbmR5LA0KDQo+ID4+DQoNCj4g Pj4NCg0KPiA+Pg0KDQo+ID4+IFR3byB3ZWVrcyBhZ28gSSBwcm9taXNlZCBhIHVzZWZ1bCBZQU5H IG1vZGVsIHdoaWNoIGV4cG9zZXMgYm90aA0KDQo+ID4+IGRldmljZSBhbmQgZG9tYWluIGNvbmZp Zy4gIFRoZSBtb2RlbCBpcyBoZXJlOg0KDQo+ID4+DQoNCj4gPj4gaHR0cDovL3d3dy5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtdHJpcGF0aHktY2xvdWQtc2xhLXlhbmctbW9kDQoNCj4g Pj4gZQ0KDQo+ID4+IGwtMDAudHh0DQoNCj4gPj4NCg0KPiA+Pg0KDQo+ID4+DQoNCj4gPj4gQSBz aW1wbGUg4oCcQ2xvdWQgUG9saWNlcuKAnSBhcHBsaWNhdGlvbiBjYW4gc2l0IGNvbXBsZXRlbHkg dXBvbiB0aGUNCg0KPiA+PiBtb2RlbC4gIFRoZSBhbGdvcml0aG0gbWlnaHQgYmU6DQoNCj4gPj4N Cg0KPiA+Pg0KDQo+ID4+DQoNCj4gPj4gKDEpIFRoZSBPcGVyYXRvciBlbnRlcnMgYSBtYXhpbXVt IGRhdGEgcmF0ZSBhY3Jvc3MgYSBmZWRlcmF0aW9uDQoNCj4gPj4gKENsb3VkKSBvZiBkZXZpY2Vz DQoNCj4gPj4NCg0KPiA+Pg0KDQo+ID4+DQoNCj4gPj4gKDIpIFN1bSB0aGUgY3VycmVudCBiYW5k d2lkdGggYWNyb3NzIHRoZSBjb2xsZWN0aW9uIG9mIGRldmljZXMgaW4gdGhlDQoNCj4gPj4gZmVk ZXJhdGlvbiAodmlhIFJGQyA3MjIzIFlBTkcgZGV2aWNlIGludGVyZmFjZSBzdGF0aXN0aWNzKQ0K DQo+ID4+DQoNCj4gPj4NCg0KPiA+Pg0KDQo+ID4+ICgzKSBQb2xpY2VkIEJhbmR3aWR0aCByYXRl IGVhY2ggZGV2aWNlID0gKGN1cnJlbnQgdHJhZmZpYyB0byB0aGUNCg0KPiA+PiBkZXZpY2UgLyBj dXJyZW50IGZlZGVyYXRpb24gdHJhZmZpYykgKiBPcGVyYXRvciBlc3RhYmxpc2hlZA0KDQo+ID4+ IEZlZGVyYXRpb24gTWF4IHJhdGUNCg0KPiA+Pg0KDQo+ID4+DQoNCj4gPj4NCg0KPiA+PiAoNCkg R28gYmFjayB0byBzdGVwICgyKQ0KDQo+ID4+DQoNCj4gPj4NCg0KPiA+Pg0KDQo+ID4+IElmIHdl IHNldCB0aGUgZmVkZXJhdGlvbiBiYW5kd2lkdGggdG8gMTAwTUIvcywgYW5kIHRoZW4gdmFyeSB0 aGUNCg0KPiA+PiBvZmZlcmVkIHRvIHR3byBkZXZpY2VzLCB0aGUgcmVzdWx0IGxvb2tzIGxpa2Ug dGhpcy4NCg0KPiA+Pg0KDQo+ID4+IDxpbWFnZTAwMy5wbmc+DQoNCj4gPj4NCg0KPiA+Pg0KDQo+ ID4+DQoNCj4gPj4gRWZmZWN0aXZlbHkgd2UgYXJlIHNob3dpbmcgdGhlIGNvbmZpZyBvZiBkb21h aW4gYW5kIGRldmljZSB1cG9uIG9uZSBncmFwaC4NCg0KPiA+PiBBbmQgdGhlIGRldmljZSBjb25m aWcgaXMgdmFyeWluZyBvdmVyIHRpbWUgYmFzZWQgb24gUGVlciBNb3VudGVkIFJGQw0KDQo+ID4+ IDcyMjMgWUFORyBpbnRlcmZhY2Ugc3RhdGlzdGljcy4NCg0KPiA+Pg0KDQo+ID4+DQoNCj4gPj4N Cg0KPiA+PiBUaGlzIGlzIHJ1bm5pbmcgY29kZS4gIFRoZSBjb2RlIGlzIHBvcnRhYmxlIHNvIHRo YXQgaXQgY2FuIHJ1biBvbiBhDQoNCj4gPj4gY29udHJvbGxlciwgb3IgaXQgY2FuIHJ1biB1cG9u IGEgZGVzaWduYXRlZCByb3V0ZXIgd2l0aGluIHRoZSBmZWRlcmF0aW9uLg0KDQo+ID4+DQoNCj4g Pj4NCg0KPiA+Pg0KDQo+ID4+DQoNCj4gPj4NCg0KPiA+Pg0KDQo+ID4+DQoNCj4gPj4gSSBkb24n dCB0aGluayB0aGUgYXBwbGljYXRpb24gbmVlZHMgWUFORyBNb3VudCB0byBhY2NvbXBsaXNoIGl0 cyB0YXNrLg0KDQo+ID4+DQoNCj4gPj4gVGhpcyBoYXMgbm90aGluZyB0byBkbyB3aXRoIHRoZSBp c3N1ZSBvZiBkZXZpY2UtY29uZmlndXJlZCB2cy4NCg0KPiA+Pg0KDQo+ID4+IGNvbnRyb2xsZXIt Y29uZmlndXJlZCBkYXRhIGNvbGxlY3Rpb24uICBBbnkgY29udHJvbGxlciBjYW4gY29sbGVjdA0K DQo+ID4+IHNvbWUgc3VidHJlZXMNCg0KPiA+Pg0KDQo+ID4+IGZyb20gZWFjaCBkZXZpY2UgYW5k IHVzZSB0aGUgZGF0YSBzb21laG93Lg0KDQo+ID4+DQoNCj4gPj4NCg0KPiA+Pg0KDQo+ID4+ICAg ICAgICAgICBUaGUgcG9pbnQgb2YgbW91bnQgaXNu4oCZdCBmb3IgdGhlIGNvbnRyb2xsZXLigJlz IGNvbnZlbmllbmNlDQoNCj4gPj4gcGVyIHNlOyBpdHMgZm9yIHRoZSBhcHAgdGhhdCB3YW50cyB0 byBnZXQgYXQgdGhvc2Ugc3RhdHMuIFRoZSBhcHANCg0KPiA+PiBvbmx5IG5lZWRzIHRvIHRhbGsg dG8gYSBzaW5nbGUgY29udHJvbGxlci4NCg0KPiA+Pg0KDQo+ID4+DQoNCj4gPj4NCg0KPiA+PiA8 RXJpYz4gIEFncmVlLiAgIEl0IGlzICpwb3NzaWJsZSogdG8gZG8gc29tZSBvZiB0aGlzIHdpdGgg ZXhpc3RpbmcgTmV0Y29uZi4NCg0KPiA+PiBCdXQgaXQgZ2V0cyB1Z2x5LiAgQXBwbGljYXRpb24g ZGV2ZWxvcGVycyBsb3NlIHRoZSBmb2xsb3dpbmcgYmVuZWZpdHM6DQoNCj4gPj4NCg0KPiA+Pg0K DQo+ID4+DQoNCj4gPj4gQXBwbGljYXRpb24gU2ltcGxpZmljYXRpb24NCg0KPiA+Pg0KDQo+ID4+ IOKAoiBNYWpvciBjb2RlIHNpemUgcmVkdWN0aW9uIOKGkiBkYXRhIGFjY2VzcyBvbmx5IHRvIGxv Y2FsIERhdGFzdG9yZQ0KDQo+ID4+DQoNCj4gPj4g4oCiIENhY2hpbmcgYW5kIHBvbGxpbmcgYmVj b21lcyBoaWRkZW4gaW5mcmFzdHJ1Y3R1cmUNCg0KPiA+Pg0KDQo+ID4+DQoNCj4gPj4NCg0KPiA+ PiBBcHBsaWNhdGlvbiBSb2J1c3RuZXNzDQoNCj4gPj4NCg0KPiA+PiDigKIgRGlzdHJpYnV0ZWQg WUFORyBvYmplY3RzIGF2YWlsYWJsZSB0byBhcHBsaWNhdGlvbnMgd2l0aG91dCBuZWVkaW5nDQoN Cj4gPj4gdG8gYWNxdWlyZSB0aGUgZGF0YSB0aGVtc2VsdmVzDQoNCj4gPj4NCg0KPiA+PiDigKIg Q2FuIHJ1biBiZXR3ZWVuIE5ldHdvcmsgRWxlbWVudHMsIHdoZXJlIHNvbWUgY29udHJvbGxlcnMg YWxyZWFkeQ0KDQo+ID4+IHJlc2lkZQ0KDQo+ID4+DQoNCj4gPj4NCg0KPiA+Pg0KDQo+ID4+IEFw cGxpY2F0aW9uIFBlcmZvcm1hbmNlDQoNCj4gPj4NCg0KPiA+PiDigKIgT24tY2hhbmdlICYgUGVy aW9kaWMgb2JqZWN0IFB1Yi9TdWIgd2l0aCB0cmFuc3BhcmVudCBjYWNoaW5nDQoNCj4gPj4NCg0K PiA+PiDigKIgU2NhbGluZyBiZW5lZml0czogYWJpbGl0eSB0byBjYXNjYWRlIHVwZGF0ZXMgYWNy b3NzIG11bHRpcGxlIHRpZXJzDQoNCj4gPj4gb2YgTW91bnQNCg0KPiA+Pg0KDQo+ID4+IE1pc2Nv bmZpZ3VyYXRpb24gVHlwZXMgRWxpbWluYXRlZA0KDQo+ID4+DQoNCj4gPj4g4oCiIEF1dGhvcml0 YXRpdmUgY29weSBpbiBGZWRlcmF0aW9uIHRyYW5zcGFyZW50bHkgdXNlZA0KDQo+ID4+DQoNCj4g Pj4g4oCiIE1vdW50ICYgbW9uaXRvciB0aGUgYWN0dWFsIHN0YXRlIG9mIHRoZSBuZXR3b3JrIChh cHBzIGRvbuKAmXQganVzdA0KDQo+ID4+IGdldCBvbmUtdGltZSDigJxBQ0vigJ0pLg0KDQo+ID4+ DQoNCj4gPj4gSW4gb3RoZXIgd29yZHMsIHdlIGFyZSB0cnlpbmcgdG8gbWFrZSBsaWZlIGVhc2ll ciBmb3IgQXBwbGljYXRpb24NCg0KPiA+PiBEZXZlbG9wZXJzLiAgRXNwZWNpYWxseSBkZXZlbG9w ZXJzIG9mIGFwcGxpY2F0aW9ucyB3aGljaCBzcGFuDQoNCj4gPj4gZmVkZXJhdGlvbnMgb2YgbmV0 d29yayBkZXZpY2VzLg0KDQo+ID4+DQoNCj4gPj4NCg0KPiA+Pg0KDQo+ID4+IEVyaWMNCg0KPiA+ Pg0KDQo+ID4+DQoNCj4gPj4NCg0KPiA+PiBKdXN0IHVzZSBORVRDT05GIG9yDQoNCj4gPj4NCg0K PiA+PiBSRVNUQ09ORiBhcy1pcy4gIEl0IHJlYWxseSBjb21wbGljYXRlcyB0aGUgYXJjaGl0ZWN0 dXJlIHRvIHVzZSBtb3VudA0KDQo+ID4+IHBvaW50cywNCg0KPiA+Pg0KDQo+ID4+IGVzcGVjaWFs bHkgaWYgZXZlcnkgY29udHJvbGxlciBpcyBnb2luZyB0byByZXBsaWNhdGUgZGF0YSBmcm9tIGV2 ZXJ5DQoNCj4gPj4gc2VydmVyIGluDQoNCj4gPj4NCg0KPiA+PiBkaWZmZXJlbnQgd2F5cywgYW5k IGZvcmNlIHRoZSBkZXZpY2VzIHRvIGRvIGFsbCB0aGUgd29yay4NCg0KPiA+Pg0KDQo+ID4+DQoN Cj4gPj4NCg0KPiA+PiAgICAgICAgICAgSXQgY29tcGxpY2F0ZXMgaXQgZm9yIHRoZSBjb250cm9s bGVyIGJ1dCBoYXMgdGhlIGFkdmFudGFnZQ0KDQo+ID4+IG9mIHNpbXBsaWZ5aW5nIGl0IGZvciBw b3RlbnRpYWxseSBtYW55LCBtYW55IG1vcmUgYXBwbGljYXRpb25zIHRoYXQNCg0KPiA+PiByZWx5 IG9uIHRoZSBjb250cm9sbGVy4oCZcyBhYnN0cmFjdGlvbiBvZiB0aGUgdW5pdmVyc2UuDQoNCj4g Pj4NCg0KPiA+Pg0KDQo+ID4+DQoNCj4gPj4gICAgICAgICAgIOKAlFRvbQ0KDQo+ID4+DQoNCj4g Pj4NCg0KPiA+Pg0KDQo+ID4+DQoNCj4gPj4NCg0KPiA+Pg0KDQo+ID4+DQoNCj4gPj4NCg0KPiA+ Pg0KDQo+ID4+DQoNCj4gPj4NCg0KPiA+Pg0KDQo+ID4+DQoNCj4gPj4gRXJpYw0KDQo+ID4+DQoN Cj4gPj4NCg0KPiA+Pg0KDQo+ID4+DQoNCj4gPj4NCg0KPiA+PiBBbmR5DQoNCj4gPj4NCg0KPiA+ Pg0KDQo+ID4+DQoNCj4gPj4NCg0KPiA+Pg0KDQo+ID4+DQoNCj4gPj4NCg0KPiA+PiBGcm9tOiBB bmR5IEJpZXJtYW4sIE9jdG9iZXIgMTQsIDIwMTQgNjo0NyBQTQ0KDQo+ID4+DQoNCj4gPj4gPHNu aXA+DQoNCj4gPj4NCg0KPiA+Pg0KDQo+ID4+DQoNCj4gPj4gSSBkbyBub3QgYWdyZWUgdGhhdCB0 aGUgImNvbGxlY3Rpb24gb2YgZGV2aWNlIG1vZGVscyIgaXMgYSB2ZXJ5DQoNCj4gPj4gaW50ZXJl c3Rpbmcgc29sdXRpb24NCg0KPiA+Pg0KDQo+ID4+IGZvciBuZXR3b3JrIG1hbmFnZW1lbnQgYXQg dGhlIG5ldHdvcmsgbGV2ZWwuICBXZSBoYXZlIGRhYmJsZWQgd2l0aA0KDQo+ID4+ICJuZXR3b3Jr LXdpZGUiDQoNCj4gPj4NCg0KPiA+PiBjb25maWd1cmF0aW9uIGEgY291cGxlIHRpbWVzLCBvbmx5 IHRvIGRyb3AgdGhlIGlzc3VlLiAgSU1PIHRoZSBtb2RlbHMNCg0KPiA+PiBhdCB0aGlzIGxldmVs DQoNCj4gPj4NCg0KPiA+PiBkZXNjcmliZSB0aGUgbmV0d29yaywgbm90IHRoZSBkZXZpY2VzLiAg VGhlcmUgaXMgc29tZSBnbHVlIHRoYXQgdGVsbHMNCg0KPiA+PiB0aGUgY29udHJvbGxlciB3aGF0 IGRldmljZXMgYXJlDQoNCj4gPj4NCg0KPiA+PiBhdmFpbGFibGUsIGFuZCBob3cgdG8gdGFsayB0 byB0aGVtLCBidXQgdGhlIGdvYWwgaXMgdG8gaGFuZGxlIHRoZQ0KDQo+ID4+IGRldmljZSBsZXZl bCBkZXRhaWxzDQoNCj4gPj4NCg0KPiA+PiBhcyBwYXJ0IG9mIHRoZSBjb250cm9sbGVyIGRhdGEg bW9kZWwgaW1wbGVtZW50YXRpb24uDQoNCj4gPj4NCg0KPiA+Pg0KDQo+ID4+DQoNCj4gPj4gPEVy aWM+IFdlIGhhdmUgYSBZQU5HIG1vZGVsIGZvciBDbG91ZCBQb2xpY2VyIGFuZCBERG9TIFRocmVz aG9sZGluZw0KDQo+IHdoaWNoDQoNCj4gPj4gZXhwb3NlcyB0aGUgaW50ZXJwbGF5IG9mIGRvbWFp biBhbmQgZGV2aWNlIHZpZXcuICAgSSB3aWxsIHN0cml2ZSB0byBnZXQgaXQNCg0KPiA+PiBwb3N0 ZWQgYXMgYSBuZXcgZHJhZnQgYmVmb3JlIE9jdCAyN3RoLiAgKElFVEYgOTEgY3V0LW9mZiBkYXRl LikNCg0KPiA+Pg0KDQo+ID4+DQoNCj4gPj4NCg0KPiA+PiBFcmljDQoNCj4gPj4NCg0KPiA+Pg0K DQo+ID4+DQoNCj4gPj4NCg0KPiA+Pg0KDQo+ID4+DQoNCj4gPj4NCg0KPiA+Pg0KDQo+ID4+DQoN Cj4gPj4gRXJpYyBWb2l0DQoNCj4gPj4NCg0KPiA+PiBQcmluY2lwYWwgRW5naW5lZXIgLSBDU0cN Cg0KPiA+Pg0KDQo+ID4+DQoNCj4gPj4NCg0KPiA+Pg0KDQo+ID4+DQoNCj4gPj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KPiA+PiBuZXRtb2QgbWFp bGluZyBsaXN0DQoNCj4gPj4gbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+ DQoNCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0K PiA+Pg0KDQo+ID4+DQoNCj4gPg0KDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCg0KPiA+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCg0KPiA+IG5ldG1v ZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0KDQo+ID4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg== --_000_EF64FF31F4C4384DBCE5D513A791C2B120A5AC8Exmbalnx11ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWlu VGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQg Q2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLlBsYWlu VGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMTI5Ljc1cHQgMS4waW4g MTI5LjdwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IEZy b206IEFuZHkgQmllcm1hbiwgT2N0b2JlciAzMCwgMjAxNCA4OjQyIFBNPC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyA8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IE9u IFRodSwgT2N0IDMwLCAyMDE0IGF0IDU6MTcgUE0sIEFsZXhhbmRlciBDbGVtbSAoYWxleCkgJmx0 OzxhIGhyZWY9Im1haWx0bzphbGV4QGNpc2NvLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRv d3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmFsZXhAY2lzY28uY29tPC9zcGFuPjwvYT4mZ3Q7 PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyB3cm90ZTo8L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgSGkgQW5keSw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgY29u dHJvbGxlcnMgLyBtb3VudCBjbGllbnRzIGhhdmUgdGhlIG9wdGlvbiB0byBzdWJzY3JpYmUgdG8g dXBkYXRlcyBpbiBhbnkgd2F5PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyB0aGV5 IGRlZW0gZml0LjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBEb2VzIHRoaXMgbWVhbiB0aGUgc2VydmVycyBoYXZlIHRv IGltcGxlbWVudCBzZXZlcmFsIHdheXMgdG8gZG8gdGhlIHNhbWU8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7IHRoaW5nLCBzbyB0aGUgY2xpZW50IGNhbiBjaG9vc2U/PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7IEkgdGhpbmsgd2UgZGlzYWdyZWUgb24gd2hlcmUgdGhlIHN5c3RlbSBjb21wbGV4aXR5IGJl bG9uZ3MuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5XZSBhcmUgcmVtb3ZpbmcgY29tcGxleGl0eSBmcm9t IHRoZSBhcHBsaWNhdGlvbiBkZXZlbG9wZXIgKHNlZSBteSBlaWdodCBidWxsZXRzIGZyb20gZWFy bGllciB0b2RheSkuJm5ic3A7IFdlIGFyZSBhbGxvd2luZyBsYXllcmVkIGFic3RyYWN0aW9ucyAo YXMgc2hvd24gdmlhIGRyYWZ0LXRyaXBhdGh5KS4mbmJzcDsgQm90aCBhcmUgd29ydGh5IGdvYWxz LiZuYnNwOyAmbmJzcDtJZiB5b3Ugd2FudCB0byBsZWF2ZSBzdWNoIGNvbXBsZXhpdHkNCiBleHBv c2VkLCBub2JvZHkgaXMgc2F5aW5nIHlvdSBjYW5ub3QgZG8gdGhhdC48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgJm5ic3A7SW4gZmFjdCwgb24tZGVtYW5kIHdpbGwgdXN1YWxseSBiZSB0aGUgZGVmYXVsdC4m bmJzcDsgUG9sbGluZyBvcHRpbWl6YXRpb25zIGFsb25nIHRoZTwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgbGluZXMgdGhhdCB5b3Ugc3VnZ2VzdCAoaWYtbW9kaWZpZWQtc2luY2Up IG1ha2Ugc2Vuc2UgYXMgd2VsbCwgYWx0aG91Z2g8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7IHByZXN1bWFibHkgYWRkaW5nIGNvbXBsZXhpdHkgdG8gdGhlIHNlcnZlciBpbXBsZW1l bnRhdGlvbiBhcyB3ZWxsLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0Ozwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBGb3IgcHVzaGluZyBkYXRhLCBp dCBpcyBkZWZpbml0ZWx5IGNvbmNlaXZhYmxlIHRvIGFkZCBhIHRocm90dGxlIG1lY2hhbmlzbSB0 aGF0PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyB0aGUgY2xpZW50IGNhbiB1c2Uu Jm5ic3A7IFRoZSBzaW1wbGVzdCBtZWNoYW5pc20gb2YgY291cnNlIGlzIHRvIGRpbWVuc2lvbiB0 aGU8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IG1pbmltdW0gaW50ZXJ2YWwgYmV0 d2VlbiB1cGRhdGVzIGFzIG5lZWRlZC48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgVG8gYWRkIHRvIHRo ZSBFcmljJ3MgZWFybGllciBwb2ludCwgdGhlIGlzc3VlIGlzIG5vdCB0aGF0IHlvdSBjb3VsZCBu b3QgYWNoaWV2ZSB0aGU8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHNhbWUgYXBw bGljYXRpb24gZ29pbmcgdG8gdGhlIGRpZmZlcmVudCBkZXZpY2VzIGRpcmVjdGx5LiZuYnNwOyBU aGUgaXNzdWUgaXMgdGhhdCBpbiB0aGF0PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyBjYXNlIHlvdSBwdXNoIHRoZSBjb21wbGV4aXR5IHRvIHRoZSBhcHBsaWNhdGlvbiBkZXZlbG9w ZXIgb2YgaGF2aW5nIHRvIGRlYWwgd2l0aDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgdGhlIGNvbXBsZXhpdHkgb2YgZGVhbGluZyB3aXRoIGVhY2ggZGV2aWNlIGluZGl2aWR1YWxs eS4mbmJzcDsgTm90IGV2ZXJ5IHN5c3RlbSBtYXk8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7IHN1cHBvcnQgbW91bnQgcG9pbnRzLCBqdXN0IGxpa2Ugbm90IGV2ZXJ5IHN5c3RlbSBt YXkgc3VwcG9ydCBhbnkgb3RoZXIgWUFORzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgbW9kdWxlLiZuYnNwOyBCdXQgd2h5IGxpbWl0IHRob3NlIHRoYXQgYXJlIGFibGUgdG8gc3Vw cG9ydCBpdCBmcm9tIGRvaW5nIHNvLCBpbjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgcGFydGljdWxhciBhcyB0aGVyZSBhcmUgY2xlYXJseSBhcHBsaWNhdGlvbnMgYW5kIGRlcGxv eW1lbnQgc2NlbmFyaW9zIHdoZXJlIHRoaXM8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7IGlzIG5lZWRlZCBhbmQgbWFrZXMgc2Vuc2UuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyA8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgVGhlIGFwcGxpY2F0aW9uIGRldmVsb3BlciBzdGlsbCBuZWVk cyB0byB1bmRlcnN0YW5kIFlBTkcgZGF0YSB0byBkbyBhZ2dyZWdhdGlvbjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgYW5kIG90aGVyIHVzZWZ1bCB0YXNrcy4mbmJzcDsgQmxpbmQg ZGF0YSByZXBsaWNhdGlvbiBpcyBub3QgdmVyeSBpbXBvcnRhbnQsIGNvbXBhcmVkIHRvPC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBhbGwgdGhlIG90aGVyIHN0dWZmIGEgY29udHJv bGxlciBjb3VsZCBiZSBkb2luZy48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoZSBPcGVuRGF5bGlnaHQg Y29udHJvbGxlciBoYXMgPGEgaHJlZj0iaHR0cDovL3NkbnR1dG9yaWFscy5jb20vaG93LXRvLWFj Y2Vzcy1kYXRhLWluLW1kLXNhbC1mcm9tLW1vdW50LXBvaW50LyI+DQphbHJlYWR5IGltcGxlbWVu dGVkPC9hPiBNb3VudCBhcyBvbmUgb2YgaXRzIG1vc3QgZXNzZW50aWFsIGJhc2ljIGZ1bmN0aW9u cy4mbmJzcDsgSWYgaXQgd2Fzbid0IGltcG9ydGFudCwgaXQgd291bGRuJ3QgaGF2ZSBiZWVuIGRv bmUuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGUgcXVlc3Rpb24gaXMg bm90IHdoZXRoZXIgWWFuZyBNb3VudCBpcyBnb2luZyB0byBoYXBwZW4uJm5ic3A7IEl0IGlzIHdo ZXRoZXIgdGhlIElFVEYgd2FudHMgdG8gYmUgaW52b2x2ZWQuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPkVyaWM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgJmd0OyAtLS0gQWxleDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7IEFuZHk8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 IDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OzwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBGcm9tOiBuZXRtb2QgWzxhIGhyZWY9Im1h aWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3Rl eHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPm1haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZzwv c3Bhbj48L2E+XSBPbiBCZWhhbGYgT2YgQW5keTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgJmd0OyBCaWVybWFuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7 IFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDMwLCAyMDE0IDI6MjMgUE08L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgVG86IEVyaWMgVm9pdCAoZXZvaXQpPC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IENjOiA8YSBocmVmPSJtYWlsdG86bmV0bW9kQGll dGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9u ZSI+bmV0bW9kQGlldGYub3JnPC9zcGFuPjwvYT48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7ICZndDsgU3ViamVjdDogUmU6IFtuZXRtb2RdIFlBTkcgbW9kZWwgY29udGFpbmluZyBi b3RoIGRldmljZSBhbmQgZG9tYWluPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAm Z3Q7IGNvbmZpZyAod2FzIFJFOiBOZXcgcmV2aXNpb24gb2YgWUFORyBtb3VudCBkcmFmdCk8L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7ICZndDsgSGksPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAm Z3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IEkgZ3Vlc3MgeW91IGFy ZSBub3QgcmVhbGx5IHVuZGVyc3RhbmRpbmcgbXkgcG9pbnQuPC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyAmZ3Q7IEkgYW0gY29uY2VybmVkIG9uIHRoZSBjb21wbGV4aXR5IHB1c2hl ZCBvbiB0aGUgZGV2aWNlcyB0byBzb21laG93IGJlPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyBjb25maWd1cmVkIHRvIGZpbmQgZWFjaCBjb250cm9sbGVyLCByZWdpc3RlciBzb21l IGRhdGEgc3VidHJlZXMgdG8gbW91bnQsIGFuZDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgdGhlbiBwdXNoIGRhdGEgdG8gZWFjaCBjb250cm9sbGVyLjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg Jmd0OyBJIGRvbid0IHNlZSB0aGF0IGl0IHNhdmVzIHdvcmsgYXMgbXVjaCBhcyBtb3ZlcyBpdCBm cm9tIGEgcmVsYXRpdmVseSBzbWFsbDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg bnVtYmVyIG9mIGNvbnRyb2xsZXJzIHRvIGEgbGFyZ2UgbnVtYmVyIG9mIHNlcnZlcnMuJm5ic3A7 IEFyZSBvcGVyYXRvcnMgZ29pbmcgdG88L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 IGNvbmZpZ3VyZSB0aGUgZGV2aWNlcyBvciBhcmUgdGhlIGNvbnRyb2xsZXJzIGdvaW5nIHRvIGNv bmZpZ3VyZSB0aGVtc2VsdmVzIGluPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBl YWNoIHNlcnZlcj8gU2VlbXMgdG9vIGNvbXBsaWNhdGVkIHRvIG1lLjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg Jmd0OyBJIHRoaW5rIHRoZSBwb2xsaW5nIGNhbiBiZSBvcHRpbWl6ZWQgKElmLU1hdGNoLCBJZi1N b2RpZmllZC1TaW5jZSwgZXRjLikuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAm Z3Q7IFRoaXMgYXBwcm9hY2ggKGFscmVhZHkgaW4gUkVTVENPTkYsIGJ1dCByZWFsbHkgb25seSBm b3IgY29uZmlnPXRydWUpIGNvdWxkIGJlPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyBhcHBsaWVkIHRvIG9wZXJhdGlvbmFsIHN0YXRlIGFzIHdlbGwuPC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyAmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAm Z3Q7IFRoZXJlIG5lZWRzIHRvIGJlIGEgbWluaW11bSB1cGRhdGUgaW50ZXJ2YWwgb3IgdGhlIGNv bnRyb2xsZXJzIGNhbiBnZXQ8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IG92ZXJy dW4gd2l0aCBwdXNoZWQgZGF0YS4mbmJzcDsgSU1PIHRoZSBjb250cm9sbGVycyBzaG91bGQgYmUg cG9sbGluZyBmb3IgY2hhbmdlcyBhdDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg dGhlIHJhdGUgdGhleSB3YW50IGRhdGEuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyAmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IElmIHRoZSBvcGVy YXRpb25hbCBzdGF0ZSBjaGFuZ2VzIGluIHNvbWV3YXkgdGhhdCBpcyBpbnRlcmVzdGluZyB0byB0 aGUgb3BlcmF0b3IsPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyB0aGVuIHRoZSB0 cmFkaXRpb25hbCBhcHByb2FjaCBvZiBkZWZpbmluZyBhbmQgc2VuZGluZyBhIG5vdGlmaWNhdGlv biBldmVudCB3b3JrczwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgZmluZS48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsg QW5keTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OzwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OzwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgJmd0OyBPbiBUaHUsIE9jdCAzMCwgMjAxNCBhdCAxOjQ4IFBNLCBFcmljIFZvaXQgKGV2 b2l0KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmV2b2l0QGNpc2NvLmNvbSI+PHNwYW4gc3R5bGU9ImNv bG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmV2b2l0QGNpc2NvLmNvbTwvc3Bh bj48L2E+Jmd0OyB3cm90ZTo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsm Z3Q7IEZyb206IFRob21hcyBELiBOYWRlYXUsIE9jdG9iZXIgMzAsIDIwMTQgNDozMSBQTTwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7IE9uIE9jdCAzMCwgMjAxNDo0OjE3IFBNLCBhdCA0OjE3 IFBNLCBBbmR5IEJpZXJtYW48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsm Z3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YW5keUB5dW1hd29ya3MuY29tIj48c3BhbiBzdHlsZT0i Y29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+YW5keUB5dW1hd29ya3MuY29t PC9zcGFuPjwvYT4mZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0 OyB3cm90ZTo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgJmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 ICZndDsmZ3Q7IE9uIFRodSwgT2N0IDMwLCAyMDE0IGF0IDEyOjE2IFBNLCBFcmljIFZvaXQgKGV2 b2l0KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmV2b2l0QGNpc2NvLmNvbSI+PHNwYW4gc3R5bGU9ImNv bG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmV2b2l0QGNpc2NvLmNvbTwvc3Bh bj48L2E+Jmd0OyB3cm90ZTo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsm Z3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyBBbmR5LDwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyAmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsgVHdv IHdlZWtzIGFnbyBJIHByb21pc2VkIGEgdXNlZnVsIFlBTkcgbW9kZWwgd2hpY2ggZXhwb3NlcyBi b3RoPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyBkZXZpY2UgYW5k IGRvbWFpbiBjb25maWcuJm5ic3A7IFRoZSBtb2RlbCBpcyBoZXJlOjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgJmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7ICZndDsmZ3Q7IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LXRyaXBhdGh5LWNsb3VkLXNsYS15YW5nLW1vZCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6 d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtdHJpcGF0aHktY2xvdWQtc2xhLXlhbmctbW9kPC9zcGFuPjwvYT48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7IGU8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7IGwtMDAudHh0PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgJmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyBBIHNpbXBsZSDigJxDbG91 ZCBQb2xpY2Vy4oCdIGFwcGxpY2F0aW9uIGNhbiBzaXQgY29tcGxldGVseSB1cG9uIHRoZTwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsgbW9kZWwuJm5ic3A7IFRoZSBh bGdvcml0aG0gbWlnaHQgYmU6PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7 Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDs8L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyAmZ3Q7Jmd0OyAoMSkgVGhlIE9wZXJhdG9yIGVudGVycyBhIG1heGltdW0gZGF0 YSByYXRlIGFjcm9zcyBhIGZlZGVyYXRpb248L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7ICZndDsmZ3Q7IChDbG91ZCkgb2YgZGV2aWNlczwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgJmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsm Z3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OzwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsgKDIpIFN1bSB0aGUgY3VycmVudCBiYW5k d2lkdGggYWNyb3NzIHRoZSBjb2xsZWN0aW9uIG9mIGRldmljZXMgaW4gdGhlPC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyBmZWRlcmF0aW9uICh2aWEgUkZDIDcyMjMg WUFORyBkZXZpY2UgaW50ZXJmYWNlIHN0YXRpc3RpY3MpPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyAmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0 OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyAoMykgUG9saWNlZCBCYW5kd2lkdGgg cmF0ZSBlYWNoIGRldmljZSA9IChjdXJyZW50IHRyYWZmaWMgdG8gdGhlPC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyBkZXZpY2UgLyBjdXJyZW50IGZlZGVyYXRpb24g dHJhZmZpYykgKiBPcGVyYXRvciBlc3RhYmxpc2hlZDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgJmd0OyZndDsgRmVkZXJhdGlvbiBNYXggcmF0ZTwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgJmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 ICZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OzwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsgKDQpIEdvIGJhY2sgdG8gc3Rl cCAoMik8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgJmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZn dDsmZ3Q7IElmIHdlIHNldCB0aGUgZmVkZXJhdGlvbiBiYW5kd2lkdGggdG8gMTAwTUIvcywgYW5k IHRoZW4gdmFyeSB0aGU8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7 IG9mZmVyZWQgdG8gdHdvIGRldmljZXMsIHRoZSByZXN1bHQgbG9va3MgbGlrZSB0aGlzLjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7ICZsdDtpbWFnZTAwMy5wbmcmZ3Q7PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgJmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsm Z3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyBFZmZlY3RpdmVs eSB3ZSBhcmUgc2hvd2luZyB0aGUgY29uZmlnIG9mIGRvbWFpbiBhbmQgZGV2aWNlIHVwb24gb25l IGdyYXBoLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsgQW5kIHRo ZSBkZXZpY2UgY29uZmlnIGlzIHZhcnlpbmcgb3ZlciB0aW1lIGJhc2VkIG9uIFBlZXIgTW91bnRl ZCBSRkM8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7IDcyMjMgWUFO RyBpbnRlcmZhY2Ugc3RhdGlzdGljcy48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 ICZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OzwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7IFRoaXMgaXMgcnVubmluZyBjb2RlLiZuYnNwOyBUaGUg Y29kZSBpcyBwb3J0YWJsZSBzbyB0aGF0IGl0IGNhbiBydW4gb24gYTwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgJmd0OyZndDsgY29udHJvbGxlciwgb3IgaXQgY2FuIHJ1biB1cG9u IGEgZGVzaWduYXRlZCByb3V0ZXIgd2l0aGluIHRoZSBmZWRlcmF0aW9uLjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7ICZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0 OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDs8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyAmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZn dDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7IEkgZG9uJ3QgdGhp bmsgdGhlIGFwcGxpY2F0aW9uIG5lZWRzIFlBTkcgTW91bnQgdG8gYWNjb21wbGlzaCBpdHMgdGFz ay48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyBUaGlzIGhhcyBub3RoaW5nIHRvIGRvIHdp dGggdGhlIGlzc3VlIG9mIGRldmljZS1jb25maWd1cmVkIHZzLjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgJmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 ICZndDsmZ3Q7IGNvbnRyb2xsZXItY29uZmlndXJlZCBkYXRhIGNvbGxlY3Rpb24uJm5ic3A7IEFu eSBjb250cm9sbGVyIGNhbiBjb2xsZWN0PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyAmZ3Q7Jmd0OyBzb21lIHN1YnRyZWVzPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyAmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsgZnJv bSBlYWNoIGRldmljZSBhbmQgdXNlIHRoZSBkYXRhIHNvbWVob3cuPC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgJmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgcG9pbnQgb2Yg bW91bnQgaXNu4oCZdCBmb3IgdGhlIGNvbnRyb2xsZXLigJlzIGNvbnZlbmllbmNlPC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyBwZXIgc2U7IGl0cyBmb3IgdGhlIGFw cCB0aGF0IHdhbnRzIHRvIGdldCBhdCB0aG9zZSBzdGF0cy4gVGhlIGFwcDwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsgb25seSBuZWVkcyB0byB0YWxrIHRvIGEgc2lu Z2xlIGNvbnRyb2xsZXIuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0 OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDs8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyAmZ3Q7Jmd0OyAmbHQ7RXJpYyZndDsmbmJzcDsgQWdyZWUuJm5ic3A7Jm5ic3A7IEl0 IGlzICpwb3NzaWJsZSogdG8gZG8gc29tZSBvZiB0aGlzIHdpdGggZXhpc3RpbmcgTmV0Y29uZi48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7IEJ1dCBpdCBnZXRzIHVn bHkuJm5ic3A7IEFwcGxpY2F0aW9uIGRldmVsb3BlcnMgbG9zZSB0aGUgZm9sbG93aW5nIGJlbmVm aXRzOjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDs8L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyAmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0 OyZndDsgQXBwbGljYXRpb24gU2ltcGxpZmljYXRpb248L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7ICZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7 Jmd0OyDigKIgTWFqb3IgY29kZSBzaXplIHJlZHVjdGlvbiDihpIgZGF0YSBhY2Nlc3Mgb25seSB0 byBsb2NhbCBEYXRhc3RvcmU8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsm Z3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyDigKIgQ2FjaGlu ZyBhbmQgcG9sbGluZyBiZWNvbWVzIGhpZGRlbiBpbmZyYXN0cnVjdHVyZTwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7ICZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0 OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsgQXBwbGljYXRpb24g Um9idXN0bmVzczwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDs8L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7IOKAoiBEaXN0cmlidXRlZCBZ QU5HIG9iamVjdHMgYXZhaWxhYmxlIHRvIGFwcGxpY2F0aW9ucyB3aXRob3V0IG5lZWRpbmc8L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7IHRvIGFjcXVpcmUgdGhlIGRh dGEgdGhlbXNlbHZlczwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDs8 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7IOKAoiBDYW4gcnVuIGJl dHdlZW4gTmV0d29yayBFbGVtZW50cywgd2hlcmUgc29tZSBjb250cm9sbGVycyBhbHJlYWR5PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyByZXNpZGU8L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyAmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0 OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7IEFwcGxpY2F0 aW9uIFBlcmZvcm1hbmNlPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0 OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsg4oCiIE9uLWNoYW5n ZSAmYW1wOyBQZXJpb2RpYyBvYmplY3QgUHViL1N1YiB3aXRoIHRyYW5zcGFyZW50IGNhY2hpbmc8 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyDigKIgU2NhbGluZyBiZW5lZml0czogYWJpbGl0 eSB0byBjYXNjYWRlIHVwZGF0ZXMgYWNyb3NzIG11bHRpcGxlIHRpZXJzPC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyBvZiBNb3VudDwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgJmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 ICZndDsmZ3Q7IE1pc2NvbmZpZ3VyYXRpb24gVHlwZXMgRWxpbWluYXRlZDwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7ICZndDsmZ3Q7IOKAoiBBdXRob3JpdGF0aXZlIGNvcHkgaW4gRmVkZXJhdGlvbiB0cmFu c3BhcmVudGx5IHVzZWQ8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7 PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyDigKIgTW91bnQgJmFt cDsgbW9uaXRvciB0aGUgYWN0dWFsIHN0YXRlIG9mIHRoZSBuZXR3b3JrIChhcHBzIGRvbuKAmXQg anVzdDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsgZ2V0IG9uZS10 aW1lIOKAnEFDS+KAnSkuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0 OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsgSW4gb3RoZXIgd29y ZHMsIHdlIGFyZSB0cnlpbmcgdG8gbWFrZSBsaWZlIGVhc2llciBmb3IgQXBwbGljYXRpb248L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7IERldmVsb3BlcnMuJm5ic3A7 IEVzcGVjaWFsbHkgZGV2ZWxvcGVycyBvZiBhcHBsaWNhdGlvbnMgd2hpY2ggc3BhbjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsgZmVkZXJhdGlvbnMgb2YgbmV0d29y ayBkZXZpY2VzLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDs8L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgJmd0OyZndDsgRXJpYzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZn dDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgJmd0OyZndDsgSnVzdCB1c2UgTkVUQ09ORiBvcjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgJmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 ICZndDsmZ3Q7IFJFU1RDT05GIGFzLWlzLiZuYnNwOyBJdCByZWFsbHkgY29tcGxpY2F0ZXMgdGhl IGFyY2hpdGVjdHVyZSB0byB1c2UgbW91bnQ8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7ICZndDsmZ3Q7IHBvaW50cyw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZn dDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyBlc3BlY2lh bGx5IGlmIGV2ZXJ5IGNvbnRyb2xsZXIgaXMgZ29pbmcgdG8gcmVwbGljYXRlIGRhdGEgZnJvbSBl dmVyeTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsgc2VydmVyIGlu PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsgZGlmZmVyZW50IHdheXMsIGFuZCBmb3JjZSB0 aGUgZGV2aWNlcyB0byBkbyBhbGwgdGhlIHdvcmsuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyAmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZn dDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJdCBjb21wbGljYXRlcyBpdCBmb3Ig dGhlIGNvbnRyb2xsZXIgYnV0IGhhcyB0aGUgYWR2YW50YWdlPC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyBvZiBzaW1wbGlmeWluZyBpdCBmb3IgcG90ZW50aWFsbHkg bWFueSwgbWFueSBtb3JlIGFwcGxpY2F0aW9ucyB0aGF0PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyAmZ3Q7Jmd0OyByZWx5IG9uIHRoZSBjb250cm9sbGVy4oCZcyBhYnN0cmFjdGlv biBvZiB0aGUgdW5pdmVyc2UuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7 Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDs8L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyAmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmbmJzcDvigJRUb208L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7ICZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0 OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDs8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyAmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZn dDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgJmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsm Z3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OzwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7ICZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7 Jmd0OyBFcmljPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OzwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyAmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDs8L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7IEFuZHk8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyAmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZn dDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgJmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsm Z3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyBGcm9tOiBBbmR5 IEJpZXJtYW4sIE9jdG9iZXIgMTQsIDIwMTQgNjo0NyBQTTwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgJmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZn dDsmZ3Q7ICZsdDtzbmlwJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0 OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgJmd0OyZndDsgSSBkbyBub3QgYWdyZWUgdGhhdCB0aGUgJnF1b3Q7Y29sbGVj dGlvbiBvZiBkZXZpY2UgbW9kZWxzJnF1b3Q7IGlzIGEgdmVyeTwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgJmd0OyZndDsgaW50ZXJlc3Rpbmcgc29sdXRpb248L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyAmZ3Q7Jmd0OyBmb3IgbmV0d29yayBtYW5hZ2VtZW50IGF0IHRoZSBuZXR3b3JrIGxl dmVsLiZuYnNwOyBXZSBoYXZlIGRhYmJsZWQgd2l0aDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgJmd0OyZndDsgJnF1b3Q7bmV0d29yay13aWRlJnF1b3Q7PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgJmd0OyZndDsgY29uZmlndXJhdGlvbiBhIGNvdXBsZSB0aW1lcywgb25seSB0byBkcm9w IHRoZSBpc3N1ZS4mbmJzcDsgSU1PIHRoZSBtb2RlbHM8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7ICZndDsmZ3Q7IGF0IHRoaXMgbGV2ZWw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7ICZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7 Jmd0OyBkZXNjcmliZSB0aGUgbmV0d29yaywgbm90IHRoZSBkZXZpY2VzLiZuYnNwOyBUaGVyZSBp cyBzb21lIGdsdWUgdGhhdCB0ZWxsczwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg Jmd0OyZndDsgdGhlIGNvbnRyb2xsZXIgd2hhdCBkZXZpY2VzIGFyZTwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgJmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7ICZndDsmZ3Q7IGF2YWlsYWJsZSwgYW5kIGhvdyB0byB0YWxrIHRvIHRoZW0sIGJ1dCB0aGUg Z29hbCBpcyB0byBoYW5kbGUgdGhlPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAm Z3Q7Jmd0OyBkZXZpY2UgbGV2ZWwgZGV0YWlsczwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgJmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7 IGFzIHBhcnQgb2YgdGhlIGNvbnRyb2xsZXIgZGF0YSBtb2RlbCBpbXBsZW1lbnRhdGlvbi48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgJmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7ICZs dDtFcmljJmd0OyBXZSBoYXZlIGEgWUFORyBtb2RlbCBmb3IgQ2xvdWQgUG9saWNlciBhbmQgRERv UyBUaHJlc2hvbGRpbmc8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHdoaWNoPC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyBleHBvc2VzIHRoZSBpbnRl cnBsYXkgb2YgZG9tYWluIGFuZCBkZXZpY2Ugdmlldy4mbmJzcDsmbmJzcDsgSSB3aWxsIHN0cml2 ZSB0byBnZXQgaXQ8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7IHBv c3RlZCBhcyBhIG5ldyBkcmFmdCBiZWZvcmUgT2N0IDI3dGguJm5ic3A7IChJRVRGIDkxIGN1dC1v ZmYgZGF0ZS4pPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OzwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyAmZ3Q7Jmd0OyBFcmljPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0 OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDs8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyAmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZn dDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgJmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsm Z3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyBFcmljIFZvaXQ8 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyBQcmluY2lwYWwgRW5naW5lZXIgLSBDU0c8L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgJmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgJmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsm Z3Q7IG5ldG1vZCBtYWlsaW5nIGxpc3Q8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 ICZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJj b2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5uZXRtb2RAaWV0Zi5vcmc8L3Nw YW4+PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsgPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QiPg0KPHNwYW4g c3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPC9zcGFuPjwvYT48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyAmZ3Q7Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0Ozwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgJmd0OyBuZXRtb2QgbWFpbGluZyBsaXN0PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPjxzcGFuIHN0eWxl PSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5uZXRtb2RAaWV0Zi5vcmc8 L3NwYW4+PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyA8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZCI+DQo8c3BhbiBz dHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8L3NwYW4+PC9hPjwvcD4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_EF64FF31F4C4384DBCE5D513A791C2B120A5AC8Exmbalnx11ciscoc_-- From nobody Thu Oct 30 23:51:37 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C99B1A8AD5 for ; Thu, 30 Oct 2014 23:51:36 -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 fq0fJ_QzpRed for ; Thu, 30 Oct 2014 23:51:34 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 48B221A8AD7 for ; Thu, 30 Oct 2014 23:51:34 -0700 (PDT) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 12ECB1280994; Fri, 31 Oct 2014 07:51:33 +0100 (CET) Date: Fri, 31 Oct 2014 07:51:32 +0100 (CET) Message-Id: <20141031.075132.208810580.mbj@tail-f.com> To: evoit@cisco.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/U9DGXt7UmgYLItvzSiZ7wovE0Pw Cc: netmod@ietf.org Subject: Re: [netmod] YANG model containing both device and domain config X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 31 Oct 2014 06:51:36 -0000 Hi, "Eric Voit (evoit)" wrote: > The OpenDaylight controller has already > implemented > Mount as one of its most essential basic functions. If it wasn't important, it > wouldn't have been done. > > > > The question is not whether Yang Mount is going to happen. It is whether the > IETF wants to be involved. A clarification question: are we talking about read-only mounting or read-write? As I have written before, I believe the mechanism proposed doesn't really work for read-write access. /martin From nobody Fri Oct 31 00:00:37 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A55D31A8ADE for ; Fri, 31 Oct 2014 00:00:35 -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 GxucynKSpAZ7 for ; Fri, 31 Oct 2014 00:00:34 -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 8E01E1A8AD8 for ; Fri, 31 Oct 2014 00:00:33 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLD17224; Fri, 31 Oct 2014 07:00:32 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 31 Oct 2014 07:00:31 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.21]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Fri, 31 Oct 2014 15:00:25 +0800 From: Qin Wu To: Martin Bjorklund , "evoit@cisco.com" Thread-Topic: [netmod] YANG model containing both device and domain config Thread-Index: AQHP9Nc2tEjARaD7QkOxXrpOP7hVwJxJxWoQ Date: Fri, 31 Oct 2014 07:00:25 +0000 Message-ID: References: <20141031.075132.208810580.mbj@tail-f.com> In-Reply-To: <20141031.075132.208810580.mbj@tail-f.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: http://mailarchive.ietf.org/arch/msg/netmod/9WKC0lYz0F6ggKRACy5138XdcKE Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG model containing both device and domain config X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 31 Oct 2014 07:00:35 -0000 WWVzLCBJIGhhdmUgc2FtZSBxdWVzdGlvbi4NCmJ5IHJlYWRpbmcgZHJhZnQtdHJpcGF0aHktY2xv dWQtc2xhLXlhbmctbW9kZWwtMDAsIEl0IHNlZW1zIHRvIG1lIGl0IG9ubHkgc3VwcG9ydHMgcmVh ZCBvYmplY3QgZnJvbSByZW1vdGUgZGF0YXN0b3JlLCBidXQgZG9lc24ndCBzdXBwb3J0IHdyaXRl IG9iamVjdCBiYWNrIGludG8gcmVtb3RlIGRhdGFzdG9yZS4NCg0KUmVnYXJkcyENCi1RaW4NCi0t LS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBuZXRtb2QgW21haWx0bzpuZXRtb2QtYm91bmNlc0Bp ZXRmLm9yZ10gtPqx7SBNYXJ0aW4gQmpvcmtsdW5kDQq3osvNyrG85DogMjAxNMTqMTDUwjMxyNUg MTQ6NTINCsrVvP7IyzogZXZvaXRAY2lzY28uY29tDQqzrcvNOiBuZXRtb2RAaWV0Zi5vcmcNCtb3 zOI6IFJlOiBbbmV0bW9kXSBZQU5HIG1vZGVsIGNvbnRhaW5pbmcgYm90aCBkZXZpY2UgYW5kIGRv bWFpbiBjb25maWcNCg0KSGksDQoNCiJFcmljIFZvaXQgKGV2b2l0KSIgPGV2b2l0QGNpc2NvLmNv bT4gd3JvdGU6DQo+IFRoZSBPcGVuRGF5bGlnaHQgY29udHJvbGxlciBoYXMgYWxyZWFkeSANCj4g aW1wbGVtZW50ZWQ8aHR0cDovL3NkbnR1dG9yaWFscy5jb20vaG93LXRvLWFjY2Vzcy1kYXRhLWlu LW1kLXNhbC1mcm9tLQ0KPiBtb3VudC1wb2ludC8+IE1vdW50IGFzIG9uZSBvZiBpdHMgbW9zdCBl c3NlbnRpYWwgYmFzaWMgZnVuY3Rpb25zLiAgSWYgDQo+IGl0IHdhc24ndCBpbXBvcnRhbnQsIGl0 IHdvdWxkbid0IGhhdmUgYmVlbiBkb25lLg0KPiANCj4gDQo+IA0KPiBUaGUgcXVlc3Rpb24gaXMg bm90IHdoZXRoZXIgWWFuZyBNb3VudCBpcyBnb2luZyB0byBoYXBwZW4uICBJdCBpcyANCj4gd2hl dGhlciB0aGUgSUVURiB3YW50cyB0byBiZSBpbnZvbHZlZC4NCg0KQSBjbGFyaWZpY2F0aW9uIHF1 ZXN0aW9uOiBhcmUgd2UgdGFsa2luZyBhYm91dCByZWFkLW9ubHkgbW91bnRpbmcgb3IgcmVhZC13 cml0ZT8NCg0KQXMgSSBoYXZlIHdyaXR0ZW4gYmVmb3JlLCBJIGJlbGlldmUgdGhlIG1lY2hhbmlz bSBwcm9wb3NlZCBkb2Vzbid0IHJlYWxseSB3b3JrIGZvciByZWFkLXdyaXRlIGFjY2Vzcy4NCg0K DQoNCi9tYXJ0aW4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg== From nobody Fri Oct 31 00:07:26 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC331A8ADB for ; Fri, 31 Oct 2014 00:07:22 -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 21XYDb1VsXFS for ; Fri, 31 Oct 2014 00:07:19 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC34E1A8AD8 for ; Fri, 31 Oct 2014 00:07:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7714; q=dns/txt; s=iport; t=1414739239; x=1415948839; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=TP+ibsffTaqjxTyMXawM02tDR8+JZM2y998uz0TGL2o=; b=gGvfmAevH7X/uWE9QMZTF3YV2gqS0giWBEkNHHnB+4YWgzU4K0V2f44g 3YsUcEDrrHvz01lykWYr0bxlW2LvirsH1kKdMCEPnjCtBCKDvgWAJ8W7b y2CSTG3L9EZgsI/QqtaMOxXNXDsCTpK7EKJ3A2HM8XU2HGLMK0Ai4kMjo w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFAPMzU1StJV2b/2dsb2JhbABcgkhGU1iDBslUAQmGeVQCG4EBFgF9hAIBAQEEAQEBIApBCxACAQYCDgMEAQEBCh0DAgICJQsUAwEFCAIEAQ0FCIg3DZgMnE+UWwEBAQEBAQEBAQEBAQEBAQEBAQEBAReQIC0EB4J3NoEeBYZhiyCERohDPIY3jX+Dd2yCSwEBAQ X-IronPort-AV: E=Sophos;i="5.07,293,1413244800"; d="scan'208,217";a="364987529" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 31 Oct 2014 07:07:19 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s9V77IGm019267 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 Oct 2014 07:07:18 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.231]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Fri, 31 Oct 2014 02:07:18 -0500 From: "Ambika Prasad Tripathy (ambtripa)" To: Qin Wu , Martin Bjorklund , "Eric Voit (evoit)" Thread-Topic: [netmod] YANG model containing both device and domain config Thread-Index: AQHP9NciSF8QziWu/kCXisv3L46wapxKGtSA//+uG9g= Date: Fri, 31 Oct 2014 07:07:18 +0000 Message-ID: <3B675C3A8DF102408C754E30986E43CF05CE77E9@xmb-aln-x08.cisco.com> References: <20141031.075132.208810580.mbj@tail-f.com>, In-Reply-To: Accept-Language: en-IN, en-US Content-Language: en-IN X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_3B675C3A8DF102408C754E30986E43CF05CE77E9xmbalnx08ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/2abuOnHWNNJdtRWG-Fv9bg2g8Hw Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG model containing both device and domain config X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 31 Oct 2014 07:07:22 -0000 --_000_3B675C3A8DF102408C754E30986E43CF05CE77E9xmbalnx08ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQpUaGlzIG1vdW50IGlzIG9ubHkgZm9yIHJlYWQuIE5vdCBmb3Igd3JpdGUuDQpCciwNCkFt YmlrYQ0KDQpTZW50IGZyb20gbXkgV2luZG93cyBQaG9uZQ0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCkZyb206IFFpbiBXdTxtYWlsdG86YmlsbC53dUBodWF3ZWkuY29tPg0KU2Vu dDog4oCOMzEt4oCOMTAt4oCOMjAxNCAxMjozMA0KVG86IE1hcnRpbiBCam9ya2x1bmQ8bWFpbHRv Om1iakB0YWlsLWYuY29tPjsgRXJpYyBWb2l0IChldm9pdCk8bWFpbHRvOmV2b2l0QGNpc2NvLmNv bT4NCkNjOiBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NClN1YmplY3Q6 IFJlOiBbbmV0bW9kXSBZQU5HIG1vZGVsIGNvbnRhaW5pbmcgYm90aCBkZXZpY2UgYW5kIGRvbWFp biBjb25maWcNCg0KWWVzLCBJIGhhdmUgc2FtZSBxdWVzdGlvbi4NCmJ5IHJlYWRpbmcgZHJhZnQt dHJpcGF0aHktY2xvdWQtc2xhLXlhbmctbW9kZWwtMDAsIEl0IHNlZW1zIHRvIG1lIGl0IG9ubHkg c3VwcG9ydHMgcmVhZCBvYmplY3QgZnJvbSByZW1vdGUgZGF0YXN0b3JlLCBidXQgZG9lc24ndCBz dXBwb3J0IHdyaXRlIG9iamVjdCBiYWNrIGludG8gcmVtb3RlIGRhdGFzdG9yZS4NCg0KUmVnYXJk cyENCi1RaW4NCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogbmV0bW9kIFttYWls dG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBNYXJ0aW4gQmpvcmtsdW5kDQrlj5Hp gIHml7bpl7Q6IDIwMTTlubQxMOaciDMx5pelIDE0OjUyDQrmlLbku7bkuro6IGV2b2l0QGNpc2Nv LmNvbQ0K5oqE6YCBOiBuZXRtb2RAaWV0Zi5vcmcNCuS4u+mimDogUmU6IFtuZXRtb2RdIFlBTkcg bW9kZWwgY29udGFpbmluZyBib3RoIGRldmljZSBhbmQgZG9tYWluIGNvbmZpZw0KDQpIaSwNCg0K IkVyaWMgVm9pdCAoZXZvaXQpIiA8ZXZvaXRAY2lzY28uY29tPiB3cm90ZToNCj4gVGhlIE9wZW5E YXlsaWdodCBjb250cm9sbGVyIGhhcyBhbHJlYWR5DQo+IGltcGxlbWVudGVkPGh0dHA6Ly9zZG50 dXRvcmlhbHMuY29tL2hvdy10by1hY2Nlc3MtZGF0YS1pbi1tZC1zYWwtZnJvbS0NCj4gbW91bnQt cG9pbnQvPiBNb3VudCBhcyBvbmUgb2YgaXRzIG1vc3QgZXNzZW50aWFsIGJhc2ljIGZ1bmN0aW9u cy4gIElmDQo+IGl0IHdhc24ndCBpbXBvcnRhbnQsIGl0IHdvdWxkbid0IGhhdmUgYmVlbiBkb25l Lg0KPg0KPg0KPg0KPiBUaGUgcXVlc3Rpb24gaXMgbm90IHdoZXRoZXIgWWFuZyBNb3VudCBpcyBn b2luZyB0byBoYXBwZW4uICBJdCBpcw0KPiB3aGV0aGVyIHRoZSBJRVRGIHdhbnRzIHRvIGJlIGlu dm9sdmVkLg0KDQpBIGNsYXJpZmljYXRpb24gcXVlc3Rpb246IGFyZSB3ZSB0YWxraW5nIGFib3V0 IHJlYWQtb25seSBtb3VudGluZyBvciByZWFkLXdyaXRlPw0KDQpBcyBJIGhhdmUgd3JpdHRlbiBi ZWZvcmUsIEkgYmVsaWV2ZSB0aGUgbWVjaGFuaXNtIHByb3Bvc2VkIGRvZXNuJ3QgcmVhbGx5IHdv cmsgZm9yIHJlYWQtd3JpdGUgYWNjZXNzLg0KDQoNCg0KL21hcnRpbg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0K bmV0bW9kQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l dG1vZA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5l dG1vZCBtYWlsaW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg== --_000_3B675C3A8DF102408C754E30986E43CF05CE77E9xmbalnx08ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHRleHQg LS0+PHN0eWxlPjwhLS0gLkVtYWlsUXVvdGUgeyBtYXJnaW4tbGVmdDogMXB0OyBwYWRkaW5nLWxl ZnQ6IDRwdDsgYm9yZGVyLWxlZnQ6ICM4MDAwMDAgMnB4IHNvbGlkOyB9IC0tPjwvc3R5bGU+DQo8 L2hlYWQ+DQo8Ym9keT4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2Fs aWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdCI+SGksPGJyPg0KVGhpcyBtb3VudCBpcyBv bmx5IGZvciByZWFkLiBOb3QgZm9yIHdyaXRlLiA8YnI+DQpCciw8YnI+DQpBbWJpa2EgPGJyPg0K PGJyPg0KU2VudCBmcm9tIG15IFdpbmRvd3MgUGhvbmU8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBkaXI9 Imx0ciI+DQo8aHI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlm OyBmb250LXNpemU6MTFwdDsgZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbToNCjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdCI+PGEg aHJlZj0ibWFpbHRvOmJpbGwud3VAaHVhd2VpLmNvbSI+UWluIFd1PC9hPjwvc3Bhbj48YnI+DQo8 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFw dDsgZm9udC13ZWlnaHQ6Ym9sZCI+U2VudDoNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdCI+4oCOMzEt4oCOMTAt4oCOMjAx NCAxMjozMDwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5z LXNlcmlmOyBmb250LXNpemU6MTFwdDsgZm9udC13ZWlnaHQ6Ym9sZCI+VG86DQo8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQi PjxhIGhyZWY9Im1haWx0bzptYmpAdGFpbC1mLmNvbSI+TWFydGluIEJqb3JrbHVuZDwvYT47DQo8 YSBocmVmPSJtYWlsdG86ZXZvaXRAY2lzY28uY29tIj5FcmljIFZvaXQgKGV2b2l0KTwvYT48L3Nw YW4+PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9u dC1zaXplOjExcHQ7IGZvbnQtd2VpZ2h0OmJvbGQiPkNjOg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0Ij48YSBocmVmPSJt YWlsdG86bmV0bW9kQGlldGYub3JnIj5uZXRtb2RAaWV0Zi5vcmc8L2E+PC9zcGFuPjxicj4NCjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0 OyBmb250LXdlaWdodDpib2xkIj5TdWJqZWN0Og0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0Ij5SZTogW25ldG1vZF0gWUFO RyBtb2RlbCBjb250YWluaW5nIGJvdGggZGV2aWNlIGFuZCBkb21haW4gY29uZmlnPC9zcGFuPjxi cj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwcHQ7Ij4NCjxkaXYgY2xhc3M9IlBsYWluVGV4dCI+WWVzLCBJIGhhdmUgc2FtZSBx dWVzdGlvbi48YnI+DQpieSByZWFkaW5nIGRyYWZ0LXRyaXBhdGh5LWNsb3VkLXNsYS15YW5nLW1v ZGVsLTAwLCBJdCBzZWVtcyB0byBtZSBpdCBvbmx5IHN1cHBvcnRzIHJlYWQgb2JqZWN0IGZyb20g cmVtb3RlIGRhdGFzdG9yZSwgYnV0IGRvZXNuJ3Qgc3VwcG9ydCB3cml0ZSBvYmplY3QgYmFjayBp bnRvIHJlbW90ZSBkYXRhc3RvcmUuPGJyPg0KPGJyPg0KUmVnYXJkcyE8YnI+DQotUWluPGJyPg0K LS0tLS3pgq7ku7bljp/ku7YtLS0tLTxicj4NCuWPkeS7tuS6ujogbmV0bW9kIFs8YSBocmVmPSJt YWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRm Lm9yZzwvYT5dIOS7o+ihqCBNYXJ0aW4gQmpvcmtsdW5kPGJyPg0K5Y+R6YCB5pe26Ze0OiAyMDE0 5bm0MTDmnIgzMeaXpSAxNDo1Mjxicj4NCuaUtuS7tuS6ujogZXZvaXRAY2lzY28uY29tPGJyPg0K 5oqE6YCBOiBuZXRtb2RAaWV0Zi5vcmc8YnI+DQrkuLvpopg6IFJlOiBbbmV0bW9kXSBZQU5HIG1v ZGVsIGNvbnRhaW5pbmcgYm90aCBkZXZpY2UgYW5kIGRvbWFpbiBjb25maWc8YnI+DQo8YnI+DQpI aSw8YnI+DQo8YnI+DQomcXVvdDtFcmljIFZvaXQgKGV2b2l0KSZxdW90OyAmbHQ7ZXZvaXRAY2lz Y28uY29tJmd0OyB3cm90ZTo8YnI+DQomZ3Q7IFRoZSBPcGVuRGF5bGlnaHQgY29udHJvbGxlciBo YXMgYWxyZWFkeSA8YnI+DQomZ3Q7IGltcGxlbWVudGVkJmx0OzxhIGhyZWY9IiI+PC9hPmh0dHA6 Ly9zZG50dXRvcmlhbHMuY29tL2hvdy10by1hY2Nlc3MtZGF0YS1pbi1tZC1zYWwtZnJvbS08YnI+ DQomZ3Q7IG1vdW50LXBvaW50LyZndDsgTW91bnQgYXMgb25lIG9mIGl0cyBtb3N0IGVzc2VudGlh bCBiYXNpYyBmdW5jdGlvbnMuJm5ic3A7IElmIDxicj4NCiZndDsgaXQgd2Fzbid0IGltcG9ydGFu dCwgaXQgd291bGRuJ3QgaGF2ZSBiZWVuIGRvbmUuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4N CiZndDsgPGJyPg0KJmd0OyBUaGUgcXVlc3Rpb24gaXMgbm90IHdoZXRoZXIgWWFuZyBNb3VudCBp cyBnb2luZyB0byBoYXBwZW4uJm5ic3A7IEl0IGlzIDxicj4NCiZndDsgd2hldGhlciB0aGUgSUVU RiB3YW50cyB0byBiZSBpbnZvbHZlZC48YnI+DQo8YnI+DQpBIGNsYXJpZmljYXRpb24gcXVlc3Rp b246IGFyZSB3ZSB0YWxraW5nIGFib3V0IHJlYWQtb25seSBtb3VudGluZyBvciByZWFkLXdyaXRl Pzxicj4NCjxicj4NCkFzIEkgaGF2ZSB3cml0dGVuIGJlZm9yZSwgSSBiZWxpZXZlIHRoZSBtZWNo YW5pc20gcHJvcG9zZWQgZG9lc24ndCByZWFsbHkgd29yayBmb3IgcmVhZC13cml0ZSBhY2Nlc3Mu PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KL21hcnRpbjxicj4NCjxicj4NCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbmV0bW9kIG1haWxpbmcgbGlz dDxicj4NCm5ldG1vZEBpZXRmLm9yZzxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbmV0bW9kIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25ldG1vZDwvYT48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCm5ldG1vZCBtYWlsaW5nIGxpc3Q8YnI+DQpuZXRtb2RAaWV0Zi5v cmc8YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l dG1vZCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8L2E+PGJy Pg0KPC9kaXY+DQo8L3NwYW4+PC9mb250Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_3B675C3A8DF102408C754E30986E43CF05CE77E9xmbalnx08ciscoc_-- From nobody Fri Oct 31 02:13:18 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1B111A6F99; Fri, 31 Oct 2014 02:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 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_REMOTE_IMAGE=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 lJp5mjUletuq; Fri, 31 Oct 2014 02:13:10 -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 387BC1A6F93; Fri, 31 Oct 2014 02:13:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOG37122; Fri, 31 Oct 2014 09:13:07 +0000 (GMT) Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 31 Oct 2014 09:13:05 +0000 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.57]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.03.0158.001; Fri, 31 Oct 2014 17:12:59 +0800 From: Tina TSOU To: "netmod@ietf.org" Thread-Topic: SUPA drafts related to YANG model Thread-Index: Ac/06t0/z/knT3IdQuS6+tu4bPZ8SA== Date: Fri, 31 Oct 2014 09:12:58 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_F5CDDBCBD59C4910A56E91021A057DBBhuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/PXVJnkfGYRsJeRSlwyjLTRBmjbU Cc: "supa@ietf.org" Subject: [netmod] SUPA drafts related to 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: Fri, 31 Oct 2014 09:13:14 -0000 --_000_F5CDDBCBD59C4910A56E91021A057DBBhuaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNClNvbWUgU1VQQSBkcmFmdHMgcmVsYXRlZCB0byBZQU5HIG1vZGVsIGZvciB5 b3VyIHJlYWRpbmcgcGxlYXN1cmUgYW5kIGNvbW1lbnRzLg0KaHR0cDovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1jb250cmVyYXMtc3VwYS15YW5nLW5ldHdvcmstdG9wby8NCmh0dHA6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtemFhbG91ay1zdXBhLWNvbmZpZ3VyYXRp b24tbW9kZWwvDQoNCk1vcmUgY29udGV4dCBjb3VsZCBiZSBmb3VuZCBhdA0KaHR0cDovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9zZWFyY2gvP25hbWU9U3VwYSZyZmNzPW9uJmFjdGl2ZWRyYWZ0 cz1vbiZzb3J0PSZieT1hdXRob3ImYXV0aG9yPQ0KDQpEb2N1bWVudCBbaHR0cDovL2RhdGF0cmFj a2VyLmlldGYub3JnL2ltYWdlcy9zb3J0LWhlYWRlci1jbGVhci5wbmddIDxodHRwOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL3NlYXJjaC8/c29ydD1kb2N1bWVudCZuYW1lPVN1cGEmYWN0aXZl ZHJhZnRzPW9uJmF1dGhvcj0mcmZjcz1vbiZieT1hdXRob3I+ICAgICAgICAgVGl0bGUgW2h0dHA6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9pbWFnZXMvc29ydC1oZWFkZXItY2xlYXIucG5nXSA8aHR0 cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9zZWFyY2gvP3NvcnQ9dGl0bGUmbmFtZT1TdXBh JmFjdGl2ZWRyYWZ0cz1vbiZhdXRob3I9JnJmY3M9b24mYnk9YXV0aG9yPiAgICAgICBEYXRlIFto dHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaW1hZ2VzL3NvcnQtaGVhZGVyLWNsZWFyLnBuZ10g PGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mvc2VhcmNoLz9zb3J0PWRhdGUmbmFtZT1T dXBhJmFjdGl2ZWRyYWZ0cz1vbiZhdXRob3I9JnJmY3M9b24mYnk9YXV0aG9yPiAgICAgICAgIFN0 YXR1cyBbaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2ltYWdlcy9zb3J0LWhlYWRlci1jbGVh ci5wbmddIDxodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL3NlYXJjaC8/c29ydD1zdGF0 dXMmbmFtZT1TdXBhJmFjdGl2ZWRyYWZ0cz1vbiZhdXRob3I9JnJmY3M9b24mYnk9YXV0aG9yPiAg ICAgSVBSIFtodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaW1hZ2VzL3NvcnQtaGVhZGVyLWNs ZWFyLnBuZ10gPGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mvc2VhcmNoLz9zb3J0PWlw ciZuYW1lPVN1cGEmYWN0aXZlZHJhZnRzPW9uJmF1dGhvcj0mcmZjcz1vbiZieT1hdXRob3I+ICAg QUQgLyBTaGVwaGVyZCBbaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2ltYWdlcy9zb3J0LWhl YWRlci1jbGVhci5wbmddIDxodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL3NlYXJjaC8/ c29ydD1hZCZuYW1lPVN1cGEmYWN0aXZlZHJhZnRzPW9uJmF1dGhvcj0mcmZjcz1vbiZieT1hdXRo b3I+DQpBY3RpdmUgSW50ZXJuZXQtRHJhZnRzDQpkcmFmdC1iaS1zdXBhLWdhcC1hbmFseXNpcy0w MDxodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJpLXN1cGEtZ2FwLWFuYWx5 c2lzLz4gICAgICBTaGFyZWQgVW5pZmllZCBQb2xpY3kgQXV0b21hdGlvbiAoU1VQQSkgR2FwIEFu YWx5c2lzICAgIDIwMTQtMDktMjUgICAgICBJLUQgRXhpc3RzDQoNCmRyYWZ0LWJpLXN1cGEtc2Rz YXZpLTAwPGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYmktc3VwYS1zZHNh dmkvPiAgQSBTVVBBIFVzZSBDYXNlIGZvciBTQVZJICAgICAgICAyMDE0LTA5LTI2ICAgICAgSS1E IEV4aXN0cw0KDQpkcmFmdC1jaGVuZy1zdXBhLWRkYy11c2UtY2FzZXMtMDE8aHR0cDovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1jaGVuZy1zdXBhLWRkYy11c2UtY2FzZXMvPiAgICAg IFVzZSBDYXNlcyBmb3IgRGlzdHJpYnV0ZWQgRGF0YSBDZW50ZXIgQXBwbGljYXRpb25zIGluIFNV UEEgICAgICAyMDE0LTEwLTI3DQpuZXc8aHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9 ZHJhZnQtY2hlbmctc3VwYS1kZGMtdXNlLWNhc2VzLTAxPg0KICAgICAgICBJLUQgRXhpc3RzDQoN CmRyYWZ0LWNvbnRyZXJhcy1zdXBhLXlhbmctbmV0d29yay10b3BvLTAxPGh0dHA6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtY29udHJlcmFzLXN1cGEteWFuZy1uZXR3b3JrLXRvcG8v PiAgICAgIEEgWUFORyBEYXRhIE1vZGVsIGZvciBOZXR3b3JrIFRvcG9sb2dpZXMgICAgICAgIDIw MTQtMTAtMjcNCm5ldzxodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1jb250 cmVyYXMtc3VwYS15YW5nLW5ldHdvcmstdG9wby0wMT4NCiAgICAgICAgSS1EIEV4aXN0cw0KDQpk cmFmdC1rYXJhZ2lhbm5pcy1zdXBhLXByb2JsZW0tc3RhdGVtZW50LTAyPGh0dHA6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQta2FyYWdpYW5uaXMtc3VwYS1wcm9ibGVtLXN0YXRlbWVu dC8+ICBQcm9ibGVtIFN0YXRlbWVudCBmb3IgU2hhcmVkIFVuaWZpZWQgUG9saWN5IEF1dG9tYXRp b24gKFNVUEEpICAgMjAxNC0xMC0yNw0KbmV3PGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91 cmwyPWRyYWZ0LWthcmFnaWFubmlzLXN1cGEtcHJvYmxlbS1zdGF0ZW1lbnQtMDI+DQogICAgICAg IEktRCBFeGlzdHMNCg0KZHJhZnQtcGVudGlrb3VzaXMtc3VwYS1tYXBwaW5nLTAwPGh0dHA6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcGVudGlrb3VzaXMtc3VwYS1tYXBwaW5nLz4g ICAgICBTVVBBIENvbmZpZ3VyYXRpb24gYW5kIFBvbGljeSBNYXBwaW5nICAgMjAxNC0wOS0yMyAg ICAgIEktRCBFeGlzdHMNCg0KZHJhZnQtc3VuLXN1cGEtb3BlbnY2LXVzZS1jYXNlcy0wMDxodHRw Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXN1bi1zdXBhLW9wZW52Ni11c2UtY2Fz ZXMvPiAgICBVc2UgY2FzZSBvZiBJUHY2IHRyYW5zaXRpb24gaW4gU1VQQSAgICAgMjAxNC0wOS0y NSAgICAgIEktRCBFeGlzdHMNCg0KZHJhZnQtemFhbG91ay1zdXBhLWNvbmZpZ3VyYXRpb24tbW9k ZWwtMDE8aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16YWFsb3VrLXN1cGEt Y29uZmlndXJhdGlvbi1tb2RlbC8+ICAgICAgWUFORyBEYXRhIE1vZGVsIGZvciBDb25maWd1cmF0 aW9uIG9mIFNoYXJlZCBVbmlmaWVkIFBvbGljeSBBdXRvbWF0aW9uIChTVVBBKSAgICAyMDE0LTEw LTI3DQpuZXc8aHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtemFhbG91ay1z dXBhLWNvbmZpZ3VyYXRpb24tbW9kZWwtMDE+DQogICAgICAgIEktRCBFeGlzdHMNCg0KZHJhZnQt emhvdS1zdXBhLWFyY2hpdGVjdHVyZS0wMDxodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LXpob3Utc3VwYS1hcmNoaXRlY3R1cmUvPiAgVGhlIEFyY2hpdGVjdHVyZSBmb3IgU2hh cmVkIFVuaWZpZWQgUG9saWN5IEF1dG9tYXRpb24gKFNVUEEpICAgIDIwMTQtMTAtMjcNCm5ldzxo dHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC16aG91LXN1cGEtYXJjaGl0ZWN0 dXJlLTAwPg0KICAgICAgICBJLUQgRXhpc3RzDQoNCg0KDQpUaGFuayB5b3UsDQpUaW5hDQo= --_000_F5CDDBCBD59C4910A56E91021A057DBBhuaweicom_ Content-Type: text/html; charset="utf-8" Content-ID: <7650C30F7F6EB2469855CBB2506E7354@huawei.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEzcHQ7Ij5EZWFyIGFsbCw8L3NwYW4+PC9kaXY+ DQo8ZGl2PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEzcHQ7Ij48YnI+DQo8L3NwYW4+PC9kaXY+ DQo8ZGl2PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEzcHQ7Ij5Tb21lIFNVUEEgZHJhZnRzIHJl bGF0ZWQgdG8gWUFORyBtb2RlbCBmb3IgeW91ciByZWFkaW5nIHBsZWFzdXJlIGFuZCBjb21tZW50 cy48L3NwYW4+PC9kaXY+DQo8ZGl2PjxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtY29udHJlcmFzLXN1cGEteWFuZy1uZXR3b3JrLXRvcG8vIj5odHRwOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWNvbnRyZXJhcy1zdXBhLXlhbmctbmV0d29yay10 b3BvLzwvYT48L2Rpdj4NCjxkaXY+PGEgaHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC16YWFsb3VrLXN1cGEtY29uZmlndXJhdGlvbi1tb2RlbC8iPmh0dHA6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtemFhbG91ay1zdXBhLWNvbmZpZ3VyYXRpb24tbW9k ZWwvPC9hPjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+TW9yZSBjb250ZXh0IGNvdWxk IGJlIGZvdW5kIGF0PC9kaXY+DQo8ZGl2PjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiBy Z2JhKDI1NSwgMjU1LCAyNTUsIDApOyI+PGEgaHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9zZWFyY2gvP25hbWU9U3VwYSZhbXA7cmZjcz1vbiZhbXA7YWN0aXZlZHJhZnRzPW9u JmFtcDtzb3J0PSZhbXA7Ynk9YXV0aG9yJmFtcDthdXRob3I9Ij5odHRwOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL3NlYXJjaC8/bmFtZT1TdXBhJmFtcDtyZmNzPW9uJmFtcDthY3RpdmVkcmFm dHM9b24mYW1wO3NvcnQ9JmFtcDtieT1hdXRob3ImYW1wO2F1dGhvcj08L2E+PC9zcGFuPjwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8dGFibGUgY2xhc3M9ImlldGYtdGFibGUgaWV0 Zi1kb2N0YWJsZSIgc3R5bGU9ImJvcmRlci1jb2xsYXBzZTogY29sbGFwc2U7IGJvcmRlcjogMXB4 IHNvbGlkIHJnYigxMjcsIDEyNywgMTI3KTsiPg0KPHRib2R5Pg0KPHRyPg0KPHRoIGNsYXNzPSJk b2N1bWVudCIgc3R5bGU9ImNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IGJhY2tncm91bmQtY29s b3I6IHJnYigzOCwgNzEsIDE2MCk7IHBhZGRpbmc6IDNweCA2cHg7IGJvcmRlci1yaWdodC13aWR0 aDogMXB4OyBib3JkZXItcmlnaHQtc3R5bGU6IHNvbGlkOyBib3JkZXItcmlnaHQtY29sb3I6IHJn YigxMjcsIDEyNywgMTI3KTsgd2hpdGUtc3BhY2U6IG5vd3JhcDsiPg0KPGEgaHJlZj0iaHR0cDov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9zZWFyY2gvP3NvcnQ9ZG9jdW1lbnQmYW1wO25hbWU9 U3VwYSZhbXA7YWN0aXZlZHJhZnRzPW9uJmFtcDthdXRob3I9JmFtcDtyZmNzPW9uJmFtcDtieT1h dXRob3IiIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7 IGJhY2tncm91bmQtY29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7Ij48Zm9udCBjb2xvcj0i IzAwMDAwMCI+RG9jdW1lbnQmbmJzcDs8aW1nIHNyYz0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYu b3JnL2ltYWdlcy9zb3J0LWhlYWRlci1jbGVhci5wbmciIHN0eWxlPSJib3JkZXI6IDBweCBub25l OyB2ZXJ0aWNhbC1hbGlnbjogdG9wOyI+PC9mb250PjwvYT48L3RoPg0KPHRoIGNsYXNzPSJ0aXRs ZSIgc3R5bGU9ImNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IGJhY2tncm91bmQtY29sb3I6IHJn YigzOCwgNzEsIDE2MCk7IHBhZGRpbmc6IDNweCA2cHg7IGJvcmRlci1yaWdodC13aWR0aDogMXB4 OyBib3JkZXItcmlnaHQtc3R5bGU6IHNvbGlkOyBib3JkZXItcmlnaHQtY29sb3I6IHJnYigxMjcs IDEyNywgMTI3KTsgd2hpdGUtc3BhY2U6IG5vd3JhcDsgbWluLXdpZHRoOiAyMGVtOyBtYXgtd2lk dGg6IDM1ZW07Ij4NCjxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mvc2Vh cmNoLz9zb3J0PXRpdGxlJmFtcDtuYW1lPVN1cGEmYW1wO2FjdGl2ZWRyYWZ0cz1vbiZhbXA7YXV0 aG9yPSZhbXA7cmZjcz1vbiZhbXA7Ynk9YXV0aG9yIiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOiBu b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1 LCAyNTUsIDApOyI+PGZvbnQgY29sb3I9IiMwMDAwMDAiPlRpdGxlJm5ic3A7PGltZyBzcmM9Imh0 dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9pbWFnZXMvc29ydC1oZWFkZXItY2xlYXIucG5nIiBz dHlsZT0iYm9yZGVyOiAwcHggbm9uZTsgdmVydGljYWwtYWxpZ246IHRvcDsiPjwvZm9udD48L2E+ PC90aD4NCjx0aCBjbGFzcz0iZGF0ZSIgc3R5bGU9ImNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7 IGJhY2tncm91bmQtY29sb3I6IHJnYigzOCwgNzEsIDE2MCk7IHBhZGRpbmc6IDNweCA2cHg7IGJv cmRlci1yaWdodC13aWR0aDogMXB4OyBib3JkZXItcmlnaHQtc3R5bGU6IHNvbGlkOyBib3JkZXIt cmlnaHQtY29sb3I6IHJnYigxMjcsIDEyNywgMTI3KTsgd2hpdGUtc3BhY2U6IG5vd3JhcDsgbWlu LXdpZHRoOiA2ZW07Ij4NCjxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv c2VhcmNoLz9zb3J0PWRhdGUmYW1wO25hbWU9U3VwYSZhbXA7YWN0aXZlZHJhZnRzPW9uJmFtcDth dXRob3I9JmFtcDtyZmNzPW9uJmFtcDtieT1hdXRob3IiIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IGJhY2tncm91bmQtY29sb3I6IHJnYmEoMjU1LCAy NTUsIDI1NSwgMCk7Ij48Zm9udCBjb2xvcj0iIzAwMDAwMCI+RGF0ZSZuYnNwOzxpbWcgc3JjPSJo dHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaW1hZ2VzL3NvcnQtaGVhZGVyLWNsZWFyLnBuZyIg c3R5bGU9ImJvcmRlcjogMHB4IG5vbmU7IHZlcnRpY2FsLWFsaWduOiB0b3A7Ij48L2ZvbnQ+PC9h PjwvdGg+DQo8dGggY2xhc3M9InN0YXR1cyIgY29sc3Bhbj0iMiIgc3R5bGU9ImNvbG9yOiByZ2Io MjU1LCAyNTUsIDI1NSk7IGJhY2tncm91bmQtY29sb3I6IHJnYigzOCwgNzEsIDE2MCk7IHBhZGRp bmc6IDNweCA2cHg7IGJvcmRlci1yaWdodC13aWR0aDogMXB4OyBib3JkZXItcmlnaHQtc3R5bGU6 IHNvbGlkOyBib3JkZXItcmlnaHQtY29sb3I6IHJnYigxMjcsIDEyNywgMTI3KTsgd2hpdGUtc3Bh Y2U6IG5vd3JhcDsgbWluLXdpZHRoOiAyMGVtOyI+DQo8YSBocmVmPSJodHRwOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL3NlYXJjaC8/c29ydD1zdGF0dXMmYW1wO25hbWU9U3VwYSZhbXA7YWN0 aXZlZHJhZnRzPW9uJmFtcDthdXRob3I9JmFtcDtyZmNzPW9uJmFtcDtieT1hdXRob3IiIHN0eWxl PSJ0ZXh0LWRlY29yYXRpb246IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IGJhY2tncm91bmQt Y29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7Ij48Zm9udCBjb2xvcj0iIzAwMDAwMCI+U3Rh dHVzJm5ic3A7PGltZyBzcmM9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9pbWFnZXMvc29y dC1oZWFkZXItY2xlYXIucG5nIiBzdHlsZT0iYm9yZGVyOiAwcHggbm9uZTsgdmVydGljYWwtYWxp Z246IHRvcDsiPjwvZm9udD48L2E+PC90aD4NCjx0aCBjbGFzcz0iaXByIiBzdHlsZT0iY29sb3I6 IHJnYigyNTUsIDI1NSwgMjU1KTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDM4LCA3MSwgMTYwKTsg cGFkZGluZzogM3B4IDZweDsgYm9yZGVyLXJpZ2h0LXdpZHRoOiAxcHg7IGJvcmRlci1yaWdodC1z dHlsZTogc29saWQ7IGJvcmRlci1yaWdodC1jb2xvcjogcmdiKDEyNywgMTI3LCAxMjcpOyB3aGl0 ZS1zcGFjZTogbm93cmFwOyBmb250LXZhcmlhbnQ6IHNtYWxsLWNhcHM7Ij4NCjxhIGhyZWY9Imh0 dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mvc2VhcmNoLz9zb3J0PWlwciZhbXA7bmFtZT1T dXBhJmFtcDthY3RpdmVkcmFmdHM9b24mYW1wO2F1dGhvcj0mYW1wO3JmY3M9b24mYW1wO2J5PWF1 dGhvciIgc3R5bGU9InRleHQtZGVjb3JhdGlvbjogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsg YmFja2dyb3VuZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsiPjxmb250IGNvbG9yPSIj MDAwMDAwIj5JUFImbmJzcDs8aW1nIHNyYz0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2lt YWdlcy9zb3J0LWhlYWRlci1jbGVhci5wbmciIHN0eWxlPSJib3JkZXI6IDBweCBub25lOyB2ZXJ0 aWNhbC1hbGlnbjogdG9wOyI+PC9mb250PjwvYT48L3RoPg0KPHRoIGNsYXNzPSJhZCIgc3R5bGU9 ImNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IGJhY2tncm91bmQtY29sb3I6IHJnYigzOCwgNzEs IDE2MCk7IHBhZGRpbmc6IDNweCA2cHg7IGJvcmRlci1yaWdodC13aWR0aDogMXB4OyBib3JkZXIt cmlnaHQtc3R5bGU6IHNvbGlkOyBib3JkZXItcmlnaHQtY29sb3I6IHJnYigxMjcsIDEyNywgMTI3 KTsgd2hpdGUtc3BhY2U6IG5vd3JhcDsgbWluLXdpZHRoOiA2ZW07Ij4NCjxhIGhyZWY9Imh0dHA6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mvc2VhcmNoLz9zb3J0PWFkJmFtcDtuYW1lPVN1cGEm YW1wO2FjdGl2ZWRyYWZ0cz1vbiZhbXA7YXV0aG9yPSZhbXA7cmZjcz1vbiZhbXA7Ynk9YXV0aG9y IiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyBiYWNr Z3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAyNTUsIDApOyI+PGZvbnQgY29sb3I9IiMwMDAw MDAiPkFEIC8gU2hlcGhlcmQmbmJzcDs8aW1nIHNyYz0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYu b3JnL2ltYWdlcy9zb3J0LWhlYWRlci1jbGVhci5wbmciIHN0eWxlPSJib3JkZXI6IDBweCBub25l OyB2ZXJ0aWNhbC1hbGlnbjogdG9wOyI+PC9mb250PjwvYT48L3RoPg0KPC90cj4NCjx0ciBjbGFz cz0iaGVhZGVyIiBzdHlsZT0iYm9yZGVyLXdpZHRoOiAxcHggMnB4IDFweCAxcHg7IGJvcmRlci1z dHlsZTogc29saWQ7IGJvcmRlci1jb2xvcjogcmdiKDEyNywgMTI3LCAxMjcpIHdoaXRlOyI+DQo8 dGQgY29sc3Bhbj0iMTAiIHN0eWxlPSJib3JkZXItcmlnaHQtd2lkdGg6IDFweDsgYm9yZGVyLXJp Z2h0LXN0eWxlOiBzb2xpZDsgYm9yZGVyLXJpZ2h0LWNvbG9yOiByZ2IoMjAzLCAyMDMsIDIwMyk7 IHBhZGRpbmc6IDZweDsgdmVydGljYWwtYWxpZ246IHRvcDsgZm9udC13ZWlnaHQ6IGJvbGQ7Ij4N CjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAyNTUsIDApOyI+ QWN0aXZlIEludGVybmV0LURyYWZ0czwvc3Bhbj48L3RkPg0KPC90cj4NCjx0ciBjbGFzcz0iZXZl bnJvdyIgc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYigyMzcsIDI0NSwgMjU1KTsiPg0KPHRk IGNsYXNzPSJkb2MiIHN0eWxlPSJib3JkZXItcmlnaHQtd2lkdGg6IDFweDsgYm9yZGVyLXJpZ2h0 LXN0eWxlOiBzb2xpZDsgYm9yZGVyLXJpZ2h0LWNvbG9yOiByZ2IoMjAzLCAyMDMsIDIwMyk7IHBh ZGRpbmc6IDNweCAwLjVlbTsgdmVydGljYWwtYWxpZ246IHRvcDsgbWluLXdpZHRoOiAyMGVtOyBt YXgtd2lkdGg6IDM1ZW07Ij4NCjxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtYmktc3VwYS1nYXAtYW5hbHlzaXMvIiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjog cmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsiPjxmb250IGNvbG9yPSIjMDAwMDAwIj5kcmFmdC1iaS1z dXBhLWdhcC1hbmFseXNpcy0wMDwvZm9udD48L2E+PC90ZD4NCjx0ZCBjbGFzcz0idGl0bGUiIHN0 eWxlPSJib3JkZXItcmlnaHQtd2lkdGg6IDFweDsgYm9yZGVyLXJpZ2h0LXN0eWxlOiBzb2xpZDsg Ym9yZGVyLXJpZ2h0LWNvbG9yOiByZ2IoMjAzLCAyMDMsIDIwMyk7IHBhZGRpbmc6IDNweCAwLjVl bTsgdmVydGljYWwtYWxpZ246IHRvcDsgbWluLXdpZHRoOiAyMGVtOyBtYXgtd2lkdGg6IDM1ZW07 Ij4NCjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAyNTUsIDAp OyI+U2hhcmVkIFVuaWZpZWQgUG9saWN5IEF1dG9tYXRpb24gKFNVUEEpIEdhcCBBbmFseXNpczwv c3Bhbj48L3RkPg0KPHRkIGNsYXNzPSJkYXRlIiBzdHlsZT0iYm9yZGVyLXJpZ2h0LXdpZHRoOiAx cHg7IGJvcmRlci1yaWdodC1zdHlsZTogc29saWQ7IGJvcmRlci1yaWdodC1jb2xvcjogcmdiKDIw MywgMjAzLCAyMDMpOyBwYWRkaW5nOiAzcHggMC41ZW07IHZlcnRpY2FsLWFsaWduOiB0b3A7IHdo aXRlLXNwYWNlOiBub3dyYXA7IG1pbi13aWR0aDogNmVtOyI+DQo8c3BhbiBzdHlsZT0id2hpdGUt c3BhY2U6IG5vcm1hbDsgYmFja2dyb3VuZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsi PjIwMTQtMDktMjU8L3NwYW4+PC90ZD4NCjx0ZCBjbGFzcz0ic3RhdHVzIiBzdHlsZT0iYm9yZGVy LXJpZ2h0LXdpZHRoOiAxcHg7IGJvcmRlci1yaWdodC1zdHlsZTogc29saWQ7IGJvcmRlci1yaWdo dC1jb2xvcjogcmdiKDIwMywgMjAzLCAyMDMpOyBwYWRkaW5nOiAzcHggMC41ZW07IHZlcnRpY2Fs LWFsaWduOiB0b3A7IG1pbi13aWR0aDogMjBlbTsiPg0KPHNwYW4gc3R5bGU9ImJhY2tncm91bmQt Y29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7Ij5JLUQgRXhpc3RzPC9zcGFuPjwvdGQ+DQo8 dGQgY2xhc3M9ImJhbGxvdCIgc3R5bGU9ImJvcmRlci1yaWdodC13aWR0aDogMXB4OyBib3JkZXIt cmlnaHQtc3R5bGU6IHNvbGlkOyBib3JkZXItcmlnaHQtY29sb3I6IHJnYigyMDMsIDIwMywgMjAz KTsgcGFkZGluZzogM3B4IDAuNWVtOyB2ZXJ0aWNhbC1hbGlnbjogdG9wOyBib3JkZXItbGVmdC1z dHlsZTogaGlkZGVuOyBtaW4td2lkdGg6IDM3cHg7Ij4NCjwvdGQ+DQo8dGQgY2xhc3M9ImlwciIg c3R5bGU9ImJvcmRlci1yaWdodC13aWR0aDogMXB4OyBib3JkZXItcmlnaHQtc3R5bGU6IHNvbGlk OyBib3JkZXItcmlnaHQtY29sb3I6IHJnYigyMDMsIDIwMywgMjAzKTsgcGFkZGluZzogM3B4IDAu NWVtOyB2ZXJ0aWNhbC1hbGlnbjogdG9wOyI+DQo8L3RkPg0KPHRkIGNsYXNzPSJhZCIgc3R5bGU9 ImJvcmRlci1yaWdodC13aWR0aDogMXB4OyBib3JkZXItcmlnaHQtc3R5bGU6IHNvbGlkOyBib3Jk ZXItcmlnaHQtY29sb3I6IHJnYigyMDMsIDIwMywgMjAzKTsgcGFkZGluZzogM3B4IDAuNWVtOyB2 ZXJ0aWNhbC1hbGlnbjogdG9wOyB3aGl0ZS1zcGFjZTogbm93cmFwOyBtaW4td2lkdGg6IDZlbTsi Pg0KPGRpdiBjbGFzcz0ic2VhcmNoLXRleHQtc2hlcGhlcmQiIHN0eWxlPSJjb2xvcjogcmdiKDEy OCwgMTI4LCAxMjgpOyI+PC9kaXY+DQo8L3RkPg0KPC90cj4NCjx0ciBjbGFzcz0ib2Rkcm93IiBz dHlsZT0iYmFja2dyb3VuZC1jb2xvcjogd2hpdGU7Ij4NCjx0ZCBjbGFzcz0iZG9jIiBzdHlsZT0i Ym9yZGVyLXJpZ2h0LXdpZHRoOiAxcHg7IGJvcmRlci1yaWdodC1zdHlsZTogc29saWQ7IGJvcmRl ci1yaWdodC1jb2xvcjogcmdiKDIwMywgMjAzLCAyMDMpOyBwYWRkaW5nOiAzcHggMC41ZW07IHZl cnRpY2FsLWFsaWduOiB0b3A7IG1pbi13aWR0aDogMjBlbTsgbWF4LXdpZHRoOiAzNWVtOyI+DQo8 YSBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJpLXN1cGEtc2Rz YXZpLyIgc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7Ij48 Zm9udCBjb2xvcj0iIzAwMDAwMCI+ZHJhZnQtYmktc3VwYS1zZHNhdmktMDA8L2ZvbnQ+PC9hPjwv dGQ+DQo8dGQgY2xhc3M9InRpdGxlIiBzdHlsZT0iYm9yZGVyLXJpZ2h0LXdpZHRoOiAxcHg7IGJv cmRlci1yaWdodC1zdHlsZTogc29saWQ7IGJvcmRlci1yaWdodC1jb2xvcjogcmdiKDIwMywgMjAz LCAyMDMpOyBwYWRkaW5nOiAzcHggMC41ZW07IHZlcnRpY2FsLWFsaWduOiB0b3A7IG1pbi13aWR0 aDogMjBlbTsgbWF4LXdpZHRoOiAzNWVtOyI+DQo8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xv cjogcmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsiPkEgU1VQQSBVc2UgQ2FzZSBmb3IgU0FWSTwvc3Bh bj48L3RkPg0KPHRkIGNsYXNzPSJkYXRlIiBzdHlsZT0iYm9yZGVyLXJpZ2h0LXdpZHRoOiAxcHg7 IGJvcmRlci1yaWdodC1zdHlsZTogc29saWQ7IGJvcmRlci1yaWdodC1jb2xvcjogcmdiKDIwMywg MjAzLCAyMDMpOyBwYWRkaW5nOiAzcHggMC41ZW07IHZlcnRpY2FsLWFsaWduOiB0b3A7IHdoaXRl LXNwYWNlOiBub3dyYXA7IG1pbi13aWR0aDogNmVtOyI+DQo8c3BhbiBzdHlsZT0id2hpdGUtc3Bh Y2U6IG5vcm1hbDsgYmFja2dyb3VuZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsiPjIw MTQtMDktMjY8L3NwYW4+PC90ZD4NCjx0ZCBjbGFzcz0ic3RhdHVzIiBzdHlsZT0iYm9yZGVyLXJp Z2h0LXdpZHRoOiAxcHg7IGJvcmRlci1yaWdodC1zdHlsZTogc29saWQ7IGJvcmRlci1yaWdodC1j b2xvcjogcmdiKDIwMywgMjAzLCAyMDMpOyBwYWRkaW5nOiAzcHggMC41ZW07IHZlcnRpY2FsLWFs aWduOiB0b3A7IG1pbi13aWR0aDogMjBlbTsiPg0KPHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29s b3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7Ij5JLUQgRXhpc3RzPC9zcGFuPjwvdGQ+DQo8dGQg Y2xhc3M9ImJhbGxvdCIgc3R5bGU9ImJvcmRlci1yaWdodC13aWR0aDogMXB4OyBib3JkZXItcmln aHQtc3R5bGU6IHNvbGlkOyBib3JkZXItcmlnaHQtY29sb3I6IHJnYigyMDMsIDIwMywgMjAzKTsg cGFkZGluZzogM3B4IDAuNWVtOyB2ZXJ0aWNhbC1hbGlnbjogdG9wOyBib3JkZXItbGVmdC1zdHls ZTogaGlkZGVuOyBtaW4td2lkdGg6IDM3cHg7Ij4NCjwvdGQ+DQo8dGQgY2xhc3M9ImlwciIgc3R5 bGU9ImJvcmRlci1yaWdodC13aWR0aDogMXB4OyBib3JkZXItcmlnaHQtc3R5bGU6IHNvbGlkOyBi b3JkZXItcmlnaHQtY29sb3I6IHJnYigyMDMsIDIwMywgMjAzKTsgcGFkZGluZzogM3B4IDAuNWVt OyB2ZXJ0aWNhbC1hbGlnbjogdG9wOyI+DQo8L3RkPg0KPHRkIGNsYXNzPSJhZCIgc3R5bGU9ImJv cmRlci1yaWdodC13aWR0aDogMXB4OyBib3JkZXItcmlnaHQtc3R5bGU6IHNvbGlkOyBib3JkZXIt cmlnaHQtY29sb3I6IHJnYigyMDMsIDIwMywgMjAzKTsgcGFkZGluZzogM3B4IDAuNWVtOyB2ZXJ0 aWNhbC1hbGlnbjogdG9wOyB3aGl0ZS1zcGFjZTogbm93cmFwOyBtaW4td2lkdGg6IDZlbTsiPg0K PGRpdiBjbGFzcz0ic2VhcmNoLXRleHQtc2hlcGhlcmQiIHN0eWxlPSJjb2xvcjogcmdiKDEyOCwg MTI4LCAxMjgpOyI+PC9kaXY+DQo8L3RkPg0KPC90cj4NCjx0ciBjbGFzcz0iZXZlbnJvdyIgc3R5 bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYigyMzcsIDI0NSwgMjU1KTsiPg0KPHRkIGNsYXNzPSJk b2MiIHN0eWxlPSJib3JkZXItcmlnaHQtd2lkdGg6IDFweDsgYm9yZGVyLXJpZ2h0LXN0eWxlOiBz b2xpZDsgYm9yZGVyLXJpZ2h0LWNvbG9yOiByZ2IoMjAzLCAyMDMsIDIwMyk7IHBhZGRpbmc6IDNw eCAwLjVlbTsgdmVydGljYWwtYWxpZ246IHRvcDsgbWluLXdpZHRoOiAyMGVtOyBtYXgtd2lkdGg6 IDM1ZW07Ij4NCjxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt Y2hlbmctc3VwYS1kZGMtdXNlLWNhc2VzLyIgc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYmEo MjU1LCAyNTUsIDI1NSwgMCk7Ij48Zm9udCBjb2xvcj0iIzAwMDAwMCI+ZHJhZnQtY2hlbmctc3Vw YS1kZGMtdXNlLWNhc2VzLTAxPC9mb250PjwvYT48L3RkPg0KPHRkIGNsYXNzPSJ0aXRsZSIgc3R5 bGU9ImJvcmRlci1yaWdodC13aWR0aDogMXB4OyBib3JkZXItcmlnaHQtc3R5bGU6IHNvbGlkOyBi b3JkZXItcmlnaHQtY29sb3I6IHJnYigyMDMsIDIwMywgMjAzKTsgcGFkZGluZzogM3B4IDAuNWVt OyB2ZXJ0aWNhbC1hbGlnbjogdG9wOyBtaW4td2lkdGg6IDIwZW07IG1heC13aWR0aDogMzVlbTsi Pg0KPHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7 Ij5Vc2UgQ2FzZXMgZm9yIERpc3RyaWJ1dGVkIERhdGEgQ2VudGVyIEFwcGxpY2F0aW9ucyBpbiBT VVBBPC9zcGFuPjwvdGQ+DQo8dGQgY2xhc3M9ImRhdGUiIHN0eWxlPSJib3JkZXItcmlnaHQtd2lk dGg6IDFweDsgYm9yZGVyLXJpZ2h0LXN0eWxlOiBzb2xpZDsgYm9yZGVyLXJpZ2h0LWNvbG9yOiBy Z2IoMjAzLCAyMDMsIDIwMyk7IHBhZGRpbmc6IDNweCAwLjVlbTsgdmVydGljYWwtYWxpZ246IHRv cDsgd2hpdGUtc3BhY2U6IG5vd3JhcDsgbWluLXdpZHRoOiA2ZW07Ij4NCjxzcGFuIHN0eWxlPSJ3 aGl0ZS1zcGFjZTogbm9ybWFsOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAyNTUs IDApOyI+MjAxNC0xMC0yNzwvc3Bhbj4NCjxkaXYgY2xhc3M9ImlldGYtc21hbGwgaWV0Zi1oaWdo bGlnaHQteSIgc3R5bGU9ImZvbnQtc2l6ZTogMTFweDsgcGFkZGluZzogMHB4IDJweDsgYmFja2dy b3VuZC1jb2xvcjogeWVsbG93OyBiYWNrZ3JvdW5kLXBvc2l0aW9uOiBpbml0aWFsIGluaXRpYWw7 IGJhY2tncm91bmQtcmVwZWF0OiBpbml0aWFsIGluaXRpYWw7Ij4NCjxhIGhyZWY9Imh0dHA6Ly93 d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWNoZW5nLXN1cGEtZGRjLXVzZS1jYXNlcy0w MSIgc3R5bGU9IndoaXRlLXNwYWNlOiBub3JtYWw7IGJhY2tncm91bmQtY29sb3I6IHJnYmEoMjU1 LCAyNTUsIDI1NSwgMCk7Ij48Zm9udCBjb2xvcj0iIzAwMDAwMCIgc2l6ZT0iMyI+bmV3PC9mb250 PjwvYT48L2Rpdj4NCjwvdGQ+DQo8dGQgY2xhc3M9InN0YXR1cyIgc3R5bGU9ImJvcmRlci1yaWdo dC13aWR0aDogMXB4OyBib3JkZXItcmlnaHQtc3R5bGU6IHNvbGlkOyBib3JkZXItcmlnaHQtY29s b3I6IHJnYigyMDMsIDIwMywgMjAzKTsgcGFkZGluZzogM3B4IDAuNWVtOyB2ZXJ0aWNhbC1hbGln bjogdG9wOyBtaW4td2lkdGg6IDIwZW07Ij4NCjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9y OiByZ2JhKDI1NSwgMjU1LCAyNTUsIDApOyI+SS1EIEV4aXN0czwvc3Bhbj48L3RkPg0KPHRkIGNs YXNzPSJiYWxsb3QiIHN0eWxlPSJib3JkZXItcmlnaHQtd2lkdGg6IDFweDsgYm9yZGVyLXJpZ2h0 LXN0eWxlOiBzb2xpZDsgYm9yZGVyLXJpZ2h0LWNvbG9yOiByZ2IoMjAzLCAyMDMsIDIwMyk7IHBh ZGRpbmc6IDNweCAwLjVlbTsgdmVydGljYWwtYWxpZ246IHRvcDsgYm9yZGVyLWxlZnQtc3R5bGU6 IGhpZGRlbjsgbWluLXdpZHRoOiAzN3B4OyI+DQo8L3RkPg0KPHRkIGNsYXNzPSJpcHIiIHN0eWxl PSJib3JkZXItcmlnaHQtd2lkdGg6IDFweDsgYm9yZGVyLXJpZ2h0LXN0eWxlOiBzb2xpZDsgYm9y ZGVyLXJpZ2h0LWNvbG9yOiByZ2IoMjAzLCAyMDMsIDIwMyk7IHBhZGRpbmc6IDNweCAwLjVlbTsg dmVydGljYWwtYWxpZ246IHRvcDsiPg0KPC90ZD4NCjx0ZCBjbGFzcz0iYWQiIHN0eWxlPSJib3Jk ZXItcmlnaHQtd2lkdGg6IDFweDsgYm9yZGVyLXJpZ2h0LXN0eWxlOiBzb2xpZDsgYm9yZGVyLXJp Z2h0LWNvbG9yOiByZ2IoMjAzLCAyMDMsIDIwMyk7IHBhZGRpbmc6IDNweCAwLjVlbTsgdmVydGlj YWwtYWxpZ246IHRvcDsgd2hpdGUtc3BhY2U6IG5vd3JhcDsgbWluLXdpZHRoOiA2ZW07Ij4NCjxk aXYgY2xhc3M9InNlYXJjaC10ZXh0LXNoZXBoZXJkIiBzdHlsZT0iY29sb3I6IHJnYigxMjgsIDEy OCwgMTI4KTsiPjwvZGl2Pg0KPC90ZD4NCjwvdHI+DQo8dHIgY2xhc3M9Im9kZHJvdyIgc3R5bGU9 ImJhY2tncm91bmQtY29sb3I6IHdoaXRlOyI+DQo8dGQgY2xhc3M9ImRvYyIgc3R5bGU9ImJvcmRl ci1yaWdodC13aWR0aDogMXB4OyBib3JkZXItcmlnaHQtc3R5bGU6IHNvbGlkOyBib3JkZXItcmln aHQtY29sb3I6IHJnYigyMDMsIDIwMywgMjAzKTsgcGFkZGluZzogM3B4IDAuNWVtOyB2ZXJ0aWNh bC1hbGlnbjogdG9wOyBtaW4td2lkdGg6IDIwZW07IG1heC13aWR0aDogMzVlbTsiPg0KPGEgaHJl Zj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1jb250cmVyYXMtc3VwYS15 YW5nLW5ldHdvcmstdG9wby8iIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1 LCAyNTUsIDApOyI+PGZvbnQgY29sb3I9IiMwMDAwMDAiPmRyYWZ0LWNvbnRyZXJhcy1zdXBhLXlh bmctbmV0d29yay10b3BvLTAxPC9mb250PjwvYT48L3RkPg0KPHRkIGNsYXNzPSJ0aXRsZSIgc3R5 bGU9ImJvcmRlci1yaWdodC13aWR0aDogMXB4OyBib3JkZXItcmlnaHQtc3R5bGU6IHNvbGlkOyBi b3JkZXItcmlnaHQtY29sb3I6IHJnYigyMDMsIDIwMywgMjAzKTsgcGFkZGluZzogM3B4IDAuNWVt OyB2ZXJ0aWNhbC1hbGlnbjogdG9wOyBtaW4td2lkdGg6IDIwZW07IG1heC13aWR0aDogMzVlbTsi Pg0KPHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7 Ij5BIFlBTkcgRGF0YSBNb2RlbCBmb3IgTmV0d29yayBUb3BvbG9naWVzPC9zcGFuPjwvdGQ+DQo8 dGQgY2xhc3M9ImRhdGUiIHN0eWxlPSJib3JkZXItcmlnaHQtd2lkdGg6IDFweDsgYm9yZGVyLXJp Z2h0LXN0eWxlOiBzb2xpZDsgYm9yZGVyLXJpZ2h0LWNvbG9yOiByZ2IoMjAzLCAyMDMsIDIwMyk7 IHBhZGRpbmc6IDNweCAwLjVlbTsgdmVydGljYWwtYWxpZ246IHRvcDsgd2hpdGUtc3BhY2U6IG5v d3JhcDsgbWluLXdpZHRoOiA2ZW07Ij4NCjxzcGFuIHN0eWxlPSJ3aGl0ZS1zcGFjZTogbm9ybWFs OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAyNTUsIDApOyI+MjAxNC0xMC0yNzwv c3Bhbj4NCjxkaXYgY2xhc3M9ImlldGYtc21hbGwgaWV0Zi1oaWdobGlnaHQteSIgc3R5bGU9ImZv bnQtc2l6ZTogMTFweDsgcGFkZGluZzogMHB4IDJweDsgYmFja2dyb3VuZC1jb2xvcjogeWVsbG93 OyBiYWNrZ3JvdW5kLXBvc2l0aW9uOiBpbml0aWFsIGluaXRpYWw7IGJhY2tncm91bmQtcmVwZWF0 OiBpbml0aWFsIGluaXRpYWw7Ij4NCjxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlm Zj91cmwyPWRyYWZ0LWNvbnRyZXJhcy1zdXBhLXlhbmctbmV0d29yay10b3BvLTAxIiBzdHlsZT0i d2hpdGUtc3BhY2U6IG5vcm1hbDsgYmFja2dyb3VuZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwgMjU1 LCAwKTsiPjxmb250IGNvbG9yPSIjMDAwMDAwIiBzaXplPSIzIj5uZXc8L2ZvbnQ+PC9hPjwvZGl2 Pg0KPC90ZD4NCjx0ZCBjbGFzcz0ic3RhdHVzIiBzdHlsZT0iYm9yZGVyLXJpZ2h0LXdpZHRoOiAx cHg7IGJvcmRlci1yaWdodC1zdHlsZTogc29saWQ7IGJvcmRlci1yaWdodC1jb2xvcjogcmdiKDIw MywgMjAzLCAyMDMpOyBwYWRkaW5nOiAzcHggMC41ZW07IHZlcnRpY2FsLWFsaWduOiB0b3A7IG1p bi13aWR0aDogMjBlbTsiPg0KPHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYmEoMjU1 LCAyNTUsIDI1NSwgMCk7Ij5JLUQgRXhpc3RzPC9zcGFuPjwvdGQ+DQo8dGQgY2xhc3M9ImJhbGxv dCIgc3R5bGU9ImJvcmRlci1yaWdodC13aWR0aDogMXB4OyBib3JkZXItcmlnaHQtc3R5bGU6IHNv bGlkOyBib3JkZXItcmlnaHQtY29sb3I6IHJnYigyMDMsIDIwMywgMjAzKTsgcGFkZGluZzogM3B4 IDAuNWVtOyB2ZXJ0aWNhbC1hbGlnbjogdG9wOyBib3JkZXItbGVmdC1zdHlsZTogaGlkZGVuOyBt aW4td2lkdGg6IDM3cHg7Ij4NCjwvdGQ+DQo8dGQgY2xhc3M9ImlwciIgc3R5bGU9ImJvcmRlci1y aWdodC13aWR0aDogMXB4OyBib3JkZXItcmlnaHQtc3R5bGU6IHNvbGlkOyBib3JkZXItcmlnaHQt Y29sb3I6IHJnYigyMDMsIDIwMywgMjAzKTsgcGFkZGluZzogM3B4IDAuNWVtOyB2ZXJ0aWNhbC1h bGlnbjogdG9wOyI+DQo8L3RkPg0KPHRkIGNsYXNzPSJhZCIgc3R5bGU9ImJvcmRlci1yaWdodC13 aWR0aDogMXB4OyBib3JkZXItcmlnaHQtc3R5bGU6IHNvbGlkOyBib3JkZXItcmlnaHQtY29sb3I6 IHJnYigyMDMsIDIwMywgMjAzKTsgcGFkZGluZzogM3B4IDAuNWVtOyB2ZXJ0aWNhbC1hbGlnbjog dG9wOyB3aGl0ZS1zcGFjZTogbm93cmFwOyBtaW4td2lkdGg6IDZlbTsiPg0KPGRpdiBjbGFzcz0i c2VhcmNoLXRleHQtc2hlcGhlcmQiIHN0eWxlPSJjb2xvcjogcmdiKDEyOCwgMTI4LCAxMjgpOyI+ PC9kaXY+DQo8L3RkPg0KPC90cj4NCjx0ciBjbGFzcz0iZXZlbnJvdyIgc3R5bGU9ImJhY2tncm91 bmQtY29sb3I6IHJnYigyMzcsIDI0NSwgMjU1KTsiPg0KPHRkIGNsYXNzPSJkb2MiIHN0eWxlPSJi b3JkZXItcmlnaHQtd2lkdGg6IDFweDsgYm9yZGVyLXJpZ2h0LXN0eWxlOiBzb2xpZDsgYm9yZGVy LXJpZ2h0LWNvbG9yOiByZ2IoMjAzLCAyMDMsIDIwMyk7IHBhZGRpbmc6IDNweCAwLjVlbTsgdmVy dGljYWwtYWxpZ246IHRvcDsgbWluLXdpZHRoOiAyMGVtOyBtYXgtd2lkdGg6IDM1ZW07Ij4NCjxh IGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQta2FyYWdpYW5uaXMt c3VwYS1wcm9ibGVtLXN0YXRlbWVudC8iIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1 NSwgMjU1LCAyNTUsIDApOyI+PGZvbnQgY29sb3I9IiMwMDAwMDAiPmRyYWZ0LWthcmFnaWFubmlz LXN1cGEtcHJvYmxlbS1zdGF0ZW1lbnQtMDI8L2ZvbnQ+PC9hPjwvdGQ+DQo8dGQgY2xhc3M9InRp dGxlIiBzdHlsZT0iYm9yZGVyLXJpZ2h0LXdpZHRoOiAxcHg7IGJvcmRlci1yaWdodC1zdHlsZTog c29saWQ7IGJvcmRlci1yaWdodC1jb2xvcjogcmdiKDIwMywgMjAzLCAyMDMpOyBwYWRkaW5nOiAz cHggMC41ZW07IHZlcnRpY2FsLWFsaWduOiB0b3A7IG1pbi13aWR0aDogMjBlbTsgbWF4LXdpZHRo OiAzNWVtOyI+DQo8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwg MjU1LCAwKTsiPlByb2JsZW0gU3RhdGVtZW50IGZvciBTaGFyZWQgVW5pZmllZCBQb2xpY3kgQXV0 b21hdGlvbiAoU1VQQSk8L3NwYW4+PC90ZD4NCjx0ZCBjbGFzcz0iZGF0ZSIgc3R5bGU9ImJvcmRl ci1yaWdodC13aWR0aDogMXB4OyBib3JkZXItcmlnaHQtc3R5bGU6IHNvbGlkOyBib3JkZXItcmln aHQtY29sb3I6IHJnYigyMDMsIDIwMywgMjAzKTsgcGFkZGluZzogM3B4IDAuNWVtOyB2ZXJ0aWNh bC1hbGlnbjogdG9wOyB3aGl0ZS1zcGFjZTogbm93cmFwOyBtaW4td2lkdGg6IDZlbTsiPg0KPHNw YW4gc3R5bGU9IndoaXRlLXNwYWNlOiBub3JtYWw7IGJhY2tncm91bmQtY29sb3I6IHJnYmEoMjU1 LCAyNTUsIDI1NSwgMCk7Ij4yMDE0LTEwLTI3PC9zcGFuPg0KPGRpdiBjbGFzcz0iaWV0Zi1zbWFs bCBpZXRmLWhpZ2hsaWdodC15IiBzdHlsZT0iZm9udC1zaXplOiAxMXB4OyBwYWRkaW5nOiAwcHgg MnB4OyBiYWNrZ3JvdW5kLWNvbG9yOiB5ZWxsb3c7IGJhY2tncm91bmQtcG9zaXRpb246IGluaXRp YWwgaW5pdGlhbDsgYmFja2dyb3VuZC1yZXBlYXQ6IGluaXRpYWwgaW5pdGlhbDsiPg0KPGEgaHJl Zj0iaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQta2FyYWdpYW5uaXMtc3Vw YS1wcm9ibGVtLXN0YXRlbWVudC0wMiIgc3R5bGU9IndoaXRlLXNwYWNlOiBub3JtYWw7IGJhY2tn cm91bmQtY29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7Ij48Zm9udCBjb2xvcj0iIzAwMDAw MCIgc2l6ZT0iMyI+bmV3PC9mb250PjwvYT48L2Rpdj4NCjwvdGQ+DQo8dGQgY2xhc3M9InN0YXR1 cyIgc3R5bGU9ImJvcmRlci1yaWdodC13aWR0aDogMXB4OyBib3JkZXItcmlnaHQtc3R5bGU6IHNv bGlkOyBib3JkZXItcmlnaHQtY29sb3I6IHJnYigyMDMsIDIwMywgMjAzKTsgcGFkZGluZzogM3B4 IDAuNWVtOyB2ZXJ0aWNhbC1hbGlnbjogdG9wOyBtaW4td2lkdGg6IDIwZW07Ij4NCjxzcGFuIHN0 eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAyNTUsIDApOyI+SS1EIEV4aXN0 czwvc3Bhbj48L3RkPg0KPHRkIGNsYXNzPSJiYWxsb3QiIHN0eWxlPSJib3JkZXItcmlnaHQtd2lk dGg6IDFweDsgYm9yZGVyLXJpZ2h0LXN0eWxlOiBzb2xpZDsgYm9yZGVyLXJpZ2h0LWNvbG9yOiBy Z2IoMjAzLCAyMDMsIDIwMyk7IHBhZGRpbmc6IDNweCAwLjVlbTsgdmVydGljYWwtYWxpZ246IHRv cDsgYm9yZGVyLWxlZnQtc3R5bGU6IGhpZGRlbjsgbWluLXdpZHRoOiAzN3B4OyI+DQo8L3RkPg0K PHRkIGNsYXNzPSJpcHIiIHN0eWxlPSJib3JkZXItcmlnaHQtd2lkdGg6IDFweDsgYm9yZGVyLXJp Z2h0LXN0eWxlOiBzb2xpZDsgYm9yZGVyLXJpZ2h0LWNvbG9yOiByZ2IoMjAzLCAyMDMsIDIwMyk7 IHBhZGRpbmc6IDNweCAwLjVlbTsgdmVydGljYWwtYWxpZ246IHRvcDsiPg0KPC90ZD4NCjx0ZCBj bGFzcz0iYWQiIHN0eWxlPSJib3JkZXItcmlnaHQtd2lkdGg6IDFweDsgYm9yZGVyLXJpZ2h0LXN0 eWxlOiBzb2xpZDsgYm9yZGVyLXJpZ2h0LWNvbG9yOiByZ2IoMjAzLCAyMDMsIDIwMyk7IHBhZGRp bmc6IDNweCAwLjVlbTsgdmVydGljYWwtYWxpZ246IHRvcDsgd2hpdGUtc3BhY2U6IG5vd3JhcDsg bWluLXdpZHRoOiA2ZW07Ij4NCjxkaXYgY2xhc3M9InNlYXJjaC10ZXh0LXNoZXBoZXJkIiBzdHls ZT0iY29sb3I6IHJnYigxMjgsIDEyOCwgMTI4KTsiPjwvZGl2Pg0KPC90ZD4NCjwvdHI+DQo8dHIg Y2xhc3M9Im9kZHJvdyIgc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHdoaXRlOyI+DQo8dGQgY2xh c3M9ImRvYyIgc3R5bGU9ImJvcmRlci1yaWdodC13aWR0aDogMXB4OyBib3JkZXItcmlnaHQtc3R5 bGU6IHNvbGlkOyBib3JkZXItcmlnaHQtY29sb3I6IHJnYigyMDMsIDIwMywgMjAzKTsgcGFkZGlu ZzogM3B4IDAuNWVtOyB2ZXJ0aWNhbC1hbGlnbjogdG9wOyBtaW4td2lkdGg6IDIwZW07IG1heC13 aWR0aDogMzVlbTsiPg0KPGEgaHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1wZW50aWtvdXNpcy1zdXBhLW1hcHBpbmcvIiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjog cmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsiPjxmb250IGNvbG9yPSIjMDAwMDAwIj5kcmFmdC1wZW50 aWtvdXNpcy1zdXBhLW1hcHBpbmctMDA8L2ZvbnQ+PC9hPjwvdGQ+DQo8dGQgY2xhc3M9InRpdGxl IiBzdHlsZT0iYm9yZGVyLXJpZ2h0LXdpZHRoOiAxcHg7IGJvcmRlci1yaWdodC1zdHlsZTogc29s aWQ7IGJvcmRlci1yaWdodC1jb2xvcjogcmdiKDIwMywgMjAzLCAyMDMpOyBwYWRkaW5nOiAzcHgg MC41ZW07IHZlcnRpY2FsLWFsaWduOiB0b3A7IG1pbi13aWR0aDogMjBlbTsgbWF4LXdpZHRoOiAz NWVtOyI+DQo8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwgMjU1 LCAwKTsiPlNVUEEgQ29uZmlndXJhdGlvbiBhbmQgUG9saWN5IE1hcHBpbmc8L3NwYW4+PC90ZD4N Cjx0ZCBjbGFzcz0iZGF0ZSIgc3R5bGU9ImJvcmRlci1yaWdodC13aWR0aDogMXB4OyBib3JkZXIt cmlnaHQtc3R5bGU6IHNvbGlkOyBib3JkZXItcmlnaHQtY29sb3I6IHJnYigyMDMsIDIwMywgMjAz KTsgcGFkZGluZzogM3B4IDAuNWVtOyB2ZXJ0aWNhbC1hbGlnbjogdG9wOyB3aGl0ZS1zcGFjZTog bm93cmFwOyBtaW4td2lkdGg6IDZlbTsiPg0KPHNwYW4gc3R5bGU9IndoaXRlLXNwYWNlOiBub3Jt YWw7IGJhY2tncm91bmQtY29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7Ij4yMDE0LTA5LTIz PC9zcGFuPjwvdGQ+DQo8dGQgY2xhc3M9InN0YXR1cyIgc3R5bGU9ImJvcmRlci1yaWdodC13aWR0 aDogMXB4OyBib3JkZXItcmlnaHQtc3R5bGU6IHNvbGlkOyBib3JkZXItcmlnaHQtY29sb3I6IHJn YigyMDMsIDIwMywgMjAzKTsgcGFkZGluZzogM3B4IDAuNWVtOyB2ZXJ0aWNhbC1hbGlnbjogdG9w OyBtaW4td2lkdGg6IDIwZW07Ij4NCjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2Jh KDI1NSwgMjU1LCAyNTUsIDApOyI+SS1EIEV4aXN0czwvc3Bhbj48L3RkPg0KPHRkIGNsYXNzPSJi YWxsb3QiIHN0eWxlPSJib3JkZXItcmlnaHQtd2lkdGg6IDFweDsgYm9yZGVyLXJpZ2h0LXN0eWxl OiBzb2xpZDsgYm9yZGVyLXJpZ2h0LWNvbG9yOiByZ2IoMjAzLCAyMDMsIDIwMyk7IHBhZGRpbmc6 IDNweCAwLjVlbTsgdmVydGljYWwtYWxpZ246IHRvcDsgYm9yZGVyLWxlZnQtc3R5bGU6IGhpZGRl bjsgbWluLXdpZHRoOiAzN3B4OyI+DQo8L3RkPg0KPHRkIGNsYXNzPSJpcHIiIHN0eWxlPSJib3Jk ZXItcmlnaHQtd2lkdGg6IDFweDsgYm9yZGVyLXJpZ2h0LXN0eWxlOiBzb2xpZDsgYm9yZGVyLXJp Z2h0LWNvbG9yOiByZ2IoMjAzLCAyMDMsIDIwMyk7IHBhZGRpbmc6IDNweCAwLjVlbTsgdmVydGlj YWwtYWxpZ246IHRvcDsiPg0KPC90ZD4NCjx0ZCBjbGFzcz0iYWQiIHN0eWxlPSJib3JkZXItcmln aHQtd2lkdGg6IDFweDsgYm9yZGVyLXJpZ2h0LXN0eWxlOiBzb2xpZDsgYm9yZGVyLXJpZ2h0LWNv bG9yOiByZ2IoMjAzLCAyMDMsIDIwMyk7IHBhZGRpbmc6IDNweCAwLjVlbTsgdmVydGljYWwtYWxp Z246IHRvcDsgd2hpdGUtc3BhY2U6IG5vd3JhcDsgbWluLXdpZHRoOiA2ZW07Ij4NCjxkaXYgY2xh c3M9InNlYXJjaC10ZXh0LXNoZXBoZXJkIiBzdHlsZT0iY29sb3I6IHJnYigxMjgsIDEyOCwgMTI4 KTsiPjwvZGl2Pg0KPC90ZD4NCjwvdHI+DQo8dHIgY2xhc3M9ImV2ZW5yb3ciIHN0eWxlPSJiYWNr Z3JvdW5kLWNvbG9yOiByZ2IoMjM3LCAyNDUsIDI1NSk7Ij4NCjx0ZCBjbGFzcz0iZG9jIiBzdHls ZT0iYm9yZGVyLXJpZ2h0LXdpZHRoOiAxcHg7IGJvcmRlci1yaWdodC1zdHlsZTogc29saWQ7IGJv cmRlci1yaWdodC1jb2xvcjogcmdiKDIwMywgMjAzLCAyMDMpOyBwYWRkaW5nOiAzcHggMC41ZW07 IHZlcnRpY2FsLWFsaWduOiB0b3A7IG1pbi13aWR0aDogMjBlbTsgbWF4LXdpZHRoOiAzNWVtOyI+ DQo8YSBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXN1bi1zdXBh LW9wZW52Ni11c2UtY2FzZXMvIiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogcmdiYSgyNTUsIDI1 NSwgMjU1LCAwKTsiPjxmb250IGNvbG9yPSIjMDAwMDAwIj5kcmFmdC1zdW4tc3VwYS1vcGVudjYt dXNlLWNhc2VzLTAwPC9mb250PjwvYT48L3RkPg0KPHRkIGNsYXNzPSJ0aXRsZSIgc3R5bGU9ImJv cmRlci1yaWdodC13aWR0aDogMXB4OyBib3JkZXItcmlnaHQtc3R5bGU6IHNvbGlkOyBib3JkZXIt cmlnaHQtY29sb3I6IHJnYigyMDMsIDIwMywgMjAzKTsgcGFkZGluZzogM3B4IDAuNWVtOyB2ZXJ0 aWNhbC1hbGlnbjogdG9wOyBtaW4td2lkdGg6IDIwZW07IG1heC13aWR0aDogMzVlbTsiPg0KPHNw YW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7Ij5Vc2Ug Y2FzZSBvZiBJUHY2IHRyYW5zaXRpb24gaW4gU1VQQTwvc3Bhbj48L3RkPg0KPHRkIGNsYXNzPSJk YXRlIiBzdHlsZT0iYm9yZGVyLXJpZ2h0LXdpZHRoOiAxcHg7IGJvcmRlci1yaWdodC1zdHlsZTog c29saWQ7IGJvcmRlci1yaWdodC1jb2xvcjogcmdiKDIwMywgMjAzLCAyMDMpOyBwYWRkaW5nOiAz cHggMC41ZW07IHZlcnRpY2FsLWFsaWduOiB0b3A7IHdoaXRlLXNwYWNlOiBub3dyYXA7IG1pbi13 aWR0aDogNmVtOyI+DQo8c3BhbiBzdHlsZT0id2hpdGUtc3BhY2U6IG5vcm1hbDsgYmFja2dyb3Vu ZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsiPjIwMTQtMDktMjU8L3NwYW4+PC90ZD4N Cjx0ZCBjbGFzcz0ic3RhdHVzIiBzdHlsZT0iYm9yZGVyLXJpZ2h0LXdpZHRoOiAxcHg7IGJvcmRl ci1yaWdodC1zdHlsZTogc29saWQ7IGJvcmRlci1yaWdodC1jb2xvcjogcmdiKDIwMywgMjAzLCAy MDMpOyBwYWRkaW5nOiAzcHggMC41ZW07IHZlcnRpY2FsLWFsaWduOiB0b3A7IG1pbi13aWR0aDog MjBlbTsiPg0KPHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1 NSwgMCk7Ij5JLUQgRXhpc3RzPC9zcGFuPjwvdGQ+DQo8dGQgY2xhc3M9ImJhbGxvdCIgc3R5bGU9 ImJvcmRlci1yaWdodC13aWR0aDogMXB4OyBib3JkZXItcmlnaHQtc3R5bGU6IHNvbGlkOyBib3Jk ZXItcmlnaHQtY29sb3I6IHJnYigyMDMsIDIwMywgMjAzKTsgcGFkZGluZzogM3B4IDAuNWVtOyB2 ZXJ0aWNhbC1hbGlnbjogdG9wOyBib3JkZXItbGVmdC1zdHlsZTogaGlkZGVuOyBtaW4td2lkdGg6 IDM3cHg7Ij4NCjwvdGQ+DQo8dGQgY2xhc3M9ImlwciIgc3R5bGU9ImJvcmRlci1yaWdodC13aWR0 aDogMXB4OyBib3JkZXItcmlnaHQtc3R5bGU6IHNvbGlkOyBib3JkZXItcmlnaHQtY29sb3I6IHJn YigyMDMsIDIwMywgMjAzKTsgcGFkZGluZzogM3B4IDAuNWVtOyB2ZXJ0aWNhbC1hbGlnbjogdG9w OyI+DQo8L3RkPg0KPHRkIGNsYXNzPSJhZCIgc3R5bGU9ImJvcmRlci1yaWdodC13aWR0aDogMXB4 OyBib3JkZXItcmlnaHQtc3R5bGU6IHNvbGlkOyBib3JkZXItcmlnaHQtY29sb3I6IHJnYigyMDMs IDIwMywgMjAzKTsgcGFkZGluZzogM3B4IDAuNWVtOyB2ZXJ0aWNhbC1hbGlnbjogdG9wOyB3aGl0 ZS1zcGFjZTogbm93cmFwOyBtaW4td2lkdGg6IDZlbTsiPg0KPGRpdiBjbGFzcz0ic2VhcmNoLXRl eHQtc2hlcGhlcmQiIHN0eWxlPSJjb2xvcjogcmdiKDEyOCwgMTI4LCAxMjgpOyI+PC9kaXY+DQo8 L3RkPg0KPC90cj4NCjx0ciBjbGFzcz0ib2Rkcm93IiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjog d2hpdGU7Ij4NCjx0ZCBjbGFzcz0iZG9jIiBzdHlsZT0iYm9yZGVyLXJpZ2h0LXdpZHRoOiAxcHg7 IGJvcmRlci1yaWdodC1zdHlsZTogc29saWQ7IGJvcmRlci1yaWdodC1jb2xvcjogcmdiKDIwMywg MjAzLCAyMDMpOyBwYWRkaW5nOiAzcHggMC41ZW07IHZlcnRpY2FsLWFsaWduOiB0b3A7IG1pbi13 aWR0aDogMjBlbTsgbWF4LXdpZHRoOiAzNWVtOyI+DQo8YSBocmVmPSJodHRwOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXphYWxvdWstc3VwYS1jb25maWd1cmF0aW9uLW1vZGVsLyIg c3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7Ij48Zm9udCBj b2xvcj0iIzAwMDAwMCI+ZHJhZnQtemFhbG91ay1zdXBhLWNvbmZpZ3VyYXRpb24tbW9kZWwtMDE8 L2ZvbnQ+PC9hPjwvdGQ+DQo8dGQgY2xhc3M9InRpdGxlIiBzdHlsZT0iYm9yZGVyLXJpZ2h0LXdp ZHRoOiAxcHg7IGJvcmRlci1yaWdodC1zdHlsZTogc29saWQ7IGJvcmRlci1yaWdodC1jb2xvcjog cmdiKDIwMywgMjAzLCAyMDMpOyBwYWRkaW5nOiAzcHggMC41ZW07IHZlcnRpY2FsLWFsaWduOiB0 b3A7IG1pbi13aWR0aDogMjBlbTsgbWF4LXdpZHRoOiAzNWVtOyI+DQo8c3BhbiBzdHlsZT0iYmFj a2dyb3VuZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsiPllBTkcgRGF0YSBNb2RlbCBm b3IgQ29uZmlndXJhdGlvbiBvZiBTaGFyZWQgVW5pZmllZCBQb2xpY3kgQXV0b21hdGlvbiAoU1VQ QSk8L3NwYW4+PC90ZD4NCjx0ZCBjbGFzcz0iZGF0ZSIgc3R5bGU9ImJvcmRlci1yaWdodC13aWR0 aDogMXB4OyBib3JkZXItcmlnaHQtc3R5bGU6IHNvbGlkOyBib3JkZXItcmlnaHQtY29sb3I6IHJn YigyMDMsIDIwMywgMjAzKTsgcGFkZGluZzogM3B4IDAuNWVtOyB2ZXJ0aWNhbC1hbGlnbjogdG9w OyB3aGl0ZS1zcGFjZTogbm93cmFwOyBtaW4td2lkdGg6IDZlbTsiPg0KPHNwYW4gc3R5bGU9Indo aXRlLXNwYWNlOiBub3JtYWw7IGJhY2tncm91bmQtY29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwg MCk7Ij4yMDE0LTEwLTI3PC9zcGFuPg0KPGRpdiBjbGFzcz0iaWV0Zi1zbWFsbCBpZXRmLWhpZ2hs aWdodC15IiBzdHlsZT0iZm9udC1zaXplOiAxMXB4OyBwYWRkaW5nOiAwcHggMnB4OyBiYWNrZ3Jv dW5kLWNvbG9yOiB5ZWxsb3c7IGJhY2tncm91bmQtcG9zaXRpb246IGluaXRpYWwgaW5pdGlhbDsg YmFja2dyb3VuZC1yZXBlYXQ6IGluaXRpYWwgaW5pdGlhbDsiPg0KPGEgaHJlZj0iaHR0cDovL3d3 dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtemFhbG91ay1zdXBhLWNvbmZpZ3VyYXRpb24t bW9kZWwtMDEiIHN0eWxlPSJ3aGl0ZS1zcGFjZTogbm9ybWFsOyBiYWNrZ3JvdW5kLWNvbG9yOiBy Z2JhKDI1NSwgMjU1LCAyNTUsIDApOyI+PGZvbnQgY29sb3I9IiMwMDAwMDAiIHNpemU9IjMiPm5l dzwvZm9udD48L2E+PC9kaXY+DQo8L3RkPg0KPHRkIGNsYXNzPSJzdGF0dXMiIHN0eWxlPSJib3Jk ZXItcmlnaHQtd2lkdGg6IDFweDsgYm9yZGVyLXJpZ2h0LXN0eWxlOiBzb2xpZDsgYm9yZGVyLXJp Z2h0LWNvbG9yOiByZ2IoMjAzLCAyMDMsIDIwMyk7IHBhZGRpbmc6IDNweCAwLjVlbTsgdmVydGlj YWwtYWxpZ246IHRvcDsgbWluLXdpZHRoOiAyMGVtOyI+DQo8c3BhbiBzdHlsZT0iYmFja2dyb3Vu ZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsiPkktRCBFeGlzdHM8L3NwYW4+PC90ZD4N Cjx0ZCBjbGFzcz0iYmFsbG90IiBzdHlsZT0iYm9yZGVyLXJpZ2h0LXdpZHRoOiAxcHg7IGJvcmRl ci1yaWdodC1zdHlsZTogc29saWQ7IGJvcmRlci1yaWdodC1jb2xvcjogcmdiKDIwMywgMjAzLCAy MDMpOyBwYWRkaW5nOiAzcHggMC41ZW07IHZlcnRpY2FsLWFsaWduOiB0b3A7IGJvcmRlci1sZWZ0 LXN0eWxlOiBoaWRkZW47IG1pbi13aWR0aDogMzdweDsiPg0KPC90ZD4NCjx0ZCBjbGFzcz0iaXBy IiBzdHlsZT0iYm9yZGVyLXJpZ2h0LXdpZHRoOiAxcHg7IGJvcmRlci1yaWdodC1zdHlsZTogc29s aWQ7IGJvcmRlci1yaWdodC1jb2xvcjogcmdiKDIwMywgMjAzLCAyMDMpOyBwYWRkaW5nOiAzcHgg MC41ZW07IHZlcnRpY2FsLWFsaWduOiB0b3A7Ij4NCjwvdGQ+DQo8dGQgY2xhc3M9ImFkIiBzdHls ZT0iYm9yZGVyLXJpZ2h0LXdpZHRoOiAxcHg7IGJvcmRlci1yaWdodC1zdHlsZTogc29saWQ7IGJv cmRlci1yaWdodC1jb2xvcjogcmdiKDIwMywgMjAzLCAyMDMpOyBwYWRkaW5nOiAzcHggMC41ZW07 IHZlcnRpY2FsLWFsaWduOiB0b3A7IHdoaXRlLXNwYWNlOiBub3dyYXA7IG1pbi13aWR0aDogNmVt OyI+DQo8ZGl2IGNsYXNzPSJzZWFyY2gtdGV4dC1zaGVwaGVyZCIgc3R5bGU9ImNvbG9yOiByZ2Io MTI4LCAxMjgsIDEyOCk7Ij48L2Rpdj4NCjwvdGQ+DQo8L3RyPg0KPHRyIGNsYXNzPSJldmVucm93 IiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogcmdiKDIzNywgMjQ1LCAyNTUpOyI+DQo8dGQgY2xh c3M9ImRvYyIgc3R5bGU9ImJvcmRlci1yaWdodC13aWR0aDogMXB4OyBib3JkZXItcmlnaHQtc3R5 bGU6IHNvbGlkOyBib3JkZXItcmlnaHQtY29sb3I6IHJnYigyMDMsIDIwMywgMjAzKTsgcGFkZGlu ZzogM3B4IDAuNWVtOyB2ZXJ0aWNhbC1hbGlnbjogdG9wOyBtaW4td2lkdGg6IDIwZW07IG1heC13 aWR0aDogMzVlbTsiPg0KPGEgaHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC16aG91LXN1cGEtYXJjaGl0ZWN0dXJlLyIgc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJn YmEoMjU1LCAyNTUsIDI1NSwgMCk7Ij48Zm9udCBjb2xvcj0iIzAwMDAwMCI+ZHJhZnQtemhvdS1z dXBhLWFyY2hpdGVjdHVyZS0wMDwvZm9udD48L2E+PC90ZD4NCjx0ZCBjbGFzcz0idGl0bGUiIHN0 eWxlPSJib3JkZXItcmlnaHQtd2lkdGg6IDFweDsgYm9yZGVyLXJpZ2h0LXN0eWxlOiBzb2xpZDsg Ym9yZGVyLXJpZ2h0LWNvbG9yOiByZ2IoMjAzLCAyMDMsIDIwMyk7IHBhZGRpbmc6IDNweCAwLjVl bTsgdmVydGljYWwtYWxpZ246IHRvcDsgbWluLXdpZHRoOiAyMGVtOyBtYXgtd2lkdGg6IDM1ZW07 Ij4NCjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAyNTUsIDAp OyI+VGhlIEFyY2hpdGVjdHVyZSBmb3IgU2hhcmVkIFVuaWZpZWQgUG9saWN5IEF1dG9tYXRpb24g KFNVUEEpPC9zcGFuPjwvdGQ+DQo8dGQgY2xhc3M9ImRhdGUiIHN0eWxlPSJib3JkZXItcmlnaHQt d2lkdGg6IDFweDsgYm9yZGVyLXJpZ2h0LXN0eWxlOiBzb2xpZDsgYm9yZGVyLXJpZ2h0LWNvbG9y OiByZ2IoMjAzLCAyMDMsIDIwMyk7IHBhZGRpbmc6IDNweCAwLjVlbTsgdmVydGljYWwtYWxpZ246 IHRvcDsgd2hpdGUtc3BhY2U6IG5vd3JhcDsgbWluLXdpZHRoOiA2ZW07Ij4NCjxzcGFuIHN0eWxl PSJ3aGl0ZS1zcGFjZTogbm9ybWFsOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAy NTUsIDApOyI+MjAxNC0xMC0yNzwvc3Bhbj4NCjxkaXYgY2xhc3M9ImlldGYtc21hbGwgaWV0Zi1o aWdobGlnaHQteSIgc3R5bGU9ImZvbnQtc2l6ZTogMTFweDsgcGFkZGluZzogMHB4IDJweDsgYmFj a2dyb3VuZC1jb2xvcjogeWVsbG93OyBiYWNrZ3JvdW5kLXBvc2l0aW9uOiBpbml0aWFsIGluaXRp YWw7IGJhY2tncm91bmQtcmVwZWF0OiBpbml0aWFsIGluaXRpYWw7Ij4NCjxhIGhyZWY9Imh0dHA6 Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXpob3Utc3VwYS1hcmNoaXRlY3R1cmUt MDAiIHN0eWxlPSJ3aGl0ZS1zcGFjZTogbm9ybWFsOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1 NSwgMjU1LCAyNTUsIDApOyI+PGZvbnQgY29sb3I9IiMwMDAwMDAiIHNpemU9IjMiPm5ldzwvZm9u dD48L2E+PC9kaXY+DQo8L3RkPg0KPHRkIGNsYXNzPSJzdGF0dXMiIHN0eWxlPSJib3JkZXItcmln aHQtd2lkdGg6IDFweDsgYm9yZGVyLXJpZ2h0LXN0eWxlOiBzb2xpZDsgYm9yZGVyLXJpZ2h0LWNv bG9yOiByZ2IoMjAzLCAyMDMsIDIwMyk7IHBhZGRpbmc6IDNweCAwLjVlbTsgdmVydGljYWwtYWxp Z246IHRvcDsgbWluLXdpZHRoOiAyMGVtOyI+DQo8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xv cjogcmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsiPkktRCBFeGlzdHM8L3NwYW4+PC90ZD4NCjx0ZCBj bGFzcz0iYmFsbG90IiBzdHlsZT0iYm9yZGVyLXJpZ2h0LXdpZHRoOiAxcHg7IGJvcmRlci1yaWdo dC1zdHlsZTogc29saWQ7IGJvcmRlci1yaWdodC1jb2xvcjogcmdiKDIwMywgMjAzLCAyMDMpOyBw YWRkaW5nOiAzcHggMC41ZW07IHZlcnRpY2FsLWFsaWduOiB0b3A7IGJvcmRlci1sZWZ0LXN0eWxl OiBoaWRkZW47IG1pbi13aWR0aDogMzdweDsiPg0KPC90ZD4NCjx0ZCBjbGFzcz0iaXByIiBzdHls ZT0iYm9yZGVyLXJpZ2h0LXdpZHRoOiAxcHg7IGJvcmRlci1yaWdodC1zdHlsZTogc29saWQ7IGJv cmRlci1yaWdodC1jb2xvcjogcmdiKDIwMywgMjAzLCAyMDMpOyBwYWRkaW5nOiAzcHggMC41ZW07 IHZlcnRpY2FsLWFsaWduOiB0b3A7Ij4NCjwvdGQ+DQo8dGQgY2xhc3M9ImFkIiBzdHlsZT0iYm9y ZGVyLXJpZ2h0LXdpZHRoOiAxcHg7IGJvcmRlci1yaWdodC1zdHlsZTogc29saWQ7IGJvcmRlci1y aWdodC1jb2xvcjogcmdiKDIwMywgMjAzLCAyMDMpOyBwYWRkaW5nOiAzcHggMC41ZW07IHZlcnRp Y2FsLWFsaWduOiB0b3A7IHdoaXRlLXNwYWNlOiBub3dyYXA7IG1pbi13aWR0aDogNmVtOyI+DQo8 ZGl2IGNsYXNzPSJzZWFyY2gtdGV4dC1zaGVwaGVyZCIgc3R5bGU9ImNvbG9yOiByZ2IoMTI4LCAx MjgsIDEyOCk7Ij48L2Rpdj4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhhbmsgeW91LDwvZGl2Pg0K PGRpdj5UaW5hPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_F5CDDBCBD59C4910A56E91021A057DBBhuaweicom_-- From nobody Fri Oct 31 02:16:32 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7BC61A7D80 for ; Fri, 31 Oct 2014 02:16:28 -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 T7tZ3okpUPHv for ; Fri, 31 Oct 2014 02:16:26 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 714C71A6FA8 for ; Fri, 31 Oct 2014 02:16:26 -0700 (PDT) Received: from [192.168.1.108] (unknown [195.113.220.254]) by mail.nic.cz (Postfix) with ESMTPSA id BB02D13FD92; Fri, 31 Oct 2014 10:16:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1414746984; bh=pfhlqiOViAFsgaTYCP0MFcKRvcYTwpQEAC+97pCp3MM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=XUbDPX8iVgYznWbIaO137lrm8U6Lpye1Hcoe7b4jrKWAXeSOdBqC8Uil3AkuybTzO nHFbD/foalDPmnmmhVM8TrLe/jMu12f1hmWpYatPK2piNQ/YRkGqSwodxj1wPhlqK+ U9SJMe5qkHAh4D1jceIRcWgWnUsXPpJ6cQ4Q5Su8= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 31 Oct 2014 10:16:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141029150630.GA17776@elstar.local> <20141029233236.GA19176@elstar.local> <20141030.120159.198377535691531775.mbj@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/SCn8UDL1-lkAXz28SjUyxUvgm3E Cc: "netmod@ietf.org" Subject: Re: [netmod] yang 1.1 webex on wednesday october 29th X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 31 Oct 2014 09:16:29 -0000 On 30 Oct 2014, at 18:00, Andy Bierman wrote: > On Thu, Oct 30, 2014 at 8:57 AM, Ladislav Lhotka = wrote: >>=20 >> On 30 Oct 2014, at 12:01, Martin Bjorklund wrote: >>=20 >>> Juergen Schoenwaelder wrote: >>>> On Wed, Oct 29, 2014 at 01:19:12PM -0700, Andy Bierman wrote: >>>>>=20 >>>>> IMO, the server vendor is responsible for providing a cohesive = module set. >>>>> This doesn't happen automatically and it is a huge problem for = open systems, >>>>> but clearly no implemented object can use an obsolete typedef. >>>>> The new YANG guidelines draft says a module should stay in = "deprecated" status >>>>> for at least a year. That just delays this problem. >>>>>=20 >>>>=20 >>>> As long as you control all your modules, this may be achievable. If >>>> you, however, implement a mix of modules, some under your control = and >>>> some not, then I assume you may have a hard time. >>>=20 >>> Yes, but consider the alternative. Suppose we have two versions of = a >>> typedef, one with an expanded range. We also have a bunch of leafs = in >>> various data models that reference this typedef. If we also have >>> something like the proposed mount mechanism (or some subagent >>> mechanism), then it means that potentially the client somehow needs = to >>> figure out which version of the type is used for every single = instance >>> of these leafs in the *data store*. I.e., it is not sufficient to = say >>> that a certain module uses a certain revision of a typedef; it can = be >>> different for different data instances as well. >>=20 >> In the case of mount, I think the only reasonable solution is to = forward somehow to the client the information about exact versions of = modules used for mounted subtrees. Perhaps this could be attached as = metadata to each mount point. >>=20 >> The format of capabilities in hello doesn=92t scale well for complex = data model specifications. >>=20 >=20 >=20 > I don't agree that the message scales are worse than = retrieving the It does, because all information has to be packed as URI parameters. I = don=92t understand the design decision to use URI as the format for = capabilities, it could have been a nicely structured XML snippet with = content specific for each capability. Lada > same information with a operation. I don't understand the value > of replicating all the server data models in a controller (or is it a > glorified cache?), > but that is a different issue. >=20 >=20 >> Lada >=20 > Andy >=20 >>=20 >>>=20 >>> The only (?) 100% safe thing to do would be to never allow any = changes >>> in the value space for a typedef or grouping. Then we'll see >>> constructs like this: >>>=20 >>> typedef foo { ... } >>> typedef foo-v2 { ... } >>> typedef foo-v3 { ... } >>>=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 >> _______________________________________________ >> 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 Oct 31 02:22:08 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7BCD1A86E7 for ; Fri, 31 Oct 2014 02:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, 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 NSxMi98v1fCx for ; Fri, 31 Oct 2014 02:22: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 DA2531A86E3 for ; Fri, 31 Oct 2014 02:22:03 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 35CF7773; Fri, 31 Oct 2014 10:22:02 +0100 (CET) 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 TOaqLci3RIxU; Fri, 31 Oct 2014 10:21:35 +0100 (CET) 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, 31 Oct 2014 10:22:01 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 663FE20038; Fri, 31 Oct 2014 10:22:01 +0100 (CET) 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 A-FqvfM2IukF; Fri, 31 Oct 2014 10:22:00 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 78AEC20035; Fri, 31 Oct 2014 10:22:00 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0C3322F3B913; Fri, 31 Oct 2014 10:21:58 +0100 (CET) Date: Fri, 31 Oct 2014 10:21:57 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20141031092156.GA1931@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , "netmod@ietf.org" References: <20141029150630.GA17776@elstar.local> <20141029233236.GA19176@elstar.local> <20141030.120159.198377535691531775.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/OkKg6gsiuGo1ibzA_431AyG0FH0 Cc: "netmod@ietf.org" Subject: Re: [netmod] yang 1.1 webex on wednesday october 29th 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, 31 Oct 2014 09:22:06 -0000 On Fri, Oct 31, 2014 at 10:16:25AM +0100, Ladislav Lhotka wrote: > > > > > I don't agree that the message scales are worse than retrieving the > > It does, because all information has to be packed as URI parameters. I don’t understand the design decision to use URI as the format for capabilities, it could have been a nicely structured XML snippet with content specific for each capability. > The format is not the issue; the issue is that the long is unavoidable - you get it whether you need it or not. With a separate well designed RPC, the client can request things as needed and it hopefully can cache things. I do not think a different encoding really makes a lot of a difference. I think the key is to send the information only when really needed rather than every time an application connects. /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 Oct 31 02:34:49 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E3A1A8715 for ; Fri, 31 Oct 2014 02:34:47 -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 IX711eJrLhM6 for ; Fri, 31 Oct 2014 02:34:45 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2E7C1A8703 for ; Fri, 31 Oct 2014 02:34:45 -0700 (PDT) Received: from [192.168.1.108] (unknown [195.113.220.254]) by mail.nic.cz (Postfix) with ESMTPSA id 41151141066; Fri, 31 Oct 2014 10:34:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1414748084; bh=r5+uAbfq3GpQDxI52fd+iK1dpiHu4PDHuAM6X2XrckE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=tE19jy1FaWtY8O6R1LTebvXN1bT/vzCB+5ryl+YgSguVQkbFQlqYHUsAbMrdU4bHe Jk4FA5nxDUIJHBbKKordDED7bRAdqj4r4zcLQ8d+hOqjSyjKncGuiekEOruChwrlS0 I3YM5XKeTxnX6O7SooW5qvKoxcfIZRTFWy1+gnO8= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <20141031092156.GA1931@elstar.local> Date: Fri, 31 Oct 2014 10:34:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141029150630.GA17776@elstar.local> <20141029233236.GA19176@elstar.local> <20141030.120159.198377535691531775.mbj@tail-f.com> <20141031092156.GA1931@elstar.local> To: =?windows-1252?Q?J=FCrgen_Sch=F6nw=E4lder?= X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/awxGV7owwEG0PptHQIr6RX-Jl4k Cc: "netmod@ietf.org" Subject: Re: [netmod] yang 1.1 webex on wednesday october 29th X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 31 Oct 2014 09:34:47 -0000 On 31 Oct 2014, at 10:21, Juergen Schoenwaelder = wrote: > On Fri, Oct 31, 2014 at 10:16:25AM +0100, Ladislav Lhotka wrote: >>=20 >>>=20 >>> I don't agree that the message scales are worse than = retrieving the >>=20 >> It does, because all information has to be packed as URI parameters. = I don=92t understand the design decision to use URI as the format for = capabilities, it could have been a nicely structured XML snippet with = content specific for each capability. >>=20 >=20 > The format is not the issue; the issue is that the long is > unavoidable - you get it whether you need it or not. With a separate > well designed RPC, the client can request things as needed and it > hopefully can cache things. >=20 > I do not think a different encoding really makes a lot of a > difference. I think the key is to send the information only when > really needed rather than every time an application connects. Right, but it is also true that URI parameters are not terribly suitable = for representing structured information. They are needed in Request-URIs = of HTTP methods but it not the case here. 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 Fri Oct 31 02:46:49 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C83CA1A1A2A for ; Fri, 31 Oct 2014 02:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, 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 blsCzzgg9KwN for ; Fri, 31 Oct 2014 02:46:46 -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 752D41A1AE9 for ; Fri, 31 Oct 2014 02:46: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 72CAA75C; Fri, 31 Oct 2014 10:46:44 +0100 (CET) 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 EWUFWEReJo0y; Fri, 31 Oct 2014 10:46:18 +0100 (CET) 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, 31 Oct 2014 10:46:43 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id B86302003B; Fri, 31 Oct 2014 10:46:43 +0100 (CET) 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 IgaNRqbuBdyh; Fri, 31 Oct 2014 10:46:43 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DCDFB20035; Fri, 31 Oct 2014 10:46:42 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D24082F3B9CC; Fri, 31 Oct 2014 10:46:41 +0100 (CET) Date: Fri, 31 Oct 2014 10:46:41 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20141031094641.GA2071@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , "netmod@ietf.org" References: <20141029150630.GA17776@elstar.local> <20141029233236.GA19176@elstar.local> <20141030.120159.198377535691531775.mbj@tail-f.com> <20141031092156.GA1931@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: http://mailarchive.ietf.org/arch/msg/netmod/-TKuCsh-Y1O7fI-EQlx50c2B4z0 Cc: "netmod@ietf.org" Subject: Re: [netmod] yang 1.1 webex on wednesday october 29th 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, 31 Oct 2014 09:46:48 -0000 On Fri, Oct 31, 2014 at 10:34:45AM +0100, Ladislav Lhotka wrote: > > Right, but it is also true that URI parameters are not terribly suitable for representing structured information. They are needed in Request-URIs of HTTP methods but it not the case here. > Lada, we are not re-designing the protocol here. If you want to do that, please post to the NETCONF mailing list. /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 Oct 31 02:53:57 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 210CF1A1A2A for ; Fri, 31 Oct 2014 02:53:55 -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 kVjrUnRDI_wE for ; Fri, 31 Oct 2014 02:53:52 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AFBF1A0354 for ; Fri, 31 Oct 2014 02:53:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24702; q=dns/txt; s=iport; t=1414749232; x=1415958832; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6d2AAKHSMJgLXOVkzDH/krMEsBBv864d5ZzSBATocMs=; b=Aa5EyRtr9W0+PPeAtx6GW9EQ9PdaIJaHsqfVabMgTOxKekU0zAasTaCl /JPptsovVELdbh6yQDTqGMWQ0/y44e37XObwSs1c51qK8X9npzbXXWTjf 0egjpr4Bg3JBpMQnZmzrB/HV/927kVOQpDDE6eUcqG/lpI/vStZR5EGki U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArgFAOhaU1StJV2a/2dsb2JhbABcgkhGVFgEgwK5eo4kgWcBC4Z3VAIcfxYBAQEBAX2EAgEBAQQBAQEgCkELEAIBBgIOAwQBAQEKHQMCAgIlCxQDAQUIAgQBDQUIiDkNmBWcX5RuAQEBAQEBAQEBAQEBAQEBAQEBAQEBF5BfFhcEBgGCdzaBHgWSFYRNiEc8hj6OHYN4bIFIgQMBAQE X-IronPort-AV: E=Sophos;i="5.07,293,1413244800"; d="scan'208,217";a="368109418" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 31 Oct 2014 09:53:51 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s9V9rpte031422 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 Oct 2014 09:53:51 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.231]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Fri, 31 Oct 2014 04:53:51 -0500 From: "Ambika Prasad Tripathy (ambtripa)" To: Qin Wu , Martin Bjorklund , "Eric Voit (evoit)" Thread-Topic: [netmod] YANG model containing both device and domain config Thread-Index: AQHP9NciSF8QziWu/kCXisv3L46wapxKGtSA//+uG9iAACes8A== Date: Fri, 31 Oct 2014 09:53:50 +0000 Message-ID: <3B675C3A8DF102408C754E30986E43CF05CE789B@xmb-aln-x08.cisco.com> References: <20141031.075132.208810580.mbj@tail-f.com>, <3B675C3A8DF102408C754E30986E43CF05CE77E9@xmb-aln-x08.cisco.com> In-Reply-To: <3B675C3A8DF102408C754E30986E43CF05CE77E9@xmb-aln-x08.cisco.com> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.100.66] Content-Type: multipart/alternative; boundary="_000_3B675C3A8DF102408C754E30986E43CF05CE789Bxmbalnx08ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ZK3eYKMKfll9fM_uZrASrVEResc Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG model containing both device and domain config X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 31 Oct 2014 09:53:55 -0000 --_000_3B675C3A8DF102408C754E30986E43CF05CE789Bxmbalnx08ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkFkZGluZyBtb3JlIGluZm8gaG93IG1vdW50IHdvcmtzOg0KDQpNb3VudCBicmluZ3Mg T25lIGF1dGhvcml0YXRpdmUgY29weSBvZiBhbiBvYmplY3QgYWNyb3NzIGEgTmV0d29yay4gSXQg aXMgcmVhZCBvbmx5IHRvIHRoZSBkYXRhIHN0b3JlIHRvIGdldCBhIHNuYXBzaG90IG9mIHRoZSBt b3VudGVkIGRhdGEgc3RvcmUgYmFzZWQgb24gbW91bnQgcG9saWNpZXMgZGVmaWVkIGluIGFub3Ro ZXIgSUVURiBkcmFmdCDigJxwZWVyLW1vdW50LXJlcXVpcmVtZW50czxodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC12b2l0LW5ldG1vZC1wZWVyLW1vdW50LXJlcXVpcmVtZW50cy0wMT7i gJ0NCg0KTW91bnQgaXMgbm90IGEgbWVjaGFuaXNtIHRvIGNvbmZpZ3VyZSBhIGRldmljZSBvciB3 cml0ZSB0byByZW1vdGUgZGF0YSBzdG9yZS4gIEZvciB0aGF0IGV4aXN0aW5nIGludGVyZmFjZXMg YXJlIGFscmVhZHkgdGhlcmUuDQoNCklmIGRldmljZXMgd2FudCB0byBnZXQgc29tZSBjb25maWd1 cmF0aW9uIGRhdGEgZnJvbSBhIG5hbWVzcGFjZSBvZiB0aGUgY29udHJvbGxlciBkYXRhIHN0b3Jl LCB0aGVuIGFwcGxpY2F0aW9ucyBydW5uaW5nIGluIHRoZSBkZXZpY2UgY2FuIG1vdW50IGl0IGZy b20gdGhlIGNvbnRyb2xsZXIgZGF0YXN0b3JlLg0KRm9yIGV4YW1wbGUsIGZvciB0aGUgcG9saWNl ciB5YW5nIG1vZGVsIGRlZmluZWQgaW4gZHJhZnQgZHJhZnQtdHJpcGF0aHktY2xvdWQtc2xhLXlh bmctbW9kZWwtMDAsIGFwcGxpY2F0aW9ucyBydW5uaW5nIGluIGRldmljZSB3aGljaCBpcyByZXNw b25zaWJsZSBvZiBwb2xpY2luZyBkYXRhIGZvciB0aGUgZG9tYWluIGluIHRoZSBkZXZpY2UsIGNh biBtb3VudCB0aGUg4oCcY29udGFpbmVyIHBvbGljaW5nLXBvbGljaWVz4oCdIHRvIGdldCBuZXcg cG9saWNlIHZhbHVlcyB3aGVuIHRoZXJlIGlzIGEgY2hhbmdlIGluIHBvbGljeSByYXRlIGJ5IGNs b3VkIGFwcGxpY2F0aW9uLg0KDQpCciwNCkFtYmlrYQ0KDQoNCkZyb206IG5ldG1vZCBbbWFpbHRv Om5ldG1vZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQW1iaWthIFByYXNhZCBUcmlw YXRoeSAoYW1idHJpcGEpDQpTZW50OiBGcmlkYXksIE9jdG9iZXIgMzEsIDIwMTQgMTI6MzcgUE0N ClRvOiBRaW4gV3U7IE1hcnRpbiBCam9ya2x1bmQ7IEVyaWMgVm9pdCAoZXZvaXQpDQpDYzogbmV0 bW9kQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW25ldG1vZF0gWUFORyBtb2RlbCBjb250YWluaW5n IGJvdGggZGV2aWNlIGFuZCBkb21haW4gY29uZmlnDQoNCkhpLA0KVGhpcyBtb3VudCBpcyBvbmx5 IGZvciByZWFkLiBOb3QgZm9yIHdyaXRlLg0KQnIsDQpBbWJpa2ENCg0KU2VudCBmcm9tIG15IFdp bmRvd3MgUGhvbmUNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBRaW4g V3U8bWFpbHRvOmJpbGwud3VAaHVhd2VpLmNvbT4NClNlbnQ6IOKAjjMxLeKAjjEwLeKAjjIwMTQg MTI6MzANClRvOiBNYXJ0aW4gQmpvcmtsdW5kPG1haWx0bzptYmpAdGFpbC1mLmNvbT47IEVyaWMg Vm9pdCAoZXZvaXQpPG1haWx0bzpldm9pdEBjaXNjby5jb20+DQpDYzogbmV0bW9kQGlldGYub3Jn PG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW25ldG1vZF0gWUFORyBtb2Rl bCBjb250YWluaW5nIGJvdGggZGV2aWNlIGFuZCBkb21haW4gY29uZmlnDQpZZXMsIEkgaGF2ZSBz YW1lIHF1ZXN0aW9uLg0KYnkgcmVhZGluZyBkcmFmdC10cmlwYXRoeS1jbG91ZC1zbGEteWFuZy1t b2RlbC0wMCwgSXQgc2VlbXMgdG8gbWUgaXQgb25seSBzdXBwb3J0cyByZWFkIG9iamVjdCBmcm9t IHJlbW90ZSBkYXRhc3RvcmUsIGJ1dCBkb2Vzbid0IHN1cHBvcnQgd3JpdGUgb2JqZWN0IGJhY2sg aW50byByZW1vdGUgZGF0YXN0b3JlLg0KDQpSZWdhcmRzIQ0KLVFpbg0KLS0tLS3pgq7ku7bljp/k u7YtLS0tLQ0K5Y+R5Lu25Lq6OiBuZXRtb2QgW21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9y Z10g5Luj6KGoIE1hcnRpbiBCam9ya2x1bmQNCuWPkemAgeaXtumXtDogMjAxNOW5tDEw5pyIMzHm l6UgMTQ6NTINCuaUtuS7tuS6ujogZXZvaXRAY2lzY28uY29tPG1haWx0bzpldm9pdEBjaXNjby5j b20+DQrmioTpgIE6IG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0K5Li7 6aKYOiBSZTogW25ldG1vZF0gWUFORyBtb2RlbCBjb250YWluaW5nIGJvdGggZGV2aWNlIGFuZCBk b21haW4gY29uZmlnDQoNCkhpLA0KDQoiRXJpYyBWb2l0IChldm9pdCkiIDxldm9pdEBjaXNjby5j b208bWFpbHRvOmV2b2l0QGNpc2NvLmNvbT4+IHdyb3RlOg0KPiBUaGUgT3BlbkRheWxpZ2h0IGNv bnRyb2xsZXIgaGFzIGFscmVhZHkNCj4gaW1wbGVtZW50ZWQ8aHR0cDovL3NkbnR1dG9yaWFscy5j b20vaG93LXRvLWFjY2Vzcy1kYXRhLWluLW1kLXNhbC1mcm9tLQ0KPGh0dHA6Ly9zZG50dXRvcmlh bHMuY29tL2hvdy10by1hY2Nlc3MtZGF0YS1pbi1tZC1zYWwtZnJvbS0lMGI+PiBtb3VudC1wb2lu dC8+IE1vdW50IGFzIG9uZSBvZiBpdHMgbW9zdCBlc3NlbnRpYWwgYmFzaWMgZnVuY3Rpb25zLiAg SWYNCj4gaXQgd2Fzbid0IGltcG9ydGFudCwgaXQgd291bGRuJ3QgaGF2ZSBiZWVuIGRvbmUuDQo+ DQo+DQo+DQo+IFRoZSBxdWVzdGlvbiBpcyBub3Qgd2hldGhlciBZYW5nIE1vdW50IGlzIGdvaW5n IHRvIGhhcHBlbi4gIEl0IGlzDQo+IHdoZXRoZXIgdGhlIElFVEYgd2FudHMgdG8gYmUgaW52b2x2 ZWQuDQoNCkEgY2xhcmlmaWNhdGlvbiBxdWVzdGlvbjogYXJlIHdlIHRhbGtpbmcgYWJvdXQgcmVh ZC1vbmx5IG1vdW50aW5nIG9yIHJlYWQtd3JpdGU/DQoNCkFzIEkgaGF2ZSB3cml0dGVuIGJlZm9y ZSwgSSBiZWxpZXZlIHRoZSBtZWNoYW5pc20gcHJvcG9zZWQgZG9lc24ndCByZWFsbHkgd29yayBm b3IgcmVhZC13cml0ZSBhY2Nlc3MuDQoNCg0KDQovbWFydGluDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRt b2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3JnPG1h aWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL25ldG1vZA0K --_000_3B675C3A8DF102408C754E30986E43CF05CE789Bxmbalnx08ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAy IDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlBNaW5nTGlVOw0K CXBhbm9zZS0xOjIgMiA1IDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpQTWluZ0xpVTsNCglwYW5vc2UtMToyIDIgNSAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAz IDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFBNaW5nTGlVIjsNCglw YW5vc2UtMToyIDIgNSAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IlxATVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0O30NCi8qIFN0eWxl IERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFs DQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcC5Nc29BY2V0YXRlLCBs aS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9t YSIsInNhbnMtc2VyaWYiO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFw aCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdp bi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFy Z2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuZW1haWxxdW90 ZSwgbGkuZW1haWxxdW90ZSwgZGl2LmVtYWlscXVvdGUNCgl7bXNvLXN0eWxlLW5hbWU6ZW1haWxx dW90ZTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjEuMHB0Ow0KCWJvcmRlcjpu b25lOw0KCXBhZGRpbmc6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5 bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0 OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGlu Ow0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJ e21zby1saXN0LWlkOjE3NTQ1NDc1Nzc7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxp c3QtdGVtcGxhdGUtaWRzOi04MjM0OTYyOTQgMTI1OTM0Mzk1NiA2NzY5ODY5MSA2NzY5ODY5MyA2 NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpA bGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0 LWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3Qg bDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFk ZGluZyBtb3JlIGluZm8gaG93IG1vdW50IHdvcmtzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TW91bnQgYnJpbmdzIE9u ZSBhdXRob3JpdGF0aXZlIGNvcHkgb2YgYW4gb2JqZWN0IGFjcm9zcyBhIE5ldHdvcmsuIEl0IGlz IHJlYWQgb25seSB0byB0aGUgZGF0YSBzdG9yZSB0byBnZXQgYSBzbmFwc2hvdCBvZiB0aGUgbW91 bnRlZCBkYXRhIHN0b3JlIGJhc2VkIG9uIG1vdW50DQogcG9saWNpZXMgZGVmaWVkIGluIGFub3Ro ZXIgSUVURiBkcmFmdCDigJw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXZvaXQtbmV0bW9kLXBlZXItbW91bnQtcmVxdWlyZW1lbnRzLTAxIj5w ZWVyLW1vdW50LXJlcXVpcmVtZW50czwvYT48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TW91bnQgaXMgbm90IGEgbWVjaGFuaXNt IHRvIGNvbmZpZ3VyZSBhIGRldmljZSBvciB3cml0ZSB0byByZW1vdGUgZGF0YSBzdG9yZS4gJm5i c3A7Rm9yIHRoYXQgZXhpc3RpbmcgaW50ZXJmYWNlcyBhcmUgYWxyZWFkeSB0aGVyZS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPklmIGRldmljZXMgd2FudCB0byBnZXQgc29tZSBjb25maWd1cmF0aW9uIGRhdGEgZnJvbSBh IG5hbWVzcGFjZSBvZiB0aGUgY29udHJvbGxlciBkYXRhIHN0b3JlLCB0aGVuIGFwcGxpY2F0aW9u cyBydW5uaW5nIGluIHRoZSBkZXZpY2UgY2FuIG1vdW50IGl0IGZyb20gdGhlDQogY29udHJvbGxl ciBkYXRhc3RvcmUuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Gb3IgZXhhbXBsZSwg Zm9yIHRoZSBwb2xpY2VyIHlhbmcgbW9kZWwgZGVmaW5lZCBpbiBkcmFmdCBkcmFmdC10cmlwYXRo eS1jbG91ZC1zbGEteWFuZy1tb2RlbC0wMCwgYXBwbGljYXRpb25zIHJ1bm5pbmcgaW4gZGV2aWNl IHdoaWNoIGlzIHJlc3BvbnNpYmxlIG9mIHBvbGljaW5nDQogZGF0YSBmb3IgdGhlIGRvbWFpbiBp biB0aGUgZGV2aWNlLCBjYW4gbW91bnQgdGhlIOKAnGNvbnRhaW5lciBwb2xpY2luZy1wb2xpY2ll c+KAnSB0byBnZXQgbmV3IHBvbGljZSB2YWx1ZXMgd2hlbiB0aGVyZSBpcyBhIGNoYW5nZSBpbiBw b2xpY3kgcmF0ZSBieSBjbG91ZCBhcHBsaWNhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJyLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5BbWJpa2E8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gbmV0bW9kIFttYWlsdG86bmV0bW9kLWJvdW5jZXNA aWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFtYmlrYSBQcmFzYWQgVHJpcGF0aHkgKGFt YnRyaXBhKTxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIE9jdG9iZXIgMzEsIDIwMTQgMTI6Mzcg UE08YnI+DQo8Yj5Ubzo8L2I+IFFpbiBXdTsgTWFydGluIEJqb3JrbHVuZDsgRXJpYyBWb2l0IChl dm9pdCk8YnI+DQo8Yj5DYzo8L2I+IG5ldG1vZEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW25ldG1vZF0gWUFORyBtb2RlbCBjb250YWluaW5nIGJvdGggZGV2aWNlIGFuZCBkb21h aW4gY29uZmlnPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5IaSw8YnI+ DQpUaGlzIG1vdW50IGlzIG9ubHkgZm9yIHJlYWQuIE5vdCBmb3Igd3JpdGUuIDxicj4NCkJyLDxi cj4NCkFtYmlrYSA8YnI+DQo8YnI+DQpTZW50IGZyb20gbXkgV2luZG93cyBQaG9uZTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9y bWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhyIHNpemU9 IjMiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ PGEgaHJlZj0ibWFpbHRvOmJpbGwud3VAaHVhd2VpLmNvbSI+UWluIFd1PC9hPjwvc3Bhbj48YnI+ DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlNlbnQ6IDwvc3Bhbj4NCjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPuKAjjMxLeKAjjEwLeKAjjIwMTQgMTI6MzA8L3NwYW4+ PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UbzogPC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9Im1haWx0bzptYmpAdGFpbC1mLmNvbSI+ TWFydGluIEJqb3JrbHVuZDwvYT47DQo8YSBocmVmPSJtYWlsdG86ZXZvaXRAY2lzY28uY29tIj5F cmljIFZvaXQgKGV2b2l0KTwvYT48L3NwYW4+PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5DYzogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhy ZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT48L3NwYW4+PGJy Pg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TdWJqZWN0OiA8L3NwYW4+DQo8L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5SZTogW25ldG1vZF0gWUFORyBtb2RlbCBjb250 YWluaW5nIGJvdGggZGV2aWNlIGFuZCBkb21haW4gY29uZmlnPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdCI+WWVzLCBJIGhhdmUgc2FtZSBxdWVzdGlvbi48YnI+DQpieSBy ZWFkaW5nIGRyYWZ0LXRyaXBhdGh5LWNsb3VkLXNsYS15YW5nLW1vZGVsLTAwLCBJdCBzZWVtcyB0 byBtZSBpdCBvbmx5IHN1cHBvcnRzIHJlYWQgb2JqZWN0IGZyb20gcmVtb3RlIGRhdGFzdG9yZSwg YnV0IGRvZXNuJ3Qgc3VwcG9ydCB3cml0ZSBvYmplY3QgYmFjayBpbnRvIHJlbW90ZSBkYXRhc3Rv cmUuPGJyPg0KPGJyPg0KUmVnYXJkcyE8YnI+DQotUWluPGJyPg0KLS0tLS08L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7UE1pbmdMaVUmcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDsiPumCruS7tuWOn+S7tjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdCI+LS0tLS08YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7UE1pbmdMaVUmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPuWP keS7tuS6ujwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+OiBuZXRtb2QgWzxh IGhyZWY9Im1haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOm5ldG1vZC1ib3Vu Y2VzQGlldGYub3JnPC9hPl0NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtNUyBNaW5jaG8mcXVvdDsiPuS7o+ihqDwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdCI+IE1hcnRpbiBCam9ya2x1bmQ8YnI+DQo8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7UE1pbmdMaVUmcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDsiPuWPkemAgeaXtumXtDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdCI+OiAyMDE0PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O01TIE1pbmNobyZxdW90OyI+5bm0PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0Ij4xMDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtNUyBNaW5jaG8mcXVvdDsiPuaciDwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdCI+MzE8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7TVMgTWluY2hvJnF1b3Q7Ij7ml6U8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQiPg0KIDE0OjUyPGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01TIE1pbmNobyZxdW90OyI+5pS25Lu25Lq6 PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij46DQo8YSBocmVmPSJtYWlsdG86 ZXZvaXRAY2lzY28uY29tIj5ldm9pdEBjaXNjby5jb208L2E+PGJyPg0KPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01TIE1pbmNobyZxdW90OyI+ 5oqE6YCBPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij46DQo8YSBocmVmPSJt YWlsdG86bmV0bW9kQGlldGYub3JnIj5uZXRtb2RAaWV0Zi5vcmc8L2E+PGJyPg0KPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01TIE1pbmNobyZx dW90OyI+5Li7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1BNaW5nTGlVJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij7popg8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjogUmU6IFtuZXRtb2RdIFlBTkcgbW9kZWwgY29udGFp bmluZyBib3RoIGRldmljZSBhbmQgZG9tYWluIGNvbmZpZzxicj4NCjxicj4NCkhpLDxicj4NCjxi cj4NCiZxdW90O0VyaWMgVm9pdCAoZXZvaXQpJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86ZXZv aXRAY2lzY28uY29tIj5ldm9pdEBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7IFRo ZSBPcGVuRGF5bGlnaHQgY29udHJvbGxlciBoYXMgYWxyZWFkeSA8YnI+DQomZ3Q7IGltcGxlbWVu dGVkJmx0OzxhIGhyZWY9Imh0dHA6Ly9zZG50dXRvcmlhbHMuY29tL2hvdy10by1hY2Nlc3MtZGF0 YS1pbi1tZC1zYWwtZnJvbS0lMGIiPmh0dHA6Ly9zZG50dXRvcmlhbHMuY29tL2hvdy10by1hY2Nl c3MtZGF0YS1pbi1tZC1zYWwtZnJvbS08YnI+DQo8L2E+Jmd0OyBtb3VudC1wb2ludC8mZ3Q7IE1v dW50IGFzIG9uZSBvZiBpdHMgbW9zdCBlc3NlbnRpYWwgYmFzaWMgZnVuY3Rpb25zLiZuYnNwOyBJ ZiA8YnI+DQomZ3Q7IGl0IHdhc24ndCBpbXBvcnRhbnQsIGl0IHdvdWxkbid0IGhhdmUgYmVlbiBk b25lLjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhlIHF1ZXN0 aW9uIGlzIG5vdCB3aGV0aGVyIFlhbmcgTW91bnQgaXMgZ29pbmcgdG8gaGFwcGVuLiZuYnNwOyBJ dCBpcyA8YnI+DQomZ3Q7IHdoZXRoZXIgdGhlIElFVEYgd2FudHMgdG8gYmUgaW52b2x2ZWQuPGJy Pg0KPGJyPg0KQSBjbGFyaWZpY2F0aW9uIHF1ZXN0aW9uOiBhcmUgd2UgdGFsa2luZyBhYm91dCBy ZWFkLW9ubHkgbW91bnRpbmcgb3IgcmVhZC13cml0ZT88YnI+DQo8YnI+DQpBcyBJIGhhdmUgd3Jp dHRlbiBiZWZvcmUsIEkgYmVsaWV2ZSB0aGUgbWVjaGFuaXNtIHByb3Bvc2VkIGRvZXNuJ3QgcmVh bGx5IHdvcmsgZm9yIHJlYWQtd3JpdGUgYWNjZXNzLjxicj4NCjxicj4NCjxicj4NCjxicj4NCi9t YXJ0aW48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCm5ldG1vZCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bmV0 bW9kQGlldGYub3JnIj5uZXRtb2RAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbmV0bW9kPC9hPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbmV0bW9kIG1haWxpbmcgbGlzdDxicj4NCjxh IGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT48YnI+DQo8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZCI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8L2E+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_3B675C3A8DF102408C754E30986E43CF05CE789Bxmbalnx08ciscoc_-- From nobody Fri Oct 31 03:04:41 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9474B1A1AE9 for ; Fri, 31 Oct 2014 03:04:39 -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 s4kRt46LaV-U for ; Fri, 31 Oct 2014 03:04:37 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B12621A1AA4 for ; Fri, 31 Oct 2014 03:04:37 -0700 (PDT) Received: from [192.168.1.108] (unknown [195.113.220.254]) by mail.nic.cz (Postfix) with ESMTPSA id 397CE140AC5; Fri, 31 Oct 2014 11:04:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1414749876; bh=+ewO1KcdpMgVjT96NQlVOWqHtn9+NuRIpEXGff+6NsQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=vjsxHt+2xNEyyrUexP+TBYb+MV29XjXr3NetXz1GZsOeq0qShIODyMyAfLd843r3F 9BWPx97TSeQY7pNRdz1P/FsMwctPzhrUnlR5DADX89nj3+hBb4yA+qZxD3ug3mbQ/0 39XsraK3fZR+LCH06D/ewK3ODl/1h2bJbbYRAfuU= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <20141031094641.GA2071@elstar.local> Date: Fri, 31 Oct 2014 11:04:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141029150630.GA17776@elstar.local> <20141029233236.GA19176@elstar.local> <20141030.120159.198377535691531775.mbj@tail-f.com> <20141031092156.GA1931@elstar.local> <20141031094641.GA2071@elstar.local> To: =?windows-1252?Q?J=FCrgen_Sch=F6nw=E4lder?= X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/PFOuY3JJ4H5AW2XbUo1otgp8GC8 Cc: "netmod@ietf.org" Subject: Re: [netmod] yang 1.1 webex on wednesday october 29th X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 31 Oct 2014 10:04:39 -0000 On 31 Oct 2014, at 10:46, Juergen Schoenwaelder = wrote: > On Fri, Oct 31, 2014 at 10:34:45AM +0100, Ladislav Lhotka wrote: >>=20 >> Right, but it is also true that URI parameters are not terribly = suitable for representing structured information. They are needed in = Request-URIs of HTTP methods but it not the case here. >>=20 >=20 > Lada, we are not re-designing the protocol here. If you want to do > that, please post to the NETCONF mailing list. I just replied to Andy=92s claim that hello capabilities are as scalable = as retrieving the same information via . Thank you, 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 Fri Oct 31 03:10:57 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DEF81A19E2 for ; Fri, 31 Oct 2014 03:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, 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 Xp5lU0qEx3hC for ; Fri, 31 Oct 2014 03:10: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 5EA011A0073 for ; Fri, 31 Oct 2014 03:10: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 2EAD5E4F; Fri, 31 Oct 2014 11:10:51 +0100 (CET) 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 1VtmKtiSInEZ; Fri, 31 Oct 2014 11:10:24 +0100 (CET) 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, 31 Oct 2014 11:10:50 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 294C720038; Fri, 31 Oct 2014 11:10:50 +0100 (CET) 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 PEKYeDwWTqM4; Fri, 31 Oct 2014 11:10:49 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D227520035; Fri, 31 Oct 2014 11:10:48 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id CDF812F3BA89; Fri, 31 Oct 2014 11:10:47 +0100 (CET) Date: Fri, 31 Oct 2014 11:10:47 +0100 From: Juergen Schoenwaelder To: "Ambika Prasad Tripathy (ambtripa)" Message-ID: <20141031101045.GA2139@elstar.local> Mail-Followup-To: "Ambika Prasad Tripathy (ambtripa)" , Qin Wu , Martin Bjorklund , "Eric Voit (evoit)" , "netmod@ietf.org" References: <3B675C3A8DF102408C754E30986E43CF05CE77E9@xmb-aln-x08.cisco.com> <3B675C3A8DF102408C754E30986E43CF05CE789B@xmb-aln-x08.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3B675C3A8DF102408C754E30986E43CF05CE789B@xmb-aln-x08.cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/JSohavIjpYp6UWK3au4RcmiGXBw Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG model containing both device and domain config 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, 31 Oct 2014 10:10:54 -0000 On Fri, Oct 31, 2014 at 09:53:50AM +0000, Ambika Prasad Tripathy (ambtripa) wrote: > Hi, > > Adding more info how mount works: > > Mount brings One authoritative copy of an object across a Network. It is read only to the data store to get a snapshot of the mounted data store based on mount policies defied in another IETF draft “peer-mount-requirements” > > Mount is not a mechanism to configure a device or write to remote data store. For that existing interfaces are already there. > Well, there are also existing interfaces to read config and state data. ;-) > If devices want to get some configuration data from a namespace of the controller data store, then applications running in the device can mount it from the controller datastore. > For example, for the policer yang model defined in draft draft-tripathy-cloud-sla-yang-model-00, applications running in device which is responsible of policing data for the domain in the device, can mount the “container policing-policies” to get new police values when there is a change in policy rate by cloud application. > This use case I find actually more interesting but then I am not sure I understand how this works or whether a plain mount is the way to do this. If a device mounts some policy information, does this mean the device commits to follow the policy information, that is to change the operational state according to the policy? If so, how are conflicts resolved? What is the lifetime of the injected config state? Is it ephemeral? Is it bound to the mount? How does this relate to I2RS? They intend to push configuration while you seem to let the device pull some configuration from a controller. Will both internally be treated the same way? I believe it is worth looking into the use case where a device wants to pull configuration from a 'controller' instead of having the 'controller' to push the configuration. Whether mount is the right solution for this, I can't tell at this point in time. /js (speaking as contributor) -- 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 Oct 31 03:33:54 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 969BB1A0A6B for ; Fri, 31 Oct 2014 03:33: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 14k4OvXLEs4B for ; Fri, 31 Oct 2014 03:33:50 -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 3BFAF1A00AB for ; Fri, 31 Oct 2014 03:33:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4702; q=dns/txt; s=iport; t=1414751631; x=1415961231; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=QBDNQZVR4vqJMVfJfV1WnTo9CjnrJa5g2YEv+IbGsQQ=; b=giunP+LHhKL5TIhTs3z7/Sul4MxcpmGC59+D3X/zWdvB5HHwWyIAJiRB dsY8hbPUk2BM72Tgb0EqPwKT1o8nWuqCLPvmJNZ/uj8KImoHEiVvuJzRT GFW+cGw778DcdWuuWeo+38ucrq/WP4nSmSoEWL8Bl8n9piOudoOYTOM32 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwFADxkU1StJV2b/2dsb2JhbABZA4MOVFgEgwLKEodLAhx/FgEBAQEBfYQCAQEBAwEjEUUFBwICAgEIDgIBBAEBAQICBh0DAgICGRcUAQgIAgQOBQgTiB0JDbRvlGwBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBIEpjzIWCxAHBguCZjaBHgWSFYRNiEc8hj6OHYN4bIFIgQMBAQE X-IronPort-AV: E=Sophos;i="5.07,294,1413244800"; d="scan'208";a="368151044" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 31 Oct 2014 10:33:50 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s9VAXnFM014455 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 Oct 2014 10:33:49 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.231]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Fri, 31 Oct 2014 05:33:49 -0500 From: "Ambika Prasad Tripathy (ambtripa)" To: Juergen Schoenwaelder Thread-Topic: [netmod] YANG model containing both device and domain config Thread-Index: AQHP9NciSF8QziWu/kCXisv3L46wapxKGtSA//+uG9iAACes8IAAX2mA//+tEJA= Date: Fri, 31 Oct 2014 10:33:48 +0000 Message-ID: <3B675C3A8DF102408C754E30986E43CF05CE78D5@xmb-aln-x08.cisco.com> References: <3B675C3A8DF102408C754E30986E43CF05CE77E9@xmb-aln-x08.cisco.com> <3B675C3A8DF102408C754E30986E43CF05CE789B@xmb-aln-x08.cisco.com> <20141031101045.GA2139@elstar.local> In-Reply-To: <20141031101045.GA2139@elstar.local> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.100.66] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/98CDHv9v7RWZwmiLKOxyuKI5-FI Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG model containing both device and domain config X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 31 Oct 2014 10:33:52 -0000 SGkgLA0KDQpZZXMuIFRoZXJlIGFyZSBvdGhlciBtZWNoYW5pc20gdG8gcHVsbCB0aGUgZGF0YSBm cm9tIGRldmljZSB3aGVuIHJlcXVpcmVkIGJ5IGNvbnRyb2xsZXIgYmFzZWQgYXBwbGljYXRpb24s IGJ1dCBtb3VudCBpcyBtb3JlIHRoYW4gdGhhdC4gVGhlIGV4aXN0aW5nIHB1bGxpbmcgbWVjaGFu aXNtIGlzIGp1c3Qgb25lIHBhcnQgb2Ygd2hhdCBtb3VudCBkZXNjcmliZXMgYXJlIG9uLWRlbWFu ZCBtb3VudCBwb2xpY3kuIFRoZSBleGlzdGluZyBwdWxsaW5nIG1lY2hhbmlzbSBpcyBub3QgcHJv dmlkaW5nIGV2ZW50dWFsbHkgY29uc2lzdGVuY3kgYWNyb3NzIHRoZSBuZXR3b3JrIHdoaWNoIGlz IG5lZWQgYnkgdGhlIERvbWFpbiBwb2xpY2VyIGFwcGxpY2F0aW9uIGRlc2NyaWVkIGluIGRyYWZ0 LiBGb3IgdGhhdCBtb3VudCBpcyBhIGJldHRlciB3YXkuDQoNCldoZW4gYXBwbGljYXRpb24gbW91 bnQncyBhbnkgb2JqZWN0IHRvIHJlbW90ZSBkYXRhIHN0b3JlLCBpdCBpcyB1cCB0byB0aGUgYXBw bGljYXRpb24gaG93IHRvIHVzZSB0aGUgb2JqZWN0cy4gTW91bnQgaXMgbm90IGVuZm9yY2luZyB0 byB1c2UgdGhvc2Ugb2JqZWN0cyBieSB0aGUgYXBwbGljYXRpb24gbm9yIGl0IG5vdCBvdmVycmlk aW5nIGFueSBwb2xpY3kgb2YgdGhlIGFwcGxpY2F0aW9uIHdoaWNoIGlzIG1vdW50aW5nLiBUaGUg YXBwbGljYXRpb24gd2hvIG93biB0aGUgYXV0aG9yaXRhdGl2ZSBjb3B5IG9mIG9iamVjdCwgdGhl eSBzaG91bGQgZGVjaWRlIG9uIGhvdyB0byB1c2UgaXQuDQoNCkJyLA0KQW1iaWthDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgW21haWx0 bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGVdIA0KU2VudDogRnJpZGF5LCBP Y3RvYmVyIDMxLCAyMDE0IDM6NDEgUE0NClRvOiBBbWJpa2EgUHJhc2FkIFRyaXBhdGh5IChhbWJ0 cmlwYSkNCkNjOiBRaW4gV3U7IE1hcnRpbiBCam9ya2x1bmQ7IEVyaWMgVm9pdCAoZXZvaXQpOyBu ZXRtb2RAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbmV0bW9kXSBZQU5HIG1vZGVsIGNvbnRhaW5p bmcgYm90aCBkZXZpY2UgYW5kIGRvbWFpbiBjb25maWcNCg0KT24gRnJpLCBPY3QgMzEsIDIwMTQg YXQgMDk6NTM6NTBBTSArMDAwMCwgQW1iaWthIFByYXNhZCBUcmlwYXRoeSAoYW1idHJpcGEpIHdy b3RlOg0KPiBIaSwNCj4gDQo+IEFkZGluZyBtb3JlIGluZm8gaG93IG1vdW50IHdvcmtzOg0KPiAN Cj4gTW91bnQgYnJpbmdzIE9uZSBhdXRob3JpdGF0aXZlIGNvcHkgb2YgYW4gb2JqZWN0IGFjcm9z cyBhIE5ldHdvcmsuIEl0IGlzIHJlYWQgb25seSB0byB0aGUgZGF0YSBzdG9yZSB0byBnZXQgYSBz bmFwc2hvdCBvZiB0aGUgbW91bnRlZCBkYXRhIHN0b3JlIGJhc2VkIG9uIG1vdW50IHBvbGljaWVz IGRlZmllZCBpbiBhbm90aGVyIElFVEYgZHJhZnQg4oCccGVlci1tb3VudC1yZXF1aXJlbWVudHM8 aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdm9pdC1uZXRtb2QtcGVlci1tb3VudC1y ZXF1aXJlbWVudHMtMDE+4oCdDQo+IA0KPiBNb3VudCBpcyBub3QgYSBtZWNoYW5pc20gdG8gY29u ZmlndXJlIGEgZGV2aWNlIG9yIHdyaXRlIHRvIHJlbW90ZSBkYXRhIHN0b3JlLiAgRm9yIHRoYXQg ZXhpc3RpbmcgaW50ZXJmYWNlcyBhcmUgYWxyZWFkeSB0aGVyZS4NCj4NCg0KV2VsbCwgdGhlcmUg YXJlIGFsc28gZXhpc3RpbmcgaW50ZXJmYWNlcyB0byByZWFkIGNvbmZpZyBhbmQgc3RhdGUgZGF0 YS4gOy0pDQoNCj4gSWYgZGV2aWNlcyB3YW50IHRvIGdldCBzb21lIGNvbmZpZ3VyYXRpb24gZGF0 YSBmcm9tIGEgbmFtZXNwYWNlIG9mIHRoZSBjb250cm9sbGVyIGRhdGEgc3RvcmUsIHRoZW4gYXBw bGljYXRpb25zIHJ1bm5pbmcgaW4gdGhlIGRldmljZSBjYW4gbW91bnQgaXQgZnJvbSB0aGUgY29u dHJvbGxlciBkYXRhc3RvcmUuDQo+IEZvciBleGFtcGxlLCBmb3IgdGhlIHBvbGljZXIgeWFuZyBt b2RlbCBkZWZpbmVkIGluIGRyYWZ0IGRyYWZ0LXRyaXBhdGh5LWNsb3VkLXNsYS15YW5nLW1vZGVs LTAwLCBhcHBsaWNhdGlvbnMgcnVubmluZyBpbiBkZXZpY2Ugd2hpY2ggaXMgcmVzcG9uc2libGUg b2YgcG9saWNpbmcgZGF0YSBmb3IgdGhlIGRvbWFpbiBpbiB0aGUgZGV2aWNlLCBjYW4gbW91bnQg dGhlIOKAnGNvbnRhaW5lciBwb2xpY2luZy1wb2xpY2llc+KAnSB0byBnZXQgbmV3IHBvbGljZSB2 YWx1ZXMgd2hlbiB0aGVyZSBpcyBhIGNoYW5nZSBpbiBwb2xpY3kgcmF0ZSBieSBjbG91ZCBhcHBs aWNhdGlvbi4NCj4NCg0KVGhpcyB1c2UgY2FzZSBJIGZpbmQgYWN0dWFsbHkgbW9yZSBpbnRlcmVz dGluZyBidXQgdGhlbiBJIGFtIG5vdCBzdXJlIEkgdW5kZXJzdGFuZCBob3cgdGhpcyB3b3JrcyBv ciB3aGV0aGVyIGEgcGxhaW4gbW91bnQgaXMgdGhlIHdheSB0byBkbyB0aGlzLiBJZiBhIGRldmlj ZSBtb3VudHMgc29tZSBwb2xpY3kgaW5mb3JtYXRpb24sIGRvZXMgdGhpcyBtZWFuIHRoZSBkZXZp Y2UgY29tbWl0cyB0byBmb2xsb3cgdGhlIHBvbGljeSBpbmZvcm1hdGlvbiwgdGhhdCBpcyB0byBj aGFuZ2UgdGhlIG9wZXJhdGlvbmFsIHN0YXRlIGFjY29yZGluZyB0byB0aGUgcG9saWN5PyBJZiBz bywgaG93IGFyZSBjb25mbGljdHMgcmVzb2x2ZWQ/IFdoYXQgaXMgdGhlIGxpZmV0aW1lIG9mIHRo ZSBpbmplY3RlZCBjb25maWcgc3RhdGU/IElzIGl0IGVwaGVtZXJhbD8gSXMgaXQgYm91bmQgdG8g dGhlIG1vdW50PyBIb3cgZG9lcyB0aGlzIHJlbGF0ZSB0byBJMlJTPw0KVGhleSBpbnRlbmQgdG8g cHVzaCBjb25maWd1cmF0aW9uIHdoaWxlIHlvdSBzZWVtIHRvIGxldCB0aGUgZGV2aWNlIHB1bGwg c29tZSBjb25maWd1cmF0aW9uIGZyb20gYSBjb250cm9sbGVyLiBXaWxsIGJvdGggaW50ZXJuYWxs eSBiZSB0cmVhdGVkIHRoZSBzYW1lIHdheT8NCg0KSSBiZWxpZXZlIGl0IGlzIHdvcnRoIGxvb2tp bmcgaW50byB0aGUgdXNlIGNhc2Ugd2hlcmUgYSBkZXZpY2Ugd2FudHMgdG8gcHVsbCBjb25maWd1 cmF0aW9uIGZyb20gYSAnY29udHJvbGxlcicgaW5zdGVhZCBvZiBoYXZpbmcgdGhlICdjb250cm9s bGVyJyB0byBwdXNoIHRoZSBjb25maWd1cmF0aW9uLiBXaGV0aGVyIG1vdW50IGlzIHRoZSByaWdo dCBzb2x1dGlvbiBmb3IgdGhpcywgSSBjYW4ndCB0ZWxsIGF0IHRoaXMgcG9pbnQgaW4gdGltZS4N Cg0KL2pzIChzcGVha2luZyBhcyBjb250cmlidXRvcikNCg0KLS0gDQpKdWVyZ2VuIFNjaG9lbndh ZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KUGhvbmU6ICs0 OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxLCAyODc1OSBCcmVtZW4sIEdlcm1h bnkNCkZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHA6Ly93d3cuamFjb2JzLXVu aXZlcnNpdHkuZGUvPg0K From nobody Fri Oct 31 05:09:44 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1EB11A8A25 for ; Fri, 31 Oct 2014 05:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, 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 0bIfTAR_dC3e for ; Fri, 31 Oct 2014 05:09:38 -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 B764C1A8A46 for ; Fri, 31 Oct 2014 05:09: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 890338F9; Fri, 31 Oct 2014 13:09:36 +0100 (CET) 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 SYtBU2cdi5rW; Fri, 31 Oct 2014 13:09:09 +0100 (CET) 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, 31 Oct 2014 13:09:35 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 63FEF20038; Fri, 31 Oct 2014 13:09:35 +0100 (CET) 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 217p1kQxKT0w; Fri, 31 Oct 2014 13:09:34 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9AC8220035; Fri, 31 Oct 2014 13:09:33 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id EED3E2F3BDCC; Fri, 31 Oct 2014 13:09:31 +0100 (CET) Date: Fri, 31 Oct 2014 13:09:30 +0100 From: Juergen Schoenwaelder To: "Ambika Prasad Tripathy (ambtripa)" Message-ID: <20141031120930.GA2576@elstar.local> Mail-Followup-To: "Ambika Prasad Tripathy (ambtripa)" , Qin Wu , Martin Bjorklund , "Eric Voit (evoit)" , "netmod@ietf.org" References: <3B675C3A8DF102408C754E30986E43CF05CE77E9@xmb-aln-x08.cisco.com> <3B675C3A8DF102408C754E30986E43CF05CE789B@xmb-aln-x08.cisco.com> <20141031101045.GA2139@elstar.local> <3B675C3A8DF102408C754E30986E43CF05CE78D5@xmb-aln-x08.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3B675C3A8DF102408C754E30986E43CF05CE78D5@xmb-aln-x08.cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/xVay3u1vK3r-LFzCDBUaj39aBzc Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG model containing both device and domain config 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, 31 Oct 2014 12:09:40 -0000 Hi, I think we need to separate the discussion clearly between: a) a controller mounting read-only data from a set of NC servers b) a NC server mounting data from a set of controllers For me, these are very different things. I can't parse your answer because I do not know when you talk about a) and when about b) and because of that I do not know what 'application' is or why eventual consistency is important. /js On Fri, Oct 31, 2014 at 10:33:48AM +0000, Ambika Prasad Tripathy (ambtripa) wrote: > Hi , > > Yes. There are other mechanism to pull the data from device when required by controller based application, but mount is more than that. The existing pulling mechanism is just one part of what mount describes are on-demand mount policy. The existing pulling mechanism is not providing eventually consistency across the network which is need by the Domain policer application descried in draft. For that mount is a better way. > > When application mount's any object to remote data store, it is up to the application how to use the objects. Mount is not enforcing to use those objects by the application nor it not overriding any policy of the application which is mounting. The application who own the authoritative copy of object, they should decide on how to use it. > > Br, > Ambika > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Friday, October 31, 2014 3:41 PM > To: Ambika Prasad Tripathy (ambtripa) > Cc: Qin Wu; Martin Bjorklund; Eric Voit (evoit); netmod@ietf.org > Subject: Re: [netmod] YANG model containing both device and domain config > > On Fri, Oct 31, 2014 at 09:53:50AM +0000, Ambika Prasad Tripathy (ambtripa) wrote: > > Hi, > > > > Adding more info how mount works: > > > > Mount brings One authoritative copy of an object across a Network. It is read only to the data store to get a snapshot of the mounted data store based on mount policies defied in another IETF draft “peer-mount-requirements” > > > > Mount is not a mechanism to configure a device or write to remote data store. For that existing interfaces are already there. > > > > Well, there are also existing interfaces to read config and state data. ;-) > > > If devices want to get some configuration data from a namespace of the controller data store, then applications running in the device can mount it from the controller datastore. > > For example, for the policer yang model defined in draft draft-tripathy-cloud-sla-yang-model-00, applications running in device which is responsible of policing data for the domain in the device, can mount the “container policing-policies” to get new police values when there is a change in policy rate by cloud application. > > > > This use case I find actually more interesting but then I am not sure I understand how this works or whether a plain mount is the way to do this. If a device mounts some policy information, does this mean the device commits to follow the policy information, that is to change the operational state according to the policy? If so, how are conflicts resolved? What is the lifetime of the injected config state? Is it ephemeral? Is it bound to the mount? How does this relate to I2RS? > They intend to push configuration while you seem to let the device pull some configuration from a controller. Will both internally be treated the same way? > > I believe it is worth looking into the use case where a device wants to pull configuration from a 'controller' instead of having the 'controller' to push the configuration. Whether mount is the right solution for this, I can't tell at this point in time. > > /js (speaking as contributor) > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- 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 Oct 31 05:51:00 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71E881A8765 for ; Fri, 31 Oct 2014 05:50:58 -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 2-VWE_8oZRzz for ; Fri, 31 Oct 2014 05:50:52 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 583341A8AA6 for ; Fri, 31 Oct 2014 05:50:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7452; q=dns/txt; s=iport; t=1414759854; x=1415969454; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=gVb3O7fZDc6GAspyxLm3K2koJIvo+AyuA/iJWbK/2Ic=; b=MyYo8e+imTmxjnQ+oKXr3raNbNV0RVOz+32QszNK5s2PB7TG8iaeAVzo 7n3ufjH769s8jWJbCGoK8YmcSxln7+4qdIyH9le/AU8nl/vH2kRJXzucU 53WAKR7acN6dDw07i6AfA9ad3nKvZZbfUbmTSVZau7bthwsKoHgNDCmEz Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwFAJKEU1StJV2P/2dsb2JhbABZA4MOVFgEgwLKIIdLAhx7FgEBAQEBfYQCAQEBBCMRRQwCAgIBCA4CAQQBAQECAgYdAwICAhkXFAEICAIEDgUIE4gmDbUIlHMBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBIEpjzIWCxAHBguCZjaBHgWSFYRNiEc8hj6KFIQJg3hsgUiBAwEBAQ X-IronPort-AV: E=Sophos;i="5.07,294,1413244800"; d="scan'208";a="92056764" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-1.cisco.com with ESMTP; 31 Oct 2014 12:50:53 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s9VCopeu016565 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 Oct 2014 12:50:51 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.231]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0195.001; Fri, 31 Oct 2014 07:50:51 -0500 From: "Ambika Prasad Tripathy (ambtripa)" To: Juergen Schoenwaelder Thread-Topic: [netmod] YANG model containing both device and domain config Thread-Index: AQHP9NciSF8QziWu/kCXisv3L46wapxKGtSA//+uG9iAACes8IAAX2mA//+tEJCAAHQbAP//s6Ow Date: Fri, 31 Oct 2014 12:50:50 +0000 Message-ID: <3B675C3A8DF102408C754E30986E43CF05CE7960@xmb-aln-x08.cisco.com> References: <3B675C3A8DF102408C754E30986E43CF05CE77E9@xmb-aln-x08.cisco.com> <3B675C3A8DF102408C754E30986E43CF05CE789B@xmb-aln-x08.cisco.com> <20141031101045.GA2139@elstar.local> <3B675C3A8DF102408C754E30986E43CF05CE78D5@xmb-aln-x08.cisco.com> <20141031120930.GA2576@elstar.local> In-Reply-To: <20141031120930.GA2576@elstar.local> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.100.66] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/AI4GfWX_13tGe6XNXiivOgDoP-Q Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG model containing both device and domain config X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 31 Oct 2014 12:50:59 -0000 SGksDQoNClRvIGNsZWFyIHlvdSBmaXJzdCBOZXRDb25mIHNlcnZlciBpcyBub3QgYSBtb3VudCBj bGllbnQuIE1vdW50IGNsaWVudCBoYXMgdGhlIGNhcGFiaWxpdHkgdG8gbW91bnQgdG8gYSBNb3Vu dCBTZXJ2ZXIuIA0KDQo8anM+DQphKSBhIGNvbnRyb2xsZXIgbW91bnRpbmcgcmVhZC1vbmx5IGRh dGEgZnJvbSBhIHNldCBvZiBOQyBzZXJ2ZXJzDQo8L2pzPg0KDQpNb3VudCBjbGllbnQgcHJlc2Vu dCBpbiBjb250cm9sbGVyIG1vdW50aW5nIHJlYWQtb25seSBkYXRhIGZyb20gYSBzZXQgb2YgbW91 bnQgc2VydmVyLiBNb3VudCBzZXJ2ZXIgaXMgaW50ZXJhY3Rpbmcgd2l0aCBsb2NhbCBkYXRhc3Rv cmUuIElmIE5ldENvbmYgc2VydmVyIGhhcyB0aGUgZnVuY3Rpb25hbGx5IG9mIE1vdW50IFNlcnZl ciB0aGVuIHRoZSBzdGF0ZW1lbnQgaXMgcmlnaHQuDQoNCjxqcz4NCmIpIGEgTkMgc2VydmVyIG1v dW50aW5nIGRhdGEgZnJvbSBhIHNldCBvZiBjb250cm9sbGVycy4NCjwvanM+DQoNCklmIE5ldENv bmYgc2VydmVyIGhhcyBtb3VudCBjbGllbnQgZnVuY3Rpb25hbGl0eSwgaXQgY2FuIG1vdW50IGZy b20gYSBzZXQgb2YgY29udHJvbGxlci4gQnV0IGlkZWFsbHksIHRoZSBtb3VudCBjbGllbnQgc2hv dWxkIG1vdW50IGRhdGEgdG8gYSBtb3VudCBzZXJ2ZXIsIGluIHRoaXMgY2FzZSwgdGhlIG1vdW50 IHNlcnZlciBzaG91bGQgYmUgYSBwYXJ0IG9mIGNvbnRyb2xsZXIuIA0KDQoNCk5ldENvbmYgY2Fu IGJlIHVzZWQgYXMgYSB0cmFuc3BvcnQgYmV0d2VlbiBtb3VudCBjbGllbnQgYW5kIG1vdW50IHNl cnZlciBhbmQgaXQgaXMgaW1wbGVtZW50YXRpb24gZGVwZW5kZW50LiANCg0KDQpCciwNCkFtYmlr YQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSnVlcmdlbiBTY2hvZW53YWVs ZGVyIFttYWlsdG86ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlXSANClNlbnQ6 IEZyaWRheSwgT2N0b2JlciAzMSwgMjAxNCA1OjQwIFBNDQpUbzogQW1iaWthIFByYXNhZCBUcmlw YXRoeSAoYW1idHJpcGEpDQpDYzogUWluIFd1OyBNYXJ0aW4gQmpvcmtsdW5kOyBFcmljIFZvaXQg KGV2b2l0KTsgbmV0bW9kQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW25ldG1vZF0gWUFORyBtb2Rl bCBjb250YWluaW5nIGJvdGggZGV2aWNlIGFuZCBkb21haW4gY29uZmlnDQoNCkhpLA0KDQpJIHRo aW5rIHdlIG5lZWQgdG8gc2VwYXJhdGUgdGhlIGRpc2N1c3Npb24gY2xlYXJseSBiZXR3ZWVuOg0K DQphKSBhIGNvbnRyb2xsZXIgbW91bnRpbmcgcmVhZC1vbmx5IGRhdGEgZnJvbSBhIHNldCBvZiBO QyBzZXJ2ZXJzDQoNCmIpIGEgTkMgc2VydmVyIG1vdW50aW5nIGRhdGEgZnJvbSBhIHNldCBvZiBj b250cm9sbGVycw0KDQpGb3IgbWUsIHRoZXNlIGFyZSB2ZXJ5IGRpZmZlcmVudCB0aGluZ3MuIEkg Y2FuJ3QgcGFyc2UgeW91ciBhbnN3ZXIgYmVjYXVzZSBJIGRvIG5vdCBrbm93IHdoZW4geW91IHRh bGsgYWJvdXQgYSkgYW5kIHdoZW4gYWJvdXQgYikgYW5kIGJlY2F1c2Ugb2YgdGhhdCBJIGRvIG5v dCBrbm93IHdoYXQgJ2FwcGxpY2F0aW9uJyBpcyBvciB3aHkgZXZlbnR1YWwgY29uc2lzdGVuY3kg aXMgaW1wb3J0YW50Lg0KDQovanMNCg0KT24gRnJpLCBPY3QgMzEsIDIwMTQgYXQgMTA6MzM6NDhB TSArMDAwMCwgQW1iaWthIFByYXNhZCBUcmlwYXRoeSAoYW1idHJpcGEpIHdyb3RlOg0KPiBIaSAs DQo+IA0KPiBZZXMuIFRoZXJlIGFyZSBvdGhlciBtZWNoYW5pc20gdG8gcHVsbCB0aGUgZGF0YSBm cm9tIGRldmljZSB3aGVuIHJlcXVpcmVkIGJ5IGNvbnRyb2xsZXIgYmFzZWQgYXBwbGljYXRpb24s IGJ1dCBtb3VudCBpcyBtb3JlIHRoYW4gdGhhdC4gVGhlIGV4aXN0aW5nIHB1bGxpbmcgbWVjaGFu aXNtIGlzIGp1c3Qgb25lIHBhcnQgb2Ygd2hhdCBtb3VudCBkZXNjcmliZXMgYXJlIG9uLWRlbWFu ZCBtb3VudCBwb2xpY3kuIFRoZSBleGlzdGluZyBwdWxsaW5nIG1lY2hhbmlzbSBpcyBub3QgcHJv dmlkaW5nIGV2ZW50dWFsbHkgY29uc2lzdGVuY3kgYWNyb3NzIHRoZSBuZXR3b3JrIHdoaWNoIGlz IG5lZWQgYnkgdGhlIERvbWFpbiBwb2xpY2VyIGFwcGxpY2F0aW9uIGRlc2NyaWVkIGluIGRyYWZ0 LiBGb3IgdGhhdCBtb3VudCBpcyBhIGJldHRlciB3YXkuDQo+IA0KPiBXaGVuIGFwcGxpY2F0aW9u IG1vdW50J3MgYW55IG9iamVjdCB0byByZW1vdGUgZGF0YSBzdG9yZSwgaXQgaXMgdXAgdG8gdGhl IGFwcGxpY2F0aW9uIGhvdyB0byB1c2UgdGhlIG9iamVjdHMuIE1vdW50IGlzIG5vdCBlbmZvcmNp bmcgdG8gdXNlIHRob3NlIG9iamVjdHMgYnkgdGhlIGFwcGxpY2F0aW9uIG5vciBpdCBub3Qgb3Zl cnJpZGluZyBhbnkgcG9saWN5IG9mIHRoZSBhcHBsaWNhdGlvbiB3aGljaCBpcyBtb3VudGluZy4g VGhlIGFwcGxpY2F0aW9uIHdobyBvd24gdGhlIGF1dGhvcml0YXRpdmUgY29weSBvZiBvYmplY3Qs IHRoZXkgc2hvdWxkIGRlY2lkZSBvbiBob3cgdG8gdXNlIGl0Lg0KPiANCj4gQnIsDQo+IEFtYmlr YQ0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSnVlcmdlbiBTY2hv ZW53YWVsZGVyIA0KPiBbbWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5k ZV0NCj4gU2VudDogRnJpZGF5LCBPY3RvYmVyIDMxLCAyMDE0IDM6NDEgUE0NCj4gVG86IEFtYmlr YSBQcmFzYWQgVHJpcGF0aHkgKGFtYnRyaXBhKQ0KPiBDYzogUWluIFd1OyBNYXJ0aW4gQmpvcmts dW5kOyBFcmljIFZvaXQgKGV2b2l0KTsgbmV0bW9kQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBb bmV0bW9kXSBZQU5HIG1vZGVsIGNvbnRhaW5pbmcgYm90aCBkZXZpY2UgYW5kIGRvbWFpbiANCj4g Y29uZmlnDQo+IA0KPiBPbiBGcmksIE9jdCAzMSwgMjAxNCBhdCAwOTo1Mzo1MEFNICswMDAwLCBB bWJpa2EgUHJhc2FkIFRyaXBhdGh5IChhbWJ0cmlwYSkgd3JvdGU6DQo+ID4gSGksDQo+ID4gDQo+ ID4gQWRkaW5nIG1vcmUgaW5mbyBob3cgbW91bnQgd29ya3M6DQo+ID4gDQo+ID4gTW91bnQgYnJp bmdzIE9uZSBhdXRob3JpdGF0aXZlIGNvcHkgb2YgYW4gb2JqZWN0IGFjcm9zcyBhIE5ldHdvcmsu IEl0IGlzIHJlYWQgb25seSB0byB0aGUgZGF0YSBzdG9yZSB0byBnZXQgYSBzbmFwc2hvdCBvZiB0 aGUgbW91bnRlZCBkYXRhIHN0b3JlIGJhc2VkIG9uIG1vdW50IHBvbGljaWVzIGRlZmllZCBpbiBh bm90aGVyIElFVEYgZHJhZnQg4oCccGVlci1tb3VudC1yZXF1aXJlbWVudHM8aHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtdm9pdC1uZXRtb2QtcGVlci1tb3VudC1yZXF1aXJlbWVudHMt MDE+4oCdDQo+ID4gDQo+ID4gTW91bnQgaXMgbm90IGEgbWVjaGFuaXNtIHRvIGNvbmZpZ3VyZSBh IGRldmljZSBvciB3cml0ZSB0byByZW1vdGUgZGF0YSBzdG9yZS4gIEZvciB0aGF0IGV4aXN0aW5n IGludGVyZmFjZXMgYXJlIGFscmVhZHkgdGhlcmUuDQo+ID4NCj4gDQo+IFdlbGwsIHRoZXJlIGFy ZSBhbHNvIGV4aXN0aW5nIGludGVyZmFjZXMgdG8gcmVhZCBjb25maWcgYW5kIHN0YXRlIA0KPiBk YXRhLiA7LSkNCj4gDQo+ID4gSWYgZGV2aWNlcyB3YW50IHRvIGdldCBzb21lIGNvbmZpZ3VyYXRp b24gZGF0YSBmcm9tIGEgbmFtZXNwYWNlIG9mIHRoZSBjb250cm9sbGVyIGRhdGEgc3RvcmUsIHRo ZW4gYXBwbGljYXRpb25zIHJ1bm5pbmcgaW4gdGhlIGRldmljZSBjYW4gbW91bnQgaXQgZnJvbSB0 aGUgY29udHJvbGxlciBkYXRhc3RvcmUuDQo+ID4gRm9yIGV4YW1wbGUsIGZvciB0aGUgcG9saWNl ciB5YW5nIG1vZGVsIGRlZmluZWQgaW4gZHJhZnQgZHJhZnQtdHJpcGF0aHktY2xvdWQtc2xhLXlh bmctbW9kZWwtMDAsIGFwcGxpY2F0aW9ucyBydW5uaW5nIGluIGRldmljZSB3aGljaCBpcyByZXNw b25zaWJsZSBvZiBwb2xpY2luZyBkYXRhIGZvciB0aGUgZG9tYWluIGluIHRoZSBkZXZpY2UsIGNh biBtb3VudCB0aGUg4oCcY29udGFpbmVyIHBvbGljaW5nLXBvbGljaWVz4oCdIHRvIGdldCBuZXcg cG9saWNlIHZhbHVlcyB3aGVuIHRoZXJlIGlzIGEgY2hhbmdlIGluIHBvbGljeSByYXRlIGJ5IGNs b3VkIGFwcGxpY2F0aW9uLg0KPiA+DQo+IA0KPiBUaGlzIHVzZSBjYXNlIEkgZmluZCBhY3R1YWxs eSBtb3JlIGludGVyZXN0aW5nIGJ1dCB0aGVuIEkgYW0gbm90IHN1cmUgSSB1bmRlcnN0YW5kIGhv dyB0aGlzIHdvcmtzIG9yIHdoZXRoZXIgYSBwbGFpbiBtb3VudCBpcyB0aGUgd2F5IHRvIGRvIHRo aXMuIElmIGEgZGV2aWNlIG1vdW50cyBzb21lIHBvbGljeSBpbmZvcm1hdGlvbiwgZG9lcyB0aGlz IG1lYW4gdGhlIGRldmljZSBjb21taXRzIHRvIGZvbGxvdyB0aGUgcG9saWN5IGluZm9ybWF0aW9u LCB0aGF0IGlzIHRvIGNoYW5nZSB0aGUgb3BlcmF0aW9uYWwgc3RhdGUgYWNjb3JkaW5nIHRvIHRo ZSBwb2xpY3k/IElmIHNvLCBob3cgYXJlIGNvbmZsaWN0cyByZXNvbHZlZD8gV2hhdCBpcyB0aGUg bGlmZXRpbWUgb2YgdGhlIGluamVjdGVkIGNvbmZpZyBzdGF0ZT8gSXMgaXQgZXBoZW1lcmFsPyBJ cyBpdCBib3VuZCB0byB0aGUgbW91bnQ/IEhvdyBkb2VzIHRoaXMgcmVsYXRlIHRvIEkyUlM/DQo+ IFRoZXkgaW50ZW5kIHRvIHB1c2ggY29uZmlndXJhdGlvbiB3aGlsZSB5b3Ugc2VlbSB0byBsZXQg dGhlIGRldmljZSBwdWxsIHNvbWUgY29uZmlndXJhdGlvbiBmcm9tIGEgY29udHJvbGxlci4gV2ls bCBib3RoIGludGVybmFsbHkgYmUgdHJlYXRlZCB0aGUgc2FtZSB3YXk/DQo+IA0KPiBJIGJlbGll dmUgaXQgaXMgd29ydGggbG9va2luZyBpbnRvIHRoZSB1c2UgY2FzZSB3aGVyZSBhIGRldmljZSB3 YW50cyB0byBwdWxsIGNvbmZpZ3VyYXRpb24gZnJvbSBhICdjb250cm9sbGVyJyBpbnN0ZWFkIG9m IGhhdmluZyB0aGUgJ2NvbnRyb2xsZXInIHRvIHB1c2ggdGhlIGNvbmZpZ3VyYXRpb24uIFdoZXRo ZXIgbW91bnQgaXMgdGhlIHJpZ2h0IHNvbHV0aW9uIGZvciB0aGlzLCBJIGNhbid0IHRlbGwgYXQg dGhpcyBwb2ludCBpbiB0aW1lLg0KPiANCj4gL2pzIChzcGVha2luZyBhcyBjb250cmlidXRvcikN Cj4gDQo+IC0tIA0KPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2 ZXJzaXR5IEJyZW1lbiBnR21iSA0KPiBQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENh bXB1cyBSaW5nIDEsIDI4NzU5IEJyZW1lbiwgR2VybWFueQ0KPiBGYXg6ICAgKzQ5IDQyMSAyMDAg MzEwMyAgICAgICAgIDxodHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4NCg0KLS0gDQpK dWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBn R21iSA0KUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxLCAyODc1 OSBCcmVtZW4sIEdlcm1hbnkNCkZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHA6 Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0K From nobody Fri Oct 31 06:37:33 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E7A1A005C for ; Fri, 31 Oct 2014 06:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 LawpxlJqDeqj for ; Fri, 31 Oct 2014 06:37:29 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 332331A005B for ; Fri, 31 Oct 2014 06:37:28 -0700 (PDT) Received: from [192.168.1.123] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 4223728ECE03; Fri, 31 Oct 2014 09:37:28 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: "Thomas D. Nadeau" In-Reply-To: <20141031.075132.208810580.mbj@tail-f.com> Date: Fri, 31 Oct 2014 09:37:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <84CC7AF8-E068-4100-A3CE-578B10951F91@lucidvision.com> References: <20141031.075132.208810580.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/EeboBl4tKUqRaHorfrUt8gHAnhA Cc: netmod@ietf.org Subject: Re: [netmod] YANG model containing both device and domain config X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 31 Oct 2014 13:37:31 -0000 Speaking as chair, Is it worth separating out r-o and r-w behavior to help move the = conversation forward? --Tom > On Oct 31, 2014:2:51 AM, at 2:51 AM, Martin Bjorklund = wrote: >=20 > Hi, >=20 > "Eric Voit (evoit)" wrote: >> The OpenDaylight controller has already >> = implemented >> Mount as one of its most essential basic functions. If it wasn't = important, it >> wouldn't have been done. >>=20 >>=20 >>=20 >> The question is not whether Yang Mount is going to happen. It is = whether the >> IETF wants to be involved. >=20 > A clarification question: are we talking about read-only mounting or > read-write? >=20 > As I have written before, I believe the mechanism proposed doesn't > really work for read-write access. >=20 >=20 >=20 > /martin >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 From nobody Fri Oct 31 06:40:02 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89F611A0065; Fri, 31 Oct 2014 06:40:00 -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, T_REMOTE_IMAGE=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 o8hOnYMnmHwA; Fri, 31 Oct 2014 06:39:58 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 359131A005C; Fri, 31 Oct 2014 06:39:57 -0700 (PDT) Received: from [192.168.1.123] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 9E53928ECE28; Fri, 31 Oct 2014 09:39:56 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_C42AC55A-CC5C-4FC0-871B-D5D2DE622D62" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: "Thomas D. Nadeau" In-Reply-To: Date: Fri, 31 Oct 2014 09:39:56 -0400 Message-Id: <2BDFF8E6-A722-48D8-B4CE-9F3229B0196F@lucidvision.com> References: To: Tina TSOU X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ZoNsNudQalEBUdU-vp3OXAdmGkI Cc: "supa@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] SUPA drafts related to 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: Fri, 31 Oct 2014 13:40:00 -0000 --Apple-Mail=_C42AC55A-CC5C-4FC0-871B-D5D2DE622D62 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Rather than dropping a big list of models here for =E2=80=9Coption= al reading=E2=80=9D, it might help if you explain the context and why = people might spend time reviewing these. It should be pointed out that SUPA is not an IETF WG, so = understanding where this fits into the universe and why its relevant = would be helpful. =E2=80=94Tom > On Oct 31, 2014:5:12 AM, at 5:12 AM, Tina TSOU = wrote: >=20 > Dear all, >=20 > Some SUPA drafts related to YANG model for your reading pleasure and = comments. > = http://datatracker.ietf.org/doc/draft-contreras-supa-yang-network-topo/ = > = http://datatracker.ietf.org/doc/draft-zaalouk-supa-configuration-model/ = >=20 > More context could be found at > = http://datatracker.ietf.org/doc/search/?name=3DSupa&rfcs=3Don&activedrafts= =3Don&sort=3D&by=3Dauthor&author=3D = >=20 > Document=C2=A0 = Title=C2=A0 = Date=C2=A0 = Status=C2=A0 = IPR = AD / Shepherd=C2=A0 = > Active Internet-Drafts > draft-bi-supa-gap-analysis-00 = Shared = Unified Policy Automation (SUPA) Gap Analysis 2014-09-25 I-D = Exists =09 > draft-bi-supa-sdsavi-00 = A SUPA Use Case = for SAVI 2014-09-26 I-D Exists =09 > draft-cheng-supa-ddc-use-cases-01 = = Use Cases for Distributed Data Center Applications in SUPA = 2014-10-27 > new = = I-D Exists =09 > draft-contreras-supa-yang-network-topo-01 = = A YANG Data Model for Network Topologies 2014-10-27 > new = I-D Exists =09 > draft-karagiannis-supa-problem-statement-02 = Problem Statement for Shared Unified Policy Automation (SUPA) = 2014-10-27 > new = I-D Exists =09 > draft-pentikousis-supa-mapping-00 = = SUPA Configuration and Policy Mapping 2014-09-23 I-D Exists = =09 > draft-sun-supa-openv6-use-cases-00 = = Use case of IPv6 transition in SUPA 2014-09-25 I-D Exists = =09 > draft-zaalouk-supa-configuration-model-01 = = YANG Data Model for Configuration of Shared Unified Policy Automation = (SUPA) 2014-10-27 > new = I-D Exists =09 > draft-zhou-supa-architecture-00 = The = Architecture for Shared Unified Policy Automation (SUPA) = 2014-10-27 > new = I-D Exists =09 >=20 >=20 > Thank you, > Tina > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --Apple-Mail=_C42AC55A-CC5C-4FC0-871B-D5D2DE622D62 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Rather = than dropping a big list of models here for =E2=80=9Coptional = reading=E2=80=9D, it might help if you explain the context and why = people might spend time reviewing these.

It should be pointed out that = SUPA is not an IETF WG, so understanding where this fits into the = universe and why its relevant would be helpful.

= =E2=80=94Tom



On Oct 31, 2014:5:12 AM, at = 5:12 AM, Tina TSOU <Tina.Tsou.Zouting@huawei.com> wrote:

Dear = all,

Some SUPA = drafts related to YANG model for your reading pleasure and = comments.
http://datatracker.ietf.org/doc/draft-contreras-supa-yang-netwo= rk-topo/
http://datatracker.ietf.org/doc/draft-zaalouk-supa-configuratio= n-model/

More context could be found at
http://datatracker.ietf.org/doc/search/?name=3DSupa&rfcs=3D= on&activedrafts=3Don&sort=3D&by=3Dauthor&author=3D

Document  Title  Date  Status  IPR  AD / = Shepherd 
Active Internet-Drafts
draft-bi-supa-gap-analysis-00 Shared Unified Policy Automation (SUPA) Gap = Analysis 2014-09-25 I-D = Exists
draft-bi-supa-sdsavi-00 A = SUPA Use Case for SAVI 2014-09-26 I-D = Exists
draft-cheng-supa-ddc-use-cases-01 Use = Cases for Distributed Data Center Applications in SUPA 2014-10-27
new
 I-D = Exists
draft-contreras-supa-yang-network-topo-01 A = YANG Data Model for Network Topologies 2014-10-27
new
= 		I-D = Exists
draft-karagiannis-supa-problem-statement-02 Problem Statement for Shared Unified Policy Automation = (SUPA) 2014-10-27
new
= 		I-D = Exists
draft-pentikousis-supa-mapping-00 SUPA = Configuration and Policy Mapping 2014-09-23 I-D = Exists
draft-sun-supa-openv6-use-cases-00 Use = case of IPv6 transition in SUPA 2014-09-25 I-D = Exists
draft-zaalouk-supa-configuration-model-01 YANG = Data Model for Configuration of Shared Unified Policy Automation = (SUPA) 2014-10-27
new
= 		I-D = Exists
draft-zhou-supa-architecture-00 The = Architecture for Shared Unified Policy Automation (SUPA) 2014-10-27
new
 I-D = Exists


Thank you,
Tina
_______________________________________________
netmod = mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

= --Apple-Mail=_C42AC55A-CC5C-4FC0-871B-D5D2DE622D62-- From nobody Fri Oct 31 06:55:16 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60D221A008C for ; Fri, 31 Oct 2014 06:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 jTtfbKcEaSlZ for ; Fri, 31 Oct 2014 06:55:11 -0700 (PDT) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FAAA1A003B for ; Fri, 31 Oct 2014 06:55:10 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id ge10so6333666lab.16 for ; Fri, 31 Oct 2014 06:55: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=EIGkHeER9guYdRMlqkPaWtMSYCMGGczt7mB2VDIM91U=; b=dpNVUF4riawsKSZRH3cD3gqFkYSJ8c0M2wvgcGy3XgLHKqa3DFhDoa5qVQ3k7h90eW ZeFdYwLXaHmu1VqlX6e4rmQCv1OsoIGIr+yLxTLEOvemndrNbn9XpPNyFktCNG/4OJE3 v5mOcVZXOIZ7JwHR5zowvkzeOLrUDBX4e5R8owTwJHsgJA+PV9zy7ESa09PnF2BxBHYS VYFQ5ZZQOJvJ292EXhyBHtGvTBeuWj+bWPdynR1PnE4KU24/sjZb3uPF0XhV3fRy4BbT SE2vtNWLk7Yr8SdC+n5XUsLxRUwyR3bVvHLzle/et62SN6rcodoC4zFZlNGk2FGz7zJe XkXg== X-Gm-Message-State: ALoCoQkOje7Kca89E3pfIACtHErAIztbIG2uO8kqOFM2/unWliOae4/LfrBHswduXuDodBf8w7Xi MIME-Version: 1.0 X-Received: by 10.152.18.166 with SMTP id x6mr26051521lad.18.1414763708757; Fri, 31 Oct 2014 06:55:08 -0700 (PDT) Received: by 10.112.130.234 with HTTP; Fri, 31 Oct 2014 06:55:08 -0700 (PDT) In-Reply-To: <84CC7AF8-E068-4100-A3CE-578B10951F91@lucidvision.com> References: <20141031.075132.208810580.mbj@tail-f.com> <84CC7AF8-E068-4100-A3CE-578B10951F91@lucidvision.com> Date: Fri, 31 Oct 2014 09:55:08 -0400 Message-ID: From: Sander Mertens To: "Thomas D. Nadeau" Content-Type: multipart/alternative; boundary=089e014942104d50600506b85884 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/wnH3bnwsRGaIk0olCUiCNBSXkk4 Cc: netmod@ietf.org Subject: Re: [netmod] YANG model containing both device and domain config X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 31 Oct 2014 13:55:14 -0000 --089e014942104d50600506b85884 Content-Type: text/plain; charset=UTF-8 Hi, Please note that it is at the very least not technically unfeasible to have both read-only and read-write behavior in the proposed architecture. As an example, any implementation of OMG-DDS allows for this behavior. The semantics can be questionable in a case where there is one clear owner of the data, with perhaps the notable exception of multiple redundant servers. For the latter usecase (deployed) patterns already exist that effectively handle these scenarios. Cheers, Sander On 31 October 2014 09:37, Thomas D. Nadeau wrote: > > Speaking as chair, > > Is it worth separating out r-o and r-w behavior to help move the > conversation forward? > > --Tom > > > > On Oct 31, 2014:2:51 AM, at 2:51 AM, Martin Bjorklund > wrote: > > > > Hi, > > > > "Eric Voit (evoit)" wrote: > >> The OpenDaylight controller has already > >> implemented< > http://sdntutorials.com/how-to-access-data-in-md-sal-from-mount-point/> > >> Mount as one of its most essential basic functions. If it wasn't > important, it > >> wouldn't have been done. > >> > >> > >> > >> The question is not whether Yang Mount is going to happen. It is > whether the > >> IETF wants to be involved. > > > > A clarification question: are we talking about read-only mounting or > > read-write? > > > > As I have written before, I believe the mechanism proposed doesn't > > really work for read-write access. > > > > > > > > /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 > --089e014942104d50600506b85884 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Please note that it is at the very = least not technically unfeasible to have both read-only and read-write beha= vior in the proposed architecture. As an example, any implementation of OMG= -DDS allows for this behavior.

The semantics can b= e questionable in a case where there is one clear owner of the data, with p= erhaps the notable exception of multiple redundant servers. For the latter = usecase (deployed) patterns already exist that effectively handle these sce= narios.

Cheers,
Sander

On 31 October 2014 09:37, T= homas D. Nadeau <tnadeau@lucidvision.com> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Speaking as chair,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Is it worth separating out r-o and r-w behavior= to help move the conversation forward?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 --Tom


> On Oct 31, 2014:2:51 AM, at 2:51 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> Hi,
>
> "Eric Voit (evoit)" <e= voit@cisco.com> wrote:
>> The OpenDaylight controller has already
>> implemented<http://sdntutorials.com/h= ow-to-access-data-in-md-sal-from-mount-point/>
>> Mount as one of its most essential basic functions.=C2=A0 If it wa= sn't important, it
>> wouldn't have been done.
>>
>>
>>
>> The question is not whether Yang Mount is going to happen.=C2=A0 I= t is whether the
>> IETF wants to be involved.
>
> A clarification question: are we talking about read-only mounting or > read-write?
>
> As I have written before, I believe the mechanism proposed doesn't=
> really work for read-write access.
>
>
>
> /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

--089e014942104d50600506b85884-- From nobody Fri Oct 31 07:03:22 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 629F21A9031 for ; Fri, 31 Oct 2014 07:03:10 -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, 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 d6OajBraYab4 for ; Fri, 31 Oct 2014 07:03:02 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id F3C9A1A902E for ; Fri, 31 Oct 2014 07:02:49 -0700 (PDT) Received: from [192.168.1.123] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 725D828ED05F; Fri, 31 Oct 2014 10:02:42 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_316C0C3A-26F2-4596-B0F9-51C3D31A871F" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: "Thomas D. Nadeau" In-Reply-To: Date: Fri, 31 Oct 2014 10:02:42 -0400 Message-Id: <9A852290-B831-4DDC-9239-B695145C8328@lucidvision.com> References: <20141031.075132.208810580.mbj@tail-f.com> <84CC7AF8-E068-4100-A3CE-578B10951F91@lucidvision.com> To: Sander Mertens X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/1Of8_7reW6cF8D36TA9Gji_HyJs Cc: netmod@ietf.org Subject: Re: [netmod] YANG model containing both device and domain config X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 31 Oct 2014 14:03:10 -0000 --Apple-Mail=_316C0C3A-26F2-4596-B0F9-51C3D31A871F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 That is part of why I am asking if it makes sense to separate = things. In the first case, the read-only method does fit in the current = architecture and might be easier to progress at the moment. The other = part might need to be in =E2=80=9CYang 2.0=E2=80=9D. =E2=80=94Tom > On Oct 31, 2014:9:55 AM, at 9:55 AM, Sander Mertens = wrote: >=20 > Hi, >=20 > Please note that it is at the very least not technically unfeasible to = have both read-only and read-write behavior in the proposed = architecture. As an example, any implementation of OMG-DDS allows for = this behavior. >=20 > The semantics can be questionable in a case where there is one clear = owner of the data, with perhaps the notable exception of multiple = redundant servers. For the latter usecase (deployed) patterns already = exist that effectively handle these scenarios. >=20 > Cheers, > Sander >=20 > On 31 October 2014 09:37, Thomas D. Nadeau > wrote: >=20 > Speaking as chair, >=20 > Is it worth separating out r-o and r-w behavior to help move = the conversation forward? >=20 > --Tom >=20 >=20 > > On Oct 31, 2014:2:51 AM, at 2:51 AM, Martin Bjorklund = > wrote: > > > > Hi, > > > > "Eric Voit (evoit)" > = wrote: > >> The OpenDaylight controller has already > >> = implemented> > >> Mount as one of its most essential basic functions. If it wasn't = important, it > >> wouldn't have been done. > >> > >> > >> > >> The question is not whether Yang Mount is going to happen. It is = whether the > >> IETF wants to be involved. > > > > A clarification question: are we talking about read-only mounting or > > read-write? > > > > As I have written before, I believe the mechanism proposed doesn't > > really work for read-write access. > > > > > > > > /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 --Apple-Mail=_316C0C3A-26F2-4596-B0F9-51C3D31A871F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

That is = part of why I am asking if it makes sense to separate things. In the = first case, the read-only method does fit in the current architecture = and might be easier to progress at the moment. The other part might need = to be in =E2=80=9CYang 2.0=E2=80=9D.

=E2=80=94Tom


On = Oct 31, 2014:9:55 AM, at 9:55 AM, Sander Mertens <sander.mertens@prismtech.com> wrote:

Hi,

Please = note that it is at the very least not technically unfeasible to have = both read-only and read-write behavior in the proposed architecture. As = an example, any implementation of OMG-DDS allows for this = behavior.

The = semantics can be questionable in a case where there is one clear owner = of the data, with perhaps the notable exception of multiple redundant = servers. For the latter usecase (deployed) patterns already exist that = effectively handle these scenarios.

Cheers,
Sander

On 31 October 2014 09:37, Thomas D. Nadeau <tnadeau@lucidvision.com> = wrote:

        Speaking as chair,

        Is it worth separating out r-o and r-w = behavior to help move the conversation forward?

        --Tom


> On Oct 31, 2014:2:51 AM, at 2:51 AM, Martin Bjorklund <mbj@tail-f.com> = wrote:
>
> Hi,
>
> "Eric Voit (evoit)" <evoit@cisco.com> wrote:
>> The OpenDaylight controller has already
>> implemented<http://sdntutorials.com/how-to-access-data-in-md-sal-from-mount= -point/>
>> Mount as one of its most essential basic functions.  If it = wasn't important, it
>> wouldn't have been done.
>>
>>
>>
>> The question is not whether Yang Mount is going to = happen.  It is whether the
>> IETF wants to be involved.
>
> A clarification question: are we talking about read-only mounting = or
> read-write?
>
> As I have written before, I believe the mechanism proposed = doesn't
> really work for read-write access.
>
>
>
> /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


= --Apple-Mail=_316C0C3A-26F2-4596-B0F9-51C3D31A871F-- From nobody Fri Oct 31 07:56:22 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6C31A9081 for ; Fri, 31 Oct 2014 07:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 6QSGFjFKoP7P for ; Fri, 31 Oct 2014 07:56:09 -0700 (PDT) Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CD4C1A9088 for ; Fri, 31 Oct 2014 07:56:03 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id j7so5474080qaq.30 for ; Fri, 31 Oct 2014 07:56:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=FhMYxCsy79nbsc2Op8jKy8RrJ7+gBNxQZXRdc2KGVgw=; b=gu2MqxXoNYL/htBBbnNrygRK8MUsJESYiZO+qb2vqAHLL9jYUjAmbXU7EJ3L+luO7C /8URJOk5Qqgg2/rDnA8v9BjSM1IbaAWhzNehzO8/2NMMC273fkhqiZ9Ohsn/4g9TENQP 93zbjgIVrxbmVSCWNszC/90Ia/4mu+nhZctlE4RXPvDZFUfxuiMQw01zid26MoxtFWNk DLPuSSiEUw34D4ME1kwbCc3/0h9G1/oGtAELeos/rfbSmne5LPxqRJeQ9+Q3gFWgjkO7 D17TjcPC6RoOrlglmwAHJPik5voweeep594nANqQ+kBW8cWqYvnyV5nauSoJXLTYr9o4 Q/0g== X-Gm-Message-State: ALoCoQnasmagEz3kT25MU7EDLC8VKdGT7kFIL6bcEorrnsu68mxlHUkqlIs15mlVOl2xoGU4sTLH MIME-Version: 1.0 X-Received: by 10.224.28.133 with SMTP id m5mr36801685qac.7.1414767362300; Fri, 31 Oct 2014 07:56:02 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Fri, 31 Oct 2014 07:56:02 -0700 (PDT) In-Reply-To: <20141031120930.GA2576@elstar.local> References: <3B675C3A8DF102408C754E30986E43CF05CE77E9@xmb-aln-x08.cisco.com> <3B675C3A8DF102408C754E30986E43CF05CE789B@xmb-aln-x08.cisco.com> <20141031101045.GA2139@elstar.local> <3B675C3A8DF102408C754E30986E43CF05CE78D5@xmb-aln-x08.cisco.com> <20141031120930.GA2576@elstar.local> Date: Fri, 31 Oct 2014 07:56:02 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , "Ambika Prasad Tripathy (ambtripa)" , Qin Wu , Martin Bjorklund , "Eric Voit (evoit)" , "netmod@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/jhwv0aOLo_i1Z2ULh97ZggnxxTg Subject: Re: [netmod] YANG model containing both device and domain config X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 31 Oct 2014 14:56:13 -0000 Hi, Maybe you can explain to me (because the authors can't) why we need mechanisms for devices to replicate their data on a controller? Why problem does this solve? Why is the device initiating the mount? How is the controller-specific config managed in each device and why is this easier/better than just configuring the controller to replicate data? I am much more concerned about resources and complexity in the devices than in the controllers. Why put complex code in 1000 boxes when it can go in just 10? Why configure 1000 boxes when you can just configure just 10? What happens when 1000 devices are pushing operational state changes too fast? How much device and network overhead is acceptable? Polling has its drawbacks but flooding the collector isn't one of them. It seems like a burst of operational updates would correlate with bursts of network activity, making congestion even worse. Andy On Fri, Oct 31, 2014 at 5:09 AM, Juergen Schoenwaelder wrote: > Hi, > > I think we need to separate the discussion clearly between: > > a) a controller mounting read-only data from a set of NC servers > > b) a NC server mounting data from a set of controllers > > For me, these are very different things. I can't parse your answer > because I do not know when you talk about a) and when about b) and > because of that I do not know what 'application' is or why eventual > consistency is important. > > /js > > On Fri, Oct 31, 2014 at 10:33:48AM +0000, Ambika Prasad Tripathy (ambtrip= a) wrote: >> Hi , >> >> Yes. There are other mechanism to pull the data from device when require= d by controller based application, but mount is more than that. The existin= g pulling mechanism is just one part of what mount describes are on-demand = mount policy. The existing pulling mechanism is not providing eventually co= nsistency across the network which is need by the Domain policer applicatio= n descried in draft. For that mount is a better way. >> >> When application mount's any object to remote data store, it is up to th= e application how to use the objects. Mount is not enforcing to use those o= bjects by the application nor it not overriding any policy of the applicati= on which is mounting. The application who own the authoritative copy of obj= ect, they should decide on how to use it. >> >> Br, >> Ambika >> >> -----Original Message----- >> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de= ] >> Sent: Friday, October 31, 2014 3:41 PM >> To: Ambika Prasad Tripathy (ambtripa) >> Cc: Qin Wu; Martin Bjorklund; Eric Voit (evoit); netmod@ietf.org >> Subject: Re: [netmod] YANG model containing both device and domain confi= g >> >> On Fri, Oct 31, 2014 at 09:53:50AM +0000, Ambika Prasad Tripathy (ambtri= pa) wrote: >> > Hi, >> > >> > Adding more info how mount works: >> > >> > Mount brings One authoritative copy of an object across a Network. It = is read only to the data store to get a snapshot of the mounted data store = based on mount policies defied in another IETF draft =E2=80=9Cpeer-mount-re= quirements=E2=80=9D >> > >> > Mount is not a mechanism to configure a device or write to remote data= store. For that existing interfaces are already there. >> > >> >> Well, there are also existing interfaces to read config and state data. = ;-) >> >> > If devices want to get some configuration data from a namespace of the= controller data store, then applications running in the device can mount i= t from the controller datastore. >> > For example, for the policer yang model defined in draft draft-tripath= y-cloud-sla-yang-model-00, applications running in device which is responsi= ble of policing data for the domain in the device, can mount the =E2=80=9Cc= ontainer policing-policies=E2=80=9D to get new police values when there is = a change in policy rate by cloud application. >> > >> >> This use case I find actually more interesting but then I am not sure I = understand how this works or whether a plain mount is the way to do this. I= f a device mounts some policy information, does this mean the device commit= s to follow the policy information, that is to change the operational state= according to the policy? If so, how are conflicts resolved? What is the li= fetime of the injected config state? Is it ephemeral? Is it bound to the mo= unt? How does this relate to I2RS? >> They intend to push configuration while you seem to let the device pull = some configuration from a controller. Will both internally be treated the s= ame way? >> >> I believe it is worth looking into the use case where a device wants to = pull configuration from a 'controller' instead of having the 'controller' t= o push the configuration. Whether mount is the right solution for this, I c= an't tell at this point in time. >> >> /js (speaking as contributor) >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 > > -- > 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 Fri Oct 31 08:06:13 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19DB51A90B5 for ; Fri, 31 Oct 2014 08:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, 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 zwJXoXWXgdrJ for ; Fri, 31 Oct 2014 08:06:08 -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 F1C1A1A90B7 for ; Fri, 31 Oct 2014 08:06: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 C4FEC764; Fri, 31 Oct 2014 16:06:06 +0100 (CET) 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 52KRVeq0RorR; Fri, 31 Oct 2014 16:05:38 +0100 (CET) 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, 31 Oct 2014 16:06:05 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4168220038; Fri, 31 Oct 2014 16:06:05 +0100 (CET) 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 m6KQIQcYHN9m; Fri, 31 Oct 2014 16:05:05 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E83C920035; Fri, 31 Oct 2014 16:06:02 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3D2E82F3C21A; Fri, 31 Oct 2014 16:06:00 +0100 (CET) Date: Fri, 31 Oct 2014 16:05:59 +0100 From: Juergen Schoenwaelder To: "Ambika Prasad Tripathy (ambtripa)" Message-ID: <20141031150557.GA3050@elstar.local> Mail-Followup-To: "Ambika Prasad Tripathy (ambtripa)" , Qin Wu , Martin Bjorklund , "Eric Voit (evoit)" , "netmod@ietf.org" References: <3B675C3A8DF102408C754E30986E43CF05CE77E9@xmb-aln-x08.cisco.com> <3B675C3A8DF102408C754E30986E43CF05CE789B@xmb-aln-x08.cisco.com> <20141031101045.GA2139@elstar.local> <3B675C3A8DF102408C754E30986E43CF05CE78D5@xmb-aln-x08.cisco.com> <20141031120930.GA2576@elstar.local> <3B675C3A8DF102408C754E30986E43CF05CE7960@xmb-aln-x08.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3B675C3A8DF102408C754E30986E43CF05CE7960@xmb-aln-x08.cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/AdUUpKlDWUJRbmAfaTr1vqZ7Ufs Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG model containing both device and domain config 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, 31 Oct 2014 15:06:11 -0000 Hi, I am getting a bit more confused - this has nothing to do with NETCONF or RESTCONF anymore? When you say 'datastore', does it mean the same thing that I think a 'datastore' is? What are the semantics of the interaction between your mount client and mount server? All implementation dependent and thus non-interoperable? IETF standards are about interoperability. When you write "But ideally, the mount client should mount data to a mount server, in this case, the mount server should be a part of controller", you seem to imply that ideally there is some other protocol involved. What is this other protocol and what are the semantics? Does your implementation only work with NC servers that have an associated Mount Client? Does any of the documents clarify all this? Any cool simple figures or highlevel summaries or terminology definitions I should look at? /js On Fri, Oct 31, 2014 at 12:50:50PM +0000, Ambika Prasad Tripathy (ambtripa) wrote: > Hi, > > To clear you first NetConf server is not a mount client. Mount client has the capability to mount to a Mount Server. > > > a) a controller mounting read-only data from a set of NC servers > > > Mount client present in controller mounting read-only data from a set of mount server. Mount server is interacting with local datastore. If NetConf server has the functionally of Mount Server then the statement is right. > > > b) a NC server mounting data from a set of controllers. > > > If NetConf server has mount client functionality, it can mount from a set of controller. But ideally, the mount client should mount data to a mount server, in this case, the mount server should be a part of controller. > > > NetConf can be used as a transport between mount client and mount server and it is implementation dependent. > > > Br, > Ambika > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Friday, October 31, 2014 5:40 PM > To: Ambika Prasad Tripathy (ambtripa) > Cc: Qin Wu; Martin Bjorklund; Eric Voit (evoit); netmod@ietf.org > Subject: Re: [netmod] YANG model containing both device and domain config > > Hi, > > I think we need to separate the discussion clearly between: > > a) a controller mounting read-only data from a set of NC servers > > b) a NC server mounting data from a set of controllers > > For me, these are very different things. I can't parse your answer because I do not know when you talk about a) and when about b) and because of that I do not know what 'application' is or why eventual consistency is important. > > /js > > On Fri, Oct 31, 2014 at 10:33:48AM +0000, Ambika Prasad Tripathy (ambtripa) wrote: > > Hi , > > > > Yes. There are other mechanism to pull the data from device when required by controller based application, but mount is more than that. The existing pulling mechanism is just one part of what mount describes are on-demand mount policy. The existing pulling mechanism is not providing eventually consistency across the network which is need by the Domain policer application descried in draft. For that mount is a better way. > > > > When application mount's any object to remote data store, it is up to the application how to use the objects. Mount is not enforcing to use those objects by the application nor it not overriding any policy of the application which is mounting. The application who own the authoritative copy of object, they should decide on how to use it. > > > > Br, > > Ambika > > > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Friday, October 31, 2014 3:41 PM > > To: Ambika Prasad Tripathy (ambtripa) > > Cc: Qin Wu; Martin Bjorklund; Eric Voit (evoit); netmod@ietf.org > > Subject: Re: [netmod] YANG model containing both device and domain > > config > > > > On Fri, Oct 31, 2014 at 09:53:50AM +0000, Ambika Prasad Tripathy (ambtripa) wrote: > > > Hi, > > > > > > Adding more info how mount works: > > > > > > Mount brings One authoritative copy of an object across a Network. It is read only to the data store to get a snapshot of the mounted data store based on mount policies defied in another IETF draft “peer-mount-requirements” > > > > > > Mount is not a mechanism to configure a device or write to remote data store. For that existing interfaces are already there. > > > > > > > Well, there are also existing interfaces to read config and state > > data. ;-) > > > > > If devices want to get some configuration data from a namespace of the controller data store, then applications running in the device can mount it from the controller datastore. > > > For example, for the policer yang model defined in draft draft-tripathy-cloud-sla-yang-model-00, applications running in device which is responsible of policing data for the domain in the device, can mount the “container policing-policies” to get new police values when there is a change in policy rate by cloud application. > > > > > > > This use case I find actually more interesting but then I am not sure I understand how this works or whether a plain mount is the way to do this. If a device mounts some policy information, does this mean the device commits to follow the policy information, that is to change the operational state according to the policy? If so, how are conflicts resolved? What is the lifetime of the injected config state? Is it ephemeral? Is it bound to the mount? How does this relate to I2RS? > > They intend to push configuration while you seem to let the device pull some configuration from a controller. Will both internally be treated the same way? > > > > I believe it is worth looking into the use case where a device wants to pull configuration from a 'controller' instead of having the 'controller' to push the configuration. Whether mount is the right solution for this, I can't tell at this point in time. > > > > /js (speaking as contributor) > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- 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 Oct 31 10:45:01 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3151A0081 for ; Fri, 31 Oct 2014 10:44:59 -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 M-Y9BUZPP-JR for ; Fri, 31 Oct 2014 10:44:56 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3B2F1A0169 for ; Fri, 31 Oct 2014 10:44:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14960; q=dns/txt; s=iport; t=1414777493; x=1415987093; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=374CtPZ89afATbMQ1mVn1uAHHYqQkfKHyR7rbVrJxuY=; b=Lt+QjVxBFD3dFd9r10foLVD9KHfomHRyHH4NNnDP9GDC8l5w9CtT0Abf 0af4/FH4aTiw0RIK5pKrqCYUytzd8InX13vCg32NTRK/Ti2UH3msw0K5V etGdVllcpQOztaW+37uacgn+RafDjbwhsfhHtEz7sJwvjvIahdfMJ5sYN 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUFAALKU1StJA2G/2dsb2JhbABcgkhGVFgEgwK6DpALAQmGeVQCHHwWAQEBAQF9hAIBAQEDAQEBASAKQQsFCwIBCBIDAwodAwICAiULFAMOAgQBDQUIE4gdCQ22E5R/AQEBAQEBAQEBAQEBAQEBAQEBAQEBF5BfFhcEBgGCdzaBHgWSFYRNiEc8gw6DMI4dg3hsgUiBAwEBAQ X-IronPort-AV: E=Sophos;i="5.07,295,1413244800"; d="scan'208,217";a="368334562" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-4.cisco.com with ESMTP; 31 Oct 2014 17:44:52 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s9VHiqVW003675 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 Oct 2014 17:44:52 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.58]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0195.001; Fri, 31 Oct 2014 12:44:52 -0500 From: "Eric Voit (evoit)" To: "Thomas D. Nadeau" , Sander Mertens Thread-Topic: [netmod] YANG model containing both device and domain config Thread-Index: AQHP9Ncc0r5QzlOUmUKJvUWcHn/dupxKicMA//+zc3SAADhMEA== Date: Fri, 31 Oct 2014 17:44:51 +0000 Message-ID: References: <20141031.075132.208810580.mbj@tail-f.com> <84CC7AF8-E068-4100-A3CE-578B10951F91@lucidvision.com> <9A852290-B831-4DDC-9239-B695145C8328@lucidvision.com> In-Reply-To: <9A852290-B831-4DDC-9239-B695145C8328@lucidvision.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.208.26] Content-Type: multipart/alternative; boundary="_000_EF64FF31F4C4384DBCE5D513A791C2B120A5B132xmbalnx11ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/PpGvAWWg9iO5t0ypG-oXnqDj5QI Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG model containing both device and domain config X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 31 Oct 2014 17:44:59 -0000 --_000_EF64FF31F4C4384DBCE5D513A791C2B120A5B132xmbalnx11ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSBmaW5lIHdpdGggc3BsaXR0aW5nIHJlYWQgYW5kIHdyaXRlLiAgVGhlIG9uZSBjYXZlYXQg aGVyZSBpcyB0aGF0IHdlIHdpbGwgZXZlbnR1YWxseSBleHBsb3JlIEhpZ2ggQXZhaWxhYmlsaXR5 IGNsdXN0ZXJzIHdoZXJlIGEgZmVkZXJhdGlvbiBvZiBNb3VudCBTZXJ2ZXJzIHByb3ZpZGUgdGhl IGF1dGhvcml0YXRpdmUgZGF0YS4gIEJ1dCBhbnkgc29sdXRpb25zIGNhbiBzdGlsbCBiZSBhIHNl cGFyYXRlIHRlY2hub2xvZ3kgZHJhZnQuDQoNCkFzIFNhbmRlciBub3RlcyBiZWxvdywgc3VjaCBI QSBjbHVzdGVyaW5nIGlzIHJ1bm5pbmcgaW4gRERTLiAgQmFzZWQgb24gaGlzIGV4cGVyaWVuY2Ug d2l0aCB0aGlzIGNvZGUsIGhlIHdyb3RlIHRoZSBIaWdoIEF2YWlsYWJpbGl0eSBwb3J0aW9uIG9m IHRoZSByZXF1aXJlbWVudHMgZHJhZnQgKFNlY3Rpb24gNS43KS4gIFNvIHdlIGNhbiBsZWFuIG9u IGhpbSBhcyB0byBob3cgaXQgbWlnaHQgYmUgZG9uZSA7LSkuDQoNCkVyaWMNCg0KRnJvbTogVGhv bWFzIEQuIE5hZGVhdSwgT2N0b2JlciAzMSwgMjAxNCAxMDowMyBBTQ0KDQogICAgICAgICAgVGhh dCBpcyBwYXJ0IG9mIHdoeSBJIGFtIGFza2luZyBpZiBpdCBtYWtlcyBzZW5zZSB0byBzZXBhcmF0 ZSB0aGluZ3MuIEluIHRoZSBmaXJzdCBjYXNlLCB0aGUgcmVhZC1vbmx5IG1ldGhvZCBkb2VzIGZp dCBpbiB0aGUgY3VycmVudCBhcmNoaXRlY3R1cmUgYW5kIG1pZ2h0IGJlIGVhc2llciB0byBwcm9n cmVzcyBhdCB0aGUgbW9tZW50LiBUaGUgb3RoZXIgcGFydCBtaWdodCBuZWVkIHRvIGJlIGluIOKA nFlhbmcgMi4w4oCdLg0KDQogICAgICAgICAg4oCUVG9tDQoNCg0KT24gT2N0IDMxLCAyMDE0Ojk6 NTUgQU0sIGF0IDk6NTUgQU0sIFNhbmRlciBNZXJ0ZW5zIDxzYW5kZXIubWVydGVuc0BwcmlzbXRl Y2guY29tPG1haWx0bzpzYW5kZXIubWVydGVuc0BwcmlzbXRlY2guY29tPj4gd3JvdGU6DQoNCkhp LA0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IGlzIGF0IHRoZSB2ZXJ5IGxlYXN0IG5vdCB0ZWNobmlj YWxseSB1bmZlYXNpYmxlIHRvIGhhdmUgYm90aCByZWFkLW9ubHkgYW5kIHJlYWQtd3JpdGUgYmVo YXZpb3IgaW4gdGhlIHByb3Bvc2VkIGFyY2hpdGVjdHVyZS4gQXMgYW4gZXhhbXBsZSwgYW55IGlt cGxlbWVudGF0aW9uIG9mIE9NRy1ERFMgYWxsb3dzIGZvciB0aGlzIGJlaGF2aW9yLg0KDQpUaGUg c2VtYW50aWNzIGNhbiBiZSBxdWVzdGlvbmFibGUgaW4gYSBjYXNlIHdoZXJlIHRoZXJlIGlzIG9u ZSBjbGVhciBvd25lciBvZiB0aGUgZGF0YSwgd2l0aCBwZXJoYXBzIHRoZSBub3RhYmxlIGV4Y2Vw dGlvbiBvZiBtdWx0aXBsZSByZWR1bmRhbnQgc2VydmVycy4gRm9yIHRoZSBsYXR0ZXIgdXNlY2Fz ZSAoZGVwbG95ZWQpIHBhdHRlcm5zIGFscmVhZHkgZXhpc3QgdGhhdCBlZmZlY3RpdmVseSBoYW5k bGUgdGhlc2Ugc2NlbmFyaW9zLg0KDQpDaGVlcnMsDQpTYW5kZXINCg0KT24gMzEgT2N0b2JlciAy MDE0IDA5OjM3LCBUaG9tYXMgRC4gTmFkZWF1IDx0bmFkZWF1QGx1Y2lkdmlzaW9uLmNvbTxtYWls dG86dG5hZGVhdUBsdWNpZHZpc2lvbi5jb20+PiB3cm90ZToNCg0KICAgICAgICBTcGVha2luZyBh cyBjaGFpciwNCg0KICAgICAgICBJcyBpdCB3b3J0aCBzZXBhcmF0aW5nIG91dCByLW8gYW5kIHIt dyBiZWhhdmlvciB0byBoZWxwIG1vdmUgdGhlIGNvbnZlcnNhdGlvbiBmb3J3YXJkPw0KDQogICAg ICAgIC0tVG9tDQoNCg0KPiBPbiBPY3QgMzEsIDIwMTQ6Mjo1MSBBTSwgYXQgMjo1MSBBTSwgTWFy dGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb208bWFpbHRvOm1iakB0YWlsLWYuY29tPj4gd3Jv dGU6DQo+DQo+IEhpLA0KPg0KPiAiRXJpYyBWb2l0IChldm9pdCkiIDxldm9pdEBjaXNjby5jb208 bWFpbHRvOmV2b2l0QGNpc2NvLmNvbT4+IHdyb3RlOg0KPj4gVGhlIE9wZW5EYXlsaWdodCBjb250 cm9sbGVyIGhhcyBhbHJlYWR5DQo+PiBpbXBsZW1lbnRlZDxodHRwOi8vc2RudHV0b3JpYWxzLmNv bS9ob3ctdG8tYWNjZXNzLWRhdGEtaW4tbWQtc2FsLWZyb20tbW91bnQtcG9pbnQvPg0KPj4gTW91 bnQgYXMgb25lIG9mIGl0cyBtb3N0IGVzc2VudGlhbCBiYXNpYyBmdW5jdGlvbnMuICBJZiBpdCB3 YXNuJ3QgaW1wb3J0YW50LCBpdA0KPj4gd291bGRuJ3QgaGF2ZSBiZWVuIGRvbmUuDQo+Pg0KPj4N Cj4+DQo+PiBUaGUgcXVlc3Rpb24gaXMgbm90IHdoZXRoZXIgWWFuZyBNb3VudCBpcyBnb2luZyB0 byBoYXBwZW4uICBJdCBpcyB3aGV0aGVyIHRoZQ0KPj4gSUVURiB3YW50cyB0byBiZSBpbnZvbHZl ZC4NCj4NCj4gQSBjbGFyaWZpY2F0aW9uIHF1ZXN0aW9uOiBhcmUgd2UgdGFsa2luZyBhYm91dCBy ZWFkLW9ubHkgbW91bnRpbmcgb3INCj4gcmVhZC13cml0ZT8NCj4NCj4gQXMgSSBoYXZlIHdyaXR0 ZW4gYmVmb3JlLCBJIGJlbGlldmUgdGhlIG1lY2hhbmlzbSBwcm9wb3NlZCBkb2Vzbid0DQo+IHJl YWxseSB3b3JrIGZvciByZWFkLXdyaXRlIGFjY2Vzcy4NCj4NCj4NCj4NCj4gL21hcnRpbg0KPg0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBuZXRt b2QgbWFpbGluZyBsaXN0DQo+IG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3Jn Pg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1h aWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQoNCg== --_000_EF64FF31F4C4384DBCE5D513A791C2B120A5B132xmbalnx11ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5hcHBsZS10YWItc3Bhbg0KCXtt c28tc3R5bGUtbmFtZTphcHBsZS10YWItc3Bhbjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGFtIGZpbmUgd2l0aCBzcGxpdHRpbmcgcmVhZCBhbmQg d3JpdGUuJm5ic3A7IFRoZSBvbmUgY2F2ZWF0IGhlcmUgaXMgdGhhdCB3ZSB3aWxsIGV2ZW50dWFs bHkgZXhwbG9yZSBIaWdoIEF2YWlsYWJpbGl0eSBjbHVzdGVycyB3aGVyZSBhIGZlZGVyYXRpb24g b2YgTW91bnQgU2VydmVycw0KIHByb3ZpZGUgdGhlIGF1dGhvcml0YXRpdmUgZGF0YS4gJm5ic3A7 QnV0IGFueSBzb2x1dGlvbnMgY2FuIHN0aWxsIGJlIGEgc2VwYXJhdGUgdGVjaG5vbG9neSBkcmFm dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkFzIFNhbmRlciBub3RlcyBiZWxvdywgc3VjaCBIQSBjbHVzdGVyaW5nIGlz IHJ1bm5pbmcgaW4gRERTLiZuYnNwOyBCYXNlZCBvbiBoaXMgZXhwZXJpZW5jZSB3aXRoIHRoaXMg Y29kZSwgaGUgd3JvdGUgdGhlIEhpZ2ggQXZhaWxhYmlsaXR5IHBvcnRpb24gb2YgdGhlIHJlcXVp cmVtZW50cw0KIGRyYWZ0IChTZWN0aW9uIDUuNykuICZuYnNwO1NvIHdlIGNhbiBsZWFuIG9uIGhp bSBhcyB0byBob3cgaXQgbWlnaHQgYmUgZG9uZSA7LSkuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5FcmljPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow aW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFRob21hcyBELiBOYWRlYXUsIE9j dG9iZXIgMzEsIDIwMTQgMTA6MDMgQU08YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxl LXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgPC9zcGFuPlRoYXQgaXMgcGFydCBvZiB3aHkgSSBhbSBhc2tpbmcgaWYgaXQgbWFr ZXMgc2Vuc2UgdG8gc2VwYXJhdGUgdGhpbmdzLiBJbiB0aGUgZmlyc3QgY2FzZSwgdGhlIHJlYWQt b25seSBtZXRob2QgZG9lcyBmaXQgaW4gdGhlIGN1cnJlbnQgYXJjaGl0ZWN0dXJlIGFuZCBtaWdo dCBiZSBlYXNpZXIgdG8gcHJvZ3Jlc3MgYXQgdGhlIG1vbWVudC4NCiBUaGUgb3RoZXIgcGFydCBt aWdodCBuZWVkIHRvIGJlIGluIOKAnFlhbmcgMi4w4oCdLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFu PuKAlFRvbTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiBPY3QgMzEsIDIwMTQ6OTo1NSBBTSwgYXQgOTo1NSBBTSwgU2FuZGVyIE1lcnRl bnMgJmx0OzxhIGhyZWY9Im1haWx0bzpzYW5kZXIubWVydGVuc0BwcmlzbXRlY2guY29tIj5zYW5k ZXIubWVydGVuc0BwcmlzbXRlY2guY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBsZWFzZSBub3RlIHRoYXQgaXQgaXMgYXQgdGhlIHZlcnkg bGVhc3Qgbm90IHRlY2huaWNhbGx5IHVuZmVhc2libGUgdG8gaGF2ZSBib3RoIHJlYWQtb25seSBh bmQgcmVhZC13cml0ZSBiZWhhdmlvciBpbiB0aGUgcHJvcG9zZWQgYXJjaGl0ZWN0dXJlLiBBcyBh biBleGFtcGxlLCBhbnkgaW1wbGVtZW50YXRpb24gb2YgT01HLUREUyBhbGxvd3MgZm9yIHRoaXMg YmVoYXZpb3IuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoZSBzZW1hbnRpY3MgY2FuIGJlIHF1ZXN0aW9uYWJsZSBpbiBhIGNhc2Ugd2hlcmUg dGhlcmUgaXMgb25lIGNsZWFyIG93bmVyIG9mIHRoZSBkYXRhLCB3aXRoIHBlcmhhcHMgdGhlIG5v dGFibGUgZXhjZXB0aW9uIG9mIG11bHRpcGxlIHJlZHVuZGFudCBzZXJ2ZXJzLiBGb3IgdGhlIGxh dHRlciB1c2VjYXNlIChkZXBsb3llZCkgcGF0dGVybnMgYWxyZWFkeSBleGlzdCB0aGF0IGVmZmVj dGl2ZWx5IGhhbmRsZSB0aGVzZQ0KIHNjZW5hcmlvcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2FuZGVyPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAzMSBPY3RvYmVyIDIwMTQgMDk6MzcsIFRo b21hcyBELiBOYWRlYXUgJmx0OzxhIGhyZWY9Im1haWx0bzp0bmFkZWF1QGx1Y2lkdmlzaW9uLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPnRuYWRlYXVAbHVjaWR2aXNpb24uY29tPC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgU3BlYWtpbmcgYXMgY2hhaXIsPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IElzIGl0IHdvcnRoIHNlcGFyYXRpbmcgb3V0IHItbyBhbmQgci13IGJl aGF2aW9yIHRvIGhlbHAgbW92ZSB0aGUgY29udmVyc2F0aW9uIGZvcndhcmQ/PGJyPg0KPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC0tVG9tPGJyPg0KPGJyPg0KPGJyPg0KJmd0OyBP biBPY3QgMzEsIDIwMTQ6Mjo1MSBBTSwgYXQgMjo1MSBBTSwgTWFydGluIEJqb3JrbHVuZCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOm1iakB0YWlsLWYuY29tIj5tYmpAdGFpbC1mLmNvbTwvYT4mZ3Q7IHdy b3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7IEhpLDxicj4NCiZndDs8YnI+DQomZ3Q7ICZxdW90O0Vy aWMgVm9pdCAoZXZvaXQpJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86ZXZvaXRAY2lzY28uY29t Ij5ldm9pdEBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyBUaGUgT3BlbkRh eWxpZ2h0IGNvbnRyb2xsZXIgaGFzIGFscmVhZHk8YnI+DQomZ3Q7Jmd0OyBpbXBsZW1lbnRlZCZs dDs8YSBocmVmPSJodHRwOi8vc2RudHV0b3JpYWxzLmNvbS9ob3ctdG8tYWNjZXNzLWRhdGEtaW4t bWQtc2FsLWZyb20tbW91bnQtcG9pbnQvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3NkbnR1dG9y aWFscy5jb20vaG93LXRvLWFjY2Vzcy1kYXRhLWluLW1kLXNhbC1mcm9tLW1vdW50LXBvaW50Lzwv YT4mZ3Q7PGJyPg0KJmd0OyZndDsgTW91bnQgYXMgb25lIG9mIGl0cyBtb3N0IGVzc2VudGlhbCBi YXNpYyBmdW5jdGlvbnMuJm5ic3A7IElmIGl0IHdhc24ndCBpbXBvcnRhbnQsIGl0PGJyPg0KJmd0 OyZndDsgd291bGRuJ3QgaGF2ZSBiZWVuIGRvbmUuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgVGhlIHF1ZXN0aW9uIGlzIG5vdCB3aGV0aGVy IFlhbmcgTW91bnQgaXMgZ29pbmcgdG8gaGFwcGVuLiZuYnNwOyBJdCBpcyB3aGV0aGVyIHRoZTxi cj4NCiZndDsmZ3Q7IElFVEYgd2FudHMgdG8gYmUgaW52b2x2ZWQuPGJyPg0KJmd0Ozxicj4NCiZn dDsgQSBjbGFyaWZpY2F0aW9uIHF1ZXN0aW9uOiBhcmUgd2UgdGFsa2luZyBhYm91dCByZWFkLW9u bHkgbW91bnRpbmcgb3I8YnI+DQomZ3Q7IHJlYWQtd3JpdGU/PGJyPg0KJmd0Ozxicj4NCiZndDsg QXMgSSBoYXZlIHdyaXR0ZW4gYmVmb3JlLCBJIGJlbGlldmUgdGhlIG1lY2hhbmlzbSBwcm9wb3Nl ZCBkb2Vzbid0PGJyPg0KJmd0OyByZWFsbHkgd29yayBmb3IgcmVhZC13cml0ZSBhY2Nlc3MuPGJy Pg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAvbWFydGluPGJyPg0KJmd0Ozxi cj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQomZ3Q7IG5ldG1vZCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpu ZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8L2E+PGJyPg0K Jmd0Ozxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KbmV0bW9kIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpuZXRt b2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPC9hPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_EF64FF31F4C4384DBCE5D513A791C2B120A5B132xmbalnx11ciscoc_-- From nobody Fri Oct 31 12:46:15 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 481E31A00DB for ; Fri, 31 Oct 2014 12:46: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 I0DQXeqDhI7U for ; Fri, 31 Oct 2014 12:46:08 -0700 (PDT) Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B4DD1A0199 for ; Fri, 31 Oct 2014 12:46:07 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id s18so2215432lam.14 for ; Fri, 31 Oct 2014 12:46:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dmIUBIV9p/nIaC+S1L50dpZ8r/TAH9pnRiEwgeozizc=; b=fBfKZo4KIgPEYSK8Y6CHifoGx382hWylecEbUf9LNiUDvvYEvcr+Lhc//1dq5ZOlv7 hRbaWNOdTniQZOK8sXX7C77oIBq5AQr3y+HNkyl35MeIDWT1zbxKJoqRECIUxNowZT4B lYiNQvoitGEthKJQYcsMuScWtG61sxVl8P+PyCo3SZKi42Px0pma0zEMDvLzIl8/pfiF 3yDL34c1iVQyvecdwUOa0RIfKqPuxm9KlyMKYNQnauThNycO4ecfL0H9pWUYhqbvGv1A EU1hI2+cREv6AvTsols1Vf6aRobaYk194ewGxVEWd10O0Yw2BE+4XMtOns6Wt+vxW4Qz TRmg== X-Gm-Message-State: ALoCoQkTWAepqao9kX36QRG6OorsYEdUB6Rou+xvORcPXYMDRIrkjKqM2KbQtfpdgkf66ChgMCDG MIME-Version: 1.0 X-Received: by 10.112.54.229 with SMTP id m5mr28865778lbp.11.1414784765472; Fri, 31 Oct 2014 12:46:05 -0700 (PDT) Received: by 10.112.130.234 with HTTP; Fri, 31 Oct 2014 12:46:05 -0700 (PDT) In-Reply-To: References: <20141031.075132.208810580.mbj@tail-f.com> <84CC7AF8-E068-4100-A3CE-578B10951F91@lucidvision.com> <9A852290-B831-4DDC-9239-B695145C8328@lucidvision.com> Date: Fri, 31 Oct 2014 15:46:05 -0400 Message-ID: From: Sander Mertens To: "Eric Voit (evoit)" Content-Type: multipart/alternative; boundary=001a11c3fd1c614ba30506bd3f50 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/9hltvmTdlBqQzSvXzR-nf4HMgzI Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG model containing both device and domain config X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 31 Oct 2014 19:46:11 -0000 --001a11c3fd1c614ba30506bd3f50 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 31 October 2014 13:44, Eric Voit (evoit) wrote: > I am fine with splitting read and write. The one caveat here is that we > will eventually explore High Availability clusters where a federation of > Mount Servers provide the authoritative data. But any solutions can stil= l > be a separate technology draft. > I agree. To facilitate the discussion we can reason about one "logical" server, while in reality many "physical" servers may exist. > > > As Sander notes below, such HA clustering is running in DDS. Based on hi= s > experience with this code, he wrote the High Availability portion of the > requirements draft (Section 5.7). So we can lean on him as to how it mig= ht > be done ;-). > > > Indeed :-) We have deployed systems (in particular, an air-traffic control management system) where we showed that (eventual) consistency can be achieved in a partitioned system with high requirements on availability (AP). It should be noted that the complexity involved in achieving high availability was abstracted from the application code by the (DDS) infrastructure. Configuration of the system was also relatively straightforward since most of the system could be auto-discovered. > Eric > > > > *From:* Thomas D. Nadeau, October 31, 2014 10:03 AM > > That is part of why I am asking if it makes sense to separate > things. In the first case, the read-only method does fit in the current > architecture and might be easier to progress at the moment. The other par= t > might need to be in =E2=80=9CYang 2.0=E2=80=9D. > > > > =E2=80=94Tom > > > > > > On Oct 31, 2014:9:55 AM, at 9:55 AM, Sander Mertens < > sander.mertens@prismtech.com> wrote: > > > > Hi, > > > > Please note that it is at the very least not technically unfeasible to > have both read-only and read-write behavior in the proposed architecture. > As an example, any implementation of OMG-DDS allows for this behavior. > > > > The semantics can be questionable in a case where there is one clear owne= r > of the data, with perhaps the notable exception of multiple redundant > servers. For the latter usecase (deployed) patterns already exist that > effectively handle these scenarios. > > > > Cheers, > > Sander > > > > On 31 October 2014 09:37, Thomas D. Nadeau > wrote: > > > Speaking as chair, > > Is it worth separating out r-o and r-w behavior to help move the > conversation forward? > > --Tom > > > > On Oct 31, 2014:2:51 AM, at 2:51 AM, Martin Bjorklund > wrote: > > > > Hi, > > > > "Eric Voit (evoit)" wrote: > >> The OpenDaylight controller has already > >> implemented< > http://sdntutorials.com/how-to-access-data-in-md-sal-from-mount-point/> > >> Mount as one of its most essential basic functions. If it wasn't > important, it > >> wouldn't have been done. > >> > >> > >> > >> The question is not whether Yang Mount is going to happen. It is > whether the > >> IETF wants to be involved. > > > > A clarification question: are we talking about read-only mounting or > > read-write? > > > > As I have written before, I believe the mechanism proposed doesn't > > really work for read-write access. > > > > > > > > /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 > > > > > --001a11c3fd1c614ba30506bd3f50 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 31 October 2014 13:44, E= ric Voit (evoit) <evoit@cisco.com> wrote:

I am fine with splitting = read and write.=C2=A0 The one caveat here is that we will eventually explor= e High Availability clusters where a federation of Mount Servers provide the authoritative data.=C2=A0 But any solutions can still be a sep= arate technology draft.


<= div>I agree. To facilitate the discussion we can reason about one "log= ical" server, while in reality many "physical" servers may e= xist.
=C2=A0

=C2=A0

As Sander notes below, su= ch HA clustering is running in DDS.=C2=A0 Based on his experience with this= code, he wrote the High Availability portion of the requirements draft (Section 5.7).=C2=A0 So we can lean on him as to how it might be don= e ;-).

=C2=A0

<= /div>

Indeed :-) We have deployed sys= tems (in particular, an air-traffic control management system) where we sho= wed that (eventual) consistency can be achieved in a partitioned system wit= h high requirements on availability (AP).

It shoul= d be noted that the complexity involved in achieving high availability was = abstracted from the application code by the (DDS) infrastructure. Configura= tion of the system was also relatively straightforward since most of the sy= stem could be auto-discovered.
=C2=A0

Eric=

=C2=A0

From: Thomas D= . Nadeau, October 31, 2014 10:03 AM

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 That is part of why I am asking if it makes sense to separ= ate things. In the first case, the read-only method does fit in the current= architecture and might be easier to progress at the moment. The other part might need to be in =E2=80=9CYang 2.0=E2=80=9D.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 =E2=80=94Tom

=C2=A0

=C2=A0

On Oct 31, 2014:9:55 AM, at 9:55 AM, Sander Mertens = <sande= r.mertens@prismtech.com> wrote:

=C2=A0

Hi,

=C2=A0

Please note that it is at the very least not technic= ally unfeasible to have both read-only and read-write behavior in the propo= sed architecture. As an example, any implementation of OMG-DDS allows for t= his behavior.

=C2=A0

The semantics can be questionable in a case where th= ere is one clear owner of the data, with perhaps the notable exception of m= ultiple redundant servers. For the latter usecase (deployed) patterns alrea= dy exist that effectively handle these scenarios.

=C2=A0

Cheers,

Sander

=C2=A0

On 31 October 2014 09:37, Thomas D. Nadeau <tnadeau@lucidvision= .com> wrote:


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Speaking as chair,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Is it worth separating out r-o and r-w behavior= to help move the conversation forward?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 --Tom


> On Oct 31, 2014:2:51 AM, at 2:51 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> Hi,
>
> "Eric Voit (evoit)" <evoit@cisco.com> wrote:
>> The OpenDaylight controller has already
>> implemented<http://sdntutorials.com/h= ow-to-access-data-in-md-sal-from-mount-point/>
>> Mount as one of its most essential basic functions.=C2=A0 If it wa= sn't important, it
>> wouldn't have been done.
>>
>>
>>
>> The question is not whether Yang Mount is going to happen.=C2=A0 I= t is whether the
>> IETF wants to be involved.
>
> A clarification question: are we talking about read-only mounting or > read-write?
>
> As I have written before, I believe the mechanism proposed doesn't=
> really work for read-write access.
>
>
>
> /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

=C2=A0

=C2=A0


--001a11c3fd1c614ba30506bd3f50--