From nobody Sun May 1 00:37:51 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2230212B02B for ; Sun, 1 May 2016 00:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDf038zZc_j9 for ; Sun, 1 May 2016 00:37:47 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C1FA12B00A for ; Sun, 1 May 2016 00:37:47 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B5589ADE; Sun, 1 May 2016 09:37:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 7qwjJE2BvqHL; Sun, 1 May 2016 09:37: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; Sun, 1 May 2016 09:37:44 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id AD26D2004E; Sun, 1 May 2016 09:37:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id O-eHot7MtYx7; Sun, 1 May 2016 09:37:43 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 69DD82004A; Sun, 1 May 2016 09:37:37 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7EA4C3AC07BB; Sun, 1 May 2016 09:37:36 +0200 (CEST) Date: Sun, 1 May 2016 09:37:36 +0200 From: Juergen Schoenwaelder To: "Ersue, Mehmet (Nokia - DE/Munich)" Message-ID: <20160501073735.GA30851@elstar.local> Mail-Followup-To: "Ersue, Mehmet (Nokia - DE/Munich)" , Netconf , "jonathan@hansfords.net" , "rex@cisco.com" , EXT Benoit Claise References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "rex@cisco.com" , Netconf Subject: Re: [Netconf] IPR Poll for draft-ietf-netconf-restconf-12 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2016 07:37:50 -0000 What is a registered contributor? Frankly, we draw somewhat arbitrary lines here. That said, I think I do understand the IETF IPR rules if that was the question. /js On Sun, May 01, 2016 at 12:15:16AM +0000, Ersue, Mehmet (Nokia - DE/Munich) wrote: > Hi Jonathan, Juergen, Rex, > > AFAICS you did not respond to the request below. > As registered contributor to the RESTCONF draft we do require your IPR statement. > > > If you are listed as a document author or contributor (CCed) please respond to this email ON NETCONF MAILLIST explicitly regardless of whether or not you are aware of > > any relevant IPR. The document will not advance to the next stage until a response has been received from _each author and contributor_. > > I hope you will respond soon and we can start the publication process officially. > > Thanks. > > Mehmet > > From: "Ersue, Mehmet (Nokia - DE/Munich)" > > Date: Sunday, April 24, 2016 at 5:49 PM > To: "netconf@ietf.org" > > Cc: EXT Ladislav Lhotka >, Juergen Schoenwaelder >, "rwilton@cisco.com" >, "jonathan@hansfords.net" >, "rex@cisco.com" >, EXT Andy Bierman >, Martin Bjorklund >, Kent Watsen > > Subject: IPR Poll for draft-ietf-netconf-restconf-12 > > Dear Authors and Contributors of RESTCONF Draft, > Dear WG Members, > > please state on the maillist clearly whether you own or are aware of any IPR that applies to draft-ietf-netconf-restconf-12.txt. > For the opposite case, please state also on the maillist clearly if you don’t own or are not aware of any IPR that applies to the draft-ietf-netconf-restconf. > > If you own or are aware of any IPR that applies to the draft-ietf-netconf-restconf please clarify whether > this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). > If not please do so asap. > > If you are listed as a document author or contributor (CCed)please respond to this email ON NETCONF MAILLIST explicitly regardless of whether or not you are aware of any relevant IPR. The document will not advance to the next stage until a response has been received from _each authorand contributor_. > > If you are not listed as an author or contributor but are on NETCONF WG maillist, then please explicitly respond if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. > > Thank you for kind support. > > Regards, > Mehmet & Mahesh > -- 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 May 1 00:42:33 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9160312B048; Sun, 1 May 2016 00:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FyzgTeA0ADzp; Sun, 1 May 2016 00:42:29 -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 6180712B00A; Sun, 1 May 2016 00:42: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 139B6A53; Sun, 1 May 2016 09:42: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 g4B9JYcRt18V; Sun, 1 May 2016 09:41:56 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sun, 1 May 2016 09:42:27 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 02A2D2004A; Sun, 1 May 2016 09:42: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 VwOi5asD-Nsq; Sun, 1 May 2016 09:42: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 7B0C420047; Sun, 1 May 2016 09:42:24 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6DDB93AC0848; Sun, 1 May 2016 09:42:24 +0200 (CEST) Date: Sun, 1 May 2016 09:42:24 +0200 From: Juergen Schoenwaelder To: Mahesh Jethanandani Message-ID: <20160501074224.GB30851@elstar.local> Mail-Followup-To: Mahesh Jethanandani , "Acee Lindem (acee)" , "draft-ietf-rtgwg-keychain@ietf.org" , Routing WG , "netconf@ietf.org" References: <20160329.212556.1290892363387952983.mbj@tail-f.com> <3D60808E-EB76-4BE9-8281-B91B4FD83527@juniper.net> <021201d191b1$757fbe40$4001a8c0@gateway.2wire.net> <64FFAE09-4DF0-4D87-ADCF-2A319DB4F684@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: Routing WG , "Acee Lindem \(acee\)" , "netconf@ietf.org" , "draft-ietf-rtgwg-keychain@ietf.org" Subject: Re: [Netconf] mbj review of draft-ietf-netconf-restconf-server-model-09 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2016 07:42:31 -0000 I have briefly looked at the abstract / intro of both documents and I am not sure I got from this why we do have two keychain models. Perhaps both documents should be send to the security area as input for a joint keychain data model? /js On Sat, Apr 30, 2016 at 03:10:38PM -0700, Mahesh Jethanandani wrote: > That or we could also rename it to protocol-key-chain to disambiguate it > from system-key-chain. > > On Sat, Apr 30, 2016 at 11:40 AM, Acee Lindem (acee) wrote: > > > So hopefully we’ve put the issue of combining the module to bed for good… > > If look at the date nodes for these two models, it is patently clear that > > these serve two different purposes. > > > > What about the naming issue? I got a comment that I should take “routing-“ > > back out due to the fact that this is what that these key-chains can be > > used for many non-routing purposes. For example, BFD - > > http://www.juniper.net/documentation/en_US/junos14.2/topics/reference/configuration-statement/key-chain-edit-security-authentication-key-chains.html > > > > Thanks, > > Acee > > > > From: rtgwg on behalf of Acee Lindem < > > acee@cisco.com> > > Date: Monday, April 18, 2016 at 6:04 PM > > To: Mahesh Jethanandani > > Cc: Martin Bjorklund , Tom Petch , " > > netconf@ietf.org" , "draft-ietf-rtgwg-keychain@ietf.org" > > , Routing WG > > Subject: Re: [Netconf] mbj review of > > draft-ietf-netconf-restconf-server-model-09 > > > > > > > > From: Mahesh Jethanandani > > Date: Monday, April 18, 2016 at 4:43 PM > > To: Acee Lindem > > Cc: Kent Watsen , Tom Petch , > > Martin Bjorklund , "netconf@ietf.org" , > > Routing WG , "draft-ietf-rtgwg-keychain@ietf.org" < > > draft-ietf-rtgwg-keychain@ietf.org> > > Subject: Re: [Netconf] mbj review of > > draft-ietf-netconf-restconf-server-model-09 > > > > > > On Apr 18, 2016, at 10:25 AM, Acee Lindem (acee) wrote: > > > > I did get some negative feedback with respect to adding “routing-“ to the > > model name since key chains are used for other non-routing applications as > > well. > > > > > > One of those non-routing protocols is BFD. I am fine if the model is > > called protocol-key-chain, but I wonder what happens the next entity > > needing key-chain is not a protocol. > > > > The bigger question in my mind is, are these really different types of > > key-chains models, or are we talking about one key-chain model? > > > > > > The rtgwg key chain model is the one we all know and love associated with > > the graceful rollover of configurable keys. The netconf model is list of > > certificates for a public key. Please look at the information content of > > the two models. I hope I don’t have to answer this question again ;^) > > > > Acee > > > > > > > > > > > > Mahesh Jethanandani > > mjethanandani@gmail.com > > > > > > > > > > > -- > Mahesh Jethanandani > mjethanandani@gmail.com > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- 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 May 1 06:38:18 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7EBF12D0C0; Sun, 1 May 2016 06:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjiYXoBSd9TZ; Sun, 1 May 2016 06:38:15 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0654E12D0B9; Sun, 1 May 2016 06:38:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5838; q=dns/txt; s=iport; t=1462109895; x=1463319495; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=h8jB3BFHJp44V18KtxxxDd/eBJzi41LqIu7dEnwGifY=; b=KWMDgZjJ0CeDvjv2E/EBv6/ZGGIN79UQL7Td9gVo6/7Vypzm6rRYLJYi m9YGjscjlxRx4qv3LkgP9gas+5xsVpRPxOEHKVeAymtG4TnJcvJwVjXfq azPn/MurkmJO/MLF5i4TF43FpBkiUtjRuGsEjRdiirKgsIsd/XD+QVrCD s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAgAWBiZX/5JdJa1bA4M4U30Grg+LY?= =?us-ascii?q?QENgXYXDYUiSgIcfTgUAQEBAQEBAWUnhEEBAQEEAQEBIBE6Cw4CAgEIDgIBAwE?= =?us-ascii?q?CAQICJgICAhkGBgsVCAgCBAENBYgVAxIOsyGLWg2ETgEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBARUEeIlxgkGBZhYXCiaCOYJWBY1XigwxAYwggXeBZ4RNiF2HUYdfAR4?= =?us-ascii?q?BAUKCBRuBS2wBhmV/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,562,1454976000"; d="scan'208";a="267490900" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 May 2016 13:38:13 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u41DcD3Q008205 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 1 May 2016 13:38:13 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 1 May 2016 09:38:12 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Sun, 1 May 2016 09:38:12 -0400 From: "Acee Lindem (acee)" To: Juergen Schoenwaelder , "Mahesh Jethanandani" Thread-Topic: [Netconf] mbj review of draft-ietf-netconf-restconf-server-model-09 Thread-Index: AQHRifX44uk/iivOuEmrTCpBJDXsvZ99sTmAgAKen+KAD4/+AIAAOu0AgAB6U4D//9OoAIASoseAgAB93QCAAJ/AAIAAIFsA Date: Sun, 1 May 2016 13:38:12 +0000 Message-ID: References: <20160329.212556.1290892363387952983.mbj@tail-f.com> <3D60808E-EB76-4BE9-8281-B91B4FD83527@juniper.net> <021201d191b1$757fbe40$4001a8c0@gateway.2wire.net> <64FFAE09-4DF0-4D87-ADCF-2A319DB4F684@gmail.com> <20160501074224.GB30851@elstar.local> In-Reply-To: <20160501074224.GB30851@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: RTGWG , "netconf@ietf.org" , "draft-ietf-rtgwg-keychain@ietf.org" Subject: Re: [Netconf] mbj review of draft-ietf-netconf-restconf-server-model-09 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2016 13:38:17 -0000 DQoNCk9uIDUvMS8xNiwgMzo0MiBBTSwgIkp1ZXJnZW4gU2Nob2Vud2FlbGRlciINCjxqLnNjaG9l bndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+IHdyb3RlOg0KDQo+SSBoYXZlIGJyaWVmbHkg bG9va2VkIGF0IHRoZSBhYnN0cmFjdCAvIGludHJvIG9mIGJvdGggZG9jdW1lbnRzIGFuZCBJDQo+ YW0gbm90IHN1cmUgSSBnb3QgZnJvbSB0aGlzIHdoeSB3ZSBkbyBoYXZlIHR3byBrZXljaGFpbiBt b2RlbHMuIFBlcmhhcHMNCj5ib3RoIGRvY3VtZW50cyBzaG91bGQgYmUgc2VuZCB0byB0aGUgc2Vj dXJpdHkgYXJlYSBhcyBpbnB1dCBmb3IgYSBqb2ludA0KPmtleWNoYWluIGRhdGEgbW9kZWw/DQoN ClBsZWFzZSBsb29rIGF0IHRoZSBkYXRhIG5vZGVzIGluIHRoZSB0d28gbW9kZWxzIC0gb25lIGlz IGFib3V0IGtleXMgYW5kDQp0aGUgb3RoZXIgaXMgYWJvdXQgY2VydGlmaWNhdGVzLg0KDQpBdCBs ZWFzdCBmb3IgdGhlIElFVEYga2V5LWNoYWluIGluIHRoZSByb3V0aW5nIFdHLCB0aGVyZSBpcyBz aWduaWZpY2FudA0KcHJlY2VkZW5jZSBhY3Jvc3MgTUFOWSBuZXR3b3JraW5nIHByb2R1Y3RzLiBS ZXByZXNlbnRhdGl2ZXMgZnJvbSBDaXNjbywNCkp1bmlwZXIsIE5va2lhLCBFcmljc3NvbiwgYW5k IEh1YXdlaSBwYXJ0aWNpcGF0ZWQgaW4gdGhlIGRlc2lnbiB0ZWFtIGFzDQphbGwgdGhlc2UgdmVu ZG9ycyBoYXZlIGltcGxlbWVudGF0aW9ucy4NCg0KQWNlZSANCg0KDQo+DQo+L2pzDQo+DQo+T24g U2F0LCBBcHIgMzAsIDIwMTYgYXQgMDM6MTA6MzhQTSAtMDcwMCwgTWFoZXNoIEpldGhhbmFuZGFu aSB3cm90ZToNCj4+IFRoYXQgb3Igd2UgY291bGQgYWxzbyByZW5hbWUgaXQgdG8gcHJvdG9jb2wt a2V5LWNoYWluIHRvIGRpc2FtYmlndWF0ZSBpdA0KPj4gZnJvbSBzeXN0ZW0ta2V5LWNoYWluLg0K Pj4gDQo+PiBPbiBTYXQsIEFwciAzMCwgMjAxNiBhdCAxMTo0MCBBTSwgQWNlZSBMaW5kZW0gKGFj ZWUpIDxhY2VlQGNpc2NvLmNvbT4NCj4+d3JvdGU6DQo+PiANCj4+ID4gU28gaG9wZWZ1bGx5IHdl 4oCZdmUgcHV0IHRoZSBpc3N1ZSBvZiBjb21iaW5pbmcgdGhlIG1vZHVsZSB0byBiZWQgZm9yDQo+ Pmdvb2TigKYNCj4+ID4gSWYgbG9vayBhdCB0aGUgZGF0ZSBub2RlcyBmb3IgdGhlc2UgdHdvIG1v ZGVscywgaXQgaXMgcGF0ZW50bHkgY2xlYXINCj4+dGhhdA0KPj4gPiB0aGVzZSBzZXJ2ZSB0d28g ZGlmZmVyZW50IHB1cnBvc2VzLg0KPj4gPg0KPj4gPiBXaGF0IGFib3V0IHRoZSBuYW1pbmcgaXNz dWU/IEkgZ290IGEgY29tbWVudCB0aGF0IEkgc2hvdWxkIHRha2UNCj4+4oCccm91dGluZy3igJwN Cj4+ID4gYmFjayBvdXQgZHVlIHRvIHRoZSBmYWN0IHRoYXQgdGhpcyBpcyB3aGF0IHRoYXQgdGhl c2Uga2V5LWNoYWlucyBjYW4NCj4+YmUNCj4+ID4gdXNlZCBmb3IgbWFueSBub24tcm91dGluZyBw dXJwb3Nlcy4gRm9yIGV4YW1wbGUsIEJGRCAtDQo+PiA+IA0KPj5odHRwOi8vd3d3Lmp1bmlwZXIu bmV0L2RvY3VtZW50YXRpb24vZW5fVVMvanVub3MxNC4yL3RvcGljcy9yZWZlcmVuY2UvY29uDQo+ PmZpZ3VyYXRpb24tc3RhdGVtZW50L2tleS1jaGFpbi1lZGl0LXNlY3VyaXR5LWF1dGhlbnRpY2F0 aW9uLWtleS1jaGFpbnMuaHQNCj4+bWwNCj4+ID4NCj4+ID4gVGhhbmtzLA0KPj4gPiBBY2VlDQo+ PiA+DQo+PiA+IEZyb206IHJ0Z3dnIDxydGd3Zy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYg b2YgQWNlZSBMaW5kZW0gPA0KPj4gPiBhY2VlQGNpc2NvLmNvbT4NCj4+ID4gRGF0ZTogTW9uZGF5 LCBBcHJpbCAxOCwgMjAxNiBhdCA2OjA0IFBNDQo+PiA+IFRvOiBNYWhlc2ggSmV0aGFuYW5kYW5p IDxtamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4NCj4+ID4gQ2M6IE1hcnRpbiBCam9ya2x1bmQgPG1i akB0YWlsLWYuY29tPiwgVG9tIFBldGNoDQo+PjxpZXRmY0BidGNvbm5lY3QuY29tPiwgIg0KPj4g PiBuZXRjb25mQGlldGYub3JnIiA8bmV0Y29uZkBpZXRmLm9yZz4sDQo+PiJkcmFmdC1pZXRmLXJ0 Z3dnLWtleWNoYWluQGlldGYub3JnIg0KPj4gPiA8ZHJhZnQtaWV0Zi1ydGd3Zy1rZXljaGFpbkBp ZXRmLm9yZz4sIFJvdXRpbmcgV0cgPHJ0Z3dnQGlldGYub3JnPg0KPj4gPiBTdWJqZWN0OiBSZTog W05ldGNvbmZdIG1iaiByZXZpZXcgb2YNCj4+ID4gZHJhZnQtaWV0Zi1uZXRjb25mLXJlc3Rjb25m LXNlcnZlci1tb2RlbC0wOQ0KPj4gPg0KPj4gPg0KPj4gPg0KPj4gPiBGcm9tOiBNYWhlc2ggSmV0 aGFuYW5kYW5pIDxtamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4NCj4+ID4gRGF0ZTogTW9uZGF5LCBB cHJpbCAxOCwgMjAxNiBhdCA0OjQzIFBNDQo+PiA+IFRvOiBBY2VlIExpbmRlbSA8YWNlZUBjaXNj by5jb20+DQo+PiA+IENjOiBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldD4sIFRvbSBQ ZXRjaA0KPj48aWV0ZmNAYnRjb25uZWN0LmNvbT4sDQo+PiA+IE1hcnRpbiBCam9ya2x1bmQgPG1i akB0YWlsLWYuY29tPiwgIm5ldGNvbmZAaWV0Zi5vcmciDQo+PjxuZXRjb25mQGlldGYub3JnPiwN Cj4+ID4gUm91dGluZyBXRyA8cnRnd2dAaWV0Zi5vcmc+LCAiZHJhZnQtaWV0Zi1ydGd3Zy1rZXlj aGFpbkBpZXRmLm9yZyIgPA0KPj4gPiBkcmFmdC1pZXRmLXJ0Z3dnLWtleWNoYWluQGlldGYub3Jn Pg0KPj4gPiBTdWJqZWN0OiBSZTogW05ldGNvbmZdIG1iaiByZXZpZXcgb2YNCj4+ID4gZHJhZnQt aWV0Zi1uZXRjb25mLXJlc3Rjb25mLXNlcnZlci1tb2RlbC0wOQ0KPj4gPg0KPj4gPg0KPj4gPiBP biBBcHIgMTgsIDIwMTYsIGF0IDEwOjI1IEFNLCBBY2VlIExpbmRlbSAoYWNlZSkgPGFjZWVAY2lz Y28uY29tPg0KPj53cm90ZToNCj4+ID4NCj4+ID4gSSBkaWQgZ2V0IHNvbWUgbmVnYXRpdmUgZmVl ZGJhY2sgd2l0aCByZXNwZWN0IHRvIGFkZGluZyDigJxyb3V0aW5nLeKAnCB0bw0KPj50aGUNCj4+ ID4gbW9kZWwgbmFtZSBzaW5jZSBrZXkgY2hhaW5zIGFyZSB1c2VkIGZvciBvdGhlciBub24tcm91 dGluZw0KPj5hcHBsaWNhdGlvbnMgYXMNCj4+ID4gd2VsbC4NCj4+ID4NCj4+ID4NCj4+ID4gT25l IG9mIHRob3NlIG5vbi1yb3V0aW5nIHByb3RvY29scyBpcyBCRkQuIEkgYW0gZmluZSBpZiB0aGUg bW9kZWwgaXMNCj4+ID4gY2FsbGVkIHByb3RvY29sLWtleS1jaGFpbiwgYnV0IEkgd29uZGVyIHdo YXQgaGFwcGVucyB0aGUgbmV4dCBlbnRpdHkNCj4+ID4gbmVlZGluZyBrZXktY2hhaW4gaXMgbm90 IGEgcHJvdG9jb2wuDQo+PiA+DQo+PiA+IFRoZSBiaWdnZXIgcXVlc3Rpb24gaW4gbXkgbWluZCBp cywgYXJlIHRoZXNlIHJlYWxseSBkaWZmZXJlbnQgdHlwZXMgb2YNCj4+ID4ga2V5LWNoYWlucyBt b2RlbHMsIG9yIGFyZSB3ZSB0YWxraW5nIGFib3V0IG9uZSBrZXktY2hhaW4gbW9kZWw/DQo+PiA+ DQo+PiA+DQo+PiA+IFRoZSBydGd3ZyBrZXkgY2hhaW4gbW9kZWwgaXMgdGhlIG9uZSB3ZSBhbGwg a25vdyBhbmQgbG92ZSBhc3NvY2lhdGVkDQo+PndpdGgNCj4+ID4gdGhlIGdyYWNlZnVsIHJvbGxv dmVyIG9mIGNvbmZpZ3VyYWJsZSBrZXlzLiBUaGUgbmV0Y29uZiBtb2RlbCBpcyBsaXN0DQo+Pm9m DQo+PiA+IGNlcnRpZmljYXRlcyBmb3IgYSBwdWJsaWMga2V5LiBQbGVhc2UgbG9vayBhdCB0aGUg aW5mb3JtYXRpb24gY29udGVudA0KPj5vZg0KPj4gPiB0aGUgdHdvIG1vZGVscy4gSSBob3BlIEkg ZG9u4oCZdCBoYXZlIHRvIGFuc3dlciB0aGlzIHF1ZXN0aW9uIGFnYWluIDteKQ0KPj4gPg0KPj4g PiBBY2VlDQo+PiA+DQo+PiA+DQo+PiA+DQo+PiA+DQo+PiA+DQo+PiA+IE1haGVzaCBKZXRoYW5h bmRhbmkNCj4+ID4gbWpldGhhbmFuZGFuaUBnbWFpbC5jb20NCj4+ID4NCj4+ID4NCj4+ID4NCj4+ ID4NCj4+IA0KPj4gDQo+PiAtLSANCj4+IE1haGVzaCBKZXRoYW5hbmRhbmkNCj4+IG1qZXRoYW5h bmRhbmlAZ21haWwuY29tDQo+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4gTmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4+IE5ldGNvbmZAaWV0Zi5v cmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0KPg0K Pg0KPi0tIA0KPkp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNp dHkgQnJlbWVuIGdHbWJIDQo+UGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMg UmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KPkZheDogICArNDkgNDIxIDIwMCAzMTAz ICAgICAgICAgPGh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0KDQo= From nobody Sun May 1 07:03:18 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3558C12D0F4; Sun, 1 May 2016 07:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPwv6bvyNeBx; Sun, 1 May 2016 07:03:11 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8262212D0E5; Sun, 1 May 2016 07:03:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21073; q=dns/txt; s=iport; t=1462111391; x=1463320991; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=xBxA1kqUsUqDUvZFxWGvcxxdDhxw3puYLwYy08S+Lcc=; b=PIYzi3fgxBLu7QdzEgFsMvnGeVsQHjiRV+9yc3FwiMtixevcfh5bVWYW iQDV+pJajlq6/u6Fok0O2ehdh9PluhYo+7PVyFa1qAZB+AVCbMxbVNOXV 1EH40SuJ26C7kiwPiDpaeKA06Mt26J1E1lki+Ccjwbx8jx2r6Fp0PRELU 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A0AgAvDCZX/4YNJK1egmxMU30Grg+Gb?= =?us-ascii?q?oRzAQ2Bdh2FKUoCHH44FAEBAQEBAQFlJ4RBAQEBBCNWEAIBCA4DAwECKAMCAgI?= =?us-ascii?q?fERQJCAIEDgWIFQMSDrMmi1YNhE4BAQEBAQEBAQEBAQEBAQEBAQEBAQEVim2CQ?= =?us-ascii?q?YFmNoJgglYFjVeKDDEBjCCBd4FnhE2IXYdRh18BHgEBQoIFG4FLbAEBhmR/AQE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos; i="5.24,562,1454976000"; d="scan'208,217"; a="99683033" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 May 2016 14:03:10 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u41E393X019501 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 1 May 2016 14:03:10 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 1 May 2016 10:03:08 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Sun, 1 May 2016 10:03:08 -0400 From: "Acee Lindem (acee)" To: Mahesh Jethanandani Thread-Topic: [Netconf] mbj review of draft-ietf-netconf-restconf-server-model-09 Thread-Index: AQHRifX44uk/iivOuEmrTCpBJDXsvZ99sTmAgAKen+KAD4/+AIAAOu0AgAB6U4D//9OoAIASoseAgAB93QCAAMcMgA== Date: Sun, 1 May 2016 14:03:08 +0000 Message-ID: References: <20160329.212556.1290892363387952983.mbj@tail-f.com> <3D60808E-EB76-4BE9-8281-B91B4FD83527@juniper.net> <021201d191b1$757fbe40$4001a8c0@gateway.2wire.net> <64FFAE09-4DF0-4D87-ADCF-2A319DB4F684@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: multipart/alternative; boundary="_000_D34B83945EFCEaceeciscocom_" MIME-Version: 1.0 Archived-At: Cc: Routing WG , "draft-ietf-rtgwg-yang-key-chain@ietf.org" , "netconf@ietf.org" Subject: Re: [Netconf] mbj review of draft-ietf-netconf-restconf-server-model-09 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2016 14:03:14 -0000 --_000_D34B83945EFCEaceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2hhdCBpZiB0aGVyZSBpcyBhIG5vbi1wcm90b2NvbCBhcHBsaWNhdGlvbj8gSWYgd2UgY2hhbmdl IGl0IGFnYWluLCBJ4oCZZCBzdGlsbCBwcmVmZXIgcmV2ZXJ0aW5nIHRvIHNpbXBseSBpZXRmLWtl eS1jaGFpbiB0byBtYXRjaCB0aGUgbXVsdGl0dWRlIG9mIG5ldHdvcmsgZGV2aWNlIGltcGxlbWVu dGF0aW9ucy4NCg0KVGhlcmUgaXMgb25lIG90aGVyIGFsdGVybmF0aXZlIHRoYXQgcmVmbGVjdHMg YW55IHBvdGVudGlhbCB1c2FnZS4gSG93ICBhYm91dCBhZ25vc3RpYy1jb25maWctZWNsZWN0aWMt ZXh0ZW5kZWQta2V5Y2hhaW4/IEJ1dCB3YWl0LCB0aGF0IGlzIGEgYml0IGxvbmcsIHBlcmhhcHMg d2UgY2FuIHVzZSBhbiBhY3JvbnltIGFjZWUta2V5LWNoYWluIDteKQ0KDQpBY2VlDQoNCkZyb206 IE1haGVzaCBKZXRoYW5hbmRhbmkgPG1qZXRoYW5hbmRhbmlAZ21haWwuY29tPG1haWx0bzptamV0 aGFuYW5kYW5pQGdtYWlsLmNvbT4+DQpEYXRlOiBTYXR1cmRheSwgQXByaWwgMzAsIDIwMTYgYXQg NjoxMCBQTQ0KVG86IEFjZWUgTGluZGVtIDxhY2VlQGNpc2NvLmNvbTxtYWlsdG86YWNlZUBjaXNj by5jb20+Pg0KQ2M6IE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29tPG1haWx0bzptYmpA dGFpbC1mLmNvbT4+LCBUb20gUGV0Y2ggPGlldGZjQGJ0Y29ubmVjdC5jb208bWFpbHRvOmlldGZj QGJ0Y29ubmVjdC5jb20+PiwgIm5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5v cmc+IiA8bmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86bmV0Y29uZkBpZXRmLm9yZz4+LCAiZHJhZnQt aWV0Zi1ydGd3Zy1rZXljaGFpbkBpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1ydGd3Zy1rZXlj aGFpbkBpZXRmLm9yZz4iIDxkcmFmdC1pZXRmLXJ0Z3dnLWtleWNoYWluQGlldGYub3JnPG1haWx0 bzpkcmFmdC1pZXRmLXJ0Z3dnLWtleWNoYWluQGlldGYub3JnPj4sIFJvdXRpbmcgV0cgPHJ0Z3dn QGlldGYub3JnPG1haWx0bzpydGd3Z0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW05ldGNvbmZd IG1iaiByZXZpZXcgb2YgZHJhZnQtaWV0Zi1uZXRjb25mLXJlc3Rjb25mLXNlcnZlci1tb2RlbC0w OQ0KDQoNClRoYXQgb3Igd2UgY291bGQgYWxzbyByZW5hbWUgaXQgdG8gcHJvdG9jb2wta2V5LWNo YWluIHRvIGRpc2FtYmlndWF0ZSBpdCBmcm9tIHN5c3RlbS1rZXktY2hhaW4uDQoNCk9uIFNhdCwg QXByIDMwLCAyMDE2IGF0IDExOjQwIEFNLCBBY2VlIExpbmRlbSAoYWNlZSkgPGFjZWVAY2lzY28u Y29tPG1haWx0bzphY2VlQGNpc2NvLmNvbT4+IHdyb3RlOg0KU28gaG9wZWZ1bGx5IHdl4oCZdmUg cHV0IHRoZSBpc3N1ZSBvZiBjb21iaW5pbmcgdGhlIG1vZHVsZSB0byBiZWQgZm9yIGdvb2TigKYg SWYgbG9vayBhdCB0aGUgZGF0ZSBub2RlcyBmb3IgdGhlc2UgdHdvIG1vZGVscywgaXQgaXMgcGF0 ZW50bHkgY2xlYXIgdGhhdCB0aGVzZSBzZXJ2ZSB0d28gZGlmZmVyZW50IHB1cnBvc2VzLg0KDQpX aGF0IGFib3V0IHRoZSBuYW1pbmcgaXNzdWU/IEkgZ290IGEgY29tbWVudCB0aGF0IEkgc2hvdWxk IHRha2Ug4oCccm91dGluZy3igJwgYmFjayBvdXQgZHVlIHRvIHRoZSBmYWN0IHRoYXQgdGhpcyBp cyB3aGF0IHRoYXQgdGhlc2Uga2V5LWNoYWlucyBjYW4gYmUgdXNlZCBmb3IgbWFueSBub24tcm91 dGluZyBwdXJwb3Nlcy4gRm9yIGV4YW1wbGUsIEJGRCAtIGh0dHA6Ly93d3cuanVuaXBlci5uZXQv ZG9jdW1lbnRhdGlvbi9lbl9VUy9qdW5vczE0LjIvdG9waWNzL3JlZmVyZW5jZS9jb25maWd1cmF0 aW9uLXN0YXRlbWVudC9rZXktY2hhaW4tZWRpdC1zZWN1cml0eS1hdXRoZW50aWNhdGlvbi1rZXkt Y2hhaW5zLmh0bWwNCg0KVGhhbmtzLA0KQWNlZQ0KDQpGcm9tOiBydGd3ZyA8cnRnd2ctYm91bmNl c0BpZXRmLm9yZzxtYWlsdG86cnRnd2ctYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBB Y2VlIExpbmRlbSA8YWNlZUBjaXNjby5jb208bWFpbHRvOmFjZWVAY2lzY28uY29tPj4NCkRhdGU6 IE1vbmRheSwgQXByaWwgMTgsIDIwMTYgYXQgNjowNCBQTQ0KVG86IE1haGVzaCBKZXRoYW5hbmRh bmkgPG1qZXRoYW5hbmRhbmlAZ21haWwuY29tPG1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNv bT4+DQpDYzogTWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb208bWFpbHRvOm1iakB0YWls LWYuY29tPj4sIFRvbSBQZXRjaCA8aWV0ZmNAYnRjb25uZWN0LmNvbTxtYWlsdG86aWV0ZmNAYnRj b25uZWN0LmNvbT4+LCAibmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86bmV0Y29uZkBpZXRmLm9yZz4i IDxuZXRjb25mQGlldGYub3JnPG1haWx0bzpuZXRjb25mQGlldGYub3JnPj4sICJkcmFmdC1pZXRm LXJ0Z3dnLWtleWNoYWluQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLXJ0Z3dnLWtleWNoYWlu QGlldGYub3JnPiIgPGRyYWZ0LWlldGYtcnRnd2cta2V5Y2hhaW5AaWV0Zi5vcmc8bWFpbHRvOmRy YWZ0LWlldGYtcnRnd2cta2V5Y2hhaW5AaWV0Zi5vcmc+PiwgUm91dGluZyBXRyA8cnRnd2dAaWV0 Zi5vcmc8bWFpbHRvOnJ0Z3dnQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbTmV0Y29uZl0gbWJq IHJldmlldyBvZiBkcmFmdC1pZXRmLW5ldGNvbmYtcmVzdGNvbmYtc2VydmVyLW1vZGVsLTA5DQoN Cg0KDQpGcm9tOiBNYWhlc2ggSmV0aGFuYW5kYW5pIDxtamV0aGFuYW5kYW5pQGdtYWlsLmNvbTxt YWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+Pg0KRGF0ZTogTW9uZGF5LCBBcHJpbCAxOCwg MjAxNiBhdCA0OjQzIFBNDQpUbzogQWNlZSBMaW5kZW0gPGFjZWVAY2lzY28uY29tPG1haWx0bzph Y2VlQGNpc2NvLmNvbT4+DQpDYzogS2VudCBXYXRzZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ8bWFp bHRvOmt3YXRzZW5AanVuaXBlci5uZXQ+PiwgVG9tIFBldGNoIDxpZXRmY0BidGNvbm5lY3QuY29t PG1haWx0bzppZXRmY0BidGNvbm5lY3QuY29tPj4sIE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWls LWYuY29tPG1haWx0bzptYmpAdGFpbC1mLmNvbT4+LCAibmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86 bmV0Y29uZkBpZXRmLm9yZz4iIDxuZXRjb25mQGlldGYub3JnPG1haWx0bzpuZXRjb25mQGlldGYu b3JnPj4sIFJvdXRpbmcgV0cgPHJ0Z3dnQGlldGYub3JnPG1haWx0bzpydGd3Z0BpZXRmLm9yZz4+ LCAiZHJhZnQtaWV0Zi1ydGd3Zy1rZXljaGFpbkBpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1y dGd3Zy1rZXljaGFpbkBpZXRmLm9yZz4iIDxkcmFmdC1pZXRmLXJ0Z3dnLWtleWNoYWluQGlldGYu b3JnPG1haWx0bzpkcmFmdC1pZXRmLXJ0Z3dnLWtleWNoYWluQGlldGYub3JnPj4NClN1YmplY3Q6 IFJlOiBbTmV0Y29uZl0gbWJqIHJldmlldyBvZiBkcmFmdC1pZXRmLW5ldGNvbmYtcmVzdGNvbmYt c2VydmVyLW1vZGVsLTA5DQoNCg0KT24gQXByIDE4LCAyMDE2LCBhdCAxMDoyNSBBTSwgQWNlZSBM aW5kZW0gKGFjZWUpIDxhY2VlQGNpc2NvLmNvbTxtYWlsdG86YWNlZUBjaXNjby5jb20+PiB3cm90 ZToNCg0KSSBkaWQgZ2V0IHNvbWUgbmVnYXRpdmUgZmVlZGJhY2sgd2l0aCByZXNwZWN0IHRvIGFk ZGluZyDigJxyb3V0aW5nLeKAnCB0byB0aGUNCm1vZGVsIG5hbWUgc2luY2Uga2V5IGNoYWlucyBh cmUgdXNlZCBmb3Igb3RoZXIgbm9uLXJvdXRpbmcgYXBwbGljYXRpb25zIGFzDQp3ZWxsLg0KDQpP bmUgb2YgdGhvc2Ugbm9uLXJvdXRpbmcgcHJvdG9jb2xzIGlzIEJGRC4gSSBhbSBmaW5lIGlmIHRo ZSBtb2RlbCBpcyBjYWxsZWQgcHJvdG9jb2wta2V5LWNoYWluLCBidXQgSSB3b25kZXIgd2hhdCBo YXBwZW5zIHRoZSBuZXh0IGVudGl0eSBuZWVkaW5nIGtleS1jaGFpbiBpcyBub3QgYSBwcm90b2Nv bC4NCg0KVGhlIGJpZ2dlciBxdWVzdGlvbiBpbiBteSBtaW5kIGlzLCBhcmUgdGhlc2UgcmVhbGx5 IGRpZmZlcmVudCB0eXBlcyBvZiBrZXktY2hhaW5zIG1vZGVscywgb3IgYXJlIHdlIHRhbGtpbmcg YWJvdXQgb25lIGtleS1jaGFpbiBtb2RlbD8NCg0KVGhlIHJ0Z3dnIGtleSBjaGFpbiBtb2RlbCBp cyB0aGUgb25lIHdlIGFsbCBrbm93IGFuZCBsb3ZlIGFzc29jaWF0ZWQgd2l0aCB0aGUgZ3JhY2Vm dWwgcm9sbG92ZXIgb2YgY29uZmlndXJhYmxlIGtleXMuIFRoZSBuZXRjb25mIG1vZGVsIGlzIGxp c3Qgb2YgY2VydGlmaWNhdGVzIGZvciBhIHB1YmxpYyBrZXkuIFBsZWFzZSBsb29rIGF0IHRoZSBp bmZvcm1hdGlvbiBjb250ZW50IG9mIHRoZSB0d28gbW9kZWxzLiBJIGhvcGUgSSBkb27igJl0IGhh dmUgdG8gYW5zd2VyIHRoaXMgcXVlc3Rpb24gYWdhaW4gO14pDQoNCkFjZWUNCg0KDQoNCg0KDQpN YWhlc2ggSmV0aGFuYW5kYW5pDQptamV0aGFuYW5kYW5pQGdtYWlsLmNvbTxtYWlsdG86bWpldGhh bmFuZGFuaUBnbWFpbC5jb20+DQoNCg0KDQoNCg0KDQotLQ0KTWFoZXNoIEpldGhhbmFuZGFuaQ0K bWpldGhhbmFuZGFuaUBnbWFpbC5jb208bWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPg0K --_000_D34B83945EFCEaceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <01CBE09E10C4F044A68F14F0D0500D9F@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5XaGF0IGlmIHRo ZXJlIGlzIGEgbm9uLXByb3RvY29sIGFwcGxpY2F0aW9uPyBJZiB3ZSBjaGFuZ2UgaXQgYWdhaW4s IEnigJlkIHN0aWxsIHByZWZlciByZXZlcnRpbmcgdG8gc2ltcGx5IGlldGYta2V5LWNoYWluIHRv IG1hdGNoIHRoZSBtdWx0aXR1ZGUgb2YgbmV0d29yayBkZXZpY2UgaW1wbGVtZW50YXRpb25zLiZu YnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhlcmUgaXMgb25lIG90aGVyIGFs dGVybmF0aXZlIHRoYXQgcmVmbGVjdHMgYW55IHBvdGVudGlhbCB1c2FnZS4gSG93ICZuYnNwO2Fi b3V0IGFnbm9zdGljLWNvbmZpZy1lY2xlY3RpYy1leHRlbmRlZC1rZXljaGFpbj8gQnV0IHdhaXQs IHRoYXQgaXMgYSBiaXQgbG9uZywgcGVyaGFwcyB3ZSBjYW4gdXNlIGFuIGFjcm9ueW0gYWNlZS1r ZXktY2hhaW4gO14pJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5BY2VlJm5i c3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNU SU9OIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0 ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsg Qk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxF RlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xp ZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBz dHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPk1haGVzaCBKZXRoYW5hbmRhbmkg Jmx0OzxhIGhyZWY9Im1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbSI+bWpldGhhbmFuZGFu aUBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5E YXRlOiA8L3NwYW4+U2F0dXJkYXksIEFwcmlsIDMwLCAyMDE2IGF0IDY6MTAgUE08YnI+DQo8c3Bh biBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj5BY2VlIExpbmRlbSAmbHQ7PGEg aHJlZj0ibWFpbHRvOmFjZWVAY2lzY28uY29tIj5hY2VlQGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0K PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+TWFydGluIEJqb3JrbHVu ZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1iakB0YWlsLWYuY29tIj5tYmpAdGFpbC1mLmNvbTwvYT4m Z3Q7LCBUb20gUGV0Y2ggJmx0OzxhIGhyZWY9Im1haWx0bzppZXRmY0BidGNvbm5lY3QuY29tIj5p ZXRmY0BidGNvbm5lY3QuY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpuZXRjb25m QGlldGYub3JnIj5uZXRjb25mQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRv Om5ldGNvbmZAaWV0Zi5vcmciPm5ldGNvbmZAaWV0Zi5vcmc8L2E+Jmd0OywNCiAmcXVvdDs8YSBo cmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1ydGd3Zy1rZXljaGFpbkBpZXRmLm9yZyI+ZHJhZnQtaWV0 Zi1ydGd3Zy1rZXljaGFpbkBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpk cmFmdC1pZXRmLXJ0Z3dnLWtleWNoYWluQGlldGYub3JnIj5kcmFmdC1pZXRmLXJ0Z3dnLWtleWNo YWluQGlldGYub3JnPC9hPiZndDssIFJvdXRpbmcgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpydGd3 Z0BpZXRmLm9yZyI+cnRnd2dAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250 LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFtOZXRjb25mXSBtYmogcmV2aWV3IG9m IGRyYWZ0LWlldGYtbmV0Y29uZi1yZXN0Y29uZi1zZXJ2ZXItbW9kZWwtMDk8YnI+DQo8L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJ T05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJ Tkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0 ciI+DQo8cCBjbGFzcz0iIj48c3BhbiBjbGFzcz0iIj5UaGF0IG9yIHdlIGNvdWxkIGFsc28gcmVu YW1lIGl0IHRvIHByb3RvY29sLWtleS1jaGFpbiB0byBkaXNhbWJpZ3VhdGUgaXQgZnJvbSBzeXN0 ZW0ta2V5LWNoYWluLjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJh Ij48YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gU2F0LCBBcHIgMzAsIDIwMTYgYXQg MTE6NDAgQU0sIEFjZWUgTGluZGVtIChhY2VlKSA8c3BhbiBkaXI9Imx0ciI+DQombHQ7PGEgaHJl Zj0ibWFpbHRvOmFjZWVAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+YWNlZUBjaXNjby5jb208 L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3Rl IiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFk ZGluZy1sZWZ0OjFleCI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZDtjb2xvcjpy Z2IoMCwwLDApO2ZvbnQtc2l6ZToxNHB4O2ZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZiI+ DQo8ZGl2PlNvIGhvcGVmdWxseSB3ZeKAmXZlIHB1dCB0aGUgaXNzdWUgb2YgY29tYmluaW5nIHRo ZSBtb2R1bGUgdG8gYmVkIGZvciBnb29k4oCmIElmIGxvb2sgYXQgdGhlIGRhdGUgbm9kZXMgZm9y IHRoZXNlIHR3byBtb2RlbHMsIGl0IGlzIHBhdGVudGx5IGNsZWFyIHRoYXQgdGhlc2Ugc2VydmUg dHdvIGRpZmZlcmVudCBwdXJwb3Nlcy4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2PldoYXQgYWJvdXQgdGhlIG5hbWluZyBpc3N1ZT8gSSBnb3QgYSBjb21tZW50IHRoYXQgSSBz aG91bGQgdGFrZSDigJxyb3V0aW5nLeKAnCBiYWNrIG91dCBkdWUgdG8gdGhlIGZhY3QgdGhhdCB0 aGlzIGlzIHdoYXQgdGhhdCB0aGVzZSBrZXktY2hhaW5zIGNhbiBiZSB1c2VkIGZvciBtYW55IG5v bi1yb3V0aW5nIHB1cnBvc2VzLiBGb3IgZXhhbXBsZSwgQkZEIC0mbmJzcDs8YSBocmVmPSJodHRw Oi8vd3d3Lmp1bmlwZXIubmV0L2RvY3VtZW50YXRpb24vZW5fVVMvanVub3MxNC4yL3RvcGljcy9y ZWZlcmVuY2UvY29uZmlndXJhdGlvbi1zdGF0ZW1lbnQva2V5LWNoYWluLWVkaXQtc2VjdXJpdHkt YXV0aGVudGljYXRpb24ta2V5LWNoYWlucy5odG1sIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3 dy5qdW5pcGVyLm5ldC9kb2N1bWVudGF0aW9uL2VuX1VTL2p1bm9zMTQuMi90b3BpY3MvcmVmZXJl bmNlL2NvbmZpZ3VyYXRpb24tc3RhdGVtZW50L2tleS1jaGFpbi1lZGl0LXNlY3VyaXR5LWF1dGhl bnRpY2F0aW9uLWtleS1jaGFpbnMuaHRtbDwvYT48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2PlRoYW5rcyw8L2Rpdj4NCjxkaXY+QWNlZTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxz cGFuPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtmb250LXNpemU6MTFwdDt0ZXh0 LWFsaWduOmxlZnQ7Y29sb3I6YmxhY2s7Qk9SREVSLUJPVFRPTTptZWRpdW0gbm9uZTtCT1JERVIt TEVGVDptZWRpdW0gbm9uZTtQQURESU5HLUJPVFRPTTowaW47UEFERElORy1MRUZUOjBpbjtQQURE SU5HLVJJR0hUOjBpbjtCT1JERVItVE9QOiNiNWM0ZGYgMXB0IHNvbGlkO0JPUkRFUi1SSUdIVDpt ZWRpdW0gbm9uZTtQQURESU5HLVRPUDozcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJv bGQiPkZyb206IDwvc3Bhbj5ydGd3ZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Z3dnLWJvdW5jZXNA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ydGd3Zy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsg b24gYmVoYWxmIG9mIEFjZWUgTGluZGVtICZsdDs8YSBocmVmPSJtYWlsdG86YWNlZUBjaXNjby5j b20iIHRhcmdldD0iX2JsYW5rIj5hY2VlQGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5 bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5Nb25kYXksIEFwcmlsIDE4LCAyMDE2 IGF0IDY6MDQgUE08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bh bj5NYWhlc2ggSmV0aGFuYW5kYW5pICZsdDs8YSBocmVmPSJtYWlsdG86bWpldGhhbmFuZGFuaUBn bWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tamV0aGFuYW5kYW5pQGdtYWlsLmNvbTwvYT4mZ3Q7 PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+TWFydGluIEJq b3JrbHVuZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1iakB0YWlsLWYuY29tIiB0YXJnZXQ9Il9ibGFu ayI+bWJqQHRhaWwtZi5jb208L2E+Jmd0OywgVG9tIFBldGNoICZsdDs8YSBocmVmPSJtYWlsdG86 aWV0ZmNAYnRjb25uZWN0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmlldGZjQGJ0Y29ubmVjdC5jb208 L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5uZXRjb25mQGlldGYub3JnPC9hPiZxdW90Ow0KICZsdDs8YSBocmVmPSJtYWlsdG86 bmV0Y29uZkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5ldGNvbmZAaWV0Zi5vcmc8L2E+Jmd0 OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtcnRnd2cta2V5Y2hhaW5AaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5kcmFmdC1pZXRmLXJ0Z3dnLWtleWNoYWluQGlldGYub3JnPC9h PiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtcnRnd2cta2V5Y2hhaW5AaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kcmFmdC1pZXRmLXJ0Z3dnLWtleWNoYWluQGlldGYub3Jn PC9hPiZndDssDQogUm91dGluZyBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Z3dnQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+cnRnd2dAaWV0Zi5vcmc8L2E+Jmd0OzxzcGFuIGNsYXNzPSIiPjxi cj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFtO ZXRjb25mXSBtYmogcmV2aWV3IG9mIGRyYWZ0LWlldGYtbmV0Y29uZi1yZXN0Y29uZi1zZXJ2ZXIt bW9kZWwtMDk8YnI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9IkJPUkRFUi1MRUZUOiNiNWM0ZGYgNSBzb2xpZDtQQURESU5HOjAgMCAwIDU7TUFS R0lOOjAgMCAwIDUiPg0KPGRpdj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkO2Nv bG9yOnJnYigwLDAsMCk7Zm9udC1zaXplOjE0cHg7Zm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNl cmlmIj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2ZvbnQtc2l6ZToxMXB0O3RleHQtYWxpZ246bGVm dDtjb2xvcjpibGFjaztCT1JERVItQk9UVE9NOm1lZGl1bSBub25lO0JPUkRFUi1MRUZUOm1lZGl1 bSBub25lO1BBRERJTkctQk9UVE9NOjBpbjtQQURESU5HLUxFRlQ6MGluO1BBRERJTkctUklHSFQ6 MGluO0JPUkRFUi1UT1A6I2I1YzRkZiAxcHQgc29saWQ7Qk9SREVSLVJJR0hUOm1lZGl1bSBub25l O1BBRERJTkctVE9QOjNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTog PC9zcGFuPk1haGVzaCBKZXRoYW5hbmRhbmkgJmx0OzxhIGhyZWY9Im1haWx0bzptamV0aGFuYW5k YW5pQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPC9h PiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPk1v bmRheSwgQXByaWwgMTgsIDIwMTYgYXQgNDo0MyBQTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdl aWdodDpib2xkIj5UbzogPC9zcGFuPkFjZWUgTGluZGVtICZsdDs8YSBocmVmPSJtYWlsdG86YWNl ZUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5hY2VlQGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0K PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+S2VudCBXYXRzZW4gJmx0 OzxhIGhyZWY9Im1haWx0bzprd2F0c2VuQGp1bmlwZXIubmV0IiB0YXJnZXQ9Il9ibGFuayI+a3dh dHNlbkBqdW5pcGVyLm5ldDwvYT4mZ3Q7LCBUb20gUGV0Y2ggJmx0OzxhIGhyZWY9Im1haWx0bzpp ZXRmY0BidGNvbm5lY3QuY29tIiB0YXJnZXQ9Il9ibGFuayI+aWV0ZmNAYnRjb25uZWN0LmNvbTwv YT4mZ3Q7LCBNYXJ0aW4gQmpvcmtsdW5kICZsdDs8YSBocmVmPSJtYWlsdG86bWJqQHRhaWwtZi5j b20iIHRhcmdldD0iX2JsYW5rIj5tYmpAdGFpbC1mLmNvbTwvYT4mZ3Q7LA0KICZxdW90OzxhIGhy ZWY9Im1haWx0bzpuZXRjb25mQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bmV0Y29uZkBpZXRm Lm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpuZXRjb25mQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+bmV0Y29uZkBpZXRmLm9yZzwvYT4mZ3Q7LCBSb3V0aW5nIFdHICZsdDs8YSBo cmVmPSJtYWlsdG86cnRnd2dAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ydGd3Z0BpZXRmLm9y ZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1ydGd3Zy1rZXljaGFp bkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmRyYWZ0LWlldGYtcnRnd2cta2V5Y2hhaW5AaWV0 Zi5vcmc8L2E+JnF1b3Q7DQogJmx0OzxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLXJ0Z3dnLWtl eWNoYWluQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZHJhZnQtaWV0Zi1ydGd3Zy1rZXljaGFp bkBpZXRmLm9yZzwvYT4mZ3Q7PHNwYW4gY2xhc3M9IiI+PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQt d2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTogW05ldGNvbmZdIG1iaiByZXZpZXcgb2Yg ZHJhZnQtaWV0Zi1uZXRjb25mLXJlc3Rjb25mLXNlcnZlci1tb2RlbC0wOTxicj4NCjwvc3Bhbj48 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iQk9SREVSLUxFRlQ6 I2I1YzRkZiA1IHNvbGlkO1BBRERJTkc6MCAwIDAgNTtNQVJHSU46MCAwIDAgNSI+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPjxicj4NCjxzcGFuIGNsYXNzPSIiPg0K PGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj5PbiBBcHIgMTgsIDIwMTYsIGF0 IDEwOjI1IEFNLCBBY2VlIExpbmRlbSAoYWNlZSkgJmx0OzxhIGhyZWY9Im1haWx0bzphY2VlQGNp c2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFjZWVAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PC9k aXY+DQo8YnI+DQo8ZGl2PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2E7Zm9udC1z aXplOjEycHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50Om5vcm1hbDtmb250LXdlaWdo dDpub3JtYWw7bGV0dGVyLXNwYWNpbmc6bm9ybWFsO2xpbmUtaGVpZ2h0Om5vcm1hbDt0ZXh0LWFs aWduOnN0YXJ0O3RleHQtaW5kZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNwYWNl Om5vcm1hbDt3b3JkLXNwYWNpbmc6MHB4O2Zsb2F0Om5vbmU7ZGlzcGxheTppbmxpbmUhaW1wb3J0 YW50Ij5JDQogZGlkIGdldCBzb21lIG5lZ2F0aXZlIGZlZWRiYWNrIHdpdGggcmVzcGVjdCB0byBh ZGRpbmcg4oCccm91dGluZy3igJwgdG8gdGhlPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6 SGVsdmV0aWNhO2ZvbnQtc2l6ZToxMnB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudDpu b3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2xldHRlci1zcGFjaW5nOm5vcm1hbDtsaW5lLWhlaWdo dDpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zvcm06 bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6SGVsdmV0aWNhO2ZvbnQtc2l6ZToxMnB4O2ZvbnQtc3R5bGU6bm9ybWFsO2Zv bnQtdmFyaWFudDpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2xldHRlci1zcGFjaW5nOm5vcm1h bDtsaW5lLWhlaWdodDpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4 dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweDtmbG9h dDpub25lO2Rpc3BsYXk6aW5saW5lIWltcG9ydGFudCI+bW9kZWwNCiBuYW1lIHNpbmNlIGtleSBj aGFpbnMgYXJlIHVzZWQgZm9yIG90aGVyIG5vbi1yb3V0aW5nIGFwcGxpY2F0aW9ucyBhczwvc3Bh bj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYTtmb250LXNpemU6MTJweDtmb250LXN0 eWxlOm5vcm1hbDtmb250LXZhcmlhbnQ6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtsZXR0ZXIt c3BhY2luZzpub3JtYWw7bGluZS1oZWlnaHQ6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4dC1p bmRlbnQ6MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6bm9ybWFsO3dvcmQtc3Bh Y2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYTtmb250LXNpemU6 MTJweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQ6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5v cm1hbDtsZXR0ZXItc3BhY2luZzpub3JtYWw7bGluZS1oZWlnaHQ6bm9ybWFsO3RleHQtYWxpZ246 c3RhcnQ7dGV4dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6bm9y bWFsO3dvcmQtc3BhY2luZzowcHg7ZmxvYXQ6bm9uZTtkaXNwbGF5OmlubGluZSFpbXBvcnRhbnQi PndlbGwuPHNwYW4+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxi cj4NCjwvZGl2Pg0KPGRpdj5PbmUgb2YgdGhvc2Ugbm9uLXJvdXRpbmcgcHJvdG9jb2xzIGlzIEJG RC4gSSBhbSBmaW5lIGlmIHRoZSBtb2RlbCBpcyBjYWxsZWQgcHJvdG9jb2wta2V5LWNoYWluLCBi dXQgSSB3b25kZXIgd2hhdCBoYXBwZW5zIHRoZSBuZXh0IGVudGl0eSBuZWVkaW5nIGtleS1jaGFp biBpcyBub3QgYSBwcm90b2NvbC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoZSBi aWdnZXIgcXVlc3Rpb24gaW4gbXkgbWluZCBpcywgYXJlIHRoZXNlIHJlYWxseSBkaWZmZXJlbnQg dHlwZXMgb2Yga2V5LWNoYWlucyBtb2RlbHMsIG9yIGFyZSB3ZSB0YWxraW5nIGFib3V0IG9uZSBr ZXktY2hhaW4gbW9kZWw/PC9kaXY+DQo8L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvc3Bhbj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoZSBydGd3ZyBrZXkgY2hhaW4g bW9kZWwgaXMgdGhlIG9uZSB3ZSBhbGwga25vdyBhbmQgbG92ZSBhc3NvY2lhdGVkIHdpdGggdGhl IGdyYWNlZnVsIHJvbGxvdmVyIG9mIGNvbmZpZ3VyYWJsZSBrZXlzLiBUaGUgbmV0Y29uZiBtb2Rl bCBpcyBsaXN0IG9mIGNlcnRpZmljYXRlcyBmb3IgYSBwdWJsaWMga2V5LiBQbGVhc2UgbG9vayBh dCB0aGUgaW5mb3JtYXRpb24gY29udGVudCBvZiB0aGUgdHdvIG1vZGVscy4gSSBob3BlIEkgZG9u 4oCZdCBoYXZlDQogdG8gYW5zd2VyIHRoaXMgcXVlc3Rpb24gYWdhaW4gO14pJm5ic3A7PC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5BY2VlJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPHNwYW4+DQo8YmxvY2txdW90ZSBzdHlsZT0iQk9SREVSLUxFRlQ6I2I1YzRkZiA1IHNv bGlkO1BBRERJTkc6MCAwIDAgNTtNQVJHSU46MCAwIDAgNSI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i d29yZC13cmFwOmJyZWFrLXdvcmQiPjxicj4NCjxkaXY+DQo8ZGl2Pk1haGVzaCBKZXRoYW5hbmRh bmk8L2Rpdj4NCjxkaXY+PGEgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tIiB0 YXJnZXQ9Il9ibGFuayI+bWpldGhhbmFuZGFuaUBnbWFpbC5jb208L2E+PC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+PC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQotLSA8YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9zaWduYXR1cmUiPg0KPGRpdiBk aXI9Imx0ciI+DQo8ZGl2Pk1haGVzaCBKZXRoYW5hbmRhbmk8YnI+DQo8L2Rpdj4NCjxhIGhyZWY9 Im1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1qZXRoYW5h bmRhbmlAZ21haWwuY29tPC9hPjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D34B83945EFCEaceeciscocom_-- From nobody Sun May 1 07:56:09 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA2DC12B036; Sun, 1 May 2016 07:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TNZDW1BHLqC; Sun, 1 May 2016 07:56:05 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EAE012B029; Sun, 1 May 2016 07:56:04 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 0DE918A4; Sun, 1 May 2016 16:56: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 jx1BidJ5Sufc; Sun, 1 May 2016 16:55:30 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sun, 1 May 2016 16:56:02 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3F93620056; Sun, 1 May 2016 16:56: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 v2yB2-w13N5m; Sun, 1 May 2016 16:56: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 0EBFB20058; Sun, 1 May 2016 16:55:57 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1124A3AC0FA3; Sun, 1 May 2016 16:55:55 +0200 (CEST) Date: Sun, 1 May 2016 16:55:55 +0200 From: Juergen Schoenwaelder To: "Acee Lindem (acee)" Message-ID: <20160501145553.GA31451@elstar.local> Mail-Followup-To: "Acee Lindem (acee)" , Mahesh Jethanandani , "draft-ietf-rtgwg-keychain@ietf.org" , RTGWG , "netconf@ietf.org" References: <3D60808E-EB76-4BE9-8281-B91B4FD83527@juniper.net> <021201d191b1$757fbe40$4001a8c0@gateway.2wire.net> <64FFAE09-4DF0-4D87-ADCF-2A319DB4F684@gmail.com> <20160501074224.GB30851@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: RTGWG , "netconf@ietf.org" , "draft-ietf-rtgwg-keychain@ietf.org" Subject: Re: [Netconf] mbj review of draft-ietf-netconf-restconf-server-model-09 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2016 14:56:08 -0000 On Sun, May 01, 2016 at 01:38:12PM +0000, Acee Lindem (acee) wrote: > > > On 5/1/16, 3:42 AM, "Juergen Schoenwaelder" > wrote: > > >I have briefly looked at the abstract / intro of both documents and I > >am not sure I got from this why we do have two keychain models. Perhaps > >both documents should be send to the security area as input for a joint > >keychain data model? > > Please look at the data nodes in the two models - one is about keys and > the other is about certificates. I looked at the abstract and the intro and the yang module description and they did not tell me why there are two different models. I think this needs to be clarified. So if I use TLS with pre-shared keys, I have to use the 'routing' key chain and if I use TLS with certificates, I have to use the 'netconf' key chain? In any case, review of both models by the security area may be a good idea (and I still believe these models should ideally be done in the security area) and not in OPS or RTG. /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 May 1 11:26:16 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5937F12D0B3; Sun, 1 May 2016 11:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmsVD2fErnyD; Sun, 1 May 2016 11:26:11 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C722212B077; Sun, 1 May 2016 11:26:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2542; q=dns/txt; s=iport; t=1462127170; x=1463336770; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=85eiWPWhZnfhk9fJ2lA+85BG/MjUwnoPWmDZm/aHiNY=; b=ZhXBbKUyb8QzA6b1fBdY8NtbRuYHmtvMx0E3LW9sjp2ER0cNuNWdtCpr 7oqFE4e6X8J0IDahGnHffEf7F9BQOVzWkm+jNivj11WItMkGocRzk4Hql TWiMPADB6nDlqlXqiIUWHoB7QgzJCSMnUN+Hmt6JerrU7L3b1qlCL4dhq Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AjAgBbSSZX/4YNJK1bA4M4U30GuW8BD?= =?us-ascii?q?YF2IoVuAhx/OBQBAQEBAQEBZSeEQgEBBCMRRQ4CAgEIDgIIAgImAgICGRcVEAI?= =?us-ascii?q?EDgUfiAsOrSGQLgEBAQEBAQEBAQEBAQEBAQEBAQEBARUEeIlxhCcWFwomgjmCV?= =?us-ascii?q?gWYFAGOF4FnhE2IXY8wAR4BAUKCBRuBS2wBhmV/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,563,1454976000"; d="scan'208";a="97957982" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 May 2016 18:26:09 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u41IQ7i6031316 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 1 May 2016 18:26:08 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 1 May 2016 14:26:07 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Sun, 1 May 2016 14:26:07 -0400 From: "Acee Lindem (acee)" To: Juergen Schoenwaelder Thread-Topic: [Netconf] mbj review of draft-ietf-netconf-restconf-server-model-09 Thread-Index: AQHRifX44uk/iivOuEmrTCpBJDXsvZ99sTmAgAKen+KAD4/+AIAAOu0AgAB6U4D//9OoAIASoseAgAB93QCAAJ/AAIAAIFsAgABYxYD///engA== Date: Sun, 1 May 2016 18:26:07 +0000 Message-ID: References: <3D60808E-EB76-4BE9-8281-B91B4FD83527@juniper.net> <021201d191b1$757fbe40$4001a8c0@gateway.2wire.net> <64FFAE09-4DF0-4D87-ADCF-2A319DB4F684@gmail.com> <20160501074224.GB30851@elstar.local> <20160501145553.GA31451@elstar.local> In-Reply-To: <20160501145553.GA31451@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: text/plain; charset="utf-8" Content-ID: <256242F8D64C6E4583B33E089B73284A@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: RTGWG , "netconf@ietf.org" , "draft-ietf-rtgwg-keychain@ietf.org" Subject: Re: [Netconf] mbj review of draft-ietf-netconf-restconf-server-model-09 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2016 18:26:13 -0000 DQoNCk9uIDUvMS8xNiwgMTA6NTUgQU0sICJKdWVyZ2VuIFNjaG9lbndhZWxkZXIiDQo8ai5zY2hv ZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPiB3cm90ZToNCg0KPk9uIFN1biwgTWF5IDAx LCAyMDE2IGF0IDAxOjM4OjEyUE0gKzAwMDAsIEFjZWUgTGluZGVtIChhY2VlKSB3cm90ZToNCj4+ IA0KPj4gDQo+PiBPbiA1LzEvMTYsIDM6NDIgQU0sICJKdWVyZ2VuIFNjaG9lbndhZWxkZXIiDQo+ PiA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPiB3cm90ZToNCj4+IA0KPj4g PkkgaGF2ZSBicmllZmx5IGxvb2tlZCBhdCB0aGUgYWJzdHJhY3QgLyBpbnRybyBvZiBib3RoIGRv Y3VtZW50cyBhbmQgSQ0KPj4gPmFtIG5vdCBzdXJlIEkgZ290IGZyb20gdGhpcyB3aHkgd2UgZG8g aGF2ZSB0d28ga2V5Y2hhaW4gbW9kZWxzLiBQZXJoYXBzDQo+PiA+Ym90aCBkb2N1bWVudHMgc2hv dWxkIGJlIHNlbmQgdG8gdGhlIHNlY3VyaXR5IGFyZWEgYXMgaW5wdXQgZm9yIGEgam9pbnQNCj4+ ID5rZXljaGFpbiBkYXRhIG1vZGVsPw0KPj4gDQo+PiBQbGVhc2UgbG9vayBhdCB0aGUgZGF0YSBu b2RlcyBpbiB0aGUgdHdvIG1vZGVscyAtIG9uZSBpcyBhYm91dCBrZXlzIGFuZA0KPj4gdGhlIG90 aGVyIGlzIGFib3V0IGNlcnRpZmljYXRlcy4NCj4NCj5JIGxvb2tlZCBhdCB0aGUgYWJzdHJhY3Qg YW5kIHRoZSBpbnRybyBhbmQgdGhlIHlhbmcgbW9kdWxlIGRlc2NyaXB0aW9uDQo+YW5kIHRoZXkg ZGlkIG5vdCB0ZWxsIG1lIHdoeSB0aGVyZSBhcmUgdHdvIGRpZmZlcmVudCBtb2RlbHMuIEkgdGhp bmsNCj50aGlzIG5lZWRzIHRvIGJlIGNsYXJpZmllZC4NCg0KSGF2ZSB5b3UgaGVhcmQgdGhlIGV4 cHJlc3Npb24sIOKAnFlvdSBjYW7igJl0IGp1ZGdlIGEgYm9vayBieSBpdHMgY292ZXLigJ0/DQoN Cj4NCj5TbyBpZiBJIHVzZSBUTFMgd2l0aCBwcmUtc2hhcmVkIGtleXMsIEkgaGF2ZSB0byB1c2Ug dGhlICdyb3V0aW5nJyBrZXkNCj5jaGFpbiBhbmQgaWYgSSB1c2UgVExTIHdpdGggY2VydGlmaWNh dGVzLCBJIGhhdmUgdG8gdXNlIHRoZSAnbmV0Y29uZicNCj5rZXkgY2hhaW4/DQoNCkkgd29u4oCZ dCBzcGVhayBmb3IgY2VydGlmaWNhdGVzIGJ1dCBpZiB5b3Ugd2VyZSBnb2luZyB1c2UgcHJlLXNo YXJlZCBrZXlzLA0KeW91IHdvdWxkIHNpbXBseSBpbXBvcnQgdGhlIGtleS1jaGFpbiBtb2RlbCBp biB0aGUgc2FtZSBtYW5uZXIgYXMgdGhlDQphcHBsaWNhdGlvbnMgdGhhdCBhcmUgY3VycmVudGx5 IHVzaW5nIGl0LiBGb3IgZXhhbXBsZSwNCmh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWll dGYtb3NwZi15YW5nLTA0LnR4dCAtIE5vdGUgdGhhdCB5b3Ugd2lsbA0KaGF2ZSB0byBsb29rIGJl eW9uZCB0aGUgYWJzdHJhY3QgZm9yIHRoZSBleGFtcGxlIG9mIHRoaXPigKYNCg0KVGhhbmtzLA0K QWNlZQ0KDQoNCj4NCj5JbiBhbnkgY2FzZSwgcmV2aWV3IG9mIGJvdGggbW9kZWxzIGJ5IHRoZSBz ZWN1cml0eSBhcmVhIG1heSBiZSBhIGdvb2QNCj5pZGVhIChhbmQgSSBzdGlsbCBiZWxpZXZlIHRo ZXNlIG1vZGVscyBzaG91bGQgaWRlYWxseSBiZSBkb25lIGluIHRoZQ0KPnNlY3VyaXR5IGFyZWEp IGFuZCBub3QgaW4gT1BTIG9yIFJURy4NCg0KDQoNCg0KPg0KPi9qcw0KPg0KPi0tIA0KPkp1ZXJn ZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJI DQo+UGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkg QnJlbWVuIHwgR2VybWFueQ0KPkZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHA6 Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0KDQo= From nobody Sun May 1 15:40:16 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB1212D0DA; Sun, 1 May 2016 15:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBt1sOLZouu7; Sun, 1 May 2016 15:40:13 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0097.outbound.protection.outlook.com [104.47.0.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F295612B033; Sun, 1 May 2016 15:40:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MaY2UZ9FsUgs76bONxkr7NzZ2mVCU1uatnEZxVsJCZg=; b=LlPmL7ZiwVVXzgMUYf+bMrW5qOGJwq4wwe6AdX4HtGli7hG/Sj7M8q1c2YsZ6z7IlyY0ysfn9AGydD55nE6j+fVO9JS6fA+PbC4ojeLr/MtcMRFvGoP3a2GHhRs3CgUrzGh39iA+e0qR9tNuNcQFXW2vI4LzQ9pkFB+91pJR6Rg= Received: from AMXPR07MB215.eurprd07.prod.outlook.com (10.242.73.17) by AMXPR07MB216.eurprd07.prod.outlook.com (10.242.73.18) with Microsoft SMTP Server (TLS) id 15.1.477.8; Sun, 1 May 2016 22:40:10 +0000 Received: from AMXPR07MB215.eurprd07.prod.outlook.com ([169.254.11.6]) by AMXPR07MB215.eurprd07.prod.outlook.com ([169.254.11.6]) with mapi id 15.01.0477.012; Sun, 1 May 2016 22:40:10 +0000 From: "Ersue, Mehmet (Nokia - DE/Munich)" To: EXT Benoit Claise , "iesg-secretary@ietf.org" Thread-Topic: Request to publish draft-ietf-netconf-restconf as Proposed Standard Thread-Index: AdGj+e+jWAT1/nELSSuLQbKCZ53HYg== Date: Sun, 1 May 2016 22:40:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=nokia.com; x-originating-ip: [12.219.170.194] x-ms-office365-filtering-correlation-id: 94ef4cc0-688b-4a25-82da-08d372118d8c x-microsoft-exchange-diagnostics: 1; AMXPR07MB216; 5:iKfmrO4Q8Heuo8AVNzImDNLnVoog9Iq/69RLwALdHXuD/Tj8PYAQlnkka6w685apKuxQBd9ickFJmoHVhFgy+mscozZK7tZy9499TXaFwloN4bdWpF3BQrmFGS5LakltBqnISF8cjHiO/c2q1jB0nQ==; 24:xFp55UL3lDoEhwycn2jE1AxrFZykxS5SIEKJg7CXA8sbOHVQpvuFzBZRmVMHUZvrIj7wIeca9S+Emm+RjqLwpIGejN3rNKxehGBploxN3Rw=; 7:WL/m/f2pI9mvzc8vMZ/xZQSnWQ+09+4O+tdSXa2D9ByOElHBs6Fo19kjHF86v+rkV/+hyXWyd0yRFxCRctKBUO+Y53ZHMmcO5w9GPDpQcMN+DB0UpZP53/MZLYvM/ZWqrMADyHg/lVOYkepUgHM+Ll2P94wuyMEDnMEJluIxywOUDcZit2hZXRS7NUGn2F0y x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB216; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521072)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:AMXPR07MB216; BCL:0; PCL:0; RULEID:; SRVR:AMXPR07MB216; x-forefront-prvs: 0929F1BAED x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(3280700002)(3660700001)(2906002)(189998001)(76576001)(6116002)(586003)(3846002)(5002640100001)(87936001)(102836003)(33656002)(19580395003)(1096002)(229853001)(1220700001)(66066001)(81166005)(4326007)(10400500002)(5003600100002)(50986999)(5008740100001)(2501003)(74316001)(92566002)(54356999)(230783001)(15975445007)(122556002)(86362001)(11100500001)(5004730100002)(2900100001)(9686002)(5001770100001)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB216; H:AMXPR07MB215.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AMXPR07MB215D09CA393B83B1D6ACCA691780AMXPR07MB215eurprd_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 May 2016 22:40:10.2930 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB216 Archived-At: Cc: Netconf Subject: [Netconf] Request to publish draft-ietf-netconf-restconf as Proposed Standard X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2016 22:40:15 -0000 --_000_AMXPR07MB215D09CA393B83B1D6ACCA691780AMXPR07MB215eurprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Benoit, based on the consensus in the NETCONF WG and as discussed with Mahesh and the authors of the NETCONF RESTCONF draft, we think that we are ready to bring the document to publication. Please initiate the necessary process for the publication of https://tools.ietf.org/html/draft-ietf-netconf-restconf-13 as Proposed Standard. Please find on IETF datatracker the document write-up: https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf/shepherdwriteu= p/ Doing my shepherd review I found a few document referencing issues which have been addressed in v13. The draft versions referenced can be handled as editorial. Thank you. Document shepherd, Mehmet Ersue --_000_AMXPR07MB215D09CA393B83B1D6ACCA691780AMXPR07MB215eurprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Benoit,
 
based on the consensus in the NETCONF WG and a= s discussed
with Mahesh and the authors of the NETCONF RES= TCONF draft,
we think that we are ready to bring the docume= nt to publication.
 
Please initiate the necessary process for the = publication of
as Proposed Standard.
 
Please find on IETF datatracker the document w= rite-up:
 
Doing my shepherd review I found a few documen= t referencing
issues which have been addressed in v13. The d= raft versions referenced
can be handled as editorial.
 
Thank you.
 
Document shepherd,
Mehmet Ersue
 
 
 --_000_AMXPR07MB215D09CA393B83B1D6ACCA691780AMXPR07MB215eurprd_-- From nobody Sun May 1 23:35:46 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43C9A12B062; Sun, 1 May 2016 23:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGKI77D2xjC0; Sun, 1 May 2016 23:35: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 D2EFB12D0FF; Sun, 1 May 2016 23:35: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 2EA826B3; Mon, 2 May 2016 08:35: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 AU4-5lq4n5om; Mon, 2 May 2016 08:35:33 +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, 2 May 2016 08:35:34 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9179720047; Mon, 2 May 2016 08:35:34 +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 XWCMJA-h-AYH; Mon, 2 May 2016 08:35:34 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A24F52004A; Mon, 2 May 2016 08:35:33 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 835893AC2083; Mon, 2 May 2016 08:35:32 +0200 (CEST) Date: Mon, 2 May 2016 08:35:31 +0200 From: Juergen Schoenwaelder To: "Acee Lindem (acee)" Message-ID: <20160502063531.GA32842@elstar.local> Mail-Followup-To: "Acee Lindem (acee)" , Mahesh Jethanandani , "draft-ietf-rtgwg-keychain@ietf.org" , RTGWG , "netconf@ietf.org" References: <64FFAE09-4DF0-4D87-ADCF-2A319DB4F684@gmail.com> <20160501074224.GB30851@elstar.local> <20160501145553.GA31451@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: RTGWG , "netconf@ietf.org" , "draft-ietf-rtgwg-keychain@ietf.org" Subject: Re: [Netconf] mbj review of draft-ietf-netconf-restconf-server-model-09 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 06:35:44 -0000 On Sun, May 01, 2016 at 06:26:07PM +0000, Acee Lindem (acee) wrote: > > Have you heard the expression, “You can’t judge a book by its cover”? > Can we please be serious and simply improve things? Thanks, /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 May 2 02:42:26 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C899312D109 for ; Mon, 2 May 2016 02:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.518 X-Spam-Level: X-Spam-Status: No, score=-15.518 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDCve9X8RtjN for ; Mon, 2 May 2016 02:42:23 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ADCF12D0CD for ; Mon, 2 May 2016 02:42:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4601; q=dns/txt; s=iport; t=1462182143; x=1463391743; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=UGtR5NKEjvMfK+A3JVGznB12TIXTKB2g1ZNq8NsAqxE=; b=cYVQjRFnS0xENwBY2CEfiqU1DJQVRiLC8bkGofFYdfeyQGe7O5y3svFv waZ8oWL8wLVYodoHahTflvso6o1XACu23Xb8ya6GV3e4x6+iyUFQSXDIl 2uKl0jEitGoPv9Y9zcMpgqJSXPw27oBNCdYmWpFV2LPOIsSjdCtcGhnR9 Q=; X-IronPort-AV: E=Sophos;i="5.24,566,1454976000"; d="scan'208";a="677005159" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 May 2016 09:42:21 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u429gLsa027650; Mon, 2 May 2016 09:42:21 GMT To: "Ersue, Mehmet (Nokia - DE/Munich)" , Netconf , "jonathan@hansfords.net" , "rex@cisco.com" References: <20160501073735.GA30851@elstar.local> From: Benoit Claise Message-ID: <572720FD.6040808@cisco.com> Date: Mon, 2 May 2016 11:42:21 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160501073735.GA30851@elstar.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Netconf] IPR Poll for draft-ietf-netconf-restconf-12 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 09:42:26 -0000 This email generated some further non-public discussions, and I was asked to provide guidelines. Here it is. Regards, Benoit =================== Theory first. - Contributor definition, see RFC 5378 and RFC3979 - Who Must Make an IPR Disclosure? A Contributor's IPR in his or her Contribution. See RFC3979 section 6.1 - The Timing of Providing Disclosure. See RFC3979 section 6.2 The chairs are right to ask about IPR before WG adoption, and again before sending the document to publication. The WG could be unhappy if an IPR declaration was made just after WG adoption, or just after publication. The WG needs to make an informed decision. So if you are a contributor, you must answer the IPR request. Full stop. It takes 3 seconds to answer "I'm not aware of any IPR" Since I'm asked, here are the suggested guidelines. 1. Let's try to respect the rule of 5 authors (RFC7322 section 4.1.1) 2. If someone made some sort of contribution (like an entire section) but he is not listed as an author, he is a contributor. The editors make the call. 3. If someone corrects a few sentences, part of a document review, he is acknowledged. The editors make the call. 4. Between authors, contributors, acknowledgement section, the document shepherd and chairs can make the call if we need an arbiter. 5. IPR requests are only sent to editors, authors, and contributors 6. Let's avoid the keywords such as contributors and ideally contributions in the acknowledgment section. Regards, Benoit > What is a registered contributor? Frankly, we draw somewhat arbitrary > lines here. That said, I think I do understand the IETF IPR rules if > that was the question. > > /js > > On Sun, May 01, 2016 at 12:15:16AM +0000, Ersue, Mehmet (Nokia - DE/Munich) wrote: >> Hi Jonathan, Juergen, Rex, >> >> AFAICS you did not respond to the request below. >> As registered contributor to the RESTCONF draft we do require your IPR statement. >> >>> If you are listed as a document author or contributor (CCed) please respond to this email ON NETCONF MAILLIST explicitly regardless of whether or not you are aware of >>> any relevant IPR. The document will not advance to the next stage until a response has been received from _each author and contributor_. >> I hope you will respond soon and we can start the publication process officially. >> >> Thanks. >> >> Mehmet >> >> From: "Ersue, Mehmet (Nokia - DE/Munich)" > >> Date: Sunday, April 24, 2016 at 5:49 PM >> To: "netconf@ietf.org" > >> Cc: EXT Ladislav Lhotka >, Juergen Schoenwaelder >, "rwilton@cisco.com" >, "jonathan@hansfords.net" >, "rex@cisco.com" >, EXT Andy Bierman >, Martin Bjorklund >, Kent Watsen > >> Subject: IPR Poll for draft-ietf-netconf-restconf-12 >> >> Dear Authors and Contributors of RESTCONF Draft, >> Dear WG Members, >> >> please state on the maillist clearly whether you own or are aware of any IPR that applies to draft-ietf-netconf-restconf-12.txt. >> For the opposite case, please state also on the maillist clearly if you don’t own or are not aware of any IPR that applies to the draft-ietf-netconf-restconf. >> >> If you own or are aware of any IPR that applies to the draft-ietf-netconf-restconf please clarify whether >> this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). >> If not please do so asap. >> >> If you are listed as a document author or contributor (CCed)please respond to this email ON NETCONF MAILLIST explicitly regardless of whether or not you are aware of any relevant IPR. The document will not advance to the next stage until a response has been received from _each authorand contributor_. >> >> If you are not listed as an author or contributor but are on NETCONF WG maillist, then please explicitly respond if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. >> >> Thank you for kind support. >> >> Regards, >> Mehmet & Mahesh >> From nobody Mon May 2 02:44:48 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6108212D10D for ; Mon, 2 May 2016 02:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EtOZp-H48BbD for ; Mon, 2 May 2016 02:44:43 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0137.outbound.protection.outlook.com [104.47.0.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE87D12D0DA for ; Mon, 2 May 2016 02:44:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Y/LNpT6icnf7PfiMS5x4c8MpLI41CZmmKgQKxjnVc90=; b=ICW8vNrQJTc2MlCO3BlSfRBVVfGq+aYoC4N6VcDGMf+DtydR2Qc7OeRM+3nji8skpX6FQrWcgjqH/ukTKWlR5lrT48x/GhetlNav9mx7V/PVY/8RNX+jcep4ZQRR2eofZTH0b9SqKe4addc8V+Sohf2/YjRfcbWkY+lFlQYe8fw= Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (109.153.79.147) by DB5PR07MB1621.eurprd07.prod.outlook.com (10.166.12.148) with Microsoft SMTP Server (TLS) id 15.1.477.8; Mon, 2 May 2016 09:44:39 +0000 Message-ID: <022801d1a456$c20e12e0$4001a8c0@gateway.2wire.net> From: t.petch To: Kent Watsen , Andy Bierman References: <3C88D813-7674-47C4-A6AF-E02C368CE71C@juniper.net> <20160429.100226.431840842419129504.mbj@tail-f.com> <20160429081529.GA26297@elstar.local> <20160429.102116.1627845264494578220.mbj@tail-f.com> <00aa01d1a209$2d165a20$4001a8c0@gateway.2wire.net> <9E3A9643-2348-42AA-A6B0-6FB9F13D1A29@juniper.net> Date: Mon, 2 May 2016 10:10:08 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [109.153.79.147] X-ClientProxiedBy: DB5PR03CA0059.eurprd03.prod.outlook.com (10.164.34.27) To DB5PR07MB1621.eurprd07.prod.outlook.com (10.166.12.148) X-MS-Office365-Filtering-Correlation-Id: f17c1b06-ba4d-4d5a-9a95-08d3726e6190 X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1621; 2:bTg9CdcTrIKLVrsb/FIu0ZuqApGRKvExKMhyhqMHSyUOGAHr2FEzlWwhRobL4zVvbkjr8DSBJDQHPL3rB78yvI/YN9jeh5EM0Kpl0H/LJtkEVXOdZotYWRNaKmajO4yK+aU3lY7nl7n1OlvKUApPqWW7QYPtmSlUiVwOS7CKSwyTGpbqPp3Wvpt93YRyS0bT; 3:hxuBl9a0taidUgOa6izF8Gwn+GdXPQd29b1w+rvctr4mUtlq9ZIlvBqFfK/XqjVyY61xsyARo0ZHOebaNkOWc864p+e2qT8AU5ku39jlQmKk96y8cSwjJ6JwNQsH/sp+; 25:cSB4eH2uOgiHh5MKXCk9XP6oFvraS5xgat6VEtFpPzJCBnkGoGbyabP+adrqgvr86oV+2XqmVi2HVALWFrphtrLp3NgdVqvmwxffc15puzHv/dIlNPAr2t33zxOiq9VDBaoTD3CmplbRL50fM99srnHxWc2Sry7Uxx7H9SwNv5Nttymt1X2T5/xHJq48LNfR1+Tb1mwofTjVJrbRfZNe7EYwJOEx48rVRlrenVzT0Zd/OdZYM8KujeP/B/gQXLfsN6WPMTE95A113fTXMAA42GDEfL9uC55Lmzc+vDQCDiaE+dDIyY9IMSNz4FzjlY483iLUeg84zMn+HTJZESYQyg== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR07MB1621; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(9101521093)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:DB5PR07MB1621; BCL:0; PCL:0; RULEID:; SRVR:DB5PR07MB1621; X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1621; 4:qrApJxPBdseKjUlZD+y71I9+zrqlTWGqJoWIQqbxe3glAvEqOvmdfk9I/DmmM0K5b8L3S9tNyr2ri6XAgY2bRLlByZ5dA9oY9dYCMWU/5K6qxpJ8Hx5YTzQfzuRYIs/KYGqjA+EuSRG16BRRyyLbVlEriz4Sf6JdtV7Uq43sU3P1LOxikYKgtOC8Lg3UCnYULtrR3zOHWMiW+uPSQrwjqrTind92HkR6Zux3uS5Cz3/RtKyExKPmMoBkkPUtlt9+VGZoCmxzrz0+tQYhiHeB9aXuMs37oDe3J9/6KKqVLjuNq8e3DHNyHqqK5nal+I4FweNK8qqg3cenp7m1orym2PQf6cbQ+QIOsjhFA/SAZoJKpsXD/r361ZkVJ3CR0g+GVYp46K8w+1KT2T7jULK+N31OmYovqbi8Y8dzZLBbVAvmxXc+tsLmq/rKVuC81KoA X-Forefront-PRVS: 0930AAFAD9 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(24454002)(13464003)(51444003)(377454003)(61296003)(6116002)(33646002)(2906002)(42186005)(3846002)(5004730100002)(189998001)(1096002)(116806002)(44736004)(50226002)(1941001)(1456003)(1556002)(66066001)(19580395003)(19580405001)(47776003)(62236002)(50986999)(84392002)(50466002)(86362001)(93886004)(586003)(5001770100001)(81816999)(81166005)(44716002)(92566002)(76176999)(230700001)(9686002)(23676002)(4326007)(5008740100001)(14496001)(81686999)(77096005)(7099028)(118906001)(74416001)(7059030)(7726001)(4720700001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR07MB1621; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjVQUjA3TUIxNjIxOzIzOlV6RjUyWUUrUzF1bnFEN1A4ZTVVREFQK3hB?= =?utf-8?B?bjczeERFc2pTeGVKblUxanp6U05QeGxZbVFGdlk2SzBKcTkrdXF1cDRUeWhM?= =?utf-8?B?RjJrODl3ZXhNK2xSaHNNaWt6SmgwUTE4cW9ZbFBCTm1Sb09IZE9YNG5XTll6?= =?utf-8?B?OFZmOXFXRFlzelpaL2pCWUNEaWN6OC9TUnpCdmdMQSs2VWpkb3JyWlc4Y05U?= =?utf-8?B?blRLdktqSUhrMGZ5a3Q4TnNaZ2tiSEF5VVpyaTZIL1pJdnZtYU5NUVRTWmp4?= =?utf-8?B?SG80TjBZV3QvY1JlQUlFYTdOdllQUm9lMEI5OGdUTjh5d2RrVWkvMzZuQTVu?= =?utf-8?B?Rm5NY2twOTBpc0ZxRzdJOWJnazIxQW1RSG5vYkpORnhDTHR3bjdFZW1QQ09n?= =?utf-8?B?WThkOXhwM25jM0RTWW9BUExCdXZweThVRE1Hbk5ncG1WYkZNd0tCeENiY05C?= =?utf-8?B?VVdCaWwyUENpODA1eTJwdWkvR1pVa21raEVSQ2lOS2t0aS8xN0tOaThwdVpt?= =?utf-8?B?RjBDMjJrbm90bHl3Rm1YZndiNURaUmhNQzMvVHJJTktFSWMvUUc5Zm5RbS9Q?= =?utf-8?B?MDBaa3hSVFd6WlZuOGJ2QjJxbmFicHA3N1hBa2NjRmdtd1pXNTYzQWgraGNl?= =?utf-8?B?NHJBQk1zK1Vnb2FwL1EzSWgrTVN2SnF5YmdCMTdpUGJHOUZacjRoV3ljWEJ1?= =?utf-8?B?eTl3aHdteHB3VW1YNDFHUkVOLzRRYyt3ZnA4eDk4Q3JDekNWSERYZ2EvR3Zl?= =?utf-8?B?UmMrU0pUWTR5NWNjNndtUW1tYWtreU1wQ1Rac2hoek50ZE8xb0RBZzZCbWRH?= =?utf-8?B?Slk4WHhOVzZ6WVFmeGh6TGtkRGFQUFdaMEZGWThzdmo3VFJteFlkd0NxL2Rp?= =?utf-8?B?L2xvSjFpSUhaanpPNXhTTk9OdmxKaGJDc0xlbXVyc2ZNVlIwQkFUSzRYM0l2?= =?utf-8?B?em1XendMSlVvZjhueVZlNG96NzNzeGVaQ015Z05vRHpnYVora3o0YzFSYlY3?= =?utf-8?B?NXJDNlVkblJlM2lxTVFNaTZRMTB1SEhOVHRuNFlLYjRFMDk5THNMa1lMNzVn?= =?utf-8?B?R0R6aDdRcFc4MDZ1d0xSSkNhaTM1dEh2eGNYWVhVb0l4RGl0K0d4WWh1MXBG?= =?utf-8?B?MEo2VHo3N1JUZytSVWhLRWlycVhuS1JKNXo1SXBtK3ZNZGxWWE90K0JCYzVW?= =?utf-8?B?bVp4NVdhUmlUbTh1VmNLOEsxN0NxNDkwVWtXajliYk8vRUk3WmJHaGt3V041?= =?utf-8?B?QmZVbmt4N0ZwbHpQVWJwSzA0MVdVTVZkZTRkTW41eEZwRVJRY1cvZldJUTQy?= =?utf-8?B?eVhhc09QRUVyUlVPTVhsdnFsWGw5Q1d2UE4zSWRoR2hxaVVNWmEvYWM4MjI0?= =?utf-8?B?QktsMDB4eGo1bVM0ZjhmTHlOaXZnQ0xXYVBBZVRVY21aV3RMQlhuaTVFSWRF?= =?utf-8?B?QXlQMkphYUZWOCtWTUl6eXFFek1pUzQ5YzlLY2l6aVFwcWg4ZWYzZ1pUbHdI?= =?utf-8?B?UVRqb1A2b2FwYnVNQlhVYjVGVDV2c0gzS202US8wb2RnSG94MUlvdjV2LzZ6?= =?utf-8?B?TTN6OXdZREtDZDI2WGRTVWExc1o0bXQrVHg4YUhhdUhyK3AyMmNEK2w2enRr?= =?utf-8?B?L0Z2a1crbWNGeXhpb2J2YTFZUFZ5SlhwdWQwa3JRbmZsVnFKTEZLT1E5c2Zk?= =?utf-8?B?Sk1mRytSeFNmai9PR09TMDQzR1NldFlGY3F2SjJBcWlxOUFJVVVpbHd4UkJ4?= =?utf-8?Q?yxEf9WQ8HACWh5mblonXFhwiOIO+MSPY/1hHw=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1621; 5:8eYmGyKrLPvIG33jXq257NgSCBzCmO382kxm8KyeRyTeX+JLPuX2cyzjL4wS7x+tZ9SPijNQ0tpiMg/+Q+PkmVQU6YZWAiBs3klWcUHj53pTodkar2heJ6gSE/R1H2S+q9Px7iF70AI6rHsIW7Ke8g==; 24:WMujP/9rl4sdIh871wriauci8fymFIm23FAAd09gFDnHJxGEzTvJ3Y5JaHDCiyfXY4rlszHVQdCgt0LcaKpQ6dOEOodymI5UfEHhJs3dRyM=; 7:eXOs19kd1JGOWlcHYeP/3c2oQe9t0TZTuJuPiwkXtGuwdz6338vcKWWv9VYFzoAo3X9DRiUoE+Z5T6LBFRlSPYLg2SVmivhM62WWcLvy1WK9ui3EqppOWm2l8STIXJM1IgXL4GTv63Jx/rw8coWqAKSI8/y7+u43Sim8jAoxo9WaP3Ib/hXo21TaNfjRCYZ+ SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 May 2016 09:44:39.6332 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB1621 Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] Confirming the decision to split the server-model draft into several drafts. X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 09:44:46 -0000 ----- Original Message ----- From: "Kent Watsen" To: "Andy Bierman" Cc: Sent: Friday, April 29, 2016 7:57 PM > > I'm open to an interim to discuss, if that is what the WG would like to do. > > But quickly, the motivating reason for the middle-two drafts (and the modules they define) to be separated is so that configuration models for other (besides NC/RC) ssh/tls-based client/servers (e.g., syslog, smtp, http) could use the ietf-[ssh|tls]-[client|server] groupings without having to have a normative reference to an RFC who's title ostensibly regards NC/RC. Kent As a reason, I think that that is abysmal. RFC should be aimed at a target audience and, for technology, the primary audience is those who will implement it (often a rather small number) closely followed by those who use it and need to understand how it works in detail (a rather larger number). You are saying that it should be written for its aesthetic appeal to standards writers; standards writers should swallow their feelings and lump it - their job is to satisfy implementers and users (as above). As Andy said, three seems the obvious number (unless that leads to a complex mesh of dependencies which, as I alluded to before, makes things hard to understand; currently, I do not think that that is the case). Tom Petch > Kent > > From: Andy Bierman > > Date: Friday, April 29, 2016 at 1:07 PM > To: Kent Watsen > > Cc: "netconf@ietf.org" netconf@ietf.orgmailto:netconf@ietf.org > > On Fri, Apr 29, 2016 at 8:49 AM, Kent Watsen > wrote: > > To answer so of the questions posted here: > > The motivation is to have well-defined RFCs that make good referenceable targets for future work. In particular, there may be other transports besides SSH and TLS, or there may be other high-level protocols that use these two transports. > > Regarding the intention of which modules would be in which drafts, I just realized that a made a mistake before, also in the slides presented in BA. Below is correct, there's actually five drafts (not four) having the following YANG modules: > > There is currently 1 draft (draft-ietf-netconf-server-model-09) correct? > > draft-ietf-netconf-system-keychain > - ietf-system-keychain // this we have already today > > draft-ietf-netconf-ssh-client-server > - ietf-ssh-client // this would be added > - ietf-ssh-server // this we have already today > > draft-ietf-netconf-tls-client-server > - ietf-tls-client // this would be added > - ietf-tls-server // this we have already today > > draft-ietf-netconf-netconf-client-server > > - ietf-netconf-client // this would be added > - ietf-netconf-server // this we have already today > > draft-ietf-netconf-restconf-client-server > - ietf-restconf-client // this would be added > - ietf-restconf-server // this we have already today > > Looking over the current draft, it seems like 3 RFCs would be more intuitive: > > - keychain > - NETCONF server > - RESTCONF server > > IMO lumping TLS and SSH together does not imply that the RFC needs > to be updated later to add new transports. They can be added as needed > via augments. > > The 5 module split is not easy to follow. It is not easy to > see how the modules relate to each other. Going to a 9 module > split spread over 5 RFCs would probably be impossible to read. > > I am not sure what is in each of the "client" modules. > IMO we should have a virtual interim on server-model-09, > before you start refactoring. > > Andy > > From nobody Mon May 2 02:44:52 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13BDD12D0DA; Mon, 2 May 2016 02:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RrQJyFvDh3z4; Mon, 2 May 2016 02:44:44 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0137.outbound.protection.outlook.com [104.47.0.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2C9812D109; Mon, 2 May 2016 02:44:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=379K+GsOOpSPxIY9DrzKE49/PizwZdHMUIuLKdROED0=; b=WR31ZzeEXCllv+6Z2hL/b9A2sc8LQrw1L4IUqXMxsFnyvzb0VUSKF21MyZFU0sWmFN1Et7BZGDhwKkA7qIuK3cWuVb+8VLCKspiXol38CUHLgdHZ5R33mlf9yLp5KIZvtSI+8OP6jnvUBLYeLwaM3aChJHa5Bo451ySvG9RqYMY= Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (109.153.79.147) by DB5PR07MB1621.eurprd07.prod.outlook.com (10.166.12.148) with Microsoft SMTP Server (TLS) id 15.1.477.8; Mon, 2 May 2016 09:44:40 +0000 Message-ID: <022901d1a456$c258d780$4001a8c0@gateway.2wire.net> From: t.petch To: Mahesh Jethanandani , "Acee Lindem (acee)" References: <20160329.212556.1290892363387952983.mbj@tail-f.com><3D60808E-EB76-4BE9-8281-B91B4FD83527@juniper.net><021201d191b1$757fbe40$4001a8c0@gateway.2wire.net><64FFAE09-4DF0-4D87-ADCF-2A319DB4F684@gmail.com> Date: Mon, 2 May 2016 10:37:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [109.153.79.147] X-ClientProxiedBy: DB5PR03CA0059.eurprd03.prod.outlook.com (10.164.34.27) To DB5PR07MB1621.eurprd07.prod.outlook.com (10.166.12.148) X-MS-Office365-Filtering-Correlation-Id: fdd264c5-1ae7-479c-e64f-08d3726e61dc X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1621; 2:jwVCr2/3axKXuLqWzV3kZvO11EOZnSrEiakRsQ/guSQSKH3XqoFCaP57nOC2J2yFUWV9YNq+GIimumsztY7u+Fo1NHzseCZrCMz0GcfGGOBQPB6QXz3VRB8s4CcWb6Am0stL2/1KFJh0X7pp9V0tY8DaYnWkRDUJvH0UX8Wer5geblRMhD6OgKjB0gF+oSkr; 3:MyZ+APiLW7KRf0RVtVYdEu9iYgn26U9b/lSzE1NRbriHzVP0RCTGBMYepkKTZXAhJrGl//06cwx4Qxopi0d87XD3cPOIcZ5bp6SLDMy8ZxAttV5il5Z/6AhNl6/zzAt0 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR07MB1621; X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1621; 25:P+yrMzv/MNoTHF2tFPHimr/b/AMBjuDmQxOaBmDe7AFrMBSLrRF1MNuTeYNCKyLVGpQruUG7RGonGJgcCDEVcBsHDBSpncsGqw8X/GUpOsPeTlh4b5HdPqaq2t7r1t8MHFBObKUBRaOBSw5j/NI/j5n84jOwC7UfAHC2rWB+Guiy8fQY4nwMjgi1aM82BewSlhu+ynIRLM3AnoIHae7tfK4ix4gEdUmMS1SqDXwNiV0hKOapE4fUDnGwt+psLoZTSgrOdeAIbmVcw+ELY4T4CbgmMmKbRwiAdflH1SzaFbYrob9i1IslKhewigskufwhtHqlTmkq9iEFt4Sfw4JoJoX/smR/Tu50MkiH53MYG/Talhd3AeiajBbN9m8A1yHCza2yUCsmVa+NnMisSSFqMAl0OfQDUNtP/btNR8/gxUJv5mpmCG+uHHibXOJoOVqdTglYT/TcRwxIN1SAcAehyVdFRAdjthS4LKKWQU7ytU34a73Lm7vE8ywo96TS93PWyr78EUDbjOe5XKaS+1dwdX+J1UINlxPgfh04sLSAEoOAuCKZPgNBD4kJhmPEWgMitEsqivrgHwrt1HBV9Gvs+sEK5vAyPX3UMJ4PCqcEBh3JrHnvIwoXmKhRhtJXGNTCH6JQPMjk+DSG2GgXaNA1oS32AVXcqop8/liXDIrwm4R9h5OtJWffcd42lkj1AfMD8/pDGmZKF7kuT6E1dq+HHdNnjG/HlcKYWV9oq19by8E= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008)(95692535739014); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(9101521093)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:DB5PR07MB1621; BCL:0; PCL:0; RULEID:; SRVR:DB5PR07MB1621; X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1621; 4:b/ZgWLM56GNLHlNdj4KOW3FOMOUhoW5QYAThCNch+PfBoPF3oLaI6V/6tqFbL4YhtWJKzca3mjEapZehQZhVE7p53qogLYnUPsIlQZ9KE8ZmuCIStKr1f7y5/1pT/Q4Hl7rN+gZ5VfuQtCEQVsEZEhiXozGGXo81S6aJrRm3MvYY8gnIh4ELfqT6H/Kw6tv3QLReNpo3gOgc9GeXRJsshmiyIj6WkWFsd0aER93UoLpN0ZnXJSwoUHeeh8El0JRY+DEKH5lrZRbOgMWeH2Q9UhiA0NlXgA/uIo9393HKdW6hxzPa6Y5/t+hOB1exEwRPuRrvxBjjinCYoS8GdSk/ybVcrIOJNRsn7hY7H6hQM/pRivLsMcrFwQoAJDu19cWQf+GDL/13gmck2BhUtBJClCpK7FLWiCdvKII4MF2IH1u6lHqPjyWgdq/LnbSxcDNx/eqpMi4LGpKNXcPOY1EU8Wkj2/+4+FCknwQLb0awsew= X-Forefront-PRVS: 0930AAFAD9 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(24454002)(13464003)(377454003)(2870700001)(61296003)(6116002)(33646002)(2906002)(42186005)(3846002)(5004730100002)(189998001)(1096002)(116806002)(44736004)(50226002)(1456003)(230783001)(1556002)(66066001)(19580395003)(19580405001)(47776003)(62236002)(50986999)(84392002)(50466002)(86362001)(93886004)(586003)(5001770100001)(81816999)(81166005)(15975445007)(44716002)(92566002)(76176999)(9686002)(23676002)(4326007)(5008740100001)(14496001)(81686999)(77096005)(7099028)(118906001)(74416001)(7726001)(4720700001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR07MB1621; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjVQUjA3TUIxNjIxOzIzOlhEWFRJdE1jaUVuS3hqeHRlRHFuQ3VTL2lo?= =?utf-8?B?Y1BmcjZtUDdvd0Z3Qk0vOEFlOVAxNUp6QTR4RDJTZ0loMUJCdE5OWjRTaGVD?= =?utf-8?B?NVZUdlg4NU1pZWIrSGcvRUJsWU9NaVRKLzYzdmhVMXU4YndJeHo2elN5K2N0?= =?utf-8?B?bUU3SEV2eUJsUXBubGlyNTZxRjhXa2FqdWRXMDJIbGJwQUowUm5oZEFDVTBs?= =?utf-8?B?aE95QWNlNXM1TDZIc0pwbTdQb1lLYzdBL2Q1WWhLWjJVM1ZkeXRWc3Fncks1?= =?utf-8?B?bkFmNUkrZ2pldkFMUktVZ3Y2QWNyd1prU1RiNHJYRTVjRVZseitYNHlDYmVW?= =?utf-8?B?MUhPY3VyV1hUZlo0eVRZSUtYN2RTcXQyVnJLZEdjQkNoQnpNWEFxV2FHWHhn?= =?utf-8?B?U2ZaMktOMTdvZlRWeTVkL3J6WG9zL2ZKRnNnMk1tQ2ErTFFCd1VuOGlmTnBL?= =?utf-8?B?a2NRQld0NWxoLzNBQlF3L3JjZjRRMjFHQXBqU25QRzZtYUtJcWJaWDR4UzVY?= =?utf-8?B?RjM4Qmc4WGJSMndaSjRIcW5pMExaSG1SQTlRcW9IZFpkdndCbU1aUEtIa0xG?= =?utf-8?B?aTVnaklMajNzUytwcWRhdXlvWFJacDZUYUlzN0s0MG55aGlmWjFZOG9iQjhk?= =?utf-8?B?MHpFRVhPdVd5US9SUjBEMkZJeGVsMEJxWVY3UUdFS0NEc3pHa2dKeE4raTVv?= =?utf-8?B?ZjdKdlVJS2Y1SW9LbXYyNzJQTXpMdHRrQWt5Ynp4bUgyQ2Zxa2FmcVJvWGtn?= =?utf-8?B?Qit4MDFqb3UxMEkvei9nd0I3bFRlT2Z2YUtLMTFqYUxlWURTb1VZVzNVYlF0?= =?utf-8?B?WW40SjRUb0Q4YlVtRkVSZ2tMdlQ2K3JudnBIYTVDeFFrR2tScTJlelczL3ZT?= =?utf-8?B?RkNFcEVyL2traWRHU2Fzb2FCeXZXZFlMUmdodUZzNFQxVXYrMElXZ1E3QWJl?= =?utf-8?B?dTFVRjc4NHBlQUV1MWk2T1E3NVVYTU5PWmV2L2kreW4yTmFOV3dJZFBtT0tZ?= =?utf-8?B?STM1WnZZRS96MzdyU09VSVFJdHVuUHNETGdNQm81Q1N0VHpFbUdrVDJUT29H?= =?utf-8?B?a1lPQ3Jzd0MyVkY2T25PVmRmdkpzbFhsUkxyVy9EQzBNVzREYlZGTlFHVm03?= =?utf-8?B?QmQyTDFaWDRDK0NIZmFIcTNMVU53T09UcHB5eGNzNUdOQWlXQVBhOW1hQUtS?= =?utf-8?B?SFBQek02L1RUY0llbE1oMzlLQVdOdU5ncjJRNkg3NnZUY1BtTUNTSm42bTdx?= =?utf-8?B?VlhIdnpyYkVDQ2dXamhEemFrekNuUURPMVIrSnc5L0I3d25jUnQ1WE11NHJt?= =?utf-8?B?MVRpTWNMNnFTTkFlRkhlZ1B3ME14UFZzdzJQZ2ZidWVtUGpKd1FwT2JaNDJS?= =?utf-8?B?d2pwTUdYb1JKMTBrZ0s3MC9OYjB2Tk1PcGFLRXY3eTRscWVFUFBER09wMmpV?= =?utf-8?B?czBSTk1PTUE4UjhyQ0Y5SzBCVzIrV0l1b2pwTXhEdDd6SXlGL200NDFMZGxT?= =?utf-8?B?YXhRQTVzdjFlZlNQeWV2VVpGNzZ2M1UxM09nK25NOXROS0xhVk9lbzJCTGpk?= =?utf-8?B?clFoWEVyQ203c05aNmVSTFllR2pYbDlWNjFkQzRGblBpSi9uUWJaUjJRNytV?= =?utf-8?B?bHVoT2t3Qlh1Nkk2SDhZUEkycUllQjh3YXhWSUhSNnZZSjBXUjRIQllGVStC?= =?utf-8?B?a1pqSm1EcFZoMFNhbzlBOW8wQjRMQmZWSUZOQUhGK00vNk1xbjVHSzQ1aThx?= =?utf-8?B?U0REY20yUURLa0pyYlZBUT09?= X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1621; 5:qPrlJ5jBABYRo9ymHKpCI7xCS1ZS0kBeL/r6xLiqSfurGI1m7D2Dq4xf+qO5r3k4z4lJvk7QXkKWtlzZPjo0HpaSTNm9P/w0WpGk/zzGfdLWoY6iQPJz6En0OBJgVMTwT6zJQLi3hEebbOSL9+Qpcw==; 24:u+PYDAm4Ys/LIGhB5Lfc939nk0ShpGt68y/jXP4us4sf76a5DNio+0oCnE+xmHIAWFv+jp+E6OPxkSs1PpulvBIBOjRfBuNOCSy6pubjVC8=; 7:lLmvL3vBTCGWCRnA/DO95JwuZCdOVwttyuO68ORl2drviTgXPy/V0hnjwCrDo/V73uWExj2HNZIDozABv0hLSuhsTUqUjO2Qp26fRIgfz+oZfUQhckl2YOpni/JhV5DAU3Fkg+ja7CBLuykgnEZdHTNbIUIzbvI0wmA7V4f/J0LCbjT8G/qjZ3RFtteOUsmc SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 May 2016 09:44:40.0395 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB1621 Archived-At: Cc: Routing WG , netconf@ietf.org, draft-ietf-rtgwg-keychain@ietf.org Subject: Re: [Netconf] mbj review of draft-ietf-netconf-restconf-server-model-09 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 09:44:47 -0000 ----- Original Message ----- From: "Mahesh Jethanandani" To: "Acee Lindem (acee)" Sent: Saturday, April 30, 2016 11:10 PM That or we could also rename it to protocol-key-chain to disambiguate it from system-key-chain. Mahesh Myself, I prefer 'rDNS'. If we have two models and one is about keys and the other is about certificates, as Acee says, then I would call one ...-keys and the other ...-certs. In this case that would be key(-)chain-keys and key(-)chain-certs. Or, to make it more distinct (and error-prone) key-chain-keys keychain-certs Tom Petch On Sat, Apr 30, 2016 at 11:40 AM, Acee Lindem (acee) wrote: > So hopefully we’ve put the issue of combining the module to bed for good… > If look at the date nodes for these two models, it is patently clear that > these serve two different purposes. > > What about the naming issue? I got a comment that I should take “routing-“ > back out due to the fact that this is what that these key-chains can be > used for many non-routing purposes. For example, BFD - > http://www.juniper.net/documentation/en_US/junos14.2/topics/reference/co nfiguration-statement/key-chain-edit-security-authentication-key-chains. html > > Thanks, > Acee > > From: rtgwg on behalf of Acee Lindem < > acee@cisco.com> > Date: Monday, April 18, 2016 at 6:04 PM > To: Mahesh Jethanandani > > From: Mahesh Jethanandani > Date: Monday, April 18, 2016 at 4:43 PM > > On Apr 18, 2016, at 10:25 AM, Acee Lindem (acee) wrote: > > I did get some negative feedback with respect to adding “routing-“ to the > model name since key chains are used for other non-routing applications as > well. > > One of those non-routing protocols is BFD. I am fine if the model is > called protocol-key-chain, but I wonder what happens the next entity > needing key-chain is not a protocol. > > The bigger question in my mind is, are these really different types of > key-chains models, or are we talking about one key-chain model? The rtgwg key chain model is the one we all know and love associated with > the graceful rollover of configurable keys. The netconf model is list of > certificates for a public key. Please look at the information content of > the two models. I hope I don’t have to answer this question again ;^) > > Acee From nobody Mon May 2 03:08:40 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 383CD12D10D; Mon, 2 May 2016 03:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hM-uUy6_CFT3; Mon, 2 May 2016 03:08:37 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E39512B051; Mon, 2 May 2016 03:08:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2152; q=dns/txt; s=iport; t=1462183717; x=1463393317; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=qYNjwZo7UsNfqnBChcG9cIQZVS3oeaiC5PHshIBzuqM=; b=aObHc6d6YvDwkslERxDWVWI7D1C3HcKfw4Ap1DTEZOx/lCm/rkM/2FmC eAr7+ZbXOiqj3zAnwrFFMiJ6RD1fnkSqCIe4k5rPddj0fC6m5sG6Cd2nL ynfMmiVFGkvSV+inrYQG36zztV/A1KkcRRiv7LhlxfiIlXNTCTXBlxqNt U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D6AQDjJSdX/4MNJK1ZA4M4U30GuW0BD?= =?us-ascii?q?YF2HoVyAhyBCDgUAQEBAQEBAWUnhEIBAQQjEUUOAgIBCA4CCAICJgICAhkXFRA?= =?us-ascii?q?CBA4FiCqneZAtAQEBAQEBAQEBAQEBAQEBAQEBAQEBFQR4iXGEJy0KJoI5glYFm?= =?us-ascii?q?BQBjheBZ4RNiF2PMAEeAQFCg2tsiAh/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,566,1454976000"; d="scan'208";a="97751676" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 May 2016 10:08:36 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u42A8aHT013128 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 2 May 2016 10:08:36 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 2 May 2016 06:08:35 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Mon, 2 May 2016 06:08:35 -0400 From: "Acee Lindem (acee)" To: Juergen Schoenwaelder Thread-Topic: [Netconf] mbj review of draft-ietf-netconf-restconf-server-model-09 Thread-Index: AQHRifX44uk/iivOuEmrTCpBJDXsvZ99sTmAgAKen+KAD4/+AIAAOu0AgAB6U4D//9OoAIASoseAgAB93QCAAJ/AAIAAIFsAgABYxYD///engIABDt6A///4eAA= Date: Mon, 2 May 2016 10:08:35 +0000 Message-ID: References: <64FFAE09-4DF0-4D87-ADCF-2A319DB4F684@gmail.com> <20160501074224.GB30851@elstar.local> <20160501145553.GA31451@elstar.local> <20160502063531.GA32842@elstar.local> In-Reply-To: <20160502063531.GA32842@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netconf@ietf.org" , "draft-ietf-rtgwg-yang-key-chain@ietf.org" , RTGWG Subject: Re: [Netconf] mbj review of draft-ietf-netconf-restconf-server-model-09 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 10:08:39 -0000 DQoNCk9uIDUvMi8xNiwgMjozNSBBTSwgIkp1ZXJnZW4gU2Nob2Vud2FlbGRlciINCjxqLnNjaG9l bndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+IHdyb3RlOg0KDQo+T24gU3VuLCBNYXkgMDEs IDIwMTYgYXQgMDY6MjY6MDdQTSArMDAwMCwgQWNlZSBMaW5kZW0gKGFjZWUpIHdyb3RlOg0KPj4g DQo+PiBIYXZlIHlvdSBoZWFyZCB0aGUgZXhwcmVzc2lvbiwg4oCcWW91IGNhbuKAmXQganVkZ2Ug YSBib29rIGJ5IGl0cyBjb3ZlcuKAnT8NCj4+DQo+DQo+Q2FuIHdlIHBsZWFzZSBiZSBzZXJpb3Vz IGFuZCBzaW1wbHkgaW1wcm92ZSB0aGluZ3M/DQoNCkhlcmUgaXMgdGhlIGFic3RyYWN0IHRvIHRo ZSBrZXktY2hhaW4gZHJhZnQ/IFdoYXQgaXMgdW5jbGVhcj8NCg0KDQogICBUaGlzIGRvY3VtZW50 IGRlc2NyaWJlcyB0aGUga2V5IGNoYWluIFlBTkcgZGF0YSBtb2RlbC4gIEEga2V5IGNoYWluDQog ICBpcyBhIGxpc3Qgb2YgZWxlbWVudHMgZWFjaCBjb250YWluaW5nIGEga2V5LCBzZW5kIGxpZmV0 aW1lLCBhY2NlcHQNCiAgIGxpZmV0aW1lLCBhbmQgYWxnb3JpdGhtLiAgQnkgcHJvcGVybHkgb3Zl cmxhcHBpbmcgdGhlIHNlbmQgYW5kIGFjY2VwdA0KICAgbGlmZXRpbWVzIG9mIG11bHRpcGxlIGtl eSBjaGFpbiBlbGVtZW50cywga2V5cyBhbmQgYWxnb3JpdGhtcyBtYXkgYmUNCiAgIGdyYWNlZnVs bHkgdXBkYXRlZC4gIEJ5IHJlcHJlc2VudGluZyB0aGVtIGluIGEgWUFORyBkYXRhIG1vZGVsLCBr ZXkNCiAgIGRpc3RyaWJ1dGlvbiBjYW4gYmUgYXV0b21hdGVkLiAgS2V5IGNoYWlucyBhcmUgY29t bW9ubHkgdXNlZCBmb3INCiAgIHJvdXRpbmcgcHJvdG9jb2wgYXV0aGVudGljYXRpb24gYW5kIG90 aGVyIGFwcGxpY2F0aW9ucy4gIEluIHNvbWUNCiAgIGFwcGxpY2F0aW9ucywgdGhlIHByb3RvY29s cyBkbyBub3QgdXNlIHRoZSBrZXkgY2hhaW4gZWxlbWVudCBrZXkNCiAgIGRpcmVjdGx5LCBidXQg cmF0aGVyIGEga2V5IGRlcml2YXRpb24gZnVuY3Rpb24gaXMgdXNlZCB0byBkZXJpdmUgYQ0KICAg c2hvcnQtbGl2ZWQga2V5IGZyb20gdGhlIGtleSBjaGFpbiBlbGVtZW50IGtleS4NCg0KDQpUaGUg ZHJhZnQgd2l0aCB0aGUgb3RoZXIgbW9kZWwgKG9mIHdoaWNoIHlvdSBhcmUgYW4gYXV0aG9yLCBp cyBtdWNoIGxlc3MNCmNsZWFyKSBhcyB0byB0aGUgdXNhZ2UgYW5kIGNvbnRleHQgb2Yga2V5LWNo YWlucy4gU3RhdGVtZW50cyBzaG91bGRu4oCZdCBiZQ0KbWFkZSBhcyByZXNvbHV0aW9uIG9mIHRo ZSBkcmFmdCBzb2xlbHkgYmFzZWQgb24gdGhlIGFic3RyYWN0IC0gd2hhdCBtb3JlDQpjYW4gSSBz YXnigKYgDQoNCkFjZWUgDQoNCg0KPg0KPlRoYW5rcywNCj4NCj4vanMNCj4NCj4tLSANCj5KdWVy Z2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21i SA0KPlBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5 IEJyZW1lbiB8IEdlcm1hbnkNCj5GYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRw Oi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4NCg0K From nobody Mon May 2 03:48:52 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8677F12D1D8; Mon, 2 May 2016 03:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CoCTo378mrOl; Mon, 2 May 2016 03:48:45 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11FA012D1CC; Mon, 2 May 2016 03:48: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 CA390E4F; Mon, 2 May 2016 12:48:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id g07fqcyqnqgP; Mon, 2 May 2016 12:48:41 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 2 May 2016 12:48:43 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1C9EC2004A; Mon, 2 May 2016 12:48:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id YHyAOb8ldeXq; Mon, 2 May 2016 12:48: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 9234A20047; Mon, 2 May 2016 12:48:40 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 93E943AC2F91; Mon, 2 May 2016 12:48:40 +0200 (CEST) Date: Mon, 2 May 2016 12:48:40 +0200 From: Juergen Schoenwaelder To: "t.petch" Message-ID: <20160502104840.GE33649@elstar.local> Mail-Followup-To: "t.petch" , Mahesh Jethanandani , "Acee Lindem (acee)" , Routing WG , netconf@ietf.org, draft-ietf-rtgwg-keychain@ietf.org References: <20160329.212556.1290892363387952983.mbj@tail-f.com> <3D60808E-EB76-4BE9-8281-B91B4FD83527@juniper.net> <021201d191b1$757fbe40$4001a8c0@gateway.2wire.net> <64FFAE09-4DF0-4D87-ADCF-2A319DB4F684@gmail.com> <022901d1a456$c258d780$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <022901d1a456$c258d780$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: draft-ietf-rtgwg-keychain@ietf.org, "Acee Lindem \(acee\)" , netconf@ietf.org, Routing WG Subject: Re: [Netconf] mbj review of draft-ietf-netconf-restconf-server-model-09 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 10:48:47 -0000 On Mon, May 02, 2016 at 10:37:46AM +0100, t.petch wrote: > ----- Original Message ----- > From: "Mahesh Jethanandani" > To: "Acee Lindem (acee)" > Sent: Saturday, April 30, 2016 11:10 PM > > > That or we could also rename it to protocol-key-chain to disambiguate it > from system-key-chain. > But then protocol-key-chain and system-key-chain seems to be largely confusing. I heard that one is for symmetric keys and the other for assymmetric keys. Or one is for keys and the other is for certificates? You seem to say it is protocol vs. system, which I am not sure is correct (or I simply keep being confused). /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 May 2 19:07:53 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D991C12D144 for ; Mon, 2 May 2016 19:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.206 X-Spam-Level: X-Spam-Status: No, score=-5.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqdzH264fjxA for ; Mon, 2 May 2016 19:07:51 -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 98F2012D10E for ; Mon, 2 May 2016 19:07:50 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CIZ99608; Tue, 03 May 2016 02:07:48 +0000 (GMT) Received: from SZXEMI413-HUB.china.huawei.com (10.86.210.41) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 3 May 2016 03:07:47 +0100 Received: from SZXEMI506-MBS.china.huawei.com ([169.254.6.161]) by SZXEMI413-HUB.china.huawei.com ([10.86.210.41]) with mapi id 14.03.0235.001; Tue, 3 May 2016 10:07:41 +0800 From: "fengchong (C)" To: Andy Bierman Thread-Topic: Some questions about restconf Thread-Index: AQHRaJApzU4dNuj6+ECAZ7XjLlP4eJ8uBvuAgB9ZbwCAUkzlAIAAlVsAgAaniEA= Date: Tue, 3 May 2016 02:07:40 +0000 Message-ID: <5756FB984666AD4BB8E1D63E2E3AA3D0845509@SZXEMI506-MBS.china.huawei.com> References: <56694FF2.1030108@ericsson.com> <56B87BD4.5060607@ericsson.com> <20160216.090033.283670312674076307.mbj@tail-f.com> <20160216114227.GC281@elstar.local> <20160307102636.GA41749@elstar.local> <20160428191506.GA25163@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.134.40.226] Content-Type: multipart/related; boundary="_004_5756FB984666AD4BB8E1D63E2E3AA3D0845509SZXEMI506MBSchina_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.572807F5.0051, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.6.161, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d2adda129c33c4cf5f0066ae0a0721a2 Archived-At: Cc: "netconf@ietf.org" Subject: [Netconf] Some questions about restconf X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 02:07:53 -0000 --_004_5756FB984666AD4BB8E1D63E2E3AA3D0845509SZXEMI506MBSchina_ Content-Type: multipart/alternative; boundary="_000_5756FB984666AD4BB8E1D63E2E3AA3D0845509SZXEMI506MBSchina_" --_000_5756FB984666AD4BB8E1D63E2E3AA3D0845509SZXEMI506MBSchina_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYW5keSwNCg0KSSBoYXZlIHNvbWUgcXVlc3Rpb25zIGFib3V0IHJlc3Rjb25mLg0KDQoNCjHv vI4gIExlYWYvbGVhZi1saXN0IGNhbiBiZSBkZWxldGVkIGJ5IHJlc3Rjb25mPw0KDQpJZiBhIG1v ZGVsIGRlZmluZWQgYXM6DQoNCkNvbnRhaW5lciBhIHsNCg0KTGlzdCBiIHsNCg0KICAgICBLZXkg YzsNCg0KICAgIExlYWYgYyB74oCmfQ0KDQogICAgTGVhZiBkIHvigKZ9DQoNCiAgICBMZWFmIGUg e+KApn0NCg0KfQ0KDQp9DQoNCg0KDQpJZiBJIHdhbnQgdG8gZGVsZXRlIGxlYWYgZCx0aGUgdXJs IHNob3VsZCBiZToNCg0KL2EvYj0xL2QNCg0KT3INCg0KL2EvYj0xIHsNCg0KICAgPGQvPg0KDQp9 DQoNCjIuIElmIEkgd2FudCB0byBkZWxldGUgbW9yZSB0aGFuIG9uZSBsZWFmcywgIHNob3VsZCBJ IHNlbmQgbWFueSByZXF1ZXN0cyBmb3IgZWFjaCBsZWFmPyBJcyB0aGVyZSBhIHdheSBvbmUgcmVx dWVzdCB0byBkZWxldGUgbWFueSBsZWFmcz8NCg0KMy4gY2FuIGRlbGV0ZSByZXF1ZXN0IGhhdmUg Ym9keT8NCiAgIEZvciBleGFtcGxlOg0KICBEZWxldGUgIGEvYj0xDQp7DQogIDxkPjE8L2Q+DQo8 ZT4yPC9lPg0KfQ0KDQpJZiBib2R5IGNhbiBiZSBhbGxvd2VkLCB0aGVuIHRoZSBjb250ZW50IG9m IGJvZHkgc2hvdWxkIGJlIGlnbm9yZWQgb3IgYmUgaW50ZXJwcmV0ZWQgYXMgc3VidHJlZSBmaWx0 ZXI/DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCuWGr+WGsg0K5Y2O5Li6 5oqA5pyv5pyJ6ZmQ5YWs5Y+4IEh1YXdlaSBUZWNobm9sb2dpZXMgQ28uLCBMdGQuDQpbQ29tcGFu eV9sb2dvXQ0KDQpQaG9uZToNCkZheDoNCk1vYmlsZTogMTg1MTkxMTczMTYNCkVtYWlsOiBmcmFu ay5mZW5nY2hvbmdAaHVhd2VpLmNvbQ0K5Zyw5Z2A77ya5Y2X5Lqs5biC6L2v5Lu25aSn6YGTMTAx 5Y+35Y2O5Li65Y2X5Lqs5Z+65ZywIOmCrue8lu+8mjIxMDAwMQ0KSHVhd2VpIFRlY2hub2xvZ2ll cyBDby4sIEx0ZC4NCg0KaHR0cDovL3d3dy5odWF3ZWkuY29tDQo= --_000_5756FB984666AD4BB8E1D63E2E3AA3D0845509SZXEMI506MBSchina_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTrljY7mlofnu4bpu5E7DQoJcGFub3NlLTE6MiAxIDYgMCA0IDEgMSAxIDEgMTt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAx IDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWNjuaWh+e7hum7kSI7DQoJcGFu b3NlLTE6MiAxIDYgMCA0IDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWu i+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVk LCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJh Z3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1z dHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cgl0ZXh0LWluZGVudDoyMS4wcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrl rovkvZM7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxlLW5hbWU6aG9lbnpiO30NCnNwYW4uRW1h aWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBw dDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVm aW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjExNDg1NDg1NzU7DQoJbXNvLWxp c3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE3NjA1ODA5NDggMTUyMTUy NDcwMCA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcw MyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRleHQ6 JTHvvI47DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjE4LjBwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30N Cm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIyMDUwIiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIGFuZHks PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgaGF2ZSBzb21lIHF1ZXN0aW9u cyBhYm91dCByZXN0Y29uZi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxp c3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNv LWxpc3Q6SWdub3JlIj4x77yOPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkxlYWYv bGVhZi1saXN0IGNhbiBiZSBkZWxldGVkIGJ5IHJlc3Rjb25mPzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0 O3RleHQtaW5kZW50OjBjbSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5JZiBhIG1vZGVsIGRlZmluZWQgYXM6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4w cHQ7dGV4dC1pbmRlbnQ6MGNtIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkNvbnRhaW5lciBhIHs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdDt0ZXh0 LWluZGVudDo5LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5MaXN0IGIgezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0O3RleHQtaW5kZW50Ojku MHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBLZXkgYzs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdDt0 ZXh0LWluZGVudDo5LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsgTGVhZiBjIHvigKZ9PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4t bGVmdDoxOC4wcHQ7dGV4dC1pbmRlbnQ6OS4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7ICZuYnNwO0xlYWYgZCB7 4oCmfTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0O3RleHQtaW5kZW50OjkuMHB0Ij48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyAm bmJzcDtMZWFmIGUge+KApn0NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0O3RleHQtaW5kZW50OjkuMHB0 Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi Pn08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdDt0ZXh0LWluZGVudDowY20iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+fTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTgu MHB0O3RleHQtaW5kZW50OjBjbSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdDt0ZXh0LWluZGVu dDowY20iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SWYgSSB3YW50IHRvIGRlbGV0ZSBsZWFmIGQsdGhlIHVybCBzaG91bGQgYmU6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJn aW4tbGVmdDoxOC4wcHQ7dGV4dC1pbmRlbnQ6MGNtIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi9hL2I9MS9kPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4w cHQ7dGV4dC1pbmRlbnQ6MGNtIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPk9yPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQ7dGV4dC1pbmRlbnQ6MGNt Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi Pi9hL2I9MSB7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQ7dGV4dC1pbmRlbnQ6MGNtIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNw OyAmbHQ7ZC8mZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQ7dGV4dC1pbmRlbnQ6MGNtIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPn08bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Mi4gSWYgSSB3YW50IHRvIGRlbGV0ZSBtb3Jl IHRoYW4gb25lIGxlYWZzLCAmbmJzcDtzaG91bGQgSSBzZW5kIG1hbnkgcmVxdWVzdHMgZm9yIGVh Y2ggbGVhZj8gSXMgdGhlcmUgYSB3YXkgb25lIHJlcXVlc3QgdG8gZGVsZXRlIG1hbnkgbGVhZnM/ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjMuIGNhbiBkZWxldGUgcmVxdWVz dCBoYXZlIGJvZHk/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDsmbmJzcDsgRm9yIGV4YW1wbGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDsgRGVsZXRlICZuYnNwO2EvYj0xDQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPns8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOyAmbHQ7ZCZndDsxJmx0Oy9kJmd0OzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmx0O2UmZ3Q7MiZsdDsvZSZndDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPn08bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+SWYgYm9keSBjYW4gYmUgYWxsb3dlZCwgdGhlbiB0aGUgY29udGVudCBv ZiBib2R5IHNob3VsZCBiZSBpZ25vcmVkIG9yIGJlIGludGVycHJldGVkIGFzIHN1YnRyZWUgZmls dGVyPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxl PSJ0ZXh0LWFsaWduOmNlbnRlciI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj4NCjxociBzaXplPSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+ PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTrljY7mlofnu4bpu5E7Y29sb3I6YmxhY2siPuWGr+WGsjxzcGFuIGxhbmc9 IkVOLVVTIj48YnI+DQo8L3NwYW4+5Y2O5Li65oqA5pyv5pyJ6ZmQ5YWs5Y+4PHNwYW4gbGFuZz0i RU4tVVMiPiBIdWF3ZWkgVGVjaG5vbG9naWVzIENvLiwgTHRkLjxicj4NCjwvc3Bhbj48L3NwYW4+ PCEtLVtpZiBndGUgdm1sIDFdPjx2OnNoYXBldHlwZSBpZD0iX3gwMDAwX3Q3NSIgY29vcmRzaXpl PSIyMTYwMCwyMTYwMCIgbzpzcHQ9Ijc1IiBvOnByZWZlcnJlbGF0aXZlPSJ0IiBwYXRoPSJtQDRA NWxANEAxMUA5QDExQDlANXhlIiBmaWxsZWQ9ImYiIHN0cm9rZWQ9ImYiPg0KPHY6c3Ryb2tlIGpv aW5zdHlsZT0ibWl0ZXIiIC8+DQo8djpmb3JtdWxhcz4NCjx2OmYgZXFuPSJpZiBsaW5lRHJhd24g cGl4ZWxMaW5lV2lkdGggMCIgLz4NCjx2OmYgZXFuPSJzdW0gQDAgMSAwIiAvPg0KPHY6ZiBlcW49 InN1bSAwIDAgQDEiIC8+DQo8djpmIGVxbj0icHJvZCBAMiAxIDIiIC8+DQo8djpmIGVxbj0icHJv ZCBAMyAyMTYwMCBwaXhlbFdpZHRoIiAvPg0KPHY6ZiBlcW49InByb2QgQDMgMjE2MDAgcGl4ZWxI ZWlnaHQiIC8+DQo8djpmIGVxbj0ic3VtIEAwIDAgMSIgLz4NCjx2OmYgZXFuPSJwcm9kIEA2IDEg MiIgLz4NCjx2OmYgZXFuPSJwcm9kIEA3IDIxNjAwIHBpeGVsV2lkdGgiIC8+DQo8djpmIGVxbj0i c3VtIEA4IDIxNjAwIDAiIC8+DQo8djpmIGVxbj0icHJvZCBANyAyMTYwMCBwaXhlbEhlaWdodCIg Lz4NCjx2OmYgZXFuPSJzdW0gQDEwIDIxNjAwIDAiIC8+DQo8L3Y6Zm9ybXVsYXM+DQo8djpwYXRo IG86ZXh0cnVzaW9ub2s9ImYiIGdyYWRpZW50c2hhcGVvaz0idCIgbzpjb25uZWN0dHlwZT0icmVj dCIgLz4NCjxvOmxvY2sgdjpleHQ9ImVkaXQiIGFzcGVjdHJhdGlvPSJ0IiAvPg0KPC92OnNoYXBl dHlwZT48djpzaGFwZSBpZD0icmlkSW1nIiBvOnNwaWQ9Il94MDAwMF9zMTAyNiIgdHlwZT0iI194 MDAwMF90NzUiIGFsdD0iQ29tcGFueV9sb2dvIiBzdHlsZT0ncG9zaXRpb246YWJzb2x1dGU7bWFy Z2luLWxlZnQ6MDttYXJnaW4tdG9wOjA7d2lkdGg6NzYuNXB0O2hlaWdodDoyNHB0O3otaW5kZXg6 MTt2aXNpYmlsaXR5OnZpc2libGU7bXNvLXdyYXAtc3R5bGU6c3F1YXJlO21zby13cmFwLWRpc3Rh bmNlLWxlZnQ6MDttc28td3JhcC1kaXN0YW5jZS10b3A6MDttc28td3JhcC1kaXN0YW5jZS1yaWdo dDowO21zby13cmFwLWRpc3RhbmNlLWJvdHRvbTowO21zby1wb3NpdGlvbi1ob3Jpem9udGFsOmxl ZnQ7bXNvLXBvc2l0aW9uLWhvcml6b250YWwtcmVsYXRpdmU6dGV4dDttc28tcG9zaXRpb24tdmVy dGljYWw6YWJzb2x1dGU7bXNvLXBvc2l0aW9uLXZlcnRpY2FsLXJlbGF0aXZlOmxpbmUnIG86YWxs b3dvdmVybGFwPSJmIj4NCjx2OmltYWdlZGF0YSBzcmM9ImNpZDppbWFnZTAwMS5qcGdAMDFEMUE1 MjMuOUY3M0Y0NzAiIG86aHJlZj0iZmlsZTovLy9DOlxVc2Vyc1xmMDAzNjAyMThcQXBwbGljYXRp b24lMjBEYXRhXE1pY3Jvc29mdFxTaWduYXR1cmVzXGNvbXBhbnlfbG9nby5qcGciIC8+DQo8dzp3 cmFwIHR5cGU9InNxdWFyZSIgYW5jaG9yeT0ibGluZSIvPg0KPC92OnNoYXBlPjwhW2VuZGlmXS0t PjwhW2lmICF2bWxdPjxpbWcgd2lkdGg9IjEwMiIgaGVpZ2h0PSIzMiIgc3JjPSJjaWQ6aW1hZ2Uw MDEuanBnQDAxRDFBNTIzLjlGNzNGNDcwIiBhbGlnbj0ibGVmdCIgYWx0PSJDb21wYW55X2xvZ28i IHY6c2hhcGVzPSJyaWRJbWciPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk65Y2O5paH57uG6buRO2NvbG9yOmJsYWNrIj48YnI+ DQo8YnI+DQpQaG9uZTogPGJyPg0KRmF4OiA8YnI+DQpNb2JpbGU6IDE4NTE5MTE3MzE2PGJyPg0K RW1haWw6IGZyYW5rLmZlbmdjaG9uZ0BodWF3ZWkuY29tPGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWNjuaWh+e7hum7kTtjb2xvcjpibGFjayI+ 5Zyw5Z2A77ya5Y2X5Lqs5biC6L2v5Lu25aSn6YGTPHNwYW4gbGFuZz0iRU4tVVMiPjEwMTwvc3Bh bj7lj7fljY7kuLrljZfkuqzln7rlnLAg6YKu57yW77yaPHNwYW4gbGFuZz0iRU4tVVMiPjIxMDAw MTxicj4NCkh1YXdlaSBUZWNobm9sb2dpZXMgQ28uLCBMdGQuPGJyPg0KPGJyPg0KaHR0cDovL3d3 dy5odWF3ZWkuY29tPC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPiA8bzpwPg0KPC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_5756FB984666AD4BB8E1D63E2E3AA3D0845509SZXEMI506MBSchina_-- --_004_5756FB984666AD4BB8E1D63E2E3AA3D0845509SZXEMI506MBSchina_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=6737; creation-date="Tue, 03 May 2016 02:07:40 GMT"; modification-date="Tue, 03 May 2016 02:07:40 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --_004_5756FB984666AD4BB8E1D63E2E3AA3D0845509SZXEMI506MBSchina_-- From nobody Tue May 3 06:48:36 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37AF212D1E2 for ; Tue, 3 May 2016 06:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYjRYoAdpK4A for ; Tue, 3 May 2016 06:48:32 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 495D312B010 for ; Tue, 3 May 2016 06:48:31 -0700 (PDT) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id 13D8AD9FA4BE7; Tue, 3 May 2016 13:48:28 +0000 (GMT) Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id u43DmTl4015515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 May 2016 13:48:29 GMT Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id u43DmTsm008982 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 May 2016 13:48:29 GMT Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.238]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Tue, 3 May 2016 09:48:29 -0400 From: "Sterne, Jason (Nokia - CA)" To: EXT Xiang Li , "'Martin Bjorklund'" , "wivory@Brocade.com" Thread-Topic: [Netconf] Clarification request for NETCONF edit-config default-operation replace Thread-Index: AQHRlyYGiZoT03uS4U+O6QebXc6r0J+hZVpggACXP4CABVTvsA== Date: Tue, 3 May 2016 13:48:29 +0000 Message-ID: References: <3b242c800dfc464aaad760ca1e8fc11c@EMEAWP-EXMB12.corp.brocade.com> <20160415.144413.1614538486330526270.mbj@tail-f.com> <401695abd7214cde8e0c50b1da9bad19@EMEAWP-EXMB12.corp.brocade.com> <20160415.164925.242005632968560972.mbj@tail-f.com> <013301d1a273$ed74d250$c85e76f0$@seguesoft.com> In-Reply-To: <013301d1a273$ed74d250$c85e76f0$@seguesoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Clarification request for NETCONF edit-config default-operation replace X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 13:48:35 -0000 In my first question I meant "using an ": Is there no way to delete (or replace) the entire contents of the datastore= using an (and without using without having to = explicitly list every single top level node ? >From the description of the default-operation 'replace' it seems it is poss= ible via the default operation: replace: The configuration data in the parameter completely replaces the configuration in the target datastore. This is useful for loading previously saved configuration data. But can replace of the entire contents be done without replace as the defau= lt operation ? Or delete of the entire contents ? The RFC doesn't seem to= clear on whether we can use an operation on the node: (c) and (d) have a delete operation on a leaf (in (c) is it inherited) but = are providing a value for the leaf at the same time. What is the meaning of= the value ? That seems like an error to me. We should warn the client tha= t they've done something unexpected (the client may have been intending to = do something different than deleting that leaf). I can see how that works when the leaf is a key leaf in a list. But it see= ms like an error for just a plain leaf. I'm also not convinced about (f) and (g). Wrt your analogy of a directory = with files: you can delete a container in NETCONF and that automatically de= letes any children, grandchildren and so on (the entire subtree). It seems= strange that there is no way to delete (or replace) the entire contents of= a list or leaf-list. Or perhaps I'm misinterpreting the description of the replace and delete op= erations in RFC6241 (the sentences "only the configuration actually present= in the parameter is affected" and "if and only if the configurati= on data currently exists" are giving me some pause here). There aren't man= y examples illustrating delete & replace in the RFC. Regards, Jason -----Original Message----- From: EXT Xiang Li [mailto:xiangli@seguesoft.com]=20 Sent: Friday, April 29, 2016 20:05 To: Sterne, Jason (Nokia - CA); 'Martin Bjorklund'; wivory@Brocade.com Cc: netconf@ietf.org Subject: RE: [Netconf] Clarification request for NETCONF edit-config defaul= t-operation replace -----Original Message----- From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Sterne, Jason = (Nokia - CA) Sent: Friday, April 29, 2016 2:12 PM To: Martin Bjorklund ; wivory@Brocade.com Cc: netconf@ietf.org Subject: Re: [Netconf] Clarification request for NETCONF edit-config defaul= t-operation replace Is there no way to delete the entire contents of the datastore without havi= ng to explicitly list every single top level node ? e.g. with no default operation (i.e. merge): Or With default operation =3D delete: Similarly -> Is there no way to replace the entire contents of the datastor= e ? [XL] I think< copy-config> or can do this. About the cases below shouldn't (c) and (d) return an error ? They contain= data for an object that is being deleted. (e) seems like the correct way = to do it. [XL] I think Martin's explanation is correct. My understanding is that if t= he value does not match, then the would return an error since the = no matching data node found (yes I view this as a content-match). Or I migh= t be totally wrong here, i.e., the value does not matter in any way as Mart= in said? (f) and (g) surprise me. If I can an entire leaf-list or list= by just specifying the tag for the leaf-list/list name, why doesn't delete= get rid of the entire leaf-list/list ? (if you specify a specific list entry/member in a delete it is basically ju= st a content match node but otherwise you've selected the entire list no ?)= . [XL] I also thought that I can delete a list entry by specifying all key n= odes and their values (i.e., list entry's instance ID). If no values of key= nodes are given, then the entire list entries matched and all of them shou= ld be deleted. Although Martin's explanation also makes sense here, that is= , you can't just delete a key node yet if it is still used by non-key node= s. Just like deleting a directory when the directory still contains files. But= , in any case, I would still like that I can delete a list entry by giving= the list entry's IID since we can unmistakably identify a list entry by g= iven a list entry's IID (i.e. , all key nodes and their corresponding value= s). I think such a delete operation would be useful, just like "rm -rf d= irectory". --Xiang -----Original Message----- From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Martin Bjorklu= nd Sent: Friday, April 15, 2016 10:49 To: wivory@Brocade.com Cc: netconf@ietf.org Subject: Re: [Netconf] Clarification request for NETCONF edit-config defaul= t-operation replace William Ivory wrote: > OK - I think it might help if I gave some specific examples, with my=20 > understanding of what would get deleted and you can tell me if I'm=20 > correct or not. Apologies for length, but I'd like to avoid any=20 > confusion by not spelling out my queries, and I'm struggling to get a=20 > clear picture of how this all works with all the different=20 > permutations! >=20 > Let's take a configuration like this: >=20 > > leafValue > leaflistValueOne > leaflistValueTwo > > firstEntryKey > firstEntryLeaf > > > secondEntryKey > secondEntryLeaf > > >=20 > --- >=20 > (a) topCont, default operation delete >=20 > With the default operation set to delete: >=20 > > > >=20 > =3D> topCont, and everything under it, would be deleted Yes. > (b) topCont, operation delete >=20 > With the default operation set to none: >=20 > > > >=20 > =3D> topCont, and everything under it, would be deleted >=20 Yes. > --- >=20 > (c) aLeaf delete, operation specified for topCont >=20 > With the default operation set to none: >=20 > > > leafValue > >=20 > =3D> Will delete aLeaf node. If this leaves topCont empty, then topCont= =20 > would be removed. If topCont still contains other elements, topCont=20 > would remain? No. This deletes the topCont and everything below it. > --- >=20 > (d) aLeaf delete, operation specified for aLeaf >=20 > With the default operation set to none: >=20 > > > leafValue > >=20 > =3D> Will delete aLeaf node. If this leaves topCont empty, then topCont= =20 > would be removed unless it is a presence node. Yes (s/would/may/) > --- >=20 > (e) aLeaf delete, operation specified for aLeaf, but no value given >=20 > With the default operation set to none: >=20 > > > > >=20 > =3D> Would this delete aLeaf, and, as per (d), conditionally ,=20 > or must the value of the leaf be specified? >=20 Yes, this would delete aLeaf. The value doesn't matter. > --- >=20 > (f) aLeafListEntry >=20 > Is there a way to delete all leaflist entries without specifying them=20 > individually, eg: >=20 > No >=20 > ... or, assuming there are other sibling nodes such that we can't just=20 > delete topCont, must I specify each individual leaflist element I wish=20 > to remove? >=20 > --- >=20 > (g) aListEntry >=20 > As per leaflist entries, is there a way to delete all entries=20 > generically No. >, or must each be specified? Yes. > Separately, if I delete a non-key node inside a list entry, I assume=20 > that just deletes that node. If I delete the list's key node, then=20 > presumably that removes the complete entry, eg: >=20 > > > > firstEntryKey > > Yes > Would the following achieve the same, ie removal of this list entry: >=20 > > > > firstEntryKey > > Hmm. I would say that this results in an error - deleting just the key of = a list is not possible. /martin >=20 > --- >=20 > Thanks for bearing with me, >=20 > William >=20 > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: 15 April 2016 13:44 > To: William Ivory > Cc: netconf@ietf.org > Subject: Re: [Netconf] Clarification request for NETCONF edit-config=20 > default-operation replace >=20 > William Ivory wrote: > > Hi Martin, > >=20 > > Thanks - I think that the section on 'replace' under=20 > > 'default-operation' could do with being clarified next time the RFC=20 > > is updated then. > >=20 > > I'd appreciate some further clarification on what exactly ' only the=20 > > configuration actually present in the parameter is affected' > > means in practice. > >=20 > > First, the general pattern of examples which use=20 > > 'operation=3D' is that this command is put in the 'parent' > > element's tag, ie the tag which specifies 'delete' is *not* deleted. >=20 > No. For example: >=20 > > 192.0.2.4 > >=20 > will delete the "interface" node with the name "192.0.2.4" >=20 > It does NOT keep the "interface" node and just delete the "name" node. >=20 > > How then would you delete a top-level container? >=20 > >=20 >=20 >=20 > /martin >=20 >=20 > > The examples have a > > '' element but in cases where there are multiple top-level=20 > > nodes, some of which are optional in the configuration (ie not=20 > > presence containers), is it possible to delete these nodes? > >=20 > > Secondly, if I'm correct that the 'delete' operation would only=20 > > affect nodes below the one with the delete operation, is it possible=20 > > to construct an edit-config PDU that would delete all child nodes=20 > > without having to explicitly specify each one? Or is the only way=20 > > to achieve this either to explicitly specify all config to be=20 > > removed, or to do a copy-config explicitly specifying all config=20 > > that is not to be deleted. > >=20 > > Thanks, > >=20 > > William > >=20 > > -----Original Message----- > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > Sent: 14 April 2016 09:34 > > To: William Ivory > > Cc: netconf@ietf.org > > Subject: Re: [Netconf] Clarification request for NETCONF edit-config=20 > > default-operation replace > >=20 > > Hi, > >=20 > > William Ivory wrote: > > > Hi, > > >=20 > > > I'd appreciate clarification of how the NETCONF edit-config=20 > > > command should work with default-operation set to 'replace'. For=20 > > > the most part, the edit-config section is clear that config will=20 > > > only be replaced if explicitly overwritten (ie if you provide=20 > > > replacement config for given nodes). However, the section on=20 > > > default-operation is less clear: > > >=20 > > > The parameter is optional, but if provided, > > > it has one of the following values: > > >=20 > > > merge: The configuration data in the parameter is > > > merged with the configuration at the corresponding=20 > > > level in > > > the target datastore. This is the default behavior. > > >=20 > > > replace: The configuration data in the parameter > > > completely replaces the configuration in the target > > > datastore. This is useful for loading previously saved > > > configuration data. > > >=20 > > > Specifically, while 'merge' states that merge happesn with=20 > > > 'configuration as the corresponding level', 'replace' states that=20 > > > is 'completely replaces' the configuration, suggesting that it=20 > > > will remove ALL existing configuration regardless of what is=20 > > > explicitly provided as the replacement. Is that correct, or is=20 > > > 'replace' meant to have equivalent semantics to 'merge' ie it will=20 > > > only replace configuration when an explicit replacement is=20 > > > provided. In other words, if the latter case is correct, all it=20 > > > does is remove the requirement to specify the operation in each element of new config. > >=20 > > Yes the latter is correct. Note that the definition of "replace" as=20 > > an operation says: > >=20 > > Unlike a > > operation, which replaces the entire target > > configuration, only the configuration actually present in > > the parameter is affected. > >=20 > >=20 > > /martin > >=20 >=20 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From nobody Tue May 3 08:22:51 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E571B12D8D2 for ; Tue, 3 May 2016 08:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ft2kw6m5ObfK for ; Tue, 3 May 2016 08:22:39 -0700 (PDT) Received: from p3plsmtpa09-07.prod.phx3.secureserver.net (p3plsmtpa09-07.prod.phx3.secureserver.net [173.201.193.236]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A19F612D8F6 for ; Tue, 3 May 2016 08:20:54 -0700 (PDT) Received: from xiangliToshiba ([98.222.132.219]) by p3plsmtpa09-07.prod.phx3.secureserver.net with id prLs1s00C4kAYmS01rLtEC; Tue, 03 May 2016 08:20:54 -0700 From: "Xiang Li" To: "'Sterne, Jason \(Nokia - CA\)'" , "'Martin Bjorklund'" , References: <3b242c800dfc464aaad760ca1e8fc11c@EMEAWP-EXMB12.corp.brocade.com> <20160415.144413.1614538486330526270.mbj@tail-f.com> <401695abd7214cde8e0c50b1da9bad19@EMEAWP-EXMB12.corp.brocade.com> <20160415.164925.242005632968560972.mbj@tail-f.com> <013301d1a273$ed74d250$c85e76f0$@seguesoft.com> In-Reply-To: Date: Tue, 3 May 2016 10:20:52 -0500 Message-ID: <01f401d1a54f$621dbad0$26593070$@seguesoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGSOxKMZqwo2XAGR88n924RhoJQ0gIEXHSeAdW+gCQB7IYm0AFIIDruAvtAVf8BpO/jKZ/IndDQ Content-Language: en-us Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] Clarification request for NETCONF edit-config default-operation replace X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 15:22:50 -0000 Hi > -----Original Message----- >... > In my first question I meant "using an ": > > Is there no way to delete (or replace) the entire contents of the datastore > using an (and without using without having to > explicitly list every single top level node ? > I don't think edit-config is designed to do that. To delete a datastore, use , although can't be deleted. To replace the *entire config*, use . > From the description of the default-operation 'replace' it seems it is possible > via the default operation: > replace: The configuration data in the parameter > completely replaces the configuration in the target > datastore. This is useful for loading previously saved > configuration data. No. The definition of "replace" as an operation says clearly: Unlike a operation, which replaces the entire target configuration, only the configuration actually present in the parameter is affected. In other words, the only replaces the data nodes that exist in the target and for nodes that are in in the but not in the target, they are created. Other nodes that exist in the device but are not present in the of the are NOT affected in any way (this is the key difference with , where they are removed because it operates on the *entire* datastore.) > But can replace of the entire contents be done without replace as the default > operation ? Not with the default "replace" operation, nor with the normal "replace" operation. The default "replace" operation has no additional semantics compared to The "operation" parameter > Or delete of the entire contents ? The RFC doesn't seem to clear > on whether we can use an operation on the node: > > The description of says: the target configuration is not necessarily replaced, as with the message. Instead, the target configuration is changed in accordance with the source's data and requested operations. In other words, the parameter in will not be valid if you do not specify it (assuming no url capability) or make it empty, as in your example. config: A hierarchy of configuration data as defined by one of the device's data models. The contents MUST be placed in an appropriate namespace, to allow the device to detect the appropriate data model, and the contents MUST follow the constraints of that data model, as defined by its capability definition. > (c) and (d) have a delete operation on a leaf (in (c) is it inherited) but are > providing a value for the leaf at the same time. What is the meaning of the > value ? That seems like an error to me. We should warn the client that > they've done something unexpected (the client may have been intending to > do something different than deleting that leaf). > I can see how that works when the leaf is a key leaf in a list. But it seems like > an error for just a plain leaf. No. I think the value is actually used by . For example, RFC6241 has this example: Delete the configuration for an interface named "Ethernet0/0" from the running configuration: none Ethernet0/0 Without specifying value so that the device can find an exact matched interface, this won't work. In other words, my understanding is that if a value is given, and the device can't find a match then then the delete will fail with a error. > I'm also not convinced about (f) and (g). Wrt your analogy of a directory with > files: you can delete a container in NETCONF and that automatically deletes > any children, grandchildren and so on (the entire subtree). It seems strange > that there is no way to delete (or replace) the entire contents of a list or leaf- > list. I don't necessarily disagree with you on this one. I was simply suggesting that the protocol perhaps should have a simple way to allow me to remove list entries. In particular I think it would be useful it allows: 1) to delete a specific list entry by providing a list entry's Instance ID ( all key nodes and corresponding values). 2) to delete all entries of a list by just providing all key nodes in the . Best, --Xiang > Or perhaps I'm misinterpreting the description of the replace and delete > operations in RFC6241 (the sentences "only the configuration actually > present in the parameter is affected" and "if and only if the > configuration data currently exists" are giving me some pause here). There > aren't many examples illustrating delete & replace in the RFC. > > Regards, > Jason > > -----Original Message----- > From: EXT Xiang Li [mailto:xiangli@seguesoft.com] > Sent: Friday, April 29, 2016 20:05 > To: Sterne, Jason (Nokia - CA); 'Martin Bjorklund'; wivory@Brocade.com > Cc: netconf@ietf.org > Subject: RE: [Netconf] Clarification request for NETCONF edit-config default- > operation replace > > > > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Sterne, > Jason (Nokia - CA) > Sent: Friday, April 29, 2016 2:12 PM > To: Martin Bjorklund ; wivory@Brocade.com > Cc: netconf@ietf.org > Subject: Re: [Netconf] Clarification request for NETCONF edit-config default- > operation replace > > Is there no way to delete the entire contents of the datastore without having > to explicitly list every single top level node ? > > e.g. > with no default operation (i.e. merge): > > > Or > With default operation = delete: > > > Similarly -> Is there no way to replace the entire contents of the datastore ? > > [XL] I think< copy-config> or can do this. > > About the cases below shouldn't (c) and (d) return an error ? They contain > data for an object that is being deleted. (e) seems like the correct way to do > it. > > [XL] I think Martin's explanation is correct. My understanding is that if the > value does not match, then the would return an error since the no > matching data node found (yes I view this as a content-match). Or I might be > totally wrong here, i.e., the value does not matter in any way as Martin said? > > (f) and (g) surprise me. If I can an entire leaf-list or list by just > specifying the tag for the leaf-list/list name, why doesn't delete get rid of the > entire leaf-list/list ? > (if you specify a specific list entry/member in a delete it is basically just a > content match node but otherwise you've selected the entire list no ?). > > [XL] I also thought that I can delete a list entry by specifying all key nodes > and their values (i.e., list entry's instance ID). If no values of key nodes are > given, then the entire list entries matched and all of them should be deleted. > Although Martin's explanation also makes sense here, that is, you can't just > delete a key node yet if it is still used by non-key nodes. > Just like deleting a directory when the directory still contains files. But, in any > case, I would still like that I can delete a list entry by giving the list entry's IID > since we can unmistakably identify a list entry by given a list entry's IID (i.e. , > all key nodes and their corresponding values). I think such a delete > operation would be useful, just like "rm -rf directory". > > --Xiang > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Martin > Bjorklund > Sent: Friday, April 15, 2016 10:49 > To: wivory@Brocade.com > Cc: netconf@ietf.org > Subject: Re: [Netconf] Clarification request for NETCONF edit-config default- > operation replace > > William Ivory wrote: > > OK - I think it might help if I gave some specific examples, with my > > understanding of what would get deleted and you can tell me if I'm > > correct or not. Apologies for length, but I'd like to avoid any > > confusion by not spelling out my queries, and I'm struggling to get a > > clear picture of how this all works with all the different > > permutations! > > > > Let's take a configuration like this: > > > > > > leafValue > > leaflistValueOne > > leaflistValueTwo > > > > firstEntryKey > > firstEntryLeaf > > > > > > secondEntryKey > > secondEntryLeaf > > > > > > > > --- > > > > (a) topCont, default operation delete > > > > With the default operation set to delete: > > > > > > > > > > > > => topCont, and everything under it, would be deleted > > Yes. > > > (b) topCont, operation delete > > > > With the default operation set to none: > > > > > > > > > > > > => topCont, and everything under it, would be deleted > > > > Yes. > > > --- > > > > (c) aLeaf delete, operation specified for topCont > > > > With the default operation set to none: > > > > > > > > leafValue > > > > > > => Will delete aLeaf node. If this leaves topCont empty, then topCont > > would be removed. If topCont still contains other elements, topCont > > would remain? > > No. This deletes the topCont and everything below it. > > > --- > > > > (d) aLeaf delete, operation specified for aLeaf > > > > With the default operation set to none: > > > > > > > > leafValue > > > > > > => Will delete aLeaf node. If this leaves topCont empty, then topCont > > would be removed unless it is a presence node. > > Yes (s/would/may/) > > > --- > > > > (e) aLeaf delete, operation specified for aLeaf, but no value given > > > > With the default operation set to none: > > > > > > > > > > > > > > => Would this delete aLeaf, and, as per (d), conditionally , > > or must the value of the leaf be specified? > > > > Yes, this would delete aLeaf. The value doesn't matter. > > > --- > > > > (f) aLeafListEntry > > > > Is there a way to delete all leaflist entries without specifying them > > individually, eg: > > > > > > No > > > > > > ... or, assuming there are other sibling nodes such that we can't just > > delete topCont, must I specify each individual leaflist element I wish > > to remove? > > > > --- > > > > (g) aListEntry > > > > As per leaflist entries, is there a way to delete all entries > > generically > > No. > > >, or must each be specified? > > Yes. > > > Separately, if I delete a non-key node inside a list entry, I assume > > that just deletes that node. If I delete the list's key node, then > > presumably that removes the complete entry, eg: > > > > > > > > > > firstEntryKey > > > > > > Yes > > > Would the following achieve the same, ie removal of this list entry: > > > > > > > > > > firstEntryKey > > > > > > Hmm. I would say that this results in an error - deleting just the key of a list is > not possible. > > > > /martin > > > > > > > --- > > > > Thanks for bearing with me, > > > > William > > > > -----Original Message----- > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > Sent: 15 April 2016 13:44 > > To: William Ivory > > Cc: netconf@ietf.org > > Subject: Re: [Netconf] Clarification request for NETCONF edit-config > > default-operation replace > > > > William Ivory wrote: > > > Hi Martin, > > > > > > Thanks - I think that the section on 'replace' under > > > 'default-operation' could do with being clarified next time the RFC > > > is updated then. > > > > > > I'd appreciate some further clarification on what exactly ' only the > > > configuration actually present in the parameter is affected' > > > means in practice. > > > > > > First, the general pattern of examples which use > > > 'operation=' is that this command is put in the 'parent' > > > element's tag, ie the tag which specifies 'delete' is *not* deleted. > > > > No. For example: > > > > > > 192.0.2.4 > > > > > > will delete the "interface" node with the name "192.0.2.4" > > > > It does NOT keep the "interface" node and just delete the "name" node. > > > > > How then would you delete a top-level container? > > > > > > > > > > > > /martin > > > > > > > The examples have a > > > '' element but in cases where there are multiple top-level > > > nodes, some of which are optional in the configuration (ie not > > > presence containers), is it possible to delete these nodes? > > > > > > Secondly, if I'm correct that the 'delete' operation would only > > > affect nodes below the one with the delete operation, is it possible > > > to construct an edit-config PDU that would delete all child nodes > > > without having to explicitly specify each one? Or is the only way > > > to achieve this either to explicitly specify all config to be > > > removed, or to do a copy-config explicitly specifying all config > > > that is not to be deleted. > > > > > > Thanks, > > > > > > William > > > > > > -----Original Message----- > > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > > Sent: 14 April 2016 09:34 > > > To: William Ivory > > > Cc: netconf@ietf.org > > > Subject: Re: [Netconf] Clarification request for NETCONF edit-config > > > default-operation replace > > > > > > Hi, > > > > > > William Ivory wrote: > > > > Hi, > > > > > > > > I'd appreciate clarification of how the NETCONF edit-config > > > > command should work with default-operation set to 'replace'. For > > > > the most part, the edit-config section is clear that config will > > > > only be replaced if explicitly overwritten (ie if you provide > > > > replacement config for given nodes). However, the section on > > > > default-operation is less clear: > > > > > > > > The parameter is optional, but if > provided, > > > > it has one of the following values: > > > > > > > > merge: The configuration data in the parameter is > > > > merged with the configuration at the corresponding > > > > level > in > > > > the target datastore. This is the default behavior. > > > > > > > > replace: The configuration data in the parameter > > > > completely replaces the configuration in the target > > > > datastore. This is useful for loading previously saved > > > > configuration data. > > > > > > > > Specifically, while 'merge' states that merge happesn with > > > > 'configuration as the corresponding level', 'replace' states that > > > > is 'completely replaces' the configuration, suggesting that it > > > > will remove ALL existing configuration regardless of what is > > > > explicitly provided as the replacement. Is that correct, or is > > > > 'replace' meant to have equivalent semantics to 'merge' ie it will > > > > only replace configuration when an explicit replacement is > > > > provided. In other words, if the latter case is correct, all it > > > > does is remove the requirement to specify the operation in each > element of new config. > > > > > > Yes the latter is correct. Note that the definition of "replace" as > > > an operation says: > > > > > > Unlike a > > > operation, which replaces the entire target > > > configuration, only the configuration actually present in > > > the parameter is affected. > > > > > > > > > /martin > > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Tue May 3 08:38:11 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFD3212D966 for ; Tue, 3 May 2016 08:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v_bjYcTQjhM8 for ; Tue, 3 May 2016 08:38:03 -0700 (PDT) Received: from p3plsmtpa08-09.prod.phx3.secureserver.net (p3plsmtpa08-09.prod.phx3.secureserver.net [173.201.193.110]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F7C412D956 for ; Tue, 3 May 2016 08:38:03 -0700 (PDT) Received: from xiangliToshiba ([98.222.132.219]) by p3plsmtpa08-09.prod.phx3.secureserver.net with id pre11s0084kAYmS01re2EB; Tue, 03 May 2016 08:38:02 -0700 From: "Xiang Li" To: "'Sterne, Jason \(Nokia - CA\)'" References: <3b242c800dfc464aaad760ca1e8fc11c@EMEAWP-EXMB12.corp.brocade.com> <20160415.144413.1614538486330526270.mbj@tail-f.com> <401695abd7214cde8e0c50b1da9bad19@EMEAWP-EXMB12.corp.brocade.com> <20160415.164925.242005632968560972.mbj@tail-f.com> <013301d1a273$ed74d250$c85e76f0$@seguesoft.com> <01f401d1a54f$621dbad0$26593070$@seguesoft.com> In-Reply-To: <01f401d1a54f$621dbad0$26593070$@seguesoft.com> Date: Tue, 3 May 2016 10:38:00 -0500 Message-ID: <000001d1a551$c6f64f60$54e2ee20$@seguesoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGSOxKMZqwo2XAGR88n924RhoJQ0gIEXHSeAdW+gCQB7IYm0AFIIDruAvtAVf8BpO/jKQJyCfiGn7Uj24A= Content-Language: en-us Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] Clarification request for NETCONF edit-config default-operation replace X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 15:38:10 -0000 > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Xiang Li > Sent: Tuesday, May 03, 2016 10:21 AM > To: 'Sterne, Jason (Nokia - CA)' ; 'Martin > Bjorklund' ; wivory@Brocade.com > Cc: netconf@ietf.org > Subject: Re: [Netconf] Clarification request for NETCONF edit-config default- > operation replace > > Hi > > > -----Original Message----- > >... > > In my first question I meant "using an ": > > > > Is there no way to delete (or replace) the entire contents of the > datastore > > using an (and without using without having > > to explicitly list every single top level node ? > > > > I don't think edit-config is designed to do that. > > To delete a datastore, use , although can't be > deleted. > To replace the *entire config*, use . > > > From the description of the default-operation 'replace' it seems it is > possible > > via the default operation: > > replace: The configuration data in the parameter > > completely replaces the configuration in the target > > datastore. This is useful for loading previously saved > > configuration data. > > > No. The definition of "replace" as an operation says clearly: > > Unlike a operation, which replaces the entire target > configuration, only the configuration actually present in > the parameter is affected. > > In other words, the only replaces the data nodes that exist in the > target and for nodes that are in in the but not in the > target, they are created. Other nodes that exist in the device but are not > present in the of the are NOT affected in any way > (this is the key difference with , where they are removed > because it operates on the *entire* datastore.) > > > But can replace of the entire contents be done without replace as the > default > > operation ? > > Not with the default "replace" operation, nor with the normal "replace" > operation. > The default "replace" operation has no additional semantics compared to The > "operation" parameter > > > Or delete of the entire contents ? The RFC doesn't seem to clear on > > whether we can use an operation on the node: > > > > > > > The description of says: the target configuration is not > necessarily replaced, as with the message. Instead, the target > configuration is changed in accordance with the source's data and requested > operations. > > In other words, the parameter in will not be valid if > you do not specify it (assuming no url capability) or make it empty, as in your > example. *if* the device accepts such a in the edit-config request, then it probably should do the following: Upon receiving a returns a data-missing error since no match is found to delete. Upon receiving a returns but effectively no-op. -Xiang > config: A hierarchy of configuration data as defined by one of > the device's data models. The contents MUST be placed in an > appropriate namespace, to allow the device to detect the > appropriate data model, and the contents MUST follow the > constraints of that data model, as defined by its capability > definition. > > > > (c) and (d) have a delete operation on a leaf (in (c) is it inherited) > > but > are > > providing a value for the leaf at the same time. What is the meaning > > of > the > > value ? That seems like an error to me. We should warn the client > > that they've done something unexpected (the client may have been > > intending to do something different than deleting that leaf). > > I can see how that works when the leaf is a key leaf in a list. But > > it > seems like > > an error for just a plain leaf. > > > No. I think the value is actually used by . For example, > RFC6241 > has this example: > > Delete the configuration for an interface named "Ethernet0/0" from > the running configuration: > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > none > > > > Ethernet0/0 > > > > > > > > Without specifying value so that the device can find an exact matched > interface, this won't work. > > In other words, my understanding is that if a value is given, and the device > > can't find a match then then the delete will fail with a error. > > > I'm also not convinced about (f) and (g). Wrt your analogy of a > > directory > with > > files: you can delete a container in NETCONF and that automatically > deletes > > any children, grandchildren and so on (the entire subtree). It seems > strange > > that there is no way to delete (or replace) the entire contents of a > > list > or leaf- > > list. > > I don't necessarily disagree with you on this one. > > I was simply suggesting that the protocol perhaps should have a simple way > to allow me to remove list entries. In particular I think it would be useful it > allows: > 1) to delete a specific list entry by providing a list entry's Instance ID ( all key > nodes and corresponding values). > 2) to delete all entries of a list by just providing all key nodes in the . > > Best, > --Xiang > > > > > Or perhaps I'm misinterpreting the description of the replace and > > delete operations in RFC6241 (the sentences "only the configuration > > actually present in the parameter is affected" and "if and > > only if the configuration data currently exists" are giving me some pause > here). > There > > aren't many examples illustrating delete & replace in the RFC. > > > > Regards, > > Jason > > > > -----Original Message----- > > From: EXT Xiang Li [mailto:xiangli@seguesoft.com] > > Sent: Friday, April 29, 2016 20:05 > > To: Sterne, Jason (Nokia - CA); 'Martin Bjorklund'; wivory@Brocade.com > > Cc: netconf@ietf.org > > Subject: RE: [Netconf] Clarification request for NETCONF edit-config > default- > > operation replace > > > > > > > > -----Original Message----- > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Sterne, > > Jason (Nokia - CA) > > Sent: Friday, April 29, 2016 2:12 PM > > To: Martin Bjorklund ; wivory@Brocade.com > > Cc: netconf@ietf.org > > Subject: Re: [Netconf] Clarification request for NETCONF edit-config > default- > > operation replace > > > > Is there no way to delete the entire contents of the datastore without > having > > to explicitly list every single top level node ? > > > > e.g. > > with no default operation (i.e. merge): > > > > > > Or > > With default operation = delete: > > > > > > Similarly -> Is there no way to replace the entire contents of the > datastore ? > > > > [XL] I think< copy-config> or can do this. > > > > About the cases below shouldn't (c) and (d) return an error ? They > contain > > data for an object that is being deleted. (e) seems like the correct > > way > to do > > it. > > > > [XL] I think Martin's explanation is correct. My understanding is that > > if > the > > value does not match, then the would return an error since > > the no matching data node found (yes I view this as a content-match). > > Or I might > be > > totally wrong here, i.e., the value does not matter in any way as > > Martin > said? > > > > (f) and (g) surprise me. If I can an entire leaf-list or > list by just > > specifying the tag for the leaf-list/list name, why doesn't delete get > > rid > of the > > entire leaf-list/list ? > > (if you specify a specific list entry/member in a delete it is > > basically > just a > > content match node but otherwise you've selected the entire list no ?). > > > > [XL] I also thought that I can delete a list entry by specifying all > > key > nodes > > and their values (i.e., list entry's instance ID). If no values of key > nodes are > > given, then the entire list entries matched and all of them should be > deleted. > > Although Martin's explanation also makes sense here, that is, you > > can't > just > > delete a key node yet if it is still used by non-key nodes. > > Just like deleting a directory when the directory still contains files. > But, in any > > case, I would still like that I can delete a list entry by giving the > list entry's IID > > since we can unmistakably identify a list entry by given a list > > entry's > IID (i.e. , > > all key nodes and their corresponding values). I think such a delete > > operation would be useful, just like "rm -rf directory". > > > > --Xiang > > -----Original Message----- > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Martin > > Bjorklund > > Sent: Friday, April 15, 2016 10:49 > > To: wivory@Brocade.com > > Cc: netconf@ietf.org > > Subject: Re: [Netconf] Clarification request for NETCONF edit-config > default- > > operation replace > > > > William Ivory wrote: > > > OK - I think it might help if I gave some specific examples, with my > > > understanding of what would get deleted and you can tell me if I'm > > > correct or not. Apologies for length, but I'd like to avoid any > > > confusion by not spelling out my queries, and I'm struggling to get > > > a clear picture of how this all works with all the different > > > permutations! > > > > > > Let's take a configuration like this: > > > > > > > > > leafValue > > > leaflistValueOne > > > leaflistValueTwo > > > > > > firstEntryKey > > > firstEntryLeaf > > > > > > > > > secondEntryKey > > > secondEntryLeaf > > > > > > > > > > > > --- > > > > > > (a) topCont, default operation delete > > > > > > With the default operation set to delete: > > > > > > > > > > > > > > > > > > => topCont, and everything under it, would be deleted > > > > Yes. > > > > > (b) topCont, operation delete > > > > > > With the default operation set to none: > > > > > > > > > > > > > > > > > > => topCont, and everything under it, would be deleted > > > > > > > Yes. > > > > > --- > > > > > > (c) aLeaf delete, operation specified for topCont > > > > > > With the default operation set to none: > > > > > > > > > > > > leafValue > > > > > > > > > => Will delete aLeaf node. If this leaves topCont empty, then > > > topCont would be removed. If topCont still contains other elements, > > > topCont would remain? > > > > No. This deletes the topCont and everything below it. > > > > > --- > > > > > > (d) aLeaf delete, operation specified for aLeaf > > > > > > With the default operation set to none: > > > > > > > > > > > > leafValue > > > > > > > > > => Will delete aLeaf node. If this leaves topCont empty, then > > > topCont would be removed unless it is a presence node. > > > > Yes (s/would/may/) > > > > > --- > > > > > > (e) aLeaf delete, operation specified for aLeaf, but no value given > > > > > > With the default operation set to none: > > > > > > > > > > > > > > > > > > => Would this delete aLeaf, and, as per (d), conditionally > > > , or must the value of the leaf be specified? > > > > > > > Yes, this would delete aLeaf. The value doesn't matter. > > > > > --- > > > > > > (f) aLeafListEntry > > > > > > Is there a way to delete all leaflist entries without specifying > > > them individually, eg: > > > > > > > > > > No > > > > > > > > > > ... or, assuming there are other sibling nodes such that we can't > > > just delete topCont, must I specify each individual leaflist element > > > I wish to remove? > > > > > > --- > > > > > > (g) aListEntry > > > > > > As per leaflist entries, is there a way to delete all entries > > > generically > > > > No. > > > > >, or must each be specified? > > > > Yes. > > > > > Separately, if I delete a non-key node inside a list entry, I assume > > > that just deletes that node. If I delete the list's key node, then > > > presumably that removes the complete entry, eg: > > > > > > > > > > > > > > > firstEntryKey > > > > > > > > > > Yes > > > > > Would the following achieve the same, ie removal of this list entry: > > > > > > > > > > > > > > > firstEntryKey > > > > > > > > > > Hmm. I would say that this results in an error - deleting just the > > key of > a list is > > not possible. > > > > > > > > /martin > > > > > > > > > > > > --- > > > > > > Thanks for bearing with me, > > > > > > William > > > > > > -----Original Message----- > > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > > Sent: 15 April 2016 13:44 > > > To: William Ivory > > > Cc: netconf@ietf.org > > > Subject: Re: [Netconf] Clarification request for NETCONF edit-config > > > default-operation replace > > > > > > William Ivory wrote: > > > > Hi Martin, > > > > > > > > Thanks - I think that the section on 'replace' under > > > > 'default-operation' could do with being clarified next time the > > > > RFC is updated then. > > > > > > > > I'd appreciate some further clarification on what exactly ' only > > > > the configuration actually present in the parameter is affected' > > > > means in practice. > > > > > > > > First, the general pattern of examples which use > > > > 'operation=' is that this command is put in the 'parent' > > > > element's tag, ie the tag which specifies 'delete' is *not* deleted. > > > > > > No. For example: > > > > > > > > > 192.0.2.4 > > > > > > > > > will delete the "interface" node with the name "192.0.2.4" > > > > > > It does NOT keep the "interface" node and just delete the "name" node. > > > > > > > How then would you delete a top-level container? > > > > > > > > > > > > > > > > > > /martin > > > > > > > > > > The examples have a > > > > '' element but in cases where there are multiple top-level > > > > nodes, some of which are optional in the configuration (ie not > > > > presence containers), is it possible to delete these nodes? > > > > > > > > Secondly, if I'm correct that the 'delete' operation would only > > > > affect nodes below the one with the delete operation, is it > > > > possible to construct an edit-config PDU that would delete all > > > > child nodes without having to explicitly specify each one? Or is > > > > the only way to achieve this either to explicitly specify all > > > > config to be removed, or to do a copy-config explicitly specifying > > > > all config that is not to be deleted. > > > > > > > > Thanks, > > > > > > > > William > > > > > > > > -----Original Message----- > > > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > > > Sent: 14 April 2016 09:34 > > > > To: William Ivory > > > > Cc: netconf@ietf.org > > > > Subject: Re: [Netconf] Clarification request for NETCONF > > > > edit-config default-operation replace > > > > > > > > Hi, > > > > > > > > William Ivory wrote: > > > > > Hi, > > > > > > > > > > I'd appreciate clarification of how the NETCONF edit-config > > > > > command should work with default-operation set to 'replace'. > > > > > For the most part, the edit-config section is clear that config > > > > > will only be replaced if explicitly overwritten (ie if you > > > > > provide replacement config for given nodes). However, the > > > > > section on default-operation is less clear: > > > > > > > > > > The parameter is optional, but if > > provided, > > > > > it has one of the following values: > > > > > > > > > > merge: The configuration data in the parameter is > > > > > merged with the configuration at the corresponding > > > > > level > > in > > > > > the target datastore. This is the default behavior. > > > > > > > > > > replace: The configuration data in the parameter > > > > > completely replaces the configuration in the target > > > > > datastore. This is useful for loading previously saved > > > > > configuration data. > > > > > > > > > > Specifically, while 'merge' states that merge happesn with > > > > > 'configuration as the corresponding level', 'replace' states > > > > > that is 'completely replaces' the configuration, suggesting that > > > > > it will remove ALL existing configuration regardless of what is > > > > > explicitly provided as the replacement. Is that correct, or is > > > > > 'replace' meant to have equivalent semantics to 'merge' ie it > > > > > will only replace configuration when an explicit replacement is > > > > > provided. In other words, if the latter case is correct, all it > > > > > does is remove the requirement to specify the operation in each > > element of new config. > > > > > > > > Yes the latter is correct. Note that the definition of "replace" > > > > as an operation says: > > > > > > > > Unlike a > > > > operation, which replaces the entire target > > > > configuration, only the configuration actually present in > > > > the parameter is affected. > > > > > > > > > > > > /martin > > > > > > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Tue May 3 16:18:59 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B304412DA20 for ; Tue, 3 May 2016 16:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xY-gFrhv9dXd for ; Tue, 3 May 2016 16:18:56 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21F2F12DA26 for ; Tue, 3 May 2016 16:18:56 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id 77so16903657pfv.2 for ; Tue, 03 May 2016 16:18:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZHH32ZCdtpeWHPgQ/Xoq3aDskcfZ0sEfmpmPhv30SG8=; b=C0eFostYYrbQpPzE6lnYW6nBj8l+2I4FiIPrRJ16D6UcRy1g9hO+uxmdnpNU1iY/jy U4DvFyzrUDzLD5D1mjozx/xcYNvfCs+sPj5m8qVdyEAo53xujZv2Lex242qUmhSetwAx jpmqeFNPElICS2lzJK9rekUGwDOScBZ/qetKPch0j3hUzoUuojPhmNVvWWzd7zNSFsno y7ADREqbIEnPbWb9OJf8UUnGDqeSHO3Lyn2tmG3sg7r6wDPS+Z3MpYXWHQaWUUQ07dzU Ee7Y+l9wioeFuIWbWnPoWDgYw/y1C1NtccXC8x9WFmCZaIYbbVGz90YPLS8Snb/hWqTX Hqpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZHH32ZCdtpeWHPgQ/Xoq3aDskcfZ0sEfmpmPhv30SG8=; b=VAq1IsStL+I0ziEWdzCaGP1Y6hTCJxh9Kzwrhv5EjuS7TR8Ih9t52DyJwvDOhHzKFR F+Fbb9FYkV/4RZSdLi0uYK9DNzJEfAGB+VkdjIo9wc7oFcai13APuNQoSXHOf8167YKT M0PJCoOFwJGQrF1mGiNF6kgrComO1AyLbBwGa7QUEDZSt9aTOCY+QXUM+Fm6mO+HAmTu lTr8mBPSuSkiYtqcOIqMVFPAM3ffkBH1XQKBaR1v+SxZFSQdSyz72pVKhD08+Ccv/Jm/ oEDeoFkOddW7iiIDb/DwqotvIB/U0ly62gLD5mVPZCdtwsAgnUvzm4UNN7chiQHcWAGI bBGw== X-Gm-Message-State: AOPr4FWhjYTIgyQNDfOHG2D0F/grN4jp2DlbQ9GDi4k9/Vh9JbecbvZQ1fYJiBKEIDnIBg== X-Received: by 10.98.25.74 with SMTP id 71mr7518224pfz.94.1462317535724; Tue, 03 May 2016 16:18:55 -0700 (PDT) Received: from dhcp-171-71-145-53.cisco.com (dhcp-171-71-145-53.cisco.com. [171.71.145.53]) by smtp.gmail.com with ESMTPSA id z17sm664972pfi.61.2016.05.03.16.18.54 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 May 2016 16:18:55 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: text/plain; charset=us-ascii From: Mahesh Jethanandani X-Priority: 3 In-Reply-To: <022801d1a456$c20e12e0$4001a8c0@gateway.2wire.net> Date: Tue, 3 May 2016 16:18:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <92BAF631-804E-45AD-89A3-48059966B2F4@gmail.com> References: <3C88D813-7674-47C4-A6AF-E02C368CE71C@juniper.net> <20160429.100226.431840842419129504.mbj@tail-f.com> <20160429081529.GA26297@elstar.local> <20160429.102116.1627845264494578220.mbj@tail-f.com> <00aa01d1a209$2d165a20$4001a8c0@gateway.2wire.net> <9E3A9643-2348-42AA-A6B0-6FB9F13D1A29@juniper.net> <022801d1a456$c20e12e0$4001a8c0@gateway.2wire.net> To: "t.petch" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] Confirming the decision to split the server-model draft into several drafts. X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 23:18:58 -0000 It appears that a virtual interim meeting might help this discussion and = the discussion around key-chain models.=20 Consider this a two week notice for the meeting. Details will be sent = out later. Mahesh & Mehmet > On May 2, 2016, at 2:10 AM, t.petch wrote: >=20 > ----- Original Message ----- > From: "Kent Watsen" > To: "Andy Bierman" > Cc: > Sent: Friday, April 29, 2016 7:57 PM >=20 >>=20 >> I'm open to an interim to discuss, if that is what the WG would like > to do. >>=20 >> But quickly, the motivating reason for the middle-two drafts (and the > modules they define) to be separated is so that configuration models = for > other (besides NC/RC) ssh/tls-based client/servers (e.g., syslog, = smtp, > http) could use the ietf-[ssh|tls]-[client|server] groupings without > having to have a normative reference to an RFC who's title ostensibly > regards NC/RC. >=20 > Kent >=20 > As a reason, I think that that is abysmal. >=20 > RFC should be aimed at a target audience and, for technology, the > primary audience is those who will implement it (often a rather small > number) closely followed by those who use it and need to understand = how > it works in detail (a rather larger number). >=20 > You are saying that it should be written for its aesthetic appeal to > standards writers; standards writers should swallow their feelings and > lump it - their job is to satisfy implementers and users (as above). >=20 > As Andy said, three seems the obvious number (unless that leads to a > complex mesh of dependencies which, as I alluded to before, makes = things > hard to understand; currently, I do not think that that is the case). >=20 > Tom Petch >=20 >=20 >> Kent >>=20 >> From: Andy Bierman > >> Date: Friday, April 29, 2016 at 1:07 PM >> To: Kent Watsen > >> Cc: "netconf@ietf.org" > netconf@ietf.orgmailto:netconf@ietf.org >>=20 >> On Fri, Apr 29, 2016 at 8:49 AM, Kent Watsen > > wrote: >>=20 >> To answer so of the questions posted here: >>=20 >> The motivation is to have well-defined RFCs that make good > referenceable targets for future work. In particular, there may be > other transports besides SSH and TLS, or there may be other high-level > protocols that use these two transports. >>=20 >> Regarding the intention of which modules would be in which drafts, I > just realized that a made a mistake before, also in the slides = presented > in BA. Below is correct, there's actually five drafts (not four) = having > the following YANG modules: >>=20 >> There is currently 1 draft (draft-ietf-netconf-server-model-09) > correct? >>=20 >> draft-ietf-netconf-system-keychain >> - ietf-system-keychain // this we have already today >>=20 >> draft-ietf-netconf-ssh-client-server >> - ietf-ssh-client // this would be added >> - ietf-ssh-server // this we have already today >>=20 >> draft-ietf-netconf-tls-client-server >> - ietf-tls-client // this would be added >> - ietf-tls-server // this we have already today >>=20 >> draft-ietf-netconf-netconf-client-server >>=20 >> - ietf-netconf-client // this would be added >> - ietf-netconf-server // this we have already today >>=20 >> draft-ietf-netconf-restconf-client-server >> - ietf-restconf-client // this would be added >> - ietf-restconf-server // this we have already today >>=20 >> Looking over the current draft, it seems like 3 RFCs would be more > intuitive: >>=20 >> - keychain >> - NETCONF server >> - RESTCONF server >>=20 >> IMO lumping TLS and SSH together does not imply that the RFC needs >> to be updated later to add new transports. They can be added as > needed >> via augments. >>=20 >> The 5 module split is not easy to follow. It is not easy to >> see how the modules relate to each other. Going to a 9 module >> split spread over 5 RFCs would probably be impossible to read. >>=20 >> I am not sure what is in each of the "client" modules. >> IMO we should have a virtual interim on server-model-09, >> before you start refactoring. >>=20 >> Andy >>>=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf Mahesh Jethanandani mjethanandani@gmail.com From nobody Wed May 4 13:03:53 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F36EC12D54C for ; Wed, 4 May 2016 13:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.206 X-Spam-Level: X-Spam-Status: No, score=-1.206 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, RDNS_NONE=0.793] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hansfords.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZAae7G28oe5 for ; Wed, 4 May 2016 13:03:49 -0700 (PDT) Received: from server.myfast.site (unknown [212.113.130.91]) (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 BEAB212D6A0 for ; Wed, 4 May 2016 13:03:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hansfords.net; s=default; h=Content-Type:MIME-Version:Message-ID:Date: Subject:In-Reply-To:References:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=DErHXqjnpkSXjeRUakjPkN8xfWne4qevX8wsShIxRLo=; b=BUTbfhiejpyBziLFbZPS1m8D8 OxNXSvw8uzMfh2nmPsazccnDur2VoPU7V8ojdechpS2QoTbkGjUNpkqpLUBqISnF38shQWO+BFf92 qpQg0LxiC5VzOJned3Ao78Ws4hLzpWE5IP8KhXbzVLpM9Bd+UeW79CGLwRvVPa17zNGIuEzhrIl2H Z0buiEY73Bf6nQM6ydLx78/82q33kHMwXCUmFfIYMb6PZ/dMeDgCK0Q+csuOssns31X41yCKVJNQ0 MQQOJnSIKniNaI+fWmPnyr5F75ykdpTRhBKiipFUH41HFEnpWgMvZwcKSKOAALqr3JE2vRPUpEpkW VFeZCP3hg==; Received: from hansfords.plus.com ([84.92.116.209]:64699 helo=Vanguard) by server.myfast.site with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1ay31K-003ptB-BH; Wed, 04 May 2016 21:03:42 +0100 From: "Jonathan Hansford" To: "'Ersue, Mehmet \(Nokia - DE/Munich\)'" , "'Netconf'" , , "'Juergen Schoenwaelder'" References: In-Reply-To: Date: Wed, 4 May 2016 21:03:42 +0100 Message-ID: <0e8d01d1a640$0ee76ae0$2cb640a0$@hansfords.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0E8E_01D1A648.70AD0B60" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQG1DadkhniYAVBPsFD464AMHNPDcQJzNgTlAp8OdOCfudJwcA== Content-Language: en-gb X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.myfast.site X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - hansfords.net X-Get-Message-Sender-Via: server.myfast.site: authenticated_id: jonathan@hansfords.net X-Authenticated-Sender: server.myfast.site: jonathan@hansfords.net Archived-At: Subject: Re: [Netconf] IPR Poll for draft-ietf-netconf-restconf-12 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 20:03:52 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0E8E_01D1A648.70AD0B60 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Apologies for the delay. I'm not aware of any IPR. =20 Jonathan =20 From: Ersue, Mehmet (Nokia - DE/Munich) [mailto:mehmet.ersue@nokia.com]=20 Sent: 01 May 2016 01:15 To: Netconf ; jonathan@hansfords.net; rex@cisco.com; = Juergen Schoenwaelder Cc: EXT Benoit Claise Subject: RE: IPR Poll for draft-ietf-netconf-restconf-12 =20 Hi Jonathan, Juergen, Rex, =20 AFAICS you did not respond to the request below. As registered contributor to the RESTCONF draft we do require your IPR = statement. =20 > If you are listed as a document author or contributor (CCed) please = respond to this email ON NETCONF MAILLIST explicitly regardless of = whether or not you are aware of=20 > any relevant IPR. The document will not advance to the next stage = until a response has been received from _each author and contributor_. =20 I hope you will respond soon and we can start the publication process = officially. =20 Thanks. =20 Mehmet=20 =20 From: "Ersue, Mehmet (Nokia - DE/Munich)" > Date: Sunday, April 24, 2016 at 5:49 PM To: "netconf@ietf.org " > Cc: EXT Ladislav Lhotka >, Juergen = Schoenwaelder >, "rwilton@cisco.com = " >, "jonathan@hansfords.net = " >, "rex@cisco.com = " >, EXT Andy Bierman = >, Martin Bjorklund = >, Kent Watsen = > Subject: IPR Poll for draft-ietf-netconf-restconf-12 =20 Dear Authors and Contributors of RESTCONF Draft, Dear WG Members, =20 please state on the maillist clearly whether you own or are aware of any = IPR that applies to draft-ietf-netconf-restconf-12.txt. For the opposite case, please state also on the maillist clearly if you = don=E2=80=99t own or are not aware of any IPR that applies to the = draft-ietf-netconf-restconf. =20 If you own or are aware of any IPR that applies to the = draft-ietf-netconf-restconf please clarify whether=20 this IPR been disclosed in compliance with IETF IPR rules (see RFCs = 3979, 4879, 3669 and 5378 for more details). If not please do so asap. =20 If you are listed as a document author or contributor (CCed)please = respond to this email ON NETCONF MAILLIST explicitly regardless of = whether or not you are aware of any relevant IPR. The document will not = advance to the next stage until a response has been received from _each = authorand contributor_. =20 If you are not listed as an author or contributor but are on NETCONF WG = maillist, then please explicitly respond if you are aware of any IPR = that has not yet been disclosed in conformance with IETF rules. =20 Thank you for kind support. =20 Regards, Mehmet & Mahesh =20 ------=_NextPart_000_0E8E_01D1A648.70AD0B60 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Apologies for the delay. I'm not aware of = any IPR.

 

Jonathan

 

From:<= /b> Ersue, = Mehmet (Nokia - DE/Munich) [mailto:mehmet.ersue@nokia.com] =
Sent: 01 May 2016 01:15
To: Netconf = <netconf@ietf.org>; jonathan@hansfords.net; rex@cisco.com; Juergen = Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Cc: = EXT Benoit Claise <bclaise@cisco.com>
Subject: RE: IPR = Poll for = draft-ietf-netconf-restconf-12

 

Hi Jonathan, Juergen, Rex,

 

AFAICS you did not respond to the request = below.

As registered contributor to the RESTCONF draft we do require your IPR = statement.

 

> If you are listed as a document author or contributor (CCed) = please respond to this email ON NETCONF MAILLIST explicitly regardless = of whether or not you are aware of

> any relevant IPR. The document will not advance to the next stage = until a response has been received from _each author and = contributor_.

 

I hope you will respond soon and we can start the publication process = officially.

 

Thanks.

 

Mehmet

<= o:p> 

From: = "Ersue, = Mehmet (Nokia - DE/Munich)" <mehmet.ersue@nokia.com>
= Date: Sunday, April 24, 2016 at 5:49 PM
To: "netconf@ietf.org" <netconf@ietf.org>
Cc: = EXT Ladislav Lhotka <lhotka@nic.cz>, Juergen = Schoenwaelder <j.schoenwaelder@jaco= bs-university.de>, "rwilton@cisco.com" <rwilton@cisco.com>, "jonathan@hansfords.net" = <jonathan@hansfords.net>, = "rex@cisco.com" <rex@cisco.com>, EXT Andy Bierman = <andy@yumaworks.com>, = Martin Bjorklund <mbj@tail-f.com>, Kent Watsen = <kwatsen@juniper.net>
Sub= ject: IPR Poll for = draft-ietf-netconf-restconf-12

<= o:p> 

Dear Authors and Contributors of RESTCONF Draft,

Dear WG Members,

 

please state on the maillist clearly whether you own or are aware of = any IPR that applies to draft-ietf-netconf-restconf-12.txt.

For the opposite case, please state also on the maillist clearly if you = don=E2=80=99t own or are not aware of any IPR that applies to the = draft-ietf-netconf-restconf.

 

If you own or are aware of any IPR that applies to the = draft-ietf-netconf-restconf please clarify whether

this IPR been disclosed in compliance with IETF IPR rules (see RFCs = 3979, 4879, 3669 and 5378 for more details).

If not please do so asap.

 

If you are listed as a document author or contributor (CCed)please = respond to this email ON NETCONF MAILLIST explicitly regardless of = whether or not you are aware of any relevant IPR. The document will not = advance to the next stage until a response has been received from = _each authorand contributor_.

 

If you are not listed as an author or contributor but are on NETCONF WG = maillist, then please explicitly respond if you are aware of any IPR = that has not yet been disclosed in conformance with IETF = rules.

 

Thank you for kind support.

 

Regards,

Mehmet & Mahesh

 

------=_NextPart_000_0E8E_01D1A648.70AD0B60-- From nobody Thu May 5 08:12:27 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D023212D8FC; Thu, 5 May 2016 08:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GL1M9Xq0B16v; Thu, 5 May 2016 08:12:23 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A084612DAFE; Thu, 5 May 2016 08:05:04 -0700 (PDT) Received: by mail-pa0-x22a.google.com with SMTP id r5so37955547pag.1; Thu, 05 May 2016 08:05:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:date:to:message-id:mime-version; bh=zljLhjOtLBwlgWmr5APcN1Z6TS+4ARSorSzhlYnPPGc=; b=A9ocMzzKNkC/c5d/3XmiEyt8K3YIpYMT4+cZTuoqDjMUqYphCSdPbdFAvR3LVCxxG6 FRJobqKkAOD1sEhda2gjfqhybsVMbWBhKI3YuSR5gQQ/Z5NfI+vlNZOXGKgNrhWdN6bQ vYwl3O1Eq0cj00iAl1twt7dsup208HlyJFydkZXQTR8P147/Q1YRD/IzRrpcY1a0IMic bh6JDZ4Iu/YhTikgbqWfblQnVVcw7rl+evuLLNXVJl0ii3mtyi8YeefvTxUmBcg403/G aNhdRp+1mJ2IMlRzlUpRQNfYgjm9lQwRZ6bLxeI4mnGlovZ/JCN4Z15zcf6I9jP+sUYp ToaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:date:to:message-id:mime-version; bh=zljLhjOtLBwlgWmr5APcN1Z6TS+4ARSorSzhlYnPPGc=; b=fkltVlZ45dVQoYcw72RlJCDCJgIhfKMdTkniJUyyZtWZaGMPoz8aQhjTXshYDaUq+L +0IU6OKHqpVb/5Y4EmlzH0Z5WcGrOfRhRqhGDbewKRkkI++IXRj5Zi8Kbhf0HS549E78 VhlEFuifT49QtPnMFma8+Z7tC7xNDVRlsNar9KqGIBMxKeMotRGnongjqg+cXadyjt5s VRtKfM+Uch+9vjRWxh6IhldGaCHoupZ4q2Z7pZcIvxVZbEzNGIvnJMv2yYTjKf3Hv9xF 9A26ZYa2UiUHSgbfGclsTz1M7gA3fcbAvVpe3uELmnr3+wyrxBrBTbueaxuqhjhMZFQs u2Ug== X-Gm-Message-State: AOPr4FUcq7jae1sUUsqjlc/IhzRkbNsjmsXh/kJb/SiMVovXoK32Ao1wzUPPgNsfwEH5uw== X-Received: by 10.66.43.143 with SMTP id w15mr21512315pal.76.1462460704281; Thu, 05 May 2016 08:05:04 -0700 (PDT) Received: from sjc-mahesh-nitro10.cisco.com ([128.107.241.170]) by smtp.gmail.com with ESMTPSA id h16sm12832379pfj.0.2016.05.05.08.05.02 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 May 2016 08:05:02 -0700 (PDT) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_636C6E07-2196-4670-8057-1EA67381DD22" X-Mail-Calendar-Part: Yes Date: Thu, 5 May 2016 08:05:00 -0700 To: iesg-secretary@ietf.org, Netconf Message-Id: <314C1200-5579-4546-A203-B3AEF99A1716@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [Netconf] Virtual Interim Meeting of NETCONF WG. X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 15:12:26 -0000 --Apple-Mail=_636C6E07-2196-4670-8057-1EA67381DD22 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This is call for a virtual interim meeting of the NETCONF WG on May 18, = at 8 a.m. PDT. A rough agenda of the meeting has been posted at = https://www.ietf.org/proceedings/interim/2016/05/18/netconf/agenda/agenda-= interim-2016-netconf-1 = Details of the call-in information are and a .ics file is attached. NETCONF Interim Meeting Wednesday, May 18, 2016 8:00 am | Pacific Daylight Time (San Francisco, GMT-07:00) | 2 hrs =20 Join WebEx meeting = Meeting number: 641 636 571 Meeting password: 6uNwSKGt =20 Join by phone 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 641 636 571 Toll-free calling restrictions = =20 Add this meeting = to your calendar. (Cannot add from mobile devices.) =20 Need help? Go to http://help.webex.com . =20 IMPORTANT NOTICE: Please note that this WebEx service allows audio and = other information sent during the session to be recorded, which may be = discoverable in a legal matter. You should inform all meeting attendees = prior to recording if you intend to record the meeting. Mahesh & Mehmet --Apple-Mail=_636C6E07-2196-4670-8057-1EA67381DD22 Content-Type: multipart/mixed; boundary="Apple-Mail=_809C6C0C-B4D5-4144-BF8A-61E0B0D120A8" --Apple-Mail=_809C6C0C-B4D5-4144-BF8A-61E0B0D120A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii This is call for a virtual interim meeting of the NETCONF WG = on May 18, at 8 a.m. PDT.

A rough agenda of the meeting has been posted at https://www.ietf.org/proceedings/interim/2016/05/18/netconf/age= nda/agenda-interim-2016-netconf-1

Details of the call-in information are = and a .ics file is attached.

NETCONF Interim = Meeting
Wednesday, May 18, 2016
8:00 am  |  Pacific Daylight Time = (San Francisco, GMT-07:00)  |  2 = hrs
 
Join WebEx = meeting
Meeting = number:641 = 636 571
Meeting = password:6uNwSKGt
 
Join by = phone
1-877-668-4493 Call-in toll free number = (US/Canada)
1-650-479-3208 Call-in toll number = (US/Canada)
Access code: 641 636 571
Toll-free calling = restrictions
 
Add this meeting to your = calendar. (Cannot add from mobile = devices.)
 
Need help? Go to http://help.webex.com.
 
IMPORTANT NOTICE: Please note that this = WebEx service allows audio and other information sent during the session = to be recorded, which may be discoverable in a legal matter. You should = inform all meeting attendees prior to recording if you intend to record = the = meeting.
= --Apple-Mail=_809C6C0C-B4D5-4144-BF8A-61E0B0D120A8 Content-Disposition: attachment; filename=WebEx_Meeting.ics Content-Type: text/calendar; name="WebEx_Meeting.ics" Content-Transfer-Encoding: quoted-printable BEGIN:VCALENDAR=0APRODID:-//Microsoft=20Corporation//Outlook=2010.0=20= MIMEDIR//EN=0AVERSION:2.0=0AMETHOD:REQUEST=0ABEGIN:VTIMEZONE=0A= TZID:Pacific=20Time=0ABEGIN:STANDARD=0ADTSTART:20141101T020000=0A= RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D1SU;BYMONTH=3D11=0A= TZOFFSETFROM:-0700=0ATZOFFSETTO:-0800=0ATZNAME:Standard=20Time=0A= END:STANDARD=0ABEGIN:DAYLIGHT=0ADTSTART:20140301T020000=0A= RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D2SU;BYMONTH=3D3=0A= TZOFFSETFROM:-0800=0ATZOFFSETTO:-0700=0ATZNAME:Daylight=20Savings=20Time=0A= END:DAYLIGHT=0AEND:VTIMEZONE=0ABEGIN:VEVENT=0AATTENDEE;CN=3D"NETCONF=20= Working=20= Group";ROLE=3DREQ-PARTICIPANT;RSVP=3DFALSE:MAILTO:netconf-chairs@ietf.org=0A= ORGANIZER;CN=3D"webex":MAILTO:messenger@webex.com=0A= DTSTART;TZID=3D"Pacific=20Time":20160518T080000=0ADTEND;TZID=3D"Pacific=20= Time":20160518T100000=0ALOCATION:https://ietf.webex.com/ietf=0A= TRANSP:OPAQUE=0ASEQUENCE:1462394763=0A= UID:6757534f-2065-40c5-906d-bb6d8d0f97bc=0ADTSTAMP:20160518T150000Z=0A= DESCRIPTION:\nHost=20key:=20558690\n\n\nJOIN=20WEBEX=20= MEETING\nhttps://ietf.webex.com/ietf/j.php?MTID=3Dm311972ec79c3875ea76bb3b= 362f3544b\nMeeting=20number:=20641=20636=20571\nMeeting=20password:=20= 6uNwSKGt\n\n\nJOIN=20BY=20PHONE\n1-877-668-4493=20Call-in=20toll=20free=20= number=20(US/Canada)=20\n1-650-479-3208=20Call-in=20toll=20number=20= (US/Canada)\nAccess=20code:=20641=20636=20571\n\nToll-free=20dialing=20= restrictions:=20= \nhttps://www.webex.com/pdf/tollfree_restrictions.pdf\n\n\n\nCan't=20= join=20the=20meeting?=20Contact=20support=20= here:\nhttps://ietf.webex.com/ietf/mc\n\n\nIMPORTANT=20NOTICE:=20Please=20= note=20that=20this=20WebEx=20service=20allows=20audio=20and=20other=20= information=20sent=20during=20the=20session=20to=20be=20recorded,=20= which=20may=20be=20discoverable=20in=20a=20legal=20matter.=20You=20= should=20inform=20all=20meeting=20attendees=20prior=20to=20recording=20= if=20you=20intend=20to=20record=20the=20meeting.\n=0A= X-ALT-DESC;FMTTYPE=3Dtext/html:=09=20=  
Host=20key:=20558690 
 
 
=20= =09=09Join=20= WebEx=20meeting=09=09=09=09=09=09=09=09=09=09=09=09= =09=09=09=09=09= =09=09=09=09= =09=09=09
=09=09=09=09=09=09Meeting=20number:=09=09=09=09=09=09=09=09=09=09=09641=20636=20571=09=09=09=09=09
=09=09=09
Meeting=20= password:6uNwSKGt
=09=09 
 
Join=20by=20phone =20
1-877-668-4493 Call-in=20toll=20= free=20number=20(US/Canada) =20
1-650-479-3208 Call-in=20toll=20= number=20(US/Canada) =20
Access=20code:=20641=20636=20= 571 =20
Toll-free=20calling=20= restrictions=20 =20


=09 
=09= =09=09=09=09= Can't=20join=20the=20meeting?=09=09Contact=20support.=09=  
 
IMPORTANT=20NOTICE:=20Please=20note=20that=20this=20WebEx=20= service=20allows=20audio=20and=20other=20information=20sent=20during=20= the=20session=20to=20be=20recorded,=20which=20may=20be=20discoverable=20= in=20a=20legal=20matter.=20You=20should=20inform=20all=20meeting=20= attendees=20prior=20to=20recording=20if=20you=20intend=20to=20record=20= the=20meeting.=0ASUMMARY:NETCONF=20Interim=20Meeting=0A= PRIORITY:5=0ACLASS:PUBLIC=0ABEGIN:VALARM=0ATRIGGER:-PT5M=0A= ACTION:DISPLAY=0ADESCRIPTION:Reminder=0AEND:VALARM=0AEND:VEVENT=0A= END:VCALENDAR=0A= --Apple-Mail=_809C6C0C-B4D5-4144-BF8A-61E0B0D120A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii


Mahesh = & = Mehmet






= --Apple-Mail=_809C6C0C-B4D5-4144-BF8A-61E0B0D120A8-- --Apple-Mail=_636C6E07-2196-4670-8057-1EA67381DD22-- From nobody Thu May 5 09:15:50 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4464912D70C for ; Thu, 5 May 2016 09:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTBwkeyyPPBn for ; Thu, 5 May 2016 09:15:45 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA3C412D715 for ; Thu, 5 May 2016 09:15:35 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id F19171199; Thu, 5 May 2016 18:15:33 +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 gUKDhuputHpS; Thu, 5 May 2016 18:15:21 +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, 5 May 2016 18:15:32 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4E8C0201C2; Thu, 5 May 2016 18:15:32 +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 7-RqTjpBap76; Thu, 5 May 2016 18:15:29 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BC8CF205E9; Thu, 5 May 2016 18:15:29 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id BECBF3AC7E9C; Thu, 5 May 2016 18:15:28 +0200 (CEST) Date: Thu, 5 May 2016 18:15:28 +0200 From: Juergen Schoenwaelder To: Mahesh Jethanandani Message-ID: <20160505161528.GA41063@elstar.local> Mail-Followup-To: Mahesh Jethanandani , Netconf References: <314C1200-5579-4546-A203-B3AEF99A1716@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: quoted-printable In-Reply-To: <314C1200-5579-4546-A203-B3AEF99A1716@gmail.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: Netconf Subject: Re: [Netconf] Virtual Interim Meeting of NETCONF WG. X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 16:15:48 -0000 Mahesh, I might have to leave about 30 minutes early due to other commitments in the evening. /js On Thu, May 05, 2016 at 05:05:00PM +0200, Mahesh Jethanandani wrote: > This is call for a virtual interim meeting of the NETCONF WG on May 18= , at > 8 a.m. PDT. > A rough agenda of the meeting has been posted > at [1]https://www.ietf.org/proceedings/interim/2016/05/18/netconf/agen= da/agenda-interim-2016-netconf-1 > Details of the call-in information are and a .ics file is attached. >=20 > NETCONF Interim Meeting > Wednesday, May 18, 2016 > 8:00 am | Pacific Daylight Time (San Francisco, GMT-07:00) | 2 hrs >=20 >=20 >=20 > [2]Join WebEx meeting >=20 > Meeting number: 641 636 571 > Meeting password: 6uNwSKGt >=20 >=20 >=20 > Join by phone > 1-877-668-4493 Call-in toll free number (US/Canada) > 1-650-479-3208 Call-in toll number (US/Canada) > Access code: 641 636 571 > [3]Toll-free calling restrictions >=20 >=20 >=20 > [4]Add this meeting to your calendar. (Cannot add from mobile devices.) >=20 >=20 >=20 > Need help? Go to [5]http://help.webex.com. >=20 >=20 >=20 > IMPORTANT NOTICE: Please note that this WebEx service allows audio and > other information sent during the session to be recorded, which may be > discoverable in a legal matter. You should inform all meeting attendees > prior to recording if you intend to record the meeting. >=20 > Mahesh & Mehmet >=20 > References >=20 > Visible links > 1. https://www.ietf.org/proceedings/interim/2016/05/18/netconf/agenda/= agenda-interim-2016-netconf-1 > 2. https://ietf.webex.com/ietf/j.php?MTID=3Dm311972ec79c3875ea76bb3b36= 2f3544b > 3. https://www.webex.com/pdf/tollfree_restrictions.pdf > 4. https://ietf.webex.com/ietf/j.php?MTID=3Dmdf74ebf247ee3c35c0ee9e33b= cc1f190 > 5. http://help.webex.com/ > BEGIN:VCALENDAR > PRODID:-//Microsoft Corporation//Outlook 10.0 MIMEDIR//EN > VERSION:2.0 > METHOD:REQUEST > BEGIN:VTIMEZONE > TZID:Pacific Time > BEGIN:STANDARD > DTSTART:20141101T020000 > RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D1SU;BYMONTH=3D11 > TZOFFSETFROM:-0700 > TZOFFSETTO:-0800 > TZNAME:Standard Time > END:STANDARD > BEGIN:DAYLIGHT > DTSTART:20140301T020000 > RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D2SU;BYMONTH=3D3 > TZOFFSETFROM:-0800 > TZOFFSETTO:-0700 > TZNAME:Daylight Savings Time > END:DAYLIGHT > END:VTIMEZONE > BEGIN:VEVENT > ATTENDEE;CN=3D"NETCONF Working Group";ROLE=3DREQ-PARTICIPANT;RSVP=3DFALSE= :MAILTO:netconf-chairs@ietf.org > ORGANIZER;CN=3D"webex":MAILTO:messenger@webex.com > DTSTART;TZID=3D"Pacific Time":20160518T080000 > DTEND;TZID=3D"Pacific Time":20160518T100000 > LOCATION:https://ietf.webex.com/ietf > TRANSP:OPAQUE > SEQUENCE:1462394763 > UID:6757534f-2065-40c5-906d-bb6d8d0f97bc > DTSTAMP:20160518T150000Z > DESCRIPTION:\nHost key: 558690\n\n\nJOIN WEBEX MEETING\nhttps://ietf.webe= x.com/ietf/j.php?MTID=3Dm311972ec79c3875ea76bb3b362f3544b\nMeeting number: = 641 636 571\nMeeting password: 6uNwSKGt\n\n\nJOIN BY PHONE\n1-877-668-4493 = Call-in toll free number (US/Canada) \n1-650-479-3208 Call-in toll number (= US/Canada)\nAccess code: 641 636 571\n\nToll-free dialing restrictions: \nh= ttps://www.webex.com/pdf/tollfree_restrictions.pdf\n\n\n\nCan't join the me= eting? Contact support here:\nhttps://ietf.webex.com/ietf/mc\n\n\nIMPORTANT= NOTICE: Please note that this WebEx service allows audio and other informa= tion sent during the session to be recorded, which may be discoverable in a= legal matter. You should inform all meeting attendees prior to recording i= f you intend to record the meeting.\n > X-ALT-DESC;FMTTYPE=3Dtext/html:  
Host key: 558690=  
 
 
Join WebEx meeting<= /FONT>
Meeting number: 641 636 571
Meeting password:6uNwSKGt
 
 
Join by phone  =
1-877-668-449= 3 Call-in toll free number (US/Canada) 
1-650-479-3208 Call-in toll number (US/Canada) 
Access code: 641 636 571 
Toll-free calling restrictions<= /a>  


 
Can't join the meeting? Co= ntact support.  
 
IMPORTANT NOTICE: Please note that this WebEx service= allows audio and other information sent during the session to be recorded,= which may be discoverable in a legal matter. You should inform all meeting= attendees prior to recording if you intend to record the meeting. > SUMMARY:NETCONF Interim Meeting > PRIORITY:5 > CLASS:PUBLIC > BEGIN:VALARM > TRIGGER:-PT5M > ACTION:DISPLAY > DESCRIPTION:Reminder > END:VALARM > END:VEVENT > END:VCALENDAR --=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 Thu May 5 10:44:43 2016 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF2412D730; Thu, 5 May 2016 10:44:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF Announcement List" X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160505174440.20544.1346.idtracker@ietfa.amsl.com> Date: Thu, 05 May 2016 10:44:40 -0700 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] NETCONF Working Group Virtual Interim Meeting: May 18, 2016 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 17:44:41 -0000 The Network Configuration (netconf) Working group will hold a virtual interim meeting on May 18, at 8 a.m. PDT. A rough agenda of the meeting has been posted at https://www.ietf.org/proceedings/interim/2016/05/18/netconf/agenda/agenda-interim-2016-netconf-1 Details of the call-in information are and a .ics file is attached. NETCONF Interim Meeting Wednesday, May 18, 2016 8:00 am | Pacific Daylight Time (San Francisco, GMT-07:00) | 2 hrs Join WebEx meeting Meeting number: 641 636 571 Meeting password: 6uNwSKGt Join by phone 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 641 636 571 Toll-free calling restrictions Add this meeting to your calendar. (Cannot add from mobile devices.) Need help? Go to http://help.webex.com . IMPORTANT NOTICE: Please note that this WebEx service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. You should inform all meeting attendees prior to recording if you intend to record the meeting. Mahesh & Mehmet From nobody Thu May 5 23:20:34 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFED512D1C9; Thu, 5 May 2016 23:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNmqY6kx2VXp; Thu, 5 May 2016 23:20:29 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B086412D4FF; Thu, 5 May 2016 23:13:39 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.238; From: "Susan Hares" To: References: <20160506061052.26811.37591.idtracker@ietfa.amsl.com> In-Reply-To: <20160506061052.26811.37591.idtracker@ietfa.amsl.com> Date: Fri, 6 May 2016 02:13:34 -0400 Message-ID: <000001d1a75e$6c2d7d60$44887820$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH4phi8G66fo2y5TGN4Rlmg6MU68J9db/mw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: netconf@ietf.org Subject: [Netconf] FW: New Version Notification for draft-hares-i2rs-protocol-strawman-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 06:20:33 -0000 =20 This version of the protocol strawman is the result of all the = suggestions from the I2RS meeting and inputs from other reviews. =20 Please let us know if you have additional reviews.=20 Sue, Amit, and Andy=20 -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Friday, May 06, 2016 2:11 AM To: Amit Daas; amit.dass@ericsson.com; Andy Bierman; Susan Hares Subject: New Version Notification for = draft-hares-i2rs-protocol-strawman-02.txt A new version of I-D, draft-hares-i2rs-protocol-strawman-02.txt has been successfully submitted by Susan Hares and posted to the IETF = repository. Name: draft-hares-i2rs-protocol-strawman Revision: 02 Title: I2RS protocol strawman Document date: 2016-05-05 Group: Individual Submission Pages: 52 URL: = https://www.ietf.org/internet-drafts/draft-hares-i2rs-protocol-strawman-0= 2.txt Status: = https://datatracker.ietf.org/doc/draft-hares-i2rs-protocol-strawman/ Htmlized: = https://tools.ietf.org/html/draft-hares-i2rs-protocol-strawman-02 Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-hares-i2rs-protocol-strawman-02= Abstract: This strawman proposal for the I2RS protocol supports I2RS requirements for ephemeral data store, management data flows, and protocol security. It proposes additions to the NETCONF, RESTCONF, and YANG for these requirements. = =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 May 6 00:44:26 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05C1412D14D; Fri, 6 May 2016 00:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2CT-0pvuAznY; Fri, 6 May 2016 00:44:23 -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 D3BB012B03A; Fri, 6 May 2016 00:44: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 9976E1084; Fri, 6 May 2016 09:44: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 NazF4JPJN6Sf; Fri, 6 May 2016 09:44:07 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 6 May 2016 09:44:20 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id B38B120961; Fri, 6 May 2016 09:44:20 +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 66P85M2KPFW2; Fri, 6 May 2016 09:44:19 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0D38F20960; Fri, 6 May 2016 09:44:19 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0057C3AC8BA1; Fri, 6 May 2016 09:44:18 +0200 (CEST) Date: Fri, 6 May 2016 09:44:18 +0200 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20160506074418.GB42286@elstar.local> Mail-Followup-To: Susan Hares , i2rs@ietf.org, netconf@ietf.org References: <20160506061052.26811.37591.idtracker@ietfa.amsl.com> <000001d1a75e$6c2d7d60$44887820$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000001d1a75e$6c2d7d60$44887820$@ndzh.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: i2rs@ietf.org, netconf@ietf.org Subject: Re: [Netconf] FW: New Version Notification for draft-hares-i2rs-protocol-strawman-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 07:44:25 -0000 I disagree with many things in the document. For example, a data model must not detail things like o encoding [XML | JSON] o protocol [RESTCONF | NETCONF] o protocol-transport [ssh, tls, tcp] o transport-ports [ports] because of layering and modularity concerns and of deployment flexibility. There are many more of these. Overall, it would help if there were fewer documents and not so many overlapping documents. /js On Fri, May 06, 2016 at 02:13:34AM -0400, Susan Hares wrote: > > This version of the protocol strawman is the result of all the suggestions from the I2RS meeting and inputs from other reviews. > Please let us know if you have additional reviews. > > Sue, Amit, and Andy > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Friday, May 06, 2016 2:11 AM > To: Amit Daas; amit.dass@ericsson.com; Andy Bierman; Susan Hares > Subject: New Version Notification for draft-hares-i2rs-protocol-strawman-02.txt > > > A new version of I-D, draft-hares-i2rs-protocol-strawman-02.txt > has been successfully submitted by Susan Hares and posted to the IETF repository. > > Name: draft-hares-i2rs-protocol-strawman > Revision: 02 > Title: I2RS protocol strawman > Document date: 2016-05-05 > Group: Individual Submission > Pages: 52 > URL: https://www.ietf.org/internet-drafts/draft-hares-i2rs-protocol-strawman-02.txt > Status: https://datatracker.ietf.org/doc/draft-hares-i2rs-protocol-strawman/ > Htmlized: https://tools.ietf.org/html/draft-hares-i2rs-protocol-strawman-02 > Diff: https://www.ietf.org/rfcdiff?url2=draft-hares-i2rs-protocol-strawman-02 > > Abstract: > This strawman proposal for the I2RS protocol supports I2RS > requirements for ephemeral data store, management data flows, and > protocol security. It proposes additions to the NETCONF, RESTCONF, > and YANG for these requirements. > > > > > 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 > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- 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 May 6 08:51:51 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADBFB12B03D; Fri, 6 May 2016 08:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYZ3MdPUr45j; Fri, 6 May 2016 08:51:46 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 1C81A12B010; Fri, 6 May 2016 08:51:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id C847925834D; Fri, 6 May 2016 08:51:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1462549905; bh=htiioxMo1Xck2pbcXRkKHjtJI1xWVNbuY80iMKiqDzQ=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=jKLagFBwIvfMRb/LfLG0BpmLqgU6sA9c8A/vUwtGTikW+v/3xBKMyFH7aXvfSb+4q RttCEfNphJJB7EG8WrdDrG8o3oXX4zWy4G3EA9nxtidGMHq9d6kwo9/pR/hU1Gz2af WJQJx7qQ/iSNqNXcCFuXm2J6zfWmkeAjYH72+wHM= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4EA6C2466C2; Fri, 6 May 2016 08:51:45 -0700 (PDT) To: Susan Hares , i2rs@ietf.org References: <20160506061052.26811.37591.idtracker@ietfa.amsl.com> <000001d1a75e$6c2d7d60$44887820$@ndzh.com> From: "Joel M. Halpern" Message-ID: Date: Fri, 6 May 2016 11:51:38 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <000001d1a75e$6c2d7d60$44887820$@ndzh.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] [i2rs] FW: New Version Notification for draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 15:51:48 -0000 Reading the latest revision, in section 3.1.1, the text in bullet 5 says that the data model indicates which portions are ephemeral. That makes sense to me. Then bullet 6 says that the management protocol needs to signal (in its yang library) which parts are ephemeral. Why the second requirement? If the data model is supported, and the data model states that certain items are ephemeral, what would it mean if the signaling did not also say that. Conversely, what would it mean if the signaling said something was ephemeral that the model does not define as ephemeral? It may be that I am misreading bullet 6. Please explain. Thank you, Joel From nobody Fri May 6 08:57:45 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1F0712D0B2; Fri, 6 May 2016 08:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CxeHKBWwnm4P; Fri, 6 May 2016 08:57:42 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 B32FE12D097; Fri, 6 May 2016 08:57:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 9CEBD2409E3; Fri, 6 May 2016 08:57:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1462550262; bh=Yl0xnnijh3Ewd4JTdOrm+ncFnGK8vQGPwv9rdAjG6zU=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=QjWubDTe/5nFRzciXKdJ3nLbh7bh21jpHuH+SULm0JaQ/BomR99Q9SSt5QYkYyZwY sl8BjusfLdDZ7rqf/367uU2LC7c1v2m5oie2RtyIp3AaEY2M7JkjC3gOytWb0rp402 xfo3kCzlOjPDc4SSFsVuY7qwsshIRJgu3zKWN3JA= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 1751E24B2DF; Fri, 6 May 2016 08:57:42 -0700 (PDT) To: Susan Hares , i2rs@ietf.org References: <20160506061052.26811.37591.idtracker@ietfa.amsl.com> <000001d1a75e$6c2d7d60$44887820$@ndzh.com> From: "Joel M. Halpern" Message-ID: <914099bb-bbec-5005-90bf-e3ebf2578135@joelhalpern.com> Date: Fri, 6 May 2016 11:57:35 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <000001d1a75e$6c2d7d60$44887820$@ndzh.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] [i2rs] FW: New Version Notification for draft-hares-i2rs-protocol-strawman-02.txt - 3.1.3 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 15:57:44 -0000 Section 3.1.3 requirements 6 and 7 introduce the marking that the protocol used by YANG / NetConf is i2RS specific. From one important angle, this makes good sense. It avoids confusing the I2RS communication with other NetConf or RestConf usage. On the other hand, it seems to create a difficulty when YANG evolves beyond YANG 1.1. Do we have to explicitly decide each time if I2RS will support the new version, and assign a new i2rs version number? This seems unfortunate. Could there not be some other way to indicate that the protocol is YANG 1.1, but that the usage of the channel is I2RS? Thank you, Joel From nobody Fri May 6 09:08:55 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89A0C12B04B; Fri, 6 May 2016 09:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZlp-F8HRa14; Fri, 6 May 2016 09:08:52 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 6A58D12B01B; Fri, 6 May 2016 09:08:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 542662409E3; Fri, 6 May 2016 09:08:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1462550932; bh=WAWjRFL5rLws6bypDydIbECYyScTTV3v3AyrBIzdEn4=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=qaiPEC0xRMzDtGjvkKzbzcW74vLOCAdpipSpcja82/QQhvtvIRHUIVf3ueYM6dN+G 6IB9VrWiaOfVYk6kJRRiK6XBJ1VY8bLby0MHEJrIVqkEsawrcHLHJt7LmUCcZMkEfw 07sA6spgn13sifbQb+drLeuNqD/h1qZkcRsJhXRQ= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id CF7F4250D2A; Fri, 6 May 2016 09:08:51 -0700 (PDT) To: Susan Hares , i2rs@ietf.org References: <20160506061052.26811.37591.idtracker@ietfa.amsl.com> <000001d1a75e$6c2d7d60$44887820$@ndzh.com> From: "Joel M. Halpern" Message-ID: <4a316713-0cc9-55ae-79a2-1b0c2ce3ff06@joelhalpern.com> Date: Fri, 6 May 2016 12:08:45 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <000001d1a75e$6c2d7d60$44887820$@ndzh.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] [i2rs] FW: New Version Notification for draft-hares-i2rs-protocol-strawman-02.txt - 3.4.1.1 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 16:08:53 -0000 The text at the end of this section talks about the I2RS agent re-evaluating a set of writes done by a client when the assigned priority of the client changes. Dealing with such changes makes sense. I am confused by the specific proposal. What is being reevaluated, and why are notifications being sent? Since the I2RS agent does not store operations from clients which are not active, there is no way that changing the priority can cause a previously ignored operation to be applied. Equally, if the priority is lowered, there is now way that any other I2RS cleint operation will suddenly take precedence. The only case I can construct is if the routing system is using priority to decide between local config and I2RS (which earlier changes seem to rule out). IN that case, a change could cause an I2RS client operation to be removed in favor of local config. Even that case would seem to cause only a single notification of that event, not a whole series of notifications. Yours, somewhat confused, Joel From nobody Fri May 6 16:15:44 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A369C12D177 for ; Fri, 6 May 2016 16:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 710OCopNf7CC for ; Fri, 6 May 2016 16:15:39 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8517212D15D for ; Fri, 6 May 2016 16:15:38 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id m64so146913335lfd.1 for ; Fri, 06 May 2016 16:15:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=wQY1EXFR2w1ADqiTABa5CRXeL+9+nsRf2U2zz/Gm0K4=; b=r84hSJa3dut2ocpyGgwG+DtLgES7sX95pj1VaVoL0L2AdBFZE3t67JjOIADe6IEkcO NlFi3LQCUz5dz1U58cEpCm+gSnTDzGQE35bwfbtzFeMTLBxKzq1l6UvO0aU9e0BVcPGW ils+QL71oKWBeEDUZT4aqbXenItFrTMCvuccwzwYKi0V4Gx5tB+jdGSJDw1fSDHxmrMC NIGmB8gTpwHWPpyRZsl008SW+k/CRDCFgrlghHH0RLEK9liRSH83FlosmQziGVv6bnJq Rqc3HNr++hZQ4GfmSTwj+wiBo2WCIxs0yDp6ArxykJ4hYGZW8TYL0PS1RCNG4MJKn4eC HwGA== 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; bh=wQY1EXFR2w1ADqiTABa5CRXeL+9+nsRf2U2zz/Gm0K4=; b=mW797AIS2ew3kKnHAe92T0tPpeXJpwbLNttBQE6LZq2d7lPyXRDETkFmB+rEm0WyHT AZzU8uqFoIYQoN/T47cGEf95l9osMT1piQQvmHqE/BVSQrbtBozoVHyDXyN2gFXVHwnw MZ0rt8F4PL1YDp4JswPLRa1l/m9UWdS0GGPZ+boGRvGNfuEn6aQ8GMlHyBm9OLYj51kt RXic1pxYktZBlVY0PKkL0+g16d7vcX0geaeFr8G1WICk+qUrPRku1pXw+6QOaoXiPN+H y9wvRcp/6E6Rp7FYj2Xu5FNo7/Ojn0aJzC9YuQgqq9unyLug+jbo+CjreD9VtwTKRL0F QPhw== X-Gm-Message-State: AOPr4FVXpR/oecPDIjVl+3oGk3POGAKcjC1QkzgKHloyQp02DzPY2Sc0OJp+euVnFOJziQGUE+CwWMCNeBatxQ== MIME-Version: 1.0 X-Received: by 10.25.141.131 with SMTP id p125mr11346773lfd.8.1462576536751; Fri, 06 May 2016 16:15:36 -0700 (PDT) Received: by 10.112.13.133 with HTTP; Fri, 6 May 2016 16:15:36 -0700 (PDT) In-Reply-To: <000001d1a75e$6c2d7d60$44887820$@ndzh.com> References: <20160506061052.26811.37591.idtracker@ietfa.amsl.com> <000001d1a75e$6c2d7d60$44887820$@ndzh.com> Date: Fri, 6 May 2016 16:15:36 -0700 Message-ID: From: Andy Bierman To: Susan Hares Content-Type: multipart/alternative; boundary=001a1140242cee28bd053234a267 Archived-At: Cc: "i2rs@ietf.org" , Netconf Subject: Re: [Netconf] FW: New Version Notification for draft-hares-i2rs-protocol-strawman-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 23:15:41 -0000 --001a1140242cee28bd053234a267 Content-Type: text/plain; charset=UTF-8 Hi, I have not have enough time to work on this draft yet, but here are my initial concerns. I won't comment on the details yet. 1) datastores There is an opstate design team working on everything except ephemeral. We need 1 RPC defining the datastore framework and each specific datastore (known at this time). The I2RS protocol should not be that document. 2) requirements There should not be any duplication of requirements. There should just be normative text defining the protocol, and non-normative examples. 3) YANG validation As stated in BA, I am strongly against protocol documents redefining how YANG works for their spot solution. The YANG designer and operator want the data models to be as protocol-independent as possible. Andy On Thu, May 5, 2016 at 11:13 PM, Susan Hares wrote: > > This version of the protocol strawman is the result of all the suggestions > from the I2RS meeting and inputs from other reviews. > Please let us know if you have additional reviews. > > Sue, Amit, and Andy > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Friday, May 06, 2016 2:11 AM > To: Amit Daas; amit.dass@ericsson.com; Andy Bierman; Susan Hares > Subject: New Version Notification for > draft-hares-i2rs-protocol-strawman-02.txt > > > A new version of I-D, draft-hares-i2rs-protocol-strawman-02.txt > has been successfully submitted by Susan Hares and posted to the IETF > repository. > > Name: draft-hares-i2rs-protocol-strawman > Revision: 02 > Title: I2RS protocol strawman > Document date: 2016-05-05 > Group: Individual Submission > Pages: 52 > URL: > https://www.ietf.org/internet-drafts/draft-hares-i2rs-protocol-strawman-02.txt > Status: > https://datatracker.ietf.org/doc/draft-hares-i2rs-protocol-strawman/ > Htmlized: > https://tools.ietf.org/html/draft-hares-i2rs-protocol-strawman-02 > Diff: > https://www.ietf.org/rfcdiff?url2=draft-hares-i2rs-protocol-strawman-02 > > Abstract: > This strawman proposal for the I2RS protocol supports I2RS > requirements for ephemeral data store, management data flows, and > protocol security. It proposes additions to the NETCONF, RESTCONF, > and YANG for these requirements. > > > > > 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 > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a1140242cee28bd053234a267 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I have not have enough time to work= on this draft yet, but here are my initial concerns.
I won't= comment on the details yet.

1) datastores

There is an opstate design team working on everything exc= ept ephemeral.
We need 1 RPC defining the datastore framework and= each specific datastore (known at this time).
The I2RS protocol = should not be that document.

2) requirements
=

There should not be any duplication of requirements.
There should just be normative text defining the protocol, and non-= normative examples.

3) YANG validation
<= br>
As stated in BA, I am strongly against protocol documents red= efining how YANG works
for their spot solution.=C2=A0 The YANG de= signer and operator want the data models to be as
protocol-indepe= ndent as possible.



A= ndy


On Thu, May 5, 2016 at 11:13 PM, Susan Hares = <shares@ndzh.com> wrote:
<WG chair hat off,= co-author hat on>
This version of the protocol strawman is the result of all the suggestions = from the I2RS meeting and inputs from other reviews.
Please let us know if you have additional reviews.

Sue, Amit, and Andy

-----Original Message-----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Friday, May 06, 2016 2:11 AM
To: Amit Daas; amit.dass@ericsson= .com; Andy Bierman; Susan Hares
Subject: New Version Notification for draft-hares-i2rs-protocol-strawman-02= .txt


A new version of I-D, draft-hares-i2rs-protocol-strawman-02.txt
has been successfully submitted by Susan Hares and posted to the IETF repos= itory.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-hares-i2rs-protocol-str= awman
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A002
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I2RS protocol strawman
Document date:=C2=A0 2016-05-05
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 52
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-hares-i2= rs-protocol-strawman-02.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-hares-i2rs-protocol-strawma= n/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-hares-i2rs-protocol-strawman-02
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-hares-i2rs-pro= tocol-strawman-02

Abstract:
=C2=A0 =C2=A0This strawman proposal for the I2RS protocol supports I2RS
=C2=A0 =C2=A0requirements for ephemeral data store, management data flows, = and
=C2=A0 =C2=A0protocol security.=C2=A0 It proposes additions to the NETCONF,= RESTCONF,
=C2=A0 =C2=A0and YANG for these requirements.




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

The IETF Secretariat


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

--001a1140242cee28bd053234a267-- From nobody Sat May 7 09:53:50 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D899F12B01B for ; Sat, 7 May 2016 09:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CmlNylR5leIz for ; Sat, 7 May 2016 09:53:43 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F5AF12B019 for ; Sat, 7 May 2016 09:53:43 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id m64so161340152lfd.1 for ; Sat, 07 May 2016 09:53:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=vkMO5VbUSgMeSbaUl3qblaUr1/bCIKzYH6DK1nGkQCs=; b=h1UQvhEY4OvcTobJH1rpWDPZNwrFd/var0eFJC/lemImON3zoIbDCqqdg6vF4oqOgC GQt2ffmn7dyfEuHKu9ZhlTRPtFYBNRWVgJttOE7zdSnG8rKRM3gWrJ+LhPLW+Nyiscn7 TZBSFv/Jzz1l1AqZG8/v0Dt6Rwuutqwms5hraaRHz8GM8wcWtNj9KxVNhI2UPJlJgblF 3ng/vPXoEkpsj4wenSMKIjw5i8I6lYjcAESH2I8Yqto4s+VlzzAfEPeB/IF6CA6cK2Hs 3nSrY2J0+W2zYKKfW6e0mnNjD4r+uM6FZ8qS+oP1FBCS/zetpNM8S6DCXKSIvVPbOBl+ fVdQ== 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; bh=vkMO5VbUSgMeSbaUl3qblaUr1/bCIKzYH6DK1nGkQCs=; b=lXVSEl2hsIkIGumkK5mVCBbQCrnGFktgmCkQexyHeb09GFjhI/bjQdMoywKbYEr+t/ uPvUY6GDrrfC6dkX+nladlN8nQ/xMkq/wlepxjIt6vJVqQ5bUYfF+MBVW7TeSqbTbD96 s72jYyb506Si9ccONNa9xy8Um9CeCE3pE3kirWzQ7W/OSZmfdr5Gtg4la3TDqYaBpiiy /4YjFNZdHmb+aQHxFPwJcFwnt9KBTlEPPtEW0bQiX8pGDWzC5jYNMQN/nOYQapE2D/1d MiaHDrFCxlKHczmCBCIJiwMi7jEqfNRhMu4LCWDRjxDJoE94bt260/WoyGfjR9Dfq0Ef gQ7g== X-Gm-Message-State: AOPr4FX3YS4Ls1ypqkb5+NqelH///Gb7XTM0WtjeG/O2A2G4Ekq7sZrLmI3Vdel7OdHvfCjzmcLJZxbgwUMHVg== MIME-Version: 1.0 X-Received: by 10.25.64.212 with SMTP id n203mr12505341lfa.54.1462640021542; Sat, 07 May 2016 09:53:41 -0700 (PDT) Received: by 10.112.13.133 with HTTP; Sat, 7 May 2016 09:53:41 -0700 (PDT) In-Reply-To: References: <20160506061052.26811.37591.idtracker@ietfa.amsl.com> <000001d1a75e$6c2d7d60$44887820$@ndzh.com> Date: Sat, 7 May 2016 09:53:41 -0700 Message-ID: From: Andy Bierman To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=001a113fc26aeb36cf0532436ac1 Archived-At: Cc: "i2rs@ietf.org" , Netconf Subject: Re: [Netconf] [i2rs] FW: New Version Notification for draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2016 16:53:47 -0000 --001a113fc26aeb36cf0532436ac1 Content-Type: text/plain; charset=UTF-8 On Fri, May 6, 2016 at 8:51 AM, Joel M. Halpern wrote: > Reading the latest revision, in section 3.1.1, the text in bullet 5 says > that the data model indicates which portions are ephemeral. That makes > sense to me. > > Then bullet 6 says that the management protocol needs to signal (in its > yang library) which parts are ephemeral. > > Why the second requirement? If the data model is supported, and the data > model states that certain items are ephemeral, what would it mean if the > signaling did not also say that. Conversely, what would it mean if the > signaling said something was ephemeral that the model does not define as > ephemeral? > > It may be that I am misreading bullet 6. Please explain. > > I think you are correct that the YANG library does not need any changes to identify ephemeral data. Only the variable components of YANG conformance are contained in the library. Thank you, > Joel > > Andy > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --001a113fc26aeb36cf0532436ac1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, May 6, 2016 at 8:51 AM, Joel M. Halpern <<= a href=3D"mailto:jmh@joelhalpern.com" target=3D"_blank">jmh@joelhalpern.com= > wrote:
Reading the latest= revision, in section 3.1.1, the text in bullet 5 says that the data model = indicates which portions are ephemeral.=C2=A0 That makes sense to me.

Then bullet 6 says that the management protocol needs to signal (in its yan= g library) which parts are ephemeral.

Why the second requirement?=C2=A0 If the data model is supported, and the d= ata model states that certain items are ephemeral, what would it mean if th= e signaling did not also say that.=C2=A0 Conversely, what would it mean if = the signaling said something was ephemeral that the model does not define a= s ephemeral?

It may be that I am misreading bullet 6.=C2=A0 Please explain.



I think you are correct= that the YANG library does not need any changes
to identify ephe= meral data.=C2=A0 Only the variable components of
YANG conformanc= e are contained in the library.


Thank you,
Joel



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

--001a113fc26aeb36cf0532436ac1-- From nobody Sun May 8 12:18:52 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B21C712B032 for ; Sun, 8 May 2016 12:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.898 X-Spam-Level: X-Spam-Status: No, score=-107.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hfuroqoCGCn for ; Sun, 8 May 2016 12:18:50 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4056C12B009 for ; Sun, 8 May 2016 12:18:50 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C18B9180003; Sun, 8 May 2016 12:18:02 -0700 (PDT) To: andy@yumaworks.com, balazs.lengyel@ericsson.com, bclaise@cisco.com, joelja@bogus.com, mjethanandani@gmail.com, mehmet.ersue@nokia.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160508191802.C18B9180003@rfc-editor.org> Date: Sun, 8 May 2016 12:18:02 -0700 (PDT) Archived-At: Cc: rfc-editor@rfc-editor.org, netconf@ietf.org Subject: [Netconf] [Editorial Errata Reported] RFC6243 (4687) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2016 19:18:52 -0000 The following errata report has been submitted for RFC6243, "With-defaults Capability for NETCONF". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6243&eid=4687 -------------------------------------- Type: Editorial Reported by: Muly Ilan Section: A.1 Original Text ------------- typedef status-type { description "Interface status"; type enumeration { enum ok; enum 'waking up'; enum 'not feeling so good'; enum 'better check it out'; enum 'better call for help'; } default ok; } Corrected Text -------------- typedef status-type { description "Interface status"; type enumeration { enum up; enum 'waking up'; enum 'not feeling so good'; enum 'better check it out'; enum 'better call for help'; } default up; } Notes ----- The examples in appendix A use the value 'up' and not the value 'ok'. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6243 (draft-ietf-netconf-with-defaults-14) -------------------------------------- Title : With-defaults Capability for NETCONF Publication Date : June 2011 Author(s) : A. Bierman, B. Lengyel Category : PROPOSED STANDARD Source : Network Configuration Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Sun May 8 12:25:13 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A26F512D0C5 for ; Sun, 8 May 2016 12:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.898 X-Spam-Level: X-Spam-Status: No, score=-107.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ma7xd27I8VGv for ; Sun, 8 May 2016 12:25:10 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F61E12D0C4 for ; Sun, 8 May 2016 12:25:10 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id D19F8180003; Sun, 8 May 2016 12:24:22 -0700 (PDT) To: andy@yumaworks.com, balazs.lengyel@ericsson.com, bclaise@cisco.com, joelja@bogus.com, mjethanandani@gmail.com, mehmet.ersue@nokia.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160508192422.D19F8180003@rfc-editor.org> Date: Sun, 8 May 2016 12:24:22 -0700 (PDT) Archived-At: Cc: rfc-editor@rfc-editor.org, netconf@ietf.org Subject: [Netconf] [Technical Errata Reported] RFC6243 (4688) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2016 19:25:11 -0000 The following errata report has been submitted for RFC6243, "With-defaults Capability for NETCONF". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6243&eid=4688 -------------------------------------- Type: Technical Reported by: Muly Ilan Section: 4.5.2 Original Text ------------- If the operation attribute contains the value 'create', and the data node already exists in the target configuration datastore, then the server MUST return an response with an 'invalid-value' error-tag. Corrected Text -------------- If the operation attribute contains the value 'create', and the data node already exists in the target configuration datastore, then the server MUST return an response with an 'data-exists' error-tag. Notes ----- According to RFC6241 section 7.2 the behavior for the 'create' operation is: " If the configuration data exists, an element is returned with an value of "data-exists". " Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6243 (draft-ietf-netconf-with-defaults-14) -------------------------------------- Title : With-defaults Capability for NETCONF Publication Date : June 2011 Author(s) : A. Bierman, B. Lengyel Category : PROPOSED STANDARD Source : Network Configuration Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Mon May 9 13:54:40 2016 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E68D12D5E2; Mon, 9 May 2016 13:54:36 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160509205436.18349.32098.idtracker@ietfa.amsl.com> Date: Mon, 09 May 2016 13:54:36 -0700 Archived-At: Cc: netconf-chairs@ietf.org, The IESG , draft-ietf-netconf-yang-library@ietf.org, rfc-editor@rfc-editor.org, netconf@ietf.org Subject: [Netconf] Protocol Action: 'YANG Module Library' to Proposed Standard (draft-ietf-netconf-yang-library-06.txt) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 20:54:36 -0000 The IESG has approved the following document: - 'YANG Module Library' (draft-ietf-netconf-yang-library-06.txt) as Proposed Standard This document is the product of the Network Configuration Working Group. The IESG contact persons are Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-library/ Technical Summary This draft presents YANG Library, which provides information about all the YANG modules used by the network management server. Previously, this information was included as part of hello message exchange and even then it did not provide all the information, e.g. revision date of the deviation modules, information on submodules and their revisions. Working Group Summary This document is a companion document to YANG 1.1 (draft-ietf-netmod-rfc6020bis) although it does not preclude its use with YANG 1.0. By caching the information, clients can minimize retrieval of this frequently changing information from the server. Document Quality This document was extensively reviewed and comments were provided both in IETF meetings and on the mailing list. Personnel The document shepherd is Mahesh Jethanandani. The responsible AD will be Benoit Claise. From nobody Mon May 9 16:04:30 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFEF12D556; Mon, 9 May 2016 16:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.106 X-Spam-Level: X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PE60hZ3WUkDJ; Mon, 9 May 2016 16:04:25 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0B1112D17F; Mon, 9 May 2016 16:04:22 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=166.172.62.119; Date: Mon, 09 May 2016 18:09:18 -0400 Message-ID: Importance: normal From: Susan Hares To: Andy Bierman , "Joel M. Halpern" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_2010411323284380" X-Authenticated-User: skh@ndzh.com Archived-At: Cc: "i2rs@ietf.org" , Netconf Subject: Re: [Netconf] [i2rs] FW: New Version Notification for draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 23:04:27 -0000 ----_com.samsung.android.email_2010411323284380 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 QW5keSBhbmQgSm9lbDoKVGhlc2UgYXJlIGdvb2QgcG9pbnRzLgpXaGF0IGhhcHBlbnMgaWYgdGhl IGRhdGEgbW9kZWwgaGFzIHNvbWUgZXBoZW1lcmFsIHNlY3Rpb25zIGFuZCB0aGUgSTJSUyBhZ2Vu dCBpcyBub3Qgc3VwcG9ydGVkIGJ5IHRoZSByb3V0aW5nIHN5c3RlbS4gwqBUaGUgZGF0YSBtb2Rl bCB3b3VsZCBzcGVjaWZ5IHRoZSBlcGhlbWVyYWwgc2VjdGlvbiwgYnV0IHRoZXJlIHdvdWxkIGJl IG5vIHN1cHBvcnQgYnkgaTJycy4gwqBJcyB0aGUgc3VwcG9ydCBvZiB0aGUgZXBoZW1lcmFsIG5v dCBhIHZhcmlhYmxlIMKgY29uZGl0aW9uIHRvIGJlIGluZGljYXRlZCBpbiBZYW5nIG1vZHVsZSBs aWJyYXJ5PwpTdWVTZW50IHZpYSB0aGUgU2Ftc3VuZyBHYWxheHkgTm90ZTUsIGFuIEFUJlQgNEcg TFRFIHNtYXJ0cGhvbmUtLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tRnJvbTogQW5k eSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IERhdGU6IDUvNy8yMDE2ICAxMjo1MyBQTSAg KEdNVC0wNTowMCkgVG86ICJKb2VsIE0uIEhhbHBlcm4iIDxqbWhAam9lbGhhbHBlcm4uY29tPiBD YzogaTJyc0BpZXRmLm9yZywgTmV0Y29uZiA8bmV0Y29uZkBpZXRmLm9yZz4sIFN1c2FuIEhhcmVz IDxzaGFyZXNAbmR6aC5jb20+IFN1YmplY3Q6IFJlOiBbaTJyc10gRlc6IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IgZHJhZnQtaGFyZXMtaTJycy1wcm90b2NvbC1zdHJhd21hbi0wMi50eHQg LSAzLjEuMSAKCgpPbiBGcmksIE1heSA2LCAyMDE2IGF0IDg6NTEgQU0sIEpvZWwgTS4gSGFscGVy biA8am1oQGpvZWxoYWxwZXJuLmNvbT4gd3JvdGU6ClJlYWRpbmcgdGhlIGxhdGVzdCByZXZpc2lv biwgaW4gc2VjdGlvbiAzLjEuMSwgdGhlIHRleHQgaW4gYnVsbGV0IDUgc2F5cyB0aGF0IHRoZSBk YXRhIG1vZGVsIGluZGljYXRlcyB3aGljaCBwb3J0aW9ucyBhcmUgZXBoZW1lcmFsLsKgIFRoYXQg bWFrZXMgc2Vuc2UgdG8gbWUuCgoKClRoZW4gYnVsbGV0IDYgc2F5cyB0aGF0IHRoZSBtYW5hZ2Vt ZW50IHByb3RvY29sIG5lZWRzIHRvIHNpZ25hbCAoaW4gaXRzIHlhbmcgbGlicmFyeSkgd2hpY2gg cGFydHMgYXJlIGVwaGVtZXJhbC4KCgoKV2h5IHRoZSBzZWNvbmQgcmVxdWlyZW1lbnQ/wqAgSWYg dGhlIGRhdGEgbW9kZWwgaXMgc3VwcG9ydGVkLCBhbmQgdGhlIGRhdGEgbW9kZWwgc3RhdGVzIHRo YXQgY2VydGFpbiBpdGVtcyBhcmUgZXBoZW1lcmFsLCB3aGF0IHdvdWxkIGl0IG1lYW4gaWYgdGhl IHNpZ25hbGluZyBkaWQgbm90IGFsc28gc2F5IHRoYXQuwqAgQ29udmVyc2VseSwgd2hhdCB3b3Vs ZCBpdCBtZWFuIGlmIHRoZSBzaWduYWxpbmcgc2FpZCBzb21ldGhpbmcgd2FzIGVwaGVtZXJhbCB0 aGF0IHRoZSBtb2RlbCBkb2VzIG5vdCBkZWZpbmUgYXMgZXBoZW1lcmFsPwoKCgpJdCBtYXkgYmUg dGhhdCBJIGFtIG1pc3JlYWRpbmcgYnVsbGV0IDYuwqAgUGxlYXNlIGV4cGxhaW4uCgoKCgpJIHRo aW5rIHlvdSBhcmUgY29ycmVjdCB0aGF0IHRoZSBZQU5HIGxpYnJhcnkgZG9lcyBub3QgbmVlZCBh bnkgY2hhbmdlc3RvIGlkZW50aWZ5IGVwaGVtZXJhbCBkYXRhLsKgIE9ubHkgdGhlIHZhcmlhYmxl IGNvbXBvbmVudHMgb2ZZQU5HIGNvbmZvcm1hbmNlIGFyZSBjb250YWluZWQgaW4gdGhlIGxpYnJh cnkuCgoKVGhhbmsgeW91LAoKSm9lbAoKCgoKQW5kecKgCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fCgppMnJzIG1haWxpbmcgbGlzdAoKaTJyc0BpZXRmLm9y ZwoKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMnJzCgoKCg== ----_com.samsung.android.email_2010411323284380 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2PkFuZHkgYW5kIEpvZWw6PC9k aXY+PGRpdj48YnI+PC9kaXY+PGRpdj5UaGVzZSBhcmUgZ29vZCBwb2ludHMuPC9kaXY+PGRpdj48 YnI+PC9kaXY+PGRpdj5XaGF0IGhhcHBlbnMgaWYgdGhlIGRhdGEgbW9kZWwgaGFzIHNvbWUgZXBo ZW1lcmFsIHNlY3Rpb25zIGFuZCB0aGUgSTJSUyBhZ2VudCBpcyBub3Qgc3VwcG9ydGVkIGJ5IHRo ZSByb3V0aW5nIHN5c3RlbS4gJm5ic3A7VGhlIGRhdGEgbW9kZWwgd291bGQgc3BlY2lmeSB0aGUg ZXBoZW1lcmFsIHNlY3Rpb24sIGJ1dCB0aGVyZSB3b3VsZCBiZSBubyBzdXBwb3J0IGJ5IGkycnMu ICZuYnNwO0lzIHRoZSBzdXBwb3J0IG9mIHRoZSBlcGhlbWVyYWwgbm90IGEgdmFyaWFibGUgJm5i c3A7Y29uZGl0aW9uIHRvIGJlIGluZGljYXRlZCBpbiBZYW5nIG1vZHVsZSBsaWJyYXJ5PzwvZGl2 PjxkaXY+PGJyPjwvZGl2PjxkaXY+U3VlPC9kaXY+PGRpdiBpZD0iY29tcG9zZXJfc2lnbmF0dXJl Ij48ZGl2IHN0eWxlPSJmb250LXNpemU6ODUlO2NvbG9yOiM1NzU3NTciPlNlbnQgdmlhIHRoZSBT YW1zdW5nIEdhbGF4eSBOb3RlNSwgYW4gQVQmYW1wO1QgNEcgTFRFIHNtYXJ0cGhvbmU8L2Rpdj48 L2Rpdj48ZGl2IHN0eWxlPSJmb250LXNpemU6MTAwJTtjb2xvcjojMDAwMDAwIj48IS0tIG9yaWdp bmFsTWVzc2FnZSAtLT48ZGl2Pi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS08L2Rp dj48ZGl2PkZyb206IEFuZHkgQmllcm1hbiAmbHQ7YW5keUB5dW1hd29ya3MuY29tJmd0OyA8L2Rp dj48ZGl2PkRhdGU6IDUvNy8yMDE2ICAxMjo1MyBQTSAgKEdNVC0wNTowMCkgPC9kaXY+PGRpdj5U bzogIkpvZWwgTS4gSGFscGVybiIgJmx0O2ptaEBqb2VsaGFscGVybi5jb20mZ3Q7IDwvZGl2Pjxk aXY+Q2M6IGkycnNAaWV0Zi5vcmcsIE5ldGNvbmYgJmx0O25ldGNvbmZAaWV0Zi5vcmcmZ3Q7LCBT dXNhbiBIYXJlcyAmbHQ7c2hhcmVzQG5kemguY29tJmd0OyA8L2Rpdj48ZGl2PlN1YmplY3Q6IFJl OiBbaTJyc10gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaGFyZXMtaTJy cy1wcm90b2NvbC1zdHJhd21hbi0wMi50eHQgLSAzLjEuMSA8L2Rpdj48ZGl2Pjxicj48L2Rpdj48 L2Rpdj48ZGl2IGRpcj0ibHRyIj48YnI+PGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxicj48ZGl2 IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gRnJpLCBNYXkgNiwgMjAxNiBhdCA4OjUxIEFNLCBKb2Vs IE0uIEhhbHBlcm4gPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxo YWxwZXJuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmptaEBqb2VsaGFscGVybi5jb208L2E+Jmd0Ozwv c3Bhbj4gd3JvdGU6PGJyPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1h cmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDox ZXgiPlJlYWRpbmcgdGhlIGxhdGVzdCByZXZpc2lvbiwgaW4gc2VjdGlvbiAzLjEuMSwgdGhlIHRl eHQgaW4gYnVsbGV0IDUgc2F5cyB0aGF0IHRoZSBkYXRhIG1vZGVsIGluZGljYXRlcyB3aGljaCBw b3J0aW9ucyBhcmUgZXBoZW1lcmFsLiZuYnNwOyBUaGF0IG1ha2VzIHNlbnNlIHRvIG1lLjxicj4K PGJyPgpUaGVuIGJ1bGxldCA2IHNheXMgdGhhdCB0aGUgbWFuYWdlbWVudCBwcm90b2NvbCBuZWVk cyB0byBzaWduYWwgKGluIGl0cyB5YW5nIGxpYnJhcnkpIHdoaWNoIHBhcnRzIGFyZSBlcGhlbWVy YWwuPGJyPgo8YnI+CldoeSB0aGUgc2Vjb25kIHJlcXVpcmVtZW50PyZuYnNwOyBJZiB0aGUgZGF0 YSBtb2RlbCBpcyBzdXBwb3J0ZWQsIGFuZCB0aGUgZGF0YSBtb2RlbCBzdGF0ZXMgdGhhdCBjZXJ0 YWluIGl0ZW1zIGFyZSBlcGhlbWVyYWwsIHdoYXQgd291bGQgaXQgbWVhbiBpZiB0aGUgc2lnbmFs aW5nIGRpZCBub3QgYWxzbyBzYXkgdGhhdC4mbmJzcDsgQ29udmVyc2VseSwgd2hhdCB3b3VsZCBp dCBtZWFuIGlmIHRoZSBzaWduYWxpbmcgc2FpZCBzb21ldGhpbmcgd2FzIGVwaGVtZXJhbCB0aGF0 IHRoZSBtb2RlbCBkb2VzIG5vdCBkZWZpbmUgYXMgZXBoZW1lcmFsPzxicj4KPGJyPgpJdCBtYXkg YmUgdGhhdCBJIGFtIG1pc3JlYWRpbmcgYnVsbGV0IDYuJm5ic3A7IFBsZWFzZSBleHBsYWluLjxi cj4KPGJyPjwvYmxvY2txdW90ZT48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pkkg dGhpbmsgeW91IGFyZSBjb3JyZWN0IHRoYXQgdGhlIFlBTkcgbGlicmFyeSBkb2VzIG5vdCBuZWVk IGFueSBjaGFuZ2VzPC9kaXY+PGRpdj50byBpZGVudGlmeSBlcGhlbWVyYWwgZGF0YS4mbmJzcDsg T25seSB0aGUgdmFyaWFibGUgY29tcG9uZW50cyBvZjwvZGl2PjxkaXY+WUFORyBjb25mb3JtYW5j ZSBhcmUgY29udGFpbmVkIGluIHRoZSBsaWJyYXJ5LjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+ PGJyPjwvZGl2PjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjow IDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPgpU aGFuayB5b3UsPGJyPgpKb2VsPGJyPgo8YnI+PC9ibG9ja3F1b3RlPjxkaXY+PGJyPjwvZGl2Pjxk aXY+PGJyPjwvZGl2PjxkaXY+QW5keTwvZGl2PjxkaXY+Jm5ic3A7PC9kaXY+PGJsb2NrcXVvdGUg Y2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6 MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+Cl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPgppMnJzIG1haWxpbmcgbGlzdDxicj4KPGEgaHJl Zj0ibWFpbHRvOmkycnNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pMnJzQGlldGYub3JnPC9h Pjxicj4KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMnJz IiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2kycnM8L2E+PGJyPgo8L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjwvZGl2 PjwvZGl2Pgo8L2JvZHk+PC9odG1sPg== ----_com.samsung.android.email_2010411323284380-- From nobody Mon May 9 16:11:10 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC5912D0E6 for ; Mon, 9 May 2016 16:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWlF2IZ1r1kq for ; Mon, 9 May 2016 16:11:06 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FB2412D0A2 for ; Mon, 9 May 2016 16:11:06 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id y84so217557082lfc.0 for ; Mon, 09 May 2016 16:11:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=HaStY+pNmp4LwkTkcVWBirbt5QHJ0zf5ZVqTC3h6q9U=; b=c2uLHFF/QB9JoT63RFY4DyfTrUqImX0FN11btReP7TIW7K9wi0TlS2kp2NHFvO+7NC JF/aX/Ai6+lHXpvVtKVHxPHzJhGV0RehBpbuoCZxkRADdyvxEpTVH1+sPQUGdaAg5dKo 7GQqqim4rT2QeoeWKc3ICueB8wS4KBKO8funutwwNpQotyHdqyQjVC74+KMRnOjHkzKa Q8o4qlicy9p83jaff6C6c8szbZqZgH+nihW8SbZHwP8QAKzK1bho1nlLJHgSSjkmGbvC +3tja/0DDWkd2W0vC4D51UuXIrPiMH8p2/vTEPCIcT2z9XLG4EHPYVHL5OFy60OcNOWw ZRiA== 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; bh=HaStY+pNmp4LwkTkcVWBirbt5QHJ0zf5ZVqTC3h6q9U=; b=ZLMoa8Bv1BXuJpXVFj9XlkglZCKqulam8x27WjXvsuibAGtpUnkY+Gi5tfGfuxddsG cTBKbZ+kVIGfvSCbMQ+dqVkhp7Ix7A4bzgIfblhJRZ7js3Tmkl7YalYv0KhJac1cOrkS 24Xhs+RyejnHJ1rWhUq8mVJq7W9UB4ClG5JuOmroh0+4jnumeSrhA+EWRJ63uO3rB2v4 /jVP6vQpjn07tDLGY/VvR8V1CgAgTLWCp1f+4qEFPvxJRCdSKHJSSmh1pJB8yB5ubeyz oxBkmzfy9pfA81VCIbP57C0UBFAz2P5SF3GLgZrnu3GQ1Lj0BIDGEptZBG3Srn/MH84X Hsxg== X-Gm-Message-State: AOPr4FUafIpzDvsx8ekhN9FDtqdWikZYs83HWXTlVm65+pGEMHegcukw6yVgQKAp8/tw3j8BbdLVlIKm+iW4rQ== MIME-Version: 1.0 X-Received: by 10.112.144.168 with SMTP id sn8mr15410376lbb.65.1462835464559; Mon, 09 May 2016 16:11:04 -0700 (PDT) Received: by 10.112.13.133 with HTTP; Mon, 9 May 2016 16:11:04 -0700 (PDT) In-Reply-To: References: Date: Mon, 9 May 2016 16:11:04 -0700 Message-ID: From: Andy Bierman To: Susan Hares Content-Type: multipart/alternative; boundary=047d7b343ef43afa3c053270ec07 Archived-At: Cc: "i2rs@ietf.org" , Netconf Subject: Re: [Netconf] [i2rs] FW: New Version Notification for draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 23:11:09 -0000 --047d7b343ef43afa3c053270ec07 Content-Type: text/plain; charset=UTF-8 On Mon, May 9, 2016 at 3:09 PM, Susan Hares wrote: > Andy and Joel: > > These are good points. > > What happens if the data model has some ephemeral sections and the I2RS > agent is not supported by the routing system. The data model would specify > the ephemeral section, but there would be no support by i2rs. Is the > support of the ephemeral not a variable condition to be indicated in Yang > module library? > > The server should have a deviations file for the parts it does not support. deviation /some/ephemeral/node { deviate delete { i2rs:ephemeral; } } Sue > Andy > Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartphone > -------- Original message -------- > From: Andy Bierman > Date: 5/7/2016 12:53 PM (GMT-05:00) > To: "Joel M. Halpern" > Cc: i2rs@ietf.org, Netconf , Susan Hares < > shares@ndzh.com> > Subject: Re: [i2rs] FW: New Version Notification for > draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1 > > > > On Fri, May 6, 2016 at 8:51 AM, Joel M. Halpern > wrote: > >> Reading the latest revision, in section 3.1.1, the text in bullet 5 says >> that the data model indicates which portions are ephemeral. That makes >> sense to me. >> >> Then bullet 6 says that the management protocol needs to signal (in its >> yang library) which parts are ephemeral. >> >> Why the second requirement? If the data model is supported, and the data >> model states that certain items are ephemeral, what would it mean if the >> signaling did not also say that. Conversely, what would it mean if the >> signaling said something was ephemeral that the model does not define as >> ephemeral? >> >> It may be that I am misreading bullet 6. Please explain. >> >> > > I think you are correct that the YANG library does not need any changes > to identify ephemeral data. Only the variable components of > YANG conformance are contained in the library. > > > Thank you, >> Joel >> >> > > Andy > > >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> > > --047d7b343ef43afa3c053270ec07 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, May 9, 2016 at 3:09 PM, Susan Hares <shares@ndzh.com> wrote:
Andy and Joel:
=

These are good points.

What ha= ppens if the data model has some ephemeral sections and the I2RS agent is n= ot supported by the routing system.=C2=A0 The data model would specify the = ephemeral section, but there would be no support by i2rs.=C2=A0 Is the supp= ort of the ephemeral not a variable =C2=A0condition to be indicated in Yang= module library?


The server should have a deviations file for the parts it does not support= .

=C2=A0 =C2=A0deviation /some/ephemeral/node {
=C2=A0 =C2=A0 =C2=A0 deviate delete {
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0i2rs:ephemeral;
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0}


Sue


Andy

=C2=A0
Sent via= the Samsung Galaxy Note5, an AT&T 4G LTE smartphone
-------- Original message -------= -
From: Andy Bierman <andy@yumaworks.com>
Date: 5/7/2016 12:53= PM (GMT-05:00)
To: "Joel M. Halpern" <jmh@joelhalpern.com> <= /div>
Cc: i2rs@ietf.= org, Netconf <= netconf@ietf.org>, Susan Hares <shares@ndzh.com>
Subject: Re: [i2rs] = FW: New Version Notification for draft-hares-i2rs-protocol-strawman-02.txt = - 3.1.1



On Fri, May 6, 2016 at 8:51 AM, Joel= M. Halpern <jmh@joelhalpern.com> wrote:
Reading the latest revision, in section 3.1.1, the text in= bullet 5 says that the data model indicates which portions are ephemeral.= =C2=A0 That makes sense to me.

Then bullet 6 says that the management protocol needs to signal (in its yan= g library) which parts are ephemeral.

Why the second requirement?=C2=A0 If the data model is supported, and the d= ata model states that certain items are ephemeral, what would it mean if th= e signaling did not also say that.=C2=A0 Conversely, what would it mean if = the signaling said something was ephemeral that the model does not define a= s ephemeral?

It may be that I am misreading bullet 6.=C2=A0 Please explain.



I think you are correct= that the YANG library does not need any changes
to identify ephe= meral data.=C2=A0 Only the variable components of
YANG conformanc= e are contained in the library.


Thank you,
Joel



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


--047d7b343ef43afa3c053270ec07-- From nobody Mon May 9 16:24:09 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A61D12D110 for ; Mon, 9 May 2016 16:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sIGZZhUNy1e2 for ; Mon, 9 May 2016 16:24:05 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7939C12D17F for ; Mon, 9 May 2016 16:24:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5916; q=dns/txt; s=iport; t=1462836245; x=1464045845; h=subject:references:to:from:message-id:date:mime-version: in-reply-to; bh=iReg13e7M34fbX6TlHbqQXXDoqeDbPnNriuzWUlwSME=; b=cha8VT4/QLUqxJqrs/T11ML6NKffz5jKFK9w5ffL6x/wYRoTjaFJQ1t5 NwFC+T6Tj8wmbrSN5bHLV1p9fF0PyB0eAKDJiSnAxJcZ+om/gMxhaeO1a mUew31rvelmlMAXHh7f57JNoH2lk1IXuhcb0RBAAiJ7jUvwbkNKnAQwJ9 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BRAgD3GjFX/4oNJK1DGoM4VX2tOoZuh?= =?us-ascii?q?HQBDYF2JIVsAoE5OBQBAQEBAQEBZSeEQQEBAQR4ERwDAQIKFg8JAwIBAgEPLAI?= =?us-ascii?q?IBg0GAgEBEIgBAxMOLLplDYQpAQEBAQEBAQEBAQEBAQEBAQEBAReGIIRMgkOCC?= =?us-ascii?q?BQMhS0FkyyERTGFfYVkQoF5gWkXN4QBgweFWIdYh2MeAQFCggUbFoFRIDIBiQk?= =?us-ascii?q?BAQE?= X-IronPort-AV: E=Sophos;i="5.24,602,1454976000"; d="scan'208,217";a="106243793" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 May 2016 23:24:04 +0000 Received: from [10.86.252.90] ([10.86.252.90]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u49NO3cw027916 for ; Mon, 9 May 2016 23:24:04 GMT References: <20160509231748.3475D180006@rfc-editor.org> To: NETCONF From: Benoit Claise X-Forwarded-Message-Id: <20160509231748.3475D180006@rfc-editor.org> Message-ID: <57311C0E.4000908@cisco.com> Date: Mon, 9 May 2016 19:23:58 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160509231748.3475D180006@rfc-editor.org> Content-Type: multipart/alternative; boundary="------------030702000706090001070005" Archived-At: Subject: [Netconf] Fwd: [RFC State] has been added to the RFC Editor database X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 23:24:07 -0000 This is a multi-part message in MIME format. --------------030702000706090001070005 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit congratulations to the authors and the NETCONF community. Regards, Benoit -------- Forwarded Message -------- Subject: [RFC State] has been added to the RFC Editor database Date: Mon, 9 May 2016 16:17:48 -0700 From: rfc-editor@rfc-editor.org To: andy@yumaworks.com, mbj@tail-f.com, kwatsen@juniper.net CC: netconf-ads@ietf.org, netconf-chairs@ietf.org, rfc-editor@rfc-editor.org, mjethanandani@gmail.com, bclaise@cisco.com Author(s), We have received notice that your document draft-ietf-netconf-yang-library-06 has been approved for publication as an RFC. The document has been added to the RFC Editor queue and you can check the status at If you submitted your XML file using the I-D submission tool, we have already retrieved it. If you did not submit the XML file via the I-D submission tool, or if you have an updated version (e.g., updated contact information), please send us the XML file at this time. Please attach the file as draft-ietf-netconf-yang-library-06.xml, and specify any differences between the approved I-D and the document that the XML produces. We recommend using xml2rfc v2 to create your document. See the RSE's message about the RFC Editor's transition to xml2rfc v2 here . If you created this document using -ms nroff, please send us the source file. This should help increase the pace with which documents move through the RFC Editor queue. Please let us know if you have any questions. Thank you. The RFC Editor Team . --------------030702000706090001070005 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit congratulations to the authors and the NETCONF community.

Regards, Benoit


-------- Forwarded Message --------
Subject: [RFC State] <draft-ietf-netconf-yang-library-06> has been added to the RFC Editor database
Date: Mon, 9 May 2016 16:17:48 -0700
From: rfc-editor@rfc-editor.org
To: andy@yumaworks.com, mbj@tail-f.com, kwatsen@juniper.net
CC: netconf-ads@ietf.org, netconf-chairs@ietf.org, rfc-editor@rfc-editor.org, mjethanandani@gmail.com, bclaise@cisco.com 


Author(s),

We have received notice that your document draft-ietf-netconf-yang-library-06 has
been approved for publication as an RFC.  The document has
been added to the RFC Editor queue and you can check the status at
<https://www.rfc-editor.org/current_queue.php>

If you submitted your XML file using the I-D submission tool, we have
already retrieved it.  If you did not submit the XML file via the I-D
submission tool, or if you have an updated version (e.g., updated
contact information), please send us the XML file at this time.  Please
attach the file as draft-ietf-netconf-yang-library-06.xml, and specify 
any differences between the approved I-D and the document that the XML
produces.  We recommend using xml2rfc v2 <http://xml2rfc.ietf.org/> to create
your document.  See the RSE's message about the RFC Editor's transition to
xml2rfc v2 here 
<https://www.rfc-editor.org/pipermail/rfc-interest/2013-December/005835.html>.

If you created this document using -ms nroff, please send us the
source file.

This should help increase the pace with which documents move through
the RFC Editor queue. 

Please let us know if you have any questions.

Thank you.

The RFC Editor Team

.


--------------030702000706090001070005-- From nobody Mon May 9 16:24:47 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1ACA12B05D; Mon, 9 May 2016 16:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.106 X-Spam-Level: X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJ7MBTyz5noD; Mon, 9 May 2016 16:24:43 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C909E12D156; Mon, 9 May 2016 16:24:31 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.172.62.119; Date: Mon, 09 May 2016 19:24:25 -0400 Message-ID: Importance: normal From: Susan Hares To: Andy Bierman MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_2017789250749970" X-Authenticated-User: skh@ndzh.com Archived-At: Cc: "i2rs@ietf.org" , Netconf Subject: Re: [Netconf] [i2rs] FW: New Version Notification for draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 23:24:46 -0000 ----_com.samsung.android.email_2017789250749970 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 QW5keQpHcmVhdC4gwqBUaGlzIHNvbHZlcyB0aGUgTm90dGluZ2hhbSBidWx0IGZvciBpMnJzLiDC oERvZXMgdGhlIHNhbWUgZGV2aWF0aW9uIHdvcmsgZm9yIGkycnMgaW5jbHVkZWQgYnV0IGNvbmZp Z3VyZWQgb2ZmLgpTdWUKCgpTZW50IHZpYSB0aGUgU2Ftc3VuZyBHYWxheHkgTm90ZTUsIGFuIEFU JlQgNEcgTFRFIHNtYXJ0cGhvbmUtLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tRnJv bTogQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IERhdGU6IDUvOS8yMDE2ICA3OjEx IFBNICAoR01ULTA1OjAwKSBUbzogU3VzYW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNvbT4gQ2M6IGky cnNAaWV0Zi5vcmcsICJKb2VsIE0uIEhhbHBlcm4iIDxqbWhAam9lbGhhbHBlcm4uY29tPiwgTmV0 Y29uZiA8bmV0Y29uZkBpZXRmLm9yZz4gU3ViamVjdDogUmU6IFtpMnJzXSBGVzogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1oYXJlcy1pMnJzLXByb3RvY29sLXN0cmF3bWFuLTAy LnR4dCAtIDMuMS4xIAoKCk9uIE1vbiwgTWF5IDksIDIwMTYgYXQgMzowOSBQTSwgU3VzYW4gSGFy ZXMgPHNoYXJlc0BuZHpoLmNvbT4gd3JvdGU6CkFuZHkgYW5kIEpvZWw6ClRoZXNlIGFyZSBnb29k IHBvaW50cy4KV2hhdCBoYXBwZW5zIGlmIHRoZSBkYXRhIG1vZGVsIGhhcyBzb21lIGVwaGVtZXJh bCBzZWN0aW9ucyBhbmQgdGhlIEkyUlMgYWdlbnQgaXMgbm90IHN1cHBvcnRlZCBieSB0aGUgcm91 dGluZyBzeXN0ZW0uwqAgVGhlIGRhdGEgbW9kZWwgd291bGQgc3BlY2lmeSB0aGUgZXBoZW1lcmFs IHNlY3Rpb24sIGJ1dCB0aGVyZSB3b3VsZCBiZSBubyBzdXBwb3J0IGJ5IGkycnMuwqAgSXMgdGhl IHN1cHBvcnQgb2YgdGhlIGVwaGVtZXJhbCBub3QgYSB2YXJpYWJsZSDCoGNvbmRpdGlvbiB0byBi ZSBpbmRpY2F0ZWQgaW4gWWFuZyBtb2R1bGUgbGlicmFyeT8KClRoZSBzZXJ2ZXIgc2hvdWxkIGhh dmUgYSBkZXZpYXRpb25zIGZpbGUgZm9yIHRoZSBwYXJ0cyBpdCBkb2VzIG5vdCBzdXBwb3J0LgrC oCDCoGRldmlhdGlvbiAvc29tZS9lcGhlbWVyYWwvbm9kZSB7wqAgwqAgwqAgZGV2aWF0ZSBkZWxl dGUge8KgIMKgIMKgIMKgIMKgaTJyczplcGhlbWVyYWw7wqAgwqAgwqAgfcKgIMKgfQoKU3VlCgpB bmR5CsKgU2VudCB2aWEgdGhlIFNhbXN1bmcgR2FsYXh5IE5vdGU1LCBhbiBBVCZUIDRHIExURSBz bWFydHBob25lLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLUZyb206IEFuZHkgQmll cm1hbiA8YW5keUB5dW1hd29ya3MuY29tPiBEYXRlOiA1LzcvMjAxNiAgMTI6NTMgUE0gIChHTVQt MDU6MDApIFRvOiAiSm9lbCBNLiBIYWxwZXJuIiA8am1oQGpvZWxoYWxwZXJuLmNvbT4gQ2M6IGky cnNAaWV0Zi5vcmcsIE5ldGNvbmYgPG5ldGNvbmZAaWV0Zi5vcmc+LCBTdXNhbiBIYXJlcyA8c2hh cmVzQG5kemguY29tPiBTdWJqZWN0OiBSZTogW2kycnNdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yIGRyYWZ0LWhhcmVzLWkycnMtcHJvdG9jb2wtc3RyYXdtYW4tMDIudHh0IC0gMy4x LjEgCgoKT24gRnJpLCBNYXkgNiwgMjAxNiBhdCA4OjUxIEFNLCBKb2VsIE0uIEhhbHBlcm4gPGpt aEBqb2VsaGFscGVybi5jb20+IHdyb3RlOgpSZWFkaW5nIHRoZSBsYXRlc3QgcmV2aXNpb24sIGlu IHNlY3Rpb24gMy4xLjEsIHRoZSB0ZXh0IGluIGJ1bGxldCA1IHNheXMgdGhhdCB0aGUgZGF0YSBt b2RlbCBpbmRpY2F0ZXMgd2hpY2ggcG9ydGlvbnMgYXJlIGVwaGVtZXJhbC7CoCBUaGF0IG1ha2Vz IHNlbnNlIHRvIG1lLgoKCgpUaGVuIGJ1bGxldCA2IHNheXMgdGhhdCB0aGUgbWFuYWdlbWVudCBw cm90b2NvbCBuZWVkcyB0byBzaWduYWwgKGluIGl0cyB5YW5nIGxpYnJhcnkpIHdoaWNoIHBhcnRz IGFyZSBlcGhlbWVyYWwuCgoKCldoeSB0aGUgc2Vjb25kIHJlcXVpcmVtZW50P8KgIElmIHRoZSBk YXRhIG1vZGVsIGlzIHN1cHBvcnRlZCwgYW5kIHRoZSBkYXRhIG1vZGVsIHN0YXRlcyB0aGF0IGNl cnRhaW4gaXRlbXMgYXJlIGVwaGVtZXJhbCwgd2hhdCB3b3VsZCBpdCBtZWFuIGlmIHRoZSBzaWdu YWxpbmcgZGlkIG5vdCBhbHNvIHNheSB0aGF0LsKgIENvbnZlcnNlbHksIHdoYXQgd291bGQgaXQg bWVhbiBpZiB0aGUgc2lnbmFsaW5nIHNhaWQgc29tZXRoaW5nIHdhcyBlcGhlbWVyYWwgdGhhdCB0 aGUgbW9kZWwgZG9lcyBub3QgZGVmaW5lIGFzIGVwaGVtZXJhbD8KCgoKSXQgbWF5IGJlIHRoYXQg SSBhbSBtaXNyZWFkaW5nIGJ1bGxldCA2LsKgIFBsZWFzZSBleHBsYWluLgoKCgoKSSB0aGluayB5 b3UgYXJlIGNvcnJlY3QgdGhhdCB0aGUgWUFORyBsaWJyYXJ5IGRvZXMgbm90IG5lZWQgYW55IGNo YW5nZXN0byBpZGVudGlmeSBlcGhlbWVyYWwgZGF0YS7CoCBPbmx5IHRoZSB2YXJpYWJsZSBjb21w b25lbnRzIG9mWUFORyBjb25mb3JtYW5jZSBhcmUgY29udGFpbmVkIGluIHRoZSBsaWJyYXJ5LgoK ClRoYW5rIHlvdSwKCkpvZWwKCgoKCkFuZHnCoApfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwoKaTJycyBtYWlsaW5nIGxpc3QKCmkycnNAaWV0Zi5vcmcKCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJycwoKCgoKCg== ----_com.samsung.android.email_2017789250749970 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2PkFuZHk8L2Rpdj48ZGl2Pjxi cj48L2Rpdj48ZGl2PkdyZWF0LiAmbmJzcDtUaGlzIHNvbHZlcyB0aGUgTm90dGluZ2hhbSBidWx0 IGZvciBpMnJzLiAmbmJzcDtEb2VzIHRoZSBzYW1lIGRldmlhdGlvbiB3b3JrIGZvciBpMnJzIGlu Y2x1ZGVkIGJ1dCBjb25maWd1cmVkIG9mZi48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlN1ZTwv ZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXYgaWQ9 ImNvbXBvc2VyX3NpZ25hdHVyZSI+PGRpdiBzdHlsZT0iZm9udC1zaXplOjg1JTtjb2xvcjojNTc1 NzU3Ij5TZW50IHZpYSB0aGUgU2Ftc3VuZyBHYWxheHkgTm90ZTUsIGFuIEFUJmFtcDtUIDRHIExU RSBzbWFydHBob25lPC9kaXY+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1zaXplOjEwMCU7Y29sb3I6 IzAwMDAwMCI+PCEtLSBvcmlnaW5hbE1lc3NhZ2UgLS0+PGRpdj4tLS0tLS0tLSBPcmlnaW5hbCBt ZXNzYWdlIC0tLS0tLS0tPC9kaXY+PGRpdj5Gcm9tOiBBbmR5IEJpZXJtYW4gJmx0O2FuZHlAeXVt YXdvcmtzLmNvbSZndDsgPC9kaXY+PGRpdj5EYXRlOiA1LzkvMjAxNiAgNzoxMSBQTSAgKEdNVC0w NTowMCkgPC9kaXY+PGRpdj5UbzogU3VzYW4gSGFyZXMgJmx0O3NoYXJlc0BuZHpoLmNvbSZndDsg PC9kaXY+PGRpdj5DYzogaTJyc0BpZXRmLm9yZywgIkpvZWwgTS4gSGFscGVybiIgJmx0O2ptaEBq b2VsaGFscGVybi5jb20mZ3Q7LCBOZXRjb25mICZsdDtuZXRjb25mQGlldGYub3JnJmd0OyA8L2Rp dj48ZGl2PlN1YmplY3Q6IFJlOiBbaTJyc10gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtaGFyZXMtaTJycy1wcm90b2NvbC1zdHJhd21hbi0wMi50eHQgLSAzLjEuMSA8L2Rp dj48ZGl2Pjxicj48L2Rpdj48L2Rpdj48ZGl2IGRpcj0ibHRyIj48YnI+PGRpdiBjbGFzcz0iZ21h aWxfZXh0cmEiPjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gTW9uLCBNYXkgOSwgMjAx NiBhdCAzOjA5IFBNLCBTdXNhbiBIYXJlcyA8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9Im1h aWx0bzpzaGFyZXNAbmR6aC5jb20iIHRhcmdldD0iX2JsYW5rIj5zaGFyZXNAbmR6aC5jb208L2E+ Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5 bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmct bGVmdDoxZXgiPjxkaXY+PGRpdj5BbmR5IGFuZCBKb2VsOjwvZGl2PjxkaXY+PGJyPjwvZGl2Pjxk aXY+VGhlc2UgYXJlIGdvb2QgcG9pbnRzLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+V2hhdCBo YXBwZW5zIGlmIHRoZSBkYXRhIG1vZGVsIGhhcyBzb21lIGVwaGVtZXJhbCBzZWN0aW9ucyBhbmQg dGhlIEkyUlMgYWdlbnQgaXMgbm90IHN1cHBvcnRlZCBieSB0aGUgcm91dGluZyBzeXN0ZW0uJm5i c3A7IFRoZSBkYXRhIG1vZGVsIHdvdWxkIHNwZWNpZnkgdGhlIGVwaGVtZXJhbCBzZWN0aW9uLCBi dXQgdGhlcmUgd291bGQgYmUgbm8gc3VwcG9ydCBieSBpMnJzLiZuYnNwOyBJcyB0aGUgc3VwcG9y dCBvZiB0aGUgZXBoZW1lcmFsIG5vdCBhIHZhcmlhYmxlICZuYnNwO2NvbmRpdGlvbiB0byBiZSBp bmRpY2F0ZWQgaW4gWWFuZyBtb2R1bGUgbGlicmFyeT88L2Rpdj48ZGl2Pjxicj48L2Rpdj48L2Rp dj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+PGRpdj5UaGUgc2VydmVyIHNob3VsZCBoYXZl IGEgZGV2aWF0aW9ucyBmaWxlIGZvciB0aGUgcGFydHMgaXQgZG9lcyBub3Qgc3VwcG9ydC48L2Rp dj48ZGl2Pjxicj48L2Rpdj48ZGl2PiZuYnNwOyAmbmJzcDtkZXZpYXRpb24gL3NvbWUvZXBoZW1l cmFsL25vZGUgezwvZGl2PjxkaXY+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgZGV2aWF0ZSBkZWxldGUg ezwvZGl2PjxkaXY+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2kycnM6ZXBoZW1l cmFsOzwvZGl2PjxkaXY+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgfTwvZGl2PjxkaXY+Jm5ic3A7ICZu YnNwO308L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48YmxvY2txdW90ZSBjbGFz cz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHgg I2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij48ZGl2PjxkaXY+PC9kaXY+PGRpdj5TdWU8L2Rp dj48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5B bmR5PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj4mbmJzcDs8L2Rpdj48YmxvY2txdW90ZSBjbGFz cz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHgg I2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij48ZGl2PjxkaXY+PGRpdiBzdHlsZT0iZm9udC1z aXplOjg1JTtjb2xvcjojNTc1NzU3Ij5TZW50IHZpYSB0aGUgU2Ftc3VuZyBHYWxheHkgTm90ZTUs IGFuIEFUJmFtcDtUIDRHIExURSBzbWFydHBob25lPC9kaXY+PC9kaXY+PGRpdiBzdHlsZT0iZm9u dC1zaXplOjEwMCU7Y29sb3I6IzAwMDAwMCI+PGRpdj4tLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdl IC0tLS0tLS0tPC9kaXY+PGRpdj5Gcm9tOiBBbmR5IEJpZXJtYW4gJmx0OzxhIGhyZWY9Im1haWx0 bzphbmR5QHl1bWF3b3Jrcy5jb20iIHRhcmdldD0iX2JsYW5rIj5hbmR5QHl1bWF3b3Jrcy5jb208 L2E+Jmd0OyA8L2Rpdj48ZGl2PkRhdGU6IDUvNy8yMDE2ICAxMjo1MyBQTSAgKEdNVC0wNTowMCkg PC9kaXY+PGRpdj5UbzogIkpvZWwgTS4gSGFscGVybiIgJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhA am9lbGhhbHBlcm4uY29tIiB0YXJnZXQ9Il9ibGFuayI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4m Z3Q7IDwvZGl2PjxkaXY+Q2M6IDxhIGhyZWY9Im1haWx0bzppMnJzQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+aTJyc0BpZXRmLm9yZzwvYT4sIE5ldGNvbmYgJmx0OzxhIGhyZWY9Im1haWx0bzpu ZXRjb25mQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bmV0Y29uZkBpZXRmLm9yZzwvYT4mZ3Q7 LCBTdXNhbiBIYXJlcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNoYXJlc0BuZHpoLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPnNoYXJlc0BuZHpoLmNvbTwvYT4mZ3Q7IDwvZGl2PjxkaXY+U3ViamVjdDogUmU6 IFtpMnJzXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1oYXJlcy1pMnJz LXByb3RvY29sLXN0cmF3bWFuLTAyLnR4dCAtIDMuMS4xIDwvZGl2PjxkaXY+PGJyPjwvZGl2Pjwv ZGl2PjxkaXYgZGlyPSJsdHIiPjxicj48ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPjxkaXYg Y2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBGcmksIE1heSA2LCAyMDE2IGF0IDg6NTEgQU0sIEpvZWwg TS4gSGFscGVybiA8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhh bHBlcm4uY29tIiB0YXJnZXQ9Il9ibGFuayI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7PC9z cGFuPiB3cm90ZTo8YnI+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFy Z2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFl eCI+UmVhZGluZyB0aGUgbGF0ZXN0IHJldmlzaW9uLCBpbiBzZWN0aW9uIDMuMS4xLCB0aGUgdGV4 dCBpbiBidWxsZXQgNSBzYXlzIHRoYXQgdGhlIGRhdGEgbW9kZWwgaW5kaWNhdGVzIHdoaWNoIHBv cnRpb25zIGFyZSBlcGhlbWVyYWwuJm5ic3A7IFRoYXQgbWFrZXMgc2Vuc2UgdG8gbWUuPGJyPgo8 YnI+ClRoZW4gYnVsbGV0IDYgc2F5cyB0aGF0IHRoZSBtYW5hZ2VtZW50IHByb3RvY29sIG5lZWRz IHRvIHNpZ25hbCAoaW4gaXRzIHlhbmcgbGlicmFyeSkgd2hpY2ggcGFydHMgYXJlIGVwaGVtZXJh bC48YnI+Cjxicj4KV2h5IHRoZSBzZWNvbmQgcmVxdWlyZW1lbnQ/Jm5ic3A7IElmIHRoZSBkYXRh IG1vZGVsIGlzIHN1cHBvcnRlZCwgYW5kIHRoZSBkYXRhIG1vZGVsIHN0YXRlcyB0aGF0IGNlcnRh aW4gaXRlbXMgYXJlIGVwaGVtZXJhbCwgd2hhdCB3b3VsZCBpdCBtZWFuIGlmIHRoZSBzaWduYWxp bmcgZGlkIG5vdCBhbHNvIHNheSB0aGF0LiZuYnNwOyBDb252ZXJzZWx5LCB3aGF0IHdvdWxkIGl0 IG1lYW4gaWYgdGhlIHNpZ25hbGluZyBzYWlkIHNvbWV0aGluZyB3YXMgZXBoZW1lcmFsIHRoYXQg dGhlIG1vZGVsIGRvZXMgbm90IGRlZmluZSBhcyBlcGhlbWVyYWw/PGJyPgo8YnI+Ckl0IG1heSBi ZSB0aGF0IEkgYW0gbWlzcmVhZGluZyBidWxsZXQgNi4mbmJzcDsgUGxlYXNlIGV4cGxhaW4uPGJy Pgo8YnI+PC9ibG9ja3F1b3RlPjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+SSB0 aGluayB5b3UgYXJlIGNvcnJlY3QgdGhhdCB0aGUgWUFORyBsaWJyYXJ5IGRvZXMgbm90IG5lZWQg YW55IGNoYW5nZXM8L2Rpdj48ZGl2PnRvIGlkZW50aWZ5IGVwaGVtZXJhbCBkYXRhLiZuYnNwOyBP bmx5IHRoZSB2YXJpYWJsZSBjb21wb25lbnRzIG9mPC9kaXY+PGRpdj5ZQU5HIGNvbmZvcm1hbmNl IGFyZSBjb250YWluZWQgaW4gdGhlIGxpYnJhcnkuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48 YnI+PC9kaXY+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAg MCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+ClRo YW5rIHlvdSw8YnI+CkpvZWw8YnI+Cjxicj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+PGRp dj48YnI+PC9kaXY+PGRpdj5BbmR5PC9kaXY+PGRpdj4mbmJzcDs8L2Rpdj48YmxvY2txdW90ZSBj bGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDox cHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+CmkycnMgbWFpbGluZyBsaXN0PGJyPgo8YSBocmVm PSJtYWlsdG86aTJyc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmkycnNAaWV0Zi5vcmc8L2E+ PGJyPgo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2kycnMi IHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vaTJyczwvYT48YnI+CjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PC9kaXY+ PC9kaXY+CjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PC9kaXY+PC9kaXY+CjwvYm9keT48 L2h0bWw+ ----_com.samsung.android.email_2017789250749970-- From nobody Mon May 9 16:32:06 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76BD312D156 for ; Mon, 9 May 2016 16:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uep_4K2IdQ_d for ; Mon, 9 May 2016 16:32:02 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A172D1200A0 for ; Mon, 9 May 2016 16:32:01 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id u64so217812839lff.3 for ; Mon, 09 May 2016 16:32:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=/TRR8u5JSGFkTJmxtpyZf2/VHiFl7Thz/eB6zlPwXbc=; b=KQlrnDrfQ6KlhPWu1xGsVonrrFEALVHaArRsS7A7XyTujf1YioYGiobmwEKkbJkkO6 mti3lwO+Trio1Sy7l5gjvVHHP9XGRsu9LyJZgl3foZf543he8B0V6Og7eAkQYS7E43cv TxZu0HEBZIRsq5BM5BCRQTVcDIyGWZ6WMafUIGWlvVjjVsX4+xR5NJsblOkjQHxWJmbl /Hvdwg5jqEreS0LRQ6eHzM+CAi/dVu4HWwYtE2DbfUkMMUbP4rkzBA+cFp/uaKMWRGj1 eneUYuEP9YS1sOxGuc0Xnt/8MBBfO91fsxIYXPKYVaRgg+GSCeVmJU+8RiaemDOa1vVE q2Hw== 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; bh=/TRR8u5JSGFkTJmxtpyZf2/VHiFl7Thz/eB6zlPwXbc=; b=Pyai1wCaKVo5wgOXuJpYYUjH7dExVpzvBrNGa0qRZUyEvTZWb+6QTt2MLjbSdIqTv9 UYQSEouAP78bLJsbyeDEgueU3nLqu5AtFD4ZtLYrXFCnB412hbGoUOXaWyKrUUEg1TjO r1opTd2Cxi61nDwnMhMMho8tansdt9kJmJOrgzPnmX/PpzTsKVqUdBnbOlswNmx+Xtr/ i5NFpOx6eq1KR6CYow23b8MrY0N63nPf1U3po/zMO/gSUVNB1R/ydjD7iV1S501OJtnU pCEff3ZQRD3sctc0ayPHak+WyL7VQlqzim7JuGKwY0KFjTE5ZuM1+3u0vsfUeaeNuIi+ wrng== X-Gm-Message-State: AOPr4FUZ1exUYXmkknYkkWFHYNhMH/z3ccwMTcfd++tL3KT80T4OAXXqG2y2YzMu0GVrd2X/X6aqUhHT8cGHkQ== MIME-Version: 1.0 X-Received: by 10.112.184.79 with SMTP id es15mr15373089lbc.30.1462836719942; Mon, 09 May 2016 16:31:59 -0700 (PDT) Received: by 10.112.13.133 with HTTP; Mon, 9 May 2016 16:31:59 -0700 (PDT) In-Reply-To: References: Date: Mon, 9 May 2016 16:31:59 -0700 Message-ID: From: Andy Bierman To: Susan Hares Content-Type: multipart/alternative; boundary=001a1133ac900e996a053271379f Archived-At: Cc: "i2rs@ietf.org" , Netconf Subject: Re: [Netconf] [i2rs] FW: New Version Notification for draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 23:32:05 -0000 --001a1133ac900e996a053271379f Content-Type: text/plain; charset=UTF-8 On Mon, May 9, 2016 at 4:24 PM, Susan Hares wrote: > Andy > > Great. This solves the Nottingham bult for i2rs. Does the same deviation > work for i2rs included but configured off. > > I don't understand the point of specifying this property in the YANG module if the operator is allowed to configure it on/off. Deviations alter the schema definition. Configuration alters instances of the data. IMO I2RS does not need such complex configuration. Access control can be used to configure I2RS on or off on specific data nodes. Sue > > Andy > > > Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartphone > -------- Original message -------- > From: Andy Bierman > Date: 5/9/2016 7:11 PM (GMT-05:00) > To: Susan Hares > Cc: i2rs@ietf.org, "Joel M. Halpern" , Netconf < > netconf@ietf.org> > Subject: Re: [i2rs] FW: New Version Notification for > draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1 > > > > On Mon, May 9, 2016 at 3:09 PM, Susan Hares wrote: > >> Andy and Joel: >> >> These are good points. >> >> What happens if the data model has some ephemeral sections and the I2RS >> agent is not supported by the routing system. The data model would specify >> the ephemeral section, but there would be no support by i2rs. Is the >> support of the ephemeral not a variable condition to be indicated in Yang >> module library? >> >> > The server should have a deviations file for the parts it does not support. > > deviation /some/ephemeral/node { > deviate delete { > i2rs:ephemeral; > } > } > > > Sue >> > > > Andy > > > >> Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartphone >> -------- Original message -------- >> From: Andy Bierman >> Date: 5/7/2016 12:53 PM (GMT-05:00) >> To: "Joel M. Halpern" >> Cc: i2rs@ietf.org, Netconf , Susan Hares < >> shares@ndzh.com> >> Subject: Re: [i2rs] FW: New Version Notification for >> draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1 >> >> >> >> On Fri, May 6, 2016 at 8:51 AM, Joel M. Halpern >> wrote: >> >>> Reading the latest revision, in section 3.1.1, the text in bullet 5 says >>> that the data model indicates which portions are ephemeral. That makes >>> sense to me. >>> >>> Then bullet 6 says that the management protocol needs to signal (in its >>> yang library) which parts are ephemeral. >>> >>> Why the second requirement? If the data model is supported, and the >>> data model states that certain items are ephemeral, what would it mean if >>> the signaling did not also say that. Conversely, what would it mean if the >>> signaling said something was ephemeral that the model does not define as >>> ephemeral? >>> >>> It may be that I am misreading bullet 6. Please explain. >>> >>> >> >> I think you are correct that the YANG library does not need any changes >> to identify ephemeral data. Only the variable components of >> YANG conformance are contained in the library. >> >> >> Thank you, >>> Joel >>> >>> >> >> Andy >> >> >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>> >> >> > --001a1133ac900e996a053271379f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, May 9, 2016 at 4:24 PM, Susan Hares <shares@ndzh.com> wrote:
Andy

<= /div>
Great.=C2=A0 This solves the Nottingham bult for i2rs.=C2=A0 Does= the same deviation work for i2rs included but configured off.

I don't understand the p= oint of specifying this property in the YANG module
if the operat= or is allowed to configure it on/off.

Deviations a= lter the schema definition.
Configuration alters instances of the= data.

IMO I2RS does not need such complex configu= ration.
Access control can be used to configure I2RS on or off on= specific data nodes.



Sue



Andy
=C2=A0


=
Sent via the Samsung = Galaxy Note5, an AT&T 4G LTE smartphone
-------- Original message --------
F= rom: Andy Bierman <andy@yumaworks.com>
Date: 5/9/2016 7:11 PM (GMT-05:0= 0)
To: Susan Hares <shares@ndzh.com>
Cc: i2rs@ietf.org, "Joel M. Halpern" &= lt;jmh@joelhalpern= .com>, Netconf <netconf@ietf.org>
Subject: Re: [i2rs] FW: New Versio= n Notification for draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1
=



On Mon, May 9, 2016 at 3:09 PM, Susan Hares <shares= @ndzh.com> wrote:
Andy and Joel:

These are good points.
=
What happens if the data model has some ephemeral sections a= nd the I2RS agent is not supported by the routing system.=C2=A0 The data mo= del would specify the ephemeral section, but there would be no support by i= 2rs.=C2=A0 Is the support of the ephemeral not a variable =C2=A0condition t= o be indicated in Yang module library?


The server should have a deviations file for the par= ts it does not support.

=C2=A0 =C2=A0deviation /so= me/ephemeral/node {
=C2=A0 =C2=A0 =C2=A0 deviate delete {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0i2rs:ephemeral;
=C2=A0 =C2= =A0 =C2=A0 }
=C2=A0 =C2=A0}


Sue


Andy

=C2=A0<= /div>
Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartph= one
-------- Or= iginal message --------
From: Andy Bierman <andy@yumaworks.com>
Date: 5/7/2016 12:53 PM (GMT-05:00)
To: "Joel M. Halpern= " <jmh@joe= lhalpern.com>
Cc: i2rs@ietf.org, Netconf <netconf@ietf.org>, Susan Hares <shares@ndzh.com>
Subject: Re: [i2rs] FW: New Version Notification for draft-hares-i2rs-pro= tocol-strawman-02.txt - 3.1.1

<= br>

On Fri, May 6,= 2016 at 8:51 AM, Joel M. Halpern <jmh@joelhalpern.com> wr= ote:
Reading the latest revision, in sect= ion 3.1.1, the text in bullet 5 says that the data model indicates which po= rtions are ephemeral.=C2=A0 That makes sense to me.

Then bullet 6 says that the management protocol needs to signal (in its yan= g library) which parts are ephemeral.

Why the second requirement?=C2=A0 If the data model is supported, and the d= ata model states that certain items are ephemeral, what would it mean if th= e signaling did not also say that.=C2=A0 Conversely, what would it mean if = the signaling said something was ephemeral that the model does not define a= s ephemeral?

It may be that I am misreading bullet 6.=C2=A0 Please explain.



I think you are correct= that the YANG library does not need any changes
to identify ephe= meral data.=C2=A0 Only the variable components of
YANG conformanc= e are contained in the library.


Thank you,
Joel



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



--001a1133ac900e996a053271379f-- From nobody Mon May 9 22:34:39 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 368D912B004; Mon, 9 May 2016 22:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4kujqMjCMVl; Mon, 9 May 2016 22:34:32 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 2544F12B02C; Mon, 9 May 2016 22:34:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 0BD70245B51; Mon, 9 May 2016 22:34:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1462858472; bh=BZ5jwnwqHBBu3dnaG4A08SvLTOSrdDvY1Frp39O01XA=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=GNwvaXRqqFwqvtFfG6qrlMy7rFgL41aeFAdD/mPS7MVxpd988y7icq5FoZJnbqDpl GNTEXlgy5PSFROW9MPGSkA0+iQrPsDrUIbAIDoPgs3Rsuku/X5So3YjpXQ6CK7deqd QAgr0qYxZ219Evq2jWwV+iW2DUx1CWLKcuOcWBrI= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [88.131.14.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 313C82409E3; Mon, 9 May 2016 22:34:20 -0700 (PDT) To: Susan Hares , Andy Bierman References: From: "Joel M. Halpern" Message-ID: <0fa49ba0-0a56-21fb-4878-e95adfcd1b49@joelhalpern.com> Date: Tue, 10 May 2016 01:34:10 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "i2rs@ietf.org" , Netconf Subject: Re: [Netconf] [i2rs] FW: New Version Notification for draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 05:34:34 -0000 As I understand it, if a model requires ephemeral elements, and the agent does not support ephemeral, then the agent can not claim to support the model. Yes, deviations allow you to specify this, as Andy says. But this is specifying a failure to conform. I would go far as to say that such an agent is not an I2RS agent, but that is a step beyond the NetConf compliance definitions. Yours, Joel On 5/9/16 6:09 PM, Susan Hares wrote: > Andy and Joel: > > These are good points. > > What happens if the data model has some ephemeral sections and the I2RS > agent is not supported by the routing system. The data model would > specify the ephemeral section, but there would be no support by i2rs. > Is the support of the ephemeral not a variable condition to be > indicated in Yang module library? > > Sue > Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartphone > -------- Original message -------- > From: Andy Bierman > Date: 5/7/2016 12:53 PM (GMT-05:00) > To: "Joel M. Halpern" > Cc: i2rs@ietf.org, Netconf , Susan Hares > > Subject: Re: [i2rs] FW: New Version Notification for > draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1 > > > > On Fri, May 6, 2016 at 8:51 AM, Joel M. Halpern > wrote: > > Reading the latest revision, in section 3.1.1, the text in bullet 5 > says that the data model indicates which portions are ephemeral. > That makes sense to me. > > Then bullet 6 says that the management protocol needs to signal (in > its yang library) which parts are ephemeral. > > Why the second requirement? If the data model is supported, and the > data model states that certain items are ephemeral, what would it > mean if the signaling did not also say that. Conversely, what would > it mean if the signaling said something was ephemeral that the model > does not define as ephemeral? > > It may be that I am misreading bullet 6. Please explain. > > > > I think you are correct that the YANG library does not need any changes > to identify ephemeral data. Only the variable components of > YANG conformance are contained in the library. > > > Thank you, > Joel > > > > Andy > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > From nobody Tue May 10 04:25:40 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBA6E12B045; Tue, 10 May 2016 04:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NbgRcceaKjzE; Tue, 10 May 2016 04:25:35 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48F6312B03A; Tue, 10 May 2016 04:25:35 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.91.193.41; From: "Susan Hares" To: "'Joel M. Halpern'" , "'Andy Bierman'" References: <0fa49ba0-0a56-21fb-4878-e95adfcd1b49@joelhalpern.com> In-Reply-To: <0fa49ba0-0a56-21fb-4878-e95adfcd1b49@joelhalpern.com> Date: Tue, 10 May 2016 07:25:29 -0400 Message-ID: <000301d1aaae$aa9be570$ffd3b050$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIojh5uyd+OkF1XWRDRkYAVtqAd8AKJO+xTnu/28RA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, 'Netconf' Subject: Re: [Netconf] [i2rs] FW: New Version Notification for draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 11:25:38 -0000 Joel:=20 What happens if the code supports the I2RS agent, but the I2RS agent is = configured to be "off"? Is this covered by the deviations or is this = variable configuration?=20 Sue=20 -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Sent: Tuesday, May 10, 2016 1:34 AM To: Susan Hares; Andy Bierman Cc: i2rs@ietf.org; Netconf Subject: Re: [i2rs] FW: New Version Notification for = draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1 As I understand it, if a model requires ephemeral elements, and the = agent does not support ephemeral, then the agent can not claim to = support the model. Yes, deviations allow you to specify this, as Andy says. But this is = specifying a failure to conform. I would go far as to say that such an agent is not an I2RS agent, but = that is a step beyond the NetConf compliance definitions. Yours, Joel On 5/9/16 6:09 PM, Susan Hares wrote: > Andy and Joel: > > These are good points. > > What happens if the data model has some ephemeral sections and the=20 > I2RS agent is not supported by the routing system. The data model=20 > would specify the ephemeral section, but there would be no support by = i2rs. > Is the support of the ephemeral not a variable condition to be=20 > indicated in Yang module library? > > Sue > Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartphone > -------- Original message -------- > From: Andy Bierman > Date: 5/7/2016 12:53 PM (GMT-05:00) > To: "Joel M. Halpern" > Cc: i2rs@ietf.org, Netconf , Susan Hares=20 > > Subject: Re: [i2rs] FW: New Version Notification for=20 > draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1 > > > > On Fri, May 6, 2016 at 8:51 AM, Joel M. Halpern > wrote: > > Reading the latest revision, in section 3.1.1, the text in bullet = 5 > says that the data model indicates which portions are ephemeral. > That makes sense to me. > > Then bullet 6 says that the management protocol needs to signal = (in > its yang library) which parts are ephemeral. > > Why the second requirement? If the data model is supported, and = the > data model states that certain items are ephemeral, what would it > mean if the signaling did not also say that. Conversely, what = would > it mean if the signaling said something was ephemeral that the = model > does not define as ephemeral? > > It may be that I am misreading bullet 6. Please explain. > > > > I think you are correct that the YANG library does not need any=20 > changes to identify ephemeral data. Only the variable components of=20 > YANG conformance are contained in the library. > > > Thank you, > Joel > > > > Andy > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > From nobody Tue May 10 05:11:55 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA68212B031; Tue, 10 May 2016 05:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUOCfpqrzUeR; Tue, 10 May 2016 05:11:47 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 DFE8E12D0C1; Tue, 10 May 2016 05:11:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id A4EE9240C4F; Tue, 10 May 2016 05:11:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1462882306; bh=h4ROFC1g3Mgm2/06PBzIdGUSon+UdC4fEmy+cG4v68k=; h=Date:Subject:From:To:Cc:From; b=gqaqoLhhuQyNNzBKU/DS0eYBqzHb7pspBFT7vXOi0kSuodm1M+q2giw10XsKY343Y UtQbWZU3skqNkVrsWTNRBHDJeXAAvvasXAXKDKhsW5hA2qSQNMstzTCkgGin+34ZAl MezKhfLFCnGX7NionF0HngMIHzyIjBOxOqSgvuBI= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [10.148.56.111] (sessfw99-sesbfw99-95.ericsson.net [192.176.1.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 618C02409E3; Tue, 10 May 2016 05:11:45 -0700 (PDT) Date: Tue, 10 May 2016 14:11:41 +0200 Message-ID: <7eqdbrhnm368w3aqvlarweoi.1462882301561@email.android.com> Importance: normal From: "jmh.direct" To: Susan Hares , "'Joel M. Halpern'" , 'Andy Bierman' MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_934795023916920" Archived-At: Cc: i2rs@ietf.org, 'Netconf' Subject: Re: [Netconf] [i2rs] FW: New Version Notification for draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 12:11:49 -0000 ----_com.samsung.android.email_934795023916920 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SWYgdGhlIEkyUlMgYXJlbid0IGlzIG9mZiB0aGVuIHRoZSBzeXN0ZW0gZG9lcyBub3QgY3VycmVu dGx5IHN1cHBvcnQgdGhpcyBtb2RlbHMuIMKgVGhpcyBpcyBqdXN0IGxpa2UgYW55IG90aGVyIG9w dGlvbmFsIFlBTkcgbW9kdWxlLiDCoElmIHlvdSBhcmUgbm90IGN1cnJlbnRseSBwcmVwYXJlZCB0 byB1c2UgaXQsIHlvdSBkb24ndCBjbGFpbSB0byBzdXBwb3J0IGl0LgpDYXZlYXQ6IFRoZSBOZXRN b2QgZm9sa3MgbWF5IGhhdmUgY29tZSB1cCB3aXRoIGEgbW9yZSBudWFuY2VkIG1lY2hhbmlzbS4g wqAKWW91cnMsSm9lbAoKClNlbnQgdmlhIHRoZSBTYW1zdW5nIEdhbGF4eSBTwq4gNiwgYW4gQVQm VCA0RyBMVEUgc21hcnRwaG9uZS0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS1Gcm9t OiBTdXNhbiBIYXJlcyA8c2hhcmVzQG5kemguY29tPiBEYXRlOiA1LzEwLzIwMTYgIDE6MjUgUE0g IChHTVQrMDE6MDApIFRvOiAiJ0pvZWwgTS4gSGFscGVybiciIDxqbWhAam9lbGhhbHBlcm4uY29t PiwgJ0FuZHkgQmllcm1hbicgPGFuZHlAeXVtYXdvcmtzLmNvbT4gQ2M6IGkycnNAaWV0Zi5vcmcs ICdOZXRjb25mJyA8bmV0Y29uZkBpZXRmLm9yZz4gU3ViamVjdDogUkU6IFtpMnJzXSBGVzogTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1oYXJlcy1pMnJzLXByb3RvY29sLXN0cmF3 bWFuLTAyLnR4dCAtIDMuMS4xIApKb2VsOiAKCldoYXQgaGFwcGVucyBpZiB0aGUgY29kZSBzdXBw b3J0cyB0aGUgSTJSUyBhZ2VudCwgYnV0IHRoZSBJMlJTIGFnZW50IGlzIGNvbmZpZ3VyZWQgdG8g YmUgIm9mZiI/wqAgSXMgdGhpcyBjb3ZlcmVkIGJ5IHRoZSBkZXZpYXRpb25zIG9yIGlzIHRoaXMg dmFyaWFibGUgY29uZmlndXJhdGlvbj8gCgpTdWUgCgotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQpGcm9tOiBKb2VsIE0uIEhhbHBlcm4gW21haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tXSAKU2Vu dDogVHVlc2RheSwgTWF5IDEwLCAyMDE2IDE6MzQgQU0KVG86IFN1c2FuIEhhcmVzOyBBbmR5IEJp ZXJtYW4KQ2M6IGkycnNAaWV0Zi5vcmc7IE5ldGNvbmYKU3ViamVjdDogUmU6IFtpMnJzXSBGVzog TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1oYXJlcy1pMnJzLXByb3RvY29sLXN0 cmF3bWFuLTAyLnR4dCAtIDMuMS4xCgpBcyBJIHVuZGVyc3RhbmQgaXQsIGlmIGEgbW9kZWwgcmVx dWlyZXMgZXBoZW1lcmFsIGVsZW1lbnRzLCBhbmQgdGhlIGFnZW50IGRvZXMgbm90IHN1cHBvcnQg ZXBoZW1lcmFsLCB0aGVuIHRoZSBhZ2VudCBjYW4gbm90IGNsYWltIHRvIHN1cHBvcnQgdGhlIG1v ZGVsLgoKWWVzLCBkZXZpYXRpb25zIGFsbG93IHlvdSB0byBzcGVjaWZ5IHRoaXMsIGFzIEFuZHkg c2F5cy7CoCBCdXQgdGhpcyBpcyBzcGVjaWZ5aW5nIGEgZmFpbHVyZSB0byBjb25mb3JtLgoKSSB3 b3VsZCBnbyBmYXIgYXMgdG8gc2F5IHRoYXQgc3VjaCBhbiBhZ2VudCBpcyBub3QgYW4gSTJSUyBh Z2VudCwgYnV0IHRoYXQgaXMgYSBzdGVwIGJleW9uZCB0aGUgTmV0Q29uZiBjb21wbGlhbmNlIGRl ZmluaXRpb25zLgoKWW91cnMsCkpvZWwKCk9uIDUvOS8xNiA2OjA5IFBNLCBTdXNhbiBIYXJlcyB3 cm90ZToKPiBBbmR5IGFuZCBKb2VsOgo+Cj4gVGhlc2UgYXJlIGdvb2QgcG9pbnRzLgo+Cj4gV2hh dCBoYXBwZW5zIGlmIHRoZSBkYXRhIG1vZGVsIGhhcyBzb21lIGVwaGVtZXJhbCBzZWN0aW9ucyBh bmQgdGhlIAo+IEkyUlMgYWdlbnQgaXMgbm90IHN1cHBvcnRlZCBieSB0aGUgcm91dGluZyBzeXN0 ZW0uwqAgVGhlIGRhdGEgbW9kZWwgCj4gd291bGQgc3BlY2lmeSB0aGUgZXBoZW1lcmFsIHNlY3Rp b24sIGJ1dCB0aGVyZSB3b3VsZCBiZSBubyBzdXBwb3J0IGJ5IGkycnMuCj7CoCBJcyB0aGUgc3Vw cG9ydCBvZiB0aGUgZXBoZW1lcmFsIG5vdCBhIHZhcmlhYmxlwqAgY29uZGl0aW9uIHRvIGJlIAo+ IGluZGljYXRlZCBpbiBZYW5nIG1vZHVsZSBsaWJyYXJ5Pwo+Cj4gU3VlCj4gU2VudCB2aWEgdGhl IFNhbXN1bmcgR2FsYXh5IE5vdGU1LCBhbiBBVCZUIDRHIExURSBzbWFydHBob25lCj4gLS0tLS0t LS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLQo+IEZyb206IEFuZHkgQmllcm1hbiA8YW5keUB5 dW1hd29ya3MuY29tPgo+IERhdGU6IDUvNy8yMDE2IDEyOjUzIFBNIChHTVQtMDU6MDApCj4gVG86 ICJKb2VsIE0uIEhhbHBlcm4iIDxqbWhAam9lbGhhbHBlcm4uY29tPgo+IENjOiBpMnJzQGlldGYu b3JnLCBOZXRjb25mIDxuZXRjb25mQGlldGYub3JnPiwgU3VzYW4gSGFyZXMgCj4gPHNoYXJlc0Bu ZHpoLmNvbT4KPiBTdWJqZWN0OiBSZTogW2kycnNdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIAo+IGRyYWZ0LWhhcmVzLWkycnMtcHJvdG9jb2wtc3RyYXdtYW4tMDIudHh0IC0gMy4x LjEKPgo+Cj4KPiBPbiBGcmksIE1heSA2LCAyMDE2IGF0IDg6NTEgQU0sIEpvZWwgTS4gSGFscGVy biA8am1oQGpvZWxoYWxwZXJuLmNvbSAKPiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+PiB3 cm90ZToKPgo+wqDCoMKgwqAgUmVhZGluZyB0aGUgbGF0ZXN0IHJldmlzaW9uLCBpbiBzZWN0aW9u IDMuMS4xLCB0aGUgdGV4dCBpbiBidWxsZXQgNQo+wqDCoMKgwqAgc2F5cyB0aGF0IHRoZSBkYXRh IG1vZGVsIGluZGljYXRlcyB3aGljaCBwb3J0aW9ucyBhcmUgZXBoZW1lcmFsLgo+wqDCoMKgwqAg VGhhdCBtYWtlcyBzZW5zZSB0byBtZS4KPgo+wqDCoMKgwqAgVGhlbiBidWxsZXQgNiBzYXlzIHRo YXQgdGhlIG1hbmFnZW1lbnQgcHJvdG9jb2wgbmVlZHMgdG8gc2lnbmFsIChpbgo+wqDCoMKgwqAg aXRzIHlhbmcgbGlicmFyeSkgd2hpY2ggcGFydHMgYXJlIGVwaGVtZXJhbC4KPgo+wqDCoMKgwqAg V2h5IHRoZSBzZWNvbmQgcmVxdWlyZW1lbnQ/wqAgSWYgdGhlIGRhdGEgbW9kZWwgaXMgc3VwcG9y dGVkLCBhbmQgdGhlCj7CoMKgwqDCoCBkYXRhIG1vZGVsIHN0YXRlcyB0aGF0IGNlcnRhaW4gaXRl bXMgYXJlIGVwaGVtZXJhbCwgd2hhdCB3b3VsZCBpdAo+wqDCoMKgwqAgbWVhbiBpZiB0aGUgc2ln bmFsaW5nIGRpZCBub3QgYWxzbyBzYXkgdGhhdC7CoCBDb252ZXJzZWx5LCB3aGF0IHdvdWxkCj7C oMKgwqDCoCBpdCBtZWFuIGlmIHRoZSBzaWduYWxpbmcgc2FpZCBzb21ldGhpbmcgd2FzIGVwaGVt ZXJhbCB0aGF0IHRoZSBtb2RlbAo+wqDCoMKgwqAgZG9lcyBub3QgZGVmaW5lIGFzIGVwaGVtZXJh bD8KPgo+wqDCoMKgwqAgSXQgbWF5IGJlIHRoYXQgSSBhbSBtaXNyZWFkaW5nIGJ1bGxldCA2LsKg IFBsZWFzZSBleHBsYWluLgo+Cj4KPgo+IEkgdGhpbmsgeW91IGFyZSBjb3JyZWN0IHRoYXQgdGhl IFlBTkcgbGlicmFyeSBkb2VzIG5vdCBuZWVkIGFueSAKPiBjaGFuZ2VzIHRvIGlkZW50aWZ5IGVw aGVtZXJhbCBkYXRhLsKgIE9ubHkgdGhlIHZhcmlhYmxlIGNvbXBvbmVudHMgb2YgCj4gWUFORyBj b25mb3JtYW5jZSBhcmUgY29udGFpbmVkIGluIHRoZSBsaWJyYXJ5Lgo+Cj4KPsKgwqDCoMKgIFRo YW5rIHlvdSwKPsKgwqDCoMKgIEpvZWwKPgo+Cj4KPiBBbmR5Cj4KPgo+wqDCoMKgwqAgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPsKgwqDCoMKgIGkycnMg bWFpbGluZyBsaXN0Cj7CoMKgwqDCoCBpMnJzQGlldGYub3JnIDxtYWlsdG86aTJyc0BpZXRmLm9y Zz4KPsKgwqDCoMKgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJycwo+ Cj4KCg== ----_com.samsung.android.email_934795023916920 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2PklmIHRoZSBJMlJTIGFyZW4n dCBpcyBvZmYgdGhlbiB0aGUgc3lzdGVtIGRvZXMgbm90IGN1cnJlbnRseSBzdXBwb3J0IHRoaXMg bW9kZWxzLiAmbmJzcDtUaGlzIGlzIGp1c3QgbGlrZSBhbnkgb3RoZXIgb3B0aW9uYWwgWUFORyBt b2R1bGUuICZuYnNwO0lmIHlvdSBhcmUgbm90IGN1cnJlbnRseSBwcmVwYXJlZCB0byB1c2UgaXQs IHlvdSBkb24ndCBjbGFpbSB0byBzdXBwb3J0IGl0LjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+ Q2F2ZWF0OiBUaGUgTmV0TW9kIGZvbGtzIG1heSBoYXZlIGNvbWUgdXAgd2l0aCBhIG1vcmUgbnVh bmNlZCBtZWNoYW5pc20uICZuYnNwOzwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+WW91cnMsPC9k aXY+PGRpdj5Kb2VsPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+ PC9kaXY+PGRpdiBpZD0iY29tcG9zZXJfc2lnbmF0dXJlIj48ZGl2IHN0eWxlPSJmb250LXNpemU6 ODUlO2NvbG9yOiM1NzU3NTciPlNlbnQgdmlhIHRoZSBTYW1zdW5nIEdhbGF4eSBTwq4gNiwgYW4g QVQmYW1wO1QgNEcgTFRFIHNtYXJ0cGhvbmU8L2Rpdj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LXNp emU6MTAwJTtjb2xvcjojMDAwMDAwIj48IS0tIG9yaWdpbmFsTWVzc2FnZSAtLT48ZGl2Pi0tLS0t LS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS08L2Rpdj48ZGl2PkZyb206IFN1c2FuIEhhcmVz ICZsdDtzaGFyZXNAbmR6aC5jb20mZ3Q7IDwvZGl2PjxkaXY+RGF0ZTogNS8xMC8yMDE2ICAxOjI1 IFBNICAoR01UKzAxOjAwKSA8L2Rpdj48ZGl2PlRvOiAiJ0pvZWwgTS4gSGFscGVybiciICZsdDtq bWhAam9lbGhhbHBlcm4uY29tJmd0OywgJ0FuZHkgQmllcm1hbicgJmx0O2FuZHlAeXVtYXdvcmtz LmNvbSZndDsgPC9kaXY+PGRpdj5DYzogaTJyc0BpZXRmLm9yZywgJ05ldGNvbmYnICZsdDtuZXRj b25mQGlldGYub3JnJmd0OyA8L2Rpdj48ZGl2PlN1YmplY3Q6IFJFOiBbaTJyc10gRlc6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaGFyZXMtaTJycy1wcm90b2NvbC1zdHJhd21h bi0wMi50eHQgLSAzLjEuMSA8L2Rpdj48ZGl2Pjxicj48L2Rpdj48L2Rpdj5Kb2VsOiA8YnI+PGJy PldoYXQgaGFwcGVucyBpZiB0aGUgY29kZSBzdXBwb3J0cyB0aGUgSTJSUyBhZ2VudCwgYnV0IHRo ZSBJMlJTIGFnZW50IGlzIGNvbmZpZ3VyZWQgdG8gYmUgIm9mZiI/Jm5ic3A7IElzIHRoaXMgY292 ZXJlZCBieSB0aGUgZGV2aWF0aW9ucyBvciBpcyB0aGlzIHZhcmlhYmxlIGNvbmZpZ3VyYXRpb24/ IDxicj48YnI+U3VlIDxicj48YnI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+RnJvbTog Sm9lbCBNLiBIYWxwZXJuIFttYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbV0gPGJyPlNlbnQ6IFR1 ZXNkYXksIE1heSAxMCwgMjAxNiAxOjM0IEFNPGJyPlRvOiBTdXNhbiBIYXJlczsgQW5keSBCaWVy bWFuPGJyPkNjOiBpMnJzQGlldGYub3JnOyBOZXRjb25mPGJyPlN1YmplY3Q6IFJlOiBbaTJyc10g Rlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaGFyZXMtaTJycy1wcm90b2Nv bC1zdHJhd21hbi0wMi50eHQgLSAzLjEuMTxicj48YnI+QXMgSSB1bmRlcnN0YW5kIGl0LCBpZiBh IG1vZGVsIHJlcXVpcmVzIGVwaGVtZXJhbCBlbGVtZW50cywgYW5kIHRoZSBhZ2VudCBkb2VzIG5v dCBzdXBwb3J0IGVwaGVtZXJhbCwgdGhlbiB0aGUgYWdlbnQgY2FuIG5vdCBjbGFpbSB0byBzdXBw b3J0IHRoZSBtb2RlbC48YnI+PGJyPlllcywgZGV2aWF0aW9ucyBhbGxvdyB5b3UgdG8gc3BlY2lm eSB0aGlzLCBhcyBBbmR5IHNheXMuJm5ic3A7IEJ1dCB0aGlzIGlzIHNwZWNpZnlpbmcgYSBmYWls dXJlIHRvIGNvbmZvcm0uPGJyPjxicj5JIHdvdWxkIGdvIGZhciBhcyB0byBzYXkgdGhhdCBzdWNo IGFuIGFnZW50IGlzIG5vdCBhbiBJMlJTIGFnZW50LCBidXQgdGhhdCBpcyBhIHN0ZXAgYmV5b25k IHRoZSBOZXRDb25mIGNvbXBsaWFuY2UgZGVmaW5pdGlvbnMuPGJyPjxicj5Zb3Vycyw8YnI+Sm9l bDxicj48YnI+T24gNS85LzE2IDY6MDkgUE0sIFN1c2FuIEhhcmVzIHdyb3RlOjxicj4mZ3Q7IEFu ZHkgYW5kIEpvZWw6PGJyPiZndDs8YnI+Jmd0OyBUaGVzZSBhcmUgZ29vZCBwb2ludHMuPGJyPiZn dDs8YnI+Jmd0OyBXaGF0IGhhcHBlbnMgaWYgdGhlIGRhdGEgbW9kZWwgaGFzIHNvbWUgZXBoZW1l cmFsIHNlY3Rpb25zIGFuZCB0aGUgPGJyPiZndDsgSTJSUyBhZ2VudCBpcyBub3Qgc3VwcG9ydGVk IGJ5IHRoZSByb3V0aW5nIHN5c3RlbS4mbmJzcDsgVGhlIGRhdGEgbW9kZWwgPGJyPiZndDsgd291 bGQgc3BlY2lmeSB0aGUgZXBoZW1lcmFsIHNlY3Rpb24sIGJ1dCB0aGVyZSB3b3VsZCBiZSBubyBz dXBwb3J0IGJ5IGkycnMuPGJyPiZndDsmbmJzcDsgSXMgdGhlIHN1cHBvcnQgb2YgdGhlIGVwaGVt ZXJhbCBub3QgYSB2YXJpYWJsZSZuYnNwOyBjb25kaXRpb24gdG8gYmUgPGJyPiZndDsgaW5kaWNh dGVkIGluIFlhbmcgbW9kdWxlIGxpYnJhcnk/PGJyPiZndDs8YnI+Jmd0OyBTdWU8YnI+Jmd0OyBT ZW50IHZpYSB0aGUgU2Ftc3VuZyBHYWxheHkgTm90ZTUsIGFuIEFUJmFtcDtUIDRHIExURSBzbWFy dHBob25lPGJyPiZndDsgLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLTxicj4mZ3Q7 IEZyb206IEFuZHkgQmllcm1hbiAmbHQ7YW5keUB5dW1hd29ya3MuY29tJmd0Ozxicj4mZ3Q7IERh dGU6IDUvNy8yMDE2IDEyOjUzIFBNIChHTVQtMDU6MDApPGJyPiZndDsgVG86ICJKb2VsIE0uIEhh bHBlcm4iICZsdDtqbWhAam9lbGhhbHBlcm4uY29tJmd0Ozxicj4mZ3Q7IENjOiBpMnJzQGlldGYu b3JnLCBOZXRjb25mICZsdDtuZXRjb25mQGlldGYub3JnJmd0OywgU3VzYW4gSGFyZXMgPGJyPiZn dDsgJmx0O3NoYXJlc0BuZHpoLmNvbSZndDs8YnI+Jmd0OyBTdWJqZWN0OiBSZTogW2kycnNdIEZX OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIDxicj4mZ3Q7IGRyYWZ0LWhhcmVzLWkycnMt cHJvdG9jb2wtc3RyYXdtYW4tMDIudHh0IC0gMy4xLjE8YnI+Jmd0Ozxicj4mZ3Q7PGJyPiZndDs8 YnI+Jmd0OyBPbiBGcmksIE1heSA2LCAyMDE2IGF0IDg6NTEgQU0sIEpvZWwgTS4gSGFscGVybiAm bHQ7am1oQGpvZWxoYWxwZXJuLmNvbSA8YnI+Jmd0OyAmbHQ7bWFpbHRvOmptaEBqb2VsaGFscGVy bi5jb20mZ3Q7Jmd0OyB3cm90ZTo8YnI+Jmd0Ozxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IFJlYWRpbmcgdGhlIGxhdGVzdCByZXZpc2lvbiwgaW4gc2VjdGlvbiAzLjEuMSwgdGhlIHRl eHQgaW4gYnVsbGV0IDU8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzYXlzIHRoYXQg dGhlIGRhdGEgbW9kZWwgaW5kaWNhdGVzIHdoaWNoIHBvcnRpb25zIGFyZSBlcGhlbWVyYWwuPGJy PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhhdCBtYWtlcyBzZW5zZSB0byBtZS48YnI+ Jmd0Ozxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZW4gYnVsbGV0IDYgc2F5cyB0 aGF0IHRoZSBtYW5hZ2VtZW50IHByb3RvY29sIG5lZWRzIHRvIHNpZ25hbCAoaW48YnI+Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpdHMgeWFuZyBsaWJyYXJ5KSB3aGljaCBwYXJ0cyBhcmUg ZXBoZW1lcmFsLjxicj4mZ3Q7PGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgV2h5IHRo ZSBzZWNvbmQgcmVxdWlyZW1lbnQ/Jm5ic3A7IElmIHRoZSBkYXRhIG1vZGVsIGlzIHN1cHBvcnRl ZCwgYW5kIHRoZTxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRhdGEgbW9kZWwgc3Rh dGVzIHRoYXQgY2VydGFpbiBpdGVtcyBhcmUgZXBoZW1lcmFsLCB3aGF0IHdvdWxkIGl0PGJyPiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbWVhbiBpZiB0aGUgc2lnbmFsaW5nIGRpZCBub3Qg YWxzbyBzYXkgdGhhdC4mbmJzcDsgQ29udmVyc2VseSwgd2hhdCB3b3VsZDxicj4mZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGl0IG1lYW4gaWYgdGhlIHNpZ25hbGluZyBzYWlkIHNvbWV0aGlu ZyB3YXMgZXBoZW1lcmFsIHRoYXQgdGhlIG1vZGVsPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgZG9lcyBub3QgZGVmaW5lIGFzIGVwaGVtZXJhbD88YnI+Jmd0Ozxicj4mZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IEl0IG1heSBiZSB0aGF0IEkgYW0gbWlzcmVhZGluZyBidWxsZXQg Ni4mbmJzcDsgUGxlYXNlIGV4cGxhaW4uPGJyPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7PGJyPiZndDsg SSB0aGluayB5b3UgYXJlIGNvcnJlY3QgdGhhdCB0aGUgWUFORyBsaWJyYXJ5IGRvZXMgbm90IG5l ZWQgYW55IDxicj4mZ3Q7IGNoYW5nZXMgdG8gaWRlbnRpZnkgZXBoZW1lcmFsIGRhdGEuJm5ic3A7 IE9ubHkgdGhlIHZhcmlhYmxlIGNvbXBvbmVudHMgb2YgPGJyPiZndDsgWUFORyBjb25mb3JtYW5j ZSBhcmUgY29udGFpbmVkIGluIHRoZSBsaWJyYXJ5Ljxicj4mZ3Q7PGJyPiZndDs8YnI+Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGFuayB5b3UsPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgSm9lbDxicj4mZ3Q7PGJyPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7IEFuZHk8YnI+Jmd0 Ozxicj4mZ3Q7PGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBpMnJzIG1haWxpbmcgbGlzdDxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGkycnNAaWV0Zi5vcmcgJmx0O21haWx0bzppMnJzQGlldGYub3JnJmd0Ozxicj4mZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aTJyczxicj4mZ3Q7PGJyPiZndDs8YnI+PGJyPjwvYm9keT48L2h0bWw+ ----_com.samsung.android.email_934795023916920-- From nobody Tue May 10 07:54:44 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A87012D1B7; Tue, 10 May 2016 07:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.739 X-Spam-Level: * X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ay661oZVxXEU; Tue, 10 May 2016 07:54:41 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A58EB12D0E3; Tue, 10 May 2016 07:54:39 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.91.193.41; From: "Susan Hares" To: "'jmh.direct'" , "'Joel M. Halpern'" , "'Andy Bierman'" References: <7eqdbrhnm368w3aqvlarweoi.1462882301561@email.android.com> In-Reply-To: <7eqdbrhnm368w3aqvlarweoi.1462882301561@email.android.com> Date: Tue, 10 May 2016 10:54:28 -0400 Message-ID: <010901d1aacb$ddabec90$9903c5b0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_010A_01D1AAAA.569BD330" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJK5cF+B3c7cj/h/Gl6Cpq2sTtrkJ6/y26w Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, 'Netconf' Subject: Re: [Netconf] [i2rs] FW: New Version Notification for draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 14:54:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_010A_01D1AAAA.569BD330 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Joel:=20 =20 See below. Just trying to wrap up the discussion. =20 From: jmh.direct [mailto:jmh.direct@joelhalpern.com]=20 Sent: Tuesday, May 10, 2016 8:12 AM To: Susan Hares; 'Joel M. Halpern'; 'Andy Bierman' Cc: i2rs@ietf.org; 'Netconf' Subject: RE: [i2rs] FW: New Version Notification for = draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1 =20 If the I2RS aren't is off then the system does not currently support = this models. This is just like any other optional YANG module. If you = are not currently prepared to use it, you don't claim to support it. =20 Sue: I assume you desired to say=E2=80=A6 if the I2RS is not on, then = the system does not support this model. =20 =20 Caveat: The NetMod folks may have come up with a more nuanced mechanism. = =20 =20 Sue: Do we need them to come up with mechanism that indicates I2RS is = there but off?=20 =20 Yours, Joel =20 =20 =20 Sent via the Samsung Galaxy S=C2=AE 6, an AT&T 4G LTE smartphone -------- Original message -------- From: Susan Hares =20 Date: 5/10/2016 1:25 PM (GMT+01:00)=20 To: "'Joel M. Halpern'" , 'Andy Bierman' = =20 Cc: i2rs@ietf.org, 'Netconf' =20 Subject: RE: [i2rs] FW: New Version Notification for = draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1=20 =20 Joel:=20 What happens if the code supports the I2RS agent, but the I2RS agent is = configured to be "off"? Is this covered by the deviations or is this = variable configuration?=20 Sue=20 -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Sent: Tuesday, May 10, 2016 1:34 AM To: Susan Hares; Andy Bierman Cc: i2rs@ietf.org; Netconf Subject: Re: [i2rs] FW: New Version Notification for = draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1 As I understand it, if a model requires ephemeral elements, and the = agent does not support ephemeral, then the agent can not claim to = support the model. Yes, deviations allow you to specify this, as Andy says. But this is = specifying a failure to conform. I would go far as to say that such an agent is not an I2RS agent, but = that is a step beyond the NetConf compliance definitions. Yours, Joel On 5/9/16 6:09 PM, Susan Hares wrote: > Andy and Joel: > > These are good points. > > What happens if the data model has some ephemeral sections and the=20 > I2RS agent is not supported by the routing system. The data model=20 > would specify the ephemeral section, but there would be no support by = i2rs. > Is the support of the ephemeral not a variable condition to be=20 > indicated in Yang module library? > > Sue > Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartphone > -------- Original message -------- > From: Andy Bierman > Date: 5/7/2016 12:53 PM (GMT-05:00) > To: "Joel M. Halpern" > Cc: i2rs@ietf.org, Netconf , Susan Hares=20 > > Subject: Re: [i2rs] FW: New Version Notification for=20 > draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1 > > > > On Fri, May 6, 2016 at 8:51 AM, Joel M. Halpern =20 > > wrote: > > Reading the latest revision, in section 3.1.1, the text in bullet = 5 > says that the data model indicates which portions are ephemeral. > That makes sense to me. > > Then bullet 6 says that the management protocol needs to signal = (in > its yang library) which parts are ephemeral. > > Why the second requirement? If the data model is supported, and = the > data model states that certain items are ephemeral, what would it > mean if the signaling did not also say that. Conversely, what = would > it mean if the signaling said something was ephemeral that the = model > does not define as ephemeral? > > It may be that I am misreading bullet 6. Please explain. > > > > I think you are correct that the YANG library does not need any=20 > changes to identify ephemeral data. Only the variable components of=20 > YANG conformance are contained in the library. > > > Thank you, > Joel > > > > Andy > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > ------=_NextPart_000_010A_01D1AAAA.569BD330 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Joel:

 

See below.=C2=A0=C2=A0 Just trying to wrap up the = discussion.

 

From:= = jmh.direct [mailto:jmh.direct@joelhalpern.com]
Sent: Tuesday, = May 10, 2016 8:12 AM
To: Susan Hares; 'Joel M. Halpern'; 'Andy = Bierman'
Cc: i2rs@ietf.org; 'Netconf'
Subject: RE: = [i2rs] FW: New Version Notification for = draft-hares-i2rs-protocol-strawman-02.txt - = 3.1.1

 

If the = I2RS aren't is off then the system does not currently support this = models.  This is just like any other optional YANG module.  If = you are not currently prepared to use it, you don't claim to support = it.

 

Sue: I assume you desired to say=E2=80=A6 =C2=A0if the I2RS is not = on, then the system does not support this model.=C2=A0 =

 

Caveat: = The NetMod folks may have come up with a more nuanced mechanism. =  

 

Sue: Do we need them to come up with mechanism that indicates I2RS is = there but off?

 

Yours,

Joel

 

 

 

Sent via the Samsung Galaxy = S=C2=AE 6, an AT&T 4G LTE = smartphone

-------- Original message = --------

From: Susan Hares <shares@ndzh.com> =

Date: 5/10/2016 1:25 PM (GMT+01:00) =

To: "'Joel M. Halpern'" <jmh@joelhalpern.com>, 'Andy = Bierman' <andy@yumaworks.com> =

Cc: i2rs@ietf.org, 'Netconf' <netconf@ietf.org> =

Subject: RE: [i2rs] FW: New Version Notification = for draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1 =

 

Joel:

What = happens if the code supports the I2RS agent, but the I2RS agent is = configured to be "off"?  Is this covered by the = deviations or is this variable configuration?

Sue =

-----Original Message-----
From: Joel M. Halpern [mailto:jmh@joelhalpern.com] =
Sent: Tuesday, May 10, 2016 1:34 AM
To: Susan Hares; Andy = Bierman
Cc: i2rs@ietf.org; = Netconf
Subject: Re: [i2rs] FW: New Version Notification for = draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1

As I understand = it, if a model requires ephemeral elements, and the agent does not = support ephemeral, then the agent can not claim to support the = model.

Yes, deviations allow you to specify this, as Andy = says.  But this is specifying a failure to conform.

I would = go far as to say that such an agent is not an I2RS agent, but that is a = step beyond the NetConf compliance = definitions.

Yours,
Joel

On 5/9/16 6:09 PM, Susan Hares = wrote:
> Andy and Joel:
>
> These are good = points.
>
> What happens if the data model has some = ephemeral sections and the
> I2RS agent is not supported by the = routing system.  The data model
> would specify the = ephemeral section, but there would be no support by i2rs.
>  = Is the support of the ephemeral not a variable  condition to be =
> indicated in Yang module library?
>
> Sue
> = Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartphone
> = -------- Original message --------
> From: Andy Bierman <andy@yumaworks.com>
> = Date: 5/7/2016 12:53 PM (GMT-05:00)
> To: "Joel M. = Halpern" <jmh@joelhalpern.com>
> = Cc: i2rs@ietf.org, Netconf <netconf@ietf.org>, Susan Hares =
> <shares@ndzh.com>
> Subject: = Re: [i2rs] FW: New Version Notification for
> = draft-hares-i2rs-protocol-strawman-02.txt - = 3.1.1
>
>
>
> On Fri, May 6, 2016 at 8:51 AM, = Joel M. Halpern <jmh@joelhalpern.com =
> <mailto:jmh@joelhalpern.com>>= ; wrote:
>
>     Reading the latest = revision, in section 3.1.1, the text in bullet = 5
>     says that the data model indicates = which portions are ephemeral.
>     That makes = sense to me.
>
>     Then bullet 6 says = that the management protocol needs to signal = (in
>     its yang library) which parts are = ephemeral.
>
>     Why the second = requirement?  If the data model is supported, and = the
>     data model states that certain items = are ephemeral, what would it
>     mean if the = signaling did not also say that.  Conversely, what = would
>     it mean if the signaling said = something was ephemeral that the model
>     = does not define as ephemeral?
>
>     It = may be that I am misreading bullet 6.  Please = explain.
>
>
>
> I think you are correct that = the YANG library does not need any
> changes to identify = ephemeral data.  Only the variable components of
> YANG = conformance are contained in the = library.
>
>
>     Thank = you,
>     = Joel
>
>
>
> = Andy
>
>
>     = _______________________________________________
>   =   i2rs mailing list
>     i2rs@ietf.org <mailto:i2rs@ietf.org>
> &= nbsp;   https://www.ietf.org/= mailman/listinfo/i2rs
>
>

------=_NextPart_000_010A_01D1AAAA.569BD330-- From nobody Tue May 10 08:11:08 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0375412D1C2; Tue, 10 May 2016 08:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pm6JuMf0IKpz; Tue, 10 May 2016 08:10:59 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 A6D4312D1B7; Tue, 10 May 2016 08:10:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 893A31C0ADE; Tue, 10 May 2016 08:10:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1462893059; bh=ezCJLbyAj5IWw44TMffc8bjdpV+TWSPrRNn+KKGWeoE=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=ZQfmeHnBtECYICBDGbFIG9vCiCsvreePVufZlDLCDgXF74+Sy4YDz/Igp7sERJpWL 4+uDOOUv/qSVYapcRPpbi6gVk1RybOLAEe0vV6ah6dvzsl2uvhL/VDWsTb3V3bJDCl 77HVB8RgKUXxyb6bcBSRLHDVPOswUWhFHUTUZ5Hw= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (sessfw99-sesbfw99-81.ericsson.net [192.176.1.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 3C3C31C069E; Tue, 10 May 2016 08:10:58 -0700 (PDT) To: Susan Hares , 'Andy Bierman' References: <7eqdbrhnm368w3aqvlarweoi.1462882301561@email.android.com> <010901d1aacb$ddabec90$9903c5b0$@ndzh.com> From: "Joel M. Halpern" Message-ID: <5b422567-7120-16c8-7a7d-2ee5227165c1@joelhalpern.com> Date: Tue, 10 May 2016 11:10:55 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <010901d1aacb$ddabec90$9903c5b0$@ndzh.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: i2rs@ietf.org, 'Netconf' Subject: Re: [Netconf] [i2rs] FW: New Version Notification for draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 15:11:02 -0000 Yes, you interpreted my awful typing correctly. I don't see any need for anything more, but was allowing that I am not fully current on the groups thinking. Yours, Joel On 5/10/16 10:54 AM, Susan Hares wrote: > Joel: > > > > See below. Just trying to wrap up the discussion. > > > > *From:*jmh.direct [mailto:jmh.direct@joelhalpern.com] > *Sent:* Tuesday, May 10, 2016 8:12 AM > *To:* Susan Hares; 'Joel M. Halpern'; 'Andy Bierman' > *Cc:* i2rs@ietf.org; 'Netconf' > *Subject:* RE: [i2rs] FW: New Version Notification for > draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1 > > > > If the I2RS aren't is off then the system does not currently support > this models. This is just like any other optional YANG module. If you > are not currently prepared to use it, you don't claim to support it. > > > > Sue: I assume you desired to say… if the I2RS is not on, then the > system does not support this model. > > > > Caveat: The NetMod folks may have come up with a more nuanced mechanism. > > > > Sue: Do we need them to come up with mechanism that indicates I2RS is > there but off? > > > > Yours, > > Joel > > > > > > > > Sent via the Samsung Galaxy S® 6, an AT&T 4G LTE smartphone > > -------- Original message -------- > > From: Susan Hares > > > Date: 5/10/2016 1:25 PM (GMT+01:00) > > To: "'Joel M. Halpern'" >, 'Andy Bierman' > > > Cc: i2rs@ietf.org , 'Netconf' > > > Subject: RE: [i2rs] FW: New Version Notification for > draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1 > > > > Joel: > > What happens if the code supports the I2RS agent, but the I2RS agent is > configured to be "off"? Is this covered by the deviations or is this > variable configuration? > > Sue > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Tuesday, May 10, 2016 1:34 AM > To: Susan Hares; Andy Bierman > Cc: i2rs@ietf.org ; Netconf > Subject: Re: [i2rs] FW: New Version Notification for > draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1 > > As I understand it, if a model requires ephemeral elements, and the > agent does not support ephemeral, then the agent can not claim to > support the model. > > Yes, deviations allow you to specify this, as Andy says. But this is > specifying a failure to conform. > > I would go far as to say that such an agent is not an I2RS agent, but > that is a step beyond the NetConf compliance definitions. > > Yours, > Joel > > On 5/9/16 6:09 PM, Susan Hares wrote: >> Andy and Joel: >> >> These are good points. >> >> What happens if the data model has some ephemeral sections and the >> I2RS agent is not supported by the routing system. The data model >> would specify the ephemeral section, but there would be no support by > i2rs. >> Is the support of the ephemeral not a variable condition to be >> indicated in Yang module library? >> >> Sue >> Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartphone >> -------- Original message -------- >> From: Andy Bierman > >> Date: 5/7/2016 12:53 PM (GMT-05:00) >> To: "Joel M. Halpern" > >> Cc: i2rs@ietf.org , Netconf >, Susan Hares >> > >> Subject: Re: [i2rs] FW: New Version Notification for >> draft-hares-i2rs-protocol-strawman-02.txt - 3.1.1 >> >> >> >> On Fri, May 6, 2016 at 8:51 AM, Joel M. Halpern > > wrote: >> >> Reading the latest revision, in section 3.1.1, the text in bullet 5 >> says that the data model indicates which portions are ephemeral. >> That makes sense to me. >> >> Then bullet 6 says that the management protocol needs to signal (in >> its yang library) which parts are ephemeral. >> >> Why the second requirement? If the data model is supported, and the >> data model states that certain items are ephemeral, what would it >> mean if the signaling did not also say that. Conversely, what would >> it mean if the signaling said something was ephemeral that the model >> does not define as ephemeral? >> >> It may be that I am misreading bullet 6. Please explain. >> >> >> >> I think you are correct that the YANG library does not need any >> changes to identify ephemeral data. Only the variable components of >> YANG conformance are contained in the library. >> >> >> Thank you, >> Joel >> >> >> >> Andy >> >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> >> > From nobody Wed May 11 12:19:42 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1295A12D7A7 for ; Wed, 11 May 2016 12:19: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6LRoyaO8Lg4h for ; Wed, 11 May 2016 12:19:39 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0119.outbound.protection.outlook.com [207.46.100.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 959D712D79E for ; Wed, 11 May 2016 12:19:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=VHRLJq01FBr8szs6YteZkWtrRAH/l6sqC6PZhlHfdFY=; b=GmHTifzYU9YRusVt2DHtNi0aQrU3pV1AtBK6OamNNSEyg2/UUvT8NTFjuKGYzKNNhi74rX7T27eiT7jYl9NxYLBVUenhDDFOYlmygK1Lx807gTO284FqX2MlKi+aJu9w8EU13tVzAwF4oYkoQMuuQZCxJKWAep6Vl/0hSnw/frc= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1441.namprd05.prod.outlook.com (10.160.117.150) with Microsoft SMTP Server (TLS) id 15.1.497.12; Wed, 11 May 2016 19:19:21 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0492.016; Wed, 11 May 2016 19:19:21 +0000 From: Kent Watsen To: Sean Turner Thread-Topic: netconf server-model (keychain) draft issues Thread-Index: AQHRq7oF1V9bdqG6E0qiTQDwkdd7Lg== Date: Wed, 11 May 2016 19:19:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.15.1.160411 authentication-results: ieca.com; dkim=none (message not signed) header.d=none;ieca.com; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.10] x-ms-office365-filtering-correlation-id: 7d37ea77-3b9a-4c3c-b953-08d379d127f5 x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1441; 5:airr9k0BwvioWBYHzetXz6tHJ898HE6HzIr9hBqOdz7ccdj6M6gdfMwk6AcYj06aH2hzz8TrCG9BB2NZlzH+gA1MxMGcCjJv+w/c/IYWTTBeVQlDGXusmhqQz6zTQzEyvBD0DTfnCdrsoB7ZDlJaUQ==; 24:yy6HP0LhKGcJw2AtH5ylVb9eIE3pD1WlOmpwpdNMimHf7bVmsNrYoZbcqEa340COYgZKY9uyudXor9XGARspC4K0PjKBvL2v3akhTmrQzpE=; 7:1ULgVETHMeKnaXXV69ooT/TCcZzBWBCQBoH9uoffVXM5xKR0grYcroITbMNAbJLkKvB/xxZ/TWJtKn2Hc7hKUtX2LEC63lrWnEb6hUusOwakMHleECB7xc+oUtFP/vk2TmcIhQjtKzarwGWYTbqv1F6BrtbzFoJUKUzLj330L/NmvZyBoHphLXS+fLZI6qde x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1441; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:BN3PR0501MB1441; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1441; x-forefront-prvs: 0939529DE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(110136002)(3660700001)(4326007)(6116002)(16236675004)(5004730100002)(229853001)(83716003)(3280700002)(1220700001)(83506001)(586003)(4001350100001)(10400500002)(66066001)(3846002)(102836003)(2906002)(5002640100001)(189998001)(33656002)(92566002)(2900100001)(54356999)(50986999)(81166006)(86362001)(87936001)(36756003)(106116001)(19617315012)(77096005)(15975445007)(19580395003)(5008740100001)(122556002)(8936002)(11100500001)(82746002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1441; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DEBB7C29DD814E8EB55B081D02B817AEjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 11 May 2016 19:19:21.3819 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1441 Archived-At: Cc: "netconf@ietf.org" Subject: [Netconf] netconf server-model (keychain) draft issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 19:19:41 -0000 --_000_DEBB7C29DD814E8EB55B081D02B817AEjunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU2VhbiwNCg0KVGhhbmsgeW91IGFnYWluIGZvciB5b3VyIHJldmlldyBvZiB0aGUgc2VydmVy LW1vZGVsIGRyYWZ0IGJlZm9yZSwgcHJpbWFyaWx5IGZvY3VzaW5nIG9uIHRoZSBrZXljaGFpbiBt b2RlbC4gIEFzIHlvdSBrbm93LCBJIHVwZGF0ZWQgdGhlIGRyYWZ0IHNpZ25pZmljYW50bHkgYmFz ZWQgb24geW91ciBjb21tZW50cyBmb3IgOTUsIGJ1dCBvbmUgaXNzdWUgcmVtYWlucy4uLg0KDQpU aGUgcmVtYWluaW5nIGlzc3VlIHJlZ2FyZHMgJ2tleS11c2FnZScgaW4gdGhlIGdlbmVyYXRlLXBy aXZhdGUta2V5IGFjdGlvbiBsaXN0ZWQgb24gcGFnZSAyMyBvZiBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRjb25mLXNlcnZlci1tb2RlbC0wOS4gIEJlbG93IGlzIHRo ZSBjdXJyZW50IChpbmNvbXBsZXRlKSBkZWZpbml0aW9uOg0KDQogICAgICAgICAgbGVhZiBrZXkt dXNhZ2Ugew0KICAgICAgICAgICAgdHlwZSBlbnVtZXJhdGlvbiB7DQogICAgICAgICAgICAgIGVu dW0gc2lnbmluZyAgICB7IGRlc2NyaXB0aW9uICJzaWduaW5nIjsgfQ0KICAgICAgICAgICAgICBl bnVtIGVuY3J5cHRpb24geyBkZXNjcmlwdGlvbiAiZW5jcnlwdGlvbiI7IH0NCiAgICAgICAgICAg ICAgLy8gdW5jbGVhciBpZiB0aGVzZSBzaG91bGQgYmUgc29tZWhvdyBtb3JlDQogICAgICAgICAg ICAgIC8vIHNwZWNpZmljIG9yIHZhcmllZC4NCiAgICAgICAgICAgIH0NCg0KVGhlIHF1ZXN0aW9u IGlzIGhvdyB0byBtYWtlIHRoaXMga2V5LXVzYWdlIGRlZmluaXRpb24gY29tcGxldGU/ICBJIGNh biBkbyB0aGUgWUFORyB0cmFuc2xhdGlvbiwgYnV0IHdoYXQgYXJlIHRoZSBwb3NzaWJsZSB2YWx1 ZXM/ICBJcyBpdCB0aGUgY2FzZSB0aGF0IHRoZSBpc3N1ZSBvbmx5IG1hdHRlcnMgd2hlbiBkaXNj dXNzaW5nIFRQTXMsIHdoaWNoIGhhdmUgdmVyeSBkaXN0aW5jdCBhbmQgc3BlY2lmaWMgdXNhZ2Ug cHJvZmlsZXM/ICAgQXMgYSBnZW5lcmljIGtleWNoYWluIG1vZGVsLCBpdCBzaG91bGRuJ3QgYmUg c3BlY2lmaWMgdG8gbmV0d29yayBtYW5hZ2VtZW50LCBidXQgaXQgd291bGQgYmUgcmVtaXNzIGZv ciBtZSB0byBub3QgcG9pbnQgb3V0IHRoYXQsIGluIG5ldHdvcmsgbWFuYWdlbWVudCwgdGhlIHBy aXZhdGUga2V5IHNlZW1zIHRvIGFsd2F5cyBoYXZlIHRoZSBzYW1lIGtleSB1c2FnZSAoaS5lLiB3 aGF0J3MgbmVlZGVkIHRvIGVzdGFibGlzaCBhIFNTSC9UTFMgdHVubmVsKS4gICBUaG91Z2h0cz8N Cg0KVGhhbmtzLA0KS2VudA0KDQo= --_000_DEBB7C29DD814E8EB55B081D02B817AEjunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <483C9593A3ECD64E91F4071627A92371@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+SGkgU2Vhbiw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 PlRoYW5rIHlvdSBhZ2FpbiBmb3IgeW91ciByZXZpZXcgb2YgdGhlIHNlcnZlci1tb2RlbCBkcmFm dCBiZWZvcmUsIHByaW1hcmlseSBmb2N1c2luZyBvbiB0aGUga2V5Y2hhaW4gbW9kZWwuICZuYnNw O0FzIHlvdSBrbm93LCBJIHVwZGF0ZWQgdGhlIGRyYWZ0IHNpZ25pZmljYW50bHkgYmFzZWQgb24g eW91ciBjb21tZW50cyBmb3IgOTUsIGJ1dCBvbmUgaXNzdWUgcmVtYWlucy4uLiZuYnNwOzwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhlIHJlbWFpbmluZyBpc3N1ZSByZWdhcmRzICdr ZXktdXNhZ2UnIGluIHRoZSBnZW5lcmF0ZS1wcml2YXRlLWtleSBhY3Rpb24gbGlzdGVkIG9uIHBh Z2UgMjMgb2YmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1uZXRjb25mLXNlcnZlci1tb2RlbC0wOSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtbmV0Y29uZi1zZXJ2ZXItbW9kZWwtMDk8L2E+LiAmbmJzcDtCZWxvdyBpcyB0 aGUgY3VycmVudA0KIChpbmNvbXBsZXRlKSBkZWZpbml0aW9uOjwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgbGVh ZiBrZXktdXNhZ2UgezwvZGl2Pg0KPGRpdj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyB0eXBlIGVudW1lcmF0aW9uIHs8L2Rpdj4NCjxkaXY+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGVudW0gc2lnbmluZyAmbmJzcDsgJm5i c3A7eyBkZXNjcmlwdGlvbiAmcXVvdDtzaWduaW5nJnF1b3Q7OyB9PC9kaXY+DQo8ZGl2PiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBlbnVtIGVuY3J5cHRp b24geyBkZXNjcmlwdGlvbiAmcXVvdDtlbmNyeXB0aW9uJnF1b3Q7OyB9PC9kaXY+DQo8ZGl2PiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAvLyB1bmNsZWFy IGlmIHRoZXNlIHNob3VsZCBiZSBzb21laG93IG1vcmU8L2Rpdj4NCjxkaXY+Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC8vIHNwZWNpZmljIG9yIHZhcmll ZC48L2Rpdj4NCjxkaXY+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg fTwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoZSBxdWVz dGlvbiBpcyBob3cgdG8gbWFrZSB0aGlzIGtleS11c2FnZSBkZWZpbml0aW9uIGNvbXBsZXRlPyAm bmJzcDtJIGNhbiBkbyB0aGUgWUFORyB0cmFuc2xhdGlvbiwgYnV0IHdoYXQgYXJlIHRoZSBwb3Nz aWJsZSB2YWx1ZXM/ICZuYnNwO0lzIGl0IHRoZSBjYXNlIHRoYXQgdGhlIGlzc3VlIG9ubHkgbWF0 dGVycyB3aGVuIGRpc2N1c3NpbmcgVFBNcywgd2hpY2ggaGF2ZSB2ZXJ5IGRpc3RpbmN0IGFuZCBz cGVjaWZpYyB1c2FnZSBwcm9maWxlcz8gJm5ic3A7DQogQXMgYSBnZW5lcmljIGtleWNoYWluIG1v ZGVsLCBpdCBzaG91bGRuJ3QgYmUgc3BlY2lmaWMgdG8gbmV0d29yayBtYW5hZ2VtZW50LCBidXQg aXQgd291bGQgYmUgcmVtaXNzIGZvciBtZSB0byBub3QgcG9pbnQgb3V0IHRoYXQsIGluIG5ldHdv cmsgbWFuYWdlbWVudCwgdGhlIHByaXZhdGUga2V5IHNlZW1zIHRvIGFsd2F5cyBoYXZlIHRoZSBz YW1lIGtleSB1c2FnZSAoaS5lLiB3aGF0J3MgbmVlZGVkIHRvIGVzdGFibGlzaCBhIFNTSC9UTFMg dHVubmVsKS4NCiAmbmJzcDsgVGhvdWdodHM/PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp dj5UaGFua3MsPC9kaXY+DQo8ZGl2PktlbnQ8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2IGlkPSJNQUNfT1VUTE9PS19TSUdOQVRVUkUiPjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DEBB7C29DD814E8EB55B081D02B817AEjunipernet_-- From nobody Wed May 11 15:28:52 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E502412D607 for ; Wed, 11 May 2016 15:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEWiQ4drKC1h for ; Wed, 11 May 2016 15:28:50 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0125.outbound.protection.outlook.com [65.55.169.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D0F912B049 for ; Wed, 11 May 2016 15:28:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+1HhuIajV44dGgQW3Gbw6hv3k8mT9SMAe8WJBWWuFIs=; b=Pl+8fc+mOgg8sq8KxM1bC7uF9/4GhxnoxIHWC+CQ88o8/R9xBZHZNWvqpnLy4EawRIWlkveVXw+OCjCkF5i39ew28814PsKmZlWhFSloZD1Lr8CTe9tNCXTzP3bzwu7MhaYV01j25LNOcWalazG7GVSX40Pb0NrPYRG1DcDTlIw= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) with Microsoft SMTP Server (TLS) id 15.1.492.11; Wed, 11 May 2016 22:28:48 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0492.016; Wed, 11 May 2016 22:28:48 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: zero-touch open issues Thread-Index: AQHRq9R8p7Kw7uGDtkGDdidKR1P5KQ== Date: Wed, 11 May 2016 22:28:48 +0000 Message-ID: <61B0912D-CCD6-4FCC-B73D-E2D09DB51C1E@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.15.1.160411 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.10] x-ms-office365-filtering-correlation-id: 87daf84b-776d-4577-ddb8-08d379eb9f1a x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 5:47Zu7NSpj/iKYQ73MQbAB3nz1ijdOJehRBgzGKzXZb5xLIu/vjuWpdbuW4LtqJgQS8rNHITDTW9pM+pRyx19c1bI5lF2WqPAi8TIW3AwoBGV+byth+rMvK0N6w4dJV81S5G69K4PSggTSNBCQoS2Lg==; 24:SioTjEqiIsfsSSOEmofqgrQzeeO6kPGBsPhYXQT2CHHac6qoC/GpM0w4kghtq4SI4BoOOZZS81j+ZHIUmOqAEWFI3R6xBl287lzb4oVHGwQ=; 7:GiV0gU8QhsMabq6kuSdFeOvucEhEyKn5sMupTTER9boycNn32pILiasxbTefXDlw/jaCyMmbuBD+KpfYWKqDeHxaIGDIfQUj9K/ytXpsrJLS4RNGXqv1eNe97QRlKogVK1boq7jWxhfyBtjlqC4uXUclNKOEP/dwweFTVv+QklMozU60Vm14ADpjG2GzG5+4 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 0939529DE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(50986999)(3846002)(1220700001)(2351001)(586003)(6116002)(11100500001)(102836003)(5002640100001)(5008740100001)(54356999)(83716003)(1730700003)(82746002)(92566002)(122556002)(229853001)(36756003)(86362001)(81166006)(5004730100002)(83506001)(450100001)(8936002)(33656002)(87936001)(106116001)(189998001)(2501003)(2900100001)(16236675004)(3660700001)(2906002)(107886002)(66066001)(77096005)(3480700004)(99286002)(5640700001)(110136002)(3280700002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_61B0912DCCD64FCCB73DE2D09DB51C1Ejunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 11 May 2016 22:28:48.1579 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1442 Archived-At: Subject: [Netconf] zero-touch open issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 22:28:52 -0000 --_000_61B0912DCCD64FCCB73DE2D09DB51C1Ejunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpORVRDT05GIFdHLA0KDQpXZSBkaXNjdXNzZWQgdGhlIGZvbGxvd2luZyBmb3VyIGlzc3VlcyBk dXJpbmcgdGhlIElFVEYgOTUgbWVldGluZzoNCg0KICAqIE93bmVyc2hpcCBWb3VjaGVyIOKAkyBm b3JtYWxseSBkZWZpbmU/DQogICogSG93IHRvIGNvbW1pdCBjb25maWc/ICBNZXJnZS9yZXBsYWNl Pw0KICAqIFNpZ25hdHVyZSBvdmVyIFlBTkcgZGF0YT8NCiAgKiBSZW1vdmFibGUgc3RvcmFnZSBk ZXRhaWxzPw0KDQpXaGlsZSB0aGVyZSB3YXMgc29tZSBkaXNjdXNzaW9uIG9uIHNvbWUgb2YgdGhl c2UgaXNzdWVzLCB0aGV5IGFsbCBuZWVkZWQgdG8gYmUgYnJvdWdodCB0byB0aGUgbGlzdCBmb3Ig ZGlzY3Vzc2lvbi4uLiAgICBTaG9ydGx5IEkgd2lsbCBiZSBzZW5kaW5nIG91dCBmb3VyIGVtYWls cywgb25lIGZvciBlYWNoIG9mIHRoZXNlIGlzc3Vlcywgc28gdGhhdCB3ZSBjYW4gaGF2ZSB0aG9z ZSBkaXNjdXNzaW9ucyBhbmQgY2xvc2UgdGhlc2UgaXNzdWVzLg0KDQpSZWdhcmRzLA0KS2VudA0K DQoNCg== --_000_61B0912DCCD64FCCB73DE2D09DB51C1Ejunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdiBzdHlsZT0iY29s b3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQt c2l6ZTogMTRweDsiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAs IDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+ DQpORVRDT05GIFdHLDwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGJyPg0K PC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQpXZSBkaXNjdXNzZWQgdGhlIGZv bGxvd2luZyBmb3VyIGlzc3VlcyBkdXJpbmcgdGhlIElFVEYgOTUgbWVldGluZzo8L2Rpdj4NCjxk aXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29s b3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQt c2l6ZTogMTRweDsiPg0KPGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4mbmJzcDsgKiBP d25lcnNoaXAgVm91Y2hlciDigJMgZm9ybWFsbHkgZGVmaW5lPzwvZm9udD48L2Rpdj4NCjxkaXYg c3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCiZuYnNwOyAqIEhvdyB0byBjb21taXQgY29uZmlnPyAm bmJzcDtNZXJnZS9yZXBsYWNlPzwvZGl2Pg0KPGRpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJy aSxzYW5zLXNlcmlmIj4mbmJzcDsgKiBTaWduYXR1cmUgb3ZlciBZQU5HIGRhdGE/PC9mb250Pjwv ZGl2Pg0KPGRpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4mbmJzcDsg KiBSZW1vdmFibGUgc3RvcmFnZSBkZXRhaWxzPzwvZm9udD48L2Rpdj4NCjxkaXYgc3R5bGU9ImNv bG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250 LXNpemU6IDE0cHg7Ij4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9 ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBm b250LXNpemU6IDE0cHg7Ij4NCldoaWxlIHRoZXJlIHdhcyBzb21lIGRpc2N1c3Npb24gb24gc29t ZSBvZiB0aGVzZSBpc3N1ZXMsIHRoZXkgYWxsIG5lZWRlZCB0byBiZSBicm91Z2h0IHRvIHRoZSBs aXN0IGZvciBkaXNjdXNzaW9uLi4uICZuYnNwOyAmbmJzcDtTaG9ydGx5IEkgd2lsbCBiZSBzZW5k aW5nIG91dCBmb3VyIGVtYWlscywgb25lIGZvciBlYWNoIG9mIHRoZXNlIGlzc3Vlcywgc28gdGhh dCB3ZSBjYW4gaGF2ZSB0aG9zZSBkaXNjdXNzaW9ucyBhbmQgY2xvc2UgdGhlc2UgaXNzdWVzLjwv ZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsgZm9udC1zaXplOiAxNHB4OyI+DQpSZWdhcmRzLDwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6 IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6 ZTogMTRweDsiPg0KS2VudDwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGJy Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8ZGl2IHN0eWxlPSJjb2xv cjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1z aXplOiAxNHB4OyI+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJn YigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTog MTRweDsiPg0KPGRpdiBpZD0iTUFDX09VVExPT0tfU0lHTkFUVVJFIj48L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_61B0912DCCD64FCCB73DE2D09DB51C1Ejunipernet_-- From nobody Wed May 11 15:57:56 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAB3912B049 for ; Wed, 11 May 2016 15:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWcftSzujG09 for ; Wed, 11 May 2016 15:57:52 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0139.outbound.protection.outlook.com [207.46.100.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 053C912B077 for ; Wed, 11 May 2016 15:57:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2X0rsxYBqfOnGU4fjcsHReDAIwaaPaVdgGz683o71s0=; b=fNZ8UIbUiTxPwB1Vzy+BFCLxIIpGNRqDB1Ihm7Gtc1qmF6tt/gnc9JvPpQVxRuNlq2NOvtSyLf0ZtGvJu01XpLJkBVNPPTl7tmH6PYkmxY//jWxWy1xp/Ccb8e0QA2Cny3nDmKyHeRQSXH9quaRuE/2fnrgcoqmvCBlyNCk/HYE= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) with Microsoft SMTP Server (TLS) id 15.1.492.11; Wed, 11 May 2016 22:57:50 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0492.016; Wed, 11 May 2016 22:57:50 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: =?utf-8?B?emVyb3RvdWNoLzExOiBPd25lcnNoaXAgVm91Y2hlciDigJMgZm9ybWFsbHkg?= =?utf-8?Q?define=3F?= Thread-Index: AQHRq9iLCA+twW8d2kK6dwvWSYOwLw== Date: Wed, 11 May 2016 22:57:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.15.1.160411 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.10] x-ms-office365-filtering-correlation-id: d2f8c788-9c87-4795-1130-08d379efadc6 x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 5:NgkALcfzA8XPqaeRaxmrqmq10UNMH1QqnncTVyk4INBFfz7xpTMbqW+j2o5CWRAFjHKynb/UevavxIZxZyAWelEOwJdnZkJi1bGe+nWJFJuIsdKHOrZ1TfS7fVuqd5/wpR8oqltHXUVPWdCi5No5GQ==; 24:tSBN/2PvzkZiZdbOYT4BwuaguD1eW+0z2Qnar/GK94LpET5/xArQrX8sU6YcaC+M3J8VTzJKHkuhvAphR3+f6KqPMhxidAM9NjRR+CXuCGg=; 7:0NE9TcKfvSVuf6KaH9WNmQIVaqIb047aWG7iIsIuWNcEcB0WKaRIYM2U0Xm2kqrarRRPm2Ay7ySQ8jaCq6L0kbV9KIhL/LcP9dUPXp+hiXSaiWbVyV34bC5Wu4AZbbW4Mv+BVe2FaZL0JBjkex2db1nbKlydtkc97gV5mNRyP8GVutYyjGiZCTV1prh7U39S x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 0939529DE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(50986999)(3846002)(1220700001)(2351001)(586003)(6116002)(11100500001)(5002640100001)(102836003)(5008740100001)(54356999)(83716003)(1730700003)(82746002)(92566002)(122556002)(229853001)(36756003)(86362001)(81166006)(5004730100002)(83506001)(450100001)(8936002)(33656002)(87936001)(106116001)(189998001)(2501003)(2900100001)(16236675004)(15975445007)(3660700001)(2906002)(107886002)(66066001)(19580395003)(77096005)(5640700001)(110136002)(3280700002)(99286002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_C543FCC5A86B410BABE27F2AF895FA76junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 11 May 2016 22:57:50.8017 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1442 Archived-At: Subject: [Netconf] =?utf-8?q?zerotouch/11=3A_Ownership_Voucher_=E2=80=93_f?= =?utf-8?q?ormally_define=3F?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 22:57:55 -0000 --_000_C543FCC5A86B410BABE27F2AF895FA76junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 aHR0cHM6Ly9naXRodWIuY29tL25ldGNvbmYtd2cvemVyby10b3VjaC9pc3N1ZXMvMTENCg0KVGhp cyBpc3N1ZSByZWdhcmRzIHRoZSBmb3JtYXQgb2YgdGhlIG93bmVyc2hpcCB2b3VjaGVyLiAgVGhl IGN1cnJlbnQgZHJhZnQgZGVmaW5lcyB0aGUgb3duZXJzaGlwIHZvdWNoZXIgYXMgYSB2ZW5kb3It c3BlY2lmaWMgZm9ybWF0LCBidXQgdGhlcmUgbWF5IGJlIGEgZGVzaXJlIHRvIGRlZmluZSBhIG5v cm1hdGl2ZSBmb3JtYXQsIHNvIHRoYXQgaXQgaGVscHMgd2l0aCBETlMtU0QgYXMgd2VsbCBhcyB3 aXRoIHRoZSBBTklNQSBib290c3RyYXBwaW5nIGFwcHJvYWNoLg0KDQpDdXJyZW50bHkgdGhpcyBp dGVtIGlzIG9uIHRoZSBBTklNQSBib290c3RyYXBwaW5nIHRlYW0ncyBhZ2VuZGEgdG8gZGlzY3Vz cyBpbiBhbiB1cGNvbWluZyBtZWV0aW5nLiAgSXQncyBwcm9iYWJseSBiZXN0IHRvIGRlZmVyIGRp c2N1c3Npb24gb24gdGhpcyBpc3N1ZSB1bnRpbCBhZnRlciB0aGUgQU5JTUEgZm9sa3MgaGF2ZSBk aXNjdXNzZWQgaXQuICBJIHdpbGwgc2VuZCBhbiB1cGRhdGUgdG8gdGhlIGxpc3Qgd2l0aCB0aGUg cmVzdWx0cyBvZiB0aGF0IGRpc2N1c3Npb24gYXMgc29vbiBhcyBJIGNhbi4NCg0KDQpSZWdhcmRz LA0KDQpLZW50DQoNCg== --_000_C543FCC5A86B410BABE27F2AF895FA76junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <9C7FBEA1056AEB4293A2865CC85CF0DF@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxwIHN0eWxl PSJib3gtc2l6aW5nOiBib3JkZXItYm94OyBtYXJnaW4tYm90dG9tOiAxNnB4OyBjb2xvcjogcmdi KDUxLCA1MSwgNTEpOyBmb250LWZhbWlseTogJ0hlbHZldGljYSBOZXVlJywgSGVsdmV0aWNhLCAn U2Vnb2UgVUknLCBBcmlhbCwgZnJlZXNhbnMsIHNhbnMtc2VyaWYsICdBcHBsZSBDb2xvciBFbW9q aScsICdTZWdvZSBVSSBFbW9qaScsICdTZWdvZSBVSSBTeW1ib2wnOyBtYXJnaW4tdG9wOiAwcHgg IWltcG9ydGFudDsiPg0KaHR0cHM6Ly9naXRodWIuY29tL25ldGNvbmYtd2cvemVyby10b3VjaC9p c3N1ZXMvMTE8L3A+DQo8cCBzdHlsZT0iYm94LXNpemluZzogYm9yZGVyLWJveDsgbWFyZ2luLWJv dHRvbTogMTZweDsgY29sb3I6IHJnYig1MSwgNTEsIDUxKTsgZm9udC1mYW1pbHk6ICdIZWx2ZXRp Y2EgTmV1ZScsIEhlbHZldGljYSwgJ1NlZ29lIFVJJywgQXJpYWwsIGZyZWVzYW5zLCBzYW5zLXNl cmlmLCAnQXBwbGUgQ29sb3IgRW1vamknLCAnU2Vnb2UgVUkgRW1vamknLCAnU2Vnb2UgVUkgU3lt Ym9sJzsgbWFyZ2luLXRvcDogMHB4ICFpbXBvcnRhbnQ7Ij4NClRoaXMgaXNzdWUgcmVnYXJkcyB0 aGUgZm9ybWF0IG9mIHRoZSBvd25lcnNoaXAgdm91Y2hlci4gJm5ic3A7VGhlIGN1cnJlbnQgZHJh ZnQgZGVmaW5lcyB0aGUgb3duZXJzaGlwIHZvdWNoZXIgYXMgYSB2ZW5kb3Itc3BlY2lmaWMgZm9y bWF0LCBidXQgdGhlcmUgbWF5IGJlIGEgZGVzaXJlIHRvIGRlZmluZSBhIG5vcm1hdGl2ZSBmb3Jt YXQsIHNvIHRoYXQgaXQgaGVscHMgd2l0aCBETlMtU0QgYXMgd2VsbCBhcyB3aXRoIHRoZSBBTklN QSBib290c3RyYXBwaW5nDQogYXBwcm9hY2guPC9wPg0KPHAgc3R5bGU9ImJveC1zaXppbmc6IGJv cmRlci1ib3g7IG1hcmdpbi10b3A6IDBweDsgY29sb3I6IHJnYig1MSwgNTEsIDUxKTsgZm9udC1m YW1pbHk6ICdIZWx2ZXRpY2EgTmV1ZScsIEhlbHZldGljYSwgJ1NlZ29lIFVJJywgQXJpYWwsIGZy ZWVzYW5zLCBzYW5zLXNlcmlmLCAnQXBwbGUgQ29sb3IgRW1vamknLCAnU2Vnb2UgVUkgRW1vamkn LCAnU2Vnb2UgVUkgU3ltYm9sJzsgbWFyZ2luLWJvdHRvbTogMHB4ICFpbXBvcnRhbnQ7Ij4NCkN1 cnJlbnRseSB0aGlzIGl0ZW0gaXMgb24gdGhlIEFOSU1BIGJvb3RzdHJhcHBpbmcgdGVhbSdzIGFn ZW5kYSB0byBkaXNjdXNzIGluIGFuIHVwY29taW5nIG1lZXRpbmcuICZuYnNwO0l0J3MgcHJvYmFi bHkgYmVzdCB0byBkZWZlciBkaXNjdXNzaW9uIG9uIHRoaXMgaXNzdWUgdW50aWwgYWZ0ZXIgdGhl IEFOSU1BIGZvbGtzIGhhdmUgZGlzY3Vzc2VkIGl0LiAmbmJzcDtJIHdpbGwgc2VuZCBhbiB1cGRh dGUgdG8gdGhlIGxpc3Qgd2l0aCB0aGUgcmVzdWx0cyBvZiB0aGF0DQogZGlzY3Vzc2lvbiBhcyBz b29uIGFzIEkgY2FuLjwvcD4NCjxwIHN0eWxlPSJib3gtc2l6aW5nOiBib3JkZXItYm94OyBtYXJn aW4tdG9wOiAwcHg7IGNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7IGZvbnQtZmFtaWx5OiAnSGVsdmV0 aWNhIE5ldWUnLCBIZWx2ZXRpY2EsICdTZWdvZSBVSScsIEFyaWFsLCBmcmVlc2Fucywgc2Fucy1z ZXJpZiwgJ0FwcGxlIENvbG9yIEVtb2ppJywgJ1NlZ29lIFVJIEVtb2ppJywgJ1NlZ29lIFVJIFN5 bWJvbCc7IG1hcmdpbi1ib3R0b206IDBweCAhaW1wb3J0YW50OyI+DQo8YnI+DQo8L3A+DQo8cCBz dHlsZT0iYm94LXNpemluZzogYm9yZGVyLWJveDsgbWFyZ2luLXRvcDogMHB4OyBjb2xvcjogcmdi KDUxLCA1MSwgNTEpOyBmb250LWZhbWlseTogJ0hlbHZldGljYSBOZXVlJywgSGVsdmV0aWNhLCAn U2Vnb2UgVUknLCBBcmlhbCwgZnJlZXNhbnMsIHNhbnMtc2VyaWYsICdBcHBsZSBDb2xvciBFbW9q aScsICdTZWdvZSBVSSBFbW9qaScsICdTZWdvZSBVSSBTeW1ib2wnOyBtYXJnaW4tYm90dG9tOiAw cHggIWltcG9ydGFudDsiPg0KUmVnYXJkcyw8L3A+DQo8cCBzdHlsZT0iYm94LXNpemluZzogYm9y ZGVyLWJveDsgbWFyZ2luLXRvcDogMHB4OyBjb2xvcjogcmdiKDUxLCA1MSwgNTEpOyBmb250LWZh bWlseTogJ0hlbHZldGljYSBOZXVlJywgSGVsdmV0aWNhLCAnU2Vnb2UgVUknLCBBcmlhbCwgZnJl ZXNhbnMsIHNhbnMtc2VyaWYsICdBcHBsZSBDb2xvciBFbW9qaScsICdTZWdvZSBVSSBFbW9qaScs ICdTZWdvZSBVSSBTeW1ib2wnOyBtYXJnaW4tYm90dG9tOiAwcHggIWltcG9ydGFudDsiPg0KS2Vu dDwvcD4NCjxwIHN0eWxlPSJib3gtc2l6aW5nOiBib3JkZXItYm94OyBtYXJnaW4tdG9wOiAwcHg7 IGNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7IGZvbnQtZmFtaWx5OiAnSGVsdmV0aWNhIE5ldWUnLCBI ZWx2ZXRpY2EsICdTZWdvZSBVSScsIEFyaWFsLCBmcmVlc2Fucywgc2Fucy1zZXJpZiwgJ0FwcGxl IENvbG9yIEVtb2ppJywgJ1NlZ29lIFVJIEVtb2ppJywgJ1NlZ29lIFVJIFN5bWJvbCc7IG1hcmdp bi1ib3R0b206IDBweCAhaW1wb3J0YW50OyI+DQo8YnI+DQo8L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2IGlkPSJNQUNfT1VUTE9PS19TSUdOQVRVUkUiPjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_C543FCC5A86B410BABE27F2AF895FA76junipernet_-- From nobody Wed May 11 16:03:49 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B58412D1E5 for ; Wed, 11 May 2016 16:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9e4iVncwsRV for ; Wed, 11 May 2016 16:03:46 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0141.outbound.protection.outlook.com [65.55.169.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43BD412D157 for ; Wed, 11 May 2016 16:03:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=iqBikoO+YSsQBmLPTrmbK8Y+6UcTGtd9epugWn8iBy4=; b=Qa3yfgoYc9iAr6/RIzW7K0QklUKNsWioKAazK796HjjqDb2RABn1+vHLtXxca0FE8InE6yQqIujxIPpcErmn5wFgd3/vr1SCiGdcWhRaim9fhYi0SfrNxwSXE2f0twB+nRoWAgEssnepnaA1pQw6wWi14WjXUCIG7qzwdyTGa+Y= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1444.namprd05.prod.outlook.com (10.160.117.153) with Microsoft SMTP Server (TLS) id 15.1.485.9; Wed, 11 May 2016 23:03:44 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0492.016; Wed, 11 May 2016 23:03:44 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: zerotouch/12: How to commit config? Merge/replace? Thread-Index: AQHRq9lekirsStPVvk6fQTyyNydlJg== Date: Wed, 11 May 2016 23:03:44 +0000 Message-ID: <6E20A00C-BB9B-4AD1-96DE-CD461E0F38CD@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.15.1.160411 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.10] x-ms-office365-filtering-correlation-id: d5ac43c9-92c5-4190-14d9-08d379f08097 x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1444; 5:W0B8wL77W6zG9xoK8qrXyrVYTSzD0affmyJfoGF4Y1WA0z1SPIYZfepFwl1jfaacEr2I4C4IaEMlCJqEY15GJPTO4O/KHHCn0uDYaMykm3f5Zw6ksnqVHMwL1z2HFNDadiYsVtPds3C6SnkGs+nLDA==; 24:sYcH3Pm+5/pMcdZZnl100VWhAvwZEfjkxOjB6VdicQ1EGop6jWGyOpohqu65APxUh78Y0tt691UXV1oyQdnFI4ZXRPdBvHaJZgkNvEB+YNk=; 7:gpFS55WtzWc8tpjwNHscNmQjTZekayAD4LPaII9sANYwodSlt8PHPVOPCkF5OKxxmtY33zcKXI4hRQSub89bonGufeEn2LC5vA2mkYrnEVRl5JBLBaYENzbbXSfs6S457FLogUKKhGwDaIDy3roJ3FhjXuXoKinGixjyGAXmKt6r7PwBiPbzHe+cscEF9ubG x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1444; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:BN3PR0501MB1444; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1444; x-forefront-prvs: 0939529DE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(2351001)(19580395003)(33656002)(3280700002)(2900100001)(229853001)(110136002)(5002640100001)(50986999)(82746002)(81166006)(1730700003)(2501003)(83506001)(16236675004)(189998001)(107886002)(54356999)(122556002)(15975445007)(5008740100001)(77096005)(3660700001)(66066001)(83716003)(5640700001)(1220700001)(2906002)(8936002)(102836003)(6116002)(5004730100002)(36756003)(586003)(92566002)(99286002)(106116001)(3846002)(11100500001)(450100001)(87936001)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1444; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_6E20A00CBB9B4AD196DECD461E0F38CDjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 11 May 2016 23:03:44.4931 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1444 Archived-At: Subject: [Netconf] zerotouch/12: How to commit config? Merge/replace? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 23:03:48 -0000 --_000_6E20A00CBB9B4AD196DECD461E0F38CDjunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 aHR0cHM6Ly9naXRodWIuY29tL25ldGNvbmYtd2cvemVyby10b3VjaC9pc3N1ZXMvMTINCg0KDQpT bGlkZSAxMCBmcm9tIHRoZSB6ZXJvIHRvdWNoIHByZXNvIEAgOTUgaGFkOg0KDQogIE9wdGlvbnM6 DQpBLiBIYXJkY29kZSDigJ1yZXBsYWNl4oCdICAgICAgICAgICAgICAgICAgICAgICAgLy8gYWx3 YXlzIHdvcmtzLCBidXQgbGFyZ2UgaW4gc2l6ZQ0KQi4gVXNlIGEgdG9wLWxldmVsIGZsYWcgICAg ICAgICAgICAgICAgICAgICAgICAgLy8gbGV0IGRlcGxveW1lbnRzIGRlY2lkZQ0KQy4gVXNlIGVk aXQtY29uZmlnIG9yIHlhbmctcGF0Y2g/ICAgICAvLyBpcyB0aGlzIG11Y2ggZ3JhbnVsYXJpdHkg bmVlZGVkPw0KDQpUaGUgbWludXRlcyBub3RlIHRoYXQgUmljayBUYXlsb3IgcHJlZmVycyB0aGUg bGFzdCBvcHRpb24sIHN0YXRpbmcgdGhhdCB0aGUgY29uZmlndXJhdGlvbiBjYW4gYmUgYmlnLg0K DQpCdXQgbGV0J3MgY29uc2lkZXIgb3B0aW9uIChiKSBpbiB0aGUgY29udGV4dCBvZiB0aGUgY29u ZmlnIGJlaW5nIGJpZy4gICBJZiB0aGUgdG9wLWxldmVsIGZsYWcgaXMgJ21lcmdlJyBhbmQgdGhl IGNvbmZpZyBpcyBodWdlLCB0aGVuIGl0J3MgZWZmZWN0aXZlbHkgdGhlIHNhbWUgYXMgPGVkaXQt Y29uZmlnPi4gICBPdGhlcndpc2UsIGlmIHRoZSB0b3AtbGV2ZWwgZmxhZyBpcyAncmVwbGFjZScg YW5kIHRoZSBjb25maWcgaXMgaHVnZSwgdGhlbiB0aGUgYW1vdW50IG9mIGZhY3RvcnktZGVmYXVs dCBjb25maWcgdGhhdCBnZXRzIHJlcGxhY2VkIGlzIHJlbGF0aXZlbHkgc21hbGwuICBTbyBpdCBz ZWVtcyB0aGF0IG9wdGlvbiAoYikgaXMgZXF1YWxseSB2aWFibGUgaW4gdGhlIGNvbnRleHQgb2Yg aHVnZSBjb25maWdzLg0KDQpJIHBlcnNvbmFsbHkgcHJlZmVyIG9wdGlvbiAoYiksIGJlY2F1c2Ug SSB0aGluayB0aGF0IGl0J3MgYmV0dGVyIGluIHRoaXMgY2FzZSB0byBub3QgcmVxdWlyZSB0aGUg Y2xpZW50IHRvIGhhdmUgdG8gdW5kZXJzdGFuZCBlZGl0LWNvbmZpZyBvciB5YW5nLXBhdGNoLiAg UmVjYWxsLCB0aGUgZGV2aWNlIGlzIHRoZSBIVFRQIGNsaWVudCwgYW5kIHRoZSBsb2dpYyB0aGF0 IGltcGxlbWVudHMgdGhlIGJvb3RzdHJhcHBpbmcgY29kZSBtYXkgYmUgZGlmZmVyZW50IHRoYW4g dGhlIGxvZ2ljIHRoYXQga25vd3MgaG93IHRvIHByb2Nlc3MgTkVUQ09ORiBvciBSRVNUQ09ORiwg YXQgbGVhc3QgdGhpcyBob3cgSSd2ZSBzZWVuIGl0IGltcGxlbWVudGVkLi4uDQoNClRob3VnaHRz Pw0KDQpLZW50DQoNCg== --_000_6E20A00CBB9B4AD196DECD461E0F38CDjunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <31BB0F14DB159A41BA778BDF7938ED56@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj5odHRwczovL2dpdGh1Yi5jb20vbmV0Y29uZi13Zy96ZXJvLXRvdWNoL2lzc3Vl cy8xMjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlNs aWRlIDEwIGZyb20gdGhlIHplcm8gdG91Y2ggcHJlc28gQCA5NSBoYWQ6PC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdj4mbmJzcDsgT3B0aW9uczo8L2Rpdj4NCjxkaXY+PHNwYW4gY2xhc3M9 IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+QS4gSGFyZGNv ZGUg4oCdcmVwbGFjZeKAnSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy8vIGFsd2F5cyB3b3Jr cywgYnV0IGxhcmdlIGluIHNpemU8L2Rpdj4NCjxkaXY+PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1z cGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+Qi4gVXNlIGEgdG9wLWxldmVsIGZs YWcgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsvLyBsZXQgZGVwbG95bWVudHMgZGVj aWRlPC9kaXY+DQo8ZGl2PjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRl LXNwYWNlOnByZSI+PC9zcGFuPkMuIFVzZSBlZGl0LWNvbmZpZyBvciB5YW5nLXBhdGNoPyAmbmJz cDsgJm5ic3A7Jm5ic3A7Ly8gaXMgdGhpcyBtdWNoIGdyYW51bGFyaXR5IG5lZWRlZD88L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoZSBtaW51dGVzIG5vdGUgdGhhdCBSaWNrIFRheWxv ciBwcmVmZXJzIHRoZSBsYXN0IG9wdGlvbiwgc3RhdGluZyB0aGF0IHRoZSBjb25maWd1cmF0aW9u IGNhbiBiZSBiaWcuICZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QnV0IGxl dCdzIGNvbnNpZGVyIG9wdGlvbiAoYikgaW4gdGhlIGNvbnRleHQgb2YgdGhlIGNvbmZpZyBiZWlu ZyBiaWcuICZuYnNwOyBJZiB0aGUgdG9wLWxldmVsIGZsYWcgaXMgJ21lcmdlJyBhbmQgdGhlIGNv bmZpZyBpcyBodWdlLCB0aGVuIGl0J3MgZWZmZWN0aXZlbHkgdGhlIHNhbWUgYXMgJmx0O2VkaXQt Y29uZmlnJmd0Oy4gJm5ic3A7IE90aGVyd2lzZSwgaWYgdGhlIHRvcC1sZXZlbCBmbGFnIGlzICdy ZXBsYWNlJyBhbmQgdGhlIGNvbmZpZyBpcyBodWdlLCB0aGVuDQogdGhlIGFtb3VudCBvZiBmYWN0 b3J5LWRlZmF1bHQgY29uZmlnIHRoYXQgZ2V0cyByZXBsYWNlZCBpcyByZWxhdGl2ZWx5IHNtYWxs LiAmbmJzcDtTbyBpdCBzZWVtcyB0aGF0IG9wdGlvbiAoYikgaXMgZXF1YWxseSB2aWFibGUgaW4g dGhlIGNvbnRleHQgb2YgaHVnZSBjb25maWdzLiAmbmJzcDsmbmJzcDs8L2Rpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8ZGl2PkkgcGVyc29uYWxseSBwcmVmZXIgb3B0aW9uIChiKSwgYmVjYXVzZSBJ IHRoaW5rIHRoYXQgaXQncyBiZXR0ZXIgaW4gdGhpcyBjYXNlIHRvIG5vdCByZXF1aXJlIHRoZSBj bGllbnQgdG8gaGF2ZSB0byB1bmRlcnN0YW5kIGVkaXQtY29uZmlnIG9yIHlhbmctcGF0Y2guICZu YnNwO1JlY2FsbCwgdGhlIGRldmljZSBpcyB0aGUgSFRUUCBjbGllbnQsIGFuZCB0aGUgbG9naWMg dGhhdCBpbXBsZW1lbnRzIHRoZSBib290c3RyYXBwaW5nIGNvZGUgbWF5IGJlDQogZGlmZmVyZW50 IHRoYW4gdGhlIGxvZ2ljIHRoYXQga25vd3MgaG93IHRvIHByb2Nlc3MgTkVUQ09ORiBvciBSRVNU Q09ORiwgYXQgbGVhc3QgdGhpcyBob3cgSSd2ZSBzZWVuIGl0IGltcGxlbWVudGVkLi4uPC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaG91Z2h0cz88L2Rpdj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8ZGl2PktlbnQ8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2IGlkPSJNQUNfT1VUTE9PS19TSUdOQVRVUkUiPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_6E20A00CBB9B4AD196DECD461E0F38CDjunipernet_-- From nobody Wed May 11 16:21:16 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 619F212D844 for ; Wed, 11 May 2016 16:21: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CKArC3YrW2A for ; Wed, 11 May 2016 16:20:56 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0776.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:776]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4A1712D82B for ; Wed, 11 May 2016 16:20:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=M6S5SOcq/lirECF/1G7OINNce6r+IPKYkekMsR0lO0A=; b=cj+4Wu/cwPdJXD3uuN1kkair0BjwhoM7rjtauadXLTUVijtc1IGuT4ZXWA9ekEUsr1HTyRYF77YcC7nLhStrd6N/SXdi5UR9BjRxdqZ8S6KRNR3uZN2W/Bv9YkpsqljivLD2lgXQi1F73BytQcHBL7Z37VBViNVQKMVxf3HpM2s= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) with Microsoft SMTP Server (TLS) id 15.1.492.11; Wed, 11 May 2016 23:20:23 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0492.016; Wed, 11 May 2016 23:20:23 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: zerotouch/13: Signature over YANG data? Thread-Index: AQHRq9uwhpJMr9xoKUGxID7jNEzq6A== Date: Wed, 11 May 2016 23:20:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.15.1.160411 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.10] x-ms-office365-filtering-correlation-id: ab1f7c50-66ec-48d7-41bc-08d379f2d445 x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 5:t1zJEK1w1mS861j7Jz1aFXCDS3n3eDxT1agtA+Q7fSYgB6NXrzdf3K2zzPWUuGBbaYsYRwPcR14TEFoB1s58s5EkHQ8emjnSibw+/RLwq63x6MG+C0ovmAUIqCuCKa6ap0J5yg7Kbgxk233aVPI6Hg==; 24:HILtbjeKrJ0ZkY0d8HBEjMc32iAKl6KwJUbCQWuIExBovssr1O/orfC5B+/ImG17iS49k85r2FlntRQh+3hy7SjLRDhBREI1gtgfXkbL72w=; 7:SkmxiPfrQUJzigPwk/vjQfg1ebuL27AyYimb+mVNVgtw33EkOllJ7LjgUWC7zpCBLohWOBy8xxgzXuJQSLWpQR4BOnIx1li2ASP3mYoI7Iv0cIKqkLUqMlkTeBqeCKy0K/TUbw6xm8VhKuOzZdUc+ZsniJjdal+YZUcsEflVfN3uWYPcbGXnWy57sV60tieW x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 0939529DE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(450100001)(87936001)(106116001)(33656002)(8936002)(81166006)(5004730100002)(86362001)(83506001)(77096005)(107886002)(19580395003)(66066001)(99286002)(3280700002)(110136002)(5640700001)(16236675004)(15975445007)(2501003)(189998001)(2900100001)(2906002)(3660700001)(11100500001)(102836003)(5002640100001)(54356999)(5008740100001)(50986999)(2351001)(6116002)(586003)(3846002)(1220700001)(36756003)(122556002)(229853001)(92566002)(83716003)(82746002)(1730700003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_EF803F0EC1CA43F6AB17EE2E10B6DB13junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 11 May 2016 23:20:23.6914 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1442 Archived-At: Subject: [Netconf] zerotouch/13: Signature over YANG data? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 23:21:06 -0000 --_000_EF803F0EC1CA43F6AB17EE2E10B6DB13junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 aHR0cHM6Ly9naXRodWIuY29tL25ldGNvbmYtd2cvemVyby10b3VjaC9pc3N1ZXMvMTMNCg0KDQoN ClNsaWRlICMxMSBwcmVzZW50ZWQgZHVyaW5nIHRoZSBJRVRGIDk1IG1lZXRpbmcgc2FpZDoNCg0K PT09PT1TVEFSVD09PT09DQpDdXJyZW50IHRleHQgc2F5cyB0aGF0IHRoZSBzaWduYXR1cmUgaXMg b3ZlciB0aGUgZGF0YSBpbiB3aGF0ZXZlciBmb3JtIGl04oCZcyBwcm92aWRlZCAoWE1MIG9yIEpT T04pDQoNClRoaXMgd29ya3MgZ3JlYXQgZm9yIGFsbCBzb3VyY2VzIG9mIGJvb3RzdHJhcHBpbmcg ZGF0YSBidXQsIGZvciB0aGUgYm9vdHN0cmFwIHNlcnZlciwgcmVxdWlyZXMgdGhhdCBib3RoIHRo ZSBub3J0aGJvdW5kIGFwcGxpY2F0aW9uIGFuZCB0aGUgZGV2aWNlIGFjY2VzcyBzcGVjaWZpYyBV UkwgcmVzb3VyY2VzOg0KL2lldGYtemVyb3RvdWNoLWJvb3RzdHJhcC1zZXJ2ZXI6ZGV2aWNlcy9k ZXZpY2U9MTIzNDU2L3JlZGlyZWN0LWluZm9ybWF0aW9uDQovaWV0Zi16ZXJvdG91Y2gtYm9vdHN0 cmFwLXNlcnZlcjpkZXZpY2VzL2RldmljZT0xMjM0NTYvYm9vdHN0cmFwLWluZm9ybWF0aW9uDQoN CkJ1dCB0aGlzIGFwcHJvYWNoIGhhcyBpc3N1ZXM6DQoNCiAgKiAgIFNlcnZlciBNVVNUIE5PVCBj aGFuZ2UgaXRzIGVuY29kaW5nIGluIGFueSB3YXkgYmV0d2VlbiB0aGUgdGltZSB0aGUgZGF0YSB3 YXMgc2F2ZWQgYW5kIHdoZW4gdGhlIGRldmljZSByZXRyaWV2ZXMgdGhlIGRhdGENCiAgKiAgIFRo ZXNlIHR3byByZXNvdXJjZXMgYXJlIHVuZGVyIGEgY2hvaWNlIG5vZGUsIGFuZCB0aGUgZGV2aWNl IGRvZXNu4oCZdCBrbm93IHVwIGZyb250IHdoaWNoIHdpbGwgYmUgcHJlc2VudC4NCiAgKiAgIEl0 IGlzIGRlc2lyYWJsZSBmb3IgZGV2aWNlIHRvIGp1c3QgZmV0Y2ggdGhlIHRvcC1sZXZlbCDigJxk ZXZpY2XigJ0gcmVzb3VyY2UsIHRvIGdldCBldmVyeXRoaW5nIGluIG9uZSByZXF1ZXN0DQoNCk9w dGlvbnM6DQoNCiAgKiAgIEtlZXAgYXMgaXMgKGUuZy4sIGZvcmNlIGRldmljZSB0byB0cnkgYm90 aCBVUkwgcmVzb3VyY2VzKSAvLyB1cCB0byAzIHJvdW5kIHRyaXBzIGluc3RlYWQgb2YganVzdCBv bmUNCiAgKiAgIERlZmluZSBhIGNhbm9uaWNhbCBmb3JtYXQgZm9yIFhNTCBhbmQgSlNPTiBlbmNv ZGluZ3MgLy8gTm90IHN1cmUgaWYgdGhpcyBpcyBldmVuIHBvc3NpYmxl4oCmDQogICogICBEZWZp bmUgYW4gZW5jb2RpbmctaW5kZXBlbmRlbnQgc2lnbmF0dXJlIGFsZ29yaXRobSAgICAgIC8vIHRy aWNreSB0byBkZWZpbmUsIG5vdCBlYXN5IHRvIGltcGxlbWVudA0KICAqICAgRW5jb2RlIGJvdGgg cmVzb3VyY2VzIGluIGEgbGVhZiBoYXZpbmcgdHlwZSDigJxzdHJpbmfigJ0gICAgICAgLy8gZXZl biB0aG91Z2ggaXTigJlzIFlBTkctZW5jb2RlZCBkYXRhDQoNClRob3VnaHRzPw0KPT09PT1TVE9Q PT09PT0NCg0KSW4gdGhlIGRpc2N1c3Npb24gb24gdGhpcyBzbGlkZSwgSmVmZiBIYWFzIG5vdGVk IHRoYXQgUEtDUyM5IGlzIHBvcHVsYXIgaW4gdGhlIElFVEYgYW5kIHRoYXQgaGUgZmVsdCB0aGF0 IGNhbm9uaWNhbGl6YXRpb24gbWlnaHQgYmUgYSByZXF1aXJlbWVudC4gQnV0IEtlbnQgbm90ZWQg dGhhdCBjYW5vbmljYWxpemF0aW9uIGlzIHByYWN0aWNhbGx5IGltcG9zc2libGUgZ2l2ZW4gdGhh dCBYTUwvSlNPTiBoYXMgbm8gZ3VhcmFudGVlZCBvcmRlcmluZyBvZiB0cmVlIG5vZGVzLg0KDQpJ IGRvbid0IHRoaW5rIHdlIGhhdmUgYSBnb29kIHNvbHV0aW9uIHlldC4uLg0KDQoNCg0KS2VudA0K DQo= --_000_EF803F0EC1CA43F6AB17EE2E10B6DB13junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <111B97A35DC834439303EA767DA2A008@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pmh0dHBzOi8vZ2l0aHViLmNvbS9uZXRjb25mLXdnL3plcm8tdG91Y2gvaXNzdWVzLzEzPC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8cCBzdHls ZT0iYm94LXNpemluZzogYm9yZGVyLWJveDsgbWFyZ2luLWJvdHRvbTogMTZweDsgY29sb3I6IHJn Yig1MSwgNTEsIDUxKTsgZm9udC1mYW1pbHk6ICdIZWx2ZXRpY2EgTmV1ZScsIEhlbHZldGljYSwg J1NlZ29lIFVJJywgQXJpYWwsIGZyZWVzYW5zLCBzYW5zLXNlcmlmLCAnQXBwbGUgQ29sb3IgRW1v amknLCAnU2Vnb2UgVUkgRW1vamknLCAnU2Vnb2UgVUkgU3ltYm9sJzsgbWFyZ2luLXRvcDogMHB4 ICFpbXBvcnRhbnQ7Ij4NClNsaWRlICMxMSZuYnNwO3ByZXNlbnRlZCBkdXJpbmcgdGhlIElFVEYg OTUgbWVldGluZyBzYWlkOjwvcD4NCjxwIHN0eWxlPSJib3gtc2l6aW5nOiBib3JkZXItYm94OyBt YXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDE2cHg7IGNvbG9yOiByZ2IoNTEsIDUxLCA1 MSk7IGZvbnQtZmFtaWx5OiAnSGVsdmV0aWNhIE5ldWUnLCBIZWx2ZXRpY2EsICdTZWdvZSBVSScs IEFyaWFsLCBmcmVlc2Fucywgc2Fucy1zZXJpZiwgJ0FwcGxlIENvbG9yIEVtb2ppJywgJ1NlZ29l IFVJIEVtb2ppJywgJ1NlZ29lIFVJIFN5bWJvbCc7Ij4NCj09PT09U1RBUlQ9PT09PTxiciBzdHls ZT0iYm94LXNpemluZzogYm9yZGVyLWJveDsiPg0KQ3VycmVudCB0ZXh0IHNheXMgdGhhdCB0aGUg c2lnbmF0dXJlIGlzIG92ZXIgdGhlIGRhdGEgaW4gd2hhdGV2ZXIgZm9ybSBpdOKAmXMgcHJvdmlk ZWQgKFhNTCBvciBKU09OKTwvcD4NCjxwIHN0eWxlPSJib3gtc2l6aW5nOiBib3JkZXItYm94OyBt YXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDE2cHg7IGNvbG9yOiByZ2IoNTEsIDUxLCA1 MSk7IGZvbnQtZmFtaWx5OiAnSGVsdmV0aWNhIE5ldWUnLCBIZWx2ZXRpY2EsICdTZWdvZSBVSScs IEFyaWFsLCBmcmVlc2Fucywgc2Fucy1zZXJpZiwgJ0FwcGxlIENvbG9yIEVtb2ppJywgJ1NlZ29l IFVJIEVtb2ppJywgJ1NlZ29lIFVJIFN5bWJvbCc7Ij4NClRoaXMgd29ya3MgZ3JlYXQgZm9yIGFs bCBzb3VyY2VzIG9mIGJvb3RzdHJhcHBpbmcgZGF0YSBidXQsIGZvciB0aGUgYm9vdHN0cmFwIHNl cnZlciwgcmVxdWlyZXMgdGhhdCBib3RoIHRoZSBub3J0aGJvdW5kIGFwcGxpY2F0aW9uIGFuZCB0 aGUgZGV2aWNlIGFjY2VzcyBzcGVjaWZpYyBVUkwgcmVzb3VyY2VzOjxiciBzdHlsZT0iYm94LXNp emluZzogYm9yZGVyLWJveDsiPg0KL2lldGYtemVyb3RvdWNoLWJvb3RzdHJhcC1zZXJ2ZXI6ZGV2 aWNlcy9kZXZpY2U9MTIzNDU2L3JlZGlyZWN0LWluZm9ybWF0aW9uPGJyIHN0eWxlPSJib3gtc2l6 aW5nOiBib3JkZXItYm94OyI+DQovaWV0Zi16ZXJvdG91Y2gtYm9vdHN0cmFwLXNlcnZlcjpkZXZp Y2VzL2RldmljZT0xMjM0NTYvYm9vdHN0cmFwLWluZm9ybWF0aW9uPC9wPg0KPHAgc3R5bGU9ImJv eC1zaXppbmc6IGJvcmRlci1ib3g7IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMTZw eDsgY29sb3I6IHJnYig1MSwgNTEsIDUxKTsgZm9udC1mYW1pbHk6ICdIZWx2ZXRpY2EgTmV1ZScs IEhlbHZldGljYSwgJ1NlZ29lIFVJJywgQXJpYWwsIGZyZWVzYW5zLCBzYW5zLXNlcmlmLCAnQXBw bGUgQ29sb3IgRW1vamknLCAnU2Vnb2UgVUkgRW1vamknLCAnU2Vnb2UgVUkgU3ltYm9sJzsiPg0K QnV0IHRoaXMgYXBwcm9hY2ggaGFzIGlzc3Vlczo8L3A+DQo8dWwgc3R5bGU9ImJveC1zaXppbmc6 IGJvcmRlci1ib3g7IHBhZGRpbmctbGVmdDogMmVtOyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1i b3R0b206IDE2cHg7IGNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7IGZvbnQtZmFtaWx5OiAnSGVsdmV0 aWNhIE5ldWUnLCBIZWx2ZXRpY2EsICdTZWdvZSBVSScsIEFyaWFsLCBmcmVlc2Fucywgc2Fucy1z ZXJpZiwgJ0FwcGxlIENvbG9yIEVtb2ppJywgJ1NlZ29lIFVJIEVtb2ppJywgJ1NlZ29lIFVJIFN5 bWJvbCc7Ij4NCjxsaSBzdHlsZT0iYm94LXNpemluZzogYm9yZGVyLWJveDsiPlNlcnZlciBNVVNU IE5PVCBjaGFuZ2UgaXRzIGVuY29kaW5nIGluIGFueSB3YXkgYmV0d2VlbiB0aGUgdGltZSB0aGUg ZGF0YSB3YXMgc2F2ZWQgYW5kIHdoZW4gdGhlIGRldmljZSByZXRyaWV2ZXMgdGhlIGRhdGE8L2xp PjxsaSBzdHlsZT0iYm94LXNpemluZzogYm9yZGVyLWJveDsiPlRoZXNlIHR3byByZXNvdXJjZXMg YXJlIHVuZGVyIGEgY2hvaWNlIG5vZGUsIGFuZCB0aGUgZGV2aWNlIGRvZXNu4oCZdCBrbm93IHVw IGZyb250IHdoaWNoIHdpbGwgYmUgcHJlc2VudC48YnIgc3R5bGU9ImJveC1zaXppbmc6IGJvcmRl ci1ib3g7Ij4NCjwvbGk+PGxpIHN0eWxlPSJib3gtc2l6aW5nOiBib3JkZXItYm94OyI+SXQgaXMg ZGVzaXJhYmxlIGZvciBkZXZpY2UgdG8ganVzdCBmZXRjaCB0aGUgdG9wLWxldmVsIOKAnGRldmlj ZeKAnSByZXNvdXJjZSwgdG8gZ2V0IGV2ZXJ5dGhpbmcgaW4gb25lIHJlcXVlc3Q8L2xpPjwvdWw+ DQo8cCBzdHlsZT0iYm94LXNpemluZzogYm9yZGVyLWJveDsgbWFyZ2luLXRvcDogMHB4OyBtYXJn aW4tYm90dG9tOiAxNnB4OyBjb2xvcjogcmdiKDUxLCA1MSwgNTEpOyBmb250LWZhbWlseTogJ0hl bHZldGljYSBOZXVlJywgSGVsdmV0aWNhLCAnU2Vnb2UgVUknLCBBcmlhbCwgZnJlZXNhbnMsIHNh bnMtc2VyaWYsICdBcHBsZSBDb2xvciBFbW9qaScsICdTZWdvZSBVSSBFbW9qaScsICdTZWdvZSBV SSBTeW1ib2wnOyI+DQpPcHRpb25zOjwvcD4NCjx1bCBzdHlsZT0iYm94LXNpemluZzogYm9yZGVy LWJveDsgcGFkZGluZy1sZWZ0OiAyZW07IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTog MTZweDsgY29sb3I6IHJnYig1MSwgNTEsIDUxKTsgZm9udC1mYW1pbHk6ICdIZWx2ZXRpY2EgTmV1 ZScsIEhlbHZldGljYSwgJ1NlZ29lIFVJJywgQXJpYWwsIGZyZWVzYW5zLCBzYW5zLXNlcmlmLCAn QXBwbGUgQ29sb3IgRW1vamknLCAnU2Vnb2UgVUkgRW1vamknLCAnU2Vnb2UgVUkgU3ltYm9sJzsi Pg0KPGxpIHN0eWxlPSJib3gtc2l6aW5nOiBib3JkZXItYm94OyI+S2VlcCBhcyBpcyAoZS5nLiwg Zm9yY2UgZGV2aWNlIHRvIHRyeSBib3RoIFVSTCByZXNvdXJjZXMpIC8vIHVwIHRvIDMgcm91bmQg dHJpcHMgaW5zdGVhZCBvZiBqdXN0IG9uZTwvbGk+PGxpIHN0eWxlPSJib3gtc2l6aW5nOiBib3Jk ZXItYm94OyI+RGVmaW5lIGEgY2Fub25pY2FsIGZvcm1hdCBmb3IgWE1MIGFuZCBKU09OIGVuY29k aW5ncyAvLyBOb3Qgc3VyZSBpZiB0aGlzIGlzIGV2ZW4gcG9zc2libGXigKY8L2xpPjxsaSBzdHls ZT0iYm94LXNpemluZzogYm9yZGVyLWJveDsiPkRlZmluZSBhbiBlbmNvZGluZy1pbmRlcGVuZGVu dCBzaWduYXR1cmUgYWxnb3JpdGhtICZuYnNwOyAmbmJzcDsgJm5ic3A7Ly8gdHJpY2t5IHRvIGRl ZmluZSwgbm90IGVhc3kgdG8gaW1wbGVtZW50PC9saT48bGkgc3R5bGU9ImJveC1zaXppbmc6IGJv cmRlci1ib3g7Ij5FbmNvZGUgYm90aCByZXNvdXJjZXMgaW4gYSBsZWFmIGhhdmluZyB0eXBlIOKA nHN0cmluZ+KAnSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAvLyBldmVuIHRob3VnaCBpdOKAmXMgWUFO Ry1lbmNvZGVkIGRhdGE8L2xpPjwvdWw+DQo8cCBzdHlsZT0iYm94LXNpemluZzogYm9yZGVyLWJv eDsgbWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAxNnB4OyBjb2xvcjogcmdiKDUxLCA1 MSwgNTEpOyBmb250LWZhbWlseTogJ0hlbHZldGljYSBOZXVlJywgSGVsdmV0aWNhLCAnU2Vnb2Ug VUknLCBBcmlhbCwgZnJlZXNhbnMsIHNhbnMtc2VyaWYsICdBcHBsZSBDb2xvciBFbW9qaScsICdT ZWdvZSBVSSBFbW9qaScsICdTZWdvZSBVSSBTeW1ib2wnOyI+DQpUaG91Z2h0cz88YnIgc3R5bGU9 ImJveC1zaXppbmc6IGJvcmRlci1ib3g7Ij4NCj09PT09U1RPUD09PT09PC9wPg0KPHAgc3R5bGU9 ImJveC1zaXppbmc6IGJvcmRlci1ib3g7IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTog MTZweDsgY29sb3I6IHJnYig1MSwgNTEsIDUxKTsgZm9udC1mYW1pbHk6ICdIZWx2ZXRpY2EgTmV1 ZScsIEhlbHZldGljYSwgJ1NlZ29lIFVJJywgQXJpYWwsIGZyZWVzYW5zLCBzYW5zLXNlcmlmLCAn QXBwbGUgQ29sb3IgRW1vamknLCAnU2Vnb2UgVUkgRW1vamknLCAnU2Vnb2UgVUkgU3ltYm9sJzsi Pg0KSW4gdGhlIGRpc2N1c3Npb24gb24gdGhpcyBzbGlkZSwgSmVmZiBIYWFzIG5vdGVkIHRoYXQg UEtDUyM5IGlzIHBvcHVsYXIgaW4gdGhlIElFVEYgYW5kIHRoYXQgaGUgZmVsdCB0aGF0IGNhbm9u aWNhbGl6YXRpb24gbWlnaHQgYmUgYSByZXF1aXJlbWVudC4gQnV0IEtlbnQgbm90ZWQgdGhhdCBj YW5vbmljYWxpemF0aW9uIGlzIHByYWN0aWNhbGx5IGltcG9zc2libGUgZ2l2ZW4gdGhhdCBYTUwv SlNPTiBoYXMgbm8gZ3VhcmFudGVlZCBvcmRlcmluZw0KIG9mIHRyZWUgbm9kZXMuPC9wPg0KPHAg c3R5bGU9ImJveC1zaXppbmc6IGJvcmRlci1ib3g7IG1hcmdpbi10b3A6IDBweDsgY29sb3I6IHJn Yig1MSwgNTEsIDUxKTsgZm9udC1mYW1pbHk6ICdIZWx2ZXRpY2EgTmV1ZScsIEhlbHZldGljYSwg J1NlZ29lIFVJJywgQXJpYWwsIGZyZWVzYW5zLCBzYW5zLXNlcmlmLCAnQXBwbGUgQ29sb3IgRW1v amknLCAnU2Vnb2UgVUkgRW1vamknLCAnU2Vnb2UgVUkgU3ltYm9sJzsgbWFyZ2luLWJvdHRvbTog MHB4ICFpbXBvcnRhbnQ7Ij4NCkkgZG9uJ3QgdGhpbmsgd2UgaGF2ZSBhIGdvb2Qgc29sdXRpb24g eWV0Li4uPC9wPg0KPHAgc3R5bGU9ImJveC1zaXppbmc6IGJvcmRlci1ib3g7IG1hcmdpbi10b3A6 IDBweDsgY29sb3I6IHJnYig1MSwgNTEsIDUxKTsgZm9udC1mYW1pbHk6ICdIZWx2ZXRpY2EgTmV1 ZScsIEhlbHZldGljYSwgJ1NlZ29lIFVJJywgQXJpYWwsIGZyZWVzYW5zLCBzYW5zLXNlcmlmLCAn QXBwbGUgQ29sb3IgRW1vamknLCAnU2Vnb2UgVUkgRW1vamknLCAnU2Vnb2UgVUkgU3ltYm9sJzsg bWFyZ2luLWJvdHRvbTogMHB4ICFpbXBvcnRhbnQ7Ij4NCjxicj4NCjwvcD4NCjxwIHN0eWxlPSJi b3gtc2l6aW5nOiBib3JkZXItYm94OyBtYXJnaW4tdG9wOiAwcHg7IGNvbG9yOiByZ2IoNTEsIDUx LCA1MSk7IGZvbnQtZmFtaWx5OiAnSGVsdmV0aWNhIE5ldWUnLCBIZWx2ZXRpY2EsICdTZWdvZSBV SScsIEFyaWFsLCBmcmVlc2Fucywgc2Fucy1zZXJpZiwgJ0FwcGxlIENvbG9yIEVtb2ppJywgJ1Nl Z29lIFVJIEVtb2ppJywgJ1NlZ29lIFVJIFN5bWJvbCc7IG1hcmdpbi1ib3R0b206IDBweCAhaW1w b3J0YW50OyI+DQo8YnI+DQo8L3A+DQo8cCBzdHlsZT0iYm94LXNpemluZzogYm9yZGVyLWJveDsg bWFyZ2luLXRvcDogMHB4OyBjb2xvcjogcmdiKDUxLCA1MSwgNTEpOyBmb250LWZhbWlseTogJ0hl bHZldGljYSBOZXVlJywgSGVsdmV0aWNhLCAnU2Vnb2UgVUknLCBBcmlhbCwgZnJlZXNhbnMsIHNh bnMtc2VyaWYsICdBcHBsZSBDb2xvciBFbW9qaScsICdTZWdvZSBVSSBFbW9qaScsICdTZWdvZSBV SSBTeW1ib2wnOyBtYXJnaW4tYm90dG9tOiAwcHggIWltcG9ydGFudDsiPg0KS2VudDwvcD4NCjxw IHN0eWxlPSJib3gtc2l6aW5nOiBib3JkZXItYm94OyBtYXJnaW4tdG9wOiAwcHg7IGNvbG9yOiBy Z2IoNTEsIDUxLCA1MSk7IGZvbnQtZmFtaWx5OiAnSGVsdmV0aWNhIE5ldWUnLCBIZWx2ZXRpY2Es ICdTZWdvZSBVSScsIEFyaWFsLCBmcmVlc2Fucywgc2Fucy1zZXJpZiwgJ0FwcGxlIENvbG9yIEVt b2ppJywgJ1NlZ29lIFVJIEVtb2ppJywgJ1NlZ29lIFVJIFN5bWJvbCc7IG1hcmdpbi1ib3R0b206 IDBweCAhaW1wb3J0YW50OyI+DQo8YnI+DQo8L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGlkPSJN QUNfT1VUTE9PS19TSUdOQVRVUkUiPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_EF803F0EC1CA43F6AB17EE2E10B6DB13junipernet_-- From nobody Wed May 11 16:41:21 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A1312D831 for ; Wed, 11 May 2016 16:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RzH-z5YO7CLc for ; Wed, 11 May 2016 16:41:18 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0148.outbound.protection.outlook.com [65.55.169.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5215312D82C for ; Wed, 11 May 2016 16:41:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=V7YzHPaQsd1hvAUeY1Q+96a+5cHa0nxbgjYQRaaOc0w=; b=aoIDcTA0L5NA+W6zGL9l/1LMbsdwxhJkI1T34g66zfEQ2j0U47kvZg+zhF+5v4ZRFokFvIZsyoD9G3M2L6PsntBIXf97yO/nEX2sFLzEZsf3GPdGy7XRVtQ5QPFoMO5HfmWbtcGROSWA0S0MHXshAp9E503jeEgZLO0Nr88YcU8= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) with Microsoft SMTP Server (TLS) id 15.1.492.11; Wed, 11 May 2016 23:41:14 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0492.016; Wed, 11 May 2016 23:41:14 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: zerotouch/14: Removable storage details? Thread-Index: AQHRq96aoeOBJizsz0Suy3PZsyqGQA== Date: Wed, 11 May 2016 23:41:13 +0000 Message-ID: <633A61C1-905D-4C4E-98D6-4C864FD752A7@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.15.1.160411 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.10] x-ms-office365-filtering-correlation-id: e7fb552f-8275-4d8d-5622-08d379f5bd68 x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 5:aXWoFkZGZvnhbPUUtqiUQ79GAqjRVzoqSXh6rQsO+WwZMasbaBjI/Ttz2aJbhXpTBaCXX103B9hn7MsZ2ExjOMUgJkXpsRcswhamjCjyJH9z3JFHEkVoNIWm+Iihjl/wQ1aWHyBJNjiZ5Z3/DzluOA==; 24:JJ+lltF1l4euQrEAZhhrmRgcLDLvzZR/QHVwDyGVuLjMsZ/tMSX88gri9UNComIguxeePHRGQTbkOLohtQZEckm3sfYQLSQ752v+/9JcwSk=; 7:UTgxmsn+ZLTX4M4LCFx/BN//EgdU405GXkHwvZnOCiP31oOCjKgb/WVCZSJD+pfTMj2J9r+V9LEgriIRsecVAvI1GKOBZ6rqaGOxLhkcA+obb0IcOBjhWSc3yC/nXZxpZ/2aelmKJpjDH+WYKHPtXJTXVUHNK6Q521ZdVujCaal5NeqAlKzumFh6eXRVSkmQ x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 0939529DE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51444003)(450100001)(87936001)(106116001)(33656002)(8936002)(81166006)(5004730100002)(10400500002)(86362001)(83506001)(77096005)(107886002)(19580395003)(4001350100001)(66066001)(99286002)(110136002)(3280700002)(5640700001)(16236675004)(15975445007)(2501003)(189998001)(2900100001)(2906002)(3660700001)(11100500001)(5002640100001)(102836003)(54356999)(5008740100001)(50986999)(2351001)(6116002)(586003)(3846002)(1220700001)(36756003)(122556002)(229853001)(92566002)(83716003)(82746002)(1730700003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_633A61C1905D4C4E98D64C864FD752A7junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 11 May 2016 23:41:13.9333 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1442 Archived-At: Subject: [Netconf] zerotouch/14: Removable storage details? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 23:41:20 -0000 --_000_633A61C1905D4C4E98D64C864FD752A7junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 aHR0cHM6Ly9naXRodWIuY29tL25ldGNvbmYtd2cvemVyby10b3VjaC9pc3N1ZXMvMTQNCg0KVGhl IGN1cnJlbnQgZHJhZnQgc2F5czogIkRldGFpbHMgc3VjaCBhcyB0aGUgZm9ybWF0IG9mIGZpbGUg c3lzdGVtIGFuZCB0aGUgbmFtaW5nIG9mIHRoZSBmaWxlcyBhcmUgbGVmdCB0byB0aGUgZGV2aWNl J3MgbWFudWZhY3R1cmVyIHRvIGRlZmluZSIsICBidXQgYW4gb24tbGlzdCByZXZpZXcgcmVjb21t ZW5kcyB0aGF0IHRoZSBkcmFmdCBiZSBtb3JlIG5vcm1hdGl2ZSBhYm91dCB0aGlzLg0KDQpUaGUg YWJvdmUgaXMgZXNzZW50aWFsbHkgc2xpZGUgIzEyIGZyb20gdGhlIElFVEYgOTUgcHJlc2VudGF0 aW9uLiAgVGhlIG1pbnV0ZXMgdGhlbiBjYXB0dXJlIHRoZSBmb2xsb3dpbmcgZGlhbG9nOg0KDQog IC0gSkg6IHN0b3JhZ2UgZm9ybWF0cyBoYXZlIGNoYW5nZWQgaW1tZW5zZWx5IG92ZXIgdGhlIHll YXJzLiAgRml4aW5nIHRoZW0gaW4gdGhlIG1vZGVsIHdpbGwgbGlrZWx5IGp1c3QgbWFrZSB0aGUg bW9kZWwgb2JzZWxldGUgcXVpY2tseSAuIE1heWJlIGEgcmVnaXN0cnkgPw0KICAtIEtXOiBXaGF0 IHdvdWxkIGJlIHRoZSBtb3RpdmF0aW9uPw0KICAtIE1DUjogTm90IHRoYXQgd2UgZGVmaW5lIHRo ZW0sIHdlIHNob3VsZCBqdXN0IHJlZmVyIHRvIHRoZW0uDQogIC0gUlQ6IHdoYXQgYXJlIHdlIHRy eWluZyB0byBhY2hpZXZlIGhlcmUgPyAgSnVzdCBiYXNpYyBib290aW5nID8gIG9yIG1vcmUgPw0K DQpJIHRoaW5rIHRoYXQgdGhlcmUgd2FzL2lzIGEgZnVuZGFtZW50YWwgbWlzdW5kZXJzdGFuZGlu Zy4gIFdlJ3JlIG5vdCBoZXJlIGRpc2N1c3NpbmcgdGhlIGZvcm1hdCBvZiB0aGUgZmlsZXN5c3Rl bSBmb3IgdGhlIGRldmljZSBpdHNlbGYsIHRoYXQgaXMgY29tcGxldGVseSBvdXQgb2Ygc2NvcGUu ICBJbnN0ZWFkLCB3ZSdyZSBqdXN0IGRpc2N1c3NpbmcgdGhlIGZvcm1hdCBvZiB0aGUgZmlsZXN5 c3RlbSBmb3IgdGhlIHJlbW92YWJsZSBzdG9yYWdlIGRldmljZSAoZS5nLiwgYSBVU0IgZmxhc2gg ZHJpdmUpLCBhbmQvb3IgdGhlIG5hbWVzIG9mIHRoZSBmaWxlcyB0aGF0IHRoZSBkZXZpY2UgbWln aHQgbG9vayBmb3Igb24gdGhlIHN0b3JhZ2UgZGV2aWNlLg0KDQpNeSB2aWV3IGlzIHRoYXQgd2Ug c2hvdWxkIGxldCBlYWNoIHZlbmRvciBkZWNpZGUgZm9yIHRoZW1zZWx2ZXMuICBJZiB0aGV5IHdh bnQgdG8gc3VwcG9ydCBleHQzLCBtc2RvcywgbnRmcywgaGZmKywgb3Igd2hhdGV2ZXIgLSBpdCdz IHVwIHRvIHRoZW0gdG8gZGVjaWRlLiBGdXJ0aGVyLCB0aGV5IHNob3VsZCBiZSBhbGxvd2VkIHRv IGRlZmluZSB0aGUgZmlsZSBuYW1lcyBhbmQgZm9ybWF0cyBhcyB3ZWxsLiAgIE15IHRob3VnaHQg aXRzIHRoYXQgdGhlcmUgaXMgbGl0dGxlIG5lZWQgdG8gcGx1ZyBhIHNwZWNpZmljIHJlbW92YWJs ZSBzdG9yYWdlIGRldmljZSBpbnN0YW5jZSBpbnRvIG1vcmUgdGhhbiBvbmUgZGV2aWNlLCB0aHVz IHRoZSBtdWx0aS12ZW5kb3IgYXNwZWN0IG9mIHRoaXMgaXQgbm90IHZlcnkgc3Ryb25nLCBhbmQg c28gd2Ugc2hvdWxkIGRlY2xhcmUgaXQgYXMgb3V0LW9mLXNjb3BlLg0KDQpUaG91Z2h0cz8NCg0K S2VudA0KDQoNCg0K --_000_633A61C1905D4C4E98D64C864FD752A7junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj5odHRwczovL2dpdGh1Yi5jb20vbmV0Y29uZi13Zy96ZXJvLXRvdWNoL2lzc3Vl cy8xNDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhlIGN1cnJlbnQgZHJhZnQgc2F5 czogJnF1b3Q7RGV0YWlscyBzdWNoIGFzIHRoZSBmb3JtYXQgb2YgZmlsZSBzeXN0ZW0gYW5kIHRo ZSBuYW1pbmcgb2YgdGhlIGZpbGVzIGFyZSBsZWZ0IHRvIHRoZSBkZXZpY2UncyBtYW51ZmFjdHVy ZXIgdG8gZGVmaW5lJnF1b3Q7LCAmbmJzcDtidXQgYW4gb24tbGlzdCByZXZpZXcgcmVjb21tZW5k cyB0aGF0IHRoZSBkcmFmdCBiZSBtb3JlIG5vcm1hdGl2ZSBhYm91dCB0aGlzLiZuYnNwOzwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhlIGFib3ZlIGlzIGVzc2VudGlhbGx5IHNsaWRl ICMxMiBmcm9tIHRoZSBJRVRGIDk1IHByZXNlbnRhdGlvbi4gJm5ic3A7VGhlIG1pbnV0ZXMgdGhl biBjYXB0dXJlIHRoZSBmb2xsb3dpbmcgZGlhbG9nOjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+Jm5ic3A7IC0gSkg6IHN0b3JhZ2UgZm9ybWF0cyBoYXZlIGNoYW5nZWQgaW1tZW5zZWx5 IG92ZXIgdGhlIHllYXJzLiAmbmJzcDtGaXhpbmcgdGhlbSBpbiB0aGUgbW9kZWwgd2lsbCBsaWtl bHkganVzdCBtYWtlIHRoZSBtb2RlbCBvYnNlbGV0ZSBxdWlja2x5IC4gTWF5YmUgYSByZWdpc3Ry eSA/PC9kaXY+DQo8ZGl2PiZuYnNwOyAtIEtXOiBXaGF0IHdvdWxkIGJlIHRoZSBtb3RpdmF0aW9u PyZuYnNwOzwvZGl2Pg0KPGRpdj4mbmJzcDsgLSBNQ1I6IE5vdCB0aGF0IHdlIGRlZmluZSB0aGVt LCB3ZSBzaG91bGQganVzdCByZWZlciB0byB0aGVtLjwvZGl2Pg0KPGRpdj4mbmJzcDsgLSBSVDog d2hhdCBhcmUgd2UgdHJ5aW5nIHRvIGFjaGlldmUgaGVyZSA/ICZuYnNwO0p1c3QgYmFzaWMgYm9v dGluZyA/ICZuYnNwO29yIG1vcmUgPzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SSB0 aGluayB0aGF0IHRoZXJlIHdhcy9pcyBhIGZ1bmRhbWVudGFsIG1pc3VuZGVyc3RhbmRpbmcuICZu YnNwO1dlJ3JlIG5vdCBoZXJlIGRpc2N1c3NpbmcgdGhlIGZvcm1hdCBvZiB0aGUgZmlsZXN5c3Rl bSBmb3IgdGhlIGRldmljZSBpdHNlbGYsIHRoYXQgaXMgY29tcGxldGVseSBvdXQgb2Ygc2NvcGUu ICZuYnNwO0luc3RlYWQsIHdlJ3JlIGp1c3QgZGlzY3Vzc2luZyB0aGUgZm9ybWF0IG9mIHRoZSBm aWxlc3lzdGVtIGZvciB0aGUgcmVtb3ZhYmxlIHN0b3JhZ2UNCiBkZXZpY2UgKGUuZy4sIGEgVVNC IGZsYXNoIGRyaXZlKSwgYW5kL29yIHRoZSBuYW1lcyBvZiB0aGUgZmlsZXMgdGhhdCB0aGUgZGV2 aWNlIG1pZ2h0IGxvb2sgZm9yIG9uIHRoZSBzdG9yYWdlIGRldmljZS48L2Rpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8ZGl2Pk15IHZpZXcgaXMgdGhhdCB3ZSBzaG91bGQgbGV0IGVhY2ggdmVuZG9y IGRlY2lkZSBmb3IgdGhlbXNlbHZlcy4gJm5ic3A7SWYgdGhleSB3YW50IHRvIHN1cHBvcnQgZXh0 MywgbXNkb3MsIG50ZnMsIGhmZiYjNDM7LCBvciB3aGF0ZXZlciAtIGl0J3MgdXAgdG8gdGhlbSB0 byBkZWNpZGUuIEZ1cnRoZXIsIHRoZXkgc2hvdWxkIGJlIGFsbG93ZWQgdG8gZGVmaW5lIHRoZSBm aWxlIG5hbWVzIGFuZCBmb3JtYXRzIGFzIHdlbGwuICZuYnNwOyBNeSB0aG91Z2h0IGl0cyB0aGF0 DQogdGhlcmUgaXMgbGl0dGxlIG5lZWQgdG8gcGx1ZyBhIHNwZWNpZmljIHJlbW92YWJsZSBzdG9y YWdlIGRldmljZSBpbnN0YW5jZSBpbnRvIG1vcmUgdGhhbiBvbmUgZGV2aWNlLCB0aHVzIHRoZSBt dWx0aS12ZW5kb3IgYXNwZWN0IG9mIHRoaXMgaXQgbm90IHZlcnkgc3Ryb25nLCBhbmQgc28gd2Ug c2hvdWxkIGRlY2xhcmUgaXQgYXMgb3V0LW9mLXNjb3BlLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+VGhvdWdodHM/PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5LZW50PC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBpZD0iTUFDX09VVExPT0tf U0lHTkFUVVJFIj48L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_633A61C1905D4C4E98D64C864FD752A7junipernet_-- From nobody Wed May 11 22:55:32 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0456612D5DB for ; Wed, 11 May 2016 22:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6w0F9Ni3EWyT for ; Wed, 11 May 2016 22:55:28 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D8F612D551 for ; Wed, 11 May 2016 22:55:27 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 953A48DD; Thu, 12 May 2016 07:55:25 +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 WFV2jKx-B3M4; Thu, 12 May 2016 07:55:09 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 12 May 2016 07:55:24 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8E7CD2004E; Thu, 12 May 2016 07:55:24 +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 FMBx242Yw3Ow; Thu, 12 May 2016 07:55:23 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5D83A20047; Thu, 12 May 2016 07:55:23 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 43D1A3AD0E5F; Thu, 12 May 2016 07:55:21 +0200 (CEST) Date: Thu, 12 May 2016 07:55:21 +0200 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20160512055519.GA54966@elstar.local> Mail-Followup-To: Kent Watsen , "netconf@ietf.org" References: <633A61C1-905D-4C4E-98D6-4C864FD752A7@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <633A61C1-905D-4C4E-98D6-4C864FD752A7@juniper.net> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] zerotouch/14: Removable storage details? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 05:55:31 -0000 On Wed, May 11, 2016 at 11:41:13PM +0000, Kent Watsen wrote: > https://github.com/netconf-wg/zero-touch/issues/14 > > The current draft says: "Details such as the format of file system and the naming of the files are left to the device's manufacturer to define", but an on-list review recommends that the draft be more normative about this. > > The above is essentially slide #12 from the IETF 95 presentation. The minutes then capture the following dialog: > > - JH: storage formats have changed immensely over the years. Fixing them in the model will likely just make the model obselete quickly . Maybe a registry ? > - KW: What would be the motivation? > - MCR: Not that we define them, we should just refer to them. > - RT: what are we trying to achieve here ? Just basic booting ? or more ? > > I think that there was/is a fundamental misunderstanding. We're not here discussing the format of the filesystem for the device itself, that is completely out of scope. Instead, we're just discussing the format of the filesystem for the removable storage device (e.g., a USB flash drive), and/or the names of the files that the device might look for on the storage device. > > My view is that we should let each vendor decide for themselves. If they want to support ext3, msdos, ntfs, hff+, or whatever - it's up to them to decide. Further, they should be allowed to define the file names and formats as well. My thought its that there is little need to plug a specific removable storage device instance into more than one device, thus the multi-vendor aspect of this it not very strong, and so we should declare it as out-of-scope. > I think it is useful to have a format that is readable and writable by 'regular' computers; if vendors start to produce storage sticks that can't be read or copied using 'regular' computers, I would be somewhat unhappy. That said, I am not sure a standard can really prevent this from happening but giving some advice that using open formats is a good thing may be useful. (An open format may allow me to create combined boot sticks that can boot more than a single device type.) /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 May 12 06:44:00 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A47B512D12F for ; Thu, 12 May 2016 06:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cMabVlj-eAX for ; Thu, 12 May 2016 06:43:51 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0729.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56E8B12B00C for ; Thu, 12 May 2016 06:43:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=I+Un1fi7YroW2Ug2rtWO0sHrSMAR+7ytb4Jq0opmnwk=; b=d4rLZGRs8M1B1yyjjs/mpAd3p3FDYWp5DRPrEAGOxcH954NEwdmDX8LvqG6521afisaP/Fvas93Xb85eIE4G0xAXlC3j0Xw5r1Hkm0FgmEKt5VZDHVSgURTo0ApRNpR0ThxAnbaR1uEZMxE/YNduKvLrcvCJjIFU5uFf3xhf1gQ= Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (109.145.193.232) by DB5PR07MB1622.eurprd07.prod.outlook.com (10.166.12.149) with Microsoft SMTP Server (TLS) id 15.1.492.11; Thu, 12 May 2016 13:43:24 +0000 Message-ID: <00bc01d1ac53$bd3846a0$4001a8c0@gateway.2wire.net> From: t.petch To: Kent Watsen , Sean Turner References: Date: Thu, 12 May 2016 14:38:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [109.145.193.232] X-ClientProxiedBy: DB3PR05CA0047.eurprd05.prod.outlook.com (10.160.41.175) To DB5PR07MB1622.eurprd07.prod.outlook.com (10.166.12.149) X-MS-Office365-Filtering-Correlation-Id: 59b66ef3-418b-4f06-9360-08d37a6b6432 X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1622; 2:6qCu7LrIglb3Jljnv3O9J4uQ2+g4sH0KUIXXtzMtIBLae1ISIwLwpWL1N4SMrAW8ewZbYRsPdz2xkGEOuinUbv60aBu20aZgCzyJE4FLzq5QvN2o/ZeyT3ji9w0IOOFeTqjBdZJH+tHUTmCQdKMW8rHlFNk7D02MC6Ha3HolfXizVvBDOxPzWg4d/bValjou; 3:G4ZEdE1AJ5cRnxyQEtf5TJ47uJaYCUDKJ8Iaj+nDjpjWyBgI6ogHI9j830eys5zEBmVA5TEhSs2c/M8xQI/gnvrSlOBWJ+j4ifeKcq9BAR2VoHPhJUWNLMOp39/A8G/2 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR07MB1622; X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1622; 25:rAArqp3/uS39kcLpYKx+v1u9fhlqGWW8gQlqvMrMGnOtIoezuyTk43fHgGZ04VlYvDbEE/y2d/dFaZCJb2DsFqZ+xI9Nj4myVGnJ8+1ECmKW37X/zi3gUZosi/Oh+5akUYt/GGgMFoC24NKe/2Xb7qGVJAfWW8IrwNc2AFVhydy3IuB8rf0jDB0PoTQ/nHT6vFDFOW7A9W8/GbdUtwplkGV5xFNXhtB1cBGrl5BiDt63HhNm0WKpUfarTsQgzF9KU8RtTmUY0MJaSTj/9JFPib0zTlFLYtUSYe6qqF9bMg4X0q8nU+itfoQJ9/FH1O2Kd8fUGuUcSvfqscCppt3i3zt2NTQfSqCi/z63gEYd124lXh+C8fmhk2K8dqD0Ea2usU5itOFs/ud5Aa67yod5ODD18ZDt79rGdK15V1bNuNK92lw04Uu6HjwQbvVqZY9HIgCKzcgNyC0zoDJ3zN4NQ5unfa7n7Tc+hXZ1x8Z2PkYEZCz4GQjYEp8hyu3LSdJ3N8xwyQtAvK3R4QsZaF6PmhHnBcM/F3vz2yZFyEMauPbeyd8ggRJpXB6ij3Pwia2cl9I1oOtOrofJvkVkLdFyLBmrJadZYlvLuGkd1cJmfUOKbKtw2BN3VUbe2f4VrhrpuZNRPUisIvNlbgJR4i4MA6j+Kz7Yb1WKHfUllrydzAUVKIPA/FsWMocL2ot4qonhdwZjPa/mveqE990jVC85DBCDbB5+j/UWu0VbnceEiTanbFc/aE2KshwHR1wllqODAOkV2wlbR1N+S2282Ayk6rLwg2JLJC/vQvWnK67tF8IcFlpRFMI/INV5ghrj8HzV X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:DB5PR07MB1622; BCL:0; PCL:0; RULEID:; SRVR:DB5PR07MB1622; X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1622; 4:+99rJag75aTjZ9SQ08Fj2ca1aAEsP2U3IXF0PlLQFQqsGYH0QK22/ADDdiX9Xaoi8f+/tUDMZNC7jDNF6JXiUP5Sq8cDyZqonxXS06c1OWMNbYzMoVUH/qzHXG5rmpWUMQlkWjJWILY1szjSTCqEVdkr/miFOr9LUqKeTPAxg/R3CEUR8Q3aAXdAF5l1fVNjfvbp8dkfwo9k7tdRyaYekgdUJ4N0He12GzIqysc+mNw8UWz5OMqtPudEinC5F4cvI9YL4Ntd3w5K+mc9D5nkJl0XeRaTymfqpMDOZAMpuKlIo/78j2MfXnXBYf2gEdzC6Md3iVkPzkNJG2SaVxM1VWvh69NhicW8UUNsm9qAIOaoKhc5bhc2d8LbCjoaFAWX0vGyhDY9gAGe9nQ67BTWgJAaTToz23+v3rbjiFVCeFM= X-Forefront-PRVS: 0940A19703 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(13464003)(377454003)(14496001)(81816999)(66066001)(76176999)(81686999)(1456003)(5004730100002)(33646002)(92566002)(586003)(5008740100001)(3846002)(6116002)(50466002)(47776003)(19580405001)(50986999)(9686002)(86362001)(50226002)(116806002)(19580395003)(44736004)(61296003)(2906002)(62236002)(77096005)(189998001)(44716002)(23676002)(15975445007)(42186005)(230700001)(81166006)(5001770100001)(74416001)(7059030)(7726001)(4720700001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR07MB1622; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjVQUjA3TUIxNjIyOzIzOm13NWJmcEJsOEtOTW0vZ1R5eGZXWkJBcnIx?= =?utf-8?B?SGhQT2M3NXh2QWlKcURGdjNNNFVoOXp1MG5mUGpocnYxZDVTbUJSODdaMHEz?= =?utf-8?B?eWpLajZLWTIzeVgyY21yeEtodG5hZ3hSNk40Rkt0RzVqNUJ1S1MrSlRkL3FZ?= =?utf-8?B?WSttYUF4b3cwbHoyU3RUWWh1SEVDT2Z1SDhyRGZEQkZOZjJPKzBieVJyRXI0?= =?utf-8?B?VStzTzAwY29WY3dPMFRPRVdOZklsSU4vT2Y5N0tQYXF0WTdEa0gxcnNYb2tt?= =?utf-8?B?RE4zTk1ZSFBrMnVjLzJUMVhrZGlZY2VPb3crSTZGSmYvbTZEUmZ6bStPMm1U?= =?utf-8?B?YXZabVNXMU1YWjVDbWVHaDJiRDFuWFBhMW5KRVg3djF1RjR3WUgwRXdZVlgy?= =?utf-8?B?bGlUczJHejFhTzkxRkNpbEg2RExYaFFvY21yZmRlQWVpb3hTK1ZwZkR2RlFv?= =?utf-8?B?YmdiRGpIeUQ4N1A3T1h5cGJHVUxGOWdMR2N2emhPY011cGs1VWtsQ2crMWVp?= =?utf-8?B?YXJYOFRqcC81a0ttTHBVVnlvUlNmVWUwc0FNcXVTOGQvcEJZL0orVDNqOGF4?= =?utf-8?B?Ujc4M2hzSGNxMVRjbDVZNnEvd0h4Q215dkduZG5hWGJOWDQ3VFJxOFRvQ2hF?= =?utf-8?B?LzFtYThXdUY5V2tiZ2ZxcXVnN1UyYnZOeWNDY2d5MERGU1ZRcEd2dE43YzU3?= =?utf-8?B?V3Y4YVVhSFV3UWRJU0NFRzNkalJnK0NPZGNNMG5nNzZaM252Z3p2L2pSd3Rk?= =?utf-8?B?VzZBUXIzZEgrOG9BM3kyaWxSNWw4UXFUdnh6MkhoVGc3QzlhSWhJc1FWL2hq?= =?utf-8?B?Yk1zL2pUb1pZbk1jd0xNbzhRY3pQYjMram1yNUt6SktOSjFqMXg3aWxhVnpY?= =?utf-8?B?ODVoNndTVDlGNHRPYmNqVWJ5dVd4RUdOQ2xWY0R6MVo4R2J5NFRXZzlvRWlo?= =?utf-8?B?a3FLRXpRKzlzWHNoZVUyeXYwbkdRaTFpRy94blEvd0tJVE55Nm56T1F1c1R3?= =?utf-8?B?NmtwQXVkTzZzWFJhQ21NeWdSZnF0Qlhsc2Z4MmZlTGFwb0Y5cVJHS0ZDbklo?= =?utf-8?B?azEwU21oZUhUVWdBMkpEbzJxbDZTL0hGbzAzbWZCZW0zQmhHTXVpbnEvUWow?= =?utf-8?B?UXdXTWVWOFJyWTBMMHVPa2ZjUDhFdHlqRVMyZi9OMjRYV1BjTTlUYUwrYzg3?= =?utf-8?B?Z2QvWEMwK01BMTNBL2M3dG9PdDZMd3BIN1BzNzJ3aE04SDduOGJEN0ttc0I2?= =?utf-8?B?Qk9FN2VHTi96NWVKSUZXRTNYeXdaRFhoUVB4bjd2S0NqSUJGcktNNDFCaC9R?= =?utf-8?B?bUpuN3NOMkt6RkhLVUU2ZTFtYVFpd3h0RkhEMzVSak4yTUVQQUlwSEVDaUh0?= =?utf-8?B?Qm1FY0ZBZ0FjTUNIQmczMklYZXBoS1c4S003TS9RdWdIVGFwRkR5T2hVYlBj?= =?utf-8?B?ZTB2K0FKV1VTdG8welNtbUs4MGxxeGNkZWJDN1BVazBJYmRvZVJnNzljSnJ5?= =?utf-8?Q?y2ZpfCA9WxVD74c9OojZrQJ1M=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1622; 5:YiCTgzjOOCksgolNpAqoW+y3C4ve1MucIY6/yxmnsM2QKVASyx5VvRvS5Fw9R9yOaIlpZ3MIawoT9+BzIoapK/xuOg4H0ahL42rhXLfppdIVYwjs1P+2+xbj5+kjceBy6Fv6MiAkgdE7Ggi2ih1gcQ==; 24:URPyJzSTjVYA/XG7eOnltGXLUa7R63TZXXgNYijHqoRMLtuF/OY8qitdgmJiIDRaThXJ+Oy6wk8Pju8H8TpdOaFs9AQiDRuxlFhutL43TmI=; 7:C4MbbwCs6sOVHPzufszpE8ppksh0hNl93fYwV/lp1WkKsR2SUP1e9PZLBNPl/kTyiXifg0UHR8wqUnROtfoQ1Bi8je2UCF98WUn+aeJwYtMpqZTVz4GDB47HxOH1WBq569HBNDhOau83BM+fToDExzS818RUMVKL6C/f/p4LKtJPkvisIKwUY62e5fpnC6YI SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 May 2016 13:43:24.8778 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB1622 Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] netconf server-model (keychain) draft issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 13:43:59 -0000 ----- Original Message ----- From: "Kent Watsen" To: "Sean Turner" Cc: Sent: Wednesday, May 11, 2016 8:19 PM > Hi Sean, > > Thank you again for your review of the server-model draft before, primarily focusing on the keychain model. As you know, I updated the draft significantly based on your comments for 95, but one issue remains... > > The remaining issue regards 'key-usage' in the generate-private-key action listed on page 23 of https://tools.ietf.org/html/draft-ietf-netconf-server-model-09. Below is the current (incomplete) definition: > > leaf key-usage { > type enumeration { > enum signing { description "signing"; } > enum encryption { description "encryption"; } > // unclear if these should be somehow more > // specific or varied. > } > > The question is how to make this key-usage definition complete? I can do the YANG translation, but what are the possible values? Is it the case that the issue only matters when discussing TPMs, which have very distinct and specific usage profiles? As a generic keychain model, it shouldn't be specific to network management, but it would be remiss for me to not point out that, in network management, the private key seems to always have the same key usage (i.e. what's needed to establish a SSH/TLS tunnel). Thoughts? Kent sidr have defined " id-kp-bgpsec-router OBJECT IDENTIFIER ::= { id-kp 30 } A BGPsec router MUST require the extended key usage extension to be present in a BGPsec Router Certificate it receives. " and may be about to define another EKU, while IPsec IKE did dabble with EKU some time ago. Tom Petch > > Thanks, > Kent > > From nobody Mon May 16 13:33:30 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE8412D525; Mon, 16 May 2016 13:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.328 X-Spam-Level: X-Spam-Status: No, score=-108.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFXEHz82I_jW; Mon, 16 May 2016 13:33:22 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 219B212D1D7; Mon, 16 May 2016 13:33:22 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A48F6180004; Mon, 16 May 2016 13:33:13 -0700 (PDT) To: muly_i@rad.com, andy@yumaworks.com, balazs.lengyel@ericsson.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160516203313.A48F6180004@rfc-editor.org> Date: Mon, 16 May 2016 13:33:13 -0700 (PDT) Archived-At: Cc: rfc-editor@rfc-editor.org, iesg@ietf.org, netconf@ietf.org Subject: [Netconf] [Errata Verified] RFC6243 (4688) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 20:33:23 -0000 The following errata report has been verified for RFC6243, "With-defaults Capability for NETCONF". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6243&eid=4688 -------------------------------------- Status: Verified Type: Technical Reported by: Muly Ilan Date Reported: 2016-05-08 Verified by: Benoit Claise (IESG) Section: 4.5.2 Original Text ------------- If the operation attribute contains the value 'create', and the data node already exists in the target configuration datastore, then the server MUST return an response with an 'invalid-value' error-tag. Corrected Text -------------- If the operation attribute contains the value 'create', and the data node already exists in the target configuration datastore, then the server MUST return an response with an 'data-exists' error-tag. Notes ----- According to RFC6241 section 7.2 the behavior for the 'create' operation is: " If the configuration data exists, an element is returned with an value of "data-exists". " -------------------------------------- RFC6243 (draft-ietf-netconf-with-defaults-14) -------------------------------------- Title : With-defaults Capability for NETCONF Publication Date : June 2011 Author(s) : A. Bierman, B. Lengyel Category : PROPOSED STANDARD Source : Network Configuration Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Tue May 17 01:22:46 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C264B12B02D; Tue, 17 May 2016 01:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.328 X-Spam-Level: X-Spam-Status: No, score=-108.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id esC1NA4NZ4tV; Tue, 17 May 2016 01:22:44 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ECB312B00D; Tue, 17 May 2016 01:22:44 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 8E66F180004; Tue, 17 May 2016 01:22:35 -0700 (PDT) To: muly_i@rad.com, andy@yumaworks.com, balazs.lengyel@ericsson.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160517082235.8E66F180004@rfc-editor.org> Date: Tue, 17 May 2016 01:22:35 -0700 (PDT) Archived-At: Cc: rfc-editor@rfc-editor.org, iesg@ietf.org, netconf@ietf.org Subject: [Netconf] [Errata Verified] RFC6243 (4687) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 08:22:46 -0000 The following errata report has been verified for RFC6243, "With-defaults Capability for NETCONF". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6243&eid=4687 -------------------------------------- Status: Verified Type: Editorial Reported by: Muly Ilan Date Reported: 2016-05-08 Verified by: Benoit Claise (IESG) Section: A.1 Original Text ------------- typedef status-type { description "Interface status"; type enumeration { enum ok; enum 'waking up'; enum 'not feeling so good'; enum 'better check it out'; enum 'better call for help'; } default ok; } Corrected Text -------------- typedef status-type { description "Interface status"; type enumeration { enum up; enum 'waking up'; enum 'not feeling so good'; enum 'better check it out'; enum 'better call for help'; } default up; } Notes ----- The examples in appendix A use the value 'up' and not the value 'ok'. -------------------------------------- RFC6243 (draft-ietf-netconf-with-defaults-14) -------------------------------------- Title : With-defaults Capability for NETCONF Publication Date : June 2011 Author(s) : A. Bierman, B. Lengyel Category : PROPOSED STANDARD Source : Network Configuration Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Tue May 17 11:37:37 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5687112D8A9; Tue, 17 May 2016 11:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3F2eLZZKOJmO; Tue, 17 May 2016 11:37:34 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 24B8612D8E7; Tue, 17 May 2016 11:37:34 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 82E4C1E335; Tue, 17 May 2016 14:42:45 -0400 (EDT) Date: Tue, 17 May 2016 14:42:45 -0400 From: Jeffrey Haas To: Susan Hares , i2rs@ietf.org, netconf@ietf.org Message-ID: <20160517184245.GD17462@pfrc.org> References: <20160506061052.26811.37591.idtracker@ietfa.amsl.com> <000001d1a75e$6c2d7d60$44887820$@ndzh.com> <20160506074418.GB42286@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20160506074418.GB42286@elstar.local> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Netconf] [i2rs] FW: New Version Notification for draft-hares-i2rs-protocol-strawman-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 18:37:35 -0000 Jrgen, On Fri, May 06, 2016 at 09:44:18AM +0200, Juergen Schoenwaelder wrote: > I disagree with many things in the document. For example, a data model > must not detail things like > > o encoding [XML | JSON] > > o protocol [RESTCONF | NETCONF] > > o protocol-transport [ssh, tls, tcp] > > o transport-ports [ports] I believe the strawman document may be too general with regard to these items. These keywords may be appropriate for subscription/notification type model entries, especially when the subscription is intended to be directed to an end-point different than the transport connect the subscription is being requested from. The strawman should be updated to cover an example to clarify this point. > because of layering and modularity concerns and of deployment > flexibility. There are many more of these. Overall, it would help if > there were fewer documents and not so many overlapping documents. I agree that there are too many documents. The number of them has been somewhat driven by different parties pushing for analysis of requirements from different angles. As we converge on content, we should be centralizing the content. -- Jeff From nobody Tue May 17 23:10:10 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6015712B03B; Tue, 17 May 2016 23:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AlGDrFrB4qlJ; Tue, 17 May 2016 23:10:07 -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 92A0712B029; Tue, 17 May 2016 23:10:06 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id COX41221; Wed, 18 May 2016 06:10:03 +0000 (GMT) Received: from SZXEML430-HUB.china.huawei.com (10.82.67.185) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 18 May 2016 07:10:02 +0100 Received: from szxeml561-mbs.china.huawei.com ([169.254.6.98]) by szxeml430-hub.china.huawei.com ([10.82.67.185]) with mapi id 14.03.0235.001; Wed, 18 May 2016 14:09:57 +0800 From: Rohit pobbathi To: netconf , "netmod@ietf.org" Thread-Topic: Conflicting usage scenario for "invalid-value" error-tag between RFC 6241 & RFC 6020 Thread-Index: AdGwy+Y03p/3Jjn0Rlaa0Z7VvPBCdg== Importance: high X-Priority: 1 Date: Wed, 18 May 2016 06:09:57 +0000 Message-ID: <2730B0D5F3302249A30EBF0DAE96D4CB44C103EA@SZXEML561-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.210.230] Content-Type: multipart/alternative; boundary="_000_2730B0D5F3302249A30EBF0DAE96D4CB44C103EASZXEML561MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.573C073C.00C8, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.6.98, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a6f2baf49f21960eaa22e5342166db6d Archived-At: Subject: [Netconf] Conflicting usage scenario for "invalid-value" error-tag between RFC 6241 & RFC 6020 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 06:10:09 -0000 --_000_2730B0D5F3302249A30EBF0DAE96D4CB44C103EASZXEML561MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have noticed a conflict in the usage of error-tag for payload parsing sce= nario between RFC 6241 & RFC 6020 RFC 6241 Appendix A. NETCONF Error List - provides the below description f= or "invalid-value" & "bad-element" error-tag: invalid-value error-type: protocol, application error-severity: error error-info: none Description: The request specifies an unacceptable value for one or more parameters. error-tag: bad-element error-type: protocol, application error-severity: error error-info: : name of the element w/ bad value Description: An element value is not correct; e.g., wrong type, out of range, pattern mismatch. RFC 6020 Section 8.3.1. Payload Parsing 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. For leaf data value mismatch in range/length/pattern there is conflict in t= he error-tag suggested by RFC 6241 & RFC 6020. Please confirm which is the right error-tag to be used in a standard Netcon= f Server implementation. Regards, Rohit Pobbathi --_000_2730B0D5F3302249A30EBF0DAE96D4CB44C103EASZXEML561MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have noticed a conflict in the usage of error-tag = for payload parsing scenario between RFC 6241 & RFC 6020

 

RFC 6241 Appendix A.  NETCONF Error List = 211; provides the below description for “invalid-value” & &= #8220;bad-element”

   error-tag:     = ;    invalid-value

   error-type:     &nb= sp; protocol, application

   error-severity: error

   error-info:     &nb= sp; none

   Description:    The request specifies an unacceptable value for one=

    &= nbsp;           &nbs= p;            or mor= e parameters.

 <= /p>

   error-tag:     = ;    bad-element

   error-type:     &nb= sp; protocol, application

   error-severity: error

   error-info:     &nb= sp;  <bad-element> : name of the element w/ bad value<= /o:p>

   Description:     An element value is not correct; e.g., wrong type,=

    &= nbsp;           &nbs= p;             = out of range, pattern mismatch.

 <= /p>

RFC 6020 Section 8.3.= 1.  Payload Parsing

   o  If = a leaf data value does not match the type constraints for the

    =   leaf, including those defined in th= e type's "range", "length", and

    &n= bsp; "pattern" properties, the server MUST reply with an

    &n= bsp; "invalid-value" error-tag= in the rpc-error, and with the error-

    =   app-tag and error-message associated with the constraint, if any

    =   exist.

 =

For leaf data value mism= atch in range/length/pattern there is conflict in the error-tag suggested b= y RFC 6241 & RFC 6020.

 =

Please confirm which is = the right error-tag to be used in a standard Netconf Server implementation.=

 =

Regards,

Rohit Pobbathi

--_000_2730B0D5F3302249A30EBF0DAE96D4CB44C103EASZXEML561MBSchi_-- From nobody Wed May 18 10:14:24 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7894B12D5E3 for ; Wed, 18 May 2016 10:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWamHSFVoHyB for ; Wed, 18 May 2016 10:14:21 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBE1812D5A9 for ; Wed, 18 May 2016 10:14:21 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id y69so20425258pfb.1 for ; Wed, 18 May 2016 10:14:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:message-id:date:to:mime-version; bh=tajU20OvU5QYohfnfFaaxv4moIjMKblbcH64cLcYAeg=; b=YVioFu/XgD/jX27m9rGbJJ8N521BnSA63ryfBnlsQErxKt8HMNBu03NEH064TZb24z enYuaCVyJALoSfnlSFiE+MM0Bzyl7BSsDl2a/xDGt1QrasuICnapzcmTTA3iEE/DlnPF 40ts6UIZz4Bo7tOqP9QYX3lqyrDqpu934j7o31oL1k8oGwcuMAIsNpbbHlzijpet8tnd 3mlzSjl/I365pFV7dyBq/JxH7ld4KKLay/pHIQLP35P2lL3XqCuyaxCvwierLX0Q5ryy fk140aNCMC9CJcYvH1OYHg+sscN7ryUyvFdDPAKUZsOUGLngkEmHDvr2bt6z1xARy5iY URbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:message-id:date:to:mime-version; bh=tajU20OvU5QYohfnfFaaxv4moIjMKblbcH64cLcYAeg=; b=nLqGwwhFv7nRIYC2YaT/enY1brYkA1QRJIA4fu/QUED9yRVZOevsLZDaTP+0ayGiaf K5MaEjHLQzZVhIsTeoLU9eAG07NXrAi7gLaWX0C181OV6ajc2ElO1cvWxuiJXsRPWSUD YcUuwCAM+zWTTwduSwsPlLcRlehUo02NG3Y/kc0xvsvMJvsMnoTKPrt/Yc5eQWDHAlSx cTZrT/7NP9Qa5mvrU+60P6r2MvItRBuPjtQaQ6URl0sRab6i7mXtUPK2snkWOPc1Fp88 EiEHic+3UJE/dG80sUlTuaEBLpdBYAvEB64EqfVmxIsgiH51+2Z1++OBBTVYVGs1nUXD ofQQ== X-Gm-Message-State: AOPr4FWLLlRT7FUK+03JRjvReXJv3bl/V0vkQHuI5JlhldwQq0rNXRDLMXIT3ni2RXqJ9A== X-Received: by 10.98.0.9 with SMTP id 9mr12389485pfa.19.1463591661153; Wed, 18 May 2016 10:14:21 -0700 (PDT) Received: from mahesh-m-62at.attlocal.net ([2602:306:cf77:df90:a43f:1e7c:9062:9406]) by smtp.gmail.com with ESMTPSA id w27sm13633153pfi.24.2016.05.18.10.14.18 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 May 2016 10:14:19 -0700 (PDT) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_C3DC2E85-0C71-47B2-91B8-D4EF113665A8" Message-Id: <7548C9B2-1AD6-49DB-A2E3-B5EAC01B5543@gmail.com> Date: Wed, 18 May 2016 10:14:17 -0700 To: Netconf Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [Netconf] Notes and meeting material from interim meeting X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 17:14:23 -0000 --Apple-Mail=_C3DC2E85-0C71-47B2-91B8-D4EF113665A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii First of all, a big thanks to Sue for taking some very diligent notes = today.=20 The notes from the interim meeting are captured on the Etherpad link = below. Contributors, please edit/add comments to the notes that Sue = took. The deadline for making the changes is till May 25th. http://etherpad.tools.ietf.org:9000/p/netconf-may-18-2016-interim = The chairs will use the notes to drive any action items. The meeting materials page for some reason is showing a broken link and = there is a case open to address it. For now use the following links to = access the meeting materials. = https://www.ietf.org/proceedings/interim/2016/05/18/netconf/slides/slides-= interim-2016-netconf-1-1.pdf = = https://www.ietf.org/proceedings/interim/2016/05/18/netconf/slides/slides-= interim-2016-netconf-1-2.pdf = = https://www.ietf.org/proceedings/interim/2016/05/18/netconf/slides/slides-= interim-2016-netconf-1-3.pdf = = https://www.ietf.org/proceedings/interim/2016/05/18/netconf/slides/slides-= interim-2016-netconf-1-4.pdf = Mahesh & Mehmet (as co-chair) --Apple-Mail=_C3DC2E85-0C71-47B2-91B8-D4EF113665A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii First of all, a big thanks to Sue for taking some very = diligent notes today. 

The notes from the interim meeting are captured on the = Etherpad link below. Contributors, please edit/add comments to the notes = that Sue took. The deadline for making the changes is till May 25th.

http://etherpad.tools.ietf.org:9000/p/netconf-may-18-2016-inter= im

The = chairs will use the notes to drive any action items.

The meeting materials = page for some reason is showing a broken link and there is a case open = to address it. For now use the following links to access the meeting = materials.

https://www.ietf.org/proceedings/interim/2016/05/18/netconf/sli= des/slides-interim-2016-netconf-1-1.pdf
https://www.ietf.org/proceedings/interim/2016/05/18/netconf/sli= des/slides-interim-2016-netconf-1-2.pdf
https://www.ietf.org/proceedings/interim/2016/05/18/netconf/sli= des/slides-interim-2016-netconf-1-3.pdf
https://www.ietf.org/proceedings/interim/2016/05/18/netconf/sli= des/slides-interim-2016-netconf-1-4.pdf

Mahesh & Mehmet
(as = co-chair)





= --Apple-Mail=_C3DC2E85-0C71-47B2-91B8-D4EF113665A8-- From nobody Wed May 18 13:03:10 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3BED12D669 for ; Wed, 18 May 2016 13:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.945 X-Spam-Level: X-Spam-Status: No, score=-15.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CurRc2oB_9kl for ; Wed, 18 May 2016 13:03:07 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 416BD12D0BF for ; Wed, 18 May 2016 13:03:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9224; q=dns/txt; s=iport; t=1463601786; x=1464811386; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=foq7uzar8hmEk/1rMDtRD2jgZjkH+LwAc5cdehSR8Og=; b=HT72TzQVUcAn+P+S8Op4BYA7Y0FxiPX4xp7TNSOqdbGtAYCnWBHzN9R1 jqIpUGyMUNVyclr5zoDUNGtQZ0fasf4Ls3MFJ6e8Ms28R1ut0dh78ruPM WCWOLPChIqqa8HC87MtHK3LYp0MmoOu6DDNo8WLZYKgBLumScikISWTzj 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DHAgASyjxX/4sNJK1egmxLVn4GhUKvO?= =?us-ascii?q?oR5AQ2BdSSEFXkVSgKBQzgUAQEBAQEBAWUnhEIBAQECAi1cAgEIDgcxMiUCBAE?= =?us-ascii?q?aiCcOxCcBAQEBAQEBAQEBAQEBAQEBAQEBAQEchiWETYoYBZgrAYV/iBmBcE6EA?= =?us-ascii?q?Yhij0gBDw8BAUKDbW4BhwZ/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,330,1459814400"; d="scan'208,217";a="103987261" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 May 2016 20:03:05 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u4IK34Qb028931 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 18 May 2016 20:03:05 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 18 May 2016 16:03:03 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1104.009; Wed, 18 May 2016 16:03:03 -0400 From: "Eric Voit (evoit)" To: Mahesh Jethanandani , Netconf Thread-Topic: [Netconf] Notes and meeting material from interim meeting Thread-Index: AQHRsSjICwk6NMVU3U6Psw4QP9t3WJ+++fuQ Date: Wed, 18 May 2016 20:03:03 +0000 Message-ID: <894d155dc86e4f6ea44e02efa7ba543a@XCH-RTP-013.cisco.com> References: <7548C9B2-1AD6-49DB-A2E3-B5EAC01B5543@gmail.com> In-Reply-To: <7548C9B2-1AD6-49DB-A2E3-B5EAC01B5543@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.228] Content-Type: multipart/alternative; boundary="_000_894d155dc86e4f6ea44e02efa7ba543aXCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] Notes and meeting material from interim meeting X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 20:03:09 -0000 --_000_894d155dc86e4f6ea44e02efa7ba543aXCHRTP013ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Per today's call, there is a group of potential authors working Event and Y= ANG Datastore Subscriptions. Slides defining the effort is the 2nd of Mahe= sh's links below: https://www.ietf.org/proceedings/interim/2016/05/18/netconf/slides/slides-i= nterim-2016-netconf-1-2.pdf Meeting minutes for a number of contributors meeting are at: https://github.com/netconf-wg/yang-push/wiki/Minutes If after reviewing the minutes linked above you feel there is something you= would like to contribute to this effort, please let us know. Thanks, Eric From: Netconf, May 18, 2016 1:14 PM First of all, a big thanks to Sue for taking some very diligent notes today= . The notes from the interim meeting are captured on the Etherpad link below.= Contributors, please edit/add comments to the notes that Sue took. The dea= dline for making the changes is till May 25th. http://etherpad.tools.ietf.org:9000/p/netconf-may-18-2016-interim The chairs will use the notes to drive any action items. The meeting materials page for some reason is showing a broken link and the= re is a case open to address it. For now use the following links to access = the meeting materials. https://www.ietf.org/proceedings/interim/2016/05/18/netconf/slides/slides-i= nterim-2016-netconf-1-1.pdf https://www.ietf.org/proceedings/interim/2016/05/18/netconf/slides/slides-i= nterim-2016-netconf-1-2.pdf https://www.ietf.org/proceedings/interim/2016/05/18/netconf/slides/slides-i= nterim-2016-netconf-1-3.pdf https://www.ietf.org/proceedings/interim/2016/05/18/netconf/slides/slides-i= nterim-2016-netconf-1-4.pdf Mahesh & Mehmet (as co-chair) --_000_894d155dc86e4f6ea44e02efa7ba543aXCHRTP013ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Per today’s call, t= here is a group of potential authors working Event and YANG Datastore Subsc= riptions.  Slides defining the effort is the 2nd of Mahesh’s links below:

https://www.ietf.org/proceedings/interim/2016/05/18/netconf/= slides/slides-interim-2016-netconf-1-2.pdf

 <= /p>

Meeting minutes for a num= ber of contributors meeting are at:

https://github.com/netconf-wg/yang-= push/wiki/Minutes

If after reviewing the mi= nutes linked above you feel there is something you would like to contribute= to this effort, please let us know.

 <= /p>

Thanks,
Eric

 <= /p>

From: Netconf,= May 18, 2016 1:14 PM

First of all, a big thanks to Sue for taking some ve= ry diligent notes today. 

 

The notes from the interim meeting are captured on t= he Etherpad link below. Contributors, please edit/add comments to the notes= that Sue took. The deadline for making the changes is till May 25th.<= /o:p>

 

 

The chairs will use the notes to drive any action it= ems.

 

The meeting materials page for some reason is showin= g a broken link and there is a case open to address it. For now use the fol= lowing links to access the meeting materials.

 

--_000_894d155dc86e4f6ea44e02efa7ba543aXCHRTP013ciscocom_-- From nobody Wed May 18 16:24:02 2016 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DCFDC12D73A; Wed, 18 May 2016 13:44:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Liaison Statement Management Tool To: "Benoit Claise" , =?utf-8?b?IkrDvHJnZW4gU2Now7Zud8OkbGRlciI=?= , "Joel Jaeggli" , "Tom Nadeau" , "Mahesh Jethanandani" , "Mehmet Ersue" X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160518204443.14700.50752.idtracker@ietfa.amsl.com> Date: Wed, 18 May 2016 13:44:43 -0700 Archived-At: X-Mailman-Approved-At: Wed, 18 May 2016 16:24:02 -0700 Cc: =?utf-8?q?hanandani=40gmail=2Ecom=3E=2C_=22Mehmet_Ersue=22_=3Cmehmet=2Eersu?=@ietfa.amsl.com, =?utf-8?b?PGpvZWxqYUBib2d1cy5jb20+LCAiS2VudCBXYXRzZW4iIDxrd2F0c2VuQGp1bmlw?=@ietfa.amsl.com, =?utf-8?q?choenwaelder=40jacobs-university=2Ede=3E=2C_=22Joel_Jaeggli=22_?=@ietfa.amsl.com, =?utf-8?q?rope=22_=3Cdavid=2Esinicrope=40ericsson=2Ecom=3E=2C_=22The_IETF_C?=@ietfa.amsl.com, =?utf-8?b?IiA8bmV0bW9kQGlldGYub3JnPiwgIk1haGVzaCBKZXRoYW5hbmRhbmkiIDxtamV0?=@ietfa.amsl.com, =?utf-8?b?aGFpciIgPGNoYWlyQGlldGYub3JnPiwgIkJlbm9pdCBDbGFpc2UiIDxiY2xhaXNl?=@ietfa.amsl.com, =?utf-8?b?IkxvdSBCZXJnZXIiIDxsYmVyZ2VyQGxhYm4ubmV0PiwgIkRhdmlkIFNpbmlj?=@ietfa.amsl.com, =?utf-8?b?PG5ldGNvbmZAaWV0Zi5vcmc+LCAiSsO8cmdlbiBTY2jDtm53w6RsZGVyIiA8ai5z?=@ietfa.amsl.com, =?utf-8?q?=40cisco=2Ecom=3E=2C_=22Network_Configuration_Discussion_List=22_?=@ietfa.amsl.com, =?utf-8?q?er=2Enet=3E=2C_=22NETCONF_Data_Modeling_Language_Discussion_List?=@ietfa.amsl.com, =?utf-8?b?ZUBub2tpYS5jb20+?=@ietfa.amsl.com Subject: [Netconf] New Liaison Statement, "Liaison to IETF on YANG Models to enable G.fast deployments" X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 20:44:44 -0000 Title: Liaison to IETF on YANG Models to enable G.fast deployments Submission Date: 2016-05-18 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1476/ From: "Michael Fargano" To: Benoit Claise ,Joel Jaeggli ,Mahesh Jethanandani ,Mehmet Ersue ,Jürgen Schönwälder , Tom Nadeau Cc: Joel Jaeggli ,Mahesh Jethanandani ,David Sinicrope ,Jürgen Schönwälder ,Kent Watsen ,Mehmet Ersue ,NETCONF Data Modeling Language Discussion List ,The IETF Chair ,Lou Berger ,Benoit Claise ,Network Configuration Discussion List , Response Contacts: Technical Contacts: Purpose: For information Body: The Broadband Forum is developing YANG models to meet the end 2016/early 2017 G.fast deployment timeline announced by several service providers. Broadband Forum practice is to base its YANG work on existing IETF YANG models and expertise. In the Broadband Forum meeting of 18-22 April, the Fiber to the Distribution Point (FTTdp) Work Area agreed to work on developing YANG models based on draft-entitydt-netmodentity & draft-wilton-netmod-intf-ext-yang for G.fast deployments meeting the above timelines. Given our interest in these drafts, participants will work within the IETF according to IETF processes, to help progress them. Please keep us apprised of progress of these drafts. Further, we would like to inform you that our FTTdp Work Area is defining YANG models for Broadband Forum specific context and use cases for : - forwarding/QoS and required protocols (e.g. layer 2 multicast model & DHCP) - bulk data collection (evaluating draft-ietf-netconf-yang-push and related work), - software image management, - operational states (evaluating draft-ietf-netmod-opstate-reqs and related work) Once the models reach a level of maturity we plan to share these with IETF for review and comment. Comments from IETF may be made via a liaison or BBF members may comment directly. Please see below for information on our next meetings. Sincerely, Michael Fargano, Broadband Forum Technical Committee Chair Attachments: Liaison to IETF on YANG Models to enable G.fast deployments https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2016-05-18-broadband-forum-ops-netconf-netmod-liaison-to-ietf-on-yang-models-to-enable-gfast-deployments-attachment-1.pdf From nobody Thu May 19 02:01:21 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F39E212D138 for ; Thu, 19 May 2016 02:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pka5dpRFlIHw for ; Thu, 19 May 2016 02:01:13 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DED312D0F6 for ; Thu, 19 May 2016 02:01:13 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-af-573d80d7e211 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 50.15.12926.7D08D375; Thu, 19 May 2016 11:01:11 +0200 (CEST) Received: from [159.107.198.21] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.86) with Microsoft SMTP Server id 14.3.248.2; Thu, 19 May 2016 11:01:00 +0200 To: "netconf@ietf.org" References: <20160407.211618.713559915962370737.mbj@tail-f.com> <5955a6d8c3c349d89df9bea9d9d400b0@XCH-RTP-001.cisco.com> <20160408.083656.300674541946534958.mbj@tail-f.com> From: Balazs Lengyel Message-ID: <7711f8d0-b1ea-da04-d811-837fa7064fd9@ericsson.com> Date: Thu, 19 May 2016 11:00:59 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBLMWRmVeSWpSXmKPExsUyM+Jvje71Bttwg51TDC2mbrrN6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujOZHmgVPBCu2vvvH1MB4ibeLkYNDQsBEYsourS5GTiBTTOLC vfVsXYxcHEICRxklbnd9ZIFw1jBKzP/9lBmkSlhAXeLX3ausILaIgKZE46wPrBBFrxklJt9f wAaSYBMwkpjaf54FZAOvgL3E6T4TEJNFQFVi+XlfkApRgRiJ7V2T2UFsXgFBiZMzn7CA2JwC rhL7554Cs5kF9CWu37nPCmHLSzRvnQ12gpCAhsTDC39ZJzAKzELSPgtJyywkLQsYmVcxihan FiflphsZ66UWZSYXF+fn6eWllmxiBIbfwS2/VXcwXn7jeIhRgINRiYdXQc42XIg1say4MvcQ owQHs5IIb341UIg3JbGyKrUoP76oNCe1+BCjNAeLkjiv/0vFcCGB9MSS1OzU1ILUIpgsEwen VANj0rQv0iH2jOlXFJovR0oK63ofM//jLJ3UYvZknwJn37Ur3S1VayeKMW3Wzkx2ObhzdkLV /MmvxZhyWFd59N4/e5xha/lZf04RnvMPD65X3V4jFVp6VuDiQ0vhkmle91+3ddeb/ov8K5O9 bLbSI6k3Ikf1ZmT+3Sl485UV/w7rx037Wf2kQ3OVWIozEg21mIuKEwF9D9ekOwIAAA== Archived-At: Subject: Re: [Netconf] yang push drafts X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 09:01:20 -0000

Hello Eric,

As indicated on yesterdays interim meeting, we have some issues with the yang-push draft

1) Implementing yang-push for every data bit e.g. counters will make it difficult for some of our nodes to implement yang-push. I propose to have a yang-extension "not-notifiable" that indicates that for a specific data-node datastore change notifications will not be sent. An alternative could be to define streams that filter out fast changing data-nodes like counters. However how do we know from the model which data nodes are counters and which are slow changing state data for which notifications are needed: to solve this I think a yang-extension would be good.

2) If I have an on-change subscription and I loose some notifications it is much cheaper to somehow playback those notifications than to get the full datastore (or subtree). We would need a replay capability to get the lost notifications. This also implies the need for a way to detect st notifications. I concur with Juergen that a sequence number for the notifications would be good.

3) For an on-change subscription in some cases (e.g. reload, upgrade, etc.) there are so many changes that instead of sending them all, it would be better to :
- the node suspends change notifications
- the node sends a special notification change-notifications-lost or resynchronization-proposed. This would allow the client to re-synchronize, read the datastore with a get operation.
As an example, there is no sense sending individual changes when 70% of the datastore changed.

Opinions?

regards Balazs
-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
From nobody Thu May 19 02:15:36 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73AC012D0A9 for ; Thu, 19 May 2016 02:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58scgFY2QfHe for ; Thu, 19 May 2016 02:15: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 BCB0C12B00A for ; Thu, 19 May 2016 02:15:33 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 866BF11A5; Thu, 19 May 2016 11:15:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id u-X1QTjfIbqV; Thu, 19 May 2016 11:15:15 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 19 May 2016 11:15:31 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 674CA20289; Thu, 19 May 2016 11:15:31 +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 xUpGfyV8Ypoh; Thu, 19 May 2016 11:15:29 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4EEC42034E; Thu, 19 May 2016 11:15:29 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8564B3AD9FF8; Thu, 19 May 2016 11:15:28 +0200 (CEST) Date: Thu, 19 May 2016 11:15:28 +0200 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20160519091528.GA1736@elstar.local> Mail-Followup-To: Balazs Lengyel , "netconf@ietf.org" References: <20160407.211618.713559915962370737.mbj@tail-f.com> <5955a6d8c3c349d89df9bea9d9d400b0@XCH-RTP-001.cisco.com> <20160408.083656.300674541946534958.mbj@tail-f.com> <7711f8d0-b1ea-da04-d811-837fa7064fd9@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7711f8d0-b1ea-da04-d811-837fa7064fd9@ericsson.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] yang push drafts X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 09:15:35 -0000 On Thu, May 19, 2016 at 11:00:59AM +0200, Balazs Lengyel wrote: > > 1) Implementing yang-push for every data bit e.g. counters will make it > difficult for some of our nodes to implement yang-push. I propose to have > a yang-extension "not-notifiable" that indicates that for a specific > data-node datastore change notifications will not be sent. An alternative > could be to define streams that filter out fast changing data-nodes like > counters. However how do we know from the model which data nodes are > counters and which are slow changing state data for which notifications > are needed: to solve this I think a yang-extension would be good. > I am not sure that pushing this decision to the data model writer is a good solution. How does a model writer decide which schema nodes to mark as 'not-notifiable'? Sure, there are cases where this may be clear but then there are also many cases where it is usage dependent whether an object can change too fast or there might be platform specific implementation constraints (that should not be documented in a data model). I think there are two alternatives: Make it runtime discoverable on which data nodes I can request change notifications or require that I can request change notifications on all data nodes but have a mechanism in place through which the system can tell me that certain data nodes will be excluded. On some systems, I might also have limits concerning the granularity (e.g., I get change notifications at max every N seconds but not on each individual change). Anyway, I do not know what the right solution is but to me it sounds wrong to push the decision on the data model writer. /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 May 19 02:31:52 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B410B12B04F for ; Thu, 19 May 2016 02:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xgGHROBszL6 for ; Thu, 19 May 2016 02:31:49 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17FA212D15A for ; Thu, 19 May 2016 02:31:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9019; q=dns/txt; s=iport; t=1463650302; x=1464859902; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=tLWCMlfA+N1hnBroapW5tgbVoXIb76QHAKuDWs98jkE=; b=AwMpENuPVfgal0dW8bEFeTT3xxM8ZRayavf9frNMKYwsesqKso76Zq/L 9DDa01NM0TBM5AtGYG7A8D0EVeLWMhuVm0pnYIZICd3Iy9Xn+uXM9h336 USluPJRTSmCwLjZstifP/46OZWAGIK6C+U37okk9KZvonX7p+vl2uDSVP 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BDAgC9hj1X/5xdJa1dgmxLgVQGtQaEe?= =?us-ascii?q?QENgXWGEQKBMzgUAQEBAQEBAWUnhEIBAQEEgQkCAQgRAwECDhoHMhQJCAIEARK?= =?us-ascii?q?IL8NlAQEBAQEBAQEBAQEBAQEBAQEBAR6KcoQREQEGNoU5BZgxAY4fgWmHeoU3j?= =?us-ascii?q?0gBHgEBQoNtboZICRcDHH8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,334,1459814400"; d="scan'208,217";a="104175476" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 May 2016 09:31:41 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u4J9Ve5e011455 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 19 May 2016 09:31:41 GMT Received: from xch-rtp-003.cisco.com (64.101.220.143) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 19 May 2016 05:31:40 -0400 Received: from xch-rtp-003.cisco.com ([64.101.220.143]) by XCH-RTP-003.cisco.com ([64.101.220.143]) with mapi id 15.00.1104.009; Thu, 19 May 2016 05:31:39 -0400 From: "Alberto Gonzalez Prieto (albertgo)" To: Balazs Lengyel , "netconf@ietf.org" Thread-Topic: [Netconf] yang push drafts Thread-Index: AQHRkQIBXT8OlZhANk6RNfFGvrR4NZ9/dE0AgABu0wCABWTnAIA7Mu+A//+TNQA= Date: Thu, 19 May 2016 09:31:39 +0000 Message-ID: References: <20160407.211618.713559915962370737.mbj@tail-f.com> <5955a6d8c3c349d89df9bea9d9d400b0@XCH-RTP-001.cisco.com> <20160408.083656.300674541946534958.mbj@tail-f.com> <7711f8d0-b1ea-da04-d811-837fa7064fd9@ericsson.com> In-Reply-To: <7711f8d0-b1ea-da04-d811-837fa7064fd9@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.29.31] Content-Type: multipart/alternative; boundary="_000_D362D1D87545Dalbertgociscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] yang push drafts X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 09:31:50 -0000 --_000_D362D1D87545Dalbertgociscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Balazs, From: Netconf > o= n behalf of Balazs Lengyel > Date: Thursday, May 19, 2016 at 2:00 AM To: "netconf@ietf.org" > Subject: Re: [Netconf] yang push drafts Hello Eric, As indicated on yesterdays interim meeting, we have some issues with the ya= ng-push draft 1) Implementing yang-push for every data bit e.g. counters will make it dif= ficult for some of our nodes to implement yang-push. I propose to have a ya= ng-extension "not-notifiable" that indicates that for a specific data-node= datastore change notifications will not be sent. An alternative could be = to define streams that filter out fast changing data-nodes like counters. H= owever how do we know from the model which data nodes are counters and whic= h are slow changing state data for which notifications are needed: to solve= this I think a yang-extension would be good. [AG] Does the requirement apply to on-change subscriptions only? Or also t= o periodic? An option is for the server to reject subscriptions that cannot be served (= I.e., on-change updates of fast-changing state). Using the negotiation mechanism, it can guide the client stating that it ca= nnot serve on-change subscriptions for the requested data nodes, but it can= serve periodic updates [/AG] 2) If I have an on-change subscription and I loose some notifications it is= much cheaper to somehow playback those notifications than to get the full = datastore (or subtree). We would need a replay capability to get the lost n= otifications. This also implies the need for a way to detect st notificatio= ns. I concur with Juergen that a sequence number for the notifications woul= d be good. 3) For an on-change subscription in some cases (e.g. reload, upgrade, etc.= ) there are so many changes that instead of sending them all, it would be b= etter to : - the node suspends change notifications [AG] subscription suspensions are decided unilaterally by the server. The s= uspension is notified to the subscribers/receivers, including the reason fo= r the suspension. [/AG] - the node sends a special notification change-notifications-lost or resync= hronization-proposed. This would allow the client to re-synchronize, read t= he datastore with a get operation. As an example, there is no sense sending individual changes when 70% of the= datastore changed. [AG] would a synch-on-resume flag address this? The semantics being similar to those of the synch-on-start on the draft, an= d also being part of the subscription request. (Both flags may be combined into just one) [/AG] Opinions? regards Balazs -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com --_000_D362D1D87545Dalbertgociscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <0D9CD9D1309DE5468DF7C79E5D9F3AEE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Balazs,



From: Netconf <netconf-bounces@ietf.org> on behalf of Ba= lazs Lengyel <balazs.leng= yel@ericsson.com>
Date: Thursday, May 19, 2016 at 2:0= 0 AM
To: "netconf@ietf.org" <netconf@ietf.org>
Subject: Re: [Netconf] yang push dr= afts

Hello Eric,

As indicated on yesterdays interim meeting, we have some issues with the= yang-push draft

1) Implementing yang-push for every data bit e.g. counters will make it dif= ficult for some of our nodes to implement yang-push. I propose to have a ya= ng-extension "not-notifiable"  that indicates that for a spe= cific data-node datastore change notifications  will not be sent. An alternative could be to define streams that filter ou= t fast changing data-nodes like counters. However how do we know from the m= odel which data nodes are counters and which are slow changing state data f= or which notifications are needed: to solve this I think a yang-extension would be good.

[AG] Does the requirement apply to on-change subscriptions only?  = ;Or also to periodic?
An option is for the server to reject subscriptions that cannot be ser= ved (I.e., on-change updates of fast-changing state).
Using the negotiation mechanism, it can guide the client stating that = it cannot serve on-change subscriptions for the requested data nodes, but i= t can serve periodic updates
[/AG]



2) If I have an on-change subscription and I loose some notifications it is= much cheaper to somehow playback those notifications than to get the full = datastore (or subtree). We would need a replay capability to get the lost n= otifications. This also implies the need for a way to detect st notifications. I concur with Juergen that = a sequence number for the notifications would be good.

3) For an on-change subscription in some cases  (e.g. reload, upgrade,= etc.) there are so many changes that instead of sending them all, it would= be better to :
- the node suspends change notifications
[AG] subscription suspensions are decided unilaterally by the server. = The suspension is notified to the subscribers/receivers, including the reas= on for the suspension.
[/AG]


- the node sends a special notification change-notifications-lost or resync= hronization-proposed. This would allow the client to re-synchronize, read t= he datastore with a get operation.
As an example, there is no sense sending individual changes when 70% of the= datastore changed.

[AG] would a synch-on-resume flag address this? 
The semantics being similar to those of the synch-on-start on the draft, and also being part of the s= ubscription request.
(Both flags may be combined into just one)
[/AG]



Opinions?

regards Balazs
--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@erics=
son.com=20
--_000_D362D1D87545Dalbertgociscocom_-- From nobody Thu May 19 07:47:39 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF7CF12D501 for ; Thu, 19 May 2016 07:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qo6NTHrWfPjK for ; Thu, 19 May 2016 07:47:32 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5350B12D50B for ; Thu, 19 May 2016 07:47:32 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id g133so80238745ywb.2 for ; Thu, 19 May 2016 07:47:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=dswWl/1EQj95WLmKR9A1ZkcBOfIEyVhvIN9f3gwdEcY=; b=qZt0b38Td2Mv9bgzXsDLWFfntvzwuiBTFehKiOGLoMbxC7xSxs58pxZ4l6IvpIoVJE 2BuM5bJHztoSNEkKAGPWUcw1V3z7yKcXH8mCDEGE+RabY9I2hPvrbLgyUDsebx7a36/P VRLtZID6UckkOYaf9RGpk+lrUY9PLCU4NWaGTTsxgQqqEajWyljFomJa1x3AA88SorVj x5E9BEeB4QVjto7Am6pyQTVBjLP+yPg0T0CnaFRR8OrXGVPM5wfq5dQJ3VT6ayR/pOA3 8NMNi0cGqUV9y3A6Nz7n7bpp+qRbSfZLQHBjaaflycvUJl/WPm7cO1ocJEb1zB+Vp1UU 54kA== 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; bh=dswWl/1EQj95WLmKR9A1ZkcBOfIEyVhvIN9f3gwdEcY=; b=QTW7o2yiB1w+9w2wxm39TfmXaD4wDtwoafl5+sPiyHjg4QBiMW25VY3ucAaySYTgb0 JcIMC1MOdVTw12gmFml6Kq/yLW5k46V+c2iF3dlBX9QSyPLeOfiQgWNoyjZB1fVM+1iG Z3hSYI7cbaJPZo08Q5DdsTSqsKtGZdaVONUbJHvuegw+raRl402klnaL7nOSkZCaMxNR LV8x3SmNcPuQLwNaORWPoWiCXERz1rnMajAL/iHGnjYRZJqQMVX/q5mdpj77SzqqQlOj HHBXXlkmMC3p/vSDZQ17nLOH6mJz6wmu9Moqfi0/8lQtbFJRbExHoAL6tCja3EkW3DeP 0FIg== X-Gm-Message-State: AOPr4FWH646SP6NIygfgLAtxVdatyzttI2oK2GpxQ/ScvsfadN1odOX2SDeV1tIKapeKgLEGovkKq61QSKkKvQ== MIME-Version: 1.0 X-Received: by 10.37.80.133 with SMTP id e127mr2188480ybb.162.1463669251606; Thu, 19 May 2016 07:47:31 -0700 (PDT) Received: by 10.37.44.130 with HTTP; Thu, 19 May 2016 07:47:31 -0700 (PDT) In-Reply-To: <20160519091528.GA1736@elstar.local> References: <20160407.211618.713559915962370737.mbj@tail-f.com> <5955a6d8c3c349d89df9bea9d9d400b0@XCH-RTP-001.cisco.com> <20160408.083656.300674541946534958.mbj@tail-f.com> <7711f8d0-b1ea-da04-d811-837fa7064fd9@ericsson.com> <20160519091528.GA1736@elstar.local> Date: Thu, 19 May 2016 07:47:31 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Balazs Lengyel , "netconf@ietf.org" Content-Type: multipart/alternative; boundary=001a113e9b6ccfc3c60533330d2b Archived-At: Subject: Re: [Netconf] yang push drafts X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 14:47:38 -0000 --001a113e9b6ccfc3c60533330d2b Content-Type: text/plain; charset=UTF-8 On Thu, May 19, 2016 at 2:15 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Thu, May 19, 2016 at 11:00:59AM +0200, Balazs Lengyel wrote: > > > > 1) Implementing yang-push for every data bit e.g. counters will make > it > > difficult for some of our nodes to implement yang-push. I propose to > have > > a yang-extension "not-notifiable" that indicates that for a specific > > data-node datastore change notifications will not be sent. An > alternative > > could be to define streams that filter out fast changing data-nodes > like > > counters. However how do we know from the model which data nodes are > > counters and which are slow changing state data for which > notifications > > are needed: to solve this I think a yang-extension would be good. > > > > I am not sure that pushing this decision to the data model writer is a > good solution. How does a model writer decide which schema nodes to > mark as 'not-notifiable'? Sure, there are cases where this may be > clear but then there are also many cases where it is usage dependent > whether an object can change too fast or there might be platform > specific implementation constraints (that should not be documented in > a data model). > > I think there are two alternatives: Make it runtime discoverable on > which data nodes I can request change notifications or require that I > can request change notifications on all data nodes but have a > mechanism in place through which the system can tell me that certain > data nodes will be excluded. On some systems, I might also have limits > concerning the granularity (e.g., I get change notifications at max > every N seconds but not on each individual change). > > Anyway, I do not know what the right solution is but to me it sounds > wrong to push the decision on the data model writer. > > I agree -- the frequency of YANG Push updates is dervied from the usage, not the definition. I do not like the use of a subtree filter to select the data do push. I prefer a list of subtree identifiers. The server could reject specific subtree requests if it decides the update frequency is too high. A solution that allows the client to know the expected update frequency of a specific subtree would be useful. Resource management is the hardest part of YANG Push. The current draft puts an impossible burden on the server. A realistic solution would include counters for the client to inspect, including drop counters for each subscription receiver address. It would allow the server to adjust parameters and report the differences. /js > > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a113e9b6ccfc3c60533330d2b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, May 19, 2016 at 2:15 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Thu, May 19, 2016 at 11:00:59AM +0200, Balazs Len= gyel wrote:
>
>=C2=A0 =C2=A0 1) Implementing yang-push for every data bit e.g. counter= s will make it
>=C2=A0 =C2=A0 difficult for some of our nodes to implement yang-push. I= propose to have
>=C2=A0 =C2=A0 a yang-extension "not-notifiable"=C2=A0 that in= dicates that for a specific
>=C2=A0 =C2=A0 data-node datastore change notifications=C2=A0 will not b= e sent. An alternative
>=C2=A0 =C2=A0 could be to define streams that filter out fast changing = data-nodes like
>=C2=A0 =C2=A0 counters. However how do we know from the model which dat= a nodes are
>=C2=A0 =C2=A0 counters and which are slow changing state data for which= notifications
>=C2=A0 =C2=A0 are needed: to solve this I think a yang-extension would = be good.
>

I am not sure that pushing this decision to the data model writer is a
good solution. How does a model writer decide which schema nodes to
mark as 'not-notifiable'? Sure, there are cases where this may be clear but then there are also many cases where it is usage dependent
whether an object can change too fast or there might be platform
specific implementation constraints (that should not be documented in
a data model).

I think there are two alternatives: Make it runtime discoverable on
which data nodes I can request change notifications or require that I
can request change notifications on all data nodes but have a
mechanism in place through which the system can tell me that certain
data nodes will be excluded. On some systems, I might also have limits
concerning the granularity (e.g., I get change notifications at max
every N seconds but not on each individual change).

Anyway, I do not know what the right solution is but to me it sounds
wrong to push the decision on the data model writer.




I agree -- the frequen= cy of YANG Push updates is dervied from the usage, not the definition.

I do not like the use of a subtree filter to select th= e data do push.
I prefer a list of subtree identifiers.=C2=A0 The= server could reject specific subtree requests
if it decides the = update frequency is too high.

A solution that allo= ws the client to know the expected update frequency of a specific subtree
would be useful.

Resource management = is the hardest part of YANG Push.=C2=A0 The current draft puts an impossibl= e
burden on the server.=C2=A0 A realistic solution would include = counters for the client to inspect,
including drop counters for e= ach subscription receiver address. It would allow the server
to a= djust parameters and report the differences.


<= /div>
/js


Andy
=C2=A0
--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>

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

--001a113e9b6ccfc3c60533330d2b-- From nobody Tue May 24 23:47:32 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DEE912D631 for ; Tue, 24 May 2016 23:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWS0ReP5pn9n for ; Tue, 24 May 2016 23:47:30 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB3412D5BF for ; Tue, 24 May 2016 23:47:30 -0700 (PDT) Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id A38E11AE030A for ; Wed, 25 May 2016 08:47:27 +0200 (CEST) Date: Wed, 25 May 2016 08:47:48 +0200 (CEST) Message-Id: <20160525.084748.529965813670684706.mbj@tail-f.com> To: netconf@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: Subject: [Netconf] restconf draft bug X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 06:47:31 -0000 Hi, It was pointed out to me privately that there is a bug in appendix D.1.3 in the restconf draft. Section 9.1.2 says about the "defaults" capability: This protocol capability URI MUST be supported by the server, and MUST be listed in the "capability" leaf-list in Section 9.3. Yet this capability is missing from the example in D.1.3. I also noted that the XML namespace was missing for no apparent reason. For completeness the "with-defaults" capability should also be listed. So, I will do: OLD: urn:ietf:params:restconf:capability:depth:1.0 urn:ietf:params:restconf:capability:fields:1.0 urn:ietf:params:restconf:capability:filter:1.0 urn:ietf:params:restconf:capability:start-time:1.0 urn:ietf:params:restconf:capability:stop-time:1.0 http://example.com/capabilities/myparam NEW: urn:ietf:params:restconf:capability:defaults:1.0? basic-mode=explicit urn:ietf:params:restconf:capability:with-defaults:1.0 urn:ietf:params:restconf:capability:depth:1.0 urn:ietf:params:restconf:capability:fields:1.0 urn:ietf:params:restconf:capability:filter:1.0 urn:ietf:params:restconf:capability:start-time:1.0 urn:ietf:params:restconf:capability:stop-time:1.0 http://example.com/capabilities/myparam /martin From nobody Thu May 26 15:35:12 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8DDA12D0A6 for ; Thu, 26 May 2016 15:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxuoI5CovgV4 for ; Thu, 26 May 2016 15:35:10 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADC6612D14E for ; Thu, 26 May 2016 15:35:08 -0700 (PDT) Received: by mail-pa0-x233.google.com with SMTP id eu11so24413311pad.3 for ; Thu, 26 May 2016 15:35:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:message-id:mime-version:subject:date:references:to:in-reply-to; bh=xzraNr7os+4xYOwaDoM/6AH5A7ENweqbzJe8CzJkw3U=; b=spTWjQT0R7vspG3i9fQDZzmXPYxlcq9Gd7woSuI6V9xv22RWQOhT2/PGikbLaESV2X NF20Va+d4nzHF4qufOTn9xUSTGRoZg+XC9gyRpYFDmcQnO1tDThktROOdqSOPGmWSAJb nkN/1gvx09Arkg86BpG+OMWnVuEwlyfL4o8jePjOt0OBVipiiT628jYMe6cYLozETjPf 9T8oUxV79Q6O4iT2LQma8Ia6kVsdFQjD2mYYvaem19ibjhCJahFesRswPMOSXFG9dknQ eQaXxxXJLKb5LD3wJP0LstzdIYbil3j3pwXfBKlhrG3kFjgVxbGbg1Qsmw1YwPBkSahM 2eEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :references:to:in-reply-to; bh=xzraNr7os+4xYOwaDoM/6AH5A7ENweqbzJe8CzJkw3U=; b=JkVteyQcImX9CylmYBIlBkTMyWImONlNuTeF83o3h2AWjWjMxsCKe/6OcP7X5gkxx1 Ttb02L008AmTSP+JBEytt9jV4pIdPtTMVqfS7z3JlPImJyklaAE8+gfcJgiSEgUSdu0+ N/8h/kGGlacdcQStTIVitEe7XJzaVAVBlEYrIREQNQbGthi5xlDeaL2rerB3dGFwGL+V rB477M5dO26lIxVaitBd3bMfOUbIi+z74/pqvTCu768msjAqHJHv0Q7ZYde/cM9rUAuy w94klSZMjmziPh/GaZ/gZj+KVIy5Hu6MPDQqTPdRkotM0fOBjg+J4JczKMS1v5J50FgG ZsGQ== X-Gm-Message-State: ALyK8tLOQQLHa8mw2YBoFPmYQDG3JvhMg6Mvmzx5/MQRgKlbKF6+1J1nlfGfochi7ixiVw== X-Received: by 10.66.25.141 with SMTP id c13mr17713157pag.66.1464302108146; Thu, 26 May 2016 15:35:08 -0700 (PDT) Received: from ?IPv6:2001:420:290:1266:8d3b:4cd4:e5a4:de35? ([2001:420:290:1266:8d3b:4cd4:e5a4:de35]) by smtp.gmail.com with ESMTPSA id f66sm8445837pfj.28.2016.05.26.15.35.05 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 May 2016 15:35:06 -0700 (PDT) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_03175FD3-1D58-43C6-9D6C-B40A2059BAEA" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Date: Thu, 26 May 2016 15:35:14 -0700 References: <7548C9B2-1AD6-49DB-A2E3-B5EAC01B5543@gmail.com> To: Netconf In-Reply-To: <7548C9B2-1AD6-49DB-A2E3-B5EAC01B5543@gmail.com> X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Netconf] Notes and meeting material from interim meeting X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 22:35:12 -0000 --Apple-Mail=_03175FD3-1D58-43C6-9D6C-B40A2059BAEA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Notes from the meeting have now been uploaded into the data tracker. = Please find the agenda, minutes and all the material from the meeting = here. https://datatracker.ietf.org/wg/netconf/meetings/ = There were four action items from the call. Eric has already responded = and posted for his AI on this thread. The remaining three items relate to server configuration draft. Kent to send proposal #2 and #3 from his presentation to this mailing = list. The idea would be conclude on it so that Kent can make the split = coming into IETF 96. Initiate a review of the keychain model by SecDir. Kent has had a = previous preview done by Sean Turner, and he will continue the = discussion with him. Discuss and finalize how private keys are installed on the box. The = question was should it be a leaf or an action. Will kick start the = thread that had this discussion. Thanks. > On May 18, 2016, at 10:14 AM, Mahesh Jethanandani = wrote: >=20 > First of all, a big thanks to Sue for taking some very diligent notes = today.=20 >=20 > The notes from the interim meeting are captured on the Etherpad link = below. Contributors, please edit/add comments to the notes that Sue = took. The deadline for making the changes is till May 25th. >=20 > http://etherpad.tools.ietf.org:9000/p/netconf-may-18-2016-interim = >=20 > The chairs will use the notes to drive any action items. >=20 > The meeting materials page for some reason is showing a broken link = and there is a case open to address it. For now use the following links = to access the meeting materials. >=20 > = https://www.ietf.org/proceedings/interim/2016/05/18/netconf/slides/slides-= interim-2016-netconf-1-1.pdf = > = https://www.ietf.org/proceedings/interim/2016/05/18/netconf/slides/slides-= interim-2016-netconf-1-2.pdf = > = https://www.ietf.org/proceedings/interim/2016/05/18/netconf/slides/slides-= interim-2016-netconf-1-3.pdf = > = https://www.ietf.org/proceedings/interim/2016/05/18/netconf/slides/slides-= interim-2016-netconf-1-4.pdf = Mahesh & Mehmet --Apple-Mail=_03175FD3-1D58-43C6-9D6C-B40A2059BAEA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Notes from the meeting have now been uploaded into the data = tracker. Please find the agenda, minutes and all the material from the = meeting here.

https://datatracker.ietf.org/wg/netconf/meetings/

There were four action = items from the call. Eric has already responded and posted for his AI on = this thread.

The= remaining three items relate to server configuration draft.

  • Kent to send proposal #2 and #3 = from his presentation to this mailing list. The idea would be conclude = on it so that Kent can make the split coming into IETF 96.
  • Initiate a review of the keychain model by SecDir. Kent has = had a previous preview done by Sean Turner, and he will continue the = discussion with him.
  • Discuss and finalize how private = keys are installed on the box. The question was should it be a leaf or = an action. Will kick start the thread that had this = discussion.

Thanks.

On May 18, 2016, at 10:14 AM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:

First of all, = a big thanks to Sue for taking some very diligent notes today. 

The notes from the = interim meeting are captured on the Etherpad link below. Contributors, = please edit/add comments to the notes that Sue took. The deadline for = making the changes is till May 25th.

http://etherpad.tools.ietf.org:9000/p/netconf-may-18-2016-inter= im

The = chairs will use the notes to drive any action items.

The meeting materials = page for some reason is showing a broken link and there is a case open = to address it. For now use the following links to access the meeting = materials.

https://www.ietf.org/proceedings/interim/2016/05/18/netconf/sli= des/slides-interim-2016-netconf-1-1.pdf
https://www.ietf.org/proceedings/interim/2016/05/18/netconf/sli= des/slides-interim-2016-netconf-1-2.pdf
https://www.ietf.org/proceedings/interim/2016/05/18/netconf/sli= des/slides-interim-2016-netconf-1-3.pdf
https://www.ietf.org/proceedings/interim/2016/05/18/netconf/sli= des/slides-interim-2016-netconf-1-4.pdf
<= /blockquote>
Mahesh & Mehmet



= --Apple-Mail=_03175FD3-1D58-43C6-9D6C-B40A2059BAEA-- From nobody Thu May 26 17:06:40 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1607B12D767 for ; Thu, 26 May 2016 17:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBT5xxkA0C4D for ; Thu, 26 May 2016 17:06:37 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37AB112D698 for ; Thu, 26 May 2016 17:06:37 -0700 (PDT) Received: by mail-pa0-x233.google.com with SMTP id eu11so25041934pad.3 for ; Thu, 26 May 2016 17:06:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:message-id:date:to:mime-version; bh=4yykSyVSOLjkfvG+zOjtK8HasoZI5WwOpQkMg81wtV8=; b=WBBlBS4fX0kdHmqwH0279a/S53U5i/vj5lo1f3OaOqJScbOpHO4Dh0N1t+z6QkWebm 46bqZziZM+u1q9w9Hlf1oNp8nTtL/Yjsh2KhPcedNxvwrfFa4JezpgfDTZZk6EPzc6ho 0+4FACInF8t4c+pz68DlV3A9giZdKW0vJCYundGsidg+hkD0cyUWLsIXuluHuvtQURLR ahwnga1kizKlqm9MbYspQM2okhZHFn3FV2v9tGOeAB38VwNrFttFUWYNl9MafPlzogHr GVhUW9e2loqzO58cV/Mq13jT/Yvi8fm/8QxUNXH0ceNQ188sQg1iEHIJYYBKvxr2k6Rx ATEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:message-id:date:to:mime-version; bh=4yykSyVSOLjkfvG+zOjtK8HasoZI5WwOpQkMg81wtV8=; b=FAbAXAHNYEAsivM/mngYVUZ7gyrrO+2nAg1HRIgePXGxPkZrOmzhS7QwVSGtwL7vXw /ewHXBR9f+YI5URQCc7CmXYhjO15Z2M3Jkcq4MKVy+flZ2O8TMsNgfQLMzqp44vQ4wia iLghKogy6bj1IpvrEvxYh53JvJTR1k73/qXvgCdmdDupH9deUBtl45Y+lb0zGuCEcgOt McNxCZpY/LON2cID9Ov1ZuhLlKOGxny7/jsZ2AKdrhBZ2GO54Tp5+sB65I8I9YCXWiH/ uQsg486U7eeGk9TnX13IMJQUjlVzgroJagWVEMmwMTF3nmL10WfYWq9/CoFCh+DJ7hFn x/Ow== X-Gm-Message-State: ALyK8tLQL8Hr3nXDkamqu0ZeZUwmuKThdJdjDXgBEpo5mybmnxVmp8Wb63MCJ6yyKHKTXA== X-Received: by 10.66.7.69 with SMTP id h5mr18066660paa.11.1464307596620; Thu, 26 May 2016 17:06:36 -0700 (PDT) Received: from ?IPv6:2001:420:290:1330:a570:540b:44bc:d149? ([2001:420:290:1330:a570:540b:44bc:d149]) by smtp.gmail.com with ESMTPSA id q188sm8639928pfq.66.2016.05.26.17.06.35 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 May 2016 17:06:35 -0700 (PDT) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_62054681-9F2A-4149-90F1-412D93F6601F" Message-Id: Date: Thu, 26 May 2016 17:06:43 -0700 To: Netconf Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [Netconf] Semi-configurable design in server model draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 00:06:39 -0000 --Apple-Mail=_62054681-9F2A-4149-90F1-412D93F6601F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii One of the issues that Kent brought up in the interim meeting was the = issue of configuring the private key. Some background on that issue = dates back to the thread that started with Martin reviewing the document = and here is what he brought up in that review. o Section 4.1 I think the "semi-configurable" design has some issues. You have defined some actions that actually modifies the configuration of the system. It is not clear which config datastore is modified. Presumably running. Interactions with locking and access control are not described. Also, the resulting configuration is not complete - i.e., you cannot do to save/restore a backup. This is fine, since you really don't want to expose the private keys in the config backup. But some discussion is needed around this subject. What happens if I generate a private key with your action, backup that config and then restore it? What happens with config that has references to such a key? One way to avoid that the actions modify the configuration could be to move them into the private-key list. One drawback is that two operations are needed in order to create a (usable) key - first create the config in running, then call the action. Another option might be to model the keys as config false data. This also solves the problem that some keys (in TPM for example) are not deletable. The two suggestions that Kent brought to the meeting on whether to make = it a leaf or an action.=20 Leafs can be backed up or restored. But private-keys in TPM never leave = the source. How do we support special hardware like TPM? Making it an action requires creation of a dummy private key, and then = call action to populate the data in it, as Martin states above. What = happens if the key is not available but is referenced by the system? Kent, is that a fair summary of the issue? Let the discussion begin :-) Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_62054681-9F2A-4149-90F1-412D93F6601F Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii One of the issues that Kent brought up in the interim meeting was the issue of configuring the private key. Some background on that issue dates back to the thread that started with Martin reviewing the document and here is what he brought up in that review.

o  Section 4.1

  I think the "semi-configurable" design has some issues.  You have
  defined some actions that actually modifies the configuration of the
  system.  It is not clear which config datastore is modified.
  Presumably running.  Interactions with locking and access control
  are not described.  Also, the resulting configuration is not
  complete - i.e., you cannot do <copy-config> to save/restore a
  backup.  This is fine, since you really don't want to expose the
  private keys in the config backup.  But some discussion is needed
  around this subject.  What happens if I generate a private key with
  your action, backup that config and then restore it?  What happens
  with config that has references to such a key?

  One way to avoid that the actions modify the configuration could be
  to move them into the private-key list.  One drawback is that two
  operations are needed in order to create a (usable) key - first
  create the config in running, then call the action.

  Another option might be to model the keys as config false data.
  This also solves the problem that some keys (in TPM for example)
  are not deletable.
The two suggestions that Kent brought to the meeting on whether to make it a leaf or an action. 

Leafs can be backed up or restored. But private-keys in TPM never leave the source. How do we support special hardware like TPM?

Making it an action requires creation of a dummy private key, and then call action to populate the data in it, as Martin states above. What happens if the key is not available but is referenced by the system?

Kent, is that a fair summary of the issue?

Let the discussion begin :-)

Mahesh Jethanandani



--Apple-Mail=_62054681-9F2A-4149-90F1-412D93F6601F-- From nobody Fri May 27 03:57:50 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9942012D90D for ; Fri, 27 May 2016 03:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYrf9qb27jnr for ; Fri, 27 May 2016 03:57:47 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD0E412D94C for ; Fri, 27 May 2016 03:57:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1815; q=dns/txt; s=iport; t=1464346666; x=1465556266; h=subject:references:to:from:message-id:date:mime-version: in-reply-to; bh=lgxRF631MKrUo+Ca4wnAq8VmAVQafuzy2khwls6I6v8=; b=ULzszic/kMkYhRMJ0pzM5Pt0gJ+a/MP2KPXGfRQPdXomCSmFafq804M5 9eGyIMOIIGjqLv1tcCkwNONfmZXuA9z8DnvTMuNUJ4OrR3trSODA1iLmD u1ZQl31ISUBIx1o0JMQIUZP+v+2taIOrrDstR/L6xF5yXgPAAzCEyDHUn 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAgDmJkhX/xbLJq1chA8rUrR2gmqCD?= =?us-ascii?q?wENgXgihW8CgXMUAQEBAQEBAWUnhDoKAgQjZg4BPgICVwYNCAEBiCsOsjqRSQE?= =?us-ascii?q?BAQEBAQEDAQEBAQEBAQEBGQWGJ4F2ihaCWQWYN44giUGFW49MHgEBQoNvOjIBi?= =?us-ascii?q?gcBAQE?= X-IronPort-AV: E=Sophos;i="5.26,373,1459814400"; d="scan'208,217";a="634852929" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 May 2016 10:57:45 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u4RAviqC007566 for ; Fri, 27 May 2016 10:57:44 GMT References: <7156655b-270d-1022-dc13-fbeb7e74088e@cisco.com> To: NETCONF From: Benoit Claise X-Forwarded-Message-Id: <7156655b-270d-1022-dc13-fbeb7e74088e@cisco.com> Message-ID: Date: Fri, 27 May 2016 12:57:44 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <7156655b-270d-1022-dc13-fbeb7e74088e@cisco.com> Content-Type: multipart/alternative; boundary="------------FD8FB383B2BEBED0648D8280" Archived-At: Subject: [Netconf] IETF Hackathon in Berlin: YANG/NETCONF/RESTCONF X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 10:57:49 -0000 This is a multi-part message in MIME format. --------------FD8FB383B2BEBED0648D8280 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, If you start planning your trip to the Berlin IETF now, you might consider participating to the IETF Hackathon. We had some good success at thelast IETF , and we want to repeat the experience. See https://www.ietf.org/hackathon/96-hackathon.html for the detail, and let me know which YANG/NETCONF/RESTCONF projects you want to work on. Regards, Benoit --------------FD8FB383B2BEBED0648D8280 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Dear all,

If you start planning your trip to the Berlin IETF now, you might consider participating to the IETF Hackathon.
We had some good success at the last IETF, and we want to repeat the experience.

See https://www.ietf.org/hackathon/96-hackathon.html for the detail, and let me know which YANG/NETCONF/RESTCONF projects you want to work on.

Regards, Benoit




--------------FD8FB383B2BEBED0648D8280-- From nobody Fri May 27 10:13:05 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDDA012DA25 for ; Fri, 27 May 2016 10:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6MMrdL86nOR for ; Fri, 27 May 2016 10:13:02 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0120.outbound.protection.outlook.com [65.55.169.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40E8712D73B for ; Fri, 27 May 2016 10:13:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=aPlbEE4aFSNs+tq3nJr6AfEQEMFZIg0FztzMdmZPqdk=; b=HoqU1an8pi6YikM6jBlyAfn+KhxWcdE0o+jjravhPo3OSaUuRAAbYzsFIUsA//xQQaz8iTO/zx3JmIkVHlFTcAjVqQWXKAFFevXuLSPth1R7WUxnOEZCbTMn9+gUDt3TBmeDT8hjPsS831+v37GRH+0NVY6qo6E4FRz32BWM9Lk= Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1449.namprd05.prod.outlook.com (10.160.148.155) with Microsoft SMTP Server (TLS) id 15.1.501.7; Fri, 27 May 2016 17:12:59 +0000 Received: from CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) by CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) with mapi id 15.01.0501.016; Fri, 27 May 2016 17:12:58 +0000 From: Kent Watsen To: Mahesh Jethanandani , t.petch Thread-Topic: [Netconf] Confirming the decision to split the server-model draft into several drafts. Thread-Index: AQHRoaVh8ffONUU7e0mY3J48WLy0wJ+gl6QAgAADqICAAAGbAIAAMy4MgAAG/4CAAFj0gP//24sAgARfpPCAAnXPAIAlDqYA Date: Fri, 27 May 2016 17:12:58 +0000 Message-ID: References: <3C88D813-7674-47C4-A6AF-E02C368CE71C@juniper.net> <20160429.100226.431840842419129504.mbj@tail-f.com> <20160429081529.GA26297@elstar.local> <20160429.102116.1627845264494578220.mbj@tail-f.com> <00aa01d1a209$2d165a20$4001a8c0@gateway.2wire.net> <9E3A9643-2348-42AA-A6B0-6FB9F13D1A29@juniper.net> <022801d1a456$c20e12e0$4001a8c0@gateway.2wire.net> <92BAF631-804E-45AD-89A3-48059966B2F4@gmail.com> In-Reply-To: <92BAF631-804E-45AD-89A3-48059966B2F4@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.16.0.160506 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-ms-office365-filtering-correlation-id: 56c35dd3-2289-4d9d-0665-08d3865226a1 x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1449; 5:FOeM2h14ufNNxoNCZDyb7FicPiRApEUw8rTvlzBJWXdDHMQruabOtSiC63XXELD4MCwEjIIMYH12nyqylAlNVpcXgiDp2WrGAxX6l9nN3eCf03ike69K2iVPupCdrUm4rWbfE3P2gbx1Z/H55Qlevw==; 24:lD1yKp/8Ny//3EpRKnpVYdbgsivSkpMJfuLu3JDjIPtK0KZux0wqVUOVPTFVYtHpOs3lR7iDoQYsR2I1qJ97lJ0JOFnNjbVXZRF09KSFtgQ=; 7:eTuSBFYJn4fyPrLX/DOixKcuj6AgQoUZqnZsvBdeLZYXm+MvXsDWRzt2Jx5qYG+X6k2GDZ5+BxYZ40IGA3bsxAXaOXSROU3/gaTS1YEiO92nJb0C+IGKOF+h8NuMKAzGqN1CNF85wIqZRUBBgmsehxM/WQARqPW7Fkf0j3CVyxTJYqxShIF9X5D0VEOcqbF4 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1449; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415321)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:CY1PR0501MB1449; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1449; x-forefront-prvs: 09555FB1AD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(87936001)(2950100001)(99286002)(77096005)(2900100001)(99936001)(82746002)(83506001)(8676002)(83716003)(81166006)(122556002)(50986999)(76176999)(54356999)(8936002)(5002640100001)(5004730100002)(561944003)(33656002)(189998001)(4001350100001)(86362001)(66066001)(4326007)(106116001)(5001770100001)(93886004)(10400500002)(36756003)(586003)(1220700001)(6116002)(102836003)(5008740100001)(92566002)(8666003)(5890100001)(3846002)(2906002)(19580405001)(19580395003)(3660700001)(3280700002)(7059030)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1449; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/mixed; boundary="_002_DB7556EB55674DAFBC60691C79AB2A7Fjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 27 May 2016 17:12:58.1180 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1449 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Confirming the decision to split the server-model draft into several drafts. X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 17:13:04 -0000 --_002_DB7556EB55674DAFBC60691C79AB2A7Fjunipernet_ Content-Type: text/plain; charset="utf-8" Content-ID: <503B8C3B9D314C4BA95A9E4273D46F4E@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 DQoNCk9uIDUvMy8xNiwgNzoxOCBQTSwgIk1haGVzaCBKZXRoYW5hbmRhbmkiIDxtamV0aGFuYW5k YW5pQGdtYWlsLmNvbT4gd3JvdGU6DQoNCj5JdCBhcHBlYXJzIHRoYXQgYSB2aXJ0dWFsIGludGVy aW0gbWVldGluZyBtaWdodCBoZWxwIHRoaXMgZGlzY3Vzc2lvbiBhbmQgdGhlIGRpc2N1c3Npb24g YXJvdW5kIGtleS1jaGFpbiBtb2RlbHMuIA0KPg0KPkNvbnNpZGVyIHRoaXMgYSB0d28gd2VlayBu b3RpY2UgZm9yIHRoZSBtZWV0aW5nLiBEZXRhaWxzIHdpbGwgYmUgc2VudCBvdXQgbGF0ZXIuDQo+ DQo+TWFoZXNoICYgTWVobWV0DQoNCg0KT2theSwgd2UgaGFkIHRoZSBpbnRlcmltLiAgVGhlIHNs aWRlcyBJIHByZXNlbnRlZCB0aGVuIGFyZSBhdHRhY2hlZC4NCg0KT2YgdGhlIHZhcmlvdXMgcHJv cG9zYWxzIGxpc3RlZCBpbiB0aGUgc2xpZGVzLCB0aGUgaW50ZXJpbeKAmXMgY29uc2Vuc3VzIHdh cyB0byBtb3ZlIGZvcndhcmQgd2l0aCBlaXRoZXIgcHJvcG9zYWwgIzIgb3IgcHJvcG9zYWwgIzMg KHNsaWRlcyA4IGFuZCA5KS4gIFRoZSBvbmx5IGRpZmZlcmVuY2UgYmV0d2VlbiB0aGVzZSBwcm9w b3NhbHMgaXMgdGhhdCAjMyBzcGxpdHMgb3V0IHRoZSByZXN0Y29uZiBjbGllbnQvc2VydmVyIG1v ZGVscyBpbnRvIGl0cyBvd24gZHJhZnQsIGFzIG9wcG9zZWQgdG8gaGF2aW5nIHRoZW0gaW4gdGhl IHNhbWUgZHJhZnQgd2l0aCB0aGUgbmV0Y29uZiBjbGllbnQvc2VydmVyIG1vZGVscy4NCg0KQXNz dW1pbmcgdGhlIGludGVyaW3igJlzIGNvbnNlbnN1cyBpcyB1cGhlbGQgaGVyZSBvbiBsaXN0LCB3 ZSBub3cgbmVlZCB0byBwaWNrIGJldHdlZW4gcHJvcG9zYWxzICMyIGFuZCAjMy4gICBGV0lXLCBJ IGhhdmUgYSBzbGlnaHQgcHJlZmVyZW5jZSBmb3IgIzMgb25seSBiZWNhdXNlIEkgbGlrZSB0aGUg Y29uc2lzdGVuY3kgb2YgaXQuICBBbnkgb3RoZXIgb3BpbmlvbnM/DQoNClRoYW5rcywNCktlbnQN Cg0KDQo= --_002_DB7556EB55674DAFBC60691C79AB2A7Fjunipernet_ Content-Type: application/vnd.openxmlformats-officedocument.presentationml.presentation; name="netconf-interim-server-model.pptx" Content-Description: netconf-interim-server-model.pptx Content-Disposition: attachment; filename="netconf-interim-server-model.pptx"; size=81049; creation-date="Fri, 27 May 2016 17:12:57 GMT"; modification-date="Fri, 27 May 2016 17:12:57 GMT" Content-ID: <692F7364ABEBD14F97A3DFADC310F637@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQALt7AiJAIAAIAWAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADE mN9v2yAQx98n9X+weK1iQrd13RSnD+32tB+V1v0BzL4kbBgQkKz573e2k86p0jgdQbxEOsN973N2 uAMm1w+1zFZgndCqICwfkwxUqSuh5gX5cf9pdEUy57mquNQKCrIGR66nZ68m92sDLkNv5Qqy8N58 oNSVC6i5y7UBhSMzbWvu0bRzanj5m8+BXozHl7TUyoPyI99okOnkFmZ8KX328QEfdyToTrKbbl4T qiDcGClK7nGYNqN0r58F6Q44rlT1hG60IcvRs53jFsK48+cj/DIwfxJB1E1q7QD6fMPXaUUF2R23 /iuvcQI1xlNjwaFLGyQ/nN8eTD2biRIqXS5rdMn7YrXcMfOaC7VN4DkYJ/HhF+48fvq+wU5N1tM+ imlDE4fjJQQXyQleJyd4k5zgbXKCy+QE75ITXCUneJ+cgI3TI6Sviix9WWTp6yJLXxhZ+srI0pdG lqY2Ku3BbXdPPePk67OnPcS0wE26Xvot1Y55cq4d9SGyxvfOauNi7Hpb4SGClYA/UQgehYcIPJ6M oPsN/xitzGBE/lPCd7+WcPKse9JHLdbPfI1/ls2S7Yw4nazT/l+mOK0tjClOrwtjitP8wpjidMMw pjjtMYwpTr8MY4pzughjinPeCGOKdAIJhEpZyXtdNbx4H9dV/0UML82DEXFmu7ugpbbw8nDbq83G e2RQCKwXh3v2Y0SUDs4PmlvTCqo9sWl7fzz9CwAA//8DAFBLAwQUAAYACAAAACEAo+yCJgIBAADi AgAACwAIAl9yZWxzLy5yZWxzIKIEAiigAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKySz0oDMRCH74LvEObezbaKiDTbiwi9iawPMCazu6mb PyRTad/e2IO6sBTBHjPzm49vkqw3BzeKD0rZBq9gWdUgyOtgrO8VvLZPi3sQmdEbHIMnBUfKsGmu r9YvNCKXoTzYmEWh+KxgYI4PUmY9kMNchUi+dLqQHHI5pl5G1O/Yk1zV9Z1MvxnQTJhiaxSkrbkB 0R4j/Y8tHTEaZJQ6JFrEVKYT27KLaDH1xApM0M+lnE+JqpBBzgvd/l0odJ3V9Bj03pHnOS86MHlD 5rwSxnjOaHlJo2niRyZGljFRLsVT+pzQ6rJvxsPevXm048zVfPeqXaT+S0hOfmbzCQAA//8DAFBL AwQUAAYACAAAACEAS/U97L0AAAA3AQAAIAAAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGU3LnhtbC5y ZWxzjM+9CsIwEAfwXfAdwu0m1UFEmrqIIDiJPsCRXNtgm4RcFPv2ZrTg4Hhfvz9XH97jIF6U2AWv YS0rEORNsM53Gu6302oHgjN6i0PwpGEihkOzXNRXGjCXI+5dZFEUzxr6nONeKTY9jcgyRPJl0oY0 Yi5l6lRE88CO1Kaqtip9G9DMTHG2GtLZrkHcpkj/2KFtnaFjMM+RfP4RoXhwli44hWcuLKaOsgYp v/uzpY0sEaCaWs3ebT4AAAD//wMAUEsDBBQABgAIAAAAIQBL9T3svQAAADcBAAAgAAAAcHB0L3Ns aWRlcy9fcmVscy9zbGlkZTYueG1sLnJlbHOMz70KwjAQB/Bd8B3C7SbVQUSauoggOIk+wJFc22Cb hFwU+/ZmtODgeF+/P1cf3uMgXpTYBa9hLSsQ5E2wznca7rfTageCM3qLQ/CkYSKGQ7Nc1FcaMJcj 7l1kURTPGvqc414pNj2NyDJE8mXShjRiLmXqVETzwI7Upqq2Kn0b0MxMcbYa0tmuQdymSP/YoW2d oWMwz5F8/hGheHCWLjiFZy4spo6yBim/+7OljSwRoJpazd5tPgAAAP//AwBQSwMEFAAGAAgAAAAh AEv1Pey9AAAANwEAACAAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlNS54bWwucmVsc4zPvQrCMBAH 8F3wHcLtJtVBRJq6iCA4iT7AkVzbYJuEXBT79ma04OB4X78/Vx/e4yBelNgFr2EtKxDkTbDOdxru t9NqB4IzeotD8KRhIoZDs1zUVxowlyPuXWRRFM8a+pzjXik2PY3IMkTyZdKGNGIuZepURPPAjtSm qrYqfRvQzExxthrS2a5B3KZI/9ihbZ2hYzDPkXz+EaF4cJYuOIVnLiymjrIGKb/7s6WNLBGgmlrN 3m0+AAAA//8DAFBLAwQUAAYACAAAACEAS/U97L0AAAA3AQAAIAAAAHBwdC9zbGlkZXMvX3JlbHMv c2xpZGUzLnhtbC5yZWxzjM+9CsIwEAfwXfAdwu0m1UFEmrqIIDiJPsCRXNtgm4RcFPv2ZrTg4Hhf vz9XH97jIF6U2AWvYS0rEORNsM53Gu6302oHgjN6i0PwpGEihkOzXNRXGjCXI+5dZFEUzxr6nONe KTY9jcgyRPJl0oY0Yi5l6lRE88CO1Kaqtip9G9DMTHG2GtLZrkHcpkj/2KFtnaFjMM+RfP4RoXhw li44hWcuLKaOsgYpv/uzpY0sEaCaWs3ebT4AAAD//wMAUEsDBBQABgAIAAAAIQBL9T3svQAAADcB AAAgAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTgueG1sLnJlbHOMz70KwjAQB/Bd8B3C7SbVQUSa uoggOIk+wJFc22CbhFwU+/ZmtODgeF+/P1cf3uMgXpTYBa9hLSsQ5E2wznca7rfTageCM3qLQ/Ck YSKGQ7Nc1FcaMJcj7l1kURTPGvqc414pNj2NyDJE8mXShjRiLmXqVETzwI7Upqq2Kn0b0MxMcbYa 0tmuQdymSP/YoW2doWMwz5F8/hGheHCWLjiFZy4spo6yBim/+7OljSwRoJpazd5tPgAAAP//AwBQ SwMEFAAGAAgAAAAhAEv1Pey9AAAANwEAACAAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMi54bWwu cmVsc4zPvQrCMBAH8F3wHcLtJtVBRJq6iCA4iT7AkVzbYJuEXBT79ma04OB4X78/Vx/e4yBelNgF r2EtKxDkTbDOdxrut9NqB4IzeotD8KRhIoZDs1zUVxowlyPuXWRRFM8a+pzjXik2PY3IMkTyZdKG NGIuZepURPPAjtSmqrYqfRvQzExxthrS2a5B3KZI/9ihbZ2hYzDPkXz+EaF4cJYuOIVnLiymjrIG Kb/7s6WNLBGgmlrN3m0+AAAA//8DAFBLAwQUAAYACAAAACEAY1wjtMAAAAA3AQAAIAAAAHBwdC9z bGlkZXMvX3JlbHMvc2xpZGUxLnhtbC5yZWxzjM+9asMwEAfwPdB3ELdXsjuEECxlKQVDp5A+wCGd bVFbEjq5xG8fjTF0yHhfvz/XXe7LLP4os49BQysbEBRsdD6MGn5uX+8nEFwwOJxjIA0bMVzM26G7 0oylHvHkE4uqBNYwlZLOSrGdaEGWMVGokyHmBUst86gS2l8cSX00zVHlZwPMzhS905B714K4bYle seMweEuf0a4LhfJPhOLZO/rGLa6lsphHKhqkfO7vllpZI0CZTu3eNQ8AAAD//wMAUEsDBBQABgAI AAAAIQBL9T3svQAAADcBAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTQueG1sLnJlbHOMz70K wjAQB/Bd8B3C7SbVQUSauoggOIk+wJFc22CbhFwU+/ZmtODgeF+/P1cf3uMgXpTYBa9hLSsQ5E2w znca7rfTageCM3qLQ/CkYSKGQ7Nc1FcaMJcj7l1kURTPGvqc414pNj2NyDJE8mXShjRiLmXqVETz wI7Upqq2Kn0b0MxMcbYa0tmuQdymSP/YoW2doWMwz5F8/hGheHCWLjiFZy4spo6yBim/+7OljSwR oJpazd5tPgAAAP//AwBQSwMEFAAGAAgAAAAhAEv1Pey9AAAANwEAACEAAABwcHQvc2xpZGVzL19y ZWxzL3NsaWRlMTAueG1sLnJlbHOMz70KwjAQB/Bd8B3C7SbVQUSauoggOIk+wJFc22CbhFwU+/Zm tODgeF+/P1cf3uMgXpTYBa9hLSsQ5E2wznca7rfTageCM3qLQ/CkYSKGQ7Nc1FcaMJcj7l1kURTP Gvqc414pNj2NyDJE8mXShjRiLmXqVETzwI7Upqq2Kn0b0MxMcbYa0tmuQdymSP/YoW2doWMwz5F8 /hGheHCWLjiFZy4spo6yBim/+7OljSwRoJpazd5tPgAAAP//AwBQSwMEFAAGAAgAAAAhAH03a4aP AQAAaw0AAB8ACAFwcHQvX3JlbHMvcHJlc2VudGF0aW9uLnhtbC5yZWxzIKIEASigAAEAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAvJfNaoQwFIX3hb6DZF+jzp9TRmdTCrMolHb6AKlef6gmkmSm 9e0bpsWqDJcuQpY5JtePm5MTstt/tY13BqlqwRMS+gHxgGcir3mZkLfj411MPKUZz1kjOCSkB0X2 6e3N7gUaps0iVdWd8kwVrhJSad3dU6qyClqmfNEBN18KIVumzVCWtGPZByuBRkGwpnJcg6STmt4h T4g85FviHfsO/lNbFEWdwYPITi1wfeUXVDV1DqYgkyXohFyGv2rsm2qEXoeIApsUlWmnOOknpjTI P5qJPJsVonShTbpOgnqWwmzIQDZIKEVkk+Jcw+eMYpBQioVNCm3WjvxyGf6I+IYsrUKw9wZedd/A qBkjESMJrRoXOT5blMKqQRGKMEAxrDoUw0DdEVq1KIYRoRhWTYphLFCMlSuMJYqxdoWxQjE2rjDW KEbsCmODYli9/LnQoOaX7kiczMBPsPXuzLFG4mQGfu242jQMwlW4odnmKtrQZHMVbGiuuYo1NNVc hRqaaa4ibUg0Onkipd8AAAD//wMAUEsDBBQABgAIAAAAIQBjXCO0wAAAADcBAAAhAAAAcHB0L3Ns aWRlcy9fcmVscy9zbGlkZTE3LnhtbC5yZWxzjM+9asMwEAfwPdB3ELdXsjuEECxlKQVDp5A+wCGd bVFbEjq5xG8fjTF0yHhfvz/XXe7LLP4os49BQysbEBRsdD6MGn5uX+8nEFwwOJxjIA0bMVzM26G7 0oylHvHkE4uqBNYwlZLOSrGdaEGWMVGokyHmBUst86gS2l8cSX00zVHlZwPMzhS905B714K4bYle seMweEuf0a4LhfJPhOLZO/rGLa6lsphHKhqkfO7vllpZI0CZTu3eNQ8AAAD//wMAUEsDBBQABgAI AAAAIQBL9T3svQAAADcBAAAhAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTE2LnhtbC5yZWxzjM+9 CsIwEAfwXfAdwu0m1UFEmrqIIDiJPsCRXNtgm4RcFPv2ZrTg4Hhfvz9XH97jIF6U2AWvYS0rEORN sM53Gu6302oHgjN6i0PwpGEihkOzXNRXGjCXI+5dZFEUzxr6nONeKTY9jcgyRPJl0oY0Yi5l6lRE 88CO1Kaqtip9G9DMTHG2GtLZrkHcpkj/2KFtnaFjMM+RfP4RoXhwli44hWcuLKaOsgYpv/uzpY0s EaCaWs3ebT4AAAD//wMAUEsDBBQABgAIAAAAIQBL9T3svQAAADcBAAAhAAAAcHB0L3NsaWRlcy9f cmVscy9zbGlkZTE1LnhtbC5yZWxzjM+9CsIwEAfwXfAdwu0m1UFEmrqIIDiJPsCRXNtgm4RcFPv2 ZrTg4Hhfvz9XH97jIF6U2AWvYS0rEORNsM53Gu6302oHgjN6i0PwpGEihkOzXNRXGjCXI+5dZFEU zxr6nONeKTY9jcgyRPJl0oY0Yi5l6lRE88CO1Kaqtip9G9DMTHG2GtLZrkHcpkj/2KFtnaFjMM+R fP4RoXhwli44hWcuLKaOsgYpv/uzpY0sEaCaWs3ebT4AAAD//wMAUEsDBBQABgAIAAAAIQBL9T3s vQAAADcBAAAhAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTE0LnhtbC5yZWxzjM+9CsIwEAfwXfAd wu0m1UFEmrqIIDiJPsCRXNtgm4RcFPv2ZrTg4Hhfvz9XH97jIF6U2AWvYS0rEORNsM53Gu6302oH gjN6i0PwpGEihkOzXNRXGjCXI+5dZFEUzxr6nONeKTY9jcgyRPJl0oY0Yi5l6lRE88CO1Kaqtip9 G9DMTHG2GtLZrkHcpkj/2KFtnaFjMM+RfP4RoXhwli44hWcuLKaOsgYpv/uzpY0sEaCaWs3ebT4A AAD//wMAUEsDBBQABgAIAAAAIQBL9T3svQAAADcBAAAhAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlk ZTEzLnhtbC5yZWxzjM+9CsIwEAfwXfAdwu0m1UFEmrqIIDiJPsCRXNtgm4RcFPv2ZrTg4Hhfvz9X H97jIF6U2AWvYS0rEORNsM53Gu6302oHgjN6i0PwpGEihkOzXNRXGjCXI+5dZFEUzxr6nONeKTY9 jcgyRPJl0oY0Yi5l6lRE88CO1Kaqtip9G9DMTHG2GtLZrkHcpkj/2KFtnaFjMM+RfP4RoXhwli44 hWcuLKaOsgYpv/uzpY0sEaCaWs3ebT4AAAD//wMAUEsDBBQABgAIAAAAIQBL9T3svQAAADcBAAAh AAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTEyLnhtbC5yZWxzjM+9CsIwEAfwXfAdwu0m1UFEmrqI IDiJPsCRXNtgm4RcFPv2ZrTg4Hhfvz9XH97jIF6U2AWvYS0rEORNsM53Gu6302oHgjN6i0PwpGEi hkOzXNRXGjCXI+5dZFEUzxr6nONeKTY9jcgyRPJl0oY0Yi5l6lRE88CO1Kaqtip9G9DMTHG2GtLZ rkHcpkj/2KFtnaFjMM+RfP4RoXhwli44hWcuLKaOsgYpv/uzpY0sEaCaWs3ebT4AAAD//wMAUEsD BBQABgAIAAAAIQBL9T3svQAAADcBAAAhAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTExLnhtbC5y ZWxzjM+9CsIwEAfwXfAdwu0m1UFEmrqIIDiJPsCRXNtgm4RcFPv2ZrTg4Hhfvz9XH97jIF6U2AWv YS0rEORNsM53Gu6302oHgjN6i0PwpGEihkOzXNRXGjCXI+5dZFEUzxr6nONeKTY9jcgyRPJl0oY0 Yi5l6lRE88CO1Kaqtip9G9DMTHG2GtLZrkHcpkj/2KFtnaFjMM+RfP4RoXhwli44hWcuLKaOsgYp v/uzpY0sEaCaWs3ebT4AAAD//wMAUEsDBBQABgAIAAAAIQBL9T3svQAAADcBAAAgAAAAcHB0L3Ns aWRlcy9fcmVscy9zbGlkZTkueG1sLnJlbHOMz70KwjAQB/Bd8B3C7SbVQUSauoggOIk+wJFc22Cb hFwU+/ZmtODgeF+/P1cf3uMgXpTYBa9hLSsQ5E2wznca7rfTageCM3qLQ/CkYSKGQ7Nc1FcaMJcj 7l1kURTPGvqc414pNj2NyDJE8mXShjRiLmXqVETzwI7Upqq2Kn0b0MxMcbYa0tmuQdymSP/YoW2d oWMwz5F8/hGheHCWLjiFZy4spo6yBim/+7OljSwRoJpazd5tPgAAAP//AwBQSwMEFAAGAAgAAAAh ADa64C1uAwAA0hAAABQAAABwcHQvcHJlc2VudGF0aW9uLnhtbOyX347jJhTG7yv1HSxuq4yN/yca Z5XZbapKUzXazD4AY5PEWgwW4JnMVH33HrCT4Hi0Wqm3uQrwHT7jH+SYc//p2DDvhUpVC14gfBcg j/JSVDXfF+jb03qWI09pwivCBKcFeqMKfVr++st9u2glVZRromGqBzZcLUiBDlq3C99X5YE2RN2J lnLQdkI2RENX7v1Kklewb5gfBkHqN6TmaJgvf2a+2O3qkn4RZdfA43sTSZldhzrUrTq5tT/j5r7F eEnqIF63LS1rwjZM/c2fas3ollUFAkiKvNBt96yoXguuFaBDHum0+Cwa46g2dak7aJjgJcBSrPqL KE3ln9Wj0lcjXg2mIY6zOI/SGIjLhRkBBSN/ee9/NJ0LTdWPxhyT+eDy0ZwD7K3o9I9HL15hMHh9 PA/WOW73r5YFzjuFxmEkz0NHjq7lKJg7cjyVsSMnU9k1T6dy5MjZVI4dOZ/KiSNbzGM5dffSohvr o722mz3WM1efgIuwyxV/QG6kT9FhFx2esAvno/VN4WGXLZ7Swy5cbPH1h9k9JNt3rzwWaI7jODAL Lt8KlOZJbjv6rYWso0pJKY+PwxvaczxMO0eaaScPG1XRHemYfqJHvdVvjC7viRnbbOTQ+rqRHiMm 0VE++7a1q3ND2AvDLcQ0RD7aPz1he0iSDHkQ80Set+8FipMstJQ1syGUPPIH+d3mA5OS+NAFCf4x e8h7m46X2ujOKhQ44dz4fKfS5GHjaXQlWF2ta8Zsx2Qx+plJ74XA0/Sxzw5XUfapltuOlMDut4bP mDaRZEHJlUBJL5TqSijVBcdXg8M/8xjQhBc0Jwg3PgbKwCe68OmP5Y1PD2XgE1/44CjD6Q3QicoA KHEA5WFuV38DZKgMgNILoDDMU/sVuAEyVAZAmQMoi6Nbjj5TGQDlF0CGzi1Jn6kMgOYOoDTJbkn6 TMXeZKdXzHYB7eFuCy2vk3WB/vl9vVo/hFE0C9JoPYvDh2SWw0dvNv+yjtYJfljhYPWvqRNxYm7E f3R1RcHkVMfiZFLJNnUphRI7fVeKZiiJ/Va8UtmK2lbFOOzr2N51byztpRy2RMgaSl7wFPIdea1Q pvpMbaEKoSWzu6/k/vlMeRWvopWtH/xziG1Z3+tHhCdT+Gj9D1PbdnBY5AD19Hsackv45X8AAAD/ /wMAUEsDBBQABgAIAAAAIQB7pbM6EQMAADcJAAAWAAAAcHB0L3NsaWRlcy9zbGlkZTE0LnhtbLRW 21LbMBB970z/QeM+G8eJcx0CEwfSMkMh08AHCFmOPciSKikhaYd/70q2Ey5hoBBeLFlarc45q9Xq 8HhVMLSkSueCD73woOEhyolIcj4fetdXE7/nIW0wTzATnA69NdXe8dHXL4dyoFmCYDXXAzz0MmPk IAg0yWiB9YGQlMNcKlSBDfyqeZAofAdeCxY0G41OUOCce9V69Zb1Ik1zQk8EWRSUm9KJogwbQK6z XOram3yLN6moBjdu9SNIR8CMzFhiWy2vFKW2x5fflZzJqXLTF8upQnkCenmI4wJk8YJqojJzv3zp OsGT5fO6iwerVBW2BW5oNfRA/LX9BnaMrgwi5SDZjpLscoctyU53WAf1BsGDTS2rEtxzOs2azlVu GEXhhlWNV8tzQW414gL4WPolvY1Fydm2MkNmLcGVsa4qu3LSdbZgKrHMKhbJ2m5yA60bxAOmzcys GXU/0n4cDAV4GbYnlHL/euahJFfGsUa6MGNGMd9IY47OtF5Q9K1l9TBOFeeE8mSKFf71oq9SQekA 1+iCWr6XRWzVIo4FN3DE0JRhQjPBEqpQ82OS5slqa7IHNcEcFVidO+lyngBc18VsDgoSozznYnEB uV/JUaJ+VbyngSiV/PRt97bTK+esOlo/xB0yAuEkgetEI5NRpGmR+0TwNJ8vFL6BNPrfc/c50r0j cbCWlBj9lMDbpBGpk+OWrkkG9yoqRELZ8SNX78muqM6uGcsTii4WxQ2k1cMUa+3j1oLaBq5BlT9D 7/cCK0OVV2WfS+H9pF8KFdSS+juJ21H/JG74o34XSm4cnfq9sAOfcdzqjXpRvxVN7r0NNmDOAd3O OOyIYxhtZU9tZfvY5eeaujBClTrXpuqhhcqBTRz3O81xL/bjMJr40Um/648mnbY/abeiaBz3RuPW 6b0ttGE0IIq6GnxWvyVg8Fn9LnKihBapOSCiqB4CgRR3VEmRu7dA2KgeFEvMIEb9Tj/strtRu4oV YKtbh9ZGv6rxhKmfWF4u3UmBzSDSYzck4bFSHZStieUO6/4BAAD//wMAUEsDBBQABgAIAAAAIQDJ ce14rggAAB1YAAAVAAAAcHB0L3NsaWRlcy9zbGlkZTgueG1s7Fxbb+M2Fn7eBfY/ENqXFljH4kUS FTRTxJ5xu8C0Dep03zUSHQuVJS1F59KiQH/G9u/1l5QXSb5EsjMZ2Yl3lIdIpsgjHvL7SJ5zKH71 9f0iAbeMF3GWXljwzLYAS8MsitObC+un68mAWqAQQRoFSZayC+uBFdbXb/7x96/y8yKJgCydFufB hTUXIj8fDotwzhZBcZblLJXPZhlfBEL+5DfDiAd3UuoiGSLbdoeLIE6tsjx/SvlsNotD9jYLlwuW CiOEsyQQsubFPM6LSlr+FGk5Z4UUo0tvVOmN1CycJpG6Fvk1Z0zdpbff8HyaX3H9+PvbKw7iSLaX BdJgIZvFGpYPymz6Z3qrb4ZbxW+q2+D8fsYX6ip1A/cXlmz8B/V/qNLYvQChSQxXqeH8h4a84fxd Q+5h9YLh2kuVVqZyj9VBlTrXsUgYgLVWVX2L/H0W/lyANJP6KPWNenUOo7O65nMgHnIpSihRZT7z UN+sKlM2lrgfZdGDeskHedWJwXlSiKl4SJj+kat/uhpc1jcJFEJZOvhpaoEo5kJrDYqFGCcsSOum EW+ueJZnRZCAfyLVJEI3jJbD0ugq4MGPreJMI+a6zlUFh1ULtrcjqdpxmsQRA98vFx8YB1dJELJ5 lkTyHnfRtJKAUrTU+ZcL67/LgAvGLfl+iQKIumvxmaS5UurXycgh/tuRPbj0PTkujMi7AYWu/Dce YXpJiY/J5DerrpvUPJW1a+yvhl6iq76ZKfYdrnecGuWSYqPsHpCNzgBKlGpDk7pO4vUmbKAvdh3f 8zxNTIR9FxHdDSsqQ0pdRF1DUYyp4+hX1zyVyvBCfMOyBVA3FxZnodAtGNy+L0Spb5lFgyaTzTyJ k0T/4DcfxgkHt0FyYU3k33hcSt/IlqTgTtbPIbatRW/KUCMmq6UEYSgHSYPFjZxDJadsbdMm22gC dzyQOE7lrGEBLpJxlqg+M1C/XIpsEpcKmfwfQ3cFeOjK+q8Rn3Gux+MGaMVMzLaY/3S5DfIGxUMh 2GLwM3sI53LOeOKo0iD9mQh2txHsdIRg5FGIqa8RjAmG1NtGMPYIdPxDIbgJfVgXT5aL77LIpEvk 2mVnyGQ1H+pkt0pWUK0k9fg/AP6fLWxHJYti3i1HGZfL2qNT09umptsRNR3bgQ6EO6iJsGsTckxq Oo+oiZqpSXtqnjA1RVJ0WscwiWXXHZ2adJuaXlezJkTEQcYgI65c+VUUqKnpYR9T75jUJD01Pwdq pkyEWdrx6vZlZk5/m560I3oSW8LWwSU9MbGpnpPX6QkJpqXnpKdnT8/OKslZ0T0/Dzp9hvfptKTo WN0+8njWLs+p4EF8MxfgkvPsDoyzNJW0yDiA+hW6UC1C4kPIH5X1qp1U1SSZRtUTp3xSea/WJWxS fi15nfVglsT5f1RvrLtliEuJa4xa5GHi+dv8h5gQBxr+u75nezpDO/+LUvVaZ/O+ltFAcUr2VRAn 79Ko8oryWPZSIlkkaZvcWCBhqb4xxbdoWCj+GFE/slnVRnuprXNrF56kd12wpOuugmV+3UazmdSw LmwU3Vm4LqHfnKWrwos4zXiTAHFfv9nkN9obrRUOKlDuRSfej04NrnZ0egdG57d6rGjCKXFt5JfL yGac2q7rKhV7nJ46TmsPXjtOVz69RpzSVpxW42u3oyjyfYIgMf4Hz7MJ2kIn8QhyHANO6kj47llE 9eB8peBEdRiwFZxoFRr8SHDCw8zx+9FJiY3Vy3t4vnJ4tluIqn83TUS4GUf9BO+q5yFiInctcQ+b Qq+Pe/Qm4muPe7yQc1UNrVvc7Cqs7kGKHbibnMhG5bq4j3z05Hy1kY8Xcq0qo3KLnH5XE6dvQ6wm Ru1cJRAhHVVZd65SGx93x0DvXO2dq6fG0EdLW9TV0hZR33HN7NkcnHQ9TOw+ONkT9BSCkx+/vFWg 6Cj4geoYZbtnZBW1bPSMKKK3uUaqR926RiBELvLKjUNNrhFoO7ZbbkrtPSMn7LjD+x13eI/jbgc8 q8DIkdFJHIJllh6epw/P2kXQDs+Vz6ARnv6R0UkoRS4xW0ca0elRl/rlzhHqYtfd/PCmB+fJgLPe HdgOztV+weax0z521MP1fOgo27p9aifI9yp8eja1q+bq8XkqUQ+y+iqv+l5p88O8T/CsUjm3UmfH zjgb2Z5a9R7PNnSPGvbY/GRqXWJvGNbfOiXZzQvtNsO147Ld4Fp5MhtH5dqqOtZ2M4gwxLj8CrBp G498CB3ab+P5P1g07N9uhvdsN6tXBq9wvxmWSHbtcvTvgXrKQN2/3wzv2W+mliEHtb3ageq4ru8o rrUtc5FLCVQR4t4MO3Wg7vew4j0e1h1A7cgMa0eqRzFx1Hq5DakO9CEqd5r3QD1Ne6ye9Gt7bDXH P8MeW0Fq3bJ3oOeZEQ9ihz6KqlOIbLv6otCVtptx7D7fMEszZeyYeu4xcwp11kj3hs5OM+R6Hhcg SJLsrgCzpVhyBkyktgBfsLObs3+BJxk93ZpQTzGcvgQiA5zNGGdpyICYMzCdfguCNBrKsez6/RQs smiZsAJEPJgJqWQBUsYiFp0f6bAa9OiTdTNodXEgihzgsPHtO8R1kNk2vL5lHBJafXgH5XKTYG3N HQXGx7LWSzyQLq3yCixfpJkAcRomS3Vgl0bXn7//zyDvz9//MNm+3ESSwcgztfhbp74FU7+DxJ4/ 3693d5xN82ldP3jaGPvEivZd33nXn8725O62WfVg7sH8wgeZvDyY+0n5MwTzqdTzgGcgHHK3rr5U x79Kg0WaG+UdWPL4wvp1NPJdNKajwQiSyYC89b3B5cR1BhMHEzIe0csxfvebOk4WkvOQM33S7L+r E3Nl4qNTahdxyLMim4mzMFuUx90O8+yO8TyL9Ym30C6PzdW+DGk7OYQiaNwPQ1236qprq/wZ5Um2 YcK/C/IfbnUDyZcJxsc6KZd2Q+kLW2VRustyfwEAAP//AwBQSwMEFAAGAAgAAAAhADCS0gJhCAAA rlQAABUAAABwcHQvc2xpZGVzL3NsaWRlNy54bWzsXNmO4zYWfZ4B5h8IzUvmwW1xEUkVUh2U3e0k QJZCqjPvapkuC9EWSq4lQYB8xszv5UuGiyQvJdm9yO5yjxqNkkyRl7zkOSTv5fLlVw9JDO6ELKIs vXTgC9cBIg2zeZTeXjo/v5mNuAOKMkjnQZyl4tJ5FIXz1ct//P3L/KKI50ClTouL4NJZlmV+MR4X 4VIkQfEiy0Wqvi0ymQSl+ilvx3MZ3CupSTxGrkvHSRClTpVevkv6bLGIQvEqC1eJSEsrRIo4KFXJ i2WUF7W0/F2k5VIUSoxJvVWkl0qz8Cae62eRv5FC6Lf07muZ3+TX0nz+4e5agmiu6ssBaZCoanHG 1YcqmvmZ3pmX8U7y2/o1uHhYyEQ/lW7g4dJRlf+o/451mHgoQWgDw3VouPyxJW64fN0Se1xnMN7I VGtlC/dUHVSr8yYqYwFgo1Vd3iL/Lgt/KUCaKX20+la9JobVWT/zJSgfcyWq1KKqePajeVkXpqqs 8mGSzR91Jm/V0wQGF3FR3pSPsTA/cv3HFEOq8saBRqhIRz/fOGAeydJoDYqknMYiSJuqKV9eyyzP iiAG/4S6SkpTMUaOSOfXgQx+6hRnKzE3Za4LOK5rsLseSV2PN3E0F+CHVfJWSHAdB6FYZvFcveM+ qlYRUIlWOv926fy6CmQppKPyVyiAqL8aXyiaa6V+n0084r+auKMrn6l+YUJejzik6s90gvkVJz4m sz+cpmxK81SVrrW9WlqJrdtmodl3vNbxGpQrik2yB0C2GgNoUboObegmiTersIW+mHo+Y8wQE2Gf ImKaYU1lyDlFnFqKYsw9z2Td8FQpI4vya5ElQL9cOlKEpanB4O67oqz0raIY0GSqmmdRHJsf8vbt NJbgLogvnZn6N51W0reixSm4V+XziOsa0dsydI8pGilBGKpO0mJxK+ZYy6lq29bJLprAvQwUjlM1 ajhAlvE0i3WbWahfrcpsFlUK2fjvQ3cNeEhV+TeIL6Q0/XELtCJRLnaY/+5yW+SNiseiFMnoF/EY LtWY8Y69Sov0D0Qw3UWw1xOCEeMQc98gGBMMOdtFMGYEev6xENyGPmySx6vk+2xuwxVy3aoxVLAe D00wrYM1VGtJA/6PgP8PFrankEWx7JejQqpp7cmpyXapSXuipud60INwDzURpi4hAzUHavZMzTIu ei1jGEeq6U5OTb5LTdbXqAkR8ZA1yAhVM7+aAg01GfYxZ6ekJnlCTdROTT5Q84ypmYoyzNKeZ7ef ZuT0d+nJe6IncRVsPVzRExOXmzF5k56QYF55TgZ6DvTsrZBSFP3z86jDZ/iQ3lQUnerXJx7PxuV5 U8ogul2W4ErK7B5MszRVtMgkgCYLk6gRofBRqh+19WqcVPUgmc7rL171pfZebUrYpvxG8CbrwSKO 8n/r1th0yxDKCbVGLWKYMH+X/xAT4kHLf+ozl5kI3fwvKtUbnW1+Hb2B5pRqqyCKX6fz2isqI9VK sWKRom1864BYpObFJt+hYaH5Y0X9JBZ1HR2ktoltXHiK3k3Ciq77ElbxTR0tFkrDJrFVdG/iJoXJ OUvXiZMozWSbgPKhydnGt9pbrTUOalAeRCc+jE4Drm50siOj8xvTV7ThlFAX+dU0sh2nLqVUqzjg 9Nxx2njwunG69um14pR34rTuX/vtRZHvEwSJ9T8w5hK0g07CCPI8C07uKfgemEQN4Hym4ETNMmAn ONF6afA9wQmPM8YfRicnLtaZD/B85vDsthB1+26biHB7HfUjvKuMIWJX7jrWPVwO2bDuMZiIz33d 4xM5V3XXusPNvpbVGeTYg/vJiVxUzYsHcg7kfLYrH5/ItaqNyh1y+n0NnL4LsR4YjXOVQITMqsqm c5W7+LQ7Bgbn6uBcPTeGPpnaor6mtoj7HrWjZ/viJGWYuMPi5EDQc1icfP/prQZFT4sfqFmj7PaM rFctWz0jmuhdrpH6U7+uEQgRRazaONTmGoGu59JqU+rgGTljxx0+7LjDBxx3e+BZL4ycGJ3EI1hF GeB5/vBsXATd8Fz7DFrh6Z8YnYRzRIndOtKKTsYp96udI5xiSrcP3gzgPBtwNrsDu8G53i/Y3ne6 p171oMyHnratu4d2gnxW45O53K2ra8Dnuax6kPWpvPq80vbBvI/wrHI1tnJvz844F7lMz3pPZxvS k3pWt49MbUocDMPmrFOc3X6i3Wa4cVx2G1xrT2Zrr9xYVafabgYRhhhXpwDbtvGoj9Djwzaez2DS cHi7GT6w3ayZGTzD/WZYIZm6Ve8/APWcgXp4vxk+sN9MT0OOant1A9Wj1Pc017qmuYhyAvUK8WCG nTtQD3tY8QEP6x6g9mSGdSOVcUw8PV/uQqoHfYiqneYDUM/THmsG/cYeW4/xH2CPrSG1adl7kDHb 40Hs8Ser6hwi121OFFIf23nGhxtmaaaNHVvOA2ZOoe8a6d/Q2WuGvFlGBVD/VcNGySoBd1HwNhZA WWkrfYPPxYkudnnS9B/V8ptnVFRXgK0X3PPUnAs+2VwNCa+PqEGXMQRNN3iSBj+ZXdvS8BjMZbAo C/BFmpUgSsN4pe+mAuVSgL/+/I+1Tv/687822r+2gWCb+H2LUeX8t17NaFu+oyyz/v8eVN1zDcvQ 9J9105/DTtzzuYqhbdfTQKCBQJ9pOY94KvuY+wfNo76QUk0M1bSuegMrGV06v08mPkVTPhlNIJmN yCufja5m1BvNPEzIdMKvpvj1H/qCS0guQinM3Zff1nd4qsAn92YmUSizIluUL8IsqS7gHOfZvZB5 Fpk7OKFbXeRprCsfcox9ajcXj03R6qcprDawqqs1w1h+H+Q/3pn6UXmVQk5NUK5md5Vxvo6iVVfp /gcAAP//AwBQSwMEFAAGAAgAAAAhALodRjFQCAAA1UoAABUAAABwcHQvc2xpZGVzL3NsaWRlNi54 bWzsXNtu5DYSfV9g/4HQ8/a0eBFFGekJ3D3ubICZZBBP9l2W2G4haklL0bcNAuy37Kftl2yRuvTF ktt2ZM94IT9YaoossornkKwipe++v92k6FqqMsmzmYPfuQ6SWZTHSXY5c379spwIB5U6zOIwzTM5 c+5k6Xz//q9/+a44KdMYQemsPAlnzlrr4mQ6LaO13ITlu7yQGTxb5WoTavipLqexCm9A6iadEtfl 002YZE5dXj2mfL5aJZH8kEdXG5npSoiSaaih5eU6KcpGWvEYaYWSJYixpfea9B40i87T2FzL4ouS 0txl1z+o4rz4rOzjn64/K5TEYC8HZeEGzOJM6wd1Nvszu7Y304Pil81teHK7UhtzBd3Q7cwB49+Z /1OTJm81iqrEaJsarX/uyButzzpyT5sKpjuVGq2qxt1XhzTqfEl0KhFutWraWxYf8+i3EmU56GPU r9Rrc1Q6m2uxRvquAFHaiKrzVQ/tzbYxtbH07TyP70wlF3C1ieFJWupzfZdK+6Mw/2wzFLQ3DQ1C ZTb59dxBcaK01RqVG71IZZi1ptHvz5MskujHsy9LFHjok5QaYGiMo62JrESZxZ9DFf7SK7gyZ2Fb 3zR12tiy36Ksseh5msQS/XS1uZAKfU7DSK7zNIZ7OoSRgYogGrT/18z551WotFQO1A94wGQ426+A 8Eap35dzjwUf5u7kNPBhhJizs4nAHP4t5lScChZQtvzDadsGmmfQus6e6+gvvu2bleHhy/WO1+Id yDbPbxHb6wxkRBkbVqm7dN41YQeRKfcC3/ctRQkNOGG2G7akxkJwInhFVkqF59mqW8aCMqrUP8h8 g8zNzFEy0taC4fXHUtf61lksaHIw8zJJU/tDXV4sUoWuw3TmLOFvsail72VLM3QD7fOY61rR+zLM 2ClbKWEUwXBZYXEv59TIqa1d2eQQTehGhYDjDOYPBymdLvLU9FkF9dMrnS+TWqEq/1OIbwCPObR/ ZwiQStmRuQNaidSrA+Y/Xm6HvEl5V2q5mfwm76I1zB6PHFU6pD8TwfwQwd5ACCa+wFQEFsGUUSz8 QwRTn2EvGBH8xhH8bGEPNLIs18OyTCpYor46ufxDcvGByOW5HvYwfoBchHKXsZFcI7nuCdVpOWgb ozSBrnt1colDcvlDzVyYMI9U7hHjsPpyDxwq7NOACn8k10iue0IzqaM8G3iN+HVmr+CQYGIggjEX YOvRmmCUucLOi7sEw4yKOhIxEmwk2I5QJcvhGfaiU1h0m53XJFuY23sxwDYIeK5VmFyuNTpVKr9B izzLANi5QthWYQu1IgAfGn40XpwN1jQTVRY3T7z6SRPF2ZWwT9qd5F3eolWaFP8wvbEbnmBcMF45 d8SnzA8OGYwpYx6uGMwD3/Vthn4Gl7Xqrc5VfT18NpyCvgqT9CyLmzihSqCXUmAR0Da9dFAqM3tT FT+gYWn4U4n6Ra4aGx2lts1tQ1lA77ZgTdeHCtb5rY1WK9CwLVwp+mDhtoStOc+2hTdJlqsuAfq2 rbnKX2lfaW1w0IDyKDrpcXRacPWj039hdP7djhVdOGXcJUG9lOvGqcs5NyqOOH3rOG0jWf043ca2 OnEqenHajK/DjqIkCBjBrPLifd9l5ACdzGfE8ypwCg/ge2QZNILzGwUnaTfGesFJtptlTwQnfpk5 /jg6BXOpqXyE5zcOz34fz/TvvpOH9/cT/0SM0vcJq3aweuL/rsD+GP8fnbyXj/9/pRClGRwP2DXU BrGPBfXww/QiLqlXtiO9Rnq94A7AVwpQGsfugF7BUJNX4GJqJicbomSYELu7sBuiFC4dd69Her1W iPJrcezeApEMtUAkIvB4NYN1b7NxnzJ33GYbKfY622xPXyQaUAy0CUDa3bb+CMF2/60zQmCo2hci aB4NGyLAmHDi18dQukIE2PVcXh9SHCMEbziARY8HsOiRANYD8Gw2CF4ZncxjFLKM8Hz78Gwd7X54 bj3vTngGr4xOJgThrDoE0YlOX3AR1GcgBKec77+SMYLzzYCzPanWD87t2bXusdN97eg/9wPsGf+2 f2pnJPAbfPqucBtzjfh8K9F/tn1fq3l/Zf+VrT8RnxQwtwrvgTNeLnF9s+p9Ge+uy9jcFk+vNp/y uEqHBXzjdUKyeTHOJvMm2bhxjaSn+ob7/uWuxNExbN99SfPHvkg39Kkr2gYP+x2ubTSxc1RuvarX OnaFCcWU1m+FdR1ngYfYE+Nxlv+DRcPxY1f0yLGrdmXwDZ67ooBk7taj/wjUtwzU4+eu6JFzV2YZ 8qK+Vz9QPc4Dz3Ctb5lLuGDY7LOObthbB+rxCCs9EmF9AKgDuWH9SPUFZZ5ZL/ch1cMBJvWJ6xGo b9Mfayf91h/bzvHP8Me2kNr17D3s+9WIh6kn7u1sC0xct3m7jYPvVgV2n++YZblxdqp2HnFzSvPt ieEdnQfdkNM4ljF6lGMzrJv0GOfob2ilwNCxClf6cRtpr9nG4RqUSb3J48HMhtB+h1ZuYvMPJG5C 9RHGVEYCDwSl16ltWJLFMAbMnAkRnu9V4Lu4WgKd7Yi3CiOg5imMeimwYx2qUuq27ourBaTY5Jnz 33//p/FOK6Q+Q5Us1/IE1fqAcWSKkhJd5HqNQlTtVaIQxuIQPelowGO8Z3tpvlwE4wLQur5DVyqZ Ob/P5wEnCzGfzDFbTtiHwJ+cLrk3WXqUscVcnC7o2R/mS0iYnURK2o8k/dh87AkS731gaZNEKi/z lX4X5Zv6S03TIr+RqsgT+7Em7NZffLKDLcYMRim7rpzahjVX21Qz2tZfYIpS9Sksfr62NoGatFQL m1Qk2WU9U2+zGMWh3P8AAAD//wMAUEsDBBQABgAIAAAAIQATnU8HawcAAAc/AAAVAAAAcHB0L3Ns aWRlcy9zbGlkZTUueG1s7FvZjts2FH0v0H8g9FjAY3GVOKgTjJ1xGyBpg0zad0Wmx0JlSaU4W4sC +ZD25/IlJSlKXkaKk1YOYkR+sDbyivfyHC6H4vdP79cpuBWyTPJs4sEz3wMii/NFkl1PvF/ezEeh B0oVZYsozTMx8R5E6T198u033xfnZboAOndWnkcTb6VUcT4el/FKrKPyLC9Epp8tc7mOlL6U1+OF jO601XU6Rr7PxusoyTyXX35M/ny5TGLxLI9v1iJTlREp0kjpkperpChra8XHWCukKLUZm3unSE+0 Z/FVujDHsngjhTBn2e0PsrgqXkn7+KfbVxIkCx0vD2TRWofFG7sHLpm9zG7tyXgv+3V9Gp3fL+Xa HLVv4H7i6eA/mP+xuSfuFYirm/Hmbrz6uSVtvLpsST2uXzDeeqnxqircY3dQ7c6bRKUCwMarurxl 8SKPfytBlmt/jPuVe02KymdzLFZAPRTalDKmXLrqoT3ZFMYFS91P88WDeclbfbQ3o/O0VFfqIRX2 ojB/thhSlzeNDEJFNvrlygOLRCrrNSjXapaKKGtCo57MZb4Gzy/fzAGn4KUQSqPQxEbZCFmDIlu8 imT0utNuFc3CFr4u6bgOZXdASR3QqzRZCPDTzfqtkOBVGsVilacLfY77iLFmojatnf9j4v1+E0kl pKffr+EAUX+hX2q+G6f+nE8p4c+m/uiCB7qBmJLLUQiZ/ptNcXgREo7J/C+vKZv2PNOla624luqi m7pZGhoer3ZoA3fNtWl+D8hOZQBjysSwurvN5u0QtvAYE0gRCi1DESXU58EupxH0/ZCziquYcYyr etpYKmSpfhAauOZk4kkRKxvB6PZFqZy/LokFTa7DPE/S1F7I67ezVILbKJ14c/2bzZz1nWRpBu5s +Xzfmt61YZpO0ViJ4li3lhUWd1KOjR0X7Som+2gCdzLSOM509+EBqdJZnpo6q6B+caPyeeIcqtL/ N94LKW1z3AKoRKjlHt//QysyKh9KJdaj38RDvNIdxWdqQdg+RmlPGEUIE4qYxSimnITMQnCDUQ1h P/ThgNETwugnmvhAgcpy1QdnhNRjy89ElWCfKqwnqhDuExpwRxXGKLe99hZVND1Y4IZeA1W+Mqqo tOyhPHGa6Cr5TFQJ96lixyd99CqEQ2yYoEtHAuoHId+jCseIETpQ5aukSiZUnGe9jMY+Z8/C9+kS 9tWzhHqa4AZhJAhQQO3wbpsuvuYIGujyVdJFirIvvhyhe4nvsytHmZk5fSSONerYlZJRcr1S4ELK /A7M8izTMM0lgPYVNlNjQte20hf17MfKGLUkli3qJ9Q9qfWNbQu7FNy6vc1CsEyT4lcT+e3ui3PC UVBN3DkkBO13XyTwA8IrPrLQJ9gOBbv5WDrXG5+r93Ww0zBE11CUpJfZohbQZKLrJtWc0CRMrz2Q isyeVNn3SFUaNlSmXotlHaODRLWprcijydpkdOT7UEaX3sZoudQeNpkrRz+Yuclh35xnm8zrJMtl mwF137y5Sl95X3ltcFCD8iA68WF0WnB1ozM4Mjp/tO1CG04JYZQFVb/RjlOIcIBDh1OKILPa1oDT 08NpowB143SjCbXiNOzEad2+Hgun2+0p5oxAbmG4wSlhKGBOBw1CPbO2rgwwPTmYombtqBOmaLOe 9Ikwhcfp7TGhgR5SO3RiytHe6JsghHzdclp4hpCEQyv6hcKze+4GmzW4evIGd9fc/scyD9VtmoNP q4JOKCQID5O3QUE/DVnQtLN7XOlrSZRx5iNck6VNQyeY+8SNWAeyDBr6ly4KIv8RWewkrAeyBD6F 2Iw7umXBgGE4LDgNsuBJMebRUAz1NRSDfhiakV4nYUKGEQsGwgzLTqcmo6Nm9al7Zr1Zj2qdWRvi dU2t60f9Tq2hT3xiRnNdwg/myOhCdmLth5TVSB8m1qel+5i1yQPoxAd0nw+gs1bYjwnONt2HkpDX smSIWYh3v6ce4Hky8GxmtN3w3ExxW+HJj4zObvWc0pATN6ppxake1YSBmzIPMD1lmDYfZHXDdPOJ Vnsr6h9bPu8GasACHtB6macFqPpWwNxXLANQTxio5PCqOTmwat6MOLuXzbf2vPTS3QecBbRaLA+Q kU72dmNgTCl1On3IqM+tkDPA8/TgeXixnBxYLG8ay254Vp/8HKO/hwya0XAnUCHDzIjoQzt6suuR 5uOxvV1n/+tr0g2mtpAUEgxZ9RU2xDjUXfIukBiDPqoXtvuQw7LcqFNVOQ/oUqXZoXhMZapFt3mW lPFNafY4g7uoBCoHUVrmYCGWSSaAWgnw/t3f/elNPQlg3zm56f27f8A6X9ykogS69HciTc/OznoU oeyh3uqsMaKr2J2BG5lMvD+nU87QLJyOppDMR+QZD0YXc0ZHc4oJmU3Dixm+/MtsnYbkPJbC7qp+ Xu8O1zcf7cheJ7HMy3ypzuJ87bZ2j4v8TsgiT+zubui7LeKWeJhDGNKg+jrIlqw+2rIa6rk923Eq X0bFz7c2KPpVSsiZvVUk2bVrtzdJjOc6378AAAD//wMAUEsDBBQABgAIAAAAIQBtx24PpggAAL1Y AAAVAAAAcHB0L3NsaWRlcy9zbGlkZTkueG1s7FzZjuM2Fn3OAPkHQvOSAOO2uIoqxB2U3e1kgCyF VGfeVTJtC5ElDcXaEgTIZ8z8Xr5kSGrxUpLdi+wqT9RolGSKvOIlzyF576X41dcPqxjcCZlHaTJy 4CvXASIJ01mULEbOz++mA+6AXAXJLIjTRIycR5E7X7/+/G9fZRd5PAO6dJJfBCNnqVR2MRzm4VKs gvxVmolEP5unchUo/VMuhjMZ3Gupq3iIXJcNV0GUOGV5+T7l0/k8CsWbNLxdiUQVQqSIA6Vrni+j LK+kZe8jLZMi12Js6a0qvdaahdfxzFzz7J0Uwtwld9/I7Dq7kvbxD3dXEkQz3V4OSIKVbhZnWD4o s9mfyZ29Ge4UX1S3wcXDXK7MVesGHkaObvxH83do0sSDAmGRGK5Tw+WPDXnD5duG3MPqBcONlxqt iso9VQdV6ryLVCwArLWq6ptn36XhLzlIUq2PUb9Qr85R6Gyu2RKox0yLUkZUma94aG/WlSkbSz2M 09mjecmNvtrE4CLO1bV6jIX9kZk/thpS1zcODEJFMvj52gGzSCqrNchXahKLIKmbRr2+kmmW5kEM /o5NkyjbMFaOSGZXgQx+ahVXNGJm61xVcFi1YHs7kqodr+NoJsAPt6sbIcFVHIRimcYzfY+7aFpN QC1a6/zryPn3bSCVkI5+v0YBRN21+FzT3Cj123RMif9m7A4ufU+PC2PydsAh038mY8wvOfExmf7u 1HXTmie6do391dBL/rpv5oZ9x+sdWqNcU2ycPgCy1RnAiDJtWKRuknizCRvoixn1Pc+zxEQIMQj9 bSpDzhnirKAoxpxS++qap1oZmatvRLoC5mbkSBEq24LB3Xe5KvUts1jQpLqZp1Ec2x9ycTOJJbgL 4pEz1f8mk1L6VrY4Afe6fpS4rhW9LcOMmKKWEoShHiQLLG7lHBo5ZWsXbbKLJnAvA43jRM8aDpAq nqSx6bMC6pe3Kp1GpUJF/g+huwE8ZLr+G8QXUtrxuAFakVDzHea/v9wGeYP8MVdiNfhFPIZLPWe8 56jSIP0jEcx2EUw7QjDyOMTctwjGGsAe2UUw9gik/rEQ3IQ+bIvHt6vv01mRrpHrlp2hk818aJNZ lWygWknq8X8E/H+0sD2VzPNltxwVUi9rT05Nb5earCNqUpdCCuEeaiLMXEJOSU36hJqomZq8p+YZ U1PFead1DONId93Jqcl3qel1NWtCRCgqDDJCKDZrwG1qetjH3DslNUlPzb8CNROhwjTpeHX7PDOn v0tP3hE9iathS3FJT4Z9Zq3vTXpCgnnpOTk2PW8W6Ak1/Z6DZ8xBKfLuSXjUOTJ8SK5LHk7M7RO3 Zu3XvFYyiBZLBS6lTO/BJE0Sjf1UAmhfYQvVIjQ+lP5RmajWE1U5M5NZ9YSWTyoX1aaEbV5vJG9S G8zjKPuX6Y1N3wthnLDCckWUEebtkhxiPTfDguTM91zPrszbSZ6Xqtc6F+9robzhlO6rIIrfJrPK 9Skj3UuxZpGmbbxwQCwSe1MU36FhbvhTiPpJzKs2Okhtm9v66TS964IlXfcVLPPbNprPtYZ14ULR vYXrEvbNabIuvIqSVDYJUA/1m4v8hfaF1gYHFSgPohMfRqcFVzs6vSOj81s7VjThlDAX+eVasRmn LmPMqNjj9NxxWrvp2nG6dtw14pS34rQaX7sdRZHvEwRJ4WTQEwp2d9BJPIIoLcDJKdY/e3CeJThR HetrBSdax/8+EJzwOHP8YXRy4mLz8h6eLxye7Wag6d9tOxBuB0s/wYXqeYgU4bmW4IbLodcHN3oT 8aUHN57Jg2qG1h1udhU79yDHFO4nJ3JRuS7uwxs9OV9seOOZ/KfGqNwhp6VQFxOn70JsJkbrQfUg dC33Nj2o3MWn2hbQe1B7D+oLpuGT9Svqav2KuE9ZMUU2hxmZh4nbhxl7gp5DmPHD17AGFB1FOFAd bWx3f6zjj43uD0P0Nv9H9ahb/weEiCGv3ALU5P+ALnVZub20d3+csXcOH/bO4QPeuT3wrKIfJ0Yn oURbdqiH5/nDs/YDtMNz7RhohKd/YnQSzhEjxSaQRnR6nHG/3APCGWZs+xOaHpxnA856n187ONc7 /5rHTvfUoQ3m+ZAaA7p9aifI9yp8ei53q+bq8XkuoQ2y/r6u+vJo+xO7T3Cfcj23crpnj5uLXM+s ek9nG7KTxja2P37alNgbhvVXS3G6eKYtZbj2TrYbXGt3ZeOoXFtVp9pTBhGGGJff8zXt1dEPIeX9 Xp3/g0XD4T1l+MCesnpl8AI3lWGNZOaWo38P1HMG6uFNZfjApjKzDDmq7dUOVMqYTw3X2pa5iHEC TRi4N8POHaiHPaz4gId1D1A7MsPakepxTKhZL7chlUIfonI7eQ/U87TH6km/tsfWc/xH2GNrSG1a 9hR6XjHiQUw5QjtBOw6R69bfBjIfF+uMjzfMktQYO0U9D5g5uTk1pHtDZ68Z8m4Z5UD/D7Q6QqlH sEi1eZgFUkXmLJ4oWfwD3EdqCcSdkI9qqRNAqi0/EceDmZhHiZiBm/Q2mQUyEvnFiU50QU++60Zd fdi9EdWlyMWoWJptuM2hnhSNx9UABFLmHxxqOkTIyQzhBqRQMJPBXOXgiyRVIErC+NYcSwXUUoA/ //hPYc7++cd/i2xfbkOh6OQPrUb55s86tbuL+h0lLvvX/UZ1zwksn9b1A9BlRfuu77zrz2d/bndb kHow92B+5uM6ng/MTZX6rJ9VzwSNx9s61oTIfrjsAfpyjm845h5ke6mOp9W2orb0yjtwK6OR89t4 7DM04ePBGJLpgLzxvcHllNHBlGJCJmN+OcFvfzfH3UJyEUphT8L9Z3Wir058coruKgplmqdz9SpM V+VxvMMsvRcySyN7Ii90y2N9rYcGco+6PqJlrMHWrbra2hovTXnSbhjL74PsxzvbQPplSsiJTcq0 xVd6+NZZjO663P8AAAD//wMAUEsDBBQABgAIAAAAIQB+wQXs2AgAAL5kAAAWAAAAcHB0L3NsaWRl cy9zbGlkZTEwLnhtbOxd647jthX+nQJ9B0H90wL1WrxTg8wGY+86LZBkB5lN/2tl2hZWllRKc2sQ II/Rvl6epLxI8mUkezOrUcY7WixGskQe8pDfR/KcQ0lff3O3jp0bIfMoTc5d8MpzHZGE6TxKlufu T+9nI+46eREk8yBOE3Hu3ovc/eb1n//0dXaWx3NH5U7ys+DcXRVFdjYe5+FKrIP8VZqJRN1bpHId FOqnXI7nMrhVUtfxGHoeHa+DKHHL/PJT8qeLRRSKN2l4vRZJYYVIEQeFqnm+irK8kpZ9irRMilyJ Mbl3qvRaaRZexXN9zLP3Ugh9ltx8K7Or7FKa2z/cXEonmqv2cp0kWKtmccfljTKZ+ZncmJPxXvZl dRqc3S3kWh+Vbs7duasa/17/Hetr4q5wQnsx3FwNV+8a0oartw2px1UB461CtVa2cg/VgZU676Mi Fg6otarqm2ffpeHH3ElSpY9W36pXp7A662O2cor7TIkqtKgynb1pTjaVKRuruJuk83tdyAd1NBeD szgvror7WJgfmf5jqiFVfeNAI1Qko5+uXGceycJo7eTrYhqLIKmbpnh9KdMszYPY+QvWTVKYhjFy RDK/DGTwY6s424iZqXNVwXHVgu3tiKt2vIqjuXB+uF5/ENK5jINQrNJ4rs5RF02rCKhEK53/c+7+ +zqQhZCuKl+hAMDuWnyhaK6V+nk2Idh/M/FGFz5T48IEvx1xQNWf6QTxC459hGe/uHXdlOaJql1j fzX0EvA2nbPQ9Hu67iE1zBXHJumdg3d6w9GidCPaq9ss3m7DBv4iSnzGmGEmRD6F2PTDhsuAcwo5 tRxFiBNiiq6JqpSRefGtSNeOPjl3pQgL04TBzXd5UepbJjGoSVU7z6I4Nj/k8sM0ls5NEJ+7M/Vv Oi2l7ySLE+dW1Y9gzzOid2XoIVPUUoIwVKOkBeNOyrGWU7a2bZN9ODm3MlBATtS04TqyiKdprPvM Yv3iukhnUamQTf97+K4RD6iq/xbzhZRmQG7AViSKxR71P11ug7xRfp8XYj36KO7DlZo0PnFYaZD+ SATTfQSTjhAMGQeI+wbBCCPA2T6CEcOA+E+F4F30fVgCkzW+Xn+fzu01Tjyvarc6+QDyJwD5o4Ud qGSer7olopBq8do7/9g+/2hH/CMeAQSAA/yDiHoY98M/SwzygINqtWw5aC7rBamlZnV5oOYJUrOI 807rGMaR6rreqcn3qcm6mhoBxARaswtTtbyrKFBTkyEfcdYnNdFAzZdAzUQUYZp0vIT9Y2ZOf5+e vCN6Yk/BlqCSngh73MzJ2/QEGPHSP9IPPR+uXnEzPelAzxOmpxR59/x80ukzvEuuSopO9ekDv2bt 2LwqZBAtV4VzIWV660zTJFG0SKUDTBEmUy1C4aNQPyoT1biiqkkymVd3SHmn8lFtS9il/NblbdY7 izjK/qV7Y9v3ginH1FqukCHM/H3+A4QxAZb/1GceMwna+Z+Xqtc62/JaRgPNKdVXQRS/TeaV71NG qpdixSJF23jpOrFIzInNvkfDXPPHivpRLKo2Okptk9o46hS964wlXQ9lLNObNloslIZ1Zqvowcx1 DlNymmwyr6MklU0Ciru6ZJveam+11jioQHkUneg4Og242tHJnhid/zBjRRNOMfWgXy4jm3HqUUq1 igNOTx2ntZuuHacbx10jTnkrTqvxtdtRFPo+hgBb/wNjHoZ76MQMQ0IsODlR8D2yiBrA+UzBCetg Xys44SYA+DvBCZ5mjj+OTo49pAsf4PnM4dluIer+3TURwW609DO8q4xBbMNzLcENjwPWU3CjzYMz mIhD3OO5Olf10LrHza5i5wxwRMBhckIPluvifshpR+aBnEPk4xRcq9qo3COn39XE6XsA6YnROFcx gNBEVbadq9xD/W0LeEhMf2Dg4EF9HjR8sH6FXa1fIfcJtVNkcwSSMoS9XiOQeIhADhHIvtawGhQd RThgHYhsd39sQpON7g9N9Db/R3WrW/8HAJBCVu4OavJ/AI94tNxeOrg/Ttg7h45759AR79wBeFbR j57RiQlGKskAz9OHZ+0HaIfnxjHQCE+/Z3RiziHFdn9IIzoZp9wvt4dwiijdfYZmAOfJgLPeAtgO zs2mwOax0+s7tEGZD4g2oNundgx9VuGTedyrmmvA56mENvDmAbvqyaPdZ+w+w33K1dzKyYHtbx70 mF719mcb0l7dp7sPP21LHAzD+qmlOF3+QVvKUO2dbDe4Nu7KxlG5tqr62lMGIAIIlc/zNe3VUTcB 4cNenS9g0XB8Txk6sqesXhk8w01lSCGZeuXoPwD1lIF6fFMZOrKpTC9DntT2agcqodQnmmtty1xI OQY6DDyYYacO1OMeVnTEw3oAqB2ZYe1IZRxhotfLbUglwAew3E4+APU07bF60q/tsc0c/wh7bAOp bcueAMbsiAcQ4Q9C5xxAz6sfG6Q+suuMxxtmSaqNHVvPI2ZOrl8b0r2hc9AMefcxuP+7U6yi3FH/ l2mULJ0iTZ1FIM96ej8LfPCQqO2UbkO0BHoI2nXW1kKMKqPCLxdigFD/6LjRYXf3ZdWWPe13ab06 cxksitz5a5IWTpSE8bV+R5XCkXB++/W/1rT97df/2WR/20WSxcgjtfiqUxvc1u9JYrQv91HWA29j eVzXNxXz1dB3T9B3J7rZ9vNGlJHTZf0GVL5IVHa2vW1A8YDi039LzIDiAcUvbcc/ql/TUNmxaPNW hs98lSWBkOu3JWhDlvqEAeOr2zJkiUex9msYQ9ZjDNoUX6IhOwwSL3GQeB57nofpbkDyF/3+sME3 85Kg2Ne7soZRcoDmF/4QojlUH6hQy3K1qC7PnGsZnbs/TyY+hVM+GU0Ano3wG5+NLmaUjGYEYTyd 8IspevuL/uAFwGehFOZbGP+svumhLj74jsY6CmWap4viVZiuyw9yjLP0Vsgsjcw3OYBXftjD7usk AHCGiNmPMjZVq46msjpKW35qI4zl90H27sa0jyqrEHJqLmVRsiwj/JskWnWV7/8AAAD//wMAUEsD BBQABgAIAAAAIQBbuX0vgQgAALBSAAAWAAAAcHB0L3NsaWRlcy9zbGlkZTExLnhtbOxc2ZLjthV9 TqryDyjmJXnQiFgJdlnjammm7VR56XKP886hoBbLFMmA6C0uV/kzkt/zlwQLSS1NSuMeSjNy2A8t LsAlLnAOLu7F8sWXj6sU3AtZJnk28eAr3wMii/N5kt1OvB/fXY24B0oVZfMozTMx8Z5E6X35+i9/ /qK4KNM50Lmz8iKaeEuliovxuIyXYhWVr/JCZPrdIperSOlbeTuey+hBS12lY+T7bLyKksyr8ssP yZ8vFkks3uTx3UpkygmRIo2ULnm5TIqyllZ8iLRCilKLsbm3ivRaaxbfpHPzWxbvpBDmKrv/ShY3 xbW0r7+7v5Ygmev68kAWrXS1eOPqRZXM3mb39mK8k/22vowuHhdyZX61buBx4unKfzL/x+aZeFQg dg/j9dN4+X1L2nj5tiX1uP7AeOOjRitXuOfqoFqdd4lKBYCNVnV5y+KbPP6pBFmu9THqO/WaFE5n 81ssgXoqtChlRFXp3Et7sS5MVVnqcZrPn8xH3utf+zC6SEt1o55SYW8K888WQ+ryppFBqMhGP954 YJ5IZbUG5UrNUhFlTdWo19cyL/IySsFfqakSZSvGyhHZ/DqS0Q+d4lwlFrbMdQHHdQ121yOp6/Em TeYCfHe3ei8kuE6jWCzzdK6vcR9VqwmoRWud/z3x/nUXSSWkp7+vUQBRfzW+0DQ3Sv18NaUkfDP1 R5dhoPuFKXk74pDpf7Mp5pechJhc/eI1ZdOaZ7p0re3V0koQrhtnYeh3vOahDcw1x6b5IyBbrQGM KFOJ7ukmizfrsIW/mNEwCALLTIQpDuAOlyHnDHHmOIoxp9R+uiGqVkaW6iuRr4C5mHhSxMpWYXT/ TakqfaskFjW5ruerJE3tjbx9P0sluI/SiXel/2azSvpWsjQDD7p8lPi+Fb0tw3SZopESxbHuJR0Y t1KOjZyqtl2d7MIJPMhIAznTZsMDUqWzPDVt5rB+eafyq6RSyKX/PXw3iIdMl3+D+UJK2yG3YCsR arFD/Q+X2yJvVD6VSqxGP4mneKmNxgd2Ky3SX4hgtotg2hOCUcAh5qFFsManpvQugnFAIA2PheA2 9FGbPb1bfZvP3XNtrf2qXPqxMYj2Ma8fG6jWkgb8HwH/Lxa2p5BlueyXo0Lqce3JqRnsUpP1RE3q U0gh3ENNhJlPyCmpiZ9Rk7RTkw3UPGNqqrTstYxxmuimOzk1+S41g76sJkSEIueREaotKOM71Axw iHkwWM2Bmj1TMxMqzrOeR7efxnKGu/S0JOqBnsTXsKW4omcIK/Zt0hMSzKvQyWA5B3r2Vkgpyv75 eVTzGT9mNxVFZ+byWciziXneKBklt0sFLqXMH8AszzJNi1wCF/WwmRoRGh9K39Teq41S1ePXbF6/ odWbOny1KWGb8huPN1kPFmlS/NO0xmZYhjBOmHNqEQsRYrv8h5gQCh3/WRj4gR20d/O/rFRvdHbf 6+gNDKd0W0VJ+jab12FRmehWSjWLNG3TWw+kIrMXLvsODUvDHyfqB7Go6+ggtW1qG8PT9G4yVnTd l7FKb+tosdAaNpmdonszNznsl/NsnXmVZLlsE6Aemy+79E57p7XBQQ3Kg+jEh9FpwdWNzuDI6Pza 9hVtOCXMR2E1jGzHqc8YMyoOOD13nDYRvG6crmN6rTjlnTit+9d+e1EUhgRB4uIPAQp4uINOEhBE qQMnp1jfDuA8S3CiZh6wE5xoPTf4O8EJj2PjD6OTEx+bjw/w/Mzh2e0hmvbddhHh9kTqR0RXgwAR N3PXMe/hcxicdN5jcBGHeY/zCa6arnWHm31NqweQYwr3kxP5qBoXD+HVgZyf7czHJwqtGqdyh5xh X4Yz9CE2htEFVzkLrd+yGVzlPh5WDAzkPI/g6qdi6LOhLepraIt4SJmznu2TkyzQFvWkk5PD0HaY nDzZ8NaAoqfJD9TMUXZHRtazlq2REUP0rtBI/arf0AiEiKGgWjjUFhqBPvVZtSh1iIycceAOHw7c 4QOBuz3wrCdGToxOQgnWSQZ4nj88mxBBNzzXMYNWeIYnRifhHDHilo60ojPgjIfVyhHOMGPbO28G cJ4NOJvVgd3gXK8XbO87/VPPerDArGaqluu3m3aCwqDGZ+Bzv66uAZ/nMutB1tvy6v1K2zvzPiKy yrVt5XTPyjgf+YEZ9Z7ON2Qn9Q23t0xtShwcw2avU5rffqLVZrgJXHY7XOtIZmuv3HhVp1puBhGG GFe7ANuW8eiXkPJhGc8fYNBweLkZPrDcrBkZfIbrzbBGMvOr3n8A6jkD9fB6M3xgvZkZhhzV9+oG KmUspIZrXcNcxDiBZoZ4cMPOHaiHI6z4QIR1D1B7csO6kRpwTKgZL3chlcIQomql+QDU8/THGqPf +GNrG/8Cf2wNqU3PnsIgcD0exJQjZGMPaxxxiHy/2VHIQuzGGS93zLLcODuunAfcnNIcNtK/o7PX DXm3TEowz0WZ/fbrfxWI0uQ2M+cWPYEHkabgIVFLoJZCS3wSMsluQZIthdRY0Rf2xSqf36WivDjR ETDo2T5w1NtGcA0M08fp4ml3nIR0BxqYaQ8krEZt0A8CBG2PeRJsnMoFrmCB+3R1wVxGC1WCv2W5 gU2c3pljsCx6fvv1P84P1uhzyf6+jSSHkRdq8adeHXZXvqNM6P7/bondc+DLxzX9CPRZ0KHpj7Tg YKTth3i2GPAlYbABKH/obfP9AeX5gMP+1EcSanOvjXV1Be5kMvF+nk5DhmZ8OppCcjUib8JgdHnF 6OiKYkJmU345w29/MUccQnIRS2FPP/xHfYqjfvjs5MRVEsu8zBfqVZyvqiMYx0X+IGSRJ/YURuhX Rzna4XWAQ844DuzatbEtWv1rC2tG2NXhinEqv42K7+9t/ehvKSFn9lGhjW7lna2TGNV1vv8BAAD/ /wMAUEsDBBQABgAIAAAAIQBlXKBPHAQAAIwLAAAWAAAAcHB0L3NsaWRlcy9zbGlkZTE1LnhtbKxW 227bOBB9X2D/gaunBKgtyZavqFPYTrxYoGmNOP0AmhrFQiiSS1KuvYsC/Yzd3+uX7JCS4zpxsoHb F1LiZXjOmSFn3r7bFJysQZtcilEQN6OAgGAyzcXdKPh0O2v0A2IsFSnlUsAo2IIJ3l38+stbNTQ8 JbhbmCEdBStr1TAMDVtBQU1TKhA4l0ldUIu/+i5MNf2MVgsetqKoGxY0F0G9X79mv8yynMGlZGUB wlZGNHBqEblZ5crsrKnXWFMaDJrxuw8gXSAztuCp64261QDuS6x/12qh5tpPf1jPNclT1CsgghYo SxDWE/Uy/yvW/iN8tP1u90mHm0wXrkduZDMKUPyta0M3BhtLWDXI9qNs9fHIWra6OrI63B0Qfneo Y1WBe0qnvaMzlcKiOmTOKYOV5Clo0nrguENv1HvJ7g0REtk5MSqyDysqBVyvVmh/s19SjfuPPaqj krTjftxvea5x0ulFg8GhOv1OJ4q73Yp1u9UdxHHvMffKtBrazUSmW7d7iX11nMCYGJdWZrklGbJe MMrBmY0ilJKLhWI3kJbMxQlCiNxwZX5vgxu7sFsOHphyjR/WqCqn7h6BaHxa4D36axS0+s5ummvr vURMYaccqHhwpb24XQFhpdbOAXhpMmwhywUYQj0Mdx8tuEtgiCnZilBDvn395w4EaJxoKJ2vXX8P 229f/yV4d900lzR9NOVYWM/FOaOG7hsQ6ZxqenOMQdx5kcGBnVfrUFOfH0D6QR0rrgS5onL6QVO+ JaWga5pzuuRAckEsCl7IFPgbsiyt+90SJkt83pZAaJpC6kVUWlpgFv+WW3IyUNDavxtHAAvKiiH6 mpbcNlIQ2wbl/NFBL3nmqaYHzlBuz5rXt/BFzMn/iuuEEtISROgV/o2QMwNAhL+YsnDhef5TAuzk mDp+t6glhubpG2JkAaS+EPsgEYDJkOzD4wyad01cbKWuHE/J7fz6VO/XKM6bp8fPEVJkIfHt0i5w DZxsuTZmtgYfF4NXgbL7UmGK9dzJ2c31+Jzk5qcizwsljclR6OZpsfJcyIf7194ngJfzXrLLewue p0A+lMUSg+D75Nf+seRntwqtY8GEpivgf5ZUW9BBnRd9cn0+MfrDH6cvr+HT3JPhu+VI/T2bdJLB 5SRqjAc9rOMmyVWjH3exmU7a/XE/GbST2ZfgARsyF4juuDufui7u7D2WuXLpeUe9xj2+21Vb+Ia8 N7b+IqXOkc1kMui2pv1JYxIns0ZyOeg1xrNupzHrtJNkOumPp+2rL656i5Mh0+ALuz92BSoOPikK i5xpaWRmm/hc1dVlqORn0ErmvsCMo7pKXVP3anZ6g6jX6/d8BRJ6bLveo3XerwtHxvU1VR/XPlLw MPT01A8prIDrQNkvcdxx338AAAD//wMAUEsDBBQABgAIAAAAIQDwn+jJdQUAAD57AAAWAAAAcHB0 L3NsaWRlcy9zbGlkZTE2LnhtbOxdW3OjNhR+70z/A8NjOxhj8HXWycRO3NmZNJtpdp86fZBBttWA xErCsdvuf68kcBw73jbZJBsgxw+AQbfvnKMPcSQ4745XSWwtMReE0aHtNZq2hWnIIkLnQ/vTx4nT sy0hEY1QzCge2mss7OOjH394lw5EHFkqNxUDNLQXUqYD1xXhAidINFiKqbo2YzxBUv3lczfi6EaV msRuq9nsuAki1C7y84fkZ7MZCfEpC7MEU5kXwnGMpGq5WJBUbEpLH1JayrFQxZjcO006UsjCqzjS e5F+5BjrI7r8hadX6SU3ly+Wl9wikZKXbVGUKLHYbnGhSGb+0qU5cPeyzzeHaLCa8UTvFTZrNbSV 8Nd66+pzeCWtMD8Zbs+Giw8H0oaLswOp3U0F7p1KNaq8cffh+Bs4Y0alko51GaMQL1gcYW61bjFu Wi/ScxZeC4syhU4LIwd7myKXgN6nC1X+apskP28Otq06KBKv6Xt+u2vAeq1m0GnvSqfTCdp+0M9R d7p+t+2bFHex50WnA7kasWitc0/VPq+OspNMshmReZ7thVjIK7mOsaktNRslpQTxcyNkQiMlIH1o yssuVO/Iiyhw5BuVJUa6K6Wxc3muutJfBoYqICJcGkWZypQdUkuuUzxTAtfyzzjBXKFaIC6wqSeH jR6SKhT/n8o1rdOp5ZGVsCiL8cDSZ2V+7VEYLMy51m4JsBAsZ98KowTNd8RaSJw4NdDENV6ri4Tu QcE0ukQc/VZqfWwbmffpt0AC6vezUwfD4zcVJoA6cDD0/Mr1fOj80PmfB0PKyRJJ7CgSEEAAVSKA f4ADgAOemwMqrImfrN9roAvt0amwEv7YafubI2TgZOBk4IFtl9j+vlklIpHjGCNaUmBCckLnMHKu JFFzVgeqQPGccSIXSYX54vgNUMVTTa1s+K7Dwa3pge8AGPBVPdhOjOlcLoACy0yBGaHSbwFVVJUq 0mwak7Ams911ebqqJ1fUbbA0JRTxfZsD6gOHHjj03oZDL8RckhkJ9USLWW4Bj0wVJAPgA+CDF+ID mHqFKReYen0iOcPCOOBnYIPdp2mYeoVRNBA1EHX9B9KVHkLDxDf4cuHG8+K+XGf1WHucGhssI/XN McXcOBDuOBMEmVM1LnI4/pxhIR9tpntwwVhfy1jzIZJzU4v3vGmaPd4UwQjLYIQFb9bCDkU2/ROH +5ZYQe3UdawIg0WgPqC+F1kmLiUn00zi/Ynnqi2SBOoD6gPq+w6PHvVYHM4yCc8eVbXCOhniw500 VdNYDZQD96qqfgGllg7dr3+SAxy4lZptAO8tWCBMIcCCrDtP+7X1X8CaLKCK0rwPngk0rzJfmNfB 60wVdfN2YpolevBOGHxJF/gPvgj0HMoB/oPPAQEDAgO+3S8C1ZkB4XNA4HN/fWAxQxH42ytvlbBa Gizw1S0Q/O1lfAH6gFMajBNCVtRj7UzdFn2WBM/3vpOV9HlNEUaj0ThAne42QKuJ2frfoWqDTaja q5hE2LrIkinmO/Fq/afFq9XYhraII1V0Lt/PGeJSY8xD2Zp4uF+PZWsq3484awR3P7LsLI4MqL8n o3bQPx01nZN+d+L0RsGZ0/M6ajMe+b2TXtD3g8kX+7ZtCjlVrdu1CEydT1e72jc1ySOvsxX7TEc4 PtCNity3VlTY3iH1mN0mQDJeyXMhiyNLGYNCMxr1O61xb+SMvGDiBKf9rnMy6bSdSdsPgvGodzL2 z77ogMteMAg5NhMd7zcxpdXJe3GcExJyJthMNkKWFAGh3ZTdYJ4yYmJCe80isPQSxUO76/e9ltfs bjStmrbZm8Zq5RehnsOY/4rSD0tjKKoupeixOZWqG31hJ9skGrrK9y8AAAD//wMAUEsDBBQABgAI AAAAIQDs9NTFlgIAAOcFAAAWAAAAcHB0L3NsaWRlcy9zbGlkZTE3LnhtbKxU4W7bIBD+P2nvwPjv 2m6cxImaVHHaTJO6NlrSB6AY11YxMCBpsqnSXmOvtyfZQexkW1Op0vqHg+M4vu87uLPzTc3RmmlT STHC8UmEERNU5pW4H+Hb5SxIMTKWiJxwKdgIb5nB5+P3787U0PAcwWlhhmSES2vVMAwNLVlNzIlU TMBeIXVNLCz1fZhr8ghZax6eRlEvrEklcHNev+a8LIqKsgtJVzUTdpdEM04sIDdlpUybTb0mm9LM QBp/+i9IY2BGFzx31qilZszNxPqjVgs11377ej3XqMpBL4wEqUEWHDYbTZhfirWfhP8cv2+nZLgp dO0scEObEQbxt24MnY9tLKI7Jz14aXlzJJaWl0eiw/aC8I9LHasduOd0ui2dZWU5Q8meVYvXqCtJ HwwSEvg4+jt6+4gdZ2dViexWQSpqtc/WhO72/eSAp9HLbjKZb909d2C9kwy5sQu75cwvlBs8Eg2Q OXGPlIngdoFRXmnriSNT2ylnROzVseNlSeyvHz8NIpyjQvIH88GpY71GPh8T+Zxo8uXFtDs9lcfe Ag1bMV+WNGklXfAqZ+h6Vd8xjeacUFZKnsO88xYqw1+E1MD92wh/XRFtmcZwPzyI+PTtlC/gxztS 32dZNxlcZFEwGfShRWTJZZDGPRimWSedpMmgk8ye8B4bMBeA7mjdjlQr7h+KU7if+H/l8ab9yPCr roxtZmilK2CTZYPe6TTNgixOZkFyMegHk1mvG8y6nSSZZulk2rl8co0hToZUM98zPrW9D5zP+k1d US2NLOwJlXXTuEIlH5lWsvK9K46aBrgmHGrUTTtJHEX9QVMrwNZaj9ZVv+lJlOvPRN2s/UuBy6DS U+9S0Fybh3IIcdzh3G8AAAD//wMAUEsDBBQABgAIAAAAIQAII/d5DQMAAOAJAAAWAAAAcHB0L3Ns aWRlcy9zbGlkZTEyLnhtbMRWXW/aMBR9n7T/YGXPaQiENqDSitCyVWItWugPcGMD0Rzbsw2FTf3v u3YS6AdVu5ZqL7Fj33t9zrF9fY9PVwVDS6p0LnjPCw8aHqI8EyTns553PRn6sYe0wZxgJjjteWuq vdOTz5+OZVczgsCb6y7ueXNjZDcIdDanBdYHQlIOc1OhCmzgV80CovAtRC1Y0Gw0DoMC59yr/NVr /MV0mmf0TGSLgnJTBlGUYQPI9TyXuo4mXxNNKqohjPN+AOkEmGUpI7bVcqIotT2+/KpkKsfKTV8u xwrlBPTyEMcFyOIF1URl5n750nWCR+6zuou7q6kqbAvc0Krngfhr+w3sGF0ZlJWD2XY0m1/tsM3m 5zusg3qB4N6illUJ7imdZk1nkhtGUbhhVePVciSynxpxAXws/ZLexqLkbFs5R2YtIZSxoSq7ctJ1 tmAqscwqEWRtF7mB1g3iLtMmNWtG3Y+0HwdDAV6G7Qml3L9OPURyZRxrpAszYBTzjTTm5ELrBUVf mlYP41RxQSgnY6zwj2djlQpKB7hGF9TyPS9iqxZxILiBI4bGDGd0LhihCjXfJ2lOVluTPagJ5qjA auSkyzkBuK6L2QwUzIzyXIjFJdz9So4S9YviPd6IUskPX3ZvK73hnH0Tt+jRGXshSuWYiUIyaigi Apk5/ccgu6Ck6TcEORtNRumDYP9Nm0IQyvTb5OGUEmQEuqGnH0Dmo9JAVKeBlOWEostFcQP3/34u aO0jvcIjDKFB898979cCK0OVV6UJl2v2kyem8NRbUn+GSTvqnCUNv985gtogic79ODyEzyBpxf04 6rSi4Z23wQbMOaDbuc07Tkl4L0dP7RP8vu1xTf2Cw3M60qbqoYXKgU2SdA6bgzjxkzAa+tFZ58jv Dw/b/rDdiqJBEvcHrfM7WxGEUTdT1BULF3XRA4NPCo0iz5TQYmoO4E5XFUsgxS1VUuSuaAkbVeWz xAz2qNEI23GzHbervQJsdevQ2t2vipGMqe9YXi3dSYHFYKcHbkhCVVUdlK2J5Q5+fwEAAP//AwBQ SwMEFAAGAAgAAAAhAMPIYVejBgAAiy8AABUAAABwcHQvc2xpZGVzL3NsaWRlNC54bWzsWt1u2zYU vh+wdyB0sTtHP9Qfs7pF7NbbgK4N6nT3qkzbQiVKI+nEWVFgr7HX25PskJRkx5aTNHHSZnUQWJRE Hp6f76PIQz57sSxydE65yErWt9wjx0KUpeUkY7O+9f5s1IstJGTCJkleMtq3LqmwXjz/8Ydn1bHI JwhaM3Gc9K25lNWxbYt0TotEHJUVZfBuWvIikXDLZ/aEJxcgtchtz3FCu0gyZtXt+W3al9NpltKX ZbooKJNGCKd5IkFzMc8q0UirbiOt4lSAGN36ikrPwbJ0nE/UVVRnnFJVYue/8GpcnXL9+s35KUfZ BPxlIZYU4BbLrl/U1fQtO9cFe6P5rCkmx8spL9QVbEPLvgXOv1S/tnpGlxKl5mG6eprO33bUTeev OmrbTQf2WqfKKqPctjleY85ZJnOK3NaqRl9RvS7TjwKxEuxR5hvz2hrGZnWt5kheViBKKlF1PfNS F1bK1M6Sy0E5uVSdfICrfpgc50KO5WVO9U2lfrQaHPTNE4VQynrvxxaaZFxqq5Eo5DCnCWtdI58P F5xDqJU7pHaKlkHZ5DThybudoowDK61vo5zdeG+3D/3Gh+M8m1D0ZlF8oByd5klK52U+gTLeh1uB fCAa7P2rb/25SLik3IL+AQGutz9vT4HiyqhPo0Hgk5cDp3dCIhgTBv6rXuyG8DMc4Pgk9gn2R5+t VjewnIF2nbHqiJC/is1UMe/hohO0CAd6Dcol8q8EAylRyofm6TqB113YQV3s49AnnialFwRBhDdo 7LmOE5PQ0BOHBGMTp5Wkigv5Cy0LpAp9i9NUag8m56+FrO2tq2jQlODmUZbn+obPPgxzjs6TvG+N 4G84rKVfqZYzdKH08x1Hi74qQ42WtJWSpCmwxmDxSk1byam9bXyyiSZ0wRPAMYMvhoW4zIdlrmJm oH6ykOUoqw0y9e9Gdcq5HoE7AJVROd3g+x0Gjp64FJIWvY/0Mp3Dt+GRRpBwE6PBnjDqYd+JA4NR HMaRE2jJK4y6gefEjnvA6BPC6BeKuEYhIeb74AzlMJ18JKpEm1QJ90SVwHEd4gTXUMXHxPHjA1W+ S6rIXDw1qsSbVIn29VVxMUx8iKaKTwIcuFrGGlUI9kI/OFDlu6QKozIt2V5mY49JF7JJl3hPdPGj gDjX0yUKsVuv4w90+c7owqn4hvmSLtm4psxQFbfyYW1CbCx5ks3mEp1wXl6gYckYwLTkyNVd6Eat CIi2hJtm9aPTGM3ymU2aN0H9pslvrEu4SsG1x+ssRNM8q/5Qnl9fuLuO6wXYLNyJFzihlr/GRxwH MAM0fIxClxCdwNnNR1Gb3tps+tvBTsUQiFCS5a/YpMmZ8QxikwMngIT5zEI5Zbpgmm+QSig2GFHv 6LTx0Y1E1bV1kgfI2jasyXddw7q+9tF0Cha2jY2h1zZuW+ieS7ZqXGSs5F0C5LLt2dQ31hurFQ4a UN6ITnwzOnXwd6MzemB0/qrHhS6c+n4cEt9kfbtx6vnYj8kBp08fp20GaDdOVzmhTpzGO3HajK8P MYqa1JLvBCGO9fJiDZ0GlzGJAKcHXD5NXLaT4t24XE2TO3FJduKyGVkfavxUGXm/mXd3IjSMgnqR +sgoPaDyPqj02l3Lnaj0VjuZXzha7geVXzxaeqFH3Kiecx7GzG8Ynddspm/tNZog3jWHsBrf1pAU +9gNzaTQxZETY93FCkhRrPYl95hMYKVa2xs9b1jVC7Uv/ZDr+o5F79k8Ewj+5ZxCxWTGkwLKiVTP MobGYF1WMoTVja7Dk6k8Ojq6yOQcCTtZzPThkoWgwp79+/c/aJot6eTokZJO3tbWn3evvb9OyHhh hCM1tihEOFGEid40WfsQup6DvQYzsPoNbhh8vn3MqFMSwBPnBvT8lMufb5V46ZJ3TVIHbqec3i6n c1tVZ1uq7kJlh8S74nNrv82714ZbJz4D7JEQm4SMwme8lSA94POAz258bm1yeffa5eoePwF9UbOQ wDgIo41ETBQS3/X+n/DcAUr1vfw6Ed/ap/HutVHTGXHsOwQTM8s6RPwrRxw7WxEn+/8GRYSEKhtw iPjjRFxfmsPW4GRwUl1CC571rU+DAQm9YTzoDVx/1PNfkqh3MgqD3ijAvj8cxCdD/OqzOrzt+scp p/pc92/N+XR4uHUmvMhSXooSZv9pWdSHy+2qvKC8KjN9vtx16kPqekXoRp4bq7MOesZja92aq9ZW rQrrc+Npzn9Pqrfn2kHQmaR8qB9VGZvViYRVFWU7tPsPAAD//wMAUEsDBBQABgAIAAAAIQBVrNaZ +QIAANEIAAAVAAAAcHB0L3NsaWRlcy9zbGlkZTMueG1stFZtb9owEP4+af/B8j6nARJaQKUVoWWr 1LVotD/AcxwSzbE921DY1P++s5NAX6jarexL7JzP5+d57pzL8emq5GjJtCmkGOL2QQsjJqhMCzEf 4tubSdDDyFgiUsKlYEO8Zgafnnz8cKwGhqcIdgszIEOcW6sGYWhozkpiDqRiAtYyqUti4VXPw1ST O4ha8rDTah2GJSkErvfrt+yXWVZQdibpomTCVkE048QCcpMXyjTR1FuiKc0MhPG7H0E6AWZ0xlM3 GnWjGXMzsfys1UxNtV++Wk41KlLQCyNBSpAFh/VC7eZfxdJPwifb582UDFaZLt0I3NBqiEH8tXuG zsZWFtHKSLdWml/v8KX5+Q7vsDkgfHCoY1WBe06n09C5KSxnqL1h1eA16lLSHwYJCXwc/YrexqPi 7EaVI7tWEMq6ULVftegnWzC1WHaVyHTtDvkOozeSATd2Ztec+RflHh6GBrycuAplIridYZQW2nrW yJR2zBkRG2nsyYUxC4Y+tZ0e1qvigzCRTokm316MVSmoPOAGXdjI97KIUSPiWAoLJYamnFCWS54y jTrvk7RIV1uXPagJ7qgk+tJLV4gU4Pop4XNQkFqNfYjFFdz9Wo4K9aviPU1EpeR/P3ZvJ/1DnX2R d+hJjb0Spd5oJTKKFxbZvDAIvpOZBazOyuDLTHhlMqePgr+F5rtV/LvKj5vKn/EiZehqUX6Hkn9Y /tE+vijQdyA0pODXEP9cEG2ZxvXN8NdrP1cjg+7mSP2eJN24f5a0glH/CNphEp8HvfYhPMZJ1Bv1 4n4UT+7xBhswF4BuZ+J3FE20TWrmms77suOHpmdBA7k0tp6hhS6ATJL0DzvjXhIk7XgSxGf9o2A0 OewGk24Ux+OkNxpH5/euB7bjAdXMt8eLps2D8VlrLQuqpZGZPaCyrHt0qOQd00oWvk23W3WvXxI+ xL1O1O7GUadbZwqgNaMH63Jfd1/K9Veirpe+TuAsyPPYmxT8RtRlsnVx1GHfHwAAAP//AwBQSwME FAAGAAgAAAAhAIU6ZTjdAwAAZQ4AABUAAABwcHQvc2xpZGVzL3NsaWRlMi54bWzsV11u4zYQfi/Q OxB6LRT5R3YsY53AcuLuAm5i1NkD0BQVsUuRLEk7dosF9hq9QA+2J+mQkuLEdoq08UMX6ItI8Wf4 zTefqJl3l5uSozXVhkkxCtpnrQBRQWTGxP0o+Hg3DQcBMhaLDHMp6CjYUhNcXnz/3Ts1NDxDsFuY IR4FhbVqGEWGFLTE5kwqKmAul7rEFl71fZRp/ABWSx51Wq1+VGImgnq/fs1+meeM0CtJViUVtjKi KccWkJuCKdNYU6+xpjQ1YMbvfgbpAjwjC5651qg7TanrifWPWi3UXPvpm/VcI5YBXwESuARagqie qJf5V7H2nWhv+33TxcNNrkvXgm9oMwqA/K17Rm6Mbiwi1SDZjZLi9shaUlwfWR01B0RPDnVeVeAO 3ek07twxyylqP3rV4DVqJskng4QEf5z7lXuPKyqfXasKZLcKTFlnql5XTfrODkxNlt2kMtu6Q5bQ +kE85MYu7JZT/6Lcw8PQgJdjp1Aqwo+LAGVMW+81MqWdcIrFIzX24haijz4Ys6LGUWI9Md4OFdkc a/zzi+YqEpXH3ACMGgZf5rHb8DiRwoLK0JxjQgvJM6pR522ssmyzW/ICoUekFffOQeNeM+1+q+X6 z1Q26HSSvlvg1BP3Or2k393XUGX6MFSuJ+DbGq+szJmtdu2mDoMIdlCJ9WwU9NpxtwenMpEBT6Mg rAe88dUU6PMyyoG+UfBD+UvIbYV7uXKn3azKWmYQxiUjc6qZzJqwVccfV4z5DeQeO4f/Vjvv5QOy EhnFmUV76nm14dqWLZhBcAvmFtx1Rincu5hXQ/vSfBPqy1fq/DjWSvHfZKhOSSKRpeLUUpRJZAt6 UtuLxfvobrY4pcmT4itlRjlcSJRmTv5L+lxR/yuk+qAlwlkGiYTxAjG0ZCGRImf3K3AAfqDYKEqs QTL3Cz7RLSkgx0Ce3v8KpSe5HJ5AbMDdQL54utjNqP365Q+4P5khK2O+fvnzG73j/gHOfR7+TSoS N6nIgrOMIkC4hBzkaT7if/NvzfKgFgDTlRe/rrC2VAd1quLzndMkfzlUHM6p36dpL06u0lY4Ts6h REnj63DQ7sNjknYH40GcdOPp5+ARG3guAN1x/R1qrbOTVu4Kgbclir5p6ghIt2bG1j200gycSdOk 35kM0jBtx9MwvkrOw/G03wunvW4cT9LBeNK9/uzqknY8JJr6kuVDU3rB4EG5UzKipZG5PYN/WF03 RUo+UK0k86VTu1XXX2vMIURJN+kOkkETaIDWtB6si31dERGuf8Lqdu11AmdBnCd+SEFpV8tkt8S5 Dvv+AgAA//8DAFBLAwQUAAYACAAAACEAMbYC55EEAAAPEAAAFgAAAHBwdC9zbGlkZXMvc2xpZGUx My54bWy8V11u4zYQfi/QOxB6Xkf+kR3b2CSInLhdIN0EdfYAtDSy2FAkS1KO3WKBXqPX60k6pOQ4 dryOk032RZQocvjNNz+c+Xi2KDiZgzZMipOgddQMCIhEpkzMToIvt+NGPyDGUpFSLgWcBEswwdnp zz99VEPDU4K7hRnSkyC3Vg3D0CQ5FNQcSQUC/2VSF9Tip56Fqab3KLXgYbvZ7IUFZSKo9+tD9sss YwlcyKQsQNhKiAZOLSI3OVNmJU0dIk1pMCjG796AdIqaJROeutGoWw3g3sT8F60m6kb735/nN5qw FPkKiKAF0hKE9Y96mf8Uc/8Sbm2frV7pcJHpwo2oG1mcBEj+0j1DNwcLS5JqMlnPJvn1jrVJfrlj dbg6IHx0qNOqAvdUnc5KnZEUFtkhN5wmkEuegibtBx1X6I26ksmdIUKido6MStmHFRUDblQ5yl+s l1Tz/mWNaicl7U5n0Op5XVud43Yr6m+y0+8Nmv1oUGkdddvdQa+zrXslWg3tIpbp0u2e4lgdJ+R5 aWXGbLVn/YMbO7FLDv405R5+WiNVnLrgANH4MsHg+AtBNpvIe8q09dQTU9gRByoe7GNPb3MgSam1 YxUjIcMnZEyAIZQUTLCiLIgppwYskRmZTH4Nb68mxIDG2CQOmfX4KgwHAwGtvZPuAJRIkbHZlmQQ 6Q3V9PdXKBnWLFUPJ2DOa4PvQ9zqP0vdJ+RKgnMzezgTB8jN6RxeL/Cl1H4X1DfV+07IqSFKyzlL ISXTJSFzqpkszav97oBTWaE4uMxdJewN0e/nO3FpyRTw2iF/lMaSmZalwi/zgdgclv/9868GDETD ZgKZsBLXYjQu8J0J/KKJLSlfsVHIFPghwH2m3As8ehb4WGJKFu7mTeADoeIFttgSvsdRr/FeRJO/ WvQuT31MFnI5yy0pDYSYrzG5ONbfRRMGNntLNRrvAdKY/E0xVlS/IIU/I3RvGO6VuxmI26K+8+Jk hjBjSkDXgsIQwwrGqXbRSp2blRzQraglAiA1btqUSkltMYoLKpZY3YpU6h+VcS4kuQfn8uRqdIGB mxJYKEgsoeVsnf4czIxxjjGOQWKMy1CKamvIfQ7CqwLp2Q+CfI3hSu/AZRnIsEi2G+ikdn9Sr1IG 1Jb4jXnJ+mTuFQFBp2iEUqyJr3SpEioHrHZkaV+gzvs4W/sAZ5MlZiyzCfWZumhT7AOecF1w+hp0 f+kdrUrvCcdbmXwuiylm0cf1ty9rX19/26VC6dizoegK+J8lGgl0UJfm/tb6dm3uD9+uoD1tTyvl DDtDp9Tf47gbDS7iZuN8cIytZBxdNvqtHj5Gcad/jnV7Jxp/DR6woeYC0e224FNrtTprM2WuY/u2 oQ4xjx9WDR/eV1fG1m+k1Ay1ieNBrz3qx424FY0b0cXguHE+7nUb424nikZx/3zUufzqGshWNEw0 +Ej/tOqRcfJJX1qwREsjM3uUyKJucEMl70EryXyP22rWjfKcuujotaJBt9fs9WpbIbbV6NE669e9 a8L1b1Rdz72n4GFo6ZGfcvVP7SjrJU533Pc/AAAA//8DAFBLAwQUAAYACAAAACEABNxtRf0EAACO GwAAFQAAAHBwdC9zbGlkZXMvc2xpZGUxLnhtbOxZS2/bOBC+L7D/gdB115ElS7Js1CliNy4C5IXY 3TstUbFQihQo2nVa7H/f4YiK7MRpgzbYJEV8sIaveX1DzYh8935TcLJmqsqlGDneQdchTCQyzcX1 yPk0n3Zih1SaipRyKdjIuWGV8/7wzz/elcOKpwRWi2pIR85S63LoulWyZAWtDmTJBIxlUhVUQ1Nd u6miX4BrwV2/243cgubCsevVY9bLLMsT9kEmq4IJXTNRjFMNmlfLvKwabuVjuJWKVcAGV++odAiW JTOemmdVzhVjhhLrj6qclZcKh8/Xl4rkKfjLIYIW4BbHtQN2GjbFGgn3zvLrhqTDTaYK8wTbyGbk gPNvzL9r+thGk6TuTNreZHmxZ26yPN4z220EuFtCjVW1cvfN8Rtz5rnmjHi3VjX6VuWpTD5XREiw x5hfm3c7o7bZPMsl0TclsEq0Qm52aj2ORKvPXmdEcRh3ays9vx8OwsGuX/r9vh+YCcbeoDeI/d49 q2vW5VBvxjK9MasX8KzFCYiGo5WWWa5JJoWeJZSDvoMu/CyfdjKv9EzfcIYalOYPuxU4jlOzVZjo fJrBVvkKuhgGJM2VbgHSh+fH88nF+ZTMmILtRmBHkavj2U6fEalRcM38sRJIVegJZ1S04mr9kcPi p/kYD/yyJocTKbL8eqVwq5EzmTJe3bH0/1TxF/zzZC6BV2GmOznTWUcwnYCDOhWGQKcw7ul0Bz8b Ci/AuhcUes2ee8KNdfgPDK4of1KeJ0/JTGim8uLFBlAv+qEFZ/SGePHfxO960TPbwUR6SRW92rfM 9/csKzHvNPkGU9D3c27Y5NzZaqEx7fo7aZcYXhuTa7cS8N602yTYH+RVz496YTfAxNoLgjjo9nYT axR5vX4/qhOrF3qDuBfvJFawUlX6I5MFMcTIUSzRqB5dn1bW6c2U7+ZhU3nC+qVUXx3CT0QF+dcL AnCrxkYQ9n1oqO2Rxc6I5hPJjfvvpPSHEjjSa+4ZzxZUnWIM5iKFWhBJyq8FFi2ALMvmdDEzAWKE 1dJwEqOnYqw+Y/1nClBhmzC0hCiBKvdyJRLdgpaMWWapy0STNQU+/lah0c5YrKZQi2DtlNEEwuJI 5ZTXAC1W51CDIwm6mZjEDYWqfWbK1O+GRkGS5+k05xwbpgxmE65qwXpTqwV6W1X64ZYqzeS6tc0H Td1S7a9CdLi2wUPvDDBqS9PqzkBSWUm1DUhaRCw4fgtO4/lXjZCPdeyrR8jAYhHqtQjhrnz1CKEJ rx4hA4tFKGgRgre5h0n3dUOESfrVQ2RwsRCFWxDFfowviTeInh8ig4uFKGoh8v04QvveIHp+iAwu FqL+FkT9oC6G3iB6fogMLhaiuIXI4PMblAu/B0QGFwvRYAuiKOy/lQsvBCKDS01vfb/i+fNDJxO3 5xE4Kcvg0/z2m7xd8/BZBT6aaw+2MYstRVYqHznfxuNB5E/icWfsBdNO8GHQ7xxNo7AzDXtBMBnH R5Pe8b/mGsULholieOx70twUQee925kiT5SsZKYPElnYax63lF+YKmWONz1e114XIS5e1w8Gg94g xIMSF3VrnqitORqxNzgJV2e0vFhjnIMwzdQEu0oIR3uK0k4BZ+QFDCAlrOUlrU9s5qK58klXauSY 3ZHlItcMdgCrNDUHGYKtGewRIVM2x9sPXVxJicHgWk7G4zVrQ1lxxumg8H8AAAD//wMAUEsDBBQA BgAIAAAAIQDV0ZLxvAAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91 dDEueG1sLnJlbHOMz70KwjAQB/Bd8B3C7Satg4g0dRHBwUX0AY7k2gbbJOSi6Nub0YKD4339/lyz f02jeFJiF7yGWlYgyJtgne813K7H1RYEZ/QWx+BJw5sY9u1y0VxoxFyOeHCRRVE8axhyjjul2Aw0 IcsQyZdJF9KEuZSpVxHNHXtS66raqPRtQDszxclqSCdbg7i+I/1jh65zhg7BPCby+UeE4tFZOiNn SoXF1FPWIOV3f7ZUyxIBqm3U7N32AwAA//8DAFBLAwQUAAYACAAAACEA1dGS8bwAAAA3AQAALAAA AHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ4LnhtbC5yZWxzjM+9CsIwEAfwXfAd wu0mrYOINHURwcFF9AGO5NoG2yTkoujbm9GCg+N9/f5cs39No3hSYhe8hlpWIMibYJ3vNdyux9UW BGf0FsfgScObGPbtctFcaMRcjnhwkUVRPGsYco47pdgMNCHLEMmXSRfShLmUqVcRzR17Uuuq2qj0 bUA7M8XJakgnW4O4viP9Y4euc4YOwTwm8vlHhOLRWTojZ0qFxdRT1iDld3+2VMsSAapt1Ozd9gMA AP//AwBQSwMEFAAGAAgAAAAhANXRkvG8AAAANwEAAC0AAABwcHQvc2xpZGVMYXlvdXRzL19yZWxz L3NsaWRlTGF5b3V0MTAueG1sLnJlbHOMz70KwjAQB/Bd8B3C7Satg4g0dRHBwUX0AY7k2gbbJOSi 6Nub0YKD4339/lyzf02jeFJiF7yGWlYgyJtgne813K7H1RYEZ/QWx+BJw5sY9u1y0VxoxFyOeHCR RVE8axhyjjul2Aw0IcsQyZdJF9KEuZSpVxHNHXtS66raqPRtQDszxclqSCdbg7i+I/1jh65zhg7B PCby+UeE4tFZOiNnSoXF1FPWIOV3f7ZUyxIBqm3U7N32AwAA//8DAFBLAwQUAAYACAAAACEA1dGS 8bwAAAA3AQAALQAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQxMS54bWwucmVs c4zPvQrCMBAH8F3wHcLtJq2DiDR1EcHBRfQBjuTaBtsk5KLo25vRgoPjff3+XLN/TaN4UmIXvIZa ViDIm2Cd7zXcrsfVFgRn9BbH4EnDmxj27XLRXGjEXI54cJFFUTxrGHKOO6XYDDQhyxDJl0kX0oS5 lKlXEc0de1Lrqtqo9G1AOzPFyWpIJ1uDuL4j/WOHrnOGDsE8JvL5R4Ti0Vk6I2dKhcXUU9Yg5Xd/ tlTLEgGqbdTs3fYDAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvAAAADcBAAAsAAAAcHB0L3NsaWRl TGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDkueG1sLnJlbHOMz70KwjAQB/Bd8B3C7Satg4g0dRHB wUX0AY7k2gbbJOSi6Nub0YKD4339/lyzf02jeFJiF7yGWlYgyJtgne813K7H1RYEZ/QWx+BJw5sY 9u1y0VxoxFyOeHCRRVE8axhyjjul2Aw0IcsQyZdJF9KEuZSpVxHNHXtS66raqPRtQDszxclqSCdb g7i+I/1jh65zhg7BPCby+UeE4tFZOiNnSoXF1FPWIOV3f7ZUyxIBqm3U7N32AwAA//8DAFBLAwQU AAYACAAAACEA1dGS8bwAAAA3AQAALAAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlv dXQ2LnhtbC5yZWxzjM+9CsIwEAfwXfAdwu0mrYOINHURwcFF9AGO5NoG2yTkoujbm9GCg+N9/f5c s39No3hSYhe8hlpWIMibYJ3vNdyux9UWBGf0FsfgScObGPbtctFcaMRcjnhwkUVRPGsYco47pdgM NCHLEMmXSRfShLmUqVcRzR17Uuuq2qj0bUA7M8XJakgnW4O4viP9Y4euc4YOwTwm8vlHhOLRWToj Z0qFxdRT1iDld3+2VMsSAapt1Ozd9gMAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG8AAAANwEAACwA AABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0NS54bWwucmVsc4zPvQrCMBAH8F3w HcLtJq2DiDR1EcHBRfQBjuTaBtsk5KLo25vRgoPjff3+XLN/TaN4UmIXvIZaViDIm2Cd7zXcrsfV FgRn9BbH4EnDmxj27XLRXGjEXI54cJFFUTxrGHKOO6XYDDQhyxDJl0kX0oS5lKlXEc0de1Lrqtqo 9G1AOzPFyWpIJ1uDuL4j/WOHrnOGDsE8JvL5R4Ti0Vk6I2dKhcXUU9Yg5Xd/tlTLEgGqbdTs3fYD AAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvAAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVs cy9zbGlkZUxheW91dDQueG1sLnJlbHOMz70KwjAQB/Bd8B3C7Satg4g0dRHBwUX0AY7k2gbbJOSi 6Nub0YKD4339/lyzf02jeFJiF7yGWlYgyJtgne813K7H1RYEZ/QWx+BJw5sY9u1y0VxoxFyOeHCR RVE8axhyjjul2Aw0IcsQyZdJF9KEuZSpVxHNHXtS66raqPRtQDszxclqSCdbg7i+I/1jh65zhg7B PCby+UeE4tFZOiNnSoXF1FPWIOV3f7ZUyxIBqm3U7N32AwAA//8DAFBLAwQUAAYACAAAACEA1dGS 8bwAAAA3AQAALAAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQzLnhtbC5yZWxz jM+9CsIwEAfwXfAdwu0mrYOINHURwcFF9AGO5NoG2yTkoujbm9GCg+N9/f5cs39No3hSYhe8hlpW IMibYJ3vNdyux9UWBGf0FsfgScObGPbtctFcaMRcjnhwkUVRPGsYco47pdgMNCHLEMmXSRfShLmU qVcRzR17Uuuq2qj0bUA7M8XJakgnW4O4viP9Y4euc4YOwTwm8vlHhOLRWTojZ0qFxdRT1iDld3+2 VMsSAapt1Ozd9gMAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG8AAAANwEAACwAAABwcHQvc2xpZGVM YXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0Mi54bWwucmVsc4zPvQrCMBAH8F3wHcLtJq2DiDR1EcHB RfQBjuTaBtsk5KLo25vRgoPjff3+XLN/TaN4UmIXvIZaViDIm2Cd7zXcrsfVFgRn9BbH4EnDmxj2 7XLRXGjEXI54cJFFUTxrGHKOO6XYDDQhyxDJl0kX0oS5lKlXEc0de1Lrqtqo9G1AOzPFyWpIJ1uD uL4j/WOHrnOGDsE8JvL5R4Ti0Vk6I2dKhcXUU9Yg5Xd/tlTLEgGqbdTs3fYDAAD//wMAUEsDBBQA BgAIAAAAIQDV0ZLxvAAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91 dDcueG1sLnJlbHOMz70KwjAQB/Bd8B3C7Satg4g0dRHBwUX0AY7k2gbbJOSi6Nub0YKD4339/lyz f02jeFJiF7yGWlYgyJtgne813K7H1RYEZ/QWx+BJw5sY9u1y0VxoxFyOeHCRRVE8axhyjjul2Aw0 IcsQyZdJF9KEuZSpVxHNHXtS66raqPRtQDszxclqSCdbg7i+I/1jh65zhg7BPCby+UeE4tFZOiNn SoXF1FPWIOV3f7ZUyxIBqm3U7N32AwAA//8DAFBLAwQUAAYACAAAACEAEii2Ux8HAADoLgAAIQAA AHBwdC9zbGlkZU1hc3RlcnMvc2xpZGVNYXN0ZXIxLnhtbOxa727bNhD/PmDvIGgfB9fWf9moU8RO 3QVIu6BJH4CWaFsLTWkU7SYdCvQd9gZ7i23f9ih9kh1PpC0nduosSRF3BgLrfDwdj/e7O5LnPH9x OWXWnIoyy3nXdp61bIvyJE8zPu7a784Hjdi2Skl4SljOade+oqX94uD7754XnZKlr0kpqbBABy87 pGtPpCw6zWaZTOiUlM/ygnIYG+ViSiR8FeNmKsh70D1lTbfVCptTknFbvy+2eT8fjbKEHuXJbEq5 rJQIyogE+8tJVpRGW7GNtkLQEtTg2ysmHcD6kjOWqudwXH2+pSMrSy/BS62WAxKkg5ppnwlrTljX Ho4du3nwvKmFNaVeLotzQami+PyVKM6KU4EzvJmfCtAJKm2Lkyn4VynAAS2GX/kciea118eGJJ3L kZiqJ7jHAgsBxSv12VQ8eimtpGImS24y+XmNbDJ5uUa6aSZo1iZVq6qMu7kc1yznPJOMWqeMJHSS sxRiBV2Essb2sjjJk4vS4jmsTbmiWupColq/ehYTS14VoFYqtVquGkRiadhar/hBBAjjct3ID714 1T+x67ZDNa7W7Ti+12qtrp50ClHKVzSfWoro2oImEgOBzE9KWYkaETSpMqToyMtenl4pySE8wUmQ cfD+JBcfbIsd87Jrtx3fh7klfkFLbUvUR4YrI5L1c4YoEZ6Anq6dSIG2cIjvw5nMR5m2qJpSDbFS nskrRnHZhfpAtgCDGFEJT3nj3Rkk/FT2GSV8ERbyoM+y5MKSuUXTTFo67xEGKA+gUk0kcTpUSXl6 SgR5e02zdhH6xvgE3XR7OHmLcFJY1aPJfYhoUg6ydWrfJ6gciB5Fb44qP3CDdug9/ai6cyAVCuk5 vovMewaW8h7GVbkSWFXwXJ8SQbvDlGc0yXlqMTqnbAv1GGN3UH8+ycT22jEY7qB9kM+EnGyt3r+r +my0VvtDp7RvUvqIyNUNAh1y35ROJazuA+QCYSOd2gjjf03t0Avg71pqu47nLVLbCwPHDXZsv8Dl mGRGes4cFTuEjSEqGBqb0pECXbnTUf5ASHKWpYOMsTXHIHlZnY5kxmXFiYLlVroQrr4t9TTNTEhq Qyq6ZiBG94ilGES/hUHLaUX9ViN2Y78ROX7YiEMnbgwO+14/ODxqD5zoo21iAiJNZlNaWbdNMgRN J2o64TIRRupE+NCpEJhUGOS5Kn71ZMD0vW8yjABphO/XGREwg06Iahu6S0J4juvfnhFxO/imM8Ic sp5eTjxsTIYmJs/AFmq9mU2H1yITgb1vZMIVElSvC04M/DsFZxgE3v+7XD/V0FyU60Ev8NtHvVbj sB0NGnHPf9mInRA++j0vPoz9tucPFuW6VJHHITq2rdafP/35w+dPfz1AtcaHubFD+AD6mrJmIoOF 9Hrt0O3HvUbP8QcN/6gdNQ4HYdAYBJ7v93sxbD8vP6omguN3EkGxv3Ccms6E49/oTUyzRORlPpLP knyqmxzNIn9PRZFn2OdwWrpZghAFQeyFTjs0aQKmmScaq/JOty8SJl6TwhqOHdjQpQPuvQQqvQBq OHYVz1U8V/GAIklCuQQJTRiOazgLGc9wPMPxDcc3nMBwAsMJDQdKzIRl/AJ8oR62NcrZTxXDUFWJ gSJxQq7ymTxONRA1TtVucPzIB4f4bUidjuKI41Q3GjbJBirNjKy+Rm6UdWqy+ny6Udatyerte6Os V5PVBXWjrF+TDb8gG9Rkoy/IhjVZ7IjcIhvVZNtfkI3rWGCS3iK8ApzZOW4CPxlZk1RgXYRDDT5T qUuAymKsOyXSqjVxyyZuQfE6J8OzD8tjPhRd1EjJCe+JC2zKqcYi119haAL1I+Pj0xlPpBqvtr2k p5p9SJ0muoYu6udidDh7k/Pqxlwr0VD7Qe8FFar7um251qrrUmgoVs4R7NFd+8fpLw0m9QZIrg1Q ort95bWBpNS615b2Va8WuNndcPGUiBPYXn23rRaWcajh4KqGYZiLxWP7HzQu97AaBoMcdrnlog9F RljljOGsPyHCSuCja3/+9EfFrUFVnS4eAyq+CSq+CSp+O1RIuks4IvC+KngLONw4iBRjZ+D4/QYc brwDcCgMNBzeEg7TXK7h4cZ4NN3h9HAfrZI9IB4KBI2HX8NDN253GI81+YER9sTxUCBoPIIlHm4r iDCadhWPf/7eTTgUBhqOsAZH4Pjo/W+qXO0CHgoEjUdUw6MdObj57fH4yngoEDQe8fXD7h6Pr4+H AkHj0a7hEcfhjm/nO4qHAqH6t5fl1bDo5HJCxeKiCG+cVqjp1d1syi1FVm+Vj4JgvV+6C1eK9Tc8 44S9f9ZfubDLvvfP5iuQF6lb0N5Bm+4kTuzGaP3eQRtuCbjH7h20+dge+VULce+gDedoMHdfpG87 2IZBtC/SqyfN+uESf8k1vwFVPyBV/1B48C8AAAD//wMAUEsDBBQABgAIAAAAIQA0zbnOFgEAAMcH AAAsAAAAcHB0L3NsaWRlTWFzdGVycy9fcmVscy9zbGlkZU1hc3RlcjEueG1sLnJlbHPE1d1qwyAU B/D7wd5Bzv1iTNs0HTW9GYPCrkb3ABJPPliionYsbz/ZGDSwyQYFbwSP+veHF8f94X0ayRtaN2jF gWU5EFSNloPqOLycHu8qIM4LJcWoFXKY0cGhvr3ZP+MofDjk+sE4ElKU49B7b+4pdU2Pk3CZNqjC SqvtJHyY2o4a0byKDmmR5yW1lxlQLzLJUXKwR8kYkNNs8C/hum2HBh90c55Q+R/uoG4cJD6JWZ99 iBW2Q88hyy7ri02MZeEOoL/YimvafDiLC9Vn5WuMO5I+UUx21Qf6r6yIyVYpZauYbJ1Sto7JNill m5isTCkrY7JtStk2JqtSyqqYbJdStot22jxpq82/bXTx/dYfAAAA//8DAFBLAwQUAAYACAAAACEA NH5Ux5QDAADGCwAAIgAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxMC54bWysVttu2zgQ fV+g/0Coz4osW3Zko04hOVaxQNoGtbvvrERFRCmRJWnV3kWB/tbu5/RLOqREu7kUsDd+ES8aHs6c MyTn1ettzVBLpKK8mXvhxcBDpMl5QZu7ufdxnfmxh5TGTYEZb8jc2xHlvb568ccrMVOsuME7vtEI MBo1w3Ov0lrMgkDlFamxuuCCNPCv5LLGGobyLigk/grYNQuGg8EkqDFtvH69PGY9L0uak2ueb2rS 6A5EEoY1+K8qKpRDE8egCUkUwNjV913SOwHRAjF6vfWQtZMtzITeFYSer1iBGlzDxJpqRhAQhP4C Y5pjhtZkq62ZEmtJiOk17RspVuJW2tXv2luJaGHQehQv6H/0ZnbYtLYTPFh+57p4ti1lbVpgBW3n Hoi3M9/AzIETKO8m88NsXr1/wjavlk9YB26D4JdNTVSdc4/DGbpwOlLCfVTOXyVueP5ZoYZDPCb8 Lry9RRezaUXVS6ANVG/X/bSdgzM9WXqb8mJnNvkErZ3EM6b0Su8YsQNhPtYNCf4ybDKcNP7HFWR4 rReM4GZPiL5aMJp/RpojUlCN3mKliUTWGTgPAGnY0ZYjC0ma4hZL/OEBcseisE47DwNH4e+JHDki 7+UUumU4JxVnBbgyPAe5hioPcUnhEHTZ7sH+28PiUxg31wigEGyc7mh8zL8wBLVsT/Qz9TCsWDnU PT06zh9uaYM6YcsVyTmca0Zawo6At4qcAL+uqDwefXQiesY3UldHw0enwtPySfRzn4TInYRrrMm9 A2AJee4BKCDh1d/wVGBWutTv7r6z3DYlPBMmin/iyTKdJlnox5dJ7A+SKPGng+XUjxN4ciZxOBov k2/u1SkgVE1rYt6a49QYB+FlEE4OSsDG59di7LTIODen71c1bP48V41Sy06OLxssYQenyP+5jX6j yHkZmThGVowWBL3b1J8e8DI+By9QaQH0k9TYS+fMyZql42h6nQ78ZHoJBWAaLf04nMBnkY7iJI6m oyjbJ6sykTfg3bG5+uP7vy9/fP/vDLlqG1dhwUtwo3TfQxtJIZA0nU6Gizj10zDK/Oh6eukn2WTs Z+NRFC3SOFmMlt9MpRZGs1wSWwb+WbgCMowelZA1zSVXvNQXOa/7WjQQ/CuRglNbjoaDvoBssXkS RpMwGkZhHPcygW+utd4a4VcmfmiZfIvF+9YmSW3ft4WdElAv9zlyMDGxu/r76icAAAD//wMAUEsD BBQABgAIAAAAIQDYW64YlQQAACoSAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDku eG1svJjrbts2FMe/D9g7CNpnRaJE3YwmRWTHw4A0Deb0ARiJjoXqNop27A4F+lrb4/RJdg4l2Vbi pK4j7ItF0eSPPLe/JL57v84zbcVFnZbFuU7OLF3jRVwmafFwrn+6mxqBrtWSFQnLyoKf6xte6+8v fv3lXTWqs+Sabcql1IBR1CN2ri+krEamWccLnrP6rKx4Af/NS5EzCbfiwUwEewR2npm2ZXlmztJC b+eLY+aX83ka80kZL3NeyAYieMYk7L9epFXd0apjaJXgNWDU7P6W5KYCa6s0vlvrmhomVtBB9Auw PJ5liVawHDpu01guBdceU7nQxqxCkhpTV3eCc2wVq99FNatuhZp6s7oVWpogqkXoZvtHO0zdFivV MJ9Mf+iabLSeixyv4BFtfa5D4Db4a2IfX0stbjrjXW+8+HhgbLy4OjDa7BYw9xZFq5rNPTfH7sy5 S2XGNbK1qttvXV2X8edaK0qwB81vzNuOaGzGa7Vo3S8R1Y5r/lSN3WYOeoL4oW0HgbKRBhBS64lX XBp41GqtdT3Pd4KnJjfoaiTXUZlscPI9XMFUVsSLEjL1vkFmtZzJTcZVe5WRCodkD1BKmY59CZ// CV31F3CQhUved5ZvxzftPU6FP8owAVMzhpXIC+PTDCoxl+OMs2IbPHkxztL4syZLjSep1D6wWnKh KcdB3QIR6VKtoZC8SG6ZYLipfXKzo0rZ3tms3PB60J0u6F0Z3GYs5osyS2AT9hApABWow1IY1jcl gkds33dfyQNKCCbLsYnwYvRzJq5VKaVFAtKCTTVreQP6qWbt5YRjb1fcZoNq2jsUdX0cdRTP3lnQ Qlqes+OFhCqjj+LhyC0PIS2P7njE8QmW2HFALIItECkt0N0DBhC004BIaYHeDghJ4Kni+3kgUlqg vwf0qYrcCUCktMBgB0Ta8UHpAZHSAsM9oOf6JwYFKYc1aVjtoNsHBtbjvnA4QwgHlqmuzFuwbN5q iJKkkzXEdeBR0TwrXhCRwIK7ZpH/TUNIr0bfriGkp0lv1xDSy64BNCQcWEJ6vAEUpMcbQEB6vAH0 o8cbQD56vJfVA+kwYPvq8sY3HKw/9YJT995wTlEit1OiCZP9Vxg6hBIl8pkOkcZjLwqRWvVVuVA3 yq9z+BZBK/4OfY9MrIlj+NHYMwJCPeNyHEyM8dT2iUNpFDnh1+7LJgFTZZpz/KA5LgyuSXyTeDtv w8LDPxW8LhbTssQ470dDvb69NRpzKZpw/LVkAlboIvKD18uficiwHvE7j8yyNOHazTK/f+IXbwi/ wNc8oA+65gdPzZOSdRq5NJxElnEZ+lMjiOgVZKwHP+PICS4DGjp0uk3WGi0vYHfH5ur3b//89v3b vwPkqrp0X/KgOde1bFvaUqRgSBSFnj0OIiMidGrQSegbl1PPNaYulNw4Ci7HztVXPBEgdBQLro4a /ki6QwpCnx1T5Gksyrqcy7O4zNvzDrMqH7moylQdeRCrPaRYsQwz1wosl1I7bMMEe+uuarcY+Bna D9dMfGDVx5VKklwp6Vh1VWnx0ObIbgja3p3xXPwHAAD//wMAUEsDBBQABgAIAAAAIQCSW4grzgQA ALsSAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDgueG1szFhbbuM2FP0v0D0I6rci UW8bkwz8iIsCmUxQexbASHSsDiWqFO3YLQaYbbXLmZX0khIdW3FiOfFHf6xr+vCQ93Uo88PHdU6N FeFVxopLE104pkGKhKVZ8XBpfplNrNg0KoGLFFNWkEtzQyrz49XPP30o+xVNb/CGLYUBHEXVx5fm Qoiyb9tVsiA5ri5YSQr4bc54jgV85Q92yvEjcOfUdh0ntHOcFWYzn3eZz+bzLCFjlixzUoiahBOK Bey/WmRlpdnKLmwlJxXQqNn7WxKbErxl93/M1qahYHwFA8i8As+TKU2NAucwMGKFAAbjMRMLY4RL yaQwVTnjhEirWP3Ky2l5x9XU29UdN7JUUjUUpt380MDU12KlDLs1/UGbuL+e81w+ISLG+tKExG3k py3HyFoYST2YPI0mi88HsMni+gDa1gvYO4tKr+rNPXfH1e7MMkGJgbZe6f1W5Q1LvlZGwcAf6X7t 3hZR+yyf5aIJv5BUDa7+URlPmzkYCT+IIJHKRTfynKAVE89xYg95ta8IhW6D2PW4Zi77Yj1k6UbO vocneIqLZMGgUO9rTlqJqdhQouwVRaWE0AfoJGrKsZTMf4eh6i/YiiP3dK8d3+Jre4enlB/KLw5T KZaNSArryxQaMRcjSnCxzZ24GtEs+WoIZpA0E8YnXAnCDRU3aFtglOxCraEoSZHeYY7lpnaZ6x2V ynftswrD6zn3dM51F9xRnJAFoylswn1fBWTp+gnSPfleEAUyoS9lP0AIRfJ3mf0gDjwEpdAx+y+l vJVpT1ZfK8fKdJ9j3XgXqwFgegew/i5WA8D0D2BltW2xGgBmcAyrAWCGx7AaAGZ0DKsBYMbHsBoA Zu8YtgYc6iHZjADYNss7e0pWkGqpaq+n6r5pL6kK94QlpyRhRWpQsiK0A73qrRPoZ4uMd2dXDXEC +4QtOZx+Xen9U+mz+UH2c6uZvz3BZKp3pUwF5L2HmdQQUxXwAtO5WQucSuRbTzfkewGqe+GF480P e8gJ3y1wRo75jXo/yIoUdF6aatbyFl4K1ayd/kR7OtXSv4ZKe9GJb09PWxrZ8PWQL1ftxrenHy0d bfiQF6GwK2HvFa3VfLEbS6k/na+lxw2f68aheqE4ma+l2Zov8tWxdTpfS9cbPknWOSF7fC3t13xh EL0tH/+P8+E0JQq0Eo2xIHtKpLTzvUqUimc6hOqIvShEatVX5UJ9UXGdw58j6cXfvheG4fXIsdxB L7KQ48fW0BsH1iAajB0n8MbedfBN/9VKwVWR5UT+w+qWhsBGkY3Cp2jDwuc/FUKdiwljMs+72QjO kY254HU6/lxiDivojBx59z0lI+eNSKQjMqVZSozbZX7fikt4jrhUNAXqg6E5cmq+qVgnw8DvjYeO BbU6seKhf23FKISP0dCLB7Hf8/zJtlgr6XkBu+taqz++//PLj+//nqFW1UNfLYDm3FSisYwlz8CR 4bAXuqN4aA2RP7H8MbTeYBIG1iTwfH80jAcj7/qbvKJAfj/hRN19/JbqWxPkP7s3ybOEs4rNxUXC 8uYCxi7ZI+Ely9QdDHKaW5MVlq+PUYxiP0CuEitb7U0/1W5l4qfSf3hS/gmXn1eqSHKlpCM1VGbF Q1MjTxDpu750uvoPAAD//wMAUEsDBBQABgAIAAAAIQBJgYLHFQMAALIIAAAhAAAAcHB0L3NsaWRl TGF5b3V0cy9zbGlkZUxheW91dDYueG1srFZZbtswEP0v0DsQ6rciy5JXxA4sL0WBLEadHICRqFgI RbIk7dotCuRa7XFykg4p0U6TFPCHfsRtZjjvzQxH5xe7kqItkargbOSFZy0PEZbyrGAPI+/uduH3 PaQ0ZhmmnJGRtyfKuxh//HAuhopml3jPNxqBDaaGeOSttRbDIFDpmpRYnXFBGJzlXJZYw1I+BJnE 38F2SYN2q9UNSlwwr9aXp+jzPC9SMuPppiRMV0YkoViD/2pdCOWsiVOsCUkUmLHa/7qk9wLQ6kJT csPo3kNWVG5hM/TGgD5d0QwxXMLGrZFCVsycKHErCTEztv0sxUospVW43i4lKjJjoFb0gvqgFrNL trWT4JX6g5vi4S6XpRmBC7QbeRCyvfkGZo/sNEqrzfS4m65v3pFN1/N3pAN3QfDiUoOqcu4tnLaD U/EQHlA5f5W45OmjQowDHgO/gneQqDCbUaxfEl/LVYd2cnSmJkvvEp7tzSX3MNpNPKRKr/SeErsQ 5mPdkOAvxSavCfPvVpDXpZ5SgtmBED2e0iJ9RJojkhUaXWGliUTWGagCMGnY0ZYja5KwbIkl/vrK csWisE47DwNH4f+JjByRM6wJWlKckjWnGXjQboLTTAPkH1AWmOYeXAhxD6uIN8JxDvVgUPyc9cNo MIsifzKbzP3ePIZHJJxEfjeOFrNBO4x6nfkvV2EZQNVFSUxRnRaiThD2grB7jARc3HwsYheLBecm B15GI2oiGrmWVTi+bbCEG1xEnG4DEWmWkY5jZEWLjKDrTXn/ipe4CV6gq4Dpd6mxVdBwsi6STjyY JS1/MuhBnibxHJK1C59pEvUn/XgQxYtDsiqDnIF3p+bq89PvT89PfxrIVTu4vgKP/KXS9QxtZAFA kmTQbU/7iZ+EUHDxbNDzJ4tux190ojieJv3JNIKqA50wHqaS2Jb3JXPNMozftMuySCVXPNdnKS/r vhsI/p1IwQvbesNW3Sy3mMLrFcWtNtDV69VhAt/caL01gV8Z/DBSeYXFzdYmSWlf2andEvBvUOfI UcRgd/8a478AAAD//wMAUEsDBBQABgAIAAAAIQCEOCFAyQMAAKYMAAAiAAAAcHB0L3NsaWRlTGF5 b3V0cy9zbGlkZUxheW91dDExLnhtbLRX3Y7TOBS+X4l3sMJ1Jv8/reigptOilQYY0cK9SZxphBMb 2y0tKyRea/dxeJI9dpKW6RS21XRvYsc5/nzO9/nYJy9ebmqK1kTIijUjy7tyLUSanBVVcz+y3i9m dmohqXBTYMoaMrK2RFovr5/98YIPJS1u8ZatFAKMRg7xyFoqxYeOI/MlqbG8Ypw08K1kosYKXsW9 Uwj8BbBr6viuGzs1rhqrmy9Omc/KssrJDctXNWlUCyIIxQr8l8uKyx6Nn4LGBZEAY2Y/dEltOUQL xKhFpSgZN8ViYyFjL9bwxbOugYJ8TgvU4BoGPoBplWOKjD0CxtCCbJQxk3whCNG9Zv1K8Dm/E2b2 m/WdQFWh0ToUy+k+dGbmtVmbjnMw/b7v4uGmFLVugR20GVkg4lY/HT0GTqC8Hcz3o/ny7RHbfDk9 Yu30Czg/Laqjap17HI7fh3NAircLr3dc8luWf5KoYRCY5qGNc2fRBq9bvuw0URrKQkxUoFwrUTer NTWdvY9HCYpjfxC6beh+EsZB+pAr340S811zEKWRF/nRIRMtNB+qTcaKrZ79EVpgQHs0sgjWwbew VKq52lJiXrh+GKcEGFOsE4009vs5JFqtJpTgZqeHup7QKv+EFEOkqBR6jaUiAhkKIC0BUrukjGMG kjTFHRb43QFy6zo3fvf+mhB+r2PwWEfN0B3FOVkyWoAr/iUk1cQdKArrb/aTT1c2jBL/N8LGrjdI /09huWZ+TXcKPlFo7bfRWT4QuhXzcEnD1hlLzknO4JiiZE3oCfBG6jPgF8tKnI4enIk+YyuhlifD h+fCV+VR9EunWNin2A1W5EFmGUKemlkFZJL8ClchpmWfU+2Z/sukMqse7v1f7PYSrj8dxV+TwM8y N05tf+rH9ngWDuwszTJ7mkzHkySLgnEafOtv1QJCVVVN9B16mhqR4yWOF++VgIUvr0XUazFjTGff z2qY/fNUNUolWjk+r7CAFXpF/uOYO0eRyzIS94zMaVUQ9GZVfzzgxZyeT+UFKkmAPkqNOXQuvFln WRQObjLXHg8SKHCzcGqnXgyPSRak4zQcBOFst1mljrwB707dqz++//38x/d/LrBXTdNXjnAT3ErV 9dBKVBBIlg1if5JmduaFMzu8GSSQenFkz6IgDCdZOp4E02+6AvXCYS6IKXP/LPoC2Qsflch1lQsm WamuclZ3tbbD2RciOKtMue25XYG8xvrGCXw3dIMkaC9R41vfGm+18HMdP7RUvMb87dpsktrcbxMz xOF/oNsjexMde/9/cf0vAAAA//8DAFBLAwQUAAYACAAAACEAfzaj/AMFAAAvHAAAIQAAAHBwdC9z bGlkZUxheW91dHMvc2xpZGVMYXlvdXQ1LnhtbOxZ3XKjNhS+70zfgaHXBGTEn2eTnWDHnc5kk8za +wAKyDFdkKiQHbudndnXah9nn6SSAGM72CGOLzpT3xghjj6d349j9OHjMku1BWZFQsmlDi4sXcMk onFCni71L5OR4etawRGJUUoJvtRXuNA/Xv3804e8X6TxLVrROdcEBin66FKfcZ73TbOIZjhDxQXN MRHPppRliItb9mTGDD0L7Cw1e5blmhlKiF6tZ13W0+k0ifCQRvMME16CMJwiLvQvZkle1Gh5F7Sc 4ULAqNXbKvFVLqzlz3SynDzT+8ffdU0Js4WYBvqVsD8ap7FGUCYmBjTLEUsKStSTIp8wjOWILH5l +Th/YGrB3eKBaUksAaqFulk9qMTULVmogbmz/Kkeov5yyjJ5Fd7Qlpe6CNpK/ppyDi+5FpWTUTMb ze5bZKPZTYu0WW9gbmwqrSqVe2lOrzZnkvAUa2BtVa1vkd/S6GuhESrskeaX5q0lSpvlNZ/VrpdQ lVz5UA0aZSpn8WVI45Xc5FFc1STqpwUf81WK1XiRgkqNGE8/l67dmJbjDfFc/ihpJqxLkawDTIwv Y1EHGR+kGJG1+/jVIE2irxqnGo4Trn1CBcdMU6qLqhGIEp2rPRQkJvEDYujzDnKpUa5MrO0xa4fv d7u9druM+UOKIjyjaSw06J0iAtKfutho2YjvCURLSkLHE9Wkcg04tgOAvZ2d0IIW8P0y61w78Fyl 82bqlcgvI6whEs2oYIvHErIl2FqG2K1K6oTEosDlUAHM7wSLqVVlLmjFnyJ9odT0sTZzK2XEsNcA 1lZ1QrVeokqoCtVuUAMAlQZdUIH/ElVCVaiwQQW2B9zOsEpyG1ZiVbDOBqzf85UOx8JKrArWbWB7 Pd9VDjsWVmJVsN4GrAftzhFrg5VYFazfwErM7iFrgZVYFWywAes63rtCJrHaGU1uIgTW1PVOhpNl rAiu2GK4Y1gM1iw2oIQLq7eITLHG8UQm/TRD6bSisZJijqSxHvCg7zkHaMwOHCCKoyuPvf6mathp Hy+1cc4+tmljkn0c0pZr+4jhoOxOtR+U3Snhg7I7dXlQdqfYDsr+Nypod0uV5W/YcowjSmItxQuc doBXdfEG+MksYd3Rqzd/Z/QRnTM+6wwP3wqfTFvRT92dOXu7M6XxabozmcB/zBETKVVxnPL22zjO hY7Vcw72asATzHfu1c692rlX+z/3au6hXk21Ru/r1bapTPHk0VS2r19rqOzcr537tXO/du7XSm7z am4bIo63iM09Rb8W87Jb2/g7Cso8fsf3TXWj3DtNY2XFX0MYOm4QjozAB6HhWNA2/OHQNYbejRUO B/7IHTjf6u/bsTCVJxmWH7S7RcMxgWcCt4mE2Pj0sfDrWIwoldW3GQ3vFNGYctbWPINXPnS+JSKn 9UhQe2ScJjHW7ubZ445f1HvsvX4p0lhAt7rmlY8nRyXrKHRgMAwt4zrwRoYfwhvDB674GYS2f+3D wIajdbIW0nIitOuaqz++//3Lj+//nCBX1aU+0xFvgtuCVyNtzhJhSBgGbm/gh0YI4MiAw8Azrkeu Y4wcG8JB6F8P7Jtv8mwIwH7EsDpw+i2uj6oAfHFYlSURowWd8ouIZtWpl5nTZ8xymqiDL2BVR1UL JFjVdUUvY/W8OkpCtfqqlJVxH0vzxTVln1B+v1A5kqnX20BN5Ql5qlKkEZGm1wd9V/8CAAD//wMA UEsDBBQABgAIAAAAIQCVQTlLEwQAAGESAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91 dDQueG1s7FjdcqM2FL7vTN+BodcEYwsMnnV2Ag6dzmQ3mdr7AArIMV2BqCQ79nZ2Zl+rfZx9kh4J 5L94a7vxZW7QQXz6dP4BvXu/LKm1IFwUrBra3lXHtkiVsbyonob2p0nqhLYlJK5yTFlFhvaKCPv9 9c8/vasHguZ3eMXm0gKOSgzw0J5JWQ9cV2QzUmJxxWpSwbMp4yWWcMuf3JzjZ+AuqdvtdAK3xEVl t+v5KevZdFpkZMSyeUkq2ZBwQrEE/cWsqIVhq09hqzkRQKNX76okVzVYK5/Z/eMftqVxfAEznn0N pmdjmlsVLmFi8syshFUSaPQjUU84IUqqFr/yelw/cL3i4+KBW0WuGNqVtts+aGH6tlpowd1b/mRE PFhOealG8IS1HNoQsJW6umqOLKWVNZPZZjab3R/AZrPbA2jXbOBubaqsapR7aU7XmDMpJCWWt7bK 6CvqO5Z9FlbFwB5lfmPeGtHYrMZ6ZtyuqFpc81ALG2VaZ8llzPKV2uQRRj2JB1TIsVxRom9qddFq cNCXYpXVpHI+jSGrS5lQgqu1Q+R1QovssyWZRfJCWh+wkIRbWhmoAaBU3pHaR5qSVPkD5vj3PebG i7VW2mjoGhf+2JE948g2m6wHijMyYzQHJbqvc6v4AtWA6dSGnZYb8A98eyDLkN+H4tDp4wWdjpJ3 Eg51emGgACqRkN/1o6C3n04N9ZGoaXlBvVaNnEyVe5X+3bDZ1N0BgNg9gEXbWAMAsXcA29nGGgCI 6CXW29HBAED0j2ENAMTgGNYAQOwfwxoAiOExrAGAGB3DNgAlbwVGV1Ot0n1B12XzyupSGaSLS+xU V1NB+1vqxD1jyzHJWJVblCwIPYFeV9kZ9JNZwU9n1wVxBnvK5lzOTqZH59IX04Psl+5r6L/6mvbJ xfqajt95fS1A4Vtje2tsb43trbGd29h809hGWJKdrqY1fu1HcC7tF99tTR5f5KN4Cn8wyoq/oKOE o36/6wTpCDmJj7pOHN12nDhJR2E/juMkHn01P0Q5mCqLkqjfoNOi4bte3/WCTSRg48vHIjCxSBlT 1bcdDf8S0ZhK3oTjzznmsIOJyJFP6XMiclmP9I1HxrTIifVxXj7u+SW4hF8EzYH6oGuOvI3/V7Km sY+iUdxxbqJ+6oQxunVCL4BLEvfCmxBFPZSuk1UoyyvQ7tRc/f7t71++f/vnArmqB3MQAG+COyFb yZrzAgyJ4yjoJmHsxB5KHTSK+s5NGvhO6vcQSuLwJundflUHCh4aZJzoE4rfcnO24aEXpxtlkXEm 2FReZaxsj0ncmj0TXrNCn5R4nfZsY4HVKyHygwh5oaeblat1M6PWVgV+rOyHkfIPuL5f6CQp9fst 0VN1UT21ObKBKNvN0dD1vwAAAP//AwBQSwMEFAAGAAgAAAAhAPrkb3nnAgAAYAcAACEAAABwcHQv c2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0Ny54bWysVUtu2zAQ3RfoHQR1rcj62ZIRO7D8KQqkiVEn B2AkKhZCkSxJu3aLALlWe5ycpENKdNIkBbLwRqRGM8N5742Gp2e7hjhbLGTN6MgNTnqug2nBypre jtzrq4WXuo5UiJaIMIpH7h5L92z88cMpH0pSnqM92ygHclA5RCN3rRQf+r4s1rhB8oRxTOFbxUSD FLyKW78U6Afkbogf9np9v0E1dbt48Z54VlV1gWes2DSYqjaJwAQpqF+uay5tNv6ebFxgCWlM9L8l qT0HtDcE0TvXMW5iC4bAHQPyYkVKh6IGDLnx0EbJrwTGeke3nwVf8aUwvhfbpXDqUsd2Ma7ffejc zCvdmo3/IvzWbtFwV4lGr0CBsxu5oNReP31twzvlFK2xeLIW68s3fIv1/A1v3x7gPztUo2qLew0n tHBmSGFnSVCB14yUWDjBAaAtXfJzVtxJhzKApplokR48Wvh65euO+lJB4/0EERGpXDgQyg3aQq2z 2TzV2fGodjkr9/rQG1iNEQ2JVCu1J9i8cP2oQEGN4leaZrNpOkm9JJkPvDSMMy/tT3peFCSDQTqJ o3Ca3Nt+KAGqqhus2wANBTAB8sOPgql3vYJ6GzUlGNED1Wqc+MHAD/qaXmVIhoONYLRcIoG+vUjR CsENOIvEtyr8X4vIarFgTIECz9UIj6FGpUQrx/cNEnCCVcTGHkGR4zISW0ZWpC6xc7Fpbl7wEh2D F5iBkPpNagzvR27WRZ7E2SzveZNsAKM5j+deGvThMc0j6OE4i+LFoVmlRk6huvf26uPD70+PD3+O 0KtmseMQZtO5VN3O2YgagOR51g+nae7lQbzw4lk28CaLfuItkiiOp3k6mUbzez1Wg3hYCGwG9JfS jvYgfjXcm7oQTLJKnRSs6W4Jn7MfWHBWm4si6HWjfYsITK9+mIWDIOklnUxQm11NtVr4lcYPKxFf Eb/cmiaBw0DkqTFxuMm6Hnly0djtzTj+CwAA//8DAFBLAwQUAAYACAAAACEAkuuHDToEAAD+EAAA IQAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxLnhtbMyY627bNhSA/w/YOwjab0U36mKj SWHZ8TAgTYM6fQBGomOhFKlRtGtvKNDX2h6nT9LDI8ly0nTzNg/wH4uiDg+/c+PFr15vK25tmGpK KS5t/8KzLSZyWZTi8dJ+fz93UttqNBUF5VKwS3vHGvv11Y8/vKrHDS9u6E6utQU6RDOml/ZK63rs uk2+YhVtLmTNBHxbSlVRDa/q0S0U/Qi6K+4Gnhe7FS2F3Y1Xx4yXy2WZs5nM1xUTulWiGKca+JtV WTe9tvoYbbViDajB0U+R9K4Ga3WpObMtFFMb6PDtK7A8X/DCErSCjnsjYS14WTD81NT3ijHTEpuf Vb2o7xSOuN3cKassjIZupO12HzoxfBUbbLjPhj/2TTreLlVlnuAIa3tpQ7x25tc1fWyrrbztzIfe fPX2Bdl8df2CtNtP4B5Maqxq4b41J+jNaR3h763qeZv6RuYfGktIsMeY35q3l2htNs961Xk91wq1 daLtd2wMPC86I06j1GutDPzQI0H01C9JkgTECBh7fZJ4XitxaHWruh7rbSaLnRn9AE+MCh3zRi/0 jjN8qc0PYihwBqemYphw3i+gYio95YyKvbf11ZSX+QdLS4sVpbbe0EYzZWF+QX2BSgOhEQVVMlHc UUXfPdPcwtZI2hMi9F9HKeyjtFg/tHMGpwhUs35oAwWTbIchxwfMDxM/7iIWpmkMBfg0YjGEC0OK EUuiwEj/m4hhe8N9kLUqqm4w7UtRQPVjk/JHgZlno4L1Lax2qKBgy3edgyRU+bzkHF/MosKmXFkb ymGh2JqVASJYCt32JJG3R90Lt2+DHnfQ7+75OtRgQCVRYjxzhrwGsuMNB96RT7DMzo/XQHa8ZODd p+H5ARvKDjg6AE6DFMvi/IANZQccD8BBkMZG2xkCG8oOODkATkh4pjVnKDvgdAA2tGdadIayAx4d AMdRcqZFZyjb9sHucYLtvul33/9/xyf9jj+jmll3nOZsJXkBEOEpdv5Cg9W/wRGb8mW/+7d+/u72 j7MeeapawvnaWPF7SDwSet7MmSWTmTONSeaMpnHg+LAjEn+eRfEk+tSf1gswVZcVa5PgmChFrp+4 fjxEAiY+fSyiPhZzKU0aHEaDnCIaSygYDMeva6pghj4if3Mg+ycROa1H4v151FycrNt19fDML3gu /8/nU16A6hddg+ffEycrpCMZzTLPmYwSuDhn5NpJ/Rh+plmYTlIyCsl8n6yNsVwA3bG5+uXzHz99 +fznCXIVH/01FU7aN43uWtZalWBIlo3iYJpmTuaTuUNmo8SZzOPImUchIdMsnUzD60/muuuTca4Y Xp9/KfqLt0++uXpXZa5kI5f6IpdVd4d3a/mRqVqWeI33ve7ijcu2PwJfpV6UYHm4yNY/kdYEfmHs hydXb2j9doNJUuFCO8WuuhSPXY4MIsb2/n+Lq68AAAD//wMAUEsDBBQABgAIAAAAIQDmkZRyewQA AFIRAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDMueG1szJjrbts2FID/D9g7CNpv Rfeb0aSwlGgbkKbBnD4AI9G2UErUKNq1NxToa22P0yfZOZRk2WnauY0R5I9IUeThdy7kIfXq9aZi 2pqKtuT1uW6fWbpG65wXZb0419/dZUaka60kdUEYr+m5vqWt/vri559eNZOWFddky1dSAxl1OyHn +lLKZmKabb6kFWnPeENr+DbnoiISXsXCLAT5ALIrZjqWFZgVKWu9Hy+OGc/n8zKnlzxfVbSWnRBB GZHA3y7Lph2kNcdIawRtQYwafYgktw1o29L8N0oKXVMdxRqabP0CdM9nrNBqUkHDjOY4XMOOVKiv bXMnKMVavf5VNLPmVqhBN+tboZUFCukH62b/oe+mXuu1qpgPhi+GKpls5qLCEqyhbc51cNoWnya2 0Y3U8q4xH1vz5dtH+ubLq0d6m8ME5t6kqFUH96U6zqDOXSkZ1eydVgNv21zz/H2r1Rz0QfU79XY9 Op2xbJa96SWK6vt1H1VlhHnUEqHjuLarVPQ8K4itB0YJw9DxrF5Z2w0cK/QfqtyJbiZyk/Bii6Pv oQRVSZ0vOUSp7GSyVs7kllFVXzO7wS5sAcuI6dhW0Pkf0NT+BSwWznmvHJ8TsABhrJ+2H9nV9yQ2 +FAqChDCCK5HWhvvZrAeK5kySuqdG+VFysr8vSa5RotSam9IK6nQlAlh9YJElC7VHEokrYtbIgji 7UvuiBplhUF7ZZBvu9/duR/NfMtITpecwWLQnFNEAlpfh4k2Y/cfCggntoIQ6t8ICN+y7Cj87oC4 /3pAVERcq9VV1gXsNFhVAlY3sJ2qUXth4mCYKCtxVhZZyZh6wf2Lpkxoa8Ig+ja4BYE7y1p2LaGP 4zroXefubZRjDjMdRp2qOiOp54cOmuMYXDt6Rlxk7HHdETe2PeW9o3CDZ8RFxh7XG3FtN1QUx/Gi Zs/Fi5A9r7/HGzkROvnl8SJkzxuMvI4TBWqrfXG8CNnzhnu8oecev9yekxche95o5EXY49fbc/Ii ZM8b7/EGfvgy1xtCPp7zkR467JL7E88AmOjUEaA9OAP8SJ73hjx/SSQ9yPMqqT41zxdSV35YEjYf 8n1n2K8mfDXrw7R8kIvVi7LrHE7sqMXfQRglWeinxpVvZYafepaROF5oZFYSualvpU44/TjcAApQ VZYV7bx+jBt80w5NOxitDROf/szlD77IOEc/73vDO4U35lJ07vhzRQTMMHjkf45g3+OR01okGCwy g1VHtZtVdf/ALuqk/1S7wK0XRD9qGnXaPXGwZonvxZeJZUzjEC7jiXdlRHYAjzRxo2nkxa6X7YK1 Rc1roDs2Vj9/+ueXz5/+PUGsqmK49cKec93KvqatRAmKJEkcOGmUGIntZYZ3GYfGNAt8I/Ndz0uT aJq6Vx/x9mx7k1xQdSX/vRgu87b3xXW+KnPBWz6XZzmv+v8CZsM/UNHwUv0asK3+Mq/2aTcOXDuO 4dDauwnYhlLRouNnqD+UTLwhzdu1CpJK7aSpamrKetHHyNgFdR/+hVz8BwAA//8DAFBLAwQUAAYA CAAAACEAj6x2pn0DAACZCwAAIQAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQyLnhtbKxW 0Y6bOBR9X2n/wWKfGUIChETNVIGE1UrTdtRMP8ADZmBrbK/t0GRXlfpbu5/TL+m1gWRmmpUymrxg Y+zje8492PfN211DUUukqjlbOP7VyEGE5byo2cPC+XSXubGDlMaswJQzsnD2RDlvr3/95Y2YK1rc 4D3fagQYTM3xwqm0FnPPU3lFGqyuuCAMvpVcNljDq3zwCom/AHZDvfFoFHkNrpnTr5fnrOdlWedk xfNtQ5juQCShWEP8qqqFGtDEOWhCEgUwdvXTkPReAFt+/6eD7CTZwqvvXAPvfEMLxHADA3e1pgSB OijlTAOSnaDEnSTE9Fj7uxQbcSvtuvftrUR1YXD69Y7Xf+in2VfW2o73bPnD0MXzXSkb04IYaLdw IGd78/TMGNlplHeD+XE0rz6cmJtX6xOzvWED79GmhlUX3M90xgOdTg7/wGqIV4kbnn9WiHHgY+h3 9A4zOs6mFVWvvDZQ/bzuo+0cg+nF0ruEF3uzyT20dhDPqdIbvafEvgjzsGFIiJdiY2zC3E8bMHaj U0owOwiir1Na55+R5ogUtUbvsNJEIhsM/AYAadTRViMLSVhxiyX++Ay5U1HYoIcIvUHC/xdyMgjZ uwndUpyTitMCghi/Tta62B2nXEBRYSi39CDdKxU2trUCqycKdyo+39LSeMGWG5Jz+EcpaQk9A94q /QL4u6qW56NPXoie8a3U1dnwwUvh6/Ik+qW9HQzeXmFNnhjbCvLa86LQwO5vOPMxLZ3e7N1pdhG3 l3DkGxb/rNarIBnNxu40Wq3ctR+M3Hg8Dt10EkfLUZxlYTT9OlwfBVDVdUPMvXFeNkLPn3p+dMwE bHz5XIRDLjLOzd/3OBvWP6/NRqlll46/tljCDkNGLnj+XFaRaFBkQ+uCoPfb5v6ZLuEldIGSCaBP SmMPnQubNUvCYLZKRu5yNoVKLgnWbuxH8EiTSbyMg9kkyA5mVYY5g+jO9er3b//+9v3bf+d6FRW1 1I9qjJM5ss1QPcGdcKN030NbWQOlJJlF4zRO3MQPMjdYzabuMotCNwsnQZAm8TKdrL+aKswP5rkk trL7oxhqQj/4qSps6lxyxUt9lfOmLy89wb8QKXhtK0x/1NeELTZ3TzyZxeHUn0Z9wiC2obXRGgts jBLQUvkOiw+ttUtjb7rUDgkogXu3HKcY7kNJff0DAAD//wMAUEsDBBQABgAIAAAAIQCTCm11TgYA AOcdAAAUAAAAcHB0L3RoZW1lL3RoZW1lMS54bWzsWUuPGzUcvyPxHay5t3lvN6tmq002aaHddpVN i3p0ZpwZdz3jke3sbm6oPSIhIQrigsSNAwIqtRKX8mkWiqBI/Qr4MTMZJ043bReo1OaQ2J7f//2w Pbl85SQm4AgxjmnS8WoXqx5AiU8DnIQd7/ZocGHTA1zAJICEJqjjzRD3rmx/+MFluCUiFCMg6RO+ BTteJES6ValwXy5DfpGmKJHPJpTFUMgpCysBg8eSb0wq9Wp1oxJDnHgggbFke2sywT4CI8XS286Z 94n8SgRXCz5hB4o1sig0NjisqR8+4z3CwBEkHU/KCejxCJ0IDxDIhXzQ8ar641W2L1cKIiJW0Jbo BvqT0WUEwWFd07FwXBDWBs32pd2CvwYQsYzr9/u9fq3gpwHQ96WlRpcytjnYrHVzniWQGS7z7lVb 1aaNL/FvLOHb3W631bbwGmSGzSX8ZnWjuVO38Bpkhq1l/bs7vd6GhdcgM9xYwg8utTeaNl6DIoKT wyW0imcRmQIyoeSaE74p4Zt5AsxRlVJ2GfpErMq1GN6jbCABOrhQ4ASIWYom0Je4HiR4zLASALcQ LD0xSz5fWlKyAPcZTkXH+ziFsiLmkBdPf3zx9DF48fTR6f0np/d/OX3w4PT+zw7CazAJy4TPv//i 728/BX89/u75w6/ceF7G//7TZ7/9+qUbKMrAZ18/+uPJo2fffP7nDw8d8B0Gx2X4CMeIg5voGAxp LG1zCEBj9moUowjiMsVOEnKYQEXjQPdFZKFvziCBDlwX2R68w2QXcAGvTu9ZCh9EbCqykFvA61Fs AfcoJV3KnDZdV7LKXpgmoVs4m5ZxQwiPXLJ7C/HtT1OZztjFshchS819IkMOQ5QgAdQzeoiQg+wu xpZf97DPKKcTAe5i0IXY6ZIRHlvZNCe6hmMZl5lLQRlvyzd7d0CXEhf7XXRkI2VVQOJiiYjlxqtw KmDs1BjGpIy8AUXkUvJgxnzL4VzISIeIUNAPEOcumltsZql7XXYPd9j3yCy2kUzgQxfyBqS0jNyl h70IxqlTZ5xEZexH/FCmKAT7VDiVoHaFqLmMA0xWhvsORla4z67t2zi0VJoniHoyZa6SQNSuxxmZ QKSZVxbadYyT97177d69w7CzeBY79ircYp/uURbgt79N78Jpso9kZbzv0u+79LvYpVfV8/n35nk7 1sfx/NCt2cQrT+ATTMiBmBF0g+tGzqV5wUAu6okmKg78aSSHmTgLFzKox4BR8QkW0UEEUymmpiWE PGMdcpBSLq8ZetnJW99VsbRZr7XyC6ZEQ7FHA7PcKF88CzZ6FurLbS6ooRisK6xx6c2E1QxwTWk1 rdqytMJkpzT9k3lT1g2A6rVCbaNuRMtEgQQFyu+GQR6WfzFEmdXGkAgGyLFcsq+m3Xnu3iwnytlK nI+TcwZzJ6uyW6gmktgzcNzx2q16ywM+TDveRB6b5DBOJT+uOg0kYdLxfGEMPLsWFyxuu7OqVs3X lwy2RKSMi13II0OlH+WvVZK5/vVWU/nhfAxwNJP1tGhs1v5HLfRPObRoMkG+WLEyn2bP6FQgdhAF x2BMpmwIpd5Nk10B5rLT61xTEyZzWz+RM7tws9pYfH2T1QwkaQSzbFevaXILDVyPCx30rKReMVvQ /TVNURV/XqaU0/gdM0VlrjyfNgJ9e5K7OINA5WjHo0xEVHahNML+gMl9X8uSegFZFkolQNTLaKUr Opr3LcPDNLkwEkMcAoZlpxMRQ2hfZHaewayWdcWsMjJGWZ8p1OWp+R2jI0RGqno3lP0eiPJukjlC 4xaDZs8zZ4xDVahv68HFpM2rbjxzQYZ+XWGlpl/aCtpvpsI6G3BJnOlYS+LqrZU7z+JWm8pbBlBf snFj5pP58XREhzL6oNjngUzEC6qrqSwsFsdSZ7NopClW/9UpqJD7L54dS84uDlELzn65uNd3djay fF3OI4erK8slqo5H+T1Ez5b+lKLje1L2rrzeTIlZ4amcmcE+0waPaTDLhoSblmAckbd0kgzRBODg JA/rgkezf32KzXxoBCjbC8LG2YQZfr6JFMT1s4kLivyOVxDrW5yLAZlLNngT5aJFFp4iyZu4bA3l 3S5zZu+6LlsjUK/hMnHycpdlnlK77lLioRPBYC//G0vmr2GkU3b7HwAAAP//AwBQSwMEFAAGAAgA AAAhAEEiBejCBQAA6R0AACEAAABwcHQvbm90ZXNNYXN0ZXJzL25vdGVzTWFzdGVyMS54bWzsWP1u 2zYQ/3/A3oHQ/hxUWZ+WjTpFbMdtgLQN6vQBaImyBFOURtFu0qJAX2t7nD7JjhTprwSb3XoDihoB otPxeOT9+LvTmc9f3JcUrQhviooNLPdZx0KEJVVasPnAen83sWMLNQKzFNOKkYH1QBrrxcWvvzyv +6wSpHmNG0E4Ai+s6eOBlQtR9x2nSXJS4uZZVRMGY1nFSyzglc+dlOMP4L2kjtfpRE6JC2bp+fyQ +VWWFQkZV8myJEy0TjihWEAETV7UjfFWH+Kt5qQBN2r2zpYuIMJkSlP5nM3b/+9Ihor0HnDqdFyw wH3lmYwoRytMB9Zs7lrOxXNHG2tJTm7qO06IlNjqJa+n9S1XK7xZ3XLwCS4txHAJCEsHakCbqVe2 UoKzN31uRNy/z3gpnwAPgh3COT7I/47UkXuBklaZbLRJ/vYJ2yS/esLaMQs4W4vKqNrNPQ7HM+G8 IjgFgtxSnJC8olJWGCljs/mmvqmSRYNYBcFJLNpY1xYtAPJZ50g81OA3Tzkw8+PA+mOJOVBQT2nt lLDZ5OEIeb2uG3d05EHYBT7shI/7NW/ES1KVSAoDi5NEKCbg1U0jWlNjovbRrl73xf2wSh+k5Qye gBIkHczPK/7RQvSaNQOr5wYBLC3Ui1rcQnx7ZLYzIuioousIaCOm4oESJa+oC8siTOeQ1FTtLyXZ O1BJxNxNVNqylbc81AoUlt5ijuU0imU9IMx+P9UzaxWdiUoF+s+M8A0jxliQHT54p+BDKiydm0cz wY/jIHL9n4UP/Fv5kNFUneSn0TC69HreyO6ML7t2EAUjuzcOxnYYjd1w3ItHk3H42TIHA8ctipJM ivmSk7fLFh6+RyrUlGJECWbrAMRF6Lhdx43kXoTaUSbL8al5GRheTmmREnRd4vkuPf1/pydI7yqh pVEOmyKXTQ1UOIy7DU2vy7nmr8qGo/jruoHfkSQFjkZxKPm6Q+KWt5rEfuD15Mt3sBjDp39SUNry jKEPkkJd8KmwqQBGOWrcbj6OgOlCr7tlJZnG/q/UQJgl4GdgJUJ9MTYsVy//QdkLDb3eyHZph1jB KeqehGj3Q9jSSLH2KBpp6kgWBT787dMoDOJIKttaCKTTRPuBiuHmkGU5hGK3tlCAHFKURrRIFkhU iKSFQLr9FRKjRq7QbKpVW0Xb1XaWVMd6xJJTklQsRZSsCD3AvSogR7i/ywt+uHfFqyO8T6olF/nB 7lVOHOO+yJ70fuo0jkwaT6pKnvh2HoenyONM7PWzbRorPL6hr40hmz1XH9YP3c2sS/bsB2l0u7sN xZtlOdsjTHQKwkDTAK6f4ozi4zd3wD8jc76/Je5542gSjCI7HAYT++oq6NrDq+HY9i/HV5NeOPRc L1q3xI0kBoPDO7TKff3y529fv/x1gk5YPcxVBJwuHI6W0JIXEMhw2Iu8UTy0hy4EEox7XftyEoX2 JPSDYDSML0f+1Wd5O+IG/YQTdXFynZorFzd4dOlSFgmvmioTz5Kq1Lc3Tl19ILyuCnWB43b0LZBq E/2453Z6YeCbJIC9mafarcwLfTGTUP4a12g2dyH7BXTf4h6kdAHSbO5JnSd1ntSBhJOEMAEWWjAa z2jWNr7R+EYTGE1gNKHRhEYTGQ18LXJasAWAIR8Wyir6qlUYqS0BeYbylCuywgdAPVOhD17fsD2i bIn5TUtvXfUQEPcOz6Yf16kpk0CZEHzDhnyhfpnIKzKmX2FI/kop2Px2ydqfKU9lAFoQLq8Fpfyo ud+7+wLoHzf3sGu5quJ9BgVwYP1eMpsKXV3w3gDB+hKq2RtIGu273eFuYirR20BjQDjjI0HR+Pgb fFTVPOOjQdH4BBt8XL/rRmeADCoaoHALoNiLVTdwBkiiogGKNgB5XhypG5czQBIVDVB3C6Bu4J9r 9BoVDVC8AUiicy7Sa1Q0QL0tgKKwey7Sa1Ta33lb/aJ5bW+oLv4GAAD//wMAUEsDBBQABgAIAAAA IQCTqn2YuQAAACQBAAAwAAAAcHB0L2hhbmRvdXRNYXN0ZXJzL19yZWxzL2hhbmRvdXRNYXN0ZXIx LnhtbC5yZWxzjM/BCsIwDAbgu+A7lNxtNwURWbeLCLvKfIDSZl1xa0tbxb29hV0cePASSML/hVTN exrJC0M0znIoaQEErXTKWM3h3l13JyAxCavE6CxymDFCU2831Q1HkXIoDsZHkhUbOQwp+TNjUQ44 iUidR5s3vQuTSLkNmnkhH0Ij2xfFkYVvA+qVSVrFIbSqBNLNHv+xXd8biRcnnxPa9OMESzmLGRRB Y+JA6TJZ6oFmD1hdsdVv9QcAAP//AwBQSwMEFAAGAAgAAAAhAJMKbXVOBgAA5x0AABQAAABwcHQv dGhlbWUvdGhlbWUyLnhtbOxZS48bNRy/I/EdrLm3eW83q2arTTZpod12lU2LenRmnBl3PeOR7exu bqg9IiEhCuKCxI0DAiq1EpfyaRaKoEj9CvgxMxknTjdtF6jU5pDYnt///bA9uXzlJCbgCDGOadLx aherHkCJTwOchB3v9mhwYdMDXMAkgIQmqOPNEPeubH/4wWW4JSIUIyDpE74FO14kRLpVqXBfLkN+ kaYokc8mlMVQyCkLKwGDx5JvTCr1anWjEkOceCCBsWR7azLBPgIjxdLbzpn3ifxKBFcLPmEHijWy KDQ2OKypHz7jPcLAESQdT8oJ6PEInQgPEMiFfNDxqvrjVbYvVwoiIlbQlugG+pPRZQTBYV3TsXBc ENYGzfal3YK/BhCxjOv3+71+reCnAdD3paVGlzK2OdisdXOeJZAZLvPuVVvVpo0v8W8s4dvdbrfV tvAaZIbNJfxmdaO5U7fwGmSGrWX9uzu93oaF1yAz3FjCDy61N5o2XoMigpPDJbSKZxGZAjKh5JoT vinhm3kCzFGVUnYZ+kSsyrUY3qNsIAE6uFDgBIhZiibQl7geJHjMsBIAtxAsPTFLPl9aUrIA9xlO Rcf7OIWyIuaQF09/fPH0MXjx9NHp/Sen9385ffDg9P7PDsJrMAnLhM+//+Lvbz8Ffz3+7vnDr9x4 Xsb//tNnv/36pRsoysBnXz/648mjZ998/ucPDx3wHQbHZfgIx4iDm+gYDGksbXMIQGP2ahSjCOIy xU4ScphAReNA90VkoW/OIIEOXBfZHrzDZBdwAa9O71kKH0RsKrKQW8DrUWwB9yglXcqcNl1Xsspe mCahWziblnFDCI9csnsL8e1PU5nO2MWyFyFLzX0iQw5DlCAB1DN6iJCD7C7Gll/3sM8opxMB7mLQ hdjpkhEeW9k0J7qGYxmXmUtBGW/LN3t3QJcSF/tddGQjZVVA4mKJiOXGq3AqYOzUGMakjLwBReRS 8mDGfMvhXMhIh4hQ0A8Q5y6aW2xmqXtddg932PfILLaRTOBDF/IGpLSM3KWHvQjGqVNnnERl7Ef8 UKYoBPtUOJWgdoWouYwDTFaG+w5GVrjPru3bOLRUmieIejJlrpJA1K7HGZlApJlXFtp1jJP3vXvt 3r3DsLN4Fjv2Ktxin+5RFuC3v03vwmmyj2RlvO/S77v0u9ilV9Xz+ffmeTvWx/H80K3ZxCtP4BNM yIGYEXSD60bOpXnBQC7qiSYqDvxpJIeZOAsXMqjHgFHxCRbRQQRTKaamJYQ8Yx1ykFIurxl62clb 31WxtFmvtfILpkRDsUcDs9woXzwLNnoW6sttLqihGKwrrHHpzYTVDHBNaTWt2rK0wmSnNP2TeVPW DYDqtUJto25Ey0SBBAXK74ZBHpZ/MUSZ1caQCAbIsVyyr6bdee7eLCfK2Uqcj5NzBnMnq7JbqCaS 2DNw3PHarXrLAz5MO95EHpvkME4lP646DSRh0vF8YQw8uxYXLG67s6pWzdeXDLZEpIyLXcgjQ6Uf 5a9Vkrn+9VZT+eF8DHA0k/W0aGzW/kct9E85tGgyQb5YsTKfZs/oVCB2EAXHYEymbAil3k2TXQHm stPrXFMTJnNbP5Ezu3Cz2lh8fZPVDCRpBLNsV69pcgsNXI8LHfSspF4xW9D9NU1RFX9eppTT+B0z RWWuPJ82An17krs4g0DlaMejTERUdqE0wv6AyX1fy5J6AVkWSiVA1MtopSs6mvctw8M0uTASQxwC hmWnExFDaF9kdp7BrJZ1xawyMkZZnynU5an5HaMjREaqejeU/R6I8m6SOULjFoNmzzNnjENVqG/r wcWkzatuPHNBhn5dYaWmX9oK2m+mwjobcEmc6VhL4uqtlTvP4labylsGUF+ycWPmk/nxdESHMvqg 2OeBTMQLqqupLCwWx1Jns2ikKVb/1SmokPsvnh1Lzi4OUQvOfrm413d2NrJ8Xc4jh6sryyWqjkf5 PUTPlv6UouN7UvauvN5MiVnhqZyZwT7TBo9pMMuGhJuWYByRt3SSDNEE4OAkD+uCR7N/fYrNfGgE KNsLwsbZhBl+vokUxPWziQuK/I5XEOtbnIsBmUs2eBPlokUWniLJm7hsDeXdLnNm77ouWyNQr+Ey cfJyl2WeUrvuUuKhE8FgL/8bS+avYaRTdvsfAAAA//8DAFBLAwQUAAYACAAAACEAOe09xeYDAACW DQAAJQAAAHBwdC9oYW5kb3V0TWFzdGVycy9oYW5kb3V0TWFzdGVyMS54bWzkV9uO2zgMfV9g/0Hw Pnsc2bLjBJMUk1tboJdB036AYsuxMbLllZQ006JAf2v3c/olpWRrLumgmJ3NS9GXiD4mKZI6opnz Z4eaoz2TqhLNxMNnAw+xJhN51Wwn3of3Kz/1kNK0ySkXDZt410x5z6Z//nHejktAxU6/pkozicBP o8Z04pVat+MgUFnJaqrORMsaeFcIWVMNj3Ib5JJ+BP81D8LBIAlqWjVeby8fYy+KosrYQmS7mjW6 cyIZpxpyUGXVKuetfYy3VjIFbqz1vZCmkGO25rlZN9vu9x0rUJUfoFKDAQYNOrae2ZxLtKd84m22 2Aum50Gv3EvGWLXvJWNGavbPZbtuL6Xd4c3+UoJPcOmhhtZQY+PAvujV7GOzt0JwZL51Ih0fClmb FcqDIEI4yWvzGxiMHTTKOjC7RbPy7QO6Wbl8QDtwGwR3NjVZdcH9mE7o0nnBaA4EueQ0Y6XgRrY1 ssoueNW+EtmVQo2A5EwtulxvNLoCmLUtkb5uwW+ZS+Dmp4n3945KoGBv0ulZ4TbIx1coHA1xOugz J/EQ+HAvfTpupdLPmaiRESaeZJm2TKD7V0p3qk7FxtHt3o71YSbya6O5gRWqBNcO7EshP3mIv2zU xBthQmBrbR/s5h6Sd99s7r3RfC74TQZc6bW+5szKe45hW0T5Fq41t/HlrHgHkKkYvs2q1+zkOx5a W5Qmv6SSGjNOTUdgjf9h3Vu2NjuXlU3054yIHCMWVLN7fAhPwYdc36dDf1H/My2iNCUJjn4Xcsin kqPguT3Wz6vFRTQiydJfhknkpyHBfjqMV364TAYJIYt4gWdfPHdKcPa6qtmq2u4ke7vryiOPGIZU reec0eYmAT2NAzwMcGJi0TaiwvTmU5OUOJKuhDDftbs0jU5B00Ifta2Op/YKPKF9pUkah9hG9ovz FNEmAz/wDf1F+lnsqLLmVc7Qm129OSIMOQVhFM/B9UOcsaf+5N72OzLn/ze7+XKeLqKY+HFIVv5w TmJ/hNPUvyCj4XIRJaMZuW12yhCjgcN7bI/79vWfv759/fcEPc4ubuKE04XD6SW0kxUkMpuNknCe zvwZhkTIYjT0L1ZJ7K/iiJD5LL2YR8svZgjGZJxJZufjl7mbrDH5Ybauq0wKJQp9lom6H9KDVnxk shWVndPxoB/27aiMh8MExwMSOxpDbG610Zp70c/fGZevaYtguobbr2FS1geQ8iuQNtvQYKHBQoOB RLMMRnrQ6AWHhA650YkcEjmEOIQ4JHZI7JDEIYmHSl41V1AMs3ioEPxFBzipawFlgWBetWSFD4Bd c+1G66P/UtPvAAAA//8DAFBLAwQUAAYACAAAACEAtM9YGbkAAAAkAQAALAAAAHBwdC9ub3Rlc01h c3RlcnMvX3JlbHMvbm90ZXNNYXN0ZXIxLnhtbC5yZWxzjM/BCsIwDAbgu+A7lNxttx1EZO0uIuwq 8wFKl3XFrS1tFff2FnZx4MFLIAn/F1I373kiLwzROMuhpAUQtMr1xmoO9+56OAGJSdpeTs4ihwUj NGK/q284yZRDcTQ+kqzYyGFMyZ8Zi2rEWUbqPNq8GVyYZcpt0MxL9ZAaWVUURxa+DRAbk7Q9h9D2 JZBu8fiP7YbBKLw49ZzRph8nWMpZzKAMGhMHStfJWiuaPWCiZpvfxAcAAP//AwBQSwMECgAAAAAA AAAhAE8QgQ7xMQAA8TEAABcAAABkb2NQcm9wcy90aHVtYm5haWwuanBlZ//Y/+AAEEpGSUYAAQEB AEgASAAA/+EAgEV4aWYAAE1NACoAAAAIAAQBGgAFAAAAAQAAAD4BGwAFAAAAAQAAAEYBKAADAAAA AQACAACHaQAEAAAAAQAAAE4AAAAAAAAASAAAAAEAAABIAAAAAQADoAEAAwAAAAEAAQAAoAIABAAA AAEAAAEAoAMABAAAAAEAAADAAAAAAP/tADhQaG90b3Nob3AgMy4wADhCSU0EBAAAAAAAADhCSU0E JQAAAAAAENQdjNmPALIE6YAJmOz4Qn7/4gxYSUNDX1BST0ZJTEUAAQEAAAxITGlubwIQAABtbnRy UkdCIFhZWiAHzgACAAkABgAxAABhY3NwTVNGVAAAAABJRUMgc1JHQgAAAAAAAAAAAAAAAAAA9tYA AQAAAADTLUhQICAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ABFjcHJ0AAABUAAAADNkZXNjAAABhAAAAGx3dHB0AAAB8AAAABRia3B0AAACBAAAABRyWFlaAAAC GAAAABRnWFlaAAACLAAAABRiWFlaAAACQAAAABRkbW5kAAACVAAAAHBkbWRkAAACxAAAAIh2dWVk AAADTAAAAIZ2aWV3AAAD1AAAACRsdW1pAAAD+AAAABRtZWFzAAAEDAAAACR0ZWNoAAAEMAAAAAxy VFJDAAAEPAAACAxnVFJDAAAEPAAACAxiVFJDAAAEPAAACAx0ZXh0AAAAAENvcHlyaWdodCAoYykg MTk5OCBIZXdsZXR0LVBhY2thcmQgQ29tcGFueQAAZGVzYwAAAAAAAAASc1JHQiBJRUM2MTk2Ni0y LjEAAAAAAAAAAAAAABJzUkdCIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAPNRAAEAAAABFsxYWVogAAAAAAAAAAAA AAAAAAAAAFhZWiAAAAAAAABvogAAOPUAAAOQWFlaIAAAAAAAAGKZAAC3hQAAGNpYWVogAAAAAAAA JKAAAA+EAAC2z2Rlc2MAAAAAAAAAFklFQyBodHRwOi8vd3d3LmllYy5jaAAAAAAAAAAAAAAAFklF QyBodHRwOi8vd3d3LmllYy5jaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABkZXNjAAAAAAAAAC5JRUMgNjE5NjYtMi4xIERlZmF1bHQgUkdCIGNvbG91ciBzcGFj ZSAtIHNSR0IAAAAAAAAAAAAAAC5JRUMgNjE5NjYtMi4xIERlZmF1bHQgUkdCIGNvbG91ciBzcGFj ZSAtIHNSR0IAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZGVzYwAAAAAAAAAsUmVmZXJlbmNlIFZpZXdp bmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAALFJlZmVyZW5jZSBWaWV3aW5n IENvbmRpdGlvbiBpbiBJRUM2MTk2Ni0yLjEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHZpZXcA AAAAABOk/gAUXy4AEM8UAAPtzAAEEwsAA1yeAAAAAVhZWiAAAAAAAEwJVgBQAAAAVx/nbWVhcwAA AAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAo8AAAACc2lnIAAAAABDUlQgY3VydgAAAAAAAAQAAAAA BQAKAA8AFAAZAB4AIwAoAC0AMgA3ADsAQABFAEoATwBUAFkAXgBjAGgAbQByAHcAfACBAIYAiwCQ AJUAmgCfAKQAqQCuALIAtwC8AMEAxgDLANAA1QDbAOAA5QDrAPAA9gD7AQEBBwENARMBGQEfASUB KwEyATgBPgFFAUwBUgFZAWABZwFuAXUBfAGDAYsBkgGaAaEBqQGxAbkBwQHJAdEB2QHhAekB8gH6 AgMCDAIUAh0CJgIvAjgCQQJLAlQCXQJnAnECegKEAo4CmAKiAqwCtgLBAssC1QLgAusC9QMAAwsD FgMhAy0DOANDA08DWgNmA3IDfgOKA5YDogOuA7oDxwPTA+AD7AP5BAYEEwQgBC0EOwRIBFUEYwRx BH4EjASaBKgEtgTEBNME4QTwBP4FDQUcBSsFOgVJBVgFZwV3BYYFlgWmBbUFxQXVBeUF9gYGBhYG JwY3BkgGWQZqBnsGjAadBq8GwAbRBuMG9QcHBxkHKwc9B08HYQd0B4YHmQesB78H0gflB/gICwgf CDIIRghaCG4IggiWCKoIvgjSCOcI+wkQCSUJOglPCWQJeQmPCaQJugnPCeUJ+woRCicKPQpUCmoK gQqYCq4KxQrcCvMLCwsiCzkLUQtpC4ALmAuwC8gL4Qv5DBIMKgxDDFwMdQyODKcMwAzZDPMNDQ0m DUANWg10DY4NqQ3DDd4N+A4TDi4OSQ5kDn8Omw62DtIO7g8JDyUPQQ9eD3oPlg+zD88P7BAJECYQ QxBhEH4QmxC5ENcQ9RETETERTxFtEYwRqhHJEegSBxImEkUSZBKEEqMSwxLjEwMTIxNDE2MTgxOk E8UT5RQGFCcUSRRqFIsUrRTOFPAVEhU0FVYVeBWbFb0V4BYDFiYWSRZsFo8WshbWFvoXHRdBF2UX iReuF9IX9xgbGEAYZRiKGK8Y1Rj6GSAZRRlrGZEZtxndGgQaKhpRGncanhrFGuwbFBs7G2Mbihuy G9ocAhwqHFIcexyjHMwc9R0eHUcdcB2ZHcMd7B4WHkAeah6UHr4e6R8THz4faR+UH78f6iAVIEEg bCCYIMQg8CEcIUghdSGhIc4h+yInIlUigiKvIt0jCiM4I2YjlCPCI/AkHyRNJHwkqyTaJQklOCVo JZclxyX3JicmVyaHJrcm6CcYJ0kneierJ9woDSg/KHEooijUKQYpOClrKZ0p0CoCKjUqaCqbKs8r Ais2K2krnSvRLAUsOSxuLKIs1y0MLUEtdi2rLeEuFi5MLoIuty7uLyQvWi+RL8cv/jA1MGwwpDDb MRIxSjGCMbox8jIqMmMymzLUMw0zRjN/M7gz8TQrNGU0njTYNRM1TTWHNcI1/TY3NnI2rjbpNyQ3 YDecN9c4FDhQOIw4yDkFOUI5fzm8Ofk6Njp0OrI67zstO2s7qjvoPCc8ZTykPOM9Ij1hPaE94D4g PmA+oD7gPyE/YT+iP+JAI0BkQKZA50EpQWpBrEHuQjBCckK1QvdDOkN9Q8BEA0RHRIpEzkUSRVVF mkXeRiJGZ0arRvBHNUd7R8BIBUhLSJFI10kdSWNJqUnwSjdKfUrESwxLU0uaS+JMKkxyTLpNAk1K TZNN3E4lTm5Ot08AT0lPk0/dUCdQcVC7UQZRUFGbUeZSMVJ8UsdTE1NfU6pT9lRCVI9U21UoVXVV wlYPVlxWqVb3V0RXklfgWC9YfVjLWRpZaVm4WgdaVlqmWvVbRVuVW+VcNVyGXNZdJ114XcleGl5s Xr1fD19hX7NgBWBXYKpg/GFPYaJh9WJJYpxi8GNDY5dj62RAZJRk6WU9ZZJl52Y9ZpJm6Gc9Z5Nn 6Wg/aJZo7GlDaZpp8WpIap9q92tPa6dr/2xXbK9tCG1gbbluEm5rbsRvHm94b9FwK3CGcOBxOnGV cfByS3KmcwFzXXO4dBR0cHTMdSh1hXXhdj52m3b4d1Z3s3gReG54zHkqeYl553pGeqV7BHtje8J8 IXyBfOF9QX2hfgF+Yn7CfyN/hH/lgEeAqIEKgWuBzYIwgpKC9INXg7qEHYSAhOOFR4Wrhg6GcobX hzuHn4gEiGmIzokziZmJ/opkisqLMIuWi/yMY4zKjTGNmI3/jmaOzo82j56QBpBukNaRP5GokhGS epLjk02TtpQglIqU9JVflcmWNJaflwqXdZfgmEyYuJkkmZCZ/JpomtWbQpuvnByciZz3nWSd0p5A nq6fHZ+Ln/qgaaDYoUehtqImopajBqN2o+akVqTHpTilqaYapoum/adup+CoUqjEqTepqaocqo+r Aqt1q+msXKzQrUStuK4trqGvFq+LsACwdbDqsWCx1rJLssKzOLOutCW0nLUTtYq2AbZ5tvC3aLfg uFm40blKucK6O7q1uy67p7whvJu9Fb2Pvgq+hL7/v3q/9cBwwOzBZ8Hjwl/C28NYw9TEUcTOxUvF yMZGxsPHQce/yD3IvMk6ybnKOMq3yzbLtsw1zLXNNc21zjbOts83z7jQOdC60TzRvtI/0sHTRNPG 1EnUy9VO1dHWVdbY11zX4Nhk2OjZbNnx2nba+9uA3AXcit0Q3ZbeHN6i3ynfr+A24L3hROHM4lPi 2+Nj4+vkc+T85YTmDeaW5x/nqegy6LzpRunQ6lvq5etw6/vshu0R7ZzuKO6070DvzPBY8OXxcvH/ 8ozzGfOn9DT0wvVQ9d72bfb794r4Gfio+Tj5x/pX+uf7d/wH/Jj9Kf26/kv+3P9t////wAARCADA AQADASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIE AwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJico KSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZ mqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6 /8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAEC AxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNE RUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmq srO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9sAQwACAgICAgID AgIDBQMDAwUGBQUFBQYIBgYGBgYICggICAgICAoKCgoKCgoKDAwMDAwMDg4ODg4PDw8PDw8PDw8P /9sAQwECAgIEBAQHBAQHEAsJCxAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQ/90ABAAQ/9oADAMBAAIRAxEAPwD9/KKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAP/0P38ooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA//R/fyi iigAoorwX4u/HzQ/g54s8D+HvEOmzz2PjC4uIJtQjZRDpqQmGNZrgHnymmuIo2YcJu3N8oNAHvVF fKGuftOTW2o2Oh+HfDCX2o3/AIg1vQYxealHYW4bRELyzNM0cmBIB8ibc56mtPxP8avij4e8ceGP A9v8O7a+n8WQzSWky66iRhrS3jmuVbNqThC5VGGd+M4XOKAPpyivmTRv2irvWNM1P4hp4Tlg+GGl jUnfxDJewiRoNKEomulsceYbdnhZY2D+Y/DeUEOadoHx+8RtrXhiy8f+ArnwpYeOI5zo1y17DdOZ 4bZ7wW17FGq/ZppLeN3UK0q5RlLhsAgH0zRXyj8Kv2rfD3xU8NeBtbs9CutMvfF+rvo9xYXEiGbT Zv7On1SJ5CvEiTW0SPGV+8sqnsRXd/A34s+JPjF4atPGl94Xi8P6LqtrFd2DjUUvJ5UlyQJYkiTy iBg43Nzx2oA9zor53+HPx+tvHdj4i8W32mW+g+DdAl1CF9TudRhMsUmm3DQTLeWoUNak7GkUM7HZ gttJArobj9ob4MWfhxfFd54ptrfTmvf7NBlWWOX7aYjOtsYGQTCVohvRCm51IKg5GQD2eivOovi5 8NJtOs9XXxHaLZ393eWMMrvsU3OnpNJdRtuxtMKW8rSbsBQhJ4rmx+0V8Ex4cufFsni20h0uzuIb WWWXzImSa5XfAvluok/fLzEQuJP4C1AHtNFee+Jfir4B8IeHdP8AFXiPVPsemaqiyW0hhmd5EaPz d3lIjSABPmYlRtH3sVgar+0B8F9E1Sw0bVPF9hDd6nDZXNuvmble31FilrMXUFVimYbUkYhCxAzk gEA9hor578W/tGeBtC+IPh34ZaLfW2ra/q2uR6Pd2yyMrWm+1munbcFKPJGETfEG3KHDNjjOD8Y/ 2kn+EnifVNIPhd9Y07w9oltr+qXSX0NvNHaXFzPbhba3lX/SJQYGbYHQtlVXLECgD6ior5/0r40a 3r/xY134daN4ct30/wAN3ltZ3d9PqiQ3Ba4sYb7dDY+UzuqpOqnLrkhvSuL8OftHeM/Gfw11D4re EvAUF9odtHLcwB9bgSdoLfzDOtxGsL/Z7mPYN0BLYLbWdWUigD60or5R0v8AaK8Y6xpfhC2sfh/5 3irxzaSarp2mJqsZhj0iKKCR7y7ujCBCA9xHEI1jkZnYY+XcV2Ln44+O73W7nwj4P+HM2reItD0+ 2vtctZtUtraKxe88zyLSKcCRbieRYmcABECFC7oWAAB9LUV8oeHv2ufA/iTxz4E8K2mm3kGn+P8A R4tStNSn2JHb3U8kscVhcpklJnNvMoOSvmJsBJZcw6J+01rXjK+8Kab4H8FrfXPiTR59akF5qcdm ttbwXgsyobypPMcsd2AFGO+aAPrWivDvin8Yb3wF4q8LeBdA0JNc17xYl7Lax3F9FpsDJYCIyRpN Kr77h/OUxwquWCuxZVUmuqn+Lfw8svF1t4A1HW7e18R3JiT7GzElJpkMkcDyAGNZXQFkjLB3X5lB GDQB6PRXk/hD46fCTx7d2dj4P8T2uqS6i80dr5W/ZcPbxiWVYnKhZDGhywUnbgg8qwEVv8e/g9d3 2k6da+KrSWbXFha02liji5kaKDdIF2J58issO8r5pGE3UAeu0VwXhL4oeAfHmq6xong/WodWvNAl aC/WAMy28ySPE8TvjZ5ivGwZAdy8ZABGe9oAKKKKAP/S/fyiiigArxb4k/B+w+Jni7QdT19orjQr HS9c0u/sZFJN1DrMdvGQGBG0KIWz35GMYr2migD8+7D9kPxxo+geFbS81nRPG+oeHNd1zVJT4isn mt76LVYzDEZkUt+/jXazPghnyRjNfTt98N9Z1fxp8NvGl5cWdo/gy21CK6tbaNxDJJfW0cOLfONk cbIcBhnbgV7PRQB8f6F+z94/0vwPrHwEu9d0u5+F2owarZxt9lnGtRWOpiYrbb/N8jdA02Em2ksi gGPcS1a2k/CD4ua/rHg+b4seItJvbDwCJ5bEaZaTQy6hfyWclhHdXfmyOsQSGaQ+THuBkbO8BQp+ qqKAPi3w1+yhf+GfFnwc8Waf4giik8A6Zaafr1usLeVq8mnaZPYWdxH82Y5IftMoy27dGwU/cWvX f2f/AIG+GvgZ8P8ASPDVhp+nLrcFlBbalqNlapbyX8sIP7yRgN78sSN5J5Ne6184+Avi749+IdzL 4x0jQNMtfhvHfX9mt/dajJHqMkOnyyW8l6IBbmFYWmiYKjTBjHiQkZ2UAeT+M/2VvFvxO1nxTrfi vU9F0G71nR59L8/QbS4gbUZDdW9za3Opq0w3m3NuERVbeFlkxKoIA7Dwx+z1q1lqXhzxBqq6bY6l pfiVNcvTbT39+bxIdLudOiDT6hLJL5imcFeiqi7Rk812EH7UvwWk0jUdeuNWubGw06yh1MyXenXl v9o06eZYI7y1WSFWuIGkdRviDAblJwGUniPiP+1JYWWh6OPhtbXU+s6r4kt/Dk6X+i6k76dLJD9q ZriyRIZyWgKvEuUDhwwJCsKAM7xZ+yUPF/jH4hX97r4tvDnjDS9ShsbKKE+Zp2qa1bQ2moXobcA2 +O2QqvHzST5Pz0/Q/wBmzX1TT73Wm0q01W013QtTuLi2n1K+a7t9EaV0jZ9QnldDumYxIp2x5OSx II7i5/aX8CeF/D9xq/jS8M0ltca35i6PY3195Nnol41pcXEyLBvjSJgqyuRs3k7Gdfmr0OL4yfD+ SNpDfyRlNZtfD7LJbzI6aneRRTRQMrICCUnTJPyqTgkEEAA5r43fDvx58QrfRbfwbr66Xa2ktx9v tJJru2ivI54THGzTWMsM/wC4c7xFvCSdGIwCPGrT9lLW7b4b694GOvWr3GreDvDPhhLjyH2pLoAn 3zkbidknnAqoOVwck169p37Sfw11rw/ceKfD8WtavpdvO9v59noepTpI8W8TGMpbnekRjZZHXKqw 253EA8vrH7UfhNdS8S6R4ftriaLR/CcHiu21ia1uzpEtrcw3E0bPNDC5WPZADuAJYkoimRGWgDFt /wBn/wAf2vjWwkj13TD4R0zxpd+Moozay/2lJLfx3Iltnk8zygscly5RwpLJtQhdpLX/AIxfsx2P xZ8Z6542ubi1t9Vfw/Y6foN49uJLrSNW068ub2G+ikPIHmSx7lUgsEKsSDivRZ/j98NrHxNB4Q1C /mF+09nYzXEVldSafb39+iPbWs14IvIimlEibEd1Y70BALqC/wAG/H/4YePfEkXhXw3f3Et7ci9+ zvNY3Vvb3LabKILxIJ5okileByBIqMSM56A4APPPD/wX8a6D8Z9e+Jz23he/HiS6s7uW7ns5Tqtk 0Om29jNHazcgRs0LOoJHDkHuTQ8PfALxk3ijxx408TXeiaXqPi7QZtFlh0G1nt7a8nkLEajerK7b 51B2JjLKhYGR8rt6jSv2gPtH7RXiH4G6xpC2Flp1pFNY6qZ8rdXK28V1cW7RlQI2SGZZEO47lSQ4 G2uU+G37Wmg+LtC8ReJfE2kzaPZ2uvR6TokNsk2oXurwXVnFf2c0dtDEZBJNbyeb5ahtkY3MwAJA Bq3PwR8d+Hk+G/ib4d61p8fijwJoB8OXKajBK9hqNlKlt5n+qYSwuk1qkkbDdwWVgc5DD8Lvjn4e 8Xav498F+IPD7av4xsbKDW472xuhaw3tgskcV3ZrHOXK+U4R4ZW+by1YSJlhWt4u/aj+GOieCT4n 0W8uNTurqw1O8traLT72aWIaUTFctewxxGW1jguMRSmYJtY46g4v6H+0X4H/ALH8Mf8ACVXL2uq6 xpukXl99mtbiay0+XWFUWyXNyiPHbiaVikXmuCeCeCCQDznT/wBkLSrHR/8AhF/7bkewi8KWOiQX QTbexapY302ox6opB2rItzIsqKOAy4zt4pnw4/ZLsNDvfA978SzpXjBvCPhqXSCJ7FXU38t6t2bu FZdwjHBUAfMM9cV3/wAO/wBoPSfElvpWl+IYJR4k1a91iJLTTrO5ukitNO1afTY7mdkWQQxsY1DO 5C7ixGFBx9H0AfP37QXwx8WfFvwu/grSYvD8+lahDLFcHWrSe4mtJ2GIby0aKRcSw5ZlHytu2kSL g58y0T9l3UdB+Ih164vrfxLpF1qWmaxNLqdzqK3sd9p1pbWwlWCGdbOZ2a1SZZJIwyOzA7wFx9nU UAfH2sfs2eJn/Z68GfDDwt4kg0bxh4HW3aw1lbdmijl8qS1umEQYNiW2nmUDdwxVjnFZT/smW+k+ Olv9AWyvvCd0mgpLYX9xqERtf7BjihhMUVrOlvcfJBGyiZPkkBbLA7R9rUUAeZ/CfwFcfDnwvd6B dXMd3LdaxrOpmSNCgxqmoT3qqQerIswVj3IyOK9MoooAKKKKAP/T/fyiiigAooooAKKKKACiiigA r5i8P/ADxH4btNV8Baf4yU/DXVZ9TlbR305TexRasZZJ7WO/84AQCWZ2TMBkUYTzMCvp2igD42l/ ZV1zXNGj0vxn44/tOXS9GtdA0qaDTVtfIsoLy0vJHuF89/OuJjZQqzqY0UKSsYLGvRdU+AkGpeO7 nxudaeNrnxPpviTyPIBAbTtM/s0Qbt/Rx+8344Py4PWvoSigD80fi/8As4fEK18RWb+EtPn8T6et v4kuEVUgNvPfa7qv9oizv4JL2zJtB8qO2+VZADujUgBveP8AhnfxbqniSHxDqPiuHT9PvPEWleLr /SYLETH+1rK2gglhjvHlU/ZX8hWUeVvDc7yvyV9bUUAfJGq/sv3l18OfB/w9sPFQFt4Xkvmmju7J rizv1vfMwZrZLiLMkBk3QlnZA3LI2Rtrr+yvd2nhmTwhpviwR6ff+AbfwLfGWwDyyJZw3EdveRMJ lEbA3Ls8ZDhgFAZeSfr+igD5auv2cdRm1nULWHxX5fg/W9c03xHqGmGxVrmS/wBMFqyLFeeaPLgl ks4ZJEMLPwyrIqt8u/4R+AUHhW88CXa6290fBNxr86gwBPtP9uyySkH5zs8nfgdd2O1fQ1FAHyf8 UP2WLH4l3Piy+bxPdaNe+JdS03UIrm0iUTWS2dkdOuYUYt8wu7R5omPGzzMgEqK0NS/Zxe31648W +CfECaHq1vr1trelh7EXFparBosehvaSQiWMyxPboSCrxsjFcHCnd9QUUAfG7/sq63YxyXvhrxyb DWtbsdasdevJdNSdbwa5dtezS28PnIttJFKzCLJlUIcOrsA1Lbfsi6Pp3inTfENtdaVqSR2GiWV9 HrGjrfu7aJEsMc1pJ9oj+ztJGqhg6yqrKHUZzn7HooA+SZv2YbvHhi3tPEkFunh3V7zVlvU09l1Z TearJqcsFteJcr5UMqyfZ50eOVZEBO0MRj62oooAKKKKACiiigAooooAKKKKAP/U/fyiiigAoooo AKKxPEviDTPCXhzVfFWtOY9P0a0nvbllG4rDbxmSQgdyFU8V8PT/ALT/AI80TxbqnijxT4QvrDRY fCuj6lZaJHdWk811Lq2qizikEg2hJgsiLJG7bVI4Zgd1AH35RXy5rf7R9z4Q8Y+FvBnjTw9a6dfe IrixspIItZtbm8trrUGZIcWqgSSQBwFaX5cZJVGVSa8J+GPxz+PMninw3/b2hpf2njnxN4ms5xca nAY7C00Wa5jRLRYoIygiSL5zIZDKU3AqX4AP0Zor5b8YftJeAdGv9H8TaXrz6l4Zh03xFf3z6eIJ oHGi28E8iuXXzPMVZP3axsoJb58jGPNr/wDa88Sax4ae78CeEra71m01rw3ZTwvqUU1m1pr139nX ZdRLs+0KVaN4yD5TMsn7xMbgD7tor4y8JfGDXbD4zfEe8+Luor4Z8N6Hd2Gi6Zby39u9n59xY296 RsWFZWnfzGbeZNoX5NuRuO/Y/tSW39uMmv8AhS70nwy2oeINLh1d7iGUSXXhxbmW5P2dD5ixPFaS sjnncu0qAVZgD6uor8/9U/bT1TWfAOsa/wDD7wtDcavZRaLfQRy38c9s1lqt6lrtnlhGIrpNw3wZ O3erB3AYV7Z/w0HeW8vinUtR8JzQeGvAUUq+IdTW8hf7Jd21gmoTwwQYElwkaSJGZBty7YVCoZgA fSlFfI2oftSal4ctbyDxd4AvtO1sW2kX1jp0V5bXD3lrrGoRabH+9ykcc0M0qebGx2gMCsjDJHF+ N/jb8S/F994N8IeHdGufC9/L4zn8P+IVg1G1E0QtNLk1NVguHhlR45YjHKzBFbCNFgF9wAPu2ivm 3xV+0v4O02Tw0fCD2viGz8RXs9iL9r6Oz0+Ce3WNjA9zIrJ9plEo8iE7fMwwDAjnAsv2svC2ofEy 6+H9lpjTwwalqGji5S5jaf7dpsMss5ktADJHbboXiWdm5kAyoVlYgH1jRXyNoP7V1vJ4c0Pxj478 JXXhPRPE+g6h4g02ea6huHkttPtYbwxyJFxHNLBI8kabmysTZwflEGjftd6HqfjzTvA1x4fltLie 9sdJvUN3FJeWep3lrHcmM2ije8ELSrFLOCAHzhSil6APsCivnL4XftF6J480nRtY8S2C+Dk8VybN BgvbyKW51EK3luyxR52DfgKCxLKQSFJKjy/T/wBr3xHq+m2Wp6Z8Lr+WLWNFvtf0/dqVmnnWGluk d40mT+6cGWPyVw3mbxu8vDYAPt2ivk7Uf2qtNijuvEWi+F7zUvB+jLo51fVfOihezOtQwXEOy2bL zCKG5hknIZdobCCRgQOe8T/tB+KL7x54Ri0TR7jSfBa+L9S0W81h54HW9GkWGom7ia2wZY4xc2x8 uQElvKOQqsu4A+0qK/PbWP2wf+E/+Hur3XgW2k0TUPs2japYXcNxDeg2N5qltbPHcBAVt7kxyjdC 275XO1yVbb7J47+MH/CWeK/B/wANvhH4qt7S51/VL601LUraOK7msk06zkuXijjmDRCaR1RcurBU 3kKTggA+paK/LfxD+0n8btM8G6r4i1XVZNJPhDStXe3ubTQpL6y8Raroep31ncQ3LxpKLONobSJy FaMgzs4k2R4r9OtMvf7R0201DyzF9qhjl2Hqu9Q2D7jOKAL1FFFABRRRQB//1f38ooooAKKKKAKG q6Xp+t6ZeaLq0C3VjfwyW9xC4ykkUqlHRh3DKSDXz5pn7K3wu063mgnl1bUzLaafYB77Up7l47PS rtL2zgjLsdqRSoOnLDO8sSTX0lRQB4hrf7P3gHX/AB0/j+8fUI72a/07VJraG9ljs57/AEoItrcS wqcMyJGqYPyEAEruAarDfAfwKkGgR2DXuny+GtYvtasp7a6eOVbnU5ZprtGbndDMZ3DRkY24AxgG vZ6KAPPvGfwu8F/EG+tL7xdYm/8AsllqOnCJnZYntdVjSK6jkVSNwdEAB6jnFchJ8BfDV14Pu/BW ra5r2qWk89lcQT3epyy3VlLp0qz2r20x+ZGjkRW3HczkDeWr3CigDjvDPgbQ/Cep65rOmec974im t7i+lmlMjSy2trFZo3PQ+VCm7HVsnqa5RPgf8PBFYW8tlJPDp2qatrEcckrOjXWtpdR3m9Tw0bre TAIeBkY6CvXKKAPBrf8AZ48FxeCNT+HV3qetahoGoW8FrDb3WpTS/YYrRg9uLRydyNEyqVcln+VQ WIGKlj/Z68CDVdQ1G4udUuoNct/J1axl1CY2OqSG0Fi9xeW4ISSZ7dVR2wAxVWKllUj3SigD5+0v 9mn4cafbTQ3kuqaxNIdLVLnUdQmuriG30a6W9s7aORzlYUnQOw6yH/WM3GOvT4O+CI/Ea+Klgm/t BddfxEG85tv9oSad/ZbNtzjZ9m42dN3zda9SooA8y+Jfwp8O/FfT49G8VXeoLpZV47qytbt7e3vY ZCpaK5Rfvqdo5BDAEgMAxzn6d8F/DGj+JdS8Q6Rf6pZQaxNc3V1pkV7INNkurtCk832foGfJdgCE Mnz7d/zV67RQB4p4h/Z9+GPirwD4T+GmuWEtxoXguSwk06Pz3V1/s6PyYlkcENIjxZjlVuJFYhs5 rXt/hD4dsPHF3460fUNT0ybUrlb29sbW9kj0+7ukiWETTW/3S5jRFbaVD7VLhiM16pRQByvgjwZo Xw88Kab4L8MxvFpekxeVAsjmRwmS3LNyeSetcJpXwG+Hei2GkaZY206waJot/oFsGuHYiw1J4nuF Yk/MxMKYY8jnHWvZaKAPnhv2YPhZ9rtJI01CKxhi0yO509L6ZbHUDoyJHZPeQZ2yvEsUYycbwiiQ MFAq7H+zh8N4/GKeMv8AiYO8OqXOsw2DX0zabDf30UsN3MlqT5eZ1mkLggjczMoUs2feqKAPBbD9 nXwPY+FrnwM+oaxeeHJEtIrfT7nUZpoLKGxnSeCK3DHcqo0aAbix2AJnbxXb/EL4Z+H/AIkW+mDV 5rzT77RLk3mn3+nXDWt5aTNG8LtHKvZ4pHR1YFWVuR0I9DooA8FuP2cvh7caFpXhDz9Uj8M6ZF5U mkpqEwsr/MzXDverkvO0srM0pZ/3uSJNwOK96AAGBRRQAUUUUAFFFFAH/9b9/KKKKACiiigAoooo AKKKKACivyWPxJ+IXga2vbLX/EeoXej/ABE+IRi0a6kuJGewvtP8Xra3OlLJnK29zp8fmQx52/u7 hMYYCvevgb4avvHPjD4i33i20vLqxfxH4m0+PUR4n1FJRDFevClvHp0bJFAscYKpIjhl2gjBOQAf d9Fflpp9gnh3wlpyL4i1rTLDxP8AE7VPCuralLrWoSyQaNbX18La2jlnuH+z+dJb29r5ybZNr7Q+ 5ga9n1vw14WX4yeD/gcviTVIfBF3p2t6m1qNdvGku9VtnsUSya7M5ufLhgmkuBbCUAlt5BVcUAfc lFflFdax8WNVuNB8MfC/xdf3reG/HHieLw9LPeSSpq1ro+nC6j0+8nZibmD7QZ7PzJGZlChixdM1 FD8StY+MaaJqfhr+1dd0zxD8S9SgXSV1e40ab7PD4ZadrKSeORGiFtcqzPECB5iEYyaAP1ior5g+ Mza74G+E3hjx/o/2vSz8PLvTtT1CyF5LdGTS0X7PqUE8zMTceVbSyShnLEyRK/XmvFLT4k66dd03 4rRzf2lY+M9c8Sz6MJLm4+zwaXomjXEVo8MUcqRMl01s1wd6sCJgwwwVgAfoVRXwh4e8c/HzxB4u +BOp654n0ewtfHOn3+qX2n2enTeQ0P2W1uEt/MkuyzyIruEl2gAksYyBtqxpn7VWpP4X8G67r91p Ol/214Y8S63qcpimnWyk0aa3hibyI5fNaPdK4kQHezLtVlOaAPueivzysPiv4z8deL/Cnh/xfH9n v/CvxGs7AyLatpr3EF14cu7xRNaG4utjK0hGPNOQFYqrZA7H4w/E3xr8Pfit41v/AAtNFczWnhrw glpaXzytYLcap4gu7GSVo42BDGNxll+Y7VByABQB9uUV8C658S/jle+LvDvg4eJNK0y/0X4gHw/q F1Bp0v2bUbWfQH1WDdA93uj279jKJW3OqOGABRq+k/tM/GjVvD3ij4hW3haL/hGbHTvFNxC00Cwr ZT6F5y2qyTfbHe585oWWZBbwmNiACQCSAfoFRXwB44+MPxP+H0I8Va1HpOp+JovAepa7GYFvLexR /t1gsdsYTcurqomIaYqJDgFdgLIdi4+NHx18N+Lda0zxFP4ev9N8KeJfDmi3f2ayuoJ7yHxI1qoa MvdSLA1q10ME+YJgvIjNAH3PRRRQAUUUUAFFFFABRRRQB//X/fyiiigAooooAKKKKACiiigDmJ/B Xg66sYtMudCsZrOC9/tKOF7aJo0vvONx9pVSuBN5zGTzB828ls5OaytP+Fvw00nxTN440rwppVn4 iuXkkl1KGyhjvJHm4kZplUOS+fmJOT3rvKKAOZu/BXg6/wBDv/DF9odjcaPqkk0t3ZyW0b21xJcO ZZXliKlHZ5CXYsCS3J55rmJfgt8H5/C8PgibwTor+H7eY3EdgdPt/syTkYMqxbNokI4LAbiO9em0 UAcvpnhbwZp8Wm2mj6TYW0fhzfHYxwQRItjvTaywqgAi3I2CFxlT6Go9O8H+B7eSLUtI0XT43+2T amk0FvED9tuUaOa6DKv+ulRmV5PvMpIJINfn/wD8IX8UdB+Ifjy18K6NqEdh8YvEN9o+o3aRMq6f HB5LJqYY42q9g13Esg4M0duueazfD0/xW8A+Dfhj4E8GaRr+i/2WmmxtFFBMbQ2lxrUlvdQmFbKZ d8Fl87tPcQhEaNowzbqAP01vbKz1Kzn07UYI7q0uo2imhlUPHJG4Ksjq2QysCQQRgiuYPhjwFbaX Z2J0vTotO8ORNb20fkwrDYwmHyWjjXG2JfIbYVGBsOPumvBP2cPFPxK8Y6h4kHjq7leLwUyeFXLI iJqGqae8jXepDaBxPG9uFAIVWEgwDXzlqOkWMvgT4seFfBnhzVLKzvfHGk6lbSSaLftDFarFpok1 CS2ngDX8KXFvKZ4V3NKAxYqp8wAH6ET+DPAevWGhrcaLp2oWWhPDcaVmCKSO0eFdsMltwRGUXhSm MDgcVhWHwz+Dseqazcab4X0MajfiZdTaKztvOlW8AMy3GF3MJgMuH4fqc15D+zDrFr4f8IaZ8NNX tZbHXZ5Nc1OJPsktnHc2a6ic3qWropsorh5w0Fs4BVcqu5ULV88/ELQovG3if4qap8P/AAjf6BqV noepaLDbW+jXdnceIDNdw3GpXT3PkRwS71iMVmDK0kheVxgOtAH3V4c8DfCbQtNt5/CehaNY2Fvc rdQvZ29ukS3So1usqsgA80IzRh87sErnnFbmr6F4IvtRDa9YafPf6kkEI+0xxNLOllKbiFBvG5xD KTIg52Mdwwea/Orx74Z8OXXgv4ga14d8IajD4e1HxH4euvDdjb6HfREXNklmL67isI4A8K7I2Xe8 ShmjYrkkFvQNQi8Zj9pO78WWWjvq39r6l4fGlre6DNNHHoL2sYu5o9RkwLGS2lNxKYWCOXKqysZF 2gH2hrHw+8B+Ire6tde8O6fqMN9dRX1wlxaxSrLdwIscc7hlO6RERVVz8wVQAcCqA+FPwxGsap4g HhLShqetxSwX1z9ih866iuBtlSZ9uXEg4cNncOua7+igDmtR8G+EdYXbq2iWV4PsrWOJreOQfZGZ XaD5lP7ssiEp93Kg44FS3HhPwtdzXVxdaRaTS309tdTs8CM0txZlDbyuSPmeEohjY8rtGCMCugoo AKKKKACiiigAooooAKKKKAP/0P38ooooAKKKKACiiigAooooAKKKKACiiigAooooAztM0jStFgkt tIs4rKKaaa4dYUVA81w5klkYKBl3dizMeSSSea0aKKAK4tLVbp75YUFzIixtKFG9kQkqpbqQCzED oCT6mrFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB/9H9/KKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAP/0v38ooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo A//ZUEsDBBQABgAIAAAAIQCTCm11TgYAAOcdAAAUAAAAcHB0L3RoZW1lL3RoZW1lMy54bWzsWUuP GzUcvyPxHay5t3lvN6tmq002aaHddpVNi3p0ZpwZdz3jke3sbm6oPSIhIQrigsSNAwIqtRKX8mkW iqBI/Qr4MTMZJ043bReo1OaQ2J7f//2wPbl85SQm4AgxjmnS8WoXqx5AiU8DnIQd7/ZocGHTA1zA JICEJqjjzRD3rmx/+MFluCUiFCMg6RO+BTteJES6ValwXy5DfpGmKJHPJpTFUMgpCysBg8eSb0wq 9Wp1oxJDnHgggbFke2sywT4CI8XS286Z94n8SgRXCz5hB4o1sig0NjisqR8+4z3CwBEkHU/KCejx CJ0IDxDIhXzQ8ar641W2L1cKIiJW0JboBvqT0WUEwWFd07FwXBDWBs32pd2CvwYQsYzr9/u9fq3g pwHQ96WlRpcytjnYrHVzniWQGS7z7lVb1aaNL/FvLOHb3W631bbwGmSGzSX8ZnWjuVO38Bpkhq1l /bs7vd6GhdcgM9xYwg8utTeaNl6DIoKTwyW0imcRmQIyoeSaE74p4Zt5AsxRlVJ2GfpErMq1GN6j bCABOrhQ4ASIWYom0Je4HiR4zLASALcQLD0xSz5fWlKyAPcZTkXH+ziFsiLmkBdPf3zx9DF48fTR 6f0np/d/OX3w4PT+zw7CazAJy4TPv//i728/BX89/u75w6/ceF7G//7TZ7/9+qUbKMrAZ18/+uPJ o2fffP7nDw8d8B0Gx2X4CMeIg5voGAxpLG1zCEBj9moUowjiMsVOEnKYQEXjQPdFZKFvziCBDlwX 2R68w2QXcAGvTu9ZCh9EbCqykFvA61FsAfcoJV3KnDZdV7LKXpgmoVs4m5ZxQwiPXLJ7C/HtT1OZ ztjFshchS819IkMOQ5QgAdQzeoiQg+wuxpZf97DPKKcTAe5i0IXY6ZIRHlvZNCe6hmMZl5lLQRlv yzd7d0CXEhf7XXRkI2VVQOJiiYjlxqtwKmDs1BjGpIy8AUXkUvJgxnzL4VzISIeIUNAPEOcumlts Zql7XXYPd9j3yCy2kUzgQxfyBqS0jNylh70IxqlTZ5xEZexH/FCmKAT7VDiVoHaFqLmMA0xWhvsO Rla4z67t2zi0VJoniHoyZa6SQNSuxxmZQKSZVxbadYyT97177d69w7CzeBY79ircYp/uURbgt79N 78Jpso9kZbzv0u+79LvYpVfV8/n35nk71sfx/NCt2cQrT+ATTMiBmBF0g+tGzqV5wUAu6okmKg78 aSSHmTgLFzKox4BR8QkW0UEEUymmpiWEPGMdcpBSLq8ZetnJW99VsbRZr7XyC6ZEQ7FHA7PcKF88 CzZ6FurLbS6ooRisK6xx6c2E1QxwTWk1rdqytMJkpzT9k3lT1g2A6rVCbaNuRMtEgQQFyu+GQR6W fzFEmdXGkAgGyLFcsq+m3Xnu3iwnytlKnI+TcwZzJ6uyW6gmktgzcNzx2q16ywM+TDveRB6b5DBO JT+uOg0kYdLxfGEMPLsWFyxuu7OqVs3Xlwy2RKSMi13II0OlH+WvVZK5/vVWU/nhfAxwNJP1tGhs 1v5HLfRPObRoMkG+WLEyn2bP6FQgdhAFx2BMpmwIpd5Nk10B5rLT61xTEyZzWz+RM7tws9pYfH2T 1QwkaQSzbFevaXILDVyPCx30rKReMVvQ/TVNURV/XqaU0/gdM0VlrjyfNgJ9e5K7OINA5WjHo0xE VHahNML+gMl9X8uSegFZFkolQNTLaKUrOpr3LcPDNLkwEkMcAoZlpxMRQ2hfZHaewayWdcWsMjJG WZ8p1OWp+R2jI0RGqno3lP0eiPJukjlC4xaDZs8zZ4xDVahv68HFpM2rbjxzQYZ+XWGlpl/aCtpv psI6G3BJnOlYS+LqrZU7z+JWm8pbBlBfsnFj5pP58XREhzL6oNjngUzEC6qrqSwsFsdSZ7NopClW /9UpqJD7L54dS84uDlELzn65uNd3djayfF3OI4erK8slqo5H+T1Ez5b+lKLje1L2rrzeTIlZ4amc mcE+0waPaTDLhoSblmAckbd0kgzRBODgJA/rgkezf32KzXxoBCjbC8LG2YQZfr6JFMT1s4kLivyO VxDrW5yLAZlLNngT5aJFFp4iyZu4bA3l3S5zZu+6LlsjUK/hMnHycpdlnlK77lLioRPBYC//G0vm r2GkU3b7HwAAAP//AwBQSwMEFAAGAAgAAAAhANj9jY+sAAAAtgAAABMAAABwcHQvdGFibGVTdHls ZXMueG1sDMxJDoIwGEDhvYl3aP59LUNRJBTCICt36gEqlCHpQGijEuPdZfnyki/NP0qil1jsZDQD /+ABEro13aQHBo97g2NA1nHdcWm0YLAKC3m236U8cU95c6sUV+vQpmibcAajc3NCiG1Hobg9mFno 7fVmUdxtuQykW/h705UkgecdieKTBtSJnsE3qoIgorTAp8vliGlIA1x6NMZxVNbVuan9Kix+QLI/ AAAA//8DAFBLAwQUAAYACAAAACEA6XN4m64BAACLAwAAEQAAAHBwdC92aWV3UHJvcHMueG1sjFPB btswDL0P2D8Iuq923C11jThFh2G7FNiApLtrEuOosCVBVFInXz9Kjt1ky6E3kXx8fHy0Fw9917I9 eNTW1Hx2k3MGRlqlTVPz5/X3TyVnGIRRorUGan4A5A/Ljx8WrtpreP3lGREYrETNtyG4KstQbqET eGMdGKptrO9EoNA3mfLilYi7NivyfJ51Qht+6vfv6bebjZbwzcpdByYMJB5aEUg8brXDkc29h815 QKJJ3ReSlrScicD297Di1vrjV+FXhCULOtHrTh9BJSCRBOtBPcEmMDySh/d3XwqendfW1qXS/Twv yU+xC/ZRveww1DyPyOxyXmzFVit4C+WqVScxaIRb2x9eq9h9Cn/+eQEZkKYnUfKE3ZNoKVoY8xiD 5UJU2LN47oIIiGaWJxmUPlxJZ1Ofq6zXjTasp2L5mbNDzYvbtGw2DY2wZkfqnzBMb0aN5DWdhazk zFmSWszmiX+EDMmyHIe+kUTyyYBB0KU9xgbANfThzLEzL//ZOr++9WX6+tZ52nkETDPSAf+T0NCN Vk5I+uSZpOa7eRFnyMP4HFiG/2j5FwAA//8DAFBLAwQUAAYACAAAACEAJiDaVqsBAACOAwAAEQAA AHBwdC9wcmVzUHJvcHMueG1svJPfbtsgFMbvJ+0dLO4J+B+JrTgVNkSatEnV1D0AwzhBsw0C0naa 9u6jTtqtWydVuxg3B3R0Pn7fObC9up/G5FY5r83cgHSFQaJmaXo9Hxrw6WYPNyDxQcy9GM2sGvBV eXC1e/tma2vrlFdzECGWXrskCs2+Fg04hmBrhLw8qkn4lbFqjrnBuEmEeHQH1DtxFy+YRpRhTNAk 9Awu9e419WYYtFTMyNMUAc4iTo0LiT9q6x/V7GvUfvXxDGkXTcrRfXCn3VbU3h0+d6NLbsXYgH1c XQfQCwkc1wuJnDLCyUMC/VS1tboP73247JKT0w34xtek41VBIcF5B4u0yGBb8RYSluZrjFNMs/X3 B7q0qHvtpXD9u0kcFO91YCKIR/Np8Yf9SUtnvBnCSprp0kdkzZ1y1uillSm+zGOhXpygBe45I8tT iklG4braUFjkWQVpyxhsW7opCclwmeInRjWI0xgWRmb1/8Dbs5LvKWUQ847Dosw5rDZ5CgvSZnnL Y8iLM15Zy6Nw4cYJ+SW+yY9qaIVX/RNk+S+Q2V8hz3EZOfr9C+1+AAAA//8DAFBLAwQUAAYACAAA ACEAXek7zG4BAAC4AgAAEQAIAWRvY1Byb3BzL2NvcmUueG1sIKIEASigAAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAfJJRS8MwEMffBb9DyXuWpnWbhq6Cii86EJxMfAvJdQu2aUlOt317026t Gw4fm/vdL3f/NLvdVmX0Dc6b2s4IH8UkAqtqbexqRt4Wj/SaRB6l1bKsLczIDjy5zS8vMtUIVTt4 cXUDDg34KJisF6qZkTViIxjzag2V9KNA2FAsaldJDJ9uxRqpPuUKWBLHE1YBSi1RslZIm8FIDkqt BmXz5cpOoBWDEiqw6BkfcfbLIrjKn23oKkdkZXDXwFm0Lw701psB3Gw2o03aoWF+zt7nz6/dqtTY NisFJM+0EmiwhFw7WSA1gAW1gKq2BXXQJg7U+3XGBrBtUQ4k1i5/CotFy5AW2I7oz9vYS+lxHl6o MKDvdqfo33LbEe4z7QPnCecdMxxkh7z2F4COwp5in0pfWab3D4tHkicxT2k8pclkwa8ET8R4/NHO dtL/K6wOI/xvnNB4TPl0kaQiTcTVzZGxF+TdxKf/Wv4DAAD//wMAUEsDBBQABgAIAAAAIQCO4Jbw 9QIAANMHAAAQAAgBZG9jUHJvcHMvYXBwLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAJxVzW7bMAy+D9g7cN5lA5bacf8DxUWRNWiHpQ0WtzurNp0IlSVDUtJmp73GXm9PMtpu nGRN22WnkPy+UPQnkWQnD7mEGRortOp67Z3AA1SJToUad73ruN868sA6rlIutcKuN0frnURv37Ch 0QUaJ9ACpVC2602cKzq+b5MJ5tzuEKwIybTJuSPXjH2dZSLBzzqZ5qicHwbBgY8PDlWKaatoEnp1 xs7M/W/SVCdlffYmnheUL2KxdlzGIscoPNo/DJm/DLDv2qQ2OtxrM7822WlRSJFwR5pEA5EYbXXm YMAToZy2ExjqezRDTR7zV7kkCloqovL6VY3RlWrZxCAqGE30PXzY6+x+ZP4GIhtyw8eGFxMbhcER cZY+G0mRoo3ah8x/NNmldvQTML822LlIU1SPKIXXfDYY9KQoKmBhslHCJfZIpyjj0iKlbgLsHHn5 BoZcGGLOXGeGidMGrPhBr+DAg1tusVS36824EVw5r6bVTmXLwjoT9bVyFq4tpsxvgpW5yl21xV60 WxHIeJFY54rpaeAWudtb5K7kg1g4iXabIw43n1E5lZBkr0tcn3GV0a27DYqH7VXJqypqweuCelyK WyNWS1xiemoEmo3YKRUmNyJXVVvBE3Eb6/Is7l1d9mGEhuYH0IiAb2ejtRj0tMrEeGqqdw4DnaK0 AKnhmWsJdFlLoUuI07LVH1p5yWgFxwCL7DfCuCmXcKEcGpFTE86hffQJwqB9AJsLpxEBF9ZO12+s sSoI3tev4IlWU2OwbOsNWN/oHC7O4j4c78MA0dHlbSSOhCLl/oVZDilt6fOeKWeJh6/gdcM8j++9 gu+/pNUzhzdTEFbH2UuJnqlyi0TbcOMJd79//rLApYRMyzv77kkPL5rxr/br6bzgah59mSpBWwku 0d1rc0cvaoGwr0Ld2esi1p+5w8UEXQ+y0YQbTGk3NRO2CbBz6mQjS35vwtUY0wXnKVAupJt6R0ft /Z0gCMNq8Sxi5T5ZLM/oDwAAAP//AwBQSwECLQAUAAYACAAAACEAC7ewIiQCAACAFgAAEwAAAAAA AAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQCj7IImAgEAAOIC AAALAAAAAAAAAAAAAAAAAF0EAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQBL9T3svQAAADcB AAAgAAAAAAAAAAAAAAAAAJAHAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlNy54bWwucmVsc1BLAQIt ABQABgAIAAAAIQBL9T3svQAAADcBAAAgAAAAAAAAAAAAAAAAAIsIAABwcHQvc2xpZGVzL19yZWxz L3NsaWRlNi54bWwucmVsc1BLAQItABQABgAIAAAAIQBL9T3svQAAADcBAAAgAAAAAAAAAAAAAAAA AIYJAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlNS54bWwucmVsc1BLAQItABQABgAIAAAAIQBL9T3s vQAAADcBAAAgAAAAAAAAAAAAAAAAAIEKAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMy54bWwucmVs c1BLAQItABQABgAIAAAAIQBL9T3svQAAADcBAAAgAAAAAAAAAAAAAAAAAHwLAABwcHQvc2xpZGVz L19yZWxzL3NsaWRlOC54bWwucmVsc1BLAQItABQABgAIAAAAIQBL9T3svQAAADcBAAAgAAAAAAAA AAAAAAAAAHcMAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMi54bWwucmVsc1BLAQItABQABgAIAAAA IQBjXCO0wAAAADcBAAAgAAAAAAAAAAAAAAAAAHINAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMS54 bWwucmVsc1BLAQItABQABgAIAAAAIQBL9T3svQAAADcBAAAgAAAAAAAAAAAAAAAAAHAOAABwcHQv c2xpZGVzL19yZWxzL3NsaWRlNC54bWwucmVsc1BLAQItABQABgAIAAAAIQBL9T3svQAAADcBAAAh AAAAAAAAAAAAAAAAAGsPAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMTAueG1sLnJlbHNQSwECLQAU AAYACAAAACEAfTdrho8BAABrDQAAHwAAAAAAAAAAAAAAAABnEAAAcHB0L19yZWxzL3ByZXNlbnRh dGlvbi54bWwucmVsc1BLAQItABQABgAIAAAAIQBjXCO0wAAAADcBAAAhAAAAAAAAAAAAAAAAADsT AABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMTcueG1sLnJlbHNQSwECLQAUAAYACAAAACEAS/U97L0A AAA3AQAAIQAAAAAAAAAAAAAAAAA6FAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTE2LnhtbC5yZWxz UEsBAi0AFAAGAAgAAAAhAEv1Pey9AAAANwEAACEAAAAAAAAAAAAAAAAANhUAAHBwdC9zbGlkZXMv X3JlbHMvc2xpZGUxNS54bWwucmVsc1BLAQItABQABgAIAAAAIQBL9T3svQAAADcBAAAhAAAAAAAA AAAAAAAAADIWAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMTQueG1sLnJlbHNQSwECLQAUAAYACAAA ACEAS/U97L0AAAA3AQAAIQAAAAAAAAAAAAAAAAAuFwAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTEz LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAEv1Pey9AAAANwEAACEAAAAAAAAAAAAAAAAAKhgAAHBw dC9zbGlkZXMvX3JlbHMvc2xpZGUxMi54bWwucmVsc1BLAQItABQABgAIAAAAIQBL9T3svQAAADcB AAAhAAAAAAAAAAAAAAAAACYZAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMTEueG1sLnJlbHNQSwEC LQAUAAYACAAAACEAS/U97L0AAAA3AQAAIAAAAAAAAAAAAAAAAAAiGgAAcHB0L3NsaWRlcy9fcmVs cy9zbGlkZTkueG1sLnJlbHNQSwECLQAUAAYACAAAACEANrrgLW4DAADSEAAAFAAAAAAAAAAAAAAA AAAdGwAAcHB0L3ByZXNlbnRhdGlvbi54bWxQSwECLQAUAAYACAAAACEAe6WzOhEDAAA3CQAAFgAA AAAAAAAAAAAAAAC9HgAAcHB0L3NsaWRlcy9zbGlkZTE0LnhtbFBLAQItABQABgAIAAAAIQDJce14 rggAAB1YAAAVAAAAAAAAAAAAAAAAAAIiAABwcHQvc2xpZGVzL3NsaWRlOC54bWxQSwECLQAUAAYA CAAAACEAMJLSAmEIAACuVAAAFQAAAAAAAAAAAAAAAADjKgAAcHB0L3NsaWRlcy9zbGlkZTcueG1s UEsBAi0AFAAGAAgAAAAhALodRjFQCAAA1UoAABUAAAAAAAAAAAAAAAAAdzMAAHBwdC9zbGlkZXMv c2xpZGU2LnhtbFBLAQItABQABgAIAAAAIQATnU8HawcAAAc/AAAVAAAAAAAAAAAAAAAAAPo7AABw cHQvc2xpZGVzL3NsaWRlNS54bWxQSwECLQAUAAYACAAAACEAbcduD6YIAAC9WAAAFQAAAAAAAAAA AAAAAACYQwAAcHB0L3NsaWRlcy9zbGlkZTkueG1sUEsBAi0AFAAGAAgAAAAhAH7BBezYCAAAvmQA ABYAAAAAAAAAAAAAAAAAcUwAAHBwdC9zbGlkZXMvc2xpZGUxMC54bWxQSwECLQAUAAYACAAAACEA W7l9L4EIAACwUgAAFgAAAAAAAAAAAAAAAAB9VQAAcHB0L3NsaWRlcy9zbGlkZTExLnhtbFBLAQIt ABQABgAIAAAAIQBlXKBPHAQAAIwLAAAWAAAAAAAAAAAAAAAAADJeAABwcHQvc2xpZGVzL3NsaWRl MTUueG1sUEsBAi0AFAAGAAgAAAAhAPCf6Ml1BQAAPnsAABYAAAAAAAAAAAAAAAAAgmIAAHBwdC9z bGlkZXMvc2xpZGUxNi54bWxQSwECLQAUAAYACAAAACEA7PTUxZYCAADnBQAAFgAAAAAAAAAAAAAA AAAraAAAcHB0L3NsaWRlcy9zbGlkZTE3LnhtbFBLAQItABQABgAIAAAAIQAII/d5DQMAAOAJAAAW AAAAAAAAAAAAAAAAAPVqAABwcHQvc2xpZGVzL3NsaWRlMTIueG1sUEsBAi0AFAAGAAgAAAAhAMPI YVejBgAAiy8AABUAAAAAAAAAAAAAAAAANm4AAHBwdC9zbGlkZXMvc2xpZGU0LnhtbFBLAQItABQA BgAIAAAAIQBVrNaZ+QIAANEIAAAVAAAAAAAAAAAAAAAAAAx1AABwcHQvc2xpZGVzL3NsaWRlMy54 bWxQSwECLQAUAAYACAAAACEAhTplON0DAABlDgAAFQAAAAAAAAAAAAAAAAA4eAAAcHB0L3NsaWRl cy9zbGlkZTIueG1sUEsBAi0AFAAGAAgAAAAhADG2AueRBAAADxAAABYAAAAAAAAAAAAAAAAASHwA AHBwdC9zbGlkZXMvc2xpZGUxMy54bWxQSwECLQAUAAYACAAAACEABNxtRf0EAACOGwAAFQAAAAAA AAAAAAAAAAANgQAAcHB0L3NsaWRlcy9zbGlkZTEueG1sUEsBAi0AFAAGAAgAAAAhANXRkvG8AAAA NwEAACwAAAAAAAAAAAAAAAAAPYYAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQx LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG8AAAANwEAACwAAAAAAAAAAAAAAAAAQ4cAAHBw dC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ4LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAh ANXRkvG8AAAANwEAAC0AAAAAAAAAAAAAAAAASYgAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xp ZGVMYXlvdXQxMC54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvAAAADcBAAAtAAAAAAAAAAAA AAAAAFCJAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0MTEueG1sLnJlbHNQSwEC LQAUAAYACAAAACEA1dGS8bwAAAA3AQAALAAAAAAAAAAAAAAAAABXigAAcHB0L3NsaWRlTGF5b3V0 cy9fcmVscy9zbGlkZUxheW91dDkueG1sLnJlbHNQSwECLQAUAAYACAAAACEA1dGS8bwAAAA3AQAA LAAAAAAAAAAAAAAAAABdiwAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDYueG1s LnJlbHNQSwECLQAUAAYACAAAACEA1dGS8bwAAAA3AQAALAAAAAAAAAAAAAAAAABjjAAAcHB0L3Ns aWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDUueG1sLnJlbHNQSwECLQAUAAYACAAAACEA1dGS 8bwAAAA3AQAALAAAAAAAAAAAAAAAAABpjQAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxh eW91dDQueG1sLnJlbHNQSwECLQAUAAYACAAAACEA1dGS8bwAAAA3AQAALAAAAAAAAAAAAAAAAABv jgAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDMueG1sLnJlbHNQSwECLQAUAAYA CAAAACEA1dGS8bwAAAA3AQAALAAAAAAAAAAAAAAAAAB1jwAAcHB0L3NsaWRlTGF5b3V0cy9fcmVs cy9zbGlkZUxheW91dDIueG1sLnJlbHNQSwECLQAUAAYACAAAACEA1dGS8bwAAAA3AQAALAAAAAAA AAAAAAAAAAB7kAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDcueG1sLnJlbHNQ SwECLQAUAAYACAAAACEAEii2Ux8HAADoLgAAIQAAAAAAAAAAAAAAAACBkQAAcHB0L3NsaWRlTWFz dGVycy9zbGlkZU1hc3RlcjEueG1sUEsBAi0AFAAGAAgAAAAhADTNuc4WAQAAxwcAACwAAAAAAAAA AAAAAAAA35gAAHBwdC9zbGlkZU1hc3RlcnMvX3JlbHMvc2xpZGVNYXN0ZXIxLnhtbC5yZWxzUEsB Ai0AFAAGAAgAAAAhADR+VMeUAwAAxgsAACIAAAAAAAAAAAAAAAAAP5oAAHBwdC9zbGlkZUxheW91 dHMvc2xpZGVMYXlvdXQxMC54bWxQSwECLQAUAAYACAAAACEA2FuuGJUEAAAqEgAAIQAAAAAAAAAA AAAAAAATngAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDkueG1sUEsBAi0AFAAGAAgAAAAh AJJbiCvOBAAAuxIAACEAAAAAAAAAAAAAAAAA56IAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlv dXQ4LnhtbFBLAQItABQABgAIAAAAIQBJgYLHFQMAALIIAAAhAAAAAAAAAAAAAAAAAPSnAABwcHQv c2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0Ni54bWxQSwECLQAUAAYACAAAACEAhDghQMkDAACmDAAA IgAAAAAAAAAAAAAAAABIqwAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDExLnhtbFBLAQIt ABQABgAIAAAAIQB/NqP8AwUAAC8cAAAhAAAAAAAAAAAAAAAAAFGvAABwcHQvc2xpZGVMYXlvdXRz L3NsaWRlTGF5b3V0NS54bWxQSwECLQAUAAYACAAAACEAlUE5SxMEAABhEgAAIQAAAAAAAAAAAAAA AACTtAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDQueG1sUEsBAi0AFAAGAAgAAAAhAPrk b3nnAgAAYAcAACEAAAAAAAAAAAAAAAAA5bgAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ3 LnhtbFBLAQItABQABgAIAAAAIQCS64cNOgQAAP4QAAAhAAAAAAAAAAAAAAAAAAu8AABwcHQvc2xp ZGVMYXlvdXRzL3NsaWRlTGF5b3V0MS54bWxQSwECLQAUAAYACAAAACEA5pGUcnsEAABSEQAAIQAA AAAAAAAAAAAAAACEwAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDMueG1sUEsBAi0AFAAG AAgAAAAhAI+sdqZ9AwAAmQsAACEAAAAAAAAAAAAAAAAAPsUAAHBwdC9zbGlkZUxheW91dHMvc2xp ZGVMYXlvdXQyLnhtbFBLAQItABQABgAIAAAAIQCTCm11TgYAAOcdAAAUAAAAAAAAAAAAAAAAAPrI AABwcHQvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQBBIgXowgUAAOkdAAAhAAAAAAAA AAAAAAAAAHrPAABwcHQvbm90ZXNNYXN0ZXJzL25vdGVzTWFzdGVyMS54bWxQSwECLQAUAAYACAAA ACEAk6p9mLkAAAAkAQAAMAAAAAAAAAAAAAAAAAB71QAAcHB0L2hhbmRvdXRNYXN0ZXJzL19yZWxz L2hhbmRvdXRNYXN0ZXIxLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAJMKbXVOBgAA5x0AABQAAAAA AAAAAAAAAAAAgtYAAHBwdC90aGVtZS90aGVtZTIueG1sUEsBAi0AFAAGAAgAAAAhADntPcXmAwAA lg0AACUAAAAAAAAAAAAAAAAAAt0AAHBwdC9oYW5kb3V0TWFzdGVycy9oYW5kb3V0TWFzdGVyMS54 bWxQSwECLQAUAAYACAAAACEAtM9YGbkAAAAkAQAALAAAAAAAAAAAAAAAAAAr4QAAcHB0L25vdGVz TWFzdGVycy9fcmVscy9ub3Rlc01hc3RlcjEueG1sLnJlbHNQSwECLQAKAAAAAAAAACEATxCBDvEx AADxMQAAFwAAAAAAAAAAAAAAAAAu4gAAZG9jUHJvcHMvdGh1bWJuYWlsLmpwZWdQSwECLQAUAAYA CAAAACEAkwptdU4GAADnHQAAFAAAAAAAAAAAAAAAAABUFAEAcHB0L3RoZW1lL3RoZW1lMy54bWxQ SwECLQAUAAYACAAAACEA2P2Nj6wAAAC2AAAAEwAAAAAAAAAAAAAAAADUGgEAcHB0L3RhYmxlU3R5 bGVzLnhtbFBLAQItABQABgAIAAAAIQDpc3ibrgEAAIsDAAARAAAAAAAAAAAAAAAAALEbAQBwcHQv dmlld1Byb3BzLnhtbFBLAQItABQABgAIAAAAIQAmINpWqwEAAI4DAAARAAAAAAAAAAAAAAAAAI4d AQBwcHQvcHJlc1Byb3BzLnhtbFBLAQItABQABgAIAAAAIQBd6TvMbgEAALgCAAARAAAAAAAAAAAA AAAAAGgfAQBkb2NQcm9wcy9jb3JlLnhtbFBLAQItABQABgAIAAAAIQCO4Jbw9QIAANMHAAAQAAAA AAAAAAAAAAAAAA0iAQBkb2NQcm9wcy9hcHAueG1sUEsFBgAAAABLAEsASxYAADgmAQAAAA== --_002_DB7556EB55674DAFBC60691C79AB2A7Fjunipernet_-- From nobody Fri May 27 10:29:13 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D09EF12D7D4 for ; Fri, 27 May 2016 10:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WhJPykRa7rx for ; Fri, 27 May 2016 10:29:07 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B4F112DAEF for ; Fri, 27 May 2016 10:29:06 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id h19so112350921ywc.0 for ; Fri, 27 May 2016 10:29:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=vyFRQnMvvPUjI2U3dAhQVikZEHo1baav9CjaJqssKSY=; b=AbQJ7zE0f2orpSPy+V0ZO8fZU7Ds1lj6p6s3Xlalor1ou891k+GaV98E6QpQHMvMer S/87BvFZlUBpoHULMQ+0o8ybFJW4i0/nXOUJiEuatPVoy8jAylpz+qROUy5HDnm8Eff2 rvjsicZFPYhYrRLC733J1AyznB+nFPMjb6+KOVtwAZDObS5RhOTzspkXm/Zon+p+eR+L nNMAHuoWTOc2hfrWLShJCYTefryAF5LYk58c/yhx3pEL1hSA5VzBIoLtvLcC3nscvdgr pZP2EYdpTN1WRRd2B3MR1epNmum3CmxfNuBaMZh9ptRn8ChN+LhPNk7foFiWkIPeu7jK jeiw== 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; bh=vyFRQnMvvPUjI2U3dAhQVikZEHo1baav9CjaJqssKSY=; b=f61Bv06V9dOBp5WwAmgBuAV7yU2dW0uTOSmOWtdXwmYufaZHwMU2/PC3Gr6W8wHPKi VWAa8W0tc6bUZ3N4rfZBGJvXLB2KhRw9MMVyxD8xAa9oBItmPsVLatg++a/c0Zq46gm+ GLGQSrkyINxVya/Ps6y6tJHKGEm/zeypzcb60NGkBryndPm0cZo4sVvBBA2qYSsJpUAA bD0Z1v+XpxVC99GKo5apiE6HX1Nor8tFNeX8IJbkIb+wKtHMjLouNF7SqquLwn3VlZ4k yN6jCo4431GJdLpoefmK7EWo5HZZuM5J77/T0L5lZ8DzudpX0Px7Qmieup50GuGoTDna +vOg== X-Gm-Message-State: ALyK8tKxQusckMY3M1zFcOqAino+ndlATkSQOMQz+EMXDCo5vGXYc2kP3BCFjvII+PeFJk/tbYlToKLCRIvq3w== MIME-Version: 1.0 X-Received: by 10.129.137.129 with SMTP id z123mr10115552ywf.101.1464370145333; Fri, 27 May 2016 10:29:05 -0700 (PDT) Received: by 10.37.44.199 with HTTP; Fri, 27 May 2016 10:29:05 -0700 (PDT) In-Reply-To: References: <3C88D813-7674-47C4-A6AF-E02C368CE71C@juniper.net> <20160429.100226.431840842419129504.mbj@tail-f.com> <20160429081529.GA26297@elstar.local> <20160429.102116.1627845264494578220.mbj@tail-f.com> <00aa01d1a209$2d165a20$4001a8c0@gateway.2wire.net> <9E3A9643-2348-42AA-A6B0-6FB9F13D1A29@juniper.net> <022801d1a456$c20e12e0$4001a8c0@gateway.2wire.net> <92BAF631-804E-45AD-89A3-48059966B2F4@gmail.com> Date: Fri, 27 May 2016 10:29:05 -0700 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: multipart/alternative; boundary=94eb2c06bf3855475a0533d63e1c Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Confirming the decision to split the server-model draft into several drafts. X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 17:29:12 -0000 --94eb2c06bf3855475a0533d63e1c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, #3 is better to decouple the normative references and instability as each protocol changes over time. Andy On Fri, May 27, 2016 at 10:12 AM, Kent Watsen wrote: > > > On 5/3/16, 7:18 PM, "Mahesh Jethanandani" wrote= : > > >It appears that a virtual interim meeting might help this discussion and > the discussion around key-chain models. > > > >Consider this a two week notice for the meeting. Details will be sent ou= t > later. > > > >Mahesh & Mehmet > > > Okay, we had the interim. The slides I presented then are attached. > > Of the various proposals listed in the slides, the interim=E2=80=99s cons= ensus was > to move forward with either proposal #2 or proposal #3 (slides 8 and 9). > The only difference between these proposals is that #3 splits out the > restconf client/server models into its own draft, as opposed to having th= em > in the same draft with the netconf client/server models. > > Assuming the interim=E2=80=99s consensus is upheld here on list, we now n= eed to > pick between proposals #2 and #3. FWIW, I have a slight preference for = #3 > only because I like the consistency of it. Any other opinions? > > Thanks, > Kent > > > --94eb2c06bf3855475a0533d63e1c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,


#3 is better to deco= uple the normative references and instability as each protocol changes over= time.


Andy


On Fri, May 27= , 2016 at 10:12 AM, Kent Watsen <kwatsen@juniper.net> wrot= e:


On 5/3/16, 7:18 PM, "Mahesh Jethanandani" <mjethanandani@gmail.com> wrote:

>It appears that a virtual interim meeting might help this discussion an= d the discussion around key-chain models.
>
>Consider this a two week notice for the meeting. Details will be sent o= ut later.
>
>Mahesh & Mehmet


Okay, we had the interim.=C2=A0 The slides I presented then are attached.
Of the various proposals listed in the slides, the interim=E2=80=99s consen= sus was to move forward with either proposal #2 or proposal #3 (slides 8 an= d 9).=C2=A0 The only difference between these proposals is that #3 splits o= ut the restconf client/server models into its own draft, as opposed to havi= ng them in the same draft with the netconf client/server models.

Assuming the interim=E2=80=99s consensus is upheld here on list, we now nee= d to pick between proposals #2 and #3.=C2=A0 =C2=A0FWIW, I have a slight pr= eference for #3 only because I like the consistency of it.=C2=A0 Any other = opinions?

Thanks,
Kent



--94eb2c06bf3855475a0533d63e1c-- From nobody Fri May 27 10:31:54 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B923B12D77C for ; Fri, 27 May 2016 10:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKELW6p1CLEG for ; Fri, 27 May 2016 10:31:50 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0797.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:797]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E901D12D0A7 for ; Fri, 27 May 2016 10:31:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bcwuPf4ft2NS3zo55gIeFBb+GnnkIA385kkwNJ04b3w=; b=b/p4ii85PgDr39IZDnN6gxpC8mcxNrX76sYPovFUiYn8T+uXitYy5d9GA19hDRJZZl9DkbNabszoDDE8Rnu+yXDuhTwksqFZzERJnJrCxbsfrscxcUBm5W8pCdiZE664cMnZ2Yi9cOA62O+UJjV4H6P21YECVQ0eFJoUCfDOkZA= Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1449.namprd05.prod.outlook.com (10.160.148.155) with Microsoft SMTP Server (TLS) id 15.1.501.7; Fri, 27 May 2016 17:31:29 +0000 Received: from CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) by CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) with mapi id 15.01.0501.016; Fri, 27 May 2016 17:31:29 +0000 From: Kent Watsen To: Mahesh Jethanandani , Netconf Thread-Topic: [Netconf] Semi-configurable design in server model draft Thread-Index: AQHRt6undd9KBwAb2k2PocgHOjB2f5/MyM0A Date: Fri, 27 May 2016 17:31:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.16.0.160506 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-ms-office365-filtering-correlation-id: 7acda86b-1180-4e38-c219-08d38654bcb6 x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1449; 5:rHHrgjX+Xalmptz3n7chSxXo5BLe4ciEzbVyEPbab+nGwzT+pMGJ4d6UDfOFERkbM22oBmGsfWTH8k4B+t2XGfDETViXHAZn1CLdk3YAVphFD8ZdgurAMvo/WWn3JK6BDmufYRkTjgoSt1jtkKcrqg==; 24:mAedTgtgqAJ4HIJQYgDoP8kYqZsTrGh1O1PRWnWjchqC/2nkG2rMq0lqyIPs5yOi957q5S6Gq3jSsnAaUfQNvugE/TEyOlAdXc8PNs9ZQ2k=; 7:mC52awkwCmFx7A20yu4DZjf47l4Rw++iGh+3NC9csuaRRq57+tfbIN/YK+XV4SU8ul6YCNSlKW8Bi31K/3VfxfgjyJ2xrEPCPdMDUmrWjjqzdQ3y9GPuuLhquYydTdIlL446cHbAmXkLoa7Rxf4bbygIeFv/d2lbbeRUG9Ql4/4WdP9annXYVi2Q5tkTGuQ5 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1449; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:CY1PR0501MB1449; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1449; x-forefront-prvs: 09555FB1AD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(51444003)(377454003)(36756003)(102836003)(6116002)(1220700001)(586003)(106116001)(19300405004)(10400500002)(5001770100001)(16236675004)(3846002)(19580395003)(3660700001)(3280700002)(19580405001)(2906002)(5008740100001)(92566002)(76176999)(54356999)(50986999)(5002640100001)(8936002)(19625215002)(11100500001)(122556002)(2900100001)(82746002)(87936001)(15975445007)(2950100001)(99286002)(77096005)(81166006)(83716003)(8676002)(83506001)(107886002)(4001350100001)(189998001)(66066001)(86362001)(5004730100002)(33656002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1449; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CF412B7FFCAB452C9AE08494B7E674F5junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 27 May 2016 17:31:29.0059 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1449 Archived-At: Subject: Re: [Netconf] Semi-configurable design in server model draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 17:31:53 -0000 --_000_CF412B7FFCAB452C9AE08494B7E674F5junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQgc2hvdWxkIGJlIG5vdGVkIHRoYXQgdGhlIGZvbGxvd2luZyBleGNoYW5nZSBoYXBwZW5lZCBv biBBcHIgN3RoOg0KDQo8a2VudD4NClllcywgdGhlIGFjdGlvbiBzdGF0ZW1lbnRzIGFyZSBpbnRl bmRlZCB0byB1cGRhdGUgdGhlIHJ1bm5pbmcgZGF0YXN0b3JlLiAgUHJlc3VtYWJseSBiZWNhdXNl IHRoZSBhY3Rpb25zIGFyZSBlaXRoZXIgZ2VuZXJhdGluZyBvciBsb2FkaW5nIGEgbmV3IGtleSwg dGhlcmUgd291bGQgbm90IGJlIGEgcmVhbCB3b3JsZCBsb2NraW5nIGlzc3VlLCBidXQgSSBjYW4g c2VlIGhvdyB0aGlzIG1pZ2h0IGxlYWQgdG8gdW5kZXNpcmFibGUgcmVzdWx0cy4gIEFjY2VzcyBj b250cm9sIChOQUNNKSB3YXMgcmVtb3ZlZCB3aGVuIHdlIG1vdmVkIHRvIHRoZSBrZXljaGFpbiBi YXNlZCBhcHByb2FjaCwgYnV0IHByZXN1bWFibHkgdGhlIHByaXZhdGUga2V5IHdvdWxkIG5lZWQg dG8gcHJvdGVjdGVkIGJ5IG5hY206ZGVmYXVsdC1kZW55LWFsbC4NCg0KSSBzZWUgd2hhdCB5b3Un cmUgc2F5aW5nLiAgWW91J3JlIHJpZ2h0IGFib3V0IHRoaXMgYnJlYWtpbmcgYmFja3VwIGFuZCBy ZXN0b3JlLiAgVGhlIG9ubHkgd2F5IHRvIGZpeCBpdCBpcyBmb3IgdGhlIGJhY2t1cCAoPGdldC1j b25maWc+KSB0byBjb250YWluIHRoZSBwcml2YXRlIGtleXMuICBCdXQgbm90ZSB0aGF0IHN5c3Rl bXMgdXNpbmcgYSBUUE0gYWN0dWFsbHkgaGF2ZSBOTyBXQVkgdG8gZ2V0IHRoZSBwcml2YXRlIGtl eSBvdXQgb2YgdGhlIFRQTSAtIG9ubHkgdGhlIFRQTSBpdHNlbGYgaGFzIGFjY2VzcyB0byB0aGUg cHJpdmF0ZSBrZXkuICBTbyBmb3IgdGhlc2Ugc3lzdGVtcywgYmFja3VwL3Jlc3RvcmUgKFJNQSkg aXMgaW1wb3NzaWJsZSwgZXZlbiB3aXRoIHJvb3QtbGV2ZWwgYWNjZXNzIG9uIHRoZSBjb21tYW5k IGxpbmUuDQoNCkknbSBub3Qgc3VyZSBpZiBJIHVuZGVyc3RhbmQgeW91ciBmaXJzdCBvcHRpb24u ICBEbyB5b3UgbWVhbiB0aGUgY2xpZW50IHdvdWxkIGNyZWF0ZSBhIGR1bW15IHByaXZhdGUga2V5 IGVudHJ5IChhIHBsYWNlaG9sZGVyKSBhbmQgdGhlbiBjYWxsIGFuIGFjdGlvbiB0byBwb3B1bGF0 ZSB0aGUga2V5IHdpdGggZGF0YT8NCjwva2VudD4NCg0KPG1hcnRpbj4NClllcywgYnV0IHNpbmNl IHRoZSBwcml2YXRlIGtleSBpcyBub3QgcGFydCBvZiB0aGUgY29uZmlnLCB0aGUgYWN0aW9uDQp3 aWxsIG5vdCB0b3VjaCB0aGUgcnVubmluZyBjb25maWcuDQo8L21hcnRpbj4NCg0KPGtlbnQ+DQpJ IGRvbid0IHRoaW5rIHRoZSBwcml2YXRlIGtleXMgY2FuIGJlIGNvbmZpZyBmYWxzZSwgc2luY2Ug dGhleSBhcmUgcmVmZXJlbmNlZCBieSBjb25maWcgdHJ1ZSBub2RlcyBpbiB0aGUgdGxzL3NzaC1z ZXJ2ZXIgbW9kdWxlcy4NCjwva2VudD4NCg0KPG1hcnRpbj4NCllvdSBjYW4gaGF2ZSBhIHJlcXVp cmUtaW5zdGFuY2UgZmFsc2UgbGVhZnJlZiB0byB0aGUgY29uZmlnIGZhbHNlIG9mDQprZXlzLCBh bmQgdGhlbiBkZXNjcmliZSB3aGF0IHdpbGwgaGFwcGVuIGlmIHNvbWUgc2VydmVyIGlzIGNvbmZp Z3VyZWQNCnRvIHBvaW50IHRvIGEgcHJpdmF0ZSBrZXkgdGhhdCBkb2Vzbid0IGV4aXN0Lg0KDQpU aGVyZSBhcmUgc3lzdGVtcyB3aXRoIHRhbXBlci1wcm9vZiBodyB0aGF0IHdvbid0IGFsbG93IHlv dSB0byBhY2Nlc3MNCnRoZSBrZXlzIHVubGVzcyBhIHBoeXNpY2FsIHRva2VuIGlzIHByZXNlbnQg KGUuZy4gYSBVU0Igc3RpY2spLiAgSW4NCnN1Y2ggc3lzdGVtcywgeW91IG1heSB2ZXJ5IHdlbGwg ZW5kIHVwIHdpdGggY29uZmlnIHRoYXQgcmVmZXJzIHRvIGENCmtleSB0aGF0IGlzbid0IGF2YWls YWJsZS4NCg0KUXVlc3Rpb24gMTogIElmIHRoZSBwcml2YXRlIGtleSBpcyBub3Qgc3RvcmVkIGlu IHNwZWNpYWwgSFcsIGRvIHdlDQogIHdhbnQgdG8gc3VwcG9ydCBiYWNrdXAvcmVzdG9yZSBvZiBz dWNoIGtleXM/DQoNCiAgSWYgdGhlIGFuc3dlciBpcyB5ZXM6DQogICAgICBVc2UgYSBjb25maWcg bGlzdCBhbmQgYSBzZXBhcmF0ZSAtc3RhdGUgbGlzdC4NCiAgICAgIE1ha2UgYWxsIHJlZmVyZW5j ZXMgcG9pbnQgdG8gdGhlIC1zdGF0ZSBsaXN0IChpbiBvcmRlciB0byBoYW5kbGUNCiAgICAgIFRQ TSBldGMpDQoNCiAgSWYgdGhlIGFuc3dlciBpcyBubzoNCiAgICAgIFVzZSBvbmx5IGEgY29uZmln IGZhbHNlIGxpc3QgYW5kIGRlZmluZSBhY3Rpb25zIHRvIG1hbmlwdWxhdGUNCiAgICAgIHRoZSBs aXN0Lg0KPC9tYXJ0aW4+DQoNCg0KUmVnYXJkaW5nIE1hcnRpbuKAmXMgcXVlc3Rpb24gIzEgKG5v dGU6IHRoZXJlIHdhc27igJl0IGEgcXVlc3Rpb24gIzIpLCBJIHRoaW5rIHRoYXQgdGhlIGFuc3dl ciBpcyDigJx5ZXMsIHdl4oCZZCBsaWtlIHRvIHN1cHBvcnQgYmFja3VwL3Jlc3RvcmUgb2YgcHJp dmF0ZSBrZXlz4oCdLiAgIElzIHRoaXMgdGhlIFdH4oCZcyBvcGluaW9uIGFzIHdlbGw/DQoNCg0K VGhhbmtzLA0KS2VudA0KDQoNCkZyb206IE5ldGNvbmYgPG5ldGNvbmYtYm91bmNlc0BpZXRmLm9y Zz4gb24gYmVoYWxmIG9mIE1haGVzaCBKZXRoYW5hbmRhbmkgPG1qZXRoYW5hbmRhbmlAZ21haWwu Y29tPg0KRGF0ZTogVGh1cnNkYXksIE1heSAyNiwgMjAxNiBhdCA4OjA2IFBNDQpUbzogIm5ldGNv bmZAaWV0Zi5vcmciIDxuZXRjb25mQGlldGYub3JnPg0KU3ViamVjdDogW05ldGNvbmZdIFNlbWkt Y29uZmlndXJhYmxlIGRlc2lnbiBpbiBzZXJ2ZXIgbW9kZWwgZHJhZnQNCg0KT25lIG9mIHRoZSBp c3N1ZXMgdGhhdCBLZW50IGJyb3VnaHQgdXAgaW4gdGhlIGludGVyaW0gbWVldGluZyB3YXMgdGhl IGlzc3VlIG9mIGNvbmZpZ3VyaW5nIHRoZSBwcml2YXRlIGtleS4gU29tZSBiYWNrZ3JvdW5kIG9u IHRoYXQgaXNzdWUgZGF0ZXMgYmFjayB0byB0aGUgdGhyZWFkIHRoYXQgc3RhcnRlZCB3aXRoIE1h cnRpbiByZXZpZXdpbmcgdGhlIGRvY3VtZW50IGFuZCBoZXJlIGlzIHdoYXQgaGUgYnJvdWdodCB1 cCBpbiB0aGF0IHJldmlldy4NCg0KDQpvICBTZWN0aW9uIDQuMQ0KDQoNCg0KICBJIHRoaW5rIHRo ZSAic2VtaS1jb25maWd1cmFibGUiIGRlc2lnbiBoYXMgc29tZSBpc3N1ZXMuICBZb3UgaGF2ZQ0K DQogIGRlZmluZWQgc29tZSBhY3Rpb25zIHRoYXQgYWN0dWFsbHkgbW9kaWZpZXMgdGhlIGNvbmZp Z3VyYXRpb24gb2YgdGhlDQoNCiAgc3lzdGVtLiAgSXQgaXMgbm90IGNsZWFyIHdoaWNoIGNvbmZp ZyBkYXRhc3RvcmUgaXMgbW9kaWZpZWQuDQoNCiAgUHJlc3VtYWJseSBydW5uaW5nLiAgSW50ZXJh Y3Rpb25zIHdpdGggbG9ja2luZyBhbmQgYWNjZXNzIGNvbnRyb2wNCg0KICBhcmUgbm90IGRlc2Ny aWJlZC4gIEFsc28sIHRoZSByZXN1bHRpbmcgY29uZmlndXJhdGlvbiBpcyBub3QNCg0KICBjb21w bGV0ZSAtIGkuZS4sIHlvdSBjYW5ub3QgZG8gPGNvcHktY29uZmlnPiB0byBzYXZlL3Jlc3RvcmUg YQ0KDQogIGJhY2t1cC4gIFRoaXMgaXMgZmluZSwgc2luY2UgeW91IHJlYWxseSBkb24ndCB3YW50 IHRvIGV4cG9zZSB0aGUNCg0KICBwcml2YXRlIGtleXMgaW4gdGhlIGNvbmZpZyBiYWNrdXAuICBC dXQgc29tZSBkaXNjdXNzaW9uIGlzIG5lZWRlZA0KDQogIGFyb3VuZCB0aGlzIHN1YmplY3QuICBX aGF0IGhhcHBlbnMgaWYgSSBnZW5lcmF0ZSBhIHByaXZhdGUga2V5IHdpdGgNCg0KICB5b3VyIGFj dGlvbiwgYmFja3VwIHRoYXQgY29uZmlnIGFuZCB0aGVuIHJlc3RvcmUgaXQ/ICBXaGF0IGhhcHBl bnMNCg0KICB3aXRoIGNvbmZpZyB0aGF0IGhhcyByZWZlcmVuY2VzIHRvIHN1Y2ggYSBrZXk/DQoN Cg0KDQogIE9uZSB3YXkgdG8gYXZvaWQgdGhhdCB0aGUgYWN0aW9ucyBtb2RpZnkgdGhlIGNvbmZp Z3VyYXRpb24gY291bGQgYmUNCg0KICB0byBtb3ZlIHRoZW0gaW50byB0aGUgcHJpdmF0ZS1rZXkg bGlzdC4gIE9uZSBkcmF3YmFjayBpcyB0aGF0IHR3bw0KDQogIG9wZXJhdGlvbnMgYXJlIG5lZWRl ZCBpbiBvcmRlciB0byBjcmVhdGUgYSAodXNhYmxlKSBrZXkgLSBmaXJzdA0KDQogIGNyZWF0ZSB0 aGUgY29uZmlnIGluIHJ1bm5pbmcsIHRoZW4gY2FsbCB0aGUgYWN0aW9uLg0KDQoNCg0KICBBbm90 aGVyIG9wdGlvbiBtaWdodCBiZSB0byBtb2RlbCB0aGUga2V5cyBhcyBjb25maWcgZmFsc2UgZGF0 YS4NCg0KICBUaGlzIGFsc28gc29sdmVzIHRoZSBwcm9ibGVtIHRoYXQgc29tZSBrZXlzIChpbiBU UE0gZm9yIGV4YW1wbGUpDQoNCiAgYXJlIG5vdCBkZWxldGFibGUuDQpUaGUgdHdvIHN1Z2dlc3Rp b25zIHRoYXQgS2VudCBicm91Z2h0IHRvIHRoZSBtZWV0aW5nIG9uIHdoZXRoZXIgdG8gbWFrZSBp dCBhIGxlYWYgb3IgYW4gYWN0aW9uLg0KDQpMZWFmcyBjYW4gYmUgYmFja2VkIHVwIG9yIHJlc3Rv cmVkLiBCdXQgcHJpdmF0ZS1rZXlzIGluIFRQTSBuZXZlciBsZWF2ZSB0aGUgc291cmNlLiBIb3cg ZG8gd2Ugc3VwcG9ydCBzcGVjaWFsIGhhcmR3YXJlIGxpa2UgVFBNPw0KDQpNYWtpbmcgaXQgYW4g YWN0aW9uIHJlcXVpcmVzIGNyZWF0aW9uIG9mIGEgZHVtbXkgcHJpdmF0ZSBrZXksIGFuZCB0aGVu IGNhbGwgYWN0aW9uIHRvIHBvcHVsYXRlIHRoZSBkYXRhIGluIGl0LCBhcyBNYXJ0aW4gc3RhdGVz IGFib3ZlLiBXaGF0IGhhcHBlbnMgaWYgdGhlIGtleSBpcyBub3QgYXZhaWxhYmxlIGJ1dCBpcyBy ZWZlcmVuY2VkIGJ5IHRoZSBzeXN0ZW0/DQoNCktlbnQsIGlzIHRoYXQgYSBmYWlyIHN1bW1hcnkg b2YgdGhlIGlzc3VlPw0KDQpMZXQgdGhlIGRpc2N1c3Npb24gYmVnaW4gOi0pDQoNCk1haGVzaCBK ZXRoYW5hbmRhbmkNCm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPG1haWx0bzptamV0aGFuYW5kYW5p QGdtYWlsLmNvbT4NCg0KDQoNCg== --_000_CF412B7FFCAB452C9AE08494B7E674F5junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <838A05402B508B438FF220B684CFB06B@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q291cmllcjt9DQpz cGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNh bGlicmkiPkl0IHNob3VsZCBiZSBub3RlZCB0aGF0IHRoZSBmb2xsb3dpbmcgZXhjaGFuZ2UgaGFw cGVuZWQgb24gQXByIDc8c3VwPnRoPC9zdXA+OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZs dDtrZW50Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPlllcywgdGhl IGFjdGlvbiBzdGF0ZW1lbnRzIGFyZSBpbnRlbmRlZCB0byB1cGRhdGUgdGhlIHJ1bm5pbmcgZGF0 YXN0b3JlLiZuYnNwOyBQcmVzdW1hYmx5IGJlY2F1c2UgdGhlIGFjdGlvbnMgYXJlIGVpdGhlciBn ZW5lcmF0aW5nIG9yIGxvYWRpbmcgYSBuZXcga2V5LCB0aGVyZSB3b3VsZCBub3QgYmUgYSByZWFs IHdvcmxkIGxvY2tpbmcNCiBpc3N1ZSwgYnV0IEkgY2FuIHNlZSBob3cgdGhpcyBtaWdodCBsZWFk IHRvIHVuZGVzaXJhYmxlIHJlc3VsdHMuJm5ic3A7IEFjY2VzcyBjb250cm9sIChOQUNNKSB3YXMg cmVtb3ZlZCB3aGVuIHdlIG1vdmVkIHRvIHRoZSBrZXljaGFpbiBiYXNlZCBhcHByb2FjaCwgYnV0 IHByZXN1bWFibHkgdGhlIHByaXZhdGUga2V5IHdvdWxkIG5lZWQgdG8gcHJvdGVjdGVkIGJ5IG5h Y206ZGVmYXVsdC1kZW55LWFsbC4mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkkg c2VlIHdoYXQgeW91J3JlIHNheWluZy4mbmJzcDsgWW91J3JlIHJpZ2h0IGFib3V0IHRoaXMgYnJl YWtpbmcgYmFja3VwIGFuZCByZXN0b3JlLiZuYnNwOyBUaGUgb25seSB3YXkgdG8gZml4IGl0IGlz IGZvciB0aGUgYmFja3VwICgmbHQ7Z2V0LWNvbmZpZyZndDspIHRvIGNvbnRhaW4gdGhlIHByaXZh dGUga2V5cy4mbmJzcDsgQnV0IG5vdGUgdGhhdCBzeXN0ZW1zDQogdXNpbmcgYSBUUE0gYWN0dWFs bHkgaGF2ZSBOTyBXQVkgdG8gZ2V0IHRoZSBwcml2YXRlIGtleSBvdXQgb2YgdGhlIFRQTSAtIG9u bHkgdGhlIFRQTSBpdHNlbGYgaGFzIGFjY2VzcyB0byB0aGUgcHJpdmF0ZSBrZXkuJm5ic3A7IFNv IGZvciB0aGVzZSBzeXN0ZW1zLCBiYWNrdXAvcmVzdG9yZSAoUk1BKSBpcyBpbXBvc3NpYmxlLCBl dmVuIHdpdGggcm9vdC1sZXZlbCBhY2Nlc3Mgb24gdGhlIGNvbW1hbmQgbGluZS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpIj5JJ20gbm90IHN1cmUgaWYgSSB1bmRlcnN0YW5kIHlvdXIgZmlyc3Qg b3B0aW9uLiZuYnNwOyBEbyB5b3UgbWVhbiB0aGUgY2xpZW50IHdvdWxkIGNyZWF0ZSBhIGR1bW15 IHByaXZhdGUga2V5IGVudHJ5IChhIHBsYWNlaG9sZGVyKSBhbmQgdGhlbiBjYWxsIGFuIGFjdGlv biB0byBwb3B1bGF0ZSB0aGUga2V5IHdpdGggZGF0YT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDYWxpYnJpIj4mbHQ7L2tlbnQmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jmx0 O21hcnRpbiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5ZZXMsIGJ1 dCBzaW5jZSB0aGUgcHJpdmF0ZSBrZXkgaXMgbm90IHBhcnQgb2YgdGhlIGNvbmZpZywgdGhlIGFj dGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPndpbGwgbm90IHRvdWNo IHRoZSBydW5uaW5nIGNvbmZpZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJp Ij4mbHQ7L21hcnRpbiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbHQ7a2VudCZndDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5JIGRvbid0IHRoaW5rIHRoZSBw cml2YXRlIGtleXMgY2FuIGJlIGNvbmZpZyBmYWxzZSwgc2luY2UgdGhleSBhcmUgcmVmZXJlbmNl ZCBieSBjb25maWcgdHJ1ZSBub2RlcyBpbiB0aGUgdGxzL3NzaC1zZXJ2ZXIgbW9kdWxlcy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbHQ7L2tlbnQmZ3Q7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6Q2FsaWJyaSI+Jmx0O21hcnRpbiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDYWxpYnJpIj5Zb3UgY2FuIGhhdmUgYSByZXF1aXJlLWluc3RhbmNlIGZhbHNlIGxlYWZy ZWYgdG8gdGhlIGNvbmZpZyBmYWxzZSBvZjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNh bGlicmkiPmtleXMsIGFuZCB0aGVuIGRlc2NyaWJlIHdoYXQgd2lsbCBoYXBwZW4gaWYgc29tZSBz ZXJ2ZXIgaXMgY29uZmlndXJlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmki PnRvIHBvaW50IHRvIGEgcHJpdmF0ZSBrZXkgdGhhdCBkb2Vzbid0IGV4aXN0LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OkNhbGlicmkiPlRoZXJlIGFyZSBzeXN0ZW1zIHdpdGggdGFtcGVyLXByb29mIGh3IHRo YXQgd29uJ3QgYWxsb3cgeW91IHRvIGFjY2VzczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OkNhbGlicmkiPnRoZSBrZXlzIHVubGVzcyBhIHBoeXNpY2FsIHRva2VuIGlzIHByZXNlbnQgKGUu Zy4gYSBVU0Igc3RpY2spLiZuYnNwOyBJbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNh bGlicmkiPnN1Y2ggc3lzdGVtcywgeW91IG1heSB2ZXJ5IHdlbGwgZW5kIHVwIHdpdGggY29uZmln IHRoYXQgcmVmZXJzIHRvIGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5r ZXkgdGhhdCBpc24ndCBhdmFpbGFibGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2Fs aWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+UXVlc3Rp b24gMTombmJzcDsgSWYgdGhlIHByaXZhdGUga2V5IGlzIG5vdCBzdG9yZWQgaW4gc3BlY2lhbCBI VywgZG8gd2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsgd2Fu dCB0byBzdXBwb3J0IGJhY2t1cC9yZXN0b3JlIG9mIHN1Y2gga2V5cz88bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDYWxpYnJpIj4mbmJzcDsgSWYgdGhlIGFuc3dlciBpcyB5ZXM6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFVzZSBh IGNvbmZpZyBsaXN0IGFuZCBhIHNlcGFyYXRlIC1zdGF0ZSBsaXN0LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBNYWtl IGFsbCByZWZlcmVuY2VzIHBvaW50IHRvIHRoZSAtc3RhdGUgbGlzdCAoaW4gb3JkZXIgdG8gaGFu ZGxlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IFRQTSBldGMpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2Fs aWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7 IElmIHRoZSBhbnN3ZXIgaXMgbm86PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJy aSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFVzZSBvbmx5IGEgY29uZmlnIGZhbHNl IGxpc3QgYW5kIGRlZmluZSBhY3Rpb25zIHRvIG1hbmlwdWxhdGU8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlIGxp c3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jmx0Oy9tYXJ0aW4mZ3Q7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6Q2FsaWJyaSI+UmVnYXJkaW5nIE1hcnRpbuKAmXMgcXVlc3Rpb24gIzEgKG5vdGU6IHRo ZXJlIHdhc27igJl0IGEgcXVlc3Rpb24gIzIpLCBJIHRoaW5rIHRoYXQgdGhlIGFuc3dlciBpcyDi gJx5ZXMsIHdl4oCZZCBsaWtlIHRvIHN1cHBvcnQgYmFja3VwL3Jlc3RvcmUgb2YgcHJpdmF0ZSBr ZXlz4oCdLiZuYnNwOyZuYnNwOyBJcyB0aGlzIHRoZSBXR+KAmXMgb3BpbmlvbiBhcyB3ZWxsPzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OkNhbGlicmkiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJp Ij5LZW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bh bj4NCjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+TmV0 Y29uZiAmbHQ7bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgTWFoZXNo IEpldGhhbmFuZGFuaSAmbHQ7bWpldGhhbmFuZGFuaUBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+RGF0 ZTogPC9iPlRodXJzZGF5LCBNYXkgMjYsIDIwMTYgYXQgODowNiBQTTxicj4NCjxiPlRvOiA8L2I+ JnF1b3Q7bmV0Y29uZkBpZXRmLm9yZyZxdW90OyAmbHQ7bmV0Y29uZkBpZXRmLm9yZyZndDs8YnI+ DQo8Yj5TdWJqZWN0OiA8L2I+W05ldGNvbmZdIFNlbWktY29uZmlndXJhYmxlIGRlc2lnbiBpbiBz ZXJ2ZXIgbW9kZWwgZHJhZnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbmUgb2YgdGhlIGlzc3VlcyB0aGF0IEtlbnQg YnJvdWdodCB1cCBpbiB0aGUgaW50ZXJpbSBtZWV0aW5nIHdhcyB0aGUgaXNzdWUgb2YgY29uZmln dXJpbmcgdGhlIHByaXZhdGUga2V5LiBTb21lIGJhY2tncm91bmQgb24gdGhhdCBpc3N1ZSBkYXRl cyBiYWNrIHRvIHRoZSB0aHJlYWQgdGhhdCBzdGFydGVkIHdpdGggTWFydGluIHJldmlld2luZyB0 aGUgZG9jdW1lbnQgYW5kIGhlcmUgaXMgd2hhdCBoZSBicm91Z2h0DQogdXAgaW4gdGhhdCByZXZp ZXcuIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWxp Z2F0dXJlczogbm9ybWFsO2ZvbnQtdmFyaWFudC1wb3NpdGlvbjogbm9ybWFsO2ZvbnQtdmFyaWFu dC1udW1lcmljOiBub3JtYWw7Zm9udC12YXJpYW50LWFsdGVybmF0ZXM6IG5vcm1hbDtmb250LXZh cmlhbnQtZWFzdC1hc2lhbjogbm9ybWFsO3dpZG93czogMSI+byZuYnNwOyBTZWN0aW9uIDQuMTxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw OyBJIHRoaW5rIHRoZSAmcXVvdDtzZW1pLWNvbmZpZ3VyYWJsZSZxdW90OyBkZXNpZ24gaGFzIHNv bWUgaXNzdWVzLiZuYnNwOyBZb3UgaGF2ZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyBk ZWZpbmVkIHNvbWUgYWN0aW9ucyB0aGF0IGFjdHVhbGx5IG1vZGlmaWVzIHRoZSBjb25maWd1cmF0 aW9uIG9mIHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyBzeXN0ZW0uJm5ic3A7IEl0 IGlzIG5vdCBjbGVhciB3aGljaCBjb25maWcgZGF0YXN0b3JlIGlzIG1vZGlmaWVkLjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyBQcmVzdW1hYmx5IHJ1bm5pbmcuJm5ic3A7IEludGVyYWN0 aW9ucyB3aXRoIGxvY2tpbmcgYW5kIGFjY2VzcyBjb250cm9sPG86cD48L286cD48L3ByZT4NCjxw cmU+Jm5ic3A7IGFyZSBub3QgZGVzY3JpYmVkLiZuYnNwOyBBbHNvLCB0aGUgcmVzdWx0aW5nIGNv bmZpZ3VyYXRpb24gaXMgbm90PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7IGNvbXBsZXRl IC0gaS5lLiwgeW91IGNhbm5vdCBkbyAmbHQ7Y29weS1jb25maWcmZ3Q7IHRvIHNhdmUvcmVzdG9y ZSBhPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7IGJhY2t1cC4mbmJzcDsgVGhpcyBpcyBm aW5lLCBzaW5jZSB5b3UgcmVhbGx5IGRvbid0IHdhbnQgdG8gZXhwb3NlIHRoZTxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPiZuYnNwOyBwcml2YXRlIGtleXMgaW4gdGhlIGNvbmZpZyBiYWNrdXAuJm5i c3A7IEJ1dCBzb21lIGRpc2N1c3Npb24gaXMgbmVlZGVkPG86cD48L286cD48L3ByZT4NCjxwcmU+ Jm5ic3A7IGFyb3VuZCB0aGlzIHN1YmplY3QuJm5ic3A7IFdoYXQgaGFwcGVucyBpZiBJIGdlbmVy YXRlIGEgcHJpdmF0ZSBrZXkgd2l0aDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyB5b3Vy IGFjdGlvbiwgYmFja3VwIHRoYXQgY29uZmlnIGFuZCB0aGVuIHJlc3RvcmUgaXQ/Jm5ic3A7IFdo YXQgaGFwcGVuczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyB3aXRoIGNvbmZpZyB0aGF0 IGhhcyByZWZlcmVuY2VzIHRvIHN1Y2ggYSBrZXk/PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86 cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7IE9uZSB3YXkgdG8gYXZvaWQgdGhhdCB0 aGUgYWN0aW9ucyBtb2RpZnkgdGhlIGNvbmZpZ3VyYXRpb24gY291bGQgYmU8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT4mbmJzcDsgdG8gbW92ZSB0aGVtIGludG8gdGhlIHByaXZhdGUta2V5IGxpc3Qu Jm5ic3A7IE9uZSBkcmF3YmFjayBpcyB0aGF0IHR3bzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZu YnNwOyBvcGVyYXRpb25zIGFyZSBuZWVkZWQgaW4gb3JkZXIgdG8gY3JlYXRlIGEgKHVzYWJsZSkg a2V5IC0gZmlyc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsgY3JlYXRlIHRoZSBjb25m aWcgaW4gcnVubmluZywgdGhlbiBjYWxsIHRoZSBhY3Rpb24uPG86cD48L286cD48L3ByZT4NCjxw cmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7IEFub3RoZXIgb3B0aW9uIG1p Z2h0IGJlIHRvIG1vZGVsIHRoZSBrZXlzIGFzIGNvbmZpZyBmYWxzZSBkYXRhLjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPiZuYnNwOyBUaGlzIGFsc28gc29sdmVzIHRoZSBwcm9ibGVtIHRoYXQgc29t ZSBrZXlzIChpbiBUUE0gZm9yIGV4YW1wbGUpPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7 IGFyZSBub3QgZGVsZXRhYmxlLjxvOnA+PC9vOnA+PC9wcmU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhlIHR3byBzdWdnZXN0aW9ucyB0aGF0IEtlbnQgYnJvdWdodCB0byB0aGUgbWVl dGluZyBvbiB3aGV0aGVyIHRvIG1ha2UgaXQgYSBsZWFmIG9yIGFuIGFjdGlvbi4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TGVhZnMg Y2FuIGJlIGJhY2tlZCB1cCBvciByZXN0b3JlZC4gQnV0IHByaXZhdGUta2V5cyBpbiBUUE0gbmV2 ZXIgbGVhdmUgdGhlIHNvdXJjZS4gSG93IGRvIHdlIHN1cHBvcnQgc3BlY2lhbCBoYXJkd2FyZSBs aWtlIFRQTT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+TWFraW5nIGl0IGFuIGFjdGlvbiByZXF1aXJlcyBjcmVhdGlvbiBvZiBhIGR1bW15IHBy aXZhdGUga2V5LCBhbmQgdGhlbiBjYWxsIGFjdGlvbiB0byBwb3B1bGF0ZSB0aGUgZGF0YSBpbiBp dCwgYXMgTWFydGluIHN0YXRlcyBhYm92ZS4gV2hhdCBoYXBwZW5zIGlmIHRoZSBrZXkgaXMgbm90 IGF2YWlsYWJsZSBidXQgaXMgcmVmZXJlbmNlZCBieSB0aGUgc3lzdGVtPzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5LZW50LCBpcyB0aGF0IGEg ZmFpciBzdW1tYXJ5IG9mIHRoZSBpc3N1ZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TGV0IHRoZSBkaXNjdXNzaW9uIGJlZ2luIDotKTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1haGVzaCBK ZXRoYW5hbmRhbmk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxhIGhyZWY9Im1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbSI+bWpldGhhbmFu ZGFuaUBnbWFpbC5jb208L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CF412B7FFCAB452C9AE08494B7E674F5junipernet_-- From nobody Fri May 27 10:46:31 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B75DC12D7B1 for ; Fri, 27 May 2016 10:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76c21BO9lTFx for ; Fri, 27 May 2016 10:46:28 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1F8712D7B3 for ; Fri, 27 May 2016 10:46:27 -0700 (PDT) Received: by mail-pa0-x234.google.com with SMTP id eu11so32893187pad.3 for ; Fri, 27 May 2016 10:46:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=IAz5VnhHPPwjgyPMDSfhBxCwPusT2csiTZH8ROj6LIk=; b=Q147h3ISIF3h8gx+v0aSgA/FoXFriEP06DFP3505KQul8OqHTVl+MNh99oSCaxrIdi d/L/rai58wk7tw4AA5nS3xsXGeiSCqLCQ+vFo8hdkUuGsEB0cM1G5p7JsWdSwwLhkGRV n5/ez8ct02SNl0IuXozQpLZtq7yk91INmmzvc5+1Dl9ko5GcP/Glybx0C6SVptmz4MV2 yxzIR260k1Zd3nr+LPUOavKGGJ2KaKsySDtPNIU8iWMLXUnUtF72yA5xHvHEKQu3ihiz DS0iAdncquY405WMb9jC04WyZz4wpCSgtl3KKaKEGLx/KayJQzPiWWrjElz5WH7CI0Jb nrEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=IAz5VnhHPPwjgyPMDSfhBxCwPusT2csiTZH8ROj6LIk=; b=P1VJJOgGG3/mDFsxP1iwQ2V2QcNNA5yrR8qkcqRU+kaNv/KVgsXuptL2/ytXRiWa0C qd8gSxf2gLkF7evZb0B6ayTrlAGsakz5k2WOXaksW50uwpPq2gwckciDKC/qvhVec6Fx sosgT2ul+mfuChhNkNjWWOGoZ/Hta20oKWDB+MEPDPcDVQ33CbOP09A23ng15Uaqv4JH YnVzATJuTIDuRXg3qoVdT51zf+svR+2yUYytnnLihaNTrPzvBPAk1PDLJ5BPsMDwaQhc /Ar0yzqHUie/XF60nhPQktJoVdwB1VfCDuty7cNZ9BlTrV62xaepR1Fh3jYcTOYtZuZi OhfA== X-Gm-Message-State: ALyK8tINaf5JcxfZ3yKAeZdca3TTwlCYA9ADi2NWWqm8KElzFcDbB4sEhmAawfSd4MDOVA== X-Received: by 10.66.87.198 with SMTP id ba6mr24647170pab.151.1464371187153; Fri, 27 May 2016 10:46:27 -0700 (PDT) Received: from ?IPv6:2001:420:c0c8:1005::56f? ([2001:420:c0c8:1005::56f]) by smtp.gmail.com with ESMTPSA id 19sm15169735pfu.83.2016.05.27.10.46.25 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 May 2016 10:46:25 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_3D4B5825-7998-428D-B0E2-CAEA085522F0" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mahesh Jethanandani In-Reply-To: Date: Fri, 27 May 2016 10:46:24 -0700 Message-Id: References: To: Kent Watsen X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Netconf Subject: Re: [Netconf] Semi-configurable design in server model draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 17:46:31 -0000 --Apple-Mail=_3D4B5825-7998-428D-B0E2-CAEA085522F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [Chair hat off] > On May 27, 2016, at 10:31 AM, Kent Watsen wrote: >=20 > It should be noted that the following exchange happened on Apr 7th: > =20 > > Yes, the action statements are intended to update the running = datastore. Presumably because the actions are either generating or = loading a new key, there would not be a real world locking issue, but I = can see how this might lead to undesirable results. Access control = (NACM) was removed when we moved to the keychain based approach, but = presumably the private key would need to protected by = nacm:default-deny-all.=20 > =20 > I see what you're saying. You're right about this breaking backup and = restore. The only way to fix it is for the backup () to = contain the private keys. But note that systems using a TPM actually = have NO WAY to get the private key out of the TPM - only the TPM itself = has access to the private key. So for these systems, backup/restore = (RMA) is impossible, even with root-level access on the command line. > =20 > I'm not sure if I understand your first option. Do you mean the = client would create a dummy private key entry (a placeholder) and then = call an action to populate the key with data? > > =20 > > Yes, but since the private key is not part of the config, the action > will not touch the running config. > > =20 > > I don't think the private keys can be config false, since they are = referenced by config true nodes in the tls/ssh-server modules. > > =20 > > You can have a require-instance false leafref to the config false of > keys, and then describe what will happen if some server is configured > to point to a private key that doesn't exist. > =20 > There are systems with tamper-proof hw that won't allow you to access > the keys unless a physical token is present (e.g. a USB stick). In > such systems, you may very well end up with config that refers to a > key that isn't available. > =20 > Question 1: If the private key is not stored in special HW, do we > want to support backup/restore of such keys? > =20 > If the answer is yes: > Use a config list and a separate -state list. > Make all references point to the -state list (in order to handle > TPM etc) > =20 > If the answer is no: > Use only a config false list and define actions to manipulate > the list. > > =20 > =20 > Regarding Martin=E2=80=99s question #1 (note: there wasn=E2=80=99t a = question #2), I think that the answer is =E2=80=9Cyes, we=E2=80=99d like = to support backup/restore of private keys=E2=80=9D. Is this the WG=E2=80= =99s opinion as well? My personal opinion is yes also. But I am a little confused here. If TPM = does not allow for keys to be exported, what would be reflected in the = -state list? And if a config true node refers to this config false node, = what are we =E2=80=9Cdescribing=E2=80=9D that will happen? Is there a = when statement? > =20 > =20 > Thanks, > Kent > =20 > =20 > From: Netconf on behalf of Mahesh = Jethanandani > Date: Thursday, May 26, 2016 at 8:06 PM > To: "netconf@ietf.org" > Subject: [Netconf] Semi-configurable design in server model draft > =20 > One of the issues that Kent brought up in the interim meeting was the = issue of configuring the private key. Some background on that issue = dates back to the thread that started with Martin reviewing the document = and here is what he brought up in that review.=20 > =20 > o Section 4.1 > =20 > I think the "semi-configurable" design has some issues. You have > defined some actions that actually modifies the configuration of the > system. It is not clear which config datastore is modified. > Presumably running. Interactions with locking and access control > are not described. Also, the resulting configuration is not > complete - i.e., you cannot do to save/restore a > backup. This is fine, since you really don't want to expose the > private keys in the config backup. But some discussion is needed > around this subject. What happens if I generate a private key with > your action, backup that config and then restore it? What happens > with config that has references to such a key? > =20 > One way to avoid that the actions modify the configuration could be > to move them into the private-key list. One drawback is that two > operations are needed in order to create a (usable) key - first > create the config in running, then call the action. > =20 > Another option might be to model the keys as config false data. > This also solves the problem that some keys (in TPM for example) > are not deletable. > The two suggestions that Kent brought to the meeting on whether to = make it a leaf or an action.=20 > =20 > Leafs can be backed up or restored. But private-keys in TPM never = leave the source. How do we support special hardware like TPM? > =20 > Making it an action requires creation of a dummy private key, and then = call action to populate the data in it, as Martin states above. What = happens if the key is not available but is referenced by the system? > =20 > Kent, is that a fair summary of the issue? > =20 > Let the discussion begin :-) > =20 > Mahesh Jethanandani > mjethanandani@gmail.com > =20 > =20 > =20 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_3D4B5825-7998-428D-B0E2-CAEA085522F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 [Chair hat off]

On May 27, 2016, at 10:31 AM, = Kent Watsen <kwatsen@juniper.net> wrote:

It should be noted that the following exchange happened on = Apr 7th:
 
<kent>
Yes, the action statements are intended to update = the running datastore.  Presumably because the actions are either = generating or loading a new key, there would not be a real world locking = issue, but I can see how this might lead to undesirable results.  = Access control (NACM) was removed when we moved to the keychain based = approach, but presumably the private key would need to protected by = nacm:default-deny-all. 
 
I see what you're saying.  You're right about = this breaking backup and restore.  The only way to fix it is for = the backup (<get-config>) to contain the private keys.  But = note that systems using a TPM actually have NO WAY to get the private = key out of the TPM - only the TPM itself has access to the private = key.  So for these systems, backup/restore (RMA) is impossible, = even with root-level access on the command line.
 
I'm not sure if I understand your first option.  Do you = mean the client would create a dummy private key entry (a placeholder) = and then call an action to populate the key with data?
</kent>
 
<martin>
Yes, but since the private key is not part of the = config, the action
will not touch the running config.
</martin>
 
<kent>
I don't think the private keys can be config false, = since they are referenced by config true nodes in the tls/ssh-server = modules.
</kent>
 
<martin>
You can have a require-instance false leafref to = the config false of
keys, and then describe what will happen if some = server is configured
to point to a private key that doesn't exist.
 
There are systems with tamper-proof hw that won't allow you = to access
the keys unless a physical token is present (e.g. a USB = stick).  In
such systems, you may very well end up with config that = refers to a
key that isn't available.
 
Question 1:  If the private key is not stored in special = HW, do we
  want to support backup/restore of such keys?
 
  If the answer is yes:
      Use a config list and a = separate -state list.
      Make all references = point to the -state list (in order to handle
      TPM etc)
 
  If the answer is no:
      Use only a config false list = and define actions to manipulate
      the list.
</martin>
 
 
Regarding Martin=E2=80=99s question #1 (note: there = wasn=E2=80=99t a question #2), I think that the answer is =E2=80=9Cyes, = we=E2=80=99d like to support backup/restore of private = keys=E2=80=9D.   Is this the WG=E2=80=99s opinion as = well?

My = personal opinion is yes also. But I am a little confused here. If TPM = does not allow for keys to be exported, what would be reflected in the = -state list? And if a config true node refers to this config false node, = what are we =E2=80=9Cdescribing=E2=80=9D that will happen? Is there a = when statement?

 
 
Thanks,
Kent
 
 
From: Netconf <netconf-bounces@ietf.org> on behalf of Mahesh = Jethanandani <mjethanandani@gmail.com>
Date: Thursday, May 26, 2016 = at 8:06 PM
To: "netconf@ietf.org" <netconf@ietf.org>
Subject: [Netconf] = Semi-configurable design in server model draft
 
One of the issues that Kent = brought up in the interim meeting was the issue of configuring the = private key. Some background on that issue dates back to the thread that = started with Martin reviewing the document and here is what he brought = up in that review. 
 
o  Section =
4.1
 
  I think =
the "semi-configurable" design has some issues.  You have
  defined =
some actions that actually modifies the configuration of the
  =
system.  It is not clear which config datastore is modified.
  =
Presumably running.  Interactions with locking and access =
control
  =
are not described.  Also, the resulting configuration is not
  complete =
- i.e., you cannot do <copy-config> to save/restore a
  =
backup.  This is fine, since you really don't want to expose =
the
  private =
keys in the config backup.  But some discussion is needed
  around =
this subject.  What happens if I generate a private key with
  your =
action, backup that config and then restore it?  What happens
  with =
config that has references to such a key?
 
  One way to avoid that the actions =
modify the configuration could be
  to move them into the private-key =
list.  One drawback is that two
  operations are needed in order to =
create a (usable) key - first
  create the config in running, then =
call the action.
 
  Another option might be to model the keys as config =
false data.
  =
This also solves the problem that some keys (in TPM for example)
  are not =
deletable.
The two suggestions that Kent brought to the = meeting on whether to make it a leaf or an action. 
 
Leafs can be backed up or restored. But = private-keys in TPM never leave the source. How do we support special = hardware like TPM?
 
Making it an action requires = creation of a dummy private key, and then call action to populate the = data in it, as Martin states above. What happens if the key is not = available but is referenced by the system?
 
Kent, is that a fair summary of the issue?
 
Let the discussion begin :-)
 
Mahesh Jethanandani
 
 
 

Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_3D4B5825-7998-428D-B0E2-CAEA085522F0-- From nobody Sun May 29 02:07:29 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 034E012D1C7 for ; Sun, 29 May 2016 02:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdE4QPG1LQ2j for ; Sun, 29 May 2016 02:07:26 -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 B8F3512D0E1 for ; Sun, 29 May 2016 02:07:25 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 317198DB; Sun, 29 May 2016 11:07:23 +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 pDetiVEUNNnq; Sun, 29 May 2016 11:07: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; Sun, 29 May 2016 11:07:22 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6C9DC20050; Sun, 29 May 2016 11:07:22 +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 p4NO-7byIT2t; Sun, 29 May 2016 11:07:21 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 59E8C2004E; Sun, 29 May 2016 11:07:21 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0B6A13AF9E9C; Sun, 29 May 2016 11:07:19 +0200 (CEST) Date: Sun, 29 May 2016 11:07:19 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20160529090719.GB18064@elstar.local> Mail-Followup-To: Andy Bierman , Kent Watsen , "netconf@ietf.org" References: <20160429081529.GA26297@elstar.local> <20160429.102116.1627845264494578220.mbj@tail-f.com> <00aa01d1a209$2d165a20$4001a8c0@gateway.2wire.net> <9E3A9643-2348-42AA-A6B0-6FB9F13D1A29@juniper.net> <022801d1a456$c20e12e0$4001a8c0@gateway.2wire.net> <92BAF631-804E-45AD-89A3-48059966B2F4@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Confirming the decision to split the server-model draft into several drafts. X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2016 09:07:29 -0000 On Fri, May 27, 2016 at 10:29:05AM -0700, Andy Bierman wrote: > Hi, > > #3 is better to decouple the normative references and instability as each > protocol changes over time. > Yes, this is why I also favored #3 during the call. If we go with #2, I am reasonably sure we will end up with #3 over time when protocol updates are being made. /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 May 30 01:17:14 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF0412D196 for ; Mon, 30 May 2016 01:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GW_FEdMFbnFr for ; Mon, 30 May 2016 01:17:10 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9927312D17D for ; Mon, 30 May 2016 01:17:10 -0700 (PDT) Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id 938111AE0483; Mon, 30 May 2016 10:17:09 +0200 (CEST) Date: Mon, 30 May 2016 10:17:30 +0200 (CEST) Message-Id: <20160530.101730.2119371451725076352.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20160529090719.GB18064@elstar.local> References: <20160529090719.GB18064@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] Confirming the decision to split the server-model draft into several drafts. X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 08:17:12 -0000 Juergen Schoenwaelder wrote: > On Fri, May 27, 2016 at 10:29:05AM -0700, Andy Bierman wrote: > > Hi, > > > > #3 is better to decouple the normative references and instability as each > > protocol changes over time. > > > > Yes, this is why I also favored #3 during the call. If we go with #2, > I am reasonably sure we will end up with #3 over time when protocol > updates are being made. I'm fine with #3. #2 is also ok. The most important part is to have the correct *modules*. Which document they go into is imo less important. /martin From nobody Mon May 30 01:26:06 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A844E12D18B for ; Mon, 30 May 2016 01:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8mA55Y4dih5c for ; Mon, 30 May 2016 01:26:03 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 19DFC12D18A for ; Mon, 30 May 2016 01:26:02 -0700 (PDT) Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id E68941AE048A; Mon, 30 May 2016 10:26:00 +0200 (CEST) Date: Mon, 30 May 2016 10:26:22 +0200 (CEST) Message-Id: <20160530.102622.281213031392882639.mbj@tail-f.com> To: mjethanandani@gmail.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=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] Semi-configurable design in server model draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 08:26:04 -0000 TWFoZXNoIEpldGhhbmFuZGFuaSA8bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+IHdyb3RlOg0KPiBb Q2hhaXIgaGF0IG9mZl0NCj4gDQo+ID4gT24gTWF5IDI3LCAyMDE2LCBhdCAxMDozMSBBTSwgS2Vu dCBXYXRzZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ+IHdyb3RlOg0KPiA+IA0KPiA+IEl0IHNob3Vs ZCBiZSBub3RlZCB0aGF0IHRoZSBmb2xsb3dpbmcgZXhjaGFuZ2UgaGFwcGVuZWQgb24gQXByIDd0 aDoNCj4gPiAgDQo+ID4gPGtlbnQ+DQo+ID4gWWVzLCB0aGUgYWN0aW9uIHN0YXRlbWVudHMgYXJl IGludGVuZGVkIHRvIHVwZGF0ZSB0aGUgcnVubmluZw0KPiA+IGRhdGFzdG9yZS4gIFByZXN1bWFi bHkgYmVjYXVzZSB0aGUgYWN0aW9ucyBhcmUgZWl0aGVyIGdlbmVyYXRpbmcgb3INCj4gPiBsb2Fk aW5nIGEgbmV3IGtleSwgdGhlcmUgd291bGQgbm90IGJlIGEgcmVhbCB3b3JsZCBsb2NraW5nIGlz c3VlLCBidXQNCj4gPiBJIGNhbiBzZWUgaG93IHRoaXMgbWlnaHQgbGVhZCB0byB1bmRlc2lyYWJs ZSByZXN1bHRzLiAgQWNjZXNzIGNvbnRyb2wNCj4gPiAoTkFDTSkgd2FzIHJlbW92ZWQgd2hlbiB3 ZSBtb3ZlZCB0byB0aGUga2V5Y2hhaW4gYmFzZWQgYXBwcm9hY2gsIGJ1dA0KPiA+IHByZXN1bWFi bHkgdGhlIHByaXZhdGUga2V5IHdvdWxkIG5lZWQgdG8gcHJvdGVjdGVkIGJ5DQo+ID4gbmFjbTpk ZWZhdWx0LWRlbnktYWxsLg0KPiA+ICANCj4gPiBJIHNlZSB3aGF0IHlvdSdyZSBzYXlpbmcuICBZ b3UncmUgcmlnaHQgYWJvdXQgdGhpcyBicmVha2luZyBiYWNrdXAgYW5kDQo+ID4gcmVzdG9yZS4g IFRoZSBvbmx5IHdheSB0byBmaXggaXQgaXMgZm9yIHRoZSBiYWNrdXAgKDxnZXQtY29uZmlnPikg dG8NCj4gPiBjb250YWluIHRoZSBwcml2YXRlIGtleXMuICBCdXQgbm90ZSB0aGF0IHN5c3RlbXMg dXNpbmcgYSBUUE0gYWN0dWFsbHkNCj4gPiBoYXZlIE5PIFdBWSB0byBnZXQgdGhlIHByaXZhdGUg a2V5IG91dCBvZiB0aGUgVFBNIC0gb25seSB0aGUgVFBNDQo+ID4gaXRzZWxmIGhhcyBhY2Nlc3Mg dG8gdGhlIHByaXZhdGUga2V5LiAgU28gZm9yIHRoZXNlIHN5c3RlbXMsDQo+ID4gYmFja3VwL3Jl c3RvcmUgKFJNQSkgaXMgaW1wb3NzaWJsZSwgZXZlbiB3aXRoIHJvb3QtbGV2ZWwgYWNjZXNzIG9u IHRoZQ0KPiA+IGNvbW1hbmQgbGluZS4NCj4gPiAgDQo+ID4gSSdtIG5vdCBzdXJlIGlmIEkgdW5k ZXJzdGFuZCB5b3VyIGZpcnN0IG9wdGlvbi4gIERvIHlvdSBtZWFuIHRoZQ0KPiA+IGNsaWVudCB3 b3VsZCBjcmVhdGUgYSBkdW1teSBwcml2YXRlIGtleSBlbnRyeSAoYSBwbGFjZWhvbGRlcikgYW5k IHRoZW4NCj4gPiBjYWxsIGFuIGFjdGlvbiB0byBwb3B1bGF0ZSB0aGUga2V5IHdpdGggZGF0YT8N Cj4gPiA8L2tlbnQ+DQo+ID4gIA0KPiA+IDxtYXJ0aW4+DQo+ID4gWWVzLCBidXQgc2luY2UgdGhl IHByaXZhdGUga2V5IGlzIG5vdCBwYXJ0IG9mIHRoZSBjb25maWcsIHRoZSBhY3Rpb24NCj4gPiB3 aWxsIG5vdCB0b3VjaCB0aGUgcnVubmluZyBjb25maWcuDQo+ID4gPC9tYXJ0aW4+DQo+ID4gIA0K PiA+IDxrZW50Pg0KPiA+IEkgZG9uJ3QgdGhpbmsgdGhlIHByaXZhdGUga2V5cyBjYW4gYmUgY29u ZmlnIGZhbHNlLCBzaW5jZSB0aGV5IGFyZQ0KPiA+IHJlZmVyZW5jZWQgYnkgY29uZmlnIHRydWUg bm9kZXMgaW4gdGhlIHRscy9zc2gtc2VydmVyIG1vZHVsZXMuDQo+ID4gPC9rZW50Pg0KPiA+ICAN Cj4gPiA8bWFydGluPg0KPiA+IFlvdSBjYW4gaGF2ZSBhIHJlcXVpcmUtaW5zdGFuY2UgZmFsc2Ug bGVhZnJlZiB0byB0aGUgY29uZmlnIGZhbHNlIG9mDQo+ID4ga2V5cywgYW5kIHRoZW4gZGVzY3Jp YmUgd2hhdCB3aWxsIGhhcHBlbiBpZiBzb21lIHNlcnZlciBpcyBjb25maWd1cmVkDQo+ID4gdG8g cG9pbnQgdG8gYSBwcml2YXRlIGtleSB0aGF0IGRvZXNuJ3QgZXhpc3QuDQo+ID4gIA0KPiA+IFRo ZXJlIGFyZSBzeXN0ZW1zIHdpdGggdGFtcGVyLXByb29mIGh3IHRoYXQgd29uJ3QgYWxsb3cgeW91 IHRvIGFjY2Vzcw0KPiA+IHRoZSBrZXlzIHVubGVzcyBhIHBoeXNpY2FsIHRva2VuIGlzIHByZXNl bnQgKGUuZy4gYSBVU0Igc3RpY2spLiAgSW4NCj4gPiBzdWNoIHN5c3RlbXMsIHlvdSBtYXkgdmVy eSB3ZWxsIGVuZCB1cCB3aXRoIGNvbmZpZyB0aGF0IHJlZmVycyB0byBhDQo+ID4ga2V5IHRoYXQg aXNuJ3QgYXZhaWxhYmxlLg0KPiA+ICANCj4gPiBRdWVzdGlvbiAxOiAgSWYgdGhlIHByaXZhdGUg a2V5IGlzIG5vdCBzdG9yZWQgaW4gc3BlY2lhbCBIVywgZG8gd2UNCj4gPiAgIHdhbnQgdG8gc3Vw cG9ydCBiYWNrdXAvcmVzdG9yZSBvZiBzdWNoIGtleXM/DQo+ID4gIA0KPiA+ICAgSWYgdGhlIGFu c3dlciBpcyB5ZXM6DQo+ID4gICAgICAgVXNlIGEgY29uZmlnIGxpc3QgYW5kIGEgc2VwYXJhdGUg LXN0YXRlIGxpc3QuDQo+ID4gICAgICAgTWFrZSBhbGwgcmVmZXJlbmNlcyBwb2ludCB0byB0aGUg LXN0YXRlIGxpc3QgKGluIG9yZGVyIHRvIGhhbmRsZQ0KPiA+ICAgICAgIFRQTSBldGMpDQo+ID4g IA0KPiA+ICAgSWYgdGhlIGFuc3dlciBpcyBubzoNCj4gPiAgICAgICBVc2Ugb25seSBhIGNvbmZp ZyBmYWxzZSBsaXN0IGFuZCBkZWZpbmUgYWN0aW9ucyB0byBtYW5pcHVsYXRlDQo+ID4gICAgICAg dGhlIGxpc3QuDQo+ID4gPC9tYXJ0aW4+DQo+ID4gIA0KPiA+ICANCj4gPiBSZWdhcmRpbmcgTWFy dGlu4oCZcyBxdWVzdGlvbiAjMSAobm90ZTogdGhlcmUgd2FzbuKAmXQgYSBxdWVzdGlvbiAjMiks IEkNCj4gPiB0aGluayB0aGF0IHRoZSBhbnN3ZXIgaXMg4oCceWVzLCB3ZeKAmWQgbGlrZSB0byBz dXBwb3J0IGJhY2t1cC9yZXN0b3JlIG9mDQo+ID4gcHJpdmF0ZSBrZXlz4oCdLiAgSXMgdGhpcyB0 aGUgV0figJlzIG9waW5pb24gYXMgd2VsbD8NCj4gDQo+IE15IHBlcnNvbmFsIG9waW5pb24gaXMg eWVzIGFsc28uIEJ1dCBJIGFtIGEgbGl0dGxlIGNvbmZ1c2VkIGhlcmUuIElmDQo+IFRQTSBkb2Vz IG5vdCBhbGxvdyBmb3Iga2V5cyB0byBiZSBleHBvcnRlZCwgd2hhdCB3b3VsZCBiZSByZWZsZWN0 ZWQgaW4NCj4gdGhlIC1zdGF0ZSBsaXN0Pw0KDQpUaGUgLXN0YXRlIGxpc3Qgd291bGQgY29udGFp biBqdXN0IHRoZSBuYW1lIG9mIHRoZSBrZXk7IG5vdCB0aGUga2V5DQppdHNlbGYuDQoNCj4gQW5k IGlmIGEgY29uZmlnIHRydWUgbm9kZSByZWZlcnMgdG8gdGhpcyBjb25maWcgZmFsc2UNCj4gbm9k ZSwgd2hhdCBhcmUgd2Ug4oCcZGVzY3JpYmluZ+KAnSB0aGF0IHdpbGwgaGFwcGVuPyBJcyB0aGVy ZSBhIHdoZW4NCj4gc3RhdGVtZW50Pw0KDQpGb3IgZXhhbXBsZSwgaWYgdGhlIGludGVuZGVkIGNv bmZpZyBvZiB0aGUgTkVUQ09ORiBzZXJ2ZXIgY29udGFpbnMgYQ0KcmVmZXJlbmNlIHRvIGEga2V5 IHRoYXQgZG9lc24ndCBleGlzdCBpbiAtc3RhdGUsIGZvciBleGFtcGxlIGIvYyB0aGUNCnNwZWNp YWwgaHcgY291bGRuJ3QgYmUgYWNjZXNzZWQsIHRoZW4gdGhlIE5FVENPTkYgc2VydmVyIHdvdWxk bid0IGJlDQpzdGFydGVkLiAgSWYgd2UgaGF2ZSBzb21lICJvcGVyLXN0YXR1cyIgbGVhZiBmb3Ig dGhlIE5FVENPTkYgc2VydmVyLA0KaXQgY291bGQgaW5kaWNhdGUgdGhlIHJlYXNvbiB0aGF0IHRo ZSBzZXJ2ZXIgd2Fzbid0IHN0YXJ0ZWQNCigibWlzc2luZy1rZXkiIG9yIHNvbWV0aGluZykuDQoN Cg0KL21hcnRpbg0KDQoNCg0KDQo+IA0KPiA+ICANCj4gPiAgDQo+ID4gVGhhbmtzLA0KPiA+IEtl bnQNCj4gPiAgDQo+ID4gIA0KPiA+IEZyb206IE5ldGNvbmYgPG5ldGNvbmYtYm91bmNlc0BpZXRm Lm9yZz4gb24gYmVoYWxmIG9mIE1haGVzaA0KPiA+IEpldGhhbmFuZGFuaSA8bWpldGhhbmFuZGFu aUBnbWFpbC5jb20+DQo+ID4gRGF0ZTogVGh1cnNkYXksIE1heSAyNiwgMjAxNiBhdCA4OjA2IFBN DQo+ID4gVG86ICJuZXRjb25mQGlldGYub3JnIiA8bmV0Y29uZkBpZXRmLm9yZz4NCj4gPiBTdWJq ZWN0OiBbTmV0Y29uZl0gU2VtaS1jb25maWd1cmFibGUgZGVzaWduIGluIHNlcnZlciBtb2RlbCBk cmFmdA0KPiA+ICANCj4gPiBPbmUgb2YgdGhlIGlzc3VlcyB0aGF0IEtlbnQgYnJvdWdodCB1cCBp biB0aGUgaW50ZXJpbSBtZWV0aW5nIHdhcyB0aGUNCj4gPiBpc3N1ZSBvZiBjb25maWd1cmluZyB0 aGUgcHJpdmF0ZSBrZXkuIFNvbWUgYmFja2dyb3VuZCBvbiB0aGF0IGlzc3VlDQo+ID4gZGF0ZXMg YmFjayB0byB0aGUgdGhyZWFkIHRoYXQgc3RhcnRlZCB3aXRoIE1hcnRpbiByZXZpZXdpbmcgdGhl DQo+ID4gZG9jdW1lbnQgYW5kIGhlcmUgaXMgd2hhdCBoZSBicm91Z2h0IHVwIGluIHRoYXQgcmV2 aWV3Lg0KPiA+ICANCj4gPiBvICBTZWN0aW9uIDQuMQ0KPiA+ICANCj4gPiAgIEkgdGhpbmsgdGhl ICJzZW1pLWNvbmZpZ3VyYWJsZSIgZGVzaWduIGhhcyBzb21lIGlzc3Vlcy4gIFlvdSBoYXZlDQo+ ID4gICBkZWZpbmVkIHNvbWUgYWN0aW9ucyB0aGF0IGFjdHVhbGx5IG1vZGlmaWVzIHRoZSBjb25m aWd1cmF0aW9uIG9mIHRoZQ0KPiA+ICAgc3lzdGVtLiAgSXQgaXMgbm90IGNsZWFyIHdoaWNoIGNv bmZpZyBkYXRhc3RvcmUgaXMgbW9kaWZpZWQuDQo+ID4gICBQcmVzdW1hYmx5IHJ1bm5pbmcuICBJ bnRlcmFjdGlvbnMgd2l0aCBsb2NraW5nIGFuZCBhY2Nlc3MgY29udHJvbA0KPiA+ICAgYXJlIG5v dCBkZXNjcmliZWQuICBBbHNvLCB0aGUgcmVzdWx0aW5nIGNvbmZpZ3VyYXRpb24gaXMgbm90DQo+ ID4gICBjb21wbGV0ZSAtIGkuZS4sIHlvdSBjYW5ub3QgZG8gPGNvcHktY29uZmlnPiB0byBzYXZl L3Jlc3RvcmUgYQ0KPiA+ICAgYmFja3VwLiAgVGhpcyBpcyBmaW5lLCBzaW5jZSB5b3UgcmVhbGx5 IGRvbid0IHdhbnQgdG8gZXhwb3NlIHRoZQ0KPiA+ICAgcHJpdmF0ZSBrZXlzIGluIHRoZSBjb25m aWcgYmFja3VwLiAgQnV0IHNvbWUgZGlzY3Vzc2lvbiBpcyBuZWVkZWQNCj4gPiAgIGFyb3VuZCB0 aGlzIHN1YmplY3QuICBXaGF0IGhhcHBlbnMgaWYgSSBnZW5lcmF0ZSBhIHByaXZhdGUga2V5IHdp dGgNCj4gPiAgIHlvdXIgYWN0aW9uLCBiYWNrdXAgdGhhdCBjb25maWcgYW5kIHRoZW4gcmVzdG9y ZSBpdD8gIFdoYXQgaGFwcGVucw0KPiA+ICAgd2l0aCBjb25maWcgdGhhdCBoYXMgcmVmZXJlbmNl cyB0byBzdWNoIGEga2V5Pw0KPiA+ICANCj4gPiAgIE9uZSB3YXkgdG8gYXZvaWQgdGhhdCB0aGUg YWN0aW9ucyBtb2RpZnkgdGhlIGNvbmZpZ3VyYXRpb24gY291bGQgYmUNCj4gPiAgIHRvIG1vdmUg dGhlbSBpbnRvIHRoZSBwcml2YXRlLWtleSBsaXN0LiAgT25lIGRyYXdiYWNrIGlzIHRoYXQgdHdv DQo+ID4gICBvcGVyYXRpb25zIGFyZSBuZWVkZWQgaW4gb3JkZXIgdG8gY3JlYXRlIGEgKHVzYWJs ZSkga2V5IC0gZmlyc3QNCj4gPiAgIGNyZWF0ZSB0aGUgY29uZmlnIGluIHJ1bm5pbmcsIHRoZW4g Y2FsbCB0aGUgYWN0aW9uLg0KPiA+ICANCj4gPiAgIEFub3RoZXIgb3B0aW9uIG1pZ2h0IGJlIHRv IG1vZGVsIHRoZSBrZXlzIGFzIGNvbmZpZyBmYWxzZSBkYXRhLg0KPiA+ICAgVGhpcyBhbHNvIHNv bHZlcyB0aGUgcHJvYmxlbSB0aGF0IHNvbWUga2V5cyAoaW4gVFBNIGZvciBleGFtcGxlKQ0KPiA+ ICAgYXJlIG5vdCBkZWxldGFibGUuDQo+ID4gVGhlIHR3byBzdWdnZXN0aW9ucyB0aGF0IEtlbnQg YnJvdWdodCB0byB0aGUgbWVldGluZyBvbiB3aGV0aGVyIHRvDQo+ID4gbWFrZSBpdCBhIGxlYWYg b3IgYW4gYWN0aW9uLg0KPiA+ICANCj4gPiBMZWFmcyBjYW4gYmUgYmFja2VkIHVwIG9yIHJlc3Rv cmVkLiBCdXQgcHJpdmF0ZS1rZXlzIGluIFRQTSBuZXZlcg0KPiA+IGxlYXZlIHRoZSBzb3VyY2Uu IEhvdyBkbyB3ZSBzdXBwb3J0IHNwZWNpYWwgaGFyZHdhcmUgbGlrZSBUUE0/DQo+ID4gIA0KPiA+ IE1ha2luZyBpdCBhbiBhY3Rpb24gcmVxdWlyZXMgY3JlYXRpb24gb2YgYSBkdW1teSBwcml2YXRl IGtleSwgYW5kIHRoZW4NCj4gPiBjYWxsIGFjdGlvbiB0byBwb3B1bGF0ZSB0aGUgZGF0YSBpbiBp dCwgYXMgTWFydGluIHN0YXRlcyBhYm92ZS4gV2hhdA0KPiA+IGhhcHBlbnMgaWYgdGhlIGtleSBp cyBub3QgYXZhaWxhYmxlIGJ1dCBpcyByZWZlcmVuY2VkIGJ5IHRoZSBzeXN0ZW0/DQo+ID4gIA0K PiA+IEtlbnQsIGlzIHRoYXQgYSBmYWlyIHN1bW1hcnkgb2YgdGhlIGlzc3VlPw0KPiA+ICANCj4g PiBMZXQgdGhlIGRpc2N1c3Npb24gYmVnaW4gOi0pDQo+ID4gIA0KPiA+IE1haGVzaCBKZXRoYW5h bmRhbmkNCj4gPiBtamV0aGFuYW5kYW5pQGdtYWlsLmNvbSA8bWFpbHRvOm1qZXRoYW5hbmRhbmlA Z21haWwuY29tPg0KPiA+ICANCj4gPiAgDQo+ID4gIA0KPiANCj4gTWFoZXNoIEpldGhhbmFuZGFu aQ0KPiBtamV0aGFuYW5kYW5pQGdtYWlsLmNvbQ0KPiANCj4gDQo+IA0KPiANCj4gDQo= From nobody Mon May 30 15:44:43 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF07C12D69B for ; Mon, 30 May 2016 15:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxRNzjey5JmM for ; Mon, 30 May 2016 15:44:38 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7F8712D123 for ; Mon, 30 May 2016 15:44:37 -0700 (PDT) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id 1B010D82610E6; Mon, 30 May 2016 22:44:33 +0000 (GMT) Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id u4UMia3Q002296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 30 May 2016 22:44:36 GMT Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id u4UMiZeU000779 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 May 2016 22:44:35 GMT Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.17]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Mon, 30 May 2016 18:44:35 -0400 From: "Sterne, Jason (Nokia - CA)" To: EXT Xiang Li , "'Martin Bjorklund'" , "wivory@Brocade.com" , "netconf@ietf.org" Thread-Topic: [Netconf] Clarification request for NETCONF edit-config default-operation replace Thread-Index: AQHRlyYGiZoT03uS4U+O6QebXc6r0J+hZVpggACXP4CABVTvsIAAYfwAgCqd10A= Date: Mon, 30 May 2016 22:44:34 +0000 Message-ID: References: <3b242c800dfc464aaad760ca1e8fc11c@EMEAWP-EXMB12.corp.brocade.com> <20160415.144413.1614538486330526270.mbj@tail-f.com> <401695abd7214cde8e0c50b1da9bad19@EMEAWP-EXMB12.corp.brocade.com> <20160415.164925.242005632968560972.mbj@tail-f.com> <013301d1a273$ed74d250$c85e76f0$@seguesoft.com> <01f401d1a54f$621dbad0$26593070$@seguesoft.com> In-Reply-To: <01f401d1a54f$621dbad0$26593070$@seguesoft.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] Clarification request for NETCONF edit-config default-operation replace X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 22:44:42 -0000 Hi guys, I think there is some conflicting information wrt default-operation replace= here. The following snippet of RFC 6241 clearly states (IMO) that the ent= ire config is affected/replaced. The first sentence says it. Then the sec= ond sentence gives yet another indication that it replaces the entire confi= g: =20 > replace: The configuration data in the parameter > completely replaces the configuration in the target > datastore. This is useful for loading previously saved > configuration data. =20 I also found an older discussion on this on the mailing list that indicates= that a default action of replace is intended to be used for the entire da= tastore. From https://mailarchive.ietf.org/arch/msg/netconf/s4KOJxIgbDzqAX= S-uF_jFi-iQsU: =20 > 1) > $backup =3D get-config(source=3Drunning) > 2) > copy-config(source=3D$backup, target=3Drunning) > OR > edit-config(source=3D$backup, target=3Drunning, default-operation=3Dre= place)" =20 operations are inherited. The default-operation applies to al= l top level objects. But I'm not certain whether it applies to all top lev= el objects in the data model on the server or just all the top level object= s that are included in the request. From the descriptions a= bove it seems it must apply to all top level objects in the server but that= seems to conflict with: > "only the configuration actually present in the parameter is af= fected" Here is a set of examples that may help clarify things. The first 3 cases a= re an incremental lead-in to case 4 which is the least clear for me. ## Initial server Config A (used in all the cases below): 12 true 132 true 8 true ## Case 1: - Initial Config A - edit-config request (no default operation): 10 - Resulting config on the server (only 'min-length' affected): 10 true 132 true 8 true ## Case 2: - Initial Config A - edit-config request (no default operation): 10 // inherited replace - Resulting config on the server (all 'password-control' affected): 10 132 true 8 true ## Case 3: - Initial Config A - edit-config request (no default operation): // inherited replace 10 // inherited replace - Resulting config on the server (all 'system' affected) : 10 8 true =20 ## Case 4: - Initial Config A - edit-config request (!! with default-operation replace !!): =20 10 =20 =20 - Resulting config on the server (entire server datastore affected ?): 10 // no qos data ? Regards, Jason -----Original Message----- From: EXT Xiang Li [mailto:xiangli@seguesoft.com]=20 Sent: Tuesday, May 03, 2016 11:21 To: Sterne, Jason (Nokia - CA); 'Martin Bjorklund'; wivory@Brocade.com Cc: netconf@ietf.org Subject: RE: [Netconf] Clarification request for NETCONF edit-config defaul= t-operation replace Hi > -----Original Message----- >...=20 > In my first question I meant "using an ": >=20 > Is there no way to delete (or replace) the entire contents of the datastore > using an (and without using without having=20 > to explicitly list every single top level node ? >=20 I don't think edit-config is designed to do that. To delete a datastore, use , although can't be de= leted. To replace the *entire config*, use .=20 > From the description of the default-operation 'replace' it seems it is possible > via the default operation: > replace: The configuration data in the parameter > completely replaces the configuration in the target > datastore. This is useful for loading previously saved > configuration data. No. The definition of "replace" as an operation says clearly: Unlike a operation, which replaces the entire ta= rget configuration, only the configuration actually present in the parameter is affected. In other words, the only replaces the data nodes that exist in th= e target and for nodes that are in in the but not in = the target, they are created. Other nodes that exist in the device but are= not present in the of the are NOT affected in any = way (this is the key difference with , where they are removed = because it operates on the *entire* datastore.) > But can replace of the entire contents be done without replace as the default > operation ?=20 Not with the default "replace" operation, nor with the normal "replace" operation. The default "replace" operation has no additional semantics compared to The= "operation" parameter > Or delete of the entire contents ? The RFC doesn't seem to clear on=20 > whether we can use an operation on the node: > > The description of says: the target configuration is not nece= ssarily replaced, as with the message. Instead, the target c= onfiguration is changed in accordance with the source's data and requested = operations. In other words, the parameter in will not be valid i= f you do not specify it (assuming no url capability) or make it empty, as i= n your example. config: A hierarchy of configuration data as defined by one of the device's data models. The contents MUST be placed in an appropriate namespace, to allow the device to detect the appropriate data model, and the contents MUST follow the constraints of that data model, as defined by its capability definition. > (c) and (d) have a delete operation on a leaf (in (c) is it inherited)=20 > but are > providing a value for the leaf at the same time. What is the meaning=20 > of the > value ? That seems like an error to me. We should warn the client=20 > that they've done something unexpected (the client may have been=20 > intending to do something different than deleting that leaf). > I can see how that works when the leaf is a key leaf in a list. But=20 > it seems like > an error for just a plain leaf. No. I think the value is actually used by . For example, RFC6241 has this example: Delete the configuration for an interface named "Ethernet0/0" from the running configuration: none Ethernet0/0 Without specifying value so that the device can find an exact matched inter= face, this won't work. In other words, my understanding is that if a value is given, and the devic= e can't find a match then then the delete will fail with a err= or. > I'm also not convinced about (f) and (g). Wrt your analogy of a=20 > directory with > files: you can delete a container in NETCONF and that automatically deletes > any children, grandchildren and so on (the entire subtree). It seems strange > that there is no way to delete (or replace) the entire contents of a=20 > list or leaf- > list. I don't necessarily disagree with you on this one. I was simply suggesting that the protocol perhaps should have a simple way = to allow me to remove list entries. In particular I think it would be usefu= l it allows: 1) to delete a specific list entry by providing a list entry's Instance ID = ( all key nodes and corresponding values). 2) to delete all entries of a list by just providing all key nodes in the <= config>.=20 Best, --Xiang =20 > Or perhaps I'm misinterpreting the description of the replace and=20 > delete operations in RFC6241 (the sentences "only the configuration=20 > actually present in the parameter is affected" and "if and=20 > only if the configuration data currently exists" are giving me some pause= here). There > aren't many examples illustrating delete & replace in the RFC. >=20 > Regards, > Jason >=20 > -----Original Message----- > From: EXT Xiang Li [mailto:xiangli@seguesoft.com] > Sent: Friday, April 29, 2016 20:05 > To: Sterne, Jason (Nokia - CA); 'Martin Bjorklund'; wivory@Brocade.com > Cc: netconf@ietf.org > Subject: RE: [Netconf] Clarification request for NETCONF edit-config default- > operation replace >=20 >=20 >=20 > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Sterne,=20 > Jason (Nokia - CA) > Sent: Friday, April 29, 2016 2:12 PM > To: Martin Bjorklund ; wivory@Brocade.com > Cc: netconf@ietf.org > Subject: Re: [Netconf] Clarification request for NETCONF edit-config default- > operation replace >=20 > Is there no way to delete the entire contents of the datastore without having > to explicitly list every single top level node ? >=20 > e.g. > with no default operation (i.e. merge): > >=20 > Or > With default operation =3D delete: > >=20 > Similarly -> Is there no way to replace the entire contents of the datastore ? >=20 > [XL] I think< copy-config> or can do this. >=20 > About the cases below shouldn't (c) and (d) return an error ? They contain > data for an object that is being deleted. (e) seems like the correct=20 > way to do > it. >=20 > [XL] I think Martin's explanation is correct. My understanding is that=20 > if the > value does not match, then the would return an error since=20 > the no matching data node found (yes I view this as a content-match).=20 > Or I might be > totally wrong here, i.e., the value does not matter in any way as=20 > Martin said? >=20 > (f) and (g) surprise me. If I can an entire leaf-list or list by just > specifying the tag for the leaf-list/list name, why doesn't delete get=20 > rid of the > entire leaf-list/list ? > (if you specify a specific list entry/member in a delete it is=20 > basically just a > content match node but otherwise you've selected the entire list no ?). >=20 > [XL] I also thought that I can delete a list entry by specifying all=20 > key nodes > and their values (i.e., list entry's instance ID). If no values of key nodes are > given, then the entire list entries matched and all of them should be deleted. > Although Martin's explanation also makes sense here, that is, you=20 > can't just > delete a key node yet if it is still used by non-key nodes. > Just like deleting a directory when the directory still contains files. But, in any > case, I would still like that I can delete a list entry by giving the list entry's IID > since we can unmistakably identify a list entry by given a list=20 > entry's IID (i.e. , > all key nodes and their corresponding values). I think such a delete=20 > operation would be useful, just like "rm -rf directory". >=20 > --Xiang > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Martin=20 > Bjorklund > Sent: Friday, April 15, 2016 10:49 > To: wivory@Brocade.com > Cc: netconf@ietf.org > Subject: Re: [Netconf] Clarification request for NETCONF edit-config default- > operation replace >=20 > William Ivory wrote: > > OK - I think it might help if I gave some specific examples, with my=20 > > understanding of what would get deleted and you can tell me if I'm=20 > > correct or not. Apologies for length, but I'd like to avoid any=20 > > confusion by not spelling out my queries, and I'm struggling to get=20 > > a clear picture of how this all works with all the different=20 > > permutations! > > > > Let's take a configuration like this: > > > > > > leafValue > > leaflistValueOne > > leaflistValueTwo > > > > firstEntryKey > > firstEntryLeaf > > > > > > secondEntryKey > > secondEntryLeaf > > > > > > > > --- > > > > (a) topCont, default operation delete > > > > With the default operation set to delete: > > > > > > > > > > > > =3D> topCont, and everything under it, would be deleted >=20 > Yes. >=20 > > (b) topCont, operation delete > > > > With the default operation set to none: > > > > > > > > > > > > =3D> topCont, and everything under it, would be deleted > > >=20 > Yes. >=20 > > --- > > > > (c) aLeaf delete, operation specified for topCont > > > > With the default operation set to none: > > > > > > > > leafValue > > > > > > =3D> Will delete aLeaf node. If this leaves topCont empty, then=20 > > topCont would be removed. If topCont still contains other elements,=20 > > topCont would remain? >=20 > No. This deletes the topCont and everything below it. >=20 > > --- > > > > (d) aLeaf delete, operation specified for aLeaf > > > > With the default operation set to none: > > > > > > > > leafValue > > > > > > =3D> Will delete aLeaf node. If this leaves topCont empty, then=20 > > topCont would be removed unless it is a presence node. >=20 > Yes (s/would/may/) >=20 > > --- > > > > (e) aLeaf delete, operation specified for aLeaf, but no value given > > > > With the default operation set to none: > > > > > > > > > > > > =3D> Would this delete aLeaf, and, as per (d), conditionally=20 > > , or must the value of the leaf be specified? > > >=20 > Yes, this would delete aLeaf. The value doesn't matter. >=20 > > --- > > > > (f) aLeafListEntry > > > > Is there a way to delete all leaflist entries without specifying=20 > > them individually, eg: > > > > >=20 > No >=20 >=20 > > > > ... or, assuming there are other sibling nodes such that we can't=20 > > just delete topCont, must I specify each individual leaflist element=20 > > I wish to remove? > > > > --- > > > > (g) aListEntry > > > > As per leaflist entries, is there a way to delete all entries=20 > > generically >=20 > No. >=20 > >, or must each be specified? >=20 > Yes. >=20 > > Separately, if I delete a non-key node inside a list entry, I assume=20 > > that just deletes that node. If I delete the list's key node, then=20 > > presumably that removes the complete entry, eg: > > > > > > > > > > firstEntryKey > > > > >=20 > Yes >=20 > > Would the following achieve the same, ie removal of this list entry: > > > > > > > > > > firstEntryKey > > > > >=20 > Hmm. I would say that this results in an error - deleting just the=20 > key of a list is > not possible. >=20 >=20 >=20 > /martin >=20 >=20 >=20 > > > > --- > > > > Thanks for bearing with me, > > > > William > > > > -----Original Message----- > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > Sent: 15 April 2016 13:44 > > To: William Ivory > > Cc: netconf@ietf.org > > Subject: Re: [Netconf] Clarification request for NETCONF edit-config=20 > > default-operation replace > > > > William Ivory wrote: > > > Hi Martin, > > > > > > Thanks - I think that the section on 'replace' under=20 > > > 'default-operation' could do with being clarified next time the=20 > > > RFC is updated then. > > > > > > I'd appreciate some further clarification on what exactly ' only=20 > > > the configuration actually present in the parameter is affec= ted' > > > means in practice. > > > > > > First, the general pattern of examples which use=20 > > > 'operation=3D' is that this command is put in the 'parent' > > > element's tag, ie the tag which specifies 'delete' is *not* deleted. > > > > No. For example: > > > > > > 192.0.2.4 > > > > > > will delete the "interface" node with the name "192.0.2.4" > > > > It does NOT keep the "interface" node and just delete the "name" node. > > > > > How then would you delete a top-level container? > > > > > > > > > > > > /martin > > > > > > > The examples have a > > > '' element but in cases where there are multiple top-level=20 > > > nodes, some of which are optional in the configuration (ie not=20 > > > presence containers), is it possible to delete these nodes? > > > > > > Secondly, if I'm correct that the 'delete' operation would only=20 > > > affect nodes below the one with the delete operation, is it=20 > > > possible to construct an edit-config PDU that would delete all=20 > > > child nodes without having to explicitly specify each one? Or is=20 > > > the only way to achieve this either to explicitly specify all=20 > > > config to be removed, or to do a copy-config explicitly specifying=20 > > > all config that is not to be deleted. > > > > > > Thanks, > > > > > > William > > > > > > -----Original Message----- > > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > > Sent: 14 April 2016 09:34 > > > To: William Ivory > > > Cc: netconf@ietf.org > > > Subject: Re: [Netconf] Clarification request for NETCONF=20 > > > edit-config default-operation replace > > > > > > Hi, > > > > > > William Ivory wrote: > > > > Hi, > > > > > > > > I'd appreciate clarification of how the NETCONF edit-config=20 > > > > command should work with default-operation set to 'replace'. =20 > > > > For the most part, the edit-config section is clear that config=20 > > > > will only be replaced if explicitly overwritten (ie if you=20 > > > > provide replacement config for given nodes). However, the=20 > > > > section on default-operation is less clear: > > > > > > > > The parameter is optional, but if > provided, > > > > it has one of the following values: > > > > > > > > merge: The configuration data in the parameter i= s > > > > merged with the configuration at the corresponding=20 > > > > level > in > > > > the target datastore. This is the default behavior. > > > > > > > > replace: The configuration data in the parameter > > > > completely replaces the configuration in the target > > > > datastore. This is useful for loading previously saved > > > > configuration data. > > > > > > > > Specifically, while 'merge' states that merge happesn with=20 > > > > 'configuration as the corresponding level', 'replace' states=20 > > > > that is 'completely replaces' the configuration, suggesting that=20 > > > > it will remove ALL existing configuration regardless of what is=20 > > > > explicitly provided as the replacement. Is that correct, or is=20 > > > > 'replace' meant to have equivalent semantics to 'merge' ie it=20 > > > > will only replace configuration when an explicit replacement is=20 > > > > provided. In other words, if the latter case is correct, all it=20 > > > > does is remove the requirement to specify the operation in each > element of new config. > > > > > > Yes the latter is correct. Note that the definition of "replace"=20 > > > as an operation says: > > > > > > Unlike a > > > operation, which replaces the entire target > > > configuration, only the configuration actually present in > > > the parameter is affected. > > > > > > > > > /martin > > > > > >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Tue May 31 00:25:49 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4602612D0F4 for ; Tue, 31 May 2016 00:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9Da_SS3T9F5 for ; Tue, 31 May 2016 00:25:44 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFA512B04A for ; Tue, 31 May 2016 00:25:43 -0700 (PDT) Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id 4B9261AE028C for ; Tue, 31 May 2016 09:25:41 +0200 (CEST) Date: Tue, 31 May 2016 09:26:02 +0200 (CEST) Message-Id: <20160531.092602.4771955077736281.mbj@tail-f.com> To: netconf@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: Subject: [Netconf] restconf error code bug X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 07:25:47 -0000 Hi, The RESTCONF draft lists a mapping from NETCONF error tags to HTTP error codes. It maps "too-big" to "413". But this is not entirely correct. "too-big" is used when either the request is too large or the response would be too large. 413 is only used when the request is too large. It is not entirely clear which HTTP error code is appropriate when the response would be too large. 403 seems to be recommended. Maybe we should check with the HTTP WG. /martin From nobody Tue May 31 01:49:48 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA33012D096 for ; Tue, 31 May 2016 01:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EbY5lRkFu8qE for ; Tue, 31 May 2016 01:49:44 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 58ED112B008 for ; Tue, 31 May 2016 01:49:44 -0700 (PDT) Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id E34431AE028C; Tue, 31 May 2016 10:49:41 +0200 (CEST) Date: Tue, 31 May 2016 10:50:03 +0200 (CEST) Message-Id: <20160531.105003.567321207823725528.mbj@tail-f.com> To: jason.sterne@nokia.com From: Martin Bjorklund In-Reply-To: References: <01f401d1a54f$621dbad0$26593070$@seguesoft.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] Clarification request for NETCONF edit-config default-operation replace X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 08:49:47 -0000 "Sterne, Jason (Nokia - CA)" wrote: > Hi guys, > > I think there is some conflicting information wrt default-operation > replace here. I agree it is not clear. > The following snippet of RFC 6241 clearly states (IMO) > that the entire config is affected/replaced. The first sentence says > it. I don't think this statement clearly says that the entire datastore is replaced. It uses the term "completely replace". I don't know how that is different from "replace". IMO, "replace" implies "completely"... > Then the second sentence gives yet another indication that it > replaces the entire config: Not necessarily. > > replace: The configuration data in the parameter > > completely replaces the configuration in the target > > datastore. This is useful for loading previously saved > > configuration data. > > > I also found an older discussion on this on the mailing list that > indicates that a default action of replace is intended to be used for > the entire datastore. From > https://mailarchive.ietf.org/arch/msg/netconf/s4KOJxIgbDzqAXS-uF_jFi-iQsU: > > > > 1) > > $backup = get-config(source=running) > > 2) > > copy-config(source=$backup, target=running) > > OR > > edit-config(source=$backup, target=running, > > default-operation=replace)" > > > operations are inherited. The default-operation applies > to all top level objects. But I'm not certain whether it applies to > all top level objects in the data model on the server or just all the > top level objects that are included in the request. The latter. It is just a default value for the "operation" attribute; i.e., instead of using "default-operation", you could explicitly set the "operation" attribute - and you can only do that for the elements in the request (obvioulsy). > From the descriptions above it seems it must apply to all top level > objects in the server but that seems to conflict with: > > > "only the configuration actually present in the parameter is > > affected" > > Here is a set of examples that may help clarify things. The first 3 > cases are an incremental lead-in to case 4 which is the least clear > for me. > > ## Initial server Config A (used in all the cases below): > > > 12 > true > > > 132 > true > > > > > 8 > true > > > > ## Case 1: > - Initial Config A > - edit-config request (no default operation): > > > 10 > > > - Resulting config on the server (only 'min-length' affected): > > > 10 > true > > > 132 > true > > > > > 8 > true > > > > ## Case 2: > - Initial Config A > - edit-config request (no default operation): > > > 10 // inherited replace > > > - Resulting config on the server (all 'password-control' affected): > > > 10 > > > 132 > true > > > > > 8 > true > > > > ## Case 3: > - Initial Config A > - edit-config request (no default operation): > > // inherited replace > 10 // inherited replace > > > - Resulting config on the server (all 'system' affected) : > > > 10 > > > > > 8 > true > > > > ## Case 4: > - Initial Config A > - edit-config request (!! with default-operation replace !!): > > > 10 > > > - Resulting config on the server (entire server datastore affected ?): > > > 10 > > > // no qos data ? This is not correct; qos is unaffected. ## Case 5: - Initial Config A - copy-config request 10 - Resulting config on the server (entire server datastore affected !): 10 // no qos data ! /martin > > Regards, > Jason > > -----Original Message----- > From: EXT Xiang Li [mailto:xiangli@seguesoft.com] > Sent: Tuesday, May 03, 2016 11:21 > To: Sterne, Jason (Nokia - CA); 'Martin Bjorklund'; wivory@Brocade.com > Cc: netconf@ietf.org > Subject: RE: [Netconf] Clarification request for NETCONF edit-config > default-operation replace > > Hi > > > -----Original Message----- > >... > > In my first question I meant "using an ": > > > > Is there no way to delete (or replace) the entire contents of the > datastore > > using an (and without using without having > > to explicitly list every single top level node ? > > > > I don't think edit-config is designed to do that. > > To delete a datastore, use , although can't > be deleted. > To replace the *entire config*, use . > > > From the description of the default-operation 'replace' it seems it is > possible > > via the default operation: > > replace: The configuration data in the parameter > > completely replaces the configuration in the target > > datastore. This is useful for loading previously saved > > configuration data. > > > No. The definition of "replace" as an operation says clearly: > > Unlike a operation, which replaces the entire target > configuration, only the configuration actually present in > the parameter is affected. > > In other words, the only replaces the data nodes that exist > in the target and for nodes that are in in the > but not in the target, they are created. Other nodes that > exist in the device but are not present in the of the > are NOT affected in any way (this is the key difference > with , where they are removed because it operates on the > *entire* datastore.) > > > But can replace of the entire contents be done without replace as the > default > > operation ? > > Not with the default "replace" operation, nor with the normal > "replace" > operation. > The default "replace" operation has no additional semantics compared > to The "operation" parameter > > > Or delete of the entire contents ? The RFC doesn't seem to clear on > > whether we can use an operation on the node: > > > > > > > The description of says: the target configuration is not > necessarily replaced, as with the message. Instead, the > target configuration is changed in accordance with the source's data > and requested operations. > > In other words, the parameter in will not be > valid if you do not specify it (assuming no url capability) or make it > empty, as in your example. > > config: A hierarchy of configuration data as defined by one of > the device's data models. The contents MUST be placed in an > appropriate namespace, to allow the device to detect the > appropriate data model, and the contents MUST follow the > constraints of that data model, as defined by its capability > definition. > > > > (c) and (d) have a delete operation on a leaf (in (c) is it inherited) > > but > are > > providing a value for the leaf at the same time. What is the meaning > > of > the > > value ? That seems like an error to me. We should warn the client > > that they've done something unexpected (the client may have been > > intending to do something different than deleting that leaf). > > I can see how that works when the leaf is a key leaf in a list. But > > it > seems like > > an error for just a plain leaf. > > > No. I think the value is actually used by . For example, > RFC6241 > has this example: > > Delete the configuration for an interface named "Ethernet0/0" from > the running configuration: > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > none > > > > Ethernet0/0 > > > > > > > > Without specifying value so that the device can find an exact matched > interface, this won't work. > > In other words, my understanding is that if a value is given, and the > device > > can't find a match then then the delete will fail with a > error. > > > I'm also not convinced about (f) and (g). Wrt your analogy of a > > directory > with > > files: you can delete a container in NETCONF and that automatically > deletes > > any children, grandchildren and so on (the entire subtree). It seems > strange > > that there is no way to delete (or replace) the entire contents of a > > list > or leaf- > > list. > > I don't necessarily disagree with you on this one. > > I was simply suggesting that the protocol perhaps should have a simple > way to allow me to remove list entries. In particular I think it would > be useful it allows: > 1) to delete a specific list entry by providing a list entry's > Instance ID ( all key nodes and corresponding values). > 2) to delete all entries of a list by just providing all key nodes in > the . > > Best, > --Xiang > > > > > Or perhaps I'm misinterpreting the description of the replace and > > delete operations in RFC6241 (the sentences "only the configuration > > actually present in the parameter is affected" and "if and > > only if the configuration data currently exists" are giving me some > > pause here). > There > > aren't many examples illustrating delete & replace in the RFC. > > > > Regards, > > Jason > > > > -----Original Message----- > > From: EXT Xiang Li [mailto:xiangli@seguesoft.com] > > Sent: Friday, April 29, 2016 20:05 > > To: Sterne, Jason (Nokia - CA); 'Martin Bjorklund'; wivory@Brocade.com > > Cc: netconf@ietf.org > > Subject: RE: [Netconf] Clarification request for NETCONF edit-config > default- > > operation replace > > > > > > > > -----Original Message----- > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Sterne, > > Jason (Nokia - CA) > > Sent: Friday, April 29, 2016 2:12 PM > > To: Martin Bjorklund ; wivory@Brocade.com > > Cc: netconf@ietf.org > > Subject: Re: [Netconf] Clarification request for NETCONF edit-config > default- > > operation replace > > > > Is there no way to delete the entire contents of the datastore without > having > > to explicitly list every single top level node ? > > > > e.g. > > with no default operation (i.e. merge): > > > > > > Or > > With default operation = delete: > > > > > > Similarly -> Is there no way to replace the entire contents of the > datastore ? > > > > [XL] I think< copy-config> or can do this. > > > > About the cases below shouldn't (c) and (d) return an error ? They > contain > > data for an object that is being deleted. (e) seems like the correct > > way > to do > > it. > > > > [XL] I think Martin's explanation is correct. My understanding is that > > if > the > > value does not match, then the would return an error since > > the no matching data node found (yes I view this as a content-match). > > Or I might > be > > totally wrong here, i.e., the value does not matter in any way as > > Martin > said? > > > > (f) and (g) surprise me. If I can an entire leaf-list or > list by just > > specifying the tag for the leaf-list/list name, why doesn't delete get > > rid > of the > > entire leaf-list/list ? > > (if you specify a specific list entry/member in a delete it is > > basically > just a > > content match node but otherwise you've selected the entire list no > > ?). > > > > [XL] I also thought that I can delete a list entry by specifying all > > key > nodes > > and their values (i.e., list entry's instance ID). If no values of key > nodes are > > given, then the entire list entries matched and all of them should be > deleted. > > Although Martin's explanation also makes sense here, that is, you > > can't > just > > delete a key node yet if it is still used by non-key nodes. > > Just like deleting a directory when the directory still contains > > files. > But, in any > > case, I would still like that I can delete a list entry by giving the > list entry's IID > > since we can unmistakably identify a list entry by given a list > > entry's > IID (i.e. , > > all key nodes and their corresponding values). I think such a delete > > operation would be useful, just like "rm -rf directory". > > > > --Xiang > > -----Original Message----- > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Martin > > Bjorklund > > Sent: Friday, April 15, 2016 10:49 > > To: wivory@Brocade.com > > Cc: netconf@ietf.org > > Subject: Re: [Netconf] Clarification request for NETCONF edit-config > default- > > operation replace > > > > William Ivory wrote: > > > OK - I think it might help if I gave some specific examples, with my > > > understanding of what would get deleted and you can tell me if I'm > > > correct or not. Apologies for length, but I'd like to avoid any > > > confusion by not spelling out my queries, and I'm struggling to get > > > a clear picture of how this all works with all the different > > > permutations! > > > > > > Let's take a configuration like this: > > > > > > > > > leafValue > > > leaflistValueOne > > > leaflistValueTwo > > > > > > firstEntryKey > > > firstEntryLeaf > > > > > > > > > secondEntryKey > > > secondEntryLeaf > > > > > > > > > > > > --- > > > > > > (a) topCont, default operation delete > > > > > > With the default operation set to delete: > > > > > > > > > > > > > > > > > > => topCont, and everything under it, would be deleted > > > > Yes. > > > > > (b) topCont, operation delete > > > > > > With the default operation set to none: > > > > > > > > > > > > > > > > > > => topCont, and everything under it, would be deleted > > > > > > > Yes. > > > > > --- > > > > > > (c) aLeaf delete, operation specified for topCont > > > > > > With the default operation set to none: > > > > > > > > > > > > leafValue > > > > > > > > > => Will delete aLeaf node. If this leaves topCont empty, then > > > topCont would be removed. If topCont still contains other elements, > > > topCont would remain? > > > > No. This deletes the topCont and everything below it. > > > > > --- > > > > > > (d) aLeaf delete, operation specified for aLeaf > > > > > > With the default operation set to none: > > > > > > > > > > > > leafValue > > > > > > > > > => Will delete aLeaf node. If this leaves topCont empty, then > > > topCont would be removed unless it is a presence node. > > > > Yes (s/would/may/) > > > > > --- > > > > > > (e) aLeaf delete, operation specified for aLeaf, but no value given > > > > > > With the default operation set to none: > > > > > > > > > > > > > > > > > > => Would this delete aLeaf, and, as per (d), conditionally > > > , or must the value of the leaf be specified? > > > > > > > Yes, this would delete aLeaf. The value doesn't matter. > > > > > --- > > > > > > (f) aLeafListEntry > > > > > > Is there a way to delete all leaflist entries without specifying > > > them individually, eg: > > > > > > > > > > No > > > > > > > > > > ... or, assuming there are other sibling nodes such that we can't > > > just delete topCont, must I specify each individual leaflist element > > > I wish to remove? > > > > > > --- > > > > > > (g) aListEntry > > > > > > As per leaflist entries, is there a way to delete all entries > > > generically > > > > No. > > > > >, or must each be specified? > > > > Yes. > > > > > Separately, if I delete a non-key node inside a list entry, I assume > > > that just deletes that node. If I delete the list's key node, then > > > presumably that removes the complete entry, eg: > > > > > > > > > > > > > > > firstEntryKey > > > > > > > > > > Yes > > > > > Would the following achieve the same, ie removal of this list entry: > > > > > > > > > > > > > > > firstEntryKey > > > > > > > > > > Hmm. I would say that this results in an error - deleting just the > > key of > a list is > > not possible. > > > > > > > > /martin > > > > > > > > > > > > --- > > > > > > Thanks for bearing with me, > > > > > > William > > > > > > -----Original Message----- > > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > > Sent: 15 April 2016 13:44 > > > To: William Ivory > > > Cc: netconf@ietf.org > > > Subject: Re: [Netconf] Clarification request for NETCONF edit-config > > > default-operation replace > > > > > > William Ivory wrote: > > > > Hi Martin, > > > > > > > > Thanks - I think that the section on 'replace' under > > > > 'default-operation' could do with being clarified next time the > > > > RFC is updated then. > > > > > > > > I'd appreciate some further clarification on what exactly ' only > > > > the configuration actually present in the parameter is > > > > affected' > > > > means in practice. > > > > > > > > First, the general pattern of examples which use > > > > 'operation=' is that this command is put in the 'parent' > > > > element's tag, ie the tag which specifies 'delete' is *not* deleted. > > > > > > No. For example: > > > > > > > > > 192.0.2.4 > > > > > > > > > will delete the "interface" node with the name "192.0.2.4" > > > > > > It does NOT keep the "interface" node and just delete the "name" node. > > > > > > > How then would you delete a top-level container? > > > > > > > > > > > > > > > > > > /martin > > > > > > > > > > The examples have a > > > > '' element but in cases where there are multiple top-level > > > > nodes, some of which are optional in the configuration (ie not > > > > presence containers), is it possible to delete these nodes? > > > > > > > > Secondly, if I'm correct that the 'delete' operation would only > > > > affect nodes below the one with the delete operation, is it > > > > possible to construct an edit-config PDU that would delete all > > > > child nodes without having to explicitly specify each one? Or is > > > > the only way to achieve this either to explicitly specify all > > > > config to be removed, or to do a copy-config explicitly specifying > > > > all config that is not to be deleted. > > > > > > > > Thanks, > > > > > > > > William > > > > > > > > -----Original Message----- > > > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > > > Sent: 14 April 2016 09:34 > > > > To: William Ivory > > > > Cc: netconf@ietf.org > > > > Subject: Re: [Netconf] Clarification request for NETCONF > > > > edit-config default-operation replace > > > > > > > > Hi, > > > > > > > > William Ivory wrote: > > > > > Hi, > > > > > > > > > > I'd appreciate clarification of how the NETCONF edit-config > > > > > command should work with default-operation set to 'replace'. > > > > > For the most part, the edit-config section is clear that config > > > > > will only be replaced if explicitly overwritten (ie if you > > > > > provide replacement config for given nodes). However, the > > > > > section on default-operation is less clear: > > > > > > > > > > The parameter is optional, but if > > provided, > > > > > it has one of the following values: > > > > > > > > > > merge: The configuration data in the parameter is > > > > > merged with the configuration at the corresponding > > > > > level > > in > > > > > the target datastore. This is the default behavior. > > > > > > > > > > replace: The configuration data in the parameter > > > > > completely replaces the configuration in the target > > > > > datastore. This is useful for loading previously saved > > > > > configuration data. > > > > > > > > > > Specifically, while 'merge' states that merge happesn with > > > > > 'configuration as the corresponding level', 'replace' states > > > > > that is 'completely replaces' the configuration, suggesting that > > > > > it will remove ALL existing configuration regardless of what is > > > > > explicitly provided as the replacement. Is that correct, or is > > > > > 'replace' meant to have equivalent semantics to 'merge' ie it > > > > > will only replace configuration when an explicit replacement is > > > > > provided. In other words, if the latter case is correct, all it > > > > > does is remove the requirement to specify the operation in each > > element of new config. > > > > > > > > Yes the latter is correct. Note that the definition of "replace" > > > > as an operation says: > > > > > > > > Unlike a > > > > operation, which replaces the entire target > > > > configuration, only the configuration actually present in > > > > the parameter is affected. > > > > > > > > > > > > /martin > > > > > > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > From nobody Tue May 31 06:37:12 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB0E12D513 for ; Tue, 31 May 2016 06:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XR0CuoriC24Y for ; Tue, 31 May 2016 06:37:02 -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 D757712D1DC for ; Tue, 31 May 2016 06:37:01 -0700 (PDT) Received: from us70tumx1.dmz.alcatel-lucent.com (unknown [135.245.18.13]) by Websense Email Security Gateway with ESMTPS id 387872A53A32D; Tue, 31 May 2016 13:36:58 +0000 (GMT) Received: from us70tusmtp1.zam.alcatel-lucent.com (us70tusmtp1.zam.alcatel-lucent.com [135.5.2.63]) by us70tumx1.dmz.alcatel-lucent.com (GMO) with ESMTP id u4VDb04C009589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 31 May 2016 13:37:00 GMT Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id u4VDaxbX011014 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 31 May 2016 13:36:59 GMT Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.17]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Tue, 31 May 2016 09:36:59 -0400 From: "Sterne, Jason (Nokia - CA)" To: Martin Bjorklund Thread-Topic: [Netconf] Clarification request for NETCONF edit-config default-operation replace Thread-Index: AQHRlyYGiZoT03uS4U+O6QebXc6r0J+hZVpggACXP4CABVTvsIAAYfwAgCqd10CAAPY+gIAACTeg Date: Tue, 31 May 2016 13:36:59 +0000 Message-ID: References: <01f401d1a54f$621dbad0$26593070$@seguesoft.com> <20160531.105003.567321207823725528.mbj@tail-f.com> In-Reply-To: <20160531.105003.567321207823725528.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Clarification request for NETCONF edit-config default-operation replace X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 13:37:11 -0000 Thx Martin. Your explanation that a default replace operation can only app= ly to elements that are in the request helps a lot. So there really is no such thing as an edit-config 'replace' operation that= operates "at the root". That can only be done with a special dedicated RPC= (e.g. copy-config as you show in Case 5). So my case 4 is equivalent to this: > > =20 > 10 =20 > =20 > which will replace the entire contents of the /system subtree (but not anyt= hing else). On a related note -> is the final result (i.e. datastore contents) of a rep= lace operation always exactly the same as a remove + merge with the same da= ta at the same location ? I can't think of an example where that isn't tru= e but I may be missing some corner case. =20 For the candidate datastore it seems that 'replace' is simply a shorthand w= ay to do remove+merge in a single edit-config. For a running datastore (wr= iteable-running) the impacts would be quite different though since the edit= -config 'remove' would be applied immediately which would clear out all con= fig for a short period before the 'merge' then gets processed. Regards, Jason -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com]=20 Sent: Tuesday, May 31, 2016 4:50 To: Sterne, Jason (Nokia - CA) Cc: xiangli@seguesoft.com; wivory@Brocade.com; netconf@ietf.org Subject: Re: [Netconf] Clarification request for NETCONF edit-config defaul= t-operation replace "Sterne, Jason (Nokia - CA)" wrote: > Hi guys, >=20 > I think there is some conflicting information wrt default-operation=20 > replace here. I agree it is not clear. > The following snippet of RFC 6241 clearly states (IMO) that the entire=20 > config is affected/replaced. The first sentence says it. I don't think this statement clearly says that the entire datastore is repl= aced. It uses the term "completely replace". I don't know how that is dif= ferent from "replace". IMO, "replace" implies "completely"... > Then the second sentence gives yet another indication that it replaces=20 > the entire config: Not necessarily. > > replace: The configuration data in the parameter > > completely replaces the configuration in the target > > datastore. This is useful for loading previously saved > > configuration data. > =20 >=20 > I also found an older discussion on this on the mailing list that=20 > indicates that a default action of replace is intended to be used for=20 > the entire datastore. From > https://mailarchive.ietf.org/arch/msg/netconf/s4KOJxIgbDzqAXS-uF_jFi-iQsU= : >=20 > =20 > > 1) > > $backup =3D get-config(source=3Drunning) > > 2) > > copy-config(source=3D$backup, target=3Drunning) OR > > edit-config(source=3D$backup, target=3Drunning, > > default-operation=3Dreplace)" > =20 >=20 > operations are inherited. The default-operation applies=20 > to all top level objects. But I'm not certain whether it applies to=20 > all top level objects in the data model on the server or just all the=20 > top level objects that are included in the request. The latter. It is just a default value for the "operation" attribute; i.e.= , instead of using "default-operation", you could explicitly set the "opera= tion" attribute - and you can only do that for the elements in the request = (obvioulsy). > From the descriptions above it seems it must apply to all top level=20 > objects in the server but that seems to conflict with: >=20 > > "only the configuration actually present in the parameter=20 > > is affected" >=20 > Here is a set of examples that may help clarify things. The first 3=20 > cases are an incremental lead-in to case 4 which is the least clear=20 > for me. >=20 > ## Initial server Config A (used in all the cases below): > > > 12 > true > > > 132 > true > > > > > 8 > true > > >=20 > ## Case 1: > - Initial Config A > - edit-config request (no default operation): > > > 10 > > > - Resulting config on the server (only 'min-length' affected): > > > 10 > true > > > 132 > true > > > > > 8 > true > > >=20 > ## Case 2: > - Initial Config A > - edit-config request (no default operation): > > > 10 // inherited replace > > > - Resulting config on the server (all 'password-control' affected): > > > 10 > > > 132 > true > > > > > 8 > true > > >=20 > ## Case 3: > - Initial Config A > - edit-config request (no default operation): > > // inherited replace > 10 // inherited replace > > > - Resulting config on the server (all 'system' affected) : > > > 10 > > > > > 8 > true > > > =20 > ## Case 4: > - Initial Config A > - edit-config request (!! with default-operation replace !!): > > =20 > 10 =20 > =20 > > - Resulting config on the server (entire server datastore affected ?): > > > 10 > > > // no qos data ? This is not correct; qos is unaffected. ## Case 5: - Initial Config A - copy-config request =20 10 =20 =20 - Resulting config on the server (entire server datastore affected !): 10 // no qos data ! /martin >=20 > Regards, > Jason >=20 > -----Original Message----- > From: EXT Xiang Li [mailto:xiangli@seguesoft.com] > Sent: Tuesday, May 03, 2016 11:21 > To: Sterne, Jason (Nokia - CA); 'Martin Bjorklund'; wivory@Brocade.com > Cc: netconf@ietf.org > Subject: RE: [Netconf] Clarification request for NETCONF edit-config=20 > default-operation replace >=20 > Hi >=20 > > -----Original Message----- > >...=20 > > In my first question I meant "using an ": > >=20 > > Is there no way to delete (or replace) the entire contents of the > datastore > > using an (and without using without=20 > > having to explicitly list every single top level node ? > >=20 >=20 > I don't think edit-config is designed to do that. >=20 > To delete a datastore, use , although can't=20 > be deleted. > To replace the *entire config*, use .=20 >=20 > > From the description of the default-operation 'replace' it seems it=20 > > is > possible > > via the default operation: > > replace: The configuration data in the parameter > > completely replaces the configuration in the target > > datastore. This is useful for loading previously saved > > configuration data. >=20 >=20 > No. The definition of "replace" as an operation says clearly: >=20 > Unlike a operation, which replaces the entire = target > configuration, only the configuration actually present in > the parameter is affected. >=20 > In other words, the only replaces the data nodes that exist=20 > in the target and for nodes that are in in the=20 > but not in the target, they are created. Other nodes that=20 > exist in the device but are not present in the of the=20 > are NOT affected in any way (this is the key difference=20 > with , where they are removed because it operates on the > *entire* datastore.) >=20 > > But can replace of the entire contents be done without replace as=20 > > the > default > > operation ?=20 >=20 > Not with the default "replace" operation, nor with the normal=20 > "replace" > operation. > The default "replace" operation has no additional semantics compared=20 > to The "operation" parameter >=20 > > Or delete of the entire contents ? The RFC doesn't seem to clear on=20 > > whether we can use an operation on the node: > > > > >=20 >=20 > The description of says: the target configuration is not=20 > necessarily replaced, as with the message. Instead, the=20 > target configuration is changed in accordance with the source's data=20 > and requested operations. >=20 > In other words, the parameter in will not be=20 > valid if you do not specify it (assuming no url capability) or make it=20 > empty, as in your example. >=20 > config: A hierarchy of configuration data as defined by one of > the device's data models. The contents MUST be placed in an > appropriate namespace, to allow the device to detect the > appropriate data model, and the contents MUST follow the > constraints of that data model, as defined by its capability > definition. >=20 >=20 > > (c) and (d) have a delete operation on a leaf (in (c) is it=20 > > inherited) but > are > > providing a value for the leaf at the same time. What is the meaning=20 > > of > the > > value ? That seems like an error to me. We should warn the client=20 > > that they've done something unexpected (the client may have been=20 > > intending to do something different than deleting that leaf). > > I can see how that works when the leaf is a key leaf in a list. But=20 > > it > seems like > > an error for just a plain leaf. >=20 >=20 > No. I think the value is actually used by . For example, > RFC6241 > has this example: >=20 > Delete the configuration for an interface named "Ethernet0/0" from > the running configuration: >=20 > xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > none > > > > Ethernet0/0 > > > > > >=20 >=20 > Without specifying value so that the device can find an exact matched=20 > interface, this won't work. >=20 > In other words, my understanding is that if a value is given, and the=20 > device >=20 > can't find a match then then the delete will fail with a=20 > error. >=20 > > I'm also not convinced about (f) and (g). Wrt your analogy of a=20 > > directory > with > > files: you can delete a container in NETCONF and that automatically > deletes > > any children, grandchildren and so on (the entire subtree). It=20 > > seems > strange > > that there is no way to delete (or replace) the entire contents of a=20 > > list > or leaf- > > list. >=20 > I don't necessarily disagree with you on this one. >=20 > I was simply suggesting that the protocol perhaps should have a simple=20 > way to allow me to remove list entries. In particular I think it would=20 > be useful it allows: > 1) to delete a specific list entry by providing a list entry's=20 > Instance ID ( all key nodes and corresponding values). > 2) to delete all entries of a list by just providing all key nodes in=20 > the . >=20 > Best, > --Xiang >=20 >=20 > =20 > > Or perhaps I'm misinterpreting the description of the replace and=20 > > delete operations in RFC6241 (the sentences "only the configuration=20 > > actually present in the parameter is affected" and "if and=20 > > only if the configuration data currently exists" are giving me some=20 > > pause here). > There > > aren't many examples illustrating delete & replace in the RFC. > >=20 > > Regards, > > Jason > >=20 > > -----Original Message----- > > From: EXT Xiang Li [mailto:xiangli@seguesoft.com] > > Sent: Friday, April 29, 2016 20:05 > > To: Sterne, Jason (Nokia - CA); 'Martin Bjorklund';=20 > > wivory@Brocade.com > > Cc: netconf@ietf.org > > Subject: RE: [Netconf] Clarification request for NETCONF edit-config > default- > > operation replace > >=20 > >=20 > >=20 > > -----Original Message----- > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Sterne,=20 > > Jason (Nokia - CA) > > Sent: Friday, April 29, 2016 2:12 PM > > To: Martin Bjorklund ; wivory@Brocade.com > > Cc: netconf@ietf.org > > Subject: Re: [Netconf] Clarification request for NETCONF edit-config > default- > > operation replace > >=20 > > Is there no way to delete the entire contents of the datastore=20 > > without > having > > to explicitly list every single top level node ? > >=20 > > e.g. > > with no default operation (i.e. merge): > > > >=20 > > Or > > With default operation =3D delete: > > > >=20 > > Similarly -> Is there no way to replace the entire contents of the > datastore ? > >=20 > > [XL] I think< copy-config> or can do this. > >=20 > > About the cases below shouldn't (c) and (d) return an error ? They > contain > > data for an object that is being deleted. (e) seems like the=20 > > correct way > to do > > it. > >=20 > > [XL] I think Martin's explanation is correct. My understanding is=20 > > that if > the > > value does not match, then the would return an error since=20 > > the no matching data node found (yes I view this as a content-match). > > Or I might > be > > totally wrong here, i.e., the value does not matter in any way as=20 > > Martin > said? > >=20 > > (f) and (g) surprise me. If I can an entire leaf-list=20 > > or > list by just > > specifying the tag for the leaf-list/list name, why doesn't delete=20 > > get rid > of the > > entire leaf-list/list ? > > (if you specify a specific list entry/member in a delete it is=20 > > basically > just a > > content match node but otherwise you've selected the entire list no=20 > > ?). > >=20 > > [XL] I also thought that I can delete a list entry by specifying =20 > > all key > nodes > > and their values (i.e., list entry's instance ID). If no values of=20 > > key > nodes are > > given, then the entire list entries matched and all of them should=20 > > be > deleted. > > Although Martin's explanation also makes sense here, that is, you=20 > > can't > just > > delete a key node yet if it is still used by non-key nodes. > > Just like deleting a directory when the directory still contains=20 > > files. > But, in any > > case, I would still like that I can delete a list entry by giving=20 > > the > list entry's IID > > since we can unmistakably identify a list entry by given a list=20 > > entry's > IID (i.e. , > > all key nodes and their corresponding values). I think such a=20 > > delete operation would be useful, just like "rm -rf directory". > >=20 > > --Xiang > > -----Original Message----- > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Martin=20 > > Bjorklund > > Sent: Friday, April 15, 2016 10:49 > > To: wivory@Brocade.com > > Cc: netconf@ietf.org > > Subject: Re: [Netconf] Clarification request for NETCONF edit-config > default- > > operation replace > >=20 > > William Ivory wrote: > > > OK - I think it might help if I gave some specific examples, with=20 > > > my understanding of what would get deleted and you can tell me if=20 > > > I'm correct or not. Apologies for length, but I'd like to avoid=20 > > > any confusion by not spelling out my queries, and I'm struggling=20 > > > to get a clear picture of how this all works with all the=20 > > > different permutations! > > > > > > Let's take a configuration like this: > > > > > > > > > leafValue > > > leaflistValueOne > > > leaflistValueTwo > > > > > > firstEntryKey > > > firstEntryLeaf > > > > > > > > > secondEntryKey > > > secondEntryLeaf > > > > > > > > > > > > --- > > > > > > (a) topCont, default operation delete > > > > > > With the default operation set to delete: > > > > > > > > > > > > > > > > > > =3D> topCont, and everything under it, would be deleted > >=20 > > Yes. > >=20 > > > (b) topCont, operation delete > > > > > > With the default operation set to none: > > > > > > > > > > > > > > > > > > =3D> topCont, and everything under it, would be deleted > > > > >=20 > > Yes. > >=20 > > > --- > > > > > > (c) aLeaf delete, operation specified for topCont > > > > > > With the default operation set to none: > > > > > > > > > > > > leafValue > > > > > > > > > =3D> Will delete aLeaf node. If this leaves topCont empty, then=20 > > > topCont would be removed. If topCont still contains other=20 > > > elements, topCont would remain? > >=20 > > No. This deletes the topCont and everything below it. > >=20 > > > --- > > > > > > (d) aLeaf delete, operation specified for aLeaf > > > > > > With the default operation set to none: > > > > > > > > > > > > leafValue > > > > > > > > > =3D> Will delete aLeaf node. If this leaves topCont empty, then=20 > > > topCont would be removed unless it is a presence node. > >=20 > > Yes (s/would/may/) > >=20 > > > --- > > > > > > (e) aLeaf delete, operation specified for aLeaf, but no value=20 > > > given > > > > > > With the default operation set to none: > > > > > > > > > > > > > > > > > > =3D> Would this delete aLeaf, and, as per (d), conditionally=20 > > > , or must the value of the leaf be specified? > > > > >=20 > > Yes, this would delete aLeaf. The value doesn't matter. > >=20 > > > --- > > > > > > (f) aLeafListEntry > > > > > > Is there a way to delete all leaflist entries without specifying=20 > > > them individually, eg: > > > > > > > >=20 > > No > >=20 > >=20 > > > > > > ... or, assuming there are other sibling nodes such that we can't=20 > > > just delete topCont, must I specify each individual leaflist=20 > > > element I wish to remove? > > > > > > --- > > > > > > (g) aListEntry > > > > > > As per leaflist entries, is there a way to delete all entries=20 > > > generically > >=20 > > No. > >=20 > > >, or must each be specified? > >=20 > > Yes. > >=20 > > > Separately, if I delete a non-key node inside a list entry, I=20 > > > assume that just deletes that node. If I delete the list's key=20 > > > node, then presumably that removes the complete entry, eg: > > > > > > > > > > > > > > > firstEntryKey > > > > > > > >=20 > > Yes > >=20 > > > Would the following achieve the same, ie removal of this list entry: > > > > > > > > > > > > > > > firstEntryKey > > > > > > > >=20 > > Hmm. I would say that this results in an error - deleting just the=20 > > key of > a list is > > not possible. > >=20 > >=20 > >=20 > > /martin > >=20 > >=20 > >=20 > > > > > > --- > > > > > > Thanks for bearing with me, > > > > > > William > > > > > > -----Original Message----- > > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > > Sent: 15 April 2016 13:44 > > > To: William Ivory > > > Cc: netconf@ietf.org > > > Subject: Re: [Netconf] Clarification request for NETCONF=20 > > > edit-config default-operation replace > > > > > > William Ivory wrote: > > > > Hi Martin, > > > > > > > > Thanks - I think that the section on 'replace' under=20 > > > > 'default-operation' could do with being clarified next time the=20 > > > > RFC is updated then. > > > > > > > > I'd appreciate some further clarification on what exactly ' only=20 > > > > the configuration actually present in the parameter is=20 > > > > affected' > > > > means in practice. > > > > > > > > First, the general pattern of examples which use=20 > > > > 'operation=3D' is that this command is put in the 'paren= t' > > > > element's tag, ie the tag which specifies 'delete' is *not* deleted= . > > > > > > No. For example: > > > > > > > > > 192.0.2.4 > > > > > > > > > will delete the "interface" node with the name "192.0.2.4" > > > > > > It does NOT keep the "interface" node and just delete the "name" node= . > > > > > > > How then would you delete a top-level container? > > > > > > > > > > > > > > > > > > /martin > > > > > > > > > > The examples have a > > > > '' element but in cases where there are multiple top-level=20 > > > > nodes, some of which are optional in the configuration (ie not=20 > > > > presence containers), is it possible to delete these nodes? > > > > > > > > Secondly, if I'm correct that the 'delete' operation would only=20 > > > > affect nodes below the one with the delete operation, is it=20 > > > > possible to construct an edit-config PDU that would delete all=20 > > > > child nodes without having to explicitly specify each one? Or=20 > > > > is the only way to achieve this either to explicitly specify all=20 > > > > config to be removed, or to do a copy-config explicitly=20 > > > > specifying all config that is not to be deleted. > > > > > > > > Thanks, > > > > > > > > William > > > > > > > > -----Original Message----- > > > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > > > Sent: 14 April 2016 09:34 > > > > To: William Ivory > > > > Cc: netconf@ietf.org > > > > Subject: Re: [Netconf] Clarification request for NETCONF=20 > > > > edit-config default-operation replace > > > > > > > > Hi, > > > > > > > > William Ivory wrote: > > > > > Hi, > > > > > > > > > > I'd appreciate clarification of how the NETCONF edit-config=20 > > > > > command should work with default-operation set to 'replace'. > > > > > For the most part, the edit-config section is clear that=20 > > > > > config will only be replaced if explicitly overwritten (ie if=20 > > > > > you provide replacement config for given nodes). However, the=20 > > > > > section on default-operation is less clear: > > > > > > > > > > The parameter is optional, but if > > provided, > > > > > it has one of the following values: > > > > > > > > > > merge: The configuration data in the parameter= is > > > > > merged with the configuration at the corresponding=20 > > > > > level > > in > > > > > the target datastore. This is the default behavior. > > > > > > > > > > replace: The configuration data in the paramet= er > > > > > completely replaces the configuration in the target > > > > > datastore. This is useful for loading previously sav= ed > > > > > configuration data. > > > > > > > > > > Specifically, while 'merge' states that merge happesn with=20 > > > > > 'configuration as the corresponding level', 'replace' states=20 > > > > > that is 'completely replaces' the configuration, suggesting=20 > > > > > that it will remove ALL existing configuration regardless of=20 > > > > > what is explicitly provided as the replacement. Is that=20 > > > > > correct, or is 'replace' meant to have equivalent semantics to=20 > > > > > 'merge' ie it will only replace configuration when an explicit=20 > > > > > replacement is provided. In other words, if the latter case=20 > > > > > is correct, all it does is remove the requirement to specify=20 > > > > > the operation in each > > element of new config. > > > > > > > > Yes the latter is correct. Note that the definition of "replace"=20 > > > > as an operation says: > > > > > > > > Unlike a > > > > operation, which replaces the entire targ= et > > > > configuration, only the configuration actually present = in > > > > the parameter is affected. > > > > > > > > > > > > /martin > > > > > > > > >=20 > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > >=20 > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf >=20 >=20 From nobody Tue May 31 07:16:21 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C446612D77B for ; Tue, 31 May 2016 07:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIL0CRC-jzAV for ; Tue, 31 May 2016 07:16:15 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F77712D756 for ; Tue, 31 May 2016 07:16:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=62098; q=dns/txt; s=iport; t=1464704174; x=1465913774; h=subject:references:from:to:message-id:date:mime-version: in-reply-to; bh=vm/NW6kxL9f3yHagAr+EiKTt+DJHNPuVsuyrSJF2aW4=; b=iEqFGKlDn4DH/BO6PEwO6n9z9s7u62uk4etUuPJ6/MJOFdK6HdwXWvHM rwomruO2FCGTh9tpOZqm3Pdw06mWpXDRBvVUNrDdwwDAk6UbcJd2QqXVy yVUabeyT7eFKXaExZaSTAswEOktIMNr1YnhUp4Ju0MfpC10ZPbL86251U w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DzAQA8nE1X/xbLJq1bgm+BIytSg0Ola?= =?us-ascii?q?4h9h14BDYF6JIQ8UhVKAoF2FAEBAQEBAQFlJ4RGAgQaAQgEJSIbHiUBCQICJTI?= =?us-ascii?q?GDQgBAReIDwUOrGCFR4s4AQEBAQYBAQEBAQEBAQEehieBd4ZdARsBAQWDH4JZA?= =?us-ascii?q?QSIBIFqg3eKUoYAiCCBaU6EAYMJhVuGM4FOh0seAQFCggYcgU06MgEBiQGBNQE?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.26,395,1459814400"; d="scan'208,217";a="677474184" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 May 2016 14:15:49 +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 u4VEFmGF025549 for ; Tue, 31 May 2016 14:15:48 GMT References: <5612db74-b32b-164d-c71c-daf669e6b142@cisco.com> From: Benoit Claise To: NETCONF X-Forwarded-Message-Id: <5612db74-b32b-164d-c71c-daf669e6b142@cisco.com> Message-ID: <2cb94ab9-9c1d-77ae-eb8b-2d41ba39f495@cisco.com> Date: Tue, 31 May 2016 16:15:47 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <5612db74-b32b-164d-c71c-daf669e6b142@cisco.com> Content-Type: multipart/alternative; boundary="------------FDC3C9242E626E2B4010527E" Archived-At: Subject: [Netconf] AD review of draft-ietf-netconf-restconf-13 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 14:16:20 -0000 This is a multi-part message in MIME format. --------------FDC3C9242E626E2B4010527E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, Here is my draft-ietf-netconf-restconf-13 AD review [sorry for the delay, it took longer than expected]. If some of the points have already been discussed, let me know. -https://github.com/netconf-wg/restconf/issues?q=is%3Aopen+is%3Aissue There are still open issues. I would have expected that all issues are closed. Should I be worried? - From the charter: The RESTCONF work will consider requirements suggested by the other working groups (for example I2RS). Are we good in terms of I2RS requirements for RESTCONF, if any? - section 1 RESTCONF is based on HTTP1.1 [RFC7230] What about HTTP2 [RFC7540]? I've seen some discussions on the NETCONF mailing but I'm unclear if RESTCONF would work with HTTP2. A few words are necessary IMO. background:https://www.ietf.org/mail-archive/web/netconf/current/msg08578.html I see in section 2.1 No other versions of HTTP are supported for use with RESTCONF. Do you mean: No other versions than HTTP 1.1 are supported for use with RESTCONF. So: HTTP2.0 MUST NOT be used with RESTCONF. If this is the case, some sort of justification is required. - section 1, editorial: OLD: The YANG language defines the syntax and semantics of datastore content, state data, protocol operations, and event notifications. NEW: The YANG language defines the syntax and semantics of datastore content, configuration, state data, protocol operations, and event notifications. Justification, to be more in line with RFC6020bis, which says: 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. - section 1 If a RESTCONF server is co-located with a NETCONF server, then there are protocol interactions to be considered, as described in Section 1.4 . The server MAY provide access to specific datastores using operation resources, as described inSection 3.6 . Terminology: RESTCONF server, NETCONF server, server. "Server" according to the terminology section is the RFC6241 definition, so the NETCONF server. I don't think that's right in this sentence. You should review all "server" instances in the doc, and/or potentially change the terminology. Maybe: Server is not specific, so NETCONF or RESTCONF server NETCONF server RESTCONF server Same issue with "client". - section 1.1.3 non-presence container (or NP-container) presence container (or P-container) As Lionel Morand mentioned in his OPS-DIR draft-ietf-netmod-rfc6020bis-11 review: LM: "non-presence container" is not defined anywhere in the document. I can assume that it refers to a container that does not have a "presence" statement. If it is, it could be good to: define the term in the section 3 and to extend the existing text in the section 7.5.5 - section 1.1.4: Sometimes the terms in that section are difficult to grasp without context, as some definitions don't explain what this term is for. For example: o operation resource: a resource with the media type "application/ yang.operation+xml" or "application/yang.operation+json". Except from the name itself, it doesn't tell me that this resource is linked to the "operations", meaning the RPC operations in YANG. For example: OLD: o schema resource: a resource with the media type "application/ yang". The YANG representation of the schema can be retrieved by the client with the GET method. NEW: o schema resource: a resource with the media type "application/ yang". The schema resource is used to retrieve the YANG representation of the schema by the client with the GET method. - Section 1.1.5 OLD: URI Template NEW: URI Template and Examples I would add that the examples throughout the document are based on a jukebox YANG data model, and that, even if the examples should be self contained, the full jukebox YANG data model is available in the appendix C Just one of the many justifications. See section 4.8.3 where this example comes out of the blue For example, assume the target resource is the "album" list. To retrieve only the "label" and "catalogue-number" of the "admin" container within an album, use: "fields=admin(label;catalogue-number)". - Section 1.2. >From the abstract: This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastores defined in NETCONF. >From section 1: This document defines an HTTP [RFC7230 ] based protocol called RESTCONF, for configuring data defined in YANG version 1 [RFC6020 ] or YANG version 1.1 [I-D.ietf-netmod-rfc6020bis ], using datastores defined in NETCONF [RFC6241 ]. ... The following figure shows the system components if a RESTCONF server is co-located with a NETCONF server: +-----------+ +-----------------+ | Web app | <-------> | | +-----------+ HTTP | network device | | | +-----------+ | +-----------+ | | NMS app | <-------> | | datastore | | +-----------+ NETCONF | +-----------+ | +-----------------+ The following figure shows the system components if a RESTCONF server is implemented in a device that does not have a NETCONF server: +-----------+ +-----------------+ | Web app | <-------> | | +-----------+ HTTP | network device | | | +-----------------+ So we don't use the datastores defined in NETCONF, but datastore concepts. See next point. - Section 1.2: RESTCONF does not need to mirror the full functionality of the NETCONF protocol, but it does need to be compatible with NETCONF. RESTCONF achieves this by implementing a subset of the interaction capabilities provided by the NETCONF protocol, for instance, by _eliminating _datastores and explicit locking. The abstract says: This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG,_using _the datastores defined in NETCONF. So on one side, we_eliminated _the datastore and on the other side, we_use _them. And the first figure in section 1.2 doesn't help. In case of HTTP and NETCONF access to the network device, does HTTP use the datastore? I guess you want to introduce the conceptual datastore concept. Maybe: This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG,_using _the datastore_concepts _defined in NETCONF. Introduction needs to be updated as well. - section 1.4, editorial OLD: If a datastore that would be modified by a RESTCONF operation has an active lock, the RESTCONF edit operation MUST fail with a "409 Conflict" status-line. NEW: If a datastore that would be modified by a RESTCONF operation has an active lock from a NETCONF client, the RESTCONF edit operation MUST fail with a "409 Conflict" status-line. We want to stress that there is no lock in RESTCONF - Section 1.5, editorial why "for example" in this sentence: For example, this document defines several query parameters in Section 4.8 . - section 3 All RESTCONF resource types are defined in this document except specific datastore contents, protocol operations, and event notifications. The syntax and semantics for these resource types are defined in YANG modules. What do you mean with "protocol operations"? * RPC and action: RESTCONF protocol operation (as defined in section 1.1.1) Section 3.3.2 is clearer with "data-model specific protocol operations supported by the server" * Operation resource as in S 3.6 * Operation (GET, POST) like in S 4.0 And the definition speaks of o operation: the conceptual RESTCONF operation for a message, derived from the HTTP method, request URI, headers, and message- body. The document should be clear and consistent with all instances of "(protocol) operations" Similarly in section 4: +----------+--------------------------------------------+ | RESTCONF | NETCONF | +----------+--------------------------------------------+ | OPTIONS | none | | HEAD | none | | GET | , | | POST | (operation="create") | | POST | invoke any operation | <===== | PUT | (operation="create/replace") | | PATCH | (operation="merge") | | DELETE | (operation="delete") | +----------+--------------------------------------------+ Which operation do we speak about here? It could be understood as NETCONF protocol operations... - section 3.x ** The API resource contains _the entry points_ for the RESTCONF datastore and _operation resources_. * * And I see in 3.3.1 that querying {+restconf}/data content requires application/yang.data+xml (or json), as opposed to .api+xml (or json) What about the querying {+restconf}/operations? does it require application/yang.api+xml or application/yang.data+xml ? https://tools.ietf.org/html/draft-ietf-netconf-restconf-13#section-3.3.2 should provide any example. My first guess was: since operations = API, I would have used application/yang.api+xml. Re-reading the draft, I now guess it's application/yang.data+xml (or json). The point is: what are the entry points for the operations resources? - Section 3.3.3, Editorial [RFC Editor Note: Adjust the date for ietf-yang-library below to the date in the published ietf-yang-library YANG module, and remove this note.] Make it clear that the date to be changed is 2016-04-09, as opposed to only: Mon, 23 Apr 2012 - 3.4. Datastore Resource The "{+restconf}/data" subtree represents the datastore resource type, which is a collection of configuration data and state data nodes. Should be "{+restconf}/datastore", right ? - "Last-Modified" This is one of those topics whose requirements are all over the place. This is confusing (at least to me) Section 3.4.1.1 The last change time is maintained and the "Last-Modified" ([RFC7232], Section 2.2 ) header is returned in the response for a retrieval request. The "If-Unmodified-Since" header can be used in edit operation requests to cause the server to reject the request if the resource has been modified since the specified timestamp. Section 3.5 For configuration data resources, the server MAY maintain a last- modified timestamp for the resource, and return the "Last-Modified" header when it is retrieved with the GET or HEAD methods. Section 9.1 The server MUST maintain a last-modified timestamp for this container, and return the "Last-Modified" header when this data node is retrieved with the GET or HEAD methods. Section 10.1 The server MUST maintain a last-modified timestamp for this container, and return the "Last-Modified" header when this data node is retrieved with the GET or HEAD methods. Section 10.1.1 The server SHOULD maintain a last-modified timestamp for each instance of this list entry, and return the "Last-Modified" header when this data node is retrieved with the GET or HEAD methods. and potentially some more sections At the minimum, we should have forward references from section 3.4.1.1 as it looks like self-contained. Same remark for entity-tag and section 3.4.1.2 - Section 3.5.1, editorial: container top { list list1 { key "key1 key2 key3"; ... list list2 { key "key4 key5"; ... leaf X { type string; } } } leaf-list Y { type uint32; } } For the above YANG definition, a target resource URI for leaf "X" would be encoded as follows (line wrapped for display purposes only): /restconf/data/example-top:top/list1=key1,key2,key3/ list2=key4,key5/X .... Mentions that "container top" is part of the example-top YANG data model - section 3.5.2. If the target of a GET method is a data node that represents a leaf that has a default value, and the leaf has not been configured yet, the server MUST return the default value that is in use by the server. I guess that it depends on the default handing mode. What about trim? ref:https://tools.ietf.org/html/rfc6243#section-3.2 - Section 3.6 OLD: If the "rpc" or "action" statement has an "input" section, then a message-body MAY be sent by the client in the request, otherwise the request message MUST NOT include a message-body. If the "input" objcet tree contains mandatory parameters, then a message-body MUST be sent by the client. NEW: If the "rpc" or "action" statement has an "input" section and the "input" object tree contains mandatory parameters, then a message-body MUST be sent by the client in the request. If the "rpc" or "action" statement has an "input" section and the "input" object tree doesn't contain mandatory parameters, then a message-body MAY be sent by the client in the request. If the "rpc" or "action" statement has no "input" section, the request message MUST NOT include a message-body. - section 3.6 If the operation is invoked without errors, and if the "rpc" or "action" statement has an "output" section, then a message-body MAY be sent by the server in the response, otherwise the response message MUST NOT include a message-body in the response message, and MUST send a "204 No Content" status-line instead. First, I don't understand the first MAY. I would have thought it would be a MUST. Second, "MUST NOT include a message-body in the response message, and MUST send a "204 No Content" status-line instead." So the errors are not part of the message-body? Section 7.1 says: then the server SHOULD send a response message-body containing the information described by the "errors" container definition within the YANG moduleSection 8 And third, message body or message-body. The document uses both. - RFC5277 is a normative reference. I guess that pub/sub will obsolete RFC5277. So we would have to update this RESTCONF RFC-to-be with the pub/sub publication? - Section 4, editorial OLD: The NETCONF "remove" operation attribute is not supported by the HTTP DELETE method. NEW The NETCONF "remove" operation attribute is not supported by the HTTP DELETE method. - Section 4.4.1, Editorial: OLD: The "insert" and "point" query NEW: The "insert" (Section 4.8.5 ) and "point" (Section 4.8.6 ) query - Section 4.8 RESTCONF Query Parameters, HEAD is missing. Section 4.2: The same query parameters supported by the GET method are supported by the HEAD method. - Section 4.8 I see: o Each parameter can appear at most once in a request URI. In section 4.8.2, I see: More than one "depth" query parameter MUST NOT appear in a request. If more than one instance is present, then a "400 Bad Request" status-line MUST be returned by the server. In section 4.8.3, I see: More than one "fields" query parameter MUST NOT appear in a request. If more than one instance is present, then a "400 Bad Request" status-line MUST be returned by the server. etc. You could include the generic specifications, along with the RFC2119 language, in section 4.8, as opposed to every 4.8.x section. - section 4.8.4 The format of this parameter is an XPath 1.0 expression, and is evaluated in the following context: o The set of namespace declarations is the set of prefix and namespace pairs for all supported YANG modules, where the prefix is the YANG module name, and the namespace is as defined by the "namespace" statement in the YANG module. o The function library is the core function library defined in XPath 1.0. RFC 6241 says: o The function library is the core function library, plus any functions defined by the data model. Should this be aligned? - Section 4.6.1 The plain patch mechanism merges the contents of the message body with the target resource. If the target resource is a datastore resource (seeSection 3.4 ), the message body MUST be either application/yang.datastore+xml or application/yang.datastore+json. If then the target resource is a data resource (seeSection 3.5 ), then the message body MUST be either application/yang.data+xml or application/yang.data+json. Something I completely missed (and only understood when I spoke to Martin). To edit a resource, we have two ways: 1. PATCH on the datastore resource like in appendix D.2.3 2. PATCH on the data resource, with the full path. To map the example in D.2.3, something like PATCH /restconf/data HTTP/1.1 Host: example.com Content-Type: application/yang.data+xml "http://x.x.x.x:yyyy/restconf/data/jukebox:library" Both examples should be illustrated next to each others, and the text in 4.6 or 4.6.1 clear. - Section 4.8.7 What is this "notification replay feature"? I searched for "notification replay" in the doc, without luck. I finally found it, inhttps://tools.ietf.org/html/rfc5277#section-3.3, from the reference link: leaf replay-support { type boolean; description "Indicates if replay buffer supported for this stream. If 'true', then the server MUST support the 'start-time' and 'stop-time' query parameters for this stream."; reference "RFC 5277, Section 3.4 , element."; } You should really add the references in section 4.8.7 and 8, toRFC 5277, Section 3.4 and to the replay-support - Section 5.1, editorial //?# ^ ^ ^ ^ ^ | | | | | method entry resource query fragment M M O O I The method points to a space. Indent the line starting with - section 5.2 Content is encoded in either JSON or XML format. There are no capabilities to discover this, right? So the only solution is for a client to test it, right? How does a client know this? Trying is the only solution? Do we want to explain this, and show an example, for example with the HEAD method? Btw, I hope that we request to support JSON or XML is for the entire series of resource, right? Do we want to make it clear? +-----------+---------------------------------+ | Resource | Media Type | +-----------+---------------------------------+ | API | application/yang.api+xml | | | application/yang.api+json | | Datastore | application/yang.datastore+xml | | | application/yang.datastore+json | | Data | application/yang.data+xml | | | application/yang.data+json | | [none] | application/yang.errors+xml | | | application/yang.errors+json | | Operation | application/yang.operation+xml | | | application/yang.operation+json | | Schema | application/yang | +-----------+---------------------------------+ - 5.3.2 Json MetaData Encoding Example Note thatRFC 6243 defines the "default" attribute with XSD, not YANG, so_the YANG module name has to be assigned manually_. The value "ietf-netconf-with-defaults" is assigned for JSON meta-data encoding. I don't understand "_the YANG module name has to be assigned manually_" Also, In section 5.3: The RESTCONF protocol needs to retrieve the same meta-data that is used in the NETCONF protocol. Information about default leafs, last- modified timestamps, etc. are_commonly _used to annotate representations of the datastore contents._This meta-data_ is not defined in the YANG schema because_it applies to the datastore_, and is common across all data nodes. => I don't understand:_This meta-data_ is not defined in the YANG schema because_it applies to the datastore_, and is common across all data nodes. _This _meta-data relates to default leafs and last-modified timestamps. The last-modified timestamps apply to more than just the datastore. Also: _This information is encoded as attributes in XML_. JSON encoding of meta-data is defined in [I-D.ietf-netmod-yang-metadata ]. You want to express something like this: With the XML encoding, the metadata is encoded as attributes in XML With the JSON encoding, the metadata is encoded as specified in [I-D.ietf-netmod-yang-metadata ]. btw, use a single convention throughout the doc: meta-data or metadata draft-ietf-netmod-yang-metadata uses metadata - 5.4 Each message represents some sort of resource access. An HTTP "status-line" header line is returned for each request. If a 4xx or 5xx range status code is returned in the status-line, then the error information will be returned in the response, according to the format defined inSection 7.1 . Why only 4xx and 5xx? - 6.3, editorial OLD: A RESTCONF client MAY request the server compress the events using the HTTP header field "Accept-Encoding". For instance: NEW: A RESTCONF client MAY request that the server compress the events using the HTTP header field "Accept-Encoding". For instance:- - Section 8 container operations { description "Container for all operation resources (application/yang.operation), Each resource is represented as an empty leaf with the name of the RPC operation from the YANG rpc statement. E.g.; POST /restconf/operations/show-log-errors leaf show-log-errors { type empty; } "; } I've been confused by this example, as at first glance I didn't consider a show-something as an operation. You might be thinking of a more obvious example: Reset-xxx is one - Section 13. Acknowledgment and "contributions" term. acknowledged persons for their contributions: do we speak about contributors, which has got a special meaning in terms of IPR? If not, let's avoid the "contributions" term - Good job with the appendix C and D. The examples are very useful. - Appendix D.1, editorial _The client may start by retrieving _the top-level API resource, using the entry point URI "{+restconf}". If this is a typical operational example, I guess you want to start by retrieving: GET /.well-known/host-meta HTTP/1.1 - Appendix D.1.2 An example of deviations would be welcome (even if this is ietf-yang-library, which is a different dra - D.3.3 I guess this request should not report the module-set-id? GET /restconf/data?fields=ietf-yang-library:modules-state/ module(name;revision) HTTP/1.1 ... { "ietf-yang-library:modules-state": { "module-set-id": "cb4c422111a779e1eed55bffc8d6b46a3a0999e2", "module": [ - Since we have many examples around around example-jukebox, this should pass compilation, right? pyang --ietf example-jukebox.yang example-jukebox.yang:1: error: expected keyword "namespace" as child to "module" example-jukebox.yang:1: error: expected keyword "prefix" as child to "module" example-jukebox.yang:1: warning: RFC 6087: 4.1: the module name should start with one of the strings "ietf-" or "iana-" example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" must have a "contact" substatement example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" must have a "organization" substatement example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" must have a "description" substatement example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" must have a "revision" substatement What was the agreed convention for example modules that should pass compilation? - We advice YANG data models to include a YANG tree diagram, like you did for "ietf-restconf-monitoring" The RESTCONF module doesn't. Obviously, pyang -f tree doesn't produce anything, but make it clear with some text, so that the readers don't believe it's an omission. - Security Considerations. Please includehttps://trac.tools.ietf.org/area/ops/trac/wiki/yang-security-guidelines - idnit complains about a few things. - [] in json encoding of list. For example, PUT /restconf/data/example-jukebox:jukebox/ library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1 Host: example.com Content-Type: application/yang.data+json { "example-jukebox:album" : { "name" : "Wasting Light", "genre" : "example-jukebox:alternative", "year" : 2011 } } Don't we need [] for the album list? list album { key name; description "Represents one album resource within one artist resource, within the jukebox library."; leaf name { type string { length "1 .. max"; } description "The name of the album."; } leaf genre { type identityref { base genre; } description "The genre identifying the type of music on the album."; } leaf year { type uint16 { range "1900 .. max"; } description "The year the album was released"; } See https://tools.ietf.org/html/draft-ietf-netmod-yang-json-10#section-5.4 list bar { key foo; leaf foo { type uint8; } leaf baz { type string; } } the following is a valid JSON-encoded instance: "bar": [ { "foo": 123, "baz": "zig" }, { "baz": "zag", "foo": 0 } ] Regards, Benoit (OPS AD) --------------FDC3C9242E626E2B4010527E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Dear all,

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

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

Are we good in terms of I2RS requirements for RESTCONF, if any?

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

- section 1, editorial:
OLD:
   The YANG language defines the syntax and semantics
   of datastore content, state data, protocol operations, and event
   notifications.

NEW:
   The YANG language defines the syntax and semantics
   of datastore content, configuration, state data, protocol operations, 
   and event notifications.

Justification, to be more in line with RFC6020bis, which says:
   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. 

- section 1
   If a RESTCONF server is co-located with a NETCONF server, then there
   are protocol interactions to be considered, as described in
   Section 1.4.  The server MAY provide access to specific datastores
   using operation resources, as described in Section 3.6.

Terminology: RESTCONF server, NETCONF server, server.
"Server" according to the terminology section is the RFC6241 definition, so the NETCONF server.
I don't think that's right in this sentence.
You should review all "server" instances in the doc, and/or potentially change the terminology.
Maybe:
	Server is not specific, so NETCONF or RESTCONF server
	NETCONF server
	RESTCONF server

Same issue with "client".

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

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

LM: "non-presence container" is not defined anywhere in the document.
    I can assume that it refers to a container that does not have a 
    "presence" statement. If it is, it could be good to:
    define the term in the section 3 and to extend the existing text in 
    the section 7.5.5
- section 1.1.4:
Sometimes the terms in that section are difficult to grasp without context, as some definitions don't explain what this term is for.
For example: 
   o  operation resource: a resource with the media type "application/
      yang.operation+xml" or "application/yang.operation+json".

Except from the name itself, it doesn't tell me that this resource is linked to the "operations", meaning the RPC operations in YANG.

For example:
OLD:
   o  schema resource: a resource with the media type "application/
      yang".  The YANG representation of the schema can be retrieved by
      the client with the GET method.
NEW:
   o  schema resource: a resource with the media type "application/
      yang".  The schema resource is used to retrieve the YANG representation of the schema by
      the client with the GET method.

- Section 1.1.5

OLD: URI Template
NEW: URI Template and Examples

I would add that the examples throughout the document are based on a jukebox YANG data model, 
and that, even if the examples should be self contained, the full jukebox YANG data model is 
available in the appendix C

Just one of the many justifications. See section 4.8.3 where this example comes out of the blue
   For example, assume the target resource is the "album" list.  To
   retrieve only the "label" and "catalogue-number" of the "admin"
   container within an album, use:
   "fields=admin(label;catalogue-number)".

- Section 1.2.
>From the abstract:
   This document describes an HTTP-based protocol that provides a
   programmatic interface for accessing data defined in YANG, using the
   datastores defined in NETCONF.

>From section 1:
   This document defines an HTTP [RFC7230] based protocol called
   RESTCONF, for configuring data defined in YANG version 1 [RFC6020] or
   YANG version 1.1 [I-D.ietf-netmod-rfc6020bis], using datastores
   defined in NETCONF [RFC6241].
 ...

   The following figure shows the system components if a RESTCONF server
   is co-located with a NETCONF server:

      +-----------+           +-----------------+
      |  Web app  | <-------> |                 |
      +-----------+   HTTP    | network device  |
                              |                 |
      +-----------+           |   +-----------+ |
      |  NMS app  | <-------> |   | datastore | |
      +-----------+  NETCONF  |   +-----------+ |
                              +-----------------+

   The following figure shows the system components if a RESTCONF server
   is implemented in a device that does not have a NETCONF server:

      +-----------+           +-----------------+
      |  Web app  | <-------> |                 |
      +-----------+   HTTP    | network device  |
                              |                 |
                              +-----------------+

So we don't use the datastores defined in NETCONF, but datastore concepts.
See next point.

- 
Section 1.2:
   RESTCONF does not need to mirror the full functionality of the
   NETCONF protocol, but it does need to be compatible with NETCONF.
   RESTCONF achieves this by implementing a subset of the interaction
   capabilities provided by the NETCONF protocol, for instance, by
   eliminating datastores and explicit locking.

The abstract says:
   This document describes an HTTP-based protocol that provides a
   programmatic interface for accessing data defined in YANG, using the
   datastores defined in NETCONF.

So on one side, we eliminated the datastore and on the other side, we use them.
And the first figure in section 1.2 doesn't help. In case of HTTP and NETCONF access to the network device, does HTTP use the datastore?
I guess you want to introduce the conceptual datastore concept.
Maybe: 
   This document describes an HTTP-based protocol that provides a
   programmatic interface for accessing data defined in YANG, using the
   datastore concepts defined in NETCONF.

Introduction needs to be updated as well.

- section 1.4, editorial
OLD:
   If a datastore that would be modified by a RESTCONF operation has an
   active lock, the RESTCONF edit operation MUST fail with a "409
   Conflict" status-line. 
NEW:
   If a datastore that would be modified by a RESTCONF operation has an
   active lock from a NETCONF client, the RESTCONF edit operation MUST 
   fail with a "409 Conflict" status-line.

We want to stress that there is no lock in RESTCONF

- Section 1.5, editorial
why "for example" in this sentence:
   For
   example, this document defines several query parameters in
   Section 4.8. 

- section 3
   All RESTCONF resource types are defined in this document except
   specific datastore contents, protocol operations, and event
   notifications.  The syntax and semantics for these resource types are
   defined in YANG modules.

What do you mean with "protocol operations"? 
* RPC and action: RESTCONF protocol operation (as defined in section 1.1.1)
Section 3.3.2 is clearer with "data-model specific protocol operations supported by the server"
* Operation resource as in S 3.6
* Operation (GET, POST) like in S 4.0
And the definition speaks of 
   o  operation: the conceptual RESTCONF operation for a message,
      derived from the HTTP method, request URI, headers, and message-
      body.
The document should be clear and consistent with all instances of "(protocol) operations"

Similarly in section 4:

         +----------+--------------------------------------------+
         | RESTCONF | NETCONF                                    |
         +----------+--------------------------------------------+
         | OPTIONS  | none                                       |
         | HEAD     | none                                       |
         | GET      | <get-config>, <get>                        |
         | POST     | <edit-config> (operation="create")         |
         | POST     | invoke any operation                       |   <=====
         | PUT      | <edit-config> (operation="create/replace") |
         | PATCH    | <edit-config> (operation="merge")          |
         | DELETE   | <edit-config> (operation="delete")         |
         +----------+--------------------------------------------+

Which operation do we speak about here? It could be understood as NETCONF protocol operations...

- section 3.x

    The API resource contains the entry points for the RESTCONF datastore and operation resources.

And I see in 3.3.1 that querying {+restconf}/data content requires application/yang.data+xml (or json), as opposed to .api+xml (or json)
What about the querying {+restconf}/operations? does it require application/yang.api+xml or application/yang.data+xml ?
https://tools.ietf.org/html/draft-ietf-netconf-restconf-13#section-3.3.2 should provide any example. My first guess was: since operations = API, I would have used application/yang.api+xml. Re-reading the draft, I now guess it's application/yang.data+xml (or json). The point is: what are the entry points for the operations resources?
- Section 3.3.3, Editorial

[RFC Editor Note: Adjust the date for ietf-yang-library below to the
   date in the published ietf-yang-library YANG module, and remove this
   note.]

Make it clear that the date to be changed is 2016-04-09, as opposed to only: 
Mon, 23 Apr 2012
- 
3.4. Datastore Resource 
   The "{+restconf}/data" subtree represents the datastore resource
   type, which is a collection of configuration data and state data
   nodes.
Should be  "{+restconf}/datastore", right ?
- "Last-Modified"
This is one of those topics whose requirements are all over the place. This is confusing (at least to me)

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

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

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

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

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

and potentially some more sections
At the minimum, we should have forward references from section 3.4.1.1 as it looks like self-contained.


Same remark for entity-tag and section 3.4.1.2

- Section 3.5.1, editorial:

   container top {
       list list1 {
           key "key1 key2 key3";
            ...
            list list2 {
                key "key4 key5";
                ...
                leaf X { type string; }
            }
        }
        leaf-list Y {
          type uint32;
        }
    }

   For the above YANG definition, a target resource URI for leaf "X"
   would be encoded as follows (line wrapped for display purposes only):

    /restconf/data/example-top:top/list1=key1,key2,key3/
       list2=key4,key5/X

    ....


Mentions that "container top" is part of the example-top YANG data model

- section 3.5.2.

   If the target of a GET method is a data node that represents a leaf
   that has a default value, and the leaf has not been configured yet,
   the server MUST return the default value that is in use by the
   server.

I guess that it depends on the default handing mode.
What about trim? ref: https://tools.ietf.org/html/rfc6243#section-3.2

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

NEW:

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

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

- section 3.6
   If the operation is invoked without errors, and if the "rpc" or
   "action" statement has an "output" section, then a message-body MAY
   be sent by the server in the response, otherwise the response message
   MUST NOT include a message-body in the response message, and MUST
   send a "204 No Content" status-line instead.

First, I don't understand the first MAY. I would have thought it would be a MUST. 
Second, "MUST NOT include a message-body in the response message, and MUST send a "204 No Content" status-line instead."
So the errors are not part of the message-body? Section 7.1 says: 
   then the server SHOULD send a response
   message-body containing the information described by the "errors"
   container definition within the YANG module Section 8
And third, message body or message-body. The document uses both.

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

- Section 4, editorial
OLD:
   The NETCONF "remove" operation attribute is not supported by the HTTP
   DELETE method.
NEW 
   The <edit-config> NETCONF "remove" operation attribute is not supported by the HTTP
   DELETE method.

- Section 4.4.1, Editorial:
OLD: The "insert" and "point" query
NEW: The "insert" (Section 4.8.5) and "point" (Section 4.8.6) query

- Section 4.8
RESTCONF Query Parameters, HEAD is missing.
Section 4.2:

The same query parameters supported by the GET method
are supported by the HEAD method.
- Section 4.8
I see: 
   o  Each parameter can appear at most once in a request URI.
In section 4.8.2, I see:
   More than one "depth" query parameter MUST NOT appear in a request.
   If more than one instance is present, then a "400 Bad Request"
   status-line MUST be returned by the server.
In section 4.8.3, I see:
   More than one "fields" query parameter MUST NOT appear in a request.
   If more than one instance is present, then a "400 Bad Request"
   status-line MUST be returned by the server.
etc.

You could include the generic specifications, along with the RFC2119 language, in section 4.8, as opposed to every 4.8.x section.

- section 4.8.4
   The format of this parameter is an XPath 1.0 expression, and is
   evaluated in the following context:
   o  The set of namespace declarations is the set of prefix and
      namespace pairs for all supported YANG modules, where the prefix
      is the YANG module name, and the namespace is as defined by the
      "namespace" statement in the YANG module.

   o  The function library is the core function library defined in XPath
      1.0.

RFC 6241 says:
   o  The function library is the core function library, plus any
      functions defined by the data model.

Should this be aligned?


- Section 4.6.1
   The plain patch mechanism merges the contents of the message body
   with the target resource.  If the target resource is a datastore
   resource (see Section 3.4), the message body MUST be either
   application/yang.datastore+xml or application/yang.datastore+json.
   If then the target resource is a data resource (see Section 3.5),
   then the message body MUST be either application/yang.data+xml or
   application/yang.data+json.

Something I completely missed (and only understood when I spoke to Martin).
To edit a resource, we have two ways:
 1. PATCH on the datastore resource like in appendix D.2.3
 2. PATCH on the data resource, with the full path.
    To map the example in D.2.3, something like
 	PATCH /restconf/data HTTP/1.1
   	  Host: example.com
          Content-Type: application/yang.data+xml
          "http://x.x.x.x:yyyy/restconf/data/jukebox:library"
Both examples should be illustrated next to each others, and the text in 4.6 or 4.6.1 clear.



- Section 4.8.7
What is this "notification replay feature"?
I searched for "notification replay" in the doc, without luck.
I finally found it, in https://tools.ietf.org/html/rfc5277#section-3.3, from the reference link:
       leaf replay-support {
             type boolean;
             description
               "Indicates if replay buffer supported for this stream.
                If 'true', then the server MUST support the 'start-time'
                and 'stop-time' query parameters for this stream.";
             reference
               "RFC 5277, Section 3.4, <replaySupport> element.";
           }
You should really add the references in section 4.8.7 and 8, to RFC 5277, Section 3.4 and to the replay-support

- Section 5.1, editorial
   <OP> /<restconf>/<path>?<query>#<fragment>

         ^       ^        ^       ^         ^
         |       |        |       |         |
       method  entry  resource  query    fragment

         M       M        O        O         I

The method points to a space. Indent the line starting with <OP>


- section 5.2
Content is encoded in either JSON or XML format.
There are no capabilities to discover this, right? 
So the only solution is for a client to test it, right?
How does a client know this? Trying is the only solution? 
Do we want to explain this, and show an example, for example with the HEAD method?
Btw, I hope that we request to support JSON or XML is for the entire series of resource, right? 
Do we want to make it clear?
              +-----------+---------------------------------+
              | Resource  | Media Type                      |
              +-----------+---------------------------------+
              | API       | application/yang.api+xml        |
              |           | application/yang.api+json       |
              | Datastore | application/yang.datastore+xml  |
              |           | application/yang.datastore+json |
              | Data      | application/yang.data+xml       |
              |           | application/yang.data+json      |
              | [none]    | application/yang.errors+xml     |
              |           | application/yang.errors+json    |
              | Operation | application/yang.operation+xml  |
              |           | application/yang.operation+json |
              | Schema    | application/yang                |
              +-----------+---------------------------------+

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

I don't understand "the YANG module name has to be assigned manually"

Also, In section 5.3:

   The RESTCONF protocol needs to retrieve the same meta-data that is
   used in the NETCONF protocol.  Information about default leafs, last-
   modified timestamps, etc. are commonly used to annotate
   representations of the datastore contents.  This meta-data is not
   defined in the YANG schema because it applies to the datastore, and
   is common across all data nodes.

=> I don't understand: This meta-data is not
   defined in the YANG schema because it applies to the datastore, and
   is common across all data nodes.
This meta-data relates to default leafs and last-modified timestamps. 
The last-modified timestamps apply to more than just the datastore.

Also:
   This information is encoded as attributes in XML.  JSON encoding of
   meta-data is defined in [I-D.ietf-netmod-yang-metadata].

You want to express something like this:
With the XML encoding, the metadata is encoded as attributes in XML
With the JSON encoding, the metadata is encoded as specified in [I-D.ietf-netmod-yang-metadata].

btw, use a single convention throughout the doc: meta-data or metadata
draft-ietf-netmod-yang-metadata uses metadata 


 - 5.4

   Each message represents some sort of resource access.  An HTTP
   "status-line" header line is returned for each request.  If a 4xx or
   5xx range status code is returned in the status-line, then the error
   information will be returned in the response, according to the format
   defined in Section 7.1.

Why only 4xx and 5xx?

- 6.3, editorial
OLD: 
   A RESTCONF client MAY request the server compress the events using
   the HTTP header field "Accept-Encoding".  For instance:
NEW:
   A RESTCONF client MAY request that the server compress the events using
   the HTTP header field "Accept-Encoding".  For instance:- 

-
Section 8
 container operations {
           description
             "Container for all operation resources
             (application/yang.operation),

              Each resource is represented as an empty leaf with the
              name of the RPC operation from the YANG rpc statement.

              E.g.;

                 POST /restconf/operations/show-log-errors

                 leaf show-log-errors {
                   type empty;
                 }
             ";
         }

I've been confused by this example, as at first glance I didn't consider a show-something as an operation.
You might be thinking of a more obvious example: Reset-xxx is one

 - Section 13.
Acknowledgment and "contributions" term.
acknowledged persons for their contributions: do we speak about contributors, which has got a special meaning in terms of IPR?
If not, let's avoid the "contributions" term

- Good job with the appendix C and D. The examples are very useful.

- Appendix D.1, editorial

   The client may start by retrieving the top-level API resource, using
   the entry point URI "{+restconf}".
 
If this is a typical operational example, I guess you want to start by retrieving:
   GET /.well-known/host-meta HTTP/1.1

- Appendix D.1.2
An example of deviations would be welcome (even if this is ietf-yang-library, which is a different dra

-  D.3.3
I guess this request should not report the module-set-id?
   
 GET /restconf/data?fields=ietf-yang-library:modules-state/
       module(name;revision) HTTP/1.1

    ...

    
     {
        "ietf-yang-library:modules-state": {
          "module-set-id": "cb4c422111a779e1eed55bffc8d6b46a3a0999e2",
          "module": [

  

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

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

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

- We advice YANG data models to include a YANG tree diagram, like you did for "ietf-restconf-monitoring" 
The RESTCONF module doesn't. Obviously, pyang -f tree doesn't produce anything, but make it clear with some text, so that the readers don't believe it's an omission.

- Security Considerations.
Please include https://trac.tools.ietf.org/area/ops/trac/wiki/yang-security-guidelines

- idnit complains about a few things.

- [] in json encoding of list.
For example,
      PUT /restconf/data/example-jukebox:jukebox/
          library/artist=Foo%20Fighters/album=Wasting%20Light   HTTP/1.1
      Host: example.com
      Content-Type: application/yang.data+json

      {
        "example-jukebox:album" : {
          "name" : "Wasting Light",
          "genre" : "example-jukebox:alternative",
          "year" : 2011
        }
      }


Don't we need [] for the album list? 

           list album {
              key name;

              description
                "Represents one album resource within one
                 artist resource, within the jukebox library.";

              leaf name {
                type string {
                  length "1 .. max";
                }
                description "The name of the album.";
              }

              leaf genre {
                type identityref { base genre; }
                description
                  "The genre identifying the type of music on
                   the album.";
              }

              leaf year {
                type uint16 {
                  range "1900 .. max";
                }
                description "The year the album was released";
              }



See 

https://tools.ietf.org/html/draft-ietf-netmod-yang-json-10#section-5.4
  list bar {
     key foo;
     leaf foo {
       type uint8;
     }
     leaf baz {
       type string;
     }
   }

   the following is a valid JSON-encoded instance:

   "bar": [
     {
       "foo": 123,
       "baz": "zig"
     },
     {
       "baz": "zag",
       "foo": 0
     }
   ]



Regards, Benoit (OPS AD)
--------------FDC3C9242E626E2B4010527E-- From nobody Tue May 31 07:45:11 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7060112D5CB for ; Tue, 31 May 2016 07:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.426 X-Spam-Level: X-Spam-Status: No, score=-8.426 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=-1.426] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 084OZht4zPWb for ; Tue, 31 May 2016 07:45:05 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1275B12D568 for ; Tue, 31 May 2016 07:45:05 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:ad00:92d5:f077:a52a] (unknown [IPv6:2001:718:1a02:1:ad00:92d5:f077:a52a]) by mail.nic.cz (Postfix) with ESMTPSA id 927A460831; Tue, 31 May 2016 16:45:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1464705903; bh=E8MEYO0Msq20LVJYoszlPbVwuyaMM+U6Gw8MDxnKLS0=; h=From:Date:To; b=MRKH27DVkdQ3sdSjzw9WhsC20G9VjwxEdMATk/UF+/PctPHk8Ls5B3Cvx1Op0yLsC 5+rNamtQcfNOkGbjo4jUam8sy5d+JLa2CWhLpSbsUhyB0N+Jz1BW3kO/UoR+3vAV3j 3nT8uwv+DhmgFTZCgUClXoBPT9vAQ+JC3Df3A5rw= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: <2cb94ab9-9c1d-77ae-eb8b-2d41ba39f495@cisco.com> Date: Tue, 31 May 2016 16:45:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5612db74-b32b-164d-c71c-daf669e6b142@cisco.com> <2cb94ab9-9c1d-77ae-eb8b-2d41ba39f495@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf Subject: Re: [Netconf] AD review of draft-ietf-netconf-restconf-13 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 14:45:09 -0000 > On 31 May 2016, at 16:15, Benoit Claise wrote: >=20 > Dear all, >=20 > Here is my draft-ietf-netconf-restconf-13 AD review=20 > [sorry for the delay, it took longer than expected]. > If some of the points have already been discussed, let me know. >=20 > - https://github.com/netconf-wg/restconf/issues?q=3Dis%3Aopen+is%3Aissue= >=20 > There are still open issues. I would have expected that all issues are = closed. Should I be worried? =20 >=20 > - =46rom the charter: > The RESTCONF work will consider requirements suggested by the other = working groups=20 > (for example I2RS). >=20 > Are we good in terms of I2RS requirements for RESTCONF, if any? >=20 > - section 1 > RESTCONF is based on HTTP1.1 [RFC7230] > What about HTTP2 [RFC7540]? FWIW, we are working on RESTCONF over HTTP/2 and we see no reason why it = shouldn't work. HTTP/2 didn't change semantics of HTTP operations. Lada > =20 > I've seen some discussions on the NETCONF mailing but I'm unclear if = RESTCONF would work with HTTP2. > A few words are necessary IMO. > background:=20 > https://www.ietf.org/mail-archive/web/netconf/current/msg08578.html >=20 > I see in section 2.1 > No other versions of HTTP are supported for use with RESTCONF. > Do you mean: > No other versions than HTTP 1.1 are supported for use with = RESTCONF. > So: > HTTP2.0 MUST NOT be used with RESTCONF. > If this is the case, some sort of justification is required. >=20 > - section 1, editorial: > OLD: > The YANG language defines the syntax and semantics > of datastore content, state data, protocol operations, and event > notifications. >=20 > NEW: > The YANG language defines the syntax and semantics > of datastore content, configuration, state data, protocol = operations,=20 > and event notifications. >=20 > Justification, to be more in line with RFC6020bis, which says: > 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.=20 >=20 > - section 1 > If a RESTCONF server is co-located with a NETCONF server, then = there > are protocol interactions to be considered, as described in > =20 > Section 1.4 > . The server MAY provide access to specific datastores > using operation resources, as described in=20 > Section 3.6 > . >=20 > Terminology: RESTCONF server, NETCONF server, server. > "Server" according to the terminology section is the RFC6241 = definition, so the NETCONF server. > I don't think that's right in this sentence. > You should review all "server" instances in the doc, and/or = potentially change the terminology. > Maybe: > Server is not specific, so NETCONF or RESTCONF server > NETCONF server > RESTCONF server >=20 > Same issue with "client". >=20 > - section 1.1.3 > non-presence container (or NP-container) > presence container (or P-container) >=20 > As Lionel Morand mentioned in his OPS-DIR = draft-ietf-netmod-rfc6020bis-11 review: >=20 > LM: "non-presence container" is not defined anywhere in the document. > I can assume that it refers to a container that does not have a=20 > "presence" statement. If it is, it could be good to: > define the term in the section 3 and to extend the existing text = in=20 > the section 7.5.5 >=20 > - section 1.1.4: > Sometimes the terms in that section are difficult to grasp without = context, as some definitions don't explain what this term is for. > For example:=20 > o operation resource: a resource with the media type "application/ > yang.operation+xml" or "application/yang.operation+json". >=20 > Except from the name itself, it doesn't tell me that this resource is = linked to the "operations", meaning the RPC operations in YANG. >=20 > For example: > OLD: > o schema resource: a resource with the media type "application/ > yang". The YANG representation of the schema can be retrieved = by > the client with the GET method. > NEW: > o schema resource: a resource with the media type "application/ > yang". The schema resource is used to retrieve the YANG = representation of the schema by > the client with the GET method. >=20 > - Section 1.1.5 >=20 > OLD: URI Template > NEW: URI Template and Examples >=20 > I would add that the examples throughout the document are based on a = jukebox YANG data model,=20 > and that, even if the examples should be self contained, the full = jukebox YANG data model is=20 > available in the appendix C >=20 > Just one of the many justifications. See section 4.8.3 where this = example comes out of the blue > For example, assume the target resource is the "album" list. To > retrieve only the "label" and "catalogue-number" of the "admin" > container within an album, use: > "fields=3Dadmin(label;catalogue-number)". >=20 > - Section 1.2. > >=46rom the abstract: > This document describes an HTTP-based protocol that provides a > programmatic interface for accessing data defined in YANG, using = the > datastores defined in NETCONF. >=20 > >=46rom section 1: > This document defines an HTTP [ > RFC7230 > ] based protocol called > RESTCONF, for configuring data defined in YANG version 1 [ > RFC6020 > ] or > YANG version 1.1 [ > I-D.ietf-netmod-rfc6020bis > ], using datastores > defined in NETCONF [ > RFC6241 > ]. > ... >=20 > The following figure shows the system components if a RESTCONF = server > is co-located with a NETCONF server: >=20 > +-----------+ +-----------------+ > | Web app | <-------> | | > +-----------+ HTTP | network device | > | | > +-----------+ | +-----------+ | > | NMS app | <-------> | | datastore | | > +-----------+ NETCONF | +-----------+ | > +-----------------+ >=20 > The following figure shows the system components if a RESTCONF = server > is implemented in a device that does not have a NETCONF server: >=20 > +-----------+ +-----------------+ > | Web app | <-------> | | > +-----------+ HTTP | network device | > | | > +-----------------+ >=20 > So we don't use the datastores defined in NETCONF, but datastore = concepts. > See next point. >=20 > -=20 > Section 1.2: > RESTCONF does not need to mirror the full functionality of the > NETCONF protocol, but it does need to be compatible with NETCONF. > RESTCONF achieves this by implementing a subset of the interaction > capabilities provided by the NETCONF protocol, for instance, by > =20 > eliminating=20 > datastores and explicit locking. >=20 > The abstract says: > This document describes an HTTP-based protocol that provides a > programmatic interface for accessing data defined in YANG,=20 > using=20 > the > datastores defined in NETCONF. >=20 > So on one side, we=20 > eliminated the datastore and on the other side, we use=20 > them. > And the first figure in section 1.2 doesn't help. In case of HTTP and = NETCONF access to the network device, does HTTP use the datastore? > I guess you want to introduce the conceptual datastore concept. > Maybe:=20 > This document describes an HTTP-based protocol that provides a > programmatic interface for accessing data defined in YANG,=20 > using=20 > the > datastore=20 > concepts=20 > defined in NETCONF. >=20 > Introduction needs to be updated as well. >=20 > - section 1.4, editorial > OLD: > If a datastore that would be modified by a RESTCONF operation has = an > active lock, the RESTCONF edit operation MUST fail with a "409 > Conflict" status-line.=20 > NEW: > If a datastore that would be modified by a RESTCONF operation has = an > active lock from a NETCONF client, the RESTCONF edit operation MUST=20= > fail with a "409 Conflict" status-line. >=20 > We want to stress that there is no lock in RESTCONF >=20 > - Section 1.5, editorial > why "for example" in this sentence: > For > example, this document defines several query parameters in > =20 > Section 4.8 > .=20 >=20 > - section 3 > All RESTCONF resource types are defined in this document except > specific datastore contents, protocol operations, and event > notifications. The syntax and semantics for these resource types = are > defined in YANG modules. >=20 > What do you mean with "protocol operations"?=20 > * RPC and action: RESTCONF protocol operation (as defined in section = 1.1.1) > Section 3.3.2 is clearer with "data-model specific protocol operations = supported by the server" > * Operation resource as in S 3.6 > * Operation (GET, POST) like in S 4.0 > And the definition speaks of=20 > o operation: the conceptual RESTCONF operation for a message, > derived from the HTTP method, request URI, headers, and message- > body. > The document should be clear and consistent with all instances of = "(protocol) operations" >=20 > Similarly in section 4: >=20 > +----------+--------------------------------------------+ > | RESTCONF | NETCONF | > +----------+--------------------------------------------+ > | OPTIONS | none | > | HEAD | none | > | GET | , | > | POST | (operation=3D"create") | > | POST | invoke any operation | = <=3D=3D=3D=3D=3D > | PUT | (operation=3D"create/replace") | > | PATCH | (operation=3D"merge") | > | DELETE | (operation=3D"delete") | > +----------+--------------------------------------------+ >=20 > Which operation do we speak about here? It could be understood as = NETCONF protocol operations... >=20 > - section 3.x >=20 >=20 > The API resource contains the entry points for the RESTCONF = datastore and operation resources.=20 >=20 > And I see in 3.3.1 that querying {+restconf}/data content requires = application/yang.data+xml (or json), as opposed to .api+xml (or json) > What about the querying {+restconf}/operations? does it require = application/yang.api+xml or application/yang.data+xml ? > = https://tools.ietf.org/html/draft-ietf-netconf-restconf-13#section-3.3.2 = should provide any example. My first guess was: since operations =3D = API, I would have used application/yang.api+xml. Re-reading the draft, I = now guess it's application/yang.data+xml (or json). The point is: what = are the entry points for the operations resources? > - Section 3.3.3, Editorial >=20 > [RFC Editor Note: Adjust the date for ietf-yang-library below to the > date in the published ietf-yang-library YANG module, and remove = this > note.] >=20 > Make it clear that the date to be changed is 2016-04-09, as opposed to = only:=20 > Mon, 23 Apr 2012 >=20 > - =20 > 3.4. Datastore Resource > The "{+restconf}/data" subtree represents the datastore resource > type, which is a collection of configuration data and state data > nodes. >=20 > Should be "{+restconf}/datastore", right ? > - "Last-Modified" > This is one of those topics whose requirements are all over the place. = This is confusing (at least to me) >=20 > Section 3.4.1.1=20 > The last change time is maintained and the "Last-Modified" > ( > [RFC7232], Section 2.2 > ) header is returned in the response for a > retrieval request. The "If-Unmodified-Since" header can be used in > edit operation requests to cause the server to reject the request = if > the resource has been modified since the specified timestamp. >=20 > Section 3.5 > For configuration data resources, the server MAY maintain a last- > modified timestamp for the resource, and return the "Last-Modified" > header when it is retrieved with the GET or HEAD methods. >=20 > Section 9.1 > The server MUST maintain a last-modified timestamp for this > container, and return the "Last-Modified" header when this data = node > is retrieved with the GET or HEAD methods. >=20 > Section 10.1 > The server MUST maintain a last-modified timestamp for this > container, and return the "Last-Modified" header when this data = node > is retrieved with the GET or HEAD methods. >=20 > Section 10.1.1 > The server SHOULD maintain a last-modified timestamp for each > instance of this list entry, and return the "Last-Modified" header > when this data node is retrieved with the GET or HEAD methods. >=20 > and potentially some more sections > At the minimum, we should have forward references from section 3.4.1.1 = as it looks like self-contained. >=20 >=20 > Same remark for entity-tag and section 3.4.1.2 >=20 > - Section 3.5.1, editorial: >=20 > container top { > list list1 { > key "key1 key2 key3"; > ... > list list2 { > key "key4 key5"; > ... > leaf X { type string; } > } > } > leaf-list Y { > type uint32; > } > } >=20 > For the above YANG definition, a target resource URI for leaf "X" > would be encoded as follows (line wrapped for display purposes = only): >=20 > /restconf/data/example-top:top/list1=3Dkey1,key2,key3/ > list2=3Dkey4,key5/X >=20 > .... >=20 >=20 > Mentions that "container top" is part of the example-top YANG data = model >=20 > - section 3.5.2. >=20 > If the target of a GET method is a data node that represents a leaf > that has a default value, and the leaf has not been configured yet, > the server MUST return the default value that is in use by the > server. >=20 > I guess that it depends on the default handing mode. > What about trim? ref:=20 > https://tools.ietf.org/html/rfc6243#section-3.2 >=20 >=20 > - Section 3.6 > OLD: > If the "rpc" or "action" statement has an "input" section, then a > message-body MAY be sent by the client in the request, otherwise = the > request message MUST NOT include a message-body. If the "input" > objcet tree contains mandatory parameters, then a message-body MUST > be sent by the client.=20 >=20 > NEW: >=20 > If the "rpc" or "action" statement has an "input" section and the=20= > "input" object tree contains mandatory parameters, then a = message-body=20 > MUST be sent by the client in the request.=20 >=20 > If the "rpc" or "action" statement has an "input" section and the=20= > "input" object tree doesn't contain mandatory parameters, then a = message-body=20 > MAY be sent by the client in the request.=20 > =20 > If the "rpc" or "action" statement has no "input" section, the > request message MUST NOT include a message-body. =20 >=20 > - section 3.6 > If the operation is invoked without errors, and if the "rpc" or > "action" statement has an "output" section, then a message-body MAY > be sent by the server in the response, otherwise the response = message > MUST NOT include a message-body in the response message, and MUST > send a "204 No Content" status-line instead. >=20 > First, I don't understand the first MAY. I would have thought it would = be a MUST.=20 > Second, "MUST NOT include a message-body in the response message, and = MUST send a "204 No Content" status-line instead." > So the errors are not part of the message-body? Section 7.1 says:=20 > then the server SHOULD send a response > message-body containing the information described by the "errors" > container definition within the YANG module=20 > Section 8 >=20 > And third, message body or message-body. The document uses both. >=20 > - RFC5277 is a normative reference.=20 > I guess that pub/sub will obsolete RFC5277. > So we would have to update this RESTCONF RFC-to-be with the pub/sub = publication?=20 >=20 > - Section 4, editorial > OLD: > The NETCONF "remove" operation attribute is not supported by the = HTTP > DELETE method. > NEW=20 > The NETCONF "remove" operation attribute is not = supported by the HTTP > DELETE method. >=20 > - Section 4.4.1, Editorial: > OLD: The "insert" and "point" query > NEW: The "insert" ( > Section 4.8.5) and "point" (Section 4.8.6 > ) query >=20 > - Section 4.8 > RESTCONF Query Parameters, HEAD is missing. > Section 4.2: >=20 > The same query parameters supported by the GET method > are supported by the HEAD method. >=20 > - Section 4.8 > I see:=20 > o Each parameter can appear at most once in a request URI. > In section 4.8.2, I see: > More than one "depth" query parameter MUST NOT appear in a request. > If more than one instance is present, then a "400 Bad Request" > status-line MUST be returned by the server. > In section 4.8.3, I see: > More than one "fields" query parameter MUST NOT appear in a = request. > If more than one instance is present, then a "400 Bad Request" > status-line MUST be returned by the server. > etc. >=20 > You could include the generic specifications, along with the RFC2119 = language, in section 4.8, as opposed to every 4.8.x section. >=20 > - section 4.8.4 > The format of this parameter is an XPath 1.0 expression, and is > evaluated in the following context: > o The set of namespace declarations is the set of prefix and > namespace pairs for all supported YANG modules, where the prefix > is the YANG module name, and the namespace is as defined by the > "namespace" statement in the YANG module. >=20 > o The function library is the core function library defined in = XPath > 1.0. >=20 > RFC 6241 says: > o The function library is the core function library, plus any > functions defined by the data model. >=20 > Should this be aligned? >=20 >=20 > - Section 4.6.1 > The plain patch mechanism merges the contents of the message body > with the target resource. If the target resource is a datastore > resource (see=20 > Section 3.4 > ), the message body MUST be either > application/yang.datastore+xml or application/yang.datastore+json. > If then the target resource is a data resource (see=20 > Section 3.5 > ), > then the message body MUST be either application/yang.data+xml or > application/yang.data+json. >=20 > Something I completely missed (and only understood when I spoke to = Martin). > To edit a resource, we have two ways: > 1. PATCH on the datastore resource like in appendix D.2.3 > 2. PATCH on the data resource, with the full path. > To map the example in D.2.3, something like > PATCH /restconf/data HTTP/1.1 > Host: example.com > Content-Type: application/yang.data+xml > =20 > "http://x.x.x.x:yyyy/restconf/data/jukebox:library" >=20 > Both examples should be illustrated next to each others, and the text = in 4.6 or 4.6.1 clear. >=20 >=20 >=20 > - Section 4.8.7 > What is this "notification replay feature"? > I searched for "notification replay" in the doc, without luck. > I finally found it, in=20 > https://tools.ietf.org/html/rfc5277#section-3.3 > , from the reference link: > leaf replay-support { > type boolean; > description > "Indicates if replay buffer supported for this stream. > If 'true', then the server MUST support the = 'start-time' > and 'stop-time' query parameters for this stream."; > reference > " > RFC 5277, Section 3.4 > , element."; > } > You should really add the references in section 4.8.7 and 8, to=20 > RFC 5277, Section 3.4 > and to the replay-support >=20 > - Section 5.1, editorial > //?# >=20 > ^ ^ ^ ^ ^ > | | | | | > method entry resource query fragment >=20 > M M O O I >=20 > The method points to a space. Indent the line starting with >=20 >=20 > - section 5.2 > Content is encoded in either JSON or XML format. > There are no capabilities to discover this, right?=20 > So the only solution is for a client to test it, right? > How does a client know this? Trying is the only solution?=20 > Do we want to explain this, and show an example, for example with the = HEAD method? > Btw, I hope that we request to support JSON or XML is for the entire = series of resource, right?=20 > Do we want to make it clear? > +-----------+---------------------------------+ > | Resource | Media Type | > +-----------+---------------------------------+ > | API | application/yang.api+xml | > | | application/yang.api+json | > | Datastore | application/yang.datastore+xml | > | | application/yang.datastore+json | > | Data | application/yang.data+xml | > | | application/yang.data+json | > | [none] | application/yang.errors+xml | > | | application/yang.errors+json | > | Operation | application/yang.operation+xml | > | | application/yang.operation+json | > | Schema | application/yang | > +-----------+---------------------------------+ >=20 > - 5.3.2 Json MetaData Encoding Example >=20 > Note that RFC 6243 > defines the "default" attribute with XSD, not > YANG, so=20 > the YANG module name has to be assigned manually > . The value > "ietf-netconf-with-defaults" is assigned for JSON meta-data = encoding. >=20 > I don't understand " > the YANG module name has to be assigned manually > " >=20 > Also, In section 5.3: >=20 > The RESTCONF protocol needs to retrieve the same meta-data that is > used in the NETCONF protocol. Information about default leafs, = last- > modified timestamps, etc. are=20 > commonly=20 > used to annotate > representations of the datastore contents. =20 > This meta-data > is not > defined in the YANG schema because=20 > it applies to the datastore > , and > is common across all data nodes. >=20 > =3D> I don't understand:=20 > This meta-data > is not > defined in the YANG schema because=20 > it applies to the datastore > , and > is common across all data nodes. >=20 > This=20 > meta-data relates to default leafs and last-modified timestamps.=20 > The last-modified timestamps apply to more than just the datastore. >=20 > Also: > =20 > This information is encoded as attributes in XML > . JSON encoding of > meta-data is defined in [ > I-D.ietf-netmod-yang-metadata > ]. >=20 > You want to express something like this: > With the XML encoding, the metadata is encoded as attributes in XML > With the JSON encoding, the metadata is encoded as specified in [ > I-D.ietf-netmod-yang-metadata > ]. >=20 > btw, use a single convention throughout the doc: meta-data or metadata > draft-ietf-netmod-yang-metadata uses metadata=20 >=20 >=20 > - 5.4 >=20 >=20 > Each message represents some sort of resource access. An HTTP > "status-line" header line is returned for each request. If a 4xx = or > 5xx range status code is returned in the status-line, then the = error > information will be returned in the response, according to the = format > defined in=20 > Section 7.1 > . >=20 > Why only 4xx and 5xx? >=20 > - 6.3, editorial > OLD:=20 > A RESTCONF client MAY request the server compress the events using > the HTTP header field "Accept-Encoding". For instance: > NEW: > A RESTCONF client MAY request that the server compress the events = using > the HTTP header field "Accept-Encoding". For instance:-=20 >=20 > - > Section 8 > container operations { > description > "Container for all operation resources > (application/yang.operation), >=20 > Each resource is represented as an empty leaf with the > name of the RPC operation from the YANG rpc statement. >=20 > E.g.; >=20 > POST /restconf/operations/show-log-errors >=20 > leaf show-log-errors { > type empty; > } > "; > } >=20 > I've been confused by this example, as at first glance I didn't = consider a show-something as an operation. > You might be thinking of a more obvious example: Reset-xxx is one >=20 > - Section 13. > Acknowledgment and "contributions" term. > acknowledged persons for their contributions: do we speak about = contributors, which has got a special meaning in terms of IPR? > If not, let's avoid the "contributions" term >=20 > - Good job with the appendix C and D. The examples are very useful. >=20 > - Appendix D.1, editorial >=20 >=20 > =20 > The client may start by retrieving=20 > the top-level API resource, using > the entry point URI "{+restconf}". > =20 > If this is a typical operational example, I guess you want to start by = retrieving: > GET /.well-known/host-meta HTTP/1.1 >=20 > - Appendix D.1.2 > An example of deviations would be welcome (even if this is = ietf-yang-library, which is a different dra >=20 > - D.3.3 > I guess this request should not report the module-set-id? > =20 > GET /restconf/data?fields=3Dietf-yang-library:modules-state/ > module(name;revision) HTTP/1.1 >=20 > ... >=20 > =20 > { > "ietf-yang-library:modules-state": { >=20 > "module-set-id": "cb4c422111a779e1eed55bffc8d6b46a3a0999e2", >=20 > "module": [ >=20 > =20 >=20 > -=20 > Since we have many examples around around example-jukebox, this should = pass compilation, right?=20 >=20 > pyang --ietf example-jukebox.yang=20 > example-jukebox.yang:1: error: expected keyword "namespace" as child = to "module" > example-jukebox.yang:1: error: expected keyword "prefix" as child to = "module" > example-jukebox.yang:1: warning: RFC 6087: 4.1: the module name should = start with one of the strings "ietf-" or "iana-" > example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" must = have a "contact" substatement > example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" must = have a "organization" substatement > example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" must = have a "description" substatement > example-jukebox.yang:1: error: RFC 6087: 4.7: statement "module" must = have a "revision" substatement >=20 > What was the agreed convention for example modules that should pass = compilation? >=20 > - We advice YANG data models to include a YANG tree diagram, like you = did for "ietf-restconf-monitoring"=20 > The RESTCONF module doesn't. Obviously, pyang -f tree doesn't produce = anything, but make it clear with some text, so that the readers don't = believe it's an omission. >=20 > - Security Considerations. > Please include=20 > = https://trac.tools.ietf.org/area/ops/trac/wiki/yang-security-guidelines >=20 >=20 > - idnit complains about a few things. >=20 > - [] in json encoding of list. > For example, > PUT /restconf/data/example-jukebox:jukebox/ > library/artist=3DFoo%20Fighters/album=3DWasting%20Light = HTTP/1.1 > Host: example.com > Content-Type: application/yang.data+json >=20 > { > "example-jukebox:album" : { > "name" : "Wasting Light", > "genre" : "example-jukebox:alternative", > "year" : 2011 > } > } >=20 >=20 > Don't we need [] for the album list?=20 >=20 > list album { > key name; >=20 > description > "Represents one album resource within one > artist resource, within the jukebox library."; >=20 > leaf name { > type string { > length "1 .. max"; > } > description "The name of the album."; > } >=20 > leaf genre { > type identityref { base genre; } > description > "The genre identifying the type of music on > the album."; > } >=20 > leaf year { > type uint16 { > range "1900 .. max"; > } > description "The year the album was released"; > } >=20 >=20 >=20 > See=20 >=20 > https://tools.ietf.org/html/draft-ietf-netmod-yang-json-10#section-5.4 >=20 > list bar { > key foo; > leaf foo { > type uint8; > } > leaf baz { > type string; > } > } >=20 > the following is a valid JSON-encoded instance: >=20 > "bar": [ > { > "foo": 123, > "baz": "zig" > }, > { > "baz": "zag", > "foo": 0 > } > ] >=20 >=20 >=20 > Regards, Benoit (OPS AD) >=20 > =20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue May 31 08:10:17 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF8B012D5D9 for ; Tue, 31 May 2016 08:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGaVG5dkUxC4 for ; Tue, 31 May 2016 08:10:11 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A656E12B026 for ; Tue, 31 May 2016 08:10:11 -0700 (PDT) Received: by mail-pa0-x233.google.com with SMTP id eu11so63372814pad.3 for ; Tue, 31 May 2016 08:10:11 -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-transfer-encoding :message-id:cc:from:subject:date:to; bh=1nhXYsIBjfnZZQnCbBiGm9E1M0aJnbx8DrfYqXUekys=; b=sRTrWsafqy277NM+XPkgc5UBMTGpXnNfAlyVCOAIJ1aYJKmXHIzB384OZAIcV5k3Cl FX4MQ2uro6jiA+FQKkR/C2EeDTxva3exYpHXxHM2KdlyrVQN7GQh5dSm5QabccohKGyw IWYBPlvONBA4oKEv7kIKd2M6sv7BMC+HXSMIhq95KD7s3ofP4DdDJfPCcmskk6boVpZg ZVxwH3s8lT5wxsWbq64XgGuBlLMuBspfZ3ZTA7GIGxV//0KRZq6BADNAPljX/lzE+b00 8nYgiqtYmQXiI1TZ1ES0+kEcqAXhuqtlPEy/j6S05MMHaS+Y29vVxOtgsPgfwVDnszM6 VvgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=1nhXYsIBjfnZZQnCbBiGm9E1M0aJnbx8DrfYqXUekys=; b=I3VHmqu/4bFi6R5xOBIU/B0Vplpf5azQZLHwMIolY5a+L8Vt72ELTlI27l2AMFNduH DKb6SIhg3mdTYlFDD88FZryKZ9rcGyYExD7loDvHFrUAHMM256LwSmRAKZy1VGMjoHtG PaXWvKA7jIgW6QzDzqKph3eSN2E1Hp0/TSyosbACMOdRM5kOFEcwD5bRBziptKCLKrGo e3UmRZspKyiuubIMWefhFfIR7N1LPaltQp6jbzFjjYWI2Fb90kfeVE4BjTod/azZFIz5 LvgCyAzetTABSe5Exlf6pYFT5Y629pIE8gvnzYcxdUthBhPfHdjJwdgXjCCc1P9uQYcy z4sQ== X-Gm-Message-State: ALyK8tLcD+MPpvXpu3yhGwgUJyCU+YSdMRJbqIetDQHiqGZUBByKDHxdsu9UWkWrF7CREw== X-Received: by 10.66.65.169 with SMTP id y9mr56634200pas.102.1464707411048; Tue, 31 May 2016 08:10:11 -0700 (PDT) Received: from [192.168.1.150] (108-247-125-249.lightspeed.sntcca.sbcglobal.net. [108.247.125.249]) by smtp.gmail.com with ESMTPSA id vw1sm55726340pab.35.2016.05.31.08.10.09 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 31 May 2016 08:10:09 -0700 (PDT) References: <01f401d1a54f$621dbad0$26593070$@seguesoft.com> <20160531.105003.567321207823725528.mbj@tail-f.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <4CE02CDD-99AA-4E12-AFAE-8A06081749E4@gmail.com> X-Mailer: iPad Mail (13E238) From: Mahesh Jethanandani Date: Tue, 31 May 2016 08:10:07 -0700 To: "Sterne, Jason (Nokia - CA)" Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Clarification request for NETCONF edit-config default-operation replace X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 15:10:15 -0000 > On May 31, 2016, at 6:36 AM, Sterne, Jason (Nokia - CA) wrote: >=20 > Thx Martin. Your explanation that a default replace operation can only ap= ply to elements that are in the request helps a lot. >=20 > So there really is no such thing as an edit-config 'replace' operation tha= t operates "at the root". That can only be done with a special dedicated RPC= (e.g. copy-config as you show in Case 5). >=20 > So my case 4 is equivalent to this: >=20 >> >> =20 >> 10 =20 >> =20 >> >=20 > which will replace the entire contents of the /system subtree (but not any= thing else). >=20 > On a related note -> is the final result (i.e. datastore contents) of a re= place operation always exactly the same as a remove + merge with the same da= ta at the same location ? I can't think of an example where that isn't true= but I may be missing some corner case. =20 >=20 > For the candidate datastore it seems that 'replace' is simply a shorthand w= ay to do remove+merge in a single edit-config. For a running datastore (wri= teable-running) the impacts would be quite different though since the edit-c= onfig 'remove' would be applied immediately which would clear out all config= for a short period before the 'merge' then gets processed. You would normally edit the candidate configuration, and once validated comm= it it to running. You would normally not the running data stor= e directly. Mahesh Jethanandani mjethanandani@gmail.com >=20 > Regards, > Jason >=20 > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com]=20 > Sent: Tuesday, May 31, 2016 4:50 > To: Sterne, Jason (Nokia - CA) > Cc: xiangli@seguesoft.com; wivory@Brocade.com; netconf@ietf.org > Subject: Re: [Netconf] Clarification request for NETCONF edit-config defau= lt-operation replace >=20 > "Sterne, Jason (Nokia - CA)" wrote: >> Hi guys, >>=20 >> I think there is some conflicting information wrt default-operation=20 >> replace here. >=20 > I agree it is not clear. >=20 >> The following snippet of RFC 6241 clearly states (IMO) that the entire=20= >> config is affected/replaced. The first sentence says it. >=20 > I don't think this statement clearly says that the entire datastore is rep= laced. It uses the term "completely replace". I don't know how that is dif= ferent from "replace". IMO, "replace" implies "completely"... >=20 >> Then the second sentence gives yet another indication that it replaces=20= >> the entire config: >=20 > Not necessarily. >=20 >>> replace: The configuration data in the parameter >>> completely replaces the configuration in the target >>> datastore. This is useful for loading previously saved >>> configuration data. >>=20 >>=20 >> I also found an older discussion on this on the mailing list that=20 >> indicates that a default action of replace is intended to be used for=20 >> the entire datastore. From >> https://mailarchive.ietf.org/arch/msg/netconf/s4KOJxIgbDzqAXS-uF_jFi-iQsU= : >>=20 >>=20 >>> 1) >>> $backup =3D get-config(source=3Drunning) >>> 2) >>> copy-config(source=3D$backup, target=3Drunning) OR >>> edit-config(source=3D$backup, target=3Drunning, >>> default-operation=3Dreplace)" >>=20 >>=20 >> operations are inherited. The default-operation applies=20 >> to all top level objects. But I'm not certain whether it applies to=20 >> all top level objects in the data model on the server or just all the=20 >> top level objects that are included in the request. >=20 > The latter. It is just a default value for the "operation" attribute; i.e= ., instead of using "default-operation", you could explicitly set the "opera= tion" attribute - and you can only do that for the elements in the request (= obvioulsy). >=20 >> =46rom the descriptions above it seems it must apply to all top level=20 >> objects in the server but that seems to conflict with: >>=20 >>> "only the configuration actually present in the parameter=20 >>> is affected" >>=20 >> Here is a set of examples that may help clarify things. The first 3=20 >> cases are an incremental lead-in to case 4 which is the least clear=20 >> for me. >>=20 >> ## Initial server Config A (used in all the cases below): >> >> >> 12 >> true >> >> >> 132 >> true >> >> >> >> >> 8 >> true >> >> >>=20 >> ## Case 1: >> - Initial Config A >> - edit-config request (no default operation): >> >> >> 10 >> >> >> - Resulting config on the server (only 'min-length' affected): >> >> >> 10 >> true >> >> >> 132 >> true >> >> >> >> >> 8 >> true >> >> >>=20 >> ## Case 2: >> - Initial Config A >> - edit-config request (no default operation): >> >> >> 10 // inherited replace >> >> >> - Resulting config on the server (all 'password-control' affected): >> >> >> 10 >> >> >> 132 >> true >> >> >> >> >> 8 >> true >> >> >>=20 >> ## Case 3: >> - Initial Config A >> - edit-config request (no default operation): >> >> // inherited replace >> 10 // inherited replace >> >> >> - Resulting config on the server (all 'system' affected) : >> >> >> 10 >> >> >> >> >> 8 >> true >> >> >>=20 >> ## Case 4: >> - Initial Config A >> - edit-config request (!! with default-operation replace !!): >> >> =20 >> 10 =20 >> =20 >> >> - Resulting config on the server (entire server datastore affected ?): >> >> >> 10 >> >> >> // no qos data ? >=20 > This is not correct; qos is unaffected. >=20 > ## Case 5: > - Initial Config A > - copy-config request > > =20 > 10 =20 > =20 > > - Resulting config on the server (entire server datastore affected !): > > > 10 > > > // no qos data ! >=20 >=20 >=20 > /martin >=20 >=20 >=20 >>=20 >> Regards, >> Jason >>=20 >> -----Original Message----- >> From: EXT Xiang Li [mailto:xiangli@seguesoft.com] >> Sent: Tuesday, May 03, 2016 11:21 >> To: Sterne, Jason (Nokia - CA); 'Martin Bjorklund'; wivory@Brocade.com >> Cc: netconf@ietf.org >> Subject: RE: [Netconf] Clarification request for NETCONF edit-config=20 >> default-operation replace >>=20 >> Hi >>=20 >>> -----Original Message----- >>> ...=20 >>> In my first question I meant "using an ": >>>=20 >>> Is there no way to delete (or replace) the entire contents of the >> datastore >>> using an (and without using without=20 >>> having to explicitly list every single top level node ? >>=20 >> I don't think edit-config is designed to do that. >>=20 >> To delete a datastore, use , although can't=20 >> be deleted. >> To replace the *entire config*, use .=20 >>=20 >>> =46rom the description of the default-operation 'replace' it seems it=20= >>> is >> possible >>> via the default operation: >>> replace: The configuration data in the parameter >>> completely replaces the configuration in the target >>> datastore. This is useful for loading previously saved >>> configuration data. >>=20 >>=20 >> No. The definition of "replace" as an operation says clearly: >>=20 >> Unlike a operation, which replaces the entire t= arget >> configuration, only the configuration actually present in >> the parameter is affected. >>=20 >> In other words, the only replaces the data nodes that exist=20 >> in the target and for nodes that are in in the=20 >> but not in the target, they are created. Other nodes that=20= >> exist in the device but are not present in the of the=20 >> are NOT affected in any way (this is the key difference=20 >> with , where they are removed because it operates on the >> *entire* datastore.) >>=20 >>> But can replace of the entire contents be done without replace as=20 >>> the >> default >>> operation ? >>=20 >> Not with the default "replace" operation, nor with the normal=20 >> "replace" >> operation. >> The default "replace" operation has no additional semantics compared=20 >> to The "operation" parameter >>=20 >>> Or delete of the entire contents ? The RFC doesn't seem to clear on=20 >>> whether we can use an operation on the node: >>> >>> >>=20 >>=20 >> The description of says: the target configuration is not=20= >> necessarily replaced, as with the message. Instead, the=20= >> target configuration is changed in accordance with the source's data=20 >> and requested operations. >>=20 >> In other words, the parameter in will not be=20 >> valid if you do not specify it (assuming no url capability) or make it=20= >> empty, as in your example. >>=20 >> config: A hierarchy of configuration data as defined by one of >> the device's data models. The contents MUST be placed in an >> appropriate namespace, to allow the device to detect the >> appropriate data model, and the contents MUST follow the >> constraints of that data model, as defined by its capability >> definition. >>=20 >>=20 >>> (c) and (d) have a delete operation on a leaf (in (c) is it=20 >>> inherited) but >> are >>> providing a value for the leaf at the same time. What is the meaning=20 >>> of >> the >>> value ? That seems like an error to me. We should warn the client=20 >>> that they've done something unexpected (the client may have been=20 >>> intending to do something different than deleting that leaf). >>> I can see how that works when the leaf is a key leaf in a list. But=20 >>> it >> seems like >>> an error for just a plain leaf. >>=20 >>=20 >> No. I think the value is actually used by . For example, >> RFC6241 >> has this example: >>=20 >> Delete the configuration for an interface named "Ethernet0/0" from >> the running configuration: >>=20 >> > xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"> >> >> >> >> >> none >> >> >> >> Ethernet0/0 >> >> >> >> >> >>=20 >>=20 >> Without specifying value so that the device can find an exact matched=20 >> interface, this won't work. >>=20 >> In other words, my understanding is that if a value is given, and the=20 >> device >>=20 >> can't find a match then then the delete will fail with a=20 >> error. >>=20 >>> I'm also not convinced about (f) and (g). Wrt your analogy of a=20 >>> directory >> with >>> files: you can delete a container in NETCONF and that automatically >> deletes >>> any children, grandchildren and so on (the entire subtree). It=20 >>> seems >> strange >>> that there is no way to delete (or replace) the entire contents of a=20 >>> list >> or leaf- >>> list. >>=20 >> I don't necessarily disagree with you on this one. >>=20 >> I was simply suggesting that the protocol perhaps should have a simple=20= >> way to allow me to remove list entries. In particular I think it would=20= >> be useful it allows: >> 1) to delete a specific list entry by providing a list entry's=20 >> Instance ID ( all key nodes and corresponding values). >> 2) to delete all entries of a list by just providing all key nodes in=20 >> the . >>=20 >> Best, >> --Xiang >>=20 >>=20 >>=20 >>> Or perhaps I'm misinterpreting the description of the replace and=20 >>> delete operations in RFC6241 (the sentences "only the configuration=20 >>> actually present in the parameter is affected" and "if and=20 >>> only if the configuration data currently exists" are giving me some=20 >>> pause here). >> There >>> aren't many examples illustrating delete & replace in the RFC. >>>=20 >>> Regards, >>> Jason >>>=20 >>> -----Original Message----- >>> From: EXT Xiang Li [mailto:xiangli@seguesoft.com] >>> Sent: Friday, April 29, 2016 20:05 >>> To: Sterne, Jason (Nokia - CA); 'Martin Bjorklund';=20 >>> wivory@Brocade.com >>> Cc: netconf@ietf.org >>> Subject: RE: [Netconf] Clarification request for NETCONF edit-config >> default- >>> operation replace >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Sterne,=20 >>> Jason (Nokia - CA) >>> Sent: Friday, April 29, 2016 2:12 PM >>> To: Martin Bjorklund ; wivory@Brocade.com >>> Cc: netconf@ietf.org >>> Subject: Re: [Netconf] Clarification request for NETCONF edit-config >> default- >>> operation replace >>>=20 >>> Is there no way to delete the entire contents of the datastore=20 >>> without >> having >>> to explicitly list every single top level node ? >>>=20 >>> e.g. >>> with no default operation (i.e. merge): >>> >>>=20 >>> Or >>> With default operation =3D delete: >>> >>>=20 >>> Similarly -> Is there no way to replace the entire contents of the >> datastore ? >>>=20 >>> [XL] I think< copy-config> or can do this. >>>=20 >>> About the cases below shouldn't (c) and (d) return an error ? They >> contain >>> data for an object that is being deleted. (e) seems like the=20 >>> correct way >> to do >>> it. >>>=20 >>> [XL] I think Martin's explanation is correct. My understanding is=20 >>> that if >> the >>> value does not match, then the would return an error since=20 >>> the no matching data node found (yes I view this as a content-match). >>> Or I might >> be >>> totally wrong here, i.e., the value does not matter in any way as=20 >>> Martin >> said? >>>=20 >>> (f) and (g) surprise me. If I can an entire leaf-list=20 >>> or >> list by just >>> specifying the tag for the leaf-list/list name, why doesn't delete=20 >>> get rid >> of the >>> entire leaf-list/list ? >>> (if you specify a specific list entry/member in a delete it is=20 >>> basically >> just a >>> content match node but otherwise you've selected the entire list no=20 >>> ?). >>>=20 >>> [XL] I also thought that I can delete a list entry by specifying =20 >>> all key >> nodes >>> and their values (i.e., list entry's instance ID). If no values of=20 >>> key >> nodes are >>> given, then the entire list entries matched and all of them should=20 >>> be >> deleted. >>> Although Martin's explanation also makes sense here, that is, you=20 >>> can't >> just >>> delete a key node yet if it is still used by non-key nodes. >>> Just like deleting a directory when the directory still contains=20 >>> files. >> But, in any >>> case, I would still like that I can delete a list entry by giving=20 >>> the >> list entry's IID >>> since we can unmistakably identify a list entry by given a list=20 >>> entry's >> IID (i.e. , >>> all key nodes and their corresponding values). I think such a=20 >>> delete operation would be useful, just like "rm -rf directory". >>>=20 >>> --Xiang >>> -----Original Message----- >>> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Martin=20 >>> Bjorklund >>> Sent: Friday, April 15, 2016 10:49 >>> To: wivory@Brocade.com >>> Cc: netconf@ietf.org >>> Subject: Re: [Netconf] Clarification request for NETCONF edit-config >> default- >>> operation replace >>>=20 >>> William Ivory wrote: >>>> OK - I think it might help if I gave some specific examples, with=20 >>>> my understanding of what would get deleted and you can tell me if=20 >>>> I'm correct or not. Apologies for length, but I'd like to avoid=20 >>>> any confusion by not spelling out my queries, and I'm struggling=20 >>>> to get a clear picture of how this all works with all the=20 >>>> different permutations! >>>>=20 >>>> Let's take a configuration like this: >>>>=20 >>>> >>>> leafValue >>>> leaflistValueOne >>>> leaflistValueTwo >>>> >>>> firstEntryKey >>>> firstEntryLeaf >>>> >>>> >>>> secondEntryKey >>>> secondEntryLeaf >>>> >>>> >>>>=20 >>>> --- >>>>=20 >>>> (a) topCont, default operation delete >>>>=20 >>>> With the default operation set to delete: >>>>=20 >>>> >>>> >>>> >>>>=20 >>>> =3D> topCont, and everything under it, would be deleted >>>=20 >>> Yes. >>>=20 >>>> (b) topCont, operation delete >>>>=20 >>>> With the default operation set to none: >>>>=20 >>>> >>>> >>>> >>>>=20 >>>> =3D> topCont, and everything under it, would be deleted >>>=20 >>> Yes. >>>=20 >>>> --- >>>>=20 >>>> (c) aLeaf delete, operation specified for topCont >>>>=20 >>>> With the default operation set to none: >>>>=20 >>>> >>>> >>>> leafValue >>>> >>>>=20 >>>> =3D> Will delete aLeaf node. If this leaves topCont empty, then=20 >>>> topCont would be removed. If topCont still contains other=20 >>>> elements, topCont would remain? >>>=20 >>> No. This deletes the topCont and everything below it. >>>=20 >>>> --- >>>>=20 >>>> (d) aLeaf delete, operation specified for aLeaf >>>>=20 >>>> With the default operation set to none: >>>>=20 >>>> >>>> >>>> leafValue >>>> >>>>=20 >>>> =3D> Will delete aLeaf node. If this leaves topCont empty, then=20 >>>> topCont would be removed unless it is a presence node. >>>=20 >>> Yes (s/would/may/) >>>=20 >>>> --- >>>>=20 >>>> (e) aLeaf delete, operation specified for aLeaf, but no value=20 >>>> given >>>>=20 >>>> With the default operation set to none: >>>>=20 >>>> >>>> >>>> >>>>=20 >>>> =3D> Would this delete aLeaf, and, as per (d), conditionally=20 >>>> , or must the value of the leaf be specified? >>>=20 >>> Yes, this would delete aLeaf. The value doesn't matter. >>>=20 >>>> --- >>>>=20 >>>> (f) aLeafListEntry >>>>=20 >>>> Is there a way to delete all leaflist entries without specifying=20 >>>> them individually, eg: >>>>=20 >>>> >>>=20 >>> No >>>=20 >>>=20 >>>>=20 >>>> ... or, assuming there are other sibling nodes such that we can't=20 >>>> just delete topCont, must I specify each individual leaflist=20 >>>> element I wish to remove? >>>>=20 >>>> --- >>>>=20 >>>> (g) aListEntry >>>>=20 >>>> As per leaflist entries, is there a way to delete all entries=20 >>>> generically >>>=20 >>> No. >>>=20 >>>> , or must each be specified? >>>=20 >>> Yes. >>>=20 >>>> Separately, if I delete a non-key node inside a list entry, I=20 >>>> assume that just deletes that node. If I delete the list's key=20 >>>> node, then presumably that removes the complete entry, eg: >>>>=20 >>>> >>>> >>>> >>>> firstEntryKey >>>> >>>> >>>=20 >>> Yes >>>=20 >>>> Would the following achieve the same, ie removal of this list entry: >>>>=20 >>>> >>>> >>>> >>>> firstEntryKey >>>> >>>> >>>=20 >>> Hmm. I would say that this results in an error - deleting just the=20 >>> key of >> a list is >>> not possible. >>>=20 >>>=20 >>>=20 >>> /martin >>>=20 >>>=20 >>>=20 >>>>=20 >>>> --- >>>>=20 >>>> Thanks for bearing with me, >>>>=20 >>>> William >>>>=20 >>>> -----Original Message----- >>>> From: Martin Bjorklund [mailto:mbj@tail-f.com] >>>> Sent: 15 April 2016 13:44 >>>> To: William Ivory >>>> Cc: netconf@ietf.org >>>> Subject: Re: [Netconf] Clarification request for NETCONF=20 >>>> edit-config default-operation replace >>>>=20 >>>> William Ivory wrote: >>>>> Hi Martin, >>>>>=20 >>>>> Thanks - I think that the section on 'replace' under=20 >>>>> 'default-operation' could do with being clarified next time the=20 >>>>> RFC is updated then. >>>>>=20 >>>>> I'd appreciate some further clarification on what exactly ' only=20 >>>>> the configuration actually present in the parameter is=20 >>>>> affected' >>>>> means in practice. >>>>>=20 >>>>> First, the general pattern of examples which use=20 >>>>> 'operation=3D' is that this command is put in the 'parent' >>>>> element's tag, ie the tag which specifies 'delete' is *not* deleted. >>>>=20 >>>> No. For example: >>>>=20 >>>> >>>> 192.0.2.4 >>>> >>>>=20 >>>> will delete the "interface" node with the name "192.0.2.4" >>>>=20 >>>> It does NOT keep the "interface" node and just delete the "name" node. >>>>=20 >>>>> How then would you delete a top-level container? >>>>=20 >>>> >>>>=20 >>>>=20 >>>>=20 >>>> /martin >>>>=20 >>>>=20 >>>>> The examples have a >>>>> '' element but in cases where there are multiple top-level=20 >>>>> nodes, some of which are optional in the configuration (ie not=20 >>>>> presence containers), is it possible to delete these nodes? >>>>>=20 >>>>> Secondly, if I'm correct that the 'delete' operation would only=20 >>>>> affect nodes below the one with the delete operation, is it=20 >>>>> possible to construct an edit-config PDU that would delete all=20 >>>>> child nodes without having to explicitly specify each one? Or=20 >>>>> is the only way to achieve this either to explicitly specify all=20 >>>>> config to be removed, or to do a copy-config explicitly=20 >>>>> specifying all config that is not to be deleted. >>>>>=20 >>>>> Thanks, >>>>>=20 >>>>> William >>>>>=20 >>>>> -----Original Message----- >>>>> From: Martin Bjorklund [mailto:mbj@tail-f.com] >>>>> Sent: 14 April 2016 09:34 >>>>> To: William Ivory >>>>> Cc: netconf@ietf.org >>>>> Subject: Re: [Netconf] Clarification request for NETCONF=20 >>>>> edit-config default-operation replace >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> William Ivory wrote: >>>>>> Hi, >>>>>>=20 >>>>>> I'd appreciate clarification of how the NETCONF edit-config=20 >>>>>> command should work with default-operation set to 'replace'. >>>>>> For the most part, the edit-config section is clear that=20 >>>>>> config will only be replaced if explicitly overwritten (ie if=20 >>>>>> you provide replacement config for given nodes). However, the=20 >>>>>> section on default-operation is less clear: >>>>>>=20 >>>>>> The parameter is optional, but if >>> provided, >>>>>> it has one of the following values: >>>>>>=20 >>>>>> merge: The configuration data in the parameter is >>>>>> merged with the configuration at the corresponding=20 >>>>>> level >>> in >>>>>> the target datastore. This is the default behavior. >>>>>>=20 >>>>>> replace: The configuration data in the parameter >>>>>> completely replaces the configuration in the target >>>>>> datastore. This is useful for loading previously saved >>>>>> configuration data. >>>>>>=20 >>>>>> Specifically, while 'merge' states that merge happesn with=20 >>>>>> 'configuration as the corresponding level', 'replace' states=20 >>>>>> that is 'completely replaces' the configuration, suggesting=20 >>>>>> that it will remove ALL existing configuration regardless of=20 >>>>>> what is explicitly provided as the replacement. Is that=20 >>>>>> correct, or is 'replace' meant to have equivalent semantics to=20 >>>>>> 'merge' ie it will only replace configuration when an explicit=20 >>>>>> replacement is provided. In other words, if the latter case=20 >>>>>> is correct, all it does is remove the requirement to specify=20 >>>>>> the operation in each >>> element of new config. >>>>>=20 >>>>> Yes the latter is correct. Note that the definition of "replace"=20 >>>>> as an operation says: >>>>>=20 >>>>> Unlike a >>>>> operation, which replaces the entire target >>>>> configuration, only the configuration actually present in >>>>> the parameter is affected. >>>>>=20 >>>>>=20 >>>>> /martin >>>=20 >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >>>=20 >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Tue May 31 17:38:08 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C94212D91E for ; Tue, 31 May 2016 17:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YKp2FXsKLlLr for ; Tue, 31 May 2016 17:38:04 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0115.outbound.protection.outlook.com [207.46.100.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D50712D13C for ; Tue, 31 May 2016 17:38:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7T/EGqLqeJP/teIcrMQpE7A1GDjmezN7vIp955aBfL8=; b=OYjvIduVJSxANz0+DxVHKOjNVuAG6F0K0d0opVFhO4dnhif//zmhsRw/ds4NC4t9kYtiurRTYk3qdNt+uTJIUw08OxX73mM02D2u/ZM4NRT5XgSYs00l03f53A6wdhGH5yti7cILe/JkQlr/oTHHUTWakPtduKumymjDg2DKuH0= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) with Microsoft SMTP Server (TLS) id 15.1.506.9; Wed, 1 Jun 2016 00:38:02 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0506.013; Wed, 1 Jun 2016 00:38:02 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] Confirming the decision to split the server-model draft into several drafts. Thread-Index: AQHRoaVh8ffONUU7e0mY3J48WLy0wJ+gl6QAgAADqICAAAGbAIAAMy4MgAAG/4CAAFj0gP//24sAgARfpPCAAnXPAIAlDqYAgAbFsAA= Date: Wed, 1 Jun 2016 00:38:02 +0000 Message-ID: References: <3C88D813-7674-47C4-A6AF-E02C368CE71C@juniper.net> <20160429.100226.431840842419129504.mbj@tail-f.com> <20160429081529.GA26297@elstar.local> <20160429.102116.1627845264494578220.mbj@tail-f.com> <00aa01d1a209$2d165a20$4001a8c0@gateway.2wire.net> <9E3A9643-2348-42AA-A6B0-6FB9F13D1A29@juniper.net> <022801d1a456$c20e12e0$4001a8c0@gateway.2wire.net> <92BAF631-804E-45AD-89A3-48059966B2F4@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.16.0.160506 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.10] x-ms-office365-filtering-correlation-id: 178d2dd4-d972-4027-9add-08d389b4fd81 x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 5:/FhwXn16dFslBEICmz1uFJXfOinoWLSPzctHI6i9FueKlujw09fzomPIemgTZQEqGCMOfZr/r/LBUuNNqtXJdSafxUJOwWWyXXwtJMgR84PuvAnX/gs+Ou57wqoIJYeTTGTv9ypAyZyO2jzVa0JKIQ==; 24:6KOuWgleUk0LEg8GeEtdG7chys1ajQX7eIFrBb7aMUgbde7fzhNYBPc5XqNv8dgVmewsVO77z8MD3vjGH7izsj94hfZctrcOU8lQB3RtbJ8=; 7:vo0LRlPe4OJhnPTJBH6o4NkWAFIPnycf/7Pyme2dmLrbqnur43LJRJCo8hl3SZ4KhhxKoFMN89/vV6ewN0VnvM7oYBNEHfHK7HRum1EUutfdXR/0itXj47YBbseOQyc1JHjNwCaPqBKxNzfbaSAIqIgVMYxUmohjDL3v0X0hQ/UecCcc0QZRA+KhmUvGgQEa x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(138986009662008)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 096029FF66 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(2501003)(92566002)(1730700003)(8676002)(11100500001)(450100001)(93886004)(66066001)(5004730100002)(83716003)(99286002)(77096005)(82746002)(33656002)(586003)(81166006)(122556002)(83506001)(5008740100001)(8936002)(3846002)(102836003)(6116002)(5890100001)(561944003)(87936001)(106116001)(107886002)(5002640100001)(4001350100001)(5640700001)(76176999)(19580405001)(3660700001)(54356999)(19580395003)(2900100001)(50986999)(2950100001)(86362001)(189998001)(2351001)(36756003)(110136002)(2906002)(3280700002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jun 2016 00:38:02.8838 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1442 Archived-At: Subject: Re: [Netconf] Confirming the decision to split the server-model draft into several drafts. X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 00:38:07 -0000 DQpUaGFuayB5b3UgZXZlcnlvbmUgdGhhdCByZXNwb25kZWQuICBJdCBhcHBlYXJzIHRoYXQgdGhl IG9uLWxpc3QgY29uc2Vuc3VzIGlzIHRvIGdvIHdpdGggUHJvcG9zYWwgIzMsIGEgdG90YWwgb2Yg NSBkcmFmdHMgKHNlZSBiZWxvdykuICAgSWYgbm8gb2JqZWN0aW9ucyBhcmUgcmFpc2VkIGJlZm9y ZSBuZXh0IE1vbmRheSwgSeKAmWxsIGFzc3VtZSB0aGF0IHRoaXMgY29uc2Vuc3VzIGlzIGNvbmZp cm1lZCBhbmQgd2lsbCBzdGFydCBtYWtpbmcgdGhlIGNoYW5nZXMuDQoNCg0KSGVyZSBpcyB0aGUg NSBkcmFmdHMgYW5kIHRoZWlyIG1vZHVsZXMgZnJvbSBQcm9wb3NhbCAjMzoNCg0KMS4gICAgZHJh ZnQtaWV0Zi1uZXRjb25mLXN5c3RlbS1rZXljaGFpbg0KICAgICAgICAgICAgLSBpZXRmLXN5c3Rl bS1rZXljaGFpbg0KDQoyLiAgICBkcmFmdC1pZXRmLW5ldGNvbmYtc3NoLWNsaWVudC1zZXJ2ZXIN CiAgICAgICAgICAgIC0gaWV0Zi1zc2gtY2xpZW50ICANCiAgICAgICAgICAgIC0gaWV0Zi1zc2gt c2VydmVyDQoNCjMuICAgIGRyYWZ0LWlldGYtbmV0Y29uZi10bHMtY2xpZW50LXNlcnZlcg0KICAg ICAgICAgICAgLSBpZXRmLXRscy1jbGllbnQgIA0KICAgICAgICAgICAgLSBpZXRmLXRscy1zZXJ2 ZXIgIA0KDQo0LiAgICBkcmFmdC1pZXRmLW5ldGNvbmYtbmV0Y29uZi1jbGllbnQtc2VydmVyDQog ICAgICAgICAgICAtIGlldGYtbmV0Y29uZi1jbGllbnQgIA0KICAgICAgICAgICAgLSBpZXRmLW5l dGNvbmYtc2VydmVyICANCg0KNS4gICAgZHJhZnQtaWV0Zi1uZXRjb25mLXJlc3Rjb25mLWNsaWVu dC1zZXJ2ZXINCiAgICAgICAgICAgIC0gaWV0Zi1yZXN0Y29uZi1jbGllbnQgIA0KICAgICAgICAg ICAgLSBpZXRmLXJlc3Rjb25mLXNlcnZlciAgDQoNCg0KVGhhbmtzLA0KS2VudA0KDQoNCk9uIDUv MjcvMTYsIDE6MTIgUE0sICJOZXRjb25mIG9uIGJlaGFsZiBvZiBLZW50IFdhdHNlbiIgPG5ldGNv bmYtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Yga3dhdHNlbkBqdW5pcGVyLm5ldD4gd3Jv dGU6DQoNCj4NCj4NCj5PbiA1LzMvMTYsIDc6MTggUE0sICJNYWhlc2ggSmV0aGFuYW5kYW5pIiA8 bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+IHdyb3RlOg0KPg0KPj5JdCBhcHBlYXJzIHRoYXQgYSB2 aXJ0dWFsIGludGVyaW0gbWVldGluZyBtaWdodCBoZWxwIHRoaXMgZGlzY3Vzc2lvbiBhbmQgdGhl IGRpc2N1c3Npb24gYXJvdW5kIGtleS1jaGFpbiBtb2RlbHMuIA0KPj4NCj4+Q29uc2lkZXIgdGhp cyBhIHR3byB3ZWVrIG5vdGljZSBmb3IgdGhlIG1lZXRpbmcuIERldGFpbHMgd2lsbCBiZSBzZW50 IG91dCBsYXRlci4NCj4+DQo+Pk1haGVzaCAmIE1laG1ldA0KPg0KPg0KPk9rYXksIHdlIGhhZCB0 aGUgaW50ZXJpbS4gIFRoZSBzbGlkZXMgSSBwcmVzZW50ZWQgdGhlbiBhcmUgYXR0YWNoZWQuDQo+ DQo+T2YgdGhlIHZhcmlvdXMgcHJvcG9zYWxzIGxpc3RlZCBpbiB0aGUgc2xpZGVzLCB0aGUgaW50 ZXJpbeKAmXMgY29uc2Vuc3VzIHdhcyB0byBtb3ZlIGZvcndhcmQgd2l0aCBlaXRoZXIgcHJvcG9z YWwgIzIgb3IgcHJvcG9zYWwgIzMgKHNsaWRlcyA4IGFuZCA5KS4gIFRoZSBvbmx5IGRpZmZlcmVu Y2UgYmV0d2VlbiB0aGVzZSBwcm9wb3NhbHMgaXMgdGhhdCAjMyBzcGxpdHMgb3V0IHRoZSByZXN0 Y29uZiBjbGllbnQvc2VydmVyIG1vZGVscyBpbnRvIGl0cyBvd24gZHJhZnQsIGFzIG9wcG9zZWQg dG8gaGF2aW5nIHRoZW0gaW4gdGhlIHNhbWUgZHJhZnQgd2l0aCB0aGUgbmV0Y29uZiBjbGllbnQv c2VydmVyIG1vZGVscy4NCj4NCj5Bc3N1bWluZyB0aGUgaW50ZXJpbeKAmXMgY29uc2Vuc3VzIGlz IHVwaGVsZCBoZXJlIG9uIGxpc3QsIHdlIG5vdyBuZWVkIHRvIHBpY2sgYmV0d2VlbiBwcm9wb3Nh bHMgIzIgYW5kICMzLiAgIEZXSVcsIEkgaGF2ZSBhIHNsaWdodCBwcmVmZXJlbmNlIGZvciAjMyBv bmx5IGJlY2F1c2UgSSBsaWtlIHRoZSBjb25zaXN0ZW5jeSBvZiBpdC4gIEFueSBvdGhlciBvcGlu aW9ucz8NCj4NCj5UaGFua3MsDQo+S2VudA0KPg0KPg0KDQo= From nobody Tue May 31 17:49:42 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A881A12D13C for ; Tue, 31 May 2016 17:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03aZqO_5YznP for ; Tue, 31 May 2016 17:49:35 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 034EC12D57A for ; Tue, 31 May 2016 17:49:35 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id c127so4340941ywb.1 for ; Tue, 31 May 2016 17:49:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=SpO8UfW9P/yQuq5pNiJioAG/yqghQFoCut7LXxaMS+0=; b=AiVLsF6bcS2P2ohck9LfQwVASAMkcBfTA9VMd2DDtFbqfMkISyKLz2/hUhnmL25rYc HWtvJE/FvnBuC2b9gYKeB/l3rCgWjxzUiBc6v8lZq8HrP12M2ZYOqpDN1Y/Oum9hwUgQ Flr2Hz8fYjFGzWIxjcf4sRqAMYRz4uqJiAVmsG1CVZmEq62kLYPoJEG8szp4li8bma8b WmmYFP6NqiTFPfT2oIRAfxPW/JJpMyLzzXDos7Eg/YZ1KqwIIEsH4GUtjWeECMyj/9Q/ nT304uqgmg14bbw/jNlMVbNul1G5m1ZQENR51V1GUGuawmfchMYuEh1Uw+J7ilDhKuoC UkQg== 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; bh=SpO8UfW9P/yQuq5pNiJioAG/yqghQFoCut7LXxaMS+0=; b=hUxoVrewG4aIqB0H9bIro76Hi6FiqyP0CoZ5195FOKuLrLDD20l8RzomM4AwiK+3RY bW4gr1FwNn7tB9K51mBNxzmG8JXMnZTc+C98QlyaZQNiD2tFVg+CawirDKSO3M9WKfwn FX+KgWyj+5it32XtieUCksPxLLvsk57bKNiXhec4ak9mIHPe5XNIqtYAjMf2J3VrslNz 8u2WneeMoBeQa5VVl0jn7VHJISalCKr0IaGHCUIUc89yPrcHzWlS2ftq0cKnkYzZ8seX E3Zyoys6JnNsju+h/Cx5dmcqzyCLua1t/0s2BYyKACsEYYpQfFO6wGrkQot9M203RzB3 e2Hw== X-Gm-Message-State: ALyK8tJKkNHUw4rQcDr8FA9b1cfpmT1LpiHQ6eTKXNunfsjBwLXwTiPQYuhVndv1QrrVMuKRnAmcHIvkJYcDcQ== MIME-Version: 1.0 X-Received: by 10.13.202.15 with SMTP id m15mr548361ywd.259.1464742174022; Tue, 31 May 2016 17:49:34 -0700 (PDT) Received: by 10.37.115.208 with HTTP; Tue, 31 May 2016 17:49:33 -0700 (PDT) In-Reply-To: References: <01f401d1a54f$621dbad0$26593070$@seguesoft.com> <20160531.105003.567321207823725528.mbj@tail-f.com> Date: Tue, 31 May 2016 17:49:33 -0700 Message-ID: From: Andy Bierman To: "Sterne, Jason (Nokia - CA)" Content-Type: multipart/alternative; boundary=001a11481ab6f89e9705342cdc5a Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Clarification request for NETCONF edit-config default-operation replace X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 00:49:41 -0000 --001a11481ab6f89e9705342cdc5a Content-Type: text/plain; charset=UTF-8 Hi, I don't think needs to be changed to provide the same replace semantics as . copy-config is for complete configurations. There is an unwritten assumption that the copy-config contents are not pruned at all by access control. A missing node will be interpreted as a delete attempt. This is not at all desirable if the client is not authorized and is not even aware of these "hidden" nodes. Andy On Tue, May 31, 2016 at 6:36 AM, Sterne, Jason (Nokia - CA) < jason.sterne@nokia.com> wrote: > Thx Martin. Your explanation that a default replace operation can only > apply to elements that are in the request helps a lot. > > So there really is no such thing as an edit-config 'replace' operation > that operates "at the root". That can only be done with a special dedicated > RPC (e.g. copy-config as you show in Case 5). > > So my case 4 is equivalent to this: > > > > > > > 10 > > > > > > which will replace the entire contents of the /system subtree (but not > anything else). > > On a related note -> is the final result (i.e. datastore contents) of a > replace operation always exactly the same as a remove + merge with the same > data at the same location ? I can't think of an example where that isn't > true but I may be missing some corner case. > > For the candidate datastore it seems that 'replace' is simply a shorthand > way to do remove+merge in a single edit-config. For a running datastore > (writeable-running) the impacts would be quite different though since the > edit-config 'remove' would be applied immediately which would clear out all > config for a short period before the 'merge' then gets processed. > > Regards, > Jason > > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Tuesday, May 31, 2016 4:50 > To: Sterne, Jason (Nokia - CA) > Cc: xiangli@seguesoft.com; wivory@Brocade.com; netconf@ietf.org > Subject: Re: [Netconf] Clarification request for NETCONF edit-config > default-operation replace > > "Sterne, Jason (Nokia - CA)" wrote: > > Hi guys, > > > > I think there is some conflicting information wrt default-operation > > replace here. > > I agree it is not clear. > > > The following snippet of RFC 6241 clearly states (IMO) that the entire > > config is affected/replaced. The first sentence says it. > > I don't think this statement clearly says that the entire datastore is > replaced. It uses the term "completely replace". I don't know how that is > different from "replace". IMO, "replace" implies "completely"... > > > Then the second sentence gives yet another indication that it replaces > > the entire config: > > Not necessarily. > > > > replace: The configuration data in the parameter > > > completely replaces the configuration in the target > > > datastore. This is useful for loading previously saved > > > configuration data. > > > > > > I also found an older discussion on this on the mailing list that > > indicates that a default action of replace is intended to be used for > > the entire datastore. From > > > https://mailarchive.ietf.org/arch/msg/netconf/s4KOJxIgbDzqAXS-uF_jFi-iQsU: > > > > > > > 1) > > > $backup = get-config(source=running) > > > 2) > > > copy-config(source=$backup, target=running) OR > > > edit-config(source=$backup, target=running, > > > default-operation=replace)" > > > > > > operations are inherited. The default-operation applies > > to all top level objects. But I'm not certain whether it applies to > > all top level objects in the data model on the server or just all the > > top level objects that are included in the request. > > The latter. It is just a default value for the "operation" attribute; > i.e., instead of using "default-operation", you could explicitly set the > "operation" attribute - and you can only do that for the elements in the > request (obvioulsy). > > > From the descriptions above it seems it must apply to all top level > > objects in the server but that seems to conflict with: > > > > > "only the configuration actually present in the parameter > > > is affected" > > > > Here is a set of examples that may help clarify things. The first 3 > > cases are an incremental lead-in to case 4 which is the least clear > > for me. > > > > ## Initial server Config A (used in all the cases below): > > > > > > 12 > > true > > > > > > 132 > > true > > > > > > > > > > 8 > > true > > > > > > > > ## Case 1: > > - Initial Config A > > - edit-config request (no default operation): > > > > > > 10 > > > > > > - Resulting config on the server (only 'min-length' affected): > > > > > > 10 > > true > > > > > > 132 > > true > > > > > > > > > > 8 > > true > > > > > > > > ## Case 2: > > - Initial Config A > > - edit-config request (no default operation): > > > > > > 10 // inherited replace > > > > > > - Resulting config on the server (all 'password-control' affected): > > > > > > 10 > > > > > > 132 > > true > > > > > > > > > > 8 > > true > > > > > > > > ## Case 3: > > - Initial Config A > > - edit-config request (no default operation): > > > > // inherited replace > > 10 // inherited replace > > > > > > - Resulting config on the server (all 'system' affected) : > > > > > > 10 > > > > > > > > > > 8 > > true > > > > > > > > ## Case 4: > > - Initial Config A > > - edit-config request (!! with default-operation replace !!): > > > > > > 10 > > > > > > - Resulting config on the server (entire server datastore affected ?): > > > > > > 10 > > > > > > // no qos data ? > > This is not correct; qos is unaffected. > > ## Case 5: > - Initial Config A > - copy-config request > > > 10 > > > - Resulting config on the server (entire server datastore affected !): > > > 10 > > > // no qos data ! > > > > /martin > > > > > > > Regards, > > Jason > > > > -----Original Message----- > > From: EXT Xiang Li [mailto:xiangli@seguesoft.com] > > Sent: Tuesday, May 03, 2016 11:21 > > To: Sterne, Jason (Nokia - CA); 'Martin Bjorklund'; wivory@Brocade.com > > Cc: netconf@ietf.org > > Subject: RE: [Netconf] Clarification request for NETCONF edit-config > > default-operation replace > > > > Hi > > > > > -----Original Message----- > > >... > > > In my first question I meant "using an ": > > > > > > Is there no way to delete (or replace) the entire contents of the > > datastore > > > using an (and without using without > > > having to explicitly list every single top level node ? > > > > > > > I don't think edit-config is designed to do that. > > > > To delete a datastore, use , although can't > > be deleted. > > To replace the *entire config*, use . > > > > > From the description of the default-operation 'replace' it seems it > > > is > > possible > > > via the default operation: > > > replace: The configuration data in the parameter > > > completely replaces the configuration in the target > > > datastore. This is useful for loading previously saved > > > configuration data. > > > > > > No. The definition of "replace" as an operation says clearly: > > > > Unlike a operation, which replaces the entire > target > > configuration, only the configuration actually present in > > the parameter is affected. > > > > In other words, the only replaces the data nodes that exist > > in the target and for nodes that are in in the > > but not in the target, they are created. Other nodes that > > exist in the device but are not present in the of the > > are NOT affected in any way (this is the key difference > > with , where they are removed because it operates on the > > *entire* datastore.) > > > > > But can replace of the entire contents be done without replace as > > > the > > default > > > operation ? > > > > Not with the default "replace" operation, nor with the normal > > "replace" > > operation. > > The default "replace" operation has no additional semantics compared > > to The "operation" parameter > > > > > Or delete of the entire contents ? The RFC doesn't seem to clear on > > > whether we can use an operation on the node: > > > > > > > > > > > > The description of says: the target configuration is not > > necessarily replaced, as with the message. Instead, the > > target configuration is changed in accordance with the source's data > > and requested operations. > > > > In other words, the parameter in will not be > > valid if you do not specify it (assuming no url capability) or make it > > empty, as in your example. > > > > config: A hierarchy of configuration data as defined by one of > > the device's data models. The contents MUST be placed in an > > appropriate namespace, to allow the device to detect the > > appropriate data model, and the contents MUST follow the > > constraints of that data model, as defined by its capability > > definition. > > > > > > > (c) and (d) have a delete operation on a leaf (in (c) is it > > > inherited) but > > are > > > providing a value for the leaf at the same time. What is the meaning > > > of > > the > > > value ? That seems like an error to me. We should warn the client > > > that they've done something unexpected (the client may have been > > > intending to do something different than deleting that leaf). > > > I can see how that works when the leaf is a key leaf in a list. But > > > it > > seems like > > > an error for just a plain leaf. > > > > > > No. I think the value is actually used by . For example, > > RFC6241 > > has this example: > > > > Delete the configuration for an interface named "Ethernet0/0" from > > the running configuration: > > > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > > > > none > > > > > > > > Ethernet0/0 > > > > > > > > > > > > > > > > Without specifying value so that the device can find an exact matched > > interface, this won't work. > > > > In other words, my understanding is that if a value is given, and the > > device > > > > can't find a match then then the delete will fail with a > > error. > > > > > I'm also not convinced about (f) and (g). Wrt your analogy of a > > > directory > > with > > > files: you can delete a container in NETCONF and that automatically > > deletes > > > any children, grandchildren and so on (the entire subtree). It > > > seems > > strange > > > that there is no way to delete (or replace) the entire contents of a > > > list > > or leaf- > > > list. > > > > I don't necessarily disagree with you on this one. > > > > I was simply suggesting that the protocol perhaps should have a simple > > way to allow me to remove list entries. In particular I think it would > > be useful it allows: > > 1) to delete a specific list entry by providing a list entry's > > Instance ID ( all key nodes and corresponding values). > > 2) to delete all entries of a list by just providing all key nodes in > > the . > > > > Best, > > --Xiang > > > > > > > > > Or perhaps I'm misinterpreting the description of the replace and > > > delete operations in RFC6241 (the sentences "only the configuration > > > actually present in the parameter is affected" and "if and > > > only if the configuration data currently exists" are giving me some > > > pause here). > > There > > > aren't many examples illustrating delete & replace in the RFC. > > > > > > Regards, > > > Jason > > > > > > -----Original Message----- > > > From: EXT Xiang Li [mailto:xiangli@seguesoft.com] > > > Sent: Friday, April 29, 2016 20:05 > > > To: Sterne, Jason (Nokia - CA); 'Martin Bjorklund'; > > > wivory@Brocade.com > > > Cc: netconf@ietf.org > > > Subject: RE: [Netconf] Clarification request for NETCONF edit-config > > default- > > > operation replace > > > > > > > > > > > > -----Original Message----- > > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Sterne, > > > Jason (Nokia - CA) > > > Sent: Friday, April 29, 2016 2:12 PM > > > To: Martin Bjorklund ; wivory@Brocade.com > > > Cc: netconf@ietf.org > > > Subject: Re: [Netconf] Clarification request for NETCONF edit-config > > default- > > > operation replace > > > > > > Is there no way to delete the entire contents of the datastore > > > without > > having > > > to explicitly list every single top level node ? > > > > > > e.g. > > > with no default operation (i.e. merge): > > > > > > > > > Or > > > With default operation = delete: > > > > > > > > > Similarly -> Is there no way to replace the entire contents of the > > datastore ? > > > > > > [XL] I think< copy-config> or can do this. > > > > > > About the cases below shouldn't (c) and (d) return an error ? They > > contain > > > data for an object that is being deleted. (e) seems like the > > > correct way > > to do > > > it. > > > > > > [XL] I think Martin's explanation is correct. My understanding is > > > that if > > the > > > value does not match, then the would return an error since > > > the no matching data node found (yes I view this as a content-match). > > > Or I might > > be > > > totally wrong here, i.e., the value does not matter in any way as > > > Martin > > said? > > > > > > (f) and (g) surprise me. If I can an entire leaf-list > > > or > > list by just > > > specifying the tag for the leaf-list/list name, why doesn't delete > > > get rid > > of the > > > entire leaf-list/list ? > > > (if you specify a specific list entry/member in a delete it is > > > basically > > just a > > > content match node but otherwise you've selected the entire list no > > > ?). > > > > > > [XL] I also thought that I can delete a list entry by specifying > > > all key > > nodes > > > and their values (i.e., list entry's instance ID). If no values of > > > key > > nodes are > > > given, then the entire list entries matched and all of them should > > > be > > deleted. > > > Although Martin's explanation also makes sense here, that is, you > > > can't > > just > > > delete a key node yet if it is still used by non-key nodes. > > > Just like deleting a directory when the directory still contains > > > files. > > But, in any > > > case, I would still like that I can delete a list entry by giving > > > the > > list entry's IID > > > since we can unmistakably identify a list entry by given a list > > > entry's > > IID (i.e. , > > > all key nodes and their corresponding values). I think such a > > > delete operation would be useful, just like "rm -rf directory". > > > > > > --Xiang > > > -----Original Message----- > > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Martin > > > Bjorklund > > > Sent: Friday, April 15, 2016 10:49 > > > To: wivory@Brocade.com > > > Cc: netconf@ietf.org > > > Subject: Re: [Netconf] Clarification request for NETCONF edit-config > > default- > > > operation replace > > > > > > William Ivory wrote: > > > > OK - I think it might help if I gave some specific examples, with > > > > my understanding of what would get deleted and you can tell me if > > > > I'm correct or not. Apologies for length, but I'd like to avoid > > > > any confusion by not spelling out my queries, and I'm struggling > > > > to get a clear picture of how this all works with all the > > > > different permutations! > > > > > > > > Let's take a configuration like this: > > > > > > > > > > > > leafValue > > > > leaflistValueOne > > > > leaflistValueTwo > > > > > > > > firstEntryKey > > > > firstEntryLeaf > > > > > > > > > > > > secondEntryKey > > > > secondEntryLeaf > > > > > > > > > > > > > > > > --- > > > > > > > > (a) topCont, default operation delete > > > > > > > > With the default operation set to delete: > > > > > > > > > > > > > > > > > > > > > > > > => topCont, and everything under it, would be deleted > > > > > > Yes. > > > > > > > (b) topCont, operation delete > > > > > > > > With the default operation set to none: > > > > > > > > > > > > > > > > > > > > > > > > => topCont, and everything under it, would be deleted > > > > > > > > > > Yes. > > > > > > > --- > > > > > > > > (c) aLeaf delete, operation specified for topCont > > > > > > > > With the default operation set to none: > > > > > > > > > > > > > > > > leafValue > > > > > > > > > > > > => Will delete aLeaf node. If this leaves topCont empty, then > > > > topCont would be removed. If topCont still contains other > > > > elements, topCont would remain? > > > > > > No. This deletes the topCont and everything below it. > > > > > > > --- > > > > > > > > (d) aLeaf delete, operation specified for aLeaf > > > > > > > > With the default operation set to none: > > > > > > > > > > > > > > > > leafValue > > > > > > > > > > > > => Will delete aLeaf node. If this leaves topCont empty, then > > > > topCont would be removed unless it is a presence node. > > > > > > Yes (s/would/may/) > > > > > > > --- > > > > > > > > (e) aLeaf delete, operation specified for aLeaf, but no value > > > > given > > > > > > > > With the default operation set to none: > > > > > > > > > > > > > > > > > > > > > > > > => Would this delete aLeaf, and, as per (d), conditionally > > > > , or must the value of the leaf be specified? > > > > > > > > > > Yes, this would delete aLeaf. The value doesn't matter. > > > > > > > --- > > > > > > > > (f) aLeafListEntry > > > > > > > > Is there a way to delete all leaflist entries without specifying > > > > them individually, eg: > > > > > > > > > > > > > > No > > > > > > > > > > > > > > ... or, assuming there are other sibling nodes such that we can't > > > > just delete topCont, must I specify each individual leaflist > > > > element I wish to remove? > > > > > > > > --- > > > > > > > > (g) aListEntry > > > > > > > > As per leaflist entries, is there a way to delete all entries > > > > generically > > > > > > No. > > > > > > >, or must each be specified? > > > > > > Yes. > > > > > > > Separately, if I delete a non-key node inside a list entry, I > > > > assume that just deletes that node. If I delete the list's key > > > > node, then presumably that removes the complete entry, eg: > > > > > > > > > > > > > > > > > > > > firstEntryKey > > > > > > > > > > > > > > Yes > > > > > > > Would the following achieve the same, ie removal of this list entry: > > > > > > > > > > > > > > > > > > > > firstEntryKey > > > > > > > > > > > > > > Hmm. I would say that this results in an error - deleting just the > > > key of > > a list is > > > not possible. > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > --- > > > > > > > > Thanks for bearing with me, > > > > > > > > William > > > > > > > > -----Original Message----- > > > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > > > Sent: 15 April 2016 13:44 > > > > To: William Ivory > > > > Cc: netconf@ietf.org > > > > Subject: Re: [Netconf] Clarification request for NETCONF > > > > edit-config default-operation replace > > > > > > > > William Ivory wrote: > > > > > Hi Martin, > > > > > > > > > > Thanks - I think that the section on 'replace' under > > > > > 'default-operation' could do with being clarified next time the > > > > > RFC is updated then. > > > > > > > > > > I'd appreciate some further clarification on what exactly ' only > > > > > the configuration actually present in the parameter is > > > > > affected' > > > > > means in practice. > > > > > > > > > > First, the general pattern of examples which use > > > > > 'operation=' is that this command is put in the 'parent' > > > > > element's tag, ie the tag which specifies 'delete' is *not* > deleted. > > > > > > > > No. For example: > > > > > > > > > > > > 192.0.2.4 > > > > > > > > > > > > will delete the "interface" node with the name "192.0.2.4" > > > > > > > > It does NOT keep the "interface" node and just delete the "name" > node. > > > > > > > > > How then would you delete a top-level container? > > > > > > > > > > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > The examples have a > > > > > '' element but in cases where there are multiple top-level > > > > > nodes, some of which are optional in the configuration (ie not > > > > > presence containers), is it possible to delete these nodes? > > > > > > > > > > Secondly, if I'm correct that the 'delete' operation would only > > > > > affect nodes below the one with the delete operation, is it > > > > > possible to construct an edit-config PDU that would delete all > > > > > child nodes without having to explicitly specify each one? Or > > > > > is the only way to achieve this either to explicitly specify all > > > > > config to be removed, or to do a copy-config explicitly > > > > > specifying all config that is not to be deleted. > > > > > > > > > > Thanks, > > > > > > > > > > William > > > > > > > > > > -----Original Message----- > > > > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > > > > Sent: 14 April 2016 09:34 > > > > > To: William Ivory > > > > > Cc: netconf@ietf.org > > > > > Subject: Re: [Netconf] Clarification request for NETCONF > > > > > edit-config default-operation replace > > > > > > > > > > Hi, > > > > > > > > > > William Ivory wrote: > > > > > > Hi, > > > > > > > > > > > > I'd appreciate clarification of how the NETCONF edit-config > > > > > > command should work with default-operation set to 'replace'. > > > > > > For the most part, the edit-config section is clear that > > > > > > config will only be replaced if explicitly overwritten (ie if > > > > > > you provide replacement config for given nodes). However, the > > > > > > section on default-operation is less clear: > > > > > > > > > > > > The parameter is optional, but if > > > provided, > > > > > > it has one of the following values: > > > > > > > > > > > > merge: The configuration data in the > parameter is > > > > > > merged with the configuration at the corresponding > > > > > > level > > > in > > > > > > the target datastore. This is the default behavior. > > > > > > > > > > > > replace: The configuration data in the > parameter > > > > > > completely replaces the configuration in the target > > > > > > datastore. This is useful for loading previously > saved > > > > > > configuration data. > > > > > > > > > > > > Specifically, while 'merge' states that merge happesn with > > > > > > 'configuration as the corresponding level', 'replace' states > > > > > > that is 'completely replaces' the configuration, suggesting > > > > > > that it will remove ALL existing configuration regardless of > > > > > > what is explicitly provided as the replacement. Is that > > > > > > correct, or is 'replace' meant to have equivalent semantics to > > > > > > 'merge' ie it will only replace configuration when an explicit > > > > > > replacement is provided. In other words, if the latter case > > > > > > is correct, all it does is remove the requirement to specify > > > > > > the operation in each > > > element of new config. > > > > > > > > > > Yes the latter is correct. Note that the definition of "replace" > > > > > as an operation says: > > > > > > > > > > Unlike a > > > > > operation, which replaces the entire > target > > > > > configuration, only the configuration actually present > in > > > > > the parameter is affected. > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a11481ab6f89e9705342cdc5a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I don't think <edit-config&g= t; needs to be changed to provide the
same replace semantics as &= lt;copy-config>. =C2=A0copy-config is
for complete configurati= ons.

There is an unwritten assumption that the cop= y-config contents are
not pruned at all by access control. A miss= ing node will be interpreted as a delete attempt.
This is not at = all desirable if the client is not authorized and is not even aware
of these "hidden" nodes. =C2=A0


<= /div>
Andy


On Tue, May 31, 2016 at 6:36 AM, Sterne, Jason (Nok= ia - CA) <jason.sterne@nokia.com> wrote:
Thx Martin.=C2=A0 Your explanation that a default repla= ce operation can only apply to elements that are in the request helps a lot= .

So there really is no such thing as an edit-config 'replace' operat= ion that operates "at the root". That can only be done with a spe= cial dedicated RPC (e.g. copy-config as you show in Case 5).

So my case 4 is equivalent to this:

>=C2=A0 =C2=A0 =C2=A0 <system operation=3D'replace'>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <password-control operation=3D'repla= ce'>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <min-length operation=3D'repl= ace'>10</min-length>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </password-control>
>=C2=A0 =C2=A0 =C2=A0 </system>

which will replace the entire contents of the /system subtree (but not anyt= hing else).

On a related note -> is the final result (i.e. datastore contents) of a = replace operation always exactly the same as a remove + merge with the same= data at the same location ?=C2=A0 I can't think of an example where th= at isn't true but I may be missing some corner case.

For the candidate datastore it seems that 'replace' is simply a sho= rthand way to do remove+merge in a single edit-config.=C2=A0 For a running = datastore (writeable-running) the impacts would be quite different though s= ince the edit-config 'remove' would be applied immediately which wo= uld clear out all config for a short period before the 'merge' then= gets processed.

Regards,
Jason

-----Original Message-----
From: Martin Bjorklund [mailto:mbj@tail-f= .com]
Sent: Tuesday, May 31, 2016 4:50
To: Sterne, Jason (Nokia - CA)
Cc: xiangli@seguesoft.com; wiv= ory@Brocade.com; netconf@ietf.org Subject: Re: [Netconf] Clarification request for NETCONF edit-config defaul= t-operation replace

"Sterne, Jason (Nokia - CA)" <jason.sterne@nokia.com> wrote:
> Hi guys,
>
> I think there is some conflicting information wrt default-operation > replace here.

I agree it is not clear.

> The following snippet of RFC 6241 clearly states (IMO) that the entire=
> config is affected/replaced.=C2=A0 The first sentence says it.

I don't think this statement clearly says that the entire datastore is = replaced.=C2=A0 It uses the term "completely replace".=C2=A0 I do= n't know how that is different from "replace".=C2=A0 IMO, &qu= ot;replace" implies "completely"...

> Then the second sentence gives yet another indication that it replaces=
> the entire config:

Not necessarily.

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0replace:=C2=A0 The configuration= data in the <config> parameter
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 completely replaces the = configuration in the target
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 datastore.=C2=A0 This is= useful for loading previously saved
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 configuration data.
>
>
> I also found an older discussion on this on the mailing list that
> indicates that a default action of replace is intended to be used for<= br> > the entire datastore.=C2=A0 From
> https://mailarchive.ie= tf.org/arch/msg/netconf/s4KOJxIgbDzqAXS-uF_jFi-iQsU:
>
>
> >=C2=A0 1)
> >=C2=A0 =C2=A0 $backup =3D get-config(source=3Drunning)
> >=C2=A0 2)
> >=C2=A0 =C2=A0 copy-config(source=3D$backup, target=3Drunning)=C2= =A0 OR
> >=C2=A0 =C2=A0 edit-config(source=3D$backup, target=3Drunning,
> >=C2=A0 =C2=A0 default-operation=3Dreplace)"
>
>
> <edit-config> operations are inherited. The default-operation ap= plies
> to all top level objects.=C2=A0 But I'm not certain whether it app= lies to
> all top level objects in the data model on the server or just all the<= br> > top level objects that are included in the <edit-config> request= .

The latter.=C2=A0 It is just a default value for the "operation" = attribute; i.e., instead of using "default-operation", you could = explicitly set the "operation" attribute - and you can only do th= at for the elements in the request (obvioulsy).

> From the descriptions above it seems it must apply to all top level > objects in the server but that seems to conflict with:
>
> >=C2=A0 "only the configuration actually present in the <co= nfig> parameter
> > is=C2=A0 affected"
>
> Here is a set of examples that may help clarify things. The first 3 > cases are an incremental lead-in to case 4 which is the least clear > for me.
>
> ## Initial server Config A (used in all the cases below):
>=C2=A0 =C2=A0<system>
>=C2=A0 =C2=A0 =C2=A0<password-control>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<min-length>12</min-length>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<require-caps>true<require-caps>=
>=C2=A0 =C2=A0 =C2=A0</password-control>
>=C2=A0 =C2=A0 =C2=A0<console>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<width>132</width>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<enabled>true</enabled>
>=C2=A0 =C2=A0 =C2=A0</console>
>=C2=A0 =C2=A0</system>
>=C2=A0 =C2=A0<qos>
>=C2=A0 =C2=A0 =C2=A0<ingress>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<class-limit>8</class-limit>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<sub-classes>true</sub-classes><= br> >=C2=A0 =C2=A0 =C2=A0</ingress>
>=C2=A0 =C2=A0</qos>
>
> ## Case 1:
> - Initial Config A
> - edit-config request (no default operation):
>=C2=A0 =C2=A0 =C2=A0 <system>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <password-control>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <min-length operation=3D'repl= ace'>10</min-length>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </password-control>
>=C2=A0 =C2=A0 =C2=A0 </system>
> - Resulting config on the server (only 'min-length' affected):=
>=C2=A0 =C2=A0 =C2=A0 <system>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <password-control>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <min-length>10</min-length&= gt;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <require-caps>true<require-= caps>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </password-control>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <console>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <width>132</width>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <enabled>true</enabled><= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 </console>
>=C2=A0 =C2=A0 =C2=A0 </system>
>=C2=A0 =C2=A0 =C2=A0 <qos>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <ingress>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <class-limit>8</class-limit= >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <sub-classes>true</sub-clas= ses>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </ingress>
>=C2=A0 =C2=A0 =C2=A0 </qos>
>
> ## Case 2:
> - Initial Config A
> - edit-config request (no default operation):
>=C2=A0 =C2=A0 =C2=A0 <system>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <password-control operation=3D'repla= ce'>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <min-length>10</min-length&= gt;=C2=A0 =C2=A0// inherited replace
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </password-control>
>=C2=A0 =C2=A0 =C2=A0 </system>
> - Resulting config on the server (all 'password-control' affec= ted):
>=C2=A0 =C2=A0 =C2=A0 <system>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <password-control>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <min-length>10</min-length&= gt;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </password-control>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <console>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <width>132</width>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <enabled>true</enabled><= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 </console>
>=C2=A0 =C2=A0 =C2=A0 </system>
>=C2=A0 =C2=A0 =C2=A0 <qos>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <ingress>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <class-limit>8</class-limit= >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <sub-classes>true</sub-clas= ses>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </ingress>
>=C2=A0 =C2=A0 =C2=A0 </qos>
>
> ## Case 3:
> - Initial Config A
> - edit-config request (no default operation):
>=C2=A0 =C2=A0 =C2=A0 <system operation=3D'replace'>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <password-control>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// inherited replace
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <min-length>10</min-length&= gt;=C2=A0 // inherited replace
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </password-control>
>=C2=A0 =C2=A0 =C2=A0 </system>
> - Resulting config on the server (all 'system' affected) :
>=C2=A0 =C2=A0 =C2=A0 <system>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <password-control>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <min-length>10</min-length&= gt;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </password-control>
>=C2=A0 =C2=A0 =C2=A0 </system>
>=C2=A0 =C2=A0 =C2=A0 <qos>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <ingress>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <class-limit>8</class-limit= >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <sub-classes>true</sub-clas= ses>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </ingress>
>=C2=A0 =C2=A0 =C2=A0 </qos>
>
> ## Case 4:
> - Initial Config A
> - edit-config request (!! with default-operation replace !!):
>=C2=A0 =C2=A0 =C2=A0 <system>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <password-control>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <min-length>10</min-length&= gt;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </password-control>
>=C2=A0 =C2=A0 =C2=A0 </system>
> - Resulting config on the server (entire server datastore affected ?):=
>=C2=A0 =C2=A0 =C2=A0 <system>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <password-control>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <min-length>10</min-length&= gt;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </password-control>
>=C2=A0 =C2=A0 =C2=A0 </system>
>=C2=A0 =C2=A0 =C2=A0// no qos data ?

This is not correct; qos is unaffected.

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



/martin



>
> Regards,
> Jason
>
> -----Original Message-----
> From: EXT Xiang Li [mailto:xi= angli@seguesoft.com]
> Sent: Tuesday, May 03, 2016 11:21
> To: Sterne, Jason (Nokia - CA); 'Martin Bjorklund'; wivory@Bro= cade.com
> Cc: netconf@ietf.org
> Subject: RE: [Netconf] Clarification request for NETCONF edit-config > default-operation replace
>
> Hi
>
> > -----Original Message-----
> >...
> > In my first question I meant "using an <edit-config>&q= uot;:
> >
> > Is there no way to delete (or replace) the entire contents of the=
> datastore
> > using an <edit-config> (and without using <copy-config&g= t; without
> > having to explicitly list every single top level node ?
> >
>
> I don't think edit-config is designed to do that.
>
> To delete a datastore, use <delete-config>, although <running= > can't
> be deleted.
> To replace the *entire config*, use <copy-config>.
>
> > From the description of the default-operation 'replace' i= t seems it
> > is
> possible
> > via the default operation:
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 replace:=C2=A0 The configuratio= n data in the <config> parameter
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0completely replace= s the configuration in the target
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0datastore.=C2=A0 T= his is useful for loading previously saved
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0configuration data= .
>
>
> No. The definition of "replace" as an operation says clearly= :
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Unlike a=C2=A0 <copy= -config> operation, which replaces the entire target
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0configuration, only the= configuration actually present in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the <config> para= meter is affected.
>
> In other words, the <replace> only replaces the data nodes that = exist
> in the target and for nodes that are in <config> in the
> <edit-config>but not in the target, they are created. Other node= s that
> exist in the device but are not present in the <config> of the > <edit-config> are NOT affected in any way (this is the key diffe= rence
> with <copy-config>, where they are removed because it operates o= n the
> *entire* datastore.)
>
> > But can replace of the entire contents be done without replace as=
> > the
> default
> > operation ?
>
> Not with the default "replace" operation, nor with the norma= l
> "replace"
> operation.
> The default "replace" operation has no additional semantics = compared
> to The "operation" parameter
>
> > Or delete of the entire contents ?=C2=A0 The RFC doesn't seem= to clear on
> > whether we can use an operation on the <config> node:
> > <config operation=3D"delete"/>
> > <config operation=3D"replace"/>
>
>
> The description of <edit-config> says: the target configuration = is not
> necessarily replaced, as with the <copy-config> message.=C2=A0 I= nstead, the
> target configuration is changed in accordance with the source's da= ta
> and requested operations.
>
> In other words, the <config> parameter in <edit-config> wi= ll not be
> valid if you do not specify it (assuming no url capability) or make it=
> empty, as in your example.
>
> config:=C2=A0 A hierarchy of configuration data as defined by one of >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the device's data models.=C2=A0 = The contents MUST be placed in an
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 appropriate namespace, to allow the = device to detect the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 appropriate data model, and the cont= ents MUST follow the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 constraints of that data model, as d= efined by its capability
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 definition.
>
>
> > (c) and (d) have a delete operation on a leaf (in (c) is it
> > inherited) but
> are
> > providing a value for the leaf at the same time. What is the mean= ing
> > of
> the
> > value ? That seems like an error to me.=C2=A0 We should warn the = client
> > that they've done something unexpected (the client may have b= een
> > intending to do something different than deleting that leaf).
> > I can see how that works when the leaf is a key leaf in a list.= =C2=A0 But
> > it
> seems like
> > an error for just a plain leaf.
>
>
> No. I think the value is actually used by <edit-config>. For exa= mple,
> RFC6241
> has this example:
>
> Delete the configuration for an interface named "Ethernet0/0"= ; from
>=C2=A0 =C2=A0 the running configuration:
>
>=C2=A0 =C2=A0 =C2=A0 <rpc message-id=3D"101"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0xmlns=3D"urn:ietf:params:= xml:ns:netconf:base:1.0">
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <edit-config>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <target>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <running/>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </target>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <default-operation>none</de= fault-operation>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <config xmlns:xc=3D"urn:ietf= :params:xml:ns:netconf:base:1.0">
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <top xmlns=3D"http://example.com/schema/1.2/config">
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <interface xc:opera= tion=3D"delete">
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <name>Eth= ernet0/0</name>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </interface>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </top>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </config>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </edit-config>
>=C2=A0 =C2=A0 =C2=A0 </rpc>
>
>
> Without specifying value so that the device can find an exact matched<= br> > interface, this won't work.
>
> In other words, my understanding is that if a value is given, and the<= br> > device
>
> can't find a match then then the delete will fail with a
> <data-missing> error.
>
> > I'm also not convinced about (f) and (g).=C2=A0 Wrt your anal= ogy of a
> > directory
> with
> > files: you can delete a container in NETCONF and that automatical= ly
> deletes
> > any children, grandchildren and so on (the entire subtree).=C2=A0= It
> > seems
> strange
> > that there is no way to delete (or replace) the entire contents o= f a
> > list
> or leaf-
> > list.
>
> I don't necessarily disagree with you on this one.
>
> I was simply suggesting that the protocol perhaps should have a simple=
> way to allow me to remove list entries. In particular I think it would=
> be useful it allows:
> 1) to delete a specific list entry by providing a list entry's
> Instance ID ( all key nodes and corresponding values).
> 2) to delete all entries of a list by just providing all key nodes in<= br> > the <config>.
>
> Best,
> --Xiang
>
>
>
> > Or perhaps I'm misinterpreting the description of the replace= and
> > delete operations in RFC6241 (the sentences "only the config= uration
> > actually present in the <config> parameter is affected"= ; and "if and
> > only if the configuration data currently exists" are giving = me some
> > pause here).
> There
> > aren't many examples illustrating delete & replace in the= RFC.
> >
> > Regards,
> > Jason
> >
> > -----Original Message-----
> > From: EXT Xiang Li [mailto:xiangli@seguesoft.com]
> > Sent: Friday, April 29, 2016 20:05
> > To: Sterne, Jason (Nokia - CA); 'Martin Bjorklund';
> > wivory@Brocade.com
> > Cc: netconf@ietf.org
> > Subject: RE: [Netconf] Clarification request for NETCONF edit-con= fig
> default-
> > operation replace
> >
> >
> >
> > -----Original Message-----
> > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Sterne,
> > Jason (Nokia - CA)
> > Sent: Friday, April 29, 2016 2:12 PM
> > To: Martin Bjorklund <mbj@ta= il-f.com>; wivory@Brocade.com
> > Cc: netconf@ietf.org
> > Subject: Re: [Netconf] Clarification request for NETCONF edit-con= fig
> default-
> > operation replace
> >
> > Is there no way to delete the entire contents of the datastore > > without
> having
> > to explicitly list every single top level node ?
> >
> > e.g.
> > with no default operation (i.e. merge):
> > <config operation=3D"delete"/>
> >
> > Or
> > With default operation =3D delete:
> > <config/>
> >
> > Similarly -> Is there no way to replace the entire contents of= the
> datastore ?
> >
> > [XL] I think< copy-config> or <delete-config> can do = this.
> >
> > About the cases below shouldn't (c) and (d) return an error ?= =C2=A0 They
> contain
> > data for an object that is being deleted.=C2=A0 (e) seems like th= e
> > correct way
> to do
> > it.
> >
> > [XL] I think Martin's explanation is correct. My understandin= g is
> > that if
> the
> > value does not match, then the <delete> would return an err= or since
> > the no matching data node found (yes I view this as a content-mat= ch).
> > Or I might
> be
> > totally wrong here, i.e., the value does not matter in any way as=
> > Martin
> said?
> >
> > (f) and (g) surprise me.=C2=A0 If I can <get-config> an ent= ire leaf-list
> > or
> list by just
> > specifying the tag for the leaf-list/list name, why doesn't d= elete
> > get rid
> of the
> > entire leaf-list/list ?
> > (if you specify a specific list entry/member in a delete it is > > basically
> just a
> > content match node but otherwise you've selected the entire l= ist no
> > ?).
> >
> > [XL] I also thought that I can delete a list entry by specifying<= br> > > all key
> nodes
> > and their values (i.e., list entry's instance ID). If no valu= es of
> > key
> nodes are
> > given, then the entire list entries matched and all of them shoul= d
> > be
> deleted.
> > Although Martin's explanation also makes sense here, that is,= you
> > can't
> just
> > delete a key node yet if it is still used by non-key nodes.
> > Just like deleting a directory when the directory still contains<= br> > > files.
> But, in any
> > case,=C2=A0 I would still like that I can delete a list entry by = giving
> > the
> list entry's IID
> > since we can unmistakably identify=C2=A0 a list entry by given a = list
> > entry's
> IID (i.e. ,
> > all key nodes and their corresponding values).=C2=A0 I think such= a
> > delete operation would be useful,=C2=A0 just like "rm -rf di= rectory".
> >
> > --Xiang
> > -----Original Message-----
> > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Martin
> > Bjorklund
> > Sent: Friday, April 15, 2016 10:49
> > To: wivory@Brocade.com
> > Cc: netconf@ietf.org
> > Subject: Re: [Netconf] Clarification request for NETCONF edit-con= fig
> default-
> > operation replace
> >
> > William Ivory <wivory@Brocade.com> wrote:
> > > OK - I think it might help if I gave some specific examples,= with
> > > my understanding of what would get deleted and you can tell = me if
> > > I'm correct or not.=C2=A0 Apologies for length, but I= 9;d like to avoid
> > > any confusion by not spelling out my queries, and I'm st= ruggling
> > > to get a clear picture of how this all works with all the > > > different permutations!
> > >
> > > Let's take a configuration like this:
> > >
> > > <topCont>
> > >=C2=A0 =C2=A0 =C2=A0<aLeaf>leafValue</aLeaf>
> > >=C2=A0 =C2=A0 =C2=A0<aLeafListEntry>leaflistValueOne<= ;/aLeafListEntry>
> > >=C2=A0 =C2=A0 =C2=A0<aLeafListEntry>leaflistValueTwo<= ;/aLeafListEntry>
> > >=C2=A0 =C2=A0 =C2=A0<aListEntry>
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<listKey>firstEntryKe= y</listKey>
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<listLeaf>firstEntryL= eaf</listLeaf>
> > >=C2=A0 =C2=A0 =C2=A0</aListEntry>
> > >=C2=A0 =C2=A0 =C2=A0<aListEntry>
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<listKey>secondEntryK= ey</listKey>
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<listLeaf>secondEntry= Leaf</listLeaf>
> > >=C2=A0 =C2=A0 =C2=A0</aListEntry>
> > > </topCont>
> > >
> > > ---
> > >
> > > (a) topCont, default operation delete
> > >
> > > With the default operation set to delete:
> > >
> > > <config>
> > >=C2=A0 =C2=A0 =C2=A0<topCont>
> > > </config>
> > >
> > > =3D> topCont, and everything under it, would be deleted > >
> > Yes.
> >
> > > (b) topCont, operation delete
> > >
> > > With the default operation set to none:
> > >
> > > <config>
> > >=C2=A0 =C2=A0 =C2=A0<topCont xc:operation=3Ddelete>
> > > </config>
> > >
> > > =3D> topCont, and everything under it, would be deleted > > >
> >
> > Yes.
> >
> > > ---
> > >
> > > (c) aLeaf delete, operation specified for topCont
> > >
> > > With the default operation set to none:
> > >
> > > <config>
> > >=C2=A0 =C2=A0 =C2=A0<topCont xc:operation=3Ddelete>
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<aLeaf>leafValue</= aLeaf>
> > > </config>
> > >
> > > =3D> Will delete aLeaf node.=C2=A0 If this leaves topCont= empty, then
> > > topCont would be removed.=C2=A0 If topCont still contains ot= her
> > > elements, topCont would remain?
> >
> > No.=C2=A0 This deletes the topCont and everything below it.
> >
> > > ---
> > >
> > > (d) aLeaf delete, operation specified for aLeaf
> > >
> > > With the default operation set to none:
> > >
> > > <config>
> > >=C2=A0 =C2=A0 =C2=A0<topCont>
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<aLeaf xc:operation=3Dde= lete>leafValue</aLeaf>
> > > </config>
> > >
> > > =3D> Will delete aLeaf node.=C2=A0 If this leaves topCont= empty, then
> > > topCont would be removed unless it is a presence node.
> >
> > Yes=C2=A0 (s/would/may/)
> >
> > > ---
> > >
> > > (e) aLeaf delete, operation specified for aLeaf, but no valu= e
> > > given
> > >
> > > With the default operation set to none:
> > >
> > > <config>
> > >=C2=A0 =C2=A0 =C2=A0<topCont>
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<aLeaf xc:operation=3Dde= lete/> </config>
> > >
> > > =3D> Would this delete aLeaf, and, as per (d), conditiona= lly
> > > <topCont>, or must the value of the leaf be specified?=
> > >
> >
> > Yes, this would delete aLeaf.=C2=A0 The value doesn't matter.=
> >
> > > ---
> > >
> > > (f) aLeafListEntry
> > >
> > > Is there a way to delete all leaflist entries without specif= ying
> > > them individually, eg:
> > >
> > > <aLeafListEntry xc:operation=3Ddelete>
> >
> > No
> >
> >
> > >
> > > ... or, assuming there are other sibling nodes such that we = can't
> > > just delete topCont, must I specify each individual leaflist=
> > > element I wish to remove?
> > >
> > > ---
> > >
> > > (g) aListEntry
> > >
> > > As per leaflist entries, is there a way to delete all entrie= s
> > > generically
> >
> > No.
> >
> > >, or must each be specified?
> >
> > Yes.
> >
> > > Separately, if I delete a non-key node inside a list entry, = I
> > > assume that just deletes that node.=C2=A0 If I delete the li= st's key
> > > node, then presumably that removes the complete entry, eg: > > >
> > > <config>
> > >=C2=A0 =C2=A0 =C2=A0<topCont>
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<aListEntry xc:operation= =3Ddelete>
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<listKey&g= t;firstEntryKey</listKey>
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</aListEntry>
> > > </config>
> >
> > Yes
> >
> > > Would the following achieve the same, ie removal of this lis= t entry:
> > >
> > > <config>
> > >=C2=A0 =C2=A0 =C2=A0<topCont>
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<aListEntry >
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<listKey x= c:operation=3Ddelete >firstEntryKey</listKey>
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</aListEntry>
> > > </config>
> >
> > Hmm.=C2=A0 I would say that this results in an error - deleting j= ust the
> > key of
> a list is
> > not possible.
> >
> >
> >
> > /martin
> >
> >
> >
> > >
> > > ---
> > >
> > > Thanks=C2=A0 for bearing with me,
> > >
> > > William
> > >
> > > -----Original Message-----
> > > From: Martin Bjorklund [mailto:mbj@tail-f.com]
> > > Sent: 15 April 2016 13:44
> > > To: William Ivory <wivory@Brocade.com>
> > > Cc: netconf@ietf.org=
> > > Subject: Re: [Netconf] Clarification request for NETCONF
> > > edit-config default-operation replace
> > >
> > > William Ivory <wivory@Brocade.com> wrote:
> > > > Hi Martin,
> > > >
> > > > Thanks - I think that the section on 'replace' = under
> > > > 'default-operation' could do with being clarifi= ed next time the
> > > > RFC is updated then.
> > > >
> > > > I'd appreciate some further clarification on what e= xactly ' only
> > > > the configuration actually present in the <config>= ; parameter is
> > > > affected'
> > > > means in practice.
> > > >
> > > > First, the general pattern of examples which use
> > > > 'operation=3D<operation>' is that this co= mmand is put in the 'parent'
> > > > element's tag, ie the tag which specifies 'dele= te' is *not* deleted.
> > >
> > > No.=C2=A0 For example:
> > >
> > >=C2=A0 =C2=A0 =C2=A0<interface xc:operation=3D"delete= ">
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0<name>192.0.2.4</name>=
> > >=C2=A0 =C2=A0 =C2=A0</interface>
> > >
> > > will delete the "interface" node with the name &qu= ot;192.0.2.4"
> > >
> > > It does NOT keep the "interface" node and just del= ete the "name" node.
> > >
> > > > How then would you delete a top-level container?
> > >
> > >=C2=A0 <my-top-level-container nc:operation=3D"delete= "/>
> > >
> > >
> > >
> > > /martin
> > >
> > >
> > > > The examples have a
> > > > '<top>' element but in cases where there = are multiple top-level
> > > > nodes, some of which are optional in the configuration = (ie not
> > > > presence containers), is it possible to delete these no= des?
> > > >
> > > > Secondly, if I'm correct that the 'delete' = operation would only
> > > > affect nodes below the one with the delete operation, i= s it
> > > > possible to construct an edit-config PDU that would del= ete all
> > > > child nodes without having to explicitly specify each o= ne?=C2=A0 Or
> > > > is the only way to achieve this either to explicitly sp= ecify all
> > > > config to be removed, or to do a copy-config explicitly=
> > > > specifying all config that is not to be deleted.
> > > >
> > > > Thanks,
> > > >
> > > > William
> > > >
> > > > -----Original Message-----
> > > > From: Martin Bjorklund [mailto:mbj@tail-f.com]
> > > > Sent: 14 April 2016 09:34
> > > > To: William Ivory <wivory@Brocade.com>
> > > > Cc: netconf@ietf.or= g
> > > > Subject: Re: [Netconf] Clarification request for NETCON= F
> > > > edit-config default-operation replace
> > > >
> > > > Hi,
> > > >
> > > > William Ivory <wivory@Brocade.com> wrote:
> > > > > Hi,
> > > > >
> > > > > I'd appreciate clarification of how the NETCON= F edit-config
> > > > > command should work with default-operation set to = 'replace'.
> > > > > For the most part, the edit-config section is clea= r that
> > > > > config will only be replaced if explicitly overwri= tten (ie if
> > > > > you provide replacement config for given nodes).= =C2=A0 However, the
> > > > > section on default-operation is less clear:
> > > > >
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The <default-= operation> parameter is optional, but if
> > provided,
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 it has one of th= e following values:
> > > > >
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 merge:=C2=A0 The= configuration data in the <config> parameter is
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mer= ged with the configuration at the corresponding
> > > > > level
> > in
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the= target datastore.=C2=A0 This is the default behavior.
> > > > >
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 replace:=C2=A0 T= he configuration data in the <config> parameter
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0com= pletely replaces the configuration in the target
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0dat= astore.=C2=A0 This is useful for loading previously saved
> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0con= figuration data.
> > > > >
> > > > > Specifically, while 'merge' states that me= rge happesn with
> > > > > 'configuration as the corresponding level'= , 'replace' states
> > > > > that is 'completely replaces' the configur= ation, suggesting
> > > > > that it will remove ALL existing configuration reg= ardless of
> > > > > what is explicitly provided as the replacement.=C2= =A0 Is that
> > > > > correct, or is 'replace' meant to have equ= ivalent semantics to
> > > > > 'merge' ie it will only replace configurat= ion when an explicit
> > > > > replacement is provided.=C2=A0 In other words, if = the latter case
> > > > > is correct, all it does is remove the requirement = to specify
> > > > > the operation in each
> > element of new config.
> > > >
> > > > Yes the latter is correct.=C2=A0 Note that the definiti= on of "replace"
> > > > as an operation says:
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Unlike a=
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<copy= -config> operation, which replaces the entire target
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0configur= ation, only the configuration actually present in
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the <= config> parameter is affected.
> > > >
> > > >
> > > > /martin
> > > >
> > >
> >
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf=
> >
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf=
>
>

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

--001a11481ab6f89e9705342cdc5a--