From nobody Mon Jun 1 00:26:03 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ECA71A8ACC for ; Mon, 1 Jun 2015 00:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8JhjPkOpBVQ for ; Mon, 1 Jun 2015 00:25:59 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7008E1A8AA1 for ; Mon, 1 Jun 2015 00:25:59 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id BF10FF71; Mon, 1 Jun 2015 09:25:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id ZPPVuu7rL6oC; Mon, 1 Jun 2015 09:25:37 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 1 Jun 2015 09:25:57 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id EAED22002B; Mon, 1 Jun 2015 09:25:56 +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 njGU95GWkI21; Mon, 1 Jun 2015 09:25:56 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A1CC920013; Mon, 1 Jun 2015 09:25:55 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id BA9B734171C3; Mon, 1 Jun 2015 09:25:53 +0200 (CEST) Date: Mon, 1 Jun 2015 09:25:53 +0200 From: Juergen Schoenwaelder To: Mandy Liu Message-ID: <20150601072552.GA31467@elstar.local> Mail-Followup-To: Mandy Liu , "andy@netconfcentral.org" , Kai Lin , Robert Ottinger , "netconf@ietf.org" , Athanasios Kyparlis References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "andy@netconfcentral.org" , Athanasios Kyparlis , Robert Ottinger , "netconf@ietf.org" , Kai Lin Subject: Re: [Netconf] How to augment RFC6470 to supply detail configuration change information X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jun 2015 07:26:01 -0000 On Mon, Jun 01, 2015 at 06:51:27AM +0000, Mandy Liu wrote: > [...] So we need to find a common format for the "content" to > accommodate different types of "target". what I can imagine is > anyxml could be used. But seems it is not a good choice. Because > based on RFC6020, it is not recommended to be used on configuration > data. Since you plan to augment a notification, this won't be config true data (this is what the statement in RFC 6020 really hints at). See also the definition of 'configuration data' in section 3 of RFC 6020. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jun 1 00:49:00 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 680E31A8AED for ; Mon, 1 Jun 2015 00:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDLqqAGeFdPs for ; Mon, 1 Jun 2015 00:48:56 -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 71AF11A8AF5 for ; Mon, 1 Jun 2015 00:48:56 -0700 (PDT) X-AuditID: c1b4fb25-f79b66d000001131-21-556c0e658ed5 Received: from ESGSCHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 21.EF.04401.66E0C655; Mon, 1 Jun 2015 09:48:54 +0200 (CEST) Received: from ESGSCMB103.ericsson.se ([169.254.3.225]) by ESGSCHC002.ericsson.se ([146.11.116.71]) with mapi id 14.03.0210.002; Mon, 1 Jun 2015 15:48:52 +0800 From: Mandy Liu To: Juergen Schoenwaelder Thread-Topic: [Netconf] How to augment RFC6470 to supply detail configuration change information Thread-Index: AdCcN15yUJGf8sjGSmOLzB5x9r0Sx///g4mA//92nwA= Date: Mon, 1 Jun 2015 07:48:51 +0000 Message-ID: References: <20150601072552.GA31467@elstar.local> In-Reply-To: <20150601072552.GA31467@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [146.11.116.128] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyM+JvrW4aX06owaQ+dYtneyaxWFzd+JPR Yuqm26wOzB5Llvxk8thwwNPj493NLAHMUVw2Kak5mWWpRfp2CVwZr/pnMBasFqj4272UuYHx Kk8XIyeHhICJxNZHz9kgbDGJC/fWg9lCAkcZJW499epi5AKyFzNKtH74wwKSYBPQkHj8ahI7 iC0i4CDRv60brIFZ4A2jxNN5biC2sECixOxTaxkhapIkPu15yARhW0n8OL8UrJdFQEWife8j sBpeAV+JWQcXM3cxcgAtK5U4+yMBJMwpYCQx7ekfsBJGoNu+n1rDBLFKXOLWk/lMEDcLSCzZ c54ZwhaVePn4HyuErSTR+GobVL2OxILdn6DO1JZYtvA1M8RaQYmTM5+wTGAUm4Vk7CwkLbOQ tMxC0rKAkWUVo2hxanFSbrqRsV5qUWZycXF+nl5easkmRmA8HdzyW3UH4+U3jocYBTgYlXh4 F+zJDhViTSwrrsw9xCjNwaIkzuvZFRIqJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgZHX4OPL /f8jAueGfePtm+7S4yqp67FgQ+wDi/g/f2LcN51aMGku/9MvqU9yMl/ViL57dsou/Mu81M7V 67bPqMw+ducq08eE6c+nzLr2TDah75WL9w7Pnt7cPZ82cB/asv53413vd1M31CbI7U64ph9j KbZmqW/hZz/VzT5tzzsENO3L/rTkHNulxFKckWioxVxUnAgATl5Tb4gCAAA= Archived-At: Cc: "andy@netconfcentral.org" , Athanasios Kyparlis , Robert Ottinger , "netconf@ietf.org" , Kai Lin Subject: Re: [Netconf] How to augment RFC6470 to supply detail configuration change information X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 07:48:58 -0000 Sorry, I don't get your point. But hopefully I addressed my question more c= learly this time.=20 The configuration change notification is generated when the NETCONF server = detects that the or configuration datastore has been ch= anged by a management session. The notification summarizes the "edits" that= have been detected. " The structure of the "edit" is addressed in RFC6470= as below. What I want is to add the another leaf to address the "target" i= s changed to what. But because the "target" may be a container, a list, a l= eaf or a leaf-reference, etc. It could be any node of the tree. So a common= format for addressing the "target" is changed to what is needed.=20 list edit { leaf target { type instance-identifier; description ..... } leaf operation { type nc:edit-operation-type; description ..... } } Thanks, Mandy -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Monday, June 01, 2015 3:26 PM To: Mandy Liu Cc: andy@netconfcentral.org; Kai Lin; Robert Ottinger; netconf@ietf.org; At= hanasios Kyparlis Subject: Re: [Netconf] How to augment RFC6470 to supply detail configuratio= n change information On Mon, Jun 01, 2015 at 06:51:27AM +0000, Mandy Liu wrote: > [...] So we need to find a common format for the "content" to=20 > accommodate different types of "target". what I can imagine is anyxml=20 > could be used. But seems it is not a good choice. Because based on=20 > RFC6020, it is not recommended to be used on configuration data. Since you plan to augment a notification, this won't be config true data (t= his is what the statement in RFC 6020 really hints at). See also the defini= tion of 'configuration data' in section 3 of RFC 6020. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jun 1 02:55:06 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5621A9135 for ; Mon, 1 Jun 2015 02:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAt0tCBX_udr for ; Mon, 1 Jun 2015 02:55:02 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9953C1A9068 for ; Mon, 1 Jun 2015 02:55:02 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 67825E8A; Mon, 1 Jun 2015 11:55:01 +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 uBzwpRJRxYgz; Mon, 1 Jun 2015 11:54:40 +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, 1 Jun 2015 11:55:00 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 424022002B; Mon, 1 Jun 2015 11:55:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id DNpGyb6-jmSt; Mon, 1 Jun 2015 11:54:59 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 80B8320013; Mon, 1 Jun 2015 11:54:56 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8069434174E0; Mon, 1 Jun 2015 11:54:56 +0200 (CEST) Date: Mon, 1 Jun 2015 11:54:56 +0200 From: Juergen Schoenwaelder To: Mandy Liu Message-ID: <20150601095456.GD31801@elstar.local> Mail-Followup-To: Mandy Liu , "andy@netconfcentral.org" , Kai Lin , Robert Ottinger , "netconf@ietf.org" , Athanasios Kyparlis References: <20150601072552.GA31467@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "andy@netconfcentral.org" , Athanasios Kyparlis , Robert Ottinger , "netconf@ietf.org" , Kai Lin Subject: Re: [Netconf] How to augment RFC6470 to supply detail configuration change information X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jun 2015 09:55:05 -0000 Let me try to say it differently: Using anyxml in a notification does not cause a conflict with this statement in section 7.10 of RFC 6020: Since the use of anyxml limits the manipulation of the content, it is RECOMMENDED that the "anyxml" statement not be used to represent configuration data. Note that configuration data is defined as follows: o configuration data: The set of writable data that is required to transform a system from its initial default state into its current state [RFC4741]. Notification content is not configuration data. /js On Mon, Jun 01, 2015 at 07:48:51AM +0000, Mandy Liu wrote: > Sorry, I don't get your point. But hopefully I addressed my question more clearly this time. > > The configuration change notification is generated when the NETCONF server detects that the or configuration datastore has been changed by a management session. The notification summarizes the "edits" that have been detected. " The structure of the "edit" is addressed in RFC6470 as below. What I want is to add the another leaf to address the "target" is changed to what. But because the "target" may be a container, a list, a leaf or a leaf-reference, etc. It could be any node of the tree. So a common format for addressing the "target" is changed to what is needed. > list edit { > leaf target { > type instance-identifier; > description > ..... > } > leaf operation { > type nc:edit-operation-type; > description > ..... > } > } > > Thanks, > Mandy > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, June 01, 2015 3:26 PM > To: Mandy Liu > Cc: andy@netconfcentral.org; Kai Lin; Robert Ottinger; netconf@ietf.org; Athanasios Kyparlis > Subject: Re: [Netconf] How to augment RFC6470 to supply detail configuration change information > > On Mon, Jun 01, 2015 at 06:51:27AM +0000, Mandy Liu wrote: > > > [...] So we need to find a common format for the "content" to > > accommodate different types of "target". what I can imagine is anyxml > > could be used. But seems it is not a good choice. Because based on > > RFC6020, it is not recommended to be used on configuration data. > > Since you plan to augment a notification, this won't be config true data (this is what the statement in RFC 6020 really hints at). See also the definition of 'configuration data' in section 3 of RFC 6020. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jun 1 15:51:57 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A86F1A1A8A for ; Mon, 1 Jun 2015 15:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4_vZvobZaVnx for ; Mon, 1 Jun 2015 15:51:55 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0721.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:721]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C14C1A19FE for ; Mon, 1 Jun 2015 15:51:54 -0700 (PDT) Received: from CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) by CO1PR05MB505.namprd05.prod.outlook.com (10.141.71.140) with Microsoft SMTP Server (TLS) id 15.1.172.22; Mon, 1 Jun 2015 22:51:37 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.172.22; Mon, 1 Jun 2015 22:51:36 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.154]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.154]) with mapi id 15.01.0172.012; Mon, 1 Jun 2015 22:51:36 +0000 From: Kent Watsen To: Juergen Schoenwaelder , "netconf@ietf.org" Thread-Topic: [Netconf] WG Last Call for draft-ietf-netconf-call-home-04 and draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and server-model-06 available - All Open issues closed Thread-Index: AQHQVf+tT/7bNpWPUkyuK74/P/SDo50i7REAgAF9rYCAdCE7AA== Date: Mon, 1 Jun 2015 22:51:36 +0000 Message-ID: References: <20150318224028.GA38182@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.12] x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB505; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:CO1PR05MB459; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; x-forefront-prvs: 05947791E4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(51704005)(164054003)(189002)(479174004)(377454003)(24454002)(87936001)(50986999)(86362001)(2656002)(2950100001)(102836002)(230783001)(92566002)(46102003)(2900100001)(77156002)(62966003)(54356999)(101416001)(76176999)(106116001)(40100003)(105586002)(122556002)(2501003)(106356001)(5001830100001)(19580405001)(5001960100002)(4001350100001)(83506001)(5001860100001)(4001540100001)(189998001)(19580395003)(81156007)(99286002)(68736005)(97736004)(107886002)(5002640100001)(66066001)(5001770100001)(64706001)(36756003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-ID: <5852C65648E06648B186520D5B5F7B79@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jun 2015 22:51:36.1968 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459 X-OriginatorOrg: juniper.net Archived-At: Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-call-home-04 and draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and server-model-06 available - All Open issues closed X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 22:51:56 -0000 Hi Juergen, On 3/19/15, 9:26 PM, "Kent Watsen" wrote: >>On 3/18/15, 3:40 PM, "Juergen Schoenwaelder" >> wrote: >> >> >>* sec 3: Are certificates sometimes represented as strings and >> sometimes represented as binary? > >That's an oversight, they should all be binary. I was just looking to make this change and realized that I misspoke before. The reason why one of the certificates is a string (not binary) is because it's intended to be a poor-man's leafref. Recall before we had a read-only list of certs and a real leafref, but we subsequently took out the read-only list and now the description says this: "An unordered list of certificates the TLS server can pick from when sending its Server Certificate message. The value of the string is the unique identifier for a certificate configured on the system. How valid values are discovered is outside the scope of this module, but they are envisioned to be the keys for a list of certificates provided by another YANG module"; Makes sense? Thanks, Kent From nobody Mon Jun 1 17:38:46 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 261751A6FF8 for ; Mon, 1 Jun 2015 17:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VGenT2q9v34 for ; Mon, 1 Jun 2015 17:38:43 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0726.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:726]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3942E1A1B66 for ; Mon, 1 Jun 2015 17:38:43 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.1.172.22; Tue, 2 Jun 2015 00:38:23 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.154]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.154]) with mapi id 15.01.0172.012; Tue, 2 Jun 2015 00:38:23 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: server-model #54: move idle-timeout from global "session-options" to the "listen" tree? Thread-Index: AQHQnMxuePjQIPVzcEq31qKXMQWLXA== Date: Tue, 2 Jun 2015 00:38:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.12] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520003)(3002001); SRVR:CO1PR05MB458; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458; x-forefront-prvs: 05954A7C45 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(76104003)(31014004)(189002)(199003)(164054003)(107886002)(102836002)(5001960100002)(2900100001)(68736005)(62966003)(5002640100001)(40100003)(110136002)(106356001)(2656002)(101416001)(87936001)(97736004)(92566002)(5001860100001)(2501003)(5001830100001)(46102003)(81156007)(4001350100001)(77156002)(189998001)(50986999)(36756003)(4001540100001)(122556002)(16236675004)(86362001)(99286002)(105586002)(106116001)(83506001)(64706001)(66066001)(54356999)(450100001)(229853001)(2351001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_D192733EA8C36kwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jun 2015 00:38:22.8271 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB458 Archived-At: Subject: [Netconf] server-model #54: move idle-timeout from global "session-options" to the "listen" tree? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 00:38:45 -0000 --_000_D192733EA8C36kwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [This is a new issue] Currently, "idle-timeout" is configured in the global "session-options" tre= e, which applies to all connections, both listen and call-home. But it's un= clear if idle-timeout makes sense for call home connections, and hence shou= ld be moved to being only under the listen tree. Keep in mind that there a= re two types of call home connections: persistent and periodic. The follow= ing describes the effect of idle-timeout on each. For persistent connections, it doesn't makes sense to me that the server wo= uld ever idle-timeout a connection. This perspective is bolstered by persis= tent connections having keep-alives, so the server can detect when a client= connection has been lost and it needs to initiate a new one. An idle-timeo= ut here would be unhelpful. For periodic connections, the idle-timeout is way too course (default 1 hou= r). We use to have a "linger-timeout" for this purpose (default 30 secs), b= ut a side meeting in Dallas concluded that it was unneeded, as the client w= ould close the connection as and when it was ready. Still, the intent is th= at the connection wouldn't stay open anywhere close to the periodic interva= l (default 5 mins). An idle-timeout here is nearly useless. So, if unhelpful for persistent connections and nearly useless for periodic= connections, perhaps we should just move idle-timeout to the listen tree? = What do you think? Thanks, Kent --_000_D192733EA8C36kwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <372FB9C4CC41B4499122FAF30D79E602@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

[This is a new issue]

Currently, "idle-timeout" = is configured in the global "session-options" tree, which applies= to all connections, both listen and call-home. But it's unclear if idle-ti= meout makes sense for call home connections, and hence should be moved to being only under the listen tree.  Keep in mind th= at there are two t= ypes of call home connections: persistent and periodic.  The following= describes the effect of idle-timeout on each.

For persistent connections, it doesn= 't makes sense to me that the server would ever idle-timeout a connection. = This perspective is bolstered by persistent connections having keep-alives,= so the server can detect when a client connection has been lost and it needs to initiate a new one. An idle-timeo= ut here would be unhelpful.

For periodic connections, the idle-t= imeout is way too course (default 1 hour). We use to have a "linger-ti= meout" for this purpose (default 30 secs), but a side meeting in Dalla= s concluded that it was unneeded, as the client would close the connection as and when it was ready. Still, the intent is = that the connection wouldn't stay open anywhere close to the periodic inter= val (default 5 mins). An idle-timeout here is nearly useless.

So, if unhelpful for persistent conn= ections and nearly useless for periodic connections, perhaps we should just= move idle-timeout to the listen tree?  What do you think?

Thanks,
Kent

--_000_D192733EA8C36kwatsenjunipernet_-- From nobody Mon Jun 1 22:43:45 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E81F1A1B28 for ; Mon, 1 Jun 2015 22:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afXDmotRNwEg for ; Mon, 1 Jun 2015 22:43:41 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 841361A1B24 for ; Mon, 1 Jun 2015 22:43:39 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 321D7781; Tue, 2 Jun 2015 07:43:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id TRmQEmJgbxaG; Tue, 2 Jun 2015 07:43: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; Tue, 2 Jun 2015 07:43:37 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 33A132002B; Tue, 2 Jun 2015 07:43:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 3z99NWJYMoew; Tue, 2 Jun 2015 07:43:35 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F3C4E20013; Tue, 2 Jun 2015 07:43:34 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 23B483424F78; Tue, 2 Jun 2015 07:43:35 +0200 (CEST) Date: Tue, 2 Jun 2015 07:43:35 +0200 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20150602054335.GB66192@elstar.local> Mail-Followup-To: Kent Watsen , "netconf@ietf.org" References: <20150318224028.GA38182@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-call-home-04 and draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and server-model-06 available - All Open issues closed X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 05:43:43 -0000 On Mon, Jun 01, 2015 at 10:51:36PM +0000, Kent Watsen wrote: > > Hi Juergen, > > > On 3/19/15, 9:26 PM, "Kent Watsen" wrote: > > >>On 3/18/15, 3:40 PM, "Juergen Schoenwaelder" > >> wrote: > >> > >> > >>* sec 3: Are certificates sometimes represented as strings and > >> sometimes represented as binary? > > > >That's an oversight, they should all be binary. > > > I was just looking to make this change and realized that I misspoke > before. The reason why one of the certificates is a string (not binary) > is because it's intended to be a poor-man's leafref. Recall before we > had a read-only list of certs and a real leafref, but we subsequently took > out the read-only list and now the description says this: > > "An unordered list of certificates the TLS server can pick > from when sending its Server Certificate message. The value > of the string is the unique identifier for a certificate > configured on the system. How valid values are discovered > is outside the scope of this module, but they are envisioned > to be the keys for a list of certificates provided > by another YANG module"; > > Makes sense? > OK. What about the other then? It would IMHO be nice to have a keychain YANG model so that we could have a common way to deal with security credentials. I am struggling with the need to refer to certificates and other credentials in the LMAP YANG data model and I would love to be able to simply refer to a keychain data model instead of creating another ad-hoc solution. /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 Jun 1 23:22:43 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C99551A1BE6 for ; Mon, 1 Jun 2015 23:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOZqEhleB4Hc for ; Mon, 1 Jun 2015 23:22:31 -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 2B9971A70FD for ; Mon, 1 Jun 2015 23:22:30 -0700 (PDT) X-AuditID: c1b4fb25-f79b66d000001131-43-556d4ba385d7 Received: from ESGSCHC008.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 45.2A.04401.3AB4D655; Tue, 2 Jun 2015 08:22:27 +0200 (CEST) Received: from ESGSCMB103.ericsson.se ([169.254.3.225]) by ESGSCHC008.ericsson.se ([146.11.116.89]) with mapi id 14.03.0210.002; Tue, 2 Jun 2015 14:22:26 +0800 From: Mandy Liu To: Juergen Schoenwaelder Thread-Topic: [Netconf] How to augment RFC6470 to supply detail configuration change information Thread-Index: AdCcN15yUJGf8sjGSmOLzB5x9r0Sx///g4mA//92nwCAALMFAP/+KJHQ Date: Tue, 2 Jun 2015 06:22:25 +0000 Message-ID: References: <20150601072552.GA31467@elstar.local> <20150601095456.GD31801@elstar.local> In-Reply-To: <20150601095456.GD31801@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [146.11.116.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM+Jvre5i79xQg91LTS2e7ZnEYnF1409G i6mbbrM6MHssWfKTyWPDAU+Pj3c3swQwR3HZpKTmZJalFunbJXBlrH92nLngn3zFn7O7WRsY t0p0MXJySAiYSEy6eoQdwhaTuHBvPVsXIxeHkMBRRonDnfOgnMWMEi3f37KCVLEJaEg8fjUJ rENEwEGif1s3G4jNLPCGUeLpPDcQW1ggUWL2qbWMEDVJEp/2PGSCsN0kevu2gMVZBFQkbnf+ AOvlFfCVONJ4iR1i2UNGiU0NT8EWcAoYSSyY+hJsMSPQed9PrWGCWCYucevJfCaIswUkluw5 zwxhi0q8fPyPFcJWkJi+4R4jRL2OxILdn6AO1ZZYtvA1M8RiQYmTM5+wTGAUm4Vk7CwkLbOQ tMxC0rKAkWUVo2hxanFSbrqRsV5qUWZycXF+nl5easkmRmBUHdzyW3UH4+U3jocYBTgYlXh4 FfhyQ4VYE8uKK3MPMUpzsCiJ83p2hYQKCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYGydLzxR y0nlsfEB4zVHOs79+dK/ed7vfYc1fgn18p1evUgmgDNsSuCbsz9ervr+wlp4R72xy42oBUzC 295E/jPkl/+0yT+v5tMHBqED/zx//3e70PkgZdnuxRL7i//13zH+f80hNP2Br235aVaOxjb+ Mv5bvrYeK52inlX9/+4/73iN8uGqd7+VWIozEg21mIuKEwEySbqZiwIAAA== Archived-At: Cc: "andy@netconfcentral.org" , Athanasios Kyparlis , Robert Ottinger , "netconf@ietf.org" , Kai Lin Subject: Re: [Netconf] How to augment RFC6470 to supply detail configuration change information X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 06:22:37 -0000 Ok, thanks! Got your point. But here I want to use "data" to address the changed configuration data in = the notification. Although "data" is in the notification, but because it is= used to address the configuration data seems it still conflicts with the s= tatement in section 7.10 of RFC6020 "it is RECOMMENDED that the "anyxml" st= atement not be used to represent configuration data. " list edit { leaf target { type instance-identifier; description ..... } leaf operation { type nc:edit-operation-type; description ..... } anyxml data; } Regards, Mandy -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Monday, June 01, 2015 5:55 PM To: Mandy Liu Cc: andy@netconfcentral.org; Kai Lin; Robert Ottinger; netconf@ietf.org; At= hanasios Kyparlis Subject: Re: [Netconf] How to augment RFC6470 to supply detail configuratio= n change information Let me try to say it differently: Using anyxml in a notification does not c= ause a conflict with this statement in section 7.10 of RFC 6020: Since the use of anyxml limits the manipulation of the content, it is RECOMMENDED that the "anyxml" statement not be used to represent configuration data. Note that configuration data is defined as follows: o configuration data: The set of writable data that is required to transform a system from its initial default state into its current state [RFC4741]. Notification content is not configuration data. /js On Mon, Jun 01, 2015 at 07:48:51AM +0000, Mandy Liu wrote: > Sorry, I don't get your point. But hopefully I addressed my question more= clearly this time.=20 >=20 > The configuration change notification is generated when the NETCONF serve= r detects that the or configuration datastore has been = changed by a management session. The notification summarizes the "edits" th= at have been detected. " The structure of the "edit" is addressed in RFC64= 70 as below. What I want is to add the another leaf to address the "target"= is changed to what. But because the "target" may be a container, a list, a= leaf or a leaf-reference, etc. It could be any node of the tree. So a comm= on format for addressing the "target" is changed to what is needed.=20 > list edit { > leaf target { > type instance-identifier; > description > ..... > } > leaf operation { > type nc:edit-operation-type; > description > ..... > } > } >=20 > Thanks, > Mandy > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, June 01, 2015 3:26 PM > To: Mandy Liu > Cc: andy@netconfcentral.org; Kai Lin; Robert Ottinger;=20 > netconf@ietf.org; Athanasios Kyparlis > Subject: Re: [Netconf] How to augment RFC6470 to supply detail=20 > configuration change information >=20 > On Mon, Jun 01, 2015 at 06:51:27AM +0000, Mandy Liu wrote: >=20 > > [...] So we need to find a common format for the "content" to=20 > > accommodate different types of "target". what I can imagine is=20 > > anyxml could be used. But seems it is not a good choice. Because=20 > > based on RFC6020, it is not recommended to be used on configuration dat= a. >=20 > Since you plan to augment a notification, this won't be config true data = (this is what the statement in RFC 6020 really hints at). See also the defi= nition of 'configuration data' in section 3 of RFC 6020. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jun 1 23:47:54 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A131A87C7 for ; Mon, 1 Jun 2015 23:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKN2fvpR0IHj for ; Mon, 1 Jun 2015 23:47:51 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E37641A87DF for ; Mon, 1 Jun 2015 23:47:50 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8CF6FFAA; Tue, 2 Jun 2015 08:47:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id uw1rAjGKrKlo; Tue, 2 Jun 2015 08:47:25 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 2 Jun 2015 08:47:48 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 533CE2002B; Tue, 2 Jun 2015 08:47:48 +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 K48wQaNvQ-Ff; Tue, 2 Jun 2015 08:47:46 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 134BB20013; Tue, 2 Jun 2015 08:47:46 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6F0933425020; Tue, 2 Jun 2015 08:47:44 +0200 (CEST) Date: Tue, 2 Jun 2015 08:47:44 +0200 From: Juergen Schoenwaelder To: Mandy Liu Message-ID: <20150602064743.GA66363@elstar.local> Mail-Followup-To: Mandy Liu , "andy@netconfcentral.org" , Kai Lin , Robert Ottinger , "netconf@ietf.org" , Athanasios Kyparlis References: <20150601072552.GA31467@elstar.local> <20150601095456.GD31801@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "andy@netconfcentral.org" , Athanasios Kyparlis , Robert Ottinger , "netconf@ietf.org" , Kai Lin Subject: Re: [Netconf] How to augment RFC6470 to supply detail configuration change information X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 06:47:53 -0000 But it is not the writable configuration data but more a copy of the configuration data that got changed. Anyway, if you want to insist that this is a violation of section 7.10 of RFC6020, then don't do it. I do not believe it is a violation of section 7.10 of RFC6020. /js On Tue, Jun 02, 2015 at 06:22:25AM +0000, Mandy Liu wrote: > Ok, thanks! Got your point. > But here I want to use "data" to address the changed configuration data in the notification. Although "data" is in the notification, but because it is used to address the configuration data seems it still conflicts with the statement in section 7.10 of RFC6020 "it is RECOMMENDED that the "anyxml" statement not be used to represent configuration data. " > > list edit { > leaf target { > type instance-identifier; > description > ..... > } > leaf operation { > type nc:edit-operation-type; > description > ..... > } > anyxml data; > } > > Regards, > Mandy > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, June 01, 2015 5:55 PM > To: Mandy Liu > Cc: andy@netconfcentral.org; Kai Lin; Robert Ottinger; netconf@ietf.org; Athanasios Kyparlis > Subject: Re: [Netconf] How to augment RFC6470 to supply detail configuration change information > > Let me try to say it differently: Using anyxml in a notification does not cause a conflict with this statement in section 7.10 of RFC 6020: > > Since the use of anyxml limits the manipulation of the content, it is > RECOMMENDED that the "anyxml" statement not be used to represent > configuration data. > > Note that configuration data is defined as follows: > > o configuration data: The set of writable data that is required to > transform a system from its initial default state into its current > state [RFC4741]. > > Notification content is not configuration data. > > /js > > On Mon, Jun 01, 2015 at 07:48:51AM +0000, Mandy Liu wrote: > > Sorry, I don't get your point. But hopefully I addressed my question more clearly this time. > > > > The configuration change notification is generated when the NETCONF server detects that the or configuration datastore has been changed by a management session. The notification summarizes the "edits" that have been detected. " The structure of the "edit" is addressed in RFC6470 as below. What I want is to add the another leaf to address the "target" is changed to what. But because the "target" may be a container, a list, a leaf or a leaf-reference, etc. It could be any node of the tree. So a common format for addressing the "target" is changed to what is needed. > > list edit { > > leaf target { > > type instance-identifier; > > description > > ..... > > } > > leaf operation { > > type nc:edit-operation-type; > > description > > ..... > > } > > } > > > > Thanks, > > Mandy > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Monday, June 01, 2015 3:26 PM > > To: Mandy Liu > > Cc: andy@netconfcentral.org; Kai Lin; Robert Ottinger; > > netconf@ietf.org; Athanasios Kyparlis > > Subject: Re: [Netconf] How to augment RFC6470 to supply detail > > configuration change information > > > > On Mon, Jun 01, 2015 at 06:51:27AM +0000, Mandy Liu wrote: > > > > > [...] So we need to find a common format for the "content" to > > > accommodate different types of "target". what I can imagine is > > > anyxml could be used. But seems it is not a good choice. Because > > > based on RFC6020, it is not recommended to be used on configuration data. > > > > Since you plan to augment a notification, this won't be config true data (this is what the statement in RFC 6020 really hints at). See also the definition of 'configuration data' in section 3 of RFC 6020. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jun 1 23:52:34 2015 Return-Path: <81joseh@gmail.com> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF4A1A870E for ; Mon, 1 Jun 2015 23:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FreS133qzfJB for ; Mon, 1 Jun 2015 23:52:27 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (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 F3D271A87E2 for ; Mon, 1 Jun 2015 23:52:26 -0700 (PDT) Received: by oifu123 with SMTP id u123so118987997oif.1 for ; Mon, 01 Jun 2015 23:52:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=yjCNrMiRI9VaAJUbKgIZFfRaFyNmaL/RPhRDaMq8Pg8=; b=altX7cVg19U5TR9GdiRwp+wy6P4KQkcFgTFHuqhoCzbkRlN10N9bLzum3Lrk0sVKfD cG3njWmiMK4OQF/l25f85drGXd7JbYJG5+bpNEDH5VJFmSLG9YkarbSA4TFzuBmPl/FN g3hGbecJMNxoieBYM+evTZQZsyTMLo/fTEJaBuelPaJb3+PlFw2Zrc4/fJxNHkhHRLYh borqhIyZxHmSjBYKCnF97JnINurfgw3KEuY6Zn6eDQSSwIwTtdbpjRsq7jXM5Ltbt4e7 qfSy/Qw0/qV19JiMvWD5R0qMGSODOrZNVXRb9f5aY6TTdTqkZE6FCQM9dDgoe+lP+QYK 28yw== MIME-Version: 1.0 X-Received: by 10.182.42.131 with SMTP id o3mr21536564obl.59.1433227946270; Mon, 01 Jun 2015 23:52:26 -0700 (PDT) Received: by 10.202.214.142 with HTTP; Mon, 1 Jun 2015 23:52:26 -0700 (PDT) Received: by 10.202.214.142 with HTTP; Mon, 1 Jun 2015 23:52:26 -0700 (PDT) In-Reply-To: References: Date: Mon, 1 Jun 2015 23:52:26 -0700 Message-ID: From: jose Hernandez <81joseh@gmail.com> To: netconf@ietf.org Content-Type: multipart/alternative; boundary=001a11c30cd29ea639051783623a Archived-At: Subject: Re: [Netconf] Netconf Digest, Vol 88, Issue 2 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 06:52:33 -0000 --001a11c30cd29ea639051783623a Content-Type: text/plain; charset=UTF-8 Glad you could identify the issue so it was the poor man who had you working on it all night lmfao On Jun 1, 2015 9:48 PM, wrote: > Send Netconf mailing list submissions to > netconf@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/netconf > or, via email, send a message with subject or body 'help' to > netconf-request@ietf.org > > You can reach the person managing the list at > netconf-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Netconf digest..." > > > Today's Topics: > > 1. Re: WG Last Call for draft-ietf-netconf-call-home-04 and > draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and > server-model-06 available - All Open issues closed (Kent Watsen) > 2. server-model #54: move idle-timeout from global > "session-options" to the "listen" tree? (Kent Watsen) > 3. Re: WG Last Call for draft-ietf-netconf-call-home-04 and > draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and > server-model-06 available - All Open issues closed > (Juergen Schoenwaelder) > 4. Re: How to augment RFC6470 to supply detail configuration > change information (Mandy Liu) > 5. Re: How to augment RFC6470 to supply detail configuration > change information (Juergen Schoenwaelder) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 1 Jun 2015 22:51:36 +0000 > From: Kent Watsen > To: Juergen Schoenwaelder , > "netconf@ietf.org" > Subject: Re: [Netconf] WG Last Call for > draft-ietf-netconf-call-home-04 and > draft-ietf-netconf-server-model-06 > WAS:FW: call-home-04 and server-model-06 available - All Open > issues > closed > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > > Hi Juergen, > > > On 3/19/15, 9:26 PM, "Kent Watsen" wrote: > > >>On 3/18/15, 3:40 PM, "Juergen Schoenwaelder" > >> wrote: > >> > >> > >>* sec 3: Are certificates sometimes represented as strings and > >> sometimes represented as binary? > > > >That's an oversight, they should all be binary. > > > I was just looking to make this change and realized that I misspoke > before. The reason why one of the certificates is a string (not binary) > is because it's intended to be a poor-man's leafref. Recall before we > had a read-only list of certs and a real leafref, but we subsequently took > out the read-only list and now the description says this: > > "An unordered list of certificates the TLS server can pick > from when sending its Server Certificate message. The value > of the string is the unique identifier for a certificate > configured on the system. How valid values are discovered > is outside the scope of this module, but they are envisioned > to be the keys for a list of certificates provided > by another YANG module"; > > > > Makes sense? > > Thanks, > Kent > > > > > ------------------------------ > > Message: 2 > Date: Tue, 2 Jun 2015 00:38:22 +0000 > From: Kent Watsen > To: "netconf@ietf.org" > Subject: [Netconf] server-model #54: move idle-timeout from global > "session-options" to the "listen" tree? > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > > [This is a new issue] > > Currently, "idle-timeout" is configured in the global "session-options" > tree, which applies to all connections, both listen and call-home. But it's > unclear if idle-timeout makes sense for call home connections, and hence > should be moved to being only under the listen tree. Keep in mind that > there are two types of call home connections: persistent and periodic. The > following describes the effect of idle-timeout on each. > > For persistent connections, it doesn't makes sense to me that the server > would ever idle-timeout a connection. This perspective is bolstered by > persistent connections having keep-alives, so the server can detect when a > client connection has been lost and it needs to initiate a new one. An > idle-timeout here would be unhelpful. > > For periodic connections, the idle-timeout is way too course (default 1 > hour). We use to have a "linger-timeout" for this purpose (default 30 > secs), but a side meeting in Dallas concluded that it was unneeded, as the > client would close the connection as and when it was ready. Still, the > intent is that the connection wouldn't stay open anywhere close to the > periodic interval (default 5 mins). An idle-timeout here is nearly useless. > > So, if unhelpful for persistent connections and nearly useless for > periodic connections, perhaps we should just move idle-timeout to the > listen tree? What do you think? > > Thanks, > Kent > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://www.ietf.org/mail-archive/web/netconf/attachments/20150602/16e4ca74/attachment.html > > > > ------------------------------ > > Message: 3 > Date: Tue, 2 Jun 2015 07:43:35 +0200 > From: Juergen Schoenwaelder > To: Kent Watsen > Cc: "netconf@ietf.org" > Subject: Re: [Netconf] WG Last Call for > draft-ietf-netconf-call-home-04 and > draft-ietf-netconf-server-model-06 > WAS:FW: call-home-04 and server-model-06 available - All Open > issues > closed > Message-ID: <20150602054335.GB66192@elstar.local> > Content-Type: text/plain; charset=us-ascii > > On Mon, Jun 01, 2015 at 10:51:36PM +0000, Kent Watsen wrote: > > > > Hi Juergen, > > > > > > On 3/19/15, 9:26 PM, "Kent Watsen" wrote: > > > > >>On 3/18/15, 3:40 PM, "Juergen Schoenwaelder" > > >> wrote: > > >> > > >> > > >>* sec 3: Are certificates sometimes represented as strings and > > >> sometimes represented as binary? > > > > > >That's an oversight, they should all be binary. > > > > > > I was just looking to make this change and realized that I misspoke > > before. The reason why one of the certificates is a string (not binary) > > is because it's intended to be a poor-man's leafref. Recall before we > > had a read-only list of certs and a real leafref, but we subsequently > took > > out the read-only list and now the description says this: > > > > "An unordered list of certificates the TLS server can pick > > from when sending its Server Certificate message. The value > > of the string is the unique identifier for a certificate > > configured on the system. How valid values are discovered > > is outside the scope of this module, but they are envisioned > > to be the keys for a list of certificates provided > > by another YANG module"; > > > > Makes sense? > > > > OK. What about the other then? > > It would IMHO be nice to have a keychain YANG model so that we could > have a common way to deal with security credentials. I am struggling > with the need to refer to certificates and other credentials in the > LMAP YANG data model and I would love to be able to simply refer to a > keychain data model instead of creating another ad-hoc solution. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > > > ------------------------------ > > Message: 4 > Date: Tue, 2 Jun 2015 06:22:25 +0000 > From: Mandy Liu > To: Juergen Schoenwaelder > Cc: "andy@netconfcentral.org" , Athanasios > Kyparlis , Robert Ottinger > , "netconf@ietf.org" < > netconf@ietf.org>, > Kai Lin > Subject: Re: [Netconf] How to augment RFC6470 to supply detail > configuration change information > Message-ID: > > Content-Type: text/plain; charset="us-ascii" > > Ok, thanks! Got your point. > But here I want to use "data" to address the changed configuration data in > the notification. Although "data" is in the notification, but because it is > used to address the configuration data seems it still conflicts with the > statement in section 7.10 of RFC6020 "it is RECOMMENDED that the "anyxml" > statement not be used to represent configuration data. " > > list edit { > leaf target { > type instance-identifier; > description > ..... > } > leaf operation { > type nc:edit-operation-type; > description > ..... > } > anyxml data; > } > > Regards, > Mandy > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, June 01, 2015 5:55 PM > To: Mandy Liu > Cc: andy@netconfcentral.org; Kai Lin; Robert Ottinger; netconf@ietf.org; > Athanasios Kyparlis > Subject: Re: [Netconf] How to augment RFC6470 to supply detail > configuration change information > > Let me try to say it differently: Using anyxml in a notification does not > cause a conflict with this statement in section 7.10 of RFC 6020: > > Since the use of anyxml limits the manipulation of the content, it is > RECOMMENDED that the "anyxml" statement not be used to represent > configuration data. > > Note that configuration data is defined as follows: > > o configuration data: The set of writable data that is required to > transform a system from its initial default state into its current > state [RFC4741]. > > Notification content is not configuration data. > > /js > > On Mon, Jun 01, 2015 at 07:48:51AM +0000, Mandy Liu wrote: > > Sorry, I don't get your point. But hopefully I addressed my question > more clearly this time. > > > > The configuration change notification is generated when the NETCONF > server detects that the or configuration datastore has > been changed by a management session. The notification summarizes the > "edits" that have been detected. " The structure of the "edit" is > addressed in RFC6470 as below. What I want is to add the another leaf to > address the "target" is changed to what. But because the "target" may be a > container, a list, a leaf or a leaf-reference, etc. It could be any node of > the tree. So a common format for addressing the "target" is changed to what > is needed. > > list edit { > > leaf target { > > type instance-identifier; > > description > > ..... > > } > > leaf operation { > > type nc:edit-operation-type; > > description > > ..... > > } > > } > > > > Thanks, > > Mandy > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Monday, June 01, 2015 3:26 PM > > To: Mandy Liu > > Cc: andy@netconfcentral.org; Kai Lin; Robert Ottinger; > > netconf@ietf.org; Athanasios Kyparlis > > Subject: Re: [Netconf] How to augment RFC6470 to supply detail > > configuration change information > > > > On Mon, Jun 01, 2015 at 06:51:27AM +0000, Mandy Liu wrote: > > > > > [...] So we need to find a common format for the "content" to > > > accommodate different types of "target". what I can imagine is > > > anyxml could be used. But seems it is not a good choice. Because > > > based on RFC6020, it is not recommended to be used on configuration > data. > > > > Since you plan to augment a notification, this won't be config true data > (this is what the statement in RFC 6020 really hints at). See also the > definition of 'configuration data' in section 3 of RFC 6020. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > > > ------------------------------ > > Message: 5 > Date: Tue, 2 Jun 2015 08:47:44 +0200 > From: Juergen Schoenwaelder > To: Mandy Liu > Cc: "andy@netconfcentral.org" , Athanasios > Kyparlis , Robert Ottinger > , "netconf@ietf.org" < > netconf@ietf.org>, > Kai Lin > Subject: Re: [Netconf] How to augment RFC6470 to supply detail > configuration change information > Message-ID: <20150602064743.GA66363@elstar.local> > Content-Type: text/plain; charset=us-ascii > > But it is not the writable configuration data but more a copy of the > configuration data that got changed. Anyway, if you want to insist > that this is a violation of section 7.10 of RFC6020, then don't do > it. I do not believe it is a violation of section 7.10 of RFC6020. > > /js > > On Tue, Jun 02, 2015 at 06:22:25AM +0000, Mandy Liu wrote: > > Ok, thanks! Got your point. > > But here I want to use "data" to address the changed configuration data > in the notification. Although "data" is in the notification, but because it > is used to address the configuration data seems it still conflicts with the > statement in section 7.10 of RFC6020 "it is RECOMMENDED that the "anyxml" > statement not be used to represent configuration data. " > > > > list edit { > > leaf target { > > type instance-identifier; > > description > > ..... > > } > > leaf operation { > > type nc:edit-operation-type; > > description > > ..... > > } > > anyxml data; > > } > > > > Regards, > > Mandy > > > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de > ] > > Sent: Monday, June 01, 2015 5:55 PM > > To: Mandy Liu > > Cc: andy@netconfcentral.org; Kai Lin; Robert Ottinger; netconf@ietf.org; > Athanasios Kyparlis > > Subject: Re: [Netconf] How to augment RFC6470 to supply detail > configuration change information > > > > Let me try to say it differently: Using anyxml in a notification does > not cause a conflict with this statement in section 7.10 of RFC 6020: > > > > Since the use of anyxml limits the manipulation of the content, it is > > RECOMMENDED that the "anyxml" statement not be used to represent > > configuration data. > > > > Note that configuration data is defined as follows: > > > > o configuration data: The set of writable data that is required to > > transform a system from its initial default state into its current > > state [RFC4741]. > > > > Notification content is not configuration data. > > > > /js > > > > On Mon, Jun 01, 2015 at 07:48:51AM +0000, Mandy Liu wrote: > > > Sorry, I don't get your point. But hopefully I addressed my question > more clearly this time. > > > > > > The configuration change notification is generated when the NETCONF > server detects that the or configuration datastore has > been changed by a management session. The notification summarizes the > "edits" that have been detected. " The structure of the "edit" is > addressed in RFC6470 as below. What I want is to add the another leaf to > address the "target" is changed to what. But because the "target" may be a > container, a list, a leaf or a leaf-reference, etc. It could be any node of > the tree. So a common format for addressing the "target" is changed to what > is needed. > > > list edit { > > > leaf target { > > > type instance-identifier; > > > description > > > ..... > > > } > > > leaf operation { > > > type nc:edit-operation-type; > > > description > > > ..... > > > } > > > } > > > > > > Thanks, > > > Mandy > > > -----Original Message----- > > > From: Juergen Schoenwaelder > > > [mailto:j.schoenwaelder@jacobs-university.de] > > > Sent: Monday, June 01, 2015 3:26 PM > > > To: Mandy Liu > > > Cc: andy@netconfcentral.org; Kai Lin; Robert Ottinger; > > > netconf@ietf.org; Athanasios Kyparlis > > > Subject: Re: [Netconf] How to augment RFC6470 to supply detail > > > configuration change information > > > > > > On Mon, Jun 01, 2015 at 06:51:27AM +0000, Mandy Liu wrote: > > > > > > > [...] So we need to find a common format for the "content" to > > > > accommodate different types of "target". what I can imagine is > > > > anyxml could be used. But seems it is not a good choice. Because > > > > based on RFC6020, it is not recommended to be used on configuration > data. > > > > > > Since you plan to augment a notification, this won't be config true > data (this is what the statement in RFC 6020 really hints at). See also the > definition of 'configuration data' in section 3 of RFC 6020. > > > > > > /js > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > > Fax: +49 421 200 3103 > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > ------------------------------ > > End of Netconf Digest, Vol 88, Issue 2 > ************************************** > --001a11c30cd29ea639051783623a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Glad you could identify the issue so it was the poor man who= had you working on it all night lmfao

On Jun 1, 2015 9:48 PM, <netconf-request@ietf.org> wrote:
Send Netconf mailing list subm= issions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 netconf@iet= f.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/netconf<= /a>
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 net= conf-request@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 netco= nf-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Netconf digest..."


Today's Topics:

=C2=A0 =C2=A01. Re: WG Last Call for draft-ietf-netconf-call-home-04 and =C2=A0 =C2=A0 =C2=A0 draft-ietf-netconf-server-model-06 WAS:FW: call-home-0= 4 and
=C2=A0 =C2=A0 =C2=A0 server-model-06 available - All Open issues closed (Ke= nt Watsen)
=C2=A0 =C2=A02. server-model #54: move idle-timeout from global
=C2=A0 =C2=A0 =C2=A0 "session-options" to the "listen" = tree? (Kent Watsen)
=C2=A0 =C2=A03. Re: WG Last Call for draft-ietf-netconf-call-home-04 and =C2=A0 =C2=A0 =C2=A0 draft-ietf-netconf-server-model-06 WAS:FW: call-home-0= 4 and
=C2=A0 =C2=A0 =C2=A0 server-model-06 available - All Open issues closed
=C2=A0 =C2=A0 =C2=A0 (Juergen Schoenwaelder)
=C2=A0 =C2=A04. Re: How to augment RFC6470 to supply detail configuration =C2=A0 =C2=A0 =C2=A0 change information (Mandy Liu)
=C2=A0 =C2=A05. Re: How to augment RFC6470 to supply detail configuration =C2=A0 =C2=A0 =C2=A0 change information (Juergen Schoenwaelder)


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

Message: 1
Date: Mon, 1 Jun 2015 22:51:36 +0000
From: Kent Watsen <kwatsen@junipe= r.net>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "netco= nf@ietf.org" <netconf@ietf.= org>
Subject: Re: [Netconf] WG Last Call for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-netconf-call-home-04 and draft-ietf-= netconf-server-model-06
=C2=A0 =C2=A0 =C2=A0 =C2=A0 WAS:FW: call-home-04 and server-model-06 availa= ble - All Open issues
=C2=A0 =C2=A0 =C2=A0 =C2=A0 closed
Message-ID: <D19= 258C2.A8BA7%kwatsen@juniper.net>
Content-Type: text/plain; charset=3D"us-ascii"


Hi Juergen,


On 3/19/15, 9:26 PM, "Kent Watsen" <kwatsen@juniper.net> wrote:

>>On 3/18/15, 3:40 PM, "Juergen Schoenwaelder"
>><j.schoe= nwaelder@jacobs-university.de> wrote:
>>
>>
>>* sec 3: Are certificates sometimes represented as strings and
>>=C2=A0 sometimes represented as binary?
>
>That's an oversight, they should all be binary.


I was just looking to make this change and realized that I misspoke
before.=C2=A0 The reason why one of the certificates is a string (not binar= y)
is because it's intended to be a poor-man's leafref.=C2=A0 =C2=A0Re= call before we
had a read-only list of certs and a real leafref, but we subsequently took<= br> out the read-only list and now the description says this:

=C2=A0 =C2=A0 "An unordered list of certificates the TLS server can pi= ck
=C2=A0 =C2=A0 =C2=A0from when sending its Server Certificate message.=C2=A0= The value
=C2=A0 =C2=A0 =C2=A0of the string is the unique identifier for a certificat= e
=C2=A0 =C2=A0 =C2=A0configured on the system.=C2=A0 How valid values are di= scovered
=C2=A0 =C2=A0 =C2=A0is outside the scope of this module, but they are envis= ioned
=C2=A0 =C2=A0 =C2=A0to be the keys for a list of certificates provided
=C2=A0 =C2=A0 =C2=A0by another YANG module";



Makes sense?

Thanks,
Kent




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

Message: 2
Date: Tue, 2 Jun 2015 00:38:22 +0000
From: Kent Watsen <kwatsen@junipe= r.net>
To: "netconf@ietf.org" &l= t;netconf@ietf.org>
Subject: [Netconf] server-model #54: move idle-timeout from global
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "session-options" to the "listen= " tree?
Message-ID: <D19= 2733E.A8C36%kwatsen@juniper.net>
Content-Type: text/plain; charset=3D"us-ascii"


[This is a new issue]

Currently, "idle-timeout" is configured in the global "sessi= on-options" tree, which applies to all connections, both listen and ca= ll-home. But it's unclear if idle-timeout makes sense for call home con= nections, and hence should be moved to being only under the listen tree.=C2= =A0 Keep in mind that there are two types of call home connections: persist= ent and periodic.=C2=A0 The following describes the effect of idle-timeout = on each.

For persistent connections, it doesn't makes sense to me that the serve= r would ever idle-timeout a connection. This perspective is bolstered by pe= rsistent connections having keep-alives, so the server can detect when a cl= ient connection has been lost and it needs to initiate a new one. An idle-t= imeout here would be unhelpful.

For periodic connections, the idle-timeout is way too course (default 1 hou= r). We use to have a "linger-timeout" for this purpose (default 3= 0 secs), but a side meeting in Dallas concluded that it was unneeded, as th= e client would close the connection as and when it was ready. Still, the in= tent is that the connection wouldn't stay open anywhere close to the pe= riodic interval (default 5 mins). An idle-timeout here is nearly useless.
So, if unhelpful for persistent connections and nearly useless for periodic= connections, perhaps we should just move idle-timeout to the listen tree?= =C2=A0 What do you think?

Thanks,
Kent

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/= mail-archive/web/netconf/attachments/20150602/16e4ca74/attachment.html&= gt;

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

Message: 3
Date: Tue, 2 Jun 2015 07:43:35 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Kent Watsen <kwatsen@juniper.= net>
Cc: "netconf@ietf.org" &l= t;netconf@ietf.org>
Subject: Re: [Netconf] WG Last Call for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-netconf-call-home-04 and draft-ietf-= netconf-server-model-06
=C2=A0 =C2=A0 =C2=A0 =C2=A0 WAS:FW: call-home-04 and server-model-06 availa= ble - All Open issues
=C2=A0 =C2=A0 =C2=A0 =C2=A0 closed
Message-ID: <20150602054335.GB66192@elstar.local>
Content-Type: text/plain; charset=3Dus-ascii

On Mon, Jun 01, 2015 at 10:51:36PM +0000, Kent Watsen wrote:
>
> Hi Juergen,
>
>
> On 3/19/15, 9:26 PM, "Kent Watsen" <kwatsen@juniper.net> wrote:
>
> >>On 3/18/15, 3:40 PM, "Juergen Schoenwaelder"
> >><j.= schoenwaelder@jacobs-university.de> wrote:
> >>
> >>
> >>* sec 3: Are certificates sometimes represented as strings and=
> >>=C2=A0 sometimes represented as binary?
> >
> >That's an oversight, they should all be binary.
>
>
> I was just looking to make this change and realized that I misspoke > before.=C2=A0 The reason why one of the certificates is a string (not = binary)
> is because it's intended to be a poor-man's leafref.=C2=A0 =C2= =A0Recall before we
> had a read-only list of certs and a real leafref, but we subsequently = took
> out the read-only list and now the description says this:
>
>=C2=A0 =C2=A0 =C2=A0"An unordered list of certificates the TLS ser= ver can pick
>=C2=A0 =C2=A0 =C2=A0 from when sending its Server Certificate message.= =C2=A0 The value
>=C2=A0 =C2=A0 =C2=A0 of the string is the unique identifier for a certi= ficate
>=C2=A0 =C2=A0 =C2=A0 configured on the system.=C2=A0 How valid values a= re discovered
>=C2=A0 =C2=A0 =C2=A0 is outside the scope of this module, but they are = envisioned
>=C2=A0 =C2=A0 =C2=A0 to be the keys for a list of certificates provided=
>=C2=A0 =C2=A0 =C2=A0 by another YANG module";
>
> Makes sense?
>

OK. What about the other then?

It would IMHO be nice to have a keychain YANG model so that we could
have a common way to deal with security credentials. I am struggling
with the need to refer to certificates and other credentials in the
LMAP YANG data model and I would love to be able to simply refer to a
keychain data model instead of creating another ad-hoc solution.

/js

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



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

Message: 4
Date: Tue, 2 Jun 2015 06:22:25 +0000
From: Mandy Liu <mandy.liu@eri= csson.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Cc: "andy@netconfcentral.or= g" <andy@netconfcent= ral.org>, Athanasios
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Kyparlis <athanasios.kyparlis@ericsson.com>, Robert Ottinger=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <robert.ottinger@ericsson.com>, "netconf@ietf.org" <netconf@ietf.org>,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Kai Lin <kai.lin@ericsson.com>
Subject: Re: [Netconf] How to augment RFC6470 to supply detail
=C2=A0 =C2=A0 =C2=A0 =C2=A0 configuration change information
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <D970584466921040BD10823F192C30B9382= B120E@ESGSCMB103.ericsson.se>
Content-Type: text/plain; charset=3D"us-ascii"

Ok, thanks! Got your point.
But here I want to use "data" to address the changed configuratio= n data in the notification. Although "data" is in the notificatio= n, but because it is used to address the configuration data seems it still = conflicts with the statement in section 7.10 of RFC6020 "it is RECOMME= NDED that the "anyxml" statement not be used to represent configu= ration data. "

list edit {
=C2=A0 =C2=A0 =C2=A0leaf target {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type instance-identifier;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 description
=C2=A0 =C2=A0 =C2=A0 =C2=A0 .....
=C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0leaf operation {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type nc:edit-operation-type;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 description
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0.....
=C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0anyxml data;
=C2=A0}

Regards,
Mandy

-----Original Message-----
From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]
Sent: Monday, June 01, 2015 5:55 PM
To: Mandy Liu
Cc: andy@netconfcentral.org;= Kai Lin; Robert Ottinger; netconf@ietf= .org; Athanasios Kyparlis
Subject: Re: [Netconf] How to augment RFC6470 to supply detail configuratio= n change information

Let me try to say it differently: Using anyxml in a notification does not c= ause a conflict with this statement in section 7.10 of RFC 6020:

=C2=A0 =C2=A0Since the use of anyxml limits the manipulation of the content= , it is
=C2=A0 =C2=A0RECOMMENDED that the "anyxml" statement not be used = to represent
=C2=A0 =C2=A0configuration data.

Note that configuration data is defined as follows:

=C2=A0 =C2=A0o=C2=A0 configuration data: The set of writable data that is r= equired to
=C2=A0 =C2=A0 =C2=A0 transform a system from its initial default state into= its current
=C2=A0 =C2=A0 =C2=A0 state [RFC4741].

Notification content is not configuration data.

/js

On Mon, Jun 01, 2015 at 07:48:51AM +0000, Mandy Liu wrote:
> Sorry, I don't get your point. But hopefully I addressed my questi= on more clearly this time.
>
> The configuration change notification is generated when the NETCONF se= rver detects that the <running> or <startup> configuration data= store has been changed by a management session. The notification summarizes= the "edits" that have been detected. "=C2=A0 The structure = of the "edit" is addressed in RFC6470 as below. What I want is to= add the another leaf to address the "target" is changed to what.= But because the "target" may be a container, a list, a leaf or a= leaf-reference, etc. It could be any node of the tree. So a common format = for addressing the "target" is changed to what is needed.
> list edit {
>=C2=A0 =C2=A0 =C2=A0leaf target {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type instance-identifier;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 .....
>=C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0leaf operation {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type nc:edit-operation-type;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0.....
>=C2=A0 =C2=A0 =C2=A0}
> }
>
> Thanks,
> Mandy
> -----Original Message-----
> From: Juergen Schoenwaelder
> [mailto:j.scho= enwaelder@jacobs-university.de]
> Sent: Monday, June 01, 2015 3:26 PM
> To: Mandy Liu
> Cc: andy@netconfcentral.org= ; Kai Lin; Robert Ottinger;
> netconf@ietf.org; Athanasios K= yparlis
> Subject: Re: [Netconf] How to augment RFC6470 to supply detail
> configuration change information
>
> On Mon, Jun 01, 2015 at 06:51:27AM +0000, Mandy Liu wrote:
>
> > [...] So we need to find a common format for the "content&qu= ot; to
> > accommodate different types of "target". what I can ima= gine is
> > anyxml could be used. But seems it is not a good choice. Because<= br> > > based on RFC6020, it is not recommended to be used on configurati= on data.
>
> Since you plan to augment a notification, this won't be config tru= e data (this is what the statement in RFC 6020 really hints at). See also t= he definition of 'configuration data' in section 3 of RFC 6020.
>
> /js
>
> --
> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs U= niversity Bremen gGmbH
> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1= | 28759 Bremen | Germany
> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<= ;http://www.= jacobs-university.de/>

--
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.jacob= s-university.de/>



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

Message: 5
Date: Tue, 2 Jun 2015 08:47:44 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Mandy Liu <mandy.liu@erics= son.com>
Cc: "andy@netconfcentral.or= g" <andy@netconfcent= ral.org>, Athanasios
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Kyparlis <athanasios.kyparlis@ericsson.com>, Robert Ottinger=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <robert.ottinger@ericsson.com>, "netconf@ietf.org" <netconf@ietf.org>,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Kai Lin <kai.lin@ericsson.com>
Subject: Re: [Netconf] How to augment RFC6470 to supply detail
=C2=A0 =C2=A0 =C2=A0 =C2=A0 configuration change information
Message-ID: <20150602064743.GA66363@elstar.local>
Content-Type: text/plain; charset=3Dus-ascii

But it is not the writable configuration data but more a copy of the
configuration data that got changed. Anyway, if you want to insist
that this is a violation of section 7.10 of RFC6020, then don't do
it. I do not believe it is a violation of section 7.10 of RFC6020.

/js

On Tue, Jun 02, 2015 at 06:22:25AM +0000, Mandy Liu wrote:
> Ok, thanks! Got your point.
> But here I want to use "data" to address the changed configu= ration data in the notification. Although "data" is in the notifi= cation, but because it is used to address the configuration data seems it s= till conflicts with the statement in section 7.10 of RFC6020 "it is RE= COMMENDED that the "anyxml" statement not be used to represent co= nfiguration data. "
>
> list edit {
>=C2=A0 =C2=A0 =C2=A0 leaf target {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type instance-identifier;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0.....
>=C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 leaf operation {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type nc:edit-operation-type;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 .....
>=C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 anyxml data;
>=C2=A0 }
>
> Regards,
> Mandy
>
> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]
> Sent: Monday, June 01, 2015 5:55 PM
> To: Mandy Liu
> Cc: andy@netconfcentral.org= ; Kai Lin; Robert Ottinger; netconf= @ietf.org; Athanasios Kyparlis
> Subject: Re: [Netconf] How to augment RFC6470 to supply detail configu= ration change information
>
> Let me try to say it differently: Using anyxml in a notification does = not cause a conflict with this statement in section 7.10 of RFC 6020:
>
>=C2=A0 =C2=A0 Since the use of anyxml limits the manipulation of the co= ntent, it is
>=C2=A0 =C2=A0 RECOMMENDED that the "anyxml" statement not be = used to represent
>=C2=A0 =C2=A0 configuration data.
>
> Note that configuration data is defined as follows:
>
>=C2=A0 =C2=A0 o=C2=A0 configuration data: The set of writable data that= is required to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0transform a system from its initial default = state into its current
>=C2=A0 =C2=A0 =C2=A0 =C2=A0state [RFC4741].
>
> Notification content is not configuration data.
>
> /js
>
> On Mon, Jun 01, 2015 at 07:48:51AM +0000, Mandy Liu wrote:
> > Sorry, I don't get your point. But hopefully I addressed my q= uestion more clearly this time.
> >
> > The configuration change notification is generated when the NETCO= NF server detects that the <running> or <startup> configuration= datastore has been changed by a management session. The notification summa= rizes the "edits" that have been detected. "=C2=A0 The struc= ture of the "edit" is addressed in RFC6470 as below. What I want = is to add the another leaf to address the "target" is changed to = what. But because the "target" may be a container, a list, a leaf= or a leaf-reference, etc. It could be any node of the tree. So a common fo= rmat for addressing the "target" is changed to what is needed. > > list edit {
> >=C2=A0 =C2=A0 =C2=A0leaf target {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type instance-identifier;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 .....
> >=C2=A0 =C2=A0 =C2=A0}
> >=C2=A0 =C2=A0 =C2=A0leaf operation {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type nc:edit-operation-type;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0.....
> >=C2=A0 =C2=A0 =C2=A0}
> > }
> >
> > Thanks,
> > Mandy
> > -----Original Message-----
> > From: Juergen Schoenwaelder
> > [mailto:j= .schoenwaelder@jacobs-university.de]
> > Sent: Monday, June 01, 2015 3:26 PM
> > To: Mandy Liu
> > Cc: andy@netconfcentra= l.org; Kai Lin; Robert Ottinger;
> > netconf@ietf.org; Athanas= ios Kyparlis
> > Subject: Re: [Netconf] How to augment RFC6470 to supply detail > > configuration change information
> >
> > On Mon, Jun 01, 2015 at 06:51:27AM +0000, Mandy Liu wrote:
> >
> > > [...] So we need to find a common format for the "conte= nt" to
> > > accommodate different types of "target". what I ca= n imagine is
> > > anyxml could be used. But seems it is not a good choice. Bec= ause
> > > based on RFC6020, it is not recommended to be used on config= uration data.
> >
> > Since you plan to augment a notification, this won't be confi= g true data (this is what the statement in RFC 6020 really hints at). See a= lso the definition of 'configuration data' in section 3 of RFC 6020= .
> >
> > /js
> >
> > --
> > Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jac= obs University Bremen gGmbH
> > Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus R= ing 1 | 28759 Bremen | Germany
> > Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<http:= //www.jacobs-university.de/>
>
> --
> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs U= niversity Bremen gGmbH
> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1= | 28759 Bremen | Germany
> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<= ;http://www.= jacobs-university.de/>

--
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.jacob= s-university.de/>



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

Subject: Digest Footer

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


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

End of Netconf Digest, Vol 88, Issue 2
**************************************
--001a11c30cd29ea639051783623a-- From nobody Tue Jun 2 00:18:32 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63FE11ACD6B for ; Tue, 2 Jun 2015 00:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4PMD5aeIFjF for ; Tue, 2 Jun 2015 00:18:29 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24DBF1ACDCD for ; Tue, 2 Jun 2015 00:18:26 -0700 (PDT) X-AuditID: c1b4fb3a-f79ec6d000006dc0-b3-556d58bf7689 Received: from ESGSCHC004.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 7E.6C.28096.0C85D655; Tue, 2 Jun 2015 09:18:25 +0200 (CEST) Received: from ESGSCMB103.ericsson.se ([169.254.3.225]) by ESGSCHC004.ericsson.se ([10.0.18.180]) with mapi id 14.03.0210.002; Tue, 2 Jun 2015 15:18:23 +0800 From: Mandy Liu To: Juergen Schoenwaelder Thread-Topic: [Netconf] How to augment RFC6470 to supply detail configuration change information Thread-Index: AdCcN15yUJGf8sjGSmOLzB5x9r0Sx///g4mA//92nwCAALMFAP/+KJHQgAM1dwD//3KAIA== Date: Tue, 2 Jun 2015 07:18:22 +0000 Message-ID: References: <20150601072552.GA31467@elstar.local> <20150601095456.GD31801@elstar.local> <20150602064743.GA66363@elstar.local> In-Reply-To: <20150602064743.GA66363@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [146.11.116.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyM+Jvre7BiNxQg3WzBS2e7ZnEYnF1409G i6mbbrM6MHssWfKTyWPDAU+Pj3c3swQwR3HZpKTmZJalFunbJXBltD3bzFQwT7uiYdEqlgbG FsUuRk4OCQETiU9HJrFC2GISF+6tZwOxhQSOMkosPe3WxcgFZC9klNjQOI0RJMEmoCHx+NUk dhBbRMBBon9bN1gDs8AbRomn89xAbGGBRInZp9YyQtQkSXza85AJwg6TWLnpCdgyFgEVid51 fWBzeAV8JQ5v2cEIsfgsk8SC03IgNqeAkcTZ/7tZQGxGoOO+n1rDBLFLXOLWk/lMEEcLSCzZ c54ZwhaVePn4H9QzChLTN9xjhKjXkViw+xPUndoSyxa+ZobYKyhxcuYTlgmMYrOQjJ2FpGUW kpZZSFoWMLKsYhQtTi0uzk03MtJLLcpMLi7Oz9PLSy3ZxAiMqINbflvtYDz43PEQowAHoxIP rwJfbqgQa2JZcWXuIUZpDhYlcV7PrpBQIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYxC54sm /bZZXbvyN39h/+f8ouR5e50LLl263f9aouqi4QrGzWfTVge05K8NjLE8nT/zVJWRiqYGP39g x11lyY9TtL/VrqvVLS0Ldy0wmyDgvvFt6W9FvtKnZ1L83t+9GKS+U+LzJJEnXVt7FPveZB3i UmH/3XWjUTli6nXGfytrTu+TOflluYcSS3FGoqEWc1FxIgAPZ0ZaiQIAAA== Archived-At: Cc: "andy@netconfcentral.org" , Athanasios Kyparlis , Robert Ottinger , "netconf@ietf.org" , Kai Lin Subject: Re: [Netconf] How to augment RFC6470 to supply detail configuration change information X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 07:18:31 -0000 I am not intent to insist that. I just want to make sure it won't violate R= FC6020. I think you have convinced me by below sentence. Thanks for your su= pport, Juergen! - "But it is not the writable configuration data but more a copy of the con= figuration data that got changed." Regards, Mandy -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Tuesday, June 02, 2015 2:48 PM To: Mandy Liu Cc: andy@netconfcentral.org; Kai Lin; Robert Ottinger; netconf@ietf.org; At= hanasios Kyparlis Subject: Re: [Netconf] How to augment RFC6470 to supply detail configuratio= n change information But it is not the writable configuration data but more a copy of the config= uration data that got changed. Anyway, if you want to insist that this is a= violation of section 7.10 of RFC6020, then don't do it. I do not believe i= t is a violation of section 7.10 of RFC6020. /js On Tue, Jun 02, 2015 at 06:22:25AM +0000, Mandy Liu wrote: > Ok, thanks! Got your point. > But here I want to use "data" to address the changed configuration data i= n the notification. Although "data" is in the notification, but because it = is used to address the configuration data seems it still conflicts with the= statement in section 7.10 of RFC6020 "it is RECOMMENDED that the "anyxml" = statement not be used to represent configuration data. " >=20 > list edit { > leaf target { > type instance-identifier; > description > ..... > } > leaf operation { > type nc:edit-operation-type; > description > ..... > } > anyxml data; > } >=20 > Regards, > Mandy >=20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, June 01, 2015 5:55 PM > To: Mandy Liu > Cc: andy@netconfcentral.org; Kai Lin; Robert Ottinger;=20 > netconf@ietf.org; Athanasios Kyparlis > Subject: Re: [Netconf] How to augment RFC6470 to supply detail=20 > configuration change information >=20 > Let me try to say it differently: Using anyxml in a notification does not= cause a conflict with this statement in section 7.10 of RFC 6020: >=20 > Since the use of anyxml limits the manipulation of the content, it is > RECOMMENDED that the "anyxml" statement not be used to represent > configuration data. >=20 > Note that configuration data is defined as follows: >=20 > o configuration data: The set of writable data that is required to > transform a system from its initial default state into its current > state [RFC4741]. >=20 > Notification content is not configuration data. >=20 > /js >=20 > On Mon, Jun 01, 2015 at 07:48:51AM +0000, Mandy Liu wrote: > > Sorry, I don't get your point. But hopefully I addressed my question mo= re clearly this time.=20 > >=20 > > The configuration change notification is generated when the NETCONF ser= ver detects that the or configuration datastore has bee= n changed by a management session. The notification summarizes the "edits" = that have been detected. " The structure of the "edit" is addressed in RFC= 6470 as below. What I want is to add the another leaf to address the "targe= t" is changed to what. But because the "target" may be a container, a list,= a leaf or a leaf-reference, etc. It could be any node of the tree. So a co= mmon format for addressing the "target" is changed to what is needed.=20 > > list edit { > > leaf target { > > type instance-identifier; > > description > > ..... > > } > > leaf operation { > > type nc:edit-operation-type; > > description > > ..... > > } > > } > >=20 > > Thanks, > > Mandy > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Monday, June 01, 2015 3:26 PM > > To: Mandy Liu > > Cc: andy@netconfcentral.org; Kai Lin; Robert Ottinger;=20 > > netconf@ietf.org; Athanasios Kyparlis > > Subject: Re: [Netconf] How to augment RFC6470 to supply detail=20 > > configuration change information > >=20 > > On Mon, Jun 01, 2015 at 06:51:27AM +0000, Mandy Liu wrote: > >=20 > > > [...] So we need to find a common format for the "content" to=20 > > > accommodate different types of "target". what I can imagine is=20 > > > anyxml could be used. But seems it is not a good choice. Because=20 > > > based on RFC6020, it is not recommended to be used on configuration d= ata. > >=20 > > Since you plan to augment a notification, this won't be config true dat= a (this is what the statement in RFC 6020 really hints at). See also the de= finition of 'configuration data' in section 3 of RFC 6020. > >=20 > > /js > >=20 > > --=20 > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Jun 2 09:33:49 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 889D51B2B40 for ; Tue, 2 Jun 2015 09:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1rwhAe9KK0w for ; Tue, 2 Jun 2015 09:33:47 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 037891B2B1C for ; Tue, 2 Jun 2015 09:33:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=qN5jdBX7APWPhTGQzDtaeVM3WSui/c4in3UcVZahoAecKQSCkbaPKyMNNODpKAso; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.26] (helo=mswamui-bichon.atl.sa.earthlink.net) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Yzp8M-0005F9-HB for netconf@ietf.org; Tue, 02 Jun 2015 12:33:46 -0400 Received: from 76.254.50.165 by webmail.earthlink.net with HTTP; Tue, 2 Jun 2015 12:33:46 -0400 Message-ID: <457915.1433262826425.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> Date: Tue, 2 Jun 2015 09:33:46 -0700 (GMT-07:00) From: Randy Presuhn To: netconf@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888ff8848a73c44bba06bc4bdcf059781d3503ead2688965ea2350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.26 Archived-At: Subject: Re: [Netconf] How to augment RFC6470 to supply detail configuration change information X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 16:33:48 -0000 Hi - >From: Juergen Schoenwaelder >Sent: Jun 1, 2015 11:47 PM ... >Subject: Re: [Netconf] How to augment RFC6470 to supply detail configuration change information > >But it is not the writable configuration data but more a copy of the >configuration data that got changed. Anyway, if you want to insist >that this is a violation of section 7.10 of RFC6020, then don't do >it. I do not believe it is a violation of section 7.10 of RFC6020. I think this thread makes it clear that there is an unintended ambiguity in the statement "it is RECOMMENDED that the 'anyxml' statement not be used to represent configuration data." Perhaps replacing the word "represent" with "define" might reduce the ambiguity. Randy From nobody Tue Jun 2 14:01:15 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 067F81A8A1F for ; Tue, 2 Jun 2015 14:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JtzDnrDr6cAh for ; Tue, 2 Jun 2015 14:01:14 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id BD1751A88FA for ; Tue, 2 Jun 2015 14:01:13 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id B4C221AE019A; Tue, 2 Jun 2015 23:01:11 +0200 (CEST) Date: Tue, 02 Jun 2015 23:01:31 +0200 (CEST) Message-Id: <20150602.230131.1772714071737939282.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <457915.1433262826425.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> References: <457915.1433262826425.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] How to augment RFC6470 to supply detail configuration change information X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 21:01:15 -0000 Randy Presuhn wrote: > Hi - > > >From: Juergen Schoenwaelder > >Sent: Jun 1, 2015 11:47 PM > ... > >Subject: Re: [Netconf] How to augment RFC6470 to supply detail configuration change information > > > >But it is not the writable configuration data but more a copy of the > >configuration data that got changed. Anyway, if you want to insist > >that this is a violation of section 7.10 of RFC6020, then don't do > >it. I do not believe it is a violation of section 7.10 of RFC6020. > > I think this thread makes it clear that there is an unintended > ambiguity in the statement "it is RECOMMENDED that the 'anyxml' > statement not be used to represent configuration data." Perhaps > replacing the word "represent" with "define" might reduce the > ambiguity. Yes, I was thinking along these lines as well. I think this is a good suggestion. /martin From nobody Tue Jun 2 14:44:53 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F34F1B2C32 for ; Tue, 2 Jun 2015 14:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOTK613R-zzZ for ; Tue, 2 Jun 2015 14:44:50 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0790.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::790]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84F6C1B2BC7 for ; Tue, 2 Jun 2015 14:44:45 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.1.172.22; Tue, 2 Jun 2015 21:44:25 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.154]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.154]) with mapi id 15.01.0172.012; Tue, 2 Jun 2015 21:44:25 +0000 From: Kent Watsen To: Juergen Schoenwaelder Thread-Topic: [Netconf] WG Last Call for draft-ietf-netconf-call-home-04 and draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and server-model-06 available - All Open issues closed Thread-Index: AQHQVf+tT/7bNpWPUkyuK74/P/SDo50i7REAgAF9rYCAdCE7AIAAtimAgADJZQA= Date: Tue, 2 Jun 2015 21:44:24 +0000 Message-ID: References: <20150318224028.GA38182@elstar.local> <20150602054335.GB66192@elstar.local> In-Reply-To: <20150602054335.GB66192@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.10] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520003)(3002001); SRVR:CO1PR05MB458; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458; x-forefront-prvs: 05954A7C45 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(76104003)(189002)(199003)(51704005)(40100003)(110136002)(102836002)(5001960100002)(50986999)(62966003)(5002640100001)(551544002)(2950100001)(2900100001)(68736005)(2656002)(87936001)(101416001)(77156002)(97736004)(81156007)(46102003)(189998001)(92566002)(4001540100001)(122556002)(76176999)(36756003)(5001860100001)(4001350100001)(5001830100001)(86362001)(99286002)(106116001)(230783001)(83506001)(93886004)(66066001)(64706001)(105586002)(54356999)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-ID: <1555FA13429D054BB4F77D15DD765A51@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jun 2015 21:44:24.8076 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB458 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-call-home-04 and draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and server-model-06 available - All Open issues closed X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 21:44:52 -0000 >OK. What about the other then? > >It would IMHO be nice to have a keychain YANG model so that we could >have a common way to deal with security credentials. I am struggling >with the need to refer to certificates and other credentials in the >LMAP YANG data model and I would love to be able to simply refer to a >keychain data model instead of creating another ad-hoc solution. Are you referring to the leaf "credentials" in draft-ietf-lmap-yang? This leaf appears to be for client auth: username, password, rsa-key, client-cert, and the like. The server-model doesn't configure client-auth; not even for call home, as the NETCONF/RESTCONF server is always the SSH/TLS server (never the client). Nonetheless, I appreciate that client auth is a common use case for a keychains (password managers / vaults) However, as we've been discussing in this thread, the server-model does need to configure which SSH host-keys or TLS server-certs the server presents when establishing secure connections. Ideally there is a global store of host-keys and server-certificates that can be referenced on a per-use basis (e.g., present cert-1 when accepting a connection, present cert-2 when establishing a call home connection to app-2, etc.). Another consideration is that keychains are often used to store trust anchors. Both lmap and server-model need trust anchors. LMAP uses trust anchors to authenticate the server-certificate of a server it is connecting to, whereas server-model uses trust anchors to authenticate the client-certificate of a client that is connecting to it. Again, there should be a global store of trust anchors that specific apps can cherry-pick from. For instance, use Verisign's trust anchor is OK when connecting to 3rd-party web-server, but assert a specific trust anchor when connecting to a well-known service. Do we want to act on this now, or proceed with current drafts? Sketching this out quickly, maybe something like this: module: ietf-keychain +--rw client-credentials | +--rw client-credential* [name] | +--rw name string | +--rw type enumeration // password, rsa-key, etc. | +--rw value anydata // type-specific format +--rw private-keys | +--rw private-key* [name] | +--x generate-new // returns public key | +--rw name string | +--rw type enumeration // elliptic, rsa, dsa, etc.=20 | +--rw value anydata // type-specific format =20 +--rw host-keys | +--rw host-key* [name] | +--x generate-new // input res a private key | +--rw name string | +--rw type enumeration // rsa, dss, x509, etc. | +--rw value anydata // type-specific format =20 +--rw server-certificates | +--rw server-certificate* [name] | +--x generate-csr // returns a cert signing request | +--rw name string | +--rw certificate binary +--rw trust-anchors +--rw trust-anchor* [name] +--rw name string +--rw certificate binary Then server-model would be something like import ietf-keychain { prefix kc; } ... container tls { container trusted-ca-certs { leaf trusted-ca-cert { type leafref { path "/kc:trust-anchors/kc:trust-anchor/kc:name"; } } } } What do you think? Kent From nobody Tue Jun 2 15:41:02 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39C391A00CD for ; Tue, 2 Jun 2015 15:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46nNAN8P4jZP for ; Tue, 2 Jun 2015 15:40:58 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0129.outbound.protection.outlook.com [65.55.169.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAB951A00C0 for ; Tue, 2 Jun 2015 15:40:56 -0700 (PDT) Received: from CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) by CO1PR05MB361.namprd05.prod.outlook.com (10.141.51.148) with Microsoft SMTP Server (TLS) id 15.1.172.22; Tue, 2 Jun 2015 22:40:55 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.172.22; Tue, 2 Jun 2015 22:40:54 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.154]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.154]) with mapi id 15.01.0172.012; Tue, 2 Jun 2015 22:40:54 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] server-model #49: combine trusted-ca-certs and trusted-client-certs for ssh/tls? Thread-Index: AQHQkbgnBncK8ydKj0azKXFdHxn5752Zo96A Date: Tue, 2 Jun 2015 22:40:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.10] x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB361; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:CO1PR05MB459; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; x-forefront-prvs: 05954A7C45 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(377454003)(199003)(164054003)(19580405001)(4001350100001)(110136002)(5001830100001)(99286002)(5001960100002)(16236675004)(5001860100001)(83506001)(4001540100001)(2501003)(106356001)(107886002)(5002640100001)(64706001)(189998001)(40100003)(122556002)(66066001)(81156007)(68736005)(36756003)(97736004)(106116001)(86362001)(19580395003)(50986999)(87936001)(2656002)(54356999)(101416001)(77156002)(102836002)(105586002)(76176999)(230783001)(2351001)(19617315012)(450100001)(46102003)(2950100001)(62966003)(92566002)(15975445007)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_D1939D27A8F18kwatsenjunipernet_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jun 2015 22:40:54.8137 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459 X-OriginatorOrg: juniper.net Archived-At: Subject: Re: [Netconf] server-model #49: combine trusted-ca-certs and trusted-client-certs for ssh/tls? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 22:41:01 -0000 --_000_D1939D27A8F18kwatsenjunipernet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [Re-opening issue #49] The solution verified below was to unify the trust-ca-certs and trusted-cli= ent-certs containers across NETCONF/SSH and NETCONF/TLS, but does nothing t= o unify RESTCONF/TLS. For a server that implements both NETCONF and RESTCO= NF, wouldn't the same set of trusted ca/client certs be used for both? Since both the netconf-server and restconf-server models are in the same dr= aft, it would be relatively easy to define a 3rd YANG model in this draft (= no need for a new draft). But the recent email thread with Juergen regardi= ng keychains highlights an opportunity to do something more applicable to o= ther drafts (e.g., LMAP), which would fix both this issue (how to validate = client-certs) as well as the issue of knowing which SSH host-keys or TLS se= rver-certs to advertise. Options: 1. Do nothing (keep all separate) [issue --> DEAD] 2. Only unify netconf/ssh and netconf/tls (current plan) 3. Unify across netconf/ssh, netconf/tls, and restconf/tls A. do this using a 3rd YANG module in this draft B. do this by using "poor-man" leafrefs - i.e. a string that points to a key in some TBD module 4. Work on a keychain solution of some sort - this would delay server-model draft longer... I'm on the fence, but my preferences in order are 4, 2, 1, 3B, 3A Kent From: Kent Watsen > Date: Monday, May 18, 2015 at 6:15 PM To: "netconf@ietf.org" > Subject: Re: [Netconf] server-model #49: combine trusted-ca-certs and trust= ed-client-certs for ssh/tls? The solution described below is now considered verified. Thanks, Kent From: Kent Watsen > Date: Sunday, March 29, 2015 at 7:06 PM To: "netconf@ietf.org" > Subject: [Netconf] server-model #49: combine trusted-ca-certs and trusted-c= lient-certs for ssh/tls? This issue (see subject line and/or link below) was discussed during the Da= llas meeting with an agreement to combine the configuration for trusted CA-= certs and client-certs into one container for both SSH and TLS. The new co= ntainer would use the following YANG 1.1 if-feature statement (assuming the= WG adopts that resolution): if-feature "(ssh-x509-certs or tls)"; This issue is hence moved to the VERIFY state. The issue will move to the = EDIT state if no objection is raised by April 6th. Reference: https://github.com/netconf-wg/server-model/issues/49 Thanks, Kent --_000_D1939D27A8F18kwatsenjunipernet_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <5B29574BFED6FC49947597502938EA4B@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

[Re-opening issue #49]

The solution verified below was to unify the trust-ca-certs and truste= d-client-certs containers across NETCONF/SSH and NETCONF/TLS, but does noth= ing to unify RESTCONF/TLS.  For a server that implements both NETCONF = and RESTCONF, wouldn't the same set of trusted ca/client certs be used for both?

Since both the netconf-server and restconf-server models are in the sa= me draft, it would be relatively easy to define a 3rd YANG model in this dr= aft (no need for a new draft).  But the recent email thread with Juerg= en regarding keychains highlights an opportunity to do something more applicable to other drafts (e.g., LMAP), = which would fix both this issue (how to validate client-certs) as well as t= he issue of knowing which SSH host-keys or TLS server-certs to advertise.

Options:
   1. Do nothing   (keep all separate)   [issue --= > DEAD]
   2. Only unify netconf/ssh and netconf/tls  (current = plan)
   3. Unify across netconf/ssh, netconf/tls, and restconf/tl= s
        A. do this using a 3rd YANG module in this= draft
        B. do this by using "poor-man" l= eafrefs 
               - i.e. a string= that points to a key in some TBD module
   4. Work on a keychain solution of some sort
            - this would delay server-mo= del draft longer...

I'm on the fence, but my preferences in order are 4, 2, 1, 3B, 3A

Kent


From: Kent Watsen <kwatsen@juniper.net>
Date: Monday, May 18, 2015 at 6:15 = PM
To: "netconf@ietf.org" <netconf@ietf.org>
Subject: Re: [Netconf] server-model= #49: combine trusted-ca-certs and trusted-client-certs for ssh/tls?


The solution described below is now considered verified.

Thanks,
Kent


From: Kent Watsen <kwatsen@juniper.net>
Date: Sunday, March 29, 2015 at 7:0= 6 PM
To: "netconf@ietf.org" <netconf@ietf.org>
Subject: [Netconf] server-model #49= : combine trusted-ca-certs and trusted-client-certs for ssh/tls?


This issue (see subject line and/or = link below) was discussed during the Dallas meeting with an agreement to combine the con= figuration for trusted CA-certs and client-certs into one container for both SSH and TLS.  T= he new container would use the following YANG 1.1 if-feature statement (ass= uming the WG adopts that resolution):

    if-feature “(ssh-x509-certs or tls)”;

This issue is hence moved to the VER= IFY state.  The issue will move to the EDIT state if no objection is raised by Apri= l 6th.


Thanks,
Kent

 --_000_D1939D27A8F18kwatsenjunipernet_-- From nobody Tue Jun 2 22:39:35 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BEE81B354E for ; Tue, 2 Jun 2015 22:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDEAroNSTi_X for ; Tue, 2 Jun 2015 22:39:30 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 399021B354F for ; Tue, 2 Jun 2015 22:39:30 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D85C810FB; Wed, 3 Jun 2015 07:39: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 VjeVrv2d8gAo; Wed, 3 Jun 2015 07:39:02 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 3 Jun 2015 07:39:28 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id CFF5720013; Wed, 3 Jun 2015 07:39:27 +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 2RZOYcbR9mPh; Wed, 3 Jun 2015 07:39:27 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A93D82002B; Wed, 3 Jun 2015 07:39:26 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0554934276FF; Wed, 3 Jun 2015 07:39:25 +0200 (CEST) Date: Wed, 3 Jun 2015 07:39:25 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20150603053925.GA69619@elstar.local> Mail-Followup-To: Martin Bjorklund , randy_presuhn@mindspring.com, netconf@ietf.org References: <457915.1433262826425.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> <20150602.230131.1772714071737939282.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150602.230131.1772714071737939282.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: randy_presuhn@mindspring.com, netconf@ietf.org Subject: Re: [Netconf] How to augment RFC6470 to supply detail configuration change information X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 05:39:32 -0000 On Tue, Jun 02, 2015 at 11:01:31PM +0200, Martin Bjorklund wrote: > Randy Presuhn wrote: > > Hi - > > > > >From: Juergen Schoenwaelder > > >Sent: Jun 1, 2015 11:47 PM > > ... > > >Subject: Re: [Netconf] How to augment RFC6470 to supply detail configuration change information > > > > > >But it is not the writable configuration data but more a copy of the > > >configuration data that got changed. Anyway, if you want to insist > > >that this is a violation of section 7.10 of RFC6020, then don't do > > >it. I do not believe it is a violation of section 7.10 of RFC6020. > > > > I think this thread makes it clear that there is an unintended > > ambiguity in the statement "it is RECOMMENDED that the 'anyxml' > > statement not be used to represent configuration data." Perhaps > > replacing the word "represent" with "define" might reduce the > > ambiguity. > > Yes, I was thinking along these lines as well. I think this is a good > suggestion. > Martin, since you have seen this, I assume you will take care of making this change. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Jun 3 03:30:21 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B40CF1A0277 for ; Wed, 3 Jun 2015 03:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghB8fXD6ddTm for ; Wed, 3 Jun 2015 03:30:17 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC49E1A0276 for ; Wed, 3 Jun 2015 03:30:16 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B06DA765; Wed, 3 Jun 2015 12:30:15 +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 aPexxbxdsXCV; Wed, 3 Jun 2015 12:29:48 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 3 Jun 2015 12:30:14 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 501CC20013; Wed, 3 Jun 2015 12:30:14 +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 90YE2V1S5Xcq; Wed, 3 Jun 2015 12:30:12 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 323072002B; Wed, 3 Jun 2015 12:30:12 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 47CBE3427C5C; Wed, 3 Jun 2015 12:30:12 +0200 (CEST) Date: Wed, 3 Jun 2015 12:30:12 +0200 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20150603103012.GB70405@elstar.local> Mail-Followup-To: Kent Watsen , "netconf@ietf.org" References: <20150318224028.GA38182@elstar.local> <20150602054335.GB66192@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-call-home-04 and draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and server-model-06 available - All Open issues closed X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 10:30:19 -0000 On Tue, Jun 02, 2015 at 09:44:24PM +0000, Kent Watsen wrote: > > > >OK. What about the other then? > > > >It would IMHO be nice to have a keychain YANG model so that we could > >have a common way to deal with security credentials. I am struggling > >with the need to refer to certificates and other credentials in the > >LMAP YANG data model and I would love to be able to simply refer to a > >keychain data model instead of creating another ad-hoc solution. > > > Are you referring to the leaf "credentials" in draft-ietf-lmap-yang? This > leaf appears to be for client auth: username, password, rsa-key, > client-cert, and the like. The server-model doesn't configure > client-auth; not even for call home, as the NETCONF/RESTCONF server is > always the SSH/TLS server (never the client). Nonetheless, I appreciate > that client auth is a common use case for a keychains (password managers / > vaults) > > However, as we've been discussing in this thread, the server-model does > need to configure which SSH host-keys or TLS server-certs the server > presents when establishing secure connections. Ideally there is a global > store of host-keys and server-certificates that can be referenced on a > per-use basis (e.g., present cert-1 when accepting a connection, present > cert-2 when establishing a call home connection to app-2, etc.). > > Another consideration is that keychains are often used to store trust > anchors. Both lmap and server-model need trust anchors. LMAP uses trust > anchors to authenticate the server-certificate of a server it is > connecting to, whereas server-model uses trust anchors to authenticate the > client-certificate of a client that is connecting to it. Again, there > should be a global store of trust anchors that specific apps can > cherry-pick from. For instance, use Verisign's trust anchor is OK when > connecting to 3rd-party web-server, but assert a specific trust anchor > when connecting to a well-known service. > > Do we want to act on this now, or proceed with current drafts? This is a tough question. I will take time to fully work out a keychain module but once we have it, we surely safe effort in many other places. Since using encryption is now a must, almost all protocols will have configuration objects to setup the necessary credentials and trust anchors. So in an ideal world, we would have a generic infrastructure for this. But yes, creating such an infrastructure delays other work, ranging from administrative questions (which WG would host this effor (perhaps NETMOD), how we get security folks involved (or whether they even prefer to host it) etc.) and of course technical details. From an LMAP perspective, I would love to simply refer to something else instead of trying to cook our own solution. But then it is the LMAP WG to make that decision. > Sketching this out quickly, maybe something like this: > > module: ietf-keychain > +--rw client-credentials > | +--rw client-credential* [name] > | +--rw name string > | +--rw type enumeration // password, > rsa-key, etc. > | +--rw value anydata // type-specific format > +--rw private-keys > | +--rw private-key* [name] > | +--x generate-new // returns public key > | +--rw name string > | +--rw type enumeration // elliptic, rsa, > dsa, etc. > | +--rw value anydata // type-specific format > > > +--rw host-keys > | +--rw host-key* [name] > | +--x generate-new // input res a private key > > | +--rw name string > | +--rw type enumeration // rsa, dss, x509, > etc. > | +--rw value anydata // type-specific format > > +--rw server-certificates > > | +--rw server-certificate* [name] > | +--x generate-csr // returns a cert signing > request > | +--rw name string > | +--rw certificate binary > > +--rw trust-anchors > +--rw trust-anchor* [name] > +--rw name string > +--rw certificate binary > > > Then server-model would be something like > > import ietf-keychain { > prefix kc; > } > ... > container tls { > container trusted-ca-certs { > leaf trusted-ca-cert { > type leafref { > path "/kc:trust-anchors/kc:trust-anchor/kc:name"; > } > } > } > } > > > What do you think? Yep, this is a good sketch of something I would love to have for the LMAP data mdoel. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Jun 3 11:17:30 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8814A1A90BA for ; Wed, 3 Jun 2015 11:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.013 X-Spam-Level: X-Spam-Status: No, score=-0.013 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXLC6Q6dpBac for ; Wed, 3 Jun 2015 11:17:22 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id CCBC61ACED9 for ; Wed, 3 Jun 2015 11:17:21 -0700 (PDT) Received: from mainfs.snmp.com (mainfs.snmp.com [192.147.142.124]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id OAA28848; Wed, 3 Jun 2015 14:17:20 -0400 (EDT) Received: from mainfs.snmp.com (localhost [127.0.0.1]) by mainfs.snmp.com (8.14.5/8.14.5) with ESMTP id t53IHJRA066849; Wed, 3 Jun 2015 14:17:19 -0400 (EDT) (envelope-from luchuk@mainfs.snmp.com) Received: (from luchuk@localhost) by mainfs.snmp.com (8.14.5/8.14.5/Submit) id t53IHJit066848; Wed, 3 Jun 2015 14:17:19 -0400 (EDT) (envelope-from luchuk) Date: Wed, 3 Jun 2015 14:17:19 -0400 (EDT) From: Alan Luchuk Message-Id: <201506031817.t53IHJit066848@mainfs.snmp.com> To: , , In-Reply-To: Your message of Sat, 30 May 2015 00:02:22 +0000 References: <201505221959.t4MJxRHR081289@mainfs.snmp.com> X-Mailer: mail (GNU Mailutils 2.2) Archived-At: Subject: Re: [Netconf] draft-ietf-netconf-call-home-05.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 18:17:28 -0000 Hi Kent, >Thanks again for another great review. Below are my responses to your >comments. I was hoping to receive more comments before posting an updated >draft, but went ahead and posted -06 just now to reflect this update. You're welcome! >>Page 6, section 2.1, item C5: >>----------------------------- >> >>The text reads: >> >> validation data (e.g., pinning, using the entire host key or >> certificate as the lookup key) or via certificate path validation >> >>Perhaps delete the word "pinning"? >> >>Upon first read, I was not sure what "pinning" meant. Upon a second read, >>I assume that "pinning" is defined by the rest of the phrase in >>parenthesis. > > >I addressed this specific issue by changing the wording to "...to a >previously trusted or 'pinned' value". So it becomes self-defining. Is >this is acceptable? I think the new text is clearer. > >>As an unrelated issue, the phrase suggests the _entire_ certificate is >>used >>as the lookup key. Is this what was intended? > >Yes, but looking at it more carefully, I felt that the entire bullet point >wasn't clear enough and hence rewrote that section. Please see the >diff for details: >https://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-call-home-06.txt Thanks for the suggestion. I studied this differences fairly carefully. The new text is more specific, and I agree it is an improvement from the previous text in draft-05. Nit: Would it clarify the text in item "C6" to change "reference identifier" to "server reference identifier"? FWIW, I'm not fond of the term "reference identifier", but it is probably the best choice. Alternatives would probably be more wordy, and reduce the overall clarity of the text. Regards, --Alan From nobody Wed Jun 3 12:17:40 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59AC41AD0D0 for ; Wed, 3 Jun 2015 12:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-kjCdKbcdXI for ; Wed, 3 Jun 2015 12:17:36 -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 5C4B81B2A02 for ; Wed, 3 Jun 2015 12:17:30 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.1.172.22; Wed, 3 Jun 2015 19:17:12 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.154]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.154]) with mapi id 15.01.0172.012; Wed, 3 Jun 2015 19:17:12 +0000 From: Kent Watsen To: Alan Luchuk , "netconf@ietf.org" Thread-Topic: draft-ietf-netconf-call-home-05.txt Thread-Index: AQHQlMnODg1iNSV/nEqfYnzAyUNFnZ2R9YQAgAk0BUX//82dgA== Date: Wed, 3 Jun 2015 19:17:11 +0000 Message-ID: References: <201505221959.t4MJxRHR081289@mainfs.snmp.com> <201506031817.t53IHJit066848@mainfs.snmp.com> In-Reply-To: <201506031817.t53IHJit066848@mainfs.snmp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.11] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520003)(3002001); SRVR:CO1PR05MB457; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457; x-forefront-prvs: 05961EBAFC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(51914003)(189002)(76104003)(106116001)(105586002)(54356999)(66066001)(2656002)(46102003)(87936001)(83506001)(50986999)(230783001)(5001770100001)(76176999)(101416001)(189998001)(86362001)(81156007)(4001350100001)(4001540100001)(97736004)(107886002)(5001960100002)(5001830100001)(5001860100001)(5001920100001)(36756003)(106356001)(2501003)(68736005)(40100003)(99286002)(64706001)(2950100001)(77156002)(5002640100001)(122556002)(62966003)(102836002)(92566002)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-ID: <8CA8EBFC4309034688B6D752EF7E9792@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jun 2015 19:17:11.6789 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB457 Archived-At: Subject: Re: [Netconf] draft-ietf-netconf-call-home-05.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 19:17:38 -0000 >Thanks for the suggestion. I studied this differences fairly carefully. >The new text is more specific, and I agree it is an improvement from the >previous text in draft-05. No new split infinitives? ;) >Nit: Would it clarify the text in item "C6" to change "reference >identifier"=20 >to "server reference identifier"? >FWIW, I'm not fond of the term "reference identifier", but it is probably >the best choice. Alternatives would probably be more wordy, and reduce >the overall clarity of the text. This term comes from RFC 6125, Section 1.8. A reference to it should be added. But looking at 6125 again, I see it defines "identifier" as being of two kinds "reference" and "presented". In C6, though discussing presented identifiers, I think just using "identifier" by itself makes the most sense. Same for section 2.2. What do you think? Kent From nobody Wed Jun 3 14:28:18 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 992241B2E3E for ; Wed, 3 Jun 2015 14:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5Tgt5ciimwY for ; Wed, 3 Jun 2015 14:28:16 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5E40D1B29A8 for ; Wed, 3 Jun 2015 14:28:14 -0700 (PDT) Received: from mainfs.snmp.com (mainfs.snmp.com [192.147.142.124]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id RAA17451; Wed, 3 Jun 2015 17:28:12 -0400 (EDT) Received: from mainfs.snmp.com (localhost [127.0.0.1]) by mainfs.snmp.com (8.14.5/8.14.5) with ESMTP id t53LSCIU069497; Wed, 3 Jun 2015 17:28:12 -0400 (EDT) (envelope-from luchuk@mainfs.snmp.com) Received: (from luchuk@localhost) by mainfs.snmp.com (8.14.5/8.14.5/Submit) id t53LSB5u069496; Wed, 3 Jun 2015 17:28:11 -0400 (EDT) (envelope-from luchuk) Date: Wed, 3 Jun 2015 17:28:11 -0400 (EDT) From: Alan Luchuk Message-Id: <201506032128.t53LSB5u069496@mainfs.snmp.com> To: , , In-Reply-To: Your message of Wed, 3 Jun 2015 19:17:11 +0000 References: <201505221959.t4MJxRHR081289@mainfs.snmp.com> <201506031817.t53IHJit066848@mainfs.snmp.com> X-Mailer: mail (GNU Mailutils 2.2) Archived-At: Subject: Re: [Netconf] draft-ietf-netconf-call-home-05.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 21:28:17 -0000 Hello, >>Thanks for the suggestion. I studied this differences fairly carefully. >>The new text is more specific, and I agree it is an improvement from the >>previous text in draft-05. > >No new split infinitives? ;) I can go back and look again :-) >>Nit: Would it clarify the text in item "C6" to change "reference >>identifier" >>to "server reference identifier"? >>FWIW, I'm not fond of the term "reference identifier", but it is probably >>the best choice. Alternatives would probably be more wordy, and reduce >>the overall clarity of the text. > > >This term comes from RFC 6125, Section 1.8. A reference to it should be >added. But looking at 6125 again, I see it defines "identifier" as being >of two kinds "reference" and "presented". In C6, though discussing >presented identifiers, I think just using "identifier" by itself makes the >most sense. Same for section 2.2. What do you think? I agree that just using "identifier" by itself will be the simplest and clearest. Also, I agree that adding a reference to RFC 6125 would be helpful (and to include section 1.8, if possible.) Regards, --Alan From nobody Wed Jun 3 17:54:47 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31A161B30F7; Wed, 3 Jun 2015 17:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9mMvEH1A-Qf; Wed, 3 Jun 2015 17:54:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C749F1B30F5; Wed, 3 Jun 2015 17:54:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150604005429.4589.39914.idtracker@ietfa.amsl.com> Date: Wed, 03 Jun 2015 17:54:29 -0700 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-call-home-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2015 00:54:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : NETCONF Call Home and RESTCONF Call Home Author : Kent Watsen Filename : draft-ietf-netconf-call-home-07.txt Pages : 13 Date : 2015-06-03 Abstract: This RFC presents NETCONF Call Home and RESTCONF Call Home, which enable a NETCONF or RESTCONF server to initiate a secure connection to a NETCONF or RESTCONF client respectively. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-call-home/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netconf-call-home-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-call-home-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 3 18:00:38 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F25EE1B30FB for ; Wed, 3 Jun 2015 18:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1kl1pj_ZVUS for ; Wed, 3 Jun 2015 18:00:36 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0123.outbound.protection.outlook.com [65.55.169.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 066351B30F6 for ; Wed, 3 Jun 2015 18:00:35 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.1.172.22; Thu, 4 Jun 2015 01:00:34 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.154]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.154]) with mapi id 15.01.0172.012; Thu, 4 Jun 2015 01:00:34 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-call-home-07.txt Thread-Index: AQHQnmElVOosxde7Z0GafK9mr38h+p2bQ+gA Date: Thu, 4 Jun 2015 01:00:34 +0000 Message-ID: References: <20150604005429.4589.39914.idtracker@ietfa.amsl.com> In-Reply-To: <20150604005429.4589.39914.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.11] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB460; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:CO1PR05MB460; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB460; x-forefront-prvs: 0597911EE1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(51704005)(199003)(377424004)(377454003)(24454002)(479174004)(19580405001)(5002640100001)(46102003)(92566002)(2501003)(83506001)(76176999)(19580395003)(87936001)(64706001)(101416001)(66066001)(2656002)(15975445007)(68736005)(106116001)(102836002)(106356001)(2900100001)(2950100001)(2351001)(54356999)(230783001)(77156002)(122556002)(40100003)(81156007)(99286002)(105586002)(86362001)(5001860100001)(110136002)(5001960100002)(189998001)(5001920100001)(97736004)(5001830100001)(50986999)(107886002)(450100001)(62966003)(4001350100001)(4001540100001)(36756003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jun 2015 01:00:34.2234 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB460 Archived-At: Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-call-home-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2015 01:00:38 -0000 Updated to account for Alan's last comments. Anyone else? - time for another Last Call? Kent On 6/3/15, 8:54 PM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Network Configuration Working Group of >the IETF. > > Title : NETCONF Call Home and RESTCONF Call Home > Author : Kent Watsen > Filename : draft-ietf-netconf-call-home-07.txt > Pages : 13 > Date : 2015-06-03 > >Abstract: > This RFC presents NETCONF Call Home and RESTCONF Call Home, which > enable a NETCONF or RESTCONF server to initiate a secure connection > to a NETCONF or RESTCONF client respectively. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-netconf-call-home/ > >There's also a htmlized version available at: >https://tools.ietf.org/html/draft-ietf-netconf-call-home-07 > >A diff from the previous version is available at: >https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-call-home-07 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf From nobody Thu Jun 4 17:48:56 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B537D1ACE0B for ; Thu, 4 Jun 2015 17:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbnu6c8B9T2S for ; Thu, 4 Jun 2015 17:48:47 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0766.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:766]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28F121ACE0D for ; Thu, 4 Jun 2015 17:48:41 -0700 (PDT) Received: from CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) by CO1PR05MB475.namprd05.prod.outlook.com (10.141.72.19) with Microsoft SMTP Server (TLS) id 15.1.172.22; Fri, 5 Jun 2015 00:48:21 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.172.22; Fri, 5 Jun 2015 00:48:20 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.154]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.154]) with mapi id 15.01.0172.012; Fri, 5 Jun 2015 00:48:20 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] server-model #54: move idle-timeout from global "session-options" to the "listen" tree? Thread-Index: AQHQnylRVSAYbzmnCkGtm2Dh3wuOiA== Date: Fri, 5 Jun 2015 00:48:19 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.11] x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(42139001); SRVR:CO1PR05MB459; UriScan:; BCL:0; PCL:0; RULEID:(42139001); SRVR:CO1PR05MB475; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:CO1PR05MB459; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; x-forefront-prvs: 05986C03E0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(31014004)(24454002)(76104003)(377454003)(164054003)(99286002)(5001960100002)(50986999)(19580395003)(4001350100001)(110136002)(83506001)(16236675004)(19580405001)(107886002)(36756003)(66066001)(106116001)(189998001)(122556002)(40100003)(86362001)(5002640100001)(87936001)(102836002)(2351001)(2656002)(54356999)(77156002)(46102003)(450100001)(2501003)(62966003)(92566002)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_D19667CDA96E2kwatsenjunipernet_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jun 2015 00:48:19.8489 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459 X-OriginatorOrg: juniper.net Archived-At: Subject: Re: [Netconf] server-model #54: move idle-timeout from global "session-options" to the "listen" tree? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 00:48:53 -0000 --_000_D19667CDA96E2kwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable No response on this issue yet, but in reviewing some comments posted before= , I noticed Martin wrote: o call-home / application / connection-type / persistent-connection By default, if we configure a call-home "application", we have a persistent-connention with keep-alives being sent on the transport layer ever 15 seconds. But we also have the idle-timeout that works on the messages layer default to 3600 seconds. So it seems to me that unless there is NETCONF traffic, the persistent connection will be closed by the idle-timeout after 3600 seconds. But since the connection was persistent, the device will immediately re-establish the connection, and so on. This is what I meant by "unhelpful" below. It's tempting to move keep-alives from the SSH/TLS layer to the NETCONF/RES= TCONF layer, but : 1. Neither NETCONF nor RESTCONF support server-initiated RPCs 2. Using notifications (push/pull) would require the client subscribes to n= otifications *and* that the notification includes a correlation identifier = for the NETCONF/RESTCONF "session" (can't really call it that for RESTCONF)= the server is trying to solicit a response for. Kent From: Kent Watsen > Date: Monday, June 1, 2015 at 8:38 PM To: "netconf@ietf.org" > Subject: [Netconf] server-model #54: move idle-timeout from global "session= -options" to the "listen" tree? [This is a new issue] Currently, "idle-timeout" is configured in the global "session-options" tre= e, which applies to all connections, both listen and call-home. But it's un= clear if idle-timeout makes sense for call home connections, and hence shou= ld be moved to being only under the listen tree. Keep in mind that there a= re two types of call home connections: persistent and periodic. The follow= ing describes the effect of idle-timeout on each. For persistent connections, it doesn't makes sense to me that the server wo= uld ever idle-timeout a connection. This perspective is bolstered by persis= tent connections having keep-alives, so the server can detect when a client= connection has been lost and it needs to initiate a new one. An idle-timeo= ut here would be unhelpful. For periodic connections, the idle-timeout is way too course (default 1 hou= r). We use to have a "linger-timeout" for this purpose (default 30 secs), b= ut a side meeting in Dallas concluded that it was unneeded, as the client w= ould close the connection as and when it was ready. Still, the intent is th= at the connection wouldn't stay open anywhere close to the periodic interva= l (default 5 mins). An idle-timeout here is nearly useless. So, if unhelpful for persistent connections and nearly useless for periodic= connections, perhaps we should just move idle-timeout to the listen tree? = What do you think? Thanks, Kent --_000_D19667CDA96E2kwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

No response on this issue yet, but in reviewing some comments posted before= , I noticed Martin wrote:

    o  call-home / ap= plication / connection-type / persistent-connection

      By default, if = we configure a call-home "application", we have a
      persistent-conn= ention with keep-alives being sent on the transport
      layer ever 15 s= econds.  But we also have the idle-timeout that works
      on the messages= layer default to 3600 seconds.

      So it seems to = me that unless there is NETCONF traffic, the
      persistent conn= ection will be closed by the idle-timeout after 3600
      seconds.  = But since the connection was persistent, the device will
      immediately re-= establish the connection, and so on.

This is what I meant by "unhelpful" below.

It's tempting to move keep-alives from the SSH/TLS layer to the NETCONF/RES= TCONF layer, but :
1. Neither NETCONF nor RESTCONF support server-initiated RPCs
2. Using notifications (push/pull) would require the client subscribes to n= otifications *and* that the notification includes a correlation identifier = for the NETCONF/RESTCONF "session" (can't really call it that for= RESTCONF) the server is trying to solicit a response for.

Kent


From: Kent Watsen <kwatsen@juniper.net>
Date: Monday, June 1, 2015 at 8:38 = PM
To: "netconf@ietf.org" <netconf@ietf.org>
Subject: [Netconf] server-model #54= : move idle-timeout from global "session-options" to the "li= sten" tree?


[This is a new issue]

Currently, "idle-timeout" = is configured in the global "session-options" tree, which applies= to all connections, both listen and call-home. But it's unclear if idle-ti= meout makes sense for call home connections, and hence should be moved to being only under the listen tree.  Keep in mind th= at there are two t= ypes of call home connections: persistent and periodic.  The following= describes the effect of idle-timeout on each.

For persistent connections, it doesn= 't makes sense to me that the server would ever idle-timeout a connection. = This perspective is bolstered by persistent connections having keep-alives,= so the server can detect when a client connection has been lost and it needs to initiate a new one. An idle-timeo= ut here would be unhelpful.

For periodic connections, the idle-t= imeout is way too course (default 1 hour). We use to have a "linger-ti= meout" for this purpose (default 30 secs), but a side meeting in Dalla= s concluded that it was unneeded, as the client would close the connection as and when it was ready. Still, the intent is = that the connection wouldn't stay open anywhere close to the periodic inter= val (default 5 mins). An idle-timeout here is nearly useless.

So, if unhelpful for persistent conn= ections and nearly useless for periodic connections, perhaps we should just= move idle-timeout to the listen tree?  What do you think?

Thanks,
Kent

--_000_D19667CDA96E2kwatsenjunipernet_-- From nobody Thu Jun 4 19:01:56 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3AFC1AD210 for ; Thu, 4 Jun 2015 19:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gb_N4L5xXR5R for ; Thu, 4 Jun 2015 19:01:54 -0700 (PDT) Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB5531AD1F5 for ; Thu, 4 Jun 2015 19:01:53 -0700 (PDT) Received: by lbcmx3 with SMTP id mx3so37612139lbc.1 for ; Thu, 04 Jun 2015 19:01:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7yIZrA4TubdJ79tq5x7+LUjNvm2NBYTMidUtjfeQyQI=; b=Lg01TolOCnq71EweG4oVHHSEXyJ2tTP8q/Rl9guh/UCiIBMhesjXno/gw45ZSqK2lb wweQ0bMy7BYf80EcQuUPViaOW8QABwpbThvQanRrZ1uSjV7OYgKOd/7tWonMwzbuyyig /b/omAY1CCwVNnb7Df3KTyg+Udk/vT+IcfHqGmyYvD/izuNlqvKXfQsLnmA1Sjc0qM9h 105bAxKfpyWs6VkIwy34xkmy+jgBBcwsSGAmUed+7EM7ap1v1NbrPvdYlVwPDVaVNWoe 0rEc3Tnl0/vnj8Waz2sIv92QtUmH3WkIkE479PD59i+F5VTvAiLeW8LHT9ZkMCBLx0G5 kKUA== X-Gm-Message-State: ALoCoQkjRZBtXBnbrn0f42lrcX6bWqdw0jBYu48WvBU2OaMvGjHyyHqSROURk51VSSsTAAJlq3Al MIME-Version: 1.0 X-Received: by 10.112.77.234 with SMTP id v10mr895530lbw.119.1433469712193; Thu, 04 Jun 2015 19:01:52 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Thu, 4 Jun 2015 19:01:52 -0700 (PDT) In-Reply-To: References: Date: Thu, 4 Jun 2015 19:01:52 -0700 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] server-model #54: move idle-timeout from global "session-options" to the "listen" tree? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 02:01:56 -0000 Hi, Your solution to move the idle-timeout to the 'listen' tree is OK. BTW, I am not a fan of the 1-use groupings in the server-model draft. They are not written to be reusable. The granularity is too coarse. E.g., the entire listen tree or entire callhome tree do not seem reusable. Andy On Thu, Jun 4, 2015 at 5:48 PM, Kent Watsen wrote: > > No response on this issue yet, but in reviewing some comments posted before, > I noticed Martin wrote: > > o call-home / application / connection-type / persistent-connection > > By default, if we configure a call-home "application", we have a > persistent-connention with keep-alives being sent on the transport > layer ever 15 seconds. But we also have the idle-timeout that works > on the messages layer default to 3600 seconds. > > So it seems to me that unless there is NETCONF traffic, the > persistent connection will be closed by the idle-timeout after 3600 > seconds. But since the connection was persistent, the device will > immediately re-establish the connection, and so on. > > This is what I meant by "unhelpful" below. > > It's tempting to move keep-alives from the SSH/TLS layer to the > NETCONF/RESTCONF layer, but : > 1. Neither NETCONF nor RESTCONF support server-initiated RPCs > 2. Using notifications (push/pull) would require the client subscribes to > notifications *and* that the notification includes a correlation identifier > for the NETCONF/RESTCONF "session" (can't really call it that for RESTCONF) > the server is trying to solicit a response for. > > Kent > > > From: Kent Watsen > Date: Monday, June 1, 2015 at 8:38 PM > To: "netconf@ietf.org" > Subject: [Netconf] server-model #54: move idle-timeout from global > "session-options" to the "listen" tree? > > > [This is a new issue] > > Currently, "idle-timeout" is configured in the global "session-options" > tree, which applies to all connections, both listen and call-home. But it's > unclear if idle-timeout makes sense for call home connections, and hence > should be moved to being only under the listen tree. Keep in mind that > there are two types of call home connections: persistent and periodic. The > following describes the effect of idle-timeout on each. > > For persistent connections, it doesn't makes sense to me that the server > would ever idle-timeout a connection. This perspective is bolstered by > persistent connections having keep-alives, so the server can detect when a > client connection has been lost and it needs to initiate a new one. An > idle-timeout here would be unhelpful. > > For periodic connections, the idle-timeout is way too course (default 1 > hour). We use to have a "linger-timeout" for this purpose (default 30 secs), > but a side meeting in Dallas concluded that it was unneeded, as the client > would close the connection as and when it was ready. Still, the intent is > that the connection wouldn't stay open anywhere close to the periodic > interval (default 5 mins). An idle-timeout here is nearly useless. > > So, if unhelpful for persistent connections and nearly useless for periodic > connections, perhaps we should just move idle-timeout to the listen tree? > What do you think? > > Thanks, > Kent > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Thu Jun 4 20:57:01 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8901AC82C; Thu, 4 Jun 2015 20:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J_DzLZsxSu3I; Thu, 4 Jun 2015 20:56:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 991B01AD49F; Thu, 4 Jun 2015 20:56:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150605035657.21576.36738.idtracker@ietfa.amsl.com> Date: Thu, 04 Jun 2015 20:56:57 -0700 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-restconf-05.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 03:56:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : RESTCONF Protocol Authors : Andy Bierman Martin Bjorklund Kent Watsen Filename : draft-ietf-netconf-restconf-05.txt Pages : 103 Date : 2015-06-04 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netconf-restconf-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-restconf-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jun 4 20:58:19 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5F11A908C; Thu, 4 Jun 2015 20:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LlsXJcfRJUDp; Thu, 4 Jun 2015 20:58:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7D01B2A71; Thu, 4 Jun 2015 20:58:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150605035815.21998.75883.idtracker@ietfa.amsl.com> Date: Thu, 04 Jun 2015 20:58:15 -0700 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-yang-patch-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 03:58:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : YANG Patch Media Type Authors : Andy Bierman Martin Bjorklund Kent Watsen Filename : draft-ietf-netconf-yang-patch-04.txt Pages : 29 Date : 2015-06-04 Abstract: This document describes a method for applying patches to NETCONF datastores using data defined with the YANG data modeling language. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-patch/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-yang-patch-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 5 10:31:41 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 010631A9232 for ; Fri, 5 Jun 2015 10:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GN_cxnbSe5vz for ; Fri, 5 Jun 2015 10:31:35 -0700 (PDT) Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F09DC1B3214 for ; Fri, 5 Jun 2015 10:29:37 -0700 (PDT) Received: by lbbqq2 with SMTP id qq2so50113251lbb.3 for ; Fri, 05 Jun 2015 10:29:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=64A4l+SJQHNjhv2WzfbqH00BCWiCiXxPC5Ejg7wgV+Y=; b=lJ24rM/xvDRCXQrFzMT5n+7VTSbwGjgFVgezHYhF2smac9QXiroZuG5YD4ybgw21Ze c2Nb7skNqDQ6aBy0HUX818agzrm8ebijkbmMHz++aaSaOx61SUc0PmhhzjCnYQIrvKxv i10n3US84ujwNgmr2dYFL56iVAOerkvhrruYFzZzIsrm3GLQaQH1MnBKIVbAMBxeUVKm QsoOafRX6ID5qHvnkv+BNev4T7xqqm3xOa5E/oyi+J1I4fUBvoyEVlOUnyPtC48beicb qQFmMHF0zuWl0Y29yvj/i5g+BlxfCRP9Ixhjj2UrTl1HEZYiI7prZSnnvYVoOTMhWEAV wMAA== X-Gm-Message-State: ALoCoQmm1yYBYkqj882MoYKJHfi0SYHSN30lwC8JyWOzLYsOXhx2y1QN9VoFmq/PypSKZrx1lz+S MIME-Version: 1.0 X-Received: by 10.112.56.42 with SMTP id x10mr4346080lbp.123.1433525376278; Fri, 05 Jun 2015 10:29:36 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Fri, 5 Jun 2015 10:29:36 -0700 (PDT) Date: Fri, 5 Jun 2015 10:29:36 -0700 Message-ID: From: Andy Bierman To: Netconf Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Netconf] YANG Patch Issue #3: :distinct-startup X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 17:31:40 -0000 Hi, A new issue has been raised for the YANG Patch draft. https://github.com/netconf-wg/yang-patch/issues/3 There is no support for the client to control when running is saved to startup. If this is a concern, it needs to be addressed. If not (i.e., just use NETCONF for this level of client control) then it does not need to be addressed. Please review the latest draft and the issue list and send comments to the mailing list. Andy From nobody Fri Jun 5 11:31:30 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36A161A1B49 for ; Fri, 5 Jun 2015 11:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCpE9dc9zOBF for ; Fri, 5 Jun 2015 11:31:26 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0769.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::769]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F8AA1A1B45 for ; Fri, 5 Jun 2015 11:31:26 -0700 (PDT) Received: from BN1PR05MB456.namprd05.prod.outlook.com (10.141.59.26) by BN1PR05MB454.namprd05.prod.outlook.com (10.141.59.17) with Microsoft SMTP Server (TLS) id 15.1.172.22; Fri, 5 Jun 2015 18:31:07 +0000 Received: from BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.222]) by BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.222]) with mapi id 15.01.0172.012; Fri, 5 Jun 2015 18:31:06 +0000 From: Kent Watsen To: Andy Bierman Thread-Topic: [Netconf] server-model #54: move idle-timeout from global "session-options" to the "listen" tree? Thread-Index: AQHQnylRVSAYbzmnCkGtm2Dh3wuOiJ2dKNsAgADRUoA= Date: Fri, 5 Jun 2015 18:31:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.11] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB454; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520003)(3002001); SRVR:BN1PR05MB454; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB454; x-forefront-prvs: 05986C03E0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(99286002)(46102003)(76176999)(50986999)(40100003)(36756003)(5002640100001)(106116001)(19580395003)(4001350100001)(189998001)(54356999)(2656002)(5001960100002)(110136002)(5001920100001)(62966003)(66066001)(77156002)(15975445007)(86362001)(92566002)(87936001)(83506001)(102836002)(2950100001)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB454; H:BN1PR05MB456.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jun 2015 18:31:05.6613 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB454 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] server-model #54: move idle-timeout from global "session-options" to the "listen" tree? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 18:31:28 -0000 >Your solution to move the idle-timeout to the 'listen' tree is OK. Thanks Andy. If no objections are raised, this solution will be considered verified on June 9th.=20 >I am not a fan of the 1-use groupings in the server-model draft. >They are not written to be reusable. The granularity is too coarse. >E.g., the entire listen tree or entire callhome tree do not seem reusable. Indeed, there has been more than one comment on this: https://github.com/netconf-wg/server-model/issues/37 All the single-use groupings are removed in the upcoming -07 Kent From nobody Fri Jun 5 12:39:22 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 566D91A9103 for ; Fri, 5 Jun 2015 12:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_IS_SMALL6=0.556, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id by58XHpEQH8v for ; Fri, 5 Jun 2015 12:39:18 -0700 (PDT) Received: from ni.com (skprod3.natinst.com [130.164.80.24]) (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 11B461A90A9 for ; Fri, 5 Jun 2015 12:39:18 -0700 (PDT) Received: from US-AUS-MAIL4.amer.corp.natinst.com (nb-snip2-1338.natinst.com [130.164.19.135]) by us-aus-skprod3.natinst.com (8.15.0.59/8.15.0.59) with ESMTP id t55JdHlc006785 for ; Fri, 5 Jun 2015 14:39:17 -0500 To: netconf@ietf.org MIME-Version: 1.0 X-KeepSent: 4C683725:1D5A213D-86257E5B:0069ECFF; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3FP3 November 16, 2012 From: Rodney Cummings Message-ID: Date: Fri, 5 Jun 2015 14:39:17 -0500 X-MIMETrack: Serialize by Router on US-AUS-MAIL4/AUS/M/NIC(Release 8.5.3FP6 HF1218|December 12, 2014) at 06/05/2015 02:39:17 PM, Serialize complete at 06/05/2015 02:39:17 PM Content-Type: multipart/alternative; boundary="=_alternative 006BF73686257E5B_=" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-06-05_14:, , signatures=0 Archived-At: Subject: [Netconf] Suggestion for RESTCONF section 5.3 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 19:39:20 -0000 This is a multipart message in MIME format. --=_alternative 006BF73686257E5B_= Content-Type: text/plain; charset="US-ASCII" Hello, Although I am new to the NETCONF WG and mailing list, I have a suggestion for the RESTCONF I-D that I'd like to discuss. I realize that I may be bringing up a topic that has already been thoroughly discussed. Nevertheless, this issue is a genuine problem for deployment of RESTCONF for my applications, so if my suggestion is rejected, it will be helpful for me understand the rationale. Suggestion -- Section 5.3 of the current I-D ( https://tools.ietf.org/html/draft-ietf-netconf-restconf-04) states: "Content is encoded in either JSON or XML format. A server MUST support XML encoding and MAY support JSON encoding." My suggestion is to change section 5.3 to state: "Content is encoded in either JSON or XML format. A client MUST support at least one of the specified encodings (XML or JSON), and a client SHOULD support all specified encodings. A server MUST support at least one of the specified encodings (XML or JSON), and a server MAY support multiple encodings." In other words, if a server wants to focus on JSON exclusively, allow that as a conformant implementation. The client has a presumed burden to support a server that is XML-only or JSON-only. Rationale -- As part of a roadmap for supporting industrial IoT devices, the 802.1 Time-Sensitive Networking standards (TSN) are focusing on YANG modules for configuration of the low-level queuing behavior in 802.1 switches (e.g. schedule for traffic egress on each port). The assumption is that an SDN-style controller will use these YANG modules to write configuration to each switch in the network in an automated manner. Ideally, as TSN moves forward it will be well-aligned with analogous IETF efforts, including CoRE, 6TiSCH, and DetNet (upcoming BoF in July). One near-term focus for the TSN effort is to support an IoT device (e.g. industrial motor, smart grid IED) that supports Ethernet today, but that wants to embed an 802.1 switch. The goal is to expose two external ports from the device, using the switch to enable topologies like daisy-chain and ring. This is commonly done today using proprietary Ethernet extensions, but we want to transition industrial applications to 802/IETF standards (much like the 6TiSCH effort for wireless). The challenge is that although this IoT device is technically a switch/router, it is very "Operational Technology" (OT). A YANG-based management protocol is required to configure the switch, but the switch supports a subset of what a standalone managed switch/router supports, and the switch will always be configured in-band from an OT controller, never from an IT-style NMS. >From the perspective of one of these IoT device manufacturers, the primary question for management is: What YANG-based management protocol do I implement in my device? Among others, I've been tasked to help answer this question for TSN and its related groups (e.g. AVnu.org/industrial). The assumption is that the manufacturer will use one and only one server implementation. Since the goal is not to support a traditional NMS, implementation of multiple servers is not a goal (e.g. SNMPv3 and NETCONF and RESTCONF XML and so on). Based on this, I've been trying to choose among the following implementations in order to make a recommendation: 1. NETCONF with XML encoding 2. RESTCONF with XML encoding 3. RESTCONF with JSON encoding 4. CoMI with CBOR encoding For the industrial application space that I am evaluating, the devices are "constrained" as CoRE describes. Nevertheless, over the last few years it has become common for these devices to implement an HTTP web server for configuration. These web servers are often designed as RESTful. Given the constrained nature of the devices, they tend to use JSON, due to the perception that XML parsing is less efficient. Based on these assumptions, I tend to exclude NETCONF. NETCONF is full-featured, but most of those features are relevant to NMS concerns. Also, NETCONF's basis on XML raises a perception (if not reality) of complex implementation. CoMI looks promising, since it is based on relatively mature RFCs like CoAP and CBOR. Nevertheless, the CoMI I-D itself looks like it is not-quite-ready-for-prime-time. There are many TODOs, and the YANG hash seems like it will require more prototyping before it is truly nailed down. Given that, I can't really recommend that direction just yet, but ideally it will be useful in the future. That leaves RESTCONF. Since the industrial device manufacturers tend to be familiar with REST already, this is an easy sell. The I-D itself seems to be relatively mature. Ideally, I could recommend option 3, RESTCONF with JSON. That is the cleanest fit to what industrial devices do today. Given the limitations of section 5.3 in v04 of the I-D, I would be forced to recommend option 2, RESTCONF with XML. If the IoT device is forced to implement XML for conformance, then the addition of JSON doesn't offer much value, since the goal is automated configuration. If we could allow RESTCONF server implementation using JSON-only, that would be very helpful. What's more, that sort of conformance might leave the door open to add CoMI as a formal RESTCONF encoding in the future. Feedback is much appreciated. Thanks. ---------------------------- Rodney Cummings Principal Software Architect, Industrial/Embedded Networks National Instruments Tel: (512) 683-8544 Fax: (512) 683-8661 Email: Rodney.Cummings@ni.com --=_alternative 006BF73686257E5B_= Content-Type: text/html; charset="US-ASCII" Hello,

Although I am new to the NETCONF WG and mailing list, I have a suggestion for the RESTCONF I-D that I'd like to discuss. I realize that I may be bringing up a topic that has already been thoroughly discussed. Nevertheless, this issue is a genuine problem for deployment of RESTCONF for my applications, so if my suggestion is rejected, it will be helpful for me understand the rationale.

Suggestion
--

Section 5.3 of the current I-D (https://tools.ietf.org/html/draft-ietf-netconf-restconf-04) states:

"Content is encoded in either JSON or XML format.  A server MUST support XML encoding and MAY support JSON encoding."

My suggestion is to change section 5.3 to state:

"Content is encoded in either JSON or XML format.  A client MUST support at least one of the specified encodings (XML or JSON), and a client SHOULD support all specified encodings.  A server MUST support at least one of the specified encodings (XML or JSON), and a server MAY support multiple encodings."

In other words, if a server wants to focus on JSON exclusively, allow that as a conformant implementation. The client has a presumed burden to support a server that is XML-only or JSON-only.

Rationale
--

As part of a roadmap for supporting industrial IoT devices, the 802.1 Time-Sensitive Networking standards (TSN) are focusing on YANG modules for configuration of the low-level queuing behavior in 802.1 switches (e.g. schedule for traffic egress on each port). The assumption is that an SDN-style controller will use these YANG modules to write configuration to each switch in the network in an automated manner. Ideally, as TSN moves forward it will be well-aligned with analogous IETF efforts, including CoRE, 6TiSCH, and DetNet (upcoming BoF in July).

One near-term focus for the TSN effort is to support an IoT device (e.g. industrial motor, smart grid IED) that supports Ethernet today, but that wants to embed an 802.1 switch. The goal is to expose two external ports from the device, using the switch to enable topologies like daisy-chain and ring. This is commonly done today using proprietary Ethernet extensions, but we want to transition industrial applications to 802/IETF standards (much like the 6TiSCH effort for wireless). The challenge is that although this IoT device is technically a switch/router, it is very "Operational Technology" (OT). A YANG-based management protocol is required to configure the switch, but the switch supports a subset of what a standalone managed switch/router supports, and the switch will always be configured in-band from an OT controller, never from an IT-style NMS.

From the perspective of one of these IoT device manufacturers, the primary question for management is:
        What YANG-based management protocol do I implement in my device?
Among others, I've been tasked to help answer this question for TSN and its related groups (e.g. AVnu.org/industrial). The assumption is that the manufacturer will use one and only one server implementation. Since the goal is not to support a traditional NMS, implementation of multiple servers is not a goal (e.g. SNMPv3 and NETCONF and RESTCONF XML and so on).

Based on this, I've been trying to choose among the following implementations in order to make a recommendation:
1. NETCONF with XML encoding
2. RESTCONF with XML encoding
3. RESTCONF with JSON encoding
4. CoMI with CBOR encoding

For the industrial application space that I am evaluating, the devices are "constrained" as CoRE describes. Nevertheless, over the last few years it has become common for these devices to implement an HTTP web server for configuration. These web servers are often designed as RESTful. Given the constrained nature of the devices, they tend to use JSON, due to the perception  that XML parsing is less efficient.

Based on these assumptions, I tend to exclude NETCONF. NETCONF is full-featured, but most of those features are relevant to NMS concerns. Also, NETCONF's basis on XML raises a perception (if not reality) of complex implementation.

CoMI looks promising, since it is based on relatively mature RFCs like CoAP and CBOR. Nevertheless, the CoMI I-D itself looks like it is not-quite-ready-for-prime-time. There are many TODOs, and the YANG hash seems like it will require more prototyping before it is truly nailed down. Given that, I can't really recommend that direction just yet, but ideally it will be useful in the future.

That leaves RESTCONF. Since the industrial device manufacturers tend to be familiar with REST already, this is an easy sell. The I-D itself seems to be relatively mature.

Ideally, I could recommend option 3, RESTCONF with JSON. That is the cleanest fit to what industrial devices do today.

Given the limitations of section 5.3 in v04 of the I-D, I would be forced to recommend option 2, RESTCONF with XML. If the IoT device is forced to implement XML for conformance, then the addition of JSON doesn't offer much value, since the goal is automated configuration.

If we could allow RESTCONF server implementation using JSON-only, that would be very helpful. What's more, that sort of conformance might leave the door open to add CoMI as a formal RESTCONF encoding in the future.

Feedback is much appreciated. Thanks.

----------------------------
Rodney Cummings
Principal Software Architect, Industrial/Embedded Networks
National Instruments
Tel: (512) 683-8544
Fax: (512) 683-8661
Email: Rodney.Cummings@ni.com --=_alternative 006BF73686257E5B_=-- From nobody Fri Jun 5 15:04:15 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAF8A1A8927 for ; Fri, 5 Jun 2015 15:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LmOkdiiHze2p for ; Fri, 5 Jun 2015 15:04:09 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0109.outbound.protection.outlook.com [65.55.169.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03A851A891C for ; Fri, 5 Jun 2015 15:04:08 -0700 (PDT) Received: from BN1PR05MB456.namprd05.prod.outlook.com (10.141.59.26) by BN1PR05MB453.namprd05.prod.outlook.com (10.141.59.11) with Microsoft SMTP Server (TLS) id 15.1.172.22; Fri, 5 Jun 2015 22:04:06 +0000 Received: from BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.222]) by BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.222]) with mapi id 15.01.0172.012; Fri, 5 Jun 2015 22:04:06 +0000 From: Kent Watsen To: Rodney Cummings , "netconf@ietf.org" Thread-Topic: [Netconf] Suggestion for RESTCONF section 5.3 Thread-Index: AQHQn8dYJX+wiW2ymE+qh4KUiM/xqJ2eNHUA Date: Fri, 5 Jun 2015 22:04:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: ni.com; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.11] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB453; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:BN1PR05MB453; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB453; x-forefront-prvs: 05986C03E0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(164054003)(252514010)(41584004)(16236675004)(92566002)(54356999)(5002640100001)(36756003)(19617315012)(86362001)(106116001)(99286002)(76176999)(50986999)(122556002)(2501003)(46102003)(87936001)(40100003)(2656002)(19580405001)(5001920100001)(15975445007)(4001350100001)(83506001)(66066001)(102836002)(5001770100001)(2950100001)(77156002)(107886002)(5001960100002)(62966003)(19580395003)(2900100001)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB453; H:BN1PR05MB456.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_D19792CCA9AA4kwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jun 2015 22:04:05.1359 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB453 Archived-At: Subject: Re: [Netconf] Suggestion for RESTCONF section 5.3 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 22:04:14 -0000 --_000_D19792CCA9AA4kwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Robert, Please see this thread: https://www.ietf.org/mail-archive/web/netconf/current/msg09218.html Thanks, Kent From: Rodney Cummings > Date: Friday, June 5, 2015 at 3:39 PM To: "netconf@ietf.org" > Subject: [Netconf] Suggestion for RESTCONF section 5.3 Hello, Although I am new to the NETCONF WG and mailing list, I have a suggestion f= or the RESTCONF I-D that I'd like to discuss. I realize that I may be bring= ing up a topic that has already been thoroughly discussed. Nevertheless, th= is issue is a genuine problem for deployment of RESTCONF for my application= s, so if my suggestion is rejected, it will be helpful for me understand th= e rationale. Suggestion -- Section 5.3 of the current I-D (https://tools.ietf.org/html/draft-ietf-netc= onf-restconf-04) states: "Content is encoded in either JSON or XML format. A server MUST support XM= L encoding and MAY support JSON encoding." My suggestion is to change section 5.3 to state: "Content is encoded in either JSON or XML format. A client MUST support at= least one of the specified encodings (XML or JSON), and a client SHOULD su= pport all specified encodings. A server MUST support at least one of the s= pecified encodings (XML or JSON), and a server MAY support multiple encodin= gs." In other words, if a server wants to focus on JSON exclusively, allow that = as a conformant implementation. The client has a presumed burden to support= a server that is XML-only or JSON-only. Rationale -- As part of a roadmap for supporting industrial IoT devices, the 802.1 Time-= Sensitive Networking standards (TSN) are focusing on YANG modules for confi= guration of the low-level queuing behavior in 802.1 switches (e.g. schedule= for traffic egress on each port). The assumption is that an SDN-style cont= roller will use these YANG modules to write configuration to each switch in= the network in an automated manner. Ideally, as TSN moves forward it will = be well-aligned with analogous IETF efforts, including CoRE, 6TiSCH, and De= tNet (upcoming BoF in July). One near-term focus for the TSN effort is to support an IoT device (e.g. in= dustrial motor, smart grid IED) that supports Ethernet today, but that want= s to embed an 802.1 switch. The goal is to expose two external ports from t= he device, using the switch to enable topologies like daisy-chain and ring.= This is commonly done today using proprietary Ethernet extensions, but we = want to transition industrial applications to 802/IETF standards (much like= the 6TiSCH effort for wireless). The challenge is that although this IoT d= evice is technically a switch/router, it is very "Operational Technology" (= OT). A YANG-based management protocol is required to configure the switch, = but the switch supports a subset of what a standalone managed switch/router= supports, and the switch will always be configured in-band from an OT cont= roller, never from an IT-style NMS. >From the perspective of one of these IoT device manufacturers, the primary = question for management is: What YANG-based management protocol do I implement in my device? Among others, I've been tasked to help answer this question for TSN and its= related groups (e.g. AVnu.org/industrial). The assumption is that the manu= facturer will use one and only one server implementation. Since the goal is= not to support a traditional NMS, implementation of multiple servers is no= t a goal (e.g. SNMPv3 and NETCONF and RESTCONF XML and so on). Based on this, I've been trying to choose among the following implementatio= ns in order to make a recommendation: 1. NETCONF with XML encoding 2. RESTCONF with XML encoding 3. RESTCONF with JSON encoding 4. CoMI with CBOR encoding For the industrial application space that I am evaluating, the devices are = "constrained" as CoRE describes. Nevertheless, over the last few years it h= as become common for these devices to implement an HTTP web server for conf= iguration. These web servers are often designed as RESTful. Given the const= rained nature of the devices, they tend to use JSON, due to the perception = that XML parsing is less efficient. Based on these assumptions, I tend to exclude NETCONF. NETCONF is full-feat= ured, but most of those features are relevant to NMS concerns. Also, NETCON= F's basis on XML raises a perception (if not reality) of complex implementa= tion. CoMI looks promising, since it is based on relatively mature RFCs like CoAP= and CBOR. Nevertheless, the CoMI I-D itself looks like it is not-quite-rea= dy-for-prime-time. There are many TODOs, and the YANG hash seems like it wi= ll require more prototyping before it is truly nailed down. Given that, I c= an't really recommend that direction just yet, but ideally it will be usefu= l in the future. That leaves RESTCONF. Since the industrial device manufacturers tend to be = familiar with REST already, this is an easy sell. The I-D itself seems to b= e relatively mature. Ideally, I could recommend option 3, RESTCONF with JSON. That is the cleane= st fit to what industrial devices do today. Given the limitations of section 5.3 in v04 of the I-D, I would be forced t= o recommend option 2, RESTCONF with XML. If the IoT device is forced to imp= lement XML for conformance, then the addition of JSON doesn't offer much va= lue, since the goal is automated configuration. If we could allow RESTCONF server implementation using JSON-only, that woul= d be very helpful. What's more, that sort of conformance might leave the do= or open to add CoMI as a formal RESTCONF encoding in the future. Feedback is much appreciated. Thanks. ---------------------------- Rodney Cummings Principal Software Architect, Industrial/Embedded Networks National Instruments Tel: (512) 683-8544 Fax: (512) 683-8661 Email: Rodney.Cummings@ni.com --_000_D19792CCA9AA4kwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <448C927132C0134FB9BAFA5E0ADDEDF0@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi Robert,

Please see this thread:

h= ttps://www.ietf.org/mail-archive/web/netconf/current/msg09218.html

Thanks,
Kent


From: Rodney Cummings <rodney.cummings@ni.com>
Date: Friday, June 5, 2015 at 3:39 = PM
To: "netconf@ietf.org" <netconf@ietf.org>
Subject: [Netconf] Suggestion for R= ESTCONF section 5.3

Hello,

Although I am new to the NETCONF WG an= d mailing list, I have a suggestion for the RESTCONF I-D that I'd like to d= iscuss. I realize that I may be bringing up a topic that has already been t= horoughly discussed. Nevertheless, this issue is a genuine problem for deployment of RESTCONF for my applications,= so if my suggestion is rejected, it will be helpful for me understand the = rationale.

Suggestion
--

Section 5.3 of the current I-D (https://tools.ietf.org/html/draft-ietf-ne= tconf-restconf-04) states:

"Cont= ent is encoded in either JSON or XML format.  A server MUST support XM= L encoding and MAY support JSON encoding."

My suggestion is to change section 5.3= to state:

"Cont= ent is encoded in either JSON or XML format.  A client MUST support at= least one of the specified encodings (XML or JSON), and a client SHOULD su= pport all specified encodings.  A server MUST support at least one of the specified encodings (XML or JSON), and a server MAY su= pport multiple encodings."

In other words, if a server wants to f= ocus on JSON exclusively, allow that as a conformant implementation. The cl= ient has a presumed burden to support a server that is XML-only or JSON-onl= y.

Rationale
--

As part of a roadmap for supporting in= dustrial IoT devices, the 802.1 Time-Sensitive Networking standards (TSN) a= re focusing on YANG modules for configuration of the low-level queuing beha= vior in 802.1 switches (e.g. schedule for traffic egress on each port). The assumption is that an SDN-style cont= roller will use these YANG modules to write configuration to each switch in= the network in an automated manner. Ideally, as TSN moves forward it will = be well-aligned with analogous IETF efforts, including CoRE, 6TiSCH, and DetNet (upcoming BoF in July).=

One near-term focus for the TSN effort= is to support an IoT device (e.g. industrial motor, smart grid IED) that s= upports Ethernet today, but that wants to embed an 802.1 switch. The goal i= s to expose two external ports from the device, using the switch to enable topologies like daisy-chain and rin= g. This is commonly done today using proprietary Ethernet extensions, but w= e want to transition industrial applications to 802/IETF standards (much li= ke the 6TiSCH effort for wireless). The challenge is that although this IoT device is technically a switch/rou= ter, it is very "Operational Technology" (OT). A YANG-based manag= ement protocol is required to configure the switch, but the switch supports= a subset of what a standalone managed switch/router supports, and the switch will always be configured in-band from an OT cont= roller, never from an IT-style NMS.

From the perspective of one of these I= oT device manufacturers, the primary question for management is:
        What YANG-= based management protocol do I implement in my device?
Among others, I've been tasked to help= answer this question for TSN and its related groups (e.g. AVnu.org/industr= ial). The assumption is that the manufacturer will use one and only one ser= ver implementation. Since the goal is not to support a traditional NMS, implementation of multiple servers is no= t a goal (e.g. SNMPv3 and NETCONF and RESTCONF XML and so on).

Based on this, I've been trying to cho= ose among the following implementations in order to make a recommendation:<= /font>
1. NETCONF with XML encoding 2. RESTCONF with XML encoding <= br> 3. RESTCONF with JSON encoding =
4. CoMI with CBOR encoding

For the industrial application space t= hat I am evaluating, the devices are "constrained" as CoRE descri= bes. Nevertheless, over the last few years it has become common for these d= evices to implement an HTTP web server for configuration. These web servers are often designed as RESTful. Given the constrained nat= ure of the devices, they tend to use JSON, due to the perception  that= XML parsing is less efficient.

Based on these assumptions, I tend to = exclude NETCONF. NETCONF is full-featured, but most of those features are r= elevant to NMS concerns. Also, NETCONF's basis on XML raises a perception (= if not reality) of complex implementation.

CoMI looks promising, since it is base= d on relatively mature RFCs like CoAP and CBOR. Nevertheless, the CoMI I-D = itself looks like it is not-quite-ready-for-prime-time. There are many TODO= s, and the YANG hash seems like it will require more prototyping before it is truly nailed down. Given that, I can= 't really recommend that direction just yet, but ideally it will be useful = in the future.

That leaves RESTCONF. Since the indust= rial device manufacturers tend to be familiar with REST already, this is an= easy sell. The I-D itself seems to be relatively mature.

Ideally, I could recommend option 3, R= ESTCONF with JSON. That is the cleanest fit to what industrial devices do t= oday.

Given the limitations of section 5.3 i= n v04 of the I-D, I would be forced to recommend option 2, RESTCONF with XM= L. If the IoT device is forced to implement XML for conformance, then the a= ddition of JSON doesn't offer much value, since the goal is automated configuration.

If we could allow RESTCONF server impl= ementation using JSON-only, that would be very helpful. What's more, that s= ort of conformance might leave the door open to add CoMI as a formal RESTCO= NF encoding in the future.

Feedback is much appreciated. Thanks.<= /font>

----------------------------
Rodney Cummings
Principal Software Architect, Industrial/Embedded Networks
National Instruments
Tel: (512) 683-8544
Fax: (512) 683-8661
Email: Rodney.Cummings@ni.com=
--_000_D19792CCA9AA4kwatsenjunipernet_-- From nobody Fri Jun 5 15:41:52 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81B521A916D for ; Fri, 5 Jun 2015 15:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZahcNd0Ta_C for ; Fri, 5 Jun 2015 15:41:48 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0730.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:730]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A06771A916A for ; Fri, 5 Jun 2015 15:41:47 -0700 (PDT) Received: from BN1PR05MB456.namprd05.prod.outlook.com (10.141.59.26) by BN1PR05MB252.namprd05.prod.outlook.com (10.255.206.12) with Microsoft SMTP Server (TLS) id 15.1.172.22; Fri, 5 Jun 2015 22:41:31 +0000 Received: from BN1PR05MB456.namprd05.prod.outlook.com (10.141.59.26) by BN1PR05MB456.namprd05.prod.outlook.com (10.141.59.26) with Microsoft SMTP Server (TLS) id 15.1.172.22; Fri, 5 Jun 2015 22:41:30 +0000 Received: from BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.222]) by BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.222]) with mapi id 15.01.0172.012; Fri, 5 Jun 2015 22:41:30 +0000 From: Kent Watsen To: Rodney Cummings , "netconf@ietf.org" Thread-Topic: [Netconf] Suggestion for RESTCONF section 5.3 Thread-Index: AQHQn8dYJX+wiW2ymE+qh4KUiM/xqJ2eNHUAgAAKbYA= Date: Fri, 5 Jun 2015 22:41:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: ni.com; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.11] x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB456; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB252; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520003)(3002001); SRVR:BN1PR05MB456; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB456; x-forefront-prvs: 05986C03E0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(41584004)(377454003)(164054003)(252514010)(50986999)(102836002)(54356999)(62966003)(106116001)(86362001)(4001350100001)(2900100001)(122556002)(189998001)(87936001)(19617315012)(36756003)(76176999)(15975445007)(66066001)(5001770100001)(2501003)(92566002)(19580395003)(5001960100002)(83506001)(77156002)(107886002)(5002640100001)(46102003)(16236675004)(40100003)(19580405001)(2656002)(99286002)(2950100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB456; H:BN1PR05MB456.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_D1979DC7A9B6Ekwatsenjunipernet_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jun 2015 22:41:29.8197 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB456 X-OriginatorOrg: juniper.net Archived-At: Subject: Re: [Netconf] Suggestion for RESTCONF section 5.3 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 22:41:51 -0000 --_000_D1979DC7A9B6Ekwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable s/Robert/Rodney/ - mea culpa! From: Kent Watsen > Date: Friday, June 5, 2015 at 6:04 PM To: Rodney Cummings >= , "netconf@ietf.org" > Subject: Re: [Netconf] Suggestion for RESTCONF section 5.3 Hi Robert, Please see this thread: https://www.ietf.org/mail-archive/web/netconf/current/msg09218.html Thanks, Kent From: Rodney Cummings > Date: Friday, June 5, 2015 at 3:39 PM To: "netconf@ietf.org" > Subject: [Netconf] Suggestion for RESTCONF section 5.3 Hello, Although I am new to the NETCONF WG and mailing list, I have a suggestion f= or the RESTCONF I-D that I'd like to discuss. I realize that I may be bring= ing up a topic that has already been thoroughly discussed. Nevertheless, th= is issue is a genuine problem for deployment of RESTCONF for my application= s, so if my suggestion is rejected, it will be helpful for me understand th= e rationale. Suggestion -- Section 5.3 of the current I-D (https://tools.ietf.org/html/draft-ietf-netc= onf-restconf-04) states: "Content is encoded in either JSON or XML format. A server MUST support XM= L encoding and MAY support JSON encoding." My suggestion is to change section 5.3 to state: "Content is encoded in either JSON or XML format. A client MUST support at= least one of the specified encodings (XML or JSON), and a client SHOULD su= pport all specified encodings. A server MUST support at least one of the s= pecified encodings (XML or JSON), and a server MAY support multiple encodin= gs." In other words, if a server wants to focus on JSON exclusively, allow that = as a conformant implementation. The client has a presumed burden to support= a server that is XML-only or JSON-only. Rationale -- As part of a roadmap for supporting industrial IoT devices, the 802.1 Time-= Sensitive Networking standards (TSN) are focusing on YANG modules for confi= guration of the low-level queuing behavior in 802.1 switches (e.g. schedule= for traffic egress on each port). The assumption is that an SDN-style cont= roller will use these YANG modules to write configuration to each switch in= the network in an automated manner. Ideally, as TSN moves forward it will = be well-aligned with analogous IETF efforts, including CoRE, 6TiSCH, and De= tNet (upcoming BoF in July). One near-term focus for the TSN effort is to support an IoT device (e.g. in= dustrial motor, smart grid IED) that supports Ethernet today, but that want= s to embed an 802.1 switch. The goal is to expose two external ports from t= he device, using the switch to enable topologies like daisy-chain and ring.= This is commonly done today using proprietary Ethernet extensions, but we = want to transition industrial applications to 802/IETF standards (much like= the 6TiSCH effort for wireless). The challenge is that although this IoT d= evice is technically a switch/router, it is very "Operational Technology" (= OT). A YANG-based management protocol is required to configure the switch, = but the switch supports a subset of what a standalone managed switch/router= supports, and the switch will always be configured in-band from an OT cont= roller, never from an IT-style NMS. >From the perspective of one of these IoT device manufacturers, the primary = question for management is: What YANG-based management protocol do I implement in my device? Among others, I've been tasked to help answer this question for TSN and its= related groups (e.g. AVnu.org/industrial). The assumption is that the manu= facturer will use one and only one server implementation. Since the goal is= not to support a traditional NMS, implementation of multiple servers is no= t a goal (e.g. SNMPv3 and NETCONF and RESTCONF XML and so on). Based on this, I've been trying to choose among the following implementatio= ns in order to make a recommendation: 1. NETCONF with XML encoding 2. RESTCONF with XML encoding 3. RESTCONF with JSON encoding 4. CoMI with CBOR encoding For the industrial application space that I am evaluating, the devices are = "constrained" as CoRE describes. Nevertheless, over the last few years it h= as become common for these devices to implement an HTTP web server for conf= iguration. These web servers are often designed as RESTful. Given the const= rained nature of the devices, they tend to use JSON, due to the perception = that XML parsing is less efficient. Based on these assumptions, I tend to exclude NETCONF. NETCONF is full-feat= ured, but most of those features are relevant to NMS concerns. Also, NETCON= F's basis on XML raises a perception (if not reality) of complex implementa= tion. CoMI looks promising, since it is based on relatively mature RFCs like CoAP= and CBOR. Nevertheless, the CoMI I-D itself looks like it is not-quite-rea= dy-for-prime-time. There are many TODOs, and the YANG hash seems like it wi= ll require more prototyping before it is truly nailed down. Given that, I c= an't really recommend that direction just yet, but ideally it will be usefu= l in the future. That leaves RESTCONF. Since the industrial device manufacturers tend to be = familiar with REST already, this is an easy sell. The I-D itself seems to b= e relatively mature. Ideally, I could recommend option 3, RESTCONF with JSON. That is the cleane= st fit to what industrial devices do today. Given the limitations of section 5.3 in v04 of the I-D, I would be forced t= o recommend option 2, RESTCONF with XML. If the IoT device is forced to imp= lement XML for conformance, then the addition of JSON doesn't offer much va= lue, since the goal is automated configuration. If we could allow RESTCONF server implementation using JSON-only, that woul= d be very helpful. What's more, that sort of conformance might leave the do= or open to add CoMI as a formal RESTCONF encoding in the future. Feedback is much appreciated. Thanks. ---------------------------- Rodney Cummings Principal Software Architect, Industrial/Embedded Networks National Instruments Tel: (512) 683-8544 Fax: (512) 683-8661 Email: Rodney.Cummings@ni.com --_000_D1979DC7A9B6Ekwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <096F057364636444BAE112E4F245BDED@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

s/Robert/Rodney/  - mea culpa!


From: Kent Watsen <kwatsen@juniper.net>
Date: Friday, June 5, 2015 at 6:04 = PM
To: Rodney Cummings <rodney.cummings@ni.com>, "netconf@ietf.org" <netconf@ietf.org>
Subject: Re: [Netconf] Suggestion f= or RESTCONF section 5.3

Hi Robert,

Please see this thread:

h= ttps://www.ietf.org/mail-archive/web/netconf/current/msg09218.html

Thanks,
Kent


From: Rodney Cummings <rodney.cummings@ni.com>
Date: Friday, June 5, 2015 at 3:39 = PM
To: "netconf@ietf.org" <netconf@ietf.org>
Subject: [Netconf] Suggestion for R= ESTCONF section 5.3

Hello,

Although I am new to the NETCONF WG an= d mailing list, I have a suggestion for the RESTCONF I-D that I'd like to d= iscuss. I realize that I may be bringing up a topic that has already been t= horoughly discussed. Nevertheless, this issue is a genuine problem for deployment of RESTCONF for my applications,= so if my suggestion is rejected, it will be helpful for me understand the = rationale.

Suggestion
--

Section 5.3 of the current I-D (https://tools.ietf.org/html/draft-ietf-ne= tconf-restconf-04) states:

"Cont= ent is encoded in either JSON or XML format.  A server MUST support XM= L encoding and MAY support JSON encoding."

My suggestion is to change section 5.3= to state:

"Cont= ent is encoded in either JSON or XML format.  A client MUST support at= least one of the specified encodings (XML or JSON), and a client SHOULD su= pport all specified encodings.  A server MUST support at least one of the specified encodings (XML or JSON), and a server MAY su= pport multiple encodings."

In other words, if a server wants to f= ocus on JSON exclusively, allow that as a conformant implementation. The cl= ient has a presumed burden to support a server that is XML-only or JSON-onl= y.

Rationale
--

As part of a roadmap for supporting in= dustrial IoT devices, the 802.1 Time-Sensitive Networking standards (TSN) a= re focusing on YANG modules for configuration of the low-level queuing beha= vior in 802.1 switches (e.g. schedule for traffic egress on each port). The assumption is that an SDN-style cont= roller will use these YANG modules to write configuration to each switch in= the network in an automated manner. Ideally, as TSN moves forward it will = be well-aligned with analogous IETF efforts, including CoRE, 6TiSCH, and DetNet (upcoming BoF in July).=

One near-term focus for the TSN effort= is to support an IoT device (e.g. industrial motor, smart grid IED) that s= upports Ethernet today, but that wants to embed an 802.1 switch. The goal i= s to expose two external ports from the device, using the switch to enable topologies like daisy-chain and rin= g. This is commonly done today using proprietary Ethernet extensions, but w= e want to transition industrial applications to 802/IETF standards (much li= ke the 6TiSCH effort for wireless). The challenge is that although this IoT device is technically a switch/rou= ter, it is very "Operational Technology" (OT). A YANG-based manag= ement protocol is required to configure the switch, but the switch supports= a subset of what a standalone managed switch/router supports, and the switch will always be configured in-band from an OT cont= roller, never from an IT-style NMS.

From the perspective of one of these I= oT device manufacturers, the primary question for management is:
        What YANG-= based management protocol do I implement in my device?
Among others, I've been tasked to help= answer this question for TSN and its related groups (e.g. AVnu.org/industr= ial). The assumption is that the manufacturer will use one and only one ser= ver implementation. Since the goal is not to support a traditional NMS, implementation of multiple servers is no= t a goal (e.g. SNMPv3 and NETCONF and RESTCONF XML and so on).

Based on this, I've been trying to cho= ose among the following implementations in order to make a recommendation:<= /font>
1. NETCONF with XML encoding 2. RESTCONF with XML encoding <= br> 3. RESTCONF with JSON encoding =
4. CoMI with CBOR encoding

For the industrial application space t= hat I am evaluating, the devices are "constrained" as CoRE descri= bes. Nevertheless, over the last few years it has become common for these d= evices to implement an HTTP web server for configuration. These web servers are often designed as RESTful. Given the constrained nat= ure of the devices, they tend to use JSON, due to the perception  that= XML parsing is less efficient.

Based on these assumptions, I tend to = exclude NETCONF. NETCONF is full-featured, but most of those features are r= elevant to NMS concerns. Also, NETCONF's basis on XML raises a perception (= if not reality) of complex implementation.

CoMI looks promising, since it is base= d on relatively mature RFCs like CoAP and CBOR. Nevertheless, the CoMI I-D = itself looks like it is not-quite-ready-for-prime-time. There are many TODO= s, and the YANG hash seems like it will require more prototyping before it is truly nailed down. Given that, I can= 't really recommend that direction just yet, but ideally it will be useful = in the future.

That leaves RESTCONF. Since the indust= rial device manufacturers tend to be familiar with REST already, this is an= easy sell. The I-D itself seems to be relatively mature.

Ideally, I could recommend option 3, R= ESTCONF with JSON. That is the cleanest fit to what industrial devices do t= oday.

Given the limitations of section 5.3 i= n v04 of the I-D, I would be forced to recommend option 2, RESTCONF with XM= L. If the IoT device is forced to implement XML for conformance, then the a= ddition of JSON doesn't offer much value, since the goal is automated configuration.

If we could allow RESTCONF server impl= ementation using JSON-only, that would be very helpful. What's more, that s= ort of conformance might leave the door open to add CoMI as a formal RESTCO= NF encoding in the future.

Feedback is much appreciated. Thanks.<= /font>

----------------------------
Rodney Cummings
Principal Software Architect, Industrial/Embedded Networks
National Instruments
Tel: (512) 683-8544
Fax: (512) 683-8661
Email: Rodney.Cummings@ni.com=
--_000_D1979DC7A9B6Ekwatsenjunipernet_-- From nobody Sun Jun 7 09:04:45 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD8E1A92B1 for ; Sun, 7 Jun 2015 09:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.721 X-Spam-Level: X-Spam-Status: No, score=0.721 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecU250n9Jzer for ; Sun, 7 Jun 2015 09:04:43 -0700 (PDT) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DA511A92AF for ; Sun, 7 Jun 2015 09:04:43 -0700 (PDT) Received: by lbbtu8 with SMTP id tu8so51769016lbb.2 for ; Sun, 07 Jun 2015 09:04:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=LPOs7+ZLexXRFWmec6invdYYjARRgbw8Ebljyw9/jX0=; b=Kv7yPUv0RmTMCUer7hbaI0O04Y6Ne+5ThmxvCaRvGZx8kypuIsqnwP+3cd1s8PqKC2 BIg2hC/cfEmrvQLJ0dEQUB+/3beemUQgEe3h3y/OjK6ywwNnb/1cTIe+QmkU1rKE2Sf0 m9ntjIIZFUhd9Bl63WJqmfdyHUe+aG2+c91l2Vzg1QiupvE6o2amHR5U7CEJifLqhHB+ gBGasE7oSBJnrrukSBtDIjL8UP7OJQkQ/I2dwr03/eKbdgTcit5vTxx+ZaXbrCOW+lRY azZoyhcDEeulm4a3w2u5zRAPXZnG82TotJtEnAupt8xD0B9OpQON8DVnpom70+LTEIJj 9GFA== X-Gm-Message-State: ALoCoQmgbNAhkJHpRNmistO8s0d6bf0ZKD/ZefTEnxO2A3qA3kekC7FYUAJww9z0YvLKl6YJM1PM MIME-Version: 1.0 X-Received: by 10.152.36.161 with SMTP id r1mr12505722laj.88.1433693081487; Sun, 07 Jun 2015 09:04:41 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Sun, 7 Jun 2015 09:04:41 -0700 (PDT) In-Reply-To: References: <20150601072552.GA31467@elstar.local> <20150601095456.GD31801@elstar.local> <20150602064743.GA66363@elstar.local> Date: Sun, 7 Jun 2015 09:04:41 -0700 Message-ID: From: Andy Bierman To: Mandy Liu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Robert Ottinger , "andy@netconfcentral.org" , Athanasios Kyparlis , Kai Lin , "netconf@ietf.org" Subject: Re: [Netconf] How to augment RFC6470 to supply detail configuration change information X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2015 16:04:45 -0000 Hi, There are (at least) 2 technical issues you should consider, in case you ar= e wondering why the 'data' was left out of the netconf-config-change event. 1) Access control is effectively disabled by copying config nodes into an 'anyxml' container within a notification. Sensitive data like passwords can be transferred to a client without read privilege for that data. 2) NETCONF notifications may not be reliable. Replay is optional to implement. RFC 5277 is silent about transport requirements for notification delivery. For example if the receiver is blocked so that notifications cannot be sent on a subscription session, a server with finite resources will eventually be unable to store new events. There is one mention of resources in the RFC, wrt/ replay: The actual number of stored notifications available for retrieval at any given time is a NETCONF server implementation-specific matter. Control parameters for this aspect of the feature are outside the scope of this document. Note that notifications can not be retrieved in NETCONF. This text should say "available for delivery". Notifications do not have sequence identifiers. There is no way for a client to tell if a notification was dropped by the server. Andy On Tue, Jun 2, 2015 at 12:18 AM, Mandy Liu wrote: > I am not intent to insist that. I just want to make sure it won't violate= RFC6020. I think you have convinced me by below sentence. Thanks for your = support, Juergen! > - "But it is not the writable configuration data but more a copy of the c= onfiguration data that got changed." > > Regards, > Mandy > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Tuesday, June 02, 2015 2:48 PM > To: Mandy Liu > Cc: andy@netconfcentral.org; Kai Lin; Robert Ottinger; netconf@ietf.org; = Athanasios Kyparlis > Subject: Re: [Netconf] How to augment RFC6470 to supply detail configurat= ion change information > > But it is not the writable configuration data but more a copy of the conf= iguration data that got changed. Anyway, if you want to insist that this is= a violation of section 7.10 of RFC6020, then don't do it. I do not believe= it is a violation of section 7.10 of RFC6020. > > /js > > On Tue, Jun 02, 2015 at 06:22:25AM +0000, Mandy Liu wrote: >> Ok, thanks! Got your point. >> But here I want to use "data" to address the changed configuration data = in the notification. Although "data" is in the notification, but because it= is used to address the configuration data seems it still conflicts with th= e statement in section 7.10 of RFC6020 "it is RECOMMENDED that the "anyxml"= statement not be used to represent configuration data. " >> >> list edit { >> leaf target { >> type instance-identifier; >> description >> ..... >> } >> leaf operation { >> type nc:edit-operation-type; >> description >> ..... >> } >> anyxml data; >> } >> >> Regards, >> Mandy >> >> -----Original Message----- >> From: Juergen Schoenwaelder >> [mailto:j.schoenwaelder@jacobs-university.de] >> Sent: Monday, June 01, 2015 5:55 PM >> To: Mandy Liu >> Cc: andy@netconfcentral.org; Kai Lin; Robert Ottinger; >> netconf@ietf.org; Athanasios Kyparlis >> Subject: Re: [Netconf] How to augment RFC6470 to supply detail >> configuration change information >> >> Let me try to say it differently: Using anyxml in a notification does no= t cause a conflict with this statement in section 7.10 of RFC 6020: >> >> Since the use of anyxml limits the manipulation of the content, it is >> RECOMMENDED that the "anyxml" statement not be used to represent >> configuration data. >> >> Note that configuration data is defined as follows: >> >> o configuration data: The set of writable data that is required to >> transform a system from its initial default state into its current >> state [RFC4741]. >> >> Notification content is not configuration data. >> >> /js >> >> On Mon, Jun 01, 2015 at 07:48:51AM +0000, Mandy Liu wrote: >> > Sorry, I don't get your point. But hopefully I addressed my question m= ore clearly this time. >> > >> > The configuration change notification is generated when the NETCONF se= rver detects that the or configuration datastore has be= en changed by a management session. The notification summarizes the "edits"= that have been detected. " The structure of the "edit" is addressed in RF= C6470 as below. What I want is to add the another leaf to address the "targ= et" is changed to what. But because the "target" may be a container, a list= , a leaf or a leaf-reference, etc. It could be any node of the tree. So a c= ommon format for addressing the "target" is changed to what is needed. >> > list edit { >> > leaf target { >> > type instance-identifier; >> > description >> > ..... >> > } >> > leaf operation { >> > type nc:edit-operation-type; >> > description >> > ..... >> > } >> > } >> > >> > Thanks, >> > Mandy >> > -----Original Message----- >> > From: Juergen Schoenwaelder >> > [mailto:j.schoenwaelder@jacobs-university.de] >> > Sent: Monday, June 01, 2015 3:26 PM >> > To: Mandy Liu >> > Cc: andy@netconfcentral.org; Kai Lin; Robert Ottinger; >> > netconf@ietf.org; Athanasios Kyparlis >> > Subject: Re: [Netconf] How to augment RFC6470 to supply detail >> > configuration change information >> > >> > On Mon, Jun 01, 2015 at 06:51:27AM +0000, Mandy Liu wrote: >> > >> > > [...] So we need to find a common format for the "content" to >> > > accommodate different types of "target". what I can imagine is >> > > anyxml could be used. But seems it is not a good choice. Because >> > > based on RFC6020, it is not recommended to be used on configuration = data. >> > >> > Since you plan to augment a notification, this won't be config true da= ta (this is what the statement in RFC 6020 really hints at). See also the d= efinition of 'configuration data' in section 3 of RFC 6020. >> > >> > /js >> > >> > -- >> > Juergen Schoenwaelder Jacobs University Bremen gGmbH >> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> > Fax: +49 421 200 3103 >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> Fax: +49 421 200 3103 > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Sun Jun 7 11:33:09 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B66FA1A8AE4 for ; Sun, 7 Jun 2015 11:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6w4U8SVa-ss for ; Sun, 7 Jun 2015 11:33:06 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0727.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::727]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DEA81A8AE2 for ; Sun, 7 Jun 2015 11:33:05 -0700 (PDT) Received: from BN1PR05MB456.namprd05.prod.outlook.com (10.141.59.26) by BN1PR05MB454.namprd05.prod.outlook.com (10.141.59.17) with Microsoft SMTP Server (TLS) id 15.1.172.22; Sun, 7 Jun 2015 18:32:44 +0000 Received: from BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.222]) by BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.222]) with mapi id 15.01.0172.012; Sun, 7 Jun 2015 18:32:44 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] server-model #49: combine trusted-ca-certs and trusted-client-certs for ssh/tls? Thread-Index: AQHQkbgnBncK8ydKj0azKXFdHxn5752Zo96AgAeWTgA= Date: Sun, 7 Jun 2015 18:32:43 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.12] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB454; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:BN1PR05MB454; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB454; x-forefront-prvs: 0600F93FE1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(2501003)(92566002)(2900100001)(2950100001)(110136002)(107886002)(5001960100002)(189998001)(4001350100001)(15975445007)(77156002)(450100001)(102836002)(62966003)(86362001)(83506001)(2656002)(87936001)(50986999)(76176999)(54356999)(40100003)(66066001)(122556002)(230783001)(5002640100001)(46102003)(99286002)(2351001)(19580395003)(36756003)(106116001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB454; H:BN1PR05MB456.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jun 2015 18:32:43.9176 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB454 Archived-At: Subject: Re: [Netconf] server-model #49: combine trusted-ca-certs and trusted-client-certs for ssh/tls? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2015 18:33:08 -0000 This issue is the only issue currently blocking the server-model draft. For convenience, the email exchange with Juergen mentioned before is here: https://www.ietf.org/mail-archive/web/netconf/current/msg10156.html. As a thought exercise, assume that it is inevitable that a keychain model will exist some day, and that a future revision of this draft wants to use It (are these valid assumptions?). If so, how would this draft be updated to make use of the new keychain model? OPTION 1: use union to mix-in leafref // allowed in YANG 1.1 Examples: import ietf-keychain { // some future keychain module prefix kc; } container trusted-ca-certs { leaf-list trusted-ca-cert { type union { type string; // from original draft type leafref { // added in revision path "/kc:server-certificates/kc:server-certificate/kc:name"; } } } } container server-certificates { leaf-list server-certificate { type union { type binary; // from original draft type leafref { // added in revision path "/kc:trust-anchors/kc:trust-anchor/kc:name"; } } } } PROs: backwards-compatible, no feature statements CONs: 1) for trusted-ca-cert, how would a server differentiate the "string" and "leafref" types? Does it matter? 2) for server-certificate, would server implement "binary" as a pass-thru to the underlying keychain? If so, then would server maintain metadata to track how the leaf was configured so that it can present it the same way when returning config to clients? Would we use an attribute so that if the client sends the config back to the server, the server's metadata wouldn't change? OPTION 2: use if-feature statement to mix-in leafref import ietf-keychain { // some future keychain module prefix kc; } container trusted-ca-certs { leaf-list trusted-ca-cert { // from original draft type string; } leaf-list trusted-ca-cert-ref { // added in revision if-feature keychain; type leafref { path "/kc:server-certificates/kc:server-certificate/kc:name"; } } } container server-certificates { leaf-list server-certificate { // from original draft type binary; } leaf-list server-certificate-ref { // added in revision if-feature keychain; type leafref { path "/kc:trust-anchors/kc:trust-anchor/kc:name"; } } } PROs: still backwards-compatible CONs: not a nice data model (imagine it as CLI) OPTION 3: like Option 2, but use a "choice" statement instead PROs: backwards-compatible CONs: not a nice data model, no ability for server to opt-in to implementing the keychain module OPTION 4: replace *now* the binary type with a string type and dispense altogether using a union later. Now: container trusted-ca-certs { leaf-list trusted-ca-cert { type string; description "key to some list of certs"; } } container server-certificates { leaf-list server-certificate { type string; description "key to some list of certs"; } } Later: container trusted-ca-certs { leaf-list trusted-ca-cert { if-feature keychain; type leafref { path "/kc:server-certificates/kc:server-certificate/kc:name"; } } } container server-certificates { leaf-list server-certificate { if-feature keychain; type leafref { path "/kc:trust-anchors/kc:trust-anchor/kc:name"; } } } PROs: No change in model structure CONs: backwards-compatible? I rationalize that OPTION #4 is backwards compatible in that the value is still a string on the wire and that the server is still enforcing the rules it must've been enforcing before. Thus, no change in syntax or semantics. Any other options? Are any options acceptable? Thanks, Kent From nobody Sun Jun 7 18:21:17 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 078841A1B43 for ; Sun, 7 Jun 2015 18:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRUyvCU_04KR for ; Sun, 7 Jun 2015 18:21:14 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D27AB1A1B3E for ; Sun, 7 Jun 2015 18:21:13 -0700 (PDT) X-AuditID: c1b4fb30-f799f6d000000faf-f0-5574ee06f635 Received: from ESGSCHC005.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id E0.6B.04015.70EE4755; Mon, 8 Jun 2015 03:21:12 +0200 (CEST) Received: from ESGSCMB103.ericsson.se ([169.254.3.225]) by ESGSCHC005.ericsson.se ([146.11.116.80]) with mapi id 14.03.0210.002; Mon, 8 Jun 2015 09:21:09 +0800 From: Mandy Liu To: Andy Bierman Thread-Topic: [Netconf] How to augment RFC6470 to supply detail configuration change information Thread-Index: AdCcN15yUJGf8sjGSmOLzB5x9r0Sx///g4mA//92nwCAALMFAP/+KJHQgAM1dwD//3KAIAEgmJCA//7fOqA= Date: Mon, 8 Jun 2015 01:21:09 +0000 Message-ID: References: <20150601072552.GA31467@elstar.local> <20150601095456.GD31801@elstar.local> <20150602064743.GA66363@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [146.11.116.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZGfG3VpfjXUmowc1+dotneyaxWDw4Movd 4urGn4wWUzfdZnVg8Viy5CeTx4YDnh4f725m8Wjpv8gSwBLFZZOSmpNZllqkb5fAlXFq0QPW gkf+FX9m97I3MN7x7WLk5JAQMJG4cvQrE4QtJnHh3nq2LkYuDiGBo4wSRzbPYYVwFjNKfF3x mgWkik1AQ+Lxq0nsILaIgKrEhbkTmUGKmAUamCUufdoENkpYIFFi9qm1jBBFSRKf9jxkgrE3 zf3PBmKzCKhIvJm4GGwQr4CvxOs79xkhtt1glji6azJYEadAoMTP731gRYxA930/tQZsELOA uMStJ/Oh7haQWLLnPDOELSrx8vE/VghbQWL6hntAQzmA6jUl1u/Sh2hVlJjS/RBqr6DEyZlP WCYwis1CMnUWQscsJB2zkHQsYGRZxShanFqclJtuZKSXWpSZXFycn6eXl1qyiREYZwe3/DbY wfjyueMhRgEORiUe3gf7SkKFWBPLiitzDzFKc7AoifPO2JwXKiSQnliSmp2aWpBaFF9UmpNa fIiRiYNTqoGx6KCzb/7peyZPbXo28WxQ2yT6Q/pDSrrP5/1L1+/ecU7iVLfmDbOnmWXfTpmy 77wluHBji2T+Wf6Eoq9Piusro3MPtsizOpXbal2cryKk6vVBJW7+/YBMHbU/glu9GKa/+TJd WqCc4YFBidrBw9HbYt0Luld/eht4Yd/MJfummT+NMP91ZaWyEktxRqKhFnNRcSIAKnECmZQC AAA= Archived-At: Cc: Robert Ottinger , "andy@netconfcentral.org" , Roy Finlay , Athanasios Kyparlis , Kai Lin , Victor Santos , "netconf@ietf.org" Subject: Re: [Netconf] How to augment RFC6470 to supply detail configuration change information X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 01:21:17 -0000 VGhhbmtzIGZvciB5b3VyIGltcG9ydGFudCBpbmZvcm1hdGlvbiwgQW5keSENCisgUm95IGFuZCBW aWN0b3IuDQoNCkhpIFJveSBhbmQgVmljdG9yLA0KDQpBbmR5IHNoYXJlZCBzb21lIGltcG9ydGFu dCBpbmZvcm1hdGlvbiBhYm91dCAiIHdoeSB0aGUgJ2RhdGEnIHdhcyBsZWZ0IG91dCBvZiB0aGUg bmV0Y29uZi1jb25maWctY2hhbmdlIGV2ZW50IiB3aXRoIHVzLiBGWUkuDQoNClJlZ2FyZHMsDQpN YW5keQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQW5keSBCaWVybWFuIFtt YWlsdG86YW5keUB5dW1hd29ya3MuY29tXSANClNlbnQ6IE1vbmRheSwgSnVuZSAwOCwgMjAxNSAx MjowNSBBTQ0KVG86IE1hbmR5IExpdQ0KQ2M6IEp1ZXJnZW4gU2Nob2Vud2FlbGRlcjsgYW5keUBu ZXRjb25mY2VudHJhbC5vcmc7IEthaSBMaW47IFJvYmVydCBPdHRpbmdlcjsgbmV0Y29uZkBpZXRm Lm9yZzsgQXRoYW5hc2lvcyBLeXBhcmxpcw0KU3ViamVjdDogUmU6IFtOZXRjb25mXSBIb3cgdG8g YXVnbWVudCBSRkM2NDcwIHRvIHN1cHBseSBkZXRhaWwgY29uZmlndXJhdGlvbiBjaGFuZ2UgaW5m b3JtYXRpb24NCg0KSGksDQoNClRoZXJlIGFyZSAoYXQgbGVhc3QpIDIgdGVjaG5pY2FsIGlzc3Vl cyB5b3Ugc2hvdWxkIGNvbnNpZGVyLCBpbiBjYXNlIHlvdSBhcmUgd29uZGVyaW5nIHdoeSB0aGUg J2RhdGEnIHdhcyBsZWZ0IG91dCBvZiB0aGUgbmV0Y29uZi1jb25maWctY2hhbmdlIGV2ZW50Lg0K DQoxKSBBY2Nlc3MgY29udHJvbCBpcyBlZmZlY3RpdmVseSBkaXNhYmxlZCBieSBjb3B5aW5nIGNv bmZpZyBub2RlcyBpbnRvIGFuICdhbnl4bWwnIGNvbnRhaW5lciB3aXRoaW4gYSBub3RpZmljYXRp b24uICBTZW5zaXRpdmUgZGF0YSBsaWtlIHBhc3N3b3JkcyBjYW4gYmUgdHJhbnNmZXJyZWQgdG8g YSBjbGllbnQgd2l0aG91dCByZWFkIHByaXZpbGVnZSBmb3IgdGhhdCBkYXRhLg0KDQoyKSBORVRD T05GIG5vdGlmaWNhdGlvbnMgbWF5IG5vdCBiZSByZWxpYWJsZS4NClJlcGxheSBpcyBvcHRpb25h bCB0byBpbXBsZW1lbnQuICBSRkMgNTI3NyBpcyBzaWxlbnQgYWJvdXQgdHJhbnNwb3J0IHJlcXVp cmVtZW50cyBmb3Igbm90aWZpY2F0aW9uIGRlbGl2ZXJ5Lg0KDQpGb3IgZXhhbXBsZSBpZiB0aGUg cmVjZWl2ZXIgaXMgYmxvY2tlZCBzbyB0aGF0IG5vdGlmaWNhdGlvbnMgY2Fubm90IGJlIHNlbnQg b24gYSBzdWJzY3JpcHRpb24gc2Vzc2lvbiwgYSBzZXJ2ZXIgd2l0aCBmaW5pdGUgcmVzb3VyY2Vz IHdpbGwgZXZlbnR1YWxseSBiZSB1bmFibGUgdG8gc3RvcmUgbmV3IGV2ZW50cy4NCg0KVGhlcmUg aXMgb25lIG1lbnRpb24gb2YgcmVzb3VyY2VzIGluIHRoZSBSRkMsIHdydC8gcmVwbGF5Og0KDQog ICBUaGUgYWN0dWFsIG51bWJlciBvZiBzdG9yZWQgbm90aWZpY2F0aW9ucyBhdmFpbGFibGUgZm9y IHJldHJpZXZhbCBhdA0KICAgYW55IGdpdmVuIHRpbWUgaXMgYSBORVRDT05GIHNlcnZlciBpbXBs ZW1lbnRhdGlvbi1zcGVjaWZpYyBtYXR0ZXIuDQogICBDb250cm9sIHBhcmFtZXRlcnMgZm9yIHRo aXMgYXNwZWN0IG9mIHRoZSBmZWF0dXJlIGFyZSBvdXRzaWRlIHRoZQ0KICAgc2NvcGUgb2YgdGhp cyBkb2N1bWVudC4NCg0KTm90ZSB0aGF0IG5vdGlmaWNhdGlvbnMgY2FuIG5vdCBiZSByZXRyaWV2 ZWQgaW4gTkVUQ09ORi4NClRoaXMgdGV4dCBzaG91bGQgc2F5ICJhdmFpbGFibGUgZm9yIGRlbGl2 ZXJ5Ii4NCg0KTm90aWZpY2F0aW9ucyBkbyBub3QgaGF2ZSBzZXF1ZW5jZSBpZGVudGlmaWVycy4N ClRoZXJlIGlzIG5vIHdheSBmb3IgYSBjbGllbnQgdG8gdGVsbCBpZiBhIG5vdGlmaWNhdGlvbiB3 YXMgZHJvcHBlZCBieSB0aGUgc2VydmVyLg0KDQoNCkFuZHkNCg0KDQpPbiBUdWUsIEp1biAyLCAy MDE1IGF0IDEyOjE4IEFNLCBNYW5keSBMaXUgPG1hbmR5LmxpdUBlcmljc3Nvbi5jb20+IHdyb3Rl Og0KPiBJIGFtIG5vdCBpbnRlbnQgdG8gaW5zaXN0IHRoYXQuIEkganVzdCB3YW50IHRvIG1ha2Ug c3VyZSBpdCB3b24ndCB2aW9sYXRlIFJGQzYwMjAuIEkgdGhpbmsgeW91IGhhdmUgY29udmluY2Vk IG1lIGJ5IGJlbG93IHNlbnRlbmNlLiBUaGFua3MgZm9yIHlvdXIgc3VwcG9ydCwgSnVlcmdlbiEN Cj4gLSAiQnV0IGl0IGlzIG5vdCB0aGUgd3JpdGFibGUgY29uZmlndXJhdGlvbiBkYXRhIGJ1dCBt b3JlIGEgY29weSBvZiB0aGUgY29uZmlndXJhdGlvbiBkYXRhIHRoYXQgZ290IGNoYW5nZWQuIg0K Pg0KPiBSZWdhcmRzLA0KPiBNYW5keQ0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiBGcm9tOiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgDQo+IFttYWlsdG86ai5zY2hvZW53YWVsZGVy QGphY29icy11bml2ZXJzaXR5LmRlXQ0KPiBTZW50OiBUdWVzZGF5LCBKdW5lIDAyLCAyMDE1IDI6 NDggUE0NCj4gVG86IE1hbmR5IExpdQ0KPiBDYzogYW5keUBuZXRjb25mY2VudHJhbC5vcmc7IEth aSBMaW47IFJvYmVydCBPdHRpbmdlcjsgDQo+IG5ldGNvbmZAaWV0Zi5vcmc7IEF0aGFuYXNpb3Mg S3lwYXJsaXMNCj4gU3ViamVjdDogUmU6IFtOZXRjb25mXSBIb3cgdG8gYXVnbWVudCBSRkM2NDcw IHRvIHN1cHBseSBkZXRhaWwgDQo+IGNvbmZpZ3VyYXRpb24gY2hhbmdlIGluZm9ybWF0aW9uDQo+ DQo+IEJ1dCBpdCBpcyBub3QgdGhlIHdyaXRhYmxlIGNvbmZpZ3VyYXRpb24gZGF0YSBidXQgbW9y ZSBhIGNvcHkgb2YgdGhlIGNvbmZpZ3VyYXRpb24gZGF0YSB0aGF0IGdvdCBjaGFuZ2VkLiBBbnl3 YXksIGlmIHlvdSB3YW50IHRvIGluc2lzdCB0aGF0IHRoaXMgaXMgYSB2aW9sYXRpb24gb2Ygc2Vj dGlvbiA3LjEwIG9mIFJGQzYwMjAsIHRoZW4gZG9uJ3QgZG8gaXQuIEkgZG8gbm90IGJlbGlldmUg aXQgaXMgYSB2aW9sYXRpb24gb2Ygc2VjdGlvbiA3LjEwIG9mIFJGQzYwMjAuDQo+DQo+IC9qcw0K Pg0KPiBPbiBUdWUsIEp1biAwMiwgMjAxNSBhdCAwNjoyMjoyNUFNICswMDAwLCBNYW5keSBMaXUg d3JvdGU6DQo+PiBPaywgdGhhbmtzISBHb3QgeW91ciBwb2ludC4NCj4+IEJ1dCBoZXJlIEkgd2Fu dCB0byB1c2UgImRhdGEiIHRvIGFkZHJlc3MgdGhlIGNoYW5nZWQgY29uZmlndXJhdGlvbiBkYXRh IGluIHRoZSBub3RpZmljYXRpb24uIEFsdGhvdWdoICJkYXRhIiBpcyBpbiB0aGUgbm90aWZpY2F0 aW9uLCBidXQgYmVjYXVzZSBpdCBpcyB1c2VkIHRvIGFkZHJlc3MgdGhlIGNvbmZpZ3VyYXRpb24g ZGF0YSBzZWVtcyBpdCBzdGlsbCBjb25mbGljdHMgd2l0aCB0aGUgc3RhdGVtZW50IGluIHNlY3Rp b24gNy4xMCBvZiBSRkM2MDIwICJpdCBpcyBSRUNPTU1FTkRFRCB0aGF0IHRoZSAiYW55eG1sIiBz dGF0ZW1lbnQgbm90IGJlIHVzZWQgdG8gcmVwcmVzZW50IGNvbmZpZ3VyYXRpb24gZGF0YS4gIg0K Pj4NCj4+IGxpc3QgZWRpdCB7DQo+PiAgICAgIGxlYWYgdGFyZ2V0IHsNCj4+ICAgICAgICAgIHR5 cGUgaW5zdGFuY2UtaWRlbnRpZmllcjsNCj4+ICAgICAgICAgZGVzY3JpcHRpb24NCj4+ICAgICAg ICAgLi4uLi4NCj4+ICAgICAgfQ0KPj4gICAgICBsZWFmIG9wZXJhdGlvbiB7DQo+PiAgICAgICAg ICB0eXBlIG5jOmVkaXQtb3BlcmF0aW9uLXR5cGU7DQo+PiAgICAgICAgIGRlc2NyaXB0aW9uDQo+ PiAgICAgICAgICAgICAgLi4uLi4NCj4+ICAgICAgfQ0KPj4gICAgICBhbnl4bWwgZGF0YTsNCj4+ ICB9DQo+Pg0KPj4gUmVnYXJkcywNCj4+IE1hbmR5DQo+Pg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4+IEZyb206IEp1ZXJnZW4gU2Nob2Vud2FlbGRlcg0KPj4gW21haWx0bzpqLnNj aG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGVdDQo+PiBTZW50OiBNb25kYXksIEp1bmUg MDEsIDIwMTUgNTo1NSBQTQ0KPj4gVG86IE1hbmR5IExpdQ0KPj4gQ2M6IGFuZHlAbmV0Y29uZmNl bnRyYWwub3JnOyBLYWkgTGluOyBSb2JlcnQgT3R0aW5nZXI7IA0KPj4gbmV0Y29uZkBpZXRmLm9y ZzsgQXRoYW5hc2lvcyBLeXBhcmxpcw0KPj4gU3ViamVjdDogUmU6IFtOZXRjb25mXSBIb3cgdG8g YXVnbWVudCBSRkM2NDcwIHRvIHN1cHBseSBkZXRhaWwgDQo+PiBjb25maWd1cmF0aW9uIGNoYW5n ZSBpbmZvcm1hdGlvbg0KPj4NCj4+IExldCBtZSB0cnkgdG8gc2F5IGl0IGRpZmZlcmVudGx5OiBV c2luZyBhbnl4bWwgaW4gYSBub3RpZmljYXRpb24gZG9lcyBub3QgY2F1c2UgYSBjb25mbGljdCB3 aXRoIHRoaXMgc3RhdGVtZW50IGluIHNlY3Rpb24gNy4xMCBvZiBSRkMgNjAyMDoNCj4+DQo+PiAg ICBTaW5jZSB0aGUgdXNlIG9mIGFueXhtbCBsaW1pdHMgdGhlIG1hbmlwdWxhdGlvbiBvZiB0aGUg Y29udGVudCwgaXQgaXMNCj4+ICAgIFJFQ09NTUVOREVEIHRoYXQgdGhlICJhbnl4bWwiIHN0YXRl bWVudCBub3QgYmUgdXNlZCB0byByZXByZXNlbnQNCj4+ICAgIGNvbmZpZ3VyYXRpb24gZGF0YS4N Cj4+DQo+PiBOb3RlIHRoYXQgY29uZmlndXJhdGlvbiBkYXRhIGlzIGRlZmluZWQgYXMgZm9sbG93 czoNCj4+DQo+PiAgICBvICBjb25maWd1cmF0aW9uIGRhdGE6IFRoZSBzZXQgb2Ygd3JpdGFibGUg ZGF0YSB0aGF0IGlzIHJlcXVpcmVkIHRvDQo+PiAgICAgICB0cmFuc2Zvcm0gYSBzeXN0ZW0gZnJv bSBpdHMgaW5pdGlhbCBkZWZhdWx0IHN0YXRlIGludG8gaXRzIGN1cnJlbnQNCj4+ICAgICAgIHN0 YXRlIFtSRkM0NzQxXS4NCj4+DQo+PiBOb3RpZmljYXRpb24gY29udGVudCBpcyBub3QgY29uZmln dXJhdGlvbiBkYXRhLg0KPj4NCj4+IC9qcw0KPj4NCj4+IE9uIE1vbiwgSnVuIDAxLCAyMDE1IGF0 IDA3OjQ4OjUxQU0gKzAwMDAsIE1hbmR5IExpdSB3cm90ZToNCj4+ID4gU29ycnksIEkgZG9uJ3Qg Z2V0IHlvdXIgcG9pbnQuIEJ1dCBob3BlZnVsbHkgSSBhZGRyZXNzZWQgbXkgcXVlc3Rpb24gbW9y ZSBjbGVhcmx5IHRoaXMgdGltZS4NCj4+ID4NCj4+ID4gVGhlIGNvbmZpZ3VyYXRpb24gY2hhbmdl IG5vdGlmaWNhdGlvbiBpcyBnZW5lcmF0ZWQgd2hlbiB0aGUgTkVUQ09ORiBzZXJ2ZXIgZGV0ZWN0 cyB0aGF0IHRoZSA8cnVubmluZz4gb3IgPHN0YXJ0dXA+IGNvbmZpZ3VyYXRpb24gZGF0YXN0b3Jl IGhhcyBiZWVuIGNoYW5nZWQgYnkgYSBtYW5hZ2VtZW50IHNlc3Npb24uIFRoZSBub3RpZmljYXRp b24gc3VtbWFyaXplcyB0aGUgImVkaXRzIiB0aGF0IGhhdmUgYmVlbiBkZXRlY3RlZC4gIiAgVGhl IHN0cnVjdHVyZSBvZiB0aGUgImVkaXQiIGlzIGFkZHJlc3NlZCBpbiBSRkM2NDcwIGFzIGJlbG93 LiBXaGF0IEkgd2FudCBpcyB0byBhZGQgdGhlIGFub3RoZXIgbGVhZiB0byBhZGRyZXNzIHRoZSAi dGFyZ2V0IiBpcyBjaGFuZ2VkIHRvIHdoYXQuIEJ1dCBiZWNhdXNlIHRoZSAidGFyZ2V0IiBtYXkg YmUgYSBjb250YWluZXIsIGEgbGlzdCwgYSBsZWFmIG9yIGEgbGVhZi1yZWZlcmVuY2UsIGV0Yy4g SXQgY291bGQgYmUgYW55IG5vZGUgb2YgdGhlIHRyZWUuIFNvIGEgY29tbW9uIGZvcm1hdCBmb3Ig YWRkcmVzc2luZyB0aGUgInRhcmdldCIgaXMgY2hhbmdlZCB0byB3aGF0IGlzIG5lZWRlZC4NCj4+ ID4gbGlzdCBlZGl0IHsNCj4+ID4gICAgIGxlYWYgdGFyZ2V0IHsNCj4+ID4gICAgICAgICB0eXBl IGluc3RhbmNlLWlkZW50aWZpZXI7DQo+PiA+ICAgICAgICBkZXNjcmlwdGlvbg0KPj4gPiAgICAg ICAgLi4uLi4NCj4+ID4gICAgIH0NCj4+ID4gICAgIGxlYWYgb3BlcmF0aW9uIHsNCj4+ID4gICAg ICAgICB0eXBlIG5jOmVkaXQtb3BlcmF0aW9uLXR5cGU7DQo+PiA+ICAgICAgICBkZXNjcmlwdGlv bg0KPj4gPiAgICAgICAgICAgICAuLi4uLg0KPj4gPiAgICAgfQ0KPj4gPiB9DQo+PiA+DQo+PiA+ IFRoYW5rcywNCj4+ID4gTWFuZHkNCj4+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ ID4gRnJvbTogSnVlcmdlbiBTY2hvZW53YWVsZGVyDQo+PiA+IFttYWlsdG86ai5zY2hvZW53YWVs ZGVyQGphY29icy11bml2ZXJzaXR5LmRlXQ0KPj4gPiBTZW50OiBNb25kYXksIEp1bmUgMDEsIDIw MTUgMzoyNiBQTQ0KPj4gPiBUbzogTWFuZHkgTGl1DQo+PiA+IENjOiBhbmR5QG5ldGNvbmZjZW50 cmFsLm9yZzsgS2FpIExpbjsgUm9iZXJ0IE90dGluZ2VyOyANCj4+ID4gbmV0Y29uZkBpZXRmLm9y ZzsgQXRoYW5hc2lvcyBLeXBhcmxpcw0KPj4gPiBTdWJqZWN0OiBSZTogW05ldGNvbmZdIEhvdyB0 byBhdWdtZW50IFJGQzY0NzAgdG8gc3VwcGx5IGRldGFpbCANCj4+ID4gY29uZmlndXJhdGlvbiBj aGFuZ2UgaW5mb3JtYXRpb24NCj4+ID4NCj4+ID4gT24gTW9uLCBKdW4gMDEsIDIwMTUgYXQgMDY6 NTE6MjdBTSArMDAwMCwgTWFuZHkgTGl1IHdyb3RlOg0KPj4gPg0KPj4gPiA+IFsuLi5dIFNvIHdl IG5lZWQgdG8gZmluZCBhIGNvbW1vbiBmb3JtYXQgZm9yIHRoZSAiY29udGVudCIgdG8gDQo+PiA+ ID4gYWNjb21tb2RhdGUgZGlmZmVyZW50IHR5cGVzIG9mICJ0YXJnZXQiLiB3aGF0IEkgY2FuIGlt YWdpbmUgaXMgDQo+PiA+ID4gYW55eG1sIGNvdWxkIGJlIHVzZWQuIEJ1dCBzZWVtcyBpdCBpcyBu b3QgYSBnb29kIGNob2ljZS4gQmVjYXVzZSANCj4+ID4gPiBiYXNlZCBvbiBSRkM2MDIwLCBpdCBp cyBub3QgcmVjb21tZW5kZWQgdG8gYmUgdXNlZCBvbiBjb25maWd1cmF0aW9uIGRhdGEuDQo+PiA+ DQo+PiA+IFNpbmNlIHlvdSBwbGFuIHRvIGF1Z21lbnQgYSBub3RpZmljYXRpb24sIHRoaXMgd29u J3QgYmUgY29uZmlnIHRydWUgZGF0YSAodGhpcyBpcyB3aGF0IHRoZSBzdGF0ZW1lbnQgaW4gUkZD IDYwMjAgcmVhbGx5IGhpbnRzIGF0KS4gU2VlIGFsc28gdGhlIGRlZmluaXRpb24gb2YgJ2NvbmZp Z3VyYXRpb24gZGF0YScgaW4gc2VjdGlvbiAzIG9mIFJGQyA2MDIwLg0KPj4gPg0KPj4gPiAvanMN Cj4+ID4NCj4+ID4gLS0NCj4+ID4gSnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNv YnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNCj4+ID4gUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcg ICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KPj4gPiBGYXg6 ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5 LmRlLz4NCj4+DQo+PiAtLQ0KPj4gSnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNv YnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNCj4+IFBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAg ICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnkNCj4+IEZheDogICAr NDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUv Pg0KPg0KPiAtLQ0KPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2 ZXJzaXR5IEJyZW1lbiBnR21iSA0KPiBQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENh bXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55DQo+IEZheDogICArNDkgNDIxIDIw MCAzMTAzICAgICAgICAgPGh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0K From nobody Sun Jun 7 18:31:46 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 543341A1B88 for ; Sun, 7 Jun 2015 18:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.08 X-Spam-Level: X-Spam-Status: No, score=-0.08 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GVxN4x34ER1 for ; Sun, 7 Jun 2015 18:31:42 -0700 (PDT) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84DF11A1B7B for ; Sun, 7 Jun 2015 18:31:41 -0700 (PDT) Received: by lbcue7 with SMTP id ue7so71522442lbc.0 for ; Sun, 07 Jun 2015 18:31:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=uMb5A1ZVL1/VXkmryghlfMrf4xQUkiS+oxqmy4LZmrI=; b=HmCmM8ya+E4IxQSRzuBXeM4X3gqfqqRL/M7tE0Gf0bXnLFjMYg3RK4yawtYqxjqDQF 6zdc6Ncdd27pTEVaSaAsagzcDrtlXX4qBlzvRjR/OoUORngk4XGW9Pvalgk9zKWlpzmZ 9q1gTHj1hpe1cCPtxNf70kiUs2xMAjxmj5JmGAjO6OHUNeBH0rlEjMiz7iMJxAYALfAa vSJ+VXxTHwK2HRB00Ff43q8JreuhRpvjNeWz1HvC5jQMY269QaQlmNuLJM6nQb6eZl4h tsQsH5ta5TqF+ENOU5hKPJFTlOOnYc2hJf/6D477rxlMRvDILccSEJljXhkUcrvrW1pU SZ2g== X-Gm-Message-State: ALoCoQnT9B2EopKWSYVsFc3vUB+1/SCi+a2MiDtw9Nhz7SLbTEo54D0Px3tPTclTdeq3tr5Yz+t3 MIME-Version: 1.0 X-Received: by 10.152.116.49 with SMTP id jt17mr14069892lab.82.1433727099818; Sun, 07 Jun 2015 18:31:39 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Sun, 7 Jun 2015 18:31:39 -0700 (PDT) In-Reply-To: References: Date: Sun, 7 Jun 2015 18:31:39 -0700 Message-ID: From: Andy Bierman To: Rodney Cummings Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Netconf Subject: Re: [Netconf] Suggestion for RESTCONF section 5.3 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 01:31:44 -0000 Hi, Only choice (1) is published in an RFC. Options (2) - (4) are work-in-progress. It is difficult to estimate how long an IETF RFC will take, or how much it will change from the current draft to RFC. IMO IoT should use (4), but wait for the RFC. Participate in the CoMI work and it might get done faster. Andy On Fri, Jun 5, 2015 at 12:39 PM, Rodney Cummings wrote: > Hello, > > Although I am new to the NETCONF WG and mailing list, I have a suggestion > for the RESTCONF I-D that I'd like to discuss. I realize that I may be > bringing up a topic that has already been thoroughly discussed. > Nevertheless, this issue is a genuine problem for deployment of RESTCONF for > my applications, so if my suggestion is rejected, it will be helpful for me > understand the rationale. > > Suggestion > -- > > Section 5.3 of the current I-D > (https://tools.ietf.org/html/draft-ietf-netconf-restconf-04) states: > > "Content is encoded in either JSON or XML format. A server MUST support XML > encoding and MAY support JSON encoding." > > My suggestion is to change section 5.3 to state: > > "Content is encoded in either JSON or XML format. A client MUST support at > least one of the specified encodings (XML or JSON), and a client SHOULD > support all specified encodings. A server MUST support at least one of the > specified encodings (XML or JSON), and a server MAY support multiple > encodings." > > In other words, if a server wants to focus on JSON exclusively, allow that > as a conformant implementation. The client has a presumed burden to support > a server that is XML-only or JSON-only. > > Rationale > -- > > As part of a roadmap for supporting industrial IoT devices, the 802.1 > Time-Sensitive Networking standards (TSN) are focusing on YANG modules for > configuration of the low-level queuing behavior in 802.1 switches (e.g. > schedule for traffic egress on each port). The assumption is that an > SDN-style controller will use these YANG modules to write configuration to > each switch in the network in an automated manner. Ideally, as TSN moves > forward it will be well-aligned with analogous IETF efforts, including CoRE, > 6TiSCH, and DetNet (upcoming BoF in July). > > One near-term focus for the TSN effort is to support an IoT device (e.g. > industrial motor, smart grid IED) that supports Ethernet today, but that > wants to embed an 802.1 switch. The goal is to expose two external ports > from the device, using the switch to enable topologies like daisy-chain and > ring. This is commonly done today using proprietary Ethernet extensions, but > we want to transition industrial applications to 802/IETF standards (much > like the 6TiSCH effort for wireless). The challenge is that although this > IoT device is technically a switch/router, it is very "Operational > Technology" (OT). A YANG-based management protocol is required to configure > the switch, but the switch supports a subset of what a standalone managed > switch/router supports, and the switch will always be configured in-band > from an OT controller, never from an IT-style NMS. > > From the perspective of one of these IoT device manufacturers, the primary > question for management is: > What YANG-based management protocol do I implement in my device? > Among others, I've been tasked to help answer this question for TSN and its > related groups (e.g. AVnu.org/industrial). The assumption is that the > manufacturer will use one and only one server implementation. Since the goal > is not to support a traditional NMS, implementation of multiple servers is > not a goal (e.g. SNMPv3 and NETCONF and RESTCONF XML and so on). > > Based on this, I've been trying to choose among the following > implementations in order to make a recommendation: > 1. NETCONF with XML encoding > 2. RESTCONF with XML encoding > 3. RESTCONF with JSON encoding > 4. CoMI with CBOR encoding > > For the industrial application space that I am evaluating, the devices are > "constrained" as CoRE describes. Nevertheless, over the last few years it > has become common for these devices to implement an HTTP web server for > configuration. These web servers are often designed as RESTful. Given the > constrained nature of the devices, they tend to use JSON, due to the > perception that XML parsing is less efficient. > > Based on these assumptions, I tend to exclude NETCONF. NETCONF is > full-featured, but most of those features are relevant to NMS concerns. > Also, NETCONF's basis on XML raises a perception (if not reality) of complex > implementation. > > CoMI looks promising, since it is based on relatively mature RFCs like CoAP > and CBOR. Nevertheless, the CoMI I-D itself looks like it is > not-quite-ready-for-prime-time. There are many TODOs, and the YANG hash > seems like it will require more prototyping before it is truly nailed down. > Given that, I can't really recommend that direction just yet, but ideally it > will be useful in the future. > > That leaves RESTCONF. Since the industrial device manufacturers tend to be > familiar with REST already, this is an easy sell. The I-D itself seems to be > relatively mature. > > Ideally, I could recommend option 3, RESTCONF with JSON. That is the > cleanest fit to what industrial devices do today. > > Given the limitations of section 5.3 in v04 of the I-D, I would be forced to > recommend option 2, RESTCONF with XML. If the IoT device is forced to > implement XML for conformance, then the addition of JSON doesn't offer much > value, since the goal is automated configuration. > > If we could allow RESTCONF server implementation using JSON-only, that would > be very helpful. What's more, that sort of conformance might leave the door > open to add CoMI as a formal RESTCONF encoding in the future. > > Feedback is much appreciated. Thanks. > > ---------------------------- > Rodney Cummings > Principal Software Architect, Industrial/Embedded Networks > National Instruments > Tel: (512) 683-8544 > Fax: (512) 683-8661 > Email: Rodney.Cummings@ni.com > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Sun Jun 7 23:38:45 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5A21B2C94 for ; Sun, 7 Jun 2015 23:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7_uvfXAsXGSS for ; Sun, 7 Jun 2015 23:38:36 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FAA61B2C8E for ; Sun, 7 Jun 2015 23:38:36 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DEE92727; Mon, 8 Jun 2015 08:38:34 +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 JDhAa7QXvOBa; Mon, 8 Jun 2015 08:38: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, 8 Jun 2015 08:38:33 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id A48282002B; Mon, 8 Jun 2015 08:38:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id IAF_owT3WY-b; Mon, 8 Jun 2015 08:38:35 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 39D2B20013; Mon, 8 Jun 2015 08:38:32 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 01DDC34404F6; Mon, 8 Jun 2015 08:38:30 +0200 (CEST) Date: Mon, 8 Jun 2015 08:38:29 +0200 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20150608063828.GB28037@elstar.local> Mail-Followup-To: Kent Watsen , "netconf@ietf.org" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] server-model #49: combine trusted-ca-certs and trusted-client-certs for ssh/tls? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 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, 08 Jun 2015 06:38:43 -0000 On Sun, Jun 07, 2015 at 06:32:43PM +0000, Kent Watsen wrote: > > This issue is the only issue currently blocking the server-model draft. > > > For convenience, the email exchange with Juergen mentioned before is here: > https://www.ietf.org/mail-archive/web/netconf/current/msg10156.html. > > > As a thought exercise, assume that it is inevitable that a keychain model > will exist some day, and that a future revision of this draft wants to use > It (are these valid assumptions?). If so, how would this draft be updated > to make use of the new keychain model? > For the sake of completeness: OPTION 5: factor out a keychain model now and use it import ietf-keychain { prefix kc; } container trusted-ca-certs { leaf-list trusted-ca-cert { type leafref { path "/kc:trust-anchors/kc:trust-anchor/kc:name"; } } container server-certificates { leaf-list server-certificate { type leafref { path "/kc:server-certificates/kc:server-certificate/kc:name"; } } Yes, this sounds bad since this means another dependency. But that said, getting the keystore (or keychain or credential store) right is likely not much more work than getting it right for the server model (although a generic keystore might attract more security area eyeballs but then this may not be bad either in terms of quality of the final solution). /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 Jun 8 01:18:57 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA121B2D6F for ; Mon, 8 Jun 2015 01:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0664qdu4PNRS for ; Mon, 8 Jun 2015 01:18:54 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 10DE51B2D69 for ; Mon, 8 Jun 2015 01:18:54 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 5AE331AE043B; Mon, 8 Jun 2015 10:18:52 +0200 (CEST) Date: Mon, 08 Jun 2015 10:20:05 +0200 (CEST) Message-Id: <20150608.102005.1482395931170643204.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] YANG Patch Issue #3: :distinct-startup X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 08:18:55 -0000 Andy Bierman wrote: > Hi, > > A new issue has been raised for the YANG Patch draft. > > https://github.com/netconf-wg/yang-patch/issues/3 > > There is no support for the client to control > when running is saved to startup. If this is a concern, > it needs to be addressed. If not (i.e., just use > NETCONF for this level of client control) then > it does not need to be addressed. Isn't this a RESTCONF issue, rather than YANG PATCH issue? YANG PATCH defines a format for applying to patches to a YANG data store. Which data store to apply the patches to is handled by the protocol (RESTCONF). /martin From nobody Mon Jun 8 02:32:00 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA3B1B2DF6 for ; Mon, 8 Jun 2015 02:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQb9BGkSBU7S for ; Mon, 8 Jun 2015 02:31:58 -0700 (PDT) Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [209.85.215.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 032F41B2DDA for ; Mon, 8 Jun 2015 02:31:58 -0700 (PDT) Received: by laew7 with SMTP id w7so92466648lae.1 for ; Mon, 08 Jun 2015 02:31:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=R6N2XjZmfEvYZCpwtdyCk3l8G5VO1xRCobj4h9+3jj8=; b=YVvqMgiYB+Pd4ac99tW2xmVvlSPbCdUC3CzJnqg0uOwLGP+eUr9e4matcF34pdKF4r 2blXQcdp3jLXRx82aqYIQBRnTNE9uOeXbx6ldVsZPqpXNJg4QipOLXDrZfhDkC1n7+F2 6YgswLn1TrZNXwiNrHYh3HLjhvubm++6QwuepdpctB8QHPXMv+IDYNh7w+jUKi6vd9+u afaNz9y2bVOsvthY8phySWFRlXCcyPTFEwEeDFxoBCC4ed8md3H3noyNhBwP74zssapX XxOaqJ07E0FU0ja+hoTsZX1d3NPMGBuZvx0KRTDKVmKUm6rvYUbg1yynB6EW+x4IAYKL j4Mg== X-Gm-Message-State: ALoCoQk/X03iQxqHQURXGxuvpu8T3GMzjx9FuIgDQg08Yzz1rDggPPVaEsszvhC4NXA2zCJ26aDM MIME-Version: 1.0 X-Received: by 10.112.97.194 with SMTP id ec2mr15711026lbb.88.1433755916390; Mon, 08 Jun 2015 02:31:56 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Mon, 8 Jun 2015 02:31:56 -0700 (PDT) In-Reply-To: <20150608.102005.1482395931170643204.mbj@tail-f.com> References: <20150608.102005.1482395931170643204.mbj@tail-f.com> Date: Mon, 8 Jun 2015 02:31:56 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Netconf Subject: Re: [Netconf] YANG Patch Issue #3: :distinct-startup X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 09:31:59 -0000 Hi, Perhaps this is a RESTCONF issue. It has not been accepted as an open issue. IMO this can be left out. RESTCONF has a unified datastore. For access to individual datastores, use NETCONF. Andy On Mon, Jun 8, 2015 at 1:20 AM, Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> A new issue has been raised for the YANG Patch draft. >> >> https://github.com/netconf-wg/yang-patch/issues/3 >> >> There is no support for the client to control >> when running is saved to startup. If this is a concern, >> it needs to be addressed. If not (i.e., just use >> NETCONF for this level of client control) then >> it does not need to be addressed. > > Isn't this a RESTCONF issue, rather than YANG PATCH issue? YANG > PATCH defines a format for applying to patches to a YANG data store. > Which data store to apply the patches to is handled by the protocol > (RESTCONF). > > > /martin From nobody Mon Jun 8 02:47:32 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0C381B2E37 for ; Mon, 8 Jun 2015 02:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37wkMb4uEPPy for ; Mon, 8 Jun 2015 02:47:24 -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 6458A1B2E38 for ; Mon, 8 Jun 2015 02:47:24 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 1CAE01017; Mon, 8 Jun 2015 11:47: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 lpIbH1nGgkfz; Mon, 8 Jun 2015 11:47:22 +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, 8 Jun 2015 11:47:22 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3838920031; Mon, 8 Jun 2015 11:47:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id GyN-YrgBFasr; Mon, 8 Jun 2015 11:47:15 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8403B20038; Mon, 8 Jun 2015 11:47:12 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 362D734414AC; Mon, 8 Jun 2015 11:47:10 +0200 (CEST) Date: Mon, 8 Jun 2015 11:47:09 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20150608094708.GA28936@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , Netconf References: <20150608.102005.1482395931170643204.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Netconf Subject: Re: [Netconf] YANG Patch Issue #3: :distinct-startup X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 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, 08 Jun 2015 09:47:31 -0000 On Mon, Jun 08, 2015 at 02:31:56AM -0700, Andy Bierman wrote: > Hi, > > Perhaps this is a RESTCONF issue. > It has not been accepted as an open issue. > IMO this can be left out. > RESTCONF has a unified datastore. > For access to individual datastores, use NETCONF. > Looking at section 1.3 of draft-ietf-netconf-restconf-05, should the text be more explicit about the details? I mean, if the candidate is used, is it cleared first or do any pending edits in candidate become part of the commit? Is a server supporting both NETCONF and RESTCONF going to use locks on or during the processing of a RESTCONF edit or is that left up to the implementor to decide? Is the copy to startup something that happens after each edit? This may be pretty expensive if a RESTCONF client is pushing many small edits in a loop (not unlikely that we see such clients I would say). /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 Jun 8 04:51:40 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4CC51A6EF2 for ; Mon, 8 Jun 2015 04:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3t3qy1Q3-z0A for ; Mon, 8 Jun 2015 04:51:37 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E07951A6F0B for ; Mon, 8 Jun 2015 04:51:36 -0700 (PDT) Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id DB5771AE043B; Mon, 8 Jun 2015 13:51:34 +0200 (CEST) Date: Mon, 08 Jun 2015 13:51:34 +0200 (CEST) Message-Id: <20150608.135134.815056002069146319.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20150608063828.GB28037@elstar.local> References: <20150608063828.GB28037@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] server-model #49: combine trusted-ca-certs and trusted-client-certs for ssh/tls? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 11:51:39 -0000 Juergen Schoenwaelder wrote: > On Sun, Jun 07, 2015 at 06:32:43PM +0000, Kent Watsen wrote: > > > > This issue is the only issue currently blocking the server-model draft. > > > > > > For convenience, the email exchange with Juergen mentioned before is here: > > https://www.ietf.org/mail-archive/web/netconf/current/msg10156.html. > > > > > > As a thought exercise, assume that it is inevitable that a keychain model > > will exist some day, and that a future revision of this draft wants to use > > It (are these valid assumptions?). If so, how would this draft be updated > > to make use of the new keychain model? > > > > For the sake of completeness: > > OPTION 5: factor out a keychain model now and use it How is this different from option 4? /martin > > import ietf-keychain { > prefix kc; > } > > container trusted-ca-certs { > leaf-list trusted-ca-cert { > type leafref { > path "/kc:trust-anchors/kc:trust-anchor/kc:name"; > } > } > > container server-certificates { > leaf-list server-certificate { > type leafref { > path "/kc:server-certificates/kc:server-certificate/kc:name"; > } > } > > Yes, this sounds bad since this means another dependency. But that > said, getting the keystore (or keychain or credential store) right is > likely not much more work than getting it right for the server model > (although a generic keystore might attract more security area eyeballs > but then this may not be bad either in terms of quality of the final > solution). > > /js > > -- > 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 > From nobody Mon Jun 8 05:08:45 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4080E1A6F39 for ; Mon, 8 Jun 2015 05:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nP3aowiKv2Ib for ; Mon, 8 Jun 2015 05:08:42 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 918CF1A6F2E for ; Mon, 8 Jun 2015 05:08:42 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 4C9341204; Mon, 8 Jun 2015 14:08:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id cVL-JglLhT6V; Mon, 8 Jun 2015 14:08:38 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 8 Jun 2015 14:08:38 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id CA9D92002B; Mon, 8 Jun 2015 14:08:38 +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 K5hHlgPJAYwZ; Mon, 8 Jun 2015 14:08: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 C172320013; Mon, 8 Jun 2015 14:08:36 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 53D063441FBC; Mon, 8 Jun 2015 14:08:34 +0200 (CEST) Date: Mon, 8 Jun 2015 14:08:33 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20150608120832.GB29405@elstar.local> Mail-Followup-To: Martin Bjorklund , kwatsen@juniper.net, netconf@ietf.org References: <20150608063828.GB28037@elstar.local> <20150608.135134.815056002069146319.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150608.135134.815056002069146319.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] server-model #49: combine trusted-ca-certs and trusted-client-certs for ssh/tls? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 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, 08 Jun 2015 12:08:44 -0000 On Mon, Jun 08, 2015 at 01:51:34PM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Sun, Jun 07, 2015 at 06:32:43PM +0000, Kent Watsen wrote: > > > > > > This issue is the only issue currently blocking the server-model draft. > > > > > > > > > For convenience, the email exchange with Juergen mentioned before is here: > > > https://www.ietf.org/mail-archive/web/netconf/current/msg10156.html. > > > > > > > > > As a thought exercise, assume that it is inevitable that a keychain model > > > will exist some day, and that a future revision of this draft wants to use > > > It (are these valid assumptions?). If so, how would this draft be updated > > > to make use of the new keychain model? > > > > > > > For the sake of completeness: > > > > OPTION 5: factor out a keychain model now and use it > > How is this different from option 4? > Option #4 says we use an opaque string to refer to something yet to be defined. Option #5 says we define it and use a leafref. I actually think #4 is broken since it requires updates that I think violate YANG update rules nor do I understand why something that was a string suddenly becomes conditional via an if-feature. /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 Jun 8 05:48:37 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7BF1A70FE for ; Mon, 8 Jun 2015 05:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q43z-_yKoNbr for ; Mon, 8 Jun 2015 05:48:34 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6DA1A702A for ; Mon, 8 Jun 2015 05:48:31 -0700 (PDT) Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id EA90E1AE043B; Mon, 8 Jun 2015 14:48:29 +0200 (CEST) Date: Mon, 08 Jun 2015 14:48:29 +0200 (CEST) Message-Id: <20150608.144829.87446572227513213.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20150608120832.GB29405@elstar.local> References: <20150608063828.GB28037@elstar.local> <20150608.135134.815056002069146319.mbj@tail-f.com> <20150608120832.GB29405@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] server-model #49: combine trusted-ca-certs and trusted-client-certs for ssh/tls? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 12:48:35 -0000 Juergen Schoenwaelder wrote: > On Mon, Jun 08, 2015 at 01:51:34PM +0200, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > On Sun, Jun 07, 2015 at 06:32:43PM +0000, Kent Watsen wrote: > > > > > > > > This issue is the only issue currently blocking the server-model draft. > > > > > > > > > > > > For convenience, the email exchange with Juergen mentioned before is here: > > > > https://www.ietf.org/mail-archive/web/netconf/current/msg10156.html. > > > > > > > > > > > > As a thought exercise, assume that it is inevitable that a keychain model > > > > will exist some day, and that a future revision of this draft wants to use > > > > It (are these valid assumptions?). If so, how would this draft be updated > > > > to make use of the new keychain model? > > > > > > > > > > For the sake of completeness: > > > > > > OPTION 5: factor out a keychain model now and use it > > > > How is this different from option 4? > > > > Option #4 says we use an opaque string to refer to something yet to be > defined. Option #5 says we define it and use a leafref. I actually > think #4 is broken since it requires updates that I think violate YANG > update rules nor do I understand why something that was a string > suddenly becomes conditional via an if-feature. Maybe I am confused. I am lookng at the issue page https://github.com/netconf-wg/server-model/issues/49. Kent posted a message there 6 days ago, in which he lists 4 options. Option #4 is described as: Work on a keychain solution of some sort - this would delay server-model draft longer... Is there another option list for this issue? /martin From nobody Mon Jun 8 06:43:00 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED5F61A87A4 for ; Mon, 8 Jun 2015 06:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4hxGAkZqg4U3 for ; Mon, 8 Jun 2015 06:42:57 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7175E1A87A3 for ; Mon, 8 Jun 2015 06:42:57 -0700 (PDT) Received: from localhost (unknown [173.38.220.47]) by mail.tail-f.com (Postfix) with ESMTPSA id 8891F1AE043B; Mon, 8 Jun 2015 15:42:56 +0200 (CEST) Date: Mon, 08 Jun 2015 15:42:55 +0200 (CEST) Message-Id: <20150608.154255.1228399594019434358.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20150608.144829.87446572227513213.mbj@tail-f.com> References: <20150608.135134.815056002069146319.mbj@tail-f.com> <20150608120832.GB29405@elstar.local> <20150608.144829.87446572227513213.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] server-model #49: combine trusted-ca-certs and trusted-client-certs for ssh/tls? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 13:42:59 -0000 Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Mon, Jun 08, 2015 at 01:51:34PM +0200, Martin Bjorklund wrote: > > > Juergen Schoenwaelder wrote: > > > > On Sun, Jun 07, 2015 at 06:32:43PM +0000, Kent Watsen wrote: > > > > > > > > > > This issue is the only issue currently blocking the server-model draft. > > > > > > > > > > > > > > > For convenience, the email exchange with Juergen mentioned before is here: > > > > > https://www.ietf.org/mail-archive/web/netconf/current/msg10156.html. > > > > > > > > > > > > > > > As a thought exercise, assume that it is inevitable that a keychain model > > > > > will exist some day, and that a future revision of this draft wants to use > > > > > It (are these valid assumptions?). If so, how would this draft be updated > > > > > to make use of the new keychain model? > > > > > > > > > > > > > For the sake of completeness: > > > > > > > > OPTION 5: factor out a keychain model now and use it > > > > > > How is this different from option 4? > > > > > > > Option #4 says we use an opaque string to refer to something yet to be > > defined. Option #5 says we define it and use a leafref. I actually > > think #4 is broken since it requires updates that I think violate YANG > > update rules nor do I understand why something that was a string > > suddenly becomes conditional via an if-feature. > > Maybe I am confused. I am lookng at the issue page > https://github.com/netconf-wg/server-model/issues/49. Kent posted a > message there 6 days ago, in which he lists 4 options. Option #4 is > described as: Work on a keychain solution of some sort - this would > delay server-model draft longer... > > Is there another option list for this issue? Aha, ok, found it in an email from Kent. I suggest we try to keep a single option list for each issue up to date. /martin From nobody Mon Jun 8 07:18:34 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9C21A8862 for ; Mon, 8 Jun 2015 07:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWzUYFLpQpGE for ; Mon, 8 Jun 2015 07:18:31 -0700 (PDT) Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F0EA1A88C6 for ; Mon, 8 Jun 2015 07:18:30 -0700 (PDT) Received: by laew7 with SMTP id w7so98169840lae.1 for ; Mon, 08 Jun 2015 07:18:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=0vRcjvBcnc1u1sVeOpBRYJvc32vDXHHwTnc1P0ayCPU=; b=R2NEbD0Zr8Uc38uJwE2Khyj659CcORaDWHTVPdB9Aj0tnyEj901AkIC/DcyYFh1rML Kh+hwCUYosZocFIeq4K1tzAILhWeCZTVZy+2nMvYtU2uEdH3LP0VdS1r6q1+AUD3lzXk fg3cKpYqqy0+LO4PTOaysyIpWB3xLh3sgH6Te5hbsnk5sIDehwXysgnDoZM43g4nsINE HdiSoIo4nKlPijkNo6xUcmwGLhqKVXU2RWFGevy//eCqU4dKxubnrU+cTgk6KEDgJEty ovnKH/iP82kVvlBti2nQ0dTjjofcNCap86AzEn+JlAKpzBywnNRs5eLhjy2t+UYkmByi MVZg== X-Gm-Message-State: ALoCoQkZVKZ9ag0bCKxJIVN9P0ICxMurXGnfrk6UlmftfSeLKmA+fcBHJ8BQkyH4KXUw+eIiYa2o MIME-Version: 1.0 X-Received: by 10.152.204.7 with SMTP id ku7mr17002404lac.38.1433773108557; Mon, 08 Jun 2015 07:18:28 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Mon, 8 Jun 2015 07:18:28 -0700 (PDT) In-Reply-To: <20150608094708.GA28936@elstar.local> References: <20150608.102005.1482395931170643204.mbj@tail-f.com> <20150608094708.GA28936@elstar.local> Date: Mon, 8 Jun 2015 07:18:28 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Martin Bjorklund , Netconf Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Netconf] YANG Patch Issue #3: :distinct-startup X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 14:18:32 -0000 On Mon, Jun 8, 2015 at 2:47 AM, Juergen Schoenwaelder wrote: > On Mon, Jun 08, 2015 at 02:31:56AM -0700, Andy Bierman wrote: >> Hi, >> >> Perhaps this is a RESTCONF issue. >> It has not been accepted as an open issue. >> IMO this can be left out. >> RESTCONF has a unified datastore. >> For access to individual datastores, use NETCONF. >> > > Looking at section 1.3 of draft-ietf-netconf-restconf-05, should the > text be more explicit about the details? I mean, if the candidate is > used, is it cleared first or do any pending edits in candidate become > part of the commit? Is a server supporting both NETCONF and RESTCONF > going to use locks on or during the processing > of a RESTCONF edit or is that left up to the implementor to decide? > It works justlike like NETCONF. If the candidate is unlocked and dirty, the pending edits get committed. > Is the copy to startup something that happens after each edit? This > may be pretty expensive if a RESTCONF client is pushing many small > edits in a loop (not unlikely that we see such clients I would say). > There were multiple proposals suggested to the WG to add a query parameter to control nv-save. The WG was not interested in any of them. Use NETCONF to access the individual datastores. RESTCONF has no direct access to any NETCONF datastores. > /js > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Mon Jun 8 07:31:16 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F6B1A8935 for ; Mon, 8 Jun 2015 07:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4JMPrFNU58Ai for ; Mon, 8 Jun 2015 07:31:10 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 422A31A8932 for ; Mon, 8 Jun 2015 07:31:10 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E9DAFE7D; Mon, 8 Jun 2015 16:31:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id xNtp-YFGAZJV; Mon, 8 Jun 2015 16:31:07 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 8 Jun 2015 16:31:08 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id DD6AB2002B; Mon, 8 Jun 2015 16:31:07 +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 Z68ypmK9Y5En; Mon, 8 Jun 2015 16:31:11 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 323A820013; Mon, 8 Jun 2015 16:31:06 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 46DC13442A0E; Mon, 8 Jun 2015 16:31:03 +0200 (CEST) Date: Mon, 8 Jun 2015 16:31:02 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20150608143100.GD29788@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , Netconf References: <20150608.102005.1482395931170643204.mbj@tail-f.com> <20150608094708.GA28936@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Netconf Subject: Re: [Netconf] YANG Patch Issue #3: :distinct-startup X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 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, 08 Jun 2015 14:31:14 -0000 On Mon, Jun 08, 2015 at 07:18:28AM -0700, Andy Bierman wrote: > On Mon, Jun 8, 2015 at 2:47 AM, Juergen Schoenwaelder > wrote: > > On Mon, Jun 08, 2015 at 02:31:56AM -0700, Andy Bierman wrote: > >> Hi, > >> > >> Perhaps this is a RESTCONF issue. > >> It has not been accepted as an open issue. > >> IMO this can be left out. > >> RESTCONF has a unified datastore. > >> For access to individual datastores, use NETCONF. > >> > > > > Looking at section 1.3 of draft-ietf-netconf-restconf-05, should the > > text be more explicit about the details? I mean, if the candidate is > > used, is it cleared first or do any pending edits in candidate become > > part of the commit? Is a server supporting both NETCONF and RESTCONF > > going to use locks on or during the processing > > of a RESTCONF edit or is that left up to the implementor to decide? > > > > It works justlike like NETCONF. > If the candidate is unlocked and dirty, the pending edits get > committed. I think this should be mentioned to avoid surprises. > > Is the copy to startup something that happens after each edit? This > > may be pretty expensive if a RESTCONF client is pushing many small > > edits in a loop (not unlikely that we see such clients I would say). > > There were multiple proposals suggested to the WG to add a query > parameter to control nv-save. The WG was not interested > in any of them. Use NETCONF to access the individual datastores. > RESTCONF has no direct access to any NETCONF datastores. I am interested in what I can expect from a RESTCONF server. If every RESTCONF edit causes an NV write (and this is how I read the current text), then my performance expectations are likely a down to NV write speed. On some of my boxes, this is really slow. Hence, my expectation is that implementors will cheat a bit and do delayed writes (but then I never know when something really got written). /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 Jun 8 07:57:49 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6A91B2E75 for ; Mon, 8 Jun 2015 07:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wd8Wqkd2FKfS for ; Mon, 8 Jun 2015 07:57:46 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29EDA1B2E79 for ; Mon, 8 Jun 2015 07:57:44 -0700 (PDT) Received: by laew7 with SMTP id w7so99084516lae.1 for ; Mon, 08 Jun 2015 07:57:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=jIi2PgQ2ULzXxuv6eUXSEJnhtpW7Ef/pPKhe5kekJmE=; b=UTNe3OOTVu/OjBL3SFbVQZXY9ifDPAN9IHBdDu/JU+gV9ke2jOXB1/ufTdszfsvFuP 7xRAvegaekhsmSVMFjM79zFWxvLIygXT7Z1tXn3bzeRtt7/yl+Zu1Wuj9xlb2+WsAunp jvnNuj2yw8eIk+QBcM1FtkrnNwblwvUuNwFGNp0kphFqVDXEoCn0NVfSAbLqUAUFjK0+ PHlTuEZkIBs3TrPrE69wohMnNoO6l9bNIAZOwoz7ghnVAKVLa/35AX7Jk/aUwqiFJTmP Nt1mwSdSBjAxCDsQG9KApON3VdBFPhZ7xbrB+f0jBh4LBydDxZFVLUfWVwqHUQ6PprEd 60YQ== X-Gm-Message-State: ALoCoQlOD3sQmJTr7ebelnr9PnUezqV1OTpQmLKAk5k7ld9//Pr1P1PQKZi0v4gPlyWoqy1NXNcB MIME-Version: 1.0 X-Received: by 10.152.204.7 with SMTP id ku7mr17236716lac.38.1433775462669; Mon, 08 Jun 2015 07:57:42 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Mon, 8 Jun 2015 07:57:42 -0700 (PDT) In-Reply-To: <20150608143100.GD29788@elstar.local> References: <20150608.102005.1482395931170643204.mbj@tail-f.com> <20150608094708.GA28936@elstar.local> <20150608143100.GD29788@elstar.local> Date: Mon, 8 Jun 2015 07:57:42 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Martin Bjorklund , Netconf Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Netconf] YANG Patch Issue #3: :distinct-startup X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 14:57:48 -0000 On Mon, Jun 8, 2015 at 7:31 AM, Juergen Schoenwaelder wrote: > On Mon, Jun 08, 2015 at 07:18:28AM -0700, Andy Bierman wrote: >> On Mon, Jun 8, 2015 at 2:47 AM, Juergen Schoenwaelder >> wrote: >> > On Mon, Jun 08, 2015 at 02:31:56AM -0700, Andy Bierman wrote: >> >> Hi, >> >> >> >> Perhaps this is a RESTCONF issue. >> >> It has not been accepted as an open issue. >> >> IMO this can be left out. >> >> RESTCONF has a unified datastore. >> >> For access to individual datastores, use NETCONF. >> >> >> > >> > Looking at section 1.3 of draft-ietf-netconf-restconf-05, should the >> > text be more explicit about the details? I mean, if the candidate is >> > used, is it cleared first or do any pending edits in candidate become >> > part of the commit? Is a server supporting both NETCONF and RESTCONF >> > going to use locks on or during the processing >> > of a RESTCONF edit or is that left up to the implementor to decide? >> > >> >> It works justlike like NETCONF. >> If the candidate is unlocked and dirty, the pending edits get >> committed. > > I think this should be mentioned to avoid surprises. > >> > Is the copy to startup something that happens after each edit? This >> > may be pretty expensive if a RESTCONF client is pushing many small >> > edits in a loop (not unlikely that we see such clients I would say). >> >> There were multiple proposals suggested to the WG to add a query >> parameter to control nv-save. The WG was not interested >> in any of them. Use NETCONF to access the individual datastores. >> RESTCONF has no direct access to any NETCONF datastores. > > I am interested in what I can expect from a RESTCONF server. If every > RESTCONF edit causes an NV write (and this is how I read the current > text), then my performance expectations are likely a down to NV write > speed. On some of my boxes, this is really slow. Hence, my expectation > is that implementors will cheat a bit and do delayed writes (but then > I never know when something really got written). > Then it might be better to use NETCONF without :distinct-startup, so there is no requirement to ever save the running datastore to non-volatile storage. If startup can be different than running, then the client needs to retrieve running and startup and compare them. Individual datastore access could be added in another RFC and include startup. > /js > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Mon Jun 8 08:14:06 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E061B2E90 for ; Mon, 8 Jun 2015 08:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Imj3BE3ei8ZJ for ; Mon, 8 Jun 2015 08:14:02 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B3CF1B2EB3 for ; Mon, 8 Jun 2015 08:11:10 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C5CEC10FB; Mon, 8 Jun 2015 17:11:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id pO0hqPFYzHSi; Mon, 8 Jun 2015 17:11:07 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 8 Jun 2015 17:11:07 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5030120013; Mon, 8 Jun 2015 17:11:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id JfMM1xN4nURf; Mon, 8 Jun 2015 17:11:02 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 774A22002C; Mon, 8 Jun 2015 17:11:05 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 129EB3442D8C; Mon, 8 Jun 2015 17:11:03 +0200 (CEST) Date: Mon, 8 Jun 2015 17:11:02 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20150608151059.GB30068@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , Netconf References: <20150608.102005.1482395931170643204.mbj@tail-f.com> <20150608094708.GA28936@elstar.local> <20150608143100.GD29788@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Netconf Subject: Re: [Netconf] YANG Patch Issue #3: :distinct-startup X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 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, 08 Jun 2015 15:14:04 -0000 On Mon, Jun 08, 2015 at 07:57:42AM -0700, Andy Bierman wrote: > On Mon, Jun 8, 2015 at 7:31 AM, Juergen Schoenwaelder > wrote: > > On Mon, Jun 08, 2015 at 07:18:28AM -0700, Andy Bierman wrote: > >> On Mon, Jun 8, 2015 at 2:47 AM, Juergen Schoenwaelder > >> wrote: > >> > On Mon, Jun 08, 2015 at 02:31:56AM -0700, Andy Bierman wrote: > >> >> Hi, > >> >> > >> >> Perhaps this is a RESTCONF issue. > >> >> It has not been accepted as an open issue. > >> >> IMO this can be left out. > >> >> RESTCONF has a unified datastore. > >> >> For access to individual datastores, use NETCONF. > >> >> > >> > > >> > Looking at section 1.3 of draft-ietf-netconf-restconf-05, should the > >> > text be more explicit about the details? I mean, if the candidate is > >> > used, is it cleared first or do any pending edits in candidate become > >> > part of the commit? Is a server supporting both NETCONF and RESTCONF > >> > going to use locks on or during the processing > >> > of a RESTCONF edit or is that left up to the implementor to decide? > >> > > >> > >> It works justlike like NETCONF. > >> If the candidate is unlocked and dirty, the pending edits get > >> committed. > > > > I think this should be mentioned to avoid surprises. > > > >> > Is the copy to startup something that happens after each edit? This > >> > may be pretty expensive if a RESTCONF client is pushing many small > >> > edits in a loop (not unlikely that we see such clients I would say). > >> > >> There were multiple proposals suggested to the WG to add a query > >> parameter to control nv-save. The WG was not interested > >> in any of them. Use NETCONF to access the individual datastores. > >> RESTCONF has no direct access to any NETCONF datastores. > > > > I am interested in what I can expect from a RESTCONF server. If every > > RESTCONF edit causes an NV write (and this is how I read the current > > text), then my performance expectations are likely a down to NV write > > speed. On some of my boxes, this is really slow. Hence, my expectation > > is that implementors will cheat a bit and do delayed writes (but then > > I never know when something really got written). > > Then it might be better to use NETCONF without :distinct-startup, > so there is no requirement to ever save the running datastore > to non-volatile storage. I do want to safe to non-volatile storage and I am concerned about the performance if every RESTCONF edit goes to NV storage on its own. /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 Jun 8 08:19:30 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 771551B2E8F for ; Mon, 8 Jun 2015 08:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y_XTF7hPPpqH for ; Mon, 8 Jun 2015 08:19:27 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0743.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::743]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 706C41A9034 for ; Mon, 8 Jun 2015 08:19:26 -0700 (PDT) Received: from BN1PR05MB456.namprd05.prod.outlook.com (10.141.59.26) by BN1PR05MB453.namprd05.prod.outlook.com (10.141.59.11) with Microsoft SMTP Server (TLS) id 15.1.172.22; Mon, 8 Jun 2015 15:19:09 +0000 Received: from BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.222]) by BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.222]) with mapi id 15.01.0172.012; Mon, 8 Jun 2015 15:19:09 +0000 From: Kent Watsen To: Juergen Schoenwaelder , "Martin Bjorklund" Thread-Topic: [Netconf] server-model #49: combine trusted-ca-certs and trusted-client-certs for ssh/tls? Thread-Index: AQHQkbgnBncK8ydKj0azKXFdHxn5752Zo96AgAeProCAARR5gIAAV3kAgAAEv4D///IvAA== Date: Mon, 8 Jun 2015 15:19:09 +0000 Message-ID: References: <20150608063828.GB28037@elstar.local> <20150608.135134.815056002069146319.mbj@tail-f.com> <20150608120832.GB29405@elstar.local> In-Reply-To: <20150608120832.GB29405@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.12] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB453; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:BN1PR05MB453; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB453; x-forefront-prvs: 060166847D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(102836002)(83506001)(5001770100001)(77156002)(2656002)(66066001)(4001350100001)(62966003)(5001960100002)(189998001)(2900100001)(2950100001)(93886004)(99286002)(106116001)(36756003)(92566002)(54356999)(5002640100001)(87936001)(230783001)(46102003)(86362001)(40100003)(50986999)(76176999)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB453; H:BN1PR05MB456.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <5CD761AE3DD09B4F93A1D4E78FE25E6E@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2015 15:19:09.1130 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB453 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] server-model #49: combine trusted-ca-certs and trusted-client-certs for ssh/tls? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 15:19:28 -0000 > I actually think #4 is broken since it requires updates that I think >violate YANG update rules I couldn't find specific language that prevented it. I was hoping that it might be allowed since the syntax/semantics would remain the same... > nor do I understand why something that was a string suddenly becomes >conditional via an if-feature. This was a copy/paste error, OPTION 4 should've been: Now: container trusted-ca-certs { leaf-list trusted-ca-cert { type string; description "key to some list of certs"; } } container server-certificates { leaf-list server-certificate { type string; description "key to some list of certs"; } } Later: container trusted-ca-certs { leaf-list trusted-ca-cert { type leafref { path "/kc:server-certificates/kc:server-certificate/kc:name"; } } } container server-certificates { leaf-list server-certificate { type leafref { path "/kc:trust-anchors/kc:trust-anchor/kc:name"; } } } From nobody Mon Jun 8 08:27:19 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3A881B2EEF for ; Mon, 8 Jun 2015 08:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vzx98TXADCRH for ; Mon, 8 Jun 2015 08:27:16 -0700 (PDT) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D7FC1B2F02 for ; Mon, 8 Jun 2015 08:27:15 -0700 (PDT) Received: by lbbqq2 with SMTP id qq2so83085648lbb.3 for ; Mon, 08 Jun 2015 08:27:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=WXqm2a6JhZdUp3kq7Pbbi4GCdLVB+RK+A7Qj0uLrmYo=; b=a2lGnlxqc+9C28VnUp6F41s1GPCFitWhfmWojoaBzhMjBnDORt82IM0wRBrSNn7N70 20l6D+4iht1x/b2oGZE3m7T+sgaDed46tkR9KSOziQFwLKwvZpfkUqb1OBg8LJrSNtOH ALHtDKErVe7hATN3QJ2DpotlTKS+oh1XCsdND2lHHzptN9fYKH6rxoxOl8AgieCqEdDe Sy501U4r8U5+fdh5pfblgTJ5dGtjUNuxtSDe+mS3/5ByU+mwpPI0f3i/i2hBBbJPfE5m T7bIBS6kKuDD6f70siGc9+E0u77323HJvJRsXuSqEFJ7NJ2seYO5stghuQFFdkvgirLg By8g== X-Gm-Message-State: ALoCoQl2bCh4z1N4REbP4F6s1jb3bCfqswmf0hAOUvGu4SR6uGVL+GtIsRv0QYE1/AbwC/t2bbbn MIME-Version: 1.0 X-Received: by 10.152.36.161 with SMTP id r1mr17465970laj.88.1433777233524; Mon, 08 Jun 2015 08:27:13 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Mon, 8 Jun 2015 08:27:13 -0700 (PDT) In-Reply-To: <20150608151059.GB30068@elstar.local> References: <20150608.102005.1482395931170643204.mbj@tail-f.com> <20150608094708.GA28936@elstar.local> <20150608143100.GD29788@elstar.local> <20150608151059.GB30068@elstar.local> Date: Mon, 8 Jun 2015 08:27:13 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Martin Bjorklund , Netconf Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Netconf] YANG Patch Issue #3: :distinct-startup X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 15:27:18 -0000 On Mon, Jun 8, 2015 at 8:11 AM, Juergen Schoenwaelder wrote: > On Mon, Jun 08, 2015 at 07:57:42AM -0700, Andy Bierman wrote: >> On Mon, Jun 8, 2015 at 7:31 AM, Juergen Schoenwaelder >> wrote: >> > On Mon, Jun 08, 2015 at 07:18:28AM -0700, Andy Bierman wrote: >> >> On Mon, Jun 8, 2015 at 2:47 AM, Juergen Schoenwaelder >> >> wrote: >> >> > On Mon, Jun 08, 2015 at 02:31:56AM -0700, Andy Bierman wrote: >> >> >> Hi, >> >> >> >> >> >> Perhaps this is a RESTCONF issue. >> >> >> It has not been accepted as an open issue. >> >> >> IMO this can be left out. >> >> >> RESTCONF has a unified datastore. >> >> >> For access to individual datastores, use NETCONF. >> >> >> >> >> > >> >> > Looking at section 1.3 of draft-ietf-netconf-restconf-05, should the >> >> > text be more explicit about the details? I mean, if the candidate is >> >> > used, is it cleared first or do any pending edits in candidate become >> >> > part of the commit? Is a server supporting both NETCONF and RESTCONF >> >> > going to use locks on or during the processing >> >> > of a RESTCONF edit or is that left up to the implementor to decide? >> >> > >> >> >> >> It works justlike like NETCONF. >> >> If the candidate is unlocked and dirty, the pending edits get >> >> committed. >> > >> > I think this should be mentioned to avoid surprises. >> > >> >> > Is the copy to startup something that happens after each edit? This >> >> > may be pretty expensive if a RESTCONF client is pushing many small >> >> > edits in a loop (not unlikely that we see such clients I would say). >> >> >> >> There were multiple proposals suggested to the WG to add a query >> >> parameter to control nv-save. The WG was not interested >> >> in any of them. Use NETCONF to access the individual datastores. >> >> RESTCONF has no direct access to any NETCONF datastores. >> > >> > I am interested in what I can expect from a RESTCONF server. If every >> > RESTCONF edit causes an NV write (and this is how I read the current >> > text), then my performance expectations are likely a down to NV write >> > speed. On some of my boxes, this is really slow. Hence, my expectation >> > is that implementors will cheat a bit and do delayed writes (but then >> > I never know when something really got written). >> >> Then it might be better to use NETCONF without :distinct-startup, >> so there is no requirement to ever save the running datastore >> to non-volatile storage. > > I do want to safe to non-volatile storage and I am concerned about the > performance if every RESTCONF edit goes to NV storage on its own. > This is what NETCONF servers actually do if there is no startup config. I agree this can be slow. I made a proposal to address the NV-storage (nv-save=true|false) but not retrieval of the startup datastore. > /js Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Mon Jun 8 11:29:36 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E60A71A8A94 for ; Mon, 8 Jun 2015 11:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cboxEsN-azHV for ; Mon, 8 Jun 2015 11:29:31 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C2661A899B for ; Mon, 8 Jun 2015 11:29:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8531; q=dns/txt; s=iport; t=1433788172; x=1434997772; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TQxUpP55W0yaRlXKfTNycBkIEuJ3cEYFA/+w+yUcFr0=; b=htsINP4U5Sdsn27zEqU5Oye9W7JcV6v5nbU+AVPbOPhlGoxeVGxtPrUB Eo8RYr4xx3hW6wZ+zRdP8Qt3uqeM8Bo+gvSR3jBttDU1CJT0JlKJTkbvk WJnN3N+KbXSkplx4npd4PK6rVZeggETc9OyxEpsh4K8yfKm1TcnVZmlAo M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AaBQDE3nVV/51dJa1ZA4MQVF4GvniBUwqFL0oCgSs6EgEBAQEBAQGBCoQiAQEBBAEBATc0CwwCAgIBCBABBAEBAQoDEQkHGwwLFAkIAgQBCQQFCIglDc1oAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwSLP4E9gn4aIRAHBguDBoEWBZMujFmGeYVPhg2DWSSCOoE9b4FGgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,574,1427760000"; d="scan'208";a="157339502" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-2.cisco.com with ESMTP; 08 Jun 2015 18:29:10 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t58IT9l0022032 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Jun 2015 18:29:09 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.172]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Mon, 8 Jun 2015 13:29:09 -0500 From: "Alexander Clemm (alex)" To: Mandy Liu , Andy Bierman Thread-Topic: [Netconf] How to augment RFC6470 to supply detail configuration change information Thread-Index: AdCcN15yUJGf8sjGSmOLzB5x9r0SxwALruGAAADNVoAABGdGAAAq3o+AAADiWQAAARHiAAEN1qeAABNvNIAAGS/MQA== Date: Mon, 8 Jun 2015 18:29:09 +0000 Message-ID: References: <20150601072552.GA31467@elstar.local> <20150601095456.GD31801@elstar.local> <20150602064743.GA66363@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.204.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Roy Finlay , "andy@netconfcentral.org" , Robert Ottinger , Athanasios Kyparlis , Kai Lin , Victor Santos , "netconf@ietf.org" Subject: Re: [Netconf] How to augment RFC6470 to supply detail configuration change information X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 18:29:34 -0000 Hi, one follow-on question regarding item 2 that Andy mentions: I am not sure = what unreliable transport has to do with leaving out data from the config-c= hange event? Those seem to be separate, orthogonal issues. (Obviously, if= you want to rely on notifications to "stay on top" of configuration change= s, you need a reliability mechanism. But this does not explain why you omit= data from the payload.) =20 --- Alex -----Original Message----- From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Mandy Liu Sent: Sunday, June 07, 2015 6:21 PM To: Andy Bierman Cc: Robert Ottinger; andy@netconfcentral.org; Roy Finlay; Athanasios Kyparl= is; Kai Lin; Victor Santos; netconf@ietf.org Subject: Re: [Netconf] How to augment RFC6470 to supply detail configuratio= n change information Thanks for your important information, Andy! + Roy and Victor. Hi Roy and Victor, Andy shared some important information about " why the 'data' was left out = of the netconf-config-change event" with us. FYI. Regards, Mandy -----Original Message----- From: Andy Bierman [mailto:andy@yumaworks.com] Sent: Monday, June 08, 2015 12:05 AM To: Mandy Liu Cc: Juergen Schoenwaelder; andy@netconfcentral.org; Kai Lin; Robert Ottinge= r; netconf@ietf.org; Athanasios Kyparlis Subject: Re: [Netconf] How to augment RFC6470 to supply detail configuratio= n change information Hi, There are (at least) 2 technical issues you should consider, in case you ar= e wondering why the 'data' was left out of the netconf-config-change event. 1) Access control is effectively disabled by copying config nodes into an '= anyxml' container within a notification. Sensitive data like passwords can= be transferred to a client without read privilege for that data. 2) NETCONF notifications may not be reliable. Replay is optional to implement. RFC 5277 is silent about transport requir= ements for notification delivery. For example if the receiver is blocked so that notifications cannot be sent= on a subscription session, a server with finite resources will eventually = be unable to store new events. There is one mention of resources in the RFC, wrt/ replay: The actual number of stored notifications available for retrieval at any given time is a NETCONF server implementation-specific matter. Control parameters for this aspect of the feature are outside the scope of this document. Note that notifications can not be retrieved in NETCONF. This text should say "available for delivery". Notifications do not have sequence identifiers. There is no way for a client to tell if a notification was dropped by the s= erver. Andy On Tue, Jun 2, 2015 at 12:18 AM, Mandy Liu wrote: > I am not intent to insist that. I just want to make sure it won't violate= RFC6020. I think you have convinced me by below sentence. Thanks for your = support, Juergen! > - "But it is not the writable configuration data but more a copy of the c= onfiguration data that got changed." > > Regards, > Mandy > > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Tuesday, June 02, 2015 2:48 PM > To: Mandy Liu > Cc: andy@netconfcentral.org; Kai Lin; Robert Ottinger;=20 > netconf@ietf.org; Athanasios Kyparlis > Subject: Re: [Netconf] How to augment RFC6470 to supply detail=20 > configuration change information > > But it is not the writable configuration data but more a copy of the conf= iguration data that got changed. Anyway, if you want to insist that this is= a violation of section 7.10 of RFC6020, then don't do it. I do not believe= it is a violation of section 7.10 of RFC6020. > > /js > > On Tue, Jun 02, 2015 at 06:22:25AM +0000, Mandy Liu wrote: >> Ok, thanks! Got your point. >> But here I want to use "data" to address the changed configuration data = in the notification. Although "data" is in the notification, but because it= is used to address the configuration data seems it still conflicts with th= e statement in section 7.10 of RFC6020 "it is RECOMMENDED that the "anyxml"= statement not be used to represent configuration data. " >> >> list edit { >> leaf target { >> type instance-identifier; >> description >> ..... >> } >> leaf operation { >> type nc:edit-operation-type; >> description >> ..... >> } >> anyxml data; >> } >> >> Regards, >> Mandy >> >> -----Original Message----- >> From: Juergen Schoenwaelder >> [mailto:j.schoenwaelder@jacobs-university.de] >> Sent: Monday, June 01, 2015 5:55 PM >> To: Mandy Liu >> Cc: andy@netconfcentral.org; Kai Lin; Robert Ottinger;=20 >> netconf@ietf.org; Athanasios Kyparlis >> Subject: Re: [Netconf] How to augment RFC6470 to supply detail=20 >> configuration change information >> >> Let me try to say it differently: Using anyxml in a notification does no= t cause a conflict with this statement in section 7.10 of RFC 6020: >> >> Since the use of anyxml limits the manipulation of the content, it is >> RECOMMENDED that the "anyxml" statement not be used to represent >> configuration data. >> >> Note that configuration data is defined as follows: >> >> o configuration data: The set of writable data that is required to >> transform a system from its initial default state into its current >> state [RFC4741]. >> >> Notification content is not configuration data. >> >> /js >> >> On Mon, Jun 01, 2015 at 07:48:51AM +0000, Mandy Liu wrote: >> > Sorry, I don't get your point. But hopefully I addressed my question m= ore clearly this time. >> > >> > The configuration change notification is generated when the NETCONF se= rver detects that the or configuration datastore has be= en changed by a management session. The notification summarizes the "edits"= that have been detected. " The structure of the "edit" is addressed in RF= C6470 as below. What I want is to add the another leaf to address the "targ= et" is changed to what. But because the "target" may be a container, a list= , a leaf or a leaf-reference, etc. It could be any node of the tree. So a c= ommon format for addressing the "target" is changed to what is needed. >> > list edit { >> > leaf target { >> > type instance-identifier; >> > description >> > ..... >> > } >> > leaf operation { >> > type nc:edit-operation-type; >> > description >> > ..... >> > } >> > } >> > >> > Thanks, >> > Mandy >> > -----Original Message----- >> > From: Juergen Schoenwaelder >> > [mailto:j.schoenwaelder@jacobs-university.de] >> > Sent: Monday, June 01, 2015 3:26 PM >> > To: Mandy Liu >> > Cc: andy@netconfcentral.org; Kai Lin; Robert Ottinger;=20 >> > netconf@ietf.org; Athanasios Kyparlis >> > Subject: Re: [Netconf] How to augment RFC6470 to supply detail=20 >> > configuration change information >> > >> > On Mon, Jun 01, 2015 at 06:51:27AM +0000, Mandy Liu wrote: >> > >> > > [...] So we need to find a common format for the "content" to=20 >> > > accommodate different types of "target". what I can imagine is=20 >> > > anyxml could be used. But seems it is not a good choice. Because=20 >> > > based on RFC6020, it is not recommended to be used on configuration = data. >> > >> > Since you plan to augment a notification, this won't be config true da= ta (this is what the statement in RFC 6020 really hints at). See also the d= efinition of 'configuration data' in section 3 of RFC 6020. >> > >> > /js >> > >> > -- >> > Juergen Schoenwaelder Jacobs University Bremen gGmbH >> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> > Fax: +49 421 200 3103 >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> Fax: +49 421 200 3103 > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From nobody Mon Jun 8 12:06:43 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2439F1B31CF for ; Mon, 8 Jun 2015 12:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mSj1B1tPaaX for ; Mon, 8 Jun 2015 12:06:38 -0700 (PDT) Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF8D91B31D0 for ; Mon, 8 Jun 2015 12:06:37 -0700 (PDT) Received: by lbbqq2 with SMTP id qq2so86755598lbb.3 for ; Mon, 08 Jun 2015 12:06:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Z7Zk2jPTYCkL/LYiiJdFPTp2YH6X3qz/2Bvwk4WggEo=; b=VWhvb/xifG9ZMKt7Hzf0NspCWIAoIQwsBJ6UnSVTWqTC2ZyvgzmAGnJsL/lh8djtww te/IvX5A+qeMFLMtXFf426rXCv2zPRY2ZyHfrIw7+vfW7AmpZ0b4Mfuwua19psUbzUl5 UFHuEI0c3hZG/G+gdnQs2EQr/K4LUraPsvsDW2ruMiAO3tnis178TFXLgZBq8/X0W0bM YkeLezNG77Ws8583jMbnAjXKplCsyKUTD5bKMI3efxgXUfEZLNigngbSQGPZG7faQCsT Ge18mG+acWdydI3lnqYuNQhRDEHDt20DMhTAASGtpJY6l7U3gIq+MsUTLjepZ0WvX5tb 5USw== X-Gm-Message-State: ALoCoQnkQ9gQx7Tm07wj3fD/KCYimE4ifVMCJsEFRWSZpKDsrKT9tjaHI28krRH/km9xOGYQ1aXL MIME-Version: 1.0 X-Received: by 10.112.164.66 with SMTP id yo2mr18780469lbb.33.1433790395941; Mon, 08 Jun 2015 12:06:35 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Mon, 8 Jun 2015 12:06:35 -0700 (PDT) In-Reply-To: References: <20150601072552.GA31467@elstar.local> <20150601095456.GD31801@elstar.local> <20150602064743.GA66363@elstar.local> Date: Mon, 8 Jun 2015 12:06:35 -0700 Message-ID: From: Andy Bierman To: "Alexander Clemm (alex)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Roy Finlay , Mandy Liu , "andy@netconfcentral.org" , Robert Ottinger , Athanasios Kyparlis , Kai Lin , Victor Santos , "netconf@ietf.org" Subject: Re: [Netconf] How to augment RFC6470 to supply detail configuration change information X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 19:06:41 -0000 On Mon, Jun 8, 2015 at 11:29 AM, Alexander Clemm (alex) wr= ote: > Hi, > > one follow-on question regarding item 2 that Andy mentions: I am not sur= e what unreliable transport has to do with leaving out data from the config= -change event? Those seem to be separate, orthogonal issues. (Obviously, = if you want to rely on notifications to "stay on top" of configuration chan= ges, you need a reliability mechanism. But this does not explain why you om= it data from the payload.) > Access control cannot be enforced. The WG also wanted to minimize the size of the notification. Using the netconf-config-change to replicate a datastore would work OK if you add a sequence-id for netconf-config-change events. That way if your replication client detects a gap in the sequencing, it can do a to re-sync. > --- Alex Andy > > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Mandy Liu > Sent: Sunday, June 07, 2015 6:21 PM > To: Andy Bierman > Cc: Robert Ottinger; andy@netconfcentral.org; Roy Finlay; Athanasios Kypa= rlis; Kai Lin; Victor Santos; netconf@ietf.org > Subject: Re: [Netconf] How to augment RFC6470 to supply detail configurat= ion change information > > Thanks for your important information, Andy! > + Roy and Victor. > > Hi Roy and Victor, > > Andy shared some important information about " why the 'data' was left ou= t of the netconf-config-change event" with us. FYI. > > Regards, > Mandy > > -----Original Message----- > From: Andy Bierman [mailto:andy@yumaworks.com] > Sent: Monday, June 08, 2015 12:05 AM > To: Mandy Liu > Cc: Juergen Schoenwaelder; andy@netconfcentral.org; Kai Lin; Robert Ottin= ger; netconf@ietf.org; Athanasios Kyparlis > Subject: Re: [Netconf] How to augment RFC6470 to supply detail configurat= ion change information > > Hi, > > There are (at least) 2 technical issues you should consider, in case you = are wondering why the 'data' was left out of the netconf-config-change even= t. > > 1) Access control is effectively disabled by copying config nodes into an= 'anyxml' container within a notification. Sensitive data like passwords c= an be transferred to a client without read privilege for that data. > > 2) NETCONF notifications may not be reliable. > Replay is optional to implement. RFC 5277 is silent about transport requ= irements for notification delivery. > > For example if the receiver is blocked so that notifications cannot be se= nt on a subscription session, a server with finite resources will eventuall= y be unable to store new events. > > There is one mention of resources in the RFC, wrt/ replay: > > The actual number of stored notifications available for retrieval at > any given time is a NETCONF server implementation-specific matter. > Control parameters for this aspect of the feature are outside the > scope of this document. > > Note that notifications can not be retrieved in NETCONF. > This text should say "available for delivery". > > Notifications do not have sequence identifiers. > There is no way for a client to tell if a notification was dropped by the= server. > > > Andy > > > On Tue, Jun 2, 2015 at 12:18 AM, Mandy Liu wrote= : >> I am not intent to insist that. I just want to make sure it won't violat= e RFC6020. I think you have convinced me by below sentence. Thanks for your= support, Juergen! >> - "But it is not the writable configuration data but more a copy of the = configuration data that got changed." >> >> Regards, >> Mandy >> >> -----Original Message----- >> From: Juergen Schoenwaelder >> [mailto:j.schoenwaelder@jacobs-university.de] >> Sent: Tuesday, June 02, 2015 2:48 PM >> To: Mandy Liu >> Cc: andy@netconfcentral.org; Kai Lin; Robert Ottinger; >> netconf@ietf.org; Athanasios Kyparlis >> Subject: Re: [Netconf] How to augment RFC6470 to supply detail >> configuration change information >> >> But it is not the writable configuration data but more a copy of the con= figuration data that got changed. Anyway, if you want to insist that this i= s a violation of section 7.10 of RFC6020, then don't do it. I do not believ= e it is a violation of section 7.10 of RFC6020. >> >> /js >> >> On Tue, Jun 02, 2015 at 06:22:25AM +0000, Mandy Liu wrote: >>> Ok, thanks! Got your point. >>> But here I want to use "data" to address the changed configuration data= in the notification. Although "data" is in the notification, but because i= t is used to address the configuration data seems it still conflicts with t= he statement in section 7.10 of RFC6020 "it is RECOMMENDED that the "anyxml= " statement not be used to represent configuration data. " >>> >>> list edit { >>> leaf target { >>> type instance-identifier; >>> description >>> ..... >>> } >>> leaf operation { >>> type nc:edit-operation-type; >>> description >>> ..... >>> } >>> anyxml data; >>> } >>> >>> Regards, >>> Mandy >>> >>> -----Original Message----- >>> From: Juergen Schoenwaelder >>> [mailto:j.schoenwaelder@jacobs-university.de] >>> Sent: Monday, June 01, 2015 5:55 PM >>> To: Mandy Liu >>> Cc: andy@netconfcentral.org; Kai Lin; Robert Ottinger; >>> netconf@ietf.org; Athanasios Kyparlis >>> Subject: Re: [Netconf] How to augment RFC6470 to supply detail >>> configuration change information >>> >>> Let me try to say it differently: Using anyxml in a notification does n= ot cause a conflict with this statement in section 7.10 of RFC 6020: >>> >>> Since the use of anyxml limits the manipulation of the content, it i= s >>> RECOMMENDED that the "anyxml" statement not be used to represent >>> configuration data. >>> >>> Note that configuration data is defined as follows: >>> >>> o configuration data: The set of writable data that is required to >>> transform a system from its initial default state into its curren= t >>> state [RFC4741]. >>> >>> Notification content is not configuration data. >>> >>> /js >>> >>> On Mon, Jun 01, 2015 at 07:48:51AM +0000, Mandy Liu wrote: >>> > Sorry, I don't get your point. But hopefully I addressed my question = more clearly this time. >>> > >>> > The configuration change notification is generated when the NETCONF s= erver detects that the or configuration datastore has b= een changed by a management session. The notification summarizes the "edits= " that have been detected. " The structure of the "edit" is addressed in R= FC6470 as below. What I want is to add the another leaf to address the "tar= get" is changed to what. But because the "target" may be a container, a lis= t, a leaf or a leaf-reference, etc. It could be any node of the tree. So a = common format for addressing the "target" is changed to what is needed. >>> > list edit { >>> > leaf target { >>> > type instance-identifier; >>> > description >>> > ..... >>> > } >>> > leaf operation { >>> > type nc:edit-operation-type; >>> > description >>> > ..... >>> > } >>> > } >>> > >>> > Thanks, >>> > Mandy >>> > -----Original Message----- >>> > From: Juergen Schoenwaelder >>> > [mailto:j.schoenwaelder@jacobs-university.de] >>> > Sent: Monday, June 01, 2015 3:26 PM >>> > To: Mandy Liu >>> > Cc: andy@netconfcentral.org; Kai Lin; Robert Ottinger; >>> > netconf@ietf.org; Athanasios Kyparlis >>> > Subject: Re: [Netconf] How to augment RFC6470 to supply detail >>> > configuration change information >>> > >>> > On Mon, Jun 01, 2015 at 06:51:27AM +0000, Mandy Liu wrote: >>> > >>> > > [...] So we need to find a common format for the "content" to >>> > > accommodate different types of "target". what I can imagine is >>> > > anyxml could be used. But seems it is not a good choice. Because >>> > > based on RFC6020, it is not recommended to be used on configuration= data. >>> > >>> > Since you plan to augment a notification, this won't be config true d= ata (this is what the statement in RFC 6020 really hints at). See also the = definition of 'configuration data' in section 3 of RFC 6020. >>> > >>> > /js >>> > >>> > -- >>> > Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | German= y >>> > Fax: +49 421 200 3103 >>> >>> -- >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>> Fax: +49 421 200 3103 >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> Fax: +49 421 200 3103 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Mon Jun 8 13:07:28 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC271B322B for ; Mon, 8 Jun 2015 13:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4bS1mmNGf5m for ; Mon, 8 Jun 2015 13:07:25 -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 0221F1B3216 for ; Mon, 8 Jun 2015 13:07:05 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7E6D01257; Mon, 8 Jun 2015 22:07: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 YLBeft3_7cZO; Mon, 8 Jun 2015 22:07:02 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 8 Jun 2015 22:07:02 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id B5E932002B; Mon, 8 Jun 2015 22:07:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id zbS-XKcUsiLV; Mon, 8 Jun 2015 22:06:57 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A29DE20013; Mon, 8 Jun 2015 22:07:01 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 53AF73444073; Mon, 8 Jun 2015 22:06:59 +0200 (CEST) Date: Mon, 8 Jun 2015 22:06:58 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20150608200657.GA30988@elstar.local> Mail-Followup-To: Andy Bierman , "Alexander Clemm (alex)" , "netconf@ietf.org" References: <20150601072552.GA31467@elstar.local> <20150601095456.GD31801@elstar.local> <20150602064743.GA66363@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] How to augment RFC6470 to supply detail configuration change information X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 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, 08 Jun 2015 20:07:27 -0000 On Mon, Jun 08, 2015 at 12:06:35PM -0700, Andy Bierman wrote: > Using the netconf-config-change to replicate a datastore > would work OK if you add a sequence-id for netconf-config-change > events. That way if your replication client detects a gap in > the sequencing, it can do a to re-sync. This reminds me after several years we still do not have a simple version number or version hash for the configuration itself. We should eventually fix this, no? /js PS: I have removed lots of email addresses, I assume people interested are on the list anyway. ;-) -- 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 Jun 8 13:15:15 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC5F1AC44D for ; Mon, 8 Jun 2015 13:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfsUDfbMa3-e for ; Mon, 8 Jun 2015 13:15:11 -0700 (PDT) Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 777A71A92FE for ; Mon, 8 Jun 2015 13:15:11 -0700 (PDT) Received: by labpy14 with SMTP id py14so105292297lab.0 for ; Mon, 08 Jun 2015 13:15:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=DfHJL1xm6Wmz7vD4rTfYqV9R5yOSoZD/yzj67aJH2rg=; b=TJWInY/rEpGeRYHjQIC5O9h9hjC3GhcM8StgtONf1Kxu64MuJeNksmWKTiDQ7vrOgI DzXJ8SSfKWS14ClIpwcUXSEf1HZfN+s6+whlFzOqoIc6jD6IXUj5Ql/6C7zTggORh5Vx LLMlpM7tVfmg3hxFMYqR2rOVPXBFaHv+H7d/oHkylo4OUfs4Rb+O0awfBsZ6bykyCMPU XX/1gI3sqmkoKTCz1Z25tfsPbfNdijTxtn/7m4X63bdP0InIFY6G0fqPmMW4e0s7a9FJ imnQKPHCCXnIis2C08UehLBiCIR2yc7laa0tVcCiuBH0yPepx2KdPjlPuVwKtlcj4d64 dshQ== X-Gm-Message-State: ALoCoQnwUK0HPMKNKrSx1iOOSe5AgGpm4hn+wCnLmz1L2tF7kj/a+Q+iTUCHupXyXimoPDl2tjTh MIME-Version: 1.0 X-Received: by 10.152.36.161 with SMTP id r1mr19017490laj.88.1433794509926; Mon, 08 Jun 2015 13:15:09 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Mon, 8 Jun 2015 13:15:09 -0700 (PDT) In-Reply-To: <20150608200657.GA30988@elstar.local> References: <20150601072552.GA31467@elstar.local> <20150601095456.GD31801@elstar.local> <20150602064743.GA66363@elstar.local> <20150608200657.GA30988@elstar.local> Date: Mon, 8 Jun 2015 13:15:09 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , "Alexander Clemm (alex)" , "netconf@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Netconf] How to augment RFC6470 to supply detail configuration change information X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 20:15:14 -0000 On Mon, Jun 8, 2015 at 1:06 PM, Juergen Schoenwaelder wrote: > On Mon, Jun 08, 2015 at 12:06:35PM -0700, Andy Bierman wrote: > >> Using the netconf-config-change to replicate a datastore >> would work OK if you add a sequence-id for netconf-config-change >> events. That way if your replication client detects a gap in >> the sequencing, it can do a to re-sync. > > This reminds me after several years we still do not have a simple > version number or version hash for the configuration itself. We > should eventually fix this, no? > This was in NETCONF Efficiency Extensions. We support the "config-id" capability in our server. An ETag for the entire config is required for RESTCONF. > /js Andy > > PS: I have removed lots of email addresses, I assume people interested > are on the list anyway. ;-) > > -- > 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 Jun 8 13:20:08 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B04A81B32ED for ; Mon, 8 Jun 2015 13:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pTLlZRfm3qV for ; Mon, 8 Jun 2015 13:20: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 AF2FC1B32F5 for ; Mon, 8 Jun 2015 13:20: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 5E652FA0; Mon, 8 Jun 2015 22:20:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id mHPJqwUBfJQY; Mon, 8 Jun 2015 22:20:01 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 8 Jun 2015 22:20:02 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0451D2002B; Mon, 8 Jun 2015 22:20:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id xp3QtRvbgnKK; Mon, 8 Jun 2015 22:20:05 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BB09720013; Mon, 8 Jun 2015 22:20:00 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 872D63444167; Mon, 8 Jun 2015 22:19:59 +0200 (CEST) Date: Mon, 8 Jun 2015 22:19:58 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20150608201956.GA31069@elstar.local> Mail-Followup-To: Andy Bierman , "Alexander Clemm (alex)" , "netconf@ietf.org" References: <20150601095456.GD31801@elstar.local> <20150602064743.GA66363@elstar.local> <20150608200657.GA30988@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] How to augment RFC6470 to supply detail configuration change information X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 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, 08 Jun 2015 20:20:06 -0000 On Mon, Jun 08, 2015 at 01:15:09PM -0700, Andy Bierman wrote: > On Mon, Jun 8, 2015 at 1:06 PM, Juergen Schoenwaelder > wrote: > > On Mon, Jun 08, 2015 at 12:06:35PM -0700, Andy Bierman wrote: > > > >> Using the netconf-config-change to replicate a datastore > >> would work OK if you add a sequence-id for netconf-config-change > >> events. That way if your replication client detects a gap in > >> the sequencing, it can do a to re-sync. > > > > This reminds me after several years we still do not have a simple > > version number or version hash for the configuration itself. We > > should eventually fix this, no? > > > This was in NETCONF Efficiency Extensions. > We support the "config-id" capability in our server. > An ETag for the entire config is required for RESTCONF. > As I said, we talked about it several times - can we eventually make it a standard (that works for NC, RC, and friends equally well)? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jun 8 19:58:05 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8225A1A901D for ; Mon, 8 Jun 2015 19:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DvauLwpw8LMt for ; Mon, 8 Jun 2015 19:57:57 -0700 (PDT) Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC7D91A8A0E for ; Mon, 8 Jun 2015 19:57:56 -0700 (PDT) Received: by labko7 with SMTP id ko7so3360185lab.2 for ; Mon, 08 Jun 2015 19:57:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=7G+vusn8z9f0djzci/syC9AvxM01GpOalBFmNOejYtg=; b=QaDF0udxUc4tI2IWAhwGScQ8IWZwasGwDPcMbsK1QFU81wi6GPXah9EfJS6FEVoq2x 094PjtQDdgniHUdPCccvdXnAw96XWZlmxMLaq52eXoXFaHs8SwgDB9Rr9jBdCrdszvMP 5CCxQjM+IJQK9aLZywcwYZepb1/Bnf+yRbw48QsgWXps3AxBLcPpngwBuRf7XsYBe0jO zMqsACNTMTezttW+5EMkUOx3/ZvzlgPuIoEkGb6E7QdKyuo9pLey6e1ymGSymsFQvJNN g+YdNgOh3+9SWLNXX3A2dsk1k2huIq/65GKAEILHacQNfFjNQ0RvVRuXz+Q7oeUDkyuN IQPA== X-Gm-Message-State: ALoCoQlaW4u610qnbqio2SGdpI6uRfqpKTryvqRK8SYTqW8cXHLM9B1ySLOKP9W6udsqsK2HTptG MIME-Version: 1.0 X-Received: by 10.152.37.67 with SMTP id w3mr20240420laj.123.1433818675252; Mon, 08 Jun 2015 19:57:55 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Mon, 8 Jun 2015 19:57:55 -0700 (PDT) In-Reply-To: <20150608151059.GB30068@elstar.local> References: <20150608.102005.1482395931170643204.mbj@tail-f.com> <20150608094708.GA28936@elstar.local> <20150608143100.GD29788@elstar.local> <20150608151059.GB30068@elstar.local> Date: Mon, 8 Jun 2015 19:57:55 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Martin Bjorklund , Netconf Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Netconf] YANG Patch Issue #3: :distinct-startup X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 02:57:58 -0000 ... >> Then it might be better to use NETCONF without :distinct-startup, >> so there is no requirement to ever save the running datastore >> to non-volatile storage. > > I do want to safe to non-volatile storage and I am concerned about the > performance if every RESTCONF edit goes to NV storage on its own. > I haven't seen much interest in this problem. The problem needs to be clearly scoped. Problem: NV-storage is expensive so if the server supports the :startup capability then control of NV-storage should be provided in RESTCONF. Query parameter "nv-save" leaf nv-save { if-feature nc:startup; type boolean; default true; description "If 'true' then save the edits to non-volatile storage. If 'false' then do not save the edits to non-volatile storage. Only applies to configuration edits."; } POST/restconf/data/some/data1?nv-save=false POST /restconf/data/some/data2?nv-save=false POST /restconf/data/some/data3 The edits for data1 and data2 are not saved to startup. The edit 'data3' saves all of running to startup. Another client can do 'nv-save' before this one. This client will save any edits to running, not just its own. (Shared running datastore!) There is no read or write access directly to the NETCONF 'startup' datastore. Access to datastores is a different topic. This solution simply provides control over NV-storage if the server supports it. Do you think this solution will work? If not, do you have a different one? > /js Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Mon Jun 8 20:12:47 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 263CE1ACDBB for ; Mon, 8 Jun 2015 20:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4pa88MBdruLO for ; Mon, 8 Jun 2015 20:12:44 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AF781ACDBA for ; Mon, 8 Jun 2015 20:12:44 -0700 (PDT) Received: by lbbqq2 with SMTP id qq2so3047824lbb.3 for ; Mon, 08 Jun 2015 20:12:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=6Wes6BWzVVi/FQsdIyiHpyQPCpMP8syE9zH1++MpRHg=; b=W/HxVFJBFvecYGh5M0ZdnD20NaQaRTk9UcCEM2J+K09NwjgbuNs0ZwNsj0O2xUWW+o Z56RqnDC6PDKmEsG+d7IF+Sf3+7YM6jiC8c5njciUU0d6gJ16WoB+nz75xjcCHnEMIG4 L3kAnib27CMQjzs6zdARYSq01D89NYXXbyVvUuLIktmdG/eNUHeRxPol77wFM734hHHM A69qwzQjblaoY/Dy/7T07uQfA0baKv9h76bQ+VlhXPqy4Pf+SstKVg4rWVw/c+55+hlY 5a0UbdpjLwtF8uxExwKvCR4kZNE8aViB1p/BEA8Fk/RG3ZRGu4t6hTRBgeyuc+EBPX6r Xd5w== X-Gm-Message-State: ALoCoQl6o5v9UDKOqlzX4Ll+lezAEd6zIpJ0MN26LUdinMgzznD/wst3bJ1TG6An6rKRY9Rf8Pei MIME-Version: 1.0 X-Received: by 10.152.7.65 with SMTP id h1mr20261623laa.33.1433819562893; Mon, 08 Jun 2015 20:12:42 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Mon, 8 Jun 2015 20:12:42 -0700 (PDT) In-Reply-To: References: <20150608.102005.1482395931170643204.mbj@tail-f.com> <20150608094708.GA28936@elstar.local> <20150608143100.GD29788@elstar.local> <20150608151059.GB30068@elstar.local> Date: Mon, 8 Jun 2015 20:12:42 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Martin Bjorklund , Netconf Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Netconf] YANG Patch Issue #3: :distinct-startup X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 03:12:46 -0000 Hi, I forgot about the other solution we already discussed, that does not require any new query parameters POST /restconf/operations/ietf-netconf:copy-config {"ietf-netconf:input":{ "source":{ "running":null }, "target":{ "startup":null } } } Andy On Mon, Jun 8, 2015 at 7:57 PM, Andy Bierman wrote: > ... >>> Then it might be better to use NETCONF without :distinct-startup, >>> so there is no requirement to ever save the running datastore >>> to non-volatile storage. >> >> I do want to safe to non-volatile storage and I am concerned about the >> performance if every RESTCONF edit goes to NV storage on its own. >> > > I haven't seen much interest in this problem. > The problem needs to be clearly scoped. > Problem: NV-storage is expensive so if the server supports > the :startup capability then control of NV-storage should be provided > in RESTCONF. > > Query parameter "nv-save" > > leaf nv-save { > if-feature nc:startup; > type boolean; > default true; > description > "If 'true' then save the edits to non-volatile storage. > If 'false' then do not save the edits to non-volatile > storage. Only applies to configuration edits."; > } > > POST/restconf/data/some/data1?nv-save=false > POST /restconf/data/some/data2?nv-save=false > POST /restconf/data/some/data3 > > The edits for data1 and data2 are not saved to startup. > The edit 'data3' saves all of running to startup. > Another client can do 'nv-save' before this one. > This client will save any edits to running, not just its own. > (Shared running datastore!) > > There is no read or write access directly to the NETCONF 'startup' > datastore. Access to datastores is a different topic. > This solution simply provides control over NV-storage > if the server supports it. > > Do you think this solution will work? > If not, do you have a different one? > > >> /js > > > Andy > > >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> Fax: +49 421 200 3103 From nobody Mon Jun 8 22:48:03 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2B81A86F1 for ; Mon, 8 Jun 2015 22:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkfGww13Rwuw for ; Mon, 8 Jun 2015 22:48:00 -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 15C251A86E3 for ; Mon, 8 Jun 2015 22:48:00 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id AB1E512BB; Tue, 9 Jun 2015 07:47:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id N3b_vWg7i_NU; Tue, 9 Jun 2015 07:47:57 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 9 Jun 2015 07:47:57 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id D642E20013; Tue, 9 Jun 2015 07:47:57 +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 Qzpnb3qqMwYg; Tue, 9 Jun 2015 07:48:03 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7C3242002B; Tue, 9 Jun 2015 07:47:55 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9A21034468CA; Tue, 9 Jun 2015 07:47:53 +0200 (CEST) Date: Tue, 9 Jun 2015 07:47:51 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20150609054750.GA32431@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , Netconf References: <20150608.102005.1482395931170643204.mbj@tail-f.com> <20150608094708.GA28936@elstar.local> <20150608143100.GD29788@elstar.local> <20150608151059.GB30068@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Netconf Subject: Re: [Netconf] YANG Patch Issue #3: :distinct-startup X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 05:48:02 -0000 This is fine except how do I decide whether I have to use this copy-config? If a server does not support :startup, then each edit still leads to an NV write? I am OK with using this approach if the specification provides enough clarity that application developers know how to do this right. (I actually like this approach more than magic query parameters.) /js On Mon, Jun 08, 2015 at 08:12:42PM -0700, Andy Bierman wrote: > Hi, > > I forgot about the other solution we already discussed, > that does not require any new query parameters > > POST /restconf/operations/ietf-netconf:copy-config > > {"ietf-netconf:input":{ > "source":{ > "running":null > }, > "target":{ > "startup":null > } > } > } > > > > Andy > > > On Mon, Jun 8, 2015 at 7:57 PM, Andy Bierman wrote: > > ... > >>> Then it might be better to use NETCONF without :distinct-startup, > >>> so there is no requirement to ever save the running datastore > >>> to non-volatile storage. > >> > >> I do want to safe to non-volatile storage and I am concerned about the > >> performance if every RESTCONF edit goes to NV storage on its own. > >> > > > > I haven't seen much interest in this problem. > > The problem needs to be clearly scoped. > > Problem: NV-storage is expensive so if the server supports > > the :startup capability then control of NV-storage should be provided > > in RESTCONF. > > > > Query parameter "nv-save" > > > > leaf nv-save { > > if-feature nc:startup; > > type boolean; > > default true; > > description > > "If 'true' then save the edits to non-volatile storage. > > If 'false' then do not save the edits to non-volatile > > storage. Only applies to configuration edits."; > > } > > > > POST/restconf/data/some/data1?nv-save=false > > POST /restconf/data/some/data2?nv-save=false > > POST /restconf/data/some/data3 > > > > The edits for data1 and data2 are not saved to startup. > > The edit 'data3' saves all of running to startup. > > Another client can do 'nv-save' before this one. > > This client will save any edits to running, not just its own. > > (Shared running datastore!) > > > > There is no read or write access directly to the NETCONF 'startup' > > datastore. Access to datastores is a different topic. > > This solution simply provides control over NV-storage > > if the server supports it. > > > > Do you think this solution will work? > > If not, do you have a different one? > > > > > >> /js > > > > > > Andy > > > > > >> > >> -- > >> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > >> Fax: +49 421 200 3103 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jun 8 23:08:41 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 528C31AD0EA for ; Mon, 8 Jun 2015 23:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adKaQfASlER1 for ; Mon, 8 Jun 2015 23:08:38 -0700 (PDT) Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 522A21AD0CC for ; Mon, 8 Jun 2015 23:08:38 -0700 (PDT) Received: by laew7 with SMTP id w7so5013862lae.1 for ; Mon, 08 Jun 2015 23:08:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=rvQaG1T6mhIkwBf2jPZPUfdvUdU/x6iFV0GhjZtmUk8=; b=GethCsXvLqafsLFWSVK8X96n6JM3uDJpqkbt6Q9OQO7vMFoxrLK0esUiDm0rHrjBtJ Br5fd18wnewmDMZZB+GfYLTDjV3i86CowUbPtMa1gW3Sw8tqz+kCmnRb4Wnpguq/q5HF itK0tLHdgSBQNXq6NlOEOUhgcgT/CZrWFVIwrsJnpIA0GJghmUtp3GKx3noiczWve3gS ValQaoUq97YOqabGRQeHeRfvJdl4smVIFiCUedrIdWw+zguBsmosyDdv7Ab9qYu9khKX xkVTf8A1eGoqWJfBuQj1pStRwVqVKGlHZNUnblhnDL3QmF3/+lcAqtS5fuu0wzU+d5p6 1vKA== X-Gm-Message-State: ALoCoQkNzMdJ3ZffUoUsM6jy0Y8UWKfH0IEF9JKaaYtdcgSqO1sfJ6oLgQ2ah57uJuhG85yzXKaA MIME-Version: 1.0 X-Received: by 10.152.37.67 with SMTP id w3mr20800438laj.123.1433830116829; Mon, 08 Jun 2015 23:08:36 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Mon, 8 Jun 2015 23:08:36 -0700 (PDT) In-Reply-To: <20150609054750.GA32431@elstar.local> References: <20150608.102005.1482395931170643204.mbj@tail-f.com> <20150608094708.GA28936@elstar.local> <20150608143100.GD29788@elstar.local> <20150608151059.GB30068@elstar.local> <20150609054750.GA32431@elstar.local> Date: Mon, 8 Jun 2015 23:08:36 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Martin Bjorklund , Netconf Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Netconf] YANG Patch Issue #3: :distinct-startup X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 06:08:40 -0000 On Mon, Jun 8, 2015 at 10:47 PM, Juergen Schoenwaelder wrote: > This is fine except how do I decide whether I have to use this > copy-config? If a server does not support :startup, then each edit > still leads to an NV write? > I guess a RESTCONF capability for startup is needed. We already have one for with-defaults. > I am OK with using this approach if the specification provides enough > clarity that application developers know how to do this right. (I > actually like this approach more than magic query parameters.) > The operation can be accessed the same way to read the startup datastore. But this would mean the server never automatically does an NV-save (just like NETCONF) if :startup is advertised. > /js Andy > > On Mon, Jun 08, 2015 at 08:12:42PM -0700, Andy Bierman wrote: >> Hi, >> >> I forgot about the other solution we already discussed, >> that does not require any new query parameters >> >> POST /restconf/operations/ietf-netconf:copy-config >> >> {"ietf-netconf:input":{ >> "source":{ >> "running":null >> }, >> "target":{ >> "startup":null >> } >> } >> } >> >> >> >> Andy >> >> >> On Mon, Jun 8, 2015 at 7:57 PM, Andy Bierman wrote: >> > ... >> >>> Then it might be better to use NETCONF without :distinct-startup, >> >>> so there is no requirement to ever save the running datastore >> >>> to non-volatile storage. >> >> >> >> I do want to safe to non-volatile storage and I am concerned about the >> >> performance if every RESTCONF edit goes to NV storage on its own. >> >> >> > >> > I haven't seen much interest in this problem. >> > The problem needs to be clearly scoped. >> > Problem: NV-storage is expensive so if the server supports >> > the :startup capability then control of NV-storage should be provided >> > in RESTCONF. >> > >> > Query parameter "nv-save" >> > >> > leaf nv-save { >> > if-feature nc:startup; >> > type boolean; >> > default true; >> > description >> > "If 'true' then save the edits to non-volatile storage. >> > If 'false' then do not save the edits to non-volatile >> > storage. Only applies to configuration edits."; >> > } >> > >> > POST/restconf/data/some/data1?nv-save=false >> > POST /restconf/data/some/data2?nv-save=false >> > POST /restconf/data/some/data3 >> > >> > The edits for data1 and data2 are not saved to startup. >> > The edit 'data3' saves all of running to startup. >> > Another client can do 'nv-save' before this one. >> > This client will save any edits to running, not just its own. >> > (Shared running datastore!) >> > >> > There is no read or write access directly to the NETCONF 'startup' >> > datastore. Access to datastores is a different topic. >> > This solution simply provides control over NV-storage >> > if the server supports it. >> > >> > Do you think this solution will work? >> > If not, do you have a different one? >> > >> > >> >> /js >> > >> > >> > Andy >> > >> > >> >> >> >> -- >> >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> >> Fax: +49 421 200 3103 > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Mon Jun 8 23:15:02 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8751AD182 for ; Mon, 8 Jun 2015 23:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQzGIespl5Dl for ; Mon, 8 Jun 2015 23:14:59 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2539E1AD186 for ; Mon, 8 Jun 2015 23:14:59 -0700 (PDT) Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id F29E41AE0375; Tue, 9 Jun 2015 08:14:57 +0200 (CEST) Date: Tue, 09 Jun 2015 08:14:57 +0200 (CEST) Message-Id: <20150609.081457.165185592509362446.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20150608151059.GB30068@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] YANG Patch Issue #3: :distinct-startup X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 06:15:00 -0000 Andy Bierman wrote: > ... > >> Then it might be better to use NETCONF without :distinct-startup, > >> so there is no requirement to ever save the running datastore > >> to non-volatile storage. > > > > I do want to safe to non-volatile storage and I am concerned about the > > performance if every RESTCONF edit goes to NV storage on its own. > > > > I haven't seen much interest in this problem. > The problem needs to be clearly scoped. > Problem: NV-storage is expensive so if the server supports > the :startup capability then control of NV-storage should be provided > in RESTCONF. I would state this a bit differently: In a traditional implementation of a distinct startup configuration, saving running to startup is expensive, so if the server supports the :startup capability then control of when to save to startup should be provided in RESTCONF. Copy to startup doesn't *have* to be expensive (it is implementation dependent), and a system that implements writable running only has probably made sure that each edit is pretty cheap. My point is that it is not the NV-storage per se that is expensive. > Query parameter "nv-save" > > leaf nv-save { > if-feature nc:startup; Should the leaf be called 'copy-to-startup'? Or 'save-to-startup'? 'nv-save' is correct, but maybe a bit misleading. > type boolean; > default true; > description > "If 'true' then save the edits to non-volatile storage. ^^^^^ Actually, it will do more - it will also copy any other unsaved edits to nv-storage. That's why I would prefer to call it 'copy-to-startup', and explain this in the text. > If 'false' then do not save the edits to non-volatile > storage. Only applies to configuration edits."; > } > > POST/restconf/data/some/data1?nv-save=false > POST /restconf/data/some/data2?nv-save=false > POST /restconf/data/some/data3 > > The edits for data1 and data2 are not saved to startup. > The edit 'data3' saves all of running to startup. > Another client can do 'nv-save' before this one. > This client will save any edits to running, not just its own. > (Shared running datastore!) > > There is no read or write access directly to the NETCONF 'startup' > datastore. Access to datastores is a different topic. > This solution simply provides control over NV-storage > if the server supports it. > > Do you think this solution will work? Is there a way to first do the equivalent of copy-running-to-startup, i.e., do this POST w/o any additional parameters? > If not, do you have a different one? POST /restconf/.../copy-to-startup (with no body) But you idea is better, since it avoids a round-trip in some cases. /martin From nobody Tue Jun 9 04:29:35 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF801A0046 for ; Tue, 9 Jun 2015 04:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0yOcMBmaUWy for ; Tue, 9 Jun 2015 04:29:31 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0772.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::772]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 414561A19F8 for ; Tue, 9 Jun 2015 04:29:30 -0700 (PDT) Authentication-Results: jacobs-university.de; dkim=none (message not signed) header.d=none; Received: from pc6 (81.151.162.168) by DBXPR07MB064.eurprd07.prod.outlook.com (10.242.147.24) with Microsoft SMTP Server (TLS) id 15.1.184.17; Tue, 9 Jun 2015 10:34:33 +0000 Message-ID: <026201d0a29f$84e75fc0$4001a8c0@gateway.2wire.net> From: t.petch To: Juergen Schoenwaelder , Andy Bierman References: <20150608.102005.1482395931170643204.mbj@tail-f.com> <20150608094708.GA28936@elstar.local> <20150608143100.GD29788@elstar.local> <20150608151059.GB30068@elstar.local> <20150609054750.GA32431@elstar.local> Date: Tue, 9 Jun 2015 10:41:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.162.168] X-ClientProxiedBy: DB5PR09CA0030.eurprd09.prod.outlook.com (25.161.191.40) To DBXPR07MB064.eurprd07.prod.outlook.com (10.242.147.24) X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB064; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520003)(3002001); SRVR:DBXPR07MB064; BCL:0; PCL:0; RULEID:; SRVR:DBXPR07MB064; X-Forefront-PRVS: 06022AA85F X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(51444003)(51704005)(24454002)(5383002)(50466002)(46102003)(19580395003)(19580405001)(66066001)(77096005)(44716002)(62236002)(84392001)(33646002)(122386002)(47776003)(23756003)(40100003)(81816999)(76176999)(50986999)(116806002)(61296003)(93886004)(50226001)(44736004)(81686999)(14496001)(189998001)(86362001)(1556002)(87976001)(5001770100001)(5001960100002)(42186005)(15975445007)(62966003)(77156002)(1456003)(92566002); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB064; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jun 2015 10:34:33.3666 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB064 Archived-At: Cc: Netconf Subject: Re: [Netconf] YANG Patch Issue #3: :distinct-startup X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 11:29:33 -0000 ----- Original Message ----- From: "Juergen Schoenwaelder" To: "Andy Bierman" Cc: "Netconf" Sent: Tuesday, June 09, 2015 6:47 AM > This is fine except how do I decide whether I have to use this > copy-config? If a server does not support :startup, then each edit > still leads to an NV write? > > I am OK with using this approach if the specification provides enough > clarity that application developers know how to do this right. (I > actually like this approach more than magic query parameters.) I agree that the specification should provide clarity. This issue did surface with vanilla Netconf, I think as a result of I2RS, with the supposition that what had been implemented was a NV write for each edit when there was no startup:; but I think that it should be specified. (There may also have been a supposition that no :startup was rare but IOT and other low capacity devices might change that). Tom Petch > /js > > On Mon, Jun 08, 2015 at 08:12:42PM -0700, Andy Bierman wrote: > > Hi, > > > > I forgot about the other solution we already discussed, > > that does not require any new query parameters > > > > POST /restconf/operations/ietf-netconf:copy-config > > > > {"ietf-netconf:input":{ > > "source":{ > > "running":null > > }, > > "target":{ > > "startup":null > > } > > } > > } > > > > > > > > Andy > > > > > > On Mon, Jun 8, 2015 at 7:57 PM, Andy Bierman wrote: > > > ... > > >>> Then it might be better to use NETCONF without :distinct-startup, > > >>> so there is no requirement to ever save the running datastore > > >>> to non-volatile storage. > > >> > > >> I do want to safe to non-volatile storage and I am concerned about the > > >> performance if every RESTCONF edit goes to NV storage on its own. > > >> > > > > > > I haven't seen much interest in this problem. > > > The problem needs to be clearly scoped. > > > Problem: NV-storage is expensive so if the server supports > > > the :startup capability then control of NV-storage should be provided > > > in RESTCONF. > > > > > > Query parameter "nv-save" > > > > > > leaf nv-save { > > > if-feature nc:startup; > > > type boolean; > > > default true; > > > description > > > "If 'true' then save the edits to non-volatile storage. > > > If 'false' then do not save the edits to non-volatile > > > storage. Only applies to configuration edits."; > > > } > > > > > > POST/restconf/data/some/data1?nv-save=false > > > POST /restconf/data/some/data2?nv-save=false > > > POST /restconf/data/some/data3 > > > > > > The edits for data1 and data2 are not saved to startup. > > > The edit 'data3' saves all of running to startup. > > > Another client can do 'nv-save' before this one. > > > This client will save any edits to running, not just its own. > > > (Shared running datastore!) > > > > > > There is no read or write access directly to the NETCONF 'startup' > > > datastore. Access to datastores is a different topic. > > > This solution simply provides control over NV-storage > > > if the server supports it. > > > > > > Do you think this solution will work? > > > If not, do you have a different one? > > > > > > > > >> /js > > > > > > > > > Andy > > > > > > > > >> > > >> -- > > >> Juergen Schoenwaelder Jacobs University Bremen gGmbH > > >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > >> Fax: +49 421 200 3103 > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Tue Jun 9 04:29:36 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46D431A0046 for ; Tue, 9 Jun 2015 04:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUSsaqFTqRu3 for ; Tue, 9 Jun 2015 04:29:32 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0772.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::772]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44B6C1A1A1C for ; Tue, 9 Jun 2015 04:29:31 -0700 (PDT) Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none; Received: from pc6 (81.151.162.168) by DBXPR07MB064.eurprd07.prod.outlook.com (10.242.147.24) with Microsoft SMTP Server (TLS) id 15.1.184.17; Tue, 9 Jun 2015 10:34:33 +0000 Message-ID: <026301d0a29f$852a8340$4001a8c0@gateway.2wire.net> From: t.petch To: Kent Watsen , Alan Luchuk , References: <201505221959.t4MJxRHR081289@mainfs.snmp.com> <201506031817.t53IHJit066848@mainfs.snmp.com> Date: Tue, 9 Jun 2015 11:31:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.162.168] X-ClientProxiedBy: DB5PR09CA0030.eurprd09.prod.outlook.com (25.161.191.40) To DBXPR07MB064.eurprd07.prod.outlook.com (10.242.147.24) X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB064; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520003)(3002001); SRVR:DBXPR07MB064; BCL:0; PCL:0; RULEID:; SRVR:DBXPR07MB064; X-Forefront-PRVS: 06022AA85F X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(76104003)(51704005)(50466002)(46102003)(19580395003)(19580405001)(66066001)(77096005)(44716002)(62236002)(84392001)(33646002)(122386002)(47776003)(23756003)(40100003)(81816999)(76176999)(50986999)(116806002)(61296003)(93886004)(50226001)(44736004)(81686999)(14496001)(189998001)(230783001)(86362001)(1556002)(87976001)(5001770100001)(5001960100002)(107886002)(42186005)(62966003)(77156002)(1456003)(92566002)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB064; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jun 2015 10:34:33.8034 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB064 Archived-At: Subject: Re: [Netconf] draft-ietf-netconf-call-home-05.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 11:29:34 -0000 ----- Original Message ----- From: "Kent Watsen" To: "Alan Luchuk" ; Sent: Wednesday, June 03, 2015 8:17 PM > > > >Thanks for the suggestion. I studied this differences fairly carefully. > >The new text is more specific, and I agree it is an improvement from the > >previous text in draft-05. > > No new split infinitives? ;) No but there might be the avoidance thereof in S4 "the server MUST also send any intermediate certificates leading up to the trust anchor the clients are expected use to authenticate it. " And in s.4, " This reversal is incongruous with [RFC4253], ", I wonder if incongruent is intended. I like Alan's changes. One issue from earlier is what methods of authentication are acceptable. 5539bis now says X.509 certificate, RFC6242 is silent; I don't know where Restconf is heading. This I-D sort of implies that servers will only offer certificates or host keys, in which case I would like to see that made explicit. On client authentication by servers, we seem not to require it. I have read and re-read "3. The NETCONF or RESTCONF Server 3.1. Protocol Operation " and can see no mention thereof. Tom Petch > > >Nit: Would it clarify the text in item "C6" to change "reference > >identifier" > >to "server reference identifier"? > >FWIW, I'm not fond of the term "reference identifier", but it is probably > >the best choice. Alternatives would probably be more wordy, and reduce > >the overall clarity of the text. > > > This term comes from RFC 6125, Section 1.8. A reference to it should be > added. But looking at 6125 again, I see it defines "identifier" as being > of two kinds "reference" and "presented". In C6, though discussing > presented identifiers, I think just using "identifier" by itself makes the > most sense. Same for section 2.2. What do you think? > > Kent > From nobody Tue Jun 9 09:50:39 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9364D1A047A for ; Tue, 9 Jun 2015 09:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.355 X-Spam-Level: * X-Spam-Status: No, score=1.355 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_IS_SMALL6=0.556, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGo8q_OHArdv for ; Tue, 9 Jun 2015 09:50:33 -0700 (PDT) Received: from ni.com (skprod2.natinst.com [130.164.80.23]) (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 5ACA51A90F7 for ; Tue, 9 Jun 2015 09:50:02 -0700 (PDT) Received: from US-AUS-MAIL4.amer.corp.natinst.com (nb-snip2-1338.natinst.com [130.164.19.135]) by us-aus-skprod2.natinst.com (8.15.0.59/8.15.0.59) with ESMTP id t59Go1Aa005514; Tue, 9 Jun 2015 11:50:01 -0500 In-Reply-To: References: To: Andy Bierman MIME-Version: 1.0 X-KeepSent: 320856F3:52E807EA-86257E5E:00790AF4; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3FP3 November 16, 2012 From: Rodney Cummings Message-ID: Date: Tue, 9 Jun 2015 11:50:01 -0500 X-MIMETrack: Serialize by Router on US-AUS-MAIL4/AUS/M/NIC(Release 8.5.3FP6 HF1218|December 12, 2014) at 06/09/2015 11:50:01 AM, Serialize complete at 06/09/2015 11:50:01 AM Content-Type: multipart/alternative; boundary="=_alternative 005C784786257E5F_=" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-06-09_12:, , signatures=0 Archived-At: Cc: Netconf Subject: Re: [Netconf] Suggestion for RESTCONF section 5.3 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 16:50:37 -0000 This is a multipart message in MIME format. --=_alternative 005C784786257E5F_= Content-Type: text/plain; charset="US-ASCII" Thanks Andy, I should have been clear on this point. For the applications that I am targeting, the relevant IEEE 802.1 TSN standards are currently in draft stage (not published), so even the hardware components are a work-in-progress. Therefore, the recommendation that I am attempting to make for the management protocol occurs with an understanding of the risks of using pre-publication IEEE / IETF standards. Although there are definitely folks in TSN who are eager to start with implementations, we understand that a draft can change in major ways, and therefore the implementation can change in major ways. I'm looking at the problem as "A few years in the future, when options 1, 2, 3, and 4 are in RFC form, which is the best fit for IoT applications?" In my opinion, the answer will vary depending on the requirements of each IoT application. To help explain, let's refer back to the previous thread on this topic that Kent referenced: https://www.ietf.org/mail-archive/web/netconf/current/msg09218.html My suggestion is effectively a new option e) e) Specify RESTCONF-XML and RESTCONF-JSON as distinct conformance categories (i.e. RESTCONF-JSON client interoperates with a RESTCONF-JSON server). I realize that for a typical NMS client, this is effectively the same as option d), because the NMS must interoperate with all possible servers. Speaking as someone who will implement both client and server, I am comfortable with option d). I can't speak for all clients, but my client is not constrained, but the servers are very constrained. In addition, the servers in my space are very opinionated as to what is "heavy" and what is "constrained" for their market space. Some of the comments in the thread debated the which-is-best angle... XML or JSON. In my opinion this is not relevant. The relevant question is: Are there implementers out there who feel strongly that JSON is preferable to XML? Whether I agree with the implementers or not, the answer is clearly Yes. One or two comments in the thread argued that implementation complexity does not matter. That may be a reasonable argument, but if you feel that way, I would suggest that you oppose RESTCONF as a whole. If implementation complexity does not matter, the best course of action is to mandate full-featured NETCONF, and abort RESTCONF and CoMI. I assume that the benefit of applying RESTful methodology to the YANG data model is that it provides implementation flexibility that is a better fit to some use cases and applications. I'll use a few IoT applications as examples. Smart Grid: A network of synchrophasors can span an entire nation, which inherently implies the class of router that is used for Internet applications. This router can accommodate a full NETCONF implementation, and RESTCONF-XML provides another way to access the same XML information model. For this IoT application, the option a) fits just fine. Field-level control on an industrial factory floor: Historically, these networks were non-Ethernet busses, with simple binary data for network configuration. Over the past decade or so, the devices in these networks typically use Ethernet and IP, and they often implement a web server for configuration, using REST, JSON, TLS, and so on. Nevertheless, these devices are still sceptical of technologies that are viewed as heavy-weight, so I am concerned that XML-on-the-wire won't be universally accepted. If RESTCONF mandates option a) for this IoT application, this effectively boils down to a statement like: I know you love apples, and you hate oranges, but oranges are good for you, so you must eat an orange first, and then you can eat an apple. This sort of argument is likely to be rejected, because I can go elsewhere and buy an apple. It would be very helpful if RESTCONF would allow servers in this network to use RESTCONF-JSON. The client could mandate option d), but for this localized IoT application, option e) would also work. I appreciate Andy's suggestion that this application could use CoMI, but given that this IoT application already implements REST-with-JSON, I'm sure you'll agree that CoMI is a strange recommendation. That is effectively saying that RESTCONF does not support JSON at all. Control network inside a car: Today, these networks are non-Ethernet busses with binary configuration. They are currently in the process of slowly integrating Ethernet. The processor in each controller typically runs "bare metal", with no operating system at all. Given these constraints, the network for this IoT application is typically "preconfigured" (stored in NV memory when the car rolls out of the factory). Nevertheless, looking forward, there is discussion of using management, IP protocols, and so on. Given the lack of operating system infrastructure, CoMI will clearly be the best fit for this IoT application. My point is that we want to bring IETF technologies to these applications, and that includes YANG-based management. If we insist on a one-size-fits-all approach, the IoT initiatives will succeed for some applications, and fail for others. I genuinely feel that YANG-based management is a great fit for all IoT applications, and I think that option d) or e) is the best way to go. Nevertheless, I realize that the WG has already made a decision on this, and a single voice of opposition certainly does not justify revisiting it. I'll try to encourage others in the IoT initiatives to voice opinion on this, but failing that, I'm happy to let the issue REST (no pun intended). Rodney From: Andy Bierman To: Rodney Cummings , Cc: Netconf Date: 06/07/2015 08:31 PM Subject: Re: [Netconf] Suggestion for RESTCONF section 5.3 Hi, Only choice (1) is published in an RFC. Options (2) - (4) are work-in-progress. It is difficult to estimate how long an IETF RFC will take, or how much it will change from the current draft to RFC. IMO IoT should use (4), but wait for the RFC. Participate in the CoMI work and it might get done faster. Andy On Fri, Jun 5, 2015 at 12:39 PM, Rodney Cummings wrote: > Hello, > > Although I am new to the NETCONF WG and mailing list, I have a suggestion > for the RESTCONF I-D that I'd like to discuss. I realize that I may be > bringing up a topic that has already been thoroughly discussed. > Nevertheless, this issue is a genuine problem for deployment of RESTCONF for > my applications, so if my suggestion is rejected, it will be helpful for me > understand the rationale. > > Suggestion > -- > > Section 5.3 of the current I-D > (https://tools.ietf.org/html/draft-ietf-netconf-restconf-04) states: > > "Content is encoded in either JSON or XML format. A server MUST support XML > encoding and MAY support JSON encoding." > > My suggestion is to change section 5.3 to state: > > "Content is encoded in either JSON or XML format. A client MUST support at > least one of the specified encodings (XML or JSON), and a client SHOULD > support all specified encodings. A server MUST support at least one of the > specified encodings (XML or JSON), and a server MAY support multiple > encodings." > > In other words, if a server wants to focus on JSON exclusively, allow that > as a conformant implementation. The client has a presumed burden to support > a server that is XML-only or JSON-only. > > Rationale > -- > > As part of a roadmap for supporting industrial IoT devices, the 802.1 > Time-Sensitive Networking standards (TSN) are focusing on YANG modules for > configuration of the low-level queuing behavior in 802.1 switches (e.g. > schedule for traffic egress on each port). The assumption is that an > SDN-style controller will use these YANG modules to write configuration to > each switch in the network in an automated manner. Ideally, as TSN moves > forward it will be well-aligned with analogous IETF efforts, including CoRE, > 6TiSCH, and DetNet (upcoming BoF in July). > > One near-term focus for the TSN effort is to support an IoT device (e.g. > industrial motor, smart grid IED) that supports Ethernet today, but that > wants to embed an 802.1 switch. The goal is to expose two external ports > from the device, using the switch to enable topologies like daisy-chain and > ring. This is commonly done today using proprietary Ethernet extensions, but > we want to transition industrial applications to 802/IETF standards (much > like the 6TiSCH effort for wireless). The challenge is that although this > IoT device is technically a switch/router, it is very "Operational > Technology" (OT). A YANG-based management protocol is required to configure > the switch, but the switch supports a subset of what a standalone managed > switch/router supports, and the switch will always be configured in-band > from an OT controller, never from an IT-style NMS. > > From the perspective of one of these IoT device manufacturers, the primary > question for management is: > What YANG-based management protocol do I implement in my device? > Among others, I've been tasked to help answer this question for TSN and its > related groups (e.g. AVnu.org/industrial). The assumption is that the > manufacturer will use one and only one server implementation. Since the goal > is not to support a traditional NMS, implementation of multiple servers is > not a goal (e.g. SNMPv3 and NETCONF and RESTCONF XML and so on). > > Based on this, I've been trying to choose among the following > implementations in order to make a recommendation: > 1. NETCONF with XML encoding > 2. RESTCONF with XML encoding > 3. RESTCONF with JSON encoding > 4. CoMI with CBOR encoding > > For the industrial application space that I am evaluating, the devices are > "constrained" as CoRE describes. Nevertheless, over the last few years it > has become common for these devices to implement an HTTP web server for > configuration. These web servers are often designed as RESTful. Given the > constrained nature of the devices, they tend to use JSON, due to the > perception that XML parsing is less efficient. > > Based on these assumptions, I tend to exclude NETCONF. NETCONF is > full-featured, but most of those features are relevant to NMS concerns. > Also, NETCONF's basis on XML raises a perception (if not reality) of complex > implementation. > > CoMI looks promising, since it is based on relatively mature RFCs like CoAP > and CBOR. Nevertheless, the CoMI I-D itself looks like it is > not-quite-ready-for-prime-time. There are many TODOs, and the YANG hash > seems like it will require more prototyping before it is truly nailed down. > Given that, I can't really recommend that direction just yet, but ideally it > will be useful in the future. > > That leaves RESTCONF. Since the industrial device manufacturers tend to be > familiar with REST already, this is an easy sell. The I-D itself seems to be > relatively mature. > > Ideally, I could recommend option 3, RESTCONF with JSON. That is the > cleanest fit to what industrial devices do today. > > Given the limitations of section 5.3 in v04 of the I-D, I would be forced to > recommend option 2, RESTCONF with XML. If the IoT device is forced to > implement XML for conformance, then the addition of JSON doesn't offer much > value, since the goal is automated configuration. > > If we could allow RESTCONF server implementation using JSON-only, that would > be very helpful. What's more, that sort of conformance might leave the door > open to add CoMI as a formal RESTCONF encoding in the future. > > Feedback is much appreciated. Thanks. > > ---------------------------- > Rodney Cummings > Principal Software Architect, Industrial/Embedded Networks > National Instruments > Tel: (512) 683-8544 > Fax: (512) 683-8661 > Email: Rodney.Cummings@ni.com > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --=_alternative 005C784786257E5F_= Content-Type: text/html; charset="US-ASCII" Thanks Andy,

I should have been clear on this point. For the applications that I am targeting, the relevant IEEE 802.1 TSN standards are currently in draft stage (not published), so even the hardware components are a work-in-progress. Therefore, the recommendation that I am attempting to make for the management protocol occurs with an understanding of the risks of using pre-publication IEEE / IETF standards. Although there are definitely folks in TSN who are eager to start with implementations, we understand that a draft can change in major ways, and therefore the implementation can change in major ways.

I'm looking at the problem as "A few years in the future, when options 1, 2, 3, and 4 are in RFC form, which is the best fit for IoT applications?"

In my opinion, the answer will vary depending on the requirements of each IoT application.

To help explain, let's refer back to the previous thread on this topic that Kent referenced:
        https://www.ietf.org/mail-archive/web/netconf/current/msg09218.html
My suggestion is effectively a new option e)
        e) Specify RESTCONF-XML and RESTCONF-JSON as distinct conformance categories (i.e. RESTCONF-JSON client interoperates with a RESTCONF-JSON server).
I realize that for a typical NMS client, this is effectively the same as option d), because the NMS must interoperate with all possible servers.

Speaking as someone who will implement both client and server, I am comfortable with option d). I can't speak for all clients, but my client is not constrained, but the servers are very constrained. In addition, the servers in my space are very opinionated as to what is "heavy" and what is "constrained" for their market space.

Some of the comments in the thread debated the which-is-best angle... XML or JSON. In my opinion this is not relevant. The relevant question is:
        Are there implementers out there who feel strongly that JSON is preferable to XML?
Whether I agree with the implementers or not, the answer is clearly Yes.

One or two comments in the thread argued that implementation complexity does not matter. That may be a reasonable argument, but if you feel that way, I would suggest that you oppose RESTCONF as a whole. If implementation complexity does not matter, the best course of action is to mandate full-featured NETCONF, and abort RESTCONF and CoMI. I assume that the benefit of applying RESTful methodology to the YANG data model is that it provides implementation flexibility that is a better fit to some use cases and applications.

I'll use a few IoT applications as examples.

Smart Grid: A network of synchrophasors can span an entire nation, which inherently implies the class of router that is used for Internet applications. This router can accommodate a full NETCONF implementation, and RESTCONF-XML provides another way to access the same XML information model. For this IoT application, the option a) fits just fine.

Field-level control on an industrial factory floor: Historically, these networks were non-Ethernet busses, with simple binary data for network configuration. Over the past decade or so, the devices in these networks typically use Ethernet and IP, and they often implement a web server for configuration, using REST, JSON, TLS, and so on. Nevertheless, these devices are still sceptical of technologies that are viewed as heavy-weight, so I am concerned that XML-on-the-wire won't be universally accepted. If RESTCONF mandates option a) for this IoT application, this effectively boils down to a statement like:
        I know you love apples, and you hate oranges, but oranges are good for you, so you must eat an orange first, and then you can eat an apple.
This sort of argument is likely to be rejected, because I can go elsewhere and buy an apple. It would be very helpful if RESTCONF would allow servers in this network to use RESTCONF-JSON. The client could mandate option d), but for this localized  IoT application, option e) would also work. I appreciate Andy's suggestion that this application could use CoMI, but given that this IoT application already implements REST-with-JSON, I'm sure you'll agree that CoMI is a strange recommendation. That is effectively saying that RESTCONF does not support JSON at all.

Control network inside a car: Today, these networks are non-Ethernet busses with binary configuration. They are currently in the process of slowly integrating Ethernet. The processor in each controller typically runs "bare metal", with no operating system at all. Given these constraints, the network for this IoT application is typically "preconfigured" (stored in NV memory when the car rolls out of the factory). Nevertheless, looking forward, there is discussion of using management, IP protocols, and so on. Given the lack of operating system infrastructure, CoMI will clearly be the best fit for this IoT application.

My point is that we want to bring IETF technologies to these applications, and that includes YANG-based management. If we insist on a one-size-fits-all approach, the IoT initiatives will succeed for some applications, and fail for others. I genuinely feel that YANG-based management is a great fit for all IoT applications, and I think that option d) or e) is the best way to go.

Nevertheless, I realize that the WG has already made a decision on this, and a single voice of opposition certainly does not justify revisiting it. I'll try to encourage others in the IoT initiatives to voice opinion on this, but failing that, I'm happy to let the issue REST (no pun intended).

Rodney



From:        Andy Bierman <andy@yumaworks.com>
To:        Rodney Cummings <rodney.cummings@ni.com>,
Cc:        Netconf <netconf@ietf.org>
Date:        06/07/2015 08:31 PM
Subject:        Re: [Netconf] Suggestion for RESTCONF section 5.3



Hi,

Only choice (1) is published in an RFC.
Options (2) - (4) are work-in-progress.
It is difficult to estimate how long an IETF RFC will take,
or how much it will change from the current draft to RFC.

IMO IoT should use (4), but wait for the RFC.
Participate in the CoMI work and it might get done faster.


Andy





On Fri, Jun 5, 2015 at 12:39 PM, Rodney Cummings <rodney.cummings@ni.com> wrote:
> Hello,
>
> Although I am new to the NETCONF WG and mailing list, I have a suggestion
> for the RESTCONF I-D that I'd like to discuss. I realize that I may be
> bringing up a topic that has already been thoroughly discussed.
> Nevertheless, this issue is a genuine problem for deployment of RESTCONF for
> my applications, so if my suggestion is rejected, it will be helpful for me
> understand the rationale.
>
> Suggestion
> --
>
> Section 5.3 of the current I-D
> (https://tools.ietf.org/html/draft-ietf-netconf-restconf-04) states:
>
> "Content is encoded in either JSON or XML format.  A server MUST support XML
> encoding and MAY support JSON encoding."
>
> My suggestion is to change section 5.3 to state:
>
> "Content is encoded in either JSON or XML format.  A client MUST support at
> least one of the specified encodings (XML or JSON), and a client SHOULD
> support all specified encodings.  A server MUST support at least one of the
> specified encodings (XML or JSON), and a server MAY support multiple
> encodings."
>
> In other words, if a server wants to focus on JSON exclusively, allow that
> as a conformant implementation. The client has a presumed burden to support
> a server that is XML-only or JSON-only.
>
> Rationale
> --
>
> As part of a roadmap for supporting industrial IoT devices, the 802.1
> Time-Sensitive Networking standards (TSN) are focusing on YANG modules for
> configuration of the low-level queuing behavior in 802.1 switches (e.g.
> schedule for traffic egress on each port). The assumption is that an
> SDN-style controller will use these YANG modules to write configuration to
> each switch in the network in an automated manner. Ideally, as TSN moves
> forward it will be well-aligned with analogous IETF efforts, including CoRE,
> 6TiSCH, and DetNet (upcoming BoF in July).
>
> One near-term focus for the TSN effort is to support an IoT device (e.g.
> industrial motor, smart grid IED) that supports Ethernet today, but that
> wants to embed an 802.1 switch. The goal is to expose two external ports
> from the device, using the switch to enable topologies like daisy-chain and
> ring. This is commonly done today using proprietary Ethernet extensions, but
> we want to transition industrial applications to 802/IETF standards (much
> like the 6TiSCH effort for wireless). The challenge is that although this
> IoT device is technically a switch/router, it is very "Operational
> Technology" (OT). A YANG-based management protocol is required to configure
> the switch, but the switch supports a subset of what a standalone managed
> switch/router supports, and the switch will always be configured in-band
> from an OT controller, never from an IT-style NMS.
>
> From the perspective of one of these IoT device manufacturers, the primary
> question for management is:
>         What YANG-based management protocol do I implement in my device?
> Among others, I've been tasked to help answer this question for TSN and its
> related groups (e.g. AVnu.org/industrial). The assumption is that the
> manufacturer will use one and only one server implementation. Since the goal
> is not to support a traditional NMS, implementation of multiple servers is
> not a goal (e.g. SNMPv3 and NETCONF and RESTCONF XML and so on).
>
> Based on this, I've been trying to choose among the following
> implementations in order to make a recommendation:
> 1. NETCONF with XML encoding
> 2. RESTCONF with XML encoding
> 3. RESTCONF with JSON encoding
> 4. CoMI with CBOR encoding
>
> For the industrial application space that I am evaluating, the devices are
> "constrained" as CoRE describes. Nevertheless, over the last few years it
> has become common for these devices to implement an HTTP web server for
> configuration. These web servers are often designed as RESTful. Given the
> constrained nature of the devices, they tend to use JSON, due to the
> perception  that XML parsing is less efficient.
>
> Based on these assumptions, I tend to exclude NETCONF. NETCONF is
> full-featured, but most of those features are relevant to NMS concerns.
> Also, NETCONF's basis on XML raises a perception (if not reality) of complex
> implementation.
>
> CoMI looks promising, since it is based on relatively mature RFCs like CoAP
> and CBOR. Nevertheless, the CoMI I-D itself looks like it is
> not-quite-ready-for-prime-time. There are many TODOs, and the YANG hash
> seems like it will require more prototyping before it is truly nailed down.
> Given that, I can't really recommend that direction just yet, but ideally it
> will be useful in the future.
>
> That leaves RESTCONF. Since the industrial device manufacturers tend to be
> familiar with REST already, this is an easy sell. The I-D itself seems to be
> relatively mature.
>
> Ideally, I could recommend option 3, RESTCONF with JSON. That is the
> cleanest fit to what industrial devices do today.
>
> Given the limitations of section 5.3 in v04 of the I-D, I would be forced to
> recommend option 2, RESTCONF with XML. If the IoT device is forced to
> implement XML for conformance, then the addition of JSON doesn't offer much
> value, since the goal is automated configuration.
>
> If we could allow RESTCONF server implementation using JSON-only, that would
> be very helpful. What's more, that sort of conformance might leave the door
> open to add CoMI as a formal RESTCONF encoding in the future.
>
> Feedback is much appreciated. Thanks.
>
> ----------------------------
> Rodney Cummings
> Principal Software Architect, Industrial/Embedded Networks
> National Instruments
> Tel: (512) 683-8544
> Fax: (512) 683-8661
> Email: Rodney.Cummings@ni.com
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
--=_alternative 005C784786257E5F_=-- From nobody Tue Jun 9 10:11:07 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FCA61B2D65 for ; Tue, 9 Jun 2015 10:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7iwmJGHj8k4n for ; Tue, 9 Jun 2015 10:10:59 -0700 (PDT) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 692641B2D63 for ; Tue, 9 Jun 2015 10:10:59 -0700 (PDT) Received: by iebmu5 with SMTP id mu5so18476644ieb.1 for ; Tue, 09 Jun 2015 10:10:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=/HUdnqBCplnmuJd/FXzqfx/5VJAG9vTqVsS6R49gfxU=; b=NBb4djdje7+Wef+umcIw5t1aVombvGIc/Tq/vDScbQS84fGdnpVmkqGRUvsH6iVjbE IPfDQPxssOfecaZtV31JShE1jXaLzTlYH3TXNR4CXKRhYygrwYpVT1uvHlDDKozZQAZ9 kQLJnSKtxMbHbYWqKpwh5WpLrCbyWxOnzZmOLNdpfd+TNdcuN9FiBjJoHywbnN8Uku3w PfvC9i8SaEwvU/zAyCko8fJ1c9+CNd1CdlWFEUxOrE/Y+yVTkymlIsVTxAHnZZGyMo4e dCHZt1Flj+d+tRRfyrfzCkLMsX29jSZN8YDA1J+SILEE1epID5FQVkCMd6B2IfuZ2VWB LroQ== X-Gm-Message-State: ALoCoQmLWnvEi9nvmi1FMIb6+Ixtudo5XqkSCvg7mp8dYo1s8yo286UKuEXR9RkEdOCO9kVboPrH X-Received: by 10.107.10.151 with SMTP id 23mr27642864iok.89.1433869857679; Tue, 09 Jun 2015 10:10:57 -0700 (PDT) Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com. [209.85.213.179]) by mx.google.com with ESMTPSA id x3sm1519170igl.2.2015.06.09.10.10.55 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jun 2015 10:10:56 -0700 (PDT) Received: by igbpi8 with SMTP id pi8so17159307igb.1 for ; Tue, 09 Jun 2015 10:10:55 -0700 (PDT) X-Received: by 10.42.119.83 with SMTP id a19mr30792323icr.83.1433869855072; Tue, 09 Jun 2015 10:10:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Douglas Hubler Date: Tue, 09 Jun 2015 17:10:44 +0000 Message-ID: To: Rodney Cummings , Andy Bierman Content-Type: multipart/alternative; boundary=90e6ba613bca5dab34051818d7f6 Archived-At: Cc: Netconf Subject: Re: [Netconf] Suggestion for RESTCONF section 5.3 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 17:11:04 -0000 --90e6ba613bca5dab34051818d7f6 Content-Type: text/plain; charset=UTF-8 The possibility of an entire segment of the tech industry: namely IoT could embrace RESTCONF if we just create two categories RESTCONF-XML and RESTCONF-JSON, then is seems like a great opportunity to gain momentum behind RFC. It's unlikely to affect any implementations today as I'd bet money they all support JSON. On Tue, Jun 9, 2015 at 12:50 PM Rodney Cummings wrote: > Thanks Andy, > > I should have been clear on this point. For the applications that I am > targeting, the relevant IEEE 802.1 TSN standards are currently in draft > stage (not published), so even the hardware components are a > work-in-progress. Therefore, the recommendation that I am attempting to > make for the management protocol occurs with an understanding of the risks > of using pre-publication IEEE / IETF standards. Although there are > definitely folks in TSN who are eager to start with implementations, we > understand that a draft can change in major ways, and therefore the > implementation can change in major ways. > > I'm looking at the problem as "A few years in the future, when options 1, > 2, 3, and 4 are in RFC form, which is the best fit for IoT applications?" > > In my opinion, the answer will vary depending on the requirements of each > IoT application. > > To help explain, let's refer back to the previous thread on this topic > that Kent referenced: > > *https://www.ietf.org/mail-archive/web/netconf/current/msg09218.html* > > My suggestion is effectively a new option e) > e) Specify RESTCONF-XML and RESTCONF-JSON as distinct conformance > categories (i.e. RESTCONF-JSON client interoperates with a RESTCONF-JSON > server). > I realize that for a typical NMS client, this is effectively the same as > option d), because the NMS must interoperate with all possible servers. > > Speaking as someone who will implement both client and server, I am > comfortable with option d). I can't speak for all clients, but my client is > not constrained, but the servers are very constrained. In addition, the > servers in my space are very opinionated as to what is "heavy" and what is > "constrained" for their market space. > > Some of the comments in the thread debated the which-is-best angle... XML > or JSON. In my opinion this is not relevant. The relevant question is: > Are there implementers out there who feel strongly that JSON is > preferable to XML? > Whether I agree with the implementers or not, the answer is clearly Yes. > > One or two comments in the thread argued that implementation complexity > does not matter. That may be a reasonable argument, but if you feel that > way, I would suggest that you oppose RESTCONF as a whole. If implementation > complexity does not matter, the best course of action is to mandate > full-featured NETCONF, and abort RESTCONF and CoMI. I assume that the > benefit of applying RESTful methodology to the YANG data model is that it > provides implementation flexibility that is a better fit to some use cases > and applications. > > I'll use a few IoT applications as examples. > > Smart Grid: A network of synchrophasors can span an entire nation, which > inherently implies the class of router that is used for Internet > applications. This router can accommodate a full NETCONF implementation, > and RESTCONF-XML provides another way to access the same XML information > model. For this IoT application, the option a) fits just fine. > > Field-level control on an industrial factory floor: Historically, these > networks were non-Ethernet busses, with simple binary data for network > configuration. Over the past decade or so, the devices in these networks > typically use Ethernet and IP, and they often implement a web server for > configuration, using REST, JSON, TLS, and so on. Nevertheless, these > devices are still sceptical of technologies that are viewed as > heavy-weight, so I am concerned that XML-on-the-wire won't be universally > accepted. If RESTCONF mandates option a) for this IoT application, this > effectively boils down to a statement like: > I know you love apples, and you hate oranges, but oranges are good > for you, so you must eat an orange first, and then you can eat an apple. > This sort of argument is likely to be rejected, because I can go elsewhere > and buy an apple. It would be very helpful if RESTCONF would allow servers > in this network to use RESTCONF-JSON. The client could mandate option d), > but for this localized IoT application, option e) would also work. I > appreciate Andy's suggestion that this application could use CoMI, but > given that this IoT application already implements REST-with-JSON, I'm sure > you'll agree that CoMI is a strange recommendation. That is effectively > saying that RESTCONF does not support JSON at all. > > Control network inside a car: Today, these networks are non-Ethernet > busses with binary configuration. They are currently in the process of > slowly integrating Ethernet. The processor in each controller typically > runs "bare metal", with no operating system at all. Given these > constraints, the network for this IoT application is typically > "preconfigured" (stored in NV memory when the car rolls out of the > factory). Nevertheless, looking forward, there is discussion of using > management, IP protocols, and so on. Given the lack of operating system > infrastructure, CoMI will clearly be the best fit for this IoT application. > > My point is that we want to bring IETF technologies to these applications, > and that includes YANG-based management. If we insist on a > one-size-fits-all approach, the IoT initiatives will succeed for some > applications, and fail for others. I genuinely feel that YANG-based > management is a great fit for all IoT applications, and I think that option > d) or e) is the best way to go. > > Nevertheless, I realize that the WG has already made a decision on this, > and a single voice of opposition certainly does not justify revisiting it. > I'll try to encourage others in the IoT initiatives to voice opinion on > this, but failing that, I'm happy to let the issue REST (no pun intended). > > Rodney > > > > From: Andy Bierman > To: Rodney Cummings , > Cc: Netconf > Date: 06/07/2015 08:31 PM > Subject: Re: [Netconf] Suggestion for RESTCONF section 5.3 > ------------------------------ > > > > Hi, > > Only choice (1) is published in an RFC. > Options (2) - (4) are work-in-progress. > It is difficult to estimate how long an IETF RFC will take, > or how much it will change from the current draft to RFC. > > IMO IoT should use (4), but wait for the RFC. > Participate in the CoMI work and it might get done faster. > > > Andy > > > > > > On Fri, Jun 5, 2015 at 12:39 PM, Rodney Cummings > wrote: > > Hello, > > > > Although I am new to the NETCONF WG and mailing list, I have a suggestion > > for the RESTCONF I-D that I'd like to discuss. I realize that I may be > > bringing up a topic that has already been thoroughly discussed. > > Nevertheless, this issue is a genuine problem for deployment of RESTCONF > for > > my applications, so if my suggestion is rejected, it will be helpful for > me > > understand the rationale. > > > > Suggestion > > -- > > > > Section 5.3 of the current I-D > > (https://tools.ietf.org/html/draft-ietf-netconf-restconf-04) states: > > > > "Content is encoded in either JSON or XML format. A server MUST support > XML > > encoding and MAY support JSON encoding." > > > > My suggestion is to change section 5.3 to state: > > > > "Content is encoded in either JSON or XML format. A client MUST support > at > > least one of the specified encodings (XML or JSON), and a client SHOULD > > support all specified encodings. A server MUST support at least one of > the > > specified encodings (XML or JSON), and a server MAY support multiple > > encodings." > > > > In other words, if a server wants to focus on JSON exclusively, allow > that > > as a conformant implementation. The client has a presumed burden to > support > > a server that is XML-only or JSON-only. > > > > Rationale > > -- > > > > As part of a roadmap for supporting industrial IoT devices, the 802.1 > > Time-Sensitive Networking standards (TSN) are focusing on YANG modules > for > > configuration of the low-level queuing behavior in 802.1 switches (e.g. > > schedule for traffic egress on each port). The assumption is that an > > SDN-style controller will use these YANG modules to write configuration > to > > each switch in the network in an automated manner. Ideally, as TSN moves > > forward it will be well-aligned with analogous IETF efforts, including > CoRE, > > 6TiSCH, and DetNet (upcoming BoF in July). > > > > One near-term focus for the TSN effort is to support an IoT device (e.g. > > industrial motor, smart grid IED) that supports Ethernet today, but that > > wants to embed an 802.1 switch. The goal is to expose two external ports > > from the device, using the switch to enable topologies like daisy-chain > and > > ring. This is commonly done today using proprietary Ethernet extensions, > but > > we want to transition industrial applications to 802/IETF standards (much > > like the 6TiSCH effort for wireless). The challenge is that although this > > IoT device is technically a switch/router, it is very "Operational > > Technology" (OT). A YANG-based management protocol is required to > configure > > the switch, but the switch supports a subset of what a standalone managed > > switch/router supports, and the switch will always be configured in-band > > from an OT controller, never from an IT-style NMS. > > > > From the perspective of one of these IoT device manufacturers, the > primary > > question for management is: > > What YANG-based management protocol do I implement in my device? > > Among others, I've been tasked to help answer this question for TSN and > its > > related groups (e.g. AVnu.org/industrial). The assumption is that the > > manufacturer will use one and only one server implementation. Since the > goal > > is not to support a traditional NMS, implementation of multiple servers > is > > not a goal (e.g. SNMPv3 and NETCONF and RESTCONF XML and so on). > > > > Based on this, I've been trying to choose among the following > > implementations in order to make a recommendation: > > 1. NETCONF with XML encoding > > 2. RESTCONF with XML encoding > > 3. RESTCONF with JSON encoding > > 4. CoMI with CBOR encoding > > > > For the industrial application space that I am evaluating, the devices > are > > "constrained" as CoRE describes. Nevertheless, over the last few years it > > has become common for these devices to implement an HTTP web server for > > configuration. These web servers are often designed as RESTful. Given the > > constrained nature of the devices, they tend to use JSON, due to the > > perception that XML parsing is less efficient. > > > > Based on these assumptions, I tend to exclude NETCONF. NETCONF is > > full-featured, but most of those features are relevant to NMS concerns. > > Also, NETCONF's basis on XML raises a perception (if not reality) of > complex > > implementation. > > > > CoMI looks promising, since it is based on relatively mature RFCs like > CoAP > > and CBOR. Nevertheless, the CoMI I-D itself looks like it is > > not-quite-ready-for-prime-time. There are many TODOs, and the YANG hash > > seems like it will require more prototyping before it is truly nailed > down. > > Given that, I can't really recommend that direction just yet, but > ideally it > > will be useful in the future. > > > > That leaves RESTCONF. Since the industrial device manufacturers tend to > be > > familiar with REST already, this is an easy sell. The I-D itself seems > to be > > relatively mature. > > > > Ideally, I could recommend option 3, RESTCONF with JSON. That is the > > cleanest fit to what industrial devices do today. > > > > Given the limitations of section 5.3 in v04 of the I-D, I would be > forced to > > recommend option 2, RESTCONF with XML. If the IoT device is forced to > > implement XML for conformance, then the addition of JSON doesn't offer > much > > value, since the goal is automated configuration. > > > > If we could allow RESTCONF server implementation using JSON-only, that > would > > be very helpful. What's more, that sort of conformance might leave the > door > > open to add CoMI as a formal RESTCONF encoding in the future. > > > > Feedback is much appreciated. Thanks. > > > > ---------------------------- > > Rodney Cummings > > Principal Software Architect, Industrial/Embedded Networks > > National Instruments > > Tel: (512) 683-8544 > > Fax: (512) 683-8661 > > Email: Rodney.Cummings@ni.com > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --90e6ba613bca5dab34051818d7f6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The possibility of an entire segment of the tech industry:= namely IoT could embrace RESTCONF if we just create two categories RESTCON= F-XML and RESTCONF-JSON, then is seems like a great opportunity to gain mom= entum behind RFC.=C2=A0 It's unlikely to affect any implementations tod= ay as I'd bet money they all support JSON.



On Tue, Jun 9, 2015 at 12:50 PM Rodney= Cummings <rodney.cummings@ni.= com> wrote:
Thanks Andy,

I should have been clear on this p= oint. For the applications that I am targeting, the relevant IEEE 802.1 TSN stand= ards are currently in draft stage (not published), so even the hardware componen= ts are a work-in-progress. Therefore, the recommendation that I am attempting to make for the management protocol occurs with an understanding of the risks of using pre-publication IEEE / IETF standards. Although there are definitely folks in TSN who are eager to start with implementations, we understand that a draft can change in major ways, and therefore the impleme= ntation can change in major ways.

I'm looking at the problem as = "A few years in the future, when options 1, 2, 3, and 4 are in RFC form, which is the best fit for IoT applications?"

In my opinion, the answer will var= y depending on the requirements of each IoT application.

To help explain, let's refer b= ack to the previous thread on this topic that Kent referenced:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf= .org/mail-archive/web/netconf/current/msg09218.html
My suggestion is effectively a new= option e)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 e) Specify RESTCONF-XML and RESTCONF-JSON as distinct conformance categories (i.e. RESTCONF-JSON client interoperates with a RESTCONF-JSON server).
I realize that for a typical NMS c= lient, this is effectively the same as option d), because the NMS must interoperat= e with all possible servers.

Speaking as someone who will imple= ment both client and server, I am comfortable with option d). I can't speak for all clients, but my client is not constrained, but the servers are very constrained. In addition, the servers in my space are very opinionated as to what is "heavy" and what is "constrained" for their market space.

Some of the comments in the thread= debated the which-is-best angle... XML or JSON. In my opinion this is not relevant. The relevant question is:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Are there implementers out there who feel strongly that JSON is preferable to XML?
Whether I agree with the implement= ers or not, the answer is clearly Yes.

One or two comments in the thread = argued that implementation complexity does not matter. That may be a reasonable argument, but if you feel that way, I would suggest that you oppose RESTCON= F as a whole. If implementation complexity does not matter, the best course of action is to mandate full-featured NETCONF, and abort RESTCONF and CoMI. I assume that the benefit of applying RESTful methodology to the YANG data model is that it provides implementation flexibility that is a better fit to some use cases and applications.

I'll use a few IoT application= s as examples.

Smart Grid: A network of synchroph= asors can span an entire nation, which inherently implies the class of router that is used for Internet applications. This router can accommodate a full NETCONF implementation, and RESTCONF-XML provides another way to access the same XML information model. For this IoT application, the option a) fits just fine.

Field-level control on an industri= al factory floor: Historically, these networks were non-Ethernet busses, with simple binary data for network configuration. Over the past decade or so, the devices in these networks typically use Ethernet and IP, and they often implement a web server for configuration, using REST, JSON, TLS, and so on. Nevertheless, these devices are still sceptical of technologies that are viewed as heavy-weight, so I am concerned that XML-on-the-wire won'= t be universally accepted. If RESTCONF mandates option a) for this IoT applic= ation, this effectively boils down to a statement like:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 I know you love apples, and you hate oranges, but oranges are good for you, so you must eat an orange first, and then you can eat an apple.
This sort of argument is likely to= be rejected, because I can go elsewhere and buy an apple. It would be very helpful if RESTCONF would allow servers in this network to use RESTCONF-JSO= N. The client could mandate option d), but for this localized =C2=A0IoT applic= ation, option e) would also work. I appreciate Andy's suggestion that this app= lication could use CoMI, but given that this IoT application already implements REST-with-JSON, I'm sure you'll agree that CoMI is a strange recomm= endation. That is effectively saying that RESTCONF does not support JSON at all.

Control network inside a car: Toda= y, these networks are non-Ethernet busses with binary configuration. They are currently in the process of slowly integrating Ethernet. The processor in each controller typically runs "bare metal", with no operating system at all. Given these constraints, the network for this IoT applicatio= n is typically "preconfigured" (stored in NV memory when the car rolls out of the factory). Nevertheless, looking forward, there is discussi= on of using management, IP protocols, and so on. Given the lack of operating system infrastructure, CoMI will clearly be the best fit for this IoT appli= cation.

My point is that we want to bring = IETF technologies to these applications, and that includes YANG-based management= . If we insist on a one-size-fits-all approach, the IoT initiatives will succeed for some applications, and fail for others. I genuinely feel that YANG-based management is a great fit for all IoT applications, and I think that option d) or e) is the best way to go.

Nevertheless, I realize that the W= G has already made a decision on this, and a single voice of opposition certa= inly does not justify revisiting it. I'll try to encourage others in the IoT initiatives to voice opinion on this, but failing that, I'm happy to le= t the issue REST (no pun intended).

Rodney



From: =C2=A0 =C2= =A0 =C2=A0 =C2=A0Andy Bierman <andy@yumaworks.com>=
To: =C2=A0 =C2= =A0 =C2=A0 =C2=A0Rodney Cummings <rodney.cummings@ni.c= om>,
Cc: =C2=A0 =C2= =A0 =C2=A0 =C2=A0Netconf <netconf@ietf.org>
Date: =C2=A0 =C2= =A0 =C2=A0 =C2=A006/07/2015 08:31 PM
Subject: =C2=A0 = =C2=A0 =C2=A0 =C2=A0Re: [Netconf] Suggestion for RESTCONF section 5.3



Hi,

Only choice (1) is published in an RFC.
Options (2) - (4) are work-in-progress.
It is difficult to estimate how long an IETF RFC will take,
or how much it will change from the current draft to RFC.

IMO IoT should use (4), but wait for the RFC.
Participate in the CoMI work and it might get done faster.


Andy





On Fri, Jun 5, 2015 at 12:39 PM, Rodney Cummings <rodney.cummings@ni.com> wrote:
> Hello,
>
> Although I am new to the NETCONF WG and mailing list, I have a suggest= ion
> for the RESTCONF I-D that I'd like to discuss. I realize that I ma= y be
> bringing up a topic that has already been thoroughly discussed.
> Nevertheless, this issue is a genuine problem for deployment of RESTCO= NF for
> my applications, so if my suggestion is rejected, it will be helpful for me
> understand the rationale.
>
> Suggestion
> --
>
> Section 5.3 of the current I-D
> (https://tools.ietf.org= /html/draft-ietf-netconf-restconf-04) states:
>
> "Content is encoded in either JSON or XML format.=C2=A0 A server MUST support XML
> encoding and MAY support JSON encoding."
>
> My suggestion is to change section 5.3 to state:
>
> "Content is encoded in either JSON or XML format.=C2=A0 A client MUST support at
> least one of the specified encodings (XML or JSON), and a client SHOUL= D
> support all specified encodings.=C2=A0 A server MUST support at least one of the
> specified encodings (XML or JSON), and a server MAY support multiple > encodings."
>
> In other words, if a server wants to focus on JSON exclusively, allow that
> as a conformant implementation. The client has a presumed burden to support
> a server that is XML-only or JSON-only.
>
> Rationale
> --
>
> As part of a roadmap for supporting industrial IoT devices, the 802.1<= br> > Time-Sensitive Networking standards (TSN) are focusing on YANG modules for
> configuration of the low-level queuing behavior in 802.1 switches (e.g.
> schedule for traffic egress on each port). The assumption is that an
> SDN-style controller will use these YANG modules to write configuratio= n to
> each switch in the network in an automated manner. Ideally, as TSN moves
> forward it will be well-aligned with analogous IETF efforts, including CoRE,
> 6TiSCH, and DetNet (upcoming BoF in July).
>
> One near-term focus for the TSN effort is to support an IoT device (e.g.
> industrial motor, smart grid IED) that supports Ethernet today, but that
> wants to embed an 802.1 switch. The goal is to expose two external ports
> from the device, using the switch to enable topologies like daisy-chai= n and
> ring. This is commonly done today using proprietary Ethernet extension= s, but
> we want to transition industrial applications to 802/IETF standards (much
> like the 6TiSCH effort for wireless). The challenge is that although this
> IoT device is technically a switch/router, it is very "Operationa= l
> Technology" (OT). A YANG-based management protocol is required to configure
> the switch, but the switch supports a subset of what a standalone managed
> switch/router supports, and the switch will always be configured in-ba= nd
> from an OT controller, never from an IT-style NMS.
>
> From the perspective of one of these IoT device manufacturers, the primary
> question for management is:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 What YANG-based management protocol do I implement in my device?
> Among others, I've been tasked to help answer this question for TS= N and its
> related groups (e.g. AVnu.org/industrial). The assumption is that the
> manufacturer will use one and only one server implementation. Since the goal
> is not to support a traditional NMS, implementation of multiple server= s is
> not a goal (e.g. SNMPv3 and NETCONF and RESTCONF XML and so on).
>
> Based on this, I've been trying to choose among the following
> implementations in order to make a recommendation:
> 1. NETCONF with XML encoding
> 2. RESTCONF with XML encoding
> 3. RESTCONF with JSON encoding
> 4. CoMI with CBOR encoding
>
> For the industrial application space that I am evaluating, the devices are
> "constrained" as CoRE describes. Nevertheless, over the last few years it
> has become common for these devices to implement an HTTP web server for
> configuration. These web servers are often designed as RESTful. Given the
> constrained nature of the devices, they tend to use JSON, due to the > perception =C2=A0that XML parsing is less efficient.
>
> Based on these assumptions, I tend to exclude NETCONF. NETCONF is
> full-featured, but most of those features are relevant to NMS concerns= .
> Also, NETCONF's basis on XML raises a perception (if not reality) of complex
> implementation.
>
> CoMI looks promising, since it is based on relatively mature RFCs like CoAP
> and CBOR. Nevertheless, the CoMI I-D itself looks like it is
> not-quite-ready-for-prime-time. There are many TODOs, and the YANG hash
> seems like it will require more prototyping before it is truly nailed down.
> Given that, I can't really recommend that direction just yet, but ideally it
> will be useful in the future.
>
> That leaves RESTCONF. Since the industrial device manufacturers tend to be
> familiar with REST already, this is an easy sell. The I-D itself seems to be
> relatively mature.
>
> Ideally, I could recommend option 3, RESTCONF with JSON. That is the > cleanest fit to what industrial devices do today.
>
> Given the limitations of section 5.3 in v04 of the I-D, I would be forced to
> recommend option 2, RESTCONF with XML. If the IoT device is forced to
> implement XML for conformance, then the addition of JSON doesn't o= ffer much
> value, since the goal is automated configuration.
>
> If we could allow RESTCONF server implementation using JSON-only, that would
> be very helpful. What's more, that sort of conformance might leave the door
> open to add CoMI as a formal RESTCONF encoding in the future.
>
> Feedback is much appreciated. Thanks.
>
> ----------------------------
> Rodney Cummings
> Principal Software Architect, Industrial/Embedded Networks
> National Instruments
> Tel: (512) 683-8544
> Fax: (512) 683-8661
> Email: Rod= ney.Cummings@ni.com
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org=
> https://www.ietf.org/mailman/listinf= o/netconf
>
_______________________________________________
Netconf mailing list
Netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--90e6ba613bca5dab34051818d7f6-- From nobody Tue Jun 9 11:51:37 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2441B2E33 for ; Tue, 9 Jun 2015 11:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BkwxJWb7LJxz for ; Tue, 9 Jun 2015 11:51:33 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0726.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::726]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80DE31ACCE2 for ; Tue, 9 Jun 2015 11:51:32 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.1.172.22; Tue, 9 Jun 2015 18:51:11 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.121]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.121]) with mapi id 15.01.0184.014; Tue, 9 Jun 2015 18:51:11 +0000 From: Kent Watsen To: Netconf Thread-Topic: [Netconf] YANG Patch Issue #3: :distinct-startup Thread-Index: AQHQn7V+nTs/gEHKBUCSzfCLoklY1p2iSG2AgAAUEwCAAARBgIAAS84AgAADgwCAAAdzAIAAA7oAgADFgICAAMdGgA== Date: Tue, 9 Jun 2015 18:51:10 +0000 Message-ID: References: <20150608.102005.1482395931170643204.mbj@tail-f.com> <20150608094708.GA28936@elstar.local> <20150608143100.GD29788@elstar.local> <20150608151059.GB30068@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.11] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB460; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:CO1PR05MB460; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB460; x-forefront-prvs: 06022AA85F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(5383002)(51704005)(110136002)(77156002)(5001960100002)(86362001)(99286002)(561944003)(19580395003)(4001350100001)(189998001)(36756003)(107886002)(15395725005)(87936001)(50986999)(54356999)(66066001)(76176999)(2656002)(5002640100001)(2950100001)(1720100001)(122556002)(62966003)(450100001)(2900100001)(92566002)(46102003)(83506001)(102836002)(93886004)(106116001)(40100003)(15975445007)(19607625011); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <801936D11D55E64EB34EADC51F875904@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jun 2015 18:51:10.8385 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB460 Archived-At: Subject: Re: [Netconf] YANG Patch Issue #3: :distinct-startup X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 18:51:35 -0000 > Query parameter "nv-save" > > leaf nv-save { > if-feature nc:startup; > type boolean; > default true; > description > "If 'true' then save the edits to non-volatile storage. > If 'false' then do not save the edits to non-volatile > storage. Only applies to configuration edits."; > } > >POST/restconf/data/some/data1?nv-save=3Dfalse >POST /restconf/data/some/data2?nv-save=3Dfalse >POST /restconf/data/some/data3 > >The edits for data1 and data2 are not saved to startup. >The edit 'data3' saves all of running to startup. >Another client can do 'nv-save' before this one. >This client will save any edits to running, not just its own. >(Shared running datastore!) > >There is no read or write access directly to the NETCONF 'startup' >datastore. Access to datastores is a different topic. >This solution simply provides control over NV-storage >if the server supports it. How can a client save all of running to startup outside of an edit operation? E.g., make some changes, do some tests, persist running only if tests pass. Assuming the URL points to a data node (e.g., /restconf/data/), none of POST/PUT/DELETE seem to work. PATCH with an empty patch-set might work, but PATCH is optional, so not a good choice. The ietf-netconf:copy-config operation approach resolves the above concern but, since it doesn't support Etag, the client would have to do something like: 1. POST /restconf/operations/ietf-netconf:lock 2. HEAD /restconf/data (verify Etag is as expected) 3. POST /restconf/operations/ietf-netconf:copy-config 4. POST /restconf/operations/ietf-netconf:unlock Which looks dreadfully verbose > >Do you think this solution will work? >If not, do you have a different one? >=20 How about an "action" statement called "save" on the /restconf/data? POST /restconf/data/save HTTP/1.1 If-Match: c3a3e673bc2c ...or, as discussed off list before (see below), embrace NETCONF datastores in a RESTful manner, which would give: POST /restconf/running/save HTTP/1.1 If-Match: c3a3e673bc2c =3D=3D=3D=3D=3D FROM BEFORE =3D=3D=3D=3D=3D RESTCONF/NETCONF datastore gaps (in priority order): 1) no support for confirmed-commit, without which a NMS cannot safely push updates - i.e. w/o risking severing its connection to a networking device (router) 2) no support for 2-phase commit, which complicates (but not prevent) the ability to do an atomic update on a plurality of devices 3) no ability to explicitly save to persistent storage, which might drive devices to persist every update, which isn't necessarily what is wanted all the time. 4) no ability to ask device to validate contents of a candidate datastore, which is only useful in that on-box validations are some times more thorough than what might be captured in the YANG schema. Following is my RESTful proposal addressing all of the above. It includes support for confirmed-commit, 2-phase commit, explicit persistence, and validation. High-level sketch of solution: 1. let there be URL entry points (datastores) like: {+restconf}/running {+restconf}/startup {+restconf}/candidate 2. let each datastore have its own Last-Modified / ETag headers 3. let the "candidate" datastore, if one exists, have "validate" and "commit" actions/methods 4. let the "running" datastore have a "confirmed" action, only if a "candidate" datastore exists. 5. let the "running" datastore have a "save" action, only if a "startup" datastore exists. Concrete example below (validation, confirmed-commit, save to startup): 1) Update the candidate datastore: Request: PATCH /restconf/candidate/example-jukebox:jukebox/ library/artist=3DFoo%20Fighters/album=3DWasting%20Light HTTP/1.1 Host: example.com If-Match: a8389233a4a Content-Type: application/yang.data+json { "example-jukebox:album" : { "genre" : "example-jukebox:rock", "year" : 2011 } } Response: HTTP/1.1 204 No Content Date: Mon, 23 Apr 2012 17:49:30 GMT Server: example-server Last-Modified: Mon, 23 Apr 2012 17:49:30 GMT ETag: b2788923da4b 2) Request device to validate contents of candidate datastore - note use of If-Match Request: POST /restconf/candidate/validate HTTP/1.1 Host: example.com If-Match: b2788923da4b Response: HTTP/1.1 204 No Content <------ No errors Date: Mon, 23 Apr 2012 17:50:00 GMT Server: example-server ETag: b2788923da4b <------ SAME ETAG AS BEFORE SINCE DATASTORE UNCHANGED 3) Commit with a 2-minute confirmation timeout - note again the use of If-Match Request: POST /restconf/candidate/commit HTTP/1.1 Host: example.com If-Match: b2788923da4b <------ SAME ETAG AS BEFORE Content-Type: application/yang.operation+json { "confirm-timeout" : "120" } Response: HTTP/1.1 201 Created Date: Mon, 23 Apr 2012 17:01:00 GMT Server: example-server ETag: c3a3e673bc2c <------- THIS IS THE ETAG FOR THE UPDATED RUNNING DATASTORE 4) Confirm the commit (note use of If-Match) Request: POST /restconf/running/confirm HTTP/1.1 Host: example.com If-Match: c3a3e673bc2c <------ SAME AS BEFORE Response: HTTP/1.1 204 No Content <------ SUCCESS Date: Mon, 23 Apr 2012 17:50:00 GMT Server: example-server ETag: c3a3e673bc2c <------ SAME ETAG AS BEFORE SINCE DATASTORE UNCHANGED 5) Persist to startup datastore (note use of If-Match) Request: POST /restconf/running/save HTTP/1.1 Host: example.com If-Match: c3a3e673bc2c <------ SAME AS BEFORE Response: HTTP/1.1 204 No Content

The I2SR = Protocol Requirements will be passed to NETCONF later this week =

 

https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-re= qs (adopted by I2RS WG)

http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-= netconf-requirements : withdrawn

http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub= -requirements/ ( WG LC completed, consensus) 

http://datatracker.ietf.org/doc/draft-ietf-i2rs-traceab= ility/  WG LC complete, consensus  

 

Come and = discuss these at the I2RS Interim before the documents are passed to = NETCONF.

 

Sue Hares

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= o:p>

 

I2RS interim 6/10/2015

 

Agenda: =

 

0) Agenda Bashing [10:00 – 10:05] =

1) DiscussionI2RS Protocol = requirements for ephemeral state   [10:05 – 10:20] =

https://datatracker.ietf.org/doc/draft-haas-i2rs-epheme= ral-state-reqs

        presenter = (Jeff Haas)   

 

2) Review of = WG Adoption and WG LC

Discussion = on  All requirements including the following drafts = [10:20-10:30]  

 

http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-= netconf-requirements  - withdrawn

http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub= -requirements/ ( WG LC completed, consensus) 

http://datatracker.ietf.org/doc/draft-ietf-i2rs-traceab= ility/  WG LC complete, consensus

 

3) = draft-hares-i2rs-auth-transaction-00.txt  (WG Adoption 6/10 to = 6/24) [10:30-10:45]

 

4) Open = Discussion [10:45 to 11:15]

 

=

  http://etherpad.tools.ietf.org:9000/p/i2rs-= interim-Jun-10-2015-minutes

[Jeff = and Sue will be active in the discussions.  We appreciate any extra = note-takers]

 Meeting blue sheets:

   http://etherpad.tools.ietf.org:9000/p= /i2rs-interim-jun-10-2015-vBlueSheets

[Please sign up on the virtual Blue Sheets. = ]

 

         &= nbsp;      =             &= nbsp;     

 I2RS Interim 6/7

Wednesday, June 10, 2015

9:30 am  |  Eastern Daylight Time (New York, = GMT-04:00)  |  2 hrs

 

 

Join WebEx = meeting

= https://ietf.webex.com/ietf/j.php?MTID=3Dm82ee9ad7a04c2334cb77af58f195cf4= 8

 

Meeting number: =            648 859 109 =

Meeting = password:         = choice.is.yours

 

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: 648 859 = 109

 

 

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

 

------=_NextPart_000_0234_01D0A2D5.4F9EDF10-- From nobody Tue Jun 9 14:32:16 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53FB81A1B21; Tue, 9 Jun 2015 14:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.155 X-Spam-Level: X-Spam-Status: No, score=-97.155 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYu0fEIRb4aH; Tue, 9 Jun 2015 14:32:05 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7BB1A1B05; Tue, 9 Jun 2015 14:32:05 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=184.157.82.115; From: "Susan Hares" To: Date: Tue, 9 Jun 2015 17:31:54 -0400 Message-ID: <026e01d0a2fb$b52d99e0$1f88cda0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_026F_01D0A2DA.2E1DA790" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdCi90273nYdXGB4SLeA1ZmD/g423g== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Alia Atlas' , netconf@ietf.org, netmod@ietf.org Subject: [Netconf] WG documents for I2RS Protocol - WG calls 5/27 to 6/9 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 21:32:07 -0000 This is a multipart message in MIME format. ------=_NextPart_000_026F_01D0A2DA.2E1DA790 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The following I2RS Protocol Requirements will be passed to NETCONF later this week https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-reqs (adopted by I2RS WG) (will be sent as draft-ietf-i2rs-ephemeral-state-reqs) http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ ( WG LC completed, consensus) http://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/ WG LC complete, consensus Come and discuss these at the I2RS Interim before the documents are passed to NETCONF. Below are 10 requirements that NETCONF SHOULD meet. There has been debate on the I2RS list whether NETCONF can provide requirement 2. If you have an opinion on these requirements, the interim tomorrow is your chance to provide feedback before the requirements go to NETCONF. Sue Hares ============================================= 1. The I2RS protocol SHOULD support highly reliable notifications (but not perfectly reliable notifications) from an I2RS agent to an I2RS client. 2. The I2RS protocol SHOULD support a high bandwidth, asynchronous interface, with real-time guarantees on getting data from an I2RS agent by an I2RS client. 3. The I2RS protocol will operate on data models which may be protocol independent or protocol dependent. 4. I2RS Agent needs to record the client identity when a node is created or modified. The I2RS Agent needs to be able to read the client identity of a node and use the client identity's associated priority to resolve conflicts. The secondary identity is useful for traceability and may also be recorded. 5. Client identity will have only one priority for the client identity. A collision on writes is considered an error, but priority is utilized to compare requests from two different clients in order to modify an existing node entry. Only an entry from a client which is higher priority can modify an existing entry (First entry wins). Priority only has meaning at the time of use. 6. The Agent identity and the Client identity should be passed outside of the I2RS protocol in a authentication and authorization protocol (AAA). Client priority may be passed in the AAA protocol. The values of identities are originally set by operators, and not standardized. 7. An I2RS Client and I2RS Agent mutually authenticate each other based on pre-established authenticated identities. 8. Secondary identity data is read-only meta-data that is recorded by the I2RS agent associated with a data model's node is written, updated or deleted. Just like the primary identity, the secondary identity is only recorded when the data node is written or updated or deleted. 9. I2RS agent can have a lower priority I2RS client attempting to modify a higher priority client's entry in a data model. The filtering out of lower priority clients attempting to write or modify a higher priority client's entry in a data model SHOULD be effectively handled and not put an undue strain on the I2RS agent. Note: Jeff's suggests that priority is kept at the NACM at the client level (rather than the path level or the group level) will allow these lower priority clients to be filtered out using an extended NACM approach. This is only a suggestion of a method to provide the requirement 9. 10. The I2RS protocol MUST support the use of a secure transport. However, certain functions such as notifications MAY use a non-secure transport. Each model or service (notification, logging) must define within the model or service the valid uses of a non-secure transport. ------=_NextPart_000_026F_01D0A2DA.2E1DA790 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The = following I2RS Protocol Requirements will be passed to NETCONF later = this week

 

https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-re= qs (adopted by I2RS WG)

   (will be sent as = draft-ietf-i2rs-ephemeral-state-reqs)

http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub= -requirements/ ( WG LC completed, consensus) 

http://datatracker.ietf.org/doc/draft-ietf-i2rs-traceab= ility/  WG LC complete, consensus  

 

Come and = discuss these at the I2RS Interim before the documents are passed to = NETCONF.

 

Below are 10 requirements that NETCONF SHOULD = meet.  There has been debate on the I2RS list whether NETCONF can = provide requirement 2.  If you have an opinion on these = requirements,  the interim tomorrow is your chance to provide = feedback before the requirements go to NETCONF.  

 

Sue = Hares

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

 

 1.   The I2RS protocol SHOULD support = highly reliable notifications (but not perfectly reliable notifications) = from an I2RS agent to an  I2RS client.

 2.  =  The I2RS protocol SHOULD support a high bandwidth, asynchronous = interface, with real-time guarantees on getting data from an I2RS  = agent by an I2RS client.

3.  The I2RS protocol will operate = on data models which may be protocol independent or protocol = dependent.

 

4. I2RS Agent needs to = record the client identity when a node is created or modified. The I2RS = Agent needs to be able to read the client identity of a node and use the = client identity's associated priority to resolve conflicts.   = The secondary identity is useful for traceability and may also be = recorded.

 5.   Client identity will = have only one priority for the client identity. A collision on writes is = considered an error, but priority is utilized to compare requests from = two different clients in order to modify an existing node entry.  = Only an entry from a client which is higher priority can modify an = existing entry (First entry wins). Priority only has meaning at the time = of use.  

6.   The Agent identity and the Client = identity should be passed outside of the I2RS protocol in a = authentication and authorization  protocol (AAA).  Client = priority may be passed in the AAA protocol.  The values of = identities are originally set by operators, and not  standardized. =  

 7.  An I2RS Client and I2RS Agent mutually = authenticate each other based on pre-established authenticated = identities.  

 8. Secondary identity data is read-only = meta-data that is recorded by the I2RS agent associated with a data = model's node is written, updated or deleted. Just like the primary = identity, the secondary identity is only recorded when the data node is = written or updated or deleted. 

 9.   I2RS = agent can have a lower priority I2RS client attempting to modify a = higher priority client's entry in a data model.  The filtering out = of lower priority clients attempting to write or modify a higher = priority client's entry in a data model SHOULD be effectively handled = and not put an
undue strain on the I2RS agent.  =

Note:  Jeff's suggests that priority is kept at the NACM at = the client level (rather than the path level or the group level) will = allow these lower priority clients to be filtered out using an extended = NACM approach. This is only a suggestion of a method to provide the = requirement 9. 

10.  The = I2RS protocol MUST support the use of a secure transport. However, = certain functions such as notifications MAY use a non-secure = transport.  Each model or service (notification, logging) must = define within the model or service the valid uses of a non-secure = transport.

 

 

------=_NextPart_000_026F_01D0A2DA.2E1DA790-- From nobody Tue Jun 9 14:46:51 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 313E71A6ED9 for ; Tue, 9 Jun 2015 14:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tGLnCivZ4bW for ; Tue, 9 Jun 2015 14:46:48 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0111.outbound.protection.outlook.com [65.55.169.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4C611A1F00 for ; Tue, 9 Jun 2015 14:46:47 -0700 (PDT) Received: from CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) by CO1PR05MB348.namprd05.prod.outlook.com (10.141.52.22) with Microsoft SMTP Server (TLS) id 15.1.172.22; Tue, 9 Jun 2015 21:46:46 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.172.22; Tue, 9 Jun 2015 21:46:45 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.121]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.121]) with mapi id 15.01.0184.014; Tue, 9 Jun 2015 21:46:45 +0000 From: Kent Watsen To: t.petch , Alan Luchuk , "netconf@ietf.org" Thread-Topic: [Netconf] draft-ietf-netconf-call-home-05.txt Thread-Index: AQHQlMnODg1iNSV/nEqfYnzAyUNFnZ2R9YQAgAk0BUX//82dgIAJHwuFgAB4uYA= Date: Tue, 9 Jun 2015 21:46:45 +0000 Message-ID: References: <201505221959.t4MJxRHR081289@mainfs.snmp.com> <201506031817.t53IHJit066848@mainfs.snmp.com> <026301d0a29f$852a8340$4001a8c0@gateway.2wire.net> In-Reply-To: <026301d0a29f$852a8340$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: btconnect.com; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.11] x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB348; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520003)(3002001); SRVR:CO1PR05MB459; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; x-forefront-prvs: 06022AA85F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(164054003)(189998001)(19580395003)(5001770100001)(4001350100001)(2501003)(5002640100001)(36756003)(66066001)(83506001)(122556002)(107886002)(5001960100002)(2900100001)(77156002)(40100003)(86362001)(54356999)(50986999)(2656002)(76176999)(87936001)(46102003)(106116001)(92566002)(2950100001)(15975445007)(93886004)(99286002)(230783001)(102836002)(62966003)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <894FA7178FBF9A499FA8F80C3EBFB27B@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jun 2015 21:46:45.3853 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459 X-OriginatorOrg: juniper.net Archived-At: Subject: Re: [Netconf] draft-ietf-netconf-call-home-05.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 21:46:50 -0000 Hi Tom, >>No new split infinitives? ;) > >No but there might be the avoidance thereof in S4 >"the server MUST also send any intermediate certificates leading up to >the trust anchor the clients are expected use to authenticate it. " Good catch, this is what I have now: If a certificate is sent, the server MUST also send any intermediate certificates leading up to the trust anchor the client will use to authenticate the server's certificate with. OK? >And in s.4, " This reversal is incongruous with [RFC4253], ", I wonder >if incongruent is intended. Searching "incongruous vs incongruent" returns a surprising number of responses. It seems that this is a common question! My reading is that "incongruous" is the better option here, so I plan to leave it as it is. >One issue from earlier is what methods of authentication are acceptable. >5539bis now says X.509 certificate, RFC6242 is silent; I don't know >where Restconf is heading. This I-D sort of implies that servers will >only offer certificates or host keys, in which case I would like to see >that made explicit. True, RFC6242 is silent, for which I'm happy as it extends it to support RFC 6187. RESTCONF, like 5539bis, is also exclusively X.509: https://tools.ietf.org/html/draft-ietf-netconf-restconf-05#section-2.2. I'm not sure what to do about your last comment - any concrete suggestions? It is relatively easy to lock TLS to X.509, but SSH is all over the map. SSH calls it a "host key" (RFC 4251, Section-4.1), and host keys correspond to public key algorithms (RFC 4253, Section 7.1), and there are a number of algorithms (http://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-pa rameters-19), some using certificates (e.g., RFC 6187). So an SSH host key can be a certificate too... >On client authentication by servers, we seem not to require it. I have >read and re-read >"3. The NETCONF or RESTCONF Server >3.1. Protocol Operation " >and can see no mention thereof. We have this on the client side: C7 After the server's host key or certificate is validated, the SSH or TLS protocol proceeds as normal to establish a SSH or TLS connection. Where "proceeds as normal" is intended to include the client authentication step. The closest equivalent on the server side is in the beginning go S5: S5 Once the SSH or TLS connection is established, the ... Where it's only tangentially implied. Complicating matters, client auth in RESTCONF only occurs in the secure transport when using the ClientCertificate authentication scheme. When using either the Basic or Digest authentication schemes, authentication occurs post-TLS in the HTTP layer. So implying client authentication always occurs as part of TLS connection establishment is not entirely accurate. =20 This is why I was trying to hide all the client authentication steps behind the "proceeds as normal" clause and similar clauses in C8 and S5 regarding starting the NETCONF/RESTCONF protocols. I'm weary of this exploding into a lot of text. Can you suggest a simple fix? Thanks, Kent From nobody Tue Jun 9 23:48:56 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D21AE1A1AAA for ; Tue, 9 Jun 2015 23:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qjyx7CxPptV for ; Tue, 9 Jun 2015 23:48:52 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B645D1A1B48 for ; Tue, 9 Jun 2015 23:48:52 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D63A41476; Wed, 10 Jun 2015 08:48:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id OUADEmmEAYMI; Wed, 10 Jun 2015 08:48:48 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 10 Jun 2015 08:48:50 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 576BA20013; Wed, 10 Jun 2015 08:48:50 +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 ytfxWQCXmgsw; Wed, 10 Jun 2015 08:48:59 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2F0072002B; Wed, 10 Jun 2015 08:48:49 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 61907344D089; Wed, 10 Jun 2015 08:48:46 +0200 (CEST) Date: Wed, 10 Jun 2015 08:48:45 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20150610064843.GA36156@elstar.local> Mail-Followup-To: Andy Bierman , Kent Watsen , Netconf References: <20150608.102005.1482395931170643204.mbj@tail-f.com> <20150608094708.GA28936@elstar.local> <20150608143100.GD29788@elstar.local> <20150608151059.GB30068@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Netconf Subject: Re: [Netconf] YANG Patch Issue #3: :distinct-startup X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 06:48:55 -0000 On Tue, Jun 09, 2015 at 12:16:06PM -0700, Andy Bierman wrote: > > IMO this issue should move to DEAD because there is no > agreement on the scope of the problem and no agreement > on any solution. > I do not think declaring issues DEAD can be a default solution for the (sometimes painful process) of finding rough consensus. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Jun 10 00:44:18 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 464A41AC43D for ; Wed, 10 Jun 2015 00:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3LKt2hCaQvZ4 for ; Wed, 10 Jun 2015 00:44:16 -0700 (PDT) Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADFFE1AC435 for ; Wed, 10 Jun 2015 00:44:15 -0700 (PDT) Received: by labko7 with SMTP id ko7so27184212lab.2 for ; Wed, 10 Jun 2015 00:44:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=YAlWs/NPM2clz43l/TiMnAznJ1t9OYnV/d3Ku3O0rRQ=; b=GUwJM9sON/3c+SQnOc1s8bT5Tj8ss8x4bGP4QO+6g/nk+ZQ62J4VaU9BPkZM5jccMd gBE8PTUrF7ke1JTVwaJLmV4eQeMEkylZaYoqId2747rRF9YTMxuUzdI/4W4r3TejqaSW SKspkTWKVoySj9KyQMNV/FIbS0CHAxoAjiZdPpHU/tcXEWUGVYYwnflwgCx3qRwGhZ2I MG+T5Qc3GdjpPCK6pLqIMaEMGSu36umtcSm/opeJ9Xq/lPdx7SJC44C8xhZo1gbpqOq8 JhZiavRccll7KD0tyVyifZXEwS9FZDmJdoiDwVosZSKiokMXLEJZjUNznk8s1uQ1FtOX vSIw== X-Gm-Message-State: ALoCoQnQo/unGoYauzIclG2RA4sZ1bOEpIP5URSTDgpSM4siaFSfE6OX75AlS0fXVNuiuTThB6p4 MIME-Version: 1.0 X-Received: by 10.152.43.69 with SMTP id u5mr1791941lal.119.1433922254187; Wed, 10 Jun 2015 00:44:14 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Wed, 10 Jun 2015 00:44:14 -0700 (PDT) In-Reply-To: <20150610064843.GA36156@elstar.local> References: <20150608.102005.1482395931170643204.mbj@tail-f.com> <20150608094708.GA28936@elstar.local> <20150608143100.GD29788@elstar.local> <20150608151059.GB30068@elstar.local> <20150610064843.GA36156@elstar.local> Date: Wed, 10 Jun 2015 00:44:14 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Kent Watsen , Netconf Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Netconf] YANG Patch Issue #3: :distinct-startup X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 07:44:17 -0000 On Tue, Jun 9, 2015 at 11:48 PM, Juergen Schoenwaelder wrote: > On Tue, Jun 09, 2015 at 12:16:06PM -0700, Andy Bierman wrote: >> >> IMO this issue should move to DEAD because there is no >> agreement on the scope of the problem and no agreement >> on any solution. >> > > I do not think declaring issues DEAD can be a default solution > for the (sometimes painful process) of finding rough consensus. > The default is to not make a change if there is no agreement on the change. The draft has never had a "save-to-NV" button. The default will be to keep it that way. > /js Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Wed Jun 10 01:41:39 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3017C1ACD8F for ; Wed, 10 Jun 2015 01:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.588 X-Spam-Level: X-Spam-Status: No, score=-1.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSx91v_Q_U56 for ; Wed, 10 Jun 2015 01:41:35 -0700 (PDT) Received: from webmail3.hi.local (www.outitgoes.com [79.170.40.67]) (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 B2C801ACD8C for ; Wed, 10 Jun 2015 01:41:35 -0700 (PDT) Received: from localhost ([127.0.0.1]) by webmail3.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1Z2bZi-0000MN-AM; Wed, 10 Jun 2015 09:41:30 +0100 Message-Id: <80301e1e1232317992099edfe168d2936a6f9d1a@webmail.hansfords.net> From: "Jonathan Hansford" To: "Kent Watsen" , "t.petch" , "Alan Luchuk" , netconf@ietf.org X-Mailer: Atmail 6.6.0.11156 X-Originating-IP: 10.0.1.196 in-reply-to: Date: Wed, 10 Jun 2015 09:41:30 +0100 Content-Type: multipart/alternative; boundary="=_e80589f37c7a483612c59a31894c4f55" MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] draft-ietf-netconf-call-home-05.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 08:41:38 -0000 --=_e80589f37c7a483612c59a31894c4f55 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Kent,=0A=0ARe S4, the resulting sentence feels a little clumsy and th= e intent is=0Anot that clear to me. Presumably the intent is that "the s= erver MUST=0Asend any intermediate certificates the client will use to a= uthenticate=0Athe server's certificate" and the "leading up to the trust= anchor" is=0Aprovided as context. Should it not also be "all" rather th= an "any"?=0AHow about:=0AIf a certificate is sent, the server MUST also= send all intermediate=0Acertificates leading up to the trust anchor. Th= ese will be used by the=0Aclient to=0Aauthenticate the server's certific= ate.=0AJonathan=0A----- Original Message -----=0AFrom: "Kent Watsen" =0A= To:"t.petch" , "Alan Luchuk" , "netconf@ietf.org" =0ACc:=0ASent:Tue, 9 J= un 2015 21:46:45 +0000=0ASubject:Re: [Netconf] draft-ietf-netconf-call-h= ome-05.txt=0A=0A Hi Tom,=0A=0A >>No new split infinitives? ;)=0A >=0A >N= o but there might be the avoidance thereof in S4=0A >"the server MUST al= so send any intermediate certificates leading up=0Ato=0A >the trust anch= or the clients are expected use to authenticate it. "=0A=0A Good catch,= this is what I have now:=0A=0A If a certificate is sent, the server MUS= T also send any intermediate=0A certificates leading up to the trust anc= hor the client will use to=0A authenticate the server's certificate with= =0A=0A OK?=0A=0A >And in s.4, " This reversal is incongruous with [RFC4= 253], ", I=0Awonder=0A >if incongruent is intended.=0A=0A Searching "inc= ongruous vs incongruent" returns a surprising number of=0A responses. It= seems that this is a common question! My reading is=0Athat=0A "incongru= ous" is the better option here, so I plan to leave it as it=0Ais.=0A=0A= >One issue from earlier is what methods of authentication are=0Aaccepta= ble.=0A >5539bis now says X.509 certificate, RFC6242 is silent; I don't= know=0A >where Restconf is heading. This I-D sort of implies that serve= rs=0Awill=0A >only offer certificates or host keys, in which case I woul= d like to=0Asee=0A >that made explicit.=0A=0A True, RFC6242 is silent, f= or which I'm happy as it extends it to=0Asupport=0A RFC 6187. RESTCONF,= like 5539bis, is also exclusively X.509:=0A https://tools.ietf.org/html= /draft-ietf-netconf-restconf-05#section-2.2.=0A I'm not sure what to do= about your last comment - any concrete=0Asuggestions?=0A=0A It is relat= ively easy to lock TLS to X.509, but SSH is all over the=0Amap.=0A SSH c= alls it a "host key" (RFC 4251, Section-4.1), and host keys=0A correspon= d to public key algorithms (RFC 4253, Section 7.1), and=0Athere are=0A a= number of algorithms=0A (http://www.iana.org/assignments/ssh-parameters= /ssh-parameters.xhtml#ssh-pa=0A rameters-19), some using certificates (e= g., RFC 6187). So an SSH=0Ahost=0A key can be a certificate too...=0A= =0A >On client authentication by servers, we seem not to require it. I= =0Ahave=0A >read and re-read=0A >"3. The NETCONF or RESTCONF Server=0A >= 3.1. Protocol Operation "=0A >and can see no mention thereof.=0A=0A We h= ave this on the client side:=0A=0A C7 After the server's host key or cer= tificate is validated, the SSH=0A or TLS protocol proceeds as normal to= establish a SSH or TLS=0A connection.=0A=0A Where "proceeds as normal"= is intended to include the client=0A authentication step. The closest e= quivalent on the server side is in=0Athe=0A beginning go S5:=0A=0A S5 On= ce the SSH or TLS connection is established, the ...=0A=0A Where it's on= ly tangentially implied.=0A=0A Complicating matters, client auth in REST= CONF only occurs in the=0Asecure=0A transport when using the ClientCerti= ficate authentication scheme.=0AWhen=0A using either the Basic or Digest= authentication schemes,=0Aauthentication=0A occurs post-TLS in the HTTP= layer. So implying client authentication=0A always occurs as part of TL= S connection establishment is not entirely=0A accurate. =0A=0A This is w= hy I was trying to hide all the client authentication steps=0A behind th= e "proceeds as normal" clause and similar clauses in C8 and=0AS5=0A rega= rding starting the NETCONF/RESTCONF protocols. I'm weary of this=0A expl= oding into a lot of text. Can you suggest a simple fix?=0A=0A Thanks,=0A= Kent=0A=0A _______________________________________________=0A Netconf m= ailing list=0A Netconf@ietf.org=0A https://www.ietf.org/mailman/listinfo= /netconf=0A --=_e80589f37c7a483612c59a31894c4f55 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Kent,

Re S4, the resulting s= entence feels a little clumsy and the intent is not that clear to me. Pr= esumably the intent is that "the server MUST send any intermediate certi= ficates the client will use to authenticate the server's certificate" an= d the "leading up to the trust anchor" is provided as context. Should it= not also be "all" rather than "any"? How about:

<= div>If a certificate is sent, the server MUST also send all intermediate=
certificates leading up to the trust anchor. These will be used by= the client to
authenticate the server's certificate.
Jonathan

----- Original Messag= e -----
From:
"Kent Watsen" <kwatsen@junip= er.net>

To:
"t.petch= " <ietfc@btconnect.com>, "Alan Luchuk" <luchuk@snmp.com>, "n= etconf@ietf.org" <netconf@ietf.org>
Cc:

Sent:
Tue,= 9 Jun 2015 21:46:45 +0000
Subject= :
Re: [Netconf] draft-ietf-netconf-call-home-05.txt

=0AHi Tom,


=0A>>No new split infinitives? ;)<= br />=0A>
=0A>No but there might be the avoidance thereof in= S4
=0A>"the server MUST also send any intermediate certificates= leading up to
=0A>the trust anchor the clients are expected use= to authenticate it. "

=0AGood catch, this is what I have no= w:

=0A If a certificate is sent, the server MUST also send= any intermediate
=0A certificates leading up to the trust anchor= the client will use to
=0A authenticate the server's certificate= with.

=0AOK?




=0A>And in s.4,= " This reversal is incongruous with [RFC4253], ", I wonder
=0A>= if incongruent is intended.

=0ASearching "incongruous vs inco= ngruent" returns a surprising number of
=0Aresponses. It seems tha= t this is a common question! My reading is that
=0A"incongruous" i= s the better option here, so I plan to leave it as it is.


=0A>One issue from earlier is what methods of authentication= are acceptable.
=0A>5539bis now says X.509 certificate, RFC624= 2 is silent; I don't know
=0A>where Restconf is heading. This I= -D sort of implies that servers will
=0A>only offer certificates= or host keys, in which case I would like to see
=0A>that made e= xplicit.

=0ATrue, RFC6242 is silent, for which I'm happy as i= t extends it to support
=0ARFC 6187. RESTCONF, like 5539bis, is al= so exclusively X.509:
=0Ahttps://tools.ietf.org/html/draft-ietf-net= conf-restconf-05#section-2.2.
=0AI'm not sure what to do about your= last comment - any concrete suggestions?

=0AIt is relatively= easy to lock TLS to X.509, but SSH is all over the map.
=0ASSH cal= ls it a "host key" (RFC 4251, Section-4.1), and host keys
=0Acorres= pond to public key algorithms (RFC 4253, Section 7.1), and there are=0Aa number of algorithms
=0A(http://www.iana.org/assignments/ss= h-parameters/ssh-parameters.xhtml#ssh-pa
=0Arameters-19), some usin= g certificates (e.g., RFC 6187). So an SSH host
=0Akey can be a ce= rtificate too...



=0A>On client authentication= by servers, we seem not to require it. I have
=0A>read and re-= read
=0A>"3. The NETCONF or RESTCONF Server
=0A>3.1. P= rotocol Operation "
=0A>and can see no mention thereof.
=0AWe have this on the client side:

=0A C7 After the se= rver's host key or certificate is validated, the SSH
=0A or T= LS protocol proceeds as normal to establish a SSH or TLS
=0A = connection.


=0AWhere "proceeds as normal" is intended= to include the client
=0Aauthentication step. The closest equival= ent on the server side is in the
=0Abeginning go S5:

=0A= S5 Once the SSH or TLS connection is established, the ...


=0AWhere it's only tangentially implied.

=0AComplicati= ng matters, client auth in RESTCONF only occurs in the secure
=0Atr= ansport when using the ClientCertificate authentication scheme. When=0Ausing either the Basic or Digest authentication schemes, authentic= ation
=0Aoccurs post-TLS in the HTTP layer. So implying client aut= hentication
=0Aalways occurs as part of TLS connection establishmen= t is not entirely
=0Aaccurate.

=0AThis is why I was tr= ying to hide all the client authentication steps
=0Abehind the "pro= ceeds as normal" clause and similar clauses in C8 and S5
=0Aregardi= ng starting the NETCONF/RESTCONF protocols. I'm weary of this
=0Ae= xploding into a lot of text. Can you suggest a simple fix?

<= br />
=0AThanks,
=0AKent

=0A_______________________= ________________________
=0ANetconf mailing list
=0ANetconf@ie= tf.org
=0Ahttps://www.ietf.org/mailman/listinfo/netconf
--=_e80589f37c7a483612c59a31894c4f55-- From nobody Wed Jun 10 02:06:51 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABB211ACDCA for ; Wed, 10 Jun 2015 02:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1x1uTEYkdb7 for ; Wed, 10 Jun 2015 02:06:49 -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 591541ACDC9 for ; Wed, 10 Jun 2015 02:06:49 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id BBFB810CD; Wed, 10 Jun 2015 11:06:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 4SnGfJL2x8aO; Wed, 10 Jun 2015 11:06:44 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 10 Jun 2015 11:06:46 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8BB562002C; Wed, 10 Jun 2015 11:06:46 +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 ijZGXIpz4qLR; Wed, 10 Jun 2015 11:06: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 1D5C820013; Wed, 10 Jun 2015 11:06:43 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 64C95344D64F; Wed, 10 Jun 2015 11:06:42 +0200 (CEST) Date: Wed, 10 Jun 2015 11:06:42 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20150610090640.GC36604@elstar.local> Mail-Followup-To: Andy Bierman , Kent Watsen , Netconf References: <20150608094708.GA28936@elstar.local> <20150608143100.GD29788@elstar.local> <20150608151059.GB30068@elstar.local> <20150610064843.GA36156@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Netconf Subject: Re: [Netconf] YANG Patch Issue #3: :distinct-startup X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 09:06:50 -0000 On Wed, Jun 10, 2015 at 12:44:14AM -0700, Andy Bierman wrote: > On Tue, Jun 9, 2015 at 11:48 PM, Juergen Schoenwaelder > wrote: > > On Tue, Jun 09, 2015 at 12:16:06PM -0700, Andy Bierman wrote: > >> > >> IMO this issue should move to DEAD because there is no > >> agreement on the scope of the problem and no agreement > >> on any solution. > >> > > > > I do not think declaring issues DEAD can be a default solution > > for the (sometimes painful process) of finding rough consensus. > > The default is to not make a change if > there is no agreement on the change. > The draft has never had a "save-to-NV" button. > The default will be to keep it that way. The I-D must document WG consensus. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Jun 10 04:03:27 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 727891ACEC1 for ; Wed, 10 Jun 2015 04:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRBY-Y5fV1Kz for ; Wed, 10 Jun 2015 04:03:21 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 0CDDD1ACED3 for ; Wed, 10 Jun 2015 04:03:20 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 707001CC0837; Wed, 10 Jun 2015 13:03:18 +0200 (CEST) From: Ladislav Lhotka To: Rodney Cummings , Andy Bierman In-Reply-To: References: User-Agent: Notmuch/0.19 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Wed, 10 Jun 2015 13:03:18 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: Netconf Subject: Re: [Netconf] Suggestion for RESTCONF section 5.3 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 11:03:25 -0000 Hi Rodney, if you read all of that juicy thread, it should come as no surprise that I fully agree with you. In fact, I already advocated your option (e) back then: https://www.ietf.org/mail-archive/web/netconf/current/msg09245.html Lada Rodney Cummings writes: > Thanks Andy, > > I should have been clear on this point. For the applications that I am > targeting, the relevant IEEE 802.1 TSN standards are currently in draft > stage (not published), so even the hardware components are a > work-in-progress. Therefore, the recommendation that I am attempting to > make for the management protocol occurs with an understanding of the risks > of using pre-publication IEEE / IETF standards. Although there are > definitely folks in TSN who are eager to start with implementations, we > understand that a draft can change in major ways, and therefore the > implementation can change in major ways. > > I'm looking at the problem as "A few years in the future, when options 1, > 2, 3, and 4 are in RFC form, which is the best fit for IoT applications?" > > In my opinion, the answer will vary depending on the requirements of each > IoT application. > > To help explain, let's refer back to the previous thread on this topic > that Kent referenced: > > https://www.ietf.org/mail-archive/web/netconf/current/msg09218.html > My suggestion is effectively a new option e) > e) Specify RESTCONF-XML and RESTCONF-JSON as distinct conformance > categories (i.e. RESTCONF-JSON client interoperates with a RESTCONF-JSON > server). > I realize that for a typical NMS client, this is effectively the same as > option d), because the NMS must interoperate with all possible servers. > > Speaking as someone who will implement both client and server, I am > comfortable with option d). I can't speak for all clients, but my client > is not constrained, but the servers are very constrained. In addition, the > servers in my space are very opinionated as to what is "heavy" and what is > "constrained" for their market space. > > Some of the comments in the thread debated the which-is-best angle... XML > or JSON. In my opinion this is not relevant. The relevant question is: > Are there implementers out there who feel strongly that JSON is > preferable to XML? > Whether I agree with the implementers or not, the answer is clearly Yes. > > One or two comments in the thread argued that implementation complexity > does not matter. That may be a reasonable argument, but if you feel that > way, I would suggest that you oppose RESTCONF as a whole. If > implementation complexity does not matter, the best course of action is to > mandate full-featured NETCONF, and abort RESTCONF and CoMI. I assume that > the benefit of applying RESTful methodology to the YANG data model is that > it provides implementation flexibility that is a better fit to some use > cases and applications. > > I'll use a few IoT applications as examples. > > Smart Grid: A network of synchrophasors can span an entire nation, which > inherently implies the class of router that is used for Internet > applications. This router can accommodate a full NETCONF implementation, > and RESTCONF-XML provides another way to access the same XML information > model. For this IoT application, the option a) fits just fine. > > Field-level control on an industrial factory floor: Historically, these > networks were non-Ethernet busses, with simple binary data for network > configuration. Over the past decade or so, the devices in these networks > typically use Ethernet and IP, and they often implement a web server for > configuration, using REST, JSON, TLS, and so on. Nevertheless, these > devices are still sceptical of technologies that are viewed as > heavy-weight, so I am concerned that XML-on-the-wire won't be universally > accepted. If RESTCONF mandates option a) for this IoT application, this > effectively boils down to a statement like: > I know you love apples, and you hate oranges, but oranges are good > for you, so you must eat an orange first, and then you can eat an apple. > This sort of argument is likely to be rejected, because I can go elsewhere > and buy an apple. It would be very helpful if RESTCONF would allow servers > in this network to use RESTCONF-JSON. The client could mandate option d), > but for this localized IoT application, option e) would also work. I > appreciate Andy's suggestion that this application could use CoMI, but > given that this IoT application already implements REST-with-JSON, I'm > sure you'll agree that CoMI is a strange recommendation. That is > effectively saying that RESTCONF does not support JSON at all. > > Control network inside a car: Today, these networks are non-Ethernet > busses with binary configuration. They are currently in the process of > slowly integrating Ethernet. The processor in each controller typically > runs "bare metal", with no operating system at all. Given these > constraints, the network for this IoT application is typically > "preconfigured" (stored in NV memory when the car rolls out of the > factory). Nevertheless, looking forward, there is discussion of using > management, IP protocols, and so on. Given the lack of operating system > infrastructure, CoMI will clearly be the best fit for this IoT > application. > > My point is that we want to bring IETF technologies to these applications, > and that includes YANG-based management. If we insist on a > one-size-fits-all approach, the IoT initiatives will succeed for some > applications, and fail for others. I genuinely feel that YANG-based > management is a great fit for all IoT applications, and I think that > option d) or e) is the best way to go. > > Nevertheless, I realize that the WG has already made a decision on this, > and a single voice of opposition certainly does not justify revisiting it. > I'll try to encourage others in the IoT initiatives to voice opinion on > this, but failing that, I'm happy to let the issue REST (no pun intended). > > Rodney > > > > From: Andy Bierman > To: Rodney Cummings , > Cc: Netconf > Date: 06/07/2015 08:31 PM > Subject: Re: [Netconf] Suggestion for RESTCONF section 5.3 > > > > Hi, > > Only choice (1) is published in an RFC. > Options (2) - (4) are work-in-progress. > It is difficult to estimate how long an IETF RFC will take, > or how much it will change from the current draft to RFC. > > IMO IoT should use (4), but wait for the RFC. > Participate in the CoMI work and it might get done faster. > > > Andy > > > > > > On Fri, Jun 5, 2015 at 12:39 PM, Rodney Cummings > wrote: >> Hello, >> >> Although I am new to the NETCONF WG and mailing list, I have a > suggestion >> for the RESTCONF I-D that I'd like to discuss. I realize that I may be >> bringing up a topic that has already been thoroughly discussed. >> Nevertheless, this issue is a genuine problem for deployment of RESTCONF > for >> my applications, so if my suggestion is rejected, it will be helpful for > me >> understand the rationale. >> >> Suggestion >> -- >> >> Section 5.3 of the current I-D >> (https://tools.ietf.org/html/draft-ietf-netconf-restconf-04) states: >> >> "Content is encoded in either JSON or XML format. A server MUST support > XML >> encoding and MAY support JSON encoding." >> >> My suggestion is to change section 5.3 to state: >> >> "Content is encoded in either JSON or XML format. A client MUST support > at >> least one of the specified encodings (XML or JSON), and a client SHOULD >> support all specified encodings. A server MUST support at least one of > the >> specified encodings (XML or JSON), and a server MAY support multiple >> encodings." >> >> In other words, if a server wants to focus on JSON exclusively, allow > that >> as a conformant implementation. The client has a presumed burden to > support >> a server that is XML-only or JSON-only. >> >> Rationale >> -- >> >> As part of a roadmap for supporting industrial IoT devices, the 802.1 >> Time-Sensitive Networking standards (TSN) are focusing on YANG modules > for >> configuration of the low-level queuing behavior in 802.1 switches (e.g. >> schedule for traffic egress on each port). The assumption is that an >> SDN-style controller will use these YANG modules to write configuration > to >> each switch in the network in an automated manner. Ideally, as TSN moves >> forward it will be well-aligned with analogous IETF efforts, including > CoRE, >> 6TiSCH, and DetNet (upcoming BoF in July). >> >> One near-term focus for the TSN effort is to support an IoT device (e.g. >> industrial motor, smart grid IED) that supports Ethernet today, but that >> wants to embed an 802.1 switch. The goal is to expose two external ports >> from the device, using the switch to enable topologies like daisy-chain > and >> ring. This is commonly done today using proprietary Ethernet extensions, > but >> we want to transition industrial applications to 802/IETF standards > (much >> like the 6TiSCH effort for wireless). The challenge is that although > this >> IoT device is technically a switch/router, it is very "Operational >> Technology" (OT). A YANG-based management protocol is required to > configure >> the switch, but the switch supports a subset of what a standalone > managed >> switch/router supports, and the switch will always be configured in-band >> from an OT controller, never from an IT-style NMS. >> >> From the perspective of one of these IoT device manufacturers, the > primary >> question for management is: >> What YANG-based management protocol do I implement in my device? >> Among others, I've been tasked to help answer this question for TSN and > its >> related groups (e.g. AVnu.org/industrial). The assumption is that the >> manufacturer will use one and only one server implementation. Since the > goal >> is not to support a traditional NMS, implementation of multiple servers > is >> not a goal (e.g. SNMPv3 and NETCONF and RESTCONF XML and so on). >> >> Based on this, I've been trying to choose among the following >> implementations in order to make a recommendation: >> 1. NETCONF with XML encoding >> 2. RESTCONF with XML encoding >> 3. RESTCONF with JSON encoding >> 4. CoMI with CBOR encoding >> >> For the industrial application space that I am evaluating, the devices > are >> "constrained" as CoRE describes. Nevertheless, over the last few years > it >> has become common for these devices to implement an HTTP web server for >> configuration. These web servers are often designed as RESTful. Given > the >> constrained nature of the devices, they tend to use JSON, due to the >> perception that XML parsing is less efficient. >> >> Based on these assumptions, I tend to exclude NETCONF. NETCONF is >> full-featured, but most of those features are relevant to NMS concerns. >> Also, NETCONF's basis on XML raises a perception (if not reality) of > complex >> implementation. >> >> CoMI looks promising, since it is based on relatively mature RFCs like > CoAP >> and CBOR. Nevertheless, the CoMI I-D itself looks like it is >> not-quite-ready-for-prime-time. There are many TODOs, and the YANG hash >> seems like it will require more prototyping before it is truly nailed > down. >> Given that, I can't really recommend that direction just yet, but > ideally it >> will be useful in the future. >> >> That leaves RESTCONF. Since the industrial device manufacturers tend to > be >> familiar with REST already, this is an easy sell. The I-D itself seems > to be >> relatively mature. >> >> Ideally, I could recommend option 3, RESTCONF with JSON. That is the >> cleanest fit to what industrial devices do today. >> >> Given the limitations of section 5.3 in v04 of the I-D, I would be > forced to >> recommend option 2, RESTCONF with XML. If the IoT device is forced to >> implement XML for conformance, then the addition of JSON doesn't offer > much >> value, since the goal is automated configuration. >> >> If we could allow RESTCONF server implementation using JSON-only, that > would >> be very helpful. What's more, that sort of conformance might leave the > door >> open to add CoMI as a formal RESTCONF encoding in the future. >> >> Feedback is much appreciated. Thanks. >> >> ---------------------------- >> Rodney Cummings >> Principal Software Architect, Industrial/Embedded Networks >> National Instruments >> Tel: (512) 683-8544 >> Fax: (512) 683-8661 >> Email: Rodney.Cummings@ni.com >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jun 10 04:43:01 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF811AD0B7 for ; Wed, 10 Jun 2015 04:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XyQ0roIW8axR for ; Wed, 10 Jun 2015 04:42:58 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id F358A1AD0B2 for ; Wed, 10 Jun 2015 04:42:57 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id C5ADB1CC0837; Wed, 10 Jun 2015 13:42:56 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder , Andy Bierman In-Reply-To: <20150610090640.GC36604@elstar.local> References: <20150608094708.GA28936@elstar.local> <20150608143100.GD29788@elstar.local> <20150608151059.GB30068@elstar.local> <20150610064843.GA36156@elstar.local> <20150610090640.GC36604@elstar.local> User-Agent: Notmuch/0.19 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Wed, 10 Jun 2015 13:42:56 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: Netconf Subject: Re: [Netconf] YANG Patch Issue #3: :distinct-startup X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 11:42:59 -0000 Juergen Schoenwaelder writes: > On Wed, Jun 10, 2015 at 12:44:14AM -0700, Andy Bierman wrote: >> On Tue, Jun 9, 2015 at 11:48 PM, Juergen Schoenwaelder >> wrote: >> > On Tue, Jun 09, 2015 at 12:16:06PM -0700, Andy Bierman wrote: >> >> >> >> IMO this issue should move to DEAD because there is no >> >> agreement on the scope of the problem and no agreement >> >> on any solution. >> >> >> > >> > I do not think declaring issues DEAD can be a default solution >> > for the (sometimes painful process) of finding rough consensus. >> >> The default is to not make a change if >> there is no agreement on the change. >> The draft has never had a "save-to-NV" button. >> The default will be to keep it that way. > > The I-D must document WG consensus. FWIW, I am with Andy on this one. RESTCONF servers needn't use NETCONF as their backend, and XML as their native encoding. Lada > > /js > > -- > 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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jun 10 04:55:01 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 461271AD0BA for ; Wed, 10 Jun 2015 04:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-UjliKJEqAo for ; Wed, 10 Jun 2015 04:54:58 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C36EF1AD0CA for ; Wed, 10 Jun 2015 04:54:56 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 33446139B; Wed, 10 Jun 2015 13:54:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id bZ-0jZG6TI2c; Wed, 10 Jun 2015 13:54:52 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 10 Jun 2015 13:54:54 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 633AA2002C; Wed, 10 Jun 2015 13:54:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Gay1B8FH9rGq; Wed, 10 Jun 2015 13:55:00 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1B5BD2002B; Wed, 10 Jun 2015 13:54:53 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D47CF344DC58; Wed, 10 Jun 2015 13:54:51 +0200 (CEST) Date: Wed, 10 Jun 2015 13:54:50 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20150610115449.GA37135@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , Netconf References: <20150608143100.GD29788@elstar.local> <20150608151059.GB30068@elstar.local> <20150610064843.GA36156@elstar.local> <20150610090640.GC36604@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Netconf Subject: Re: [Netconf] YANG Patch Issue #3: :distinct-startup X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 11:55:00 -0000 On Wed, Jun 10, 2015 at 01:42:56PM +0200, Ladislav Lhotka wrote: > Juergen Schoenwaelder writes: > > > On Wed, Jun 10, 2015 at 12:44:14AM -0700, Andy Bierman wrote: > >> On Tue, Jun 9, 2015 at 11:48 PM, Juergen Schoenwaelder > >> wrote: > >> > On Tue, Jun 09, 2015 at 12:16:06PM -0700, Andy Bierman wrote: > >> >> > >> >> IMO this issue should move to DEAD because there is no > >> >> agreement on the scope of the problem and no agreement > >> >> on any solution. > >> >> > >> > > >> > I do not think declaring issues DEAD can be a default solution > >> > for the (sometimes painful process) of finding rough consensus. > >> > >> The default is to not make a change if > >> there is no agreement on the change. > >> The draft has never had a "save-to-NV" button. > >> The default will be to keep it that way. > > > > The I-D must document WG consensus. > > FWIW, I am with Andy on this one. > > RESTCONF servers needn't use NETCONF as their backend, and XML as their > native encoding. It neeeds to be clear when changes persist or what the persistence properties are of using RESTCONF - otherwise I can't build something robust on top of it. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Jun 10 05:15:00 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4611D1AD2C4 for ; Wed, 10 Jun 2015 05:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8USBv8Mc8ikv for ; Wed, 10 Jun 2015 05:14:56 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76EE21AD2AF for ; Wed, 10 Jun 2015 05:14:55 -0700 (PDT) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 45489140B0C; Wed, 10 Jun 2015 14:14:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1433938493; bh=FkVWMY8GrAEkn9gLc5EoAbalij+ZlbdOFbzqWirY+lY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=qVROLU4wPaAUGYNvb0hgFi3hoCogCXKVXVJg6R0zaMYXEliIPezxVoTuaqomkfD6R az0zEuhl3wGWCTusoiO58LLPTmGAjJsxURsmcas8GC5tbJQAq8fDUZGMbncR6ynmku a9WGf8wKih/1mMSJPRrD1LvYt/H+fHL0AMy02Qes= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ladislav Lhotka In-Reply-To: <20150610115449.GA37135@elstar.local> Date: Wed, 10 Jun 2015 14:14:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <820D7C0F-EE6C-4002-A8DD-1F9143C341B0@nic.cz> References: <20150608143100.GD29788@elstar.local> <20150608151059.GB30068@elstar.local> <20150610064843.GA36156@elstar.local> <20150610090640.GC36604@elstar.local> <20150610115449.GA37135@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.2098) X-Virus-Scanned: clamav-milter 0.98.6 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf Subject: Re: [Netconf] YANG Patch Issue #3: :distinct-startup X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 12:14:58 -0000 > On 10 Jun 2015, at 13:54, Juergen Schoenwaelder = wrote: >=20 > On Wed, Jun 10, 2015 at 01:42:56PM +0200, Ladislav Lhotka wrote: >> Juergen Schoenwaelder writes: >>=20 >>> On Wed, Jun 10, 2015 at 12:44:14AM -0700, Andy Bierman wrote: >>>> On Tue, Jun 9, 2015 at 11:48 PM, Juergen Schoenwaelder >>>> wrote: >>>>> On Tue, Jun 09, 2015 at 12:16:06PM -0700, Andy Bierman wrote: >>>>>>=20 >>>>>> IMO this issue should move to DEAD because there is no >>>>>> agreement on the scope of the problem and no agreement >>>>>> on any solution. >>>>>>=20 >>>>>=20 >>>>> I do not think declaring issues DEAD can be a default solution >>>>> for the (sometimes painful process) of finding rough consensus. >>>>=20 >>>> The default is to not make a change if >>>> there is no agreement on the change. >>>> The draft has never had a "save-to-NV" button. >>>> The default will be to keep it that way. >>>=20 >>> The I-D must document WG consensus. >>=20 >> FWIW, I am with Andy on this one. >>=20 >> RESTCONF servers needn't use NETCONF as their backend, and XML as = their >> native encoding. >=20 > It neeeds to be clear when changes persist or what the persistence > properties are of using RESTCONF - otherwise I can't build something > robust on top of it. If persistence means that config data survive a clean shutdown, then my = understanding is that the unified datastore is persistent. It doesn=E2=80=99= t necessarily mean synchronous writes of every edit though. Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jun 10 05:48:43 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5971A039A for ; Wed, 10 Jun 2015 05:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnOnNF9fVk9U for ; Wed, 10 Jun 2015 05:48:41 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AACDA1A0110 for ; Wed, 10 Jun 2015 05:48: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 1A4198FF; Wed, 10 Jun 2015 14:48:34 +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 SWjMPQAzRuMw; Wed, 10 Jun 2015 14:48:31 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 10 Jun 2015 14:48:33 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 98EE920013; Wed, 10 Jun 2015 14:48:33 +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 Vxwemm7WKIaX; Wed, 10 Jun 2015 14:48: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 0AE5B2002B; Wed, 10 Jun 2015 14:48:32 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2A892344DE98; Wed, 10 Jun 2015 14:48:30 +0200 (CEST) Date: Wed, 10 Jun 2015 14:48:29 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20150610124829.GA37336@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , Netconf References: <20150608151059.GB30068@elstar.local> <20150610064843.GA36156@elstar.local> <20150610090640.GC36604@elstar.local> <20150610115449.GA37135@elstar.local> <820D7C0F-EE6C-4002-A8DD-1F9143C341B0@nic.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <820D7C0F-EE6C-4002-A8DD-1F9143C341B0@nic.cz> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Netconf Subject: Re: [Netconf] YANG Patch Issue #3: :distinct-startup X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 12:48:42 -0000 On Wed, Jun 10, 2015 at 02:14:53PM +0200, Ladislav Lhotka wrote: > > If persistence means that config data survive a clean shutdown, then > my understanding is that the unified datastore is persistent. It > doesn’t necessarily mean synchronous writes of every edit though. Again, all I am saying it needs to be crystal clear what the to be expected behaviour is. You are bringing up another option - fine. What I do not want is that every implementation can pick its own choice. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Jun 10 07:36:32 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 834001B2B49 for ; Wed, 10 Jun 2015 07:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id irBPq6Afb8iv for ; Wed, 10 Jun 2015 07:36:30 -0700 (PDT) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F9AC1B2B4F for ; Wed, 10 Jun 2015 07:36:28 -0700 (PDT) Received: by labko7 with SMTP id ko7so34687357lab.2 for ; Wed, 10 Jun 2015 07:36:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=ZkMkIjY9M4cvXOgwbct4QQqbyhRDPQVkm5QrXTzM9zM=; b=mH5dottVEMSUO3blWP9viEqawS54QHlvzFf+MUHL4uonWKT3Azgk/cZOUKT/LCjHep lGba/QzqejGFdc9y0nHkRYz+dlbGB9y9GzjgMJBIpBpDCezwyGOalB4wFazsYuDhn1JZ NH/NVV9Zy1z7QgLiVJnMnMCladH1ygHPlJm/LS1kMozNTwg3WPrZc83t3VlnlPnC9SoY H48mdf7BJOq99MBUIlvgsDD7vgTiGePyNMsX239RRfuBJM4blWcm35KoDePm2ZUj8dbV C1WkcLAG0/P6bGH9ME0z2tSuj0QBim3H6Ton0/qe0Lnm1cZoH/dsEdGC4dHdxtAdFUFa m/Ng== X-Gm-Message-State: ALoCoQldWoBM4QOo96gmUHjjETKRr0TQ/SsOdx7AjaGOkDzcOwRVSMHvQr0BhI48e0Vdtv5Fe2hf MIME-Version: 1.0 X-Received: by 10.152.43.69 with SMTP id u5mr4302170lal.119.1433946986516; Wed, 10 Jun 2015 07:36:26 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Wed, 10 Jun 2015 07:36:26 -0700 (PDT) In-Reply-To: <20150610124829.GA37336@elstar.local> References: <20150608151059.GB30068@elstar.local> <20150610064843.GA36156@elstar.local> <20150610090640.GC36604@elstar.local> <20150610115449.GA37135@elstar.local> <820D7C0F-EE6C-4002-A8DD-1F9143C341B0@nic.cz> <20150610124829.GA37336@elstar.local> Date: Wed, 10 Jun 2015 07:36:26 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Ladislav Lhotka , Andy Bierman , Netconf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Netconf] YANG Patch Issue #3: :distinct-startup X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 14:36:31 -0000 On Wed, Jun 10, 2015 at 5:48 AM, Juergen Schoenwaelder wrote: > On Wed, Jun 10, 2015 at 02:14:53PM +0200, Ladislav Lhotka wrote: >> >> If persistence means that config data survive a clean shutdown, then >> my understanding is that the unified datastore is persistent. It >> doesn=E2=80=99t necessarily mean synchronous writes of every edit though= . > > Again, all I am saying it needs to be crystal clear what the to be > expected behaviour is. You are bringing up another option - fine. What > I do not want is that every implementation can pick its own choice. > The draft is clear -- the server saves to NV-store after every edit. NETCONF is the one that is not very clear because it says nothing about NV-storage except for some very specific text about the startup datastore. If :startup is not supported, there is no NV storage requirement at all. In RESTCONF there is an NV storage requirement, which is compatible with NETCONF. RESTCONF does the edit procedure in 1 step. This goes for candidate or startup. Even if the server supports :candidate, the client does not do a 2-step edit+commit like NETCONF. > /js Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Wed Jun 10 11:22:39 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6154E1B2A32; Wed, 10 Jun 2015 06:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6OOnmxD_3Sy; Wed, 10 Jun 2015 06:46:18 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 229071B2A31; Wed, 10 Jun 2015 06:46:17 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8DBA3E00C; Wed, 10 Jun 2015 10:00:38 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 228A763B10; Wed, 10 Jun 2015 09:46:16 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0F2BB637FE; Wed, 10 Jun 2015 09:46:16 -0400 (EDT) From: Michael Richardson To: tools-discuss@ietf.org, netconf@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: X-Mailman-Approved-At: Wed, 10 Jun 2015 11:22:31 -0700 Subject: [Netconf] extracting yang models from RFC X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 13:46:19 -0000 --=-=-= Content-Type: text/plain Please excuse me if this is a FAQ, but a scan of 6020 didn't reveal any advice. I'm also mostly ignorant of MIB or YANG authoring, I'm just trying to help get a more consistent experience. I know that we have tools to extract MIBs from RFCs, and I assume that we have the same for YANG models. I also googled for "how to format yang model in rfc", and I looked at: https://tools.ietf.org/wg/netconf/trac/wiki, and looked at: https://mailarchive.ietf.org/arch/search/?q=netconf+how+to+format+yang+in+internet-draft&f_list=netconf What is the recommended way to embed the YANG definition into an ID? Should it be as a single section, with a single
, or should/can it be split up into multiple figures? I'm writing a makefile/sed pipeline to insert the raw .yang file into the XML to reduce editing errors. <> must be escaped as < in , but I'm unaware of any other stuffing that must be done. Probably this is a solved problem... -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVXg/p4CLcPvd0N1lAQITpgf+LeBPoWNqPyjnoBhEvFR8JITF2HDRhi3I NoGFaxXtFoEXrpBFsNZ3/RgUgAGW816CCkN+l/eL0LbRpzUgvakZKRaoG9d5ged8 xW8JsRYh2K5NFfa8u0zuIOJ4SjW9pI8gKNqDVVui+M9W0MNrwnvr5XIjCvWW2XUI aig2udlacZF/iQ7FO5nKes+ko4RUEk2hcVi4TEkKCAG77N15Xanx9KuhwwtndoUC 6K6SN9YAqitrDhsVwftuzaeF/Utv7aItIxYzdsbmmkIqFc49ZFpU5E4D6EiosOx8 hxZEz/Ze3Kavdwo1KVyKalob3kgPzLkUcYGfBRLmvfCZPhp6+KTdgQ== =vUzq -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jun 10 11:31:07 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E03C81B3406 for ; Wed, 10 Jun 2015 11:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vjlx-PizyH1O for ; Wed, 10 Jun 2015 11:31: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 46E8F1B3407 for ; Wed, 10 Jun 2015 11:31:03 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id B0A301AE075B; Wed, 10 Jun 2015 20:31:01 +0200 (CEST) Date: Wed, 10 Jun 2015 20:32:38 +0200 (CEST) Message-Id: <20150610.203238.2094212342811061832.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <820D7C0F-EE6C-4002-A8DD-1F9143C341B0@nic.cz> <20150610124829.GA37336@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] YANG Patch Issue #3: :distinct-startup X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 18:31:05 -0000 QW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IHdyb3RlOg0KPiBPbiBXZWQsIEp1biAx MCwgMjAxNSBhdCA1OjQ4IEFNLCBKdWVyZ2VuIFNjaG9lbndhZWxkZXINCj4gPGouc2Nob2Vud2Fl bGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4gd3JvdGU6DQo+ID4gT24gV2VkLCBKdW4gMTAsIDIw MTUgYXQgMDI6MTQ6NTNQTSArMDIwMCwgTGFkaXNsYXYgTGhvdGthIHdyb3RlOg0KPiA+Pg0KPiA+ PiBJZiBwZXJzaXN0ZW5jZSBtZWFucyB0aGF0IGNvbmZpZyBkYXRhIHN1cnZpdmUgYSBjbGVhbiBz aHV0ZG93biwgdGhlbg0KPiA+PiBteSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgdGhlIHVuaWZpZWQg ZGF0YXN0b3JlIGlzIHBlcnNpc3RlbnQuIEl0DQo+ID4+IGRvZXNu4oCZdCBuZWNlc3NhcmlseSBt ZWFuIHN5bmNocm9ub3VzIHdyaXRlcyBvZiBldmVyeSBlZGl0IHRob3VnaC4NCj4gPg0KPiA+IEFn YWluLCBhbGwgSSBhbSBzYXlpbmcgaXQgbmVlZHMgdG8gYmUgY3J5c3RhbCBjbGVhciB3aGF0IHRo ZSB0byBiZQ0KPiA+IGV4cGVjdGVkIGJlaGF2aW91ciBpcy4gWW91IGFyZSBicmluZ2luZyB1cCBh bm90aGVyIG9wdGlvbiAtIGZpbmUuIFdoYXQNCj4gPiBJIGRvIG5vdCB3YW50IGlzIHRoYXQgZXZl cnkgaW1wbGVtZW50YXRpb24gY2FuIHBpY2sgaXRzIG93biBjaG9pY2UuDQo+ID4NCj4gDQo+IFRo ZSBkcmFmdCBpcyBjbGVhciAtLSB0aGUgc2VydmVyIHNhdmVzIHRvIE5WLXN0b3JlIGFmdGVyIGV2 ZXJ5IGVkaXQuDQoNClJpZ2h0LiAgSXQgc2F5czoNCg0KICBFYWNoIFJFU1RDT05GIGVkaXQgb2Yg YSBkYXRhc3RvcmUgcmVzb3VyY2UgaXMgc2F2ZWQgdG8gbm9uLXZvbGF0aWxlDQogIHN0b3JhZ2Ug aW4gYW4gaW1wbGVtZW50YXRpb24tc3BlY2lmaWMgbWF0dGVyIGJ5IHRoZSBzZXJ2ZXIuDQoNClNo b3VsZG4ndCB3ZSBqdXN0IHdyaXRlOg0KDQogIEVhY2ggUkVTVENPTkYgZWRpdCBvZiBhIGRhdGFz dG9yZSByZXNvdXJjZSBpcyBzYXZlZCB0byBub24tdm9sYXRpbGUNCiAgc3RvcmFnZSBieSB0aGUg c2VydmVyLg0KDQoqaG93KiB0aGUgc2VydmVyIHBlcmZvcm1zIGp1c3QgYWJvdXQgZXZlcnl0aGlu ZyBpcyBpbXBsZW1lbnRhdGlvbg0KIHNwZWNpZmljLi4uDQoNCg0KDQovbWFydGluDQo= From nobody Wed Jun 10 11:32:35 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 157181B340B for ; Wed, 10 Jun 2015 11:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDSTIjh3dTne for ; Wed, 10 Jun 2015 11:32:32 -0700 (PDT) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) (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 D4EFC1B3406 for ; Wed, 10 Jun 2015 11:32:31 -0700 (PDT) Received: by labpy14 with SMTP id py14so39098822lab.0 for ; Wed, 10 Jun 2015 11:32:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=AWfsRb9iVi64TT6BSE1tS/xWB0MTJ84cQLCE8N01tAw=; b=Lutq7wrypuOoaP9rqRWjtCdVWJy9rGfT7A7KPWCXPO5rVu/PEW70ynCDyjkuLDqqym ygztZzttj2p5ec5JtYu4e9yePLwNLujYezeHsEqiUOxdL6AqOfTbZTUcKL2iE3B7d6qD EPV0Fi+ROUxrXRZ11MU+W+cWFN5WqMQEFFPVIiQpfncutRcqm47PXVtHTFwrsV2oM+ZV rz22gRi1Ou4mt89y29Sx4TD6vKC4/WggRfIqAexWN6wqAYr/EJX00iBKVSza9EhpJ8Pl ayhjrSowlXYNgR8/GtsDMr/QWMFKKJs0HN0z0rKcruKQYHOYO2m0stWgX0di97Of58ZT SEYQ== X-Gm-Message-State: ALoCoQlungK31hcNaU90GSLX/Okzgps8m5zn1PXokOfAmM3tiIgp8anvCShsieUJDxzpPN8gd4Y0 MIME-Version: 1.0 X-Received: by 10.112.164.66 with SMTP id yo2mr5545674lbb.33.1433961150348; Wed, 10 Jun 2015 11:32:30 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Wed, 10 Jun 2015 11:32:30 -0700 (PDT) In-Reply-To: <20150610.203238.2094212342811061832.mbj@tail-f.com> References: <820D7C0F-EE6C-4002-A8DD-1F9143C341B0@nic.cz> <20150610124829.GA37336@elstar.local> <20150610.203238.2094212342811061832.mbj@tail-f.com> Date: Wed, 10 Jun 2015 11:32:30 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Netconf Subject: Re: [Netconf] YANG Patch Issue #3: :distinct-startup X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 18:32:35 -0000 On Wed, Jun 10, 2015 at 11:32 AM, Martin Bjorklund wrote: > Andy Bierman wrote: >> On Wed, Jun 10, 2015 at 5:48 AM, Juergen Schoenwaelder >> wrote: >> > On Wed, Jun 10, 2015 at 02:14:53PM +0200, Ladislav Lhotka wrote: >> >> >> >> If persistence means that config data survive a clean shutdown, then >> >> my understanding is that the unified datastore is persistent. It >> >> doesn=E2=80=99t necessarily mean synchronous writes of every edit tho= ugh. >> > >> > Again, all I am saying it needs to be crystal clear what the to be >> > expected behaviour is. You are bringing up another option - fine. What >> > I do not want is that every implementation can pick its own choice. >> > >> >> The draft is clear -- the server saves to NV-store after every edit. > > Right. It says: > > Each RESTCONF edit of a datastore resource is saved to non-volatile > storage in an implementation-specific matter by the server. > > Shouldn't we just write: > > Each RESTCONF edit of a datastore resource is saved to non-volatile > storage by the server. > > *how* the server performs just about everything is implementation > specific... > OK > > > /martin From nobody Wed Jun 10 12:21:22 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A01B1A87F1; Wed, 10 Jun 2015 12:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKO0WCL0mSOa; Wed, 10 Jun 2015 12:21:16 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0784.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::784]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E2DD1A87EA; Wed, 10 Jun 2015 12:21:15 -0700 (PDT) Received: from CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) by CO1PR05MB281.namprd05.prod.outlook.com (10.141.70.155) with Microsoft SMTP Server (TLS) id 15.1.184.17; Wed, 10 Jun 2015 19:20:57 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.172.22; Wed, 10 Jun 2015 19:20:56 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.121]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.121]) with mapi id 15.01.0184.014; Wed, 10 Jun 2015 19:20:56 +0000 From: Kent Watsen To: Michael Richardson , "tools-discuss@ietf.org" , "netconf@ietf.org" Thread-Topic: [Netconf] extracting yang models from RFC Thread-Index: AQHQo6pyFc0mBmOcF0CwNqLTL3gPsp2l2sAA Date: Wed, 10 Jun 2015 19:20:56 +0000 Message-ID: References: <30608.1433943976@sandelman.ca> In-Reply-To: <30608.1433943976@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: sandelman.ca; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.14] x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB281; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520003)(3002001); SRVR:CO1PR05MB459; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; x-forefront-prvs: 06036BD506 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(24454002)(377454003)(51704005)(19580395003)(107886002)(5001960100002)(5001770100001)(2501003)(189998001)(19580405001)(5002640100001)(66066001)(36756003)(83506001)(2900100001)(122556002)(77156002)(40100003)(54356999)(76176999)(87936001)(2656002)(46102003)(106116001)(92566002)(2950100001)(15975445007)(62966003)(102836002)(86362001)(4001350100001)(99286002)(50986999)(1720100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <79E6607A465598418BA33908295FA23E@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jun 2015 19:20:56.7817 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459 X-OriginatorOrg: juniper.net Archived-At: Subject: Re: [Netconf] extracting yang models from RFC X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 19:21:18 -0000 See rfcstrip located here: http://www.yang-central.org/twiki/pub/Main/YangTools/rfcstrip Just do 'rfcstrip ' and you'll get the extracted YANG modules (and more). Cheers, Kent On 6/10/15, 9:46 AM, "Michael Richardson" wrote: > >Please excuse me if this is a FAQ, but a scan of 6020 didn't reveal any >advice. I'm also mostly ignorant of MIB or YANG authoring, I'm just >trying >to help get a more consistent experience. I know that we have tools to >extract MIBs from RFCs, and I assume that we have the same for YANG >models. > >I also googled for "how to format yang model in rfc", and I looked >at: https://tools.ietf.org/wg/netconf/trac/wiki, and >looked at: >https://mailarchive.ietf.org/arch/search/?q=3Dnetconf+how+to+format+yang+i= n+ >internet-draft&f_list=3Dnetconf > >What is the recommended way to embed the YANG definition into an ID? >Should it be as a single section, with a single
, >or should/can it be split up into multiple figures? > >I'm writing a makefile/sed pipeline to insert the raw .yang file into >the XML to reduce editing errors. <> must be escaped as < in >, but I'm unaware of any other stuffing that must be done. > >Probably this is a solved problem... > >-- >Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- > > > From nobody Wed Jun 10 12:22:25 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 288091A882B for ; Wed, 10 Jun 2015 12:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKEk3FudhrdR for ; Wed, 10 Jun 2015 12:22:23 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 767DA1A87EA for ; Wed, 10 Jun 2015 12:22:23 -0700 (PDT) Received: by pabqy3 with SMTP id qy3so40227324pab.3 for ; Wed, 10 Jun 2015 12:22:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Dho4aUqcx/5zPA1GWpydRaTWeCfp7+AKydRoBHGJqOs=; b=YaRHoLTK26PX8TpA+eHkux5qkyBUHCW25cOuscQTXXScig4XgZ8jm4NrTBjYyJgb47 8dI2dsjc14BbgvA/eOFesuVj4R4yH3JBTQgl/1ruK6u9Cmt3vHNf/tjQ+EnAkPSipGIA 8m3EGFw5AXa2xLGaa+HrjyyHxYQfBD7jSRGmnBzzwi2/3FCXgfcbRwQQPvZs7vJCFY7+ rnqVhCE03F+CW0fhixlqWNdEVuSKywv6OjPBsV5vS3foJaAcUo+qoSkuD3mLii/F5QKD ZPCLEXX6a7UIYIn8QKhlzNaODpoiCuucGxB5Nu7zxK/hHCMqyGegT16qWhZ8B9URtc0O PUrQ== X-Received: by 10.66.62.228 with SMTP id b4mr7971493pas.91.1433964143133; Wed, 10 Jun 2015 12:22:23 -0700 (PDT) Received: from ?IPv6:2001:420:302:1330:7197:4184:582e:ba8f? ([2001:420:302:1330:7197:4184:582e:ba8f]) by mx.google.com with ESMTPSA id ol3sm9342668pbb.70.2015.06.10.12.22.21 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Jun 2015 12:22:22 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Mahesh Jethanandani In-Reply-To: <20150610064843.GA36156@elstar.local> Date: Wed, 10 Jun 2015 12:23:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150608.102005.1482395931170643204.mbj@tail-f.com> <20150608094708.GA28936@elstar.local> <20150608143100.GD29788@elstar.local> <20150608151059.GB30068@elstar.local> <20150610064843.GA36156@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Netconf Subject: Re: [Netconf] YANG Patch Issue #3: :distinct-startup X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 19:22:25 -0000 > On Jun 9, 2015, at 11:48 PM, Juergen Schoenwaelder = wrote: >=20 > On Tue, Jun 09, 2015 at 12:16:06PM -0700, Andy Bierman wrote: >>=20 >> IMO this issue should move to DEAD because there is no >> agreement on the scope of the problem and no agreement >> on any solution. >>=20 >=20 > I do not think declaring issues DEAD can be a default solution > for the (sometimes painful process) of finding rough consensus. +1 And I thought we had just got started on discussing the problem = statement and possibly some solutions. It is too soon to declare it = DEAD. I think performance issues with writing to NV is prejudicing us into not = finding a solution. Another way to ask the question is, if one was to = take the performance issue of writing to NV taken out of the picture, = would folks support the notion of having :distinct-startup in RESTCONF? >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf Mahesh Jethanandani mjethanandani@gmail.com From nobody Wed Jun 10 12:26:32 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 151641A87E7; Wed, 10 Jun 2015 12:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YyibOla1d75e; Wed, 10 Jun 2015 12:26:27 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CAC01A8827; Wed, 10 Jun 2015 12:26:27 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C665820098; Wed, 10 Jun 2015 15:40:48 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 24B8263B10; Wed, 10 Jun 2015 15:26:26 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0B452637FE; Wed, 10 Jun 2015 15:26:26 -0400 (EDT) From: Michael Richardson To: Kent Watsen In-Reply-To: References: <30608.1433943976@sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Cc: "netconf@ietf.org" , "tools-discuss@ietf.org" Subject: Re: [Netconf] extracting yang models from RFC X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 19:26:29 -0000 Kent Watsen wrote: > See rfcstrip located here: > http://www.yang-central.org/twiki/pub/Main/YangTools/rfcstrip > Just do 'rfcstrip ' and you'll get the extracted YANG > modules (and more). okay, sure, I knew such things existed (but I hadn't found it) But, what should I do on the input side of things to make rfcstrip work better? I guess I can round trip it until I get it right... let's try. okay, back to my original question. rfcstrip results in empty output from the ID in question, so I'm back to my original question: what do I put in to make rfcstrip work? (and where is that documented?) -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From nobody Wed Jun 10 12:29:37 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1F8E1A884C; Wed, 10 Jun 2015 12:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id flZ0HuQbB0bH; Wed, 10 Jun 2015 12:29:33 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 613FC1A882A; Wed, 10 Jun 2015 12:29:33 -0700 (PDT) Received: from [172.20.10.5] (h194.viagenie.ca [206.123.31.194]) by jazz.viagenie.ca (Postfix) with ESMTPSA id E4A99403C2; Wed, 10 Jun 2015 15:29:34 -0400 (EDT) From: "Marc Blanchet" To: "Michael Richardson" Date: Wed, 10 Jun 2015 15:29:31 -0400 Message-ID: <5BB95C2D-7D3E-439E-AC0E-16493D611560@viagenie.ca> In-Reply-To: <9126.1433964386@sandelman.ca> References: <30608.1433943976@sandelman.ca> <9126.1433964386@sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate Trial (1.9.1r5084) Archived-At: Cc: "netconf@ietf.org" , "tools-discuss@ietf.org" Subject: Re: [Netconf] [Tools-discuss] extracting yang models from RFC X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 19:29:35 -0000 On 10 Jun 2015, at 15:26, Michael Richardson wrote: > Kent Watsen wrote: > > See rfcstrip located here: > > http://www.yang-central.org/twiki/pub/Main/YangTools/rfcstrip > > > Just do 'rfcstrip ' and you'll get the extracted > YANG > > modules (and more). > > okay, sure, I knew such things existed (but I hadn't found it) > But, what should I do on the input side of things to make rfcstrip > work better? > I guess I can round trip it until I get it right... let's try. > > okay, back to my original question. rfcstrip results in empty > output from the ID in question, so I'm back to my original question: > what do > I put in to make rfcstrip work? > (and where is that documented?) interesting. During the discussion on the new RFC format, I stated specifically on the mike that those should be well handled for extraction and formatting (no page headers in the middle…). I haven’t looked at the new proposed format, but I hope it should be « simpler » than now. Marc. > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | network > architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on > rails [ > > > > -- > Tools-discuss mailing list > Tools-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/tools-discuss > > Please report datatracker.ietf.org bugs at > http://tools.ietf.org/tools/ietfdb > Please report tools.ietf.org bugs at > http://tools.ietf.org/tools/issues or > send email to webmaster@tools.ietf.org From nobody Wed Jun 10 12:43:05 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B85A01A8883; Wed, 10 Jun 2015 12:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTMOIfXRoBz9; Wed, 10 Jun 2015 12:43:03 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0138.outbound.protection.outlook.com [207.46.100.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05C581A8881; Wed, 10 Jun 2015 12:43:02 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.1.172.22; Wed, 10 Jun 2015 19:43:02 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.121]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.121]) with mapi id 15.01.0184.014; Wed, 10 Jun 2015 19:43:02 +0000 From: Kent Watsen To: Michael Richardson Thread-Topic: [Netconf] extracting yang models from RFC Thread-Index: AQHQo6pyFc0mBmOcF0CwNqLTL3gPsp2l2sAAgABEmgD//8GSgA== Date: Wed, 10 Jun 2015 19:43:02 +0000 Message-ID: References: <30608.1433943976@sandelman.ca> <9126.1433964386@sandelman.ca> In-Reply-To: <9126.1433964386@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: sandelman.ca; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.14] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB460; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520003)(3002001); SRVR:CO1PR05MB460; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB460; x-forefront-prvs: 06036BD506 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(479174004)(51704005)(5001960100002)(4001350100001)(77156002)(86362001)(110136002)(19580405001)(36756003)(189998001)(19580395003)(87936001)(50986999)(54356999)(76176999)(66066001)(2656002)(122556002)(5002640100001)(2950100001)(62966003)(2900100001)(92566002)(46102003)(102836002)(99286002)(106116001)(40100003)(83506001)(15975445007); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <8AAA1EF22DA5E649B8C7CBC2046AC37D@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jun 2015 19:43:02.2176 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB460 Archived-At: Cc: "netconf@ietf.org" , "tools-discuss@ietf.org" Subject: Re: [Netconf] extracting yang models from RFC X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 19:43:04 -0000 On 6/10/15, 3:26 PM, "Michael Richardson" wrote: >okay, sure, I knew such things existed (but I hadn't found it) >But, what should I do on the input side of things to make rfcstrip >work better? >I guess I can round trip it until I get it right... let's try. > >okay, back to my original question. rfcstrip results in empty >output from the ID in question, so I'm back to my original question: what >do >I put in to make rfcstrip work? >(and where is that documented?) Code should be wrapped by and markers. See here for where it's defined: https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-02#section-4.1 Cheers, Kent From nobody Wed Jun 10 12:48:46 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCF801A87EA; Wed, 10 Jun 2015 12:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1AjfnkEq4BXb; Wed, 10 Jun 2015 12:48:43 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C7861A8775; Wed, 10 Jun 2015 12:48:43 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2117FE00C; Wed, 10 Jun 2015 16:03:05 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 6BCDE63B10; Wed, 10 Jun 2015 15:48:42 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 549AC637FE; Wed, 10 Jun 2015 15:48:42 -0400 (EDT) From: Michael Richardson To: "Marc Blanchet" In-Reply-To: <5BB95C2D-7D3E-439E-AC0E-16493D611560@viagenie.ca> References: <30608.1433943976@sandelman.ca> <9126.1433964386@sandelman.ca> <5BB95C2D-7D3E-439E-AC0E-16493D611560@viagenie.ca> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Cc: "netconf@ietf.org" , "tools-discuss@ietf.org" Subject: Re: [Netconf] [Tools-discuss] extracting yang models from RFC X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 19:48:45 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Marc Blanchet wrote: >> okay, back to my original question. rfcstrip results in empty >> output from the ID in question, so I'm back to my original question: >> what do >> I put in to make rfcstrip work? >> (and where is that documented?) > interesting. During the discussion on the new RFC format, I stated > specifically on the mike that those should be well handled for > extraction and > formatting (no page headers in the middle=E2=80=A6). I haven=E2=80= =99t looked at the new > proposed format, but I hope it should be =C2=AB=C2=A0simpler=C2=A0=C2= =BB than now. I don't know if
is what's in the new format or not. In any case, I'm not at the new format... I'm dealing with the xml2txt workflow. So I wouldn't say there is either success or failure of what you asked for at this point. I'm using xml2rfc 2.4.7 (probably not the absolute latest, but it has worked up to now). I'm assuming, looking at the awk script in the middle of the rfcstrip shell code, that it is looking for "module FOO {" to start. Hmm. I note that this code is not terminated with a } at the exactly same level in the ID.... aha the last line of original file had a }, and no trailing new line, so that very last line was never included. rfcstrip now works, and the round trip is the same except for some extra blank lines added, and slightly different indent on descriptions that cross multiple lines. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVXiUmoCLcPvd0N1lAQKk4gf/Y4xZGKGZcKuHUG0o37mweOToyYRBY3v3 UnYT4b1vyaDZtcgRvYzCW1ekmcgnxMKnp/ojjn2LB+pzg35Uvei+DNw70IDShcCf hNzFSphxGO/M96In/90p8VPel/iudjMRB36TImU6yZ1qNkuyxvZ9XgucfFTWAYCo USaWxxuCXlt7/DRYSQdGkmFRduAmFz0FSsVUtJ+pJ6E1MHoG9yoHfqTy1wReu9yD 8MzTPM+M8j0fRWrtFlh+G9laTNSqvc1bOIgr9fiP5gErjGVIPpsh8AR3FGhFM4Yd XAycwlMYh6MQN452U3vBgcOKjDKTEVqQM9gXSp0StrZqjuCNDPEzPQ== =0b59 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jun 10 12:54:28 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A008B1A896F; Wed, 10 Jun 2015 12:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y48M9_3IY4Br; Wed, 10 Jun 2015 12:54:24 -0700 (PDT) Received: from proper.com (Opus1.Proper.COM [207.182.41.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 7F6EF1A895B; Wed, 10 Jun 2015 12:54:24 -0700 (PDT) Received: from [10.20.30.109] (142-254-17-100.dsl.dynamic.fusionbroadband.com [142.254.17.100]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t5AJsNNw056839 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Jun 2015 12:54:23 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 142-254-17-100.dsl.dynamic.fusionbroadband.com [142.254.17.100] claimed to be [10.20.30.109] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Paul Hoffman In-Reply-To: <5BB95C2D-7D3E-439E-AC0E-16493D611560@viagenie.ca> Date: Wed, 10 Jun 2015 12:54:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <30608.1433943976@sandelman.ca> <9126.1433964386@sandelman.ca> <5BB95C2D-7D3E-439E-AC0E-16493D611560@viagenie.ca> To: Marc Blanchet X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Michael Richardson , "tools-discuss@ietf.org" , "netconf@ietf.org" Subject: Re: [Netconf] [Tools-discuss] extracting yang models from RFC X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 19:54:25 -0000 On Jun 10, 2015, at 12:29 PM, Marc Blanchet = wrote: > interesting. During the discussion on the new RFC format, I stated = specifically on the mike that those should be well handled for = extraction and formatting (no page headers in the middle=E2=80=A6). I = haven=E2=80=99t looked at the new proposed format, but I hope it should = be =C2=AB simpler =C2=BB than now. Much simpler: see the element in = . --Paul Hoffman= From nobody Wed Jun 10 13:08:39 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF481A90CD for ; Wed, 10 Jun 2015 13:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Yq75axygg0q for ; Wed, 10 Jun 2015 13:08:37 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABB8D1A90DE for ; Wed, 10 Jun 2015 13:08:35 -0700 (PDT) Received: by lbbqq2 with SMTP id qq2so34940818lbb.3 for ; Wed, 10 Jun 2015 13:08:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=sKmt5X8hNM1rQ22FAvP07B1WZLjMIpi0GDlAv9rRSlM=; b=eCZHeIGhdM3iluPOgqXWszGK8xK5QY56MhLQXfi/h3DEFGxe0odcCujNDT4PEVNau5 NLWupVndS/SKEmYkGVXyV4Gakd3Zv8p/5BQ7nYvSmSwUC18XwfKrN9hZkia8/182hvYw valNsticdG85RZvkf+MX7Wo1QvyuyldXUmD8HqJnY3apOjhueDErT8go5eWNs5lYYeKU QTBsn+XCIJsGO4LYUW1JmuQ4bjUFuJ7iXZSAP/852uerTGCOxH1btjepWtYUNDUK2s20 HHnCGBqKznDIvA7tPuf1LNTTvfsj7WZiq9WYRfHed8eZDdfOMzA6DP6eQcOxyR4o0Dcq I3gw== X-Gm-Message-State: ALoCoQn9gmXJFUbXai1b7+ZSH2Sv886RZ42WEC/xsMH4f/euB/3SRZnoxwARSjINY3iKK7SNsr4k MIME-Version: 1.0 X-Received: by 10.152.116.49 with SMTP id jt17mr5881501lab.82.1433966914070; Wed, 10 Jun 2015 13:08:34 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Wed, 10 Jun 2015 13:08:33 -0700 (PDT) In-Reply-To: References: <20150608.102005.1482395931170643204.mbj@tail-f.com> <20150608094708.GA28936@elstar.local> <20150608143100.GD29788@elstar.local> <20150608151059.GB30068@elstar.local> <20150610064843.GA36156@elstar.local> Date: Wed, 10 Jun 2015 13:08:33 -0700 Message-ID: From: Andy Bierman To: Mahesh Jethanandani Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Netconf Subject: Re: [Netconf] YANG Patch Issue #3: :distinct-startup X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 20:08:39 -0000 On Wed, Jun 10, 2015 at 12:23 PM, Mahesh Jethanandani wrote: > >> On Jun 9, 2015, at 11:48 PM, Juergen Schoenwaelder wrote: >> >> On Tue, Jun 09, 2015 at 12:16:06PM -0700, Andy Bierman wrote: >>> >>> IMO this issue should move to DEAD because there is no >>> agreement on the scope of the problem and no agreement >>> on any solution. >>> >> >> I do not think declaring issues DEAD can be a default solution >> for the (sometimes painful process) of finding rough consensus. > > +1 > Note the text "IMO this issue should"... I was stating my opinion, not declaring the issue dead. > And I thought we had just got started on discussing the problem statement= and possibly some solutions. It is too soon to declare it DEAD. > OK > I think performance issues with writing to NV is prejudicing us into not = finding a solution. Another way to ask the question is, if one was to take = the performance issue of writing to NV taken out of the picture, would folk= s support the notion of having :distinct-startup in RESTCONF? > > The other use of user-controlled NV-store is that in case the device reboot= s, it will come back with a known good configuration. If every edit is NV-sav= ed, then there is no chance for the operator to test the changes before changing the startup config. >> >> /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 > > Mahesh Jethanandani > mjethanandani@gmail.com > > > From nobody Wed Jun 10 13:09:06 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA601A8915 for ; Wed, 10 Jun 2015 13:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.061 X-Spam-Level: X-Spam-Status: No, score=-0.061 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_46=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0m7o9ux20BY for ; Wed, 10 Jun 2015 13:09:02 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 517471A90ED for ; Wed, 10 Jun 2015 13:09:02 -0700 (PDT) Received: from [IPv6:2a01:5e0:29:ffff:842b:366c:980f:c11d] (unknown [IPv6:2a01:5e0:29:ffff:842b:366c:980f:c11d]) by mail.nic.cz (Postfix) with ESMTPSA id B1A7713F889; Wed, 10 Jun 2015 22:09:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1433966940; bh=1WZaJOCNeZpnwDanshKRGSMz6BeTi7f0f3a/HrCgI7g=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=SfdH4VbK5wFRtsNSfAuXTwxY2ZBMaTJ1pBKnNRPjSrm7Hu0ThDVTEfU3qgqVFigKF MqK95lqJt1mI2/Aq/sQif5Ge0k4oMFHGq4WmAELB/X8rVbNw7xkBtsyOT15OkaaV4C TIvZ0W/lPU5nqG8lueTbxIGXIV3D9hTSt8Q9Cjbw= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ladislav Lhotka In-Reply-To: Date: Wed, 10 Jun 2015 22:09:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <43ACFC28-4ECD-4ED8-9229-76A0194B7A07@nic.cz> References: <20150608151059.GB30068@elstar.local> <20150610064843.GA36156@elstar.local> <20150610090640.GC36604@elstar.local> <20150610115449.GA37135@elstar.local> <820D7C0F-EE6C-4002-A8DD-1F9143C341B0@nic.cz> <20150610124829.GA37336@elstar.local> To: Andy Bierman X-Mailer: Apple Mail (2.2098) X-Virus-Scanned: clamav-milter 0.98.6 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf Subject: Re: [Netconf] YANG Patch Issue #3: :distinct-startup X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 20:09:04 -0000 > On 10 Jun 2015, at 16:36, Andy Bierman wrote: >=20 > On Wed, Jun 10, 2015 at 5:48 AM, Juergen Schoenwaelder > wrote: >> On Wed, Jun 10, 2015 at 02:14:53PM +0200, Ladislav Lhotka wrote: >>>=20 >>> If persistence means that config data survive a clean shutdown, then >>> my understanding is that the unified datastore is persistent. It >>> doesn=E2=80=99t necessarily mean synchronous writes of every edit = though. >>=20 >> Again, all I am saying it needs to be crystal clear what the to be >> expected behaviour is. You are bringing up another option - fine. = What >> I do not want is that every implementation can pick its own choice. >>=20 >=20 > The draft is clear -- the server saves to NV-store after every edit. Yes, but how it is done is an =E2=80=9Cimplementation-specific = matter=E2=80=9D. This may also mean it is a delayed write. I think the = protocol specification shouldn=E2=80=99t be too specific here, it should = suffice to say that it is expected the configuration won=E2=80=99t = disappear with a device reboot. These days, with all the virtualization options, cloud storage etc., it = is hard to define what non-volatile storage is. Lada > NETCONF is the one that is not very clear because it says nothing > about NV-storage except for some very specific text about > the startup datastore. If :startup is not supported, there is no > NV storage requirement at all. >=20 > In RESTCONF there is an NV storage requirement, which is compatible > with NETCONF. RESTCONF does the edit procedure in 1 step. > This goes for candidate or startup. Even if the server supports > :candidate, the client does not do a 2-step edit+commit like NETCONF. >=20 >=20 >> /js >=20 > Andy >=20 >>=20 >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >> Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jun 10 13:11:46 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B2C1A90ED for ; Wed, 10 Jun 2015 13:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbvzOgC5wiMH for ; Wed, 10 Jun 2015 13:11:43 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0755.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::755]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D26DB1A9109 for ; Wed, 10 Jun 2015 13:11:42 -0700 (PDT) Received: from CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) by CO1PR05MB426.namprd05.prod.outlook.com (10.141.74.24) with Microsoft SMTP Server (TLS) id 15.1.190.14; Wed, 10 Jun 2015 20:11:27 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.172.22; Wed, 10 Jun 2015 20:11:26 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.121]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.121]) with mapi id 15.01.0184.014; Wed, 10 Jun 2015 20:11:26 +0000 From: Kent Watsen To: Martin Bjorklund , "j.schoenwaelder@jacobs-university.de" Thread-Topic: [Netconf] server-model #49: combine trusted-ca-certs and trusted-client-certs for ssh/tls? Thread-Index: AQHQkbgnBncK8ydKj0azKXFdHxn5752Zo96AgAeProCAARR5gIAAV3kAgAAEv4CAAAsogIAADzaAgANOJ4A= Date: Wed, 10 Jun 2015 20:11:26 +0000 Message-ID: References: <20150608.135134.815056002069146319.mbj@tail-f.com> <20150608120832.GB29405@elstar.local> <20150608.144829.87446572227513213.mbj@tail-f.com> <20150608.154255.1228399594019434358.mbj@tail-f.com> In-Reply-To: <20150608.154255.1228399594019434358.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: tail-f.com; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.14] x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB426; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:CO1PR05MB459; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; x-forefront-prvs: 06036BD506 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(106116001)(46102003)(15975445007)(2950100001)(92566002)(87936001)(76176999)(2656002)(230783001)(93886004)(62966003)(102836002)(4001350100001)(99286002)(86362001)(50986999)(2501003)(189998001)(5001770100001)(19580395003)(5001960100002)(77156002)(40100003)(122556002)(2900100001)(54356999)(5002640100001)(5001920100001)(36756003)(83506001)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <67A48A2E87FAAF44ADE3248CA0D6F061@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jun 2015 20:11:26.5261 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459 X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB426; 2:wlzoTB3rUaBXxAO0m/HRaFJPXiChiPb9LEzUyjEru1wtMjLeOerUdNuFZW9AyxBJ; 2:ffr0i5Am5RlWMPgQQJhBPMdHb7zSrgNtTn5mG9papHtC96W4jXdQ1GUm9JxLdpIBBnJkCOdqLTsNRPf6JkXiH0pJ4nAi7jiZ+NxiQmxULNrmC5i7NCH/01mO34pjQV9SDCSERmJrgWLQOya0zZH6mw==; 9:vQwLns6sfd1TofSBV/ViI3aSKCcMLQw6y3k+UelOKcfL5UtUTKDf2xCfmZL/Mo0FBZ/lYrEmZdF8sXLRTjef6yuiDP7qjkEGc9rwmHPnFTsFKiNkeumdY3/BgtEXkLWfCjNglzbsI+511iTTqUZAUQ== X-OriginatorOrg: juniper.net Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] server-model #49: combine trusted-ca-certs and trusted-client-certs for ssh/tls? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 20:11:44 -0000 >Aha, ok, found it in an email from Kent. I suggest we try to keep a >single option list for each issue up to date. There are two different lists: - one list for what to do with this draft - the other list exploring how we might revise the module to use a keychain module in the future, assuming we don't do it now. The goal for the 2nd list was to see if there were any elegant options to delaying defining a keychain module now. To which I think only the "poor man's leafref" played out nicely. I just updated comment #1 on this issue to reflect the living status of this=20 issue: https://github.com/netconf-wg/server-model/issues/49 Regards, Kent From nobody Wed Jun 10 13:13:53 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC8D1A911E for ; Wed, 10 Jun 2015 13:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1TN49RGH7dL for ; Wed, 10 Jun 2015 13:13:49 -0700 (PDT) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8521B1A8A6E for ; Wed, 10 Jun 2015 13:13:49 -0700 (PDT) Received: by lbcmx3 with SMTP id mx3so34922550lbc.1 for ; Wed, 10 Jun 2015 13:13:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qM1xumoTtKptKckQshSUTvXzmHY3hDVlEGQC743iwPU=; b=Ma6Z1PjTbAq56IT2nXBWNnLLqiz505rrnjaq7QfaYyAN9PTEMTDlTxavsM3MPXd3W8 tpUbp2ZmQL5US6ofZbn734yjgSHzqb+mPOr82MOr7UmJIha7sCrtMO4rXXo+WDWCeIxI 1kSKv57Sq3suTC95/czUQ1YRwruIrRFM+Ca1UEdAC2Xd6Mt1s4T7ZGFtgVEvXm24Sysb iYsASdUdqkSEW/Oru5uo1kLP+BTS6iVIS76OYCdFOTMICvDgSZMYzepdxMWLREkPYtC7 TYlBKdlhbPRPzR+gNtQI3y9y56j9bf+FdyqqChYZs6ER5tuspA5U5UjaWRDu0k1MqZxt 2fBQ== X-Gm-Message-State: ALoCoQnk2b8EQy8llvc+jATt/ltkrOFeFt4XExcQUDmDAl5DRb2fQ08bqR9WLRRdYwR5JusWzmym MIME-Version: 1.0 X-Received: by 10.112.140.197 with SMTP id ri5mr5804314lbb.37.1433967226910; Wed, 10 Jun 2015 13:13:46 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Wed, 10 Jun 2015 13:13:46 -0700 (PDT) In-Reply-To: <43ACFC28-4ECD-4ED8-9229-76A0194B7A07@nic.cz> References: <20150608151059.GB30068@elstar.local> <20150610064843.GA36156@elstar.local> <20150610090640.GC36604@elstar.local> <20150610115449.GA37135@elstar.local> <820D7C0F-EE6C-4002-A8DD-1F9143C341B0@nic.cz> <20150610124829.GA37336@elstar.local> <43ACFC28-4ECD-4ED8-9229-76A0194B7A07@nic.cz> Date: Wed, 10 Jun 2015 13:13:46 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Netconf Subject: Re: [Netconf] YANG Patch Issue #3: :distinct-startup X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 20:13:51 -0000 On Wed, Jun 10, 2015 at 1:09 PM, Ladislav Lhotka wrote: > >> On 10 Jun 2015, at 16:36, Andy Bierman wrote: >> >> On Wed, Jun 10, 2015 at 5:48 AM, Juergen Schoenwaelder >> wrote: >>> On Wed, Jun 10, 2015 at 02:14:53PM +0200, Ladislav Lhotka wrote: >>>> >>>> If persistence means that config data survive a clean shutdown, then >>>> my understanding is that the unified datastore is persistent. It >>>> doesn=E2=80=99t necessarily mean synchronous writes of every edit thou= gh. >>> >>> Again, all I am saying it needs to be crystal clear what the to be >>> expected behaviour is. You are bringing up another option - fine. What >>> I do not want is that every implementation can pick its own choice. >>> >> >> The draft is clear -- the server saves to NV-store after every edit. > > Yes, but how it is done is an =E2=80=9Cimplementation-specific matter=E2= =80=9D. This may also mean it is a delayed write. I think the protocol spec= ification shouldn=E2=80=99t be too specific here, it should suffice to say = that it is expected the configuration won=E2=80=99t disappear with a device= reboot. > > These days, with all the virtualization options, cloud storage etc., it i= s hard to define what non-volatile storage is. > Maybe RESTCONF should not mention anything about NV-storage. Or maybe the "nv-store" flag should be a hint, but the server can ignore it= . NETCONF has no NV-storage requirement at all and that has not prevented servers from booting with the previous configuration. The market can decide how fast is fast enough. The market can decide that a configuration management system that only works until the next reboot is not OK. > Lada > Andy >> NETCONF is the one that is not very clear because it says nothing >> about NV-storage except for some very specific text about >> the startup datastore. If :startup is not supported, there is no >> NV storage requirement at all. >> >> In RESTCONF there is an NV storage requirement, which is compatible >> with NETCONF. RESTCONF does the edit procedure in 1 step. >> This goes for candidate or startup. Even if the server supports >> :candidate, the client does not do a 2-step edit+commit like NETCONF. >> >> >>> /js >> >> Andy >> >>> >>> -- >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>> Fax: +49 421 200 3103 > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From nobody Wed Jun 10 13:17:34 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD7131A92EF for ; Wed, 10 Jun 2015 13:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.061 X-Spam-Level: X-Spam-Status: No, score=-0.061 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_46=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSa971u5TiK1 for ; Wed, 10 Jun 2015 13:17:32 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15CF91A9241 for ; Wed, 10 Jun 2015 13:17:32 -0700 (PDT) Received: from [IPv6:2a01:5e0:29:ffff:842b:366c:980f:c11d] (unknown [IPv6:2a01:5e0:29:ffff:842b:366c:980f:c11d]) by mail.nic.cz (Postfix) with ESMTPSA id A25AF140152; Wed, 10 Jun 2015 22:17:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1433967450; bh=jAzG2iGKip03FVe1+pO34Tz07JU5eqxJeZGGSoULxRY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Eq9GMzvgZf3yNVNjPDUk/YWtv6rqNz5DWpNN7zyaOJs0+x7CPyNe7OFqeqN5sq1L2 78xmzHgNHPg5J5K7raqo5iy3R6pphrV5r+zCaQ0AnBAwhCsedb3gtVw1W1ZGBHKrUh EKQ6CmEHy0FF60pfOXkqEUrHEQ4E8V/1da3ulEGY= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ladislav Lhotka In-Reply-To: Date: Wed, 10 Jun 2015 22:17:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150608151059.GB30068@elstar.local> <20150610064843.GA36156@elstar.local> <20150610090640.GC36604@elstar.local> <20150610115449.GA37135@elstar.local> <820D7C0F-EE6C-4002-A8DD-1F9143C341B0@nic.cz> <20150610124829.GA37336@elstar.local> <43ACFC28-4ECD-4ED8-9229-76A0194B7A07@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.2098) X-Virus-Scanned: clamav-milter 0.98.6 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf Subject: Re: [Netconf] YANG Patch Issue #3: :distinct-startup X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 20:17:33 -0000 > On 10 Jun 2015, at 22:13, Andy Bierman wrote: >=20 > On Wed, Jun 10, 2015 at 1:09 PM, Ladislav Lhotka = wrote: >>=20 >>> On 10 Jun 2015, at 16:36, Andy Bierman wrote: >>>=20 >>> On Wed, Jun 10, 2015 at 5:48 AM, Juergen Schoenwaelder >>> wrote: >>>> On Wed, Jun 10, 2015 at 02:14:53PM +0200, Ladislav Lhotka wrote: >>>>>=20 >>>>> If persistence means that config data survive a clean shutdown, = then >>>>> my understanding is that the unified datastore is persistent. It >>>>> doesn=E2=80=99t necessarily mean synchronous writes of every edit = though. >>>>=20 >>>> Again, all I am saying it needs to be crystal clear what the to be >>>> expected behaviour is. You are bringing up another option - fine. = What >>>> I do not want is that every implementation can pick its own choice. >>>>=20 >>>=20 >>> The draft is clear -- the server saves to NV-store after every edit. >>=20 >> Yes, but how it is done is an =E2=80=9Cimplementation-specific = matter=E2=80=9D. This may also mean it is a delayed write. I think the = protocol specification shouldn=E2=80=99t be too specific here, it should = suffice to say that it is expected the configuration won=E2=80=99t = disappear with a device reboot. >>=20 >> These days, with all the virtualization options, cloud storage etc., = it is hard to define what non-volatile storage is. >>=20 >=20 > Maybe RESTCONF should not mention anything about NV-storage. > Or maybe the "nv-store" flag should be a hint, but the server can = ignore it. >=20 > NETCONF has no NV-storage requirement at all and that has not > prevented servers from booting with the previous configuration. > The market can decide how fast is fast enough. The market can > decide that a configuration management system that only works > until the next reboot is not OK. I agree. Lada >=20 >> Lada >>=20 >=20 > Andy >=20 >>> NETCONF is the one that is not very clear because it says nothing >>> about NV-storage except for some very specific text about >>> the startup datastore. If :startup is not supported, there is no >>> NV storage requirement at all. >>>=20 >>> In RESTCONF there is an NV storage requirement, which is compatible >>> with NETCONF. RESTCONF does the edit procedure in 1 step. >>> This goes for candidate or startup. Even if the server supports >>> :candidate, the client does not do a 2-step edit+commit like = NETCONF. >>>=20 >>>=20 >>>> /js >>>=20 >>> Andy >>>=20 >>>>=20 >>>> -- >>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>>> Fax: +49 421 200 3103 >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jun 10 15:35:49 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD381B2CEA for ; Wed, 10 Jun 2015 15:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bn73A70QKi6y for ; Wed, 10 Jun 2015 15:35:33 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0132.outbound.protection.outlook.com [207.46.100.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72FBB1A8F4B for ; Wed, 10 Jun 2015 15:35:25 -0700 (PDT) Received: from CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) by CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) with Microsoft SMTP Server (TLS) id 15.1.184.17; Wed, 10 Jun 2015 22:35:24 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.172.22; Wed, 10 Jun 2015 22:35:22 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.121]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.121]) with mapi id 15.01.0184.014; Wed, 10 Jun 2015 22:35:22 +0000 From: Kent Watsen To: Andy Bierman , Mahesh Jethanandani Thread-Topic: [Netconf] YANG Patch Issue #3: :distinct-startup Thread-Index: AQHQn7V+nTs/gEHKBUCSzfCLoklY1p2iSG2AgAAUEwCAAARBgIAAS84AgAADgwCAAAdzAIAAA7oAgADFgICAAMdGgIAASgcAgADBhoCAANLSAIAADKSA///l9wA= Date: Wed, 10 Jun 2015 22:35:22 +0000 Message-ID: References: <20150608.102005.1482395931170643204.mbj@tail-f.com> <20150608094708.GA28936@elstar.local> <20150608143100.GD29788@elstar.local> <20150608151059.GB30068@elstar.local> <20150610064843.GA36156@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.14] x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:CO1PR05MB459; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; x-forefront-prvs: 06036BD506 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51444003)(164054003)(5383002)(479174004)(377454003)(24454002)(106116001)(46102003)(92566002)(2950100001)(76176999)(87936001)(2656002)(93886004)(4001350100001)(62966003)(102836002)(99286002)(86362001)(50986999)(189998001)(5001770100001)(19580395003)(5001960100002)(40100003)(77156002)(54356999)(2900100001)(122556002)(5001920100001)(19580405001)(5002640100001)(83506001)(66066001)(36756003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jun 2015 22:35:22.5102 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459 X-OriginatorOrg: juniper.net Archived-At: Cc: Netconf Subject: Re: [Netconf] YANG Patch Issue #3: :distinct-startup X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 22:35:40 -0000 On 6/10/15, 4:08 PM, "Andy Bierman" wrote: >The other use of user-controlled NV-store is that in case the device >reboots, >it will come back with a known good configuration. If every edit is >NV-saved, >then there is no chance for the operator to test the changes before >changing the startup config. Both are important, but I think that this is the primary use case, with performance being a close second. Case in point, Junos CLI has auto-commit on by default (i.e. performance isn't an issue), but offers what is called Manual Commit mode (service manual-commit). I'm trying to collect numbers, but I heard that it's still widely used. Thanks, Kent From nobody Thu Jun 11 00:35:28 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1E31A92F2 for ; Thu, 11 Jun 2015 00:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gITd30C-wey for ; Thu, 11 Jun 2015 00:35:24 -0700 (PDT) Received: from smtpsec.ubiqube.com (smtpsec.netcelo.com [213.30.157.8]) by ietfa.amsl.com (Postfix) with ESMTP id DE8301A1EFD for ; Thu, 11 Jun 2015 00:35:19 -0700 (PDT) Received: from VANUATU.ubiqube.com (unknown [92.103.182.30]) by smtpsec.ubiqube.com (Postfix) with ESMTP id 3F559794B9 for ; Thu, 11 Jun 2015 07:35:18 +0000 (UTC) Received: from VANUATU.ubiqube.com ([10.15.1.111]) by VANUATU.ubiqube.com ([10.15.1.111]) with mapi; Thu, 11 Jun 2015 09:35:18 +0200 From: Said Malah To: Netconf Date: Thu, 11 Jun 2015 09:35:13 +0200 Thread-Topic: A tool to convert yang file to many extensions Thread-Index: AdCkGP7Japs2EoQfS0aGo5DWhUNHSA== Message-ID: <558404461FB4F343AE569BBAE75300390165D9147F3F@VANUATU.ubiqube.com> Accept-Language: fr-FR Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Netconf] A tool to convert yang file to many extensions X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 07:35:25 -0000 SGksDQoNCkkgd2lzaCBpZiBJIGNhbiBoYXZlIGEgdG9vbCBvdGhlciB0aGF0ICJweWFuZyIgdGhh dCBjYW4gbWFrZSBhbiB4bWwgZmlsZSBmcm9tIHlhbmcgZmlsZS4NCg0KVGhhbmsgeW91Lg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTmV0Y29uZiBt YWlsaW5nIGxpc3QNCk5ldGNvbmZAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbmV0Y29uZg0K From nobody Thu Jun 11 00:38:48 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 083521A3B9B for ; Thu, 11 Jun 2015 00:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cq-hGxxCSssg for ; Thu, 11 Jun 2015 00:38:45 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A33961A1EFD for ; Thu, 11 Jun 2015 00:38:45 -0700 (PDT) Received: from [IPv6:2001:1488:fffe:6:58ae:fb73:c3fe:c23e] (unknown [IPv6:2001:1488:fffe:6:58ae:fb73:c3fe:c23e]) by mail.nic.cz (Postfix) with ESMTPSA id 1286113F801; Thu, 11 Jun 2015 09:38:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1434008324; bh=ExaW8V6/x3lFdyxawfsjeOULX4VrmILcGBrWe89ntZM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=MK8CIi/T9Qt/8RfaHKlRtqe2cU0CR9Q2qILtrZ5JSaeWKxfeYOSzHkEZD1xt16Wbb 3265FO3gYKD9jdkDrRtMLhdCQHAj5Es9DikTgtbeG9QFW1JYIz5WYzw4u01VvV4Mki Y6hM3/tGX3kgfaDwR2mfqW36Z3kX1lJw+MN7BUTc= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ladislav Lhotka In-Reply-To: <558404461FB4F343AE569BBAE75300390165D9147F3F@VANUATU.ubiqube.com> Date: Thu, 11 Jun 2015 09:38:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <558404461FB4F343AE569BBAE75300390165D9147F3F@VANUATU.ubiqube.com> To: Said Malah X-Mailer: Apple Mail (2.2098) X-Virus-Scanned: clamav-milter 0.98.6 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf Subject: Re: [Netconf] A tool to convert yang file to many extensions X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 07:38:47 -0000 > On 11 Jun 2015, at 09:35, Said Malah wrote: >=20 > Hi, >=20 > I wish if I can have a tool other that "pyang" that can make an xml = file from yang file. Do you mean something like the sample-xml-skeleton plugin in pyang? I am = not aware of any other tool that does this. Lada >=20 > Thank you. >=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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jun 11 00:41:05 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95F141A86E6 for ; Thu, 11 Jun 2015 00:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K76GK-5KtMyj for ; Thu, 11 Jun 2015 00:41:02 -0700 (PDT) Received: from smtpsec.ubiqube.com (smtpsec.netcelo.com [213.30.157.8]) by ietfa.amsl.com (Postfix) with ESMTP id 457121A8035 for ; Thu, 11 Jun 2015 00:41:02 -0700 (PDT) Received: from VANUATU.ubiqube.com (unknown [92.103.182.30]) by smtpsec.ubiqube.com (Postfix) with ESMTP id 37D4178B9B; Thu, 11 Jun 2015 07:40:57 +0000 (UTC) Received: from VANUATU.ubiqube.com ([10.15.1.111]) by VANUATU.ubiqube.com ([10.15.1.111]) with mapi; Thu, 11 Jun 2015 09:40:36 +0200 From: Said Malah To: Ladislav Lhotka Date: Thu, 11 Jun 2015 09:40:35 +0200 Thread-Topic: [Netconf] A tool to convert yang file to many extensions Thread-Index: AdCkGaVm0x61utOeTMKWFz7REzsmWAAABHvg Message-ID: <558404461FB4F343AE569BBAE75300390165D9147F41@VANUATU.ubiqube.com> References: <558404461FB4F343AE569BBAE75300390165D9147F3F@VANUATU.ubiqube.com> In-Reply-To: Accept-Language: fr-FR Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Netconf Subject: Re: [Netconf] A tool to convert yang file to many extensions X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 07:41:03 -0000 Yes, something like that because the Pyang version didn't get an update sin= ce a while. So I wish if I can find a other tool that can do the same. -----Original Message----- From: Ladislav Lhotka [mailto:lhotka@nic.cz]=20 Sent: jeudi 11 juin 2015 09:39 To: Said Malah Cc: Netconf Subject: Re: [Netconf] A tool to convert yang file to many extensions > On 11 Jun 2015, at 09:35, Said Malah wrote: >=20 > Hi, >=20 > I wish if I can have a tool other that "pyang" that can make an xml file = from yang file. Do you mean something like the sample-xml-skeleton plugin in pyang? I am no= t aware of any other tool that does this. Lada >=20 > Thank you. >=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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jun 11 02:47:23 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD761ACDC5 for ; Thu, 11 Jun 2015 02:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppCsm2UylHwc for ; Thu, 11 Jun 2015 02:47:18 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0796.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::796]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 912DF1ACDC1 for ; Thu, 11 Jun 2015 02:47:16 -0700 (PDT) Received: from AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143) by AMXPR07MB021.eurprd07.prod.outlook.com (10.242.67.141) with Microsoft SMTP Server (TLS) id 15.1.184.17; Thu, 11 Jun 2015 09:47:00 +0000 Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none; Received: from pc6 (81.151.162.168) by AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143) with Microsoft SMTP Server (TLS) id 15.1.190.14; Thu, 11 Jun 2015 09:46:59 +0000 Message-ID: <02fb01d0a42b$33b519c0$4001a8c0@gateway.2wire.net> From: t.petch To: Kent Watsen , Alan Luchuk , References: <201505221959.t4MJxRHR081289@mainfs.snmp.com> <201506031817.t53IHJit066848@mainfs.snmp.com> <026301d0a29f$852a8340$4001a8c0@gateway.2wire.net> Date: Thu, 11 Jun 2015 10:44:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.162.168] X-ClientProxiedBy: DB4PR02CA0052.eurprd02.prod.outlook.com (10.242.174.180) To AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143) X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB054; 2:4A7baQhmFZs7j3MvHUkvojydanY/mLm7u8vasHTyTh97gU7pa49BFZa2BHpZltbK; 2:mK6ZZsN+2SpL14NIJsoytfpBGzLqYHbxKZd8JFxD0xVEc/ST771TXgkhBiEW+Xp3YlYmd2x153UOqOg4Onhd5MEPREcHvU6jW+VRiH9jeEmMgIWiPDbR/tJYsgor87HxlzstoNTyp7K0YSsNN8W6AA==; 6:1oQdwbDgsZ/KX7wYnZoU4LBR8XX3KohBFg0mHS5WZzS9PXS8jgoa/9QxpLmd2fIOUvKGyM64ipkUm/nEKnMAPaF01AWRJUbau1tkGTV0zQdKHv8J1yK7rgJUiWGxo9/g/MiYG5IjSnmuAZmzNUKIrA==; 3:/Tj+lymuprhi7I94sQn5L42uhu7bchPevq5WAv2b87vPAnk97R/Ra5i9Z06elAoXQQw5P1cXulp53rQgwL/vfXFt9YGj+diWNhVF9mSsythvzEOv+Ro7VHwiTy61jalq+/nAjBhi/QSQnG3Dc8Uyx5TSRjpPNAJEq34uQMiPwXBmKFJhnqOGUrr+1sjd54KUgVLNZltWMr5MRkcuJ6f7klkUkJvGoA+Xh+4ElqaqIXzUb0cqWoK0b1Jn829E9+5br5/BOzf7m8cEU7Z+XDLXxCHBMQ/BwokFyxVgbqImMVeK1wUCSF7ha5tQ37KY9exF X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:AMXPR07MB054; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:AMXPR07MB021; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520003)(3002001); SRVR:AMXPR07MB054; BCL:0; PCL:0; RULEID:; SRVR:AMXPR07MB054; X-Forefront-PRVS: 0604AFA86B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(377454003)(164054003)(13464003)(44736004)(50226001)(14496001)(230783001)(116806002)(19580405001)(62236002)(44716002)(86362001)(23756003)(50466002)(93886004)(84392001)(47776003)(66066001)(61296003)(42186005)(15975445007)(189998001)(5001960100002)(107886002)(5001920100001)(92566002)(19580395003)(62966003)(40100003)(122386002)(76176999)(5001770100001)(77156002)(50986999)(87976001)(33646002)(81686999)(77096005)(46102003)(81816999)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB054; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; AMXPR07MB054; 9:uMiPzYUUkEAuw7iUhqXI+apblxgrGY9lWjQfE+nuk?= =?iso-8859-1?Q?Dghdwn6gzVT7WydzhdD/KweKNhiHucIm2/x+jp61BnTkAn6TNbjDOEn9bD?= =?iso-8859-1?Q?4UCKwnirmO7RjJNZ8exTnC9u6CaaI4UHd4e8qathfUNsHZF95d4H+JNffn?= =?iso-8859-1?Q?kORuesK4y9ENwdLdldqCi9q0EIQ8dfDKzxq+Ps1LkggdkKNm0yF2ULH0q5?= =?iso-8859-1?Q?QFMAB2U3OAMwNdKWoN7iU6HQFytL0J0oXqQ2ccJlXNnrPpbMfCYxwW3J7D?= =?iso-8859-1?Q?To7pWdiecgU/blJ4nFPxK0afbMNa/hdRu6jZVDwz0kEA2zY6L2Q+4rWJ+T?= =?iso-8859-1?Q?K3n7UfIVFOr3EvCVZux/cpjfIAJ5RrTkTatuMmP9HLW2YGZkbhnSxA1W31?= =?iso-8859-1?Q?+uC9/ZpgJbpCEPgpOK+gRzPR/QhCLwDAzGv+h8jWokAIzHh0CToo1pg2IE?= =?iso-8859-1?Q?v+HnBvd7zugmZgnr/a8JLldTbwELTKDMDWc/HCuAADDF9KiGhyg01/wACP?= =?iso-8859-1?Q?J6LrOqCzL64T04Nio18ubnVpvVAPzrortxQcCqxBVyx06FrkWDlMWi01nb?= =?iso-8859-1?Q?B9ZA0dCd5hCjfNoGUsu4A4Hy+WA6MjvXIV8Cvml/Wg4kmXc/NpB2ICibiC?= =?iso-8859-1?Q?SrBgfMV7z5DEK9RE4bypkgns184bQM+BMJUp5pAlwvVWKLyWXur+Akthis?= =?iso-8859-1?Q?JZJU5+DHPbPSSl2dPNhdf/dav0VchmORaNUDI2+samaM5pRw8D6JP0htPz?= =?iso-8859-1?Q?lTNrGGMYskfsvLMYA0yig5ctbY4C5wfvBPtvYIPGKZeADEZEqVI7E8+VJ9?= =?iso-8859-1?Q?9MVV42yTzO9swCG7WnSPFp57Mt1pTvAD/4/1ae6mwslJv6QE86FWpApBEI?= =?iso-8859-1?Q?iQOcCw4KdSuhAuaqkcup1Ar5nMPpU6y3u8Hb6t7dVq1Ny3MeNFtLmBu/8w?= =?iso-8859-1?Q?zH9O8JPam2RA4ApwbWCK5jVGdNsdW3mxzvSq8hqQrJmJDDkkYHNLlgbDDr?= =?iso-8859-1?Q?LFiM/CyCLSKm83LUZjZB3Im71oDIyhYfqGfICy392tl8bWxkl1FeQkA5ET?= =?iso-8859-1?Q?4Rcx0QERuptOyrQrUZHJywIHITPnH3YbB+Stx0zD7o+CQ89TDlj95xlDpO?= =?iso-8859-1?Q?Juz6UD/u0K+Qrg7TXVAmLC0NWNyprGh0KPoOV8ilK9xHl8=3D?= X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB054; 3:6yL/ZRyefu8hTSVWKx6l2jFZabAbon+jMUnpFG0QeJa+bUFS92f9B/cnkcwxxKf83E1hcBWTL8l4xP6SsLeC7mtOpN00f6ez5Swbd6O+azPIeo7yHKMZnTWt2+KKF2INruXnMU8t/Mo8OEkzzHKJEg==; 10:MuoV41fjIJbz07UpqiYM8Cac2CvZx/hO+rRa89nEcmVOD0DHioEBTkRhLHQmFsF0W96X5T7h7BtWF/DmJIMG8hdNmdjq3DmUtW3+dfkZiak=; 6:w6Pr5gpVp58x/nONkBjw9McKlIk90ZDb+2el35kxOB9i4Cj+lsHmi6Riqll7u4NX X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jun 2015 09:46:59.6326 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB054 X-OriginatorOrg: btconnect.com Archived-At: Subject: Re: [Netconf] draft-ietf-netconf-call-home-05.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 09:47:22 -0000 ---- Original Message ----- From: "Kent Watsen" To: "t.petch" ; "Alan Luchuk" ; Sent: Tuesday, June 09, 2015 10:46 PM Hi Tom, >>No new split infinitives? ;) > >No but there might be the avoidance thereof in S4 >"the server MUST also send any intermediate certificates leading up to >the trust anchor the clients are expected use to authenticate it. " Good catch, this is what I have now: If a certificate is sent, the server MUST also send any intermediate certificates leading up to the trust anchor the client will use to authenticate the server's certificate with. OK? OK also OK with Jonathan's alternative >And in s.4, " This reversal is incongruous with [RFC4253], ", I wonder >if incongruent is intended. Searching "incongruous vs incongruent" returns a surprising number of responses. It seems that this is a common question! My reading is that "incongruous" is the better option here, so I plan to leave it as it is. !!! >One issue from earlier is what methods of authentication are acceptable. >5539bis now says X.509 certificate, RFC6242 is silent; I don't know >where Restconf is heading. This I-D sort of implies that servers will >only offer certificates or host keys, in which case I would like to see >that made explicit. True, RFC6242 is silent, for which I'm happy as it extends it to support RFC 6187. RESTCONF, like 5539bis, is also exclusively X.509: https://tools.ietf.org/html/draft-ietf-netconf-restconf-05#section-2.2. I'm not sure what to do about your last comment - any concrete suggestions? It is relatively easy to lock TLS to X.509, but SSH is all over the map. SSH calls it a "host key" (RFC 4251, Section-4.1), and host keys correspond to public key algorithms (RFC 4253, Section 7.1), and there are a number of algorithms (http://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh -pa rameters-19), some using certificates (e.g., RFC 6187). So an SSH host key can be a certificate too... yes but I think worth making explicit, saying something along the lines that that for TLS, the scope of authentication is the same as for 5539bis, namely X.509 certificates while for SSH, any method defined for SSH will do. The current text sort of implies a greater restriction and it is that that I wanted to clarify. >On client authentication by servers, we seem not to require it. I have >read and re-read >"3. The NETCONF or RESTCONF Server >3.1. Protocol Operation " >and can see no mention thereof. We have this on the client side: C7 After the server's host key or certificate is validated, the SSH or TLS protocol proceeds as normal to establish a SSH or TLS connection. Where "proceeds as normal" is intended to include the client authentication step. The closest equivalent on the server side is in the beginning go S5: S5 Once the SSH or TLS connection is established, the ... Where it's only tangentially implied. Complicating matters, client auth in RESTCONF only occurs in the secure transport when using the ClientCertificate authentication scheme. When using either the Basic or Digest authentication schemes, authentication occurs post-TLS in the HTTP layer. So implying client authentication always occurs as part of TLS connection establishment is not entirely accurate. This is why I was trying to hide all the client authentication steps behind the "proceeds as normal" clause and similar clauses in C8 and S5 regarding starting the NETCONF/RESTCONF protocols. I'm weary of this exploding into a lot of text. Can you suggest a simple fix? No:-( I had not thought through the RESTCONF implications. I will think some more but will probably end up leaving it as is unless anyone else picks up on it. Thanks, Kent From nobody Thu Jun 11 05:16:29 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A78391ACDED for ; Thu, 11 Jun 2015 05:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVyYOGXgjOtC for ; Thu, 11 Jun 2015 05:16:26 -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 623571ACDEC for ; Thu, 11 Jun 2015 05:16:25 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BTR19293; Thu, 11 Jun 2015 12:16:23 +0000 (GMT) Received: from SZXEML434-HUB.china.huawei.com (10.82.67.225) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 11 Jun 2015 13:16:23 +0100 Received: from SZXEML512-MBS.china.huawei.com ([169.254.8.185]) by szxeml434-hub.china.huawei.com ([10.82.67.225]) with mapi id 14.03.0158.001; Thu, 11 Jun 2015 20:15:28 +0800 From: Rohit R Ranade To: "netconf@ietf.org" Thread-Topic: Some doubts about draft-ietf-netconf-call-home-07 Thread-Index: AdCkQEtVofjRO8XGS4yLP5Tiq04C/A== Date: Thu, 11 Jun 2015 12:15:28 +0000 Message-ID: <991B70D8B4112A4699D5C00DDBBF878A67202231@szxeml512-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.144.92] Content-Type: multipart/alternative; boundary="_000_991B70D8B4112A4699D5C00DDBBF878A67202231szxeml512mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Netconf] Some doubts about draft-ietf-netconf-call-home-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 12:16:28 -0000 --_000_991B70D8B4112A4699D5C00DDBBF878A67202231szxeml512mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, In Section 2.1 : C1 The NETCONF/RESTCONF client listens for TCP connection requests from NETCONF/RESTCONF servers. The client SHOULD listen for connections on the IANA-assigned ports defined in section Section 5, but MAY be configured to use a non-standard port Here it mentions that NETCONF client needs to listen for TCP connections ev= en if NETCONF is over SSH ? If this is so, it violates one portion of "Introduction" section in RFC 474= 2 . Throughout this document, the terms "client" and "server" are used to refer to the two ends of the SSH transport connection. The client actively opens the SSH connection, and the server passively listens for the incoming SSH connection. In above statement , it mentions that SSH opens and listens on a connection= . Can you please explain as to why NETCONF should handle the call-home conn= ection when till now SSH was handling the connection part ? NETCONF client will have to accept connections, pass the socket FD to the S= SH client and then the SSH client will do the key-exchange and be ready wit= h the SSH connection. If there are some systems where in NETCONF and SSH are separate sub-systems= , then this passing of Socket Fds between modules is very cumbersome. Coming back to Section 2.1 in draft-ietf-netconf-call-home-07 C5 As part of establishing an SSH or TLS connection, the NETCONF/ RESTCONF client MUST validate the server's presented host key or certificate. This validation MAY be accomplished by certificate path validation or by comparing the host key or certificate to a previously trusted or "pinned" value. Validation of Server is SSH client job, should this not be done by SSH clie= nt ? Why NETCONF client need to validate Server ? The same holds good for C6 also .. With Regards, Rohit --_000_991B70D8B4112A4699D5C00DDBBF878A67202231szxeml512mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

In Section 2.1 :

 &=
nbsp; C1  The NETCONF/RESTCONF client listens for TCP connection reque=
sts
 &=
nbsp;     from NETCONF/RESTCONF servers.  The clie=
nt SHOULD listen for
 &=
nbsp;     connections on the IANA-assigned ports define=
d in section
 &=
nbsp;     Section 5, but MAY be configured t=
o use a non-standard port

 

Here it mentions that NETCONF client needs to listen= for TCP connections even if NETCONF is over SSH ?

If this is so, it violates one portion of “Int= roduction” section in RFC 4742 .

 

   Throughout this document, the terms "client&quo=
t; and "server" are used to
   refer to the two ends of the SSH transport connectio=
n.  The client
   actively opens the SSH connection, and the server pa=
ssively listens
   for the incoming SSH connection. <=
/pre>

 


In above statement , it mentions that SSH opens and =
listens on a connection. Can you please explain as to why NETCONF should ha=
ndle the call-home connection when till now SSH was handling the connection=
 part ?


 


NETCONF client will have to accept connections, pass=
 the socket FD to the SSH client and then the SSH client will do the key-ex=
change and be ready with the SSH connection.


If there are some systems where in NETCONF and SSH a=
re separate sub-systems,  then this passing of Socket Fds between modu=
les is very cumbersome.


 


Coming back to Section 2.1 in draft-ietf-netconf-cal=
l-home-07


 


 &=
nbsp; C5  As part of establishing an SSH or TLS connection, the NETCON=
F/


 &=
nbsp;     RESTCONF client MUST validate the server's pr=
esented host key or


 &=
nbsp;     certificate.  This validation MAY be acc=
omplished by certificate


 &=
nbsp;     path validation or by comparing the host key =
or certificate to a


 &=
nbsp;     previously trusted or "pinned" valu=
e.


 


Validation of Server is SSH client job, should this =
not be done by SSH client ? Why NETCONF client need to validate Server ?


The same holds good for C6 also ..


 


With Regards,


Rohit
--_000_991B70D8B4112A4699D5C00DDBBF878A67202231szxeml512mbschi_-- From nobody Thu Jun 11 06:44:17 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 905531A1B45 for ; Thu, 11 Jun 2015 06:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xka7Yq_3GHg5 for ; Thu, 11 Jun 2015 06:44:14 -0700 (PDT) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1C851A1B44 for ; Thu, 11 Jun 2015 06:44:14 -0700 (PDT) Received: by iebmu5 with SMTP id mu5so6072989ieb.1 for ; Thu, 11 Jun 2015 06:44:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=/oKLmgknUDauJPT1TJxWpf/bslnFjrLenp+/3T4H7PE=; b=QN4oEQrAnpSdEa7ycay1ieONAdteIPzi7tayBmI3dpslO0VqO1rnUj7gIPRplkcSO+ yUh8ZjORsxpRh0EEU0QcLy/q+V7jz0BuRYMHdcqjovrmEcHL6V3ZJ16MWcciIDOc1jGp sGgK0lmsWPBbKjlwXYm96FVwfLs2Nz+hgpOXpNw9ZfxaUdaW1tnggF1sxeBaOoMdsajv 24/WKl/xTCPu3rv63l6zoPY9O7fo1KRIiOtgpCbkAkWQdgTx56i6RsOjrMc1vofpYCNd i/7EcosU/vyTHv9gOpbG1YNZvdK55KAp3AzwhHdjYJr/x3vBn2TcerROonhZH4EQX42L 8RcA== X-Gm-Message-State: ALoCoQmPEYaDdrscDCBoOJIX6Ke1J6OA1JAh8jTKdCiTjCb+hBWUt1zFc0msFbp3GAnyqPY7mTqR X-Received: by 10.107.19.104 with SMTP id b101mr11686672ioj.39.1434030254156; Thu, 11 Jun 2015 06:44:14 -0700 (PDT) Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com. [209.85.223.173]) by mx.google.com with ESMTPSA id d77sm383038ioj.6.2015.06.11.06.44.12 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Jun 2015 06:44:13 -0700 (PDT) Received: by iesa3 with SMTP id a3so6057970ies.2 for ; Thu, 11 Jun 2015 06:44:12 -0700 (PDT) X-Received: by 10.107.136.42 with SMTP id k42mr10889338iod.63.1434030252207; Thu, 11 Jun 2015 06:44:12 -0700 (PDT) MIME-Version: 1.0 References: <558404461FB4F343AE569BBAE75300390165D9147F3F@VANUATU.ubiqube.com> <558404461FB4F343AE569BBAE75300390165D9147F41@VANUATU.ubiqube.com> In-Reply-To: <558404461FB4F343AE569BBAE75300390165D9147F41@VANUATU.ubiqube.com> From: Douglas Hubler Date: Thu, 11 Jun 2015 13:44:01 +0000 Message-ID: To: Said Malah , Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a113ecd9ec7b84f05183e2ff5 Archived-At: Cc: Netconf Subject: Re: [Netconf] A tool to convert yang file to many extensions X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 13:44:16 -0000 --001a113ecd9ec7b84f05183e2ff5 Content-Type: text/plain; charset=UTF-8 Are you looking to create YIN, or custom XML? If custom, you're looking for python API to walk yang tree? On Thu, Jun 11, 2015 at 3:41 AM Said Malah wrote: > Yes, something like that because the Pyang version didn't get an update > since a while. So I wish if I can find a other tool that can do the same. > > -----Original Message----- > From: Ladislav Lhotka [mailto:lhotka@nic.cz] > Sent: jeudi 11 juin 2015 09:39 > To: Said Malah > Cc: Netconf > Subject: Re: [Netconf] A tool to convert yang file to many extensions > > > > On 11 Jun 2015, at 09:35, Said Malah wrote: > > > > Hi, > > > > I wish if I can have a tool other that "pyang" that can make an xml file > from yang file. > > Do you mean something like the sample-xml-skeleton plugin in pyang? I am > not aware of any other tool that does this. > > Lada > > > > > Thank you. > > > > _______________________________________________ > > 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 > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a113ecd9ec7b84f05183e2ff5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Are you looking to create YIN, or custom XML?=C2=A0 If cus= tom, you're looking for python API to walk yang tree?

On Thu, Jun 11, 2015 at 3:41 AM Sai= d Malah <sma@ubiqube.com> wrot= e:
Yes, something like that because= the Pyang version didn't get an update since a while. So I wish if I c= an find a other tool that can do the same.

-----Original Message-----
From: Ladislav Lhotka [mailto:lhotka@nic.cz]
Sent: jeudi 11 juin 2015 09:39
To: Said Malah
Cc: Netconf
Subject: Re: [Netconf] A tool to convert yang file to many extensions


> On 11 Jun 2015, at 09:35, Said Malah <sma@ubiqube.com> wrote:
>
> Hi,
>
> I wish if I can have a tool other that "pyang" that can make= an xml file from yang file.

Do you mean something like the sample-xml-skeleton plugin in pyang? I am no= t aware of any other tool that does this.

Lada

>
> Thank you.
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org=
> https://www.ietf.org/mailman/listinfo/netconf<= br> > _______________________________________________
> Netconf mailing list
> Netconf@ietf.org=
> https://www.ietf.org/mailman/listinfo/netconf<= br>
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




_______________________________________________
Netconf mailing list
Netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--001a113ecd9ec7b84f05183e2ff5-- From nobody Thu Jun 11 07:42:07 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6246D1B29F6 for ; Thu, 11 Jun 2015 07:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BdfW4U5yS3Ud for ; Thu, 11 Jun 2015 07:42:04 -0700 (PDT) Received: from smtpsec.ubiqube.com (smtpsec.netcelo.com [213.30.157.8]) by ietfa.amsl.com (Postfix) with ESMTP id EF57E1A6EE4 for ; Thu, 11 Jun 2015 07:38:55 -0700 (PDT) Received: from VANUATU.ubiqube.com (unknown [92.103.182.30]) by smtpsec.ubiqube.com (Postfix) with ESMTP id E9AE07951E; Thu, 11 Jun 2015 14:38:54 +0000 (UTC) Received: from VANUATU.ubiqube.com ([10.15.1.111]) by VANUATU.ubiqube.com ([10.15.1.111]) with mapi; Thu, 11 Jun 2015 16:38:54 +0200 From: Said Malah To: Douglas Hubler , Ladislav Lhotka Date: Thu, 11 Jun 2015 16:38:53 +0200 Thread-Topic: [Netconf] A tool to convert yang file to many extensions Thread-Index: AdCkTLTf0Wu8ZAgvStSK6pwYeYoQxgAB0tDA Message-ID: <558404461FB4F343AE569BBAE75300390165D9147F75@VANUATU.ubiqube.com> References: <558404461FB4F343AE569BBAE75300390165D9147F3F@VANUATU.ubiqube.com> <558404461FB4F343AE569BBAE75300390165D9147F41@VANUATU.ubiqube.com> In-Reply-To: Accept-Language: fr-FR Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_558404461FB4F343AE569BBAE75300390165D9147F75VANUATUubiq_" MIME-Version: 1.0 Archived-At: Cc: Netconf Subject: Re: [Netconf] A tool to convert yang file to many extensions X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 14:42:06 -0000 --_000_558404461FB4F343AE569BBAE75300390165D9147F75VANUATUubiq_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VG8gYmUgYWNjdXJhdGUsIEnigJltIGxvb2tpbmcgZm9yIGEgdG9vbCB0aGF0IGNhbiBtYWtlIHRo ZSBzYW1lIG91dHB1dCBhcyBQeWFuZyBmb3IgeG1sIHNvIGEgY3VzdG9tIFhNTC4NCkJ1dCB3aHkg dGhlcmUgaXMganVzdCBhIFB5dGhvbiBBUEkgZm9yIHRoYXQgPw0KSSBkaWQgbWFueSByZXNlYXJj aCBpbiB2YWluIGFjdHVhbGx5IHRvIGZpbmQgYSB3YXkgdG8gY29udmVydCAhISBub3RoaW5nICEN Cg0KRnJvbTogRG91Z2xhcyBIdWJsZXIgW21haWx0bzpkb3VnbGFzQGh1Ymxlci51c10NClNlbnQ6 IGpldWRpIDExIGp1aW4gMjAxNSAxNTo0NA0KVG86IFNhaWQgTWFsYWg7IExhZGlzbGF2IExob3Rr YQ0KQ2M6IE5ldGNvbmYNClN1YmplY3Q6IFJlOiBbTmV0Y29uZl0gQSB0b29sIHRvIGNvbnZlcnQg eWFuZyBmaWxlIHRvIG1hbnkgZXh0ZW5zaW9ucw0KDQpBcmUgeW91IGxvb2tpbmcgdG8gY3JlYXRl IFlJTiwgb3IgY3VzdG9tIFhNTD8gIElmIGN1c3RvbSwgeW91J3JlIGxvb2tpbmcgZm9yIHB5dGhv biBBUEkgdG8gd2FsayB5YW5nIHRyZWU/DQoNCk9uIFRodSwgSnVuIDExLCAyMDE1IGF0IDM6NDEg QU0gU2FpZCBNYWxhaCA8c21hQHViaXF1YmUuY29tPG1haWx0bzpzbWFAdWJpcXViZS5jb20+PiB3 cm90ZToNClllcywgc29tZXRoaW5nIGxpa2UgdGhhdCBiZWNhdXNlIHRoZSBQeWFuZyB2ZXJzaW9u IGRpZG4ndCBnZXQgYW4gdXBkYXRlIHNpbmNlIGEgd2hpbGUuIFNvIEkgd2lzaCBpZiBJIGNhbiBm aW5kIGEgb3RoZXIgdG9vbCB0aGF0IGNhbiBkbyB0aGUgc2FtZS4NCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IExhZGlzbGF2IExob3RrYSBbbWFpbHRvOmxob3RrYUBuaWMuY3o8 bWFpbHRvOmxob3RrYUBuaWMuY3o+XQ0KU2VudDogamV1ZGkgMTEganVpbiAyMDE1IDA5OjM5DQpU bzogU2FpZCBNYWxhaA0KQ2M6IE5ldGNvbmYNClN1YmplY3Q6IFJlOiBbTmV0Y29uZl0gQSB0b29s IHRvIGNvbnZlcnQgeWFuZyBmaWxlIHRvIG1hbnkgZXh0ZW5zaW9ucw0KDQoNCj4gT24gMTEgSnVu IDIwMTUsIGF0IDA5OjM1LCBTYWlkIE1hbGFoIDxzbWFAdWJpcXViZS5jb208bWFpbHRvOnNtYUB1 YmlxdWJlLmNvbT4+IHdyb3RlOg0KPg0KPiBIaSwNCj4NCj4gSSB3aXNoIGlmIEkgY2FuIGhhdmUg YSB0b29sIG90aGVyIHRoYXQgInB5YW5nIiB0aGF0IGNhbiBtYWtlIGFuIHhtbCBmaWxlIGZyb20g eWFuZyBmaWxlLg0KDQpEbyB5b3UgbWVhbiBzb21ldGhpbmcgbGlrZSB0aGUgc2FtcGxlLXhtbC1z a2VsZXRvbiBwbHVnaW4gaW4gcHlhbmc/IEkgYW0gbm90IGF3YXJlIG9mIGFueSBvdGhlciB0b29s IHRoYXQgZG9lcyB0aGlzLg0KDQpMYWRhDQoNCj4NCj4gVGhhbmsgeW91Lg0KPg0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBOZXRjb25mIG1haWxp bmcgbGlzdA0KPiBOZXRjb25mQGlldGYub3JnPG1haWx0bzpOZXRjb25mQGlldGYub3JnPg0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gTmV0Y29uZiBtYWlsaW5n IGxpc3QNCj4gTmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86TmV0Y29uZkBpZXRmLm9yZz4NCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQoNCi0tDQpMYWRpc2xh diBMaG90a2EsIENaLk5JQyBMYWJzDQpQR1AgS2V5IElEOiBFNzRFOEMwQw0KDQoNCg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTmV0Y29uZiBtYWls aW5nIGxpc3QNCk5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmc+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg== --_000_558404461FB4F343AE569BBAE75300390165D9147F75VANUATUubiq_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNv QWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxv b24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNw YW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzQ0NTQ2QTt9DQpzcGFuLkJh bGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglm b250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RlI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFy Z2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RlIgbGluaz1ibHVlIHZs aW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiM0NDU0NkEnPlRvIGJlIGFjY3VyYXRlLCBJ4oCZbSBsb29r aW5nIGZvciBhIHRvb2wgdGhhdCBjYW4gbWFrZSB0aGUgc2FtZSBvdXRwdXQgYXMgUHlhbmcgZm9y IHhtbCBzbyBhIGN1c3RvbSBYTUwuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzQ0NTQ2QSc+QnV0IHdoeSB0aGVyZSBpcyBq dXN0IGEgUHl0aG9uIEFQSSBmb3IgdGhhdCA/PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzQ0NTQ2QSc+SSBkaWQgbWFueSBy ZXNlYXJjaCBpbiB2YWluIGFjdHVhbGx5IHRvIGZpbmQgYSB3YXkgdG8gY29udmVydCAhISBub3Ro aW5nICE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9 RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojNDQ1NDZBJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxiPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g bGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwi c2Fucy1zZXJpZiInPiBEb3VnbGFzIEh1YmxlciBbbWFpbHRvOmRvdWdsYXNAaHVibGVyLnVzXSA8 YnI+PGI+U2VudDo8L2I+IGpldWRpIDExIGp1aW4gMjAxNSAxNTo0NDxicj48Yj5Ubzo8L2I+IFNh aWQgTWFsYWg7IExhZGlzbGF2IExob3RrYTxicj48Yj5DYzo8L2I+IE5ldGNvbmY8YnI+PGI+U3Vi amVjdDo8L2I+IFJlOiBbTmV0Y29uZl0gQSB0b29sIHRvIGNvbnZlcnQgeWFuZyBmaWxlIHRvIG1h bnkgZXh0ZW5zaW9uczxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PG86 cD4mbmJzcDs8L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+QXJlIHlvdSBsb29raW5n IHRvIGNyZWF0ZSBZSU4sIG9yIGN1c3RvbSBYTUw/Jm5ic3A7IElmIGN1c3RvbSwgeW91J3JlIGxv b2tpbmcgZm9yIHB5dGhvbiBBUEkgdG8gd2FsayB5YW5nIHRyZWU/PG86cD48L286cD48L3A+PC9k aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+T24gVGh1LCBKdW4gMTEsIDIwMTUgYXQgMzo0MSBBTSBTYWlkIE1hbGFo ICZsdDs8YSBocmVmPSJtYWlsdG86c21hQHViaXF1YmUuY29tIj5zbWFAdWJpcXViZS5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD48L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0nYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20nPjxwIGNsYXNzPU1zb05v cm1hbD5ZZXMsIHNvbWV0aGluZyBsaWtlIHRoYXQgYmVjYXVzZSB0aGUgUHlhbmcgdmVyc2lvbiBk aWRuJ3QgZ2V0IGFuIHVwZGF0ZSBzaW5jZSBhIHdoaWxlLiBTbyBJIHdpc2ggaWYgSSBjYW4gZmlu ZCBhIG90aGVyIHRvb2wgdGhhdCBjYW4gZG8gdGhlIHNhbWUuPGJyPjxicj4tLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLTxicj5Gcm9tOiBMYWRpc2xhdiBMaG90a2EgW21haWx0bzo8YSBocmVmPSJt YWlsdG86bGhvdGthQG5pYy5jeiIgdGFyZ2V0PSJfYmxhbmsiPmxob3RrYUBuaWMuY3o8L2E+XTxi cj5TZW50OiBqZXVkaSAxMSBqdWluIDIwMTUgMDk6Mzk8YnI+VG86IFNhaWQgTWFsYWg8YnI+Q2M6 IE5ldGNvbmY8YnI+U3ViamVjdDogUmU6IFtOZXRjb25mXSBBIHRvb2wgdG8gY29udmVydCB5YW5n IGZpbGUgdG8gbWFueSBleHRlbnNpb25zPGJyPjxicj48YnI+Jmd0OyBPbiAxMSBKdW4gMjAxNSwg YXQgMDk6MzUsIFNhaWQgTWFsYWggJmx0OzxhIGhyZWY9Im1haWx0bzpzbWFAdWJpcXViZS5jb20i IHRhcmdldD0iX2JsYW5rIj5zbWFAdWJpcXViZS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+Jmd0Ozxi cj4mZ3Q7IEhpLDxicj4mZ3Q7PGJyPiZndDsgSSB3aXNoIGlmIEkgY2FuIGhhdmUgYSB0b29sIG90 aGVyIHRoYXQgJnF1b3Q7cHlhbmcmcXVvdDsgdGhhdCBjYW4gbWFrZSBhbiB4bWwgZmlsZSBmcm9t IHlhbmcgZmlsZS48YnI+PGJyPkRvIHlvdSBtZWFuIHNvbWV0aGluZyBsaWtlIHRoZSBzYW1wbGUt eG1sLXNrZWxldG9uIHBsdWdpbiBpbiBweWFuZz8gSSBhbSBub3QgYXdhcmUgb2YgYW55IG90aGVy IHRvb2wgdGhhdCBkb2VzIHRoaXMuPGJyPjxicj5MYWRhPGJyPjxicj4mZ3Q7PGJyPiZndDsgVGhh bmsgeW91Ljxicj4mZ3Q7PGJyPiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+Jmd0OyBOZXRjb25mIG1haWxpbmcgbGlzdDxicj4mZ3Q7IDxhIGhy ZWY9Im1haWx0bzpOZXRjb25mQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+TmV0Y29uZkBpZXRm Lm9yZzwvYT48YnI+Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25ldGNvbmYiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25ldGNvbmY8L2E+PGJyPiZndDsgX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+Jmd0OyBOZXRjb25mIG1haWxpbmcgbGlzdDxicj4m Z3Q7IDxhIGhyZWY9Im1haWx0bzpOZXRjb25mQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+TmV0 Y29uZkBpZXRmLm9yZzwvYT48YnI+Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL25ldGNvbmYiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmY8L2E+PGJyPjxicj4tLTxicj5MYWRpc2xhdiBM aG90a2EsIENaLk5JQyBMYWJzPGJyPlBHUCBLZXkgSUQ6IEU3NEU4QzBDPGJyPjxicj48YnI+PGJy Pjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj5O ZXRjb25mIG1haWxpbmcgbGlzdDxicj48YSBocmVmPSJtYWlsdG86TmV0Y29uZkBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPk5ldGNvbmZAaWV0Zi5vcmc8L2E+PGJyPjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZiIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZjwvYT48bzpwPjwvbzpw PjwvcD48L2Jsb2NrcXVvdGU+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_558404461FB4F343AE569BBAE75300390165D9147F75VANUATUubiq_-- From nobody Thu Jun 11 08:28:39 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 637C41ACDE7 for ; Thu, 11 Jun 2015 08:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBQsfjB6c59b for ; Thu, 11 Jun 2015 08:28:33 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 098271A1A68 for ; Thu, 11 Jun 2015 08:28:33 -0700 (PDT) Received: from [IPv6:2a01:5e0:29:ffff:71d7:7e72:6489:1a52] (unknown [IPv6:2a01:5e0:29:ffff:71d7:7e72:6489:1a52]) by mail.nic.cz (Postfix) with ESMTPSA id 7EAD2140AE0; Thu, 11 Jun 2015 17:28:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1434036511; bh=poDek7V3fd1vNVbC0Fh2EUzP4U95mnDbuqqJfELNQfs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=gOYvhjtnXyIjnVyZGET5gQUMCabGH+lA7Pnk6rgQsjjqS/wp9t3uILvdFk3vYWTVr v/+k/VpKZbjvGLN5u9pykGx9zZOexstpl9eQ1SuA7FpwGcpXgaMKD4OeBioQtx8h1W 8bqXTiNrROMIP8os7f3rvF6DXOxtLG/lfwDQV61I= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ladislav Lhotka In-Reply-To: Date: Thu, 11 Jun 2015 17:28:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <917DAE81-647B-4CC1-B468-907437E5846F@nic.cz> References: <558404461FB4F343AE569BBAE75300390165D9147F3F@VANUATU.ubiqube.com> <558404461FB4F343AE569BBAE75300390165D9147F41@VANUATU.ubiqube.com> To: Douglas Hubler X-Mailer: Apple Mail (2.2098) X-Virus-Scanned: clamav-milter 0.98.6 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf Subject: Re: [Netconf] A tool to convert yang file to many extensions X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 15:28:35 -0000 > On 11 Jun 2015, at 15:44, Douglas Hubler wrote: >=20 > Are you looking to create YIN, or custom XML? If custom, you're = looking for python API to walk yang tree? >=20 > On Thu, Jun 11, 2015 at 3:41 AM Said Malah wrote: > Yes, something like that because the Pyang version didn't get an = update since a while. So I wish if I can find a other tool that can do = the same. sample-xml-skeleton plugin is available in the stable 1.5 version of = pyang, so I don=E2=80=99t understand why you can=E2=80=99t use it. Lada >=20 > -----Original Message----- > From: Ladislav Lhotka [mailto:lhotka@nic.cz] > Sent: jeudi 11 juin 2015 09:39 > To: Said Malah > Cc: Netconf > Subject: Re: [Netconf] A tool to convert yang file to many extensions >=20 >=20 > > On 11 Jun 2015, at 09:35, Said Malah wrote: > > > > Hi, > > > > I wish if I can have a tool other that "pyang" that can make an xml = file from yang file. >=20 > Do you mean something like the sample-xml-skeleton plugin in pyang? I = am not aware of any other tool that does this. >=20 > Lada >=20 > > > > Thank you. > > > > _______________________________________________ > > 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 >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=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 Thu Jun 11 10:46:02 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA16C1A017C for ; Thu, 11 Jun 2015 10:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWUms0ac0d5v for ; Thu, 11 Jun 2015 10:45:59 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0112.outbound.protection.outlook.com [207.46.100.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6877E1A8BB1 for ; Thu, 11 Jun 2015 10:45:58 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.1.184.17; Thu, 11 Jun 2015 17:45:57 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.121]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.121]) with mapi id 15.01.0184.014; Thu, 11 Jun 2015 17:45:57 +0000 From: Kent Watsen To: Rohit R Ranade , "netconf@ietf.org" Thread-Topic: [Netconf] Some doubts about draft-ietf-netconf-call-home-07 Thread-Index: AQHQpG545iqpAB5O/k+2wwLTsZvz+w== Date: Thu, 11 Jun 2015 17:45:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: huawei.com; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.12] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:CO1PR05MB458; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458; x-forefront-prvs: 0604AFA86B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(51444003)(164054003)(106116001)(66066001)(5002640100001)(86362001)(189998001)(62966003)(40100003)(2501003)(77156002)(46102003)(36756003)(2900100001)(230783001)(83506001)(102836002)(92566002)(5001920100001)(5001960100002)(107886002)(54356999)(122556002)(50986999)(5001770100001)(87936001)(2656002)(4001350100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jun 2015 17:45:57.0886 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB458 Archived-At: Subject: Re: [Netconf] Some doubts about draft-ietf-netconf-call-home-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 17:46:00 -0000 > In Section 2.1 : > C1 The NETCONF/RESTCONF client listens for TCP connection requests > from NETCONF/RESTCONF servers. The client SHOULD listen for > connections on the IANA-assigned ports defined in section > Section 5, but MAY be configured to use a non-standard port > > Here it mentions that NETCONF client needs to listen for TCP connections >even if NETCONF is over SSH ? > If this is so, it violates one portion of =B3Introduction=B2 section in R= FC >4742 . =20 > > Throughout this document, the terms "client" and "server" are used to > refer to the two ends of the SSH transport connection. The client > actively opens the SSH connection, and the server passively listens > for the incoming SSH connection. RFC 4742 is obsolete, replaced by RFC 6242, which does not include the quoted text above. I can't find any conflicts with RFC 6242, can you? > In above statement , it mentions that SSH opens and listens on > a connection. Can you please explain as to why NETCONF should > handle the call-home connection when till now SSH was handling > the connection part ? I don't understand your question, but I think that you asked a similar question back in March. Recall that with call home, there is a reversal as to which peer initiates the TCP connection, otherwise all the roles are the same. Actually, the current text was greatly expanded to address your earlier request for clarification. Is the new text still not clear enough? =20 > NETCONF client will have to accept connections, pass the socket > FD to the SSH client and then the SSH client will do the key- > exchange and be ready with the SSH connection. If there are > some systems where in NETCONF and SSH are separate sub-systems, > then this passing of Socket Fds between modules is very cumbersome. On the contrary, the NETCONF/SSH call-home client code has be written in a few programming languages already without issue. All SSH libraries seem to support the ability to passed an accepted socket into the SSH library. As for SSH and NETCONF being separate, call home doesn't change anything between the SSH and NETCONF layers - in all cases, the NETCONF client opens the "netconf" SSH subsystem on the NETCONF server... =20 > Coming back to Section 2.1 in draft-ietf-netconf-call-home-07 > =20 > C5 As part of establishing an SSH or TLS connection, the NETCONF/ > RESTCONF client MUST validate the server's presented host key or > certificate. This validation MAY be accomplished by certificate > path validation or by comparing the host key or certificate to a > previously trusted or "pinned" value. > > Validation of Server is SSH client job, should this not be done by SSH > client ? Why NETCONF client need to validate Server ? The same holds > good for C6 also .. =20 Keep in mind that the NETCONF client *is* the SSH client, so actually it is as you say it should be. Makes sense? Thanks, Kent From nobody Thu Jun 11 11:57:35 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B08CC1B2CC3 for ; Thu, 11 Jun 2015 11:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.745 X-Spam-Level: X-Spam-Status: No, score=-0.745 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_IS_SMALL6=0.556, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nloQdmJ-lCc for ; Thu, 11 Jun 2015 11:57:31 -0700 (PDT) Received: from ni.com (skprod2.natinst.com [130.164.80.23]) (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 8DF061B2CC2 for ; Thu, 11 Jun 2015 11:57:31 -0700 (PDT) Received: from US-AUS-MAIL4.amer.corp.natinst.com (nb-chan1-1338.natinst.com [130.164.19.134]) by us-aus-skprod2.natinst.com (8.15.0.59/8.15.0.59) with ESMTP id t5BIvUmm024756; Thu, 11 Jun 2015 13:57:30 -0500 In-Reply-To: References: <20150608151059.GB30068@elstar.local> <20150610064843.GA36156@elstar.local> <20150610090640.GC36604@elstar.local> <20150610115449.GA37135@elstar.local> <820D7C0F-EE6C-4002-A8DD-1F9143C341B0@nic.cz> <20150610124829.GA37336@elstar.local> <43ACFC28-4ECD-4ED8-9229-76A0194B7A07@nic.cz> To: Andy Bierman MIME-Version: 1.0 X-KeepSent: 755B78AF:ED529BE9-86257E61:0066A834; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3FP3 November 16, 2012 From: Rodney Cummings Message-ID: Date: Thu, 11 Jun 2015 13:57:30 -0500 X-MIMETrack: Serialize by Router on US-AUS-MAIL4/AUS/M/NIC(Release 8.5.3FP6 HF1218|December 12, 2014) at 06/11/2015 01:57:30 PM, Serialize complete at 06/11/2015 01:57:30 PM Content-Type: multipart/alternative; boundary="=_alternative 0068244386257E61_=" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-06-11_09:, , signatures=0 Archived-At: Cc: Netconf Subject: Re: [Netconf] YANG Patch Issue #3: :distinct-startup X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 18:57:33 -0000 This is a multipart message in MIME format. --=_alternative 0068244386257E61_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 UGVyc29uYWxseSwgSSByZWFsbHkgbGlrZSB0aGUgZmFjdCB0aGF0IFJFU1RDT05GIHNwZWNpZmll cyB0aGUgTlYgc3RvcmFnZSANCnJlcXVpcmVtZW50Lg0KDQpTb21lIGFwcGxpY2F0aW9ucyByZXF1 aXJlIE5WIHN0b3JhZ2UgYXMgYSBiYXNlbGluZSBhc3N1bXB0aW9uLiBJZiB3ZSBsZWF2ZSANCk5W IHN0b3JhZ2UgdW5zcGVjaWZpZWQgaW4gUkVTVENPTkYsIHRoYXQgYnJpbmdzIHRoZSByaXNrIHRo YXQgZGlmZmVyZW50IA0KYXBwbGljYXRpb25zIG11c3Qgc3BlY2lmeSB0aGVpciBvd24gTlYgcmVx dWlyZW1lbnRzIG91dHNpZGUgb2YgUkVTVENPTkYuIA0KVGhlIG1hcmtldCBtYXkgcHVsbCB0aGlz IGlzc3VlIGluIGRpZmZlcmVudCBkaXJlY3Rpb25zLg0KDQpJIHRlbmQgdG8gdGhpbmsgb2YgdGhl IFJFU1RDT05GIHNlY3Rpb24gMy40IGFzIGNsZWFyLCBpbiB0aGF0IGl0IGltcGxpZXMgDQp0aGF0 IHRoZSBzYXZlIHRvIE5WIHN0b3JhZ2Ugb2NjdXJzIHByaW9yIHRvIHRoZSByZXNwb25zZSB0byBQ QVRDSC4gSWYgc29tZSANCmFyZSBjb25jZXJuZWQgdGhhdCB0aGlzIGlzIG5vdCBzdWZmaWNpZW50 bHkgY2xlYXIsIHdlIGNvdWxkIHBvc3NpYmx5IA0KY2hhbmdlIHRoZSB0ZXh0IHRvIHN0YXRlIHRo aXMgZXhwbGljaXRseS4NCg0KSWYgYSBnaXZlbiBpbXBsZW1lbnRhdGlvbiBkb2VzIG5vdCB3YW50 IHRvIHNhdmUgdG8gTlYgc3RvcmFnZSBvbiBlYWNoIA0KZWRpdCwgSSB3b3VsZCBhcmd1ZSB0aGF0 IE5FVENPTkYgaXMgdGhlIGJlc3QgYWx0ZXJuYXRpdmUuIEkgZG9uJ3QgdGhpbmsgd2UgDQpzaG91 bGQgYWRkIGV2ZXJ5IGZlYXR1cmUgZnJvbSBORVRDT05GIGludG8gUkVTVENPTkYuDQoNCg0KDQpG cm9tOiAgIEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPg0KVG86ICAgICBMYWRpc2xh diBMaG90a2EgPGxob3RrYUBuaWMuY3o+LCANCkNjOiAgICAgTmV0Y29uZiA8bmV0Y29uZkBpZXRm Lm9yZz4NCkRhdGU6ICAgMDYvMTAvMjAxNSAwMzoxMyBQTQ0KU3ViamVjdDogICAgICAgIFJlOiBb TmV0Y29uZl0gWUFORyBQYXRjaCBJc3N1ZSAjMzogOmRpc3RpbmN0LXN0YXJ0dXANClNlbnQgYnk6 ICAgICAgICAiTmV0Y29uZiIgPG5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZz4NCg0KDQoNCk9uIFdl ZCwgSnVuIDEwLCAyMDE1IGF0IDE6MDkgUE0sIExhZGlzbGF2IExob3RrYSA8bGhvdGthQG5pYy5j ej4gd3JvdGU6DQo+DQo+PiBPbiAxMCBKdW4gMjAxNSwgYXQgMTY6MzYsIEFuZHkgQmllcm1hbiA8 YW5keUB5dW1hd29ya3MuY29tPiB3cm90ZToNCj4+DQo+PiBPbiBXZWQsIEp1biAxMCwgMjAxNSBh dCA1OjQ4IEFNLCBKdWVyZ2VuIFNjaG9lbndhZWxkZXINCj4+IDxqLnNjaG9lbndhZWxkZXJAamFj b2JzLXVuaXZlcnNpdHkuZGU+IHdyb3RlOg0KPj4+IE9uIFdlZCwgSnVuIDEwLCAyMDE1IGF0IDAy OjE0OjUzUE0gKzAyMDAsIExhZGlzbGF2IExob3RrYSB3cm90ZToNCj4+Pj4NCj4+Pj4gSWYgcGVy c2lzdGVuY2UgbWVhbnMgdGhhdCBjb25maWcgZGF0YSBzdXJ2aXZlIGEgY2xlYW4gc2h1dGRvd24s IHRoZW4NCj4+Pj4gbXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IHRoZSB1bmlmaWVkIGRhdGFzdG9y ZSBpcyBwZXJzaXN0ZW50LiBJdA0KPj4+PiBkb2VzbuKAmXQgbmVjZXNzYXJpbHkgbWVhbiBzeW5j aHJvbm91cyB3cml0ZXMgb2YgZXZlcnkgZWRpdCB0aG91Z2guDQo+Pj4NCj4+PiBBZ2FpbiwgYWxs IEkgYW0gc2F5aW5nIGl0IG5lZWRzIHRvIGJlIGNyeXN0YWwgY2xlYXIgd2hhdCB0aGUgdG8gYmUN Cj4+PiBleHBlY3RlZCBiZWhhdmlvdXIgaXMuIFlvdSBhcmUgYnJpbmdpbmcgdXAgYW5vdGhlciBv cHRpb24gLSBmaW5lLiBXaGF0DQo+Pj4gSSBkbyBub3Qgd2FudCBpcyB0aGF0IGV2ZXJ5IGltcGxl bWVudGF0aW9uIGNhbiBwaWNrIGl0cyBvd24gY2hvaWNlLg0KPj4+DQo+Pg0KPj4gVGhlIGRyYWZ0 IGlzIGNsZWFyIC0tIHRoZSBzZXJ2ZXIgc2F2ZXMgdG8gTlYtc3RvcmUgYWZ0ZXIgZXZlcnkgZWRp dC4NCj4NCj4gWWVzLCBidXQgaG93IGl0IGlzIGRvbmUgaXMgYW4g4oCcaW1wbGVtZW50YXRpb24t c3BlY2lmaWMgbWF0dGVy4oCdLiBUaGlzIG1heSANCmFsc28gbWVhbiBpdCBpcyBhIGRlbGF5ZWQg d3JpdGUuIEkgdGhpbmsgdGhlIHByb3RvY29sIHNwZWNpZmljYXRpb24gDQpzaG91bGRu4oCZdCBi ZSB0b28gc3BlY2lmaWMgaGVyZSwgaXQgc2hvdWxkIHN1ZmZpY2UgdG8gc2F5IHRoYXQgaXQgaXMg DQpleHBlY3RlZCB0aGUgY29uZmlndXJhdGlvbiB3b27igJl0IGRpc2FwcGVhciB3aXRoIGEgZGV2 aWNlIHJlYm9vdC4NCj4NCj4gVGhlc2UgZGF5cywgd2l0aCBhbGwgdGhlIHZpcnR1YWxpemF0aW9u IG9wdGlvbnMsIGNsb3VkIHN0b3JhZ2UgZXRjLiwgaXQgDQppcyBoYXJkIHRvIGRlZmluZSB3aGF0 IG5vbi12b2xhdGlsZSBzdG9yYWdlIGlzLg0KPg0KDQpNYXliZSBSRVNUQ09ORiBzaG91bGQgbm90 IG1lbnRpb24gYW55dGhpbmcgYWJvdXQgTlYtc3RvcmFnZS4NCk9yIG1heWJlIHRoZSAibnYtc3Rv cmUiIGZsYWcgc2hvdWxkIGJlIGEgaGludCwgYnV0IHRoZSBzZXJ2ZXIgY2FuIGlnbm9yZSANCml0 Lg0KDQpORVRDT05GIGhhcyBubyBOVi1zdG9yYWdlIHJlcXVpcmVtZW50IGF0IGFsbCBhbmQgdGhh dCBoYXMgbm90DQpwcmV2ZW50ZWQgc2VydmVycyBmcm9tIGJvb3Rpbmcgd2l0aCB0aGUgcHJldmlv dXMgY29uZmlndXJhdGlvbi4NClRoZSBtYXJrZXQgY2FuIGRlY2lkZSBob3cgZmFzdCBpcyBmYXN0 IGVub3VnaC4gVGhlIG1hcmtldCBjYW4NCmRlY2lkZSB0aGF0IGEgY29uZmlndXJhdGlvbiBtYW5h Z2VtZW50IHN5c3RlbSB0aGF0IG9ubHkgd29ya3MNCnVudGlsIHRoZSBuZXh0IHJlYm9vdCBpcyBu b3QgT0suDQoNCj4gTGFkYQ0KPg0KDQpBbmR5DQoNCj4+IE5FVENPTkYgaXMgdGhlIG9uZSB0aGF0 IGlzIG5vdCB2ZXJ5IGNsZWFyIGJlY2F1c2UgaXQgc2F5cyBub3RoaW5nDQo+PiBhYm91dCBOVi1z dG9yYWdlIGV4Y2VwdCBmb3Igc29tZSB2ZXJ5IHNwZWNpZmljIHRleHQgYWJvdXQNCj4+IHRoZSBz dGFydHVwIGRhdGFzdG9yZS4gIElmIDpzdGFydHVwIGlzIG5vdCBzdXBwb3J0ZWQsIHRoZXJlIGlz IG5vDQo+PiBOViBzdG9yYWdlIHJlcXVpcmVtZW50IGF0IGFsbC4NCj4+DQo+PiBJbiBSRVNUQ09O RiB0aGVyZSBpcyBhbiBOViBzdG9yYWdlIHJlcXVpcmVtZW50LCB3aGljaCBpcyBjb21wYXRpYmxl DQo+PiB3aXRoIE5FVENPTkYuICBSRVNUQ09ORiBkb2VzIHRoZSBlZGl0IHByb2NlZHVyZSBpbiAx IHN0ZXAuDQo+PiBUaGlzIGdvZXMgZm9yIGNhbmRpZGF0ZSBvciBzdGFydHVwLiAgRXZlbiBpZiB0 aGUgc2VydmVyIHN1cHBvcnRzDQo+PiA6Y2FuZGlkYXRlLCB0aGUgY2xpZW50IGRvZXMgbm90IGRv IGEgMi1zdGVwIGVkaXQrY29tbWl0IGxpa2UgTkVUQ09ORi4NCj4+DQo+Pg0KPj4+IC9qcw0KPj4N Cj4+IEFuZHkNCj4+DQo+Pj4NCj4+PiAtLQ0KPj4+IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAg ICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQo+Pj4gUGhvbmU6ICs0OSA0MjEg MjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0K Pj4+IEZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHA6Ly93d3cuamFjb2JzLXVu aXZlcnNpdHkuZGUvPg0KPg0KPiAtLQ0KPiBMYWRpc2xhdiBMaG90a2EsIENaLk5JQyBMYWJzDQo+ IFBHUCBLZXkgSUQ6IEU3NEU4QzBDDQo+DQo+DQo+DQo+DQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpOZXRjb25mIG1haWxpbmcgbGlzdA0KTmV0Y29u ZkBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25m DQoNCg0K --=_alternative 0068244386257E61_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlBlcnNvbmFsbHksIEkgcmVhbGx5IGxpa2Ug dGhlIGZhY3QgdGhhdA0KUkVTVENPTkYgc3BlY2lmaWVzIHRoZSBOViBzdG9yYWdlIHJlcXVpcmVt ZW50LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+U29t ZSBhcHBsaWNhdGlvbnMgcmVxdWlyZSBOViBzdG9yYWdlDQphcyBhIGJhc2VsaW5lIGFzc3VtcHRp b24uIElmIHdlIGxlYXZlIE5WIHN0b3JhZ2UgdW5zcGVjaWZpZWQgaW4gUkVTVENPTkYsDQp0aGF0 IGJyaW5ncyB0aGUgcmlzayB0aGF0IGRpZmZlcmVudCBhcHBsaWNhdGlvbnMgbXVzdCBzcGVjaWZ5 IHRoZWlyIG93bg0KTlYgcmVxdWlyZW1lbnRzIG91dHNpZGUgb2YgUkVTVENPTkYuIFRoZSBtYXJr ZXQgbWF5IHB1bGwgdGhpcyBpc3N1ZSBpbg0KZGlmZmVyZW50IGRpcmVjdGlvbnMuPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JIHRlbmQgdG8gdGhpbmsg b2YgdGhlIFJFU1RDT05GIHNlY3Rpb24NCjMuNCBhcyBjbGVhciwgaW4gdGhhdCBpdCBpbXBsaWVz IHRoYXQgdGhlIHNhdmUgdG8gTlYgc3RvcmFnZSBvY2N1cnMgcHJpb3INCnRvIHRoZSByZXNwb25z ZSB0byBQQVRDSC4gSWYgc29tZSBhcmUgY29uY2VybmVkIHRoYXQgdGhpcyBpcyBub3Qgc3VmZmlj aWVudGx5DQpjbGVhciwgd2UgY291bGQgcG9zc2libHkgY2hhbmdlIHRoZSB0ZXh0IHRvIHN0YXRl IHRoaXMgZXhwbGljaXRseS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPklmIGEgZ2l2ZW4gaW1wbGVtZW50YXRpb24gZG9lcyBub3Qgd2FudA0KdG8gc2F2 ZSB0byBOViBzdG9yYWdlIG9uIGVhY2ggZWRpdCwgSSB3b3VsZCBhcmd1ZSB0aGF0IE5FVENPTkYg aXMgdGhlIGJlc3QNCmFsdGVybmF0aXZlLiBJIGRvbid0IHRoaW5rIHdlIHNob3VsZCBhZGQgZXZl cnkgZmVhdHVyZSBmcm9tIE5FVENPTkYgaW50bw0KUkVTVENPTkYuPC9mb250Pg0KPGJyPg0KPGJy Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZhY2U9InNhbnMtc2VyaWYi PkZyb206ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPkFuZHkgQmllcm1hbiAmbHQ7YW5keUB5dW1hd29ya3MuY29tJmd0Ozwv Zm9udD4NCjxicj48Zm9udCBzaXplPTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj5U bzogJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+TGFkaXNsYXYgTGhvdGthICZsdDtsaG90a2FAbmljLmN6Jmd0OywNCjwvZm9u dD4NCjxicj48Zm9udCBzaXplPTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj5DYzog Jm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+TmV0Y29uZiAmbHQ7bmV0Y29uZkBpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+RGF0ZTogJm5ic3A7ICZu YnNwOyAmbmJzcDsNCiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ MDYvMTAvMjAxNSAwMzoxMyBQTTwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgY29sb3I9IzVmNWY1 ZiBmYWNlPSJzYW5zLXNlcmlmIj5TdWJqZWN0OiAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7 PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SZTogW05ldGNvbmZdDQpZQU5H IFBhdGNoIElzc3VlICMzOiA6ZGlzdGluY3Qtc3RhcnR1cDwvZm9udD4NCjxicj48Zm9udCBzaXpl PTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj5TZW50IGJ5OiAmbmJzcDsgJm5ic3A7 DQombmJzcDsgJm5ic3A7PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVv dDtOZXRjb25mJnF1b3Q7DQombHQ7bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnJmd0OzwvZm9udD4N Cjxicj4NCjxociBub3NoYWRlPg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+T24g V2VkLCBKdW4gMTAsIDIwMTUgYXQgMTowOSBQTSwgTGFkaXNsYXYgTGhvdGthICZsdDtsaG90a2FA bmljLmN6Jmd0Ow0Kd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsmZ3Q7IE9uIDEwIEp1biAyMDE1 LCBhdCAxNjozNiwgQW5keSBCaWVybWFuICZsdDthbmR5QHl1bWF3b3Jrcy5jb20mZ3Q7DQp3cm90 ZTo8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IE9uIFdlZCwgSnVuIDEwLCAyMDE1IGF0IDU6 NDggQU0sIEp1ZXJnZW4gU2Nob2Vud2FlbGRlcjxicj4NCiZndDsmZ3Q7ICZsdDtqLnNjaG9lbndh ZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUmZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7Jmd0OyBP biBXZWQsIEp1biAxMCwgMjAxNSBhdCAwMjoxNDo1M1BNICswMjAwLCBMYWRpc2xhdiBMaG90a2EN Cndyb3RlOjxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IElmIHBl cnNpc3RlbmNlIG1lYW5zIHRoYXQgY29uZmlnIGRhdGEgc3Vydml2ZSBhIGNsZWFuDQpzaHV0ZG93 biwgdGhlbjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgbXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IHRo ZSB1bmlmaWVkIGRhdGFzdG9yZSBpcyBwZXJzaXN0ZW50Lg0KSXQ8YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7IGRvZXNu4oCZdCBuZWNlc3NhcmlseSBtZWFuIHN5bmNocm9ub3VzIHdyaXRlcyBvZiBldmVy eQ0KZWRpdCB0aG91Z2guPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IEFnYWlu LCBhbGwgSSBhbSBzYXlpbmcgaXQgbmVlZHMgdG8gYmUgY3J5c3RhbCBjbGVhciB3aGF0IHRoZQ0K dG8gYmU8YnI+DQomZ3Q7Jmd0OyZndDsgZXhwZWN0ZWQgYmVoYXZpb3VyIGlzLiBZb3UgYXJlIGJy aW5naW5nIHVwIGFub3RoZXIgb3B0aW9uDQotIGZpbmUuIFdoYXQ8YnI+DQomZ3Q7Jmd0OyZndDsg SSBkbyBub3Qgd2FudCBpcyB0aGF0IGV2ZXJ5IGltcGxlbWVudGF0aW9uIGNhbiBwaWNrIGl0cyBv d24NCmNob2ljZS48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 IFRoZSBkcmFmdCBpcyBjbGVhciAtLSB0aGUgc2VydmVyIHNhdmVzIHRvIE5WLXN0b3JlIGFmdGVy IGV2ZXJ5DQplZGl0Ljxicj4NCiZndDs8YnI+DQomZ3Q7IFllcywgYnV0IGhvdyBpdCBpcyBkb25l IGlzIGFuIOKAnGltcGxlbWVudGF0aW9uLXNwZWNpZmljIG1hdHRlcuKAnS4NClRoaXMgbWF5IGFs c28gbWVhbiBpdCBpcyBhIGRlbGF5ZWQgd3JpdGUuIEkgdGhpbmsgdGhlIHByb3RvY29sIHNwZWNp ZmljYXRpb24NCnNob3VsZG7igJl0IGJlIHRvbyBzcGVjaWZpYyBoZXJlLCBpdCBzaG91bGQgc3Vm ZmljZSB0byBzYXkgdGhhdCBpdCBpcyBleHBlY3RlZA0KdGhlIGNvbmZpZ3VyYXRpb24gd29u4oCZ dCBkaXNhcHBlYXIgd2l0aCBhIGRldmljZSByZWJvb3QuPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhl c2UgZGF5cywgd2l0aCBhbGwgdGhlIHZpcnR1YWxpemF0aW9uIG9wdGlvbnMsIGNsb3VkIHN0b3Jh Z2UgZXRjLiwNCml0IGlzIGhhcmQgdG8gZGVmaW5lIHdoYXQgbm9uLXZvbGF0aWxlIHN0b3JhZ2Ug aXMuPGJyPg0KJmd0Ozxicj4NCjxicj4NCk1heWJlIFJFU1RDT05GIHNob3VsZCBub3QgbWVudGlv biBhbnl0aGluZyBhYm91dCBOVi1zdG9yYWdlLjxicj4NCk9yIG1heWJlIHRoZSAmcXVvdDtudi1z dG9yZSZxdW90OyBmbGFnIHNob3VsZCBiZSBhIGhpbnQsIGJ1dCB0aGUgc2VydmVyDQpjYW4gaWdu b3JlIGl0Ljxicj4NCjxicj4NCk5FVENPTkYgaGFzIG5vIE5WLXN0b3JhZ2UgcmVxdWlyZW1lbnQg YXQgYWxsIGFuZCB0aGF0IGhhcyBub3Q8YnI+DQpwcmV2ZW50ZWQgc2VydmVycyBmcm9tIGJvb3Rp bmcgd2l0aCB0aGUgcHJldmlvdXMgY29uZmlndXJhdGlvbi48YnI+DQpUaGUgbWFya2V0IGNhbiBk ZWNpZGUgaG93IGZhc3QgaXMgZmFzdCBlbm91Z2guIFRoZSBtYXJrZXQgY2FuPGJyPg0KZGVjaWRl IHRoYXQgYSBjb25maWd1cmF0aW9uIG1hbmFnZW1lbnQgc3lzdGVtIHRoYXQgb25seSB3b3Jrczxi cj4NCnVudGlsIHRoZSBuZXh0IHJlYm9vdCBpcyBub3QgT0suPGJyPg0KPGJyPg0KJmd0OyBMYWRh PGJyPg0KJmd0Ozxicj4NCjxicj4NCkFuZHk8YnI+DQo8YnI+DQomZ3Q7Jmd0OyBORVRDT05GIGlz IHRoZSBvbmUgdGhhdCBpcyBub3QgdmVyeSBjbGVhciBiZWNhdXNlIGl0IHNheXMgbm90aGluZzxi cj4NCiZndDsmZ3Q7IGFib3V0IE5WLXN0b3JhZ2UgZXhjZXB0IGZvciBzb21lIHZlcnkgc3BlY2lm aWMgdGV4dCBhYm91dDxicj4NCiZndDsmZ3Q7IHRoZSBzdGFydHVwIGRhdGFzdG9yZS4gJm5ic3A7 SWYgOnN0YXJ0dXAgaXMgbm90IHN1cHBvcnRlZCwgdGhlcmUNCmlzIG5vPGJyPg0KJmd0OyZndDsg TlYgc3RvcmFnZSByZXF1aXJlbWVudCBhdCBhbGwuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyBJbiBSRVNUQ09ORiB0aGVyZSBpcyBhbiBOViBzdG9yYWdlIHJlcXVpcmVtZW50LCB3aGljaCBp cyBjb21wYXRpYmxlPGJyPg0KJmd0OyZndDsgd2l0aCBORVRDT05GLiAmbmJzcDtSRVNUQ09ORiBk b2VzIHRoZSBlZGl0IHByb2NlZHVyZSBpbiAxIHN0ZXAuPGJyPg0KJmd0OyZndDsgVGhpcyBnb2Vz IGZvciBjYW5kaWRhdGUgb3Igc3RhcnR1cC4gJm5ic3A7RXZlbiBpZiB0aGUgc2VydmVyIHN1cHBv cnRzPGJyPg0KJmd0OyZndDsgOmNhbmRpZGF0ZSwgdGhlIGNsaWVudCBkb2VzIG5vdCBkbyBhIDIt c3RlcCBlZGl0K2NvbW1pdCBsaWtlIE5FVENPTkYuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7Jmd0OyAvanM8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEFuZHk8 YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyAtLTxicj4N CiZndDsmZ3Q7Jmd0OyBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBKYWNvYnMNClVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIPGJyPg0KJmd0OyZn dDsmZ3Q7IFBob25lOiArNDkgNDIxIDIwMCAzNTg3ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBDYW1wdXMNClJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnk8YnI+DQomZ3Q7Jmd0OyZn dDsgRmF4OiAmbmJzcDsgKzQ5IDQyMSAyMDAgMzEwMyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJmx0OzwvZm9udD48L3R0PjxhIGhyZWY9Imh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHku ZGUvIj48dHQ+PGZvbnQgc2l6ZT0yPmh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPC9m b250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+Jmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IC0t PGJyPg0KJmd0OyBMYWRpc2xhdiBMaG90a2EsIENaLk5JQyBMYWJzPGJyPg0KJmd0OyBQR1AgS2V5 IElEOiBFNzRFOEMwQzxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+ DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCk5ldGNvbmYgbWFpbGluZyBsaXN0PGJyPg0KTmV0Y29uZkBpZXRmLm9yZzxicj4NCjwvZm9u dD48L3R0PjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRj b25mPjx0dD48Zm9udCBzaXplPTI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRjb25mPC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KPC9mb250Pjwv dHQ+DQo8YnI+DQo= --=_alternative 0068244386257E61_=-- From nobody Fri Jun 12 13:55:48 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0031B2A9B for ; Fri, 12 Jun 2015 13:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ij8D3j3zg5tI for ; Fri, 12 Jun 2015 13:55:44 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0106.outbound.protection.outlook.com [65.55.169.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09EBF1B2A98 for ; Fri, 12 Jun 2015 13:55:43 -0700 (PDT) Received: from CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) by CO1PR05MB410.namprd05.prod.outlook.com (10.141.74.151) with Microsoft SMTP Server (TLS) id 15.1.190.14; Fri, 12 Jun 2015 20:55:42 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.190.14; Fri, 12 Jun 2015 20:55:41 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.121]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.121]) with mapi id 15.01.0184.014; Fri, 12 Jun 2015 20:55:41 +0000 From: Kent Watsen To: Jonathan Hansford , t.petch , Alan Luchuk , "netconf@ietf.org" Thread-Topic: [Netconf] draft-ietf-netconf-call-home-05.txt Thread-Index: AQHQlMnODg1iNSV/nEqfYnzAyUNFnZ2R9YQAgAk0BUX//82dgIAJHwuFgAB4uYCAAPoAAIADrriA Date: Fri, 12 Jun 2015 20:55:41 +0000 Message-ID: References: <80301e1e1232317992099edfe168d2936a6f9d1a@webmail.hansfords.net> In-Reply-To: <80301e1e1232317992099edfe168d2936a6f9d1a@webmail.hansfords.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: hansfords.net; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.11] x-microsoft-exchange-diagnostics: 1; CO1PR05MB459; 3:xpYDkSyMT5xKY/EEp7uTqfWThn2iQwsRyY1DKAJLcsHuNzmso/YxtvlAoyFH9TSlZcP2t4xO4kekwV2dsmc5iFZmmwnitAOTvQ1S9ZZQtK2cWq56O2evk64KNvbX2DzeXO5ifsgganmZTqXVPYWiTQ==; 10:VceRTWeEg7vJsQguieDHPoADNnp9uXGyBvzBmwpqefCYWpE7kwc5vQOYHH50eDOfjLvYc9x8o1/ZNGWKoSCLqvaAs4IyI3b1XhjmiISZPsA=; 6:q13Odbg1wnh2XSbDZwv82LhZI7f42JLt9hQea6l6Cfjaz1hvYnz1hbgjJdvp7u/b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB410; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520003)(3002001); SRVR:CO1PR05MB459; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; x-forefront-prvs: 060503E79B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(164054003)(51704005)(13464003)(19580395003)(106116001)(2656002)(16236675004)(2900100001)(99286002)(62966003)(77156002)(230783001)(5001770100001)(19580405001)(87936001)(5002640100001)(5001960100002)(107886002)(14971765001)(122556002)(2950100001)(15975445007)(102836002)(92566002)(40100003)(2501003)(46102003)(66066001)(189998001)(19617315012)(5001920100001)(36756003)(86362001)(76176999)(54356999)(50986999)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_D1A0BD8EAEB2Dkwatsenjunipernet_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2015 20:55:41.1737 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459 X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB410; 2:em96jHka8zjRLNbdDzILdhujRuVF8iNxyTt1tyOPQTH1H9HhQlGQep/snPgHmh2J; 2:dVpoIhXmPu8njNt3r3K/ESsI34oUc3XakP5fd7p1K4Ug80g9cBZFotWMpsvepaXuXZ9+czeQQVxUsr9l1n5BoMXjaSm9OSbjF+haT2sjRzUQxrowPAfBmqQhh8J4YzqQmrDbTy7AMgyFpA6BooXyLA==; 9:u3g4Wzvg8VItpnmK9BSx4PK2bKcgAwW4cR5zPiI88eBXVCG9wxcrFpq7yuUblY7852231X7zLkDDhm0n0jU1gTug9lUThZK5UJDjtZjgmQwvXu3fJIwoDmjssY3dWIu+qYjHeIJW5iBODSwLKu9Shw== X-OriginatorOrg: juniper.net Archived-At: Subject: Re: [Netconf] draft-ietf-netconf-call-home-05.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 20:55:47 -0000 --_000_D1A0BD8EAEB2Dkwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jonathan, I went with your first sentence, with a minor tweak. I left out your secon= d sentence, since it seemed unnecessary the more I looked at it (hopefully = you agree!). Here is where we are at now: S4 As part of establishing the SSH or TLS connection, the NETCONF/ RESTCONF server will send its host key or certificate to the client. If a certificate is sent, the server MUST also send all intermediate certificates leading up to the certificate's trust anchor. How to send a list of certificates is defined for SSH in [RFC6187] Section 2.1, and for TLS in [RFC5246] Section 7.4.2. You like? Thanks, Kent From: Jonathan Hansford > Date: Wednesday, June 10, 2015 at 4:41 AM To: Kent Watsen >, "t.petch= " >, Alan Luchuk >, "netconf@ietf.org= " > Subject: Re: [Netconf] draft-ietf-netconf-call-home-05.txt Hi Kent, Re S4, the resulting sentence feels a little clumsy and the intent is not t= hat clear to me. Presumably the intent is that "the server MUST send any in= termediate certificates the client will use to authenticate the server's ce= rtificate" and the "leading up to the trust anchor" is provided as context.= Should it not also be "all" rather than "any"? How about: If a certificate is sent, the server MUST also send all intermediate certificates leading up to the trust anchor. These will be used by the clie= nt to authenticate the server's certificate. Jonathan ----- Original Message ----- From: "Kent Watsen" > To: "t.petch" >, "Alan Luchuk" = >, "netconf@ietf.org" > Cc: Sent: Tue, 9 Jun 2015 21:46:45 +0000 Subject: Re: [Netconf] draft-ietf-netconf-call-home-05.txt Hi Tom, >>No new split infinitives? ;) > >No but there might be the avoidance thereof in S4 >"the server MUST also send any intermediate certificates leading up to >the trust anchor the clients are expected use to authenticate it. " Good catch, this is what I have now: If a certificate is sent, the server MUST also send any intermediate certificates leading up to the trust anchor the client will use to authenticate the server's certificate with. OK? >And in s.4, " This reversal is incongruous with [RFC4253], ", I wonder >if incongruent is intended. Searching "incongruous vs incongruent" returns a surprising number of responses. It seems that this is a common question! My reading is that "incongruous" is the better option here, so I plan to leave it as it is. >One issue from earlier is what methods of authentication are acceptable. >5539bis now says X.509 certificate, RFC6242 is silent; I don't know >where Restconf is heading. This I-D sort of implies that servers will >only offer certificates or host keys, in which case I would like to see >that made explicit. True, RFC6242 is silent, for which I'm happy as it extends it to support RFC 6187. RESTCONF, like 5539bis, is also exclusively X.509: https://tools.ietf.org/html/draft-ietf-netconf-restconf-05#section-2.2. I'm not sure what to do about your last comment - any concrete suggestions? It is relatively easy to lock TLS to X.509, but SSH is all over the map. SSH calls it a "host key" (RFC 4251, Section-4.1), and host keys correspond to public key algorithms (RFC 4253, Section 7.1), and there are a number of algorithms (http://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-pa rameters-19), some using certificates (e.g., RFC 6187). So an SSH host key can be a certificate too... >On client authentication by servers, we seem not to require it. I have >read and re-read >"3. The NETCONF or RESTCONF Server >3.1. Protocol Operation " >and can see no mention thereof. We have this on the client side: C7 After the server's host key or certificate is validated, the SSH or TLS protocol proceeds as normal to establish a SSH or TLS connection. Where "proceeds as normal" is intended to include the client authentication step. The closest equivalent on the server side is in the beginning go S5: S5 Once the SSH or TLS connection is established, the ... Where it's only tangentially implied. Complicating matters, client auth in RESTCONF only occurs in the secure transport when using the ClientCertificate authentication scheme. When using either the Basic or Digest authentication schemes, authentication occurs post-TLS in the HTTP layer. So implying client authentication always occurs as part of TLS connection establishment is not entirely accurate. This is why I was trying to hide all the client authentication steps behind the "proceeds as normal" clause and similar clauses in C8 and S5 regarding starting the NETCONF/RESTCONF protocols. I'm weary of this exploding into a lot of text. Can you suggest a simple fix? Thanks, Kent _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --_000_D1A0BD8EAEB2Dkwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <92FBB1D664BB8B4BAAAEBBC7CE1E5264@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi Jonathan,

I went with your first sentence, wit= h a minor tweak.  I = ;left out your second sentence, since it seemed unnecessary the more I= looked at it (hopefully you agree!).  Here is where we are at now:

   S4  As part of est= ablishing the SSH or TLS connection, the NETCONF/
        RESTCONF= server will send its host key or certificate to the
        client. =  If a certificate is sent, the server MUST also send all
        intermed= iate certificates leading up to the certificate's trust
        anchor. =  How to send a list of certificates is defined for SSH in
        [RFC6187= ] Section 2.1, and for TLS in [RFC5246] Section 7.4.2.

You like?

Thanks,
Kent

From: Jonathan Hansford <jonathan@hansfords.net>
Date: Wednesday, June 10, 2015 at 4= :41 AM
To: Kent Watsen <kwatsen@juniper.net>, "t.petch" &l= t;ietfc@btconnect.com>, Alan = Luchuk <luchuk@snmp.com>, "netconf@ietf.org" <<= a href=3D"mailto:netconf@ietf.org">netconf@ietf.org>
Subject: Re: [Netconf] draft-ietf-n= etconf-call-home-05.txt

Hi Kent,

Re S4, the resulting sentence feels a little clumsy and the intent is not t= hat clear to me. Presumably the intent is that "the server MUST send a= ny intermediate certificates the client will use to authenticate the server= 's certificate" and the "leading up to the trust anchor" is provided as context. Should it not also be "= ;all" rather than "any"? How about:

If a certificate is sent, the server MUST also send all intermediate certificates leading up to the trust anchor. These will be used by the clie= nt to
authenticate the server's certificate.

Jonathan

----- Original Message -----
From:
"Kent Watsen" <kwatsen@= juniper.net>

To:
"t.petch" <ietfc@btconn= ect.com>, "Alan Luchuk" <luchuk@snmp.com>, "net= conf@ietf.org" <netconf@iet= f.org>
Cc:

Sent:
Tue, 9 Jun 2015 21:46:45 +0000
Subject:
Re: [Netconf] draft-ietf-netconf-call-home-05.txt


Hi Tom,


>>No new split infinitives? ;)
>
>No but there might be the avoidance thereof in S4
>"the server MUST also send any intermediate certificates leading u= p to
>the trust anchor the clients are expected use to authenticate it. "= ;

Good catch, this is what I have now:

If a certificate is sent, the server MUST also send any intermediate
certificates leading up to the trust anchor the client will use to
authenticate the server's certificate with.

OK?




>And in s.4, " This reversal is incongruous with [RFC4253], ",= I wonder
>if incongruent is intended.

Searching "incongruous vs incongruent" returns a surprising numbe= r of
responses. It seems that this is a common question! My reading is that
"incongruous" is the better option here, so I plan to leave it as= it is.



>One issue from earlier is what methods of authentication are acceptable= .
>5539bis now says X.509 certificate, RFC6242 is silent; I don't know
>where Restconf is heading. This I-D sort of implies that servers will >only offer certificates or host keys, in which case I would like to see=
>that made explicit.

True, RFC6242 is silent, for which I'm happy as it extends it to support RFC 6187. RESTCONF, like 5539bis, is also exclusively X.509:
https://tools.ietf.org/html/draft-ietf-netconf-restconf-05#section-= 2.2.
I'm not sure what to do about your last comment - any concrete suggestions?=

It is relatively easy to lock TLS to X.509, but SSH is all over the map. SSH calls it a "host key" (RFC 4251, Section-4.1), and host keys<= br> correspond to public key algorithms (RFC 4253, Section 7.1), and there are<= br> a number of algorithms
(http://www.iana.org/assignments/ssh-parameters/ssh-parameters.= xhtml#ssh-pa
rameters-19), some using certificates (e.g., RFC 6187). So an SSH host
key can be a certificate too...



>On client authentication by servers, we seem not to require it. I have<= br> >read and re-read
>"3. The NETCONF or RESTCONF Server
>3.1. Protocol Operation "
>and can see no mention thereof.

We have this on the client side:

C7 After the server's host key or certificate is validated, the SSH
or TLS protocol proceeds as normal to establish a SSH or TLS
connection.


Where "proceeds as normal" is intended to include the client
authentication step. The closest equivalent on the server side is in the beginning go S5:

S5 Once the SSH or TLS connection is established, the ...


Where it's only tangentially implied.

Complicating matters, client auth in RESTCONF only occurs in the secure
transport when using the ClientCertificate authentication scheme. When
using either the Basic or Digest authentication schemes, authentication
occurs post-TLS in the HTTP layer. So implying client authentication
always occurs as part of TLS connection establishment is not entirely
accurate.

This is why I was trying to hide all the client authentication steps
behind the "proceeds as normal" clause and similar clauses in C8 = and S5
regarding starting the NETCONF/RESTCONF protocols. I'm weary of this
exploding into a lot of text. Can you suggest a simple fix?



Thanks,
Kent

_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.= org/mailman/listinfo/netconf
 --_000_D1A0BD8EAEB2Dkwatsenjunipernet_-- From nobody Fri Jun 12 13:57:48 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC6CD1B2AA0 for ; Fri, 12 Jun 2015 13:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0a5orxe0nPG for ; Fri, 12 Jun 2015 13:57:45 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0130.outbound.protection.outlook.com [65.55.169.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03F7B1B2AA2 for ; Fri, 12 Jun 2015 13:57:42 -0700 (PDT) Received: from CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) by CO1PR05MB508.namprd05.prod.outlook.com (10.141.71.153) with Microsoft SMTP Server (TLS) id 15.1.190.14; Fri, 12 Jun 2015 20:57:39 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.190.14; Fri, 12 Jun 2015 20:57:39 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.121]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.121]) with mapi id 15.01.0184.014; Fri, 12 Jun 2015 20:57:39 +0000 From: Kent Watsen To: t.petch , Alan Luchuk , "netconf@ietf.org" Thread-Topic: [Netconf] draft-ietf-netconf-call-home-05.txt Thread-Index: AQHQlMnODg1iNSV/nEqfYnzAyUNFnZ2R9YQAgAk0BUX//82dgIAJHwuFgAB4uYCAAp6qDYACCp+A Date: Fri, 12 Jun 2015 20:57:39 +0000 Message-ID: References: <201505221959.t4MJxRHR081289@mainfs.snmp.com> <201506031817.t53IHJit066848@mainfs.snmp.com> <026301d0a29f$852a8340$4001a8c0@gateway.2wire.net> <02fb01d0a42b$33b519c0$4001a8c0@gateway.2wire.net> In-Reply-To: <02fb01d0a42b$33b519c0$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: btconnect.com; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.11] x-microsoft-exchange-diagnostics: 1; CO1PR05MB459; 3:sgDzBJnihgD8HqHz4Q51kRDi4p4WBXYriBfKPe/eX/7fxNHpqHHa6vm/lOQwq847HiAOUMNNdM+BItHlUNwO7V9T26dOE5bVem2OZ0YIxro1og2h8YNPfTLOvbHWFVHpwoCILMy0EqiuLUHPoMwedw==; 10:a8oyKqJZRmm+dkpvVMA6GBbAk9chX53DmOlCi5GyQ2MkbgYvfyuvtLniAz6Lk63fywHPYGAEnNnOSvNvWNuZnB8l+B7+HSlJ/PrrDT+wnA4=; 6:5mFZyJ8sWzL5EQLop8dA7V7roZ2suNbvp6BnkAtCVvk8UcoZNYCOqDliaP6wvy+t x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB508; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520003)(3002001); SRVR:CO1PR05MB459; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; x-forefront-prvs: 060503E79B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(51704005)(76104003)(106116001)(2656002)(2900100001)(99286002)(62966003)(77156002)(230783001)(5001770100001)(87936001)(5002640100001)(5001960100002)(107886002)(122556002)(93886004)(2950100001)(102836002)(92566002)(40100003)(2501003)(46102003)(66066001)(189998001)(5001920100001)(36756003)(86362001)(76176999)(54356999)(50986999)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <92C5065CDC621E45B25AE3A4E8B1AD2C@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2015 20:57:39.3571 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459 X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB508; 2:kl/emGcTKAaqgbwHj2YaB2TXR2Q0vmTH/yB2oSqo0QIKYtwdYhrJAAvv3yfQ3Dgh; 2:3/5dqz6l5+vD9lyWBbAJjH+FpaFOV6jfxxe4PmlqfKCvifUTPFGvhZg71sEhncNRKmnBigOIwsxuwToPSFuWHeH/Zg/vqKsvd9u1DySpTdeuPT3PCfGASzFn/G12vv+mlDGB/hCem7e7iGstPMyTyw==; 9:BrRABxBH3pkZwJqUDgH4NUWBpEq0alD+TeZcAFkGGeEZnJc3DDxeMwp50PuLnNaZnz5/9gh/jmCztqQcZdCy36sb/0TO/luwRFEvBZex04GkjWjTG8juFjpBoL97XhQAXtk3rvpFV80iwMCYBQwFmw== X-OriginatorOrg: juniper.net Archived-At: Subject: Re: [Netconf] draft-ietf-netconf-call-home-05.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 20:57:46 -0000 Hi Tom, > >yes but I think worth making explicit, saying something along the lines >that that for TLS, the scope of authentication is the same as for >5539bis, namely X.509 certificates while for SSH, any method defined for >SSH will do. The current text sort of implies a greater restriction and >it is that that I wanted to clarify. I tried inserting some text into the Introduction, but there wasn't an easy way to do it. So I rather ask, where are you picking up this greater restriction in the text? >>On client authentication by servers, we seem not to require it. I added this new section: S5 In most cases, establishing the SSH or TLS connection also entails server authentication of client credentials; only with RESTCONF do some client authentication schemes occur after the secure transport connection (TLS) has been established. If client authentication is required, and the client is unable to successfully authenticate itself to the server in an amount of time defined by local policy, the server SHOULD close the connection. What do you think? I disagree that client auth seems not required, in that it's required by the draft's normative references: 1. RFC 6241 says "NETCONF connections MUST be authenticated. The transport protocol is responsible for authentication of the server to the client and authentication of the client to the server." 2. RFC6242 says: "The identity of the SSH client MUST also be verified and authenticated ..." 3. 5539bis says "The NETCONF server MUST verify the identity of the NETCONF client ..." 4. restconf-07 says "The RESTCONF server MUST authenticate client access ..." I'm hoping that the new S5 and the normative references address your concern - do they? Thanks, Kent From nobody Sat Jun 13 02:31:50 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2081B2F8C for ; Sat, 13 Jun 2015 02:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzQFxeU27C8w for ; Sat, 13 Jun 2015 02:31:46 -0700 (PDT) Received: from mailscan1.extendcp.co.uk (mailscan28.extendcp.co.uk [176.32.228.2]) (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 A7AE91B2F89 for ; Sat, 13 Jun 2015 02:31:45 -0700 (PDT) Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mailscan1.hi.local) by mailscan-g72.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1Z3hmu-0006dd-T2; Sat, 13 Jun 2015 10:31:40 +0100 Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mail149.extendcp.co.uk) by mailscan1.hi.local with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1Z3hmt-0006aI-Cl; Sat, 13 Jun 2015 10:31:41 +0100 Received: from hansfords.plus.com ([84.92.116.209] helo=[192.168.1.24]) by mail149.extendcp.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) id 1Z3hmo-00023W-M1; Sat, 13 Jun 2015 10:31:34 +0100 Content-Type: multipart/alternative; boundary=Apple-Mail-81E1E63B-E58D-4EBB-8166-D6E8F721ADC3 Mime-Version: 1.0 (1.0) From: Jonathan Hansford X-Mailer: iPad Mail (12F69) In-Reply-To: Date: Sat, 13 Jun 2015 10:31:25 +0100 Content-Transfer-Encoding: 7bit Message-Id: <4AB71C40-D51B-4242-933B-CA32F62E3517@hansfords.net> References: <80301e1e1232317992099edfe168d2936a6f9d1a@webmail.hansfords.net> To: Kent Watsen X-Authenticated-As: jonathan@hansfords.net X-Extend-Src: mailout Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] draft-ietf-netconf-call-home-05.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2015 09:31:49 -0000 --Apple-Mail-81E1E63B-E58D-4EBB-8166-D6E8F721ADC3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Kent, Looks good to me. Jonathan > On 12 Jun 2015, at 21:55, Kent Watsen wrote: >=20 > Hi Jonathan, >=20 > I went with your first sentence, with a minor tweak. I left out your seco= nd sentence, since it seemed unnecessary the more I looked at it (hopefully y= ou agree!). Here is where we are at now: >=20 > S4 As part of establishing the SSH or TLS connection, the NETCONF/ > RESTCONF server will send its host key or certificate to the > client. If a certificate is sent, the server MUST also send all > intermediate certificates leading up to the certificate's trust > anchor. How to send a list of certificates is defined for SSH in > [RFC6187] Section 2.1, and for TLS in [RFC5246] Section 7.4.2. >=20 > You like? >=20 > Thanks, > Kent >=20 > From: Jonathan Hansford > Date: Wednesday, June 10, 2015 at 4:41 AM > To: Kent Watsen , "t.petch" , Al= an Luchuk , "netconf@ietf.org" > Subject: Re: [Netconf] draft-ietf-netconf-call-home-05.txt >=20 > Hi Kent, >=20 > Re S4, the resulting sentence feels a little clumsy and the intent is not t= hat clear to me. Presumably the intent is that "the server MUST send any int= ermediate certificates the client will use to authenticate the server's cert= ificate" and the "leading up to the trust anchor" is provided as context. Sh= ould it not also be "all" rather than "any"? How about: >=20 > If a certificate is sent, the server MUST also send all intermediate > certificates leading up to the trust anchor. These will be used by the cli= ent to > authenticate the server's certificate. >=20 > Jonathan >=20 > ----- Original Message ----- > From: > "Kent Watsen" >=20 > To: > "t.petch" , "Alan Luchuk" , "netconf= @ietf.org" > Cc: >=20 > Sent: > Tue, 9 Jun 2015 21:46:45 +0000 > Subject: > Re: [Netconf] draft-ietf-netconf-call-home-05.txt >=20 >=20 > Hi Tom, >=20 >=20 > >>No new split infinitives? ;) > > > >No but there might be the avoidance thereof in S4 > >"the server MUST also send any intermediate certificates leading up to > >the trust anchor the clients are expected use to authenticate it. " >=20 > Good catch, this is what I have now: >=20 > If a certificate is sent, the server MUST also send any intermediate > certificates leading up to the trust anchor the client will use to > authenticate the server's certificate with. >=20 > OK? >=20 >=20 >=20 >=20 > >And in s.4, " This reversal is incongruous with [RFC4253], ", I wonder > >if incongruent is intended. >=20 > Searching "incongruous vs incongruent" returns a surprising number of > responses. It seems that this is a common question! My reading is that > "incongruous" is the better option here, so I plan to leave it as it is. >=20 >=20 >=20 > >One issue from earlier is what methods of authentication are acceptable. > >5539bis now says X.509 certificate, RFC6242 is silent; I don't know > >where Restconf is heading. This I-D sort of implies that servers will > >only offer certificates or host keys, in which case I would like to see > >that made explicit. >=20 > True, RFC6242 is silent, for which I'm happy as it extends it to support > RFC 6187. RESTCONF, like 5539bis, is also exclusively X.509: > https://tools.ietf.org/html/draft-ietf-netconf-restconf-05#section-2.2. > I'm not sure what to do about your last comment - any concrete suggestions= ? >=20 > It is relatively easy to lock TLS to X.509, but SSH is all over the map. > SSH calls it a "host key" (RFC 4251, Section-4.1), and host keys > correspond to public key algorithms (RFC 4253, Section 7.1), and there are= > a number of algorithms > (http://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-p= a > rameters-19), some using certificates (e.g., RFC 6187). So an SSH host > key can be a certificate too... >=20 >=20 >=20 > >On client authentication by servers, we seem not to require it. I have > >read and re-read > >"3. The NETCONF or RESTCONF Server > >3.1. Protocol Operation " > >and can see no mention thereof. >=20 > We have this on the client side: >=20 > C7 After the server's host key or certificate is validated, the SSH > or TLS protocol proceeds as normal to establish a SSH or TLS > connection. >=20 >=20 > Where "proceeds as normal" is intended to include the client > authentication step. The closest equivalent on the server side is in the > beginning go S5: >=20 > S5 Once the SSH or TLS connection is established, the ... >=20 >=20 > Where it's only tangentially implied. >=20 > Complicating matters, client auth in RESTCONF only occurs in the secure > transport when using the ClientCertificate authentication scheme. When > using either the Basic or Digest authentication schemes, authentication > occurs post-TLS in the HTTP layer. So implying client authentication > always occurs as part of TLS connection establishment is not entirely > accurate.=20 >=20 > This is why I was trying to hide all the client authentication steps > behind the "proceeds as normal" clause and similar clauses in C8 and S5 > regarding starting the NETCONF/RESTCONF protocols. I'm weary of this > exploding into a lot of text. Can you suggest a simple fix? >=20 >=20 >=20 > Thanks, > Kent >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --Apple-Mail-81E1E63B-E58D-4EBB-8166-D6E8F721ADC3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Hi Kent,

Looks good to me.

Jonathan

On 12 Jun 2015, at 21:55, Kent Watsen <kwatsen@juniper.net> wrote:

Hi Jonathan,

I went with your first sentence, with a minor tweak.  I left out your second sentence, since it seemed unnecessary the more I looked at it (hopefully you agree!).  Here is where we are at now:

   S4  As part of establishing the SSH or TLS connection, the NETCONF/
        RESTCONF server will send its host key or certificate to the
        client.  If a certificate is sent, the server MUST also send all
        intermediate certificates leading up to the certificate's trust
        anchor.  How to send a list of certificates is defined for SSH in
        [RFC6187] Section 2.1, and for TLS in [RFC5246] Section 7.4.2.

You like?

Thanks,
Kent

From: Jonathan Hansford <jonathan@hansfords.net>
Date: Wednesday, June 10, 2015 at 4:41 AM
To: Kent Watsen <kwatsen@juniper.net>, "t.petch" <ietfc@btconnect.com>, Alan Luchuk <luchuk@snmp.com>, "netconf@ietf.org" <netconf@ietf.org>
Subject: Re: [Netconf] draft-ietf-netconf-call-home-05.txt

Hi Kent,

Re S4, the resulting sentence feels a little clumsy and the intent is not that clear to me. Presumably the intent is that "the server MUST send any intermediate certificates the client will use to authenticate the server's certificate" and the "leading up to the trust anchor" is provided as context. Should it not also be "all" rather than "any"? How about:

If a certificate is sent, the server MUST also send all intermediate
certificates leading up to the trust anchor. These will be used by the client to
authenticate the server's certificate.

Jonathan

----- Original Message -----
From:
"Kent Watsen" <kwatsen@juniper.net>

To:
"t.petch" <ietfc@btconnect.com>, "Alan Luchuk" <luchuk@snmp.com>, "netconf@ietf.org" <netconf@ietf.org>
Cc:

Sent:
Tue, 9 Jun 2015 21:46:45 +0000
Subject:
Re: [Netconf] draft-ietf-netconf-call-home-05.txt


Hi Tom,


>>No new split infinitives? ;)
>
>No but there might be the avoidance thereof in S4
>"the server MUST also send any intermediate certificates leading up to
>the trust anchor the clients are expected use to authenticate it. "

Good catch, this is what I have now:

If a certificate is sent, the server MUST also send any intermediate
certificates leading up to the trust anchor the client will use to
authenticate the server's certificate with.

OK?




>And in s.4, " This reversal is incongruous with [RFC4253], ", I wonder
>if incongruent is intended.

Searching "incongruous vs incongruent" returns a surprising number of
responses. It seems that this is a common question! My reading is that
"incongruous" is the better option here, so I plan to leave it as it is.



>One issue from earlier is what methods of authentication are acceptable.
>5539bis now says X.509 certificate, RFC6242 is silent; I don't know
>where Restconf is heading. This I-D sort of implies that servers will
>only offer certificates or host keys, in which case I would like to see
>that made explicit.

True, RFC6242 is silent, for which I'm happy as it extends it to support
RFC 6187. RESTCONF, like 5539bis, is also exclusively X.509:
https://tools.ietf.org/html/draft-ietf-netconf-restconf-05#section-2.2.
I'm not sure what to do about your last comment - any concrete suggestions?

It is relatively easy to lock TLS to X.509, but SSH is all over the map.
SSH calls it a "host key" (RFC 4251, Section-4.1), and host keys
correspond to public key algorithms (RFC 4253, Section 7.1), and there are
a number of algorithms
(http://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-pa
rameters-19), some using certificates (e.g., RFC 6187). So an SSH host
key can be a certificate too...



>On client authentication by servers, we seem not to require it. I have
>read and re-read
>"3. The NETCONF or RESTCONF Server
>3.1. Protocol Operation "
>and can see no mention thereof.

We have this on the client side:

C7 After the server's host key or certificate is validated, the SSH
or TLS protocol proceeds as normal to establish a SSH or TLS
connection.


Where "proceeds as normal" is intended to include the client
authentication step. The closest equivalent on the server side is in the
beginning go S5:

S5 Once the SSH or TLS connection is established, the ...


Where it's only tangentially implied.

Complicating matters, client auth in RESTCONF only occurs in the secure
transport when using the ClientCertificate authentication scheme. When
using either the Basic or Digest authentication schemes, authentication
occurs post-TLS in the HTTP layer. So implying client authentication
always occurs as part of TLS connection establishment is not entirely
accurate.

This is why I was trying to hide all the client authentication steps
behind the "proceeds as normal" clause and similar clauses in C8 and S5
regarding starting the NETCONF/RESTCONF protocols. I'm weary of this
exploding into a lot of text. Can you suggest a simple fix?



Thanks,
Kent

_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf
--Apple-Mail-81E1E63B-E58D-4EBB-8166-D6E8F721ADC3-- From nobody Sat Jun 13 04:57:24 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A41141B30BC for ; Sat, 13 Jun 2015 04:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6SnbuBac0iC for ; Sat, 13 Jun 2015 04:57:11 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0730.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0DC31B30BA for ; Sat, 13 Jun 2015 04:57:10 -0700 (PDT) Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none; Received: from pc6 (81.151.162.168) by AMSPR07MB049.eurprd07.prod.outlook.com (10.242.81.11) with Microsoft SMTP Server (TLS) id 15.1.190.14; Sat, 13 Jun 2015 11:56:47 +0000 Message-ID: <032d01d0a5cf$a8cd8940$4001a8c0@gateway.2wire.net> From: t.petch To: Kent Watsen , Alan Luchuk , References: <201505221959.t4MJxRHR081289@mainfs.snmp.com> <201506031817.t53IHJit066848@mainfs.snmp.com> <026301d0a29f$852a8340$4001a8c0@gateway.2wire.net> <02fb01d0a42b$33b519c0$4001a8c0@gateway.2wire.net> Date: Sat, 13 Jun 2015 12:53:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.162.168] X-ClientProxiedBy: AM2PR07CA0021.eurprd07.prod.outlook.com (25.163.24.159) To AMSPR07MB049.eurprd07.prod.outlook.com (10.242.81.11) X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB049; 2:Uf6+0GZYOlxZkXeftqCLAI0q7wuLyVPjaNrYFr/g5iCE4zzGaCypTz+jW6R9eDlc; 2:vkBiMo8/ZFgvu5Mt/IO3jBg5cpskNTzv61lTYFAOnFAa4QAQ8FjKEjHyWi4ASxnZXwWq74ogomoWSwvt8zA/cQJlAj6z+TEZhL+0aMAM4rPspDlGHCKdwHRjREXvBIGn1eGel6FW+0qZGLcUykmKcw==; 6:jGnSktTIxb409KH1hVjV0siwAbMXM3azOyNl2WJEdmeHcO11rnWpO5RrP9Jo5lZCNzuMdabT91tng1ZUtE/84RBBFJZj2pQBHV/7XP/iJr2EkSr5YphKosjV8I3jrsHtL5wIMEUE5mVpScaXYvWeDA==; 3:LKhm/th731O0FpoToTrX0o3RzRqGu23ox+l07f6A1VyJO1UZFl8ZcCOkoqOCZXPN+QnXE4Fm69zGncTpgw9zEPPZ52IP+Ro4/7cdV29nlTZNB2rN400OsI1n/VKiSKstCcnRYx6BZNZvxD1s/pHgrw7/vrZ+A/PWgQTJSia0Q1FvrB7WXhwjzm/1qW/HkK94753Tm1XwtdHtPDHaNzE+jJbI9zHw5e+rHeL+1dWtuEJurG9YVQIwLVcA8GlRUpyD+nlJMSceYkRlLmQpDUyp9IrgiQZH8B1arh92sOUfXNUNH45xDAR6lEQTazJqP8ar X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB049; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:AMSPR07MB049; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB049; X-Forefront-PRVS: 0606BBEB39 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(164054003)(51704005)(377454003)(50986999)(81816999)(81686999)(86362001)(76176999)(14496001)(62966003)(122386002)(87976001)(77156002)(84392001)(50226001)(44736004)(40100003)(230783001)(33646002)(19580395003)(116806002)(5001770100001)(19580405001)(66066001)(47776003)(23756003)(62236002)(44716002)(61296003)(46102003)(42186005)(5001960100002)(107886002)(77096005)(189998001)(50466002)(92566002)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB049; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; AMSPR07MB049; 9:a6N5JGG+178KtPsAOAin+rFa0pC6EhiuhJFfZPbid?= =?iso-8859-1?Q?EGGVijD1kUZvi4jbpduOwlU8JpQNUJmbpAasUU0kPQ8gXF1zrAhY30s0z7?= =?iso-8859-1?Q?nzA16zFEY1ifN6PLJLjqSQHD7pI0TpfkjI7WPBmkpux+xGHk6I7i9hOGv0?= =?iso-8859-1?Q?pNHVx7zMQVkQIv22E/DKgcacHrn+pB41qfc/fwrjU37b3adMiATh7JkYsv?= =?iso-8859-1?Q?5sufP+g+BFCPLVuvBNaU6rL0XGcMMgwKvIPA7TbLjA0aZ4F4SlHBmKFi4F?= =?iso-8859-1?Q?iB3BICvKMZNeCAyPtQTxoZHRHgJ9QKJwG9rGdJS9puzGAnEMdx8VTbdVST?= =?iso-8859-1?Q?c36+7+j7ZtUj4oaTkxyo8iXF1O3w8gU2/s7qFeSwWadgQEBqPShjoYvXFE?= =?iso-8859-1?Q?AJDImdA1JpvFHt9rIdMn1IipEqmEd56d4DXHTszudA3yy0XjD6uafg6RZX?= =?iso-8859-1?Q?mTEUPX0NdgKVZNV47GkN1i/1+dKqeUuJhWnda95xUnN4SdrxK4GByQolLv?= =?iso-8859-1?Q?rOofCDP7xzQvcBumdILXQwg7cKFL5PTfePpG8C1P+JKsKTvE8ocBFTxRFD?= =?iso-8859-1?Q?oRXcQonJGsY7ZlSuoksfF4d0r1YoPZXzMqnheaIX1e2DDFBzVxfmJ6nYpv?= =?iso-8859-1?Q?xyUwOHzsW/3l9Wf7mKbRCyYKd/UFfabU7IKdVEnO+o6AGMFrHAfBkQ0pnk?= =?iso-8859-1?Q?wYSrqCbPHElKz9UDrYIhGwr4NNZpWzazyFQxBqag4nKN8qi5UE3zeDHt1a?= =?iso-8859-1?Q?XgFm8O3Ir8KjVzAEJLmqPaiS94kGWOSuFCoUq4H/F5IUk4jbF0WCtHKNUK?= =?iso-8859-1?Q?+x5IlvnuoTIPwDIcifoUT3EvGp4VgZOCxCATmvzQBI6phkZJg5DtvMBFLh?= =?iso-8859-1?Q?UQY6VR+oxZgDxNuxqXk1t5yLdg5/m3XvMVHvagavaRNjwNzdw+uaCZ703J?= =?iso-8859-1?Q?4FmpW81hNmXrQPH0I3WekMKW9wkWqH5b+AIClHYjNa1qWsSf58TTyWHbWh?= =?iso-8859-1?Q?rivfBotW1bT3X9bXs78TFa86FR9aFHw9dLF7foum1rq1m27IjAYQdn6NNS?= =?iso-8859-1?Q?BWj7+A0Ymd9SHvHDplw=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB049; 3:D4uztKPOV5p3dNpTq1O3Wwefl+bO7BiS/cUmLZYBcHrHPnVUWQI8yOHgyf4sr0zpold+0vO0bePAP760L9AHS65hBf0g8E9jGhIQu0Az1FnpJ69JMpHz2tWv242J74jFavJiRMARb140Q1QpLRLWOA==; 10:wGZ4D5L8Su8NaiwyfYjBaY4XfPAvGxEaMKxjAnUfo2wABJAHi9KxuMXFp4vcYTiqUqPpmrgjzBAIozFUr0uVhq1Ky6Y2wxhDnf8f+DIxETg=; 6:ygs0i+AVnesgvXDdsZ9Lr9J4tTc0/+plvNR5X1kVGzJoTNXfACgQ22p+wWnh8xEw X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jun 2015 11:56:47.9073 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB049 Archived-At: Subject: Re: [Netconf] draft-ietf-netconf-call-home-05.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2015 11:57:20 -0000 ----- Original Message ----- From: "Kent Watsen" To: "t.petch" ; "Alan Luchuk" ; Sent: Friday, June 12, 2015 9:57 PM Hi Tom, > >yes but I think worth making explicit, saying something along the lines >that that for TLS, the scope of authentication is the same as for >5539bis, namely X.509 certificates while for SSH, any method defined for >SSH will do. The current text sort of implies a greater restriction and >it is that that I wanted to clarify. I tried inserting some text into the Introduction, but there wasn't an easy way to do it. So I rather ask, where are you picking up this greater restriction in the text? Funny you should ask:-) Look at your other post "As part of establishing the SSH or TLS connection, the NETCONF/ RESTCONF server will send its host key or certificate to the client. " which to me says it is certificate or it is host key and it cannot be anything else! Ditto C5 or C7. But if noone else joins in, perhaps best left as is. >>On client authentication by servers, we seem not to require it. I added this new section: S5 In most cases, establishing the SSH or TLS connection also entails server authentication of client credentials; only with RESTCONF do some client authentication schemes occur after the secure transport connection (TLS) has been established. If client authentication is required, and the client is unable to successfully authenticate itself to the server in an amount of time defined by local policy, the server SHOULD close the connection. What do you think? I disagree that client auth seems not required, in that it's required by the draft's normative references: Perhaps 'MUST close' but otherwise ok. And of course when you know the References intimately having worked on them since draft-wasserman, then yes, you will know the requirement for authentication - but I think there is no harm and some benefit in repeating it here, since the vast majority of uses of TLS do not call for client authentication - it is us that is out on a limb here. Tom Petch 1. RFC 6241 says "NETCONF connections MUST be authenticated. The transport protocol is responsible for authentication of the server to the client and authentication of the client to the server." 2. RFC6242 says: "The identity of the SSH client MUST also be verified and authenticated ..." 3. 5539bis says "The NETCONF server MUST verify the identity of the NETCONF client ..." 4. restconf-07 says "The RESTCONF server MUST authenticate client access ..." I'm hoping that the new S5 and the normative references address your concern - do they? Thanks, Kent From nobody Mon Jun 15 06:18:28 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 897A61B2D36; Mon, 15 Jun 2015 06:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.053 X-Spam-Level: X-Spam-Status: No, score=-99.053 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100, WEIRD_PORT=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59_vLQQva-Bl; Mon, 15 Jun 2015 06:18:24 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 72F671B2D32; Mon, 15 Jun 2015 06:18:23 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=8.25.222.10; From: "Susan Hares" To: Date: Mon, 15 Jun 2015 09:18:21 -0400 Message-ID: <00f101d0a76d$c1750550$445f0ff0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F2_01D0A74C.3A667290" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdCnbYY6gWWwpVZITSOWq+lEk1Ly0Q== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: Rtg-yang-coord@ietf.org, 'BESS' , netmod@ietf.org, supa@ietf.org, netconf@ietf.org Subject: [Netconf] IDR interim today at 10:00 - 11:30am ET - Agenda change X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2015 13:18:25 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00F2_01D0A74C.3A667290 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit IDR June 15 interim agenda has changed to allow more time to discuss base BGP yang module. Slides and Agenda are at: http://www.ietf.org/proceedings/interim/2015/06/15/idr/proceedings.html. This bgp yang module (draft-shaikh-idr-bgp-model-02.txt) is being considered for WG adoption (6/15 to 6/29). http://datatracker.ietf.org/doc/draft-shaikh-idr-bgp-model/ Sue Hares ================= IDR interim meeting 6/15 10:00 - 11:30am ET Agenda: 10:00 - 10:05 Bash Agenda 10:05 - 10:20 Presentation of Merged BGP Yang module (Keyur Patel, Anees Shaikh, Rob Shakir) Open Config reference: http://www.openconfig.net/data-models/project-updates/updatedbgpandpolicymod els IETF Draft: http://datatracker.ietf.org/doc/draft-shaikh-idr-bgp-model/ 10:20 - 11:30 Discussion of Merged BGP Module Web-Ex: https://ietf.webex.com/ietf/j.php?MTID=mbb2d89722983f9d24990ba043332a856 Meeting number: 649 169 095 Meeting password: yang.for.life Join by phone 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 649 169 095 Virtual Blue sheets http://etherpad.tools.ietf.org:9000/p/idr-interim-2015-June-15-vBlueSheets Please sign up on the virtual blue sheets. Minutes: http://etherpad.tools.ietf.org:9000/p/idr-interim-2015-June-15-minutes [Please consider helping Sue and John during the interim discussion take minutes. Join the etherpad and correct or work on the web] ------=_NextPart_000_00F2_01D0A74C.3A667290 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable


IDR June 15 interim  agenda = has changed to allow more time to discuss base BGP yang module. =

 

Slides = and Agenda are at:

http://www.ietf.org/proceedings/interim/2015/06/15/idr/proceeding= s.html.

 

This bgp = yang module (draft-shaikh-idr-bgp-model-02.txt)  is being = considered for WG adoption (6/15 to 6/29).

 http= ://datatracker.ietf.org/doc/draft-shaikh-idr-bgp-model/

 

 

Sue Hares =

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

 

IDR = interim meeting 6/15 10:00 - 11:30am ET

 

Agenda: =

 

10:00 - = 10:05   Bash Agenda

10:05 - = 10:20  Presentation of Merged BGP Yang = module

     &nbs= p;            = ;            =             &= nbsp;           &n= bsp;         (Keyur Patel, Anees = Shaikh, Rob Shakir)

 

Open = Config reference:

http://www.openconfig.net/data-mod= els/project-updates/updatedbgpandpolicymodels

 

IETF = Draft:

http://datatracker.ietf.org/doc/dr= aft-shaikh-idr-bgp-model/

 

10:20 - = 11:30           &n= bsp;    Discussion of Merged BGP Module =

 

Web-Ex: =

https://ietf.webex.com/ietf/j.php?= MTID=3Dmbb2d89722983f9d24990ba043332a856

 

Meeting = number:         649 169 095 =

Meeting = password:      = yang.for.life

 

Join by = phone

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

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

Access code: 649 169 = 095

 

Virtual = Blue sheets

http://etherpad.tools.ietf.org:900= 0/p/idr-interim-2015-June-15-vBlueSheets

 

Please = sign up on the virtual blue sheets.

 

 

Minutes: =

http://etherpad.tools.ietf.org:900= 0/p/idr-interim-2015-June-15-minutes

 

[Please = consider helping Sue and John during the interim discussion take = minutes.

Join the etherpad and correct or = work on the web]

 

------=_NextPart_000_00F2_01D0A74C.3A667290-- From nobody Mon Jun 15 06:40:59 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E629A1B2D3D; Mon, 15 Jun 2015 06:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.053 X-Spam-Level: X-Spam-Status: No, score=-99.053 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100, WEIRD_PORT=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKpNMOzRQY1o; Mon, 15 Jun 2015 06:40:53 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id CCC9D1B2BE0; Mon, 15 Jun 2015 06:40:52 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=8.25.222.10; From: "Susan Hares" To: Date: Mon, 15 Jun 2015 09:40:51 -0400 Message-ID: <013301d0a770$e59000e0$b0b002a0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0134_01D0A74F.5E82F4C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdCncKKmELtn8F67Sd+LgR9RcrS6Bg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: Rtg-yang-coord@ietf.org, supa@ietf.org, netmod@ietf.org, 'BESS' , netconf@ietf.org Subject: Re: [Netconf] [Rtg-yang-coord] IDR interim today at 10:00 - 11:30am ET - Agenda (web-ex correction) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2015 13:40:55 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0134_01D0A74F.5E82F4C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Apologies for extra email. Sue Hares --------------------------- Web-Ex: Web-ex is giving me two different web-sites - I suspect both will work. Send email to shares@ndzh.com) if you have problems. https://ietf.webex.com/ietf/j.php?MTID=m05394c6a99d9df8d68e4646e6a6aa80a [online request] https://ietf.webex.com/ietf/e.php?MTID=m8a391b9e59f0215e0a2251f10dac8aae Sue From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, June 15, 2015 9:18 AM To: idr@ietf.org Cc: Rtg-yang-coord@ietf.org; 'BESS'; netmod@ietf.org; supa@ietf.org; netconf@ietf.org Subject: [Rtg-yang-coord] IDR interim today at 10:00 - 11:30am ET - Agenda change IDR June 15 interim agenda has changed to allow more time to discuss base BGP yang module. Slides and Agenda are at: http://www.ietf.org/proceedings/interim/2015/06/15/idr/proceedings.html. This bgp yang module (draft-shaikh-idr-bgp-model-02.txt) is being considered for WG adoption (6/15 to 6/29). http://datatracker.ietf.org/doc/draft-shaikh-idr-bgp-model/ Sue Hares ================= IDR interim meeting 6/15 10:00 - 11:30am ET Agenda: 10:00 - 10:05 Bash Agenda 10:05 - 10:20 Presentation of Merged BGP Yang module (Keyur Patel, Anees Shaikh, Rob Shakir) Open Config reference: http://www.openconfig.net/data-models/project-updates/updatedbgpandpolicymod els IETF Draft: http://datatracker.ietf.org/doc/draft-shaikh-idr-bgp-model/ 10:20 - 11:30 Discussion of Merged BGP Module Web-Ex: https://ietf.webex.com/ietf/j.php?MTID=mbb2d89722983f9d24990ba043332a856 Meeting number: 649 169 095 Meeting password: yang.for.life Join by phone 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 649 169 095 Virtual Blue sheets http://etherpad.tools.ietf.org:9000/p/idr-interim-2015-June-15-vBlueSheets Please sign up on the virtual blue sheets. Minutes: http://etherpad.tools.ietf.org:9000/p/idr-interim-2015-June-15-minutes [Please consider helping Sue and John during the interim discussion take minutes. Join the etherpad and correct or work on the web] ------=_NextPart_000_0134_01D0A74F.5E82F4C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Apologies for extra email. =

Sue Hares

 

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

=

Web-Ex: =

Web-ex is giving me two different web-sites - =  I suspect both will work.  Send email to shares@ndzh.com) if you have = problems.  

 

https://ietf.webex.com/ietf/j.php?MTID=3Dm05394c6= a99d9df8d68e4646e6a6aa80a

 

=

[online request]

https://ietf.webex.com/ietf/e.php?MTID=3Dm8a391b9= e59f0215e0a2251f10dac8aae

 

Sue =

 

From:= = Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of = Susan Hares
Sent: Monday, June 15, 2015 9:18 = AM
To: idr@ietf.org
Cc: Rtg-yang-coord@ietf.org; = 'BESS'; netmod@ietf.org; supa@ietf.org; = netconf@ietf.org
Subject: [Rtg-yang-coord] IDR interim today = at 10:00 - 11:30am ET - Agenda = change

 


IDR June 15 interim  agenda = has changed to allow more time to discuss base BGP yang module. =

 

Slides = and Agenda are at:

http://www.ietf.org/proceedings/interim/2015/06/15/idr/proceeding= s.html.

 

This bgp = yang module (draft-shaikh-idr-bgp-model-02.txt)  is being = considered for WG adoption (6/15 to 6/29).

 http= ://datatracker.ietf.org/doc/draft-shaikh-idr-bgp-model/

 

 

Sue Hares =

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

 

IDR = interim meeting 6/15 10:00 - 11:30am ET

 

Agenda: =

 

10:00 - = 10:05   Bash Agenda

10:05 - = 10:20  Presentation of Merged BGP Yang = module

     &nbs= p;            = ;            =             &= nbsp;           &n= bsp;         (Keyur Patel, Anees = Shaikh, Rob Shakir)

 

Open = Config reference:

http://www.openconfig.net/data-models/project-updates/upd= atedbgpandpolicymodels

 

IETF = Draft:

http= ://datatracker.ietf.org/doc/draft-shaikh-idr-bgp-model/

 

10:20 - = 11:30           &n= bsp;    Discussion of Merged BGP Module =

 

Web-Ex: =

https://ietf.webex.com/ietf/j.php?MTID=3Dmbb2d89722983f9d24990= ba043332a856

 

Meeting = number:         649 169 095 =

Meeting = password:      = yang.for.life

 

Join by = phone

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

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

Access code: 649 169 = 095

 

Virtual = Blue sheets

http://etherpad.tools.ietf.org:9000/p/idr-interim-2015-June-15= -vBlueSheets

 

Please = sign up on the virtual blue sheets.

 

 

Minutes: =

http://etherpad.tools.ietf.org:9000/p/idr-interim-2015-June-15-min= utes

 

[Please = consider helping Sue and John during the interim discussion take = minutes.

Join the etherpad and correct or = work on the web]

 

------=_NextPart_000_0134_01D0A74F.5E82F4C0-- From nobody Mon Jun 15 10:22:11 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6948A1A90ED; Mon, 15 Jun 2015 10:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMRLv-vlLlSk; Mon, 15 Jun 2015 10:22:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 177A41A908D; Mon, 15 Jun 2015 10:22:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150615172209.4489.31033.idtracker@ietfa.amsl.com> Date: Mon, 15 Jun 2015 10:22:09 -0700 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-call-home-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2015 17:22:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : NETCONF Call Home and RESTCONF Call Home Author : Kent Watsen Filename : draft-ietf-netconf-call-home-08.txt Pages : 14 Date : 2015-06-15 Abstract: This RFC presents NETCONF Call Home and RESTCONF Call Home, which enable a NETCONF or RESTCONF server to initiate a secure connection to a NETCONF or RESTCONF client respectively. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-call-home/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netconf-call-home-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-call-home-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 15 10:28:18 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9267F1A9163 for ; Mon, 15 Jun 2015 10:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pI2ilCIYUy5O for ; Mon, 15 Jun 2015 10:28:15 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0127.outbound.protection.outlook.com [65.55.169.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51CC61A90F6 for ; Mon, 15 Jun 2015 10:28:15 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.1.184.17; Mon, 15 Jun 2015 17:28:13 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.121]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.121]) with mapi id 15.01.0184.014; Mon, 15 Jun 2015 17:28:13 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-call-home-08.txt Thread-Index: AQHQp4/TscwZ+fUUMUq+Tw4za/eIKJ2tjx+A Date: Mon, 15 Jun 2015 17:28:13 +0000 Message-ID: References: <20150615172209.4489.31033.idtracker@ietfa.amsl.com> In-Reply-To: <20150615172209.4489.31033.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [96.231.191.4] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:CO1PR05MB458; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458; x-forefront-prvs: 0608DEDB67 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(24454002)(377424004)(377454003)(164054003)(2950100001)(99286002)(106116001)(15975445007)(102836002)(2900100001)(230783001)(77156002)(62966003)(450100001)(66066001)(2656002)(19580395003)(87936001)(40100003)(122556002)(86362001)(46102003)(54356999)(50986999)(76176999)(2351001)(92566002)(19580405001)(5002640100001)(5001920100001)(4001350100001)(5001960100002)(189998001)(107886002)(110136002)(2501003)(36756003)(83506001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <6CF21FFCC14176439294DF6A58DAD216@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jun 2015 17:28:13.1702 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB458 Archived-At: Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-call-home-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2015 17:28:17 -0000 Changes: o Added text regarding client authentication o Now says server must send all (not any) intermediate certificates o Improved wording based on suggestions from Jonathan and Tom o Now says client-initiated (not standard) NETCONF/RESTCONF Connections I am not aware of any open issues so, in my view, this document should be ready for WGLC. Thanks, Kent On 6/15/15, 1:22 PM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Network Configuration Working Group of >the IETF. > > Title : NETCONF Call Home and RESTCONF Call Home > Author : Kent Watsen > Filename : draft-ietf-netconf-call-home-08.txt > Pages : 14 > Date : 2015-06-15 > >Abstract: > This RFC presents NETCONF Call Home and RESTCONF Call Home, which > enable a NETCONF or RESTCONF server to initiate a secure connection > to a NETCONF or RESTCONF client respectively. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-netconf-call-home/ > >There's also a htmlized version available at: >https://tools.ietf.org/html/draft-ietf-netconf-call-home-08 > >A diff from the previous version is available at: >https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-call-home-08 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf From nobody Tue Jun 16 03:54:03 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 830BE1A1AC1 for ; Tue, 16 Jun 2015 03:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FH2jmo0jPgEs for ; Tue, 16 Jun 2015 03:53:59 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0734.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0781B1A0123 for ; Tue, 16 Jun 2015 03:53:58 -0700 (PDT) Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none; Received: from pc6 (81.151.162.168) by AM2PR07MB0516.eurprd07.prod.outlook.com (10.160.31.21) with Microsoft SMTP Server (TLS) id 15.1.190.14; Tue, 16 Jun 2015 10:53:41 +0000 Message-ID: <009701d0a822$552532c0$4001a8c0@gateway.2wire.net> From: t.p. To: Kent Watsen , Phil Shafer References: <201503300503.t2U53jqh084141@idle.juniper.net> Date: Tue, 16 Jun 2015 11:34:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.162.168] X-ClientProxiedBy: AMSPR02CA0016.eurprd02.prod.outlook.com (10.242.225.144) To AM2PR07MB0516.eurprd07.prod.outlook.com (25.160.31.21) X-Microsoft-Exchange-Diagnostics: 1; AM2PR07MB0516; 2:K3TjIUQ/GWeFvKASgJ/lYh80M+GVRyFlWduCHCfhIFlaXLmEW3njoAEVPebi2wUr; 2:sDK6T/8JDwp3Gb7ELF+9a6oR2ndmDAMb96pQBatzY/kHiZvmaXmp2FMuVPrDpTzPfWO5asOQt2XtJLMKoyeRb6MFvaSp6+qe1P1VSc1ftaoZ0fvHRmfDeo2hPO+o0v1dXSjaujE7J5/HBLbtgBLOGQ==; 6:5rzPwekeIwTpuvdgt6kQKo+tAp3IzXkGOdNq3aC0GsSx+OaeXVJJP3nIf2MrrRWGI3b9OIWIYQd2fwbQqUAKZX7gR8/frfdltLI6Ig1KvzJzumOakTnb4OWMb+C85mVth6MnZcWMUgGGbKnWLItDfQ==; 3:1sR1ZBlyRfvZd5SR8OvmvlyL4eb7BHcIW9+PJ0jK/xaL3p3BEcny+vnSjZD67iADJnR/noxQvzg/SYhAjNlAk0bbLE8sef1Xl+uRpJ+aGnXv6Dx2+pcjAXte/Oogh5P8jF4elhCkwEjMckSrPf93wqMA5EfjLsTOAcvoFSQn6nqHGQpmNObJIK7gHmpiY/JYtqyanK4H7vvDvTEQWcQgO4VZShqxIJXKk5LWeXozN3HGbaSkss4Le2+/Ym9zVe4y1OItNVDwNvaJZtoFMPf7/JQLgqsRlxqFNKhCBXKjrKP0Gf+3aQMTZbsQYTo7f2wc X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM2PR07MB0516; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:AM2PR07MB0516; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0516; X-Forefront-PRVS: 06098A2863 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(479174004)(24454002)(13464003)(164054003)(51704005)(84392001)(77156002)(42186005)(77096005)(1456003)(50466002)(189998001)(122386002)(40100003)(23756003)(61296003)(14496001)(5001770100001)(87976001)(86362001)(44716002)(5001960100002)(62236002)(33646002)(66066001)(46102003)(50226001)(44736004)(5001920100001)(19580395003)(50986999)(76176999)(47776003)(92566002)(19580405001)(81816999)(1556002)(116806002)(81686999)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:AM2PR07MB0516; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; AM2PR07MB0516; 9:sRRxrJrDcAZwXRdiNucU7WUEPeoyL9rBreDrLe23?= =?iso-8859-1?Q?khIyLTnKOZSCokkG1fzn9rsLKpk2bIBJPPLStTIy84FOMRpQAwuhO6uRom?= =?iso-8859-1?Q?YdadKhjlxOxUEjCKqb5n/eypt55BrHCJ7NM2vKEjxYAqhnmbqEJqQiBXqC?= =?iso-8859-1?Q?7axt3JHrEAN/MeKhuzIsKw3wi/PlcsUNqz2aaU/qFFOsabYbWkPQp9k2ZZ?= =?iso-8859-1?Q?1wovtq0cYRWcnUcKtSjzbjo7UvxbQ+v/EVEv/OqMUozbLfg0LZKCw9f4gR?= =?iso-8859-1?Q?TTQvzoh0sjbhe5KsT/P3eTTrICcLQGc2ALRi8blFiw2kAgkHGNLjPjurxJ?= =?iso-8859-1?Q?T1hl9xbHzUADJ2lW0zMAheNuLkgU3WzTQxfKC4yF0TI3Xjxar0OaPpJ7HT?= =?iso-8859-1?Q?i79UVGdZkXG9MuXFvJsWR/Expo8YDv56d2eqGtjaZHqa7d+eqKJ/+92cNe?= =?iso-8859-1?Q?ASBkpnvWx2YuVNNCMHGKNmpT4Ty7pw/xkk/CMDQ0a4DhVQRGcQ+2GhjXpV?= =?iso-8859-1?Q?9AaCMzjYyaQO/P0Ukpl8dFl1aYrtBorluVODlWijxC0n/13CwjzfFI2Whw?= =?iso-8859-1?Q?UXj5iGYvClgGjjQvEOgYn0FObJHZcJfNX6H5LYtPPDpBnapTcd8QGVqQuY?= =?iso-8859-1?Q?uYMNM/58fwR5kxwg01FUKAQA3kslyYvdI5u0+yTs7ExuKQySChTBAPn4Tm?= =?iso-8859-1?Q?FX2X6rJBdvT7N+EvJMAFJZ+GxDUkGu60BOyLxfIfOMa2Uof0KY70x6a9+p?= =?iso-8859-1?Q?Ahe59yxi/OVYhFn6GfoQQAUbWwxhUpF+KRt6zBLemMXIS4p8PbIsPN5IEM?= =?iso-8859-1?Q?tyYoTyJmayc+OYb6kbMmzzTNnKUoZ78NGm+HeuhL3rJjl4w2SFQBmp028K?= =?iso-8859-1?Q?GjD9XGdVo4B0PiCRr24u4D27rjEKgy0nwx5/gqk47wdk29TpSo+E5TBQiS?= =?iso-8859-1?Q?o4zDQj7rHWdSdoXIgZ1mzF9PpJnVqNSg2gaq9ViPzBEzHtKIuNASujHp6q?= =?iso-8859-1?Q?PxA1pEdxxyXQktaOL1Em15JQtNBrXwdzCjwSS+9p3PQMWwQvGlg+WbbWBZ?= =?iso-8859-1?Q?Aigw6UkKD0BhzsBjf62LUIroKv1LVoEQhLOWZkszKelbjy8IYVDYtrDDHH?= =?iso-8859-1?Q?BeP5CERN/27xAF5JQfcI3qcU0A=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; AM2PR07MB0516; 3:eQmkXhVXobU9Txw+7Vq8DUgYcz1s4gVdtwbyfuSkhHUSnAMFd51OZhyXvwbszbvRoYMLYChOZPOAU9xRDdmGQGPJaJKuRLtr/y7HcAzIKKU5JnjzondI45PcKvUySvMjLdb3rPNaxSmjdl+AVzHKQQ==; 10:6W2uH5kEME1cFOTd9J0pQTku1GteV+JccbAl4pg4J4j3p8eCO7sOixyEkNPrsDjFxdu+5Fn91JJq8DlzI068QHXYxADeB60pZATt0z3Yh1c=; 6:zSg1tQUeRS0BNfFbqMPhn3ZYREC4AydWvTmuk6z5dvlcFY9YpEX/+1LXKshlkUzk X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Jun 2015 10:53:41.9109 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0516 Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] server-model #43: keep-alive, linger, reconnect interval defaults OK? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 10:54:01 -0000 ----- Original Message ----- From: "Kent Watsen" To: "Phil Shafer" Cc: Sent: Friday, May 15, 2015 12:06 AM > > On 3/30/15, 1:03 AM, "Phil Shafer" wrote: > >Kent Watsen writes: > >>Note, this is a > >>keep-alive message being sent every 15 to 300 seconds, with a default > >>count-max of '3', results in a new connection after 45 to 900 seconds - > >>that's 3/4 of a minute to 15 minutes to proactively bring up a failed > >>session. > > > >Having a connection to your NMS die after 45 seconds during a network > >issue, when the network _is_ having trouble, seems unwise. > > Hi Phil, > > This timer is to test the aliveness of the connection. Sure, if the NMS > doesn't respond in time, the device tears down that connection in hope to > find a connection the works better. > > 45 seconds seems too short to you, and 15 minutes seems too long to me. > How about 5 minutes for the default? Anyone else have an opinion? Yes; it depends on the application. In voice (not where this will be used), the target MTTR is 50mS so failure detection is set at 30mS so the keepalives are sent every 10mS and this is seen as the norm. In network operation, I see operation centres wanting to know about failures before the phone starts ringing, in which case I see 30S used, which is on the long side, but a shorter interval may generate too much traffic when the network has over 100,000 elements. For a non-operational system, minutes or hours might be appropriate, even once a day for a backup system. I would rather we did not put in a default but something along these lines, that it depends how quickly a failure needs to be detected to meet the required service. The count of three attempts before declaring failure is, by contrast, almost universal so I have no qualms there. This implies failures are detected in three to four times the interval. If forced to put in a default time, I would go for 30S with a caveat that this should be reviewed in the light of how much traffic this will generate - it is very dependent of network size. Tom Petch > > Thanks, > Kent > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Tue Jun 16 03:56:21 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0863F1A1AC1 for ; Tue, 16 Jun 2015 03:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFw0V_P96khP for ; Tue, 16 Jun 2015 03:56:17 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0773.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::773]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A04C11B2FDD for ; Tue, 16 Jun 2015 03:56:16 -0700 (PDT) Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none; Received: from pc6 (81.151.162.168) by DBXPR07MB064.eurprd07.prod.outlook.com (10.242.147.24) with Microsoft SMTP Server (TLS) id 15.1.190.14; Tue, 16 Jun 2015 10:55:56 +0000 Message-ID: <00a001d0a822$a53961a0$4001a8c0@gateway.2wire.net> From: t.petch To: Date: Tue, 16 Jun 2015 11:53:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.162.168] X-ClientProxiedBy: AMSPR02CA0042.eurprd02.prod.outlook.com (10.242.225.170) To DBXPR07MB064.eurprd07.prod.outlook.com (10.242.147.24) X-Microsoft-Exchange-Diagnostics: 1; DBXPR07MB064; 2:2FfCKtyYOjVC59tOSzmntHSgeCuGm2gJmukXm2UyiE2aiAovkEe/zZgRXcPzZed3; 2:wzP09/KybjDfhByrFN1CIVeCU5IoIFQmt+CMaznI0Uai3TPFQdtZ7YCfxY0HhxmpYVfciTjhGIOCr4T3ow5DNz0QcwrGOfhn3VJcJeBBgSzCfDhW3DHWxganzda3ALzBviJ8QxSYg3S47uvvoRKv4w==; 6:qkYn8R287BwWeYi8JwX8+VEf/69cKdaQ/g3cqdTOLHFuvxRhyU46BVUTEsplaodnThR+QAmP8I7MDe59AOP/62dh0L2o99g4D755dJOJyD2b9DVZysZZ9fnE4jpA0bMDlV6uOsb9veOGEigDsznj4Q==; 3:n5/va4cmZ54mySj1aMcqbn+q1YC3w2rWDWTW5/+AxB1gCEwnv9tTPQNdJENmKkAEqw5SrRKy0qKeTcEb8U9z+SsO7dUVQJXMuILBKGoS34nOUi0oQlyUu27TxLiFSujWZmNhWadIPEsbRFx4Cenyr3FuQ4oBO9P+iP9+f9OMHnnc7+crOKsd5TKiCi2cLaBEcvr+rUlrYGAhJ+nNMSijpthJFXfSe8ySzC6w6saZ40ttZ7TSddY7Ghn9IOlvEwRtzmPcGT8UnYIhynZgdghW250JvDdaH+2YX8Q72b4/zDW1JKGiVuzCG595i9PCtpTR X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB064; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:DBXPR07MB064; BCL:0; PCL:0; RULEID:; SRVR:DBXPR07MB064; X-Forefront-PRVS: 06098A2863 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(51704005)(24454002)(164054003)(377454003)(479174004)(2351001)(50466002)(33646002)(50226001)(42186005)(81816999)(229853001)(81686999)(61296003)(1456003)(5001960100002)(110136002)(189998001)(107886002)(46102003)(14496001)(40100003)(450100001)(122386002)(77156002)(92566002)(44736004)(47776003)(66066001)(86362001)(62236002)(116806002)(84392001)(23756003)(77096005)(19580405001)(87976001)(50986999)(44716002)(1556002)(19580395003); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB064; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; DBXPR07MB064; 9:kDhfhUim/MD/5693uJto+GJbt4+WHlsvmDxsT4yZW?= =?iso-8859-1?Q?QniPOMT8lIxEhdlqHcO3QhXrhKxA4GSwpbZ8Wg174kltN0KAoekFlxHgFB?= =?iso-8859-1?Q?TrxTtKYsqLc0stD+JywXJEzxgkuqWNQwE6jhHLQUt1VGhAdw0lDjvVbnOl?= =?iso-8859-1?Q?+NZkkcoXngxH5crHKb+6NdXtsxs6v4ncXSTKKIghD8nvzk5vNOsygA6Two?= =?iso-8859-1?Q?2FVPXBzdPpKyyEH/lxDLf+93KXMSHtm/UrDJLNTYzGZJMGmlFBiWpoBLHO?= =?iso-8859-1?Q?7NbRWdFgeTAIep0aWfPjHkcUK3rye1qGw3OpZgTLU3VPEQsTbVpv1wk5mm?= =?iso-8859-1?Q?uFoVM7MzMH/fnlsnkfGKVBawOsFI2cXWS1mIwuY4ZVRFZbSQJegmt2N6H7?= =?iso-8859-1?Q?hc3AUNup7afZa203VdeSSqTUZzjSn8irD5MXHWAq06IV+hNqN3s2ZlX027?= =?iso-8859-1?Q?NmSbXtxF8IfeFgzx5KYOHMgeEbNg3hr3WB2P3/moxqYY6Jd35cah6WgiY0?= =?iso-8859-1?Q?4pIEj3MW7aGHNjgQ73yB28ujBB39Dvp3Ki56RocvzsozHYvOu0uJIWmZJr?= =?iso-8859-1?Q?IkZY9usOn38/3tvCi+LryGEPpaPeJgkJ62HXi8dG6qAM1jf4g2eQbrMJqm?= =?iso-8859-1?Q?qDFIrP5thrlFBNZSSxK8/Zwe/1iu8tfeQZBecfnx1n5B9JoxB3f7uIUnBn?= =?iso-8859-1?Q?0OeOn/QbX3+bi4TW0vsShhkTMtGkqDmiQhaQKOJPUfBa1F07Fm8c519eQg?= =?iso-8859-1?Q?WxjX5+CMHTZ6JyNBcmrjiR71EsvzsNvgquxBlQ/5vROQmMO+yJ3gv1iZGF?= =?iso-8859-1?Q?399BKpxth2mp0P/mFGueI/sB47gldTY1uoTP7b6QaQplf6UQMwoiXr3+IJ?= =?iso-8859-1?Q?TQ9QpxmQ04OALzavNhXxmk8PFgn05q6+W1AvRtlIBZMcSHv3fk35N5kTqE?= =?iso-8859-1?Q?xup/olUkUJVNX+xKBRpnfAaCDKiCIu0mBFdLxB/96RDd8ujwGzQdeK928t?= =?iso-8859-1?Q?ZpPH8wsmxGBMP76Uk12qe1tbSI+Kc3fP11qKynnLs0nAmogxvyeR6Gl+kq?= =?iso-8859-1?Q?YZrvWB+RSqtd6DT8vXfWJs46kQgDjmlENBQxzahD3HgooG+DwCCHYj5Pgg?= =?iso-8859-1?Q?ktfxYimsxv2wcinKsu2Hqublg=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; DBXPR07MB064; 3:x+iXGSqs2lWgvMwDXmL/NZ9kQOMR5i35OmC5VnRbi+ovS8N4F9p0v3vbdGPukRv141PbY2Id2HJbqTlt+ceJEXYpTvDXjIYzV7ACC8zOLycIuG9wL8kbnmsuY84ayzXtwBF95/WBg/s/g2kv5hp8gA==; 10:DpS/Ey79isTG0jFS9TVuR60cqEcRN6W7fTDY9PVkkUs233zkaYT30TYLTI1nHl2GAddBQIHGLL0Y+0NWe1ZtjUEy1gPF4tVEK7WM6URWAow=; 6:vzA6ko/2/JCZcxv+JnN1PWyR8T8E0XgDD/6oQTNA+HxhFRCKKkNUJwRVtKzYejRa X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Jun 2015 10:55:56.0715 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB064 Archived-At: Subject: [Netconf] server-model #43: keep-alive, linger, reconnect interval defaults OK? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 10:56:19 -0000 ----- Original Message ----- From: "Kent Watsen" To: "Phil Shafer" Cc: Sent: Friday, May 15, 2015 12:06 AM > > On 3/30/15, 1:03 AM, "Phil Shafer" wrote: > >Kent Watsen writes: > >>Note, this is a > >>keep-alive message being sent every 15 to 300 seconds, with a default > >>count-max of '3', results in a new connection after 45 to 900 seconds - > >>that's 3/4 of a minute to 15 minutes to proactively bring up a failed > >>session. > > > >Having a connection to your NMS die after 45 seconds during a network > >issue, when the network _is_ having trouble, seems unwise. > > Hi Phil, > > This timer is to test the aliveness of the connection. Sure, if the NMS > doesn't respond in time, the device tears down that connection in hope to > find a connection the works better. > > 45 seconds seems too short to you, and 15 minutes seems too long to me. > How about 5 minutes for the default? Anyone else have an opinion? Yes; it depends on the application. In voice (not where this will be used), the target MTTR is 50mS so failure detection is set at 30mS so the keepalives are sent every 10mS and this is seen as the norm. In network operation, I see operation centres wanting to know about failures before the phone starts ringing, in which case I see 30S used, which is on the long side, but a shorter interval may generate too much traffic when the network has over 100,000 elements. For a non-operational system, minutes or hours might be appropriate, even once a day for a backup system. I would rather we did not put in a default but something along these lines, that it depends how quickly a failure needs to be detected to meet the required service. The count of three attempts before declaring failure is, by contrast, almost universal so I have no qualms there. This implies failures are detected in three to four times the interval. If forced to put in a default time, I would go for 30S with a caveat that this should be reviewed in the light of how much traffic this will generate - it is very dependent of network size. Tom Petch > > > > Thanks, > > Kent From nobody Tue Jun 16 16:36:11 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24EA11B2A38 for ; Tue, 16 Jun 2015 16:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wo10GiJ5xG5b for ; Tue, 16 Jun 2015 16:36:07 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0119.outbound.protection.outlook.com [65.55.169.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 E8E5A1B2A16 for ; Tue, 16 Jun 2015 16:36:06 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.1.190.14; Tue, 16 Jun 2015 23:36:05 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.121]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.121]) with mapi id 15.01.0184.014; Tue, 16 Jun 2015 23:36:05 +0000 From: Kent Watsen To: Kent Watsen , Andy Bierman , Mahesh Jethanandani Thread-Topic: [Netconf] YANG Patch Issue #3: :distinct-startup Thread-Index: AQHQn7V+nTs/gEHKBUCSzfCLoklY1p2iSG2AgAAUEwCAAARBgIAAS84AgAADgwCAAAdzAIAAA7oAgADFgICAAMdGgIAASgcAgADBhoCAANLSAIAADKSA///l9wCACX7vgA== Date: Tue, 16 Jun 2015 23:36:04 +0000 Message-ID: References: <20150608.102005.1482395931170643204.mbj@tail-f.com> <20150608094708.GA28936@elstar.local> <20150608143100.GD29788@elstar.local> <20150608151059.GB30068@elstar.local> <20150610064843.GA36156@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: juniper.net; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [96.231.191.4] x-microsoft-exchange-diagnostics: 1; CO1PR05MB457; 3:LqNOegF5S2UK8fBjrBaDpzTuOg5XaZc4jsw9DAC6Mjm/lhiFFlzYarbsS2njD2ZnvELJnvS3WWwZT2TObYmatD61dS4bynkBSOvt742zeoT6XOSOCn/VsRiFAXHXjmfFgcp2NBbrdsOp6AsTMDURrA==; 10:8xyYkPSh6MG2A6cYN+lz2dShFTx77fU87urFFBVmjn6fwN9jkANtXKRki1+cVkkQ0PpUYszKYsncsQk1fUIlVsh78JW5eqJ8ILUAPhocGfk=; 6:rc4Q2RFnWIMf+vLl2g66LmNcpPl63kh+86iM2nM5GkDd86k88w5hCsTvG1+ZSbse x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520003)(3002001); SRVR:CO1PR05MB457; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457; x-forefront-prvs: 06098A2863 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(24454002)(377454003)(51704005)(51444003)(164054003)(5383002)(99286002)(5001770100001)(54356999)(4001350100001)(19580405001)(19580395003)(86362001)(87936001)(2656002)(102836002)(2950100001)(15975445007)(2900100001)(189998001)(50986999)(92566002)(5002640100001)(76176999)(62966003)(77156002)(106116001)(5001960100002)(93886004)(83506001)(46102003)(66066001)(40100003)(122556002)(36756003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jun 2015 23:36:04.3178 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB457 Archived-At: Cc: Netconf Subject: Re: [Netconf] YANG Patch Issue #3: :distinct-startup X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 23:36:09 -0000 Following up on this, it turns out that our NMS always persists its updates to the server's NV store, and there are no customer requests to provide a knob to control that behavior. Even more surprising, JUNOS does not even support the :distinct-startup (unlike JUNOSe and IOS). Possible explanations include: 1) Junos commits are already long, such that the persistence overhead isn't a big deal, 2) NETCONF clients typically push a single large , unlike CLI interactions, hence why operators are not concerned by persistence overhead, and 3) the desire for operators to test changes before persisting to NVS isn't as important as I had originally thought. As there are no customer requests to change this behavior, I have to take back my thinking a RESTCONF equivalent to the distinct-startup capability is important feature. It will be interesting to here from operators on this, or even other vendors that have collected operator input. Kent On 6/10/15, 6:35 PM, "Kent Watsen" wrote: > > >On 6/10/15, 4:08 PM, "Andy Bierman" wrote: > >>The other use of user-controlled NV-store is that in case the device >>reboots, >>it will come back with a known good configuration. If every edit is >>NV-saved, >>then there is no chance for the operator to test the changes before >>changing the startup config. > > >Both are important, but I think that this is the primary use case, with >performance being a close second. > >Case in point, Junos (update: I meant JUNOSe here) CLI has auto-commit on >by default (i.e. performance >isn't an issue), but offers what is called Manual Commit mode (service >manual-commit). I'm trying to collect numbers, but I heard that it's >still widely used. > >Thanks, >Kent > > > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf From nobody Tue Jun 16 16:51:31 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A40371B2B5C for ; Tue, 16 Jun 2015 16:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hyrx9dbeQ2oQ for ; Tue, 16 Jun 2015 16:51:28 -0700 (PDT) Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 328F51B2B5B for ; Tue, 16 Jun 2015 16:51:28 -0700 (PDT) Received: by labko7 with SMTP id ko7so21856277lab.2 for ; Tue, 16 Jun 2015 16:51:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=OyVtN5vOR3MiBF2l1USpJ8HjEIpq4wikqFlP/lF6qvA=; b=D7TYcIdUpYxC0Jm8TzBHMOp+ty0W2G/eWBYpjwQ5H1QyHLfETWmfNQk+mXVnXNOIiL Chm5f6XyjOXotqL3QCYvjGoUQNv9MQwLeZDmPDU8SJUR6EL+TwY2vm7XN6Yjx3vxSs3I 7LHhg5ZfSRAejhll87obuqjnZd55a9OVFnsKmE6pJa681X2emDC7BpGn+Bk1UHrHK4LG IzdWbMf3VLjcjgl0Jyu5UQiIAHXYFIdwVMc1lYHgrKAes2uJ+QPI5Egr60ittrDVTGYQ YxMRVPKhxWqsfwsjtPo0qPxoZi8Q49BRgfCPZ2/R5J33ubYL/hu9YYdBAAQaeYN68DMb kNsA== X-Gm-Message-State: ALoCoQmZF24z9DyamMeYcm7byMJDOOYtgaW4bLEVA/YN5Bs+60zI/aV6Zaf92Y4fMmdxCOofUJ62 MIME-Version: 1.0 X-Received: by 10.112.55.207 with SMTP id u15mr4871074lbp.88.1434498686624; Tue, 16 Jun 2015 16:51:26 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Tue, 16 Jun 2015 16:51:26 -0700 (PDT) In-Reply-To: References: <20150608.102005.1482395931170643204.mbj@tail-f.com> <20150608094708.GA28936@elstar.local> <20150608143100.GD29788@elstar.local> <20150608151059.GB30068@elstar.local> <20150610064843.GA36156@elstar.local> Date: Tue, 16 Jun 2015 16:51:26 -0700 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: multipart/alternative; boundary=001a113403d8a5b9f10518ab40cf Archived-At: Cc: Netconf Subject: Re: [Netconf] YANG Patch Issue #3: :distinct-startup X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 23:51:30 -0000 --001a113403d8a5b9f10518ab40cf Content-Type: text/plain; charset=UTF-8 On Tue, Jun 16, 2015 at 4:36 PM, Kent Watsen wrote: > > Following up on this, it turns out that our NMS always persists its > updates to the server's NV store, and there are no customer requests to > provide a knob to control that behavior. Even more surprising, JUNOS > does not even support the :distinct-startup (unlike JUNOSe and IOS). > > Possible explanations include: 1) Junos commits are already long, such > that the persistence overhead isn't a big deal, 2) NETCONF clients > typically push a single large , unlike CLI interactions, > hence why operators are not concerned by persistence overhead, and 3) the > desire for operators to test changes before persisting to NVS isn't as > important as I had originally thought. > > As there are no customer requests to change this behavior, I have to take > back my thinking a RESTCONF equivalent to the distinct-startup capability > is important feature. It will be interesting to here from operators on > this, or even other vendors that have collected operator input. > > I suspect that REST developers that use ORM/SQL APIs expect the same behavior in RESTCONF -- editing an object is saved in SQL right away. It isn't very REST-like to come back later a push the magic "save" button. This could easily be added as a vendor extension if needed. > Kent > > Andy > > > On 6/10/15, 6:35 PM, "Kent Watsen" wrote: > > > > > > >On 6/10/15, 4:08 PM, "Andy Bierman" wrote: > > > >>The other use of user-controlled NV-store is that in case the device > >>reboots, > >>it will come back with a known good configuration. If every edit is > >>NV-saved, > >>then there is no chance for the operator to test the changes before > >>changing the startup config. > > > > > >Both are important, but I think that this is the primary use case, with > >performance being a close second. > > > >Case in point, Junos (update: I meant JUNOSe here) CLI has auto-commit on > >by default (i.e. performance > >isn't an issue), but offers what is called Manual Commit mode (service > >manual-commit). I'm trying to collect numbers, but I heard that it's > >still widely used. > > > >Thanks, > >Kent > > > > > > > >_______________________________________________ > >Netconf mailing list > >Netconf@ietf.org > >https://www.ietf.org/mailman/listinfo/netconf > > --001a113403d8a5b9f10518ab40cf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jun 16, 2015 at 4:36 PM, Kent Watsen <kwatsen@juniper.net> wrote:

Following up on this, it turns out that our NMS always persists its
updates to the server's NV store, and there are no customer requests to=
provide a knob to control that behavior.=C2=A0 =C2=A0Even more surprising, = JUNOS
does not even support the :distinct-startup (unlike JUNOSe and IOS).

Possible explanations include: 1) Junos commits are already long, such
that the persistence overhead isn't a big deal, 2) NETCONF clients
typically push a single large <edit-config>, unlike CLI interactions,=
hence why operators are not concerned by persistence overhead, and 3) the desire for operators to test changes before persisting to NVS isn't as<= br> important as I had originally thought.

As there are no customer requests to change this behavior, I have to take back my thinking a RESTCONF equivalent to the distinct-startup capability is important feature.=C2=A0 =C2=A0 It will be interesting to here from oper= ators on
this, or even other vendors that have collected operator input.


I suspect that REST developers that us= e ORM/SQL APIs expect the same behavior
in RESTCONF -- editing an= object is saved in SQL right away.
It isn't very REST-like t= o come back later a push the magic "save" button.
This = could easily be added as a vendor extension if needed.

=
=C2=A0
Kent


Andy
=C2=A0


On 6/10/15, 6:35 PM, "Kent Watsen" <kwatsen@juniper.net> wrote:

>
>
>On 6/10/15, 4:08 PM, "Andy Bierman" <andy@yumaworks.com> wrote:
>
>>The other use of user-controlled NV-store is that in case the devic= e
>>reboots,
>>it will come back with a known good configuration.=C2=A0 If every e= dit is
>>NV-saved,
>>then there is no chance for the operator to test the changes before=
>>changing the startup config.
>
>
>Both are important, but I think that this is the primary use case, with=
>performance being a close second.
>
>Case in point, Junos (update: I meant JUNOSe here) CLI has auto-commit = on
>by default (i.e. performance
>isn't an issue), but offers what is called Manual Commit mode (serv= ice
>manual-commit).=C2=A0 I'm trying to collect numbers, but I heard th= at it's
>still widely used.
>
>Thanks,
>Kent
>
>
>
>_______________________________________________
>Netconf mailing list
>Netconf@ietf.org
>https://www.ietf.org/mailman/listinfo/netconf

--001a113403d8a5b9f10518ab40cf-- From nobody Fri Jun 19 17:22:42 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6618A1A9153; Fri, 19 Jun 2015 17:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqVEGH0IKe2B; Fri, 19 Jun 2015 17:22:39 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 552931A90A1; Fri, 19 Jun 2015 17:22:39 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C912D180205; Fri, 19 Jun 2015 17:19:44 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150620001944.C912D180205@rfc-editor.org> Date: Fri, 19 Jun 2015 17:19:44 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, netconf@ietf.org, rfc-editor@rfc-editor.org Subject: [Netconf] RFC 7589 on Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2015 00:22:41 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7589 Title: Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication Author: M. Badra, A. Luchuk, J. Schoenwaelder Status: Standards Track Stream: IETF Date: June 2015 Mailbox: mohamad.badra@zu.ac.ae, luchuk@snmp.com, j.schoenwaelder@jacobs-university.de Pages: 11 Characters: 22727 Obsoletes: RFC 5539 I-D Tag: draft-ietf-netconf-rfc5539bis-10.txt URL: https://www.rfc-editor.org/info/rfc7589 DOI: http://dx.doi.org/10.17487/RFC7589 The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use the Transport Layer Security (TLS) protocol with mutual X.509 authentication to secure the exchange of NETCONF messages. This revision of RFC 5539 documents the new message framing used by NETCONF 1.1 and it obsoletes RFC 5539. This document is a product of the Network Configuration Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Sat Jun 20 00:49:30 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C85FE1B2D87; Sat, 20 Jun 2015 00:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRB8yTu1M5c0; Sat, 20 Jun 2015 00:49:26 -0700 (PDT) Received: from g9t5009.houston.hp.com (g9t5009.houston.hp.com [15.240.92.67]) (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 CED981A6EF2; Sat, 20 Jun 2015 00:49:26 -0700 (PDT) Received: from G9W0364.americas.hpqcorp.net (g9w0364.houston.hp.com [16.216.193.45]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g9t5009.houston.hp.com (Postfix) with ESMTPS id 9BF6D169; Sat, 20 Jun 2015 07:49:25 +0000 (UTC) Received: from G9W3616.americas.hpqcorp.net (16.216.186.51) by G9W0364.americas.hpqcorp.net (16.216.193.45) with Microsoft SMTP Server (TLS) id 14.3.169.1; Sat, 20 Jun 2015 07:46:17 +0000 Received: from G9W0739.americas.hpqcorp.net ([169.254.10.154]) by G9W3616.americas.hpqcorp.net ([16.216.186.51]) with mapi id 14.03.0169.001; Sat, 20 Jun 2015 07:46:18 +0000 From: "Klahr, Sebastien (Communications and Media Solutions)" To: "ietf@ietf.org" , "ietf-announce@ietf.org" , "rfc-dist@rfc-editor.org" Thread-Topic: RFC 7589 on Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication Thread-Index: AQHQqu9FIceyJrHY80WkpXsFx42n1Z21BILL Date: Sat, 20 Jun 2015 07:46:16 +0000 Message-ID: <0078326A92611A458779E9D42AAE590916AFA617@G9W0739.americas.hpqcorp.net> References: <20150620001944.C912D180205@rfc-editor.org> In-Reply-To: <20150620001944.C912D180205@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "drafts-update-ref@iana.org" , "netconf@ietf.org" , "rfc-editor@rfc-editor.org" Subject: Re: [Netconf] RFC 7589 on Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2015 07:49:28 -0000 C Sebastien Klahr ----- Reply message ----- From: "rfc-editor@rfc-editor.org" To: "ietf-announce@ietf.org" , "rfc-dist@rfc-editor= .org" Cc: "drafts-update-ref@iana.org" , "netconf@iet= f.org" , "rfc-editor@rfc-editor.org" Subject: RFC 7589 on Using the NETCONF Protocol over Transport Layer Securi= ty (TLS) with Mutual X.509 Authentication Date: Sat, Jun 20, 2015 02:23 A new Request for Comments is now available in online RFC libraries. RFC 7589 Title: Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication Author: M. Badra, A. Luchuk, J. Schoenwaelder Status: Standards Track Stream: IETF Date: June 2015 Mailbox: mohamad.badra@zu.ac.ae, luchuk@snmp.com, j.schoenwaelder@jacobs-university.de Pages: 11 Characters: 22727 Obsoletes: RFC 5539 I-D Tag: draft-ietf-netconf-rfc5539bis-10.txt URL: https://www.rfc-editor.org/info/rfc7589 DOI: http://dx.doi.org/10.17487/RFC7589 The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use the Transport Layer Security (TLS) protocol with mutual X.509 authentication to secure the exchange of NETCONF messages. This revision of RFC 5539 documents the new message framing used by NETCONF 1.1 and it obsoletes RFC 5539. This document is a product of the Network Configuration Working Group of th= e IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestion= s for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Sat Jun 20 01:52:21 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F67A1A0046 for ; Sat, 20 Jun 2015 01:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2v2eOiUEH7tD for ; Sat, 20 Jun 2015 01:52:17 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0775.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::775]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EA761A0041 for ; Sat, 20 Jun 2015 01:52:16 -0700 (PDT) Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none; Received: from pc6 (81.151.162.168) by AMXPR07MB053.eurprd07.prod.outlook.com (10.242.67.142) with Microsoft SMTP Server (TLS) id 15.1.195.15; Sat, 20 Jun 2015 08:51:55 +0000 Message-ID: <014201d0ab35$f890cd00$4001a8c0@gateway.2wire.net> From: t.petch To: Kent Watsen , References: <201505221959.t4MJxRHR081289@mainfs.snmp.com> <201506031817.t53IHJit066848@mainfs.snmp.com> <026301d0a29f$852a8340$4001a8c0@gateway.2wire.net> <02fb01d0a42b$33b519c0$4001a8c0@gateway.2wire.net> <032d01d0a5cf$a8cd8940$4001a8c0@gateway.2wire.net> Date: Sat, 20 Jun 2015 09:46:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.162.168] X-ClientProxiedBy: DB4PR05CA0025.eurprd05.prod.outlook.com (25.160.40.35) To AMXPR07MB053.eurprd07.prod.outlook.com (10.242.67.142) X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB053; 2:mA4bqgNvc4qGdZlPawYJJX22tOp7p1hKo8fFMYF9OJClK1AfHSqpD5MGtzPEXJ+L; 3:jM5vEE81W9IgdhHJZyFH+mwiaswMLrJPZPVEnQiR0kBll2JsubgvPiqMj9+ZjMSLxUIChkq0Rh6E+88TFqa6tnmfMcN4YcOsm5sRPpm8WNl3Agr07Z3cXJUAu3EZ1k0bWxf7pmAOVJ/K/t0oFiFUUQ==; 20:la3T19/W+/rItIgcU3/fQ6bVX60Qa0XtG+vaVkN8MqCgitmLm5frVfknsIf2WeFk5/oH501Vy55rM3A7NCH3fg==; 4:TtptiAJs2RTxfvN6fzlV9GCpSQd7BQTVga2Tlbef29CE362kR7f370ugfaHtdaBkBmgEBNw4v43QEHXRbCwXcscEH0h+PB/y1FmeEJviLeuB6nPNQyKyU5YCmW1DaBCSdw+rS5rj5EiyKNYGWLZsmZHh9Rgb2qKmRYSnL0HRrZ+Y+qwffefWO0q4yBZN+eN0oed3kck9sAUNdDjZ2w/s2QwH11JBgL+cvKi5Te7MHpvx+lgb4tqfaA29RK5nrmcxDEBJsAAGI3aR3XkzhZk9uRZzMB8gDhaHvGfxoHpErXo= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB053; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:AMXPR07MB053; BCL:0; PCL:0; RULEID:; SRVR:AMXPR07MB053; X-Forefront-PRVS: 0613912E23 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(377454003)(13464003)(76104003)(164054003)(77156002)(107886002)(42186005)(1556002)(47776003)(5001770100001)(76176999)(122386002)(66066001)(81816999)(23756003)(33646002)(81686999)(50986999)(93886004)(5001960100002)(86362001)(40100003)(189998001)(87976001)(19580395003)(19580405001)(62236002)(5001920100001)(14496001)(230783001)(46102003)(61296003)(84392001)(44716002)(62966003)(92566002)(77096005)(50466002)(50226001)(1456003)(15975445007)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB053; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; AMXPR07MB053; 23:6ZMY9+jFo/u/5X+fGt9nMHZs2XWhNIJdOqlFNM0Q?= =?iso-8859-1?Q?4SNhlziHxs2DAk/IKIUhSm8A5ahh+1hUqJDIFrSglIN8kvVwIRIA09tbB0?= =?iso-8859-1?Q?6fXXwIV/bI0FhWnhG6pffj3+i3pqODgwH98LDsAR9rNm+GaRdBOLeLyYL4?= =?iso-8859-1?Q?erBvrk9E+J3l2aMqlmm1WzgbA86lhC6xMCv3VgGkWTrA6ajywP9fHkUIH6?= =?iso-8859-1?Q?LKW0mwo0GYjLALJq1InU0HYKQmNZUqMBNfw9pXtr5QkLWbaqCzbBfz4ylV?= =?iso-8859-1?Q?JQvvFz+X0X/IBlvE6iniDFquBgDQbJ+GV0WhjAITj5MmPK0KA/Y/IbO/nK?= =?iso-8859-1?Q?UWRAx8Z8yJDAFHgHBGpo5+zrUNSDdMc7jh2+HZ19IhCb4p2dcRrcQqjfT7?= =?iso-8859-1?Q?751r6gnjpnBspPPjgFSJ1rr4247cfs15oXsmceWvDV2Z71fsrupMpvdpcL?= =?iso-8859-1?Q?/IwAya2f0KUy4yrp8J3eOhpULdTUaeEaOZ+mlngssKcqQlHKwKXcT/I9nN?= =?iso-8859-1?Q?7ptXeNHjQn476dQL/tj20yNLiMz5T4lSf70xRddZuHjU4/yxO43BhmmRd5?= =?iso-8859-1?Q?paHFZfqirHCfjJ7vKtK+7OT/oL4598f16SwieJI4mkjiAO6Wo4BTVXLBfp?= =?iso-8859-1?Q?tNJVytPQLJtTBV6LdykmMtdqWpFIud+mTnkwBZkTedLf3eGpNcvfTBcHhI?= =?iso-8859-1?Q?Hp6Dm843IP/DxxjBO0SgRmfnn9fJqY4wWqFwr8RUxE8tyd5pCPGnUKo+ja?= =?iso-8859-1?Q?/D3CxBkLsSLC3oCwnFcags2FWVdkKzyBZXufWhf3IpySdj/UIDg7irFRZa?= =?iso-8859-1?Q?tsCrwGrmzBkfXOk2/SI4O0cRbPi+D+DOTbqrVXyZAaoLCQbE+M9QiI8qZb?= =?iso-8859-1?Q?Vu29DWnxB0miTOas5gm681IHz6OvuLV5OIHOHiNBufrK24O4Fn1Xt7ZDOb?= =?iso-8859-1?Q?b3PBppxWD5i5AqqPA1HlDVhW6GBv9zsogskIegO4XAb8NjkFs17tbOJeAu?= =?iso-8859-1?Q?/E2wtchRsXsP248aPYmcRsSsBFKQLQYEl3OUdfj1NZP0x4W9RkKa6loLMS?= =?iso-8859-1?Q?70FPznQTW0kuSxKNLljSoQbCNuvC0jG6VMgctaIzX/6f2BKTRjwW0bD94H?= =?iso-8859-1?Q?FTd1LIQmepvLA5ULhufjRxL7m2qrVHuxGcd6IM9yXNYPUdFDgvP+T6zczX?= =?iso-8859-1?Q?qui1xmGkHM?= X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB053; 5:sLaZNe5jt55DMijOG6vS/RB0TFCg4q1Z/DJwU0QNuZy8bCntRbxvOibfgulYKjxMULQ4wx+4T+Tc40fpBvcQ5L7uaraM6AVK2K8raB8FMaPgU6M+C6dgOVID+MggCBZnap22jiKNTnqn1EVJCByhcw==; 24:EWeZiJg1o41BhE3CPJso36195Uep0VB7l13ZhCiNwPVz0hcb1+Eq5jx6yh9lDpg70le8W3TQgu4r4rCoiNK61fMohjZYIRDArg4sBcDhWTM=; 20:xdGKssOugtVlhhz7HMLxauQlIUch+jWynDaesUVIAozxCLsBYYt5diX03M0tymqQWNj/uLdnVTn/Djstd3Zz4A== X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jun 2015 08:51:55.0000 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB053 Archived-At: Subject: Re: [Netconf] draft-ietf-netconf-call-home-05.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2015 08:52:20 -0000 And your reference to 5539bis needs updating:-) Tom Petch ----- Original Message ----- From: "t.petch" To: "Kent Watsen" ; "Alan Luchuk" ; Sent: Saturday, June 13, 2015 12:53 PM Subject: Re: [Netconf] draft-ietf-netconf-call-home-05.txt > ----- Original Message ----- > From: "Kent Watsen" > To: "t.petch" ; "Alan Luchuk" ; > > Sent: Friday, June 12, 2015 9:57 PM > > Hi Tom, > > > > >yes but I think worth making explicit, saying something along the lines > >that that for TLS, the scope of authentication is the same as for > >5539bis, namely X.509 certificates while for SSH, any method defined > for > >SSH will do. The current text sort of implies a greater restriction > and > >it is that that I wanted to clarify. > > I tried inserting some text into the Introduction, but there wasn't an > easy way to do it. So I rather ask, where are you picking up this > greater > restriction in the text? > > > Funny you should ask:-) Look at your other post > > "As part of establishing the SSH or TLS connection, the NETCONF/ > RESTCONF server will send its host key or certificate to the > client. " > which to me says it is certificate or it is host key and it cannot be > anything else! Ditto C5 or C7. But if noone else joins in, perhaps best > left as is. > > >>On client authentication by servers, we seem not to require it. > > I added this new section: > > S5 In most cases, establishing the SSH or TLS connection also > entails server authentication of client credentials; only with > RESTCONF do some client authentication schemes occur after the > secure transport connection (TLS) has been established. If > client authentication is required, and the client is unable to > > successfully authenticate itself to the server in an amount of > time defined by local policy, the server SHOULD close the > connection. > > What do you think? > > > I disagree that client auth seems not required, in that it's required by > the draft's normative references: > > > > Perhaps 'MUST close' but otherwise ok. And of course when you know the > References intimately having worked on them since draft-wasserman, then > yes, you will know the requirement for authentication - but I think > there is no harm and some benefit in repeating it here, since the vast > majority of uses of TLS do not call for client authentication - it is us > that is out on a limb here. > > Tom Petch > > > 1. RFC 6241 says "NETCONF connections MUST be authenticated. The > transport protocol is responsible for authentication of the server to > the > client and authentication of the client to the server." > > > 2. RFC6242 says: "The identity of the SSH client MUST also be verified > and > authenticated ..." > > 3. 5539bis says "The NETCONF server MUST verify the identity of the > NETCONF client ..." > > 4. restconf-07 says "The RESTCONF server MUST authenticate client access > ..." > > > I'm hoping that the new S5 and the normative references address your > concern - do they? > > > Thanks, > Kent > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Sat Jun 20 08:29:57 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B45971A1BDB; Sat, 20 Jun 2015 08:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqMSc_4M_FYr; Sat, 20 Jun 2015 08:29:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 196381A1BF1; Sat, 20 Jun 2015 08:29:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150620152954.28627.42869.idtracker@ietfa.amsl.com> Date: Sat, 20 Jun 2015 08:29:54 -0700 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-restconf-06.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2015 15:29:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : RESTCONF Protocol Authors : Andy Bierman Martin Bjorklund Kent Watsen Filename : draft-ietf-netconf-restconf-06.txt Pages : 103 Date : 2015-06-20 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netconf-restconf-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-restconf-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Jun 20 08:46:48 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 536E71A8706 for ; Sat, 20 Jun 2015 08:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IiYvWqx12rK8 for ; Sat, 20 Jun 2015 08:46:45 -0700 (PDT) Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAE0A1A86EA for ; Sat, 20 Jun 2015 08:46:44 -0700 (PDT) Received: by lbbti3 with SMTP id ti3so87236465lbb.1 for ; Sat, 20 Jun 2015 08:46:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=chWdU+ftsWW36MrStfD5B+zXS0PO9Tv6rPnTrNOIWHE=; b=ftgVSiKVHAtuMcAw7K8JKjPn6xL5IPcXZelWEOgxkJx+WtUenkfzcqrbNnmUxHf5q6 2zKuv1MmpxbUuFG0gt77vRmCbnSvkNlZREUWK79u7gkaqrj27t7X+ulgxXk0RWvftBQ/ BtlhPYJnqkPqCdmYvPkERsrotUXyC9M5Ox4oVSyxcm41LJ2RQwj9T7mjocWT363VG5m+ jHNST9dA8sV9GDYvu6hkvGXO3+lR3zHFtMsExGydtzOW1VM/oEWyrt7ESDYMZ4CyGCP+ ncXrDv5UGPZEc5E5t2+Vgq68+/wIeqpf0KBPxMhkOOT5zfdrnxCJtcqR+MsgNmTKLwrA X2Qw== X-Gm-Message-State: ALoCoQk8tBtH2Db2ZjY1oVgWA8DS84Ze9Zj4ZIqW2VXmi2mnn4wjwBDQ9eAHuEri54m59Cy31WO5 MIME-Version: 1.0 X-Received: by 10.152.7.65 with SMTP id h1mr22671278laa.33.1434815203285; Sat, 20 Jun 2015 08:46:43 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Sat, 20 Jun 2015 08:46:43 -0700 (PDT) In-Reply-To: References: <20150608.102005.1482395931170643204.mbj@tail-f.com> <20150608094708.GA28936@elstar.local> <20150608143100.GD29788@elstar.local> <20150608151059.GB30068@elstar.local> <20150610064843.GA36156@elstar.local> Date: Sat, 20 Jun 2015 08:46:43 -0700 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: multipart/alternative; boundary=001a11c27cf082b19a0518f4f2d1 Archived-At: Cc: Netconf Subject: Re: [Netconf] YANG Patch Issue #3: :distinct-startup X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2015 15:46:47 -0000 --001a11c27cf082b19a0518f4f2d1 Content-Type: text/plain; charset=UTF-8 Hi, There does not seem to be any consensus that this needs to be added to RESTCONF. Are there any objections to moving this issue status to 'DEAD', which would mean the NETCONF :startup capability will not be exposed in RESTCONF. Andy On Tue, Jun 16, 2015 at 4:36 PM, Kent Watsen wrote: > > Following up on this, it turns out that our NMS always persists its > updates to the server's NV store, and there are no customer requests to > provide a knob to control that behavior. Even more surprising, JUNOS > does not even support the :distinct-startup (unlike JUNOSe and IOS). > > Possible explanations include: 1) Junos commits are already long, such > that the persistence overhead isn't a big deal, 2) NETCONF clients > typically push a single large , unlike CLI interactions, > hence why operators are not concerned by persistence overhead, and 3) the > desire for operators to test changes before persisting to NVS isn't as > important as I had originally thought. > > As there are no customer requests to change this behavior, I have to take > back my thinking a RESTCONF equivalent to the distinct-startup capability > is important feature. It will be interesting to here from operators on > this, or even other vendors that have collected operator input. > > Kent > > > > On 6/10/15, 6:35 PM, "Kent Watsen" wrote: > > > > > > >On 6/10/15, 4:08 PM, "Andy Bierman" wrote: > > > >>The other use of user-controlled NV-store is that in case the device > >>reboots, > >>it will come back with a known good configuration. If every edit is > >>NV-saved, > >>then there is no chance for the operator to test the changes before > >>changing the startup config. > > > > > >Both are important, but I think that this is the primary use case, with > >performance being a close second. > > > >Case in point, Junos (update: I meant JUNOSe here) CLI has auto-commit on > >by default (i.e. performance > >isn't an issue), but offers what is called Manual Commit mode (service > >manual-commit). I'm trying to collect numbers, but I heard that it's > >still widely used. > > > >Thanks, > >Kent > > > > > > > >_______________________________________________ > >Netconf mailing list > >Netconf@ietf.org > >https://www.ietf.org/mailman/listinfo/netconf > > --001a11c27cf082b19a0518f4f2d1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

There does not seem to be any conse= nsus that this needs to
be added to RESTCONF.

Are there any objections to moving this issue status to 'DEAD'= ;,
which would mean the NETCONF :startup capability will not
be exposed in RESTCONF.



<= /div>
Andy


On Tue, Jun 16, 2015 at 4:36 PM, Kent Watsen <kw= atsen@juniper.net> wrote:
<= br> Following up on this, it turns out that our NMS always persists its
updates to the server's NV store, and there are no customer requests to=
provide a knob to control that behavior.=C2=A0 =C2=A0Even more surprising, = JUNOS
does not even support the :distinct-startup (unlike JUNOSe and IOS).

Possible explanations include: 1) Junos commits are already long, such
that the persistence overhead isn't a big deal, 2) NETCONF clients
typically push a single large <edit-config>, unlike CLI interactions,=
hence why operators are not concerned by persistence overhead, and 3) the desire for operators to test changes before persisting to NVS isn't as<= br> important as I had originally thought.

As there are no customer requests to change this behavior, I have to take back my thinking a RESTCONF equivalent to the distinct-startup capability is important feature.=C2=A0 =C2=A0 It will be interesting to here from oper= ators on
this, or even other vendors that have collected operator input.

Kent



On 6/10/15, 6:35 PM, "Kent Watsen" <kwatsen@juniper.net> wrote:

>
>
>On 6/10/15, 4:08 PM, "Andy Bierman" <andy@yumaworks.com> wrote:
>
>>The other use of user-controlled NV-store is that in case the devic= e
>>reboots,
>>it will come back with a known good configuration.=C2=A0 If every e= dit is
>>NV-saved,
>>then there is no chance for the operator to test the changes before=
>>changing the startup config.
>
>
>Both are important, but I think that this is the primary use case, with=
>performance being a close second.
>
>Case in point, Junos (update: I meant JUNOSe here) CLI has auto-commit = on
>by default (i.e. performance
>isn't an issue), but offers what is called Manual Commit mode (serv= ice
>manual-commit).=C2=A0 I'm trying to collect numbers, but I heard th= at it's
>still widely used.
>
>Thanks,
>Kent
>
>
>
>_______________________________________________
>Netconf mailing list
>Netconf@ietf.org
>https://www.ietf.org/mailman/listinfo/netconf

--001a11c27cf082b19a0518f4f2d1-- From nobody Mon Jun 22 01:58:55 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0911B2E60 for ; Mon, 22 Jun 2015 01:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.811 X-Spam-Level: * X-Spam-Status: No, score=1.811 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVemDxSRpGBp for ; Mon, 22 Jun 2015 01:58:51 -0700 (PDT) Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 4ECC01B2E5F for ; Mon, 22 Jun 2015 01:58:50 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by galileo.mg-soft.si (Postfix) with ESMTP id BA4D6C4175C1 for ; Mon, 22 Jun 2015 10:58:49 +0200 (CEST) Message-ID: <5587CE46.2010000@mg-soft.si> Date: Mon, 22 Jun 2015 10:58:46 +0200 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 CC: netconf@ietf.org References: <20150620152954.28627.42869.idtracker@ietfa.amsl.com> In-Reply-To: <20150620152954.28627.42869.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------010006000602000004090300" Archived-At: Subject: [Netconf] draft-ietf-netconf-restconf-06.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 08:58:54 -0000 This is a multi-part message in MIME format. --------------010006000602000004090300 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi, here's some stuff I noticed while reading the draft. BTW, is there a list of RESTCONF server implementations to test clients against? -- In 4.3. GET [https://tools.ietf.org/html/draft-ietf-netconf-restconf-06#section-4.3]: The client might request the response headers for a JSON representation of the "library" resource the example shows the client is actually requesting and receiving application/yang.data+xml, not JSON (for an "album" resource). -- The query parameter sections claim some parameters MUST be supported, yet 5.1 states all are optional to implement. Is there a way for a server to support but not implement? 4.8.1. The "content" Query Parameter [https://tools.ietf.org/html/draft-ietf-netconf-restconf-06#section-4.8.1] This query parameter MUST be supported by the server. 4.8.4. The "insert" Query Parameter [https://tools.ietf.org/html/draft-ietf-netconf-restconf-06#section-4.8.4] The "insert" query parameter MUST be supported by the server. 4.8.5. The "point" Query Parameter [https://tools.ietf.org/html/draft-ietf-netconf-restconf-06#section-4.8.5] The "point" query parameter MUST be supported by the server. 5.1. Request URI Structure [https://tools.ietf.org/html/draft-ietf-netconf-restconf-06#section-5.1] All query parameters are optional to implement by the server and optional to use by the client. -- In section 7.1. Error Response Message [https://tools.ietf.org/html/draft-ietf-netconf-restconf-06#section-7.1]: The client MAY specify the desired encoding for error messages by specifying the appropriate media-type in the Accept header. If no error media is specified, the server MUST assume that "application/ yang.errors+xml" was specified. All of the examples in this document, except for the one below, assume the default XML encoding will be returned if there is an error. yet the second example in the same section (POST), where the client does not specify an Accept header, is showing the client getting an application/yang.errors+json response. -- In section 9. RESTCONF Monitoring [https://tools.ietf.org/html/draft-ietf-netconf-restconf-06#section-9]: Implementation is mandatory for RESTCONF servers, if any protocol capabilities or event notification streams are supported. and then in section 9.1.2 The "defaults" Protocol Capability URI [https://tools.ietf.org/html/draft-ietf-netconf-restconf-06#section-9.1.2]: This protocol capability URI MUST be supported by the server, and the MUST be listed in the "capability" leaf-list in Section 9.3 . Seem to conflict each other (also note the excess 'the' in latter). Jernej Dne 20.6.2015 ob 17:29 je internet-drafts@ietf.org zapisal(a): > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Network Configuration Working Group of the IETF. > > Title : RESTCONF Protocol > Authors : Andy Bierman > Martin Bjorklund > Kent Watsen > Filename : draft-ietf-netconf-restconf-06.txt > Pages : 103 > Date : 2015-06-20 > > 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. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-netconf-restconf-06 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-restconf-06 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --------------010006000602000004090300 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi,

here's some stuff I noticed while reading the draft. BTW, is there a list of RESTCONF server implementations to test clients against?

--
In 4.3. GET [https://tools.ietf.org/html/draft-ietf-netconf-restconf-06#section-4.3]:
   The client might request the response headers for a JSON
   representation of the "library" resource
the example shows the client is actually requesting and receiving application/yang.data+xml, not JSON (for an "album" resource).

--
The query parameter sections claim some parameters MUST be supported, yet 5.1 states all are optional to implement. Is there a way for a server to support but not implement?

4.8.1. The "content" Query Parameter [https://tools.ietf.org/html/draft-ietf-netconf-restconf-06#section-4.8.1]
   This query parameter MUST be supported by the server.
4.8.4.  The "insert" Query Parameter [https://tools.ietf.org/html/draft-ietf-netconf-restconf-06#section-4.8.4]
   The "insert" query parameter MUST be supported by the server.
4.8.5.  The "point" Query Parameter [https://tools.ietf.org/html/draft-ietf-netconf-restconf-06#section-4.8.5]
   The "point" query parameter MUST be supported by the server.
5.1.  Request URI Structure [https://tools.ietf.org/html/draft-ietf-netconf-restconf-06#section-5.1]
      All query
      parameters are optional to implement by the server and optional to
      use by the client.
--
In section 7.1. Error Response Message [https://tools.ietf.org/html/draft-ietf-netconf-restconf-06#section-7.1]:
   The client MAY specify the desired encoding for error messages by
   specifying the appropriate media-type in the Accept header.  If no
   error media is specified, the server MUST assume that "application/
   yang.errors+xml" was specified.  All of the examples in this
   document, except for the one below, assume the default XML encoding
   will be returned if there is an error.
yet the second example in the same section (POST), where the client does not specify an Accept header, is showing the client getting an application/yang.errors+json response.

--
In section 9. RESTCONF Monitoring [https://tools.ietf.org/html/draft-ietf-netconf-restconf-06#section-9]:
   Implementation is mandatory for RESTCONF
   servers, if any protocol capabilities or event notification streams
   are supported.
and then in section 9.1.2 The "defaults" Protocol Capability URI [https://tools.ietf.org/html/draft-ietf-netconf-restconf-06#section-9.1.2]:
   This protocol capability URI MUST be supported by the server, and the
   MUST be listed in the "capability" leaf-list in Section 9.3.
Seem to conflict each other (also note the excess 'the' in latter).

Jernej

Dne 20.6.2015 ob 17:29 je internet-drafts@ietf.org zapisal(a):
A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Network Configuration Working Group of the IETF.

        Title           : RESTCONF Protocol
        Authors         : Andy Bierman
                          Martin Bjorklund
                          Kent Watsen
	Filename        : draft-ietf-netconf-restconf-06.txt
	Pages           : 103
	Date            : 2015-06-20

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.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-netconf-restconf-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-restconf-06


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

--------------010006000602000004090300-- From nobody Tue Jun 23 11:19:23 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E6F1A7D82; Tue, 23 Jun 2015 11:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXZsj8M9eeam; Tue, 23 Jun 2015 11:19:12 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (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 9DA261A876C; Tue, 23 Jun 2015 11:19:11 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.187.115; From: "Susan Hares" To: , Date: Tue, 23 Jun 2015 14:19:08 -0400 Message-ID: <00d901d0ade1$194280e0$4bc782a0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DA_01D0ADBF.9235C2E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdCt3DMPLBEZlsLhQ3mxKrWQI0Jk+w== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: Rtg-yang-coord@ietf.org, netmod@ietf.org, "'BRUNGARD, DEBORAH A'" , 'Alia Atlas' , "'Alvaro Retana \(aretana\)'" Subject: [Netconf] Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2015 18:19:15 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00DA_01D0ADBF.9235C2E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Netconf Working Group: The I2RS WG would like to pass you a set of requirements for the I2RS protocol, and asks that you provide an analysis by IETF 93 on whether NETCONF or RESTCONF can meet these requirements. We expect that these requirements may require changes to the either NETCONF or RESTCONF. The I2RS architecture document ( draft-ietf-i2rs-architecture-09) provides a high-level overview of the I2RS protocol. The I2RS has compiled the following documents to provide the additional details on the requirements for the protocols. 1) draft-ietf-i2rs-ephemeral-state-00 2) draft-ietf-i2rs-pub-sub-requirements-02 3) draft-ietf-i2rs-traceability-03 The draft-ietf-i2rs-ephemeral-state-00 contains the results of the discussion from the 6/10 interim and the top 10 requirements for I2RS. In addition, the draft-ietf-i2rs-ephemeral-state-00 contains an set of detailed requirements on how the I2RS WG sees the I2RS protocol operating. These detailed requirements are to be seen as suggestions on what type of solution the I2RS WG would like to see, but I2RS WG is asking the NETCONF WG to provide its best designed protocol. Please note as part of these detailed requirement the draft-ietf-i2rs-ephemeral-states-00 contains the idea of using metadata to record secondary identity. The I2RS protocol is driven by data-models. The approved data models for protocol independent services are: - draft-ietf-i2rs-rib-data-model-00 - Filter-Based RIBS: draft-kini-i2rs-fb-rib-data-model.00 (released later this week) - Topology model which is a composite of: o Generic topology model: draft-ietf-i2rs-yang-network-topo-01 o L3 topology model: draft-ietf-i2rs-yang-l3-topology-00 o L2 topology model: draft-ietf-i2rs-yang-l2-network-topology-00 o L1 Topology model: draft-zhang-i2rs-l1-topo-yang-model-01 (-02 released later this week). o Service topology model: draft-hares-i2rs-service-topo-yang-model-00 (released on Wednesday) At this time, none of the Topology models utilize Traffic engineering. It is anticipated that these models will support traffic engineering. Estimated rates of transfer and timing requirements for these modules are at: http://trac.tools.ietf.org/wg/i2rs/trac/wiki - under the protocol requirements table. We hope that NETCONF WG can provide some initial feedback on these requirements by IETF 93 at the Tuesday I2RS session. I2RS will use the 6/24 interim at 10:00-11:30am ET to provide a time for any participate in the I2RS, netconf, or netmod group to ask additional questions on these requirements. Sue Hares Interim time: 10:00-11:30am ET Date 6/24/2015 Webex: https://ietf.webex.com/ietf/j.php?MTID=m4260bee7be61cb17b0008a3c52069d0f agenda: 10:00 - 10:05 - Bash Agenda 10:05 - 10:20- - review of requirements from draft-ietf-i2rs-ephemeral-state-00 draft-ietf-i2rs-pub-sub-requirements-02 draft-ietf-i2rs-traceability-03 Timing requirements 10:20 - 10:30 Review of requirements for mutual authentication, and transaction in draft-hares-auth-trans-01 requirements 10:30- 11:30 Open discussion for I2RS Requirements Proceedings and slides can be found at: http://www.ietf.org/proceedings/interim/2015/06/24/i2rs/proceedings.html Sue Hares ------=_NextPart_000_00DA_01D0ADBF.9235C2E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Netconf = Working Group:

 

The I2RS WG = would like to pass you a set of requirements for the I2RS protocol, and = asks that you provide an analysis by IETF 93 on whether NETCONF or = RESTCONF can meet these requirements.   We expect that these = requirements may require changes to the either NETCONF or = RESTCONF. 

 

The I2RS = architecture document (<= span = style=3D'font-size:11.5pt;color:#3D22B3;background:white;text-decoration:= none'>draft-ietf-i2rs-architecture-09) = provides a high-level overview of the I2RS =  protocol.  The I2RS has compiled the following documents to = provide the additional details on the requirements for the protocols. =

 

1)      draft-ietf-i2rs-ephemeral-state-00 =

2)      draft-ietf-i2rs-pub-sub-requirements-02 =

3)      <= span = style=3D'font-size:11.5pt;color:#3D22B3;background:white;text-decoration:= none'>draft-ietf-i2rs-traceability-03  =

 

The = draft-ietf-i2rs-ephemeral-state-00 contains the results of the = discussion from the 6/10 interim and the top 10 requirements for = I2RS.  In addition, the draft-ietf-i2rs-ephemeral-state-00 contains = an set of detailed requirements on how the I2RS WG sees the I2RS = protocol operating.  These detailed requirements are to be seen as = suggestions on what type of solution the I2RS WG would like to see, but = I2RS WG is asking the NETCONF WG to provide its best designed = protocol.  Please note as part of these detailed requirement the = draft-ietf-i2rs-ephemeral-states-00 contains the idea of using metadata = to record secondary identity.   

 

The I2RS = protocol is driven by data-models.  The approved data models for = protocol independent services are:

-          = draft-ietf-i2rs-rib-data-model-00

-          = Filter-Based RIBS:  draft-kini-i2rs= -fb-rib-data-model.00 (released later this = week)

-          = Topology model = which is a composite of:

o   Generic = topology model: draft-ietf-i2rs-yang-network-topo-01 

o   L3 topology = model: draft-ietf-i2rs-yang-l3-topology-00 =

o   L2 topology = model: draft-ietf-i2rs-yang-l2-network-topology-00 

o   L1 Topology = model: draft-zhang-i2rs-l1-topo-yang-model-01 (-02 = released later this week).

o   Service = topology model: = draft-hares-i2rs-service-topo-yang-model-00 (released on = Wednesday)

 

At this time, none of the Topology models utilize = Traffic engineering.  It is anticipated that these models will = support traffic engineering.  Estimated rates of transfer and = timing requirements for these modules are at: http://trac.tools.i= etf.org/wg/i2rs/trac/wiki - under the protocol requirements table. =

 

We hope that NETCONF WG can provide some initial = feedback on these requirements by IETF 93 at the Tuesday I2RS = session.   I2RS will use the 6/24 interim at 10:00-11:30am ET =  to provide a time for any participate in the I2RS, netconf, or = netmod group to ask additional questions on these requirements. =

 

Sue Hares

 

Interim = time: 10:00-11:30am ET

Date = 6/24/2015

Webex:

https://ietf.webex.com/ietf/j.php?MTID=3Dm4260bee7be61cb17b000= 8a3c52069d0f

 

agenda: =

 

10:00 – 10:05 – Bash = Agenda

10:05 – 10:20- -  = review of requirements from

= draft-ietf-i2rs-ephemeral-state-00

= draft-ietf-i2rs-pub-sub-requirements-02

= draft-ietf-i2rs-traceability-03

Timing requirements =

 

10:20 – 10:30    Review of = requirements for mutual authentication,

and = transaction in  draft-hares-auth-trans-01 requirements =

 

10:30- 11:30     Open discussion = for I2RS Requirements

 

Proceedings = and slides can be found at:

http://www.ietf.org/proceedings/interim/2015/06/24/i2rs/proceedi= ngs.html

 

Sue Hares

 

 

------=_NextPart_000_00DA_01D0ADBF.9235C2E0-- From nobody Tue Jun 23 17:59:22 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF4E1B3305 for ; Tue, 23 Jun 2015 17:59: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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tb6HrSX2YuH for ; Tue, 23 Jun 2015 17:59:19 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0763.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:763]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1ADB1B3304 for ; Tue, 23 Jun 2015 17:59:18 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.1.195.15; Wed, 24 Jun 2015 00:59:02 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.100]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.100]) with mapi id 15.01.0195.005; Wed, 24 Jun 2015 00:59:02 +0000 From: Kent Watsen To: t.p. Thread-Topic: [Netconf] server-model #43: keep-alive, linger, reconnect interval defaults OK? Thread-Index: AQHQalr5OEpeLICj8UOqu96zVYFF7Z00eRaAgEekRwCAM1NdWoALqW6A Date: Wed, 24 Jun 2015 00:59:02 +0000 Message-ID: References: <201503300503.t2U53jqh084141@idle.juniper.net> <009701d0a822$552532c0$4001a8c0@gateway.2wire.net> In-Reply-To: <009701d0a822$552532c0$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: btconnect.com; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.12] x-microsoft-exchange-diagnostics: 1; CO1PR05MB460; 5:KOWEgIj0j79GWcnfmHAR0L1pqAUni0AXb+u+SJoYfzAtQV6jIhtFlSZNfoUT0V0RuB5ptkq96hYKy4cMnccq5WoxsGmnl0qNc8LYa9K1U24Wrxb+uXVHTK7iQcsY21gDMz06BcSRmuhD2O0Q2aEhMQ==; 24:Ke/kphraPj8zacrK8Uy5nA+THjyPITLw9NBsgFm3jAxgbpluLfuTz4nnZDslSG3M9zUn4zZG+nWI/2t+RXN+o4+mq/VtguSVW00hjHVA8BM=; 20:lqO2CgiaRtgjI2lD11J252mzFlLtA4rmjVCgPgFzBskKi074NwePahuFmBbeS3DYACyQreDd1CTbIfItWHaRpg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB460; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CO1PR05MB460; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB460; x-forefront-prvs: 061725F016 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(164054003)(122556002)(5001960100002)(36756003)(5002640100001)(62966003)(110136002)(77156002)(40100003)(4001350100001)(189998001)(2900100001)(102836002)(92566002)(2950100001)(106116001)(50986999)(76176999)(54356999)(46102003)(99286002)(93886004)(87936001)(2656002)(86362001)(83506001)(66066001)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <9AF5072ACA18A64ABBC2E080D1C52955@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2015 00:59:02.1435 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB460 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] server-model #43: keep-alive, linger, reconnect interval defaults OK? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2015 00:59:20 -0000 >Kent: >> This timer is to test the aliveness of the connection. Sure, >> if the NMS doesn't respond in time, the device tears down that >> connection in hope to find a connection the works better. 45 >> seconds seems too short to you, and 15 minutes seems too long >> to me. How about 5 minutes for the default? Anyone else have >> an opinion? TP: > I would rather we did not put in a default but something along > these lines, that it depends how quickly a failure needs to be > detected to meet the required service. The count of three > attempts before declaring failure is, by contrast, almost > universal so I have no qualms there. This implies failures > are detected in three to four times the interval. > > If forced to put in a default time, I would go for 30S with a > caveat that this should be reviewed in the light of how much > traffic this will generate - it is very dependent of network > size. I much rather keep it small as well. It's actually 15 seconds currently (3*15=3D45), but I'll bump it up to 30 seconds per your recommendation... Thanks, Kent From nobody Wed Jun 24 14:14:58 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4E21B2E35; Wed, 24 Jun 2015 14:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxgUbkt6ap-e; Wed, 24 Jun 2015 14:14:52 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id CA6961B2E3A; Wed, 24 Jun 2015 14:14:51 -0700 (PDT) Received: from localhost (unknown [173.38.220.38]) by mail.tail-f.com (Postfix) with ESMTPSA id 3B8FB1AE06C0; Wed, 24 Jun 2015 23:14:50 +0200 (CEST) Date: Wed, 24 Jun 2015 23:14:49 +0200 (CEST) Message-Id: <20150624.231449.697617442831847315.mbj@tail-f.com> To: netmod@ietf.org, 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] Y45-04 and ietf-yang-library X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2015 21:14:55 -0000 Hi, I am preparing a new version of draft-ietf-netmod-rfc6020bis in order to address Y45-04. Note that YANG 1.1 uses the module ietf-yang-library from draft-ietf-netconf-yang-library (hence the crossposting). [BTW, shouldn't ietf-yang-library be moved to NETMOD?] We have a whole bunch of documents that have a normative reference to draft-ietf-netmod-rfc6020bis, which has a normative reference to draft-ietf-netconf-yang-library. This means we need to finish this document pretty soon. I ran into some issues with ietf-yang-library: 1. The leaf "conformance" is of type "boolean". It is not obvious what "conformance = false" means. Should we change the name and/or type of this leaf? I don't have a good proposal, but what we need is a way to indicate "I implement the protocol accessible nodes in this module" vs. "I just list this module b/c some other module that I implement uses typdefs/groupings/... from it". This issue is related to the github issue #3. I think we need this information; Y45-04 relies on it. 2. The "/modules/module" list is keyed by "name" and "revision". Should we really have "revision" as key? A server can only implement one revision of a module, and should only list one revision of a module w/ conformance = false. I suggest we make this leaf mandatory, and not part of the key. /martin From nobody Wed Jun 24 14:31:18 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B06901B2E53 for ; Wed, 24 Jun 2015 14:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nQcRZ5iz6S2 for ; Wed, 24 Jun 2015 14:31:11 -0700 (PDT) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B33CE1B2E4F for ; Wed, 24 Jun 2015 14:31:01 -0700 (PDT) Received: by lbnk3 with SMTP id k3so34236525lbn.1 for ; Wed, 24 Jun 2015 14:31:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tBw5uWu9vCiu+nXISYDUDohLwTHc5ocGpLSN7fDifjA=; b=I558VG3MrJ05HzjAWPKpJPhbS2TL8ZC+DyXcfXckhGRkI3mquxse1WVMTmXJhzxYC7 Tb+Y9Uc0vrceyD+Sqhjbn4Kk+RuDej5Ik2rUPETKRGnf8wXZB1M9Ulsgeu24WpMlUqcT ERWvTou5j4t9P1YG10h2JfJz0snpuh/7lpI2hk11zbmjDpUQa7qennc//2W6/mMPHcvH EopDVf0qWgronPyGsCkAVUTeJOGn5BSOWio0xSpY3l6wwe9xAri+z4GpEDqNcISNTE7/ 6gWnun/i7marplDi60VoSunuUEXLANrdcTSSEOEJ9u83P6ycn8C/98eY0ul8Lr/CmrvV y2Zw== X-Gm-Message-State: ALoCoQkpf5+D/DVIO35woCXRpbEk89X+NIaORZh4wnNRtTT3Dl0LXmnWcAQdhfZe99cz1ev1FNyM MIME-Version: 1.0 X-Received: by 10.152.43.69 with SMTP id u5mr41253244lal.119.1435181460132; Wed, 24 Jun 2015 14:31:00 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Wed, 24 Jun 2015 14:31:00 -0700 (PDT) In-Reply-To: <20150624.231449.697617442831847315.mbj@tail-f.com> References: <20150624.231449.697617442831847315.mbj@tail-f.com> Date: Wed, 24 Jun 2015 14:31:00 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11c366601eac2b05194a3981 Archived-At: Cc: Netconf , "netmod@ietf.org" Subject: Re: [Netconf] [netmod] Y45-04 and ietf-yang-library X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2015 21:31:13 -0000 --001a11c366601eac2b05194a3981 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 24, 2015 at 2:14 PM, Martin Bjorklund wrote: > Hi, > > I am preparing a new version of draft-ietf-netmod-rfc6020bis in order > to address Y45-04. Note that YANG 1.1 uses the module > ietf-yang-library from draft-ietf-netconf-yang-library (hence the > crossposting). > > [BTW, shouldn't ietf-yang-library be moved to NETMOD?] > > We have a whole bunch of documents that have a normative reference to > draft-ietf-netmod-rfc6020bis, which has a normative reference to > draft-ietf-netconf-yang-library. This means we need to finish this > document pretty soon. > > I ran into some issues with ietf-yang-library: > > 1. The leaf "conformance" is of type "boolean". It is not obvious > what "conformance = false" means. Should we change the name > and/or type of this leaf? > > I don't have a good proposal, but what we need is a way to > indicate "I implement the protocol accessible nodes in this > module" vs. "I just list this module b/c some other module that > I implement uses typdefs/groupings/... from it". > > This issue is related to the github issue #3. I think we need > this information; Y45-04 relies on it. > > We went through this before and you didn't have a better suggestion last time either. conformance=false means the server is not claiming conformance for this module. A NETCONF should not have any modules tagged as conformance=false. CoMI relies on this module as well. It has been ready for WGLC since January. > > 2. The "/modules/module" list is keyed by "name" and "revision". > Should we really have "revision" as key? A server can only > implement one revision of a module, and should only list one > revision of a module w/ conformance = false. I suggest we make > this leaf mandatory, and not part of the key. > I am not in favor of this change. Two modules "foo" and "bar" released on the same date could not be represented. I think the indexing is fine in the current draft. The operation in NETCONF and RESTCONF need the module name and the revision-date. This module should not care how many revisions of each module are listed. This is the full YANG library, not a message. > > /martin > > Andy > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a11c366601eac2b05194a3981 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jun 24, 2015 at 2:14 PM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Hi,

I am preparing a new version of draft-ietf-netmod-rfc6020bis in order
to address Y45-04.=C2=A0 Note that YANG 1.1 uses the module
ietf-yang-library from draft-ietf-netconf-yang-library (hence the
crossposting).

[BTW, shouldn't ietf-yang-library be moved to NETMOD?]

We have a whole bunch of documents that have a normative reference to
draft-ietf-netmod-rfc6020bis, which has a normative reference to
draft-ietf-netconf-yang-library.=C2=A0 This means we need to finish this document pretty soon.

I ran into some issues with ietf-yang-library:

=C2=A0 1.=C2=A0 The leaf "conformance" is of type "boolean&q= uot;.=C2=A0 It is not obvious
=C2=A0 =C2=A0 =C2=A0 what "conformance =3D false" means.=C2=A0 Sh= ould we change the name
=C2=A0 =C2=A0 =C2=A0 and/or type of this leaf?

=C2=A0 =C2=A0 =C2=A0 I don't have a good proposal, but what we need is = a way to
=C2=A0 =C2=A0 =C2=A0 indicate "I implement the protocol accessible nod= es in this
=C2=A0 =C2=A0 =C2=A0 module" vs. "I just list this module b/c som= e other module that
=C2=A0 =C2=A0 =C2=A0 I implement uses typdefs/groupings/... from it".<= br>
=C2=A0 =C2=A0 =C2=A0 This issue is related to the github issue #3.=C2=A0 I = think we need
=C2=A0 =C2=A0 =C2=A0 this information; Y45-04 relies on it.



We went through this be= fore and you didn't have a better suggestion last
time either= .

conformance=3Dfalse means the server is not clai= ming conformance for this
module.=C2=A0 A NETCONF <hello> s= hould not have any modules tagged
as conformance=3Dfalse.

CoMI relies on this module as well.=C2=A0
It ha= s been ready for WGLC since January.


=C2=A0

=C2=A0 2.=C2=A0 The "/modules/module" list is keyed by "name= " and "revision".
=C2=A0 =C2=A0 =C2=A0 Should we really have "revision" as key?=C2= =A0 A server can only
=C2=A0 =C2=A0 =C2=A0 implement one revision of a module, and should only li= st one
=C2=A0 =C2=A0 =C2=A0 revision of a module w/ conformance =3D false.=C2=A0 I= suggest we make
=C2=A0 =C2=A0 =C2=A0 this leaf mandatory, and not part of the key.


I am not in favor of this change= .
Two modules "foo" and "bar" released on the= same date
could not be represented.

I t= hink the indexing is fine in the current draft.
The <get-schem= a> operation in NETCONF and RESTCONF need
the module name and = the revision-date.

This module should not care how= many revisions of each module
are listed.=C2=A0 This is the full= YANG library, not a <hello> message.

=C2=A0=
=C2=A0

/martin


Andy

=C2=A0



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

--001a11c366601eac2b05194a3981-- From nobody Thu Jun 25 01:14:32 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4181B31FD; Thu, 25 Jun 2015 01:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSBumtviz7HK; Thu, 25 Jun 2015 01:14:28 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC361B322A; Thu, 25 Jun 2015 01:14:20 -0700 (PDT) Received: from localhost (h-85-24-195-9.na.cust.bahnhof.se [85.24.195.9]) by mail.tail-f.com (Postfix) with ESMTPSA id ED4761AE046E; Thu, 25 Jun 2015 10:14:17 +0200 (CEST) Date: Thu, 25 Jun 2015 10:14:17 +0200 (CEST) Message-Id: <20150625.101417.2199972820527866360.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20150624.231449.697617442831847315.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [Netconf] [netmod] Y45-04 and ietf-yang-library X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2015 08:14:29 -0000 Andy Bierman wrote: > On Wed, Jun 24, 2015 at 2:14 PM, Martin Bjorklund wrote: > > > Hi, > > > > I am preparing a new version of draft-ietf-netmod-rfc6020bis in order > > to address Y45-04. Note that YANG 1.1 uses the module > > ietf-yang-library from draft-ietf-netconf-yang-library (hence the > > crossposting). > > > > [BTW, shouldn't ietf-yang-library be moved to NETMOD?] > > > > We have a whole bunch of documents that have a normative reference to > > draft-ietf-netmod-rfc6020bis, which has a normative reference to > > draft-ietf-netconf-yang-library. This means we need to finish this > > document pretty soon. > > > > I ran into some issues with ietf-yang-library: > > > > 1. The leaf "conformance" is of type "boolean". It is not obvious > > what "conformance = false" means. Should we change the name > > and/or type of this leaf? > > > > I don't have a good proposal, but what we need is a way to > > indicate "I implement the protocol accessible nodes in this > > module" vs. "I just list this module b/c some other module that > > I implement uses typdefs/groupings/... from it". > > > > This issue is related to the github issue #3. I think we need > > this information; Y45-04 relies on it. > > > > > > We went through this before and you didn't have a better suggestion last > time either. > > conformance=false means the server is not claiming conformance for this > module. Yes I know. I just wish we had a better name for this. But you're right, if we can't come up with a better term, we'll stick to what we have. > A NETCONF should not have any modules tagged > as conformance=false. > > CoMI relies on this module as well. > It has been ready for WGLC since January. > > > > > > > > 2. The "/modules/module" list is keyed by "name" and "revision". > > Should we really have "revision" as key? A server can only > > implement one revision of a module, and should only list one > > revision of a module w/ conformance = false. I suggest we make > > this leaf mandatory, and not part of the key. > > > > > I am not in favor of this change. > Two modules "foo" and "bar" released on the same date > could not be represented. The name of the module would be the (single) key, so this should be possible. > I think the indexing is fine in the current draft. > The operation in NETCONF and RESTCONF need > the module name and the revision-date. Yes, revision must be mandatory. > This module should not care how many revisions of each module > are listed. This is the full YANG library, not a message. The whole point of this module is to replace the message! It first came up in RESTCONF, and we want to use it also in NETCONF in order to have one single way to do YANG module advertisement regardless of protocol. There is already the schema list in ietf-netconf-monitoring that gives you the full set of modules and submodules used in a server. /martin From nobody Thu Jun 25 05:50:13 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB6D1A1BC6 for ; Thu, 25 Jun 2015 05:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQf_EWV_S1gj for ; Thu, 25 Jun 2015 05:50:04 -0700 (PDT) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) (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 15A6F1A1BB8 for ; Thu, 25 Jun 2015 05:50:04 -0700 (PDT) Received: by lbnk3 with SMTP id k3so44834758lbn.1 for ; Thu, 25 Jun 2015 05:50:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=VP6Hc7feZP6AaZ2Sh93ZoItLkoH5+fn1I3axoagI9C8=; b=dkDN5fGf14XsMZCKSK7+xGOKZ/Y1smnZicEOqxlGgBIC+QxrSZZ5FoCTKTyIczzz+p xBNXnr7N2oWm0ZeXuvEO3IoaiWeBxEaNLTlr0aOI9N+GeHatr4/Ue/NoNqVOrGjVoB37 W4kNBMefQYLl4LADV/LCaxjj4Xua72VB4765/MxmxWBG9Ksd+Q2A8lXpmmeUzaFyN3wS bNUEqlDLP12xi9ElcadBggXgaWQLO3WbhEytD3Ejg7NHO+zqHhLgpDPp7ssgnw04eE25 IMvPl6g9OiCnMq8y4RjabntKHaHNEmRHU8T+KtHUUgGrXpZh/Q832dFaDfPs4nok65AU pZiw== X-Gm-Message-State: ALoCoQlNoZ3FzDnFt5GclXpcNrZ1YD8CfHHISn0vV0KrOm6hX6QmP6osAllcHgCxdEUo1bvnPybq MIME-Version: 1.0 X-Received: by 10.112.24.71 with SMTP id s7mr43691152lbf.37.1435236602564; Thu, 25 Jun 2015 05:50:02 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Thu, 25 Jun 2015 05:50:02 -0700 (PDT) In-Reply-To: <20150625.101417.2199972820527866360.mbj@tail-f.com> References: <20150624.231449.697617442831847315.mbj@tail-f.com> <20150625.101417.2199972820527866360.mbj@tail-f.com> Date: Thu, 25 Jun 2015 05:50:02 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11343832dd6a390519570fbe Archived-At: Cc: Netconf , "netmod@ietf.org" Subject: Re: [Netconf] [netmod] Y45-04 and ietf-yang-library X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2015 12:50:10 -0000 --001a11343832dd6a390519570fbe Content-Type: text/plain; charset=UTF-8 On Thu, Jun 25, 2015 at 1:14 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Wed, Jun 24, 2015 at 2:14 PM, Martin Bjorklund > wrote: > > > > > Hi, > > > > > > I am preparing a new version of draft-ietf-netmod-rfc6020bis in order > > > to address Y45-04. Note that YANG 1.1 uses the module > > > ietf-yang-library from draft-ietf-netconf-yang-library (hence the > > > crossposting). > > > > > > [BTW, shouldn't ietf-yang-library be moved to NETMOD?] > > > > > > We have a whole bunch of documents that have a normative reference to > > > draft-ietf-netmod-rfc6020bis, which has a normative reference to > > > draft-ietf-netconf-yang-library. This means we need to finish this > > > document pretty soon. > > > > > > I ran into some issues with ietf-yang-library: > > > > > > 1. The leaf "conformance" is of type "boolean". It is not obvious > > > what "conformance = false" means. Should we change the name > > > and/or type of this leaf? > > > > > > I don't have a good proposal, but what we need is a way to > > > indicate "I implement the protocol accessible nodes in this > > > module" vs. "I just list this module b/c some other module that > > > I implement uses typdefs/groupings/... from it". > > > > > > This issue is related to the github issue #3. I think we need > > > this information; Y45-04 relies on it. > > > > > > > > > > We went through this before and you didn't have a better suggestion last > > time either. > > > > conformance=false means the server is not claiming conformance for this > > module. > > Yes I know. I just wish we had a better name for this. But you're > right, if we can't come up with a better term, we'll stick to what we > have. > > > A NETCONF should not have any modules tagged > > as conformance=false. > > > > CoMI relies on this module as well. > > It has been ready for WGLC since January. > > > > > > > > > > > > > > 2. The "/modules/module" list is keyed by "name" and "revision". > > > Should we really have "revision" as key? A server can only > > > implement one revision of a module, and should only list one > > > revision of a module w/ conformance = false. I suggest we make > > > this leaf mandatory, and not part of the key. > > > > > > > > > I am not in favor of this change. > > Two modules "foo" and "bar" released on the same date > > could not be represented. > > The name of the module would be the (single) key, so this should be > possible. > > This does not work. > > I think the indexing is fine in the current draft. > > The operation in NETCONF and RESTCONF need > > the module name and the revision-date. > > Yes, revision must be mandatory. > Unless revision is the key then only 1 revision of the module is possible. > > > This module should not care how many revisions of each module > > are listed. This is the full YANG library, not a message. > > The whole point of this module is to replace the message! It > first came up in RESTCONF, and we want to use it also in NETCONF in > order to have one single way to do YANG module advertisement > regardless of protocol. > > There is already the schema list in ietf-netconf-monitoring that gives > you the full set of modules and submodules used in a server. > > We already discussed relation to the schema list and decided to ignore it. The whole point of this library is to provide the full list of YANG modules and submodules on the device. I strongly object to changing this module. IMO it is quite clear how to fill in the list of modules. > > > /martin > Andy --001a11343832dd6a390519570fbe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jun 25, 2015 at 1:14 AM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Wed, Jun 24, 2015 at 2:14 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Hi,
> >
> > I am preparing a new version of draft-ietf-netmod-rfc6020bis in o= rder
> > to address Y45-04.=C2=A0 Note that YANG 1.1 uses the module
> > ietf-yang-library from draft-ietf-netconf-yang-library (hence the=
> > crossposting).
> >
> > [BTW, shouldn't ietf-yang-library be moved to NETMOD?]
> >
> > We have a whole bunch of documents that have a normative referenc= e to
> > draft-ietf-netmod-rfc6020bis, which has a normative reference to<= br> > > draft-ietf-netconf-yang-library.=C2=A0 This means we need to fini= sh this
> > document pretty soon.
> >
> > I ran into some issues with ietf-yang-library:
> >
> >=C2=A0 =C2=A01.=C2=A0 The leaf "conformance" is of type = "boolean".=C2=A0 It is not obvious
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0what "conformance =3D false" = means.=C2=A0 Should we change the name
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0and/or type of this leaf?
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0I don't have a good proposal, but w= hat we need is a way to
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0indicate "I implement the protocol= accessible nodes in this
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0module" vs. "I just list this= module b/c some other module that
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0I implement uses typdefs/groupings/... = from it".
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0This issue is related to the github iss= ue #3.=C2=A0 I think we need
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0this information; Y45-04 relies on it.<= br> > >
> >
>
> We went through this before and you didn't have a better suggestio= n last
> time either.
>
> conformance=3Dfalse means the server is not claiming conformance for t= his
> module.

Yes I know.=C2=A0 I just wish we had a better name for this.=C2=A0 But you&= #39;re
right, if we can't come up with a better term, we'll stick to what = we
have.

> A NETCONF <hello> should not have any modules tagged
> as conformance=3Dfalse.
>
> CoMI relies on this module as well.
> It has been ready for WGLC since January.
>
>
>
>
> >
> >=C2=A0 =C2=A02.=C2=A0 The "/modules/module" list is keye= d by "name" and "revision".
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Should we really have "revision&qu= ot; as key?=C2=A0 A server can only
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0implement one revision of a module, and= should only list one
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0revision of a module w/ conformance =3D= false.=C2=A0 I suggest we make
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0this leaf mandatory, and not part of th= e key.
> >
>
>
> I am not in favor of this change.
> Two modules "foo" and "bar" released on the same d= ate
> could not be represented.

The name of the module would be the (single) key, so this should be
possible.



This does not work.

=C2=A0
> I think the indexing is fine in the current draft.
> The <get-schema> operation in NETCONF and RESTCONF need
> the module name and the revision-date.

Yes, revision must be mandatory.

Unless= revision is the key then only 1 revision of the module is possible.
<= div>
=C2=A0

> This module should not care how many revisions of each module
> are listed.=C2=A0 This is the full YANG library, not a <hello> m= essage.

The whole point of this module is to replace the <hello> message!=C2= =A0 It
first came up in RESTCONF, and we want to use it also in NETCONF in
order to have one single way to do YANG module advertisement
regardless of protocol.

There is already the schema list in ietf-netconf-monitoring that gives
you the full set of modules and submodules used in a server.



We already discussed relation to the = schema list and decided to ignore it.
The whole point of this lib= rary is to provide the full list of YANG modules
and submodules o= n the device.

I strongly object to changing this m= odule.
IMO it is quite clear how to fill in the list of modules.<= /div>



=C2=A0


/martin


<= /div>
Andy

--001a11343832dd6a390519570fbe-- From nobody Thu Jun 25 06:06:04 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD8DD1A8798 for ; Thu, 25 Jun 2015 06:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uM2x8p_QUm3S for ; Thu, 25 Jun 2015 06:06:01 -0700 (PDT) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 354021A878E for ; Thu, 25 Jun 2015 06:06:01 -0700 (PDT) Received: by lbbwc1 with SMTP id wc1so45103283lbb.2 for ; Thu, 25 Jun 2015 06:05:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GO7nALE+H9GJyBsYVt7CWKAff6WP8ZMaVoQ5SH0QkrI=; b=Oy1HJTfrI+yRhp7j5fzGzzEazcs1noRHlvJcD8ucXGxsBp7PmYZan6akvBmQNhIT8B 2afDGkDS7YtdlALJxe4pbY0O17LEqSjEjg332b0NSfaoj8V5/1ZYpgVR3EKxtfXvMs+h 5KnChyI/pMGwHeQ+5399tDNd1/Po3quMubRuH0JDfLG7Xgn0TwNF/xCjEhSsERW57wIW +w3XRDU/iwvC7MTrfqjAF46fpg7zrQXDbTfdsdzqsnq0T6+n0ueyxA8hQyWgMdXMbyJx nnXkND4T0cL5AsWuqaF0rniOfOrVjiu4GaQbEu/jdpxTRkma382U0J7JjujCHv9TZabF VFtA== X-Gm-Message-State: ALoCoQnWreoOhYAi27rP58mLImeOdzsklz+gbi0nKNXj4Bgy26al6ZcM3Z9Kfumjdy5TBURmqK/b MIME-Version: 1.0 X-Received: by 10.152.7.65 with SMTP id h1mr11393370laa.33.1435237559514; Thu, 25 Jun 2015 06:05:59 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Thu, 25 Jun 2015 06:05:59 -0700 (PDT) In-Reply-To: <20150625.101417.2199972820527866360.mbj@tail-f.com> References: <20150624.231449.697617442831847315.mbj@tail-f.com> <20150625.101417.2199972820527866360.mbj@tail-f.com> Date: Thu, 25 Jun 2015 06:05:59 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11c27cf0e755190519574876 Archived-At: Cc: Netconf , "netmod@ietf.org" Subject: Re: [Netconf] [netmod] Y45-04 and ietf-yang-library X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2015 13:06:02 -0000 --001a11c27cf0e755190519574876 Content-Type: text/plain; charset=UTF-8 > > ..... > There is already the schema list in ietf-netconf-monitoring that gives > you the full set of modules and submodules used in a server. > > > This is not true. --ro schemas | +--ro schema* [identifier version format] | +--ro identifier string | +--ro version string | +--ro format identityref | +--ro namespace inet:uri | +--ro location* union There is no way to tell a submodule from a module in RFC 6022. There is no way to tell which submodules go with which modules. There is no way to identify deviation files. So this 'schema' list does not work for RESTCONF or CoMI. That is 1 reason it was rejected and the ietf-yang-library module is being used instead. It is very useful for a client to be able to scan 1 table and find out all the YANG files used by the server, and then use to retrieve any files missing from the client. IMO the message issue is misguided because the size of the hello message is not really a bottleneck anywhere. Even 1000 YANG modules would be less than 100K in a message. > /martin > Andy --001a11c27cf0e755190519574876 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
.....
There is already the schema list in ietf-netconf-monitoring that gives
you the full set of modules and submodules used in a server.



This is not true.
<= div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0--ro schemas
=C2=A0= =C2=A0 =C2=A0 | =C2=A0+--ro schema* [identifier version format]
= =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 +--ro identifier =C2=A0 =C2=A0string
=C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 +--ro version =C2=A0 =C2=A0 = =C2=A0 string
=C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 +--ro format = =C2=A0 =C2=A0 =C2=A0 =C2=A0identityref
=C2=A0 =C2=A0 =C2=A0 | =C2= =A0 =C2=A0 +--ro namespace =C2=A0 =C2=A0 inet:uri
=C2=A0 =C2=A0 = =C2=A0 | =C2=A0 =C2=A0 +--ro location* =C2=A0 =C2=A0 union
=C2=A0=


There is no way to tell a subm= odule from a module in RFC 6022.
There is no way to tell which su= bmodules go with which modules.
There is no way to identify devia= tion files.
So this 'schema' list does not work for RESTC= ONF or CoMI.
That is 1 reason it was rejected and the ietf-yang-l= ibrary module
is being used instead.

It = is very useful for a client to be able to scan 1 table and find out
all the YANG files used by the server, and then use <get-schema>
to retrieve any files missing from the client.

IMO the <hello> message issue is misguided because the size of = the
hello message is not really a bottleneck anywhere.=C2=A0 Even= 1000 YANG modules
would be less than 100K in a <hello> mes= sage.


=
/martin

Andy<= /div>

--001a11c27cf0e755190519574876-- From nobody Thu Jun 25 12:33:39 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ADD21ACD4F; Thu, 25 Jun 2015 12:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDYUf7AhtFZ8; Thu, 25 Jun 2015 12:33:34 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A74941ACD96; Thu, 25 Jun 2015 12:33:09 -0700 (PDT) Received: from localhost (h-85-24-195-9.na.cust.bahnhof.se [85.24.195.9]) by mail.tail-f.com (Postfix) with ESMTPSA id 17D9D1AE0981; Thu, 25 Jun 2015 21:33:08 +0200 (CEST) Date: Thu, 25 Jun 2015 21:33:07 +0200 (CEST) Message-Id: <20150625.213307.987589961886974156.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20150625.101417.2199972820527866360.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [Netconf] [netmod] Y45-04 and ietf-yang-library X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2015 19:33:36 -0000 Andy Bierman wrote: > On Thu, Jun 25, 2015 at 1:14 AM, Martin Bjorklund wrote: > > > Andy Bierman wrote: > > > On Wed, Jun 24, 2015 at 2:14 PM, Martin Bjorklund > > wrote: > > > > > > > Hi, > > > > > > > > I am preparing a new version of draft-ietf-netmod-rfc6020bis in order > > > > to address Y45-04. Note that YANG 1.1 uses the module > > > > ietf-yang-library from draft-ietf-netconf-yang-library (hence the > > > > crossposting). > > > > > > > > [BTW, shouldn't ietf-yang-library be moved to NETMOD?] > > > > > > > > We have a whole bunch of documents that have a normative reference to > > > > draft-ietf-netmod-rfc6020bis, which has a normative reference to > > > > draft-ietf-netconf-yang-library. This means we need to finish this > > > > document pretty soon. > > > > > > > > I ran into some issues with ietf-yang-library: > > > > > > > > 1. The leaf "conformance" is of type "boolean". It is not obvious > > > > what "conformance = false" means. Should we change the name > > > > and/or type of this leaf? > > > > > > > > I don't have a good proposal, but what we need is a way to > > > > indicate "I implement the protocol accessible nodes in this > > > > module" vs. "I just list this module b/c some other module that > > > > I implement uses typdefs/groupings/... from it". > > > > > > > > This issue is related to the github issue #3. I think we need > > > > this information; Y45-04 relies on it. > > > > > > > > > > > > > > We went through this before and you didn't have a better suggestion last > > > time either. > > > > > > conformance=false means the server is not claiming conformance for this > > > module. > > > > Yes I know. I just wish we had a better name for this. But you're > > right, if we can't come up with a better term, we'll stick to what we > > have. > > > > > A NETCONF should not have any modules tagged > > > as conformance=false. > > > > > > CoMI relies on this module as well. > > > It has been ready for WGLC since January. > > > > > > > > > > > > > > > > > > > > 2. The "/modules/module" list is keyed by "name" and "revision". > > > > Should we really have "revision" as key? A server can only > > > > implement one revision of a module, and should only list one > > > > revision of a module w/ conformance = false. I suggest we make > > > > this leaf mandatory, and not part of the key. > > > > > > > > > > > > > I am not in favor of this change. > > > Two modules "foo" and "bar" released on the same date > > > could not be represented. > > > > The name of the module would be the (single) key, so this should be > > possible. > > > > > > This does not work. > > > > > > I think the indexing is fine in the current draft. > > > The operation in NETCONF and RESTCONF need > > > the module name and the revision-date. > > > > Yes, revision must be mandatory. > > > > Unless revision is the key then only 1 revision of the module is possible. Correct. We agreed that a server cannot implement more than one version of a module (i.e., conformance = true). And the reason for listing other modules (conformance = false) is for the client to learn which revision of such a module is used by the server in modules that import them without revision. Again, there must only be one such revision. An example might help. Suppose we have a typedef only module "t", and three modules "a", "b", and "c" importing it: module a { ... import t { prefix t; // note: no revision-date } ... } module b { ... import t { prefix t; revision-date 2015-01-01; } ... } module c { ... import t { prefix t; revision-date 2015-02-02; } ... } module t { ... revision 2015-02-02; revision 2015-01-01; ... } Now the server lists in ietf-yang-library: modules: module: name: t revision: 2015-01-01; conformance: false module: name: t revision: 2015-02-02; conformance: false ... A client downloads all modules from the server. Now, how can the client tell which revsion of "t" was used to implement "a"? I can se two solutions: 1. Just list one revision of "t" - the one used to implement module "a" (and any other module that imports "t" w/o revision). There really is no reason to list the other revsion of "t". 2. List both revisions of "t", but mark the one that is used to implement module "a" in some way. > > > This module should not care how many revisions of each module > > > are listed. This is the full YANG library, not a message. > > > > The whole point of this module is to replace the message! It > > first came up in RESTCONF, and we want to use it also in NETCONF in > > order to have one single way to do YANG module advertisement > > regardless of protocol. > > > > There is already the schema list in ietf-netconf-monitoring that gives > > you the full set of modules and submodules used in a server. > > > > > > We already discussed relation to the schema list and decided to ignore it. > The whole point of this library is to provide the full list of YANG modules > and submodules on the device. > > I strongly object to changing this module. > IMO it is quite clear how to fill in the list of modules. Yes it is clear. I argue that it the information is provides is not sufficient to solve the advertisement problem. /martin From nobody Thu Jun 25 12:37:30 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 947191ACD03; Thu, 25 Jun 2015 12:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id veUIEEOvRsfF; Thu, 25 Jun 2015 12:37:28 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 757241ACCFC; Thu, 25 Jun 2015 12:37:28 -0700 (PDT) Received: from localhost (h-85-24-195-9.na.cust.bahnhof.se [85.24.195.9]) by mail.tail-f.com (Postfix) with ESMTPSA id 8B8861AE0981; Thu, 25 Jun 2015 21:37:27 +0200 (CEST) Date: Thu, 25 Jun 2015 21:37:27 +0200 (CEST) Message-Id: <20150625.213727.1996609386257583091.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20150625.101417.2199972820527866360.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [Netconf] [netmod] Y45-04 and ietf-yang-library X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2015 19:37:29 -0000 Andy Bierman wrote: > > > > ..... > > There is already the schema list in ietf-netconf-monitoring that gives > > you the full set of modules and submodules used in a server. > > > > > > > This is not true. > > --ro schemas > | +--ro schema* [identifier version format] > | +--ro identifier string > | +--ro version string > | +--ro format identityref > | +--ro namespace inet:uri > | +--ro location* union > > > > There is no way to tell a submodule from a module in RFC 6022. > There is no way to tell which submodules go with which modules. > There is no way to identify deviation files. A client can just download all of them and find which submodules etc are in there. > So this 'schema' list does not work for RESTCONF or CoMI. > That is 1 reason it was rejected and the ietf-yang-library module > is being used instead. > > It is very useful for a client to be able to scan 1 table and find out > all the YANG files used by the server, and then use > to retrieve any files missing from the client. > > IMO the message issue is misguided because the size of the > hello message is not really a bottleneck anywhere. Even 1000 YANG modules > would be less than 100K in a message. Are you saying you want to undo Y16? One nice thing with ietf-yang-library is that is has potential to be used as the advertisement solution for any YANG-based protocol. /martin From nobody Thu Jun 25 13:23:40 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36AED1ACEEE for ; Thu, 25 Jun 2015 13:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1I2MXktwQyw for ; Thu, 25 Jun 2015 13:23:36 -0700 (PDT) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A291D1ACEFE for ; Thu, 25 Jun 2015 13:23:25 -0700 (PDT) Received: by laka10 with SMTP id a10so51964556lak.0 for ; Thu, 25 Jun 2015 13:23:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ElDIbYuPf0JS/qlJU8UyDC/I2pW6u96BUULzIyFyhAU=; b=lJMc3tB6/82HfwPIR/ObTa3l21zwd/S9t6wdXZWHVP7PqjClM93X0zgB/Ub7HhK4V0 v07wSlXtIBAsi7mmx004DIp1yv9cY/ajhcPSH2797RR8UajIfRHnNwaItmQiaOUMe0fB pu6SQ/2S73DSzQFG4SMsbG714nKGV/AvgtgqoaD1UsxrehM2Da14+mw1Fjm1l4rV3giY 2Ut+5AqL7zLiJX50HrlLbSsIoY3hberd1XT15SIQbsqxaE2dimF9n2q39psBsGmmp5nV vDAqBxx+2asI+/Mjo4PFccothCqgo6C1EjR1cgKXsRHme8mKSM7sD6YvF2FFXHSAMeT/ 54ow== X-Gm-Message-State: ALoCoQk6cDJv8b6+RM3Irf5eiqTNhfhzG7WlIApKZbgBZFwWkp37ZqZbKhcfzUlKh4mXEYTg2BCS MIME-Version: 1.0 X-Received: by 10.112.124.71 with SMTP id mg7mr46463437lbb.38.1435263804090; Thu, 25 Jun 2015 13:23:24 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Thu, 25 Jun 2015 13:23:24 -0700 (PDT) In-Reply-To: <20150625.213727.1996609386257583091.mbj@tail-f.com> References: <20150625.101417.2199972820527866360.mbj@tail-f.com> <20150625.213727.1996609386257583091.mbj@tail-f.com> Date: Thu, 25 Jun 2015 13:23:24 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=047d7bfd0d8633d96105195d6596 Archived-At: Cc: Netconf , "netmod@ietf.org" Subject: Re: [Netconf] [netmod] Y45-04 and ietf-yang-library X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2015 20:23:38 -0000 --047d7bfd0d8633d96105195d6596 Content-Type: text/plain; charset=UTF-8 On Thu, Jun 25, 2015 at 12:37 PM, Martin Bjorklund wrote: > Andy Bierman wrote: > > > > > > ..... > > > There is already the schema list in ietf-netconf-monitoring that gives > > > you the full set of modules and submodules used in a server. > > > > > > > > > > > This is not true. > > > > --ro schemas > > | +--ro schema* [identifier version format] > > | +--ro identifier string > > | +--ro version string > > | +--ro format identityref > > | +--ro namespace inet:uri > > | +--ro location* union > > > > > > > > There is no way to tell a submodule from a module in RFC 6022. > > There is no way to tell which submodules go with which modules. > > There is no way to identify deviation files. > > A client can just download all of them and find which submodules etc > are in there. > The feedback I have received is that the NETCONF schema table is not very good and does not list all the YANG files, such as the submodules and deviations. The goal is to be able to retrieve the correct module set without needing to parse the modules first to find all the imports and includes. I don't see why it helps to remove the version index. Explain what problem this solves? Since YANG 1.1 allows module X to import an unlimited number of revisions of Y, I don't see how the server can just list 1 revision of each module in its library. > > > So this 'schema' list does not work for RESTCONF or CoMI. > > That is 1 reason it was rejected and the ietf-yang-library module > > is being used instead. > > > > It is very useful for a client to be able to scan 1 table and find out > > all the YANG files used by the server, and then use > > to retrieve any files missing from the client. > > > > IMO the message issue is misguided because the size of the > > hello message is not really a bottleneck anywhere. Even 1000 YANG > modules > > would be less than 100K in a message. > > Are you saying you want to undo Y16? > > I don't care much if the YANG 1.0 way is used for YANG 1.1 as well. IMO it is very confusing that there are 2 ways of advertising modules, based on the language version. One nice thing with ietf-yang-library is that is has potential to be > used as the advertisement solution for any YANG-based protocol. > > > /martin > Andy --047d7bfd0d8633d96105195d6596 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jun 25, 2015 at 12:37 PM, Martin Bjorklund &l= t;mbj@tail-f.com>= ; wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> >
> > .....
> > There is already the schema list in ietf-netconf-monitoring that = gives
> > you the full set of modules and submodules used in a server.
> >
> >
> >
> This is not true.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 --ro schemas
>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--ro schema* [identifier version fo= rmat]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--ro identifier=C2=A0 = =C2=A0 string
>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--ro version=C2=A0 =C2= =A0 =C2=A0 =C2=A0string
>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--ro format=C2=A0 =C2= =A0 =C2=A0 =C2=A0 identityref
>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--ro namespace=C2=A0 = =C2=A0 =C2=A0inet:uri
>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--ro location*=C2=A0 = =C2=A0 =C2=A0union
>
>
>
> There is no way to tell a submodule from a module in RFC 6022.
> There is no way to tell which submodules go with which modules.
> There is no way to identify deviation files.

A client can just download all of them and find which submodules etc
are in there.

The feedback I have recei= ved is that the NETCONF schema table is not
very good and does no= t list all the YANG files, such as
the submodules and deviations.= =C2=A0 The goal is to be able to retrieve
the correct module set = without needing to
parse the modules first to find all the import= s and includes.

I don't see why it helps to re= move the version index.
Explain what problem this solves?

Since YANG 1.1 allows module X to import an unlimited num= ber of
revisions of Y, I don't see how the server can just li= st 1 revision of
each module in its library.

=


=C2=A0

> So this 'schema' list does not work for RESTCONF or CoMI.
> That is 1 reason it was rejected and the ietf-yang-library module
> is being used instead.
>
> It is very useful for a client to be able to scan 1 table and find out=
> all the YANG files used by the server, and then use <get-schema>=
> to retrieve any files missing from the client.
>
> IMO the <hello> message issue is misguided because the size of t= he
> hello message is not really a bottleneck anywhere.=C2=A0 Even 1000 YAN= G modules
> would be less than 100K in a <hello> message.

Are you saying you want to undo Y16?



I don't care much i= f the YANG 1.0 way is used for YANG 1.1 as well.
IMO it is very c= onfusing that there are 2 ways of advertising
modules, based on t= he language version.



One nice thing with ietf-yang-library is that is has potential to be
used as the advertisement solution for any YANG-based protocol.


/martin


<= /div>
Andy

--047d7bfd0d8633d96105195d6596-- From nobody Thu Jun 25 14:46:23 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5CC1B2AEA for ; Thu, 25 Jun 2015 14:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qi06YoFBlOXw for ; Thu, 25 Jun 2015 14:46:16 -0700 (PDT) Received: from mail-la0-f47.google.com (mail-la0-f47.google.com [209.85.215.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 088BD1B2A83 for ; Thu, 25 Jun 2015 14:46:16 -0700 (PDT) Received: by lagx9 with SMTP id x9so53027515lag.1 for ; Thu, 25 Jun 2015 14:46:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=hWA7LONSD+/+eFzlALZDmbfA9W/c/zGzOBiYq2lbWeU=; b=DsvnYgiF0adarxKduSElH4kV6rRr48yV1hFh5iN1Sod6MlQ//ffVJt9wjpx1JVoa+a lz25rGQz7J//BSExp/+rJp2vClg4OpXmT36Nx48esQl367WeuhcAUEGX/Fi6HfvubKpI lJtyzlAYkFARV12uew6ULzIELjbfJ3T6OfC8qbq8YZdllb69H/7G8eNeyzsdQ1fqTNf7 u25x2AiLjJLiSQv+CLmdsMv0NVcdJtKRBcspuxNmtahnBE2opSxGtt+pkNecFdvo417P DaJTng3rxr57BFRLtvUKqYVWAqoQeqxEFMpKbKv7CgYT9HGIyUhiKrzyYhgpZgJYk/YH n2EQ== X-Gm-Message-State: ALoCoQkTp4n/Ae9wUO5oD++pfMrpW7TLV8ISgL4Z5ZvVDRLMdZZ/kLxqUrvRns1OhopQW8W7OzCW MIME-Version: 1.0 X-Received: by 10.112.164.66 with SMTP id yo2mr25562360lbb.33.1435268774418; Thu, 25 Jun 2015 14:46:14 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Thu, 25 Jun 2015 14:46:14 -0700 (PDT) In-Reply-To: <20150624.231449.697617442831847315.mbj@tail-f.com> References: <20150624.231449.697617442831847315.mbj@tail-f.com> Date: Thu, 25 Jun 2015 14:46:14 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11c32d5c74f27105195e8d15 Archived-At: Cc: Netconf , "netmod@ietf.org" Subject: Re: [Netconf] [netmod] Y45-04 and ietf-yang-library X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2015 21:46:18 -0000 --001a11c32d5c74f27105195e8d15 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 24, 2015 at 2:14 PM, Martin Bjorklund wrote: > Hi, > > I am preparing a new version of draft-ietf-netmod-rfc6020bis in order > to address Y45-04. Note that YANG 1.1 uses the module > ietf-yang-library from draft-ietf-netconf-yang-library (hence the > crossposting). > > [BTW, shouldn't ietf-yang-library be moved to NETMOD?] > > We have a whole bunch of documents that have a normative reference to > draft-ietf-netmod-rfc6020bis, which has a normative reference to > draft-ietf-netconf-yang-library. This means we need to finish this > document pretty soon. > > I ran into some issues with ietf-yang-library: > > 1. The leaf "conformance" is of type "boolean". It is not obvious > what "conformance = false" means. Should we change the name > and/or type of this leaf? > > Here is a proposal. There are no restrictions about how many revisions can appear in order to support existing YANG 1.0 servers, which have no such restrictions. leaf conformance mandatory true; type enumeration { enum implement { description "The server implements the specified revision of this module"; } enum import { description "The server imports the specified revision of this module"; } enum none { description "The server does not use the specified revision of this module. The server only supports retrieval of this YANG module."; } } } > I don't have a good proposal, but what we need is a way to > indicate "I implement the protocol accessible nodes in this > module" vs. "I just list this module b/c some other module that > I implement uses typdefs/groupings/... from it". > > This issue is related to the github issue #3. I think we need > this information; Y45-04 relies on it. > > > 2. The "/modules/module" list is keyed by "name" and "revision". > Should we really have "revision" as key? A server can only > implement one revision of a module, and should only list one > revision of a module w/ conformance = false. I suggest we make > this leaf mandatory, and not part of the key. > > > /martin > > > > Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a11c32d5c74f27105195e8d15 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jun 24, 2015 at 2:14 PM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Hi,

I am preparing a new version of draft-ietf-netmod-rfc6020bis in order
to address Y45-04.=C2=A0 Note that YANG 1.1 uses the module
ietf-yang-library from draft-ietf-netconf-yang-library (hence the
crossposting).

[BTW, shouldn't ietf-yang-library be moved to NETMOD?]

We have a whole bunch of documents that have a normative reference to
draft-ietf-netmod-rfc6020bis, which has a normative reference to
draft-ietf-netconf-yang-library.=C2=A0 This means we need to finish this document pretty soon.

I ran into some issues with ietf-yang-library:

=C2=A0 1.=C2=A0 The leaf "conformance" is of type "boolean&q= uot;.=C2=A0 It is not obvious
=C2=A0 =C2=A0 =C2=A0 what "conformance =3D false" means.=C2=A0 Sh= ould we change the name
=C2=A0 =C2=A0 =C2=A0 and/or type of this leaf?



Here is a proposal.
There are no restrictions about how many revisions can appear
<= div>in order to support existing YANG 1.0 servers, which have
no = such restrictions.


=C2=A0 =C2=A0 le= af conformance
=C2=A0 =C2=A0 =C2=A0 mandatory true;
=C2=A0 =C2=A0 =C2=A0 type enumeration {
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0enum implement {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 description
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = "The server implements the specified revision of this module";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0enum import {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 description
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0"The server imports the specified revision of this module= ";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 enum none {
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 description
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0"The server does not use the specified revision of= this module.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0The server only supports retrieval of this YANG module.";=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2= =A0 =C2=A0}
=C2=A0 =C2=A0}




=C2=A0
=C2=A0 =C2=A0 =C2=A0 I don't have a good proposal, but what we need is = a way to
=C2=A0 =C2=A0 =C2=A0 indicate "I implement the protocol accessible nod= es in this
=C2=A0 =C2=A0 =C2=A0 module" vs. "I just list this module b/c som= e other module that
=C2=A0 =C2=A0 =C2=A0 I implement uses typdefs/groupings/... from it".<= br>
=C2=A0 =C2=A0 =C2=A0 This issue is related to the github issue #3.=C2=A0 I = think we need
=C2=A0 =C2=A0 =C2=A0 this information; Y45-04 relies on it.


=C2=A0 2.=C2=A0 The "/modules/module" list is keyed by "name= " and "revision".
=C2=A0 =C2=A0 =C2=A0 Should we really have "revision" as key?=C2= =A0 A server can only
=C2=A0 =C2=A0 =C2=A0 implement one revision of a module, and should only li= st one
=C2=A0 =C2=A0 =C2=A0 revision of a module w/ conformance =3D false.=C2=A0 I= suggest we make
=C2=A0 =C2=A0 =C2=A0 this leaf mandatory, and not part of the key.


/martin





Andy

=C2=A0

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

--001a11c32d5c74f27105195e8d15-- From nobody Thu Jun 25 16:25:15 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE271B2CA0 for ; Thu, 25 Jun 2015 16:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQLAZ2WlZiJX for ; Thu, 25 Jun 2015 16:25:13 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0105.outbound.protection.outlook.com [65.55.169.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE0E51A89FD for ; Thu, 25 Jun 2015 16:25:12 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.195.15; Thu, 25 Jun 2015 23:25:11 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.100]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.100]) with mapi id 15.01.0195.005; Thu, 25 Jun 2015 23:25:11 +0000 From: Kent Watsen To: Kent Watsen Thread-Topic: [Netconf] server-model #54: move idle-timeout from global "session-options" to the "listen" tree? Thread-Index: AQHQnylRVSAYbzmnCkGtm2Dh3wuOiJ2dKNsAgADRUoCAH8DLAA== Date: Thu, 25 Jun 2015 23:25:11 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: juniper.net; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.10] x-microsoft-exchange-diagnostics: 1; CO1PR05MB459; 5:J1o4Y/yKGKMb/1wLNgCkBioiuwCPuj/zlBY059i0BY938jXLfglELeRJgVwKBS3PMGqrxqD2FDvsiumFtPccP951+ep+y1o+UItx2kE07o1ypLyPmYgl0XiiQAB2CwJO+OJOuHJFrjqA0FSgytZkqg==; 24:iEqrL8FqPxzeTVUitcmdQYfxaNmrdedoDC0FpZ8PymlsPMsvUq/pBnip/uc9YO3tCH9qVtpESedlfdPysg4onnko3C0GiFdDsocCLIjtRm8=; 20:4Cv5NvrrltX3IaHuEmy8Ian/j5b5JT5JHDBuAZ6WWHY8RPixA6OUwI9ne0gRmdHEnYFM/9lb2yTzHlH3q9RWWQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CO1PR05MB459; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; x-forefront-prvs: 0618E4E7E1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(76104003)(83506001)(46102003)(106116001)(92566002)(50986999)(76176999)(99286002)(54356999)(4001350100001)(36756003)(110136002)(6200100001)(5001960100002)(5002640100001)(450100001)(189998001)(62966003)(77156002)(7049001)(2656002)(40100003)(87936001)(122556002)(66066001)(102836002)(86362001)(2900100001)(2950100001)(4001450100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <482417A766480F46A0F718E9483A843A@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jun 2015 23:25:11.2601 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] server-model #54: move idle-timeout from global "session-options" to the "listen" tree? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2015 23:25:14 -0000 Regarding moving "idle-timeout" node to the "listen" tree, I'm still a fan of that, but what I think would be even better is to also have an idle-timeout in the call-home/periodic and the call-home/persistent sub-trees. =20 An idle-timeout is always useful, but its value needs to be different for the various cases. How about this: Default ------- listen/idle-timeout 1 hour call-home/periodic/idle-timeout 5 min call-home/persistent/idle-timeout 1 day What do you think? - makes sense? Kent From nobody Thu Jun 25 22:21:19 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B93071B2A53 for ; Thu, 25 Jun 2015 22:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIldHsAbb9CC for ; Thu, 25 Jun 2015 22:21:13 -0700 (PDT) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::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 70AFB1B2A67 for ; Thu, 25 Jun 2015 22:21:12 -0700 (PDT) Received: by pdcu2 with SMTP id u2so67822124pdc.3 for ; Thu, 25 Jun 2015 22:21:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=9+4gjEapWmIHOW13KdmbPGtN+SLOltHj5SfKfXIXNdc=; b=z0o6FlkMto5SkMgIrEpoSORrKrDU1/ZodvaFPAqeGUJ7Htb7eiLC7mKJDVkx/oWvWI hb5GQy0QUW3y+jzQ7Syl5UgmpLoJJqMNSgQoiu4/Blv9Np7Ge9T7wSmFX9hiUsKQDalg NR8VKwiBEGIKCRkJ4DTwI8VADg/QZhNHumiUaaE3h65ahYLntYpsKfkr9Ekq8Sp7tV7w 7fq13slX5+KVr3p0QQIcSVcok6oGUzFtj+QLVmPUlKJ7k1Qd1kJSz3lpC9iJfSjLMrut 9wac8DFF3MNWODjNLPCChaGjC4+TLTKog0Wb+ih7kClNjW4cVwrsRcZrhaJ0PqzEZgdm tkug== X-Received: by 10.68.89.164 with SMTP id bp4mr6764815pbb.41.1435296071967; Thu, 25 Jun 2015 22:21:11 -0700 (PDT) Received: from ?IPv6:2602:306:cf77:f4c0:b8d0:cd48:77d6:bc6b? ([2602:306:cf77:f4c0:b8d0:cd48:77d6:bc6b]) by mx.google.com with ESMTPSA id sc7sm19877077pbb.85.2015.06.25.22.21.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Jun 2015 22:21:10 -0700 (PDT) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_66F81CD0-E7A9-46C2-9926-5C0ABDCF5B8D" Message-Id: Date: Thu, 25 Jun 2015 22:21:06 -0700 To: Netconf Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Archived-At: Subject: [Netconf] WG Last Call for draft-ietf-netconf-call-home-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2015 05:21:14 -0000 --Apple-Mail=_66F81CD0-E7A9-46C2-9926-5C0ABDCF5B8D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear NETCONF participants, This e-mail is a notification to start a NETCONF WG Last Call for the = document "NETCONF Call Home and RESTCONF Call Home=E2=80=9D. The document can be found at: draft-ietf-netconf-call-home-07 = . Please review the document, provide comments, and indicate your support = for the draft by Friday July 3 (your timezone). The comments can be in = the form of: =E2=80=9CI have reviewed the I-D Blah and I have found issues with it=E2=80= =9D =E2=80=9CI have reviewed I-D Blah and I found no issues=E2=80=9D Simultaneously, the author on this draft should state to the mailing = list whether there is any IPR associated with this draft or not. Thanks Mahesh and Mehmet (Co-chairs, NETCONF WG) --Apple-Mail=_66F81CD0-E7A9-46C2-9926-5C0ABDCF5B8D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear NETCONF participants,

This = e-mail is a notification to start a NETCONF WG Last Call for the = document "NETCONF Call Home and RESTCONF Call Home=E2=80=9D.

The document can be found at: draft-ietf-netconf-call-home-07.

Please review the document, provide = comments, and indicate your support for the draft by Friday July 3 (your = timezone). The comments can be in the form of:

  • =E2=80=9CI have reviewed the I-D Blah and I have found issues = with it=E2=80=9D
  • =E2=80=9CI have reviewed I-D Blah = and I found no issues=E2=80=9D

Simultaneously, the author on this = draft should state to the mailing list whether there is any IPR = associated with this draft or not.

Thanks

Mahesh and = Mehmet
(Co-chairs, NETCONF WG)




= --Apple-Mail=_66F81CD0-E7A9-46C2-9926-5C0ABDCF5B8D-- From nobody Fri Jun 26 01:32:07 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88B4B1A00ED; Fri, 26 Jun 2015 01:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eaWzDeMo9GMu; Fri, 26 Jun 2015 01:32: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 C6BAD1A00EC; Fri, 26 Jun 2015 01:32:02 -0700 (PDT) Received: from localhost (h-85-24-195-9.na.cust.bahnhof.se [85.24.195.9]) by mail.tail-f.com (Postfix) with ESMTPSA id ACF721AE0286; Fri, 26 Jun 2015 10:32:00 +0200 (CEST) Date: Fri, 26 Jun 2015 10:32:00 +0200 (CEST) Message-Id: <20150626.103200.573472643590304772.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20150625.213727.1996609386257583091.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [Netconf] [netmod] Y45-04 and ietf-yang-library X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2015 08:32:04 -0000 Andy Bierman wrote: > On Thu, Jun 25, 2015 at 12:37 PM, Martin Bjorklund wrote: > > > Andy Bierman wrote: > > > > > > > > ..... > > > > There is already the schema list in ietf-netconf-monitoring that gives > > > > you the full set of modules and submodules used in a server. > > > > > > > > > > > > > > > This is not true. > > > > > > --ro schemas > > > | +--ro schema* [identifier version format] > > > | +--ro identifier string > > > | +--ro version string > > > | +--ro format identityref > > > | +--ro namespace inet:uri > > > | +--ro location* union > > > > > > > > > > > > There is no way to tell a submodule from a module in RFC 6022. > > > There is no way to tell which submodules go with which modules. > > > There is no way to identify deviation files. > > > > A client can just download all of them and find which submodules etc > > are in there. > > > > The feedback I have received is that the NETCONF schema table is not > very good and does not list all the YANG files, such as > the submodules and deviations. That seems to be an issue with the implementation rather than the model. > The goal is to be able to retrieve > the correct module set without needing to > parse the modules first to find all the imports and includes. Yes; download all modules in the schema list. > I don't see why it helps to remove the version index. > Explain what problem this solves? It solves the advertisement problem: 1. The client needs to know which modules the server implements, and their revisions. Since a server can only implement one revision of a module, this is easy. List the module and mark it with conformance true. 2. Some definitions-only modules might be imported by revision by the modules that are implemented. These do not need to be advertised. 3. Some definitions-only modules might be imported without revision by the modules that are implemented. The server MUST pick one revision and use that, and it needs to advertise this revision, and mark it with conformance false. Again, it is just one revision. If this list contains more than one revision of a conformance false module, the client cannot tell which revision was used. And if the list contains more than one revision of a conformance true module, the server lies (since it cannot implement more than one revision). > Since YANG 1.1 allows module X to import an unlimited number of > revisions of Y, I don't see how the server can just list 1 revision of > each module in its library. See above. > > > So this 'schema' list does not work for RESTCONF or CoMI. > > > That is 1 reason it was rejected and the ietf-yang-library module > > > is being used instead. > > > > > > It is very useful for a client to be able to scan 1 table and find out > > > all the YANG files used by the server, and then use > > > to retrieve any files missing from the client. > > > > > > IMO the message issue is misguided because the size of the > > > hello message is not really a bottleneck anywhere. Even 1000 YANG > > modules > > > would be less than 100K in a message. > > > > Are you saying you want to undo Y16? > > > > > > I don't care much if the YANG 1.0 way is used for YANG 1.1 as well. > IMO it is very confusing that there are 2 ways of advertising > modules, based on the language version. The YANG 1.0 way only works for NETCONF. So there will be another mechanism for RESTCONF and possibly other protocols. Isn't it better to use that mechanism for all protocols? /martin > > > > One nice thing with ietf-yang-library is that is has potential to be > > used as the advertisement solution for any YANG-based protocol. > > > > > > /martin > > > > > Andy From nobody Fri Jun 26 01:59:11 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB2C71A1A5F; Fri, 26 Jun 2015 01:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5Ks-Nz8jrkS; Fri, 26 Jun 2015 01:59:08 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9361A1A5D; Fri, 26 Jun 2015 01:59:08 -0700 (PDT) Received: from localhost (h-85-24-195-9.na.cust.bahnhof.se [85.24.195.9]) by mail.tail-f.com (Postfix) with ESMTPSA id 88AFA1AE048E; Fri, 26 Jun 2015 10:59:07 +0200 (CEST) Date: Fri, 26 Jun 2015 10:59:07 +0200 (CEST) Message-Id: <20150626.105907.1929816701749723248.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20150624.231449.697617442831847315.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [Netconf] [netmod] Y45-04 and ietf-yang-library X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2015 08:59:09 -0000 Andy Bierman wrote: > On Wed, Jun 24, 2015 at 2:14 PM, Martin Bjorklund wrote: > > > Hi, > > > > I am preparing a new version of draft-ietf-netmod-rfc6020bis in order > > to address Y45-04. Note that YANG 1.1 uses the module > > ietf-yang-library from draft-ietf-netconf-yang-library (hence the > > crossposting). > > > > [BTW, shouldn't ietf-yang-library be moved to NETMOD?] > > > > We have a whole bunch of documents that have a normative reference to > > draft-ietf-netmod-rfc6020bis, which has a normative reference to > > draft-ietf-netconf-yang-library. This means we need to finish this > > document pretty soon. > > > > I ran into some issues with ietf-yang-library: > > > > 1. The leaf "conformance" is of type "boolean". It is not obvious > > what "conformance = false" means. Should we change the name > > and/or type of this leaf? > > > > > > Here is a proposal. Thanks, I think this is good progress. > There are no restrictions about how many revisions can appear > in order to support existing YANG 1.0 servers, which have > no such restrictions. I don't think this is an important goal. I also think that this module should have yang-version 1.1 - which all modules will have going forward. But if we combine what both of us have said there are two goals with this module: 1. Solve the advertisement problem (protocol independent). 2. Provide a complete listing of all YANG modules used in the server. I believe that your proposed solution below can solve both these requirements (with some minor tweaks): > leaf conformance > mandatory true; > type enumeration { > enum implement { > description > "The server implements the specified revision of this module"; Ok. We need to clearly define what "implement" a module means. I have started to do this in 6020bis, so we should provide a ref to that section. > } > enum import { > description > "The server imports the specified revision of this module"; This should be more precise - "the server uses the specified revision of this module for all other modules that import this module without revision". > } > enum none { > description > "The server does not use the specified revision of this > module. > The server only supports retrieval of this YANG module."; I don't think this is correct. The server would list a typedef only module that is imported by revision here, right? I think it should be something like "the server uses the specified revision of this module because some other module imports this revision". We should also say: There MUST NOT be more than one listing with conformance "implemented" for a given module name. There MUST NOT be more than one listing with conformance "import" for a given module name. How is a deviation module listed? Does the conformance leaf matter for such a module? /martin From nobody Fri Jun 26 07:12:20 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 953B41B2F5B for ; Fri, 26 Jun 2015 07:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5TNxMe9x22v for ; Fri, 26 Jun 2015 07:12:17 -0700 (PDT) Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E67BE1B2F55 for ; Fri, 26 Jun 2015 07:12:16 -0700 (PDT) Received: by lacny3 with SMTP id ny3so64316704lac.3 for ; Fri, 26 Jun 2015 07:12:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=eD5D19nuoOwglmvWn09Xgz3I+HqrWe+hZaSLjmLAnoA=; b=akHSAHTDBtmh3zz+i3VKEdlxSl3bf8/JkEjRxLAHsB5Te2gbhbH+AzTPPGsYJk6yRm jsmpKEgArP4iSS4YFsY33zwycGnt/XF7RWk+W49Q9ws3xJqkB496CImiuLEs8llXM1u3 UfPSed+NkzXtbxEutE9jAZ/wbiA1EwcCiE7tvw9oSmFZH8uHH2TWS5AACorhKKAkueiZ vUf5B2aR33OCSuhIxIi5Cv90cEhoBHGkAl/hEC6BWJ267dQAf5dM9fF7xkJIUiIvq6tg fdxJOjwLu6aKT61Vr7kC41UttlX+ccqbX2+DKxYN494tpyEVbYlhDgUViT8wetsFSKZt MarQ== X-Gm-Message-State: ALoCoQmmZf4MGRm6e3HMeI4vOjuxTTYQYOPIq2KzkPLKnkwEOow+cXFLmQ8pEMGjkdm1uXAQWnMd MIME-Version: 1.0 X-Received: by 10.112.41.171 with SMTP id g11mr1760894lbl.123.1435327935333; Fri, 26 Jun 2015 07:12:15 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Fri, 26 Jun 2015 07:12:15 -0700 (PDT) In-Reply-To: <20150626.105907.1929816701749723248.mbj@tail-f.com> References: <20150624.231449.697617442831847315.mbj@tail-f.com> <20150626.105907.1929816701749723248.mbj@tail-f.com> Date: Fri, 26 Jun 2015 07:12:15 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11346d9cb8dda505196c538f Archived-At: Cc: Netconf , "netmod@ietf.org" Subject: Re: [Netconf] [netmod] Y45-04 and ietf-yang-library X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2015 14:12:19 -0000 --001a11346d9cb8dda505196c538f Content-Type: text/plain; charset=UTF-8 On Fri, Jun 26, 2015 at 1:59 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Wed, Jun 24, 2015 at 2:14 PM, Martin Bjorklund > wrote: > > > > > Hi, > > > > > > I am preparing a new version of draft-ietf-netmod-rfc6020bis in order > > > to address Y45-04. Note that YANG 1.1 uses the module > > > ietf-yang-library from draft-ietf-netconf-yang-library (hence the > > > crossposting). > > > > > > [BTW, shouldn't ietf-yang-library be moved to NETMOD?] > > > > > > We have a whole bunch of documents that have a normative reference to > > > draft-ietf-netmod-rfc6020bis, which has a normative reference to > > > draft-ietf-netconf-yang-library. This means we need to finish this > > > document pretty soon. > > > > > > I ran into some issues with ietf-yang-library: > > > > > > 1. The leaf "conformance" is of type "boolean". It is not obvious > > > what "conformance = false" means. Should we change the name > > > and/or type of this leaf? > > > > > > > > > > Here is a proposal. > > Thanks, I think this is good progress. > > > There are no restrictions about how many revisions can appear > > in order to support existing YANG 1.0 servers, which have > > no such restrictions. > > I don't think this is an important goal. I also think that this > module should have yang-version 1.1 - which all modules will have > going forward. > > This is an an important goal to me. I do not see any value in restricting the contents of the YANG library, IMO the library MUST contain all the YANG files and it MUST bwe absolutely clear which files are modules, submodules, or deviations. The schema list does not do that. > But if we combine what both of us have said there are two goals with > this module: > > 1. Solve the advertisement problem (protocol independent). > > 2. Provide a complete listing of all YANG modules used in the > server. > > I believe that your proposed solution below can solve both these > requirements (with some minor tweaks): > > > leaf conformance > > mandatory true; > > type enumeration { > > enum implement { > > description > > "The server implements the specified revision of this > module"; > > Ok. We need to clearly define what "implement" a module means. I > have started to do this in 6020bis, so we should provide a ref to that > section. > Any implementation of a protocol-accessible object. Fairly obvious I think. > > > } > > enum import { > > description > > "The server imports the specified revision of this > module"; > > This should be more precise - "the server uses the specified revision > of this module for all other modules that import this module without > revision". > > > } > > enum none { > > description > > "The server does not use the specified revision of this > > module. > > The server only supports retrieval of this YANG > module."; > > I don't think this is correct. The server would list a typedef only > module that is imported by revision here, right? I think it should > be something like "the server uses the specified revision of this > module because some other module imports this revision". > > I want to support a "module server" that does nothing more than provide all the YANG modules for retrieval. > We should also say: > > There MUST NOT be more than one listing with conformance "implemented" > for a given module name. > > There MUST NOT be more than one listing with conformance "import" > for a given module name. > > > No -- YANG 1.1 allows module X to import module Y a million times if it wants. Every one of those revisions of module Y will be listed. > How is a deviation module listed? Does the conformance leaf matter > for such a module? > > I would say 'none' > > /martin > Andy --001a11346d9cb8dda505196c538f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jun 26, 2015 at 1:59 AM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Wed, Jun 24, 2015 at 2:14 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Hi,
> >
> > I am preparing a new version of draft-ietf-netmod-rfc6020bis in o= rder
> > to address Y45-04.=C2=A0 Note that YANG 1.1 uses the module
> > ietf-yang-library from draft-ietf-netconf-yang-library (hence the=
> > crossposting).
> >
> > [BTW, shouldn't ietf-yang-library be moved to NETMOD?]
> >
> > We have a whole bunch of documents that have a normative referenc= e to
> > draft-ietf-netmod-rfc6020bis, which has a normative reference to<= br> > > draft-ietf-netconf-yang-library.=C2=A0 This means we need to fini= sh this
> > document pretty soon.
> >
> > I ran into some issues with ietf-yang-library:
> >
> >=C2=A0 =C2=A01.=C2=A0 The leaf "conformance" is of type = "boolean".=C2=A0 It is not obvious
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0what "conformance =3D false" = means.=C2=A0 Should we change the name
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0and/or type of this leaf?
> >
> >
>
> Here is a proposal.

Thanks, I think this is good progress.

> There are no restrictions about how many revisions can appear
> in order to support existing YANG 1.0 servers, which have
> no such restrictions.

I don't think this is an important goal.=C2=A0 I also think that this module should have yang-version 1.1 - which all modules will have
going forward.



This is an an important= goal to me.

I do not see any value in restricting= the contents of the YANG library,

IMO the library= MUST contain all the YANG files and it MUST
bwe absolutely clear= which files are modules, submodules, or deviations.
The schema l= ist does not do that.

=C2=A0
But if we combine what both of us have said there are two goals with
this module:

=C2=A0 1.=C2=A0 Solve the advertisement problem (protocol independent).

=C2=A0 2.=C2=A0 Provide a complete listing of all YANG modules used in the<= br> =C2=A0 =C2=A0 =C2=A0 server.

I believe that your proposed solution below can solve both these
requirements (with some minor tweaks):

>=C2=A0 =C2=A0 =C2=A0leaf conformance
>=C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0type enumeration {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 enum implement {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"The server= implements the specified revision of this module";

Ok.=C2=A0 We need to clearly define what "implement" a module mea= ns.=C2=A0 I
have started to do this in 6020bis, so we should provide a ref to that
section.

Any implementation of a protoc= ol-accessible object.
Fairly obvious I think.


=C2=A0

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 enum import {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "The serve= r imports the specified revision of this module";

This should be more precise - "the server uses the specified revision<= br> of this module for all other modules that import this module without
revision".

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum none {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "The serve= r does not use the specified revision of this
> module.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The serv= er only supports retrieval of this YANG module.";

I don't think this is correct.=C2=A0 The server would list a typedef on= ly
module that is imported by revision here, right?=C2=A0 =C2=A0I think it sho= uld
be something like "the server uses the specified revision of this
module because some other module imports this revision".



I want to support a &qu= ot;module server" that does nothing more than
provide all th= e YANG modules for retrieval.

=C2=A0
We should also say:

=C2=A0 There MUST NOT be more than one listing with conformance "imple= mented"
=C2=A0 for a given module name.

=C2=A0 There MUST NOT be more than one listing with conformance "impor= t"
=C2=A0 for a given module name.




No -- YANG 1.1 allows m= odule X to
import module Y a million times if it wants.
Every one of those revisions of module Y will be listed.


=C2=A0
How is a deviation module listed?=C2=A0 Does the conformance leaf matter for such a module?


I would say 'none'

= =C2=A0

/martin


<= /div>
Andy

--001a11346d9cb8dda505196c538f-- From nobody Fri Jun 26 10:18:58 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF1E1A8F51 for ; Fri, 26 Jun 2015 10:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXJXmDv8iWzo for ; Fri, 26 Jun 2015 10:18:53 -0700 (PDT) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 261931A8AAF for ; Fri, 26 Jun 2015 10:18:53 -0700 (PDT) Received: by lbnk3 with SMTP id k3so68508516lbn.1 for ; Fri, 26 Jun 2015 10:18:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qVbxGwjPl8KzEKAbtL2uYzqrUOMd1PPQEyc2ZzcG7iI=; b=V4NTzuE+pTxJ0JwAWPUsIDSNIhV2j1tG+w3va+6avm/LxYmb4G6eDpuAsvDJGGHTkP LsAvHIDI1V+19BW47qtNVwp2adCSjDg89TEyxC92Am4J8PBCRId6s6tL0+N8+Pgex/nn G3cQP9dLU+yNkLXriPZ5VHGIhq8OaRHk4xf7O+4Qg73q81XugF2sVNsOgczCCG5dgRrP ENcN42/t5SVKiBynRQEUD3FYFaY+3uqCZTOCY13fjelzhYznfYVkSk6OLU0/Q1/rRo9s YPS/axGZWfNX+8PxcXghntrshddByw5ZNAVA0V8NUX2xKIW/6x+1UnNBd49HKQPA9Ou0 h7lQ== X-Gm-Message-State: ALoCoQkLO8JlGhL8rXv/mENlrnBXn2ba70HqJRMsWg3YprL+5U8a9LCt+57Tlu9ZNSfFoQuIfL7u MIME-Version: 1.0 X-Received: by 10.152.36.161 with SMTP id r1mr2530737laj.88.1435339131623; Fri, 26 Jun 2015 10:18:51 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Fri, 26 Jun 2015 10:18:51 -0700 (PDT) In-Reply-To: <20150626.105907.1929816701749723248.mbj@tail-f.com> References: <20150624.231449.697617442831847315.mbj@tail-f.com> <20150626.105907.1929816701749723248.mbj@tail-f.com> Date: Fri, 26 Jun 2015 10:18:51 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=089e0158b5e412b4fe05196eef55 Archived-At: Cc: Netconf , "netmod@ietf.org" Subject: Re: [Netconf] [netmod] Y45-04 and ietf-yang-library X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2015 17:18:55 -0000 --089e0158b5e412b4fe05196eef55 Content-Type: text/plain; charset=UTF-8 On Fri, Jun 26, 2015 at 1:59 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Wed, Jun 24, 2015 at 2:14 PM, Martin Bjorklund > wrote: > > > > > Hi, > > > > > > I am preparing a new version of draft-ietf-netmod-rfc6020bis in order > > > to address Y45-04. Note that YANG 1.1 uses the module > > > ietf-yang-library from draft-ietf-netconf-yang-library (hence the > > > crossposting). > > > > > > [BTW, shouldn't ietf-yang-library be moved to NETMOD?] > > > > > > We have a whole bunch of documents that have a normative reference to > > > draft-ietf-netmod-rfc6020bis, which has a normative reference to > > > draft-ietf-netconf-yang-library. This means we need to finish this > > > document pretty soon. > > > > > > I ran into some issues with ietf-yang-library: > > > > > > 1. The leaf "conformance" is of type "boolean". It is not obvious > > > what "conformance = false" means. Should we change the name > > > and/or type of this leaf? > > > > > > > > > > Here is a proposal. > > Thanks, I think this is good progress. > > > There are no restrictions about how many revisions can appear > > in order to support existing YANG 1.0 servers, which have > > no such restrictions. > > I don't think this is an important goal. I also think that this > module should have yang-version 1.1 - which all modules will have > going forward. > > But if we combine what both of us have said there are two goals with > this module: > > 1. Solve the advertisement problem (protocol independent). > > 2. Provide a complete listing of all YANG modules used in the > server. > > I believe that your proposed solution below can solve both these > requirements (with some minor tweaks): > > > leaf conformance > > mandatory true; > > type enumeration { > > enum implement { > > description > > "The server implements the specified revision of this > module"; > > Ok. We need to clearly define what "implement" a module means. I > have started to do this in 6020bis, so we should provide a ref to that > section. > > > } > > enum import { > > description > > "The server imports the specified revision of this > module"; > > This should be more precise - "the server uses the specified revision > of this module for all other modules that import this module without > revision". > > > } > > enum none { > > description > > "The server does not use the specified revision of this > > module. > > The server only supports retrieval of this YANG > module."; > > I don't think this is correct. The server would list a typedef only > module that is imported by revision here, right? I think it should > be something like "the server uses the specified revision of this > module because some other module imports this revision". > > We should also say: > > There MUST NOT be more than one listing with conformance "implemented" > for a given module name. > This is not true for YANG 1.0, only YANG 1.1 > > There MUST NOT be more than one listing with conformance "import" > for a given module name. > > There are no restrictions on YANG for what is contained in the same module. Module X can have typedefs, groupings, and objects. The server implements the objects in X.5. According to YANG 1.1, Y45-04: Module A can import X.1 for its typedefs. Module B can import X.2 for a different version of the typedefs. Module C can import X.3 for the groupings in that version. The library will have these entries: module=A, revision=1, conformance=implement module=B, revision=1, conformance=implement module=C, revision=1, conformance=implement module=X, revision=1, conformance=import module=X, revision=2, conformance=import module=X, revision=3, conformance=import module=X, revision=5, conformance=implement > How is a deviation module listed? Does the conformance leaf matter > for such a module? > > I think 'deviation' should be its own enum, not use 'none' The nice thing about enum 'import' is that the server does not need to provide deviation statements for any objects in the base module, just to import from the module. > > /martin > Andy --089e0158b5e412b4fe05196eef55 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jun 26, 2015 at 1:59 AM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Wed, Jun 24, 2015 at 2:14 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Hi,
> >
> > I am preparing a new version of draft-ietf-netmod-rfc6020bis in o= rder
> > to address Y45-04.=C2=A0 Note that YANG 1.1 uses the module
> > ietf-yang-library from draft-ietf-netconf-yang-library (hence the=
> > crossposting).
> >
> > [BTW, shouldn't ietf-yang-library be moved to NETMOD?]
> >
> > We have a whole bunch of documents that have a normative referenc= e to
> > draft-ietf-netmod-rfc6020bis, which has a normative reference to<= br> > > draft-ietf-netconf-yang-library.=C2=A0 This means we need to fini= sh this
> > document pretty soon.
> >
> > I ran into some issues with ietf-yang-library:
> >
> >=C2=A0 =C2=A01.=C2=A0 The leaf "conformance" is of type = "boolean".=C2=A0 It is not obvious
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0what "conformance =3D false" = means.=C2=A0 Should we change the name
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0and/or type of this leaf?
> >
> >
>
> Here is a proposal.

Thanks, I think this is good progress.

> There are no restrictions about how many revisions can appear
> in order to support existing YANG 1.0 servers, which have
> no such restrictions.

I don't think this is an important goal.=C2=A0 I also think that this module should have yang-version 1.1 - which all modules will have
going forward.

But if we combine what both of us have said there are two goals with
this module:

=C2=A0 1.=C2=A0 Solve the advertisement problem (protocol independent).

=C2=A0 2.=C2=A0 Provide a complete listing of all YANG modules used in the<= br> =C2=A0 =C2=A0 =C2=A0 server.

I believe that your proposed solution below can solve both these
requirements (with some minor tweaks):

>=C2=A0 =C2=A0 =C2=A0leaf conformance
>=C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0type enumeration {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 enum implement {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"The server= implements the specified revision of this module";

Ok.=C2=A0 We need to clearly define what "implement" a module mea= ns.=C2=A0 I
have started to do this in 6020bis, so we should provide a ref to that
section.

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 enum import {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "The serve= r imports the specified revision of this module";

This should be more precise - "the server uses the specified revision<= br> of this module for all other modules that import this module without
revision".

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum none {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "The serve= r does not use the specified revision of this
> module.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The serv= er only supports retrieval of this YANG module.";

I don't think this is correct.=C2=A0 The server would list a typedef on= ly
module that is imported by revision here, right?=C2=A0 =C2=A0I think it sho= uld
be something like "the server uses the specified revision of this
module because some other module imports this revision".

We should also say:

=C2=A0 There MUST NOT be more than one listing with conformance "imple= mented"
=C2=A0 for a given module name.


This is not true for YANG 1.0, only YANG 1.1
=C2=A0
=

=C2=A0 There MUST NOT be more than one listing with conformance "impor= t"
=C2=A0 for a given module name.


There are no restrictions on YANG for = what is contained in the same module.

Module X can= have typedefs, groupings, and objects.
The server implements the= objects in X.5.
According to YANG 1.1, Y45-04:
Module = A can import X.1 for its typedefs.
Module B can import X.2 for a = different version of the typedefs.
Module C can import X.3 for th= e groupings in that version.

The library will have= these entries:

=C2=A0 =C2=A0 module=3DA, revision= =3D1, conformance=3Dimplement
=C2=A0 =C2=A0 module=3DB, revision= =3D1, conformance=3Dimplement
=C2=A0 =C2=A0 module=3DC, revision= =3D1, conformance=3Dimplement
=C2=A0 =C2=A0 module=3DX, revision= =3D1, conformance=3Dimport
=C2=A0 =C2=A0 module=3DX, revision= =3D2, conformance=3Dimport
=C2=A0 =C2=A0 module=3DX, revision=3D3= , conformance=3Dimport
=C2=A0 =C2=A0 module=3DX, revision=3D5, co= nformance=3Dimplement
=C2=A0


How is a deviation module listed?=C2=A0 Does the conformance leaf matter for such a module?


I think 'deviation' should be its own enum, not us= e 'none'

The nice thing about enum 'im= port' is that the server does not need to
provide deviation s= tatements for any objects in the base module,
just to import from= the module.


=C2=A0

/martin


<= /div>
Andy

--089e0158b5e412b4fe05196eef55-- From nobody Fri Jun 26 14:39:16 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACC281A9022 for ; Fri, 26 Jun 2015 14:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILYd7eHo0QIy for ; Fri, 26 Jun 2015 14:39:13 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD10C1A901E for ; Fri, 26 Jun 2015 14:39:13 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 3171BA93; Fri, 26 Jun 2015 23:39:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id YHibcMOvUb_x; Fri, 26 Jun 2015 23:39:08 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 26 Jun 2015 23:39:06 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 357752002B; Fri, 26 Jun 2015 23:39:09 +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 VItCTNB5Wwdm; Fri, 26 Jun 2015 23:39:30 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CA18820013; Fri, 26 Jun 2015 23:39:07 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 15839347B9E8; Fri, 26 Jun 2015 23:39:09 +0200 (CEST) Date: Fri, 26 Jun 2015 23:39:09 +0200 From: Juergen Schoenwaelder To: Mahesh Jethanandani Message-ID: <20150626213909.GC43864@elstar.local> Mail-Followup-To: Mahesh Jethanandani , Netconf 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.4.2.3i Archived-At: Cc: Netconf Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-call-home-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 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, 26 Jun 2015 21:39:15 -0000 On Thu, Jun 25, 2015 at 10:21:06PM -0700, Mahesh Jethanandani wrote: > Dear NETCONF participants, > > This e-mail is a notification to start a NETCONF WG Last Call for the document "NETCONF Call Home and RESTCONF Call Homeâ€. > > The document can be found at: draft-ietf-netconf-call-home-07 . > I have reviewed draft-ietf-netconf-call-home-08 and I have the following comments: - I have no technical issues with the document and I believe it is ready to go to the IESG. - I do not understand the second bullet in section 1.1. It is unclear what kind of 'mapping service' this is referring to. - Nit: s/YANG [RFC6020] model/YANG [RFC6020] data model/ /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Jun 26 14:57:49 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 620321ACCF0 for ; Fri, 26 Jun 2015 14:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MsuhDGU1V_yK for ; Fri, 26 Jun 2015 14:57:45 -0700 (PDT) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::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 CD3861ACCDC for ; Fri, 26 Jun 2015 14:57:45 -0700 (PDT) Received: by pdjn11 with SMTP id n11so81891719pdj.0 for ; Fri, 26 Jun 2015 14:57:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:message-id:mime-version:subject:date:references :to:in-reply-to; bh=6bdZ+aEh7sKNkE4wNskkQmp3YVwALyEGH9xooYHqLqw=; b=AC+Rn3y+G1QjzbKjGJQ55e6gMwzeMOYHKxDs9BAQLlfxIFABJoB4K7Z6d7okSf0Y1a I1LvG2+S/JV1PyPajHA5iYpV9qihMR7pdTyTuDjoKmGLW9yOjHb6jMHMrTcL9y/wJx07 8j6D88l6/OjwiyrxfCFRI+IlHkrqUUjmXAMAnElQuNJBjTI7UIkcSxvClvNx9v5Iqg3h SOX8I2c1zyAfUAMwlQEbff9tX8eqduZYz8KhegU5yRc2Ut4rmCWmh4EU8dJCTZYwOdgg d1UBzYKWy3/NXymx4BQICJZ6+uIBbIWdM6d81tjvzghCPQj03iUv0bqtGuN05HwbVTZB ljkQ== X-Received: by 10.70.125.129 with SMTP id mq1mr7397888pdb.19.1435355865459; Fri, 26 Jun 2015 14:57:45 -0700 (PDT) Received: from ?IPv6:2001:420:302:1330:7197:4184:582e:ba8f? ([2001:420:302:1330:7197:4184:582e:ba8f]) by mx.google.com with ESMTPSA id tj8sm34556294pab.30.2015.06.26.14.57.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 26 Jun 2015 14:57:44 -0700 (PDT) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_F8F2C2C5-6914-48A5-88D8-139ED204BDCE" Message-Id: <8429B335-3CC5-4416-B897-9974E1027AD1@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Date: Fri, 26 Jun 2015 14:59:28 -0700 References: To: Netconf In-Reply-To: X-Mailer: Apple Mail (2.2098) Archived-At: Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-call-home-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2015 21:57:47 -0000 --Apple-Mail=_F8F2C2C5-6914-48A5-88D8-139ED204BDCE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 It turns out that this draft has a -08 version, which may not show up if = you just search for the html version of the draft. But here is the link = to it. https://tools.ietf.org/html/draft-ietf-netconf-call-home-08 = The WGLC is for -08 version of the draft. Cheers. > On Jun 25, 2015, at 10:21 PM, Mahesh Jethanandani = wrote: >=20 > Dear NETCONF participants, >=20 > This e-mail is a notification to start a NETCONF WG Last Call for the = document "NETCONF Call Home and RESTCONF Call Home=E2=80=9D. >=20 > The document can be found at: draft-ietf-netconf-call-home-07 = . >=20 > Please review the document, provide comments, and indicate your = support for the draft by Friday July 3 (your timezone). The comments can = be in the form of: >=20 > =E2=80=9CI have reviewed the I-D Blah and I have found issues with = it=E2=80=9D > =E2=80=9CI have reviewed I-D Blah and I found no issues=E2=80=9D >=20 > Simultaneously, the author on this draft should state to the mailing = list whether there is any IPR associated with this draft or not. >=20 > Thanks >=20 > Mahesh and Mehmet > (Co-chairs, NETCONF WG) >=20 >=20 >=20 >=20 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_F8F2C2C5-6914-48A5-88D8-139ED204BDCE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 It turns out that this draft has a -08 version, which may not = show up if you just search for the html version of the draft. But here = is the link to it.

https://tools.ietf.org/html/draft-ietf-netconf-call-home-08=

The WGLC is = for -08 version of the draft.

Cheers.
On = Jun 25, 2015, at 10:21 PM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:

Dear NETCONF = participants,

This e-mail is a notification = to start a NETCONF WG Last Call for the document "NETCONF Call Home and = RESTCONF Call Home=E2=80=9D.

The document = can be found at: draft-ietf-netconf-call-home-07.

Please review the document, provide = comments, and indicate your support for the draft by Friday July 3 (your = timezone). The comments can be in the form of:

  • =E2=80=9CI have reviewed the I-D Blah and I have found issues = with it=E2=80=9D
  • =E2=80=9CI have reviewed I-D Blah = and I found no issues=E2=80=9D

Simultaneously, the author on this = draft should state to the mailing list whether there is any IPR = associated with this draft or not.

Thanks

Mahesh and = Mehmet
(Co-chairs, NETCONF WG)





Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_F8F2C2C5-6914-48A5-88D8-139ED204BDCE-- From nobody Fri Jun 26 15:24:10 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6D21ACE35 for ; Fri, 26 Jun 2015 15:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WotyhW3QjnL9 for ; Fri, 26 Jun 2015 15:24:03 -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 D5CEC1ACE54 for ; Fri, 26 Jun 2015 15:24:03 -0700 (PDT) Received: from CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) by CO1PR05MB380.namprd05.prod.outlook.com (10.141.51.15) with Microsoft SMTP Server (TLS) id 15.1.195.15; Fri, 26 Jun 2015 22:24:03 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.1.195.15; Fri, 26 Jun 2015 22:24:01 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.100]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.100]) with mapi id 15.01.0195.005; Fri, 26 Jun 2015 22:24:01 +0000 From: Kent Watsen To: Juergen Schoenwaelder , "Mahesh Jethanandani" Thread-Topic: [Netconf] WG Last Call for draft-ietf-netconf-call-home-07 Thread-Index: AQHQr8/wgNbw1Xb4ekWUZVRu4N+Yqp2/UXGA///JegA= Date: Fri, 26 Jun 2015 22:24:01 +0000 Message-ID: References: <20150626213909.GC43864@elstar.local> In-Reply-To: <20150626213909.GC43864@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.10] x-microsoft-exchange-diagnostics: 1; CO1PR05MB457; 5:RWHEOKrPItyyIMN3z/29kZ+HBdh4/lr8OZ6XTtPPoKaDwjdgVTfpn7o/GWoKxpzm4r37ILCaU6gjyBw84jW8f5ckPXHpcvysF6cP8zJHTnOCzKcx68R0k4c6zjcRoyIYoFHO6ud2+CFXZVuhJ45Z7g==; 24:ijsDlGUMJIOfwlQkzWBA7NClHnyG9reSD1sqsprUvoeElWcBywcbMj6SYRTGYt56VoBnZMsai7PsDJ+ZaQM9I8TOFhYWWhimD6O/9/bZ83w=; 20:tb4SZiCwS7/lW1A2vcxqOgLyCXiv6eU+qmkKzCdrprbOno4JaqxC2kzA9n6JpZ8fTJw3zFo4VLBPOknp3kdSKQ== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB380; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CO1PR05MB457; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457; x-forefront-prvs: 0619D53754 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(51704005)(24454002)(377454003)(479174004)(164054003)(68736005)(2900100001)(5001960100002)(15975445007)(102836002)(66066001)(2950100001)(92566002)(83506001)(5002640100001)(4001350100001)(189998001)(97736004)(5001770100001)(50986999)(77156002)(54356999)(62966003)(76176999)(122556002)(40100003)(46102003)(230783001)(87936001)(2656002)(19580405001)(19580395003)(86362001)(99286002)(106116001)(36756003)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-ID: <0026C76F4660394D9C913E7DD5EC6CDF@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2015 22:24:01.5290 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB457 X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB380; 2:8PH+TOTlqrJd+4XYtECwYL6sNa+U+cc0ifbmO1z3+Cinp1lVcCHgJqXsumIircJ1; 3:LkkVnDoVtUivYCTM7gBPwKUuUQQr0xl+T79oyf7LQzSIxhhA35kq5b5bYnsU2ugYbppWWBDsYLQEV9giyCL86d3ybxPzeFMkZux18TQy2ZWGW2tR/pyaLtQJtK6Ot9D/vM6ln6B81piWWuOdWkHcBQ==; 23:7giR17MDaM4Bx8PG2Ek0c2+gvMOsZHq0+EtdQm8hyfC4J9rMYZJinAeXbaQVjT5xTXmeYK+MxGg7sZYGxn7HjArCCf9EXcsruXfRagef3jG85ZKMzVebnVLIY6a50QuKK6w+QYqF1R/6R7I4q/1tpzNWuJafGMiuY92WJNcZ6RwdGAihP4bJDC9V3CkU9rZIUv8Z1Tb5Zdz6iDyxUE/ogES5OcPWV87G6hO+Lfjf2LuMo0A4JGAHmwVxLLgR2zEK X-OriginatorOrg: juniper.net Archived-At: Cc: Netconf Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-call-home-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2015 22:24:08 -0000 Hi Juergen, Thank you for your review. > I do not understand the second bullet in section 1.1. It is unclear > what kind of 'mapping service' this is referring to. The mapping service here refers to something like a dynamic DNS, but I wasn't trying to lock it to DDNS. Suggestions? Thanks, Kent On 6/26/15, 5:39 PM, "Juergen Schoenwaelder" wrote: >On Thu, Jun 25, 2015 at 10:21:06PM -0700, Mahesh Jethanandani wrote: >> Dear NETCONF participants, >>=20 >> This e-mail is a notification to start a NETCONF WG Last Call for the >>document "NETCONF Call Home and RESTCONF Call Home=B2. >>=20 >> The document can be found at: draft-ietf-netconf-call-home-07 >>. >>=20 > >I have reviewed draft-ietf-netconf-call-home-08 and I have the >following comments: > >- I have no technical issues with the document and I believe it is > ready to go to the IESG. > >- I do not understand the second bullet in section 1.1. It is unclear > what kind of 'mapping service' this is referring to. > >- Nit: s/YANG [RFC6020] model/YANG [RFC6020] data model/ > >/js > >--=20 >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 From nobody Fri Jun 26 15:48:10 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 218B81AD35A for ; Fri, 26 Jun 2015 15:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xZDWfAyQve7 for ; Fri, 26 Jun 2015 15:48:07 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A49571AD36F for ; Fri, 26 Jun 2015 15:48:07 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 91C371775; Sat, 27 Jun 2015 00:48:01 +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 aHpiemTUJiI1; Sat, 27 Jun 2015 00:48:03 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sat, 27 Jun 2015 00:48:00 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C550D2002C; Sat, 27 Jun 2015 00:48:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id nmfxJ81IxP7v; Sat, 27 Jun 2015 00:48:05 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 821F22002B; Sat, 27 Jun 2015 00:48:02 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6525B3488EC8; Sat, 27 Jun 2015 00:47:58 +0200 (CEST) Date: Sat, 27 Jun 2015 00:47:57 +0200 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20150626224756.GA68380@elstar.local> Mail-Followup-To: Kent Watsen , Mahesh Jethanandani , Netconf References: <20150626213909.GC43864@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Netconf Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-call-home-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 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, 26 Jun 2015 22:48:09 -0000 On Fri, Jun 26, 2015 at 10:24:01PM +0000, Kent Watsen wrote: > Hi Juergen, > > Thank you for your review. > > > I do not understand the second bullet in section 1.1. It is unclear > > what kind of 'mapping service' this is referring to. > > > The mapping service here refers to something like a dynamic DNS, but I > wasn't trying to lock it to DDNS. Suggestions? > Simply add '(e.g., dynamic DNS)'? This would have helped me. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sat Jun 27 01:19:32 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D06461B3227; Sat, 27 Jun 2015 01:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.311 X-Spam-Level: X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_61=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NiPvTCAiVsEj; Sat, 27 Jun 2015 01:19:29 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 582CC1B3226; Sat, 27 Jun 2015 01:19:29 -0700 (PDT) Received: from localhost (h-85-24-195-9.na.cust.bahnhof.se [85.24.195.9]) by mail.tail-f.com (Postfix) with ESMTPSA id 4C1A21AE047A; Sat, 27 Jun 2015 10:19:27 +0200 (CEST) Date: Sat, 27 Jun 2015 10:19:27 +0200 (CEST) Message-Id: <20150627.101927.980507351929498326.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20150626.105907.1929816701749723248.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [Netconf] [netmod] Y45-04 and ietf-yang-library X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2015 08:19:31 -0000 Andy Bierman wrote: > On Fri, Jun 26, 2015 at 1:59 AM, Martin Bjorklund wrote: > > > Andy Bierman wrote: > > > On Wed, Jun 24, 2015 at 2:14 PM, Martin Bjorklund > > wrote: > > > > > > > Hi, > > > > > > > > I am preparing a new version of draft-ietf-netmod-rfc6020bis in order > > > > to address Y45-04. Note that YANG 1.1 uses the module > > > > ietf-yang-library from draft-ietf-netconf-yang-library (hence the > > > > crossposting). > > > > > > > > [BTW, shouldn't ietf-yang-library be moved to NETMOD?] > > > > > > > > We have a whole bunch of documents that have a normative reference to > > > > draft-ietf-netmod-rfc6020bis, which has a normative reference to > > > > draft-ietf-netconf-yang-library. This means we need to finish this > > > > document pretty soon. > > > > > > > > I ran into some issues with ietf-yang-library: > > > > > > > > 1. The leaf "conformance" is of type "boolean". It is not obvious > > > > what "conformance = false" means. Should we change the name > > > > and/or type of this leaf? > > > > > > > > > > > > > > Here is a proposal. > > > > Thanks, I think this is good progress. > > > > > There are no restrictions about how many revisions can appear > > > in order to support existing YANG 1.0 servers, which have > > > no such restrictions. > > > > I don't think this is an important goal. I also think that this > > module should have yang-version 1.1 - which all modules will have > > going forward. > > > > But if we combine what both of us have said there are two goals with > > this module: > > > > 1. Solve the advertisement problem (protocol independent). > > > > 2. Provide a complete listing of all YANG modules used in the > > server. > > > > I believe that your proposed solution below can solve both these > > requirements (with some minor tweaks): > > > > > leaf conformance > > > mandatory true; > > > type enumeration { > > > enum implement { > > > description > > > "The server implements the specified revision of this > > module"; > > > > Ok. We need to clearly define what "implement" a module means. I > > have started to do this in 6020bis, so we should provide a ref to that > > section. > > > > > } > > > enum import { > > > description > > > "The server imports the specified revision of this > > module"; > > > > This should be more precise - "the server uses the specified revision > > of this module for all other modules that import this module without > > revision". > > > > > } > > > enum none { > > > description > > > "The server does not use the specified revision of this > > > module. > > > The server only supports retrieval of this YANG > > module."; > > > > I don't think this is correct. The server would list a typedef only > > module that is imported by revision here, right? I think it should > > be something like "the server uses the specified revision of this > > module because some other module imports this revision". > > > > We should also say: > > > > There MUST NOT be more than one listing with conformance "implemented" > > for a given module name. > > > > > This is not true for YANG 1.0, only YANG 1.1 How can you implement two revisions of a module in YANG 1.0? IMO it is not possible. > > There MUST NOT be more than one listing with conformance "import" > > for a given module name. > > > > > There are no restrictions on YANG for what is contained in the same module. > > Module X can have typedefs, groupings, and objects. > The server implements the objects in X.5. > According to YANG 1.1, Y45-04: > Module A can import X.1 for its typedefs. > Module B can import X.2 for a different version of the typedefs. > Module C can import X.3 for the groupings in that version. > > The library will have these entries: > > module=A, revision=1, conformance=implement > module=B, revision=1, conformance=implement > module=C, revision=1, conformance=implement Ok. > module=X, revision=1, conformance=import > module=X, revision=2, conformance=import > module=X, revision=3, conformance=import I would say that all these should be conformace=none. Or maybe a new enum if you prefer. I have tried to explain the rationale for this, but apparently I have failed. The problem is that if module D imports X without revision, the client needs to be able to determine which revision of X the server uses. > module=X, revision=5, conformance=implement > > > > > How is a deviation module listed? Does the conformance leaf matter > > for such a module? > > > > > I think 'deviation' should be its own enum, not use 'none' But as you wrote above, deviations can be mixed with other statements, so a module cannot be classified as "deviation" only. > The nice thing about enum 'import' is that the server does not need to > provide deviation statements for any objects in the base module, > just to import from the module. /martin From nobody Sat Jun 27 08:50:11 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEC581B2E1E for ; Sat, 27 Jun 2015 08:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bt_e0mBzzuyN for ; Sat, 27 Jun 2015 08:50:04 -0700 (PDT) Received: from mail-la0-f52.google.com (mail-la0-f52.google.com [209.85.215.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F41D1B2E5A for ; Sat, 27 Jun 2015 08:50:04 -0700 (PDT) Received: by laar3 with SMTP id r3so22936571laa.0 for ; Sat, 27 Jun 2015 08:50:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3mVyxaI4kahQokfx89c3T4LN8TjRE0Q2xy4IcpqV7/w=; b=VE/+VZTRacaQrR/NoX6mHbluvRWx2gN1wOvnlPaPjiMG+eqy04Ys3YM00SEGa4K2kz +ghRMA6hhSKSaG2TyhkJ+6C99Gj29FfqqyutyOiRjaF3w5AIDntpUuOh5HyL0TF9F2of ZDonEOgquF6MqcR7P+3KNZRyRlDX4j6u8vTYSN3q9TXG1AUHviLz6Jq6h6cFZUZC2a88 H8+qrxFR4JmaepXPXl5G8166qi95lt8zqlIRaV9vOlhLFjsJ+C7RuuhrVmb5Ohr4sMSe KH4lmJ3715A8puFJG8QOPfHo3n23JgqqXQiTlp3GdCeVivifK2QHGADYiKkjks6ajB0F D/XQ== X-Gm-Message-State: ALoCoQlvfg2e+ylsr0k+TXWlMLz37sHEV2W9A6+SO/XxRHfyToo6r6/VY5uuf7VWe5tYifa7jgvt MIME-Version: 1.0 X-Received: by 10.152.7.65 with SMTP id h1mr6431225laa.33.1435420202337; Sat, 27 Jun 2015 08:50:02 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Sat, 27 Jun 2015 08:50:02 -0700 (PDT) In-Reply-To: <20150627.101927.980507351929498326.mbj@tail-f.com> References: <20150626.105907.1929816701749723248.mbj@tail-f.com> <20150627.101927.980507351929498326.mbj@tail-f.com> Date: Sat, 27 Jun 2015 08:50:02 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11c27cf043a7b6051981cfc0 Archived-At: Cc: Netconf , "netmod@ietf.org" Subject: Re: [Netconf] [netmod] Y45-04 and ietf-yang-library X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2015 15:50:07 -0000 --001a11c27cf043a7b6051981cfc0 Content-Type: text/plain; charset=UTF-8 On Sat, Jun 27, 2015 at 1:19 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Fri, Jun 26, 2015 at 1:59 AM, Martin Bjorklund > wrote: > > > > > Andy Bierman wrote: > > > > On Wed, Jun 24, 2015 at 2:14 PM, Martin Bjorklund > > > wrote: > > > > > > > > > Hi, > > > > > > > > > > I am preparing a new version of draft-ietf-netmod-rfc6020bis in > order > > > > > to address Y45-04. Note that YANG 1.1 uses the module > > > > > ietf-yang-library from draft-ietf-netconf-yang-library (hence the > > > > > crossposting). > > > > > > > > > > [BTW, shouldn't ietf-yang-library be moved to NETMOD?] > > > > > > > > > > We have a whole bunch of documents that have a normative reference > to > > > > > draft-ietf-netmod-rfc6020bis, which has a normative reference to > > > > > draft-ietf-netconf-yang-library. This means we need to finish this > > > > > document pretty soon. > > > > > > > > > > I ran into some issues with ietf-yang-library: > > > > > > > > > > 1. The leaf "conformance" is of type "boolean". It is not > obvious > > > > > what "conformance = false" means. Should we change the name > > > > > and/or type of this leaf? > > > > > > > > > > > > > > > > > > Here is a proposal. > > > > > > Thanks, I think this is good progress. > > > > > > > There are no restrictions about how many revisions can appear > > > > in order to support existing YANG 1.0 servers, which have > > > > no such restrictions. > > > > > > I don't think this is an important goal. I also think that this > > > module should have yang-version 1.1 - which all modules will have > > > going forward. > > > > > > But if we combine what both of us have said there are two goals with > > > this module: > > > > > > 1. Solve the advertisement problem (protocol independent). > > > > > > 2. Provide a complete listing of all YANG modules used in the > > > server. > > > > > > I believe that your proposed solution below can solve both these > > > requirements (with some minor tweaks): > > > > > > > leaf conformance > > > > mandatory true; > > > > type enumeration { > > > > enum implement { > > > > description > > > > "The server implements the specified revision of this > > > module"; > > > > > > Ok. We need to clearly define what "implement" a module means. I > > > have started to do this in 6020bis, so we should provide a ref to that > > > section. > > > > > > > } > > > > enum import { > > > > description > > > > "The server imports the specified revision of this > > > module"; > > > > > > This should be more precise - "the server uses the specified revision > > > of this module for all other modules that import this module without > > > revision". > It is true in YANG 1.1 that the revision used if no import-date is given in the import-stmt, if the server implements some specific revision. If not, then good luck figuring out which one to use. Is this a new requirement you are adding that all import-without-revision of X refer to just 1 revision of X? > > > > > > } > > > > enum none { > > > > description > > > > "The server does not use the specified revision of > this > > > > module. > > > > The server only supports retrieval of this YANG > > > module."; > > > > > > I don't think this is correct. The server would list a typedef only > > > module that is imported by revision here, right? I think it should > > > be something like "the server uses the specified revision of this > > > module because some other module imports this revision". > > > > > > We should also say: > > > > > > There MUST NOT be more than one listing with conformance > "implemented" > > > for a given module name. > > > > > > > > > This is not true for YANG 1.0, only YANG 1.1 > > How can you implement two revisions of a module in YANG 1.0? IMO it > is not possible. > > > > There MUST NOT be more than one listing with conformance "import" > > > for a given module name. > > > > > > > > There are no restrictions on YANG for what is contained in the same > module. > > > > Module X can have typedefs, groupings, and objects. > > The server implements the objects in X.5. > > According to YANG 1.1, Y45-04: > > Module A can import X.1 for its typedefs. > > Module B can import X.2 for a different version of the typedefs. > > Module C can import X.3 for the groupings in that version. > > > > The library will have these entries: > > > > module=A, revision=1, conformance=implement > > module=B, revision=1, conformance=implement > > module=C, revision=1, conformance=implement > > Ok. > > > module=X, revision=1, conformance=import > > module=X, revision=2, conformance=import > > module=X, revision=3, conformance=import > > I would say that all these should be conformace=none. Or maybe a new > enum if you prefer. > > The module X example above could all be import-by-revision. All this example, modules, A, B, and C just use typedefs and groupings from module A. Even in RFC 6020 (sec. 7.1.5) it is quite clear that each of these modules (A, B ,C) can import their own revision of module A. When the optional "revision-date" substatement is present, any typedef, grouping, extension, feature, and identity referenced by definitions in the local module are taken from the specified revision of the imported module. It is an error if the specified revision of the imported module does not exist. If no "revision-date" substatement is present, it is undefined from which revision of the module they are taken. Note that this text says import-without-revision does not require the server to use any specific revision. Are you proposing a new YANG 1.1 issue, and trying to change this paragraph? In the example, let's say A and B import X by revision but C does not. This list does not help a client figure out which entry for X was used. As you pointed out to the WG, the only way to do that would be to replicate all the nested import-stmts for a module and add any missing revision dates. > I have tried to explain the rationale for this, but apparently I have > failed. The problem is that if module D imports X without revision, > the client needs to be able to determine which revision of X the > server uses. > > No --- the current RFC says that is not possible. There is no way to do that. What if module X is not implemented at all, just the typedefs and groupings used? module A { ... import X { revision 2014-01-01; prefix x; } revision 2014-06-01; } module B { ... import X { prefix x; } revision 2015-02-01; } module C { ... import X { revision 2015-01-01; prefix x; } revision 2015-06-01; } module=A, revision=2014-06-01, conformance=implement module=B, revision=2015-02-01, conformance=implement module=C, revision=2015-06-01, conformance=implement module=X, revision=2014-01-01, conformance=import module=X, revision=2015-06-01, conformance=import In this case, the client has no idea which revision of X is imported by B. The library narrows the choice from all revisions to 2 in this example. What if modules A, B, C, and X import other modules, which in turn import other modules? YANG clearly allows each one to import a specific revision or leave the revision completely unspecified. I think you are suggesting a new rule and maybe a new leaf, sibling of the 'conformance' leaf: leaf default-revision { type boolean; default false; description "Indicates that this revision is used by the server if this module is imported without a specific revision date."; } I can't think of any reason this could not be implemented in a YANG 1.1 server. It is quite clear YANG 1.0 imports cannot be restricted in this way. > > module=X, revision=5, conformance=implement > > > > > > > > > How is a deviation module listed? Does the conformance leaf matter > > > for such a module? > > > > > > > > I think 'deviation' should be its own enum, not use 'none' > > But as you wrote above, deviations can be mixed with other statements, > so a module cannot be classified as "deviation" only. > It is true that deviations can be combined with regular objects, except it is not allowed in IETF modules. In practice this does not work because the regular modules are shared by all the vendor platforms. The deviations are platform-specific so they are done in their own module. I would suggest conformance 'none' for deviations. > > The nice thing about enum 'import' is that the server does not need to > > provide deviation statements for any objects in the base module, > > just to import from the module. > > > /martin > Andy --001a11c27cf043a7b6051981cfc0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Jun 27, 2015 at 1:19 AM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Fri, Jun 26, 2015 at 1:59 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Andy Bierman <andy@yumaw= orks.com> wrote:
> > > On Wed, Jun 24, 2015 at 2:14 PM, Martin Bjorklund <mbj@tail-f.com>
> > wrote:
> > >
> > > > Hi,
> > > >
> > > > I am preparing a new version of draft-ietf-netmod-rfc60= 20bis in order
> > > > to address Y45-04.=C2=A0 Note that YANG 1.1 uses the mo= dule
> > > > ietf-yang-library from draft-ietf-netconf-yang-library = (hence the
> > > > crossposting).
> > > >
> > > > [BTW, shouldn't ietf-yang-library be moved to NETMO= D?]
> > > >
> > > > We have a whole bunch of documents that have a normativ= e reference to
> > > > draft-ietf-netmod-rfc6020bis, which has a normative ref= erence to
> > > > draft-ietf-netconf-yang-library.=C2=A0 This means we ne= ed to finish this
> > > > document pretty soon.
> > > >
> > > > I ran into some issues with ietf-yang-library:
> > > >
> > > >=C2=A0 =C2=A01.=C2=A0 The leaf "conformance" i= s of type "boolean".=C2=A0 It is not obvious
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0what "conformance =3D fa= lse" means.=C2=A0 Should we change the name
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0and/or type of this leaf?
> > > >
> > > >
> > >
> > > Here is a proposal.
> >
> > Thanks, I think this is good progress.
> >
> > > There are no restrictions about how many revisions can appea= r
> > > in order to support existing YANG 1.0 servers, which have > > > no such restrictions.
> >
> > I don't think this is an important goal.=C2=A0 I also think t= hat this
> > module should have yang-version 1.1 - which all modules will have=
> > going forward.
> >
> > But if we combine what both of us have said there are two goals w= ith
> > this module:
> >
> >=C2=A0 =C2=A01.=C2=A0 Solve the advertisement problem (protocol in= dependent).
> >
> >=C2=A0 =C2=A02.=C2=A0 Provide a complete listing of all YANG modul= es used in the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0server.
> >
> > I believe that your proposed solution below can solve both these<= br> > > requirements (with some minor tweaks):
> >
> > >=C2=A0 =C2=A0 =C2=A0leaf conformance
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0type enumeration {
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 enum implement {
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"= The server implements the specified revision of this
> > module";
> >
> > Ok.=C2=A0 We need to clearly define what "implement" a = module means.=C2=A0 I
> > have started to do this in 6020bis, so we should provide a ref to= that
> > section.
> >
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 enum import {
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "= ;The server imports the specified revision of this
> > module";
> >
> > This should be more precise - "the server uses the specified= revision
> > of this module for all other modules that import this module with= out
> > revision".


It is true in YANG 1.1 that the revision used if no import-date
is given in the import-stmt, if the server implements some specific
<= div>revision.=C2=A0 If not, then good luck figuring out which one to use.

Is this a new requirement you are adding that all i= mport-without-revision
of X refer to just 1 revision of X?
<= div>

> >
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enum none {
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "= ;The server does not use the specified revision of this
> > > module.
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 The server only supports retrieval of this YANG
> > module.";
> >
> > I don't think this is correct.=C2=A0 The server would list a = typedef only
> > module that is imported by revision here, right?=C2=A0 =C2=A0I th= ink it should
> > be something like "the server uses the specified revision of= this
> > module because some other module imports this revision".
> >
> > We should also say:
> >
> >=C2=A0 =C2=A0There MUST NOT be more than one listing with conforma= nce "implemented"
> >=C2=A0 =C2=A0for a given module name.
> >
>
>
> This is not true for YANG 1.0, only YANG 1.1

How can you implement two revisions of a module in YANG 1.0?=C2=A0 IMO it is not possible.

> >=C2=A0 =C2=A0There MUST NOT be more than one listing with conforma= nce "import"
> >=C2=A0 =C2=A0for a given module name.
> >
> >
> There are no restrictions on YANG for what is contained in the same mo= dule.
>
> Module X can have typedefs, groupings, and objects.
> The server implements the objects in X.5.
> According to YANG 1.1, Y45-04:
> Module A can import X.1 for its typedefs.
> Module B can import X.2 for a different version of the typedefs.
> Module C can import X.3 for the groupings in that version.
>
> The library will have these entries:
>
>=C2=A0 =C2=A0 =C2=A0module=3DA, revision=3D1, conformance=3Dimplement >=C2=A0 =C2=A0 =C2=A0module=3DB, revision=3D1, conformance=3Dimplement >=C2=A0 =C2=A0 =C2=A0module=3DC, revision=3D1, conformance=3Dimplement
Ok.

>=C2=A0 =C2=A0 =C2=A0module=3DX, revision=3D1, conformance=3Dimport
>=C2=A0 =C2=A0 =C2=A0module=3DX, revision=3D2, conformance=3Dimport
>=C2=A0 =C2=A0 =C2=A0module=3DX, revision=3D3, conformance=3Dimport

I would say that all these should be conformace=3Dnone.=C2=A0 Or maybe a ne= w
enum if you prefer.



The module X example ab= ove could all be import-by-revision.
All this example, modules, A= , B, and C just use typedefs and groupings
from module A.=C2=A0 E= ven in RFC 6020 (sec. 7.1.5) it is quite clear that
each of these= modules (A, B ,C) can import their own revision of module A.


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

Note that this text says import-without-revisio= n does not require the server to
use any specific revision.=C2=A0= Are you proposing a new YANG 1.1 issue,
and trying to change thi= s paragraph?

In the example, let's say A and B= import X by revision but C does not.
This list does not help a c= lient figure out which entry for X was used.
As you pointed out t= o the WG, the only way to do that would be
to replicate all the n= ested import-stmts for a module and add
any missing revision date= s.


=C2=A0
I have tried to explain the rationale for this, but apparently I have
failed.=C2=A0 The problem is that if module D imports X without revision, the client needs to be able to determine which revision of X the
server uses.



No --- the current RFC = says that is not possible.
There is no way to do that. What if mo= dule X is not implemented
at all, just the typedefs and groupings= used?


=C2=A0 =C2=A0module A {
=C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 =C2=A0import X { rev= ision 2014-01-01; prefix x; }
=C2=A0 =C2=A0 =C2=A0revision 2014-0= 6-01;
=C2=A0 =C2=A0}

=C2=A0 =C2=A0m= odule B {
=C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 =C2=A0= import X { prefix x; }
=C2=A0 =C2=A0 =C2=A0revision 2015-02-01;
=C2=A0 =C2=A0}

=C2=A0 modu= le C {
=C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 =C2=A0imp= ort X { revision 2015-01-01; prefix x; }
=C2=A0 =C2=A0 =C2=A0revi= sion 2015-06-01;
=C2=A0 =C2=A0}


=C2=A0 =C2=A0 =C2=A0module=3DA, revision=3D2014-06-01, con= formance=3Dimplement
=C2=A0 =C2=A0 =C2=A0module=3DB, revision=3D2015-02-= 01, conformance=3Dimplement
=C2=A0 =C2=A0 =C2=A0module=3DC, revision=3D2= 015-06-01, conformance=3Dimplement
=C2=A0 =C2=A0 =C2=A0module=3DX, revis= ion=3D2014-01-01, conformance=3Dimport
=C2=A0 =C2=A0 =C2=A0module=3DX, r= evision=3D2015-06-01, conformance=3Dimport


In this case, the client has no idea which revision of X is imported by B.=
The library narrows the choice from all revisions to 2 in this e= xample.

What if modules A, B, C, and X import othe= r modules,
which in turn import other modules?=C2=A0 YANG clearly= allows
each one to import a specific revision or leave the revis= ion
completely unspecified.=C2=A0

I thin= k you are suggesting a new rule and maybe a new leaf,
sibling of = the 'conformance' leaf:

=C2=A0 =C2=A0leaf = default-revision {
=C2=A0 =C2=A0 =C2=A0 type boolean;
= =C2=A0 =C2=A0 =C2=A0 default false;
=C2=A0 =C2=A0 =C2=A0 descript= ion
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Indicates that this r= evision is used by the server if this module
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 is imported without a specific revision date.";
=C2=A0 =C2=A0 }

I can't think of any reason= this could not be implemented
in a YANG 1.1 server.=C2=A0 It is = quite clear YANG 1.0 imports
cannot be restricted in this way.

=C2=A0
>=C2=A0 =C2=A0 =C2=A0module=3DX, revision=3D5, conformance=3Dimplement >
>
>
> > How is a deviation module listed?=C2=A0 Does the conformance leaf= matter
> > for such a module?
> >
> >
> I think 'deviation' should be its own enum, not use 'none&= #39;

But as you wrote above, deviations can be mixed with other statements,
so a module cannot be classified as "deviation" only.


It is true that deviations can be c= ombined with regular objects,
except it is not allowed in IETF mo= dules. In practice this does not work
because the regular modules= are shared by all the vendor platforms.
The deviations are platf= orm-specific so they are done in their own module.
I would sugges= t conformance 'none' for deviations.


<= /div>

> The nice thing about enum 'import' is that the server does not= need to
> provide deviation statements for any objects in the base module,
> just to import from the module.


/martin


<= /div>
Andy

--001a11c27cf043a7b6051981cfc0-- From nobody Sun Jun 28 01:11:21 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 258961ACDD0; Sun, 28 Jun 2015 01:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.311 X-Spam-Level: X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_61=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kudxnq77lsof; Sun, 28 Jun 2015 01:11:18 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id CA2D11ACDCD; Sun, 28 Jun 2015 01:11:17 -0700 (PDT) Received: from localhost (h-85-24-195-9.na.cust.bahnhof.se [85.24.195.9]) by mail.tail-f.com (Postfix) with ESMTPSA id B42C51AE00DA; Sun, 28 Jun 2015 10:11:15 +0200 (CEST) Date: Sun, 28 Jun 2015 10:11:15 +0200 (CEST) Message-Id: <20150628.101115.524154870753102418.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20150627.101927.980507351929498326.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [Netconf] [netmod] Y45-04 and ietf-yang-library X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2015 08:11:20 -0000 Andy Bierman wrote: > On Sat, Jun 27, 2015 at 1:19 AM, Martin Bjorklund wrote: > > > Andy Bierman wrote: > > > On Fri, Jun 26, 2015 at 1:59 AM, Martin Bjorklund > > wrote: > > > > > > > Andy Bierman wrote: > > > > > On Wed, Jun 24, 2015 at 2:14 PM, Martin Bjorklund > > > > wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > > I am preparing a new version of draft-ietf-netmod-rfc6020bis in > > order > > > > > > to address Y45-04. Note that YANG 1.1 uses the module > > > > > > ietf-yang-library from draft-ietf-netconf-yang-library (hence the > > > > > > crossposting). > > > > > > > > > > > > [BTW, shouldn't ietf-yang-library be moved to NETMOD?] > > > > > > > > > > > > We have a whole bunch of documents that have a normative reference > > to > > > > > > draft-ietf-netmod-rfc6020bis, which has a normative reference to > > > > > > draft-ietf-netconf-yang-library. This means we need to finish this > > > > > > document pretty soon. > > > > > > > > > > > > I ran into some issues with ietf-yang-library: > > > > > > > > > > > > 1. The leaf "conformance" is of type "boolean". It is not > > obvious > > > > > > what "conformance = false" means. Should we change the name > > > > > > and/or type of this leaf? > > > > > > > > > > > > > > > > > > > > > > Here is a proposal. > > > > > > > > Thanks, I think this is good progress. > > > > > > > > > There are no restrictions about how many revisions can appear > > > > > in order to support existing YANG 1.0 servers, which have > > > > > no such restrictions. > > > > > > > > I don't think this is an important goal. I also think that this > > > > module should have yang-version 1.1 - which all modules will have > > > > going forward. > > > > > > > > But if we combine what both of us have said there are two goals with > > > > this module: > > > > > > > > 1. Solve the advertisement problem (protocol independent). > > > > > > > > 2. Provide a complete listing of all YANG modules used in the > > > > server. > > > > > > > > I believe that your proposed solution below can solve both these > > > > requirements (with some minor tweaks): > > > > > > > > > leaf conformance > > > > > mandatory true; > > > > > type enumeration { > > > > > enum implement { > > > > > description > > > > > "The server implements the specified revision of this > > > > module"; > > > > > > > > Ok. We need to clearly define what "implement" a module means. I > > > > have started to do this in 6020bis, so we should provide a ref to that > > > > section. > > > > > > > > > } > > > > > enum import { > > > > > description > > > > > "The server imports the specified revision of this > > > > module"; > > > > > > > > This should be more precise - "the server uses the specified revision > > > > of this module for all other modules that import this module without > > > > revision". > > > > > It is true in YANG 1.1 that the revision used if no import-date > is given in the import-stmt, if the server implements some specific > revision. If not, then good luck figuring out which one to use. > > Is this a new requirement you are adding that all import-without-revision > of X refer to just 1 revision of X? I thought this was discussed and decided. The idea being that in a specific server, all import-without-revision of X refers to exactly one revision of X. > > > > > } > > > > > enum none { > > > > > description > > > > > "The server does not use the specified revision of > > this > > > > > module. > > > > > The server only supports retrieval of this YANG > > > > module."; > > > > > > > > I don't think this is correct. The server would list a typedef only > > > > module that is imported by revision here, right? I think it should > > > > be something like "the server uses the specified revision of this > > > > module because some other module imports this revision". > > > > > > > > We should also say: > > > > > > > > There MUST NOT be more than one listing with conformance > > "implemented" > > > > for a given module name. > > > > > > > > > > > > > This is not true for YANG 1.0, only YANG 1.1 > > > > How can you implement two revisions of a module in YANG 1.0? IMO it > > is not possible. > > > > > > There MUST NOT be more than one listing with conformance "import" > > > > for a given module name. > > > > > > > > > > > There are no restrictions on YANG for what is contained in the same > > module. > > > > > > Module X can have typedefs, groupings, and objects. > > > The server implements the objects in X.5. > > > According to YANG 1.1, Y45-04: > > > Module A can import X.1 for its typedefs. > > > Module B can import X.2 for a different version of the typedefs. > > > Module C can import X.3 for the groupings in that version. > > > > > > The library will have these entries: > > > > > > module=A, revision=1, conformance=implement > > > module=B, revision=1, conformance=implement > > > module=C, revision=1, conformance=implement > > > > Ok. > > > > > module=X, revision=1, conformance=import > > > module=X, revision=2, conformance=import > > > module=X, revision=3, conformance=import > > > > I would say that all these should be conformace=none. Or maybe a new > > enum if you prefer. > > > > > > The module X example above could all be import-by-revision. > All this example, modules, A, B, and C just use typedefs and groupings > from module A. Even in RFC 6020 (sec. 7.1.5) it is quite clear that > each of these modules (A, B ,C) can import their own revision of module A. > > > > When the optional "revision-date" substatement is present, any > typedef, grouping, extension, feature, and identity referenced by > definitions in the local module are taken from the specified revision > of the imported module. It is an error if the specified revision of > the imported module does not exist. If no "revision-date" > substatement is present, it is undefined from which revision of the > module they are taken. > > > Note that this text says import-without-revision does not require the > server to > use any specific revision. The text means that from a modelling perspective, the revision is not fixed. A server will of course use some revision. > Are you proposing a new YANG 1.1 issue, > and trying to change this paragraph? No. > In the example, let's say A and B import X by revision but C does not. > This list does not help a client figure out which entry for X was used. > As you pointed out to the WG, the only way to do that would be > to replicate all the nested import-stmts for a module and add > any missing revision dates. > > > > > > I have tried to explain the rationale for this, but apparently I have > > failed. The problem is that if module D imports X without revision, > > the client needs to be able to determine which revision of X the > > server uses. > > > > > > No --- the current RFC says that is not possible. I don't think it does. But more importantly, do you agree that the server will use one revision of X? If so, wouldn't it be good to inform the client about which revision is used? > There is no way to do that. What if module X is not implemented > at all, just the typedefs and groupings used? > > > module A { > ... > import X { revision 2014-01-01; prefix x; } > revision 2014-06-01; > } > > module B { > ... > import X { prefix x; } > revision 2015-02-01; > } > > module C { > ... > import X { revision 2015-01-01; prefix x; } > revision 2015-06-01; > } > > > module=A, revision=2014-06-01, conformance=implement > module=B, revision=2015-02-01, conformance=implement > module=C, revision=2015-06-01, conformance=implement > module=X, revision=2014-01-01, conformance=import > module=X, revision=2015-06-01, conformance=import > > > In this case, the client has no idea which revision of X is imported by B. > The library narrows the choice from all revisions to 2 in this example. Exactly. This is the problem I thought we're trying to solve. How about we introduce conformace=import-by-revision in addition to conformace=import. Then the above example would be module=X, revision=2014-01-01, conformance=import-by-revision module=X, revision=2015-06-01, conformance=import > What if modules A, B, C, and X import other modules, > which in turn import other modules? YANG clearly allows > each one to import a specific revision or leave the revision > completely unspecified. > > I think you are suggesting a new rule and maybe a new leaf, > sibling of the 'conformance' leaf: > > leaf default-revision { > type boolean; > default false; > description > "Indicates that this revision is used by the server if this module > is imported without a specific revision date."; > } Yes this would also work, I think. Or conformance import-by-revision/import or import/import-default-revision. > I can't think of any reason this could not be implemented > in a YANG 1.1 server. It is quite clear YANG 1.0 imports > cannot be restricted in this way. > > > > > > module=X, revision=5, conformance=implement > > > > > > > > > > > > > How is a deviation module listed? Does the conformance leaf matter > > > > for such a module? > > > > > > > > > > > I think 'deviation' should be its own enum, not use 'none' > > > > But as you wrote above, deviations can be mixed with other statements, > > so a module cannot be classified as "deviation" only. > > > > > It is true that deviations can be combined with regular objects, > except it is not allowed in IETF modules. In practice this does not work > because the regular modules are shared by all the vendor platforms. > The deviations are platform-specific so they are done in their own module. > I would suggest conformance 'none' for deviations. Sounds good. /martin > > > > > > The nice thing about enum 'import' is that the server does not need to > > > provide deviation statements for any objects in the base module, > > > just to import from the module. > > > > > > /martin > > > > > Andy From nobody Sun Jun 28 23:10:08 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D94E1A1A46; Sun, 28 Jun 2015 23:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyBoGW8EN2D6; Sun, 28 Jun 2015 23:10:03 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A44641A1A45; Sun, 28 Jun 2015 23:10:02 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D53AF1440; Mon, 29 Jun 2015 08:10:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id n0OSkE-zY7WP; Mon, 29 Jun 2015 08:09:57 +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, 29 Jun 2015 08:09:59 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 576F32002B; Mon, 29 Jun 2015 08:09:59 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id A7sRYY7bolii; Mon, 29 Jun 2015 08:09:57 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AC40520013; Mon, 29 Jun 2015 08:09:56 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3E9A234E2DF6; Mon, 29 Jun 2015 08:09:55 +0200 (CEST) Date: Mon, 29 Jun 2015 08:09:54 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20150629060954.GB32652@elstar.local> Mail-Followup-To: Martin Bjorklund , andy@yumaworks.com, netconf@ietf.org, netmod@ietf.org References: <20150625.101417.2199972820527866360.mbj@tail-f.com> <20150625.213307.987589961886974156.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150625.213307.987589961886974156.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod@ietf.org, netconf@ietf.org Subject: Re: [Netconf] [netmod] Y45-04 and ietf-yang-library X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 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, 29 Jun 2015 06:10:05 -0000 On Thu, Jun 25, 2015 at 09:33:07PM +0200, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Thu, Jun 25, 2015 at 1:14 AM, Martin Bjorklund wrote: > > > > > Andy Bierman wrote: > > > > On Wed, Jun 24, 2015 at 2:14 PM, Martin Bjorklund > > > wrote: > > > > > > > > > Hi, > > > > > > > > > > I am preparing a new version of draft-ietf-netmod-rfc6020bis in order > > > > > to address Y45-04. Note that YANG 1.1 uses the module > > > > > ietf-yang-library from draft-ietf-netconf-yang-library (hence the > > > > > crossposting). > > > > > > > > > > [BTW, shouldn't ietf-yang-library be moved to NETMOD?] > > > > > > > > > > We have a whole bunch of documents that have a normative reference to > > > > > draft-ietf-netmod-rfc6020bis, which has a normative reference to > > > > > draft-ietf-netconf-yang-library. This means we need to finish this > > > > > document pretty soon. > > > > > > > > > > I ran into some issues with ietf-yang-library: > > > > > > > > > > 1. The leaf "conformance" is of type "boolean". It is not obvious > > > > > what "conformance = false" means. Should we change the name > > > > > and/or type of this leaf? > > > > > > > > > > I don't have a good proposal, but what we need is a way to > > > > > indicate "I implement the protocol accessible nodes in this > > > > > module" vs. "I just list this module b/c some other module that > > > > > I implement uses typdefs/groupings/... from it". > > > > > > > > > > This issue is related to the github issue #3. I think we need > > > > > this information; Y45-04 relies on it. > > > > > > > > > > > > > > > > > > We went through this before and you didn't have a better suggestion last > > > > time either. > > > > > > > > conformance=false means the server is not claiming conformance for this > > > > module. > > > > > > Yes I know. I just wish we had a better name for this. But you're > > > right, if we can't come up with a better term, we'll stick to what we > > > have. > > > > > > > A NETCONF should not have any modules tagged > > > > as conformance=false. > > > > > > > > CoMI relies on this module as well. > > > > It has been ready for WGLC since January. > > > > > > > > > > > > > > > > > > > > > > > > > > 2. The "/modules/module" list is keyed by "name" and "revision". > > > > > Should we really have "revision" as key? A server can only > > > > > implement one revision of a module, and should only list one > > > > > revision of a module w/ conformance = false. I suggest we make > > > > > this leaf mandatory, and not part of the key. > > > > > > > > > > > > > > > > > I am not in favor of this change. > > > > Two modules "foo" and "bar" released on the same date > > > > could not be represented. > > > > > > The name of the module would be the (single) key, so this should be > > > possible. > > > > > > > > > > This does not work. > > > > > > > > > > I think the indexing is fine in the current draft. > > > > The operation in NETCONF and RESTCONF need > > > > the module name and the revision-date. > > > > > > Yes, revision must be mandatory. > > > > > > > Unless revision is the key then only 1 revision of the module is possible. > > Correct. We agreed that a server cannot implement more than one > version of a module (i.e., conformance = true). And the reason for > listing other modules (conformance = false) is for the client to learn > which revision of such a module is used by the server in modules that > import them without revision. Again, there must only be one such > revision. > > An example might help. > > Suppose we have a typedef only module "t", and three modules "a", > "b", and "c" importing it: > > module a { > ... > import t { > prefix t; // note: no revision-date > } > ... > } > > module b { > ... > import t { > prefix t; > revision-date 2015-01-01; > } > ... > } > > module c { > ... > import t { > prefix t; > revision-date 2015-02-02; > } > ... > } > > module t { > ... > revision 2015-02-02; > revision 2015-01-01; > ... > } > > Now the server lists in ietf-yang-library: > > modules: > module: > name: t > revision: 2015-01-01; > conformance: false > module: > name: t > revision: 2015-02-02; > conformance: false > ... > > A client downloads all modules from the server. Now, how can the > client tell which revsion of "t" was used to implement "a"? > > I can se two solutions: > > 1. Just list one revision of "t" - the one used to implement module > "a" (and any other module that imports "t" w/o revision). > > There really is no reason to list the other revsion of "t". > > 2. List both revisions of "t", but mark the one that is used to > implement module "a" in some way. Note that you can have two modules importing t without a revision and the two modules may use different versions of t. If so, then it seems the indexing we have is right since you may need to list multiple revisions of t. If the requirement is to announce which version of t has been used by module a, then it seems you need to kind of list the imports with the revisions actually used in the data model, no? > > > > This module should not care how many revisions of each module > > > > are listed. This is the full YANG library, not a message. > > > > > > The whole point of this module is to replace the message! It > > > first came up in RESTCONF, and we want to use it also in NETCONF in > > > order to have one single way to do YANG module advertisement > > > regardless of protocol. > > > > > > There is already the schema list in ietf-netconf-monitoring that gives > > > you the full set of modules and submodules used in a server. > > > > > > > > > > We already discussed relation to the schema list and decided to ignore it. > > The whole point of this library is to provide the full list of YANG modules > > and submodules on the device. > > > > I strongly object to changing this module. > > IMO it is quite clear how to fill in the list of modules. > > Yes it is clear. I argue that it the information is provides is not > sufficient to solve the advertisement problem. /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 Jun 29 08:07:28 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BCE71A0187 for ; Mon, 29 Jun 2015 08:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWd8tX4BgxwK for ; Mon, 29 Jun 2015 08:07:25 -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 9AB4A1A010F for ; Mon, 29 Jun 2015 08: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 BF60AFEC for ; Mon, 29 Jun 2015 17: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 kxEB8VhXaalu for ; Mon, 29 Jun 2015 17:07:23 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Mon, 29 Jun 2015 17:07:22 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 862E62002B for ; Mon, 29 Jun 2015 17:07:23 +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 Vdvfanhge8yA; Mon, 29 Jun 2015 17:07: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 2480420013; Mon, 29 Jun 2015 17:07:22 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 21B0F34E49F4; Mon, 29 Jun 2015 17:07:21 +0200 (CEST) Date: Mon, 29 Jun 2015 17:07:21 +0200 From: Juergen Schoenwaelder To: netconf@ietf.org Message-ID: <20150629150721.GA2587@elstar.local> Mail-Followup-To: netconf@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="82I3+IH0IqGh5yIs" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: Subject: [Netconf] [FOWARDING] Last Call: (Time Capability in NETCONF) to Experimental RFC X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 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, 29 Jun 2015 15:07:27 -0000 --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, just to make sure everybody here has seen this. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 --82I3+IH0IqGh5yIs Content-Type: message/rfc822 Content-Disposition: inline Received: from hermes.jacobs-university.de (212.201.44.23) by SHUBCAS05.jacobs.jacobs-university.de (10.70.0.128) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 29 Jun 2015 16:59:11 +0200 Received: from atlas2.jacobs-university.de (atlas2a.jacobs-university.de [212.201.44.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "atlas2.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id EB91120013 for ; Mon, 29 Jun 2015 16:59:10 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by atlas2.jacobs-university.de (Postfix) with ESMTP id C617550 for ; Mon, 29 Jun 2015 16:59:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-100 required=6.2 tests=[BAYES_00=-1.5, RP_MATCHES_RCVD=-1.051, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: demetrius3.jacobs-university.de (amavisd-new); dkim=pass (1024-bit key) header.d=ietf.org Received: from atlas2a.jacobs-university.de ([212.201.44.15]) by localhost (demetrius3.jacobs-university.de [212.201.44.48]) (amavisd-new, port 10030) with ESMTP id tyAm1n_pR9pc for ; Mon, 29 Jun 2015 16:59:06 +0200 (CEST) X-JacobsISPWhiteListed: No X-policyd-weight: using cached result; rate:hard: -6.1 Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by atlas2a.jacobs-university.de (Postfix) with ESMTPS for ; Mon, 29 Jun 2015 16:59:09 +0200 (CEST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 45B451ACDEF; Mon, 29 Jun 2015 07:58:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1435589911; bh=YDD2PDDQQ8l8iAq9/+2mnFZfGqxhP76RK3pIAremNJw=; h=Content-Type:MIME-Version:Content-Transfer-Encoding:From:To: Subject:Message-ID:Date:Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:Sender; b=QH+5ZJKFZ9P2EvdAUJK6oxLoK0UvnITJCUJP33Xf2HXcbmyIX/EIRvzbexyIWdZSF XGSzAf2PmdjPyU7+e9eF/QE3WH6zLvgKKsWCnoVnxQ9kakKZsaergA2fxQTURcomU9 5GeHGmg7IhRFy8lSubV/x/l25jTe5o/Pd+csWhvk= X-Original-To: ietf-announce@ietfa.amsl.com Delivered-To: ietf-announce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61A3B1ACE03 for ; Mon, 29 Jun 2015 07:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bn33XPOS47x for ; Mon, 29 Jun 2015 07:58:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D09C41ACDF0 for ; Mon, 29 Jun 2015 07:58:22 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Last Call: (Time Capability in NETCONF) to Experimental RFC X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150629145822.7722.8876.idtracker@ietfa.amsl.com> Date: Mon, 29 Jun 2015 07:58:22 -0700 Archived-At: X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.15 Reply-To: List-Id: "IETF announcement list. No discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ietf-announce-bounces@ietf.org Sender: IETF-Announce Return-Path: ietf-announce-bounces@ietf.org X-MS-Exchange-Organization-AuthSource: SHUBCAS05.jacobs.jacobs-university.de X-MS-Exchange-Organization-AuthAs: Anonymous MIME-Version: 1.0 The IESG has received a request from an individual submitter to consider the following document: - 'Time Capability in NETCONF' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-07-29. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a capability-based extension to the Network Configuration Protocol (NETCONF) that allows time-triggered configuration and management operations. This extension allows NETCONF clients to invoke configuration updates according to scheduled times, and allows NETCONF servers to attach timestamps to the data they send to NETCONF clients. The Network Configuration Protocol (NETCONF) Capability URNs registry requires a standards action in order to populate the registry. This document was taken out of the ISE stream and brought forward as an AD sponsored individual-submission to address this consideration. The file can be obtained via https://datatracker.ietf.org/doc/draft-mm-netconf-time-capability/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-mm-netconf-time-capability/ballot/ No IPR declarations have been submitted directly on this I-D. --82I3+IH0IqGh5yIs-- From nobody Mon Jun 29 09:49:47 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 524BD1B2AB9; Mon, 29 Jun 2015 09:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hXVMicJ4igaY; Mon, 29 Jun 2015 09:49:43 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 934771B2AB5; Mon, 29 Jun 2015 09:49:29 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIGAHvmdlXGmAcV/2dsb2JhbABcgmYqVF4GrF8BAQEBAQEGk26FeQKBSEwBAQEBAQGBAAuEIgEBAQEDEig0CwwEAgEIDQQBAwEBCxQFBAcyFAMGCAIEDgUIGogMAQyhPK5+AQEBAQEBAQECAQEBAQEBAQEBAQETBIYZhSqEVTEHBoMRgRYFkz6EQoJThUuDe4J1j0skYoEoHBWBPW+BRoEBAQEB X-IronPort-AV: E=Sophos;i="5.13,581,1427774400"; d="scan'208";a="127056955" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 29 Jun 2015 12:49:28 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 29 Jun 2015 12:49:27 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0174.001; Mon, 29 Jun 2015 12:49:26 -0400 From: "Romascanu, Dan (Dan)" To: "ietf@ietf.org" Thread-Topic: Last Call: (Time Capability in NETCONF) to Experimental RFC Thread-Index: AQHQsnwZ8VMhG5B+QkSHejS8k3Acip3Dr38w Date: Mon, 29 Jun 2015 16:49:26 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5CA78C61@AZ-FFEXMB04.global.avaya.com> References: <20150629145822.7722.8876.idtracker@ietfa.amsl.com> In-Reply-To: <20150629145822.7722.8876.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.48] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netconf@ietf.org" , "lmap@ietf.org" Subject: Re: [Netconf] Last Call: (Time Capability in NETCONF) to Experimental RFC X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 16:49:45 -0000 (I apologize for cross-posting) but it seems justified in this case)=20 I find this work useful.=20 I have two questions:=20 - why was not this document adopted by the NETCONF WG? Lack of time, out of= focus, or are there any other (technical?) reasons? Why did it had to go o= n AD-sponsored and Experimental track? - This work may potentially be useful for LMAP which has scheduling and tim= e-stamping features in its architecture and framework. LMAP however just se= lected RESTCONF as their preferred protocol. What would it take to extend t= his work to RESTCONF)? (may be another piece of work) Thanks and Regards, Dan > -----Original Message----- > From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf Of > The IESG > Sent: Monday, June 29, 2015 5:58 PM > To: IETF-Announce > Subject: Last Call: (Time > Capability in NETCONF) to Experimental RFC >=20 >=20 > The IESG has received a request from an individual submitter to consider = the > following document: > - 'Time Capability in NETCONF' > as Experimental RFC >=20 > The IESG plans to make a decision in the next few weeks, and solicits fin= al > comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2015-07-29. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the beginnin= g of > the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > This document defines a capability-based extension to the Network > Configuration Protocol (NETCONF) that allows time-triggered > configuration and management operations. This extension allows > NETCONF clients to invoke configuration updates according to > scheduled times, and allows NETCONF servers to attach timestamps to > the data they send to NETCONF clients. >=20 >=20 > The Network Configuration Protocol (NETCONF) Capability URNs registry > requires a standards action in order to populate the registry. This docum= ent > was taken out of the ISE stream and brought forward as an AD sponsored > individual-submission to address this consideration. >=20 >=20 > The file can be obtained via > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__datatracker.ietf.org_doc_draft-2Dmm-2Dnetconf-2Dtime- > 2Dcapability_&d=3DAwICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNX > CJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DeIbq6OXE65r_w9lwmd5WrktViMncM > zhCDjk3tyjnVvU&s=3DB6e1FBSZH9H- > OYAnRMYEgTJVYQ6SSqa2K9XpuIyx3mI&e=3D >=20 > IESG discussion can be tracked via > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__datatracker.ietf.org_doc_draft-2Dmm-2Dnetconf-2Dtime- > 2Dcapability_ballot_&d=3DAwICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR3 > 1OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DeIbq6OXE65r_w9lwmd5WrktVi > MncMzhCDjk3tyjnVvU&s=3DWbISmWkVGVo43riTMHY7kzIkAREkQrB2aq- > lyYOad-Y&e=3D >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 From nobody Mon Jun 29 10:15:58 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2FF81B2BC7; Mon, 29 Jun 2015 10:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROYtZI_1TZWK; Mon, 29 Jun 2015 10:15:51 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9E5B1B2BC8; Mon, 29 Jun 2015 10:15:51 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C7621124E; Mon, 29 Jun 2015 19:15:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 3VDYdoz48t30; Mon, 29 Jun 2015 19:15:49 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 29 Jun 2015 19:15:48 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6F99A2002B; Mon, 29 Jun 2015 19:15:49 +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 FRC6l5cJPF4d; Mon, 29 Jun 2015 19:15:44 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AE4D920013; Mon, 29 Jun 2015 19:15:47 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1340F34E4C8F; Mon, 29 Jun 2015 19:15:46 +0200 (CEST) Date: Mon, 29 Jun 2015 19:15:46 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20150629171546.GA2841@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , "ietf@ietf.org" , "netconf@ietf.org" , "lmap@ietf.org" References: <20150629145822.7722.8876.idtracker@ietfa.amsl.com> <9904FB1B0159DA42B0B887B7FA8119CA5CA78C61@AZ-FFEXMB04.global.avaya.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5CA78C61@AZ-FFEXMB04.global.avaya.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "lmap@ietf.org" , "ietf@ietf.org" , "netconf@ietf.org" Subject: Re: [Netconf] Last Call: (Time Capability in NETCONF) to Experimental RFC X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 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, 29 Jun 2015 17:15:54 -0000 On Mon, Jun 29, 2015 at 04:49:26PM +0000, Romascanu, Dan (Dan) wrote: > (I apologize for cross-posting) but it seems justified in this case) > > I find this work useful. > > I have two questions: > - why was not this document adopted by the NETCONF WG? Lack of time, out of focus, or are there any other (technical?) reasons? Why did it had to go on AD-sponsored and Experimental track? > - This work may potentially be useful for LMAP which has scheduling and time-stamping features in its architecture and framework. LMAP however just selected RESTCONF as their preferred protocol. What would it take to extend this work to RESTCONF)? (may be another piece of work) > LMAP deals with scheduling as part of the data model. I do not think that config changes are the way to model the start of measurements. /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 Jun 29 10:17:21 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 705801B2BD5; Mon, 29 Jun 2015 10:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVkYEDfLsGnN; Mon, 29 Jun 2015 10:17:17 -0700 (PDT) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::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 D9DFC1B2BD3; Mon, 29 Jun 2015 10:17:16 -0700 (PDT) Received: by pdbep18 with SMTP id ep18so98286302pdb.1; Mon, 29 Jun 2015 10:17:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=GsAOnkQTG7bu9wfkZMA2tXgOXhM4VLkNVpphyUiuugw=; b=h1cgBlnSwa/RMzcQmJqEfhqhkcOTPOD+6WiFGiTC5ZOwewl0Tv/MfoM2o53fDr9n1d yYhoz5hsPkRi+PDtm0h+wf6KxfPQRKbTj7Scy3GMcaffOFUImobkXfVdLPvk7rkjB2qZ q9aN1q+MK8IKKkDzr9yeU+DlyqYCpzCGbE3koPVNn6NilXW4rgN4VHci9h8kW/Uma1ZP YkWquSGMiDqdfXZLEZuV+R2/ZrqnXpUA7PJbWwa1EgqIdiZ95kGZQp/xSCjmy21EAio9 rbRCpbXha0BkRtW2lT08KCgDsPlhuvvpZPhmAvmp6zK94etuQsjiJVv6IS5hzxw418qS FDYQ== X-Received: by 10.70.43.169 with SMTP id x9mr33720899pdl.52.1435598236591; Mon, 29 Jun 2015 10:17:16 -0700 (PDT) Received: from sjc-mahesh-nitro3.cisco.com ([128.107.241.183]) by mx.google.com with ESMTPSA id go5sm42808464pbd.36.2015.06.29.10.17.14 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jun 2015 10:17:15 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_38C39B79-38E9-4874-B178-F93387A385BE" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Mahesh Jethanandani In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5CA78C61@AZ-FFEXMB04.global.avaya.com> Date: Mon, 29 Jun 2015 10:17:13 -0700 Message-Id: References: <20150629145822.7722.8876.idtracker@ietfa.amsl.com> <9904FB1B0159DA42B0B887B7FA8119CA5CA78C61@AZ-FFEXMB04.global.avaya.com> To: "Dan Romascanu (Dan)" X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "lmap@ietf.org" , "ietf@ietf.org" , "netconf@ietf.org" Subject: Re: [Netconf] Last Call: (Time Capability in NETCONF) to Experimental RFC X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 17:17:19 -0000 --Apple-Mail=_38C39B79-38E9-4874-B178-F93387A385BE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dan, If you go into the archives of NETCONF and search for the draft, you = will find some history on the draft. It started by folks asking for questions and clarifications on the = draft. Even after they were seemingly addressed, their was little or no = support for adopting the draft into the WG both in IETF 92 and on the = mailing list. If you believe that there is a need for this work and able to get folks = to review the draft and show support for it on the mailing list, the WG = can relook at the draft. Making it experimental is always an option. Cheers. > On Jun 29, 2015, at 9:49 AM, Romascanu, Dan (Dan) = wrote: >=20 > (I apologize for cross-posting) but it seems justified in this case)=20= >=20 > I find this work useful.=20 >=20 > I have two questions:=20 > - why was not this document adopted by the NETCONF WG? Lack of time, = out of focus, or are there any other (technical?) reasons? Why did it = had to go on AD-sponsored and Experimental track? > - This work may potentially be useful for LMAP which has scheduling = and time-stamping features in its architecture and framework. LMAP = however just selected RESTCONF as their preferred protocol. What would = it take to extend this work to RESTCONF)? (may be another piece of work) >=20 > Thanks and Regards, >=20 > Dan >=20 >=20 >> -----Original Message----- >> From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf = Of >> The IESG >> Sent: Monday, June 29, 2015 5:58 PM >> To: IETF-Announce >> Subject: Last Call: (Time >> Capability in NETCONF) to Experimental RFC >>=20 >>=20 >> The IESG has received a request from an individual submitter to = consider the >> following document: >> - 'Time Capability in NETCONF' >> as Experimental RFC >>=20 >> The IESG plans to make a decision in the next few weeks, and solicits = final >> comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2015-07-29. Exceptionally, comments = may be >> sent to iesg@ietf.org instead. In either case, please retain the = beginning of >> the Subject line to allow automated sorting. >>=20 >> Abstract >>=20 >>=20 >> This document defines a capability-based extension to the Network >> Configuration Protocol (NETCONF) that allows time-triggered >> configuration and management operations. This extension allows >> NETCONF clients to invoke configuration updates according to >> scheduled times, and allows NETCONF servers to attach timestamps to >> the data they send to NETCONF clients. >>=20 >>=20 >> The Network Configuration Protocol (NETCONF) Capability URNs registry >> requires a standards action in order to populate the registry. This = document >> was taken out of the ISE stream and brought forward as an AD = sponsored >> individual-submission to address this consideration. >>=20 >>=20 >> The file can be obtained via >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >> 3A__datatracker.ietf.org_doc_draft-2Dmm-2Dnetconf-2Dtime- >> 2Dcapability_&d=3DAwICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNX >> CJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DeIbq6OXE65r_w9lwmd5WrktViMncM >> zhCDjk3tyjnVvU&s=3DB6e1FBSZH9H- >> OYAnRMYEgTJVYQ6SSqa2K9XpuIyx3mI&e=3D >>=20 >> IESG discussion can be tracked via >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >> 3A__datatracker.ietf.org_doc_draft-2Dmm-2Dnetconf-2Dtime- >> 2Dcapability_ballot_&d=3DAwICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR3= >> 1OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DeIbq6OXE65r_w9lwmd5WrktVi >> MncMzhCDjk3tyjnVvU&s=3DWbISmWkVGVo43riTMHY7kzIkAREkQrB2aq- >> lyYOad-Y&e=3D >>=20 >>=20 >> No IPR declarations have been submitted directly on this I-D. >>=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_38C39B79-38E9-4874-B178-F93387A385BE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dan,

If = you go into the archives of NETCONF and search for the draft, you will = find some history on the draft.

It started by folks asking for = questions and clarifications on the draft. Even after they were = seemingly addressed, their was little or no support for adopting the = draft into the WG both in IETF 92 and on the mailing list.

If you believe that = there is a need for this work and able to get folks to review the draft = and show support for it on the mailing list, the WG can relook at the = draft. Making it experimental is always an option.

Cheers.

On Jun 29, 2015, at 9:49 AM, Romascanu, Dan (Dan) <dromasca@avaya.com> = wrote:

(I = apologize for cross-posting) but it seems justified in this case)

I find this work useful.

I have two questions:
- why was not this = document adopted by the NETCONF WG? Lack of time, out of focus, or are = there any other (technical?) reasons? Why did it had to go on = AD-sponsored and Experimental track?
- This work may = potentially be useful for LMAP which has scheduling and time-stamping = features in its architecture and framework. LMAP however just selected = RESTCONF as their preferred protocol. What would it take to extend this = work to RESTCONF)? (may be another piece of work)

Thanks and Regards,

Dan


-----Original Message-----
From: IETF-Announce = [mailto:ietf-announce-bounces@ietf.org] On Behalf Of
The IESG
Sent: Monday, June 29, 2015 5:58 PM
To: IETF-Announce
Subject: Last Call: = <draft-mm-netconf-time-capability-05.txt> (Time
Capability in NETCONF) to Experimental RFC


The IESG has received a request from an = individual submitter to consider the
following = document:
- 'Time Capability in NETCONF'
=  <draft-mm-netconf-time-capability-05.txt> as Experimental = RFC

The IESG plans to make a decision in = the next few weeks, and solicits final
comments on this = action. Please send substantive comments to the
ietf@ietf.org mailing lists = by 2015-07-29. Exceptionally, comments may be
sent to iesg@ietf.org instead. In = either case, please retain the beginning of
the Subject = line to allow automated sorting.

Abstract


  This document = defines a capability-based extension to the Network
=   Configuration Protocol (NETCONF) that allows = time-triggered
  configuration and management = operations. This extension allows
  NETCONF = clients to invoke configuration updates according to
=   scheduled times, and allows NETCONF servers to attach = timestamps to
  the data they send to NETCONF = clients.


The Network = Configuration Protocol (NETCONF) Capability URNs registry
requires a standards action in order to populate the = registry. This document
was taken out of the ISE stream = and brought forward as an AD sponsored
individual-submission= to address this consideration.


The file can be obtained via
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-
3A__datatracker.ietf.org_doc_draft-2Dmm-2Dnetconf-2Dtime-
2Dcapability_&d=3DAwICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&= ;r=3DI4dzGxR31OcNX
CJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DeIbq6OXE65r_w9lwmd5WrktV= iMncM
zhCDjk3tyjnVvU&s=3DB6e1FBSZH9H-
OYAnRMYEgTJVYQ6SSqa2K9XpuIyx3mI&e=3D

IESG discussion can be tracked via
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-
3A__datatracker.ietf.org_doc_draft-2Dmm-2Dnetconf-2Dtime-
2Dcapability_ballot_&d=3DAwICAg&c=3DBFpWQw8bsuKpl1SgiZH= 64Q&r=3DI4dzGxR3
1OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DeIbq6OXE65r_w9lwmd5= WrktVi
MncMzhCDjk3tyjnVvU&s=3DWbISmWkVGVo43riTMHY7kzIkAREkQrB2aq-<= br class=3D"">lyYOad-Y&e=3D


No IPR declarations have been submitted directly on this = I-D.


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

Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_38C39B79-38E9-4874-B178-F93387A385BE-- From nobody Mon Jun 29 10:17:34 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F05B1B2BDE; Mon, 29 Jun 2015 10:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7agxBpAPlok; Mon, 29 Jun 2015 10:17:26 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF03B1B2BDC; Mon, 29 Jun 2015 10:17:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3532; q=dns/txt; s=iport; t=1435598245; x=1436807845; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=a2cjrFbYHuNvpuOB56CryJlGxrpc1cX358/ZzwvlcDc=; b=XgK1Z8fmCZs4dc/YuoO37w3tAu2xoMDfEDZG4hxGkoebDkiVusvbJM79 Y2sWIVzB2/AJjJmPpU+fXPdgaXx4hb3lcDIAPyUVWW0Z5g4pklissTwOc wfWY1JXf7t31IkICjYufVcx/0BfJP8X2bydsWjmhm/IjOnp51omdiGqZn U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CoAwAtfZFV/4sNJK1bgxFUX70kCYFcCoUuSgKBOzgUAQEBAQEBAYEKhCIBAQEDAQEBATU2CgEMBAsRAQMBAQEJFgQEBwkDAgECARUfAwYIBgEMAQUCAQGIIwgNyHsBAQEBAQEBAQEBAQEBAQEBAQEBAQETBItKhFMzBwaEJQEElASEWYJYhCSBOoQRgmuQBSZjgSkcFYFZIjGCSAEBAQ X-IronPort-AV: E=Sophos;i="5.15,371,1432598400"; d="scan'208";a="163670655" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-2.cisco.com with ESMTP; 29 Jun 2015 17:17:07 +0000 Received: from [10.150.53.127] (dhcp-10-150-53-127.cisco.com [10.150.53.127]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t5THH6gh031642; Mon, 29 Jun 2015 17:17:06 GMT Message-ID: <55917D92.5050604@cisco.com> Date: Mon, 29 Jun 2015 13:17:06 -0400 From: Joe Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" , "ietf@ietf.org" References: <20150629145822.7722.8876.idtracker@ietfa.amsl.com> <9904FB1B0159DA42B0B887B7FA8119CA5CA78C61@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5CA78C61@AZ-FFEXMB04.global.avaya.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "netconf@ietf.org" , "lmap@ietf.org" Subject: Re: [Netconf] Last Call: (Time Capability in NETCONF) to Experimental RFC X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 17:17:31 -0000 On 6/29/15 12:49, Romascanu, Dan (Dan) wrote: > (I apologize for cross-posting) but it seems justified in this case) > > I find this work useful. As do I. I remember the when this was first presented in Berlin. I thought it had value. > > I have two questions: > - why was not this document adopted by the NETCONF WG? Lack of time, out of focus, or are there any other (technical?) reasons? Why did it had to go on AD-sponsored and Experimental track? I'll speak from what I saw. There didn't seem to be a lot of traction on the WG list, but I do feel this would be beneficial as a working group item. Joe > - This work may potentially be useful for LMAP which has scheduling and time-stamping features in its architecture and framework. LMAP however just selected RESTCONF as their preferred protocol. What would it take to extend this work to RESTCONF)? (may be another piece of work) > > Thanks and Regards, > > Dan > > >> -----Original Message----- >> From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf Of >> The IESG >> Sent: Monday, June 29, 2015 5:58 PM >> To: IETF-Announce >> Subject: Last Call: (Time >> Capability in NETCONF) to Experimental RFC >> >> >> The IESG has received a request from an individual submitter to consider the >> following document: >> - 'Time Capability in NETCONF' >> as Experimental RFC >> >> The IESG plans to make a decision in the next few weeks, and solicits final >> comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2015-07-29. Exceptionally, comments may be >> sent to iesg@ietf.org instead. In either case, please retain the beginning of >> the Subject line to allow automated sorting. >> >> Abstract >> >> >> This document defines a capability-based extension to the Network >> Configuration Protocol (NETCONF) that allows time-triggered >> configuration and management operations. This extension allows >> NETCONF clients to invoke configuration updates according to >> scheduled times, and allows NETCONF servers to attach timestamps to >> the data they send to NETCONF clients. >> >> >> The Network Configuration Protocol (NETCONF) Capability URNs registry >> requires a standards action in order to populate the registry. This document >> was taken out of the ISE stream and brought forward as an AD sponsored >> individual-submission to address this consideration. >> >> >> The file can be obtained via >> https://urldefense.proofpoint.com/v2/url?u=https- >> 3A__datatracker.ietf.org_doc_draft-2Dmm-2Dnetconf-2Dtime- >> 2Dcapability_&d=AwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNX >> CJfQzvlsiLQfucBXRucPvdrphpBsFA&m=eIbq6OXE65r_w9lwmd5WrktViMncM >> zhCDjk3tyjnVvU&s=B6e1FBSZH9H- >> OYAnRMYEgTJVYQ6SSqa2K9XpuIyx3mI&e= >> >> IESG discussion can be tracked via >> https://urldefense.proofpoint.com/v2/url?u=https- >> 3A__datatracker.ietf.org_doc_draft-2Dmm-2Dnetconf-2Dtime- >> 2Dcapability_ballot_&d=AwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR3 >> 1OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=eIbq6OXE65r_w9lwmd5WrktVi >> MncMzhCDjk3tyjnVvU&s=WbISmWkVGVo43riTMHY7kzIkAREkQrB2aq- >> lyYOad-Y&e= >> >> >> No IPR declarations have been submitted directly on this I-D. >> > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Mon Jun 29 10:27:09 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 302AD1B2BE9 for ; Mon, 29 Jun 2015 10:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XaKqNGmfSkez for ; Mon, 29 Jun 2015 10:27:05 -0700 (PDT) Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A110A1B2BC8 for ; Mon, 29 Jun 2015 10:27:04 -0700 (PDT) Received: by lagc2 with SMTP id c2so18444936lag.3 for ; Mon, 29 Jun 2015 10:27:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=9/dLZ5WUvw7tG5K4o9QiT0tKgNUODNn9Dyh24O13fDM=; b=NoTFUlxA779wNh40EY05j2l3yqNJlHghYGl7OqLhRLQQK1AOHuU7lu6EQBDyFoh/9/ fRzHmKIs4HPhnKxGbMOgH7nRrfpbiGsB7eu/Ba6GJBtEBEb80aKTEI7fVrTHqfd/BAdM cdZH2AsSljMJ9VV/w7dAgVmoPjExTgvpe7vMehBx2jag7akzMoVUIIgKo11GlTLMBfmf YfDkFS/qNkM8ler2TCcC+2ZtWfQp9S2JR1m16uNOR+Eu/yaEcweRb6hVwaUXsGLwXB/Q 51L8jgDX5RsoORdFf4QpAZNm8NNOK1xB2vaORqspPoNatYTX/NCAAjCwfHQQCrTdcsi+ sTBQ== X-Gm-Message-State: ALoCoQkiZpmXj1x04IufwWKRKZukdK3uxaKwlOGLkRoc/VulIFcHbT59Y5aM07amsQN7JE9JnlFn MIME-Version: 1.0 X-Received: by 10.112.41.171 with SMTP id g11mr15276628lbl.123.1435598823098; Mon, 29 Jun 2015 10:27:03 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Mon, 29 Jun 2015 10:27:03 -0700 (PDT) In-Reply-To: <20150629150721.GA2587@elstar.local> References: <20150629150721.GA2587@elstar.local> Date: Mon, 29 Jun 2015 10:27:03 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Netconf Content-Type: multipart/alternative; boundary=001a11346d9ce423ba0519ab65f5 Archived-At: Subject: Re: [Netconf] [FOWARDING] Last Call: (Time Capability in NETCONF) to Experimental RFC X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 17:27:07 -0000 --001a11346d9ce423ba0519ab65f5 Content-Type: text/plain; charset=UTF-8 Hi, Is this an AD-sponsored draft? This draft was "interesting" but not enough to be prioritized ahead of other work being done in the NETCONF WG. The draft mixes server measurement of RPC execution time with a "cron" function. The rationale for this grab-bag of time-related functionality is not entirely clear. This work does not have any consensus within the NETCONF WG. It does seem a little surprising that it is being published without even asking the NETCONF WG for comments. I don't have any problem with Experimental RFCs as long as it is clear this is not a product of the NETCONF WG. Andy On Mon, Jun 29, 2015 at 8:07 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > Hi, > > just to make sure everybody here has seen this. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > > ---------- Forwarded message ---------- > From: The IESG > To: IETF-Announce > Cc: > Date: Mon, 29 Jun 2015 07:58:22 -0700 > Subject: Last Call: (Time > Capability in NETCONF) to Experimental RFC > > The IESG has received a request from an individual submitter to consider > the following document: > - 'Time Capability in NETCONF' > as Experimental RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2015-07-29. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document defines a capability-based extension to the Network > Configuration Protocol (NETCONF) that allows time-triggered > configuration and management operations. This extension allows > NETCONF clients to invoke configuration updates according to > scheduled times, and allows NETCONF servers to attach timestamps to > the data they send to NETCONF clients. > > > The Network Configuration Protocol (NETCONF) Capability URNs registry > requires a standards action in order to populate the registry. This > document > was taken out of the ISE stream and brought forward as an AD sponsored > individual-submission to address this consideration. > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-mm-netconf-time-capability/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-mm-netconf-time-capability/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --001a11346d9ce423ba0519ab65f5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,


Is this an AD-sponso= red draft?

This draft was "interesting" = but not enough to be prioritized ahead
of other work being done i= n the NETCONF WG.

The draft mixes server measureme= nt of RPC execution time
with a "cron" function.=C2=A0 = The rationale for this grab-bag of
time-related functionality is = not entirely clear.

This work does not have any co= nsensus within the NETCONF WG.
It does seem a little surprising t= hat it is being published without
even asking the NETCONF WG for = comments.

I don't have any problem with Experi= mental RFCs as long as it
is clear this is not a product of the N= ETCONF WG.



Andy



On Mon, Jun 29, 2015 at 8:07 AM, Juergen Schoenwaelder = <j.schoenwaelder@jacobs-university.de> wr= ote:
Hi,

just to make sure everybody here has seen this.

/js

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


---------- Forwarded message ----------
From:=C2= =A0The IESG <iesg-secretary@i= etf.org>
To:=C2=A0IETF-Announce <ietf-announce@ietf.org>
Cc:=C2=A0
Date:=C2=A0Mon,= 29 Jun 2015 07:58:22 -0700
Subject:=C2=A0Last Call: <draft-mm-netcon= f-time-capability-05.txt> (Time Capability in NETCONF) to Experimental R= FC

The IESG has received a request from an individual submitter to consider the following document:
- 'Time Capability in NETCONF'
=C2=A0 <draft-mm-netconf-time-capability-05.txt> as Experimental RFC<= br>
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-07= -29. Exceptionally, comments may be
sent to iesg@ietf.org instead. In eith= er case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


=C2=A0 =C2=A0This document defines a capability-based extension to the Netw= ork
=C2=A0 =C2=A0Configuration Protocol (NETCONF) that allows time-triggered =C2=A0 =C2=A0configuration and management operations. This extension allows=
=C2=A0 =C2=A0NETCONF clients to invoke configuration updates according to =C2=A0 =C2=A0scheduled times, and allows NETCONF servers to attach timestam= ps to
=C2=A0 =C2=A0the data they send to NETCONF clients.


The Network Configuration Protocol (NETCONF) Capability URNs registry
requires a standards action in order to populate the registry. This documen= t
was taken out of the ISE stream and brought forward as an AD sponsored
individual-submission to address this consideration.


The file can be obtained via
https://datatracker.ietf.org/doc/d= raft-mm-netconf-time-capability/

IESG discussion can be tracked via
https://datatracker.ietf.or= g/doc/draft-mm-netconf-time-capability/ballot/


No IPR declarations have been submitted directly on this I-D.



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


--001a11346d9ce423ba0519ab65f5-- From nobody Mon Jun 29 10:54:46 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 878FD1B2C09 for ; Mon, 29 Jun 2015 10:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGkU0gJCvTnO for ; Mon, 29 Jun 2015 10:54:42 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 890BB1B2C0B for ; Mon, 29 Jun 2015 10:54:42 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8FE08879; Mon, 29 Jun 2015 19:54:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id QCWAl8XJ6z-H; Mon, 29 Jun 2015 19:54:39 +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, 29 Jun 2015 19:54:38 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 669F92002B; Mon, 29 Jun 2015 19:54:39 +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 sksY4b7f_bus; Mon, 29 Jun 2015 19:54: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 8E2F820013; Mon, 29 Jun 2015 19:54:37 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3CF1434E4D6D; Mon, 29 Jun 2015 19:54:38 +0200 (CEST) Date: Mon, 29 Jun 2015 19:54:38 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20150629175438.GC2841@elstar.local> Mail-Followup-To: Andy Bierman , Netconf References: <20150629150721.GA2587@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Netconf Subject: Re: [Netconf] [FOWARDING] Last Call: (Time Capability in NETCONF) to Experimental RFC X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 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, 29 Jun 2015 17:54:44 -0000 Technically, I believe the solution is not really desirable. Figure 4 says you send an RPC and then wait potentially days or weeks for a matching RPC reply and in between you get notifications (which travel over a very different communication channel). But yeah, let people experiment with this if they want to. What I do not get is why this idea requires to get an entry in the capabilities registry and thus is AD sponsored. I do not think that NETCONF requires that experimental capabilities need to be registered with IANA. /js On Mon, Jun 29, 2015 at 10:27:03AM -0700, Andy Bierman wrote: > Hi, > > > Is this an AD-sponsored draft? > > This draft was "interesting" but not enough to be prioritized ahead > of other work being done in the NETCONF WG. > > The draft mixes server measurement of RPC execution time > with a "cron" function. The rationale for this grab-bag of > time-related functionality is not entirely clear. > > This work does not have any consensus within the NETCONF WG. > It does seem a little surprising that it is being published without > even asking the NETCONF WG for comments. > > I don't have any problem with Experimental RFCs as long as it > is clear this is not a product of the NETCONF WG. > > > > Andy > > > > On Mon, Jun 29, 2015 at 8:07 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > Hi, > > > > just to make sure everybody here has seen this. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > > > > ---------- Forwarded message ---------- > > From: The IESG > > To: IETF-Announce > > Cc: > > Date: Mon, 29 Jun 2015 07:58:22 -0700 > > Subject: Last Call: (Time > > Capability in NETCONF) to Experimental RFC > > > > The IESG has received a request from an individual submitter to consider > > the following document: > > - 'Time Capability in NETCONF' > > as Experimental RFC > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send substantive comments to the > > ietf@ietf.org mailing lists by 2015-07-29. Exceptionally, comments may be > > sent to iesg@ietf.org instead. In either case, please retain the > > beginning of the Subject line to allow automated sorting. > > > > Abstract > > > > > > This document defines a capability-based extension to the Network > > Configuration Protocol (NETCONF) that allows time-triggered > > configuration and management operations. This extension allows > > NETCONF clients to invoke configuration updates according to > > scheduled times, and allows NETCONF servers to attach timestamps to > > the data they send to NETCONF clients. > > > > > > The Network Configuration Protocol (NETCONF) Capability URNs registry > > requires a standards action in order to populate the registry. This > > document > > was taken out of the ISE stream and brought forward as an AD sponsored > > individual-submission to address this consideration. > > > > > > The file can be obtained via > > https://datatracker.ietf.org/doc/draft-mm-netconf-time-capability/ > > > > IESG discussion can be tracked via > > https://datatracker.ietf.org/doc/draft-mm-netconf-time-capability/ballot/ > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > > > _______________________________________________ > > 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 Mon Jun 29 11:08:32 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0E201B2C5C for ; Mon, 29 Jun 2015 11:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id np1x_50Da803 for ; Mon, 29 Jun 2015 11:08:28 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 968311B2C4E for ; Mon, 29 Jun 2015 11:08:27 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FABSJkVWHCzIm/2dsb2JhbABYA4JmK1RfBqsCAQEGjXmGEYV4AoE9TAEBAQEBAYELhCIBAQEBAxIoNAsMAgICAQgNAQIBAwEBAQEKFAUEBxsXFAkIAgQBDQUIEweIDQEMp3uhCQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEBIYYhS6ENAEBBRohEAcGC4MGgRQFhwONAQGEWIJYhV6EEYMBjBKDXRcPY4FagT1vAYELOoECAQEB X-IronPort-AV: E=Sophos;i="5.15,371,1432612800"; d="scan'208";a="123292482" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 29 Jun 2015 14:08:25 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 29 Jun 2015 14:08:25 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Mon, 29 Jun 2015 20:08:24 +0200 From: "Romascanu, Dan (Dan)" To: Juergen Schoenwaelder , Andy Bierman Thread-Topic: [Netconf] [FOWARDING] Last Call: (Time Capability in NETCONF) to Experimental RFC Thread-Index: AQHQsn1Rkt/LDbnOZkuAY/7qNg0eB53Dmx6AgAAHtQCAACR40A== Date: Mon, 29 Jun 2015 18:08:23 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5CA78DC1@AZ-FFEXMB04.global.avaya.com> References: <20150629150721.GA2587@elstar.local> <20150629175438.GC2841@elstar.local> In-Reply-To: <20150629175438.GC2841@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.48] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Netconf Subject: Re: [Netconf] [FOWARDING] Last Call: (Time Capability in NETCONF) to Experimental RFC X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 18:08:30 -0000 I believe that you should make your (Juergen's, Andy's) concerns known to t= he IETF mail list. This being an AD-sponsored I-D that seems to be the plac= e to comment.=20 Regards, Dan > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen > Schoenwaelder > Sent: Monday, June 29, 2015 8:55 PM > To: Andy Bierman > Cc: Netconf > Subject: Re: [Netconf] [FOWARDING] Last Call: capability-05.txt> (Time Capability in NETCONF) to Experimental RFC >=20 > Technically, I believe the solution is not really desirable. Figure 4 say= s you > send an RPC and then wait potentially days or weeks for a matching RPC > reply and in between you get notifications (which travel over a very diff= erent > communication channel). But yeah, let people experiment with this if they > want to. >=20 > What I do not get is why this idea requires to get an entry in the capabi= lities > registry and thus is AD sponsored. I do not think that NETCONF requires t= hat > experimental capabilities need to be registered with IANA. >=20 > /js >=20 > On Mon, Jun 29, 2015 at 10:27:03AM -0700, Andy Bierman wrote: > > Hi, > > > > > > Is this an AD-sponsored draft? > > > > This draft was "interesting" but not enough to be prioritized ahead of > > other work being done in the NETCONF WG. > > > > The draft mixes server measurement of RPC execution time with a "cron" > > function. The rationale for this grab-bag of time-related > > functionality is not entirely clear. > > > > This work does not have any consensus within the NETCONF WG. > > It does seem a little surprising that it is being published without > > even asking the NETCONF WG for comments. > > > > I don't have any problem with Experimental RFCs as long as it is clear > > this is not a product of the NETCONF WG. > > > > > > > > Andy > > > > > > > > On Mon, Jun 29, 2015 at 8:07 AM, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > Hi, > > > > > > just to make sure everybody here has seen this. > > > > > > /js > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | German= y > > > Fax: +49 421 200 3103 > 2Duniversity.de_&d=3DAwICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31O > cNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DQ87IdLt8nKswJo- > EKyD24gL4IKoQu5XOXa5aeKohufY&s=3DYOeonUh8hkmY4VdCwSpkZk593aUNn > haxHAeGUDKyUV0&e=3D > > > > > > > > > > ---------- Forwarded message ---------- > > > From: The IESG > > > To: IETF-Announce > > > Cc: > > > Date: Mon, 29 Jun 2015 07:58:22 -0700 > > > Subject: Last Call: (Time > > > Capability in NETCONF) to Experimental RFC > > > > > > The IESG has received a request from an individual submitter to > > > consider the following document: > > > - 'Time Capability in NETCONF' > > > as Experimental RFC > > > > > > The IESG plans to make a decision in the next few weeks, and > > > solicits final comments on this action. Please send substantive > > > comments to the ietf@ietf.org mailing lists by 2015-07-29. > > > Exceptionally, comments may be sent to iesg@ietf.org instead. In > > > either case, please retain the beginning of the Subject line to allow > automated sorting. > > > > > > Abstract > > > > > > > > > This document defines a capability-based extension to the Network > > > Configuration Protocol (NETCONF) that allows time-triggered > > > configuration and management operations. This extension allows > > > NETCONF clients to invoke configuration updates according to > > > scheduled times, and allows NETCONF servers to attach timestamps t= o > > > the data they send to NETCONF clients. > > > > > > > > > The Network Configuration Protocol (NETCONF) Capability URNs > > > registry requires a standards action in order to populate the > > > registry. This document was taken out of the ISE stream and brought > > > forward as an AD sponsored individual-submission to address this > > > consideration. > > > > > > > > > The file can be obtained via > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ie= t > > > f.org_doc_draft-2Dmm-2Dnetconf-2Dtime- > 2Dcapability_&d=3DAwICAg&c=3DBFpWQ > > > > w8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA& > m=3DQ8 > > > 7IdLt8nKswJo- > EKyD24gL4IKoQu5XOXa5aeKohufY&s=3DxXpTwBGoKzQwCICBcvA-IOLm > > > fEd8emgt7EGVyAmzJ2s&e=3D > > > > > > IESG discussion can be tracked via > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ie= t > > > f.org_doc_draft-2Dmm-2Dnetconf-2Dtime- > 2Dcapability_ballot_&d=3DAwICAg& > > > > c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrp > hpBs > > > FA&m=3DQ87IdLt8nKswJo- > EKyD24gL4IKoQu5XOXa5aeKohufY&s=3D5XcQnG3n5R4D-qUiv > > > 2DD-r67mQdOk39an9qW5Eb86Z8&e=3D > > > > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > > > > > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_ma > > > > ilman_listinfo_netconf&d=3DAwICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGx > R31 > > > OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DQ87IdLt8nKswJo- > EKyD24gL4IKoQu5X > > > OXa5aeKohufY&s=3D1RLb- > m80wIXpLUu28LFybr6Sy0KTrI_zhriR7mQWflo&e=3D > > > > > > >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > 2Duniversity.de_&d=3DAwICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31O > cNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DQ87IdLt8nKswJo- > EKyD24gL4IKoQu5XOXa5aeKohufY&s=3DYOeonUh8hkmY4VdCwSpkZk593aUNn > haxHAeGUDKyUV0&e=3D > >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_netconf&d=3DAwICAg&c=3DBFpWQw8bsu > Kpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DQ87I > dLt8nKswJo-EKyD24gL4IKoQu5XOXa5aeKohufY&s=3D1RLb- > m80wIXpLUu28LFybr6Sy0KTrI_zhriR7mQWflo&e=3D From nobody Mon Jun 29 11:24:43 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8D31A0049 for ; Mon, 29 Jun 2015 11:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2J0UNKtaMC5 for ; Mon, 29 Jun 2015 11:24:40 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (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 2458B1A002A for ; Mon, 29 Jun 2015 11:24:40 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id t5TIOd5F003816; Mon, 29 Jun 2015 11:24:39 -0700 Received: from il-exch01.marvell.com (galiil.marvell.com [199.203.130.254]) by mx0b-0016f401.pphosted.com with ESMTP id 1v9ubfnaqp-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 29 Jun 2015 11:24:39 -0700 Received: from IL-EXCH01.marvell.com (10.4.102.220) by IL-EXCH01.marvell.com (10.4.102.220) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Mon, 29 Jun 2015 21:24:36 +0300 Received: from IL-EXCH01.marvell.com ([fe80::41:1c9f:8611:3a4a]) by IL-EXCH01.marvell.com ([fe80::41:1c9f:8611:3a4a%20]) with mapi id 15.00.1044.021; Mon, 29 Jun 2015 21:24:36 +0300 From: Tal Mizrahi To: Juergen Schoenwaelder Thread-Topic: [Netconf] [FOWARDING] Last Call: (Time Capability in NETCONF) to Experimental RFC Thread-Index: AQHQspSqqIId9+7BtECIv6ffNOIXrp3DyuKA Date: Mon, 29 Jun 2015 18:24:36 +0000 Message-ID: References: <20150629150721.GA2587@elstar.local> <20150629175438.GC2841@elstar.local> In-Reply-To: <20150629175438.GC2841@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [199.203.130.14] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-06-29_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1506180000 definitions=main-1506290295 Archived-At: Cc: Netconf Subject: Re: [Netconf] [FOWARDING] Last Call: (Time Capability in NETCONF) to Experimental RFC X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 18:24:42 -0000 Hi J=FCrgen, Thanks for the feedback. > Figure 4 says you send an RPC and then wait potentially days or weeks for= a matching RPC reply and in between you get notifications For this reason (and others), the draft specifies that the time capability = is intended for *near future* scheduling (see Section 3.6). Note that the d= efault of the sched-max-future parameter is 15 seconds. Cheers, Tal. -----Original Message----- From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen Schoen= waelder Sent: Monday, June 29, 2015 8:55 PM To: Andy Bierman Cc: Netconf Subject: Re: [Netconf] [FOWARDING] Last Call: (Time Capability in NETCONF) to Experimental RFC Technically, I believe the solution is not really desirable. Figure 4 says = you send an RPC and then wait potentially days or weeks for a matching RPC = reply and in between you get notifications (which travel over a very differ= ent communication channel). But yeah, let people experiment with this if th= ey want to. What I do not get is why this idea requires to get an entry in the capabili= ties registry and thus is AD sponsored. I do not think that NETCONF require= s that experimental capabilities need to be registered with IANA. /js On Mon, Jun 29, 2015 at 10:27:03AM -0700, Andy Bierman wrote: > Hi, >=20 >=20 > Is this an AD-sponsored draft? >=20 > This draft was "interesting" but not enough to be prioritized ahead of=20 > other work being done in the NETCONF WG. >=20 > The draft mixes server measurement of RPC execution time with a "cron"=20 > function. The rationale for this grab-bag of time-related=20 > functionality is not entirely clear. >=20 > This work does not have any consensus within the NETCONF WG. > It does seem a little surprising that it is being published without=20 > even asking the NETCONF WG for comments. >=20 > I don't have any problem with Experimental RFCs as long as it is clear=20 > this is not a product of the NETCONF WG. >=20 >=20 >=20 > Andy >=20 >=20 >=20 > On Mon, Jun 29, 2015 at 8:07 AM, Juergen Schoenwaelder <=20 > j.schoenwaelder@jacobs-university.de> wrote: >=20 > > Hi, > > > > just to make sure everybody here has seen this. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > > > > ---------- Forwarded message ---------- > > From: The IESG > > To: IETF-Announce > > Cc: > > Date: Mon, 29 Jun 2015 07:58:22 -0700 > > Subject: Last Call: (Time=20 > > Capability in NETCONF) to Experimental RFC > > > > The IESG has received a request from an individual submitter to=20 > > consider the following document: > > - 'Time Capability in NETCONF' > > as Experimental RFC > > > > The IESG plans to make a decision in the next few weeks, and=20 > > solicits final comments on this action. Please send substantive=20 > > comments to the ietf@ietf.org mailing lists by 2015-07-29.=20 > > Exceptionally, comments may be sent to iesg@ietf.org instead. In=20 > > either case, please retain the beginning of the Subject line to allow a= utomated sorting. > > > > Abstract > > > > > > This document defines a capability-based extension to the Network > > Configuration Protocol (NETCONF) that allows time-triggered > > configuration and management operations. This extension allows > > NETCONF clients to invoke configuration updates according to > > scheduled times, and allows NETCONF servers to attach timestamps to > > the data they send to NETCONF clients. > > > > > > The Network Configuration Protocol (NETCONF) Capability URNs=20 > > registry requires a standards action in order to populate the=20 > > registry. This document was taken out of the ISE stream and brought=20 > > forward as an AD sponsored individual-submission to address this=20 > > consideration. > > > > > > The file can be obtained via > > https://datatracker.ietf.org/doc/draft-mm-netconf-time-capability/ > > > > IESG discussion can be tracked via > > https://datatracker.ietf.org/doc/draft-mm-netconf-time-capability/ba > > llot/ > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > --=20 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 From nobody Mon Jun 29 11:53:12 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C935B1ACEF4 for ; Mon, 29 Jun 2015 11:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1iQEDflTGBa for ; Mon, 29 Jun 2015 11:53:08 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (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 296F41ACEF6 for ; Mon, 29 Jun 2015 11:53:07 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id t5TIoUcp018224; Mon, 29 Jun 2015 11:53:07 -0700 Received: from il-exch01.marvell.com (galiil.marvell.com [199.203.130.254]) by mx0b-0016f401.pphosted.com with ESMTP id 1v9ubfncjc-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 29 Jun 2015 11:53:06 -0700 Received: from IL-EXCH01.marvell.com (10.4.102.220) by IL-EXCH01.marvell.com (10.4.102.220) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Mon, 29 Jun 2015 21:53:03 +0300 Received: from IL-EXCH01.marvell.com ([fe80::41:1c9f:8611:3a4a]) by IL-EXCH01.marvell.com ([fe80::41:1c9f:8611:3a4a%20]) with mapi id 15.00.1044.021; Mon, 29 Jun 2015 21:53:03 +0300 From: Tal Mizrahi To: Andy Bierman , Netconf Thread-Topic: [Netconf] [FOWARDING] Last Call: (Time Capability in NETCONF) to Experimental RFC Thread-Index: AQHQspDXqIId9+7BtECIv6ffNOIXrp3DzWJw Date: Mon, 29 Jun 2015 18:53:03 +0000 Message-ID: <7be9dceb27734ceb94bcb04fdfb3451c@IL-EXCH01.marvell.com> References: <20150629150721.GA2587@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [199.203.130.14] Content-Type: multipart/alternative; boundary="_000_7be9dceb27734ceb94bcb04fdfb3451cILEXCH01marvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-06-29_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1506180000 definitions=main-1506290300 Archived-At: Subject: Re: [Netconf] [FOWARDING] Last Call: (Time Capability in NETCONF) to Experimental RFC X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 18:53:11 -0000 --_000_7be9dceb27734ceb94bcb04fdfb3451cILEXCH01marvellcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwNCg0KVGhhbmtzIGZvciB0aGUgY29tbWVudHMuDQoNCj5UaGUgZHJhZnQgbWl4ZXMg c2VydmVyIG1lYXN1cmVtZW50IG9mIFJQQyBleGVjdXRpb24gdGltZQ0KPndpdGggYSAiY3JvbiIg ZnVuY3Rpb24uICBUaGUgcmF0aW9uYWxlIGZvciB0aGlzIGdyYWItYmFnIG9mDQo+dGltZS1yZWxh dGVkIGZ1bmN0aW9uYWxpdHkgaXMgbm90IGVudGlyZWx5IGNsZWFyLg0KDQpPbmUgb2YgdGhlIG1v c3Qgbm90YWJsZSB1c2UgY2FzZXMgaXMgYSBuZXR3b3JrLXdpZGUgY29tbWl0LiBUaGUgdGltZSBj YXBhYmlsaXR5ICh1c2luZyBzY2hlZHVsZWQgY29tbWl0cyBhbmQgY2FuY2VsLXNjaGVkdWxlKSBh bGxvd3MgYSBjbGllbnQgdG8gcGVyZm9ybSBhIG5ldHdvcmstd2lkZSBjb21taXQgaW4gTiBzZXJ2 ZXJzLCB3aGVyZSBlaXRoZXIgYWxsIHBlcmZvcm0gdGhlIGNvbW1pdCwgb3Igbm9uZSBvZiB0aGVt IGRvZXMuIFN1Y2ggYmVoYXZpb3IgaXMgbm90IGN1cnJlbnRseSBwb3NzaWJsZSB3aXRoIGNvbmZp cm1lZCBjb21taXRzIChSRkM2MjQxKTsgd2hlbiB1c2luZyBjb25maXJtZWQgY29tbWl0cywgaWYg c29tZXRoaW5nIGdvZXMgd3JvbmcsIHRoZW4gYWxsIHRoZSBzZXJ2ZXJzIHJvbGwgYmFjayB0byB0 aGUgcHJldmlvdXMgY29uZmlndXJhdGlvbiwgd2hpY2ggbWVhbnMgdGhhdCB0aGVyZSBpcyBhIChw b3RlbnRpYWxseSBsb25nKSB0cmFuc2llbnQgc3RhdGUgd2hlcmUgc29tZSBzZXJ2ZXJzIGhhdmUg Y2hhbmdlZCB0aGVpciBjb25maWd1cmF0aW9uIGFuZCBvdGhlcnMgaGF2ZSBub3QuDQpUaGUgdGlt ZSBjYXBhYmlsaXR5IGFsbG93cyB0aGUgY2xpZW50IHRvIGNhbmNlbCB0aGUgY29tbWl0IGluIGFk dmFuY2U6IGlmIG9uZSBvZiB0aGUgc2VydmVycyBpbmRpY2F0ZXMgaXQgY2Fubm90IHBlcmZvcm0g dGhlIGNvbW1pdCAodXNpbmcgYW4gZXJyb3IgbWVzc2FnZSksIHRoZW4gdGhlIGNsaWVudCBzZW5k cyBhIGNhbmNlbGxhdGlvbiBtZXNzYWdlIHRvIGFsbCB0aGUgc2VydmVycyBiZWZvcmUgdGhlIGNv bW1pdCBoYXMgb2NjdXJyZWQuIEFsbCB0aGUgc2VydmVycyBjb25zaXN0ZW50bHkgdXNlIHRoZSBz YW1lIGRhdGFzdG9yZSB0aHJvdWdob3V0IHRoZSBwcm9jZWR1cmUuDQoNClRoZSBleGVjdXRpb24t dGltZSBwYXJhbWV0ZXIgYWxsb3dzIHRoZSBjbGllbnQgdG8gcmVjZWl2ZSBmZWVkYmFjayBhYm91 dCB0aGUgYWN0dWFsIGV4ZWN1dGlvbiB0aW1lIG9mIHRoZSBSUEMuIEJhc2VkIG9uIHRoaXMgZmVl ZGJhY2sgdGhlIGNsaWVudDogKDEpIGtub3dzIGhvdyBhY2N1cmF0ZWx5IHRoZSBzZXJ2ZXIgc2No ZWR1bGVkIHRoZSBSUEMsIGFuZCAoMikgaGFzIGEgKHJvdWdoKSBwaWN0dXJlIG9mIHdoZXRoZXIg dGhlIHNlcnZlcuKAmXMgY2xvY2sgaXMgc3luY2hyb25pemVkIHRvIGl0cyBvd24gKHNlZSBTZWN0 aW9uIDMuMyBmb3IgZnVydGhlciBkaXNjdXNzaW9uKS4NCg0KV2UgcHJlc2VudGVkIGEgZmV3IHVz ZS1jYXNlcyBhdCB0aGUgSUVURiBtZWV0aW5nIGluIEJlcmxpbiAoaHR0cDovL3d3dy5pZXRmLm9y Zy9wcm9jZWVkaW5ncy84Ny9zbGlkZXMvc2xpZGVzLTg3LW5ldGNvbmYtMS5wZGYpLCBhbmQgdGhl IERhbGxhcyBwcmVzZW50YXRpb24gKGh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzky L3NsaWRlcy9zbGlkZXMtOTItbmV0Y29uZi0xMy5wZGYpLCB3aGljaCB3YXMgbm90IHByZXNlbnRl ZCBkdWUgdG8gbGFjayBvZiB0aW1lLCBpbmNsdWRlZCB0aGUgbmV0d29yay13aWRlIGNvbW1pdCB1 c2UgY2FzZS4NCg0KQ2hlZXJzLA0KVGFsLg0KDQpGcm9tOiBOZXRjb25mIFttYWlsdG86bmV0Y29u Zi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQW5keSBCaWVybWFuDQpTZW50OiBNb25k YXksIEp1bmUgMjksIDIwMTUgODoyNyBQTQ0KVG86IEp1ZXJnZW4gU2Nob2Vud2FlbGRlcjsgTmV0 Y29uZg0KU3ViamVjdDogUmU6IFtOZXRjb25mXSBbRk9XQVJESU5HXSBMYXN0IENhbGw6IDxkcmFm dC1tbS1uZXRjb25mLXRpbWUtY2FwYWJpbGl0eS0wNS50eHQ+IChUaW1lIENhcGFiaWxpdHkgaW4g TkVUQ09ORikgdG8gRXhwZXJpbWVudGFsIFJGQw0KDQpIaSwNCg0KDQpJcyB0aGlzIGFuIEFELXNw b25zb3JlZCBkcmFmdD8NCg0KVGhpcyBkcmFmdCB3YXMgImludGVyZXN0aW5nIiBidXQgbm90IGVu b3VnaCB0byBiZSBwcmlvcml0aXplZCBhaGVhZA0Kb2Ygb3RoZXIgd29yayBiZWluZyBkb25lIGlu IHRoZSBORVRDT05GIFdHLg0KDQpUaGUgZHJhZnQgbWl4ZXMgc2VydmVyIG1lYXN1cmVtZW50IG9m IFJQQyBleGVjdXRpb24gdGltZQ0Kd2l0aCBhICJjcm9uIiBmdW5jdGlvbi4gIFRoZSByYXRpb25h bGUgZm9yIHRoaXMgZ3JhYi1iYWcgb2YNCnRpbWUtcmVsYXRlZCBmdW5jdGlvbmFsaXR5IGlzIG5v dCBlbnRpcmVseSBjbGVhci4NCg0KVGhpcyB3b3JrIGRvZXMgbm90IGhhdmUgYW55IGNvbnNlbnN1 cyB3aXRoaW4gdGhlIE5FVENPTkYgV0cuDQpJdCBkb2VzIHNlZW0gYSBsaXR0bGUgc3VycHJpc2lu ZyB0aGF0IGl0IGlzIGJlaW5nIHB1Ymxpc2hlZCB3aXRob3V0DQpldmVuIGFza2luZyB0aGUgTkVU Q09ORiBXRyBmb3IgY29tbWVudHMuDQoNCkkgZG9uJ3QgaGF2ZSBhbnkgcHJvYmxlbSB3aXRoIEV4 cGVyaW1lbnRhbCBSRkNzIGFzIGxvbmcgYXMgaXQNCmlzIGNsZWFyIHRoaXMgaXMgbm90IGEgcHJv ZHVjdCBvZiB0aGUgTkVUQ09ORiBXRy4NCg0KDQoNCkFuZHkNCg0KDQoNCk9uIE1vbiwgSnVuIDI5 LCAyMDE1IGF0IDg6MDcgQU0sIEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVsZGVy QGphY29icy11bml2ZXJzaXR5LmRlPG1haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZl cnNpdHkuZGU+PiB3cm90ZToNCkhpLA0KDQpqdXN0IHRvIG1ha2Ugc3VyZSBldmVyeWJvZHkgaGVy ZSBoYXMgc2VlbiB0aGlzLg0KDQovanMNCg0KLS0NCkp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAg ICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQpQaG9uZTogKzQ5IDQyMSAyMDAg MzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55DQpGYXg6 ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5 LmRlLz4NCg0KDQotLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLS0NCkZyb206 IFRoZSBJRVNHIDxpZXNnLXNlY3JldGFyeUBpZXRmLm9yZzxtYWlsdG86aWVzZy1zZWNyZXRhcnlA aWV0Zi5vcmc+Pg0KVG86IElFVEYtQW5ub3VuY2UgPGlldGYtYW5ub3VuY2VAaWV0Zi5vcmc8bWFp bHRvOmlldGYtYW5ub3VuY2VAaWV0Zi5vcmc+Pg0KQ2M6DQpEYXRlOiBNb24sIDI5IEp1biAyMDE1 IDA3OjU4OjIyIC0wNzAwDQpTdWJqZWN0OiBMYXN0IENhbGw6IDxkcmFmdC1tbS1uZXRjb25mLXRp bWUtY2FwYWJpbGl0eS0wNS50eHQ+IChUaW1lIENhcGFiaWxpdHkgaW4gTkVUQ09ORikgdG8gRXhw ZXJpbWVudGFsIFJGQw0KDQpUaGUgSUVTRyBoYXMgcmVjZWl2ZWQgYSByZXF1ZXN0IGZyb20gYW4g aW5kaXZpZHVhbCBzdWJtaXR0ZXIgdG8gY29uc2lkZXINCnRoZSBmb2xsb3dpbmcgZG9jdW1lbnQ6 DQotICdUaW1lIENhcGFiaWxpdHkgaW4gTkVUQ09ORicNCiAgPGRyYWZ0LW1tLW5ldGNvbmYtdGlt ZS1jYXBhYmlsaXR5LTA1LnR4dD4gYXMgRXhwZXJpbWVudGFsIFJGQw0KDQpUaGUgSUVTRyBwbGFu cyB0byBtYWtlIGEgZGVjaXNpb24gaW4gdGhlIG5leHQgZmV3IHdlZWtzLCBhbmQgc29saWNpdHMN CmZpbmFsIGNvbW1lbnRzIG9uIHRoaXMgYWN0aW9uLiBQbGVhc2Ugc2VuZCBzdWJzdGFudGl2ZSBj b21tZW50cyB0byB0aGUNCmlldGZAaWV0Zi5vcmc8bWFpbHRvOmlldGZAaWV0Zi5vcmc+IG1haWxp bmcgbGlzdHMgYnkgMjAxNS0wNy0yOS4gRXhjZXB0aW9uYWxseSwgY29tbWVudHMgbWF5IGJlDQpz ZW50IHRvIGllc2dAaWV0Zi5vcmc8bWFpbHRvOmllc2dAaWV0Zi5vcmc+IGluc3RlYWQuIEluIGVp dGhlciBjYXNlLCBwbGVhc2UgcmV0YWluIHRoZQ0KYmVnaW5uaW5nIG9mIHRoZSBTdWJqZWN0IGxp bmUgdG8gYWxsb3cgYXV0b21hdGVkIHNvcnRpbmcuDQoNCkFic3RyYWN0DQoNCg0KICAgVGhpcyBk b2N1bWVudCBkZWZpbmVzIGEgY2FwYWJpbGl0eS1iYXNlZCBleHRlbnNpb24gdG8gdGhlIE5ldHdv cmsNCiAgIENvbmZpZ3VyYXRpb24gUHJvdG9jb2wgKE5FVENPTkYpIHRoYXQgYWxsb3dzIHRpbWUt dHJpZ2dlcmVkDQogICBjb25maWd1cmF0aW9uIGFuZCBtYW5hZ2VtZW50IG9wZXJhdGlvbnMuIFRo aXMgZXh0ZW5zaW9uIGFsbG93cw0KICAgTkVUQ09ORiBjbGllbnRzIHRvIGludm9rZSBjb25maWd1 cmF0aW9uIHVwZGF0ZXMgYWNjb3JkaW5nIHRvDQogICBzY2hlZHVsZWQgdGltZXMsIGFuZCBhbGxv d3MgTkVUQ09ORiBzZXJ2ZXJzIHRvIGF0dGFjaCB0aW1lc3RhbXBzIHRvDQogICB0aGUgZGF0YSB0 aGV5IHNlbmQgdG8gTkVUQ09ORiBjbGllbnRzLg0KDQoNClRoZSBOZXR3b3JrIENvbmZpZ3VyYXRp b24gUHJvdG9jb2wgKE5FVENPTkYpIENhcGFiaWxpdHkgVVJOcyByZWdpc3RyeQ0KcmVxdWlyZXMg YSBzdGFuZGFyZHMgYWN0aW9uIGluIG9yZGVyIHRvIHBvcHVsYXRlIHRoZSByZWdpc3RyeS4gVGhp cyBkb2N1bWVudA0Kd2FzIHRha2VuIG91dCBvZiB0aGUgSVNFIHN0cmVhbSBhbmQgYnJvdWdodCBm b3J3YXJkIGFzIGFuIEFEIHNwb25zb3JlZA0KaW5kaXZpZHVhbC1zdWJtaXNzaW9uIHRvIGFkZHJl c3MgdGhpcyBjb25zaWRlcmF0aW9uLg0KDQoNClRoZSBmaWxlIGNhbiBiZSBvYnRhaW5lZCB2aWEN Cmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1tLW5ldGNvbmYtdGltZS1j YXBhYmlsaXR5Lw0KDQpJRVNHIGRpc2N1c3Npb24gY2FuIGJlIHRyYWNrZWQgdmlhDQpodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1tbS1uZXRjb25mLXRpbWUtY2FwYWJpbGl0 eS9iYWxsb3QvDQoNCg0KTm8gSVBSIGRlY2xhcmF0aW9ucyBoYXZlIGJlZW4gc3VibWl0dGVkIGRp cmVjdGx5IG9uIHRoaXMgSS1ELg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCk5ldGNvbmYgbWFpbGluZyBsaXN0DQpOZXRjb25mQGlldGYub3Jn PG1haWx0bzpOZXRjb25mQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9uZXRjb25mDQoNCg== --_000_7be9dceb27734ceb94bcb04fdfb3451cILEXCH01marvellcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkJh bGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglm b250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjI1aW4gMS4waW4gMS4yNWluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBBbmR5LDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+VGhhbmtzIGZvciB0aGUgY29tbWVudHMuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZndDtUaGUgZHJhZnQgbWl4ZXMgc2VydmVyIG1lYXN1cmVtZW50IG9mIFJQQyBleGVjdXRpb24g dGltZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0O3dpdGggYSAmcXVv dDtjcm9uJnF1b3Q7IGZ1bmN0aW9uLiZuYnNwOyBUaGUgcmF0aW9uYWxlIGZvciB0aGlzIGdyYWIt YmFnIG9mPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7dGltZS1yZWxh dGVkIGZ1bmN0aW9uYWxpdHkgaXMgbm90IGVudGlyZWx5IGNsZWFyLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5PbmUgb2YgdGhlIG1v c3Qgbm90YWJsZSB1c2UgY2FzZXMgaXMgYSBuZXR3b3JrLXdpZGUgY29tbWl0LiBUaGUgdGltZSBj YXBhYmlsaXR5ICh1c2luZyBzY2hlZHVsZWQgY29tbWl0cyBhbmQgY2FuY2VsLXNjaGVkdWxlKSBh bGxvd3MgYSBjbGllbnQgdG8gcGVyZm9ybSBhIG5ldHdvcmstd2lkZQ0KIGNvbW1pdCBpbiBOIHNl cnZlcnMsIHdoZXJlIGVpdGhlciBhbGwgcGVyZm9ybSB0aGUgY29tbWl0LCBvciBub25lIG9mIHRo ZW0gZG9lcy4gU3VjaCBiZWhhdmlvciBpcyBub3QgY3VycmVudGx5IHBvc3NpYmxlIHdpdGggY29u ZmlybWVkIGNvbW1pdHMgKFJGQzYyNDEpOyB3aGVuIHVzaW5nIGNvbmZpcm1lZCBjb21taXRzLCBp ZiBzb21ldGhpbmcgZ29lcyB3cm9uZywgdGhlbiBhbGwgdGhlIHNlcnZlcnMgcm9sbCBiYWNrIHRv IHRoZSBwcmV2aW91cw0KIGNvbmZpZ3VyYXRpb24sIHdoaWNoIG1lYW5zIHRoYXQgdGhlcmUgaXMg YSAocG90ZW50aWFsbHkgbG9uZykgdHJhbnNpZW50IHN0YXRlIHdoZXJlIHNvbWUgc2VydmVycyBo YXZlIGNoYW5nZWQgdGhlaXIgY29uZmlndXJhdGlvbiBhbmQgb3RoZXJzIGhhdmUgbm90LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgdGltZSBjYXBhYmlsaXR5IGFsbG93cyB0aGUg Y2xpZW50IHRvIGNhbmNlbCB0aGUgY29tbWl0IGluIGFkdmFuY2U6IGlmIG9uZSBvZiB0aGUgc2Vy dmVycyBpbmRpY2F0ZXMgaXQgY2Fubm90IHBlcmZvcm0gdGhlIGNvbW1pdCAodXNpbmcgYW4gZXJy b3IgbWVzc2FnZSksDQogdGhlbiB0aGUgY2xpZW50IHNlbmRzIGEgY2FuY2VsbGF0aW9uIG1lc3Nh Z2UgdG8gYWxsIHRoZSBzZXJ2ZXJzIGJlZm9yZSB0aGUgY29tbWl0IGhhcyBvY2N1cnJlZC4gQWxs IHRoZSBzZXJ2ZXJzIGNvbnNpc3RlbnRseSB1c2UgdGhlIHNhbWUgZGF0YXN0b3JlIHRocm91Z2hv dXQgdGhlIHByb2NlZHVyZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIGV4ZWN1dGlvbi10aW1lIHBhcmFtZXRl ciBhbGxvd3MgdGhlIGNsaWVudCB0byByZWNlaXZlIGZlZWRiYWNrIGFib3V0IHRoZSBhY3R1YWwg ZXhlY3V0aW9uIHRpbWUgb2YgdGhlIFJQQy4gQmFzZWQgb24gdGhpcyBmZWVkYmFjayB0aGUgY2xp ZW50OiAoMSkga25vd3MNCiBob3cgYWNjdXJhdGVseSB0aGUgc2VydmVyIHNjaGVkdWxlZCB0aGUg UlBDLCBhbmQgKDIpIGhhcyBhIChyb3VnaCkgcGljdHVyZSBvZiB3aGV0aGVyIHRoZSBzZXJ2ZXLi gJlzIGNsb2NrIGlzIHN5bmNocm9uaXplZCB0byBpdHMgb3duIChzZWUgU2VjdGlvbiAzLjMgZm9y IGZ1cnRoZXIgZGlzY3Vzc2lvbikuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldlIHByZXNlbnRlZCBhIGZldyB1c2Ut Y2FzZXMgYXQgdGhlIElFVEYgbWVldGluZyBpbiBCZXJsaW4gKDxhIGhyZWY9Imh0dHA6Ly93d3cu aWV0Zi5vcmcvcHJvY2VlZGluZ3MvODcvc2xpZGVzL3NsaWRlcy04Ny1uZXRjb25mLTEucGRmIj5o dHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzg3L3NsaWRlcy9zbGlkZXMtODctbmV0Y29u Zi0xLnBkZjwvYT4pLA0KIGFuZCB0aGUgRGFsbGFzIHByZXNlbnRhdGlvbiAoPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTIvc2xpZGVzL3NsaWRlcy05Mi1uZXRjb25m LTEzLnBkZiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTIvc2xpZGVzL3NsaWRl cy05Mi1uZXRjb25mLTEzLnBkZjwvYT4pLCB3aGljaCB3YXMgbm90IHByZXNlbnRlZCBkdWUgdG8g bGFjayBvZiB0aW1lLCBpbmNsdWRlZCB0aGUgbmV0d29yay13aWRlIGNvbW1pdA0KIHVzZSBjYXNl Ljwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UYWwuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBOZXRjb25mIFttYWlsdG86bmV0Y29uZi1i b3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5BbmR5IEJpZXJtYW48YnI+DQo8 Yj5TZW50OjwvYj4gTW9uZGF5LCBKdW5lIDI5LCAyMDE1IDg6MjcgUE08YnI+DQo8Yj5Ubzo8L2I+ IEp1ZXJnZW4gU2Nob2Vud2FlbGRlcjsgTmV0Y29uZjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W05ldGNvbmZdIFtGT1dBUkRJTkddIExhc3QgQ2FsbDogJmx0O2RyYWZ0LW1tLW5ldGNvbmYtdGlt ZS1jYXBhYmlsaXR5LTA1LnR4dCZndDsgKFRpbWUgQ2FwYWJpbGl0eSBpbiBORVRDT05GKSB0byBF eHBlcmltZW50YWwgUkZDPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGks PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklzIHRoaXMg YW4gQUQtc3BvbnNvcmVkIGRyYWZ0PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGRyYWZ0IHdhcyAmcXVvdDtpbnRlcmVzdGluZyZxdW90 OyBidXQgbm90IGVub3VnaCB0byBiZSBwcmlvcml0aXplZCBhaGVhZDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+b2Ygb3RoZXIgd29yayBiZWluZyBk b25lIGluIHRoZSBORVRDT05GIFdHLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZHJhZnQgbWl4ZXMgc2VydmVyIG1lYXN1cmVtZW50IG9m IFJQQyBleGVjdXRpb24gdGltZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+d2l0aCBhICZxdW90O2Nyb24mcXVvdDsgZnVuY3Rpb24uJm5ic3A7IFRo ZSByYXRpb25hbGUgZm9yIHRoaXMgZ3JhYi1iYWcgb2Y8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRpbWUtcmVsYXRlZCBmdW5jdGlvbmFsaXR5IGlz IG5vdCBlbnRpcmVseSBjbGVhci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhpcyB3b3JrIGRvZXMgbm90IGhhdmUgYW55IGNvbnNlbnN1cyB3 aXRoaW4gdGhlIE5FVENPTkYgV0cuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JdCBkb2VzIHNlZW0gYSBsaXR0bGUgc3VycHJpc2luZyB0aGF0IGl0 IGlzIGJlaW5nIHB1Ymxpc2hlZCB3aXRob3V0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ldmVuIGFza2luZyB0aGUgTkVUQ09ORiBXRyBmb3IgY29t bWVudHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkkgZG9uJ3QgaGF2ZSBhbnkgcHJvYmxlbSB3aXRoIEV4cGVyaW1lbnRhbCBSRkNzIGFzIGxv bmcgYXMgaXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPmlzIGNsZWFyIHRoaXMgaXMgbm90IGEgcHJvZHVjdCBvZiB0aGUgTkVUQ09ORiBXRy48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFu ZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIE1vbiwgSnVuIDI5LCAyMDE1IGF0IDg6MDcgQU0sIEp1ZXJnZW4gU2Nob2Vud2FlbGRl ciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5k ZSIgdGFyZ2V0PSJfYmxhbmsiPmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5IaSw8YnI+DQo8YnI+DQpqdXN0IHRvIG1ha2Ugc3VyZSBl dmVyeWJvZHkgaGVyZSBoYXMgc2VlbiB0aGlzLjxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojODg4 ODg4Ij48YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj4vanM8L3NwYW4+PGJyPg0KPGJyPg0KPHNw YW4gY2xhc3M9ImhvZW56YiI+LS08L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+SnVl cmdlbiBTY2hvZW53YWVsZGVyJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkg8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9 ImhvZW56YiI+UGhvbmU6ICYjNDM7NDkgNDIxIDIwMCAzNTg3Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO0NhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55PC9zcGFu Pjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPkZheDombmJzcDsgJm5ic3A7JiM0Mzs0OSA0MjEg MjAwIDMxMDMmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0OzxhIGhyZWY9Imh0 dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3 dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS88L2E+Jmd0Ozwvc3Bhbj48YnI+DQo8L3NwYW4+PGJyPg0K PGJyPg0KLS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0tPGJyPg0KRnJvbTom bmJzcDtUaGUgSUVTRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmllc2ctc2VjcmV0YXJ5QGlldGYub3Jn Ij5pZXNnLXNlY3JldGFyeUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KVG86Jm5ic3A7SUVURi1Bbm5v dW5jZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGYtYW5ub3VuY2VAaWV0Zi5vcmciPmlldGYtYW5u b3VuY2VAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCkNjOiZuYnNwOzxicj4NCkRhdGU6Jm5ic3A7TW9u LCAyOSBKdW4gMjAxNSAwNzo1ODoyMiAtMDcwMDxicj4NClN1YmplY3Q6Jm5ic3A7TGFzdCBDYWxs OiAmbHQ7ZHJhZnQtbW0tbmV0Y29uZi10aW1lLWNhcGFiaWxpdHktMDUudHh0Jmd0OyAoVGltZSBD YXBhYmlsaXR5IGluIE5FVENPTkYpIHRvIEV4cGVyaW1lbnRhbCBSRkM8YnI+DQo8YnI+DQpUaGUg SUVTRyBoYXMgcmVjZWl2ZWQgYSByZXF1ZXN0IGZyb20gYW4gaW5kaXZpZHVhbCBzdWJtaXR0ZXIg dG8gY29uc2lkZXI8YnI+DQp0aGUgZm9sbG93aW5nIGRvY3VtZW50Ojxicj4NCi0gJ1RpbWUgQ2Fw YWJpbGl0eSBpbiBORVRDT05GJzxicj4NCiZuYnNwOyAmbHQ7ZHJhZnQtbW0tbmV0Y29uZi10aW1l LWNhcGFiaWxpdHktMDUudHh0Jmd0OyBhcyBFeHBlcmltZW50YWwgUkZDPGJyPg0KPGJyPg0KVGhl IElFU0cgcGxhbnMgdG8gbWFrZSBhIGRlY2lzaW9uIGluIHRoZSBuZXh0IGZldyB3ZWVrcywgYW5k IHNvbGljaXRzPGJyPg0KZmluYWwgY29tbWVudHMgb24gdGhpcyBhY3Rpb24uIFBsZWFzZSBzZW5k IHN1YnN0YW50aXZlIGNvbW1lbnRzIHRvIHRoZTxicj4NCjxhIGhyZWY9Im1haWx0bzppZXRmQGll dGYub3JnIj5pZXRmQGlldGYub3JnPC9hPiBtYWlsaW5nIGxpc3RzIGJ5IDIwMTUtMDctMjkuIEV4 Y2VwdGlvbmFsbHksIGNvbW1lbnRzIG1heSBiZTxicj4NCnNlbnQgdG8gPGEgaHJlZj0ibWFpbHRv Omllc2dAaWV0Zi5vcmciPmllc2dAaWV0Zi5vcmc8L2E+IGluc3RlYWQuIEluIGVpdGhlciBjYXNl LCBwbGVhc2UgcmV0YWluIHRoZTxicj4NCmJlZ2lubmluZyBvZiB0aGUgU3ViamVjdCBsaW5lIHRv IGFsbG93IGF1dG9tYXRlZCBzb3J0aW5nLjxicj4NCjxicj4NCkFic3RyYWN0PGJyPg0KPGJyPg0K PGJyPg0KJm5ic3A7ICZuYnNwO1RoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIGNhcGFiaWxpdHktYmFz ZWQgZXh0ZW5zaW9uIHRvIHRoZSBOZXR3b3JrPGJyPg0KJm5ic3A7ICZuYnNwO0NvbmZpZ3VyYXRp b24gUHJvdG9jb2wgKE5FVENPTkYpIHRoYXQgYWxsb3dzIHRpbWUtdHJpZ2dlcmVkPGJyPg0KJm5i c3A7ICZuYnNwO2NvbmZpZ3VyYXRpb24gYW5kIG1hbmFnZW1lbnQgb3BlcmF0aW9ucy4gVGhpcyBl eHRlbnNpb24gYWxsb3dzPGJyPg0KJm5ic3A7ICZuYnNwO05FVENPTkYgY2xpZW50cyB0byBpbnZv a2UgY29uZmlndXJhdGlvbiB1cGRhdGVzIGFjY29yZGluZyB0bzxicj4NCiZuYnNwOyAmbmJzcDtz Y2hlZHVsZWQgdGltZXMsIGFuZCBhbGxvd3MgTkVUQ09ORiBzZXJ2ZXJzIHRvIGF0dGFjaCB0aW1l c3RhbXBzIHRvPGJyPg0KJm5ic3A7ICZuYnNwO3RoZSBkYXRhIHRoZXkgc2VuZCB0byBORVRDT05G IGNsaWVudHMuPGJyPg0KPGJyPg0KPGJyPg0KVGhlIE5ldHdvcmsgQ29uZmlndXJhdGlvbiBQcm90 b2NvbCAoTkVUQ09ORikgQ2FwYWJpbGl0eSBVUk5zIHJlZ2lzdHJ5PGJyPg0KcmVxdWlyZXMgYSBz dGFuZGFyZHMgYWN0aW9uIGluIG9yZGVyIHRvIHBvcHVsYXRlIHRoZSByZWdpc3RyeS4gVGhpcyBk b2N1bWVudDxicj4NCndhcyB0YWtlbiBvdXQgb2YgdGhlIElTRSBzdHJlYW0gYW5kIGJyb3VnaHQg Zm9yd2FyZCBhcyBhbiBBRCBzcG9uc29yZWQ8YnI+DQppbmRpdmlkdWFsLXN1Ym1pc3Npb24gdG8g YWRkcmVzcyB0aGlzIGNvbnNpZGVyYXRpb24uPGJyPg0KPGJyPg0KPGJyPg0KVGhlIGZpbGUgY2Fu IGJlIG9idGFpbmVkIHZpYTxicj4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LW1tLW5ldGNvbmYtdGltZS1jYXBhYmlsaXR5LyIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1tLW5ldGNvbmYtdGltZS1j YXBhYmlsaXR5LzwvYT48YnI+DQo8YnI+DQpJRVNHIGRpc2N1c3Npb24gY2FuIGJlIHRyYWNrZWQg dmlhPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt bW0tbmV0Y29uZi10aW1lLWNhcGFiaWxpdHkvYmFsbG90LyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1tLW5ldGNvbmYtdGltZS1jYXBhYmls aXR5L2JhbGxvdC88L2E+PGJyPg0KPGJyPg0KPGJyPg0KTm8gSVBSIGRlY2xhcmF0aW9ucyBoYXZl IGJlZW4gc3VibWl0dGVkIGRpcmVjdGx5IG9uIHRoaXMgSS1ELjxicj4NCjxicj4NCjxicj4NCjxi cj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K TmV0Y29uZiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86TmV0Y29uZkBpZXRmLm9y ZyI+TmV0Y29uZkBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmY8L2E+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7be9dceb27734ceb94bcb04fdfb3451cILEXCH01marvellcom_-- From nobody Mon Jun 29 12:03:41 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1131AD2A9 for ; Mon, 29 Jun 2015 12:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WA1DYXSePXJt for ; Mon, 29 Jun 2015 12:03: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 3046F1A014D for ; Mon, 29 Jun 2015 12:03:38 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2CD1312A4; Mon, 29 Jun 2015 21:03:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id rB_9BmuCv6lz; Mon, 29 Jun 2015 21:03:35 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 29 Jun 2015 21:03:34 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 245BB2002B; Mon, 29 Jun 2015 21:03:35 +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 TsZxGoRn-iNf; Mon, 29 Jun 2015 21:03:33 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 714C820013; Mon, 29 Jun 2015 21:03:33 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C7B9134E4F66; Mon, 29 Jun 2015 21:03:32 +0200 (CEST) Date: Mon, 29 Jun 2015 21:03:32 +0200 From: Juergen Schoenwaelder To: Tal Mizrahi Message-ID: <20150629190329.GC3128@elstar.local> Mail-Followup-To: Tal Mizrahi , Andy Bierman , Netconf References: <20150629150721.GA2587@elstar.local> <7be9dceb27734ceb94bcb04fdfb3451c@IL-EXCH01.marvell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7be9dceb27734ceb94bcb04fdfb3451c@IL-EXCH01.marvell.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Netconf Subject: Re: [Netconf] [FOWARDING] Last Call: (Time Capability in NETCONF) to Experimental RFC X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 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, 29 Jun 2015 19:03:40 -0000 On Mon, Jun 29, 2015 at 06:53:03PM +0000, Tal Mizrahi wrote: > One of the most notable use cases is a network-wide commit. The time capability (using scheduled commits and cancel-schedule) allows a client to perform a network-wide commit in N servers, where either all perform the commit, or none of them does. Such behavior is not currently possible with confirmed commits (RFC6241); when using confirmed commits, if something goes wrong, then all the servers roll back to the previous configuration, which means that there is a (potentially long) transient state where some servers have changed their configuration and others have not. > The time capability allows the client to cancel the commit in advance: if one of the servers indicates it cannot perform the commit (using an error message), then the client sends a cancellation message to all the servers before the commit has occurred. All the servers consistently use the same datastore throughout the procedure. I am not sure I fully see the difference / advantage. With plain NC, you can push changes into the candidate datastore and you can validate that all the changes are valid regarding the data model(s). Then you start the commit itself. Servers roll back the commit if the commit fails. They also roll back in case the management system does not send the confirming commit. (This includes that case where the commit locks out the management system.) You seem to schedule the commits to happen all at the same time (assuming some reasonable time synchronization). Good. But if one out of the several commits now fails, how do you recover from that? And how is the recovery better than NC with confirmed-commit? You seem to be talking about the idea that manager wants to abort the scheduled commit. This does not exist in NC with confirmed-commit, except that the manager can simply stop invoking commits if it changes its mind spontaneously. Perhaps both approaches simply try to optimize for different kinds of commit failures. /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 Jun 29 12:05:09 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8481B29D9 for ; Mon, 29 Jun 2015 12:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8B0op3W1wNB for ; Mon, 29 Jun 2015 12:05:05 -0700 (PDT) Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CC0B1B29CD for ; Mon, 29 Jun 2015 12:05:04 -0700 (PDT) Received: by laar3 with SMTP id r3so75128197laa.0 for ; Mon, 29 Jun 2015 12:05:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ocbkTlozCjjcqiO41vhX9aLv2BdFLFftZSr74bPxQqY=; b=KloOfqJvVy2bIRnlmFLwW8P3viYtPKuYh9EG3AR77B4pvmBG/y9FVbYXeZ6JZfeLIi w2b/Iqsykqw9dkMtNdk3ml9uqyQjkWv3vPcu26bUvXwJwiqpY+QKewoSrN8oa1EdHFaC GZKhXuirpbDj9siJbuIM74/X5NXoega+cpHPZh19eUIQoHaG+tw3gx7/Rq0X9ChoGsbK 8TCCxPHzsocM78/gQV5++wFReqDPPwxx48htA4i/jpeU0VUvPw0CERtRDO9xxMSl24UD I2UarbTHJiwSf98h1UZTrTYMJ5iibpgaWZKrhGmMdVgda5IJ+FdCry5d+EqmdE3WX4/b VZVg== X-Gm-Message-State: ALoCoQlkDJU7e1mclz5WErWQ4sX7Z7CemsvmI75b9LytBy+Q2TaTYbNmfVuOlvJoMc5Ue6nH44q9 MIME-Version: 1.0 X-Received: by 10.112.41.171 with SMTP id g11mr34556lbl.123.1435604703115; Mon, 29 Jun 2015 12:05:03 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Mon, 29 Jun 2015 12:05:03 -0700 (PDT) In-Reply-To: <7be9dceb27734ceb94bcb04fdfb3451c@IL-EXCH01.marvell.com> References: <20150629150721.GA2587@elstar.local> <7be9dceb27734ceb94bcb04fdfb3451c@IL-EXCH01.marvell.com> Date: Mon, 29 Jun 2015 12:05:03 -0700 Message-ID: From: Andy Bierman To: Tal Mizrahi Content-Type: multipart/alternative; boundary=001a11346d9c5e14400519acc4d8 Archived-At: Cc: Netconf Subject: Re: [Netconf] [FOWARDING] Last Call: (Time Capability in NETCONF) to Experimental RFC X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 19:05:08 -0000 --001a11346d9c5e14400519acc4d8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jun 29, 2015 at 11:53 AM, Tal Mizrahi wrote: > Hi Andy, > > > > Thanks for the comments. > > > > >The draft mixes server measurement of RPC execution time > > >with a "cron" function. The rationale for this grab-bag of > > >time-related functionality is not entirely clear. > > > > One of the most notable use cases is a network-wide commit. The time > capability (using scheduled commits and cancel-schedule) allows a client = to > perform a network-wide commit in N servers, where either all perform the > commit, or none of them does. Such behavior is not currently possible wit= h > confirmed commits (RFC6241); when using confirmed commits, if something > goes wrong, then all the servers roll back to the previous configuration, > which means that there is a (potentially long) transient state where some > servers have changed their configuration and others have not. > > The time capability allows the client to cancel the commit in advance: if > one of the servers indicates it cannot perform the commit (using an error > message), then the client sends a cancellation message to all the servers > before the commit has occurred. All the servers consistently use the same > datastore throughout the procedure. > > > Actually, RFC 6241 confirmed-commit has a operation so it can operate the same way (client send cancel to N-1 servers when 1 server returns a commit-failed error) > The execution-time parameter allows the client to receive feedback about > the actual execution time of the RPC. Based on this feedback the client: > (1) knows how accurately the server scheduled the RPC, and (2) has a > (rough) picture of whether the server=E2=80=99s clock is synchronized to = its own > (see Section 3.3 for further discussion). > > > This assumes that the load on the system at the time of the RPC execution is somewhat known and stable. I am talking about the elapsed time measurement. The cleint can check the server's time-of-day just by reading the current-date-time object. It does not need executed-at timestamps to check that the clocks are in synch. > We presented a few use-cases at the IETF meeting in Berlin ( > http://www.ietf.org/proceedings/87/slides/slides-87-netconf-1.pdf), and > the Dallas presentation ( > https://www.ietf.org/proceedings/92/slides/slides-92-netconf-13.pdf), > which was not presented due to lack of time, included the network-wide > commit use case. > > > > Cheers, > > Tal. > > > Andy > *From:* Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of *Andy > Bierman > *Sent:* Monday, June 29, 2015 8:27 PM > *To:* Juergen Schoenwaelder; Netconf > *Subject:* Re: [Netconf] [FOWARDING] Last Call: > (Time Capability in NETCONF) to > Experimental RFC > > > > Hi, > > > > > > Is this an AD-sponsored draft? > > > > This draft was "interesting" but not enough to be prioritized ahead > > of other work being done in the NETCONF WG. > > > > The draft mixes server measurement of RPC execution time > > with a "cron" function. The rationale for this grab-bag of > > time-related functionality is not entirely clear. > > > > This work does not have any consensus within the NETCONF WG. > > It does seem a little surprising that it is being published without > > even asking the NETCONF WG for comments. > > > > I don't have any problem with Experimental RFCs as long as it > > is clear this is not a product of the NETCONF WG. > > > > > > > > Andy > > > > > > > > On Mon, Jun 29, 2015 at 8:07 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > Hi, > > just to make sure everybody here has seen this. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > > ---------- Forwarded message ---------- > From: The IESG > To: IETF-Announce > Cc: > Date: Mon, 29 Jun 2015 07:58:22 -0700 > Subject: Last Call: (Time > Capability in NETCONF) to Experimental RFC > > The IESG has received a request from an individual submitter to consider > the following document: > - 'Time Capability in NETCONF' > as Experimental RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2015-07-29. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document defines a capability-based extension to the Network > Configuration Protocol (NETCONF) that allows time-triggered > configuration and management operations. This extension allows > NETCONF clients to invoke configuration updates according to > scheduled times, and allows NETCONF servers to attach timestamps to > the data they send to NETCONF clients. > > > The Network Configuration Protocol (NETCONF) Capability URNs registry > requires a standards action in order to populate the registry. This > document > was taken out of the ISE stream and brought forward as an AD sponsored > individual-submission to address this consideration. > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-mm-netconf-time-capability/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-mm-netconf-time-capability/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > --001a11346d9c5e14400519acc4d8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jun 29, 2015 at 11:53 AM, Tal Mizrahi <talmi@marvell.com&g= t; wrote:

Hi Andy,

=C2=A0

Thanks for the comments.<= u>

=C2=A0

>The draft mixes server measurement of RPC execut= ion time

>with a "cron" function.=C2=A0 The rati= onale for this grab-bag of

>time-related functionality is not entirely clear= .

=C2=A0

One of the most notable u= se cases is a network-wide commit. The time capability (using scheduled com= mits and cancel-schedule) allows a client to perform a network-wide commit in N servers, where either all perform the commit, or none of them = does. Such behavior is not currently possible with confirmed commits (RFC62= 41); when using confirmed commits, if something goes wrong, then all the se= rvers roll back to the previous configuration, which means that there is a (potentially long) transient st= ate where some servers have changed their configuration and others have not= .

The time capability allow= s the client to cancel the commit in advance: if one of the servers indicat= es it cannot perform the commit (using an error message), then the client sends a cancellation message to all the servers before the= commit has occurred. All the servers consistently use the same datastore t= hroughout the procedure.

=C2=A0

<= /div>


Actually, RFC 62= 41 confirmed-commit has a <cancel-commit> operation
so it c= an operate the same way (client send cancel to N-1 servers when
1= server returns a commit-failed error)


<= div>
=C2=A0

The execution-time parame= ter allows the client to receive feedback about the actual execution time o= f the RPC. Based on this feedback the client: (1) knows how accurately the server scheduled the RPC, and (2) has a (rough) picture= of whether the server=E2=80=99s clock is synchronized to its own (see Sect= ion 3.3 for further discussion).

=C2=A0

<= /div>


This assumes tha= t the load on the system at the time of the RPC
execution is some= what known and stable. I am talking about
the elapsed time measur= ement.

The cleint can check the server's time-= of-day just by
reading the current-date-time object.=C2=A0 It doe= s not need
executed-at timestamps to check that the clocks are in= synch.



=C2=A0
=

We presented a few use-ca= ses at the IETF meeting in Berlin (http://www.ietf.org= /proceedings/87/slides/slides-87-netconf-1.pdf), and the Dallas presentation (https://www.ietf.org/p= roceedings/92/slides/slides-92-netconf-13.pdf), which was not presented= due to lack of time, included the network-wide commit use case.

=C2=A0

Cheers,

Tal.

=C2=A0

<= /div>


Andy
= =C2=A0

<= u>

From: Netconf = [mailto:netco= nf-bounces@ietf.org] On Behalf Of Andy Bierman
Sent: Monday, June 29, 2015 8:27 PM
To: Juergen Schoenwaelder; Netconf
Subject: Re: [Netconf] [FOWARDING] Last Call: <draft-mm-netconf-t= ime-capability-05.txt> (Time Capability in NETCONF) to Experimental RFC<= u>

=C2=A0

Hi,

=C2=A0

=C2=A0

Is this an AD-sponsored draft?

=C2=A0

This draft was "interesting" but not enoug= h to be prioritized ahead

of other work being done in the NETCONF WG.

=C2=A0

The draft mixes server measurement of RPC execution = time

with a "cron" function.=C2=A0 The rational= e for this grab-bag of

time-related functionality is not entirely clear.=

=C2=A0

This work does not have any consensus within the NET= CONF WG.

It does seem a little surprising that it is being pu= blished without

even asking the NETCONF WG for comments.

=C2=A0

I don't have any problem with Experimental RFCs = as long as it

is clear this is not a product of the NETCONF WG.=

=C2=A0

=C2=A0

=C2=A0

Andy

=C2=A0

=C2=A0

=C2=A0

On Mon, Jun 29, 2015 at 8:07 AM, Juergen Schoenwaeld= er <j.schoenwaelder@jacobs-university.de> wrote:

Hi,

just to make sure everybody here has seen this.

/js

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs = University Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring = 1 | 28759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&l= t;http://www= .jacobs-university.de/>


---------- Forwarded message ----------
From:=C2=A0The IESG <iesg-secretary@ietf.org>
To:=C2=A0IETF-Announce <ietf-announce@ietf.org>
Cc:=C2=A0
Date:=C2=A0Mon, 29 Jun 2015 07:58:22 -0700
Subject:=C2=A0Last Call: <draft-mm-netconf-time-capability-05.txt> (T= ime Capability in NETCONF) to Experimental RFC

The IESG has received a request from an individual submitter to consider the following document:
- 'Time Capability in NETCONF'
=C2=A0 <draft-mm-netconf-time-capability-05.txt> as Experimental RFC<= br>
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailin= g lists by 2015-07-29. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


=C2=A0 =C2=A0This document defines a capability-based extension to the Netw= ork
=C2=A0 =C2=A0Configuration Protocol (NETCONF) that allows time-triggered =C2=A0 =C2=A0configuration and management operations. This extension allows=
=C2=A0 =C2=A0NETCONF clients to invoke configuration updates according to =C2=A0 =C2=A0scheduled times, and allows NETCONF servers to attach timestam= ps to
=C2=A0 =C2=A0the data they send to NETCONF clients.


The Network Configuration Protocol (NETCONF) Capability URNs registry
requires a standards action in order to populate the registry. This documen= t
was taken out of the ISE stream and brought forward as an AD sponsored
individual-submission to address this consideration.


The file can be obtained via
https://datatracker.ietf.org/doc/draft-mm-netconf-tim= e-capability/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-mm-netc= onf-time-capability/ballot/


No IPR declarations have been submitted directly on this I-D.



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

=C2=A0


--001a11346d9c5e14400519acc4d8-- From nobody Mon Jun 29 13:19:48 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBEF91B33B8 for ; Mon, 29 Jun 2015 13:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wx-gy8qRRzI4 for ; Mon, 29 Jun 2015 13:19:43 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (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 748F81B33B1 for ; Mon, 29 Jun 2015 13:19:41 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id t5TKJexu002976; Mon, 29 Jun 2015 13:19:40 -0700 Received: from il-exch02.marvell.com (galiil.marvell.com [199.203.130.254]) by mx0b-0016f401.pphosted.com with ESMTP id 1v9ubfnhnj-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 29 Jun 2015 13:19:39 -0700 Received: from IL-EXCH01.marvell.com (10.4.102.220) by IL-EXCH02.marvell.com (10.4.102.221) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Mon, 29 Jun 2015 23:19:29 +0300 Received: from IL-EXCH01.marvell.com ([fe80::41:1c9f:8611:3a4a]) by IL-EXCH01.marvell.com ([fe80::41:1c9f:8611:3a4a%20]) with mapi id 15.00.1044.021; Mon, 29 Jun 2015 23:19:29 +0300 From: Tal Mizrahi To: Andy Bierman Thread-Topic: [Netconf] [FOWARDING] Last Call: (Time Capability in NETCONF) to Experimental RFC Thread-Index: AQHQspDXqIId9+7BtECIv6ffNOIXrp3DzWJw///YM4CAAEI+cA== Date: Mon, 29 Jun 2015 20:19:28 +0000 Message-ID: References: <20150629150721.GA2587@elstar.local> <7be9dceb27734ceb94bcb04fdfb3451c@IL-EXCH01.marvell.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [199.203.130.14] Content-Type: multipart/alternative; boundary="_000_f0c6024283f548629d32d2937ed9d2c0ILEXCH01marvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-06-29_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1506180000 definitions=main-1506290324 Archived-At: Cc: Netconf Subject: Re: [Netconf] [FOWARDING] Last Call: (Time Capability in NETCONF) to Experimental RFC X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 20:19:47 -0000 --_000_f0c6024283f548629d32d2937ed9d2c0ILEXCH01marvellcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW5keSwgSsO8cmdlbiwNCg0KVGhhbmtzIGZvciB0aGUgcHJvbXB0IHJlc3BvbnNlcy4NCg0KUXVv dGluZyBBbmR5Og0KDQo+IEFjdHVhbGx5LCBSRkMgNjI0MSBjb25maXJtZWQtY29tbWl0IGhhcyBh IDxjYW5jZWwtY29tbWl0PiBvcGVyYXRpb24NCj5zbyBpdCBjYW4gb3BlcmF0ZSB0aGUgc2FtZSB3 YXkgKGNsaWVudCBzZW5kIGNhbmNlbCB0byBOLTEgc2VydmVycyB3aGVuDQo+MSBzZXJ2ZXIgcmV0 dXJucyBhIGNvbW1pdC1mYWlsZWQgZXJyb3IpDQoNCkluZGVlZCwgYnV0IHRoZSA8Y2FuY2VsLWNv bW1pdD4gaXMgYXBwbGllZCBvbmx5IGFmdGVyIHRoZSBjb21taXQgd2FzIGFscmVhZHkgcGVyZm9y bWVkLCBtZWFuaW5nIHRoYXQgbm93IHRoZSBzZXJ2ZXIgaGFzIHRvIHJvbGwgYmFjay4NClRoZSA8 Y2FuY2VsLXNjaGVkdWxlPiBvcGVyYXRpb24gbGV0cyB5b3UgY2FuY2VsIHRoZSBjb21taXQgYmVm b3JlIGl0IGhhcyBvY2N1cnJlZCwgYWxsb3dpbmcgYWxsIHNlcnZlcnMgdG8gcmVtYWluIHdpdGgg dGhlIGN1cnJlbnQgY29uZmlndXJhdGlvbi4gU2VlIHRoZSBleGFtcGxlIGJlbG93Lg0KDQpRdW90 aW5nIErDvHJnZW46DQoNCj5CdXQgaWYgb25lIG91dCBvZiB0aGUgc2V2ZXJhbCBjb21taXRzIG5v dyBmYWlscywgaG93IGRvIHlvdSByZWNvdmVyIGZyb20gdGhhdD8gQW5kIGhvdyBpcyB0aGUgcmVj b3ZlcnkgYmV0dGVyIHRoYW4gTkMgd2l0aCBjb25maXJtZWQtY29tbWl0Pw0KDQpIZXJlIGlzIGFu IGV4YW1wbGU6DQoxLiBDbGllbnQgc2VuZHMgc2NoZWR1bGVkIGNvbW1pdCB0byBOIHNlcnZlcnMs IHRvIGJlIHBlcmZvcm1lZCBhdCBhIGZ1dHVyZSB0aW1lIFQuDQoyLiBPbmUgb2YgdGhlIHNlcnZl cnMgcmVwbGllcyB3aXRoIGFuIHJwYy1lcnJvciAobWVhbmluZyBpdCB3aWxsIG5vdCBiZSBhYmxl IHRvIGNvbW1pdCkuDQozLiBDbGllbnQgc2VuZHMgPGNhbmNlbC1zY2hlZHVsZT4gdG8gdGhlIG90 aGVyIE4tMSBzZXJ2ZXJzLCBiZWZvcmUgdGltZSBULiBOb25lIG9mIHRoZSBzZXJ2ZXJzIGhhcyBj b21taXR0ZWQgeWV0LCBhbmQgdGhleSBhbGwgY2FuY2VsIHRoZSBzY2hlZHVsZWQgY29tbWl0Lg0K DQpUaGUgYWR2YW50YWdlIGlzIHRoYXQgdGhlcmUgaXMgbm8gbmVlZCB0byByb2xsIGJhY2suIEZy b20gYSBuZXR3b3JrLXdpZGUgcGVyc3BlY3RpdmUsIHRoZSBjb25maWd1cmF0aW9uIHJlbWFpbnMg Y29udGludW91c2x5IGNvbnNpc3RlbnQgaW4gdGhlIHRocmVlIHN0ZXBzIGFib3ZlLg0KDQpRdW90 aW5nIEFuZHk6DQoNCj5UaGlzIGFzc3VtZXMgdGhhdCB0aGUgbG9hZCBvbiB0aGUgc3lzdGVtIGF0 IHRoZSB0aW1lIG9mIHRoZSBSUEMNCj5leGVjdXRpb24gaXMgc29tZXdoYXQga25vd24gYW5kIHN0 YWJsZS4gSSBhbSB0YWxraW5nIGFib3V0DQo+dGhlIGVsYXBzZWQgdGltZSBtZWFzdXJlbWVudC4N Cg0KSXQgaXMgbm90IGFzc3VtZWQgdGhhdCB0aGUgdGltZSBvZiB0aGUgUlBDIGV4ZWN1dGlvbiBp cyBrbm93biBvciBzdGFibGUuIFRoZSBzY2hlZHVsZWQtdGltZSBzcGVjaWZpZXMgdGhlICpzdGFy dCogdGltZSBvZiB0aGUgUlBDLCBhbmQgdGhlIGV4ZWN1dGlvbi10aW1lIHNwZWNpZmllcyB0aGUg KmNvbXBsZXRpb24qIHRpbWUuIFRoYXQgbWVhbnMgdGhhdCBieSBrbm93aW5nIHRoZSBzY2hlZHVs ZWQtdGltZSBhbmQgZXhlY3V0aW9uLXRpbWUsIHRoZSBjbGllbnQga25vd3MgdGhhdCB0aGUgZGlm ZmVyZW5jZSBiZXR3ZWVuIHRoZXNlIHR3byB2YWx1ZXMgaXMgdGhlIGVsYXBzZWQgdGltZSBvZiBl eGVjdXRpb24gKyB0aGUgc2NoZWR1bGluZyBpbmFjY3VyYWN5Lg0KVGh1cywgdGhlIDxleGVjdXRp b24tdGltZT4gcGFyYW1ldGVyIGFsbG93cyB0aGUgY2xpZW50IHRvIGRldGVjdCBhbmQgbW9uaXRv ciBmbHVjdHVhdGlvbnMgaW4gdGhlIFJQQyBleGVjdXRpb24gdGltZS4NCg0KUXVvdGluZyBKw7xy Z2VuOg0KDQo+WW91IHNlZW0gdG8gYmUgdGFsa2luZyBhYm91dCB0aGUgaWRlYSB0aGF0IG1hbmFn ZXIgd2FudHMgdG8gYWJvcnQgdGhlIHNjaGVkdWxlZCBjb21taXQuDQo+VGhpcyBkb2VzIG5vdCBl eGlzdCBpbiBOQyB3aXRoIGNvbmZpcm1lZC1jb21taXQsIGV4Y2VwdCB0aGF0IHRoZSBtYW5hZ2Vy IGNhbiBzaW1wbHkgc3RvcCBpbnZva2luZyBjb21taXRzIGlmIGl0IGNoYW5nZXMgaXRzIG1pbmQg c3BvbnRhbmVvdXNseS4NCg0KQXMgQW5keSBub3RlZCwgTkMgc3VwcG9ydHMgdGhlIDxjYW5jZWwt Y29tbWl0PiBvcGVyYXRpb24uIFRoZSBtYWluIGRpZmZlcmVuY2UgaXMgdGhhdCB0aGUgPGNhbmNl bC1jb21taXQ+IGlzIHBlcmZvcm1lZCAqYWZ0ZXIqIHRoZSBjb21taXQgd2FzIGFwcGxpZWQsIGFz IG9wcG9zZWQgdG8gdGhlIDxjYW5jZWwtc2NoZWR1bGU+LCBwZXJmb3JtZWQgKmJlZm9yZSogdGhl IGNvbW1pdCBpcyBhcHBsaWVkLg0KDQpDaGVlcnMsDQpUYWwuDQoNCkZyb206IEFuZHkgQmllcm1h biBbbWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbV0NClNlbnQ6IE1vbmRheSwgSnVuZSAyOSwgMjAx NSAxMDowNSBQTQ0KVG86IFRhbCBNaXpyYWhpDQpDYzogTmV0Y29uZg0KU3ViamVjdDogUmU6IFtO ZXRjb25mXSBbRk9XQVJESU5HXSBMYXN0IENhbGw6IDxkcmFmdC1tbS1uZXRjb25mLXRpbWUtY2Fw YWJpbGl0eS0wNS50eHQ+IChUaW1lIENhcGFiaWxpdHkgaW4gTkVUQ09ORikgdG8gRXhwZXJpbWVu dGFsIFJGQw0KDQoNCg0KT24gTW9uLCBKdW4gMjksIDIwMTUgYXQgMTE6NTMgQU0sIFRhbCBNaXpy YWhpIDx0YWxtaUBtYXJ2ZWxsLmNvbTxtYWlsdG86dGFsbWlAbWFydmVsbC5jb20+PiB3cm90ZToN CkhpIEFuZHksDQoNClRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzLg0KDQo+VGhlIGRyYWZ0IG1peGVz IHNlcnZlciBtZWFzdXJlbWVudCBvZiBSUEMgZXhlY3V0aW9uIHRpbWUNCj53aXRoIGEgImNyb24i IGZ1bmN0aW9uLiAgVGhlIHJhdGlvbmFsZSBmb3IgdGhpcyBncmFiLWJhZyBvZg0KPnRpbWUtcmVs YXRlZCBmdW5jdGlvbmFsaXR5IGlzIG5vdCBlbnRpcmVseSBjbGVhci4NCg0KT25lIG9mIHRoZSBt b3N0IG5vdGFibGUgdXNlIGNhc2VzIGlzIGEgbmV0d29yay13aWRlIGNvbW1pdC4gVGhlIHRpbWUg Y2FwYWJpbGl0eSAodXNpbmcgc2NoZWR1bGVkIGNvbW1pdHMgYW5kIGNhbmNlbC1zY2hlZHVsZSkg YWxsb3dzIGEgY2xpZW50IHRvIHBlcmZvcm0gYSBuZXR3b3JrLXdpZGUgY29tbWl0IGluIE4gc2Vy dmVycywgd2hlcmUgZWl0aGVyIGFsbCBwZXJmb3JtIHRoZSBjb21taXQsIG9yIG5vbmUgb2YgdGhl bSBkb2VzLiBTdWNoIGJlaGF2aW9yIGlzIG5vdCBjdXJyZW50bHkgcG9zc2libGUgd2l0aCBjb25m aXJtZWQgY29tbWl0cyAoUkZDNjI0MSk7IHdoZW4gdXNpbmcgY29uZmlybWVkIGNvbW1pdHMsIGlm IHNvbWV0aGluZyBnb2VzIHdyb25nLCB0aGVuIGFsbCB0aGUgc2VydmVycyByb2xsIGJhY2sgdG8g dGhlIHByZXZpb3VzIGNvbmZpZ3VyYXRpb24sIHdoaWNoIG1lYW5zIHRoYXQgdGhlcmUgaXMgYSAo cG90ZW50aWFsbHkgbG9uZykgdHJhbnNpZW50IHN0YXRlIHdoZXJlIHNvbWUgc2VydmVycyBoYXZl IGNoYW5nZWQgdGhlaXIgY29uZmlndXJhdGlvbiBhbmQgb3RoZXJzIGhhdmUgbm90Lg0KVGhlIHRp bWUgY2FwYWJpbGl0eSBhbGxvd3MgdGhlIGNsaWVudCB0byBjYW5jZWwgdGhlIGNvbW1pdCBpbiBh ZHZhbmNlOiBpZiBvbmUgb2YgdGhlIHNlcnZlcnMgaW5kaWNhdGVzIGl0IGNhbm5vdCBwZXJmb3Jt IHRoZSBjb21taXQgKHVzaW5nIGFuIGVycm9yIG1lc3NhZ2UpLCB0aGVuIHRoZSBjbGllbnQgc2Vu ZHMgYSBjYW5jZWxsYXRpb24gbWVzc2FnZSB0byBhbGwgdGhlIHNlcnZlcnMgYmVmb3JlIHRoZSBj b21taXQgaGFzIG9jY3VycmVkLiBBbGwgdGhlIHNlcnZlcnMgY29uc2lzdGVudGx5IHVzZSB0aGUg c2FtZSBkYXRhc3RvcmUgdGhyb3VnaG91dCB0aGUgcHJvY2VkdXJlLg0KDQoNCg0KQWN0dWFsbHks IFJGQyA2MjQxIGNvbmZpcm1lZC1jb21taXQgaGFzIGEgPGNhbmNlbC1jb21taXQ+IG9wZXJhdGlv bg0Kc28gaXQgY2FuIG9wZXJhdGUgdGhlIHNhbWUgd2F5IChjbGllbnQgc2VuZCBjYW5jZWwgdG8g Ti0xIHNlcnZlcnMgd2hlbg0KMSBzZXJ2ZXIgcmV0dXJucyBhIGNvbW1pdC1mYWlsZWQgZXJyb3Ip DQoNCg0KDQoNClRoZSBleGVjdXRpb24tdGltZSBwYXJhbWV0ZXIgYWxsb3dzIHRoZSBjbGllbnQg dG8gcmVjZWl2ZSBmZWVkYmFjayBhYm91dCB0aGUgYWN0dWFsIGV4ZWN1dGlvbiB0aW1lIG9mIHRo ZSBSUEMuIEJhc2VkIG9uIHRoaXMgZmVlZGJhY2sgdGhlIGNsaWVudDogKDEpIGtub3dzIGhvdyBh Y2N1cmF0ZWx5IHRoZSBzZXJ2ZXIgc2NoZWR1bGVkIHRoZSBSUEMsIGFuZCAoMikgaGFzIGEgKHJv dWdoKSBwaWN0dXJlIG9mIHdoZXRoZXIgdGhlIHNlcnZlcuKAmXMgY2xvY2sgaXMgc3luY2hyb25p emVkIHRvIGl0cyBvd24gKHNlZSBTZWN0aW9uIDMuMyBmb3IgZnVydGhlciBkaXNjdXNzaW9uKS4N Cg0KDQoNClRoaXMgYXNzdW1lcyB0aGF0IHRoZSBsb2FkIG9uIHRoZSBzeXN0ZW0gYXQgdGhlIHRp bWUgb2YgdGhlIFJQQw0KZXhlY3V0aW9uIGlzIHNvbWV3aGF0IGtub3duIGFuZCBzdGFibGUuIEkg YW0gdGFsa2luZyBhYm91dA0KdGhlIGVsYXBzZWQgdGltZSBtZWFzdXJlbWVudC4NCg0KVGhlIGNs ZWludCBjYW4gY2hlY2sgdGhlIHNlcnZlcidzIHRpbWUtb2YtZGF5IGp1c3QgYnkNCnJlYWRpbmcg dGhlIGN1cnJlbnQtZGF0ZS10aW1lIG9iamVjdC4gIEl0IGRvZXMgbm90IG5lZWQNCmV4ZWN1dGVk LWF0IHRpbWVzdGFtcHMgdG8gY2hlY2sgdGhhdCB0aGUgY2xvY2tzIGFyZSBpbiBzeW5jaC4NCg0K DQoNCg0KV2UgcHJlc2VudGVkIGEgZmV3IHVzZS1jYXNlcyBhdCB0aGUgSUVURiBtZWV0aW5nIGlu IEJlcmxpbiAoaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84Ny9zbGlkZXMvc2xpZGVz LTg3LW5ldGNvbmYtMS5wZGYpLCBhbmQgdGhlIERhbGxhcyBwcmVzZW50YXRpb24gKGh0dHBzOi8v d3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzkyL3NsaWRlcy9zbGlkZXMtOTItbmV0Y29uZi0xMy5w ZGYpLCB3aGljaCB3YXMgbm90IHByZXNlbnRlZCBkdWUgdG8gbGFjayBvZiB0aW1lLCBpbmNsdWRl ZCB0aGUgbmV0d29yay13aWRlIGNvbW1pdCB1c2UgY2FzZS4NCg0KQ2hlZXJzLA0KVGFsLg0KDQoN Cg0KQW5keQ0KDQpGcm9tOiBOZXRjb25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgQW5keSBCaWVy bWFuDQpTZW50OiBNb25kYXksIEp1bmUgMjksIDIwMTUgODoyNyBQTQ0KVG86IEp1ZXJnZW4gU2No b2Vud2FlbGRlcjsgTmV0Y29uZg0KU3ViamVjdDogUmU6IFtOZXRjb25mXSBbRk9XQVJESU5HXSBM YXN0IENhbGw6IDxkcmFmdC1tbS1uZXRjb25mLXRpbWUtY2FwYWJpbGl0eS0wNS50eHQ+IChUaW1l IENhcGFiaWxpdHkgaW4gTkVUQ09ORikgdG8gRXhwZXJpbWVudGFsIFJGQw0KDQpIaSwNCg0KDQpJ cyB0aGlzIGFuIEFELXNwb25zb3JlZCBkcmFmdD8NCg0KVGhpcyBkcmFmdCB3YXMgImludGVyZXN0 aW5nIiBidXQgbm90IGVub3VnaCB0byBiZSBwcmlvcml0aXplZCBhaGVhZA0Kb2Ygb3RoZXIgd29y ayBiZWluZyBkb25lIGluIHRoZSBORVRDT05GIFdHLg0KDQpUaGUgZHJhZnQgbWl4ZXMgc2VydmVy IG1lYXN1cmVtZW50IG9mIFJQQyBleGVjdXRpb24gdGltZQ0Kd2l0aCBhICJjcm9uIiBmdW5jdGlv bi4gIFRoZSByYXRpb25hbGUgZm9yIHRoaXMgZ3JhYi1iYWcgb2YNCnRpbWUtcmVsYXRlZCBmdW5j dGlvbmFsaXR5IGlzIG5vdCBlbnRpcmVseSBjbGVhci4NCg0KVGhpcyB3b3JrIGRvZXMgbm90IGhh dmUgYW55IGNvbnNlbnN1cyB3aXRoaW4gdGhlIE5FVENPTkYgV0cuDQpJdCBkb2VzIHNlZW0gYSBs aXR0bGUgc3VycHJpc2luZyB0aGF0IGl0IGlzIGJlaW5nIHB1Ymxpc2hlZCB3aXRob3V0DQpldmVu IGFza2luZyB0aGUgTkVUQ09ORiBXRyBmb3IgY29tbWVudHMuDQoNCkkgZG9uJ3QgaGF2ZSBhbnkg cHJvYmxlbSB3aXRoIEV4cGVyaW1lbnRhbCBSRkNzIGFzIGxvbmcgYXMgaXQNCmlzIGNsZWFyIHRo aXMgaXMgbm90IGEgcHJvZHVjdCBvZiB0aGUgTkVUQ09ORiBXRy4NCg0KDQoNCkFuZHkNCg0KDQoN Ck9uIE1vbiwgSnVuIDI5LCAyMDE1IGF0IDg6MDcgQU0sIEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8 ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPG1haWx0bzpqLnNjaG9lbndhZWxk ZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+PiB3cm90ZToNCkhpLA0KDQpqdXN0IHRvIG1ha2Ugc3Vy ZSBldmVyeWJvZHkgaGVyZSBoYXMgc2VlbiB0aGlzLg0KDQovanMNCg0KLS0NCkp1ZXJnZW4gU2No b2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQpQaG9u ZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4g fCBHZXJtYW55DQpGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwOi8vd3d3Lmph Y29icy11bml2ZXJzaXR5LmRlLz4NCg0KDQotLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0t LS0tLS0tLS0NCkZyb206IFRoZSBJRVNHIDxpZXNnLXNlY3JldGFyeUBpZXRmLm9yZzxtYWlsdG86 aWVzZy1zZWNyZXRhcnlAaWV0Zi5vcmc+Pg0KVG86IElFVEYtQW5ub3VuY2UgPGlldGYtYW5ub3Vu Y2VAaWV0Zi5vcmc8bWFpbHRvOmlldGYtYW5ub3VuY2VAaWV0Zi5vcmc+Pg0KQ2M6DQpEYXRlOiBN b24sIDI5IEp1biAyMDE1IDA3OjU4OjIyIC0wNzAwDQpTdWJqZWN0OiBMYXN0IENhbGw6IDxkcmFm dC1tbS1uZXRjb25mLXRpbWUtY2FwYWJpbGl0eS0wNS50eHQ+IChUaW1lIENhcGFiaWxpdHkgaW4g TkVUQ09ORikgdG8gRXhwZXJpbWVudGFsIFJGQw0KDQpUaGUgSUVTRyBoYXMgcmVjZWl2ZWQgYSBy ZXF1ZXN0IGZyb20gYW4gaW5kaXZpZHVhbCBzdWJtaXR0ZXIgdG8gY29uc2lkZXINCnRoZSBmb2xs b3dpbmcgZG9jdW1lbnQ6DQotICdUaW1lIENhcGFiaWxpdHkgaW4gTkVUQ09ORicNCiAgPGRyYWZ0 LW1tLW5ldGNvbmYtdGltZS1jYXBhYmlsaXR5LTA1LnR4dD4gYXMgRXhwZXJpbWVudGFsIFJGQw0K DQpUaGUgSUVTRyBwbGFucyB0byBtYWtlIGEgZGVjaXNpb24gaW4gdGhlIG5leHQgZmV3IHdlZWtz LCBhbmQgc29saWNpdHMNCmZpbmFsIGNvbW1lbnRzIG9uIHRoaXMgYWN0aW9uLiBQbGVhc2Ugc2Vu ZCBzdWJzdGFudGl2ZSBjb21tZW50cyB0byB0aGUNCmlldGZAaWV0Zi5vcmc8bWFpbHRvOmlldGZA aWV0Zi5vcmc+IG1haWxpbmcgbGlzdHMgYnkgMjAxNS0wNy0yOS4gRXhjZXB0aW9uYWxseSwgY29t bWVudHMgbWF5IGJlDQpzZW50IHRvIGllc2dAaWV0Zi5vcmc8bWFpbHRvOmllc2dAaWV0Zi5vcmc+ IGluc3RlYWQuIEluIGVpdGhlciBjYXNlLCBwbGVhc2UgcmV0YWluIHRoZQ0KYmVnaW5uaW5nIG9m IHRoZSBTdWJqZWN0IGxpbmUgdG8gYWxsb3cgYXV0b21hdGVkIHNvcnRpbmcuDQoNCkFic3RyYWN0 DQoNCg0KICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgY2FwYWJpbGl0eS1iYXNlZCBleHRlbnNp b24gdG8gdGhlIE5ldHdvcmsNCiAgIENvbmZpZ3VyYXRpb24gUHJvdG9jb2wgKE5FVENPTkYpIHRo YXQgYWxsb3dzIHRpbWUtdHJpZ2dlcmVkDQogICBjb25maWd1cmF0aW9uIGFuZCBtYW5hZ2VtZW50 IG9wZXJhdGlvbnMuIFRoaXMgZXh0ZW5zaW9uIGFsbG93cw0KICAgTkVUQ09ORiBjbGllbnRzIHRv IGludm9rZSBjb25maWd1cmF0aW9uIHVwZGF0ZXMgYWNjb3JkaW5nIHRvDQogICBzY2hlZHVsZWQg dGltZXMsIGFuZCBhbGxvd3MgTkVUQ09ORiBzZXJ2ZXJzIHRvIGF0dGFjaCB0aW1lc3RhbXBzIHRv DQogICB0aGUgZGF0YSB0aGV5IHNlbmQgdG8gTkVUQ09ORiBjbGllbnRzLg0KDQoNClRoZSBOZXR3 b3JrIENvbmZpZ3VyYXRpb24gUHJvdG9jb2wgKE5FVENPTkYpIENhcGFiaWxpdHkgVVJOcyByZWdp c3RyeQ0KcmVxdWlyZXMgYSBzdGFuZGFyZHMgYWN0aW9uIGluIG9yZGVyIHRvIHBvcHVsYXRlIHRo ZSByZWdpc3RyeS4gVGhpcyBkb2N1bWVudA0Kd2FzIHRha2VuIG91dCBvZiB0aGUgSVNFIHN0cmVh bSBhbmQgYnJvdWdodCBmb3J3YXJkIGFzIGFuIEFEIHNwb25zb3JlZA0KaW5kaXZpZHVhbC1zdWJt aXNzaW9uIHRvIGFkZHJlc3MgdGhpcyBjb25zaWRlcmF0aW9uLg0KDQoNClRoZSBmaWxlIGNhbiBi ZSBvYnRhaW5lZCB2aWENCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1t LW5ldGNvbmYtdGltZS1jYXBhYmlsaXR5Lw0KDQpJRVNHIGRpc2N1c3Npb24gY2FuIGJlIHRyYWNr ZWQgdmlhDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1tbS1uZXRjb25m LXRpbWUtY2FwYWJpbGl0eS9iYWxsb3QvDQoNCg0KTm8gSVBSIGRlY2xhcmF0aW9ucyBoYXZlIGJl ZW4gc3VibWl0dGVkIGRpcmVjdGx5IG9uIHRoaXMgSS1ELg0KDQoNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk5ldGNvbmYgbWFpbGluZyBsaXN0DQpO ZXRjb25mQGlldGYub3JnPG1haWx0bzpOZXRjb25mQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQoNCg0K --_000_f0c6024283f548629d32d2937ed9d2c0ILEXCH01marvellcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1z b0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGlu Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6 LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMjVpbiAxLjBp biAxLjI1aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBM aXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo3ODI5MTc0ODY7DQoJ bXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi00OTEzODUyMDIg Njc2OTg3MDUgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2 OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC10 ZXh0OiIlMVwpIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21h bi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7 bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz dCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsN Cgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFs cGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6 LTkuMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206 MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QW5keSwgSsO8cmdl biw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlRoYW5rcyBmb3IgdGhlIHByb21wdCByZXNwb25zZXMuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5R dW90aW5nIEFuZHk6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IEFjdHVhbGx5 LCBSRkMgNjI0MSBjb25maXJtZWQtY29tbWl0IGhhcyBhICZsdDtjYW5jZWwtY29tbWl0Jmd0OyBv cGVyYXRpb248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDtzbyBpdCBj YW4gb3BlcmF0ZSB0aGUgc2FtZSB3YXkgKGNsaWVudCBzZW5kIGNhbmNlbCB0byBOLTEgc2VydmVy cyB3aGVuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7MSBzZXJ2ZXIg cmV0dXJucyBhIGNvbW1pdC1mYWlsZWQgZXJyb3IpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkluZGVlZCwgYnV0IHRoZSAmbHQ7Y2Fu Y2VsLWNvbW1pdCZndDsgaXMgYXBwbGllZCBvbmx5IGFmdGVyIHRoZSBjb21taXQgd2FzIGFscmVh ZHkgcGVyZm9ybWVkLCBtZWFuaW5nIHRoYXQgbm93IHRoZSBzZXJ2ZXIgaGFzIHRvIHJvbGwgYmFj ay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlICZsdDtjYW5jZWwtc2NoZWR1bGUm Z3Q7IG9wZXJhdGlvbiBsZXRzIHlvdSBjYW5jZWwgdGhlIGNvbW1pdCBiZWZvcmUgaXQgaGFzIG9j Y3VycmVkLCBhbGxvd2luZyBhbGwgc2VydmVycyB0byByZW1haW4gd2l0aCB0aGUgY3VycmVudCBj b25maWd1cmF0aW9uLiBTZWUgdGhlIGV4YW1wbGUNCiBiZWxvdy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlF1b3Rpbmcg SsO8cmdlbjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0O0J1dCBpZiBvbmUgb3V0IG9mIHRo ZSBzZXZlcmFsIGNvbW1pdHMgbm93IGZhaWxzLCBob3cgZG8geW91IHJlY292ZXIgZnJvbSB0aGF0 PyBBbmQgaG93IGlzIHRoZSByZWNvdmVyeSBiZXR0ZXIgdGhhbiBOQyB3aXRoIGNvbmZpcm1lZC1j b21taXQ/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkhlcmUgaXMgYW4gZXhhbXBsZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+MS4gQ2xpZW50IHNlbmRzIHNjaGVkdWxlZCBjb21taXQgdG8gTiBzZXJ2ZXJzLCB0byBiZSBw ZXJmb3JtZWQgYXQgYSBmdXR1cmUgdGltZSBULjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4yLiBPbmUgb2YgdGhlIHNlcnZlcnMgcmVwbGllcyB3aXRoIGFuIHJwYy1lcnJvciAobWVhbmlu ZyBpdCB3aWxsIG5vdCBiZSBhYmxlIHRvIGNvbW1pdCkuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjMuIENsaWVudCBzZW5kcyAmbHQ7Y2FuY2VsLXNjaGVkdWxlJmd0OyB0byB0aGUgb3Ro ZXIgTi0xIHNlcnZlcnMsIGJlZm9yZSB0aW1lIFQuIE5vbmUgb2YgdGhlIHNlcnZlcnMgaGFzIGNv bW1pdHRlZCB5ZXQsIGFuZCB0aGV5IGFsbCBjYW5jZWwgdGhlIHNjaGVkdWxlZCBjb21taXQuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5UaGUgYWR2YW50YWdlIGlzIHRoYXQgdGhlcmUgaXMgbm8gbmVlZCB0byByb2xsIGJh Y2suIEZyb20gYSBuZXR3b3JrLXdpZGUgcGVyc3BlY3RpdmUsIHRoZSBjb25maWd1cmF0aW9uIHJl bWFpbnMgY29udGludW91c2x5IGNvbnNpc3RlbnQgaW4gdGhlIHRocmVlIHN0ZXBzIGFib3ZlLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+UXVvdGluZyBBbmR5Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7VGhpcyBh c3N1bWVzIHRoYXQgdGhlIGxvYWQgb24gdGhlIHN5c3RlbSBhdCB0aGUgdGltZSBvZiB0aGUgUlBD PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7ZXhlY3V0aW9uIGlzIHNv bWV3aGF0IGtub3duIGFuZCBzdGFibGUuIEkgYW0gdGFsa2luZyBhYm91dDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0O3RoZSBlbGFwc2VkIHRpbWUgbWVhc3VyZW1lbnQu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkl0IGlzIG5vdCBhc3N1bWVkIHRoYXQgdGhlIHRpbWUgb2YgdGhlIFJQQyBleGVjdXRpb24g aXMga25vd24gb3Igc3RhYmxlLiBUaGUgc2NoZWR1bGVkLXRpbWUgc3BlY2lmaWVzIHRoZSAqPGI+ c3RhcnQ8L2I+KiB0aW1lIG9mIHRoZSBSUEMsIGFuZCB0aGUgZXhlY3V0aW9uLXRpbWUNCiBzcGVj aWZpZXMgdGhlICo8Yj5jb21wbGV0aW9uPC9iPiogdGltZS4gVGhhdCBtZWFucyB0aGF0IGJ5IGtu b3dpbmcgdGhlIHNjaGVkdWxlZC10aW1lIGFuZCBleGVjdXRpb24tdGltZSwgdGhlIGNsaWVudCBr bm93cyB0aGF0IHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlc2UgdHdvIHZhbHVlcyBpcyB0aGUg ZWxhcHNlZCB0aW1lIG9mIGV4ZWN1dGlvbiAmIzQzOyB0aGUgc2NoZWR1bGluZyBpbmFjY3VyYWN5 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaHVzLCB0aGUgJmx0O2V4ZWN1dGlvbi10 aW1lJmd0OyBwYXJhbWV0ZXIgYWxsb3dzIHRoZSBjbGllbnQgdG8gZGV0ZWN0IGFuZCBtb25pdG9y IGZsdWN0dWF0aW9ucyBpbiB0aGUgUlBDIGV4ZWN1dGlvbiB0aW1lLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UXVvdGlu ZyBKw7xyZ2VuOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7WW91IHNlZW0gdG8gYmUgdGFs a2luZyBhYm91dCB0aGUgaWRlYSB0aGF0IG1hbmFnZXIgd2FudHMgdG8gYWJvcnQgdGhlIHNjaGVk dWxlZCBjb21taXQuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDtU aGlzIGRvZXMgbm90IGV4aXN0IGluIE5DIHdpdGggY29uZmlybWVkLWNvbW1pdCwgZXhjZXB0IHRo YXQgdGhlIG1hbmFnZXIgY2FuIHNpbXBseSBzdG9wIGludm9raW5nIGNvbW1pdHMgaWYgaXQgY2hh bmdlcyBpdHMgbWluZCBzcG9udGFuZW91c2x5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BcyBBbmR5IG5vdGVkLCBOQyBzdXBwb3J0 cyB0aGUgJmx0O2NhbmNlbC1jb21taXQmZ3Q7IG9wZXJhdGlvbi4gVGhlIG1haW4gZGlmZmVyZW5j ZSBpcyB0aGF0IHRoZSAmbHQ7Y2FuY2VsLWNvbW1pdCZndDsgaXMgcGVyZm9ybWVkICo8Yj5hZnRl cjwvYj4qIHRoZSBjb21taXQgd2FzIGFwcGxpZWQsDQogYXMgb3Bwb3NlZCB0byB0aGUgJmx0O2Nh bmNlbC1zY2hlZHVsZSZndDssIHBlcmZvcm1lZCAqPGI+YmVmb3JlPC9iPiogdGhlIGNvbW1pdCBp cyBhcHBsaWVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UYWwu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBBbmR5IEJpZXJtYW4g W21haWx0bzphbmR5QHl1bWF3b3Jrcy5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBK dW5lIDI5LCAyMDE1IDEwOjA1IFBNPGJyPg0KPGI+VG86PC9iPiBUYWwgTWl6cmFoaTxicj4NCjxi PkNjOjwvYj4gTmV0Y29uZjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW05ldGNvbmZdIFtGT1dB UkRJTkddIExhc3QgQ2FsbDogJmx0O2RyYWZ0LW1tLW5ldGNvbmYtdGltZS1jYXBhYmlsaXR5LTA1 LnR4dCZndDsgKFRpbWUgQ2FwYWJpbGl0eSBpbiBORVRDT05GKSB0byBFeHBlcmltZW50YWwgUkZD PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBKdW4gMjksIDIwMTUgYXQgMTE6NTMg QU0sIFRhbCBNaXpyYWhpICZsdDs8YSBocmVmPSJtYWlsdG86dGFsbWlAbWFydmVsbC5jb20iIHRh cmdldD0iX2JsYW5rIj50YWxtaUBtYXJ2ZWxsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBBbmR5LDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5r cyBmb3IgdGhlIGNvbW1lbnRzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jmd0O1RoZSBk cmFmdCBtaXhlcyBzZXJ2ZXIgbWVhc3VyZW1lbnQgb2YgUlBDIGV4ZWN1dGlvbiB0aW1lPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZndDt3aXRoIGEgJnF1b3Q7Y3JvbiZx dW90OyBmdW5jdGlvbi4mbmJzcDsgVGhlIHJhdGlvbmFsZSBmb3IgdGhpcyBncmFiLWJhZyBvZjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mZ3Q7dGltZS1yZWxhdGVkIGZ1 bmN0aW9uYWxpdHkgaXMgbm90IGVudGlyZWx5IGNsZWFyLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T25lIG9mIHRoZSBtb3N0 IG5vdGFibGUgdXNlIGNhc2VzIGlzIGEgbmV0d29yay13aWRlIGNvbW1pdC4gVGhlIHRpbWUgY2Fw YWJpbGl0eSAodXNpbmcgc2NoZWR1bGVkDQogY29tbWl0cyBhbmQgY2FuY2VsLXNjaGVkdWxlKSBh bGxvd3MgYSBjbGllbnQgdG8gcGVyZm9ybSBhIG5ldHdvcmstd2lkZSBjb21taXQgaW4gTiBzZXJ2 ZXJzLCB3aGVyZSBlaXRoZXIgYWxsIHBlcmZvcm0gdGhlIGNvbW1pdCwgb3Igbm9uZSBvZiB0aGVt IGRvZXMuIFN1Y2ggYmVoYXZpb3IgaXMgbm90IGN1cnJlbnRseSBwb3NzaWJsZSB3aXRoIGNvbmZp cm1lZCBjb21taXRzIChSRkM2MjQxKTsgd2hlbiB1c2luZyBjb25maXJtZWQgY29tbWl0cywgaWYN CiBzb21ldGhpbmcgZ29lcyB3cm9uZywgdGhlbiBhbGwgdGhlIHNlcnZlcnMgcm9sbCBiYWNrIHRv IHRoZSBwcmV2aW91cyBjb25maWd1cmF0aW9uLCB3aGljaCBtZWFucyB0aGF0IHRoZXJlIGlzIGEg KHBvdGVudGlhbGx5IGxvbmcpIHRyYW5zaWVudCBzdGF0ZSB3aGVyZSBzb21lIHNlcnZlcnMgaGF2 ZSBjaGFuZ2VkIHRoZWlyIGNvbmZpZ3VyYXRpb24gYW5kIG90aGVycyBoYXZlIG5vdC48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgdGltZSBjYXBhYmlsaXR5IGFsbG93cyB0aGUg Y2xpZW50IHRvIGNhbmNlbCB0aGUgY29tbWl0IGluIGFkdmFuY2U6IGlmIG9uZSBvZiB0aGUgc2Vy dmVycyBpbmRpY2F0ZXMNCiBpdCBjYW5ub3QgcGVyZm9ybSB0aGUgY29tbWl0ICh1c2luZyBhbiBl cnJvciBtZXNzYWdlKSwgdGhlbiB0aGUgY2xpZW50IHNlbmRzIGEgY2FuY2VsbGF0aW9uIG1lc3Nh Z2UgdG8gYWxsIHRoZSBzZXJ2ZXJzIGJlZm9yZSB0aGUgY29tbWl0IGhhcyBvY2N1cnJlZC4gQWxs IHRoZSBzZXJ2ZXJzIGNvbnNpc3RlbnRseSB1c2UgdGhlIHNhbWUgZGF0YXN0b3JlIHRocm91Z2hv dXQgdGhlIHByb2NlZHVyZS4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkFjdHVhbGx5LCBSRkMgNjI0MSBjb25maXJtZWQtY29tbWl0IGhhcyBh ICZsdDtjYW5jZWwtY29tbWl0Jmd0OyBvcGVyYXRpb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnNvIGl0IGNhbiBvcGVyYXRlIHRoZSBzYW1lIHdh eSAoY2xpZW50IHNlbmQgY2FuY2VsIHRvIE4tMSBzZXJ2ZXJzIHdoZW48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEgc2VydmVyIHJldHVybnMgYSBj b21taXQtZmFpbGVkIGVycm9yKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBleGVjdXRpb24tdGltZSBwYXJhbWV0 ZXIgYWxsb3dzIHRoZSBjbGllbnQgdG8gcmVjZWl2ZSBmZWVkYmFjayBhYm91dCB0aGUgYWN0dWFs IGV4ZWN1dGlvbiB0aW1lDQogb2YgdGhlIFJQQy4gQmFzZWQgb24gdGhpcyBmZWVkYmFjayB0aGUg Y2xpZW50OiAoMSkga25vd3MgaG93IGFjY3VyYXRlbHkgdGhlIHNlcnZlciBzY2hlZHVsZWQgdGhl IFJQQywgYW5kICgyKSBoYXMgYSAocm91Z2gpIHBpY3R1cmUgb2Ygd2hldGhlciB0aGUgc2VydmVy 4oCZcyBjbG9jayBpcyBzeW5jaHJvbml6ZWQgdG8gaXRzIG93biAoc2VlIFNlY3Rpb24gMy4zIGZv ciBmdXJ0aGVyIGRpc2N1c3Npb24pLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBhc3N1bWVzIHRoYXQgdGhl IGxvYWQgb24gdGhlIHN5c3RlbSBhdCB0aGUgdGltZSBvZiB0aGUgUlBDPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5leGVjdXRpb24gaXMgc29tZXdo YXQga25vd24gYW5kIHN0YWJsZS4gSSBhbSB0YWxraW5nIGFib3V0PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGUgZWxhcHNlZCB0aW1lIG1lYXN1 cmVtZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGUgY2xlaW50IGNhbiBjaGVjayB0aGUgc2VydmVyJ3MgdGltZS1vZi1kYXkganVzdCBi eTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cmVh ZGluZyB0aGUgY3VycmVudC1kYXRlLXRpbWUgb2JqZWN0LiZuYnNwOyBJdCBkb2VzIG5vdCBuZWVk PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5leGVj dXRlZC1hdCB0aW1lc3RhbXBzIHRvIGNoZWNrIHRoYXQgdGhlIGNsb2NrcyBhcmUgaW4gc3luY2gu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+V2UgcHJlc2VudGVkIGEgZmV3IHVzZS1jYXNlcyBhdCB0aGUgSUVURiBtZWV0 aW5nIGluIEJlcmxpbiAoPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84 Ny9zbGlkZXMvc2xpZGVzLTg3LW5ldGNvbmYtMS5wZGYiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8v d3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzg3L3NsaWRlcy9zbGlkZXMtODctbmV0Y29uZi0xLnBk ZjwvYT4pLA0KIGFuZCB0aGUgRGFsbGFzIHByZXNlbnRhdGlvbiAoPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTIvc2xpZGVzL3NsaWRlcy05Mi1uZXRjb25mLTEzLnBk ZiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzkyL3Ns aWRlcy9zbGlkZXMtOTItbmV0Y29uZi0xMy5wZGY8L2E+KSwgd2hpY2ggd2FzIG5vdCBwcmVzZW50 ZWQgZHVlIHRvIGxhY2sgb2YgdGltZSwgaW5jbHVkZWQgdGhlIG5ldHdvcmstd2lkZQ0KIGNvbW1p dCB1c2UgY2FzZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DaGVlcnMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPlRhbC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmln aHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4gTmV0Y29uZiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpuZXRjb25mLWJvdW5jZXNA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5uZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0K PGI+T24gQmVoYWxmIE9mIDwvYj5BbmR5IEJpZXJtYW48YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5 LCBKdW5lIDI5LCAyMDE1IDg6MjcgUE08YnI+DQo8Yj5Ubzo8L2I+IEp1ZXJnZW4gU2Nob2Vud2Fl bGRlcjsgTmV0Y29uZjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW05ldGNvbmZdIFtGT1dBUkRJ TkddIExhc3QgQ2FsbDogJmx0O2RyYWZ0LW1tLW5ldGNvbmYtdGltZS1jYXBhYmlsaXR5LTA1LnR4 dCZndDsgKFRpbWUgQ2FwYWJpbGl0eSBpbiBORVRDT05GKSB0byBFeHBlcmltZW50YWwgUkZDPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhpLDxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JcyB0aGlzIGFuIEFELXNw b25zb3JlZCBkcmFmdD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPlRoaXMgZHJhZnQgd2FzICZxdW90O2ludGVyZXN0aW5nJnF1b3Q7IGJ1 dCBub3QgZW5vdWdoIHRvIGJlIHByaW9yaXRpemVkIGFoZWFkPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPm9mIG90aGVyIHdvcmsgYmVpbmcgZG9u ZSBpbiB0aGUgTkVUQ09ORiBXRy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBkcmFmdCBtaXhlcyBzZXJ2ZXIgbWVhc3VyZW1lbnQg b2YgUlBDIGV4ZWN1dGlvbiB0aW1lPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPndpdGggYSAmcXVvdDtjcm9uJnF1b3Q7IGZ1bmN0aW9uLiZuYnNw OyBUaGUgcmF0aW9uYWxlIGZvciB0aGlzIGdyYWItYmFnIG9mPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnRpbWUtcmVsYXRlZCBmdW5jdGlvbmFs aXR5IGlzIG5vdCBlbnRpcmVseSBjbGVhci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoaXMgd29yayBkb2VzIG5vdCBoYXZlIGFueSBj b25zZW5zdXMgd2l0aGluIHRoZSBORVRDT05GIFdHLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JdCBkb2VzIHNlZW0gYSBsaXR0bGUgc3VycHJp c2luZyB0aGF0IGl0IGlzIGJlaW5nIHB1Ymxpc2hlZCB3aXRob3V0PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPmV2ZW4gYXNraW5nIHRoZSBORVRD T05GIFdHIGZvciBjb21tZW50cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgZG9uJ3QgaGF2ZSBhbnkgcHJvYmxlbSB3aXRoIEV4cGVy aW1lbnRhbCBSRkNzIGFzIGxvbmcgYXMgaXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+aXMgY2xlYXIgdGhpcyBpcyBub3QgYSBwcm9kdWN0IG9m IHRoZSBORVRDT05GIFdHLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BbmR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIE1vbiwgSnVuIDI5LCAy MDE1IGF0IDg6MDcgQU0sIEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAmbHQ7PGEgaHJlZj0ibWFpbHRv Omouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZSIgdGFyZ2V0PSJfYmxhbmsiPmou c2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5IaSw8YnI+DQo8YnI+DQpqdXN0IHRvIG1ha2Ugc3Vy ZSBldmVyeWJvZHkgaGVyZSBoYXMgc2VlbiB0aGlzLjxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjoj ODg4ODg4Ij48YnI+DQovanM8YnI+DQo8YnI+DQotLTxicj4NCkp1ZXJnZW4gU2Nob2Vud2FlbGRl ciZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SmFjb2JzIFVuaXZlcnNp dHkgQnJlbWVuIGdHbWJIPGJyPg0KUGhvbmU6ICYjNDM7NDkgNDIxIDIwMCAzNTg3Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0NhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBH ZXJtYW55PGJyPg0KRmF4OiZuYnNwOyAmbmJzcDsmIzQzOzQ5IDQyMSAyMDAgMzEwMyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7PGEgaHJlZj0iaHR0cDovL3d3dy5qYWNvYnMt dW5pdmVyc2l0eS5kZS8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LmphY29icy11bml2ZXJz aXR5LmRlLzwvYT4mZ3Q7PGJyPg0KPC9zcGFuPjxicj4NCjxicj4NCi0tLS0tLS0tLS0gRm9yd2Fy ZGVkIG1lc3NhZ2UgLS0tLS0tLS0tLTxicj4NCkZyb206Jm5ic3A7VGhlIElFU0cgJmx0OzxhIGhy ZWY9Im1haWx0bzppZXNnLXNlY3JldGFyeUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmllc2ct c2VjcmV0YXJ5QGlldGYub3JnPC9hPiZndDs8YnI+DQpUbzombmJzcDtJRVRGLUFubm91bmNlICZs dDs8YSBocmVmPSJtYWlsdG86aWV0Zi1hbm5vdW5jZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PmlldGYtYW5ub3VuY2VAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCkNjOiZuYnNwOzxicj4NCkRhdGU6 Jm5ic3A7TW9uLCAyOSBKdW4gMjAxNSAwNzo1ODoyMiAtMDcwMDxicj4NClN1YmplY3Q6Jm5ic3A7 TGFzdCBDYWxsOiAmbHQ7ZHJhZnQtbW0tbmV0Y29uZi10aW1lLWNhcGFiaWxpdHktMDUudHh0Jmd0 OyAoVGltZSBDYXBhYmlsaXR5IGluIE5FVENPTkYpIHRvIEV4cGVyaW1lbnRhbCBSRkM8YnI+DQo8 YnI+DQpUaGUgSUVTRyBoYXMgcmVjZWl2ZWQgYSByZXF1ZXN0IGZyb20gYW4gaW5kaXZpZHVhbCBz dWJtaXR0ZXIgdG8gY29uc2lkZXI8YnI+DQp0aGUgZm9sbG93aW5nIGRvY3VtZW50Ojxicj4NCi0g J1RpbWUgQ2FwYWJpbGl0eSBpbiBORVRDT05GJzxicj4NCiZuYnNwOyAmbHQ7ZHJhZnQtbW0tbmV0 Y29uZi10aW1lLWNhcGFiaWxpdHktMDUudHh0Jmd0OyBhcyBFeHBlcmltZW50YWwgUkZDPGJyPg0K PGJyPg0KVGhlIElFU0cgcGxhbnMgdG8gbWFrZSBhIGRlY2lzaW9uIGluIHRoZSBuZXh0IGZldyB3 ZWVrcywgYW5kIHNvbGljaXRzPGJyPg0KZmluYWwgY29tbWVudHMgb24gdGhpcyBhY3Rpb24uIFBs ZWFzZSBzZW5kIHN1YnN0YW50aXZlIGNvbW1lbnRzIHRvIHRoZTxicj4NCjxhIGhyZWY9Im1haWx0 bzppZXRmQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aWV0ZkBpZXRmLm9yZzwvYT4gbWFpbGlu ZyBsaXN0cyBieSAyMDE1LTA3LTI5LiBFeGNlcHRpb25hbGx5LCBjb21tZW50cyBtYXkgYmU8YnI+ DQpzZW50IHRvIDxhIGhyZWY9Im1haWx0bzppZXNnQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ aWVzZ0BpZXRmLm9yZzwvYT4gaW5zdGVhZC4gSW4gZWl0aGVyIGNhc2UsIHBsZWFzZSByZXRhaW4g dGhlPGJyPg0KYmVnaW5uaW5nIG9mIHRoZSBTdWJqZWN0IGxpbmUgdG8gYWxsb3cgYXV0b21hdGVk IHNvcnRpbmcuPGJyPg0KPGJyPg0KQWJzdHJhY3Q8YnI+DQo8YnI+DQo8YnI+DQombmJzcDsgJm5i c3A7VGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgY2FwYWJpbGl0eS1iYXNlZCBleHRlbnNpb24gdG8g dGhlIE5ldHdvcms8YnI+DQombmJzcDsgJm5ic3A7Q29uZmlndXJhdGlvbiBQcm90b2NvbCAoTkVU Q09ORikgdGhhdCBhbGxvd3MgdGltZS10cmlnZ2VyZWQ8YnI+DQombmJzcDsgJm5ic3A7Y29uZmln dXJhdGlvbiBhbmQgbWFuYWdlbWVudCBvcGVyYXRpb25zLiBUaGlzIGV4dGVuc2lvbiBhbGxvd3M8 YnI+DQombmJzcDsgJm5ic3A7TkVUQ09ORiBjbGllbnRzIHRvIGludm9rZSBjb25maWd1cmF0aW9u IHVwZGF0ZXMgYWNjb3JkaW5nIHRvPGJyPg0KJm5ic3A7ICZuYnNwO3NjaGVkdWxlZCB0aW1lcywg YW5kIGFsbG93cyBORVRDT05GIHNlcnZlcnMgdG8gYXR0YWNoIHRpbWVzdGFtcHMgdG88YnI+DQom bmJzcDsgJm5ic3A7dGhlIGRhdGEgdGhleSBzZW5kIHRvIE5FVENPTkYgY2xpZW50cy48YnI+DQo8 YnI+DQo8YnI+DQpUaGUgTmV0d29yayBDb25maWd1cmF0aW9uIFByb3RvY29sIChORVRDT05GKSBD YXBhYmlsaXR5IFVSTnMgcmVnaXN0cnk8YnI+DQpyZXF1aXJlcyBhIHN0YW5kYXJkcyBhY3Rpb24g aW4gb3JkZXIgdG8gcG9wdWxhdGUgdGhlIHJlZ2lzdHJ5LiBUaGlzIGRvY3VtZW50PGJyPg0Kd2Fz IHRha2VuIG91dCBvZiB0aGUgSVNFIHN0cmVhbSBhbmQgYnJvdWdodCBmb3J3YXJkIGFzIGFuIEFE IHNwb25zb3JlZDxicj4NCmluZGl2aWR1YWwtc3VibWlzc2lvbiB0byBhZGRyZXNzIHRoaXMgY29u c2lkZXJhdGlvbi48YnI+DQo8YnI+DQo8YnI+DQpUaGUgZmlsZSBjYW4gYmUgb2J0YWluZWQgdmlh PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbW0t bmV0Y29uZi10aW1lLWNhcGFiaWxpdHkvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbW0tbmV0Y29uZi10aW1lLWNhcGFiaWxpdHkvPC9hPjxi cj4NCjxicj4NCklFU0cgZGlzY3Vzc2lvbiBjYW4gYmUgdHJhY2tlZCB2aWE8YnI+DQo8YSBocmVm PSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1tbS1uZXRjb25mLXRpbWUt Y2FwYWJpbGl0eS9iYWxsb3QvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtbW0tbmV0Y29uZi10aW1lLWNhcGFiaWxpdHkvYmFsbG90LzwvYT48 YnI+DQo8YnI+DQo8YnI+DQpObyBJUFIgZGVjbGFyYXRpb25zIGhhdmUgYmVlbiBzdWJtaXR0ZWQg ZGlyZWN0bHkgb24gdGhpcyBJLUQuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpOZXRjb25mIG1haWxpbmcg bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpOZXRjb25mQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+TmV0Y29uZkBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmY8L2E+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_f0c6024283f548629d32d2937ed9d2c0ILEXCH01marvellcom_-- From nobody Mon Jun 29 13:39:32 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 084F71B341D for ; Mon, 29 Jun 2015 13:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nodXlRnUbW1a for ; Mon, 29 Jun 2015 13:39:21 -0700 (PDT) Received: from mail-la0-f47.google.com (mail-la0-f47.google.com [209.85.215.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93F3D1B3410 for ; Mon, 29 Jun 2015 13:39:20 -0700 (PDT) Received: by laar3 with SMTP id r3so77890700laa.0 for ; Mon, 29 Jun 2015 13:39:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7pRlk8kLCllzFeRUluBrsxitsj1xsiw62GRElV2MSXI=; b=Ne2YHAd6HEWceSFGKjFv6cB3SR4J5SalrtXH9jAZjZ3LridFFv3lZWdIWmJeNZH90R trzd1sMuIoHYejQl3odCxWq2/SHHRiXofojvge1sPTi4XzOOj31S4Dr6Z9Y3P6oExqj4 U+8axPKGX+KkE6UpM7ygFYrw6jrs60Gbs3fuPFezMxBa6vKKSIIZPLUrJQ/uDoBPveig hffke/U7Pvk7M18YRYbPEh4ddzPFB+0dyKXqkA/g2C1YkUXvljgD1hqRtwYZsvdnjK+C 8F5lQGr+5nenf+msl4zDBnYsMZ7683Lste63DVX5Nz6H99wEc2F6qgW5wswjbfzS5h1G inZA== X-Gm-Message-State: ALoCoQnNhhe62ARkIjNn7mt8e0xub+PoR1J/EQGTtTMbYhuWqexx0jKdyyTc8DqvMD7iiqVsLOJ9 MIME-Version: 1.0 X-Received: by 10.112.164.66 with SMTP id yo2mr16055831lbb.33.1435610359038; Mon, 29 Jun 2015 13:39:19 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Mon, 29 Jun 2015 13:39:18 -0700 (PDT) In-Reply-To: References: <20150629150721.GA2587@elstar.local> <7be9dceb27734ceb94bcb04fdfb3451c@IL-EXCH01.marvell.com> Date: Mon, 29 Jun 2015 13:39:18 -0700 Message-ID: From: Andy Bierman To: Tal Mizrahi Content-Type: multipart/alternative; boundary=001a11c32d5c7c9d680519ae150b Archived-At: Cc: Netconf Subject: Re: [Netconf] [FOWARDING] Last Call: (Time Capability in NETCONF) to Experimental RFC X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 20:39:31 -0000 --001a11c32d5c7c9d680519ae150b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jun 29, 2015 at 1:19 PM, Tal Mizrahi wrote: > Andy, J=C3=BCrgen, > > > > Thanks for the prompt responses. > > > > Quoting Andy: > > > > > Actually, RFC 6241 confirmed-commit has a operation > > >so it can operate the same way (client send cancel to N-1 servers when > > >1 server returns a commit-failed error) > > > > Indeed, but the is applied only after the commit was > already performed, meaning that now the server has to roll back. > > The operation lets you cancel the commit before it has > occurred, allowing all servers to remain with the current configuration. > See the example below. > > > But the normal server doesn't send RPCs until they are needed so it doesn't need to cancel anything before the commit. > Quoting J=C3=BCrgen: > > > > >But if one out of the several commits now fails, how do you recover from > that? And how is the recovery better than NC with confirmed-commit? > > > > Here is an example: > > 1. Client sends scheduled commit to N servers, to be performed at a futur= e > time T. > > 2. One of the servers replies with an rpc-error (meaning it will not be > able to commit). > This is a big problem. The server cannot validate the config at schedule time and say it will be OK at RPC execution time. What if it changes? Even if everything stays locked for a long time (definitely NOT how NETCONF locks are intended to be used) what if the operator changes the hardware in some way (e.g. pull a line-card out) or some hardware fails. All the server can say for ANY is "ok - I scheduled this operation for the desired invocation time" > 3. Client sends to the other N-1 servers, before time > T. None of the servers has committed yet, and they all cancel the schedul= ed > commit. > > > > The advantage is that there is no need to roll back. From a network-wide > perspective, the configuration remains continuously consistent in the thr= ee > steps above. > > > > Quoting Andy: > > > > >This assumes that the load on the system at the time of the RPC > > >execution is somewhat known and stable. I am talking about > > >the elapsed time measurement. > > > > It is not assumed that the time of the RPC execution is known or stable. > The scheduled-time specifies the **start** time of the RPC, and the > execution-time specifies the **completion** time. That means that by > knowing the scheduled-time and execution-time, the client knows that the > difference between these two values is the elapsed time of execution + th= e > scheduling inaccuracy. > > Thus, the parameter allows the client to detect and > monitor fluctuations in the RPC execution time. > > > > Quoting J=C3=BCrgen: > > > > >You seem to be talking about the idea that manager wants to abort the > scheduled commit. > > >This does not exist in NC with confirmed-commit, except that the manager > can simply stop invoking commits if it changes its mind spontaneously. > > > > As Andy noted, NC supports the operation. The main > difference is that the is performed **after** the commit > was applied, as opposed to the , performed **before** > the commit is applied. > But is a generic operation that has nothing to do with . The :time capability does not offer any features related to commit. I could see something like this used in CoMI where the network is slow ther= e may be lots of servers, so a unicast storm of requests and responses all at commit time would be a problem. But constrained devices need simple APIs so none of the extras (like measuring execution time) would be appropriate. > > Cheers, > > Tal. > Andy > > > *From:* Andy Bierman [mailto:andy@yumaworks.com] > *Sent:* Monday, June 29, 2015 10:05 PM > *To:* Tal Mizrahi > *Cc:* Netconf > *Subject:* Re: [Netconf] [FOWARDING] Last Call: > (Time Capability in NETCONF) to > Experimental RFC > > > > > > > > On Mon, Jun 29, 2015 at 11:53 AM, Tal Mizrahi wrote: > > Hi Andy, > > > > Thanks for the comments. > > > > >The draft mixes server measurement of RPC execution time > > >with a "cron" function. The rationale for this grab-bag of > > >time-related functionality is not entirely clear. > > > > One of the most notable use cases is a network-wide commit. The time > capability (using scheduled commits and cancel-schedule) allows a client = to > perform a network-wide commit in N servers, where either all perform the > commit, or none of them does. Such behavior is not currently possible wit= h > confirmed commits (RFC6241); when using confirmed commits, if something > goes wrong, then all the servers roll back to the previous configuration, > which means that there is a (potentially long) transient state where some > servers have changed their configuration and others have not. > > The time capability allows the client to cancel the commit in advance: if > one of the servers indicates it cannot perform the commit (using an error > message), then the client sends a cancellation message to all the servers > before the commit has occurred. All the servers consistently use the same > datastore throughout the procedure. > > > > > > > > Actually, RFC 6241 confirmed-commit has a operation > > so it can operate the same way (client send cancel to N-1 servers when > > 1 server returns a commit-failed error) > > > > > > > > > > The execution-time parameter allows the client to receive feedback about > the actual execution time of the RPC. Based on this feedback the client: > (1) knows how accurately the server scheduled the RPC, and (2) has a > (rough) picture of whether the server=E2=80=99s clock is synchronized to = its own > (see Section 3.3 for further discussion). > > > > > > > > This assumes that the load on the system at the time of the RPC > > execution is somewhat known and stable. I am talking about > > the elapsed time measurement. > > > > The cleint can check the server's time-of-day just by > > reading the current-date-time object. It does not need > > executed-at timestamps to check that the clocks are in synch. > > > > > > > > > > We presented a few use-cases at the IETF meeting in Berlin ( > http://www.ietf.org/proceedings/87/slides/slides-87-netconf-1.pdf), and > the Dallas presentation ( > https://www.ietf.org/proceedings/92/slides/slides-92-netconf-13.pdf), > which was not presented due to lack of time, included the network-wide > commit use case. > > > > Cheers, > > Tal. > > > > > > > > Andy > > > > *From:* Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of *Andy > Bierman > *Sent:* Monday, June 29, 2015 8:27 PM > *To:* Juergen Schoenwaelder; Netconf > *Subject:* Re: [Netconf] [FOWARDING] Last Call: > (Time Capability in NETCONF) to > Experimental RFC > > > > Hi, > > > > > > Is this an AD-sponsored draft? > > > > This draft was "interesting" but not enough to be prioritized ahead > > of other work being done in the NETCONF WG. > > > > The draft mixes server measurement of RPC execution time > > with a "cron" function. The rationale for this grab-bag of > > time-related functionality is not entirely clear. > > > > This work does not have any consensus within the NETCONF WG. > > It does seem a little surprising that it is being published without > > even asking the NETCONF WG for comments. > > > > I don't have any problem with Experimental RFCs as long as it > > is clear this is not a product of the NETCONF WG. > > > > > > > > Andy > > > > > > > > On Mon, Jun 29, 2015 at 8:07 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > Hi, > > just to make sure everybody here has seen this. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > > ---------- Forwarded message ---------- > From: The IESG > To: IETF-Announce > Cc: > Date: Mon, 29 Jun 2015 07:58:22 -0700 > Subject: Last Call: (Time > Capability in NETCONF) to Experimental RFC > > The IESG has received a request from an individual submitter to consider > the following document: > - 'Time Capability in NETCONF' > as Experimental RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2015-07-29. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document defines a capability-based extension to the Network > Configuration Protocol (NETCONF) that allows time-triggered > configuration and management operations. This extension allows > NETCONF clients to invoke configuration updates according to > scheduled times, and allows NETCONF servers to attach timestamps to > the data they send to NETCONF clients. > > > The Network Configuration Protocol (NETCONF) Capability URNs registry > requires a standards action in order to populate the registry. This > document > was taken out of the ISE stream and brought forward as an AD sponsored > individual-submission to address this consideration. > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-mm-netconf-time-capability/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-mm-netconf-time-capability/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > > > --001a11c32d5c7c9d680519ae150b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jun 29, 2015 at 1:19 PM, Tal Mizrahi <talmi@marvell.com>= ; wrote:

Andy, J=C3=BCrgen,=

=C2=A0

Thanks for the prompt res= ponses.

=C2=A0

Quoting Andy:

=C2=A0

> Actually, RFC 6241 confirmed-commit has a <c= ancel-commit> operation

>so it can operate the same way (client send canc= el to N-1 servers when

>1 server returns a commit-failed error)

=C2=A0

Indeed, but the <cance= l-commit> is applied only after the commit was already performed, meanin= g that now the server has to roll back.

The <cancel-schedule&g= t; operation lets you cancel the commit before it has occurred, allowing al= l servers to remain with the current configuration. See the example below.

=C2=A0

<= /div>


But the normal s= erver doesn't send RPCs until they are needed
so it doesn'= ;t need to cancel anything before the commit.

=C2= =A0

<= /u>

Quoting J=C3=BCrgen:

=C2=A0

>But if one out of the several commits now fails,= how do you recover from that? And how is the recovery better than NC with = confirmed-commit?

=C2=A0

Here is an example:

1. Client sends scheduled= commit to N servers, to be performed at a future time T.

2. One of the servers rep= lies with an rpc-error (meaning it will not be able to commit).

<= /div>


This is a big pr= oblem.
The server cannot validate the config at schedule time
and say it will be OK at RPC execution time.=C2=A0 What if it change= s?
Even if everything stays locked for a long time (definitely NO= T how
NETCONF locks are intended to be used) what if the operator=
changes the hardware in some way (e.g. pull a line-card out)
or some hardware fails.

All the server can = say for ANY <rpc> is "ok - I scheduled this operation
= for the desired invocation time"

=C2=A0

<= u>

3. Client sends <cance= l-schedule> to the other N-1 servers, before time T. None of the servers= has committed yet, and they all cancel the scheduled commit.=

=C2=A0

The advantage is that the= re is no need to roll back. From a network-wide perspective, the configurat= ion remains continuously consistent in the three steps above.=

=C2=A0

Quoting Andy:

=C2=A0

>This assumes that the load on the system at the = time of the RPC

>execution is somewhat known and stable. I am tal= king about

>the elapsed time measurement.

=C2=A0

It is not assumed that th= e time of the RPC execution is known or stable. The scheduled-time specifie= s the *start* time of the RPC, and the execution-time specifies the *completion* time. That means that by knowing the sch= eduled-time and execution-time, the client knows that the difference betwee= n these two values is the elapsed time of execution + the scheduling inaccu= racy.

Thus, the <execution-t= ime> parameter allows the client to detect and monitor fluctuations in t= he RPC execution time.

=C2=A0

Quoting J=C3=BCrgen:

=C2=A0

>You seem to be talking about the idea that manag= er wants to abort the scheduled commit.

>This does not exist in NC with confirmed-commit,= except that the manager can simply stop invoking commits if it changes its= mind spontaneously.

=C2=A0

As Andy noted, NC support= s the <cancel-commit> operation. The main difference is that the <= cancel-commit> is performed *after* the commit was applied, as opposed to the <cancel-schedule>, performed *before* the c= ommit is applied.


Bu= t <cancel-schedule> is a generic operation that has nothing to do
with <commit>.=C2=A0 The :time capability does not offer any f= eatures
related to commit.

I could see s= omething like this used in CoMI where the network is slow there
m= ay be lots of servers, so a unicast storm of requests and responses
all at commit time would be a problem.=C2=A0 But constrained devices nee= d
simple APIs so none of the extras (like measuring execution tim= e)
would be appropriate.


=

=

=C2=A0=

Cheers,

Tal.

=


Andy

=C2=A0

=

=C2=A0

From: Andy Bie= rman [mailto:andy@y= umaworks.com]
Sent: Monday, June 29, 2015 10:05 PM
To: Tal Mizrahi
Cc: Netconf
Subject: Re: [Netconf] [FOWARDING] Last Call: <draft-mm-netconf-t= ime-capability-05.txt> (Time Capability in NETCONF) to Experimental RFC<= u>

=C2=A0

=C2=A0

=C2=A0

On Mon, Jun 29, 2015 at 11:53 AM, Tal Mizrahi <talmi@marvell.com&= gt; wrote:

Hi Andy,=

=C2=A0

Thanks for the comments.<= /span>

=C2=A0

>The draft mixes server measurement of RPC execut= ion time

>with a "cron" function.=C2=A0 The rati= onale for this grab-bag of

>time-related functionality is not entirely clear= .

=C2=A0

One of the most notable u= se cases is a network-wide commit. The time capability (using scheduled commits and cancel-schedule) allows a client to perform a network-wide com= mit in N servers, where either all perform the commit, or none of them does= . Such behavior is not currently possible with confirmed commits (RFC6241);= when using confirmed commits, if something goes wrong, then all the servers roll back to the previous confi= guration, which means that there is a (potentially long) transient state wh= ere some servers have changed their configuration and others have not.

The time capability allow= s the client to cancel the commit in advance: if one of the servers indicat= es it cannot perform the commit (using an error message), then the client sen= ds a cancellation message to all the servers before the commit has occurred= . All the servers consistently use the same datastore throughout the proced= ure.

=C2=A0

=C2=A0

=C2=A0

Actually, RFC 6241 confirmed-commit has a <cancel= -commit> operation

so it can operate the same way (client send cancel t= o N-1 servers when

1 server returns a commit-failed error)

=C2=A0

=C2=A0

=C2=A0

=C2=A0

The execution-time parame= ter allows the client to receive feedback about the actual execution time of the RPC. Based on this feedback the client: (1) knows how accurately th= e server scheduled the RPC, and (2) has a (rough) picture of whether the se= rver=E2=80=99s clock is synchronized to its own (see Section 3.3 for furthe= r discussion).

=C2=A0

=C2=A0

=C2=A0

This assumes that the load on the system at the time= of the RPC

execution is somewhat known and stable. I am talking= about

the elapsed time measurement.

=C2=A0

The cleint can check the server's time-of-day ju= st by

reading the current-date-time object.=C2=A0 It does = not need

executed-at timestamps to check that the clocks are = in synch.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

We presented a few use-ca= ses at the IETF meeting in Berlin (http://www.ietf.org= /proceedings/87/slides/slides-87-netconf-1.pdf), and the Dallas presentation (https://www.ietf.org/p= roceedings/92/slides/slides-92-netconf-13.pdf), which was not presented= due to lack of time, included the network-wide commit use case.

=C2=A0

Cheers,<= /u>

Tal.

=C2=A0

=C2=A0

=C2=A0

Andy

=C2=A0

From: Netconf = [mailto:netco= nf-bounces@ietf.org] On Behalf Of Andy Bierman
Sent: Monday, June 29, 2015 8:27 PM
To: Juergen Schoenwaelder; Netconf
Subject: Re: [Netconf] [FOWARDING] Last Call: <draft-mm-netconf-t= ime-capability-05.txt> (Time Capability in NETCONF) to Experimental RFC<= /span>

=C2=A0

Hi,

=C2=A0

=C2=A0

Is this an AD-sponsored draft?

=C2=A0

This draft was "interesting" but not enoug= h to be prioritized ahead

of other work being done in the NETCONF WG.

=C2=A0

The draft mixes server measurement of RPC execution = time

with a "cron" function.=C2=A0 The rational= e for this grab-bag of

time-related functionality is not entirely clear.=

=C2=A0

This work does not have any consensus within the NET= CONF WG.

It does seem a little surprising that it is being pu= blished without

even asking the NETCONF WG for comments.

=C2=A0

I don't have any problem with Experimental RFCs = as long as it

is clear this is not a product of the NETCONF WG.=

=C2=A0

=C2=A0

=C2=A0

Andy

=C2=A0

=C2=A0

=C2=A0

On Mon, Jun 29, 2015 at 8:07 AM, Juergen Schoenwaeld= er <j.schoenwaelder@jacobs-university.de> wrote:

Hi,

just to make sure everybody here has seen this.

/js

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


---------- Forwarded message ----------
From:=C2=A0The IESG <iesg-secretary@ietf.org>
To:=C2=A0IETF-Announce <ietf-announce@ietf.org>
Cc:=C2=A0
Date:=C2=A0Mon, 29 Jun 2015 07:58:22 -0700
Subject:=C2=A0Last Call: <draft-mm-netconf-time-capability-05.txt> (T= ime Capability in NETCONF) to Experimental RFC

The IESG has received a request from an individual submitter to consider the following document:
- 'Time Capability in NETCONF'
=C2=A0 <draft-mm-netconf-time-capability-05.txt> as Experimental RFC<= br>
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailin= g lists by 2015-07-29. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


=C2=A0 =C2=A0This document defines a capability-based extension to the Netw= ork
=C2=A0 =C2=A0Configuration Protocol (NETCONF) that allows time-triggered =C2=A0 =C2=A0configuration and management operations. This extension allows=
=C2=A0 =C2=A0NETCONF clients to invoke configuration updates according to =C2=A0 =C2=A0scheduled times, and allows NETCONF servers to attach timestam= ps to
=C2=A0 =C2=A0the data they send to NETCONF clients.


The Network Configuration Protocol (NETCONF) Capability URNs registry
requires a standards action in order to populate the registry. This documen= t
was taken out of the ISE stream and brought forward as an AD sponsored
individual-submission to address this consideration.


The file can be obtained via
https://datatracker.ietf.org/doc/draft-mm-netconf-tim= e-capability/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-mm-netc= onf-time-capability/ballot/


No IPR declarations have been submitted directly on this I-D.



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

=C2=A0

=C2=A0


--001a11c32d5c7c9d680519ae150b-- From nobody Mon Jun 29 20:34:09 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD481B301B; Mon, 29 Jun 2015 20:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDdCbvFBAsIi; Mon, 29 Jun 2015 20:34:06 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCF721B3019; Mon, 29 Jun 2015 20:33:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUN30265; Tue, 30 Jun 2015 03:33:52 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 30 Jun 2015 04:33:51 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.155]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Tue, 30 Jun 2015 11:33:47 +0800 From: "Anil Kumar S N (VRP Network BL)" To: "lmap@ietf.org" , "ietf@ietf.org" , "netconf@ietf.org" Thread-Topic: [Netconf] Last Call: (Time Capability in NETCONF) to Experimental RFC Thread-Index: AQHQsnwZysM/LtkX402MtFtOvN7Dw53Dr38w//+D5QCAATGdcA== Date: Tue, 30 Jun 2015 03:33:46 +0000 Message-ID: <327562D94EA7BF428CD805F338C31EF06B5AD96A@nkgeml512-mbx.china.huawei.com> References: <20150629145822.7722.8876.idtracker@ietfa.amsl.com> <9904FB1B0159DA42B0B887B7FA8119CA5CA78C61@AZ-FFEXMB04.global.avaya.com> <20150629171546.GA2841@elstar.local> In-Reply-To: <20150629171546.GA2841@elstar.local> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.212.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "moses@ee.technion.ac.il" Subject: Re: [Netconf] Last Call: (Time Capability in NETCONF) to Experimental RFC X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 03:34:07 -0000 I support this draft. Thanks & Regards Anil S N "Be liberal in what you accept, and conservative in what you send" - Jon Po= stel -----Original Message----- From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf Of Th= e IESG Sent: Monday, June 29, 2015 5:58 PM To: IETF-Announce Subject: Last Call: (Time Capabil= ity in NETCONF) to Experimental RFC The IESG has received a request from an individual submitter to consider th= e following document: - 'Time Capability in NETCONF' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final= comments on this action. Please send substantive comments to the ietf@ietf= .org mailing lists by 2015-07-29. Exceptionally, comments may be sent to ie= sg@ietf.org instead. In either case, please retain the beginning of the Sub= ject line to allow automated sorting. Abstract This document defines a capability-based extension to the Network Configuration Protocol (NETCONF) that allows time-triggered configuration and management operations. This extension allows NETCONF clients to invoke configuration updates according to scheduled times, and allows NETCONF servers to attach timestamps to the data they send to NETCONF clients. The Network Configuration Protocol (NETCONF) Capability URNs registry requi= res a standards action in order to populate the registry. This document was= taken out of the ISE stream and brought forward as an AD sponsored individ= ual-submission to address this consideration. The file can be obtained via https://datatracker.ietf.org/doc/draft-mm-netconf-time-capability/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-mm-netconf-time-capability/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Jun 29 22:58:26 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0761B3638 for ; Mon, 29 Jun 2015 22:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ecs7gMnnoMUB for ; Mon, 29 Jun 2015 22:58:24 -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 159E11B3634 for ; Mon, 29 Jun 2015 22:58:24 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9994514A1; Tue, 30 Jun 2015 07:58: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 RvpzvuWuQEiD; Tue, 30 Jun 2015 07:58: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; Tue, 30 Jun 2015 07:58:20 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1664020013; Tue, 30 Jun 2015 07:58:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id nRTSWjAMDSQw; Tue, 30 Jun 2015 07:58:16 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A14EF2002B; Tue, 30 Jun 2015 07:58:20 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 110E834E5351; Tue, 30 Jun 2015 07:58:20 +0200 (CEST) Date: Tue, 30 Jun 2015 07:58:20 +0200 From: Juergen Schoenwaelder To: Tal Mizrahi Message-ID: <20150630055819.GC4083@elstar.local> Mail-Followup-To: Tal Mizrahi , Andy Bierman , Netconf References: <20150629150721.GA2587@elstar.local> <7be9dceb27734ceb94bcb04fdfb3451c@IL-EXCH01.marvell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Netconf Subject: Re: [Netconf] [FOWARDING] Last Call: (Time Capability in NETCONF) to Experimental RFC X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 05:58:25 -0000 On Mon, Jun 29, 2015 at 08:19:28PM +0000, Tal Mizrahi wrote: > Quoting Jürgen: > > >But if one out of the several commits now fails, how do you recover from that? And how is the recovery better than NC with confirmed-commit? > > Here is an example: > 1. Client sends scheduled commit to N servers, to be performed at a future time T. > 2. One of the servers replies with an rpc-error (meaning it will not be able to commit). > 3. Client sends to the other N-1 servers, before time T. None of the servers has committed yet, and they all cancel the scheduled commit. > > The advantage is that there is no need to roll back. From a network-wide perspective, the configuration remains continuously consistent in the three steps above. So what are the reasons you envision that causes one server fails with an rpc-error? If you validated the config and nothing has changed in the meantime, the commit failures should be rare. Is there any evidence that this is a real-world problem? Do you have data how often this problem occurs (after applying validation etc.) in operational networks? /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 Jun 29 23:16:19 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE271B36D2 for ; Mon, 29 Jun 2015 23:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rXXuSsgW0FRq for ; Mon, 29 Jun 2015 23:16:12 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (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 65C791A1A43 for ; Mon, 29 Jun 2015 23:16:12 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id t5U6ENhr015186; Mon, 29 Jun 2015 23:16:11 -0700 Received: from il-exch01.marvell.com (galiil.marvell.com [199.203.130.254]) by mx0b-0016f401.pphosted.com with ESMTP id 1vbggrgk9t-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 29 Jun 2015 23:16:10 -0700 Received: from IL-EXCH01.marvell.com (10.4.102.220) by IL-EXCH01.marvell.com (10.4.102.220) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Tue, 30 Jun 2015 09:16:07 +0300 Received: from IL-EXCH01.marvell.com ([fe80::41:1c9f:8611:3a4a]) by IL-EXCH01.marvell.com ([fe80::41:1c9f:8611:3a4a%20]) with mapi id 15.00.1044.021; Tue, 30 Jun 2015 09:16:07 +0300 From: Tal Mizrahi To: Andy Bierman Thread-Topic: [Netconf] [FOWARDING] Last Call: (Time Capability in NETCONF) to Experimental RFC Thread-Index: AQHQspDXqIId9+7BtECIv6ffNOIXrp3DzWJw///YM4CAAEI+cP//2BcAgADQ+UA= Date: Tue, 30 Jun 2015 06:16:06 +0000 Message-ID: References: <20150629150721.GA2587@elstar.local> <7be9dceb27734ceb94bcb04fdfb3451c@IL-EXCH01.marvell.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [199.203.130.14] Content-Type: multipart/alternative; boundary="_000_c16824608da54be79f6395d8ff65b014ILEXCH01marvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-06-30_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1506180000 definitions=main-1506300115 Archived-At: Cc: Netconf Subject: Re: [Netconf] [FOWARDING] Last Call: (Time Capability in NETCONF) to Experimental RFC X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 06:16:17 -0000 --_000_c16824608da54be79f6395d8ff65b014ILEXCH01marvellcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQo+QWxsIHRoZSBzZXJ2ZXIgY2FuIHNheSBmb3IgQU5ZIDxycGM+IGlzICJvayAtIEkgc2NoZWR1 bGVkIHRoaXMgb3BlcmF0aW9uDQo+Zm9yIHRoZSBkZXNpcmVkIGludm9jYXRpb24gdGltZSINCg0K SG93ZXZlciwgaWYgdGhlIHNlcnZlciBpcyBkb3duLCBhbmQgZG9lcyBub3Qgc2VuZCBiYWNrIGFu IOKAnG9rIOKAkyBJIHNjaGVkdWxlZCB0aGlzIG9wZXJhdGlvbuKAnSwgdGhlIGNsaWVudCBjYW4g c2VuZCBhIGNhbmNlbC1zY2hlZHVsZSB0byB0aGUgb3RoZXIgc2VydmVycy4NCkdvaW5nIGJhY2sg dG8gdGhlIGNvbmZpcm1lZCBjb21taXQsIGlmIG9uZSBvZiB0aGUgc2VydmVycyBpcyBkb3duIGFu ZCB0aGUgY2xpZW50IHNlbmRzIGEgY29tbWl0IHRvIGFsbCB0aGUgc2VydmVycywgdGhlIGNsaWVu dCBjYW4gc2VuZCBhIDxjYW5jZWwtY29tbWl0PiB1cG9uIGRldGVjdGluZyB0aGUgZmFpbHVyZSwg YnV0IHRoaXMsIGFnYWluIHdpbGwgcmVzdWx0IGluIGEgdGVtcG9yYXJ5IHN0YXRlIHdoZXJlIGRp ZmZlcmVudCBzZXJ2ZXJzIHVzZSBkaWZmZXJlbnQgY29uZmlndXJhdGlvbiB2ZXJzaW9ucy4gVXNp bmcgdGhlIDp0aW1lIGNhcGFiaWxpdHksIG9uIHRoZSBvdGhlciBoYW5kLCBwcmV2ZW50cyB0aGlz IHRlbXBvcmFyeSBpbmNvbnNpc3RlbmN5Lg0KDQpUaGFua3MsDQpUYWwuDQoNCkZyb206IEFuZHkg Qmllcm1hbiBbbWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbV0NClNlbnQ6IE1vbmRheSwgSnVuZSAy OSwgMjAxNSAxMTozOSBQTQ0KVG86IFRhbCBNaXpyYWhpDQpDYzogTmV0Y29uZg0KU3ViamVjdDog UmU6IFtOZXRjb25mXSBbRk9XQVJESU5HXSBMYXN0IENhbGw6IDxkcmFmdC1tbS1uZXRjb25mLXRp bWUtY2FwYWJpbGl0eS0wNS50eHQ+IChUaW1lIENhcGFiaWxpdHkgaW4gTkVUQ09ORikgdG8gRXhw ZXJpbWVudGFsIFJGQw0KDQoNCg0KT24gTW9uLCBKdW4gMjksIDIwMTUgYXQgMToxOSBQTSwgVGFs IE1penJhaGkgPHRhbG1pQG1hcnZlbGwuY29tPG1haWx0bzp0YWxtaUBtYXJ2ZWxsLmNvbT4+IHdy b3RlOg0KQW5keSwgSsO8cmdlbiwNCg0KVGhhbmtzIGZvciB0aGUgcHJvbXB0IHJlc3BvbnNlcy4N Cg0KUXVvdGluZyBBbmR5Og0KDQo+IEFjdHVhbGx5LCBSRkMgNjI0MSBjb25maXJtZWQtY29tbWl0 IGhhcyBhIDxjYW5jZWwtY29tbWl0PiBvcGVyYXRpb24NCj5zbyBpdCBjYW4gb3BlcmF0ZSB0aGUg c2FtZSB3YXkgKGNsaWVudCBzZW5kIGNhbmNlbCB0byBOLTEgc2VydmVycyB3aGVuDQo+MSBzZXJ2 ZXIgcmV0dXJucyBhIGNvbW1pdC1mYWlsZWQgZXJyb3IpDQoNCkluZGVlZCwgYnV0IHRoZSA8Y2Fu Y2VsLWNvbW1pdD4gaXMgYXBwbGllZCBvbmx5IGFmdGVyIHRoZSBjb21taXQgd2FzIGFscmVhZHkg cGVyZm9ybWVkLCBtZWFuaW5nIHRoYXQgbm93IHRoZSBzZXJ2ZXIgaGFzIHRvIHJvbGwgYmFjay4N ClRoZSA8Y2FuY2VsLXNjaGVkdWxlPiBvcGVyYXRpb24gbGV0cyB5b3UgY2FuY2VsIHRoZSBjb21t aXQgYmVmb3JlIGl0IGhhcyBvY2N1cnJlZCwgYWxsb3dpbmcgYWxsIHNlcnZlcnMgdG8gcmVtYWlu IHdpdGggdGhlIGN1cnJlbnQgY29uZmlndXJhdGlvbi4gU2VlIHRoZSBleGFtcGxlIGJlbG93Lg0K DQoNCg0KQnV0IHRoZSBub3JtYWwgc2VydmVyIGRvZXNuJ3Qgc2VuZCBSUENzIHVudGlsIHRoZXkg YXJlIG5lZWRlZA0Kc28gaXQgZG9lc24ndCBuZWVkIHRvIGNhbmNlbCBhbnl0aGluZyBiZWZvcmUg dGhlIGNvbW1pdC4NCg0KDQpRdW90aW5nIErDvHJnZW46DQoNCj5CdXQgaWYgb25lIG91dCBvZiB0 aGUgc2V2ZXJhbCBjb21taXRzIG5vdyBmYWlscywgaG93IGRvIHlvdSByZWNvdmVyIGZyb20gdGhh dD8gQW5kIGhvdyBpcyB0aGUgcmVjb3ZlcnkgYmV0dGVyIHRoYW4gTkMgd2l0aCBjb25maXJtZWQt Y29tbWl0Pw0KDQpIZXJlIGlzIGFuIGV4YW1wbGU6DQoxLiBDbGllbnQgc2VuZHMgc2NoZWR1bGVk IGNvbW1pdCB0byBOIHNlcnZlcnMsIHRvIGJlIHBlcmZvcm1lZCBhdCBhIGZ1dHVyZSB0aW1lIFQu DQoyLiBPbmUgb2YgdGhlIHNlcnZlcnMgcmVwbGllcyB3aXRoIGFuIHJwYy1lcnJvciAobWVhbmlu ZyBpdCB3aWxsIG5vdCBiZSBhYmxlIHRvIGNvbW1pdCkuDQoNCg0KVGhpcyBpcyBhIGJpZyBwcm9i bGVtLg0KVGhlIHNlcnZlciBjYW5ub3QgdmFsaWRhdGUgdGhlIGNvbmZpZyBhdCBzY2hlZHVsZSB0 aW1lDQphbmQgc2F5IGl0IHdpbGwgYmUgT0sgYXQgUlBDIGV4ZWN1dGlvbiB0aW1lLiAgV2hhdCBp ZiBpdCBjaGFuZ2VzPw0KRXZlbiBpZiBldmVyeXRoaW5nIHN0YXlzIGxvY2tlZCBmb3IgYSBsb25n IHRpbWUgKGRlZmluaXRlbHkgTk9UIGhvdw0KTkVUQ09ORiBsb2NrcyBhcmUgaW50ZW5kZWQgdG8g YmUgdXNlZCkgd2hhdCBpZiB0aGUgb3BlcmF0b3INCmNoYW5nZXMgdGhlIGhhcmR3YXJlIGluIHNv bWUgd2F5IChlLmcuIHB1bGwgYSBsaW5lLWNhcmQgb3V0KQ0Kb3Igc29tZSBoYXJkd2FyZSBmYWls cy4NCg0KQWxsIHRoZSBzZXJ2ZXIgY2FuIHNheSBmb3IgQU5ZIDxycGM+IGlzICJvayAtIEkgc2No ZWR1bGVkIHRoaXMgb3BlcmF0aW9uDQpmb3IgdGhlIGRlc2lyZWQgaW52b2NhdGlvbiB0aW1lIg0K DQoNCjMuIENsaWVudCBzZW5kcyA8Y2FuY2VsLXNjaGVkdWxlPiB0byB0aGUgb3RoZXIgTi0xIHNl cnZlcnMsIGJlZm9yZSB0aW1lIFQuIE5vbmUgb2YgdGhlIHNlcnZlcnMgaGFzIGNvbW1pdHRlZCB5 ZXQsIGFuZCB0aGV5IGFsbCBjYW5jZWwgdGhlIHNjaGVkdWxlZCBjb21taXQuDQoNClRoZSBhZHZh bnRhZ2UgaXMgdGhhdCB0aGVyZSBpcyBubyBuZWVkIHRvIHJvbGwgYmFjay4gRnJvbSBhIG5ldHdv cmstd2lkZSBwZXJzcGVjdGl2ZSwgdGhlIGNvbmZpZ3VyYXRpb24gcmVtYWlucyBjb250aW51b3Vz bHkgY29uc2lzdGVudCBpbiB0aGUgdGhyZWUgc3RlcHMgYWJvdmUuDQoNClF1b3RpbmcgQW5keToN Cg0KPlRoaXMgYXNzdW1lcyB0aGF0IHRoZSBsb2FkIG9uIHRoZSBzeXN0ZW0gYXQgdGhlIHRpbWUg b2YgdGhlIFJQQw0KPmV4ZWN1dGlvbiBpcyBzb21ld2hhdCBrbm93biBhbmQgc3RhYmxlLiBJIGFt IHRhbGtpbmcgYWJvdXQNCj50aGUgZWxhcHNlZCB0aW1lIG1lYXN1cmVtZW50Lg0KDQpJdCBpcyBu b3QgYXNzdW1lZCB0aGF0IHRoZSB0aW1lIG9mIHRoZSBSUEMgZXhlY3V0aW9uIGlzIGtub3duIG9y IHN0YWJsZS4gVGhlIHNjaGVkdWxlZC10aW1lIHNwZWNpZmllcyB0aGUgKnN0YXJ0KiB0aW1lIG9m IHRoZSBSUEMsIGFuZCB0aGUgZXhlY3V0aW9uLXRpbWUgc3BlY2lmaWVzIHRoZSAqY29tcGxldGlv biogdGltZS4gVGhhdCBtZWFucyB0aGF0IGJ5IGtub3dpbmcgdGhlIHNjaGVkdWxlZC10aW1lIGFu ZCBleGVjdXRpb24tdGltZSwgdGhlIGNsaWVudCBrbm93cyB0aGF0IHRoZSBkaWZmZXJlbmNlIGJl dHdlZW4gdGhlc2UgdHdvIHZhbHVlcyBpcyB0aGUgZWxhcHNlZCB0aW1lIG9mIGV4ZWN1dGlvbiAr IHRoZSBzY2hlZHVsaW5nIGluYWNjdXJhY3kuDQpUaHVzLCB0aGUgPGV4ZWN1dGlvbi10aW1lPiBw YXJhbWV0ZXIgYWxsb3dzIHRoZSBjbGllbnQgdG8gZGV0ZWN0IGFuZCBtb25pdG9yIGZsdWN0dWF0 aW9ucyBpbiB0aGUgUlBDIGV4ZWN1dGlvbiB0aW1lLg0KDQpRdW90aW5nIErDvHJnZW46DQoNCj5Z b3Ugc2VlbSB0byBiZSB0YWxraW5nIGFib3V0IHRoZSBpZGVhIHRoYXQgbWFuYWdlciB3YW50cyB0 byBhYm9ydCB0aGUgc2NoZWR1bGVkIGNvbW1pdC4NCj5UaGlzIGRvZXMgbm90IGV4aXN0IGluIE5D IHdpdGggY29uZmlybWVkLWNvbW1pdCwgZXhjZXB0IHRoYXQgdGhlIG1hbmFnZXIgY2FuIHNpbXBs eSBzdG9wIGludm9raW5nIGNvbW1pdHMgaWYgaXQgY2hhbmdlcyBpdHMgbWluZCBzcG9udGFuZW91 c2x5Lg0KDQpBcyBBbmR5IG5vdGVkLCBOQyBzdXBwb3J0cyB0aGUgPGNhbmNlbC1jb21taXQ+IG9w ZXJhdGlvbi4gVGhlIG1haW4gZGlmZmVyZW5jZSBpcyB0aGF0IHRoZSA8Y2FuY2VsLWNvbW1pdD4g aXMgcGVyZm9ybWVkICphZnRlciogdGhlIGNvbW1pdCB3YXMgYXBwbGllZCwgYXMgb3Bwb3NlZCB0 byB0aGUgPGNhbmNlbC1zY2hlZHVsZT4sIHBlcmZvcm1lZCAqYmVmb3JlKiB0aGUgY29tbWl0IGlz IGFwcGxpZWQuDQoNCkJ1dCA8Y2FuY2VsLXNjaGVkdWxlPiBpcyBhIGdlbmVyaWMgb3BlcmF0aW9u IHRoYXQgaGFzIG5vdGhpbmcgdG8gZG8NCndpdGggPGNvbW1pdD4uICBUaGUgOnRpbWUgY2FwYWJp bGl0eSBkb2VzIG5vdCBvZmZlciBhbnkgZmVhdHVyZXMNCnJlbGF0ZWQgdG8gY29tbWl0Lg0KDQpJ IGNvdWxkIHNlZSBzb21ldGhpbmcgbGlrZSB0aGlzIHVzZWQgaW4gQ29NSSB3aGVyZSB0aGUgbmV0 d29yayBpcyBzbG93IHRoZXJlDQptYXkgYmUgbG90cyBvZiBzZXJ2ZXJzLCBzbyBhIHVuaWNhc3Qg c3Rvcm0gb2YgcmVxdWVzdHMgYW5kIHJlc3BvbnNlcw0KYWxsIGF0IGNvbW1pdCB0aW1lIHdvdWxk IGJlIGEgcHJvYmxlbS4gIEJ1dCBjb25zdHJhaW5lZCBkZXZpY2VzIG5lZWQNCnNpbXBsZSBBUElz IHNvIG5vbmUgb2YgdGhlIGV4dHJhcyAobGlrZSBtZWFzdXJpbmcgZXhlY3V0aW9uIHRpbWUpDQp3 b3VsZCBiZSBhcHByb3ByaWF0ZS4NCg0KDQoNCg0KQ2hlZXJzLA0KVGFsLg0KDQoNCkFuZHkNCg0K DQoNCkZyb206IEFuZHkgQmllcm1hbiBbbWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbTxtYWlsdG86 YW5keUB5dW1hd29ya3MuY29tPl0NClNlbnQ6IE1vbmRheSwgSnVuZSAyOSwgMjAxNSAxMDowNSBQ TQ0KVG86IFRhbCBNaXpyYWhpDQpDYzogTmV0Y29uZg0KU3ViamVjdDogUmU6IFtOZXRjb25mXSBb Rk9XQVJESU5HXSBMYXN0IENhbGw6IDxkcmFmdC1tbS1uZXRjb25mLXRpbWUtY2FwYWJpbGl0eS0w NS50eHQ+IChUaW1lIENhcGFiaWxpdHkgaW4gTkVUQ09ORikgdG8gRXhwZXJpbWVudGFsIFJGQw0K DQoNCg0KT24gTW9uLCBKdW4gMjksIDIwMTUgYXQgMTE6NTMgQU0sIFRhbCBNaXpyYWhpIDx0YWxt aUBtYXJ2ZWxsLmNvbTxtYWlsdG86dGFsbWlAbWFydmVsbC5jb20+PiB3cm90ZToNCkhpIEFuZHks DQoNClRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzLg0KDQo+VGhlIGRyYWZ0IG1peGVzIHNlcnZlciBt ZWFzdXJlbWVudCBvZiBSUEMgZXhlY3V0aW9uIHRpbWUNCj53aXRoIGEgImNyb24iIGZ1bmN0aW9u LiAgVGhlIHJhdGlvbmFsZSBmb3IgdGhpcyBncmFiLWJhZyBvZg0KPnRpbWUtcmVsYXRlZCBmdW5j dGlvbmFsaXR5IGlzIG5vdCBlbnRpcmVseSBjbGVhci4NCg0KT25lIG9mIHRoZSBtb3N0IG5vdGFi bGUgdXNlIGNhc2VzIGlzIGEgbmV0d29yay13aWRlIGNvbW1pdC4gVGhlIHRpbWUgY2FwYWJpbGl0 eSAodXNpbmcgc2NoZWR1bGVkIGNvbW1pdHMgYW5kIGNhbmNlbC1zY2hlZHVsZSkgYWxsb3dzIGEg Y2xpZW50IHRvIHBlcmZvcm0gYSBuZXR3b3JrLXdpZGUgY29tbWl0IGluIE4gc2VydmVycywgd2hl cmUgZWl0aGVyIGFsbCBwZXJmb3JtIHRoZSBjb21taXQsIG9yIG5vbmUgb2YgdGhlbSBkb2VzLiBT dWNoIGJlaGF2aW9yIGlzIG5vdCBjdXJyZW50bHkgcG9zc2libGUgd2l0aCBjb25maXJtZWQgY29t bWl0cyAoUkZDNjI0MSk7IHdoZW4gdXNpbmcgY29uZmlybWVkIGNvbW1pdHMsIGlmIHNvbWV0aGlu ZyBnb2VzIHdyb25nLCB0aGVuIGFsbCB0aGUgc2VydmVycyByb2xsIGJhY2sgdG8gdGhlIHByZXZp b3VzIGNvbmZpZ3VyYXRpb24sIHdoaWNoIG1lYW5zIHRoYXQgdGhlcmUgaXMgYSAocG90ZW50aWFs bHkgbG9uZykgdHJhbnNpZW50IHN0YXRlIHdoZXJlIHNvbWUgc2VydmVycyBoYXZlIGNoYW5nZWQg dGhlaXIgY29uZmlndXJhdGlvbiBhbmQgb3RoZXJzIGhhdmUgbm90Lg0KVGhlIHRpbWUgY2FwYWJp bGl0eSBhbGxvd3MgdGhlIGNsaWVudCB0byBjYW5jZWwgdGhlIGNvbW1pdCBpbiBhZHZhbmNlOiBp ZiBvbmUgb2YgdGhlIHNlcnZlcnMgaW5kaWNhdGVzIGl0IGNhbm5vdCBwZXJmb3JtIHRoZSBjb21t aXQgKHVzaW5nIGFuIGVycm9yIG1lc3NhZ2UpLCB0aGVuIHRoZSBjbGllbnQgc2VuZHMgYSBjYW5j ZWxsYXRpb24gbWVzc2FnZSB0byBhbGwgdGhlIHNlcnZlcnMgYmVmb3JlIHRoZSBjb21taXQgaGFz IG9jY3VycmVkLiBBbGwgdGhlIHNlcnZlcnMgY29uc2lzdGVudGx5IHVzZSB0aGUgc2FtZSBkYXRh c3RvcmUgdGhyb3VnaG91dCB0aGUgcHJvY2VkdXJlLg0KDQoNCg0KQWN0dWFsbHksIFJGQyA2MjQx IGNvbmZpcm1lZC1jb21taXQgaGFzIGEgPGNhbmNlbC1jb21taXQ+IG9wZXJhdGlvbg0Kc28gaXQg Y2FuIG9wZXJhdGUgdGhlIHNhbWUgd2F5IChjbGllbnQgc2VuZCBjYW5jZWwgdG8gTi0xIHNlcnZl cnMgd2hlbg0KMSBzZXJ2ZXIgcmV0dXJucyBhIGNvbW1pdC1mYWlsZWQgZXJyb3IpDQoNCg0KDQoN ClRoZSBleGVjdXRpb24tdGltZSBwYXJhbWV0ZXIgYWxsb3dzIHRoZSBjbGllbnQgdG8gcmVjZWl2 ZSBmZWVkYmFjayBhYm91dCB0aGUgYWN0dWFsIGV4ZWN1dGlvbiB0aW1lIG9mIHRoZSBSUEMuIEJh c2VkIG9uIHRoaXMgZmVlZGJhY2sgdGhlIGNsaWVudDogKDEpIGtub3dzIGhvdyBhY2N1cmF0ZWx5 IHRoZSBzZXJ2ZXIgc2NoZWR1bGVkIHRoZSBSUEMsIGFuZCAoMikgaGFzIGEgKHJvdWdoKSBwaWN0 dXJlIG9mIHdoZXRoZXIgdGhlIHNlcnZlcuKAmXMgY2xvY2sgaXMgc3luY2hyb25pemVkIHRvIGl0 cyBvd24gKHNlZSBTZWN0aW9uIDMuMyBmb3IgZnVydGhlciBkaXNjdXNzaW9uKS4NCg0KDQoNClRo aXMgYXNzdW1lcyB0aGF0IHRoZSBsb2FkIG9uIHRoZSBzeXN0ZW0gYXQgdGhlIHRpbWUgb2YgdGhl IFJQQw0KZXhlY3V0aW9uIGlzIHNvbWV3aGF0IGtub3duIGFuZCBzdGFibGUuIEkgYW0gdGFsa2lu ZyBhYm91dA0KdGhlIGVsYXBzZWQgdGltZSBtZWFzdXJlbWVudC4NCg0KVGhlIGNsZWludCBjYW4g Y2hlY2sgdGhlIHNlcnZlcidzIHRpbWUtb2YtZGF5IGp1c3QgYnkNCnJlYWRpbmcgdGhlIGN1cnJl bnQtZGF0ZS10aW1lIG9iamVjdC4gIEl0IGRvZXMgbm90IG5lZWQNCmV4ZWN1dGVkLWF0IHRpbWVz dGFtcHMgdG8gY2hlY2sgdGhhdCB0aGUgY2xvY2tzIGFyZSBpbiBzeW5jaC4NCg0KDQoNCg0KV2Ug cHJlc2VudGVkIGEgZmV3IHVzZS1jYXNlcyBhdCB0aGUgSUVURiBtZWV0aW5nIGluIEJlcmxpbiAo aHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84Ny9zbGlkZXMvc2xpZGVzLTg3LW5ldGNv bmYtMS5wZGYpLCBhbmQgdGhlIERhbGxhcyBwcmVzZW50YXRpb24gKGh0dHBzOi8vd3d3LmlldGYu b3JnL3Byb2NlZWRpbmdzLzkyL3NsaWRlcy9zbGlkZXMtOTItbmV0Y29uZi0xMy5wZGYpLCB3aGlj aCB3YXMgbm90IHByZXNlbnRlZCBkdWUgdG8gbGFjayBvZiB0aW1lLCBpbmNsdWRlZCB0aGUgbmV0 d29yay13aWRlIGNvbW1pdCB1c2UgY2FzZS4NCg0KQ2hlZXJzLA0KVGFsLg0KDQoNCg0KQW5keQ0K DQpGcm9tOiBOZXRjb25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpu ZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgQW5keSBCaWVybWFuDQpTZW50 OiBNb25kYXksIEp1bmUgMjksIDIwMTUgODoyNyBQTQ0KVG86IEp1ZXJnZW4gU2Nob2Vud2FlbGRl cjsgTmV0Y29uZg0KU3ViamVjdDogUmU6IFtOZXRjb25mXSBbRk9XQVJESU5HXSBMYXN0IENhbGw6 IDxkcmFmdC1tbS1uZXRjb25mLXRpbWUtY2FwYWJpbGl0eS0wNS50eHQ+IChUaW1lIENhcGFiaWxp dHkgaW4gTkVUQ09ORikgdG8gRXhwZXJpbWVudGFsIFJGQw0KDQpIaSwNCg0KDQpJcyB0aGlzIGFu IEFELXNwb25zb3JlZCBkcmFmdD8NCg0KVGhpcyBkcmFmdCB3YXMgImludGVyZXN0aW5nIiBidXQg bm90IGVub3VnaCB0byBiZSBwcmlvcml0aXplZCBhaGVhZA0Kb2Ygb3RoZXIgd29yayBiZWluZyBk b25lIGluIHRoZSBORVRDT05GIFdHLg0KDQpUaGUgZHJhZnQgbWl4ZXMgc2VydmVyIG1lYXN1cmVt ZW50IG9mIFJQQyBleGVjdXRpb24gdGltZQ0Kd2l0aCBhICJjcm9uIiBmdW5jdGlvbi4gIFRoZSBy YXRpb25hbGUgZm9yIHRoaXMgZ3JhYi1iYWcgb2YNCnRpbWUtcmVsYXRlZCBmdW5jdGlvbmFsaXR5 IGlzIG5vdCBlbnRpcmVseSBjbGVhci4NCg0KVGhpcyB3b3JrIGRvZXMgbm90IGhhdmUgYW55IGNv bnNlbnN1cyB3aXRoaW4gdGhlIE5FVENPTkYgV0cuDQpJdCBkb2VzIHNlZW0gYSBsaXR0bGUgc3Vy cHJpc2luZyB0aGF0IGl0IGlzIGJlaW5nIHB1Ymxpc2hlZCB3aXRob3V0DQpldmVuIGFza2luZyB0 aGUgTkVUQ09ORiBXRyBmb3IgY29tbWVudHMuDQoNCkkgZG9uJ3QgaGF2ZSBhbnkgcHJvYmxlbSB3 aXRoIEV4cGVyaW1lbnRhbCBSRkNzIGFzIGxvbmcgYXMgaXQNCmlzIGNsZWFyIHRoaXMgaXMgbm90 IGEgcHJvZHVjdCBvZiB0aGUgTkVUQ09ORiBXRy4NCg0KDQoNCkFuZHkNCg0KDQoNCk9uIE1vbiwg SnVuIDI5LCAyMDE1IGF0IDg6MDcgQU0sIEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53 YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPG1haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2Jz LXVuaXZlcnNpdHkuZGU+PiB3cm90ZToNCkhpLA0KDQpqdXN0IHRvIG1ha2Ugc3VyZSBldmVyeWJv ZHkgaGVyZSBoYXMgc2VlbiB0aGlzLg0KDQovanMNCg0KLS0NCkp1ZXJnZW4gU2Nob2Vud2FlbGRl ciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQpQaG9uZTogKzQ5IDQy MSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55 DQpGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwOi8vd3d3LmphY29icy11bml2 ZXJzaXR5LmRlLz4NCg0KDQotLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLS0N CkZyb206IFRoZSBJRVNHIDxpZXNnLXNlY3JldGFyeUBpZXRmLm9yZzxtYWlsdG86aWVzZy1zZWNy ZXRhcnlAaWV0Zi5vcmc+Pg0KVG86IElFVEYtQW5ub3VuY2UgPGlldGYtYW5ub3VuY2VAaWV0Zi5v cmc8bWFpbHRvOmlldGYtYW5ub3VuY2VAaWV0Zi5vcmc+Pg0KQ2M6DQpEYXRlOiBNb24sIDI5IEp1 biAyMDE1IDA3OjU4OjIyIC0wNzAwDQpTdWJqZWN0OiBMYXN0IENhbGw6IDxkcmFmdC1tbS1uZXRj b25mLXRpbWUtY2FwYWJpbGl0eS0wNS50eHQ+IChUaW1lIENhcGFiaWxpdHkgaW4gTkVUQ09ORikg dG8gRXhwZXJpbWVudGFsIFJGQw0KDQpUaGUgSUVTRyBoYXMgcmVjZWl2ZWQgYSByZXF1ZXN0IGZy b20gYW4gaW5kaXZpZHVhbCBzdWJtaXR0ZXIgdG8gY29uc2lkZXINCnRoZSBmb2xsb3dpbmcgZG9j dW1lbnQ6DQotICdUaW1lIENhcGFiaWxpdHkgaW4gTkVUQ09ORicNCiAgPGRyYWZ0LW1tLW5ldGNv bmYtdGltZS1jYXBhYmlsaXR5LTA1LnR4dD4gYXMgRXhwZXJpbWVudGFsIFJGQw0KDQpUaGUgSUVT RyBwbGFucyB0byBtYWtlIGEgZGVjaXNpb24gaW4gdGhlIG5leHQgZmV3IHdlZWtzLCBhbmQgc29s aWNpdHMNCmZpbmFsIGNvbW1lbnRzIG9uIHRoaXMgYWN0aW9uLiBQbGVhc2Ugc2VuZCBzdWJzdGFu dGl2ZSBjb21tZW50cyB0byB0aGUNCmlldGZAaWV0Zi5vcmc8bWFpbHRvOmlldGZAaWV0Zi5vcmc+ IG1haWxpbmcgbGlzdHMgYnkgMjAxNS0wNy0yOS4gRXhjZXB0aW9uYWxseSwgY29tbWVudHMgbWF5 IGJlDQpzZW50IHRvIGllc2dAaWV0Zi5vcmc8bWFpbHRvOmllc2dAaWV0Zi5vcmc+IGluc3RlYWQu IEluIGVpdGhlciBjYXNlLCBwbGVhc2UgcmV0YWluIHRoZQ0KYmVnaW5uaW5nIG9mIHRoZSBTdWJq ZWN0IGxpbmUgdG8gYWxsb3cgYXV0b21hdGVkIHNvcnRpbmcuDQoNCkFic3RyYWN0DQoNCg0KICAg VGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgY2FwYWJpbGl0eS1iYXNlZCBleHRlbnNpb24gdG8gdGhl IE5ldHdvcmsNCiAgIENvbmZpZ3VyYXRpb24gUHJvdG9jb2wgKE5FVENPTkYpIHRoYXQgYWxsb3dz IHRpbWUtdHJpZ2dlcmVkDQogICBjb25maWd1cmF0aW9uIGFuZCBtYW5hZ2VtZW50IG9wZXJhdGlv bnMuIFRoaXMgZXh0ZW5zaW9uIGFsbG93cw0KICAgTkVUQ09ORiBjbGllbnRzIHRvIGludm9rZSBj b25maWd1cmF0aW9uIHVwZGF0ZXMgYWNjb3JkaW5nIHRvDQogICBzY2hlZHVsZWQgdGltZXMsIGFu ZCBhbGxvd3MgTkVUQ09ORiBzZXJ2ZXJzIHRvIGF0dGFjaCB0aW1lc3RhbXBzIHRvDQogICB0aGUg ZGF0YSB0aGV5IHNlbmQgdG8gTkVUQ09ORiBjbGllbnRzLg0KDQoNClRoZSBOZXR3b3JrIENvbmZp Z3VyYXRpb24gUHJvdG9jb2wgKE5FVENPTkYpIENhcGFiaWxpdHkgVVJOcyByZWdpc3RyeQ0KcmVx dWlyZXMgYSBzdGFuZGFyZHMgYWN0aW9uIGluIG9yZGVyIHRvIHBvcHVsYXRlIHRoZSByZWdpc3Ry eS4gVGhpcyBkb2N1bWVudA0Kd2FzIHRha2VuIG91dCBvZiB0aGUgSVNFIHN0cmVhbSBhbmQgYnJv dWdodCBmb3J3YXJkIGFzIGFuIEFEIHNwb25zb3JlZA0KaW5kaXZpZHVhbC1zdWJtaXNzaW9uIHRv IGFkZHJlc3MgdGhpcyBjb25zaWRlcmF0aW9uLg0KDQoNClRoZSBmaWxlIGNhbiBiZSBvYnRhaW5l ZCB2aWENCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1tLW5ldGNvbmYt dGltZS1jYXBhYmlsaXR5Lw0KDQpJRVNHIGRpc2N1c3Npb24gY2FuIGJlIHRyYWNrZWQgdmlhDQpo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1tbS1uZXRjb25mLXRpbWUtY2Fw YWJpbGl0eS9iYWxsb3QvDQoNCg0KTm8gSVBSIGRlY2xhcmF0aW9ucyBoYXZlIGJlZW4gc3VibWl0 dGVkIGRpcmVjdGx5IG9uIHRoaXMgSS1ELg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCk5ldGNvbmYgbWFpbGluZyBsaXN0DQpOZXRjb25mQGll dGYub3JnPG1haWx0bzpOZXRjb25mQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9uZXRjb25mDQoNCg0KDQo= --_000_c16824608da54be79f6395d8ff65b014ILEXCH01marvellcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFu LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMjVpbiAxLjBpbiAxLjI1aW47fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mZ3Q7QWxsIHRoZSBzZXJ2ZXIgY2FuIHNheSBmb3IgQU5ZICZsdDtycGMmZ3Q7IGlz ICZxdW90O29rIC0gSSBzY2hlZHVsZWQgdGhpcyBvcGVyYXRpb248bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZndDtmb3IgdGhlIGRlc2lyZWQgaW52b2NhdGlvbiB0aW1lJnF1 b3Q7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhv d2V2ZXIsIGlmIHRoZSBzZXJ2ZXIgaXMgZG93biwgYW5kIGRvZXMgbm90IHNlbmQgYmFjayBhbiDi gJxvayDigJMgSSBzY2hlZHVsZWQgdGhpcyBvcGVyYXRpb27igJ0sIHRoZSBjbGllbnQgY2FuIHNl bmQgYSBjYW5jZWwtc2NoZWR1bGUgdG8gdGhlIG90aGVyIHNlcnZlcnMuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5Hb2luZyBiYWNrIHRvIHRoZSBjb25maXJtZWQgY29tbWl0LCBpZiBvbmUg b2YgdGhlIHNlcnZlcnMgaXMgZG93biBhbmQgdGhlIGNsaWVudCBzZW5kcyBhIGNvbW1pdCB0byBh bGwgdGhlIHNlcnZlcnMsIHRoZSBjbGllbnQgY2FuIHNlbmQgYSAmbHQ7Y2FuY2VsLWNvbW1pdCZn dDsgdXBvbg0KIGRldGVjdGluZyB0aGUgZmFpbHVyZSwgYnV0IHRoaXMsIGFnYWluIHdpbGwgcmVz dWx0IGluIGEgdGVtcG9yYXJ5IHN0YXRlIHdoZXJlIGRpZmZlcmVudCBzZXJ2ZXJzIHVzZSBkaWZm ZXJlbnQgY29uZmlndXJhdGlvbiB2ZXJzaW9ucy4gVXNpbmcgdGhlIDp0aW1lIGNhcGFiaWxpdHks IG9uIHRoZSBvdGhlciBoYW5kLCBwcmV2ZW50cyB0aGlzIHRlbXBvcmFyeSBpbmNvbnNpc3RlbmN5 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UYWwuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBBbmR5IEJpZXJtYW4gW21haWx0bzph bmR5QHl1bWF3b3Jrcy5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBKdW5lIDI5LCAy MDE1IDExOjM5IFBNPGJyPg0KPGI+VG86PC9iPiBUYWwgTWl6cmFoaTxicj4NCjxiPkNjOjwvYj4g TmV0Y29uZjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW05ldGNvbmZdIFtGT1dBUkRJTkddIExh c3QgQ2FsbDogJmx0O2RyYWZ0LW1tLW5ldGNvbmYtdGltZS1jYXBhYmlsaXR5LTA1LnR4dCZndDsg KFRpbWUgQ2FwYWJpbGl0eSBpbiBORVRDT05GKSB0byBFeHBlcmltZW50YWwgUkZDPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBKdW4gMjksIDIwMTUgYXQgMToxOSBQTSwgVGFsIE1p enJhaGkgJmx0OzxhIGhyZWY9Im1haWx0bzp0YWxtaUBtYXJ2ZWxsLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPnRhbG1pQG1hcnZlbGwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkFuZHksIErDvHJnZW4sPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIGZv ciB0aGUgcHJvbXB0IHJlc3BvbnNlcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5RdW90aW5nIEFuZHk6PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jmd0OyBBY3R1YWxseSwgUkZDIDYyNDEgY29u ZmlybWVkLWNvbW1pdCBoYXMgYSAmbHQ7Y2FuY2VsLWNvbW1pdCZndDsgb3BlcmF0aW9uPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZndDtzbyBpdCBjYW4gb3BlcmF0ZSB0 aGUgc2FtZSB3YXkgKGNsaWVudCBzZW5kIGNhbmNlbCB0byBOLTEgc2VydmVycyB3aGVuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZndDsxIHNlcnZlciByZXR1cm5zIGEg Y29tbWl0LWZhaWxlZCBlcnJvcik8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkluZGVlZCwgYnV0IHRoZSAmbHQ7Y2FuY2VsLWNv bW1pdCZndDsgaXMgYXBwbGllZCBvbmx5IGFmdGVyIHRoZSBjb21taXQgd2FzIGFscmVhZHkgcGVy Zm9ybWVkLCBtZWFuaW5nIHRoYXQNCiBub3cgdGhlIHNlcnZlciBoYXMgdG8gcm9sbCBiYWNrLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSAmbHQ7Y2FuY2VsLXNjaGVkdWxlJmd0 OyBvcGVyYXRpb24gbGV0cyB5b3UgY2FuY2VsIHRoZSBjb21taXQgYmVmb3JlIGl0IGhhcyBvY2N1 cnJlZCwgYWxsb3dpbmcgYWxsIHNlcnZlcnMNCiB0byByZW1haW4gd2l0aCB0aGUgY3VycmVudCBj b25maWd1cmF0aW9uLiBTZWUgdGhlIGV4YW1wbGUgYmVsb3cuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnV0IHRoZSBub3JtYWwgc2VydmVyIGRv ZXNuJ3Qgc2VuZCBSUENzIHVudGlsIHRoZXkgYXJlIG5lZWRlZDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+c28gaXQgZG9lc24ndCBuZWVkIHRvIGNh bmNlbCBhbnl0aGluZyBiZWZvcmUgdGhlIGNvbW1pdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlF1b3RpbmcgSsO8cmdlbjo8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZndDtCdXQgaWYgb25lIG91dCBvZiB0aGUgc2V2 ZXJhbCBjb21taXRzIG5vdyBmYWlscywgaG93IGRvIHlvdSByZWNvdmVyIGZyb20gdGhhdD8gQW5k IGhvdyBpcyB0aGUgcmVjb3ZlcnkgYmV0dGVyIHRoYW4gTkMgd2l0aCBjb25maXJtZWQtY29tbWl0 PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+SGVyZSBpcyBhbiBleGFtcGxlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjEuIENsaWVudCBzZW5kcyBzY2hlZHVsZWQgY29tbWl0IHRvIE4gc2VydmVycywgdG8gYmUg cGVyZm9ybWVkIGF0IGEgZnV0dXJlIHRpbWUgVC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4yLiBPbmUgb2YgdGhlIHNlcnZlcnMgcmVwbGllcyB3aXRoIGFuIHJwYy1lcnJvciAobWVh bmluZyBpdCB3aWxsIG5vdCBiZSBhYmxlIHRvIGNvbW1pdCkuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhpcyBpcyBhIGJpZyBwcm9ibGVtLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHNlcnZlciBjYW5ub3QgdmFsaWRhdGUgdGhl IGNvbmZpZyBhdCBzY2hlZHVsZSB0aW1lPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5hbmQgc2F5IGl0IHdpbGwgYmUgT0sgYXQgUlBDIGV4ZWN1dGlv biB0aW1lLiZuYnNwOyBXaGF0IGlmIGl0IGNoYW5nZXM/PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FdmVuIGlmIGV2ZXJ5dGhpbmcgc3RheXMgbG9j a2VkIGZvciBhIGxvbmcgdGltZSAoZGVmaW5pdGVseSBOT1QgaG93PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ORVRDT05GIGxvY2tzIGFyZSBpbnRl bmRlZCB0byBiZSB1c2VkKSB3aGF0IGlmIHRoZSBvcGVyYXRvcjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Y2hhbmdlcyB0aGUgaGFyZHdhcmUgaW4g c29tZSB3YXkgKGUuZy4gcHVsbCBhIGxpbmUtY2FyZCBvdXQpPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5vciBzb21lIGhhcmR3YXJlIGZhaWxzLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbGwg dGhlIHNlcnZlciBjYW4gc2F5IGZvciBBTlkgJmx0O3JwYyZndDsgaXMgJnF1b3Q7b2sgLSBJIHNj aGVkdWxlZCB0aGlzIG9wZXJhdGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Zm9yIHRoZSBkZXNpcmVkIGludm9jYXRpb24gdGltZSZxdW90Ozxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+My4gQ2xpZW50IHNlbmRzICZsdDtjYW5jZWwtc2NoZWR1bGUmZ3Q7IHRvIHRoZSBvdGhl ciBOLTEgc2VydmVycywgYmVmb3JlIHRpbWUgVC4gTm9uZSBvZiB0aGUgc2VydmVycyBoYXMNCiBj b21taXR0ZWQgeWV0LCBhbmQgdGhleSBhbGwgY2FuY2VsIHRoZSBzY2hlZHVsZWQgY29tbWl0Ljwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlRoZSBhZHZhbnRhZ2UgaXMgdGhhdCB0aGVyZSBpcyBubyBuZWVkIHRvIHJv bGwgYmFjay4gRnJvbSBhIG5ldHdvcmstd2lkZSBwZXJzcGVjdGl2ZSwgdGhlIGNvbmZpZ3VyYXRp b24NCiByZW1haW5zIGNvbnRpbnVvdXNseSBjb25zaXN0ZW50IGluIHRoZSB0aHJlZSBzdGVwcyBh Ym92ZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5RdW90aW5nIEFuZHk6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mZ3Q7VGhpcyBhc3N1bWVzIHRoYXQgdGhlIGxvYWQgb24gdGhlIHN5c3RlbSBhdCB0aGUg dGltZSBvZiB0aGUgUlBDPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZn dDtleGVjdXRpb24gaXMgc29tZXdoYXQga25vd24gYW5kIHN0YWJsZS4gSSBhbSB0YWxraW5nIGFi b3V0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZndDt0aGUgZWxhcHNl ZCB0aW1lIG1lYXN1cmVtZW50LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SXQgaXMgbm90IGFzc3VtZWQgdGhhdCB0aGUgdGlt ZSBvZiB0aGUgUlBDIGV4ZWN1dGlvbiBpcyBrbm93biBvciBzdGFibGUuIFRoZSBzY2hlZHVsZWQt dGltZSBzcGVjaWZpZXMNCiB0aGUgKjxiPnN0YXJ0PC9iPiogdGltZSBvZiB0aGUgUlBDLCBhbmQg dGhlIGV4ZWN1dGlvbi10aW1lIHNwZWNpZmllcyB0aGUgKjxiPmNvbXBsZXRpb248L2I+KiB0aW1l LiBUaGF0IG1lYW5zIHRoYXQgYnkga25vd2luZyB0aGUgc2NoZWR1bGVkLXRpbWUgYW5kIGV4ZWN1 dGlvbi10aW1lLCB0aGUgY2xpZW50IGtub3dzIHRoYXQgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiB0 aGVzZSB0d28gdmFsdWVzIGlzIHRoZSBlbGFwc2VkIHRpbWUgb2YgZXhlY3V0aW9uDQogJiM0Mzsg dGhlIHNjaGVkdWxpbmcgaW5hY2N1cmFjeS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5UaHVzLCB0aGUgJmx0O2V4ZWN1dGlvbi10aW1lJmd0OyBwYXJhbWV0ZXIgYWxsb3dzIHRoZSBj bGllbnQgdG8gZGV0ZWN0IGFuZCBtb25pdG9yIGZsdWN0dWF0aW9ucyBpbiB0aGUNCiBSUEMgZXhl Y3V0aW9uIHRpbWUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UXVvdGluZyBKw7xyZ2VuOjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jmd0O1lvdSBzZWVtIHRvIGJlIHRhbGtpbmcgYWJvdXQgdGhlIGlkZWEg dGhhdCBtYW5hZ2VyIHdhbnRzIHRvIGFib3J0IHRoZSBzY2hlZHVsZWQgY29tbWl0Lg0KPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZndDtUaGlzIGRvZXMgbm90IGV4aXN0 IGluIE5DIHdpdGggY29uZmlybWVkLWNvbW1pdCwgZXhjZXB0IHRoYXQgdGhlIG1hbmFnZXIgY2Fu IHNpbXBseSBzdG9wIGludm9raW5nIGNvbW1pdHMgaWYgaXQgY2hhbmdlcyBpdHMgbWluZCBzcG9u dGFuZW91c2x5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+QXMgQW5keSBub3RlZCwgTkMgc3VwcG9ydHMgdGhlICZsdDtjYW5j ZWwtY29tbWl0Jmd0OyBvcGVyYXRpb24uIFRoZSBtYWluIGRpZmZlcmVuY2UgaXMgdGhhdCB0aGUg Jmx0O2NhbmNlbC1jb21taXQmZ3Q7DQogaXMgcGVyZm9ybWVkICo8Yj5hZnRlcjwvYj4qIHRoZSBj b21taXQgd2FzIGFwcGxpZWQsIGFzIG9wcG9zZWQgdG8gdGhlICZsdDtjYW5jZWwtc2NoZWR1bGUm Z3Q7LCBwZXJmb3JtZWQgKjxiPmJlZm9yZTwvYj4qIHRoZSBjb21taXQgaXMgYXBwbGllZC48L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnV0ICZsdDtjYW5jZWwtc2NoZWR1bGUmZ3Q7IGlzIGEg Z2VuZXJpYyBvcGVyYXRpb24gdGhhdCBoYXMgbm90aGluZyB0byBkbzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+d2l0aCAmbHQ7Y29tbWl0Jmd0Oy4m bmJzcDsgVGhlIDp0aW1lIGNhcGFiaWxpdHkgZG9lcyBub3Qgb2ZmZXIgYW55IGZlYXR1cmVzPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5yZWxhdGVk IHRvIGNvbW1pdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SSBjb3VsZCBzZWUgc29tZXRoaW5nIGxpa2UgdGhpcyB1c2VkIGluIENvTUkgd2hl cmUgdGhlIG5ldHdvcmsgaXMgc2xvdyB0aGVyZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+bWF5IGJlIGxvdHMgb2Ygc2VydmVycywgc28gYSB1bmlj YXN0IHN0b3JtIG9mIHJlcXVlc3RzIGFuZCByZXNwb25zZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFsbCBhdCBjb21taXQgdGltZSB3b3VsZCBi ZSBhIHByb2JsZW0uJm5ic3A7IEJ1dCBjb25zdHJhaW5lZCBkZXZpY2VzIG5lZWQ8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnNpbXBsZSBBUElzIHNv IG5vbmUgb2YgdGhlIGV4dHJhcyAobGlrZSBtZWFzdXJpbmcgZXhlY3V0aW9uIHRpbWUpPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj53b3VsZCBiZSBh cHByb3ByaWF0ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5D aGVlcnMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRhbC48L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5BbmR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4i Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBBbmR5IEJpZXJtYW4gW21h aWx0bzo8YSBocmVmPSJtYWlsdG86YW5keUB5dW1hd29ya3MuY29tIiB0YXJnZXQ9Il9ibGFuayI+ YW5keUB5dW1hd29ya3MuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEp1bmUg MjksIDIwMTUgMTA6MDUgUE08YnI+DQo8Yj5Ubzo8L2I+IFRhbCBNaXpyYWhpPGJyPg0KPGI+Q2M6 PC9iPiBOZXRjb25mPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbTmV0Y29uZl0gW0ZPV0FSRElO R10gTGFzdCBDYWxsOiAmbHQ7ZHJhZnQtbW0tbmV0Y29uZi10aW1lLWNhcGFiaWxpdHktMDUudHh0 Jmd0OyAoVGltZSBDYXBhYmlsaXR5IGluIE5FVENPTkYpIHRvIEV4cGVyaW1lbnRhbCBSRkM8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIE1vbiwgSnVuIDI5LCAyMDE1IGF0IDEx OjUzIEFNLCBUYWwgTWl6cmFoaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRhbG1pQG1hcnZlbGwuY29t IiB0YXJnZXQ9Il9ibGFuayI+dGFsbWlAbWFydmVsbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgQW5keSw8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5U aGFua3MgZm9yIHRoZSBjb21tZW50cy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZndDtU aGUgZHJhZnQgbWl4ZXMgc2VydmVyIG1lYXN1cmVtZW50IG9mIFJQQyBleGVjdXRpb24gdGltZTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mZ3Q7d2l0aCBhICZxdW90O2Ny b24mcXVvdDsgZnVuY3Rpb24uJm5ic3A7IFRoZSByYXRpb25hbGUgZm9yIHRoaXMgZ3JhYi1iYWcg b2Y8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jmd0O3RpbWUtcmVsYXRl ZCBmdW5jdGlvbmFsaXR5IGlzIG5vdCBlbnRpcmVseSBjbGVhci48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk9uZSBvZiB0aGUg bW9zdCBub3RhYmxlIHVzZSBjYXNlcyBpcyBhIG5ldHdvcmstd2lkZSBjb21taXQuIFRoZSB0aW1l IGNhcGFiaWxpdHkgKHVzaW5nIHNjaGVkdWxlZA0KIGNvbW1pdHMgYW5kIGNhbmNlbC1zY2hlZHVs ZSkgYWxsb3dzIGEgY2xpZW50IHRvIHBlcmZvcm0gYSBuZXR3b3JrLXdpZGUgY29tbWl0IGluIE4g c2VydmVycywgd2hlcmUgZWl0aGVyIGFsbCBwZXJmb3JtIHRoZSBjb21taXQsIG9yIG5vbmUgb2Yg dGhlbSBkb2VzLiBTdWNoIGJlaGF2aW9yIGlzIG5vdCBjdXJyZW50bHkgcG9zc2libGUgd2l0aCBj b25maXJtZWQgY29tbWl0cyAoUkZDNjI0MSk7IHdoZW4gdXNpbmcgY29uZmlybWVkIGNvbW1pdHMs IGlmDQogc29tZXRoaW5nIGdvZXMgd3JvbmcsIHRoZW4gYWxsIHRoZSBzZXJ2ZXJzIHJvbGwgYmFj ayB0byB0aGUgcHJldmlvdXMgY29uZmlndXJhdGlvbiwgd2hpY2ggbWVhbnMgdGhhdCB0aGVyZSBp cyBhIChwb3RlbnRpYWxseSBsb25nKSB0cmFuc2llbnQgc3RhdGUgd2hlcmUgc29tZSBzZXJ2ZXJz IGhhdmUgY2hhbmdlZCB0aGVpciBjb25maWd1cmF0aW9uIGFuZCBvdGhlcnMgaGF2ZSBub3QuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIHRpbWUgY2FwYWJpbGl0eSBhbGxvd3Mg dGhlIGNsaWVudCB0byBjYW5jZWwgdGhlIGNvbW1pdCBpbiBhZHZhbmNlOiBpZiBvbmUgb2YgdGhl IHNlcnZlcnMgaW5kaWNhdGVzDQogaXQgY2Fubm90IHBlcmZvcm0gdGhlIGNvbW1pdCAodXNpbmcg YW4gZXJyb3IgbWVzc2FnZSksIHRoZW4gdGhlIGNsaWVudCBzZW5kcyBhIGNhbmNlbGxhdGlvbiBt ZXNzYWdlIHRvIGFsbCB0aGUgc2VydmVycyBiZWZvcmUgdGhlIGNvbW1pdCBoYXMgb2NjdXJyZWQu IEFsbCB0aGUgc2VydmVycyBjb25zaXN0ZW50bHkgdXNlIHRoZSBzYW1lIGRhdGFzdG9yZSB0aHJv dWdob3V0IHRoZSBwcm9jZWR1cmUuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BY3R1YWxseSwgUkZDIDYyNDEgY29uZmlybWVkLWNv bW1pdCBoYXMgYSAmbHQ7Y2FuY2VsLWNvbW1pdCZndDsgb3BlcmF0aW9uPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnNvIGl0IGNhbiBvcGVyYXRl IHRoZSBzYW1lIHdheSAoY2xpZW50IHNlbmQgY2FuY2VsIHRvIE4tMSBzZXJ2ZXJzIHdoZW48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MSBzZXJ2 ZXIgcmV0dXJucyBhIGNvbW1pdC1mYWlsZWQgZXJyb3IpPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIGV4ZWN1dGlvbi10aW1lIHBhcmFt ZXRlciBhbGxvd3MgdGhlIGNsaWVudCB0byByZWNlaXZlIGZlZWRiYWNrIGFib3V0IHRoZSBhY3R1 YWwgZXhlY3V0aW9uIHRpbWUNCiBvZiB0aGUgUlBDLiBCYXNlZCBvbiB0aGlzIGZlZWRiYWNrIHRo ZSBjbGllbnQ6ICgxKSBrbm93cyBob3cgYWNjdXJhdGVseSB0aGUgc2VydmVyIHNjaGVkdWxlZCB0 aGUgUlBDLCBhbmQgKDIpIGhhcyBhIChyb3VnaCkgcGljdHVyZSBvZiB3aGV0aGVyIHRoZSBzZXJ2 ZXLigJlzIGNsb2NrIGlzIHN5bmNocm9uaXplZCB0byBpdHMgb3duIChzZWUgU2VjdGlvbiAzLjMg Zm9yIGZ1cnRoZXIgZGlzY3Vzc2lvbikuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGlzIGFzc3VtZXMg dGhhdCB0aGUgbG9hZCBvbiB0aGUgc3lzdGVtIGF0IHRoZSB0aW1lIG9mIHRoZSBSUEM8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ZXhlY3V0aW9u IGlzIHNvbWV3aGF0IGtub3duIGFuZCBzdGFibGUuIEkgYW0gdGFsa2luZyBhYm91dDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj50aGUgZWxhcHNl ZCB0aW1lIG1lYXN1cmVtZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIGNsZWludCBjYW4gY2hlY2sgdGhlIHNlcnZlcidzIHRp bWUtb2YtZGF5IGp1c3QgYnk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+cmVhZGluZyB0aGUgY3VycmVudC1kYXRlLXRpbWUgb2JqZWN0LiZuYnNw OyBJdCBkb2VzIG5vdCBuZWVkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPmV4ZWN1dGVkLWF0IHRpbWVzdGFtcHMgdG8gY2hlY2sgdGhhdCB0aGUg Y2xvY2tzIGFyZSBpbiBzeW5jaC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5XZSBwcmVzZW50ZWQgYSBmZXcgdXNlLWNhc2VzIGF0IHRoZSBJ RVRGIG1lZXRpbmcgaW4gQmVybGluICg8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL3Byb2Nl ZWRpbmdzLzg3L3NsaWRlcy9zbGlkZXMtODctbmV0Y29uZi0xLnBkZiIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvODcvc2xpZGVzL3NsaWRlcy04Ny1uZXRj b25mLTEucGRmPC9hPiksDQogYW5kIHRoZSBEYWxsYXMgcHJlc2VudGF0aW9uICg8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85Mi9zbGlkZXMvc2xpZGVzLTkyLW5ldGNv bmYtMTMucGRmIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGlu Z3MvOTIvc2xpZGVzL3NsaWRlcy05Mi1uZXRjb25mLTEzLnBkZjwvYT4pLCB3aGljaCB3YXMgbm90 IHByZXNlbnRlZCBkdWUgdG8gbGFjayBvZiB0aW1lLCBpbmNsdWRlZCB0aGUgbmV0d29yay13aWRl DQogY29tbWl0IHVzZSBjYXNlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNoZWVycyw8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+VGFsLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFuZHk8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiBOZXRjb25mIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5P biBCZWhhbGYgT2YgPC9iPkFuZHkgQmllcm1hbjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEp1 bmUgMjksIDIwMTUgODoyNyBQTTxicj4NCjxiPlRvOjwvYj4gSnVlcmdlbiBTY2hvZW53YWVsZGVy OyBOZXRjb25mPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbTmV0Y29uZl0gW0ZPV0FSRElOR10g TGFzdCBDYWxsOiAmbHQ7ZHJhZnQtbW0tbmV0Y29uZi10aW1lLWNhcGFiaWxpdHktMDUudHh0Jmd0 OyAoVGltZSBDYXBhYmlsaXR5IGluIE5FVENPTkYpIHRvIEV4cGVyaW1lbnRhbCBSRkM8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGksPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklzIHRoaXMgYW4gQUQtc3BvbnNv cmVkIGRyYWZ0PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+VGhpcyBkcmFmdCB3YXMgJnF1b3Q7aW50ZXJlc3RpbmcmcXVvdDsgYnV0IG5v dCBlbm91Z2ggdG8gYmUgcHJpb3JpdGl6ZWQgYWhlYWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+b2Ygb3RoZXIgd29yayBiZWluZyBkb25lIGlu IHRoZSBORVRDT05GIFdHLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+VGhlIGRyYWZ0IG1peGVzIHNlcnZlciBtZWFzdXJlbWVudCBvZiBS UEMgZXhlY3V0aW9uIHRpbWU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+d2l0aCBhICZxdW90O2Nyb24mcXVvdDsgZnVuY3Rpb24uJm5ic3A7IFRo ZSByYXRpb25hbGUgZm9yIHRoaXMgZ3JhYi1iYWcgb2Y8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+dGltZS1yZWxhdGVkIGZ1bmN0aW9uYWxpdHkg aXMgbm90IGVudGlyZWx5IGNsZWFyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhpcyB3b3JrIGRvZXMgbm90IGhhdmUgYW55IGNvbnNl bnN1cyB3aXRoaW4gdGhlIE5FVENPTkYgV0cuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkl0IGRvZXMgc2VlbSBhIGxpdHRsZSBzdXJwcmlzaW5n IHRoYXQgaXQgaXMgYmVpbmcgcHVibGlzaGVkIHdpdGhvdXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ZXZlbiBhc2tpbmcgdGhlIE5FVENPTkYg V0cgZm9yIGNvbW1lbnRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+SSBkb24ndCBoYXZlIGFueSBwcm9ibGVtIHdpdGggRXhwZXJpbWVu dGFsIFJGQ3MgYXMgbG9uZyBhcyBpdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5pcyBjbGVhciB0aGlzIGlzIG5vdCBhIHByb2R1Y3Qgb2YgdGhl IE5FVENPTkYgV0cuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkFuZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gTW9uLCBKdW4gMjksIDIwMTUg YXQgODowNyBBTSwgSnVlcmdlbiBTY2hvZW53YWVsZGVyICZsdDs8YSBocmVmPSJtYWlsdG86ai5z Y2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlIiB0YXJnZXQ9Il9ibGFuayI+ai5zY2hv ZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bWFyZ2luLWJvdHRvbToxMi4wcHQiPkhpLDxicj4NCjxicj4NCmp1c3QgdG8gbWFrZSBzdXJlIGV2 ZXJ5Ym9keSBoZXJlIGhhcyBzZWVuIHRoaXMuPGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4 ODgiPjxicj4NCi9qczxicj4NCjxicj4NCi0tPGJyPg0KSnVlcmdlbiBTY2hvZW53YWVsZGVyJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtKYWNvYnMgVW5pdmVyc2l0eSBC cmVtZW4gZ0dtYkg8YnI+DQpQaG9uZTogJiM0Mzs0OSA0MjEgMjAwIDM1ODcmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7Q2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1h bnk8YnI+DQpGYXg6Jm5ic3A7ICZuYnNwOyYjNDM7NDkgNDIxIDIwMCAzMTAzJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDs8YSBocmVmPSJodHRwOi8vd3d3LmphY29icy11bml2 ZXJzaXR5LmRlLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHku ZGUvPC9hPiZndDs8YnI+DQo8L3NwYW4+PGJyPg0KPGJyPg0KLS0tLS0tLS0tLSBGb3J3YXJkZWQg bWVzc2FnZSAtLS0tLS0tLS0tPGJyPg0KRnJvbTombmJzcDtUaGUgSUVTRyAmbHQ7PGEgaHJlZj0i bWFpbHRvOmllc2ctc2VjcmV0YXJ5QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aWVzZy1zZWNy ZXRhcnlAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NClRvOiZuYnNwO0lFVEYtQW5ub3VuY2UgJmx0Ozxh IGhyZWY9Im1haWx0bzppZXRmLWFubm91bmNlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aWV0 Zi1hbm5vdW5jZUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KQ2M6Jm5ic3A7PGJyPg0KRGF0ZTombmJz cDtNb24sIDI5IEp1biAyMDE1IDA3OjU4OjIyIC0wNzAwPGJyPg0KU3ViamVjdDombmJzcDtMYXN0 IENhbGw6ICZsdDtkcmFmdC1tbS1uZXRjb25mLXRpbWUtY2FwYWJpbGl0eS0wNS50eHQmZ3Q7IChU aW1lIENhcGFiaWxpdHkgaW4gTkVUQ09ORikgdG8gRXhwZXJpbWVudGFsIFJGQzxicj4NCjxicj4N ClRoZSBJRVNHIGhhcyByZWNlaXZlZCBhIHJlcXVlc3QgZnJvbSBhbiBpbmRpdmlkdWFsIHN1Ym1p dHRlciB0byBjb25zaWRlcjxicj4NCnRoZSBmb2xsb3dpbmcgZG9jdW1lbnQ6PGJyPg0KLSAnVGlt ZSBDYXBhYmlsaXR5IGluIE5FVENPTkYnPGJyPg0KJm5ic3A7ICZsdDtkcmFmdC1tbS1uZXRjb25m LXRpbWUtY2FwYWJpbGl0eS0wNS50eHQmZ3Q7IGFzIEV4cGVyaW1lbnRhbCBSRkM8YnI+DQo8YnI+ DQpUaGUgSUVTRyBwbGFucyB0byBtYWtlIGEgZGVjaXNpb24gaW4gdGhlIG5leHQgZmV3IHdlZWtz LCBhbmQgc29saWNpdHM8YnI+DQpmaW5hbCBjb21tZW50cyBvbiB0aGlzIGFjdGlvbi4gUGxlYXNl IHNlbmQgc3Vic3RhbnRpdmUgY29tbWVudHMgdG8gdGhlPGJyPg0KPGEgaHJlZj0ibWFpbHRvOmll dGZAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pZXRmQGlldGYub3JnPC9hPiBtYWlsaW5nIGxp c3RzIGJ5IDIwMTUtMDctMjkuIEV4Y2VwdGlvbmFsbHksIGNvbW1lbnRzIG1heSBiZTxicj4NCnNl bnQgdG8gPGEgaHJlZj0ibWFpbHRvOmllc2dAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pZXNn QGlldGYub3JnPC9hPiBpbnN0ZWFkLiBJbiBlaXRoZXIgY2FzZSwgcGxlYXNlIHJldGFpbiB0aGU8 YnI+DQpiZWdpbm5pbmcgb2YgdGhlIFN1YmplY3QgbGluZSB0byBhbGxvdyBhdXRvbWF0ZWQgc29y dGluZy48YnI+DQo8YnI+DQpBYnN0cmFjdDxicj4NCjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtU aGlzIGRvY3VtZW50IGRlZmluZXMgYSBjYXBhYmlsaXR5LWJhc2VkIGV4dGVuc2lvbiB0byB0aGUg TmV0d29yazxicj4NCiZuYnNwOyAmbmJzcDtDb25maWd1cmF0aW9uIFByb3RvY29sIChORVRDT05G KSB0aGF0IGFsbG93cyB0aW1lLXRyaWdnZXJlZDxicj4NCiZuYnNwOyAmbmJzcDtjb25maWd1cmF0 aW9uIGFuZCBtYW5hZ2VtZW50IG9wZXJhdGlvbnMuIFRoaXMgZXh0ZW5zaW9uIGFsbG93czxicj4N CiZuYnNwOyAmbmJzcDtORVRDT05GIGNsaWVudHMgdG8gaW52b2tlIGNvbmZpZ3VyYXRpb24gdXBk YXRlcyBhY2NvcmRpbmcgdG88YnI+DQombmJzcDsgJm5ic3A7c2NoZWR1bGVkIHRpbWVzLCBhbmQg YWxsb3dzIE5FVENPTkYgc2VydmVycyB0byBhdHRhY2ggdGltZXN0YW1wcyB0bzxicj4NCiZuYnNw OyAmbmJzcDt0aGUgZGF0YSB0aGV5IHNlbmQgdG8gTkVUQ09ORiBjbGllbnRzLjxicj4NCjxicj4N Cjxicj4NClRoZSBOZXR3b3JrIENvbmZpZ3VyYXRpb24gUHJvdG9jb2wgKE5FVENPTkYpIENhcGFi aWxpdHkgVVJOcyByZWdpc3RyeTxicj4NCnJlcXVpcmVzIGEgc3RhbmRhcmRzIGFjdGlvbiBpbiBv cmRlciB0byBwb3B1bGF0ZSB0aGUgcmVnaXN0cnkuIFRoaXMgZG9jdW1lbnQ8YnI+DQp3YXMgdGFr ZW4gb3V0IG9mIHRoZSBJU0Ugc3RyZWFtIGFuZCBicm91Z2h0IGZvcndhcmQgYXMgYW4gQUQgc3Bv bnNvcmVkPGJyPg0KaW5kaXZpZHVhbC1zdWJtaXNzaW9uIHRvIGFkZHJlc3MgdGhpcyBjb25zaWRl cmF0aW9uLjxicj4NCjxicj4NCjxicj4NClRoZSBmaWxlIGNhbiBiZSBvYnRhaW5lZCB2aWE8YnI+ DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1tbS1uZXRj b25mLXRpbWUtY2FwYWJpbGl0eS8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1tbS1uZXRjb25mLXRpbWUtY2FwYWJpbGl0eS88L2E+PGJyPg0K PGJyPg0KSUVTRyBkaXNjdXNzaW9uIGNhbiBiZSB0cmFja2VkIHZpYTxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1tLW5ldGNvbmYtdGltZS1jYXBh YmlsaXR5L2JhbGxvdC8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1tbS1uZXRjb25mLXRpbWUtY2FwYWJpbGl0eS9iYWxsb3QvPC9hPjxicj4N Cjxicj4NCjxicj4NCk5vIElQUiBkZWNsYXJhdGlvbnMgaGF2ZSBiZWVuIHN1Ym1pdHRlZCBkaXJl Y3RseSBvbiB0aGlzIEktRC48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk5ldGNvbmYgbWFpbGluZyBsaXN0 PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5O ZXRjb25mQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbmV0Y29uZiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_c16824608da54be79f6395d8ff65b014ILEXCH01marvellcom_-- From nobody Tue Jun 30 00:44:12 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23FA51A0368 for ; Tue, 30 Jun 2015 00:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwjBLFLq2ej8 for ; Tue, 30 Jun 2015 00:44:05 -0700 (PDT) Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [209.85.215.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1F031A0302 for ; Tue, 30 Jun 2015 00:44:04 -0700 (PDT) Received: by laar3 with SMTP id r3so2578304laa.0 for ; Tue, 30 Jun 2015 00:44:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=meduR0mSwKoWPV9rl6TizGqropHQrnWb++plJ1YfePI=; b=ilICp4yf174WCajUFMvOg/sFTpRGlscklCMrhAQtcrgrlvr4DUqu/9oOwL61snfEP9 wPlwuvbjhP5QKBL5H28vOeXucTGMPhTu9QdORycDHKKRoxMfOO0ye0r4kGrXHb7sOFdu h+PH9aRI58cs2VmeAeLujPw8DDiHdmOVV241dOIfptUq3RAVmt3xXNHrjDeFk2L5Ipu2 aVtFuXXzqAS9dWHCt/hDoP1F06wVJzuBVF80goFIjTPoyo6YR2n6XBeAFnmLOwmOovg+ jghMrlLpmtgCmADZsbC3LDabZQNRlSWOTS2FZsRgwGdv2By04ruU6qgwoX43hNvB7a3z FKGw== X-Gm-Message-State: ALoCoQmMdi3BSfHszwPIZX7kBQF2xiapzVOsss+s2HQY64Ux9zi6RmiiEzh6y97/0DB3jx59olGx MIME-Version: 1.0 X-Received: by 10.112.41.171 with SMTP id g11mr2531602lbl.123.1435650243104; Tue, 30 Jun 2015 00:44:03 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Tue, 30 Jun 2015 00:44:02 -0700 (PDT) In-Reply-To: References: <20150629150721.GA2587@elstar.local> <7be9dceb27734ceb94bcb04fdfb3451c@IL-EXCH01.marvell.com> Date: Tue, 30 Jun 2015 00:44:02 -0700 Message-ID: From: Andy Bierman To: Tal Mizrahi Content-Type: multipart/alternative; boundary=001a11346d9cc327b80519b75e9d Archived-At: Cc: Netconf Subject: Re: [Netconf] [FOWARDING] Last Call: (Time Capability in NETCONF) to Experimental RFC X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 07:44:10 -0000 --001a11346d9cc327b80519b75e9d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jun 29, 2015 at 11:16 PM, Tal Mizrahi wrote: > > > >All the server can say for ANY is "ok - I scheduled this operation > > >for the desired invocation time" > > > > However, if the server is down, and does not send back an =E2=80=9Cok =E2= =80=93 I > scheduled this operation=E2=80=9D, the client can send a cancel-schedule = to the > other servers. > > Going back to the confirmed commit, if one of the servers is down and the > client sends a commit to all the servers, the client can send a > upon detecting the failure, but this, again will result i= n > a temporary state where different servers use different configuration > versions. Using the :time capability, on the other hand, prevents this > temporary inconsistency. > > > Seems like if a server goes down the NMS will find out about it through its normal FCAPS management. If the NMS maintains sessions then the dropped TCP connection will tell the NMS the server is down. This seems like a non-problem. It is just as likely that the server will be up, return to the schedule, and then go down. This causes the not to run, which causes the anyway. > Thanks, > > Tal. > Andy > > > *From:* Andy Bierman [mailto:andy@yumaworks.com] > *Sent:* Monday, June 29, 2015 11:39 PM > *To:* Tal Mizrahi > *Cc:* Netconf > *Subject:* Re: [Netconf] [FOWARDING] Last Call: > (Time Capability in NETCONF) to > Experimental RFC > > > > > > > > On Mon, Jun 29, 2015 at 1:19 PM, Tal Mizrahi wrote: > > Andy, J=C3=BCrgen, > > > > Thanks for the prompt responses. > > > > Quoting Andy: > > > > > Actually, RFC 6241 confirmed-commit has a operation > > >so it can operate the same way (client send cancel to N-1 servers when > > >1 server returns a commit-failed error) > > > > Indeed, but the is applied only after the commit was > already performed, meaning that now the server has to roll back. > > The operation lets you cancel the commit before it has > occurred, allowing all servers to remain with the current configuration. > See the example below. > > > > > > > > But the normal server doesn't send RPCs until they are needed > > so it doesn't need to cancel anything before the commit. > > > > > > Quoting J=C3=BCrgen: > > > > >But if one out of the several commits now fails, how do you recover from > that? And how is the recovery better than NC with confirmed-commit? > > > > Here is an example: > > 1. Client sends scheduled commit to N servers, to be performed at a futur= e > time T. > > 2. One of the servers replies with an rpc-error (meaning it will not be > able to commit). > > > > > > This is a big problem. > > The server cannot validate the config at schedule time > > and say it will be OK at RPC execution time. What if it changes? > > Even if everything stays locked for a long time (definitely NOT how > > NETCONF locks are intended to be used) what if the operator > > changes the hardware in some way (e.g. pull a line-card out) > > or some hardware fails. > > > > All the server can say for ANY is "ok - I scheduled this operation > > for the desired invocation time" > > > > > > 3. Client sends to the other N-1 servers, before time > T. None of the servers has committed yet, and they all cancel the schedul= ed > commit. > > > > The advantage is that there is no need to roll back. From a network-wide > perspective, the configuration remains continuously consistent in the thr= ee > steps above. > > > > Quoting Andy: > > > > >This assumes that the load on the system at the time of the RPC > > >execution is somewhat known and stable. I am talking about > > >the elapsed time measurement. > > > > It is not assumed that the time of the RPC execution is known or stable. > The scheduled-time specifies the **start** time of the RPC, and the > execution-time specifies the **completion** time. That means that by > knowing the scheduled-time and execution-time, the client knows that the > difference between these two values is the elapsed time of execution + th= e > scheduling inaccuracy. > > Thus, the parameter allows the client to detect and > monitor fluctuations in the RPC execution time. > > > > Quoting J=C3=BCrgen: > > > > >You seem to be talking about the idea that manager wants to abort the > scheduled commit. > > >This does not exist in NC with confirmed-commit, except that the manager > can simply stop invoking commits if it changes its mind spontaneously. > > > > As Andy noted, NC supports the operation. The main > difference is that the is performed **after** the commit > was applied, as opposed to the , performed **before** > the commit is applied. > > > > But is a generic operation that has nothing to do > > with . The :time capability does not offer any features > > related to commit. > > > > I could see something like this used in CoMI where the network is slow > there > > may be lots of servers, so a unicast storm of requests and responses > > all at commit time would be a problem. But constrained devices need > > simple APIs so none of the extras (like measuring execution time) > > would be appropriate. > > > > > > > > > > Cheers, > > Tal. > > > > > > Andy > > > > > > > > *From:* Andy Bierman [mailto:andy@yumaworks.com] > *Sent:* Monday, June 29, 2015 10:05 PM > *To:* Tal Mizrahi > *Cc:* Netconf > *Subject:* Re: [Netconf] [FOWARDING] Last Call: > (Time Capability in NETCONF) to > Experimental RFC > > > > > > > > On Mon, Jun 29, 2015 at 11:53 AM, Tal Mizrahi wrote: > > Hi Andy, > > > > Thanks for the comments. > > > > >The draft mixes server measurement of RPC execution time > > >with a "cron" function. The rationale for this grab-bag of > > >time-related functionality is not entirely clear. > > > > One of the most notable use cases is a network-wide commit. The time > capability (using scheduled commits and cancel-schedule) allows a client = to > perform a network-wide commit in N servers, where either all perform the > commit, or none of them does. Such behavior is not currently possible wit= h > confirmed commits (RFC6241); when using confirmed commits, if something > goes wrong, then all the servers roll back to the previous configuration, > which means that there is a (potentially long) transient state where some > servers have changed their configuration and others have not. > > The time capability allows the client to cancel the commit in advance: if > one of the servers indicates it cannot perform the commit (using an error > message), then the client sends a cancellation message to all the servers > before the commit has occurred. All the servers consistently use the same > datastore throughout the procedure. > > > > > > > > Actually, RFC 6241 confirmed-commit has a operation > > so it can operate the same way (client send cancel to N-1 servers when > > 1 server returns a commit-failed error) > > > > > > > > > > The execution-time parameter allows the client to receive feedback about > the actual execution time of the RPC. Based on this feedback the client: > (1) knows how accurately the server scheduled the RPC, and (2) has a > (rough) picture of whether the server=E2=80=99s clock is synchronized to = its own > (see Section 3.3 for further discussion). > > > > > > > > This assumes that the load on the system at the time of the RPC > > execution is somewhat known and stable. I am talking about > > the elapsed time measurement. > > > > The cleint can check the server's time-of-day just by > > reading the current-date-time object. It does not need > > executed-at timestamps to check that the clocks are in synch. > > > > > > > > > > We presented a few use-cases at the IETF meeting in Berlin ( > http://www.ietf.org/proceedings/87/slides/slides-87-netconf-1.pdf), and > the Dallas presentation ( > https://www.ietf.org/proceedings/92/slides/slides-92-netconf-13.pdf), > which was not presented due to lack of time, included the network-wide > commit use case. > > > > Cheers, > > Tal. > > > > > > > > Andy > > > > *From:* Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of *Andy > Bierman > *Sent:* Monday, June 29, 2015 8:27 PM > *To:* Juergen Schoenwaelder; Netconf > *Subject:* Re: [Netconf] [FOWARDING] Last Call: > (Time Capability in NETCONF) to > Experimental RFC > > > > Hi, > > > > > > Is this an AD-sponsored draft? > > > > This draft was "interesting" but not enough to be prioritized ahead > > of other work being done in the NETCONF WG. > > > > The draft mixes server measurement of RPC execution time > > with a "cron" function. The rationale for this grab-bag of > > time-related functionality is not entirely clear. > > > > This work does not have any consensus within the NETCONF WG. > > It does seem a little surprising that it is being published without > > even asking the NETCONF WG for comments. > > > > I don't have any problem with Experimental RFCs as long as it > > is clear this is not a product of the NETCONF WG. > > > > > > > > Andy > > > > > > > > On Mon, Jun 29, 2015 at 8:07 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > Hi, > > just to make sure everybody here has seen this. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > > ---------- Forwarded message ---------- > From: The IESG > To: IETF-Announce > Cc: > Date: Mon, 29 Jun 2015 07:58:22 -0700 > Subject: Last Call: (Time > Capability in NETCONF) to Experimental RFC > > The IESG has received a request from an individual submitter to consider > the following document: > - 'Time Capability in NETCONF' > as Experimental RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2015-07-29. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document defines a capability-based extension to the Network > Configuration Protocol (NETCONF) that allows time-triggered > configuration and management operations. This extension allows > NETCONF clients to invoke configuration updates according to > scheduled times, and allows NETCONF servers to attach timestamps to > the data they send to NETCONF clients. > > > The Network Configuration Protocol (NETCONF) Capability URNs registry > requires a standards action in order to populate the registry. This > document > was taken out of the ISE stream and brought forward as an AD sponsored > individual-submission to address this consideration. > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-mm-netconf-time-capability/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-mm-netconf-time-capability/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > --001a11346d9cc327b80519b75e9d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jun 29, 2015 at 11:16 PM, Tal Mizrahi <talmi@marvell.com&g= t; wrote:

=C2=A0

>All the server can say for ANY <rpc> is &q= uot;ok - I scheduled this operation

>for the desired invocation time"

=C2=A0

However, if the server is d= own, and does not send back an =E2=80=9Cok =E2=80=93 I scheduled this opera= tion=E2=80=9D, the client can send a cancel-schedule to the other servers.<= u>

Going back to the confirmed= commit, if one of the servers is down and the client sends a commit to all= the servers, the client can send a <cancel-commit> upon detecting the failure, but this, again will result in a temporary state wh= ere different servers use different configuration versions. Using the :time= capability, on the other hand, prevents this temporary inconsistency.

=C2=A0


Seems like if a server goes down = the NMS will find out about it
through its normal FCAPS managemen= t.=C2=A0 If the NMS maintains
sessions then the dropped TCP conne= ction will tell the NMS the server is down.
This seems like a non= -problem.

It is just as likely that the server wil= l be up, return <ok> to
the schedule, and then go down.=C2= =A0 This causes the <commit>
not to run, which causes the &= lt;cancel-commit> anyway.


=C2=A0=

Thanks,

Tal.

=


Andy
=C2=A0
=

<= /span>

=C2=A0

From: Andy Bie= rman [mailto:andy@y= umaworks.com]
Sent: Monday, June 29, 2015 11:39 PM
To: Tal Mizrahi
Cc: Netconf
Subject: Re: [Netconf] [FOWARDING] Last Call: <draft-mm-netconf-t= ime-capability-05.txt> (Time Capability in NETCONF) to Experimental RFC<= u>

=C2=A0

=C2=A0

=C2=A0

On Mon, Jun 29, 2015 at 1:19 PM, Tal Mizrahi <talmi@marvell.com&g= t; wrote:

Andy, J=C3=BCrgen,=

=C2=A0

Thanks for the prompt res= ponses.

=C2=A0

Quoting Andy:

=C2=A0

> Actually, RFC 6241 confirmed-commit has a <c= ancel-commit> operation

>so it can operate the same way (client send canc= el to N-1 servers when

>1 server returns a commit-failed error)

=C2=A0

Indeed, but the <cance= l-commit> is applied only after the commit was already performed, meanin= g that now the server has to roll back.

The <cancel-schedule&g= t; operation lets you cancel the commit before it has occurred, allowing al= l servers to remain with the current configuration. See the example below.=

=C2=A0

=C2=A0

=C2=A0

But the normal server doesn't send RPCs until th= ey are needed

so it doesn't need to cancel anything before the= commit.

=C2=A0

=C2=A0

Quoting J=C3=BCrgen:

=C2=A0

>But if one out of the several commits now fails,= how do you recover from that? And how is the recovery better than NC with = confirmed-commit?

=C2=A0

Here is an example:

1. Client sends scheduled= commit to N servers, to be performed at a future time T.<= /u>

2. One of the servers rep= lies with an rpc-error (meaning it will not be able to commit).

=C2=A0

=C2=A0

This is a big problem.

The server cannot validate the config at schedule ti= me

and say it will be OK at RPC execution time.=C2=A0 W= hat if it changes?

Even if everything stays locked for a long time (def= initely NOT how

NETCONF locks are intended to be used) what if the o= perator

changes the hardware in some way (e.g. pull a line-c= ard out)

or some hardware fails.

=C2=A0

All the server can say for ANY <rpc> is "= ok - I scheduled this operation

for the desired invocation time"<= /p>

=C2=A0

=C2=A0

3. Client sends <cance= l-schedule> to the other N-1 servers, before time T. None of the servers= has committed yet, and they all cancel the scheduled commit.<= /u>

=C2=A0

The advantage is that the= re is no need to roll back. From a network-wide perspective, the configurat= ion remains continuously consistent in the three steps above.=

=C2=A0

Quoting Andy:

=C2=A0

>This assumes that the load on the system at the = time of the RPC

>execution is somewhat known and stable. I am tal= king about

>the elapsed time measurement.

=C2=A0

It is not assumed that th= e time of the RPC execution is known or stable. The scheduled-time specifie= s the *start* time of the RPC, and the execution-time specifies the *= completion* time. That means that by knowing the scheduled-time and = execution-time, the client knows that the difference between these two valu= es is the elapsed time of execution + the scheduling inaccuracy.

Thus, the <execution-t= ime> parameter allows the client to detect and monitor fluctuations in t= he RPC execution time.

=C2=A0

Quoting J=C3=BCrgen:

=C2=A0

>You seem to be talking about the idea that manag= er wants to abort the scheduled commit.

>This does not exist in NC with confirmed-commit,= except that the manager can simply stop invoking commits if it changes its= mind spontaneously.

=C2=A0

As Andy noted, NC support= s the <cancel-commit> operation. The main difference is that the <= cancel-commit> is performed *after* the commit was applied, as opposed to the <= cancel-schedule>, performed *before* the commit is applied.

=C2=A0

But <cancel-schedule> is a generic operation t= hat has nothing to do

with <commit>.=C2=A0 The :time capability does= not offer any features

related to commit.

=C2=A0

I could see something like this used in CoMI where t= he network is slow there

may be lots of servers, so a unicast storm of reques= ts and responses

all at commit time would be a problem.=C2=A0 But con= strained devices need

simple APIs so none of the extras (like measuring ex= ecution time)

would be appropriate.

=C2=A0

=C2=A0

=C2=A0

=C2=A0=

Cheers,

Tal.

=C2=A0

=C2=A0

Andy

=C2=A0

=C2=A0

=C2=A0

From: Andy Bie= rman [mailto:andy@y= umaworks.com]
Sent: Monday, June 29, 2015 10:05 PM
To: Tal Mizrahi
Cc: Netconf
Subject: Re: [Netconf] [FOWARDING] Last Call: <draft-mm-netconf-t= ime-capability-05.txt> (Time Capability in NETCONF) to Experimental RFC<= /span>

=C2=A0

=C2=A0

=C2=A0

On Mon, Jun 29, 2015 at 11:53 AM, Tal Mizrahi <talmi@marvell.com&= gt; wrote:

Hi Andy,=

=C2=A0

Thanks for the comments.<= /span>

=C2=A0

>The draft mixes server measurement of RPC execut= ion time

>with a "cron" function.=C2=A0 The rati= onale for this grab-bag of

>time-related functionality is not entirely clear= .

=C2=A0

One of the most notable u= se cases is a network-wide commit. The time capability (using scheduled commits and cancel-schedule) allows a client to perform a network-wide com= mit in N servers, where either all perform the commit, or none of them does= . Such behavior is not currently possible with confirmed commits (RFC6241);= when using confirmed commits, if something goes wrong, then all the servers roll back to the previous confi= guration, which means that there is a (potentially long) transient state wh= ere some servers have changed their configuration and others have not.

The time capability allow= s the client to cancel the commit in advance: if one of the servers indicat= es it cannot perform the commit (using an error message), then the client sen= ds a cancellation message to all the servers before the commit has occurred= . All the servers consistently use the same datastore throughout the proced= ure.

=C2=A0

=C2=A0

=C2=A0

Actually, RFC 6241 confirmed-commit has a <cancel= -commit> operation

so it can operate the same way (client send cancel t= o N-1 servers when

1 server returns a commit-failed error)

=C2=A0

=C2=A0

=C2=A0

=C2=A0

The execution-time parame= ter allows the client to receive feedback about the actual execution time of the RPC. Based on this feedback the client: (1) knows how accurately th= e server scheduled the RPC, and (2) has a (rough) picture of whether the se= rver=E2=80=99s clock is synchronized to its own (see Section 3.3 for furthe= r discussion).

=C2=A0

=C2=A0

=C2=A0

This assumes that the load on the system at the time= of the RPC

execution is somewhat known and stable. I am talking= about

the elapsed time measurement.

=C2=A0

The cleint can check the server's time-of-day ju= st by

reading the current-date-time object.=C2=A0 It does = not need

executed-at timestamps to check that the clocks are = in synch.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

We presented a few use-ca= ses at the IETF meeting in Berlin (http://www.ietf.org= /proceedings/87/slides/slides-87-netconf-1.pdf), and the Dallas presentation (https://www.ietf.org/p= roceedings/92/slides/slides-92-netconf-13.pdf), which was not presented= due to lack of time, included the network-wide commit use case.

=C2=A0

Cheers,<= /u>

Tal.

=C2=A0

=C2=A0

=C2=A0

Andy

=C2=A0

From: Netconf = [mailto:netco= nf-bounces@ietf.org] On Behalf Of Andy Bierman
Sent: Monday, June 29, 2015 8:27 PM
To: Juergen Schoenwaelder; Netconf
Subject: Re: [Netconf] [FOWARDING] Last Call: <draft-mm-netconf-t= ime-capability-05.txt> (Time Capability in NETCONF) to Experimental RFC<= /span>

=C2=A0

Hi,

=C2=A0

=C2=A0

Is this an AD-sponsored draft?

=C2=A0

This draft was "interesting" but not enoug= h to be prioritized ahead

of other work being done in the NETCONF WG.

=C2=A0

The draft mixes server measurement of RPC execution = time

with a "cron" function.=C2=A0 The rational= e for this grab-bag of

time-related functionality is not entirely clear.=

=C2=A0

This work does not have any consensus within the NET= CONF WG.

It does seem a little surprising that it is being pu= blished without

even asking the NETCONF WG for comments.

=C2=A0

I don't have any problem with Experimental RFCs = as long as it

is clear this is not a product of the NETCONF WG.=

=C2=A0

=C2=A0

=C2=A0

Andy

=C2=A0

=C2=A0

=C2=A0

On Mon, Jun 29, 2015 at 8:07 AM, Juergen Schoenwaeld= er <j.schoenwaelder@jacobs-university.de> wrote:

Hi,

just to make sure everybody here has seen this.

/js

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


---------- Forwarded message ----------
From:=C2=A0The IESG <iesg-secretary@ietf.org>
To:=C2=A0IETF-Announce <ietf-announce@ietf.org>
Cc:=C2=A0
Date:=C2=A0Mon, 29 Jun 2015 07:58:22 -0700
Subject:=C2=A0Last Call: <draft-mm-netconf-time-capability-05.txt> (T= ime Capability in NETCONF) to Experimental RFC

The IESG has received a request from an individual submitter to consider the following document:
- 'Time Capability in NETCONF'
=C2=A0 <draft-mm-netconf-time-capability-05.txt> as Experimental RFC<= br>
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailin= g lists by 2015-07-29. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


=C2=A0 =C2=A0This document defines a capability-based extension to the Netw= ork
=C2=A0 =C2=A0Configuration Protocol (NETCONF) that allows time-triggered =C2=A0 =C2=A0configuration and management operations. This extension allows=
=C2=A0 =C2=A0NETCONF clients to invoke configuration updates according to =C2=A0 =C2=A0scheduled times, and allows NETCONF servers to attach timestam= ps to
=C2=A0 =C2=A0the data they send to NETCONF clients.


The Network Configuration Protocol (NETCONF) Capability URNs registry
requires a standards action in order to populate the registry. This documen= t
was taken out of the ISE stream and brought forward as an AD sponsored
individual-submission to address this consideration.


The file can be obtained via
https://datatracker.ietf.org/doc/draft-mm-netconf-tim= e-capability/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-mm-netc= onf-time-capability/ballot/


No IPR declarations have been submitted directly on this I-D.



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

=C2=A0

=C2=A0

=C2=A0


--001a11346d9cc327b80519b75e9d-- From nobody Tue Jun 30 01:44:55 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0F561A1BC3; Tue, 30 Jun 2015 01:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WouuKbSkvpO6; Tue, 30 Jun 2015 01:44:51 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9301A1BDD; Tue, 30 Jun 2015 01:44:51 -0700 (PDT) Received: from localhost (h-85-24-195-9.na.cust.bahnhof.se [85.24.195.9]) by mail.tail-f.com (Postfix) with ESMTPSA id BBE2E1AE047F; Tue, 30 Jun 2015 10:44:49 +0200 (CEST) Date: Tue, 30 Jun 2015 10:44:49 +0200 (CEST) Message-Id: <20150630.104449.916352783153186338.mbj@tail-f.com> To: netconf@ietf.org, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <20150628.101115.524154870753102418.mbj@tail-f.com> References: <20150627.101927.980507351929498326.mbj@tail-f.com> <20150628.101115.524154870753102418.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Netconf] [netmod] Y45-04 and ietf-yang-library X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 08:44:52 -0000 Hi, Here's a short summary, and then some questions for the WG. The ietf-yang-library module is designed to serve two purposes: 1. A protocol-independent advertisement mechanism for YANG 1.1 modules. 2. A list of the YANG modules stored in a server. Q1. Do you agree with these goals? Q2. Should this module be designed to work with both YANG 1.0 and YANG 1.1 servers - i.e., should it have yang-version 1.1 or not? If it should not be defined using YANG 1.1, why is this module special? Q3. Should the /modules/module list be designed to store both YANG 1.0 and YANG 1.1 modules? Q4. Consider these modules, which both import foo without revision: module a { ... import foo; ... } module b { ... import foo; ... } Do we require a server that implements both a and b to use the same revision of foo? If the answer is yes, we need to indicate the default revision that the server uses in the model: container modules { ... list module { ... leaf default-revision { type boolean; default false; description "Indicates that this revision is used by the server if this module is imported without a specific revision date."; } } } If the answer is no, note that this puts an implementation burden on the client. A client cannot simply download all listed modules, and load/compile/process them as one set. If the anwser is no, I propose that we extend the module as such: container modules { ... list module { ... list imported-without-revision { key "name revision"; ... } } } A server could then list: a 2015-01-01 foo 2002-02-02 b 2015-01-01 foo 2001-01-01 /martin From nobody Tue Jun 30 02:06:06 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47CD41A1EED for ; Tue, 30 Jun 2015 02:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBURc2L7gHim for ; Tue, 30 Jun 2015 02:06:03 -0700 (PDT) Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [209.85.215.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 278F31A212A for ; Tue, 30 Jun 2015 02:05:49 -0700 (PDT) Received: by lagh6 with SMTP id h6so4970021lag.2 for ; Tue, 30 Jun 2015 02:05:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9cmj1Obu6dQhh5xQ2GAkto9Sa1ILVcnJcxJDQC7P+QM=; b=B04cxjJanlC0LARuaaYR/EHVczIq+axNb56krAha0KRD9GoWbtuktSDrGYeTN8fLTV PTmNVYG8Gg2GP4rrmR0InbkIozWkUmNK6QLkoJIgoKg2UFGIIBy8PkiudrkW4LEc4Ukv LF0mDXlo+IpmF4dzCLRn8ew6OTd36jR7wEIS1lT6OpY5SAiMT8BrvAKdhnvGwWaLtGww jBR7TUwnPkM9SrRwTN3k4nSWjfZhp0depzY0sJvl+f7WSP3OqoZ5Dvs70NqX+QgdY84n QurR7r6gPHh3WRigFxE/W7GmHVkAKE4GghlsC/x7uOClE9UmYVQrOrzK4GwsP+1zRkNn FiJg== X-Gm-Message-State: ALoCoQlYAdhir77HYxJB75qBEnzZofz6+ZUGD9SOUN0fqIk2IqxI8dRTfgt1bSOeovGDp6UJdchp MIME-Version: 1.0 X-Received: by 10.112.164.66 with SMTP id yo2mr694972lbb.33.1435655147722; Tue, 30 Jun 2015 02:05:47 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Tue, 30 Jun 2015 02:05:47 -0700 (PDT) In-Reply-To: <20150630.104449.916352783153186338.mbj@tail-f.com> References: <20150627.101927.980507351929498326.mbj@tail-f.com> <20150628.101115.524154870753102418.mbj@tail-f.com> <20150630.104449.916352783153186338.mbj@tail-f.com> Date: Tue, 30 Jun 2015 02:05:47 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11c32d5c19b6620519b883cb Archived-At: Cc: Netconf , "netmod@ietf.org" Subject: Re: [Netconf] [netmod] Y45-04 and ietf-yang-library X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 09:06:05 -0000 --001a11c32d5c19b6620519b883cb Content-Type: text/plain; charset=UTF-8 On Tue, Jun 30, 2015 at 1:44 AM, Martin Bjorklund wrote: > Hi, > > Here's a short summary, and then some questions for the WG. > > The ietf-yang-library module is designed to serve two purposes: > > 1. A protocol-independent advertisement mechanism for YANG 1.1 > modules. > > 2. A list of the YANG modules stored in a server. > > > Q1. Do you agree with these goals? > > > Q2. Should this module be designed to work with both YANG 1.0 and > YANG 1.1 servers - i.e., should it have yang-version 1.1 or not? > > If it should not be defined using YANG 1.1, why is this module > special? > > What does 'special' mean here? Can you identify a YANG 1.1 statement that this module needs? > > Q3. Should the /modules/module list be designed to store both YANG > 1.0 and YANG 1.1 modules? > > Do you have some reason why YANG 1.0 files should be excluded? > > Q4. Consider these modules, which both import foo without revision: > > module a { ... import foo; ... } > module b { ... import foo; ... } > > Do we require a server that implements both a and b to use the > same revision of foo? > > If the answer is yes, we need to indicate the default revision > that the server uses in the model: > > container modules { > ... > list module { > ... > leaf default-revision { > type boolean; > default false; > description > "Indicates that this revision is used by the server if > this module is imported without a specific revision > date."; > } > } > } > > If the answer is no, note that this puts an implementation burden > on the client. A client cannot simply download all listed > modules, and load/compile/process them as one set. > > If the anwser is no, I propose that we extend the module as such: > > container modules { > ... > list module { > ... > list imported-without-revision { > key "name revision"; > ... > } > } > } > > I do not think this change is needed > A server could then list: > > > a > 2015-01-01 > > foo > 2002-02-02 > > > > b > 2015-01-01 > > foo > 2001-01-01 > > > > > YANG 1.0 and current 1.1 says that if no revision-date is used, then the client does not know the version and the server is not required to pick any specific version. Your proposal seems to be that the library will fill in all the revision-dates and reproduce the import-tree. It makes more sense to make import-by-revision mandatory. But IMO this is not a real problem so there is no point in this solution. > > /martin > > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a11c32d5c19b6620519b883cb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jun 30, 2015 at 1:44 AM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Hi,

Here's a short summary, and then some questions for the WG.

The ietf-yang-library module is designed to serve two purposes:

=C2=A0 1.=C2=A0 A protocol-independent advertisement mechanism for YANG 1.1=
=C2=A0 =C2=A0 =C2=A0 modules.

=C2=A0 2.=C2=A0 A list of the YANG modules stored in a server.


Q1.=C2=A0 Do you agree with these goals?


Q2.=C2=A0 Should this module be designed to work with both YANG 1.0 and
=C2=A0 =C2=A0 =C2=A0YANG 1.1 servers - i.e., should it have yang-version 1.= 1 or not?

=C2=A0 =C2=A0 =C2=A0If it should not be defined using YANG 1.1, why is this= module
=C2=A0 =C2=A0 =C2=A0special?



What does 'special&= #39; mean here?
Can you identify a YANG 1.1 statement that this m= odule needs?
=C2=A0

Q3.=C2=A0 Should the /modules/module list be designed to store both YANG =C2=A0 =C2=A0 =C2=A01.0 and YANG 1.1 modules?


Do you have some reason why YANG 1.0 f= iles should be excluded?
=C2=A0

Q4.=C2=A0 Consider these modules, which both import foo without revision:
=C2=A0 =C2=A0 =C2=A0 =C2=A0module a { ... import foo; ... }
=C2=A0 =C2=A0 =C2=A0 =C2=A0module b { ... import foo; ... }

=C2=A0 =C2=A0 =C2=A0Do we require a server that implements both a and b to = use the
=C2=A0 =C2=A0 =C2=A0same revision of foo?

=C2=A0 =C2=A0 =C2=A0If the answer is yes, we need to indicate the default r= evision
=C2=A0 =C2=A0 =C2=A0that the server uses in the model:

=C2=A0 =C2=A0 =C2=A0 =C2=A0container modules {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0list module {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf default-revision {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type boolean;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0default false;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Indicates that= this revision is used by the server if
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 this module is impo= rted without a specific revision
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 date.";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0 =C2=A0}

=C2=A0 =C2=A0 =C2=A0If the answer is no, note that this puts an implementat= ion burden
=C2=A0 =C2=A0 =C2=A0on the client.=C2=A0 A client cannot simply download al= l listed
=C2=A0 =C2=A0 =C2=A0modules, and load/compile/process them as one set.

=C2=A0 =C2=A0 =C2=A0If the anwser is no, I propose that we extend the modul= e as such:

=C2=A0 =C2=A0 =C2=A0 =C2=A0container modules {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0list module {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0list imported-without-revision { =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0key "name revision&quo= t;;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0 =C2=A0}


I do not think this change is needed
=C2=A0
=C2=A0 =C2=A0 =C2=A0A server could then list:

=C2=A0 =C2=A0 =C2=A0 <module>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <name>a</name>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <revision>2015-01-01</revision>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <imported-without-revision>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <name>foo</name>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <revision>2002-02-02</revision&= gt;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 </imported-without-revision>
=C2=A0 =C2=A0 =C2=A0 </module>
=C2=A0 =C2=A0 =C2=A0 <module>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <name>b</name>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <revision>2015-01-01</revision>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <imported-without-revision>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <name>foo</name>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <revision>2001-01-01</revision&= gt;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 </imported-without-revision>
=C2=A0 =C2=A0 =C2=A0 </module>



YANG 1.0 and current 1.1 says that if = no revision-date is used,
then the client does not know the versi= on and the
server is not required to pick any specific version.

Your proposal seems to be that the library will fil= l in all the revision-dates
and reproduce the import-tree.=C2=A0 = It makes more sense to make
import-by-revision mandatory.=C2=A0 B= ut IMO this is not a real
problem so there is no point in this so= lution.


=C2=A0

/martin



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

--001a11c32d5c19b6620519b883cb-- From nobody Tue Jun 30 02:16:55 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7C1F1A21BF; Tue, 30 Jun 2015 02:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0p3l_mXhtNY; Tue, 30 Jun 2015 02:16:50 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 230A91A1EF4; Tue, 30 Jun 2015 02:16:50 -0700 (PDT) Received: from localhost (h-85-24-195-9.na.cust.bahnhof.se [85.24.195.9]) by mail.tail-f.com (Postfix) with ESMTPSA id 6E25D1AE047F; Tue, 30 Jun 2015 11:16:48 +0200 (CEST) Date: Tue, 30 Jun 2015 11:16:48 +0200 (CEST) Message-Id: <20150630.111648.1303614349753408672.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20150628.101115.524154870753102418.mbj@tail-f.com> <20150630.104449.916352783153186338.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [Netconf] [netmod] Y45-04 and ietf-yang-library X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 09:16:52 -0000 Andy Bierman wrote: > On Tue, Jun 30, 2015 at 1:44 AM, Martin Bjorklund wrote: > > > Hi, > > > > Here's a short summary, and then some questions for the WG. > > > > The ietf-yang-library module is designed to serve two purposes: > > > > 1. A protocol-independent advertisement mechanism for YANG 1.1 > > modules. > > > > 2. A list of the YANG modules stored in a server. > > > > > > Q1. Do you agree with these goals? > > > > > > Q2. Should this module be designed to work with both YANG 1.0 and > > YANG 1.1 servers - i.e., should it have yang-version 1.1 or not? > > > > If it should not be defined using YANG 1.1, why is this module > > special? > > > > > > What does 'special' mean here? Special in the sense that going forward, I assume all modules published by the IETF will be YANG 1.1. > Can you identify a YANG 1.1 statement that this module needs? No. > > Q3. Should the /modules/module list be designed to store both YANG > > 1.0 and YANG 1.1 modules? > > > > > Do you have some reason why YANG 1.0 files should be excluded? No, but if this module is supposed to be used for advertising 1.1 modules, why store 1.0 modules here? Also, the description statements will have to reflect the fact that some things don't apply to 1.0 modules (like conformance). > > Q4. Consider these modules, which both import foo without revision: > > > > module a { ... import foo; ... } > > module b { ... import foo; ... } > > > > Do we require a server that implements both a and b to use the > > same revision of foo? > > > > If the answer is yes, we need to indicate the default revision > > that the server uses in the model: > > > > container modules { > > ... > > list module { > > ... > > leaf default-revision { > > type boolean; > > default false; > > description > > "Indicates that this revision is used by the server if > > this module is imported without a specific revision > > date."; > > } > > } > > } > > > > If the answer is no, note that this puts an implementation burden > > on the client. A client cannot simply download all listed > > modules, and load/compile/process them as one set. > > > > If the anwser is no, I propose that we extend the module as such: > > > > container modules { > > ... > > list module { > > ... > > list imported-without-revision { > > key "name revision"; > > ... > > } > > } > > } > > > > > I do not think this change is needed > > > > A server could then list: > > > > > > a > > 2015-01-01 > > > > foo > > 2002-02-02 > > > > > > > > b > > 2015-01-01 > > > > foo > > 2001-01-01 > > > > > > > > > > > YANG 1.0 and current 1.1 says that if no revision-date is used, > then the client does not know the version and the > server is not required to pick any specific version. > > Your proposal seems to be that the library will fill in all the > revision-dates > and reproduce the import-tree. Yes. /martin > It makes more sense to make > import-by-revision mandatory. But IMO this is not a real > problem so there is no point in this solution. > > > > > > > > /martin > > > > > > Andy > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > From nobody Tue Jun 30 02:56:07 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0D7B1A8718; Tue, 30 Jun 2015 02:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7U0QmAr9Gb9; Tue, 30 Jun 2015 02:56:03 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 294E81A8714; Tue, 30 Jun 2015 02:56:03 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 40F851CC0450; Tue, 30 Jun 2015 11:56:05 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund , netconf@ietf.org, netmod@ietf.org In-Reply-To: <20150630.104449.916352783153186338.mbj@tail-f.com> References: <20150627.101927.980507351929498326.mbj@tail-f.com> <20150628.101115.524154870753102418.mbj@tail-f.com> <20150630.104449.916352783153186338.mbj@tail-f.com> User-Agent: Notmuch/0.19 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Tue, 30 Jun 2015 11:56:02 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Netconf] [netmod] Y45-04 and ietf-yang-library X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 09:56:05 -0000 Martin Bjorklund writes: > Hi, > > Here's a short summary, and then some questions for the WG. > > The ietf-yang-library module is designed to serve two purposes: > > 1. A protocol-independent advertisement mechanism for YANG 1.1 > modules. > > 2. A list of the YANG modules stored in a server. Is this used by "get-schema" or for something else? > > > Q1. Do you agree with these goals? I think it should be only #1, if it is going to be the only way for advertising YANG modules. A server may just implement the modules without storing them. (But maybe I misunderstood the purpose of #2.) > > > Q2. Should this module be designed to work with both YANG 1.0 and > YANG 1.1 servers - i.e., should it have yang-version 1.1 or not? > > If it should not be defined using YANG 1.1, why is this module > special? > Hmm, it depends on what a 1.0 client is expected to do when encountering 1.1 modules. This is probably not specified in 6020bis. (?) > > Q3. Should the /modules/module list be designed to store both YANG > 1.0 and YANG 1.1 modules? > Yes. > > Q4. Consider these modules, which both import foo without revision: > > module a { ... import foo; ... } > module b { ... import foo; ... } > > Do we require a server that implements both a and b to use the > same revision of foo? > > If the answer is yes, we need to indicate the default revision > that the server uses in the model: > > container modules { > ... > list module { > ... > leaf default-revision { > type boolean; > default false; > description > "Indicates that this revision is used by the server if > this module is imported without a specific revision > date."; > } > } > } > > If the answer is no, note that this puts an implementation burden > on the client. A client cannot simply download all listed > modules, and load/compile/process them as one set. > > If the anwser is no, I propose that we extend the module as such: I'd vote for this option. A server implementor might need to use an old revision of a grouping/typedef in one subsystem and a new revision in another. Lada > > container modules { > ... > list module { > ... > list imported-without-revision { > key "name revision"; > ... > } > } > } > > A server could then list: > > > a > 2015-01-01 > > foo > 2002-02-02 > > > > b > 2015-01-01 > > foo > 2001-01-01 > > > > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jun 30 05:45:13 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 299E61A8F3B; Tue, 30 Jun 2015 05:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6QCOEA6SddI; Tue, 30 Jun 2015 05:45:08 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 492561A8F34; Tue, 30 Jun 2015 05:45:08 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8D1C313DB; Tue, 30 Jun 2015 14:45:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id WHL7b1_nDmE6; Tue, 30 Jun 2015 14:45:05 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 30 Jun 2015 14:45:04 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1F4E220013; Tue, 30 Jun 2015 14:45:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id HsYJrwq72NKj; Tue, 30 Jun 2015 14:45:04 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EA9F22002C; Tue, 30 Jun 2015 14:45:03 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C5FBC34E62EC; Tue, 30 Jun 2015 14:45:03 +0200 (CEST) Date: Tue, 30 Jun 2015 14:45:03 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20150630124503.GA5406@elstar.local> Mail-Followup-To: Martin Bjorklund , netconf@ietf.org, netmod@ietf.org References: <20150627.101927.980507351929498326.mbj@tail-f.com> <20150628.101115.524154870753102418.mbj@tail-f.com> <20150630.104449.916352783153186338.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150630.104449.916352783153186338.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [Netconf] [netmod] Y45-04 and ietf-yang-library X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 12:45:11 -0000 Writing as technical contributor... On Tue, Jun 30, 2015 at 10:44:49AM +0200, Martin Bjorklund wrote: > Hi, > > Here's a short summary, and then some questions for the WG. > > The ietf-yang-library module is designed to serve two purposes: > > 1. A protocol-independent advertisement mechanism for YANG 1.1 > modules. > > 2. A list of the YANG modules stored in a server. > > > Q1. Do you agree with these goals? I primarily care about goal 1. > Q2. Should this module be designed to work with both YANG 1.0 and > YANG 1.1 servers - i.e., should it have yang-version 1.1 or not? > > If it should not be defined using YANG 1.1, why is this module > special? I assume this module will sooner or later be YANG 1.1 anyway. > Q3. Should the /modules/module list be designed to store both YANG > 1.0 and YANG 1.1 modules? Yes. Even if YANG 1.1 hits the street tomorrow, we will not have revised all published YANG data models that were written using YANG 1.0. So a server needs to be able to announce both YANG 1.0 and YANG 1.1 modules. > Q4. Consider these modules, which both import foo without revision: > > module a { ... import foo; ... } > module b { ... import foo; ... } > > Do we require a server that implements both a and b to use the > same revision of foo? > > If the answer is yes, we need to indicate the default revision > that the server uses in the model: > > container modules { > ... > list module { > ... > leaf default-revision { > type boolean; > default false; > description > "Indicates that this revision is used by the server if > this module is imported without a specific revision > date."; > } > } > } > > If the answer is no, note that this puts an implementation burden > on the client. A client cannot simply download all listed > modules, and load/compile/process them as one set. > > If the anwser is no, I propose that we extend the module as such: > > container modules { > ... > list module { > ... > list imported-without-revision { > key "name revision"; > ... > } > } > } > > A server could then list: > > > a > 2015-01-01 > > foo > 2002-02-02 > > > > b > 2015-01-01 > > foo > 2001-01-01 > > I believe truth is advertisement is a good thing. In the SNMP world, not all pieces of the instrumentation were moving at the same pace and I would be somewhat surprised if this would be the case for all implementations in the NETCONF world. Hence, I rather accept that an import of foo without revision may resolve to different versions of foo for different imports. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Jun 30 05:45:38 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9968C1A8BBD; Tue, 30 Jun 2015 05:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPfUJjfAEoCV; Tue, 30 Jun 2015 05:45:31 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 467051A8F40; Tue, 30 Jun 2015 05:45:28 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 812321AE047F; Tue, 30 Jun 2015 14:45:26 +0200 (CEST) Date: Tue, 30 Jun 2015 14:46:13 +0200 (CEST) Message-Id: <20150630.144613.434177163718632086.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <20150628.101115.524154870753102418.mbj@tail-f.com> <20150630.104449.916352783153186338.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [Netconf] [netmod] Y45-04 and ietf-yang-library X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 12:45:35 -0000 Ladislav Lhotka wrote: > Martin Bjorklund writes: > > > Hi, > > > > Here's a short summary, and then some questions for the WG. > > > > The ietf-yang-library module is designed to serve two purposes: > > > > 1. A protocol-independent advertisement mechanism for YANG 1.1 > > modules. > > > > 2. A list of the YANG modules stored in a server. > > Is this used by "get-schema" or for something else? Andy might be able to explain this requirement. My personal view is that ietf-yang-library should do #1 only. /martin > > Q1. Do you agree with these goals? > > I think it should be only #1, if it is going to be the only way for > advertising YANG modules. A server may just implement the modules > without storing them. (But maybe I misunderstood the purpose of #2.) > > > > > > > Q2. Should this module be designed to work with both YANG 1.0 and > > YANG 1.1 servers - i.e., should it have yang-version 1.1 or not? > > > > If it should not be defined using YANG 1.1, why is this module > > special? > > > > Hmm, it depends on what a 1.0 client is expected to do when encountering > 1.1 modules. This is probably not specified in 6020bis. (?) > > > > > > Q3. Should the /modules/module list be designed to store both YANG > > 1.0 and YANG 1.1 modules? > > > > Yes. > > > > > Q4. Consider these modules, which both import foo without revision: > > > > module a { ... import foo; ... } > > module b { ... import foo; ... } > > > > Do we require a server that implements both a and b to use the > > same revision of foo? > > > > If the answer is yes, we need to indicate the default revision > > that the server uses in the model: > > > > container modules { > > ... > > list module { > > ... > > leaf default-revision { > > type boolean; > > default false; > > description > > "Indicates that this revision is used by the server if > > this module is imported without a specific revision > > date."; > > } > > } > > } > > > > If the answer is no, note that this puts an implementation burden > > on the client. A client cannot simply download all listed > > modules, and load/compile/process them as one set. > > > > If the anwser is no, I propose that we extend the module as such: > > I'd vote for this option. A server implementor might need to use an old > revision of a grouping/typedef in one subsystem and a new revision in > another. > > Lada > > > > > container modules { > > ... > > list module { > > ... > > list imported-without-revision { > > key "name revision"; > > ... > > } > > } > > } > > > > A server could then list: > > > > > > a > > 2015-01-01 > > > > foo > > 2002-02-02 > > > > > > > > b > > 2015-01-01 > > > > foo > > 2001-01-01 > > > > > > > > > > > > /martin > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > From nobody Tue Jun 30 07:17:09 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6444C1A9008 for ; Tue, 30 Jun 2015 07:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9M7P1MLxCBP for ; Tue, 30 Jun 2015 07:17:01 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E6541A9024 for ; Tue, 30 Jun 2015 07:16:31 -0700 (PDT) Received: by lagc2 with SMTP id c2so15370414lag.3 for ; Tue, 30 Jun 2015 07:16:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+E+Fk5O26dbYS8fClizu/ILE09I2XG3YMkui7q9n44g=; b=aERVhAu++ZSCy5M8vopiO7nfLEh1GqomD16BsljTAcjh8xW6xpwAjmsiG54GhnueuS 61arEIBN5ghwnAi4UouFTqj48ObIK8Wpil/QQYW5oKTw6KCvlgSERnXX3tB2oXQNngig XvE4acmI148BP4sNxo9t7Kgg3sPZvUJZzmEEHV8OjUNsU6f760bomVyXB1PEuKTwipdJ J5Vx4pMRWy128x5EBKjLkzHcFtkmXXV4IE2QX/n/pap0eF4dQAOXp4MozmoPBZx+5Loi cERjCZMc6UicBnclMxJB7dU43uM8mKWDUoNf65fkrdTflYlvjHErk+6oPgY2z/gFXgQk kHVA== X-Gm-Message-State: ALoCoQmPkcgbeC3FQcArsI3iDulaWUYorAoH8HRO9Z3SinABHRRGBtjbRZRHewrbOQpbE5OlGk6i MIME-Version: 1.0 X-Received: by 10.112.55.207 with SMTP id u15mr19943965lbp.88.1435673789889; Tue, 30 Jun 2015 07:16:29 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Tue, 30 Jun 2015 07:16:29 -0700 (PDT) In-Reply-To: <20150630.144613.434177163718632086.mbj@tail-f.com> References: <20150628.101115.524154870753102418.mbj@tail-f.com> <20150630.104449.916352783153186338.mbj@tail-f.com> <20150630.144613.434177163718632086.mbj@tail-f.com> Date: Tue, 30 Jun 2015 07:16:29 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a113403d842972a0519bcdae8 Archived-At: Cc: "netmod@ietf.org" , Netconf Subject: Re: [Netconf] [netmod] Y45-04 and ietf-yang-library X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 14:17:07 -0000 --001a113403d842972a0519bcdae8 Content-Type: text/plain; charset=UTF-8 On Tue, Jun 30, 2015 at 5:46 AM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: > > Martin Bjorklund writes: > > > > > Hi, > > > > > > Here's a short summary, and then some questions for the WG. > > > > > > The ietf-yang-library module is designed to serve two purposes: > > > > > > 1. A protocol-independent advertisement mechanism for YANG 1.1 > > > modules. > > > > > > 2. A list of the YANG modules stored in a server. > > > > Is this used by "get-schema" or for something else? > > Andy might be able to explain this requirement. > > My personal view is that ietf-yang-library should do #1 only. > > #2 is to support easy retrieval of all types of YANG files. The types of YANG files can be identified (unlike the schema list) so a subset of files can be retrieved if needed. The 'schema' list does not support submodules or deviation files. No YANG file types can be identified with the 'schema' list. It is useful to be able to retrieve the YANG files without having to parse them first. This allows modular implementation. The "schema" list is optional to implement so a client cannot rely on it . Only the YANG library is mandatory to implement for RESTCONF and CoMI. Since storage of the YANG files is expensive for constrained devices, it is very useful to support a server which contains all the YANG files for lots of device types. (the conformance=none enumeration supports this mode) There is no harm whatsoever in allowing multiple revisions from appearing in the library. I don't really understand why this is a problem. > > /martin > Andy > > > > > Q1. Do you agree with these goals? > > > > I think it should be only #1, if it is going to be the only way for > > advertising YANG modules. A server may just implement the modules > > without storing them. (But maybe I misunderstood the purpose of #2.) > > > > > > > > > > > Q2. Should this module be designed to work with both YANG 1.0 and > > > YANG 1.1 servers - i.e., should it have yang-version 1.1 or not? > > > > > > If it should not be defined using YANG 1.1, why is this module > > > special? > > > > > > > Hmm, it depends on what a 1.0 client is expected to do when encountering > > 1.1 modules. This is probably not specified in 6020bis. (?) > > > > > > > > > > Q3. Should the /modules/module list be designed to store both YANG > > > 1.0 and YANG 1.1 modules? > > > > > > > Yes. > > > > > > > > Q4. Consider these modules, which both import foo without revision: > > > > > > module a { ... import foo; ... } > > > module b { ... import foo; ... } > > > > > > Do we require a server that implements both a and b to use the > > > same revision of foo? > > > > > > If the answer is yes, we need to indicate the default revision > > > that the server uses in the model: > > > > > > container modules { > > > ... > > > list module { > > > ... > > > leaf default-revision { > > > type boolean; > > > default false; > > > description > > > "Indicates that this revision is used by the server if > > > this module is imported without a specific revision > > > date."; > > > } > > > } > > > } > > > > > > If the answer is no, note that this puts an implementation burden > > > on the client. A client cannot simply download all listed > > > modules, and load/compile/process them as one set. > > > > > > If the anwser is no, I propose that we extend the module as such: > > > > I'd vote for this option. A server implementor might need to use an old > > revision of a grouping/typedef in one subsystem and a new revision in > > another. > > > > Lada > > > > > > > > container modules { > > > ... > > > list module { > > > ... > > > list imported-without-revision { > > > key "name revision"; > > > ... > > > } > > > } > > > } > > > > > > A server could then list: > > > > > > > > > a > > > 2015-01-01 > > > > > > foo > > > 2002-02-02 > > > > > > > > > > > > b > > > 2015-01-01 > > > > > > foo > > > 2001-01-01 > > > > > > > > > > > > > > > > > > /martin > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a113403d842972a0519bcdae8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jun 30, 2015 at 5:46 AM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Ladislav Lhotka <lhotka@nic.cz> wrote:
> Martin Bjorklund <mbj@tail-f.com<= /a>> writes:
>
> > Hi,
> >
> > Here's a short summary, and then some questions for the WG. > >
> > The ietf-yang-library module is designed to serve two purposes: > >
> >=C2=A0 =C2=A01.=C2=A0 A protocol-independent advertisement mechani= sm for YANG 1.1
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0modules.
> >
> >=C2=A0 =C2=A02.=C2=A0 A list of the YANG modules stored in a serve= r.
>
> Is this used by "get-schema" or for something else?

Andy might be able to explain this requirement.

My personal view is that ietf-yang-library should do #1 only.










/martin




> > Q1.=C2=A0 Do you agree with these goals?
>
> I think it should be only #1, if it is going to be the only way for > advertising YANG modules. A server may just implement the modules
> without storing them. (But maybe I misunderstood the purpose of #2.) >
> >
> >
> > Q2.=C2=A0 Should this module be designed to work with both YANG 1= .0 and
> >=C2=A0 =C2=A0 =C2=A0 YANG 1.1 servers - i.e., should it have yang-= version 1.1 or not?
> >
> >=C2=A0 =C2=A0 =C2=A0 If it should not be defined using YANG 1.1, w= hy is this module
> >=C2=A0 =C2=A0 =C2=A0 special?
> >
>
> Hmm, it depends on what a 1.0 client is expected to do when encounteri= ng
> 1.1 modules. This is probably not specified in 6020bis. (?)
>
>
> >
> > Q3.=C2=A0 Should the /modules/module list be designed to store bo= th YANG
> >=C2=A0 =C2=A0 =C2=A0 1.0 and YANG 1.1 modules?
> >
>
> Yes.
>
> >
> > Q4.=C2=A0 Consider these modules, which both import foo without r= evision:
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 module a { ... import foo; ... }
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 module b { ... import foo; ... }
> >
> >=C2=A0 =C2=A0 =C2=A0 Do we require a server that implements both a= and b to use the
> >=C2=A0 =C2=A0 =C2=A0 same revision of foo?
> >
> >=C2=A0 =C2=A0 =C2=A0 If the answer is yes, we need to indicate the= default revision
> >=C2=A0 =C2=A0 =C2=A0 that the server uses in the model:
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 container modules {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 list module {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf default-revision {<= br> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type boolean;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 default false; > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Indi= cates that this revision is used by the server if
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this= module is imported without a specific revision
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0date= .";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> >
> >=C2=A0 =C2=A0 =C2=A0 If the answer is no, note that this puts an i= mplementation burden
> >=C2=A0 =C2=A0 =C2=A0 on the client.=C2=A0 A client cannot simply d= ownload all listed
> >=C2=A0 =C2=A0 =C2=A0 modules, and load/compile/process them as one= set.
> >
> >=C2=A0 =C2=A0 =C2=A0 If the anwser is no, I propose that we extend= the module as such:
>
> I'd vote for this option. A server implementor might need to use a= n old
> revision of a grouping/typedef in one subsystem and a new revision in<= br> > another.
>
> Lada
>
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 container modules {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 list module {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 list imported-without-re= vision {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 key "name re= vision";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> >
> >=C2=A0 =C2=A0 =C2=A0 A server could then list:
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0<module>
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>a</name>
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<revision>2015-01-01</r= evision>
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<imported-without-revision>= ;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>foo</name&= gt;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<revision>2002-02-0= 2</revision>
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</imported-without-revision&g= t;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0</module>
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0<module>
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>b</name>
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<revision>2015-01-01</r= evision>
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<imported-without-revision>= ;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>foo</name&= gt;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<revision>2001-01-0= 1</revision>
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</imported-without-revision&g= t;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0</module>
> >
> >
> >
> > /martin
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>

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

--001a113403d842972a0519bcdae8-- From nobody Tue Jun 30 10:11:29 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F951AD374; Tue, 30 Jun 2015 10:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugkvjCNEKFup; Tue, 30 Jun 2015 10:11:22 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (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 8CA171AD355; Tue, 30 Jun 2015 10:11:21 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.15.1/8.15.1) with ESMTPS id t5UHBDDB014649 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 30 Jun 2015 17:11:13 GMT Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t5UHBCTK029335 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Jun 2015 19:11:13 +0200 Received: from DEMUHTC007.nsn-intra.net (10.159.42.38) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 30 Jun 2015 19:11:12 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.53]) by DEMUHTC007.nsn-intra.net ([10.159.42.38]) with mapi id 14.03.0235.001; Tue, 30 Jun 2015 19:11:12 +0200 From: "Ersue, Mehmet (Nokia - DE/Munich)" To: ext Joe Clarke , "Romascanu, Dan (Dan)" , "ietf@ietf.org" Thread-Topic: [Netconf] Last Call: (Time Capability in NETCONF) to Experimental RFC Thread-Index: AQHQsnwZ8VMhG5B+QkSHejS8k3Acip3Dr38w///o2gCAAa+3UA== Date: Tue, 30 Jun 2015 17:11:11 +0000 Message-ID: References: <20150629145822.7722.8876.idtracker@ietfa.amsl.com> <9904FB1B0159DA42B0B887B7FA8119CA5CA78C61@AZ-FFEXMB04.global.avaya.com> <55917D92.5050604@cisco.com> In-Reply-To: <55917D92.5050604@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.115] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 4599 X-purgate-ID: 151667::1435684273-000058F0-55589F8E/0/0 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Last Call: (Time Capability in NETCONF) to Experimental RFC X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 17:11:28 -0000 Dear Joe, an individual draft cannot be adopted by a WG if there is no measurable sup= port on the maillist. As such Netconf co-chairs asked Tal Mizrahi in April to demonstrate such su= pport. Where have you been as Tal was asking on the maillist people to state their= support on his draft by saying: "Feedbacks will be welcome. Even short feedbacks such as "I think this draft is useful" will be welcome= ." Unfortunately there was no response to Tal's mail on April 15, 2015. Mehmet=20 -----Original Message----- From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Joe Clarke Sent: Monday, June 29, 2015 7:17 PM To: Romascanu, Dan (Dan); ietf@ietf.org Cc: netconf@ietf.org; lmap@ietf.org Subject: Re: [Netconf] Last Call: = (Time Capability in NETCONF) to Experimental RFC On 6/29/15 12:49, Romascanu, Dan (Dan) wrote: > (I apologize for cross-posting) but it seems justified in this case) > > I find this work useful. As do I. I remember the when this was first presented in Berlin. I=20 thought it had value. > > I have two questions: > - why was not this document adopted by the NETCONF WG? Lack of time, out = of focus, or are there any other (technical?) reasons? Why did it had to go= on AD-sponsored and Experimental track? I'll speak from what I saw. There didn't seem to be a lot of traction=20 on the WG list, but I do feel this would be beneficial as a working=20 group item. Joe > - This work may potentially be useful for LMAP which has scheduling and t= ime-stamping features in its architecture and framework. LMAP however just = selected RESTCONF as their preferred protocol. What would it take to extend= this work to RESTCONF)? (may be another piece of work) > > Thanks and Regards, > > Dan > > >> -----Original Message----- >> From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf Of >> The IESG >> Sent: Monday, June 29, 2015 5:58 PM >> To: IETF-Announce >> Subject: Last Call: (Time >> Capability in NETCONF) to Experimental RFC >> >> >> The IESG has received a request from an individual submitter to consider= the >> following document: >> - 'Time Capability in NETCONF' >> as Experimental RFC >> >> The IESG plans to make a decision in the next few weeks, and solicits fi= nal >> comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2015-07-29. Exceptionally, comments may b= e >> sent to iesg@ietf.org instead. In either case, please retain the beginni= ng of >> the Subject line to allow automated sorting. >> >> Abstract >> >> >> This document defines a capability-based extension to the Network >> Configuration Protocol (NETCONF) that allows time-triggered >> configuration and management operations. This extension allows >> NETCONF clients to invoke configuration updates according to >> scheduled times, and allows NETCONF servers to attach timestamps to >> the data they send to NETCONF clients. >> >> >> The Network Configuration Protocol (NETCONF) Capability URNs registry >> requires a standards action in order to populate the registry. This docu= ment >> was taken out of the ISE stream and brought forward as an AD sponsored >> individual-submission to address this consideration. >> >> >> The file can be obtained via >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >> 3A__datatracker.ietf.org_doc_draft-2Dmm-2Dnetconf-2Dtime- >> 2Dcapability_&d=3DAwICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNX >> CJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DeIbq6OXE65r_w9lwmd5WrktViMncM >> zhCDjk3tyjnVvU&s=3DB6e1FBSZH9H- >> OYAnRMYEgTJVYQ6SSqa2K9XpuIyx3mI&e=3D >> >> IESG discussion can be tracked via >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >> 3A__datatracker.ietf.org_doc_draft-2Dmm-2Dnetconf-2Dtime- >> 2Dcapability_ballot_&d=3DAwICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR3 >> 1OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DeIbq6OXE65r_w9lwmd5WrktVi >> MncMzhCDjk3tyjnVvU&s=3DWbISmWkVGVo43riTMHY7kzIkAREkQrB2aq- >> lyYOad-Y&e=3D >> >> >> No IPR declarations have been submitted directly on this I-D. >> > > _______________________________________________ > 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 Jun 30 10:29:00 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89C6D1A9117; Tue, 30 Jun 2015 10:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkcD5ojWKDwd; Tue, 30 Jun 2015 10:28:57 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77C8E1A90A6; Tue, 30 Jun 2015 10:28:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4905; q=dns/txt; s=iport; t=1435685337; x=1436894937; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=pGXXfXn5VGqVXct53QAq9R9A4kn56Y0bo7L8VbpTWdg=; b=IW5TlNPpRH1OVZmpJ9bAOxwBqzZttjqqSFQWcFi4H2eBJtyfiHijhLJI hGx27Z2qDcpahdIjzE2sg//0QcfpKxKdFpuyGwYC5Bnh3TTPpewFteEeU 9NapQlXL10DSIJTQwgdpZK1VvntfoYIY0OnEjewb5lSio8W52DwONTe67 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CnAwB20ZJV/4ENJK1bgxFUX71DCYFhCoUuSgKBUTgUAQEBAQEBAYEKhCIBAQEDAQEBATU2CwwECxEBAwEBAQkaBAcPAhYfAwYIBgEMAQUCAQGIIwgNyHEBAQEBAQEBAQEBAQEBAQEBAQEBAQETBItKhDQBAR0zBwaEJQEElAeEWoJZhCSBOoQSgmuQBiZjgSkcFYFZIjGBDIE8AQEB X-IronPort-AV: E=Sophos;i="5.15,379,1432598400"; d="scan'208";a="164261532" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-6.cisco.com with ESMTP; 30 Jun 2015 17:28:56 +0000 Received: from [10.150.55.108] (dhcp-10-150-55-108.cisco.com [10.150.55.108]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t5UHStnE018851; Tue, 30 Jun 2015 17:28:56 GMT Message-ID: <5592D1D7.70203@cisco.com> Date: Tue, 30 Jun 2015 13:28:55 -0400 From: Joe Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Ersue, Mehmet (Nokia - DE/Munich)" , "Romascanu, Dan (Dan)" , "ietf@ietf.org" References: <20150629145822.7722.8876.idtracker@ietfa.amsl.com> <9904FB1B0159DA42B0B887B7FA8119CA5CA78C61@AZ-FFEXMB04.global.avaya.com> <55917D92.5050604@cisco.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Last Call: (Time Capability in NETCONF) to Experimental RFC X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 17:28:59 -0000 On 6/30/15 13:11, Ersue, Mehmet (Nokia - DE/Munich) wrote: > Dear Joe, > > an individual draft cannot be adopted by a WG if there is no measurable support on the maillist. > As such Netconf co-chairs asked Tal Mizrahi in April to demonstrate such support. > > Where have you been as Tal was asking on the maillist people to state their support on his draft by saying: > > "Feedbacks will be welcome. > Even short feedbacks such as "I think this draft is useful" will be welcome." > > Unfortunately there was no response to Tal's mail on April 15, 2015. Mehmet, I understand about lack of feedback. What's interesting is that now the draft has gone this experimental route, more feedback (and support has come forward). Joe > > Mehmet > > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Joe Clarke > Sent: Monday, June 29, 2015 7:17 PM > To: Romascanu, Dan (Dan); ietf@ietf.org > Cc: netconf@ietf.org; lmap@ietf.org > Subject: Re: [Netconf] Last Call: (Time Capability in NETCONF) to Experimental RFC > > On 6/29/15 12:49, Romascanu, Dan (Dan) wrote: >> (I apologize for cross-posting) but it seems justified in this case) >> >> I find this work useful. > > As do I. I remember the when this was first presented in Berlin. I > thought it had value. > >> >> I have two questions: >> - why was not this document adopted by the NETCONF WG? Lack of time, out of focus, or are there any other (technical?) reasons? Why did it had to go on AD-sponsored and Experimental track? > > I'll speak from what I saw. There didn't seem to be a lot of traction > on the WG list, but I do feel this would be beneficial as a working > group item. > > Joe > >> - This work may potentially be useful for LMAP which has scheduling and time-stamping features in its architecture and framework. LMAP however just selected RESTCONF as their preferred protocol. What would it take to extend this work to RESTCONF)? (may be another piece of work) >> >> Thanks and Regards, >> >> Dan >> >> >>> -----Original Message----- >>> From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf Of >>> The IESG >>> Sent: Monday, June 29, 2015 5:58 PM >>> To: IETF-Announce >>> Subject: Last Call: (Time >>> Capability in NETCONF) to Experimental RFC >>> >>> >>> The IESG has received a request from an individual submitter to consider the >>> following document: >>> - 'Time Capability in NETCONF' >>> as Experimental RFC >>> >>> The IESG plans to make a decision in the next few weeks, and solicits final >>> comments on this action. Please send substantive comments to the >>> ietf@ietf.org mailing lists by 2015-07-29. Exceptionally, comments may be >>> sent to iesg@ietf.org instead. In either case, please retain the beginning of >>> the Subject line to allow automated sorting. >>> >>> Abstract >>> >>> >>> This document defines a capability-based extension to the Network >>> Configuration Protocol (NETCONF) that allows time-triggered >>> configuration and management operations. This extension allows >>> NETCONF clients to invoke configuration updates according to >>> scheduled times, and allows NETCONF servers to attach timestamps to >>> the data they send to NETCONF clients. >>> >>> >>> The Network Configuration Protocol (NETCONF) Capability URNs registry >>> requires a standards action in order to populate the registry. This document >>> was taken out of the ISE stream and brought forward as an AD sponsored >>> individual-submission to address this consideration. >>> >>> >>> The file can be obtained via >>> https://urldefense.proofpoint.com/v2/url?u=https- >>> 3A__datatracker.ietf.org_doc_draft-2Dmm-2Dnetconf-2Dtime- >>> 2Dcapability_&d=AwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNX >>> CJfQzvlsiLQfucBXRucPvdrphpBsFA&m=eIbq6OXE65r_w9lwmd5WrktViMncM >>> zhCDjk3tyjnVvU&s=B6e1FBSZH9H- >>> OYAnRMYEgTJVYQ6SSqa2K9XpuIyx3mI&e= >>> >>> IESG discussion can be tracked via >>> https://urldefense.proofpoint.com/v2/url?u=https- >>> 3A__datatracker.ietf.org_doc_draft-2Dmm-2Dnetconf-2Dtime- >>> 2Dcapability_ballot_&d=AwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR3 >>> 1OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=eIbq6OXE65r_w9lwmd5WrktVi >>> MncMzhCDjk3tyjnVvU&s=WbISmWkVGVo43riTMHY7kzIkAREkQrB2aq- >>> lyYOad-Y&e= >>> >>> >>> No IPR declarations have been submitted directly on this I-D. >>> >> >> _______________________________________________ >> 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 Jun 30 11:10:41 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB3671B2A9A for ; Tue, 30 Jun 2015 11:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QhF3JcdJxldc for ; Tue, 30 Jun 2015 11:10:38 -0700 (PDT) Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA56D1B2A9F for ; Tue, 30 Jun 2015 11:10:37 -0700 (PDT) Received: by lagh6 with SMTP id h6so23938349lag.2 for ; Tue, 30 Jun 2015 11:10:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=vC4YAiGNti6zPOmFRzcEdvfwjo+G7mo1VbyCSmjMwPI=; b=AAPJ4qe38Co8B1f1TQcJoM4e3Yk9d7iIH4fuzwK+tW0UxiJZEZ7/sIVKugCvsoQ1jo VEyKZmdkl4s0ZpGTukNvfuOKcVA7bkzEPjOpOKRBw14qX8u8mDo8ynm7Kis8sjVJz6Gs VdC3LeXw93gf/Mxn8EFd1wTFwx+1uhEJTXu4oOWuZbA2QJH8w7f+ZtCIBhkmu4Zyl+Qj tXpmzrqxOlcXYgsZcyy+HmhdtZwHeF3x0rcPgDqwoK1fGQ95O+LTUW5lULr83li52yET XOwx1SlCfeIeM4LL+DbuslJDHw5IkARw47qwo+cleKXZNInotKqO3ej/YAP9HLqq/zaa 9yZA== X-Gm-Message-State: ALoCoQnfcYwaS3jH9uSUFKOMyJK1/sqHxaLmts3cOvUzcbCeNRG2AdJvCbR1TvCbuF3UVDdWJIuT MIME-Version: 1.0 X-Received: by 10.112.147.233 with SMTP id tn9mr20813341lbb.119.1435687835799; Tue, 30 Jun 2015 11:10:35 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Tue, 30 Jun 2015 11:10:35 -0700 (PDT) In-Reply-To: <20150630124503.GA5406@elstar.local> References: <20150627.101927.980507351929498326.mbj@tail-f.com> <20150628.101115.524154870753102418.mbj@tail-f.com> <20150630.104449.916352783153186338.mbj@tail-f.com> <20150630124503.GA5406@elstar.local> Date: Tue, 30 Jun 2015 11:10:35 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Martin Bjorklund , Netconf , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=047d7b3a89787634220519c01f3e Archived-At: Subject: Re: [Netconf] [netmod] Y45-04 and ietf-yang-library X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 18:10:41 -0000 --047d7b3a89787634220519c01f3e Content-Type: text/plain; charset=UTF-8 On Tue, Jun 30, 2015 at 5:45 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > Writing as technical contributor... > > On Tue, Jun 30, 2015 at 10:44:49AM +0200, Martin Bjorklund wrote: > > Hi, > > > > Here's a short summary, and then some questions for the WG. > > > > The ietf-yang-library module is designed to serve two purposes: > > > > 1. A protocol-independent advertisement mechanism for YANG 1.1 > > modules. > > > > 2. A list of the YANG modules stored in a server. > > > > > > Q1. Do you agree with these goals? > > I primarily care about goal 1. > > > Q2. Should this module be designed to work with both YANG 1.0 and > > YANG 1.1 servers - i.e., should it have yang-version 1.1 or not? > > > > If it should not be defined using YANG 1.1, why is this module > > special? > > I assume this module will sooner or later be YANG 1.1 anyway. > > > Q3. Should the /modules/module list be designed to store both YANG > > 1.0 and YANG 1.1 modules? > > Yes. Even if YANG 1.1 hits the street tomorrow, we will not have > revised all published YANG data models that were written using YANG > 1.0. So a server needs to be able to announce both YANG 1.0 and YANG > 1.1 modules. > Yes -- We also agreed that we would not be republishing modules just to change the yang-version to 1.1. There are lots of YANG modules in progress at this time. Perhaps 3 out of 100 are relying on YANG 1.1 statements. It seems rather disruptive to declare all module must be YANG 1.1 since it has not even made it through WGLC yat, let alone be published as an RFC, let alone be implemented in real tool-chains. I suspect if people find out the only think YANG 1.1 in their module (preventing their existing tools from working) is a yang-version-stmt, they might not be too happy. Andy > > > Q4. Consider these modules, which both import foo without revision: > > > > module a { ... import foo; ... } > > module b { ... import foo; ... } > > > > Do we require a server that implements both a and b to use the > > same revision of foo? > > > > If the answer is yes, we need to indicate the default revision > > that the server uses in the model: > > > > container modules { > > ... > > list module { > > ... > > leaf default-revision { > > type boolean; > > default false; > > description > > "Indicates that this revision is used by the server if > > this module is imported without a specific revision > > date."; > > } > > } > > } > > > > If the answer is no, note that this puts an implementation burden > > on the client. A client cannot simply download all listed > > modules, and load/compile/process them as one set. > > > > If the anwser is no, I propose that we extend the module as such: > > > > container modules { > > ... > > list module { > > ... > > list imported-without-revision { > > key "name revision"; > > ... > > } > > } > > } > > > > A server could then list: > > > > > > a > > 2015-01-01 > > > > foo > > 2002-02-02 > > > > > > > > b > > 2015-01-01 > > > > foo > > 2001-01-01 > > > > > > I believe truth is advertisement is a good thing. In the SNMP world, > not all pieces of the instrumentation were moving at the same pace and > I would be somewhat surprised if this would be the case for all > implementations in the NETCONF world. Hence, I rather accept that an > import of foo without revision may resolve to different versions of > foo for different imports. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --047d7b3a89787634220519c01f3e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jun 30, 2015 at 5:45 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
Writing as technical contributor...

On Tue, Jun 30, 2015 at 10:44:49AM +0200, Martin Bjorklund wrote:
> Hi,
>
> Here's a short summary, and then some questions for the WG.
>
> The ietf-yang-library module is designed to serve two purposes:
>
>=C2=A0 =C2=A01.=C2=A0 A protocol-independent advertisement mechanism fo= r YANG 1.1
>=C2=A0 =C2=A0 =C2=A0 =C2=A0modules.
>
>=C2=A0 =C2=A02.=C2=A0 A list of the YANG modules stored in a server. >
>
> Q1.=C2=A0 Do you agree with these goals?

I primarily care about goal 1.

> Q2.=C2=A0 Should this module be designed to work with both YANG 1.0 an= d
>=C2=A0 =C2=A0 =C2=A0 YANG 1.1 servers - i.e., should it have yang-versi= on 1.1 or not?
>
>=C2=A0 =C2=A0 =C2=A0 If it should not be defined using YANG 1.1, why is= this module
>=C2=A0 =C2=A0 =C2=A0 special?

I assume this module will sooner or later be YANG 1.1 anyway.

> Q3.=C2=A0 Should the /modules/module list be designed to store both YA= NG
>=C2=A0 =C2=A0 =C2=A0 1.0 and YANG 1.1 modules?

Yes. Even if YANG 1.1 hits the street tomorrow, we will not have
revised all published YANG data models that were written using YANG
1.0. So a server needs to be able to announce both YANG 1.0 and YANG
1.1 modules.


Yes -- We a= lso agreed that we would not be republishing modules
just to chan= ge the yang-version to 1.1.

There are lots of YANG= modules in progress at this time.
Perhaps 3 out of 100 are relyi= ng on YANG 1.1 statements.
It seems rather disruptive to declare = all module must be YANG 1.1
since it has not even made it through= WGLC yat, let alone
be published as an RFC, let alone be impleme= nted
in real tool-chains.

I suspect if p= eople find out the only think YANG 1.1 in their module
(preventin= g their existing tools from working) is a yang-version-stmt,
they= might not be too happy.


Andy
=
=C2=A0

> Q4.=C2=A0 Consider these modules, which both import foo without revisi= on:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 module a { ... import foo; ... }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 module b { ... import foo; ... }
>
>=C2=A0 =C2=A0 =C2=A0 Do we require a server that implements both a and = b to use the
>=C2=A0 =C2=A0 =C2=A0 same revision of foo?
>
>=C2=A0 =C2=A0 =C2=A0 If the answer is yes, we need to indicate the defa= ult revision
>=C2=A0 =C2=A0 =C2=A0 that the server uses in the model:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 container modules {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 list module {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf default-revision {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type boolean;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 default false;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Indicates= that this revision is used by the server if
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this modu= le is imported without a specific revision
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0date.&quo= t;;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>
>=C2=A0 =C2=A0 =C2=A0 If the answer is no, note that this puts an implem= entation burden
>=C2=A0 =C2=A0 =C2=A0 on the client.=C2=A0 A client cannot simply downlo= ad all listed
>=C2=A0 =C2=A0 =C2=A0 modules, and load/compile/process them as one set.=
>
>=C2=A0 =C2=A0 =C2=A0 If the anwser is no, I propose that we extend the = module as such:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 container modules {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 list module {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 list imported-without-revisio= n {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 key "name revisio= n";
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>
>=C2=A0 =C2=A0 =C2=A0 A server could then list:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<module>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>a</name>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<revision>2015-01-01</revisi= on>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<imported-without-revision>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>foo</name> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<revision>2002-02-02<= /revision>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</imported-without-revision> >=C2=A0 =C2=A0 =C2=A0 =C2=A0</module>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<module>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>b</name>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<revision>2015-01-01</revisi= on>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<imported-without-revision>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>foo</name> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<revision>2001-01-01<= /revision>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</imported-without-revision> >=C2=A0 =C2=A0 =C2=A0 =C2=A0</module>

I believe truth is advertisement is a good thing. In the SNMP world,
not all pieces of the instrumentation were moving at the same pace and
I would be somewhat surprised if this would be the case for all
implementations in the NETCONF world. Hence, I rather accept that an
import of foo without revision may resolve to different versions of
foo for different imports.

/js

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

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

--047d7b3a89787634220519c01f3e-- From nobody Tue Jun 30 14:06:53 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9DBA1A1AE3; Tue, 30 Jun 2015 14:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Eymkubt07Yu; Tue, 30 Jun 2015 14:06:42 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C08A91A1ADB; Tue, 30 Jun 2015 14:06:40 -0700 (PDT) Received: by pdbci14 with SMTP id ci14so12309793pdb.2; Tue, 30 Jun 2015 14:06:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=YK+LYEiwGkO5fsdhE8iG7NdlYogXfBaxteSzLretNCQ=; b=eHBLUCwedxc5ywrLGi8/9vI4LWW5OXRA2dMcSlEC11ob4jalWRhsoZSK2CGsMI8IU7 T3o7CXkiEBHfB5JISZZL/HV1BKSObQV2FKSag9aRba44ZQrv80Dy61efio2zWoFWMC0j S++ocdISd2OVcwZJE8rrIAvSjRQ9l/SVMvjG32vQJhZJTie4P5HpeHW7T6QhJjsJF5QY e7EgOZR/Ix6jiIbgZYkm3c9EBWsg6f79QVqO3+llaQknySe6MPaHNRfyDXKizp5b/11T hTKKV8UdbhBYdnlp95Bt2bj/eMZwKWfM1rJqbIoHWyHp9BuVRmG4ExhQY8MBF30RMJnm Bkcg== X-Received: by 10.66.249.1 with SMTP id yq1mr46365173pac.3.1435698399851; Tue, 30 Jun 2015 14:06:39 -0700 (PDT) Received: from ?IPv6:2001:420:290:1266:8188:3b9c:b5d1:be1b? ([2001:420:290:1266:8188:3b9c:b5d1:be1b]) by mx.google.com with ESMTPSA id vl1sm46770397pab.21.2015.06.30.14.06.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 30 Jun 2015 14:06:38 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_D4B66922-6925-4751-AD43-941A1D78CBE5" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Mahesh Jethanandani In-Reply-To: <00d901d0ade1$194280e0$4bc782a0$@ndzh.com> Date: Tue, 30 Jun 2015 12:43:31 -0700 Message-Id: References: <00d901d0ade1$194280e0$4bc782a0$@ndzh.com> To: Susan Hares X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Rtg-yang-coord@ietf.org, i2rs@ietf.org, "BRUNGARD, DEBORAH A" , Netconf , NETMOD Working Group Subject: Re: [Netconf] [netmod] Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 21:06:46 -0000 --Apple-Mail=_D4B66922-6925-4751-AD43-941A1D78CBE5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Susan, The NETCONF WG acknowledges the receipt of the requirements. These requirements need to be discussed in front of the NETCONF WG. = Would suggest that i2rs WG present these requirements in front of the = NETCONF WG during IETF 93 in Prague to kick start discussion within the = WG. Please let us know how much time you (or someone from i2rs) would = need to present the requirements. Thanks. > On Jun 23, 2015, at 11:19 AM, Susan Hares wrote: >=20 > Netconf Working Group:=20 > =20 > The I2RS WG would like to pass you a set of requirements for the I2RS = protocol, and asks that you provide an analysis by IETF 93 on whether = NETCONF or RESTCONF can meet these requirements. We expect that these = requirements may require changes to the either NETCONF or RESTCONF. =20 > =20 > The I2RS architecture document (draft-ietf-i2rs-architecture-09 = ) = provides a high-level overview of the I2RS protocol. The I2RS has = compiled the following documents to provide the additional details on = the requirements for the protocols.=20 > =20 > 1) draft-ietf-i2rs-ephemeral-state-00 = =20 > 2) draft-ietf-i2rs-pub-sub-requirements-02 = =20= > 3) draft-ietf-i2rs-traceability-03 = =20 > =20 > The draft-ietf-i2rs-ephemeral-state-00 contains the results of the = discussion from the 6/10 interim and the top 10 requirements for I2RS. = In addition, the draft-ietf-i2rs-ephemeral-state-00 contains an set of = detailed requirements on how the I2RS WG sees the I2RS protocol = operating. These detailed requirements are to be seen as suggestions on = what type of solution the I2RS WG would like to see, but I2RS WG is = asking the NETCONF WG to provide its best designed protocol. Please = note as part of these detailed requirement the = draft-ietf-i2rs-ephemeral-states-00 contains the idea of using metadata = to record secondary identity. =20 > =20 > The I2RS protocol is driven by data-models. The approved data models = for protocol independent services are: > - draft-ietf-i2rs-rib-data-model-00 = > - Filter-Based RIBS: draft-kini-i2rs-fb-rib-data-model.00 = (released later this week) > - Topology model which is a composite of: > o Generic topology model: draft-ietf-i2rs-yang-network-topo-01 = =20 > o L3 topology model: draft-ietf-i2rs-yang-l3-topology-00 = =20 > o L2 topology model: draft-ietf-i2rs-yang-l2-network-topology-00 = =20 > o L1 Topology model: draft-zhang-i2rs-l1-topo-yang-model-01 (-02 = released later this week).=20 > o Service topology model: = draft-hares-i2rs-service-topo-yang-model-00 (released on Wednesday) > =20 > At this time, none of the Topology models utilize Traffic engineering. = It is anticipated that these models will support traffic engineering. = Estimated rates of transfer and timing requirements for these modules = are at: http://trac.tools.ietf.org/wg/i2rs/trac/wiki = - under the protocol = requirements table.=20 > =20 > We hope that NETCONF WG can provide some initial feedback on these = requirements by IETF 93 at the Tuesday I2RS session. I2RS will use the = 6/24 interim at 10:00-11:30am ET to provide a time for any participate = in the I2RS, netconf, or netmod group to ask additional questions on = these requirements.=20 > =20 > Sue Hares=20 > =20 > Interim time: 10:00-11:30am ET > Date 6/24/2015 > Webex:=20 > = https://ietf.webex.com/ietf/j.php?MTID=3Dm4260bee7be61cb17b0008a3c52069d0f= = > =20 > agenda:=20 > =20 > 10:00 =E2=80=93 10:05 =E2=80=93 Bash Agenda > 10:05 =E2=80=93 10:20- - review of requirements from > draft-ietf-i2rs-ephemeral-state-00 > draft-ietf-i2rs-pub-sub-requirements-02 > draft-ietf-i2rs-traceability-03 > Timing requirements=20 > =20 > 10:20 =E2=80=93 10:30 Review of requirements for mutual = authentication, > and transaction in draft-hares-auth-trans-01 requirements=20 > =20 > 10:30- 11:30 Open discussion for I2RS Requirements=20 > =20 > Proceedings and slides can be found at:=20 > = http://www.ietf.org/proceedings/interim/2015/06/24/i2rs/proceedings.html = = > =20 > Sue Hares=20 > =20 > =20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod = Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_D4B66922-6925-4751-AD43-941A1D78CBE5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Susan,

The = NETCONF WG acknowledges the receipt of the requirements.

These requirements need = to be discussed in front of the NETCONF WG. Would suggest that i2rs WG = present these requirements in front of the NETCONF WG during IETF 93 in = Prague to kick start discussion within the WG. Please let us know how = much time you (or someone from i2rs) would need to present the = requirements.

Thanks.

On Jun 23, 2015, at 11:19 AM, = Susan Hares <shares@ndzh.com> wrote:

Netconf = Working Group: 
 
The I2RS = WG would like to pass you a set of requirements for the I2RS protocol, = and asks that you provide an analysis by IETF 93 on whether NETCONF or = RESTCONF can meet these requirements.   We expect that these = requirements may require changes to the either NETCONF or = RESTCONF.  
 
The I2RS = architecture document (draft-ietf-i2rs-architecture-09) provides a = high-level overview of the I2RS  protocol.  The I2RS has = compiled the following documents to provide the additional details on = the requirements for the protocols. 
 
1)      draft-ietf-i2rs-ephemeral-state-00 
2)      draft-ietf-i2rs-pub-sub-requirements-02 
3)      draft-ietf-i2rs-traceability-03  
 
The = draft-ietf-i2rs-ephemeral-state-00 contains the results of the = discussion from the 6/10 interim and the top 10 requirements for = I2RS.  In addition, the draft-ietf-i2rs-ephemeral-state-00 contains = an set of detailed requirements on how the I2RS WG sees the I2RS = protocol operating.  These detailed requirements are to be seen as = suggestions on what type of solution the I2RS WG would like to see, but = I2RS WG is asking the NETCONF WG to provide its best designed = protocol.  Please note as part of these detailed requirement the = draft-ietf-i2rs-ephemeral-states-00 contains the idea of using metadata = to record secondary identity.   
 
The I2RS protocol is driven by = data-models.  The approved data models for protocol independent = services are:
-          draft-ietf-i2rs-rib-data-model-00
-          Filter-B= ased RIBS:  draft-kini-i2rs-fb-rib-data-model.00 (released later this = week)
-          Topology model = which is a composite of:
o   <= span class=3D"apple-converted-space">Generic = topology model: draft-ietf-i2rs-yang-network-topo-01 
o   <= span class=3D"apple-converted-space">L3 = topology model: draft-ietf-i2rs-yang-l3-topology-00 
o   <= span class=3D"apple-converted-space">L2 = topology model: draft-ietf-i2rs-yang-l2-network-topology-00 
o   L1 Topology = model: draft-zhang-i2rs-l1-topo-yang= -model-01 (-02 released later this week). 
o   Service = topology model: draft-hares-i2rs-service-topo= -yang-model-00 (released on Wednesday)
 
At this time, none of the Topology = models utilize Traffic engineering.  It is anticipated that these = models will support traffic engineering.  Estimated rates of = transfer and timing requirements for these modules are at: http://trac.tools.ietf.org/wg/i2rs/trac/wiki - under the protocol = requirements table. 
 
We hope = that NETCONF WG can provide some initial feedback on these requirements = by IETF 93 at the Tuesday I2RS session.   I2RS will use the = 6/24 interim at 10:00-11:30am ET  to provide a time for any = participate in the I2RS, netconf, or netmod group to ask additional = questions on these requirements. 
 
Sue = Hares 
 
Interim = time: 10:00-11:30am ET
Date 6/24/2015
Webex: 
https://ietf.webex.com/ietf/j.php?MTID=3Dm4260bee7be61cb17b0008= a3c52069d0f
 
agenda: 
 
10:00 =E2=80= =93 10:05 =E2=80=93 Bash Agenda
10:05 =E2=80=93 10:20- -  review = of requirements from
draft-ietf-i2rs-ephemeral-state-00
draft-ietf-i2rs-pub-sub-requirements-02
draft-ietf-i2rs-traceability-03
Timing = requirements 
 
10:20 =E2=80=93 10:30    Review of = requirements for mutual authentication,
and transaction in =  draft-hares-auth-trans-01 requirements 
 
10:30- = 11:30     Open discussion for I2RS Requirements 
 
Proceedings= and slides can be found at: 
http://www.ietf.org/proceedings/interim/2015/06/24/i2rs/proceed= ings.html
 
Sue Hares 
 
 
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_D4B66922-6925-4751-AD43-941A1D78CBE5-- From nobody Tue Jun 30 14:16:32 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA59F1B2E69; Tue, 30 Jun 2015 14:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoEyHFXdm96z; Tue, 30 Jun 2015 14:16:26 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (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 5A0441B32B1; Tue, 30 Jun 2015 14:16:18 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.185.134; From: "Susan Hares" To: "'Mahesh Jethanandani'" References: <00d901d0ade1$194280e0$4bc782a0$@ndzh.com> In-Reply-To: Date: Tue, 30 Jun 2015 17:16:20 -0400 Message-ID: <007501d0b37a$02d6fbd0$0884f370$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0076_01D0B358.7BC9EFB0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQISFdXuYb8FEw5zRd6nzKGMwfXW3QKbN0DLnS3sq9A= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: Rtg-yang-coord@ietf.org, i2rs@ietf.org, 'NETMOD Working Group' , 'Netconf' , "'BRUNGARD, DEBORAH A'" Subject: Re: [Netconf] [Rtg-yang-coord] [netmod] Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 21:16:29 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0076_01D0B358.7BC9EFB0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mahesh:=20 =20 Ok. I thought you were going to review the requirement documents and = give I2RS an initial guess. We have present these at 3 I2RS interims, = and the slides are online. I will send the minutes to the netconf = working group for their review.=20 =20 The presentation of the requirements will need the following time:=20 =20 1) 10 top requirements =E2=80=93 5-10 minutes [Sue Hares]=20 2) Ephemeral state =E2=80=93 15 minutes [Jeff Haas]=20 3) Pub/sub requirements =E2=80=93 10-15 minutes [Eric Voit] 4) Traceability [ 10-15 minutes]=20 5) Security [10 minutes] [Sue Hares and Joel Halpern] 6) Review of I2RS models [5 minutes]=20 7) =20 If you have heard pub/sub and traceability requirements, you may delete = this from timeline.=20 =20 Sue Hares=20 =20 From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf = Of Mahesh Jethanandani Sent: Tuesday, June 30, 2015 3:44 PM To: Susan Hares Cc: Rtg-yang-coord@ietf.org; i2rs@ietf.org; BRUNGARD, DEBORAH A; = Netconf; NETMOD Working Group Subject: Re: [Rtg-yang-coord] [netmod] Requirements for I2RS protocol = and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) =20 Susan, =20 The NETCONF WG acknowledges the receipt of the requirements. =20 These requirements need to be discussed in front of the NETCONF WG. = Would suggest that i2rs WG present these requirements in front of the = NETCONF WG during IETF 93 in Prague to kick start discussion within the = WG. Please let us know how much time you (or someone from i2rs) would = need to present the requirements. =20 Thanks. =20 On Jun 23, 2015, at 11:19 AM, Susan Hares wrote: =20 Netconf Working Group:=20 =20 The I2RS WG would like to pass you a set of requirements for the I2RS = protocol, and asks that you provide an analysis by IETF 93 on whether = NETCONF or RESTCONF can meet these requirements. We expect that these = requirements may require changes to the either NETCONF or RESTCONF. =20 =20 The I2RS architecture document ( = = draft-ietf-i2rs-architecture-09) provides a high-level overview of the = I2RS protocol. The I2RS has compiled the following documents to = provide the additional details on the requirements for the protocols.=20 =20 1) = = draft-ietf-i2rs-ephemeral-state-00=20 2) = = draft-ietf-i2rs-pub-sub-requirements-02=20 3) = = draft-ietf-i2rs-traceability-03 =20 =20 The draft-ietf-i2rs-ephemeral-state-00 contains the results of the = discussion from the 6/10 interim and the top 10 requirements for I2RS. = In addition, the draft-ietf-i2rs-ephemeral-state-00 contains an set of = detailed requirements on how the I2RS WG sees the I2RS protocol = operating. These detailed requirements are to be seen as suggestions on = what type of solution the I2RS WG would like to see, but I2RS WG is = asking the NETCONF WG to provide its best designed protocol. Please = note as part of these detailed requirement the = draft-ietf-i2rs-ephemeral-states-00 contains the idea of using metadata = to record secondary identity. =20 =20 The I2RS protocol is driven by data-models. The approved data models = for protocol independent services are: - = = draft-ietf-i2rs-rib-data-model-00 - Filter-Based RIBS: draft-kini-i2rs-fb-rib-data-model.00 = (released later this week) - Topology model which is a composite of: o Generic topology model: = = draft-ietf-i2rs-yang-network-topo-01=20 o L3 topology model: = = draft-ietf-i2rs-yang-l3-topology-00=20 o L2 topology model: = draft-ietf-i2rs-yang-l2-network-topology-00=20 o L1 Topology model: draft-zhang-i2rs-l1-topo-yang-model-01 (-02 = released later this week).=20 o Service topology model: draft-hares-i2rs-service-topo-yang-model-00 = (released on Wednesday) =20 At this time, none of the Topology models utilize Traffic engineering. = It is anticipated that these models will support traffic engineering. = Estimated rates of transfer and timing requirements for these modules = are at: = http://trac.tools.ietf.org/wg/i2rs/trac/wiki - under the protocol = requirements table.=20 =20 We hope that NETCONF WG can provide some initial feedback on these = requirements by IETF 93 at the Tuesday I2RS session. I2RS will use the = 6/24 interim at 10:00-11:30am ET to provide a time for any participate = in the I2RS, netconf, or netmod group to ask additional questions on = these requirements.=20 =20 Sue Hares=20 =20 Interim time: 10:00-11:30am ET Date 6/24/2015 Webex:=20 = = https://ietf.webex.com/ietf/j.php?MTID=3Dm4260bee7be61cb17b0008a3c52069d0= f =20 agenda:=20 =20 10:00 =E2=80=93 10:05 =E2=80=93 Bash Agenda 10:05 =E2=80=93 10:20- - review of requirements from draft-ietf-i2rs-ephemeral-state-00 draft-ietf-i2rs-pub-sub-requirements-02 draft-ietf-i2rs-traceability-03 Timing requirements=20 =20 10:20 =E2=80=93 10:30 Review of requirements for mutual = authentication, and transaction in draft-hares-auth-trans-01 requirements=20 =20 10:30- 11:30 Open discussion for I2RS Requirements=20 =20 Proceedings and slides can be found at:=20 = = http://www.ietf.org/proceedings/interim/2015/06/24/i2rs/proceedings.html =20 Sue Hares=20 =20 =20 _______________________________________________ netmod mailing list netmod@ietf.org = https://www.ietf.org/mailman/listinfo/netmod =20 Mahesh Jethanandani mjethanandani@gmail.com =20 =20 =20 ------=_NextPart_000_0076_01D0B358.7BC9EFB0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Mahesh:

 

Ok. =C2=A0I thought you were going to review the requirement = documents and give I2RS an initial guess.=C2=A0 We have present these at = 3 I2RS interims, and the slides are online.=C2=A0 I will send the = minutes to the netconf working group for their review. =

 

The presentation of the requirements will need the following time: =

 

1)      = 10 top requirements =E2=80=93 5-10 minutes [Sue Hares] =

2)      = Ephemeral state =E2=80=93 15 minutes [Jeff Haas] =

3)      = Pub/sub requirements =E2=80=93 10-15 minutes [Eric = Voit]

4)      = Traceability [ 10-15 minutes]

5)      = Security [10 minutes] [Sue Hares and Joel = Halpern]

6)      = Review of I2RS models [5 minutes]

7)      =  

If you have heard pub/sub and traceability requirements, you may = delete this from timeline.

 

Sue Hares

 

From:= = Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of = Mahesh Jethanandani
Sent: Tuesday, June 30, 2015 3:44 = PM
To: Susan Hares
Cc: Rtg-yang-coord@ietf.org; = i2rs@ietf.org; BRUNGARD, DEBORAH A; Netconf; NETMOD Working = Group
Subject: Re: [Rtg-yang-coord] [netmod] Requirements for = I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am = ET)

 

Susan,

 

The NETCONF WG acknowledges the receipt of the = requirements.

 

These requirements need to be discussed in front of = the NETCONF WG. Would suggest that i2rs WG present these requirements in = front of the NETCONF WG during IETF 93 in Prague to kick start = discussion within the WG. Please let us know how much time you (or = someone from i2rs) would need to present the = requirements.

 

Thanks.

 

On Jun 23, 2015, at 11:19 AM, Susan Hares <shares@ndzh.com> = wrote:

 

Netconf = Working Group: 

 =

The I2RS = WG would like to pass you a set of requirements for the I2RS protocol, = and asks that you provide an analysis by IETF 93 on whether NETCONF or = RESTCONF can meet these requirements.   We expect that these = requirements may require changes to the either NETCONF or = RESTCONF.  

 =

The I2RS = architecture document (<= span = style=3D'font-size:11.5pt;color:#3D22B3;background:white;text-decoration:= none'>draft-ietf-i2rs-architecture-09) provides a = high-level overview of the I2RS  protocol.  The I2RS has = compiled the following documents to provide the additional details on = the requirements for the protocols. 

 =

 =

The = draft-ietf-i2rs-ephemeral-state-00 contains the results of the = discussion from the 6/10 interim and the top 10 requirements for = I2RS.  In addition, the draft-ietf-i2rs-ephemeral-state-00 contains = an set of detailed requirements on how the I2RS WG sees the I2RS = protocol operating.  These detailed requirements are to be seen as = suggestions on what type of solution the I2RS WG would like to see, but = I2RS WG is asking the NETCONF WG to provide its best designed = protocol.  Please note as part of these detailed requirement the = draft-ietf-i2rs-ephemeral-states-00 contains the idea of using metadata = to record secondary identity. =   

 =

The I2RS = protocol is driven by data-models.  The approved data models for = protocol independent services are:

-        = ;  draft-ietf-i2rs-rib-data-model-00

<= /div>

-        = ;  Filter-Base= d RIBS:  draft-kini-i2rs-fb-rib-data-model.00 (released later = this week)=

-        = ;  Topology model which is a composite = of:=

o   Generic topology model: draft-ietf-i2rs-yang-network-topo-01 =

o   L3 topology model: draft-ietf-i2rs-yang-l3-topology-00 =

o   L2 topology model: draft-ietf-i2rs-yang-l2-network-topology-00 =

o   L1 Topology model: draft-zhang= -i2rs-l1-topo-yang-model-01 (-02 released later this week). 

o   Service topology model: draft-hares= -i2rs-service-topo-yang-model-00 (released on = Wednesday)

 =

At this = time, none of the Topology models utilize Traffic engineering.  It = is anticipated that these models will support traffic engineering. =  Estimated rates of transfer and timing requirements for these = modules are at: http://trac.tools.ietf.org/wg/i2rs/trac/wiki - under the = protocol requirements table. 

 =

We hope = that NETCONF WG can provide some initial feedback on these requirements = by IETF 93 at the Tuesday I2RS session.   I2RS will use the = 6/24 interim at 10:00-11:30am ET  to provide a time for any = participate in the I2RS, netconf, or netmod group to ask additional = questions on these requirements. 

 =

Sue = Hares 

 =

Interim = time: 10:00-11:30am ET

Date = 6/24/2015

Webex: 

https://ietf.webex.com/ietf/j.php?MTID=3Dm4260bee7= be61cb17b0008a3c52069d0f

 =

agenda: 

 =

10:00 = =E2=80=93 10:05 =E2=80=93 Bash Agenda

10:05 = =E2=80=93 10:20- -  review of requirements = from

draft-ietf-= i2rs-ephemeral-state-00

draft-ietf-= i2rs-pub-sub-requirements-02

draft-ietf-= i2rs-traceability-03

Timing = requirements 

 =

10:20 = =E2=80=93 10:30    Review of requirements for mutual = authentication,

and = transaction in  draft-hares-auth-trans-01 requirements 

 =

10:30- = 11:30     Open discussion for I2RS Requirements 

 =

Proceedings= and slides can be found at: 

http://www.ietf.org/proceedings/interim/2015/06/24= /i2rs/proceedings.html

 =

Sue = Hares 

 =

 =

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

=

 

Mahesh Jethanandani

 

 

 

------=_NextPart_000_0076_01D0B358.7BC9EFB0-- From nobody Tue Jun 30 15:13:51 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E861B3317; Tue, 30 Jun 2015 15:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulGayuEvAWcB; Tue, 30 Jun 2015 15:13:45 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25E9B1B3313; Tue, 30 Jun 2015 15:13:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=61472; q=dns/txt; s=iport; t=1435702425; x=1436912025; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=tjhHoEQRxgW3RYGGcDYhd1sTUgeHWTSMXCa73+bIz7M=; b=kjKFZLfSzzDGGAzeqkl+V2xpq7M7IIVO2Goh/iV8UGa+T1zs2f8rQ4qI XTqg13Lo6W95nYuJE5uH1+2ckzVUvZPptW0AlVmwNSUW64Gx7ytDvgMA9 DHXYmul0vi4FRDuG3S7iyTIIeZeyCW3wMyT2ydMap2sH9sbRCE5xW5DO3 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A0BQByFJNV/5JdJa1BEQmCRUxUXwaDGLoAKgmBSBkBC4UsSgIcgTo4FAEBAQEBAQGBCoQiAQEBBAEBASAKQQsQAgEIDgMBAwEBCxYBAgQDAgICHwYLFAMGCAIEAQkEBQgBEod/AxINOrImkQcNhXMBAQEBAQEBAQEBAQEBAQEBAQEBAQEXi0qCTYFdKy0EBgGCaC+BFAWRKYJeAYRZhRqBZIE5RINOi1eHGhEVggwcFYE9bwGBRYECAQEB X-IronPort-AV: E=Sophos;i="5.15,380,1432598400"; d="scan'208,217";a="164434195" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Jun 2015 22:13:29 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t5UMDSCg026310 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Jun 2015 22:13:28 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.147]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Tue, 30 Jun 2015 17:13:21 -0500 From: "Eric Voit (evoit)" To: Susan Hares , "'Mahesh Jethanandani'" Thread-Topic: [Rtg-yang-coord] [netmod] Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) Thread-Index: AQISFdXuYb8FEw5zRd6nzKGMwfXW3QKbN0DLnS3sq9CAAAbrEA== Date: Tue, 30 Jun 2015 22:13:21 +0000 Message-ID: References: <00d901d0ade1$194280e0$4bc782a0$@ndzh.com> <007501d0b37a$02d6fbd0$0884f370$@ndzh.com> In-Reply-To: <007501d0b37a$02d6fbd0$0884f370$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.118.56.228] Content-Type: multipart/alternative; boundary="_000_EF64FF31F4C4384DBCE5D513A791C2B121B00EE1xmbalnx11ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "Rtg-yang-coord@ietf.org" , "i2rs@ietf.org" , 'NETMOD Working Group' , "'BRUNGARD, DEBORAH A'" , 'Netconf' Subject: Re: [Netconf] [Rtg-yang-coord] [netmod] Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 22:13:48 -0000 --_000_EF64FF31F4C4384DBCE5D513A791C2B121B00EE1xmbalnx11ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBwcmVzZW50ZWQgUHViU3ViIOKAmC0wMeKAmSByZXF1aXJlbWVudHMgaW4gTkVUQ09ORiBhdCBJ RVRGIDkyLiAgICBDaGFuZ2VzIGluIOKAmC0wMuKAmSBhcmUgbGlrZWx5IG5vdCBlbm91Z2ggZm9y IGEgc3BlYWtpbmcgc2xvdC4NCg0KV2hhdCBtaWdodCBiZSBpbnRlcmVzdGluZyBmb3IgYSBORVRD T05GIHNwZWFraW5nIHNsb3QgaXMgYW4gYW5hbHlzaXMgb2Ygd2hhdCByZXF1aXJlbWVudHMgZnJv bSDigJxkcmFmdC1pZXRmLWkycnMtcHViLXN1Yi1yZXF1aXJlbWVudHPigJ0gYXJlIG1ldCBieSDi gJxkcmFmdC1jbGVtbS1uZXRjb25mLXlhbmctcHVzaOKAnS4gICAoRHVyaW5nIElFVEYgOTIsIE5F VENPTkYgcmV2aWV3ZWQgZHJhZnQtY2xlbW0uIFRoZXJlIHdhcyBhIHN0cmF3bWFuIHBvbGwgKDEy IHllcywgMCBubykgd2hlcmUgdGhlIFdHIGluZGljYXRlZCBpbnRlcmVzdC4pDQoNCldvdWxkIE5F VENPTkYgd2FudCBBbGV4IG9yIEkgdG8gc3BlYWsgb24gYSByZXF1aXJlbWVudHMtdG8tdGVjaG5v bG9neSBjb21wYXJpc29uIGluIFByYWd1ZT8NCg0KRXJpYw0KDQpGcm9tOiBSdGcteWFuZy1jb29y ZCBbbWFpbHRvOnJ0Zy15YW5nLWNvb3JkLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBT dXNhbiBIYXJlcw0KU2VudDogVHVlc2RheSwgSnVuZSAzMCwgMjAxNSA1OjE2IFBNDQpUbzogJ01h aGVzaCBKZXRoYW5hbmRhbmknDQpDYzogUnRnLXlhbmctY29vcmRAaWV0Zi5vcmc7IGkycnNAaWV0 Zi5vcmc7ICdORVRNT0QgV29ya2luZyBHcm91cCc7ICdOZXRjb25mJzsgJ0JSVU5HQVJELCBERUJP UkFIIEEnDQpTdWJqZWN0OiBSZTogW1J0Zy15YW5nLWNvb3JkXSBbbmV0bW9kXSBSZXF1aXJlbWVu dHMgZm9yIEkyUlMgcHJvdG9jb2wgYW5kIEkyUlMgaW50ZXJpbSAoNi8yNC8yMDE1IGF0IDEwOjAw IC0gMTE6MzBhbSBFVCkNCg0KTWFoZXNoOg0KDQpPay4gIEkgdGhvdWdodCB5b3Ugd2VyZSBnb2lu ZyB0byByZXZpZXcgdGhlIHJlcXVpcmVtZW50IGRvY3VtZW50cyBhbmQgZ2l2ZSBJMlJTIGFuIGlu aXRpYWwgZ3Vlc3MuICBXZSBoYXZlIHByZXNlbnQgdGhlc2UgYXQgMyBJMlJTIGludGVyaW1zLCBh bmQgdGhlIHNsaWRlcyBhcmUgb25saW5lLiAgSSB3aWxsIHNlbmQgdGhlIG1pbnV0ZXMgdG8gdGhl IG5ldGNvbmYgd29ya2luZyBncm91cCBmb3IgdGhlaXIgcmV2aWV3Lg0KDQpUaGUgcHJlc2VudGF0 aW9uIG9mIHRoZSByZXF1aXJlbWVudHMgd2lsbCBuZWVkIHRoZSBmb2xsb3dpbmcgdGltZToNCg0K DQoxKSAgICAgIDEwIHRvcCByZXF1aXJlbWVudHMg4oCTIDUtMTAgbWludXRlcyBbU3VlIEhhcmVz XQ0KDQoyKSAgICAgIEVwaGVtZXJhbCBzdGF0ZSDigJMgMTUgbWludXRlcyBbSmVmZiBIYWFzXQ0K DQozKSAgICAgIFB1Yi9zdWIgcmVxdWlyZW1lbnRzIOKAkyAxMC0xNSBtaW51dGVzIFtFcmljIFZv aXRdDQoNCjQpICAgICAgVHJhY2VhYmlsaXR5IFsgMTAtMTUgbWludXRlc10NCg0KNSkgICAgICBT ZWN1cml0eSBbMTAgbWludXRlc10gW1N1ZSBIYXJlcyBhbmQgSm9lbCBIYWxwZXJuXQ0KDQo2KSAg ICAgIFJldmlldyBvZiBJMlJTIG1vZGVscyBbNSBtaW51dGVzXQ0KDQo3KQ0KSWYgeW91IGhhdmUg aGVhcmQgcHViL3N1YiBhbmQgdHJhY2VhYmlsaXR5IHJlcXVpcmVtZW50cywgeW91IG1heSBkZWxl dGUgdGhpcyBmcm9tIHRpbWVsaW5lLg0KDQpTdWUgSGFyZXMNCg0KRnJvbTogUnRnLXlhbmctY29v cmQgW21haWx0bzpydGcteWFuZy1jb29yZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg TWFoZXNoIEpldGhhbmFuZGFuaQ0KU2VudDogVHVlc2RheSwgSnVuZSAzMCwgMjAxNSAzOjQ0IFBN DQpUbzogU3VzYW4gSGFyZXMNCkNjOiBSdGcteWFuZy1jb29yZEBpZXRmLm9yZzxtYWlsdG86UnRn LXlhbmctY29vcmRAaWV0Zi5vcmc+OyBpMnJzQGlldGYub3JnPG1haWx0bzppMnJzQGlldGYub3Jn PjsgQlJVTkdBUkQsIERFQk9SQUggQTsgTmV0Y29uZjsgTkVUTU9EIFdvcmtpbmcgR3JvdXANClN1 YmplY3Q6IFJlOiBbUnRnLXlhbmctY29vcmRdIFtuZXRtb2RdIFJlcXVpcmVtZW50cyBmb3IgSTJS UyBwcm90b2NvbCBhbmQgSTJSUyBpbnRlcmltICg2LzI0LzIwMTUgYXQgMTA6MDAgLSAxMTozMGFt IEVUKQ0KDQpTdXNhbiwNCg0KVGhlIE5FVENPTkYgV0cgYWNrbm93bGVkZ2VzIHRoZSByZWNlaXB0 IG9mIHRoZSByZXF1aXJlbWVudHMuDQoNClRoZXNlIHJlcXVpcmVtZW50cyBuZWVkIHRvIGJlIGRp c2N1c3NlZCBpbiBmcm9udCBvZiB0aGUgTkVUQ09ORiBXRy4gV291bGQgc3VnZ2VzdCB0aGF0IGky cnMgV0cgcHJlc2VudCB0aGVzZSByZXF1aXJlbWVudHMgaW4gZnJvbnQgb2YgdGhlIE5FVENPTkYg V0cgZHVyaW5nIElFVEYgOTMgaW4gUHJhZ3VlIHRvIGtpY2sgc3RhcnQgZGlzY3Vzc2lvbiB3aXRo aW4gdGhlIFdHLiBQbGVhc2UgbGV0IHVzIGtub3cgaG93IG11Y2ggdGltZSB5b3UgKG9yIHNvbWVv bmUgZnJvbSBpMnJzKSB3b3VsZCBuZWVkIHRvIHByZXNlbnQgdGhlIHJlcXVpcmVtZW50cy4NCg0K VGhhbmtzLg0KDQpPbiBKdW4gMjMsIDIwMTUsIGF0IDExOjE5IEFNLCBTdXNhbiBIYXJlcyA8c2hh cmVzQG5kemguY29tPG1haWx0bzpzaGFyZXNAbmR6aC5jb20+PiB3cm90ZToNCg0KTmV0Y29uZiBX b3JraW5nIEdyb3VwOg0KDQpUaGUgSTJSUyBXRyB3b3VsZCBsaWtlIHRvIHBhc3MgeW91IGEgc2V0 IG9mIHJlcXVpcmVtZW50cyBmb3IgdGhlIEkyUlMgcHJvdG9jb2wsIGFuZCBhc2tzIHRoYXQgeW91 IHByb3ZpZGUgYW4gYW5hbHlzaXMgYnkgSUVURiA5MyBvbiB3aGV0aGVyIE5FVENPTkYgb3IgUkVT VENPTkYgY2FuIG1lZXQgdGhlc2UgcmVxdWlyZW1lbnRzLiAgIFdlIGV4cGVjdCB0aGF0IHRoZXNl IHJlcXVpcmVtZW50cyBtYXkgcmVxdWlyZSBjaGFuZ2VzIHRvIHRoZSBlaXRoZXIgTkVUQ09ORiBv ciBSRVNUQ09ORi4NCg0KVGhlIEkyUlMgYXJjaGl0ZWN0dXJlIGRvY3VtZW50IChkcmFmdC1pZXRm LWkycnMtYXJjaGl0ZWN0dXJlLTA5PGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtaTJycy1hcmNoaXRlY3R1cmUvPikgcHJvdmlkZXMgYSBoaWdoLWxldmVsIG92ZXJ2 aWV3IG9mIHRoZSBJMlJTICBwcm90b2NvbC4gIFRoZSBJMlJTIGhhcyBjb21waWxlZCB0aGUgZm9s bG93aW5nIGRvY3VtZW50cyB0byBwcm92aWRlIHRoZSBhZGRpdGlvbmFsIGRldGFpbHMgb24gdGhl IHJlcXVpcmVtZW50cyBmb3IgdGhlIHByb3RvY29scy4NCg0KMSkgICAgICBkcmFmdC1pZXRmLWky cnMtZXBoZW1lcmFsLXN0YXRlLTAwPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtaTJycy1lcGhlbWVyYWwtc3RhdGUvPg0KMikgICAgICBkcmFmdC1pZXRmLWkycnMt cHViLXN1Yi1yZXF1aXJlbWVudHMtMDI8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtaWV0Zi1pMnJzLXB1Yi1zdWItcmVxdWlyZW1lbnRzLz4NCjMpICAgICAgZHJhZnQtaWV0 Zi1pMnJzLXRyYWNlYWJpbGl0eS0wMzxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLWkycnMtdHJhY2VhYmlsaXR5Lz4NCg0KVGhlIGRyYWZ0LWlldGYtaTJycy1lcGhl bWVyYWwtc3RhdGUtMDAgY29udGFpbnMgdGhlIHJlc3VsdHMgb2YgdGhlIGRpc2N1c3Npb24gZnJv bSB0aGUgNi8xMCBpbnRlcmltIGFuZCB0aGUgdG9wIDEwIHJlcXVpcmVtZW50cyBmb3IgSTJSUy4g IEluIGFkZGl0aW9uLCB0aGUgZHJhZnQtaWV0Zi1pMnJzLWVwaGVtZXJhbC1zdGF0ZS0wMCBjb250 YWlucyBhbiBzZXQgb2YgZGV0YWlsZWQgcmVxdWlyZW1lbnRzIG9uIGhvdyB0aGUgSTJSUyBXRyBz ZWVzIHRoZSBJMlJTIHByb3RvY29sIG9wZXJhdGluZy4gIFRoZXNlIGRldGFpbGVkIHJlcXVpcmVt ZW50cyBhcmUgdG8gYmUgc2VlbiBhcyBzdWdnZXN0aW9ucyBvbiB3aGF0IHR5cGUgb2Ygc29sdXRp b24gdGhlIEkyUlMgV0cgd291bGQgbGlrZSB0byBzZWUsIGJ1dCBJMlJTIFdHIGlzIGFza2luZyB0 aGUgTkVUQ09ORiBXRyB0byBwcm92aWRlIGl0cyBiZXN0IGRlc2lnbmVkIHByb3RvY29sLiAgUGxl YXNlIG5vdGUgYXMgcGFydCBvZiB0aGVzZSBkZXRhaWxlZCByZXF1aXJlbWVudCB0aGUgZHJhZnQt aWV0Zi1pMnJzLWVwaGVtZXJhbC1zdGF0ZXMtMDAgY29udGFpbnMgdGhlIGlkZWEgb2YgdXNpbmcg bWV0YWRhdGEgdG8gcmVjb3JkIHNlY29uZGFyeSBpZGVudGl0eS4NCg0KVGhlIEkyUlMgcHJvdG9j b2wgaXMgZHJpdmVuIGJ5IGRhdGEtbW9kZWxzLiAgVGhlIGFwcHJvdmVkIGRhdGEgbW9kZWxzIGZv ciBwcm90b2NvbCBpbmRlcGVuZGVudCBzZXJ2aWNlcyBhcmU6DQotICAgICAgICAgIGRyYWZ0LWll dGYtaTJycy1yaWItZGF0YS1tb2RlbC0wMDxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLWkycnMtcmliLWRhdGEtbW9kZWwvPg0KLSAgICAgICAgICBGaWx0ZXItQmFz ZWQgUklCUzogIGRyYWZ0LWtpbmktaTJycy1mYi1yaWItZGF0YS1tb2RlbC4wMCAocmVsZWFzZWQg bGF0ZXIgdGhpcyB3ZWVrKQ0KLSAgICAgICAgICBUb3BvbG9neSBtb2RlbCB3aGljaCBpcyBhIGNv bXBvc2l0ZSBvZjoNCm8gICBHZW5lcmljIHRvcG9sb2d5IG1vZGVsOiBkcmFmdC1pZXRmLWkycnMt eWFuZy1uZXR3b3JrLXRvcG8tMDE8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1pMnJzLXlhbmctbmV0d29yay10b3BvLz4NCm8gICBMMyB0b3BvbG9neSBtb2RlbDog ZHJhZnQtaWV0Zi1pMnJzLXlhbmctbDMtdG9wb2xvZ3ktMDA8aHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pMnJzLXlhbmctbDMtdG9wb2xvZ3kvPg0KbyAgIEwyIHRv cG9sb2d5IG1vZGVsOiBkcmFmdC1pZXRmLWkycnMteWFuZy1sMi1uZXR3b3JrLXRvcG9sb2d5LTAw PGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaTJycy15YW5nLWwy LW5ldHdvcmstdG9wb2xvZ3kvPg0KbyAgIEwxIFRvcG9sb2d5IG1vZGVsOiBkcmFmdC16aGFuZy1p MnJzLWwxLXRvcG8teWFuZy1tb2RlbC0wMSAoLTAyIHJlbGVhc2VkIGxhdGVyIHRoaXMgd2Vlayku DQpvICAgU2VydmljZSB0b3BvbG9neSBtb2RlbDogZHJhZnQtaGFyZXMtaTJycy1zZXJ2aWNlLXRv cG8teWFuZy1tb2RlbC0wMCAocmVsZWFzZWQgb24gV2VkbmVzZGF5KQ0KDQpBdCB0aGlzIHRpbWUs IG5vbmUgb2YgdGhlIFRvcG9sb2d5IG1vZGVscyB1dGlsaXplIFRyYWZmaWMgZW5naW5lZXJpbmcu ICBJdCBpcyBhbnRpY2lwYXRlZCB0aGF0IHRoZXNlIG1vZGVscyB3aWxsIHN1cHBvcnQgdHJhZmZp YyBlbmdpbmVlcmluZy4gIEVzdGltYXRlZCByYXRlcyBvZiB0cmFuc2ZlciBhbmQgdGltaW5nIHJl cXVpcmVtZW50cyBmb3IgdGhlc2UgbW9kdWxlcyBhcmUgYXQ6IGh0dHA6Ly90cmFjLnRvb2xzLmll dGYub3JnL3dnL2kycnMvdHJhYy93aWtpIC0gdW5kZXIgdGhlIHByb3RvY29sIHJlcXVpcmVtZW50 cyB0YWJsZS4NCg0KV2UgaG9wZSB0aGF0IE5FVENPTkYgV0cgY2FuIHByb3ZpZGUgc29tZSBpbml0 aWFsIGZlZWRiYWNrIG9uIHRoZXNlIHJlcXVpcmVtZW50cyBieSBJRVRGIDkzIGF0IHRoZSBUdWVz ZGF5IEkyUlMgc2Vzc2lvbi4gICBJMlJTIHdpbGwgdXNlIHRoZSA2LzI0IGludGVyaW0gYXQgMTA6 MDAtMTE6MzBhbSBFVCAgdG8gcHJvdmlkZSBhIHRpbWUgZm9yIGFueSBwYXJ0aWNpcGF0ZSBpbiB0 aGUgSTJSUywgbmV0Y29uZiwgb3IgbmV0bW9kIGdyb3VwIHRvIGFzayBhZGRpdGlvbmFsIHF1ZXN0 aW9ucyBvbiB0aGVzZSByZXF1aXJlbWVudHMuDQoNClN1ZSBIYXJlcw0KDQpJbnRlcmltIHRpbWU6 IDEwOjAwLTExOjMwYW0gRVQNCkRhdGUgNi8yNC8yMDE1DQpXZWJleDoNCmh0dHBzOi8vaWV0Zi53 ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW00MjYwYmVlN2JlNjFjYjE3YjAwMDhhM2M1MjA2OWQw Zg0KDQphZ2VuZGE6DQoNCjEwOjAwIOKAkyAxMDowNSDigJMgQmFzaCBBZ2VuZGENCjEwOjA1IOKA kyAxMDoyMC0gLSAgcmV2aWV3IG9mIHJlcXVpcmVtZW50cyBmcm9tDQpkcmFmdC1pZXRmLWkycnMt ZXBoZW1lcmFsLXN0YXRlLTAwDQpkcmFmdC1pZXRmLWkycnMtcHViLXN1Yi1yZXF1aXJlbWVudHMt MDINCmRyYWZ0LWlldGYtaTJycy10cmFjZWFiaWxpdHktMDMNClRpbWluZyByZXF1aXJlbWVudHMN Cg0KMTA6MjAg4oCTIDEwOjMwICAgIFJldmlldyBvZiByZXF1aXJlbWVudHMgZm9yIG11dHVhbCBh dXRoZW50aWNhdGlvbiwNCmFuZCB0cmFuc2FjdGlvbiBpbiAgZHJhZnQtaGFyZXMtYXV0aC10cmFu cy0wMSByZXF1aXJlbWVudHMNCg0KMTA6MzAtIDExOjMwICAgICBPcGVuIGRpc2N1c3Npb24gZm9y IEkyUlMgUmVxdWlyZW1lbnRzDQoNClByb2NlZWRpbmdzIGFuZCBzbGlkZXMgY2FuIGJlIGZvdW5k IGF0Og0KaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy9pbnRlcmltLzIwMTUvMDYvMjQv aTJycy9wcm9jZWVkaW5ncy5odG1sDQoNClN1ZSBIYXJlcw0KDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRt b2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCk1haGVzaCBKZXRoYW5hbmRhbmkNCm1qZXRoYW5h bmRhbmlAZ21haWwuY29tPG1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4NCg0KDQoNCg== --_000_EF64FF31F4C4384DBCE5D513A791C2B121B00EE1xmbalnx11ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsN CgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnAuTXNvTGlzdFBhcmFncmFw aCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxl LXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFy Z2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwi c2VyaWYiO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFw cGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9y OiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0 OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRl eHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxs b29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDox ODkyMzAyNTU1Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlk czotMTMyNDQyNzg3MiA2NzY5ODcwNSA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcx MyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDEN Cgl7bXNvLWxldmVsLXRleHQ6IiUxXCkiOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxp c3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0 IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21h bi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7 bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz dCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsN Cgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7 bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5JIHByZXNlbnRlZCBQdWJTdWIg4oCYLTAx4oCZIHJlcXVpcmVtZW50cyBpbiBORVRDT05GIGF0 IElFVEYgOTIuJm5ic3A7Jm5ic3A7ICZuYnNwO0NoYW5nZXMgaW4g4oCYLTAy4oCZIGFyZSBsaWtl bHkgbm90IGVub3VnaCBmb3IgYSBzcGVha2luZyBzbG90LiZuYnNwOyZuYnNwOw0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5XaGF0IG1pZ2h0IGJlIGludGVyZXN0aW5nIGZvciBhIE5FVENPTkYgc3BlYWtpbmcgc2xvdCBp cyBhbiBhbmFseXNpcyBvZiB3aGF0IHJlcXVpcmVtZW50cyBmcm9tIOKAnGRyYWZ0LWlldGYtaTJy cy1wdWItc3ViLXJlcXVpcmVtZW50c+KAnSBhcmUgbWV0IGJ5IOKAnGRyYWZ0LWNsZW1tLW5ldGNv bmYteWFuZy1wdXNo4oCdLiZuYnNwOyZuYnNwOw0KIChEdXJpbmcgSUVURiA5MiwgTkVUQ09ORiBy ZXZpZXdlZCBkcmFmdC1jbGVtbS4gVGhlcmUgd2FzIGEgc3RyYXdtYW4gcG9sbCAoMTIgeWVzLCAw IG5vKSB3aGVyZSB0aGUgV0cgaW5kaWNhdGVkIGludGVyZXN0Lik8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldvdWxkIE5F VENPTkYgd2FudCBBbGV4IG9yIEkgdG8gc3BlYWsgb24gYSByZXF1aXJlbWVudHMtdG8tdGVjaG5v bG9neSBjb21wYXJpc29uIGluIFByYWd1ZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkVyaWM8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUnRnLXlhbmctY29vcmQgW21haWx0bzpydGct eWFuZy1jb29yZC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5TdXNhbiBI YXJlczxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKdW5lIDMwLCAyMDE1IDU6MTYgUE08YnI+ DQo8Yj5Ubzo8L2I+ICdNYWhlc2ggSmV0aGFuYW5kYW5pJzxicj4NCjxiPkNjOjwvYj4gUnRnLXlh bmctY29vcmRAaWV0Zi5vcmc7IGkycnNAaWV0Zi5vcmc7ICdORVRNT0QgV29ya2luZyBHcm91cCc7 ICdOZXRjb25mJzsgJ0JSVU5HQVJELCBERUJPUkFIIEEnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBbUnRnLXlhbmctY29vcmRdIFtuZXRtb2RdIFJlcXVpcmVtZW50cyBmb3IgSTJSUyBwcm90b2Nv bCBhbmQgSTJSUyBpbnRlcmltICg2LzI0LzIwMTUgYXQgMTA6MDAgLSAxMTozMGFtIEVUKTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1haGVzaDoNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Pay4gJm5ic3A7SSB0aG91Z2h0IHlv dSB3ZXJlIGdvaW5nIHRvIHJldmlldyB0aGUgcmVxdWlyZW1lbnQgZG9jdW1lbnRzIGFuZCBnaXZl IEkyUlMgYW4gaW5pdGlhbCBndWVzcy4mbmJzcDsgV2UgaGF2ZSBwcmVzZW50IHRoZXNlIGF0IDMg STJSUw0KIGludGVyaW1zLCBhbmQgdGhlIHNsaWRlcyBhcmUgb25saW5lLiZuYnNwOyBJIHdpbGwg c2VuZCB0aGUgbWludXRlcyB0byB0aGUgbmV0Y29uZiB3b3JraW5nIGdyb3VwIGZvciB0aGVpciBy ZXZpZXcuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+VGhlIHByZXNlbnRhdGlvbiBvZiB0aGUgcmVxdWlyZW1lbnRzIHdpbGwgbmVl ZCB0aGUgZm9sbG93aW5nIHRpbWU6DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW47dGV4dC1pbmRl bnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNd PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0i bXNvLWxpc3Q6SWdub3JlIj4xKTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9z cGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjEwIHRvcCByZXF1aXJlbWVudHMg4oCTIDUtMTAgbWludXRlcyBbU3VlIEhhcmVzXQ0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJtYXJnaW4tbGVmdDoxLjBpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzIiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjIpPHNwYW4gc3R5 bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RXBoZW1lcmFsIHN0YXRlIOKAkyAx NSBtaW51dGVzIFtKZWZmIEhhYXNdDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluO3RleHQtaW5kZW50Oi0u MjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1s aXN0Oklnbm9yZSI+Myk8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48 L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5QdWIvc3ViIHJlcXVpcmVtZW50cyDigJMgMTAtMTUgbWludXRlcyBbRXJpYyBWb2l0XTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MS4waW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8y Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj40KTxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRyYWNlYWJpbGl0eSBbIDEwLTE1IG1pbnV0 ZXNdDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+NSk8c3Bh biBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TZWN1cml0eSBbMTAgbWlu dXRlc10gW1N1ZSBIYXJlcyBhbmQgSm9lbCBIYWxwZXJuXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW47dGV4 dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4NCjwhW2lmICFzdXBwb3J0 TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj42KTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3Nw YW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlJldmlldyBvZiBJMlJTIG1vZGVscyBbNSBtaW51dGVzXQ0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4t bGVmdDoxLjBpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPg0K PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjcpPHNwYW4gc3R5bGU9ImZvbnQ6 Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JZiB5b3UgaGF2ZSBoZWFyZCBwdWIvc3Vi IGFuZCB0cmFjZWFiaWxpdHkgcmVxdWlyZW1lbnRzLCB5b3UgbWF5IGRlbGV0ZSB0aGlzIGZyb20g dGltZWxpbmUuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+U3VlIEhhcmVzDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFJ0Zy15YW5nLWNvb3JkIFs8 YSBocmVmPSJtYWlsdG86cnRnLXlhbmctY29vcmQtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnJ0 Zy15YW5nLWNvb3JkLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5N YWhlc2ggSmV0aGFuYW5kYW5pPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEp1bmUgMzAsIDIw MTUgMzo0NCBQTTxicj4NCjxiPlRvOjwvYj4gU3VzYW4gSGFyZXM8YnI+DQo8Yj5DYzo8L2I+IDxh IGhyZWY9Im1haWx0bzpSdGcteWFuZy1jb29yZEBpZXRmLm9yZyI+UnRnLXlhbmctY29vcmRAaWV0 Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86aTJyc0BpZXRmLm9yZyI+DQppMnJzQGlldGYub3Jn PC9hPjsgQlJVTkdBUkQsIERFQk9SQUggQTsgTmV0Y29uZjsgTkVUTU9EIFdvcmtpbmcgR3JvdXA8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtSdGcteWFuZy1jb29yZF0gW25ldG1vZF0gUmVxdWly ZW1lbnRzIGZvciBJMlJTIHByb3RvY29sIGFuZCBJMlJTIGludGVyaW0gKDYvMjQvMjAxNSBhdCAx MDowMCAtIDExOjMwYW0gRVQpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij5TdXNhbiw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhlIE5FVENP TkYgV0cgYWNrbm93bGVkZ2VzIHRoZSByZWNlaXB0IG9mIHRoZSByZXF1aXJlbWVudHMuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhlc2UgcmVxdWlyZW1l bnRzIG5lZWQgdG8gYmUgZGlzY3Vzc2VkIGluIGZyb250IG9mIHRoZSBORVRDT05GIFdHLiBXb3Vs ZCBzdWdnZXN0IHRoYXQgaTJycyBXRyBwcmVzZW50IHRoZXNlIHJlcXVpcmVtZW50cyBpbiBmcm9u dCBvZiB0aGUgTkVUQ09ORiBXRyBkdXJpbmcgSUVURiA5MyBpbiBQcmFndWUgdG8ga2ljayBzdGFy dCBkaXNjdXNzaW9uIHdpdGhpbiB0aGUgV0cuDQogUGxlYXNlIGxldCB1cyBrbm93IGhvdyBtdWNo IHRpbWUgeW91IChvciBzb21lb25lIGZyb20gaTJycykgd291bGQgbmVlZCB0byBwcmVzZW50IHRo ZSByZXF1aXJlbWVudHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+VGhhbmtzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj5PbiBKdW4gMjMsIDIwMTUsIGF0IDExOjE5IEFNLCBTdXNhbiBIYXJlcyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnNoYXJlc0BuZHpoLmNvbSI+c2hhcmVzQG5kemguY29tPC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+TmV0Y29uZiBXb3JraW5nIEdyb3VwOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGUgSTJSUyBXRyB3b3VsZCBsaWtlIHRv IHBhc3MgeW91IGEgc2V0IG9mIHJlcXVpcmVtZW50cyBmb3IgdGhlIEkyUlMgcHJvdG9jb2wsIGFu ZCBhc2tzIHRoYXQgeW91IHByb3ZpZGUgYW4gYW5hbHlzaXMgYnkgSUVURiA5MyBvbiB3aGV0aGVy IE5FVENPTkYNCiBvciBSRVNUQ09ORiBjYW4gbWVldCB0aGVzZSByZXF1aXJlbWVudHMuJm5ic3A7 Jm5ic3A7IFdlIGV4cGVjdCB0aGF0IHRoZXNlIHJlcXVpcmVtZW50cyBtYXkgcmVxdWlyZSBjaGFu Z2VzIHRvIHRoZSBlaXRoZXIgTkVUQ09ORiBvciBSRVNUQ09ORi4mbmJzcDs8c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhlIEkyUlMgYXJjaGl0 ZWN0dXJlIGRvY3VtZW50ICg8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLWkycnMtYXJjaGl0ZWN0dXJlLyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS41cHQ7Y29sb3I6IzNEMjJCMztiYWNrZ3JvdW5kOndoaXRlO3RleHQtZGVjb3JhdGlvbjpub25l Ij5kcmFmdC1pZXRmLWkycnMtYXJjaGl0ZWN0dXJlLTA5PC9zcGFuPjwvYT48L3NwYW4+PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMyMjIyMjI7YmFja2dyb3VuZDp3aGl0ZSI+KSZuYnNwOzwvc3Bhbj48L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5wcm92aWRlcw0KIGEgaGlnaC1sZXZlbCBvdmVydmll dyBvZiB0aGUgSTJSUyAmbmJzcDtwcm90b2NvbC4mbmJzcDsgVGhlIEkyUlMgaGFzIGNvbXBpbGVk IHRoZSBmb2xsb3dpbmcgZG9jdW1lbnRzIHRvIHByb3ZpZGUgdGhlIGFkZGl0aW9uYWwgZGV0YWls cyBvbiB0aGUgcmVxdWlyZW1lbnRzIGZvciB0aGUgcHJvdG9jb2xzLjxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluIj48c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPjEpPC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGEgaHJl Zj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pMnJzLWVwaGVt ZXJhbC1zdGF0ZS8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2NvbG9yOiMzRDIyQjM7 YmFja2dyb3VuZDojRjlGOUY5O3RleHQtZGVjb3JhdGlvbjpub25lIj5kcmFmdC1pZXRmLWkycnMt ZXBoZW1lcmFsLXN0YXRlLTAwPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjI7 YmFja2dyb3VuZDojRjlGOUY5Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluO3RleHQtaW5kZW50Oi0uMjVpbiI+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4yKTwvc3Bhbj48L3NwYW4+PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBw dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaTJycy1wdWItc3ViLXJlcXVpcmVtZW50cy8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuNXB0O2NvbG9yOiMzRDIyQjM7YmFja2dyb3VuZDojRjlGOUY5O3Rl eHQtZGVjb3JhdGlvbjpub25lIj5kcmFmdC1pZXRmLWkycnMtcHViLXN1Yi1yZXF1aXJlbWVudHMt MDI8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMjtiYWNrZ3JvdW5kOiNGOUY5 RjkiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRl bnQ6LS4yNWluIj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPjMpPC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1pMnJzLXRyYWNlYWJpbGl0eS8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2Nv bG9yOiMzRDIyQjM7YmFja2dyb3VuZDp3aGl0ZTt0ZXh0LWRlY29yYXRpb246bm9uZSI+ZHJhZnQt aWV0Zi1pMnJzLXRyYWNlYWJpbGl0eS0wMzwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MjIyMjIyO2JhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGUgZHJhZnQtaWV0Zi1pMnJzLWVwaGVtZXJh bC1zdGF0ZS0wMCBjb250YWlucyB0aGUgcmVzdWx0cyBvZiB0aGUgZGlzY3Vzc2lvbiBmcm9tIHRo ZSA2LzEwIGludGVyaW0gYW5kIHRoZSB0b3AgMTAgcmVxdWlyZW1lbnRzIGZvciBJMlJTLiZuYnNw OyBJbiBhZGRpdGlvbiwNCiB0aGUgZHJhZnQtaWV0Zi1pMnJzLWVwaGVtZXJhbC1zdGF0ZS0wMCBj b250YWlucyBhbiBzZXQgb2YgZGV0YWlsZWQgcmVxdWlyZW1lbnRzIG9uIGhvdyB0aGUgSTJSUyBX RyBzZWVzIHRoZSBJMlJTIHByb3RvY29sIG9wZXJhdGluZy4mbmJzcDsgVGhlc2UgZGV0YWlsZWQg cmVxdWlyZW1lbnRzIGFyZSB0byBiZSBzZWVuIGFzIHN1Z2dlc3Rpb25zIG9uIHdoYXQgdHlwZSBv ZiBzb2x1dGlvbiB0aGUgSTJSUyBXRyB3b3VsZCBsaWtlIHRvIHNlZSwgYnV0IEkyUlMNCiBXRyBp cyBhc2tpbmcgdGhlIE5FVENPTkYgV0cgdG8gcHJvdmlkZSBpdHMgYmVzdCBkZXNpZ25lZCBwcm90 b2NvbC4mbmJzcDsgUGxlYXNlIG5vdGUgYXMgcGFydCBvZiB0aGVzZSBkZXRhaWxlZCByZXF1aXJl bWVudCB0aGUgZHJhZnQtaWV0Zi1pMnJzLWVwaGVtZXJhbC1zdGF0ZXMtMDAgY29udGFpbnMgdGhl IGlkZWEgb2YgdXNpbmcgbWV0YWRhdGEgdG8gcmVjb3JkIHNlY29uZGFyeSBpZGVudGl0eS4gJm5i c3A7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+VGhlIEkyUlMgcHJvdG9jb2wgaXMgZHJpdmVuIGJ5IGRhdGEtbW9kZWxz LiZuYnNwOyBUaGUgYXBwcm92ZWQgZGF0YSBtb2RlbHMgZm9yIHByb3RvY29sIGluZGVwZW5kZW50 IHNlcnZpY2VzIGFyZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi Pi08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtaTJycy1yaWItZGF0YS1tb2RlbC8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2Nv bG9yOiMzRDIyQjM7YmFja2dyb3VuZDp3aGl0ZTt0ZXh0LWRlY29yYXRpb246bm9uZSI+ZHJhZnQt aWV0Zi1pMnJzLXJpYi1kYXRhLW1vZGVsLTAwPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluIj48c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPi08L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5GaWx0ZXItQmFzZWQNCiBSSUJTOiZuYnNwOzxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMy MjIyMjI7YmFja2dyb3VuZDp3aGl0ZSI+ZHJhZnQta2luaS1pMnJzLWZiLXJpYi1kYXRhLW1vZGVs LjAwIChyZWxlYXNlZCBsYXRlciB0aGlzIHdlZWspPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbjt0ZXh0LWluZGVudDotLjI1aW4iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+LTwvc3Bhbj48L3NwYW4+PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3 LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMjtiYWNrZ3JvdW5kOndo aXRlIj5Ub3BvbG9neQ0KIG1vZGVsIHdoaWNoIGlzIGEgY29tcG9zaXRlIG9mOjwvc3Bhbj48L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQtaW5kZW50Oi0uMjVpbiI+PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPm88L3NwYW4+PC9zcGFuPjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4w cHQiPiZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjI7 YmFja2dyb3VuZDp3aGl0ZSI+R2VuZXJpYw0KIHRvcG9sb2d5IG1vZGVsOiZuYnNwOzwvc3Bhbj48 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWkycnMteWFuZy1uZXR3b3JrLXRvcG8vIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtjb2xvcjojM0QyMkIzO2JhY2tncm91bmQ6d2hp dGU7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmRyYWZ0LWlldGYtaTJycy15YW5nLW5ldHdvcmstdG9w by0wMTwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyO2JhY2tncm91bmQ6d2hp dGUiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQtaW5k ZW50Oi0uMjVpbiI+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi Pm88L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48L3NwYW4+ PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMyMjIyMjI7YmFja2dyb3VuZDp3aGl0ZSI+TDMNCiB0b3BvbG9neSBtb2Rl bDo8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtaTJycy15YW5nLWwzLXRvcG9sb2d5LyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS41cHQ7Y29sb3I6IzNEMjJCMztiYWNrZ3JvdW5kOiNGOUY5Rjk7dGV4dC1kZWNvcmF0aW9u Om5vbmUiPmRyYWZ0LWlldGYtaTJycy15YW5nLWwzLXRvcG9sb2d5LTAwPC9zcGFuPjwvYT48L3Nw YW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjI7YmFja2dyb3VuZDojRjlGOUY5Ij4mbmJzcDs8L3NwYW4+ PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVudDotLjI1aW4iPjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5vPC9zcGFuPjwvc3Bhbj48 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIy MjIyO2JhY2tncm91bmQ6d2hpdGUiPkwyDQogdG9wb2xvZ3kgbW9kZWw6Jm5ic3A7PC9zcGFuPjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaTJycy15YW5nLWwyLW5ldHdvcmstdG9wb2xv Z3kvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtjb2xvcjojM0QyMkIzO2JhY2tncm91 bmQ6d2hpdGU7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmRyYWZ0LWlldGYtaTJycy15YW5nLWwyLW5l dHdvcmstdG9wb2xvZ3ktMDA8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMjti YWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW4tbGVmdDoxLjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbjt0ZXh0LWluZGVudDotLjI1aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5vPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjI7YmFja2dyb3Vu ZDp3aGl0ZSI+TDENCiBUb3BvbG9neSBtb2RlbDo8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7 PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmRyYWZ0LXpoYW5nLWky cnMtbDEtdG9wby15YW5nLW1vZGVsLTAxICgtMDINCiByZWxlYXNlZCBsYXRlciB0aGlzIHdlZWsp LjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQtaW5kZW50 Oi0uMjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPm88L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+ Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMjtiYWNrZ3JvdW5kOndoaXRlIj5TZXJ2aWNl DQogdG9wb2xvZ3kgbW9kZWw6PC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5kcmFmdC1oYXJlcy1pMnJzLXNlcnZpY2Ut dG9wby15YW5nLW1vZGVsLTAwDQogKHJlbGVhc2VkIG9uIFdlZG5lc2RheSk8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5BdCB0aGlz IHRpbWUsIG5vbmUgb2YgdGhlIFRvcG9sb2d5IG1vZGVscyB1dGlsaXplIFRyYWZmaWMgZW5naW5l ZXJpbmcuJm5ic3A7IEl0IGlzIGFudGljaXBhdGVkIHRoYXQgdGhlc2UgbW9kZWxzIHdpbGwgc3Vw cG9ydCB0cmFmZmljIGVuZ2luZWVyaW5nLiAmbmJzcDtFc3RpbWF0ZWQNCiByYXRlcyBvZiB0cmFu c2ZlciBhbmQgdGltaW5nIHJlcXVpcmVtZW50cyBmb3IgdGhlc2UgbW9kdWxlcyBhcmUgYXQ6PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0 dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL2kycnMvdHJhYy93aWtpIj48c3BhbiBzdHlsZT0i Y29sb3I6cHVycGxlIj5odHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9pMnJzL3RyYWMvd2lr aTwvc3Bhbj48L2E+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPi0NCiB1bmRlciB0aGUgcHJvdG9jb2wgcmVxdWlyZW1lbnRzIHRhYmxlLjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5XZSBob3BlIHRoYXQg TkVUQ09ORiBXRyBjYW4gcHJvdmlkZSBzb21lIGluaXRpYWwgZmVlZGJhY2sgb24gdGhlc2UgcmVx dWlyZW1lbnRzIGJ5IElFVEYgOTMgYXQgdGhlIFR1ZXNkYXkgSTJSUyBzZXNzaW9uLiZuYnNwOyZu YnNwOyBJMlJTIHdpbGwgdXNlIHRoZSA2LzI0DQogaW50ZXJpbSBhdCAxMDowMC0xMTozMGFtIEVU ICZuYnNwO3RvIHByb3ZpZGUgYSB0aW1lIGZvciBhbnkgcGFydGljaXBhdGUgaW4gdGhlIEkyUlMs IG5ldGNvbmYsIG9yIG5ldG1vZCBncm91cCB0byBhc2sgYWRkaXRpb25hbCBxdWVzdGlvbnMgb24g dGhlc2UgcmVxdWlyZW1lbnRzLjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5TdWUgSGFyZXM8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SW50ZXJpbSB0aW1lOiAxMDowMC0xMTozMGFtIEVUPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGF0 ZSA2LzI0LzIwMTU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5XZWJleDo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+PGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9 bTQyNjBiZWU3YmU2MWNiMTdiMDAwOGEzYzUyMDY5ZDBmIj48c3BhbiBzdHlsZT0iY29sb3I6cHVy cGxlIj5odHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tNDI2MGJlZTdiZTYx Y2IxN2IwMDA4YTNjNTIwNjlkMGY8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmFnZW5kYTo8c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+MTA6MDAg4oCTIDEwOjA1 IOKAkyBCYXNoIEFnZW5kYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPjEwOjA1IOKAkyAxMDoyMC0gLSZuYnNwOyByZXZpZXcgb2YgcmVxdWly ZW1lbnRzIGZyb208bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW47dGV4dC1pbmRlbnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5kcmFm dC1pZXRmLWkycnMtZXBoZW1lcmFsLXN0YXRlLTAwPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQtaW5kZW50Oi41aW4iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+ZHJhZnQtaWV0Zi1pMnJzLXB1Yi1zdWItcmVxdWlyZW1lbnRzLTAyPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQtaW5k ZW50Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ZHJhZnQtaWV0Zi1pMnJzLXRy YWNlYWJpbGl0eS0wMzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbjt0ZXh0LWluZGVudDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRp bWluZyByZXF1aXJlbWVudHM8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluO3RleHQtaW5kZW50Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ MTA6MjAg4oCTIDEwOjMwJm5ic3A7Jm5ic3A7Jm5ic3A7IFJldmlldyBvZiByZXF1aXJlbWVudHMg Zm9yIG11dHVhbCBhdXRoZW50aWNhdGlvbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5hbmQgdHJhbnNhY3Rpb24gaW4gJm5ic3A7ZHJhZnQtaGFyZXMtYXV0aC10cmFu cy0wMSByZXF1aXJlbWVudHM8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+MTA6MzAtIDExOjMwICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO09wZW4g ZGlzY3Vzc2lvbiBmb3IgSTJSUyBSZXF1aXJlbWVudHM8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+UHJvY2VlZGluZ3MgYW5kIHNsaWRlcyBjYW4g YmUgZm91bmQgYXQ6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPjxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvaW50ZXJpbS8yMDE1 LzA2LzI0L2kycnMvcHJvY2VlZGluZ3MuaHRtbCI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ aHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy9pbnRlcmltLzIwMTUvMDYvMjQvaTJycy9w cm9jZWVkaW5ncy5odG1sPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TdWUgSGFyZXM8c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpuZXRtb2QgbWFpbGluZyBsaXN0PGJy Pg0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6cHVycGxlIj5uZXRtb2RAaWV0Zi5vcmc8L3NwYW4+PC9hPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCjwvc3Bhbj48YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbmV0bW9kPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5NYWhlc2ggSmV0aGFuYW5kYW5pPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PGEgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tIj5tamV0 aGFuYW5kYW5pQGdtYWlsLmNvbTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_EF64FF31F4C4384DBCE5D513A791C2B121B00EE1xmbalnx11ciscoc_--