From nobody Sat Aug 1 09:51:32 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB3741A005A for ; Sat, 1 Aug 2015 09:51: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 pOWm2eXwvf7q for ; Sat, 1 Aug 2015 09:51:30 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41ED91A0058 for ; Sat, 1 Aug 2015 09:51:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2424; q=dns/txt; s=iport; t=1438447890; x=1439657490; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=5iN141kOMocC5Os76JT9PtKsijNiLcxB0CvevW4qB7U=; b=e+2AKqiRh0ExOhICifySEm1cRzDbmGotiPFCHOiWQrvA04+jy/EL3s0B 5zi4P5XEpfFWLT7s6BZENC79VnA2QaIxNHEq7Ae3T8P607SQ+pDbBMw+C 9gKuSZCT87AYlAxenIPMEJGDLGwAfeJpUAOAaLy9BjbyteA7rg3RAssRD I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BzAwBK+LxV/49dJa1YAxkBAQGCflRpBoMduSQJgVgiCoUvSgIcgQY4FAEBAQEBAQGBCoQkAQEBAwEBASAROgsOAgIBCA4CCAICJgICAhkMCxUQAgQBDQUbiBMNsnKVXAEBAQEBAQEBAQEBAQEBAQEBAQEBARcEgR6KLYRVGAsQBxKCV4FDBZR5AYxLgUeHNJBNJoN9bwGBR4EEAQEB X-IronPort-AV: E=Sophos;i="5.15,592,1432598400"; d="scan'208";a="174607304" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-4.cisco.com with ESMTP; 01 Aug 2015 16:51:29 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t71GpTWs000918 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 1 Aug 2015 16:51:29 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.80]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Sat, 1 Aug 2015 11:51:29 -0500 From: "Acee Lindem (acee)" To: Juergen Schoenwaelder , Lou Berger Thread-Topic: [netmod] Y34 Thread-Index: AQHQwun4N/mOpIK+o0+8Bax//aiDw53koqAAgAAB9wCAAAOxAIAAH1sAgAAl1QCAAAOsgIAAA9aAgAA3SgCABy78gIACOXiAgABATICAAGEgAIAAn0CAgAATdYCABkYhgIAA7BgAgAB1QQA= Date: Sat, 1 Aug 2015 16:51:28 +0000 Message-ID: References: <20150720210041.GA17614@elstar.local> <14ecceb6dd0.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <14ed0338068.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <55BBA679.7070508@labn.net> <20150801065150.GA67416@elstar.local> In-Reply-To: <20150801065150.GA67416@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.37.102.14] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Y34 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Aug 2015 16:51:31 -0000 SGkgSnVlcmdlbiwgDQoNCk9uIDgvMS8xNSwgMjo1MSBBTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2Yg SnVlcmdlbiBTY2hvZW53YWVsZGVyIg0KPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFs ZiBvZg0Kai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPiB3cm90ZToNCg0KPk9u IEZyaSwgSnVsIDMxLCAyMDE1IGF0IDEyOjQ2OjQ5UE0gLTA0MDAsIExvdSBCZXJnZXIgd3JvdGU6 DQo+PiBBbmR5LA0KPj4gDQo+PiBPbiAwNy8yNy8yMDE1IDEyOjU4IFBNLCBBbmR5IEJpZXJtYW4g d3JvdGU6DQo+PiA+IEhpLA0KPj4gPiANCj4+ID4gSSBkb24ndCB0aGluayBhIHN0YW5kYXJkIGZv ciByZWxvY2F0aW5nIHN1YnRyZWVzIHdvdWxkIGJlIHdvcnRoIGl0Lg0KPj4gPiBJIGFtIG5vdCBp biBmYXZvciBvZiBtb3ZpbmcgL2ludGVyZmFjZXMgb3IgL3N5c3RlbSB0byBhIG5ldyBsb2NhdGlv bi4NCj4+ID4gVGhhdCdzIG5vdCBob3cgWUFORyB3b3Jrcy4gSXQgb25seSBhbGxvd3MgIm9ic29s ZXRlIGFuZCBzdGFydCBvdmVyIi4NCj4+ID4gDQo+PiA+IEkgd291bGQgc3VnZ2VzdCBwdXJzdWlu ZyBzb2x1dGlvbnMgdGhhdCBkb24ndCBjYXVzZQ0KPj4gPiBhcyBtdWNoIGRpc3J1cHRpb24gYW5k IGV4cGVuc2UgYXMgcG9zc2libGUuDQo+PiA+IA0KPj4gDQo+PiBJIHRoaW5rIGl0IHdvdWxkIGJl IHJlYWxseSBnb29kIHRvIGV4cGxvcmUgb3RoZXIsIGxlc3MgImRpc3J1cHRpdmUiDQo+PiBvcHRp b25zLg0KPj4NCj4NCj5JIHRoaW5rIHRoZSBmaXJzdCBzdGVwIGlzIHRvIGZpbmQgb3V0IHdoZXRo ZXIgdGhlcmUgaXMgYSBwcm9ibGVtIHdvcnRoDQo+dG8gYmUgZml4ZWQuIFdoeSBhcmUgdGhlIFJG Q3MgaW4gcXVlc3Rpb24gYnJva2VuPyAoWWVzLCBJIGhhdmUgcmVhZA0KPnRoZSBvcGVuY29uZmln IElEcywNCg0KU2VjdGlvbiAxLjEgaW4gDQpodHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1v cGVuY29uZmlnLW5ldG1vZC1tb2RlbC1zdHJ1Y3R1cmUtMDAudHh0DQpsaXN0cyB0aGUgZ29hbHMg b2YgYSBnZW5lcmljIG1vZGVsIHN0cnVjdHVyZSB0aGF0IHdpbGwgYWNjb21tb2RhdGUgbW9zdA0K bW9kZXJuIG5ldHdvcmsgZGV2aWNlcy4gSSBndWVzcyB5b3UgZG9u4oCZdCBhZ3JlZSB0aGF0IHRo ZXNlIGFyZSBkZXNpcmFibGU/DQoNClRoYW5rcywNCkFjZWUgDQoNCg0KDQo+SSBsaXN0ZW5lZCB0 byB0aGUgdmlydHVhbCBpbnRlcmltIG1lZXRpbmdzLCBJDQo+YXNzdW1lIHlvdSBoYXZlIHJlYWQg ZHJhZnQtYmpvcmtsdW5kLW5ldG1vZC1vcGVuY29uZmlnLXJlcGx5LikNCg0KDQoNCj4NCj5MZXRz IGdldCB0aGUgY29yZSBvZiB0aGUgb3BlbmNvbmZpZyBhcmd1bWVudCBvbiB0aGUgdGFibGUgd2h5 IHRoZQ0KPmV4aXN0aW5nIFJGQ3MgYXJlIGZsYXdlZC4NCj4NCj4vanMNCj4NCj4tLSANCj5KdWVy Z2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21i SA0KPlBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5 IEJyZW1lbiB8IEdlcm1hbnkNCj5GYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRw Oi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4NCj4NCj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPm5ldG1vZCBtYWlsaW5nIGxpc3QNCj5uZXRtb2RA aWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0K DQo= From nobody Sat Aug 1 10:23:41 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6EC21A00E8 for ; Sat, 1 Aug 2015 10:23:38 -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 wvGGWkgthY7m for ; Sat, 1 Aug 2015 10:23: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 4AFBE1A00CD for ; Sat, 1 Aug 2015 10:23: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 DCC471631; Sat, 1 Aug 2015 19:23: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 H1jKQ_Cpxuvt; Sat, 1 Aug 2015 19:23:27 +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, 1 Aug 2015 19:23:27 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 196EA20046; Sat, 1 Aug 2015 19:23: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 1XFvDqL5FgPx; Sat, 1 Aug 2015 19:23:51 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DE6AC20045; Sat, 1 Aug 2015 19:23:30 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AFDEE36071B3; Sat, 1 Aug 2015 19:23:28 +0200 (CEST) Date: Sat, 1 Aug 2015 19:23:27 +0200 From: Juergen Schoenwaelder To: "Acee Lindem (acee)" Message-ID: <20150801172325.GA68312@elstar.local> Mail-Followup-To: "Acee Lindem (acee)" , Lou Berger , NETMOD Working Group References: <20150720210041.GA17614@elstar.local> <14ecceb6dd0.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <14ed0338068.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <55BBA679.7070508@labn.net> <20150801065150.GA67416@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Y34 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Aug 2015 17:23:38 -0000 On Sat, Aug 01, 2015 at 04:51:28PM +0000, Acee Lindem (acee) wrote: > > Section 1.1 in > https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt > lists the goals of a generic model structure that will accommodate most > modern network devices. I guess you don’t agree that these are desirable? o a common schema to access data related to all aspects of a device This is why we produce standards. They are a common schema. o an extensible structure that makes it clear where additional models or data should be fit (e.g., using YANG augmentation or imports) This is why we have /interfaces. Interface related stuff goes here. It is easy to reference. o a place for including metadata that provides useful information about the corresponding individual models, such as which organization provides them, which vendors support them, or which version of the model is deployed Not really sure what this means. YANG modules have meta data. A NETCONF or RESTCONF server exposes which data models it implements. A list of which vendor supports what is clearly outside the scope of IETF work. o a common infrastructure model layer on which higher layer service models can be built, for example by specifying which models are needed to provide the service Not sure what this means exactly but I also do not see why any of the existing RFCs breaks this. o an ability to express an instance of the structure consisting of models that have been validated to work together (i.e., with information about sources of the models, their versions, etc.), so that operators can easily identify a set of models that is known to be mutually consistent Not sure what this means exactly but YANG modules published by the IETF are supposed to work together. YANG 1.1 has even clearer rules what imports mean etc. Bottom line is that I do not get out of these bullets what is _broken_ with the existing RFCs. I like to see text of the sort - RFC 7223 is broken because ... - RFC 7277 is broken because ... [...] This text is not in section 1.1 as far as I can tell. Bottom line is that I do not understand why /interfaces is broken such that this needs to be redone while /device/interfaces is golden. What do we do if in two years some group of people find /device/network/interfaces a brilliant idea? /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 Aug 1 11:05:57 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47F691A0277 for ; Sat, 1 Aug 2015 11:05:55 -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 TEhvJQzQtlGu for ; Sat, 1 Aug 2015 11:05:53 -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 92F831A026F for ; Sat, 1 Aug 2015 11:05:52 -0700 (PDT) Received: by lbbyj8 with SMTP id yj8so61412110lbb.0 for ; Sat, 01 Aug 2015 11:05: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=tMWJxFozUYd+m8p78d21r4zyj50QB3jHfJHGFFVFGKY=; b=C59eK5iE8iSINa6+TrTdkNaIe1vn4jPTo2PmfG078naMvF+rO5g8E9oTPCvT79Q4H5 5PA5ECXVcTOx9IvGTELNg+Ir4JhxqYoE2HbPT/L0a6xXo9nboHYWA1PNWrKCQwX4T0fj b7PSEUPuPz9a6vxYxhAOAV7uoTPeIVP8pibfY8ntNW2h0UvEDO02Ii+g1JHgWPLh6Ffy gSpiXWp5GFAq4rF8HywJXdWHKOTLP4HfiHqZXRu23dGijGQU4R+89YXvMHJr5nGMnzbT lFwbP3ecjCvhHEvcXRQB/G6Xco40aMRjZnztfQrQTYDpKiqYu9cQFDk7zBJR8arHqxf6 cOqw== X-Gm-Message-State: ALoCoQkwzXen864P8WWeEVVcjDaCKlm/20vFaDSRmThA9VPDlWW8oTsMs8TNTa4FPqKvV18SKTyU MIME-Version: 1.0 X-Received: by 10.152.7.65 with SMTP id h1mr9193479laa.33.1438452350759; Sat, 01 Aug 2015 11:05:50 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Sat, 1 Aug 2015 11:05:50 -0700 (PDT) In-Reply-To: References: <20150720210041.GA17614@elstar.local> <14ecceb6dd0.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <14ed0338068.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <55BBA679.7070508@labn.net> <20150801065150.GA67416@elstar.local> Date: Sat, 1 Aug 2015 11:05:50 -0700 Message-ID: From: Andy Bierman To: "Acee Lindem (acee)" Content-Type: multipart/alternative; boundary=001a11c27cf064cffb051c43c9ff Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Y34 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Aug 2015 18:05:55 -0000 --001a11c27cf064cffb051c43c9ff Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem (acee) wrote: > Hi Juergen, > > On 8/1/15, 2:51 AM, "netmod on behalf of Juergen Schoenwaelder" > j.schoenwaelder@jacobs-university.de> wrote: > > >On Fri, Jul 31, 2015 at 12:46:49PM -0400, Lou Berger wrote: > >> Andy, > >> > >> On 07/27/2015 12:58 PM, Andy Bierman wrote: > >> > Hi, > >> > > >> > I don't think a standard for relocating subtrees would be worth it. > >> > I am not in favor of moving /interfaces or /system to a new location= . > >> > That's not how YANG works. It only allows "obsolete and start over". > >> > > >> > I would suggest pursuing solutions that don't cause > >> > as much disruption and expense as possible. > >> > > >> > >> I think it would be really good to explore other, less "disruptive" > >> options. > >> > > > >I think the first step is to find out whether there is a problem worth > >to be fixed. Why are the RFCs in question broken? (Yes, I have read > >the openconfig IDs, > > Section 1.1 in > https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt > lists the goals of a generic model structure that will accommodate most > modern network devices. I guess you don=E2=80=99t agree that these are de= sirable? > > The only objection I have to this draft is the insertion of a top-level roo= t called "device". (Might as well be called "self"). There are no sibling nodes planned or intended for this node, so it serves as an extra document root. The well-specified XPath and YANG root (/) can be accessed by all protocol operations, exactly the same as a node called 'device'. The actual node name will depend on the RPC function (e.g. 'data' or 'config'). This is more than redundant however. It introduces a "super-module" into YANG that every other module is expected to augment. YANG is intended to be more loosely coupled than that. This introduces an extra node and namespace declaration in all protocol messages, increasing message sizes. It also assumes all existing YANG models will get rewritten to account for "/device" in all path and XPath expressions. This is highly disruptive to existing deployments. Also, multiple data models to edit the same thing causes lots of extra complexity in the server (supporting both old location and new location). IMO a resource directory approach is much more realistic. The /device tree can contain all the organized NP containers. Instead of all the actual data nodes, this tree just has pointers to the real location of the resource. (like 301 Moved Permanently) Thanks, > Acee > > > Andy > > >I listened to the virtual interim meetings, I > >assume you have read draft-bjorklund-netmod-openconfig-reply.) > > > > > > >Lets get the core of the openconfig argument on the table why the > >existing RFCs are flawed. > > > >/js > > > >-- > >Juergen Schoenwaelder Jacobs University Bremen gGmbH > >Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > >Fax: +49 421 200 3103 > > > >_______________________________________________ > >netmod mailing list > >netmod@ietf.org > >https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a11c27cf064cffb051c43c9ff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem (acee) &l= t;acee@cisco.com>= ; wrote:
Hi Juergen,

On 8/1/15, 2:51 AM, "netmod on behalf of Juergen Schoenwaelder" <netmod-bounces@ietf.org = on behalf of
j.schoenwaelder@jac= obs-university.de> wrote:

>On Fri, Jul 31, 2015 at 12:46:49PM -0400, Lou Berger wrote:
>> Andy,
>>
>> On 07/27/2015 12:58 PM, Andy Bierman wrote:
>> > Hi,
>> >
>> > I don't think a standard for relocating subtrees would be= worth it.
>> > I am not in favor of moving /interfaces or /system to a new l= ocation.
>> > That's not how YANG works. It only allows "obsolete = and start over".
>> >
>> > I would suggest pursuing solutions that don't cause
>> > as much disruption and expense as possible.
>> >
>>
>> I think it would be really good to explore other, less "disru= ptive"
>> options.
>>
>
>I think the first step is to find out whether there is a problem worth<= br> >to be fixed. Why are the RFCs in question broken? (Yes, I have read
>the openconfig IDs,

Section 1.1 in
https://www.ietf.org/id/draft-= openconfig-netmod-model-structure-00.txt
lists the goals of a generic model structure that will accommodate most
modern network devices. I guess you don=E2=80=99t agree that these are desi= rable?



The only objection I ha= ve to this draft is the insertion of a top-level root
called &quo= t;device". =C2=A0(Might as well be called "self").
There are no sibling nodes planned or intended for
this node, so= it serves as an extra document root.

The well-spe= cified XPath and YANG root (/) can be
accessed by all protocol op= erations, exactly the same
as a node called 'device'.=C2= =A0 The actual node name will
depend on the RPC function (e.g. &#= 39;data' or 'config').

This is more th= an redundant however.=C2=A0 It introduces a "super-module"
<= div>into YANG that every other module is expected to augment.
YAN= G is intended to be more loosely coupled than that.
This introduc= es an extra node and namespace declaration
in all protocol messag= es, increasing message sizes.

It also assumes all = existing YANG models will get rewritten to
account for "/dev= ice" in all path and XPath expressions.=C2=A0
This is highly= disruptive to existing deployments.
Also, multiple data models t= o edit the same thing causes lots
of extra complexity in the serv= er (supporting both old
location and new location).
IMO a resource directory approach is much more realistic.
=
The /device tree can contain all the organized NP containers.
Instead of all the actual data nodes, this tree just has pointers
to the real location of the resource. (like 301 Moved Permanently)=




Thanks,
Acee



Andy
=C2=A0

>I listened to the virtual interim meetings, I
>assume you have read draft-bjorklund-netmod-openconfig-reply.)



>
>Lets get the core of the openconfig argument on the table why the
>existing RFCs are flawed.
>
>/js
>
>--
>Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Un= iversity 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/>
>
>_______________________________________________
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod

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

--001a11c27cf064cffb051c43c9ff-- From nobody Mon Aug 3 00:22:57 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC261A893E for ; Mon, 3 Aug 2015 00:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4x_2fJx5PLP for ; Mon, 3 Aug 2015 00:22:52 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 719471A8949 for ; Mon, 3 Aug 2015 00:22:52 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 12A4C1CC0363; Mon, 3 Aug 2015 09:22:50 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: References: <20150730.194130.1378875555824248389.mbj@tail-f.com> <20150730.211629.1600508626921450694.mbj@tail-f.com> <1D650959-4AB3-4B74-8A30-7BE3A69B896D@nic.cz> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Mon, 03 Aug 2015 09:22:48 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 07:22:56 -0000 Andy Bierman writes: > On Fri, Jul 31, 2015 at 8:37 AM, Ladislav Lhotka wrote: > >> >> > On 31 Jul 2015, at 16:54, Andy Bierman wrote: >> > >> > >> > >> > On Fri, Jul 31, 2015 at 5:45 AM, Ladislav Lhotka wrote: >> > >> > > On 31 Jul 2015, at 14:40, Andy Bierman wrote: >> > > >> > > >> > > >> > > On Fri, Jul 31, 2015 at 1:12 AM, Ladislav Lhotka >> wrote: >> > > Martin Bjorklund writes: >> > > >> > > > Andy Bierman wrote: >> > > >> On Thu, Jul 30, 2015 at 10:41 AM, Martin Bjorklund >> wrote: >> > > >> >> > > >> > Andy Bierman wrote: >> > > >> > > On Wed, Jul 29, 2015 at 10:51 AM, Martin Bjorklund < >> mbj@tail-f.com> >> > > >> > wrote: >> > > >> > > >> > > >> > > > Andy Bierman wrote: >> > > >> > > > > Hi, >> > > >> > > > > >> > > >> > > > > I understand the intent is that an implementation of NACM >> > > >> > > > > has to understand these NACM extensions. I agree with La= da >> > > >> > > > > that the YANG text about MAY ignore extensions casts doubt >> whether >> > > >> > > > > this sort of NACM rule is enforceable or specified >> correctly. >> > > >> > > > >> > > >> > > > So do you agree that it would be a good idea to clarify this >> > > >> > > > according to Juergen's suggestion? >> > > >> > > > >> > > >> > > > >> > > >> > > > >> > > >> > > Not really. >> > > >> > > Pretending the extension is just another description-stmt >> > > >> > > does not really fix anything. >> > > >> > > >> > > >> > > A real YANG statement like config-stmt or a new statement >> > > >> > > called ephemeral-stmt can be modified with refine-stmt >> > > >> > > or deviate-stmt. This can never happen for >> > > >> > > an external statement. >> > > >> > >> > > >> > There are two separate issues here: >> > > >> > >> > > >> > 1) It seems we are in agreement that if a model uses an extensi= on >> > > >> > statement, it is normative (like ietf-system's usage of >> nacm:*). >> > > >> > >> > > >> > Should we somehow clarify this in 6020bis? >> > > >> > >> > > >> > 2) Extensions cannot be refined or deviated. >> > > >> > >> > > >> > Actually, the *syntax* rules allows things like: >> > > >> > >> > > >> > deviation /x:foo { >> > > >> > deviate replace { >> > > >> > i2rs:ephemeral true; >> > > >> > } >> > > >> > } >> > > >> > >> > > >> > I agree that it not clear what this means, but we could also >> > > >> > clarify this in 6020bis. >> > > >> > >> > > >> > >> > > >> >> > > >> But this will take even longer than just defining the statements >> that >> > > >> are needed for ephemeral state, so no point in doing that. >> > > >> >> > > >> The text in 7.18.3.2 clearly does not support the example above = at >> all. >> > > > >> > > > The grammar allows extensions everywhere, so the example is (as I >> > > > wrote) syntactically valid. >> > > > >> > > >> Only one of the keywords listed in the table are supported. >> > > > >> > > > The text doesn't say so, and anyway my point was that - regardless= of >> > > > the outcome of the ephemeral dicussion - it might be a good a idea= to >> > > > clarify that extensions can be deviated as well. >> > > >> > > +1 >> > > >> > > >> > > So you are saying that a tool MAY ignore any extension, except >> > > inside a deviation-stmt? Then it becomes mandatory to support? >> > > >> > > Or do you mean: >> > > >> > > Yes you can put extension-stmts anywhere, but also, yes the tool >> > > MAY ignore every single extension (everywhere, including inside a >> > > deviation-stmt) >> > >> > I understood Martin=E2=80=99s proposal so that a device that doesn=E2= =80=99t support an >> extension used in modules it advertises will have to put it in a >> =E2=80=9Cnot-supported=E2=80=9D deviation. >> > >> > >> > So features are all "not-supported" by default. but extensions, >> > which a tool MAY ignore, are all supported by default? >> >> I proposed to remove this =E2=80=9CMAY ignore=E2=80=9D text. >> > > > I do not support this change > The current "MAY ignore" formulation is unclear, and it doesn't matter whether it talks about compilers, parsers or tools. The problem with extensions is that they can mean virtually anything =E2=80= =93 in particular, they can change semantics of YANG or the management protocol. I think there are two possible approaches: 1. Treat all extensions appearing in the server's data model as mandatory parts of data model or protocol semantics. 2. Make extensions truly optional and irrelevant from the point of view of YANG language. With #1, a client that doesn't understand all extensions the server uses SHOULD terminate the session, because there are no means for negotiating support for extensions one by one. I am afraid this could have disastrous consequences for interoperability: we would have silos where servers only work with clients of the same provenience. #2 is what RELAX NG does: elements and attributes from foreign namespaces are allowed in a schema but they cannot affect the notion of RELAX NG validity because the specification of the validation procedure says: "Foreign attributes and elements are removed." With #2, protocols such as I2RS can still define their extensions provided that - there is some way for making sure that both the server and client understands it, - it doesn't affect servers and clients of other protocols, so they may safely ignore it. I would personally vote for #2, but then the NACM stuff or the "annotation" statement really cannot be extensions. Lada > > >> >> > A server would be required to identify and remember all >> > extensions used? And what about nested extensions: >> > >> > acme:foo test1 { >> > acme:foo2 test2; >> > } >> > >> >> Yes. >> >> > The server would be required to completely parse all extensions, >> > and not skip over them? Just to list them as deviations? >> > >> > I think extensions should be like features and the server should >> > advertise them if they are supported. >> >> My idea was that all extensions has to be supported, and those that aren= =E2=80=99t >> will be declared as not-supported in deviations. >> >> > I do not support this change. > Extensions are used to define external statements > which are, in fact, not part of the YANG language. > (hence the name "external") > > IMO it is a mistake to try to make them part of YANG and > YANG conformance. > > > >> > >> > I don't agree that "external-stmt" should be under YANG conformance >> > at all. That is why MAY skip over is in the text. A tool that >> > understands the extension is purely optional. >> > >> >> But then we run into problems if extensions change semantics on the serv= er >> side, as with nacm. >> >> > > Some people have asked if they can just support the NACM extensions > and not the NACM module. A: no. Only the NACM module is required > to understand these extensions. They do not affect the > syntax or semantics of the tagged objects at all. > They only affect access control for those objects. > IMO the NACM extensions should be real YANG statements, > and then the concepts of 'default-deny-write' and 'default-deny-all' > could be implemented without NACM. > > > > Lada >> > > Andy > > >> >> > >> > Lada >> > >> > >> > Andy >> > >> > > >> > > >> > > >> > > Lada >> > > >> > > Andy >> > > >> > > >> > > > >> > > > /martin >> > > > >> > > >> >> > > >> >> > > >> The substatement's keyword MUST match a corresponding >> > > >> keyword in the target node, and the argument's string MUST be >> equal >> > > >> to the corresponding keyword's argument string in the target >> node. >> > > >> >> > > >> The deviates's Substatements >> > > >> >> > > >> +--------------+---------+-------------+ >> > > >> | substatement | section | cardinality | >> > > >> +--------------+---------+-------------+ >> > > >> | config | 7.19.1 | 0..1 | >> > > >> | default | 7.6.4 | 0..1 | >> > > >> | mandatory | 7.6.5 | 0..1 | >> > > >> | max-elements | 7.7.4 | 0..1 | >> > > >> | min-elements | 7.7.3 | 0..1 | >> > > >> | must | 7.5.3 | 0..n | >> > > >> | type | 7.4 | 0..1 | >> > > >> | unique | 7.8.3 | 0..n | >> > > >> | units | 7.3.3 | 0..1 | >> > > >> +--------------+---------+-------------+ >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> > > IMO ephemeral data support needs to be a real statement >> > > >> > > that can be used with refine-stmt and deviate-stmt. >> > > >> > > It is a real property of a data node. >> > > >> > >> > > >> > Note: it is still not clear that such a statement (base or >> extension) >> > > >> > is needed at all. >> > > >> > >> > > >> > >> > > >> >> > > >> Maybe not to you, but according to the I2RS ephemeral requirement= s, >> > > >> it is needed, so unless you have a better plan, this is the defau= lt. >> > > >> >> > > >> Explain how ephemeral state can be identified within a data node. >> > > >> It must be possible to use groupings to define such data nodes. >> > > >> If must be possible to refine these groupings. >> > > >> It must be possible for a vendor to write deviation statements. >> > > >> All YANG tools must recognize the ephemeral data property. >> > > >> It should not be isolated to a particular YANG module, which would >> > > >> create a dependency in all future YANG modules. >> > > >> >> > > >> >> > > >> Andy >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> > >> > > >> > /martin >> > > >> > >> > > >> > > -- >> > > Ladislav Lhotka, CZ.NIC Labs >> > > PGP Key ID: E74E8C0C >> > > >> > >> > -- >> > Ladislav Lhotka, CZ.NIC Labs >> > PGP Key ID: E74E8C0C >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> >> >> >> --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Aug 3 01:18:35 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B69EF1A8A7C for ; Mon, 3 Aug 2015 01:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tfmnK9zVbb_J for ; Mon, 3 Aug 2015 01:18: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 AEF331A8A7F for ; Mon, 3 Aug 2015 01:18: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 B0022155F; Mon, 3 Aug 2015 10:18:22 +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 fyHBjtAww-Jc; Mon, 3 Aug 2015 10:18: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; Mon, 3 Aug 2015 10:18:21 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3F62F20048; Mon, 3 Aug 2015 10:18:21 +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 RkZ1eHKjM_iM; Mon, 3 Aug 2015 10:18:19 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BE23B20045; Mon, 3 Aug 2015 10:18:17 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 823D0360786C; Mon, 3 Aug 2015 10:18:15 +0200 (CEST) Date: Mon, 3 Aug 2015 10:18:14 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20150803081814.GA71323@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , Martin =?iso-8859-1?Q?Bj=F6rklund?= , "netmod@ietf.org" References: <20150730.194130.1378875555824248389.mbj@tail-f.com> <20150730.211629.1600508626921450694.mbj@tail-f.com> <1D650959-4AB3-4B74-8A30-7BE3A69B896D@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: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 08:18:30 -0000 On Mon, Aug 03, 2015 at 09:22:48AM +0200, Ladislav Lhotka wrote: > Andy Bierman writes: > > > On Fri, Jul 31, 2015 at 8:37 AM, Ladislav Lhotka wrote: > > > >> > >> > On 31 Jul 2015, at 16:54, Andy Bierman wrote: > >> > > >> > > >> > > >> > On Fri, Jul 31, 2015 at 5:45 AM, Ladislav Lhotka wrote: > >> > > >> > > On 31 Jul 2015, at 14:40, Andy Bierman wrote: > >> > > > >> > > > >> > > > >> > > On Fri, Jul 31, 2015 at 1:12 AM, Ladislav Lhotka > >> wrote: > >> > > Martin Bjorklund writes: > >> > > > >> > > > Andy Bierman wrote: > >> > > >> On Thu, Jul 30, 2015 at 10:41 AM, Martin Bjorklund > >> wrote: > >> > > >> > >> > > >> > Andy Bierman wrote: > >> > > >> > > On Wed, Jul 29, 2015 at 10:51 AM, Martin Bjorklund < > >> mbj@tail-f.com> > >> > > >> > wrote: > >> > > >> > > > >> > > >> > > > Andy Bierman wrote: > >> > > >> > > > > Hi, > >> > > >> > > > > > >> > > >> > > > > I understand the intent is that an implementation of NACM > >> > > >> > > > > has to understand these NACM extensions. I agree with Lada > >> > > >> > > > > that the YANG text about MAY ignore extensions casts doubt > >> whether > >> > > >> > > > > this sort of NACM rule is enforceable or specified > >> correctly. > >> > > >> > > > > >> > > >> > > > So do you agree that it would be a good idea to clarify this > >> > > >> > > > according to Juergen's suggestion? > >> > > >> > > > > >> > > >> > > > > >> > > >> > > > > >> > > >> > > Not really. > >> > > >> > > Pretending the extension is just another description-stmt > >> > > >> > > does not really fix anything. > >> > > >> > > > >> > > >> > > A real YANG statement like config-stmt or a new statement > >> > > >> > > called ephemeral-stmt can be modified with refine-stmt > >> > > >> > > or deviate-stmt. This can never happen for > >> > > >> > > an external statement. > >> > > >> > > >> > > >> > There are two separate issues here: > >> > > >> > > >> > > >> > 1) It seems we are in agreement that if a model uses an extension > >> > > >> > statement, it is normative (like ietf-system's usage of > >> nacm:*). > >> > > >> > > >> > > >> > Should we somehow clarify this in 6020bis? > >> > > >> > > >> > > >> > 2) Extensions cannot be refined or deviated. > >> > > >> > > >> > > >> > Actually, the *syntax* rules allows things like: > >> > > >> > > >> > > >> > deviation /x:foo { > >> > > >> > deviate replace { > >> > > >> > i2rs:ephemeral true; > >> > > >> > } > >> > > >> > } > >> > > >> > > >> > > >> > I agree that it not clear what this means, but we could also > >> > > >> > clarify this in 6020bis. > >> > > >> > > >> > > >> > > >> > > >> > >> > > >> But this will take even longer than just defining the statements > >> that > >> > > >> are needed for ephemeral state, so no point in doing that. > >> > > >> > >> > > >> The text in 7.18.3.2 clearly does not support the example above at > >> all. > >> > > > > >> > > > The grammar allows extensions everywhere, so the example is (as I > >> > > > wrote) syntactically valid. > >> > > > > >> > > >> Only one of the keywords listed in the table are supported. > >> > > > > >> > > > The text doesn't say so, and anyway my point was that - regardless of > >> > > > the outcome of the ephemeral dicussion - it might be a good a idea to > >> > > > clarify that extensions can be deviated as well. > >> > > > >> > > +1 > >> > > > >> > > > >> > > So you are saying that a tool MAY ignore any extension, except > >> > > inside a deviation-stmt? Then it becomes mandatory to support? > >> > > > >> > > Or do you mean: > >> > > > >> > > Yes you can put extension-stmts anywhere, but also, yes the tool > >> > > MAY ignore every single extension (everywhere, including inside a > >> > > deviation-stmt) > >> > > >> > I understood Martin’s proposal so that a device that doesn’t support an > >> extension used in modules it advertises will have to put it in a > >> “not-supported” deviation. > >> > > >> > > >> > So features are all "not-supported" by default. but extensions, > >> > which a tool MAY ignore, are all supported by default? > >> > >> I proposed to remove this “MAY ignore” text. > >> > > > > > > I do not support this change > > > > The current "MAY ignore" formulation is unclear, and it doesn't matter > whether it talks about compilers, parsers or tools. > > The problem with extensions is that they can mean virtually anything – > in particular, they can change semantics of YANG or the management > protocol. Any description statement in principle can do this. We trust that sane data model writers won't do bad things. And if they do, we hope that people will not implement and deploy bad things. > I think there are two possible approaches: > > 1. Treat all extensions appearing in the server's data model as > mandatory parts of data model or protocol semantics. > > 2. Make extensions truly optional and irrelevant from the point of view > of YANG language. > > With #1, a client that doesn't understand all extensions the server uses > SHOULD terminate the session, because there are no means for negotiating > support for extensions one by one. > > I am afraid this could have disastrous consequences for > interoperability: we would have silos where servers only work with > clients of the same provenience. > > #2 is what RELAX NG does: elements and attributes from foreign > namespaces are allowed in a schema but they cannot affect the notion of > RELAX NG validity because the specification of the validation procedure > says: "Foreign attributes and elements are removed." > > With #2, protocols such as I2RS can still define their extensions > provided that > > - there is some way for making sure that both the server and client > understands it, > > - it doesn't affect servers and clients of other protocols, so they may > safely ignore it. > > I would personally vote for #2, but then the NACM stuff or the > "annotation" statement really cannot be extensions. I continue to see extension statements as reusable and (in principle) machine readable fragments of description statements. From this perspective, it seems odd to make a difference between extensions and description statements. I think the NACM extensions are just fine as they are. I do not see anything broken about them. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Aug 3 02:05:09 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBD5D1B2CD2 for ; Mon, 3 Aug 2015 02:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.361 X-Spam-Level: X-Spam-Status: No, score=-5.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XAS4qicgrf72 for ; Mon, 3 Aug 2015 02:05:03 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C85111A8AEF for ; Mon, 3 Aug 2015 02:05:02 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:112d:ff1f:8f47:32e2] (unknown [IPv6:2001:718:1a02:1:112d:ff1f:8f47:32e2]) by mail.nic.cz (Postfix) with ESMTPSA id 3EF4618181E; Mon, 3 Aug 2015 11:05:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1438592701; bh=u5oAxoA9A/Z3a4ZugmMYDx6nO7mV0lnsjHb5QPKpkig=; h=From:Date:To; b=mwm0qpsDt4kfZTf2EN3Z/Ht+KUK9hhV6JB79s2Y7OJOw/NEx9RjenMe2OOE6ZcMFv keaa7LjD3VOLmJvLhhTDp9yOgy5hQYua+SD6uW5Raf9xeCPHASH9f/ouIORQu+JsTR 516KI8KOBEdM4Ijxj/xGJGrVdgnAXj5xyVVDqdcg= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: <20150803081814.GA71323@elstar.local> Date: Mon, 3 Aug 2015 11:05:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <393C4635-7F2E-4C6F-A265-A84126F1FA1E@nic.cz> References: <20150730.194130.1378875555824248389.mbj@tail-f.com> <20150730.211629.1600508626921450694.mbj@tail-f.com> <1D650959-4AB3-4B74-8A30-7BE3A69B896D@nic.cz> <20150803081814.GA71323@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 09:05:07 -0000 > On 03 Aug 2015, at 10:18, Juergen Schoenwaelder = wrote: >=20 > On Mon, Aug 03, 2015 at 09:22:48AM +0200, Ladislav Lhotka wrote: >> Andy Bierman writes: >>=20 >>> On Fri, Jul 31, 2015 at 8:37 AM, Ladislav Lhotka = wrote: >>>=20 >>>>=20 >>>>> On 31 Jul 2015, at 16:54, Andy Bierman wrote: >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Fri, Jul 31, 2015 at 5:45 AM, Ladislav Lhotka = wrote: >>>>>=20 >>>>>> On 31 Jul 2015, at 14:40, Andy Bierman = wrote: >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Fri, Jul 31, 2015 at 1:12 AM, Ladislav Lhotka >>>> wrote: >>>>>> Martin Bjorklund writes: >>>>>>=20 >>>>>>> Andy Bierman wrote: >>>>>>>> On Thu, Jul 30, 2015 at 10:41 AM, Martin Bjorklund = >>>> wrote: >>>>>>>>=20 >>>>>>>>> Andy Bierman wrote: >>>>>>>>>> On Wed, Jul 29, 2015 at 10:51 AM, Martin Bjorklund < >>>> mbj@tail-f.com> >>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> Andy Bierman wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>>=20 >>>>>>>>>>>> I understand the intent is that an implementation of NACM >>>>>>>>>>>> has to understand these NACM extensions. I agree with Lada >>>>>>>>>>>> that the YANG text about MAY ignore extensions casts doubt >>>> whether >>>>>>>>>>>> this sort of NACM rule is enforceable or specified >>>> correctly. >>>>>>>>>>>=20 >>>>>>>>>>> So do you agree that it would be a good idea to clarify this >>>>>>>>>>> according to Juergen's suggestion? >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>> Not really. >>>>>>>>>> Pretending the extension is just another description-stmt >>>>>>>>>> does not really fix anything. >>>>>>>>>>=20 >>>>>>>>>> A real YANG statement like config-stmt or a new statement >>>>>>>>>> called ephemeral-stmt can be modified with refine-stmt >>>>>>>>>> or deviate-stmt. This can never happen for >>>>>>>>>> an external statement. >>>>>>>>>=20 >>>>>>>>> There are two separate issues here: >>>>>>>>>=20 >>>>>>>>> 1) It seems we are in agreement that if a model uses an = extension >>>>>>>>> statement, it is normative (like ietf-system's usage of >>>> nacm:*). >>>>>>>>>=20 >>>>>>>>> Should we somehow clarify this in 6020bis? >>>>>>>>>=20 >>>>>>>>> 2) Extensions cannot be refined or deviated. >>>>>>>>>=20 >>>>>>>>> Actually, the *syntax* rules allows things like: >>>>>>>>>=20 >>>>>>>>> deviation /x:foo { >>>>>>>>> deviate replace { >>>>>>>>> i2rs:ephemeral true; >>>>>>>>> } >>>>>>>>> } >>>>>>>>>=20 >>>>>>>>> I agree that it not clear what this means, but we could also >>>>>>>>> clarify this in 6020bis. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> But this will take even longer than just defining the = statements >>>> that >>>>>>>> are needed for ephemeral state, so no point in doing that. >>>>>>>>=20 >>>>>>>> The text in 7.18.3.2 clearly does not support the example = above at >>>> all. >>>>>>>=20 >>>>>>> The grammar allows extensions everywhere, so the example is (as = I >>>>>>> wrote) syntactically valid. >>>>>>>=20 >>>>>>>> Only one of the keywords listed in the table are supported. >>>>>>>=20 >>>>>>> The text doesn't say so, and anyway my point was that - = regardless of >>>>>>> the outcome of the ephemeral dicussion - it might be a good a = idea to >>>>>>> clarify that extensions can be deviated as well. >>>>>>=20 >>>>>> +1 >>>>>>=20 >>>>>>=20 >>>>>> So you are saying that a tool MAY ignore any extension, except >>>>>> inside a deviation-stmt? Then it becomes mandatory to support? >>>>>>=20 >>>>>> Or do you mean: >>>>>>=20 >>>>>> Yes you can put extension-stmts anywhere, but also, yes the tool >>>>>> MAY ignore every single extension (everywhere, including inside a >>>>>> deviation-stmt) >>>>>=20 >>>>> I understood Martin=E2=80=99s proposal so that a device that = doesn=E2=80=99t support an >>>> extension used in modules it advertises will have to put it in a >>>> =E2=80=9Cnot-supported=E2=80=9D deviation. >>>>>=20 >>>>>=20 >>>>> So features are all "not-supported" by default. but extensions, >>>>> which a tool MAY ignore, are all supported by default? >>>>=20 >>>> I proposed to remove this =E2=80=9CMAY ignore=E2=80=9D text. >>>>=20 >>>=20 >>>=20 >>> I do not support this change >>>=20 >>=20 >> The current "MAY ignore" formulation is unclear, and it doesn't = matter >> whether it talks about compilers, parsers or tools. >>=20 >> The problem with extensions is that they can mean virtually anything = =E2=80=93 >> in particular, they can change semantics of YANG or the management >> protocol. >=20 > Any description statement in principle can do this. We trust that sane 6020(bis) is silent about the effects a description or extension can = have - I think there should be relatively strict limits. I agree with = Jernej that descriptions or extensions should not be allowed to change = YANG semantics. We had a discussion before about defining new XPath functions via = extensions. Doing it via descriptions is equally inacceptable for me. Lada=20 > data model writers won't do bad things. And if they do, we hope that > people will not implement and deploy bad things. >=20 >> I think there are two possible approaches: >>=20 >> 1. Treat all extensions appearing in the server's data model as >> mandatory parts of data model or protocol semantics. >>=20 >> 2. Make extensions truly optional and irrelevant from the point of = view >> of YANG language. >>=20 >> With #1, a client that doesn't understand all extensions the server = uses >> SHOULD terminate the session, because there are no means for = negotiating >> support for extensions one by one. >>=20 >> I am afraid this could have disastrous consequences for >> interoperability: we would have silos where servers only work with >> clients of the same provenience. >>=20 >> #2 is what RELAX NG does: elements and attributes from foreign >> namespaces are allowed in a schema but they cannot affect the notion = of >> RELAX NG validity because the specification of the validation = procedure >> says: "Foreign attributes and elements are removed." >>=20 >> With #2, protocols such as I2RS can still define their extensions >> provided that >>=20 >> - there is some way for making sure that both the server and client >> understands it, >>=20 >> - it doesn't affect servers and clients of other protocols, so they = may >> safely ignore it. >>=20 >> I would personally vote for #2, but then the NACM stuff or the >> "annotation" statement really cannot be extensions. >=20 > I continue to see extension statements as reusable and (in principle) > machine readable fragments of description statements. =46rom this > perspective, it seems odd to make a difference between extensions and > description statements. I think the NACM extensions are just fine as > they are. I do not see anything broken about them. >=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 Mon Aug 3 02:06:51 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59E131B2CE4 for ; Mon, 3 Aug 2015 02:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.611 X-Spam-Level: X-Spam-Status: No, score=-1.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gH732st3Cinb for ; Mon, 3 Aug 2015 02:06:48 -0700 (PDT) Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id B30A21B2CE2 for ; Mon, 3 Aug 2015 02:06:47 -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 2037BC4175C5; Mon, 3 Aug 2015 11:06:44 +0200 (CEST) To: Ladislav Lhotka , Andy Bierman , =?UTF-8?Q?Martin_Bj=c3=b6rklund?= , "netmod@ietf.org" References: <20150730.194130.1378875555824248389.mbj@tail-f.com> <20150730.211629.1600508626921450694.mbj@tail-f.com> <1D650959-4AB3-4B74-8A30-7BE3A69B896D@nic.cz> <20150803081814.GA71323@elstar.local> From: Jernej Tuljak Message-ID: <55BF2F21.1070900@mg-soft.si> Date: Mon, 3 Aug 2015 11:06:41 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20150803081814.GA71323@elstar.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 09:06:50 -0000 Juergen Schoenwaelder je 3.8.2015 ob 10:18 napisal: > On Mon, Aug 03, 2015 at 09:22:48AM +0200, Ladislav Lhotka wrote: >> Andy Bierman writes: >> >>> On Fri, Jul 31, 2015 at 8:37 AM, Ladislav Lhotka wrote: >>> >>>>> On 31 Jul 2015, at 16:54, Andy Bierman wrote: >>>>> >>>>> >>>>> >>>>> On Fri, Jul 31, 2015 at 5:45 AM, Ladislav Lhotka wrote: >>>>> >>>>>> On 31 Jul 2015, at 14:40, Andy Bierman wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Jul 31, 2015 at 1:12 AM, Ladislav Lhotka >>>> wrote: >>>>>> Martin Bjorklund writes: >>>>>> >>>>>>> Andy Bierman wrote: >>>>>>>> On Thu, Jul 30, 2015 at 10:41 AM, Martin Bjorklund >>>> wrote: >>>>>>>>> Andy Bierman wrote: >>>>>>>>>> On Wed, Jul 29, 2015 at 10:51 AM, Martin Bjorklund < >>>> mbj@tail-f.com> >>>>>>>>> wrote: >>>>>>>>>>> Andy Bierman wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> I understand the intent is that an implementation of NACM >>>>>>>>>>>> has to understand these NACM extensions. I agree with Lada >>>>>>>>>>>> that the YANG text about MAY ignore extensions casts doubt >>>> whether >>>>>>>>>>>> this sort of NACM rule is enforceable or specified >>>> correctly. >>>>>>>>>>> So do you agree that it would be a good idea to clarify this >>>>>>>>>>> according to Juergen's suggestion? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Not really. >>>>>>>>>> Pretending the extension is just another description-stmt >>>>>>>>>> does not really fix anything. >>>>>>>>>> >>>>>>>>>> A real YANG statement like config-stmt or a new statement >>>>>>>>>> called ephemeral-stmt can be modified with refine-stmt >>>>>>>>>> or deviate-stmt. This can never happen for >>>>>>>>>> an external statement. >>>>>>>>> There are two separate issues here: >>>>>>>>> >>>>>>>>> 1) It seems we are in agreement that if a model uses an extension >>>>>>>>> statement, it is normative (like ietf-system's usage of >>>> nacm:*). >>>>>>>>> Should we somehow clarify this in 6020bis? >>>>>>>>> >>>>>>>>> 2) Extensions cannot be refined or deviated. >>>>>>>>> >>>>>>>>> Actually, the *syntax* rules allows things like: >>>>>>>>> >>>>>>>>> deviation /x:foo { >>>>>>>>> deviate replace { >>>>>>>>> i2rs:ephemeral true; >>>>>>>>> } >>>>>>>>> } >>>>>>>>> >>>>>>>>> I agree that it not clear what this means, but we could also >>>>>>>>> clarify this in 6020bis. >>>>>>>>> >>>>>>>>> >>>>>>>> But this will take even longer than just defining the statements >>>> that >>>>>>>> are needed for ephemeral state, so no point in doing that. >>>>>>>> >>>>>>>> The text in 7.18.3.2 clearly does not support the example above at >>>> all. >>>>>>> The grammar allows extensions everywhere, so the example is (as I >>>>>>> wrote) syntactically valid. >>>>>>> >>>>>>>> Only one of the keywords listed in the table are supported. >>>>>>> The text doesn't say so, and anyway my point was that - regardless of >>>>>>> the outcome of the ephemeral dicussion - it might be a good a idea to >>>>>>> clarify that extensions can be deviated as well. >>>>>> +1 >>>>>> >>>>>> >>>>>> So you are saying that a tool MAY ignore any extension, except >>>>>> inside a deviation-stmt? Then it becomes mandatory to support? >>>>>> >>>>>> Or do you mean: >>>>>> >>>>>> Yes you can put extension-stmts anywhere, but also, yes the tool >>>>>> MAY ignore every single extension (everywhere, including inside a >>>>>> deviation-stmt) >>>>> I understood Martin’s proposal so that a device that doesn’t support an >>>> extension used in modules it advertises will have to put it in a >>>> “not-supported” deviation. >>>>> >>>>> So features are all "not-supported" by default. but extensions, >>>>> which a tool MAY ignore, are all supported by default? >>>> I proposed to remove this “MAY ignore” text. >>>> >>> >>> I do not support this change >>> >> The current "MAY ignore" formulation is unclear, and it doesn't matter >> whether it talks about compilers, parsers or tools. >> >> The problem with extensions is that they can mean virtually anything – >> in particular, they can change semantics of YANG or the management >> protocol. > Any description statement in principle can do this. We trust that sane > data model writers won't do bad things. And if they do, we hope that > people will not implement and deploy bad things. Why not simply make this impossible by ensuring that description statements cannot change what has already been agreed upon in RFC6020 (aka YANG semantics)? I would have no problem with descriptions being normative, if this would be the case. > >> I think there are two possible approaches: >> >> 1. Treat all extensions appearing in the server's data model as >> mandatory parts of data model or protocol semantics. >> >> 2. Make extensions truly optional and irrelevant from the point of view >> of YANG language. >> >> With #1, a client that doesn't understand all extensions the server uses >> SHOULD terminate the session, because there are no means for negotiating >> support for extensions one by one. >> >> I am afraid this could have disastrous consequences for >> interoperability: we would have silos where servers only work with >> clients of the same provenience. >> >> #2 is what RELAX NG does: elements and attributes from foreign >> namespaces are allowed in a schema but they cannot affect the notion of >> RELAX NG validity because the specification of the validation procedure >> says: "Foreign attributes and elements are removed." >> >> With #2, protocols such as I2RS can still define their extensions >> provided that >> >> - there is some way for making sure that both the server and client >> understands it, >> >> - it doesn't affect servers and clients of other protocols, so they may >> safely ignore it. >> >> I would personally vote for #2, but then the NACM stuff or the >> "annotation" statement really cannot be extensions. > I continue to see extension statements as reusable and (in principle) > machine readable fragments of description statements. From this > perspective, it seems odd to make a difference between extensions and > description statements. I still disagree that description statements should be more powerful than any other YANG statement. > I think the NACM extensions are just fine as > they are. I do not see anything broken about them. I agree. Both NACM extensions and "annotation" are examples of what the best practice for extension usage should be. Standardize first, then use. I don't mind implementing something (in a generic client) that was widely agreed to be useful. There are cases like this for other languages. EXSLT for XSLT, for example. In time, extensions should become proper YANG keywords. FWIW, I prefer #2, since that is how I always understood YANG extensions. Don't mind #1 for standard extensions only. Jernej > > /js > From nobody Mon Aug 3 02:19:20 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1B441A0137 for ; Mon, 3 Aug 2015 02:19:18 -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 RN2-adptoI0v for ; Mon, 3 Aug 2015 02:19: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 DED671A010E for ; Mon, 3 Aug 2015 02:19: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 3240713AC; Mon, 3 Aug 2015 11:19: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 DiTt0iTFlGUh; Mon, 3 Aug 2015 11:19:14 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 3 Aug 2015 11:19:14 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C776D20046; Mon, 3 Aug 2015 11:19:14 +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 MkWraizOZx2O; Mon, 3 Aug 2015 11:19:14 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6958120045; Mon, 3 Aug 2015 11:19:13 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id F085A3607A75; Mon, 3 Aug 2015 11:19:10 +0200 (CEST) Date: Mon, 3 Aug 2015 11:19:09 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20150803091908.GA71565@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , Martin =?iso-8859-1?Q?Bj=F6rklund?= , "netmod@ietf.org" References: <20150730.211629.1600508626921450694.mbj@tail-f.com> <1D650959-4AB3-4B74-8A30-7BE3A69B896D@nic.cz> <20150803081814.GA71323@elstar.local> <393C4635-7F2E-4C6F-A265-A84126F1FA1E@nic.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <393C4635-7F2E-4C6F-A265-A84126F1FA1E@nic.cz> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 09:19:18 -0000 On Mon, Aug 03, 2015 at 11:05:01AM +0200, Ladislav Lhotka wrote: > > > Any description statement in principle can do this. We trust that sane > > 6020(bis) is silent about the effects a description or extension can have - I think there should be relatively strict limits. I agree with Jernej that descriptions or extensions should not be allowed to change YANG semantics. > How do you define 'change YANG semantics'? Some of the core typedefs have semantics defined in description statements that go beyond what can be expressed using YANG's type restriction statements. This has >20 years of history of being useful so lets make sure we do not loose any of that because of a fear that things may be misused. /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 Aug 3 02:25:10 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ACE11A015F for ; Mon, 3 Aug 2015 02:25: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 fySj56PSIUyH for ; Mon, 3 Aug 2015 02:25: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 A5CE01A00F9 for ; Mon, 3 Aug 2015 02:25:06 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E6AAB12E9; Mon, 3 Aug 2015 11:25:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id LocEtTmV-PSE; Mon, 3 Aug 2015 11:25:04 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 3 Aug 2015 11:25:03 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4A0D720048; Mon, 3 Aug 2015 11:25:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id XFd4e6pp9Foh; Mon, 3 Aug 2015 11:25: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 1864220045; Mon, 3 Aug 2015 11:25:03 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 739733607AA7; Mon, 3 Aug 2015 11:25:01 +0200 (CEST) Date: Mon, 3 Aug 2015 11:25:01 +0200 From: Juergen Schoenwaelder To: Jernej Tuljak Message-ID: <20150803092501.GB71565@elstar.local> Mail-Followup-To: Jernej Tuljak , Ladislav Lhotka , Andy Bierman , Martin =?iso-8859-1?Q?Bj=F6rklund?= , "netmod@ietf.org" References: <20150730.211629.1600508626921450694.mbj@tail-f.com> <1D650959-4AB3-4B74-8A30-7BE3A69B896D@nic.cz> <20150803081814.GA71323@elstar.local> <55BF2F21.1070900@mg-soft.si> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55BF2F21.1070900@mg-soft.si> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 09:25:09 -0000 On Mon, Aug 03, 2015 at 11:06:41AM +0200, Jernej Tuljak wrote: > Juergen Schoenwaelder je 3.8.2015 ob 10:18 napisal: > >Any description statement in principle can do this. We trust that sane > >data model writers won't do bad things. And if they do, we hope that > >people will not implement and deploy bad things. > > Why not simply make this impossible by ensuring that description > statements cannot change what has already been agreed upon in RFC6020 > (aka YANG semantics)? I would have no problem with descriptions being > normative, if this would be the case. You need to define way more clearly what 'YANG semantics' means. > >I continue to see extension statements as reusable and (in principle) > >machine readable fragments of description statements. From this > >perspective, it seems odd to make a difference between extensions and > >description statements. > > I still disagree that description statements should be more powerful > than any other YANG statement. What does 'powerful' mean? Time that someone writes concrete text so we can have a more constructive discussion. /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 Aug 3 02:57:27 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C67BC1A1A03 for ; Mon, 3 Aug 2015 02:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.361 X-Spam-Level: X-Spam-Status: No, score=-5.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J34dtTbgV_DK for ; Mon, 3 Aug 2015 02:57:22 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A6C01A1A02 for ; Mon, 3 Aug 2015 02:57:21 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:112d:ff1f:8f47:32e2] (unknown [IPv6:2001:718:1a02:1:112d:ff1f:8f47:32e2]) by mail.nic.cz (Postfix) with ESMTPSA id 9B162181469; Mon, 3 Aug 2015 11:57:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1438595839; bh=RtmMg9f1hdO4yZt31Rd9l+Bddn/mH0NFaUGi2haeh0A=; h=From:Date:To; b=MsTmlImFJraO9+goDSL80C7uCV4gE4OjqSlRNWJZ/5MZNMOuCGzL+vEonNKi1dxCx WK4w12GBsD2M9zMxfp2ya1L6gNR9QEWZr1mQx0Gq90NtY6a1oBnCBLx1l7FwrToALY PmAu3pLk3bZSWZDDGeBAaW4riWIs2xrIv5u9Ayfs= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: <20150803091908.GA71565@elstar.local> Date: Mon, 3 Aug 2015 11:57:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <04F4BDCF-4AB8-4323-98C3-7EA6BC05BC10@nic.cz> References: <20150730.211629.1600508626921450694.mbj@tail-f.com> <1D650959-4AB3-4B74-8A30-7BE3A69B896D@nic.cz> <20150803081814.GA71323@elstar.local> <393C4635-7F2E-4C6F-A265-A84126F1FA1E@nic.cz> <20150803091908.GA71565@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 09:57:24 -0000 > On 03 Aug 2015, at 11:19, Juergen Schoenwaelder = wrote: >=20 > On Mon, Aug 03, 2015 at 11:05:01AM +0200, Ladislav Lhotka wrote: >>=20 >>> Any description statement in principle can do this. We trust that = sane >>=20 >> 6020(bis) is silent about the effects a description or extension can = have - I think there should be relatively strict limits. I agree with = Jernej that descriptions or extensions should not be allowed to change = YANG semantics. >>=20 >=20 > How do you define 'change YANG semantics=E2=80=99? Anything that changes YANG language as defined in the spec of the = corresponding version. =20 >=20 > Some of the core typedefs have semantics defined in description > statements that go beyond what can be expressed using YANG's type > restriction statements. This has >20 years of history of being useful > so lets make sure we do not loose any of that because of a fear that > things may be misused. >=20 Typedefs like counter32 are just instructions for server developers = about the internal semantics of a parameter in state data. It has no = relevance to the data model as a client-server contract. It=E2=80=99s OK to state a semantic rule for a given data model in a = description, if it can't be done via =E2=80=9Cmust=E2=80=9D expression, = or specify how to select a default value for a leaf, things like that. = On the other hand, for example, saying in a description of a config list = that a key isn=E2=80=99t required for that list must not be allowed. = Doing the same with an extension would not be better. Lada > /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 Mon Aug 3 02:59:42 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C860B1A1A1B for ; Mon, 3 Aug 2015 02:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.611 X-Spam-Level: X-Spam-Status: No, score=-1.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQSVk__uqQd8 for ; Mon, 3 Aug 2015 02:59:40 -0700 (PDT) Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id E978A1A1A12 for ; Mon, 3 Aug 2015 02:59:39 -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 23728C4175C5; Mon, 3 Aug 2015 11:59:39 +0200 (CEST) To: Ladislav Lhotka , Andy Bierman , =?UTF-8?Q?Martin_Bj=c3=b6rklund?= , "netmod@ietf.org" References: <20150730.211629.1600508626921450694.mbj@tail-f.com> <1D650959-4AB3-4B74-8A30-7BE3A69B896D@nic.cz> <20150803081814.GA71323@elstar.local> <55BF2F21.1070900@mg-soft.si> <20150803092501.GB71565@elstar.local> From: Jernej Tuljak Message-ID: <55BF3B88.9080509@mg-soft.si> Date: Mon, 3 Aug 2015 11:59:36 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20150803092501.GB71565@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 09:59:40 -0000 Juergen Schoenwaelder je 3.8.2015 ob 11:25 napisal: > On Mon, Aug 03, 2015 at 11:06:41AM +0200, Jernej Tuljak wrote: >> Juergen Schoenwaelder je 3.8.2015 ob 10:18 napisal: >>> Any description statement in principle can do this. We trust that sane >>> data model writers won't do bad things. And if they do, we hope that >>> people will not implement and deploy bad things. >> Why not simply make this impossible by ensuring that description >> statements cannot change what has already been agreed upon in RFC6020 >> (aka YANG semantics)? I would have no problem with descriptions being >> normative, if this would be the case. > You need to define way more clearly what 'YANG semantics' means. In terminology used by you, when you were explaining your view of descriptions and extensions: All we do is agreeing on certain constructs to be generally useful and so we can write shortcuts that have well defined meanings. This is why we have a language and do not write everything in prose. It is more compact and more efficit. Those shortcuts. > >>> I continue to see extension statements as reusable and (in principle) >>> machine readable fragments of description statements. From this >>> perspective, it seems odd to make a difference between extensions and >>> description statements. >> I still disagree that description statements should be more powerful >> than any other YANG statement. > What does 'powerful' mean? Time that someone writes concrete text so > we can have a more constructive discussion. The power to change previously agreed upon meaning of a YANG language construct. The power to turn an arbitrary leaf into a container by mere mention of it in what is defined as a textual description for humans. Jernej > > /js > From nobody Mon Aug 3 06:43:22 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D89741A1AAE for ; Mon, 3 Aug 2015 06:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXOBFaL_rccv for ; Mon, 3 Aug 2015 06:43:13 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 08BD51A88A6 for ; Mon, 3 Aug 2015 06:43:13 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 041091CC0397; Mon, 3 Aug 2015 15:43:12 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder , "Acee Lindem \(acee\)" In-Reply-To: <20150801172325.GA68312@elstar.local> References: <20150720210041.GA17614@elstar.local> <14ecceb6dd0.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <14ed0338068.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <55BBA679.7070508@labn.net> <20150801065150.GA67416@elstar.local> <20150801172325.GA68312@elstar.local> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Mon, 03 Aug 2015 15:43:09 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Y34 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 13:43:21 -0000 Juergen Schoenwaelder writes: > On Sat, Aug 01, 2015 at 04:51:28PM +0000, Acee Lindem (acee) wrote: >>=20 >> Section 1.1 in=20 >> https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt >> lists the goals of a generic model structure that will accommodate most >> modern network devices. I guess you don=E2=80=99t agree that these are d= esirable? > > o a common schema to access data related to all aspects of a device > > This is why we produce standards. They are a common schema. > > o an extensible structure that makes it clear where additional > models or data should be fit (e.g., using YANG augmentation or > imports) > > This is why we have /interfaces. Interface related stuff goes here. > It is easy to reference. But it is only suitable for a single device with its set of interfaces. So the ietf-interfaces module isn't broken but doesn't allow for typical generalizations, e.g. a device comprising a number of virtual devices, each with its own set of interfaces. Lada > > o a place for including metadata that provides useful information > about the corresponding individual models, such as which > organization provides them, which vendors support them, or which > version of the model is deployed > > Not really sure what this means. YANG modules have meta data. A > NETCONF or RESTCONF server exposes which data models it implements. A > list of which vendor supports what is clearly outside the scope of > IETF work. > > o a common infrastructure model layer on which higher layer service > models can be built, for example by specifying which models are > needed to provide the service > > Not sure what this means exactly but I also do not see why any of the > existing RFCs breaks this. > > o an ability to express an instance of the structure consisting of > models that have been validated to work together (i.e., with > information about sources of the models, their versions, etc.), so > that operators can easily identify a set of models that is known > to be mutually consistent > > Not sure what this means exactly but YANG modules published by the > IETF are supposed to work together. YANG 1.1 has even clearer rules > what imports mean etc. > > Bottom line is that I do not get out of these bullets what is _broken_ > with the existing RFCs. I like to see text of the sort > > - RFC 7223 is broken because ... > - RFC 7277 is broken because ... > [...] > > This text is not in section 1.1 as far as I can tell. > > Bottom line is that I do not understand why /interfaces is broken such > that this needs to be redone while /device/interfaces is golden. What do > we do if in two years some group of people find /device/network/interfaces > a brilliant idea? > > /js > > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Aug 3 07:41:34 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 720FB1A1A4A for ; Mon, 3 Aug 2015 07:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u_WCx2i_r-Pj for ; Mon, 3 Aug 2015 07:41:31 -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 79F7B1A1A9F for ; Mon, 3 Aug 2015 07:41:31 -0700 (PDT) Received: by labsr2 with SMTP id sr2so13008462lab.2 for ; Mon, 03 Aug 2015 07:41:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=2lTDjrTYlC2SDipINhx3rRG/ME7HAeLb9rlzrxl+4WI=; b=RC4iHBMY6wN4TGVvIJbQY0n/sYBf0SOgUaSy+5YyuPKXoVjBV9ms8KNjdkjsEAb31N HVNeWoVkrt9ZoVh89QqiNiU2lKZSqUMuyDe9u5MdtT4FQIqFVzG4gzcg0u/Htl5PBV0d qgQqLv0k8IGUlEFLMKEtLceIfiV98UTcNYVvJET5UOI2czOkZ/wtSc4NlaZxq1i08Cfe m4hbYGILPC2FiGSsgH/kign9rRVGun0AwSgjv5q8bXdb3RPGUofoOD80uyK4xwjM7pHW H5wNDLDBIL5NZCy8krG0qKUG71PcbsY6s3u+JJjffzb0+MNRwWmLjqylEUp7CHZrO2Dv SFjg== X-Gm-Message-State: ALoCoQkKpwT4b0FVscxxpTKjQNTiDjOfUlLEm8QFOrZdMkI4iuV8EuZDNYUsz3zh7d3JYAXPkw+9 MIME-Version: 1.0 X-Received: by 10.112.160.42 with SMTP id xh10mr5144242lbb.88.1438612889847; Mon, 03 Aug 2015 07:41:29 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Mon, 3 Aug 2015 07:41:29 -0700 (PDT) In-Reply-To: <20150803092501.GB71565@elstar.local> References: <20150730.211629.1600508626921450694.mbj@tail-f.com> <1D650959-4AB3-4B74-8A30-7BE3A69B896D@nic.cz> <20150803081814.GA71323@elstar.local> <55BF2F21.1070900@mg-soft.si> <20150803092501.GB71565@elstar.local> Date: Mon, 3 Aug 2015 07:41:29 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Jernej Tuljak , Ladislav Lhotka , Andy Bierman , =?UTF-8?Q?Martin_Bj=C3=B6rklund?= , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11c3423844e15c051c692a61 Archived-At: Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 14:41:33 -0000 --001a11c3423844e15c051c692a61 Content-Type: text/plain; charset=UTF-8 On Mon, Aug 3, 2015 at 2:25 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Mon, Aug 03, 2015 at 11:06:41AM +0200, Jernej Tuljak wrote: > > Juergen Schoenwaelder je 3.8.2015 ob 10:18 napisal: > > >Any description statement in principle can do this. We trust that sane > > >data model writers won't do bad things. And if they do, we hope that > > >people will not implement and deploy bad things. > > > > Why not simply make this impossible by ensuring that description > > statements cannot change what has already been agreed upon in RFC6020 > > (aka YANG semantics)? I would have no problem with descriptions being > > normative, if this would be the case. > > You need to define way more clearly what 'YANG semantics' means. > > Agreed. The description-stmt is normative. It defines implementation requirements for a data node. It is not used to override other YANG statements. However, if the description says "child foo must be greater than the value of bar" that is just as normative as a must-stmt that says the same thing. > >I continue to see extension statements as reusable and (in principle) > > >machine readable fragments of description statements. From this > > >perspective, it seems odd to make a difference between extensions and > > >description statements. > > > > I still disagree that description statements should be more powerful > > than any other YANG statement. > > What does 'powerful' mean? Time that someone writes concrete text so > we can have a more constructive discussion. > A YANG description-stmt cannot override the syntax and semantics of other YANG statements. But is is mandatory and it is normative. > /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --001a11c3423844e15c051c692a61 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Aug 3, 2015 at 2:25 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Mon, Aug 03, 2015 at 11:06:41AM +0200, Jernej Tulj= ak wrote:
> Juergen Schoenwaelder je 3.8.2015 ob 10:18 napisal:
> >Any description statement in principle can do this. We trust that = sane
> >data model writers won't do bad things. And if they do, we hop= e that
> >people will not implement and deploy bad things.
>
> Why not simply make this impossible by ensuring that description
> statements cannot change what has already been agreed upon in RFC6020<= br> > (aka YANG semantics)? I would have no problem with descriptions being<= br> > normative, if this would be the case.

You need to define way more clearly what 'YANG semantics' means.


Agreed.=C2=A0 The descr= iption-stmt is normative.
It defines implementation requirements = for a data node.
It is not used to override other YANG statements= .
However, if the description says "child foo must be
<= div>greater than the value of bar" that is just as normative
as a must-stmt that says the same thing.


> >I continue to see extension statements as reusable and (in princip= le)
> >machine readable fragments of description statements. From this > >perspective, it seems odd to make a difference between extensions = and
> >description statements.
>
> I still disagree that description statements should be more powerful > than any other YANG statement.

What does 'powerful' mean? Time that someone writes concrete text s= o
we can have a more constructive discussion.

=

A YANG description-stmt cannot override the syntax and = semantics of other YANG
statements.=C2=A0 But is is mandatory and= it is normative.




/js


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

--001a11c3423844e15c051c692a61-- From nobody Mon Aug 3 07:48:59 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2D301A1A8A for ; Mon, 3 Aug 2015 07:48:57 -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 aMDiK8wG_lBK for ; Mon, 3 Aug 2015 07:48:53 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53EBF1A1A87 for ; Mon, 3 Aug 2015 07:48:52 -0700 (PDT) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id CAD81181747; Mon, 3 Aug 2015 16:48:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1438613330; bh=p4pZo4g/9rnoY/lPogLsIhYj6paXatjtKoVipfQo/nw=; h=From:Date:To; b=Twg0mCsIURbsbddA6qghYutPBJjR0AExwUn1c2rsqTKu0whGz1x5ucD8fV/yAMLFh 38Zin0bd/A7egjuu4ZNdzpwna+RBu4TS3vWD2tflIB7hiTLawlq79rE5YUyEa2IjEi ew6EZKxS7Pe2CbhgpmTpAb39xptZ4NINO3f6Q4no= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 3 Aug 2015 16:48:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <646276CA-ED9B-40D1-8613-4F0FD6DD69BE@nic.cz> References: <20150730.211629.1600508626921450694.mbj@tail-f.com> <1D650959-4AB3-4B74-8A30-7BE3A69B896D@nic.cz> <20150803081814.GA71323@elstar.local> <55BF2F21.1070900@mg-soft.si> <20150803092501.GB71565@elstar.local> To: Andy Bierman X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Jernej Tuljak , "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 14:48:58 -0000 > On 03 Aug 2015, at 16:41, Andy Bierman wrote: >=20 >=20 >=20 > On Mon, Aug 3, 2015 at 2:25 AM, Juergen Schoenwaelder = wrote: > On Mon, Aug 03, 2015 at 11:06:41AM +0200, Jernej Tuljak wrote: > > Juergen Schoenwaelder je 3.8.2015 ob 10:18 napisal: > > >Any description statement in principle can do this. We trust that = sane > > >data model writers won't do bad things. And if they do, we hope = that > > >people will not implement and deploy bad things. > > > > Why not simply make this impossible by ensuring that description > > statements cannot change what has already been agreed upon in = RFC6020 > > (aka YANG semantics)? I would have no problem with descriptions = being > > normative, if this would be the case. >=20 > You need to define way more clearly what 'YANG semantics' means. >=20 >=20 >=20 > Agreed. The description-stmt is normative. > It defines implementation requirements for a data node. > It is not used to override other YANG statements. > However, if the description says "child foo must be > greater than the value of bar" that is just as normative > as a must-stmt that says the same thing. >=20 >=20 > > >I continue to see extension statements as reusable and (in = principle) > > >machine readable fragments of description statements. =46rom this > > >perspective, it seems odd to make a difference between extensions = and > > >description statements. > > > > I still disagree that description statements should be more powerful > > than any other YANG statement. >=20 > What does 'powerful' mean? Time that someone writes concrete text so > we can have a more constructive discussion. >=20 >=20 > A YANG description-stmt cannot override the syntax and semantics of = other YANG > statements. But is is mandatory and it is normative. It=E2=80=99s not only about overriding. For example, it wouldn=E2=80=99t = be good to introduce a new data node type though an extension. Lada >=20 >=20 >=20 >=20 > /js >=20 >=20 > Andy > =20 >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Aug 3 07:52:34 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F3E51A1BB8 for ; Mon, 3 Aug 2015 07:52:33 -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 oj_cKZwHWdag for ; Mon, 3 Aug 2015 07:52:29 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0789.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::789]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 138781A00C7 for ; Mon, 3 Aug 2015 07:52:28 -0700 (PDT) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.151.167.91) by AMXPR07MB056.eurprd07.prod.outlook.com (10.242.67.151) with Microsoft SMTP Server (TLS) id 15.1.225.19; Mon, 3 Aug 2015 14:52:08 +0000 Message-ID: <002401d0cdfb$758b6760$4001a8c0@gateway.2wire.net> From: t.petch To: Andy Bierman References: <20150720210041.GA17614@elstar.local> <14ecceb6dd0.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <14ed0338068.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <55BBA679.7070508@labn.net> <20150801065150.GA67416@elstar.local> Date: Mon, 3 Aug 2015 15:48:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.167.91] X-ClientProxiedBy: DB4PR05CA0004.eurprd05.prod.outlook.com (25.160.40.14) To AMXPR07MB056.eurprd07.prod.outlook.com (10.242.67.151) X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB056; 2:02sBMYesfRtatnBo1TbI3ZJBtrcCdSvWepgt2bpCd3p7nJgU2QGNTZMKk8jk2gKTxOTiqPlVjNzDQ+S/b19TJndLJeSt312lJU2RwnzTplVTmwWXIOuwn1VKlYw6hQ46t9TvklVsgrYA6d55gT08Kh/a33WXGkAHsDgH8AEDeJY=; 3:EK+R0ouO9xT5MnGqoiTlcHbDGEVsUd3qjgQN4ZvAfDCLQ4SlqSVMjdbSc0kqwzm7O62iDbJUvJoxk/4CbLhh1lQyJxiK0GzPe1/aFoEjQZ5ldhkaC+egU8j4mShQx+4BiIFAHFRK3oNBPjsPO0aQXA==; 25:k6RSwJvFpcPKpSNC5L80T5delY5kc5GHfexE9vx4/MUiyuVV4Al71smuzs4mphkNX04GeXoajhlBfvv7tcsSBF8uQymWgxTUTQuR+K0P5cIYh663Si61y6GtwScaRdiG10ok9AfATJPCpFaZIbY2YFGTz4xyYr99YHXwZbvT3rq8LG6/0we6x+kOmCR3R5cbaDvjC7SDS8toNHSWJHE6hFEAHMIT56wfMDKPNfsUBMl194ygT3R36vVFfzMquPguHnZylikUf2RgNJ1nAkwZAQ==; 4:rj1Lu+y9TSWDEOtEfSEteJ7v8zH4TvCh5Jeo3P9w3aMmeotE3FGB0PkegKKKao6e6wkkp8HAYmH0OgM65fv1FdC4HjpJEiqmjsXjto+TE0NKaLdgoNLHy5B/pEy/VuUbRY8Krp6b7Ha7j8ns8hWrEpaV/vktTHS6eYfHOveJ/potVCVz8kpTxWwzTd4o0raxaqG31yFMMNZmw2XzAGTNqjh/fvzO8HTZ4vsfu+RRViD+UELOL/balmBchiSCbxlJQs6RpOoWJrYLaPCfTypeNK65eRUNt/jWDSQw5Xz73Hw= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB056; 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:AMXPR07MB056; BCL:0; PCL:0; RULEID:; SRVR:AMXPR07MB056; X-Forefront-PRVS: 0657D528EC X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(377454003)(13464003)(189002)(24454002)(479174004)(164054003)(23676002)(50466002)(77096005)(86362001)(50226001)(105586002)(47776003)(64706001)(68736005)(15975445007)(106356001)(1456003)(61296003)(5820100001)(44736004)(50986999)(87976001)(81686999)(42186005)(76176999)(81816999)(1556002)(84392001)(189998001)(101416001)(66066001)(93886004)(46102003)(5001830100001)(14496001)(110136002)(77156002)(62966003)(5001960100002)(33646002)(116806002)(4001540100001)(81156007)(122386002)(5001860100001)(92566002)(40100003)(19580395003)(5001920100001)(97736004)(19580405001)(62236002)(44716002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB056; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTVhQUjA3TUIwNTY7MjM6Yi9Kdk5Wa200UGIzSFhFeUIxRVYzbkZ6QlFw?= =?utf-8?B?VjlzdSt0R2tZcUJZZy8yWkZQUmhid1diRitXVXN6aTQ4TDZkWTBKTnNPblVk?= =?utf-8?B?dmY1dEpyb1IxUW16YVhPbkdQaEFheG92Mm1qa2pDK3ZuL2pVdUM1d3RPa1N1?= =?utf-8?B?bjdZU3lsQVFPbWNqQisySUR1RllObzZZanlmRXR6aWRMZlFLSys1aGlmT29n?= =?utf-8?B?akFvUFlncVJVVUNFejdoRmJ2U0F3dEdEYVZSdFZRcjV4Ukk4OTJTeFRjR1V1?= =?utf-8?B?MVZzR0dGNEpYRjczei82K0NuTmg4NC9RQ2RiOEJzQWhieUZlLzhMWkV4MzJV?= =?utf-8?B?cEp1SmhFY29LRDlrWDVPcUx2bEMzaGdESXYrbyttak5IVGo0Qk14RVI0cWNj?= =?utf-8?B?YWZjSFFpMWdBMmlKbEh3WDdWRjh6R0ZpU2ZNc0hkeDhka3ZiNGRwSGdXbDVX?= =?utf-8?B?NXBWRzh3eXFFeUh0UUMzVmR3Ty9qNFA4MHFsdVk3R1NqUDhuSDlCOWhUeEZW?= =?utf-8?B?SXhZWVh5VkhNcXJXdVkwVmdPQTFXVm9WOGQ0ZFl4ZDB3aTBveHVYdERVM05w?= =?utf-8?B?MDJyU0w3eFpIbkhQQWtvdTN0NG9OKzZwbDcxTzhsS0l2SlpRRldjOWhuSytr?= =?utf-8?B?KzJGZHc4Nk9ZeU1Wd0xTdEpXYk51Y1krR2FyaVFsbC9CaDJPQjB6RkdpaUJz?= =?utf-8?B?UCtUKzhvalA4OCtVeDhoa2RORHBycUNHdDR5cmxOVEVUcnUzNTRyYi8wMGZM?= =?utf-8?B?eGptSnRYS2RDY3hxZTBPc3RMK25QN1B0Sms2VW1aYVVvNENYS0diTDBTNWZj?= =?utf-8?B?MWJRN3Y1NFh0SU9uTWtOcnRVc0dtWmVOUUdCWEJwL044V3dGUkVKd2lHbUFh?= =?utf-8?B?RFFoNElGNm1RclRlcU9qbUJnWEJ1Si80dzVENEllZE9oektzSmk0Q3lyWTBL?= =?utf-8?B?VWRIeWg0Y0ViUUh5SEhLakoxT29BcEpTS2pVeWJzczdnODAwMnpqbmVseGZC?= =?utf-8?B?cWFxM1ZOQU1yQVcvbmtwODl4RFd4T2wyWVY1a2ZEdWVZWVdRbkxzTXFJbHZz?= =?utf-8?B?eDhCU2w0K2xNLzJjS1l5UTJNMEVSSThyanp4dTZudkloc0w5VnMvcjk1Q01u?= =?utf-8?B?enlwTFd4K0hSaEFweTdPQ3NTaWd1UW8rR0R0Y0lIQUJ6dWM3c1UzaEplcTdC?= =?utf-8?B?MVlSRi9pT0hwMzh2K0M1Y0F0WGFqdDNJTVZmUkVvajVTTnBTVkhvWXY2VVYz?= =?utf-8?B?SGtoeFkrOUZXRFY1NEtCMEV5WUhQYkgxWUVOMngvK3lCd2FHTTFScytaMzBt?= =?utf-8?B?RVpDY0FCT3p2elRrd2cyYmMySW8xOExsai9ZL1ZyMHVidGxMRzR5ZDVXd0po?= =?utf-8?B?OVR6WmIvSjdKekVCb0NXZE41cDN4QnJwdW8yamRJNjR0emdmNFpxUElrUXIr?= =?utf-8?B?S3lUQmw4RjZIZ3Ftczh3VFRteWtvTjlqbU1nWm1sL25qMVd0bzB1LzhqN045?= =?utf-8?B?S0lQZzc4RGw2WlZ5a3FQV0s0UnM2cDAvM2svQlM1b1NEdkFzeVZjNXc3ZWRr?= =?utf-8?B?TlVqNG5KTlNKN1hlNE85UUN1c2xyYy9sUmpYeFQ5ME5BMVpaNjVuWHZDc0Yv?= =?utf-8?B?RytTQitSa0xrZEJtc3lCeUtmaDFhUHZCRXBrOGU2aDZ5U1E2VmRYUkZvbUlQ?= =?utf-8?B?dXpUTHdwZkVLMkZ5WThsK3libjlJNVF0eklqZThmVlQzTGlRa2NxVlcyMjVn?= =?utf-8?B?a0tkME9iNlVRR1Ixc2drbVh2cE45Q3pvZFJmMXRvOTJ5OWVWMHRvRVpnSTFQ?= =?utf-8?B?Uk9RSjRxdlRSNzNQNXNxNU1BeTMycUdrZTUyaGpGWjk4VmVPamFEMnNLMXlu?= =?utf-8?B?eTRENUNvMUt3NzdUN3dwU1NvNFlOemtMcEhhMkFlczJrTkc0Tk1qM3lmeVBw?= =?utf-8?B?UTFOUkJrMkh0NTBmV3FLMDVCTWkxY1ZNeHRwVXFKdHZhaFZpT3FCZDBZYzVE?= =?utf-8?Q?hdwLY?= X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB056; 5:NsI7jFnbSSyWgP6mbXkOd/Rb2LU0/x0+yLy7AVXIV8I+zqAVtUQpHDx/znOwRpCAaOCdM3gM5m1y86bfo9YJWzHZjoQADfr8G2WoUVNScm2wHqBcuYRqH9+lfMV/EEVF+VJD1kY1GSxG3X7JqGDJyg==; 24:oHjURkszmGPouMXoRr4mpAAxG7a1WrreXNurulkusiiUW80J8eg9VcOP8IQY4sl88sK+mVHHezILH9Ww9UZiROC20VC4KNBvmkAcWRWh5/4=; 20:4gIyG5A4RERTNqdwMd+lyVURI0crGTUHv8IP1q2/u9z6R5OGrN0fNVatzHIiREOkXfm7l+83HPaGu6/JM+oNtA== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Aug 2015 14:52:08.5999 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB056 Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Y34 - root node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 14:52:33 -0000 ----- Original Message ----- From: "Andy Bierman" To: "Acee Lindem (acee)" Cc: "NETMOD Working Group" Sent: Saturday, August 01, 2015 7:05 PM Subject: Re: [netmod] Y34 On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem (acee) wrote: > Hi Juergen, > > On 8/1/15, 2:51 AM, j.schoenwaelder@jacobs-university.de> wrote: > > >On Fri, Jul 31, 2015 at 12:46:49PM -0400, Lou Berger wrote: > >> Andy, > >> > >> On 07/27/2015 12:58 PM, Andy Bierman wrote: > >> > Hi, > >> > > >> > I don't think a standard for relocating subtrees would be worth it. > >> > I am not in favor of moving /interfaces or /system to a new location. > >> > That's not how YANG works. It only allows "obsolete and start over". > >> > > >> > I would suggest pursuing solutions that don't cause > >> > as much disruption and expense as possible. > >> > > >> I think it would be really good to explore other, less "disruptive" > >> options. > > > >I think the first step is to find out whether there is a problem worth > >to be fixed. Why are the RFCs in question broken? (Yes, I have read > >the openconfig IDs, > > Section 1.1 in > https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt > lists the goals of a generic model structure that will accommodate most > modern network devices. I guess you don’t agree that these are desirable? The only objection I have to this draft is the insertion of a top-level root called "device". (Might as well be called "self"). There are no sibling nodes planned or intended for this node, so it serves as an extra document root. One aspect of YANG I have never grasped is what a root means, if anything. I understand that it is needed for NETCONF (filters) and for YANG (augments, constraints) and so must be somewhere and must be relatively stable, but has it any other significance in the data model? As you may recall, I was involved with SMI first, where the root is somewhere up in the sky and life only becomes interesting some six levels down the hierarchy and that may colour my thinking. Tom Petch The well-specified XPath and YANG root (/) can be accessed by all protocol operations, exactly the same as a node called 'device'. The actual node name will depend on the RPC function (e.g. 'data' or 'config'). This is more than redundant however. It introduces a "super-module" into YANG that every other module is expected to augment. YANG is intended to be more loosely coupled than that. This introduces an extra node and namespace declaration in all protocol messages, increasing message sizes. It also assumes all existing YANG models will get rewritten to account for "/device" in all path and XPath expressions. This is highly disruptive to existing deployments. Also, multiple data models to edit the same thing causes lots of extra complexity in the server (supporting both old location and new location). IMO a resource directory approach is much more realistic. The /device tree can contain all the organized NP containers. Instead of all the actual data nodes, this tree just has pointers to the real location of the resource. (like 301 Moved Permanently) Thanks, > Acee > > > Andy From nobody Mon Aug 3 08:10:23 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 834651A906D for ; Mon, 3 Aug 2015 08:10:21 -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_15=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 tkZ_LKy6JECy for ; Mon, 3 Aug 2015 08:10:17 -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 A07981A907F for ; Mon, 3 Aug 2015 08:10:16 -0700 (PDT) Received: by labow3 with SMTP id ow3so18903527lab.1 for ; Mon, 03 Aug 2015 08:10: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=kVj5PJMUdFBkYxxleuQOK4GCLzcjCa94qbJrJUR+rl0=; b=Kf7KemFaNd5nbRmB1mPcKZP9hUmbnACimwdvCoUECF6JCYNsckzPdKTdn1Y7Cm33AG WaunJCH/nnC+uNwWno53DY1ztM92QOr1YL0a86867/fv2uXth56Y6s8h8PvxZ5+VJdq8 6xjymso7yEbcLcLjfu7kFJCPcsbdWN+ojlTaQ00RN5pvp+rVJvKyezSgKKH2RgCDCGlm QmRQmAIeiZugCeSJpqOKALq/E3C9M7dGmCekxZp+KjKgTUhj/TSU0ofy2y0h1qvrmMqB MGfkopTGZ9I+Vjq72ITxpf8K6rZzw56gu/M6PVVXyp212b6AWJgEJpthty0sQL1KqBKf v0JQ== X-Gm-Message-State: ALoCoQkJYWFxc2zUCIHOpB/wMhtnEhNahJeq2XhApG5PIj4vpNfx9du1qL+0ZajlIGpPsWEJnzI2 MIME-Version: 1.0 X-Received: by 10.112.85.3 with SMTP id d3mr17429901lbz.33.1438614615052; Mon, 03 Aug 2015 08:10:15 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Mon, 3 Aug 2015 08:10:14 -0700 (PDT) In-Reply-To: <002401d0cdfb$758b6760$4001a8c0@gateway.2wire.net> References: <20150720210041.GA17614@elstar.local> <14ecceb6dd0.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <14ed0338068.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <55BBA679.7070508@labn.net> <20150801065150.GA67416@elstar.local> <002401d0cdfb$758b6760$4001a8c0@gateway.2wire.net> Date: Mon, 3 Aug 2015 08:10:14 -0700 Message-ID: From: Andy Bierman To: "t.petch" Content-Type: multipart/alternative; boundary=001a1134946c196b5b051c6991e4 Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Y34 - root node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 15:10:21 -0000 --001a1134946c196b5b051c6991e4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Aug 3, 2015 at 7:48 AM, t.petch wrote: > ----- Original Message ----- > From: "Andy Bierman" > To: "Acee Lindem (acee)" > Cc: "NETMOD Working Group" > Sent: Saturday, August 01, 2015 7:05 PM > Subject: Re: [netmod] Y34 > On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem (acee) > wrote: > > > Hi Juergen, > > > > On 8/1/15, 2:51 AM, j.schoenwaelder@jacobs-university.de> wrote: > > > > >On Fri, Jul 31, 2015 at 12:46:49PM -0400, Lou Berger wrote: > > >> Andy, > > >> > > >> On 07/27/2015 12:58 PM, Andy Bierman wrote: > > >> > Hi, > > >> > > > >> > I don't think a standard for relocating subtrees would be worth > it. > > >> > I am not in favor of moving /interfaces or /system to a new > location. > > >> > That's not how YANG works. It only allows "obsolete and start > over". > > >> > > > >> > I would suggest pursuing solutions that don't cause > > >> > as much disruption and expense as possible. > > >> > > > >> I think it would be really good to explore other, less "disruptive" > > >> options. > > > > > >I think the first step is to find out whether there is a problem > worth > > >to be fixed. Why are the RFCs in question broken? (Yes, I have read > > >the openconfig IDs, > > > > Section 1.1 in > > https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt > > lists the goals of a generic model structure that will accommodate > most > > modern network devices. I guess you don=E2=80=99t agree that these are > desirable? > > The only objection I have to this draft is the insertion of a top-level > root > called "device". (Might as well be called "self"). > There are no sibling nodes planned or intended for > this node, so it serves as an extra document root. > > > One aspect of YANG I have never grasped is what a root means, if > anything. > > I understand that it is needed for NETCONF (filters) and for YANG > (augments, constraints) and so must be somewhere and must be relatively > stable, but has it any other significance in the data model? > > As you may recall, I was involved with SMI first, where the root is > somewhere up in the sky and life only becomes interesting some six > levels down the hierarchy and that may colour my thinking. > > YANG does a poor job of defining the root for YANG data nodes. It is sometimes called a datastore (in the abstract). Technically, YANG borrows the definition from XPath. YANG just defines top-level data nodes and the parent of these nodes is the document root. There is no protocol or encoding neutral definition, only an XML-specific definition. > Tom Petch > Andy > > > The well-specified XPath and YANG root (/) can be > accessed by all protocol operations, exactly the same > as a node called 'device'. The actual node name will > depend on the RPC function (e.g. 'data' or 'config'). > > This is more than redundant however. It introduces a "super-module" > into YANG that every other module is expected to augment. > YANG is intended to be more loosely coupled than that. > This introduces an extra node and namespace declaration > in all protocol messages, increasing message sizes. > > It also assumes all existing YANG models will get rewritten to > account for "/device" in all path and XPath expressions. > This is highly disruptive to existing deployments. > Also, multiple data models to edit the same thing causes lots > of extra complexity in the server (supporting both old > location and new location). > > IMO a resource directory approach is much more realistic. > The /device tree can contain all the organized NP containers. > Instead of all the actual data nodes, this tree just has pointers > to the real location of the resource. (like 301 Moved Permanently) > > Thanks, > > Acee > > > > > > > Andy > > > --001a1134946c196b5b051c6991e4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Aug 3, 2015 at 7:48 AM, t.petch <ietfc@btconnect.com&g= t; wrote:
----- Original Message -= ----
From: "Andy Bierman" <an= dy@yumaworks.com>
To: "Acee Lindem (acee)" <ac= ee@cisco.com>
Cc: "NETMOD Working Group" <netmod@ietf.org>
Sent: Saturday, August 01, 2015 7:05 PM
Subject: Re: [netmod] Y34
On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem (acee) <acee@cisco.com>
wrote:

> Hi Juergen,
>
> On 8/1/15, 2:51 AM,=C2=A0 j.schoenwaelder@jacobs-university.de> wrote:
>
> >On Fri, Jul 31, 2015 at 12:46:49PM -0400, Lou Berger wrote:
> >> Andy,
> >>
> >> On 07/27/2015 12:58 PM, Andy Bierman wrote:
> >> > Hi,
> >> >
> >> > I don't think a standard for relocating subtrees wou= ld be worth
it.
> >> > I am not in favor of moving /interfaces or /system to a = new
location.
> >> > That's not how YANG works. It only allows "obso= lete and start
over".
> >> >
> >> > I would suggest pursuing solutions that don't cause<= br> > >> > as much disruption and expense as possible.
> >> >
> >> I think it would be really good to explore other, less "= disruptive"
> >> options.
> >
> >I think the first step is to find out whether there is a problem worth
> >to be fixed. Why are the RFCs in question broken? (Yes, I have rea= d
> >the openconfig IDs,
>
> Section 1.1 in
> https://www.ietf.org/id/d= raft-openconfig-netmod-model-structure-00.txt
> lists the goals of a generic model structure that will accommodate
most
> modern network devices. I guess you don=E2=80=99t agree that these are=
desirable?

The only objection I have to this draft is the insertion of a top-level
root
called "device".=C2=A0 (Might as well be called "self")= .
There are no sibling nodes planned or intended for
this node, so it serves as an extra document root.

<tp>
One aspect of YANG I have never grasped is what a root means, if
anything.

I understand that it is needed for NETCONF (filters) and for YANG
(augments, constraints) and so must be somewhere and must be relatively
stable, but has it any other significance in the data model?

As you may recall, I was involved with SMI first, where the root is
somewhere up in the sky and life only becomes interesting some six
levels down the hierarchy and that may colour my thinking.



YANG does a poor job of= defining the root for YANG data nodes.
It is sometimes called a = datastore (in the abstract).
Technically, YANG borrows the defini= tion from XPath.
YANG just defines top-level data nodes and the p= arent of
these nodes is the document root.

There is no protocol or encoding neutral definition,
only an X= ML-specific definition.

=C2=A0
Tom Petch

Andy
=C2=A0


The well-specified XPath and YANG root (/) can be
accessed by all protocol operations, exactly the same
as a node called 'device'.=C2=A0 The actual node name will
depend on the RPC function (e.g. 'data' or 'config').

This is more than redundant however.=C2=A0 It introduces a "super-modu= le"
into YANG that every other module is expected to augment.
YANG is intended to be more loosely coupled than that.
This introduces an extra node and namespace declaration
in all protocol messages, increasing message sizes.

It also assumes all existing YANG models will get rewritten to
account for "/device" in all path and XPath expressions.
This is highly disruptive to existing deployments.
Also, multiple data models to edit the same thing causes lots
of extra complexity in the server (supporting both old
location and new location).

IMO a resource directory approach is much more realistic.
The /device tree can contain all the organized NP containers.
Instead of all the actual data nodes, this tree just has pointers
to the real location of the resource. (like 301 Moved Permanently)

Thanks,
> Acee
>
>
>
Andy



--001a1134946c196b5b051c6991e4-- From nobody Mon Aug 3 09:01:43 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE36E1A92E2 for ; Mon, 3 Aug 2015 09:01:41 -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_64=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 dBE5nZs9D_jg for ; Mon, 3 Aug 2015 09:01:37 -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 8E1B41A92EB for ; Mon, 3 Aug 2015 09:01:31 -0700 (PDT) Received: by lbbpo9 with SMTP id po9so6544051lbb.2 for ; Mon, 03 Aug 2015 09:01: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=V+188sMOoBer9cdXM+hJYPBV/QhetwCuQd4j6npH50Q=; b=jZ+XRw/ylOGlgi+1YdUbWpD4TZqfnXCKZSmR90Zs7ses4+Q6g5FmGTEIdxYjq8yD8d 4DjuSmiA11EpeRJONlFv4aLzAico4AA2qGcrDow994a+zlpbVxiXz73NYU4KHuP57AK/ 6BK/ocIt5cqwwcblPmk4+Z3XQHTRQ1yJyfXDjiQIN+zzeVY/Zk1JQU2ugTx6ABBgoP/Q 3Nkp2uXyzjc7caczpvkdUm8o7Bxe8mZQI8lI5SomXkwOwo/W+5kth2L1JTZMx0lXTHIF e8dbqmtUBsZ13Kwuef1Cd32Abpw775T/hvr+ENNhpefuakrks2xtHc2hGaWX13P5sb1q kHkw== X-Gm-Message-State: ALoCoQliIlVinBtqU1z6U+PQEFYHPqRMcB+iGD6ZoyxxG6L9MjoPb0qCTUW+Dnb2RsHj+GtjZFbX MIME-Version: 1.0 X-Received: by 10.112.118.41 with SMTP id kj9mr16300193lbb.123.1438617689949; Mon, 03 Aug 2015 09:01:29 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Mon, 3 Aug 2015 09:01:29 -0700 (PDT) In-Reply-To: <646276CA-ED9B-40D1-8613-4F0FD6DD69BE@nic.cz> References: <20150730.211629.1600508626921450694.mbj@tail-f.com> <1D650959-4AB3-4B74-8A30-7BE3A69B896D@nic.cz> <20150803081814.GA71323@elstar.local> <55BF2F21.1070900@mg-soft.si> <20150803092501.GB71565@elstar.local> <646276CA-ED9B-40D1-8613-4F0FD6DD69BE@nic.cz> Date: Mon, 3 Aug 2015 09:01:29 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=047d7bfd0098609ec6051c6a4803 Archived-At: Cc: Jernej Tuljak , "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 16:01:41 -0000 --047d7bfd0098609ec6051c6a4803 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Aug 3, 2015 at 7:48 AM, Ladislav Lhotka wrote: > > > On 03 Aug 2015, at 16:41, Andy Bierman wrote: > > > > > > > > On Mon, Aug 3, 2015 at 2:25 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > On Mon, Aug 03, 2015 at 11:06:41AM +0200, Jernej Tuljak wrote: > > > Juergen Schoenwaelder je 3.8.2015 ob 10:18 napisal: > > > >Any description statement in principle can do this. We trust that sa= ne > > > >data model writers won't do bad things. And if they do, we hope that > > > >people will not implement and deploy bad things. > > > > > > Why not simply make this impossible by ensuring that description > > > statements cannot change what has already been agreed upon in RFC6020 > > > (aka YANG semantics)? I would have no problem with descriptions being > > > normative, if this would be the case. > > > > You need to define way more clearly what 'YANG semantics' means. > > > > > > > > Agreed. The description-stmt is normative. > > It defines implementation requirements for a data node. > > It is not used to override other YANG statements. > > However, if the description says "child foo must be > > greater than the value of bar" that is just as normative > > as a must-stmt that says the same thing. > > > > > > > >I continue to see extension statements as reusable and (in principle= ) > > > >machine readable fragments of description statements. From this > > > >perspective, it seems odd to make a difference between extensions an= d > > > >description statements. > > > > > > I still disagree that description statements should be more powerful > > > than any other YANG statement. > > > > What does 'powerful' mean? Time that someone writes concrete text so > > we can have a more constructive discussion. > > > > > > A YANG description-stmt cannot override the syntax and semantics of > other YANG > > statements. But is is mandatory and it is normative. > > It=E2=80=99s not only about overriding. For example, it wouldn=E2=80=99t = be good to > introduce a new data node type though an extension. > > But isn't that exactly what you are proposing by making ephemeral data an extension instead of part of YANG? None of the existing text covers the validation rules for ephemeral data. Nothing is needed for config=3Dtrue nodes in the ephemeral datastore, but ephemeral-only data needs to be identified. Validation rules are needed for ephemeral data. Whether this is part of a protocol spec or YANG needs to be decided. > Lada > > Andy > > > > > > > > > > /js > > > > > > Andy > > > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --047d7bfd0098609ec6051c6a4803 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


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

> On 03 Aug 2015, at 16:41, Andy Bierman <andy@yumaworks.com> wrote:
>
>
>
> On Mon, Aug 3, 2015 at 2:25 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-universi= ty.de> wrote:
> On Mon, Aug 03, 2015 at 11:06:41AM +0200, Jernej Tuljak wrote:
> > Juergen Schoenwaelder je 3.8.2015 ob 10:18 napisal:
> > >Any description statement in principle can do this. We trust = that sane
> > >data model writers won't do bad things. And if they do, w= e hope that
> > >people will not implement and deploy bad things.
> >
> > Why not simply make this impossible by ensuring that description<= br> > > statements cannot change what has already been agreed upon in RFC= 6020
> > (aka YANG semantics)? I would have no problem with descriptions b= eing
> > normative, if this would be the case.
>
> You need to define way more clearly what 'YANG semantics' mean= s.
>
>
>
> Agreed.=C2=A0 The description-stmt is normative.
> It defines implementation requirements for a data node.
> It is not used to override other YANG statements.
> However, if the description says "child foo must be
> greater than the value of bar" that is just as normative
> as a must-stmt that says the same thing.
>
>
> > >I continue to see extension statements as reusable and (in pr= inciple)
> > >machine readable fragments of description statements. From th= is
> > >perspective, it seems odd to make a difference between extens= ions and
> > >description statements.
> >
> > I still disagree that description statements should be more power= ful
> > than any other YANG statement.
>
> What does 'powerful' mean? Time that someone writes concrete t= ext so
> we can have a more constructive discussion.
>
>
> A YANG description-stmt cannot override the syntax and semantics of ot= her YANG
> statements.=C2=A0 But is is mandatory and it is normative.

It=E2=80=99s not only about overriding. For example, it wouldn=E2=80=99t be= good to introduce a new data node type though an extension.


But isn't that exactly what you ar= e proposing by making ephemeral data
an extension instead of part= of YANG?

None of the existing text covers the val= idation rules for ephemeral data.
Nothing is needed for config=3D= true nodes in the ephemeral datastore,
but ephemeral-only data ne= eds to be identified.

Validation rules are needed = for ephemeral data.
Whether this is part of a protocol spec or YA= NG needs to be decided.


=C2=A0
Lada


Andy
=C2=A0
>
>
>
>
> /js
>
>
> Andy
>
>
> --
> 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/>
>

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





--047d7bfd0098609ec6051c6a4803-- From nobody Mon Aug 3 09:06:20 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB4741ABD38 for ; Mon, 3 Aug 2015 09:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, SPF_HELO_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 0rRimohoFSeE for ; Mon, 3 Aug 2015 09:06:14 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0737.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::737]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D25FC1ABC10 for ; Mon, 3 Aug 2015 09:06:11 -0700 (PDT) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.151.167.91) by DBXPR07MB064.eurprd07.prod.outlook.com (10.242.147.24) with Microsoft SMTP Server (TLS) id 15.1.225.19; Mon, 3 Aug 2015 16:05:52 +0000 Message-ID: <03d301d0ce05$c320a800$4001a8c0@gateway.2wire.net> From: t.petch To: Andy Bierman References: <20150720210041.GA17614@elstar.local><14ecceb6dd0.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net><14ed0338068.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net><55BBA679.7070508@labn.net><20150801065150.GA67416@elstar.local><002401d0cdfb$758b6760$4001a8c0@gateway.2wire.net> Date: Mon, 3 Aug 2015 17:01:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.167.91] X-ClientProxiedBy: DB4PR05CA0040.eurprd05.prod.outlook.com (25.160.40.50) To DBXPR07MB064.eurprd07.prod.outlook.com (10.242.147.24) X-Microsoft-Exchange-Diagnostics: 1; DBXPR07MB064; 2:0dOGvwadhCeLMh7MnjdltXxct+Xlx1fJpgv6qEDgD+bPXUPbPffgJPujg4DpCWeGhFJtihs22TKn6/6umcLt0xTDH8C7FOXGu/y3NUAh0FB2XeLIX0JrfZ8jfBSwNJ1AzBAcRhjGb+Vq/KnTQ5nyl2TvkodcAhipj5f30LNXaDw=; 3:IxaxUS7gghvoYoTQrUNIX5GxHdESTZEMDUn0wox/Jz/e4am8hY4RlTwBe/YKBYfKhgOOwdg/VtY9aZ9AseyzVBffT0gOsfmG70czwngNsaP6LS2w57YsC9JXjdExyrWPvn5z9UKrbFfykb1ik86iJQ==; 25:wkB9qe0i2Q1DVJkogkbY8jdJ3Rq7icwOUVgAcqbHU3Hs5gLTddibR7l3NHvFcmk4q3LxtGqVXND1fNIyPpPd89Nuc7dgitSGFVs1c213ZZuwCHxZLI59q9soo9ZSmL+20I6dTB/+JmNGVPiOSaOqPknHBq2+19BqEAR6rNNW63Fs5ah3h9kfLC1OgFHiK/muWpYzEC3PizBGd44vUqPKHII3k3IekBLRH5wFwTDvX4VcOQHbdLVEObaSxVSbBVAYsBhtcI/kubTsUEWIwZ77nA==; 4:NUZeT9Z7zjEZVwwcYrSpYQsizKFLduvU9mdE5T7Qn0rN8mOGc3e/BY11yIyaTqMxnyDHdiGLotOM1zFVtgp7N/ZuN0cQd0s/nca2VVWCarkmxeUbptj23S6qHcrVzUrWPZ91OxD+8oPlQazgYEjtBCrBbD39MpvWTO7YryaVKli75q08xvRLYutCwziD8QwtMzlu/Ja5g1ujFk4vvoGWA6JwFVseWSYC5LCvlnAbC+1FrKGpOjG5y075TZZ0ZxEKyctLQEsQ5DvjoRXLc3vF/I/iwvQDgOENus6fOvAOJMc= 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)(3002001); SRVR:DBXPR07MB064; BCL:0; PCL:0; RULEID:; SRVR:DBXPR07MB064; X-Forefront-PRVS: 0657D528EC X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(164054003)(479174004)(13464003)(377454003)(24454002)(106356001)(68736005)(77096005)(105586002)(15975445007)(1556002)(86362001)(116806002)(87976001)(84392001)(1456003)(92566002)(93886004)(81816999)(50986999)(5001960100002)(76176999)(81686999)(62236002)(44716002)(23676002)(101416001)(189998001)(5001860100001)(50466002)(97736004)(5001830100001)(110136002)(81156007)(4001540100001)(50226001)(42186005)(44736004)(61296003)(19580405001)(19580395003)(64706001)(47776003)(66066001)(46102003)(5820100001)(77156002)(62966003)(33646002)(14496001)(40100003)(122386002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB064; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQlhQUjA3TUIwNjQ7MjM6MVFTN0VCejNBRDNaLy9wb1BpVGtjSG1hdFh0?= =?utf-8?B?cjlZSzhXUkhvVzdJN2w4Q2l3WTZrbDRJNWo2c0ExbDAwSEVjZ1VEYms5ZXhV?= =?utf-8?B?RW5aNjVXS0tKLzE1SGhRSmdKTkNIeVF6eEJSckJ4Y3djRFR3MFduandCRkxo?= =?utf-8?B?SDBoRDh0VDBmWU1KNnY1WU0yU1ZrT3U5aWJXSU4wakdyU3VJbXhWMW5JNHpE?= =?utf-8?B?T1dkbzVNbDhSQ3pUYit0Q3V5ZDUxVTRDcDFWVkNjZFhSYU5yS0d5YmdYbzNK?= =?utf-8?B?TXVRUnNMYzRqTWR5VDVmZzdjOU9teDU2K1owUzJOZWRyakNnNXhlQ0Q5cHh6?= =?utf-8?B?aUN2ZXRuZTM0dzZibGlvNjJZYjBhREJJSzN1QTVtaVpjZGYzRTBJWXJLSVJY?= =?utf-8?B?cnU3eEloMmlNbGZZRVhWbHdDelhpNjUvTllHQTJUd2hscHhySlBGS1UwVGdH?= =?utf-8?B?b0ZrVTBNZHliYWJDL2NybEdTelNkTDdFUldNK3dRZE5oNXFKS2VFdEg5YXhq?= =?utf-8?B?b1hzckR2SWt2RFc0aXhwMCtPUUZKZ3lxT2ozQjRaaTYwQ2JpYitCVmNLcmZz?= =?utf-8?B?UWNtNmlNMWtuK0lHNFQ0bnJqanUrZm1nLzRuVGVCRHNtaTdvelhGSWJEazlk?= =?utf-8?B?T1ZEazZuVFpnU0JYeVUvWkQwcXh5WVY4M05iLytoUGdGUnZLY2pFeFVDWHph?= =?utf-8?B?YlhKNktWTHdEQ3pPMnlxUlZ3R2xTdlYzNkUya1RNUlQvME9Ba01DOWdtYWFw?= =?utf-8?B?Qy82WUJLZXVNbzJwTm90Vkh2aU9PdzEvMGNHT2RmeFUweWJNZ1RrT29IN1Zh?= =?utf-8?B?OEprVzB0K01rVUtlNml4VlpVN1o5eVlOOEVZRUovcGtUdEtBeEhLUHVsVHZo?= =?utf-8?B?NHRDYWtrUlNqcS9uclU2RlZPb2R5Zm9vNWYzdHB1N0VTVTdDY2lMWDdJMjNz?= =?utf-8?B?WTFkb24rYlVrdDN5Qi9hS1RIR1lweVBhdDNrVVpGYi9ISnFYcldUR2RkZi96?= =?utf-8?B?RmVsQ3NGY1J4ZVY5c2NQaTNCSm1FdTFUTjNBV3dkVlJYcWN0d3ptWHRYbEhK?= =?utf-8?B?bTF1YUc5aHRSdXpqa3ltS0pZNENFSlc0K0dhdWN1Wk1aVm5KWWlzWGNZL0ZG?= =?utf-8?B?Y2l5czdMSGVkRC9OSkZqSTdyV3NGQ2VndnhsUFoxa2VyQ0tvNGZ0blkwNytm?= =?utf-8?B?UmJJSFJ6b284TGpWbXJzODZOTmdTRTNlcXI1V09LcFJxNFBmdU8wV2JKcDQ4?= =?utf-8?B?TXNGb2ROSlVKRzdzNGdaU0ZnWklRUlF5SjNGYTlvV3I5RmgzeTFHSXIzd2dV?= =?utf-8?B?YUwwRndGRW4vakpJUTROWGJIdWZNYU9Rb0xobVJHTjZiaG1TWHdHZFlvRmNk?= =?utf-8?B?TnVYcjY3dllZQTQ5S1A1QjlSVERHYzN6amc5eDJDSzQyRGJ6NWd4Qk54Yjky?= =?utf-8?B?bDBDY2dka2R4djhWdXQ1OU5kNWJKUmhIeVV1MG9DWDhJOEltNkJnMmxGRXFW?= =?utf-8?B?aUFBd1NUOVdORVN6bmxyTFVPNTNHdE5NcmFqSDVvaWlZUmVFUlFKRkpaQVds?= =?utf-8?B?V0pvaFFRU2o5Z1ppYkRDVlVpREtvZllFajlOWEtiQ3VQa3RqdkFpQitibWVX?= =?utf-8?B?WFUvWXZGQmZOUTNBY1dUTzk3dUNpekx2K3l5V21hR0dKMWhXOWllVWYxWElw?= =?utf-8?B?VzFOQkN0Y1NxSWhTT3l0TmtIeTBSbHU4OUFnOGxySktSeUpHLzJ2OGV4T3ly?= =?utf-8?B?M2RSL0t4TmJKSi9SZGN5azdXTkZOcTVOeHlHcVA5Z25IQnVEK2M5b1Rpc1Zv?= =?utf-8?B?QkI3U0FjRU52T0RvbGtEajlkalNYRWdQN0xJQS94TzJVUU9HM3R2ZG81cXZY?= =?utf-8?B?aUlWdVdPRHdkdm1GdkdETnZNRExwMWw4aURGZUlqOHF2YmRiaW9SbzFMMmgv?= =?utf-8?B?SEsyYXludGc9PQ==?= X-Microsoft-Exchange-Diagnostics: 1; DBXPR07MB064; 5:+JCLRwq3hejzAS5bNckDBmmNTXcxjk0BzOd014LFRMtU7xKkBhsJ6LFMJtqmoviNaTiICaqub51PBQqS5UulABvDnRBqHqmdbXYMYXhBgGMH2ImiqayPitDtBxhD9137WC7vmWJqF9WAgWgXcL38Aw==; 24:JVjH/HbjNArMFTDOkML0pXPzz/1LTuBHpUglRpcNidfr4otrxeW5H7oFogw0cnUmoggAearMoWcjCcMZJ44ih0u3WG08mp5myCtlOf6QhIw=; 20:FBnR71GKq7bB1pkek6SpFz7B7jI7WCCsnYUv48iQ6lS3jjSVt5FjR0R6FfmSpt/Cc4AJm3f31iRZXPdanzAhbg== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Aug 2015 16:05:52.6521 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB064 Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Y34 - root node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 16:06:17 -0000 ----- Original Message ----- From: "Andy Bierman" To: "t.petch" Cc: "NETMOD Working Group" Sent: Monday, August 03, 2015 4:10 PM On Mon, Aug 3, 2015 at 7:48 AM, t.petch wrote: > ----- Original Message ----- > From: "Andy Bierman" andy@yumaworks.com > Sent: Saturday, August 01, 2015 7:05 PM > On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem (acee) > wrote: > > > Hi Juergen, > > > > On 8/1/15, 2:51 AM, j.schoenwaelder@jacobs-university.de> wrote: > > > > >On Fri, Jul 31, 2015 at 12:46:49PM -0400, Lou Berger wrote: > > >> Andy, > > >> > > >> On 07/27/2015 12:58 PM, Andy Bierman wrote: > > >> > Hi, > > >> > > > >> > I don't think a standard for relocating subtrees would be worth > it. > > >> > I am not in favor of moving /interfaces or /system to a new > location. > > >> > That's not how YANG works. It only allows "obsolete and start > over". > > >> > > > >> > I would suggest pursuing solutions that don't cause > > >> > as much disruption and expense as possible. > > >> > > > >> I think it would be really good to explore other, less "disruptive" > > >> options. > > > > > >I think the first step is to find out whether there is a problem > worth > > >to be fixed. Why are the RFCs in question broken? (Yes, I have read > > >the openconfig IDs, > > > > Section 1.1 in > > https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt > > lists the goals of a generic model structure that will accommodate > most > > modern network devices. I guess you don’t agree that these are > desirable? > > The only objection I have to this draft is the insertion of a top-level > root > called "device". (Might as well be called "self"). > There are no sibling nodes planned or intended for > this node, so it serves as an extra document root. > > > One aspect of YANG I have never grasped is what a root means, if > anything. > > I understand that it is needed for NETCONF (filters) and for YANG > (augments, constraints) and so must be somewhere and must be relatively > stable, but has it any other significance in the data model? > > As you may recall, I was involved with SMI first, where the root is > somewhere up in the sky and life only becomes interesting some six > levels down the hierarchy and that may colour my thinking. > YANG does a poor job of defining the root for YANG data nodes. It is sometimes called a datastore (in the abstract). Technically, YANG borrows the definition from XPath. YANG just defines top-level data nodes and the parent of these nodes is the document root. There is no protocol or encoding neutral definition, only an XML-specific definition. Thanks for that. It seems to me that much of the extensive discussion on Y34 (all of which I have read) is as much political as technical, that is SMI is hierarchical, top down, perhaps befitting its origins in ISO, whereas YANG is bottom up. IETF-like. YANG could have had a single tree, but doesn't. So when I read https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt I see a plea for a more hierarchical organisation, and when I read draft-bjorklund-netmod-openconfig-reply-00 I see a response that says we are not like that. If so, I doubt that there ever will be a technical solution. And I am mindful that when I configure routing in a (Cisco) router, I have to do some of it under the interface definitions and some of it under the definition of the routing protocol. Which is life, never wholy interface-centric and never wholy routing protocol-centric! Tom Petch > Andy > The well-specified XPath and YANG root (/) can be > accessed by all protocol operations, exactly the same > as a node called 'device'. The actual node name will > depend on the RPC function (e.g. 'data' or 'config'). > > This is more than redundant however. It introduces a "super-module" > into YANG that every other module is expected to augment. > YANG is intended to be more loosely coupled than that. > This introduces an extra node and namespace declaration > in all protocol messages, increasing message sizes. > > It also assumes all existing YANG models will get rewritten to > account for "/device" in all path and XPath expressions. > This is highly disruptive to existing deployments. > Also, multiple data models to edit the same thing causes lots > of extra complexity in the server (supporting both old > location and new location). > > IMO a resource directory approach is much more realistic. > The /device tree can contain all the organized NP containers. > Instead of all the actual data nodes, this tree just has pointers > to the real location of the resource. (like 301 Moved Permanently) > > Thanks, > > Acee > > > Andy From nobody Mon Aug 3 09:17:40 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43CDD1ACE22 for ; Mon, 3 Aug 2015 09:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_34=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 KbM2h2rPnki9 for ; Mon, 3 Aug 2015 09:17:35 -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 570771ABC10 for ; Mon, 3 Aug 2015 09:17:35 -0700 (PDT) Received: by labix3 with SMTP id ix3so3622673lab.0 for ; Mon, 03 Aug 2015 09:17:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=LsYWga+HmsY9uQldjHtZonD3FsmRETMKmp6yG+GPwTA=; b=SF2TqzvlqdmlLUO+YVKKDZMxRuHXQ+i6cbDr7ggyeo5hqvaQIVchTD1RKLEUqD/VpA 4yub8zhGwS4E9SkZX2RRpjVaVDOHtxAc61RNezr7KI60QLAx8AZSnGUWITIjVlMD2bYP 4kWNwS3qQumHu+JHiMeUQO4N9K6ANhrwbBKoqmgRFnE7ATfHTfXxOBYxLTVe0g5r7X+U s7Qaf8m9pyrUgsvA0YmuY8G81n51u4ufTbQn+KwwNPS/Pwb6UMDkQcy+4kT75zE1TAaB M1OtB1A1m7OEgaG6o71eu1OqbJfvhbxJKaysQLUgBOUQkyo48EbGqnKBn2HUXGCoJrAz Qv1A== X-Gm-Message-State: ALoCoQkyB3NkGjIjdHg9mQurKuBZJwM40T8+ycjQZr3aiwq1LxTNU8D6FecQZekNO4a8tdktbt52 MIME-Version: 1.0 X-Received: by 10.112.46.130 with SMTP id v2mr17449174lbm.119.1438618653797; Mon, 03 Aug 2015 09:17:33 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Mon, 3 Aug 2015 09:17:33 -0700 (PDT) In-Reply-To: <03d301d0ce05$c320a800$4001a8c0@gateway.2wire.net> References: <20150720210041.GA17614@elstar.local> <14ecceb6dd0.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <14ed0338068.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <55BBA679.7070508@labn.net> <20150801065150.GA67416@elstar.local> <002401d0cdfb$758b6760$4001a8c0@gateway.2wire.net> <03d301d0ce05$c320a800$4001a8c0@gateway.2wire.net> Date: Mon, 3 Aug 2015 09:17:33 -0700 Message-ID: From: Andy Bierman To: "t.petch" Content-Type: multipart/alternative; boundary=001a1134aee8d3c91c051c6a81f3 Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Y34 - root node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 16:17:38 -0000 --001a1134aee8d3c91c051c6a81f3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Aug 3, 2015 at 9:01 AM, t.petch wrote: > ----- Original Message ----- > From: "Andy Bierman" > To: "t.petch" > Cc: "NETMOD Working Group" > Sent: Monday, August 03, 2015 4:10 PM > > On Mon, Aug 3, 2015 at 7:48 AM, t.petch wrote: > > > ----- Original Message ----- > > From: "Andy Bierman" andy@yumaworks.com > > Sent: Saturday, August 01, 2015 7:05 PM > > On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem (acee) > > wrote: > > > > > Hi Juergen, > > > > > > On 8/1/15, 2:51 AM, j.schoenwaelder@jacobs-university.de> wrote: > > > > > > >On Fri, Jul 31, 2015 at 12:46:49PM -0400, Lou Berger wrote: > > > >> Andy, > > > >> > > > >> On 07/27/2015 12:58 PM, Andy Bierman wrote: > > > >> > Hi, > > > >> > > > > >> > I don't think a standard for relocating subtrees would be worth > > it. > > > >> > I am not in favor of moving /interfaces or /system to a new > > location. > > > >> > That's not how YANG works. It only allows "obsolete and start > > over". > > > >> > > > > >> > I would suggest pursuing solutions that don't cause > > > >> > as much disruption and expense as possible. > > > >> > > > > >> I think it would be really good to explore other, less > "disruptive" > > > >> options. > > > > > > > >I think the first step is to find out whether there is a problem > > worth > > > >to be fixed. Why are the RFCs in question broken? (Yes, I have read > > > >the openconfig IDs, > > > > > > Section 1.1 in > > > > https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt > > > lists the goals of a generic model structure that will accommodate > > most > > > modern network devices. I guess you don=E2=80=99t agree that these ar= e > > desirable? > > > > The only objection I have to this draft is the insertion of a > top-level > > root > > called "device". (Might as well be called "self"). > > There are no sibling nodes planned or intended for > > this node, so it serves as an extra document root. > > > > > > One aspect of YANG I have never grasped is what a root means, if > > anything. > > > > I understand that it is needed for NETCONF (filters) and for YANG > > (augments, constraints) and so must be somewhere and must be > relatively > > stable, but has it any other significance in the data model? > > > > As you may recall, I was involved with SMI first, where the root is > > somewhere up in the sky and life only becomes interesting some six > > levels down the hierarchy and that may colour my thinking. > > > > YANG does a poor job of defining the root for YANG data nodes. > It is sometimes called a datastore (in the abstract). > Technically, YANG borrows the definition from XPath. > YANG just defines top-level data nodes and the parent of > these nodes is the document root. > > There is no protocol or encoding neutral definition, > only an XML-specific definition. > > > > Thanks for that. > > It seems to me that much of the extensive discussion on Y34 (all of > which I have read) is as much political as technical, that is SMI is > hierarchical, top down, perhaps befitting its origins in ISO, whereas > YANG is bottom up. IETF-like. YANG could have had a single tree, but > doesn't. So when I read > > https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt > > I see a plea for a more hierarchical organisation, and when I read > > draft-bjorklund-netmod-openconfig-reply-00 > > I see a response that says we are not like that. > > If so, I doubt that there ever will be a technical solution. > > And I am mindful that when I configure routing in a (Cisco) router, I > have to do some of it under the interface definitions and some of it > under the definition of the routing protocol. Which is life, never > wholy interface-centric and never wholy routing protocol-centric! > > Are you saying the job would be easier if the path was /device/interfaces/interface instead of just /interfaces/interface? Are you saying that /protocols/routing could not also be defined? Clearly edit-config and copy-config allow both subtrees to be accessed in the same operation, so I don't understand your concern. I have been trying to get the root node to be better defined in the protocols that use YANG (i.e., ncx:root, Y34-04). IMO this is a better approach than defining a YANG module with a special container that all other modules are expected to augment. YANG is designed such that each vendor or SDO is not dependent on other vendors or SDOs in order to define data nodes. > Tom Petch > > > > Andy > Andy > > > The well-specified XPath and YANG root (/) can be > > accessed by all protocol operations, exactly the same > > as a node called 'device'. The actual node name will > > depend on the RPC function (e.g. 'data' or 'config'). > > > > This is more than redundant however. It introduces a "super-module" > > into YANG that every other module is expected to augment. > > YANG is intended to be more loosely coupled than that. > > This introduces an extra node and namespace declaration > > in all protocol messages, increasing message sizes. > > > > It also assumes all existing YANG models will get rewritten to > > account for "/device" in all path and XPath expressions. > > This is highly disruptive to existing deployments. > > Also, multiple data models to edit the same thing causes lots > > of extra complexity in the server (supporting both old > > location and new location). > > > > IMO a resource directory approach is much more realistic. > > The /device tree can contain all the organized NP containers. > > Instead of all the actual data nodes, this tree just has pointers > > to the real location of the resource. (like 301 Moved Permanently) > > > > Thanks, > > > Acee > > > > > Andy > > --001a1134aee8d3c91c051c6a81f3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Aug 3, 2015 at 9:01 AM, t.petch <ietfc@btconnect.com&g= t; wrote:
----- Original Message -= ----
From: "Andy Bierman" <an= dy@yumaworks.com>
To: "t.petch" <ietfc@bt= connect.com>
Cc: "NETMOD Working Group" <netmod@ietf.org>
Sent: Monday, August 03, 2015 4:10 PM

On Mon, Aug 3, 2015 at 7:48 AM, t.petch <ietfc@btconnect.com> wrote:

> ----- Original Message -----
> From: "Andy Bierman" a= ndy@yumaworks.com
> Sent: Saturday, August 01, 2015 7:05 PM
> On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem (acee) <acee@cisco.com>
> wrote:
>
> > Hi Juergen,
> >
> > On 8/1/15, 2:51 AM,=C2=A0 j.schoenwaelder@jacobs-university.de> wrote:
> >
> > >On Fri, Jul 31, 2015 at 12:46:49PM -0400, Lou Berger wrote: > > >> Andy,
> > >>
> > >> On 07/27/2015 12:58 PM, Andy Bierman wrote:
> > >> > Hi,
> > >> >
> > >> > I don't think a standard for relocating subtree= s would be worth
> it.
> > >> > I am not in favor of moving /interfaces or /system = to a new
> location.
> > >> > That's not how YANG works. It only allows "= ;obsolete and start
> over".
> > >> >
> > >> > I would suggest pursuing solutions that don't c= ause
> > >> > as much disruption and expense as possible.
> > >> >
> > >> I think it would be really good to explore other, less "disruptive"
> > >> options.
> > >
> > >I think the first step is to find out whether there is a prob= lem
> worth
> > >to be fixed. Why are the RFCs in question broken? (Yes, I hav= e read
> > >the openconfig IDs,
> >
> > Section 1.1 in
> >
https://www.ietf.org/id/draft-= openconfig-netmod-model-structure-00.txt
> > lists the goals of a generic model structure that will accommodat= e
> most
> > modern network devices. I guess you don=E2=80=99t agree that thes= e are
> desirable?
>
> The only objection I have to this draft is the insertion of a
top-level
> root
> called "device".=C2=A0 (Might as well be called "self&q= uot;).
> There are no sibling nodes planned or intended for
> this node, so it serves as an extra document root.
>
> <tp>
> One aspect of YANG I have never grasped is what a root means, if
> anything.
>
> I understand that it is needed for NETCONF (filters) and for YANG
> (augments, constraints) and so must be somewhere and must be
relatively
> stable, but has it any other significance in the data model?
>
> As you may recall, I was involved with SMI first, where the root is > somewhere up in the sky and life only becomes interesting some six
> levels down the hierarchy and that may colour my thinking.
>

YANG does a poor job of defining the root for YANG data nodes.
It is sometimes called a datastore (in the abstract).
Technically, YANG borrows the definition from XPath.
YANG just defines top-level data nodes and the parent of
these nodes is the document root.

There is no protocol or encoding neutral definition,
only an XML-specific definition.

<tp>

Thanks for that.

It seems to me that much of the extensive discussion on Y34 (all of
which I have read) is as much political as technical, that is SMI is
hierarchical, top down, perhaps befitting its origins in ISO, whereas
YANG is bottom up. IETF-like.=C2=A0 YANG could have had a single tree, but<= br> doesn't.=C2=A0 So when I read

https://www.ietf.org/id/draft-= openconfig-netmod-model-structure-00.txt

I see a plea for a more hierarchical organisation, and when I read

draft-bjorklund-netmod-openconfig-reply-00

I see a response that says we are not like that.

If so, I doubt that there ever will be a technical solution.

And I am mindful that when I configure routing in a (Cisco) router, I
have to do some of it under the interface definitions and some of it
under the definition of the routing protocol.=C2=A0 Which is life, never wholy interface-centric and never wholy routing protocol-centric!



Are you saying the job = would be easier if the
path was /device/interfaces/interface inst= ead
of just /interfaces/interface?=C2=A0 Are you saying
that /protocols/routing could not also be defined?
Clearly edit-= config and copy-config allow both
subtrees to be accessed in the = same operation,
so I don't understand your concern.

I have been trying to get the root node to be better define= d
in the protocols that use YANG (i.e., ncx:root, Y34-04).
<= div>IMO this is a better approach than defining a YANG module
wit= h a special container that all other modules are expected
to augm= ent.=C2=A0 YANG is designed such that each vendor or SDO
is not d= ependent on other vendors or SDOs in order to
define data nodes.<= /div>

=C2=A0
Tom Petch
>



Andy
=C2=A0
Andy

> The well-specified XPath and YANG root (/) can be
> accessed by all protocol operations, exactly the same
> as a node called 'device'.=C2=A0 The actual node name will
> depend on the RPC function (e.g. 'data' or 'config').<= br> >
> This is more than redundant however.=C2=A0 It introduces a "super= -module"
> into YANG that every other module is expected to augment.
> YANG is intended to be more loosely coupled than that.
> This introduces an extra node and namespace declaration
> in all protocol messages, increasing message sizes.
>
> It also assumes all existing YANG models will get rewritten to
> account for "/device" in all path and XPath expressions.
> This is highly disruptive to existing deployments.
> Also, multiple data models to edit the same thing causes lots
> of extra complexity in the server (supporting both old
> location and new location).
>
> IMO a resource directory approach is much more realistic.
> The /device tree can contain all the organized NP containers.
> Instead of all the actual data nodes, this tree just has pointers
> to the real location of the resource. (like 301 Moved Permanently)
>
> Thanks,
> > Acee
> >
> Andy


--001a1134aee8d3c91c051c6a81f3-- From nobody Mon Aug 3 11:58:45 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 459661A0053 for ; Mon, 3 Aug 2015 11:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.061 X-Spam-Level: X-Spam-Status: No, score=-5.061 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DbVh8nhxWowP for ; Mon, 3 Aug 2015 11:58:42 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF6AF1A004D for ; Mon, 3 Aug 2015 11:58:41 -0700 (PDT) Received: from [172.29.2.202] (nat-14.bravonet.cz [77.48.225.14]) by mail.nic.cz (Postfix) with ESMTPSA id 013C818148A; Mon, 3 Aug 2015 20:58:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1438628319; bh=p+ps6WldV6rM+8HBvbgKCZE6jpl+mLgWYEeSNlLXhlE=; h=From:Date:To; b=p/e1mUbMm1e+eYg2HuxNm8F5iQ8w+jUIRuKfrKg/DHQV+wzRfNJaRUikXUYnEPF79 UCE4TAa3jQUwjEOEwtzDf2gt40y2nosS9RMHpNuHCZ89j3m9osL303gKzCzdsGJpGL oH2ZI5/XPqHieOEuEpNhWuJ7AEnJGFkDHpzc8nek= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 3 Aug 2015 20:58:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150730.211629.1600508626921450694.mbj@tail-f.com> <1D650959-4AB3-4B74-8A30-7BE3A69B896D@nic.cz> <20150803081814.GA71323@elstar.local> <55BF2F21.1070900@mg-soft.si> <20150803092501.GB71565@elstar.local> <646276CA-ED9B-40D1-8613-4F0FD6DD69BE@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Jernej Tuljak , "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 18:58:44 -0000 > On 03 Aug 2015, at 18:01, Andy Bierman wrote: >=20 >=20 >=20 > On Mon, Aug 3, 2015 at 7:48 AM, Ladislav Lhotka wrote: >=20 > > On 03 Aug 2015, at 16:41, Andy Bierman wrote: > > > > > > > > On Mon, Aug 3, 2015 at 2:25 AM, Juergen Schoenwaelder = wrote: > > On Mon, Aug 03, 2015 at 11:06:41AM +0200, Jernej Tuljak wrote: > > > Juergen Schoenwaelder je 3.8.2015 ob 10:18 napisal: > > > >Any description statement in principle can do this. We trust that = sane > > > >data model writers won't do bad things. And if they do, we hope = that > > > >people will not implement and deploy bad things. > > > > > > Why not simply make this impossible by ensuring that description > > > statements cannot change what has already been agreed upon in = RFC6020 > > > (aka YANG semantics)? I would have no problem with descriptions = being > > > normative, if this would be the case. > > > > You need to define way more clearly what 'YANG semantics' means. > > > > > > > > Agreed. The description-stmt is normative. > > It defines implementation requirements for a data node. > > It is not used to override other YANG statements. > > However, if the description says "child foo must be > > greater than the value of bar" that is just as normative > > as a must-stmt that says the same thing. > > > > > > > >I continue to see extension statements as reusable and (in = principle) > > > >machine readable fragments of description statements. =46rom this > > > >perspective, it seems odd to make a difference between extensions = and > > > >description statements. > > > > > > I still disagree that description statements should be more = powerful > > > than any other YANG statement. > > > > What does 'powerful' mean? Time that someone writes concrete text so > > we can have a more constructive discussion. > > > > > > A YANG description-stmt cannot override the syntax and semantics of = other YANG > > statements. But is is mandatory and it is normative. >=20 > It=E2=80=99s not only about overriding. For example, it wouldn=E2=80=99t= be good to introduce a new data node type though an extension. >=20 >=20 > But isn't that exactly what you are proposing by making ephemeral data > an extension instead of part of YANG? It depends on how it would be defined and used. If it is an extension, = NETCONF/RESTCONF clients either shouldn=E2=80=99t see it at all, or they = should be able to ignore it. >=20 > None of the existing text covers the validation rules for ephemeral = data. > Nothing is needed for config=3Dtrue nodes in the ephemeral datastore, > but ephemeral-only data needs to be identified. I think it still has to be clarified how ephemeral data interact with = normal config data. Normal semantic validation of config=3Dtrue data = doesn=E2=80=99t make much sense to me if some parameters may be = overriden by ephemeral values.=20 Lada >=20 > Validation rules are needed for ephemeral data. > Whether this is part of a protocol spec or YANG needs to be decided. >=20 >=20 > =20 > Lada >=20 >=20 > Andy > =20 > > > > > > > > > > /js > > > > > > Andy > > > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany > > Fax: +49 421 200 3103 > > >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Aug 3 12:16:40 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC6E1B30AF for ; Mon, 3 Aug 2015 12:16:39 -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_64=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 erW8WD45Apud for ; Mon, 3 Aug 2015 12:16:36 -0700 (PDT) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66B371B30AE for ; Mon, 3 Aug 2015 12:16:36 -0700 (PDT) Received: by lbbud7 with SMTP id ud7so79211782lbb.3 for ; Mon, 03 Aug 2015 12:16:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=K/dDNpxfTgJmNTmcLjxrKjGwcnM/HnT+7dgQIShb9dI=; b=N5CCer16oPAm3qlxSr1hC67QZvbQU/pA+Dcf0JB8cHvzR3SZyxuZxW58o5IXbomNf2 G2S7AqO0OAGBNAZtDH8DabddFiQ/400ltLVe4sBx0iDd98lS1fFDBS2SsPjGvIm6zsqN 8g8tB9GALeZQE6baU5EzgywmdF80ePXCU9Ss/vFhBFv14XO+Yosmo38InX6y/y4MXqz8 mJihY3Q/Xzlra1J864BQAP/W5K/3C6hByXh25Jo8tRQpilil5/pFRPrQ7+RPdv6E+F17 ckAL5nVKwsbAZQyKJ6TaZwmT01WpaxD9TZf8i0ydJviaF0tzjsAc+zKQa80AXbG7peO/ HSxg== X-Gm-Message-State: ALoCoQmW9LgZbQpnlPRlKuN2n17sM9+MCIr5rN3lQUQw8pdMieNibSyLL2sfslmicioL0JLWswuj MIME-Version: 1.0 X-Received: by 10.112.64.172 with SMTP id p12mr13931216lbs.38.1438629394852; Mon, 03 Aug 2015 12:16:34 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Mon, 3 Aug 2015 12:16:34 -0700 (PDT) In-Reply-To: References: <20150730.211629.1600508626921450694.mbj@tail-f.com> <1D650959-4AB3-4B74-8A30-7BE3A69B896D@nic.cz> <20150803081814.GA71323@elstar.local> <55BF2F21.1070900@mg-soft.si> <20150803092501.GB71565@elstar.local> <646276CA-ED9B-40D1-8613-4F0FD6DD69BE@nic.cz> Date: Mon, 3 Aug 2015 12:16:34 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11349f100b46b8051c6d02e2 Archived-At: Cc: Jernej Tuljak , "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 19:16:39 -0000 --001a11349f100b46b8051c6d02e2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Aug 3, 2015 at 11:58 AM, Ladislav Lhotka wrote: > > > On 03 Aug 2015, at 18:01, Andy Bierman wrote: > > > > > > > > On Mon, Aug 3, 2015 at 7:48 AM, Ladislav Lhotka wrote: > > > > > On 03 Aug 2015, at 16:41, Andy Bierman wrote: > > > > > > > > > > > > On Mon, Aug 3, 2015 at 2:25 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > On Mon, Aug 03, 2015 at 11:06:41AM +0200, Jernej Tuljak wrote: > > > > Juergen Schoenwaelder je 3.8.2015 ob 10:18 napisal: > > > > >Any description statement in principle can do this. We trust that > sane > > > > >data model writers won't do bad things. And if they do, we hope th= at > > > > >people will not implement and deploy bad things. > > > > > > > > Why not simply make this impossible by ensuring that description > > > > statements cannot change what has already been agreed upon in RFC60= 20 > > > > (aka YANG semantics)? I would have no problem with descriptions bei= ng > > > > normative, if this would be the case. > > > > > > You need to define way more clearly what 'YANG semantics' means. > > > > > > > > > > > > Agreed. The description-stmt is normative. > > > It defines implementation requirements for a data node. > > > It is not used to override other YANG statements. > > > However, if the description says "child foo must be > > > greater than the value of bar" that is just as normative > > > as a must-stmt that says the same thing. > > > > > > > > > > >I continue to see extension statements as reusable and (in > principle) > > > > >machine readable fragments of description statements. From this > > > > >perspective, it seems odd to make a difference between extensions > and > > > > >description statements. > > > > > > > > I still disagree that description statements should be more powerfu= l > > > > than any other YANG statement. > > > > > > What does 'powerful' mean? Time that someone writes concrete text so > > > we can have a more constructive discussion. > > > > > > > > > A YANG description-stmt cannot override the syntax and semantics of > other YANG > > > statements. But is is mandatory and it is normative. > > > > It=E2=80=99s not only about overriding. For example, it wouldn=E2=80=99= t be good to > introduce a new data node type though an extension. > > > > > > But isn't that exactly what you are proposing by making ephemeral data > > an extension instead of part of YANG? > > It depends on how it would be defined and used. If it is an extension, > NETCONF/RESTCONF clients either shouldn=E2=80=99t see it at all, or they = should be > able to ignore it. > > > > > None of the existing text covers the validation rules for ephemeral dat= a. > > Nothing is needed for config=3Dtrue nodes in the ephemeral datastore, > > but ephemeral-only data needs to be identified. > > I think it still has to be clarified how ephemeral data interact with > normal config data. Normal semantic validation of config=3Dtrue data does= n=E2=80=99t > make much sense to me if some parameters may be overriden by ephemeral > values. > > I agree that suitable solutions have been discussed off-line, and the slides from Jeff do not specify how validation would work. This is part of the month of work left to do. IMO the running datastore and ephemeral datastore have different validation procedures: Running: config=3Dtrue validation same as now; no impact from ephemeral datastore validation done at edit-time Ephemeral: config=3Dtrue validation done with ephemeral data first, then running datastore if no matching ephemeral data (panes of glass) ; validation done at edit-time config=3Dephemeral validation done with ephemeral data and operational state; config=3Dtrue MUST NOT appear in any ephemeral data node constraint expressions.; validation done at edit-time; not clear if additional validation needed whenever any relevant operational state changes. (Implementation detail how quickly server checks?) Lada > > Andy > > > > Validation rules are needed for ephemeral data. > > Whether this is part of a protocol spec or YANG needs to be decided. > > > > > > > > Lada > > > > > > Andy > > > > > > > > > > > > > > > > > /js > > > > > > > > > Andy > > > > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | German= y > > > Fax: +49 421 200 3103 > > > > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > > > > > > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a11349f100b46b8051c6d02e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Aug 3, 2015 at 11:58 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:

> On 03 Aug 2015, at 18:01, Andy Bierman <andy@yumaworks.com> wrote:
>
>
>
> On Mon, Aug 3, 2015 at 7:48 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> > On 03 Aug 2015, at 16:41, Andy Bierman <andy@yumaworks.com> wrote:
> >
> >
> >
> > On Mon, Aug 3, 2015 at 2:25 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-uni= versity.de> wrote:
> > On Mon, Aug 03, 2015 at 11:06:41AM +0200, Jernej Tuljak wrote: > > > Juergen Schoenwaelder je 3.8.2015 ob 10:18 napisal:
> > > >Any description statement in principle can do this. We t= rust that sane
> > > >data model writers won't do bad things. And if they = do, we hope that
> > > >people will not implement and deploy bad things.
> > >
> > > Why not simply make this impossible by ensuring that descrip= tion
> > > statements cannot change what has already been agreed upon i= n RFC6020
> > > (aka YANG semantics)? I would have no problem with descripti= ons being
> > > normative, if this would be the case.
> >
> > You need to define way more clearly what 'YANG semantics'= means.
> >
> >
> >
> > Agreed.=C2=A0 The description-stmt is normative.
> > It defines implementation requirements for a data node.
> > It is not used to override other YANG statements.
> > However, if the description says "child foo must be
> > greater than the value of bar" that is just as normative
> > as a must-stmt that says the same thing.
> >
> >
> > > >I continue to see extension statements as reusable and (= in principle)
> > > >machine readable fragments of description statements. Fr= om this
> > > >perspective, it seems odd to make a difference between e= xtensions and
> > > >description statements.
> > >
> > > I still disagree that description statements should be more = powerful
> > > than any other YANG statement.
> >
> > What does 'powerful' mean? Time that someone writes concr= ete text so
> > we can have a more constructive discussion.
> >
> >
> > A YANG description-stmt cannot override the syntax and semantics = of other YANG
> > statements.=C2=A0 But is is mandatory and it is normative.
>
> It=E2=80=99s not only about overriding. For example, it wouldn=E2=80= =99t be good to introduce a new data node type though an extension.
>
>
> But isn't that exactly what you are proposing by making ephemeral = data
> an extension instead of part of YANG?

It depends on how it would be defined and used. If it is an extension, NETC= ONF/RESTCONF clients either shouldn=E2=80=99t see it at all, or they should= be able to ignore it.

>
> None of the existing text covers the validation rules for ephemeral da= ta.
> Nothing is needed for config=3Dtrue nodes in the ephemeral datastore,<= br> > but ephemeral-only data needs to be identified.

I think it still has to be clarified how ephemeral data interact with norma= l config data. Normal semantic validation of config=3Dtrue data doesn=E2=80= =99t make much sense to me if some parameters may be overriden by ephemeral= values.



I agree that suitable s= olutions have been discussed off-line,
and the slides from Jeff d= o not specify how validation would work.
This is part of the mont= h of work left to do.

IMO the running datastore an= d ephemeral datastore have different
validation procedures:
=

Running:
=C2=A0 =C2=A0config=3Dtrue validatio= n
=C2=A0 =C2=A0same as now; no impact from ephemeral datastore
=C2=A0 =C2=A0validation done at edit-time

= Ephemeral:
=C2=A0 config=3Dtrue validation done with ephemeral da= ta first,
=C2=A0 then running datastore if no matching ephemeral = data
=C2=A0 (panes of glass) ; validation done at edit-time
=

=C2=A0 config=3Dephemeral validation done with ephemera= l data
=C2=A0 and operational state; config=3Dtrue MUST NOT appea= r
=C2=A0 in any ephemeral data node constraint expressions.;
=C2=A0 validation done at edit-time; not clear if additional validati= on
=C2=A0 needed whenever any relevant operational state changes.=
=C2=A0(Implementation detail how quickly server checks?)



Lada



Andy
=C2=A0
>
> Validation rules are needed for ephemeral data.
> Whether this is part of a protocol spec or YANG needs to be decided. >
>
>
> Lada
>
>
> Andy
>
> >
> >
> >
> >
> > /js
> >
> >
> > Andy
> >
> >
> > --
> > Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jac= obs University Bremen gGmbH
> > Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus R= ing 1 | 28759 Bremen | Germany
> > Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<http://www.jacobs-university.de/>
> >
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>

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





--001a11349f100b46b8051c6d02e2-- From nobody Tue Aug 4 02:39:23 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA3E1B3766 for ; Tue, 4 Aug 2015 02:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, SPF_HELO_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 3Rbb1KfaXqNs for ; Tue, 4 Aug 2015 02:39:20 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0769.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::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 B1F671B3760 for ; Tue, 4 Aug 2015 02:39:18 -0700 (PDT) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.151.167.91) by AMXPR07MB053.eurprd07.prod.outlook.com (10.242.67.142) with Microsoft SMTP Server (TLS) id 15.1.225.19; Tue, 4 Aug 2015 09:38:57 +0000 Message-ID: <01e601d0ce98$df05e240$4001a8c0@gateway.2wire.net> From: t.petch To: Andy Bierman References: <20150720210041.GA17614@elstar.local><14ecceb6dd0.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net><14ed0338068.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net><55BBA679.7070508@labn.net><20150801065150.GA67416@elstar.local><002401d0cdfb$758b6760$4001a8c0@gateway.2wire.net><03d301d0ce05$c320a800$4001a8c0@gateway.2wire.net> Date: Tue, 4 Aug 2015 10:34:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.167.91] X-ClientProxiedBy: DB3PR05CA0047.eurprd05.prod.outlook.com (25.160.41.175) To AMXPR07MB053.eurprd07.prod.outlook.com (10.242.67.142) X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB053; 2:PtYRjUZdtt9NW2B4wNg7FinBqdEKUiNbsKxU1/XqswwQKE+YpcqSwty3D8ZKTH53P6IFPZTDyMIwB6Dh9C4dhYRpkKs1YEMOBz2oMxWVZp3OvtC0U+ZQjUArOdfDIVoq8pYeafdAfriM7DfE1yNb66HY5tpb+ByRGV8agJ/6tVU=; 3:btVGYblNTRyhTsBe9kdh+boTTQQo3I08pGNeTPkmbg+d25EGOdGvSraN2mSzYnJprwFmGhsicSMk8dftO5xVscSNM3AnsLApXr9INdQfx8auu+kvdcbWIJfNqLPyp1x3TnwDjgUrjMQAeOQae1czXA==; 25:nqd4PRWtMWqj5WaBnk/o5idTujIbEqSXeI9iBP8lAwVLwaNzyxBTXX4Q/7cpgesR8hCFvrVkMiL7Nza29MIXrFml3AMq5PT6cw3PtCLBUatGjBxWUaoHTV9OsqjI0jTzg0ppd0Wm9ezbRJ5Tg9evgJL2f8YPQqJZe2IPbNN2YDbA+2XJOLWb04YJptnvSUU6NhukfCO6O2WMs2zuVcJS/0uBUTeDDVB4kmHTzmiq+w7f3iClwIfxKFybxGAcre2sRqqZlGu/h4CvLEDM6RJ4tw==; 4:D7WnCR/4wkeEGVEs6ngWoNgeXjs4paA6hEhRl4qMYh3gEQeQw5vGA4WswnAkIHrtdQzdUaSLOLTdiY/Mt27PCVcJ9MQjzwFeFFr3Pp2KmOyRzcYTcZy9C7niRMze2LfvhGsLPRbUEazrQ1NMLmH6dk/V737QKR19trJLz0fTzZkoQ0RwMjEoh6jFZErKzj+ZINsHxM97mSoCA7ly1ANmE1kYaJl0ORxky8gvulGmhal+jstWtni5PtwuwTr1h3CmMQ63hBz3GYLTsx4NQT8n6ROtlvZ6qZ34uxSAgB2V84c= 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: 0658BAF71F X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(479174004)(377454003)(199003)(189002)(13464003)(62966003)(62236002)(5001960100002)(110136002)(116806002)(33646002)(50986999)(47776003)(1456003)(14496001)(105586002)(64706001)(101416001)(50226001)(68736005)(61296003)(77096005)(44736004)(23676002)(76176999)(15975445007)(77156002)(81686999)(4001540100001)(81156007)(5001860100001)(122386002)(50466002)(81816999)(97736004)(93886004)(5001830100001)(42186005)(1556002)(86362001)(106356001)(66066001)(87976001)(46102003)(84392001)(44716002)(19580395003)(40100003)(19580405001)(189998001)(92566002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB053; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTVhQUjA3TUIwNTM7MjM6YkFwRTh5blFjQTkrcUF5OW1UdFk3QTgwcUpS?= =?utf-8?B?a094d3Z6ZDJBUTRuUnBLakhaS082R2lHcnNreDNqV2R1VUt1azJCdlBOSnlz?= =?utf-8?B?cEdtVzI0L09sQnd5NW8rR1BCdDZwdld3SUJ0eVRnZGZoNkllOS9nRUVyL2FE?= =?utf-8?B?WERPeS8xNEtWcW8vOURlSVhxOTVaaExIekNOYzYrVGlpZVBramlZNUhSQzVY?= =?utf-8?B?L0UrZmtWQjYvQ1hHOWJDcFpIajFqb0lHbytERW5zTVRWTjNUenUwTmNwUmdW?= =?utf-8?B?SnBzSGFuMnVoS3JSc21waTN6MWZ3R0pXT2l5NndHekxvdXJ4OWtYc1U1dW9G?= =?utf-8?B?Y04yaVhSdzdjTnIwZitIckRVdkJSbGtPTFZqbHhYMlBFazNxbDdJcm9CUUpG?= =?utf-8?B?NWd2aWV2T0E2UXVOcDVPR3FPRWZJeVJYSHVOOTZsNlhBNTBZTnZjYnFZaFND?= =?utf-8?B?T1Y4ZTdrbXRtWmNmWnhiTHBMemk0alpZK0hWTUkyRkQzdWkxREdPOEd4Z085?= =?utf-8?B?OWx5UHNBam9mSmlYKzNsQ1VQL0tTcmNLb1dxakI0ZHhxdXNYUEhEVXBqTkxn?= =?utf-8?B?SlhZdzBqWkdpcFFmMDlLSC9WMlhWczVmc0w4SG9pTG5abjB4TWlxakFLUTlE?= =?utf-8?B?a3B2Szk3NE1sMThsK3pZN2UvQWVXNlhuRCt5WTN5OCsyZ0tmRDdxazBSTnd3?= =?utf-8?B?Wm5jVDdWY2phRzlFYUNpazBWcDhxSHMyMEFmUk80cE13RkVvUG42d3FOWGww?= =?utf-8?B?cTN1M2JzaDVWNFpIN3h3L2RYSFBONWdobHRWeGcyblJpNXlMTi9lS2NtVTVD?= =?utf-8?B?TiswYmY1eFdIWDh3elpNNTJ6bVlGYTJKek5JZTVXZjI3R0l1S1RSZWRoMThj?= =?utf-8?B?UTRNU010ZksxRzZMU2IxY0tLMVZMR2pMRm5EWldRSjNzV2h5QkFmNk9uRVJ4?= =?utf-8?B?Y2FBZEg3RXRTeW01SFhwQ0JCY1JZYlphVEY2ckRwZjdtQ0E0VlFyUU9uaTdQ?= =?utf-8?B?aUl2U2k5djdCRjZQMkd3VnFESlRLVC9pa1UzRjcwRGFJaE9oTlpPa3pnT2p6?= =?utf-8?B?aEZNV0UwVVN0dnREOWErVmc4akFnVm81cGZkMEVXdFpWbzNzbHpabHRhMWYx?= =?utf-8?B?TC9aNVFoOHFKaGZNMnFZL2NaY2NEb0hSSzNEUmQ1M1hyTURxOFdzNTNCWjhL?= =?utf-8?B?T2ZYaVRTQmJldXRBV1JkVGJkTGJLZnJNVmVDcWVvaU93amtDOTlSdFREbkVo?= =?utf-8?B?SjV2V2dMZitQL1pkQmk0d2syTlRQSXJ6aHVrSTMxdnNhbEVHWk9SOHcxV3dh?= =?utf-8?B?TFVFMWtHLzE3ZE1SU0pucG9TcFZPM1lTeVhnVi9peWJ1VmVtTHIzb2g5YUhk?= =?utf-8?B?Mm1ZV2VQK3JBZzVRUVh5S3BMUjlKaEJxRkZRVHJmaERxVkVzSHRYVmJoRDFU?= =?utf-8?B?enZQT3pzT0UxZjVhV0g1UzVWMEFEWlR2YzJ5QmM0MllkTWxIcURITE9EVHFF?= =?utf-8?B?Yy9xcm5DRjlVTW5RSUtpaUgzT1pTQ3pmVmtSbXlkcGw4VmZya28wU0tjRWMw?= =?utf-8?B?eDhsaElaTHVuSUxqT2FmMEFRT1BLWldoc0g2ODZUaXZuNUVlb3gzMDM1OWhL?= =?utf-8?B?N1BVV1VuRXJDOFFwaDVTc1RDMjlCdTBmeVJ3eGx6TDZkV0NFTW9naEJNTm44?= =?utf-8?B?dUh0ZUlLUytTRU4vVUtVSEVHajZNWjl5dTNNSFNjN0NJbHRRcXFUSkFvbyt0?= =?utf-8?B?amhqc3A4M2pKLyszdEtTbXU0VkpDbmRQZlB6NDR6OU0zaTFTQi92cVl6VXlk?= =?utf-8?B?MysrUWgwZjlSMEFtS3VHckdkaWhnNlBjYTdQV3RMTEZ1Q0dMZCtnQmNXam4z?= =?utf-8?Q?Cd8Jy8sm1U=3D?= X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB053; 5:bcLJJu23EA7SUC8YE6aSfghgVWtEI/9T2KlJ/8DluaTlrU3Bl+32i56Fv3HAfHUMkpMHltWtotwp4OinQU3N1bONmFNVTnS3a9ROSXvz5dSMjW7uuzEhCVp14CcMWi/EYDLCR4yMaKk1q2kr2+8FIQ==; 24:Ou/yDmMl8kMBFXsLmqdkfuVnIwNnZPXgmVhgmDbAG3qEK2oou9XJ/pti1s8KhZ9FZpkLwFloUrqEJzbg2cPdZPciWdvgvJdZzmn+2wl84cs=; 20:E5MpAepQwVrnWd/dUw8gNpR2ReRd3bjr100zna9nfNZd/Fg/LNKv5/93QZdlY+LW+SU0gx/NrqiFn9l9ULgXPA== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Aug 2015 09:38:57.6712 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB053 Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Y34 - root node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 09:39:22 -0000 ----- Original Message ----- From: "Andy Bierman" To: "t.petch" Sent: Monday, August 03, 2015 5:17 PM > ----- Original Message ----- > From: "Andy Bierman" > To: "t.petch" > Sent: Monday, August 03, 2015 4:10 PM > > > ----- Original Message ----- > > From: "Andy Bierman" andy@yumaworks.com > > Sent: Saturday, August 01, 2015 7:05 PM > > On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem (acee) > > >>> On 8/1/15, 2:51 AM, j.schoenwaelder@jacobs-university.de> wrote: >>> >>> Section 1.1 in >>> > https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt >>> lists the goals of a generic model structure that will accommodate >> most >>> modern network devices. I guess you don’t agree that these are >> desirable? > > > > The only objection I have to this draft is the insertion of a top-level > > root > > called "device". (Might as well be called "self"). > > There are no sibling nodes planned or intended for > > this node, so it serves as an extra document root. > > > > > > One aspect of YANG I have never grasped is what a root means, if > > anything. > > > > I understand that it is needed for NETCONF (filters) and for YANG > > (augments, constraints) and so must be somewhere and must be > relatively > > stable, but has it any other significance in the data model? > > > > As you may recall, I was involved with SMI first, where the root is > > somewhere up in the sky and life only becomes interesting some six > > levels down the hierarchy and that may colour my thinking. > > > > YANG does a poor job of defining the root for YANG data nodes. > It is sometimes called a datastore (in the abstract). > Technically, YANG borrows the definition from XPath. > YANG just defines top-level data nodes and the parent of > these nodes is the document root. > > There is no protocol or encoding neutral definition, > only an XML-specific definition. > > > > Thanks for that. > > It seems to me that much of the extensive discussion on Y34 (all of > which I have read) is as much political as technical, that is SMI is > hierarchical, top down, perhaps befitting its origins in ISO, whereas > YANG is bottom up. IETF-like. YANG could have had a single tree, but > doesn't. So when I read > > https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt > > I see a plea for a more hierarchical organisation, and when I read > > draft-bjorklund-netmod-openconfig-reply-00 > > I see a response that says we are not like that. > > If so, I doubt that there ever will be a technical solution. > > And I am mindful that when I configure routing in a (Cisco) router, I > have to do some of it under the interface definitions and some of it > under the definition of the routing protocol. Which is life, never > wholy interface-centric and never wholy routing protocol-centric! Are you saying the job would be easier if the path was /device/interfaces/interface instead of just /interfaces/interface? Are you saying that /protocols/routing could not also be defined? Clearly edit-config and copy-config allow both subtrees to be accessed in the same operation, so I don't understand your concern. I have been trying to get the root node to be better defined in the protocols that use YANG (i.e., ncx:root, Y34-04). IMO this is a better approach than defining a YANG module with a special container that all other modules are expected to augment. YANG is designed such that each vendor or SDO is not dependent on other vendors or SDOs in order to define data nodes. Andy I am agreeing with you that adding 'device' brings no technical benefit, rather that the motivation is the opposite of technical (which I referred to as political). I am also agreeing with the current declared consensus on Y34. And yes, YANG is going to give us a large number of modules, some tightly coupled (augments) some loosely so (how many do you need to configure OSPF?) and work in this area will be of benefit now and probably essential in a few years time. That said, I am unsure what such work would be like; I am looking (in despair) at 50 routing area YANG models and wondering how a user will ever get a coherent picture of how to do what they want to do. Tom Petch Andy > Andy > > > The well-specified XPath and YANG root (/) can be > > accessed by all protocol operations, exactly the same > > as a node called 'device'. The actual node name will > > depend on the RPC function (e.g. 'data' or 'config'). > > > > This is more than redundant however. It introduces a "super-module" > > into YANG that every other module is expected to augment. > > YANG is intended to be more loosely coupled than that. > > This introduces an extra node and namespace declaration > > in all protocol messages, increasing message sizes. > > > > It also assumes all existing YANG models will get rewritten to > > account for "/device" in all path and XPath expressions. > > This is highly disruptive to existing deployments. > > Also, multiple data models to edit the same thing causes lots > > of extra complexity in the server (supporting both old > > location and new location). > > > > IMO a resource directory approach is much more realistic. > > The /device tree can contain all the organized NP containers. > > Instead of all the actual data nodes, this tree just has pointers > > to the real location of the resource. (like 301 Moved Permanently) > > > > > Acee > > > > > Andy ** Solution Y34-02 Keep 'anyxml'. Introduce 'anydata' as above but without the 'format' substatement. 'anyxml' would still be used to represent unrestricted XML, as is done in NETCONF. 'anydata' would be an unknown chunk of data that can be modelled with YANG. Can be encoded as xml or json. For example: #+BEGIN_EXAMPLE anydata data; #+END_EXAMPLE ** Solution Y34-05 Same as Y34-02 plus two guidelines adopted from Y34-04: - Keep 'anyxml' unchanged as it is defined in YANG 1.0. This ensures backward compatibility. - Introduce a new 'anydata' statement that represents an unknown chunk of data that can be modeled with YANG - Document that implementations MAY have restrictions for anyxml and that anyxml is not necessarily interoperable; data model writers should use anydata whenever possible. - The guidelines document should say that YANG Doctors will review each use of anyxml in IETF modules when YANG 1.1 is adopted to avoid its use whenever possible. > From nobody Tue Aug 4 09:17:06 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15DFA1A8033 for ; Tue, 4 Aug 2015 09:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_34=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 TbisBYyUhx8k for ; Tue, 4 Aug 2015 09:17:03 -0700 (PDT) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52E661A872C for ; Tue, 4 Aug 2015 09:16:26 -0700 (PDT) Received: by labsr2 with SMTP id sr2so10807557lab.2 for ; Tue, 04 Aug 2015 09:16: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=EXeEw8REEjG5t4Qll1ZSJwDo76HcN16pSeN4PAuBHgw=; b=UETPlFsVJb7gxEJ+5zGV7Zm0YbRsSyAdLPQk/FQ0hkMKK9bTSPxbPj+4+XooTBT3t9 ATlzt5tvByhGvtTzOzUW9e48XJDxxHRE0D7tgLXYT5IitfhvfaLSboZ8XgG33A8424Rz XUgi+W0RJBP/Lx//oW4RJpBlcC1ch2kUOoRWfA2k/8x29q2wsQFRiH6aV7xJ6lQ1lf5S q1oaqE18Md/rNCK1SrkDnP5jozuKXSbfGYd+BQEcRkYreWQ5pMUvE3UeabwDk4fBOkJh oDWnErfAUcNUqwyq6vNgu0Fpd/Qhgo9vFIZenxfc8XxTm/nNVS9NMPX7XNjhoQMw0p0y rWCw== X-Gm-Message-State: ALoCoQl8KDGNbLcSV7btFv7YbCYY/rwe2FD3Qbb6HR/BsMmEHv4e4VX4IUiXizSbxVdVCbtLwjQy MIME-Version: 1.0 X-Received: by 10.112.85.3 with SMTP id d3mr4444369lbz.33.1438704984673; Tue, 04 Aug 2015 09:16:24 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Tue, 4 Aug 2015 09:16:24 -0700 (PDT) In-Reply-To: <01e601d0ce98$df05e240$4001a8c0@gateway.2wire.net> References: <20150720210041.GA17614@elstar.local> <14ecceb6dd0.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <14ed0338068.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <55BBA679.7070508@labn.net> <20150801065150.GA67416@elstar.local> <002401d0cdfb$758b6760$4001a8c0@gateway.2wire.net> <03d301d0ce05$c320a800$4001a8c0@gateway.2wire.net> <01e601d0ce98$df05e240$4001a8c0@gateway.2wire.net> Date: Tue, 4 Aug 2015 09:16:24 -0700 Message-ID: From: Andy Bierman To: "t.petch" Content-Type: multipart/alternative; boundary=001a1134946c8c8be0051c7e9b5d Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Y34 - root node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 16:17:06 -0000 --001a1134946c8c8be0051c7e9b5d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Aug 4, 2015 at 2:34 AM, t.petch wrote: > ----- Original Message ----- > From: "Andy Bierman" > To: "t.petch" > Sent: Monday, August 03, 2015 5:17 PM > > > ----- Original Message ----- > > From: "Andy Bierman" > > To: "t.petch" > > Sent: Monday, August 03, 2015 4:10 PM > > > > > ----- Original Message ----- > > > From: "Andy Bierman" andy@yumaworks.com > > > Sent: Saturday, August 01, 2015 7:05 PM > > > On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem (acee) > > > > >>> On 8/1/15, 2:51 AM, j.schoenwaelder@jacobs-university.de> wrote: > >>> > >>> Section 1.1 in > >>> > > https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt > >>> lists the goals of a generic model structure that will accommodate > >> most > >>> modern network devices. I guess you don=E2=80=99t agree that these ar= e > >> desirable? > > > > > > The only objection I have to this draft is the insertion of a > top-level > > > root > > > called "device". (Might as well be called "self"). > > > There are no sibling nodes planned or intended for > > > this node, so it serves as an extra document root. > > > > > > > > > One aspect of YANG I have never grasped is what a root means, if > > > anything. > > > > > > I understand that it is needed for NETCONF (filters) and for YANG > > > (augments, constraints) and so must be somewhere and must be > > relatively > > > stable, but has it any other significance in the data model? > > > > > > As you may recall, I was involved with SMI first, where the root is > > > somewhere up in the sky and life only becomes interesting some six > > > levels down the hierarchy and that may colour my thinking. > > > > > > > YANG does a poor job of defining the root for YANG data nodes. > > It is sometimes called a datastore (in the abstract). > > Technically, YANG borrows the definition from XPath. > > YANG just defines top-level data nodes and the parent of > > these nodes is the document root. > > > > There is no protocol or encoding neutral definition, > > only an XML-specific definition. > > > > > > > > Thanks for that. > > > > It seems to me that much of the extensive discussion on Y34 (all of > > which I have read) is as much political as technical, that is SMI is > > hierarchical, top down, perhaps befitting its origins in ISO, whereas > > YANG is bottom up. IETF-like. YANG could have had a single tree, but > > doesn't. So when I read > > > > https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt > > > > I see a plea for a more hierarchical organisation, and when I read > > > > draft-bjorklund-netmod-openconfig-reply-00 > > > > I see a response that says we are not like that. > > > > If so, I doubt that there ever will be a technical solution. > > > > And I am mindful that when I configure routing in a (Cisco) router, I > > have to do some of it under the interface definitions and some of it > > under the definition of the routing protocol. Which is life, never > > wholy interface-centric and never wholy routing protocol-centric! > > Are you saying the job would be easier if the > path was /device/interfaces/interface instead > of just /interfaces/interface? Are you saying > that /protocols/routing could not also be defined? > Clearly edit-config and copy-config allow both > subtrees to be accessed in the same operation, > so I don't understand your concern. > > I have been trying to get the root node to be better defined > in the protocols that use YANG (i.e., ncx:root, Y34-04). > IMO this is a better approach than defining a YANG module > with a special container that all other modules are expected > to augment. YANG is designed such that each vendor or SDO > is not dependent on other vendors or SDOs in order to > define data nodes. > > > > Andy > > I am agreeing with you that adding 'device' brings no technical benefit, > rather that the motivation is the opposite of technical (which I > referred to as political). I am also agreeing with the current declared > consensus on Y34. > > And yes, YANG is going to give us a large number of modules, some > tightly coupled (augments) some loosely so (how many do you need to > configure OSPF?) and work in this area will be of benefit now and > probably essential in a few years time. That said, I am unsure what > such work would be like; I am looking (in despair) at 50 routing area > YANG models and wondering how a user will ever get a coherent picture of > how to do what they want to do. > > The "YANG Land Grab" gives a false sense of progress. Reaching WG consensus on every single leaf is hard work. I don't think a collection of 100s of YANG modules is ever going to to be easy to understand. Operators will not examine a NETCONF message, look at 150 module URIs, and say "I know exactly what this device supports". I guess it is up to client tools to do that. I wrote a draft that defines YANG Packages, which can provide a higher level of organization for YANG modules. http://datatracker.ietf.org/doc/draft-bierman-netmod-yang-package/ You and I are apparently in the minority, since the official status is that there is no problem with the current approach, and no need to organize individual YANG modules into any larger abstractions. Tom Petch > > Andy > Andy > > > Andy > > > > > The well-specified XPath and YANG root (/) can be > > > accessed by all protocol operations, exactly the same > > > as a node called 'device'. The actual node name will > > > depend on the RPC function (e.g. 'data' or 'config'). > > > > > > This is more than redundant however. It introduces a "super-module" > > > into YANG that every other module is expected to augment. > > > YANG is intended to be more loosely coupled than that. > > > This introduces an extra node and namespace declaration > > > in all protocol messages, increasing message sizes. > > > > > > It also assumes all existing YANG models will get rewritten to > > > account for "/device" in all path and XPath expressions. > > > This is highly disruptive to existing deployments. > > > Also, multiple data models to edit the same thing causes lots > > > of extra complexity in the server (supporting both old > > > location and new location). > > > > > > IMO a resource directory approach is much more realistic. > > > The /device tree can contain all the organized NP containers. > > > Instead of all the actual data nodes, this tree just has pointers > > > to the real location of the resource. (like 301 Moved Permanently) > > > > > > > Acee > > > > > > > Andy > > > ** Solution Y34-02 > > Keep 'anyxml'. Introduce 'anydata' as above but without the > 'format' substatement. > > 'anyxml' would still be used to represent unrestricted XML, as is > done in NETCONF. > > 'anydata' would be an unknown chunk of data that can be modelled > with YANG. Can be encoded as xml or json. > > For example: > > #+BEGIN_EXAMPLE > anydata data; > #+END_EXAMPLE > > ** Solution Y34-05 > > Same as Y34-02 plus two guidelines adopted from Y34-04: > > - Keep 'anyxml' unchanged as it is defined in YANG 1.0. This > ensures backward compatibility. > - Introduce a new 'anydata' statement that represents an unknown > chunk of data that can be modeled with YANG > - Document that implementations MAY have restrictions for anyxml and > that anyxml is not necessarily interoperable; data model writers > should use anydata whenever possible. > - The guidelines document should say that YANG Doctors will review > each use of anyxml in IETF modules when YANG 1.1 is adopted to > avoid its use whenever possible. > > > > > > --001a1134946c8c8be0051c7e9b5d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Aug 4, 2015 at 2:34 AM, t.petch <ietfc@btconnect.com&g= t; wrote:
----- Original Message -= ----
From: "Andy Bierman" <an= dy@yumaworks.com>
To: "t.petch" <ietfc@bt= connect.com>
Sent: Monday, August 03, 2015 5:17 PM

> ----- Original Message -----
> From: "Andy Bierman" <andy@yumaworks.com>
> To: "t.petch" <iet= fc@btconnect.com>
> Sent: Monday, August 03, 2015 4:10 PM
>
> > ----- Original Message -----
> > From: "Andy Bierman" andy@yumaworks.com
> > Sent: Saturday, August 01, 2015 7:05 PM
> > On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem (acee) <acee@cisco.com>
> >
>>> On 8/1/15, 2:51 AM,=C2=A0 j.schoenwaelder@jacobs-university.de> wrote:
>>>
>>> Section 1.1 in
>>>
> https://www.ietf.org/id/d= raft-openconfig-netmod-model-structure-00.txt
>>> lists the goals of a generic model structure that will accommo= date
>> most
>>> modern network devices. I guess you don=E2=80=99t agree that t= hese are
>> desirable?
> >
> > The only objection I have to this draft is the insertion of a
top-level
> > root
> > called "device".=C2=A0 (Might as well be called "s= elf").
> > There are no sibling nodes planned or intended for
> > this node, so it serves as an extra document root.
> >
> > <tp>
> > One aspect of YANG I have never grasped is what a root means, if<= br> > > anything.
> >
> > I understand that it is needed for NETCONF (filters) and for YANG=
> > (augments, constraints) and so must be somewhere and must be
> relatively
> > stable, but has it any other significance in the data model?
> >
> > As you may recall, I was involved with SMI first, where the root = is
> > somewhere up in the sky and life only becomes interesting some si= x
> > levels down the hierarchy and that may colour my thinking.
> >
>
> YANG does a poor job of defining the root for YANG data nodes.
> It is sometimes called a datastore (in the abstract).
> Technically, YANG borrows the definition from XPath.
> YANG just defines top-level data nodes and the parent of
> these nodes is the document root.
>
> There is no protocol or encoding neutral definition,
> only an XML-specific definition.
>
> <tp>
>
> Thanks for that.
>
> It seems to me that much of the extensive discussion on Y34 (all of > which I have read) is as much political as technical, that is SMI is > hierarchical, top down, perhaps befitting its origins in ISO, whereas<= br> > YANG is bottom up. IETF-like.=C2=A0 YANG could have had a single tree,= but
> doesn't.=C2=A0 So when I read
>
> https://www.ietf.org/id/d= raft-openconfig-netmod-model-structure-00.txt
>
> I see a plea for a more hierarchical organisation, and when I read
>
> draft-bjorklund-netmod-openconfig-reply-00
>
> I see a response that says we are not like that.
>
> If so, I doubt that there ever will be a technical solution.
>
> And I am mindful that when I configure routing in a (Cisco) router, I<= br> > have to do some of it under the interface definitions and some of it > under the definition of the routing protocol.=C2=A0 Which is life, nev= er
> wholy interface-centric and never wholy routing protocol-centric!

Are you saying the job would be easier if the
path was /device/interfaces/interface instead
of just /interfaces/interface?=C2=A0 Are you saying
that /protocols/routing could not also be defined?
Clearly edit-config and copy-config allow both
subtrees to be accessed in the same operation,
so I don't understand your concern.

I have been trying to get the root node to be better defined
in the protocols that use YANG (i.e., ncx:root, Y34-04).
IMO this is a better approach than defining a YANG module
with a special container that all other modules are expected
to augment.=C2=A0 YANG is designed such that each vendor or SDO
is not dependent on other vendors or SDOs in order to
define data nodes.

<tp>

Andy

I am agreeing with you that adding 'device' brings no technical ben= efit,
rather that the motivation is the opposite of technical (which I
referred to as political). I am also agreeing with the current declared
consensus on Y34.

And yes, YANG is going to give us a large number of modules, some
tightly coupled (augments) some loosely so (how many do you need to
configure OSPF?) and work in this area will be of benefit now and
probably essential in a few years time.=C2=A0 That said, I am unsure what such work would be like; I am looking (in despair) at 50 routing area
YANG models and wondering how a user will ever get a coherent picture of how to do what they want to do.



The "YANG Land Gra= b" gives a false sense of progress.
Reaching WG consensus on= every single leaf is hard work.

I don't think= a collection of 100s of YANG modules is ever
going to to be = easy to understand.=C2=A0 Operators will not examine
a NETCONF &l= t;hello> message, look at 150 module URIs,
and say "I kno= w exactly what this device supports".
I guess it is up to cl= ient tools to do that.

I wrote a draft that define= s YANG Packages, which can provide
a higher level of organization= for YANG modules.


Yo= u and I are apparently in the minority, since the official status
is that there is no problem with the current approach, and no need
to organize individual YANG modules into any larger abstractions.
<= div>


=C2=A0Tom Petch



Andy
=C2=A0
Andy

> Andy
>
> > The well-specified XPath and YANG root (/) can be
> > accessed by all protocol operations, exactly the same
> > as a node called 'device'.=C2=A0 The actual node name wil= l
> > depend on the RPC function (e.g. 'data' or 'config= 9;).
> >
> > This is more than redundant however.=C2=A0 It introduces a "= super-module"
> > into YANG that every other module is expected to augment.
> > YANG is intended to be more loosely coupled than that.
> > This introduces an extra node and namespace declaration
> > in all protocol messages, increasing message sizes.
> >
> > It also assumes all existing YANG models will get rewritten to > > account for "/device" in all path and XPath expressions= .
> > This is highly disruptive to existing deployments.
> > Also, multiple data models to edit the same thing causes lots
> > of extra complexity in the server (supporting both old
> > location and new location).
> >
> > IMO a resource directory approach is much more realistic.
> > The /device tree can contain all the organized NP containers.
> > Instead of all the actual data nodes, this tree just has pointers=
> > to the real location of the resource. (like 301 Moved Permanently= )
> >
> > > Acee
> > >
> > Andy


** Solution Y34-02

=C2=A0 Keep 'anyxml'.=C2=A0 Introduce 'anydata' as above bu= t without the
=C2=A0 'format' substatement.

=C2=A0 'anyxml' would still be used to represent unrestricted XML, = as is
=C2=A0 done in NETCONF.

=C2=A0 'anydata' would be an unknown chunk of data that can be mode= lled
=C2=A0 with YANG.=C2=A0 Can be encoded as xml or json.

=C2=A0 For example:

=C2=A0 =C2=A0 #+BEGIN_EXAMPLE
=C2=A0 =C2=A0 anydata data;
=C2=A0 =C2=A0 #+END_EXAMPLE

** Solution Y34-05

=C2=A0 =C2=A0Same as Y34-02 plus two guidelines adopted from Y34-04:

=C2=A0 =C2=A0- Keep 'anyxml' unchanged as it is defined in YANG 1.0= . This
=C2=A0 =C2=A0 =C2=A0ensures backward compatibility.
=C2=A0 =C2=A0- Introduce a new 'anydata' statement that represents = an unknown
=C2=A0 =C2=A0 =C2=A0chunk of data that can be modeled with YANG
=C2=A0 =C2=A0- Document that implementations MAY have restrictions for anyx= ml and
=C2=A0 =C2=A0 =C2=A0that anyxml is not necessarily interoperable; data mode= l writers
=C2=A0 =C2=A0 =C2=A0should use anydata whenever possible.
=C2=A0 =C2=A0- The guidelines document should say that YANG Doctors will re= view
=C2=A0 =C2=A0 =C2=A0each use of anyxml in IETF modules when YANG 1.1 is ado= pted to
=C2=A0 =C2=A0 =C2=A0avoid its use whenever possible.


>


--001a1134946c8c8be0051c7e9b5d-- From nobody Thu Aug 6 00:43:33 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A98901ACE98 for ; Thu, 6 Aug 2015 00:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 498ME4p76eg2 for ; Thu, 6 Aug 2015 00:43:29 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5170D1ACE8A for ; Thu, 6 Aug 2015 00:43:28 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 8A0761CC0047; Thu, 6 Aug 2015 09:43:29 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: References: <20150730.211629.1600508626921450694.mbj@tail-f.com> <1D650959-4AB3-4B74-8A30-7BE3A69B896D@nic.cz> <20150803081814.GA71323@elstar.local> <55BF2F21.1070900@mg-soft.si> <20150803092501.GB71565@elstar.local> <646276CA-ED9B-40D1-8613-4F0FD6DD69BE@nic.cz> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Thu, 06 Aug 2015 09:43:26 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Jernej Tuljak , "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 07:43:31 -0000 Andy Bierman writes: > On Mon, Aug 3, 2015 at 11:58 AM, Ladislav Lhotka wrote: > >> >> > On 03 Aug 2015, at 18:01, Andy Bierman wrote: >> > >> > >> > >> > On Mon, Aug 3, 2015 at 7:48 AM, Ladislav Lhotka wrote: >> > >> > > On 03 Aug 2015, at 16:41, Andy Bierman wrote: >> > > >> > > >> > > >> > > On Mon, Aug 3, 2015 at 2:25 AM, Juergen Schoenwaelder < >> j.schoenwaelder@jacobs-university.de> wrote: >> > > On Mon, Aug 03, 2015 at 11:06:41AM +0200, Jernej Tuljak wrote: >> > > > Juergen Schoenwaelder je 3.8.2015 ob 10:18 napisal: >> > > > >Any description statement in principle can do this. We trust that >> sane >> > > > >data model writers won't do bad things. And if they do, we hope t= hat >> > > > >people will not implement and deploy bad things. >> > > > >> > > > Why not simply make this impossible by ensuring that description >> > > > statements cannot change what has already been agreed upon in RFC6= 020 >> > > > (aka YANG semantics)? I would have no problem with descriptions be= ing >> > > > normative, if this would be the case. >> > > >> > > You need to define way more clearly what 'YANG semantics' means. >> > > >> > > >> > > >> > > Agreed. The description-stmt is normative. >> > > It defines implementation requirements for a data node. >> > > It is not used to override other YANG statements. >> > > However, if the description says "child foo must be >> > > greater than the value of bar" that is just as normative >> > > as a must-stmt that says the same thing. >> > > >> > > >> > > > >I continue to see extension statements as reusable and (in >> principle) >> > > > >machine readable fragments of description statements. From this >> > > > >perspective, it seems odd to make a difference between extensions >> and >> > > > >description statements. >> > > > >> > > > I still disagree that description statements should be more powerf= ul >> > > > than any other YANG statement. >> > > >> > > What does 'powerful' mean? Time that someone writes concrete text so >> > > we can have a more constructive discussion. >> > > >> > > >> > > A YANG description-stmt cannot override the syntax and semantics of >> other YANG >> > > statements. But is is mandatory and it is normative. >> > >> > It=E2=80=99s not only about overriding. For example, it wouldn=E2=80= =99t be good to >> introduce a new data node type though an extension. >> > >> > >> > But isn't that exactly what you are proposing by making ephemeral data >> > an extension instead of part of YANG? >> >> It depends on how it would be defined and used. If it is an extension, >> NETCONF/RESTCONF clients either shouldn=E2=80=99t see it at all, or they= should be >> able to ignore it. >> >> > >> > None of the existing text covers the validation rules for ephemeral da= ta. >> > Nothing is needed for config=3Dtrue nodes in the ephemeral datastore, >> > but ephemeral-only data needs to be identified. >> >> I think it still has to be clarified how ephemeral data interact with >> normal config data. Normal semantic validation of config=3Dtrue data doe= sn=E2=80=99t >> make much sense to me if some parameters may be overriden by ephemeral >> values. >> >> > > I agree that suitable solutions have been discussed off-line, > and the slides from Jeff do not specify how validation would work. > This is part of the month of work left to do. > > IMO the running datastore and ephemeral datastore have different > validation procedures: > > Running: > config=3Dtrue validation > same as now; no impact from ephemeral datastore > validation done at edit-time I think there has to be an impact - validation of running has to take into account ephemeral values as long as they are what's operationally used. For example, take IPv6 RA parameters valid-lifetime and preferred-lifetime as defined in ietf-ipv6-unicast-routing. A must constraint is there to ensure that preferred-lifetime <=3D valid-lifetime Now, assume their values in running are p and v, respectively, but an I2RS client sets an ephemeral value of valid-lifetime to v' where v' < v If a NETCONF client changes value of preferred-lifetime to p' where v' < p' <=3D v then the constraint in running is satisfied but the values p' and v' appearing in RA Prefix Information sent by the device violate RFC=C2=A04861. How is this supposed to be resolved? Lada > > Ephemeral: > config=3Dtrue validation done with ephemeral data first, > then running datastore if no matching ephemeral data > (panes of glass) ; validation done at edit-time > > config=3Dephemeral validation done with ephemeral data > and operational state; config=3Dtrue MUST NOT appear > in any ephemeral data node constraint expressions.; > validation done at edit-time; not clear if additional validation > needed whenever any relevant operational state changes. > (Implementation detail how quickly server checks?) > > > > Lada >> >> > > Andy > > >> > >> > Validation rules are needed for ephemeral data. >> > Whether this is part of a protocol spec or YANG needs to be decided. >> > >> > >> > >> > Lada >> > >> > >> > Andy >> > >> > > >> > > >> > > >> > > >> > > /js >> > > >> > > >> > > Andy >> > > >> > > >> > > -- >> > > Juergen Schoenwaelder Jacobs University Bremen gGmbH >> > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germa= ny >> > > Fax: +49 421 200 3103 >> > > >> > >> > -- >> > Ladislav Lhotka, CZ.NIC Labs >> > PGP Key ID: E74E8C0C >> > >> > >> > >> > >> > >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> >> >> >> --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Aug 6 04:03:10 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC0B11B2CCD for ; Thu, 6 Aug 2015 04:03: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_64=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 ItMamBLf3d_M for ; Thu, 6 Aug 2015 04:03:05 -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 B34101B2CC3 for ; Thu, 6 Aug 2015 04:03:04 -0700 (PDT) Received: by labow3 with SMTP id ow3so46795828lab.1 for ; Thu, 06 Aug 2015 04:03: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=cydRL854w+3/arZ3UbwoJ7WDjf0+XaYsFIRm9TQOFRk=; b=BlGXxm/U1MBAygiL7geKr4csN01jqvy1I761sA7qEtH9onYvAR9RzEfRwzfo7f2my7 fZzmav8mdkHzdzVSI9y2PD5AunZXWc6si5oislebsAjBVMJcaJ6gRB8cD5jA3zVHTdBU T/TIS/dRH73F5DnA4Vovk/GmABS2bEePnr1DJz3l3Sa49bC2W2jozuTEXb0L93/Qi316 TkuYSMrEJKdIptM65yQAx6Bgco7+l1AoYx2sDsBJSeFxJAPQN8h6aVXAXVFlSDzj4Dux O+TBoW7fdKTJNbEWo8hMBv3w6R12yaqHv+QkOVaQly02IgztYhCYms8lvbG9+OyrBQmP l5Kw== X-Gm-Message-State: ALoCoQkiIGSokOi/1Wp8Xtc0+X3zX6fmrTbXrLMEQUIVYdjdA4q+DoNuAXf2NXohREXUZB10b+8h MIME-Version: 1.0 X-Received: by 10.152.42.209 with SMTP id q17mr937876lal.33.1438858983214; Thu, 06 Aug 2015 04:03:03 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Thu, 6 Aug 2015 04:03:02 -0700 (PDT) In-Reply-To: References: <20150730.211629.1600508626921450694.mbj@tail-f.com> <1D650959-4AB3-4B74-8A30-7BE3A69B896D@nic.cz> <20150803081814.GA71323@elstar.local> <55BF2F21.1070900@mg-soft.si> <20150803092501.GB71565@elstar.local> <646276CA-ED9B-40D1-8613-4F0FD6DD69BE@nic.cz> Date: Thu, 6 Aug 2015 04:03:02 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c34b6c93a6ea051ca27695 Archived-At: Cc: Jernej Tuljak , "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 11:03:08 -0000 --001a11c34b6c93a6ea051ca27695 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Aug 6, 2015 at 12:43 AM, Ladislav Lhotka wrote: > Andy Bierman writes: > > > On Mon, Aug 3, 2015 at 11:58 AM, Ladislav Lhotka wrote: > > > >> > >> > On 03 Aug 2015, at 18:01, Andy Bierman wrote: > >> > > >> > > >> > > >> > On Mon, Aug 3, 2015 at 7:48 AM, Ladislav Lhotka > wrote: > >> > > >> > > On 03 Aug 2015, at 16:41, Andy Bierman wrote: > >> > > > >> > > > >> > > > >> > > On Mon, Aug 3, 2015 at 2:25 AM, Juergen Schoenwaelder < > >> j.schoenwaelder@jacobs-university.de> wrote: > >> > > On Mon, Aug 03, 2015 at 11:06:41AM +0200, Jernej Tuljak wrote: > >> > > > Juergen Schoenwaelder je 3.8.2015 ob 10:18 napisal: > >> > > > >Any description statement in principle can do this. We trust th= at > >> sane > >> > > > >data model writers won't do bad things. And if they do, we hope > that > >> > > > >people will not implement and deploy bad things. > >> > > > > >> > > > Why not simply make this impossible by ensuring that description > >> > > > statements cannot change what has already been agreed upon in > RFC6020 > >> > > > (aka YANG semantics)? I would have no problem with descriptions > being > >> > > > normative, if this would be the case. > >> > > > >> > > You need to define way more clearly what 'YANG semantics' means. > >> > > > >> > > > >> > > > >> > > Agreed. The description-stmt is normative. > >> > > It defines implementation requirements for a data node. > >> > > It is not used to override other YANG statements. > >> > > However, if the description says "child foo must be > >> > > greater than the value of bar" that is just as normative > >> > > as a must-stmt that says the same thing. > >> > > > >> > > > >> > > > >I continue to see extension statements as reusable and (in > >> principle) > >> > > > >machine readable fragments of description statements. From this > >> > > > >perspective, it seems odd to make a difference between extensio= ns > >> and > >> > > > >description statements. > >> > > > > >> > > > I still disagree that description statements should be more > powerful > >> > > > than any other YANG statement. > >> > > > >> > > What does 'powerful' mean? Time that someone writes concrete text = so > >> > > we can have a more constructive discussion. > >> > > > >> > > > >> > > A YANG description-stmt cannot override the syntax and semantics o= f > >> other YANG > >> > > statements. But is is mandatory and it is normative. > >> > > >> > It=E2=80=99s not only about overriding. For example, it wouldn=E2=80= =99t be good to > >> introduce a new data node type though an extension. > >> > > >> > > >> > But isn't that exactly what you are proposing by making ephemeral da= ta > >> > an extension instead of part of YANG? > >> > >> It depends on how it would be defined and used. If it is an extension, > >> NETCONF/RESTCONF clients either shouldn=E2=80=99t see it at all, or th= ey should > be > >> able to ignore it. > >> > >> > > >> > None of the existing text covers the validation rules for ephemeral > data. > >> > Nothing is needed for config=3Dtrue nodes in the ephemeral datastore= , > >> > but ephemeral-only data needs to be identified. > >> > >> I think it still has to be clarified how ephemeral data interact with > >> normal config data. Normal semantic validation of config=3Dtrue data > doesn=E2=80=99t > >> make much sense to me if some parameters may be overriden by ephemeral > >> values. > >> > >> > > > > I agree that suitable solutions have been discussed off-line, > > and the slides from Jeff do not specify how validation would work. > > This is part of the month of work left to do. > > > > IMO the running datastore and ephemeral datastore have different > > validation procedures: > > > > Running: > > config=3Dtrue validation > > same as now; no impact from ephemeral datastore > > validation done at edit-time > > I think there has to be an impact - validation of running has to take > into account ephemeral values as long as they are what's operationally > used. > > This is completely wrong. Config nodes cannot refer to non-config nodes for validation. Consider the moment when the device boots, and there is no ephemeral data. Any validation of the startup config that depends on ephemeral data will fail. The running config must be self-consistent. It never ever relies on ephemeral or operational data for validation. > For example, take IPv6 RA parameters valid-lifetime and > preferred-lifetime as defined in ietf-ipv6-unicast-routing. A must > constraint is there to ensure that > > preferred-lifetime <=3D valid-lifetime > > Now, assume their values in running are p and v, respectively, but an > I2RS client sets an ephemeral value of valid-lifetime to v' where > > v' < v > > If a NETCONF client changes value of preferred-lifetime to p' where > > v' < p' <=3D v > > then the constraint in running is satisfied but the values p' and v' > appearing in RA Prefix Information sent by the device violate RFC 4861. > > How is this supposed to be resolved? > Setting the ephemeral value has to be valid in the ephermal datastore. That is a separate datastore and validated differently. See paragraph "Ephemeral' below. Perhaps the "panes of glass" concept has not been explained to you? > > Lada > Andy > > > > > Ephemeral: > > config=3Dtrue validation done with ephemeral data first, > > then running datastore if no matching ephemeral data > > (panes of glass) ; validation done at edit-time > > > > config=3Dephemeral validation done with ephemeral data > > and operational state; config=3Dtrue MUST NOT appear > > in any ephemeral data node constraint expressions.; > > validation done at edit-time; not clear if additional validation > > needed whenever any relevant operational state changes. > > (Implementation detail how quickly server checks?) > > > > > > > > Lada > >> > >> > > > > Andy > > > > > >> > > >> > Validation rules are needed for ephemeral data. > >> > Whether this is part of a protocol spec or YANG needs to be decided. > >> > > >> > > >> > > >> > Lada > >> > > >> > > >> > Andy > >> > > >> > > > >> > > > >> > > > >> > > > >> > > /js > >> > > > >> > > > >> > > Andy > >> > > > >> > > > >> > > -- > >> > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > >> > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > Germany > >> > > Fax: +49 421 200 3103 > >> > > > >> > > >> > -- > >> > Ladislav Lhotka, CZ.NIC Labs > >> > PGP Key ID: E74E8C0C > >> > > >> > > >> > > >> > > >> > > >> > >> -- > >> Ladislav Lhotka, CZ.NIC Labs > >> PGP Key ID: E74E8C0C > >> > >> > >> > >> > >> > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > --001a11c34b6c93a6ea051ca27695 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Aug 6, 2015 at 12:43 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:
Andy Bierman <andy@yumaworks.com> writes:

> On Mon, Aug 3, 2015 at 11:58 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
>>
>> > On 03 Aug 2015, at 18:01, Andy Bierman <andy@yumaworks.com> wrote:
>> >
>> >
>> >
>> > On Mon, Aug 3, 2015 at 7:48 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>> >
>> > > On 03 Aug 2015, at 16:41, Andy Bierman <andy@yumaworks.com> wrote:
>> > >
>> > >
>> > >
>> > > On Mon, Aug 3, 2015 at 2:25 AM, Juergen Schoenwaelder &l= t;
>> j.schoenwa= elder@jacobs-university.de> wrote:
>> > > On Mon, Aug 03, 2015 at 11:06:41AM +0200, Jernej Tuljak = wrote:
>> > > > Juergen Schoenwaelder je 3.8.2015 ob 10:18 napisal:=
>> > > > >Any description statement in principle can do t= his. We trust that
>> sane
>> > > > >data model writers won't do bad things. And= if they do, we hope that
>> > > > >people will not implement and deploy bad things= .
>> > > >
>> > > > Why not simply make this impossible by ensuring tha= t description
>> > > > statements cannot change what has already been agre= ed upon in RFC6020
>> > > > (aka YANG semantics)? I would have no problem with = descriptions being
>> > > > normative, if this would be the case.
>> > >
>> > > You need to define way more clearly what 'YANG seman= tics' means.
>> > >
>> > >
>> > >
>> > > Agreed.=C2=A0 The description-stmt is normative.
>> > > It defines implementation requirements for a data node.<= br> >> > > It is not used to override other YANG statements.
>> > > However, if the description says "child foo must be=
>> > > greater than the value of bar" that is just as norm= ative
>> > > as a must-stmt that says the same thing.
>> > >
>> > >
>> > > > >I continue to see extension statements as reusa= ble and (in
>> principle)
>> > > > >machine readable fragments of description state= ments. From this
>> > > > >perspective, it seems odd to make a difference = between extensions
>> and
>> > > > >description statements.
>> > > >
>> > > > I still disagree that description statements should= be more powerful
>> > > > than any other YANG statement.
>> > >
>> > > What does 'powerful' mean? Time that someone wri= tes concrete text so
>> > > we can have a more constructive discussion.
>> > >
>> > >
>> > > A YANG description-stmt cannot override the syntax and s= emantics of
>> other YANG
>> > > statements.=C2=A0 But is is mandatory and it is normativ= e.
>> >
>> > It=E2=80=99s not only about overriding. For example, it would= n=E2=80=99t be good to
>> introduce a new data node type though an extension.
>> >
>> >
>> > But isn't that exactly what you are proposing by making e= phemeral data
>> > an extension instead of part of YANG?
>>
>> It depends on how it would be defined and used. If it is an extens= ion,
>> NETCONF/RESTCONF clients either shouldn=E2=80=99t see it at all, o= r they should be
>> able to ignore it.
>>
>> >
>> > None of the existing text covers the validation rules for eph= emeral data.
>> > Nothing is needed for config=3Dtrue nodes in the ephemeral da= tastore,
>> > but ephemeral-only data needs to be identified.
>>
>> I think it still has to be clarified how ephemeral data interact w= ith
>> normal config data. Normal semantic validation of config=3Dtrue da= ta doesn=E2=80=99t
>> make much sense to me if some parameters may be overriden by ephem= eral
>> values.
>>
>>
>
> I agree that suitable solutions have been discussed off-line,
> and the slides from Jeff do not specify how validation would work.
> This is part of the month of work left to do.
>
> IMO the running datastore and ephemeral datastore have different
> validation procedures:
>
> Running:
>=C2=A0 =C2=A0 config=3Dtrue validation
>=C2=A0 =C2=A0 same as now; no impact from ephemeral datastore
>=C2=A0 =C2=A0 validation done at edit-time

I think there has to be an impact - validation of running has to take
into account ephemeral values as long as they are what's operationally<= br> used.




This is = completely wrong.
Config nodes cannot refer to non-config nodes f= or validation.
Consider the moment when the device boots, and the= re is
no ephemeral data.=C2=A0 Any validation of the startup conf= ig
that depends on ephemeral data will fail.

=
The running config must be self-consistent.
It never ever re= lies on ephemeral or operational data
for validation.
<= br>
=C2=A0
For example, take IPv6 RA parameters valid-lifetime and
preferred-lifetime as defined in ietf-ipv6-unicast-routing. A must
constraint is there to ensure that

preferred-lifetime <=3D valid-lifetime

Now, assume their values in running are p and v, respectively, but an
I2RS client sets an ephemeral value of valid-lifetime to v' where

v' < v

If a NETCONF client changes value of preferred-lifetime to p' where

v' < p' <=3D v

then the constraint in running is satisfied but the values p' and v'= ;
appearing in RA Prefix Information sent by the device violate RFC=C2=A04861= .

How is this supposed to be resolved?

Setting the ephemeral value has to be valid in the ephermal da= tastore.
That is a separate datastore and validated differently.<= /div>
See paragraph "Ephemeral' below.
Perhaps the &= quot;panes of glass" concept has not been explained to you?
=
=C2=A0

Lada


Andy
=C2= =A0

>
> Ephemeral:
>=C2=A0 =C2=A0config=3Dtrue validation done with ephemeral data first, >=C2=A0 =C2=A0then running datastore if no matching ephemeral data
>=C2=A0 =C2=A0(panes of glass) ; validation done at edit-time
>
>=C2=A0 =C2=A0config=3Dephemeral validation done with ephemeral data
>=C2=A0 =C2=A0and operational state; config=3Dtrue MUST NOT appear
>=C2=A0 =C2=A0in any ephemeral data node constraint expressions.;
>=C2=A0 =C2=A0validation done at edit-time; not clear if additional vali= dation
>=C2=A0 =C2=A0needed whenever any relevant operational state changes. >=C2=A0 (Implementation detail how quickly server checks?)
>
>
>
> Lada
>>
>>
>
> Andy
>
>
>> >
>> > Validation rules are needed for ephemeral data.
>> > Whether this is part of a protocol spec or YANG needs to be d= ecided.
>> >
>> >
>> >
>> > Lada
>> >
>> >
>> > Andy
>> >
>> > >
>> > >
>> > >
>> > >
>> > > /js
>> > >
>> > >
>> > > Andy
>> > >
>> > >
>> > > --
>> > > 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<http://www.jacobs-university.de/>
>> > >
>> >
>> > --
>> > Ladislav Lhotka, CZ.NIC Labs
>> > PGP Key ID: E74E8C0C
>> >
>> >
>> >
>> >
>> >
>>
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>
>>
>>
>>
>>

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

--001a11c34b6c93a6ea051ca27695-- From nobody Thu Aug 6 05:50:30 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9AB1B2E97 for ; Thu, 6 Aug 2015 05:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.061 X-Spam-Level: X-Spam-Status: No, score=-5.061 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CLvDFC89FY9 for ; Thu, 6 Aug 2015 05:50:20 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 619501B2AA5 for ; Thu, 6 Aug 2015 05:50:06 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:9c2f:bb09:39e3:669d] (unknown [IPv6:2001:718:1a02:1:9c2f:bb09:39e3:669d]) by mail.nic.cz (Postfix) with ESMTPSA id C54E9181861; Thu, 6 Aug 2015 14:50:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1438865404; bh=Bi6tfmvUE3Gt9/kBnWsDK49w8XzuCZKd8KhWUgf5//0=; h=From:Date:To; b=XcwTXQXQbMbCy9ni7KJd+0DaU2Psu9UdAqHDC0Tba1GyG+z/isGPaCsRxaJGlINCt +GSdIWdIzRo/nio4w1Ikl5UhTVr5Ml6LElgP+rqpEQEOTwcacW/ZPynLgWcd6Gp9oJ iTH73I0gMtsQ83tgVOl2C+giC0jZHkTDo3/LSUnc= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: Date: Thu, 6 Aug 2015 14:50:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <60C5B0D3-47C0-4748-95EA-1976C9EBE508@nic.cz> References: <20150730.211629.1600508626921450694.mbj@tail-f.com> <1D650959-4AB3-4B74-8A30-7BE3A69B896D@nic.cz> <20150803081814.GA71323@elstar.local> <55BF2F21.1070900@mg-soft.si> <20150803092501.GB71565@elstar.local> <646276CA-ED9B-40D1-8613-4F0FD6DD69BE@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Jernej Tuljak , "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 12:50:29 -0000 > On 06 Aug 2015, at 13:03, Andy Bierman wrote: >=20 >=20 >=20 > On Thu, Aug 6, 2015 at 12:43 AM, Ladislav Lhotka = wrote: > Andy Bierman writes: >=20 > > On Mon, Aug 3, 2015 at 11:58 AM, Ladislav Lhotka = wrote: > > > >> > >> > On 03 Aug 2015, at 18:01, Andy Bierman = wrote: > >> > > >> > > >> > > >> > On Mon, Aug 3, 2015 at 7:48 AM, Ladislav Lhotka = wrote: > >> > > >> > > On 03 Aug 2015, at 16:41, Andy Bierman = wrote: > >> > > > >> > > > >> > > > >> > > On Mon, Aug 3, 2015 at 2:25 AM, Juergen Schoenwaelder < > >> j.schoenwaelder@jacobs-university.de> wrote: > >> > > On Mon, Aug 03, 2015 at 11:06:41AM +0200, Jernej Tuljak wrote: > >> > > > Juergen Schoenwaelder je 3.8.2015 ob 10:18 napisal: > >> > > > >Any description statement in principle can do this. We trust = that > >> sane > >> > > > >data model writers won't do bad things. And if they do, we = hope that > >> > > > >people will not implement and deploy bad things. > >> > > > > >> > > > Why not simply make this impossible by ensuring that = description > >> > > > statements cannot change what has already been agreed upon in = RFC6020 > >> > > > (aka YANG semantics)? I would have no problem with = descriptions being > >> > > > normative, if this would be the case. > >> > > > >> > > You need to define way more clearly what 'YANG semantics' = means. > >> > > > >> > > > >> > > > >> > > Agreed. The description-stmt is normative. > >> > > It defines implementation requirements for a data node. > >> > > It is not used to override other YANG statements. > >> > > However, if the description says "child foo must be > >> > > greater than the value of bar" that is just as normative > >> > > as a must-stmt that says the same thing. > >> > > > >> > > > >> > > > >I continue to see extension statements as reusable and (in > >> principle) > >> > > > >machine readable fragments of description statements. =46rom = this > >> > > > >perspective, it seems odd to make a difference between = extensions > >> and > >> > > > >description statements. > >> > > > > >> > > > I still disagree that description statements should be more = powerful > >> > > > than any other YANG statement. > >> > > > >> > > What does 'powerful' mean? Time that someone writes concrete = text so > >> > > we can have a more constructive discussion. > >> > > > >> > > > >> > > A YANG description-stmt cannot override the syntax and = semantics of > >> other YANG > >> > > statements. But is is mandatory and it is normative. > >> > > >> > It=E2=80=99s not only about overriding. For example, it = wouldn=E2=80=99t be good to > >> introduce a new data node type though an extension. > >> > > >> > > >> > But isn't that exactly what you are proposing by making ephemeral = data > >> > an extension instead of part of YANG? > >> > >> It depends on how it would be defined and used. If it is an = extension, > >> NETCONF/RESTCONF clients either shouldn=E2=80=99t see it at all, or = they should be > >> able to ignore it. > >> > >> > > >> > None of the existing text covers the validation rules for = ephemeral data. > >> > Nothing is needed for config=3Dtrue nodes in the ephemeral = datastore, > >> > but ephemeral-only data needs to be identified. > >> > >> I think it still has to be clarified how ephemeral data interact = with > >> normal config data. Normal semantic validation of config=3Dtrue = data doesn=E2=80=99t > >> make much sense to me if some parameters may be overriden by = ephemeral > >> values. > >> > >> > > > > I agree that suitable solutions have been discussed off-line, > > and the slides from Jeff do not specify how validation would work. > > This is part of the month of work left to do. > > > > IMO the running datastore and ephemeral datastore have different > > validation procedures: > > > > Running: > > config=3Dtrue validation > > same as now; no impact from ephemeral datastore > > validation done at edit-time >=20 > I think there has to be an impact - validation of running has to take > into account ephemeral values as long as they are what's operationally > used. >=20 >=20 >=20 >=20 > This is completely wrong. > Config nodes cannot refer to non-config nodes for validation. > Consider the moment when the device boots, and there is > no ephemeral data. Any validation of the startup config > that depends on ephemeral data will fail. If there is no ephemeral data, then config data is what counts. However, = if some config parameters may be overriden by ephemeral values, then a = separate validation of running is not sufficient - it may be in conflict = with ephemeral data. I guess the purpose of semantic rules and validation is to make sure the = parameters that the device uses, no matter where they come from, are = correct. >=20 > The running config must be self-consistent. > It never ever relies on ephemeral or operational data > for validation. Ephemeral data is a configuration, too. >=20 > =20 > For example, take IPv6 RA parameters valid-lifetime and > preferred-lifetime as defined in ietf-ipv6-unicast-routing. A must > constraint is there to ensure that >=20 > preferred-lifetime <=3D valid-lifetime >=20 > Now, assume their values in running are p and v, respectively, but an > I2RS client sets an ephemeral value of valid-lifetime to v' where >=20 > v' < v >=20 > If a NETCONF client changes value of preferred-lifetime to p' where >=20 > v' < p' <=3D v >=20 > then the constraint in running is satisfied but the values p' and v' > appearing in RA Prefix Information sent by the device violate RFC = 4861. >=20 > How is this supposed to be resolved? >=20 >=20 > Setting the ephemeral value has to be valid in the ephermal datastore. > That is a separate datastore and validated differently. > See paragraph "Ephemeral' below. > Perhaps the "panes of glass" concept has not been explained to you? Of course it was. You didn=E2=80=99t answer my question though, so let = me expand my example into the following scenario: 1. The device boots, values of valid-lifetime and preferred-lifetime in = running are initialized from startup to v and p, respectively, where p < = v. The device sends RAs with there values, everything=E2=80=99s OK. 2. I2RS sets the ephemeral value of valid-lifetime to v=E2=80=99 where p = < v=E2=80=99 < v. The device now sends RAs with p and v=E2=80=99, which = is still OK. 3. A NETCONF client attempts to change preferred-lifetime in running to = p=E2=80=99 where v=E2=80=99 < p=E2=80=99 <=3D v. Should this edit be = rejected? On one hand, running continues to be perfectly valid, but on = the other hand RAs with values of p=E2=80=99 and v=E2=80=99 are broken. Lada >=20 > =20 >=20 > Lada >=20 >=20 > Andy > =20 >=20 > > > > Ephemeral: > > config=3Dtrue validation done with ephemeral data first, > > then running datastore if no matching ephemeral data > > (panes of glass) ; validation done at edit-time > > > > config=3Dephemeral validation done with ephemeral data > > and operational state; config=3Dtrue MUST NOT appear > > in any ephemeral data node constraint expressions.; > > validation done at edit-time; not clear if additional validation > > needed whenever any relevant operational state changes. > > (Implementation detail how quickly server checks?) > > > > > > > > Lada > >> > >> > > > > Andy > > > > > >> > > >> > Validation rules are needed for ephemeral data. > >> > Whether this is part of a protocol spec or YANG needs to be = decided. > >> > > >> > > >> > > >> > Lada > >> > > >> > > >> > Andy > >> > > >> > > > >> > > > >> > > > >> > > > >> > > /js > >> > > > >> > > > >> > > Andy > >> > > > >> > > > >> > > -- > >> > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > >> > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany > >> > > Fax: +49 421 200 3103 = > >> > > > >> > > >> > -- > >> > Ladislav Lhotka, CZ.NIC Labs > >> > PGP Key ID: E74E8C0C > >> > > >> > > >> > > >> > > >> > > >> > >> -- > >> Ladislav Lhotka, CZ.NIC Labs > >> PGP Key ID: E74E8C0C > >> > >> > >> > >> > >> >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Aug 6 08:31:39 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 806931B2A3A for ; Thu, 6 Aug 2015 08:31:37 -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_64=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 chvz4b3r3IvM for ; Thu, 6 Aug 2015 08:31:34 -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 A0B381AD16B for ; Thu, 6 Aug 2015 08:31:33 -0700 (PDT) Received: by labkb6 with SMTP id kb6so29487493lab.2 for ; Thu, 06 Aug 2015 08:31:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WacOxdGWkGrsN66CWhCZHclG2pE+gAZ9UflRf7oT78Q=; b=D/3IcYsl4BBuLl//1Lha6k40BWvLnh1Ua7LLq7ZF283yp8UTHLWiThtqJ8TLaZ0O4o 3DhQM67pY7LmP6In+CMcWd0YQQ0NRC0V2tMZXRWEOKaYwImvRoWsgBBZjiWZFm/lvULx 2y4a9/hN/36olAzltvjfMDsQrX3q78KfhyTRqu4iCvnwFWbKDMSDsFlYvx3oCgx4Yw8w QT1/yRVgVZAbwzrYNde+cYgC21pGs4VN/WQfIHveqJxXSfPOAwfIh0rovJnFO2ig5HW5 xY8UVcVRKgGadCE8f2t/0OLqvg1MORoMGL/IpNP45s4ObnmVCsDayfv6WP5pFGJ8ZWe8 rWqw== X-Gm-Message-State: ALoCoQkuNF6YmsDVhNjXRjFtRChTlF3XJZq3wt+nSI2/60wYeDlAXONQQgP8vc5wjwqQuNmkhrYP MIME-Version: 1.0 X-Received: by 10.112.234.163 with SMTP id uf3mr2583788lbc.37.1438875091814; Thu, 06 Aug 2015 08:31:31 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Thu, 6 Aug 2015 08:31:31 -0700 (PDT) In-Reply-To: <60C5B0D3-47C0-4748-95EA-1976C9EBE508@nic.cz> References: <20150730.211629.1600508626921450694.mbj@tail-f.com> <1D650959-4AB3-4B74-8A30-7BE3A69B896D@nic.cz> <20150803081814.GA71323@elstar.local> <55BF2F21.1070900@mg-soft.si> <20150803092501.GB71565@elstar.local> <646276CA-ED9B-40D1-8613-4F0FD6DD69BE@nic.cz> <60C5B0D3-47C0-4748-95EA-1976C9EBE508@nic.cz> Date: Thu, 6 Aug 2015 08:31:31 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c317e8b9641a051ca6362e Archived-At: Cc: Jernej Tuljak , "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 15:31:37 -0000 --001a11c317e8b9641a051ca6362e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Aug 6, 2015 at 5:50 AM, Ladislav Lhotka wrote: > > > On 06 Aug 2015, at 13:03, Andy Bierman wrote: > > > > > > > > On Thu, Aug 6, 2015 at 12:43 AM, Ladislav Lhotka wrote: > > Andy Bierman writes: > > > > > On Mon, Aug 3, 2015 at 11:58 AM, Ladislav Lhotka > wrote: > > > > > >> > > >> > On 03 Aug 2015, at 18:01, Andy Bierman wrote: > > >> > > > >> > > > >> > > > >> > On Mon, Aug 3, 2015 at 7:48 AM, Ladislav Lhotka > wrote: > > >> > > > >> > > On 03 Aug 2015, at 16:41, Andy Bierman > wrote: > > >> > > > > >> > > > > >> > > > > >> > > On Mon, Aug 3, 2015 at 2:25 AM, Juergen Schoenwaelder < > > >> j.schoenwaelder@jacobs-university.de> wrote: > > >> > > On Mon, Aug 03, 2015 at 11:06:41AM +0200, Jernej Tuljak wrote: > > >> > > > Juergen Schoenwaelder je 3.8.2015 ob 10:18 napisal: > > >> > > > >Any description statement in principle can do this. We trust > that > > >> sane > > >> > > > >data model writers won't do bad things. And if they do, we > hope that > > >> > > > >people will not implement and deploy bad things. > > >> > > > > > >> > > > Why not simply make this impossible by ensuring that descripti= on > > >> > > > statements cannot change what has already been agreed upon in > RFC6020 > > >> > > > (aka YANG semantics)? I would have no problem with description= s > being > > >> > > > normative, if this would be the case. > > >> > > > > >> > > You need to define way more clearly what 'YANG semantics' means. > > >> > > > > >> > > > > >> > > > > >> > > Agreed. The description-stmt is normative. > > >> > > It defines implementation requirements for a data node. > > >> > > It is not used to override other YANG statements. > > >> > > However, if the description says "child foo must be > > >> > > greater than the value of bar" that is just as normative > > >> > > as a must-stmt that says the same thing. > > >> > > > > >> > > > > >> > > > >I continue to see extension statements as reusable and (in > > >> principle) > > >> > > > >machine readable fragments of description statements. From th= is > > >> > > > >perspective, it seems odd to make a difference between > extensions > > >> and > > >> > > > >description statements. > > >> > > > > > >> > > > I still disagree that description statements should be more > powerful > > >> > > > than any other YANG statement. > > >> > > > > >> > > What does 'powerful' mean? Time that someone writes concrete tex= t > so > > >> > > we can have a more constructive discussion. > > >> > > > > >> > > > > >> > > A YANG description-stmt cannot override the syntax and semantics > of > > >> other YANG > > >> > > statements. But is is mandatory and it is normative. > > >> > > > >> > It=E2=80=99s not only about overriding. For example, it wouldn=E2= =80=99t be good to > > >> introduce a new data node type though an extension. > > >> > > > >> > > > >> > But isn't that exactly what you are proposing by making ephemeral > data > > >> > an extension instead of part of YANG? > > >> > > >> It depends on how it would be defined and used. If it is an extensio= n, > > >> NETCONF/RESTCONF clients either shouldn=E2=80=99t see it at all, or = they > should be > > >> able to ignore it. > > >> > > >> > > > >> > None of the existing text covers the validation rules for ephemera= l > data. > > >> > Nothing is needed for config=3Dtrue nodes in the ephemeral datasto= re, > > >> > but ephemeral-only data needs to be identified. > > >> > > >> I think it still has to be clarified how ephemeral data interact wit= h > > >> normal config data. Normal semantic validation of config=3Dtrue data > doesn=E2=80=99t > > >> make much sense to me if some parameters may be overriden by ephemer= al > > >> values. > > >> > > >> > > > > > > I agree that suitable solutions have been discussed off-line, > > > and the slides from Jeff do not specify how validation would work. > > > This is part of the month of work left to do. > > > > > > IMO the running datastore and ephemeral datastore have different > > > validation procedures: > > > > > > Running: > > > config=3Dtrue validation > > > same as now; no impact from ephemeral datastore > > > validation done at edit-time > > > > I think there has to be an impact - validation of running has to take > > into account ephemeral values as long as they are what's operationally > > used. > > > If an edit would cause the datastore to be invalid, then it has to be rejected. > > > > > > > > This is completely wrong. > > Config nodes cannot refer to non-config nodes for validation. > > Consider the moment when the device boots, and there is > > no ephemeral data. Any validation of the startup config > > that depends on ephemeral data will fail. > > If there is no ephemeral data, then config data is what counts. However, > if some config parameters may be overriden by ephemeral values, then a > separate validation of running is not sufficient - it may be in conflict > with ephemeral data. > > I guess the purpose of semantic rules and validation is to make sure the > parameters that the device uses, no matter where they come from, are > correct. > > > > > The running config must be self-consistent. > > It never ever relies on ephemeral or operational data > > for validation. > > Ephemeral data is a configuration, too. > It needs to be in a separate datastore so it can be validated separately from the running config. > > > > > > > For example, take IPv6 RA parameters valid-lifetime and > > preferred-lifetime as defined in ietf-ipv6-unicast-routing. A must > > constraint is there to ensure that > > > > preferred-lifetime <=3D valid-lifetime > > > > Now, assume their values in running are p and v, respectively, but an > > I2RS client sets an ephemeral value of valid-lifetime to v' where > > > > v' < v > > > > If a NETCONF client changes value of preferred-lifetime to p' where > > > > v' < p' <=3D v > > > > then the constraint in running is satisfied but the values p' and v' > > appearing in RA Prefix Information sent by the device violate RFC 4861. > > > > How is this supposed to be resolved? > > > > > > Setting the ephemeral value has to be valid in the ephermal datastore. > > That is a separate datastore and validated differently. > > See paragraph "Ephemeral' below. > > Perhaps the "panes of glass" concept has not been explained to you? > > Of course it was. You didn=E2=80=99t answer my question though, so let me= expand > my example into the following scenario: > > 1. The device boots, values of valid-lifetime and preferred-lifetime in > running are initialized from startup to v and p, respectively, where p < = v. > The device sends RAs with there values, everything=E2=80=99s OK. > > 2. I2RS sets the ephemeral value of valid-lifetime to v=E2=80=99 where p = < v=E2=80=99 < v. > The device now sends RAs with p and v=E2=80=99, which is still OK. > > 3. A NETCONF client attempts to change preferred-lifetime in running to p= =E2=80=99 > where v=E2=80=99 < p=E2=80=99 <=3D v. Should this edit be rejected? On on= e hand, running > continues to be perfectly valid, but on the other hand RAs with values of > p=E2=80=99 and v=E2=80=99 are broken. > > This type of corner case has been discussed. The ephemeral state needs to over-write enough of the running config to be self-consistent. In any case it is OK to set the running config value to something that will not be used at the moment. I2RS will prevent the running config value of p from being used. The ephemeral config has priority over the running config. Lada > Andy > > > > > > > > > Lada > > > > > > Andy > > > > > > > > > > Ephemeral: > > > config=3Dtrue validation done with ephemeral data first, > > > then running datastore if no matching ephemeral data > > > (panes of glass) ; validation done at edit-time > > > > > > config=3Dephemeral validation done with ephemeral data > > > and operational state; config=3Dtrue MUST NOT appear > > > in any ephemeral data node constraint expressions.; > > > validation done at edit-time; not clear if additional validation > > > needed whenever any relevant operational state changes. > > > (Implementation detail how quickly server checks?) > > > > > > > > > > > > Lada > > >> > > >> > > > > > > Andy > > > > > > > > >> > > > >> > Validation rules are needed for ephemeral data. > > >> > Whether this is part of a protocol spec or YANG needs to be decide= d. > > >> > > > >> > > > >> > > > >> > Lada > > >> > > > >> > > > >> > Andy > > >> > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > /js > > >> > > > > >> > > > > >> > > Andy > > >> > > > > >> > > > > >> > > -- > > >> > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > >> > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > Germany > > >> > > Fax: +49 421 200 3103 > > > >> > > > > >> > > > >> > -- > > >> > Ladislav Lhotka, CZ.NIC Labs > > >> > PGP Key ID: E74E8C0C > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > >> -- > > >> Ladislav Lhotka, CZ.NIC Labs > > >> PGP Key ID: E74E8C0C > > >> > > >> > > >> > > >> > > >> > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a11c317e8b9641a051ca6362e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Aug 6, 2015 at 5:50 AM, Ladislav Lhotka <<= a href=3D"mailto:lhotka@nic.cz" target=3D"_blank">lhotka@nic.cz> wrote:

> On 06 Aug 2015, at 13:03, Andy Bierman <andy@yumaworks.com> wrote:
>
>
>
> On Thu, Aug 6, 2015 at 12:43 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> Andy Bierman <andy@yumaworks.= com> writes:
>
> > On Mon, Aug 3, 2015 at 11:58 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> >
> >>
> >> > On 03 Aug 2015, at 18:01, Andy Bierman <andy@yumaworks.com> wrote:
> >> >
> >> >
> >> >
> >> > On Mon, Aug 3, 2015 at 7:48 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> >> >
> >> > > On 03 Aug 2015, at 16:41, Andy Bierman <andy@yumaworks.com> wrote:
> >> > >
> >> > >
> >> > >
> >> > > On Mon, Aug 3, 2015 at 2:25 AM, Juergen Schoenwaeld= er <
> >> j.sch= oenwaelder@jacobs-university.de> wrote:
> >> > > On Mon, Aug 03, 2015 at 11:06:41AM +0200, Jernej Tu= ljak wrote:
> >> > > > Juergen Schoenwaelder je 3.8.2015 ob 10:18 nap= isal:
> >> > > > >Any description statement in principle can= do this. We trust that
> >> sane
> >> > > > >data model writers won't do bad things= . And if they do, we hope that
> >> > > > >people will not implement and deploy bad t= hings.
> >> > > >
> >> > > > Why not simply make this impossible by ensurin= g that description
> >> > > > statements cannot change what has already been= agreed upon in RFC6020
> >> > > > (aka YANG semantics)? I would have no problem = with descriptions being
> >> > > > normative, if this would be the case.
> >> > >
> >> > > You need to define way more clearly what 'YANG = semantics' means.
> >> > >
> >> > >
> >> > >
> >> > > Agreed.=C2=A0 The description-stmt is normative. > >> > > It defines implementation requirements for a data n= ode.
> >> > > It is not used to override other YANG statements. > >> > > However, if the description says "child foo mu= st be
> >> > > greater than the value of bar" that is just as= normative
> >> > > as a must-stmt that says the same thing.
> >> > >
> >> > >
> >> > > > >I continue to see extension statements as = reusable and (in
> >> principle)
> >> > > > >machine readable fragments of description = statements. From this
> >> > > > >perspective, it seems odd to make a differ= ence between extensions
> >> and
> >> > > > >description statements.
> >> > > >
> >> > > > I still disagree that description statements s= hould be more powerful
> >> > > > than any other YANG statement.
> >> > >
> >> > > What does 'powerful' mean? Time that someon= e writes concrete text so
> >> > > we can have a more constructive discussion.
> >> > >
> >> > >
> >> > > A YANG description-stmt cannot override the syntax = and semantics of
> >> other YANG
> >> > > statements.=C2=A0 But is is mandatory and it is nor= mative.
> >> >
> >> > It=E2=80=99s not only about overriding. For example, it = wouldn=E2=80=99t be good to
> >> introduce a new data node type though an extension.
> >> >
> >> >
> >> > But isn't that exactly what you are proposing by mak= ing ephemeral data
> >> > an extension instead of part of YANG?
> >>
> >> It depends on how it would be defined and used. If it is an e= xtension,
> >> NETCONF/RESTCONF clients either shouldn=E2=80=99t see it at a= ll, or they should be
> >> able to ignore it.
> >>
> >> >
> >> > None of the existing text covers the validation rules fo= r ephemeral data.
> >> > Nothing is needed for config=3Dtrue nodes in the ephemer= al datastore,
> >> > but ephemeral-only data needs to be identified.
> >>
> >> I think it still has to be clarified how ephemeral data inter= act with
> >> normal config data. Normal semantic validation of config=3Dtr= ue data doesn=E2=80=99t
> >> make much sense to me if some parameters may be overriden by = ephemeral
> >> values.
> >>
> >>
> >
> > I agree that suitable solutions have been discussed off-line,
> > and the slides from Jeff do not specify how validation would work= .
> > This is part of the month of work left to do.
> >
> > IMO the running datastore and ephemeral datastore have different<= br> > > validation procedures:
> >
> > Running:
> >=C2=A0 =C2=A0 config=3Dtrue validation
> >=C2=A0 =C2=A0 same as now; no impact from ephemeral datastore
> >=C2=A0 =C2=A0 validation done at edit-time
>
> I think there has to be an impact - validation of running has to take<= br> > into account ephemeral values as long as they are what's operation= ally
> used.
>


If an edit would ca= use the datastore to be invalid,
then it has to be rejected.

=C2=A0
>
>
>
> This is completely wrong.
> Config nodes cannot refer to non-config nodes for validation.
> Consider the moment when the device boots, and there is
> no ephemeral data.=C2=A0 Any validation of the startup config
> that depends on ephemeral data will fail.

If there is no ephemeral data, then config data is what counts. However, if= some config parameters may be overriden by ephemeral values, then a separa= te validation of running is not sufficient - it may be in conflict with eph= emeral data.

I guess the purpose of semantic rules and validation is to make sure the pa= rameters that the device uses, no matter where they come from, are correct.=

>
> The running config must be self-consistent.
> It never ever relies on ephemeral or operational data
> for validation.

Ephemeral data is a configuration, too.

It needs to be in a separate datastore so it can be
validated se= parately from the running config.

=C2=A0

>
>
> For example, take IPv6 RA parameters valid-lifetime and
> preferred-lifetime as defined in ietf-ipv6-unicast-routing. A must
> constraint is there to ensure that
>
> preferred-lifetime <=3D valid-lifetime
>
> Now, assume their values in running are p and v, respectively, but an<= br> > I2RS client sets an ephemeral value of valid-lifetime to v' where<= br> >
> v' < v
>
> If a NETCONF client changes value of preferred-lifetime to p' wher= e
>
> v' < p' <=3D v
>
> then the constraint in running is satisfied but the values p' and = v'
> appearing in RA Prefix Information sent by the device violate RFC 4861= .
>
> How is this supposed to be resolved?
>
>
> Setting the ephemeral value has to be valid in the ephermal datastore.=
> That is a separate datastore and validated differently.
> See paragraph "Ephemeral' below.
> Perhaps the "panes of glass" concept has not been explained = to you?

Of course it was. You didn=E2=80=99t answer my question though, so let me e= xpand my example into the following scenario:

1. The device boots, values of valid-lifetime and preferred-lifetime in run= ning are initialized from startup to v and p, respectively, where p < v.= The device sends RAs with there values, everything=E2=80=99s OK.

2. I2RS sets the ephemeral value of valid-lifetime to v=E2=80=99 where p &l= t; v=E2=80=99 < v. The device now sends RAs with p and v=E2=80=99, which= is still OK.

3. A NETCONF client attempts to change preferred-lifetime in running to p= =E2=80=99 where v=E2=80=99 < p=E2=80=99 <=3D v. Should this edit be r= ejected? On one hand, running continues to be perfectly valid, but on the o= ther hand RAs with values of p=E2=80=99 and v=E2=80=99 are broken.



This type of corner cas= e has been discussed.
The ephemeral state needs to over-write eno= ugh of
the running config to be self-consistent.=C2=A0
=
In any case it is OK to set the running config value to
something that will not be used at the moment.=C2=A0 I2RS
w= ill prevent the running config value of p from being used.
The ep= hemeral config has priority over the running config.


Lada

Andy
=C2=A0

>
>
>
> Lada
>
>
> Andy
>
>
> >
> > Ephemeral:
> >=C2=A0 =C2=A0config=3Dtrue validation done with ephemeral data fir= st,
> >=C2=A0 =C2=A0then running datastore if no matching ephemeral data<= br> > >=C2=A0 =C2=A0(panes of glass) ; validation done at edit-time
> >
> >=C2=A0 =C2=A0config=3Dephemeral validation done with ephemeral dat= a
> >=C2=A0 =C2=A0and operational state; config=3Dtrue MUST NOT appear<= br> > >=C2=A0 =C2=A0in any ephemeral data node constraint expressions.; > >=C2=A0 =C2=A0validation done at edit-time; not clear if additional= validation
> >=C2=A0 =C2=A0needed whenever any relevant operational state change= s.
> >=C2=A0 (Implementation detail how quickly server checks?)
> >
> >
> >
> > Lada
> >>
> >>
> >
> > Andy
> >
> >
> >> >
> >> > Validation rules are needed for ephemeral data.
> >> > Whether this is part of a protocol spec or YANG needs to= be decided.
> >> >
> >> >
> >> >
> >> > Lada
> >> >
> >> >
> >> > Andy
> >> >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > /js
> >> > >
> >> > >
> >> > > Andy
> >> > >
> >> > >
> >> > > --
> >> > > 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<http://www.jacobs-university.de/>
> >> > >
> >> >
> >> > --
> >> > Ladislav Lhotka, CZ.NIC Labs
> >> > PGP Key ID: E74E8C0C
> >> >
> >> >
> >> >
> >> >
> >> >
> >>
> >> --
> >> Ladislav Lhotka, CZ.NIC Labs
> >> PGP Key ID: E74E8C0C
> >>
> >>
> >>
> >>
> >>
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C

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





--001a11c317e8b9641a051ca6362e-- From nobody Thu Aug 6 08:40:51 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7420E1B2E0D for ; Thu, 6 Aug 2015 08:40:50 -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_64=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 idmfLH4Q6pLB for ; Thu, 6 Aug 2015 08:40:47 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 998E71B2E0C for ; Thu, 6 Aug 2015 08:40:47 -0700 (PDT) Received: from [172.29.2.202] (nat-14.bravonet.cz [77.48.225.14]) by mail.nic.cz (Postfix) with ESMTPSA id F41D018144C; Thu, 6 Aug 2015 17:40:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1438875646; bh=khr6L6IQepHR1xyud1uf7lyb/hWXetXdzLxDxUnBlGE=; h=From:Date:To; b=CR44aG6fiyx6dP1fQjdG9UaYGdRLF54rlVYz1qAXiAFVx2V7OtrYIHESB8CUquuhj DkG6Cke6/wCvP+b8OOG5x7a0eHwLcdwQqQakkGASC+tkDg8e4qsfDpboKOqAxIBlju 5w6MJQoh1aos5HGymDomlBVtD/N+obYW7dzdxLHw= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: Date: Thu, 6 Aug 2015 17:40:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2DBDE99A-0138-439E-B8DD-EB9ED12069ED@nic.cz> References: <20150730.211629.1600508626921450694.mbj@tail-f.com> <1D650959-4AB3-4B74-8A30-7BE3A69B896D@nic.cz> <20150803081814.GA71323@elstar.local> <55BF2F21.1070900@mg-soft.si> <20150803092501.GB71565@elstar.local> <646276CA-ED9B-40D1-8613-4F0FD6DD69BE@nic.cz> <60C5B0D3-47C0-4748-95EA-1976C9EBE508@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Jernej Tuljak , "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 15:40:50 -0000 > On 06 Aug 2015, at 17:31, Andy Bierman wrote: >=20 >=20 >=20 > On Thu, Aug 6, 2015 at 5:50 AM, Ladislav Lhotka wrote: >=20 > > On 06 Aug 2015, at 13:03, Andy Bierman wrote: > > > > > > > > On Thu, Aug 6, 2015 at 12:43 AM, Ladislav Lhotka = wrote: > > Andy Bierman writes: > > > > > On Mon, Aug 3, 2015 at 11:58 AM, Ladislav Lhotka = wrote: > > > > > >> > > >> > On 03 Aug 2015, at 18:01, Andy Bierman = wrote: > > >> > > > >> > > > >> > > > >> > On Mon, Aug 3, 2015 at 7:48 AM, Ladislav Lhotka = wrote: > > >> > > > >> > > On 03 Aug 2015, at 16:41, Andy Bierman = wrote: > > >> > > > > >> > > > > >> > > > > >> > > On Mon, Aug 3, 2015 at 2:25 AM, Juergen Schoenwaelder < > > >> j.schoenwaelder@jacobs-university.de> wrote: > > >> > > On Mon, Aug 03, 2015 at 11:06:41AM +0200, Jernej Tuljak = wrote: > > >> > > > Juergen Schoenwaelder je 3.8.2015 ob 10:18 napisal: > > >> > > > >Any description statement in principle can do this. We = trust that > > >> sane > > >> > > > >data model writers won't do bad things. And if they do, we = hope that > > >> > > > >people will not implement and deploy bad things. > > >> > > > > > >> > > > Why not simply make this impossible by ensuring that = description > > >> > > > statements cannot change what has already been agreed upon = in RFC6020 > > >> > > > (aka YANG semantics)? I would have no problem with = descriptions being > > >> > > > normative, if this would be the case. > > >> > > > > >> > > You need to define way more clearly what 'YANG semantics' = means. > > >> > > > > >> > > > > >> > > > > >> > > Agreed. The description-stmt is normative. > > >> > > It defines implementation requirements for a data node. > > >> > > It is not used to override other YANG statements. > > >> > > However, if the description says "child foo must be > > >> > > greater than the value of bar" that is just as normative > > >> > > as a must-stmt that says the same thing. > > >> > > > > >> > > > > >> > > > >I continue to see extension statements as reusable and (in > > >> principle) > > >> > > > >machine readable fragments of description statements. =46rom= this > > >> > > > >perspective, it seems odd to make a difference between = extensions > > >> and > > >> > > > >description statements. > > >> > > > > > >> > > > I still disagree that description statements should be more = powerful > > >> > > > than any other YANG statement. > > >> > > > > >> > > What does 'powerful' mean? Time that someone writes concrete = text so > > >> > > we can have a more constructive discussion. > > >> > > > > >> > > > > >> > > A YANG description-stmt cannot override the syntax and = semantics of > > >> other YANG > > >> > > statements. But is is mandatory and it is normative. > > >> > > > >> > It=E2=80=99s not only about overriding. For example, it = wouldn=E2=80=99t be good to > > >> introduce a new data node type though an extension. > > >> > > > >> > > > >> > But isn't that exactly what you are proposing by making = ephemeral data > > >> > an extension instead of part of YANG? > > >> > > >> It depends on how it would be defined and used. If it is an = extension, > > >> NETCONF/RESTCONF clients either shouldn=E2=80=99t see it at all, = or they should be > > >> able to ignore it. > > >> > > >> > > > >> > None of the existing text covers the validation rules for = ephemeral data. > > >> > Nothing is needed for config=3Dtrue nodes in the ephemeral = datastore, > > >> > but ephemeral-only data needs to be identified. > > >> > > >> I think it still has to be clarified how ephemeral data interact = with > > >> normal config data. Normal semantic validation of config=3Dtrue = data doesn=E2=80=99t > > >> make much sense to me if some parameters may be overriden by = ephemeral > > >> values. > > >> > > >> > > > > > > I agree that suitable solutions have been discussed off-line, > > > and the slides from Jeff do not specify how validation would work. > > > This is part of the month of work left to do. > > > > > > IMO the running datastore and ephemeral datastore have different > > > validation procedures: > > > > > > Running: > > > config=3Dtrue validation > > > same as now; no impact from ephemeral datastore > > > validation done at edit-time > > > > I think there has to be an impact - validation of running has to = take > > into account ephemeral values as long as they are what's = operationally > > used. > > >=20 >=20 > If an edit would cause the datastore to be invalid, > then it has to be rejected. >=20 > =20 > > > > > > > > This is completely wrong. > > Config nodes cannot refer to non-config nodes for validation. > > Consider the moment when the device boots, and there is > > no ephemeral data. Any validation of the startup config > > that depends on ephemeral data will fail. >=20 > If there is no ephemeral data, then config data is what counts. = However, if some config parameters may be overriden by ephemeral values, = then a separate validation of running is not sufficient - it may be in = conflict with ephemeral data. >=20 > I guess the purpose of semantic rules and validation is to make sure = the parameters that the device uses, no matter where they come from, are = correct. >=20 > > > > The running config must be self-consistent. > > It never ever relies on ephemeral or operational data > > for validation. >=20 > Ephemeral data is a configuration, too. >=20 > It needs to be in a separate datastore so it can be > validated separately from the running config. >=20 > =20 >=20 > > > > > > For example, take IPv6 RA parameters valid-lifetime and > > preferred-lifetime as defined in ietf-ipv6-unicast-routing. A must > > constraint is there to ensure that > > > > preferred-lifetime <=3D valid-lifetime > > > > Now, assume their values in running are p and v, respectively, but = an > > I2RS client sets an ephemeral value of valid-lifetime to v' where > > > > v' < v > > > > If a NETCONF client changes value of preferred-lifetime to p' where > > > > v' < p' <=3D v > > > > then the constraint in running is satisfied but the values p' and v' > > appearing in RA Prefix Information sent by the device violate RFC = 4861. > > > > How is this supposed to be resolved? > > > > > > Setting the ephemeral value has to be valid in the ephermal = datastore. > > That is a separate datastore and validated differently. > > See paragraph "Ephemeral' below. > > Perhaps the "panes of glass" concept has not been explained to you? >=20 > Of course it was. You didn=E2=80=99t answer my question though, so let = me expand my example into the following scenario: >=20 > 1. The device boots, values of valid-lifetime and preferred-lifetime = in running are initialized from startup to v and p, respectively, where = p < v. The device sends RAs with there values, everything=E2=80=99s OK. >=20 > 2. I2RS sets the ephemeral value of valid-lifetime to v=E2=80=99 where = p < v=E2=80=99 < v. The device now sends RAs with p and v=E2=80=99, = which is still OK. >=20 > 3. A NETCONF client attempts to change preferred-lifetime in running = to p=E2=80=99 where v=E2=80=99 < p=E2=80=99 <=3D v. Should this edit be = rejected? On one hand, running continues to be perfectly valid, but on = the other hand RAs with values of p=E2=80=99 and v=E2=80=99 are broken. >=20 >=20 >=20 > This type of corner case has been discussed. > The ephemeral state needs to over-write enough of > the running config to be self-consistent. Hmm, so such values become suddenly persistent? And what if running is = locked when this over-write is attempted? Will such chagnes be = propagated to candidate? This looks like a lot of wizardry that tries to hack ephemeral state on = top of the existing NETCONF architecture. Lada > =20 >=20 > In any case it is OK to set the running config value to > something that will not be used at the moment. I2RS > will prevent the running config value of p from being used. > The ephemeral config has priority over the running config. >=20 >=20 > Lada >=20 > Andy > =20 >=20 > > > > > > > > Lada > > > > > > Andy > > > > > > > > > > Ephemeral: > > > config=3Dtrue validation done with ephemeral data first, > > > then running datastore if no matching ephemeral data > > > (panes of glass) ; validation done at edit-time > > > > > > config=3Dephemeral validation done with ephemeral data > > > and operational state; config=3Dtrue MUST NOT appear > > > in any ephemeral data node constraint expressions.; > > > validation done at edit-time; not clear if additional validation > > > needed whenever any relevant operational state changes. > > > (Implementation detail how quickly server checks?) > > > > > > > > > > > > Lada > > >> > > >> > > > > > > Andy > > > > > > > > >> > > > >> > Validation rules are needed for ephemeral data. > > >> > Whether this is part of a protocol spec or YANG needs to be = decided. > > >> > > > >> > > > >> > > > >> > Lada > > >> > > > >> > > > >> > Andy > > >> > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > /js > > >> > > > > >> > > > > >> > > Andy > > >> > > > > >> > > > > >> > > -- > > >> > > Juergen Schoenwaelder Jacobs University Bremen = gGmbH > > >> > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen = | Germany > > >> > > Fax: +49 421 200 3103 = > > >> > > > > >> > > > >> > -- > > >> > Ladislav Lhotka, CZ.NIC Labs > > >> > PGP Key ID: E74E8C0C > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > >> -- > > >> Ladislav Lhotka, CZ.NIC Labs > > >> PGP Key ID: E74E8C0C > > >> > > >> > > >> > > >> > > >> > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Aug 6 08:46:50 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF831B3060 for ; Thu, 6 Aug 2015 08:46:46 -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_64=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 YwOvEjMSZoPD for ; Thu, 6 Aug 2015 08:46:42 -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 B5A491B305A for ; Thu, 6 Aug 2015 08:46:41 -0700 (PDT) Received: by lbbpo9 with SMTP id po9so45528358lbb.2 for ; Thu, 06 Aug 2015 08:46:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=nc56Pa0RWuAVeCVwz1B4rRdluzwYXGgmJbQ/JZGlnT8=; b=RWrbU2ncGCNKuS4PXA6gVQg2lHWlzNNUKCl2cJfCZpZgG7sv7G/Ts5mgJ0FS8xkPZL ct3+BsMZyb1G13BtT+KMcoxWsLjEf53Uo98If99TVvS2WWYiJmo2XX9syh62friIfTAz 6POJRQ2cZHy8GA/Af5r0Lndq7f3Fzk54IiJpd+8Pb0i92xLEtGOGh+Wk1rwi9s4vBNWu Do2tN/WQXfWX6pQWpupSu8guxhp1hV8aY4tDEjZAqpGoy4aqJ5OZwCpOMSX+Ns5Oj5Dk 6tUie8rWL0QkvYjTpFUhs9UkxbU/y4HrnzVWGFdOg0YdjwbmtnpSYvXRl0YDvbiDWBmi BKBw== X-Gm-Message-State: ALoCoQlu/6zbdGO9StLzfntFcWjUtNb6VwPTDzUWa9riJdpjTAVhZ7VV4PO9VnMcetCg1JM3V8pL MIME-Version: 1.0 X-Received: by 10.112.234.163 with SMTP id uf3mr2710031lbc.37.1438876000174; Thu, 06 Aug 2015 08:46:40 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Thu, 6 Aug 2015 08:46:39 -0700 (PDT) In-Reply-To: <2DBDE99A-0138-439E-B8DD-EB9ED12069ED@nic.cz> References: <20150730.211629.1600508626921450694.mbj@tail-f.com> <1D650959-4AB3-4B74-8A30-7BE3A69B896D@nic.cz> <20150803081814.GA71323@elstar.local> <55BF2F21.1070900@mg-soft.si> <20150803092501.GB71565@elstar.local> <646276CA-ED9B-40D1-8613-4F0FD6DD69BE@nic.cz> <60C5B0D3-47C0-4748-95EA-1976C9EBE508@nic.cz> <2DBDE99A-0138-439E-B8DD-EB9ED12069ED@nic.cz> Date: Thu, 6 Aug 2015 08:46:39 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c317e8ddcfe3051ca66c77 Archived-At: Cc: Jernej Tuljak , "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 15:46:46 -0000 --001a11c317e8ddcfe3051ca66c77 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Aug 6, 2015 at 8:40 AM, Ladislav Lhotka wrote: > > > On 06 Aug 2015, at 17:31, Andy Bierman wrote: > > > > > > > > On Thu, Aug 6, 2015 at 5:50 AM, Ladislav Lhotka wrote: > > > > > On 06 Aug 2015, at 13:03, Andy Bierman wrote: > > > > > > > > > > > > On Thu, Aug 6, 2015 at 12:43 AM, Ladislav Lhotka > wrote: > > > Andy Bierman writes: > > > > > > > On Mon, Aug 3, 2015 at 11:58 AM, Ladislav Lhotka > wrote: > > > > > > > >> > > > >> > On 03 Aug 2015, at 18:01, Andy Bierman > wrote: > > > >> > > > > >> > > > > >> > > > > >> > On Mon, Aug 3, 2015 at 7:48 AM, Ladislav Lhotka > wrote: > > > >> > > > > >> > > On 03 Aug 2015, at 16:41, Andy Bierman > wrote: > > > >> > > > > > >> > > > > > >> > > > > > >> > > On Mon, Aug 3, 2015 at 2:25 AM, Juergen Schoenwaelder < > > > >> j.schoenwaelder@jacobs-university.de> wrote: > > > >> > > On Mon, Aug 03, 2015 at 11:06:41AM +0200, Jernej Tuljak wrote: > > > >> > > > Juergen Schoenwaelder je 3.8.2015 ob 10:18 napisal: > > > >> > > > >Any description statement in principle can do this. We trus= t > that > > > >> sane > > > >> > > > >data model writers won't do bad things. And if they do, we > hope that > > > >> > > > >people will not implement and deploy bad things. > > > >> > > > > > > >> > > > Why not simply make this impossible by ensuring that > description > > > >> > > > statements cannot change what has already been agreed upon i= n > RFC6020 > > > >> > > > (aka YANG semantics)? I would have no problem with > descriptions being > > > >> > > > normative, if this would be the case. > > > >> > > > > > >> > > You need to define way more clearly what 'YANG semantics' mean= s. > > > >> > > > > > >> > > > > > >> > > > > > >> > > Agreed. The description-stmt is normative. > > > >> > > It defines implementation requirements for a data node. > > > >> > > It is not used to override other YANG statements. > > > >> > > However, if the description says "child foo must be > > > >> > > greater than the value of bar" that is just as normative > > > >> > > as a must-stmt that says the same thing. > > > >> > > > > > >> > > > > > >> > > > >I continue to see extension statements as reusable and (in > > > >> principle) > > > >> > > > >machine readable fragments of description statements. From > this > > > >> > > > >perspective, it seems odd to make a difference between > extensions > > > >> and > > > >> > > > >description statements. > > > >> > > > > > > >> > > > I still disagree that description statements should be more > powerful > > > >> > > > than any other YANG statement. > > > >> > > > > > >> > > What does 'powerful' mean? Time that someone writes concrete > text so > > > >> > > we can have a more constructive discussion. > > > >> > > > > > >> > > > > > >> > > A YANG description-stmt cannot override the syntax and > semantics of > > > >> other YANG > > > >> > > statements. But is is mandatory and it is normative. > > > >> > > > > >> > It=E2=80=99s not only about overriding. For example, it wouldn= =E2=80=99t be good > to > > > >> introduce a new data node type though an extension. > > > >> > > > > >> > > > > >> > But isn't that exactly what you are proposing by making ephemera= l > data > > > >> > an extension instead of part of YANG? > > > >> > > > >> It depends on how it would be defined and used. If it is an > extension, > > > >> NETCONF/RESTCONF clients either shouldn=E2=80=99t see it at all, o= r they > should be > > > >> able to ignore it. > > > >> > > > >> > > > > >> > None of the existing text covers the validation rules for > ephemeral data. > > > >> > Nothing is needed for config=3Dtrue nodes in the ephemeral > datastore, > > > >> > but ephemeral-only data needs to be identified. > > > >> > > > >> I think it still has to be clarified how ephemeral data interact > with > > > >> normal config data. Normal semantic validation of config=3Dtrue da= ta > doesn=E2=80=99t > > > >> make much sense to me if some parameters may be overriden by > ephemeral > > > >> values. > > > >> > > > >> > > > > > > > > I agree that suitable solutions have been discussed off-line, > > > > and the slides from Jeff do not specify how validation would work. > > > > This is part of the month of work left to do. > > > > > > > > IMO the running datastore and ephemeral datastore have different > > > > validation procedures: > > > > > > > > Running: > > > > config=3Dtrue validation > > > > same as now; no impact from ephemeral datastore > > > > validation done at edit-time > > > > > > I think there has to be an impact - validation of running has to take > > > into account ephemeral values as long as they are what's operationall= y > > > used. > > > > > > > > > If an edit would cause the datastore to be invalid, > > then it has to be rejected. > > > > > > > > > > > > > > > > This is completely wrong. > > > Config nodes cannot refer to non-config nodes for validation. > > > Consider the moment when the device boots, and there is > > > no ephemeral data. Any validation of the startup config > > > that depends on ephemeral data will fail. > > > > If there is no ephemeral data, then config data is what counts. However= , > if some config parameters may be overriden by ephemeral values, then a > separate validation of running is not sufficient - it may be in conflict > with ephemeral data. > > > > I guess the purpose of semantic rules and validation is to make sure th= e > parameters that the device uses, no matter where they come from, are > correct. > > > > > > > > The running config must be self-consistent. > > > It never ever relies on ephemeral or operational data > > > for validation. > > > > Ephemeral data is a configuration, too. > > > > It needs to be in a separate datastore so it can be > > validated separately from the running config. > > > > > > > > > > > > > > > For example, take IPv6 RA parameters valid-lifetime and > > > preferred-lifetime as defined in ietf-ipv6-unicast-routing. A must > > > constraint is there to ensure that > > > > > > preferred-lifetime <=3D valid-lifetime > > > > > > Now, assume their values in running are p and v, respectively, but an > > > I2RS client sets an ephemeral value of valid-lifetime to v' where > > > > > > v' < v > > > > > > If a NETCONF client changes value of preferred-lifetime to p' where > > > > > > v' < p' <=3D v > > > > > > then the constraint in running is satisfied but the values p' and v' > > > appearing in RA Prefix Information sent by the device violate RFC 486= 1. > > > > > > How is this supposed to be resolved? > > > > > > > > > Setting the ephemeral value has to be valid in the ephermal datastore= . > > > That is a separate datastore and validated differently. > > > See paragraph "Ephemeral' below. > > > Perhaps the "panes of glass" concept has not been explained to you? > > > > Of course it was. You didn=E2=80=99t answer my question though, so let = me expand > my example into the following scenario: > > > > 1. The device boots, values of valid-lifetime and preferred-lifetime in > running are initialized from startup to v and p, respectively, where p < = v. > The device sends RAs with there values, everything=E2=80=99s OK. > > > > 2. I2RS sets the ephemeral value of valid-lifetime to v=E2=80=99 where = p < v=E2=80=99 < > v. The device now sends RAs with p and v=E2=80=99, which is still OK. > > > > 3. A NETCONF client attempts to change preferred-lifetime in running to > p=E2=80=99 where v=E2=80=99 < p=E2=80=99 <=3D v. Should this edit be reje= cted? On one hand, running > continues to be perfectly valid, but on the other hand RAs with values of > p=E2=80=99 and v=E2=80=99 are broken. > > > > > > > > This type of corner case has been discussed. > > The ephemeral state needs to over-write enough of > > the running config to be self-consistent. > > Hmm, so such values become suddenly persistent? And what if running is > locked when this over-write is attempted? Will such chagnes be propagated > to candidate? > > no -- the ephemeral datastore can contain config=3Dtrue nodes. If the ephemeral data had both p and v, then the running config values are not used and not relevant. Tho running config values get used if the ephemeral values are removed. It is quite easy for an operator to mess up by over-riding configured values. YANG validation is going to be slow so probably will be avoided. Only "operator clue" can prevent this sharp knife from killing the network. This looks like a lot of wizardry that tries to hack ephemeral state on top > of the existing NETCONF architecture. > > Lada > > Andy > > > > > > In any case it is OK to set the running config value to > > something that will not be used at the moment. I2RS > > will prevent the running config value of p from being used. > > The ephemeral config has priority over the running config. > > > > > > Lada > > > > Andy > > > > > > > > > > > > > > > > Lada > > > > > > > > > Andy > > > > > > > > > > > > > > Ephemeral: > > > > config=3Dtrue validation done with ephemeral data first, > > > > then running datastore if no matching ephemeral data > > > > (panes of glass) ; validation done at edit-time > > > > > > > > config=3Dephemeral validation done with ephemeral data > > > > and operational state; config=3Dtrue MUST NOT appear > > > > in any ephemeral data node constraint expressions.; > > > > validation done at edit-time; not clear if additional validation > > > > needed whenever any relevant operational state changes. > > > > (Implementation detail how quickly server checks?) > > > > > > > > > > > > > > > > Lada > > > >> > > > >> > > > > > > > > Andy > > > > > > > > > > > >> > > > > >> > Validation rules are needed for ephemeral data. > > > >> > Whether this is part of a protocol spec or YANG needs to be > decided. > > > >> > > > > >> > > > > >> > > > > >> > Lada > > > >> > > > > >> > > > > >> > Andy > > > >> > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > /js > > > >> > > > > > >> > > > > > >> > > Andy > > > >> > > > > > >> > > > > > >> > > -- > > > >> > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > >> > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > Germany > > > >> > > Fax: +49 421 200 3103 < > http://www.jacobs-university.de/> > > > >> > > > > > >> > > > > >> > -- > > > >> > Ladislav Lhotka, CZ.NIC Labs > > > >> > PGP Key ID: E74E8C0C > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > >> -- > > > >> Ladislav Lhotka, CZ.NIC Labs > > > >> PGP Key ID: E74E8C0C > > > >> > > > >> > > > >> > > > >> > > > >> > > > > > > -- > > > Ladislav Lhotka, CZ.NIC Labs > > > PGP Key ID: E74E8C0C > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a11c317e8ddcfe3051ca66c77 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Aug 6, 2015 at 8:40 AM, Ladislav Lhotka <<= a href=3D"mailto:lhotka@nic.cz" target=3D"_blank">lhotka@nic.cz> wrote:

> On 06 Aug 2015, at 17:31, Andy Bierman <andy@yumaworks.com> wrote:
>
>
>
> On Thu, Aug 6, 2015 at 5:50 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> > On 06 Aug 2015, at 13:03, Andy Bierman <andy@yumaworks.com> wrote:
> >
> >
> >
> > On Thu, Aug 6, 2015 at 12:43 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> > Andy Bierman <andy@yumaw= orks.com> writes:
> >
> > > On Mon, Aug 3, 2015 at 11:58 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> > >
> > >>
> > >> > On 03 Aug 2015, at 18:01, Andy Bierman <andy@yumaworks.com> wrote:
> > >> >
> > >> >
> > >> >
> > >> > On Mon, Aug 3, 2015 at 7:48 AM, Ladislav Lhotka <= ;lhotka@nic.cz> wrote:
> > >> >
> > >> > > On 03 Aug 2015, at 16:41, Andy Bierman <andy@yumaworks.com> wrote:
> > >> > >
> > >> > >
> > >> > >
> > >> > > On Mon, Aug 3, 2015 at 2:25 AM, Juergen Schoen= waelder <
> > >> = j.schoenwaelder@jacobs-university.de> wrote:
> > >> > > On Mon, Aug 03, 2015 at 11:06:41AM +0200, Jern= ej Tuljak wrote:
> > >> > > > Juergen Schoenwaelder je 3.8.2015 ob 10:1= 8 napisal:
> > >> > > > >Any description statement in principl= e can do this. We trust that
> > >> sane
> > >> > > > >data model writers won't do bad t= hings. And if they do, we hope that
> > >> > > > >people will not implement and deploy = bad things.
> > >> > > >
> > >> > > > Why not simply make this impossible by en= suring that description
> > >> > > > statements cannot change what has already= been agreed upon in RFC6020
> > >> > > > (aka YANG semantics)? I would have no pro= blem with descriptions being
> > >> > > > normative, if this would be the case.
> > >> > >
> > >> > > You need to define way more clearly what '= YANG semantics' means.
> > >> > >
> > >> > >
> > >> > >
> > >> > > Agreed.=C2=A0 The description-stmt is normativ= e.
> > >> > > It defines implementation requirements for a d= ata node.
> > >> > > It is not used to override other YANG statemen= ts.
> > >> > > However, if the description says "child f= oo must be
> > >> > > greater than the value of bar" that is ju= st as normative
> > >> > > as a must-stmt that says the same thing.
> > >> > >
> > >> > >
> > >> > > > >I continue to see extension statement= s as reusable and (in
> > >> principle)
> > >> > > > >machine readable fragments of descrip= tion statements. From this
> > >> > > > >perspective, it seems odd to make a d= ifference between extensions
> > >> and
> > >> > > > >description statements.
> > >> > > >
> > >> > > > I still disagree that description stateme= nts should be more powerful
> > >> > > > than any other YANG statement.
> > >> > >
> > >> > > What does 'powerful' mean? Time that s= omeone writes concrete text so
> > >> > > we can have a more constructive discussion. > > >> > >
> > >> > >
> > >> > > A YANG description-stmt cannot override the sy= ntax and semantics of
> > >> other YANG
> > >> > > statements.=C2=A0 But is is mandatory and it i= s normative.
> > >> >
> > >> > It=E2=80=99s not only about overriding. For example= , it wouldn=E2=80=99t be good to
> > >> introduce a new data node type though an extension.
> > >> >
> > >> >
> > >> > But isn't that exactly what you are proposing b= y making ephemeral data
> > >> > an extension instead of part of YANG?
> > >>
> > >> It depends on how it would be defined and used. If it is= an extension,
> > >> NETCONF/RESTCONF clients either shouldn=E2=80=99t see it= at all, or they should be
> > >> able to ignore it.
> > >>
> > >> >
> > >> > None of the existing text covers the validation rul= es for ephemeral data.
> > >> > Nothing is needed for config=3Dtrue nodes in the ep= hemeral datastore,
> > >> > but ephemeral-only data needs to be identified.
> > >>
> > >> I think it still has to be clarified how ephemeral data = interact with
> > >> normal config data. Normal semantic validation of config= =3Dtrue data doesn=E2=80=99t
> > >> make much sense to me if some parameters may be override= n by ephemeral
> > >> values.
> > >>
> > >>
> > >
> > > I agree that suitable solutions have been discussed off-line= ,
> > > and the slides from Jeff do not specify how validation would= work.
> > > This is part of the month of work left to do.
> > >
> > > IMO the running datastore and ephemeral datastore have diffe= rent
> > > validation procedures:
> > >
> > > Running:
> > >=C2=A0 =C2=A0 config=3Dtrue validation
> > >=C2=A0 =C2=A0 same as now; no impact from ephemeral datastore=
> > >=C2=A0 =C2=A0 validation done at edit-time
> >
> > I think there has to be an impact - validation of running has to = take
> > into account ephemeral values as long as they are what's oper= ationally
> > used.
> >
>
>
> If an edit would cause the datastore to be invalid,
> then it has to be rejected.
>
>
> >
> >
> >
> > This is completely wrong.
> > Config nodes cannot refer to non-config nodes for validation.
> > Consider the moment when the device boots, and there is
> > no ephemeral data.=C2=A0 Any validation of the startup config
> > that depends on ephemeral data will fail.
>
> If there is no ephemeral data, then config data is what counts. Howeve= r, if some config parameters may be overriden by ephemeral values, then a s= eparate validation of running is not sufficient - it may be in conflict wit= h ephemeral data.
>
> I guess the purpose of semantic rules and validation is to make sure t= he parameters that the device uses, no matter where they come from, are cor= rect.
>
> >
> > The running config must be self-consistent.
> > It never ever relies on ephemeral or operational data
> > for validation.
>
> Ephemeral data is a configuration, too.
>
> It needs to be in a separate datastore so it can be
> validated separately from the running config.
>
>
>
> >
> >
> > For example, take IPv6 RA parameters valid-lifetime and
> > preferred-lifetime as defined in ietf-ipv6-unicast-routing. A mus= t
> > constraint is there to ensure that
> >
> > preferred-lifetime <=3D valid-lifetime
> >
> > Now, assume their values in running are p and v, respectively, bu= t an
> > I2RS client sets an ephemeral value of valid-lifetime to v' w= here
> >
> > v' < v
> >
> > If a NETCONF client changes value of preferred-lifetime to p'= where
> >
> > v' < p' <=3D v
> >
> > then the constraint in running is satisfied but the values p'= and v'
> > appearing in RA Prefix Information sent by the device violate RFC= 4861.
> >
> > How is this supposed to be resolved?
> >
> >
> > Setting the ephemeral value has to be valid in the ephermal datas= tore.
> > That is a separate datastore and validated differently.
> > See paragraph "Ephemeral' below.
> > Perhaps the "panes of glass" concept has not been expla= ined to you?
>
> Of course it was. You didn=E2=80=99t answer my question though, so let= me expand my example into the following scenario:
>
> 1. The device boots, values of valid-lifetime and preferred-lifetime i= n running are initialized from startup to v and p, respectively, where p &l= t; v. The device sends RAs with there values, everything=E2=80=99s OK.
>
> 2. I2RS sets the ephemeral value of valid-lifetime to v=E2=80=99 where= p < v=E2=80=99 < v. The device now sends RAs with p and v=E2=80=99, = which is still OK.
>
> 3. A NETCONF client attempts to change preferred-lifetime in running t= o p=E2=80=99 where v=E2=80=99 < p=E2=80=99 <=3D v. Should this edit b= e rejected? On one hand, running continues to be perfectly valid, but on th= e other hand RAs with values of p=E2=80=99 and v=E2=80=99 are broken.
>
>
>
> This type of corner case has been discussed.
> The ephemeral state needs to over-write enough of
> the running config to be self-consistent.

Hmm, so such values become suddenly persistent? And what if running is lock= ed when this over-write is attempted? Will such chagnes be propagated to ca= ndidate?



no -- the ephemeral dat= astore can contain config=3Dtrue nodes.
If the ephemeral data had= both p and v, then the running config
values are not used and no= t relevant.=C2=A0 Tho running config values
get used if the ephem= eral values are removed.

It is quite easy for an o= perator to mess up by over-riding configured
values.=C2=A0 YANG v= alidation is going to
be slow so probably will be avoided.
<= div>Only "operator clue" can prevent this sharp knife
f= rom killing the network.


This looks like a lot of wizardry that tries to hack ephemeral state on top= of the existing NETCONF architecture.

Lada


Andy
=C2=A0
>
>
> In any case it is OK to set the running config value to
> something that will not be used at the moment.=C2=A0 I2RS
> will prevent the running config value of p from being used.
> The ephemeral config has priority over the running config.
>
>
> Lada
>
> Andy
>
>
> >
> >
> >
> > Lada
> >
> >
> > Andy
> >
> >
> > >
> > > Ephemeral:
> > >=C2=A0 =C2=A0config=3Dtrue validation done with ephemeral dat= a first,
> > >=C2=A0 =C2=A0then running datastore if no matching ephemeral = data
> > >=C2=A0 =C2=A0(panes of glass) ; validation done at edit-time<= br> > > >
> > >=C2=A0 =C2=A0config=3Dephemeral validation done with ephemera= l data
> > >=C2=A0 =C2=A0and operational state; config=3Dtrue MUST NOT ap= pear
> > >=C2=A0 =C2=A0in any ephemeral data node constraint expression= s.;
> > >=C2=A0 =C2=A0validation done at edit-time; not clear if addit= ional validation
> > >=C2=A0 =C2=A0needed whenever any relevant operational state c= hanges.
> > >=C2=A0 (Implementation detail how quickly server checks?)
> > >
> > >
> > >
> > > Lada
> > >>
> > >>
> > >
> > > Andy
> > >
> > >
> > >> >
> > >> > Validation rules are needed for ephemeral data.
> > >> > Whether this is part of a protocol spec or YANG nee= ds to be decided.
> > >> >
> > >> >
> > >> >
> > >> > Lada
> > >> >
> > >> >
> > >> > Andy
> > >> >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > > /js
> > >> > >
> > >> > >
> > >> > > Andy
> > >> > >
> > >> > >
> > >> > > --
> > >> > > 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<http://www.jacobs-university.de/><= br> > > >> > >
> > >> >
> > >> > --
> > >> > Ladislav Lhotka, CZ.NIC Labs
> > >> > PGP Key ID: E74E8C0C
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >>
> > >> --
> > >> Ladislav Lhotka, CZ.NIC Labs
> > >> PGP Key ID: E74E8C0C
> > >>
> > >>
> > >>
> > >>
> > >>
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C

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





--001a11c317e8ddcfe3051ca66c77-- From nobody Thu Aug 6 08:53:38 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 265CD1B2FE4 for ; Thu, 6 Aug 2015 08:53:37 -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 SDC1KKcPR8TR for ; Thu, 6 Aug 2015 08:53:33 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AD431B2F93 for ; Thu, 6 Aug 2015 08:53:33 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 42EDE10B6; Thu, 6 Aug 2015 17:53:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id MMAYyR1hxbZS; Thu, 6 Aug 2015 17:53:30 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 6 Aug 2015 17:53:30 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id CB2F020048; Thu, 6 Aug 2015 17:53:30 +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 EOuk8qIpvOWz; Thu, 6 Aug 2015 17:53:29 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F12082004E; Thu, 6 Aug 2015 17:53:28 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3F089360B2EA; Thu, 6 Aug 2015 17:53:25 +0200 (CEST) Date: Thu, 6 Aug 2015 17:53:25 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20150806155325.GA80464@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , Jernej Tuljak , Martin =?iso-8859-1?Q?Bj=F6rklund?= , "netmod@ietf.org" References: <55BF2F21.1070900@mg-soft.si> <20150803092501.GB71565@elstar.local> <646276CA-ED9B-40D1-8613-4F0FD6DD69BE@nic.cz> <60C5B0D3-47C0-4748-95EA-1976C9EBE508@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: <60C5B0D3-47C0-4748-95EA-1976C9EBE508@nic.cz> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Jernej Tuljak , "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 15:53:37 -0000 On Thu, Aug 06, 2015 at 02:50:04PM +0200, Ladislav Lhotka wrote: > > > If there is no ephemeral data, then config data is what counts. However, if some config parameters may be overriden by ephemeral values, then a separate validation of running is not sufficient - it may be in conflict with ephemeral data. > > I guess the purpose of semantic rules and validation is to make sure the parameters that the device uses, no matter where they come from, are correct. > So far, validation concerns a configuration data store, no more and no less. Expanding this to something different will be a major change how the curent protocol and its implementations work. > Of course it was. You didn’t answer my question though, so let me expand my example into the following scenario: > > 1. The device boots, values of valid-lifetime and preferred-lifetime in running are initialized from startup to v and p, respectively, where p < v. The device sends RAs with there values, everything’s OK. > > 2. I2RS sets the ephemeral value of valid-lifetime to v’ where p < v’ < v. The device now sends RAs with p and v’, which is still OK. > > 3. A NETCONF client attempts to change preferred-lifetime in running to p’ where v’ < p’ <= v. Should this edit be rejected? On one hand, running continues to be perfectly valid, but on the other hand RAs with values of p’ and v’ are broken. The running config is valid. I think it is today an implementation issue how any conflicts with other dynamic information are resolved (e.g., whether the running config in this case overwrites or deletes the now broken ephemeral value or whether the NC server signals a runtime error while processing the edit-config - which would not be a validation error). We currently understand what a valid configuration datastore means. This is goodness and we should work hard to preserve this. When we add ephemeral configuration datastores, it is not clear what it means for them to be valid or whether we also have to think in addition in terms of validation of the resulting 'merged datastore'. Some people also wanted to allow references from ephemeral configuration data to operational state data, which adds another dimension of complexity to the picture. All I can say at this point in time is that the precise semantics of validation of ephemeral data are rather unclear to me. And there may also be a risk to define validation semantics that at the end nobody will implement fully because it does not scale (e.g., because it requires to monitor significant amounts of operational state to detect changes that trigger re-validation). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Aug 6 09:03:16 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E392C1B3AD0 for ; Thu, 6 Aug 2015 09:03: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 mhR7-srbUkVp for ; Thu, 6 Aug 2015 09:03: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 9F0301B3ACF for ; Thu, 6 Aug 2015 09:03: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 69F9610CB; Thu, 6 Aug 2015 18:03:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id cpAsLfwB8_ia; Thu, 6 Aug 2015 18:03:11 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 6 Aug 2015 18:03:11 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id AB9952004E; Thu, 6 Aug 2015 18:03:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Vtfv8HyjAmxc; Thu, 6 Aug 2015 18:03: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 D1B3D20048; Thu, 6 Aug 2015 18:03:09 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5F1A5360B37D; Thu, 6 Aug 2015 18:03:07 +0200 (CEST) Date: Thu, 6 Aug 2015 18:03:06 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20150806160305.GC80464@elstar.local> Mail-Followup-To: Andy Bierman , Ladislav Lhotka , Jernej Tuljak , Martin =?iso-8859-1?Q?Bj=F6rklund?= , "netmod@ietf.org" References: <646276CA-ED9B-40D1-8613-4F0FD6DD69BE@nic.cz> <60C5B0D3-47C0-4748-95EA-1976C9EBE508@nic.cz> <2DBDE99A-0138-439E-B8DD-EB9ED12069ED@nic.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Jernej Tuljak , "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 16:03:15 -0000 On Thu, Aug 06, 2015 at 08:46:39AM -0700, Andy Bierman wrote: > > If the ephemeral data had both p and v, then the running config > values are not used and not relevant. Tho running config values > get used if the ephemeral values are removed. > If the ephemeral datastore uses the same data model as the configuration datastores, you will mostly likely only be able to have _both_ p and v in the ephemeral datastore. It is likely goodness to keep certain restrictions alive instead of allowing arbitrary selective overwrites. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Aug 6 09:21:51 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D81861B3B83 for ; Thu, 6 Aug 2015 09:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.078 X-Spam-Level: X-Spam-Status: No, score=-1.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6t_KeGAN7gCq for ; Thu, 6 Aug 2015 09:21:49 -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 3CB871B3B80 for ; Thu, 6 Aug 2015 09:21:49 -0700 (PDT) Received: by labow3 with SMTP id ow3so52519274lab.1 for ; Thu, 06 Aug 2015 09:21:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=TN9tWKmHuCZtLOEiQUcWXQ0SLgr5IP1PSio+ziGffm4=; b=almp3fTSD3+hdR6bmtX3zTjBjnOjELjGc7W202Oug+T4wqQNI3X+Nknn38CLtdCh71 4LrHBLvZk6eLJ1dTzhKFM+eQ1qPtmAL8v8VEYsd0+27yN0H0D3pMgDqYCRb4jwuKITBe boaB3o8EojOZlU55RJgCD1dz7XE6J0agb8j/5o8yHt6O/tJ303VXu0sM6xznaositGfh EeDcFulkMVNAMxzBN2hv4WyC8KQ9BD5aRqIe6Zc0o5siAR4N316ixEwAMlWbnkTdFtG7 oGM+CrOTJ/mmjJWhnVHZIOW5YoEwwGt5y/7Vok9tE57HAXdUlsPZaAGRqjtaL0r+N4u5 OsZQ== X-Gm-Message-State: ALoCoQn9gz6Of3h+LlAbyswZp9ecdYRByMQSW1+diyMekEBLvUdn0qj0OzqxvSTU3xIsJfX/0RKf MIME-Version: 1.0 X-Received: by 10.112.234.163 with SMTP id uf3mr2986985lbc.37.1438878107575; Thu, 06 Aug 2015 09:21:47 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Thu, 6 Aug 2015 09:21:47 -0700 (PDT) In-Reply-To: <20150806160305.GC80464@elstar.local> References: <646276CA-ED9B-40D1-8613-4F0FD6DD69BE@nic.cz> <60C5B0D3-47C0-4748-95EA-1976C9EBE508@nic.cz> <2DBDE99A-0138-439E-B8DD-EB9ED12069ED@nic.cz> <20150806160305.GC80464@elstar.local> Date: Thu, 6 Aug 2015 09:21:47 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Ladislav Lhotka , Jernej Tuljak , =?UTF-8?Q?Martin_Bj=C3=B6rklund?= , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11c317e87a3f8f051ca6ea87 Archived-At: Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 16:21:51 -0000 --001a11c317e87a3f8f051ca6ea87 Content-Type: text/plain; charset=UTF-8 On Thu, Aug 6, 2015 at 9:03 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Thu, Aug 06, 2015 at 08:46:39AM -0700, Andy Bierman wrote: > > > > If the ephemeral data had both p and v, then the running config > > values are not used and not relevant. Tho running config values > > get used if the ephemeral values are removed. > > > > If the ephemeral datastore uses the same data model as the > configuration datastores, you will mostly likely only be able to have > _both_ p and v in the ephemeral datastore. > > It is likely goodness to keep certain restrictions alive instead of > allowing arbitrary selective overwrites. > > It is up to the operator to make sure of these things. It might be possible to come up with YANG statements to help, but might not be worth the effort. I agree that config=true datastore validation needs to be preserved. The ephemeral datastore has different "default" rules than other datastores. Normally, a missing node is either a YANG default or nothing. In the ephemeral datastore, a missing node is first the corresponding node in the running config, and then the YANG default if nothing in running to match. I think these validation rules would work for config=true nodes in the ephemeral daatstore. Validation of config=ephemeral nodes in the ephemeral datastore is still a bit unclear. I have asked some routing experts for examples of ephemeral data that needs to reference operational state. > /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --001a11c317e87a3f8f051ca6ea87 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Aug 6, 2015 at 9:03 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Thu, Aug 06, 2015 at 08:46:39AM -0700, Andy Bierma= n wrote:
>
> If the ephemeral data had both p and v, then the running config
> values are not used and not relevant.=C2=A0 Tho running config values<= br> > get used if the ephemeral values are removed.
>

If the ephemeral datastore uses the same data model as the
configuration datastores, you will mostly likely only be able to have
_both_ p and v in the ephemeral datastore.

It is likely goodness to keep certain restrictions alive instead of
allowing arbitrary selective overwrites.


It is up to the operator to make sure of these thing= s.
It might be possible to come up with YANG statements
to help, but might not be worth the effort.

I agr= ee that config=3Dtrue datastore validation needs to be preserved.

The ephemeral datastore has different "default" r= ules than other datastores.
Normally, a missing node is either a = YANG default or nothing.
In the ephemeral datastore, a missing no= de is first the corresponding
node in the running config, and the= n the YANG default if nothing
in running to match.=C2=A0 I think = these validation rules would work for
config=3Dtrue nodes in the = ephemeral daatstore.

Validation of config=3Depheme= ral nodes in the ephemeral datastore
is still a bit unclear.=C2= =A0 I have asked some routing experts for examples
of ephemeral d= ata that needs to reference operational state.

=C2=A0
/js

Andy
=C2=A0=

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

--001a11c317e87a3f8f051ca6ea87-- From nobody Thu Aug 6 12:03:58 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 819F51B2DB4 for ; Thu, 6 Aug 2015 12:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.91 X-Spam-Level: X-Spam-Status: No, score=-8.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 IyMZOfW_I5IE for ; Thu, 6 Aug 2015 12:03:55 -0700 (PDT) Received: from sjmda16.webex.com (sjmda16.webex.com [64.68.124.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24E321B2D9F for ; Thu, 6 Aug 2015 12:03:55 -0700 (PDT) Received: from jva2tc202.webex.com (sjc02-wxp00-lbace03-core-vl120-np10-4.webex.com [64.68.121.248]) by sjmda16.webex.com (Postfix) with ESMTP id D2CD4A31B6 for ; Thu, 6 Aug 2015 19:03:54 +0000 (GMT) Received: from jva2tc202.webex.com (localhost [127.0.0.1]) by jva2tc202.webex.com (Postfix) with ESMTP id 928D640CD5 for ; Thu, 6 Aug 2015 19:03:54 +0000 (GMT) Date: Thu, 6 Aug 2015 19:03:54 +0000 (GMT) From: NETMOD Working Group To: netmod@ietf.org Message-ID: <1516231808.93378.1438887834598.JavaMail.nobody@jva2tc202.webex.com> MIME-Version: 1.0 Content-Type: multipart/Mixed; boundary="----=_Part_93376_1270781918.1438887834597" X-Priority: 3 Importance: normal Archived-At: Subject: [netmod] WebEx meeting invitation: NETMOD Interm meeting on OpenConfig X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: netmod-chairs@tools.ietf.org List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 19:03:56 -0000 ------=_Part_93376_1270781918.1438887834597 Content-Type: multipart/Alternative; boundary="----=_Part_93377_1306826411.1438887834597" ------=_Part_93377_1306826411.1438887834597 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: base64 CkhlbGxvLAoKTkVUTU9EIFdvcmtpbmcgR3JvdXAgaW52aXRlcyB5b3UgdG8gam9pbiB0aGlzIFdl YkV4IG1lZXRpbmcuCgoKTkVUTU9EIEludGVybSBtZWV0aW5nIG9uIE9wZW5Db25maWcKVGh1cnNk YXksIFNlcHRlbWJlciAxMCwgMjAxNQoxMTowMCBhbSAgfCAgRWFzdGVybiBEYXlsaWdodCBUaW1l IChOZXcgWW9yaywgR01ULTA0OjAwKSAgfCAgMSBocgoKCkpPSU4gV0VCRVggTUVFVElORwpodHRw czovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tNTRjN2JjYmVkODRhMDhkYzc4ZmJh MTI4ZDUwMGY4YzAKTWVldGluZyBudW1iZXI6IDY0NSA3MzIgMjc3Ck1lZXRpbmcgcGFzc3dvcmQ6 IDEyMzQKCg0KSk9JTiBCWSBQSE9ORQ0KMS04NzctNjY4LTQ0OTMgQ2FsbC1pbiB0b2xsIGZyZWUg bnVtYmVyIChVUy9DYW5hZGEpIAoxLTY1MC00NzktMzIwOCBDYWxsLWluIHRvbGwgbnVtYmVyIChV Uy9DYW5hZGEpCkFjY2VzcyBjb2RlOiA2NDUgNzMyIDI3NwoKVG9sbC1mcmVlIGRpYWxpbmcgcmVz dHJpY3Rpb25zOiAKaHR0cDovL3d3dy53ZWJleC5jb20vcGRmL3RvbGxmcmVlX3Jlc3RyaWN0aW9u cy5wZGYNCg0KCkFkZCB0aGlzIG1lZXRpbmcgdG8geW91ciBjYWxlbmRhcjoKaHR0cHM6Ly9pZXRm LndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTE3MDg2ZDZiOTgxMGEyNzIyYzVkYzhjNjRlYzc5 NWI5DQoNCgpDYW4ndCBqb2luIHRoZSBtZWV0aW5nPyBDb250YWN0IHN1cHBvcnQgaGVyZToKaHR0 cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL21jCgoKSU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5v dGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1h dGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJl IGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24s IHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5b3UgZG8g bm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRpc2N1c3MgeW91ciBjb25jZXJucyB3aXRo IHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLgo= ------=_Part_93377_1306826411.1438887834597 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPjxtZXRhIG5hbWU9InZpZXdwb3J0IiBjb250ZW50PSJ3aWR0aD1kZXZpY2Utd2lk dGgsIGluaXRpYWwtc2NhbGU9MSIgLz48Ym9keT48c3R5bGUgdHlwZT0idGV4dC9jc3MiPgpkaXYs cCx0ZCxzcGFuIHt3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7d29yZC1icmVhazogbm9ybWFsO30KCnRh YmxlIHtib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyBib3JkZXI6IDA7Ym9yZGVyLXNwYWNpbmc6 IDA7Ym9yZGVyLWNvbG9yOiB3aGl0ZTsgd2lkdGg6MTAwJSFpbXBvcnRhbnQ7d2lkdGg6NTI1cHg7 IG1heC13aWR0aDo1MjVweCFpbXBvcnRhbnQ7IG1pbi13aWR0aDogMjc5cHghaW1wb3J0YW50O30K dHIge2xpbmUtaGVpZ2h0OiAyMHB4O30KCnRkLGEge2ZvbnQtc2l6ZTogMTVweDtmb250LWZhbWls eTogQXJpYWw7Y29sb3I6ICM2NjY2NjY7cGFkZGluZzowO30KPC9zdHlsZT4KCjx0YWJsZSBzdHls ZT0icGFkZGluZzowOyBtYXJnaW46MCIgd2lkdGg9IjEwMCUiIGFsaWduPSJsZWZ0Ij4KICAgPHRy PgogICAgICA8dGQgc3R5bGU9InBhZGRpbmctdG9wOjVweDsiPgogICAgICAgIDx0YWJsZSBzdHls ZT0id2lkdGg6IDUyNXB4O21hcmdpbi1sZWZ0OjVweCIgYWxpZ249ImxlZnQiPgoJCQk8dHI+CgkJ CQk8dGQgdmFsaWduPSJ0b3AiPgoKPHRhYmxlPgogICAgICAgPHRyPgogICAgICAgICAgPHRkIHN0 eWxlPSJmb250LXNpemU6IDE1cHg7Zm9udC1mYW1pbHk6IEFyaWFsO2NvbG9yOiM0RDRENEQiPgog ICAgICAgICAgICAgSGVsbG8sCiAgICAgICAgICA8L3RkPgogICAgICAgPC90cj4KICAgICAgIDx0 cj4KICAgICAgICAgICA8dGQgc3R5bGU9ImZvbnQtc2l6ZTogMTVweDtmb250LWZhbWlseTogQXJp YWw7Y29sb3I6IzRENEQ0RDtwYWRkaW5nLXRvcDoxMHB4OyI+CiAgICAgICAgICAgICAgICBORVRN T0QgV29ya2luZyBHcm91cCBpbnZpdGVzIHlvdSB0byBqb2luIHRoaXMgV2ViRXggbWVldGluZy4K ICAgICAgICAgICAgICAgIAkgICAgICAgICAgIDwvdGQ+CiAgICAgIDwvdHI+CjwvdGFibGU+CgoK Cgo8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0 OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPgoJCQkJCQk8dGFibGUgIHdpZHRoPSIxMDAl Ij4KCQkJCQkJCTx0cj4KCQkJCQkJCQk8dGQgc3R5bGU9ImZvbnQtc2l6ZToxNnB4OyBjb2xvcjoj NEQ0RDREIj4KCQkJCQkJCQkJPGI+TkVUTU9EIEludGVybSBtZWV0aW5nIG9uIE9wZW5Db25maWc8 L2I+CgkJCQkJCQkJPC90ZD4KCQkJCQkJCTwvdHI+CgkJCQkJCQk8dHIgc3R5bGU9Im1hcmdpbjow cHgiPgoJCQkJCQkJCTx0ZD5UaHVyc2RheSwgU2VwdGVtYmVyIDEwLCAyMDE1CgkJCQkJCQkJPC90 ZD4KCQkJCQkJCTwvdHI+CgkJCQkJCQk8dHIgc3R5bGU9Im1hcmdpbjowcHgiPgoJCQkJCQkJCTx0 ZD4xMTowMCBhbSZuYnNwOyZuYnNwO3wmbmJzcDsmbmJzcDtFYXN0ZXJuIERheWxpZ2h0IFRpbWUg KE5ldyBZb3JrLCBHTVQtMDQ6MDApJm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNwOzEgaHIKCQkJCQkJ CQk8L3RkPgoJCQkJCQkJPC90cj4KCQkJCQkJPC90YWJsZT4KCjx0YWJsZT48dHIgc3R5bGU9Imxp bmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3Ry PjwvdGFibGU+CgkJCQkJCTx0YWJsZSBzdHlsZT0id2lkdGg6YXV0bzsgd2lkdGg6YXV0byFpbXBv cnRhbnQiPgoJCQkJCQkJPHRyPgoJCQkJCQkJCTx0ZCBzdHlsZT0iY29sb3I6IzAwQUZGOTtmb250 LXNpemU6MTZweCI+CgkJCQkJCQkJCTxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0 Zi9qLnBocD9NVElEPW01NGM3YmNiZWQ4NGEwOGRjNzhmYmExMjhkNTAwZjhjMCIKCQkJCQkJCQkJ CXN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZTtmb250LXNpemU6MTZweDtjb2xvcjojMDBBRkY5 Ij4KCQkJCQkJCQkJCTxiPkpvaW4gV2ViRXggbWVldGluZzwvYj4KCQkJCQkJCQkJPC9hPgoJCQkJ CQkJCTwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJCQk8L3RhYmxlPgoJCQkJCQk8dGFibGUgc3R5bGU9 IndpZHRoOmF1dG87IHdpZHRoOmF1dG8haW1wb3J0YW50Ij4KCQkJCQkJCTx0ciBzdHlsZT0ibWFy Z2luOjBweCI+CgkJCQkJCQkJPHRkIHN0eWxlPSJwYWRkaW5nLXJpZ2h0OiA1cHg7Ij4KCQkJCQkJ CQkJTWVldGluZyBudW1iZXI6CgkJCQkJCQkJPC90ZD4KCQkJCQkJCQk8dGQ+NjQ1IDczMiAyNzcK CQkJCQkJCQk8L3RkPgoJCQkJCQkJPC90cj4KCQkJCQkJCTx0cj4KCQkJCQkJCQk8dGQgc3R5bGU9 InBhZGRpbmctcmlnaHQ6IDVweDsiPk1lZXRpbmcgcGFzc3dvcmQ6PC90ZD4KCQkJCQkJCQk8dGQ+ MTIzNDwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJCQk8L3RhYmxlPgoKCgoJCgoJPHRhYmxlPjx0ciBz dHlsZT0ibGluZS1oZWlnaHQ6MjBweCI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90 ZD48L3RyPjwvdGFibGU+PHRhYmxlPjx0cj48dGQgc3R5bGU9ImZvbnQtc2l6ZToxNnB4Ij48Yj5K b2luIGJ5IHBob25lPC9iPjwvdGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZD48Yj4x LTg3Ny02NjgtNDQ5MzwvYj4mbmJzcDtDYWxsLWluIHRvbGwgZnJlZSBudW1iZXIgKFVTL0NhbmFk YSk8L3RkPjwvdHI+PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij48dGQ+PGI+MS02NTAtNDc5LTMyMDg8 L2I+Jm5ic3A7Q2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKTwvdGQ+PC90cj48dHIgc3R5 bGU9Im1hcmdpbjowcHgiPjx0ZD5BY2Nlc3MgY29kZTombmJzcDs2NDUgNzMyIDI3NzwvdGQ+PC90 cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZD48YSBocmVmPSJodHRwOi8vd3d3LndlYmV4LmNv bS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBkZiIgc3R5bGU9InRleHQtZGVjb3JhdGlvbjpu b25lO2ZvbnQtc2l6ZToxM3B4O2NvbG9yOiMwMEFGRjk7Ij5Ub2xsLWZyZWUgY2FsbGluZyByZXN0 cmljdGlvbnM8L2E+PC90ZD48L3RyPjwvdGFibGU+CgoJCQkJCTx0YWJsZT48dHIgc3R5bGU9Imxp bmUtaGVpZ2h0OjIwcHgiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48 L3RhYmxlPjx0YWJsZT48dHI+PHRkIHN0eWxlPSJmb250LXNpemU6MTNweCI+PGEgaHJlZj0iaHR0 cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTE3MDg2ZDZiOTgxMGEyNzIyYzVk YzhjNjRlYzc5NWI5IiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7Y29sb3I6IzAwQUZGOTsg Zm9udC1zaXplOjEzcHgiPkFkZCB0aGlzIG1lZXRpbmc8L2E+IHRvIHlvdXIgY2FsZW5kYXIuPC90 ZD48L3RyPjwvdGFibGU+Cjx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRk IHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+Cjx0YWJsZT4KICAg IDx0cj4KICAgICAgIDx0ZCBzdHlsZT0iZm9udC1zaXplOiAxM3B4O2ZvbnQtZmFtaWx5OiBBcmlh bDtjb2xvcjogIzY2NjY2NjsiPgogICAgICAgIENhbid0IGpvaW4gdGhlIG1lZXRpbmc/CiAgICAg CTxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9tYyIgc3R5bGU9InRleHQtZGVj b3JhdGlvbjpub25lO2ZvbnQtc2l6ZToxM3B4O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOiMwMEFG Rjk7Zm9udC1jb2xvcjojMDBBRkY5OyI+CiAgICAgICAgCUNvbnRhY3Qgc3VwcG9ydC48L2E+CgkJ PC90ZD4KICAgIDwvdHI+CjwvdGFibGU+Cjx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAx MHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MTBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+CgkJ CQkJCTx0YWJsZT4KCQkJCQkJCTx0cj4KCQkJCQkJCQk8dGQgc3R5bGU9ImZvbnQtc2l6ZToxMnB4 O2NvbG9yOiAjQTBBMEEwOyI+CgkJCQkJCQkJCUlNUE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3Rl IHRoYXQgdGhpcyBXZWJFeCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRp b24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBk aXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5 b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5v dCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0 aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi48L3RkPgoJCQkJCQkJPC90cj4KCQkJ CQkJPC90YWJsZT4KCQkJCTwvdGQ+CgkJCTwvdHI+CgkJPC90YWJsZT4KCTwvdGQ+CiAgIDwvdHI+ CjwvdGFibGU+Cgo8L2JvZHk+ ------=_Part_93377_1306826411.1438887834597-- ------=_Part_93376_1270781918.1438887834597 Content-Type: application/octet-stream; name="WebEx_Meeting.ics" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="WebEx_Meeting.ics" QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP TkUKVFpJRDpFYXN0ZXJuIFRpbWUKQkVHSU46U1RBTkRBUkQKRFRTVEFSVDoyMDEzMTEwMVQwMjAw MDAKUlJVTEU6RlJFUT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0xU1U7QllNT05USD0xMQpUWk9G RlNFVEZST006LTA0MDAKVFpPRkZTRVRUTzotMDUwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDEzMDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0yU1U7QllNT05USD0zClRaT0ZGU0VURlJPTTotMDUw MApUWk9GRlNFVFRPOi0wNDAwClRaTkFNRTpEYXlsaWdodCBTYXZpbmdzIFRpbWUKRU5EOkRBWUxJ R0hUCkVORDpWVElNRVpPTkUKQkVHSU46VkVWRU5UCkFUVEVOREVFO0NOPSIiO1JPTEU9UkVRLVBB UlRJQ0lQQU5UO1JTVlA9VFJVRTpNQUlMVE86bmV0bW9kQGlldGYub3JnCk9SR0FOSVpFUjtDTj0i TkVUTU9EIFdvcmtpbmcgR3JvdXAiOk1BSUxUTzpuZXRtb2QtY2hhaXJzQHRvb2xzLmlldGYub3Jn CkRUU1RBUlQ7VFpJRD0iRWFzdGVybiBUaW1lIjoyMDE1MDkxMFQxMTAwMDAKRFRFTkQ7VFpJRD0i RWFzdGVybiBUaW1lIjoyMDE1MDkxMFQxMjAwMDAKTE9DQVRJT046aHR0cHM6Ly9pZXRmLndlYmV4 LmNvbS9pZXRmClRSQU5TUDpPUEFRVUUKU0VRVUVOQ0U6MTQzODg4NzgzNApVSUQ6MDM0MDY0YzIt ZTBkZi00Yjk2LTg0YzQtZGMzNmRkZmI2ZDM3CkRUU1RBTVA6MjAxNTA5MTBUMTUwMDAwWgpERVND UklQVElPTjpcblxuXG5KT0lOIFdFQkVYIE1FRVRJTkdcbmh0dHBzOi8vaWV0Zi53ZWJleC5jb20v aWV0Zi9qLnBocD9NVElEPW1iMTU0MDY3Y2QyZjBiZTdjMDY2ZGMxMjc2NDliMjRhMlxuTWVldGlu ZyBudW1iZXI6IDY0NSA3MzIgMjc3XG5NZWV0aW5nIHBhc3N3b3JkOiAxMjM0XG5cblxuSk9JTiBC WSBQSE9ORVxuMS04NzctNjY4LTQ0OTMgQ2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChVUy9DYW5h ZGEpIFxuMS02NTAtNDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKVxuQWNj ZXNzIGNvZGU6IDY0NSA3MzIgMjc3XG5cblRvbGwtZnJlZSBkaWFsaW5nIHJlc3RyaWN0aW9uczog XG5odHRwOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBkZlxuXG5c blxuQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz8gQ29udGFjdCBzdXBwb3J0IGhlcmU6XG5odHRwczov L2lldGYud2ViZXguY29tL2lldGYvbWNcblxuXG5JTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90 ZSB0aGF0IHRoaXMgV2ViRXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0 aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUg ZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwg eW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBu b3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGgg dGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uXG4KWC1BTFQtREVTQztGTVRUWVBF PXRleHQvaHRtbDoJPEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxCUj4gPEZPTlQg U0laRT0iNCIgRkFDRT0iQVJJQUwiPgkJPGEJCQkJCWhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5j b20vaWV0Zi9qLnBocD9NVElEPW1iMTU0MDY3Y2QyZjBiZTdjMDY2ZGMxMjc2NDliMjRhMiI+PEZP TlQgU0laRT0iMyIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9IkFyaWFsIj5Kb2luIFdlYkV4IG1lZXRp bmc8L0ZPTlQ+PC9hPgkJCTx0YWJsZT4JCQkJPHRyPgkJCQkJPHRkPgkJCQkJCTxGT05UIFNJWkU9 IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBudW1iZXI6PC9GT05UPgkJ CQkJPC90ZD4JCQkJCTx0ZD4JCQkJCQk8Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFD RT0iYXJpYWwiPjY0NSA3MzIgMjc3PC9GT05UPgkJCQkJPC90ZD4JCQkJPC90cj4JCQk8L3RhYmxl PgkJCTx0YWJsZT48dHI+PHRkPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJh cmlhbCI+TWVldGluZyBwYXNzd29yZDo8L0ZPTlQ+PC90ZD48dGQ+PEZPTlQgU0laRT0iMiIgIENP TE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+MTIzNDwvRk9OVD48L3RkPjwvdHI+PC90YWJsZT4J CTwvRk9OVD48Rk9OVCBTSVpFPSIxIiBGQUNFPSJBUklBTCI+Jm5ic3A7PEJSPiZuYnNwOzxCUj48 L0ZPTlQ+PEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9IjMiIENPTE9SPSIj NjY2NjY2IiBGQUNFPSJhcmlhbCI+Sm9pbiBieSBwaG9uZTwvRk9OVD4mbmJzcDsgPEJSPjxGT05U IFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+PHN0cm9uZz4xLTg3Ny02Njgt NDQ5Mzwvc3Ryb25nPiZuYnNwO0NhbGwtaW4gdG9sbCBmcmVlIG51bWJlciAoVVMvQ2FuYWRhKTwv Rk9OVD4mbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlh bCI+PHN0cm9uZz4xLTY1MC00NzktMzIwODwvc3Ryb25nPiZuYnNwO0NhbGwtaW4gdG9sbCBudW1i ZXIgKFVTL0NhbmFkYSk8L0ZPTlQ+Jm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2 NjY2NiIgRkFDRT0iYXJpYWwiPkFjY2VzcyBjb2RlOiA2NDUgNzMyIDI3NzwvRk9OVD4mbmJzcDsg PEJSPjxhIGhyZWY9Imh0dHA6Ly93d3cud2ViZXguY29tL3BkZi90b2xsZnJlZV9yZXN0cmljdGlv bnMucGRmIj48Rk9OVCBTSVpFPSIxIiBDT0xPUj0iIzAwQUZGOSIgRkFDRT0iYXJpYWwiPlRvbGwt ZnJlZSBjYWxsaW5nIHJlc3RyaWN0aW9uczwvRk9OVD48L2E+ICZuYnNwOyA8QlI+PC9GT05UPjxC Uj48QlI+CSZuYnNwOzxCUj4JPEZPTlQgU0laRT0iMSIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFy aWFsIj4JCQkJQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz88L0ZPTlQ+CTxhIGhyZWY9Imh0dHBzOi8v aWV0Zi53ZWJleC5jb20vaWV0Zi9tYyI+CTxGT05UIFNJWkU9IjEiIENPTE9SPSIjMDBBRkY5IiBG QUNFPSJBcmlhbCI+Q29udGFjdCBzdXBwb3J0LjwvRk9OVD48L2E+CSZuYnNwOzxCUj4mbmJzcDs8 QlI+PEZPTlQgQ09MT1I9IiNBMEEwQTAiIHNpemU9IjEiIEZBQ0U9ImFyaWFsIj5JTVBPUlRBTlQg Tk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViRXggc2VydmljZSBhbGxvd3MgYXVkaW8g YW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29y ZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2lu aW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29y ZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5 b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uPC9G T05UPjwvRk9OVD4KU1VNTUFSWTpORVRNT0QgSW50ZXJtIG1lZXRpbmcgb24gT3BlbkNvbmZpZwpQ UklPUklUWTo1CkNMQVNTOlBVQkxJQwpCRUdJTjpWQUxBUk0KVFJJR0dFUjotUFQ1TQpBQ1RJT046 RElTUExBWQpERVNDUklQVElPTjpSZW1pbmRlcgpFTkQ6VkFMQVJNCkVORDpWRVZFTlQKRU5EOlZD QUxFTkRBUgo= ------=_Part_93376_1270781918.1438887834597-- From nobody Thu Aug 6 23:32:18 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 864441B31D1; Thu, 6 Aug 2015 23:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z92rdqSniZ7B; Thu, 6 Aug 2015 23:32:15 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 737741B31CD; Thu, 6 Aug 2015 23:32:15 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E01828EB; Fri, 7 Aug 2015 08:32:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id K0ycAeBiVohP; Fri, 7 Aug 2015 08:32:13 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 7 Aug 2015 08:32:13 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 310C92004E; Fri, 7 Aug 2015 08:32:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id JrDpSP5zce8K; Fri, 7 Aug 2015 08:32: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 A4F8020048; Fri, 7 Aug 2015 08:32:11 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D371B362023A; Fri, 7 Aug 2015 08:32:06 +0200 (CEST) Date: Fri, 7 Aug 2015 08:32:05 +0200 From: Juergen Schoenwaelder To: iesg-secretary@ietf.org Message-ID: <20150807063205.GA75724@elstar.local> Mail-Followup-To: iesg-secretary@ietf.org, netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod@ietf.org Subject: [netmod] NETMOD WG YANG 1.1 virtual interim meetings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 06:32:17 -0000 The NETMOD WG will hold a series of weekly virtual interim meetings in order to resolve YANG 1.1 review comments. The meetings will take place on Mondays between 17:00-18:00 CEST. The dates for the virtual meetings are: 2015-08-24 2015-08-31 2015-09-07 2015-09-14 2015-09-21 2015-09-28 2015-10-05 2015-10-12 We will use the meeting slots as needed (i.e., we may skip slots if there is nothing to resolve anymore). Additional information will be announced on the NETMOD mailing list: http://www.ietf.org/mail-archive/web/netmod/current/maillist.html /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 Aug 7 05:26:38 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3201B2BF9 for ; Fri, 7 Aug 2015 05:26:38 -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 r7IwA065rzZM for ; Fri, 7 Aug 2015 05:26:35 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 343E11B2BE2 for ; Fri, 7 Aug 2015 05:26:35 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id DB98B1CC0383; Fri, 7 Aug 2015 14:26:36 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20150806155325.GA80464@elstar.local> References: <55BF2F21.1070900@mg-soft.si> <20150803092501.GB71565@elstar.local> <646276CA-ED9B-40D1-8613-4F0FD6DD69BE@nic.cz> <60C5B0D3-47C0-4748-95EA-1976C9EBE508@nic.cz> <20150806155325.GA80464@elstar.local> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Fri, 07 Aug 2015 14:26:32 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Jernej Tuljak , "netmod@ietf.org" Subject: Re: [netmod] new YANG 1.1 Issue Y61: I2RS support X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 12:26:38 -0000 Juergen Schoenwaelder writes: > On Thu, Aug 06, 2015 at 02:50:04PM +0200, Ladislav Lhotka wrote: >>=20 >>=20 >> If there is no ephemeral data, then config data is what counts. However,= if some config parameters may be overriden by ephemeral values, then a sep= arate validation of running is not sufficient - it may be in conflict with = ephemeral data. >>=20 >> I guess the purpose of semantic rules and validation is to make sure the= parameters that the device uses, no matter where they come from, are corre= ct. >> > > So far, validation concerns a configuration data store, no more and no > less. Expanding this to something different will be a major change how > the curent protocol and its implementations work. > >> Of course it was. You didn=E2=80=99t answer my question though, so let m= e expand my example into the following scenario: >>=20 >> 1. The device boots, values of valid-lifetime and preferred-lifetime in = running are initialized from startup to v and p, respectively, where p < v.= The device sends RAs with there values, everything=E2=80=99s OK. >>=20 >> 2. I2RS sets the ephemeral value of valid-lifetime to v=E2=80=99 where p= < v=E2=80=99 < v. The device now sends RAs with p and v=E2=80=99, which is= still OK. >>=20 >> 3. A NETCONF client attempts to change preferred-lifetime in running to = p=E2=80=99 where v=E2=80=99 < p=E2=80=99 <=3D v. Should this edit be reject= ed? On one hand, running continues to be perfectly valid, but on the other = hand RAs with values of p=E2=80=99 and v=E2=80=99 are broken. > > The running config is valid. I think it is today an implementation > issue how any conflicts with other dynamic information are resolved > (e.g., whether the running config in this case overwrites or deletes > the now broken ephemeral value or whether the NC server signals a > runtime error while processing the edit-config - which would not be a > validation error). > > We currently understand what a valid configuration datastore > means. This is goodness and we should work hard to preserve this. > > When we add ephemeral configuration datastores, it is not clear what > it means for them to be valid or whether we also have to think in > addition in terms of validation of the resulting 'merged > datastore'. Some people also wanted to allow references from ephemeral > configuration data to operational state data, which adds another > dimension of complexity to the picture. > > All I can say at this point in time is that the precise semantics of > validation of ephemeral data are rather unclear to me. And there may > also be a risk to define validation semantics that at the end nobody > will implement fully because it does not scale (e.g., because it > requires to monitor significant amounts of operational state to detect > changes that trigger re-validation). RFC 6241 says that running datastore contains "the complete configuration currently active on the device". However, ephemeral datastore is also designed to contain active (non-persistent) configuration, and I understand it can sometimes override running so that certain parameters in running become inactive. In other words, the ephemeral datastore competes with running for providing active configuration to the device. I think there have to be rules for merging configurations from running and ephemeral, and producing configuration that's really active on the device. To this end, the openconfig idea of intended versus applied configuration might be useful. We would in fact have - running =3D configuration intended by NETCONF, - ephemeral =3D configuration intended by I2RS, - applied =3D active configuration, result of merging/arbitrating running and ephemeral The intended configurations may be validated separately but it is the applied configuration whose validity really matters. This approach could also be generalised - an additional management interface would just contribute its own intended configuration. Lada > > /js > > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Aug 7 07:00:05 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2BE1B2D8D for ; Fri, 7 Aug 2015 07:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jr-viJaomxm for ; Fri, 7 Aug 2015 07:00:02 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60C2E1B2D88 for ; Fri, 7 Aug 2015 06:59:59 -0700 (PDT) Received: from [70.24.199.3] (helo=corretto.local) by cappuccino.rob.sh with esmtpa (Exim 4.80) (envelope-from ) id 1ZNiBW-0003GK-Ck for netmod@ietf.org; Fri, 07 Aug 2015 14:59:46 +0100 Message-ID: <55C4B9DB.1030400@rob.sh> Date: Fri, 07 Aug 2015 09:59:55 -0400 From: Rob Shakir User-Agent: Postbox 4.0.3 (Macintosh/20150805) MIME-Version: 1.0 To: "netmod@ietf.org" Content-Type: multipart/alternative; boundary="------------040005090501000009020605" Archived-At: Subject: [netmod] draft-openconfig-netmod-opstate: Changes in -01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 14:00:04 -0000 This is a multi-part message in MIME format. --------------040005090501000009020605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi netmod folks, Prior to the Prague IETF, Anees, Marcus and I took some time to update draft-openconfig-netmod-opstate. The intent of this update was two-fold: * to provide clarifications of the types of data that we consider to exist within a YANG module. This very much reflects the discussions that we had both on the interim meeting calls, and subsequently on the list. We aimed to document the terms 'intended configuration', 'applied configuration' and 'derived state', and record the relationship between them that we'd iterated on. o This is contained in Section 2. We would encourage interested parties to review these definitions to ensure that the common understanding that we reached has been documented. * add some clarifications to the requirements based on alternative suggestions that had been briefly mentioned during the interims. Particularly, it is worth mentioning: o Section 4.5: we added some clarification about paths within some of the NMS systems that we are working on. o Section 7: which is dedicated to covering some of the observations that have been made relating to the proposed solution. We (the authors) have tried to provide some feedback to some of these points (where it has been possible to do so). The diff for this revision can be found at https://tools.ietf.org/rfcdiff?url2=draft-openconfig-netmod-opstate-01.txt - Appendix D provides a brief changelog. Kind regards, r. --------------040005090501000009020605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi netmod folks,

Prior to the Prague IETF, Anees, Marcus and I took some time to update draft-openconfig-netmod-opstate. The intent of this update was two-fold:
  • to provide clarifications of the types of data that we consider to exist within a YANG module. This very much reflects the discussions that we had both on the interim meeting calls, and subsequently on the list. We aimed to document the terms ‘intended configuration’, ‘applied configuration’ and ‘derived state’, and record the relationship between them that we’d iterated on.
    • This is contained in Section 2. We would encourage interested parties to review these definitions to ensure that the common understanding that we reached has been documented.
  • add some clarifications to the requirements based on alternative suggestions that had been briefly mentioned during the interims. Particularly, it is worth mentioning:
    • Section 4.5: we added some clarification about paths within some of the NMS systems that we are working on.
    • Section 7: which is dedicated to covering some of the observations that have been made relating to the proposed solution. We (the authors) have tried to provide some feedback to some of these points (where it has been possible to do so).
The diff for this revision can be found at https://tools.ietf.org/rfcdiff?url2=draft-openconfig-netmod-opstate-01.txt - Appendix D provides a brief changelog.

Kind regards,
r.

--------------040005090501000009020605-- From nobody Fri Aug 7 07:14:55 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4261B2A53 for ; Fri, 7 Aug 2015 07:14: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 pF0HjRe-v2cu for ; Fri, 7 Aug 2015 07:14:52 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4920C1AD1BA for ; Fri, 7 Aug 2015 07:14:48 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id BDD981256; Fri, 7 Aug 2015 16:14:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id uHskJjBR-M7J; Fri, 7 Aug 2015 16:14:46 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 7 Aug 2015 16:14:46 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 135352004E; Fri, 7 Aug 2015 16:14:46 +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 ru0JBmDfMpAB; Fri, 7 Aug 2015 16:14:45 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E3A0820048; Fri, 7 Aug 2015 16:14:40 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1601A3620E73; Fri, 7 Aug 2015 16:14:39 +0200 (CEST) Date: Fri, 7 Aug 2015 16:14:39 +0200 From: Juergen Schoenwaelder To: Rob Shakir Message-ID: <20150807141439.GA76991@elstar.local> Mail-Followup-To: Rob Shakir , "netmod@ietf.org" References: <55C4B9DB.1030400@rob.sh> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55C4B9DB.1030400@rob.sh> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] draft-openconfig-netmod-opstate: Changes in -01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 14:14:54 -0000 On Fri, Aug 07, 2015 at 09:59:55AM -0400, Rob Shakir wrote: > Hi netmod folks, > > Prior to the Prague IETF, Anees, Marcus and I took some time to update > draft-openconfig-netmod-opstate. The intent of this update was two-fold: [...] > The diff for this revision can be found at > https://tools.ietf.org/rfcdiff?url2=draft-openconfig-netmod-opstate-01.txt > - Appendix D provides a brief changelog. > [...] That is, it avoids the need for an NMS to provide a tuple to uniquely identify a data node. I assume you mean instead of . /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 Aug 7 07:40:16 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E01E21A0368 for ; Fri, 7 Aug 2015 07:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpYI9SpGxgMA for ; Fri, 7 Aug 2015 07:40:13 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FCC21A0061 for ; Fri, 7 Aug 2015 07:40:12 -0700 (PDT) Received: from [70.24.199.3] (helo=corretto.local) by cappuccino.rob.sh with esmtpa (Exim 4.80) (envelope-from ) id 1ZNioQ-0003RN-Jn; Fri, 07 Aug 2015 15:39:58 +0100 Message-ID: <55C4C346.406@rob.sh> Date: Fri, 07 Aug 2015 10:40:06 -0400 From: Rob Shakir User-Agent: Postbox 4.0.3 (Macintosh/20150805) MIME-Version: 1.0 To: Juergen Schoenwaelder , "netmod@ietf.org" References: <55C4B9DB.1030400@rob.sh> <20150807141439.GA76991@elstar.local> In-Reply-To: <20150807141439.GA76991@elstar.local> Content-Type: multipart/alternative; boundary="------------040900060900030504020705" Archived-At: Subject: Re: [netmod] draft-openconfig-netmod-opstate: Changes in -01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 14:40:15 -0000 This is a multi-part message in MIME format. --------------040900060900030504020705 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Juergen Schoenwaelder wrote: > I assume you mean instead of. > > /js Hi Juergen, Generically, the intent here is express that it is '' rather than merely 'path'. The 'some-access-method' might be a reference to a particular datastore, or a certain operation within the access protocol (GET vs. GET-OPER maybe). Thanks, r. --------------040900060900030504020705 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit


Juergen Schoenwaelder wrote:
I assume you mean <datastore, path> instead of <RPC-call, path>.

/js
Hi Juergen,

Generically, the intent here is express that it is '<some-access-method, path>' rather than merely 'path'. The 'some-access-method' might be a reference to a particular datastore, or a certain operation within the access protocol (GET vs. GET-OPER maybe).

Thanks,
r.
--------------040900060900030504020705-- From nobody Fri Aug 7 08:21:23 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC42D1A8F33; Fri, 7 Aug 2015 08:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.51 X-Spam-Level: X-Spam-Status: No, score=-16.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ArmCzymyDg1T; Fri, 7 Aug 2015 08:21:20 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00B9A1A8F42; Fri, 7 Aug 2015 08:21:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14345; q=dns/txt; s=iport; t=1438960879; x=1440170479; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=P6U8xIGpxT28e5MD+dWNbYCrjQy0/CZerFn5H677ii8=; b=OatOlt8ud9cNKjNAaffBfm02eiHpQ7WvhVLqQNQpa0q3E22pYVS9qxzK mL+cd3vPv+AlbjlHl3MKEmFpFC2FpWljtjHVIjAi2Wiqp9bn1YNoKeYpy TWZwslPMxePReamUvsxXXdV6nYnAOx76kkoPlvlDZuwzY0aKS6IltSIwR E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C9AAB8zMRV/xbLJq1BFwOCToEhab4vBXEBC4UtSgKCDAEBAQEBAYELhCQBAQIBAQEBAWMIBgQGCQILIQsEBwUKCQMCAQIBCQwvAQMEDAYCAQGIIggNPLxwkGQBAQEBAQEBAwEBAQEBAQEBARkEi0uBPQGDBzQXEgeEEwWVCIUAhS6CLoFHFTGDXYJ1jTGDZSaCDg0PgQRRPDEBgksBAQE X-IronPort-AV: E=Sophos;i="5.15,630,1432598400"; d="scan'208,217";a="594944900" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 07 Aug 2015 15:21:16 +0000 Received: from [10.60.67.90] (ams-bclaise-8919.cisco.com [10.60.67.90]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t77FLGXX004527; Fri, 7 Aug 2015 15:21:16 GMT To: netmod-chairs@tools.ietf.org, netmod@ietf.org, draft-bjorklund-netmod-openconfig-reply@ietf.org References: <1516231808.93378.1438887834598.JavaMail.nobody@jva2tc202.webex.com> From: Benoit Claise Message-ID: <55C4CCEC.4020209@cisco.com> Date: Fri, 7 Aug 2015 17:21:16 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <1516231808.93378.1438887834598.JavaMail.nobody@jva2tc202.webex.com> Content-Type: multipart/alternative; boundary="------------060504000505040000090308" Archived-At: Subject: Re: [netmod] WebEx meeting invitation: NETMOD Interm meeting on OpenConfig X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 15:21:22 -0000 This is a multi-part message in MIME format. --------------060504000505040000090308 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Dear all, Let me set the stage for this future interim. First of (and let me repeat), I'm happy that the operators gathered and collectively worked on YANG models and related requirements. The previous two interim meetings in June on the openconfig issues (draft-openconfig-netmod-opstate-01 and draft-openconfig-netmod-model-structure-00 ) were successful in the sense that the requirements are now understood. Unfortunately, some key players were not in Prague and we could not finalize the discussion. How to represent the operational state is one important guidance from RFC 6087bis that we must be providing to all existing and future YANG models (and not only in the IETF). We need to bring closure on that topic, and this is the plan for that interim meeting in September. http://datatracker.ietf.org/doc/draft-openconfig-netmod-opstate/ has been updated. Please comment on this version. Also, any alternate proposals must be prepared for that interim in September. They must be prepared with the same level of rigour as draft-openconfig-netmod-opstate., i.e. must have the same level of details. In the meeting in September, the goal is to take a decision. Regards, Benoit (OPS AD) > Hello, > NETMOD Working Group invites you to join this WebEx meeting. > > *NETMOD Interm meeting on OpenConfig* > Thursday, September 10, 2015 > 11:00 am | Eastern Daylight Time (New York, GMT-04:00) | 1 hr > > *Join WebEx meeting* > > > > Meeting number: 645 732 277 > Meeting password: 1234 > > *Join by phone* > *1-877-668-4493* Call-in toll free number (US/Canada) > *1-650-479-3208* Call-in toll number (US/Canada) > Access code: 645 732 277 > Toll-free calling restrictions > > > Add this meeting > > to your calendar. > > Can't join the meeting? Contact support. > > IMPORTANT NOTICE: Please note that this WebEx service allows audio and > other information sent during the session to be recorded, which may be > discoverable in a legal matter. By joining this session, you > automatically consent to such recordings. If you do not consent to > being recorded, discuss your concerns with the host or do not join the > session. > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------060504000505040000090308 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Dear all,

Let me set the stage for this future interim.

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

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

Unfortunately, some key players were not in Prague and we could not finalize the discussion.
How to represent the operational state is one important guidance from RFC 6087bis that we must be providing to all existing and future YANG models (and not only in the IETF).

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

http://datatracker.ietf.org/doc/draft-openconfig-netmod-opstate/ has been updated. Please comment on this version.
Also, any alternate proposals must be prepared for that interim in September. They must be prepared with the same level of rigour as draft-openconfig-netmod-opstate., i.e. must have the same level of details.

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

Regards, Benoit (OPS AD)

Hello,
NETMOD Working Group invites you to join this WebEx meeting.
NETMOD Interm meeting on OpenConfig
Thursday, September 10, 2015
11:00 am|Eastern Daylight Time (New York, GMT-04:00)|1 hr
Join WebEx meeting
Meeting number: 645 732 277
Meeting password: 1234
Join by phone
1-877-668-4493Call-in toll free number (US/Canada)
1-650-479-3208Call-in toll number (US/Canada)
Access code:645 732 277
Toll-free calling restrictions
Add this meeting to your calendar.
Can't join the meeting? Contact support.
IMPORTANT NOTICE: Please note that this WebEx service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session. 


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

--------------060504000505040000090308-- From nobody Fri Aug 7 08:39:19 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 078541B29E4 for ; Fri, 7 Aug 2015 08:39:18 -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 jAGqaU5h-X7D for ; Fri, 7 Aug 2015 08:39:16 -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 7B3EE1B29B3 for ; Fri, 7 Aug 2015 08:39: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 4708210DA; Fri, 7 Aug 2015 17:39: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 tBQP6mGccWdS; Fri, 7 Aug 2015 17:39:14 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 7 Aug 2015 17:39:14 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4DE1D20054; Fri, 7 Aug 2015 17:39:14 +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 ibbgRlEnZFgK; Fri, 7 Aug 2015 17:39:13 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4B47C20048; Fri, 7 Aug 2015 17:39:12 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id F187C3621028; Fri, 7 Aug 2015 17:39:09 +0200 (CEST) Date: Fri, 7 Aug 2015 17:39:09 +0200 From: Juergen Schoenwaelder To: Rob Shakir Message-ID: <20150807153909.GA182@elstar.local> Mail-Followup-To: Rob Shakir , "netmod@ietf.org" References: <55C4B9DB.1030400@rob.sh> <20150807141439.GA76991@elstar.local> <55C4C346.406@rob.sh> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55C4C346.406@rob.sh> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] draft-openconfig-netmod-opstate: Changes in -01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 15:39:18 -0000 On Fri, Aug 07, 2015 at 10:40:06AM -0400, Rob Shakir wrote: > > > Juergen Schoenwaelder wrote: > >I assume you mean instead of. > > > >/js > Hi Juergen, > > Generically, the intent here is express that it is ' path>' rather than merely 'path'. The 'some-access-method' might be a > reference to a particular datastore, or a certain operation within the > access protocol (GET vs. GET-OPER maybe). > Configuration data resides in configuration datastores. This is quite deeply wired in the NETCONF and YANG specifications. For operations on the configuration datastores, the datastore name is passed as an argument in RPC calls. Hence, for configuration data, the naming model is . There have been many discussions over the years whether there should be an explicitly named operational datastore since architecturally we treat operational data somewhat differently. Some of this is hinted at in section 4.3.3 of RFC 6244 and you can find also various I-Ds that were posted in this context. But you are right, it is not just the path that is needed to identify data residing in configuration datastores. It is in general a tuple and for configuration data the selector is a configuration datastore name. /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 Aug 7 08:42:04 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 021631B2E6B; Fri, 7 Aug 2015 08:42:03 -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 b5b9OvM77hGa; Fri, 7 Aug 2015 08:42:01 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA5611A914A; Fri, 7 Aug 2015 08:41:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3230; q=dns/txt; s=iport; t=1438962096; x=1440171696; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=f6DiP42oHcCSMjr6m5TTFbVL/ArqzBKI8X3RdSApwh0=; b=Ln9cj/TorjVkQNAz8PZzGaM3A6PYp/Tmts0nczdcKWClkeERsqJIh3W4 BLMLZeavZmSA9ZXKUqwoQdN5m2YdLTyo7eAL9L386pQ3R3FTlNzFLm+cv TpdIVZvb2mWUHTguAXVFl9aYNrWrKDlFTf8OsVJ4709dqDXn3eEaM0AOy 0=; X-IronPort-AV: E=Sophos;i="5.15,630,1432598400"; d="scan'208,217";a="601434380" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 07 Aug 2015 15:41:34 +0000 Received: from [10.60.67.90] (ams-bclaise-8919.cisco.com [10.60.67.90]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t77FfYmx020582; Fri, 7 Aug 2015 15:41:34 GMT To: iesg-secretary@ietf.org, netmod@ietf.org References: <20150807063205.GA75724@elstar.local> From: Benoit Claise Message-ID: <55C4D1AD.8070402@cisco.com> Date: Fri, 7 Aug 2015 17:41:33 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <20150807063205.GA75724@elstar.local> Content-Type: multipart/alternative; boundary="------------000207040907070405070608" Archived-At: Subject: Re: [netmod] NETMOD WG YANG 1.1 virtual interim meetings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 15:42:03 -0000 This is a multi-part message in MIME format. --------------000207040907070405070608 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Dear all, During the YANG Model Coordination Group webex call today, we discussed this oper status and structure open issues. We're ready to help facilitate the discussion between the different proposals We could compare the pros/cons of the different solutions from our point of view. To allow us some preparation time, alternate proposals should be posted a week before the NETMOD interim meeting, i.e. Sept 3rd. The YANG Model Coordination Group > The NETMOD WG will hold a series of weekly virtual interim meetings in > order to resolve YANG 1.1 review comments. The meetings will take > place on Mondays between 17:00-18:00 CEST. The dates for the virtual > meetings are: > > 2015-08-24 > 2015-08-31 > 2015-09-07 > 2015-09-14 > 2015-09-21 > 2015-09-28 > 2015-10-05 > 2015-10-12 > > We will use the meeting slots as needed (i.e., we may skip slots if > there is nothing to resolve anymore). > > Additional information will be announced on the NETMOD mailing list: > http://www.ietf.org/mail-archive/web/netmod/current/maillist.html > > /js > --------------000207040907070405070608 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit
Dear all,

During the YANG Model Coordination Group webex call today, we discussed this oper status and structure open issues. We're ready to help facilitate the discussion between the different proposals
We could compare the pros/cons of the different solutions from our point of view.

To allow us some preparation time, alternate proposals should be posted a week before the NETMOD interim meeting, i.e. Sept 3rd.

The YANG Model Coordination Group
The NETMOD WG will hold a series of weekly virtual interim meetings in
order to resolve YANG 1.1 review comments. The meetings will take
place on Mondays between 17:00-18:00 CEST. The dates for the virtual
meetings are:

2015-08-24
2015-08-31
2015-09-07
2015-09-14
2015-09-21
2015-09-28
2015-10-05
2015-10-12

We will use the meeting slots as needed (i.e., we may skip slots if
there is nothing to resolve anymore).

Additional information will be announced on the NETMOD mailing list:
http://www.ietf.org/mail-archive/web/netmod/current/maillist.html

/js

--------------000207040907070405070608-- From nobody Fri Aug 7 08:57:23 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2461ACD5E for ; Fri, 7 Aug 2015 08:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L_-2cmlyj6_n for ; Fri, 7 Aug 2015 08:57:19 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A47A31A8AE4 for ; Fri, 7 Aug 2015 08:57:18 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 88DDCFB7; Fri, 7 Aug 2015 17:57:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Wf1yebg-XNGh; Fri, 7 Aug 2015 17:57:16 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 7 Aug 2015 17:57:16 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5449E2004E; Fri, 7 Aug 2015 17:57:16 +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 u1ekIq2zOneJ; Fri, 7 Aug 2015 17:57: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 D928820048; Fri, 7 Aug 2015 17:57:14 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B1D693621085; Fri, 7 Aug 2015 17:57:12 +0200 (CEST) Date: Fri, 7 Aug 2015 17:57:12 +0200 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20150807155712.GA255@elstar.local> Mail-Followup-To: Benoit Claise , netmod@ietf.org References: <20150807063205.GA75724@elstar.local> <55C4D1AD.8070402@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55C4D1AD.8070402@cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] NETMOD WG YANG 1.1 virtual interim meetings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 15:57:21 -0000 Lets please not mix YANG 1.1 work with other discussions at this point in time. /js On Fri, Aug 07, 2015 at 05:41:33PM +0200, Benoit Claise wrote: > Dear all, > > During the YANG Model Coordination Group webex call today, we discussed > this oper status and structure open issues. We're ready to help > facilitate the discussion between the different proposals > We could compare the pros/cons of the different solutions from our point > of view. > > To allow us some preparation time, alternate proposals should be posted > a week before the NETMOD interim meeting, i.e. Sept 3rd. > > The YANG Model Coordination Group > > >The NETMOD WG will hold a series of weekly virtual interim meetings in > >order to resolve YANG 1.1 review comments. The meetings will take > >place on Mondays between 17:00-18:00 CEST. The dates for the virtual > >meetings are: > > > >2015-08-24 > >2015-08-31 > >2015-09-07 > >2015-09-14 > >2015-09-21 > >2015-09-28 > >2015-10-05 > >2015-10-12 > > > >We will use the meeting slots as needed (i.e., we may skip slots if > >there is nothing to resolve anymore). > > > >Additional information will be announced on the NETMOD mailing list: > >http://www.ietf.org/mail-archive/web/netmod/current/maillist.html > > > >/js > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Aug 7 09:09:27 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2159C1ACEE8 for ; Fri, 7 Aug 2015 09:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.51 X-Spam-Level: X-Spam-Status: No, score=-16.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4n1N96URB-s for ; Fri, 7 Aug 2015 09:09:23 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D40C11A87AE for ; Fri, 7 Aug 2015 09:09:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12124; q=dns/txt; s=iport; t=1438963762; x=1440173362; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=d62t61flNPs5FsShyn7dBS1qvkxpr0SsxFBgsKSeu8c=; b=lXa6ZbexFQyoM3G0+2RbDrKuZHHhqIg/7MQUq5ACbKugdZyRajEHE286 o9NJGQTq4e5OZZyUxTdEgufMDWbgWhO39EAnTyTiNuuim4vdsv5CUQrPD 6i83/ZZ99hGs6eyXM+nC+/6kyVIDGgzjTzcpQbEaj5BdiOhsuHZzI7gyR 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C9AADo18RV/xbLJq1BFwOCToEhab4yBXEBC4UtSgKCDgEBAQEBAYELhCQBAQIBAQEBAWMICgYJAgshCwQHBQoJAwIBAgEJDC8BAwQMBgIBAReICwgNPL0DkGgBAQEBAQEBAwEBAQEBAQEBGgSLS4E9AYMHNBcSB4QTBZUIhQCFLoIugUcVhA6CdY0xg2Umgg4ND4EEUTwxAYJLAQEB X-IronPort-AV: E=Sophos;i="5.15,630,1432598400"; d="scan'208,217";a="596845260" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 07 Aug 2015 16:09:21 +0000 Received: from [10.60.67.90] (ams-bclaise-8919.cisco.com [10.60.67.90]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t77G9K01024964; Fri, 7 Aug 2015 16:09:20 GMT To: netmod-chairs@tools.ietf.org, netmod@ietf.org References: <1516231808.93378.1438887834598.JavaMail.nobody@jva2tc202.webex.com> From: Benoit Claise Message-ID: <55C4D830.8030601@cisco.com> Date: Fri, 7 Aug 2015 18:09:20 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <1516231808.93378.1438887834598.JavaMail.nobody@jva2tc202.webex.com> Content-Type: multipart/alternative; boundary="------------000101070006020009060403" Archived-At: Subject: Re: [netmod] WebEx meeting invitation: NETMOD Interm meeting on OpenConfig X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 16:09:26 -0000 This is a multi-part message in MIME format. --------------000101070006020009060403 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Dear all, During the YANG Model Coordination Group webex call today, we discussed this oper status and structure open issues. We're ready to help facilitate the discussion between the different proposals We could compare the pros/cons of the different solutions from our point of view. To allow us some preparation time, alternate proposals should be posted a week before the NETMOD interim meeting, i.e. Sept 3rd. The YANG Model Coordination Group > Hello, > NETMOD Working Group invites you to join this WebEx meeting. > > *NETMOD Interm meeting on OpenConfig* > Thursday, September 10, 2015 > 11:00 am | Eastern Daylight Time (New York, GMT-04:00) | 1 hr > > *Join WebEx meeting* > > > > Meeting number: 645 732 277 > Meeting password: 1234 > > *Join by phone* > *1-877-668-4493* Call-in toll free number (US/Canada) > *1-650-479-3208* Call-in toll number (US/Canada) > Access code: 645 732 277 > Toll-free calling restrictions > > > Add this meeting > > to your calendar. > > Can't join the meeting? Contact support. > > IMPORTANT NOTICE: Please note that this WebEx service allows audio and > other information sent during the session to be recorded, which may be > discoverable in a legal matter. By joining this session, you > automatically consent to such recordings. If you do not consent to > being recorded, discuss your concerns with the host or do not join the > session. > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------000101070006020009060403 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit 
Dear all,

During the YANG Model Coordination Group webex call today, we discussed 
this oper status and structure open issues. We're ready to help 
facilitate the discussion between the different proposals
We could compare the pros/cons of the different solutions from our point 
of view.

To allow us some preparation time, alternate proposals should be posted 
a week before the NETMOD interim meeting, i.e. Sept 3rd.

The YANG Model Coordination Group
Hello,
NETMOD Working Group invites you to join this WebEx meeting.
NETMOD Interm meeting on OpenConfig
Thursday, September 10, 2015
11:00 am|Eastern Daylight Time (New York, GMT-04:00)|1 hr
Join WebEx meeting
Meeting number: 645 732 277
Meeting password: 1234
Join by phone
1-877-668-4493Call-in toll free number (US/Canada)
1-650-479-3208Call-in toll number (US/Canada)
Access code:645 732 277
Toll-free calling restrictions
Add this meeting to your calendar.
Can't join the meeting? Contact support.
IMPORTANT NOTICE: Please note that this WebEx service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session. 


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

--------------000101070006020009060403-- From nobody Fri Aug 7 09:12:02 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0851A914F for ; Fri, 7 Aug 2015 09:12:00 -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 OH3eHJBDQEVn for ; Fri, 7 Aug 2015 09:11:57 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E06BC1B2A0C for ; Fri, 7 Aug 2015 09:11:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1639; q=dns/txt; s=iport; t=1438963916; x=1440173516; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=JUqdhMo+++2lX68gh58WxdE83bX5FX2n9OaB+cdg/Dc=; b=dvRF36mhd5eIBpkb6gjzCT+rkJc4dOgPXvmWR3yfOqY3K5CLjhceRBjD qukuBIJ6HIPmTxBAkZMJUAnAZfPqciPiefPyafze6+MXmxuAN0fMevDUI 6d9LKnA6Dug2zLS9oUsoVNQLNKNWExlUOkCGUjVy4KxLFGM137Zkbk0e7 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CfBADo18RV/xbLJq1bg29pvygMhS1KAoIOAQEBAQEBgQuEJAEBBAEBATU2ChELGAkWDwkDAgECARUwEwYCAQEFEogTDc4nAQEBAQEFAQEBAQEdi0+CPSmBQBACAVcXhBUBBJUIh2eEdYFHhCOCdZEWJoN/PDEBgksBAQE X-IronPort-AV: E=Sophos;i="5.15,630,1432598400"; d="scan'208";a="596847940" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 07 Aug 2015 16:11:55 +0000 Received: from [10.60.67.90] (ams-bclaise-8919.cisco.com [10.60.67.90]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t77GBt62021078 for ; Fri, 7 Aug 2015 16:11:55 GMT To: netmod@ietf.org References: <20150807063205.GA75724@elstar.local> <55C4D1AD.8070402@cisco.com> <20150807155712.GA255@elstar.local> From: Benoit Claise Message-ID: <55C4D8CB.8050207@cisco.com> Date: Fri, 7 Aug 2015 18:11:55 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <20150807155712.GA255@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] NETMOD WG YANG 1.1 virtual interim meetings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 16:12:00 -0000 I obviously replied to the wrong email. My bad. Let me start again Regards, Benoit > Lets please not mix YANG 1.1 work with other discussions at this point > in time. > > /js > > On Fri, Aug 07, 2015 at 05:41:33PM +0200, Benoit Claise wrote: >> Dear all, >> >> During the YANG Model Coordination Group webex call today, we discussed >> this oper status and structure open issues. We're ready to help >> facilitate the discussion between the different proposals >> We could compare the pros/cons of the different solutions from our point >> of view. >> >> To allow us some preparation time, alternate proposals should be posted >> a week before the NETMOD interim meeting, i.e. Sept 3rd. >> >> The YANG Model Coordination Group >> >>> The NETMOD WG will hold a series of weekly virtual interim meetings in >>> order to resolve YANG 1.1 review comments. The meetings will take >>> place on Mondays between 17:00-18:00 CEST. The dates for the virtual >>> meetings are: >>> >>> 2015-08-24 >>> 2015-08-31 >>> 2015-09-07 >>> 2015-09-14 >>> 2015-09-21 >>> 2015-09-28 >>> 2015-10-05 >>> 2015-10-12 >>> >>> We will use the meeting slots as needed (i.e., we may skip slots if >>> there is nothing to resolve anymore). >>> >>> Additional information will be announced on the NETMOD mailing list: >>> http://www.ietf.org/mail-archive/web/netmod/current/maillist.html >>> >>> /js >>> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > From nobody Fri Aug 7 09:24:04 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C43C21B2F1F for ; Fri, 7 Aug 2015 09:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJnKItFf2Vgx for ; Fri, 7 Aug 2015 09:24:00 -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 252FF1B2F1E for ; Fri, 7 Aug 2015 09:22:43 -0700 (PDT) Received: by lagz9 with SMTP id z9so24942047lag.3 for ; Fri, 07 Aug 2015 09:22: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:content-type; bh=jOnZuT4ofwOcHq05raGgzgJt55Pq1SdRbwSQlFp3IP8=; b=MTeV1P1gV7OKSbpkt/AEqeMBIRD/nee5gSoC1bQ33SRdpzzpBrDsQE/NB0tkFPx6lo FVfkSn9X6OvMxBvcxN6WEiLUtvaPUCPKkX2glsB2xrNBxYJ092nRdSE1K2vzvTsM1r36 CaJGqj0NrRkiwSBnSMAJXWsiwihhYMtvfVLbvVooTI5sWs/0O/2nj36os8VfznavCQWu oRQO4PdU/ImihdtyPaVaGrMGAzq82RQ0g7Xm0Ambpiux5Bs5epUBEVKYgQcYnBdzqlFf 3Cv1GJEicuBS43eFf3E+LVAsXJMTqJjUrQUX+uAdXhYfWV1vUwGiU/FQ9DiWzSU8NUPn 5/Yg== X-Gm-Message-State: ALoCoQnmqkRIiHFeoqF6wN0bC+5U3vA3AhlNo/5ZooR1kJ5tbGzpjYkySpFPIY5dHJOIOkzCHK5I MIME-Version: 1.0 X-Received: by 10.112.85.3 with SMTP id d3mr8526987lbz.33.1438964561417; Fri, 07 Aug 2015 09:22:41 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Fri, 7 Aug 2015 09:22:41 -0700 (PDT) In-Reply-To: <20150807155712.GA255@elstar.local> References: <20150807063205.GA75724@elstar.local> <55C4D1AD.8070402@cisco.com> <20150807155712.GA255@elstar.local> Date: Fri, 7 Aug 2015 09:22:41 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Benoit Claise , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a1134946c8732b8051cbb0b31 Archived-At: Subject: Re: [netmod] NETMOD WG YANG 1.1 virtual interim meetings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 16:24:02 -0000 --001a1134946c8732b8051cbb0b31 Content-Type: text/plain; charset=UTF-8 On Fri, Aug 7, 2015 at 8:57 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > Lets please not mix YANG 1.1 work with other discussions at this point > in time. > > I would really like the WG and IESG to decide how YANG is going to be updated to support ephemeral state and operational state. It seems there are many documents waiting on YANG 1.1, yet only 1 or 2 actually use anything from YANG 1.1. If YANG 1.0 is not being deprecated then I do not see any reason to link documents to YANG 1.1 unless they actually use it. Is the plan to start work on YANG 1.2 before YANG 1.1 is even published? If so, then say so. Let's not pretend YANG is stable or that all new improvements after YANG 1.1 are going to be done with extension hacks. If the IESG and the WG had a development plan for this work, it might help vendors decide when and what to support. /js > Andy > > On Fri, Aug 07, 2015 at 05:41:33PM +0200, Benoit Claise wrote: > > Dear all, > > > > During the YANG Model Coordination Group webex call today, we discussed > > this oper status and structure open issues. We're ready to help > > facilitate the discussion between the different proposals > > We could compare the pros/cons of the different solutions from our point > > of view. > > > > To allow us some preparation time, alternate proposals should be posted > > a week before the NETMOD interim meeting, i.e. Sept 3rd. > > > > The YANG Model Coordination Group > > > > > >The NETMOD WG will hold a series of weekly virtual interim meetings in > > >order to resolve YANG 1.1 review comments. The meetings will take > > >place on Mondays between 17:00-18:00 CEST. The dates for the virtual > > >meetings are: > > > > > >2015-08-24 > > >2015-08-31 > > >2015-09-07 > > >2015-09-14 > > >2015-09-21 > > >2015-09-28 > > >2015-10-05 > > >2015-10-12 > > > > > >We will use the meeting slots as needed (i.e., we may skip slots if > > >there is nothing to resolve anymore). > > > > > >Additional information will be announced on the NETMOD mailing list: > > >http://www.ietf.org/mail-archive/web/netmod/current/maillist.html > > > > > >/js > > > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a1134946c8732b8051cbb0b31 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Aug 7, 2015 at 8:57 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
Lets please not mix YANG 1.1 work with other discussi= ons at this point
in time.


I would really like the WG and IESG to= decide how YANG is going to be
updated to support ephemeral stat= e and operational state.

It seems there are many d= ocuments waiting on YANG 1.1, yet
only 1 or 2 actually use anythi= ng from YANG 1.1.

If YANG 1.0 is not being depreca= ted then I do not see
any reason to link documents to YANG 1.1 un= less they
actually use it.

Is the plan t= o start work on YANG 1.2 before YANG 1.1 is even published?
If so= , then say so.=C2=A0 Let's not pretend YANG is stable
or that= all new improvements after YANG 1.1 are going to be
done with ex= tension hacks.

If the IESG and the WG had a develo= pment plan for this work,
it might help vendors decide when and w= hat to support.


/js

Andy
=C2=A0

On Fri, Aug 07, 2015 at 05:41:33PM +0200, Benoit Claise wrote:
> Dear all,
>
> During the YANG Model Coordination Group webex call today, we discusse= d
> this oper status and structure open issues. We're ready to help > facilitate the discussion between the different proposals
> We could compare the pros/cons of the different solutions from our poi= nt
> of view.
>
> To allow us some preparation time, alternate proposals should be poste= d
> a week before the NETMOD interim meeting, i.e. Sept 3rd.
>
> The YANG Model Coordination Group
> <http://www.ietf.org/= iesg/directorate/yang-model-coordination-group.html>
> >The NETMOD WG will hold a series of weekly virtual interim meeting= s in
> >order to resolve YANG 1.1 review comments. The meetings will take<= br> > >place on Mondays between 17:00-18:00 CEST. The dates for the virtu= al
> >meetings are:
> >
> >2015-08-24
> >2015-08-31
> >2015-09-07
> >2015-09-14
> >2015-09-21
> >2015-09-28
> >2015-10-05
> >2015-10-12
> >
> >We will use the meeting slots as needed (i.e., we may skip slots i= f
> >there is nothing to resolve anymore).
> >
> >Additional information will be announced on the NETMOD mailing lis= t:
> >http://www.ietf.org/mail-a= rchive/web/netmod/current/maillist.html
> >
> >/js
> >
>

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

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

--001a1134946c8732b8051cbb0b31-- From nobody Fri Aug 7 12:21:59 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A23371A3BA4 for ; Fri, 7 Aug 2015 12:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOWkleSdj-Bv for ; Fri, 7 Aug 2015 12:21:55 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B38631A21C4 for ; Fri, 7 Aug 2015 12:21:54 -0700 (PDT) Received: from [70.24.199.3] (helo=corretto.local) by cappuccino.rob.sh with esmtpa (Exim 4.80) (envelope-from ) id 1ZNnD3-0004yr-1O; Fri, 07 Aug 2015 20:21:41 +0100 Message-ID: <55C5054C.1090704@rob.sh> Date: Fri, 07 Aug 2015 15:21:48 -0400 From: Rob Shakir User-Agent: Postbox 4.0.3 (Macintosh/20150805) MIME-Version: 1.0 To: Rob Shakir , "netmod@ietf.org" References: <55C4B9DB.1030400@rob.sh> <20150807141439.GA76991@elstar.local> <55C4C346.406@rob.sh> <20150807153909.GA182@elstar.local> In-Reply-To: <20150807153909.GA182@elstar.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] draft-openconfig-netmod-opstate: Changes in -01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 19:21:57 -0000 Juergen Schoenwaelder wrote: > But you are right, it is not just the path that is needed to identify > data residing in configuration datastores. It is in general a tuple > and for configuration data the selector is a > configuration datastore name. Thanks for the clarification. Do you have examples of other (i.e., non-NETCONF) systems that utilise this convention that a path is not an absolute reference to a certain data node? Reviewing with various interested parties, I'm not sure that there are clear cases that form a precedent for this. If we consider that this then might drive some new behaviour where the systems architecture for NMS differs from elsewhere then we might want to question whether this is necessary complexity. Indeed, for me this comes back to one of the discussions about the other datastores that we had on an interim call. * 'startup' is really a property of the intended configuration - as to whether it has been made persistent. In general, I see very few changes that are made where we interact only with the persistent version of the intended configuration; and even fewer where the intended configuration is not made persistent. In both cases, it tends to be the lack of a declarative configuration API that drives the need to interact with either. * 'candidate' is again a property of the intended configuration - insofar that the 'candidate' set of configuration represents a set of changes that have not been requested to be transitioned to the 'applied configuration'. This makes sense when a human is working through building up a transaction (configure protocol X, protocol Y .. protocol Z, then commit) - but isn't quite so clear when it programmatic interaction with the network. It is quite trivial for me to see cases where an external NMS would never really need to interact with either of these datastores - such that it's quite tricky for me to determine that we really want to architect the entire NMS to be able to carry the tuple (stealing your terms, thanks!), especially if this means that it has to work entirely differently w.r.t paths than the rest of OSS. r. From nobody Sat Aug 8 04:10:24 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4F2A1A88F4 for ; Sat, 8 Aug 2015 04:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.31 X-Spam-Level: X-Spam-Status: No, score=-13.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_34=0.6, 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 k-FUF3_rYu-3 for ; Sat, 8 Aug 2015 04:10:19 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41D681A88EF for ; Sat, 8 Aug 2015 04:10:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31626; q=dns/txt; s=iport; t=1439032219; x=1440241819; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=C1KdteR5juoHTdSudu9Kg9HeHWKnrez7ieP68/jMUWE=; b=MFdm41yl5ifkzinPIN93qEQT7i4b7O+klOoXSC6Hb+gA2LNgnsLZajz2 DEJN0/O9FWEYHl1AJIlrXlshJlqvM33fdk2TaUOZnO6XaWslUnI4iEDXx XuXzvYWIDETqPYnzIbuz9smaXPL1OXTfnT7GTZA9nC/qh3uFE7gS0KPYM k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DCDwDb4sVV/5xdJa1bgxtULTwGgx6qH49Cgi0BCYUvSgIcgQ47EQEBAQEBAQGBCoQjAQEBAwEBAQEgSwQHBQcEAgEIEAUBAhUSAwICAiULFBECBA4FGQKICwgNtzSVewEBAQEBAQEBAQEBAQEBAQEBAQEBAReLUYQ+RwQHCoJfL4EUBYxUAYg2AYUBgmmEeIFJRoZ2jRKDZhEVgg4cgVNvAYFHgQQBAQE X-IronPort-AV: E=Sophos; i="5.15,633,1432598400"; d="scan'208,217"; a="16955213" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 08 Aug 2015 11:10:17 +0000 Received: from XCH-RCD-020.cisco.com (xch-rcd-020.cisco.com [173.37.102.30]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t78BAHp6029624 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 8 Aug 2015 11:10:17 GMT Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-RCD-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 8 Aug 2015 06:10:16 -0500 Received: from xhc-aln-x12.cisco.com (173.36.12.86) by xch-rcd-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Sat, 8 Aug 2015 06:10:16 -0500 Received: from xmb-aln-x15.cisco.com ([169.254.9.148]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0248.002; Sat, 8 Aug 2015 06:10:16 -0500 From: "Einar Nilsen-Nygaard (einarnn)" To: Andy Bierman Thread-Topic: [netmod] Y34 - root node Thread-Index: AQHQzfwQ7zjuRBGFiEyMX11aiFLAyp36tNgA//+74pCAAFbtgIAAz0+UgADCtACABfPGAA== Date: Sat, 8 Aug 2015 11:10:15 +0000 Message-ID: <1FF17F20-66A0-4E68-8E07-08FD3CA76F04@cisco.com> References: <20150720210041.GA17614@elstar.local> <14ecceb6dd0.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <14ed0338068.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <55BBA679.7070508@labn.net> <20150801065150.GA67416@elstar.local> <002401d0cdfb$758b6760$4001a8c0@gateway.2wire.net> <03d301d0ce05$c320a800$4001a8c0@gateway.2wire.net> <01e601d0ce98$df05e240$4001a8c0@gateway.2wire.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.36.7.20] Content-Type: multipart/alternative; boundary="_000_1FF17F2066A04E688E0708FD3CA76F04ciscocom_" MIME-Version: 1.0 Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Y34 - root node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2015 11:10:23 -0000 --_000_1FF17F2066A04E688E0708FD3CA76F04ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW5keSwNCg0KSSBhZ3JlZSB0aGF0IHRoZXJlIGlzIGEgbmVlZCBmb3Igb3JnYW5pemF0aW9uIG9m IG1vZGVscywgYnV0IEkgZG9u4oCZdCBoYXZlIGEgZmlybSBwb3NpdGlvbiBvbiBkcmFmdC1vcGVu Y29uZmlnLW5ldG1vZC1tb2RlbC1zdHJ1Y3R1cmUvZHJhZnQtcnRneWFuZ2R0LXJ0Z3dnLWRldmlj ZS1tb2RlbCBvciBkcmFmdC1iaWVybWFuLW5ldG1vZC15YW5nLXBhY2thZ2UuIEJ1dCB3ZSBhYnNv bHV0ZWx5IG5lZWQgKnNvbWV0aGluZyogdG8gaGVscCBlbmQtdXNlcnMgb2YgdGhlIG1vZGVscyBj b21wcmVoZW5kIHRoZSBvdmVyYWxsIHN0cnVjdHVyZSBvZiBtb2RlbHMsIHRoZWlyIHJlbGF0aW9u c2hpcCBhbmQgaG93IHRvIHVzZSB0aGVtLg0KDQpDaGVlcnMsDQoNCkVpbmFyDQoNCk9uIEF1ZyA0 LCAyMDE1LCBhdCA1OjE2IFBNLCBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbTxtYWls dG86YW5keUB5dW1hd29ya3MuY29tPj4gd3JvdGU6DQoNCg0KDQpPbiBUdWUsIEF1ZyA0LCAyMDE1 IGF0IDI6MzQgQU0sIHQucGV0Y2ggPGlldGZjQGJ0Y29ubmVjdC5jb208bWFpbHRvOmlldGZjQGJ0 Y29ubmVjdC5jb20+PiB3cm90ZToNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206 ICJBbmR5IEJpZXJtYW4iIDxhbmR5QHl1bWF3b3Jrcy5jb208bWFpbHRvOmFuZHlAeXVtYXdvcmtz LmNvbT4+DQpUbzogInQucGV0Y2giIDxpZXRmY0BidGNvbm5lY3QuY29tPG1haWx0bzppZXRmY0Bi dGNvbm5lY3QuY29tPj4NClNlbnQ6IE1vbmRheSwgQXVndXN0IDAzLCAyMDE1IDU6MTcgUE0NCg0K PiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+IEZyb206ICJBbmR5IEJpZXJtYW4iIDxh bmR5QHl1bWF3b3Jrcy5jb208bWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbT4+DQo+IFRvOiAidC5w ZXRjaCIgPGlldGZjQGJ0Y29ubmVjdC5jb208bWFpbHRvOmlldGZjQGJ0Y29ubmVjdC5jb20+Pg0K PiBTZW50OiBNb25kYXksIEF1Z3VzdCAwMywgMjAxNSA0OjEwIFBNDQo+DQo+ID4gLS0tLS0gT3Jp Z2luYWwgTWVzc2FnZSAtLS0tLQ0KPiA+IEZyb206ICJBbmR5IEJpZXJtYW4iIGFuZHlAeXVtYXdv cmtzLmNvbTxtYWlsdG86YW5keUB5dW1hd29ya3MuY29tPg0KPiA+IFNlbnQ6IFNhdHVyZGF5LCBB dWd1c3QgMDEsIDIwMTUgNzowNSBQTQ0KPiA+IE9uIFNhdCwgQXVnIDEsIDIwMTUgYXQgOTo1MSBB TSwgQWNlZSBMaW5kZW0gKGFjZWUpIDxhY2VlQGNpc2NvLmNvbTxtYWlsdG86YWNlZUBjaXNjby5j b20+Pg0KPiA+DQo+Pj4gT24gOC8xLzE1LCAyOjUxIEFNLCAgai5zY2hvZW53YWVsZGVyQGphY29i cy11bml2ZXJzaXR5LmRlPG1haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHku ZGU+PiB3cm90ZToNCj4+Pg0KPj4+IFNlY3Rpb24gMS4xIGluDQo+Pj4NCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvaWQvZHJhZnQtb3BlbmNvbmZpZy1uZXRtb2QtbW9kZWwtc3RydWN0dXJlLTAwLnR4 dA0KPj4+IGxpc3RzIHRoZSBnb2FscyBvZiBhIGdlbmVyaWMgbW9kZWwgc3RydWN0dXJlIHRoYXQg d2lsbCBhY2NvbW1vZGF0ZQ0KPj4gbW9zdA0KPj4+IG1vZGVybiBuZXR3b3JrIGRldmljZXMuIEkg Z3Vlc3MgeW91IGRvbuKAmXQgYWdyZWUgdGhhdCB0aGVzZSBhcmUNCj4+IGRlc2lyYWJsZT8NCj4g Pg0KPiA+IFRoZSBvbmx5IG9iamVjdGlvbiBJIGhhdmUgdG8gdGhpcyBkcmFmdCBpcyB0aGUgaW5z ZXJ0aW9uIG9mIGENCnRvcC1sZXZlbA0KPiA+IHJvb3QNCj4gPiBjYWxsZWQgImRldmljZSIuICAo TWlnaHQgYXMgd2VsbCBiZSBjYWxsZWQgInNlbGYiKS4NCj4gPiBUaGVyZSBhcmUgbm8gc2libGlu ZyBub2RlcyBwbGFubmVkIG9yIGludGVuZGVkIGZvcg0KPiA+IHRoaXMgbm9kZSwgc28gaXQgc2Vy dmVzIGFzIGFuIGV4dHJhIGRvY3VtZW50IHJvb3QuDQo+ID4NCj4gPiA8dHA+DQo+ID4gT25lIGFz cGVjdCBvZiBZQU5HIEkgaGF2ZSBuZXZlciBncmFzcGVkIGlzIHdoYXQgYSByb290IG1lYW5zLCBp Zg0KPiA+IGFueXRoaW5nLg0KPiA+DQo+ID4gSSB1bmRlcnN0YW5kIHRoYXQgaXQgaXMgbmVlZGVk IGZvciBORVRDT05GIChmaWx0ZXJzKSBhbmQgZm9yIFlBTkcNCj4gPiAoYXVnbWVudHMsIGNvbnN0 cmFpbnRzKSBhbmQgc28gbXVzdCBiZSBzb21ld2hlcmUgYW5kIG11c3QgYmUNCj4gcmVsYXRpdmVs eQ0KPiA+IHN0YWJsZSwgYnV0IGhhcyBpdCBhbnkgb3RoZXIgc2lnbmlmaWNhbmNlIGluIHRoZSBk YXRhIG1vZGVsPw0KPiA+DQo+ID4gQXMgeW91IG1heSByZWNhbGwsIEkgd2FzIGludm9sdmVkIHdp dGggU01JIGZpcnN0LCB3aGVyZSB0aGUgcm9vdCBpcw0KPiA+IHNvbWV3aGVyZSB1cCBpbiB0aGUg c2t5IGFuZCBsaWZlIG9ubHkgYmVjb21lcyBpbnRlcmVzdGluZyBzb21lIHNpeA0KPiA+IGxldmVs cyBkb3duIHRoZSBoaWVyYXJjaHkgYW5kIHRoYXQgbWF5IGNvbG91ciBteSB0aGlua2luZy4NCj4g Pg0KPg0KPiBZQU5HIGRvZXMgYSBwb29yIGpvYiBvZiBkZWZpbmluZyB0aGUgcm9vdCBmb3IgWUFO RyBkYXRhIG5vZGVzLg0KPiBJdCBpcyBzb21ldGltZXMgY2FsbGVkIGEgZGF0YXN0b3JlIChpbiB0 aGUgYWJzdHJhY3QpLg0KPiBUZWNobmljYWxseSwgWUFORyBib3Jyb3dzIHRoZSBkZWZpbml0aW9u IGZyb20gWFBhdGguDQo+IFlBTkcganVzdCBkZWZpbmVzIHRvcC1sZXZlbCBkYXRhIG5vZGVzIGFu ZCB0aGUgcGFyZW50IG9mDQo+IHRoZXNlIG5vZGVzIGlzIHRoZSBkb2N1bWVudCByb290Lg0KPg0K PiBUaGVyZSBpcyBubyBwcm90b2NvbCBvciBlbmNvZGluZyBuZXV0cmFsIGRlZmluaXRpb24sDQo+ IG9ubHkgYW4gWE1MLXNwZWNpZmljIGRlZmluaXRpb24uDQo+DQo+IDx0cD4NCj4NCj4gVGhhbmtz IGZvciB0aGF0Lg0KPg0KPiBJdCBzZWVtcyB0byBtZSB0aGF0IG11Y2ggb2YgdGhlIGV4dGVuc2l2 ZSBkaXNjdXNzaW9uIG9uIFkzNCAoYWxsIG9mDQo+IHdoaWNoIEkgaGF2ZSByZWFkKSBpcyBhcyBt dWNoIHBvbGl0aWNhbCBhcyB0ZWNobmljYWwsIHRoYXQgaXMgU01JIGlzDQo+IGhpZXJhcmNoaWNh bCwgdG9wIGRvd24sIHBlcmhhcHMgYmVmaXR0aW5nIGl0cyBvcmlnaW5zIGluIElTTywgd2hlcmVh cw0KPiBZQU5HIGlzIGJvdHRvbSB1cC4gSUVURi1saWtlLiAgWUFORyBjb3VsZCBoYXZlIGhhZCBh IHNpbmdsZSB0cmVlLCBidXQNCj4gZG9lc24ndC4gIFNvIHdoZW4gSSByZWFkDQo+DQo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LW9wZW5jb25maWctbmV0bW9kLW1vZGVsLXN0cnVjdHVy ZS0wMC50eHQNCj4NCj4gSSBzZWUgYSBwbGVhIGZvciBhIG1vcmUgaGllcmFyY2hpY2FsIG9yZ2Fu aXNhdGlvbiwgYW5kIHdoZW4gSSByZWFkDQo+DQo+IGRyYWZ0LWJqb3JrbHVuZC1uZXRtb2Qtb3Bl bmNvbmZpZy1yZXBseS0wMA0KPg0KPiBJIHNlZSBhIHJlc3BvbnNlIHRoYXQgc2F5cyB3ZSBhcmUg bm90IGxpa2UgdGhhdC4NCj4NCj4gSWYgc28sIEkgZG91YnQgdGhhdCB0aGVyZSBldmVyIHdpbGwg YmUgYSB0ZWNobmljYWwgc29sdXRpb24uDQo+DQo+IEFuZCBJIGFtIG1pbmRmdWwgdGhhdCB3aGVu IEkgY29uZmlndXJlIHJvdXRpbmcgaW4gYSAoQ2lzY28pIHJvdXRlciwgSQ0KPiBoYXZlIHRvIGRv IHNvbWUgb2YgaXQgdW5kZXIgdGhlIGludGVyZmFjZSBkZWZpbml0aW9ucyBhbmQgc29tZSBvZiBp dA0KPiB1bmRlciB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgcm91dGluZyBwcm90b2NvbC4gIFdoaWNo IGlzIGxpZmUsIG5ldmVyDQo+IHdob2x5IGludGVyZmFjZS1jZW50cmljIGFuZCBuZXZlciB3aG9s eSByb3V0aW5nIHByb3RvY29sLWNlbnRyaWMhDQoNCkFyZSB5b3Ugc2F5aW5nIHRoZSBqb2Igd291 bGQgYmUgZWFzaWVyIGlmIHRoZQ0KcGF0aCB3YXMgL2RldmljZS9pbnRlcmZhY2VzL2ludGVyZmFj ZSBpbnN0ZWFkDQpvZiBqdXN0IC9pbnRlcmZhY2VzL2ludGVyZmFjZT8gIEFyZSB5b3Ugc2F5aW5n DQp0aGF0IC9wcm90b2NvbHMvcm91dGluZyBjb3VsZCBub3QgYWxzbyBiZSBkZWZpbmVkPw0KQ2xl YXJseSBlZGl0LWNvbmZpZyBhbmQgY29weS1jb25maWcgYWxsb3cgYm90aA0Kc3VidHJlZXMgdG8g YmUgYWNjZXNzZWQgaW4gdGhlIHNhbWUgb3BlcmF0aW9uLA0Kc28gSSBkb24ndCB1bmRlcnN0YW5k IHlvdXIgY29uY2Vybi4NCg0KSSBoYXZlIGJlZW4gdHJ5aW5nIHRvIGdldCB0aGUgcm9vdCBub2Rl IHRvIGJlIGJldHRlciBkZWZpbmVkDQppbiB0aGUgcHJvdG9jb2xzIHRoYXQgdXNlIFlBTkcgKGku ZS4sIG5jeDpyb290LCBZMzQtMDQpLg0KSU1PIHRoaXMgaXMgYSBiZXR0ZXIgYXBwcm9hY2ggdGhh biBkZWZpbmluZyBhIFlBTkcgbW9kdWxlDQp3aXRoIGEgc3BlY2lhbCBjb250YWluZXIgdGhhdCBh bGwgb3RoZXIgbW9kdWxlcyBhcmUgZXhwZWN0ZWQNCnRvIGF1Z21lbnQuICBZQU5HIGlzIGRlc2ln bmVkIHN1Y2ggdGhhdCBlYWNoIHZlbmRvciBvciBTRE8NCmlzIG5vdCBkZXBlbmRlbnQgb24gb3Ro ZXIgdmVuZG9ycyBvciBTRE9zIGluIG9yZGVyIHRvDQpkZWZpbmUgZGF0YSBub2Rlcy4NCg0KPHRw Pg0KDQpBbmR5DQoNCkkgYW0gYWdyZWVpbmcgd2l0aCB5b3UgdGhhdCBhZGRpbmcgJ2RldmljZScg YnJpbmdzIG5vIHRlY2huaWNhbCBiZW5lZml0LA0KcmF0aGVyIHRoYXQgdGhlIG1vdGl2YXRpb24g aXMgdGhlIG9wcG9zaXRlIG9mIHRlY2huaWNhbCAod2hpY2ggSQ0KcmVmZXJyZWQgdG8gYXMgcG9s aXRpY2FsKS4gSSBhbSBhbHNvIGFncmVlaW5nIHdpdGggdGhlIGN1cnJlbnQgZGVjbGFyZWQNCmNv bnNlbnN1cyBvbiBZMzQuDQoNCkFuZCB5ZXMsIFlBTkcgaXMgZ29pbmcgdG8gZ2l2ZSB1cyBhIGxh cmdlIG51bWJlciBvZiBtb2R1bGVzLCBzb21lDQp0aWdodGx5IGNvdXBsZWQgKGF1Z21lbnRzKSBz b21lIGxvb3NlbHkgc28gKGhvdyBtYW55IGRvIHlvdSBuZWVkIHRvDQpjb25maWd1cmUgT1NQRj8p IGFuZCB3b3JrIGluIHRoaXMgYXJlYSB3aWxsIGJlIG9mIGJlbmVmaXQgbm93IGFuZA0KcHJvYmFi bHkgZXNzZW50aWFsIGluIGEgZmV3IHllYXJzIHRpbWUuICBUaGF0IHNhaWQsIEkgYW0gdW5zdXJl IHdoYXQNCnN1Y2ggd29yayB3b3VsZCBiZSBsaWtlOyBJIGFtIGxvb2tpbmcgKGluIGRlc3BhaXIp IGF0IDUwIHJvdXRpbmcgYXJlYQ0KWUFORyBtb2RlbHMgYW5kIHdvbmRlcmluZyBob3cgYSB1c2Vy IHdpbGwgZXZlciBnZXQgYSBjb2hlcmVudCBwaWN0dXJlIG9mDQpob3cgdG8gZG8gd2hhdCB0aGV5 IHdhbnQgdG8gZG8uDQoNCg0KDQpUaGUgIllBTkcgTGFuZCBHcmFiIiBnaXZlcyBhIGZhbHNlIHNl bnNlIG9mIHByb2dyZXNzLg0KUmVhY2hpbmcgV0cgY29uc2Vuc3VzIG9uIGV2ZXJ5IHNpbmdsZSBs ZWFmIGlzIGhhcmQgd29yay4NCg0KSSBkb24ndCB0aGluayBhIGNvbGxlY3Rpb24gb2YgMTAwcyBv ZiBZQU5HIG1vZHVsZXMgaXMgZXZlcg0KZ29pbmcgdG8gdG8gYmUgZWFzeSB0byB1bmRlcnN0YW5k LiAgT3BlcmF0b3JzIHdpbGwgbm90IGV4YW1pbmUNCmEgTkVUQ09ORiA8aGVsbG8+IG1lc3NhZ2Us IGxvb2sgYXQgMTUwIG1vZHVsZSBVUklzLA0KYW5kIHNheSAiSSBrbm93IGV4YWN0bHkgd2hhdCB0 aGlzIGRldmljZSBzdXBwb3J0cyIuDQpJIGd1ZXNzIGl0IGlzIHVwIHRvIGNsaWVudCB0b29scyB0 byBkbyB0aGF0Lg0KDQpJIHdyb3RlIGEgZHJhZnQgdGhhdCBkZWZpbmVzIFlBTkcgUGFja2FnZXMs IHdoaWNoIGNhbiBwcm92aWRlDQphIGhpZ2hlciBsZXZlbCBvZiBvcmdhbml6YXRpb24gZm9yIFlB TkcgbW9kdWxlcy4NCg0KaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1iaWVy bWFuLW5ldG1vZC15YW5nLXBhY2thZ2UvDQoNCllvdSBhbmQgSSBhcmUgYXBwYXJlbnRseSBpbiB0 aGUgbWlub3JpdHksIHNpbmNlIHRoZSBvZmZpY2lhbCBzdGF0dXMNCmlzIHRoYXQgdGhlcmUgaXMg bm8gcHJvYmxlbSB3aXRoIHRoZSBjdXJyZW50IGFwcHJvYWNoLCBhbmQgbm8gbmVlZA0KdG8gb3Jn YW5pemUgaW5kaXZpZHVhbCBZQU5HIG1vZHVsZXMgaW50byBhbnkgbGFyZ2VyIGFic3RyYWN0aW9u cy4NCg0KDQoNCiBUb20gUGV0Y2gNCg0KDQoNCkFuZHkNCg0KQW5keQ0KDQo+IEFuZHkNCj4NCj4g PiBUaGUgd2VsbC1zcGVjaWZpZWQgWFBhdGggYW5kIFlBTkcgcm9vdCAoLykgY2FuIGJlDQo+ID4g YWNjZXNzZWQgYnkgYWxsIHByb3RvY29sIG9wZXJhdGlvbnMsIGV4YWN0bHkgdGhlIHNhbWUNCj4g PiBhcyBhIG5vZGUgY2FsbGVkICdkZXZpY2UnLiAgVGhlIGFjdHVhbCBub2RlIG5hbWUgd2lsbA0K PiA+IGRlcGVuZCBvbiB0aGUgUlBDIGZ1bmN0aW9uIChlLmcuICdkYXRhJyBvciAnY29uZmlnJyku DQo+ID4NCj4gPiBUaGlzIGlzIG1vcmUgdGhhbiByZWR1bmRhbnQgaG93ZXZlci4gIEl0IGludHJv ZHVjZXMgYSAic3VwZXItbW9kdWxlIg0KPiA+IGludG8gWUFORyB0aGF0IGV2ZXJ5IG90aGVyIG1v ZHVsZSBpcyBleHBlY3RlZCB0byBhdWdtZW50Lg0KPiA+IFlBTkcgaXMgaW50ZW5kZWQgdG8gYmUg bW9yZSBsb29zZWx5IGNvdXBsZWQgdGhhbiB0aGF0Lg0KPiA+IFRoaXMgaW50cm9kdWNlcyBhbiBl eHRyYSBub2RlIGFuZCBuYW1lc3BhY2UgZGVjbGFyYXRpb24NCj4gPiBpbiBhbGwgcHJvdG9jb2wg bWVzc2FnZXMsIGluY3JlYXNpbmcgbWVzc2FnZSBzaXplcy4NCj4gPg0KPiA+IEl0IGFsc28gYXNz dW1lcyBhbGwgZXhpc3RpbmcgWUFORyBtb2RlbHMgd2lsbCBnZXQgcmV3cml0dGVuIHRvDQo+ID4g YWNjb3VudCBmb3IgIi9kZXZpY2UiIGluIGFsbCBwYXRoIGFuZCBYUGF0aCBleHByZXNzaW9ucy4N Cj4gPiBUaGlzIGlzIGhpZ2hseSBkaXNydXB0aXZlIHRvIGV4aXN0aW5nIGRlcGxveW1lbnRzLg0K PiA+IEFsc28sIG11bHRpcGxlIGRhdGEgbW9kZWxzIHRvIGVkaXQgdGhlIHNhbWUgdGhpbmcgY2F1 c2VzIGxvdHMNCj4gPiBvZiBleHRyYSBjb21wbGV4aXR5IGluIHRoZSBzZXJ2ZXIgKHN1cHBvcnRp bmcgYm90aCBvbGQNCj4gPiBsb2NhdGlvbiBhbmQgbmV3IGxvY2F0aW9uKS4NCj4gPg0KPiA+IElN TyBhIHJlc291cmNlIGRpcmVjdG9yeSBhcHByb2FjaCBpcyBtdWNoIG1vcmUgcmVhbGlzdGljLg0K PiA+IFRoZSAvZGV2aWNlIHRyZWUgY2FuIGNvbnRhaW4gYWxsIHRoZSBvcmdhbml6ZWQgTlAgY29u dGFpbmVycy4NCj4gPiBJbnN0ZWFkIG9mIGFsbCB0aGUgYWN0dWFsIGRhdGEgbm9kZXMsIHRoaXMg dHJlZSBqdXN0IGhhcyBwb2ludGVycw0KPiA+IHRvIHRoZSByZWFsIGxvY2F0aW9uIG9mIHRoZSBy ZXNvdXJjZS4gKGxpa2UgMzAxIE1vdmVkIFBlcm1hbmVudGx5KQ0KPiA+DQo+ID4gPiBBY2VlDQo+ ID4gPg0KPiA+IEFuZHkNCg0KDQoqKiBTb2x1dGlvbiBZMzQtMDINCg0KICBLZWVwICdhbnl4bWwn LiAgSW50cm9kdWNlICdhbnlkYXRhJyBhcyBhYm92ZSBidXQgd2l0aG91dCB0aGUNCiAgJ2Zvcm1h dCcgc3Vic3RhdGVtZW50Lg0KDQogICdhbnl4bWwnIHdvdWxkIHN0aWxsIGJlIHVzZWQgdG8gcmVw cmVzZW50IHVucmVzdHJpY3RlZCBYTUwsIGFzIGlzDQogIGRvbmUgaW4gTkVUQ09ORi4NCg0KICAn YW55ZGF0YScgd291bGQgYmUgYW4gdW5rbm93biBjaHVuayBvZiBkYXRhIHRoYXQgY2FuIGJlIG1v ZGVsbGVkDQogIHdpdGggWUFORy4gIENhbiBiZSBlbmNvZGVkIGFzIHhtbCBvciBqc29uLg0KDQog IEZvciBleGFtcGxlOg0KDQogICAgIytCRUdJTl9FWEFNUExFDQogICAgYW55ZGF0YSBkYXRhOw0K ICAgICMrRU5EX0VYQU1QTEUNCg0KKiogU29sdXRpb24gWTM0LTA1DQoNCiAgIFNhbWUgYXMgWTM0 LTAyIHBsdXMgdHdvIGd1aWRlbGluZXMgYWRvcHRlZCBmcm9tIFkzNC0wNDoNCg0KICAgLSBLZWVw ICdhbnl4bWwnIHVuY2hhbmdlZCBhcyBpdCBpcyBkZWZpbmVkIGluIFlBTkcgMS4wLiBUaGlzDQog ICAgIGVuc3VyZXMgYmFja3dhcmQgY29tcGF0aWJpbGl0eS4NCiAgIC0gSW50cm9kdWNlIGEgbmV3 ICdhbnlkYXRhJyBzdGF0ZW1lbnQgdGhhdCByZXByZXNlbnRzIGFuIHVua25vd24NCiAgICAgY2h1 bmsgb2YgZGF0YSB0aGF0IGNhbiBiZSBtb2RlbGVkIHdpdGggWUFORw0KICAgLSBEb2N1bWVudCB0 aGF0IGltcGxlbWVudGF0aW9ucyBNQVkgaGF2ZSByZXN0cmljdGlvbnMgZm9yIGFueXhtbCBhbmQN CiAgICAgdGhhdCBhbnl4bWwgaXMgbm90IG5lY2Vzc2FyaWx5IGludGVyb3BlcmFibGU7IGRhdGEg bW9kZWwgd3JpdGVycw0KICAgICBzaG91bGQgdXNlIGFueWRhdGEgd2hlbmV2ZXIgcG9zc2libGUu DQogICAtIFRoZSBndWlkZWxpbmVzIGRvY3VtZW50IHNob3VsZCBzYXkgdGhhdCBZQU5HIERvY3Rv cnMgd2lsbCByZXZpZXcNCiAgICAgZWFjaCB1c2Ugb2YgYW55eG1sIGluIElFVEYgbW9kdWxlcyB3 aGVuIFlBTkcgMS4xIGlzIGFkb3B0ZWQgdG8NCiAgICAgYXZvaWQgaXRzIHVzZSB3aGVuZXZlciBw b3NzaWJsZS4NCg0KDQo+DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9yZzxtYWlsdG86 bmV0bW9kQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u ZXRtb2QNCg0K --_000_1FF17F2066A04E688E0708FD3CA76F04ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <64F3D24F7058364B92E108F4AA364B6C@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KQW5keSwNCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkkgYWdyZWUgdGhhdCB0aGVyZSBp cyBhIG5lZWQgZm9yIG9yZ2FuaXphdGlvbiBvZiBtb2RlbHMsIGJ1dCBJIGRvbuKAmXQgaGF2ZSBh IGZpcm0gcG9zaXRpb24gb24mbmJzcDtkcmFmdC1vcGVuY29uZmlnLW5ldG1vZC1tb2RlbC1zdHJ1 Y3R1cmUvZHJhZnQtcnRneWFuZ2R0LXJ0Z3dnLWRldmljZS1tb2RlbCBvciZuYnNwO2RyYWZ0LWJp ZXJtYW4tbmV0bW9kLXlhbmctcGFja2FnZS4gQnV0IHdlIGFic29sdXRlbHkgbmVlZCAqc29tZXRo aW5nKiB0bw0KIGhlbHAgZW5kLXVzZXJzIG9mIHRoZSBtb2RlbHMgY29tcHJlaGVuZCB0aGUgb3Zl cmFsbCBzdHJ1Y3R1cmUgb2YgbW9kZWxzLCB0aGVpciByZWxhdGlvbnNoaXAgYW5kIGhvdyB0byB1 c2UgdGhlbS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPkNoZWVycyw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPkVpbmFyPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+T24gQXVnIDQsIDIwMTUsIGF0IDU6MTYgUE0sIEFuZHkgQmllcm1hbiAmbHQ7PGEgaHJlZj0i bWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbSIgY2xhc3M9IiI+YW5keUB5dW1hd29ya3MuY29tPC9h PiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUi Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFp bF9xdW90ZSI+T24gVHVlLCBBdWcgNCwgMjAxNSBhdCAyOjM0IEFNLCB0LnBldGNoIDxzcGFuIGRp cj0ibHRyIiBjbGFzcz0iIj4NCiZsdDs8YSBocmVmPSJtYWlsdG86aWV0ZmNAYnRjb25uZWN0LmNv bSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmlldGZjQGJ0Y29ubmVjdC5jb208L2E+Jmd0Ozwv c3Bhbj4gd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3Rl IiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFk ZGluZy1sZWZ0OjFleCI+DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tPGJyIGNsYXNzPSIi Pg0KRnJvbTogJnF1b3Q7QW5keSBCaWVybWFuJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YW5k eUB5dW1hd29ya3MuY29tIiBjbGFzcz0iIj5hbmR5QHl1bWF3b3Jrcy5jb208L2E+Jmd0OzxiciBj bGFzcz0iIj4NClRvOiAmcXVvdDt0LnBldGNoJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86aWV0 ZmNAYnRjb25uZWN0LmNvbSIgY2xhc3M9IiI+aWV0ZmNAYnRjb25uZWN0LmNvbTwvYT4mZ3Q7PGJy IGNsYXNzPSIiPg0KU2VudDogTW9uZGF5LCBBdWd1c3QgMDMsIDIwMTUgNToxNyBQTTxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCiZndDsgLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLTxi ciBjbGFzcz0iIj4NCiZndDsgRnJvbTogJnF1b3Q7QW5keSBCaWVybWFuJnF1b3Q7ICZsdDs8YSBo cmVmPSJtYWlsdG86YW5keUB5dW1hd29ya3MuY29tIiBjbGFzcz0iIj5hbmR5QHl1bWF3b3Jrcy5j b208L2E+Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsgVG86ICZxdW90O3QucGV0Y2gmcXVvdDsgJmx0 OzxhIGhyZWY9Im1haWx0bzppZXRmY0BidGNvbm5lY3QuY29tIiBjbGFzcz0iIj5pZXRmY0BidGNv bm5lY3QuY29tPC9hPiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7IFNlbnQ6IE1vbmRheSwgQXVndXN0 IDAzLCAyMDE1IDQ6MTAgUE08YnIgY2xhc3M9IiI+DQomZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyAm Z3Q7IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS08YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsg RnJvbTogJnF1b3Q7QW5keSBCaWVybWFuJnF1b3Q7IDxhIGhyZWY9Im1haWx0bzphbmR5QHl1bWF3 b3Jrcy5jb20iIGNsYXNzPSIiPmFuZHlAeXVtYXdvcmtzLmNvbTwvYT48YnIgY2xhc3M9IiI+DQom Z3Q7ICZndDsgU2VudDogU2F0dXJkYXksIEF1Z3VzdCAwMSwgMjAxNSA3OjA1IFBNPGJyIGNsYXNz PSIiPg0KJmd0OyAmZ3Q7IE9uIFNhdCwgQXVnIDEsIDIwMTUgYXQgOTo1MSBBTSwgQWNlZSBMaW5k ZW0gKGFjZWUpICZsdDs8YSBocmVmPSJtYWlsdG86YWNlZUBjaXNjby5jb20iIGNsYXNzPSIiPmFj ZWVAY2lzY28uY29tPC9hPiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDs8YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyZndDsgT24gOC8xLzE1LCAyOjUxIEFNLCZuYnNwOyA8YSBocmVmPSJtYWlsdG86 ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlIiBjbGFzcz0iIj4NCmouc2Nob2Vu d2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZTwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyBTZWN0aW9uIDEuMSBpbjxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsgPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtb3BlbmNvbmZpZy1uZXRtb2QtbW9kZWwtc3RydWN0 dXJlLTAwLnR4dCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1vcGVuY29uZmlnLW5ldG1vZC1tb2RlbC1zdHJ1 Y3R1cmUtMDAudHh0PC9hPjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyBsaXN0cyB0aGUgZ29h bHMgb2YgYSBnZW5lcmljIG1vZGVsIHN0cnVjdHVyZSB0aGF0IHdpbGwgYWNjb21tb2RhdGU8YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyBtb3N0PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmZ3Q7IG1vZGVy biBuZXR3b3JrIGRldmljZXMuIEkgZ3Vlc3MgeW91IGRvbuKAmXQgYWdyZWUgdGhhdCB0aGVzZSBh cmU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBkZXNpcmFibGU/PGJyIGNsYXNzPSIiPg0KJmd0OyAm Z3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7IFRoZSBvbmx5IG9iamVjdGlvbiBJIGhhdmUgdG8g dGhpcyBkcmFmdCBpcyB0aGUgaW5zZXJ0aW9uIG9mIGE8YnIgY2xhc3M9IiI+DQp0b3AtbGV2ZWw8 YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgcm9vdDxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyBjYWxs ZWQgJnF1b3Q7ZGV2aWNlJnF1b3Q7LiZuYnNwOyAoTWlnaHQgYXMgd2VsbCBiZSBjYWxsZWQgJnF1 b3Q7c2VsZiZxdW90OykuPGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7IFRoZXJlIGFyZSBubyBzaWJs aW5nIG5vZGVzIHBsYW5uZWQgb3IgaW50ZW5kZWQgZm9yPGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7 IHRoaXMgbm9kZSwgc28gaXQgc2VydmVzIGFzIGFuIGV4dHJhIGRvY3VtZW50IHJvb3QuPGJyIGNs YXNzPSIiPg0KJmd0OyAmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7ICZsdDt0cCZndDs8YnIg Y2xhc3M9IiI+DQomZ3Q7ICZndDsgT25lIGFzcGVjdCBvZiBZQU5HIEkgaGF2ZSBuZXZlciBncmFz cGVkIGlzIHdoYXQgYSByb290IG1lYW5zLCBpZjxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyBhbnl0 aGluZy48YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgSSB1 bmRlcnN0YW5kIHRoYXQgaXQgaXMgbmVlZGVkIGZvciBORVRDT05GIChmaWx0ZXJzKSBhbmQgZm9y IFlBTkc8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgKGF1Z21lbnRzLCBjb25zdHJhaW50cykgYW5k IHNvIG11c3QgYmUgc29tZXdoZXJlIGFuZCBtdXN0IGJlPGJyIGNsYXNzPSIiPg0KJmd0OyByZWxh dGl2ZWx5PGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7IHN0YWJsZSwgYnV0IGhhcyBpdCBhbnkgb3Ro ZXIgc2lnbmlmaWNhbmNlIGluIHRoZSBkYXRhIG1vZGVsPzxiciBjbGFzcz0iIj4NCiZndDsgJmd0 OzxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyBBcyB5b3UgbWF5IHJlY2FsbCwgSSB3YXMgaW52b2x2 ZWQgd2l0aCBTTUkgZmlyc3QsIHdoZXJlIHRoZSByb290IGlzPGJyIGNsYXNzPSIiPg0KJmd0OyAm Z3Q7IHNvbWV3aGVyZSB1cCBpbiB0aGUgc2t5IGFuZCBsaWZlIG9ubHkgYmVjb21lcyBpbnRlcmVz dGluZyBzb21lIHNpeDxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyBsZXZlbHMgZG93biB0aGUgaGll cmFyY2h5IGFuZCB0aGF0IG1heSBjb2xvdXIgbXkgdGhpbmtpbmcuPGJyIGNsYXNzPSIiPg0KJmd0 OyAmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4NCiZndDsgWUFORyBkb2VzIGEg cG9vciBqb2Igb2YgZGVmaW5pbmcgdGhlIHJvb3QgZm9yIFlBTkcgZGF0YSBub2Rlcy48YnIgY2xh c3M9IiI+DQomZ3Q7IEl0IGlzIHNvbWV0aW1lcyBjYWxsZWQgYSBkYXRhc3RvcmUgKGluIHRoZSBh YnN0cmFjdCkuPGJyIGNsYXNzPSIiPg0KJmd0OyBUZWNobmljYWxseSwgWUFORyBib3Jyb3dzIHRo ZSBkZWZpbml0aW9uIGZyb20gWFBhdGguPGJyIGNsYXNzPSIiPg0KJmd0OyBZQU5HIGp1c3QgZGVm aW5lcyB0b3AtbGV2ZWwgZGF0YSBub2RlcyBhbmQgdGhlIHBhcmVudCBvZjxiciBjbGFzcz0iIj4N CiZndDsgdGhlc2Ugbm9kZXMgaXMgdGhlIGRvY3VtZW50IHJvb3QuPGJyIGNsYXNzPSIiPg0KJmd0 OzxiciBjbGFzcz0iIj4NCiZndDsgVGhlcmUgaXMgbm8gcHJvdG9jb2wgb3IgZW5jb2RpbmcgbmV1 dHJhbCBkZWZpbml0aW9uLDxiciBjbGFzcz0iIj4NCiZndDsgb25seSBhbiBYTUwtc3BlY2lmaWMg ZGVmaW5pdGlvbi48YnIgY2xhc3M9IiI+DQomZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyAmbHQ7dHAm Z3Q7PGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4NCiZndDsgVGhhbmtzIGZvciB0aGF0 LjxiciBjbGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7IEl0IHNlZW1zIHRvIG1lIHRo YXQgbXVjaCBvZiB0aGUgZXh0ZW5zaXZlIGRpc2N1c3Npb24gb24gWTM0IChhbGwgb2Y8YnIgY2xh c3M9IiI+DQomZ3Q7IHdoaWNoIEkgaGF2ZSByZWFkKSBpcyBhcyBtdWNoIHBvbGl0aWNhbCBhcyB0 ZWNobmljYWwsIHRoYXQgaXMgU01JIGlzPGJyIGNsYXNzPSIiPg0KJmd0OyBoaWVyYXJjaGljYWws IHRvcCBkb3duLCBwZXJoYXBzIGJlZml0dGluZyBpdHMgb3JpZ2lucyBpbiBJU08sIHdoZXJlYXM8 YnIgY2xhc3M9IiI+DQomZ3Q7IFlBTkcgaXMgYm90dG9tIHVwLiBJRVRGLWxpa2UuJm5ic3A7IFlB TkcgY291bGQgaGF2ZSBoYWQgYSBzaW5nbGUgdHJlZSwgYnV0PGJyIGNsYXNzPSIiPg0KJmd0OyBk b2Vzbid0LiZuYnNwOyBTbyB3aGVuIEkgcmVhZDxiciBjbGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9 IiI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LW9wZW5jb25m aWctbmV0bW9kLW1vZGVsLXN0cnVjdHVyZS0wMC50eHQiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0 PSJfYmxhbmsiIGNsYXNzPSIiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtb3BlbmNv bmZpZy1uZXRtb2QtbW9kZWwtc3RydWN0dXJlLTAwLnR4dDwvYT48YnIgY2xhc3M9IiI+DQomZ3Q7 PGJyIGNsYXNzPSIiPg0KJmd0OyBJIHNlZSBhIHBsZWEgZm9yIGEgbW9yZSBoaWVyYXJjaGljYWwg b3JnYW5pc2F0aW9uLCBhbmQgd2hlbiBJIHJlYWQ8YnIgY2xhc3M9IiI+DQomZ3Q7PGJyIGNsYXNz PSIiPg0KJmd0OyBkcmFmdC1iam9ya2x1bmQtbmV0bW9kLW9wZW5jb25maWctcmVwbHktMDA8YnIg Y2xhc3M9IiI+DQomZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyBJIHNlZSBhIHJlc3BvbnNlIHRoYXQg c2F5cyB3ZSBhcmUgbm90IGxpa2UgdGhhdC48YnIgY2xhc3M9IiI+DQomZ3Q7PGJyIGNsYXNzPSIi Pg0KJmd0OyBJZiBzbywgSSBkb3VidCB0aGF0IHRoZXJlIGV2ZXIgd2lsbCBiZSBhIHRlY2huaWNh bCBzb2x1dGlvbi48YnIgY2xhc3M9IiI+DQomZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyBBbmQgSSBh bSBtaW5kZnVsIHRoYXQgd2hlbiBJIGNvbmZpZ3VyZSByb3V0aW5nIGluIGEgKENpc2NvKSByb3V0 ZXIsIEk8YnIgY2xhc3M9IiI+DQomZ3Q7IGhhdmUgdG8gZG8gc29tZSBvZiBpdCB1bmRlciB0aGUg aW50ZXJmYWNlIGRlZmluaXRpb25zIGFuZCBzb21lIG9mIGl0PGJyIGNsYXNzPSIiPg0KJmd0OyB1 bmRlciB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgcm91dGluZyBwcm90b2NvbC4mbmJzcDsgV2hpY2gg aXMgbGlmZSwgbmV2ZXI8YnIgY2xhc3M9IiI+DQomZ3Q7IHdob2x5IGludGVyZmFjZS1jZW50cmlj IGFuZCBuZXZlciB3aG9seSByb3V0aW5nIHByb3RvY29sLWNlbnRyaWMhPGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KQXJlIHlvdSBzYXlpbmcgdGhlIGpvYiB3b3VsZCBiZSBlYXNpZXIgaWYg dGhlPGJyIGNsYXNzPSIiPg0KcGF0aCB3YXMgL2RldmljZS9pbnRlcmZhY2VzL2ludGVyZmFjZSBp bnN0ZWFkPGJyIGNsYXNzPSIiPg0Kb2YganVzdCAvaW50ZXJmYWNlcy9pbnRlcmZhY2U/Jm5ic3A7 IEFyZSB5b3Ugc2F5aW5nPGJyIGNsYXNzPSIiPg0KdGhhdCAvcHJvdG9jb2xzL3JvdXRpbmcgY291 bGQgbm90IGFsc28gYmUgZGVmaW5lZD88YnIgY2xhc3M9IiI+DQpDbGVhcmx5IGVkaXQtY29uZmln IGFuZCBjb3B5LWNvbmZpZyBhbGxvdyBib3RoPGJyIGNsYXNzPSIiPg0Kc3VidHJlZXMgdG8gYmUg YWNjZXNzZWQgaW4gdGhlIHNhbWUgb3BlcmF0aW9uLDxiciBjbGFzcz0iIj4NCnNvIEkgZG9uJ3Qg dW5kZXJzdGFuZCB5b3VyIGNvbmNlcm4uPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSSBo YXZlIGJlZW4gdHJ5aW5nIHRvIGdldCB0aGUgcm9vdCBub2RlIHRvIGJlIGJldHRlciBkZWZpbmVk PGJyIGNsYXNzPSIiPg0KaW4gdGhlIHByb3RvY29scyB0aGF0IHVzZSBZQU5HIChpLmUuLCBuY3g6 cm9vdCwgWTM0LTA0KS48YnIgY2xhc3M9IiI+DQpJTU8gdGhpcyBpcyBhIGJldHRlciBhcHByb2Fj aCB0aGFuIGRlZmluaW5nIGEgWUFORyBtb2R1bGU8YnIgY2xhc3M9IiI+DQp3aXRoIGEgc3BlY2lh bCBjb250YWluZXIgdGhhdCBhbGwgb3RoZXIgbW9kdWxlcyBhcmUgZXhwZWN0ZWQ8YnIgY2xhc3M9 IiI+DQp0byBhdWdtZW50LiZuYnNwOyBZQU5HIGlzIGRlc2lnbmVkIHN1Y2ggdGhhdCBlYWNoIHZl bmRvciBvciBTRE88YnIgY2xhc3M9IiI+DQppcyBub3QgZGVwZW5kZW50IG9uIG90aGVyIHZlbmRv cnMgb3IgU0RPcyBpbiBvcmRlciB0bzxiciBjbGFzcz0iIj4NCmRlZmluZSBkYXRhIG5vZGVzLjxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZsdDt0cCZndDs8YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQpBbmR5PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSSBhbSBhZ3JlZWlu ZyB3aXRoIHlvdSB0aGF0IGFkZGluZyAnZGV2aWNlJyBicmluZ3Mgbm8gdGVjaG5pY2FsIGJlbmVm aXQsPGJyIGNsYXNzPSIiPg0KcmF0aGVyIHRoYXQgdGhlIG1vdGl2YXRpb24gaXMgdGhlIG9wcG9z aXRlIG9mIHRlY2huaWNhbCAod2hpY2ggSTxiciBjbGFzcz0iIj4NCnJlZmVycmVkIHRvIGFzIHBv bGl0aWNhbCkuIEkgYW0gYWxzbyBhZ3JlZWluZyB3aXRoIHRoZSBjdXJyZW50IGRlY2xhcmVkPGJy IGNsYXNzPSIiPg0KY29uc2Vuc3VzIG9uIFkzNC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQpBbmQgeWVzLCBZQU5HIGlzIGdvaW5nIHRvIGdpdmUgdXMgYSBsYXJnZSBudW1iZXIgb2YgbW9k dWxlcywgc29tZTxiciBjbGFzcz0iIj4NCnRpZ2h0bHkgY291cGxlZCAoYXVnbWVudHMpIHNvbWUg bG9vc2VseSBzbyAoaG93IG1hbnkgZG8geW91IG5lZWQgdG88YnIgY2xhc3M9IiI+DQpjb25maWd1 cmUgT1NQRj8pIGFuZCB3b3JrIGluIHRoaXMgYXJlYSB3aWxsIGJlIG9mIGJlbmVmaXQgbm93IGFu ZDxiciBjbGFzcz0iIj4NCnByb2JhYmx5IGVzc2VudGlhbCBpbiBhIGZldyB5ZWFycyB0aW1lLiZu YnNwOyBUaGF0IHNhaWQsIEkgYW0gdW5zdXJlIHdoYXQ8YnIgY2xhc3M9IiI+DQpzdWNoIHdvcmsg d291bGQgYmUgbGlrZTsgSSBhbSBsb29raW5nIChpbiBkZXNwYWlyKSBhdCA1MCByb3V0aW5nIGFy ZWE8YnIgY2xhc3M9IiI+DQpZQU5HIG1vZGVscyBhbmQgd29uZGVyaW5nIGhvdyBhIHVzZXIgd2ls bCBldmVyIGdldCBhIGNvaGVyZW50IHBpY3R1cmUgb2Y8YnIgY2xhc3M9IiI+DQpob3cgdG8gZG8g d2hhdCB0aGV5IHdhbnQgdG8gZG8uPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9ibG9j a3F1b3RlPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoZSAmcXVvdDtZQU5HIExh bmQgR3JhYiZxdW90OyBnaXZlcyBhIGZhbHNlIHNlbnNlIG9mIHByb2dyZXNzLjwvZGl2Pg0KPGRp diBjbGFzcz0iIj5SZWFjaGluZyBXRyBjb25zZW5zdXMgb24gZXZlcnkgc2luZ2xlIGxlYWYgaXMg aGFyZCB3b3JrLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+SSBkb24ndCB0aGluayBhIGNvbGxlY3Rpb24gb2YgMTAwcyBvZiBZQU5HIG1v ZHVsZXMgaXMgZXZlcjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5nb2luZyB0 byB0byBiZSBlYXN5IHRvIHVuZGVyc3RhbmQuJm5ic3A7IE9wZXJhdG9ycyB3aWxsIG5vdCBleGFt aW5lPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPmEgTkVUQ09ORiAmbHQ7aGVsbG8mZ3Q7IG1lc3NhZ2Us IGxvb2sgYXQgMTUwIG1vZHVsZSBVUklzLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5hbmQgc2F5ICZx dW90O0kga25vdyBleGFjdGx5IHdoYXQgdGhpcyBkZXZpY2Ugc3VwcG9ydHMmcXVvdDsuPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPkkgZ3Vlc3MgaXQgaXMgdXAgdG8gY2xpZW50IHRvb2xzIHRvIGRvIHRo YXQuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj5JIHdyb3RlIGEgZHJhZnQgdGhhdCBkZWZpbmVzIFlBTkcgUGFja2FnZXMsIHdoaWNoIGNh biBwcm92aWRlPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPmEgaGlnaGVyIGxldmVsIG9mIG9yZ2FuaXph dGlvbiBmb3IgWUFORyBtb2R1bGVzLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1iaWVybWFuLW5ldG1vZC15YW5nLXBhY2thZ2UvIiBjbGFzcz0iIj5odHRw Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJpZXJtYW4tbmV0bW9kLXlhbmctcGFj a2FnZS88L2E+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5Zb3UgYW5kIEkgYXJlIGFwcGFyZW50bHkgaW4gdGhl IG1pbm9yaXR5LCBzaW5jZSB0aGUgb2ZmaWNpYWwgc3RhdHVzPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PmlzIHRoYXQgdGhlcmUgaXMgbm8gcHJvYmxlbSB3aXRoIHRoZSBjdXJyZW50IGFwcHJvYWNoLCBh bmQgbm8gbmVlZDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj50byBvcmdhbml6ZSBpbmRpdmlkdWFsIFlB TkcgbW9kdWxlcyBpbnRvIGFueSBsYXJnZXIgYWJzdHJhY3Rpb25zLjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg Y2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6 MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQombmJzcDtUb20gUGV0Y2g8YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+QW5keTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDs8L2Rpdj4NCjxibG9j a3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRl ci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KQW5keTxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NCiZndDsgQW5keTxiciBjbGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9 IiI+DQomZ3Q7ICZndDsgVGhlIHdlbGwtc3BlY2lmaWVkIFhQYXRoIGFuZCBZQU5HIHJvb3QgKC8p IGNhbiBiZTxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyBhY2Nlc3NlZCBieSBhbGwgcHJvdG9jb2wg b3BlcmF0aW9ucywgZXhhY3RseSB0aGUgc2FtZTxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyBhcyBh IG5vZGUgY2FsbGVkICdkZXZpY2UnLiZuYnNwOyBUaGUgYWN0dWFsIG5vZGUgbmFtZSB3aWxsPGJy IGNsYXNzPSIiPg0KJmd0OyAmZ3Q7IGRlcGVuZCBvbiB0aGUgUlBDIGZ1bmN0aW9uIChlLmcuICdk YXRhJyBvciAnY29uZmlnJykuPGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7PGJyIGNsYXNzPSIiPg0K Jmd0OyAmZ3Q7IFRoaXMgaXMgbW9yZSB0aGFuIHJlZHVuZGFudCBob3dldmVyLiZuYnNwOyBJdCBp bnRyb2R1Y2VzIGEgJnF1b3Q7c3VwZXItbW9kdWxlJnF1b3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyAm Z3Q7IGludG8gWUFORyB0aGF0IGV2ZXJ5IG90aGVyIG1vZHVsZSBpcyBleHBlY3RlZCB0byBhdWdt ZW50LjxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyBZQU5HIGlzIGludGVuZGVkIHRvIGJlIG1vcmUg bG9vc2VseSBjb3VwbGVkIHRoYW4gdGhhdC48YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgVGhpcyBp bnRyb2R1Y2VzIGFuIGV4dHJhIG5vZGUgYW5kIG5hbWVzcGFjZSBkZWNsYXJhdGlvbjxiciBjbGFz cz0iIj4NCiZndDsgJmd0OyBpbiBhbGwgcHJvdG9jb2wgbWVzc2FnZXMsIGluY3JlYXNpbmcgbWVz c2FnZSBzaXplcy48YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7ICZn dDsgSXQgYWxzbyBhc3N1bWVzIGFsbCBleGlzdGluZyBZQU5HIG1vZGVscyB3aWxsIGdldCByZXdy aXR0ZW4gdG88YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgYWNjb3VudCBmb3IgJnF1b3Q7L2Rldmlj ZSZxdW90OyBpbiBhbGwgcGF0aCBhbmQgWFBhdGggZXhwcmVzc2lvbnMuPGJyIGNsYXNzPSIiPg0K Jmd0OyAmZ3Q7IFRoaXMgaXMgaGlnaGx5IGRpc3J1cHRpdmUgdG8gZXhpc3RpbmcgZGVwbG95bWVu dHMuPGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7IEFsc28sIG11bHRpcGxlIGRhdGEgbW9kZWxzIHRv IGVkaXQgdGhlIHNhbWUgdGhpbmcgY2F1c2VzIGxvdHM8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsg b2YgZXh0cmEgY29tcGxleGl0eSBpbiB0aGUgc2VydmVyIChzdXBwb3J0aW5nIGJvdGggb2xkPGJy IGNsYXNzPSIiPg0KJmd0OyAmZ3Q7IGxvY2F0aW9uIGFuZCBuZXcgbG9jYXRpb24pLjxiciBjbGFz cz0iIj4NCiZndDsgJmd0OzxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyBJTU8gYSByZXNvdXJjZSBk aXJlY3RvcnkgYXBwcm9hY2ggaXMgbXVjaCBtb3JlIHJlYWxpc3RpYy48YnIgY2xhc3M9IiI+DQom Z3Q7ICZndDsgVGhlIC9kZXZpY2UgdHJlZSBjYW4gY29udGFpbiBhbGwgdGhlIG9yZ2FuaXplZCBO UCBjb250YWluZXJzLjxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyBJbnN0ZWFkIG9mIGFsbCB0aGUg YWN0dWFsIGRhdGEgbm9kZXMsIHRoaXMgdHJlZSBqdXN0IGhhcyBwb2ludGVyczxiciBjbGFzcz0i Ij4NCiZndDsgJmd0OyB0byB0aGUgcmVhbCBsb2NhdGlvbiBvZiB0aGUgcmVzb3VyY2UuIChsaWtl IDMwMSBNb3ZlZCBQZXJtYW5lbnRseSk8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDs8YnIgY2xhc3M9 IiI+DQomZ3Q7ICZndDsgJmd0OyBBY2VlPGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7ICZndDs8YnIg Y2xhc3M9IiI+DQomZ3Q7ICZndDsgQW5keTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCioqIFNvbHV0aW9uIFkzNC0wMjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCiZuYnNwOyBLZWVwICdhbnl4bWwnLiZuYnNwOyBJbnRyb2R1Y2UgJ2FueWRhdGEnIGFzIGFi b3ZlIGJ1dCB3aXRob3V0IHRoZTxiciBjbGFzcz0iIj4NCiZuYnNwOyAnZm9ybWF0JyBzdWJzdGF0 ZW1lbnQuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICdhbnl4bWwnIHdvdWxk IHN0aWxsIGJlIHVzZWQgdG8gcmVwcmVzZW50IHVucmVzdHJpY3RlZCBYTUwsIGFzIGlzPGJyIGNs YXNzPSIiPg0KJm5ic3A7IGRvbmUgaW4gTkVUQ09ORi48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQombmJzcDsgJ2FueWRhdGEnIHdvdWxkIGJlIGFuIHVua25vd24gY2h1bmsgb2YgZGF0YSB0 aGF0IGNhbiBiZSBtb2RlbGxlZDxiciBjbGFzcz0iIj4NCiZuYnNwOyB3aXRoIFlBTkcuJm5ic3A7 IENhbiBiZSBlbmNvZGVkIGFzIHhtbCBvciBqc29uLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCiZuYnNwOyBGb3IgZXhhbXBsZTo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJz cDsgJm5ic3A7ICMmIzQzO0JFR0lOX0VYQU1QTEU8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7 IGFueWRhdGEgZGF0YTs8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICMmIzQzO0VORF9FWEFN UExFPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KKiogU29sdXRpb24gWTM0LTA1PGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO1NhbWUgYXMgWTM0LTAyIHBsdXMg dHdvIGd1aWRlbGluZXMgYWRvcHRlZCBmcm9tIFkzNC0wNDo8YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQombmJzcDsgJm5ic3A7LSBLZWVwICdhbnl4bWwnIHVuY2hhbmdlZCBhcyBpdCBpcyBk ZWZpbmVkIGluIFlBTkcgMS4wLiBUaGlzPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDtlbnN1cmVzIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkuPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZu YnNwOy0gSW50cm9kdWNlIGEgbmV3ICdhbnlkYXRhJyBzdGF0ZW1lbnQgdGhhdCByZXByZXNlbnRz IGFuIHVua25vd248YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwO2NodW5rIG9mIGRh dGEgdGhhdCBjYW4gYmUgbW9kZWxlZCB3aXRoIFlBTkc8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5i c3A7LSBEb2N1bWVudCB0aGF0IGltcGxlbWVudGF0aW9ucyBNQVkgaGF2ZSByZXN0cmljdGlvbnMg Zm9yIGFueXhtbCBhbmQ8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwO3RoYXQgYW55 eG1sIGlzIG5vdCBuZWNlc3NhcmlseSBpbnRlcm9wZXJhYmxlOyBkYXRhIG1vZGVsIHdyaXRlcnM8 YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwO3Nob3VsZCB1c2UgYW55ZGF0YSB3aGVu ZXZlciBwb3NzaWJsZS48YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7LSBUaGUgZ3VpZGVsaW5l cyBkb2N1bWVudCBzaG91bGQgc2F5IHRoYXQgWUFORyBEb2N0b3JzIHdpbGwgcmV2aWV3PGJyIGNs YXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDtlYWNoIHVzZSBvZiBhbnl4bWwgaW4gSUVURiBt b2R1bGVzIHdoZW4gWUFORyAxLjEgaXMgYWRvcHRlZCB0bzxiciBjbGFzcz0iIj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7YXZvaWQgaXRzIHVzZSB3aGVuZXZlciBwb3NzaWJsZS48YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQomZ3Q7PGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwv ZGl2Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIg Y2xhc3M9IiI+DQpuZXRtb2QgbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFp bHRvOm5ldG1vZEBpZXRmLm9yZyIgY2xhc3M9IiI+bmV0bW9kQGlldGYub3JnPC9hPjxiciBjbGFz cz0iIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_1FF17F2066A04E688E0708FD3CA76F04ciscocom_-- From nobody Sat Aug 8 23:59:47 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF68E1ACD6A for ; Sat, 8 Aug 2015 23:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.86 X-Spam-Level: X-Spam-Status: No, score=-5.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQLFwLWnp2bP for ; Sat, 8 Aug 2015 23:59: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 79D5D1ACD66 for ; Sat, 8 Aug 2015 23:59: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 EF44913E4 for ; Sun, 9 Aug 2015 08:59: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 HWzlAMcGWjvy for ; Sun, 9 Aug 2015 08:59: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 for ; Sun, 9 Aug 2015 08:59:39 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id AE9E02004E for ; Sun, 9 Aug 2015 08:59:39 +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 BW5Nq4TkvFX6; Sun, 9 Aug 2015 08:59:38 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CF4FF20048; Sun, 9 Aug 2015 08:59:34 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 34C20362214C; Sun, 9 Aug 2015 08:59:29 +0200 (CEST) Date: Sun, 9 Aug 2015 08:59:29 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20150809065929.GA4345@elstar.local> Mail-Followup-To: netmod@ietf.org References: <1516231808.93378.1438887834598.JavaMail.nobody@jva2tc202.webex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1516231808.93378.1438887834598.JavaMail.nobody@jva2tc202.webex.com> User-Agent: Mutt/1.4.2.3i Archived-At: Subject: Re: [netmod] WebEx meeting invitation: NETMOD Interm meeting on OpenConfig X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2015 06:59:45 -0000 I am most likely not able to join this interim meeting due to other commitments. I hope Martin and others knowing NETCONF/YANG by heart are able to join. Anyway, if this is supposed to a virtual interim meeting, it also needs to be announced as such. /js On Thu, Aug 06, 2015 at 07:03:54PM +0000, NETMOD Working Group wrote: > > Hello, > > NETMOD Working Group invites you to join this WebEx meeting. > > > NETMOD Interm meeting on OpenConfig > Thursday, September 10, 2015 > 11:00 am | Eastern Daylight Time (New York, GMT-04:00) | 1 hr > > > JOIN WEBEX MEETING > https://ietf.webex.com/ietf/j.php?MTID=m54c7bcbed84a08dc78fba128d500f8c0 > Meeting number: 645 732 277 > Meeting password: 1234 > > > JOIN BY PHONE > 1-877-668-4493 Call-in toll free number (US/Canada) > 1-650-479-3208 Call-in toll number (US/Canada) > Access code: 645 732 277 > > Toll-free dialing restrictions: > http://www.webex.com/pdf/tollfree_restrictions.pdf > > > Add this meeting to your calendar: > https://ietf.webex.com/ietf/j.php?MTID=m17086d6b9810a2722c5dc8c64ec795b9 > > > Can't join the meeting? Contact support here: > https://ietf.webex.com/ietf/mc > > > IMPORTANT NOTICE: Please note that this WebEx service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session. > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sun Aug 9 00:50:32 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866991ACDEF for ; Sun, 9 Aug 2015 00:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8k0X-wqCcOeu for ; Sun, 9 Aug 2015 00:50:28 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B3E91ACDEB for ; Sun, 9 Aug 2015 00:50:28 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 0FF1DFE9; Sun, 9 Aug 2015 09:50:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id c5ecZy9_KL5T; Sun, 9 Aug 2015 09:50: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; Sun, 9 Aug 2015 09:50:25 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id ACEC120054; Sun, 9 Aug 2015 09:50:25 +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 zEj9L2ToKKHs; Sun, 9 Aug 2015 09:50:24 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 72FD320048; Sun, 9 Aug 2015 09:50:24 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 82DED36221E8; Sun, 9 Aug 2015 09:50:21 +0200 (CEST) Date: Sun, 9 Aug 2015 09:50:21 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20150809075020.GA4480@elstar.local> Mail-Followup-To: Andy Bierman , Benoit Claise , "netmod@ietf.org" References: <20150807063205.GA75724@elstar.local> <55C4D1AD.8070402@cisco.com> <20150807155712.GA255@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] NETMOD WG YANG 1.1 virtual interim meetings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2015 07:50:30 -0000 On Fri, Aug 07, 2015 at 09:22:41AM -0700, Andy Bierman wrote: > On Fri, Aug 7, 2015 at 8:57 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > Lets please not mix YANG 1.1 work with other discussions at this point > > in time. > > > > > I would really like the WG and IESG to decide how YANG is going to be > updated to support ephemeral state and operational state. > > It seems there are many documents waiting on YANG 1.1, yet > only 1 or 2 actually use anything from YANG 1.1. > > If YANG 1.0 is not being deprecated then I do not see > any reason to link documents to YANG 1.1 unless they > actually use it. > > Is the plan to start work on YANG 1.2 before YANG 1.1 is even published? > If so, then say so. Let's not pretend YANG is stable > or that all new improvements after YANG 1.1 are going to be > done with extension hacks. > > If the IESG and the WG had a development plan for this work, > it might help vendors decide when and what to support. > I can't speak for the IESG, I can't speak for the WG - the WG has to speak first. My personal goal is to complete YANG 1.1 with the feature set that we all worked on hard during that last year. I believe in the value of finishing something. The alternative is to keep YANG 1.1 a moving target for at least another year to come (and likely even longer, who knows which wishes comes next and how long it takes to settle all the semantic issues with ephemeral state). Since the solution direction for ephemeral state is not even set yet (and ephemeral state might not even be a feature that every NETCONF/RESTCONF implementation may choose to support), I would rather work with YANG extensions as long as possible (and if not possible, consider alternatives such as YANG 1.2 once we 'understand the edits'). At this stage, my personal preference is to finish YANG 1.1 with the feature set that we have now. /js -- 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 Aug 9 13:12:08 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A80C1B2A4D for ; Sun, 9 Aug 2015 13:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6q3ArtNrZHWJ for ; Sun, 9 Aug 2015 13:12:06 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 18A2A1B2A44 for ; Sun, 9 Aug 2015 13:12:05 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 094941AE0977; Sun, 9 Aug 2015 22:12:04 +0200 (CEST) Date: Sun, 09 Aug 2015 22:13:34 +0200 (CEST) Message-Id: <20150809.221334.1054629320378717519.mbj@tail-f.com> To: rjs@rob.sh From: Martin Bjorklund In-Reply-To: <55C5054C.1090704@rob.sh> References: <55C4C346.406@rob.sh> <20150807153909.GA182@elstar.local> <55C5054C.1090704@rob.sh> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] draft-openconfig-netmod-opstate: Changes in -01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2015 20:12:07 -0000 Hi, Rob Shakir wrote: > > > Juergen Schoenwaelder wrote: > > But you are right, it is not just the path that is needed to identify > > data residing in configuration datastores. It is in general a tuple > > and for configuration data the selector is a > > configuration datastore name. > > Thanks for the clarification. Do you have examples of other (i.e., > non-NETCONF) systems that utilise this convention that a path is not > an absolute reference to a certain data node? Reviewing with various > interested parties, I'm not sure that there are clear cases that form > a precedent for this. One example is SNMP, where a tuple (enginge id, context, OID) is needed. In general you also need a device id of some sort (address, port). How the necessary info is handled seems to be an implementation detail, and it seems to be pretty trivial, but maybe I have misunderstood something. > If we consider that this then might drive some new behaviour where the > systems architecture for NMS differs from elsewhere then we might want > to question whether this is necessary complexity. Indeed, for me this > comes back to one of the discussions about the other datastores that > we had on an interim call. > > * 'startup' is really a property of the intended configuration - as to > whether it has been made persistent. In general, I see very few > changes that are made where we interact only with the persistent > version of the intended configuration; and even fewer where the > intended configuration is not made persistent. In both cases, it tends > to be the lack of a declarative configuration API that drives the need > to interact with either. I do not understand this comment. Are you proposing some kind of changes to current YANG models to handle 'startup'? Are you proposing changing NETCONF? > * 'candidate' is again a property of the intended configuration - > insofar that the 'candidate' set of configuration represents a set of > changes that have not been requested to be transitioned to the > 'applied configuration'. This makes sense when a human is working > through building up a transaction (configure protocol X, protocol Y > .. protocol Z, then commit) - but isn't quite so clear when it > programmatic interaction with the network. If I understand your terms correctly, 'running' would be the intended configuration. 'candidate' is a separate structure, that is not part of the intended configuration. Are you proposing some YANG or NETCONF changes to handle the candidate? > It is quite trivial for me to see cases where an external NMS would > never really need to interact with either of these datastores - such > that it's quite tricky for me to determine that we really want to > architect the entire NMS to be able to carry the tuple > (stealing your terms, thanks!), especially if this means that it has > to work entirely differently w.r.t paths than the rest of OSS. Even if we had the four separate datastores 'startup', 'running', 'candidate', and 'applied', it is not entirely clear to me why the datastore would have to be carried together with the path internally all the time. (We do not carry the current datastores in our system today). Maybe this is an implementation issue? /martin From nobody Sun Aug 9 13:29:14 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D49E1B2B5E for ; Sun, 9 Aug 2015 13:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbzn_ckdO1py for ; Sun, 9 Aug 2015 13:29:11 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A0B11B2B4E for ; Sun, 9 Aug 2015 13:29:10 -0700 (PDT) Received: from [70.24.199.3] (helo=corretto.local) by cappuccino.rob.sh with esmtpa (Exim 4.80) (envelope-from ) id 1ZOXDD-0007V9-9u; Sun, 09 Aug 2015 21:28:56 +0100 Message-ID: <55C7B80F.8070203@rob.sh> Date: Sun, 09 Aug 2015 16:29:03 -0400 From: Rob Shakir User-Agent: Postbox 4.0.3 (Macintosh/20150805) MIME-Version: 1.0 To: Martin Bjorklund References: <55C4C346.406@rob.sh> <20150807153909.GA182@elstar.local> <55C5054C.1090704@rob.sh> <20150809.221334.1054629320378717519.mbj@tail-f.com> In-Reply-To: <20150809.221334.1054629320378717519.mbj@tail-f.com> Content-Type: multipart/alternative; boundary="------------080304050808070607030604" Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] draft-openconfig-netmod-opstate: Changes in -01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2015 20:29:13 -0000 This is a multi-part message in MIME format. --------------080304050808070607030604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Martin, To be clear -- I'm not proposing any changes to YANG or NETCONF. I was merely trying to write down the discussion that we had on one of the interims about ways that 'datastores' may be considered by some implementations, particularly as this view can mean that they might be able to ignore them - based on the current ones that are implemented. Martin Bjorklund wrote: > Even if we had the four separate datastores 'startup', 'running', > 'candidate', and 'applied', it is not entirely clear to me why the > datastore would have to be carried together with the path internally > all the time. (We do not carry the current datastores in our system > today). Maybe this is an implementation issue? Sure, it does not have to be carried all the time, but is /is/ required in some cases. If one wants a standardised 'path' format to be passed between systems then there's going to need to be space for the 'datastore' to be carried in path references that are handed about (even if there is a 'default' datastore). I, for one, would find it messy if there needs to be context specific ways of handling what a path looks like. I find the fact that there can be ambiguity for a certain path something that is quite different from all other systems, and hence consider it to be suboptimal when compared to having a unique path to a particular set of data. Having a path that can result in different values being returned seems fragile. Best, r. --------------080304050808070607030604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Martin,

To be clear -- I'm not proposing any changes to YANG or NETCONF. I was merely trying to write down the discussion that we had on one of the interims about ways that 'datastores' may be considered by some implementations, particularly as this view can mean that they might be able to ignore them - based on the current ones that are implemented.

Martin Bjorklund wrote:
Even if we had the four separate datastores 'startup', 'running',
'candidate', and 'applied', it is not entirely clear to me why the
datastore would have to be carried together with the path internally
all the time.  (We do not carry the current datastores in our system
today).  Maybe this is an implementation issue?
Sure, it does not have to be carried all the time, but is /is/ required in some cases. If one wants a standardised 'path' format to be passed between systems then there's going to need to be space for the 'datastore' to be carried in path references that are handed about (even if there is a 'default' datastore). I, for one, would find it messy if there needs to be context specific ways of handling what a path looks like.

I find the fact that there can be ambiguity for a certain path something that is quite different from all other systems, and hence consider it to be suboptimal when compared to having a unique path to a particular set of data. Having a path that can result in different values being returned seems fragile.

Best,
r.
--------------080304050808070607030604-- From nobody Mon Aug 10 00:21:07 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA8A1ACC88 for ; Mon, 10 Aug 2015 00:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.199 X-Spam-Level: * X-Spam-Status: No, score=1.199 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_34=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CX-Ufqmn-XoT for ; Mon, 10 Aug 2015 00:21:03 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 7E42C1AC43C for ; Mon, 10 Aug 2015 00:21:02 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 0DDBC1CC0329; Mon, 10 Aug 2015 09:21:05 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman , "t.petch" In-Reply-To: References: <20150720210041.GA17614@elstar.local> <14ecceb6dd0.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <14ed0338068.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <55BBA679.7070508@labn.net> <20150801065150.GA67416@elstar.local> <002401d0cdfb$758b6760$4001a8c0@gateway.2wire.net> <03d301d0ce05$c320a800$4001a8c0@gateway.2wire.net> <01e601d0ce98$df05e240$4001a8c0@gateway.2wire.net> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Mon, 10 Aug 2015 09:21:10 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Y34 - root node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 07:21:06 -0000 Andy Bierman writes: > On Tue, Aug 4, 2015 at 2:34 AM, t.petch wrote: > >> ----- Original Message ----- >> From: "Andy Bierman" >> To: "t.petch" >> Sent: Monday, August 03, 2015 5:17 PM >> >> > ----- Original Message ----- >> > From: "Andy Bierman" >> > To: "t.petch" >> > Sent: Monday, August 03, 2015 4:10 PM >> > >> > > ----- Original Message ----- >> > > From: "Andy Bierman" andy@yumaworks.com >> > > Sent: Saturday, August 01, 2015 7:05 PM >> > > On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem (acee) >> > > >> >>> On 8/1/15, 2:51 AM, j.schoenwaelder@jacobs-university.de> wrote: >> >>> >> >>> Section 1.1 in >> >>> >> > https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt >> >>> lists the goals of a generic model structure that will accommodate >> >> most >> >>> modern network devices. I guess you don=E2=80=99t agree that these a= re >> >> desirable? >> > > >> > > The only objection I have to this draft is the insertion of a >> top-level >> > > root >> > > called "device". (Might as well be called "self"). >> > > There are no sibling nodes planned or intended for >> > > this node, so it serves as an extra document root. >> > > >> > > >> > > One aspect of YANG I have never grasped is what a root means, if >> > > anything. >> > > >> > > I understand that it is needed for NETCONF (filters) and for YANG >> > > (augments, constraints) and so must be somewhere and must be >> > relatively >> > > stable, but has it any other significance in the data model? >> > > >> > > As you may recall, I was involved with SMI first, where the root is >> > > somewhere up in the sky and life only becomes interesting some six >> > > levels down the hierarchy and that may colour my thinking. >> > > >> > >> > YANG does a poor job of defining the root for YANG data nodes. >> > It is sometimes called a datastore (in the abstract). >> > Technically, YANG borrows the definition from XPath. >> > YANG just defines top-level data nodes and the parent of >> > these nodes is the document root. >> > >> > There is no protocol or encoding neutral definition, >> > only an XML-specific definition. >> > >> > >> > >> > Thanks for that. >> > >> > It seems to me that much of the extensive discussion on Y34 (all of >> > which I have read) is as much political as technical, that is SMI is >> > hierarchical, top down, perhaps befitting its origins in ISO, whereas >> > YANG is bottom up. IETF-like. YANG could have had a single tree, but >> > doesn't. So when I read >> > >> > https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt >> > >> > I see a plea for a more hierarchical organisation, and when I read >> > >> > draft-bjorklund-netmod-openconfig-reply-00 >> > >> > I see a response that says we are not like that. >> > >> > If so, I doubt that there ever will be a technical solution. >> > >> > And I am mindful that when I configure routing in a (Cisco) router, I >> > have to do some of it under the interface definitions and some of it >> > under the definition of the routing protocol. Which is life, never >> > wholy interface-centric and never wholy routing protocol-centric! >> >> Are you saying the job would be easier if the >> path was /device/interfaces/interface instead >> of just /interfaces/interface? Are you saying >> that /protocols/routing could not also be defined? >> Clearly edit-config and copy-config allow both >> subtrees to be accessed in the same operation, >> so I don't understand your concern. >> >> I have been trying to get the root node to be better defined >> in the protocols that use YANG (i.e., ncx:root, Y34-04). >> IMO this is a better approach than defining a YANG module >> with a special container that all other modules are expected >> to augment. YANG is designed such that each vendor or SDO >> is not dependent on other vendors or SDOs in order to >> define data nodes. >> >> >> >> Andy >> >> I am agreeing with you that adding 'device' brings no technical benefit, >> rather that the motivation is the opposite of technical (which I >> referred to as political). I am also agreeing with the current declared >> consensus on Y34. >> >> And yes, YANG is going to give us a large number of modules, some >> tightly coupled (augments) some loosely so (how many do you need to >> configure OSPF?) and work in this area will be of benefit now and >> probably essential in a few years time. That said, I am unsure what >> such work would be like; I am looking (in despair) at 50 routing area >> YANG models and wondering how a user will ever get a coherent picture of >> how to do what they want to do. >> >> > > The "YANG Land Grab" gives a false sense of progress. > Reaching WG consensus on every single leaf is hard work. > > I don't think a collection of 100s of YANG modules is ever > going to to be easy to understand. Operators will not examine > a NETCONF message, look at 150 module URIs, > and say "I know exactly what this device supports". > I guess it is up to client tools to do that. > > I wrote a draft that defines YANG Packages, which can provide > a higher level of organization for YANG modules. > > http://datatracker.ietf.org/doc/draft-bierman-netmod-yang-package/ > > You and I are apparently in the minority, since the official status > is that there is no problem with the current approach, and no need > to organize individual YANG modules into any larger abstractions. > I believe most people agree something like this is needed, and the attempt to clarify import semantics in YANG 1.1 isn't meant as a replacement for packages. Lada > > > Tom Petch >> >> > > Andy > > >> Andy >> >> > Andy >> > >> > > The well-specified XPath and YANG root (/) can be >> > > accessed by all protocol operations, exactly the same >> > > as a node called 'device'. The actual node name will >> > > depend on the RPC function (e.g. 'data' or 'config'). >> > > >> > > This is more than redundant however. It introduces a "super-module" >> > > into YANG that every other module is expected to augment. >> > > YANG is intended to be more loosely coupled than that. >> > > This introduces an extra node and namespace declaration >> > > in all protocol messages, increasing message sizes. >> > > >> > > It also assumes all existing YANG models will get rewritten to >> > > account for "/device" in all path and XPath expressions. >> > > This is highly disruptive to existing deployments. >> > > Also, multiple data models to edit the same thing causes lots >> > > of extra complexity in the server (supporting both old >> > > location and new location). >> > > >> > > IMO a resource directory approach is much more realistic. >> > > The /device tree can contain all the organized NP containers. >> > > Instead of all the actual data nodes, this tree just has pointers >> > > to the real location of the resource. (like 301 Moved Permanently) >> > > >> > > > Acee >> > > > >> > > Andy >> >> >> ** Solution Y34-02 >> >> Keep 'anyxml'. Introduce 'anydata' as above but without the >> 'format' substatement. >> >> 'anyxml' would still be used to represent unrestricted XML, as is >> done in NETCONF. >> >> 'anydata' would be an unknown chunk of data that can be modelled >> with YANG. Can be encoded as xml or json. >> >> For example: >> >> #+BEGIN_EXAMPLE >> anydata data; >> #+END_EXAMPLE >> >> ** Solution Y34-05 >> >> Same as Y34-02 plus two guidelines adopted from Y34-04: >> >> - Keep 'anyxml' unchanged as it is defined in YANG 1.0. This >> ensures backward compatibility. >> - Introduce a new 'anydata' statement that represents an unknown >> chunk of data that can be modeled with YANG >> - Document that implementations MAY have restrictions for anyxml and >> that anyxml is not necessarily interoperable; data model writers >> should use anydata whenever possible. >> - The guidelines document should say that YANG Doctors will review >> each use of anyxml in IETF modules when YANG 1.1 is adopted to >> avoid its use whenever possible. >> >> >> > >> >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Aug 10 00:33:41 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 077691ACD46 for ; Mon, 10 Aug 2015 00:33:40 -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 m3TgVbbwPB_0 for ; Mon, 10 Aug 2015 00:33:38 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 04F2D1ACD49 for ; Mon, 10 Aug 2015 00:33:38 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 2F11D1CC0329; Mon, 10 Aug 2015 09:33:42 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman , Juergen Schoenwaelder , Benoit Claise , "netmod\@ietf.org" In-Reply-To: References: <20150807063205.GA75724@elstar.local> <55C4D1AD.8070402@cisco.com> <20150807155712.GA255@elstar.local> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Mon, 10 Aug 2015 09:33:47 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] NETMOD WG YANG 1.1 virtual interim meetings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 07:33:40 -0000 Andy Bierman writes: > On Fri, Aug 7, 2015 at 8:57 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > >> Lets please not mix YANG 1.1 work with other discussions at this point >> in time. >> >> > I would really like the WG and IESG to decide how YANG is going to be > updated to support ephemeral state and operational state. > > It seems there are many documents waiting on YANG 1.1, yet > only 1 or 2 actually use anything from YANG 1.1. > > If YANG 1.0 is not being deprecated then I do not see > any reason to link documents to YANG 1.1 unless they > actually use it. =E2=80=A6 or unless they use something more significant than "anydata". Specifically, witholding the RESTCONF suite is IMO counterproductive. Lada > > Is the plan to start work on YANG 1.2 before YANG 1.1 is even published? > If so, then say so. Let's not pretend YANG is stable > or that all new improvements after YANG 1.1 are going to be > done with extension hacks. > > If the IESG and the WG had a development plan for this work, > it might help vendors decide when and what to support. > > > /js >> > > Andy > > >> >> On Fri, Aug 07, 2015 at 05:41:33PM +0200, Benoit Claise wrote: >> > Dear all, >> > >> > During the YANG Model Coordination Group webex call today, we discussed >> > this oper status and structure open issues. We're ready to help >> > facilitate the discussion between the different proposals >> > We could compare the pros/cons of the different solutions from our poi= nt >> > of view. >> > >> > To allow us some preparation time, alternate proposals should be posted >> > a week before the NETMOD interim meeting, i.e. Sept 3rd. >> > >> > The YANG Model Coordination Group >> > > > >> > >The NETMOD WG will hold a series of weekly virtual interim meetings in >> > >order to resolve YANG 1.1 review comments. The meetings will take >> > >place on Mondays between 17:00-18:00 CEST. The dates for the virtual >> > >meetings are: >> > > >> > >2015-08-24 >> > >2015-08-31 >> > >2015-09-07 >> > >2015-09-14 >> > >2015-09-21 >> > >2015-09-28 >> > >2015-10-05 >> > >2015-10-12 >> > > >> > >We will use the meeting slots as needed (i.e., we may skip slots if >> > >there is nothing to resolve anymore). >> > > >> > >Additional information will be announced on the NETMOD mailing list: >> > >http://www.ietf.org/mail-archive/web/netmod/current/maillist.html >> > > >> > >/js >> > > >> > >> >> > _______________________________________________ >> > netmod mailing list >> > netmod@ietf.org >> > https://www.ietf.org/mailman/listinfo/netmod >> >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> Fax: +49 421 200 3103 >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Aug 10 01:14:17 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 034411B2CE3 for ; Mon, 10 Aug 2015 01:14:16 -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 opV-t-HW0PFR for ; Mon, 10 Aug 2015 01:14:14 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6885A1AD367 for ; Mon, 10 Aug 2015 01:14:13 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 13FAA1CC0329 for ; Mon, 10 Aug 2015 10:14:17 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Mon, 10 Aug 2015 10:14:22 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [netmod] extensions and conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 08:14:16 -0000 Hi, recent discussions show that 6020(bis) text about extensions isn't sufficiently clear about the scope and semantics of extensions. IMO this needs to be fixed and so I propose to add the following item to YANG 1.1 issue list. Comments and additional solutions are welcome. Lada ------------------------------------------------------------------------ * NEW :Yxx: clarify conformance wrt extensions ** Description YANG extensions as defined in RFC 6020 have no limits on scope=C2=A0=E2= =80=93 they can possibly modify YANG language, datastore semantics or even the NETCONF protocol. However, from the text in RFC=C2=A06020 it is unclear whether extensions appearing in YANG modules advertised by a server are mandatory to implement: "If a YANG compiler does not support a particular extension, which appears in a YANG module as an unknown-statement (see Section 12), the entire unknown-statement MAY be ignored by the compiler." ** Solution Yxx-01 =20=20=20 Extensions appearing in the server's model are an integral part of the server-client contract. That is, the server MUST implement them, and the client SHOULD terminate the session if it doesn't implement any of the extensions. ** Solution Yxx-02 Develop a mechanism for negotiating extensions. ** Solution Yxx-03 Make extensions optional. This means that extensions won't be allowed to change YANG language, NETCONF protocol, and validity of datastores and protocol messages. ------------------------------------------------------------------------ --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Aug 10 01:46:52 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7781B3358 for ; Mon, 10 Aug 2015 01:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_NONE=-0.0001] 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 3D9-f_fffvsd for ; Mon, 10 Aug 2015 01:46: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 9A33C1B3341 for ; Mon, 10 Aug 2015 01:46:46 -0700 (PDT) Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mailscan3.hi.local) by mailscan-g68.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1ZOijE-0002w7-3K; Mon, 10 Aug 2015 09:46:44 +0100 Received: from mailscanlb0.hi.local ([10.0.44.160] helo=webmail5.hi.local) by mailscan3.hi.local with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1ZOijA-0000K9-6w; Mon, 10 Aug 2015 09:46:41 +0100 Received: from localhost ([127.0.0.1]) by webmail5.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1ZOij9-00029T-GT; Mon, 10 Aug 2015 09:46:39 +0100 Message-Id: From: "Jonathan Hansford" To: "Einar Nilsen-Nygaard (einarnn)" , "Andy Bierman" X-Mailer: Atmail 6.6.0.11156 X-Originating-IP: 79.77.2.126 in-reply-to: <1FF17F20-66A0-4E68-8E07-08FD3CA76F04@cisco.com> Date: Mon, 10 Aug 2015 09:46:39 +0100 Content-Type: multipart/alternative; boundary="=_723a6bbc62437eaf520205db1b51efd0" MIME-Version: 1.0 X-Authenticated-As: jonathan@hansfords.net Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Y34 - root node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 08:46:51 -0000 --=_723a6bbc62437eaf520205db1b51efd0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =C2=A0And it is not just end users who need help to better understand YA= NG=0Amodels and how to use them. For those still on the edge, looking to= =0Afinally take the plunge and use NETCONF/YANG to configure their=0Adev= ices, help is also required to determine how best to structure=0Atheir Y= ANG models, make use of the existing ones, etc. For those who=0Ahave "gr= own up" with the developments in NETCONF and YANG, much of=0Athis is pro= bably second nature. But coming to it cold (in the sense of=0Acompiling/= writing a first set of YANG models for a device; I've been=0Afollowing t= he netconf/netmod WGs for 3+ years), it still feels very=0Amuch like a d= ark art! It is not just the individual modules, it is how=0Ato put them= together to best manage a device (let alone a system).=0AJonathan=0A=0A= ----- Original Message -----=0AFrom: "Einar Nilsen-Nygaard (einarnn)"= =0ATo:"Andy Bierman" =0ACc:"NETMOD Working Group" =0ASent:Sat, 8 Aug 20= 15 11:10:15 +0000=0ASubject:Re: [netmod] Y34 - root node=0A=0A Andy, =0A= I agree that there is a need for organization of models, but I=0Adon=E2= =80=99t have a firm position=0Aon=C2=A0draft-openconfig-netmod-model-str= ucture/draft-rtgyangdt-rtgwg-device-model=0Aor=C2=A0draft-bierman-netmod= -yang-package. But we absolutely need=0A*something* to help end-users of= the models comprehend the overall=0Astructure of models, their relation= ship and how to use them. =0A Cheers, =0A Einar =0A On Aug 4, 2015, at= 5:16 PM, Andy Bierman wrote: =0A=0AOn Tue, Aug 4, 2015 at 2:34 AM, t.p= etch wrote:=0A ----- Original Message -----=0A From: "Andy Bierman"= =0A To: "t.petch" =0A Sent: Monday, August 03, 2015 5:17 PM=0A=0A > ---= -- Original Message -----=0A > From: "Andy Bierman" =0A > To: "t.petch"= =0A > Sent: Monday, August 03, 2015 4:10 PM=0A >=0A > > ----- Original= Message -----=0A > > From: "Andy Bierman" andy@yumaworks.com [7]=0A > >= Sent: Saturday, August 01, 2015 7:05 PM=0A > > On Sat, Aug 1, 2015 at 9= :51 AM, Acee Lindem (acee) =0A > >=0A >>> On 8/1/15, 2:51 AM,=C2=A0 j.sc= hoenwaelder@jacobs-university.de [9]>=0Awrote:=0A >>>=0A >>> Section 1.1= in=0A >>>=0A >=0Ahttps://www.ietf.org/id/draft-openconfig-netmod-model-= structure-00.txt=0A[10]=0A >>> lists the goals of a generic model struct= ure that will=0Aaccommodate=0A >> most=0A >>> modern network devices. I= guess you don=E2=80=99t agree that these are=0A >> desirable?=0A > >=0A= > > The only objection I have to this draft is the insertion of a=0A to= p-level=0A > > root=0A > > called "device".=C2=A0 (Might as well be call= ed "self").=0A > > There are no sibling nodes planned or intended for=0A= > > this node, so it serves as an extra document root.=0A > >=0A > >= =0A > > One aspect of YANG I have never grasped is what a root means, i= f=0A > > anything.=0A > >=0A > > I understand that it is needed for NETC= ONF (filters) and for YANG=0A > > (augments, constraints) and so must be= somewhere and must be=0A > relatively=0A > > stable, but has it any oth= er significance in the data model?=0A > >=0A > > As you may recall, I wa= s involved with SMI first, where the root=0Ais=0A > > somewhere up in th= e sky and life only becomes interesting some=0Asix=0A > > levels down th= e hierarchy and that may colour my thinking.=0A > >=0A >=0A > YANG does= a poor job of defining the root for YANG data nodes.=0A > It is sometim= es called a datastore (in the abstract).=0A > Technically, YANG borrows= the definition from XPath.=0A > YANG just defines top-level data nodes= and the parent of=0A > these nodes is the document root.=0A >=0A > Ther= e is no protocol or encoding neutral definition,=0A > only an XML-specif= ic definition.=0A >=0A > =0A >=0A > Thanks for that.=0A >=0A > It seems= to me that much of the extensive discussion on Y34 (all of=0A > which I= have read) is as much political as technical, that is SMI=0Ais=0A > hie= rarchical, top down, perhaps befitting its origins in ISO,=0Awhereas=0A= > YANG is bottom up. IETF-like.=C2=A0 YANG could have had a single tree= ,=0Abut=0A > doesn't.=C2=A0 So when I read=0A >=0A >=0Ahttps://www.ietf.= org/id/draft-openconfig-netmod-model-structure-00.txt=0A[11]=0A >=0A > I= see a plea for a more hierarchical organisation, and when I read=0A >= =0A > draft-bjorklund-netmod-openconfig-reply-00=0A >=0A > I see a respo= nse that says we are not like that.=0A >=0A > If so, I doubt that there= ever will be a technical solution.=0A >=0A > And I am mindful that when= I configure routing in a (Cisco) router,=0AI=0A > have to do some of it= under the interface definitions and some of=0Ait=0A > under the definit= ion of the routing protocol.=C2=A0 Which is life,=0Anever=0A > wholy int= erface-centric and never wholy routing protocol-centric!=0A=0A Are you s= aying the job would be easier if the=0A path was /device/interfaces/inte= rface instead=0A of just /interfaces/interface?=C2=A0 Are you saying=0A= that /protocols/routing could not also be defined?=0A Clearly edit-conf= ig and copy-config allow both=0A subtrees to be accessed in the same ope= ration,=0A so I don't understand your concern.=0A=0A I have been trying= to get the root node to be better defined=0A in the protocols that use= YANG (i.e., ncx:root, Y34-04).=0A IMO this is a better approach than de= fining a YANG module=0A with a special container that all other modules= are expected=0A to augment.=C2=A0 YANG is designed such that each vendo= r or SDO=0A is not dependent on other vendors or SDOs in order to=0A def= ine data nodes.=0A=0A Andy=0A=0A I am agreeing with you that adding 'dev= ice' brings no technical=0Abenefit,=0A rather that the motivation is the= opposite of technical (which I=0A referred to as political). I am also= agreeing with the current=0Adeclared=0A consensus on Y34.=0A=0A And yes= , YANG is going to give us a large number of modules, some=0A tightly co= upled (augments) some loosely so (how many do you need to=0A configure O= SPF?) and work in this area will be of benefit now and=0A probably essen= tial in a few years time.=C2=A0 That said, I am unsure what=0A such work= would be like; I am looking (in despair) at 50 routing area=0A YANG mod= els and wondering how a user will ever get a coherent picture=0Aof=0A ho= w to do what they want to do.=0A=0A The "YANG Land Grab" gives a false s= ense of progress. Reaching WG=0Aconsensus on every single leaf is hard w= ork. =0A I don't think a collection of 100s of YANG modules is ever=0A g= oing to to be easy to understand.=C2=A0 Operators will not examine a=0AN= ETCONF message, look at 150 module URIs, and say "I know exactly=0Awhat= this device supports". I guess it is up to client tools to do=0Athat.= =0A I wrote a draft that defines YANG Packages, which can provide a=0Ah= igher level of organization for YANG modules. =0A http://datatracker.iet= f.org/doc/draft-bierman-netmod-yang-package/=0A[12]=0A=0A You and I are= apparently in the minority, since the official status=0Ais that there i= s no problem with the current approach, and no need to=0Aorganize indivi= dual YANG modules into any larger abstractions. =0A=0A =C2=A0Tom Petch= =0A=0A Andy =C2=A0 Andy=0A=0A > Andy=0A >=0A > > The well-specified XPa= th and YANG root (/) can be=0A > > accessed by all protocol operations,= exactly the same=0A > > as a node called 'device'.=C2=A0 The actual nod= e name will=0A > > depend on the RPC function (e.g. 'data' or 'config').= =0A > >=0A > > This is more than redundant however.=C2=A0 It introduces= a=0A"super-module"=0A > > into YANG that every other module is expected= to augment.=0A > > YANG is intended to be more loosely coupled than tha= t.=0A > > This introduces an extra node and namespace declaration=0A > >= in all protocol messages, increasing message sizes.=0A > >=0A > > It al= so assumes all existing YANG models will get rewritten to=0A > > account= for "/device" in all path and XPath expressions.=0A > > This is highly= disruptive to existing deployments.=0A > > Also, multiple data models t= o edit the same thing causes lots=0A > > of extra complexity in the serv= er (supporting both old=0A > > location and new location).=0A > >=0A > >= IMO a resource directory approach is much more realistic.=0A > > The /d= evice tree can contain all the organized NP containers.=0A > > Instead o= f all the actual data nodes, this tree just has pointers=0A > > to the r= eal location of the resource. (like 301 Moved=0APermanently)=0A > >=0A >= > > Acee=0A > > >=0A > > Andy=0A=0A ** Solution Y34-02=0A=0A =C2=A0 Kee= p 'anyxml'.=C2=A0 Introduce 'anydata' as above but without the=0A =C2=A0= 'format' substatement.=0A=0A =C2=A0 'anyxml' would still be used to rep= resent unrestricted XML, as is=0A =C2=A0 done in NETCONF.=0A=0A =C2=A0 '= anydata' would be an unknown chunk of data that can be modelled=0A =C2= =A0 with YANG.=C2=A0 Can be encoded as xml or json.=0A=0A =C2=A0 For exa= mple:=0A=0A =C2=A0 =C2=A0 #+BEGIN_EXAMPLE=0A =C2=A0 =C2=A0 anydata data;= =0A =C2=A0 =C2=A0 #+END_EXAMPLE=0A=0A ** Solution Y34-05=0A=0A =C2=A0= =C2=A0Same as Y34-02 plus two guidelines adopted from Y34-04:=0A=0A =C2= =A0 =C2=A0- Keep 'anyxml' unchanged as it is defined in YANG 1.0. This= =0A =C2=A0 =C2=A0 =C2=A0ensures backward compatibility.=0A =C2=A0 =C2=A0= - Introduce a new 'anydata' statement that represents an unknown=0A =C2= =A0 =C2=A0 =C2=A0chunk of data that can be modeled with YANG=0A =C2=A0= =C2=A0- Document that implementations MAY have restrictions for anyxml= =0Aand=0A =C2=A0 =C2=A0 =C2=A0that anyxml is not necessarily interoperab= le; data model=0Awriters=0A =C2=A0 =C2=A0 =C2=A0should use anydata whene= ver possible.=0A =C2=A0 =C2=A0- The guidelines document should say that= YANG Doctors will=0Areview=0A =C2=A0 =C2=A0 =C2=A0each use of anyxml in= IETF modules when YANG 1.1 is adopted=0Ato=0A =C2=A0 =C2=A0 =C2=A0avoid= its use whenever possible.=0A=0A >=0A=0A _____________________________= __________________=0A netmod mailing list=0Anetmod@ietf.org [13]=0A http= s://www.ietf.org/mailman/listinfo/netmod=0A=0A =0A=0ALinks:=0A------=0A[= 1] mailto:andy@yumaworks.com=0A[2] mailto:ietfc@btconnect.com=0A[3] mail= to:andy@yumaworks.com=0A[4] mailto:ietfc@btconnect.com=0A[5] mailto:andy= @yumaworks.com=0A[6] mailto:ietfc@btconnect.com=0A[7] mailto:andy@yumawo= rks.com=0A[8] mailto:acee@cisco.com=0A[9] mailto:j.schoenwaelder@jacobs-= university.de=0A[10]=0Ahttps://www.ietf.org/id/draft-openconfig-netmod-m= odel-structure-00.txt=0A[11]=0Ahttps://www.ietf.org/id/draft-openconfig-= netmod-model-structure-00.txt=0A[12]=0Ahttp://datatracker.ietf.org/doc/d= raft-bierman-netmod-yang-package/=0A[13] mailto:netmod@ietf.org=0A --=_723a6bbc62437eaf520205db1b51efd0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =C2=A0And it is not just end users who need hel= p to better understand YANG models and how to use them. For those still= on the edge, looking to finally take the plunge and use NETCONF/YANG to= configure their devices, help is also required to determine how best to= structure their YANG models, make use of the existing ones, etc. For th= ose who have "grown up" with the developments in NETCONF and YANG, much= of this is probably second nature. But coming to it cold (in the sense= of compiling/writing a first set of YANG models for a device; I've been= following the netconf/netmod WGs for 3+ years), it still feels very muc= h like a dark art! It is not just the individual modules, it is how to p= ut them together to best manage a device (let alone a system).

Jonathan



----- Original M= essage -----
From:
"Einar Nilsen-Nygaard (ein= arnn)" <einarnn@cisco.com>

To:
"Andy Bierman" <andy@yumaworks.com>
Cc:
"NETMOD Working Group" <netmod@ietf.o= rg>
Sent:
Sat, 8 Aug 2015= 11:10:15 +0000
Subject:
Re:= [netmod] Y34 - root node


=0AAndy,=0A

= =0A
I agree that there is a need for organization of models, but I d= on=E2=80=99t have a firm position on=C2=A0draft-openconfig-netmod-model-= structure/draft-rtgyangdt-rtgwg-device-model or=C2=A0draft-bierman-netmo= d-yang-package. But we absolutely need *something* to=0A help end-users= of the models comprehend the overall structure of models, their relatio= nship and how to use them.
=0A

=0A
Cheers,=0A

=0A
Einar
=0A

=0A=0A
On Aug 4, 2015, at 5:16 PM, Andy Bierman <andy@yumaworks.com> wrote:
=0A
=0A


On Tue, Aug 4, 2015= at 2:34 AM, t.petch =0A<ietfc@btconnect.com> wrote:
=0A----- Original Message -----
=0AFrom: "A= ndy Bierman" <andy@yumaworks.co= m>
=0ATo: "t.petch" <ietfc@btconnect.com>
=0ASent: Monday, August 03, 2015 5:1= 7 PM

=0A> ----- Original Message -----
=0A> From:= "Andy Bierman" <andy@yumaworks= com>
=0A> To: "t.petch" <ietfc@btconnect.com>
=0A> Sent: Monday, August= 03, 2015 4:10 PM
=0A>
=0A> > ----- Original Message= -----
=0A> > From: "Andy Bierman" andy@yumaworks.com
=0A> > Sent: Saturday, Aug= ust 01, 2015 7:05 PM
=0A> > On Sat, Aug 1, 2015 at 9:51 AM, A= cee Lindem (acee) <acee@cisco.com>
=0A> >
=0A>>> On 8/1/15, 2:51 AM,=C2=A0= =0Aj.schoenwael= der@jacobs-university.de> wrote:
=0A>>>
=0A>= ;>> Section 1.1 in
=0A>>>
=0A> = =0Ahttps://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.tx= t
=0A>>> lists the goals of a generic model structure= that will accommodate
=0A>> most
=0A>>> modern= network devices. I guess you don=E2=80=99t agree that these are
= =0A>> desirable?
=0A> >
=0A> > The only obje= ction I have to this draft is the insertion of a
=0Atop-level
= =0A> > root
=0A> > called "device".=C2=A0 (Might as wel= l be called "self").
=0A> > There are no sibling nodes planne= d or intended for
=0A> > this node, so it serves as an extra= document root.
=0A> >
=0A> > <tp>
=0A&= gt; > One aspect of YANG I have never grasped is what a root means, i= f
=0A> > anything.
=0A> >
=0A> > I unde= rstand that it is needed for NETCONF (filters) and for YANG
=0A>= > (augments, constraints) and so must be somewhere and must be
= =0A> relatively
=0A> > stable, but has it any other signif= icance in the data model?
=0A> >
=0A> > As you may= recall, I was involved with SMI first, where the root is
=0A> &= gt; somewhere up in the sky and life only becomes interesting some six=0A> > levels down the hierarchy and that may colour my thinki= ng.
=0A> >
=0A>
=0A> YANG does a poor job of= defining the root for YANG data nodes.
=0A> It is sometimes cal= led a datastore (in the abstract).
=0A> Technically, YANG borrow= s the definition from XPath.
=0A> YANG just defines top-level da= ta nodes and the parent of
=0A> these nodes is the document root=
=0A>
=0A> There is no protocol or encoding neutral def= inition,
=0A> only an XML-specific definition.
=0A>
=0A> <tp>
=0A>
=0A> Thanks for that.
=0A&= gt;
=0A> It seems to me that much of the extensive discussion on= Y34 (all of
=0A> which I have read) is as much political as tec= hnical, that is SMI is
=0A> hierarchical, top down, perhaps befi= tting its origins in ISO, whereas
=0A> YANG is bottom up. IETF-l= ike.=C2=A0 YANG could have had a single tree, but
=0A> doesn't.= =C2=A0 So when I read
=0A>
=0A> =0Ahttps://ww= w.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt
= =0A>
=0A> I see a plea for a more hierarchical organisation,= and when I read
=0A>
=0A> draft-bjorklund-netmod-openco= nfig-reply-00
=0A>
=0A> I see a response that says we ar= e not like that.
=0A>
=0A> If so, I doubt that there eve= r will be a technical solution.
=0A>
=0A> And I am mindf= ul that when I configure routing in a (Cisco) router, I
=0A> hav= e to do some of it under the interface definitions and some of it
= =0A> under the definition of the routing protocol.=C2=A0 Which is lif= e, never
=0A> wholy interface-centric and never wholy routing pr= otocol-centric!

=0AAre you saying the job would be easier if= the
=0Apath was /device/interfaces/interface instead
=0Aof ju= st /interfaces/interface?=C2=A0 Are you saying
=0Athat /protocols/r= outing could not also be defined?
=0AClearly edit-config and copy-c= onfig allow both
=0Asubtrees to be accessed in the same operation,<= br />=0Aso I don't understand your concern.

=0AI have been tr= ying to get the root node to be better defined
=0Ain the protocols= that use YANG (i.e., ncx:root, Y34-04).
=0AIMO this is a better ap= proach than defining a YANG module
=0Awith a special container that= all other modules are expected
=0Ato augment.=C2=A0 YANG is design= ed such that each vendor or SDO
=0Ais not dependent on other vendor= s or SDOs in order to
=0Adefine data nodes.

=0A<tp>= ;

=0AAndy

=0AI am agreeing with you that adding 'd= evice' brings no technical benefit,
=0Arather that the motivation i= s the opposite of technical (which I
=0Areferred to as political).= I am also agreeing with the current declared
=0Aconsensus on Y34.<= br />
=0AAnd yes, YANG is going to give us a large number of module= s, some
=0Atightly coupled (augments) some loosely so (how many do= you need to
=0Aconfigure OSPF?) and work in this area will be of b= enefit now and
=0Aprobably essential in a few years time.=C2=A0 Tha= t said, I am unsure what
=0Asuch work would be like; I am looking (= in despair) at 50 routing area
=0AYANG models and wondering how a u= ser will ever get a coherent picture of
=0Ahow to do what they want= to do.

=0A

=0A

= =0A
The "YANG Land Grab" gives a false sense of progress.
=0AReaching WG consensus on every single leaf is hard work.
=0A
=0A
I don't think a collection of 100s of YANG modules= is ever
=0A
going to to be easy to understand.=C2=A0 Ope= rators will not examine
=0A
a NETCONF <hello> message, lo= ok at 150 module URIs,
=0A
and say "I know exactly what this de= vice supports".
=0A
I guess it is up to client tools to do that=
=0A

=0A
I wrote a draft that defines YANG Pac= kages, which can provide
=0A
a higher level of organization for= YANG modules.
=0A

=0A=0A
=0A
You and I are apparently in the minority, since the= official status
=0A
is that there is no problem with the curre= nt approach, and no need
=0A
to organize individual YANG module= s into any larger abstractions.
=0A

=0A

<= /div>=0A

=0A
=0A=C2=A0= Tom Petch

=0A

=0A

=0A
Andy
=0A
=C2=A0
=0A
=0AAndy

=0A> Andy
=0A>
=0A> > The= well-specified XPath and YANG root (/) can be
=0A> > accesse= d by all protocol operations, exactly the same
=0A> > as a no= de called 'device'.=C2=A0 The actual node name will
=0A> > de= pend on the RPC function (e.g. 'data' or 'config').
=0A> >=0A> > This is more than redundant however.=C2=A0 It introduces= a "super-module"
=0A> > into YANG that every other module is= expected to augment.
=0A> > YANG is intended to be more loos= ely coupled than that.
=0A> > This introduces an extra node a= nd namespace declaration
=0A> > in all protocol messages, inc= reasing message sizes.
=0A> >
=0A> > It also assum= es all existing YANG models will get rewritten to
=0A> > acco= unt for "/device" in all path and XPath expressions.
=0A> > T= his is highly disruptive to existing deployments.
=0A> > Also= , multiple data models to edit the same thing causes lots
=0A> &= gt; of extra complexity in the server (supporting both old
=0A>= > location and new location).
=0A> >
=0A> > IM= O a resource directory approach is much more realistic.
=0A> >= ; The /device tree can contain all the organized NP containers.
=0A= > > Instead of all the actual data nodes, this tree just has point= ers
=0A> > to the real location of the resource. (like 301 Mo= ved Permanently)
=0A> >
=0A> > > Acee
=0A&= gt; > >
=0A> > Andy


=0A** Solution Y34= -02

=0A=C2=A0 Keep 'anyxml'.=C2=A0 Introduce 'anydata' as abo= ve but without the
=0A=C2=A0 'format' substatement.

=0A= =C2=A0 'anyxml' would still be used to represent unrestricted XML, as is=
=0A=C2=A0 done in NETCONF.

=0A=C2=A0 'anydata' would be= an unknown chunk of data that can be modelled
=0A=C2=A0 with YANG.= =C2=A0 Can be encoded as xml or json.

=0A=C2=A0 For example:<= br />
=0A=C2=A0 =C2=A0 #+BEGIN_EXAMPLE
=0A=C2=A0 =C2=A0 anydat= a data;
=0A=C2=A0 =C2=A0 #+END_EXAMPLE

=0A** Solution Y3= 4-05

=0A=C2=A0 =C2=A0Same as Y34-02 plus two guidelines adopt= ed from Y34-04:

=0A=C2=A0 =C2=A0- Keep 'anyxml' unchanged as= it is defined in YANG 1.0. This
=0A=C2=A0 =C2=A0 =C2=A0ensures bac= kward compatibility.
=0A=C2=A0 =C2=A0- Introduce a new 'anydata' st= atement that represents an unknown
=0A=C2=A0 =C2=A0 =C2=A0chunk of= data that can be modeled with YANG
=0A=C2=A0 =C2=A0- Document that= implementations MAY have restrictions for anyxml and
=0A=C2=A0 =C2= =A0 =C2=A0that anyxml is not necessarily interoperable; data model write= rs
=0A=C2=A0 =C2=A0 =C2=A0should use anydata whenever possible.=0A=C2=A0 =C2=A0- The guidelines document should say that YANG Doctor= s will review
=0A=C2=A0 =C2=A0 =C2=A0each use of anyxml in IETF mod= ules when YANG 1.1 is adopted to
=0A=C2=A0 =C2=A0 =C2=A0avoid its u= se whenever possible.


=0A>

= =0A
=0A
=0A=0A____________________________________= ___________
=0Anetmod mailing list
netmod@ietf.org
=0Ahttps://www.ietf.org/mailman/listinf= o/netmod
=0A=0A=0A
=0A=0A --=_723a6bbc62437eaf520205db1b51efd0-- From nobody Mon Aug 10 02:30:05 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A59801B33B4 for ; Mon, 10 Aug 2015 02:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.31 X-Spam-Level: X-Spam-Status: No, score=-13.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_34=0.6, 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 osz9YDNYvFVl for ; Mon, 10 Aug 2015 02:29:54 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A7AB1B33B3 for ; Mon, 10 Aug 2015 02:29:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=37236; q=dns/txt; s=iport; t=1439198994; x=1440408594; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=aIdmBeD6wHswE7HihUotLItQnBYz8pM1uchmex8/8JM=; b=ENkh/VNwWhxc2OzsvP9YUzmhepFAhoXGNst4dMWvFy3yDaBWibEMJEyK kET2BJIHjuhR0i4u7n7t8s+kL4LAg6GXHxbFOxOvye80DYYzmU1qKFAOp f+y897z0NjUIkHnoeH9LY6u8u8Dy2cQ/eqxYbkAvZhpEu37lKzCfuYW1D M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A5CgBtbshV/5xdJa1dgk5NVGkGgx6qJI9Cgi0BCYUvSgIcgRM8EAEBAQEBAQGBCoQjAQEBAwEBAQEgSwQHBQcEAgEIEAEEAQEBFQsHAwICAiULFAkIAgQOBRkCiAsIDbgYlWEBAQEBAQEBAQEBAQEBAQEBAQEBAQEXik6BA4Q+MBcEBwYEgl8vgRQFjFQBiDYBhQGCaYR4gUlGhnaNEoNmERWCDhyBU3EBgUeBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,644,1432598400"; d="scan'208,217";a="177138850" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-4.cisco.com with ESMTP; 10 Aug 2015 09:29:52 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t7A9TqXl004641 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 10 Aug 2015 09:29:52 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 10 Aug 2015 04:29:51 -0500 Received: from xhc-aln-x13.cisco.com (173.36.12.87) by xch-aln-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Mon, 10 Aug 2015 04:29:51 -0500 Received: from xmb-aln-x15.cisco.com ([169.254.9.148]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0248.002; Mon, 10 Aug 2015 04:29:51 -0500 From: "Einar Nilsen-Nygaard (einarnn)" To: Jonathan Hansford Thread-Topic: [netmod] Y34 - root node Thread-Index: AQHQzfwQ7zjuRBGFiEyMX11aiFLAyp36tNgA//+74pCAAFbtgIAAz0+UgADCtACABfPGAIAC/I6AgAAMEQA= Date: Mon, 10 Aug 2015 09:29:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.36.7.29] Content-Type: multipart/alternative; boundary="_000_B638E6EC24C3481981074C97EF366833ciscocom_" MIME-Version: 1.0 Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Y34 - root node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 09:30:01 -0000 --_000_B638E6EC24C3481981074C97EF366833ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgc29tZW9uZSBzaGFyaW5nIHJlc3BvbnNpYmlsaXRpZXMgZm9yIGd1aWRpbmcgYSBudW1iZXIg b2YgZGV2ZWxvcG1lbnQgdGVhbXMgYm90aCBkZWZpbmluZyBuZXcgbW9kZWxzIGFuZCBpbXBsZW1l bnRpbmcgdG8gc29tZSBhbHJlYWR5IGRlZmluZWQgbW9kZWxzIGluIHRoaXMgYXJlYSwgSSBjYW4g b25seSBhZ3JlZSB3aXRoIHRoaXMgYWRkaXRpb24gdG8gd2hhdCBJIHNhaWQgZWFybGllci4NCg0K Q2hlZXJzLA0KDQpFaW5hcg0KDQpPbiBBdWcgMTAsIDIwMTUsIGF0IDk6NDYgQU0sIEpvbmF0aGFu IEhhbnNmb3JkIDxqb25hdGhhbkBoYW5zZm9yZHMubmV0PG1haWx0bzpqb25hdGhhbkBoYW5zZm9y ZHMubmV0Pj4gd3JvdGU6DQoNCiBBbmQgaXQgaXMgbm90IGp1c3QgZW5kIHVzZXJzIHdobyBuZWVk IGhlbHAgdG8gYmV0dGVyIHVuZGVyc3RhbmQgWUFORyBtb2RlbHMgYW5kIGhvdyB0byB1c2UgdGhl bS4gRm9yIHRob3NlIHN0aWxsIG9uIHRoZSBlZGdlLCBsb29raW5nIHRvIGZpbmFsbHkgdGFrZSB0 aGUgcGx1bmdlIGFuZCB1c2UgTkVUQ09ORi9ZQU5HIHRvIGNvbmZpZ3VyZSB0aGVpciBkZXZpY2Vz LCBoZWxwIGlzIGFsc28gcmVxdWlyZWQgdG8gZGV0ZXJtaW5lIGhvdyBiZXN0IHRvIHN0cnVjdHVy ZSB0aGVpciBZQU5HIG1vZGVscywgbWFrZSB1c2Ugb2YgdGhlIGV4aXN0aW5nIG9uZXMsIGV0Yy4g Rm9yIHRob3NlIHdobyBoYXZlICJncm93biB1cCIgd2l0aCB0aGUgZGV2ZWxvcG1lbnRzIGluIE5F VENPTkYgYW5kIFlBTkcsIG11Y2ggb2YgdGhpcyBpcyBwcm9iYWJseSBzZWNvbmQgbmF0dXJlLiBC dXQgY29taW5nIHRvIGl0IGNvbGQgKGluIHRoZSBzZW5zZSBvZiBjb21waWxpbmcvd3JpdGluZyBh IGZpcnN0IHNldCBvZiBZQU5HIG1vZGVscyBmb3IgYSBkZXZpY2U7IEkndmUgYmVlbiBmb2xsb3dp bmcgdGhlIG5ldGNvbmYvbmV0bW9kIFdHcyBmb3IgMysgeWVhcnMpLCBpdCBzdGlsbCBmZWVscyB2 ZXJ5IG11Y2ggbGlrZSBhIGRhcmsgYXJ0ISBJdCBpcyBub3QganVzdCB0aGUgaW5kaXZpZHVhbCBt b2R1bGVzLCBpdCBpcyBob3cgdG8gcHV0IHRoZW0gdG9nZXRoZXIgdG8gYmVzdCBtYW5hZ2UgYSBk ZXZpY2UgKGxldCBhbG9uZSBhIHN5c3RlbSkuDQoNCkpvbmF0aGFuDQoNCg0KDQotLS0tLSBPcmln aW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOg0KIkVpbmFyIE5pbHNlbi1OeWdhYXJkIChlaW5hcm5u KSIgPGVpbmFybm5AY2lzY28uY29tPG1haWx0bzplaW5hcm5uQGNpc2NvLmNvbT4+DQoNClRvOg0K IkFuZHkgQmllcm1hbiIgPGFuZHlAeXVtYXdvcmtzLmNvbTxtYWlsdG86YW5keUB5dW1hd29ya3Mu Y29tPj4NCkNjOg0KIk5FVE1PRCBXb3JraW5nIEdyb3VwIiA8bmV0bW9kQGlldGYub3JnPG1haWx0 bzpuZXRtb2RAaWV0Zi5vcmc+Pg0KU2VudDoNClNhdCwgOCBBdWcgMjAxNSAxMToxMDoxNSArMDAw MA0KU3ViamVjdDoNClJlOiBbbmV0bW9kXSBZMzQgLSByb290IG5vZGUNCg0KDQpBbmR5LA0KDQpJ IGFncmVlIHRoYXQgdGhlcmUgaXMgYSBuZWVkIGZvciBvcmdhbml6YXRpb24gb2YgbW9kZWxzLCBi dXQgSSBkb27igJl0IGhhdmUgYSBmaXJtIHBvc2l0aW9uIG9uIGRyYWZ0LW9wZW5jb25maWctbmV0 bW9kLW1vZGVsLXN0cnVjdHVyZS9kcmFmdC1ydGd5YW5nZHQtcnRnd2ctZGV2aWNlLW1vZGVsIG9y IGRyYWZ0LWJpZXJtYW4tbmV0bW9kLXlhbmctcGFja2FnZS4gQnV0IHdlIGFic29sdXRlbHkgbmVl ZCAqc29tZXRoaW5nKiB0byBoZWxwIGVuZC11c2VycyBvZiB0aGUgbW9kZWxzIGNvbXByZWhlbmQg dGhlIG92ZXJhbGwgc3RydWN0dXJlIG9mIG1vZGVscywgdGhlaXIgcmVsYXRpb25zaGlwIGFuZCBo b3cgdG8gdXNlIHRoZW0uDQoNCkNoZWVycywNCg0KRWluYXINCg0KT24gQXVnIDQsIDIwMTUsIGF0 IDU6MTYgUE0sIEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPG1haWx0bzphbmR5QHl1 bWF3b3Jrcy5jb20+PiB3cm90ZToNCg0KDQoNCk9uIFR1ZSwgQXVnIDQsIDIwMTUgYXQgMjozNCBB TSwgdC5wZXRjaCA8aWV0ZmNAYnRjb25uZWN0LmNvbTxtYWlsdG86aWV0ZmNAYnRjb25uZWN0LmNv bT4+IHdyb3RlOg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogIkFuZHkgQmll cm1hbiIgPGFuZHlAeXVtYXdvcmtzLmNvbTxtYWlsdG86YW5keUB5dW1hd29ya3MuY29tPj4NClRv OiAidC5wZXRjaCIgPGlldGZjQGJ0Y29ubmVjdC5jb208bWFpbHRvOmlldGZjQGJ0Y29ubmVjdC5j b20+Pg0KU2VudDogTW9uZGF5LCBBdWd1c3QgMDMsIDIwMTUgNToxNyBQTQ0KDQo+IC0tLS0tIE9y aWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4gRnJvbTogIkFuZHkgQmllcm1hbiIgPGFuZHlAeXVtYXdv cmtzY29tPG1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20+Pg0KPiBUbzogInQucGV0Y2giIDxpZXRm Y0BidGNvbm5lY3QuY29tPG1haWx0bzppZXRmY0BidGNvbm5lY3QuY29tPj4NCj4gU2VudDogTW9u ZGF5LCBBdWd1c3QgMDMsIDIwMTUgNDoxMCBQTQ0KPg0KPiA+IC0tLS0tIE9yaWdpbmFsIE1lc3Nh Z2UgLS0tLS0NCj4gPiBGcm9tOiAiQW5keSBCaWVybWFuIiBhbmR5QHl1bWF3b3Jrcy5jb208bWFp bHRvOmFuZHlAeXVtYXdvcmtzLmNvbT4NCj4gPiBTZW50OiBTYXR1cmRheSwgQXVndXN0IDAxLCAy MDE1IDc6MDUgUE0NCj4gPiBPbiBTYXQsIEF1ZyAxLCAyMDE1IGF0IDk6NTEgQU0sIEFjZWUgTGlu ZGVtIChhY2VlKSA8YWNlZUBjaXNjby5jb208bWFpbHRvOmFjZWVAY2lzY28uY29tPj4NCj4gPg0K Pj4+IE9uIDgvMS8xNSwgMjo1MSBBTSwgIGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0 eS5kZTxtYWlsdG86ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPj4gd3JvdGU6 DQo+Pj4NCj4+PiBTZWN0aW9uIDEuMSBpbg0KPj4+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL2lk L2RyYWZ0LW9wZW5jb25maWctbmV0bW9kLW1vZGVsLXN0cnVjdHVyZS0wMC50eHQNCj4+PiBsaXN0 cyB0aGUgZ29hbHMgb2YgYSBnZW5lcmljIG1vZGVsIHN0cnVjdHVyZSB0aGF0IHdpbGwgYWNjb21t b2RhdGUNCj4+IG1vc3QNCj4+PiBtb2Rlcm4gbmV0d29yayBkZXZpY2VzLiBJIGd1ZXNzIHlvdSBk b27igJl0IGFncmVlIHRoYXQgdGhlc2UgYXJlDQo+PiBkZXNpcmFibGU/DQo+ID4NCj4gPiBUaGUg b25seSBvYmplY3Rpb24gSSBoYXZlIHRvIHRoaXMgZHJhZnQgaXMgdGhlIGluc2VydGlvbiBvZiBh DQp0b3AtbGV2ZWwNCj4gPiByb290DQo+ID4gY2FsbGVkICJkZXZpY2UiLiAgKE1pZ2h0IGFzIHdl bGwgYmUgY2FsbGVkICJzZWxmIikuDQo+ID4gVGhlcmUgYXJlIG5vIHNpYmxpbmcgbm9kZXMgcGxh bm5lZCBvciBpbnRlbmRlZCBmb3INCj4gPiB0aGlzIG5vZGUsIHNvIGl0IHNlcnZlcyBhcyBhbiBl eHRyYSBkb2N1bWVudCByb290Lg0KPiA+DQo+ID4gPHRwPg0KPiA+IE9uZSBhc3BlY3Qgb2YgWUFO RyBJIGhhdmUgbmV2ZXIgZ3Jhc3BlZCBpcyB3aGF0IGEgcm9vdCBtZWFucywgaWYNCj4gPiBhbnl0 aGluZy4NCj4gPg0KPiA+IEkgdW5kZXJzdGFuZCB0aGF0IGl0IGlzIG5lZWRlZCBmb3IgTkVUQ09O RiAoZmlsdGVycykgYW5kIGZvciBZQU5HDQo+ID4gKGF1Z21lbnRzLCBjb25zdHJhaW50cykgYW5k IHNvIG11c3QgYmUgc29tZXdoZXJlIGFuZCBtdXN0IGJlDQo+IHJlbGF0aXZlbHkNCj4gPiBzdGFi bGUsIGJ1dCBoYXMgaXQgYW55IG90aGVyIHNpZ25pZmljYW5jZSBpbiB0aGUgZGF0YSBtb2RlbD8N Cj4gPg0KPiA+IEFzIHlvdSBtYXkgcmVjYWxsLCBJIHdhcyBpbnZvbHZlZCB3aXRoIFNNSSBmaXJz dCwgd2hlcmUgdGhlIHJvb3QgaXMNCj4gPiBzb21ld2hlcmUgdXAgaW4gdGhlIHNreSBhbmQgbGlm ZSBvbmx5IGJlY29tZXMgaW50ZXJlc3Rpbmcgc29tZSBzaXgNCj4gPiBsZXZlbHMgZG93biB0aGUg aGllcmFyY2h5IGFuZCB0aGF0IG1heSBjb2xvdXIgbXkgdGhpbmtpbmcuDQo+ID4NCj4NCj4gWUFO RyBkb2VzIGEgcG9vciBqb2Igb2YgZGVmaW5pbmcgdGhlIHJvb3QgZm9yIFlBTkcgZGF0YSBub2Rl cy4NCj4gSXQgaXMgc29tZXRpbWVzIGNhbGxlZCBhIGRhdGFzdG9yZSAoaW4gdGhlIGFic3RyYWN0 KS4NCj4gVGVjaG5pY2FsbHksIFlBTkcgYm9ycm93cyB0aGUgZGVmaW5pdGlvbiBmcm9tIFhQYXRo Lg0KPiBZQU5HIGp1c3QgZGVmaW5lcyB0b3AtbGV2ZWwgZGF0YSBub2RlcyBhbmQgdGhlIHBhcmVu dCBvZg0KPiB0aGVzZSBub2RlcyBpcyB0aGUgZG9jdW1lbnQgcm9vdA0KPg0KPiBUaGVyZSBpcyBu byBwcm90b2NvbCBvciBlbmNvZGluZyBuZXV0cmFsIGRlZmluaXRpb24sDQo+IG9ubHkgYW4gWE1M LXNwZWNpZmljIGRlZmluaXRpb24uDQo+DQo+IDx0cD4NCj4NCj4gVGhhbmtzIGZvciB0aGF0Lg0K Pg0KPiBJdCBzZWVtcyB0byBtZSB0aGF0IG11Y2ggb2YgdGhlIGV4dGVuc2l2ZSBkaXNjdXNzaW9u IG9uIFkzNCAoYWxsIG9mDQo+IHdoaWNoIEkgaGF2ZSByZWFkKSBpcyBhcyBtdWNoIHBvbGl0aWNh bCBhcyB0ZWNobmljYWwsIHRoYXQgaXMgU01JIGlzDQo+IGhpZXJhcmNoaWNhbCwgdG9wIGRvd24s IHBlcmhhcHMgYmVmaXR0aW5nIGl0cyBvcmlnaW5zIGluIElTTywgd2hlcmVhcw0KPiBZQU5HIGlz IGJvdHRvbSB1cC4gSUVURi1saWtlLiAgWUFORyBjb3VsZCBoYXZlIGhhZCBhIHNpbmdsZSB0cmVl LCBidXQNCj4gZG9lc24ndC4gIFNvIHdoZW4gSSByZWFkDQo+DQo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL2lkL2RyYWZ0LW9wZW5jb25maWctbmV0bW9kLW1vZGVsLXN0cnVjdHVyZS0wMC50eHQNCj4N Cj4gSSBzZWUgYSBwbGVhIGZvciBhIG1vcmUgaGllcmFyY2hpY2FsIG9yZ2FuaXNhdGlvbiwgYW5k IHdoZW4gSSByZWFkDQo+DQo+IGRyYWZ0LWJqb3JrbHVuZC1uZXRtb2Qtb3BlbmNvbmZpZy1yZXBs eS0wMA0KPg0KPiBJIHNlZSBhIHJlc3BvbnNlIHRoYXQgc2F5cyB3ZSBhcmUgbm90IGxpa2UgdGhh dC4NCj4NCj4gSWYgc28sIEkgZG91YnQgdGhhdCB0aGVyZSBldmVyIHdpbGwgYmUgYSB0ZWNobmlj YWwgc29sdXRpb24uDQo+DQo+IEFuZCBJIGFtIG1pbmRmdWwgdGhhdCB3aGVuIEkgY29uZmlndXJl IHJvdXRpbmcgaW4gYSAoQ2lzY28pIHJvdXRlciwgSQ0KPiBoYXZlIHRvIGRvIHNvbWUgb2YgaXQg dW5kZXIgdGhlIGludGVyZmFjZSBkZWZpbml0aW9ucyBhbmQgc29tZSBvZiBpdA0KPiB1bmRlciB0 aGUgZGVmaW5pdGlvbiBvZiB0aGUgcm91dGluZyBwcm90b2NvbC4gIFdoaWNoIGlzIGxpZmUsIG5l dmVyDQo+IHdob2x5IGludGVyZmFjZS1jZW50cmljIGFuZCBuZXZlciB3aG9seSByb3V0aW5nIHBy b3RvY29sLWNlbnRyaWMhDQoNCkFyZSB5b3Ugc2F5aW5nIHRoZSBqb2Igd291bGQgYmUgZWFzaWVy IGlmIHRoZQ0KcGF0aCB3YXMgL2RldmljZS9pbnRlcmZhY2VzL2ludGVyZmFjZSBpbnN0ZWFkDQpv ZiBqdXN0IC9pbnRlcmZhY2VzL2ludGVyZmFjZT8gIEFyZSB5b3Ugc2F5aW5nDQp0aGF0IC9wcm90 b2NvbHMvcm91dGluZyBjb3VsZCBub3QgYWxzbyBiZSBkZWZpbmVkPw0KQ2xlYXJseSBlZGl0LWNv bmZpZyBhbmQgY29weS1jb25maWcgYWxsb3cgYm90aA0Kc3VidHJlZXMgdG8gYmUgYWNjZXNzZWQg aW4gdGhlIHNhbWUgb3BlcmF0aW9uLA0Kc28gSSBkb24ndCB1bmRlcnN0YW5kIHlvdXIgY29uY2Vy bi4NCg0KSSBoYXZlIGJlZW4gdHJ5aW5nIHRvIGdldCB0aGUgcm9vdCBub2RlIHRvIGJlIGJldHRl ciBkZWZpbmVkDQppbiB0aGUgcHJvdG9jb2xzIHRoYXQgdXNlIFlBTkcgKGkuZS4sIG5jeDpyb290 LCBZMzQtMDQpLg0KSU1PIHRoaXMgaXMgYSBiZXR0ZXIgYXBwcm9hY2ggdGhhbiBkZWZpbmluZyBh IFlBTkcgbW9kdWxlDQp3aXRoIGEgc3BlY2lhbCBjb250YWluZXIgdGhhdCBhbGwgb3RoZXIgbW9k dWxlcyBhcmUgZXhwZWN0ZWQNCnRvIGF1Z21lbnQuICBZQU5HIGlzIGRlc2lnbmVkIHN1Y2ggdGhh dCBlYWNoIHZlbmRvciBvciBTRE8NCmlzIG5vdCBkZXBlbmRlbnQgb24gb3RoZXIgdmVuZG9ycyBv ciBTRE9zIGluIG9yZGVyIHRvDQpkZWZpbmUgZGF0YSBub2Rlcy4NCg0KPHRwPg0KDQpBbmR5DQoN CkkgYW0gYWdyZWVpbmcgd2l0aCB5b3UgdGhhdCBhZGRpbmcgJ2RldmljZScgYnJpbmdzIG5vIHRl Y2huaWNhbCBiZW5lZml0LA0KcmF0aGVyIHRoYXQgdGhlIG1vdGl2YXRpb24gaXMgdGhlIG9wcG9z aXRlIG9mIHRlY2huaWNhbCAod2hpY2ggSQ0KcmVmZXJyZWQgdG8gYXMgcG9saXRpY2FsKS4gSSBh bSBhbHNvIGFncmVlaW5nIHdpdGggdGhlIGN1cnJlbnQgZGVjbGFyZWQNCmNvbnNlbnN1cyBvbiBZ MzQuDQoNCkFuZCB5ZXMsIFlBTkcgaXMgZ29pbmcgdG8gZ2l2ZSB1cyBhIGxhcmdlIG51bWJlciBv ZiBtb2R1bGVzLCBzb21lDQp0aWdodGx5IGNvdXBsZWQgKGF1Z21lbnRzKSBzb21lIGxvb3NlbHkg c28gKGhvdyBtYW55IGRvIHlvdSBuZWVkIHRvDQpjb25maWd1cmUgT1NQRj8pIGFuZCB3b3JrIGlu IHRoaXMgYXJlYSB3aWxsIGJlIG9mIGJlbmVmaXQgbm93IGFuZA0KcHJvYmFibHkgZXNzZW50aWFs IGluIGEgZmV3IHllYXJzIHRpbWUuICBUaGF0IHNhaWQsIEkgYW0gdW5zdXJlIHdoYXQNCnN1Y2gg d29yayB3b3VsZCBiZSBsaWtlOyBJIGFtIGxvb2tpbmcgKGluIGRlc3BhaXIpIGF0IDUwIHJvdXRp bmcgYXJlYQ0KWUFORyBtb2RlbHMgYW5kIHdvbmRlcmluZyBob3cgYSB1c2VyIHdpbGwgZXZlciBn ZXQgYSBjb2hlcmVudCBwaWN0dXJlIG9mDQpob3cgdG8gZG8gd2hhdCB0aGV5IHdhbnQgdG8gZG8u DQoNCg0KDQpUaGUgIllBTkcgTGFuZCBHcmFiIiBnaXZlcyBhIGZhbHNlIHNlbnNlIG9mIHByb2dy ZXNzLg0KUmVhY2hpbmcgV0cgY29uc2Vuc3VzIG9uIGV2ZXJ5IHNpbmdsZSBsZWFmIGlzIGhhcmQg d29yay4NCg0KSSBkb24ndCB0aGluayBhIGNvbGxlY3Rpb24gb2YgMTAwcyBvZiBZQU5HIG1vZHVs ZXMgaXMgZXZlcg0KZ29pbmcgdG8gdG8gYmUgZWFzeSB0byB1bmRlcnN0YW5kLiAgT3BlcmF0b3Jz IHdpbGwgbm90IGV4YW1pbmUNCmEgTkVUQ09ORiA8aGVsbG8+IG1lc3NhZ2UsIGxvb2sgYXQgMTUw IG1vZHVsZSBVUklzLA0KYW5kIHNheSAiSSBrbm93IGV4YWN0bHkgd2hhdCB0aGlzIGRldmljZSBz dXBwb3J0cyIuDQpJIGd1ZXNzIGl0IGlzIHVwIHRvIGNsaWVudCB0b29scyB0byBkbyB0aGF0DQoN Ckkgd3JvdGUgYSBkcmFmdCB0aGF0IGRlZmluZXMgWUFORyBQYWNrYWdlcywgd2hpY2ggY2FuIHBy b3ZpZGUNCmEgaGlnaGVyIGxldmVsIG9mIG9yZ2FuaXphdGlvbiBmb3IgWUFORyBtb2R1bGVzLg0K DQpodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJpZXJtYW4tbmV0bW9kLXlh bmctcGFja2FnZS8NCg0KWW91IGFuZCBJIGFyZSBhcHBhcmVudGx5IGluIHRoZSBtaW5vcml0eSwg c2luY2UgdGhlIG9mZmljaWFsIHN0YXR1cw0KaXMgdGhhdCB0aGVyZSBpcyBubyBwcm9ibGVtIHdp dGggdGhlIGN1cnJlbnQgYXBwcm9hY2gsIGFuZCBubyBuZWVkDQp0byBvcmdhbml6ZSBpbmRpdmlk dWFsIFlBTkcgbW9kdWxlcyBpbnRvIGFueSBsYXJnZXIgYWJzdHJhY3Rpb25zLg0KDQoNCg0KIFRv bSBQZXRjaA0KDQoNCg0KQW5keQ0KDQpBbmR5DQoNCj4gQW5keQ0KPg0KPiA+IFRoZSB3ZWxsLXNw ZWNpZmllZCBYUGF0aCBhbmQgWUFORyByb290ICgvKSBjYW4gYmUNCj4gPiBhY2Nlc3NlZCBieSBh bGwgcHJvdG9jb2wgb3BlcmF0aW9ucywgZXhhY3RseSB0aGUgc2FtZQ0KPiA+IGFzIGEgbm9kZSBj YWxsZWQgJ2RldmljZScuICBUaGUgYWN0dWFsIG5vZGUgbmFtZSB3aWxsDQo+ID4gZGVwZW5kIG9u IHRoZSBSUEMgZnVuY3Rpb24gKGUuZy4gJ2RhdGEnIG9yICdjb25maWcnKS4NCj4gPg0KPiA+IFRo aXMgaXMgbW9yZSB0aGFuIHJlZHVuZGFudCBob3dldmVyLiAgSXQgaW50cm9kdWNlcyBhICJzdXBl ci1tb2R1bGUiDQo+ID4gaW50byBZQU5HIHRoYXQgZXZlcnkgb3RoZXIgbW9kdWxlIGlzIGV4cGVj dGVkIHRvIGF1Z21lbnQuDQo+ID4gWUFORyBpcyBpbnRlbmRlZCB0byBiZSBtb3JlIGxvb3NlbHkg Y291cGxlZCB0aGFuIHRoYXQuDQo+ID4gVGhpcyBpbnRyb2R1Y2VzIGFuIGV4dHJhIG5vZGUgYW5k IG5hbWVzcGFjZSBkZWNsYXJhdGlvbg0KPiA+IGluIGFsbCBwcm90b2NvbCBtZXNzYWdlcywgaW5j cmVhc2luZyBtZXNzYWdlIHNpemVzLg0KPiA+DQo+ID4gSXQgYWxzbyBhc3N1bWVzIGFsbCBleGlz dGluZyBZQU5HIG1vZGVscyB3aWxsIGdldCByZXdyaXR0ZW4gdG8NCj4gPiBhY2NvdW50IGZvciAi L2RldmljZSIgaW4gYWxsIHBhdGggYW5kIFhQYXRoIGV4cHJlc3Npb25zLg0KPiA+IFRoaXMgaXMg aGlnaGx5IGRpc3J1cHRpdmUgdG8gZXhpc3RpbmcgZGVwbG95bWVudHMuDQo+ID4gQWxzbywgbXVs dGlwbGUgZGF0YSBtb2RlbHMgdG8gZWRpdCB0aGUgc2FtZSB0aGluZyBjYXVzZXMgbG90cw0KPiA+ IG9mIGV4dHJhIGNvbXBsZXhpdHkgaW4gdGhlIHNlcnZlciAoc3VwcG9ydGluZyBib3RoIG9sZA0K PiA+IGxvY2F0aW9uIGFuZCBuZXcgbG9jYXRpb24pLg0KPiA+DQo+ID4gSU1PIGEgcmVzb3VyY2Ug ZGlyZWN0b3J5IGFwcHJvYWNoIGlzIG11Y2ggbW9yZSByZWFsaXN0aWMuDQo+ID4gVGhlIC9kZXZp Y2UgdHJlZSBjYW4gY29udGFpbiBhbGwgdGhlIG9yZ2FuaXplZCBOUCBjb250YWluZXJzLg0KPiA+ IEluc3RlYWQgb2YgYWxsIHRoZSBhY3R1YWwgZGF0YSBub2RlcywgdGhpcyB0cmVlIGp1c3QgaGFz IHBvaW50ZXJzDQo+ID4gdG8gdGhlIHJlYWwgbG9jYXRpb24gb2YgdGhlIHJlc291cmNlLiAobGlr ZSAzMDEgTW92ZWQgUGVybWFuZW50bHkpDQo+ID4NCj4gPiA+IEFjZWUNCj4gPiA+DQo+ID4gQW5k eQ0KDQoNCioqIFNvbHV0aW9uIFkzNC0wMg0KDQogIEtlZXAgJ2FueXhtbCcuICBJbnRyb2R1Y2Ug J2FueWRhdGEnIGFzIGFib3ZlIGJ1dCB3aXRob3V0IHRoZQ0KICAnZm9ybWF0JyBzdWJzdGF0ZW1l bnQuDQoNCiAgJ2FueXhtbCcgd291bGQgc3RpbGwgYmUgdXNlZCB0byByZXByZXNlbnQgdW5yZXN0 cmljdGVkIFhNTCwgYXMgaXMNCiAgZG9uZSBpbiBORVRDT05GLg0KDQogICdhbnlkYXRhJyB3b3Vs ZCBiZSBhbiB1bmtub3duIGNodW5rIG9mIGRhdGEgdGhhdCBjYW4gYmUgbW9kZWxsZWQNCiAgd2l0 aCBZQU5HLiAgQ2FuIGJlIGVuY29kZWQgYXMgeG1sIG9yIGpzb24uDQoNCiAgRm9yIGV4YW1wbGU6 DQoNCiAgICAjK0JFR0lOX0VYQU1QTEUNCiAgICBhbnlkYXRhIGRhdGE7DQogICAgIytFTkRfRVhB TVBMRQ0KDQoqKiBTb2x1dGlvbiBZMzQtMDUNCg0KICAgU2FtZSBhcyBZMzQtMDIgcGx1cyB0d28g Z3VpZGVsaW5lcyBhZG9wdGVkIGZyb20gWTM0LTA0Og0KDQogICAtIEtlZXAgJ2FueXhtbCcgdW5j aGFuZ2VkIGFzIGl0IGlzIGRlZmluZWQgaW4gWUFORyAxLjAuIFRoaXMNCiAgICAgZW5zdXJlcyBi YWNrd2FyZCBjb21wYXRpYmlsaXR5Lg0KICAgLSBJbnRyb2R1Y2UgYSBuZXcgJ2FueWRhdGEnIHN0 YXRlbWVudCB0aGF0IHJlcHJlc2VudHMgYW4gdW5rbm93bg0KICAgICBjaHVuayBvZiBkYXRhIHRo YXQgY2FuIGJlIG1vZGVsZWQgd2l0aCBZQU5HDQogICAtIERvY3VtZW50IHRoYXQgaW1wbGVtZW50 YXRpb25zIE1BWSBoYXZlIHJlc3RyaWN0aW9ucyBmb3IgYW55eG1sIGFuZA0KICAgICB0aGF0IGFu eXhtbCBpcyBub3QgbmVjZXNzYXJpbHkgaW50ZXJvcGVyYWJsZTsgZGF0YSBtb2RlbCB3cml0ZXJz DQogICAgIHNob3VsZCB1c2UgYW55ZGF0YSB3aGVuZXZlciBwb3NzaWJsZS4NCiAgIC0gVGhlIGd1 aWRlbGluZXMgZG9jdW1lbnQgc2hvdWxkIHNheSB0aGF0IFlBTkcgRG9jdG9ycyB3aWxsIHJldmll dw0KICAgICBlYWNoIHVzZSBvZiBhbnl4bWwgaW4gSUVURiBtb2R1bGVzIHdoZW4gWUFORyAxLjEg aXMgYWRvcHRlZCB0bw0KICAgICBhdm9pZCBpdHMgdXNlIHdoZW5ldmVyIHBvc3NpYmxlLg0KDQoN Cj4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K bmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQoNCg== --_000_B638E6EC24C3481981074C97EF366833ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KQXMgc29tZW9uZSBzaGFyaW5nIHJl c3BvbnNpYmlsaXRpZXMgZm9yIGd1aWRpbmcgYSBudW1iZXIgb2YgZGV2ZWxvcG1lbnQgdGVhbXMg Ym90aCBkZWZpbmluZyBuZXcgbW9kZWxzIGFuZCBpbXBsZW1lbnRpbmcgdG8gc29tZSBhbHJlYWR5 IGRlZmluZWQgbW9kZWxzIGluIHRoaXMgYXJlYSwgSSBjYW4gb25seSBhZ3JlZSB3aXRoIHRoaXMg YWRkaXRpb24gdG8gd2hhdCBJIHNhaWQgZWFybGllci4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkNoZWVycyw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkVpbmFyPGJyIGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIEF1 ZyAxMCwgMjAxNSwgYXQgOTo0NiBBTSwgSm9uYXRoYW4gSGFuc2ZvcmQgJmx0OzxhIGhyZWY9Im1h aWx0bzpqb25hdGhhbkBoYW5zZm9yZHMubmV0IiBjbGFzcz0iIj5qb25hdGhhbkBoYW5zZm9yZHMu bmV0PC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5l d2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiAnSGVsdmV0 aWNhIE5ldWUnLEhlbHZldGljYSxBcmlhbCxzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHg7IiBj bGFzcz0iIj4NCiZuYnNwO0FuZCBpdCBpcyBub3QganVzdCBlbmQgdXNlcnMgd2hvIG5lZWQgaGVs cCB0byBiZXR0ZXIgdW5kZXJzdGFuZCBZQU5HIG1vZGVscyBhbmQgaG93IHRvIHVzZSB0aGVtLiBG b3IgdGhvc2Ugc3RpbGwgb24gdGhlIGVkZ2UsIGxvb2tpbmcgdG8gZmluYWxseSB0YWtlIHRoZSBw bHVuZ2UgYW5kIHVzZSBORVRDT05GL1lBTkcgdG8gY29uZmlndXJlIHRoZWlyIGRldmljZXMsIGhl bHAgaXMgYWxzbyByZXF1aXJlZCB0byBkZXRlcm1pbmUgaG93IGJlc3QgdG8NCiBzdHJ1Y3R1cmUg dGhlaXIgWUFORyBtb2RlbHMsIG1ha2UgdXNlIG9mIHRoZSBleGlzdGluZyBvbmVzLCBldGMuIEZv ciB0aG9zZSB3aG8gaGF2ZSAmcXVvdDtncm93biB1cCZxdW90OyB3aXRoIHRoZSBkZXZlbG9wbWVu dHMgaW4gTkVUQ09ORiBhbmQgWUFORywgbXVjaCBvZiB0aGlzIGlzIHByb2JhYmx5IHNlY29uZCBu YXR1cmUuIEJ1dCBjb21pbmcgdG8gaXQgY29sZCAoaW4gdGhlIHNlbnNlIG9mIGNvbXBpbGluZy93 cml0aW5nIGEgZmlyc3Qgc2V0IG9mIFlBTkcgbW9kZWxzDQogZm9yIGEgZGV2aWNlOyBJJ3ZlIGJl ZW4gZm9sbG93aW5nIHRoZSBuZXRjb25mL25ldG1vZCBXR3MgZm9yIDMmIzQzOyB5ZWFycyksIGl0 IHN0aWxsIGZlZWxzIHZlcnkgbXVjaCBsaWtlIGEgZGFyayBhcnQhIEl0IGlzIG5vdCBqdXN0IHRo ZSBpbmRpdmlkdWFsIG1vZHVsZXMsIGl0IGlzIGhvdyB0byBwdXQgdGhlbSB0b2dldGhlciB0byBi ZXN0IG1hbmFnZSBhIGRldmljZSAobGV0IGFsb25lIGEgc3lzdGVtKS4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkpvbmF0aGFuPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLTxiciBjbGFzcz0iIj4NCjxk aXYgc3R5bGU9IndpZHRoOjEwMCU7YmFja2dyb3VuZDpyZ2IoMjI4LDIyOCwyMjgpOyIgY2xhc3M9 IiI+DQo8ZGl2IHN0eWxlPSJmb250LXdlaWdodDpib2xkOyIgY2xhc3M9IiI+RnJvbTo8L2Rpdj4N CiZxdW90O0VpbmFyIE5pbHNlbi1OeWdhYXJkIChlaW5hcm5uKSZxdW90OyAmbHQ7PGEgaHJlZj0i bWFpbHRvOmVpbmFybm5AY2lzY28uY29tIiBjbGFzcz0iIj5laW5hcm5uQGNpc2NvLmNvbTwvYT4m Z3Q7PC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJmb250LXdlaWdodDpib2xkOyIg Y2xhc3M9IiI+VG86PC9kaXY+DQomcXVvdDtBbmR5IEJpZXJtYW4mcXVvdDsgJmx0OzxhIGhyZWY9 Im1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20iIGNsYXNzPSIiPmFuZHlAeXVtYXdvcmtzLmNvbTwv YT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZDsiIGNsYXNz PSIiPkNjOjwvZGl2Pg0KJnF1b3Q7TkVUTU9EIFdvcmtpbmcgR3JvdXAmcXVvdDsgJmx0OzxhIGhy ZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciIGNsYXNzPSIiPm5ldG1vZEBpZXRmLm9yZzwvYT4m Z3Q7PGJyIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZDsiIGNsYXNzPSIi PlNlbnQ6PC9kaXY+DQpTYXQsIDggQXVnIDIwMTUgMTE6MTA6MTUgJiM0MzswMDAwPGJyIGNsYXNz PSIiPg0KPGRpdiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZDsiIGNsYXNzPSIiPlN1YmplY3Q6PC9k aXY+DQpSZTogW25ldG1vZF0gWTM0IC0gcm9vdCBub2RlPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KQW5keSwNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkkgYWdyZWUgdGhhdCB0aGVyZSBpcyBhIG5lZWQgZm9yIG9y Z2FuaXphdGlvbiBvZiBtb2RlbHMsIGJ1dCBJIGRvbuKAmXQgaGF2ZSBhIGZpcm0gcG9zaXRpb24g b24mbmJzcDtkcmFmdC1vcGVuY29uZmlnLW5ldG1vZC1tb2RlbC1zdHJ1Y3R1cmUvZHJhZnQtcnRn eWFuZ2R0LXJ0Z3dnLWRldmljZS1tb2RlbCBvciZuYnNwO2RyYWZ0LWJpZXJtYW4tbmV0bW9kLXlh bmctcGFja2FnZS4gQnV0IHdlIGFic29sdXRlbHkgbmVlZCAqc29tZXRoaW5nKiB0bw0KIGhlbHAg ZW5kLXVzZXJzIG9mIHRoZSBtb2RlbHMgY29tcHJlaGVuZCB0aGUgb3ZlcmFsbCBzdHJ1Y3R1cmUg b2YgbW9kZWxzLCB0aGVpciByZWxhdGlvbnNoaXAgYW5kIGhvdyB0byB1c2UgdGhlbS48L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkNoZWVy cyw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPkVpbmFyPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+DQo8YmxvY2txdW90ZSBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gQXVnIDQsIDIwMTUs IGF0IDU6MTYgUE0sIEFuZHkgQmllcm1hbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFuZHlAeXVtYXdv cmtzLmNvbSIgY2xhc3M9IiI+YW5keUB5dW1hd29ya3MuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+ DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWls X2V4dHJhIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gVHVlLCBB dWcgNCwgMjAxNSBhdCAyOjM0IEFNLCB0LnBldGNoIDxzcGFuIGRpcj0ibHRyIiBjbGFzcz0iIj4N CiZsdDs8YSBocmVmPSJtYWlsdG86aWV0ZmNAYnRjb25uZWN0LmNvbSIgY2xhc3M9IiI+aWV0ZmNA YnRjb25uZWN0LmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YmxvY2tx dW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXIt bGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4OyI+DQotLS0tLSBPcmlnaW5hbCBN ZXNzYWdlIC0tLS0tPGJyIGNsYXNzPSIiPg0KRnJvbTogJnF1b3Q7QW5keSBCaWVybWFuJnF1b3Q7 ICZsdDs8YSBocmVmPSJtYWlsdG86YW5keUB5dW1hd29ya3MuY29tIiBjbGFzcz0iIj5hbmR5QHl1 bWF3b3Jrcy5jb208L2E+Jmd0OzxiciBjbGFzcz0iIj4NClRvOiAmcXVvdDt0LnBldGNoJnF1b3Q7 ICZsdDs8YSBocmVmPSJtYWlsdG86aWV0ZmNAYnRjb25uZWN0LmNvbSIgY2xhc3M9IiI+aWV0ZmNA YnRjb25uZWN0LmNvbTwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KU2VudDogTW9uZGF5LCBBdWd1c3Qg MDMsIDIwMTUgNToxNyBQTTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZndDsgLS0tLS0g T3JpZ2luYWwgTWVzc2FnZSAtLS0tLTxiciBjbGFzcz0iIj4NCiZndDsgRnJvbTogJnF1b3Q7QW5k eSBCaWVybWFuJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YW5keUB5dW1hd29ya3MuY29tIiBj bGFzcz0iIj5hbmR5QHl1bWF3b3Jrc2NvbTwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyBUbzog JnF1b3Q7dC5wZXRjaCZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGZjQGJ0Y29ubmVjdC5j b20iIGNsYXNzPSIiPmlldGZjQGJ0Y29ubmVjdC5jb208L2E+Jmd0OzxiciBjbGFzcz0iIj4NCiZn dDsgU2VudDogTW9uZGF5LCBBdWd1c3QgMDMsIDIwMTUgNDoxMCBQTTxiciBjbGFzcz0iIj4NCiZn dDs8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLTxi ciBjbGFzcz0iIj4NCiZndDsgJmd0OyBGcm9tOiAmcXVvdDtBbmR5IEJpZXJtYW4mcXVvdDsgPGEg aHJlZj0ibWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbSIgY2xhc3M9IiI+YW5keUB5dW1hd29ya3Mu Y29tPC9hPjxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyBTZW50OiBTYXR1cmRheSwgQXVndXN0IDAx LCAyMDE1IDc6MDUgUE08YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgT24gU2F0LCBBdWcgMSwgMjAx NSBhdCA5OjUxIEFNLCBBY2VlIExpbmRlbSAoYWNlZSkgJmx0OzxhIGhyZWY9Im1haWx0bzphY2Vl QGNpc2NvLmNvbSIgY2xhc3M9IiI+YWNlZUBjaXNjby5jb208L2E+Jmd0OzxiciBjbGFzcz0iIj4N CiZndDsgJmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyBPbiA4LzEvMTUsIDI6NTEgQU0s Jm5ic3A7IDxhIGhyZWY9Im1haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHku ZGUiIGNsYXNzPSIiPg0Kai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPC9hPiZn dDsgd3JvdGU6PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsmZ3Q7IFNlY3Rpb24gMS4xIGluPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmZ3Q7PGJyIGNsYXNz PSIiPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1vcGVuY29u ZmlnLW5ldG1vZC1tb2RlbC1zdHJ1Y3R1cmUtMDAudHh0IiBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL2lkL2RyYWZ0LW9wZW5jb25maWctbmV0bW9kLW1vZGVsLXN0cnVjdHVyZS0wMC50 eHQ8L2E+PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmZ3Q7IGxpc3RzIHRoZSBnb2FscyBvZiBhIGdl bmVyaWMgbW9kZWwgc3RydWN0dXJlIHRoYXQgd2lsbCBhY2NvbW1vZGF0ZTxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7IG1vc3Q8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDsgbW9kZXJuIG5ldHdvcmsg ZGV2aWNlcy4gSSBndWVzcyB5b3UgZG9u4oCZdCBhZ3JlZSB0aGF0IHRoZXNlIGFyZTxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7IGRlc2lyYWJsZT88YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDs8YnIgY2xh c3M9IiI+DQomZ3Q7ICZndDsgVGhlIG9ubHkgb2JqZWN0aW9uIEkgaGF2ZSB0byB0aGlzIGRyYWZ0 IGlzIHRoZSBpbnNlcnRpb24gb2YgYTxiciBjbGFzcz0iIj4NCnRvcC1sZXZlbDxiciBjbGFzcz0i Ij4NCiZndDsgJmd0OyByb290PGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7IGNhbGxlZCAmcXVvdDtk ZXZpY2UmcXVvdDsuJm5ic3A7IChNaWdodCBhcyB3ZWxsIGJlIGNhbGxlZCAmcXVvdDtzZWxmJnF1 b3Q7KS48YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgVGhlcmUgYXJlIG5vIHNpYmxpbmcgbm9kZXMg cGxhbm5lZCBvciBpbnRlbmRlZCBmb3I8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgdGhpcyBub2Rl LCBzbyBpdCBzZXJ2ZXMgYXMgYW4gZXh0cmEgZG9jdW1lbnQgcm9vdC48YnIgY2xhc3M9IiI+DQom Z3Q7ICZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgJmx0O3RwJmd0OzxiciBjbGFzcz0iIj4N CiZndDsgJmd0OyBPbmUgYXNwZWN0IG9mIFlBTkcgSSBoYXZlIG5ldmVyIGdyYXNwZWQgaXMgd2hh dCBhIHJvb3QgbWVhbnMsIGlmPGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7IGFueXRoaW5nLjxiciBj bGFzcz0iIj4NCiZndDsgJmd0OzxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyBJIHVuZGVyc3RhbmQg dGhhdCBpdCBpcyBuZWVkZWQgZm9yIE5FVENPTkYgKGZpbHRlcnMpIGFuZCBmb3IgWUFORzxiciBj bGFzcz0iIj4NCiZndDsgJmd0OyAoYXVnbWVudHMsIGNvbnN0cmFpbnRzKSBhbmQgc28gbXVzdCBi ZSBzb21ld2hlcmUgYW5kIG11c3QgYmU8YnIgY2xhc3M9IiI+DQomZ3Q7IHJlbGF0aXZlbHk8YnIg Y2xhc3M9IiI+DQomZ3Q7ICZndDsgc3RhYmxlLCBidXQgaGFzIGl0IGFueSBvdGhlciBzaWduaWZp Y2FuY2UgaW4gdGhlIGRhdGEgbW9kZWw/PGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7PGJyIGNsYXNz PSIiPg0KJmd0OyAmZ3Q7IEFzIHlvdSBtYXkgcmVjYWxsLCBJIHdhcyBpbnZvbHZlZCB3aXRoIFNN SSBmaXJzdCwgd2hlcmUgdGhlIHJvb3QgaXM8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgc29tZXdo ZXJlIHVwIGluIHRoZSBza3kgYW5kIGxpZmUgb25seSBiZWNvbWVzIGludGVyZXN0aW5nIHNvbWUg c2l4PGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7IGxldmVscyBkb3duIHRoZSBoaWVyYXJjaHkgYW5k IHRoYXQgbWF5IGNvbG91ciBteSB0aGlua2luZy48YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDs8YnIg Y2xhc3M9IiI+DQomZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyBZQU5HIGRvZXMgYSBwb29yIGpvYiBv ZiBkZWZpbmluZyB0aGUgcm9vdCBmb3IgWUFORyBkYXRhIG5vZGVzLjxiciBjbGFzcz0iIj4NCiZn dDsgSXQgaXMgc29tZXRpbWVzIGNhbGxlZCBhIGRhdGFzdG9yZSAoaW4gdGhlIGFic3RyYWN0KS48 YnIgY2xhc3M9IiI+DQomZ3Q7IFRlY2huaWNhbGx5LCBZQU5HIGJvcnJvd3MgdGhlIGRlZmluaXRp b24gZnJvbSBYUGF0aC48YnIgY2xhc3M9IiI+DQomZ3Q7IFlBTkcganVzdCBkZWZpbmVzIHRvcC1s ZXZlbCBkYXRhIG5vZGVzIGFuZCB0aGUgcGFyZW50IG9mPGJyIGNsYXNzPSIiPg0KJmd0OyB0aGVz ZSBub2RlcyBpcyB0aGUgZG9jdW1lbnQgcm9vdDxiciBjbGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9 IiI+DQomZ3Q7IFRoZXJlIGlzIG5vIHByb3RvY29sIG9yIGVuY29kaW5nIG5ldXRyYWwgZGVmaW5p dGlvbiw8YnIgY2xhc3M9IiI+DQomZ3Q7IG9ubHkgYW4gWE1MLXNwZWNpZmljIGRlZmluaXRpb24u PGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4NCiZndDsgJmx0O3RwJmd0OzxiciBjbGFz cz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7IFRoYW5rcyBmb3IgdGhhdC48YnIgY2xhc3M9 IiI+DQomZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyBJdCBzZWVtcyB0byBtZSB0aGF0IG11Y2ggb2Yg dGhlIGV4dGVuc2l2ZSBkaXNjdXNzaW9uIG9uIFkzNCAoYWxsIG9mPGJyIGNsYXNzPSIiPg0KJmd0 OyB3aGljaCBJIGhhdmUgcmVhZCkgaXMgYXMgbXVjaCBwb2xpdGljYWwgYXMgdGVjaG5pY2FsLCB0 aGF0IGlzIFNNSSBpczxiciBjbGFzcz0iIj4NCiZndDsgaGllcmFyY2hpY2FsLCB0b3AgZG93biwg cGVyaGFwcyBiZWZpdHRpbmcgaXRzIG9yaWdpbnMgaW4gSVNPLCB3aGVyZWFzPGJyIGNsYXNzPSIi Pg0KJmd0OyBZQU5HIGlzIGJvdHRvbSB1cC4gSUVURi1saWtlLiZuYnNwOyBZQU5HIGNvdWxkIGhh dmUgaGFkIGEgc2luZ2xlIHRyZWUsIGJ1dDxiciBjbGFzcz0iIj4NCiZndDsgZG9lc24ndC4mbmJz cDsgU28gd2hlbiBJIHJlYWQ8YnIgY2xhc3M9IiI+DQomZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyA8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1vcGVuY29uZmlnLW5ldG1vZC1t b2RlbC1zdHJ1Y3R1cmUtMDAudHh0IiBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL2lk L2RyYWZ0LW9wZW5jb25maWctbmV0bW9kLW1vZGVsLXN0cnVjdHVyZS0wMC50eHQ8L2E+PGJyIGNs YXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4NCiZndDsgSSBzZWUgYSBwbGVhIGZvciBhIG1vcmUg aGllcmFyY2hpY2FsIG9yZ2FuaXNhdGlvbiwgYW5kIHdoZW4gSSByZWFkPGJyIGNsYXNzPSIiPg0K Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsgZHJhZnQtYmpvcmtsdW5kLW5ldG1vZC1vcGVuY29uZmln LXJlcGx5LTAwPGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4NCiZndDsgSSBzZWUgYSBy ZXNwb25zZSB0aGF0IHNheXMgd2UgYXJlIG5vdCBsaWtlIHRoYXQuPGJyIGNsYXNzPSIiPg0KJmd0 OzxiciBjbGFzcz0iIj4NCiZndDsgSWYgc28sIEkgZG91YnQgdGhhdCB0aGVyZSBldmVyIHdpbGwg YmUgYSB0ZWNobmljYWwgc29sdXRpb24uPGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4N CiZndDsgQW5kIEkgYW0gbWluZGZ1bCB0aGF0IHdoZW4gSSBjb25maWd1cmUgcm91dGluZyBpbiBh IChDaXNjbykgcm91dGVyLCBJPGJyIGNsYXNzPSIiPg0KJmd0OyBoYXZlIHRvIGRvIHNvbWUgb2Yg aXQgdW5kZXIgdGhlIGludGVyZmFjZSBkZWZpbml0aW9ucyBhbmQgc29tZSBvZiBpdDxiciBjbGFz cz0iIj4NCiZndDsgdW5kZXIgdGhlIGRlZmluaXRpb24gb2YgdGhlIHJvdXRpbmcgcHJvdG9jb2wu Jm5ic3A7IFdoaWNoIGlzIGxpZmUsIG5ldmVyPGJyIGNsYXNzPSIiPg0KJmd0OyB3aG9seSBpbnRl cmZhY2UtY2VudHJpYyBhbmQgbmV2ZXIgd2hvbHkgcm91dGluZyBwcm90b2NvbC1jZW50cmljITxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkFyZSB5b3Ugc2F5aW5nIHRoZSBqb2Igd291bGQg YmUgZWFzaWVyIGlmIHRoZTxiciBjbGFzcz0iIj4NCnBhdGggd2FzIC9kZXZpY2UvaW50ZXJmYWNl cy9pbnRlcmZhY2UgaW5zdGVhZDxiciBjbGFzcz0iIj4NCm9mIGp1c3QgL2ludGVyZmFjZXMvaW50 ZXJmYWNlPyZuYnNwOyBBcmUgeW91IHNheWluZzxiciBjbGFzcz0iIj4NCnRoYXQgL3Byb3RvY29s cy9yb3V0aW5nIGNvdWxkIG5vdCBhbHNvIGJlIGRlZmluZWQ/PGJyIGNsYXNzPSIiPg0KQ2xlYXJs eSBlZGl0LWNvbmZpZyBhbmQgY29weS1jb25maWcgYWxsb3cgYm90aDxiciBjbGFzcz0iIj4NCnN1 YnRyZWVzIHRvIGJlIGFjY2Vzc2VkIGluIHRoZSBzYW1lIG9wZXJhdGlvbiw8YnIgY2xhc3M9IiI+ DQpzbyBJIGRvbid0IHVuZGVyc3RhbmQgeW91ciBjb25jZXJuLjxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCkkgaGF2ZSBiZWVuIHRyeWluZyB0byBnZXQgdGhlIHJvb3Qgbm9kZSB0byBiZSBi ZXR0ZXIgZGVmaW5lZDxiciBjbGFzcz0iIj4NCmluIHRoZSBwcm90b2NvbHMgdGhhdCB1c2UgWUFO RyAoaS5lLiwgbmN4OnJvb3QsIFkzNC0wNCkuPGJyIGNsYXNzPSIiPg0KSU1PIHRoaXMgaXMgYSBi ZXR0ZXIgYXBwcm9hY2ggdGhhbiBkZWZpbmluZyBhIFlBTkcgbW9kdWxlPGJyIGNsYXNzPSIiPg0K d2l0aCBhIHNwZWNpYWwgY29udGFpbmVyIHRoYXQgYWxsIG90aGVyIG1vZHVsZXMgYXJlIGV4cGVj dGVkPGJyIGNsYXNzPSIiPg0KdG8gYXVnbWVudC4mbmJzcDsgWUFORyBpcyBkZXNpZ25lZCBzdWNo IHRoYXQgZWFjaCB2ZW5kb3Igb3IgU0RPPGJyIGNsYXNzPSIiPg0KaXMgbm90IGRlcGVuZGVudCBv biBvdGhlciB2ZW5kb3JzIG9yIFNET3MgaW4gb3JkZXIgdG88YnIgY2xhc3M9IiI+DQpkZWZpbmUg ZGF0YSBub2Rlcy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombHQ7dHAmZ3Q7PGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQW5keTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CkkgYW0gYWdyZWVpbmcgd2l0aCB5b3UgdGhhdCBhZGRpbmcgJ2RldmljZScgYnJpbmdzIG5vIHRl Y2huaWNhbCBiZW5lZml0LDxiciBjbGFzcz0iIj4NCnJhdGhlciB0aGF0IHRoZSBtb3RpdmF0aW9u IGlzIHRoZSBvcHBvc2l0ZSBvZiB0ZWNobmljYWwgKHdoaWNoIEk8YnIgY2xhc3M9IiI+DQpyZWZl cnJlZCB0byBhcyBwb2xpdGljYWwpLiBJIGFtIGFsc28gYWdyZWVpbmcgd2l0aCB0aGUgY3VycmVu dCBkZWNsYXJlZDxiciBjbGFzcz0iIj4NCmNvbnNlbnN1cyBvbiBZMzQuPGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KQW5kIHllcywgWUFORyBpcyBnb2luZyB0byBnaXZlIHVzIGEgbGFyZ2Ug bnVtYmVyIG9mIG1vZHVsZXMsIHNvbWU8YnIgY2xhc3M9IiI+DQp0aWdodGx5IGNvdXBsZWQgKGF1 Z21lbnRzKSBzb21lIGxvb3NlbHkgc28gKGhvdyBtYW55IGRvIHlvdSBuZWVkIHRvPGJyIGNsYXNz PSIiPg0KY29uZmlndXJlIE9TUEY/KSBhbmQgd29yayBpbiB0aGlzIGFyZWEgd2lsbCBiZSBvZiBi ZW5lZml0IG5vdyBhbmQ8YnIgY2xhc3M9IiI+DQpwcm9iYWJseSBlc3NlbnRpYWwgaW4gYSBmZXcg eWVhcnMgdGltZS4mbmJzcDsgVGhhdCBzYWlkLCBJIGFtIHVuc3VyZSB3aGF0PGJyIGNsYXNzPSIi Pg0Kc3VjaCB3b3JrIHdvdWxkIGJlIGxpa2U7IEkgYW0gbG9va2luZyAoaW4gZGVzcGFpcikgYXQg NTAgcm91dGluZyBhcmVhPGJyIGNsYXNzPSIiPg0KWUFORyBtb2RlbHMgYW5kIHdvbmRlcmluZyBo b3cgYSB1c2VyIHdpbGwgZXZlciBnZXQgYSBjb2hlcmVudCBwaWN0dXJlIG9mPGJyIGNsYXNzPSIi Pg0KaG93IHRvIGRvIHdoYXQgdGhleSB3YW50IHRvIGRvLjxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGUg JnF1b3Q7WUFORyBMYW5kIEdyYWImcXVvdDsgZ2l2ZXMgYSBmYWxzZSBzZW5zZSBvZiBwcm9ncmVz cy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+UmVhY2hpbmcgV0cgY29uc2Vuc3VzIG9uIGV2ZXJ5IHNp bmdsZSBsZWFmIGlzIGhhcmQgd29yay48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkkgZG9uJ3QgdGhpbmsgYSBjb2xsZWN0aW9uIG9mIDEw MHMgb2YgWUFORyBtb2R1bGVzIGlzIGV2ZXI8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+Z29pbmcgdG8gdG8gYmUgZWFzeSB0byB1bmRlcnN0YW5kLiZuYnNwOyBPcGVyYXRvcnMg d2lsbCBub3QgZXhhbWluZTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5hIE5FVENPTkYgJmx0O2hlbGxv Jmd0OyBtZXNzYWdlLCBsb29rIGF0IDE1MCBtb2R1bGUgVVJJcyw8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+YW5kIHNheSAmcXVvdDtJIGtub3cgZXhhY3RseSB3aGF0IHRoaXMgZGV2aWNlIHN1cHBvcnRz JnF1b3Q7LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIGd1ZXNzIGl0IGlzIHVwIHRvIGNsaWVudCB0 b29scyB0byBkbyB0aGF0PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj5JIHdyb3RlIGEgZHJhZnQgdGhhdCBkZWZpbmVzIFlBTkcgUGFja2Fn ZXMsIHdoaWNoIGNhbiBwcm92aWRlPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPmEgaGlnaGVyIGxldmVs IG9mIG9yZ2FuaXphdGlvbiBmb3IgWUFORyBtb2R1bGVzLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0iaHR0cDovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1iaWVybWFuLW5ldG1vZC15YW5nLXBhY2thZ2UvIiBj bGFzcz0iIj5odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJpZXJtYW4tbmV0 bW9kLXlhbmctcGFja2FnZS88L2E+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5Zb3UgYW5kIEkgYXJlIGFwcGFy ZW50bHkgaW4gdGhlIG1pbm9yaXR5LCBzaW5jZSB0aGUgb2ZmaWNpYWwgc3RhdHVzPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPmlzIHRoYXQgdGhlcmUgaXMgbm8gcHJvYmxlbSB3aXRoIHRoZSBjdXJyZW50 IGFwcHJvYWNoLCBhbmQgbm8gbmVlZDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj50byBvcmdhbml6ZSBp bmRpdmlkdWFsIFlBTkcgbW9kdWxlcyBpbnRvIGFueSBsYXJnZXIgYWJzdHJhY3Rpb25zLjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7 Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleDsiPg0KJm5ic3A7VG9t IFBldGNoPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkFuZHk8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7 PC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAw IDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4OyI+DQpB bmR5PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJmd0OyBBbmR5PGJyIGNsYXNzPSIiPg0K Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyBUaGUgd2VsbC1zcGVjaWZpZWQgWFBhdGggYW5k IFlBTkcgcm9vdCAoLykgY2FuIGJlPGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7IGFjY2Vzc2VkIGJ5 IGFsbCBwcm90b2NvbCBvcGVyYXRpb25zLCBleGFjdGx5IHRoZSBzYW1lPGJyIGNsYXNzPSIiPg0K Jmd0OyAmZ3Q7IGFzIGEgbm9kZSBjYWxsZWQgJ2RldmljZScuJm5ic3A7IFRoZSBhY3R1YWwgbm9k ZSBuYW1lIHdpbGw8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgZGVwZW5kIG9uIHRoZSBSUEMgZnVu Y3Rpb24gKGUuZy4gJ2RhdGEnIG9yICdjb25maWcnKS48YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDs8 YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgVGhpcyBpcyBtb3JlIHRoYW4gcmVkdW5kYW50IGhvd2V2 ZXIuJm5ic3A7IEl0IGludHJvZHVjZXMgYSAmcXVvdDtzdXBlci1tb2R1bGUmcXVvdDs8YnIgY2xh c3M9IiI+DQomZ3Q7ICZndDsgaW50byBZQU5HIHRoYXQgZXZlcnkgb3RoZXIgbW9kdWxlIGlzIGV4 cGVjdGVkIHRvIGF1Z21lbnQuPGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7IFlBTkcgaXMgaW50ZW5k ZWQgdG8gYmUgbW9yZSBsb29zZWx5IGNvdXBsZWQgdGhhbiB0aGF0LjxiciBjbGFzcz0iIj4NCiZn dDsgJmd0OyBUaGlzIGludHJvZHVjZXMgYW4gZXh0cmEgbm9kZSBhbmQgbmFtZXNwYWNlIGRlY2xh cmF0aW9uPGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7IGluIGFsbCBwcm90b2NvbCBtZXNzYWdlcywg aW5jcmVhc2luZyBtZXNzYWdlIHNpemVzLjxiciBjbGFzcz0iIj4NCiZndDsgJmd0OzxiciBjbGFz cz0iIj4NCiZndDsgJmd0OyBJdCBhbHNvIGFzc3VtZXMgYWxsIGV4aXN0aW5nIFlBTkcgbW9kZWxz IHdpbGwgZ2V0IHJld3JpdHRlbiB0bzxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyBhY2NvdW50IGZv ciAmcXVvdDsvZGV2aWNlJnF1b3Q7IGluIGFsbCBwYXRoIGFuZCBYUGF0aCBleHByZXNzaW9ucy48 YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgVGhpcyBpcyBoaWdobHkgZGlzcnVwdGl2ZSB0byBleGlz dGluZyBkZXBsb3ltZW50cy48YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgQWxzbywgbXVsdGlwbGUg ZGF0YSBtb2RlbHMgdG8gZWRpdCB0aGUgc2FtZSB0aGluZyBjYXVzZXMgbG90czxiciBjbGFzcz0i Ij4NCiZndDsgJmd0OyBvZiBleHRyYSBjb21wbGV4aXR5IGluIHRoZSBzZXJ2ZXIgKHN1cHBvcnRp bmcgYm90aCBvbGQ8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgbG9jYXRpb24gYW5kIG5ldyBsb2Nh dGlvbikuPGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7IElN TyBhIHJlc291cmNlIGRpcmVjdG9yeSBhcHByb2FjaCBpcyBtdWNoIG1vcmUgcmVhbGlzdGljLjxi ciBjbGFzcz0iIj4NCiZndDsgJmd0OyBUaGUgL2RldmljZSB0cmVlIGNhbiBjb250YWluIGFsbCB0 aGUgb3JnYW5pemVkIE5QIGNvbnRhaW5lcnMuPGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7IEluc3Rl YWQgb2YgYWxsIHRoZSBhY3R1YWwgZGF0YSBub2RlcywgdGhpcyB0cmVlIGp1c3QgaGFzIHBvaW50 ZXJzPGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7IHRvIHRoZSByZWFsIGxvY2F0aW9uIG9mIHRoZSBy ZXNvdXJjZS4gKGxpa2UgMzAxIE1vdmVkIFBlcm1hbmVudGx5KTxiciBjbGFzcz0iIj4NCiZndDsg Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7IEFjZWU8YnIgY2xhc3M9IiI+DQomZ3Q7 ICZndDsgJmd0OzxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyBBbmR5PGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KKiogU29sdXRpb24gWTM0LTAyPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7IEtlZXAgJ2FueXhtbCcuJm5ic3A7IEludHJvZHVjZSAn YW55ZGF0YScgYXMgYWJvdmUgYnV0IHdpdGhvdXQgdGhlPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICdm b3JtYXQnIHN1YnN0YXRlbWVudC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsg J2FueXhtbCcgd291bGQgc3RpbGwgYmUgdXNlZCB0byByZXByZXNlbnQgdW5yZXN0cmljdGVkIFhN TCwgYXMgaXM8YnIgY2xhc3M9IiI+DQombmJzcDsgZG9uZSBpbiBORVRDT05GLjxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyAnYW55ZGF0YScgd291bGQgYmUgYW4gdW5rbm93biBj aHVuayBvZiBkYXRhIHRoYXQgY2FuIGJlIG1vZGVsbGVkPGJyIGNsYXNzPSIiPg0KJm5ic3A7IHdp dGggWUFORy4mbmJzcDsgQ2FuIGJlIGVuY29kZWQgYXMgeG1sIG9yIGpzb24uPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7IEZvciBleGFtcGxlOjxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgIyYjNDM7QkVHSU5fRVhBTVBMRTxiciBjbGFzcz0iIj4N CiZuYnNwOyAmbmJzcDsgYW55ZGF0YSBkYXRhOzxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsg IyYjNDM7RU5EX0VYQU1QTEU8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQoqKiBTb2x1dGlv biBZMzQtMDU8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7U2FtZSBh cyBZMzQtMDIgcGx1cyB0d28gZ3VpZGVsaW5lcyBhZG9wdGVkIGZyb20gWTM0LTA0OjxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDstIEtlZXAgJ2FueXhtbCcgdW5jaGFu Z2VkIGFzIGl0IGlzIGRlZmluZWQgaW4gWUFORyAxLjAuIFRoaXM8YnIgY2xhc3M9IiI+DQombmJz cDsgJm5ic3A7ICZuYnNwO2Vuc3VyZXMgYmFja3dhcmQgY29tcGF0aWJpbGl0eS48YnIgY2xhc3M9 IiI+DQombmJzcDsgJm5ic3A7LSBJbnRyb2R1Y2UgYSBuZXcgJ2FueWRhdGEnIHN0YXRlbWVudCB0 aGF0IHJlcHJlc2VudHMgYW4gdW5rbm93bjxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7Y2h1bmsgb2YgZGF0YSB0aGF0IGNhbiBiZSBtb2RlbGVkIHdpdGggWUFORzxiciBjbGFzcz0i Ij4NCiZuYnNwOyAmbmJzcDstIERvY3VtZW50IHRoYXQgaW1wbGVtZW50YXRpb25zIE1BWSBoYXZl IHJlc3RyaWN0aW9ucyBmb3IgYW55eG1sIGFuZDxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7dGhhdCBhbnl4bWwgaXMgbm90IG5lY2Vzc2FyaWx5IGludGVyb3BlcmFibGU7IGRhdGEg bW9kZWwgd3JpdGVyczxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7c2hvdWxkIHVz ZSBhbnlkYXRhIHdoZW5ldmVyIHBvc3NpYmxlLjxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDst IFRoZSBndWlkZWxpbmVzIGRvY3VtZW50IHNob3VsZCBzYXkgdGhhdCBZQU5HIERvY3RvcnMgd2ls bCByZXZpZXc8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwO2VhY2ggdXNlIG9mIGFu eXhtbCBpbiBJRVRGIG1vZHVsZXMgd2hlbiBZQU5HIDEuMSBpcyBhZG9wdGVkIHRvPGJyIGNsYXNz PSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDthdm9pZCBpdHMgdXNlIHdoZW5ldmVyIHBvc3NpYmxl LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZndDs8YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPC9kaXY+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxiciBjbGFzcz0iIj4NCm5ldG1vZCBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+ DQo8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIiBjbGFzcz0iIj5uZXRtb2RAaWV0Zi5v cmc8L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9uZXRtb2QiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbmV0bW9kPC9hPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B638E6EC24C3481981074C97EF366833ciscocom_-- From nobody Mon Aug 10 03:17:31 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4047B1B3419 for ; Mon, 10 Aug 2015 03:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LsUsSlZqiXBV for ; Mon, 10 Aug 2015 03:17:27 -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 E223F1B3416 for ; Mon, 10 Aug 2015 03:17:26 -0700 (PDT) Received: by lbbtg9 with SMTP id tg9so54458255lbb.1 for ; Mon, 10 Aug 2015 03:17:25 -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=Jm92YvV8I7AGFqtFT5EsTlvJAlPKutZkwgR9kLBE2Uw=; b=jYCrCo2Zv7e15UFIkia31wg3EPouZD22QaTrHA3wbrVI/EjPPGWk10jY/wVlkF8RcK nobvc3oDT2YmRzGep1h632fmJt1cZ8f3a09OjX3ECdTgNorUTkyZyjiRYQmp2hiQa7FQ lGULw8f8Z0WhSVlZBFE6BxVM83OrFUhPV03RrJPains75LfW/XhpG1by6nW+mnxoHBm8 2E4bi+dReXCDQMP3g/rta+41Fxocclrs6mSkF8p8AdexCBM+2GmB8h/kYgDJG3Ee8Wa6 QyR4AHdsbGqxlmaHRhLdAVJS1m9VIghc5oqAwHs78h3fXauUa7ho9xwKeA7O/wmslWBC IuJQ== X-Gm-Message-State: ALoCoQkKiMNSuu3YWYc/r1VIaIZTasmzPJEE/o8GbnxsBcg7LpL68sXOSUaxD7j1tKN4EaxoLyub MIME-Version: 1.0 X-Received: by 10.112.118.41 with SMTP id kj9mr19628271lbb.123.1439201845406; Mon, 10 Aug 2015 03:17:25 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Mon, 10 Aug 2015 03:17:25 -0700 (PDT) In-Reply-To: References: Date: Mon, 10 Aug 2015 03:17:25 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=047d7bfd0098c18a30051cf24ab5 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] extensions and conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 10:17:29 -0000 --047d7bfd0098c18a30051cf24ab5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I am strongly against changing the contract on extensions. They MAY be ignored by any YANG tool. Period. That means they are far from mandatory. They are little more than a keyword and a description clause. There are not even any rules or help determining which extensions can appear as children of other extensions. That indicates that they are not real statements and not really part of YANG at all. There are some uses of extensions that fit the modular design, but not many. The NACM extensions only affect NACM. They have no impact whatsoever on any YANG statement. Yet even these statements should be real YANG statements. There is really no need to force implementation of NACM in order to utilize the concept of 'default-deny-all'. But full implementation of NACM is required to use these extensions. Andy On Mon, Aug 10, 2015 at 1:14 AM, Ladislav Lhotka wrote: > Hi, > > recent discussions show that 6020(bis) text about extensions isn't > sufficiently clear about the scope and semantics of extensions. IMO this > needs to be fixed and so I propose to add the following item to YANG 1.1 > issue list. Comments and additional solutions are welcome. > > Lada > > ------------------------------------------------------------------------ > * NEW :Yxx: clarify conformance wrt extensions > > ** Description > > YANG extensions as defined in RFC 6020 have no limits on scope =E2=80= =93 > they can possibly modify YANG language, datastore semantics or even > the NETCONF protocol. However, from the text in RFC 6020 it is > unclear whether extensions appearing in YANG modules advertised by > a server are mandatory to implement: "If a YANG compiler does not > support a particular extension, which appears in a YANG module as > an unknown-statement (see Section 12), the entire unknown-statement > MAY be ignored by the compiler." > > ** Solution Yxx-01 > > Extensions appearing in the server's model are an integral part of > the server-client contract. That is, the server MUST implement > them, and the client SHOULD terminate the session if it doesn't > implement any of the extensions. > > ** Solution Yxx-02 > > Develop a mechanism for negotiating extensions. > > ** Solution Yxx-03 > > Make extensions optional. This means that extensions won't be > allowed to change YANG language, NETCONF protocol, and validity of > datastores and protocol messages. > ------------------------------------------------------------------------ > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --047d7bfd0098c18a30051cf24ab5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I am strongly against changing the = contract on extensions.
They MAY be ignored by any YANG tool. Per= iod.
That means they are far from mandatory.
They are l= ittle more than a keyword and a description clause.

There are not even any rules or help determining
which extensio= ns can appear as children of other
extensions.=C2=A0 That indicat= es that they are not
real statements and not really part of YANG = at all.

There are some uses of extensions that fit= the modular design,
but not many.=C2=A0 The NACM extensions only= affect NACM.
They have no impact whatsoever on any YANG statemen= t.
Yet even these statements should be real YANG statements.
There is really no need to force implementation of NACM
in = order to utilize the concept of 'default-deny-all'.
But f= ull implementation of NACM is required to use these
extensions.


Andy


On Mon, Aug 10, 2015 a= t 1:14 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
Hi,

recent discussions show that 6020(bis) text about extensions isn't
sufficiently clear about the scope and semantics of extensions. IMO this needs to be fixed and so I propose to add the following item to YANG 1.1 issue list. Comments and additional solutions are welcome.

Lada

------------------------------------------------------------------------ * NEW :Yxx: clarify conformance wrt extensions

** Description

=C2=A0 =C2=A0YANG extensions as defined in RFC 6020 have no limits on scope= =C2=A0=E2=80=93
=C2=A0 =C2=A0they can possibly modify YANG language, datastore semantics or= even
=C2=A0 =C2=A0the NETCONF protocol. However, from the text in RFC=C2=A06020 = it is
=C2=A0 =C2=A0unclear whether extensions appearing in YANG modules advertise= d by
=C2=A0 =C2=A0a server are mandatory to implement: "If a YANG compiler = does not
=C2=A0 =C2=A0support a particular extension, which appears in a YANG module= as
=C2=A0 =C2=A0an unknown-statement (see Section 12), the entire unknown-stat= ement
=C2=A0 =C2=A0MAY be ignored by the compiler."

** Solution Yxx-01

=C2=A0 =C2=A0Extensions appearing in the server's model are an integral= part of
=C2=A0 =C2=A0the server-client contract. That is, the server MUST implement=
=C2=A0 =C2=A0them, and the client SHOULD terminate the session if it doesn&= #39;t
=C2=A0 =C2=A0implement any of the extensions.

** Solution Yxx-02

=C2=A0 =C2=A0Develop a mechanism for negotiating extensions.

** Solution Yxx-03

=C2=A0 =C2=A0Make extensions optional. This means that extensions won't= be
=C2=A0 =C2=A0allowed to change YANG language, NETCONF protocol, and validit= y of
=C2=A0 =C2=A0datastores and protocol messages.
------------------------------------------------------------------------
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

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

--047d7bfd0098c18a30051cf24ab5-- From nobody Mon Aug 10 04:24:45 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 728141AC44D for ; Mon, 10 Aug 2015 04:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.661 X-Spam-Level: X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uxv20BuKTbZe for ; Mon, 10 Aug 2015 04:24:42 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC14F1AC43A for ; Mon, 10 Aug 2015 04:24:41 -0700 (PDT) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 3A4CB1818C2; Mon, 10 Aug 2015 13:24:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1439205880; bh=AcDvHu0tF3Za+ivKpWptJCllVNfxU/ZucfoXbWevHcg=; h=From:Date:To; b=rn4ouh4GCCz4NkicIedNBfXQC28/iRZrUGCmE5xgEX3wESjt/BTWH+XNqHfK8eR/N PI60Cw8XmJhVEW+o3HNZwSn99se48Jm2kqboxmE7YZpecZpNq0ROWa6LQ8UbBElshg 5A6uqMoaZ5RAul6Cyf1OFSLTcT2CLUw1oJYAFVJQ= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 10 Aug 2015 13:24:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <935AE06C-DF0E-4B79-BBB0-FBFC67297106@nic.cz> References: To: Andy Bierman X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] extensions and conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 11:24:44 -0000 > On 10 Aug 2015, at 12:17, Andy Bierman wrote: >=20 > Hi, >=20 > I am strongly against changing the contract on extensions. > They MAY be ignored by any YANG tool. Period. > That means they are far from mandatory. > They are little more than a keyword and a description clause. So do you prefer my proposed solution -02 or -03? >=20 > There are not even any rules or help determining > which extensions can appear as children of other > extensions. That indicates that they are not > real statements and not really part of YANG at all. >=20 > There are some uses of extensions that fit the modular design, > but not many. The NACM extensions only affect NACM. > They have no impact whatsoever on any YANG statement. > Yet even these statements should be real YANG statements. > There is really no need to force implementation of NACM > in order to utilize the concept of 'default-deny-all'. > But full implementation of NACM is required to use these > extensions. >=20 The descriptions of =E2=80=9Cdefault-deny-write=E2=80=9D and = =E2=80=9Cdefault-deny-all=E2=80=9D describe normative server behaviour. = It is not even clear from 6020 text whether server implementations can = ignore these extensions or not and still use the modules where the = extensions are present. Lada >=20 > Andy >=20 >=20 > On Mon, Aug 10, 2015 at 1:14 AM, Ladislav Lhotka = wrote: > Hi, >=20 > recent discussions show that 6020(bis) text about extensions isn't > sufficiently clear about the scope and semantics of extensions. IMO = this > needs to be fixed and so I propose to add the following item to YANG = 1.1 > issue list. Comments and additional solutions are welcome. >=20 > Lada >=20 > = ------------------------------------------------------------------------ > * NEW :Yxx: clarify conformance wrt extensions >=20 > ** Description >=20 > YANG extensions as defined in RFC 6020 have no limits on scope =E2=80= =93 > they can possibly modify YANG language, datastore semantics or even > the NETCONF protocol. However, from the text in RFC 6020 it is > unclear whether extensions appearing in YANG modules advertised by > a server are mandatory to implement: "If a YANG compiler does not > support a particular extension, which appears in a YANG module as > an unknown-statement (see Section 12), the entire unknown-statement > MAY be ignored by the compiler." >=20 > ** Solution Yxx-01 >=20 > Extensions appearing in the server's model are an integral part of > the server-client contract. That is, the server MUST implement > them, and the client SHOULD terminate the session if it doesn't > implement any of the extensions. >=20 > ** Solution Yxx-02 >=20 > Develop a mechanism for negotiating extensions. >=20 > ** Solution Yxx-03 >=20 > Make extensions optional. This means that extensions won't be > allowed to change YANG language, NETCONF protocol, and validity of > datastores and protocol messages. > = ------------------------------------------------------------------------ >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Aug 10 08:32:32 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B31A41B36F3 for ; Mon, 10 Aug 2015 08:32: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 1cnnDDsDFADE for ; Mon, 10 Aug 2015 08:32:28 -0700 (PDT) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7F7C1B36F2 for ; Mon, 10 Aug 2015 08:32:27 -0700 (PDT) Received: by lbbsx3 with SMTP id sx3so13591269lbb.0 for ; Mon, 10 Aug 2015 08:32: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=4EMdHuAV604NpDUfrPdNHfr3qNrqao55md4Q0DvFyP4=; b=YYVMzNLRC3q4E0LMtWA61FpD5Ut5nnW0AKAimQzeKDhJC9FaPeMGltxPV5/7Tub3Dk 3T4DaB4JBJHApr2UdNmsdgk8AtFv61mFb0AaM9Y5XEXLWSYitraFiC1MOiDcgy1VapoX qxTDe+1x3f//r4g0qmMt4/1nx0KStA6ug0Z5NDeryTwna+oyHO5erzY8BmW0SW05Mgsv 3G9KTQ/I+gOQjC6Xz+AD0Xp00Fb/ZrbashttzZteEDTlwPqqAZjEj3FhRh+g0H+w3lyE cYfUqijFdvuUTvBsLu2G0HFEjb7hluC82WMa1k2fWPImPwNlPXjRfc+wyiiuzLyEr4Ng +Xuw== X-Gm-Message-State: ALoCoQkMF+ntci4y5BtB0pgO2UfKYi2fCf1tCt0X9UpXUSGY9+4cZOhzKyOn5GZb1ZtSp0EY8F9f MIME-Version: 1.0 X-Received: by 10.152.88.106 with SMTP id bf10mr20473963lab.82.1439220746367; Mon, 10 Aug 2015 08:32:26 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Mon, 10 Aug 2015 08:32:26 -0700 (PDT) In-Reply-To: <935AE06C-DF0E-4B79-BBB0-FBFC67297106@nic.cz> References: <935AE06C-DF0E-4B79-BBB0-FBFC67297106@nic.cz> Date: Mon, 10 Aug 2015 08:32:26 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c2640e575667051cf6b1ef Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] extensions and conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 15:32:30 -0000 --001a11c2640e575667051cf6b1ef Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Aug 10, 2015 at 4:24 AM, Ladislav Lhotka wrote: > > > On 10 Aug 2015, at 12:17, Andy Bierman wrote: > > > > Hi, > > > > I am strongly against changing the contract on extensions. > > They MAY be ignored by any YANG tool. Period. > > That means they are far from mandatory. > > They are little more than a keyword and a description clause. > > So do you prefer my proposed solution -02 or -03? > ** Solution Yxx-03 Make extensions optional. This means that extensions won't be allowed to change YANG language, NETCONF protocol, and validity of datastores and protocol messages. This is how we use extensions to tag YANG data models to drive automation tools. Your entire problem statement assumes that the consumer of the extension is a protocol (client and/or server). IMO this is really bad design to use statements for standards that are by definition external to the YANG language, as if they were part of the YANG language. This is just a hack and it usually doesn't work well. For example, when I pointed out that an extension for "ephemeral" could not be modified with a refine-stmt, you just changed the subject and ignored that problem. Andy > > > > There are not even any rules or help determining > > which extensions can appear as children of other > > extensions. That indicates that they are not > > real statements and not really part of YANG at all. > > > > There are some uses of extensions that fit the modular design, > > but not many. The NACM extensions only affect NACM. > > They have no impact whatsoever on any YANG statement. > > Yet even these statements should be real YANG statements. > > There is really no need to force implementation of NACM > > in order to utilize the concept of 'default-deny-all'. > > But full implementation of NACM is required to use these > > extensions. > > > > The descriptions of =E2=80=9Cdefault-deny-write=E2=80=9D and =E2=80=9Cdef= ault-deny-all=E2=80=9D describe > normative server behaviour. It is not even clear from 6020 text whether > server implementations can ignore these extensions or not and still use t= he > modules where the extensions are present. > > Lada > > > > > Andy > > > > > > On Mon, Aug 10, 2015 at 1:14 AM, Ladislav Lhotka wrote: > > Hi, > > > > recent discussions show that 6020(bis) text about extensions isn't > > sufficiently clear about the scope and semantics of extensions. IMO thi= s > > needs to be fixed and so I propose to add the following item to YANG 1.= 1 > > issue list. Comments and additional solutions are welcome. > > > > Lada > > > > -----------------------------------------------------------------------= - > > * NEW :Yxx: clarify conformance wrt extensions > > > > ** Description > > > > YANG extensions as defined in RFC 6020 have no limits on scope =E2= =80=93 > > they can possibly modify YANG language, datastore semantics or even > > the NETCONF protocol. However, from the text in RFC 6020 it is > > unclear whether extensions appearing in YANG modules advertised by > > a server are mandatory to implement: "If a YANG compiler does not > > support a particular extension, which appears in a YANG module as > > an unknown-statement (see Section 12), the entire unknown-statement > > MAY be ignored by the compiler." > > > > ** Solution Yxx-01 > > > > Extensions appearing in the server's model are an integral part of > > the server-client contract. That is, the server MUST implement > > them, and the client SHOULD terminate the session if it doesn't > > implement any of the extensions. > > > > ** Solution Yxx-02 > > > > Develop a mechanism for negotiating extensions. > > > > ** Solution Yxx-03 > > > > Make extensions optional. This means that extensions won't be > > allowed to change YANG language, NETCONF protocol, and validity of > > datastores and protocol messages. > > -----------------------------------------------------------------------= - > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a11c2640e575667051cf6b1ef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Aug 10, 2015 at 4:24 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:

> On 10 Aug 2015, at 12:17, Andy Bierman <andy@yumaworks.com> wrote:
>
> Hi,
>
> I am strongly against changing the contract on extensions.
> They MAY be ignored by any YANG tool. Period.
> That means they are far from mandatory.
> They are little more than a keyword and a description clause.

So do you prefer my proposed solution -02 or -03?

=
** Solution Yxx-03

=C2=A0 =C2=A0Make = extensions optional. This means that extensions won't be
=C2=A0 =C2=A0allowed to change YANG language, NETCONF protocol, and va= lidity of
=C2=A0 =C2=A0datastores and protocol mess= ages.


This is how we use ext= ensions to tag YANG data models
to drive automation tools.
<= div>
Your entire problem statement assumes that the consumer<= /div>
of the extension is a protocol (client and/or server).
= IMO this is really bad design to use statements for standards
tha= t are by definition external to the YANG language, as if they
wer= e part of the YANG language.=C2=A0 This is just a hack and
it usu= ally doesn't work well.

For example, when I po= inted out that an extension for "ephemeral"
could not b= e modified with a refine-stmt, you just changed the
subject and i= gnored that problem.



=C2=A0Andy


>
> There are not even any rules or help determining
> which extensions can appear as children of other
> extensions.=C2=A0 That indicates that they are not
> real statements and not really part of YANG at all.
>
> There are some uses of extensions that fit the modular design,
> but not many.=C2=A0 The NACM extensions only affect NACM.
> They have no impact whatsoever on any YANG statement.
> Yet even these statements should be real YANG statements.
> There is really no need to force implementation of NACM
> in order to utilize the concept of 'default-deny-all'.
> But full implementation of NACM is required to use these
> extensions.
>

The descriptions of =E2=80=9Cdefault-deny-write=E2=80=9D and =E2=80=9Cdefau= lt-deny-all=E2=80=9D describe normative server behaviour. It is not even cl= ear from 6020 text whether server implementations can ignore these extensio= ns or not and still use the modules where the extensions are present.

Lada

>
> Andy
>
>
> On Mon, Aug 10, 2015 at 1:14 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> Hi,
>
> recent discussions show that 6020(bis) text about extensions isn't=
> sufficiently clear about the scope and semantics of extensions. IMO th= is
> needs to be fixed and so I propose to add the following item to YANG 1= .1
> issue list. Comments and additional solutions are welcome.
>
> Lada
>
> ----------------------------------------------------------------------= --
> * NEW :Yxx: clarify conformance wrt extensions
>
> ** Description
>
>=C2=A0 =C2=A0 YANG extensions as defined in RFC 6020 have no limits on = scope =E2=80=93
>=C2=A0 =C2=A0 they can possibly modify YANG language, datastore semanti= cs or even
>=C2=A0 =C2=A0 the NETCONF protocol. However, from the text in RFC 6020 = it is
>=C2=A0 =C2=A0 unclear whether extensions appearing in YANG modules adve= rtised by
>=C2=A0 =C2=A0 a server are mandatory to implement: "If a YANG comp= iler does not
>=C2=A0 =C2=A0 support a particular extension, which appears in a YANG m= odule as
>=C2=A0 =C2=A0 an unknown-statement (see Section 12), the entire unknown= -statement
>=C2=A0 =C2=A0 MAY be ignored by the compiler."
>
> ** Solution Yxx-01
>
>=C2=A0 =C2=A0 Extensions appearing in the server's model are an int= egral part of
>=C2=A0 =C2=A0 the server-client contract. That is, the server MUST impl= ement
>=C2=A0 =C2=A0 them, and the client SHOULD terminate the session if it d= oesn't
>=C2=A0 =C2=A0 implement any of the extensions.
>
> ** Solution Yxx-02
>
>=C2=A0 =C2=A0 Develop a mechanism for negotiating extensions.
>
> ** Solution Yxx-03
>
>=C2=A0 =C2=A0 Make extensions optional. This means that extensions won&= #39;t be
>=C2=A0 =C2=A0 allowed to change YANG language, NETCONF protocol, and va= lidity of
>=C2=A0 =C2=A0 datastores and protocol messages.
> ----------------------------------------------------------------------= --
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod >

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





--001a11c2640e575667051cf6b1ef-- From nobody Mon Aug 10 09:09:51 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFCAD1B37EF for ; Mon, 10 Aug 2015 09:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_34=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 iw49c9Pt7ouT for ; Mon, 10 Aug 2015 09:09:47 -0700 (PDT) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) (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 E180F1B3796 for ; Mon, 10 Aug 2015 09:09:44 -0700 (PDT) Received: by lbbtg9 with SMTP id tg9so60088820lbb.1 for ; Mon, 10 Aug 2015 09:09: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=LQPyMri663oxPGnQAPGtYPV6Suij1shjT4ix1gHalW0=; b=QzeTzbN+wuz0IbOf1YBID41tC1YW0Kt1eY4yonlNQM/ssW/M8m20iE5anLK9y+X9TC igb7juywj/+DyxU10bBQSTODr/ye6mE2t4tUVSIHmhgRbL0h89z5P88XGYLh22MeER7h syGKumYnd93gpyHhzbj8vG63ipyWSu44gpaL3qi+HVDyk3ZmTcVXLJFOJyD0HhdH0KMk Zi4fwHHXmS4a+GuBWP5HcFQdzVZkz0LT0HsA91I04z3ORXoMpTnIhjcl87kYNShRAF37 vps7s1Ymf+mJ0LjvWjLnoO7P/odBLWOqpFiDqCAg/e7sIEU/8Z1DRH5H7Ykd7ndDV4GJ VKtw== X-Gm-Message-State: ALoCoQkPM7l6COFs5Bhw2W681XwW1P8AzVM2mw60BLEwa6kWRZYAYLLZ6GR84K8XMWR1AV9A93Tu MIME-Version: 1.0 X-Received: by 10.112.170.2 with SMTP id ai2mr15225114lbc.82.1439222983195; Mon, 10 Aug 2015 09:09:43 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Mon, 10 Aug 2015 09:09:43 -0700 (PDT) In-Reply-To: References: <1FF17F20-66A0-4E68-8E07-08FD3CA76F04@cisco.com> Date: Mon, 10 Aug 2015 09:09:43 -0700 Message-ID: From: Andy Bierman To: Jonathan Hansford Content-Type: multipart/alternative; boundary=001a11c33e18aa9b48051cf73617 Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Y34 - root node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 16:09:50 -0000 --001a11c33e18aa9b48051cf73617 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Aug 10, 2015 at 1:46 AM, Jonathan Hansford wrote: > And it is not just end users who need help to better understand YANG > models and how to use them. For those still on the edge, looking to final= ly > take the plunge and use NETCONF/YANG to configure their devices, help is > also required to determine how best to structure their YANG models, make > use of the existing ones, etc. For those who have "grown up" with the > developments in NETCONF and YANG, much of this is probably second nature. > But coming to it cold (in the sense of compiling/writing a first set of > YANG models for a device; I've been following the netconf/netmod WGs for = 3+ > years), it still feels very much like a dark art! It is not just the > individual modules, it is how to put them together to best manage a devic= e > (let alone a system). > > IMO you are describing a different problem. Certainly YANG authors need to know how to use YANG most effectively. A separate problem is the ease of use of YANG module implementations within NETCONF or RESTCONF servers by operators. The current answer is (a) proprietary tool magic or (b) read every single YANG module very carefully and then all the vendor documentation. Then study the server module advertisements to plug in all the features, revisions, and deviations. The "resource directory" approach and YANG package approach are complimentary. It is useful to know that a on /services/routing will return the location of routing data. It is also useful to know in advance what modules are used for routing in each server. The location of actual resources should not be hard-wired and brittle. We should learn from HTTP how to manage resources without hard-wiring the paths to resources. > Jonathan > Andy > > > > ----- Original Message ----- > From: > "Einar Nilsen-Nygaard (einarnn)" > > To: > "Andy Bierman" > Cc: > "NETMOD Working Group" > Sent: > Sat, 8 Aug 2015 11:10:15 +0000 > Subject: > Re: [netmod] Y34 - root node > > > Andy, > > I agree that there is a need for organization of models, but I don=E2=80= =99t have > a firm position > on draft-openconfig-netmod-model-structure/draft-rtgyangdt-rtgwg-device-m= odel > or draft-bierman-netmod-yang-package. But we absolutely need *something* = to > help end-users of the models comprehend the overall structure of models, > their relationship and how to use them. > > Cheers, > > Einar > > On Aug 4, 2015, at 5:16 PM, Andy Bierman wrote: > > > > On Tue, Aug 4, 2015 at 2:34 AM, t.petch wrote: > >> ----- Original Message ----- >> From: "Andy Bierman" >> To: "t.petch" >> Sent: Monday, August 03, 2015 5:17 PM >> >> > ----- Original Message ----- >> > From: "Andy Bierman" > >> > To: "t.petch" >> > Sent: Monday, August 03, 2015 4:10 PM >> > >> > > ----- Original Message ----- >> > > From: "Andy Bierman" andy@yumaworks.com >> > > Sent: Saturday, August 01, 2015 7:05 PM >> > > On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem (acee) >> > > >> >>> On 8/1/15, 2:51 AM, j.schoenwaelder@jacobs-university.de> wrote: >> >>> >> >>> Section 1.1 in >> >>> >> > https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt >> >>> lists the goals of a generic model structure that will accommodate >> >> most >> >>> modern network devices. I guess you don=E2=80=99t agree that these a= re >> >> desirable? >> > > >> > > The only objection I have to this draft is the insertion of a >> top-level >> > > root >> > > called "device". (Might as well be called "self"). >> > > There are no sibling nodes planned or intended for >> > > this node, so it serves as an extra document root. >> > > >> > > >> > > One aspect of YANG I have never grasped is what a root means, if >> > > anything. >> > > >> > > I understand that it is needed for NETCONF (filters) and for YANG >> > > (augments, constraints) and so must be somewhere and must be >> > relatively >> > > stable, but has it any other significance in the data model? >> > > >> > > As you may recall, I was involved with SMI first, where the root is >> > > somewhere up in the sky and life only becomes interesting some six >> > > levels down the hierarchy and that may colour my thinking. >> > > >> > >> > YANG does a poor job of defining the root for YANG data nodes. >> > It is sometimes called a datastore (in the abstract). >> > Technically, YANG borrows the definition from XPath. >> > YANG just defines top-level data nodes and the parent of >> > these nodes is the document root >> > >> > There is no protocol or encoding neutral definition, >> > only an XML-specific definition. >> > >> > >> > >> > Thanks for that. >> > >> > It seems to me that much of the extensive discussion on Y34 (all of >> > which I have read) is as much political as technical, that is SMI is >> > hierarchical, top down, perhaps befitting its origins in ISO, whereas >> > YANG is bottom up. IETF-like. YANG could have had a single tree, but >> > doesn't. So when I read >> > >> > https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt >> > >> > I see a plea for a more hierarchical organisation, and when I read >> > >> > draft-bjorklund-netmod-openconfig-reply-00 >> > >> > I see a response that says we are not like that. >> > >> > If so, I doubt that there ever will be a technical solution. >> > >> > And I am mindful that when I configure routing in a (Cisco) router, I >> > have to do some of it under the interface definitions and some of it >> > under the definition of the routing protocol. Which is life, never >> > wholy interface-centric and never wholy routing protocol-centric! >> >> Are you saying the job would be easier if the >> path was /device/interfaces/interface instead >> of just /interfaces/interface? Are you saying >> that /protocols/routing could not also be defined? >> Clearly edit-config and copy-config allow both >> subtrees to be accessed in the same operation, >> so I don't understand your concern. >> >> I have been trying to get the root node to be better defined >> in the protocols that use YANG (i.e., ncx:root, Y34-04). >> IMO this is a better approach than defining a YANG module >> with a special container that all other modules are expected >> to augment. YANG is designed such that each vendor or SDO >> is not dependent on other vendors or SDOs in order to >> define data nodes. >> >> >> >> Andy >> >> I am agreeing with you that adding 'device' brings no technical benefit, >> rather that the motivation is the opposite of technical (which I >> referred to as political). I am also agreeing with the current declared >> consensus on Y34. >> >> And yes, YANG is going to give us a large number of modules, some >> tightly coupled (augments) some loosely so (how many do you need to >> configure OSPF?) and work in this area will be of benefit now and >> probably essential in a few years time. That said, I am unsure what >> such work would be like; I am looking (in despair) at 50 routing area >> YANG models and wondering how a user will ever get a coherent picture of >> how to do what they want to do. >> >> > > The "YANG Land Grab" gives a false sense of progress. > Reaching WG consensus on every single leaf is hard work. > > I don't think a collection of 100s of YANG modules is ever > going to to be easy to understand. Operators will not examine > a NETCONF message, look at 150 module URIs, > and say "I know exactly what this device supports". > I guess it is up to client tools to do that > > I wrote a draft that defines YANG Packages, which can provide > a higher level of organization for YANG modules. > > http://datatracker.ietf.org/doc/draft-bierman-netmod-yang-package/ > > You and I are apparently in the minority, since the official status > is that there is no problem with the current approach, and no need > to organize individual YANG modules into any larger abstractions. > > > > Tom Petch >> >> > > Andy > > >> Andy >> >> > Andy >> > >> > > The well-specified XPath and YANG root (/) can be >> > > accessed by all protocol operations, exactly the same >> > > as a node called 'device'. The actual node name will >> > > depend on the RPC function (e.g. 'data' or 'config'). >> > > >> > > This is more than redundant however. It introduces a "super-module" >> > > into YANG that every other module is expected to augment. >> > > YANG is intended to be more loosely coupled than that. >> > > This introduces an extra node and namespace declaration >> > > in all protocol messages, increasing message sizes. >> > > >> > > It also assumes all existing YANG models will get rewritten to >> > > account for "/device" in all path and XPath expressions. >> > > This is highly disruptive to existing deployments. >> > > Also, multiple data models to edit the same thing causes lots >> > > of extra complexity in the server (supporting both old >> > > location and new location). >> > > >> > > IMO a resource directory approach is much more realistic. >> > > The /device tree can contain all the organized NP containers. >> > > Instead of all the actual data nodes, this tree just has pointers >> > > to the real location of the resource. (like 301 Moved Permanently) >> > > >> > > > Acee >> > > > >> > > Andy >> >> >> ** Solution Y34-02 >> >> Keep 'anyxml'. Introduce 'anydata' as above but without the >> 'format' substatement. >> >> 'anyxml' would still be used to represent unrestricted XML, as is >> done in NETCONF. >> >> 'anydata' would be an unknown chunk of data that can be modelled >> with YANG. Can be encoded as xml or json. >> >> For example: >> >> #+BEGIN_EXAMPLE >> anydata data; >> #+END_EXAMPLE >> >> ** Solution Y34-05 >> >> Same as Y34-02 plus two guidelines adopted from Y34-04: >> >> - Keep 'anyxml' unchanged as it is defined in YANG 1.0. This >> ensures backward compatibility. >> - Introduce a new 'anydata' statement that represents an unknown >> chunk of data that can be modeled with YANG >> - Document that implementations MAY have restrictions for anyxml and >> that anyxml is not necessarily interoperable; data model writers >> should use anydata whenever possible. >> - The guidelines document should say that YANG Doctors will review >> each use of anyxml in IETF modules when YANG 1.1 is adopted to >> avoid its use whenever possible. >> >> >> > >> >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > --001a11c33e18aa9b48051cf73617 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Aug 10, 2015 at 1:46 AM, Jonathan Hansford &l= t;jonathan@hans= fords.net> wrote:
=C2=A0And it is not just end users who need help to better under= stand YANG models and how to use them. For those still on the edge, looking= to finally take the plunge and use NETCONF/YANG to configure their devices= , help is also required to determine how best to structure their YANG model= s, make use of the existing ones, etc. For those who have "grown up&qu= ot; with the developments in NETCONF and YANG, much of this is probably sec= ond nature. But coming to it cold (in the sense of compiling/writing a firs= t set of YANG models for a device; I've been following the netconf/netm= od WGs for 3+ years), it still feels very much like a dark art! It is not j= ust the individual modules, it is how to put them together to best manage a= device (let alone a system).


IMO you are describing a different problem.
Certainly YAN= G authors need to know how to use YANG most effectively.

A separate problem is the ease of use of YANG module implementations=
within NETCONF or RESTCONF servers by operators.

<= /div>
The current answer is (a) proprietary tool magic or (b) read ever= y single
YANG module very carefully and then all the vendor docum= entation.
Then study the server module advertisements to plug in = all the features,
revisions, and deviations.

=
The "resource directory" approach and YANG package approach = are
complimentary.=C2=A0 It is useful to know that a <get> = on /services/routing
will return the location of routing data.=C2= =A0 It is also useful to know in advance
what modules are used fo= r routing in each server.

The location of actual r= esources should not be hard-wired and brittle.
We should learn fr= om HTTP how to manage resources without hard-wiring
the paths to = resources.


=C2=A0
Jonathan


Andy
=C2=A0



----- Original Message -----
From:
"Einar N= ilsen-Nygaard (einarnn)" <einarnn@cisco.com>

To:
"Andy Bierman" <andy@yumaworks.com>
Cc:
"NETMOD Working Group" <netmod@ietf.org>
Sent:
Sat, 8 Aug 2015 11:10:15 +0000
Subject:
Re: [netmod] Y34 - root node

<= br> Andy,

I agree that there is a need for organization of models, but I don=E2= =80=99t have a firm position on=C2=A0draft-openconfig-netmod-model-structur= e/draft-rtgyangdt-rtgwg-device-model or=C2=A0draft-bierman-netmod-yang-pack= age. But we absolutely need *something* to help end-users of the models comprehend the overall structure of models, t= heir relationship and how to use them.

Cheers,

Einar

On Aug 4, 2015, at 5:16 PM, Andy Bierman <andy@yumaworks.com> wrote:



On Tue, Aug 4, 2015 at 2:34 AM, t.petch <ietfc@btconnec= t.com> wrote:
----- Original Message -----
From: "Andy Bierman" <andy@yumaworks.com>
To: "t.petch" <ietfc@btconnect.com>
Sent: Monday, August 03, 2015 5:17 PM

> ----- Original Message -----
> From: "Andy Bierman" <andy@yumaworkscom>
> To: "t.petch" <ietfc@btconnect.com>
> Sent: Monday, August 03, 2015 4:10 PM
>
> > ----- Original Message -----
> > From: "Andy Bierman" andy@yumaworks.com
> > Sent: Saturday, August 01, 2015 7:05 PM
> > On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem (acee) <acee@cisco.com>
> >
>>> On 8/1/15, 2:51 AM,=C2=A0 j.schoenwaelder@jacobs-university.de> wrote:
>>>
>>> Section 1.1 in
>>>
> https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt<= br> >>> lists the goals of a generic model structure that will accommo= date
>> most
>>> modern network devices. I guess you don=E2=80=99t agree that t= hese are
>> desirable?
> >
> > The only objection I have to this draft is the insertion of a
top-level
> > root
> > called "device".=C2=A0 (Might as well be called "s= elf").
> > There are no sibling nodes planned or intended for
> > this node, so it serves as an extra document root.
> >
> > <tp>
> > One aspect of YANG I have never grasped is what a root means, if<= br> > > anything.
> >
> > I understand that it is needed for NETCONF (filters) and for YANG=
> > (augments, constraints) and so must be somewhere and must be
> relatively
> > stable, but has it any other significance in the data model?
> >
> > As you may recall, I was involved with SMI first, where the root = is
> > somewhere up in the sky and life only becomes interesting some si= x
> > levels down the hierarchy and that may colour my thinking.
> >
>
> YANG does a poor job of defining the root for YANG data nodes.
> It is sometimes called a datastore (in the abstract).
> Technically, YANG borrows the definition from XPath.
> YANG just defines top-level data nodes and the parent of
> these nodes is the document root
>
> There is no protocol or encoding neutral definition,
> only an XML-specific definition.
>
> <tp>
>
> Thanks for that.
>
> It seems to me that much of the extensive discussion on Y34 (all of > which I have read) is as much political as technical, that is SMI is > hierarchical, top down, perhaps befitting its origins in ISO, whereas<= br> > YANG is bottom up. IETF-like.=C2=A0 YANG could have had a single tree,= but
> doesn't.=C2=A0 So when I read
>
> https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt<= br> >
> I see a plea for a more hierarchical organisation, and when I read
>
> draft-bjorklund-netmod-openconfig-reply-00
>
> I see a response that says we are not like that.
>
> If so, I doubt that there ever will be a technical solution.
>
> And I am mindful that when I configure routing in a (Cisco) router, I<= br> > have to do some of it under the interface definitions and some of it > under the definition of the routing protocol.=C2=A0 Which is life, nev= er
> wholy interface-centric and never wholy routing protocol-centric!
<= br> Are you saying the job would be easier if the
path was /device/interfaces/interface instead
of just /interfaces/interface?=C2=A0 Are you saying
that /protocols/routing could not also be defined?
Clearly edit-config and copy-config allow both
subtrees to be accessed in the same operation,
so I don't understand your concern.

I have been trying to get the root node to be better defined
in the protocols that use YANG (i.e., ncx:root, Y34-04).
IMO this is a better approach than defining a YANG module
with a special container that all other modules are expected
to augment.=C2=A0 YANG is designed such that each vendor or SDO
is not dependent on other vendors or SDOs in order to
define data nodes.

<tp>

Andy

I am agreeing with you that adding 'device' brings no technical ben= efit,
rather that the motivation is the opposite of technical (which I
referred to as political). I am also agreeing with the current declared
consensus on Y34.

And yes, YANG is going to give us a large number of modules, some
tightly coupled (augments) some loosely so (how many do you need to
configure OSPF?) and work in this area will be of benefit now and
probably essential in a few years time.=C2=A0 That said, I am unsure what such work would be like; I am looking (in despair) at 50 routing area
YANG models and wondering how a user will ever get a coherent picture of how to do what they want to do.



The "YANG Land Grab" gives a false sense of progress.
Reaching WG consensus on every single leaf is hard work.

I don't think a collection of 100s of YANG modules is ever
going to to be easy to understand.=C2=A0 Operators will not examine
a NETCONF <hello> message, look at 150 module URIs,
and say "I know exactly what this device supports".
I guess it is up to client tools to do that

I wrote a draft that defines YANG Packages, which can provide
a higher level of organization for YANG modules.


You and I are apparently in the minority, since the official status
is that there is no problem with the current approach, and no need
to organize individual YANG modules into any larger abstractions.



=C2=A0Tom Petch



Andy
=C2=A0
Andy

> Andy
>
> > The well-specified XPath and YANG root (/) can be
> > accessed by all protocol operations, exactly the same
> > as a node called 'device'.=C2=A0 The actual node name wil= l
> > depend on the RPC function (e.g. 'data' or 'config= 9;).
> >
> > This is more than redundant however.=C2=A0 It introduces a "= super-module"
> > into YANG that every other module is expected to augment.
> > YANG is intended to be more loosely coupled than that.
> > This introduces an extra node and namespace declaration
> > in all protocol messages, increasing message sizes.
> >
> > It also assumes all existing YANG models will get rewritten to > > account for "/device" in all path and XPath expressions= .
> > This is highly disruptive to existing deployments.
> > Also, multiple data models to edit the same thing causes lots
> > of extra complexity in the server (supporting both old
> > location and new location).
> >
> > IMO a resource directory approach is much more realistic.
> > The /device tree can contain all the organized NP containers.
> > Instead of all the actual data nodes, this tree just has pointers=
> > to the real location of the resource. (like 301 Moved Permanently= )
> >
> > > Acee
> > >
> > Andy


** Solution Y34-02

=C2=A0 Keep 'anyxml'.=C2=A0 Introduce 'anydata' as above bu= t without the
=C2=A0 'format' substatement.

=C2=A0 'anyxml' would still be used to represent unrestricted XML, = as is
=C2=A0 done in NETCONF.

=C2=A0 'anydata' would be an unknown chunk of data that can be mode= lled
=C2=A0 with YANG.=C2=A0 Can be encoded as xml or json.

=C2=A0 For example:

=C2=A0 =C2=A0 #+BEGIN_EXAMPLE
=C2=A0 =C2=A0 anydata data;
=C2=A0 =C2=A0 #+END_EXAMPLE

** Solution Y34-05

=C2=A0 =C2=A0Same as Y34-02 plus two guidelines adopted from Y34-04:
=C2=A0 =C2=A0- Keep 'anyxml' unchanged as it is defined in YANG 1.0= . This
=C2=A0 =C2=A0 =C2=A0ensures backward compatibility.
=C2=A0 =C2=A0- Introduce a new 'anydata' statement that represents = an unknown
=C2=A0 =C2=A0 =C2=A0chunk of data that can be modeled with YANG
=C2=A0 =C2=A0- Document that implementations MAY have restrictions for anyx= ml and
=C2=A0 =C2=A0 =C2=A0that anyxml is not necessarily interoperable; data mode= l writers
=C2=A0 =C2=A0 =C2=A0should use anydata whenever possible.
=C2=A0 =C2=A0- The guidelines document should say that YANG Doctors will re= view
=C2=A0 =C2=A0 =C2=A0each use of anyxml in IETF modules when YANG 1.1 is ado= pted to
=C2=A0 =C2=A0 =C2=A0avoid its use whenever possible.


>


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


--001a11c33e18aa9b48051cf73617-- From nobody Mon Aug 10 09:37:38 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABE71B3951 for ; Mon, 10 Aug 2015 09:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1V9_YKWejrzh for ; Mon, 10 Aug 2015 09:37:34 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C6CD1B394E for ; Mon, 10 Aug 2015 09:37:34 -0700 (PDT) Received: from [172.29.2.202] (nat-14.bravonet.cz [77.48.225.14]) by mail.nic.cz (Postfix) with ESMTPSA id B9BA2181462; Mon, 10 Aug 2015 18:37:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1439224652; bh=cH6YgrxkOLo1ZZF3jXgtyu5S9dbbHCdjQ5FcwmCxdcY=; h=From:Date:To; b=pEJKMjg3thoEPEk7WzBpOsyn/ioF/C8O10Z0/m5GBCMZ2laPD8e9dGWnIhsnaIKK8 VWCElPfpJAZlABC6pw9oyXz/ALGX8pb0/I6t6rGbNTUwItR/JkSmhK5Ncvu+zW5+i1 PaKW+61q6iRfT49XOtr3tc9bhtO0EUVvq+U8M1+k= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 10 Aug 2015 18:37:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <154527D1-C76B-49DD-B58D-39B197FAD033@nic.cz> References: <935AE06C-DF0E-4B79-BBB0-FBFC67297106@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] extensions and conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 16:37:36 -0000 > On 10 Aug 2015, at 17:32, Andy Bierman wrote: >=20 >=20 >=20 > On Mon, Aug 10, 2015 at 4:24 AM, Ladislav Lhotka = wrote: >=20 > > On 10 Aug 2015, at 12:17, Andy Bierman wrote: > > > > Hi, > > > > I am strongly against changing the contract on extensions. > > They MAY be ignored by any YANG tool. Period. > > That means they are far from mandatory. > > They are little more than a keyword and a description clause. >=20 > So do you prefer my proposed solution -02 or -03? >=20 > ** Solution Yxx-03 >=20 > Make extensions optional. This means that extensions won't be > allowed to change YANG language, NETCONF protocol, and validity of > datastores and protocol messages. >=20 >=20 > This is how we use extensions to tag YANG data models > to drive automation tools. But that means, for example, that annotations cannot be defined via an = extension statement as in draft-ietf-netmod-yang-metadata. >=20 > Your entire problem statement assumes that the consumer > of the extension is a protocol (client and/or server). > IMO this is really bad design to use statements for standards > that are by definition external to the YANG language, as if they > were part of the YANG language. This is just a hack and > it usually doesn't work well. Well, in the past you supported the idea of introducing new XPath = functions through extensions, and it is exactly of this sort. I=E2=80=99d also argue that current wording of 6020 allows a server = implementing =E2=80=9Cietf-system=E2=80=9D and =E2=80=9Cietf-netconf-nacm=E2= =80=9D to ignore the nacm:* extensions and make e.g. container = =E2=80=9Cauthentication=E2=80=9D writeable by default in non-recovery = sessions. >=20 > For example, when I pointed out that an extension for "ephemeral" > could not be modified with a refine-stmt, you just changed the > subject and ignored that problem. >=20 I didn=E2=80=99t ignore that problem, I just didn=E2=80=99t understand = why =E2=80=9Cephemeral=E2=80=9D (or any) extension needs to be refined. Lada >=20 >=20 > Andy >=20 >=20 > > > > There are not even any rules or help determining > > which extensions can appear as children of other > > extensions. That indicates that they are not > > real statements and not really part of YANG at all. > > > > There are some uses of extensions that fit the modular design, > > but not many. The NACM extensions only affect NACM. > > They have no impact whatsoever on any YANG statement. > > Yet even these statements should be real YANG statements. > > There is really no need to force implementation of NACM > > in order to utilize the concept of 'default-deny-all'. > > But full implementation of NACM is required to use these > > extensions. > > >=20 > The descriptions of =E2=80=9Cdefault-deny-write=E2=80=9D and = =E2=80=9Cdefault-deny-all=E2=80=9D describe normative server behaviour. = It is not even clear from 6020 text whether server implementations can = ignore these extensions or not and still use the modules where the = extensions are present. >=20 > Lada >=20 > > > > Andy > > > > > > On Mon, Aug 10, 2015 at 1:14 AM, Ladislav Lhotka = wrote: > > Hi, > > > > recent discussions show that 6020(bis) text about extensions isn't > > sufficiently clear about the scope and semantics of extensions. IMO = this > > needs to be fixed and so I propose to add the following item to YANG = 1.1 > > issue list. Comments and additional solutions are welcome. > > > > Lada > > > > = ------------------------------------------------------------------------ > > * NEW :Yxx: clarify conformance wrt extensions > > > > ** Description > > > > YANG extensions as defined in RFC 6020 have no limits on scope = =E2=80=93 > > they can possibly modify YANG language, datastore semantics or = even > > the NETCONF protocol. However, from the text in RFC 6020 it is > > unclear whether extensions appearing in YANG modules advertised = by > > a server are mandatory to implement: "If a YANG compiler does not > > support a particular extension, which appears in a YANG module as > > an unknown-statement (see Section 12), the entire = unknown-statement > > MAY be ignored by the compiler." > > > > ** Solution Yxx-01 > > > > Extensions appearing in the server's model are an integral part = of > > the server-client contract. That is, the server MUST implement > > them, and the client SHOULD terminate the session if it doesn't > > implement any of the extensions. > > > > ** Solution Yxx-02 > > > > Develop a mechanism for negotiating extensions. > > > > ** Solution Yxx-03 > > > > Make extensions optional. This means that extensions won't be > > allowed to change YANG language, NETCONF protocol, and validity = of > > datastores and protocol messages. > > = ------------------------------------------------------------------------ > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Aug 10 09:46:25 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 640391ACE5D for ; Mon, 10 Aug 2015 09:46:24 -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 6Lp8rN4ZzA3P for ; Mon, 10 Aug 2015 09:46:21 -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 E6A5C1A8750 for ; Mon, 10 Aug 2015 09:46:20 -0700 (PDT) Received: by lalv9 with SMTP id v9so14159524lal.0 for ; Mon, 10 Aug 2015 09:46: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=+MYrWpwiU+9TLXjZjN33+xaWguLZWUlHGk1yOLaYwik=; b=hUbi5oNGbVzJbpX5ukmDxbB3fPR3CTTLkT4wdDrc658Z4MTy7NOtY45DVQL8V9MFn7 Hm82a6ASwdJzyQ6gKuOeqecQb1hkXBmWcBZMJhPPl/4JUragKKWvVqf2v6LmB8oesZpc 4wFFaYYc5zbdFJvksd/TWQoxNkT2PG+E3uWTKF9Bl3DIQ/Ta+vDxcO0A3hrKZwNiDKYL +pwIz0E59+K7vKmlhI9zyHyZtIlXlnfC8FuPCeG19mnc1Gy2GBGx6KUdXGoaEERjkYP/ PsM4Puid8tMLCn7Nlh8MnqI42v7Y62h0EGPmEBQOZJ+In9JUpGWmRoP9wR4Cf/zypGPS OUQA== X-Gm-Message-State: ALoCoQk1SnKcf2KzZ07KMH7U3WNvVNVQkPg7VsAYUXCZW/Y2ZDW6QCt8NUwqg5ynHWz8L6mtLFiE MIME-Version: 1.0 X-Received: by 10.112.160.42 with SMTP id xh10mr20885222lbb.88.1439225179423; Mon, 10 Aug 2015 09:46:19 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Mon, 10 Aug 2015 09:46:19 -0700 (PDT) In-Reply-To: <154527D1-C76B-49DD-B58D-39B197FAD033@nic.cz> References: <935AE06C-DF0E-4B79-BBB0-FBFC67297106@nic.cz> <154527D1-C76B-49DD-B58D-39B197FAD033@nic.cz> Date: Mon, 10 Aug 2015 09:46:19 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c34238925118051cf7b9fe Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] extensions and conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 16:46:24 -0000 --001a11c34238925118051cf7b9fe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Aug 10, 2015 at 9:37 AM, Ladislav Lhotka wrote: > > > On 10 Aug 2015, at 17:32, Andy Bierman wrote: > > > > > > > > On Mon, Aug 10, 2015 at 4:24 AM, Ladislav Lhotka wrote: > > > > > On 10 Aug 2015, at 12:17, Andy Bierman wrote: > > > > > > Hi, > > > > > > I am strongly against changing the contract on extensions. > > > They MAY be ignored by any YANG tool. Period. > > > That means they are far from mandatory. > > > They are little more than a keyword and a description clause. > > > > So do you prefer my proposed solution -02 or -03? > > > > ** Solution Yxx-03 > > > > Make extensions optional. This means that extensions won't be > > allowed to change YANG language, NETCONF protocol, and validity of > > datastores and protocol messages. > > > > > > This is how we use extensions to tag YANG data models > > to drive automation tools. > > But that means, for example, that annotations cannot be defined via an > extension statement as in draft-ietf-netmod-yang-metadata. > > Which means these statements should be real instead of extensions. If the statements are defining data that is exchanged between peers in a standard protocol, then YANG extensions are not appropriate. > > > Your entire problem statement assumes that the consumer > > of the extension is a protocol (client and/or server). > > IMO this is really bad design to use statements for standards > > that are by definition external to the YANG language, as if they > > were part of the YANG language. This is just a hack and > > it usually doesn't work well. > > Well, in the past you supported the idea of introducing new XPath > functions through extensions, and it is exactly of this sort. > > I don't remember the details, but new XPath functions should be part of the language, not extensions. > I=E2=80=99d also argue that current wording of 6020 allows a server imple= menting > =E2=80=9Cietf-system=E2=80=9D and =E2=80=9Cietf-netconf-nacm=E2=80=9D to = ignore the nacm:* extensions and > make e.g. container =E2=80=9Cauthentication=E2=80=9D writeable by default= in non-recovery > sessions. > > > > > For example, when I pointed out that an extension for "ephemeral" > > could not be modified with a refine-stmt, you just changed the > > subject and ignored that problem. > > > > I didn=E2=80=99t ignore that problem, I just didn=E2=80=99t understand wh= y =E2=80=9Cephemeral=E2=80=9D (or > any) extension needs to be refined. > > Because it is common for data is defined in a grouping without any config-stmt (or ephemeral-stmt) and then add these in for each uses-stmt. Lada > > Andy > > > > > > Andy > > > > > > > > > > There are not even any rules or help determining > > > which extensions can appear as children of other > > > extensions. That indicates that they are not > > > real statements and not really part of YANG at all. > > > > > > There are some uses of extensions that fit the modular design, > > > but not many. The NACM extensions only affect NACM. > > > They have no impact whatsoever on any YANG statement. > > > Yet even these statements should be real YANG statements. > > > There is really no need to force implementation of NACM > > > in order to utilize the concept of 'default-deny-all'. > > > But full implementation of NACM is required to use these > > > extensions. > > > > > > > The descriptions of =E2=80=9Cdefault-deny-write=E2=80=9D and =E2=80=9Cd= efault-deny-all=E2=80=9D describe > normative server behaviour. It is not even clear from 6020 text whether > server implementations can ignore these extensions or not and still use t= he > modules where the extensions are present. > > > > Lada > > > > > > > > Andy > > > > > > > > > On Mon, Aug 10, 2015 at 1:14 AM, Ladislav Lhotka > wrote: > > > Hi, > > > > > > recent discussions show that 6020(bis) text about extensions isn't > > > sufficiently clear about the scope and semantics of extensions. IMO > this > > > needs to be fixed and so I propose to add the following item to YANG > 1.1 > > > issue list. Comments and additional solutions are welcome. > > > > > > Lada > > > > > > > ------------------------------------------------------------------------ > > > * NEW :Yxx: clarify conformance wrt extensions > > > > > > ** Description > > > > > > YANG extensions as defined in RFC 6020 have no limits on scope =E2= =80=93 > > > they can possibly modify YANG language, datastore semantics or eve= n > > > the NETCONF protocol. However, from the text in RFC 6020 it is > > > unclear whether extensions appearing in YANG modules advertised by > > > a server are mandatory to implement: "If a YANG compiler does not > > > support a particular extension, which appears in a YANG module as > > > an unknown-statement (see Section 12), the entire unknown-statemen= t > > > MAY be ignored by the compiler." > > > > > > ** Solution Yxx-01 > > > > > > Extensions appearing in the server's model are an integral part of > > > the server-client contract. That is, the server MUST implement > > > them, and the client SHOULD terminate the session if it doesn't > > > implement any of the extensions. > > > > > > ** Solution Yxx-02 > > > > > > Develop a mechanism for negotiating extensions. > > > > > > ** Solution Yxx-03 > > > > > > Make extensions optional. This means that extensions won't be > > > allowed to change YANG language, NETCONF protocol, and validity of > > > datastores and protocol messages. > > > > ------------------------------------------------------------------------ > > > > > > -- > > > Ladislav Lhotka, CZ.NIC Labs > > > PGP Key ID: E74E8C0C > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > > > > > > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a11c34238925118051cf7b9fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Aug 10, 2015 at 9:37 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:

> On 10 Aug 2015, at 17:32, Andy Bierman <andy@yumaworks.com> wrote:
>
>
>
> On Mon, Aug 10, 2015 at 4:24 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> > On 10 Aug 2015, at 12:17, Andy Bierman <andy@yumaworks.com> wrote:
> >
> > Hi,
> >
> > I am strongly against changing the contract on extensions.
> > They MAY be ignored by any YANG tool. Period.
> > That means they are far from mandatory.
> > They are little more than a keyword and a description clause.
>
> So do you prefer my proposed solution -02 or -03?
>
> ** Solution Yxx-03
>
>=C2=A0 =C2=A0 Make extensions optional. This means that extensions won&= #39;t be
>=C2=A0 =C2=A0 allowed to change YANG language, NETCONF protocol, and va= lidity of
>=C2=A0 =C2=A0 datastores and protocol messages.
>
>
> This is how we use extensions to tag YANG data models
> to drive automation tools.

But that means, for example, that annotations cannot be defined via an exte= nsion statement as in draft-ietf-netmod-yang-metadata.



Which means these state= ments should be real instead of extensions.
If the statements are= defining data that is exchanged between
peers in a standard prot= ocol, then YANG extensions are not
appropriate.


>
> Your entire problem statement assumes that the consumer
> of the extension is a protocol (client and/or server).
> IMO this is really bad design to use statements for standards
> that are by definition external to the YANG language, as if they
> were part of the YANG language.=C2=A0 This is just a hack and
> it usually doesn't work well.

Well, in the past you supported the idea of introducing new XPath functions= through extensions, and it is exactly of this sort.


I don't remember the details, but = new XPath functions
should be part of the language, not extension= s.

=C2=A0
I=E2=80=99d also argue that current wording of 6020 allows a server impleme= nting =E2=80=9Cietf-system=E2=80=9D and =E2=80=9Cietf-netconf-nacm=E2=80=9D= to ignore the nacm:* extensions and make e.g. container =E2=80=9Cauthentic= ation=E2=80=9D writeable by default in non-recovery sessions.

>
> For example, when I pointed out that an extension for "ephemeral&= quot;
> could not be modified with a refine-stmt, you just changed the
> subject and ignored that problem.
>

I didn=E2=80=99t ignore that problem, I just didn=E2=80=99t understand why = =E2=80=9Cephemeral=E2=80=9D (or any) extension needs to be refined.



Because it is common fo= r data is defined in a grouping without any config-stmt
(or ephem= eral-stmt) and then add these in for each uses-stmt.


Lada


Andy
=C2=A0
>
>
>=C2=A0 Andy
>
>
> >
> > There are not even any rules or help determining
> > which extensions can appear as children of other
> > extensions.=C2=A0 That indicates that they are not
> > real statements and not really part of YANG at all.
> >
> > There are some uses of extensions that fit the modular design, > > but not many.=C2=A0 The NACM extensions only affect NACM.
> > They have no impact whatsoever on any YANG statement.
> > Yet even these statements should be real YANG statements.
> > There is really no need to force implementation of NACM
> > in order to utilize the concept of 'default-deny-all'. > > But full implementation of NACM is required to use these
> > extensions.
> >
>
> The descriptions of =E2=80=9Cdefault-deny-write=E2=80=9D and =E2=80=9C= default-deny-all=E2=80=9D describe normative server behaviour. It is not ev= en clear from 6020 text whether server implementations can ignore these ext= ensions or not and still use the modules where the extensions are present.<= br> >
> Lada
>
> >
> > Andy
> >
> >
> > On Mon, Aug 10, 2015 at 1:14 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> > Hi,
> >
> > recent discussions show that 6020(bis) text about extensions isn&= #39;t
> > sufficiently clear about the scope and semantics of extensions. I= MO this
> > needs to be fixed and so I propose to add the following item to Y= ANG 1.1
> > issue list. Comments and additional solutions are welcome.
> >
> > Lada
> >
> > -----------------------------------------------------------------= -------
> > * NEW :Yxx: clarify conformance wrt extensions
> >
> > ** Description
> >
> >=C2=A0 =C2=A0 YANG extensions as defined in RFC 6020 have no limit= s on scope =E2=80=93
> >=C2=A0 =C2=A0 they can possibly modify YANG language, datastore se= mantics or even
> >=C2=A0 =C2=A0 the NETCONF protocol. However, from the text in RFC = 6020 it is
> >=C2=A0 =C2=A0 unclear whether extensions appearing in YANG modules= advertised by
> >=C2=A0 =C2=A0 a server are mandatory to implement: "If a YANG= compiler does not
> >=C2=A0 =C2=A0 support a particular extension, which appears in a Y= ANG module as
> >=C2=A0 =C2=A0 an unknown-statement (see Section 12), the entire un= known-statement
> >=C2=A0 =C2=A0 MAY be ignored by the compiler."
> >
> > ** Solution Yxx-01
> >
> >=C2=A0 =C2=A0 Extensions appearing in the server's model are a= n integral part of
> >=C2=A0 =C2=A0 the server-client contract. That is, the server MUST= implement
> >=C2=A0 =C2=A0 them, and the client SHOULD terminate the session if= it doesn't
> >=C2=A0 =C2=A0 implement any of the extensions.
> >
> > ** Solution Yxx-02
> >
> >=C2=A0 =C2=A0 Develop a mechanism for negotiating extensions.
> >
> > ** Solution Yxx-03
> >
> >=C2=A0 =C2=A0 Make extensions optional. This means that extensions= won't be
> >=C2=A0 =C2=A0 allowed to change YANG language, NETCONF protocol, a= nd validity of
> >=C2=A0 =C2=A0 datastores and protocol messages.
> > -----------------------------------------------------------------= -------
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>

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





--001a11c34238925118051cf7b9fe-- From nobody Mon Aug 10 10:01:09 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE2381B3867 for ; Mon, 10 Aug 2015 10:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.661 X-Spam-Level: X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PRNXFJYApGTQ for ; Mon, 10 Aug 2015 10:01:05 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B0DF1B398F for ; Mon, 10 Aug 2015 10:01:04 -0700 (PDT) Received: from [IPv6:2a01:5e0:29:ffff:ed04:65c0:261a:60a2] (unknown [IPv6:2a01:5e0:29:ffff:ed04:65c0:261a:60a2]) by mail.nic.cz (Postfix) with ESMTPSA id 9E31B181721; Mon, 10 Aug 2015 19:01:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1439226062; bh=fnzVxRi2AfpoLOrg64VxDFW+vo7NQuslVh8gMIA3HhA=; h=From:Date:To; b=b8NtV7IDZAz/O1a6fAyZTHu/18qSIEWLSJhH0TrtGc2HJgsQEeEuBunoZ3ee9sL/o 2DllX+ms67lpHxvhGxHN5CsNk6uz/jJ9dvnUaxkI0b34YgK56o0NSo2K+wnqGoPpw/ g0ZdZFODd6Jpg9M5G2jIHnJoL+yEaEeSUETjlwxY= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 10 Aug 2015 19:01:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9B232151-C380-4B43-BAF4-88F7E4821B8D@nic.cz> References: <935AE06C-DF0E-4B79-BBB0-FBFC67297106@nic.cz> <154527D1-C76B-49DD-B58D-39B197FAD033@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] extensions and conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 17:01:08 -0000 > On 10 Aug 2015, at 18:46, Andy Bierman wrote: >=20 >=20 >=20 > On Mon, Aug 10, 2015 at 9:37 AM, Ladislav Lhotka = wrote: >=20 > > On 10 Aug 2015, at 17:32, Andy Bierman wrote: > > > > > > > > On Mon, Aug 10, 2015 at 4:24 AM, Ladislav Lhotka = wrote: > > > > > On 10 Aug 2015, at 12:17, Andy Bierman wrote: > > > > > > Hi, > > > > > > I am strongly against changing the contract on extensions. > > > They MAY be ignored by any YANG tool. Period. > > > That means they are far from mandatory. > > > They are little more than a keyword and a description clause. > > > > So do you prefer my proposed solution -02 or -03? > > > > ** Solution Yxx-03 > > > > Make extensions optional. This means that extensions won't be > > allowed to change YANG language, NETCONF protocol, and validity = of > > datastores and protocol messages. > > > > > > This is how we use extensions to tag YANG data models > > to drive automation tools. >=20 > But that means, for example, that annotations cannot be defined via an = extension statement as in draft-ietf-netmod-yang-metadata. >=20 >=20 >=20 > Which means these statements should be real instead of extensions. > If the statements are defining data that is exchanged between > peers in a standard protocol, then YANG extensions are not > appropriate. I agree, and -03 is my preferred solution, too. >=20 >=20 > > > > Your entire problem statement assumes that the consumer > > of the extension is a protocol (client and/or server). > > IMO this is really bad design to use statements for standards > > that are by definition external to the YANG language, as if they > > were part of the YANG language. This is just a hack and > > it usually doesn't work well. >=20 > Well, in the past you supported the idea of introducing new XPath = functions through extensions, and it is exactly of this sort. >=20 >=20 > I don't remember the details, but new XPath functions > should be part of the language, not extensions. >=20 > =20 > I=E2=80=99d also argue that current wording of 6020 allows a server = implementing =E2=80=9Cietf-system=E2=80=9D and =E2=80=9Cietf-netconf-nacm=E2= =80=9D to ignore the nacm:* extensions and make e.g. container = =E2=80=9Cauthentication=E2=80=9D writeable by default in non-recovery = sessions. >=20 > > > > For example, when I pointed out that an extension for "ephemeral" > > could not be modified with a refine-stmt, you just changed the > > subject and ignored that problem. > > >=20 > I didn=E2=80=99t ignore that problem, I just didn=E2=80=99t understand = why =E2=80=9Cephemeral=E2=80=9D (or any) extension needs to be refined. >=20 >=20 >=20 > Because it is common for data is defined in a grouping without any = config-stmt > (or ephemeral-stmt) and then add these in for each uses-stmt. OK, I see. Lada >=20 >=20 > Lada >=20 >=20 > Andy > =20 > > > > > > Andy > > > > > > > > > > There are not even any rules or help determining > > > which extensions can appear as children of other > > > extensions. That indicates that they are not > > > real statements and not really part of YANG at all. > > > > > > There are some uses of extensions that fit the modular design, > > > but not many. The NACM extensions only affect NACM. > > > They have no impact whatsoever on any YANG statement. > > > Yet even these statements should be real YANG statements. > > > There is really no need to force implementation of NACM > > > in order to utilize the concept of 'default-deny-all'. > > > But full implementation of NACM is required to use these > > > extensions. > > > > > > > The descriptions of =E2=80=9Cdefault-deny-write=E2=80=9D and = =E2=80=9Cdefault-deny-all=E2=80=9D describe normative server behaviour. = It is not even clear from 6020 text whether server implementations can = ignore these extensions or not and still use the modules where the = extensions are present. > > > > Lada > > > > > > > > Andy > > > > > > > > > On Mon, Aug 10, 2015 at 1:14 AM, Ladislav Lhotka = wrote: > > > Hi, > > > > > > recent discussions show that 6020(bis) text about extensions isn't > > > sufficiently clear about the scope and semantics of extensions. = IMO this > > > needs to be fixed and so I propose to add the following item to = YANG 1.1 > > > issue list. Comments and additional solutions are welcome. > > > > > > Lada > > > > > > = ------------------------------------------------------------------------ > > > * NEW :Yxx: clarify conformance wrt extensions > > > > > > ** Description > > > > > > YANG extensions as defined in RFC 6020 have no limits on scope = =E2=80=93 > > > they can possibly modify YANG language, datastore semantics or = even > > > the NETCONF protocol. However, from the text in RFC 6020 it is > > > unclear whether extensions appearing in YANG modules advertised = by > > > a server are mandatory to implement: "If a YANG compiler does = not > > > support a particular extension, which appears in a YANG module = as > > > an unknown-statement (see Section 12), the entire = unknown-statement > > > MAY be ignored by the compiler." > > > > > > ** Solution Yxx-01 > > > > > > Extensions appearing in the server's model are an integral part = of > > > the server-client contract. That is, the server MUST implement > > > them, and the client SHOULD terminate the session if it doesn't > > > implement any of the extensions. > > > > > > ** Solution Yxx-02 > > > > > > Develop a mechanism for negotiating extensions. > > > > > > ** Solution Yxx-03 > > > > > > Make extensions optional. This means that extensions won't be > > > allowed to change YANG language, NETCONF protocol, and validity = of > > > datastores and protocol messages. > > > = ------------------------------------------------------------------------ > > > > > > -- > > > Ladislav Lhotka, CZ.NIC Labs > > > PGP Key ID: E74E8C0C > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > > > > > > > >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Aug 10 10:36:34 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84C1F1B29EA for ; Mon, 10 Aug 2015 10:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OyfXTvVe6ycK for ; Mon, 10 Aug 2015 10:36:29 -0700 (PDT) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 031F21AD351 for ; Mon, 10 Aug 2015 10:36:29 -0700 (PDT) Received: by lagz9 with SMTP id z9so57572873lag.3 for ; Mon, 10 Aug 2015 10:36:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=lp/sMm7gzwcFxuvtE4pG/skDyFEZ4hq1FiPdYSqwJFU=; b=SfLodAfCxaknD2pw/b/0QKDwJ5Kiz9vSKOIjAYS2yaaZosdEZbWIRkQKpgXwdpauZ1 yQEunYb0LTrZKR2eDJl+aucL/POrXDNoHmFKIbIdXMjieFDLXFuoV7HaddKk3lCCeVUW phdFnIgp7kxAzAhxh5ZK56fwjOZUgg1YLP3m/OfEZ253eTFU5+rtH8rua36zD8vuqF2c L3F31k6NNSPqliBU9n/4tKvgr3yki7O4DVFQ2f0AVm7xd82ky0LJVOXl1QzUgvRXY8J5 i1ZK4/tmjNm4/SVZuEHlkHJfvyW9TvhGC8G3aoWFmR9dRIHexIZQ1+0eQoE2TlgNRCjW W7OQ== X-Gm-Message-State: ALoCoQlB7P7q/3UG80yT8PoUfKRp2HLcsJH//ZjGyZRmSCKEGiqKwseEaIsf2rYei/g4nF8fcGVI MIME-Version: 1.0 X-Received: by 10.152.88.106 with SMTP id bf10mr20954700lab.82.1439228187376; Mon, 10 Aug 2015 10:36:27 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Mon, 10 Aug 2015 10:36:27 -0700 (PDT) In-Reply-To: <9B232151-C380-4B43-BAF4-88F7E4821B8D@nic.cz> References: <935AE06C-DF0E-4B79-BBB0-FBFC67297106@nic.cz> <154527D1-C76B-49DD-B58D-39B197FAD033@nic.cz> <9B232151-C380-4B43-BAF4-88F7E4821B8D@nic.cz> Date: Mon, 10 Aug 2015 10:36:27 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c2640edc1a1b051cf86cc3 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] extensions and conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 17:36:32 -0000 --001a11c2640edc1a1b051cf86cc3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Aug 10, 2015 at 10:01 AM, Ladislav Lhotka wrote: > > > On 10 Aug 2015, at 18:46, Andy Bierman wrote: > > > > > > > > On Mon, Aug 10, 2015 at 9:37 AM, Ladislav Lhotka wrote: > > > > > On 10 Aug 2015, at 17:32, Andy Bierman wrote: > > > > > > > > > > > > On Mon, Aug 10, 2015 at 4:24 AM, Ladislav Lhotka > wrote: > > > > > > > On 10 Aug 2015, at 12:17, Andy Bierman wrote: > > > > > > > > Hi, > > > > > > > > I am strongly against changing the contract on extensions. > > > > They MAY be ignored by any YANG tool. Period. > > > > That means they are far from mandatory. > > > > They are little more than a keyword and a description clause. > > > > > > So do you prefer my proposed solution -02 or -03? > > > > > > ** Solution Yxx-03 > > > > > > Make extensions optional. This means that extensions won't be > > > allowed to change YANG language, NETCONF protocol, and validity of > > > datastores and protocol messages. > > > > > > > > > This is how we use extensions to tag YANG data models > > > to drive automation tools. > > > > But that means, for example, that annotations cannot be defined via an > extension statement as in draft-ietf-netmod-yang-metadata. > > > > > > > > Which means these statements should be real instead of extensions. > > If the statements are defining data that is exchanged between > > peers in a standard protocol, then YANG extensions are not > > appropriate. > > I agree, and -03 is my preferred solution, too. > > This would allow "if-feature" to be used so attributes would not have to be mandatory. Andy > > > > > > > > > > Your entire problem statement assumes that the consumer > > > of the extension is a protocol (client and/or server). > > > IMO this is really bad design to use statements for standards > > > that are by definition external to the YANG language, as if they > > > were part of the YANG language. This is just a hack and > > > it usually doesn't work well. > > > > Well, in the past you supported the idea of introducing new XPath > functions through extensions, and it is exactly of this sort. > > > > > > I don't remember the details, but new XPath functions > > should be part of the language, not extensions. > > > > > > I=E2=80=99d also argue that current wording of 6020 allows a server imp= lementing > =E2=80=9Cietf-system=E2=80=9D and =E2=80=9Cietf-netconf-nacm=E2=80=9D to = ignore the nacm:* extensions and > make e.g. container =E2=80=9Cauthentication=E2=80=9D writeable by default= in non-recovery > sessions. > > > > > > > > For example, when I pointed out that an extension for "ephemeral" > > > could not be modified with a refine-stmt, you just changed the > > > subject and ignored that problem. > > > > > > > I didn=E2=80=99t ignore that problem, I just didn=E2=80=99t understand = why =E2=80=9Cephemeral=E2=80=9D > (or any) extension needs to be refined. > > > > > > > > Because it is common for data is defined in a grouping without any > config-stmt > > (or ephemeral-stmt) and then add these in for each uses-stmt. > > OK, I see. > > Lada > > > > > > > Lada > > > > > > Andy > > > > > > > > > > > Andy > > > > > > > > > > > > > > There are not even any rules or help determining > > > > which extensions can appear as children of other > > > > extensions. That indicates that they are not > > > > real statements and not really part of YANG at all. > > > > > > > > There are some uses of extensions that fit the modular design, > > > > but not many. The NACM extensions only affect NACM. > > > > They have no impact whatsoever on any YANG statement. > > > > Yet even these statements should be real YANG statements. > > > > There is really no need to force implementation of NACM > > > > in order to utilize the concept of 'default-deny-all'. > > > > But full implementation of NACM is required to use these > > > > extensions. > > > > > > > > > > The descriptions of =E2=80=9Cdefault-deny-write=E2=80=9D and =E2=80= =9Cdefault-deny-all=E2=80=9D > describe normative server behaviour. It is not even clear from 6020 text > whether server implementations can ignore these extensions or not and sti= ll > use the modules where the extensions are present. > > > > > > Lada > > > > > > > > > > > Andy > > > > > > > > > > > > On Mon, Aug 10, 2015 at 1:14 AM, Ladislav Lhotka > wrote: > > > > Hi, > > > > > > > > recent discussions show that 6020(bis) text about extensions isn't > > > > sufficiently clear about the scope and semantics of extensions. IMO > this > > > > needs to be fixed and so I propose to add the following item to YAN= G > 1.1 > > > > issue list. Comments and additional solutions are welcome. > > > > > > > > Lada > > > > > > > > > ------------------------------------------------------------------------ > > > > * NEW :Yxx: clarify conformance wrt extensions > > > > > > > > ** Description > > > > > > > > YANG extensions as defined in RFC 6020 have no limits on scope = =E2=80=93 > > > > they can possibly modify YANG language, datastore semantics or > even > > > > the NETCONF protocol. However, from the text in RFC 6020 it is > > > > unclear whether extensions appearing in YANG modules advertised = by > > > > a server are mandatory to implement: "If a YANG compiler does no= t > > > > support a particular extension, which appears in a YANG module a= s > > > > an unknown-statement (see Section 12), the entire > unknown-statement > > > > MAY be ignored by the compiler." > > > > > > > > ** Solution Yxx-01 > > > > > > > > Extensions appearing in the server's model are an integral part = of > > > > the server-client contract. That is, the server MUST implement > > > > them, and the client SHOULD terminate the session if it doesn't > > > > implement any of the extensions. > > > > > > > > ** Solution Yxx-02 > > > > > > > > Develop a mechanism for negotiating extensions. > > > > > > > > ** Solution Yxx-03 > > > > > > > > Make extensions optional. This means that extensions won't be > > > > allowed to change YANG language, NETCONF protocol, and validity = of > > > > datastores and protocol messages. > > > > > ------------------------------------------------------------------------ > > > > > > > > -- > > > > Ladislav Lhotka, CZ.NIC Labs > > > > PGP Key ID: E74E8C0C > > > > > > > > _______________________________________________ > > > > netmod mailing list > > > > netmod@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > > -- > > > Ladislav Lhotka, CZ.NIC Labs > > > PGP Key ID: E74E8C0C > > > > > > > > > > > > > > > > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a11c2640edc1a1b051cf86cc3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Aug 10, 2015 at 10:01 AM, Ladislav Lhotka <= ;lhotka@nic.cz> wrote:

> On 10 Aug 2015, at 18:46, Andy Bierman <andy@yumaworks.com> wrote:
>
>
>
> On Mon, Aug 10, 2015 at 9:37 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> > On 10 Aug 2015, at 17:32, Andy Bierman <andy@yumaworks.com> wrote:
> >
> >
> >
> > On Mon, Aug 10, 2015 at 4:24 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> >
> > > On 10 Aug 2015, at 12:17, Andy Bierman <andy@yumaworks.com> wrote:
> > >
> > > Hi,
> > >
> > > I am strongly against changing the contract on extensions. > > > They MAY be ignored by any YANG tool. Period.
> > > That means they are far from mandatory.
> > > They are little more than a keyword and a description clause= .
> >
> > So do you prefer my proposed solution -02 or -03?
> >
> > ** Solution Yxx-03
> >
> >=C2=A0 =C2=A0 Make extensions optional. This means that extensions= won't be
> >=C2=A0 =C2=A0 allowed to change YANG language, NETCONF protocol, a= nd validity of
> >=C2=A0 =C2=A0 datastores and protocol messages.
> >
> >
> > This is how we use extensions to tag YANG data models
> > to drive automation tools.
>
> But that means, for example, that annotations cannot be defined via an= extension statement as in draft-ietf-netmod-yang-metadata.
>
>
>
> Which means these statements should be real instead of extensions.
> If the statements are defining data that is exchanged between
> peers in a standard protocol, then YANG extensions are not
> appropriate.

I agree, and -03 is my preferred solution, too.



This would allow "= if-feature" to be used so attributes would not
have to be ma= ndatory.


Andy

<= div>
=C2=A0
>
>
> >
> > Your entire problem statement assumes that the consumer
> > of the extension is a protocol (client and/or server).
> > IMO this is really bad design to use statements for standards
> > that are by definition external to the YANG language, as if they<= br> > > were part of the YANG language.=C2=A0 This is just a hack and
> > it usually doesn't work well.
>
> Well, in the past you supported the idea of introducing new XPath func= tions through extensions, and it is exactly of this sort.
>
>
> I don't remember the details, but new XPath functions
> should be part of the language, not extensions.
>
>
> I=E2=80=99d also argue that current wording of 6020 allows a server im= plementing =E2=80=9Cietf-system=E2=80=9D and =E2=80=9Cietf-netconf-nacm=E2= =80=9D to ignore the nacm:* extensions and make e.g. container =E2=80=9Caut= hentication=E2=80=9D writeable by default in non-recovery sessions.
>
> >
> > For example, when I pointed out that an extension for "ephem= eral"
> > could not be modified with a refine-stmt, you just changed the > > subject and ignored that problem.
> >
>
> I didn=E2=80=99t ignore that problem, I just didn=E2=80=99t understand= why =E2=80=9Cephemeral=E2=80=9D (or any) extension needs to be refined. >
>
>
> Because it is common for data is defined in a grouping without any con= fig-stmt
> (or ephemeral-stmt) and then add these in for each uses-stmt.

OK, I see.

Lada

>
>
> Lada
>
>
> Andy
>
> >
> >
> >=C2=A0 Andy
> >
> >
> > >
> > > There are not even any rules or help determining
> > > which extensions can appear as children of other
> > > extensions.=C2=A0 That indicates that they are not
> > > real statements and not really part of YANG at all.
> > >
> > > There are some uses of extensions that fit the modular desig= n,
> > > but not many.=C2=A0 The NACM extensions only affect NACM. > > > They have no impact whatsoever on any YANG statement.
> > > Yet even these statements should be real YANG statements. > > > There is really no need to force implementation of NACM
> > > in order to utilize the concept of 'default-deny-all'= ;.
> > > But full implementation of NACM is required to use these
> > > extensions.
> > >
> >
> > The descriptions of =E2=80=9Cdefault-deny-write=E2=80=9D and =E2= =80=9Cdefault-deny-all=E2=80=9D describe normative server behaviour. It is = not even clear from 6020 text whether server implementations can ignore the= se extensions or not and still use the modules where the extensions are pre= sent.
> >
> > Lada
> >
> > >
> > > Andy
> > >
> > >
> > > On Mon, Aug 10, 2015 at 1:14 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> > > Hi,
> > >
> > > recent discussions show that 6020(bis) text about extensions= isn't
> > > sufficiently clear about the scope and semantics of extensio= ns. IMO this
> > > needs to be fixed and so I propose to add the following item= to YANG 1.1
> > > issue list. Comments and additional solutions are welcome. > > >
> > > Lada
> > >
> > > ------------------------------------------------------------= ------------
> > > * NEW :Yxx: clarify conformance wrt extensions
> > >
> > > ** Description
> > >
> > >=C2=A0 =C2=A0 YANG extensions as defined in RFC 6020 have no = limits on scope =E2=80=93
> > >=C2=A0 =C2=A0 they can possibly modify YANG language, datasto= re semantics or even
> > >=C2=A0 =C2=A0 the NETCONF protocol. However, from the text in= RFC 6020 it is
> > >=C2=A0 =C2=A0 unclear whether extensions appearing in YANG mo= dules advertised by
> > >=C2=A0 =C2=A0 a server are mandatory to implement: "If a= YANG compiler does not
> > >=C2=A0 =C2=A0 support a particular extension, which appears i= n a YANG module as
> > >=C2=A0 =C2=A0 an unknown-statement (see Section 12), the enti= re unknown-statement
> > >=C2=A0 =C2=A0 MAY be ignored by the compiler."
> > >
> > > ** Solution Yxx-01
> > >
> > >=C2=A0 =C2=A0 Extensions appearing in the server's model = are an integral part of
> > >=C2=A0 =C2=A0 the server-client contract. That is, the server= MUST implement
> > >=C2=A0 =C2=A0 them, and the client SHOULD terminate the sessi= on if it doesn't
> > >=C2=A0 =C2=A0 implement any of the extensions.
> > >
> > > ** Solution Yxx-02
> > >
> > >=C2=A0 =C2=A0 Develop a mechanism for negotiating extensions.=
> > >
> > > ** Solution Yxx-03
> > >
> > >=C2=A0 =C2=A0 Make extensions optional. This means that exten= sions won't be
> > >=C2=A0 =C2=A0 allowed to change YANG language, NETCONF protoc= ol, and validity of
> > >=C2=A0 =C2=A0 datastores and protocol messages.
> > > ------------------------------------------------------------= ------------
> > >
> > > --
> > > Ladislav Lhotka, CZ.NIC Labs
> > > PGP Key ID: E74E8C0C
> > >
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/net= mod
> > >
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >
> >
> >
> >
> >
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C

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





--001a11c2640edc1a1b051cf86cc3-- From nobody Mon Aug 10 12:35:03 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 672201B2EAD for ; Mon, 10 Aug 2015 12:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.31 X-Spam-Level: X-Spam-Status: No, score=-13.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_34=0.6, 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 ihs54lTASwpy for ; Mon, 10 Aug 2015 12:34:58 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D2101B3CC3 for ; Mon, 10 Aug 2015 12:34:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=41673; q=dns/txt; s=iport; t=1439235286; x=1440444886; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=xacKvfOWoLBaiUDt0nQi8ihjWyjfPOr7yQhspHNj8PQ=; b=aCDacaNpHDCwGi1NYxGDSsfi/3lz9dC1dHPiCWy47A+MQd0ljUoQYmYd 7N3cYBdqmKA5+oIcWJFkLB2+Oe4AqHasG4e7f4jfcIOKD+Z3+ZSOEEvmS D2BT2sqnCkrE+IRpn+FZhlX9ouT7494Yjux8bcdezcWy9U1wPJXGRp3ei Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DmCwD3+8hV/5pdJa1dgk5NVGkGgx6qKY9CM4FiGQEJhS9KAhyBGzoSAQEBAQEBAYEKhCMBAQEDAQEBARcJSwQHBQcEAgEIEAEDAQEBARULBwMCAgIlCxQJCAIEAQ0FGQKICwgNuTOWHAEBAQEBAQEBAQEBAQEBAQEBAQEBAReKToEDhD4wCg0EBwYEgl+BQwWMVAGINgGFAYJphHiBSUaGdo0Sg2YRFYIPHIFTcQGBR4EEAQEB X-IronPort-AV: E=Sophos;i="5.15,647,1432598400"; d="scan'208,217";a="177307819" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-5.cisco.com with ESMTP; 10 Aug 2015 19:34:44 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t7AJYhti024723 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 10 Aug 2015 19:34:43 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 10 Aug 2015 14:34:42 -0500 Received: from xhc-rcd-x06.cisco.com (173.37.183.80) by xch-aln-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Mon, 10 Aug 2015 14:34:42 -0500 Received: from xmb-aln-x06.cisco.com ([169.254.1.223]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0248.002; Mon, 10 Aug 2015 14:34:40 -0500 From: "Acee Lindem (acee)" To: "Einar Nilsen-Nygaard (einarnn)" , Jonathan Hansford Thread-Topic: [netmod] Y34 - root node Thread-Index: AQHQzfwQxnbl1H5mqEiCxAjpxb0TL536tNgA//+74pCAAFbtgIAAz0+UgADCtACABfPJgIAC/IuAgAAMEQCAAGXrgA== Date: Mon, 10 Aug 2015 19:34:38 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.36.7.28] Content-Type: multipart/alternative; boundary="_000_D1EE72752AA99aceeciscocom_" MIME-Version: 1.0 Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Y34 - root node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 19:35:02 -0000 --_000_D1EE72752AA99aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB0aGVyZSBpcyBhZ3JlZW1lbnQgdGhhdCB0aGVyZSBpcyBhIHByb2JsZW0uIFRoZSBZ QU5HIFJvdXRpbmcgRGVzaWduIFRlYW0gaXMgIGFkZHJlc3NpbmcgdGhpcyB3aXRoIGh0dHBzOi8v d3d3LmlldGYub3JnL2lkL2RyYWZ0LXJ0Z3lhbmdkdC1ydGd3Zy1kZXZpY2UtbW9kZWwtMDAudHh0 ICAod2hpY2ggaGFzIGV2b2x2ZWQgZnJvbSBodHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1v cGVuY29uZmlnLW5ldG1vZC1tb2RlbC1zdHJ1Y3R1cmUtMDAudHh0KS4gSW4gZXNzZW5jZSwgYSBw bGFjZSBmb3IgZXZlcnl0aGluZyBhbmQgZXZlcnl0aGluZyBpbiBpdHMgcGxhY2UuIEhvd2V2ZXIs IHRoZXJlIGFyZSB0aG9zZSB3aG8gZmVlbCB0aGF0IGNhbuKAmXQgbWFuZGF0ZSBhIHNpbmdsZSBt b2RlbCBzdHJ1Y3R1cmUgZm9yIG5ldHdvcmsgZGV2aWNlcyBhbmQgd2UgbmVlZCBtZWNoYW5pc21z IHRvIG1hbmFnZSBtdWx0aXBsZSBtb2RlbHMgYnV0IGFsbG93IGZvciBkaWZmZXJlbnQgZGV2aWNl IHN0cnVjdHVyZSAoZS5nLiwgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtYmllcm1hbi1u ZXRtb2QteWFuZy1wYWNrYWdlLTAwLnR4dCkuICBJIGhvcGUgd2UgY2FuIGFncmVlIG9uIGFuIGFw cHJvYWNoIGluIHRoZSBjb21pbmcgaW50ZXJpbSBtZWV0aW5ncy4NCg0KVGhhbmtzLA0KQWNlZQ0K DQoNCg0KRnJvbTogbmV0bW9kIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bmV0bW9k LWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgIkVpbmFyIE5pbHNlbi1OeWdhYXJkIChl aW5hcm5uKSIgPGVpbmFybm5AY2lzY28uY29tPG1haWx0bzplaW5hcm5uQGNpc2NvLmNvbT4+DQpE YXRlOiBNb25kYXksIEF1Z3VzdCAxMCwgMjAxNSBhdCA1OjI5IEFNDQpUbzogSm9uYXRoYW4gSGFu c2ZvcmQgPGpvbmF0aGFuQGhhbnNmb3Jkcy5uZXQ8bWFpbHRvOmpvbmF0aGFuQGhhbnNmb3Jkcy5u ZXQ+Pg0KQ2M6IE5FVE1PRCBXb3JraW5nIEdyb3VwIDxuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5l dG1vZEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW25ldG1vZF0gWTM0IC0gcm9vdCBub2RlDQoN CkFzIHNvbWVvbmUgc2hhcmluZyByZXNwb25zaWJpbGl0aWVzIGZvciBndWlkaW5nIGEgbnVtYmVy IG9mIGRldmVsb3BtZW50IHRlYW1zIGJvdGggZGVmaW5pbmcgbmV3IG1vZGVscyBhbmQgaW1wbGVt ZW50aW5nIHRvIHNvbWUgYWxyZWFkeSBkZWZpbmVkIG1vZGVscyBpbiB0aGlzIGFyZWEsIEkgY2Fu IG9ubHkgYWdyZWUgd2l0aCB0aGlzIGFkZGl0aW9uIHRvIHdoYXQgSSBzYWlkIGVhcmxpZXIuDQoN CkNoZWVycywNCg0KRWluYXINCg0KT24gQXVnIDEwLCAyMDE1LCBhdCA5OjQ2IEFNLCBKb25hdGhh biBIYW5zZm9yZCA8am9uYXRoYW5AaGFuc2ZvcmRzLm5ldDxtYWlsdG86am9uYXRoYW5AaGFuc2Zv cmRzLm5ldD4+IHdyb3RlOg0KDQogQW5kIGl0IGlzIG5vdCBqdXN0IGVuZCB1c2VycyB3aG8gbmVl ZCBoZWxwIHRvIGJldHRlciB1bmRlcnN0YW5kIFlBTkcgbW9kZWxzIGFuZCBob3cgdG8gdXNlIHRo ZW0uIEZvciB0aG9zZSBzdGlsbCBvbiB0aGUgZWRnZSwgbG9va2luZyB0byBmaW5hbGx5IHRha2Ug dGhlIHBsdW5nZSBhbmQgdXNlIE5FVENPTkYvWUFORyB0byBjb25maWd1cmUgdGhlaXIgZGV2aWNl cywgaGVscCBpcyBhbHNvIHJlcXVpcmVkIHRvIGRldGVybWluZSBob3cgYmVzdCB0byBzdHJ1Y3R1 cmUgdGhlaXIgWUFORyBtb2RlbHMsIG1ha2UgdXNlIG9mIHRoZSBleGlzdGluZyBvbmVzLCBldGMu IEZvciB0aG9zZSB3aG8gaGF2ZSAiZ3Jvd24gdXAiIHdpdGggdGhlIGRldmVsb3BtZW50cyBpbiBO RVRDT05GIGFuZCBZQU5HLCBtdWNoIG9mIHRoaXMgaXMgcHJvYmFibHkgc2Vjb25kIG5hdHVyZS4g QnV0IGNvbWluZyB0byBpdCBjb2xkIChpbiB0aGUgc2Vuc2Ugb2YgY29tcGlsaW5nL3dyaXRpbmcg YSBmaXJzdCBzZXQgb2YgWUFORyBtb2RlbHMgZm9yIGEgZGV2aWNlOyBJJ3ZlIGJlZW4gZm9sbG93 aW5nIHRoZSBuZXRjb25mL25ldG1vZCBXR3MgZm9yIDMrIHllYXJzKSwgaXQgc3RpbGwgZmVlbHMg dmVyeSBtdWNoIGxpa2UgYSBkYXJrIGFydCEgSXQgaXMgbm90IGp1c3QgdGhlIGluZGl2aWR1YWwg bW9kdWxlcywgaXQgaXMgaG93IHRvIHB1dCB0aGVtIHRvZ2V0aGVyIHRvIGJlc3QgbWFuYWdlIGEg ZGV2aWNlIChsZXQgYWxvbmUgYSBzeXN0ZW0pLg0KDQpKb25hdGhhbg0KDQoNCg0KLS0tLS0gT3Jp Z2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbToNCiJFaW5hciBOaWxzZW4tTnlnYWFyZCAoZWluYXJu bikiIDxlaW5hcm5uQGNpc2NvLmNvbTxtYWlsdG86ZWluYXJubkBjaXNjby5jb20+Pg0KDQpUbzoN CiJBbmR5IEJpZXJtYW4iIDxhbmR5QHl1bWF3b3Jrcy5jb208bWFpbHRvOmFuZHlAeXVtYXdvcmtz LmNvbT4+DQpDYzoNCiJORVRNT0QgV29ya2luZyBHcm91cCIgPG5ldG1vZEBpZXRmLm9yZzxtYWls dG86bmV0bW9kQGlldGYub3JnPj4NClNlbnQ6DQpTYXQsIDggQXVnIDIwMTUgMTE6MTA6MTUgKzAw MDANClN1YmplY3Q6DQpSZTogW25ldG1vZF0gWTM0IC0gcm9vdCBub2RlDQoNCg0KQW5keSwNCg0K SSBhZ3JlZSB0aGF0IHRoZXJlIGlzIGEgbmVlZCBmb3Igb3JnYW5pemF0aW9uIG9mIG1vZGVscywg YnV0IEkgZG9u4oCZdCBoYXZlIGEgZmlybSBwb3NpdGlvbiBvbiBkcmFmdC1vcGVuY29uZmlnLW5l dG1vZC1tb2RlbC1zdHJ1Y3R1cmUvZHJhZnQtcnRneWFuZ2R0LXJ0Z3dnLWRldmljZS1tb2RlbCBv ciBkcmFmdC1iaWVybWFuLW5ldG1vZC15YW5nLXBhY2thZ2UuIEJ1dCB3ZSBhYnNvbHV0ZWx5IG5l ZWQgKnNvbWV0aGluZyogdG8gaGVscCBlbmQtdXNlcnMgb2YgdGhlIG1vZGVscyBjb21wcmVoZW5k IHRoZSBvdmVyYWxsIHN0cnVjdHVyZSBvZiBtb2RlbHMsIHRoZWlyIHJlbGF0aW9uc2hpcCBhbmQg aG93IHRvIHVzZSB0aGVtLg0KDQpDaGVlcnMsDQoNCkVpbmFyDQoNCk9uIEF1ZyA0LCAyMDE1LCBh dCA1OjE2IFBNLCBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbTxtYWlsdG86YW5keUB5 dW1hd29ya3MuY29tPj4gd3JvdGU6DQoNCg0KDQpPbiBUdWUsIEF1ZyA0LCAyMDE1IGF0IDI6MzQg QU0sIHQucGV0Y2ggPGlldGZjQGJ0Y29ubmVjdC5jb208bWFpbHRvOmlldGZjQGJ0Y29ubmVjdC5j b20+PiB3cm90ZToNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206ICJBbmR5IEJp ZXJtYW4iIDxhbmR5QHl1bWF3b3Jrcy5jb208bWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbT4+DQpU bzogInQucGV0Y2giIDxpZXRmY0BidGNvbm5lY3QuY29tPG1haWx0bzppZXRmY0BidGNvbm5lY3Qu Y29tPj4NClNlbnQ6IE1vbmRheSwgQXVndXN0IDAzLCAyMDE1IDU6MTcgUE0NCg0KPiAtLS0tLSBP cmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+IEZyb206ICJBbmR5IEJpZXJtYW4iIDxhbmR5QHl1bWF3 b3Jrc2NvbTxtYWlsdG86YW5keUB5dW1hd29ya3MuY29tPj4NCj4gVG86ICJ0LnBldGNoIiA8aWV0 ZmNAYnRjb25uZWN0LmNvbTxtYWlsdG86aWV0ZmNAYnRjb25uZWN0LmNvbT4+DQo+IFNlbnQ6IE1v bmRheSwgQXVndXN0IDAzLCAyMDE1IDQ6MTAgUE0NCj4NCj4gPiAtLS0tLSBPcmlnaW5hbCBNZXNz YWdlIC0tLS0tDQo+ID4gRnJvbTogIkFuZHkgQmllcm1hbiIgYW5keUB5dW1hd29ya3MuY29tPG1h aWx0bzphbmR5QHl1bWF3b3Jrcy5jb20+DQo+ID4gU2VudDogU2F0dXJkYXksIEF1Z3VzdCAwMSwg MjAxNSA3OjA1IFBNDQo+ID4gT24gU2F0LCBBdWcgMSwgMjAxNSBhdCA5OjUxIEFNLCBBY2VlIExp bmRlbSAoYWNlZSkgPGFjZWVAY2lzY28uY29tPG1haWx0bzphY2VlQGNpc2NvLmNvbT4+DQo+ID4N Cj4+PiBPbiA4LzEvMTUsIDI6NTEgQU0sICBqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNp dHkuZGU8bWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4+IHdyb3Rl Og0KPj4+DQo+Pj4gU2VjdGlvbiAxLjEgaW4NCj4+Pg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9p ZC9kcmFmdC1vcGVuY29uZmlnLW5ldG1vZC1tb2RlbC1zdHJ1Y3R1cmUtMDAudHh0DQo+Pj4gbGlz dHMgdGhlIGdvYWxzIG9mIGEgZ2VuZXJpYyBtb2RlbCBzdHJ1Y3R1cmUgdGhhdCB3aWxsIGFjY29t bW9kYXRlDQo+PiBtb3N0DQo+Pj4gbW9kZXJuIG5ldHdvcmsgZGV2aWNlcy4gSSBndWVzcyB5b3Ug ZG9u4oCZdCBhZ3JlZSB0aGF0IHRoZXNlIGFyZQ0KPj4gZGVzaXJhYmxlPw0KPiA+DQo+ID4gVGhl IG9ubHkgb2JqZWN0aW9uIEkgaGF2ZSB0byB0aGlzIGRyYWZ0IGlzIHRoZSBpbnNlcnRpb24gb2Yg YQ0KdG9wLWxldmVsDQo+ID4gcm9vdA0KPiA+IGNhbGxlZCAiZGV2aWNlIi4gIChNaWdodCBhcyB3 ZWxsIGJlIGNhbGxlZCAic2VsZiIpLg0KPiA+IFRoZXJlIGFyZSBubyBzaWJsaW5nIG5vZGVzIHBs YW5uZWQgb3IgaW50ZW5kZWQgZm9yDQo+ID4gdGhpcyBub2RlLCBzbyBpdCBzZXJ2ZXMgYXMgYW4g ZXh0cmEgZG9jdW1lbnQgcm9vdC4NCj4gPg0KPiA+IDx0cD4NCj4gPiBPbmUgYXNwZWN0IG9mIFlB TkcgSSBoYXZlIG5ldmVyIGdyYXNwZWQgaXMgd2hhdCBhIHJvb3QgbWVhbnMsIGlmDQo+ID4gYW55 dGhpbmcuDQo+ID4NCj4gPiBJIHVuZGVyc3RhbmQgdGhhdCBpdCBpcyBuZWVkZWQgZm9yIE5FVENP TkYgKGZpbHRlcnMpIGFuZCBmb3IgWUFORw0KPiA+IChhdWdtZW50cywgY29uc3RyYWludHMpIGFu ZCBzbyBtdXN0IGJlIHNvbWV3aGVyZSBhbmQgbXVzdCBiZQ0KPiByZWxhdGl2ZWx5DQo+ID4gc3Rh YmxlLCBidXQgaGFzIGl0IGFueSBvdGhlciBzaWduaWZpY2FuY2UgaW4gdGhlIGRhdGEgbW9kZWw/ DQo+ID4NCj4gPiBBcyB5b3UgbWF5IHJlY2FsbCwgSSB3YXMgaW52b2x2ZWQgd2l0aCBTTUkgZmly c3QsIHdoZXJlIHRoZSByb290IGlzDQo+ID4gc29tZXdoZXJlIHVwIGluIHRoZSBza3kgYW5kIGxp ZmUgb25seSBiZWNvbWVzIGludGVyZXN0aW5nIHNvbWUgc2l4DQo+ID4gbGV2ZWxzIGRvd24gdGhl IGhpZXJhcmNoeSBhbmQgdGhhdCBtYXkgY29sb3VyIG15IHRoaW5raW5nLg0KPiA+DQo+DQo+IFlB TkcgZG9lcyBhIHBvb3Igam9iIG9mIGRlZmluaW5nIHRoZSByb290IGZvciBZQU5HIGRhdGEgbm9k ZXMuDQo+IEl0IGlzIHNvbWV0aW1lcyBjYWxsZWQgYSBkYXRhc3RvcmUgKGluIHRoZSBhYnN0cmFj dCkuDQo+IFRlY2huaWNhbGx5LCBZQU5HIGJvcnJvd3MgdGhlIGRlZmluaXRpb24gZnJvbSBYUGF0 aC4NCj4gWUFORyBqdXN0IGRlZmluZXMgdG9wLWxldmVsIGRhdGEgbm9kZXMgYW5kIHRoZSBwYXJl bnQgb2YNCj4gdGhlc2Ugbm9kZXMgaXMgdGhlIGRvY3VtZW50IHJvb3QNCj4NCj4gVGhlcmUgaXMg bm8gcHJvdG9jb2wgb3IgZW5jb2RpbmcgbmV1dHJhbCBkZWZpbml0aW9uLA0KPiBvbmx5IGFuIFhN TC1zcGVjaWZpYyBkZWZpbml0aW9uLg0KPg0KPiA8dHA+DQo+DQo+IFRoYW5rcyBmb3IgdGhhdC4N Cj4NCj4gSXQgc2VlbXMgdG8gbWUgdGhhdCBtdWNoIG9mIHRoZSBleHRlbnNpdmUgZGlzY3Vzc2lv biBvbiBZMzQgKGFsbCBvZg0KPiB3aGljaCBJIGhhdmUgcmVhZCkgaXMgYXMgbXVjaCBwb2xpdGlj YWwgYXMgdGVjaG5pY2FsLCB0aGF0IGlzIFNNSSBpcw0KPiBoaWVyYXJjaGljYWwsIHRvcCBkb3du LCBwZXJoYXBzIGJlZml0dGluZyBpdHMgb3JpZ2lucyBpbiBJU08sIHdoZXJlYXMNCj4gWUFORyBp cyBib3R0b20gdXAuIElFVEYtbGlrZS4gIFlBTkcgY291bGQgaGF2ZSBoYWQgYSBzaW5nbGUgdHJl ZSwgYnV0DQo+IGRvZXNuJ3QuICBTbyB3aGVuIEkgcmVhZA0KPg0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9pZC9kcmFmdC1vcGVuY29uZmlnLW5ldG1vZC1tb2RlbC1zdHJ1Y3R1cmUtMDAudHh0DQo+ DQo+IEkgc2VlIGEgcGxlYSBmb3IgYSBtb3JlIGhpZXJhcmNoaWNhbCBvcmdhbmlzYXRpb24sIGFu ZCB3aGVuIEkgcmVhZA0KPg0KPiBkcmFmdC1iam9ya2x1bmQtbmV0bW9kLW9wZW5jb25maWctcmVw bHktMDANCj4NCj4gSSBzZWUgYSByZXNwb25zZSB0aGF0IHNheXMgd2UgYXJlIG5vdCBsaWtlIHRo YXQuDQo+DQo+IElmIHNvLCBJIGRvdWJ0IHRoYXQgdGhlcmUgZXZlciB3aWxsIGJlIGEgdGVjaG5p Y2FsIHNvbHV0aW9uLg0KPg0KPiBBbmQgSSBhbSBtaW5kZnVsIHRoYXQgd2hlbiBJIGNvbmZpZ3Vy ZSByb3V0aW5nIGluIGEgKENpc2NvKSByb3V0ZXIsIEkNCj4gaGF2ZSB0byBkbyBzb21lIG9mIGl0 IHVuZGVyIHRoZSBpbnRlcmZhY2UgZGVmaW5pdGlvbnMgYW5kIHNvbWUgb2YgaXQNCj4gdW5kZXIg dGhlIGRlZmluaXRpb24gb2YgdGhlIHJvdXRpbmcgcHJvdG9jb2wuICBXaGljaCBpcyBsaWZlLCBu ZXZlcg0KPiB3aG9seSBpbnRlcmZhY2UtY2VudHJpYyBhbmQgbmV2ZXIgd2hvbHkgcm91dGluZyBw cm90b2NvbC1jZW50cmljIQ0KDQpBcmUgeW91IHNheWluZyB0aGUgam9iIHdvdWxkIGJlIGVhc2ll ciBpZiB0aGUNCnBhdGggd2FzIC9kZXZpY2UvaW50ZXJmYWNlcy9pbnRlcmZhY2UgaW5zdGVhZA0K b2YganVzdCAvaW50ZXJmYWNlcy9pbnRlcmZhY2U/ICBBcmUgeW91IHNheWluZw0KdGhhdCAvcHJv dG9jb2xzL3JvdXRpbmcgY291bGQgbm90IGFsc28gYmUgZGVmaW5lZD8NCkNsZWFybHkgZWRpdC1j b25maWcgYW5kIGNvcHktY29uZmlnIGFsbG93IGJvdGgNCnN1YnRyZWVzIHRvIGJlIGFjY2Vzc2Vk IGluIHRoZSBzYW1lIG9wZXJhdGlvbiwNCnNvIEkgZG9uJ3QgdW5kZXJzdGFuZCB5b3VyIGNvbmNl cm4uDQoNCkkgaGF2ZSBiZWVuIHRyeWluZyB0byBnZXQgdGhlIHJvb3Qgbm9kZSB0byBiZSBiZXR0 ZXIgZGVmaW5lZA0KaW4gdGhlIHByb3RvY29scyB0aGF0IHVzZSBZQU5HIChpLmUuLCBuY3g6cm9v dCwgWTM0LTA0KS4NCklNTyB0aGlzIGlzIGEgYmV0dGVyIGFwcHJvYWNoIHRoYW4gZGVmaW5pbmcg YSBZQU5HIG1vZHVsZQ0Kd2l0aCBhIHNwZWNpYWwgY29udGFpbmVyIHRoYXQgYWxsIG90aGVyIG1v ZHVsZXMgYXJlIGV4cGVjdGVkDQp0byBhdWdtZW50LiAgWUFORyBpcyBkZXNpZ25lZCBzdWNoIHRo YXQgZWFjaCB2ZW5kb3Igb3IgU0RPDQppcyBub3QgZGVwZW5kZW50IG9uIG90aGVyIHZlbmRvcnMg b3IgU0RPcyBpbiBvcmRlciB0bw0KZGVmaW5lIGRhdGEgbm9kZXMuDQoNCjx0cD4NCg0KQW5keQ0K DQpJIGFtIGFncmVlaW5nIHdpdGggeW91IHRoYXQgYWRkaW5nICdkZXZpY2UnIGJyaW5ncyBubyB0 ZWNobmljYWwgYmVuZWZpdCwNCnJhdGhlciB0aGF0IHRoZSBtb3RpdmF0aW9uIGlzIHRoZSBvcHBv c2l0ZSBvZiB0ZWNobmljYWwgKHdoaWNoIEkNCnJlZmVycmVkIHRvIGFzIHBvbGl0aWNhbCkuIEkg YW0gYWxzbyBhZ3JlZWluZyB3aXRoIHRoZSBjdXJyZW50IGRlY2xhcmVkDQpjb25zZW5zdXMgb24g WTM0Lg0KDQpBbmQgeWVzLCBZQU5HIGlzIGdvaW5nIHRvIGdpdmUgdXMgYSBsYXJnZSBudW1iZXIg b2YgbW9kdWxlcywgc29tZQ0KdGlnaHRseSBjb3VwbGVkIChhdWdtZW50cykgc29tZSBsb29zZWx5 IHNvIChob3cgbWFueSBkbyB5b3UgbmVlZCB0bw0KY29uZmlndXJlIE9TUEY/KSBhbmQgd29yayBp biB0aGlzIGFyZWEgd2lsbCBiZSBvZiBiZW5lZml0IG5vdyBhbmQNCnByb2JhYmx5IGVzc2VudGlh bCBpbiBhIGZldyB5ZWFycyB0aW1lLiAgVGhhdCBzYWlkLCBJIGFtIHVuc3VyZSB3aGF0DQpzdWNo IHdvcmsgd291bGQgYmUgbGlrZTsgSSBhbSBsb29raW5nIChpbiBkZXNwYWlyKSBhdCA1MCByb3V0 aW5nIGFyZWENCllBTkcgbW9kZWxzIGFuZCB3b25kZXJpbmcgaG93IGEgdXNlciB3aWxsIGV2ZXIg Z2V0IGEgY29oZXJlbnQgcGljdHVyZSBvZg0KaG93IHRvIGRvIHdoYXQgdGhleSB3YW50IHRvIGRv Lg0KDQoNCg0KVGhlICJZQU5HIExhbmQgR3JhYiIgZ2l2ZXMgYSBmYWxzZSBzZW5zZSBvZiBwcm9n cmVzcy4NClJlYWNoaW5nIFdHIGNvbnNlbnN1cyBvbiBldmVyeSBzaW5nbGUgbGVhZiBpcyBoYXJk IHdvcmsuDQoNCkkgZG9uJ3QgdGhpbmsgYSBjb2xsZWN0aW9uIG9mIDEwMHMgb2YgWUFORyBtb2R1 bGVzIGlzIGV2ZXINCmdvaW5nIHRvIHRvIGJlIGVhc3kgdG8gdW5kZXJzdGFuZC4gIE9wZXJhdG9y cyB3aWxsIG5vdCBleGFtaW5lDQphIE5FVENPTkYgPGhlbGxvPiBtZXNzYWdlLCBsb29rIGF0IDE1 MCBtb2R1bGUgVVJJcywNCmFuZCBzYXkgIkkga25vdyBleGFjdGx5IHdoYXQgdGhpcyBkZXZpY2Ug c3VwcG9ydHMiLg0KSSBndWVzcyBpdCBpcyB1cCB0byBjbGllbnQgdG9vbHMgdG8gZG8gdGhhdA0K DQpJIHdyb3RlIGEgZHJhZnQgdGhhdCBkZWZpbmVzIFlBTkcgUGFja2FnZXMsIHdoaWNoIGNhbiBw cm92aWRlDQphIGhpZ2hlciBsZXZlbCBvZiBvcmdhbml6YXRpb24gZm9yIFlBTkcgbW9kdWxlcy4N Cg0KaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1iaWVybWFuLW5ldG1vZC15 YW5nLXBhY2thZ2UvDQoNCllvdSBhbmQgSSBhcmUgYXBwYXJlbnRseSBpbiB0aGUgbWlub3JpdHks IHNpbmNlIHRoZSBvZmZpY2lhbCBzdGF0dXMNCmlzIHRoYXQgdGhlcmUgaXMgbm8gcHJvYmxlbSB3 aXRoIHRoZSBjdXJyZW50IGFwcHJvYWNoLCBhbmQgbm8gbmVlZA0KdG8gb3JnYW5pemUgaW5kaXZp ZHVhbCBZQU5HIG1vZHVsZXMgaW50byBhbnkgbGFyZ2VyIGFic3RyYWN0aW9ucy4NCg0KDQoNCiBU b20gUGV0Y2gNCg0KDQoNCkFuZHkNCg0KQW5keQ0KDQo+IEFuZHkNCj4NCj4gPiBUaGUgd2VsbC1z cGVjaWZpZWQgWFBhdGggYW5kIFlBTkcgcm9vdCAoLykgY2FuIGJlDQo+ID4gYWNjZXNzZWQgYnkg YWxsIHByb3RvY29sIG9wZXJhdGlvbnMsIGV4YWN0bHkgdGhlIHNhbWUNCj4gPiBhcyBhIG5vZGUg Y2FsbGVkICdkZXZpY2UnLiAgVGhlIGFjdHVhbCBub2RlIG5hbWUgd2lsbA0KPiA+IGRlcGVuZCBv biB0aGUgUlBDIGZ1bmN0aW9uIChlLmcuICdkYXRhJyBvciAnY29uZmlnJykuDQo+ID4NCj4gPiBU aGlzIGlzIG1vcmUgdGhhbiByZWR1bmRhbnQgaG93ZXZlci4gIEl0IGludHJvZHVjZXMgYSAic3Vw ZXItbW9kdWxlIg0KPiA+IGludG8gWUFORyB0aGF0IGV2ZXJ5IG90aGVyIG1vZHVsZSBpcyBleHBl Y3RlZCB0byBhdWdtZW50Lg0KPiA+IFlBTkcgaXMgaW50ZW5kZWQgdG8gYmUgbW9yZSBsb29zZWx5 IGNvdXBsZWQgdGhhbiB0aGF0Lg0KPiA+IFRoaXMgaW50cm9kdWNlcyBhbiBleHRyYSBub2RlIGFu ZCBuYW1lc3BhY2UgZGVjbGFyYXRpb24NCj4gPiBpbiBhbGwgcHJvdG9jb2wgbWVzc2FnZXMsIGlu Y3JlYXNpbmcgbWVzc2FnZSBzaXplcy4NCj4gPg0KPiA+IEl0IGFsc28gYXNzdW1lcyBhbGwgZXhp c3RpbmcgWUFORyBtb2RlbHMgd2lsbCBnZXQgcmV3cml0dGVuIHRvDQo+ID4gYWNjb3VudCBmb3Ig Ii9kZXZpY2UiIGluIGFsbCBwYXRoIGFuZCBYUGF0aCBleHByZXNzaW9ucy4NCj4gPiBUaGlzIGlz IGhpZ2hseSBkaXNydXB0aXZlIHRvIGV4aXN0aW5nIGRlcGxveW1lbnRzLg0KPiA+IEFsc28sIG11 bHRpcGxlIGRhdGEgbW9kZWxzIHRvIGVkaXQgdGhlIHNhbWUgdGhpbmcgY2F1c2VzIGxvdHMNCj4g PiBvZiBleHRyYSBjb21wbGV4aXR5IGluIHRoZSBzZXJ2ZXIgKHN1cHBvcnRpbmcgYm90aCBvbGQN Cj4gPiBsb2NhdGlvbiBhbmQgbmV3IGxvY2F0aW9uKS4NCj4gPg0KPiA+IElNTyBhIHJlc291cmNl IGRpcmVjdG9yeSBhcHByb2FjaCBpcyBtdWNoIG1vcmUgcmVhbGlzdGljLg0KPiA+IFRoZSAvZGV2 aWNlIHRyZWUgY2FuIGNvbnRhaW4gYWxsIHRoZSBvcmdhbml6ZWQgTlAgY29udGFpbmVycy4NCj4g PiBJbnN0ZWFkIG9mIGFsbCB0aGUgYWN0dWFsIGRhdGEgbm9kZXMsIHRoaXMgdHJlZSBqdXN0IGhh cyBwb2ludGVycw0KPiA+IHRvIHRoZSByZWFsIGxvY2F0aW9uIG9mIHRoZSByZXNvdXJjZS4gKGxp a2UgMzAxIE1vdmVkIFBlcm1hbmVudGx5KQ0KPiA+DQo+ID4gPiBBY2VlDQo+ID4gPg0KPiA+IEFu ZHkNCg0KDQoqKiBTb2x1dGlvbiBZMzQtMDINCg0KICBLZWVwICdhbnl4bWwnLiAgSW50cm9kdWNl ICdhbnlkYXRhJyBhcyBhYm92ZSBidXQgd2l0aG91dCB0aGUNCiAgJ2Zvcm1hdCcgc3Vic3RhdGVt ZW50Lg0KDQogICdhbnl4bWwnIHdvdWxkIHN0aWxsIGJlIHVzZWQgdG8gcmVwcmVzZW50IHVucmVz dHJpY3RlZCBYTUwsIGFzIGlzDQogIGRvbmUgaW4gTkVUQ09ORi4NCg0KICAnYW55ZGF0YScgd291 bGQgYmUgYW4gdW5rbm93biBjaHVuayBvZiBkYXRhIHRoYXQgY2FuIGJlIG1vZGVsbGVkDQogIHdp dGggWUFORy4gIENhbiBiZSBlbmNvZGVkIGFzIHhtbCBvciBqc29uLg0KDQogIEZvciBleGFtcGxl Og0KDQogICAgIytCRUdJTl9FWEFNUExFDQogICAgYW55ZGF0YSBkYXRhOw0KICAgICMrRU5EX0VY QU1QTEUNCg0KKiogU29sdXRpb24gWTM0LTA1DQoNCiAgIFNhbWUgYXMgWTM0LTAyIHBsdXMgdHdv IGd1aWRlbGluZXMgYWRvcHRlZCBmcm9tIFkzNC0wNDoNCg0KICAgLSBLZWVwICdhbnl4bWwnIHVu Y2hhbmdlZCBhcyBpdCBpcyBkZWZpbmVkIGluIFlBTkcgMS4wLiBUaGlzDQogICAgIGVuc3VyZXMg YmFja3dhcmQgY29tcGF0aWJpbGl0eS4NCiAgIC0gSW50cm9kdWNlIGEgbmV3ICdhbnlkYXRhJyBz dGF0ZW1lbnQgdGhhdCByZXByZXNlbnRzIGFuIHVua25vd24NCiAgICAgY2h1bmsgb2YgZGF0YSB0 aGF0IGNhbiBiZSBtb2RlbGVkIHdpdGggWUFORw0KICAgLSBEb2N1bWVudCB0aGF0IGltcGxlbWVu dGF0aW9ucyBNQVkgaGF2ZSByZXN0cmljdGlvbnMgZm9yIGFueXhtbCBhbmQNCiAgICAgdGhhdCBh bnl4bWwgaXMgbm90IG5lY2Vzc2FyaWx5IGludGVyb3BlcmFibGU7IGRhdGEgbW9kZWwgd3JpdGVy cw0KICAgICBzaG91bGQgdXNlIGFueWRhdGEgd2hlbmV2ZXIgcG9zc2libGUuDQogICAtIFRoZSBn dWlkZWxpbmVzIGRvY3VtZW50IHNob3VsZCBzYXkgdGhhdCBZQU5HIERvY3RvcnMgd2lsbCByZXZp ZXcNCiAgICAgZWFjaCB1c2Ugb2YgYW55eG1sIGluIElFVEYgbW9kdWxlcyB3aGVuIFlBTkcgMS4x IGlzIGFkb3B0ZWQgdG8NCiAgICAgYXZvaWQgaXRzIHVzZSB3aGVuZXZlciBwb3NzaWJsZS4NCg0K DQo+DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cm5ldG1vZCBtYWlsaW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0KDQo= --_000_D1EE72752AA99aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5JIHRoaW5rIHRo ZXJlIGlzIGFncmVlbWVudCB0aGF0IHRoZXJlIGlzIGEgcHJvYmxlbS4gVGhlIFlBTkcgUm91dGlu ZyBEZXNpZ24gVGVhbSBpcyAmbmJzcDthZGRyZXNzaW5nIHRoaXMgd2l0aCBodHRwczovL3d3dy5p ZXRmLm9yZy9pZC9kcmFmdC1ydGd5YW5nZHQtcnRnd2ctZGV2aWNlLW1vZGVsLTAwLnR4dCAmbmJz cDsod2hpY2ggaGFzIGV2b2x2ZWQgZnJvbSZuYnNwO2h0dHBzOi8vd3d3LmlldGYub3JnL2lkL2Ry YWZ0LW9wZW5jb25maWctbmV0bW9kLW1vZGVsLXN0cnVjdHVyZS0wMC50eHQpLg0KIEluIGVzc2Vu Y2UsIGEgcGxhY2UgZm9yIGV2ZXJ5dGhpbmcgYW5kIGV2ZXJ5dGhpbmcgaW4gaXRzIHBsYWNlLiBI b3dldmVyLCB0aGVyZSBhcmUgdGhvc2Ugd2hvIGZlZWwgdGhhdCBjYW7igJl0IG1hbmRhdGUgYSBz aW5nbGUgbW9kZWwgc3RydWN0dXJlIGZvciBuZXR3b3JrIGRldmljZXMgYW5kIHdlIG5lZWQgbWVj aGFuaXNtcyB0byBtYW5hZ2UgbXVsdGlwbGUgbW9kZWxzIGJ1dCBhbGxvdyBmb3IgZGlmZmVyZW50 IGRldmljZSBzdHJ1Y3R1cmUgKGUuZy4sDQogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQt Ymllcm1hbi1uZXRtb2QteWFuZy1wYWNrYWdlLTAwLnR4dCkuICZuYnNwO0kgaG9wZSB3ZSBjYW4g YWdyZWUgb24gYW4gYXBwcm9hY2ggaW4gdGhlIGNvbWluZyBpbnRlcmltIG1lZXRpbmdzLiZuYnNw OzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhhbmtzLDwvZGl2Pg0KPGRpdj5BY2Vl ICZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0ZXh0LWFsaWduOmxlZnQ7 IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1l ZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElO Ry1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hU OiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWln aHQ6Ym9sZCI+RnJvbTogPC9zcGFuPm5ldG1vZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5ldG1vZC1i b3VuY2VzQGlldGYub3JnIj5uZXRtb2QtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFs ZiBvZiAmcXVvdDtFaW5hciBOaWxzZW4tTnlnYWFyZCAoZWluYXJubikmcXVvdDsgJmx0OzxhIGhy ZWY9Im1haWx0bzplaW5hcm5uQGNpc2NvLmNvbSI+ZWluYXJubkBjaXNjby5jb208L2E+Jmd0Ozxi cj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+TW9uZGF5LCBB dWd1c3QgMTAsIDIwMTUgYXQgNToyOSBBTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpi b2xkIj5UbzogPC9zcGFuPkpvbmF0aGFuIEhhbnNmb3JkICZsdDs8YSBocmVmPSJtYWlsdG86am9u YXRoYW5AaGFuc2ZvcmRzLm5ldCI+am9uYXRoYW5AaGFuc2ZvcmRzLm5ldDwvYT4mZ3Q7PGJyPg0K PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+TkVUTU9EIFdvcmtpbmcg R3JvdXAgJmx0OzxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9y ZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwv c3Bhbj5SZTogW25ldG1vZF0gWTM0IC0gcm9vdCBub2RlPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVP VEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7 IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13 b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXIt d2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkFzIHNvbWVvbmUgc2hhcmluZyByZXNwb25zaWJpbGl0 aWVzIGZvciBndWlkaW5nIGEgbnVtYmVyIG9mIGRldmVsb3BtZW50IHRlYW1zIGJvdGggZGVmaW5p bmcgbmV3IG1vZGVscyBhbmQgaW1wbGVtZW50aW5nIHRvIHNvbWUgYWxyZWFkeSBkZWZpbmVkIG1v ZGVscyBpbiB0aGlzIGFyZWEsIEkgY2FuIG9ubHkgYWdyZWUgd2l0aCB0aGlzIGFkZGl0aW9uIHRv IHdoYXQgSSBzYWlkIGVhcmxpZXIuDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj5DaGVlcnMsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5FaW5hcjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBBdWcgMTAsIDIwMTUs IGF0IDk6NDYgQU0sIEpvbmF0aGFuIEhhbnNmb3JkICZsdDs8YSBocmVmPSJtYWlsdG86am9uYXRo YW5AaGFuc2ZvcmRzLm5ldCIgY2xhc3M9IiI+am9uYXRoYW5AaGFuc2ZvcmRzLm5ldDwvYT4mZ3Q7 IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogJ0hlbHZldGljYSBOZXVlJyxI ZWx2ZXRpY2EsQXJpYWwsc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB4OyIgY2xhc3M9IiI+DQom bmJzcDtBbmQgaXQgaXMgbm90IGp1c3QgZW5kIHVzZXJzIHdobyBuZWVkIGhlbHAgdG8gYmV0dGVy IHVuZGVyc3RhbmQgWUFORyBtb2RlbHMgYW5kIGhvdyB0byB1c2UgdGhlbS4gRm9yIHRob3NlIHN0 aWxsIG9uIHRoZSBlZGdlLCBsb29raW5nIHRvIGZpbmFsbHkgdGFrZSB0aGUgcGx1bmdlIGFuZCB1 c2UgTkVUQ09ORi9ZQU5HIHRvIGNvbmZpZ3VyZSB0aGVpciBkZXZpY2VzLCBoZWxwIGlzIGFsc28g cmVxdWlyZWQgdG8gZGV0ZXJtaW5lIGhvdyBiZXN0IHRvDQogc3RydWN0dXJlIHRoZWlyIFlBTkcg bW9kZWxzLCBtYWtlIHVzZSBvZiB0aGUgZXhpc3Rpbmcgb25lcywgZXRjLiBGb3IgdGhvc2Ugd2hv IGhhdmUgJnF1b3Q7Z3Jvd24gdXAmcXVvdDsgd2l0aCB0aGUgZGV2ZWxvcG1lbnRzIGluIE5FVENP TkYgYW5kIFlBTkcsIG11Y2ggb2YgdGhpcyBpcyBwcm9iYWJseSBzZWNvbmQgbmF0dXJlLiBCdXQg Y29taW5nIHRvIGl0IGNvbGQgKGluIHRoZSBzZW5zZSBvZiBjb21waWxpbmcvd3JpdGluZyBhIGZp cnN0IHNldCBvZiBZQU5HIG1vZGVscw0KIGZvciBhIGRldmljZTsgSSd2ZSBiZWVuIGZvbGxvd2lu ZyB0aGUgbmV0Y29uZi9uZXRtb2QgV0dzIGZvciAzJiM0MzsgeWVhcnMpLCBpdCBzdGlsbCBmZWVs cyB2ZXJ5IG11Y2ggbGlrZSBhIGRhcmsgYXJ0ISBJdCBpcyBub3QganVzdCB0aGUgaW5kaXZpZHVh bCBtb2R1bGVzLCBpdCBpcyBob3cgdG8gcHV0IHRoZW0gdG9nZXRoZXIgdG8gYmVzdCBtYW5hZ2Ug YSBkZXZpY2UgKGxldCBhbG9uZSBhIHN5c3RlbSkuDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5Kb25hdGhhbjxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N Ci0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS08YnIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJ3 aWR0aDoxMDAlO2JhY2tncm91bmQ6cmdiKDIyOCwyMjgsMjI4KTsiIGNsYXNzPSIiPg0KPGRpdiBz dHlsZT0iZm9udC13ZWlnaHQ6Ym9sZDsiIGNsYXNzPSIiPkZyb206PC9kaXY+DQomcXVvdDtFaW5h ciBOaWxzZW4tTnlnYWFyZCAoZWluYXJubikmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzplaW5h cm5uQGNpc2NvLmNvbSIgY2xhc3M9IiI+ZWluYXJubkBjaXNjby5jb208L2E+Jmd0OzwvZGl2Pg0K PGJyIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZDsiIGNsYXNzPSIiPlRv OjwvZGl2Pg0KJnF1b3Q7QW5keSBCaWVybWFuJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YW5k eUB5dW1hd29ya3MuY29tIiBjbGFzcz0iIj5hbmR5QHl1bWF3b3Jrcy5jb208L2E+Jmd0OzxiciBj bGFzcz0iIj4NCjxkaXYgc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQ7IiBjbGFzcz0iIj5DYzo8L2Rp dj4NCiZxdW90O05FVE1PRCBXb3JraW5nIEdyb3VwJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86 bmV0bW9kQGlldGYub3JnIiBjbGFzcz0iIj5uZXRtb2RAaWV0Zi5vcmc8L2E+Jmd0OzxiciBjbGFz cz0iIj4NCjxkaXYgc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQ7IiBjbGFzcz0iIj5TZW50OjwvZGl2 Pg0KU2F0LCA4IEF1ZyAyMDE1IDExOjEwOjE1ICYjNDM7MDAwMDxiciBjbGFzcz0iIj4NCjxkaXYg c3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQ7IiBjbGFzcz0iIj5TdWJqZWN0OjwvZGl2Pg0KUmU6IFtu ZXRtb2RdIFkzNCAtIHJvb3Qgbm9kZTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCkFuZHksDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj5JIGFncmVlIHRoYXQgdGhlcmUgaXMgYSBuZWVkIGZvciBvcmdhbml6YXRpb24g b2YgbW9kZWxzLCBidXQgSSBkb27igJl0IGhhdmUgYSBmaXJtIHBvc2l0aW9uIG9uJm5ic3A7ZHJh ZnQtb3BlbmNvbmZpZy1uZXRtb2QtbW9kZWwtc3RydWN0dXJlL2RyYWZ0LXJ0Z3lhbmdkdC1ydGd3 Zy1kZXZpY2UtbW9kZWwgb3ImbmJzcDtkcmFmdC1iaWVybWFuLW5ldG1vZC15YW5nLXBhY2thZ2Uu IEJ1dCB3ZSBhYnNvbHV0ZWx5IG5lZWQgKnNvbWV0aGluZyogdG8NCiBoZWxwIGVuZC11c2VycyBv ZiB0aGUgbW9kZWxzIGNvbXByZWhlbmQgdGhlIG92ZXJhbGwgc3RydWN0dXJlIG9mIG1vZGVscywg dGhlaXIgcmVsYXRpb25zaGlwIGFuZCBob3cgdG8gdXNlIHRoZW0uPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5DaGVlcnMsPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5FaW5hcjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGJsb2Nr cXVvdGUgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIEF1ZyA0LCAyMDE1LCBhdCA1OjE2IFBN LCBBbmR5IEJpZXJtYW4gJmx0OzxhIGhyZWY9Im1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20iIGNs YXNzPSIiPmFuZHlAeXVtYXdvcmtzLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNz PSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0i bHRyIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJy IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIFR1ZSwgQXVnIDQsIDIwMTUg YXQgMjozNCBBTSwgdC5wZXRjaCA8c3BhbiBkaXI9Imx0ciIgY2xhc3M9IiI+DQombHQ7PGEgaHJl Zj0ibWFpbHRvOmlldGZjQGJ0Y29ubmVjdC5jb20iIGNsYXNzPSIiPmlldGZjQGJ0Y29ubmVjdC5j b208L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgY2xhc3M9 ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNj Y2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleDsiPg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0t LTxiciBjbGFzcz0iIj4NCkZyb206ICZxdW90O0FuZHkgQmllcm1hbiZxdW90OyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbSIgY2xhc3M9IiI+YW5keUB5dW1hd29ya3MuY29t PC9hPiZndDs8YnIgY2xhc3M9IiI+DQpUbzogJnF1b3Q7dC5wZXRjaCZxdW90OyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmlldGZjQGJ0Y29ubmVjdC5jb20iIGNsYXNzPSIiPmlldGZjQGJ0Y29ubmVjdC5j b208L2E+Jmd0OzxiciBjbGFzcz0iIj4NClNlbnQ6IE1vbmRheSwgQXVndXN0IDAzLCAyMDE1IDU6 MTcgUE08YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQomZ3Q7IC0tLS0tIE9yaWdpbmFsIE1l c3NhZ2UgLS0tLS08YnIgY2xhc3M9IiI+DQomZ3Q7IEZyb206ICZxdW90O0FuZHkgQmllcm1hbiZx dW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbSIgY2xhc3M9IiI+YW5k eUB5dW1hd29ya3Njb208L2E+Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsgVG86ICZxdW90O3QucGV0 Y2gmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzppZXRmY0BidGNvbm5lY3QuY29tIiBjbGFzcz0i Ij5pZXRmY0BidGNvbm5lY3QuY29tPC9hPiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7IFNlbnQ6IE1v bmRheSwgQXVndXN0IDAzLCAyMDE1IDQ6MTAgUE08YnIgY2xhc3M9IiI+DQomZ3Q7PGJyIGNsYXNz PSIiPg0KJmd0OyAmZ3Q7IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS08YnIgY2xhc3M9IiI+ DQomZ3Q7ICZndDsgRnJvbTogJnF1b3Q7QW5keSBCaWVybWFuJnF1b3Q7IDxhIGhyZWY9Im1haWx0 bzphbmR5QHl1bWF3b3Jrcy5jb20iIGNsYXNzPSIiPmFuZHlAeXVtYXdvcmtzLmNvbTwvYT48YnIg Y2xhc3M9IiI+DQomZ3Q7ICZndDsgU2VudDogU2F0dXJkYXksIEF1Z3VzdCAwMSwgMjAxNSA3OjA1 IFBNPGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7IE9uIFNhdCwgQXVnIDEsIDIwMTUgYXQgOTo1MSBB TSwgQWNlZSBMaW5kZW0gKGFjZWUpICZsdDs8YSBocmVmPSJtYWlsdG86YWNlZUBjaXNjby5jb20i IGNsYXNzPSIiPmFjZWVAY2lzY28uY29tPC9hPiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDs8 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDsgT24gOC8xLzE1LCAyOjUxIEFNLCZuYnNwOyA8YSBo cmVmPSJtYWlsdG86ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlIiBjbGFzcz0i Ij4NCmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZTwvYT4mZ3Q7IHdyb3RlOjxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyBTZWN0 aW9uIDEuMSBpbjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsg PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtb3BlbmNvbmZpZy1uZXRtb2Qt bW9kZWwtc3RydWN0dXJlLTAwLnR4dCIgY2xhc3M9IiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9p ZC9kcmFmdC1vcGVuY29uZmlnLW5ldG1vZC1tb2RlbC1zdHJ1Y3R1cmUtMDAudHh0PC9hPjxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyBsaXN0cyB0aGUgZ29hbHMgb2YgYSBnZW5lcmljIG1vZGVs IHN0cnVjdHVyZSB0aGF0IHdpbGwgYWNjb21tb2RhdGU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBt b3N0PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmZ3Q7IG1vZGVybiBuZXR3b3JrIGRldmljZXMuIEkg Z3Vlc3MgeW91IGRvbuKAmXQgYWdyZWUgdGhhdCB0aGVzZSBhcmU8YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyBkZXNpcmFibGU/PGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0 OyAmZ3Q7IFRoZSBvbmx5IG9iamVjdGlvbiBJIGhhdmUgdG8gdGhpcyBkcmFmdCBpcyB0aGUgaW5z ZXJ0aW9uIG9mIGE8YnIgY2xhc3M9IiI+DQp0b3AtbGV2ZWw8YnIgY2xhc3M9IiI+DQomZ3Q7ICZn dDsgcm9vdDxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyBjYWxsZWQgJnF1b3Q7ZGV2aWNlJnF1b3Q7 LiZuYnNwOyAoTWlnaHQgYXMgd2VsbCBiZSBjYWxsZWQgJnF1b3Q7c2VsZiZxdW90OykuPGJyIGNs YXNzPSIiPg0KJmd0OyAmZ3Q7IFRoZXJlIGFyZSBubyBzaWJsaW5nIG5vZGVzIHBsYW5uZWQgb3Ig aW50ZW5kZWQgZm9yPGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7IHRoaXMgbm9kZSwgc28gaXQgc2Vy dmVzIGFzIGFuIGV4dHJhIGRvY3VtZW50IHJvb3QuPGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7PGJy IGNsYXNzPSIiPg0KJmd0OyAmZ3Q7ICZsdDt0cCZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsg T25lIGFzcGVjdCBvZiBZQU5HIEkgaGF2ZSBuZXZlciBncmFzcGVkIGlzIHdoYXQgYSByb290IG1l YW5zLCBpZjxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyBhbnl0aGluZy48YnIgY2xhc3M9IiI+DQom Z3Q7ICZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgSSB1bmRlcnN0YW5kIHRoYXQgaXQgaXMg bmVlZGVkIGZvciBORVRDT05GIChmaWx0ZXJzKSBhbmQgZm9yIFlBTkc8YnIgY2xhc3M9IiI+DQom Z3Q7ICZndDsgKGF1Z21lbnRzLCBjb25zdHJhaW50cykgYW5kIHNvIG11c3QgYmUgc29tZXdoZXJl IGFuZCBtdXN0IGJlPGJyIGNsYXNzPSIiPg0KJmd0OyByZWxhdGl2ZWx5PGJyIGNsYXNzPSIiPg0K Jmd0OyAmZ3Q7IHN0YWJsZSwgYnV0IGhhcyBpdCBhbnkgb3RoZXIgc2lnbmlmaWNhbmNlIGluIHRo ZSBkYXRhIG1vZGVsPzxiciBjbGFzcz0iIj4NCiZndDsgJmd0OzxiciBjbGFzcz0iIj4NCiZndDsg Jmd0OyBBcyB5b3UgbWF5IHJlY2FsbCwgSSB3YXMgaW52b2x2ZWQgd2l0aCBTTUkgZmlyc3QsIHdo ZXJlIHRoZSByb290IGlzPGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7IHNvbWV3aGVyZSB1cCBpbiB0 aGUgc2t5IGFuZCBsaWZlIG9ubHkgYmVjb21lcyBpbnRlcmVzdGluZyBzb21lIHNpeDxiciBjbGFz cz0iIj4NCiZndDsgJmd0OyBsZXZlbHMgZG93biB0aGUgaGllcmFyY2h5IGFuZCB0aGF0IG1heSBj b2xvdXIgbXkgdGhpbmtpbmcuPGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7PGJyIGNsYXNzPSIiPg0K Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsgWUFORyBkb2VzIGEgcG9vciBqb2Igb2YgZGVmaW5pbmcg dGhlIHJvb3QgZm9yIFlBTkcgZGF0YSBub2Rlcy48YnIgY2xhc3M9IiI+DQomZ3Q7IEl0IGlzIHNv bWV0aW1lcyBjYWxsZWQgYSBkYXRhc3RvcmUgKGluIHRoZSBhYnN0cmFjdCkuPGJyIGNsYXNzPSIi Pg0KJmd0OyBUZWNobmljYWxseSwgWUFORyBib3Jyb3dzIHRoZSBkZWZpbml0aW9uIGZyb20gWFBh dGguPGJyIGNsYXNzPSIiPg0KJmd0OyBZQU5HIGp1c3QgZGVmaW5lcyB0b3AtbGV2ZWwgZGF0YSBu b2RlcyBhbmQgdGhlIHBhcmVudCBvZjxiciBjbGFzcz0iIj4NCiZndDsgdGhlc2Ugbm9kZXMgaXMg dGhlIGRvY3VtZW50IHJvb3Q8YnIgY2xhc3M9IiI+DQomZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyBU aGVyZSBpcyBubyBwcm90b2NvbCBvciBlbmNvZGluZyBuZXV0cmFsIGRlZmluaXRpb24sPGJyIGNs YXNzPSIiPg0KJmd0OyBvbmx5IGFuIFhNTC1zcGVjaWZpYyBkZWZpbml0aW9uLjxiciBjbGFzcz0i Ij4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7ICZsdDt0cCZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7 PGJyIGNsYXNzPSIiPg0KJmd0OyBUaGFua3MgZm9yIHRoYXQuPGJyIGNsYXNzPSIiPg0KJmd0Ozxi ciBjbGFzcz0iIj4NCiZndDsgSXQgc2VlbXMgdG8gbWUgdGhhdCBtdWNoIG9mIHRoZSBleHRlbnNp dmUgZGlzY3Vzc2lvbiBvbiBZMzQgKGFsbCBvZjxiciBjbGFzcz0iIj4NCiZndDsgd2hpY2ggSSBo YXZlIHJlYWQpIGlzIGFzIG11Y2ggcG9saXRpY2FsIGFzIHRlY2huaWNhbCwgdGhhdCBpcyBTTUkg aXM8YnIgY2xhc3M9IiI+DQomZ3Q7IGhpZXJhcmNoaWNhbCwgdG9wIGRvd24sIHBlcmhhcHMgYmVm aXR0aW5nIGl0cyBvcmlnaW5zIGluIElTTywgd2hlcmVhczxiciBjbGFzcz0iIj4NCiZndDsgWUFO RyBpcyBib3R0b20gdXAuIElFVEYtbGlrZS4mbmJzcDsgWUFORyBjb3VsZCBoYXZlIGhhZCBhIHNp bmdsZSB0cmVlLCBidXQ8YnIgY2xhc3M9IiI+DQomZ3Q7IGRvZXNuJ3QuJm5ic3A7IFNvIHdoZW4g SSByZWFkPGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4NCiZndDsgPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtb3BlbmNvbmZpZy1uZXRtb2QtbW9kZWwtc3RydWN0 dXJlLTAwLnR4dCIgY2xhc3M9IiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1vcGVu Y29uZmlnLW5ldG1vZC1tb2RlbC1zdHJ1Y3R1cmUtMDAudHh0PC9hPjxiciBjbGFzcz0iIj4NCiZn dDs8YnIgY2xhc3M9IiI+DQomZ3Q7IEkgc2VlIGEgcGxlYSBmb3IgYSBtb3JlIGhpZXJhcmNoaWNh bCBvcmdhbmlzYXRpb24sIGFuZCB3aGVuIEkgcmVhZDxiciBjbGFzcz0iIj4NCiZndDs8YnIgY2xh c3M9IiI+DQomZ3Q7IGRyYWZ0LWJqb3JrbHVuZC1uZXRtb2Qtb3BlbmNvbmZpZy1yZXBseS0wMDxi ciBjbGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7IEkgc2VlIGEgcmVzcG9uc2UgdGhh dCBzYXlzIHdlIGFyZSBub3QgbGlrZSB0aGF0LjxiciBjbGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9 IiI+DQomZ3Q7IElmIHNvLCBJIGRvdWJ0IHRoYXQgdGhlcmUgZXZlciB3aWxsIGJlIGEgdGVjaG5p Y2FsIHNvbHV0aW9uLjxiciBjbGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7IEFuZCBJ IGFtIG1pbmRmdWwgdGhhdCB3aGVuIEkgY29uZmlndXJlIHJvdXRpbmcgaW4gYSAoQ2lzY28pIHJv dXRlciwgSTxiciBjbGFzcz0iIj4NCiZndDsgaGF2ZSB0byBkbyBzb21lIG9mIGl0IHVuZGVyIHRo ZSBpbnRlcmZhY2UgZGVmaW5pdGlvbnMgYW5kIHNvbWUgb2YgaXQ8YnIgY2xhc3M9IiI+DQomZ3Q7 IHVuZGVyIHRoZSBkZWZpbml0aW9uIG9mIHRoZSByb3V0aW5nIHByb3RvY29sLiZuYnNwOyBXaGlj aCBpcyBsaWZlLCBuZXZlcjxiciBjbGFzcz0iIj4NCiZndDsgd2hvbHkgaW50ZXJmYWNlLWNlbnRy aWMgYW5kIG5ldmVyIHdob2x5IHJvdXRpbmcgcHJvdG9jb2wtY2VudHJpYyE8YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQpBcmUgeW91IHNheWluZyB0aGUgam9iIHdvdWxkIGJlIGVhc2llciBp ZiB0aGU8YnIgY2xhc3M9IiI+DQpwYXRoIHdhcyAvZGV2aWNlL2ludGVyZmFjZXMvaW50ZXJmYWNl IGluc3RlYWQ8YnIgY2xhc3M9IiI+DQpvZiBqdXN0IC9pbnRlcmZhY2VzL2ludGVyZmFjZT8mbmJz cDsgQXJlIHlvdSBzYXlpbmc8YnIgY2xhc3M9IiI+DQp0aGF0IC9wcm90b2NvbHMvcm91dGluZyBj b3VsZCBub3QgYWxzbyBiZSBkZWZpbmVkPzxiciBjbGFzcz0iIj4NCkNsZWFybHkgZWRpdC1jb25m aWcgYW5kIGNvcHktY29uZmlnIGFsbG93IGJvdGg8YnIgY2xhc3M9IiI+DQpzdWJ0cmVlcyB0byBi ZSBhY2Nlc3NlZCBpbiB0aGUgc2FtZSBvcGVyYXRpb24sPGJyIGNsYXNzPSIiPg0Kc28gSSBkb24n dCB1bmRlcnN0YW5kIHlvdXIgY29uY2Vybi48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJ IGhhdmUgYmVlbiB0cnlpbmcgdG8gZ2V0IHRoZSByb290IG5vZGUgdG8gYmUgYmV0dGVyIGRlZmlu ZWQ8YnIgY2xhc3M9IiI+DQppbiB0aGUgcHJvdG9jb2xzIHRoYXQgdXNlIFlBTkcgKGkuZS4sIG5j eDpyb290LCBZMzQtMDQpLjxiciBjbGFzcz0iIj4NCklNTyB0aGlzIGlzIGEgYmV0dGVyIGFwcHJv YWNoIHRoYW4gZGVmaW5pbmcgYSBZQU5HIG1vZHVsZTxiciBjbGFzcz0iIj4NCndpdGggYSBzcGVj aWFsIGNvbnRhaW5lciB0aGF0IGFsbCBvdGhlciBtb2R1bGVzIGFyZSBleHBlY3RlZDxiciBjbGFz cz0iIj4NCnRvIGF1Z21lbnQuJm5ic3A7IFlBTkcgaXMgZGVzaWduZWQgc3VjaCB0aGF0IGVhY2gg dmVuZG9yIG9yIFNETzxiciBjbGFzcz0iIj4NCmlzIG5vdCBkZXBlbmRlbnQgb24gb3RoZXIgdmVu ZG9ycyBvciBTRE9zIGluIG9yZGVyIHRvPGJyIGNsYXNzPSIiPg0KZGVmaW5lIGRhdGEgbm9kZXMu PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJmx0O3RwJmd0OzxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCkFuZHk8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJIGFtIGFncmVl aW5nIHdpdGggeW91IHRoYXQgYWRkaW5nICdkZXZpY2UnIGJyaW5ncyBubyB0ZWNobmljYWwgYmVu ZWZpdCw8YnIgY2xhc3M9IiI+DQpyYXRoZXIgdGhhdCB0aGUgbW90aXZhdGlvbiBpcyB0aGUgb3Bw b3NpdGUgb2YgdGVjaG5pY2FsICh3aGljaCBJPGJyIGNsYXNzPSIiPg0KcmVmZXJyZWQgdG8gYXMg cG9saXRpY2FsKS4gSSBhbSBhbHNvIGFncmVlaW5nIHdpdGggdGhlIGN1cnJlbnQgZGVjbGFyZWQ8 YnIgY2xhc3M9IiI+DQpjb25zZW5zdXMgb24gWTM0LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCkFuZCB5ZXMsIFlBTkcgaXMgZ29pbmcgdG8gZ2l2ZSB1cyBhIGxhcmdlIG51bWJlciBvZiBt b2R1bGVzLCBzb21lPGJyIGNsYXNzPSIiPg0KdGlnaHRseSBjb3VwbGVkIChhdWdtZW50cykgc29t ZSBsb29zZWx5IHNvIChob3cgbWFueSBkbyB5b3UgbmVlZCB0bzxiciBjbGFzcz0iIj4NCmNvbmZp Z3VyZSBPU1BGPykgYW5kIHdvcmsgaW4gdGhpcyBhcmVhIHdpbGwgYmUgb2YgYmVuZWZpdCBub3cg YW5kPGJyIGNsYXNzPSIiPg0KcHJvYmFibHkgZXNzZW50aWFsIGluIGEgZmV3IHllYXJzIHRpbWUu Jm5ic3A7IFRoYXQgc2FpZCwgSSBhbSB1bnN1cmUgd2hhdDxiciBjbGFzcz0iIj4NCnN1Y2ggd29y ayB3b3VsZCBiZSBsaWtlOyBJIGFtIGxvb2tpbmcgKGluIGRlc3BhaXIpIGF0IDUwIHJvdXRpbmcg YXJlYTxiciBjbGFzcz0iIj4NCllBTkcgbW9kZWxzIGFuZCB3b25kZXJpbmcgaG93IGEgdXNlciB3 aWxsIGV2ZXIgZ2V0IGEgY29oZXJlbnQgcGljdHVyZSBvZjxiciBjbGFzcz0iIj4NCmhvdyB0byBk byB3aGF0IHRoZXkgd2FudCB0byBkby48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhlICZxdW90O1lBTkcg TGFuZCBHcmFiJnF1b3Q7IGdpdmVzIGEgZmFsc2Ugc2Vuc2Ugb2YgcHJvZ3Jlc3MuPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPlJlYWNoaW5nIFdHIGNvbnNlbnN1cyBvbiBldmVyeSBzaW5nbGUgbGVhZiBp cyBoYXJkIHdvcmsuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj5JIGRvbid0IHRoaW5rIGEgY29sbGVjdGlvbiBvZiAxMDBzIG9mIFlBTkcg bW9kdWxlcyBpcyBldmVyPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPmdvaW5n IHRvIHRvIGJlIGVhc3kgdG8gdW5kZXJzdGFuZC4mbmJzcDsgT3BlcmF0b3JzIHdpbGwgbm90IGV4 YW1pbmU8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+YSBORVRDT05GICZsdDtoZWxsbyZndDsgbWVzc2Fn ZSwgbG9vayBhdCAxNTAgbW9kdWxlIFVSSXMsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPmFuZCBzYXkg JnF1b3Q7SSBrbm93IGV4YWN0bHkgd2hhdCB0aGlzIGRldmljZSBzdXBwb3J0cyZxdW90Oy48L2Rp dj4NCjxkaXYgY2xhc3M9IiI+SSBndWVzcyBpdCBpcyB1cCB0byBjbGllbnQgdG9vbHMgdG8gZG8g dGhhdDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+SSB3cm90ZSBhIGRyYWZ0IHRoYXQgZGVmaW5lcyBZQU5HIFBhY2thZ2VzLCB3aGljaCBj YW4gcHJvdmlkZTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5hIGhpZ2hlciBsZXZlbCBvZiBvcmdhbml6 YXRpb24gZm9yIFlBTkcgbW9kdWxlcy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtYmllcm1hbi1uZXRtb2QteWFuZy1wYWNrYWdlLyIgY2xhc3M9IiI+aHR0 cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1iaWVybWFuLW5ldG1vZC15YW5nLXBh Y2thZ2UvPC9hPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+WW91IGFuZCBJIGFyZSBhcHBhcmVudGx5IGluIHRo ZSBtaW5vcml0eSwgc2luY2UgdGhlIG9mZmljaWFsIHN0YXR1czwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij5pcyB0aGF0IHRoZXJlIGlzIG5vIHByb2JsZW0gd2l0aCB0aGUgY3VycmVudCBhcHByb2FjaCwg YW5kIG5vIG5lZWQ8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+dG8gb3JnYW5pemUgaW5kaXZpZHVhbCBZ QU5HIG1vZHVsZXMgaW50byBhbnkgbGFyZ2VyIGFic3RyYWN0aW9ucy48L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0 OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXg7Ij4NCiZuYnNwO1RvbSBQZXRjaDxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj5BbmR5PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOzwvZGl2Pg0KPGJs b2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9y ZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleDsiPg0KQW5keTxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCiZndDsgQW5keTxiciBjbGFzcz0iIj4NCiZndDs8YnIgY2xh c3M9IiI+DQomZ3Q7ICZndDsgVGhlIHdlbGwtc3BlY2lmaWVkIFhQYXRoIGFuZCBZQU5HIHJvb3Qg KC8pIGNhbiBiZTxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyBhY2Nlc3NlZCBieSBhbGwgcHJvdG9j b2wgb3BlcmF0aW9ucywgZXhhY3RseSB0aGUgc2FtZTxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyBh cyBhIG5vZGUgY2FsbGVkICdkZXZpY2UnLiZuYnNwOyBUaGUgYWN0dWFsIG5vZGUgbmFtZSB3aWxs PGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7IGRlcGVuZCBvbiB0aGUgUlBDIGZ1bmN0aW9uIChlLmcu ICdkYXRhJyBvciAnY29uZmlnJykuPGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7PGJyIGNsYXNzPSIi Pg0KJmd0OyAmZ3Q7IFRoaXMgaXMgbW9yZSB0aGFuIHJlZHVuZGFudCBob3dldmVyLiZuYnNwOyBJ dCBpbnRyb2R1Y2VzIGEgJnF1b3Q7c3VwZXItbW9kdWxlJnF1b3Q7PGJyIGNsYXNzPSIiPg0KJmd0 OyAmZ3Q7IGludG8gWUFORyB0aGF0IGV2ZXJ5IG90aGVyIG1vZHVsZSBpcyBleHBlY3RlZCB0byBh dWdtZW50LjxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyBZQU5HIGlzIGludGVuZGVkIHRvIGJlIG1v cmUgbG9vc2VseSBjb3VwbGVkIHRoYW4gdGhhdC48YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgVGhp cyBpbnRyb2R1Y2VzIGFuIGV4dHJhIG5vZGUgYW5kIG5hbWVzcGFjZSBkZWNsYXJhdGlvbjxiciBj bGFzcz0iIj4NCiZndDsgJmd0OyBpbiBhbGwgcHJvdG9jb2wgbWVzc2FnZXMsIGluY3JlYXNpbmcg bWVzc2FnZSBzaXplcy48YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7 ICZndDsgSXQgYWxzbyBhc3N1bWVzIGFsbCBleGlzdGluZyBZQU5HIG1vZGVscyB3aWxsIGdldCBy ZXdyaXR0ZW4gdG88YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgYWNjb3VudCBmb3IgJnF1b3Q7L2Rl dmljZSZxdW90OyBpbiBhbGwgcGF0aCBhbmQgWFBhdGggZXhwcmVzc2lvbnMuPGJyIGNsYXNzPSIi Pg0KJmd0OyAmZ3Q7IFRoaXMgaXMgaGlnaGx5IGRpc3J1cHRpdmUgdG8gZXhpc3RpbmcgZGVwbG95 bWVudHMuPGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7IEFsc28sIG11bHRpcGxlIGRhdGEgbW9kZWxz IHRvIGVkaXQgdGhlIHNhbWUgdGhpbmcgY2F1c2VzIGxvdHM8YnIgY2xhc3M9IiI+DQomZ3Q7ICZn dDsgb2YgZXh0cmEgY29tcGxleGl0eSBpbiB0aGUgc2VydmVyIChzdXBwb3J0aW5nIGJvdGggb2xk PGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7IGxvY2F0aW9uIGFuZCBuZXcgbG9jYXRpb24pLjxiciBj bGFzcz0iIj4NCiZndDsgJmd0OzxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyBJTU8gYSByZXNvdXJj ZSBkaXJlY3RvcnkgYXBwcm9hY2ggaXMgbXVjaCBtb3JlIHJlYWxpc3RpYy48YnIgY2xhc3M9IiI+ DQomZ3Q7ICZndDsgVGhlIC9kZXZpY2UgdHJlZSBjYW4gY29udGFpbiBhbGwgdGhlIG9yZ2FuaXpl ZCBOUCBjb250YWluZXJzLjxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyBJbnN0ZWFkIG9mIGFsbCB0 aGUgYWN0dWFsIGRhdGEgbm9kZXMsIHRoaXMgdHJlZSBqdXN0IGhhcyBwb2ludGVyczxiciBjbGFz cz0iIj4NCiZndDsgJmd0OyB0byB0aGUgcmVhbCBsb2NhdGlvbiBvZiB0aGUgcmVzb3VyY2UuIChs aWtlIDMwMSBNb3ZlZCBQZXJtYW5lbnRseSk8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDs8YnIgY2xh c3M9IiI+DQomZ3Q7ICZndDsgJmd0OyBBY2VlPGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7ICZndDs8 YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgQW5keTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NCioqIFNvbHV0aW9uIFkzNC0wMjxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCiZuYnNwOyBLZWVwICdhbnl4bWwnLiZuYnNwOyBJbnRyb2R1Y2UgJ2FueWRhdGEnIGFz IGFib3ZlIGJ1dCB3aXRob3V0IHRoZTxiciBjbGFzcz0iIj4NCiZuYnNwOyAnZm9ybWF0JyBzdWJz dGF0ZW1lbnQuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICdhbnl4bWwnIHdv dWxkIHN0aWxsIGJlIHVzZWQgdG8gcmVwcmVzZW50IHVucmVzdHJpY3RlZCBYTUwsIGFzIGlzPGJy IGNsYXNzPSIiPg0KJm5ic3A7IGRvbmUgaW4gTkVUQ09ORi48YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQombmJzcDsgJ2FueWRhdGEnIHdvdWxkIGJlIGFuIHVua25vd24gY2h1bmsgb2YgZGF0 YSB0aGF0IGNhbiBiZSBtb2RlbGxlZDxiciBjbGFzcz0iIj4NCiZuYnNwOyB3aXRoIFlBTkcuJm5i c3A7IENhbiBiZSBlbmNvZGVkIGFzIHhtbCBvciBqc29uLjxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCiZuYnNwOyBGb3IgZXhhbXBsZTo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQom bmJzcDsgJm5ic3A7ICMmIzQzO0JFR0lOX0VYQU1QTEU8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5i c3A7IGFueWRhdGEgZGF0YTs8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICMmIzQzO0VORF9F WEFNUExFPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KKiogU29sdXRpb24gWTM0LTA1PGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO1NhbWUgYXMgWTM0LTAyIHBs dXMgdHdvIGd1aWRlbGluZXMgYWRvcHRlZCBmcm9tIFkzNC0wNDo8YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQombmJzcDsgJm5ic3A7LSBLZWVwICdhbnl4bWwnIHVuY2hhbmdlZCBhcyBpdCBp cyBkZWZpbmVkIGluIFlBTkcgMS4wLiBUaGlzPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDtlbnN1cmVzIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkuPGJyIGNsYXNzPSIiPg0KJm5ic3A7 ICZuYnNwOy0gSW50cm9kdWNlIGEgbmV3ICdhbnlkYXRhJyBzdGF0ZW1lbnQgdGhhdCByZXByZXNl bnRzIGFuIHVua25vd248YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwO2NodW5rIG9m IGRhdGEgdGhhdCBjYW4gYmUgbW9kZWxlZCB3aXRoIFlBTkc8YnIgY2xhc3M9IiI+DQombmJzcDsg Jm5ic3A7LSBEb2N1bWVudCB0aGF0IGltcGxlbWVudGF0aW9ucyBNQVkgaGF2ZSByZXN0cmljdGlv bnMgZm9yIGFueXhtbCBhbmQ8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwO3RoYXQg YW55eG1sIGlzIG5vdCBuZWNlc3NhcmlseSBpbnRlcm9wZXJhYmxlOyBkYXRhIG1vZGVsIHdyaXRl cnM8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwO3Nob3VsZCB1c2UgYW55ZGF0YSB3 aGVuZXZlciBwb3NzaWJsZS48YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7LSBUaGUgZ3VpZGVs aW5lcyBkb2N1bWVudCBzaG91bGQgc2F5IHRoYXQgWUFORyBEb2N0b3JzIHdpbGwgcmV2aWV3PGJy IGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDtlYWNoIHVzZSBvZiBhbnl4bWwgaW4gSUVU RiBtb2R1bGVzIHdoZW4gWUFORyAxLjEgaXMgYWRvcHRlZCB0bzxiciBjbGFzcz0iIj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7YXZvaWQgaXRzIHVzZSB3aGVuZXZlciBwb3NzaWJsZS48YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQomZ3Q7PGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjwvZGl2Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnIgY2xhc3M9IiI+DQpuZXRtb2QgbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0i bWFpbHRvOm5ldG1vZEBpZXRmLm9yZyIgY2xhc3M9IiI+bmV0bW9kQGlldGYub3JnPC9hPjxiciBj bGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bmV0bW9kIiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l dG1vZDwvYT48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D1EE72752AA99aceeciscocom_-- From nobody Mon Aug 10 13:15:21 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFF5D1B3D98 for ; Mon, 10 Aug 2015 13:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_34=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 kJmmduAf8rVu for ; Mon, 10 Aug 2015 13:15:15 -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 AB2221B3D91 for ; Mon, 10 Aug 2015 13:15:14 -0700 (PDT) Received: by lbcbn3 with SMTP id bn3so7040766lbc.2 for ; Mon, 10 Aug 2015 13:15:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=2uVZA4p/YTGdOgxcDvQbmu1aDTZUH3ygjYNaw16cEE8=; b=iHrCgoEcbQ21x5E1mzfq+NSP/z2fm3ilSTqYIjQOJactwft+XGAyUTCIX+IMniLsUK fQOQxqb0tETjAUjMfHcCsWtYozb6/TNQBLhVJ6T0te+Hozyl6ZQPSCwemiu8tjhfu2Ip gU6/CLfABF5a5HRMlWQQWQziwTSaZPuJsKqHL7bWJPLvW9fW/4XzqXW+0zYqIZs9HqDA YP/sHp5sKRXnVp6osN3h07+IiMJMsNW2Dm9EagzG4hBnoa8FtGFmatAy4CsgjG13ESrD ZThpFO6cKgZBs0ZScyKooH8hZZuZ82rDQ702o8qZIjSd9iYD7RVFUvUpQEVxJ9RA+vl8 Bjaw== X-Gm-Message-State: ALoCoQmVd17pyOS05amOcFs03VL3JQ8MRWQym30iBmZ10IgDQ0+X0OUL2jMatcZ71dAoAGVbNkr+ MIME-Version: 1.0 X-Received: by 10.152.37.67 with SMTP id w3mr22262887laj.123.1439237713083; Mon, 10 Aug 2015 13:15:13 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Mon, 10 Aug 2015 13:15:12 -0700 (PDT) In-Reply-To: References: Date: Mon, 10 Aug 2015 13:15:12 -0700 Message-ID: From: Andy Bierman To: "Acee Lindem (acee)" Content-Type: multipart/alternative; boundary=089e0158ba0aa2da44051cfaa4ee Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Y34 - root node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 20:15:19 -0000 --089e0158ba0aa2da44051cfaa4ee Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Aug 10, 2015 at 12:34 PM, Acee Lindem (acee) wrote= : > I think there is agreement that there is a problem. The YANG Routing > Design Team is addressing this with > https://www.ietf.org/id/draft-rtgyangdt-rtgwg-device-model-00.txt (which > has evolved from > https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt). > In essence, a place for everything and everything in its place. However, > there are those who feel that can=E2=80=99t mandate a single model struct= ure for > network devices and we need mechanisms to manage multiple models but allo= w > for different device structure (e.g., > https://www.ietf.org/id/draft-bierman-netmod-yang-package-00.txt). I > hope we can agree on an approach in the coming interim meetings. > > Do you expect "everything in its place" to apply to all other SDOs and all vendor modules? Or do you expect just the IETF routing modules to follow this subtree hierarchy? If the former, does this mean the YANG Routing Design Team is the "YANG data placement authority" or all YANG modules that ever get written? How long should it take for all other SDOs and vendors to redo all their existing modules to re-root them in their assigned place in the data tree? IMO is is not a good idea to rely on rigid data node placement, and a single data placement authority. It is better and use meta-data built from the YANG modules (or YANG packages) instead. The reason Linux uses packages to install/update functionality is because managing 8000 packages is hard enough. Managing 247,000 individual files would be insane. The actual location of files is quite configurable and different across distros. We could learn something from the last decade of Linux package management, and try to apply it to YANG. Thanks, > Acee > Andy > > > > From: netmod on behalf of "Einar Nilsen-Nygaard > (einarnn)" > Date: Monday, August 10, 2015 at 5:29 AM > To: Jonathan Hansford > Cc: NETMOD Working Group > Subject: Re: [netmod] Y34 - root node > > As someone sharing responsibilities for guiding a number of development > teams both defining new models and implementing to some already defined > models in this area, I can only agree with this addition to what I said > earlier. > > Cheers, > > Einar > > On Aug 10, 2015, at 9:46 AM, Jonathan Hansford > wrote: > > And it is not just end users who need help to better understand YANG > models and how to use them. For those still on the edge, looking to final= ly > take the plunge and use NETCONF/YANG to configure their devices, help is > also required to determine how best to structure their YANG models, make > use of the existing ones, etc. For those who have "grown up" with the > developments in NETCONF and YANG, much of this is probably second nature. > But coming to it cold (in the sense of compiling/writing a first set of > YANG models for a device; I've been following the netconf/netmod WGs for = 3+ > years), it still feels very much like a dark art! It is not just the > individual modules, it is how to put them together to best manage a devic= e > (let alone a system). > > Jonathan > > > > ----- Original Message ----- > From: > "Einar Nilsen-Nygaard (einarnn)" > > To: > "Andy Bierman" > Cc: > "NETMOD Working Group" > Sent: > Sat, 8 Aug 2015 11:10:15 +0000 > Subject: > Re: [netmod] Y34 - root node > > > Andy, > > I agree that there is a need for organization of models, but I don=E2=80= =99t have > a firm position > on draft-openconfig-netmod-model-structure/draft-rtgyangdt-rtgwg-device-m= odel > or draft-bierman-netmod-yang-package. But we absolutely need *something* = to > help end-users of the models comprehend the overall structure of models, > their relationship and how to use them. > > Cheers, > > Einar > > On Aug 4, 2015, at 5:16 PM, Andy Bierman wrote: > > > > On Tue, Aug 4, 2015 at 2:34 AM, t.petch wrote: > >> ----- Original Message ----- >> From: "Andy Bierman" >> To: "t.petch" >> Sent: Monday, August 03, 2015 5:17 PM >> >> > ----- Original Message ----- >> > From: "Andy Bierman" > >> > To: "t.petch" >> > Sent: Monday, August 03, 2015 4:10 PM >> > >> > > ----- Original Message ----- >> > > From: "Andy Bierman" andy@yumaworks.com >> > > Sent: Saturday, August 01, 2015 7:05 PM >> > > On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem (acee) >> > > >> >>> On 8/1/15, 2:51 AM, j.schoenwaelder@jacobs-university.de> wrote: >> >>> >> >>> Section 1.1 in >> >>> >> > https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt >> >>> lists the goals of a generic model structure that will accommodate >> >> most >> >>> modern network devices. I guess you don=E2=80=99t agree that these a= re >> >> desirable? >> > > >> > > The only objection I have to this draft is the insertion of a >> top-level >> > > root >> > > called "device". (Might as well be called "self"). >> > > There are no sibling nodes planned or intended for >> > > this node, so it serves as an extra document root. >> > > >> > > >> > > One aspect of YANG I have never grasped is what a root means, if >> > > anything. >> > > >> > > I understand that it is needed for NETCONF (filters) and for YANG >> > > (augments, constraints) and so must be somewhere and must be >> > relatively >> > > stable, but has it any other significance in the data model? >> > > >> > > As you may recall, I was involved with SMI first, where the root is >> > > somewhere up in the sky and life only becomes interesting some six >> > > levels down the hierarchy and that may colour my thinking. >> > > >> > >> > YANG does a poor job of defining the root for YANG data nodes. >> > It is sometimes called a datastore (in the abstract). >> > Technically, YANG borrows the definition from XPath. >> > YANG just defines top-level data nodes and the parent of >> > these nodes is the document root >> > >> > There is no protocol or encoding neutral definition, >> > only an XML-specific definition. >> > >> > >> > >> > Thanks for that. >> > >> > It seems to me that much of the extensive discussion on Y34 (all of >> > which I have read) is as much political as technical, that is SMI is >> > hierarchical, top down, perhaps befitting its origins in ISO, whereas >> > YANG is bottom up. IETF-like. YANG could have had a single tree, but >> > doesn't. So when I read >> > >> > https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt >> > >> > I see a plea for a more hierarchical organisation, and when I read >> > >> > draft-bjorklund-netmod-openconfig-reply-00 >> > >> > I see a response that says we are not like that. >> > >> > If so, I doubt that there ever will be a technical solution. >> > >> > And I am mindful that when I configure routing in a (Cisco) router, I >> > have to do some of it under the interface definitions and some of it >> > under the definition of the routing protocol. Which is life, never >> > wholy interface-centric and never wholy routing protocol-centric! >> >> Are you saying the job would be easier if the >> path was /device/interfaces/interface instead >> of just /interfaces/interface? Are you saying >> that /protocols/routing could not also be defined? >> Clearly edit-config and copy-config allow both >> subtrees to be accessed in the same operation, >> so I don't understand your concern. >> >> I have been trying to get the root node to be better defined >> in the protocols that use YANG (i.e., ncx:root, Y34-04). >> IMO this is a better approach than defining a YANG module >> with a special container that all other modules are expected >> to augment. YANG is designed such that each vendor or SDO >> is not dependent on other vendors or SDOs in order to >> define data nodes. >> >> >> >> Andy >> >> I am agreeing with you that adding 'device' brings no technical benefit, >> rather that the motivation is the opposite of technical (which I >> referred to as political). I am also agreeing with the current declared >> consensus on Y34. >> >> And yes, YANG is going to give us a large number of modules, some >> tightly coupled (augments) some loosely so (how many do you need to >> configure OSPF?) and work in this area will be of benefit now and >> probably essential in a few years time. That said, I am unsure what >> such work would be like; I am looking (in despair) at 50 routing area >> YANG models and wondering how a user will ever get a coherent picture of >> how to do what they want to do. >> >> > > The "YANG Land Grab" gives a false sense of progress. > Reaching WG consensus on every single leaf is hard work. > > I don't think a collection of 100s of YANG modules is ever > going to to be easy to understand. Operators will not examine > a NETCONF message, look at 150 module URIs, > and say "I know exactly what this device supports". > I guess it is up to client tools to do that > > I wrote a draft that defines YANG Packages, which can provide > a higher level of organization for YANG modules. > > http://datatracker.ietf.org/doc/draft-bierman-netmod-yang-package/ > > You and I are apparently in the minority, since the official status > is that there is no problem with the current approach, and no need > to organize individual YANG modules into any larger abstractions. > > > > Tom Petch >> >> > > Andy > > >> Andy >> >> > Andy >> > >> > > The well-specified XPath and YANG root (/) can be >> > > accessed by all protocol operations, exactly the same >> > > as a node called 'device'. The actual node name will >> > > depend on the RPC function (e.g. 'data' or 'config'). >> > > >> > > This is more than redundant however. It introduces a "super-module" >> > > into YANG that every other module is expected to augment. >> > > YANG is intended to be more loosely coupled than that. >> > > This introduces an extra node and namespace declaration >> > > in all protocol messages, increasing message sizes. >> > > >> > > It also assumes all existing YANG models will get rewritten to >> > > account for "/device" in all path and XPath expressions. >> > > This is highly disruptive to existing deployments. >> > > Also, multiple data models to edit the same thing causes lots >> > > of extra complexity in the server (supporting both old >> > > location and new location). >> > > >> > > IMO a resource directory approach is much more realistic. >> > > The /device tree can contain all the organized NP containers. >> > > Instead of all the actual data nodes, this tree just has pointers >> > > to the real location of the resource. (like 301 Moved Permanently) >> > > >> > > > Acee >> > > > >> > > Andy >> >> >> ** Solution Y34-02 >> >> Keep 'anyxml'. Introduce 'anydata' as above but without the >> 'format' substatement. >> >> 'anyxml' would still be used to represent unrestricted XML, as is >> done in NETCONF. >> >> 'anydata' would be an unknown chunk of data that can be modelled >> with YANG. Can be encoded as xml or json. >> >> For example: >> >> #+BEGIN_EXAMPLE >> anydata data; >> #+END_EXAMPLE >> >> ** Solution Y34-05 >> >> Same as Y34-02 plus two guidelines adopted from Y34-04: >> >> - Keep 'anyxml' unchanged as it is defined in YANG 1.0. This >> ensures backward compatibility. >> - Introduce a new 'anydata' statement that represents an unknown >> chunk of data that can be modeled with YANG >> - Document that implementations MAY have restrictions for anyxml and >> that anyxml is not necessarily interoperable; data model writers >> should use anydata whenever possible. >> - The guidelines document should say that YANG Doctors will review >> each use of anyxml in IETF modules when YANG 1.1 is adopted to >> avoid its use whenever possible. >> >> >> > >> >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --089e0158ba0aa2da44051cfaa4ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Aug 10, 2015 at 12:34 PM, Acee Lindem (acee) = <acee@cisco.com&= gt; wrote:
I think there is agreement that there is a problem. The YANG Routing D= esign Team is =C2=A0addressing this with https://www.i= etf.org/id/draft-rtgyangdt-rtgwg-device-model-00.txt =C2=A0(which has e= volved from=C2=A0https://www.ietf.org/id/draft-op= enconfig-netmod-model-structure-00.txt). In essence, a place for everything and everything in its place. However, t= here are those who feel that can=E2=80=99t mandate a single model structure= for network devices and we need mechanisms to manage multiple models but a= llow for different device structure (e.g., https://www.ietf.org/id/draft-bierman-netmod-yang-pack= age-00.txt).=C2=A0 I hope we can agree on an approach in the coming int= erim meetings.=C2=A0


Do you expect "e= verything in its place" to apply to all other SDOs and
all v= endor modules? Or do you expect just the IETF routing modules
to = follow this subtree hierarchy? If the former, does this mean the
= YANG Routing Design Team is the "YANG data placement authority"= =C2=A0
or all YANG modules that ever get written? How long should=
it take for all other SDOs and vendors to redo all their existin= g
modules to re-root them in their assigned place in the data tre= e?

IMO is is not a good idea to rely on rigid data= node placement,
and a single data placement authority. It is bet= ter and use meta-data
built from the YANG modules (or YANG packag= es) instead.

The reason Linux uses packages to ins= tall/update functionality
is because managing 8000 packages is ha= rd enough.
Managing 247,000 individual files would be insane.
The actual location of files is quite configurable and different
across distros. We could learn something from the last decade
<= div>of Linux package management, and try to apply it to YANG.




Thanks,
Acee =C2=A0


Andy
=C2=A0



From: netmod <netmod-bounces@ietf.org> = on behalf of "Einar Nilsen-Nygaard (einarnn)" <einarnn@cisco.com>
Date: Monday, August 10, 2015 at 5:= 29 AM
To: Jonathan Hansford <jonathan@hansfords.net= >
Cc: NETMOD Working Group <netmod@ietf.org>
Subject: Re: [netmod] Y34 - root no= de

As someone sharing responsibilities for guiding a number of development tea= ms both defining new models and implementing to some already defined models= in this area, I can only agree with this addition to what I said earlier.

Cheers,

Einar

On Aug 10, 2015, at 9:46 AM, Jonathan Hansford <jonathan@hansfords.net> wro= te:

=C2=A0And it is not just end users who need help to better understand YANG = models and how to use them. For those still on the edge, looking to finally= take the plunge and use NETCONF/YANG to configure their devices, help is a= lso required to determine how best to structure their YANG models, make use of the existing ones, etc. For those= who have "grown up" with the developments in NETCONF and YANG, m= uch of this is probably second nature. But coming to it cold (in the sense = of compiling/writing a first set of YANG models for a device; I've been following the netconf/netmod WGs for 3+ years)= , it still feels very much like a dark art! It is not just the individual m= odules, it is how to put them together to best manage a device (let alone a= system).

Jonathan



----- Original Message -----
From:
"Einar Nilsen-Nygaard (einarnn)" <einarnn@cisco.com>

To:
"Andy Bierman" <andy@yumaworks.com>
Cc:
"NETMOD Working Group" <netmod@ietf.org>
Sent:
Sat, 8 Aug 2015 11:10:15 +0000
Subject:
Re: [netmod] Y34 - root node


Andy,

I agree that there is a need for organization of models, but I don=E2= =80=99t have a firm position on=C2=A0draft-openconfig-netmod-model-structur= e/draft-rtgyangdt-rtgwg-device-model or=C2=A0draft-bierman-netmod-yang-pack= age. But we absolutely need *something* to help end-users of the models comprehend the overall structure of models, t= heir relationship and how to use them.

Cheers,

Einar

On Aug 4, 2015, at 5:16 PM, Andy Bierman <andy@yumaworks.com> wrote:



On Tue, Aug 4, 2015 at 2:34 AM, t.petch <ietfc@btconnec= t.com> wrote:
----- Original Message -----
From: "Andy Bierman" <andy@yumaworks.com>
To: "t.petch" <ietfc@btconnect.com>
Sent: Monday, August 03, 2015 5:17 PM

> ----- Original Message -----
> From: "Andy Bierman" <andy@yumaworkscom>
> To: "t.petch" <ietfc@btconnect.com>
> Sent: Monday, August 03, 2015 4:10 PM
>
> > ----- Original Message -----
> > From: "Andy Bierman" andy@yumaworks.com
> > Sent: Saturday, August 01, 2015 7:05 PM
> > On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem (acee) <acee@cisco.com>
> >
>>> On 8/1/15, 2:51 AM,=C2=A0 j.schoenwaelder@jacobs-university.de> wrote:
>>>
>>> Section 1.1 in
>>>
> https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt<= br> >>> lists the goals of a generic model structure that will accommo= date
>> most
>>> modern network devices. I guess you don=E2=80=99t agree that t= hese are
>> desirable?
> >
> > The only objection I have to this draft is the insertion of a
top-level
> > root
> > called "device".=C2=A0 (Might as well be called "s= elf").
> > There are no sibling nodes planned or intended for
> > this node, so it serves as an extra document root.
> >
> > <tp>
> > One aspect of YANG I have never grasped is what a root means, if<= br> > > anything.
> >
> > I understand that it is needed for NETCONF (filters) and for YANG=
> > (augments, constraints) and so must be somewhere and must be
> relatively
> > stable, but has it any other significance in the data model?
> >
> > As you may recall, I was involved with SMI first, where the root = is
> > somewhere up in the sky and life only becomes interesting some si= x
> > levels down the hierarchy and that may colour my thinking.
> >
>
> YANG does a poor job of defining the root for YANG data nodes.
> It is sometimes called a datastore (in the abstract).
> Technically, YANG borrows the definition from XPath.
> YANG just defines top-level data nodes and the parent of
> these nodes is the document root
>
> There is no protocol or encoding neutral definition,
> only an XML-specific definition.
>
> <tp>
>
> Thanks for that.
>
> It seems to me that much of the extensive discussion on Y34 (all of > which I have read) is as much political as technical, that is SMI is > hierarchical, top down, perhaps befitting its origins in ISO, whereas<= br> > YANG is bottom up. IETF-like.=C2=A0 YANG could have had a single tree,= but
> doesn't.=C2=A0 So when I read
>
> https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt<= br> >
> I see a plea for a more hierarchical organisation, and when I read
>
> draft-bjorklund-netmod-openconfig-reply-00
>
> I see a response that says we are not like that.
>
> If so, I doubt that there ever will be a technical solution.
>
> And I am mindful that when I configure routing in a (Cisco) router, I<= br> > have to do some of it under the interface definitions and some of it > under the definition of the routing protocol.=C2=A0 Which is life, nev= er
> wholy interface-centric and never wholy routing protocol-centric!

Are you saying the job would be easier if the
path was /device/interfaces/interface instead
of just /interfaces/interface?=C2=A0 Are you saying
that /protocols/routing could not also be defined?
Clearly edit-config and copy-config allow both
subtrees to be accessed in the same operation,
so I don't understand your concern.

I have been trying to get the root node to be better defined
in the protocols that use YANG (i.e., ncx:root, Y34-04).
IMO this is a better approach than defining a YANG module
with a special container that all other modules are expected
to augment.=C2=A0 YANG is designed such that each vendor or SDO
is not dependent on other vendors or SDOs in order to
define data nodes.

<tp>

Andy

I am agreeing with you that adding 'device' brings no technical ben= efit,
rather that the motivation is the opposite of technical (which I
referred to as political). I am also agreeing with the current declared
consensus on Y34.

And yes, YANG is going to give us a large number of modules, some
tightly coupled (augments) some loosely so (how many do you need to
configure OSPF?) and work in this area will be of benefit now and
probably essential in a few years time.=C2=A0 That said, I am unsure what such work would be like; I am looking (in despair) at 50 routing area
YANG models and wondering how a user will ever get a coherent picture of how to do what they want to do.



The "YANG Land Grab" gives a false sense of progress.
Reaching WG consensus on every single leaf is hard work.

I don't think a collection of 100s of YANG modules is ever
going to to be easy to understand.=C2=A0 Operators will not examine
a NETCONF <hello> message, look at 150 module URIs,
and say "I know exactly what this device supports".
I guess it is up to client tools to do that

I wrote a draft that defines YANG Packages, which can provide
a higher level of organization for YANG modules.


You and I are apparently in the minority, since the official status
is that there is no problem with the current approach, and no need
to organize individual YANG modules into any larger abstractions.



=C2=A0Tom Petch



Andy
=C2=A0
Andy

> Andy
>
> > The well-specified XPath and YANG root (/) can be
> > accessed by all protocol operations, exactly the same
> > as a node called 'device'.=C2=A0 The actual node name wil= l
> > depend on the RPC function (e.g. 'data' or 'config= 9;).
> >
> > This is more than redundant however.=C2=A0 It introduces a "= super-module"
> > into YANG that every other module is expected to augment.
> > YANG is intended to be more loosely coupled than that.
> > This introduces an extra node and namespace declaration
> > in all protocol messages, increasing message sizes.
> >
> > It also assumes all existing YANG models will get rewritten to > > account for "/device" in all path and XPath expressions= .
> > This is highly disruptive to existing deployments.
> > Also, multiple data models to edit the same thing causes lots
> > of extra complexity in the server (supporting both old
> > location and new location).
> >
> > IMO a resource directory approach is much more realistic.
> > The /device tree can contain all the organized NP containers.
> > Instead of all the actual data nodes, this tree just has pointers=
> > to the real location of the resource. (like 301 Moved Permanently= )
> >
> > > Acee
> > >
> > Andy


** Solution Y34-02

=C2=A0 Keep 'anyxml'.=C2=A0 Introduce 'anydata' as above bu= t without the
=C2=A0 'format' substatement.

=C2=A0 'anyxml' would still be used to represent unrestricted XML, = as is
=C2=A0 done in NETCONF.

=C2=A0 'anydata' would be an unknown chunk of data that can be mode= lled
=C2=A0 with YANG.=C2=A0 Can be encoded as xml or json.

=C2=A0 For example:

=C2=A0 =C2=A0 #+BEGIN_EXAMPLE
=C2=A0 =C2=A0 anydata data;
=C2=A0 =C2=A0 #+END_EXAMPLE

** Solution Y34-05

=C2=A0 =C2=A0Same as Y34-02 plus two guidelines adopted from Y34-04:

=C2=A0 =C2=A0- Keep 'anyxml' unchanged as it is defined in YANG 1.0= . This
=C2=A0 =C2=A0 =C2=A0ensures backward compatibility.
=C2=A0 =C2=A0- Introduce a new 'anydata' statement that represents = an unknown
=C2=A0 =C2=A0 =C2=A0chunk of data that can be modeled with YANG
=C2=A0 =C2=A0- Document that implementations MAY have restrictions for anyx= ml and
=C2=A0 =C2=A0 =C2=A0that anyxml is not necessarily interoperable; data mode= l writers
=C2=A0 =C2=A0 =C2=A0should use anydata whenever possible.
=C2=A0 =C2=A0- The guidelines document should say that YANG Doctors will re= view
=C2=A0 =C2=A0 =C2=A0each use of anyxml in IETF modules when YANG 1.1 is ado= pted to
=C2=A0 =C2=A0 =C2=A0avoid its use whenever possible.


>


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

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


--089e0158ba0aa2da44051cfaa4ee-- From nobody Mon Aug 10 14:28:50 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50A791A038D for ; Mon, 10 Aug 2015 14:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.31 X-Spam-Level: X-Spam-Status: No, score=-13.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_34=0.6, 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 5xeeaRSVtEoE for ; Mon, 10 Aug 2015 14:28:43 -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 356CD1B2F27 for ; Mon, 10 Aug 2015 14:28:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=49529; q=dns/txt; s=iport; t=1439242123; x=1440451723; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=QzkKoL55mat23FqRQDe7I7WKIpKAkZZ5v4ouP2/MIgo=; b=nGA81TOuwOy1dugeqYvagjKvMCrWCmCdoheeJEGmdzy2KXx64834X0C9 DtYZEidYWI52uyvXCi0gFNivVJ8DLErpwjpWRTorj89S8dmcbs9vE9Dlr w53Qm6NeA93jZRAgRK96DKZ4z+Rh6UJv+IGflwelAkunbQHXyEVh1pa5s 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DmCwAtF8lV/4MNJK1TCoJOTVRpBoMeqimPQjOBYhkBCYUvSgIcgRw6EgEBAQEBAQGBCoQjAQEBAwEBAQEXCUsEBwUHBAIBCBABAwEBAQEVCwEGAwICAiULFAkIAgQOBRkCiAsIDbk6ljEBAQEBAQEBAQEBAQEBAQEBAQEBAQEXik6BA4QsEjAKDQQHBgSCX4FDBYxUAYg2AYUBgmmEeIFJRoZ2iE6ERINmERWCDxyBU3EBgUeBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,648,1432598400"; d="scan'208,217";a="177276750" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-6.cisco.com with ESMTP; 10 Aug 2015 21:28:36 +0000 Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t7ALSa6j017615 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 10 Aug 2015 21:28:36 GMT Received: from xch-rcd-016.cisco.com (173.37.102.26) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 10 Aug 2015 16:28:35 -0500 Received: from xhc-rcd-x03.cisco.com (173.37.183.77) by xch-rcd-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Mon, 10 Aug 2015 16:28:34 -0500 Received: from xmb-aln-x06.cisco.com ([169.254.1.223]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0248.002; Mon, 10 Aug 2015 16:28:34 -0500 From: "Acee Lindem (acee)" To: Andy Bierman Thread-Topic: [netmod] Y34 - root node Thread-Index: AQHQzfwQxnbl1H5mqEiCxAjpxb0TL536tNgA//+74pCAAFbtgIAAz0+UgADCtACABfPJgIAC/IuAgAAMEQCAAGXrgIAATmUA///RcQA= Date: Mon, 10 Aug 2015 21:28:34 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.36.7.28] Content-Type: multipart/alternative; boundary="_000_D1EE8D652AAEAaceeciscocom_" MIME-Version: 1.0 Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Y34 - root node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 21:28:48 -0000 --_000_D1EE8D652AAEAaceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkZyb206IEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPG1haWx0bzphbmR5QHl1 bWF3b3Jrcy5jb20+Pg0KRGF0ZTogTW9uZGF5LCBBdWd1c3QgMTAsIDIwMTUgYXQgNDoxNSBQTQ0K VG86IEFjZWUgTGluZGVtIDxhY2VlQGNpc2NvLmNvbTxtYWlsdG86YWNlZUBjaXNjby5jb20+Pg0K Q2M6ICJFaW5hciBOaWxzZW4tTnlnYWFyZCAoZWluYXJubikiIDxlaW5hcm5uQGNpc2NvLmNvbTxt YWlsdG86ZWluYXJubkBjaXNjby5jb20+PiwgSm9uYXRoYW4gSGFuc2ZvcmQgPGpvbmF0aGFuQGhh bnNmb3Jkcy5uZXQ8bWFpbHRvOmpvbmF0aGFuQGhhbnNmb3Jkcy5uZXQ+PiwgTkVUTU9EIFdvcmtp bmcgR3JvdXAgPG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPj4NClN1Ympl Y3Q6IFJlOiBbbmV0bW9kXSBZMzQgLSByb290IG5vZGUNCg0KDQoNCk9uIE1vbiwgQXVnIDEwLCAy MDE1IGF0IDEyOjM0IFBNLCBBY2VlIExpbmRlbSAoYWNlZSkgPGFjZWVAY2lzY28uY29tPG1haWx0 bzphY2VlQGNpc2NvLmNvbT4+IHdyb3RlOg0KSSB0aGluayB0aGVyZSBpcyBhZ3JlZW1lbnQgdGhh dCB0aGVyZSBpcyBhIHByb2JsZW0uIFRoZSBZQU5HIFJvdXRpbmcgRGVzaWduIFRlYW0gaXMgIGFk ZHJlc3NpbmcgdGhpcyB3aXRoIGh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXJ0Z3lhbmdk dC1ydGd3Zy1kZXZpY2UtbW9kZWwtMDAudHh0ICAod2hpY2ggaGFzIGV2b2x2ZWQgZnJvbSBodHRw czovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1vcGVuY29uZmlnLW5ldG1vZC1tb2RlbC1zdHJ1Y3R1 cmUtMDAudHh0KS4gSW4gZXNzZW5jZSwgYSBwbGFjZSBmb3IgZXZlcnl0aGluZyBhbmQgZXZlcnl0 aGluZyBpbiBpdHMgcGxhY2UuIEhvd2V2ZXIsIHRoZXJlIGFyZSB0aG9zZSB3aG8gZmVlbCB0aGF0 IGNhbuKAmXQgbWFuZGF0ZSBhIHNpbmdsZSBtb2RlbCBzdHJ1Y3R1cmUgZm9yIG5ldHdvcmsgZGV2 aWNlcyBhbmQgd2UgbmVlZCBtZWNoYW5pc21zIHRvIG1hbmFnZSBtdWx0aXBsZSBtb2RlbHMgYnV0 IGFsbG93IGZvciBkaWZmZXJlbnQgZGV2aWNlIHN0cnVjdHVyZSAoZS5nLiwgaHR0cHM6Ly93d3cu aWV0Zi5vcmcvaWQvZHJhZnQtYmllcm1hbi1uZXRtb2QteWFuZy1wYWNrYWdlLTAwLnR4dCkuICBJ IGhvcGUgd2UgY2FuIGFncmVlIG9uIGFuIGFwcHJvYWNoIGluIHRoZSBjb21pbmcgaW50ZXJpbSBt ZWV0aW5ncy4NCg0KDQpEbyB5b3UgZXhwZWN0ICJldmVyeXRoaW5nIGluIGl0cyBwbGFjZSIgdG8g YXBwbHkgdG8gYWxsIG90aGVyIFNET3MgYW5kDQphbGwgdmVuZG9yIG1vZHVsZXM/IE9yIGRvIHlv dSBleHBlY3QganVzdCB0aGUgSUVURiByb3V0aW5nIG1vZHVsZXMNCnRvIGZvbGxvdyB0aGlzIHN1 YnRyZWUgaGllcmFyY2h5PyBJZiB0aGUgZm9ybWVyLCBkb2VzIHRoaXMgbWVhbiB0aGUNCllBTkcg Um91dGluZyBEZXNpZ24gVGVhbSBpcyB0aGUgIllBTkcgZGF0YSBwbGFjZW1lbnQgYXV0aG9yaXR5 Ig0Kb3IgYWxsIFlBTkcgbW9kdWxlcyB0aGF0IGV2ZXIgZ2V0IHdyaXR0ZW4/IEhvdyBsb25nIHNo b3VsZA0KaXQgdGFrZSBmb3IgYWxsIG90aGVyIFNET3MgYW5kIHZlbmRvcnMgdG8gcmVkbyBhbGwg dGhlaXIgZXhpc3RpbmcNCm1vZHVsZXMgdG8gcmUtcm9vdCB0aGVtIGluIHRoZWlyIGFzc2lnbmVk IHBsYWNlIGluIHRoZSBkYXRhIHRyZWU/DQoNCknigJlkIGV4cGVjdCB0aGUgZmluYWwgZG9jdW1l bnQgdG8gYmUgYSBwcm9kdWN0IG9mIHRoZSBuZXRtb2QgV0cgYW5kLCBjb25zZXF1ZW50bHksIGhh dmUgd2lkZSByZXZpZXcgYW5kIGFwcHJvdmFsLiBXZSBhcmUgY29uc2lkZXJpbmcgc29tZSBjaGFu Z2VzIHRvIHNwZWNpZnkgYW4gaWRlbnRpZnkgZm9yIGEgY2xhc3Mgb2YgZGF0YSBtb2RlbCByYXRo ZXIgdGhhbiB0cnlpbmcgdG8gc3BlY2lmeSBzcGVjaWZpYyBtb2RlbHMuDQoNCkFzIGZvciBvdGhl ciBTRE9zIGFuZCB0aGVpciBZQU5HIG1vZGVscywgd2UgY2FuIHN1Z2dlc3QgcGxhY2VtZW50IGJ1 dCB3ZSByZWFsbHkgY2FuIGV2ZW4gZm9yY2UgdGhlbSB0byB1c2Ugb3VyIGJ1aWxkaW5nIGJsb2Nr cy4NCg0KDQpJTU8gaXMgaXMgbm90IGEgZ29vZCBpZGVhIHRvIHJlbHkgb24gcmlnaWQgZGF0YSBu b2RlIHBsYWNlbWVudCwNCmFuZCBhIHNpbmdsZSBkYXRhIHBsYWNlbWVudCBhdXRob3JpdHkuIEl0 IGlzIGJldHRlciBhbmQgdXNlIG1ldGEtZGF0YQ0KYnVpbHQgZnJvbSB0aGUgWUFORyBtb2R1bGVz IChvciBZQU5HIHBhY2thZ2VzKSBpbnN0ZWFkLg0KDQpJIGd1ZXNzIHdl4oCZcmUgZ29pbmcgdG8g aGF2ZSB0byBzZWUgdGhlIHByb2dyYW1taW5nIG1vZGVsIGZvciB0aGlzLiBGaXhlZCBwYXRocyBk byBwcm92aWRlIGEgY2xlYW4gcHJvZ3JhbW1pbmcgbW9kZWwuDQoNCg0KVGhlIHJlYXNvbiBMaW51 eCB1c2VzIHBhY2thZ2VzIHRvIGluc3RhbGwvdXBkYXRlIGZ1bmN0aW9uYWxpdHkNCmlzIGJlY2F1 c2UgbWFuYWdpbmcgODAwMCBwYWNrYWdlcyBpcyBoYXJkIGVub3VnaC4NCk1hbmFnaW5nIDI0Nyww MDAgaW5kaXZpZHVhbCBmaWxlcyB3b3VsZCBiZSBpbnNhbmUuDQpUaGUgYWN0dWFsIGxvY2F0aW9u IG9mIGZpbGVzIGlzIHF1aXRlIGNvbmZpZ3VyYWJsZSBhbmQgZGlmZmVyZW50DQphY3Jvc3MgZGlz dHJvcy4gV2UgY291bGQgbGVhcm4gc29tZXRoaW5nIGZyb20gdGhlIGxhc3QgZGVjYWRlDQpvZiBM aW51eCBwYWNrYWdlIG1hbmFnZW1lbnQsIGFuZCB0cnkgdG8gYXBwbHkgaXQgdG8gWUFORy4NCg0K SSB3aWwgZ2l2ZSB5b3VyIGRyYWZ0IGEgY2xvc2VyIHJlYWQuDQoNClRoYW5rcywNCkFjZWUNCg0K DQoNCg0KDQoNCg0KDQpUaGFua3MsDQpBY2VlDQoNCg0KQW5keQ0KDQoNCg0KDQpGcm9tOiBuZXRt b2QgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9y Zz4+IG9uIGJlaGFsZiBvZiAiRWluYXIgTmlsc2VuLU55Z2FhcmQgKGVpbmFybm4pIiA8ZWluYXJu bkBjaXNjby5jb208bWFpbHRvOmVpbmFybm5AY2lzY28uY29tPj4NCkRhdGU6IE1vbmRheSwgQXVn dXN0IDEwLCAyMDE1IGF0IDU6MjkgQU0NClRvOiBKb25hdGhhbiBIYW5zZm9yZCA8am9uYXRoYW5A aGFuc2ZvcmRzLm5ldDxtYWlsdG86am9uYXRoYW5AaGFuc2ZvcmRzLm5ldD4+DQpDYzogTkVUTU9E IFdvcmtpbmcgR3JvdXAgPG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPj4N ClN1YmplY3Q6IFJlOiBbbmV0bW9kXSBZMzQgLSByb290IG5vZGUNCg0KQXMgc29tZW9uZSBzaGFy aW5nIHJlc3BvbnNpYmlsaXRpZXMgZm9yIGd1aWRpbmcgYSBudW1iZXIgb2YgZGV2ZWxvcG1lbnQg dGVhbXMgYm90aCBkZWZpbmluZyBuZXcgbW9kZWxzIGFuZCBpbXBsZW1lbnRpbmcgdG8gc29tZSBh bHJlYWR5IGRlZmluZWQgbW9kZWxzIGluIHRoaXMgYXJlYSwgSSBjYW4gb25seSBhZ3JlZSB3aXRo IHRoaXMgYWRkaXRpb24gdG8gd2hhdCBJIHNhaWQgZWFybGllci4NCg0KQ2hlZXJzLA0KDQpFaW5h cg0KDQpPbiBBdWcgMTAsIDIwMTUsIGF0IDk6NDYgQU0sIEpvbmF0aGFuIEhhbnNmb3JkIDxqb25h dGhhbkBoYW5zZm9yZHMubmV0PG1haWx0bzpqb25hdGhhbkBoYW5zZm9yZHMubmV0Pj4gd3JvdGU6 DQoNCiBBbmQgaXQgaXMgbm90IGp1c3QgZW5kIHVzZXJzIHdobyBuZWVkIGhlbHAgdG8gYmV0dGVy IHVuZGVyc3RhbmQgWUFORyBtb2RlbHMgYW5kIGhvdyB0byB1c2UgdGhlbS4gRm9yIHRob3NlIHN0 aWxsIG9uIHRoZSBlZGdlLCBsb29raW5nIHRvIGZpbmFsbHkgdGFrZSB0aGUgcGx1bmdlIGFuZCB1 c2UgTkVUQ09ORi9ZQU5HIHRvIGNvbmZpZ3VyZSB0aGVpciBkZXZpY2VzLCBoZWxwIGlzIGFsc28g cmVxdWlyZWQgdG8gZGV0ZXJtaW5lIGhvdyBiZXN0IHRvIHN0cnVjdHVyZSB0aGVpciBZQU5HIG1v ZGVscywgbWFrZSB1c2Ugb2YgdGhlIGV4aXN0aW5nIG9uZXMsIGV0Yy4gRm9yIHRob3NlIHdobyBo YXZlICJncm93biB1cCIgd2l0aCB0aGUgZGV2ZWxvcG1lbnRzIGluIE5FVENPTkYgYW5kIFlBTkcs IG11Y2ggb2YgdGhpcyBpcyBwcm9iYWJseSBzZWNvbmQgbmF0dXJlLiBCdXQgY29taW5nIHRvIGl0 IGNvbGQgKGluIHRoZSBzZW5zZSBvZiBjb21waWxpbmcvd3JpdGluZyBhIGZpcnN0IHNldCBvZiBZ QU5HIG1vZGVscyBmb3IgYSBkZXZpY2U7IEkndmUgYmVlbiBmb2xsb3dpbmcgdGhlIG5ldGNvbmYv bmV0bW9kIFdHcyBmb3IgMysgeWVhcnMpLCBpdCBzdGlsbCBmZWVscyB2ZXJ5IG11Y2ggbGlrZSBh IGRhcmsgYXJ0ISBJdCBpcyBub3QganVzdCB0aGUgaW5kaXZpZHVhbCBtb2R1bGVzLCBpdCBpcyBo b3cgdG8gcHV0IHRoZW0gdG9nZXRoZXIgdG8gYmVzdCBtYW5hZ2UgYSBkZXZpY2UgKGxldCBhbG9u ZSBhIHN5c3RlbSkuDQoNCkpvbmF0aGFuDQoNCg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0t LS0tDQpGcm9tOg0KIkVpbmFyIE5pbHNlbi1OeWdhYXJkIChlaW5hcm5uKSIgPGVpbmFybm5AY2lz Y28uY29tPG1haWx0bzplaW5hcm5uQGNpc2NvLmNvbT4+DQoNClRvOg0KIkFuZHkgQmllcm1hbiIg PGFuZHlAeXVtYXdvcmtzLmNvbTxtYWlsdG86YW5keUB5dW1hd29ya3MuY29tPj4NCkNjOg0KIk5F VE1PRCBXb3JraW5nIEdyb3VwIiA8bmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5v cmc+Pg0KU2VudDoNClNhdCwgOCBBdWcgMjAxNSAxMToxMDoxNSArMDAwMA0KU3ViamVjdDoNClJl OiBbbmV0bW9kXSBZMzQgLSByb290IG5vZGUNCg0KDQpBbmR5LA0KDQpJIGFncmVlIHRoYXQgdGhl cmUgaXMgYSBuZWVkIGZvciBvcmdhbml6YXRpb24gb2YgbW9kZWxzLCBidXQgSSBkb27igJl0IGhh dmUgYSBmaXJtIHBvc2l0aW9uIG9uIGRyYWZ0LW9wZW5jb25maWctbmV0bW9kLW1vZGVsLXN0cnVj dHVyZS9kcmFmdC1ydGd5YW5nZHQtcnRnd2ctZGV2aWNlLW1vZGVsIG9yIGRyYWZ0LWJpZXJtYW4t bmV0bW9kLXlhbmctcGFja2FnZS4gQnV0IHdlIGFic29sdXRlbHkgbmVlZCAqc29tZXRoaW5nKiB0 byBoZWxwIGVuZC11c2VycyBvZiB0aGUgbW9kZWxzIGNvbXByZWhlbmQgdGhlIG92ZXJhbGwgc3Ry dWN0dXJlIG9mIG1vZGVscywgdGhlaXIgcmVsYXRpb25zaGlwIGFuZCBob3cgdG8gdXNlIHRoZW0u DQoNCkNoZWVycywNCg0KRWluYXINCg0KT24gQXVnIDQsIDIwMTUsIGF0IDU6MTYgUE0sIEFuZHkg Qmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPG1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20+PiB3 cm90ZToNCg0KDQoNCk9uIFR1ZSwgQXVnIDQsIDIwMTUgYXQgMjozNCBBTSwgdC5wZXRjaCA8aWV0 ZmNAYnRjb25uZWN0LmNvbTxtYWlsdG86aWV0ZmNAYnRjb25uZWN0LmNvbT4+IHdyb3RlOg0KLS0t LS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogIkFuZHkgQmllcm1hbiIgPGFuZHlAeXVt YXdvcmtzLmNvbTxtYWlsdG86YW5keUB5dW1hd29ya3MuY29tPj4NClRvOiAidC5wZXRjaCIgPGll dGZjQGJ0Y29ubmVjdC5jb208bWFpbHRvOmlldGZjQGJ0Y29ubmVjdC5jb20+Pg0KU2VudDogTW9u ZGF5LCBBdWd1c3QgMDMsIDIwMTUgNToxNyBQTQ0KDQo+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2Ug LS0tLS0NCj4gRnJvbTogIkFuZHkgQmllcm1hbiIgPGFuZHlAeXVtYXdvcmtzY29tPG1haWx0bzph bmR5QHl1bWF3b3Jrcy5jb20+Pg0KPiBUbzogInQucGV0Y2giIDxpZXRmY0BidGNvbm5lY3QuY29t PG1haWx0bzppZXRmY0BidGNvbm5lY3QuY29tPj4NCj4gU2VudDogTW9uZGF5LCBBdWd1c3QgMDMs IDIwMTUgNDoxMCBQTQ0KPg0KPiA+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4gPiBG cm9tOiAiQW5keSBCaWVybWFuIiBhbmR5QHl1bWF3b3Jrcy5jb208bWFpbHRvOmFuZHlAeXVtYXdv cmtzLmNvbT4NCj4gPiBTZW50OiBTYXR1cmRheSwgQXVndXN0IDAxLCAyMDE1IDc6MDUgUE0NCj4g PiBPbiBTYXQsIEF1ZyAxLCAyMDE1IGF0IDk6NTEgQU0sIEFjZWUgTGluZGVtIChhY2VlKSA8YWNl ZUBjaXNjby5jb208bWFpbHRvOmFjZWVAY2lzY28uY29tPj4NCj4gPg0KPj4+IE9uIDgvMS8xNSwg Mjo1MSBBTSwgIGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZTxtYWlsdG86ai5z Y2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPj4gd3JvdGU6DQo+Pj4NCj4+PiBTZWN0 aW9uIDEuMSBpbg0KPj4+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LW9wZW5jb25m aWctbmV0bW9kLW1vZGVsLXN0cnVjdHVyZS0wMC50eHQNCj4+PiBsaXN0cyB0aGUgZ29hbHMgb2Yg YSBnZW5lcmljIG1vZGVsIHN0cnVjdHVyZSB0aGF0IHdpbGwgYWNjb21tb2RhdGUNCj4+IG1vc3QN Cj4+PiBtb2Rlcm4gbmV0d29yayBkZXZpY2VzLiBJIGd1ZXNzIHlvdSBkb27igJl0IGFncmVlIHRo YXQgdGhlc2UgYXJlDQo+PiBkZXNpcmFibGU/DQo+ID4NCj4gPiBUaGUgb25seSBvYmplY3Rpb24g SSBoYXZlIHRvIHRoaXMgZHJhZnQgaXMgdGhlIGluc2VydGlvbiBvZiBhDQp0b3AtbGV2ZWwNCj4g PiByb290DQo+ID4gY2FsbGVkICJkZXZpY2UiLiAgKE1pZ2h0IGFzIHdlbGwgYmUgY2FsbGVkICJz ZWxmIikuDQo+ID4gVGhlcmUgYXJlIG5vIHNpYmxpbmcgbm9kZXMgcGxhbm5lZCBvciBpbnRlbmRl ZCBmb3INCj4gPiB0aGlzIG5vZGUsIHNvIGl0IHNlcnZlcyBhcyBhbiBleHRyYSBkb2N1bWVudCBy b290Lg0KPiA+DQo+ID4gPHRwPg0KPiA+IE9uZSBhc3BlY3Qgb2YgWUFORyBJIGhhdmUgbmV2ZXIg Z3Jhc3BlZCBpcyB3aGF0IGEgcm9vdCBtZWFucywgaWYNCj4gPiBhbnl0aGluZy4NCj4gPg0KPiA+ IEkgdW5kZXJzdGFuZCB0aGF0IGl0IGlzIG5lZWRlZCBmb3IgTkVUQ09ORiAoZmlsdGVycykgYW5k IGZvciBZQU5HDQo+ID4gKGF1Z21lbnRzLCBjb25zdHJhaW50cykgYW5kIHNvIG11c3QgYmUgc29t ZXdoZXJlIGFuZCBtdXN0IGJlDQo+IHJlbGF0aXZlbHkNCj4gPiBzdGFibGUsIGJ1dCBoYXMgaXQg YW55IG90aGVyIHNpZ25pZmljYW5jZSBpbiB0aGUgZGF0YSBtb2RlbD8NCj4gPg0KPiA+IEFzIHlv dSBtYXkgcmVjYWxsLCBJIHdhcyBpbnZvbHZlZCB3aXRoIFNNSSBmaXJzdCwgd2hlcmUgdGhlIHJv b3QgaXMNCj4gPiBzb21ld2hlcmUgdXAgaW4gdGhlIHNreSBhbmQgbGlmZSBvbmx5IGJlY29tZXMg aW50ZXJlc3Rpbmcgc29tZSBzaXgNCj4gPiBsZXZlbHMgZG93biB0aGUgaGllcmFyY2h5IGFuZCB0 aGF0IG1heSBjb2xvdXIgbXkgdGhpbmtpbmcuDQo+ID4NCj4NCj4gWUFORyBkb2VzIGEgcG9vciBq b2Igb2YgZGVmaW5pbmcgdGhlIHJvb3QgZm9yIFlBTkcgZGF0YSBub2Rlcy4NCj4gSXQgaXMgc29t ZXRpbWVzIGNhbGxlZCBhIGRhdGFzdG9yZSAoaW4gdGhlIGFic3RyYWN0KS4NCj4gVGVjaG5pY2Fs bHksIFlBTkcgYm9ycm93cyB0aGUgZGVmaW5pdGlvbiBmcm9tIFhQYXRoLg0KPiBZQU5HIGp1c3Qg ZGVmaW5lcyB0b3AtbGV2ZWwgZGF0YSBub2RlcyBhbmQgdGhlIHBhcmVudCBvZg0KPiB0aGVzZSBu b2RlcyBpcyB0aGUgZG9jdW1lbnQgcm9vdA0KPg0KPiBUaGVyZSBpcyBubyBwcm90b2NvbCBvciBl bmNvZGluZyBuZXV0cmFsIGRlZmluaXRpb24sDQo+IG9ubHkgYW4gWE1MLXNwZWNpZmljIGRlZmlu aXRpb24uDQo+DQo+IDx0cD4NCj4NCj4gVGhhbmtzIGZvciB0aGF0Lg0KPg0KPiBJdCBzZWVtcyB0 byBtZSB0aGF0IG11Y2ggb2YgdGhlIGV4dGVuc2l2ZSBkaXNjdXNzaW9uIG9uIFkzNCAoYWxsIG9m DQo+IHdoaWNoIEkgaGF2ZSByZWFkKSBpcyBhcyBtdWNoIHBvbGl0aWNhbCBhcyB0ZWNobmljYWws IHRoYXQgaXMgU01JIGlzDQo+IGhpZXJhcmNoaWNhbCwgdG9wIGRvd24sIHBlcmhhcHMgYmVmaXR0 aW5nIGl0cyBvcmlnaW5zIGluIElTTywgd2hlcmVhcw0KPiBZQU5HIGlzIGJvdHRvbSB1cC4gSUVU Ri1saWtlLiAgWUFORyBjb3VsZCBoYXZlIGhhZCBhIHNpbmdsZSB0cmVlLCBidXQNCj4gZG9lc24n dC4gIFNvIHdoZW4gSSByZWFkDQo+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LW9w ZW5jb25maWctbmV0bW9kLW1vZGVsLXN0cnVjdHVyZS0wMC50eHQNCj4NCj4gSSBzZWUgYSBwbGVh IGZvciBhIG1vcmUgaGllcmFyY2hpY2FsIG9yZ2FuaXNhdGlvbiwgYW5kIHdoZW4gSSByZWFkDQo+ DQo+IGRyYWZ0LWJqb3JrbHVuZC1uZXRtb2Qtb3BlbmNvbmZpZy1yZXBseS0wMA0KPg0KPiBJIHNl ZSBhIHJlc3BvbnNlIHRoYXQgc2F5cyB3ZSBhcmUgbm90IGxpa2UgdGhhdC4NCj4NCj4gSWYgc28s IEkgZG91YnQgdGhhdCB0aGVyZSBldmVyIHdpbGwgYmUgYSB0ZWNobmljYWwgc29sdXRpb24uDQo+ DQo+IEFuZCBJIGFtIG1pbmRmdWwgdGhhdCB3aGVuIEkgY29uZmlndXJlIHJvdXRpbmcgaW4gYSAo Q2lzY28pIHJvdXRlciwgSQ0KPiBoYXZlIHRvIGRvIHNvbWUgb2YgaXQgdW5kZXIgdGhlIGludGVy ZmFjZSBkZWZpbml0aW9ucyBhbmQgc29tZSBvZiBpdA0KPiB1bmRlciB0aGUgZGVmaW5pdGlvbiBv ZiB0aGUgcm91dGluZyBwcm90b2NvbC4gIFdoaWNoIGlzIGxpZmUsIG5ldmVyDQo+IHdob2x5IGlu dGVyZmFjZS1jZW50cmljIGFuZCBuZXZlciB3aG9seSByb3V0aW5nIHByb3RvY29sLWNlbnRyaWMh DQoNCkFyZSB5b3Ugc2F5aW5nIHRoZSBqb2Igd291bGQgYmUgZWFzaWVyIGlmIHRoZQ0KcGF0aCB3 YXMgL2RldmljZS9pbnRlcmZhY2VzL2ludGVyZmFjZSBpbnN0ZWFkDQpvZiBqdXN0IC9pbnRlcmZh Y2VzL2ludGVyZmFjZT8gIEFyZSB5b3Ugc2F5aW5nDQp0aGF0IC9wcm90b2NvbHMvcm91dGluZyBj b3VsZCBub3QgYWxzbyBiZSBkZWZpbmVkPw0KQ2xlYXJseSBlZGl0LWNvbmZpZyBhbmQgY29weS1j b25maWcgYWxsb3cgYm90aA0Kc3VidHJlZXMgdG8gYmUgYWNjZXNzZWQgaW4gdGhlIHNhbWUgb3Bl cmF0aW9uLA0Kc28gSSBkb24ndCB1bmRlcnN0YW5kIHlvdXIgY29uY2Vybi4NCg0KSSBoYXZlIGJl ZW4gdHJ5aW5nIHRvIGdldCB0aGUgcm9vdCBub2RlIHRvIGJlIGJldHRlciBkZWZpbmVkDQppbiB0 aGUgcHJvdG9jb2xzIHRoYXQgdXNlIFlBTkcgKGkuZS4sIG5jeDpyb290LCBZMzQtMDQpLg0KSU1P IHRoaXMgaXMgYSBiZXR0ZXIgYXBwcm9hY2ggdGhhbiBkZWZpbmluZyBhIFlBTkcgbW9kdWxlDQp3 aXRoIGEgc3BlY2lhbCBjb250YWluZXIgdGhhdCBhbGwgb3RoZXIgbW9kdWxlcyBhcmUgZXhwZWN0 ZWQNCnRvIGF1Z21lbnQuICBZQU5HIGlzIGRlc2lnbmVkIHN1Y2ggdGhhdCBlYWNoIHZlbmRvciBv ciBTRE8NCmlzIG5vdCBkZXBlbmRlbnQgb24gb3RoZXIgdmVuZG9ycyBvciBTRE9zIGluIG9yZGVy IHRvDQpkZWZpbmUgZGF0YSBub2Rlcy4NCg0KPHRwPg0KDQpBbmR5DQoNCkkgYW0gYWdyZWVpbmcg d2l0aCB5b3UgdGhhdCBhZGRpbmcgJ2RldmljZScgYnJpbmdzIG5vIHRlY2huaWNhbCBiZW5lZml0 LA0KcmF0aGVyIHRoYXQgdGhlIG1vdGl2YXRpb24gaXMgdGhlIG9wcG9zaXRlIG9mIHRlY2huaWNh bCAod2hpY2ggSQ0KcmVmZXJyZWQgdG8gYXMgcG9saXRpY2FsKS4gSSBhbSBhbHNvIGFncmVlaW5n IHdpdGggdGhlIGN1cnJlbnQgZGVjbGFyZWQNCmNvbnNlbnN1cyBvbiBZMzQuDQoNCkFuZCB5ZXMs IFlBTkcgaXMgZ29pbmcgdG8gZ2l2ZSB1cyBhIGxhcmdlIG51bWJlciBvZiBtb2R1bGVzLCBzb21l DQp0aWdodGx5IGNvdXBsZWQgKGF1Z21lbnRzKSBzb21lIGxvb3NlbHkgc28gKGhvdyBtYW55IGRv IHlvdSBuZWVkIHRvDQpjb25maWd1cmUgT1NQRj8pIGFuZCB3b3JrIGluIHRoaXMgYXJlYSB3aWxs IGJlIG9mIGJlbmVmaXQgbm93IGFuZA0KcHJvYmFibHkgZXNzZW50aWFsIGluIGEgZmV3IHllYXJz IHRpbWUuICBUaGF0IHNhaWQsIEkgYW0gdW5zdXJlIHdoYXQNCnN1Y2ggd29yayB3b3VsZCBiZSBs aWtlOyBJIGFtIGxvb2tpbmcgKGluIGRlc3BhaXIpIGF0IDUwIHJvdXRpbmcgYXJlYQ0KWUFORyBt b2RlbHMgYW5kIHdvbmRlcmluZyBob3cgYSB1c2VyIHdpbGwgZXZlciBnZXQgYSBjb2hlcmVudCBw aWN0dXJlIG9mDQpob3cgdG8gZG8gd2hhdCB0aGV5IHdhbnQgdG8gZG8uDQoNCg0KDQpUaGUgIllB TkcgTGFuZCBHcmFiIiBnaXZlcyBhIGZhbHNlIHNlbnNlIG9mIHByb2dyZXNzLg0KUmVhY2hpbmcg V0cgY29uc2Vuc3VzIG9uIGV2ZXJ5IHNpbmdsZSBsZWFmIGlzIGhhcmQgd29yay4NCg0KSSBkb24n dCB0aGluayBhIGNvbGxlY3Rpb24gb2YgMTAwcyBvZiBZQU5HIG1vZHVsZXMgaXMgZXZlcg0KZ29p bmcgdG8gdG8gYmUgZWFzeSB0byB1bmRlcnN0YW5kLiAgT3BlcmF0b3JzIHdpbGwgbm90IGV4YW1p bmUNCmEgTkVUQ09ORiA8aGVsbG8+IG1lc3NhZ2UsIGxvb2sgYXQgMTUwIG1vZHVsZSBVUklzLA0K YW5kIHNheSAiSSBrbm93IGV4YWN0bHkgd2hhdCB0aGlzIGRldmljZSBzdXBwb3J0cyIuDQpJIGd1 ZXNzIGl0IGlzIHVwIHRvIGNsaWVudCB0b29scyB0byBkbyB0aGF0DQoNCkkgd3JvdGUgYSBkcmFm dCB0aGF0IGRlZmluZXMgWUFORyBQYWNrYWdlcywgd2hpY2ggY2FuIHByb3ZpZGUNCmEgaGlnaGVy IGxldmVsIG9mIG9yZ2FuaXphdGlvbiBmb3IgWUFORyBtb2R1bGVzLg0KDQpodHRwOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJpZXJtYW4tbmV0bW9kLXlhbmctcGFja2FnZS8NCg0K WW91IGFuZCBJIGFyZSBhcHBhcmVudGx5IGluIHRoZSBtaW5vcml0eSwgc2luY2UgdGhlIG9mZmlj aWFsIHN0YXR1cw0KaXMgdGhhdCB0aGVyZSBpcyBubyBwcm9ibGVtIHdpdGggdGhlIGN1cnJlbnQg YXBwcm9hY2gsIGFuZCBubyBuZWVkDQp0byBvcmdhbml6ZSBpbmRpdmlkdWFsIFlBTkcgbW9kdWxl cyBpbnRvIGFueSBsYXJnZXIgYWJzdHJhY3Rpb25zLg0KDQoNCg0KIFRvbSBQZXRjaA0KDQoNCg0K QW5keQ0KDQpBbmR5DQoNCj4gQW5keQ0KPg0KPiA+IFRoZSB3ZWxsLXNwZWNpZmllZCBYUGF0aCBh bmQgWUFORyByb290ICgvKSBjYW4gYmUNCj4gPiBhY2Nlc3NlZCBieSBhbGwgcHJvdG9jb2wgb3Bl cmF0aW9ucywgZXhhY3RseSB0aGUgc2FtZQ0KPiA+IGFzIGEgbm9kZSBjYWxsZWQgJ2RldmljZScu ICBUaGUgYWN0dWFsIG5vZGUgbmFtZSB3aWxsDQo+ID4gZGVwZW5kIG9uIHRoZSBSUEMgZnVuY3Rp b24gKGUuZy4gJ2RhdGEnIG9yICdjb25maWcnKS4NCj4gPg0KPiA+IFRoaXMgaXMgbW9yZSB0aGFu IHJlZHVuZGFudCBob3dldmVyLiAgSXQgaW50cm9kdWNlcyBhICJzdXBlci1tb2R1bGUiDQo+ID4g aW50byBZQU5HIHRoYXQgZXZlcnkgb3RoZXIgbW9kdWxlIGlzIGV4cGVjdGVkIHRvIGF1Z21lbnQu DQo+ID4gWUFORyBpcyBpbnRlbmRlZCB0byBiZSBtb3JlIGxvb3NlbHkgY291cGxlZCB0aGFuIHRo YXQuDQo+ID4gVGhpcyBpbnRyb2R1Y2VzIGFuIGV4dHJhIG5vZGUgYW5kIG5hbWVzcGFjZSBkZWNs YXJhdGlvbg0KPiA+IGluIGFsbCBwcm90b2NvbCBtZXNzYWdlcywgaW5jcmVhc2luZyBtZXNzYWdl IHNpemVzLg0KPiA+DQo+ID4gSXQgYWxzbyBhc3N1bWVzIGFsbCBleGlzdGluZyBZQU5HIG1vZGVs cyB3aWxsIGdldCByZXdyaXR0ZW4gdG8NCj4gPiBhY2NvdW50IGZvciAiL2RldmljZSIgaW4gYWxs IHBhdGggYW5kIFhQYXRoIGV4cHJlc3Npb25zLg0KPiA+IFRoaXMgaXMgaGlnaGx5IGRpc3J1cHRp dmUgdG8gZXhpc3RpbmcgZGVwbG95bWVudHMuDQo+ID4gQWxzbywgbXVsdGlwbGUgZGF0YSBtb2Rl bHMgdG8gZWRpdCB0aGUgc2FtZSB0aGluZyBjYXVzZXMgbG90cw0KPiA+IG9mIGV4dHJhIGNvbXBs ZXhpdHkgaW4gdGhlIHNlcnZlciAoc3VwcG9ydGluZyBib3RoIG9sZA0KPiA+IGxvY2F0aW9uIGFu ZCBuZXcgbG9jYXRpb24pLg0KPiA+DQo+ID4gSU1PIGEgcmVzb3VyY2UgZGlyZWN0b3J5IGFwcHJv YWNoIGlzIG11Y2ggbW9yZSByZWFsaXN0aWMuDQo+ID4gVGhlIC9kZXZpY2UgdHJlZSBjYW4gY29u dGFpbiBhbGwgdGhlIG9yZ2FuaXplZCBOUCBjb250YWluZXJzLg0KPiA+IEluc3RlYWQgb2YgYWxs IHRoZSBhY3R1YWwgZGF0YSBub2RlcywgdGhpcyB0cmVlIGp1c3QgaGFzIHBvaW50ZXJzDQo+ID4g dG8gdGhlIHJlYWwgbG9jYXRpb24gb2YgdGhlIHJlc291cmNlLiAobGlrZSAzMDEgTW92ZWQgUGVy bWFuZW50bHkpDQo+ID4NCj4gPiA+IEFjZWUNCj4gPiA+DQo+ID4gQW5keQ0KDQoNCioqIFNvbHV0 aW9uIFkzNC0wMg0KDQogIEtlZXAgJ2FueXhtbCcuICBJbnRyb2R1Y2UgJ2FueWRhdGEnIGFzIGFi b3ZlIGJ1dCB3aXRob3V0IHRoZQ0KICAnZm9ybWF0JyBzdWJzdGF0ZW1lbnQuDQoNCiAgJ2FueXht bCcgd291bGQgc3RpbGwgYmUgdXNlZCB0byByZXByZXNlbnQgdW5yZXN0cmljdGVkIFhNTCwgYXMg aXMNCiAgZG9uZSBpbiBORVRDT05GLg0KDQogICdhbnlkYXRhJyB3b3VsZCBiZSBhbiB1bmtub3du IGNodW5rIG9mIGRhdGEgdGhhdCBjYW4gYmUgbW9kZWxsZWQNCiAgd2l0aCBZQU5HLiAgQ2FuIGJl IGVuY29kZWQgYXMgeG1sIG9yIGpzb24uDQoNCiAgRm9yIGV4YW1wbGU6DQoNCiAgICAjK0JFR0lO X0VYQU1QTEUNCiAgICBhbnlkYXRhIGRhdGE7DQogICAgIytFTkRfRVhBTVBMRQ0KDQoqKiBTb2x1 dGlvbiBZMzQtMDUNCg0KICAgU2FtZSBhcyBZMzQtMDIgcGx1cyB0d28gZ3VpZGVsaW5lcyBhZG9w dGVkIGZyb20gWTM0LTA0Og0KDQogICAtIEtlZXAgJ2FueXhtbCcgdW5jaGFuZ2VkIGFzIGl0IGlz IGRlZmluZWQgaW4gWUFORyAxLjAuIFRoaXMNCiAgICAgZW5zdXJlcyBiYWNrd2FyZCBjb21wYXRp YmlsaXR5Lg0KICAgLSBJbnRyb2R1Y2UgYSBuZXcgJ2FueWRhdGEnIHN0YXRlbWVudCB0aGF0IHJl cHJlc2VudHMgYW4gdW5rbm93bg0KICAgICBjaHVuayBvZiBkYXRhIHRoYXQgY2FuIGJlIG1vZGVs ZWQgd2l0aCBZQU5HDQogICAtIERvY3VtZW50IHRoYXQgaW1wbGVtZW50YXRpb25zIE1BWSBoYXZl IHJlc3RyaWN0aW9ucyBmb3IgYW55eG1sIGFuZA0KICAgICB0aGF0IGFueXhtbCBpcyBub3QgbmVj ZXNzYXJpbHkgaW50ZXJvcGVyYWJsZTsgZGF0YSBtb2RlbCB3cml0ZXJzDQogICAgIHNob3VsZCB1 c2UgYW55ZGF0YSB3aGVuZXZlciBwb3NzaWJsZS4NCiAgIC0gVGhlIGd1aWRlbGluZXMgZG9jdW1l bnQgc2hvdWxkIHNheSB0aGF0IFlBTkcgRG9jdG9ycyB3aWxsIHJldmlldw0KICAgICBlYWNoIHVz ZSBvZiBhbnl4bWwgaW4gSUVURiBtb2R1bGVzIHdoZW4gWUFORyAxLjEgaXMgYWRvcHRlZCB0bw0K ICAgICBhdm9pZCBpdHMgdXNlIHdoZW5ldmVyIHBvc3NpYmxlLg0KDQoNCj4NCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcg bGlzdA0KbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQoNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCm5l dG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0KDQo= --_000_D1EE8D652AAEAaceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <5E2525ED9406DE4C8B8DA1024BBC3CC5@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0K PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxp Z246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVIt TEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGlu OyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JE RVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJm b250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+QW5keSBCaWVybWFuICZsdDs8YSBocmVmPSJt YWlsdG86YW5keUB5dW1hd29ya3MuY29tIj5hbmR5QHl1bWF3b3Jrcy5jb208L2E+Jmd0Ozxicj4N CjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+TW9uZGF5LCBBdWd1 c3QgMTAsIDIwMTUgYXQgNDoxNSBQTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk Ij5UbzogPC9zcGFuPkFjZWUgTGluZGVtICZsdDs8YSBocmVmPSJtYWlsdG86YWNlZUBjaXNjby5j b20iPmFjZWVAY2lzY28uY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6 Ym9sZCI+Q2M6IDwvc3Bhbj4mcXVvdDtFaW5hciBOaWxzZW4tTnlnYWFyZCAoZWluYXJubikmcXVv dDsgJmx0OzxhIGhyZWY9Im1haWx0bzplaW5hcm5uQGNpc2NvLmNvbSI+ZWluYXJubkBjaXNjby5j b208L2E+Jmd0OywgSm9uYXRoYW4gSGFuc2ZvcmQgJmx0OzxhIGhyZWY9Im1haWx0bzpqb25hdGhh bkBoYW5zZm9yZHMubmV0Ij5qb25hdGhhbkBoYW5zZm9yZHMubmV0PC9hPiZndDssIE5FVE1PRCBX b3JraW5nIEdyb3VwICZsdDs8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIj5uZXRtb2RA aWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJq ZWN0OiA8L3NwYW4+UmU6IFtuZXRtb2RdIFkzNCAtIHJvb3Qgbm9kZTxicj4NCjwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9C TE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzow IDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj48 YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVv dGUiPk9uIE1vbiwgQXVnIDEwLCAyMDE1IGF0IDEyOjM0IFBNLCBBY2VlIExpbmRlbSAoYWNlZSkg PHNwYW4gZGlyPSJsdHIiPg0KJmx0OzxhIGhyZWY9Im1haWx0bzphY2VlQGNpc2NvLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmFjZWVAY2lzY28uY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4NCjxi bG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2Jv cmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBzdHlsZT0i d29yZC13cmFwOmJyZWFrLXdvcmQ7Y29sb3I6cmdiKDAsMCwwKTtmb250LXNpemU6MTRweDtmb250 LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWYiPg0KPGRpdj5JIHRoaW5rIHRoZXJlIGlzIGFncmVl bWVudCB0aGF0IHRoZXJlIGlzIGEgcHJvYmxlbS4gVGhlIFlBTkcgUm91dGluZyBEZXNpZ24gVGVh bSBpcyAmbmJzcDthZGRyZXNzaW5nIHRoaXMgd2l0aA0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvaWQvZHJhZnQtcnRneWFuZ2R0LXJ0Z3dnLWRldmljZS1tb2RlbC0wMC50eHQiIHRhcmdl dD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXJ0Z3lhbmdkdC1ydGd3 Zy1kZXZpY2UtbW9kZWwtMDAudHh0PC9hPiAmbmJzcDsod2hpY2ggaGFzIGV2b2x2ZWQgZnJvbSZu YnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LW9wZW5jb25maWctbmV0 bW9kLW1vZGVsLXN0cnVjdHVyZS0wMC50eHQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9pZC9kcmFmdC1vcGVuY29uZmlnLW5ldG1vZC1tb2RlbC1zdHJ1Y3R1cmUtMDAudHh0 PC9hPikuDQogSW4gZXNzZW5jZSwgYSBwbGFjZSBmb3IgZXZlcnl0aGluZyBhbmQgZXZlcnl0aGlu ZyBpbiBpdHMgcGxhY2UuIEhvd2V2ZXIsIHRoZXJlIGFyZSB0aG9zZSB3aG8gZmVlbCB0aGF0IGNh buKAmXQgbWFuZGF0ZSBhIHNpbmdsZSBtb2RlbCBzdHJ1Y3R1cmUgZm9yIG5ldHdvcmsgZGV2aWNl cyBhbmQgd2UgbmVlZCBtZWNoYW5pc21zIHRvIG1hbmFnZSBtdWx0aXBsZSBtb2RlbHMgYnV0IGFs bG93IGZvciBkaWZmZXJlbnQgZGV2aWNlIHN0cnVjdHVyZSAoZS5nLiwNCjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWJpZXJtYW4tbmV0bW9kLXlhbmctcGFja2FnZS0wMC50 eHQiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWJpZXJt YW4tbmV0bW9kLXlhbmctcGFja2FnZS0wMC50eHQ8L2E+KS4mbmJzcDsgSSBob3BlIHdlIGNhbiBh Z3JlZSBvbiBhbiBhcHByb2FjaCBpbiB0aGUgY29taW5nIGludGVyaW0gbWVldGluZ3MuJm5ic3A7 PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdj5EbyB5b3UgZXhwZWN0ICZxdW90O2V2ZXJ5dGhpbmcgaW4gaXRzIHBs YWNlJnF1b3Q7IHRvIGFwcGx5IHRvIGFsbCBvdGhlciBTRE9zIGFuZDwvZGl2Pg0KPGRpdj5hbGwg dmVuZG9yIG1vZHVsZXM/IE9yIGRvIHlvdSBleHBlY3QganVzdCB0aGUgSUVURiByb3V0aW5nIG1v ZHVsZXM8L2Rpdj4NCjxkaXY+dG8gZm9sbG93IHRoaXMgc3VidHJlZSBoaWVyYXJjaHk/IElmIHRo ZSBmb3JtZXIsIGRvZXMgdGhpcyBtZWFuIHRoZTwvZGl2Pg0KPGRpdj5ZQU5HIFJvdXRpbmcgRGVz aWduIFRlYW0gaXMgdGhlICZxdW90O1lBTkcgZGF0YSBwbGFjZW1lbnQgYXV0aG9yaXR5JnF1b3Q7 Jm5ic3A7PC9kaXY+DQo8ZGl2Pm9yIGFsbCBZQU5HIG1vZHVsZXMgdGhhdCBldmVyIGdldCB3cml0 dGVuPyBIb3cgbG9uZyBzaG91bGQ8L2Rpdj4NCjxkaXY+aXQgdGFrZSBmb3IgYWxsIG90aGVyIFNE T3MgYW5kIHZlbmRvcnMgdG8gcmVkbyBhbGwgdGhlaXIgZXhpc3Rpbmc8L2Rpdj4NCjxkaXY+bW9k dWxlcyB0byByZS1yb290IHRoZW0gaW4gdGhlaXIgYXNzaWduZWQgcGxhY2UgaW4gdGhlIGRhdGEg dHJlZT88L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L3NwYW4+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5J4oCZZCBleHBlY3Qg dGhlIGZpbmFsIGRvY3VtZW50IHRvIGJlIGEgcHJvZHVjdCBvZiB0aGUgbmV0bW9kIFdHIGFuZCwg Y29uc2VxdWVudGx5LCBoYXZlIHdpZGUgcmV2aWV3IGFuZCBhcHByb3ZhbC4gV2UgYXJlIGNvbnNp ZGVyaW5nIHNvbWUgY2hhbmdlcyB0byBzcGVjaWZ5IGFuIGlkZW50aWZ5IGZvciBhIGNsYXNzIG9m IGRhdGEgbW9kZWwgcmF0aGVyIHRoYW4gdHJ5aW5nIHRvIHNwZWNpZnkgc3BlY2lmaWMgbW9kZWxz LiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QXMgZm9yIG90aGVyIFNET3Mg YW5kIHRoZWlyIFlBTkcgbW9kZWxzLCB3ZSBjYW4gc3VnZ2VzdCBwbGFjZW1lbnQgYnV0IHdlIHJl YWxseSBjYW4gZXZlbiBmb3JjZSB0aGVtIHRvIHVzZSBvdXIgYnVpbGRpbmcgYmxvY2tzLiZuYnNw OzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElP TiI+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIg c3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFS R0lOOjAgMCAwIDU7Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGNsYXNz PSJnbWFpbF9leHRyYSI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj5JTU8gaXMgaXMgbm90IGEgZ29vZCBpZGVhIHRvIHJlbHkgb24gcmlnaWQgZGF0 YSBub2RlIHBsYWNlbWVudCw8L2Rpdj4NCjxkaXY+YW5kIGEgc2luZ2xlIGRhdGEgcGxhY2VtZW50 IGF1dGhvcml0eS4gSXQgaXMgYmV0dGVyIGFuZCB1c2UgbWV0YS1kYXRhPC9kaXY+DQo8ZGl2PmJ1 aWx0IGZyb20gdGhlIFlBTkcgbW9kdWxlcyAob3IgWUFORyBwYWNrYWdlcykgaW5zdGVhZC48L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L3NwYW4+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JIGd1ZXNzIHdl4oCZcmUgZ29pbmcg dG8gaGF2ZSB0byBzZWUgdGhlIHByb2dyYW1taW5nIG1vZGVsIGZvciB0aGlzLiBGaXhlZCBwYXRo cyBkbyBwcm92aWRlIGEgY2xlYW4gcHJvZ3JhbW1pbmcgbW9kZWwuJm5ic3A7PC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxibG9ja3F1 b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVS LUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsi Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJh Ij4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRo ZSByZWFzb24gTGludXggdXNlcyBwYWNrYWdlcyB0byBpbnN0YWxsL3VwZGF0ZSBmdW5jdGlvbmFs aXR5PC9kaXY+DQo8ZGl2PmlzIGJlY2F1c2UgbWFuYWdpbmcgODAwMCBwYWNrYWdlcyBpcyBoYXJk IGVub3VnaC48L2Rpdj4NCjxkaXY+TWFuYWdpbmcgMjQ3LDAwMCBpbmRpdmlkdWFsIGZpbGVzIHdv dWxkIGJlIGluc2FuZS48L2Rpdj4NCjxkaXY+VGhlIGFjdHVhbCBsb2NhdGlvbiBvZiBmaWxlcyBp cyBxdWl0ZSBjb25maWd1cmFibGUgYW5kIGRpZmZlcmVudDwvZGl2Pg0KPGRpdj5hY3Jvc3MgZGlz dHJvcy4gV2UgY291bGQgbGVhcm4gc29tZXRoaW5nIGZyb20gdGhlIGxhc3QgZGVjYWRlPC9kaXY+ DQo8ZGl2Pm9mIExpbnV4IHBhY2thZ2UgbWFuYWdlbWVudCwgYW5kIHRyeSB0byBhcHBseSBpdCB0 byBZQU5HLjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvc3Bhbj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pkkgd2lsIGdpdmUg eW91ciBkcmFmdCBhIGNsb3NlciByZWFkLiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+VGhhbmtzLDwvZGl2Pg0KPGRpdj5BY2VlJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+ DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5 bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lO OjAgMCAwIDU7Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGNsYXNzPSJn bWFpbF9leHRyYSI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBjbGFz cz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHgg I2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDpicmVh ay13b3JkO2NvbG9yOnJnYigwLDAsMCk7Zm9udC1zaXplOjE0cHg7Zm9udC1mYW1pbHk6Q2FsaWJy aSxzYW5zLXNlcmlmIj4NCjxkaXY+PC9kaXY+DQo8ZGl2PlRoYW5rcyw8L2Rpdj4NCjxkaXY+QWNl ZSAmbmJzcDs8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkFuZHk8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8 YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDti b3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgc3R5bGU9 IndvcmQtd3JhcDpicmVhay13b3JkO2NvbG9yOnJnYigwLDAsMCk7Zm9udC1zaXplOjE0cHg7Zm9u dC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmIj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuPg0KPGRpdiBzdHlsZT0iZm9udC1m YW1pbHk6Q2FsaWJyaTtmb250LXNpemU6MTFwdDt0ZXh0LWFsaWduOmxlZnQ7Y29sb3I6YmxhY2s7 Qk9SREVSLUJPVFRPTTptZWRpdW0gbm9uZTtCT1JERVItTEVGVDptZWRpdW0gbm9uZTtQQURESU5H LUJPVFRPTTowaW47UEFERElORy1MRUZUOjBpbjtQQURESU5HLVJJR0hUOjBpbjtCT1JERVItVE9Q OiNiNWM0ZGYgMXB0IHNvbGlkO0JPUkRFUi1SSUdIVDptZWRpdW0gbm9uZTtQQURESU5HLVRPUDoz cHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5uZXRtb2Qg Jmx0OzxhIGhyZWY9Im1haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPm5ldG1vZC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9mICZxdW90O0Vp bmFyIE5pbHNlbi1OeWdhYXJkIChlaW5hcm5uKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVp bmFybm5AY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZWluYXJubkBjaXNjby5jb208L2E+Jmd0 Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+TW9uZGF5 LCBBdWd1c3QgMTAsIDIwMTUgYXQgNToyOSBBTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdo dDpib2xkIj5UbzogPC9zcGFuPkpvbmF0aGFuIEhhbnNmb3JkICZsdDs8YSBocmVmPSJtYWlsdG86 am9uYXRoYW5AaGFuc2ZvcmRzLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmpvbmF0aGFuQGhhbnNmb3Jk cy5uZXQ8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzogPC9z cGFuPk5FVE1PRCBXb3JraW5nIEdyb3VwICZsdDs8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+bmV0bW9kQGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBz dHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJlOiBbbmV0bW9kXSBZMzQg LSByb290IG5vZGU8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iQk9SREVSLUxFRlQ6I2I1YzRkZiA1IHNvbGlkO1BBRERJTkc6MCAwIDAgNTtNQVJHSU46 MCAwIDAgNSI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPkFzIHNv bWVvbmUgc2hhcmluZyByZXNwb25zaWJpbGl0aWVzIGZvciBndWlkaW5nIGEgbnVtYmVyIG9mIGRl dmVsb3BtZW50IHRlYW1zIGJvdGggZGVmaW5pbmcgbmV3IG1vZGVscyBhbmQgaW1wbGVtZW50aW5n IHRvIHNvbWUgYWxyZWFkeSBkZWZpbmVkIG1vZGVscyBpbiB0aGlzIGFyZWEsIEkgY2FuIG9ubHkg YWdyZWUgd2l0aCB0aGlzIGFkZGl0aW9uIHRvIHdoYXQgSSBzYWlkIGVhcmxpZXIuDQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdj5DaGVlcnMsPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5F aW5hcjxicj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPg0KPGRpdj5PbiBBdWcgMTAsIDIwMTUsIGF0IDk6NDYgQU0sIEpvbmF0aGFuIEhh bnNmb3JkICZsdDs8YSBocmVmPSJtYWlsdG86am9uYXRoYW5AaGFuc2ZvcmRzLm5ldCIgdGFyZ2V0 PSJfYmxhbmsiPmpvbmF0aGFuQGhhbnNmb3Jkcy5uZXQ8L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxi cj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTonSGVsdmV0aWNhIE5ldWUnLEhlbHZl dGljYSxBcmlhbCxzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxMnB4Ij4NCiZuYnNwO0FuZCBpdCBpcyBu b3QganVzdCBlbmQgdXNlcnMgd2hvIG5lZWQgaGVscCB0byBiZXR0ZXIgdW5kZXJzdGFuZCBZQU5H IG1vZGVscyBhbmQgaG93IHRvIHVzZSB0aGVtLiBGb3IgdGhvc2Ugc3RpbGwgb24gdGhlIGVkZ2Us IGxvb2tpbmcgdG8gZmluYWxseSB0YWtlIHRoZSBwbHVuZ2UgYW5kIHVzZSBORVRDT05GL1lBTkcg dG8gY29uZmlndXJlIHRoZWlyIGRldmljZXMsIGhlbHAgaXMgYWxzbyByZXF1aXJlZCB0byBkZXRl cm1pbmUgaG93IGJlc3QgdG8NCiBzdHJ1Y3R1cmUgdGhlaXIgWUFORyBtb2RlbHMsIG1ha2UgdXNl IG9mIHRoZSBleGlzdGluZyBvbmVzLCBldGMuIEZvciB0aG9zZSB3aG8gaGF2ZSAmcXVvdDtncm93 biB1cCZxdW90OyB3aXRoIHRoZSBkZXZlbG9wbWVudHMgaW4gTkVUQ09ORiBhbmQgWUFORywgbXVj aCBvZiB0aGlzIGlzIHByb2JhYmx5IHNlY29uZCBuYXR1cmUuIEJ1dCBjb21pbmcgdG8gaXQgY29s ZCAoaW4gdGhlIHNlbnNlIG9mIGNvbXBpbGluZy93cml0aW5nIGEgZmlyc3Qgc2V0IG9mIFlBTkcg bW9kZWxzDQogZm9yIGEgZGV2aWNlOyBJJ3ZlIGJlZW4gZm9sbG93aW5nIHRoZSBuZXRjb25mL25l dG1vZCBXR3MgZm9yIDMmIzQzOyB5ZWFycyksIGl0IHN0aWxsIGZlZWxzIHZlcnkgbXVjaCBsaWtl IGEgZGFyayBhcnQhIEl0IGlzIG5vdCBqdXN0IHRoZSBpbmRpdmlkdWFsIG1vZHVsZXMsIGl0IGlz IGhvdyB0byBwdXQgdGhlbSB0b2dldGhlciB0byBiZXN0IG1hbmFnZSBhIGRldmljZSAobGV0IGFs b25lIGEgc3lzdGVtKS4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkpvbmF0aGFuPGJyPg0KPGJy Pg0KPGJyPg0KPGJsb2NrcXVvdGU+PGJyPg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLTxi cj4NCjxkaXYgc3R5bGU9IndpZHRoOjEwMCU7YmFja2dyb3VuZDpyZ2IoMjI4LDIyOCwyMjgpIj4N CjxkaXYgc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206PC9kaXY+DQomcXVvdDtFaW5hciBO aWxzZW4tTnlnYWFyZCAoZWluYXJubikmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzplaW5hcm5u QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmVpbmFybm5AY2lzY28uY29tPC9hPiZndDs8L2Rp dj4NCjxicj4NCjxkaXYgc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOjwvZGl2Pg0KJnF1b3Q7 QW5keSBCaWVybWFuJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YW5keUB5dW1hd29ya3MuY29t IiB0YXJnZXQ9Il9ibGFuayI+YW5keUB5dW1hd29ya3MuY29tPC9hPiZndDs8YnI+DQo8ZGl2IHN0 eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzo8L2Rpdj4NCiZxdW90O05FVE1PRCBXb3JraW5nIEdy b3VwJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+bmV0bW9kQGlldGYub3JnPC9hPiZndDs8YnI+DQo8ZGl2IHN0eWxlPSJmb250LXdlaWdo dDpib2xkIj5TZW50OjwvZGl2Pg0KU2F0LCA4IEF1ZyAyMDE1IDExOjEwOjE1ICYjNDM7MDAwMDxi cj4NCjxkaXYgc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6PC9kaXY+DQpSZTogW25l dG1vZF0gWTM0IC0gcm9vdCBub2RlPGJyPg0KPGJyPg0KPGJyPg0KQW5keSwNCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2PkkgYWdyZWUgdGhhdCB0aGVyZSBpcyBhIG5lZWQgZm9yIG9yZ2FuaXphdGlv biBvZiBtb2RlbHMsIGJ1dCBJIGRvbuKAmXQgaGF2ZSBhIGZpcm0gcG9zaXRpb24gb24mbmJzcDtk cmFmdC1vcGVuY29uZmlnLW5ldG1vZC1tb2RlbC1zdHJ1Y3R1cmUvZHJhZnQtcnRneWFuZ2R0LXJ0 Z3dnLWRldmljZS1tb2RlbCBvciZuYnNwO2RyYWZ0LWJpZXJtYW4tbmV0bW9kLXlhbmctcGFja2Fn ZS4gQnV0IHdlIGFic29sdXRlbHkgbmVlZCAqc29tZXRoaW5nKiB0byBoZWxwIGVuZC11c2Vycw0K IG9mIHRoZSBtb2RlbHMgY29tcHJlaGVuZCB0aGUgb3ZlcmFsbCBzdHJ1Y3R1cmUgb2YgbW9kZWxz LCB0aGVpciByZWxhdGlvbnNoaXAgYW5kIGhvdyB0byB1c2UgdGhlbS48L2Rpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8ZGl2PkNoZWVycyw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkVp bmFyPC9kaXY+DQo8ZGl2Pjxicj4NCjxkaXY+DQo8YmxvY2txdW90ZT4NCjxkaXY+T24gQXVnIDQs IDIwMTUsIGF0IDU6MTYgUE0sIEFuZHkgQmllcm1hbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFuZHlA eXVtYXdvcmtzLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFuZHlAeXVtYXdvcmtzLmNvbTwvYT4mZ3Q7 IHdyb3RlOjwvZGl2Pg0KPGJyPg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPjxicj4NCjxkaXYgY2xh c3M9ImdtYWlsX2V4dHJhIj48YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gVHVlLCBB dWcgNCwgMjAxNSBhdCAyOjM0IEFNLCB0LnBldGNoIDxzcGFuIGRpcj0ibHRyIj4NCiZsdDs8YSBo cmVmPSJtYWlsdG86aWV0ZmNAYnRjb25uZWN0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmlldGZjQGJ0 Y29ubmVjdC5jb208L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPg0KPGJsb2NrcXVvdGUgY2xhc3M9 ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNj Y2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0t PGJyPg0KRnJvbTogJnF1b3Q7QW5keSBCaWVybWFuJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86 YW5keUB5dW1hd29ya3MuY29tIiB0YXJnZXQ9Il9ibGFuayI+YW5keUB5dW1hd29ya3MuY29tPC9h PiZndDs8YnI+DQpUbzogJnF1b3Q7dC5wZXRjaCZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmll dGZjQGJ0Y29ubmVjdC5jb20iIHRhcmdldD0iX2JsYW5rIj5pZXRmY0BidGNvbm5lY3QuY29tPC9h PiZndDs8YnI+DQpTZW50OiBNb25kYXksIEF1Z3VzdCAwMywgMjAxNSA1OjE3IFBNPGJyPg0KPGJy Pg0KJmd0OyAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tPGJyPg0KJmd0OyBGcm9tOiAmcXVv dDtBbmR5IEJpZXJtYW4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzphbmR5QHl1bWF3b3Jrcy5j b20iIHRhcmdldD0iX2JsYW5rIj5hbmR5QHl1bWF3b3Jrc2NvbTwvYT4mZ3Q7PGJyPg0KJmd0OyBU bzogJnF1b3Q7dC5wZXRjaCZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGZjQGJ0Y29ubmVj dC5jb20iIHRhcmdldD0iX2JsYW5rIj5pZXRmY0BidGNvbm5lY3QuY29tPC9hPiZndDs8YnI+DQom Z3Q7IFNlbnQ6IE1vbmRheSwgQXVndXN0IDAzLCAyMDE1IDQ6MTAgUE08YnI+DQomZ3Q7PGJyPg0K Jmd0OyAmZ3Q7IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS08YnI+DQomZ3Q7ICZndDsgRnJv bTogJnF1b3Q7QW5keSBCaWVybWFuJnF1b3Q7IDxhIGhyZWY9Im1haWx0bzphbmR5QHl1bWF3b3Jr cy5jb20iIHRhcmdldD0iX2JsYW5rIj5hbmR5QHl1bWF3b3Jrcy5jb208L2E+PGJyPg0KJmd0OyAm Z3Q7IFNlbnQ6IFNhdHVyZGF5LCBBdWd1c3QgMDEsIDIwMTUgNzowNSBQTTxicj4NCiZndDsgJmd0 OyBPbiBTYXQsIEF1ZyAxLCAyMDE1IGF0IDk6NTEgQU0sIEFjZWUgTGluZGVtIChhY2VlKSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmFjZWVAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+YWNlZUBjaXNj by5jb208L2E+Jmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBPbiA4LzEvMTUs IDI6NTEgQU0sJm5ic3A7IDxhIGhyZWY9Im1haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVu aXZlcnNpdHkuZGUiIHRhcmdldD0iX2JsYW5rIj4NCmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5p dmVyc2l0eS5kZTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 Jmd0OyBTZWN0aW9uIDEuMSBpbjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtb3BlbmNvbmZpZy1uZXRtb2QtbW9kZWwtc3Ry dWN0dXJlLTAwLnR4dCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQv ZHJhZnQtb3BlbmNvbmZpZy1uZXRtb2QtbW9kZWwtc3RydWN0dXJlLTAwLnR4dDwvYT48YnI+DQom Z3Q7Jmd0OyZndDsgbGlzdHMgdGhlIGdvYWxzIG9mIGEgZ2VuZXJpYyBtb2RlbCBzdHJ1Y3R1cmUg dGhhdCB3aWxsIGFjY29tbW9kYXRlPGJyPg0KJmd0OyZndDsgbW9zdDxicj4NCiZndDsmZ3Q7Jmd0 OyBtb2Rlcm4gbmV0d29yayBkZXZpY2VzLiBJIGd1ZXNzIHlvdSBkb27igJl0IGFncmVlIHRoYXQg dGhlc2UgYXJlPGJyPg0KJmd0OyZndDsgZGVzaXJhYmxlPzxicj4NCiZndDsgJmd0Ozxicj4NCiZn dDsgJmd0OyBUaGUgb25seSBvYmplY3Rpb24gSSBoYXZlIHRvIHRoaXMgZHJhZnQgaXMgdGhlIGlu c2VydGlvbiBvZiBhPGJyPg0KdG9wLWxldmVsPGJyPg0KJmd0OyAmZ3Q7IHJvb3Q8YnI+DQomZ3Q7 ICZndDsgY2FsbGVkICZxdW90O2RldmljZSZxdW90Oy4mbmJzcDsgKE1pZ2h0IGFzIHdlbGwgYmUg Y2FsbGVkICZxdW90O3NlbGYmcXVvdDspLjxicj4NCiZndDsgJmd0OyBUaGVyZSBhcmUgbm8gc2li bGluZyBub2RlcyBwbGFubmVkIG9yIGludGVuZGVkIGZvcjxicj4NCiZndDsgJmd0OyB0aGlzIG5v ZGUsIHNvIGl0IHNlcnZlcyBhcyBhbiBleHRyYSBkb2N1bWVudCByb290Ljxicj4NCiZndDsgJmd0 Ozxicj4NCiZndDsgJmd0OyAmbHQ7dHAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IE9uZSBhc3BlY3Qgb2Yg WUFORyBJIGhhdmUgbmV2ZXIgZ3Jhc3BlZCBpcyB3aGF0IGEgcm9vdCBtZWFucywgaWY8YnI+DQom Z3Q7ICZndDsgYW55dGhpbmcuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEkgdW5kZXJz dGFuZCB0aGF0IGl0IGlzIG5lZWRlZCBmb3IgTkVUQ09ORiAoZmlsdGVycykgYW5kIGZvciBZQU5H PGJyPg0KJmd0OyAmZ3Q7IChhdWdtZW50cywgY29uc3RyYWludHMpIGFuZCBzbyBtdXN0IGJlIHNv bWV3aGVyZSBhbmQgbXVzdCBiZTxicj4NCiZndDsgcmVsYXRpdmVseTxicj4NCiZndDsgJmd0OyBz dGFibGUsIGJ1dCBoYXMgaXQgYW55IG90aGVyIHNpZ25pZmljYW5jZSBpbiB0aGUgZGF0YSBtb2Rl bD88YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgQXMgeW91IG1heSByZWNhbGwsIEkgd2Fz IGludm9sdmVkIHdpdGggU01JIGZpcnN0LCB3aGVyZSB0aGUgcm9vdCBpczxicj4NCiZndDsgJmd0 OyBzb21ld2hlcmUgdXAgaW4gdGhlIHNreSBhbmQgbGlmZSBvbmx5IGJlY29tZXMgaW50ZXJlc3Rp bmcgc29tZSBzaXg8YnI+DQomZ3Q7ICZndDsgbGV2ZWxzIGRvd24gdGhlIGhpZXJhcmNoeSBhbmQg dGhhdCBtYXkgY29sb3VyIG15IHRoaW5raW5nLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDs8YnI+ DQomZ3Q7IFlBTkcgZG9lcyBhIHBvb3Igam9iIG9mIGRlZmluaW5nIHRoZSByb290IGZvciBZQU5H IGRhdGEgbm9kZXMuPGJyPg0KJmd0OyBJdCBpcyBzb21ldGltZXMgY2FsbGVkIGEgZGF0YXN0b3Jl IChpbiB0aGUgYWJzdHJhY3QpLjxicj4NCiZndDsgVGVjaG5pY2FsbHksIFlBTkcgYm9ycm93cyB0 aGUgZGVmaW5pdGlvbiBmcm9tIFhQYXRoLjxicj4NCiZndDsgWUFORyBqdXN0IGRlZmluZXMgdG9w LWxldmVsIGRhdGEgbm9kZXMgYW5kIHRoZSBwYXJlbnQgb2Y8YnI+DQomZ3Q7IHRoZXNlIG5vZGVz IGlzIHRoZSBkb2N1bWVudCByb290PGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlcmUgaXMgbm8gcHJv dG9jb2wgb3IgZW5jb2RpbmcgbmV1dHJhbCBkZWZpbml0aW9uLDxicj4NCiZndDsgb25seSBhbiBY TUwtc3BlY2lmaWMgZGVmaW5pdGlvbi48YnI+DQomZ3Q7PGJyPg0KJmd0OyAmbHQ7dHAmZ3Q7PGJy Pg0KJmd0Ozxicj4NCiZndDsgVGhhbmtzIGZvciB0aGF0Ljxicj4NCiZndDs8YnI+DQomZ3Q7IEl0 IHNlZW1zIHRvIG1lIHRoYXQgbXVjaCBvZiB0aGUgZXh0ZW5zaXZlIGRpc2N1c3Npb24gb24gWTM0 IChhbGwgb2Y8YnI+DQomZ3Q7IHdoaWNoIEkgaGF2ZSByZWFkKSBpcyBhcyBtdWNoIHBvbGl0aWNh bCBhcyB0ZWNobmljYWwsIHRoYXQgaXMgU01JIGlzPGJyPg0KJmd0OyBoaWVyYXJjaGljYWwsIHRv cCBkb3duLCBwZXJoYXBzIGJlZml0dGluZyBpdHMgb3JpZ2lucyBpbiBJU08sIHdoZXJlYXM8YnI+ DQomZ3Q7IFlBTkcgaXMgYm90dG9tIHVwLiBJRVRGLWxpa2UuJm5ic3A7IFlBTkcgY291bGQgaGF2 ZSBoYWQgYSBzaW5nbGUgdHJlZSwgYnV0PGJyPg0KJmd0OyBkb2Vzbid0LiZuYnNwOyBTbyB3aGVu IEkgcmVhZDxicj4NCiZndDs8YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L2lkL2RyYWZ0LW9wZW5jb25maWctbmV0bW9kLW1vZGVsLXN0cnVjdHVyZS0wMC50eHQiIHRhcmdl dD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LW9wZW5jb25maWctbmV0 bW9kLW1vZGVsLXN0cnVjdHVyZS0wMC50eHQ8L2E+PGJyPg0KJmd0Ozxicj4NCiZndDsgSSBzZWUg YSBwbGVhIGZvciBhIG1vcmUgaGllcmFyY2hpY2FsIG9yZ2FuaXNhdGlvbiwgYW5kIHdoZW4gSSBy ZWFkPGJyPg0KJmd0Ozxicj4NCiZndDsgZHJhZnQtYmpvcmtsdW5kLW5ldG1vZC1vcGVuY29uZmln LXJlcGx5LTAwPGJyPg0KJmd0Ozxicj4NCiZndDsgSSBzZWUgYSByZXNwb25zZSB0aGF0IHNheXMg d2UgYXJlIG5vdCBsaWtlIHRoYXQuPGJyPg0KJmd0Ozxicj4NCiZndDsgSWYgc28sIEkgZG91YnQg dGhhdCB0aGVyZSBldmVyIHdpbGwgYmUgYSB0ZWNobmljYWwgc29sdXRpb24uPGJyPg0KJmd0Ozxi cj4NCiZndDsgQW5kIEkgYW0gbWluZGZ1bCB0aGF0IHdoZW4gSSBjb25maWd1cmUgcm91dGluZyBp biBhIChDaXNjbykgcm91dGVyLCBJPGJyPg0KJmd0OyBoYXZlIHRvIGRvIHNvbWUgb2YgaXQgdW5k ZXIgdGhlIGludGVyZmFjZSBkZWZpbml0aW9ucyBhbmQgc29tZSBvZiBpdDxicj4NCiZndDsgdW5k ZXIgdGhlIGRlZmluaXRpb24gb2YgdGhlIHJvdXRpbmcgcHJvdG9jb2wuJm5ic3A7IFdoaWNoIGlz IGxpZmUsIG5ldmVyPGJyPg0KJmd0OyB3aG9seSBpbnRlcmZhY2UtY2VudHJpYyBhbmQgbmV2ZXIg d2hvbHkgcm91dGluZyBwcm90b2NvbC1jZW50cmljITxicj4NCjxicj4NCkFyZSB5b3Ugc2F5aW5n IHRoZSBqb2Igd291bGQgYmUgZWFzaWVyIGlmIHRoZTxicj4NCnBhdGggd2FzIC9kZXZpY2UvaW50 ZXJmYWNlcy9pbnRlcmZhY2UgaW5zdGVhZDxicj4NCm9mIGp1c3QgL2ludGVyZmFjZXMvaW50ZXJm YWNlPyZuYnNwOyBBcmUgeW91IHNheWluZzxicj4NCnRoYXQgL3Byb3RvY29scy9yb3V0aW5nIGNv dWxkIG5vdCBhbHNvIGJlIGRlZmluZWQ/PGJyPg0KQ2xlYXJseSBlZGl0LWNvbmZpZyBhbmQgY29w eS1jb25maWcgYWxsb3cgYm90aDxicj4NCnN1YnRyZWVzIHRvIGJlIGFjY2Vzc2VkIGluIHRoZSBz YW1lIG9wZXJhdGlvbiw8YnI+DQpzbyBJIGRvbid0IHVuZGVyc3RhbmQgeW91ciBjb25jZXJuLjxi cj4NCjxicj4NCkkgaGF2ZSBiZWVuIHRyeWluZyB0byBnZXQgdGhlIHJvb3Qgbm9kZSB0byBiZSBi ZXR0ZXIgZGVmaW5lZDxicj4NCmluIHRoZSBwcm90b2NvbHMgdGhhdCB1c2UgWUFORyAoaS5lLiwg bmN4OnJvb3QsIFkzNC0wNCkuPGJyPg0KSU1PIHRoaXMgaXMgYSBiZXR0ZXIgYXBwcm9hY2ggdGhh biBkZWZpbmluZyBhIFlBTkcgbW9kdWxlPGJyPg0Kd2l0aCBhIHNwZWNpYWwgY29udGFpbmVyIHRo YXQgYWxsIG90aGVyIG1vZHVsZXMgYXJlIGV4cGVjdGVkPGJyPg0KdG8gYXVnbWVudC4mbmJzcDsg WUFORyBpcyBkZXNpZ25lZCBzdWNoIHRoYXQgZWFjaCB2ZW5kb3Igb3IgU0RPPGJyPg0KaXMgbm90 IGRlcGVuZGVudCBvbiBvdGhlciB2ZW5kb3JzIG9yIFNET3MgaW4gb3JkZXIgdG88YnI+DQpkZWZp bmUgZGF0YSBub2Rlcy48YnI+DQo8YnI+DQombHQ7dHAmZ3Q7PGJyPg0KPGJyPg0KQW5keTxicj4N Cjxicj4NCkkgYW0gYWdyZWVpbmcgd2l0aCB5b3UgdGhhdCBhZGRpbmcgJ2RldmljZScgYnJpbmdz IG5vIHRlY2huaWNhbCBiZW5lZml0LDxicj4NCnJhdGhlciB0aGF0IHRoZSBtb3RpdmF0aW9uIGlz IHRoZSBvcHBvc2l0ZSBvZiB0ZWNobmljYWwgKHdoaWNoIEk8YnI+DQpyZWZlcnJlZCB0byBhcyBw b2xpdGljYWwpLiBJIGFtIGFsc28gYWdyZWVpbmcgd2l0aCB0aGUgY3VycmVudCBkZWNsYXJlZDxi cj4NCmNvbnNlbnN1cyBvbiBZMzQuPGJyPg0KPGJyPg0KQW5kIHllcywgWUFORyBpcyBnb2luZyB0 byBnaXZlIHVzIGEgbGFyZ2UgbnVtYmVyIG9mIG1vZHVsZXMsIHNvbWU8YnI+DQp0aWdodGx5IGNv dXBsZWQgKGF1Z21lbnRzKSBzb21lIGxvb3NlbHkgc28gKGhvdyBtYW55IGRvIHlvdSBuZWVkIHRv PGJyPg0KY29uZmlndXJlIE9TUEY/KSBhbmQgd29yayBpbiB0aGlzIGFyZWEgd2lsbCBiZSBvZiBi ZW5lZml0IG5vdyBhbmQ8YnI+DQpwcm9iYWJseSBlc3NlbnRpYWwgaW4gYSBmZXcgeWVhcnMgdGlt ZS4mbmJzcDsgVGhhdCBzYWlkLCBJIGFtIHVuc3VyZSB3aGF0PGJyPg0Kc3VjaCB3b3JrIHdvdWxk IGJlIGxpa2U7IEkgYW0gbG9va2luZyAoaW4gZGVzcGFpcikgYXQgNTAgcm91dGluZyBhcmVhPGJy Pg0KWUFORyBtb2RlbHMgYW5kIHdvbmRlcmluZyBob3cgYSB1c2VyIHdpbGwgZXZlciBnZXQgYSBj b2hlcmVudCBwaWN0dXJlIG9mPGJyPg0KaG93IHRvIGRvIHdoYXQgdGhleSB3YW50IHRvIGRvLjxi cj4NCjxicj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj5UaGUgJnF1b3Q7WUFORyBMYW5kIEdyYWImcXVvdDsgZ2l2ZXMgYSBmYWxzZSBz ZW5zZSBvZiBwcm9ncmVzcy48L2Rpdj4NCjxkaXY+UmVhY2hpbmcgV0cgY29uc2Vuc3VzIG9uIGV2 ZXJ5IHNpbmdsZSBsZWFmIGlzIGhhcmQgd29yay48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2PkkgZG9uJ3QgdGhpbmsgYSBjb2xsZWN0aW9uIG9mIDEwMHMgb2YgWUFORyBtb2R1bGVzIGlz IGV2ZXI8YnI+DQo8L2Rpdj4NCjxkaXY+Z29pbmcgdG8gdG8gYmUgZWFzeSB0byB1bmRlcnN0YW5k LiZuYnNwOyBPcGVyYXRvcnMgd2lsbCBub3QgZXhhbWluZTwvZGl2Pg0KPGRpdj5hIE5FVENPTkYg Jmx0O2hlbGxvJmd0OyBtZXNzYWdlLCBsb29rIGF0IDE1MCBtb2R1bGUgVVJJcyw8L2Rpdj4NCjxk aXY+YW5kIHNheSAmcXVvdDtJIGtub3cgZXhhY3RseSB3aGF0IHRoaXMgZGV2aWNlIHN1cHBvcnRz JnF1b3Q7LjwvZGl2Pg0KPGRpdj5JIGd1ZXNzIGl0IGlzIHVwIHRvIGNsaWVudCB0b29scyB0byBk byB0aGF0PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JIHdyb3RlIGEgZHJhZnQgdGhh dCBkZWZpbmVzIFlBTkcgUGFja2FnZXMsIHdoaWNoIGNhbiBwcm92aWRlPC9kaXY+DQo8ZGl2PmEg aGlnaGVyIGxldmVsIG9mIG9yZ2FuaXphdGlvbiBmb3IgWUFORyBtb2R1bGVzLjwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxkaXY+PGEgaHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1iaWVybWFuLW5ldG1vZC15YW5nLXBhY2thZ2UvIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1iaWVybWFuLW5ldG1vZC15YW5n LXBhY2thZ2UvPC9hPjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+WW91IGFu ZCBJIGFyZSBhcHBhcmVudGx5IGluIHRoZSBtaW5vcml0eSwgc2luY2UgdGhlIG9mZmljaWFsIHN0 YXR1czwvZGl2Pg0KPGRpdj5pcyB0aGF0IHRoZXJlIGlzIG5vIHByb2JsZW0gd2l0aCB0aGUgY3Vy cmVudCBhcHByb2FjaCwgYW5kIG5vIG5lZWQ8L2Rpdj4NCjxkaXY+dG8gb3JnYW5pemUgaW5kaXZp ZHVhbCBZQU5HIG1vZHVsZXMgaW50byBhbnkgbGFyZ2VyIGFic3RyYWN0aW9ucy48L2Rpdj4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2Jv cmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KJm5ic3A7VG9tIFBl dGNoPGJyPg0KPGJyPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8ZGl2PkFuZHk8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8YmxvY2txdW90 ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVm dDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCkFuZHk8YnI+DQo8YnI+DQomZ3Q7 IEFuZHk8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFRoZSB3ZWxsLXNwZWNpZmllZCBYUGF0aCBh bmQgWUFORyByb290ICgvKSBjYW4gYmU8YnI+DQomZ3Q7ICZndDsgYWNjZXNzZWQgYnkgYWxsIHBy b3RvY29sIG9wZXJhdGlvbnMsIGV4YWN0bHkgdGhlIHNhbWU8YnI+DQomZ3Q7ICZndDsgYXMgYSBu b2RlIGNhbGxlZCAnZGV2aWNlJy4mbmJzcDsgVGhlIGFjdHVhbCBub2RlIG5hbWUgd2lsbDxicj4N CiZndDsgJmd0OyBkZXBlbmQgb24gdGhlIFJQQyBmdW5jdGlvbiAoZS5nLiAnZGF0YScgb3IgJ2Nv bmZpZycpLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBUaGlzIGlzIG1vcmUgdGhhbiBy ZWR1bmRhbnQgaG93ZXZlci4mbmJzcDsgSXQgaW50cm9kdWNlcyBhICZxdW90O3N1cGVyLW1vZHVs ZSZxdW90Ozxicj4NCiZndDsgJmd0OyBpbnRvIFlBTkcgdGhhdCBldmVyeSBvdGhlciBtb2R1bGUg aXMgZXhwZWN0ZWQgdG8gYXVnbWVudC48YnI+DQomZ3Q7ICZndDsgWUFORyBpcyBpbnRlbmRlZCB0 byBiZSBtb3JlIGxvb3NlbHkgY291cGxlZCB0aGFuIHRoYXQuPGJyPg0KJmd0OyAmZ3Q7IFRoaXMg aW50cm9kdWNlcyBhbiBleHRyYSBub2RlIGFuZCBuYW1lc3BhY2UgZGVjbGFyYXRpb248YnI+DQom Z3Q7ICZndDsgaW4gYWxsIHByb3RvY29sIG1lc3NhZ2VzLCBpbmNyZWFzaW5nIG1lc3NhZ2Ugc2l6 ZXMuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEl0IGFsc28gYXNzdW1lcyBhbGwgZXhp c3RpbmcgWUFORyBtb2RlbHMgd2lsbCBnZXQgcmV3cml0dGVuIHRvPGJyPg0KJmd0OyAmZ3Q7IGFj Y291bnQgZm9yICZxdW90Oy9kZXZpY2UmcXVvdDsgaW4gYWxsIHBhdGggYW5kIFhQYXRoIGV4cHJl c3Npb25zLjxicj4NCiZndDsgJmd0OyBUaGlzIGlzIGhpZ2hseSBkaXNydXB0aXZlIHRvIGV4aXN0 aW5nIGRlcGxveW1lbnRzLjxicj4NCiZndDsgJmd0OyBBbHNvLCBtdWx0aXBsZSBkYXRhIG1vZGVs cyB0byBlZGl0IHRoZSBzYW1lIHRoaW5nIGNhdXNlcyBsb3RzPGJyPg0KJmd0OyAmZ3Q7IG9mIGV4 dHJhIGNvbXBsZXhpdHkgaW4gdGhlIHNlcnZlciAoc3VwcG9ydGluZyBib3RoIG9sZDxicj4NCiZn dDsgJmd0OyBsb2NhdGlvbiBhbmQgbmV3IGxvY2F0aW9uKS48YnI+DQomZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDsgSU1PIGEgcmVzb3VyY2UgZGlyZWN0b3J5IGFwcHJvYWNoIGlzIG11Y2ggbW9yZSBy ZWFsaXN0aWMuPGJyPg0KJmd0OyAmZ3Q7IFRoZSAvZGV2aWNlIHRyZWUgY2FuIGNvbnRhaW4gYWxs IHRoZSBvcmdhbml6ZWQgTlAgY29udGFpbmVycy48YnI+DQomZ3Q7ICZndDsgSW5zdGVhZCBvZiBh bGwgdGhlIGFjdHVhbCBkYXRhIG5vZGVzLCB0aGlzIHRyZWUganVzdCBoYXMgcG9pbnRlcnM8YnI+ DQomZ3Q7ICZndDsgdG8gdGhlIHJlYWwgbG9jYXRpb24gb2YgdGhlIHJlc291cmNlLiAobGlrZSAz MDEgTW92ZWQgUGVybWFuZW50bHkpPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsg QWNlZTxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEFuZHk8YnI+DQo8YnI+DQo8 YnI+DQoqKiBTb2x1dGlvbiBZMzQtMDI8YnI+DQo8YnI+DQombmJzcDsgS2VlcCAnYW55eG1sJy4m bmJzcDsgSW50cm9kdWNlICdhbnlkYXRhJyBhcyBhYm92ZSBidXQgd2l0aG91dCB0aGU8YnI+DQom bmJzcDsgJ2Zvcm1hdCcgc3Vic3RhdGVtZW50Ljxicj4NCjxicj4NCiZuYnNwOyAnYW55eG1sJyB3 b3VsZCBzdGlsbCBiZSB1c2VkIHRvIHJlcHJlc2VudCB1bnJlc3RyaWN0ZWQgWE1MLCBhcyBpczxi cj4NCiZuYnNwOyBkb25lIGluIE5FVENPTkYuPGJyPg0KPGJyPg0KJm5ic3A7ICdhbnlkYXRhJyB3 b3VsZCBiZSBhbiB1bmtub3duIGNodW5rIG9mIGRhdGEgdGhhdCBjYW4gYmUgbW9kZWxsZWQ8YnI+ DQombmJzcDsgd2l0aCBZQU5HLiZuYnNwOyBDYW4gYmUgZW5jb2RlZCBhcyB4bWwgb3IganNvbi48 YnI+DQo8YnI+DQombmJzcDsgRm9yIGV4YW1wbGU6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAj JiM0MztCRUdJTl9FWEFNUExFPGJyPg0KJm5ic3A7ICZuYnNwOyBhbnlkYXRhIGRhdGE7PGJyPg0K Jm5ic3A7ICZuYnNwOyAjJiM0MztFTkRfRVhBTVBMRTxicj4NCjxicj4NCioqIFNvbHV0aW9uIFkz NC0wNTxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtTYW1lIGFzIFkzNC0wMiBwbHVzIHR3byBndWlk ZWxpbmVzIGFkb3B0ZWQgZnJvbSBZMzQtMDQ6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOy0gS2Vl cCAnYW55eG1sJyB1bmNoYW5nZWQgYXMgaXQgaXMgZGVmaW5lZCBpbiBZQU5HIDEuMC4gVGhpczxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ZW5zdXJlcyBiYWNrd2FyZCBjb21wYXRpYmlsaXR5Ljxi cj4NCiZuYnNwOyAmbmJzcDstIEludHJvZHVjZSBhIG5ldyAnYW55ZGF0YScgc3RhdGVtZW50IHRo YXQgcmVwcmVzZW50cyBhbiB1bmtub3duPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDtjaHVuayBv ZiBkYXRhIHRoYXQgY2FuIGJlIG1vZGVsZWQgd2l0aCBZQU5HPGJyPg0KJm5ic3A7ICZuYnNwOy0g RG9jdW1lbnQgdGhhdCBpbXBsZW1lbnRhdGlvbnMgTUFZIGhhdmUgcmVzdHJpY3Rpb25zIGZvciBh bnl4bWwgYW5kPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDt0aGF0IGFueXhtbCBpcyBub3QgbmVj ZXNzYXJpbHkgaW50ZXJvcGVyYWJsZTsgZGF0YSBtb2RlbCB3cml0ZXJzPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDtzaG91bGQgdXNlIGFueWRhdGEgd2hlbmV2ZXIgcG9zc2libGUuPGJyPg0KJm5i c3A7ICZuYnNwOy0gVGhlIGd1aWRlbGluZXMgZG9jdW1lbnQgc2hvdWxkIHNheSB0aGF0IFlBTkcg RG9jdG9ycyB3aWxsIHJldmlldzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ZWFjaCB1c2Ugb2Yg YW55eG1sIGluIElFVEYgbW9kdWxlcyB3aGVuIFlBTkcgMS4xIGlzIGFkb3B0ZWQgdG88YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwO2F2b2lkIGl0cyB1c2Ugd2hlbmV2ZXIgcG9zc2libGUuPGJyPg0K PGJyPg0KPGJyPg0KJmd0Ozxicj4NCjxicj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyPg0K PC9kaXY+DQo8L2Rpdj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KbmV0bW9kIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpuZXRt b2RAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5uZXRtb2RAaWV0Zi5vcmc8L2E+PGJyPg0KPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZDwv YT48YnI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N Cjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9z cGFuPjwvZGl2Pg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQpuZXRtb2QgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm5l dG1vZEBpZXRmLm9yZyI+bmV0bW9kQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kIiByZWw9Im5vcmVmZXJyZXIiIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1v ZDwvYT48YnI+DQo8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_D1EE8D652AAEAaceeciscocom_-- From nobody Tue Aug 11 00:13:05 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDB041A1A8C for ; Tue, 11 Aug 2015 00:13: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 MSNYDYWJkeHy for ; Tue, 11 Aug 2015 00:12: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 6F8831A1A91 for ; Tue, 11 Aug 2015 00:12:58 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 1227B1500; Tue, 11 Aug 2015 09:12: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 vc4dEMMRCwsT; Tue, 11 Aug 2015 09:12:55 +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, 11 Aug 2015 09:12:55 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id B3E5C20056; Tue, 11 Aug 2015 09:12:55 +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 MmgDWjna6zxY; Tue, 11 Aug 2015 09:12:54 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 55AF820048; Tue, 11 Aug 2015 09:12:53 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1A056362DDFA; Tue, 11 Aug 2015 09:12:48 +0200 (CEST) Date: Tue, 11 Aug 2015 09:12:48 +0200 From: Juergen Schoenwaelder To: Rob Shakir Message-ID: <20150811071246.GA18393@elstar.local> Mail-Followup-To: Rob Shakir , "netmod@ietf.org" References: <55C4B9DB.1030400@rob.sh> <20150807141439.GA76991@elstar.local> <55C4C346.406@rob.sh> <20150807153909.GA182@elstar.local> <55C5054C.1090704@rob.sh> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55C5054C.1090704@rob.sh> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] draft-openconfig-netmod-opstate: Changes in -01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 07:13:04 -0000 On Fri, Aug 07, 2015 at 03:21:48PM -0400, Rob Shakir wrote: > > > Juergen Schoenwaelder wrote: > >But you are right, it is not just the path that is needed to identify > >data residing in configuration datastores. It is in general a tuple > > and for configuration data the selector is a > >configuration datastore name. > > Thanks for the clarification. Do you have examples of other (i.e., > non-NETCONF) systems that utilise this convention that a path is not an > absolute reference to a certain data node? Reviewing with various > interested parties, I'm not sure that there are clear cases that form a > precedent for this. SNMP has an even more complex naming scheme. > If we consider that this then might drive some new behaviour where the > systems architecture for NMS differs from elsewhere then we might want > to question whether this is necessary complexity. Indeed, for me this > comes back to one of the discussions about the other datastores that we > had on an interim call. > * 'startup' is really a property of the intended configuration - as to > whether it has been made persistent. In general, I see very few changes > that are made where we interact only with the persistent version of the > intended configuration; and even fewer where the intended configuration > is not made persistent. In both cases, it tends to be the lack of a > declarative configuration API that drives the need to interact with either. You can have a NETCONF server without 'startup' and it still has persistent running config. I have no clue what 'the lack of a declarative configuration API' means. > * 'candidate' is again a property of the intended configuration - > insofar that the 'candidate' set of configuration represents a set of > changes that have not been requested to be transitioned to the 'applied > configuration'. This makes sense when a human is working through > building up a transaction (configure protocol X, protocol Y .. protocol > Z, then commit) - but isn't quite so clear when it programmatic > interaction with the network. There are commercial implementations that make use of candidate datastores and the transaction, validation and rollback capabilities they provide. You may decide that you do not need them but this does not imply that nobody else will need them. > It is quite trivial for me to see cases where an external NMS would > never really need to interact with either of these datastores - such > that it's quite tricky for me to determine that we really want to > architect the entire NMS to be able to carry the tuple > (stealing your terms, thanks!), especially if this means that it has to > work entirely differently w.r.t paths than the rest of OSS. It is certainly up to you how you architect your NMS the way to think it works best. I am just trying to explain how NETCONF and YANG work. But I would expect that an NMS is able to integrate namespaces. The approach allows us to use the same path in different datastores, this is considered to be a feature and not a bug. /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 Aug 11 00:38:39 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BEE21A1B0B for ; Tue, 11 Aug 2015 00:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.461 X-Spam-Level: X-Spam-Status: No, score=-4.461 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_15=0.6, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mG0l4MjlgK4p for ; Tue, 11 Aug 2015 00:38:35 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDD091A1B00 for ; Tue, 11 Aug 2015 00:38:34 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:5d3e:43b3:3d92:fd05] (unknown [IPv6:2001:718:1a02:1:5d3e:43b3:3d92:fd05]) by mail.nic.cz (Postfix) with ESMTPSA id 8CE1E181857; Tue, 11 Aug 2015 09:38:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1439278713; bh=K7SbjLvrA4EZPf3uHUR9a0mco2EBSBBdPSBVpn4datA=; h=From:Date:To; b=yRJU0RTbMTf5SAIj1SQ3SzV+gnoyUMNAtPI2zgWXjAT6KveXEkVdDM0KD8L3fRa1y Uv+WJn/vuYSo0cRCKkB+tEWTzd1e7K1lnYeFGqvCAE7aUvA/Fx3TodbdLnsENCxhvB 3JN7o+kBh/g0tUBFD1/trVlT805FZEksr7mx938w= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 11 Aug 2015 09:38:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <52B35D5C-E9F9-48B7-8B80-9416ABB18642@nic.cz> References: To: Andy Bierman X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Y34 - root node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 07:38:38 -0000 > On 10 Aug 2015, at 22:15, Andy Bierman wrote: >=20 >=20 >=20 > On Mon, Aug 10, 2015 at 12:34 PM, Acee Lindem (acee) = wrote: > I think there is agreement that there is a problem. The YANG Routing = Design Team is addressing this with = https://www.ietf.org/id/draft-rtgyangdt-rtgwg-device-model-00.txt = (which has evolved from = https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt). = In essence, a place for everything and everything in its place. However, = there are those who feel that can=E2=80=99t mandate a single model = structure for network devices and we need mechanisms to manage multiple = models but allow for different device structure (e.g., = https://www.ietf.org/id/draft-bierman-netmod-yang-package-00.txt). I = hope we can agree on an approach in the coming interim meetings.=20 >=20 >=20 > Do you expect "everything in its place" to apply to all other SDOs and > all vendor modules? Or do you expect just the IETF routing modules > to follow this subtree hierarchy? If the former, does this mean the > YANG Routing Design Team is the "YANG data placement authority"=20 > or all YANG modules that ever get written? How long should > it take for all other SDOs and vendors to redo all their existing > modules to re-root them in their assigned place in the data tree? >=20 > IMO is is not a good idea to rely on rigid data node placement, > and a single data placement authority. It is better and use meta-data > built from the YANG modules (or YANG packages) instead. >=20 > The reason Linux uses packages to install/update functionality > is because managing 8000 packages is hard enough. > Managing 247,000 individual files would be insane. > The actual location of files is quite configurable and different > across distros. We could learn something from the last decade > of Linux package management, and try to apply it to YANG. >=20 That=E2=80=99s an interesting idea, could a YANG package also specify, = e.g. that the root node for the package is X/Y/Z? This could solve some = use cases for relocatability, and it would also be relatively easy to = modify all absolute XPath expressions inside the package. Lada >=20 >=20 >=20 >=20 >=20 > Thanks, > Acee =20 >=20 >=20 > Andy > =20 >=20 >=20 >=20 > From: netmod on behalf of "Einar = Nilsen-Nygaard (einarnn)" > Date: Monday, August 10, 2015 at 5:29 AM > To: Jonathan Hansford > Cc: NETMOD Working Group > Subject: Re: [netmod] Y34 - root node >=20 > As someone sharing responsibilities for guiding a number of = development teams both defining new models and implementing to some = already defined models in this area, I can only agree with this addition = to what I said earlier. >=20 > Cheers, >=20 > Einar >=20 >> On Aug 10, 2015, at 9:46 AM, Jonathan Hansford = wrote: >>=20 >> And it is not just end users who need help to better understand YANG = models and how to use them. For those still on the edge, looking to = finally take the plunge and use NETCONF/YANG to configure their devices, = help is also required to determine how best to structure their YANG = models, make use of the existing ones, etc. For those who have "grown = up" with the developments in NETCONF and YANG, much of this is probably = second nature. But coming to it cold (in the sense of compiling/writing = a first set of YANG models for a device; I've been following the = netconf/netmod WGs for 3+ years), it still feels very much like a dark = art! It is not just the individual modules, it is how to put them = together to best manage a device (let alone a system). >>=20 >> Jonathan >>=20 >>=20 >>=20 >> ----- Original Message ----- >> From: >> "Einar Nilsen-Nygaard (einarnn)" >>=20 >> To: >> "Andy Bierman" >> Cc: >> "NETMOD Working Group" >> Sent: >> Sat, 8 Aug 2015 11:10:15 +0000 >> Subject: >> Re: [netmod] Y34 - root node >>=20 >>=20 >> Andy, >>=20 >> I agree that there is a need for organization of models, but I = don=E2=80=99t have a firm position on = draft-openconfig-netmod-model-structure/draft-rtgyangdt-rtgwg-device-model= or draft-bierman-netmod-yang-package. But we absolutely need = *something* to help end-users of the models comprehend the overall = structure of models, their relationship and how to use them. >>=20 >> Cheers, >>=20 >> Einar >>=20 >> On Aug 4, 2015, at 5:16 PM, Andy Bierman wrote: >>=20 >>=20 >>=20 >> On Tue, Aug 4, 2015 at 2:34 AM, t.petch wrote: >> ----- Original Message ----- >> From: "Andy Bierman" >> To: "t.petch" >> Sent: Monday, August 03, 2015 5:17 PM >>=20 >> > ----- Original Message ----- >> > From: "Andy Bierman" >> > To: "t.petch" >> > Sent: Monday, August 03, 2015 4:10 PM >> > >> > > ----- Original Message ----- >> > > From: "Andy Bierman" andy@yumaworks.com >> > > Sent: Saturday, August 01, 2015 7:05 PM >> > > On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem (acee) = >> > > >> >>> On 8/1/15, 2:51 AM, j.schoenwaelder@jacobs-university.de> wrote: >> >>> >> >>> Section 1.1 in >> >>> >> > = https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt >> >>> lists the goals of a generic model structure that will = accommodate >> >> most >> >>> modern network devices. I guess you don=E2=80=99t agree that = these are >> >> desirable? >> > > >> > > The only objection I have to this draft is the insertion of a >> top-level >> > > root >> > > called "device". (Might as well be called "self"). >> > > There are no sibling nodes planned or intended for >> > > this node, so it serves as an extra document root. >> > > >> > > >> > > One aspect of YANG I have never grasped is what a root means, if >> > > anything. >> > > >> > > I understand that it is needed for NETCONF (filters) and for YANG >> > > (augments, constraints) and so must be somewhere and must be >> > relatively >> > > stable, but has it any other significance in the data model? >> > > >> > > As you may recall, I was involved with SMI first, where the root = is >> > > somewhere up in the sky and life only becomes interesting some = six >> > > levels down the hierarchy and that may colour my thinking. >> > > >> > >> > YANG does a poor job of defining the root for YANG data nodes. >> > It is sometimes called a datastore (in the abstract). >> > Technically, YANG borrows the definition from XPath. >> > YANG just defines top-level data nodes and the parent of >> > these nodes is the document root >> > >> > There is no protocol or encoding neutral definition, >> > only an XML-specific definition. >> > >> > >> > >> > Thanks for that. >> > >> > It seems to me that much of the extensive discussion on Y34 (all of >> > which I have read) is as much political as technical, that is SMI = is >> > hierarchical, top down, perhaps befitting its origins in ISO, = whereas >> > YANG is bottom up. IETF-like. YANG could have had a single tree, = but >> > doesn't. So when I read >> > >> > = https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt >> > >> > I see a plea for a more hierarchical organisation, and when I read >> > >> > draft-bjorklund-netmod-openconfig-reply-00 >> > >> > I see a response that says we are not like that. >> > >> > If so, I doubt that there ever will be a technical solution. >> > >> > And I am mindful that when I configure routing in a (Cisco) router, = I >> > have to do some of it under the interface definitions and some of = it >> > under the definition of the routing protocol. Which is life, never >> > wholy interface-centric and never wholy routing protocol-centric! >>=20 >> Are you saying the job would be easier if the >> path was /device/interfaces/interface instead >> of just /interfaces/interface? Are you saying >> that /protocols/routing could not also be defined? >> Clearly edit-config and copy-config allow both >> subtrees to be accessed in the same operation, >> so I don't understand your concern. >>=20 >> I have been trying to get the root node to be better defined >> in the protocols that use YANG (i.e., ncx:root, Y34-04). >> IMO this is a better approach than defining a YANG module >> with a special container that all other modules are expected >> to augment. YANG is designed such that each vendor or SDO >> is not dependent on other vendors or SDOs in order to >> define data nodes. >>=20 >> >>=20 >> Andy >>=20 >> I am agreeing with you that adding 'device' brings no technical = benefit, >> rather that the motivation is the opposite of technical (which I >> referred to as political). I am also agreeing with the current = declared >> consensus on Y34. >>=20 >> And yes, YANG is going to give us a large number of modules, some >> tightly coupled (augments) some loosely so (how many do you need to >> configure OSPF?) and work in this area will be of benefit now and >> probably essential in a few years time. That said, I am unsure what >> such work would be like; I am looking (in despair) at 50 routing area >> YANG models and wondering how a user will ever get a coherent picture = of >> how to do what they want to do. >>=20 >>=20 >>=20 >> The "YANG Land Grab" gives a false sense of progress. >> Reaching WG consensus on every single leaf is hard work. >>=20 >> I don't think a collection of 100s of YANG modules is ever >> going to to be easy to understand. Operators will not examine >> a NETCONF message, look at 150 module URIs, >> and say "I know exactly what this device supports". >> I guess it is up to client tools to do that >>=20 >> I wrote a draft that defines YANG Packages, which can provide >> a higher level of organization for YANG modules. >>=20 >> http://datatracker.ietf.org/doc/draft-bierman-netmod-yang-package/ >>=20 >> You and I are apparently in the minority, since the official status >> is that there is no problem with the current approach, and no need >> to organize individual YANG modules into any larger abstractions. >>=20 >>=20 >>=20 >> Tom Petch >>=20 >>=20 >>=20 >> Andy >> =20 >> Andy >>=20 >> > Andy >> > >> > > The well-specified XPath and YANG root (/) can be >> > > accessed by all protocol operations, exactly the same >> > > as a node called 'device'. The actual node name will >> > > depend on the RPC function (e.g. 'data' or 'config'). >> > > >> > > This is more than redundant however. It introduces a = "super-module" >> > > into YANG that every other module is expected to augment. >> > > YANG is intended to be more loosely coupled than that. >> > > This introduces an extra node and namespace declaration >> > > in all protocol messages, increasing message sizes. >> > > >> > > It also assumes all existing YANG models will get rewritten to >> > > account for "/device" in all path and XPath expressions. >> > > This is highly disruptive to existing deployments. >> > > Also, multiple data models to edit the same thing causes lots >> > > of extra complexity in the server (supporting both old >> > > location and new location). >> > > >> > > IMO a resource directory approach is much more realistic. >> > > The /device tree can contain all the organized NP containers. >> > > Instead of all the actual data nodes, this tree just has pointers >> > > to the real location of the resource. (like 301 Moved = Permanently) >> > > >> > > > Acee >> > > > >> > > Andy >>=20 >>=20 >> ** Solution Y34-02 >>=20 >> Keep 'anyxml'. Introduce 'anydata' as above but without the >> 'format' substatement. >>=20 >> 'anyxml' would still be used to represent unrestricted XML, as is >> done in NETCONF. >>=20 >> 'anydata' would be an unknown chunk of data that can be modelled >> with YANG. Can be encoded as xml or json. >>=20 >> For example: >>=20 >> #+BEGIN_EXAMPLE >> anydata data; >> #+END_EXAMPLE >>=20 >> ** Solution Y34-05 >>=20 >> Same as Y34-02 plus two guidelines adopted from Y34-04: >>=20 >> - Keep 'anyxml' unchanged as it is defined in YANG 1.0. This >> ensures backward compatibility. >> - Introduce a new 'anydata' statement that represents an unknown >> chunk of data that can be modeled with YANG >> - Document that implementations MAY have restrictions for anyxml = and >> that anyxml is not necessarily interoperable; data model writers >> should use anydata whenever possible. >> - The guidelines document should say that YANG Doctors will review >> each use of anyxml in IETF modules when YANG 1.1 is adopted to >> avoid its use whenever possible. >>=20 >>=20 >> > >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >>=20 >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Aug 11 03:37:52 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE8D1A8547 for ; Tue, 11 Aug 2015 03:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, J_CHICKENPOX_34=0.6, SPF_HELO_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 TjdmSyGpJGY5 for ; Tue, 11 Aug 2015 03:37:48 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0743.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::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 BD0041A82E2 for ; Tue, 11 Aug 2015 03:37:47 -0700 (PDT) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.151.167.91) by AMXPR07MB056.eurprd07.prod.outlook.com (10.242.67.151) with Microsoft SMTP Server (TLS) id 15.1.225.19; Tue, 11 Aug 2015 10:37:26 +0000 Message-ID: <01c501d0d421$d78b8a40$4001a8c0@gateway.2wire.net> From: t.petch To: Jonathan Hansford , "Einar Nilsen-Nygaard (einarnn)" , Andy Bierman References: Date: Tue, 11 Aug 2015 11:38:13 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.167.91] X-ClientProxiedBy: DB4PR02CA0050.eurprd02.prod.outlook.com (10.242.174.178) To AMXPR07MB056.eurprd07.prod.outlook.com (10.242.67.151) X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB056; 2:dU20q2HTqkVEkuFoUjhZZK13qklbl94FBgpilpRDLhbKDmGnTrLOTMmLtknB8tqYqRQDGMqQY3PifUVA0B8edyqQRiyiP1QbNTVZVh4R1n+L//koA7ifF0fF4nA/ryKfokVzVqGvVtwNJZ72qMbvmds23InNtpeWleq/zl7mWp0=; 3:QgCs8uoqASZHRSNg42SakYATgxWQ/EiF0RYk5mdoxml7zAo9KaX0AJAnUlA9t/FjuvRyp/hjRzotc/D19WNIkOFg/OF2Pu4Co5uYxwC66VIgQQ+Wb2NOPk1idYvOYHjCFuV1STxBPUidtMLCrwYXuQ==; 25:Hpc60U6pD98+ySNa04dwywUyA1lFGMQYRYSNHC+G3mFA1ZxvdT6qawY7jfVGHsmg34lJ0Ug0OFxylX8vZCKm7RcQ2vO0kejnEcKiX9b7jQTyDBPyvk1LefSqKOvzxPMD5Di/sNNWMBY5G4vLXfCNbJS0udLTMEQpm/1Vz91PqqPvoVHRCSvk20opyoeLL1IaMjFJS+TzGieURT0N6fv9UstoWdOhgLc4BlqRCOWwTM5D0Ow57LFzaflheGvacfgYKN1Q6wVFZzSELZBDG5sdUg==; 4:W9YnTfyJyDJitbcKR4W7V+4d8QMkWgP5o1OCb0mxP+smTBBiLg5xXRGJdG2OmSLXC9IS3UpCtZFKGaU6kqd7e0JoJDEBeI9JW/RKubDep77nACegXfRbh6Ng/qtPz9JMGFOr7vIk6HtJtlTTOvFwoTLV4nl5yzt6hATLFXCxweFO0JDE/LlBbNeqIHzp9U8VYg3HLYu7dYgGrregWK7bxIIJ1xpKstVmmlFoeaKtnM7KYv+aNTLLL6C++Dadxhg3rIKw0eQ3Tosv/ubc3sw1AbX1Xnay67w73kCO8Xb3ZrQ= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB056; 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:AMXPR07MB056; BCL:0; PCL:0; RULEID:; SRVR:AMXPR07MB056; X-Forefront-PRVS: 066517B35B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(13464003)(24454002)(189002)(199003)(377454003)(46102003)(101416001)(50466002)(47776003)(68736005)(81156007)(5001960100002)(50986999)(84392001)(1556002)(105586002)(40100003)(62966003)(23676002)(5820100001)(5001860100001)(122386002)(92566002)(106356001)(19580405001)(4001540100001)(77156002)(50226001)(97736004)(5001830100001)(19580395003)(62236002)(87976001)(61296003)(76176999)(81816999)(5001770100001)(42186005)(116806002)(33646002)(44716002)(44736004)(77096005)(64706001)(15975445007)(66066001)(14496001)(189998001)(1456003)(86362001)(81686999)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB056; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTVhQUjA3TUIwNTY7MjM6TGxiK1NQUFJUeUE1c1NXcllyMWFtbzJJOHo5?= =?utf-8?B?bFp6Rnp6UjJ4TnZ0V0t5RUFkWlBYRHZKY1ZVWTNoMVpZaTYyNlpHK1E4bE51?= =?utf-8?B?Vm0raXdJUENFcHB5WUdycTNJNzN3a1QxaFhnbDRXNmowZTYrOStjRzlkMWVw?= =?utf-8?B?Y0dnTGo5ampDdG9POVpabjdMN0o0cTJ4L2dQNG9rMDMrWSs3Q3RXVm1IOHdM?= =?utf-8?B?S0E4VkdadVZVSGErMW5XemJnSVRsK3JtQXVsUjBVanUybHR3eTRSaklDUit2?= =?utf-8?B?YUdFc05xc0VkQjJFZVo1ZGlZY0JOQmpYWkVtNnR4dzJLeHlEdUtqWno2Um9x?= =?utf-8?B?U3lHRTZGOHJSR3plS1hZNG0xdm1nYzQxQlRya2xBMWtiSzg1UFRVR09rQUp3?= =?utf-8?B?bjVQR3orSnRzUnozeE96eGthMjgyUzlJZGhUUlV4eVd2TmhpdHJvU1M0dGkx?= =?utf-8?B?QndESUpsV2ZSeitrWUlFdkJLbWZxWjNmM2QxSlNWY0k4RnR5UUhMeURXUnV5?= =?utf-8?B?K1RndVBpZ1FKczE5MFdrWTZ4VHhSTEVIUzJWRjBCaGxpMXBOYmo0N1FBN2dz?= =?utf-8?B?RFdRQkllSFZMcTZMdEsyVVdTcWdEc0RTeXNOeGZESFFxUi9ZaUJ1UHFjTE01?= =?utf-8?B?L1gyRkdHcHgzcnI0N2JEUnFqT3d0YzRQTm1nck9IWU5rNnBGWG4wSm1hVkp3?= =?utf-8?B?Ukg3cExYT3Bndm1VQllRd3dwSWVhKzI3YkJyb2RGR2luNmQvVEh4ZElldmE1?= =?utf-8?B?THp4WnI2WGhZbGFTYUJsTXhIQVo3Ly9XUndCaXJ0aHloTkE0YVFqcHg0Zmdp?= =?utf-8?B?YWFIVkJJaGFZbXhPS20zVUNIaXpLNmhQSnhUY0l0NDhDbS9wMWROVTRzNHhM?= =?utf-8?B?c0p5RFFnRm9zeVNpOXdjZnBBQzNiNjhEeVpON1FqelhYWVczYVUwaGg0VjN3?= =?utf-8?B?Uzk4RmtNek1FV0c2OW41cTJFa204OWZOSTJXQlFab0phUC9QNGFHdGpiT1JK?= =?utf-8?B?am12akMwTHJPVFovZnJEeWU5amdyTEJoRUl4QUlDQU9Vd2J3YzI3Y0doUWhN?= =?utf-8?B?b1JkNGp6SEw0T25OU2lsRVlyNUpqdGVON091NVBwNmVremIxcDVncFlFR1pz?= =?utf-8?B?RkU1QWUvSklYbmk0MnF1TGgxYWczSVFoZjZncWtKTnZLU0I1SllYSVFHRys4?= =?utf-8?B?Yk9QWkU2bHlKeDU4cUQwUTRCeTl6bVhMQnNDRFhhYjMrcDdoUlFvNms1UEYw?= =?utf-8?B?d2JGUmd4Zlo1amxKOWlscFBSQzMvN2p0NWJ6V0NxMHVJSjU1R0lPTmZLa3ZC?= =?utf-8?B?U0wvcHlBazl1NzVTWTY5SVFKK1JsVDhYZHVjaW94RFhuSGJpRVcyK1dPekVn?= =?utf-8?B?N1o5b1RjTDlBMGlhKytERWhseGE1R0c0d0ZYbHdEdCtEcDBkZXUvNU1UQVFZ?= =?utf-8?B?SE4xTzRkQzBCakIwU05pYVBNMnhFWGJzTS85eCtUUzBCMlY4ZUdUSEtKNGh4?= =?utf-8?B?MW82ak53clN1d2ovQmJ1TEw1Q0VDUGtRczJmM2FXV0FiWEtDd05IaTlMd0VG?= =?utf-8?B?dnlwQ1VxR0sveWVwditacm5HWE9LbWhycWJJTUdHT1FLWVNuR0Fhc1hFTFFL?= =?utf-8?B?ZXpvLzJpS3RLN3pZd2Z0Y3FHWmt0bUhGT0VhejBqWFJRNkJFYjNIWkdqS3FQ?= =?utf-8?B?cEZyeFRodElxNWFOUkxRV1I2M2lsR1FzNFlmVHU1aXdCRi9ZRnJzcGRKRDNQ?= =?utf-8?B?VlpyTDFwaTNaMHdkeXd5eFcrL1I4RXFPRHVyK2Z0QldWdGxCM3NMMzdzM3Ux?= =?utf-8?B?ZWNmNEhhcmxYQWJ2bGJaK0NkdzY5OWdWRjVQaGplMjlBQVJLa2E4SjlJTWxw?= =?utf-8?Q?JKlHgVs0jiIlCwZ9ckKy9Jr2KHhBA8J?= X-Microsoft-Exchange-Diagnostics: 1; AMXPR07MB056; 5:xqXKRKLuPmbGChswRgscLu2bFRYg+tMpEuIORm914FC2ewT77K1PlK77tW/+zVXfJX8HsiI8ULraCZaIT5W+3bXtIEtt3JYUMTqHXWsQZ3skFWUwO5UR6cqq3LNDN7gX/MaxIOGqWk5mZ/V17bcS+g==; 24:263ndLs7dr4nqC2nMrDHdX960cVvl2c5y4K47DwNjTu7hEYSYg48+cc2bETfIfGZ3xZ5qG4xKo0+NTngFqx+YZjDUW38VS4q6hZYMmjP/wY=; 20:jxguBRTVEN74y5LOanMepn82Z4ZTiaJcm8h3Aw5PMSVF0nTtoYpsu65AO/aD1Qpl/Pfc0bpSZY/BzAXRheVszw== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Aug 2015 10:37:26.1803 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB056 Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Y34 - root node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 10:37:51 -0000 ----- Original Message ----- From: "Jonathan Hansford" cc: "NETMOD Working Group" Sent: Monday, August 10, 2015 9:46 AM And it is not just end users who need help to better understand YANG models and how to use them. For those still on the edge, looking to finally take the plunge and use NETCONF/YANG to configure their devices, help is also required to determine how best to structure their YANG models, make use of the existing ones, etc. For those who have "grown up" with the developments in NETCONF and YANG, much of this is probably second nature. History suggests otherwise to me. If you look at the evolution of standard modules, such as routing and interfaces, that suggests that those who have been immersed in YANG since NGO make several u-turns on the way to where we now are, which may or may not be the end point. You could also look at 6087 or 6087bis which are extensive but perhaps not comprehensive. Tom Petch But coming to it cold (in the sense of compiling/writing a first set of YANG models for a device; I've been following the netconf/netmod WGs for 3+ years), it still feels very much like a dark art! It is not just the individual modules, it is how to put them together to best manage a device (let alone a system). Jonathan ----- Original Message ----- From: "Einar Nilsen-Nygaard (einarnn)" To:"Andy Bierman" Cc:"NETMOD Working Group" Sent:Sat, 8 Aug 2015 11:10:15 +0000 Subject:Re: [netmod] Y34 - root node Andy, I agree that there is a need for organization of models, but I don’t have a firm position on draft-openconfig-netmod-model-structure/draft-rtgyangdt-rtgwg-device-mod el or draft-bierman-netmod-yang-package. But we absolutely need *something* to help end-users of the models comprehend the overall structure of models, their relationship and how to use them. Cheers, Einar On Aug 4, 2015, at 5:16 PM, Andy Bierman wrote: On Tue, Aug 4, 2015 at 2:34 AM, t.petch wrote: ----- Original Message ----- From: "Andy Bierman" To: "t.petch" Sent: Monday, August 03, 2015 5:17 PM > ----- Original Message ----- > From: "Andy Bierman" > To: "t.petch" > Sent: Monday, August 03, 2015 4:10 PM > > > ----- Original Message ----- > > From: "Andy Bierman" andy@yumaworks.com [7] > > Sent: Saturday, August 01, 2015 7:05 PM > > On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem (acee) > > >>> On 8/1/15, 2:51 AM, j.schoenwaelder@jacobs-university.de [9]> wrote: >>> >>> Section 1.1 in >>> > https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt [10] >>> lists the goals of a generic model structure that will accommodate >> most >>> modern network devices. I guess you don’t agree that these are >> desirable? > > > > The only objection I have to this draft is the insertion of a top-level > > root > > called "device". (Might as well be called "self"). > > There are no sibling nodes planned or intended for > > this node, so it serves as an extra document root. > > > > > > One aspect of YANG I have never grasped is what a root means, if > > anything. > > > > I understand that it is needed for NETCONF (filters) and for YANG > > (augments, constraints) and so must be somewhere and must be > relatively > > stable, but has it any other significance in the data model? > > > > As you may recall, I was involved with SMI first, where the root is > > somewhere up in the sky and life only becomes interesting some six > > levels down the hierarchy and that may colour my thinking. > > > > YANG does a poor job of defining the root for YANG data nodes. > It is sometimes called a datastore (in the abstract). > Technically, YANG borrows the definition from XPath. > YANG just defines top-level data nodes and the parent of > these nodes is the document root. > > There is no protocol or encoding neutral definition, > only an XML-specific definition. > > > > Thanks for that. > > It seems to me that much of the extensive discussion on Y34 (all of > which I have read) is as much political as technical, that is SMI is > hierarchical, top down, perhaps befitting its origins in ISO, whereas > YANG is bottom up. IETF-like. YANG could have had a single tree, but > doesn't. So when I read > > https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt [11] > > I see a plea for a more hierarchical organisation, and when I read > > draft-bjorklund-netmod-openconfig-reply-00 > > I see a response that says we are not like that. > > If so, I doubt that there ever will be a technical solution. > > And I am mindful that when I configure routing in a (Cisco) router, I > have to do some of it under the interface definitions and some of it > under the definition of the routing protocol. Which is life, never > wholy interface-centric and never wholy routing protocol-centric! Are you saying the job would be easier if the path was /device/interfaces/interface instead of just /interfaces/interface? Are you saying that /protocols/routing could not also be defined? Clearly edit-config and copy-config allow both subtrees to be accessed in the same operation, so I don't understand your concern. I have been trying to get the root node to be better defined in the protocols that use YANG (i.e., ncx:root, Y34-04). IMO this is a better approach than defining a YANG module with a special container that all other modules are expected to augment. YANG is designed such that each vendor or SDO is not dependent on other vendors or SDOs in order to define data nodes. Andy I am agreeing with you that adding 'device' brings no technical benefit, rather that the motivation is the opposite of technical (which I referred to as political). I am also agreeing with the current declared consensus on Y34. And yes, YANG is going to give us a large number of modules, some tightly coupled (augments) some loosely so (how many do you need to configure OSPF?) and work in this area will be of benefit now and probably essential in a few years time. That said, I am unsure what such work would be like; I am looking (in despair) at 50 routing area YANG models and wondering how a user will ever get a coherent picture of how to do what they want to do. The "YANG Land Grab" gives a false sense of progress. Reaching WG consensus on every single leaf is hard work. I don't think a collection of 100s of YANG modules is ever going to to be easy to understand. Operators will not examine a NETCONF message, look at 150 module URIs, and say "I know exactly what this device supports". I guess it is up to client tools to do that. I wrote a draft that defines YANG Packages, which can provide a higher level of organization for YANG modules. http://datatracker.ietf.org/doc/draft-bierman-netmod-yang-package/ [12] You and I are apparently in the minority, since the official status is that there is no problem with the current approach, and no need to organize individual YANG modules into any larger abstractions. Tom Petch Andy Andy > Andy > > > The well-specified XPath and YANG root (/) can be > > accessed by all protocol operations, exactly the same > > as a node called 'device'. The actual node name will > > depend on the RPC function (e.g. 'data' or 'config'). > > > > This is more than redundant however. It introduces a "super-module" > > into YANG that every other module is expected to augment. > > YANG is intended to be more loosely coupled than that. > > This introduces an extra node and namespace declaration > > in all protocol messages, increasing message sizes. > > > > It also assumes all existing YANG models will get rewritten to > > account for "/device" in all path and XPath expressions. > > This is highly disruptive to existing deployments. > > Also, multiple data models to edit the same thing causes lots > > of extra complexity in the server (supporting both old > > location and new location). > > > > IMO a resource directory approach is much more realistic. > > The /device tree can contain all the organized NP containers. > > Instead of all the actual data nodes, this tree just has pointers > > to the real location of the resource. (like 301 Moved Permanently) > > > > > Acee > > > > > Andy ** Solution Y34-02 Keep 'anyxml'. Introduce 'anydata' as above but without the 'format' substatement. 'anyxml' would still be used to represent unrestricted XML, as is done in NETCONF. 'anydata' would be an unknown chunk of data that can be modelled with YANG. Can be encoded as xml or json. For example: #+BEGIN_EXAMPLE anydata data; #+END_EXAMPLE ** Solution Y34-05 Same as Y34-02 plus two guidelines adopted from Y34-04: - Keep 'anyxml' unchanged as it is defined in YANG 1.0. This ensures backward compatibility. - Introduce a new 'anydata' statement that represents an unknown chunk of data that can be modeled with YANG - Document that implementations MAY have restrictions for anyxml and that anyxml is not necessarily interoperable; data model writers should use anydata whenever possible. - The guidelines document should say that YANG Doctors will review each use of anyxml in IETF modules when YANG 1.1 is adopted to avoid its use whenever possible. > _______________________________________________ netmod mailing list netmod@ietf.org [13] https://www.ietf.org/mailman/listinfo/netmod Links: ------ [1] mailto:andy@yumaworks.com [2] mailto:ietfc@btconnect.com [3] mailto:andy@yumaworks.com [4] mailto:ietfc@btconnect.com [5] mailto:andy@yumaworks.com [6] mailto:ietfc@btconnect.com [7] mailto:andy@yumaworks.com [8] mailto:acee@cisco.com [9] mailto:j.schoenwaelder@jacobs-university.de [10] https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt [11] https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt [12] http://datatracker.ietf.org/doc/draft-bierman-netmod-yang-package/ [13] mailto:netmod@ietf.org ------------------------------------------------------------------------ -------- > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Tue Aug 11 15:35:10 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 088591A1A55 for ; Tue, 11 Aug 2015 15:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOumJpMghp4S for ; Tue, 11 Aug 2015 15:35:06 -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 E1C011A1A73 for ; Tue, 11 Aug 2015 15:35:05 -0700 (PDT) Received: by labd1 with SMTP id d1so65518794lab.1 for ; Tue, 11 Aug 2015 15:35:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=U9mqzlFtAkbsGTci+cpougVP26c2+01PZEtAG0RZnAI=; b=fxSeHN3fNESyjzuq8EaQQli6oVv30UbC1ziwZmwr6N+WqguQe/PRxte1qmDRrc2q9R xRyBZ+qAk4VDMVEbyJhJyea8DiqwxKwZUW1wUUbn0TH6v0W1D9mf++rK4bQMJ6VN0B13 GyjoWqjr5AZQtfblaK8rFR6W3kt9bv5TBwaMqbgTWTn/mBLFr2britBIOw62Ruz7F1uN wE2kAT0NleG8OKqdkhxqq1MVgucQxGWyJ7y/gF7Ou4pCOhthzKcfx+5dDrNM/Z/hlzsg Pz8q/BfT45VbFGSvCrw8qlrAeBqSDaAo5LBk+IWoMb+yVO7GXaHZd07EeoNc8PMfillu O4QA== X-Gm-Message-State: ALoCoQk8mabCOguNaxG/vfRHOt/Il4onTaWLQ0+Gac3aBFcgYSePV/1a1tF7Gg4s0/wRlSG2sTsY MIME-Version: 1.0 X-Received: by 10.152.120.198 with SMTP id le6mr29058041lab.38.1439332504349; Tue, 11 Aug 2015 15:35:04 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Tue, 11 Aug 2015 15:35:04 -0700 (PDT) In-Reply-To: <20150811071246.GA18393@elstar.local> References: <55C4B9DB.1030400@rob.sh> <20150807141439.GA76991@elstar.local> <55C4C346.406@rob.sh> <20150807153909.GA182@elstar.local> <55C5054C.1090704@rob.sh> <20150811071246.GA18393@elstar.local> Date: Tue, 11 Aug 2015 15:35:04 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Rob Shakir , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=089e01176905a2cd27051d10b62c Archived-At: Subject: Re: [netmod] draft-openconfig-netmod-opstate: Changes in -01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 22:35:09 -0000 --089e01176905a2cd27051d10b62c Content-Type: text/plain; charset=UTF-8 On Tue, Aug 11, 2015 at 12:12 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Fri, Aug 07, 2015 at 03:21:48PM -0400, Rob Shakir wrote: > > > > > > Juergen Schoenwaelder wrote: > > >But you are right, it is not just the path that is needed to identify > > >data residing in configuration datastores. It is in general a tuple > > > and for configuration data the selector is a > > >configuration datastore name. > > > > Thanks for the clarification. Do you have examples of other (i.e., > > non-NETCONF) systems that utilise this convention that a path is not an > > absolute reference to a certain data node? Reviewing with various > > interested parties, I'm not sure that there are clear cases that form a > > precedent for this. > > SNMP has an even more complex naming scheme. > > > If we consider that this then might drive some new behaviour where the > > systems architecture for NMS differs from elsewhere then we might want > > to question whether this is necessary complexity. Indeed, for me this > > comes back to one of the discussions about the other datastores that we > > had on an interim call. > > > * 'startup' is really a property of the intended configuration - as to > > whether it has been made persistent. In general, I see very few changes > > that are made where we interact only with the persistent version of the > > intended configuration; and even fewer where the intended configuration > > is not made persistent. In both cases, it tends to be the lack of a > > declarative configuration API that drives the need to interact with > either. > > You can have a NETCONF server without 'startup' and it still has > persistent running config. I have no clue what 'the lack of a > declarative configuration API' means. > > The startup datastore simply represents the config that will be used at the next reboot. It is useful to compare the running config to candidate or startup. > > * 'candidate' is again a property of the intended configuration - > > insofar that the 'candidate' set of configuration represents a set of > > changes that have not been requested to be transitioned to the 'applied > > configuration'. This makes sense when a human is working through > > building up a transaction (configure protocol X, protocol Y .. protocol > > Z, then commit) - but isn't quite so clear when it programmatic > > interaction with the network. > > There are commercial implementations that make use of candidate > datastores and the transaction, validation and rollback capabilities > they provide. You may decide that you do not need them but this does > not imply that nobody else will need them. > > RFC 6241 should be clear that the candidate is a scratchpad. It has no effect on the system unless and until a is attempted. Since NETCONF (incorrectly) couples the confirmed commit procedure with the candidate config, it is useful to programmatic APIs. In reality, confirmed commit has absolutely nothing to do with candidate, but there seems to be no interest in fixing that. > > It is quite trivial for me to see cases where an external NMS would > > never really need to interact with either of these datastores - such > > that it's quite tricky for me to determine that we really want to > > architect the entire NMS to be able to carry the tuple > > (stealing your terms, thanks!), especially if this means that it has to > > work entirely differently w.r.t paths than the rest of OSS. > > It is certainly up to you how you architect your NMS the way to think > it works best. I am just trying to explain how NETCONF and YANG > work. But I would expect that an NMS is able to integrate namespaces. > > We should not dumb-down the standard to support dumb NMS software. Datastores and namespaces are part of the standard. Neither are difficult to implement. The approach allows us to use the same path in > different datastores, this is considered to be a feature and not a > bug. > > /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --089e01176905a2cd27051d10b62c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Aug 11, 2015 at 12:12 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Fri, Aug 07, 2015 at 03:21:48PM -0400, Rob Shaki= r wrote:
>
>
> Juergen Schoenwaelder wrote:
> >But you are right, it is not just the path that is needed to ident= ify
> >data residing in configuration datastores. It is in general a tupl= e
> ><selector, path>=C2=A0 and for configuration data the select= or is a
> >configuration datastore name.
>
> Thanks for the clarification. Do you have examples of other (i.e.,
> non-NETCONF) systems that utilise this convention that a path is not a= n
> absolute reference to a certain data node? Reviewing with various
> interested parties, I'm not sure that there are clear cases that f= orm a
> precedent for this.

SNMP has an even more complex naming scheme.

> If we consider that this then might drive some new behaviour where the=
> systems architecture for NMS differs from elsewhere then we might want=
> to question whether this is necessary complexity. Indeed, for me this<= br> > comes back to one of the discussions about the other datastores that w= e
> had on an interim call.

>=C2=A0 * 'startup' is really a property of the intended configu= ration - as to
> whether it has been made persistent. In general, I see very few change= s
> that are made where we interact only with the persistent version of th= e
> intended configuration; and even fewer where the intended configuratio= n
> is not made persistent. In both cases, it tends to be the lack of a > declarative configuration API that drives the need to interact with ei= ther.

You can have a NETCONF server without 'startup' and it still has persistent running config. I have no clue what 'the lack of a
declarative configuration API' means.



The startup datastore s= imply represents the config that will be used
at the next reboot.=

It is useful to compare the running config to can= didate or startup.

=C2=A0
>=C2=A0 * 'candidate' is again a property of the intended config= uration -
> insofar that the 'candidate' set of configuration represents a= set of
> changes that have not been requested to be transitioned to the 'ap= plied
> configuration'. This makes sense when a human is working through > building up a transaction (configure protocol X, protocol Y .. protoco= l
> Z, then commit) - but isn't quite so clear when it programmatic > interaction with the network.

There are commercial implementations that make use of candidate
datastores and the transaction, validation and rollback capabilities
they provide. You may decide that you do not need them but this does
not imply that nobody else will need them.



RFC 6241 should be clear that the candidate is a scratchpad.
It= has no effect on the system unless and until a <commit> is attempted= .
Since NETCONF (incorrectly) couples the confirmed commit proced= ure
with the candidate config, it is useful to programmatic APIs.=
In reality, confirmed commit has absolutely nothing to do with
candidate, but there seems to be no interest in fixing that.
=


=C2=A0
> It is quite trivial for me to see cases where an external NMS would > never really need to interact with either of these datastores - such > that it's quite tricky for me to determine that we really want to<= br> > architect the entire NMS to be able to carry the <selector,path>= tuple
> (stealing your terms, thanks!), especially if this means that it has t= o
> work entirely differently w.r.t paths than the rest of OSS.

It is certainly up to you how you architect your NMS the way to think
it works best. I am just trying to explain how NETCONF and YANG
work. But I would expect that an NMS is able to integrate namespaces.


We should not dumb-down the standard t= o support dumb NMS software.
Datastores and namespaces are part o= f the standard.=C2=A0 Neither are
difficult to implement.

The <selector, path> approach allows us to use the same path in
different datastores, this is considered to be a feature and not a
bug.

/js


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

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

--089e01176905a2cd27051d10b62c-- From nobody Thu Aug 13 07:07:54 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0ABA1B2DA3 for ; Thu, 13 Aug 2015 07:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_75=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOUkaO49bsSo for ; Thu, 13 Aug 2015 07:07:52 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1FD1B2DA2 for ; Thu, 13 Aug 2015 07:07:51 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 9B27E1CC0362 for ; Thu, 13 Aug 2015 16:07:50 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Thu, 13 Aug 2015 16:07:49 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [netmod] Y26 again, sorry X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 14:07:54 -0000 Hi, although YANG 1.1 issue Y26 [1] is marked as DONE, I think the adopted solution Y26-02 is really horrible, so at least I want to make sure the WG is aware of the consequences. I am currently working on a data model for DNS zone data and the schema is like this: module: dns-zones +--rw zones +--rw zone* [name] +--rw name inet:domain-name +--rw description? string +--rw class? ianadns:class +--rw rrset* [owner type] +--rw owner inet:domain-name +--rw type identityref +--rw description? string +--rw ttl positive-int32 +--rw rdata* [id] +--rw id string +--rw description? string The idea is that specific RDATA will be added for each RR type (with a "when" condition based on "type"). Data for essential RR Types (SOA, NS, A, AAAA, ...) can be defined in the same module but for some types they need to be defined in other modules and added via augmenting the target node "rdata". Typically, some (or all) of RDATA is mandatory, and this is where Y26 comes into play. The solution recommended by Y26-02 would look like this: augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" { when "derived-from-or-self(../dnsz:type,'iana-dns-parameters'," + "'TLSA')"; container rdata { // <================= presence "TLSA data"; leaf certificate-usage { mandatory true; ... } ... } } Note the superfluous presence container "rdata". It that just adds a useless level of hierarchy and still doesn't enforce the correct constraints: the data model allows the presence container to be missing so that RDATA will be empty. Defining this extra container for all ~75 RR types is a nuisance and it certainly won't make the modules more readable. As this situation is likely to be very common, I wonder: do we really want to do that? [1] https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-27 Thanks, Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Aug 13 07:45:00 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5571A21B0 for ; Thu, 13 Aug 2015 07:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.311 X-Spam-Level: X-Spam-Status: No, score=-13.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_24=0.6, J_CHICKENPOX_75=0.6, 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 wfq_wp5zkKma for ; Thu, 13 Aug 2015 07:44:57 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DE221A21B8 for ; Thu, 13 Aug 2015 07:44:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4488; q=dns/txt; s=iport; t=1439477096; x=1440686696; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=1jgHHc/O7YH98F/Mglnxns79NtGqI0boCAHAGgFf6r8=; b=dkc9hLyfGaPS4YV/Nqh/AJAqL2hWjgPy5tEViOKWKgV0AEGPFMByhppK I75GAvAkRuEQvHTMDBieSpRSnPULPwkmYgeiT7FaP+nCa3oWyc/mwCyHY G+TbCvBEA0PVKWwtftsDPEatuOe1CltU10k264uOX/5/AF4KdsGQG2b6V 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CcBACDrMxV/xbLJq1dg29pv3+FeQKCCQEBAQEBAYELhCQBAQQ4QBELGAkWDwkDAgECAUUGAQwIAQEXiBMN0UsBAQEBAQEBAQEBAQEBAQEBAQEWBItTgj2CGTqELAEEjFqIQIUEh2iIbJE2JoN+PTMBAQGCSQEBAQ X-IronPort-AV: E=Sophos;i="5.15,670,1432598400"; d="scan'208";a="605016301" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 13 Aug 2015 14:44:54 +0000 Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t7DEisHN013967; Thu, 13 Aug 2015 14:44:54 GMT To: Ladislav Lhotka , netmod@ietf.org References: From: Robert Wilton Message-ID: <55CCAD66.6070907@cisco.com> Date: Thu, 13 Aug 2015 15:44:54 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Y26 again, sorry X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 14:44:59 -0000 Hi Lada, I agree with you in that I don't really understand how having a p-container solves the problem of a mandatory node, since as you say the p-container could just be left out so to me it seems that any child node marks as mandatory isn't truly mandatory anyway! I have a similar issue in the YANG that I have defined in draft-wilton-netmod-intf-ext-yang-00 (reproduced below) for defining the nature of a sub-interface. Basically, I would like the model to enforce the rule that every child sub-interface must have a parent, but I can't currently really see a satisfactory solution to this problem. My working assumption is that I would end up describing the field as being mandatory, but not mark it as mandatory in YANG (obviously), and assume that backend servers would enforce that the leaf is present when the configuration is verified. But I'm open to any better suggestions that folks may have on how to model this :-) Hi, > > although YANG 1.1 issue Y26 [1] is marked as DONE, I think the adopted > solution Y26-02 is really horrible, so at least I want to make sure the > WG is aware of the consequences. > > I am currently working on a data model for DNS zone data and the schema > is like this: > > module: dns-zones > +--rw zones > +--rw zone* [name] > +--rw name inet:domain-name > +--rw description? string > +--rw class? ianadns:class > +--rw rrset* [owner type] > +--rw owner inet:domain-name > +--rw type identityref > +--rw description? string > +--rw ttl positive-int32 > +--rw rdata* [id] > +--rw id string > +--rw description? string > > The idea is that specific RDATA will be added for each RR type (with a > "when" condition based on "type"). Data for essential RR Types (SOA, NS, > A, AAAA, ...) can be defined in the same module but for some types they > need to be defined in other modules and added via augmenting the target > node "rdata". Typically, some (or all) of RDATA is mandatory, and this > is where Y26 comes into play. The solution recommended by Y26-02 would > look like this: > > augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" { > when "derived-from-or-self(../dnsz:type,'iana-dns-parameters'," > + "'TLSA')"; > container rdata { // <================= > presence "TLSA data"; > leaf certificate-usage { > mandatory true; > ... > } > ... > } > } > > Note the superfluous presence container "rdata". It that just adds a > useless level of hierarchy and still doesn't enforce the correct > constraints: the data model allows the presence container to be missing > so that RDATA will be empty. Defining this extra container for all ~75 > RR types is a nuisance and it certainly won't make the modules more > readable. > > As this situation is likely to be very common, I wonder: do we really > want to do that? > > [1] https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-27 > > Thanks, Lada > From nobody Thu Aug 13 07:46:15 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEF921A6ED9 for ; Thu, 13 Aug 2015 07:46:13 -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_75=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 81bgniTc6ey2 for ; Thu, 13 Aug 2015 07:46:12 -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 B77481A21B8 for ; Thu, 13 Aug 2015 07:46:11 -0700 (PDT) Received: by labd1 with SMTP id d1so27587847lab.1 for ; Thu, 13 Aug 2015 07:46: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:cc:content-type; bh=+p4br6fc8BUtFo0YouQyiaUIW6tOLRQUee4ObRur4qg=; b=l2PUMW2cmubEYkLv3L5qDsAaIdgKp+bm138pTrbIz/8C2AtX1hweXcBJh+L4tMqQHS uVQtXghXVciCfKoRpvvvDtlVshp/phwRnK/hIX4gccrcc82Pjrdwrcx+Ug9HWw0BMVmR r5HsKoawB92EJxtEubuS2EnZu7pbB3bLCVZYqx+824KYbIM3yFrztchGx08thETE7WzF 7XvPDKpIVCjcmf5GSEl5DBLfzu7sOd4yIUQ99Cjl6RHTBDxJjbaT3iEbGBywKJvOu1NH +S7s+kgCWKzje5OqaolbIMAekPCzgf+JemtwMwodKTIEFW18yYbmlRb3Sn5hMWEaAjDI /IfQ== X-Gm-Message-State: ALoCoQln1pQQcLBlgNMiMFuH9X/FMl7W4Qi4zD1y6aQxlh+ZeO2yiWqj4+OQCt2kk/FyZtVfk7rh MIME-Version: 1.0 X-Received: by 10.112.46.130 with SMTP id v2mr36513917lbm.119.1439477170259; Thu, 13 Aug 2015 07:46:10 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Thu, 13 Aug 2015 07:46:10 -0700 (PDT) In-Reply-To: References: Date: Thu, 13 Aug 2015 07:46:10 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a1134aee86563d8051d326502 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y26 again, sorry X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 14:46:14 -0000 --001a1134aee86563d8051d326502 Content-Type: text/plain; charset=UTF-8 Hi, I'm not sure how many times we need to go over this issue... YANG conformance is based on the YANG module. YANG has no concept of conformance beyond this simplistic approach, You cannot assume (ever, under any conditions) that module foo AND bar will both be present on a server. Therefore if a client is written to work with "foo", it has no responsibility at all to know that "bar" adds a mandatory node to a "foo" subtree. The extra P-container is needed to make sure clients written to work with module "foo" do not break when new nodes are added via augments. We already decided not to do anything useful wrt/ Y45, so we are stuck with the YANG module as the unit of conformance. Andy On Thu, Aug 13, 2015 at 7:07 AM, Ladislav Lhotka wrote: > Hi, > > although YANG 1.1 issue Y26 [1] is marked as DONE, I think the adopted > solution Y26-02 is really horrible, so at least I want to make sure the > WG is aware of the consequences. > > I am currently working on a data model for DNS zone data and the schema > is like this: > > module: dns-zones > +--rw zones > +--rw zone* [name] > +--rw name inet:domain-name > +--rw description? string > +--rw class? ianadns:class > +--rw rrset* [owner type] > +--rw owner inet:domain-name > +--rw type identityref > +--rw description? string > +--rw ttl positive-int32 > +--rw rdata* [id] > +--rw id string > +--rw description? string > > The idea is that specific RDATA will be added for each RR type (with a > "when" condition based on "type"). Data for essential RR Types (SOA, NS, > A, AAAA, ...) can be defined in the same module but for some types they > need to be defined in other modules and added via augmenting the target > node "rdata". Typically, some (or all) of RDATA is mandatory, and this > is where Y26 comes into play. The solution recommended by Y26-02 would > look like this: > > augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" { > when "derived-from-or-self(../dnsz:type,'iana-dns-parameters'," > + "'TLSA')"; > container rdata { // <================= > presence "TLSA data"; > leaf certificate-usage { > mandatory true; > ... > } > ... > } > } > > Note the superfluous presence container "rdata". It that just adds a > useless level of hierarchy and still doesn't enforce the correct > constraints: the data model allows the presence container to be missing > so that RDATA will be empty. Defining this extra container for all ~75 > RR types is a nuisance and it certainly won't make the modules more > readable. > > As this situation is likely to be very common, I wonder: do we really > want to do that? > > [1] https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-27 > > Thanks, Lada > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a1134aee86563d8051d326502 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,


I'm not sure how= many times we need to go over this issue...

YANG = conformance is based on the YANG module.
YANG has no concept of c= onformance beyond this
simplistic approach, =C2=A0You cannot assu= me (ever, under any conditions)
that module foo AND bar will both= be present on a server.

Therefore if a client is = written to work with "foo", it has no
responsibility at= all to know that "bar" adds a mandatory
node to a &quo= t;foo" subtree.

The extra P-container is need= ed to make sure clients written
to work with module "foo&quo= t; do not break when new nodes are
added via augments.
=
We already decided not to do anything useful wrt/ Y45,
=
so we are stuck with the YANG module as the unit of conformance.
=


Andy


=


On Thu, Aug 13, 2015 at 7:07 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:
Hi,

although YANG 1.1 issue Y26 [1] is marked as DONE, I think the adopted
solution Y26-02 is really horrible, so at least I want to make sure the
WG is aware of the consequences.

I am currently working on a data model for DNS zone data and the schema
is like this:

module: dns-zones
=C2=A0 =C2=A0+--rw zones
=C2=A0 =C2=A0 =C2=A0 +--rw zone* [name]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw name=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0inet:domain-name
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw description?=C2=A0 =C2=A0string
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw class?=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0ianadns:class
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw rrset* [owner type]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw owner=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 inet:domain-name
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw type=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0identityref
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw description?=C2=A0 =C2=A0st= ring
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw ttl=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 positive-int32
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw rdata* [id]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw id=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0string
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw description?= =C2=A0 =C2=A0string

The idea is that specific RDATA will be added for each RR type (with a
"when" condition based on "type"). Data for essential R= R Types (SOA, NS,
A, AAAA, ...) can be defined in the same module but for some types they
need to be defined in other modules and added via augmenting the target
node "rdata". Typically, some (or all) of RDATA is mandatory, and= this
is where Y26 comes into play. The solution recommended by Y26-02 would
look like this:

augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" {
=C2=A0 =C2=A0 when "derived-from-or-self(../dnsz:type,'iana-dns-pa= rameters',"
=C2=A0 =C2=A0 =C2=A0 =C2=A0+ "'TLSA')";
=C2=A0 =C2=A0 container rdata {=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 //= <=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=C2=A0 =C2=A0 =C2=A0 =C2=A0 presence "TLSA data";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf certificate-usage {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mandatory true;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 }
}

Note the superfluous presence container "rdata". It that just add= s a
useless level of hierarchy and still doesn't enforce the correct
constraints: the data model allows the presence container to be missing
so that RDATA will be empty. Defining this extra container for all ~75
RR types is a nuisance and it certainly won't make the modules more
readable.

As this situation is likely to be very common, I wonder: do we really
want to do that?

[1] https://svn.tools.ietf.org/s= vn/wg/netmod/yang-1.1/issues.html#sec-27

Thanks, Lada

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

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

--001a1134aee86563d8051d326502-- From nobody Thu Aug 13 08:40:08 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 171C41A8840 for ; Thu, 13 Aug 2015 08:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.91 X-Spam-Level: X-Spam-Status: No, score=-13.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_75=0.6, 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 YfPHSzZGftlb for ; Thu, 13 Aug 2015 08:40:04 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D4F31A8835 for ; Thu, 13 Aug 2015 08:40:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13192; q=dns/txt; s=iport; t=1439480401; x=1440690001; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=c/MMy4+yYDTDRU4IytYY5K9C8wnGpkRw2f/w9FQzdc8=; b=cpP5FdjfXzxwtPLQlQrP8G/qqDlF88L6fzamebONsNmRw+A6J1Yqs4ez 0UBvMwBgTqiipApu42qKmSjQ6hMMMxWnCbXaMHbkZcAaBrS9QhuwupTNP ZFMI0Ef4kaQ9K81bXhClST/Crfy0lcW4rI/HMNUNDbgZMEr1Iky87+Biu 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BFAgBqucxV/xbLJq1dg29pvgABCYFrAQmFL0oCgXgUAQEBAQEBAYEKhCMBAQEDAQEBAWsKARALGAkWCAcJAwIBAgEVHxEGAQwGAgEBF4gLCA3ROwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEi1OCPYIBSweELAWMWoUzgw2FBIdoiGyRNiaDfj0zAQEBgkkBAQE X-IronPort-AV: E=Sophos;i="5.15,670,1432598400"; d="scan'208,217";a="609654908" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 13 Aug 2015 15:39:59 +0000 Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t7DFdx3x006234; Thu, 13 Aug 2015 15:39:59 GMT To: Andy Bierman , Ladislav Lhotka References: From: Robert Wilton Message-ID: <55CCBA4F.9010101@cisco.com> Date: Thu, 13 Aug 2015 16:39:59 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------020306090807090001020109" Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y26 again, sorry X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 15:40:07 -0000 This is a multi-part message in MIME format. --------------020306090807090001020109 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Andy, Lada, On 13/08/2015 15:46, Andy Bierman wrote: > Hi, > > > I'm not sure how many times we need to go over this issue... > > YANG conformance is based on the YANG module. > YANG has no concept of conformance beyond this > simplistic approach, You cannot assume (ever, under any conditions) > that module foo AND bar will both be present on a server. > > Therefore if a client is written to work with "foo", it has no > responsibility at all to know that "bar" adds a mandatory > node to a "foo" subtree. > > The extra P-container is needed to make sure clients written > to work with module "foo" do not break when new nodes are > added via augments. I still don't see how a P-container really solves the problem since any child mandatory nodes aren't really mandatory, or at least not in the way that is actually intended. E.g. in Lada's example having the P-container implies that for a given RR type it is acceptable to either not provide any extra RR specific config (i.e. no P-container), or if RR specific config is provided then some fields must always be provided, and others can be left out. I.e. the P-container also needs to be mandatory for the configuration to be sane. To me, in this scenario, it feels that you might as well forego both the P-container and mandatory marking. Thanks, Rob > > We already decided not to do anything useful wrt/ Y45, > so we are stuck with the YANG module as the unit of conformance. > > > Andy > > > > > On Thu, Aug 13, 2015 at 7:07 AM, Ladislav Lhotka > wrote: > > Hi, > > although YANG 1.1 issue Y26 [1] is marked as DONE, I think the adopted > solution Y26-02 is really horrible, so at least I want to make > sure the > WG is aware of the consequences. > > I am currently working on a data model for DNS zone data and the > schema > is like this: > > module: dns-zones > +--rw zones > +--rw zone* [name] > +--rw name inet:domain-name > +--rw description? string > +--rw class? ianadns:class > +--rw rrset* [owner type] > +--rw owner inet:domain-name > +--rw type identityref > +--rw description? string > +--rw ttl positive-int32 > +--rw rdata* [id] > +--rw id string > +--rw description? string > > The idea is that specific RDATA will be added for each RR type (with a > "when" condition based on "type"). Data for essential RR Types > (SOA, NS, > A, AAAA, ...) can be defined in the same module but for some types > they > need to be defined in other modules and added via augmenting the > target > node "rdata". Typically, some (or all) of RDATA is mandatory, and this > is where Y26 comes into play. The solution recommended by Y26-02 would > look like this: > > augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" { > when "derived-from-or-self(../dnsz:type,'iana-dns-parameters'," > + "'TLSA')"; > container rdata { // <================= > presence "TLSA data"; > leaf certificate-usage { > mandatory true; > ... > } > ... > } > } > > Note the superfluous presence container "rdata". It that just adds a > useless level of hierarchy and still doesn't enforce the correct > constraints: the data model allows the presence container to be > missing > so that RDATA will be empty. Defining this extra container for all ~75 > RR types is a nuisance and it certainly won't make the modules more > readable. > > As this situation is likely to be very common, I wonder: do we really > want to do that? > > [1] > https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-27 > > Thanks, Lada > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------020306090807090001020109 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Andy, Lada,

On 13/08/2015 15:46, Andy Bierman wrote:
Hi,


I'm not sure how many times we need to go over this issue...

YANG conformance is based on the YANG module.
YANG has no concept of conformance beyond this
simplistic approach, You cannot assume (ever, under any conditions)
that module foo AND bar will both be present on a server.

Therefore if a client is written to work with "foo", it has no
responsibility at all to know that "bar" adds a mandatory
node to a "foo" subtree.

The extra P-container is needed to make sure clients written
to work with module "foo" do not break when new nodes are
added via augments.

I still don't see how a P-container really solves the problem since any child mandatory nodes aren't really mandatory, or at least not in the way that is actually intended.

E.g. in Lada's example having the P-container implies that for a given RR type it is acceptable to either not provide any extra RR specific config (i.e. no P-container), or if RR specific config is provided then some fields must always be provided, and others can be left out. I.e. the P-container also needs to be mandatory for the configuration to be sane.

To me, in this scenario, it feels that you might as well forego both the P-container and mandatory marking.

Thanks,
Rob



We already decided not to do anything useful wrt/ Y45,
so we are stuck with the YANG module as the unit of conformance.


Andy




On Thu, Aug 13, 2015 at 7:07 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
Hi,

although YANG 1.1 issue Y26 [1] is marked as DONE, I think the adopted
solution Y26-02 is really horrible, so at least I want to make sure the
WG is aware of the consequences.

I am currently working on a data model for DNS zone data and the schema
is like this:

module: dns-zones
+--rw zones
+--rw zone* [name]
+--rw name inet:domain-name
+--rw description? string
+--rw class? ianadns:class
+--rw rrset* [owner type]
+--rw owner inet:domain-name
+--rw type identityref
+--rw description? string
+--rw ttl positive-int32
+--rw rdata* [id]
+--rw id string
+--rw description? string

The idea is that specific RDATA will be added for each RR type (with a
"when" condition based on "type"). Data for essential RR Types (SOA, NS,
A, AAAA, ...) can be defined in the same module but for some types they
need to be defined in other modules and added via augmenting the target
node "rdata". Typically, some (or all) of RDATA is mandatory, and this
is where Y26 comes into play. The solution recommended by Y26-02 would
look like this:

augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" {
when "derived-from-or-self(../dnsz:type,'iana-dns-parameters',"
+ "'TLSA')";
container rdata { // <=================
presence "TLSA data";
leaf certificate-usage {
mandatory true;
...
}
...
}
}

Note the superfluous presence container "rdata". It that just adds a
useless level of hierarchy and still doesn't enforce the correct
constraints: the data model allows the presence container to be missing
so that RDATA will be empty. Defining this extra container for all ~75
RR types is a nuisance and it certainly won't make the modules more
readable.

As this situation is likely to be very common, I wonder: do we really
want to do that?

[1] https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-27

Thanks, Lada

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

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



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

--------------020306090807090001020109-- From nobody Thu Aug 13 09:08:37 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC3951B2E26 for ; Thu, 13 Aug 2015 09:08:35 -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_75=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 O41UoB5NqMPM for ; Thu, 13 Aug 2015 09:08:33 -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 0FECF1B2E18 for ; Thu, 13 Aug 2015 09:08:33 -0700 (PDT) Received: by lbbtg9 with SMTP id tg9so30086874lbb.1 for ; Thu, 13 Aug 2015 09:08:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=XE58xJc/xHp6Vfo+Pcw2TzCb3y8TeQ1TqjhCmxHrLAk=; b=ZC5+Zn+waorBayzsexouB7UO9105+ozYfdzeAqx0y38sq/aPlYTPq63PjCdud+jEj+ 9mCWK3W61udfKWgziCOvR+kLy8s7c9GsT3RNyllKGGpjwYayek4WMcahp1xjzTe9OCKF o5q+Os1NwZQPYZIp5EHZNvFMaFLK8dg8nBrAJsi9bRybbfJ9m0urh6J6Mz8zpgdfilGI 1gN/p3Shny9gKfCn7mnrDy7AF/yLhMAzU77T9kG9L0AX8K+fdmkk8boC8ItwQ8DVjEVL yF7cuW+bA1RIvrgK0aSaJk59Bo3huT2lMzXwY8zqyDT9rumKu9LQ+r70FvaMUgR5aUu9 kl7A== X-Gm-Message-State: ALoCoQn1ak86WWbTYwKmiBcqz2b8bVvcVq5CM9+QAwWUV6GpRHub9ZKDgs61sETFahV+G3gYm5tn MIME-Version: 1.0 X-Received: by 10.152.42.209 with SMTP id q17mr36939615lal.33.1439482111576; Thu, 13 Aug 2015 09:08:31 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Thu, 13 Aug 2015 09:08:31 -0700 (PDT) In-Reply-To: <55CCBA4F.9010101@cisco.com> References: <55CCBA4F.9010101@cisco.com> Date: Thu, 13 Aug 2015 09:08:31 -0700 Message-ID: From: Andy Bierman To: Robert Wilton Content-Type: multipart/alternative; boundary=001a11c34b6cebe31d051d338b61 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y26 again, sorry X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 16:08:36 -0000 --001a11c34b6cebe31d051d338b61 Content-Type: text/plain; charset=UTF-8 On Thu, Aug 13, 2015 at 8:39 AM, Robert Wilton wrote: > Hi Andy, Lada, > > On 13/08/2015 15:46, Andy Bierman wrote: > > Hi, > > > I'm not sure how many times we need to go over this issue... > > YANG conformance is based on the YANG module. > YANG has no concept of conformance beyond this > simplistic approach, You cannot assume (ever, under any conditions) > that module foo AND bar will both be present on a server. > > > Therefore if a client is written to work with "foo", it has no > responsibility at all to know that "bar" adds a mandatory > node to a "foo" subtree. > > > The extra P-container is needed to make sure clients written > to work with module "foo" do not break when new nodes are > added via augments. > > > I still don't see how a P-container really solves the problem since any > child mandatory nodes aren't really mandatory, or at least not in the way > that is actually intended. > > The concepts behind old-manager/new-agent protection mechanisms go back a couple decades (with SNMP). There is no way that a vendor can control all the applications using a particular module, and therefore mandate a flag-day upgrade on all clients, in order to upgrade some servers. YANG is very limited wrt/ adding new functionality, A designer must guess correctly on all mandatory nodes on the first version. If this a bug, then it should be fixed properly, instead of just pretending it's OK to break existing client apps. (YANG packages do not fix this problem BTW) Perhaps we need a new module-level "release" statement. release stable; release unstable; release experimental; Then all the very strict YANG change control rules can be relaxed on unstable and experimental modules. E.g. in Lada's example having the P-container implies that for a given RR > type it is acceptable to either not provide any extra RR specific config > (i.e. no P-container), or if RR specific config is provided then some > fields must always be provided, and others can be left out. I.e. the > P-container also needs to be mandatory for the configuration to be sane. > > A P-container insulates the old client because it would not know to create it, and the mandatory child nodes are only checked if the P-container exists. > To me, in this scenario, it feels that you might as well forego both the > P-container and mandatory marking. > > Thanks, > Rob > > > Andy > > We already decided not to do anything useful wrt/ Y45, > so we are stuck with the YANG module as the unit of conformance. > > > Andy > > > > > On Thu, Aug 13, 2015 at 7:07 AM, Ladislav Lhotka wrote: > >> Hi, >> >> although YANG 1.1 issue Y26 [1] is marked as DONE, I think the adopted >> solution Y26-02 is really horrible, so at least I want to make sure the >> WG is aware of the consequences. >> >> I am currently working on a data model for DNS zone data and the schema >> is like this: >> >> module: dns-zones >> +--rw zones >> +--rw zone* [name] >> +--rw name inet:domain-name >> +--rw description? string >> +--rw class? ianadns:class >> +--rw rrset* [owner type] >> +--rw owner inet:domain-name >> +--rw type identityref >> +--rw description? string >> +--rw ttl positive-int32 >> +--rw rdata* [id] >> +--rw id string >> +--rw description? string >> >> The idea is that specific RDATA will be added for each RR type (with a >> "when" condition based on "type"). Data for essential RR Types (SOA, NS, >> A, AAAA, ...) can be defined in the same module but for some types they >> need to be defined in other modules and added via augmenting the target >> node "rdata". Typically, some (or all) of RDATA is mandatory, and this >> is where Y26 comes into play. The solution recommended by Y26-02 would >> look like this: >> >> augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" { >> when "derived-from-or-self(../dnsz:type,'iana-dns-parameters'," >> + "'TLSA')"; >> container rdata { // <================= >> presence "TLSA data"; >> leaf certificate-usage { >> mandatory true; >> ... >> } >> ... >> } >> } >> >> Note the superfluous presence container "rdata". It that just adds a >> useless level of hierarchy and still doesn't enforce the correct >> constraints: the data model allows the presence container to be missing >> so that RDATA will be empty. Defining this extra container for all ~75 >> RR types is a nuisance and it certainly won't make the modules more >> readable. >> >> As this situation is likely to be very common, I wonder: do we really >> want to do that? >> >> [1] https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-27 >> >> Thanks, Lada >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > > > > _______________________________________________ > netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod > > > --001a11c34b6cebe31d051d338b61 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Aug 13, 2015 at 8:39 AM, Robert Wilton <rwilton@cisco.com&= gt; wrote:
=20 =20 =20
Hi Andy, Lada,

On 13/08/2015 15:46, Andy Bierman wrote:
=20
Hi,


I'm not sure how many times we need to go over this issue...

YANG conformance is based on the YANG module.
YANG has no concept of conformance beyond this
simplistic approach, =C2=A0You cannot assume (ever, under any conditions)
that module foo AND bar will both be present on a server.

Therefore if a client is written to work with "foo",= it has no
responsibility at all to know that "bar" adds a mand= atory
node to a "foo" subtree.

The extra P-container is needed to make sure clients written
to work with module "foo" do not break when new node= s are
added via augments.

I still don't see how a P-container really solves the problem since any child mandatory nodes aren't really mandatory, or at least not in the way that is actually intended.



The concepts = behind old-manager/new-agent protection mechanisms go back
a coup= le decades (with SNMP).=C2=A0 There is no way that a vendor can control all=
the applications using a particular module, and therefore mandat= e a flag-day
upgrade on all clients, in order to upgrade some ser= vers.


YANG is very limited wrt/ add= ing new functionality,
A designer must guess correctly on all man= datory nodes
on the first version.=C2=A0 If this a bug, then it s= hould be fixed
properly, instead of just pretending it's OK t= o break
existing client apps.

(YANG pack= ages do not fix this problem BTW)

Perhaps we need = a new module-level "release" statement.

= =C2=A0 =C2=A0release stable;
=C2=A0 =C2=A0release unstable;
=
=C2=A0 =C2=A0release experimental;

Then all t= he very strict YANG change control rules can be relaxed on
unstab= le and experimental modules.



E.g. in Lada's example having the P-container implies that for a given RR type it is acceptable to either not provide any extra RR specific config (i.e. no P-container), or if RR specific config is provided then some fields must always be provided, and others can be left out.=C2=A0 I.e. the P-container also needs to be mandatory for the configuration to be sane.


A P-container insulates the = old client because it would not know to
create it, and the mandat= ory child nodes are only checked if
the P-container exists.
=

=C2=A0
To me, in this scenario, it feels that you might as well forego both the P-container and mandatory marking.

Thanks,
Rob




Andy

=C2=A0

We already decided not to do anything useful wrt/ Y45,
so we are stuck with the YANG module as the unit of conformance.


Andy




On Thu, Aug 13, 2015 at 7:07 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
Hi,

although YANG 1.1 issue Y26 [1] is marked as DONE, I think the adopted
solution Y26-02 is really horrible, so at least I want to make sure the
WG is aware of the consequences.

I am currently working on a data model for DNS zone data and the schema
is like this:

module: dns-zones
=C2=A0 =C2=A0+--rw zones
=C2=A0 =C2=A0 =C2=A0 +--rw zone* [name]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw name=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0inet:domain-name
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw description?=C2=A0 =C2= =A0string
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw class?=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0ianadns:class
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw rrset* [owner type]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw owner=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 inet:domain-name
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw type=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0identityref
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw description?=C2= =A0 =C2=A0string
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw ttl=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 positive-int32
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw rdata* [id]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw id= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0string
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw de= scription?=C2=A0 =C2=A0string

The idea is that specific RDATA will be added for each RR type (with a
"when" condition based on "type"). Data for= essential RR Types (SOA, NS,
A, AAAA, ...) can be defined in the same module but for some types they
need to be defined in other modules and added via augmenting the target
node "rdata". Typically, some (or all) of RDATA is mandatory, and this
is where Y26 comes into play. The solution recommended by Y26-02 would
look like this:

augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata"= {
=C2=A0 =C2=A0 when "derived-from-or-self(../dnsz:type,'iana-dns-parameter= s',"
=C2=A0 =C2=A0 =C2=A0 =C2=A0+ "'TLSA')";
=C2=A0 =C2=A0 container rdata {=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 // <=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=C2=A0 =C2=A0 =C2=A0 =C2=A0 presence "TLSA data";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf certificate-usage {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mandatory true;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 }
}

Note the superfluous presence container "rdata". It t= hat just adds a
useless level of hierarchy and still doesn't enforce the correct
constraints: the data model allows the presence container to be missing
so that RDATA will be empty. Defining this extra container for all ~75
RR types is a nuisance and it certainly won't make the modules more
readable.

As this situation is likely to be very common, I wonder: do we really
want to do that?

[1] https://svn.tool= s.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-27

Thanks, Lada

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

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



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


--001a11c34b6cebe31d051d338b61-- From nobody Thu Aug 13 10:44:26 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 275AA1A8F42 for ; Thu, 13 Aug 2015 10:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.91 X-Spam-Level: X-Spam-Status: No, score=-13.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_75=0.6, 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 bNlxeOgijCqZ for ; Thu, 13 Aug 2015 10:44:20 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 233591A8BC3 for ; Thu, 13 Aug 2015 10:44:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26718; q=dns/txt; s=iport; t=1439487859; x=1440697459; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=hSf0bYkyCCHrRQtnjdLea3w7m6G42LvblwMzBUR14HE=; b=XC7UtMomGY8EfSf5Up9f13B3A3Gg1B1sXB5DOijaahiwmXTB4+8rsfHz AlgqoAaRNqMT1AAJQLdF6LEPZxfa0Pl/CKHu24CNpiOdq4Zq9rUCFZC3S zJRjujXdvnUQxM4dqDYsI5zXtYGSxHBen2H9VkbXqwWOsKO2TDtj9jGS9 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BrAgD71sxV/xbLJq1dg29pgyS6XAEJgWsBCYUvSgKBexQBAQEBAQEBgQqEIwEBAQMBAQEBIEsGBAEQCQIYCRYBBwMCAgkDAgECARUfEQYNBgIBAReICwgNnWidHZY/AQEBAQEBAQEBAQEBAQEBAQEBAQEUBItTgj2Bcw5LB4JpgUMFhyKFOIErhAiDDYUEgmyEfIhskTYmg349MwEBAYECgUcBAQE X-IronPort-AV: E=Sophos;i="5.15,671,1432598400"; d="scan'208,217";a="609754006" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 13 Aug 2015 17:44:16 +0000 Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t7DHiGKW023527; Thu, 13 Aug 2015 17:44:16 GMT To: Andy Bierman References: <55CCBA4F.9010101@cisco.com> From: Robert Wilton Message-ID: <55CCD770.2030701@cisco.com> Date: Thu, 13 Aug 2015 18:44:16 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------020601000301030401020800" Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y26 again, sorry X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 17:44:23 -0000 This is a multi-part message in MIME format. --------------020601000301030401020800 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Andy, On 13/08/2015 17:08, Andy Bierman wrote: > > > On Thu, Aug 13, 2015 at 8:39 AM, Robert Wilton > wrote: > > Hi Andy, Lada, > > On 13/08/2015 15:46, Andy Bierman wrote: >> Hi, >> >> >> I'm not sure how many times we need to go over this issue... >> >> YANG conformance is based on the YANG module. >> YANG has no concept of conformance beyond this >> simplistic approach, You cannot assume (ever, under any conditions) >> that module foo AND bar will both be present on a server. >> >> Therefore if a client is written to work with "foo", it has no >> responsibility at all to know that "bar" adds a mandatory >> node to a "foo" subtree. >> >> The extra P-container is needed to make sure clients written >> to work with module "foo" do not break when new nodes are >> added via augments. > > I still don't see how a P-container really solves the problem > since any child mandatory nodes aren't really mandatory, or at > least not in the way that is actually intended. > > > > The concepts behind old-manager/new-agent protection mechanisms go back > a couple decades (with SNMP). There is no way that a vendor can > control all > the applications using a particular module, and therefore mandate a > flag-day > upgrade on all clients, in order to upgrade some servers. > Yes, I agree in principle, but I'm not sure whether the default set of YANG modules has yet reaches the maturity that enforcing this rule truly makes sense. It feels that many of the YANG modules (even those have been standardized) are still some what at the experimental stage. This is effectively the same point that you make below. > > YANG is very limited wrt/ adding new functionality, > A designer must guess correctly on all mandatory nodes > on the first version. If this a bug, then it should be fixed > properly, instead of just pretending it's OK to break > existing client apps. In Lada's case there is no base version, all of his modules are being newly defined. So, in this scenario, ideally that RR-type specific modules should be allowed to augment with mandatory nodes since this must effectively be backwards compatible. > > (YANG packages do not fix this problem BTW) > > Perhaps we need a new module-level "release" statement. > > release stable; > release unstable; > release experimental; > > Then all the very strict YANG change control rules can be relaxed on > unstable and experimental modules. Yes, this may make sense for other scenarios, but I don't see that it helps with either of the problems that Lada or I have described. > > > > E.g. in Lada's example having the P-container implies that for a > given RR type it is acceptable to either not provide any extra RR > specific config (i.e. no P-container), or if RR specific config is > provided then some fields must always be provided, and others can > be left out. I.e. the P-container also needs to be mandatory for > the configuration to be sane. > > > A P-container insulates the old client because it would not know to > create it, and the mandatory child nodes are only checked if > the P-container exists. Yes, but in Lada's example, the P-container doesn't really help anyone, since the server has to now handle the case that the RR-type has been specified but the corresponding P-container isn't present. If it is possible for the server to handle this scenario then the mandatory child fields don't have to be mandatory either because some sensible default must exist. This implies that all servers would likely reject the configuration as being invalid if the P-container isn't also present. As I see it, having a P-container here only protects a old client in the scenario that it was mis-configured in the first place, i.e. using a particular RR-type without the corresponding mandatory nodes being specified ... which a sane server should have rejected the config for previously. I don't really want to flog a dead horse, but I do think that the mandatory rule could be relaxed to state that it cannot be used to introduce non backwards compatible nodes. The text could specify the specific conditions where it is allowed to be used in a augmentation. Or, alternatively, perhaps allow for a must statement to simulate a mandatory keyword in these cases - although I don't think that this solution is particularly clear or clean. Thanks, Rob > > > To me, in this scenario, it feels that you might as well forego > both the P-container and mandatory marking. > > Thanks, > Rob > > > > > Andy > >> >> We already decided not to do anything useful wrt/ Y45, >> so we are stuck with the YANG module as the unit of conformance. >> >> >> Andy >> >> >> >> >> On Thu, Aug 13, 2015 at 7:07 AM, Ladislav Lhotka > > wrote: >> >> Hi, >> >> although YANG 1.1 issue Y26 [1] is marked as DONE, I think >> the adopted >> solution Y26-02 is really horrible, so at least I want to >> make sure the >> WG is aware of the consequences. >> >> I am currently working on a data model for DNS zone data and >> the schema >> is like this: >> >> module: dns-zones >> +--rw zones >> +--rw zone* [name] >> +--rw name inet:domain-name >> +--rw description? string >> +--rw class? ianadns:class >> +--rw rrset* [owner type] >> +--rw owner inet:domain-name >> +--rw type identityref >> +--rw description? string >> +--rw ttl positive-int32 >> +--rw rdata* [id] >> +--rw id string >> +--rw description? string >> >> The idea is that specific RDATA will be added for each RR >> type (with a >> "when" condition based on "type"). Data for essential RR >> Types (SOA, NS, >> A, AAAA, ...) can be defined in the same module but for some >> types they >> need to be defined in other modules and added via augmenting >> the target >> node "rdata". Typically, some (or all) of RDATA is mandatory, >> and this >> is where Y26 comes into play. The solution recommended by >> Y26-02 would >> look like this: >> >> augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" { >> when >> "derived-from-or-self(../dnsz:type,'iana-dns-parameters'," >> + "'TLSA')"; >> container rdata { // <================= >> presence "TLSA data"; >> leaf certificate-usage { >> mandatory true; >> ... >> } >> ... >> } >> } >> >> Note the superfluous presence container "rdata". It that just >> adds a >> useless level of hierarchy and still doesn't enforce the correct >> constraints: the data model allows the presence container to >> be missing >> so that RDATA will be empty. Defining this extra container >> for all ~75 >> RR types is a nuisance and it certainly won't make the >> modules more >> readable. >> >> As this situation is likely to be very common, I wonder: do >> we really >> want to do that? >> >> [1] >> https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-27 >> >> Thanks, Lada >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> >> >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > --------------020601000301030401020800 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Andy,

On 13/08/2015 17:08, Andy Bierman wrote:


On Thu, Aug 13, 2015 at 8:39 AM, Robert Wilton <rwilton@cisco.com> wrote:
Hi Andy, Lada,

On 13/08/2015 15:46, Andy Bierman wrote:
Hi,


I'm not sure how many times we need to go over this issue...

YANG conformance is based on the YANG module.
YANG has no concept of conformance beyond this
simplistic approach,  You cannot assume (ever, under any conditions)
that module foo AND bar will both be present on a server.

Therefore if a client is written to work with "foo", it has no
responsibility at all to know that "bar" adds a mandatory
node to a "foo" subtree.

The extra P-container is needed to make sure clients written
to work with module "foo" do not break when new nodes are
added via augments.

I still don't see how a P-container really solves the problem since any child mandatory nodes aren't really mandatory, or at least not in the way that is actually intended.



The concepts behind old-manager/new-agent protection mechanisms go back
a couple decades (with SNMP).  There is no way that a vendor can control all
the applications using a particular module, and therefore mandate a flag-day
upgrade on all clients, in order to upgrade some servers.

Yes, I agree in principle, but I'm not sure whether the default set of YANG modules has yet reaches the maturity that enforcing this rule truly makes sense.  It feels that many of the YANG modules (even those have been standardized) are still some what at the experimental stage.  This is effectively the same point that you make below.


YANG is very limited wrt/ adding new functionality,
A designer must guess correctly on all mandatory nodes
on the first version.  If this a bug, then it should be fixed
properly, instead of just pretending it's OK to break
existing client apps.

In Lada's case there is no base version, all of his modules are being newly defined.  So, in this scenario, ideally that RR-type specific modules should be allowed to augment with mandatory nodes since this must effectively be backwards compatible.



(YANG packages do not fix this problem BTW)

Perhaps we need a new module-level "release" statement.

   release stable;
   release unstable;
   release experimental;

Then all the very strict YANG change control rules can be relaxed on
unstable and experimental modules.

Yes, this may make sense for other scenarios, but I don't see that it helps with either of the problems that Lada or I have described.




E.g. in Lada's example having the P-container implies that for a given RR type it is acceptable to either not provide any extra RR specific config (i.e. no P-container), or if RR specific config is provided then some fields must always be provided, and others can be left out.  I.e. the P-container also needs to be mandatory for the configuration to be sane.


A P-container insulates the old client because it would not know to
create it, and the mandatory child nodes are only checked if
the P-container exists.
Yes, but in Lada's example, the P-container doesn't really help anyone, since the server has to now handle the case that the RR-type has been specified but the corresponding P-container isn't present.  If it is possible for the server to handle this scenario then the mandatory child fields don't have to be mandatory either because some sensible default must exist.  This implies that all servers would likely reject the configuration as being invalid if the P-container isn't also present.

As I see it, having a P-container here only protects a old client in the scenario that it was mis-configured in the first place, i.e. using a particular RR-type without the corresponding mandatory nodes being specified ... which a sane server should have rejected the config for previously.

I don't really want to flog a dead horse, but I do think that the mandatory rule could be relaxed to state that it cannot be used to introduce non backwards compatible nodes.  The text could specify the specific conditions where it is allowed to be used in a augmentation.

Or, alternatively, perhaps allow for a must statement to simulate a mandatory keyword in these cases - although I don't think that this solution is particularly clear or clean.

Thanks,
Rob



 
To me, in this scenario, it feels that you might as well forego both the P-container and mandatory marking.

Thanks,
Rob




Andy

 

We already decided not to do anything useful wrt/ Y45,
so we are stuck with the YANG module as the unit of conformance.


Andy




On Thu, Aug 13, 2015 at 7:07 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
Hi,

although YANG 1.1 issue Y26 [1] is marked as DONE, I think the adopted
solution Y26-02 is really horrible, so at least I want to make sure the
WG is aware of the consequences.

I am currently working on a data model for DNS zone data and the schema
is like this:

module: dns-zones
   +--rw zones
      +--rw zone* [name]
         +--rw name           inet:domain-name
         +--rw description?   string
         +--rw class?         ianadns:class
         +--rw rrset* [owner type]
            +--rw owner          inet:domain-name
            +--rw type           identityref
            +--rw description?   string
            +--rw ttl            positive-int32
            +--rw rdata* [id]
               +--rw id             string
               +--rw description?   string

The idea is that specific RDATA will be added for each RR type (with a
"when" condition based on "type"). Data for essential RR Types (SOA, NS,
A, AAAA, ...) can be defined in the same module but for some types they
need to be defined in other modules and added via augmenting the target
node "rdata". Typically, some (or all) of RDATA is mandatory, and this
is where Y26 comes into play. The solution recommended by Y26-02 would
look like this:

augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" {
    when "derived-from-or-self(../dnsz:type,'iana-dns-parameters',"
       + "'TLSA')";
    container rdata {            // <=================
        presence "TLSA data";
        leaf certificate-usage {
            mandatory true;
            ...
        }
        ...
    }
}

Note the superfluous presence container "rdata". It that just adds a
useless level of hierarchy and still doesn't enforce the correct
constraints: the data model allows the presence container to be missing
so that RDATA will be empty. Defining this extra container for all ~75
RR types is a nuisance and it certainly won't make the modules more
readable.

As this situation is likely to be very common, I wonder: do we really
want to do that?

[1] https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-27

Thanks, Lada

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

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



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



--------------020601000301030401020800-- From nobody Thu Aug 13 11:11:14 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 794871B2D08 for ; Thu, 13 Aug 2015 11:11:13 -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_75=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 cdZMzUXM9gVu for ; Thu, 13 Aug 2015 11:11:10 -0700 (PDT) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A69C41A03D5 for ; Thu, 13 Aug 2015 11:11:09 -0700 (PDT) Received: by lbbtg9 with SMTP id tg9so32032961lbb.1 for ; Thu, 13 Aug 2015 11:11:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mJxkYk8U3WYTLldegOz8SUaJKCCqTpwwZGhtLLDn2AA=; b=UNm3kUCL858CXjzDnx0kWaeyaO7OHUAM7wtONEb1TUf+G5EiDg2+eOVO1LPPkOBD/i /6IWX16aiuMYUGf8PCmC2CFRVQZ4T+HupXdoJe/jMKAEadyePm89z28BVrqT893mb3xX zQHyMpI+9K7c0RlbvB6FhlcbaxZGxBMbM6MZertBsWy/SAY4Yv1Aa+clpm1Ul56lnPJv DezvGzcpbzdaLbnsA0YolyNg/45gHtjJzWoclZStWVszf1bcHMAe8QbfcojQUiTzdoGa ha4TCN+Es3bEEX/UKXqu6qh6cLEGxmWi6mnWKVE9yOC0/VmnPXNZyS04HNVM6K13AtHx nY9A== X-Gm-Message-State: ALoCoQkjnFyC6YPh0Vv6F8iBioEVcoBgXYakFubyUJdtW4UlcXx0c4Mm5J8VAL1wFSjABiN5UCeO MIME-Version: 1.0 X-Received: by 10.112.118.41 with SMTP id kj9mr38006094lbb.123.1439489467969; Thu, 13 Aug 2015 11:11:07 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Thu, 13 Aug 2015 11:11:07 -0700 (PDT) In-Reply-To: <55CCD770.2030701@cisco.com> References: <55CCBA4F.9010101@cisco.com> <55CCD770.2030701@cisco.com> Date: Thu, 13 Aug 2015 11:11:07 -0700 Message-ID: From: Andy Bierman To: Robert Wilton Content-Type: multipart/alternative; boundary=047d7bfd0098658b88051d3542b0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y26 again, sorry X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 18:11:13 -0000 --047d7bfd0098658b88051d3542b0 Content-Type: text/plain; charset=UTF-8 On Thu, Aug 13, 2015 at 10:44 AM, Robert Wilton wrote: > Hi Andy, > > On 13/08/2015 17:08, Andy Bierman wrote: > > > > On Thu, Aug 13, 2015 at 8:39 AM, Robert Wilton wrote: > >> Hi Andy, Lada, >> >> On 13/08/2015 15:46, Andy Bierman wrote: >> >> Hi, >> >> >> I'm not sure how many times we need to go over this issue... >> >> YANG conformance is based on the YANG module. >> YANG has no concept of conformance beyond this >> simplistic approach, You cannot assume (ever, under any conditions) >> that module foo AND bar will both be present on a server. >> >> >> Therefore if a client is written to work with "foo", it has no >> responsibility at all to know that "bar" adds a mandatory >> node to a "foo" subtree. >> >> >> The extra P-container is needed to make sure clients written >> to work with module "foo" do not break when new nodes are >> added via augments. >> >> >> I still don't see how a P-container really solves the problem since any >> child mandatory nodes aren't really mandatory, or at least not in the way >> that is actually intended. >> >> > > The concepts behind old-manager/new-agent protection mechanisms go back > a couple decades (with SNMP). There is no way that a vendor can control > all > the applications using a particular module, and therefore mandate a > flag-day > upgrade on all clients, in order to upgrade some servers. > > Yes, I agree in principle, but I'm not sure whether the default set of > YANG modules has yet reaches the maturity that enforcing this rule truly > makes sense. It feels that many of the YANG modules (even those have been > standardized) are still some what at the experimental stage. This is > effectively the same point that you make below. > > > YANG is very limited wrt/ adding new functionality, > A designer must guess correctly on all mandatory nodes > on the first version. If this a bug, then it should be fixed > properly, instead of just pretending it's OK to break > existing client apps. > > > In Lada's case there is no base version, all of his modules are being > newly defined. So, in this scenario, ideally that RR-type specific modules > should be allowed to augment with mandatory nodes since this must > effectively be backwards compatible. > That's really too bad because YANG has no way of saying "this group of 4 YANG modules are intended to be used together". You can pretend it does, but the RFC says differently. It is difficult if not impossible to write guidelines that insure that an individual YANG module is updated with mandatory nodes in a way that does not make assumptions about how the previous module revision was used. Since there is no way in YANG to say "the server MUST provide the base module plus augments module X and Y", there is no way to do what Lada wants. With the 'unstable' or 'experimental' attribute, it would be OK to update the base module directly and add mandatory nodes. There is no reason augment has to be used. That is a subjective design choice. Andy > > > (YANG packages do not fix this problem BTW) > > Perhaps we need a new module-level "release" statement. > > release stable; > release unstable; > release experimental; > > Then all the very strict YANG change control rules can be relaxed on > unstable and experimental modules. > > > Yes, this may make sense for other scenarios, but I don't see that it > helps with either of the problems that Lada or I have described. > > > > > E.g. in Lada's example having the P-container implies that for a given RR >> type it is acceptable to either not provide any extra RR specific config >> (i.e. no P-container), or if RR specific config is provided then some >> fields must always be provided, and others can be left out. I.e. the >> P-container also needs to be mandatory for the configuration to be sane. >> >> > A P-container insulates the old client because it would not know to > create it, and the mandatory child nodes are only checked if > the P-container exists. > > Yes, but in Lada's example, the P-container doesn't really help anyone, > since the server has to now handle the case that the RR-type has been > specified but the corresponding P-container isn't present. If it is > possible for the server to handle this scenario then the mandatory child > fields don't have to be mandatory either because some sensible default must > exist. This implies that all servers would likely reject the configuration > as being invalid if the P-container isn't also present. > > As I see it, having a P-container here only protects a old client in the > scenario that it was mis-configured in the first place, i.e. using a > particular RR-type without the corresponding mandatory nodes being > specified ... which a sane server should have rejected the config for > previously. > > I don't really want to flog a dead horse, but I do think that the > mandatory rule could be relaxed to state that it cannot be used to > introduce non backwards compatible nodes. The text could specify the > specific conditions where it is allowed to be used in a augmentation. > > Or, alternatively, perhaps allow for a must statement to simulate a > mandatory keyword in these cases - although I don't think that this > solution is particularly clear or clean. > > Thanks, > Rob > > > > > >> To me, in this scenario, it feels that you might as well forego both the >> P-container and mandatory marking. >> >> Thanks, >> Rob >> >> >> > > Andy > > > >> >> We already decided not to do anything useful wrt/ Y45, >> so we are stuck with the YANG module as the unit of conformance. >> >> >> Andy >> >> >> >> >> On Thu, Aug 13, 2015 at 7:07 AM, Ladislav Lhotka < >> lhotka@nic.cz> wrote: >> >>> Hi, >>> >>> although YANG 1.1 issue Y26 [1] is marked as DONE, I think the adopted >>> solution Y26-02 is really horrible, so at least I want to make sure the >>> WG is aware of the consequences. >>> >>> I am currently working on a data model for DNS zone data and the schema >>> is like this: >>> >>> module: dns-zones >>> +--rw zones >>> +--rw zone* [name] >>> +--rw name inet:domain-name >>> +--rw description? string >>> +--rw class? ianadns:class >>> +--rw rrset* [owner type] >>> +--rw owner inet:domain-name >>> +--rw type identityref >>> +--rw description? string >>> +--rw ttl positive-int32 >>> +--rw rdata* [id] >>> +--rw id string >>> +--rw description? string >>> >>> The idea is that specific RDATA will be added for each RR type (with a >>> "when" condition based on "type"). Data for essential RR Types (SOA, NS, >>> A, AAAA, ...) can be defined in the same module but for some types they >>> need to be defined in other modules and added via augmenting the target >>> node "rdata". Typically, some (or all) of RDATA is mandatory, and this >>> is where Y26 comes into play. The solution recommended by Y26-02 would >>> look like this: >>> >>> augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" { >>> when "derived-from-or-self(../dnsz:type,'iana-dns-parameters'," >>> + "'TLSA')"; >>> container rdata { // <================= >>> presence "TLSA data"; >>> leaf certificate-usage { >>> mandatory true; >>> ... >>> } >>> ... >>> } >>> } >>> >>> Note the superfluous presence container "rdata". It that just adds a >>> useless level of hierarchy and still doesn't enforce the correct >>> constraints: the data model allows the presence container to be missing >>> so that RDATA will be empty. Defining this extra container for all ~75 >>> RR types is a nuisance and it certainly won't make the modules more >>> readable. >>> >>> As this situation is likely to be very common, I wonder: do we really >>> want to do that? >>> >>> [1] https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-27 >>> >>> Thanks, Lada >>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> >> >> >> >> _______________________________________________ >> netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod >> >> >> > > --047d7bfd0098658b88051d3542b0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Aug 13, 2015 at 10:44 AM, Robert Wilton <<= a href=3D"mailto:rwilton@cisco.com" target=3D"_blank">rwilton@cisco.com= > wrote:
=20 =20 =20
Hi Andy,

On 13/08/2015 17:08, Andy Bierman wrote:
=20


On Thu, Aug 13, 2015 at 8:39 AM, Robert Wilton <rwilton@cisco.com> wrote:
Hi Andy, Lada,

On 13/08/2015 15:46, Andy Bierman wrote:
Hi,


I'm not sure how many times we need to go over this issue...

YANG conformance is based on the YANG module.
YANG has no concept of conformance beyond this
simplistic approach, =C2=A0You cannot assume (ever= , under any conditions)
that module foo AND bar will both be present on a server.

Therefore if a client is written to work with "foo", it has no
responsibility at all to know that "bar"= adds a mandatory
node to a "foo" subtree.

The extra P-container is needed to make sure clients written
to work with module "foo" do not break w= hen new nodes are
added via augments.

I still don't see how a P-container really solves the problem since any child mandatory nodes aren't really mandatory, or at least not in the way that is actually intended.



The concepts behind old-manager/new-agent protection mechanisms go back
a couple decades (with SNMP).=C2=A0 There is no way that a vendor can control all
the applications using a particular module, and therefore mandate a flag-day
upgrade on all clients, in order to upgrade some servers.

Yes, I agree in principle, but I'm not sure whether the default set of YANG modules has yet reaches the maturity that enforcing this rule truly makes sense.=C2=A0 It feels that many of the YANG modules (even those have been standardized) are still some what at the experimental stage.=C2=A0 This is effectively the same point that you make below.


YANG is very limited wrt/ adding new functionality,
A designer must guess correctly on all mandatory nodes
on the first version.=C2=A0 If this a bug, then it should = be fixed
properly, instead of just pretending it's OK to break<= /div>
existing client apps.

In Lada's case there is no base version, all of his modules are being newly defined.=C2=A0 So, in this scenario, ideally that RR-type specific modules should be allowed to augment with mandatory nodes since this must effectively be backwards compatible.


That's really too bad because YA= NG has no way of saying
"this group of 4 YANG modules are in= tended to be used together".
You can pretend it does, but th= e RFC says differently.

It is difficult if not imp= ossible to write guidelines that insure that
an individual YANG m= odule is updated with mandatory nodes in a way that
does not make= assumptions about how the previous module revision
was used.

Since there is no way in YANG to say "the server= MUST provide the
base module plus augments module X and Y",= there is no way
to do what Lada wants.

= With the 'unstable' or 'experimental' attribute, it would b= e OK to
update the base module directly and add mandatory nodes.<= /div>
There is no reason augment has to be used.=C2=A0 That is a subjec= tive design
choice.


Andy<= /div>






(YANG packages do not fix this problem BTW)

Perhaps we need a new module-level "release" sta= tement.

=C2=A0 =C2=A0release stable;
=C2=A0 =C2=A0release unstable;
=C2=A0 =C2=A0release experimental;

Then all the very strict YANG change control rules can be relaxed on
unstable and experimental modules.

Yes, this may make sense for other scenarios, but I don't see that it helps with either of the problems that Lada or I have described.




E.g. in Lada's example having the P-container implies that for a given RR type it is acceptable to either not provide any extra RR specific config (i.e. no P-container), or if RR specific config is provided then some fields must always be provided, and others can be left out.=C2=A0 I.e. the P-container also needs to be mandatory for the configuration to be sane.


A P-container insulates the old client because it would not know to
create it, and the mandatory child nodes are only checked if
the P-container exists.
Yes, but in Lada's example, the P-container doesn't really help anyone, since the server has to now handle the case that the RR-type has been specified but the corresponding P-container isn't present.= =C2=A0 If it is possible for the server to handle this scenario then the mandatory child fields don't have to be mandatory either because some sensible default must exist.=C2=A0 This implies that all servers would likely reject the configuration as being invalid if the P-container isn't also present.

As I see it, having a P-container here only protects a old client in the scenario that it was mis-configured in the first place, i.e. using a particular RR-type without the corresponding mandatory nodes being specified ... which a sane server should have rejected the config for previously.

I don't really want to flog a dead horse, but I do think that the mandatory rule could be relaxed to state that it cannot be used to introduce non backwards compatible nodes.=C2=A0 The text could specify the specific conditions where it is allowed to be used in a augmentation.

Or, alternatively, perhaps allow for a must statement to simulate a mandatory keyword in these cases - although I don't think that this solution is particularly clear or clean.

Thanks,
Rob



=C2=A0
To me, in this scenario, it feels that you might as well forego both the P-container and mandatory marking.

Thanks,
Rob




Andy

=C2=A0

We already decided not to do anything useful wrt/ Y45,
so we are stuck with the YANG module as the unit of conformance.


Andy




On Thu, Aug 13, 2015 at 7:07 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
Hi,

although YANG 1.1 issue Y26 [1] is marked as DONE, I think the adopted
solution Y26-02 is really horrible, so at least I want to make sure the
WG is aware of the consequences.

I am currently working on a data model for DNS zone data and the schema
is like this:

module: dns-zones
=C2=A0 =C2=A0+--rw zones
=C2=A0 =C2=A0 =C2=A0 +--rw zone* [name]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw name=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0inet:domain-name
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw description= ?=C2=A0 =C2=A0string
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw class?=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ianadns:class
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw rrset* [own= er type]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw own= er=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 inet:domain-name
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw typ= e=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0identityref
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw des= cription?=C2=A0 =C2=A0string
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw ttl= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 positive-int32
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw rda= ta* [id]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0+--rw id=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0string
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0+--rw description?=C2=A0 =C2=A0string

The idea is that specific RDATA will be added for each RR type (with a
"when" condition based on "type"= ;). Data for essential RR Types (SOA, NS,
A, AAAA, ...) can be defined in the same module but for some types they
need to be defined in other modules and added via augmenting the target
node "rdata". Typically, some (or all) of= RDATA is mandatory, and this
is where Y26 comes into play. The solution recommended by Y26-02 would
look like this:

augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata&q= uot; {
=C2=A0 =C2=A0 when "derived-from-or-self(../dnsz:type,'iana-d= ns-parameters',"
=C2=A0 =C2=A0 =C2=A0 =C2=A0+ "'TLSA')&= quot;;
=C2=A0 =C2=A0 container rdata {=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 // <=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
=C2=A0 =C2=A0 =C2=A0 =C2=A0 presence "TLSA dat= a";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf certificate-usage = {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mandatory= true;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 }
}

Note the superfluous presence container "rdata= ". It that just adds a
useless level of hierarchy and still doesn't enforce the correct
constraints: the data model allows the presence container to be missing
so that RDATA will be empty. Defining this extra container for all ~75
RR types is a nuisance and it certainly won't make the modules more
readable.

As this situation is likely to be very common, I wonder: do we really
want to do that?

[1] http= s://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-27

Thanks, Lada

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

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



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




--047d7bfd0098658b88051d3542b0-- From nobody Thu Aug 13 12:22:34 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F08F1B39B5 for ; Thu, 13 Aug 2015 12:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.061 X-Spam-Level: X-Spam-Status: No, score=-5.061 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sheu3Gpipa4S for ; Thu, 13 Aug 2015 12:22:29 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26BDD1B39B4 for ; Thu, 13 Aug 2015 12:22:29 -0700 (PDT) Received: from [172.29.2.202] (nat-14.bravonet.cz [77.48.225.14]) by mail.nic.cz (Postfix) with ESMTPSA id 87B6E1816F6; Thu, 13 Aug 2015 21:22:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1439493747; bh=b4UzVPipSy/r5jHUw9DhL1GwB5Tg7XD1CWsYoYFddIE=; h=From:Date:To; b=xIgqJ5ITqUIsJj8AORiPaHBwXCauYaQhfQV0Vg7ULbXBruqFuvmRpDR7Qlh3xdjRq l2mM8jUOtz3B0HeSojo/1BOZPq2hXDireilGyrGsBcorIBjok9xZ5iY2dKQoX352+g s9w9xPzHiKE0XgyPl6rtrXiEOBWBkxPWVCamVBSc= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: <55CCD770.2030701@cisco.com> Date: Thu, 13 Aug 2015 21:22:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <586BF923-E9EA-4248-A838-55D3709A31BE@nic.cz> References: <55CCBA4F.9010101@cisco.com> <55CCD770.2030701@cisco.com> To: Robert Wilton X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y26 again, sorry X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 19:22:32 -0000 > On 13 Aug 2015, at 19:44, Robert Wilton wrote: >=20 > Hi Andy, >=20 > On 13/08/2015 17:08, Andy Bierman wrote: >>=20 >>=20 >> On Thu, Aug 13, 2015 at 8:39 AM, Robert Wilton = wrote: >> Hi Andy, Lada, >>=20 >> On 13/08/2015 15:46, Andy Bierman wrote: >>> Hi, >>>=20 >>>=20 >>> I'm not sure how many times we need to go over this issue... >>>=20 >>> YANG conformance is based on the YANG module. >>> YANG has no concept of conformance beyond this >>> simplistic approach, You cannot assume (ever, under any conditions) >>> that module foo AND bar will both be present on a server. >>>=20 >>> Therefore if a client is written to work with "foo", it has no >>> responsibility at all to know that "bar" adds a mandatory >>> node to a "foo" subtree. >>>=20 >>> The extra P-container is needed to make sure clients written >>> to work with module "foo" do not break when new nodes are >>> added via augments. >>=20 >> I still don't see how a P-container really solves the problem since = any child mandatory nodes aren't really mandatory, or at least not in = the way that is actually intended.=20 >>=20 >>=20 >>=20 >> The concepts behind old-manager/new-agent protection mechanisms go = back >> a couple decades (with SNMP). There is no way that a vendor can = control all >> the applications using a particular module, and therefore mandate a = flag-day >> upgrade on all clients, in order to upgrade some servers. >>=20 > Yes, I agree in principle, but I'm not sure whether the default set of = YANG modules has yet reaches the maturity that enforcing this rule truly = makes sense. It feels that many of the YANG modules (even those have = been standardized) are still some what at the experimental stage. This = is effectively the same point that you make below. Right. Another thing is that augment was IMO originally intended to = allow for adding optional or vendor-specific parameters to a base data = model. However, as it turned out, it is in fact used as an essential = tool for developing *base* data models in a modular fashion. I have also argued several times that a client cherry-picking modules = advertised by the server is fundamentally unsafe - it may work but may = also break things.=20 >=20 >>=20 >> YANG is very limited wrt/ adding new functionality, >> A designer must guess correctly on all mandatory nodes >> on the first version. If this a bug, then it should be fixed >> properly, instead of just pretending it's OK to break >> existing client apps. >=20 > In Lada's case there is no base version, all of his modules are being = newly defined. So, in this scenario, ideally that RR-type specific = modules should be allowed to augment with mandatory nodes since this = must effectively be backwards compatible. >=20 >=20 >>=20 >> (YANG packages do not fix this problem BTW) >>=20 >> Perhaps we need a new module-level "release" statement. >>=20 >> release stable; >> release unstable; >> release experimental; >>=20 >> Then all the very strict YANG change control rules can be relaxed on >> unstable and experimental modules. >=20 > Yes, this may make sense for other scenarios, but I don't see that it = helps with either of the problems that Lada or I have described. It doesn=E2=80=99t, it is just hand-waving. >=20 >>=20 >>=20 >>=20 >> E.g. in Lada's example having the P-container implies that for a = given RR type it is acceptable to either not provide any extra RR = specific config (i.e. no P-container), or if RR specific config is = provided then some fields must always be provided, and others can be = left out. I.e. the P-container also needs to be mandatory for the = configuration to be sane. >>=20 >>=20 >> A P-container insulates the old client because it would not know to >> create it, and the mandatory child nodes are only checked if >> the P-container exists. > Yes, but in Lada's example, the P-container doesn't really help = anyone, since the server has to now handle the case that the RR-type has = been specified but the corresponding P-container isn't present. If it = is possible for the server to handle this scenario then the = mandatory child fields don't have to be mandatory either because some = sensible default must exist. This implies that all servers would likely = reject the configuration as being invalid if the P-container isn't also = present. >=20 > As I see it, having a P-container here only protects a old client in = the scenario that it was mis-configured in the first place, i.e. using a = particular RR-type without the corresponding mandatory nodes being = specified ... which a sane server should have rejected the config for = previously. >=20 > I don't really want to flog a dead horse, but I do think that the = mandatory rule could be relaxed to state that it cannot be used to = introduce non backwards compatible nodes. The text could specify the = specific conditions where it is allowed to be used in a augmentation. We tried to identify such situations but it is not that easy. I think = the restriction should be removed and explain backward compatibility = issues in 6087bis. Module authors then have to decide whether a certain = node needs to be defined as mandatory. If we clutter new modules with unnecessary p-containers, there will be = no way back.=20 >=20 > Or, alternatively, perhaps allow for a must statement to simulate a = mandatory keyword in these cases - although I don't think that this = solution is particularly clear or clean. Exactly, it is an ugly hack to the same effect. Lada=20 >=20 > Thanks, > Rob >=20 >=20 >>=20 >> =20 >> To me, in this scenario, it feels that you might as well forego both = the P-container and mandatory marking. >>=20 >> Thanks, >> Rob >>=20 >>=20 >>=20 >>=20 >> Andy >>=20 >> =20 >>>=20 >>> We already decided not to do anything useful wrt/ Y45, >>> so we are stuck with the YANG module as the unit of conformance. >>>=20 >>>=20 >>> Andy >>>=20 >>>=20 >>>=20 >>>=20 >>> On Thu, Aug 13, 2015 at 7:07 AM, Ladislav Lhotka = wrote: >>> Hi, >>>=20 >>> although YANG 1.1 issue Y26 [1] is marked as DONE, I think the = adopted >>> solution Y26-02 is really horrible, so at least I want to make sure = the >>> WG is aware of the consequences. >>>=20 >>> I am currently working on a data model for DNS zone data and the = schema >>> is like this: >>>=20 >>> module: dns-zones >>> +--rw zones >>> +--rw zone* [name] >>> +--rw name inet:domain-name >>> +--rw description? string >>> +--rw class? ianadns:class >>> +--rw rrset* [owner type] >>> +--rw owner inet:domain-name >>> +--rw type identityref >>> +--rw description? string >>> +--rw ttl positive-int32 >>> +--rw rdata* [id] >>> +--rw id string >>> +--rw description? string >>>=20 >>> The idea is that specific RDATA will be added for each RR type (with = a >>> "when" condition based on "type"). Data for essential RR Types (SOA, = NS, >>> A, AAAA, ...) can be defined in the same module but for some types = they >>> need to be defined in other modules and added via augmenting the = target >>> node "rdata". Typically, some (or all) of RDATA is mandatory, and = this >>> is where Y26 comes into play. The solution recommended by Y26-02 = would >>> look like this: >>>=20 >>> augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" { >>> when "derived-from-or-self(../dnsz:type,'iana-dns-parameters'," >>> + "'TLSA')"; >>> container rdata { // <=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >>> presence "TLSA data"; >>> leaf certificate-usage { >>> mandatory true; >>> ... >>> } >>> ... >>> } >>> } >>>=20 >>> Note the superfluous presence container "rdata". It that just adds a >>> useless level of hierarchy and still doesn't enforce the correct >>> constraints: the data model allows the presence container to be = missing >>> so that RDATA will be empty. Defining this extra container for all = ~75 >>> RR types is a nuisance and it certainly won't make the modules more >>> readable. >>>=20 >>> As this situation is likely to be very common, I wonder: do we = really >>> want to do that? >>>=20 >>> [1] = https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-27 >>>=20 >>> Thanks, Lada >>>=20 >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> netmod mailing list >>>=20 >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >>=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Aug 13 12:32:06 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2D21B39B1 for ; Thu, 13 Aug 2015 12:32:05 -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_75=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 rMjPniawnufo for ; Thu, 13 Aug 2015 12:32:01 -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 2411E1AC40F for ; Thu, 13 Aug 2015 12:32:01 -0700 (PDT) Received: by lbbtg9 with SMTP id tg9so33286696lbb.1 for ; Thu, 13 Aug 2015 12:31: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=FSkABjzC6TNLEO/NFsbTOVH5v593BndZIRNYx9XoGD4=; b=Elajr9zyb/9ke6ZuiMXrtVrYr9HJwb1I1D0b4nmkKnCZc1LoLnwkS4z+JK+KM0naq4 dE3H2M+JlsDkNxJjcr8DBnwxnaE5ecB8wKS6ezD1NKp7ip6EqIujfMeuujKikphhH8+8 OUkRvZjObv8WC2vYPLV/rqySUU1kyCP5dTBzQMWCKj9UnJvFD+Nov8WxnuLZKdRi1xV0 xd9IWAx/2J345BZU1g1x+BZD44pgbLN7DKCXm0TLLNIE+sB/+A0yv+Ec3Cq/bND0/fFe r43p7vIwzT1TXUBrosWzX/TdAvQTYDEiv0UfhcgHpVmnrqdaLpfBcFqp2yqnPOPvuuM6 w6Og== X-Gm-Message-State: ALoCoQkFv3WNAom3OMHHRDErPg/Z+sTOLQvrJVAm0tLzuZk96P9u1ADtdMCqBeOfWcss0WEd7atd MIME-Version: 1.0 X-Received: by 10.112.160.42 with SMTP id xh10mr38273818lbb.88.1439494319445; Thu, 13 Aug 2015 12:31:59 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Thu, 13 Aug 2015 12:31:59 -0700 (PDT) In-Reply-To: <586BF923-E9EA-4248-A838-55D3709A31BE@nic.cz> References: <55CCBA4F.9010101@cisco.com> <55CCD770.2030701@cisco.com> <586BF923-E9EA-4248-A838-55D3709A31BE@nic.cz> Date: Thu, 13 Aug 2015 12:31:59 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c34238913643051d366313 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y26 again, sorry X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 19:32:05 -0000 --001a11c34238913643051d366313 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, IMO this is issue is closed. I see no reason to re-open it. YANG does not allow augments to add mandatory nodes. Andy On Thu, Aug 13, 2015 at 12:22 PM, Ladislav Lhotka wrote: > > > On 13 Aug 2015, at 19:44, Robert Wilton wrote: > > > > Hi Andy, > > > > On 13/08/2015 17:08, Andy Bierman wrote: > >> > >> > >> On Thu, Aug 13, 2015 at 8:39 AM, Robert Wilton > wrote: > >> Hi Andy, Lada, > >> > >> On 13/08/2015 15:46, Andy Bierman wrote: > >>> Hi, > >>> > >>> > >>> I'm not sure how many times we need to go over this issue... > >>> > >>> YANG conformance is based on the YANG module. > >>> YANG has no concept of conformance beyond this > >>> simplistic approach, You cannot assume (ever, under any conditions) > >>> that module foo AND bar will both be present on a server. > >>> > >>> Therefore if a client is written to work with "foo", it has no > >>> responsibility at all to know that "bar" adds a mandatory > >>> node to a "foo" subtree. > >>> > >>> The extra P-container is needed to make sure clients written > >>> to work with module "foo" do not break when new nodes are > >>> added via augments. > >> > >> I still don't see how a P-container really solves the problem since an= y > child mandatory nodes aren't really mandatory, or at least not in the way > that is actually intended. > >> > >> > >> > >> The concepts behind old-manager/new-agent protection mechanisms go bac= k > >> a couple decades (with SNMP). There is no way that a vendor can > control all > >> the applications using a particular module, and therefore mandate a > flag-day > >> upgrade on all clients, in order to upgrade some servers. > >> > > Yes, I agree in principle, but I'm not sure whether the default set of > YANG modules has yet reaches the maturity that enforcing this rule truly > makes sense. It feels that many of the YANG modules (even those have bee= n > standardized) are still some what at the experimental stage. This is > effectively the same point that you make below. > > Right. Another thing is that augment was IMO originally intended to allow > for adding optional or vendor-specific parameters to a base data model. > However, as it turned out, it is in fact used as an essential tool for > developing *base* data models in a modular fashion. > > I have also argued several times that a client cherry-picking modules > advertised by the server is fundamentally unsafe - it may work but may al= so > break things. > > > > >> > >> YANG is very limited wrt/ adding new functionality, > >> A designer must guess correctly on all mandatory nodes > >> on the first version. If this a bug, then it should be fixed > >> properly, instead of just pretending it's OK to break > >> existing client apps. > > > > In Lada's case there is no base version, all of his modules are being > newly defined. So, in this scenario, ideally that RR-type specific modul= es > should be allowed to augment with mandatory nodes since this must > effectively be backwards compatible. > > > > > >> > >> (YANG packages do not fix this problem BTW) > >> > >> Perhaps we need a new module-level "release" statement. > >> > >> release stable; > >> release unstable; > >> release experimental; > >> > >> Then all the very strict YANG change control rules can be relaxed on > >> unstable and experimental modules. > > > > Yes, this may make sense for other scenarios, but I don't see that it > helps with either of the problems that Lada or I have described. > > It doesn=E2=80=99t, it is just hand-waving. > > > > >> > >> > >> > >> E.g. in Lada's example having the P-container implies that for a given > RR type it is acceptable to either not provide any extra RR specific conf= ig > (i.e. no P-container), or if RR specific config is provided then some > fields must always be provided, and others can be left out. I.e. the > P-container also needs to be mandatory for the configuration to be sane. > >> > >> > >> A P-container insulates the old client because it would not know to > >> create it, and the mandatory child nodes are only checked if > >> the P-container exists. > > Yes, but in Lada's example, the P-container doesn't really help anyone, > since the server has to now handle the case that the RR-type has been > specified but the corresponding P-container isn't present. If it is > possible for the server to handle this scenario then the mandatory > child fields don't have to be mandatory either because some sensible > default must exist. This implies that all servers would likely reject th= e > configuration as being invalid if the P-container isn't also present. > > > > As I see it, having a P-container here only protects a old client in th= e > scenario that it was mis-configured in the first place, i.e. using a > particular RR-type without the corresponding mandatory nodes being > specified ... which a sane server should have rejected the config for > previously. > > > > I don't really want to flog a dead horse, but I do think that the > mandatory rule could be relaxed to state that it cannot be used to > introduce non backwards compatible nodes. The text could specify the > specific conditions where it is allowed to be used in a augmentation. > > We tried to identify such situations but it is not that easy. I think the > restriction should be removed and explain backward compatibility issues i= n > 6087bis. Module authors then have to decide whether a certain node needs = to > be defined as mandatory. > > If we clutter new modules with unnecessary p-containers, there will be no > way back. > > > > > Or, alternatively, perhaps allow for a must statement to simulate a > mandatory keyword in these cases - although I don't think that this > solution is particularly clear or clean. > > Exactly, it is an ugly hack to the same effect. > > Lada > > > > > Thanks, > > Rob > > > > > >> > >> > >> To me, in this scenario, it feels that you might as well forego both > the P-container and mandatory marking. > >> > >> Thanks, > >> Rob > >> > >> > >> > >> > >> Andy > >> > >> > >>> > >>> We already decided not to do anything useful wrt/ Y45, > >>> so we are stuck with the YANG module as the unit of conformance. > >>> > >>> > >>> Andy > >>> > >>> > >>> > >>> > >>> On Thu, Aug 13, 2015 at 7:07 AM, Ladislav Lhotka > wrote: > >>> Hi, > >>> > >>> although YANG 1.1 issue Y26 [1] is marked as DONE, I think the adopte= d > >>> solution Y26-02 is really horrible, so at least I want to make sure t= he > >>> WG is aware of the consequences. > >>> > >>> I am currently working on a data model for DNS zone data and the sche= ma > >>> is like this: > >>> > >>> module: dns-zones > >>> +--rw zones > >>> +--rw zone* [name] > >>> +--rw name inet:domain-name > >>> +--rw description? string > >>> +--rw class? ianadns:class > >>> +--rw rrset* [owner type] > >>> +--rw owner inet:domain-name > >>> +--rw type identityref > >>> +--rw description? string > >>> +--rw ttl positive-int32 > >>> +--rw rdata* [id] > >>> +--rw id string > >>> +--rw description? string > >>> > >>> The idea is that specific RDATA will be added for each RR type (with = a > >>> "when" condition based on "type"). Data for essential RR Types (SOA, > NS, > >>> A, AAAA, ...) can be defined in the same module but for some types th= ey > >>> need to be defined in other modules and added via augmenting the targ= et > >>> node "rdata". Typically, some (or all) of RDATA is mandatory, and thi= s > >>> is where Y26 comes into play. The solution recommended by Y26-02 woul= d > >>> look like this: > >>> > >>> augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" { > >>> when "derived-from-or-self(../dnsz:type,'iana-dns-parameters'," > >>> + "'TLSA')"; > >>> container rdata { // <=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > >>> presence "TLSA data"; > >>> leaf certificate-usage { > >>> mandatory true; > >>> ... > >>> } > >>> ... > >>> } > >>> } > >>> > >>> Note the superfluous presence container "rdata". It that just adds a > >>> useless level of hierarchy and still doesn't enforce the correct > >>> constraints: the data model allows the presence container to be missi= ng > >>> so that RDATA will be empty. Defining this extra container for all ~7= 5 > >>> RR types is a nuisance and it certainly won't make the modules more > >>> readable. > >>> > >>> As this situation is likely to be very common, I wonder: do we really > >>> want to do that? > >>> > >>> [1] > https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-27 > >>> > >>> Thanks, Lada > >>> > >>> -- > >>> Ladislav Lhotka, CZ.NIC Labs > >>> PGP Key ID: E74E8C0C > >>> > >>> _______________________________________________ > >>> netmod mailing list > >>> netmod@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netmod > >>> > >>> > >>> > >>> _______________________________________________ > >>> netmod mailing list > >>> > >>> netmod@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netmod > >> > >> > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a11c34238913643051d366313 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

IMO this is issue is closed.
<= div>I see no reason to re-open it.
YANG does not allow augments t= o add mandatory nodes.


Andy


On Thu, Aug 13, 2015 at 12:22 PM, Ladislav Lhotka <<= a href=3D"mailto:lhotka@nic.cz" target=3D"_blank">lhotka@nic.cz> wrote:

> On 13 Aug 2015, at 19:44, Robert Wilton <rwilton@cisco.com> wrote:
>
> Hi Andy,
>
> On 13/08/2015 17:08, Andy Bierman wrote:
>>
>>
>> On Thu, Aug 13, 2015 at 8:39 AM, Robert Wilton <rwilton@cisco.com> wrote:
>> Hi Andy, Lada,
>>
>> On 13/08/2015 15:46, Andy Bierman wrote:
>>> Hi,
>>>
>>>
>>> I'm not sure how many times we need to go over this issue.= ..
>>>
>>> YANG conformance is based on the YANG module.
>>> YANG has no concept of conformance beyond this
>>> simplistic approach,=C2=A0 You cannot assume (ever, under any = conditions)
>>> that module foo AND bar will both be present on a server.
>>>
>>> Therefore if a client is written to work with "foo",= it has no
>>> responsibility at all to know that "bar" adds a mand= atory
>>> node to a "foo" subtree.
>>>
>>> The extra P-container is needed to make sure clients written >>> to work with module "foo" do not break when new node= s are
>>> added via augments.
>>
>> I still don't see how a P-container really solves the problem = since any child mandatory nodes aren't really mandatory, or at least no= t in the way that is actually intended.
>>
>>
>>
>> The concepts behind old-manager/new-agent protection mechanisms go= back
>> a couple decades (with SNMP).=C2=A0 There is no way that a vendor = can control all
>> the applications using a particular module, and therefore mandate = a flag-day
>> upgrade on all clients, in order to upgrade some servers.
>>
> Yes, I agree in principle, but I'm not sure whether the default se= t of YANG modules has yet reaches the maturity that enforcing this rule tru= ly makes sense.=C2=A0 It feels that many of the YANG modules (even those ha= ve been standardized) are still some what at the experimental stage.=C2=A0 = This is effectively the same point that you make below.

Right. Another thing is that augment was IMO originally intended to allow f= or adding optional or vendor-specific parameters to a base data model. Howe= ver,=C2=A0 as it turned out, it is in fact used as an essential tool for de= veloping *base* data models in a modular fashion.

I have also argued several times that a client cherry-picking modules adver= tised by the server is fundamentally unsafe - it may work but may also brea= k things.

>
>>
>> YANG is very limited wrt/ adding new functionality,
>> A designer must guess correctly on all mandatory nodes
>> on the first version.=C2=A0 If this a bug, then it should be fixed=
>> properly, instead of just pretending it's OK to break
>> existing client apps.
>
> In Lada's case there is no base version, all of his modules are be= ing newly defined.=C2=A0 So, in this scenario, ideally that RR-type specifi= c modules should be allowed to augment with mandatory nodes since this must= effectively be backwards compatible.
>
>
>>
>> (YANG packages do not fix this problem BTW)
>>
>> Perhaps we need a new module-level "release" statement.<= br> >>
>>=C2=A0 =C2=A0 release stable;
>>=C2=A0 =C2=A0 release unstable;
>>=C2=A0 =C2=A0 release experimental;
>>
>> Then all the very strict YANG change control rules can be relaxed = on
>> unstable and experimental modules.
>
> Yes, this may make sense for other scenarios, but I don't see that= it helps with either of the problems that Lada or I have described.

It doesn=E2=80=99t, it is just hand-waving.

>
>>
>>
>>
>> E.g. in Lada's example having the P-container implies that for= a given RR type it is acceptable to either not provide any extra RR specif= ic config (i.e. no P-container), or if RR specific config is provided then = some fields must always be provided, and others can be left out.=C2=A0 I.e.= the P-container also needs to be mandatory for the configuration to be san= e.
>>
>>
>> A P-container insulates the old client because it would not know t= o
>> create it, and the mandatory child nodes are only checked if
>> the P-container exists.
> Yes, but in Lada's example, the P-container doesn't really hel= p anyone, since the server has to now handle the case that the RR-type has = been specified but the corresponding P-container isn't present.=C2=A0 I= f it is possible for the server to handle this scenario then the=C2=A0 =C2= =A0 =C2=A0mandatory child fields don't have to be mandatory either beca= use some sensible default must exist.=C2=A0 This implies that all servers w= ould likely reject the configuration as being invalid if the P-container is= n't also present.
>
> As I see it, having a P-container here only protects a old client in t= he scenario that it was mis-configured in the first place, i.e. using a par= ticular RR-type without the corresponding mandatory nodes being specified .= .. which a sane server should have rejected the config for previously.
>
> I don't really want to flog a dead horse, but I do think that the = mandatory rule could be relaxed to state that it cannot be used to introduc= e non backwards compatible nodes.=C2=A0 The text could specify the specific= conditions where it is allowed to be used in a augmentation.

We tried to identify such situations but it is not that easy. I think the r= estriction should be removed and explain backward compatibility issues in 6= 087bis. Module authors then have to decide whether a certain node needs to = be defined as mandatory.

If we clutter new modules with unnecessary p-containers, there will be no w= ay back.

>
> Or, alternatively, perhaps allow for a must statement to simulate a ma= ndatory keyword in these cases - although I don't think that this solut= ion is particularly clear or clean.

Exactly, it is an ugly hack to the same effect.

Lada

>
> Thanks,
> Rob
>
>
>>
>>
>> To me, in this scenario, it feels that you might as well forego bo= th the P-container and mandatory marking.
>>
>> Thanks,
>> Rob
>>
>>
>>
>>
>> Andy
>>
>>
>>>
>>> We already decided not to do anything useful wrt/ Y45,
>>> so we are stuck with the YANG module as the unit of conformanc= e.
>>>
>>>
>>> Andy
>>>
>>>
>>>
>>>
>>> On Thu, Aug 13, 2015 at 7:07 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>>> Hi,
>>>
>>> although YANG 1.1 issue Y26 [1] is marked as DONE, I think the= adopted
>>> solution Y26-02 is really horrible, so at least I want to make= sure the
>>> WG is aware of the consequences.
>>>
>>> I am currently working on a data model for DNS zone data and t= he schema
>>> is like this:
>>>
>>> module: dns-zones
>>>=C2=A0 =C2=A0 +--rw zones
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw zone* [name]
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw name=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0inet:domain-name
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw description?=C2=A0 =C2= =A0string
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw class?=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0ianadns:class
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw rrset* [owner type] >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw owner=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 inet:domain-name
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw type=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0identityref
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw descripti= on?=C2=A0 =C2=A0string
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw ttl=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 positive-int32
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw rdata* [i= d]
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw i= d=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0string
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw d= escription?=C2=A0 =C2=A0string
>>>
>>> The idea is that specific RDATA will be added for each RR type= (with a
>>> "when" condition based on "type"). Data fo= r essential RR Types (SOA, NS,
>>> A, AAAA, ...) can be defined in the same module but for some t= ypes they
>>> need to be defined in other modules and added via augmenting t= he target
>>> node "rdata". Typically, some (or all) of RDATA is m= andatory, and this
>>> is where Y26 comes into play. The solution recommended by Y26-= 02 would
>>> look like this:
>>>
>>> augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata"= ; {
>>>=C2=A0 =C2=A0 =C2=A0when "derived-from-or-self(../dnsz:typ= e,'iana-dns-parameters',"
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 + "'TLSA')";
>>>=C2=A0 =C2=A0 =C2=A0container rdata {=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 // <=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0presence "TLSA data"= ;;
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf certificate-usage {
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory true;=
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...
>>>=C2=A0 =C2=A0 =C2=A0}
>>> }
>>>
>>> Note the superfluous presence container "rdata". It = that just adds a
>>> useless level of hierarchy and still doesn't enforce the c= orrect
>>> constraints: the data model allows the presence container to b= e missing
>>> so that RDATA will be empty. Defining this extra container for= all ~75
>>> RR types is a nuisance and it certainly won't make the mod= ules more
>>> readable.
>>>
>>> As this situation is likely to be very common, I wonder: do we= really
>>> want to do that?
>>>
>>> [1] https://svn.too= ls.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-27
>>>
>>> Thanks, Lada
>>>
>>> --
>>> Ladislav Lhotka, CZ.NIC Labs
>>> PGP Key ID: E74E8C0C
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/net= mod
>>>
>>>
>>>
>>> _______________________________________________
>>> netmod mailing list
>>>
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/net= mod
>>
>>
>

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





--001a11c34238913643051d366313-- From nobody Thu Aug 13 12:41:09 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC941B39DC for ; Thu, 13 Aug 2015 12:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.011 X-Spam-Level: X-Spam-Status: No, score=-4.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, 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 vdIP7EgLwwgL for ; Thu, 13 Aug 2015 12:41:06 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 177AF1B39DB for ; Thu, 13 Aug 2015 12:41:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1439494811; bh=QqEFx4+FOmfspK4np89ZPTLCpFA63gFVRZoPFI9Eouw=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=MEy+Uv469P6NYt4TY6qFqg0pQdanqh1rcQNaypJzkWNdhTVTv3IPr0a0msuxA6DQ4 q6Bd1rxXDqAjMzg/VFPwHf1meJgZ11h+rDYNqqSF4vqf64V7/2BESkfNAMiDQF//7a 0aTmHeP9rM+jETftfckYnu9TMFlMsL9xtimzHR0o= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; Content-Type: multipart/alternative; boundary="Apple-Mail=_2E587113-5B6C-43BD-B569-8321F0BB3C9B" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Nadeau Thomas In-Reply-To: <55C4D830.8030601@cisco.com> Date: Thu, 13 Aug 2015 15:41:02 -0400 Message-Id: <95032778-8873-4B5A-8CE6-D74CD77AAD13@lucidvision.com> References: <1516231808.93378.1438887834598.JavaMail.nobody@jva2tc202.webex.com> <55C4D830.8030601@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.2102) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-ShareWhite: 50.255.148.181 X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=9 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181 X-IP-stats: Notspam Incoming Last 0, First 90, in=674, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: Cc: netmod-chairs@tools.ietf.org, netmod@ietf.org Subject: Re: [netmod] WebEx meeting invitation: NETMOD Interm meeting on OpenConfig X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 19:41:08 -0000 --Apple-Mail=_2E587113-5B6C-43BD-B569-8321F0BB3C9B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On Aug 7, 2015:12:09 PM, at 12:09 PM, Benoit Claise = wrote: >=20 > Dear all, >=20 > During the YANG Model Coordination Group webex call today, we = discussed=20 > this oper status and structure open issues. We're ready to help=20 > facilitate the discussion between the different proposals > We could compare the pros/cons of the different solutions from our = point=20 > of view. >=20 > To allow us some preparation time, alternate proposals should be = posted=20 > a week before the NETMOD interim meeting, i.e. Sept 3rd. >=20 > The YANG Model Coordination Group=20 Speaking as Co-chair: Just to clarify a bit on this. The purpose of the next Interim = meeting is to close on the issues around the Open Config proposal. We = meant to do this in Praha, but we could not get the right people to = attend the meeting to have the right discussion. We need to close on = this issue as soon as possible, as this is possibly blocking a lot of = other WG-related work; therefore, if no alternative proposals are posted = to discuss ahead of the interim meeting, then the original proposal will = become the solution to move forward with in the WG. Alternatives must be = complete proposals, not bullet points of complaints or such things - = they must be a solution or they will not be allowed onto the agenda. As = Benoit declared above, these must be posted ahead of the meeting and = will be put on the agenda for the meeting to present/discuss/debate as = well as to give everyone ample time to read and understand the = document/s. Thanks, =97Tom=20 >> Hello, >> NETMOD Working Group invites you to join this WebEx meeting. >> =20 >> NETMOD Interm meeting on OpenConfig >> Thursday, September 10, 2015=20 >> 11:00 am | Eastern Daylight Time (New York, GMT-04:00) | 1 hr=20 >> =20 >> Join WebEx meeting = >> Meeting number: 645 732 277=20 >> Meeting password: 1234 >> =20 >> Join by phone >> 1-877-668-4493 Call-in toll free number (US/Canada) >> 1-650-479-3208 Call-in toll number (US/Canada) >> Access code: 645 732 277 >> Toll-free calling restrictions = >> =20 >> Add this meeting = to your calendar. >> =20 >> Can't join the meeting? Contact support. = >> =20 >> IMPORTANT NOTICE: Please note that this WebEx service allows audio = and other information sent during the session to be recorded, which may = be discoverable in a legal matter. By joining this session, you = automatically consent to such recordings. If you do not consent to being = recorded, discuss your concerns with the host or do not join the = session. >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod = >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod = --Apple-Mail=_2E587113-5B6C-43BD-B569-8321F0BB3C9B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252



On Aug 7, 2015:12:09 PM, at 12:09 PM, Benoit = Claise <bclaise@cisco.com> wrote:

Dear all,

During the YANG Model Coordination Group webex call today, we discussed=20=

this oper status and structure open issues. We're ready to help=20
facilitate the discussion between the different proposals
We could compare the pros/cons of the different solutions from our point=20=

of view.

To allow us some preparation time, alternate proposals should be posted=20=

a week before the NETMOD interim meeting, i.e. Sept 3rd.

The YANG Model Coordination Group =
Speaking as = Co-chair:

Just to = clarify a bit on this. The purpose of the next Interim meeting is to = close on the issues around the Open Config proposal. We meant to do this = in Praha, but we could not get the right people to attend the meeting to = have the right discussion. We need to close on this issue as soon as = possible, as this is possibly blocking a lot of other WG-related work; = therefore, if no alternative proposals are posted to discuss ahead of = the interim meeting, then the original proposal will become the solution = to move forward with in the WG. Alternatives must be complete proposals, = not bullet points of complaints or such things - they must be a solution = or they will not be allowed onto the agenda.  As Benoit declared = above, these must be posted ahead of the meeting and will be put on the = agenda for the meeting to present/discuss/debate as well as to give = everyone ample time to read and understand the document/s.

Thanks,

=97Tom 



Hello,
NETMOD Working Group invites you to join this = WebEx meeting.
 
NETMOD = Interm meeting on OpenConfig
Thursday, September 10, 2015 
11:00 am  |  Eastern Daylight Time (New = York, GMT-04:00)  |  1 hr 
 
Join WebEx meeting
Meeting number:645 732 277 
Meeting = password:1234
 
Join by phone
1-877-668-4493 Call-in toll free = number (US/Canada)
1-650-479-3208 Call-in toll = number (US/Canada)
Access code: 645 732 277
Toll-free calling = restrictions
 
Add this = meeting to your = calendar.
 
Can't join the meeting? Contact = support.
 
IMPORTANT NOTICE: Please note that this WebEx = service allows audio and other information sent during the session to be = recorded, which may be discoverable in a legal matter. By joining this = session, you automatically consent to such recordings. If you do not = consent to being recorded, discuss your concerns with the host or do not = join the = session.


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

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

= --Apple-Mail=_2E587113-5B6C-43BD-B569-8321F0BB3C9B-- From nobody Thu Aug 13 12:44:04 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3047B1B3A33 for ; Thu, 13 Aug 2015 12:44:03 -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_75=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 raNaLN6N7r1f for ; Thu, 13 Aug 2015 12:44:01 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 474C31B3A20 for ; Thu, 13 Aug 2015 12:43:33 -0700 (PDT) Received: from [172.29.2.202] (nat-14.bravonet.cz [77.48.225.14]) by mail.nic.cz (Postfix) with ESMTPSA id CB366181718 for ; Thu, 13 Aug 2015 21:43:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1439495011; bh=i2bR11AYWIcTTTcZygzWkGN9psAKwpsvb40D+WJx9Rg=; h=From:Date:To; b=NjfqdgAOcHl8ZA80FvnmcwENV+ZRuD2btPu3hX9bFRR1ydzneJqTDFYu3si0Wod8B HPDLUJYn/rYcQ0dZUCI0ZWLdC1u2f+VW0b+DnmatxcGKbWaW74CtPaqyIQb6rUVKyr BIi4Ru0t3S1FJDsFvMfGKZsLHBikb4O9yn1j/Nss= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: Date: Thu, 13 Aug 2015 21:43:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55CCBA4F.9010101@cisco.com> <55CCD770.2030701@cisco.com> <586BF923-E9EA-4248-A838-55D3709A31BE@nic.cz> To: NETMOD Working Group X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] Y26 again, sorry X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 19:44:03 -0000 > On 13 Aug 2015, at 21:31, Andy Bierman wrote: >=20 > Hi, >=20 > IMO this is issue is closed. > I see no reason to re-open it. > YANG does not allow augments to add mandatory nodes. I strongly disagree with this attitude, this is a normal IETF procedure. = Things can be changed even during WGLC. Virtual interims aren=E2=80=99t good for discussing non-trivial = technical issues. Lada=20 >=20 >=20 > Andy >=20 >=20 > On Thu, Aug 13, 2015 at 12:22 PM, Ladislav Lhotka = wrote: >=20 > > On 13 Aug 2015, at 19:44, Robert Wilton wrote: > > > > Hi Andy, > > > > On 13/08/2015 17:08, Andy Bierman wrote: > >> > >> > >> On Thu, Aug 13, 2015 at 8:39 AM, Robert Wilton = wrote: > >> Hi Andy, Lada, > >> > >> On 13/08/2015 15:46, Andy Bierman wrote: > >>> Hi, > >>> > >>> > >>> I'm not sure how many times we need to go over this issue... > >>> > >>> YANG conformance is based on the YANG module. > >>> YANG has no concept of conformance beyond this > >>> simplistic approach, You cannot assume (ever, under any = conditions) > >>> that module foo AND bar will both be present on a server. > >>> > >>> Therefore if a client is written to work with "foo", it has no > >>> responsibility at all to know that "bar" adds a mandatory > >>> node to a "foo" subtree. > >>> > >>> The extra P-container is needed to make sure clients written > >>> to work with module "foo" do not break when new nodes are > >>> added via augments. > >> > >> I still don't see how a P-container really solves the problem since = any child mandatory nodes aren't really mandatory, or at least not in = the way that is actually intended. > >> > >> > >> > >> The concepts behind old-manager/new-agent protection mechanisms go = back > >> a couple decades (with SNMP). There is no way that a vendor can = control all > >> the applications using a particular module, and therefore mandate a = flag-day > >> upgrade on all clients, in order to upgrade some servers. > >> > > Yes, I agree in principle, but I'm not sure whether the default set = of YANG modules has yet reaches the maturity that enforcing this rule = truly makes sense. It feels that many of the YANG modules (even those = have been standardized) are still some what at the experimental stage. = This is effectively the same point that you make below. >=20 > Right. Another thing is that augment was IMO originally intended to = allow for adding optional or vendor-specific parameters to a base data = model. However, as it turned out, it is in fact used as an essential = tool for developing *base* data models in a modular fashion. >=20 > I have also argued several times that a client cherry-picking modules = advertised by the server is fundamentally unsafe - it may work but may = also break things. >=20 > > > >> > >> YANG is very limited wrt/ adding new functionality, > >> A designer must guess correctly on all mandatory nodes > >> on the first version. If this a bug, then it should be fixed > >> properly, instead of just pretending it's OK to break > >> existing client apps. > > > > In Lada's case there is no base version, all of his modules are = being newly defined. So, in this scenario, ideally that RR-type = specific modules should be allowed to augment with mandatory nodes since = this must effectively be backwards compatible. > > > > > >> > >> (YANG packages do not fix this problem BTW) > >> > >> Perhaps we need a new module-level "release" statement. > >> > >> release stable; > >> release unstable; > >> release experimental; > >> > >> Then all the very strict YANG change control rules can be relaxed = on > >> unstable and experimental modules. > > > > Yes, this may make sense for other scenarios, but I don't see that = it helps with either of the problems that Lada or I have described. >=20 > It doesn=E2=80=99t, it is just hand-waving. >=20 > > > >> > >> > >> > >> E.g. in Lada's example having the P-container implies that for a = given RR type it is acceptable to either not provide any extra RR = specific config (i.e. no P-container), or if RR specific config is = provided then some fields must always be provided, and others can be = left out. I.e. the P-container also needs to be mandatory for the = configuration to be sane. > >> > >> > >> A P-container insulates the old client because it would not know to > >> create it, and the mandatory child nodes are only checked if > >> the P-container exists. > > Yes, but in Lada's example, the P-container doesn't really help = anyone, since the server has to now handle the case that the RR-type has = been specified but the corresponding P-container isn't present. If it = is possible for the server to handle this scenario then the = mandatory child fields don't have to be mandatory either because some = sensible default must exist. This implies that all servers would likely = reject the configuration as being invalid if the P-container isn't also = present. > > > > As I see it, having a P-container here only protects a old client in = the scenario that it was mis-configured in the first place, i.e. using a = particular RR-type without the corresponding mandatory nodes being = specified ... which a sane server should have rejected the config for = previously. > > > > I don't really want to flog a dead horse, but I do think that the = mandatory rule could be relaxed to state that it cannot be used to = introduce non backwards compatible nodes. The text could specify the = specific conditions where it is allowed to be used in a augmentation. >=20 > We tried to identify such situations but it is not that easy. I think = the restriction should be removed and explain backward compatibility = issues in 6087bis. Module authors then have to decide whether a certain = node needs to be defined as mandatory. >=20 > If we clutter new modules with unnecessary p-containers, there will be = no way back. >=20 > > > > Or, alternatively, perhaps allow for a must statement to simulate a = mandatory keyword in these cases - although I don't think that this = solution is particularly clear or clean. >=20 > Exactly, it is an ugly hack to the same effect. >=20 > Lada >=20 > > > > Thanks, > > Rob > > > > > >> > >> > >> To me, in this scenario, it feels that you might as well forego = both the P-container and mandatory marking. > >> > >> Thanks, > >> Rob > >> > >> > >> > >> > >> Andy > >> > >> > >>> > >>> We already decided not to do anything useful wrt/ Y45, > >>> so we are stuck with the YANG module as the unit of conformance. > >>> > >>> > >>> Andy > >>> > >>> > >>> > >>> > >>> On Thu, Aug 13, 2015 at 7:07 AM, Ladislav Lhotka = wrote: > >>> Hi, > >>> > >>> although YANG 1.1 issue Y26 [1] is marked as DONE, I think the = adopted > >>> solution Y26-02 is really horrible, so at least I want to make = sure the > >>> WG is aware of the consequences. > >>> > >>> I am currently working on a data model for DNS zone data and the = schema > >>> is like this: > >>> > >>> module: dns-zones > >>> +--rw zones > >>> +--rw zone* [name] > >>> +--rw name inet:domain-name > >>> +--rw description? string > >>> +--rw class? ianadns:class > >>> +--rw rrset* [owner type] > >>> +--rw owner inet:domain-name > >>> +--rw type identityref > >>> +--rw description? string > >>> +--rw ttl positive-int32 > >>> +--rw rdata* [id] > >>> +--rw id string > >>> +--rw description? string > >>> > >>> The idea is that specific RDATA will be added for each RR type = (with a > >>> "when" condition based on "type"). Data for essential RR Types = (SOA, NS, > >>> A, AAAA, ...) can be defined in the same module but for some types = they > >>> need to be defined in other modules and added via augmenting the = target > >>> node "rdata". Typically, some (or all) of RDATA is mandatory, and = this > >>> is where Y26 comes into play. The solution recommended by Y26-02 = would > >>> look like this: > >>> > >>> augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" { > >>> when = "derived-from-or-self(../dnsz:type,'iana-dns-parameters'," > >>> + "'TLSA')"; > >>> container rdata { // <=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > >>> presence "TLSA data"; > >>> leaf certificate-usage { > >>> mandatory true; > >>> ... > >>> } > >>> ... > >>> } > >>> } > >>> > >>> Note the superfluous presence container "rdata". It that just adds = a > >>> useless level of hierarchy and still doesn't enforce the correct > >>> constraints: the data model allows the presence container to be = missing > >>> so that RDATA will be empty. Defining this extra container for all = ~75 > >>> RR types is a nuisance and it certainly won't make the modules = more > >>> readable. > >>> > >>> As this situation is likely to be very common, I wonder: do we = really > >>> want to do that? > >>> > >>> [1] = https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-27 > >>> > >>> Thanks, Lada > >>> > >>> -- > >>> Ladislav Lhotka, CZ.NIC Labs > >>> PGP Key ID: E74E8C0C > >>> > >>> _______________________________________________ > >>> netmod mailing list > >>> netmod@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netmod > >>> > >>> > >>> > >>> _______________________________________________ > >>> netmod mailing list > >>> > >>> netmod@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netmod > >> > >> > > >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Aug 13 13:03:38 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23911B3A99 for ; Thu, 13 Aug 2015 13:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.378 X-Spam-Level: X-Spam-Status: No, score=-3.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, 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 Yrz-vK2UNMcD for ; Thu, 13 Aug 2015 13:03:35 -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 C21EA1B3A96 for ; Thu, 13 Aug 2015 13:03:34 -0700 (PDT) Received: by labd1 with SMTP id d1so32552279lab.1 for ; Thu, 13 Aug 2015 13:03:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=XwGnBalH6c/Tp7Bku2GMQCcJCzMRcR3MrCGB7X6TXUI=; b=Ex46+Gq2qqOM3VUkgBZptKCqAVP3sbQySt2WD3PYX0IvVUL13UU0udKF6OlB8JR2k3 TnCOTwIB7XU1yDC33XebCjS6pCZVCheBgIXOMGJXeXVMcbPaS2sJ+2+Y6Nik/VAXcymV o2r6SnA2/qSZeH6ouxorLaxokCdcXcFIrOvYZWFqG52M+Vv4CiWWguecshX3DYyV5mez AwseHENmWEmzE5RNrEoU0DWVF50+GERLiSJAMqgOBKc3xnQJwmB6sZDL5gkIzD+XrWn1 8//IgTIElY0wHe5oAoatJD+1+4FeBtsPODxfGVq/DplVEp/n3JJZ1aPPCRl7nOomDH/v MQKQ== X-Gm-Message-State: ALoCoQmHcIf7ZTiKngz9Dxnf38DZApC5o8RwpIYlGik8oD/uhhgzjxpriF6Y0nyIfX6Wy4T7eiu2 MIME-Version: 1.0 X-Received: by 10.152.87.116 with SMTP id w20mr38231499laz.119.1439496213231; Thu, 13 Aug 2015 13:03:33 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Thu, 13 Aug 2015 13:03:33 -0700 (PDT) In-Reply-To: <95032778-8873-4B5A-8CE6-D74CD77AAD13@lucidvision.com> References: <1516231808.93378.1438887834598.JavaMail.nobody@jva2tc202.webex.com> <55C4D830.8030601@cisco.com> <95032778-8873-4B5A-8CE6-D74CD77AAD13@lucidvision.com> Date: Thu, 13 Aug 2015 13:03:33 -0700 Message-ID: From: Andy Bierman To: Nadeau Thomas Content-Type: multipart/alternative; boundary=001a11c237c47214d8051d36d4fe Archived-At: Cc: "netmod-chairs@tools.ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] WebEx meeting invitation: NETMOD Interm meeting on OpenConfig X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 20:03:37 -0000 --001a11c237c47214d8051d36d4fe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Aug 13, 2015 at 12:41 PM, Nadeau Thomas wrote: > > > > On Aug 7, 2015:12:09 PM, at 12:09 PM, Benoit Claise > wrote: > > Dear all, > > During the YANG Model Coordination Group webex call today, we discussed > this oper status and structure open issues. We're ready to help > facilitate the discussion between the different proposals > We could compare the pros/cons of the different solutions from our point > of view. > > To allow us some preparation time, alternate proposals should be posted > a week before the NETMOD interim meeting, i.e. Sept 3rd. > > The YANG Model Coordination Group > > Speaking as Co-chair: > > Just to clarify a bit on this. The purpose of the next Interim meeting is > to close on the issues around the Open Config proposal. We meant to do th= is > in Praha, but we could not get the right people to attend the meeting to > have the right discussion. We need to close on this issue as soon as > possible, as this is possibly blocking a lot of other WG-related work; > therefore, if no alternative proposals are posted to discuss ahead of the > interim meeting, then the original proposal will become the solution to > move forward with in the WG. Alternatives must be complete proposals, not > bullet points of complaints or such things - they must be a solution or > they will not be allowed onto the agenda. As Benoit declared above, thes= e > must be posted ahead of the meeting and will be put on the agenda for the > meeting to present/discuss/debate as well as to give everyone ample time = to > read and understand the document/s. > > Are you proposing that all existing RFCs with YANG modules in them be changed to "obsolete", and new modules published that move the data under a container named "device" (from some TBD module)? If not, then what is the proposal for data root placement for existing RFC modules? Are you also proposing that all YANG modules with config in them must define that config in a grouping, and all config must appear in a container named "config"? Also, that all config data must be replicated (i.e., use that grouping) under a config false container named ? This will be done even though in 90% of all servers, it doesn't take very long for intended config to become the active config? If not, then what is the exact proposal for usage within IETF modules? Everyone should understand the impact of these changes. Silence should not mean "I read the openconfig proposals and approve of these changes". Only emails to this list that state as much should mean that. Thanks, > > =E2=80=94Tom > > > Andy > > Hello,NETMOD Working Group invites you to join this WebEx meeting. *NETMO= D > Interm meeting on OpenConfig*Thursday, September 10, 2015 11:00 > am | Eastern Daylight Time (New York, GMT-04:00) | 1 hr *Join WebEx > meeting* > Meeting > number:645 732 277 Meeting password:1234 *Join by phone**1-877-668-4493* = Call-in > toll free number (US/Canada)*1-650-479-3208* Call-in toll number > (US/Canada)Access code: 645 732 277Toll-free calling restrictions > Add this meeting > > to your calendar. Can't join the meeting? Contact support. > IMPORTANT NOTICE: Please note that this > WebEx service allows audio and other information sent during the session = to > be recorded, which may be discoverable in a legal matter. By joining this > session, you automatically consent to such recordings. If you do not > consent to being recorded, discuss your concerns with the host or do not > join the session. > > _______________________________________________ > netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/n= etmod > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --001a11c237c47214d8051d36d4fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Aug 13, 2015 at 12:41 PM, Nadeau Thomas <<= a href=3D"mailto:tnadeau@lucidvision.com" target=3D"_blank">tnadeau@lucidvi= sion.com> wrote:



On Aug 7, 2015:12:09 PM, at 12:09 PM, Benoit Claise = <bclaise@cisco.co= m> wrote:

Dear all,

During the YANG Model Coordination Group webex call today, we discussed=20
this oper status and structure open issues. We're ready to help=20
facilitate the discussion between the different proposals
We could compare the pros/cons of the different solutions from our point=20
of view.

To allow us some preparation time, alternate proposals should be posted=20
a week before the NETMOD interim meeting, i.e. Sept 3rd.

The YANG Model Coordination Group
Speaking as Co-chair:
Just to clarify a = bit on this. The purpose of the next Interim meeting is to close on the iss= ues around the Open Config proposal. We meant to do this in Praha, but we c= ould not get the right people to attend the meeting to have the right discu= ssion. We need to close on this issue as soon as possible, as this is possi= bly blocking a lot of other WG-related work; therefore, if no alternative p= roposals are posted to discuss ahead of the interim meeting, then the origi= nal proposal will become the solution to move forward with in the WG. Alter= natives must be complete proposals, not bullet points of complaints or such= things - they must be a solution or they will not be allowed onto the agen= da.=C2=A0 As Benoit declared above, these must be posted ahead of the meeti= ng and will be put on the agenda for the meeting to present/discuss/debate = as well as to give everyone ample time to read and understand the document/= s.



Are you proposing that all existing RFCs with YANG modules in them = be
changed to "obsolete", and new modules published tha= t move the data
under a container named "device" (from = some TBD module)?=C2=A0 If not, then
what is the proposal for dat= a root placement for existing RFC modules?

Are you= also proposing that all YANG modules with config in them must
de= fine that config in a grouping, and all config must appear in a
c= ontainer named "config"? Also, that all config data must be repli= cated
(i.e., use that grouping) under a config false container na= med <state>?
This will be done even though in 90% of all se= rvers, it doesn't take very
long for intended config to becom= e the active config?=C2=A0 If not, then what
is the exact proposa= l for usage within IETF modules?

Everyone should u= nderstand the impact of these changes.
Silence should not mean &q= uot;I read the openconfig proposals and
approve of these changes&= quot;.=C2=A0 Only emails to this list that state as much
should m= ean that.



Thanks,

=E2=80=94Tom=C2=A0
=



<= /div>
Andy
=C2=A0

=
<= table align=3D"left" width=3D"100%" style=3D"border-collapse:separate;borde= r:0px white;border-spacing:0px;width:100%!important;max-width:525px!importa= nt;min-width:279px!important;padding:0px;margin:0px"><= tr style=3D"line-height:20px">
Hello,
NETMOD Working Group invites you to join this WebEx meeting.
=C2=A0
NETMOD Interm meeting on OpenConfigThursday, September 10, 2015=C2=A011:00 am=C2=A0=C2=A0|=C2=A0=C2=A0Eastern Daylight Time (New York, GMT-0= 4:00)=C2=A0=C2=A0|=C2=A0=C2=A01 hr=C2=A0
=C2=A0
Join WebEx meeting<= /td>
=
Meeting number:645 732 277=C2=A0
Meeting password:1234
= =C2=A0
Join by phone
1-877-668-4493=C2=A0Call-in toll free number (US/Canada)
1-650-479-3208=C2=A0Call-in toll number (US/Can= ada)
Access code:=C2=A0645 732 277
Toll-free calling restrictions
=C2=A0
Add this meeting<= /a>=C2=A0to your calendar.
=C2=A0
Can't join the me= eting?=C2=A0Contact support.
=C2=A0
IMPOR= TANT NOTICE: Please note that this WebEx service allows audio and other inf= ormation sent during the session to be recorded, which may be discoverable = in a legal matter. By joining this session, you automatically consent to su= ch recordings. If you do not consent to being recorded, discuss your concer= ns with the host or do not join the session.
= 
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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


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


--001a11c237c47214d8051d36d4fe-- From nobody Thu Aug 13 13:14:48 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 082961B3AB3 for ; Thu, 13 Aug 2015 13:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.011 X-Spam-Level: X-Spam-Status: No, score=-4.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, 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 jqBS1i2mqRzi for ; Thu, 13 Aug 2015 13:14:45 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A7C41ACD11 for ; Thu, 13 Aug 2015 13:14:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1439496831; bh=1oF2ekF197ZAAIUC+3sxtjMHj/KDhwJ8X/63xAhZrUE=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=TR/k8U6CZOFx/pluxMgQmUx7kBjRvQkc9fbbC7/5cchDVWF00caYFJr1x2L9KHv/5 Stg34Pk9U7mo0ZgXBYSjRuuCHNPSf3Sg9yugJWhW6hg7aepsTgimbnb39iR89Sll3m JaH4ejvDdy7pHn6fKoG581B0aAa4HkcpArxS2McA= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; Content-Type: multipart/alternative; boundary="Apple-Mail=_9C718B0D-B7DD-4F39-B7A4-9FBF8BF2BDE4" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Nadeau Thomas In-Reply-To: Date: Thu, 13 Aug 2015 16:14:41 -0400 Message-Id: <958632F2-A758-4EC0-8D92-0B6C88DE187A@lucidvision.com> References: <1516231808.93378.1438887834598.JavaMail.nobody@jva2tc202.webex.com> <55C4D830.8030601@cisco.com> <95032778-8873-4B5A-8CE6-D74CD77AAD13@lucidvision.com> To: Andy Bierman X-Mailer: Apple Mail (2.2102) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-ShareWhite: 50.255.148.181 X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=10 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181 X-IP-stats: Notspam Incoming Last 0, First 90, in=675, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: Cc: "netmod-chairs@tools.ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] WebEx meeting invitation: NETMOD Interm meeting on OpenConfig X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 20:14:48 -0000 --Apple-Mail=_9C718B0D-B7DD-4F39-B7A4-9FBF8BF2BDE4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 13, 2015:4:03 PM, at 4:03 PM, Andy Bierman = wrote: >=20 >=20 >=20 > On Thu, Aug 13, 2015 at 12:41 PM, Nadeau Thomas = > wrote: >=20 >=20 >=20 >> On Aug 7, 2015:12:09 PM, at 12:09 PM, Benoit Claise = > wrote: >>=20 >> Dear all, >>=20 >> During the YANG Model Coordination Group webex call today, we = discussed=20 >> this oper status and structure open issues. We're ready to help=20 >> facilitate the discussion between the different proposals >> We could compare the pros/cons of the different solutions from our = point=20 >> of view. >>=20 >> To allow us some preparation time, alternate proposals should be = posted=20 >> a week before the NETMOD interim meeting, i.e. Sept 3rd. >>=20 >> The YANG Model Coordination Group=20 > Speaking as Co-chair: >=20 > Just to clarify a bit on this. The purpose of the next Interim = meeting is to close on the issues around the Open Config proposal. We = meant to do this in Praha, but we could not get the right people to = attend the meeting to have the right discussion. We need to close on = this issue as soon as possible, as this is possibly blocking a lot of = other WG-related work; therefore, if no alternative proposals are posted = to discuss ahead of the interim meeting, then the original proposal will = become the solution to move forward with in the WG. Alternatives must be = complete proposals, not bullet points of complaints or such things - = they must be a solution or they will not be allowed onto the agenda. As = Benoit declared above, these must be posted ahead of the meeting and = will be put on the agenda for the meeting to present/discuss/debate as = well as to give everyone ample time to read and understand the = document/s. >=20 >=20 >=20 > Are you proposing that all existing RFCs with YANG modules in them be > changed to "obsolete", and new modules published that move the data > under a container named "device" (from some TBD module)? If not, then > what is the proposal for data root placement for existing RFC modules? >=20 > Are you also proposing that all YANG modules with config in them must > define that config in a grouping, and all config must appear in a > container named "config"? Also, that all config data must be = replicated > (i.e., use that grouping) under a config false container named = ? > This will be done even though in 90% of all servers, it doesn't take = very > long for intended config to become the active config? If not, then = what > is the exact proposal for usage within IETF modules? >=20 > Everyone should understand the impact of these changes. > Silence should not mean "I read the openconfig proposals and > approve of these changes". Only emails to this list that state as = much > should mean that. Andy, Yes, people should read and understand the proposal. If they = don=E2=80=99t like it please come up with a=20 viable alternative. If the alternative is to do nothing, then propose = that and we will see what the consensus=20 is. If the proposal is to constructively alter parts of their proposal, = thats great too. After we get consensus on=20 the general approach, I will manage things issue-by-issue as we are = doing with other major initiatives in=20 NETMOD. What we will not do is continue to go round and round about = points of their proposal without coming to any conclusions. We=E2=80=99ve had several interim meetings = where they have taken the time to=20 discuss and educate everyone that is interested in how their approach = works and why. To-date, there=20 are no alternatives being proposed resulting from those discussions - = just more debate/discussion. =20 What the management is declaring is that the time has come to move = forward on this, one way or=20 another. =E2=80=94Tom >=20 >=20 > Thanks, >=20 > =E2=80=94Tom=20 >=20 >=20 >=20 >=20 > Andy > =20 >=20 >>> Hello, >>> NETMOD Working Group invites you to join this WebEx meeting. >>> =20 >>> NETMOD Interm meeting on OpenConfig >>> Thursday, September 10, 2015=20 >>> 11:00 am | Eastern Daylight Time (New York, GMT-04:00) | 1 hr=20 >>> =20 >>> Join WebEx meeting = >>> Meeting number: 645 732 277=20 >>> Meeting password: 1234 >>> =20 >>> Join by phone >>> 1-877-668-4493 Call-in toll free number (US/Canada) >>> 1-650-479-3208 Call-in toll number (US/Canada) >>> Access code: 645 732 277 >>> Toll-free calling restrictions = >>> =20 >>> Add this meeting = to your calendar. >>> =20 >>> Can't join the meeting? Contact support. = >>> =20 >>> IMPORTANT NOTICE: Please note that this WebEx service allows audio = and other information sent during the session to be recorded, which may = be discoverable in a legal matter. By joining this session, you = automatically consent to such recordings. If you do not consent to being = recorded, discuss your concerns with the host or do not join the = session. >>>=20 >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod = >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod = >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod = >=20 >=20 --Apple-Mail=_9C718B0D-B7DD-4F39-B7A4-9FBF8BF2BDE4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Aug 13, 2015:4:03 PM, at 4:03 PM, Andy Bierman <andy@yumaworks.com> = wrote:



On Thu, Aug 13, 2015 at 12:41 PM, = Nadeau Thomas <tnadeau@lucidvision.com> wrote:



On Aug = 7, 2015:12:09 PM, at 12:09 PM, Benoit Claise <bclaise@cisco.com> wrote:

Dear all,

During the YANG Model Coordination Group webex call today, we discussed=20=

this oper status and structure open issues. We're ready to help=20
facilitate the discussion between the different proposals
We could compare the pros/cons of the different solutions from our point=20=

of view.

To allow us some preparation time, alternate proposals should be posted=20=

a week before the NETMOD interim meeting, i.e. Sept 3rd.

The YANG Model Coordination Group
= Speaking as Co-chair:

Just to clarify a bit on this. The purpose of the = next Interim meeting is to close on the issues around the Open Config = proposal. We meant to do this in Praha, but we could not get the right = people to attend the meeting to have the right discussion. We need to = close on this issue as soon as possible, as this is possibly blocking a = lot of other WG-related work; therefore, if no alternative proposals are = posted to discuss ahead of the interim meeting, then the original = proposal will become the solution to move forward with in the WG. = Alternatives must be complete proposals, not bullet points of complaints = or such things - they must be a solution or they will not be allowed = onto the agenda.  As Benoit declared above, these must be posted = ahead of the meeting and will be put on the agenda for the meeting to = present/discuss/debate as well as to give everyone ample time to read = and understand the document/s.



Are = you proposing that all existing RFCs with YANG modules in them = be
changed to "obsolete", and new modules published = that move the data
under a container named "device" = (from some TBD module)?  If not, then
what is = the proposal for data root placement for existing RFC modules?

Are you also proposing = that all YANG modules with config in them must
define= that config in a grouping, and all config must appear in a
container named "config"? Also, that all config data must be = replicated
(i.e., use that grouping) under a config = false container named <state>?
This will be = done even though in 90% of all servers, it doesn't take very
long for intended config to become the active config?  = If not, then what
is the exact proposal for usage = within IETF modules?

Everyone should understand the impact of these = changes.
Silence should not mean "I read the = openconfig proposals and
approve of these = changes".  Only emails to this list that state as much
should mean = that.

Andy,

Yes, people should read and = understand the proposal. If they don=E2=80=99t like it please come up = with a 
viable alternative. If the alternative is to do = nothing, then propose that and we will see what the = consensus 
is.  If the proposal is to constructively = alter parts of their proposal, thats great too.  After we get = consensus on 
the general approach, I will manage things = issue-by-issue as we are doing with other major initiatives = in 
NETMOD.  What we will not do is continue to go = round and round about points of their proposal without
coming = to any conclusions. We=E2=80=99ve had several interim meetings where = they have taken the time to 
discuss and educate everyone = that is interested in how their approach works and why.  To-date, = there 
are no alternatives being proposed resulting from = those discussions - just more debate/discussion.  
What = the management is declaring is that the time has come to move forward on = this, one way or 
another.

=E2=80=94Tom






Thanks,

= =E2=80=94Tom 




Andy
 

Hello,
NETMOD = Working Group invites you to join this WebEx = meeting.
 
NETMOD = Interm meeting on OpenConfig
Thursday, = September 10, 2015 
11:00 = am  |  Eastern Daylight Time (New York, = GMT-04:00)  |  1 hr 
 
Join = WebEx meeting
Meeting = number:645 732 277 
Meeting = password:1234
 
Join = by phone
1-877-668-4493 Call-in toll free number = (US/Canada)
1-650-479-3208 Call-in toll number = (US/Canada)
Access = code: 645 732 277
Toll-free calling = restrictions
 
Add this = meeting to your = calendar.
 
Can't join the = meeting? Contact = support.
 
IMPORTANT NOTICE: = Please note that this WebEx service allows audio and other information = sent during the session to be recorded, which may be discoverable in a = legal matter. By joining this session, you automatically consent to such = recordings. If you do not consent to being recorded, discuss your = concerns with the host or do not join the = session.


_______________________________________________=

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

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


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


= --Apple-Mail=_9C718B0D-B7DD-4F39-B7A4-9FBF8BF2BDE4-- From nobody Thu Aug 13 13:15:16 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C274C1B3AB9 for ; Thu, 13 Aug 2015 13:15:14 -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_75=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 0RUCWDJIJJ11 for ; Thu, 13 Aug 2015 13:15:11 -0700 (PDT) Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5B9B1B3AB8 for ; Thu, 13 Aug 2015 13:15:10 -0700 (PDT) Received: by lagz9 with SMTP id z9so32500756lag.3 for ; Thu, 13 Aug 2015 13:15:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9YBNBP2R74W8PV+b/f4RJ70vViBnNTwbqSk+0VVSM30=; b=fPKXRN7P0jM4cqiGax18tGAIo+p/0tVxMbYp2swCSfqDsoZxIfrh4nhR/9YXZnG0sG i+TIbUMiUFjUdpF5DME9YbI6zCssR3vXtVe5FOBpjX53n88NY3ch75IrBZXl0kt22Tkr pn8pArrPWbEobzUjGvxAU1DhzWKf3U/FwUXHfuoj59utzZenG/WvzuRbcPjmejzKPpX+ iOREwKRoCipVPdT6xCLkl4WdGA7WuWz/OhkIxfQh6g365LConD8qX7KNrPahACI3KXk5 LKYcdwiMjVOkBaGiS/+bxjk16Z8XqwDI2TITTZrISkFdjbhT3jpV6fZzhdhk5XAkBGeg LNFQ== X-Gm-Message-State: ALoCoQnxsBeFscZfQOy6nsTLX19A7jyH3uyYdPz5paO+6LiFLkUeqEOIL4fNRk7QCbHTR4pIiCDe MIME-Version: 1.0 X-Received: by 10.112.170.2 with SMTP id ai2mr32881428lbc.82.1439496909132; Thu, 13 Aug 2015 13:15:09 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Thu, 13 Aug 2015 13:15:09 -0700 (PDT) In-Reply-To: References: <55CCBA4F.9010101@cisco.com> <55CCD770.2030701@cisco.com> <586BF923-E9EA-4248-A838-55D3709A31BE@nic.cz> Date: Thu, 13 Aug 2015 13:15:09 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c33e18ecb2a0051d36fd0b Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Y26 again, sorry X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 20:15:15 -0000 --001a11c33e18ecb2a0051d36fd0b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Aug 13, 2015 at 12:43 PM, Ladislav Lhotka wrote: > > > On 13 Aug 2015, at 21:31, Andy Bierman wrote: > > > > Hi, > > > > IMO this is issue is closed. > > I see no reason to re-open it. > > YANG does not allow augments to add mandatory nodes. > > I strongly disagree with this attitude, this is a normal IETF procedure. > Things can be changed even during WGLC. > > Virtual interims aren=E2=80=99t good for discussing non-trivial technical= issues. > > I am not hearing any new arguments for changing this rule for augments. It's up to the co-chairs whether they want to re-open this issue. > Lada > Andy > > > > > > > Andy > > > > > > On Thu, Aug 13, 2015 at 12:22 PM, Ladislav Lhotka wrote= : > > > > > On 13 Aug 2015, at 19:44, Robert Wilton wrote: > > > > > > Hi Andy, > > > > > > On 13/08/2015 17:08, Andy Bierman wrote: > > >> > > >> > > >> On Thu, Aug 13, 2015 at 8:39 AM, Robert Wilton > wrote: > > >> Hi Andy, Lada, > > >> > > >> On 13/08/2015 15:46, Andy Bierman wrote: > > >>> Hi, > > >>> > > >>> > > >>> I'm not sure how many times we need to go over this issue... > > >>> > > >>> YANG conformance is based on the YANG module. > > >>> YANG has no concept of conformance beyond this > > >>> simplistic approach, You cannot assume (ever, under any conditions= ) > > >>> that module foo AND bar will both be present on a server. > > >>> > > >>> Therefore if a client is written to work with "foo", it has no > > >>> responsibility at all to know that "bar" adds a mandatory > > >>> node to a "foo" subtree. > > >>> > > >>> The extra P-container is needed to make sure clients written > > >>> to work with module "foo" do not break when new nodes are > > >>> added via augments. > > >> > > >> I still don't see how a P-container really solves the problem since > any child mandatory nodes aren't really mandatory, or at least not in the > way that is actually intended. > > >> > > >> > > >> > > >> The concepts behind old-manager/new-agent protection mechanisms go > back > > >> a couple decades (with SNMP). There is no way that a vendor can > control all > > >> the applications using a particular module, and therefore mandate a > flag-day > > >> upgrade on all clients, in order to upgrade some servers. > > >> > > > Yes, I agree in principle, but I'm not sure whether the default set o= f > YANG modules has yet reaches the maturity that enforcing this rule truly > makes sense. It feels that many of the YANG modules (even those have bee= n > standardized) are still some what at the experimental stage. This is > effectively the same point that you make below. > > > > Right. Another thing is that augment was IMO originally intended to > allow for adding optional or vendor-specific parameters to a base data > model. However, as it turned out, it is in fact used as an essential too= l > for developing *base* data models in a modular fashion. > > > > I have also argued several times that a client cherry-picking modules > advertised by the server is fundamentally unsafe - it may work but may al= so > break things. > > > > > > > >> > > >> YANG is very limited wrt/ adding new functionality, > > >> A designer must guess correctly on all mandatory nodes > > >> on the first version. If this a bug, then it should be fixed > > >> properly, instead of just pretending it's OK to break > > >> existing client apps. > > > > > > In Lada's case there is no base version, all of his modules are being > newly defined. So, in this scenario, ideally that RR-type specific modul= es > should be allowed to augment with mandatory nodes since this must > effectively be backwards compatible. > > > > > > > > >> > > >> (YANG packages do not fix this problem BTW) > > >> > > >> Perhaps we need a new module-level "release" statement. > > >> > > >> release stable; > > >> release unstable; > > >> release experimental; > > >> > > >> Then all the very strict YANG change control rules can be relaxed on > > >> unstable and experimental modules. > > > > > > Yes, this may make sense for other scenarios, but I don't see that it > helps with either of the problems that Lada or I have described. > > > > It doesn=E2=80=99t, it is just hand-waving. > > > > > > > >> > > >> > > >> > > >> E.g. in Lada's example having the P-container implies that for a > given RR type it is acceptable to either not provide any extra RR specifi= c > config (i.e. no P-container), or if RR specific config is provided then > some fields must always be provided, and others can be left out. I.e. th= e > P-container also needs to be mandatory for the configuration to be sane. > > >> > > >> > > >> A P-container insulates the old client because it would not know to > > >> create it, and the mandatory child nodes are only checked if > > >> the P-container exists. > > > Yes, but in Lada's example, the P-container doesn't really help > anyone, since the server has to now handle the case that the RR-type has > been specified but the corresponding P-container isn't present. If it is > possible for the server to handle this scenario then the mandatory > child fields don't have to be mandatory either because some sensible > default must exist. This implies that all servers would likely reject th= e > configuration as being invalid if the P-container isn't also present. > > > > > > As I see it, having a P-container here only protects a old client in > the scenario that it was mis-configured in the first place, i.e. using a > particular RR-type without the corresponding mandatory nodes being > specified ... which a sane server should have rejected the config for > previously. > > > > > > I don't really want to flog a dead horse, but I do think that the > mandatory rule could be relaxed to state that it cannot be used to > introduce non backwards compatible nodes. The text could specify the > specific conditions where it is allowed to be used in a augmentation. > > > > We tried to identify such situations but it is not that easy. I think > the restriction should be removed and explain backward compatibility issu= es > in 6087bis. Module authors then have to decide whether a certain node nee= ds > to be defined as mandatory. > > > > If we clutter new modules with unnecessary p-containers, there will be > no way back. > > > > > > > > Or, alternatively, perhaps allow for a must statement to simulate a > mandatory keyword in these cases - although I don't think that this > solution is particularly clear or clean. > > > > Exactly, it is an ugly hack to the same effect. > > > > Lada > > > > > > > > Thanks, > > > Rob > > > > > > > > >> > > >> > > >> To me, in this scenario, it feels that you might as well forego both > the P-container and mandatory marking. > > >> > > >> Thanks, > > >> Rob > > >> > > >> > > >> > > >> > > >> Andy > > >> > > >> > > >>> > > >>> We already decided not to do anything useful wrt/ Y45, > > >>> so we are stuck with the YANG module as the unit of conformance. > > >>> > > >>> > > >>> Andy > > >>> > > >>> > > >>> > > >>> > > >>> On Thu, Aug 13, 2015 at 7:07 AM, Ladislav Lhotka > wrote: > > >>> Hi, > > >>> > > >>> although YANG 1.1 issue Y26 [1] is marked as DONE, I think the > adopted > > >>> solution Y26-02 is really horrible, so at least I want to make sure > the > > >>> WG is aware of the consequences. > > >>> > > >>> I am currently working on a data model for DNS zone data and the > schema > > >>> is like this: > > >>> > > >>> module: dns-zones > > >>> +--rw zones > > >>> +--rw zone* [name] > > >>> +--rw name inet:domain-name > > >>> +--rw description? string > > >>> +--rw class? ianadns:class > > >>> +--rw rrset* [owner type] > > >>> +--rw owner inet:domain-name > > >>> +--rw type identityref > > >>> +--rw description? string > > >>> +--rw ttl positive-int32 > > >>> +--rw rdata* [id] > > >>> +--rw id string > > >>> +--rw description? string > > >>> > > >>> The idea is that specific RDATA will be added for each RR type (wit= h > a > > >>> "when" condition based on "type"). Data for essential RR Types (SOA= , > NS, > > >>> A, AAAA, ...) can be defined in the same module but for some types > they > > >>> need to be defined in other modules and added via augmenting the > target > > >>> node "rdata". Typically, some (or all) of RDATA is mandatory, and > this > > >>> is where Y26 comes into play. The solution recommended by Y26-02 > would > > >>> look like this: > > >>> > > >>> augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" { > > >>> when "derived-from-or-self(../dnsz:type,'iana-dns-parameters'," > > >>> + "'TLSA')"; > > >>> container rdata { // <=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > >>> presence "TLSA data"; > > >>> leaf certificate-usage { > > >>> mandatory true; > > >>> ... > > >>> } > > >>> ... > > >>> } > > >>> } > > >>> > > >>> Note the superfluous presence container "rdata". It that just adds = a > > >>> useless level of hierarchy and still doesn't enforce the correct > > >>> constraints: the data model allows the presence container to be > missing > > >>> so that RDATA will be empty. Defining this extra container for all > ~75 > > >>> RR types is a nuisance and it certainly won't make the modules more > > >>> readable. > > >>> > > >>> As this situation is likely to be very common, I wonder: do we real= ly > > >>> want to do that? > > >>> > > >>> [1] > https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-27 > > >>> > > >>> Thanks, Lada > > >>> > > >>> -- > > >>> Ladislav Lhotka, CZ.NIC Labs > > >>> PGP Key ID: E74E8C0C > > >>> > > >>> _______________________________________________ > > >>> netmod mailing list > > >>> netmod@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/netmod > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> netmod mailing list > > >>> > > >>> netmod@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/netmod > > >> > > >> > > > > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > > > > > > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a11c33e18ecb2a0051d36fd0b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Aug 13, 2015 at 12:43 PM, Ladislav Lhotka <= ;lhotka@nic.cz> wrote:

> On 13 Aug 2015, at 21:31, Andy Bierman <andy@yumaworks.com> wrote:
>
> Hi,
>
> IMO this is issue is closed.
> I see no reason to re-open it.
> YANG does not allow augments to add mandatory nodes.

I strongly disagree with this attitude, this is a normal IETF procedure. Th= ings can be changed even during WGLC.

Virtual interims aren=E2=80=99t good for discussing non-trivial technical i= ssues.


I am not hearing any new arguments for= changing this rule for augments.
It's up to the co-chairs wh= ether they want to re-open this issue.

=C2=A0
Lada


Andy
=C2= =A0

>
>
> Andy
>
>
> On Thu, Aug 13, 2015 at 12:22 PM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> > On 13 Aug 2015, at 19:44, Robert Wilton <rwilton@cisco.com> wrote:
> >
> > Hi Andy,
> >
> > On 13/08/2015 17:08, Andy Bierman wrote:
> >>
> >>
> >> On Thu, Aug 13, 2015 at 8:39 AM, Robert Wilton <rwilton@cisco.com> wrote:
> >> Hi Andy, Lada,
> >>
> >> On 13/08/2015 15:46, Andy Bierman wrote:
> >>> Hi,
> >>>
> >>>
> >>> I'm not sure how many times we need to go over this i= ssue...
> >>>
> >>> YANG conformance is based on the YANG module.
> >>> YANG has no concept of conformance beyond this
> >>> simplistic approach,=C2=A0 You cannot assume (ever, under= any conditions)
> >>> that module foo AND bar will both be present on a server.=
> >>>
> >>> Therefore if a client is written to work with "foo&q= uot;, it has no
> >>> responsibility at all to know that "bar" adds a= mandatory
> >>> node to a "foo" subtree.
> >>>
> >>> The extra P-container is needed to make sure clients writ= ten
> >>> to work with module "foo" do not break when new= nodes are
> >>> added via augments.
> >>
> >> I still don't see how a P-container really solves the pro= blem since any child mandatory nodes aren't really mandatory, or at lea= st not in the way that is actually intended.
> >>
> >>
> >>
> >> The concepts behind old-manager/new-agent protection mechanis= ms go back
> >> a couple decades (with SNMP).=C2=A0 There is no way that a ve= ndor can control all
> >> the applications using a particular module, and therefore man= date a flag-day
> >> upgrade on all clients, in order to upgrade some servers.
> >>
> > Yes, I agree in principle, but I'm not sure whether the defau= lt set of YANG modules has yet reaches the maturity that enforcing this rul= e truly makes sense.=C2=A0 It feels that many of the YANG modules (even tho= se have been standardized) are still some what at the experimental stage.= =C2=A0 This is effectively the same point that you make below.
>
> Right. Another thing is that augment was IMO originally intended to al= low for adding optional or vendor-specific parameters to a base data model.= However,=C2=A0 as it turned out, it is in fact used as an essential tool f= or developing *base* data models in a modular fashion.
>
> I have also argued several times that a client cherry-picking modules = advertised by the server is fundamentally unsafe - it may work but may also= break things.
>
> >
> >>
> >> YANG is very limited wrt/ adding new functionality,
> >> A designer must guess correctly on all mandatory nodes
> >> on the first version.=C2=A0 If this a bug, then it should be = fixed
> >> properly, instead of just pretending it's OK to break
> >> existing client apps.
> >
> > In Lada's case there is no base version, all of his modules a= re being newly defined.=C2=A0 So, in this scenario, ideally that RR-type sp= ecific modules should be allowed to augment with mandatory nodes since this= must effectively be backwards compatible.
> >
> >
> >>
> >> (YANG packages do not fix this problem BTW)
> >>
> >> Perhaps we need a new module-level "release" statem= ent.
> >>
> >>=C2=A0 =C2=A0 release stable;
> >>=C2=A0 =C2=A0 release unstable;
> >>=C2=A0 =C2=A0 release experimental;
> >>
> >> Then all the very strict YANG change control rules can be rel= axed on
> >> unstable and experimental modules.
> >
> > Yes, this may make sense for other scenarios, but I don't see= that it helps with either of the problems that Lada or I have described. >
> It doesn=E2=80=99t, it is just hand-waving.
>
> >
> >>
> >>
> >>
> >> E.g. in Lada's example having the P-container implies tha= t for a given RR type it is acceptable to either not provide any extra RR s= pecific config (i.e. no P-container), or if RR specific config is provided = then some fields must always be provided, and others can be left out.=C2=A0= I.e. the P-container also needs to be mandatory for the configuration to b= e sane.
> >>
> >>
> >> A P-container insulates the old client because it would not k= now to
> >> create it, and the mandatory child nodes are only checked if<= br> > >> the P-container exists.
> > Yes, but in Lada's example, the P-container doesn't reall= y help anyone, since the server has to now handle the case that the RR-type= has been specified but the corresponding P-container isn't present.=C2= =A0 If it is possible for the server to handle this scenario then the=C2=A0= =C2=A0 =C2=A0mandatory child fields don't have to be mandatory either = because some sensible default must exist.=C2=A0 This implies that all serve= rs would likely reject the configuration as being invalid if the P-containe= r isn't also present.
> >
> > As I see it, having a P-container here only protects a old client= in the scenario that it was mis-configured in the first place, i.e. using = a particular RR-type without the corresponding mandatory nodes being specif= ied ... which a sane server should have rejected the config for previously.=
> >
> > I don't really want to flog a dead horse, but I do think that= the mandatory rule could be relaxed to state that it cannot be used to int= roduce non backwards compatible nodes.=C2=A0 The text could specify the spe= cific conditions where it is allowed to be used in a augmentation.
>
> We tried to identify such situations but it is not that easy. I think = the restriction should be removed and explain backward compatibility issues= in 6087bis. Module authors then have to decide whether a certain node need= s to be defined as mandatory.
>
> If we clutter new modules with unnecessary p-containers, there will be= no way back.
>
> >
> > Or, alternatively, perhaps allow for a must statement to simulate= a mandatory keyword in these cases - although I don't think that this = solution is particularly clear or clean.
>
> Exactly, it is an ugly hack to the same effect.
>
> Lada
>
> >
> > Thanks,
> > Rob
> >
> >
> >>
> >>
> >> To me, in this scenario, it feels that you might as well fore= go both the P-container and mandatory marking.
> >>
> >> Thanks,
> >> Rob
> >>
> >>
> >>
> >>
> >> Andy
> >>
> >>
> >>>
> >>> We already decided not to do anything useful wrt/ Y45, > >>> so we are stuck with the YANG module as the unit of confo= rmance.
> >>>
> >>>
> >>> Andy
> >>>
> >>>
> >>>
> >>>
> >>> On Thu, Aug 13, 2015 at 7:07 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> >>> Hi,
> >>>
> >>> although YANG 1.1 issue Y26 [1] is marked as DONE, I thin= k the adopted
> >>> solution Y26-02 is really horrible, so at least I want to= make sure the
> >>> WG is aware of the consequences.
> >>>
> >>> I am currently working on a data model for DNS zone data = and the schema
> >>> is like this:
> >>>
> >>> module: dns-zones
> >>>=C2=A0 =C2=A0 +--rw zones
> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw zone* [name]
> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw name=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0inet:domain-name
> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw description?=C2= =A0 =C2=A0string
> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw class?=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0ianadns:class
> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw rrset* [owner typ= e]
> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw owne= r=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 inet:domain-name
> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw type= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0identityref
> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw desc= ription?=C2=A0 =C2=A0string
> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw ttl= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 positive-int32
> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw rdat= a* [id]
> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +-= -rw id=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0string
> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +-= -rw description?=C2=A0 =C2=A0string
> >>>
> >>> The idea is that specific RDATA will be added for each RR= type (with a
> >>> "when" condition based on "type"). Da= ta for essential RR Types (SOA, NS,
> >>> A, AAAA, ...) can be defined in the same module but for s= ome types they
> >>> need to be defined in other modules and added via augment= ing the target
> >>> node "rdata". Typically, some (or all) of RDATA= is mandatory, and this
> >>> is where Y26 comes into play. The solution recommended by= Y26-02 would
> >>> look like this:
> >>>
> >>> augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata= " {
> >>>=C2=A0 =C2=A0 =C2=A0when "derived-from-or-self(../dns= z:type,'iana-dns-parameters',"
> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 + "'TLSA')";=
> >>>=C2=A0 =C2=A0 =C2=A0container rdata {=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 // <=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0presence "TLSA data= ";
> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf certificate-usage {=
> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory = true;
> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...
> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...
> >>>=C2=A0 =C2=A0 =C2=A0}
> >>> }
> >>>
> >>> Note the superfluous presence container "rdata"= . It that just adds a
> >>> useless level of hierarchy and still doesn't enforce = the correct
> >>> constraints: the data model allows the presence container= to be missing
> >>> so that RDATA will be empty. Defining this extra containe= r for all ~75
> >>> RR types is a nuisance and it certainly won't make th= e modules more
> >>> readable.
> >>>
> >>> As this situation is likely to be very common, I wonder: = do we really
> >>> want to do that?
> >>>
> >>> [1] https://sv= n.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-27
> >>>
> >>> Thanks, Lada
> >>>
> >>> --
> >>> Ladislav Lhotka, CZ.NIC Labs
> >>> PGP Key ID: E74E8C0C
> >>>
> >>> _______________________________________________
> >>> netmod mailing list
> >>> netmod@ietf.org > >>> https://www.ietf.org/mailman/listinfo/= netmod
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> netmod mailing list
> >>>
> >>> netmod@ietf.org > >>> https://www.ietf.org/mailman/listinfo/= netmod
> >>
> >>
> >
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>

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




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

--001a11c33e18ecb2a0051d36fd0b-- From nobody Thu Aug 13 13:15:46 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 331481B3AB5 for ; Thu, 13 Aug 2015 13:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.661 X-Spam-Level: X-Spam-Status: No, score=-7.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06C8K2_TV1Tq for ; Thu, 13 Aug 2015 13:15:43 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A9041B3AB7 for ; Thu, 13 Aug 2015 13:15:41 -0700 (PDT) Received: from [172.29.2.202] (nat-14.bravonet.cz [77.48.225.14]) by mail.nic.cz (Postfix) with ESMTPSA id D8B22181840; Thu, 13 Aug 2015 22:15:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1439496940; bh=8H1leniBUhZECj+hzEAz6NGfoSvftyfmdViFSYYedWg=; h=From:Date:To; b=b4ybxzocz1aMYoTycj11SiF5Lbh7XQg2vhM/QpU/wQltfbKybdzq+el1hzh8mJPBi +RNGkRQmXa5gSUN8r5j2+6APpQTnxNfgOqBKDF/WguymWc1SAeiapWMufZtjuNza4i Kar87SEm32KCiRky02XCKOny3TYi43xtTqt8AVtQ= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: Date: Thu, 13 Aug 2015 22:15:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <54F0CD5C-DD4C-47B6-8E8F-D47E9FB33E98@nic.cz> References: <1516231808.93378.1438887834598.JavaMail.nobody@jva2tc202.webex.com> <55C4D830.8030601@cisco.com> <95032778-8873-4B5A-8CE6-D74CD77AAD13@lucidvision.com> To: Andy Bierman X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod-chairs@tools.ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] WebEx meeting invitation: NETMOD Interm meeting on OpenConfig X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 20:15:45 -0000 > On 13 Aug 2015, at 22:03, Andy Bierman wrote: >=20 >=20 >=20 > On Thu, Aug 13, 2015 at 12:41 PM, Nadeau Thomas = wrote: >=20 >=20 >=20 >> On Aug 7, 2015:12:09 PM, at 12:09 PM, Benoit Claise = wrote: >>=20 >> Dear all, >>=20 >> During the YANG Model Coordination Group webex call today, we = discussed=20 >> this oper status and structure open issues. We're ready to help=20 >> facilitate the discussion between the different proposals >> We could compare the pros/cons of the different solutions from our = point=20 >> of view. >>=20 >> To allow us some preparation time, alternate proposals should be = posted=20 >> a week before the NETMOD interim meeting, i.e. Sept 3rd. >>=20 >> The YANG Model Coordination Group=20 >>=20 > Speaking as Co-chair: >=20 > Just to clarify a bit on this. The purpose of the next Interim = meeting is to close on the issues around the Open Config proposal. We = meant to do this in Praha, but we could not get the right people to = attend the meeting to have the right discussion. We need to close on = this issue as soon as possible, as this is possibly blocking a lot of = other WG-related work; therefore, if no alternative proposals are posted = to discuss ahead of the interim meeting, then the original proposal will = become the solution to move forward with in the WG. Alternatives must be = complete proposals, not bullet points of complaints or such things - = they must be a solution or they will not be allowed onto the agenda. As = Benoit declared above, these must be posted ahead of the meeting and = will be put on the agenda for the meeting to present/discuss/debate as = well as to give everyone ample time to read and understand the = document/s. >=20 >=20 >=20 > Are you proposing that all existing RFCs with YANG modules in them be > changed to "obsolete", and new modules published that move the data > under a container named "device" (from some TBD module)? If not, then > what is the proposal for data root placement for existing RFC modules? >=20 > Are you also proposing that all YANG modules with config in them must > define that config in a grouping, and all config must appear in a > container named "config"? Also, that all config data must be = replicated > (i.e., use that grouping) under a config false container named = ? > This will be done even though in 90% of all servers, it doesn't take = very > long for intended config to become the active config? If not, then = what > is the exact proposal for usage within IETF modules? >=20 > Everyone should understand the impact of these changes. > Silence should not mean "I read the openconfig proposals and > approve of these changes". Only emails to this list that state as = much > should mean that. +1 I may be old-fashioned but I would actually prefer to have the = discussion mainly in the mailing list. Lada >=20 >=20 >=20 > Thanks, >=20 > =E2=80=94Tom=20 >=20 >=20 >=20 >=20 > Andy > =20 >=20 >>> Hello, >>> NETMOD Working Group invites you to join this WebEx meeting. >>> =20 >>> NETMOD Interm meeting on OpenConfig >>> Thursday, September 10, 2015=20 >>> 11:00 am | Eastern Daylight Time (New York, GMT-04:00) | 1 hr=20 >>> =20 >>> Join WebEx meeting >>> Meeting number: 645 732 277=20 >>> Meeting password: 1234 >>> =20 >>> Join by phone >>> 1-877-668-4493 Call-in toll free number (US/Canada) >>> 1-650-479-3208 Call-in toll number (US/Canada) >>> Access code: 645 732 277 >>> Toll-free calling restrictions >>> =20 >>> Add this meeting to your calendar. >>> =20 >>> Can't join the meeting? Contact support. >>> =20 >>> IMPORTANT NOTICE: Please note that this WebEx service allows audio = and other information sent during the session to be recorded, which may = be discoverable in a legal matter. By joining this session, you = automatically consent to such recordings. If you do not consent to being = recorded, discuss your concerns with the host or do not join the = session. >>>=20 >>>=20 >>> _______________________________________________ >>> netmod mailing list >>>=20 >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Aug 13 13:24:10 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D8491B3AC3 for ; Thu, 13 Aug 2015 13:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.412 X-Spam-Level: X-Spam-Status: No, score=-1.412 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_75=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHF8nqS1QVol for ; Thu, 13 Aug 2015 13:24:06 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85F801B3AC2 for ; Thu, 13 Aug 2015 13:24:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1439497392; bh=Ba02Nt9ai8zVKAKc7pEL8TQkdJhm9pMYMnFw+tJQsyY=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=f0P8nVLV2UP+0G6BHh20SWd8R26yk9e9ebjbALfwwNGed7kg8tCEUizN85YfMYwd1 aHi6TGw3Es1VlsyQ8AvKkO/yqN/YgujzrJ3iuO4jj14bMF2jVBY69h9PdGmtTETneu Gj1kkVkXwAgUCcSJaSWlcS2rlYKdnhiyVDFMhBvM= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Nadeau Thomas In-Reply-To: Date: Thu, 13 Aug 2015 16:24:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55CCBA4F.9010101@cisco.com> <55CCD770.2030701@cisco.com> <586BF923-E9EA-4248-A838-55D3709A31BE@nic.cz> To: Ladislav Lhotka X-Mailer: Apple Mail (2.2102) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-ShareWhite: 50.255.148.181 X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=11 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181 X-IP-stats: Notspam Incoming Last 0, First 90, in=676, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Y26 again, sorry X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 20:24:08 -0000 Speaking as co-chair: Hold on a minute. As a point of order, our process with the = Yang 1.1 issue processing has been very clear: we debate/discuss the = issues on the interim calls in order, then propose the outcome that the = design team came up with to the list each time. There is a =E2=80=9Clast = call=E2=80=9D period when debate/discussion with the NETMOD WG can take = place after which the issue is closed and will=20 not be debated again. Looking at this issue, it was discussed/debated and is now = closed as of 2015-04-17. http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-27 Let us please stop debating this issue as it is closed. =E2=80=94Tom > On Aug 13, 2015:3:43 PM, at 3:43 PM, Ladislav Lhotka = wrote: >=20 >=20 >> On 13 Aug 2015, at 21:31, Andy Bierman wrote: >>=20 >> Hi, >>=20 >> IMO this is issue is closed. >> I see no reason to re-open it. >> YANG does not allow augments to add mandatory nodes. >=20 > I strongly disagree with this attitude, this is a normal IETF = procedure. Things can be changed even during WGLC. >=20 > Virtual interims aren=E2=80=99t good for discussing non-trivial = technical issues. >=20 > Lada=20 >=20 >>=20 >>=20 >> Andy >>=20 >>=20 >> On Thu, Aug 13, 2015 at 12:22 PM, Ladislav Lhotka = wrote: >>=20 >>> On 13 Aug 2015, at 19:44, Robert Wilton wrote: >>>=20 >>> Hi Andy, >>>=20 >>> On 13/08/2015 17:08, Andy Bierman wrote: >>>>=20 >>>>=20 >>>> On Thu, Aug 13, 2015 at 8:39 AM, Robert Wilton = wrote: >>>> Hi Andy, Lada, >>>>=20 >>>> On 13/08/2015 15:46, Andy Bierman wrote: >>>>> Hi, >>>>>=20 >>>>>=20 >>>>> I'm not sure how many times we need to go over this issue... >>>>>=20 >>>>> YANG conformance is based on the YANG module. >>>>> YANG has no concept of conformance beyond this >>>>> simplistic approach, You cannot assume (ever, under any = conditions) >>>>> that module foo AND bar will both be present on a server. >>>>>=20 >>>>> Therefore if a client is written to work with "foo", it has no >>>>> responsibility at all to know that "bar" adds a mandatory >>>>> node to a "foo" subtree. >>>>>=20 >>>>> The extra P-container is needed to make sure clients written >>>>> to work with module "foo" do not break when new nodes are >>>>> added via augments. >>>>=20 >>>> I still don't see how a P-container really solves the problem since = any child mandatory nodes aren't really mandatory, or at least not in = the way that is actually intended. >>>>=20 >>>>=20 >>>>=20 >>>> The concepts behind old-manager/new-agent protection mechanisms go = back >>>> a couple decades (with SNMP). There is no way that a vendor can = control all >>>> the applications using a particular module, and therefore mandate a = flag-day >>>> upgrade on all clients, in order to upgrade some servers. >>>>=20 >>> Yes, I agree in principle, but I'm not sure whether the default set = of YANG modules has yet reaches the maturity that enforcing this rule = truly makes sense. It feels that many of the YANG modules (even those = have been standardized) are still some what at the experimental stage. = This is effectively the same point that you make below. >>=20 >> Right. Another thing is that augment was IMO originally intended to = allow for adding optional or vendor-specific parameters to a base data = model. However, as it turned out, it is in fact used as an essential = tool for developing *base* data models in a modular fashion. >>=20 >> I have also argued several times that a client cherry-picking modules = advertised by the server is fundamentally unsafe - it may work but may = also break things. >>=20 >>>=20 >>>>=20 >>>> YANG is very limited wrt/ adding new functionality, >>>> A designer must guess correctly on all mandatory nodes >>>> on the first version. If this a bug, then it should be fixed >>>> properly, instead of just pretending it's OK to break >>>> existing client apps. >>>=20 >>> In Lada's case there is no base version, all of his modules are = being newly defined. So, in this scenario, ideally that RR-type = specific modules should be allowed to augment with mandatory nodes since = this must effectively be backwards compatible. >>>=20 >>>=20 >>>>=20 >>>> (YANG packages do not fix this problem BTW) >>>>=20 >>>> Perhaps we need a new module-level "release" statement. >>>>=20 >>>> release stable; >>>> release unstable; >>>> release experimental; >>>>=20 >>>> Then all the very strict YANG change control rules can be relaxed = on >>>> unstable and experimental modules. >>>=20 >>> Yes, this may make sense for other scenarios, but I don't see that = it helps with either of the problems that Lada or I have described. >>=20 >> It doesn=E2=80=99t, it is just hand-waving. >>=20 >>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> E.g. in Lada's example having the P-container implies that for a = given RR type it is acceptable to either not provide any extra RR = specific config (i.e. no P-container), or if RR specific config is = provided then some fields must always be provided, and others can be = left out. I.e. the P-container also needs to be mandatory for the = configuration to be sane. >>>>=20 >>>>=20 >>>> A P-container insulates the old client because it would not know to >>>> create it, and the mandatory child nodes are only checked if >>>> the P-container exists. >>> Yes, but in Lada's example, the P-container doesn't really help = anyone, since the server has to now handle the case that the RR-type has = been specified but the corresponding P-container isn't present. If it = is possible for the server to handle this scenario then the = mandatory child fields don't have to be mandatory either because some = sensible default must exist. This implies that all servers would likely = reject the configuration as being invalid if the P-container isn't also = present. >>>=20 >>> As I see it, having a P-container here only protects a old client in = the scenario that it was mis-configured in the first place, i.e. using a = particular RR-type without the corresponding mandatory nodes being = specified ... which a sane server should have rejected the config for = previously. >>>=20 >>> I don't really want to flog a dead horse, but I do think that the = mandatory rule could be relaxed to state that it cannot be used to = introduce non backwards compatible nodes. The text could specify the = specific conditions where it is allowed to be used in a augmentation. >>=20 >> We tried to identify such situations but it is not that easy. I think = the restriction should be removed and explain backward compatibility = issues in 6087bis. Module authors then have to decide whether a certain = node needs to be defined as mandatory. >>=20 >> If we clutter new modules with unnecessary p-containers, there will = be no way back. >>=20 >>>=20 >>> Or, alternatively, perhaps allow for a must statement to simulate a = mandatory keyword in these cases - although I don't think that this = solution is particularly clear or clean. >>=20 >> Exactly, it is an ugly hack to the same effect. >>=20 >> Lada >>=20 >>>=20 >>> Thanks, >>> Rob >>>=20 >>>=20 >>>>=20 >>>>=20 >>>> To me, in this scenario, it feels that you might as well forego = both the P-container and mandatory marking. >>>>=20 >>>> Thanks, >>>> Rob >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Andy >>>>=20 >>>>=20 >>>>>=20 >>>>> We already decided not to do anything useful wrt/ Y45, >>>>> so we are stuck with the YANG module as the unit of conformance. >>>>>=20 >>>>>=20 >>>>> Andy >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Thu, Aug 13, 2015 at 7:07 AM, Ladislav Lhotka = wrote: >>>>> Hi, >>>>>=20 >>>>> although YANG 1.1 issue Y26 [1] is marked as DONE, I think the = adopted >>>>> solution Y26-02 is really horrible, so at least I want to make = sure the >>>>> WG is aware of the consequences. >>>>>=20 >>>>> I am currently working on a data model for DNS zone data and the = schema >>>>> is like this: >>>>>=20 >>>>> module: dns-zones >>>>> +--rw zones >>>>> +--rw zone* [name] >>>>> +--rw name inet:domain-name >>>>> +--rw description? string >>>>> +--rw class? ianadns:class >>>>> +--rw rrset* [owner type] >>>>> +--rw owner inet:domain-name >>>>> +--rw type identityref >>>>> +--rw description? string >>>>> +--rw ttl positive-int32 >>>>> +--rw rdata* [id] >>>>> +--rw id string >>>>> +--rw description? string >>>>>=20 >>>>> The idea is that specific RDATA will be added for each RR type = (with a >>>>> "when" condition based on "type"). Data for essential RR Types = (SOA, NS, >>>>> A, AAAA, ...) can be defined in the same module but for some types = they >>>>> need to be defined in other modules and added via augmenting the = target >>>>> node "rdata". Typically, some (or all) of RDATA is mandatory, and = this >>>>> is where Y26 comes into play. The solution recommended by Y26-02 = would >>>>> look like this: >>>>>=20 >>>>> augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" { >>>>> when "derived-from-or-self(../dnsz:type,'iana-dns-parameters'," >>>>> + "'TLSA')"; >>>>> container rdata { // <=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >>>>> presence "TLSA data"; >>>>> leaf certificate-usage { >>>>> mandatory true; >>>>> ... >>>>> } >>>>> ... >>>>> } >>>>> } >>>>>=20 >>>>> Note the superfluous presence container "rdata". It that just adds = a >>>>> useless level of hierarchy and still doesn't enforce the correct >>>>> constraints: the data model allows the presence container to be = missing >>>>> so that RDATA will be empty. Defining this extra container for all = ~75 >>>>> RR types is a nuisance and it certainly won't make the modules = more >>>>> readable. >>>>>=20 >>>>> As this situation is likely to be very common, I wonder: do we = really >>>>> want to do that? >>>>>=20 >>>>> [1] = https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-27 >>>>>=20 >>>>> Thanks, Lada >>>>>=20 >>>>> -- >>>>> Ladislav Lhotka, CZ.NIC Labs >>>>> PGP Key ID: E74E8C0C >>>>>=20 >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> netmod mailing list >>>>>=20 >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>=20 >>>>=20 >>>=20 >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 >>=20 >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Aug 13 13:25:19 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98D1A1B3AC5 for ; Thu, 13 Aug 2015 13:25:18 -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_75=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 r1JGn0dvcLW2 for ; Thu, 13 Aug 2015 13:25:16 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F9731B3AC2 for ; Thu, 13 Aug 2015 13:25:16 -0700 (PDT) Received: from [172.29.2.202] (nat-14.bravonet.cz [77.48.225.14]) by mail.nic.cz (Postfix) with ESMTPSA id C34D21813C7; Thu, 13 Aug 2015 22:25:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1439497514; bh=H7zMob3k+ixlwIbLK/j4sQfmCtQM0BGiqCZFUPFX9c4=; h=From:Date:To; b=RxD6qrrY73Vg2y8S9sKmDcxQUovLCC4PSBvFY/yVLAJI2jbu0AiqmiJXPZceX4d+e NEk7mryvadFzogAo/M/pXuwH9P0BHht9it4WHbWjqleGVROpBoBlZnPdeq2s5VBRGJ jFQUVD0y/MY55ZYdDboXNRT9yaQVPdLIvyh7rRF4= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: Date: Thu, 13 Aug 2015 22:25:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <092B48A1-3134-4A32-A548-4C47E9274861@nic.cz> References: <55CCBA4F.9010101@cisco.com> <55CCD770.2030701@cisco.com> <586BF923-E9EA-4248-A838-55D3709A31BE@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Y26 again, sorry X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 20:25:18 -0000 > On 13 Aug 2015, at 22:15, Andy Bierman wrote: >=20 >=20 >=20 > On Thu, Aug 13, 2015 at 12:43 PM, Ladislav Lhotka = wrote: >=20 > > On 13 Aug 2015, at 21:31, Andy Bierman wrote: > > > > Hi, > > > > IMO this is issue is closed. > > I see no reason to re-open it. > > YANG does not allow augments to add mandatory nodes. >=20 > I strongly disagree with this attitude, this is a normal IETF = procedure. Things can be changed even during WGLC. >=20 > Virtual interims aren=E2=80=99t good for discussing non-trivial = technical issues. >=20 >=20 > I am not hearing any new arguments for changing this rule for = augments. The argument isn=E2=80=99t new, I just hope to find more support for it. = And the argument is: With the way how augments are used in existing = modules, it is not reasonable to used restricted YANG inside them. And = the p-container solves nothing. Lada > It's up to the co-chairs whether they want to re-open this issue. >=20 > =20 > Lada >=20 >=20 > Andy > =20 >=20 > > > > > > Andy > > > > > > On Thu, Aug 13, 2015 at 12:22 PM, Ladislav Lhotka = wrote: > > > > > On 13 Aug 2015, at 19:44, Robert Wilton wrote: > > > > > > Hi Andy, > > > > > > On 13/08/2015 17:08, Andy Bierman wrote: > > >> > > >> > > >> On Thu, Aug 13, 2015 at 8:39 AM, Robert Wilton = wrote: > > >> Hi Andy, Lada, > > >> > > >> On 13/08/2015 15:46, Andy Bierman wrote: > > >>> Hi, > > >>> > > >>> > > >>> I'm not sure how many times we need to go over this issue... > > >>> > > >>> YANG conformance is based on the YANG module. > > >>> YANG has no concept of conformance beyond this > > >>> simplistic approach, You cannot assume (ever, under any = conditions) > > >>> that module foo AND bar will both be present on a server. > > >>> > > >>> Therefore if a client is written to work with "foo", it has no > > >>> responsibility at all to know that "bar" adds a mandatory > > >>> node to a "foo" subtree. > > >>> > > >>> The extra P-container is needed to make sure clients written > > >>> to work with module "foo" do not break when new nodes are > > >>> added via augments. > > >> > > >> I still don't see how a P-container really solves the problem = since any child mandatory nodes aren't really mandatory, or at least not = in the way that is actually intended. > > >> > > >> > > >> > > >> The concepts behind old-manager/new-agent protection mechanisms = go back > > >> a couple decades (with SNMP). There is no way that a vendor can = control all > > >> the applications using a particular module, and therefore mandate = a flag-day > > >> upgrade on all clients, in order to upgrade some servers. > > >> > > > Yes, I agree in principle, but I'm not sure whether the default = set of YANG modules has yet reaches the maturity that enforcing this = rule truly makes sense. It feels that many of the YANG modules (even = those have been standardized) are still some what at the experimental = stage. This is effectively the same point that you make below. > > > > Right. Another thing is that augment was IMO originally intended to = allow for adding optional or vendor-specific parameters to a base data = model. However, as it turned out, it is in fact used as an essential = tool for developing *base* data models in a modular fashion. > > > > I have also argued several times that a client cherry-picking = modules advertised by the server is fundamentally unsafe - it may work = but may also break things. > > > > > > > >> > > >> YANG is very limited wrt/ adding new functionality, > > >> A designer must guess correctly on all mandatory nodes > > >> on the first version. If this a bug, then it should be fixed > > >> properly, instead of just pretending it's OK to break > > >> existing client apps. > > > > > > In Lada's case there is no base version, all of his modules are = being newly defined. So, in this scenario, ideally that RR-type = specific modules should be allowed to augment with mandatory nodes since = this must effectively be backwards compatible. > > > > > > > > >> > > >> (YANG packages do not fix this problem BTW) > > >> > > >> Perhaps we need a new module-level "release" statement. > > >> > > >> release stable; > > >> release unstable; > > >> release experimental; > > >> > > >> Then all the very strict YANG change control rules can be relaxed = on > > >> unstable and experimental modules. > > > > > > Yes, this may make sense for other scenarios, but I don't see that = it helps with either of the problems that Lada or I have described. > > > > It doesn=E2=80=99t, it is just hand-waving. > > > > > > > >> > > >> > > >> > > >> E.g. in Lada's example having the P-container implies that for a = given RR type it is acceptable to either not provide any extra RR = specific config (i.e. no P-container), or if RR specific config is = provided then some fields must always be provided, and others can be = left out. I.e. the P-container also needs to be mandatory for the = configuration to be sane. > > >> > > >> > > >> A P-container insulates the old client because it would not know = to > > >> create it, and the mandatory child nodes are only checked if > > >> the P-container exists. > > > Yes, but in Lada's example, the P-container doesn't really help = anyone, since the server has to now handle the case that the RR-type has = been specified but the corresponding P-container isn't present. If it = is possible for the server to handle this scenario then the = mandatory child fields don't have to be mandatory either because some = sensible default must exist. This implies that all servers would likely = reject the configuration as being invalid if the P-container isn't also = present. > > > > > > As I see it, having a P-container here only protects a old client = in the scenario that it was mis-configured in the first place, i.e. = using a particular RR-type without the corresponding mandatory nodes = being specified ... which a sane server should have rejected the config = for previously. > > > > > > I don't really want to flog a dead horse, but I do think that the = mandatory rule could be relaxed to state that it cannot be used to = introduce non backwards compatible nodes. The text could specify the = specific conditions where it is allowed to be used in a augmentation. > > > > We tried to identify such situations but it is not that easy. I = think the restriction should be removed and explain backward = compatibility issues in 6087bis. Module authors then have to decide = whether a certain node needs to be defined as mandatory. > > > > If we clutter new modules with unnecessary p-containers, there will = be no way back. > > > > > > > > Or, alternatively, perhaps allow for a must statement to simulate = a mandatory keyword in these cases - although I don't think that this = solution is particularly clear or clean. > > > > Exactly, it is an ugly hack to the same effect. > > > > Lada > > > > > > > > Thanks, > > > Rob > > > > > > > > >> > > >> > > >> To me, in this scenario, it feels that you might as well forego = both the P-container and mandatory marking. > > >> > > >> Thanks, > > >> Rob > > >> > > >> > > >> > > >> > > >> Andy > > >> > > >> > > >>> > > >>> We already decided not to do anything useful wrt/ Y45, > > >>> so we are stuck with the YANG module as the unit of conformance. > > >>> > > >>> > > >>> Andy > > >>> > > >>> > > >>> > > >>> > > >>> On Thu, Aug 13, 2015 at 7:07 AM, Ladislav Lhotka = wrote: > > >>> Hi, > > >>> > > >>> although YANG 1.1 issue Y26 [1] is marked as DONE, I think the = adopted > > >>> solution Y26-02 is really horrible, so at least I want to make = sure the > > >>> WG is aware of the consequences. > > >>> > > >>> I am currently working on a data model for DNS zone data and the = schema > > >>> is like this: > > >>> > > >>> module: dns-zones > > >>> +--rw zones > > >>> +--rw zone* [name] > > >>> +--rw name inet:domain-name > > >>> +--rw description? string > > >>> +--rw class? ianadns:class > > >>> +--rw rrset* [owner type] > > >>> +--rw owner inet:domain-name > > >>> +--rw type identityref > > >>> +--rw description? string > > >>> +--rw ttl positive-int32 > > >>> +--rw rdata* [id] > > >>> +--rw id string > > >>> +--rw description? string > > >>> > > >>> The idea is that specific RDATA will be added for each RR type = (with a > > >>> "when" condition based on "type"). Data for essential RR Types = (SOA, NS, > > >>> A, AAAA, ...) can be defined in the same module but for some = types they > > >>> need to be defined in other modules and added via augmenting the = target > > >>> node "rdata". Typically, some (or all) of RDATA is mandatory, = and this > > >>> is where Y26 comes into play. The solution recommended by Y26-02 = would > > >>> look like this: > > >>> > > >>> augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" { > > >>> when = "derived-from-or-self(../dnsz:type,'iana-dns-parameters'," > > >>> + "'TLSA')"; > > >>> container rdata { // <=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > >>> presence "TLSA data"; > > >>> leaf certificate-usage { > > >>> mandatory true; > > >>> ... > > >>> } > > >>> ... > > >>> } > > >>> } > > >>> > > >>> Note the superfluous presence container "rdata". It that just = adds a > > >>> useless level of hierarchy and still doesn't enforce the correct > > >>> constraints: the data model allows the presence container to be = missing > > >>> so that RDATA will be empty. Defining this extra container for = all ~75 > > >>> RR types is a nuisance and it certainly won't make the modules = more > > >>> readable. > > >>> > > >>> As this situation is likely to be very common, I wonder: do we = really > > >>> want to do that? > > >>> > > >>> [1] = https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-27 > > >>> > > >>> Thanks, Lada > > >>> > > >>> -- > > >>> Ladislav Lhotka, CZ.NIC Labs > > >>> PGP Key ID: E74E8C0C > > >>> > > >>> _______________________________________________ > > >>> netmod mailing list > > >>> netmod@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/netmod > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> netmod mailing list > > >>> > > >>> netmod@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/netmod > > >> > > >> > > > > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > > > > > > > >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Aug 13 13:32:49 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB211B3ACD for ; Thu, 13 Aug 2015 13:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, 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 2BNc7Si1CDk9 for ; Thu, 13 Aug 2015 13:32:45 -0700 (PDT) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D4231B3ACB for ; Thu, 13 Aug 2015 13:32:44 -0700 (PDT) Received: by lalv9 with SMTP id v9so32740405lal.0 for ; Thu, 13 Aug 2015 13:32: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:cc:content-type; bh=FcxFjc9eWIsnV0W8qy7WZXnrOcwvdBCEen62hTXE4fE=; b=dnctxhqMs66dBG9KzKImmxenerqlwiweXaPz4JiBat+C6Ek6/IPEoHRcYrAZXJxEtd hsyELCOZr4L8h1V9B3bNLmBQ19S5xwSJ7A2IETGwVTQTlY6bnJuH9nqPW6i4olWIikQB P31/fu2aAhEe9ZbwRUk0vYIgkjKYCser8VcBNqwA7HruwDNm+r8lYZUaVw/osMEwv7JL FIVZUQVbDDrP2HafE9bHIHduBse0ac+ZDte31UNUxzf4rX8xg3GliR+POOgHc4cgePDM LgwbsK3pUwqPl3w/JeHmVvbrIkzjJKVS1/iEIcjsy8Wm3CsyFRINnb3rz4E4OiZE9Rxn gG9Q== X-Gm-Message-State: ALoCoQnWIzv1XC4Fe61f6s7CtpZ08LEXuwyJNE8cA98YB7hPGQGXQT8ZH2VzuZLxhMRBHc+6zQGg MIME-Version: 1.0 X-Received: by 10.112.46.130 with SMTP id v2mr38383888lbm.119.1439497962805; Thu, 13 Aug 2015 13:32:42 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Thu, 13 Aug 2015 13:32:42 -0700 (PDT) In-Reply-To: <958632F2-A758-4EC0-8D92-0B6C88DE187A@lucidvision.com> References: <1516231808.93378.1438887834598.JavaMail.nobody@jva2tc202.webex.com> <55C4D830.8030601@cisco.com> <95032778-8873-4B5A-8CE6-D74CD77AAD13@lucidvision.com> <958632F2-A758-4EC0-8D92-0B6C88DE187A@lucidvision.com> Date: Thu, 13 Aug 2015 13:32:42 -0700 Message-ID: From: Andy Bierman To: Nadeau Thomas Content-Type: multipart/alternative; boundary=001a1134aee8ba7513051d373c15 Archived-At: Cc: "netmod-chairs@tools.ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] WebEx meeting invitation: NETMOD Interm meeting on OpenConfig X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 20:32:48 -0000 --001a1134aee8ba7513051d373c15 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Aug 13, 2015 at 1:14 PM, Nadeau Thomas wrote: > > On Aug 13, 2015:4:03 PM, at 4:03 PM, Andy Bierman > wrote: > > > > On Thu, Aug 13, 2015 at 12:41 PM, Nadeau Thomas > wrote: > >> >> >> >> On Aug 7, 2015:12:09 PM, at 12:09 PM, Benoit Claise >> wrote: >> >> Dear all, >> >> During the YANG Model Coordination Group webex call today, we discussed >> this oper status and structure open issues. We're ready to help >> facilitate the discussion between the different proposals >> We could compare the pros/cons of the different solutions from our point >> of view. >> >> To allow us some preparation time, alternate proposals should be posted >> a week before the NETMOD interim meeting, i.e. Sept 3rd. >> >> The YANG Model Coordination Group >> >> Speaking as Co-chair: >> >> Just to clarify a bit on this. The purpose of the next Interim meeting i= s >> to close on the issues around the Open Config proposal. We meant to do t= his >> in Praha, but we could not get the right people to attend the meeting to >> have the right discussion. We need to close on this issue as soon as >> possible, as this is possibly blocking a lot of other WG-related work; >> therefore, if no alternative proposals are posted to discuss ahead of th= e >> interim meeting, then the original proposal will become the solution to >> move forward with in the WG. Alternatives must be complete proposals, no= t >> bullet points of complaints or such things - they must be a solution or >> they will not be allowed onto the agenda. As Benoit declared above, the= se >> must be posted ahead of the meeting and will be put on the agenda for th= e >> meeting to present/discuss/debate as well as to give everyone ample time= to >> read and understand the document/s. >> >> > > Are you proposing that all existing RFCs with YANG modules in them be > changed to "obsolete", and new modules published that move the data > under a container named "device" (from some TBD module)? If not, then > what is the proposal for data root placement for existing RFC modules? > > Are you also proposing that all YANG modules with config in them must > define that config in a grouping, and all config must appear in a > container named "config"? Also, that all config data must be replicated > (i.e., use that grouping) under a config false container named ? > This will be done even though in 90% of all servers, it doesn't take very > long for intended config to become the active config? If not, then what > is the exact proposal for usage within IETF modules? > > Everyone should understand the impact of these changes. > Silence should not mean "I read the openconfig proposals and > approve of these changes". Only emails to this list that state as much > should mean that. > > > Andy, > > Yes, people should read and understand the proposal. If they don=E2=80=99= t like it > please come up with a > viable alternative. If the alternative is to do nothing, then propose tha= t > and we will see what the consensus > is. If the proposal is to constructively alter parts of their proposal, > thats great too. After we get consensus on > the general approach, I will manage things issue-by-issue as we are doing > with other major initiatives in > NETMOD. What we will not do is continue to go round and round about > points of their proposal without > coming to any conclusions. We=E2=80=99ve had several interim meetings whe= re they > have taken the time to > discuss and educate everyone that is interested in how their approach > works and why. To-date, there > are no alternatives being proposed resulting from those discussions - jus= t > more debate/discussion. > What the management is declaring is that the time has come to move forwar= d > on this, one way or > another. > It seems somewhat irregular to declare that silence means agreement to an individual submission (no WG charter, no WG draft). There has not been a debate. There have been proposals, and some people not even agreeing with the the problems. There has been no response why: (1) YANG config=3Dtrue|false is not good enough to filter, and why extra NP containers called and are even needed (2) YANG constraints written for config=3Dtrue are not intended to be applied to config=3Dfalse, yet that is exactly what is proposed with the replicated config under a container (3) Why a new operation called cannot be used to retrieve the actual value in use for /foo There is no guessing required to map 1 path to another. There is no additional cost for the 90% of devices that do not take a long time to apply intended config I agree with Lada that consensus should be gauged by mailing list statements (count the number of non-authors that approve or oppose). This discussion should take place on the mailing list, not another virtual interim that is outside normal business hours for most of us. > =E2=80=94Tom > Andy > > > > > > > Thanks, >> >> =E2=80=94Tom >> >> >> > > Andy > > >> >> Hello,NETMOD Working Group invites you to join this WebEx meeting. *NETM= OD >> Interm meeting on OpenConfig*Thursday, September 10, 2015 11:00 >> am | Eastern Daylight Time (New York, GMT-04:00) | 1 hr *Join WebEx >> meeting* >> Meeting >> number:645 732 277 Meeting password:1234 *Join by phone**1-877-668-4493*= Call-in >> toll free number (US/Canada)*1-650-479-3208* Call-in toll number >> (US/Canada)Access code: 645 732 277Toll-free calling restrictions >> Add this meeting >> >> to your calendar. Can't join the meeting? Contact support. >> IMPORTANT NOTICE: Please note that this >> WebEx service allows audio and other information sent during the session= to >> be recorded, which may be discoverable in a legal matter. By joining thi= s >> session, you automatically consent to such recordings. If you do not >> consent to being recorded, discuss your concerns with the host or do not >> join the session. >> >> _______________________________________________ >> netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/= netmod >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> >> > > --001a1134aee8ba7513051d373c15 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Aug 13, 2015 at 1:14 PM, Nadeau Thomas <tnadeau@lucidvis= ion.com> wrote:

On Aug 13= , 2015:4:03 PM, at 4:03 PM, Andy Bierman <andy@yumaworks.com> wrote:

<= div dir=3D"ltr">

On Thu, Aug 13, 2015 at 12:41 PM, Nadeau Thomas <tnadeau@lucidvis= ion.com> wrote:
Just to clarify a = bit on this. The purpose of the next Interim meeting is to close on the iss= ues around the Open Config proposal. We meant to do this in Praha, but we c= ould not get the right people to attend the meeting to have the right discu= ssion. We need to close on this issue as soon as possible, as this is possi= bly blocking a lot of other WG-related work; therefore, if no alternative p= roposals are posted to discuss ahead of the interim meeting, then the origi= nal proposal will become the solution to move forward with in the WG. Alter= natives must be complete proposals, not bullet points of complaints or such= things - they must be a solution or they will not be allowed onto the agen= da.=C2=A0 As Benoit declared above, these must be posted ahead of the meeti= ng and will be put on the agenda for the meeting to present/discuss/debate = as well as to give everyone ample time to read and understand the document/= s.



Are you proposing that all existing RFCs with YANG modules in them = be
changed to "obsolete", and new modules published tha= t move the data
under a container named "device" (from = some TBD module)?=C2=A0 If not, then
what is the proposal for dat= a root placement for existing RFC modules?

Are you= also proposing that all YANG modules with config in them must
de= fine that config in a grouping, and all config must appear in a
c= ontainer named "config"? Also, that all config data must be repli= cated
(i.e., use that grouping) under a config false container na= med <state>?
This will be done even though in 90% of all se= rvers, it doesn't take very
long for intended config to becom= e the active config?=C2=A0 If not, then what
is the exact proposa= l for usage within IETF modules?

Everyone should u= nderstand the impact of these changes.
Silence should not mean &q= uot;I read the openconfig proposals and
approve of these changes&= quot;.=C2=A0 Only emails to this list that state as much
should m= ean that.







=C2=A0 =C2=A0 =C2=A0 =C2=A0retrieve the actual value in use for /foo
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0There is no guessing required to map 1 path= to another.
=C2=A0 =C2=A0 =C2=A0 =C2=A0There is no additional co= st for the 90% of devices that
=C2=A0 =C2=A0 =C2=A0 =C2=A0do not = take a long time to apply intended config
=C2=A0
I agre= e with Lada that consensus should be gauged by mailing list
state= ments (count the number of non-authors that approve or oppose).
T= his discussion should take place on the mailing list, not another virtual
interim that is outside normal business hours for most of us.





=E2=80=94Tom


Andy
=C2=A0
=




=


Thanks,

=E2=80=94Tom=C2=A0




Andy
=C2= =A0

Hello,
NETMOD Working Gr= oup invites you to join this WebEx meeting.
=C2=A0
NE= TMOD Interm meeting on OpenConfig
Thursday, Septe= mber 10, 2015=C2=A0
11:00 am=C2=A0=C2=A0= |=C2=A0=C2=A0Eastern Daylight Time (New York, GMT-04:00)=C2=A0=C2=A0|=C2=A0= =C2=A01 hr=C2=A0
Join WebEx meeting
<= table style=3D"border-collapse:separate;border:0px white;border-spacing:0px= ;width:auto!important;max-width:525px!important;min-width:279px!important">=
Meeting number:645 732 277=C2=A0
1234<= /td>
=C2=A0
Join by phone
1-877-668-449= 3=C2=A0Call-in toll free number (US/Canada)
1-= 650-479-3208=C2=A0Call-in toll number (US/Canada)
Access code:=C2=A0645 732 277
Toll-free calling restrictions
<= tr style=3D"line-height:20px">
=C2=A0
Add this meeting=C2=A0to y= our calendar.
=C2=A0
Can't join the meeting?=C2=A0<= a href=3D"https://ietf.webex.com/ietf/mc" style=3D"font-size:13px;font-fami= ly:Arial;color:rgb(0,175,249);padding:0px;text-decoration:none" target=3D"_= blank">Contact support.
= =C2=A0
IMPORTANT NOTICE: Please note tha= t this WebEx service allows audio and other information sent during the ses= sion to be recorded, which may be discoverable in a legal matter. By joinin= g this session, you automatically consent to such recordings. If you do not= consent to being recorded, discuss your concerns with the host or do not j= oin the session.


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

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


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




--001a1134aee8ba7513051d373c15-- From nobody Thu Aug 13 13:44:08 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C663C1B3AE5 for ; Thu, 13 Aug 2015 13:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7k6L4lEjP27o for ; Thu, 13 Aug 2015 13:44:04 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D1181B3ADE for ; Thu, 13 Aug 2015 13:44:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1439498590; bh=QN6v0is0MatfIICRWoM46ibsdgXjnAkZI5pQEVSr80w=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=SuD02V0RQSVkAqtSZTucQJPvyCuQZthTeDg/H8os8JfZm7H1m1LN5npuLhWQsxBi/ 2iWNDYYkArVFY9UWe2MVLNicQsbIE7F5r1r+/jeCY0dXYYQoOSDA9P97gFl/q3Kf7v 86KD+LiiCDcvhpNXinHyIyuI382bOjnHqtEyMFdU= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; Content-Type: multipart/alternative; boundary="Apple-Mail=_15AFAF01-4C68-4306-B8A5-48FCA52EAED6" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Nadeau Thomas In-Reply-To: Date: Thu, 13 Aug 2015 16:44:00 -0400 Message-Id: <407ACE9C-C636-496E-B19B-2EF11ED0C34A@lucidvision.com> References: <1516231808.93378.1438887834598.JavaMail.nobody@jva2tc202.webex.com> <55C4D830.8030601@cisco.com> <95032778-8873-4B5A-8CE6-D74CD77AAD13@lucidvision.com> <958632F2-A758-4EC0-8D92-0B6C88DE187A@lucidvision.com> To: Andy Bierman X-Mailer: Apple Mail (2.2102) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-ShareWhite: 50.255.148.181 X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=13 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181 X-IP-stats: Notspam Incoming Last 0, First 90, in=678, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: Cc: "netmod-chairs@tools.ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] WebEx meeting invitation: NETMOD Interm meeting on OpenConfig X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 20:44:08 -0000 --Apple-Mail=_15AFAF01-4C68-4306-B8A5-48FCA52EAED6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 13, 2015:4:32 PM, at 4:32 PM, Andy Bierman = wrote: >=20 >=20 >=20 > On Thu, Aug 13, 2015 at 1:14 PM, Nadeau Thomas = > wrote: >=20 >> On Aug 13, 2015:4:03 PM, at 4:03 PM, Andy Bierman > wrote: >>=20 >>=20 >>=20 >> On Thu, Aug 13, 2015 at 12:41 PM, Nadeau Thomas = > wrote: >>=20 >>=20 >>=20 >>> On Aug 7, 2015:12:09 PM, at 12:09 PM, Benoit Claise = > wrote: >>>=20 >>> Dear all, >>>=20 >>> During the YANG Model Coordination Group webex call today, we = discussed=20 >>> this oper status and structure open issues. We're ready to help=20 >>> facilitate the discussion between the different proposals >>> We could compare the pros/cons of the different solutions from our = point=20 >>> of view. >>>=20 >>> To allow us some preparation time, alternate proposals should be = posted=20 >>> a week before the NETMOD interim meeting, i.e. Sept 3rd. >>>=20 >>> The YANG Model Coordination Group=20 >> Speaking as Co-chair: >>=20 >> Just to clarify a bit on this. The purpose of the next Interim = meeting is to close on the issues around the Open Config proposal. We = meant to do this in Praha, but we could not get the right people to = attend the meeting to have the right discussion. We need to close on = this issue as soon as possible, as this is possibly blocking a lot of = other WG-related work; therefore, if no alternative proposals are posted = to discuss ahead of the interim meeting, then the original proposal will = become the solution to move forward with in the WG. Alternatives must be = complete proposals, not bullet points of complaints or such things - = they must be a solution or they will not be allowed onto the agenda. As = Benoit declared above, these must be posted ahead of the meeting and = will be put on the agenda for the meeting to present/discuss/debate as = well as to give everyone ample time to read and understand the = document/s. >>=20 >>=20 >>=20 >> Are you proposing that all existing RFCs with YANG modules in them be >> changed to "obsolete", and new modules published that move the data >> under a container named "device" (from some TBD module)? If not, = then >> what is the proposal for data root placement for existing RFC = modules? >>=20 >> Are you also proposing that all YANG modules with config in them must >> define that config in a grouping, and all config must appear in a >> container named "config"? Also, that all config data must be = replicated >> (i.e., use that grouping) under a config false container named = ? >> This will be done even though in 90% of all servers, it doesn't take = very >> long for intended config to become the active config? If not, then = what >> is the exact proposal for usage within IETF modules? >>=20 >> Everyone should understand the impact of these changes. >> Silence should not mean "I read the openconfig proposals and >> approve of these changes". Only emails to this list that state as = much >> should mean that. >=20 > Andy, >=20 > Yes, people should read and understand the proposal. If they = don=E2=80=99t like it please come up with a=20 > viable alternative. If the alternative is to do nothing, then propose = that and we will see what the consensus=20 > is. If the proposal is to constructively alter parts of their = proposal, thats great too. After we get consensus on=20 > the general approach, I will manage things issue-by-issue as we are = doing with other major initiatives in=20 > NETMOD. What we will not do is continue to go round and round about = points of their proposal without > coming to any conclusions. We=E2=80=99ve had several interim meetings = where they have taken the time to=20 > discuss and educate everyone that is interested in how their approach = works and why. To-date, there=20 > are no alternatives being proposed resulting from those discussions - = just more debate/discussion. =20 > What the management is declaring is that the time has come to move = forward on this, one way or=20 > another. >=20 >=20 > It seems somewhat irregular to declare that silence means agreement to > an individual submission (no WG charter, no WG draft).=20 That is how we do the Yang 1.1 design team work right? The = mini-team makes a recommendation and if no one objects, it goes forward. Seems like the same thing to me. The point is that ample time has been given for anyone to object. There is still time now too - but we are limiting = that time so that the WG can move forward with or without this proposal. > There has not been a debate. There have been several interim meetings and this was discussed at now two full meetings. There have been ample opportunities for = debate. > There have been proposals, > and some people not even agreeing with the the problems. That was not the outcome of the last interim meeting. If others=20= do not agree, then they need to speak up. =E2=80=94Tom > There has been no response why: >=20 > (1) YANG config=3Dtrue|false is not good enough to filter, and why > extra NP containers called and are even = needed >=20 > (2) YANG constraints written for config=3Dtrue are not intended to > be applied to config=3Dfalse, yet that is exactly what is = proposed > with the replicated config under a container >=20 > (3) Why a new operation called cannot be used to > retrieve the actual value in use for /foo > There is no guessing required to map 1 path to another. > There is no additional cost for the 90% of devices that > do not take a long time to apply intended config > =20 > I agree with Lada that consensus should be gauged by mailing list > statements (count the number of non-authors that approve or oppose). > This discussion should take place on the mailing list, not another = virtual > interim that is outside normal business hours for most of us. >=20 >=20 >=20 >=20 >=20 > =E2=80=94Tom >=20 >=20 > Andy > =20 >=20 >=20 >=20 >=20 >>=20 >>=20 >> Thanks, >>=20 >> =E2=80=94Tom=20 >>=20 >>=20 >>=20 >>=20 >> Andy >> =20 >>=20 >>>> Hello, >>>> NETMOD Working Group invites you to join this WebEx meeting. >>>> =20 >>>> NETMOD Interm meeting on OpenConfig >>>> Thursday, September 10, 2015=20 >>>> 11:00 am | Eastern Daylight Time (New York, GMT-04:00) | 1 hr=20= >>>> =20 >>>> Join WebEx meeting = >>>> Meeting number: 645 732 277=20 >>>> Meeting password: 1234 >>>> =20 >>>> Join by phone >>>> 1-877-668-4493 Call-in toll free number (US/Canada) >>>> 1-650-479-3208 Call-in toll number (US/Canada) >>>> Access code: 645 732 277 >>>> Toll-free calling restrictions = >>>> =20 >>>> Add this meeting = to your calendar. >>>> =20 >>>> Can't join the meeting? Contact support. = >>>> =20 >>>> IMPORTANT NOTICE: Please note that this WebEx service allows audio = and other information sent during the session to be recorded, which may = be discoverable in a legal matter. By joining this session, you = automatically consent to such recordings. If you do not consent to being = recorded, discuss your concerns with the host or do not join the = session. >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod = >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod = >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod = >>=20 >>=20 >=20 >=20 --Apple-Mail=_15AFAF01-4C68-4306-B8A5-48FCA52EAED6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Aug 13, 2015:4:32 PM, at 4:32 PM, Andy Bierman <andy@yumaworks.com> = wrote:



On Thu, Aug 13, 2015 at 1:14 PM, = Nadeau Thomas <tnadeau@lucidvision.com> wrote:

On Aug = 13, 2015:4:03 PM, at 4:03 PM, Andy Bierman <andy@yumaworks.com> wrote:



On Thu, = Aug 13, 2015 at 12:41 PM, Nadeau Thomas <tnadeau@lucidvision.com> = wrote:



On Aug = 7, 2015:12:09 PM, at 12:09 PM, Benoit Claise <bclaise@cisco.com> wrote:

Dear all,

During the YANG Model Coordination Group webex call today, we discussed=20=

this oper status and structure open issues. We're ready to help=20
facilitate the discussion between the different proposals
We could compare the pros/cons of the different solutions from our point=20=

of view.

To allow us some preparation time, alternate proposals should be posted=20=

a week before the NETMOD interim meeting, i.e. Sept 3rd.

The YANG Model Coordination Group
= Speaking as Co-chair:

Just to clarify a bit on this. The purpose of the = next Interim meeting is to close on the issues around the Open Config = proposal. We meant to do this in Praha, but we could not get the right = people to attend the meeting to have the right discussion. We need to = close on this issue as soon as possible, as this is possibly blocking a = lot of other WG-related work; therefore, if no alternative proposals are = posted to discuss ahead of the interim meeting, then the original = proposal will become the solution to move forward with in the WG. = Alternatives must be complete proposals, not bullet points of complaints = or such things - they must be a solution or they will not be allowed = onto the agenda.  As Benoit declared above, these must be posted = ahead of the meeting and will be put on the agenda for the meeting to = present/discuss/debate as well as to give everyone ample time to read = and understand the document/s.



Are = you proposing that all existing RFCs with YANG modules in them = be
changed to "obsolete", and new modules published = that move the data
under a container named "device" = (from some TBD module)?  If not, then
what is = the proposal for data root placement for existing RFC modules?

Are you also proposing = that all YANG modules with config in them must
define= that config in a grouping, and all config must appear in a
container named "config"? Also, that all config data must be = replicated
(i.e., use that grouping) under a config = false container named <state>?
This will be = done even though in 90% of all servers, it doesn't take very
long for intended config to become the active config?  = If not, then what
is the exact proposal for usage = within IETF modules?

Everyone should understand the impact of these = changes.
Silence should not mean "I read the = openconfig proposals and
approve of these = changes".  Only emails to this list that state as much
should mean = that.

Andy,

Yes, people should read and understand the = proposal. If they don=E2=80=99t like it please come up with = a 
viable alternative. If the alternative is = to do nothing, then propose that and we will see what the = consensus 
is.  If the proposal is to = constructively alter parts of their proposal, thats great too.  = After we get consensus on 
the general = approach, I will manage things issue-by-issue as we are doing with other = major initiatives in 
NETMOD.  What we = will not do is continue to go round and round about points of their = proposal without
coming to any conclusions. We=E2=80=99= ve had several interim meetings where they have taken the time = to 
discuss and educate everyone that is = interested in how their approach works and why.  To-date, = there 
are no alternatives being proposed = resulting from those discussions - just more debate/discussion. =  
What the management is declaring is that the = time has come to move forward on this, one way or 
another.


It = seems somewhat irregular to declare that silence means agreement = to
an individual submission (no WG charter, no WG = draft). 

= That is how we do the Yang 1.1 design team work right? =  The mini-team
makes a recommendation and if no one = objects, it goes forward.  Seems
like the same thing to = me.  The point is that ample time has been given
for = anyone to object.  There is still time now too - but we are = limiting that
time so that the WG can move forward with or = without this proposal.

There = has not been a debate. =

There have been several interim = meetings and this was discussed
at now two full meetings. = There have been ample opportunities for debate.

There have been = proposals,
and some people not even agreeing with = the the problems.

That was not the outcome of the = last interim meeting. If others 
do not agree, then they = need to speak up.

= =E2=80=94Tom


There has been no response = why:

  = (1) YANG config=3Dtrue|false is not good enough to filter, and = why
        extra NP containers = called <config> and <state> are even needed

  (2) YANG = constraints written for config=3Dtrue are not intended to
        be applied to config=3Dfalse, yet = that is exactly what is proposed
    =      with the replicated config under a <state> = container

 (3)  Why a new operation called = <get-operational> cannot be used to
  =      retrieve the actual value in use for /foo
       There is no guessing required to = map 1 path to another.
      =  There is no additional cost for the 90% of devices that
       do not take a long time to apply = intended config
 
I agree = with Lada that consensus should be gauged by mailing list
statements (count the number of non-authors that approve or = oppose).
This discussion should take place on the = mailing list, not another virtual
interim that is = outside normal business hours for most of us.





= =E2=80=94Tom


Andy
 






Thanks,

= =E2=80=94Tom 




Andy
 

Hello,
NETMOD = Working Group invites you to join this WebEx = meeting.
 
NETMOD = Interm meeting on OpenConfig
Thursday, = September 10, 2015 
11:00 = am  |  Eastern Daylight Time (New York, = GMT-04:00)  |  1 hr 
 
Join = WebEx meeting
Meeting = number:645 732 277 
Meeting = password:1234
 
Join = by phone
1-877-668-4493 Call-in toll free number = (US/Canada)
1-650-479-3208 Call-in toll number = (US/Canada)
Access = code: 645 732 277
Toll-free calling = restrictions
 
Add this = meeting to your = calendar.
 
Can't join the = meeting? Contact = support.
 
IMPORTANT NOTICE: = Please note that this WebEx service allows audio and other information = sent during the session to be recorded, which may be discoverable in a = legal matter. By joining this session, you automatically consent to such = recordings. If you do not consent to being recorded, discuss your = concerns with the host or do not join the = session.


_______________________________________________=

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

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


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




= --Apple-Mail=_15AFAF01-4C68-4306-B8A5-48FCA52EAED6-- From nobody Thu Aug 13 14:12:41 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF3B01B3B1F for ; Thu, 13 Aug 2015 14:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.971 X-Spam-Level: X-Spam-Status: No, score=-2.971 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, MIME_HTML_MOSTLY=0.428, 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 KHhwMRm--tEF for ; Thu, 13 Aug 2015 14:12:37 -0700 (PDT) Received: from BAY004-OMC1S11.hotmail.com (bay004-omc1s11.hotmail.com [65.54.190.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AFB51B3B1E for ; Thu, 13 Aug 2015 14:12:37 -0700 (PDT) Received: from BAY407-EAS368 ([65.54.190.59]) by BAY004-OMC1S11.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Thu, 13 Aug 2015 14:12:37 -0700 X-TMN: [AO4g2t0WqE/+T2yXuAzwOjFUDEBWTbKFMiC9+ETTeYY=] X-Originating-Email: [mishra.ashesh@outlook.com] Message-ID: Content-Type: multipart/related; boundary="_04805805-1edd-42d5-8437-3fbce9f4b2ff_" From: Ashesh Mishra MIME-Version: 1.0 (1.0) Date: Thu, 13 Aug 2015 14:12:35 -0700 References: <1516231808.93378.1438887834598.JavaMail.nobody@jva2tc202.webex.com> <55C4D830.8030601@cisco.com> <95032778-8873-4B5A-8CE6-D74CD77AAD13@lucidvision.com> <958632F2-A758-4EC0-8D92-0B6C88DE187A@lucidvision.com> <407ACE9C-C636-496E-B19B-2EF11ED0C34A@lucidvision.com> To: Nadeau Thomas In-Reply-To: <407ACE9C-C636-496E-B19B-2EF11ED0C34A@lucidvision.com> X-OriginalArrivalTime: 13 Aug 2015 21:12:37.0208 (UTC) FILETIME=[C7B2CD80:01D0D60C] Archived-At: Cc: "netmod-chairs@tools.ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] WebEx meeting invitation: NETMOD Interm meeting on OpenConfig X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 21:12:41 -0000 --_04805805-1edd-42d5-8437-3fbce9f4b2ff_ Content-Type: multipart/alternative; boundary="Apple-Mail-EF8F0F39-FBC9-42AB-8BDF-994576F6A73F" Content-Transfer-Encoding: 7bit --Apple-Mail-EF8F0F39-FBC9-42AB-8BDF-994576F6A73F Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSdtIG5ldyB0byB0aGlzIElFVEYgdGhpbmcsIGJ1dCBmcm9tIG15IG90aGVyIGV4cGVyaWVuY2Vz IC0gc2lsZW5jZSBtZWFucyAiSSBkb24ndCBjYXJlIi4gIlllcyIgbWVhbnMgInllcyIuICAgDQoN CiJEbyBub3RoaW5nIC4uLiBmb3Igbm93IiBpcyBhIHBlcmZlY3RseSBnb29kIHJlc3BvbnNlIHRv IGEgcHJvcG9zYWwgdGhhdCBpc24ndCBnZW5lcmF0aW5nIHRoZSBleHBlY3RlZCBpbnRlcmVzdC4g DQoNCi0tDQpBc2hlc2gNCg0KPiBPbiBBdWcgMTMsIDIwMTUsIGF0IDE6NDQgUE0sIE5hZGVhdSBU aG9tYXMgPHRuYWRlYXVAbHVjaWR2aXNpb24uY29tPiB3cm90ZToNCj4gDQo+IA0KPj4gT24gQXVn IDEzLCAyMDE1OjQ6MzIgUE0sIGF0IDQ6MzIgUE0sIEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29y a3MuY29tPiB3cm90ZToNCj4+IA0KPj4gDQo+PiANCj4+IE9uIFRodSwgQXVnIDEzLCAyMDE1IGF0 IDE6MTQgUE0sIE5hZGVhdSBUaG9tYXMgPHRuYWRlYXVAbHVjaWR2aXNpb24uY29tPiB3cm90ZToN Cj4+PiANCj4+Pj4gT24gQXVnIDEzLCAyMDE1OjQ6MDMgUE0sIGF0IDQ6MDMgUE0sIEFuZHkgQmll cm1hbiA8YW5keUB5dW1hd29ya3MuY29tPiB3cm90ZToNCj4+Pj4gDQo+Pj4+IA0KPj4+PiANCj4+ Pj4gT24gVGh1LCBBdWcgMTMsIDIwMTUgYXQgMTI6NDEgUE0sIE5hZGVhdSBUaG9tYXMgPHRuYWRl YXVAbHVjaWR2aXNpb24uY29tPiB3cm90ZToNCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+ PiBPbiBBdWcgNywgMjAxNToxMjowOSBQTSwgYXQgMTI6MDkgUE0sIEJlbm9pdCBDbGFpc2UgPGJj bGFpc2VAY2lzY28uY29tPiB3cm90ZToNCj4+Pj4+PiANCj4+Pj4+PiBEZWFyIGFsbCwNCj4+Pj4+ PiANCj4+Pj4+PiBEdXJpbmcgdGhlIFlBTkcgTW9kZWwgQ29vcmRpbmF0aW9uIEdyb3VwIHdlYmV4 IGNhbGwgdG9kYXksIHdlIGRpc2N1c3NlZCANCj4+Pj4+PiB0aGlzIG9wZXIgc3RhdHVzIGFuZCBz dHJ1Y3R1cmUgb3BlbiBpc3N1ZXMuIFdlJ3JlIHJlYWR5IHRvIGhlbHAgDQo+Pj4+Pj4gZmFjaWxp dGF0ZSB0aGUgZGlzY3Vzc2lvbiBiZXR3ZWVuIHRoZSBkaWZmZXJlbnQgcHJvcG9zYWxzDQo+Pj4+ Pj4gV2UgY291bGQgY29tcGFyZSB0aGUgcHJvcy9jb25zIG9mIHRoZSBkaWZmZXJlbnQgc29sdXRp b25zIGZyb20gb3VyIHBvaW50IA0KPj4+Pj4+IG9mIHZpZXcuDQo+Pj4+Pj4gDQo+Pj4+Pj4gVG8g YWxsb3cgdXMgc29tZSBwcmVwYXJhdGlvbiB0aW1lLCBhbHRlcm5hdGUgcHJvcG9zYWxzIHNob3Vs ZCBiZSBwb3N0ZWQgDQo+Pj4+Pj4gYSB3ZWVrIGJlZm9yZSB0aGUgTkVUTU9EIGludGVyaW0gbWVl dGluZywgaS5lLiBTZXB0IDNyZC4NCj4+Pj4+PiANCj4+Pj4+PiBUaGUgWUFORyBNb2RlbCBDb29y ZGluYXRpb24gR3JvdXAgDQo+Pj4+PiAJU3BlYWtpbmcgYXMgQ28tY2hhaXI6DQo+Pj4+PiANCj4+ Pj4+IAlKdXN0IHRvIGNsYXJpZnkgYSBiaXQgb24gdGhpcy4gVGhlIHB1cnBvc2Ugb2YgdGhlIG5l eHQgSW50ZXJpbSBtZWV0aW5nIGlzIHRvIGNsb3NlIG9uIHRoZSBpc3N1ZXMgYXJvdW5kIHRoZSBP cGVuIENvbmZpZyBwcm9wb3NhbC4gV2UgbWVhbnQgdG8gZG8gdGhpcyBpbiBQcmFoYSwgYnV0IHdl IGNvdWxkIG5vdCBnZXQgdGhlIHJpZ2h0IHBlb3BsZSB0byBhdHRlbmQgdGhlIG1lZXRpbmcgdG8g aGF2ZSB0aGUgcmlnaHQgZGlzY3Vzc2lvbi4gV2UgbmVlZCB0byBjbG9zZSBvbiB0aGlzIGlzc3Vl IGFzIHNvb24gYXMgcG9zc2libGUsIGFzIHRoaXMgaXMgcG9zc2libHkgYmxvY2tpbmcgYSBsb3Qg b2Ygb3RoZXIgV0ctcmVsYXRlZCB3b3JrOyB0aGVyZWZvcmUsIGlmIG5vIGFsdGVybmF0aXZlIHBy b3Bvc2FscyBhcmUgcG9zdGVkIHRvIGRpc2N1c3MgYWhlYWQgb2YgdGhlIGludGVyaW0gbWVldGlu ZywgdGhlbiB0aGUgb3JpZ2luYWwgcHJvcG9zYWwgd2lsbCBiZWNvbWUgdGhlIHNvbHV0aW9uIHRv IG1vdmUgZm9yd2FyZCB3aXRoIGluIHRoZSBXRy4gQWx0ZXJuYXRpdmVzIG11c3QgYmUgY29tcGxl dGUgcHJvcG9zYWxzLCBub3QgYnVsbGV0IHBvaW50cyBvZiBjb21wbGFpbnRzIG9yIHN1Y2ggdGhp bmdzIC0gdGhleSBtdXN0IGJlIGEgc29sdXRpb24gb3IgdGhleSB3aWxsIG5vdCBiZSBhbGxvd2Vk IG9udG8gdGhlIGFnZW5kYS4gIEFzIEJlbm9pdCBkZWNsYXJlZCBhYm92ZSwgdGhlc2UgbXVzdCBi ZSBwb3N0ZWQgYWhlYWQgb2YgdGhlIG1lZXRpbmcgYW5kIHdpbGwgYmUgcHV0IG9uIHRoZSBhZ2Vu ZGEgZm9yIHRoZSBtZWV0aW5nIHRvIHByZXNlbnQvZGlzY3Vzcy9kZWJhdGUgYXMgd2VsbCBhcyB0 byBnaXZlIGV2ZXJ5b25lIGFtcGxlIHRpbWUgdG8gcmVhZCBhbmQgdW5kZXJzdGFuZCB0aGUgZG9j dW1lbnQvcy4NCj4+Pj4gDQo+Pj4+IA0KPj4+PiBBcmUgeW91IHByb3Bvc2luZyB0aGF0IGFsbCBl eGlzdGluZyBSRkNzIHdpdGggWUFORyBtb2R1bGVzIGluIHRoZW0gYmUNCj4+Pj4gY2hhbmdlZCB0 byAib2Jzb2xldGUiLCBhbmQgbmV3IG1vZHVsZXMgcHVibGlzaGVkIHRoYXQgbW92ZSB0aGUgZGF0 YQ0KPj4+PiB1bmRlciBhIGNvbnRhaW5lciBuYW1lZCAiZGV2aWNlIiAoZnJvbSBzb21lIFRCRCBt b2R1bGUpPyAgSWYgbm90LCB0aGVuDQo+Pj4+IHdoYXQgaXMgdGhlIHByb3Bvc2FsIGZvciBkYXRh IHJvb3QgcGxhY2VtZW50IGZvciBleGlzdGluZyBSRkMgbW9kdWxlcz8NCj4+Pj4gDQo+Pj4+IEFy ZSB5b3UgYWxzbyBwcm9wb3NpbmcgdGhhdCBhbGwgWUFORyBtb2R1bGVzIHdpdGggY29uZmlnIGlu IHRoZW0gbXVzdA0KPj4+PiBkZWZpbmUgdGhhdCBjb25maWcgaW4gYSBncm91cGluZywgYW5kIGFs bCBjb25maWcgbXVzdCBhcHBlYXIgaW4gYQ0KPj4+PiBjb250YWluZXIgbmFtZWQgImNvbmZpZyI/ IEFsc28sIHRoYXQgYWxsIGNvbmZpZyBkYXRhIG11c3QgYmUgcmVwbGljYXRlZA0KPj4+PiAoaS5l LiwgdXNlIHRoYXQgZ3JvdXBpbmcpIHVuZGVyIGEgY29uZmlnIGZhbHNlIGNvbnRhaW5lciBuYW1l ZCA8c3RhdGU+Pw0KPj4+PiBUaGlzIHdpbGwgYmUgZG9uZSBldmVuIHRob3VnaCBpbiA5MCUgb2Yg YWxsIHNlcnZlcnMsIGl0IGRvZXNuJ3QgdGFrZSB2ZXJ5DQo+Pj4+IGxvbmcgZm9yIGludGVuZGVk IGNvbmZpZyB0byBiZWNvbWUgdGhlIGFjdGl2ZSBjb25maWc/ICBJZiBub3QsIHRoZW4gd2hhdA0K Pj4+PiBpcyB0aGUgZXhhY3QgcHJvcG9zYWwgZm9yIHVzYWdlIHdpdGhpbiBJRVRGIG1vZHVsZXM/ DQo+Pj4+IA0KPj4+PiBFdmVyeW9uZSBzaG91bGQgdW5kZXJzdGFuZCB0aGUgaW1wYWN0IG9mIHRo ZXNlIGNoYW5nZXMuDQo+Pj4+IFNpbGVuY2Ugc2hvdWxkIG5vdCBtZWFuICJJIHJlYWQgdGhlIG9w ZW5jb25maWcgcHJvcG9zYWxzIGFuZA0KPj4+PiBhcHByb3ZlIG9mIHRoZXNlIGNoYW5nZXMiLiAg T25seSBlbWFpbHMgdG8gdGhpcyBsaXN0IHRoYXQgc3RhdGUgYXMgbXVjaA0KPj4+PiBzaG91bGQg bWVhbiB0aGF0Lg0KPj4+IA0KPj4+IAlBbmR5LA0KPj4+IA0KPj4+IAlZZXMsIHBlb3BsZSBzaG91 bGQgcmVhZCBhbmQgdW5kZXJzdGFuZCB0aGUgcHJvcG9zYWwuIElmIHRoZXkgZG9u4oCZdCBsaWtl IGl0IHBsZWFzZSBjb21lIHVwIHdpdGggYSANCj4+PiB2aWFibGUgYWx0ZXJuYXRpdmUuIElmIHRo ZSBhbHRlcm5hdGl2ZSBpcyB0byBkbyBub3RoaW5nLCB0aGVuIHByb3Bvc2UgdGhhdCBhbmQgd2Ug d2lsbCBzZWUgd2hhdCB0aGUgY29uc2Vuc3VzIA0KPj4+IGlzLiAgSWYgdGhlIHByb3Bvc2FsIGlz IHRvIGNvbnN0cnVjdGl2ZWx5IGFsdGVyIHBhcnRzIG9mIHRoZWlyIHByb3Bvc2FsLCB0aGF0cyBn cmVhdCB0b28uICBBZnRlciB3ZSBnZXQgY29uc2Vuc3VzIG9uIA0KPj4+IHRoZSBnZW5lcmFsIGFw cHJvYWNoLCBJIHdpbGwgbWFuYWdlIHRoaW5ncyBpc3N1ZS1ieS1pc3N1ZSBhcyB3ZSBhcmUgZG9p bmcgd2l0aCBvdGhlciBtYWpvciBpbml0aWF0aXZlcyBpbiANCj4+PiBORVRNT0QuICBXaGF0IHdl IHdpbGwgbm90IGRvIGlzIGNvbnRpbnVlIHRvIGdvIHJvdW5kIGFuZCByb3VuZCBhYm91dCBwb2lu dHMgb2YgdGhlaXIgcHJvcG9zYWwgd2l0aG91dA0KPj4+IGNvbWluZyB0byBhbnkgY29uY2x1c2lv bnMuIFdl4oCZdmUgaGFkIHNldmVyYWwgaW50ZXJpbSBtZWV0aW5ncyB3aGVyZSB0aGV5IGhhdmUg dGFrZW4gdGhlIHRpbWUgdG8gDQo+Pj4gZGlzY3VzcyBhbmQgZWR1Y2F0ZSBldmVyeW9uZSB0aGF0 IGlzIGludGVyZXN0ZWQgaW4gaG93IHRoZWlyIGFwcHJvYWNoIHdvcmtzIGFuZCB3aHkuICBUby1k YXRlLCB0aGVyZSANCj4+PiBhcmUgbm8gYWx0ZXJuYXRpdmVzIGJlaW5nIHByb3Bvc2VkIHJlc3Vs dGluZyBmcm9tIHRob3NlIGRpc2N1c3Npb25zIC0ganVzdCBtb3JlIGRlYmF0ZS9kaXNjdXNzaW9u LiAgDQo+Pj4gV2hhdCB0aGUgbWFuYWdlbWVudCBpcyBkZWNsYXJpbmcgaXMgdGhhdCB0aGUgdGlt ZSBoYXMgY29tZSB0byBtb3ZlIGZvcndhcmQgb24gdGhpcywgb25lIHdheSBvciANCj4+PiBhbm90 aGVyLg0KPj4gDQo+PiANCj4+IEl0IHNlZW1zIHNvbWV3aGF0IGlycmVndWxhciB0byBkZWNsYXJl IHRoYXQgc2lsZW5jZSBtZWFucyBhZ3JlZW1lbnQgdG8NCj4+IGFuIGluZGl2aWR1YWwgc3VibWlz c2lvbiAobm8gV0cgY2hhcnRlciwgbm8gV0cgZHJhZnQpLiANCj4gDQo+IAlUaGF0IGlzIGhvdyB3 ZSBkbyB0aGUgWWFuZyAxLjEgZGVzaWduIHRlYW0gd29yayByaWdodD8gIFRoZSBtaW5pLXRlYW0N Cj4gbWFrZXMgYSByZWNvbW1lbmRhdGlvbiBhbmQgaWYgbm8gb25lIG9iamVjdHMsIGl0IGdvZXMg Zm9yd2FyZC4gIFNlZW1zDQo+IGxpa2UgdGhlIHNhbWUgdGhpbmcgdG8gbWUuICBUaGUgcG9pbnQg aXMgdGhhdCBhbXBsZSB0aW1lIGhhcyBiZWVuIGdpdmVuDQo+IGZvciBhbnlvbmUgdG8gb2JqZWN0 LiAgVGhlcmUgaXMgc3RpbGwgdGltZSBub3cgdG9vIC0gYnV0IHdlIGFyZSBsaW1pdGluZyB0aGF0 DQo+IHRpbWUgc28gdGhhdCB0aGUgV0cgY2FuIG1vdmUgZm9yd2FyZCB3aXRoIG9yIHdpdGhvdXQg dGhpcyBwcm9wb3NhbC4NCj4gDQo+PiBUaGVyZSBoYXMgbm90IGJlZW4gYSBkZWJhdGUuDQo+IA0K PiAJVGhlcmUgaGF2ZSBiZWVuIHNldmVyYWwgaW50ZXJpbSBtZWV0aW5ncyBhbmQgdGhpcyB3YXMg ZGlzY3Vzc2VkDQo+IGF0IG5vdyB0d28gZnVsbCBtZWV0aW5ncy4gVGhlcmUgaGF2ZSBiZWVuIGFt cGxlIG9wcG9ydHVuaXRpZXMgZm9yIGRlYmF0ZS4NCj4gDQo+PiBUaGVyZSBoYXZlIGJlZW4gcHJv cG9zYWxzLA0KPj4gYW5kIHNvbWUgcGVvcGxlIG5vdCBldmVuIGFncmVlaW5nIHdpdGggdGhlIHRo ZSBwcm9ibGVtcy4NCj4gDQo+IAlUaGF0IHdhcyBub3QgdGhlIG91dGNvbWUgb2YgdGhlIGxhc3Qg aW50ZXJpbSBtZWV0aW5nLiBJZiBvdGhlcnMgDQo+IGRvIG5vdCBhZ3JlZSwgdGhlbiB0aGV5IG5l ZWQgdG8gc3BlYWsgdXAuDQo+IA0KPiAJ4oCUVG9tDQo+IA0KPiANCj4+IFRoZXJlIGhhcyBiZWVu IG5vIHJlc3BvbnNlIHdoeToNCj4+IA0KPj4gICAoMSkgWUFORyBjb25maWc9dHJ1ZXxmYWxzZSBp cyBub3QgZ29vZCBlbm91Z2ggdG8gZmlsdGVyLCBhbmQgd2h5DQo+PiAgICAgICAgIGV4dHJhIE5Q IGNvbnRhaW5lcnMgY2FsbGVkIDxjb25maWc+IGFuZCA8c3RhdGU+IGFyZSBldmVuIG5lZWRlZA0K Pj4gDQo+PiAgICgyKSBZQU5HIGNvbnN0cmFpbnRzIHdyaXR0ZW4gZm9yIGNvbmZpZz10cnVlIGFy ZSBub3QgaW50ZW5kZWQgdG8NCj4+ICAgICAgICAgYmUgYXBwbGllZCB0byBjb25maWc9ZmFsc2Us IHlldCB0aGF0IGlzIGV4YWN0bHkgd2hhdCBpcyBwcm9wb3NlZA0KPj4gICAgICAgICAgd2l0aCB0 aGUgcmVwbGljYXRlZCBjb25maWcgdW5kZXIgYSA8c3RhdGU+IGNvbnRhaW5lcg0KPj4gDQo+PiAg KDMpICBXaHkgYSBuZXcgb3BlcmF0aW9uIGNhbGxlZCA8Z2V0LW9wZXJhdGlvbmFsPiBjYW5ub3Qg YmUgdXNlZCB0bw0KPj4gICAgICAgIHJldHJpZXZlIHRoZSBhY3R1YWwgdmFsdWUgaW4gdXNlIGZv ciAvZm9vDQo+PiAgICAgICAgVGhlcmUgaXMgbm8gZ3Vlc3NpbmcgcmVxdWlyZWQgdG8gbWFwIDEg cGF0aCB0byBhbm90aGVyLg0KPj4gICAgICAgIFRoZXJlIGlzIG5vIGFkZGl0aW9uYWwgY29zdCBm b3IgdGhlIDkwJSBvZiBkZXZpY2VzIHRoYXQNCj4+ICAgICAgICBkbyBub3QgdGFrZSBhIGxvbmcg dGltZSB0byBhcHBseSBpbnRlbmRlZCBjb25maWcNCj4+ICANCj4+IEkgYWdyZWUgd2l0aCBMYWRh IHRoYXQgY29uc2Vuc3VzIHNob3VsZCBiZSBnYXVnZWQgYnkgbWFpbGluZyBsaXN0DQo+PiBzdGF0 ZW1lbnRzIChjb3VudCB0aGUgbnVtYmVyIG9mIG5vbi1hdXRob3JzIHRoYXQgYXBwcm92ZSBvciBv cHBvc2UpLg0KPj4gVGhpcyBkaXNjdXNzaW9uIHNob3VsZCB0YWtlIHBsYWNlIG9uIHRoZSBtYWls aW5nIGxpc3QsIG5vdCBhbm90aGVyIHZpcnR1YWwNCj4+IGludGVyaW0gdGhhdCBpcyBvdXRzaWRl IG5vcm1hbCBidXNpbmVzcyBob3VycyBmb3IgbW9zdCBvZiB1cy4NCj4+IA0KPj4gDQo+PiANCj4+ IA0KPj4+IA0KPj4+IAnigJRUb20NCj4+IA0KPj4gDQo+PiBBbmR5DQo+PiAgDQo+Pj4gDQo+Pj4g DQo+Pj4gDQo+Pj4gDQo+Pj4+IA0KPj4+PiANCj4+Pj4+IAlUaGFua3MsDQo+Pj4+PiANCj4+Pj4+ IAnigJRUb20gDQo+Pj4+IA0KPj4+PiANCj4+Pj4gQW5keQ0KPj4+PiAgDQo+Pj4+PiANCj4+Pj4+ Pj4gSGVsbG8sDQo+Pj4+Pj4+IE5FVE1PRCBXb3JraW5nIEdyb3VwIGludml0ZXMgeW91IHRvIGpv aW4gdGhpcyBXZWJFeCBtZWV0aW5nLg0KPj4+Pj4+PiAgDQo+Pj4+Pj4+IE5FVE1PRCBJbnRlcm0g bWVldGluZyBvbiBPcGVuQ29uZmlnDQo+Pj4+Pj4+IFRodXJzZGF5LCBTZXB0ZW1iZXIgMTAsIDIw MTUgDQo+Pj4+Pj4+IDExOjAwIGFtICB8ICBFYXN0ZXJuIERheWxpZ2h0IFRpbWUgKE5ldyBZb3Jr LCBHTVQtMDQ6MDApICB8ICAxIGhyIA0KPj4+Pj4+PiAgDQo+Pj4+Pj4+IEpvaW4gV2ViRXggbWVl dGluZw0KPj4+Pj4+PiBNZWV0aW5nIG51bWJlcjoJNjQ1IDczMiAyNzcgDQo+Pj4+Pj4+IE1lZXRp bmcgcGFzc3dvcmQ6CTEyMzQNCj4+Pj4+Pj4gIA0KPj4+Pj4+PiBKb2luIGJ5IHBob25lDQo+Pj4+ Pj4+IDEtODc3LTY2OC00NDkzIENhbGwtaW4gdG9sbCBmcmVlIG51bWJlciAoVVMvQ2FuYWRhKQ0K Pj4+Pj4+PiAxLTY1MC00NzktMzIwOCBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpDQo+ Pj4+Pj4+IEFjY2VzcyBjb2RlOiA2NDUgNzMyIDI3Nw0KPj4+Pj4+PiBUb2xsLWZyZWUgY2FsbGlu ZyByZXN0cmljdGlvbnMNCj4+Pj4+Pj4gIA0KPj4+Pj4+PiBBZGQgdGhpcyBtZWV0aW5nIHRvIHlv dXIgY2FsZW5kYXIuDQo+Pj4+Pj4+ICANCj4+Pj4+Pj4gQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz8g Q29udGFjdCBzdXBwb3J0Lg0KPj4+Pj4+PiAgDQo+Pj4+Pj4+IElNUE9SVEFOVCBOT1RJQ0U6IFBs ZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJFeCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIg aW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNo IG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpvaW5pbmcgdGhpcyBz ZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYg eW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNzIHlvdXIgY29uY2Vy bnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi4NCj4+Pj4+Pj4gDQo+ Pj4+Pj4+IA0KPj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4+Pj4+PiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+IG5ldG1vZEBpZXRm Lm9yZw0KPj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1v ZA0KPj4+Pj4+IA0KPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+Pj4+Pj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPj4+Pj4+IG5ldG1vZEBpZXRm Lm9yZw0KPj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9k DQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4+Pj4+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4+Pj4+IG5ldG1vZEBp ZXRmLm9yZw0KPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRt b2QNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gbmV0bW9kQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo= --Apple-Mail-EF8F0F39-FBC9-42AB-8BDF-994576F6A73F Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+SSdtIG5l dyB0byB0aGlzIElFVEYgdGhpbmcsIGJ1dCBmcm9tIG15IG90aGVyIGV4cGVyaWVuY2VzIC0gc2ls ZW5jZSBtZWFucyAiSSBkb24ndCBjYXJlIi4gIlllcyIgbWVhbnMgInllcyIuICZuYnNwOyZuYnNw OzwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+IkRvIG5vdGhpbmcgLi4uIGZvciBub3ciIGlzIGEg cGVyZmVjdGx5IGdvb2QgcmVzcG9uc2UgdG8gYSBwcm9wb3NhbCB0aGF0IGlzbid0IGdlbmVyYXRp bmcgdGhlIGV4cGVjdGVkIGludGVyZXN0LiZuYnNwOzxicj48YnI+LS08L2Rpdj48ZGl2PkFzaGVz aDxicj48L2Rpdj48ZGl2Pjxicj5PbiBBdWcgMTMsIDIwMTUsIGF0IDE6NDQgUE0sIE5hZGVhdSBU aG9tYXMgJmx0OzxhIGhyZWY9Im1haWx0bzp0bmFkZWF1QGx1Y2lkdmlzaW9uLmNvbSI+dG5hZGVh dUBsdWNpZHZpc2lvbi5jb208L2E+Jmd0OyB3cm90ZTo8YnI+PGJyPjwvZGl2PjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiPjxkaXY+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50 PSJ0ZXh0L2h0bWwgY2hhcnNldD11dGYtOCI+PGJyIGNsYXNzPSIiPjxkaXY+PGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSIgY2xhc3M9IiI+PGRpdiBjbGFzcz0iIj5PbiBBdWcgMTMsIDIwMTU6NDozMiBQ TSwgYXQgNDozMiBQTSwgQW5keSBCaWVybWFuICZsdDs8YSBocmVmPSJtYWlsdG86YW5keUB5dW1h d29ya3MuY29tIiBjbGFzcz0iIj5hbmR5QHl1bWF3b3Jrcy5jb208L2E+Jmd0OyB3cm90ZTo8L2Rp dj48YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPjxkaXYgY2xhc3M9IiI+PGRp diBkaXI9Imx0ciIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJh Ij48YnIgY2xhc3M9IiI+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIFRodSwgQXVnIDEzLCAy MDE1IGF0IDE6MTQgUE0sIE5hZGVhdSBUaG9tYXMgPHNwYW4gZGlyPSJsdHIiIGNsYXNzPSIiPiZs dDs8YSBocmVmPSJtYWlsdG86dG5hZGVhdUBsdWNpZHZpc2lvbi5jb20iIHRhcmdldD0iX2JsYW5r IiBjbGFzcz0iIj50bmFkZWF1QGx1Y2lkdmlzaW9uLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8 YnIgY2xhc3M9IiI+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2lu OjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+ PGRpdiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj48 ZGl2IGNsYXNzPSIiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPjxkaXYgY2xhc3M9 IiI+T24gQXVnIDEzLCAyMDE1OjQ6MDMgUE0sIGF0IDQ6MDMgUE0sIEFuZHkgQmllcm1hbiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNz PSIiPmFuZHlAeXVtYXdvcmtzLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2PjxiciBjbGFzcz0iIj48 ZGl2IGNsYXNzPSIiPjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj48ZGl2IGNs YXNzPSJnbWFpbF9leHRyYSI+PGJyIGNsYXNzPSIiPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5P biBUaHUsIEF1ZyAxMywgMjAxNSBhdCAxMjo0MSBQTSwgTmFkZWF1IFRob21hcyA8c3BhbiBkaXI9 Imx0ciIgY2xhc3M9IiI+Jmx0OzxhIGhyZWY9Im1haWx0bzp0bmFkZWF1QGx1Y2lkdmlzaW9uLmNv bSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPnRuYWRlYXVAbHVjaWR2aXNpb24uY29tPC9hPiZn dDs8L3NwYW4+IHdyb3RlOjxiciBjbGFzcz0iIj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVv dGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtw YWRkaW5nLWxlZnQ6MWV4Ij48ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCIgY2xhc3M9 IiI+PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+PC9kaXY+PGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+PC9kaXY+PGJyIGNsYXNzPSIiPjxkaXYgY2xhc3M9IiI+PGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSIgY2xhc3M9IiI+PGRpdiBjbGFzcz0iIj5PbiBBdWcgNywgMjAxNToxMjowOSBQTSwgYXQg MTI6MDkgUE0sIEJlbm9pdCBDbGFpc2UgJmx0OzxhIGhyZWY9Im1haWx0bzpiY2xhaXNlQGNpc2Nv LmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmJjbGFpc2VAY2lzY28uY29tPC9hPiZndDsg d3JvdGU6PC9kaXY+PGJyIGNsYXNzPSIiPjxkaXYgY2xhc3M9IiI+PGRpdiBzdHlsZT0id29yZC13 cmFwOmJyZWFrLXdvcmQ7d29yZC1icmVhazpub3JtYWw7Zm9udC1mYW1pbHk6SGVsdmV0aWNhO2Zv bnQtc2l6ZToxNnB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudDpub3JtYWw7Zm9udC13 ZWlnaHQ6bm9ybWFsO2xldHRlci1zcGFjaW5nOm5vcm1hbDtsaW5lLWhlaWdodDpub3JtYWw7dGV4 dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1z cGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweDtiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1 LDI1NSkiIGNsYXNzPSIiPjxwcmUgY2xhc3M9IiI+RGVhciBhbGwsDQoNCkR1cmluZyB0aGUgWUFO RyBNb2RlbCBDb29yZGluYXRpb24gR3JvdXAgd2ViZXggY2FsbCB0b2RheSwgd2UgZGlzY3Vzc2Vk IA0KdGhpcyBvcGVyIHN0YXR1cyBhbmQgc3RydWN0dXJlIG9wZW4gaXNzdWVzLiBXZSdyZSByZWFk eSB0byBoZWxwIA0KZmFjaWxpdGF0ZSB0aGUgZGlzY3Vzc2lvbiBiZXR3ZWVuIHRoZSBkaWZmZXJl bnQgcHJvcG9zYWxzDQpXZSBjb3VsZCBjb21wYXJlIHRoZSBwcm9zL2NvbnMgb2YgdGhlIGRpZmZl cmVudCBzb2x1dGlvbnMgZnJvbSBvdXIgcG9pbnQgDQpvZiB2aWV3Lg0KDQpUbyBhbGxvdyB1cyBz b21lIHByZXBhcmF0aW9uIHRpbWUsIGFsdGVybmF0ZSBwcm9wb3NhbHMgc2hvdWxkIGJlIHBvc3Rl ZCANCmEgd2VlayBiZWZvcmUgdGhlIE5FVE1PRCBpbnRlcmltIG1lZXRpbmcsIGkuZS4gU2VwdCAz cmQuDQoNClRoZSBZQU5HIE1vZGVsIENvb3JkaW5hdGlvbiBHcm91cCA8L3ByZT48L2Rpdj48L2Rp dj48L2Jsb2NrcXVvdGU+PGRpdiBjbGFzcz0iIj48c3BhbiBzdHlsZT0id2hpdGUtc3BhY2U6cHJl LXdyYXAiIGNsYXNzPSIiPgk8L3NwYW4+U3BlYWtpbmcgYXMgQ28tY2hhaXI6PC9kaXY+PGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+PC9kaXY+PGRpdiBjbGFzcz0iIj48c3BhbiBzdHlsZT0id2hp dGUtc3BhY2U6cHJlLXdyYXAiIGNsYXNzPSIiPgk8L3NwYW4+SnVzdCB0byBjbGFyaWZ5IGEgYml0 IG9uIHRoaXMuIFRoZSBwdXJwb3NlIG9mIHRoZSBuZXh0IEludGVyaW0gbWVldGluZyBpcyB0byBj bG9zZSBvbiB0aGUgaXNzdWVzIGFyb3VuZCB0aGUgT3BlbiBDb25maWcgcHJvcG9zYWwuIFdlIG1l YW50IHRvIGRvIHRoaXMgaW4gUHJhaGEsIGJ1dCB3ZSBjb3VsZCBub3QgZ2V0IHRoZSByaWdodCBw ZW9wbGUgdG8gYXR0ZW5kIHRoZSBtZWV0aW5nIHRvIGhhdmUgdGhlIHJpZ2h0IGRpc2N1c3Npb24u IFdlIG5lZWQgdG8gY2xvc2Ugb24gdGhpcyBpc3N1ZSBhcyBzb29uIGFzIHBvc3NpYmxlLCBhcyB0 aGlzIGlzIHBvc3NpYmx5IGJsb2NraW5nIGEgbG90IG9mIG90aGVyIFdHLXJlbGF0ZWQgd29yazsg dGhlcmVmb3JlLCBpZiBubyBhbHRlcm5hdGl2ZSBwcm9wb3NhbHMgYXJlIHBvc3RlZCB0byBkaXNj dXNzIGFoZWFkIG9mIHRoZSBpbnRlcmltIG1lZXRpbmcsIHRoZW4gdGhlIG9yaWdpbmFsIHByb3Bv c2FsIHdpbGwgYmVjb21lIHRoZSBzb2x1dGlvbiB0byBtb3ZlIGZvcndhcmQgd2l0aCBpbiB0aGUg V0cuIEFsdGVybmF0aXZlcyBtdXN0IGJlIGNvbXBsZXRlIHByb3Bvc2Fscywgbm90IGJ1bGxldCBw b2ludHMgb2YgY29tcGxhaW50cyBvciBzdWNoIHRoaW5ncyAtIHRoZXkgbXVzdCBiZSBhIHNvbHV0 aW9uIG9yIHRoZXkgd2lsbCBub3QgYmUgYWxsb3dlZCBvbnRvIHRoZSBhZ2VuZGEuJm5ic3A7IEFz IEJlbm9pdCBkZWNsYXJlZCBhYm92ZSwgdGhlc2UgbXVzdCBiZSBwb3N0ZWQgYWhlYWQgb2YgdGhl IG1lZXRpbmcgYW5kIHdpbGwgYmUgcHV0IG9uIHRoZSBhZ2VuZGEgZm9yIHRoZSBtZWV0aW5nIHRv IHByZXNlbnQvZGlzY3Vzcy9kZWJhdGUgYXMgd2VsbCBhcyB0byBnaXZlIGV2ZXJ5b25lIGFtcGxl IHRpbWUgdG8gcmVhZCBhbmQgdW5kZXJzdGFuZCB0aGUgZG9jdW1lbnQvcy48L2Rpdj48ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj48L2Rpdj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+PC9kaXY+PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+PC9k aXY+PGRpdiBjbGFzcz0iIj5BcmUgeW91IHByb3Bvc2luZyB0aGF0IGFsbCBleGlzdGluZyBSRkNz IHdpdGggWUFORyBtb2R1bGVzIGluIHRoZW0gYmU8L2Rpdj48ZGl2IGNsYXNzPSIiPmNoYW5nZWQg dG8gIm9ic29sZXRlIiwgYW5kIG5ldyBtb2R1bGVzIHB1Ymxpc2hlZCB0aGF0IG1vdmUgdGhlIGRh dGE8L2Rpdj48ZGl2IGNsYXNzPSIiPnVuZGVyIGEgY29udGFpbmVyIG5hbWVkICJkZXZpY2UiIChm cm9tIHNvbWUgVEJEIG1vZHVsZSk/Jm5ic3A7IElmIG5vdCwgdGhlbjwvZGl2PjxkaXYgY2xhc3M9 IiI+d2hhdCBpcyB0aGUgcHJvcG9zYWwgZm9yIGRhdGEgcm9vdCBwbGFjZW1lbnQgZm9yIGV4aXN0 aW5nIFJGQyBtb2R1bGVzPzwvZGl2PjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPjwvZGl2Pjxk aXYgY2xhc3M9IiI+QXJlIHlvdSBhbHNvIHByb3Bvc2luZyB0aGF0IGFsbCBZQU5HIG1vZHVsZXMg d2l0aCBjb25maWcgaW4gdGhlbSBtdXN0PC9kaXY+PGRpdiBjbGFzcz0iIj5kZWZpbmUgdGhhdCBj b25maWcgaW4gYSBncm91cGluZywgYW5kIGFsbCBjb25maWcgbXVzdCBhcHBlYXIgaW4gYTwvZGl2 PjxkaXYgY2xhc3M9IiI+Y29udGFpbmVyIG5hbWVkICJjb25maWciPyBBbHNvLCB0aGF0IGFsbCBj b25maWcgZGF0YSBtdXN0IGJlIHJlcGxpY2F0ZWQ8L2Rpdj48ZGl2IGNsYXNzPSIiPihpLmUuLCB1 c2UgdGhhdCBncm91cGluZykgdW5kZXIgYSBjb25maWcgZmFsc2UgY29udGFpbmVyIG5hbWVkICZs dDtzdGF0ZSZndDs/PC9kaXY+PGRpdiBjbGFzcz0iIj5UaGlzIHdpbGwgYmUgZG9uZSBldmVuIHRo b3VnaCBpbiA5MCUgb2YgYWxsIHNlcnZlcnMsIGl0IGRvZXNuJ3QgdGFrZSB2ZXJ5PC9kaXY+PGRp diBjbGFzcz0iIj5sb25nIGZvciBpbnRlbmRlZCBjb25maWcgdG8gYmVjb21lIHRoZSBhY3RpdmUg Y29uZmlnPyZuYnNwOyBJZiBub3QsIHRoZW4gd2hhdDwvZGl2PjxkaXYgY2xhc3M9IiI+aXMgdGhl IGV4YWN0IHByb3Bvc2FsIGZvciB1c2FnZSB3aXRoaW4gSUVURiBtb2R1bGVzPzwvZGl2PjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPjwvZGl2PjxkaXYgY2xhc3M9IiI+RXZlcnlvbmUgc2hvdWxk IHVuZGVyc3RhbmQgdGhlIGltcGFjdCBvZiB0aGVzZSBjaGFuZ2VzLjwvZGl2PjxkaXYgY2xhc3M9 IiI+U2lsZW5jZSBzaG91bGQgbm90IG1lYW4gIkkgcmVhZCB0aGUgb3BlbmNvbmZpZyBwcm9wb3Nh bHMgYW5kPC9kaXY+PGRpdiBjbGFzcz0iIj5hcHByb3ZlIG9mIHRoZXNlIGNoYW5nZXMiLiZuYnNw OyBPbmx5IGVtYWlscyB0byB0aGlzIGxpc3QgdGhhdCBzdGF0ZSBhcyBtdWNoPC9kaXY+PGRpdiBj bGFzcz0iIj5zaG91bGQgbWVhbiB0aGF0LjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2Pjwv YmxvY2txdW90ZT48ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj48L2Rpdj48ZGl2IGNsYXNzPSIi PjxzcGFuIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcCIgY2xhc3M9IiI+CTwvc3Bhbj5BbmR5 LDwvZGl2PjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPjwvZGl2PjxkaXYgY2xhc3M9IiI+PHNw YW4gc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIiBjbGFzcz0iIj4JPC9zcGFuPlllcywgcGVv cGxlIHNob3VsZCByZWFkIGFuZCB1bmRlcnN0YW5kIHRoZSBwcm9wb3NhbC4gSWYgdGhleSBkb27i gJl0IGxpa2UgaXQgcGxlYXNlIGNvbWUgdXAgd2l0aCBhJm5ic3A7PC9kaXY+PGRpdiBjbGFzcz0i Ij52aWFibGUgYWx0ZXJuYXRpdmUuIElmIHRoZSBhbHRlcm5hdGl2ZSBpcyB0byBkbyBub3RoaW5n LCB0aGVuIHByb3Bvc2UgdGhhdCBhbmQgd2Ugd2lsbCBzZWUgd2hhdCB0aGUgY29uc2Vuc3VzJm5i c3A7PC9kaXY+PGRpdiBjbGFzcz0iIj5pcy4mbmJzcDsgSWYgdGhlIHByb3Bvc2FsIGlzIHRvIGNv bnN0cnVjdGl2ZWx5IGFsdGVyIHBhcnRzIG9mIHRoZWlyIHByb3Bvc2FsLCB0aGF0cyBncmVhdCB0 b28uJm5ic3A7IEFmdGVyIHdlIGdldCBjb25zZW5zdXMgb24mbmJzcDs8L2Rpdj48ZGl2IGNsYXNz PSIiPnRoZSBnZW5lcmFsIGFwcHJvYWNoLCBJIHdpbGwgbWFuYWdlIHRoaW5ncyBpc3N1ZS1ieS1p c3N1ZSBhcyB3ZSBhcmUgZG9pbmcgd2l0aCBvdGhlciBtYWpvciBpbml0aWF0aXZlcyBpbiZuYnNw OzwvZGl2PjxkaXYgY2xhc3M9IiI+TkVUTU9ELiZuYnNwOyBXaGF0IHdlIHdpbGwgbm90IGRvIGlz IGNvbnRpbnVlIHRvIGdvIHJvdW5kIGFuZCByb3VuZCBhYm91dCBwb2ludHMgb2YgdGhlaXIgcHJv cG9zYWwgd2l0aG91dDwvZGl2PjxkaXYgY2xhc3M9IiI+Y29taW5nIHRvIGFueSBjb25jbHVzaW9u cy4gV2XigJl2ZSBoYWQgc2V2ZXJhbCBpbnRlcmltIG1lZXRpbmdzIHdoZXJlIHRoZXkgaGF2ZSB0 YWtlbiB0aGUgdGltZSB0byZuYnNwOzwvZGl2PjxkaXYgY2xhc3M9IiI+ZGlzY3VzcyBhbmQgZWR1 Y2F0ZSBldmVyeW9uZSB0aGF0IGlzIGludGVyZXN0ZWQgaW4gaG93IHRoZWlyIGFwcHJvYWNoIHdv cmtzIGFuZCB3aHkuJm5ic3A7IFRvLWRhdGUsIHRoZXJlJm5ic3A7PC9kaXY+PGRpdiBjbGFzcz0i Ij5hcmUgbm8gYWx0ZXJuYXRpdmVzIGJlaW5nIHByb3Bvc2VkIHJlc3VsdGluZyBmcm9tIHRob3Nl IGRpc2N1c3Npb25zIC0ganVzdCBtb3JlIGRlYmF0ZS9kaXNjdXNzaW9uLiAmbmJzcDs8L2Rpdj48 ZGl2IGNsYXNzPSIiPldoYXQgdGhlIG1hbmFnZW1lbnQgaXMgZGVjbGFyaW5nIGlzIHRoYXQgdGhl IHRpbWUgaGFzIGNvbWUgdG8gbW92ZSBmb3J3YXJkIG9uIHRoaXMsIG9uZSB3YXkgb3ImbmJzcDs8 L2Rpdj48ZGl2IGNsYXNzPSIiPmFub3RoZXIuPC9kaXY+PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3Rl PjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPjwvZGl2PjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPjwvZGl2PjxkaXYgY2xhc3M9IiI+SXQgc2VlbXMgc29tZXdoYXQgaXJyZWd1bGFyIHRvIGRl Y2xhcmUgdGhhdCBzaWxlbmNlIG1lYW5zIGFncmVlbWVudCB0bzwvZGl2PjxkaXYgY2xhc3M9IiI+ YW4gaW5kaXZpZHVhbCBzdWJtaXNzaW9uIChubyBXRyBjaGFydGVyLCBubyBXRyBkcmFmdCkuJm5i c3A7PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PGJyIGNs YXNzPSIiPjwvZGl2PjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNw YWNlOnByZSI+CTwvc3Bhbj5UaGF0IGlzIGhvdyB3ZSBkbyB0aGUgWWFuZyAxLjEgZGVzaWduIHRl YW0gd29yayByaWdodD8gJm5ic3A7VGhlIG1pbmktdGVhbTwvZGl2PjxkaXY+bWFrZXMgYSByZWNv bW1lbmRhdGlvbiBhbmQgaWYgbm8gb25lIG9iamVjdHMsIGl0IGdvZXMgZm9yd2FyZC4gJm5ic3A7 U2VlbXM8L2Rpdj48ZGl2Pmxpa2UgdGhlIHNhbWUgdGhpbmcgdG8gbWUuICZuYnNwO1RoZSBwb2lu dCBpcyB0aGF0IGFtcGxlIHRpbWUgaGFzIGJlZW4gZ2l2ZW48L2Rpdj48ZGl2PmZvciBhbnlvbmUg dG8gb2JqZWN0LiAmbmJzcDtUaGVyZSBpcyBzdGlsbCB0aW1lIG5vdyB0b28gLSBidXQgd2UgYXJl IGxpbWl0aW5nIHRoYXQ8L2Rpdj48ZGl2PnRpbWUgc28gdGhhdCB0aGUgV0cgY2FuIG1vdmUgZm9y d2FyZCB3aXRoIG9yIHdpdGhvdXQgdGhpcyBwcm9wb3NhbC48L2Rpdj48ZGl2PjxiciBjbGFzcz0i Ij48YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj48ZGl2IGNsYXNzPSIiPjxkaXYgZGly PSJsdHIiIGNsYXNzPSIiPjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48ZGl2IGNsYXNzPSJnbWFp bF9xdW90ZSI+PGRpdiBjbGFzcz0iIj5UaGVyZSBoYXMgbm90IGJlZW4gYSBkZWJhdGUuIDwvZGl2 PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2PjxiciBjbGFzcz0iIj48 L2Rpdj48ZGl2PjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNl OnByZSI+CTwvc3Bhbj5UaGVyZSBoYXZlIGJlZW4gc2V2ZXJhbCBpbnRlcmltIG1lZXRpbmdzIGFu ZCB0aGlzIHdhcyBkaXNjdXNzZWQ8L2Rpdj48ZGl2PmF0IG5vdyB0d28gZnVsbCBtZWV0aW5ncy4g VGhlcmUgaGF2ZSBiZWVuIGFtcGxlIG9wcG9ydHVuaXRpZXMgZm9yIGRlYmF0ZS48L2Rpdj48YnIg Y2xhc3M9IiI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+PGRpdiBjbGFzcz0iIj48 ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj48ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGRpdiBjbGFz cz0iZ21haWxfcXVvdGUiPjxkaXYgY2xhc3M9IiI+VGhlcmUgaGF2ZSBiZWVuIHByb3Bvc2Fscyw8 L2Rpdj48ZGl2IGNsYXNzPSIiPmFuZCBzb21lIHBlb3BsZSBub3QgZXZlbiBhZ3JlZWluZyB3aXRo IHRoZSB0aGUgcHJvYmxlbXMuPC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9ibG9ja3F1 b3RlPjxkaXY+PGJyIGNsYXNzPSIiPjwvZGl2PjxkaXY+PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1z cGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj4JPC9zcGFuPlRoYXQgd2FzIG5vdCB0aGUgb3V0 Y29tZSBvZiB0aGUgbGFzdCBpbnRlcmltIG1lZXRpbmcuIElmIG90aGVycyZuYnNwOzwvZGl2Pjxk aXY+ZG8gbm90IGFncmVlLCB0aGVuIHRoZXkgbmVlZCB0byBzcGVhayB1cC48L2Rpdj48ZGl2Pjxi ciBjbGFzcz0iIj48L2Rpdj48ZGl2PjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9 IndoaXRlLXNwYWNlOnByZSI+CTwvc3Bhbj7igJRUb208L2Rpdj48ZGl2PjxiciBjbGFzcz0iIj48 L2Rpdj48YnIgY2xhc3M9IiI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+PGRpdiBj bGFzcz0iIj48ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj48ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+ PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPjxkaXYgY2xhc3M9IiI+VGhlcmUgaGFzIGJlZW4gbm8g cmVzcG9uc2Ugd2h5OjwvZGl2PjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPjwvZGl2PjxkaXYg Y2xhc3M9IiI+Jm5ic3A7ICgxKSBZQU5HIGNvbmZpZz10cnVlfGZhbHNlIGlzIG5vdCBnb29kIGVu b3VnaCB0byBmaWx0ZXIsIGFuZCB3aHk8L2Rpdj48ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBleHRyYSBOUCBjb250YWluZXJzIGNhbGxlZCAmbHQ7Y29uZmlnJmd0OyBh bmQgJmx0O3N0YXRlJmd0OyBhcmUgZXZlbiBuZWVkZWQ8L2Rpdj48ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj48L2Rpdj48ZGl2IGNsYXNzPSIiPiZuYnNwOyAoMikgWUFORyBjb25zdHJhaW50cyB3 cml0dGVuIGZvciBjb25maWc9dHJ1ZSBhcmUgbm90IGludGVuZGVkIHRvPC9kaXY+PGRpdiBjbGFz cz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgYmUgYXBwbGllZCB0byBjb25maWc9ZmFs c2UsIHlldCB0aGF0IGlzIGV4YWN0bHkgd2hhdCBpcyBwcm9wb3NlZDwvZGl2PjxkaXYgY2xhc3M9 IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3dpdGggdGhlIHJlcGxpY2F0ZWQg Y29uZmlnIHVuZGVyIGEgJmx0O3N0YXRlJmd0OyBjb250YWluZXI8L2Rpdj48ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj48L2Rpdj48ZGl2IGNsYXNzPSIiPiZuYnNwOygzKSAmbmJzcDtXaHkgYSBu ZXcgb3BlcmF0aW9uIGNhbGxlZCAmbHQ7Z2V0LW9wZXJhdGlvbmFsJmd0OyBjYW5ub3QgYmUgdXNl ZCB0bzwvZGl2PjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cmV0cmll dmUgdGhlIGFjdHVhbCB2YWx1ZSBpbiB1c2UgZm9yIC9mb288L2Rpdj48ZGl2IGNsYXNzPSIiPiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1RoZXJlIGlzIG5vIGd1ZXNzaW5nIHJlcXVpcmVkIHRv IG1hcCAxIHBhdGggdG8gYW5vdGhlci48L2Rpdj48ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO1RoZXJlIGlzIG5vIGFkZGl0aW9uYWwgY29zdCBmb3IgdGhlIDkwJSBvZiBk ZXZpY2VzIHRoYXQ8L2Rpdj48ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O2RvIG5vdCB0YWtlIGEgbG9uZyB0aW1lIHRvIGFwcGx5IGludGVuZGVkIGNvbmZpZzwvZGl2Pjxk aXYgY2xhc3M9IiI+Jm5ic3A7PC9kaXY+PGRpdiBjbGFzcz0iIj5JIGFncmVlIHdpdGggTGFkYSB0 aGF0IGNvbnNlbnN1cyBzaG91bGQgYmUgZ2F1Z2VkIGJ5IG1haWxpbmcgbGlzdDwvZGl2PjxkaXYg Y2xhc3M9IiI+c3RhdGVtZW50cyAoY291bnQgdGhlIG51bWJlciBvZiBub24tYXV0aG9ycyB0aGF0 IGFwcHJvdmUgb3Igb3Bwb3NlKS48L2Rpdj48ZGl2IGNsYXNzPSIiPlRoaXMgZGlzY3Vzc2lvbiBz aG91bGQgdGFrZSBwbGFjZSBvbiB0aGUgbWFpbGluZyBsaXN0LCBub3QgYW5vdGhlciB2aXJ0dWFs PC9kaXY+PGRpdiBjbGFzcz0iIj5pbnRlcmltIHRoYXQgaXMgb3V0c2lkZSBub3JtYWwgYnVzaW5l c3MgaG91cnMgZm9yIG1vc3Qgb2YgdXMuPC9kaXY+PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ PC9kaXY+PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+PC9kaXY+PGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+PC9kaXY+PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+PC9kaXY+PGJsb2NrcXVv dGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxl ZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+PGRpdiBzdHlsZT0id29yZC13cmFw OmJyZWFrLXdvcmQiIGNsYXNzPSIiPjxkaXYgY2xhc3M9IiI+PGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+PC9kaXY+PGRpdiBjbGFzcz0iIj48c3BhbiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlLXdy YXAiIGNsYXNzPSIiPgk8L3NwYW4+4oCUVG9tPC9kaXY+PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3Rl PjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPjwvZGl2PjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPjwvZGl2PjxkaXYgY2xhc3M9IiI+QW5keTwvZGl2PjxkaXYgY2xhc3M9IiI+Jm5ic3A7PC9k aXY+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44 ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+PGRpdiBzdHls ZT0id29yZC13cmFwOmJyZWFrLXdvcmQiIGNsYXNzPSIiPjxkaXYgY2xhc3M9IiI+PGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+PC9kaXY+PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+PC9kaXY+ PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+PC9kaXY+PGJyIGNsYXNzPSIiPjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiIGNsYXNzPSIiPjxkaXYgY2xhc3M9IiI+PGRpdiBkaXI9Imx0ciIgY2xhc3M9 IiI+PGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj48ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj48L2Rpdj48ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj48 L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAg LjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij48ZGl2IHN0 eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCIgY2xhc3M9IiI+PGRpdiBjbGFzcz0iIj48ZGl2IGNs YXNzPSIiPjwvZGl2PjxkaXYgY2xhc3M9IiI+PHNwYW4gc3R5bGU9IndoaXRlLXNwYWNlOnByZS13 cmFwIiBjbGFzcz0iIj4JPC9zcGFuPlRoYW5rcyw8L2Rpdj48ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj48L2Rpdj48ZGl2IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3Jh cCIgY2xhc3M9IiI+CTwvc3Bhbj7igJRUb20mbmJzcDs8L2Rpdj48ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj48L2Rpdj48ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj48L2Rpdj48L2Rpdj48L2Rp dj48L2Jsb2NrcXVvdGU+PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+PC9kaXY+PGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+PC9kaXY+PGRpdiBjbGFzcz0iIj5BbmR5PC9kaXY+PGRpdiBjbGFz cz0iIj4mbmJzcDs8L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJt YXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6 MWV4Ij48ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCIgY2xhc3M9IiI+PGRpdiBjbGFz cz0iIj48ZGl2IGNsYXNzPSIiPjwvZGl2PjxiciBjbGFzcz0iIj48YmxvY2txdW90ZSB0eXBlPSJj aXRlIiBjbGFzcz0iIj48ZGl2IGNsYXNzPSIiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIHN0eWxl PSJmb250LWZhbWlseTpIZWx2ZXRpY2E7Zm9udC1zaXplOjE2cHg7Zm9udC1zdHlsZTpub3JtYWw7 Zm9udC12YXJpYW50Om5vcm1hbDtmb250LXdlaWdodDpub3JtYWw7bGV0dGVyLXNwYWNpbmc6bm9y bWFsO2xpbmUtaGVpZ2h0Om5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50OjBweDt0 ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNwYWNlOm5vcm1hbDt3b3JkLXNwYWNpbmc6MHB4O2Jh Y2tncm91bmQtY29sb3I6cmdiKDI1NSwyNTUsMjU1KSIgY2xhc3M9IiI+PHRhYmxlIGFsaWduPSJs ZWZ0IiB3aWR0aD0iMTAwJSIgc3R5bGU9ImJvcmRlci1jb2xsYXBzZTpzZXBhcmF0ZTtib3JkZXI6 MHB4IHdoaXRlO2JvcmRlci1zcGFjaW5nOjBweDt3aWR0aDoxMDAlIWltcG9ydGFudDttYXgtd2lk dGg6NTI1cHghaW1wb3J0YW50O21pbi13aWR0aDoyNzlweCFpbXBvcnRhbnQ7cGFkZGluZzowcHg7 bWFyZ2luOjBweCIgY2xhc3M9IiI+PHRib2R5IGNsYXNzPSIiPjx0ciBzdHlsZT0ibGluZS1oZWln aHQ6MjBweCIgY2xhc3M9IiI+PHRkIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZDt3b3JkLWJy ZWFrOm5vcm1hbDtmb250LXNpemU6MTVweDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpyZ2IoMTAy LDEwMiwxMDIpO3BhZGRpbmc6NXB4IDBweCAwcHgiIGNsYXNzPSIiPjx0YWJsZSBhbGlnbj0ibGVm dCIgc3R5bGU9ImJvcmRlci1jb2xsYXBzZTpzZXBhcmF0ZTtib3JkZXI6MHB4IHdoaXRlO2JvcmRl ci1zcGFjaW5nOjBweDt3aWR0aDoxMDAlIWltcG9ydGFudDttYXgtd2lkdGg6NTI1cHghaW1wb3J0 YW50O21pbi13aWR0aDoyNzlweCFpbXBvcnRhbnQ7bWFyZ2luLWxlZnQ6NXB4IiBjbGFzcz0iIj48 dGJvZHkgY2xhc3M9IiI+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDoyMHB4IiBjbGFzcz0iIj48dGQg dmFsaWduPSJ0b3AiIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZDt3b3JkLWJyZWFrOm5vcm1h bDtmb250LXNpemU6MTVweDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpyZ2IoMTAyLDEwMiwxMDIp O3BhZGRpbmc6MHB4IiBjbGFzcz0iIj48dGFibGUgc3R5bGU9ImJvcmRlci1jb2xsYXBzZTpzZXBh cmF0ZTtib3JkZXI6MHB4IHdoaXRlO2JvcmRlci1zcGFjaW5nOjBweDt3aWR0aDoxMDAlIWltcG9y dGFudDttYXgtd2lkdGg6NTI1cHghaW1wb3J0YW50O21pbi13aWR0aDoyNzlweCFpbXBvcnRhbnQi IGNsYXNzPSIiPjx0Ym9keSBjbGFzcz0iIj48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OjIwcHgiIGNs YXNzPSIiPjx0ZCBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQ7d29yZC1icmVhazpub3JtYWw7 Zm9udC1zaXplOjE1cHg7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6cmdiKDc3LDc3LDc3KTtwYWRk aW5nOjBweCIgY2xhc3M9IiI+SGVsbG8sPC90ZD48L3RyPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6 MjBweCIgY2xhc3M9IiI+PHRkIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZDt3b3JkLWJyZWFr Om5vcm1hbDtmb250LXNpemU6MTVweDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpyZ2IoNzcsNzcs NzcpO3BhZGRpbmc6MTBweCAwcHggMHB4IiBjbGFzcz0iIj5ORVRNT0QgV29ya2luZyBHcm91cCBp bnZpdGVzIHlvdSB0byBqb2luIHRoaXMgV2ViRXggbWVldGluZy48L3RkPjwvdHI+PC90Ym9keT48 L3RhYmxlPjx0YWJsZSBzdHlsZT0iYm9yZGVyLWNvbGxhcHNlOnNlcGFyYXRlO2JvcmRlcjowcHgg d2hpdGU7Ym9yZGVyLXNwYWNpbmc6MHB4O3dpZHRoOjEwMCUhaW1wb3J0YW50O21heC13aWR0aDo1 MjVweCFpbXBvcnRhbnQ7bWluLXdpZHRoOjI3OXB4IWltcG9ydGFudCIgY2xhc3M9IiI+PHRib2R5 IGNsYXNzPSIiPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6MjBweCIgY2xhc3M9IiI+PHRkIHN0eWxl PSJ3b3JkLXdyYXA6YnJlYWstd29yZDt3b3JkLWJyZWFrOm5vcm1hbDtmb250LXNpemU6MTVweDtm b250LWZhbWlseTpBcmlhbDtjb2xvcjpyZ2IoMTAyLDEwMiwxMDIpO3BhZGRpbmc6MHB4O2hlaWdo dDoyMHB4IiBjbGFzcz0iIj4mbmJzcDs8L3RkPjwvdHI+PC90Ym9keT48L3RhYmxlPjx0YWJsZSB3 aWR0aD0iMTAwJSIgc3R5bGU9ImJvcmRlci1jb2xsYXBzZTpzZXBhcmF0ZTtib3JkZXI6MHB4IHdo aXRlO2JvcmRlci1zcGFjaW5nOjBweDt3aWR0aDoxMDAlIWltcG9ydGFudDttYXgtd2lkdGg6NTI1 cHghaW1wb3J0YW50O21pbi13aWR0aDoyNzlweCFpbXBvcnRhbnQiIGNsYXNzPSIiPjx0Ym9keSBj bGFzcz0iIj48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OjIwcHgiIGNsYXNzPSIiPjx0ZCBzdHlsZT0i d29yZC13cmFwOmJyZWFrLXdvcmQ7d29yZC1icmVhazpub3JtYWw7Zm9udC1zaXplOjE2cHg7Zm9u dC1mYW1pbHk6QXJpYWw7Y29sb3I6cmdiKDc3LDc3LDc3KTtwYWRkaW5nOjBweCIgY2xhc3M9IiI+ PGIgY2xhc3M9IiI+TkVUTU9EIEludGVybSBtZWV0aW5nIG9uIE9wZW5Db25maWc8L2I+PC90ZD48 L3RyPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6MjBweDttYXJnaW46MHB4IiBjbGFzcz0iIj48dGQg c3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkO3dvcmQtYnJlYWs6bm9ybWFsO2ZvbnQtc2l6ZTox NXB4O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOnJnYigxMDIsMTAyLDEwMik7cGFkZGluZzowcHgi IGNsYXNzPSIiPlRodXJzZGF5LCBTZXB0ZW1iZXIgMTAsIDIwMTU8c3BhbiBjbGFzcz0iIj4mbmJz cDs8L3NwYW4+PC90ZD48L3RyPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6MjBweDttYXJnaW46MHB4 IiBjbGFzcz0iIj48dGQgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkO3dvcmQtYnJlYWs6bm9y bWFsO2ZvbnQtc2l6ZToxNXB4O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOnJnYigxMDIsMTAyLDEw Mik7cGFkZGluZzowcHgiIGNsYXNzPSIiPjExOjAwIGFtJm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNw O0Vhc3Rlcm4gRGF5bGlnaHQgVGltZSAoTmV3IFlvcmssIEdNVC0wNDowMCkmbmJzcDsmbmJzcDt8 Jm5ic3A7Jm5ic3A7MSBocjxzcGFuIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48L3RkPjwvdHI+PC90 Ym9keT48L3RhYmxlPjx0YWJsZSBzdHlsZT0iYm9yZGVyLWNvbGxhcHNlOnNlcGFyYXRlO2JvcmRl cjowcHggd2hpdGU7Ym9yZGVyLXNwYWNpbmc6MHB4O3dpZHRoOjEwMCUhaW1wb3J0YW50O21heC13 aWR0aDo1MjVweCFpbXBvcnRhbnQ7bWluLXdpZHRoOjI3OXB4IWltcG9ydGFudCIgY2xhc3M9IiI+ PHRib2R5IGNsYXNzPSIiPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6MjBweCIgY2xhc3M9IiI+PHRk IHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZDt3b3JkLWJyZWFrOm5vcm1hbDtmb250LXNpemU6 MTVweDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpyZ2IoMTAyLDEwMiwxMDIpO3BhZGRpbmc6MHB4 O2hlaWdodDoyMHB4IiBjbGFzcz0iIj4mbmJzcDs8L3RkPjwvdHI+PC90Ym9keT48L3RhYmxlPjx0 YWJsZSBzdHlsZT0iYm9yZGVyLWNvbGxhcHNlOnNlcGFyYXRlO2JvcmRlcjowcHggd2hpdGU7Ym9y ZGVyLXNwYWNpbmc6MHB4O3dpZHRoOmF1dG8haW1wb3J0YW50O21heC13aWR0aDo1MjVweCFpbXBv cnRhbnQ7bWluLXdpZHRoOjI3OXB4IWltcG9ydGFudCIgY2xhc3M9IiI+PHRib2R5IGNsYXNzPSIi Pjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6MjBweCIgY2xhc3M9IiI+PHRkIHN0eWxlPSJ3b3JkLXdy YXA6YnJlYWstd29yZDt3b3JkLWJyZWFrOm5vcm1hbDtmb250LXNpemU6MTZweDtmb250LWZhbWls eTpBcmlhbDtjb2xvcjpyZ2IoMCwxNzUsMjQ5KTtwYWRkaW5nOjBweCIgY2xhc3M9IiI+PGEgaHJl Zj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTU0YzdiY2JlZDg0YTA4 ZGM3OGZiYTEyOGQ1MDBmOGMwIiBzdHlsZT0iZm9udC1zaXplOjE2cHg7Zm9udC1mYW1pbHk6QXJp YWw7Y29sb3I6cmdiKDAsMTc1LDI0OSk7cGFkZGluZzowcHg7dGV4dC1kZWNvcmF0aW9uOm5vbmUi IHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj48YiBjbGFzcz0iIj5Kb2luIFdlYkV4IG1lZXRpbmc8 L2I+PC9hPjwvdGQ+PC90cj48L3Rib2R5PjwvdGFibGU+PHRhYmxlIHN0eWxlPSJib3JkZXItY29s bGFwc2U6c2VwYXJhdGU7Ym9yZGVyOjBweCB3aGl0ZTtib3JkZXItc3BhY2luZzowcHg7d2lkdGg6 YXV0byFpbXBvcnRhbnQ7bWF4LXdpZHRoOjUyNXB4IWltcG9ydGFudDttaW4td2lkdGg6Mjc5cHgh aW1wb3J0YW50IiBjbGFzcz0iIj48dGJvZHkgY2xhc3M9IiI+PHRyIHN0eWxlPSJsaW5lLWhlaWdo dDoyMHB4O21hcmdpbjowcHgiIGNsYXNzPSIiPjx0ZCBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdv cmQ7d29yZC1icmVhazpub3JtYWw7Zm9udC1zaXplOjE1cHg7Zm9udC1mYW1pbHk6QXJpYWw7Y29s b3I6cmdiKDEwMiwxMDIsMTAyKTtwYWRkaW5nOjBweCA1cHggMHB4IDBweCIgY2xhc3M9IiI+TWVl dGluZyBudW1iZXI6PC90ZD48dGQgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkO3dvcmQtYnJl YWs6bm9ybWFsO2ZvbnQtc2l6ZToxNXB4O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOnJnYigxMDIs MTAyLDEwMik7cGFkZGluZzowcHgiIGNsYXNzPSIiPjY0NSA3MzIgMjc3PHNwYW4gY2xhc3M9IiI+ Jm5ic3A7PC9zcGFuPjwvdGQ+PC90cj48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OjIwcHgiIGNsYXNz PSIiPjx0ZCBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQ7d29yZC1icmVhazpub3JtYWw7Zm9u dC1zaXplOjE1cHg7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6cmdiKDEwMiwxMDIsMTAyKTtwYWRk aW5nOjBweCA1cHggMHB4IDBweCIgY2xhc3M9IiI+TWVldGluZyBwYXNzd29yZDo8L3RkPjx0ZCBz dHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQ7d29yZC1icmVhazpub3JtYWw7Zm9udC1zaXplOjE1 cHg7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6cmdiKDEwMiwxMDIsMTAyKTtwYWRkaW5nOjBweCIg Y2xhc3M9IiI+MTIzNDwvdGQ+PC90cj48L3Rib2R5PjwvdGFibGU+PHRhYmxlIHN0eWxlPSJib3Jk ZXItY29sbGFwc2U6c2VwYXJhdGU7Ym9yZGVyOjBweCB3aGl0ZTtib3JkZXItc3BhY2luZzowcHg7 d2lkdGg6MTAwJSFpbXBvcnRhbnQ7bWF4LXdpZHRoOjUyNXB4IWltcG9ydGFudDttaW4td2lkdGg6 Mjc5cHghaW1wb3J0YW50IiBjbGFzcz0iIj48dGJvZHkgY2xhc3M9IiI+PHRyIHN0eWxlPSJsaW5l LWhlaWdodDoyMHB4IiBjbGFzcz0iIj48dGQgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkO3dv cmQtYnJlYWs6bm9ybWFsO2ZvbnQtc2l6ZToxNXB4O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOnJn YigxMDIsMTAyLDEwMik7cGFkZGluZzowcHg7aGVpZ2h0OjIwcHgiIGNsYXNzPSIiPiZuYnNwOzwv dGQ+PC90cj48L3Rib2R5PjwvdGFibGU+PHRhYmxlIHN0eWxlPSJib3JkZXItY29sbGFwc2U6c2Vw YXJhdGU7Ym9yZGVyOjBweCB3aGl0ZTtib3JkZXItc3BhY2luZzowcHg7d2lkdGg6MTAwJSFpbXBv cnRhbnQ7bWF4LXdpZHRoOjUyNXB4IWltcG9ydGFudDttaW4td2lkdGg6Mjc5cHghaW1wb3J0YW50 IiBjbGFzcz0iIj48dGJvZHkgY2xhc3M9IiI+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDoyMHB4IiBj bGFzcz0iIj48dGQgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkO3dvcmQtYnJlYWs6bm9ybWFs O2ZvbnQtc2l6ZToxNnB4O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOnJnYigxMDIsMTAyLDEwMik7 cGFkZGluZzowcHgiIGNsYXNzPSIiPjxiIGNsYXNzPSIiPkpvaW4gYnkgcGhvbmU8L2I+PC90ZD48 L3RyPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6MjBweDttYXJnaW46MHB4IiBjbGFzcz0iIj48dGQg c3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkO3dvcmQtYnJlYWs6bm9ybWFsO2ZvbnQtc2l6ZTox NXB4O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOnJnYigxMDIsMTAyLDEwMik7cGFkZGluZzowcHgi IGNsYXNzPSIiPjxiIGNsYXNzPSIiPjEtODc3LTY2OC00NDkzPC9iPiZuYnNwO0NhbGwtaW4gdG9s bCBmcmVlIG51bWJlciAoVVMvQ2FuYWRhKTwvdGQ+PC90cj48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0 OjIwcHg7bWFyZ2luOjBweCIgY2xhc3M9IiI+PHRkIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29y ZDt3b3JkLWJyZWFrOm5vcm1hbDtmb250LXNpemU6MTVweDtmb250LWZhbWlseTpBcmlhbDtjb2xv cjpyZ2IoMTAyLDEwMiwxMDIpO3BhZGRpbmc6MHB4IiBjbGFzcz0iIj48YiBjbGFzcz0iIj4xLTY1 MC00NzktMzIwODwvYj4mbmJzcDtDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpPC90ZD48 L3RyPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6MjBweDttYXJnaW46MHB4IiBjbGFzcz0iIj48dGQg c3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkO3dvcmQtYnJlYWs6bm9ybWFsO2ZvbnQtc2l6ZTox NXB4O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOnJnYigxMDIsMTAyLDEwMik7cGFkZGluZzowcHgi IGNsYXNzPSIiPkFjY2VzcyBjb2RlOiZuYnNwOzY0NSA3MzIgMjc3PC90ZD48L3RyPjx0ciBzdHls ZT0ibGluZS1oZWlnaHQ6MjBweDttYXJnaW46MHB4IiBjbGFzcz0iIj48dGQgc3R5bGU9IndvcmQt d3JhcDpicmVhay13b3JkO3dvcmQtYnJlYWs6bm9ybWFsO2ZvbnQtc2l6ZToxNXB4O2ZvbnQtZmFt aWx5OkFyaWFsO2NvbG9yOnJnYigxMDIsMTAyLDEwMik7cGFkZGluZzowcHgiIGNsYXNzPSIiPjxh IGhyZWY9Imh0dHA6Ly93d3cud2ViZXguY29tL3BkZi90b2xsZnJlZV9yZXN0cmljdGlvbnMucGRm IiBzdHlsZT0iZm9udC1zaXplOjEzcHg7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6cmdiKDAsMTc1 LDI0OSk7cGFkZGluZzowcHg7dGV4dC1kZWNvcmF0aW9uOm5vbmUiIHRhcmdldD0iX2JsYW5rIiBj bGFzcz0iIj5Ub2xsLWZyZWUgY2FsbGluZyByZXN0cmljdGlvbnM8L2E+PC90ZD48L3RyPjwvdGJv ZHk+PC90YWJsZT48dGFibGUgc3R5bGU9ImJvcmRlci1jb2xsYXBzZTpzZXBhcmF0ZTtib3JkZXI6 MHB4IHdoaXRlO2JvcmRlci1zcGFjaW5nOjBweDt3aWR0aDoxMDAlIWltcG9ydGFudDttYXgtd2lk dGg6NTI1cHghaW1wb3J0YW50O21pbi13aWR0aDoyNzlweCFpbXBvcnRhbnQiIGNsYXNzPSIiPjx0 Ym9keSBjbGFzcz0iIj48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OjIwcHgiIGNsYXNzPSIiPjx0ZCBz dHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQ7d29yZC1icmVhazpub3JtYWw7Zm9udC1zaXplOjE1 cHg7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6cmdiKDEwMiwxMDIsMTAyKTtwYWRkaW5nOjBweDto ZWlnaHQ6MjBweCIgY2xhc3M9IiI+Jm5ic3A7PC90ZD48L3RyPjwvdGJvZHk+PC90YWJsZT48dGFi bGUgc3R5bGU9ImJvcmRlci1jb2xsYXBzZTpzZXBhcmF0ZTtib3JkZXI6MHB4IHdoaXRlO2JvcmRl ci1zcGFjaW5nOjBweDt3aWR0aDoxMDAlIWltcG9ydGFudDttYXgtd2lkdGg6NTI1cHghaW1wb3J0 YW50O21pbi13aWR0aDoyNzlweCFpbXBvcnRhbnQiIGNsYXNzPSIiPjx0Ym9keSBjbGFzcz0iIj48 dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OjIwcHgiIGNsYXNzPSIiPjx0ZCBzdHlsZT0id29yZC13cmFw OmJyZWFrLXdvcmQ7d29yZC1icmVhazpub3JtYWw7Zm9udC1zaXplOjEzcHg7Zm9udC1mYW1pbHk6 QXJpYWw7Y29sb3I6cmdiKDEwMiwxMDIsMTAyKTtwYWRkaW5nOjBweCIgY2xhc3M9IiI+PGEgaHJl Zj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTE3MDg2ZDZiOTgxMGEy NzIyYzVkYzhjNjRlYzc5NWI5IiBzdHlsZT0iZm9udC1zaXplOjEzcHg7Zm9udC1mYW1pbHk6QXJp YWw7Y29sb3I6cmdiKDAsMTc1LDI0OSk7cGFkZGluZzowcHg7dGV4dC1kZWNvcmF0aW9uOm5vbmUi IHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5BZGQgdGhpcyBtZWV0aW5nPC9hPjxzcGFuIGNsYXNz PSIiPiZuYnNwOzwvc3Bhbj50byB5b3VyIGNhbGVuZGFyLjwvdGQ+PC90cj48L3Rib2R5PjwvdGFi bGU+PHRhYmxlIHN0eWxlPSJib3JkZXItY29sbGFwc2U6c2VwYXJhdGU7Ym9yZGVyOjBweCB3aGl0 ZTtib3JkZXItc3BhY2luZzowcHg7d2lkdGg6MTAwJSFpbXBvcnRhbnQ7bWF4LXdpZHRoOjUyNXB4 IWltcG9ydGFudDttaW4td2lkdGg6Mjc5cHghaW1wb3J0YW50IiBjbGFzcz0iIj48dGJvZHkgY2xh c3M9IiI+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDoyMHB4IiBjbGFzcz0iIj48dGQgc3R5bGU9Indv cmQtd3JhcDpicmVhay13b3JkO3dvcmQtYnJlYWs6bm9ybWFsO2ZvbnQtc2l6ZToxNXB4O2ZvbnQt ZmFtaWx5OkFyaWFsO2NvbG9yOnJnYigxMDIsMTAyLDEwMik7cGFkZGluZzowcHg7aGVpZ2h0OjIw cHgiIGNsYXNzPSIiPiZuYnNwOzwvdGQ+PC90cj48L3Rib2R5PjwvdGFibGU+PHRhYmxlIHN0eWxl PSJib3JkZXItY29sbGFwc2U6c2VwYXJhdGU7Ym9yZGVyOjBweCB3aGl0ZTtib3JkZXItc3BhY2lu ZzowcHg7d2lkdGg6MTAwJSFpbXBvcnRhbnQ7bWF4LXdpZHRoOjUyNXB4IWltcG9ydGFudDttaW4t d2lkdGg6Mjc5cHghaW1wb3J0YW50IiBjbGFzcz0iIj48dGJvZHkgY2xhc3M9IiI+PHRyIHN0eWxl PSJsaW5lLWhlaWdodDoyMHB4IiBjbGFzcz0iIj48dGQgc3R5bGU9IndvcmQtd3JhcDpicmVhay13 b3JkO3dvcmQtYnJlYWs6bm9ybWFsO2ZvbnQtc2l6ZToxM3B4O2ZvbnQtZmFtaWx5OkFyaWFsO2Nv bG9yOnJnYigxMDIsMTAyLDEwMik7cGFkZGluZzowcHgiIGNsYXNzPSIiPkNhbid0IGpvaW4gdGhl IG1lZXRpbmc/PHNwYW4gY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vaWV0 Zi53ZWJleC5jb20vaWV0Zi9tYyIgc3R5bGU9ImZvbnQtc2l6ZToxM3B4O2ZvbnQtZmFtaWx5OkFy aWFsO2NvbG9yOnJnYigwLDE3NSwyNDkpO3BhZGRpbmc6MHB4O3RleHQtZGVjb3JhdGlvbjpub25l IiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+Q29udGFjdCBzdXBwb3J0LjwvYT48L3RkPjwvdHI+ PC90Ym9keT48L3RhYmxlPjx0YWJsZSBzdHlsZT0iYm9yZGVyLWNvbGxhcHNlOnNlcGFyYXRlO2Jv cmRlcjowcHggd2hpdGU7Ym9yZGVyLXNwYWNpbmc6MHB4O3dpZHRoOjEwMCUhaW1wb3J0YW50O21h eC13aWR0aDo1MjVweCFpbXBvcnRhbnQ7bWluLXdpZHRoOjI3OXB4IWltcG9ydGFudCIgY2xhc3M9 IiI+PHRib2R5IGNsYXNzPSIiPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6MTBweCIgY2xhc3M9IiI+ PHRkIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZDt3b3JkLWJyZWFrOm5vcm1hbDtmb250LXNp emU6MTVweDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpyZ2IoMTAyLDEwMiwxMDIpO3BhZGRpbmc6 MHB4O2hlaWdodDoxMHB4IiBjbGFzcz0iIj4mbmJzcDs8L3RkPjwvdHI+PC90Ym9keT48L3RhYmxl Pjx0YWJsZSBzdHlsZT0iYm9yZGVyLWNvbGxhcHNlOnNlcGFyYXRlO2JvcmRlcjowcHggd2hpdGU7 Ym9yZGVyLXNwYWNpbmc6MHB4O3dpZHRoOjEwMCUhaW1wb3J0YW50O21heC13aWR0aDo1MjVweCFp bXBvcnRhbnQ7bWluLXdpZHRoOjI3OXB4IWltcG9ydGFudCIgY2xhc3M9IiI+PHRib2R5IGNsYXNz PSIiPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6MjBweCIgY2xhc3M9IiI+PHRkIHN0eWxlPSJ3b3Jk LXdyYXA6YnJlYWstd29yZDt3b3JkLWJyZWFrOm5vcm1hbDtmb250LXNpemU6MTJweDtmb250LWZh bWlseTpBcmlhbDtjb2xvcjpyZ2IoMTYwLDE2MCwxNjApO3BhZGRpbmc6MHB4IiBjbGFzcz0iIj5J TVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViRXggc2VydmljZSBhbGxv d3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRv IGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVy LiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBz dWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwg ZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNl c3Npb24uPC90ZD48L3RyPjwvdGJvZHk+PC90YWJsZT48L3RkPjwvdHI+PC90Ym9keT48L3RhYmxl PjwvdGQ+PC90cj48L3Rib2R5PjwvdGFibGU+PGJyIGNsYXNzPSIiPjxmaWVsZHNldCBjbGFzcz0i Ij48L2ZpZWxkc2V0PjxiciBjbGFzcz0iIj48cHJlIGNsYXNzPSIiPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQo8YSBo cmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIiBzdHlsZT0iZm9udC1zaXplOjE1cHg7Zm9udC1m YW1pbHk6QXJpYWw7Y29sb3I6cmdiKDEwMiwxMDIsMTAyKTtwYWRkaW5nOjBweCIgdGFyZ2V0PSJf YmxhbmsiIGNsYXNzPSIiPm5ldG1vZEBpZXRmLm9yZzwvYT4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kIiBzdHlsZT0iZm9udC1zaXplOjE1cHg7 Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6cmdiKDEwMiwxMDIsMTAyKTtwYWRkaW5nOjBweCIgdGFy Z2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbmV0bW9kPC9hPg0KPC9wcmU+PC9ibG9ja3F1b3RlPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6 SGVsdmV0aWNhO2ZvbnQtc2l6ZToxNnB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudDpu b3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2xldHRlci1zcGFjaW5nOm5vcm1hbDtsaW5lLWhlaWdo dDpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zvcm06 bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweDtiYWNrZ3JvdW5kLWNvbG9y OnJnYigyNTUsMjU1LDI1NSkiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpIZWx2 ZXRpY2E7Zm9udC1zaXplOjE2cHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50Om5vcm1h bDtmb250LXdlaWdodDpub3JtYWw7bGV0dGVyLXNwYWNpbmc6bm9ybWFsO2xpbmUtaGVpZ2h0Om5v cm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpub25l O3doaXRlLXNwYWNlOm5vcm1hbDt3b3JkLXNwYWNpbmc6MHB4O2JhY2tncm91bmQtY29sb3I6cmdi KDI1NSwyNTUsMjU1KTtmbG9hdDpub25lO2Rpc3BsYXk6aW5saW5lIWltcG9ydGFudCIgY2xhc3M9 IiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+ PGJyIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2E7Zm9udC1zaXplOjE2cHg7Zm9udC1zdHls ZTpub3JtYWw7Zm9udC12YXJpYW50Om5vcm1hbDtmb250LXdlaWdodDpub3JtYWw7bGV0dGVyLXNw YWNpbmc6bm9ybWFsO2xpbmUtaGVpZ2h0Om5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5k ZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNwYWNlOm5vcm1hbDt3b3JkLXNwYWNp bmc6MHB4O2JhY2tncm91bmQtY29sb3I6cmdiKDI1NSwyNTUsMjU1KSIgY2xhc3M9IiI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYTtmb250LXNpemU6MTZweDtmb250LXN0eWxlOm5v cm1hbDtmb250LXZhcmlhbnQ6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtsZXR0ZXItc3BhY2lu Zzpub3JtYWw7bGluZS1oZWlnaHQ6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4dC1pbmRlbnQ6 MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6bm9ybWFsO3dvcmQtc3BhY2luZzow cHg7YmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1NSwyNTUpO2Zsb2F0Om5vbmU7ZGlzcGxheTpp bmxpbmUhaW1wb3J0YW50IiBjbGFzcz0iIj5uZXRtb2QgbWFpbGluZyBsaXN0PC9zcGFuPjxiciBz dHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhO2ZvbnQtc2l6ZToxNnB4O2ZvbnQtc3R5bGU6bm9y bWFsO2ZvbnQtdmFyaWFudDpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2xldHRlci1zcGFjaW5n Om5vcm1hbDtsaW5lLWhlaWdodDpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDow cHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBw eDtiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1LDI1NSkiIGNsYXNzPSIiPjxhIGhyZWY9Im1h aWx0bzpuZXRtb2RAaWV0Zi5vcmciIHN0eWxlPSJmb250LXNpemU6MTVweDtmb250LWZhbWlseTpB cmlhbDtjb2xvcjpyZ2IoMTAyLDEwMiwxMDIpO3BhZGRpbmc6MHB4O2ZvbnQtc3R5bGU6bm9ybWFs O2ZvbnQtdmFyaWFudDpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2xldHRlci1zcGFjaW5nOm5v cm1hbDtsaW5lLWhlaWdodDpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7 dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweDti YWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1LDI1NSkiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0i Ij5uZXRtb2RAaWV0Zi5vcmc8L2E+PGJyIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2E7Zm9u dC1zaXplOjE2cHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50Om5vcm1hbDtmb250LXdl aWdodDpub3JtYWw7bGV0dGVyLXNwYWNpbmc6bm9ybWFsO2xpbmUtaGVpZ2h0Om5vcm1hbDt0ZXh0 LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNw YWNlOm5vcm1hbDt3b3JkLXNwYWNpbmc6MHB4O2JhY2tncm91bmQtY29sb3I6cmdiKDI1NSwyNTUs MjU1KSIgY2xhc3M9IiI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9uZXRtb2QiIHN0eWxlPSJmb250LXNpemU6MTVweDtmb250LWZhbWlseTpBcmlhbDtjb2xv cjpyZ2IoMTAyLDEwMiwxMDIpO3BhZGRpbmc6MHB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFy aWFudDpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2xldHRlci1zcGFjaW5nOm5vcm1hbDtsaW5l LWhlaWdodDpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFu c2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweDtiYWNrZ3JvdW5k LWNvbG9yOnJnYigyNTUsMjU1LDI1NSkiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZDwvYT48YnIgc3R5bGU9ImZvbnQt ZmFtaWx5OkhlbHZldGljYTtmb250LXNpemU6MTZweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXZh cmlhbnQ6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtsZXR0ZXItc3BhY2luZzpub3JtYWw7bGlu ZS1oZWlnaHQ6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4dC1pbmRlbnQ6MHB4O3RleHQtdHJh bnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6bm9ybWFsO3dvcmQtc3BhY2luZzowcHg7YmFja2dyb3Vu ZC1jb2xvcjpyZ2IoMjU1LDI1NSwyNTUpIiBjbGFzcz0iIj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9k aXY+PGJyIGNsYXNzPSIiPjwvZGl2PjxiciBjbGFzcz0iIj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCm5ldG1vZCBtYWlsaW5nIGxp c3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayIgY2xhc3M9IiI+bmV0bW9kQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kIiByZWw9Im5v cmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL25ldG1vZDwvYT48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+PC9i bG9ja3F1b3RlPjwvZGl2PjxiciBjbGFzcz0iIj48L2Rpdj48L2Rpdj4NCjwvZGl2PjwvYmxvY2tx dW90ZT48L2Rpdj48YnIgY2xhc3M9IiI+PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2PjxiciBjbGFz cz0iIj48L2Rpdj48L2Rpdj4NCjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48YnIgY2xhc3M9IiI+ PC9kaXY+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+PHNwYW4+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PGJyPjxz cGFuPm5ldG1vZCBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyPjxzcGFuPjxhIGhyZWY9Im1haWx0bzpu ZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT48L3NwYW4+PGJyPjxzcGFuPjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZDwvYT48L3NwYW4+PGJyPjwvZGl2 PjwvYmxvY2txdW90ZT48L2JvZHk+PC9odG1sPg== --Apple-Mail-EF8F0F39-FBC9-42AB-8BDF-994576F6A73F-- --_04805805-1edd-42d5-8437-3fbce9f4b2ff_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --_04805805-1edd-42d5-8437-3fbce9f4b2ff_-- From nobody Thu Aug 13 15:32:11 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3179F1B3B9F for ; Thu, 13 Aug 2015 15:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.86 X-Spam-Level: X-Spam-Status: No, score=-5.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmOxmahOBePA for ; Thu, 13 Aug 2015 15:32:09 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 007921B3B84 for ; Thu, 13 Aug 2015 15:32:09 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id BFA131557; Fri, 14 Aug 2015 00:32: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 xJR9Ph87nnaU; Fri, 14 Aug 2015 00:32:06 +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, 14 Aug 2015 00:32:06 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id B2F712004E; Fri, 14 Aug 2015 00:32:06 +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 syt0s0PdROIN; Fri, 14 Aug 2015 00:32: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 AC95520048; Fri, 14 Aug 2015 00:32:04 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 75597362F0D8; Fri, 14 Aug 2015 00:32:01 +0200 (CEST) Date: Fri, 14 Aug 2015 00:32:00 +0200 From: Juergen Schoenwaelder To: Nadeau Thomas Message-ID: <20150813223200.GB23633@elstar.local> Mail-Followup-To: Nadeau Thomas , Andy Bierman , "netmod-chairs@tools.ietf.org" , "netmod@ietf.org" References: <1516231808.93378.1438887834598.JavaMail.nobody@jva2tc202.webex.com> <55C4D830.8030601@cisco.com> <95032778-8873-4B5A-8CE6-D74CD77AAD13@lucidvision.com> <958632F2-A758-4EC0-8D92-0B6C88DE187A@lucidvision.com> <407ACE9C-C636-496E-B19B-2EF11ED0C34A@lucidvision.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <407ACE9C-C636-496E-B19B-2EF11ED0C34A@lucidvision.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod-chairs@tools.ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] WebEx meeting invitation: NETMOD Interm meeting on OpenConfig X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 22:32:10 -0000 On Thu, Aug 13, 2015 at 04:44:00PM -0400, Nadeau Thomas wrote: > > That is how we do the Yang 1.1 design team work right? The mini-team > makes a recommendation and if no one objects, it goes forward. Seems > like the same thing to me. > A few things to clarify: - There is no YANG 1.1 design team. There are virtual interim meetings that are open to everyone who wants to participate. Yes, there is a core group of people who participate regularly and are deeply engaged. But this does not mean there is an official design team. - There was WG consensus to work on YANG 1.1 and that consensus has become part of the charter of the NETMOD WG. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Aug 13 16:44:54 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D661A1ACEF6 for ; Thu, 13 Aug 2015 16:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 fhEGDHGIhKYB for ; Thu, 13 Aug 2015 16:44:49 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0721.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::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 9007B1ACEEF for ; Thu, 13 Aug 2015 16:44:48 -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.225.19; Thu, 13 Aug 2015 23:44:27 +0000 Received: from BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.71]) by BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.71]) with mapi id 15.01.0225.018; Thu, 13 Aug 2015 23:44:27 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: Draft minutes for IETF 93 meetings Thread-Index: AQHQ1iH9nEutEpO3mUSocFSeKqDmuQ== Date: Thu, 13 Aug 2015 23:44:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.11] x-microsoft-exchange-diagnostics: 1; BN1PR05MB453; 5:O/CRw/SBIV2ntdAqHP3UrczX7KmNOo4yiasm7Ed/Sh6btl7ZgGSWIFQT/6JLwbTUa9oFjBAZyhpzlp6zFuC/Ba8RikHxF6oB33faXAXk6fvb3WYUqMdf2FeFF3r+yNJQ3oR7HE23zAVx5CnTci9Jbw==; 24:MoNw2GlHZb81vklykyiHxycWTCH2CPMRIZf6y41eT+zSSKXiFk1Th8WiMet+iKir4F+d5YraMfSIG1G9h/uW7vJHRoJKQsBXfd3eMyfI9Bk=; 20:5V2NUQi2NexTP9hdBmMEYZNEUZUzVN/L6yEW/ym9sog1i8I1NncTRDSmwfWhgKH83Jftkg3gByOne9LppyVJnQ== 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)(5005006)(3002001); SRVR:BN1PR05MB453; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB453; x-forefront-prvs: 0667289FF8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(2351001)(122556002)(87936001)(64706001)(5002640100001)(2656002)(189998001)(77156002)(450100001)(46102003)(68736005)(36756003)(62966003)(5001830100001)(83506001)(99286002)(229853001)(110136002)(105586002)(5001860100001)(106356001)(2900100001)(107886002)(5001960100002)(106116001)(66066001)(16236675004)(10400500002)(97736004)(81156007)(102836002)(4001350100001)(4001540100001)(92566002)(558084003)(2501003)(54356999)(5890100001)(50986999)(99936001)(40100003)(86362001)(101416001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB453; H:BN1PR05MB456.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/mixed; boundary="_004_D1F2A34CCC006kwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Aug 2015 23:44:27.4959 (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: [netmod] Draft minutes for IETF 93 meetings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 23:44:53 -0000 --_004_D1F2A34CCC006kwatsenjunipernet_ Content-Type: multipart/alternative; boundary="_000_D1F2A34CCC006kwatsenjunipernet_" --_000_D1F2A34CCC006kwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please provide comments/corrections on the attached draft minutes. The updated minutes will be uploaded next Thursday - August 20. Huge thanks to scribes Carl Moberg and Jason Sterne! Kent --_000_D1F2A34CCC006kwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

Please provide comments/corrections on th= e attached draft minutes. 
The updated minutes will be uploaded next= Thursday - August 20.

Huge thanks to scribes Carl Moberg and Jason Sterne!

Kent


--_000_D1F2A34CCC006kwatsenjunipernet_-- --_004_D1F2A34CCC006kwatsenjunipernet_ Content-Type: text/plain; name="netmod-ietf93-minutes.txt" Content-Description: netmod-ietf93-minutes.txt Content-Disposition: attachment; filename="netmod-ietf93-minutes.txt"; size=16064; creation-date="Thu, 13 Aug 2015 23:44:27 GMT"; modification-date="Thu, 13 Aug 2015 23:44:27 GMT" Content-ID: <4CC6333EC7A7894A81F8C67F6ADB8888@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 TkVUTU9EIFdHIEFnZW5kYSBmb3IgSUVURiA5MyAoUHJhZ3VlKQpDaGFpcnM6IFRvbSBOYWRlYXUs IEtlbnQgV2F0c2VuLCBhbmQgSnVlcmdlbiBTY2hvZW53YWVsZGVyCgoKW0FDXSAgQXNlZW0gQ2hv dWRoYXJ5CltBTF0gIEFjZWUgTGluZGVtCltCQ10gIEJlbm9pdCBDbGFpc2UKW0JGXSAgQmlsbCBG ZW5uZXIKW0NNXSAgQ2FybCBNb2JlcmcKW0RCXSAgRGVhbiBCb2dkYW5vdmljCltHSF0gIEdpbGVz IEhlcm9uCltHUF0gIEdsZW4gUGFyc29ucwpbSkpdICBKb2VsIEphZWdnbGkKW0pTXSAgSnVlcmdl biBTY2hvZW53YWVsZGVyCltKUzJdIEphc29uIFN0ZXJuZQpbS1ddICBLZW50IFdhdHNlbgpbTExd ICBMYWRpc2xhdiBMaG90a2EKW0w/XSAgTHVjeSA/CltMPzJdIExvdWthcyA/CltNQV0gIE1pY2hh ZWwgQWJyYW1zCltOU10gIE5vcm0gU3RyYWhsZQpbUkVdICBSRkMgRWRpdG9yCltSS10gIFJhZGVr IEtyZWpjaQpbUlddICBSb2IgV2lsdG9uCltQR10gIFByYXZpbiBHb2hpdGUKW1M/XSAgU2FtID8K W1ROXSAgVG9tIE5hZGVhdQpbWD9dICBYaWVuIChmcm9tIEh1YXdlaSkKCgpNT05EQVksIEp1bHkg MjAsIDIwMTUKMTg1MC0xOTUwICBBZnRlcm5vb24gU2Vzc2lvbiBJVgpHcmFuZCBIaWx0b24gQmFs bHJvb20KNjAgbWludXRlcyBvbiBORVRNT0QgTW9kZWxzCj09PT09PT09PT09PT09PT09PT09PT09 PT09PQoKNSBtaW46IEJsdWUgc2hlZXRzLCBOb3RlIHdlbGwsIFNjcmliZXMsIEFnZW5kYSBCYXNo aW5nIChDaGFpcnMpCgpDaGFydGVyZWQgaXRlbXM6CgoKMTUgbWluOiBkcmFmdC1pZXRmLW5ldG1v ZC1yb3V0aW5nLWNmZy0xOSAoTGFkaXNsYXYgTGhvdGthKQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCltMTF0gc3VnZ2VzdHMgdGhlIFdH IHRvIGZvY3VzIG9uIHN0YWJpbGl6aW5nIGFuZCBwdWJsaXNoaW5nIHRoZSBtb2RlbApbQUxdIGFn cmVlcyB0aGF0IHRoZSBXRyBzaG91bGQgZm9jdXMgb24gZ2V0dGluZyB0aGUgc3BlYyBwdWJsaXNo ZWQKW0JDXSBzdWdnZXN0cyB0aGF0IHdlIGhvbGQgdGhlIHNwZWNpZmljYXRpb24gc2hvcnQgb2Yg bGFzdCBjYWxsIHRvCiAgICAgZ2V0IHNvbWUgZWFybHkgZmVlZGJhY2sgZnJvbSBpbXBsZW1lbnRh dGlvbiBleHBlcmllbmNlCltMTF0gY29tbWVudHMgdGhhdCBzdGFiaWxpemluZyB0aGUgZHJhZnQg d2lsbCBhbHNvIHN0YWJpbGl6ZSB0aGUgCiAgICAgbmFtZXNwYWNlIGZvciB0aGUgb3RoZXIgKDkg YW5kIGNvdW50aW5nKSBkcmFmdHMgdGhhdCByZWZlcmVuY2UKICAgICB0aGlzIGRyYWZ0IGFuZCBp dCdzIGRhdGEgZGVmaW5pdGlvbnMKW0FMXSBjb21tZW50cyB0aGF0IHRoZXJlIGFyZSBzb21lIGZl YXR1cmVzIChlLmcuIEVDTVAgYW5kIHJlY3Vyc2l2ZQogICAgIG5leHQgaG9wcykgdGhhdCBhcmUg bm90IGluIHRoZSBzcGVjaWZpY2F0aW9uIHlldApbREJdIGNvbW1lbnRzIHRoYXQgaWYgd2Uga2Vl cCB3YWl0aW5nIGZvciBzdXBwb3J0IGZvciBtb3JlIGFkdmFuY2VkCiAgICAgZmVhdHVyZXMsIHdl IHdpbGwgbmV2ZXIgYmUgYWJsZSB0byBwdWJsaXNoIGl0CltUTl0gY29tbWVudHMgdGhhdCB0aGUg bW9yZSBtb2RlbHMgd2UgYnVpbGQgdGhhdCBuZWVkIHRoaXMsIHRoZSBoYXJkZXIKICAgICBpdCB3 aWxsIGJlIHRvIG1ha2UgY2hhbmdlcywgbmVlZCB0byB0aGluayBvZiBhIGRpZmZlcmVudCBwbGFu IHRvCiAgICAgYXBwcm9hY2ggdGhpcwpbTExdIGNvbW1lbnRzIHRoYXQgdGhlIFlBTkcgdmVyc2lv bmluZyBtb2RlbHMgYXMgdGhleSBhcmUgcmlnaHQgbm93CiAgICAgaXMgaGFyZCB0byBob25vciBh cyB0aGUgY29tcGxleCBpbnRlcmRlcGVuZGVuY2llcyBncm93CltUTl0gY29tbWVudHMgdGhhdCB0 aGUgSUVTRyBtYXkgbmVlZCB0byBnbyBiYWNrIGFuZCBjb25zaWRlciB0aGUgCiAgICAgY29tcGxl eGl0eSBvZiB0aGUgY3VycmVudCBzaXR1YXRpb24KW0FMXSBjb21tZW50cyB0aGF0IGlmIHdlIGRv bid0IG5lZWQgSVB2NCBhbmQgSVB2NiB0byByZWZlcmVuY2UgCiAgICAgcm91dGluZyBpbnN0YW5j ZXMsIHRoYXQgd291bGQgYmUgYSBiZW5lZml0LCBzbyBSRkMgNzI3NyB3b3VsZG4ndAogICAgIG5l ZWQgdG8gY2hhbmdlLgoKCjEwIG1pbjogZHJhZnQtaWV0Zi1uZXRtb2Qtc3lzbG9nLW1vZGVsLTA0 IChQcmF2aW4gR29oaXRlKQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0KW0NNXSBhc2tzIGlmIHRoZXJlIGFyZSBhbnkga25vd24gaW1wbGVt ZW50YXRpb25zLCBQcmF2aW4gZG9lc24ndCBrbm93IGFueQpbUEddIHN1Z2dlc3RzIHRoYXQgd2Ug dGFrZSB0aGUgZHJhZnQgdG8gV0cgbGFzdCBjYWxsCltUTl0gYXNrZWQgUHJhdmluIHRvIHRha2Ug dGhlIGxhc3QgY2FsbCBxdWVzdGlvbiB0byB0aGUgbWFpbGluZyBsaXN0CgoKCjEwIG1pbjogZHJh ZnQtaWV0Zi1uZXRtb2QtYWNsLW1vZGVsLTAzIChEZWFuIEJvZ2Rhbm92aWMpCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCltUTl0gIGNvbW1l bnRlZCB0aGF0IHF1ZXN0aW9ucyBuZWVkcyB0byBiZSBhc2tlZCBhbHNvIG9uIHRoZSBtYWlsaW5n IGxpc3QKW0pTMl0gY29tbWVudGVkIHRoYXQgd2UgbmVlZCBtb3JlIHJvYnVzdCBkaXNjdXNzaW9u IG9uIHRoZSBtYWlsaW5nIGxpc3QgYXMKICAgICAgdGhlcmUgYXJlIGFsdGVybmF0aXZlcyB0byB0 aGUgY3VycmVudCBwcm9wb3NhbHMKW0pTMl0gd2FudHMgdG8gcHJvcG9zZSBhIHNlcGFyYXRlIGNv bnRhaW5lciBwZXIgYWRkcmVzcyBmYW1pbHkKW0pTMl0gY29tbWVudGVkIHRoYXQgdGhlcmUgaXMg dmFsdWUgaW4gb3BlcmF0b3IgaW5wdXQgb24gdGhpcyAoZS5nLiB0aGUKICAgICAgb3BlbmNvbmZp ZyB0ZWFtIG9yIG90aGVyIG9wZXJhdGlvbnMgcGVvcGxlKQpbREJdICBjb21tZW50ZWQgdGhhdCB0 aGVyZSB3YXMgc29tZSBpbnB1dCBmcm9tIG9wZXJhdG9ycyBkdXJpbmcgdGhlIAogICAgICBEYWxs YXMgbWVldGluZwoKCgpOb24tQ2hhcnRlcmVkIGl0ZW1zOgoKCjEwIG1pbjogZHJhZnQtYXNlY2hv dWQtbmV0bW9kLWRpZmZzZXJ2LW1vZGVsLTAzIChBc2VlbSBDaG91ZGhhcnkpCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCltO U10gc2F5cyB0aGF0IHRoZXJlIGFyZSBzdGlsbCBzb21lIGZ1bmRhbWVudGFsIGlzc3VlcyB0byBi ZSB3b3JrZWQgb3V0LCAKICAgICBlLmcuIGRpZmZlcmVudCBhcmNoaXRlY3R1cmVzIHJlcHJlc2Vu dGVkIGluIHRoZSBzYW1lIG1vZGVsCltBQ10gY29tbWVudHMgdGhhdCBpdCdzIHBlcmhhcHMgbm90 IHNvIG11Y2ggdGhlIHVuZGVybHlpbmcgYXJjaGl0ZWN0dXJlLCAKICAgICBidXQgZGlmZmVyZW50 IHVzZSBjYXNlcwpbPz9dIChtaWMgYXQgYmFjayBvZiByb29tKSBpc24ndCB0aGlzIGEgam9iIGZv ciB0d28gbW9kZWxzLCBhIG1vZGVsIHdoZXJlCiAgICAgeW91IGV4cHJlc3MgdGhlIGxpbWl0YXRp b25zIGFuZCBhIGdlbmVyaWMgbW9kZWwKW0FDXSBjb21tZW50cyB0aGF0IHRoaXMgY2FuIGJlIGFw cHJvYWNoZWQgdXNpbmcgaWYtZmVhdHVyZQpbVE5dIHN1Z2dlc3RzIHRvIGNhcnJ5IHRoaXMgcXVl c3Rpb24gYW5kIGRpc2N1c3Npb24gdG8gdGhlIG1haWxpbmcgbGlzdAoKCgo1IG1pbjogZHJhZnQt d2lsdG9uLW5ldG1vZC1pbnRmLWV4dC15YW5nLTAwICAoUm9iIFdpbHRvbikKNSBtaW46IGRyYWZ0 LXdpbHRvbi1uZXRtb2QtaW50Zi12bGFuLXlhbmctMDAgIChSb2IgV2lsdG9uKQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCltHUF0gY29t bWVudHMgdGhhdCBpdCBpcyBnb29kIHRoYXQgdGhlIGRyYWZ0IGlzIGxhYmVsZWQgYXMgY29tcGxl bWVudGFyeSAKICAgICB0byBJRUVFLCBidXQgdGhlIGNvbnRlbnQgc2VlbXMgdG8gc3VnZ2VzdCBv dGhlcndpc2UuCltHUF0gY29tbWVudHMgdGhhdCBmdXJ0aGVyIGludGVyYWN0aW9uIGFjcm9zcyBl LmcuIElFVEYsIE1FRiBhbmQgSUVFRQogICAgIHdvdWxkIGJlIGdvb2QKCgoKVFVFU0RBWSwgSnVs eSAyMSwgMjAxNQoxNTIwLTE3MjAgIEFmdGVybm9vbiBTZXNzaW9uIElJCkdyYW5kIEhpbHRvbiBC YWxscm9vbQoxMjAgbWludXRlcyBvbiBORVRNT0QgTGFuZ3VhZ2UKPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09Cgo1IG1pbjogQmx1ZSBzaGVldHMsIE5vdGUgd2VsbCwgU2NyaWJlcywgQWdl bmRhIEJhc2hpbmcgKENoYWlycykKCkNoYXJ0ZXJlZCBpdGVtczoKCgoyMCBtaW46IGRyYWZ0LWll dGYtbmV0bW9kLXJmYzYwMjBiaXMtMDYgIChKdWVyZ2VuIFNjaG9lbndhZWxkZXIpCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0g IApbQUJdIGNvbW1lbnRzIHRoYXQgdGhlIGFzc3VtcHRpb24gdGhhdCAxLjEgY2FuIGltcG9ydCAx LjAgbmVlZHMgdG8gYmUKICAgICBjbGFyaWZpZWQgaW4gdGVybXMgb2YgdGhlIHZhbGlkYXRpb24g cnVsZXMgYXBwbGllZCB0byB0aGUgbW9kZXMuCltKU10gY29tbWVudHMgdGhhdCBBbmR5IHNob3Vs ZCBwcm92aWRlIGV4YW1wbGVzIG9uIHRoZSBtYWlsaW5nIGxpc3QgdG8KICAgICBwdXNoIHRoaXMg Zm9yd2FyZApbTExdIHN1Z2dlc3RzIHRoYXQgYW55IHRyYWlsaW5nIGlzc3VlcyBmb3IgMS4wIGNh biBiZSBjb3ZlcmVkIGJ5IDEuMCBFcnJhdGEKW0RCXSBPYnNvbGV0aW5nIDYwMjAgd2lsbCBtZWFu IGRyYWZ0cyBiYXNlZCBvbiAxLjAgbWF5IG5lZWQgdG8gYmUgcmV3b3JrZWQuCiAgICAgV2hhdCBz aG91bGQgd2UgZG8gd2l0aCBkcmFmdCBtb2RlbHMgdGhhdCBhcmUgd3JpdHRlbiBhcyAxLjAgY3Vy cmVudGx5PwpbREJdIGNvbW1lbnRzIHRoYXQgaGUgYWdyZWVzIHdpdGggYXV0aG9yIHRvIG5vdCBv YnNvbGV0ZSAxLjAuIFdlIGhhdmUgbWFueQogICAgIG1vZGVscyBpbiAxLjAgaGVhZGluZyB0b3dh cmRzLCBvciBpbiBsYXN0IGNhbGwKW0pTXSBjb21tZW50cyB0aGF0IHdlIG5lZWQgdG8gZGlzdGlu Z3Vpc2ggYmV0d2VlbiBub24tcHVibGlzaGVkIG1vZHVsZXMgYW5kCiAgICAgcHVibGlzaGVkIG1v ZHVsZXMuIEhvdyBwYWluZnVsIGlzIGl0IHJlYWxseSB0byAidXBncmFkZSIgbW9kdWxlcyB0aGF0 CiAgICAgYXJlIG5vdCBwdWJsaXNoZWQ/CltUTl0gYXNrcyBBRCAoQmVub2l0KSBmb3IgYWRkaXRp b25hbCBjbGFyaWZpY2F0aW9uIG9uIHdoZXRoZXIgdG8gcGFyawogICAgIGV4aXN0aW5nIHByZS1X RyBtb2R1bGVzIHdhaXRpbmcgZm9yIDEuMSBhbmQgdGhlbiBidW1wIHRoZW0gdXAuCiAgICAgQnJp bmcgdG8gbWFpbGluZyBsaXN0LgpbSlNdIGhvdyBtYW55IGNoYW5nZXMgd2lsbCBhY3R1YWxseSBi ZSByZXF1aXJlZCA/CltKSl0gd2Ugc2hvdWxkbid0IGhhdmUgdG8gZ28gYW5kIHVwZGF0ZSBSRkNz LiAgV2UgYXJlIG5vdCBsaWtlbHkgdG8gcmV2aXNlCiAgICAgYSBsYXJnZSBzZXQgb2YgZHJhZnRz IHRvIHJlZmVyZW5jZSAxLjEuCltHSF0gY29tbWVudHMgdGhhdCBoZSBzdXBwb3J0cyByZW1vdmlu ZyB0aGUgdGVybSAiTkVUQ09ORiIgZnJvbSB0aGUgdGl0bGUKICAgICBhcyB0aGVyZSBhcmUgc2V2 ZXJhbCBhY3Rpdml0aWVzLCBlLmcuIEkyUlMgd29ya2luZyBvbiBZQU5HCltBQl0gY29tbWVudHMg dGhhdCB0YWtpbmcgIk5FVENPTkYiIG91dCBvZiB0aGUgdGl0bGUgd2lsbCBub3QgaGVscCBzaW5j ZQogICAgIG11Y2ggb2YgY29udGVudCByZWZlciBORVRDT05GIGluY2x1ZGluZyBleGFtcGxlcwpb QUJdIHNob3VsZCB3ZSByZWFsbHkgdGFrZSBORVRDT05GIGV4YW1wbGVzIG91dCBvZiB0aGUgZG9j ID8gIFRoYXQgd2lsbAogICAgIGh1cnQgaW50ZXJvcGVyYWJpbGl0eS4KW1ROXSBob3cgYWJvdXQg d2UgbGVhdmUgdGhlbSBpbiBidXQgY2xhcmlmeSB0aGV5IGFyZSBqdXN0IE5DIGV4YW1wbGVzIGFu ZAogICAgIHRoZSBkb2MgaXNuJ3QgcHVyZWx5IGZvciBOQwpbQkNdIHdoYXQgYXJlIHdlIGdvaW5n IHRvIGRvIHdpdGggdGhlIGN1cnJlbnQgNjAyMCA/ICBMZWF2ZSBpdCB0aGVyZSA/CiAgICAgT2Jz b2xldGUgaXQgPyAtIGRlcGVuZHMgb24gaWYgNjAyMCB3aWxsIHJlbWFpbiBhY3RpdmUKW0pTXSBz aW5jZSBhbW91bnQgb2YgWUFORyBtb2R1bGVzIGlzIHJlbGF0aXZlbHkgc21hbGwsIHRoZXJlIGlz IGEgY2hhbmNlCiAgICAgdGhhdCBhbGwgd2lsbCBtb3ZlIHRvIDEuMSwgdGhpcyBtZWFucyB0aGF0 IHdlIGNvdWxkIHJldGlyZSA2MDIwCltKU10gV2Ugc2hvdWxkIGNhcnJ5IGZvcndhcmQgdGhlIElB TkEgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiBpbnRvIDYwMjBiaXMKW0pKXSBjb21tZW50cyB0aGF0 IHRoZSBjb25zaWRlcmF0aW9uIGlzIHNvbGVseSBmb3IgSUFOQSBpbnN0cnVjdGlvbnMsIHNvCiAg ICAgbm90IGltcG9ydGFudCB0aGF0IHRoZXJlIGFyZSBsaXZlIChub24taGlzdG9yaWNhbCkgZG9j dW1lbnRzIHdpdGgKICAgICB0aGUgY29uc2lkZXJhdGlvbnMgaW4gdGhlbS4KW0pKXSBhc2tzIGlm IGNvbmNsdXNpb24gaXMgdG8gcmVtb3ZlIElBTkEgY29uc2lkZXJhdGlvbiB0ZXh0LCBhbmQgVG9t CiAgICAgY29tbWVudHMgdGhhdCBpdCBzb3VuZHMgbGlrZSB3ZSBoYXZlIGFncmVlbWVudCBvbiB0 aGF0CltBQl0gYXNrcyBpZiB3ZSByZWFsbHkgc2hvdWxkIGdvIHRocm91Z2ggZXhpc3RpbmcgUkZD cyBhbmQgdXBkYXRlIHRoZW0sCiAgICAgaXMgdGhlcmUgcmVhbGx5IHZhbHVlIGluIHRoYXQ/CltL V10gY29tbWVudHMgdGhhdCwgdG8gQW5keSdzIHBvaW50LCB3ZSBjYW4gaW1wb3J0IDEuMCBtb2R1 bGVzIGZyb20gMS4xCiAgICAgbW9kdWxlcywgd2hpY2ggc2F5cyB0aGF0IHdlIG1heSBub3QgcmVx dWlyZSBzd2VlcGluZyB1cGdyYWRlcyBvZgogICAgIGV4aXN0aW5nIGRvY3VtZW50cwpbVE5dIGlm IHlvdSBkb24ndCBoYXZlIHRoZSBJRCBpdCBpcyAxLjAgIApbTD9dIChSRkMgZWRpdG9yPykgY29t bWVudHMgdGhhdCBpbiBvcmRlciB0byBwcm90ZWN0IFJGQyBlZGl0b3IgcmVzb3VyY2VzLAogICAg IHNlZSBpZiB3ZSBjYW4gYXZvaWQgbXVsdGktZG9jdW1lbnQgdXBkYXRlcwpbUkVdIChMdWN5Pykg ZG9uJ3QgbWFrZSBjaGFuZ2VzIGluIGFsbCB0aGVzZSBkb2NzLCBpZiB0aGVyZSB0dXJucyBvdXQg dG8KICAgICBiZSBhIHRyYW5zaXRpb24gaXNzdWUgdGhlbiB3cml0ZSBhIHRyYW5zaXRpb24gZHJh ZnQuCltSV10gYXNrcyBpZiBhIFlBTkcgbW9kdWxlIGNhbiBkZWNsYXJlIHN1cHBvcnQgZm9yICJk b24ndCBjYXJlIiwgCiAgICAgaS5lLiB2YWxpZCBhcyBib3RoIDEuMSBhbmQgMS4wPwpbREJdIGFz a3MgaWYgdGhlIHJlZmVyZW5jZSB0byAibmV3IG1vZHVsZXMiIGFwcGxpZXMgdG8gYWxsIG5vbi1w dWJsaXNoZWQKICAgICBkcmFmdHMsIG9yIGlmIHB1Ymxpc2hlZCwgcGVyaGFwcyBsYXRlLXZlcnNp b24gZHJhZnRzLCBzaG91bGQgYWxzbyBiZQogICAgIHVwZGF0ZWQKW0xMXSBjb21tZW50cyB0aGF0 IHdvcmsgb24gaGlzIGRyYWZ0cyB3aWxsIGJlIHVwZGF0ZWQgdG8gMS4xIHRvIGxldmVyYWdlCiAg ICAgdGhlIG5ldyBmZWF0dXJlcwpbVE5dIGNoZWNrcyB0aGUgcm9vbSBmb3Igb2JqZWN0aW9ucyBv biB0aGUgV0dzIGluc2lzdGluZyBvbiBZQU5HIDEuMSB0bwogICAgIHByb2dyZXNzIGRvY3VtZW50 cwpbVE5dIGRvZXMgYW55b25lIG9iamVjdCB0byBzYXlpbmcgdGhhdCBhbGwgbmV3IG1vZHVsZXMg bXVzdCBiZSAxLjEgPwpbQUJdIGNvbW1lbnRzIHRoYXQgdGhpcyByZXF1aXJlbWVudCB3aWxsIGhh dmUgc2lnbmlmaWNhbnQgaW1wYWN0IG9uIHRoZQogICAgIHRvb2xpbmcsIGFzIGUuZy4gcGFyc2Vy cyBhbmQgdmFsaWRhdG9ycyBtYXkgbm90IGJlIHJlYWR5IGZvciAxLjEKW0JGXSBjb21tZW50cyB0 aGF0IHRoaXMgY29tbWVudCBpcyBmaW5lIGZvciBJRVRGIG1vZHVsZXMsIGJ1dCBob3cgYWJvdXQK ICAgICB2ZW5kb3IgbW9kdWxlcyB0aGF0IG1heSByZWZlcmVuY2UgZS5nLiBpbnRlcmZhY2UtbW9k dWxlLiB3aWxsIHZlbmRvcgogICAgIG1vZGVscyBuZWVkIHRvIHVwZGF0ZSB0byB5YW5nIDEuMSA/ CltCRl0gY29tbWVudHMgdGhhdCBoZSBzdXBwb3J0cyBkZWNpc2lvbiB0byByZXF1aXJlIDEuMSB0 byBwcm9ncmVzcyBtb2R1bGVzCltHSF0gYXNrcyBpZiA2MDg3YmlzIHJlZmVyZW5jZXMgMS4xLCBy b29tIGFuc3dlcnMgeWVzLCBpdCBoYXMgYmVlbiB1cGRhdGVkCltKU10gbm90ZSB0aGF0IHlvdSBj YW4gcHVsbCBpbiBieSByZXZpc2lvbiBzbyBpZiB5b3Ugd2FudCBhbiBvbGRlciB2ZXJzaW9uCiAg ICAgeW91IGNhbiB1c2UgaXQKW0pTXSBhc2tzIHJvb20gd2hvIGlzIGluIGZhdm9yIG9mIG9ubGlu ZSBtZWV0aW5ncyB2cyBub3JtYWwgbWFpbGluZyBsaXN0CiAgICAgdHJhZmZpYy4gU2xpZ2h0bHkg aGlnaGVyIGludGVyZXN0IGluIHdlYmV4LW1lZXRpbmdzCgogIAoxNSBtaW46IGRyYWZ0LWlldGYt bmV0bW9kLXlhbmctanNvbi0wNCAoTGFkaXNsYXYgTGhvdGthKQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAKW0pTXSBJIHN1cHBvcnQgdGhl IHByb3Bvc2FsIGFib3V0IFhwYXRoICh0byByZWx5IG9uIDYwMjBiaXMpICAKW0pTXSBDb21tZW50 cyB0aGF0IHRoZXJlIG1pZ2h0IGJlIGEgbGl0dGxlIGhvbGUgdG8gcGx1ZyByZWdhcmRpbmcKICAg ICB0aGUgWFBhdGggZXhwcmVzc2lvbnMgZXZhbHVhdGVkIG92ZXIgSS1KU09OIGRhdGEKW1JLXSBJ IHRoaW5rIHdlIGNhbiB1c2UgdGhlIFJGQzIxMTkgdGV4dC4gIApbUktdIENvbW1lbnRzIHRoYXQg dGhlIHN1Z2dlc3RlZCB0ZXh0IGNoYW5nZSByZWdhcmRpbmcgbmFtZXNwYWNlCiAgICAgZW5jb2Rp bmcgcnVsZXMgd29ya3MgYmV0dGVyCgoKCgoxNSBtaW46IGRyYWZ0LWlldGYtbmV0bW9kLXlhbmct bWV0YWRhdGEtMDEgKExhZGlzbGF2IExob3RrYSkKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCltBQl0gdGhlIGludGVudCBvZiB0aGUg YW5ub3RhdGlvbiBzdGF0ZW1lbnRzIChyZWxhdGVkIHRvIGlzc3VlICMxKSBtZWFucyAKICAgICB5 b3UgY2FuJ3Qgd3JpdGUgYW4gZXh0ZW5zaW9uIHN0YXRlbWVudCB0aGF0IHVuZG9lcyBhbnl0aGlu ZyB0aGF0IAogICAgIGJhc2ljIHlhbmcgc3RhdGVtZW50cyBkby4gIFRoYXQgaXMsIHRoYXQgYXJl IGxpbWl0ZWQgdG8gdGhpbmdzIHRoYXQKICAgICBkbyBub3QgY2hhbmdlIG9yIGV4dGVuZCBleGlz dGluZyBZQU5HIHN0YXRlbWVudHMuCltKU10gc3VnZ2VzdHMgdGhhdCB3ZSBtYXkgYmUgbWl4aW5n IHRoaW5ncyB1cCwgY29tcGlsZXJzIGlnbm9yZSAKICAgICBub24tY29tcGxpYW50L3N1cHBvcnRl ZCBrZXl3b3JkcyBidXQgdGhlIG1lYW5pbmcgb2YgZXh0ZW5zaW9ucyBpcwogICAgIHJlbGF0ZWQg dG8gdGhlIHByb3RvY29sLCBub3QgYXMgcGFydCBvZiB0aGUgbW9kdWxlIHN0YXRlbWVudHMuICBB CiAgICAgY2xpZW50ICYgc2VydmVyIG5lZWQgdG8gYWdyZWUvbmVnb3RpYXRlIHdoZXRoZXIgYW4g ZXh0ZW5zaW9uIGlzCiAgICAgc3VwcG9ydGVkCltUTl0gd2Fzbid0IEFuZHkgc2F5aW5nIHRoYXQg YW4gYW5ub3RhdGlvbiBjYW4ndCB1bmRvIGZ1bmN0aW9uYWxpdHkgaW4KICAgICB0aGUgYmFzZSB5 YW5nIHNwZWMKW0FCXSBXaGF0IEp1ZXJnZW4gc2FpZCBpcyBjb3JyZWN0LiAgVGhlIGNsaWVudCBz aG91bGQgYmUgYWJsZSB0byBza2lwCiAgICAgb3ZlciBhdHRyaWJ1dGVzIGl0IGRvZXNuJ3Qga25v dyAob3IgaWYgaXQgaXMgc29tZXRoaW5nIGRlZmluZWQgbGlrZQogICAgIHRoaXMgdGhlbiB0aGV5 IGNhbiBwYXJzZSBpdCBidXQgbm90IHVzZSBpdCkuCltBQl0gd2UgZG9uJ3QgcmV0dXJuIG1ldGFk YXRhIHRoYXQgdGhlIGNsaWVudCBkaWRuJ3QgZXhwbGljaXRseSByZXF1ZXN0CltMTF0gd29uJ3Qg YSBjbGllbnQgdGhhdCBkb2Vzbid0IHVuZGVyc3RhbmQgLi4uIChtaXNzZWQgdGhlIHJlc3QpCltK U10gaG93IGRvIGNsaWVudHMgYXNrIGZvciBjZXJ0YWluIGFubm90YXRpb25zCltBQl0gd2UgYWRk IGxlYWYgcGFyYW1zIHRvIHRoZSBSUEMgKHdpdGgtb3duZXJzKS4gIEluIHlvdXIgY2FzZSB5b3Ug d291bGQKICAgICBoYXZlIHRvIGFzayBmb3IgdGhlIGRpc2FibGVkIG5vZGVzIChieSBkZWZhdWx0 IHRoZXkgYXJlIGhpZGRlbiB0byBhCiAgICAgbm9ybWFsIGNsaWVudCkuCltMRF0gd2UgbmVlZCB0 byBrbm93IHRoYXQgYm90aCBjbGllbnQgJiBzZXJ2ZXIgdW5kZXJzdGFuZCB0aGUgYW5ub3RhdGlv bnMgCltBQl0gd2Ugc2hvdWxkIGNoYXJ0ZXIgY29uZGl0aW9uYWwgZW5hYmxlbWVudApbSlNdIEp1 ZXJnZW4gY29tbWVudHMgdGhhdCBmb3IgZmluaXNoaW5nIHVwIHRoaXMgZG9jdW1lbnQgd2Ugc2hv dWxkIAogICAgIGRvY3VtZW50IHRoYXQgdGhlcmUgaXMgbm8gcHJvdG9jb2wgbmVnb3RpYXRpb24g YW5kIHBlb3BsZSBzaG91bGQKICAgICBwcm9jZWVkIHdpdGggY2FyZQpbS1ddIChyZSBhbm5vdGF0 ZSBlbnRpcmUgbGlzdCk6IGRvZXMgdGhpcyBtZWFuIEpTT04gY2FuJ3QgYW5ub3RhdGUgYW4KICAg ICBlbnRpcmUgbGlzdCBlaXRoZXIgPwpbTExdIGNvcnJlY3QKW0pTXSBjb21tZW50cyAob24gaXNz dWUgIzMsIGNvLWV4aXN0IHdpdGggZGF0YSBub2RlcykgdGhhdCBoZSBhZ3JlZXMgd2l0aAogICAg IHRoZSBhdXRob3IgdGhhdCBhbm5vdGF0aW9ucyBpbiBzZXBhcmF0ZSBtb2R1bGVzIHNob3VsZCBi ZSBhIGd1aWRlbGluZQogICAgIGluIGEgZ3VpZGVsaW5lcyBkb2N1bWVudCwgYW5kIG5vdCBlbmZv cmNlZAoKCiAgCjUgbWluOiBkcmFmdC1pZXRmLW5ldG1vZC1yZmM2MDg3YmlzLTA0ICAoQW5keSBC aWVybWFuKQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0KW0JDXSB3ZSBtYXkgbmVlZCBhIHNlY3Rpb24gd2l0aCBndWlkZWxpbmVzIGZvciBleHRl cm5hbCBlbnRpdGllcyAKICAgICAoZS5nLiBTRE9zLCBvcGVuIHNvdXJjZSBwcm9qZWN0cykgYXJv dW5kIGJlc3QgcHJhY3RpY2VzIHRvCiAgICAgcHVibGlzaCBZQU5HIG1vZGVscwpbREJdIHdlIG5l ZWQgZ3VpZGVsaW5lcyBvbiBob3cgdG8gZW5jb2RlIGV4YW1wbGVzIGluIGRyYWZ0cywgQW5keQog ICAgIG5lZWRzIG1vcmUgaW5wdXQgb24gZGV0YWlscwoKIAoKTm9uLUNoYXJ0ZXJlZCBpdGVtczoK CgoxNSBtaW46IFlBTkcgTW9kZWwgQ29vcmRpbmF0aW9uIEdyb3VwIChCZW5vaXQgQ2xhaXNlKSAg ICAKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0K W01BXSB3aGVyZSBkbyB3ZSBzdWJtaXQgYSBkcmFmdCBmb3IgYSBtb2RlbCB3aGVyZSB0aGVyZSBp c24ndCBhIGNsZWFyIFdHPwpbVE5dIGl0IGlzIE5FVE1PRCBpZiB0aGVyZSByZWFsbHkgaXMgbm8g b3RoZXIgcGxhY2UKW0JDXSByZWdhcmRsZXNzIG9mIHdoZXJlIGl0IGlzIGRvbmUgd2UgbmVlZCB0 byByaWdodCBleHBlcnRzCltMPzJdIGFza2VkIGlmIHRoZXJlIHdhcyBvdmVybGFwIGJldHdlZW4g dGhlIElFVEYgYW5kIE9ETCBZQU5HIG1vZHVsZXMKW0JDXSByZXNwb25kcyB0aGF0IGRhdGEgaXMg bm90IG5vcm1hbGl6ZWQgYW5kIGNvcnJlbGF0ZWQsIHNvIHRoZXJlIG1heQogICAgIGJlIGR1cGxp Y2F0ZXMuIFRoaXMgaXMgdGhlIHR5cGUgb2YgZGF0YSB0aGF0IHdlIG5lZWQuICBJIHdpbGwgY29t ZQogICAgIGJhY2sgdG8geW91IG9uIHRoaXMuCltLV10gbnVtYmVyIG9mIG1vZGVscyBpc24ndCBh bHdheXMgcmVsZXZhbnQuICBTb21lIHZlbmRvcnMgaGF2ZSBhIHNpbmdsZQogICAgIG1vZGVsIHRo YXQgaXMgdmVyeSBsYXJnZS4KWz8/XSBXaGF0IHdpbGwgd2UgZG8gYWJvdXQgT3BlbkRheWxpZ2h0 IG1vZGVscyB0aGF0IGFyZW4ndCBjb21pbmcgdG8gSUVURgpbQkNdIHdlIHNob3VsZG4ndCByZWFs bHkgZG8gbXVjaC4gIElmIE9ETCBwZW9wbGUgd2FudCB0byBzdWJtaXQgbW9kZWxzIHRvCiAgICAg SUVURiB0aGVuIGdyZWF0LiAgT3RoZXJ3aXNlIHRoZXJlIGlzbid0IHJlYWxseSBhbiBhbnN3ZXIu ICBXZSBoYXZlCiAgICAgaW50ZXJlc3QgaW4gY29vcmRpbmF0aW5nIHRvIGF2b2lkIGR1cGxpY2F0 aW9uCltKU10gdGhlIElFVEYgaXMgdXMsIHNvIGlmIHBlb3BsZSB3YW50IGl0IHRvIGJlIHdvcmtl ZCB0aHJvdWdoIGJ5IElFVEYsCiAgICAgdGhleSBzaG91bGQgYnJpbmcgaXQgaW4gYW5kIGJlIHJl YWR5IHRvIHdvcmsgb24gaXQKW0RCXSByZWdhcmRpbmcgaGF2aW5nIGRpZmZlcmVudCBvcmdhbml6 YXRpb25zIHByb2R1Y2luZyBkaWZmZXJlbnQgbW9kZWxzCiAgICAgZm9yIHRoZSBzYW1lIHRoaW5n LiAgVGhlIGVuZCB1c2VyIGNhbiBjaG9zZSB3aGljaCBtb2RlbCB0aGV5IHdhbnQKICAgICB0byB1 c2UuICBDb21tdW5pdHkgbW9kZWwsIHZlbmRvciBtb2RlbCBvciBJRVRGIG1vZGVsLiAKWz8/XSBp ZiB0aGVyZSBpcyBhIG1vZGVsIGluIE9ETCB0aGF0IHNvbWVvbmUgd2FudHMgdG8gYnJpbmcgdG8g dGhlIElFVEYsCiAgICAgdGhleSBzaG91bGQgYmUgZW5jb3VyYWdlZCB0byBkbyBzbwpbVE5dIHRo ZSBJRVRGIGlzIG5vdCBnb2luZyB0byBnbyBvdXQgYW5kIG1pbmUgbW9kZWxzLiAgVGhlcmUgaXMg bm8KICAgICByZXN0cmljdGlvbiBvbiBicmluZ2luZyBhIG1vZGVsIHRvIHRoZSBJRVRGIHdoZW4g dGhlcmUgYWxyZWFkeSBleGlzdHMKICAgICBhbiBPREwgbW9kZWwgZm9yIHRoZSBzYW1lIHRoaW5n IChhbHRob3VnaCBpdCB3b3VsZCBiZSBnb29kIHRvIGJyaW5nCiAgICAgdGhhdCBPREwgbW9kZWwg dG8gdGhlIElFVEYgaWYgdGhhdCB3b3JrcyBpbnN0ZWFkIG9mIGNyZWF0aW5nIGEgbmV3CiAgICAg b25lIHdoZW4gb25lIGV4aXN0cykuCiAgCgoxNSBtaW46IGRyYWZ0LWJvZ2Rhbm92aWMtbmV0bW9k LXlhbmctbW9kZWwtY2xhc3NpZmljYXRpb24tMDMgKERlYW4gQm9nZGFub3ZpYykKLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tICAKW0RCXSB3aG8gcmVhZCB0aGUgZHJhZnQ/IChhYm91dCAxMCBwZW9wbGUg cmFpc2VkIGhhbmRzKQpbS1ddIGluIHRoZSB6ZXJvdG91Y2ggZHJhZnQgd2UgcHJlc2VudCBhIHNv dXRoYm91bmQgbW9kZWwgdG8gZGV2aWNlcwogICAgIHNvIHRoZXkgY2FuIGJvb3RzdHJhcC4gIEhv dyBpcyB0aGF0IGNsYXNzaWZpZWQgPyAgSXQgaXNuJ3QgcmVhbGx5CiAgICAgYSAic2VydmljZSIg YnV0IGl0IHNpdHMgaW4gYSBjb250cm9sbGVyIChhbmQgaXMgdXNlZCB0byBpbnRlcmZhY2UKICAg ICB3aXRoIGEgZGV2aWNlKS4KW0NNXSB3ZSBkbyBhZGRyZXNzIHRoYXQgaW4gdGhlIGRyYWZ0CltY P10gY2FuIGEgWUFORyBtb2RlbCBiZSBjbGFzc2lmaWVkIGJvdGggYXMgYSBzZXJ2aWNlIG1vZGVs IGFuZCBhCiAgICAgZGV2aWNlIG1vZGVsCltDTV0geWVzIC0gdGhhdCBjYW4gYmUgcG9zc2libGUu ICBUaGUgc2FtZSBkYXRhIHN0cnVjdHVyZSBjYW4gYmUgYm90aCBhCiAgICAgc2VydmljZSBtb2Rl bCBhbmQgYSBkZXZpY2UgbW9kZWwgKGUuZy4gdG9wb2xvZ3kpLiAgCls/P10gaG93IGRvZXMgdG9w b2xvZ3kgbW9kZWwgZml0IGludG8gdGhpcyBjbGFzc2lmaWNhdGlvbiA/IApbREJdIHBsZWFzZSB0 YWtlIHRoYXQgdG8gdGhlIGxpc3QKWz8/XSB3ZSBtYXkgaGF2ZSBhIGRpc2Nvbm5lY3QuIFRoZXJl IGlzIGEgZGlzY29ubmVjdCBoZXJlLiAgU29tZSBkZXZpY2VzCiAgICAgaGF2ZSBzZXJ2aWNlLWxp a2Ugb2JqZWN0cy4KW01BXSBjYW4gdGhlIG5ldHdvcmsgc2VydmljZSBtb2RlbHMgYWxzbyBoYXZl IHRoZSBzYW1lIG1peCBvZiBzdGQsCiAgICAgc3RkLWV4dGVuc2lvbnMgYW5kIHByb3ByaWV0YXJ5 ID8KW0RCXSB5ZXMuICBXaWxsIGJlIGNsYXJpZmllZCBpbiBuZXh0IGRyYWZ0LgpbUz9dIEhvdyBk b2VzIHRoaXMgZHJhZnQgb3ZlcmxhcCB3aXRoIHRoZSBPcGVuQ29uZmlnIG1vZGVsLXN0cnVjdHVy ZSBkcmFmdD8KW0RCXSBUaGV5IGFyZSBkaWZmZXJlbnQgdGhpbmdzLiAgVGhpcyBvbmUgZGVmaW5l cyBzdGQgdnMgcHJvcHJpZXRhcnkuCiAgICAgVGhlIE9wZW5Db25maWcgaXMgYSBsYXlvdXQgb2Yg aG93IG1vZGVscyBmaXQgdG9nZXRoZXIgKGUuZy4gdGF4b25vbXksCiAgICAgb3ZlcmFsbCBkYXRh IG1vZGVsIHN0cnVjdHVyZSwgZXRjLikKCgogCgoxMCBtaW46IGRyYWZ0LW1hbnNmaWVsZC11bWwt dG8teWFuZy0wMCAoU2NvdHQgTWFuc2ZpZWxkKQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAgCltDTV0gIGhlcmUncyBteSB3b3JyeTogIG15 IGV4cGVyaWVuY2UgaXMgdGhhdCB0aGlzIGlzIGEgZGlmZmljdWx0IHRhc2sKICAgICAgY29tYmlu aW5nIGRpZmZlcmVudCB2aWV3cG9pbnRzLiAgTWF5YmUgd2Ugc2hvdWxkIGFsc28gbG9vayBpbiB0 aGUKICAgICAgb3RoZXIgZGlyZWN0aW9uLiBUaGVyZSBpcyBhIFVNTCBvdXRwdXQgcGx1Z2luIGlu IHB5YW5nLgpbSlNdIHdoYXQgaXMgeW91ciBlbmQtZ29hbCA/ICBUb3RhbGx5IGF1dG9tYXRlZCB0 b29sIHN5c3RlbSB0byBmZWVkIGEgVU1MCiAgICAgbW9kZWwgYW5kIHNwaXQgb3V0IGEgWUFORyBt b2R1bGUgPyAgSnVzdCBhIHNldCBvZiBpbmZvcm1hbCBndWlkZWxpbmVzCiAgICAgZm9yIGh1bWFu cyB0byB0cmFuc2xhdGUuICBJIGRvbid0IGJlbGlldmUgaW4gdGhlIGZpcnN0IG9uZSAodG9vbCku CiAgICAgTXkgZXhwZXJpZW5jZSBpcyB0aGF0IFVNTCBtb2RlbHMgZG9uJ3QgaGF2ZSBhbGwgdGhl IGluZm9ybWF0aW9uCiAgICAgbmVlZGVkIGZvciBhIGRhdGEgbW9kZWwuCls/P10gdGhlcmUgaXMg dXNlIGluIHRoaXMuICBJdCBpcyB0byBzaGFyZSBpbmZvcm1hdGlvbiBtb2RlbHMgYWNyb3NzCiAg ICAgZGF0YSBtb2RlbHMuICBXaGF0IG1ldGFkYXRhIHdpbGwgYmUgcmVxdWlyZWQgdG8gbWFrZSB0 aGUgZ2VuZXJhdGlvbgogICAgIHBvc3NpYmxlID8KCgoKZHJhZnQtYmpvcmtsdW5kLW5ldG1vZC1v cGVuY29uZmlnLXJlcGx5LTAwIChCZW5vaXQgQ2xhaXNlKQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCltKU10gaG93IHRvIGNvbnRpbnVl ICYgY29uY2x1ZGUgdGhpcyBkaXNjdXNzaW9uID8KW1ROXSB3ZSB3aWxsIGNvbnRpbnVlIHdpdGgg aW50ZXJpbXMgdW50aWwgdGhpcyBpcyBzb2x2ZWQKW1M/XSBJIGZpbmQgaXQgb2RkIHRvIGNvbnZl cnQgcmVzcG9uc2VzIHRvIGEgZHJhZnQuICAybmQgcG9pbnQ6IGFsbCB0aGUKICAgICBjb25jZXJu cyByYWlzZWQgd2VyZSBhbHNvIGRpc2N1c3NlZCBpbiBzZWN0aW9uIDcuICAzcmQgcG9pbnQ6IHBs ZWFzZQogICAgIHB1dCBhbiBhbHRlcm5hdGUgcHJvcG9zYWwgb24gdGhlIHRhYmxlLgpbSlNdIGl0 IGlzIHF1aXRlIGNvbW1vbiB0byBoYXZlIGRyYWZ0cyBmb3IgZGlzY3Vzc2lvbi4gIEl0IGNhcHR1 cmVzCiAgICAgZGlzY3Vzc2lvbnMgYW5kIGFyZ3VtZW50cy4gIEl0IGlzIGFuIGluZGl2aWR1YWwg ZHJhZnQgdGhhdCBhbnlvbmUKICAgICBjYW4gY3JlYXRlLgpbVE5dIHVzaW5nIGRyYWZ0cyBhbG1v c3QgbGlrZSBhbiBpc3N1ZSB0cmFja2VyCltKU10gd2UgaW5jbHVkZWQgYWx0ZXJuYXRlIHByb3Bv c2Fscy4KW1M/XSBmb3IgYWxsIHRoZSBxdWVzdGlvbnMgcmFpc2VkLCBpbiBzZWN0aW9uICM3IGRp c2N1c3NlcyBhbGwgdGhlIGNvbmNlcm5zCiAgICAgcmFpc2VkIGJ5IHRoZSBwcmVzZW50YXRpb24K W1M/XSBpZiB0aGVyZSBpcyB0byBiZSBhIG1lYW5pbmdmdWwgcHJvcG9zYWwsIHdlIG5lZWQgdG8g aGVhciBjb25jcmV0ZQogICAgIHByb3Bvc2FscyB0byBtb3ZlIHRoZSBkaXNjdXNzaW9uIGZvcndh cmQKW1ROXSB3ZSBlbmNvdXJhZ2UgdXNpbmcgdGhlIHBvaW50cyBpbiB0aGUgcHJlc2VudGF0aW9u IHRvIG1vdmUgdGhlCiAgICAgZGlzY3Vzc2lvbiBmb3J3YXJkLCB0aGVyZSBpcyBub3RoaW5nIG1v cmUgdG8gaXQuIE5vIHJlc29sdXRpb24KICAgICBleHBlY3RlZCB0b2RheS4KCgo= --_004_D1F2A34CCC006kwatsenjunipernet_-- From nobody Fri Aug 14 16:32:16 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4704C1A9170 for ; Fri, 14 Aug 2015 16:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.126 X-Spam-Level: X-Spam-Status: No, score=-2.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-2.3, 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 4q7RCfvPAkgV for ; Fri, 14 Aug 2015 16:32:14 -0700 (PDT) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF1E51A9175 for ; Fri, 14 Aug 2015 16:32:13 -0700 (PDT) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 4296B6912F; Fri, 14 Aug 2015 23:32:13 +0000 (UTC) Date: Fri, 14 Aug 2015 16:32:13 -0700 From: heasley To: netmod@ietf.org Message-ID: <20150814233213.GM16689@shrubbery.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [netmod] Y26 again, sorry X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 23:32:15 -0000 > On Thu, Aug 13, 2015 at 12:43 PM, Ladislav Lhotka wrote: > > > > > > On 13 Aug 2015, at 21:31, Andy Bierman wrote: > > > > > > Hi, > > > > > > IMO this is issue is closed. > > > I see no reason to re-open it. > > > YANG does not allow augments to add mandatory nodes. > > > > I strongly disagree with this attitude, this is a normal IETF procedure. > > Things can be changed even during WGLC. > > > > Virtual interims aren?t good for discussing non-trivial technical issues. > > > > > I am not hearing any new arguments for changing this rule for augments. > It's up to the co-chairs whether they want to re-open this issue. This might be ignorance of detail, but doesn't this approach essentially force vendors to publish [what i've been calling] enterprise yang models for models that they might otherwise just augment to support proprietary features? if so, what is the point of defining *any* models? > > > > Lada > > > > > Andy From nobody Fri Aug 14 16:40:12 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52F421A92DE for ; Fri, 14 Aug 2015 16:40:11 -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_41=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 vwDTeJqBYweQ for ; Fri, 14 Aug 2015 16:40:10 -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 8F6511A916D for ; Fri, 14 Aug 2015 16:40:09 -0700 (PDT) Received: by lbcbn3 with SMTP id bn3so53533810lbc.2 for ; Fri, 14 Aug 2015 16:40:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=seqDiNY0GMeX2yQ0rDYgyIhg2hHMcbaR29/74BELsHQ=; b=h1B92tIao44ZG8ts2RInR2puFyoTllnpvnT3AYmSs3J0okeBIuuggHvcSp7ZyMWyXA XI66YyKEJT8osIGH775XZVrsmnOfo+5weD4sHob7BF1uuCCDq4M6CZaBRytjUDw4xW/K Wg+MNXhI2digCKOkjqtMVdRvPNXamkUWAWa6SbIJzMrBRgA0JQexCAwQK/WqDCx60UDe 3+3oAnGv5rfCX7bgL2tdOoLD1F9xBtcXUeJyubgDr2ma4F32yFQ7w5uvAFH8P3kWzV78 Rs028udmXtktKgsgGpRjBk2SgF3vLKWBrX9mUm6/Lw4zWpUWq7Zy7ut1zwA/GiiY8deM rUKg== X-Gm-Message-State: ALoCoQlh5zl+vpuSOaZmgy0uEDAIS3GVznmBzDNe6gXG6hdjhzv0Jw2dtPRiklw+EtLwUTdo2yCo MIME-Version: 1.0 X-Received: by 10.152.120.74 with SMTP id la10mr40756727lab.37.1439595608074; Fri, 14 Aug 2015 16:40:08 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Fri, 14 Aug 2015 16:40:07 -0700 (PDT) In-Reply-To: <20150814233213.GM16689@shrubbery.net> References: <20150814233213.GM16689@shrubbery.net> Date: Fri, 14 Aug 2015 16:40:07 -0700 Message-ID: From: Andy Bierman To: heasley Content-Type: multipart/alternative; boundary=089e01229022d7011c051d4df86f Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y26 again, sorry X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 23:40:11 -0000 --089e01229022d7011c051d4df86f Content-Type: text/plain; charset=UTF-8 On Fri, Aug 14, 2015 at 4:32 PM, heasley wrote: > > On Thu, Aug 13, 2015 at 12:43 PM, Ladislav Lhotka wrote: > > > > > > > > > On 13 Aug 2015, at 21:31, Andy Bierman wrote: > > > > > > > > Hi, > > > > > > > > IMO this is issue is closed. > > > > I see no reason to re-open it. > > > > YANG does not allow augments to add mandatory nodes. > > > > > > I strongly disagree with this attitude, this is a normal IETF > procedure. > > > Things can be changed even during WGLC. > > > > > > Virtual interims aren?t good for discussing non-trivial technical > issues. > > > > > > > > I am not hearing any new arguments for changing this rule for augments. > > It's up to the co-chairs whether they want to re-open this issue. > > This might be ignorance of detail, but doesn't this approach essentially > force > vendors to publish [what i've been calling] enterprise yang models for > models > that they might otherwise just augment to support proprietary features? > > if so, what is the point of defining *any* models? > > The issue here is that augment cannot directly add mandatory nodes. They must be inside a list or a P-container. augment /foo:bar { leaf NOT_ALLOWED { mandatory true; type string; } } augment /foo:bar { container THIS_IS_ALLOWED { presence "new feature enabled"; leaf THIS_IS_NOW_ALLOWED { mandatory true; type string; } } } IMO this extra P-container is not a burden and it serves an important purpose, which is to allow clients that know the base structure to keep working. Otherwise when they create or replace the node, the edit will be rejected because a mandatory node is missing. > > > > > > Lada > > > > Andy > > > > > > Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --089e01229022d7011c051d4df86f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Aug 14, 2015 at 4:32 PM, heasley <heas@shrubbery.net>= wrote:
> On Thu, Aug 13, 2015 = at 12:43 PM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> >
> > > On 13 Aug 2015, at 21:31, Andy Bierman <andy@yumaworks.com> wrote: > > >
> > > Hi,
> > >
> > > IMO this is issue is closed.
> > > I see no reason to re-open it.
> > > YANG does not allow augments to add mandatory nodes.
> >
> > I strongly disagree with this attitude, this is a normal IETF pro= cedure.
> > Things can be changed even during WGLC.
> >
> > Virtual interims aren?t good for discussing non-trivial technical= issues.
> >
> >
> I am not hearing any new arguments for changing this rule for augments= .
> It's up to the co-chairs whether they want to re-open this issue.<= br>
This might be ignorance of detail, but doesn't this approach essentiall= y force
vendors to publish [what i've been calling] enterprise yang models for = models
that they might otherwise just augment to support proprietary features?

if so, what is the point of defining *any* models?



The issue here is that = augment cannot directly add mandatory nodes.
They must be inside = a list or a P-container.=C2=A0


=C2= =A0 =C2=A0 augment /foo:bar {
=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf NOT= _ALLOWED {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mandatory true;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type string;
=C2=A0 =C2= =A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 }

=C2= =A0=C2=A0=C2=A0 augment /foo:bar {
=C2=A0 =C2=A0 =C2=A0 =C2=A0con= tainer THIS_IS_ALLOWED {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 prese= nce "new feature enabled";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 leaf THIS_IS_NOW_ALLOWED {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0mandatory true;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0type string;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = }
=C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 }

IMO this extra P-container is not a burden and it serves
an important purpose, which is to allow clients that
kno= w the base structure to keep working.=C2=A0 Otherwise
when they c= reate or replace the node, the edit will be
rejected because a ma= ndatory node is missing.



=

>
>
> > Lada
> >


Andy
=C2=A0
>
>
> Andy

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

--089e01229022d7011c051d4df86f-- From nobody Sat Aug 15 00:26:14 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 030281ACD3A for ; Sat, 15 Aug 2015 00:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.461 X-Spam-Level: X-Spam-Status: No, score=-4.461 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_29=0.6, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4DnsFN3K2Ux for ; Sat, 15 Aug 2015 00:26:12 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADA371ACD32 for ; Sat, 15 Aug 2015 00:26:11 -0700 (PDT) Received: from [172.29.2.202] (nat-14.bravonet.cz [77.48.225.14]) by mail.nic.cz (Postfix) with ESMTPSA id 114B2181685; Sat, 15 Aug 2015 09:26:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1439623569; bh=TXspVHS3Uu44ErJIxGmvuTwpnN1o7CRFDNoUPNQt5vQ=; h=From:Date:To; b=oeiMBZlsJfHixQ5v56FgFL4G/PC62lhdzwyRF9GSuoVVZ0wTEhhJSSHrsspVMks8Y 7DdnGrWeGctBnzomj/ivg/f7f7TYXPaTMtEoxZTJm+Q7ysIIaz0UP3KPrWGog+Aje8 /BNaW/p2XKFP7nqNA+MByHERBpu7Vqkrw163gG74= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: Date: Sat, 15 Aug 2015 09:26:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <113DB0A2-11F9-41FE-B07B-5751EA37BEF3@nic.cz> References: <20150814233213.GM16689@shrubbery.net> To: Andy Bierman X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: heasley , "netmod@ietf.org" Subject: Re: [netmod] Y26 again, sorry X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2015 07:26:14 -0000 > On 15 Aug 2015, at 01:40, Andy Bierman wrote: >=20 >=20 >=20 > On Fri, Aug 14, 2015 at 4:32 PM, heasley wrote: > > On Thu, Aug 13, 2015 at 12:43 PM, Ladislav Lhotka = wrote: > > > > > > > > > On 13 Aug 2015, at 21:31, Andy Bierman = wrote: > > > > > > > > Hi, > > > > > > > > IMO this is issue is closed. > > > > I see no reason to re-open it. > > > > YANG does not allow augments to add mandatory nodes. > > > > > > I strongly disagree with this attitude, this is a normal IETF = procedure. > > > Things can be changed even during WGLC. > > > > > > Virtual interims aren?t good for discussing non-trivial technical = issues. > > > > > > > > I am not hearing any new arguments for changing this rule for = augments. > > It's up to the co-chairs whether they want to re-open this issue. >=20 > This might be ignorance of detail, but doesn't this approach = essentially force > vendors to publish [what i've been calling] enterprise yang models for = models > that they might otherwise just augment to support proprietary = features? >=20 > if so, what is the point of defining *any* models? >=20 >=20 >=20 > The issue here is that augment cannot directly add mandatory nodes. > They must be inside a list or a P-container. In both examples, the augments are applied inside a list, only the list = is defined in the module that=E2=80=99s being augmented.=20 > =20 >=20 >=20 > augment /foo:bar { > leaf NOT_ALLOWED { > mandatory true; > type string; > } > } >=20 > augment /foo:bar { > container THIS_IS_ALLOWED { > presence "new feature enabled"; > leaf THIS_IS_NOW_ALLOWED { > mandatory true; > type string; > } > } > } >=20 > IMO this extra P-container is not a burden and it serves > an important purpose, which is to allow clients that > know the base structure to keep working. Otherwise But it also allows clients to create invalid DNS resource records in my = example, or invalid if:interface entries in Rob=E2=80=99s example, = because the p-container can be omitted entirely. =20 > when they create or replace the node, the edit will be > rejected because a mandatory node is missing. The client has no good reason to create list entries with types that it = doesn=E2=80=99t support.=20 My workaround in the dns-zones module is a must statement in the = =E2=80=9Crdata=E2=80=9D list that requires the p-container to be always = present: must =E2=80=9Ccount(*) > 2=E2=80=9D; This is a tricky and brittle solution though. Lada >=20 >=20 >=20 >=20 > > > > > > > Lada > > > >=20 >=20 > Andy > =20 > > > > > > Andy >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Sat Aug 15 01:35:57 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 254451A004C for ; Sat, 15 Aug 2015 01:35:56 -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_41=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 O0TxuURCLHw5 for ; Sat, 15 Aug 2015 01:35:54 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C94D1A0049 for ; Sat, 15 Aug 2015 01:35:54 -0700 (PDT) Received: from [172.29.2.202] (nat-14.bravonet.cz [77.48.225.14]) by mail.nic.cz (Postfix) with ESMTPSA id C5A0918188E; Sat, 15 Aug 2015 10:35:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1439627752; bh=+tgwHkN/yNSL70D/3cMwA2P4N7lkS0Zm9Rrt3uVoLas=; h=From:Date:To; b=xrGOxFgFeouNVgaGraw2DolqhHP9E3oBKqyk63/Rg19drp0Mqr1ZkgvOFbjbwJtvy UfzU15IwZufKpQheQc88PPsWCrzzFELvH2ALMf5Jt1y9s/8f1p3L27pmxwQZ6ZAQAz DkUcIXtAA5nhG6gqCLXaUQB4ZGDBvubiYk5E8Z/4= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: <20150814233213.GM16689@shrubbery.net> Date: Sat, 15 Aug 2015 10:35:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <417EA64C-AB7C-4816-A57A-D0BE7AAC86D6@nic.cz> References: <20150814233213.GM16689@shrubbery.net> To: heasley X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Y26 again, sorry X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2015 08:35:56 -0000 > On 15 Aug 2015, at 01:32, heasley wrote: >=20 >> On Thu, Aug 13, 2015 at 12:43 PM, Ladislav Lhotka = wrote: >>=20 >>>=20 >>>> On 13 Aug 2015, at 21:31, Andy Bierman wrote: >>>>=20 >>>> Hi, >>>>=20 >>>> IMO this is issue is closed. >>>> I see no reason to re-open it. >>>> YANG does not allow augments to add mandatory nodes. >>>=20 >>> I strongly disagree with this attitude, this is a normal IETF = procedure. >>> Things can be changed even during WGLC. >>>=20 >>> Virtual interims aren?t good for discussing non-trivial technical = issues. >>>=20 >>>=20 >> I am not hearing any new arguments for changing this rule for = augments. >> It's up to the co-chairs whether they want to re-open this issue. >=20 > This might be ignorance of detail, but doesn't this approach = essentially force=20 > vendors to publish [what i've been calling] enterprise yang models for = models > that they might otherwise just augment to support proprietary = features? I think there are two aspects here. On the one hand, we probably don=E2=80= =99t want vendors to augment a standard interface type with mandatory = parameters because this breaks interoperability and creates a silo. On the other hand, vendors (or anybody) can create a new interface type = (or derive its identity from a standard type), and then they should be = able to use full power of YANG to specify schema constraints including = mandatory parameters where necessary. Lada >=20 > if so, what is the point of defining *any* models? >=20 >>=20 >>=20 >>> Lada >>>=20 >>=20 >>=20 >> Andy >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Sat Aug 15 07:50:16 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB3C1ACE86 for ; Sat, 15 Aug 2015 07:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCh_QekXuAUm for ; Sat, 15 Aug 2015 07:50:12 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 625601ACE85 for ; Sat, 15 Aug 2015 07:50:11 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id C37082741E4E4 for ; Sat, 15 Aug 2015 14:50:06 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id t7FEo8jp027241 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 15 Aug 2015 14:50:08 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.167]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Sat, 15 Aug 2015 10:50:08 -0400 From: "Carey, Timothy (Timothy)" To: "netmod@ietf.org" Thread-Topic: Constraint on mandatory on nodes as part of augmentation in RFC6020bis Thread-Index: AdDXaazE/NLkpbHWQ6iOU9qx6uEYXg== Date: Sat, 15 Aug 2015 14:50:06 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77DC237498@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F77DC237498US70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: Subject: [netmod] Constraint on mandatory on nodes as part of augmentation in RFC6020bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2015 14:50:14 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77DC237498US70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Team, Section 7.17 The augment statement has verbiage If the target node is in another module, then nodes added by the augmentation MUST NOT be mandatory nodes (see Section 3.1). We are seeing situations where this constraint is invalid - Situations wher= e a standard builds on another standard and makes parts of the new standard= mandatory. It seems this was an issue in the past where the decision was to get around= this statement with a presence container. Since 6020bis is in progress - would it be possible to simply remove this p= hrase and allow mandatory nodes as part of the augmentation so we don't hav= e to have this artificial workaround? Thanks, Tim --_000_9966516C6EB5FC4381E05BF80AA55F77DC237498US70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Team,

 

 

Section 7.17 The augment statement has verbiage

If the target node is in another= module, then nodes added by the

augmentation MUST NOT be mandatory nodes (see Sect= ion 3.1).

 

 

We are seeing situations where this constraint is i= nvalid – Situations where a standard builds on another standard and m= akes parts of the new standard mandatory.

 

It seems this was an issue in the past where the de= cision was to get around this statement with a presence container.

 

Since 6020bis is in progress – would it be po= ssible to simply remove this phrase and allow mandatory nodes as part of th= e augmentation so we don’t have to have this artificial workaround?

 

Thanks,

Tim

--_000_9966516C6EB5FC4381E05BF80AA55F77DC237498US70UWXCHMBA05z_-- From nobody Sat Aug 15 08:25:24 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AFFD1B2F54 for ; Sat, 15 Aug 2015 08:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.661 X-Spam-Level: X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egwG-drZJZmi for ; Sat, 15 Aug 2015 08:25:21 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A1B81B2F53 for ; Sat, 15 Aug 2015 08:25:20 -0700 (PDT) Received: from [IPv6:2a01:5e0:29:ffff:f5de:52a6:5ccd:3094] (unknown [IPv6:2a01:5e0:29:ffff:f5de:52a6:5ccd:3094]) by mail.nic.cz (Postfix) with ESMTPSA id C897B181127; Sat, 15 Aug 2015 17:25:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1439652318; bh=o0HlgeuBvmXuPoVT8Zg7NyAxMtVcroU2lbGVkpjW7cc=; h=From:Date:To; b=saxLpHtw9oE6dXZusvydlNZ3lk/tX3daWo5gekROzr/NoyooMxphZGmnfTWimNReO oO20LlpN6XKLGkg111uf9zOCW9s/WPw+L68W6IqUAwZzdGrtEUnyUumntHZiZbbnJb TXamd2MkWGf7UNbuF/IwVju3F5OhlfPlXh0SfmHA= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77DC237498@US70UWXCHMBA05.zam.alcatel-lucent.com> Date: Sat, 15 Aug 2015 17:25:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2FA0FBCD-4779-488B-968F-4FD271D506BC@nic.cz> References: <9966516C6EB5FC4381E05BF80AA55F77DC237498@US70UWXCHMBA05.zam.alcatel-lucent.com> To: "Carey, Timothy (Timothy)" X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Constraint on mandatory on nodes as part of augmentation in RFC6020bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2015 15:25:23 -0000 > On 15 Aug 2015, at 16:50, Carey, Timothy (Timothy) = wrote: >=20 > Team, > =20 > =20 > Section 7.17 The augment statement has verbiage > If the target node is in another module, then nodes added by the > augmentation MUST NOT be mandatory nodes (see Section 3.1). > =20 > =20 > We are seeing situations where this constraint is invalid =E2=80=93 = Situations where a standard builds on another standard and makes parts = of the new standard mandatory. > =20 > It seems this was an issue in the past where the decision was to get = around this statement with a presence container. > =20 > Since 6020bis is in progress =E2=80=93 would it be possible to simply = remove this phrase and allow mandatory nodes as part of the augmentation = so we don=E2=80=99t have to have this artificial workaround? This is exactly what=E2=80=99s currently being discussed in this thread: = https://mailarchive.ietf.org/arch/search/?email_list=3Dnetmod&gbt=3D1&inde= x=3DES2ogm1wabzZVIIBlrRor0fn3rk Lada > =20 > Thanks, > Tim > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Sat Aug 15 08:39:34 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB8421B2F70 for ; Sat, 15 Aug 2015 08:39:33 -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 8PLu3A3DRSRC for ; Sat, 15 Aug 2015 08:39:32 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 529331B2F6F for ; Sat, 15 Aug 2015 08:39:32 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id 52AC2A9F21110; Sat, 15 Aug 2015 15:39:27 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id t7FFdTnw004104 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 15 Aug 2015 15:39:29 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.167]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Sat, 15 Aug 2015 11:39:28 -0400 From: "Carey, Timothy (Timothy)" To: Ladislav Lhotka Thread-Topic: [netmod] Constraint on mandatory on nodes as part of augmentation in RFC6020bis Thread-Index: AdDXaazE/NLkpbHWQ6iOU9qx6uEYXgAJnGwAAAgMWIA= Date: Sat, 15 Aug 2015 15:39:27 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77DC23755F@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77DC237498@US70UWXCHMBA05.zam.alcatel-lucent.com> <2FA0FBCD-4779-488B-968F-4FD271D506BC@nic.cz> In-Reply-To: <2FA0FBCD-4779-488B-968F-4FD271D506BC@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Constraint on mandatory on nodes as part of augmentation in RFC6020bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2015 15:39:34 -0000 TGFkYSwNCg0KWWVzIHNvcnJ5IC0gSSBqdXN0IHNhdyB0aGF0IHRocmVhZCBhZnRlciBJIHN1Ym1p dHRlZCBtaW5lLg0KDQpCUiwNClRpbQ0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IExhZGlzbGF2IExob3RrYSBbbWFpbHRvOmxob3RrYUBuaWMuY3pdIA0KU2VudDogU2F0dXJkYXks IEF1Z3VzdCAxNSwgMjAxNSAxMDoyNSBBTQ0KVG86IENhcmV5LCBUaW1vdGh5IChUaW1vdGh5KQ0K Q2M6IG5ldG1vZEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtuZXRtb2RdIENvbnN0cmFpbnQgb24g bWFuZGF0b3J5IG9uIG5vZGVzIGFzIHBhcnQgb2YgYXVnbWVudGF0aW9uIGluIFJGQzYwMjBiaXMN Cg0KDQo+IE9uIDE1IEF1ZyAyMDE1LCBhdCAxNjo1MCwgQ2FyZXksIFRpbW90aHkgKFRpbW90aHkp IDx0aW1vdGh5LmNhcmV5QGFsY2F0ZWwtbHVjZW50LmNvbT4gd3JvdGU6DQo+IA0KPiBUZWFtLA0K PiAgDQo+ICANCj4gU2VjdGlvbiA3LjE3IFRoZSBhdWdtZW50IHN0YXRlbWVudCBoYXMgdmVyYmlh Z2UgSWYgdGhlIHRhcmdldCBub2RlIGlzIA0KPiBpbiBhbm90aGVyIG1vZHVsZSwgdGhlbiBub2Rl cyBhZGRlZCBieSB0aGUgYXVnbWVudGF0aW9uIE1VU1QgTk9UIGJlIA0KPiBtYW5kYXRvcnkgbm9k ZXMgKHNlZSBTZWN0aW9uIDMuMSkuDQo+ICANCj4gIA0KPiBXZSBhcmUgc2VlaW5nIHNpdHVhdGlv bnMgd2hlcmUgdGhpcyBjb25zdHJhaW50IGlzIGludmFsaWQg4oCTIFNpdHVhdGlvbnMgd2hlcmUg YSBzdGFuZGFyZCBidWlsZHMgb24gYW5vdGhlciBzdGFuZGFyZCBhbmQgbWFrZXMgcGFydHMgb2Yg dGhlIG5ldyBzdGFuZGFyZCBtYW5kYXRvcnkuDQo+ICANCj4gSXQgc2VlbXMgdGhpcyB3YXMgYW4g aXNzdWUgaW4gdGhlIHBhc3Qgd2hlcmUgdGhlIGRlY2lzaW9uIHdhcyB0byBnZXQgYXJvdW5kIHRo aXMgc3RhdGVtZW50IHdpdGggYSBwcmVzZW5jZSBjb250YWluZXIuDQo+ICANCj4gU2luY2UgNjAy MGJpcyBpcyBpbiBwcm9ncmVzcyDigJMgd291bGQgaXQgYmUgcG9zc2libGUgdG8gc2ltcGx5IHJl bW92ZSB0aGlzIHBocmFzZSBhbmQgYWxsb3cgbWFuZGF0b3J5IG5vZGVzIGFzIHBhcnQgb2YgdGhl IGF1Z21lbnRhdGlvbiBzbyB3ZSBkb27igJl0IGhhdmUgdG8gaGF2ZSB0aGlzIGFydGlmaWNpYWwg d29ya2Fyb3VuZD8NCg0KVGhpcyBpcyBleGFjdGx5IHdoYXTigJlzIGN1cnJlbnRseSBiZWluZyBk aXNjdXNzZWQgaW4gdGhpcyB0aHJlYWQ6DQoNCmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcv YXJjaC9zZWFyY2gvP2VtYWlsX2xpc3Q9bmV0bW9kJmdidD0xJmluZGV4PUVTMm9nbTF3YWJ6WlZJ SUJsclJvcjBmbjNyaw0KDQpMYWRhDQoNCj4gIA0KPiBUaGFua3MsDQo+IFRpbQ0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBuZXRtb2QgbWFpbGlu ZyBsaXN0DQo+IG5ldG1vZEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL25ldG1vZA0KDQotLQ0KTGFkaXNsYXYgTGhvdGthLCBDWi5OSUMgTGFicw0KUEdQ IEtleSBJRDogRTc0RThDMEMNCg0KDQoNCg0K From nobody Sat Aug 15 09:00:28 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0CEF1AC3C7 for ; Sat, 15 Aug 2015 09:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUqvjQeaIifv for ; Sat, 15 Aug 2015 09:00:25 -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 7FE6F1AC3B3 for ; Sat, 15 Aug 2015 09:00:25 -0700 (PDT) Received: by lahi9 with SMTP id i9so57921243lah.2 for ; Sat, 15 Aug 2015 09:00:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=PtYgbUhW9+ssKcZrabGVtbtH+wf4DYnvRG9Ik6kOBU8=; b=c1e8so3F4+5O4X+lcqwzGhBW7SlL7tibbXRUcvOh1Ks0kGPErqUAK8Pls043gHabux ibVMY+dPVeJwoGUCJ+k1yWlVJwfEOEFC2prON7npjHAfl3YRl+tajIIRPSCgLY1jxfTl Hy+4BsxIZGWnOMo71NEedKZbe1VYazqPMW/ZRcEq7hT3izIIk6UjysvYyWygHCnPXyz+ 6bFXMxsG3H7Kp379EF1z77WjhVqzul4LYvl9v3f95cx3rEahr3287JXAHsEZkrrR6BMO c7EEZ53B1x0ryFXfAYkH7zyhuVDbC8LCXLXIPBtpGlEEV/obyfXA7A3WA/7QfJ9E31JG 2k/g== X-Gm-Message-State: ALoCoQmZX6SaH39WagAmoDLGR6suzAsTeQL/66S+JP9issWjn+0NxsZ9j7xz4FqNK6o6M54PC9fS MIME-Version: 1.0 X-Received: by 10.112.154.106 with SMTP id vn10mr38111967lbb.38.1439654423842; Sat, 15 Aug 2015 09:00:23 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Sat, 15 Aug 2015 09:00:23 -0700 (PDT) In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77DC23755F@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77DC237498@US70UWXCHMBA05.zam.alcatel-lucent.com> <2FA0FBCD-4779-488B-968F-4FD271D506BC@nic.cz> <9966516C6EB5FC4381E05BF80AA55F77DC23755F@US70UWXCHMBA05.zam.alcatel-lucent.com> Date: Sat, 15 Aug 2015 09:00:23 -0700 Message-ID: From: Andy Bierman To: "Carey, Timothy (Timothy)" Content-Type: multipart/alternative; boundary=089e0122af2a886c6c051d5baa9b Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Constraint on mandatory on nodes as part of augmentation in RFC6020bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2015 16:00:27 -0000 --089e0122af2a886c6c051d5baa9b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, If you are using mandatory nodes in augment, it is because you expect that all clients will know and implement both modules. However YANG has no way to require that. A server is NEVER required to implement the augmenting module. It doesn't really matter that you are writing these illegal YANG modules all at once. A server is not required to implement them all at once, or all of them ever. It is rather naive to think that the client must understand every YANG module implemented on a server. Even if this were useful, the client will certainly not support modules written after the client code was released. You should be using submodules (written all at once) if you want to augment with mandatory nodes. Andy On Sat, Aug 15, 2015 at 8:39 AM, Carey, Timothy (Timothy) < timothy.carey@alcatel-lucent.com> wrote: > Lada, > > Yes sorry - I just saw that thread after I submitted mine. > > BR, > Tim > -----Original Message----- > From: Ladislav Lhotka [mailto:lhotka@nic.cz] > Sent: Saturday, August 15, 2015 10:25 AM > To: Carey, Timothy (Timothy) > Cc: netmod@ietf.org > Subject: Re: [netmod] Constraint on mandatory on nodes as part of > augmentation in RFC6020bis > > > > On 15 Aug 2015, at 16:50, Carey, Timothy (Timothy) < > timothy.carey@alcatel-lucent.com> wrote: > > > > Team, > > > > > > Section 7.17 The augment statement has verbiage If the target node is > > in another module, then nodes added by the augmentation MUST NOT be > > mandatory nodes (see Section 3.1). > > > > > > We are seeing situations where this constraint is invalid =E2=80=93 Sit= uations > where a standard builds on another standard and makes parts of the new > standard mandatory. > > > > It seems this was an issue in the past where the decision was to get > around this statement with a presence container. > > > > Since 6020bis is in progress =E2=80=93 would it be possible to simply r= emove > this phrase and allow mandatory nodes as part of the augmentation so we > don=E2=80=99t have to have this artificial workaround? > > This is exactly what=E2=80=99s currently being discussed in this thread: > > > https://mailarchive.ietf.org/arch/search/?email_list=3Dnetmod&gbt=3D1&ind= ex=3DES2ogm1wabzZVIIBlrRor0fn3rk > > Lada > > > > > Thanks, > > Tim > > _______________________________________________ > > 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 > --089e0122af2a886c6c051d5baa9b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

If you are using mandatory nodes in= augment, it is because you expect
that all clients will know and= implement both modules.
However YANG has no way to require that.=
A server is NEVER required to implement the augmenting module.

It doesn't really matter that you are writing t= hese illegal YANG modules
all at once. A server is not required t= o implement them all at once,
or all of them ever.

=
It is rather naive to think that the client must understand ever= y YANG module
implemented on a server.=C2=A0 Even if this were us= eful, the client will certainly
not support modules written after= the client code was released.

You should be using= submodules (written all at once) if you want
to augment with man= datory nodes.

Andy




On Sat, Aug 15, 2015 at 8:39 AM, Carey, Timothy (Timothy) <timothy.carey@alcatel-lucent.com> wrote:
Lada,

Yes sorry - I just saw that thread after I submitted mine.

BR,
Tim
-----Original Message-----
From: Ladislav Lhotka [mailto:lhotka@nic.c= z]
Sent: Saturday, August 15, 2015 10:25 AM
To: Carey, Timothy (Timothy)
Cc: netmod@ietf.org
Subject: Re: [netmod] Constraint on mandatory on nodes as part of augmentat= ion in RFC6020bis


> On 15 Aug 2015, at 16:50, Carey, Timothy (Timothy) <timothy.carey@alcatel-lucent.com&g= t; wrote:
>
> Team,
>
>
> Section 7.17 The augment statement has verbiage If the target node is<= br> > in another module, then nodes added by the augmentation MUST NOT be > mandatory nodes (see Section 3.1).
>
>
> We are seeing situations where this constraint is invalid =E2=80=93 Si= tuations where a standard builds on another standard and makes parts of the= new standard mandatory.
>
> It seems this was an issue in the past where the decision was to get a= round this statement with a presence container.
>
> Since 6020bis is in progress =E2=80=93 would it be possible to simply = remove this phrase and allow mandatory nodes as part of the augmentation so= we don=E2=80=99t have to have this artificial workaround?

This is exactly what=E2=80=99s currently being discussed in this thread:
https://mailarchive.ietf.org/arch/search/?email_list=3Dnetmod&= amp;gbt=3D1&index=3DES2ogm1wabzZVIIBlrRor0fn3rk

Lada

>
> Thanks,
> Tim
> _______________________________________________
> 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

--089e0122af2a886c6c051d5baa9b-- From nobody Sat Aug 15 10:10:15 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D27A41A8874 for ; Sat, 15 Aug 2015 10:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.661 X-Spam-Level: X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-YBqZI45ijr for ; Sat, 15 Aug 2015 10:10:11 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A65D1A8836 for ; Sat, 15 Aug 2015 10:10:10 -0700 (PDT) Received: from [172.29.2.202] (nat-14.bravonet.cz [77.48.225.14]) by mail.nic.cz (Postfix) with ESMTPSA id 7A8F418182F; Sat, 15 Aug 2015 19:10:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1439658608; bh=6w0XwGl2iRRifsPpBDdQjaM0CINaUsejT7HdvmFCSww=; h=From:Date:To; b=Qmb3gs58XVCnX1sBpAoih4SZXye1FBrQUVn9KMo6H3Y+FjgU6Sfjf47mxetnOKog5 JlEJ6ss7dVx0LfZAH2aDbZz1fI01J/P5/94C+KdafkZTnyxNsjl4nWeILCxwAp4b6A A1joNWMkkClktkz/MmT5OooFwtvvScsOglk3SwHw= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: Date: Sat, 15 Aug 2015 19:10:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1708085B-AC2F-455D-A5D9-45382F44DB3C@nic.cz> References: <9966516C6EB5FC4381E05BF80AA55F77DC237498@US70UWXCHMBA05.zam.alcatel-lucent.com> <2FA0FBCD-4779-488B-968F-4FD271D506BC@nic.cz> <9966516C6EB5FC4381E05BF80AA55F77DC23755F@US70UWXCHMBA05.zam.alcatel-lucent.com> To: Andy Bierman X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "Carey, Timothy \(Timothy\)" , "netmod@ietf.org" Subject: Re: [netmod] Constraint on mandatory on nodes as part of augmentation in RFC6020bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2015 17:10:14 -0000 > On 15 Aug 2015, at 18:00, Andy Bierman wrote: >=20 > Hi, >=20 > If you are using mandatory nodes in augment, it is because you expect > that all clients will know and implement both modules. > However YANG has no way to require that. > A server is NEVER required to implement the augmenting module. Are you saying that a server isn=E2=80=99t required to implement modules = that it advertises? There is no text in 6020(bis) supporting this theory. An augmenting = module is an integral part of the data model as any other. =20 >=20 > It doesn't really matter that you are writing these illegal YANG = modules > all at once. A server is not required to implement them all at once, > or all of them ever. >=20 > It is rather naive to think that the client must understand every YANG = module > implemented on a server. Even if this were useful, the client will = certainly > not support modules written after the client code was released. Such a client is unsafe because the modules that the client ignores may = imply some important semantics. YANG modules are not perfectly isolated = from each other, and a client may break things if it doesn=E2=80=99t = understand the interactions. And again, I am not aware of any text in = 6020 supporting such cherry-picking clients. >=20 > You should be using submodules (written all at once) if you want > to augment with mandatory nodes. In many use cases this is impossible - e.g. for interface types. Lada >=20 > Andy >=20 >=20 >=20 >=20 > On Sat, Aug 15, 2015 at 8:39 AM, Carey, Timothy (Timothy) = wrote: > Lada, >=20 > Yes sorry - I just saw that thread after I submitted mine. >=20 > BR, > Tim > -----Original Message----- > From: Ladislav Lhotka [mailto:lhotka@nic.cz] > Sent: Saturday, August 15, 2015 10:25 AM > To: Carey, Timothy (Timothy) > Cc: netmod@ietf.org > Subject: Re: [netmod] Constraint on mandatory on nodes as part of = augmentation in RFC6020bis >=20 >=20 > > On 15 Aug 2015, at 16:50, Carey, Timothy (Timothy) = wrote: > > > > Team, > > > > > > Section 7.17 The augment statement has verbiage If the target node = is > > in another module, then nodes added by the augmentation MUST NOT be > > mandatory nodes (see Section 3.1). > > > > > > We are seeing situations where this constraint is invalid =E2=80=93 = Situations where a standard builds on another standard and makes parts = of the new standard mandatory. > > > > It seems this was an issue in the past where the decision was to get = around this statement with a presence container. > > > > Since 6020bis is in progress =E2=80=93 would it be possible to = simply remove this phrase and allow mandatory nodes as part of the = augmentation so we don=E2=80=99t have to have this artificial = workaround? >=20 > This is exactly what=E2=80=99s currently being discussed in this = thread: >=20 > = https://mailarchive.ietf.org/arch/search/?email_list=3Dnetmod&gbt=3D1&inde= x=3DES2ogm1wabzZVIIBlrRor0fn3rk >=20 > Lada >=20 > > > > Thanks, > > Tim > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Sat Aug 15 10:23:29 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB2E01B2FD7 for ; Sat, 15 Aug 2015 10:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_42=0.6, 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 EGpDHJHlDdgJ for ; Sat, 15 Aug 2015 10:23:26 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id E05571B2FD5 for ; Sat, 15 Aug 2015 10:23:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=T8rRyg5rc0nZxZumBBhRIh2WG7axq0aq7pcdEKRY+cMQQY/lWwacsW902y9CbkZJ; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.51] (helo=mswamui-thinleaf.atl.sa.earthlink.net) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1ZQfAu-0003xy-3Q for netmod@ietf.org; Sat, 15 Aug 2015 13:23:20 -0400 Received: from 76.254.49.21 by webmail.earthlink.net with HTTP; Sat, 15 Aug 2015 13:23:19 -0400 Message-ID: <33267463.1439659400007.JavaMail.root@mswamui-thinleaf.atl.sa.earthlink.net> Date: Sat, 15 Aug 2015 10:23:19 -0700 (GMT-07:00) From: Randy Presuhn To: "netmod@ietf.org" Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888ff8848a73c44bba0bf31aaae1c9105a44a3204232bc0cc4e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.51 Archived-At: Subject: Re: [netmod] Constraint on mandatory on nodes as part of augmentation in RFC6020bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2015 17:23:28 -0000 Hi - I know netmod isn't object-oriented, but I think viewing this through the lens of conformance might be causing us to miss the conflicting requirements that lead the group to this impasse. RFC 6020 effectively presents us with a way of defining instantiable classes, and augment functions as a rather limited way of defining instantiable subclasses. Usage has given us another requirement: the ability to define (or at least to designate as noninstantiable) abstract superclasses. I don't see how one can both with the current metamodel, such as it is. Randy -----Original Message----- From: Andy Bierman=20 Sent: Aug 15, 2015 9:00 AM To: "Carey, Timothy (Timothy)"=20 Cc: "netmod@ietf.org"=20 Subject: Re: [netmod] Constraint on mandatory on nodes as part of augmentat= ion in RFC6020bis Hi, If you are using mandatory nodes in augment, it is because you expectthat a= ll clients will know and implement both modules.However YANG has no way to = require that.A server is NEVER required to implement the augmenting module. It doesn't really matter that you are writing these illegal YANG modulesall= at once. A server is not required to implement them all at once,or all of = them ever. It is rather naive to think that the client must understand every YANG modu= leimplemented on a server. Even if this were useful, the client will certa= inlynot support modules written after the client code was released. You should be using submodules (written all at once) if you wantto augment = with mandatory nodes. Andy On Sat, Aug 15, 2015 at 8:39 AM, Carey, Timothy (Timothy) wrote: Lada, Yes sorry - I just saw that thread after I submitted mine. BR, Tim -----Original Message----- From: Ladislav Lhotka [mailto:lhotka@nic.cz] Sent: Saturday, August 15, 2015 10:25 AM To: Carey, Timothy (Timothy) Cc: netmod@ietf.org Subject: Re: [netmod] Constraint on mandatory on nodes as part of augmentat= ion in RFC6020bis > On 15 Aug 2015, at 16:50, Carey, Timothy (Timothy) wrote: > > Team, > > > Section 7.17 The augment statement has verbiage If the target node is > in another module, then nodes added by the augmentation MUST NOT be > mandatory nodes (see Section 3.1). > > > We are seeing situations where this constraint is invalid =E2=80=93 Situa= tions where a standard builds on another standard and makes parts of the ne= w standard mandatory. > > It seems this was an issue in the past where the decision was to get arou= nd this statement with a presence container. > > Since 6020bis is in progress =E2=80=93 would it be possible to simply rem= ove this phrase and allow mandatory nodes as part of the augmentation so we= don=E2=80=99t have to have this artificial workaround? This is exactly what=E2=80=99s currently being discussed in this thread: https://mailarchive.ietf.org/arch/search/?email_list=3Dnetmod&gbt=3D1&index= =3DES2ogm1wabzZVIIBlrRor0fn3rk Lada > > Thanks, > Tim > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From nobody Sat Aug 15 10:37:28 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC0E1A1A27 for ; Sat, 15 Aug 2015 10:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VhIF-l-TRqUz for ; Sat, 15 Aug 2015 10:37:24 -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 5BBFB1A033A for ; Sat, 15 Aug 2015 10:37:24 -0700 (PDT) Received: by lagz9 with SMTP id z9so58842320lag.3 for ; Sat, 15 Aug 2015 10:37:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=z8QVH4Z6Ged8SzdgM99m78d6Fn0KyDaA/rmk/GFK2QM=; b=OohAM4NBUUw2+z+P2ntB4NM8piBfJz637gC174mm/AwhYdvNUzGJ38JvX4Q1B0Iqwo YBXszNnH4iGzCcea75JT9ssiMyAyMAhgJ9tv7E6IZkh/+qg0EMco1W1wUsJ/fzNtkVgK 2vbRoSREbrq27sg0d72aoL7Ifh5oH4LGJtEMa1K/4HWjxsgMLscr69j4w7vi4QoqgMgb diZ7M2FA/s5ABN3+gutHw+T9y46wevXc+BnWqF5qRC36l7qSs8vh50lKQ66TrTVKTfPh tr8Ibdz0EjJxrIzjfiyuHCYTcI6o8qbGwq2IGh/2IOlamQkCVpmxq+VEv/y5gcIP/Alx f50Q== X-Gm-Message-State: ALoCoQlW1H8bL3OcOuoqlVc8ybLQci1HpKx8aZDfnBFFWyumQQYG47DyHXtR0sxwlX63ueWsz3Kk MIME-Version: 1.0 X-Received: by 10.152.120.74 with SMTP id la10mr43443655lab.37.1439660242910; Sat, 15 Aug 2015 10:37:22 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Sat, 15 Aug 2015 10:37:22 -0700 (PDT) In-Reply-To: <1708085B-AC2F-455D-A5D9-45382F44DB3C@nic.cz> References: <9966516C6EB5FC4381E05BF80AA55F77DC237498@US70UWXCHMBA05.zam.alcatel-lucent.com> <2FA0FBCD-4779-488B-968F-4FD271D506BC@nic.cz> <9966516C6EB5FC4381E05BF80AA55F77DC23755F@US70UWXCHMBA05.zam.alcatel-lucent.com> <1708085B-AC2F-455D-A5D9-45382F44DB3C@nic.cz> Date: Sat, 15 Aug 2015 10:37:22 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=089e01229022605890051d5d05f6 Archived-At: Cc: "Carey, Timothy \(Timothy\)" , "netmod@ietf.org" Subject: Re: [netmod] Constraint on mandatory on nodes as part of augmentation in RFC6020bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2015 17:37:27 -0000 --089e01229022605890051d5d05f6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Aug 15, 2015 at 10:10 AM, Ladislav Lhotka wrote: > > > On 15 Aug 2015, at 18:00, Andy Bierman wrote: > > > > Hi, > > > > If you are using mandatory nodes in augment, it is because you expect > > that all clients will know and implement both modules. > > However YANG has no way to require that. > > A server is NEVER required to implement the augmenting module. > > Are you saying that a server isn=E2=80=99t required to implement modules = that it > advertises? > Of course not. The server is allowed to implement the base module without the augmenting module. It is not required to advertise the augmenting module. A system working this way cannot just add a module later that breaks old clients. The RFC can hand-wave around this, but the tech-support team will still get calls if already deployed code stops working. I suggested a solution called YANG packages. If multiple YANG modules are required to be used together, then the current YANG conformance model is broken. > > There is no text in 6020(bis) supporting this theory. An augmenting modul= e > is an integral part of the data model as any other. > > > > > It doesn't really matter that you are writing these illegal YANG module= s > > all at once. A server is not required to implement them all at once, > > or all of them ever. > > > > It is rather naive to think that the client must understand every YANG > module > > implemented on a server. Even if this were useful, the client will > certainly > > not support modules written after the client code was released. > > Such a client is unsafe because the modules that the client ignores may > imply some important semantics. YANG modules are not perfectly isolated > from each other, and a client may break things if it doesn=E2=80=99t unde= rstand the > interactions. And again, I am not aware of any text in 6020 supporting su= ch > cherry-picking clients. > > There is no text that says if a base module is implemented, then some other modules that augment that module must also be implemented. It is not practical to re-implement a client app every time a new module is added. If you don't like how YANG conformance works then fix it. Just breaking old clients and expecting them to re-code constantly to keep up with every server release is not a solution. > > > > You should be using submodules (written all at once) if you want > > to augment with mandatory nodes. > > In many use cases this is impossible - e.g. for interface types. > There are no augments in the interface types module > > Lada > > > > > Andy > > > Andy > > > > > > > > On Sat, Aug 15, 2015 at 8:39 AM, Carey, Timothy (Timothy) < > timothy.carey@alcatel-lucent.com> wrote: > > Lada, > > > > Yes sorry - I just saw that thread after I submitted mine. > > > > BR, > > Tim > > -----Original Message----- > > From: Ladislav Lhotka [mailto:lhotka@nic.cz] > > Sent: Saturday, August 15, 2015 10:25 AM > > To: Carey, Timothy (Timothy) > > Cc: netmod@ietf.org > > Subject: Re: [netmod] Constraint on mandatory on nodes as part of > augmentation in RFC6020bis > > > > > > > On 15 Aug 2015, at 16:50, Carey, Timothy (Timothy) < > timothy.carey@alcatel-lucent.com> wrote: > > > > > > Team, > > > > > > > > > Section 7.17 The augment statement has verbiage If the target node is > > > in another module, then nodes added by the augmentation MUST NOT be > > > mandatory nodes (see Section 3.1). > > > > > > > > > We are seeing situations where this constraint is invalid =E2=80=93 S= ituations > where a standard builds on another standard and makes parts of the new > standard mandatory. > > > > > > It seems this was an issue in the past where the decision was to get > around this statement with a presence container. > > > > > > Since 6020bis is in progress =E2=80=93 would it be possible to simply= remove > this phrase and allow mandatory nodes as part of the augmentation so we > don=E2=80=99t have to have this artificial workaround? > > > > This is exactly what=E2=80=99s currently being discussed in this thread= : > > > > > https://mailarchive.ietf.org/arch/search/?email_list=3Dnetmod&gbt=3D1&ind= ex=3DES2ogm1wabzZVIIBlrRor0fn3rk > > > > Lada > > > > > > > > Thanks, > > > Tim > > > _______________________________________________ > > > 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 > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --089e01229022605890051d5d05f6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Aug 15, 2015 at 10:10 AM, Ladislav Lhotka <= ;lhotka@nic.cz> wrote:

> On 15 Aug 2015, at 18:00, Andy Bierman <andy@yumaworks.com> wrote:
>
> Hi,
>
> If you are using mandatory nodes in augment, it is because you expect<= br> > that all clients will know and implement both modules.
> However YANG has no way to require that.
> A server is NEVER required to implement the augmenting module.

Are you saying that a server isn=E2=80=99t required to implement modules th= at it advertises?

Of course not.
<= div>The server is allowed to implement the base module without the augmenti= ng module.
It is not required to advertise the augmenting module.=

A system working this way cannot just add a modul= e later that breaks old clients.
The RFC can hand-wave around thi= s, but the tech-support team will still get calls
if already depl= oyed code stops working.

I suggested a solution ca= lled YANG packages. If multiple YANG modules are
required to be u= sed together, then the current YANG conformance model is broken.
=

=C2=A0 =C2=A0=C2=A0

There is no text in 6020(bis) supporting this theory. An augmenting module = is an integral part of the data model as any other.

>
> It doesn't really matter that you are writing these illegal YANG m= odules
> all at once. A server is not required to implement them all at once, > or all of them ever.
>
> It is rather naive to think that the client must understand every YANG= module
> implemented on a server.=C2=A0 Even if this were useful, the client wi= ll certainly
> not support modules written after the client code was released.

Such a client is unsafe because the modules that the client ignores may imp= ly some important semantics. YANG modules are not perfectly isolated from e= ach other, and a client may break things if it doesn=E2=80=99t understand t= he interactions. And again, I am not aware of any text in 6020 supporting s= uch cherry-picking clients.


There is no text that says if =C2=A0a = base module is implemented,
then some other modules that augment = that module must also be implemented.
It is not practical to re-i= mplement a client app every time a new module is added.

If you don't like how YANG conformance works then fix it.
Just breaking old clients and expecting them to re-code constantly
=
to keep up with every server release is not a solution.

=

=C2=A0
>
> You should be using submodules (written all at once) if you want
> to augment with mandatory nodes.

In many use cases this is impossible - e.g. for interface types.

There are no augments in the interface types modu= le
=C2=A0

Lada

>
> Andy
>


Andy
=C2= =A0
>
>
>
> On Sat, Aug 15, 2015 at 8:39 AM, Carey, Timothy (Timothy) <timothy.carey@alcatel-lucent.c= om> wrote:
> Lada,
>
> Yes sorry - I just saw that thread after I submitted mine.
>
> BR,
> Tim
> -----Original Message-----
> From: Ladislav Lhotka [mailto:lhotka@= nic.cz]
> Sent: Saturday, August 15, 2015 10:25 AM
> To: Carey, Timothy (Timothy)
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Constraint on mandatory on nodes as part of augm= entation in RFC6020bis
>
>
> > On 15 Aug 2015, at 16:50, Carey, Timothy (Timothy) <timothy.carey@alcatel-lucent.com<= /a>> wrote:
> >
> > Team,
> >
> >
> > Section 7.17 The augment statement has verbiage If the target nod= e is
> > in another module, then nodes added by the augmentation MUST NOT = be
> > mandatory nodes (see Section 3.1).
> >
> >
> > We are seeing situations where this constraint is invalid =E2=80= =93 Situations where a standard builds on another standard and makes parts = of the new standard mandatory.
> >
> > It seems this was an issue in the past where the decision was to = get around this statement with a presence container.
> >
> > Since 6020bis is in progress =E2=80=93 would it be possible to si= mply remove this phrase and allow mandatory nodes as part of the augmentati= on so we don=E2=80=99t have to have this artificial workaround?
>
> This is exactly what=E2=80=99s currently being discussed in this threa= d:
>
> https://mailarchive.ietf.org/arch/search/?email_list=3Dne= tmod&gbt=3D1&index=3DES2ogm1wabzZVIIBlrRor0fn3rk
>
> Lada
>
> >
> > Thanks,
> > Tim
> > _______________________________________________
> > 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 >

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





--089e01229022605890051d5d05f6-- From nobody Sat Aug 15 10:55:07 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1AB11A21A1 for ; Sat, 15 Aug 2015 10:55:05 -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_42=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 zYK5YFuYjrkb for ; Sat, 15 Aug 2015 10:55:03 -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 F20511A1C06 for ; Sat, 15 Aug 2015 10:55:02 -0700 (PDT) Received: by lbbpu9 with SMTP id pu9so61124036lbb.3 for ; Sat, 15 Aug 2015 10:55:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=35wTkhaHwNMbwgrNUK+d6WfsJ9A88EIvRbSeZ/u3gBA=; b=Tm5yQSZZtZA3txn6+HLkRbJpdGxxFcNUqn8FPsWrcHt0ZPD0sDrmIRzFz/YBMCoOM7 nrE5lyS5ipQh/9UBPF5UImoYM5NqXTGmRFPfaLgHt5ubIPUfEQNnuujUUGX1t2srO6i+ dTnMc/hooge4VhwOqC763SPMAxbKZuarnx4hUhafxYGr/EP07HAtSbTayrA0AOQRXKD+ ofaaRC3VqczwkvkVlvbBCEQljsKcAvAcaxxE9VGQ31JY+VkgDROWc2DXBPZYNxhLrSDS yJR/2zRZyULdxsUkgmiKFJ2QO1tdYtrHyuQpb0OZNceMRCsZCUS66J5dBAmhFJzkJmTz LLQg== X-Gm-Message-State: ALoCoQljhPbmsEjaXi4bf42HjrCGA9ynfVwm52GgCFNtrZ8b4bZZ96+QgI6gndLvPG6/nj0eQ12H MIME-Version: 1.0 X-Received: by 10.152.120.198 with SMTP id le6mr48458463lab.38.1439661301489; Sat, 15 Aug 2015 10:55:01 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Sat, 15 Aug 2015 10:55:01 -0700 (PDT) In-Reply-To: <33267463.1439659400007.JavaMail.root@mswamui-thinleaf.atl.sa.earthlink.net> References: <33267463.1439659400007.JavaMail.root@mswamui-thinleaf.atl.sa.earthlink.net> Date: Sat, 15 Aug 2015 10:55:01 -0700 Message-ID: From: Andy Bierman To: Randy Presuhn Content-Type: multipart/alternative; boundary=089e011769057900d9051d5d4461 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Constraint on mandatory on nodes as part of augmentation in RFC6020bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2015 17:55:06 -0000 --089e011769057900d9051d5d4461 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Aug 15, 2015 at 10:23 AM, Randy Presuhn < randy_presuhn@mindspring.com> wrote: > Hi - > > I know netmod isn't object-oriented, but I think viewing > this through the lens of conformance might be causing us > to miss the conflicting requirements that lead the group > to this impasse. > > RFC 6020 effectively presents us with a way of defining > instantiable classes, and augment functions as a rather > limited way of defining instantiable subclasses. Usage > has given us another requirement: the ability to define > (or at least to designate as noninstantiable) abstract > superclasses. > > I don't see how one can both with the current metamodel, > such as it is. > > I have been trying to change the meta-model (with YANG packages). But that does not fix the problem here -- the notion of what is mandatory for a given data structure can change over time. Yet YANG absolutely does not allow that to happen. It doesn't matter whether 1 module, 2 modules, or submodules are used. All mandatory data must be defined in the first release. SNMP never had this problem because a client can just ignore new monitoring data it receives. A NETCONF client cannot create or replace configuration data that has unknown mandatory nodes. In your analogy, there is an assumed super-class, and the mandatory augments is creating a new sub-class. The problem is the data is all mixed together so a client using the old derived class needs to be insulated from the new derived class (w/ new mandatory nodes). The problem is specifying the rules for insulating the old client. One design pattern we have come up with assumes that the old client does not know about new identityref values, so it won't try to create or replace an entry using a new identity. augment /foo:bar { when "/foo:bar[foo:type=3D'example:new-identity']"; leaf maybe-ok { mandatory true; type string; } } It would be OK with me if this was allowed in YANG. Leave it to Martin to write the text ;-) Randy > Andy > -----Original Message----- > > From: Andy Bierman > > Sent: Aug 15, 2015 9:00 AM > > To: "Carey, Timothy (Timothy)" > > Cc: "netmod@ietf.org" > > Subject: Re: [netmod] Constraint on mandatory on nodes as part of > augmentation in RFC6020bis > > > > Hi, > If you are using mandatory nodes in augment, it is because you expectthat > all clients will know and implement both modules.However YANG has no way = to > require that.A server is NEVER required to implement the augmenting modul= e. > It doesn't really matter that you are writing these illegal YANG > modulesall at once. A server is not required to implement them all at > once,or all of them ever. > It is rather naive to think that the client must understand every YANG > moduleimplemented on a server. Even if this were useful, the client will > certainlynot support modules written after the client code was released. > You should be using submodules (written all at once) if you wantto augmen= t > with mandatory nodes. > Andy > > > > On Sat, Aug 15, 2015 at 8:39 AM, Carey, Timothy (Timothy) < > timothy.carey@alcatel-lucent.com> wrote: > Lada, > > > > Yes sorry - I just saw that thread after I submitted mine. > > > > BR, > > Tim > > -----Original Message----- > > From: Ladislav Lhotka [mailto:lhotka@nic.cz] > > Sent: Saturday, August 15, 2015 10:25 AM > > To: Carey, Timothy (Timothy) > > Cc: netmod@ietf.org > > Subject: Re: [netmod] Constraint on mandatory on nodes as part of > augmentation in RFC6020bis > > > > > > > On 15 Aug 2015, at 16:50, Carey, Timothy (Timothy) < > timothy.carey@alcatel-lucent.com> wrote: > > > > > > Team, > > > > > > > > > Section 7.17 The augment statement has verbiage If the target node is > > > in another module, then nodes added by the augmentation MUST NOT be > > > mandatory nodes (see Section 3.1). > > > > > > > > > We are seeing situations where this constraint is invalid =E2=80=93 Sit= uations > where a standard builds on another standard and makes parts of the new > standard mandatory. > > > > > > It seems this was an issue in the past where the decision was to get > around this statement with a presence container. > > > > > > Since 6020bis is in progress =E2=80=93 would it be possible to simply r= emove > this phrase and allow mandatory nodes as part of the augmentation so we > don=E2=80=99t have to have this artificial workaround? > > > > This is exactly what=E2=80=99s currently being discussed in this thread: > > > > > https://mailarchive.ietf.org/arch/search/?email_list=3Dnetmod&gbt=3D1&ind= ex=3DES2ogm1wabzZVIIBlrRor0fn3rk > > > > Lada > > > > > > > > Thanks, > > > Tim > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --089e011769057900d9051d5d4461 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Aug 15, 2015 at 10:23 AM, Randy Presuhn <<= a href=3D"mailto:randy_presuhn@mindspring.com" target=3D"_blank">randy_pres= uhn@mindspring.com> wrote:
= Hi -

I know netmod isn't object-oriented, but I think viewing
this through the lens of conformance might be causing us
to miss the conflicting requirements that lead the group
to this impasse.

RFC 6020 effectively presents us with a way of defining
instantiable classes, and augment functions as a rather
limited way of defining instantiable subclasses.=C2=A0 Usage
has given us another requirement: the ability to define
(or at least to designate as noninstantiable) abstract
superclasses.

I don't see how one can both with the current metamodel,
such as it is.


I have been trying to change the meta-= model (with YANG packages).
But that does not fix the problem her= e -- the notion of what is mandatory
for a given data structure c= an change over time.=C2=A0 Yet YANG absolutely
does not allow tha= t to happen.=C2=A0 It doesn't matter whether 1 module,
2 modu= les, or submodules are used.=C2=A0 All mandatory data must be defined
in the first release.

SNMP never had this= problem because a client can just ignore new
monitoring data it = receives.=C2=A0 A NETCONF client cannot create or
replace configu= ration data that has unknown mandatory nodes.

In y= our analogy, there is an assumed super-class, and the mandatory
a= ugments is creating a new sub-class.=C2=A0 The problem is the data
is all mixed together so a client using the old derived class needs
=
to be insulated from the new derived class (w/ new mandatory nodes).

The problem is specifying the rules for insulating = the old client.
One design pattern we have come up with assumes t= hat the
old client does not know about new identityref values, so= it
won't try to create or replace an entry using a new ident= ity.

=C2=A0 =C2=A0augment /foo:bar {
=C2= =A0 =C2=A0 =C2=A0 when "/foo:bar[foo:type=3D'example:new-identity&= #39;]";
=C2=A0 =C2=A0 =C2=A0 leaf maybe-ok {
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mandatory true;
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 type string;
=C2=A0 =C2=A0 =C2=A0 }
= =C2=A0 }

It would be OK with me if this was allowe= d in YANG.
Leave it to Martin to write the text ;-)

=C2=A0=C2=A0

Randy


Andy
=C2=A0
-----Original Message-----

From: Andy Bierman

Sent: Aug 15, 2015 9:00 AM

To: "Carey, Timothy (Timothy)"

Cc: "netmod@ietf.org"

Subject: Re: [netmod] Constraint on mandatory on nodes as part of augmentat= ion in RFC6020bis



Hi,
If you are using mandatory nodes in augment, it is because you expectthat a= ll clients will know and implement both modules.However YANG has no way to = require that.A server is NEVER required to implement the augmenting module.=
It doesn't really matter that you are writing these illegal YANG module= sall at once. A server is not required to implement them all at once,or all= of them ever.
It is rather naive to think that the client must understand every YANG modu= leimplemented on a server.=C2=A0 Even if this were useful, the client will = certainlynot support modules written after the client code was released. You should be using submodules (written all at once) if you wantto augment = with mandatory nodes.
Andy



On Sat, Aug 15, 2015 at 8:39 AM, Carey, Timothy (Timothy) <timothy.carey@alcatel-lucent.com= > wrote:
Lada,



Yes sorry - I just saw that thread after I submitted mine.



BR,

Tim

-----Original Message-----

From: Ladislav Lhotka [mailto:lhotka@nic.c= z]

Sent: Saturday, August 15, 2015 10:25 AM

To: Carey, Timothy (Timothy)

Cc: netmod@ietf.org

Subject: Re: [netmod] Constraint on mandatory on nodes as part of augmentat= ion in RFC6020bis





> On 15 Aug 2015, at 16:50, Carey, Timothy (Timothy) <timothy.carey@alcatel-lucent.com&g= t; wrote:

>

> Team,

>

>

> Section 7.17 The augment statement has verbiage If the target node is<= br>
> in another module, then nodes added by the augmentation MUST NOT be
> mandatory nodes (see Section 3.1).

>

>

> We are seeing situations where this constraint is invalid =E2=80=93 Si= tuations where a standard builds on another standard and makes parts of the= new standard mandatory.

>

> It seems this was an issue in the past where the decision was to get a= round this statement with a presence container.

>

> Since 6020bis is in progress =E2=80=93 would it be possible to simply = remove this phrase and allow mandatory nodes as part of the augmentation so= we don=E2=80=99t have to have this artificial workaround?



This is exactly what=E2=80=99s currently being discussed in this thread:


https://mailarchive.ietf.org/arch/search/?email_list=3Dnetmod&= amp;gbt=3D1&index=3DES2ogm1wabzZVIIBlrRor0fn3rk



Lada



>

> Thanks,

> Tim

> _______________________________________________

> netmod mailing list

> netmod@ietf.org

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


--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: E74E8C0C









_______________________________________________

netmod mailing list

netmod@ietf.org

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

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

--089e011769057900d9051d5d4461-- From nobody Sat Aug 15 12:21:13 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79C5C1A88BC for ; Sat, 15 Aug 2015 12:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPhq_h7J0EWe for ; Sat, 15 Aug 2015 12:21:10 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2DC1A88A9 for ; Sat, 15 Aug 2015 12:21:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=cLajPCssWuYYLVFK7AU97vIIYfnR1tLc+tc973oLV2BbRyxWdEVLF+wKxFISYfL+; 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.44] (helo=elwamui-ovcar.atl.sa.earthlink.net) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1ZQh0m-00063j-6G for netmod@ietf.org; Sat, 15 Aug 2015 15:21:00 -0400 Received: from 76.254.49.21 by webmail.earthlink.net with HTTP; Sat, 15 Aug 2015 15:20:59 -0400 Message-ID: <17434045.1439666459949.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> Date: Sat, 15 Aug 2015 12:20:59 -0700 (GMT-07:00) From: Randy Presuhn To: "netmod@ietf.org" Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888ff8848a73c44bba0d16c4f71e9f8c775768fd2ffa9293292350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.44 Archived-At: Subject: Re: [netmod] Constraint on mandatory on nodes as part of augmentation in RFC6020bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2015 19:21:12 -0000 Hi - > From: Andy Bierman > Sent: Aug 15, 2015 10:55 AM > To: Randy Presuhn > Cc: "netmod@ietf.org" > Subject: Re: [netmod] Constraint on mandatory on nodes as part of augmentation in RFC6020bis ... > I have been trying to change the meta-model (with YANG packages). But that > does not fix the problem here -- the notion of what is mandatory for a given > data structure can change over time. Yet YANG absolutely does not allow that > to happen. It doesn't matter whether 1 module, 2 modules, or submodules are > used. All mandatory data must be defined in the first release. It seems to be a little bit worse than that. It sounds like at least some folks would like to be able to define a superclass as an abstract (non- instantiable) class - that is, it could *only* be instantiated with some combination of augmentations. I say it's worse because they appear to have a use case which is incompatible with how augment was intended to work. > SNMP never had this problem because a client can just ignore new monitoring > data it receives. A NETCONF client cannot create or replace configuration > data that has unknown mandatory nodes. I think a better analogy would be to how row creation works in SNMP, specifically with the RowStatus textual convention. The constraints of the SMI force the modeler using AUGMENTS to provide DEFAULTs or DESCRIPTION text to provide the correct values in the AUGMENTS portions of a row, and provide no ability to select *which* of multiple AUGMENTS to instantiate. Whatever an implementation supports MUST be instantiated in a 1:1 relationship with the rows of the base MIB module. Lada's example needs something substantially more powerful, and would not be a good candidate for AUGMENTS in SMI. One question is whether Yang's augment construct is (or can be) the right tool for the job, but another important question is whether this particular type of constraint needs to be represented in machine-interpetable form, or whether this falls in with the host of other constraints on configurations that are only specified in human-readable form, and require hand-coding on the client, server, or both. > In your analogy, there is an assumed super-class, and the mandatory augments > is creating a new sub-class. And in some cases, there seems to be an assumption that for *some* use cases instantiating *just* the superclass without any extension is an invalid configuration. > The problem is the datai s all mixed together so a client using the old > derived class needsto be insulated from the new derived class (w/ new > mandatory nodes). Alternatively, one might say that another way of looking at the problem is that the client cannot distinguish an attempt to instantiate the superclass (which by itself may be operationally forbidden) from a mal-formed attempt to instantiate the subclass. > The problem is specifying the rules for insulating the old client. > One design pattern we have come up with assumes that the old client > does not know about new identityref values, so it won't try to create > or replace an entry using a new identity. This assumes that creating an un-augmented instance was *ever* a meaningful thing to do. I think part of the challenge here is that given the tools we currently have, the alternative is create a bunch of data definitions (classes) that look suspisciously similar, but with no formal representation of their common heritage. Randy From nobody Sat Aug 15 13:00:53 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B47111A89B9 for ; Sat, 15 Aug 2015 13:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XA1s-parSMfx for ; Sat, 15 Aug 2015 13:00:50 -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 DE1FF1A89B8 for ; Sat, 15 Aug 2015 13:00:49 -0700 (PDT) Received: by lahi9 with SMTP id i9so59508452lah.2 for ; Sat, 15 Aug 2015 13:00:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GudZzvPr3LvLVw6Gh0QNaMIj/FaSCGnYZGfgvNg5w0g=; b=hpAA3qgW7k41YrM6NivbGVbda1LL23KGPrCmExBTFiwxYBdylv+nxYRQ6utKI+wPEm Jw90N97GW48TNApl3tkLIYwPfQ007XPrF5GYnMwzUJH//4ObYRpbrtsT+R1oLo5+nHBC coDoTDN1OxQgK3fmAsXlIJtOg+okZ3dAxP3noXeMKgYiZlIFzRXy8o6iR1qlvXYN6wVp ig8NFIHo9yju+0cqX6qyPcJm6n5B2qdQG4ZOVfpuepvCz+xJT72xXBCuE2gKySFz8qNx qLfxNTSFiQhcyKMfE/qhs0JkBtvFCF3xUG1CTPsvE0iDLJe2pb7IuWDvFkq8mK9nRgvV 0eOg== X-Gm-Message-State: ALoCoQmt9xeIzaV+MygKG+tOmNWCdYAN9GC/9e6cS0a60UzlTwixE2h5QzgJDkeFi0/MXKlF0hOX MIME-Version: 1.0 X-Received: by 10.112.154.106 with SMTP id vn10mr38731216lbb.38.1439668848237; Sat, 15 Aug 2015 13:00:48 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Sat, 15 Aug 2015 13:00:48 -0700 (PDT) In-Reply-To: <17434045.1439666459949.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> References: <17434045.1439666459949.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> Date: Sat, 15 Aug 2015 13:00:48 -0700 Message-ID: From: Andy Bierman To: Randy Presuhn Content-Type: multipart/alternative; boundary=089e0122af2a4b37c2051d5f06d7 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Constraint on mandatory on nodes as part of augmentation in RFC6020bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2015 20:00:51 -0000 --089e0122af2a4b37c2051d5f06d7 Content-Type: text/plain; charset=UTF-8 On Sat, Aug 15, 2015 at 12:20 PM, Randy Presuhn < randy_presuhn@mindspring.com> wrote: > Hi - > ...... > > The problem is specifying the rules for insulating the old client. > > One design pattern we have come up with assumes that the old client > > does not know about new identityref values, so it won't try to create > > or replace an entry using a new identity. > > This assumes that creating an un-augmented instance was *ever* a meaningful > thing to do. I think part of the challenge here is that given the tools > we currently have, the alternative is create a bunch of data definitions > (classes) that look suspisciously similar, but with no formal > representation > of their common heritage. > > This is the the core issue. YANG has no way to describe the design pattern Lada wants to use. How about if MUST is changed to SHOULD? Plus add some text saying new mandatory nodes can break old clients using the parent data structure, so care should be taken...etc. It will be up to vendors to keep it sane, or pay the penalty with customers for breaking their applications. Randy > Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --089e0122af2a4b37c2051d5f06d7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Aug 15, 2015 at 12:20 PM, Randy Presuhn <<= a href=3D"mailto:randy_presuhn@mindspring.com" target=3D"_blank">randy_pres= uhn@mindspring.com> wrote:
= Hi -
......
> The problem is specifying the rules for insulating the old client.
> One design pattern we have come up with assumes that the old client > does not know about new identityref values, so it won't try to cre= ate
> or replace an entry using a new identity.

This assumes that creating an un-augmented instance was *ever* a meaningful=
thing to do.=C2=A0 I think part of the challenge here is that given the too= ls
we currently have, the alternative is create a bunch of data definitions (classes) that look suspisciously similar, but with no formal representatio= n
of their common heritage.


This is the the core issue.
= YANG has no way to describe the design pattern Lada wants to use.

How about if MUST is changed to SHOULD?
Plus add = some text saying new mandatory nodes can break
old clients using = the parent data structure,
so care should be taken...etc.

It will be up to vendors to keep it sane, =C2=A0or pay th= e penalty with customers
for breaking their applications.



Randy


Andy
=C2=A0

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

--089e0122af2a4b37c2051d5f06d7-- From nobody Sat Aug 15 16:58:54 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C76ED1B305F for ; Sat, 15 Aug 2015 16:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhaKYxap0N0G for ; Sat, 15 Aug 2015 16:58:47 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F318E1B3061 for ; Sat, 15 Aug 2015 16:58:45 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 368E0E34818C7; Sat, 15 Aug 2015 23:58:38 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id t7FNweCk012010 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 15 Aug 2015 23:58:41 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.167]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Sat, 15 Aug 2015 19:58:41 -0400 From: "Carey, Timothy (Timothy)" To: Andy Bierman , Ladislav Lhotka Thread-Topic: [netmod] Constraint on mandatory on nodes as part of augmentation in RFC6020bis Thread-Index: AdDXaazE/NLkpbHWQ6iOU9qx6uEYXgAJnGwAAAgMWID//8lqgIAAE3yAgAAHnQD//+CbsA== Date: Sat, 15 Aug 2015 23:58:42 +0000 Message-ID: <9966516C6EB5FC4381E05BF80AA55F77DC2377BA@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77DC237498@US70UWXCHMBA05.zam.alcatel-lucent.com> <2FA0FBCD-4779-488B-968F-4FD271D506BC@nic.cz> <9966516C6EB5FC4381E05BF80AA55F77DC23755F@US70UWXCHMBA05.zam.alcatel-lucent.com> <1708085B-AC2F-455D-A5D9-45382F44DB3C@nic.cz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_9966516C6EB5FC4381E05BF80AA55F77DC2377BAUS70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Constraint on mandatory on nodes as part of augmentation in RFC6020bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2015 23:58:49 -0000 --_000_9966516C6EB5FC4381E05BF80AA55F77DC2377BAUS70UWXCHMBA05z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW5keSwNCg0KVGhlIGV4YW1wbGUgd2UgaGF2ZSBpcyBhIG1vZHVsZSB0aGF0IHdlIGFyZSBzdGFu ZGFyZGl6aW5nIHRoYXQgaXMgYXVnbWVudGluZyBhbm90aGVyIHN0YW5kYXJkcyBvcmdhbml6YXRp b24gbW9kdWxlIChlLmcuLCBSRkMgNzIyMykuIFdlIGRpZG7igJl0IGRldmVsb3AgdGhlIG1vZHVs ZSBidXQgd2Ugd2FudCB0byByZXVzZSB0aGUgZ29vZCB3b3JrIG9mIG90aGVyIGJvZGllcyBhcyBt dWNoIGFzIHBvc3NpYmxlLiBTbyB1c2luZyBzdWItbW9kdWxlcyBkb2VzbuKAmXQgc2VlbSBmZWFz aWJsZSBhcyB0aGUgbW9kZWxzIGFyZSBhbHJlYWR5IHB1Ymxpc2hlZCBhcyBhIG1vZHVsZS4NCg0K VGhlc2UgbmV3IG1vZHVsZXMgYXJlIGluZGVlZCBzdGFuZGFyZGl6ZWQgc28gdGhlIGNsaWVudCBh bmQgc2VydmVyIGtub3cgdGhlIHNwZWNpZmljYXRpb24gYW5kIHRoZSDigJhjb250cmFjdOKAmSBh bmQgdGhlIGNsaWVudCBpbnRlcmFjdHMgd2l0aCB0aGUgc2VydmVyIGtub3dpbmcgaG93IHRvIG1h bmFnZSB0aGUgc2VydmVyIHdpdGggdGhpcyBtb2R1bGUgbmFtZS4NCg0KSW5kZWVkIHdlIGxvb2sg YXQgYmFja3dhcmQgY29tcGF0aWJpbGl0eSB3aXRoaW4gdGhlIGNvbnRleHQgb2YgdGhlIG1vZHVs ZSB3aGVuIHdlIHJldmlzZSB0aGUgbW9kdWxlIGZvciB0aGUgdmVyeSByZWFzb24geW91IHN1Z2dl c3QuIFdlIGRvbuKAmXQgd2FudCB0byBicmVhayBvbGQgY2xpZW50cy4gSSBqdXN0IGRvbuKAmXQg dGhpbmsgdGhhdCBpcyB2YWxpZCBmb3IgdGhlIGZpcnN0IHJldmlzaW9uIG9mIGEgbW9kdWxlLg0K DQpCUiwNClRpbQ0KDQpGcm9tOiBBbmR5IEJpZXJtYW4gW21haWx0bzphbmR5QHl1bWF3b3Jrcy5j b21dDQpTZW50OiBTYXR1cmRheSwgQXVndXN0IDE1LCAyMDE1IDEyOjM3IFBNDQpUbzogTGFkaXNs YXYgTGhvdGthDQpDYzogQ2FyZXksIFRpbW90aHkgKFRpbW90aHkpOyBuZXRtb2RAaWV0Zi5vcmcN ClN1YmplY3Q6IFJlOiBbbmV0bW9kXSBDb25zdHJhaW50IG9uIG1hbmRhdG9yeSBvbiBub2RlcyBh cyBwYXJ0IG9mIGF1Z21lbnRhdGlvbiBpbiBSRkM2MDIwYmlzDQoNCg0KDQpPbiBTYXQsIEF1ZyAx NSwgMjAxNSBhdCAxMDoxMCBBTSwgTGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PG1haWx0 bzpsaG90a2FAbmljLmN6Pj4gd3JvdGU6DQoNCj4gT24gMTUgQXVnIDIwMTUsIGF0IDE4OjAwLCBB bmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbTxtYWlsdG86YW5keUB5dW1hd29ya3MuY29t Pj4gd3JvdGU6DQo+DQo+IEhpLA0KPg0KPiBJZiB5b3UgYXJlIHVzaW5nIG1hbmRhdG9yeSBub2Rl cyBpbiBhdWdtZW50LCBpdCBpcyBiZWNhdXNlIHlvdSBleHBlY3QNCj4gdGhhdCBhbGwgY2xpZW50 cyB3aWxsIGtub3cgYW5kIGltcGxlbWVudCBib3RoIG1vZHVsZXMuDQo+IEhvd2V2ZXIgWUFORyBo YXMgbm8gd2F5IHRvIHJlcXVpcmUgdGhhdC4NCj4gQSBzZXJ2ZXIgaXMgTkVWRVIgcmVxdWlyZWQg dG8gaW1wbGVtZW50IHRoZSBhdWdtZW50aW5nIG1vZHVsZS4NCg0KQXJlIHlvdSBzYXlpbmcgdGhh dCBhIHNlcnZlciBpc27igJl0IHJlcXVpcmVkIHRvIGltcGxlbWVudCBtb2R1bGVzIHRoYXQgaXQg YWR2ZXJ0aXNlcz8NCg0KT2YgY291cnNlIG5vdC4NClRoZSBzZXJ2ZXIgaXMgYWxsb3dlZCB0byBp bXBsZW1lbnQgdGhlIGJhc2UgbW9kdWxlIHdpdGhvdXQgdGhlIGF1Z21lbnRpbmcgbW9kdWxlLg0K SXQgaXMgbm90IHJlcXVpcmVkIHRvIGFkdmVydGlzZSB0aGUgYXVnbWVudGluZyBtb2R1bGUuDQoN CkEgc3lzdGVtIHdvcmtpbmcgdGhpcyB3YXkgY2Fubm90IGp1c3QgYWRkIGEgbW9kdWxlIGxhdGVy IHRoYXQgYnJlYWtzIG9sZCBjbGllbnRzLg0KVGhlIFJGQyBjYW4gaGFuZC13YXZlIGFyb3VuZCB0 aGlzLCBidXQgdGhlIHRlY2gtc3VwcG9ydCB0ZWFtIHdpbGwgc3RpbGwgZ2V0IGNhbGxzDQppZiBh bHJlYWR5IGRlcGxveWVkIGNvZGUgc3RvcHMgd29ya2luZy4NCg0KSSBzdWdnZXN0ZWQgYSBzb2x1 dGlvbiBjYWxsZWQgWUFORyBwYWNrYWdlcy4gSWYgbXVsdGlwbGUgWUFORyBtb2R1bGVzIGFyZQ0K cmVxdWlyZWQgdG8gYmUgdXNlZCB0b2dldGhlciwgdGhlbiB0aGUgY3VycmVudCBZQU5HIGNvbmZv cm1hbmNlIG1vZGVsIGlzIGJyb2tlbi4NCg0KDQoNCg0KVGhlcmUgaXMgbm8gdGV4dCBpbiA2MDIw KGJpcykgc3VwcG9ydGluZyB0aGlzIHRoZW9yeS4gQW4gYXVnbWVudGluZyBtb2R1bGUgaXMgYW4g aW50ZWdyYWwgcGFydCBvZiB0aGUgZGF0YSBtb2RlbCBhcyBhbnkgb3RoZXIuDQoNCj4NCj4gSXQg ZG9lc24ndCByZWFsbHkgbWF0dGVyIHRoYXQgeW91IGFyZSB3cml0aW5nIHRoZXNlIGlsbGVnYWwg WUFORyBtb2R1bGVzDQo+IGFsbCBhdCBvbmNlLiBBIHNlcnZlciBpcyBub3QgcmVxdWlyZWQgdG8g aW1wbGVtZW50IHRoZW0gYWxsIGF0IG9uY2UsDQo+IG9yIGFsbCBvZiB0aGVtIGV2ZXIuDQo+DQo+ IEl0IGlzIHJhdGhlciBuYWl2ZSB0byB0aGluayB0aGF0IHRoZSBjbGllbnQgbXVzdCB1bmRlcnN0 YW5kIGV2ZXJ5IFlBTkcgbW9kdWxlDQo+IGltcGxlbWVudGVkIG9uIGEgc2VydmVyLiAgRXZlbiBp ZiB0aGlzIHdlcmUgdXNlZnVsLCB0aGUgY2xpZW50IHdpbGwgY2VydGFpbmx5DQo+IG5vdCBzdXBw b3J0IG1vZHVsZXMgd3JpdHRlbiBhZnRlciB0aGUgY2xpZW50IGNvZGUgd2FzIHJlbGVhc2VkLg0K DQpTdWNoIGEgY2xpZW50IGlzIHVuc2FmZSBiZWNhdXNlIHRoZSBtb2R1bGVzIHRoYXQgdGhlIGNs aWVudCBpZ25vcmVzIG1heSBpbXBseSBzb21lIGltcG9ydGFudCBzZW1hbnRpY3MuIFlBTkcgbW9k dWxlcyBhcmUgbm90IHBlcmZlY3RseSBpc29sYXRlZCBmcm9tIGVhY2ggb3RoZXIsIGFuZCBhIGNs aWVudCBtYXkgYnJlYWsgdGhpbmdzIGlmIGl0IGRvZXNu4oCZdCB1bmRlcnN0YW5kIHRoZSBpbnRl cmFjdGlvbnMuIEFuZCBhZ2FpbiwgSSBhbSBub3QgYXdhcmUgb2YgYW55IHRleHQgaW4gNjAyMCBz dXBwb3J0aW5nIHN1Y2ggY2hlcnJ5LXBpY2tpbmcgY2xpZW50cy4NCg0KVGhlcmUgaXMgbm8gdGV4 dCB0aGF0IHNheXMgaWYgIGEgYmFzZSBtb2R1bGUgaXMgaW1wbGVtZW50ZWQsDQp0aGVuIHNvbWUg b3RoZXIgbW9kdWxlcyB0aGF0IGF1Z21lbnQgdGhhdCBtb2R1bGUgbXVzdCBhbHNvIGJlIGltcGxl bWVudGVkLg0KSXQgaXMgbm90IHByYWN0aWNhbCB0byByZS1pbXBsZW1lbnQgYSBjbGllbnQgYXBw IGV2ZXJ5IHRpbWUgYSBuZXcgbW9kdWxlIGlzIGFkZGVkLg0KDQpJZiB5b3UgZG9uJ3QgbGlrZSBo b3cgWUFORyBjb25mb3JtYW5jZSB3b3JrcyB0aGVuIGZpeCBpdC4NCkp1c3QgYnJlYWtpbmcgb2xk IGNsaWVudHMgYW5kIGV4cGVjdGluZyB0aGVtIHRvIHJlLWNvZGUgY29uc3RhbnRseQ0KdG8ga2Vl cCB1cCB3aXRoIGV2ZXJ5IHNlcnZlciByZWxlYXNlIGlzIG5vdCBhIHNvbHV0aW9uLg0KDQoNCg0K Pg0KPiBZb3Ugc2hvdWxkIGJlIHVzaW5nIHN1Ym1vZHVsZXMgKHdyaXR0ZW4gYWxsIGF0IG9uY2Up IGlmIHlvdSB3YW50DQo+IHRvIGF1Z21lbnQgd2l0aCBtYW5kYXRvcnkgbm9kZXMuDQoNCkluIG1h bnkgdXNlIGNhc2VzIHRoaXMgaXMgaW1wb3NzaWJsZSAtIGUuZy4gZm9yIGludGVyZmFjZSB0eXBl cy4NCg0KVGhlcmUgYXJlIG5vIGF1Z21lbnRzIGluIHRoZSBpbnRlcmZhY2UgdHlwZXMgbW9kdWxl DQoNCg0KTGFkYQ0KDQo+DQo+IEFuZHkNCj4NCg0KDQpBbmR5DQoNCj4NCj4NCj4NCj4gT24gU2F0 LCBBdWcgMTUsIDIwMTUgYXQgODozOSBBTSwgQ2FyZXksIFRpbW90aHkgKFRpbW90aHkpIDx0aW1v dGh5LmNhcmV5QGFsY2F0ZWwtbHVjZW50LmNvbTxtYWlsdG86dGltb3RoeS5jYXJleUBhbGNhdGVs LWx1Y2VudC5jb20+PiB3cm90ZToNCj4gTGFkYSwNCj4NCj4gWWVzIHNvcnJ5IC0gSSBqdXN0IHNh dyB0aGF0IHRocmVhZCBhZnRlciBJIHN1Ym1pdHRlZCBtaW5lLg0KPg0KPiBCUiwNCj4gVGltDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IExhZGlzbGF2IExob3RrYSBbbWFp bHRvOmxob3RrYUBuaWMuY3o8bWFpbHRvOmxob3RrYUBuaWMuY3o+XQ0KPiBTZW50OiBTYXR1cmRh eSwgQXVndXN0IDE1LCAyMDE1IDEwOjI1IEFNDQo+IFRvOiBDYXJleSwgVGltb3RoeSAoVGltb3Ro eSkNCj4gQ2M6IG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0KPiBTdWJq ZWN0OiBSZTogW25ldG1vZF0gQ29uc3RyYWludCBvbiBtYW5kYXRvcnkgb24gbm9kZXMgYXMgcGFy dCBvZiBhdWdtZW50YXRpb24gaW4gUkZDNjAyMGJpcw0KPg0KPg0KPiA+IE9uIDE1IEF1ZyAyMDE1 LCBhdCAxNjo1MCwgQ2FyZXksIFRpbW90aHkgKFRpbW90aHkpIDx0aW1vdGh5LmNhcmV5QGFsY2F0 ZWwtbHVjZW50LmNvbTxtYWlsdG86dGltb3RoeS5jYXJleUBhbGNhdGVsLWx1Y2VudC5jb20+PiB3 cm90ZToNCj4gPg0KPiA+IFRlYW0sDQo+ID4NCj4gPg0KPiA+IFNlY3Rpb24gNy4xNyBUaGUgYXVn bWVudCBzdGF0ZW1lbnQgaGFzIHZlcmJpYWdlIElmIHRoZSB0YXJnZXQgbm9kZSBpcw0KPiA+IGlu IGFub3RoZXIgbW9kdWxlLCB0aGVuIG5vZGVzIGFkZGVkIGJ5IHRoZSBhdWdtZW50YXRpb24gTVVT VCBOT1QgYmUNCj4gPiBtYW5kYXRvcnkgbm9kZXMgKHNlZSBTZWN0aW9uIDMuMSkuDQo+ID4NCj4g Pg0KPiA+IFdlIGFyZSBzZWVpbmcgc2l0dWF0aW9ucyB3aGVyZSB0aGlzIGNvbnN0cmFpbnQgaXMg aW52YWxpZCDigJMgU2l0dWF0aW9ucyB3aGVyZSBhIHN0YW5kYXJkIGJ1aWxkcyBvbiBhbm90aGVy IHN0YW5kYXJkIGFuZCBtYWtlcyBwYXJ0cyBvZiB0aGUgbmV3IHN0YW5kYXJkIG1hbmRhdG9yeS4N Cj4gPg0KPiA+IEl0IHNlZW1zIHRoaXMgd2FzIGFuIGlzc3VlIGluIHRoZSBwYXN0IHdoZXJlIHRo ZSBkZWNpc2lvbiB3YXMgdG8gZ2V0IGFyb3VuZCB0aGlzIHN0YXRlbWVudCB3aXRoIGEgcHJlc2Vu Y2UgY29udGFpbmVyLg0KPiA+DQo+ID4gU2luY2UgNjAyMGJpcyBpcyBpbiBwcm9ncmVzcyDigJMg d291bGQgaXQgYmUgcG9zc2libGUgdG8gc2ltcGx5IHJlbW92ZSB0aGlzIHBocmFzZSBhbmQgYWxs b3cgbWFuZGF0b3J5IG5vZGVzIGFzIHBhcnQgb2YgdGhlIGF1Z21lbnRhdGlvbiBzbyB3ZSBkb27i gJl0IGhhdmUgdG8gaGF2ZSB0aGlzIGFydGlmaWNpYWwgd29ya2Fyb3VuZD8NCj4NCj4gVGhpcyBp cyBleGFjdGx5IHdoYXTigJlzIGN1cnJlbnRseSBiZWluZyBkaXNjdXNzZWQgaW4gdGhpcyB0aHJl YWQ6DQo+DQo+IGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9zZWFyY2gvP2VtYWls X2xpc3Q9bmV0bW9kJmdidD0xJmluZGV4PUVTMm9nbTF3YWJ6WlZJSUJsclJvcjBmbjNyaw0KPg0K PiBMYWRhDQo+DQo+ID4NCj4gPiBUaGFua3MsDQo+ID4gVGltDQo+ID4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBuZXRtb2QgbWFpbGluZyBsaXN0 DQo+ID4gbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQo+ID4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4NCj4gLS0NCj4gTGFkaXNs YXYgTGhvdGthLCBDWi5OSUMgTGFicw0KPiBQR1AgS2V5IElEOiBFNzRFOEMwQw0KPg0KPg0KPg0K Pg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBu ZXRtb2QgbWFpbGluZyBsaXN0DQo+IG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYu b3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPg0K DQotLQ0KTGFkaXNsYXYgTGhvdGthLCBDWi5OSUMgTGFicw0KUEdQIEtleSBJRDogRTc0RThDMEMN Cg0KDQoNCg0K --_000_9966516C6EB5FC4381E05BF80AA55F77DC2377BAUS70UWXCHMBA05z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiVHJlYnVjaGV0IE1T IjsNCglwYW5vc2UtMToyIDExIDYgMyAyIDIgMiAyIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9u cyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46 MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVy bGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IlRyZWJ1Y2hldCBNUyIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtUcmVi dWNoZXQgTVMmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BbmR5 LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBleGFtcGxlIHdlIGhhdmUgaXMgYSBtb2R1bGUgdGhh dCB3ZSBhcmUgc3RhbmRhcmRpemluZyB0aGF0IGlzIGF1Z21lbnRpbmcgYW5vdGhlciBzdGFuZGFy ZHMgb3JnYW5pemF0aW9uIG1vZHVsZSAoZS5nLiwgUkZDIDcyMjMpLiBXZSBkaWRu4oCZdCBkZXZl bG9wDQogdGhlIG1vZHVsZSBidXQgd2Ugd2FudCB0byByZXVzZSB0aGUgZ29vZCB3b3JrIG9mIG90 aGVyIGJvZGllcyBhcyBtdWNoIGFzIHBvc3NpYmxlLiBTbyB1c2luZyBzdWItbW9kdWxlcyBkb2Vz buKAmXQgc2VlbSBmZWFzaWJsZSBhcyB0aGUgbW9kZWxzIGFyZSBhbHJlYWR5IHB1Ymxpc2hlZCBh cyBhIG1vZHVsZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQg TVMmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGVzZSBuZXcgbW9kdWxlcyBhcmUgaW5k ZWVkIHN0YW5kYXJkaXplZCBzbyB0aGUgY2xpZW50IGFuZCBzZXJ2ZXIga25vdyB0aGUgc3BlY2lm aWNhdGlvbiBhbmQgdGhlIOKAmGNvbnRyYWN04oCZIGFuZCB0aGUgY2xpZW50IGludGVyYWN0cyB3 aXRoIHRoZSBzZXJ2ZXIga25vd2luZw0KIGhvdyB0byBtYW5hZ2UgdGhlIHNlcnZlciB3aXRoIHRo aXMgbW9kdWxlIG5hbWUuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1 Y2hldCBNUyZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkluZGVlZCB3ZSBsb29rIGF0IGJh Y2t3YXJkIGNvbXBhdGliaWxpdHkgd2l0aGluIHRoZSBjb250ZXh0IG9mIHRoZSBtb2R1bGUgd2hl biB3ZSByZXZpc2UgdGhlIG1vZHVsZSBmb3IgdGhlIHZlcnkgcmVhc29uIHlvdSBzdWdnZXN0LiBX ZSBkb27igJl0IHdhbnQgdG8gYnJlYWsNCiBvbGQgY2xpZW50cy4gSSBqdXN0IGRvbuKAmXQgdGhp bmsgdGhhdCBpcyB2YWxpZCBmb3IgdGhlIGZpcnN0IHJldmlzaW9uIG9mIGEgbW9kdWxlLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkJSLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Ry ZWJ1Y2hldCBNUyZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRp bTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiBBbmR5IEJpZXJtYW4gW21haWx0bzphbmR5QHl1bWF3b3Jrcy5j b21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gU2F0dXJkYXksIEF1Z3VzdCAxNSwgMjAxNSAxMjozNyBQ TTxicj4NCjxiPlRvOjwvYj4gTGFkaXNsYXYgTGhvdGthPGJyPg0KPGI+Q2M6PC9iPiBDYXJleSwg VGltb3RoeSAoVGltb3RoeSk7IG5ldG1vZEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW25ldG1vZF0gQ29uc3RyYWludCBvbiBtYW5kYXRvcnkgb24gbm9kZXMgYXMgcGFydCBvZiBh dWdtZW50YXRpb24gaW4gUkZDNjAyMGJpczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gU2F0LCBBdWcgMTUsIDIwMTUgYXQgMTA6MTAgQU0sIExhZGlzbGF2IExob3RrYSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmxob3RrYUBuaWMuY3oiIHRhcmdldD0iX2JsYW5rIj5saG90a2FAbmlj LmN6PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YnI+DQomZ3Q7IE9uIDE1IEF1ZyAyMDE1LCBhdCAxODowMCwgQW5keSBCaWVybWFuICZsdDs8YSBo cmVmPSJtYWlsdG86YW5keUB5dW1hd29ya3MuY29tIj5hbmR5QHl1bWF3b3Jrcy5jb208L2E+Jmd0 OyB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBIaSw8YnI+DQomZ3Q7PGJyPg0KJmd0OyBJZiB5 b3UgYXJlIHVzaW5nIG1hbmRhdG9yeSBub2RlcyBpbiBhdWdtZW50LCBpdCBpcyBiZWNhdXNlIHlv dSBleHBlY3Q8YnI+DQomZ3Q7IHRoYXQgYWxsIGNsaWVudHMgd2lsbCBrbm93IGFuZCBpbXBsZW1l bnQgYm90aCBtb2R1bGVzLjxicj4NCiZndDsgSG93ZXZlciBZQU5HIGhhcyBubyB3YXkgdG8gcmVx dWlyZSB0aGF0Ljxicj4NCiZndDsgQSBzZXJ2ZXIgaXMgTkVWRVIgcmVxdWlyZWQgdG8gaW1wbGVt ZW50IHRoZSBhdWdtZW50aW5nIG1vZHVsZS48YnI+DQo8YnI+DQpBcmUgeW91IHNheWluZyB0aGF0 IGEgc2VydmVyIGlzbuKAmXQgcmVxdWlyZWQgdG8gaW1wbGVtZW50IG1vZHVsZXMgdGhhdCBpdCBh ZHZlcnRpc2VzPzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T2YgY291cnNlIG5vdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoZSBzZXJ2ZXIgaXMgYWxsb3dlZCB0byBpbXBsZW1lbnQgdGhlIGJhc2UgbW9k dWxlIHdpdGhvdXQgdGhlIGF1Z21lbnRpbmcgbW9kdWxlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgaXMgbm90IHJlcXVpcmVkIHRvIGFkdmVy dGlzZSB0aGUgYXVnbWVudGluZyBtb2R1bGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkEgc3lzdGVtIHdvcmtpbmcgdGhpcyB3YXkgY2Fubm90 IGp1c3QgYWRkIGEgbW9kdWxlIGxhdGVyIHRoYXQgYnJlYWtzIG9sZCBjbGllbnRzLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIFJGQyBjYW4g aGFuZC13YXZlIGFyb3VuZCB0aGlzLCBidXQgdGhlIHRlY2gtc3VwcG9ydCB0ZWFtIHdpbGwgc3Rp bGwgZ2V0IGNhbGxzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5pZiBhbHJlYWR5IGRlcGxveWVkIGNvZGUgc3RvcHMgd29ya2luZy48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBzdWdnZXN0ZWQg YSBzb2x1dGlvbiBjYWxsZWQgWUFORyBwYWNrYWdlcy4gSWYgbXVsdGlwbGUgWUFORyBtb2R1bGVz IGFyZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ cmVxdWlyZWQgdG8gYmUgdXNlZCB0b2dldGhlciwgdGhlbiB0aGUgY3VycmVudCBZQU5HIGNvbmZv cm1hbmNlIG1vZGVsIGlzIGJyb2tlbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxicj4NClRoZXJlIGlzIG5vIHRleHQgaW4gNjAyMChiaXMpIHN1cHBv cnRpbmcgdGhpcyB0aGVvcnkuIEFuIGF1Z21lbnRpbmcgbW9kdWxlIGlzIGFuIGludGVncmFsIHBh cnQgb2YgdGhlIGRhdGEgbW9kZWwgYXMgYW55IG90aGVyLjxicj4NCjxicj4NCiZndDs8YnI+DQom Z3Q7IEl0IGRvZXNuJ3QgcmVhbGx5IG1hdHRlciB0aGF0IHlvdSBhcmUgd3JpdGluZyB0aGVzZSBp bGxlZ2FsIFlBTkcgbW9kdWxlczxicj4NCiZndDsgYWxsIGF0IG9uY2UuIEEgc2VydmVyIGlzIG5v dCByZXF1aXJlZCB0byBpbXBsZW1lbnQgdGhlbSBhbGwgYXQgb25jZSw8YnI+DQomZ3Q7IG9yIGFs bCBvZiB0aGVtIGV2ZXIuPGJyPg0KJmd0Ozxicj4NCiZndDsgSXQgaXMgcmF0aGVyIG5haXZlIHRv IHRoaW5rIHRoYXQgdGhlIGNsaWVudCBtdXN0IHVuZGVyc3RhbmQgZXZlcnkgWUFORyBtb2R1bGU8 YnI+DQomZ3Q7IGltcGxlbWVudGVkIG9uIGEgc2VydmVyLiZuYnNwOyBFdmVuIGlmIHRoaXMgd2Vy ZSB1c2VmdWwsIHRoZSBjbGllbnQgd2lsbCBjZXJ0YWlubHk8YnI+DQomZ3Q7IG5vdCBzdXBwb3J0 IG1vZHVsZXMgd3JpdHRlbiBhZnRlciB0aGUgY2xpZW50IGNvZGUgd2FzIHJlbGVhc2VkLjxicj4N Cjxicj4NClN1Y2ggYSBjbGllbnQgaXMgdW5zYWZlIGJlY2F1c2UgdGhlIG1vZHVsZXMgdGhhdCB0 aGUgY2xpZW50IGlnbm9yZXMgbWF5IGltcGx5IHNvbWUgaW1wb3J0YW50IHNlbWFudGljcy4gWUFO RyBtb2R1bGVzIGFyZSBub3QgcGVyZmVjdGx5IGlzb2xhdGVkIGZyb20gZWFjaCBvdGhlciwgYW5k IGEgY2xpZW50IG1heSBicmVhayB0aGluZ3MgaWYgaXQgZG9lc27igJl0IHVuZGVyc3RhbmQgdGhl IGludGVyYWN0aW9ucy4gQW5kIGFnYWluLCBJIGFtIG5vdCBhd2FyZQ0KIG9mIGFueSB0ZXh0IGlu IDYwMjAgc3VwcG9ydGluZyBzdWNoIGNoZXJyeS1waWNraW5nIGNsaWVudHMuPG86cD48L286cD48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVyZSBp cyBubyB0ZXh0IHRoYXQgc2F5cyBpZiAmbmJzcDthIGJhc2UgbW9kdWxlIGlzIGltcGxlbWVudGVk LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhl biBzb21lIG90aGVyIG1vZHVsZXMgdGhhdCBhdWdtZW50IHRoYXQgbW9kdWxlIG11c3QgYWxzbyBi ZSBpbXBsZW1lbnRlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkl0IGlzIG5vdCBwcmFjdGljYWwgdG8gcmUtaW1wbGVtZW50IGEgY2xpZW50IGFw cCBldmVyeSB0aW1lIGEgbmV3IG1vZHVsZSBpcyBhZGRlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgeW91IGRvbid0IGxpa2UgaG93IFlB TkcgY29uZm9ybWFuY2Ugd29ya3MgdGhlbiBmaXggaXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KdXN0IGJyZWFraW5nIG9sZCBjbGllbnRzIGFu ZCBleHBlY3RpbmcgdGhlbSB0byByZS1jb2RlIGNvbnN0YW50bHk8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRvIGtlZXAgdXAgd2l0aCBldmVyeSBz ZXJ2ZXIgcmVsZWFzZSBpcyBub3QgYSBzb2x1dGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDs8YnI+DQomZ3Q7IFlv dSBzaG91bGQgYmUgdXNpbmcgc3VibW9kdWxlcyAod3JpdHRlbiBhbGwgYXQgb25jZSkgaWYgeW91 IHdhbnQ8YnI+DQomZ3Q7IHRvIGF1Z21lbnQgd2l0aCBtYW5kYXRvcnkgbm9kZXMuPGJyPg0KPGJy Pg0KSW4gbWFueSB1c2UgY2FzZXMgdGhpcyBpcyBpbXBvc3NpYmxlIC0gZS5nLiBmb3IgaW50ZXJm YWNlIHR5cGVzLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhlcmUgYXJlIG5vIGF1Z21lbnRzIGluIHRoZSBpbnRlcmZhY2UgdHlw ZXMgbW9kdWxlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxicj4NCkxhZGE8YnI+DQo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBBbmR5PGJy Pg0KJmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5BbmR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+Jmd0Ozxi cj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbiBTYXQsIEF1ZyAxNSwgMjAxNSBhdCA4OjM5 IEFNLCBDYXJleSwgVGltb3RoeSAoVGltb3RoeSkgJmx0OzxhIGhyZWY9Im1haWx0bzp0aW1vdGh5 LmNhcmV5QGFsY2F0ZWwtbHVjZW50LmNvbSI+dGltb3RoeS5jYXJleUBhbGNhdGVsLWx1Y2VudC5j b208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7IExhZGEsPGJyPg0KJmd0Ozxicj4NCiZndDsgWWVz IHNvcnJ5IC0gSSBqdXN0IHNhdyB0aGF0IHRocmVhZCBhZnRlciBJIHN1Ym1pdHRlZCBtaW5lLjxi cj4NCiZndDs8YnI+DQomZ3Q7IEJSLDxicj4NCiZndDsgVGltPGJyPg0KJmd0OyAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgRnJvbTogTGFkaXNsYXYgTGhvdGthIFttYWlsdG86 PGEgaHJlZj0ibWFpbHRvOmxob3RrYUBuaWMuY3oiPmxob3RrYUBuaWMuY3o8L2E+XTxicj4NCiZn dDsgU2VudDogU2F0dXJkYXksIEF1Z3VzdCAxNSwgMjAxNSAxMDoyNSBBTTxicj4NCiZndDsgVG86 IENhcmV5LCBUaW1vdGh5IChUaW1vdGh5KTxicj4NCiZndDsgQ2M6IDxhIGhyZWY9Im1haWx0bzpu ZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IFN1YmplY3Q6IFJl OiBbbmV0bW9kXSBDb25zdHJhaW50IG9uIG1hbmRhdG9yeSBvbiBub2RlcyBhcyBwYXJ0IG9mIGF1 Z21lbnRhdGlvbiBpbiBSRkM2MDIwYmlzPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7ICZn dDsgT24gMTUgQXVnIDIwMTUsIGF0IDE2OjUwLCBDYXJleSwgVGltb3RoeSAoVGltb3RoeSkgJmx0 OzxhIGhyZWY9Im1haWx0bzp0aW1vdGh5LmNhcmV5QGFsY2F0ZWwtbHVjZW50LmNvbSI+dGltb3Ro eS5jYXJleUBhbGNhdGVsLWx1Y2VudC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDsgVGVhbSw8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDsgU2VjdGlvbiA3LjE3IFRoZSBhdWdtZW50IHN0YXRlbWVudCBoYXMgdmVyYmlhZ2Ug SWYgdGhlIHRhcmdldCBub2RlIGlzPGJyPg0KJmd0OyAmZ3Q7IGluIGFub3RoZXIgbW9kdWxlLCB0 aGVuIG5vZGVzIGFkZGVkIGJ5IHRoZSBhdWdtZW50YXRpb24gTVVTVCBOT1QgYmU8YnI+DQomZ3Q7 ICZndDsgbWFuZGF0b3J5IG5vZGVzIChzZWUgU2VjdGlvbiAzLjEpLjxicj4NCiZndDsgJmd0Ozxi cj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBXZSBhcmUgc2VlaW5nIHNpdHVhdGlvbnMgd2hl cmUgdGhpcyBjb25zdHJhaW50IGlzIGludmFsaWQg4oCTIFNpdHVhdGlvbnMgd2hlcmUgYSBzdGFu ZGFyZCBidWlsZHMgb24gYW5vdGhlciBzdGFuZGFyZCBhbmQgbWFrZXMgcGFydHMgb2YgdGhlIG5l dyBzdGFuZGFyZCBtYW5kYXRvcnkuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEl0IHNl ZW1zIHRoaXMgd2FzIGFuIGlzc3VlIGluIHRoZSBwYXN0IHdoZXJlIHRoZSBkZWNpc2lvbiB3YXMg dG8gZ2V0IGFyb3VuZCB0aGlzIHN0YXRlbWVudCB3aXRoIGEgcHJlc2VuY2UgY29udGFpbmVyLjxi cj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBTaW5jZSA2MDIwYmlzIGlzIGluIHByb2dyZXNz IOKAkyB3b3VsZCBpdCBiZSBwb3NzaWJsZSB0byBzaW1wbHkgcmVtb3ZlIHRoaXMgcGhyYXNlIGFu ZCBhbGxvdyBtYW5kYXRvcnkgbm9kZXMgYXMgcGFydCBvZiB0aGUgYXVnbWVudGF0aW9uIHNvIHdl IGRvbuKAmXQgaGF2ZSB0byBoYXZlIHRoaXMgYXJ0aWZpY2lhbCB3b3JrYXJvdW5kPzxicj4NCiZn dDs8YnI+DQomZ3Q7IFRoaXMgaXMgZXhhY3RseSB3aGF04oCZcyBjdXJyZW50bHkgYmVpbmcgZGlz Y3Vzc2VkIGluIHRoaXMgdGhyZWFkOjxicj4NCiZndDs8YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBz Oi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9zZWFyY2gvP2VtYWlsX2xpc3Q9bmV0bW9kJmFt cDtnYnQ9MSZhbXA7aW5kZXg9RVMyb2dtMXdhYnpaVklJQmxyUm9yMGZuM3JrIiB0YXJnZXQ9Il9i bGFuayI+DQpodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvc2VhcmNoLz9lbWFpbF9s aXN0PW5ldG1vZCZhbXA7Z2J0PTEmYW1wO2luZGV4PUVTMm9nbTF3YWJ6WlZJSUJsclJvcjBmbjNy azwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0OyBMYWRhPGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0Ozxi cj4NCiZndDsgJmd0OyBUaGFua3MsPGJyPg0KJmd0OyAmZ3Q7IFRpbTxicj4NCiZndDsgJmd0OyBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsg Jmd0OyBuZXRtb2QgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzpu ZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZndDsgPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZDwvYT48 YnI+DQomZ3Q7PGJyPg0KJmd0OyAtLTxicj4NCiZndDsgTGFkaXNsYXYgTGhvdGthLCBDWi5OSUMg TGFiczxicj4NCiZndDsgUEdQIEtleSBJRDogRTc0RThDMEM8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxi cj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgbmV0bW9kIG1haWxpbmcgbGlzdDxicj4NCiZn dDsgPGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+bmV0bW9kQGlldGYub3JnPC9hPjxi cj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u ZXRtb2QiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL25ldG1vZDwvYT48YnI+DQomZ3Q7PGJyPg0KPGJyPg0KLS08YnI+DQpMYWRpc2xhdiBMaG90 a2EsIENaLk5JQyBMYWJzPGJyPg0KUEdQIEtleSBJRDogRTc0RThDMEM8YnI+DQo8YnI+DQo8YnI+ DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_9966516C6EB5FC4381E05BF80AA55F77DC2377BAUS70UWXCHMBA05z_-- From nobody Sat Aug 15 17:33:35 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 716D11B3096 for ; Sat, 15 Aug 2015 17:33:34 -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 aaZTX1EZy-n3 for ; Sat, 15 Aug 2015 17:33:31 -0700 (PDT) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D86D71B3094 for ; Sat, 15 Aug 2015 17:33:30 -0700 (PDT) Received: by lbbpu9 with SMTP id pu9so63458625lbb.3 for ; Sat, 15 Aug 2015 17:33:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=yYwVzTzZids04Pr2f6/ew3KOio+VghUZ/iP4Y4tBubI=; b=c2aphObp+jW/RpPXEPh2s/yKF1QCNbD0YBcawiUVQcZtuaF1LkUNhB8gtb25xh+N4n Ft20RypXkGpBKZDFlVv4weuXvMarfsLdAZ2YKgKNb3BsUex9NkGBOeTenEJT7CsOdF47 kNi0wb3TleU+PrC+lSG2gW8S9YY0uIVIOhlA0BEc+OyYGXJZ/KyqLeg6541yp0Pq0wtM jPTSl9K46b0Z0PZ/ZeKqqD1P233gXcZb963U8TUDHdsMtpJLgalWUu45wpiyyeyBOfcN /3E+2vDUZBkfs/t2TZcEEqkfybPpzdyYAYPRluuubsopqrND17xemgMA4b1tfXi4onva MUZA== X-Gm-Message-State: ALoCoQk+NclbXC24djeNiW84Rr85y5BhF5uT4/BbzLU9iaSxfkR8zL7D9CVTrDPopFzw+fYOoycX MIME-Version: 1.0 X-Received: by 10.152.120.74 with SMTP id la10mr44494683lab.37.1439685209171; Sat, 15 Aug 2015 17:33:29 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Sat, 15 Aug 2015 17:33:29 -0700 (PDT) In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77DC2377BA@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <9966516C6EB5FC4381E05BF80AA55F77DC237498@US70UWXCHMBA05.zam.alcatel-lucent.com> <2FA0FBCD-4779-488B-968F-4FD271D506BC@nic.cz> <9966516C6EB5FC4381E05BF80AA55F77DC23755F@US70UWXCHMBA05.zam.alcatel-lucent.com> <1708085B-AC2F-455D-A5D9-45382F44DB3C@nic.cz> <9966516C6EB5FC4381E05BF80AA55F77DC2377BA@US70UWXCHMBA05.zam.alcatel-lucent.com> Date: Sat, 15 Aug 2015 17:33:29 -0700 Message-ID: From: Andy Bierman To: "Carey, Timothy (Timothy)" Content-Type: multipart/alternative; boundary=089e012290227b42e4051d62d5e6 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Constraint on mandatory on nodes as part of augmentation in RFC6020bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2015 00:33:34 -0000 --089e012290227b42e4051d62d5e6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Aug 15, 2015 at 4:58 PM, Carey, Timothy (Timothy) < timothy.carey@alcatel-lucent.com> wrote: > Andy, > > > > The example we have is a module that we are standardizing that is > augmenting another standards organization module (e.g., RFC 7223). We > didn=E2=80=99t develop the module but we want to reuse the good work of o= ther > bodies as much as possible. So using sub-modules doesn=E2=80=99t seem fea= sible as > the models are already published as a module. > > > > These new modules are indeed standardized so the client and server know > the specification and the =E2=80=98contract=E2=80=99 and the client inter= acts with the > server knowing how to manage the server with this module name. > > > > Indeed we look at backward compatibility within the context of the module > when we revise the module for the very reason you suggest. We don=E2=80= =99t want to > break old clients. I just don=E2=80=99t think that is valid for the first= revision > of a module. > > > Implementations of RFC 7223 don't know about your new module. It is compatibility with that module that is the issue, not your new module= . > BR, > > Tim > > Andy > > > *From:* Andy Bierman [mailto:andy@yumaworks.com] > *Sent:* Saturday, August 15, 2015 12:37 PM > *To:* Ladislav Lhotka > *Cc:* Carey, Timothy (Timothy); netmod@ietf.org > *Subject:* Re: [netmod] Constraint on mandatory on nodes as part of > augmentation in RFC6020bis > > > > > > > > On Sat, Aug 15, 2015 at 10:10 AM, Ladislav Lhotka wrote: > > > > On 15 Aug 2015, at 18:00, Andy Bierman wrote: > > > > Hi, > > > > If you are using mandatory nodes in augment, it is because you expect > > that all clients will know and implement both modules. > > However YANG has no way to require that. > > A server is NEVER required to implement the augmenting module. > > Are you saying that a server isn=E2=80=99t required to implement modules = that it > advertises? > > > > Of course not. > > The server is allowed to implement the base module without the augmenting > module. > > It is not required to advertise the augmenting module. > > > > A system working this way cannot just add a module later that breaks old > clients. > > The RFC can hand-wave around this, but the tech-support team will still > get calls > > if already deployed code stops working. > > > > I suggested a solution called YANG packages. If multiple YANG modules are > > required to be used together, then the current YANG conformance model is > broken. > > > > > > > > > There is no text in 6020(bis) supporting this theory. An augmenting modul= e > is an integral part of the data model as any other. > > > > > It doesn't really matter that you are writing these illegal YANG module= s > > all at once. A server is not required to implement them all at once, > > or all of them ever. > > > > It is rather naive to think that the client must understand every YANG > module > > implemented on a server. Even if this were useful, the client will > certainly > > not support modules written after the client code was released. > > Such a client is unsafe because the modules that the client ignores may > imply some important semantics. YANG modules are not perfectly isolated > from each other, and a client may break things if it doesn=E2=80=99t unde= rstand the > interactions. And again, I am not aware of any text in 6020 supporting su= ch > cherry-picking clients. > > > > There is no text that says if a base module is implemented, > > then some other modules that augment that module must also be implemented= . > > It is not practical to re-implement a client app every time a new module > is added. > > > > If you don't like how YANG conformance works then fix it. > > Just breaking old clients and expecting them to re-code constantly > > to keep up with every server release is not a solution. > > > > > > > > > > > You should be using submodules (written all at once) if you want > > to augment with mandatory nodes. > > In many use cases this is impossible - e.g. for interface types. > > > > There are no augments in the interface types module > > > > > Lada > > > > > Andy > > > > > > > > Andy > > > > > > > > > > > On Sat, Aug 15, 2015 at 8:39 AM, Carey, Timothy (Timothy) < > timothy.carey@alcatel-lucent.com> wrote: > > Lada, > > > > Yes sorry - I just saw that thread after I submitted mine. > > > > BR, > > Tim > > -----Original Message----- > > From: Ladislav Lhotka [mailto:lhotka@nic.cz] > > Sent: Saturday, August 15, 2015 10:25 AM > > To: Carey, Timothy (Timothy) > > Cc: netmod@ietf.org > > Subject: Re: [netmod] Constraint on mandatory on nodes as part of > augmentation in RFC6020bis > > > > > > > On 15 Aug 2015, at 16:50, Carey, Timothy (Timothy) < > timothy.carey@alcatel-lucent.com> wrote: > > > > > > Team, > > > > > > > > > Section 7.17 The augment statement has verbiage If the target node is > > > in another module, then nodes added by the augmentation MUST NOT be > > > mandatory nodes (see Section 3.1). > > > > > > > > > We are seeing situations where this constraint is invalid =E2=80=93 S= ituations > where a standard builds on another standard and makes parts of the new > standard mandatory. > > > > > > It seems this was an issue in the past where the decision was to get > around this statement with a presence container. > > > > > > Since 6020bis is in progress =E2=80=93 would it be possible to simply= remove > this phrase and allow mandatory nodes as part of the augmentation so we > don=E2=80=99t have to have this artificial workaround? > > > > This is exactly what=E2=80=99s currently being discussed in this thread= : > > > > > https://mailarchive.ietf.org/arch/search/?email_list=3Dnetmod&gbt=3D1&ind= ex=3DES2ogm1wabzZVIIBlrRor0fn3rk > > > > Lada > > > > > > > > Thanks, > > > Tim > > > _______________________________________________ > > > 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 > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --089e012290227b42e4051d62d5e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Aug 15, 2015 at 4:58 PM, Carey, Timothy (Timothy) <timothy.carey@alcatel-lucent.com> wrote:

Andy,<= /span>

=C2=A0=

The example we have = is a module that we are standardizing that is augmenting another standards = organization module (e.g., RFC 7223). We didn=E2=80=99t develop the module but we want to reuse the good work of other bodies as much as p= ossible. So using sub-modules doesn=E2=80=99t seem feasible as the models a= re already published as a module.

=C2=A0=

These new modules ar= e indeed standardized so the client and server know the specification and t= he =E2=80=98contract=E2=80=99 and the client interacts with the server know= ing how to manage the server with this module name.

=C2=A0=

Indeed we look at ba= ckward compatibility within the context of the module when we revise the mo= dule for the very reason you suggest. We don=E2=80=99t want to break old clients. I just don=E2=80=99t think that is valid for the first revisi= on of a module.

=C2=A0=


Implementations of RFC 722= 3 don't know about your new module.
It is compatibility with = that module that is the issue, not your new module.

=C2=A0

BR,

Tim




An= dy
=C2=A0

=C2=A0

From: Andy Bie= rman [mailto:andy@y= umaworks.com]
Sent: Saturday, August 15, 2015 12:37 PM
To: Ladislav Lhotka
Cc: Carey, Timothy (Timothy); netmod@ietf.org
Subject: Re: [netmod] Constraint on mandatory on nodes as part of au= gmentation in RFC6020bis

=C2=A0

=C2=A0

=C2=A0

On Sat, Aug 15, 2015 at 10:10 AM, Ladislav Lhotka &l= t;lhotka@nic.cz> = wrote:


> On 15 Aug 2015, at 18:00, Andy Bierman <andy@yumaworks.com> wrote:
>
> Hi,
>
> If you are using mandatory nodes in augment, it is because you expect<= br> > that all clients will know and implement both modules.
> However YANG has no way to require that.
> A server is NEVER required to implement the augmenting module.

Are you saying that a server isn=E2=80=99t required to implement modules th= at it advertises?

=C2=A0

Of course not.

The server is allowed to implement the base module w= ithout the augmenting module.

It is not required to advertise the augmenting modul= e.

=C2=A0

A system working this way cannot just add a module l= ater that breaks old clients.

The RFC can hand-wave around this, but the tech-supp= ort team will still get calls

if already deployed code stops working.

=C2=A0

I suggested a solution called YANG packages. If mult= iple YANG modules are

required to be used together, then the current YANG = conformance model is broken.

=C2=A0

=C2=A0

=C2=A0 =C2=A0=C2=A0


There is no text in 6020(bis) supporting this theory. An augmenting module = is an integral part of the data model as any other.

>
> It doesn't really matter that you are writing these illegal YANG m= odules
> all at once. A server is not required to implement them all at once, > or all of them ever.
>
> It is rather naive to think that the client must understand every YANG= module
> implemented on a server.=C2=A0 Even if this were useful, the client wi= ll certainly
> not support modules written after the client code was released.

Such a client is unsafe because the modules that the client ignores may imp= ly some important semantics. YANG modules are not perfectly isolated from e= ach other, and a client may break things if it doesn=E2=80=99t understand t= he interactions. And again, I am not aware of any text in 6020 supporting such cherry-picking clients.<= /p>

=C2=A0

There is no text that says if =C2=A0a base module is= implemented,

then some other modules that augment that module mus= t also be implemented.

It is not practical to re-implement a client app eve= ry time a new module is added.

=C2=A0

If you don't like how YANG conformance works the= n fix it.

Just breaking old clients and expecting them to re-c= ode constantly

to keep up with every server release is not a soluti= on.

=C2=A0

=C2=A0

=C2=A0

>
> You should be using submodules (written all at once) if you want
> to augment with mandatory nodes.

In many use cases this is impossible - e.g. for interface types.<= /u>

=C2=A0

There are no augments in the interface types module<= u>

=C2=A0


Lada

>
> Andy
>

=C2=A0

=C2=A0

Andy

=C2=A0

>
>
>
> On Sat, Aug 15, 2015 at 8:39 AM, Carey, Timothy (Timothy) <timothy.care= y@alcatel-lucent.com> wrote:
> Lada,
>
> Yes sorry - I just saw that thread after I submitted mine.
>
> BR,
> Tim
> -----Original Message-----
> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> Sent: Saturday, August 15, 2015 10:25 AM
> To: Carey, Timothy (Timothy)
> Cc: netmod@ietf.o= rg
> Subject: Re: [netmod] Constraint on mandatory on nodes as part of augm= entation in RFC6020bis
>
>
> > On 15 Aug 2015, at 16:50, Carey, Timothy (Timothy) <timothy.carey@a= lcatel-lucent.com> wrote:
> >
> > Team,
> >
> >
> > Section 7.17 The augment statement has verbiage If the target nod= e is
> > in another module, then nodes added by the augmentation MUST NOT = be
> > mandatory nodes (see Section 3.1).
> >
> >
> > We are seeing situations where this constraint is invalid =E2=80= =93 Situations where a standard builds on another standard and makes parts = of the new standard mandatory.
> >
> > It seems this was an issue in the past where the decision was to = get around this statement with a presence container.
> >
> > Since 6020bis is in progress =E2=80=93 would it be possible to si= mply remove this phrase and allow mandatory nodes as part of the augmentati= on so we don=E2=80=99t have to have this artificial workaround?
>
> This is exactly what=E2=80=99s currently being discussed in this threa= d:
>
> https://mailarchive.ietf.org/arch/search/?email_list=3Dnetmod&gbt=3D1&a= mp;index=3DES2ogm1wabzZVIIBlrRor0fn3rk
>
> Lada
>
> >
> > Thanks,
> > Tim
> > _______________________________________________
> > 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
>

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



=C2=A0


--089e012290227b42e4051d62d5e6-- From nobody Sun Aug 16 00:28:08 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 419F71A89B1 for ; Sun, 16 Aug 2015 00:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHfma1gGM3xP for ; Sun, 16 Aug 2015 00:28:04 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 508761A89AB for ; Sun, 16 Aug 2015 00:28:03 -0700 (PDT) Received: from localhost (unknown [172.29.2.202]) by trail.lhotka.name (Postfix) with ESMTPSA id 7BDC01CC009B; Sun, 16 Aug 2015 09:28:04 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: References: <9966516C6EB5FC4381E05BF80AA55F77DC237498@US70UWXCHMBA05.zam.alcatel-lucent.com> <2FA0FBCD-4779-488B-968F-4FD271D506BC@nic.cz> <9966516C6EB5FC4381E05BF80AA55F77DC23755F@US70UWXCHMBA05.zam.alcatel-lucent.com> <1708085B-AC2F-455D-A5D9-45382F44DB3C@nic.cz> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Sun, 16 Aug 2015 09:28:00 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "Carey, Timothy \(Timothy\)" , "netmod@ietf.org" Subject: Re: [netmod] Constraint on mandatory on nodes as part of augmentation in RFC6020bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2015 07:28:07 -0000 Andy Bierman writes: > On Sat, Aug 15, 2015 at 10:10 AM, Ladislav Lhotka wrote: > >> >> > On 15 Aug 2015, at 18:00, Andy Bierman wrote: >> > >> > Hi, >> > >> > If you are using mandatory nodes in augment, it is because you expect >> > that all clients will know and implement both modules. >> > However YANG has no way to require that. >> > A server is NEVER required to implement the augmenting module. >> >> Are you saying that a server isn=E2=80=99t required to implement modules= that it >> advertises? >> > > Of course not. The server is allowed to implement the base module > without the augmenting module. It is not required to advertise the > augmenting module. Sure, but that's the point of the concept that was introduced in RFC 7223: there will be a (large) number of modules for different interface types, all of them augmenting "ietf-interfaces". A server implementor will choose a collection of these modules depending on what interface types the device is expected to support. All these modules then become part of the data model and are advertised by the server. > > A system working this way cannot just add a module later that breaks old > clients. > The RFC can hand-wave around this, but the tech-support team will still g= et > calls > if already deployed code stops working. > > I suggested a solution called YANG packages. If multiple YANG modules > are required to be used together, then the current YANG conformance > model is broken. That's a different problem. It is true that modules like "ietf-interfaces" or "ietf-routing" are pretty much useless without other modules augmenting it, and I think this has to be clear to every server implementor already now (otherwise our RFCs and I-Ds do a poor job). Packages would formalize this information, which would of course be useful, but it has nothing to do with mandatory nodes in augments: even with packages, it will be possible for a server to support "ietf-interfaces" with, e.g., "ietf-ethernet" in revision 1, and "ietf-ethernet" + "ieee-802.1q" in revision 2. The problem this thread is about is that "ieee-802.1q" might need some parameters to be mandatory, such as the VLAN tag or reference to the "base" physical interface. Without such parameters, the VLAN interface is incomplete and has to be rejected by the server, but the data model cannot express this condition because of the restriction on "augment" contents. > > > > >> >> There is no text in 6020(bis) supporting this theory. An augmenting modu= le >> is an integral part of the data model as any other. >> >> > >> > It doesn't really matter that you are writing these illegal YANG modul= es >> > all at once. A server is not required to implement them all at once, >> > or all of them ever. >> > >> > It is rather naive to think that the client must understand every YANG >> module >> > implemented on a server. Even if this were useful, the client will >> certainly >> > not support modules written after the client code was released. >> >> Such a client is unsafe because the modules that the client ignores may >> imply some important semantics. YANG modules are not perfectly isolated >> from each other, and a client may break things if it doesn=E2=80=99t und= erstand the >> interactions. And again, I am not aware of any text in 6020 supporting s= uch >> cherry-picking clients. >> >> > There is no text that says if a base module is implemented, > then some other modules that augment that module must also be implemented. > It is not practical to re-implement a client app every time a new module = is > added. > > If you don't like how YANG conformance works then fix it. > Just breaking old clients and expecting them to re-code constantly > to keep up with every server release is not a solution. Backward compatibility is important but it mustn't be an absolute requirement. The client receives complete information about the server's data model. If it doesn't understand parts of it, it may be a problem or not, depending on what actions the client wants to perform. > > > > >> > >> > You should be using submodules (written all at once) if you want >> > to augment with mandatory nodes. >> >> In many use cases this is impossible - e.g. for interface types. >> > > There are no augments in the interface types module > There are several examples in RFC 7223 that illustrate how "ietf-interfaces" is supposed to be augmented. Lada > >> >> Lada >> >> > >> > Andy >> > >> > > > Andy > > >> > >> > >> > >> > On Sat, Aug 15, 2015 at 8:39 AM, Carey, Timothy (Timothy) < >> timothy.carey@alcatel-lucent.com> wrote: >> > Lada, >> > >> > Yes sorry - I just saw that thread after I submitted mine. >> > >> > BR, >> > Tim >> > -----Original Message----- >> > From: Ladislav Lhotka [mailto:lhotka@nic.cz] >> > Sent: Saturday, August 15, 2015 10:25 AM >> > To: Carey, Timothy (Timothy) >> > Cc: netmod@ietf.org >> > Subject: Re: [netmod] Constraint on mandatory on nodes as part of >> augmentation in RFC6020bis >> > >> > >> > > On 15 Aug 2015, at 16:50, Carey, Timothy (Timothy) < >> timothy.carey@alcatel-lucent.com> wrote: >> > > >> > > Team, >> > > >> > > >> > > Section 7.17 The augment statement has verbiage If the target node is >> > > in another module, then nodes added by the augmentation MUST NOT be >> > > mandatory nodes (see Section 3.1). >> > > >> > > >> > > We are seeing situations where this constraint is invalid =E2=80=93 = Situations >> where a standard builds on another standard and makes parts of the new >> standard mandatory. >> > > >> > > It seems this was an issue in the past where the decision was to get >> around this statement with a presence container. >> > > >> > > Since 6020bis is in progress =E2=80=93 would it be possible to simpl= y remove >> this phrase and allow mandatory nodes as part of the augmentation so we >> don=E2=80=99t have to have this artificial workaround? >> > >> > This is exactly what=E2=80=99s currently being discussed in this threa= d: >> > >> > >> https://mailarchive.ietf.org/arch/search/?email_list=3Dnetmod&gbt=3D1&in= dex=3DES2ogm1wabzZVIIBlrRor0fn3rk >> > >> > Lada >> > >> > > >> > > Thanks, >> > > Tim >> > > _______________________________________________ >> > > 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 >> > >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> >> >> >> --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Sun Aug 16 00:52:32 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 077F01A8A58 for ; Sun, 16 Aug 2015 00:52:31 -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 fP_lN-0sGfqT for ; Sun, 16 Aug 2015 00:52:28 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5FBA11A8A56 for ; Sun, 16 Aug 2015 00:52:28 -0700 (PDT) Received: from localhost (unknown [172.29.2.202]) by trail.lhotka.name (Postfix) with ESMTPSA id 22E381CC009B; Sun, 16 Aug 2015 09:52:29 +0200 (CEST) From: Ladislav Lhotka To: Randy Presuhn , "netmod\@ietf.org" In-Reply-To: <17434045.1439666459949.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> References: <17434045.1439666459949.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Sun, 16 Aug 2015 09:52:26 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] Constraint on mandatory on nodes as part of augmentation in RFC6020bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2015 07:52:31 -0000 Randy Presuhn writes: > Hi - > >> From: Andy Bierman >> Sent: Aug 15, 2015 10:55 AM >> To: Randy Presuhn >> Cc: "netmod@ietf.org" >> Subject: Re: [netmod] Constraint on mandatory on nodes as part of augmentation in RFC6020bis > ... >> I have been trying to change the meta-model (with YANG packages). But that >> does not fix the problem here -- the notion of what is mandatory for a given >> data structure can change over time. Yet YANG absolutely does not allow that >> to happen. It doesn't matter whether 1 module, 2 modules, or submodules are >> used. All mandatory data must be defined in the first release. > > It seems to be a little bit worse than that. It sounds like at least some > folks would like to be able to define a superclass as an abstract > (non-instantiable) class - that is, it could *only* be instantiated with some > combination of augmentations. I say it's worse because they appear to It's no more at "would like" stage - "ietf-interfaces" and "ietf-routing" are designed this way. > have a use case which is incompatible with how augment was intended to > work. Yes, I think so. The "augment" mechanism wasn't probably designed for such a heavy lifting. I think though it works fine - in fact, it is IMO an important mechanism that makes a gradual development of a large number of modules possible. > >> SNMP never had this problem because a client can just ignore new monitoring >> data it receives. A NETCONF client cannot create or replace configuration >> data that has unknown mandatory nodes. > > I think a better analogy would be to how row creation works in SNMP, specifically > with the RowStatus textual convention. The constraints of the SMI force the > modeler using AUGMENTS to provide DEFAULTs or DESCRIPTION text to provide > the correct values in the AUGMENTS portions of a row, and provide no ability > to select *which* of multiple AUGMENTS to instantiate. Whatever an implementation > supports MUST be instantiated in a 1:1 relationship with the rows of the > base MIB module. Lada's example needs something substantially more powerful, > and would not be a good candidate for AUGMENTS in SMI. One question is > whether Yang's augment construct is (or can be) the right tool for the job, > but another important question is whether this particular type of constraint > needs to be represented in machine-interpetable form, or whether this falls in > with the host of other constraints on configurations that are only specified > in human-readable form, and require hand-coding on the client, server, > or both. I fully agree, backward compatibility is an important principle for data model design, but it shouldn't be hardwired in the data modelling language. No schema language I am aware of has such rules. > >> In your analogy, there is an assumed super-class, and the mandatory augments >> is creating a new sub-class. > > And in some cases, there seems to be an assumption that for *some* use cases > instantiating *just* the superclass without any extension is an invalid > configuration. I think it is up to the server data model designer to select a set of modules that make sense for the particular device. Packages can help but I think it's not that difficult to perform the selection even now. Lada > >> The problem is the datai s all mixed together so a client using the old >> derived class needsto be insulated from the new derived class (w/ new >> mandatory nodes). > > Alternatively, one might say that another way of looking at the problem > is that the client cannot distinguish an attempt to instantiate the > superclass (which by itself may be operationally forbidden) from a > mal-formed attempt to instantiate the subclass. > >> The problem is specifying the rules for insulating the old client. >> One design pattern we have come up with assumes that the old client >> does not know about new identityref values, so it won't try to create >> or replace an entry using a new identity. > > This assumes that creating an un-augmented instance was *ever* a meaningful > thing to do. I think part of the challenge here is that given the tools > we currently have, the alternative is create a bunch of data definitions > (classes) that look suspisciously similar, but with no formal representation > of their common heritage. > > Randy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Sun Aug 16 15:45:15 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 611E51B29A2 for ; Sun, 16 Aug 2015 15:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 ZtV7EFdMJhlz for ; Sun, 16 Aug 2015 15:45:12 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6F31B137B for ; Sun, 16 Aug 2015 15:45:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ShCccb9D2bK9NuTtawQGBkJYQI/sDkguw4QmZOjRjUNLk6A49ERq0VT6P1ZG2Brr; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.51] (helo=mswamui-thinleaf.atl.sa.earthlink.net) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1ZR6fm-0007wH-0o for netmod@ietf.org; Sun, 16 Aug 2015 18:45:02 -0400 Received: from 99.101.141.69 by webmail.earthlink.net with HTTP; Sun, 16 Aug 2015 18:45:01 -0400 Message-ID: <31769884.1439765101926.JavaMail.root@mswamui-thinleaf.atl.sa.earthlink.net> Date: Sun, 16 Aug 2015 15:45:01 -0700 (GMT-07:00) From: Randy Presuhn To: "netmod@ietf.org" Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888ff8848a73c44bba022faaa6de8cafe2fca4466a627af0a4d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.51 Archived-At: Subject: Re: [netmod] Constraint on mandatory on nodes as part of augmentation in RFC6020bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2015 22:45:14 -0000 Hi - >From: Ladislav Lhotka >Sent: Aug 16, 2015 12:52 AM >To: Randy Presuhn , "netmod@ietf.org" >Subject: Re: [netmod] Constraint on mandatory on nodes as part of augmentation in RFC6020bis ... >> I think a better analogy would be to how row creation works in SNMP, specifically >> with the RowStatus textual convention. The constraints of the SMI force the >> modeler using AUGMENTS to provide DEFAULTs or DESCRIPTION text to provide >> the correct values in the AUGMENTS portions of a row, and provide no ability >> to select *which* of multiple AUGMENTS to instantiate. Whatever an implementation >> supports MUST be instantiated in a 1:1 relationship with the rows of the >> base MIB module. Lada's example needs something substantially more powerful, >> and would not be a good candidate for AUGMENTS in SMI. One question is >> whether Yang's augment construct is (or can be) the right tool for the job, >> but another important question is whether this particular type of constraint >> needs to be represented in machine-interpetable form, or whether this falls in >> with the host of other constraints on configurations that are only specified >> in human-readable form, and require hand-coding on the client, server, >> or both. > >I fully agree, backward compatibility is an important principle for data >model design, but it shouldn't be hardwired in the data modelling >language. No schema language I am aware of has such rules. In the CMIP world, GDMO has very strict rules for maintaining compatibility, in some regards even stricter than those of SNMP SMI. But the CMIP environment is explicitly object-oriented, and relies heavily on inheritance and notions of class compatibility through explicitly shared semantics both at the level of class definitions and of the bits and pieces used to compose class definitions. ... >> And in some cases, there seems to be an assumption that for *some* use cases >> instantiating *just* the superclass without any extension is an invalid >> configuration. > >I think it is up to the server data model designer to select a set of >modules that make sense for the particular device. Packages can help >but I think it's not that difficult to perform the selection even now. It's pretty straightforward in the case where clients always request creation of well-formed new instances (pardon my CMIP-ish vocabulary) and supplies a coherent set of augmenting bits. A challenge is for client or server code to know from the Yang definition whether there are constraints on the set of augments that may appear within a given instance (recognizing that the actual set that appears may differ from instance to instance within a given installation) and to do so in such a way that doesn't torpedo vendor extensions. The current discussion is looking to express "exactly one of set X" where "X" is defined as the set of "subclassing" augmentations, but does not include "extension" augmentations, and is complicated by the fact that set X is open-ended. Placeholder containers for the subclassing augmentations are the beginning of a hack to address this, growing out of a (perhaps dimly) recognized need to use augments to do two very different things, and that perhaps a structural convention might be enough to spackle over the real problem in modeling. Randy From nobody Mon Aug 17 01:34:25 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFF41A8890 for ; Mon, 17 Aug 2015 01:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGOLEJsugwtQ for ; Mon, 17 Aug 2015 01:34:21 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id C67FA1A88A0 for ; Mon, 17 Aug 2015 01:34:20 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id B8B611CC0311; Mon, 17 Aug 2015 10:34:20 +0200 (CEST) From: Ladislav Lhotka To: Randy Presuhn , "netmod\@ietf.org" In-Reply-To: <31769884.1439765101926.JavaMail.root@mswamui-thinleaf.atl.sa.earthlink.net> References: <31769884.1439765101926.JavaMail.root@mswamui-thinleaf.atl.sa.earthlink.net> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Mon, 17 Aug 2015 10:34:16 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] Constraint on mandatory on nodes as part of augmentation in RFC6020bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 08:34:23 -0000 Randy Presuhn writes: > Hi - > >>From: Ladislav Lhotka >>Sent: Aug 16, 2015 12:52 AM >>To: Randy Presuhn , "netmod@ietf.org" >>Subject: Re: [netmod] Constraint on mandatory on nodes as part of augment= ation in RFC6020bis > ... >>> I think a better analogy would be to how row creation works in SNMP, sp= ecifically >>> with the RowStatus textual convention. The constraints of the SMI forc= e the >>> modeler using AUGMENTS to provide DEFAULTs or DESCRIPTION text to provi= de >>> the correct values in the AUGMENTS portions of a row, and provide no ab= ility >>> to select *which* of multiple AUGMENTS to instantiate. Whatever an imp= lementation >>> supports MUST be instantiated in a 1:1 relationship with the rows of the >>> base MIB module. Lada's example needs something substantially more pow= erful, >>> and would not be a good candidate for AUGMENTS in SMI. One question is >>> whether Yang's augment construct is (or can be) the right tool for the = job, >>> but another important question is whether this particular type of const= raint >>> needs to be represented in machine-interpetable form, or whether this f= alls in >>> with the host of other constraints on configurations that are only spec= ified >>> in human-readable form, and require hand-coding on the client, server, >>> or both. >> >>I fully agree, backward compatibility is an important principle for data >>model design, but it shouldn't be hardwired in the data modelling >>language. No schema language I am aware of has such rules. > > In the CMIP world, GDMO has very strict rules for maintaining > compatibility, in some regards even stricter than those of SNMP > SMI. But the CMIP environment is explicitly object-oriented, > and relies heavily on inheritance and notions of class compatibility > through explicitly shared semantics both at the level of class > definitions and of the bits and pieces used to compose class definitions. > > ... >>> And in some cases, there seems to be an assumption that for *some* use = cases >>> instantiating *just* the superclass without any extension is an invalid >>> configuration. >> >>I think it is up to the server data model designer to select a set of >>modules that make sense for the particular device. Packages can help >>but I think it's not that difficult to perform the selection even now. > > It's pretty straightforward in the case where clients always request > creation of well-formed new instances (pardon my CMIP-ish vocabulary) > and supplies a coherent set of augmenting bits. A challenge is > for client or server code to know from the Yang definition whether > there are constraints on the set of augments that may appear within > a given instance (recognizing that the actual set that appears > may differ from instance to instance within a given installation) > and to do so in such a way that doesn't torpedo vendor extensions. > The current discussion is looking to express "exactly one of set X" > where "X" is defined as the set of "subclassing" augmentations, but > does not include "extension" augmentations, and is complicated Right, extension augmentations are a slightly different issue but IMO they will be needed as well because we can't hope to have all modules forever perfect as soon as they become RFCs, so some amount of patching will be necessary, and this may include adding mandatory nodes. However, the augmentation rules and also the update rules in sec. 10 of 6020bis effectively prevent such patches or updates. Then there are IMO two alternatives: - some schema constraints will only be coded in server's backend and won't appear in the data model, or - a completely new module has to be started that will replace the original one. Both alternatives can hardly be considered backward-compatible or more gentle to old clients. > by the fact that set X is open-ended. Placeholder containers > for the subclassing augmentations are the beginning of a hack to > address this, growing out of a (perhaps dimly) recognized need to > use augments to do two very different things, and that perhaps > a structural convention might be enough to spackle over the real > problem in modeling. Yes, that's my view. The pattern introduced in RFC 7223 (list + type and augment + when based on type), combined with the new XPath functions and multiple inheritance of identities in YANG=C2=A01.1, is able to simulate ob= ject orientation, and I don't think it is a big hack. Lada > > Randy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Aug 17 06:12:38 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE5EC1B2E0D for ; Mon, 17 Aug 2015 06:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BcHejQp_vWRU for ; Mon, 17 Aug 2015 06:12:34 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id AF7EA1B2E0E for ; Mon, 17 Aug 2015 06:12:34 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 475B51CC0040 for ; Mon, 17 Aug 2015 15:12:36 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Mon, 17 Aug 2015 15:12:31 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [netmod] domain-name X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 13:12:36 -0000 Hi, it seems the typedef "domain-name" in the "ietf-inet-types" (RFC 6991) is too restrictive: characters in domain names are not limited to [a-zA-Z0-9_]. RFC 2181 says: The DNS itself places only one restriction on the particular labels that can be used to identify resource records. That one restriction relates to the length of the label and the full name. The length of any one label is limited to between 1 and 63 octets. A full domain name is limited to 255 octets (including the separators). The zero length full name is defined as representing the root of the DNS tree, and is typically written and displayed as ".". Those restrictions aside, any binary string whatever can be used as the label of any resource record. Similarly, any binary string can serve as the value of any record that includes a domain name as some or all of its value (SOA, NS, MX, PTR, CNAME, and any others that may be added). Implementations of the DNS protocols must not place any restrictions on the labels that can be used. In particular, DNS servers must not refuse to serve a zone because it contains labels that might not be acceptable to some DNS client programs. A DNS server may be configurable to issue warnings when loading, or even to refuse to load, a primary zone containing labels that might be considered questionable, however this should not happen by default. In particular, wildcard domain names (RFC 4592) are rejected by the "domain-name" pattern. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Aug 17 09:51:12 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 803DB1A024E for ; Mon, 17 Aug 2015 09:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjePGfSXCXW4 for ; Mon, 17 Aug 2015 09:51:10 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id ECB631A01E7 for ; Mon, 17 Aug 2015 09:51:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Yg9YBJH2XoeQJpFBUF3Fz46hGchynCYnG/0NiDG3xYrYNpTb7kI+WXhIhglJ9VH8; 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.39] (helo=elwamui-little.atl.sa.earthlink.net) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1ZRNcg-0004Gr-Qf for netmod@ietf.org; Mon, 17 Aug 2015 12:50:58 -0400 Received: from 76.254.53.5 by webmail.earthlink.net with HTTP; Mon, 17 Aug 2015 12:50:33 -0400 Message-ID: <6899694.1439830233579.JavaMail.root@elwamui-little.atl.sa.earthlink.net> Date: Mon, 17 Aug 2015 09:50:33 -0700 (GMT-07:00) From: Randy Presuhn To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888ff8848a73c44bba009d09d449f65718f4ede52e09d09ac0e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.39 Archived-At: Subject: Re: [netmod] domain-name X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 16:51:11 -0000 Hi - >From: Ladislav Lhotka >Sent: Aug 17, 2015 6:12 AM >To: netmod@ietf.org >Subject: [netmod] domain-name > >Hi, > >it seems the typedef "domain-name" in the "ietf-inet-types" (RFC 6991) >is too restrictive: characters in domain names are not limited to >[a-zA-Z0-9_]. RFC 2181 says: Well, it's obviously missing "-", which is a perfectly fine character for a domain name. > The DNS itself places only one restriction on the particular labels > that can be used to identify resource records. That one restriction > relates to the length of the label and the full name. The length of > any one label is limited to between 1 and 63 octets. A full domain > name is limited to 255 octets (including the separators). The zero > length full name is defined as representing the root of the DNS tree, > and is typically written and displayed as ".". Those restrictions > aside, any binary string whatever can be used as the label of any > resource record. Similarly, any binary string can serve as the value > of any record that includes a domain name as some or all of its value > (SOA, NS, MX, PTR, CNAME, and any others that may be added). > Implementations of the DNS protocols must not place any restrictions > on the labels that can be used. In particular, DNS servers must not > refuse to serve a zone because it contains labels that might not be > acceptable to some DNS client programs. A DNS server may be > configurable to issue warnings when loading, or even to refuse to > load, a primary zone containing labels that might be considered > questionable, however this should not happen by default. This was the basis of the old "just use UTF-8" argument for IDN. Among other things, it runs afoul of the more restrictive rules for hostnames (distinct from domain names). >In particular, wildcard domain names (RFC 4592) are rejected by the >"domain-name" pattern. Not good. Randy From nobody Mon Aug 17 10:07:27 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3E31A1B1C for ; Mon, 17 Aug 2015 10:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.661 X-Spam-Level: X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sfdjonp-SNjk for ; Mon, 17 Aug 2015 10:07:24 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00B641A1B0E for ; Mon, 17 Aug 2015 10:07:23 -0700 (PDT) Received: from [172.29.2.202] (nat-14.bravonet.cz [77.48.225.14]) by mail.nic.cz (Postfix) with ESMTPSA id 786B9181524; Mon, 17 Aug 2015 19:07:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1439831242; bh=8dwdpymAa9BrW88q3kYFeDxpoKLo5o2H2iXyLcridHM=; h=From:Date:To; b=CRTHYmFNrvNzFeIZesHP764fVDX4zK6vQW6slkefh20WRPk2/fDW6ZoxdSEJXIKBf IzOfqyOxYLy0hZzyXpAsM7wTM7ko9tLX6QUmJckgp1Ao8n3TygNnukKtLhbI+j3QPc LXFyF5dqKa8nxR4waWpd3gxQwEZLppe7/VuhGtik= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: <6899694.1439830233579.JavaMail.root@elwamui-little.atl.sa.earthlink.net> Date: Mon, 17 Aug 2015 19:07:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <38687093-E259-451A-9443-3F0F15928B8A@nic.cz> References: <6899694.1439830233579.JavaMail.root@elwamui-little.atl.sa.earthlink.net> To: Randy Presuhn X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] domain-name X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 17:07:26 -0000 > On 17 Aug 2015, at 18:50, Randy Presuhn = wrote: >=20 > Hi - >=20 >> From: Ladislav Lhotka >> Sent: Aug 17, 2015 6:12 AM >> To: netmod@ietf.org >> Subject: [netmod] domain-name >>=20 >> Hi, >>=20 >> it seems the typedef "domain-name" in the "ietf-inet-types" (RFC = 6991) >> is too restrictive: characters in domain names are not limited to >> [a-zA-Z0-9_]. RFC 2181 says: >=20 > Well, it's obviously missing "-", which is a perfectly fine > character for a domain name. That=E2=80=99s my copy-and-paste mistake, sorry, the pattern in = =E2=80=9Cdomain-name=E2=80=9D does permit hyphens.=20 >=20 >> The DNS itself places only one restriction on the particular labels >> that can be used to identify resource records. That one restriction >> relates to the length of the label and the full name. The length of >> any one label is limited to between 1 and 63 octets. A full domain >> name is limited to 255 octets (including the separators). The zero >> length full name is defined as representing the root of the DNS = tree, >> and is typically written and displayed as ".". Those restrictions >> aside, any binary string whatever can be used as the label of any >> resource record. Similarly, any binary string can serve as the = value >> of any record that includes a domain name as some or all of its = value >> (SOA, NS, MX, PTR, CNAME, and any others that may be added). >> Implementations of the DNS protocols must not place any restrictions >> on the labels that can be used. In particular, DNS servers must not >> refuse to serve a zone because it contains labels that might not be >> acceptable to some DNS client programs. A DNS server may be >> configurable to issue warnings when loading, or even to refuse to >> load, a primary zone containing labels that might be considered >> questionable, however this should not happen by default. >=20 > This was the basis of the old "just use UTF-8" argument for IDN. > Among other things, it runs afoul of the more restrictive rules > for hostnames (distinct from domain names). Yes, RFCs 1034 and 1035 strongly recommend adhering to stricter hostname = rules but it is no MUST for domain names, and exceptions do exist.=20 >=20 >> In particular, wildcard domain names (RFC 4592) are rejected by the >> "domain-name" pattern. >=20 > Not good. Also, CIDR-style reverse zones contain labels like 128/26 that are = rejected by the =E2=80=9Cdomain-name=E2=80=9D pattern, too. Lada >=20 > Randy >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Aug 18 04:09:24 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 954371B33A5 for ; Tue, 18 Aug 2015 04:09:23 -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_75=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 N6lsiLkm7a5g for ; Tue, 18 Aug 2015 04:09:22 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4935B1A8895 for ; Tue, 18 Aug 2015 04:09:22 -0700 (PDT) Received: from localhost (unknown [173.38.220.43]) by mail.tail-f.com (Postfix) with ESMTPSA id DC9751AE019A; Tue, 18 Aug 2015 13:09:19 +0200 (CEST) Date: Tue, 18 Aug 2015 13:09:19 +0200 (CEST) Message-Id: <20150818.130919.1060632323457095150.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Y26 again, sorry X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 11:09:23 -0000 Hi, Ladislav Lhotka wrote: > Hi, > > although YANG 1.1 issue Y26 [1] is marked as DONE, I think the adopted > solution Y26-02 is really horrible, so at least I want to make sure the > WG is aware of the consequences. > > I am currently working on a data model for DNS zone data and the schema > is like this: > > module: dns-zones > +--rw zones > +--rw zone* [name] > +--rw name inet:domain-name > +--rw description? string > +--rw class? ianadns:class > +--rw rrset* [owner type] > +--rw owner inet:domain-name > +--rw type identityref > +--rw description? string > +--rw ttl positive-int32 > +--rw rdata* [id] > +--rw id string > +--rw description? string > > The idea is that specific RDATA will be added for each RR type (with a > "when" condition based on "type"). Data for essential RR Types (SOA, NS, > A, AAAA, ...) can be defined in the same module but for some types they > need to be defined in other modules and added via augmenting the target > node "rdata". Typically, some (or all) of RDATA is mandatory, and this > is where Y26 comes into play. The solution recommended by Y26-02 would > look like this: > > augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" { > when "derived-from-or-self(../dnsz:type,'iana-dns-parameters'," > + "'TLSA')"; > container rdata { // <================= > presence "TLSA data"; > leaf certificate-usage { > mandatory true; > ... > } Working with what we currently have, I think this would look a bit better if you instead did: augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" { when "derived-from-or-self(../dnsz:type,'iana-dns-parameters'," + "'TLSA')"; container tlsa { // name change presence "TLSA data"; leaf certificate-usage { mandatory true; ... I think the model itself is quite ok with this design, but the instance data contains the type information encoded twice; once in the the 'type' leaf and once in the container 'tlsa'. Since the 'type' leaf is part of the key, it cannot easily be removed. As for this issue in general, I think we all agreed that it would be nice if we could allow such data to be mandatory, but noone came up with any proposal for how to do this. The "safe" use case we discussed was when the identity was defined in the same module as the augment, but that is not the case in you module, where all identities are defined in a central module. /martin From nobody Tue Aug 18 05:11:39 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD03A1A0218 for ; Tue, 18 Aug 2015 05:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.239 X-Spam-Level: X-Spam-Status: No, score=0.239 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_75=0.6, 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 fAb7iXdI_mhT for ; Tue, 18 Aug 2015 05:11:36 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0248F1A0211 for ; Tue, 18 Aug 2015 05:11:35 -0700 (PDT) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 1FB45181907; Tue, 18 Aug 2015 14:11:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1439899893; bh=1NTEhuLUBi06XH5BRmTzbVpE8dUe3jJDGdlcpxkgyCg=; h=From:Date:To; b=NwocfNN12jE+2dtujy/jfewUISjlXEFgdVnuVc+y/8lggvLDsyj0Bu6adE4KsmVKu UhfHUSn0iTSpeYPSvzR6RzfGdVUs1fM/MlRtgZM1mgrQU7iCEReN9wI3I8fz8/EDFy fZHBTcaBvNGab6GcG/APwFyDQHhOaMsuqcneVOBo= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: <20150818.130919.1060632323457095150.mbj@tail-f.com> Date: Tue, 18 Aug 2015 14:11:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <778755AA-66CB-491B-9BD7-81061125CAFC@nic.cz> References: <20150818.130919.1060632323457095150.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Y26 again, sorry X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 12:11:38 -0000 > On 18 Aug 2015, at 13:09, Martin Bjorklund wrote: >=20 > Hi, >=20 > Ladislav Lhotka wrote: >> Hi, >>=20 >> although YANG 1.1 issue Y26 [1] is marked as DONE, I think the = adopted >> solution Y26-02 is really horrible, so at least I want to make sure = the >> WG is aware of the consequences. >>=20 >> I am currently working on a data model for DNS zone data and the = schema >> is like this: >>=20 >> module: dns-zones >> +--rw zones >> +--rw zone* [name] >> +--rw name inet:domain-name >> +--rw description? string >> +--rw class? ianadns:class >> +--rw rrset* [owner type] >> +--rw owner inet:domain-name >> +--rw type identityref >> +--rw description? string >> +--rw ttl positive-int32 >> +--rw rdata* [id] >> +--rw id string >> +--rw description? string >>=20 >> The idea is that specific RDATA will be added for each RR type (with = a >> "when" condition based on "type"). Data for essential RR Types (SOA, = NS, >> A, AAAA, ...) can be defined in the same module but for some types = they >> need to be defined in other modules and added via augmenting the = target >> node "rdata". Typically, some (or all) of RDATA is mandatory, and = this >> is where Y26 comes into play. The solution recommended by Y26-02 = would >> look like this: >>=20 >> augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" { >> when "derived-from-or-self(../dnsz:type,'iana-dns-parameters'," >> + "'TLSA')"; >> container rdata { // <=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >> presence "TLSA data"; >> leaf certificate-usage { >> mandatory true; >> ... >> } >=20 > Working with what we currently have, I think this would look a bit > better if you instead did: >=20 > augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" { > when "derived-from-or-self(../dnsz:type,'iana-dns-parameters'," > + "'TLSA')"; > container tlsa { // name change > presence "TLSA data"; > leaf certificate-usage { > mandatory true; > =E2=80=A6 Right, using the same name for the presence container won=E2=80=99t work = if rdata for multiple rr types are defined in the same module. But the main problem still remains: container =E2=80=9Ctlsa=E2=80=9D = needn=E2=80=99t be present, which leads to an invalid resource record. = The server would have no choice but reject such configuration. I don=E2=80= =99t get how this helps old clients. >=20 > I think the model itself is quite ok with this design, but the > instance data contains the type information encoded twice; once in the > the 'type' leaf and once in the container 'tlsa'. Since the 'type' > leaf is part of the key, it cannot easily be removed. >=20 >=20 > As for this issue in general, I think we all agreed that it would be > nice if we could allow such data to be mandatory, but noone came up > with any proposal for how to do this. The "safe" use case we > discussed was when the identity was defined in the same module as the > augment, but that is not the case in you module, where all identities > are defined in a central module. =E2=80=A6 as it is with interface types. I think it would be better to remove the restriction altogether. If a = parameter is mandatory by its substance, it should be defined as = mandatory in the data model. And if somebody wants to break old (or = someone else=E2=80=99s) clients, there are other ways for achieving it. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Aug 18 05:51:18 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E49141A1DE1; Tue, 18 Aug 2015 05:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.011 X-Spam-Level: X-Spam-Status: No, score=-4.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, 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 C10NBiisadRJ; Tue, 18 Aug 2015 05:51:12 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A69C01A1B89; Tue, 18 Aug 2015 05:51:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1439902214; bh=5ze91sp+yiEZUY4ulq3vPoBniCXZKJOg/19Ln2wL9gI=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=qOHPsW4fBYWZbWV0CoGd7fVTGW2AZv8Gz+hN4Yg4lb6Vy+LHqAnqFOYXASkh2+nJi YnhSBT9nh+o89UiGcumg/kjmO3NlAnGj0XDIyplR1dbGRmApNpqgs+MHAVYcrMNqmr NDgGoPj0VQL59mguBYeeH/M8MitvpDLKGGKadHno= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; Content-Type: multipart/alternative; boundary="Apple-Mail=_BB37A061-7DC8-4199-93EE-64A58DF64129" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Nadeau Thomas In-Reply-To: <55C4CCEC.4020209@cisco.com> Date: Tue, 18 Aug 2015 08:51:07 -0400 Message-Id: <5D155628-7CEF-4712-BAD2-98259A1DE93E@lucidvision.com> References: <1516231808.93378.1438887834598.JavaMail.nobody@jva2tc202.webex.com> <55C4CCEC.4020209@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.2104) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-ShareWhite: 50.255.148.181 X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=18 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181 X-IP-stats: Notspam Incoming Last 0, First 95, in=868, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: Cc: netmod-chairs@tools.ietf.org, netmod@ietf.org, draft-bjorklund-netmod-openconfig-reply@ietf.org Subject: Re: [netmod] WebEx meeting invitation: NETMOD Interm meeting on OpenConfig X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 12:51:17 -0000 --Apple-Mail=_BB37A061-7DC8-4199-93EE-64A58DF64129 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 BTW Benoit=92s note below and the WebEx should serve as the = official notification to the WG that we will be having this interim = meeting. It was officially registered with the WG meeting tracker too. = Despite this, someone pointed out the other day that I=92d not = officially announced it. Consider this the official announcement of the = meeting on September 10, 2015.=20 The rough agenda is to discuss any and all alternatives to the = Open Config proposal, and then compare/contrast the differences. The = goal of the meeting is to present a way forward to the WG between = choosing to adopt this proposal or not, in whole or part, or to = recommend in whole or part, the alternatives.=20 =97Tom > On Aug 7, 2015:11:21 AM, at 11:21 AM, Benoit Claise = wrote: >=20 > Dear all, >=20 > Let me set the stage for this future interim. >=20 > First of (and let me repeat), I'm happy that the operators gathered = and collectively worked on YANG models and related requirements. >=20 > The previous two interim meetings in June on the openconfig issues = (draft-openconfig-netmod-opstate-01 = and = draft-openconfig-netmod-model-structure-00 = = ) were successful in the sense that the requirements are now understood. >=20 > Unfortunately, some key players were not in Prague and we could not = finalize the discussion. > How to represent the operational state is one important guidance from = RFC 6087bis that we must be providing to all existing and future YANG = models (and not only in the IETF).=20 >=20 > We need to bring closure on that topic, and this is the plan for that = interim meeting in September. >=20 > http://datatracker.ietf.org/doc/draft-openconfig-netmod-opstate/ = has = been updated. Please comment on this version. > Also, any alternate proposals must be prepared for that interim in = September. They must be prepared with the same level of rigour as = draft-openconfig-netmod-opstate., i.e. must have the same level of = details. >=20 > In the meeting in September, the goal is to take a decision.=20 >=20 > Regards, Benoit (OPS AD) >=20 >>=20 >> Hello, >> NETMOD Working Group invites you to join this WebEx meeting. >> =20 >> NETMOD Interm meeting on OpenConfig >> Thursday, September 10, 2015=20 >> 11:00 am | Eastern Daylight Time (New York, GMT-04:00) | 1 hr=20 >> =20 >> Join WebEx meeting = >> Meeting number: 645 732 277=20 >> Meeting password: 1234 >> =20 >> Join by phone >> 1-877-668-4493 Call-in toll free number (US/Canada) >> 1-650-479-3208 Call-in toll number (US/Canada) >> Access code: 645 732 277 >> Toll-free calling restrictions = >> =20 >> Add this meeting = to your calendar. >> =20 >> Can't join the meeting? Contact support. = >> =20 >> IMPORTANT NOTICE: Please note that this WebEx service allows audio = and other information sent during the session to be recorded, which may = be discoverable in a legal matter. By joining this session, you = automatically consent to such recordings. If you do not consent to being = recorded, discuss your concerns with the host or do not join the = session. >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod = >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod = --Apple-Mail=_BB37A061-7DC8-4199-93EE-64A58DF64129 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

BTW = Benoit=92s note below and the WebEx should serve as the official = notification to the WG that we will be having this interim meeting. =  It was officially registered with the WG meeting tracker too. =  Despite this, someone pointed out the other day that I=92d not = officially announced it.  Consider this the official announcement = of the meeting on September 10, 2015. 

The rough agenda is to discuss = any and all alternatives to the Open Config proposal, and then = compare/contrast the differences.  The goal of the meeting is to = present a way forward to the WG between choosing to adopt this proposal = or not, in whole or part, or to recommend in whole or part, the = alternatives. 

= =97Tom



On = Aug 7, 2015:11:21 AM, at 11:21 AM, Benoit Claise <bclaise@cisco.com> = wrote:

Dear all,

Let me set the stage for = this future interim.

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

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

Unfortunately, some key players were not in = Prague and we could not finalize the discussion.
How to = represent the operational state is one important guidance from RFC = 6087bis that we must be providing to all existing and future YANG models = (and not only in the IETF). 

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

http://datatracker.ietf.org/doc/draft-openconfig-netmod-opstate/=  has been updated. = Please comment on this version.
Also, any alternate = proposals must be prepared for that interim in September. They must be = prepared with the same level of rigour as = draft-openconfig-netmod-opstate., i.e. must have the same level of = details.

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

Regards, Benoit (OPS AD)

Hello,
NETMOD Working Group invites you to join this = WebEx meeting.
 
NETMOD = Interm meeting on OpenConfig
Thursday, September 10, 2015 
11:00 am  |  Eastern Daylight Time (New = York, GMT-04:00)  |  1 hr 
 
Join WebEx meeting
Meeting number:645 732 277 
Meeting = password:1234
 
Join by phone
1-877-668-4493 Call-in toll free = number (US/Canada)
1-650-479-3208 Call-in toll = number (US/Canada)
Access code: 645 732 277
Toll-free calling = restrictions
 
Add this = meeting to your = calendar.
 
Can't join the meeting? Contact = support.
 
IMPORTANT NOTICE: Please note that this WebEx = service allows audio and other information sent during the session to be = recorded, which may be discoverable in a legal matter. By joining this = session, you automatically consent to such recordings. If you do not = consent to being recorded, discuss your concerns with the host or do not = join the = session.


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

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

= --Apple-Mail=_BB37A061-7DC8-4199-93EE-64A58DF64129-- From nobody Tue Aug 18 06:42:29 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF8DF1A871A for ; Tue, 18 Aug 2015 06:42:27 -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_75=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 tmJUyO20CP2n for ; Tue, 18 Aug 2015 06:42:26 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 992EB1A8715 for ; Tue, 18 Aug 2015 06:42:26 -0700 (PDT) Received: from localhost (unknown [173.38.220.43]) by mail.tail-f.com (Postfix) with ESMTPSA id 40FEA1AE019A; Tue, 18 Aug 2015 15:42:24 +0200 (CEST) Date: Tue, 18 Aug 2015 15:42:23 +0200 (CEST) Message-Id: <20150818.154223.1301963938445592911.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <778755AA-66CB-491B-9BD7-81061125CAFC@nic.cz> References: <20150818.130919.1060632323457095150.mbj@tail-f.com> <778755AA-66CB-491B-9BD7-81061125CAFC@nic.cz> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Y26 again, sorry X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 13:42:28 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+ID4gT24gMTggQXVn IDIwMTUsIGF0IDEzOjA5LCBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4gd3JvdGU6 DQo+ID4gDQo+ID4gSGksDQo+ID4gDQo+ID4gTGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6 PiB3cm90ZToNCj4gPj4gSGksDQo+ID4+IA0KPiA+PiBhbHRob3VnaCBZQU5HIDEuMSBpc3N1ZSBZ MjYgWzFdIGlzIG1hcmtlZCBhcyBET05FLCBJIHRoaW5rIHRoZSBhZG9wdGVkDQo+ID4+IHNvbHV0 aW9uIFkyNi0wMiBpcyByZWFsbHkgaG9ycmlibGUsIHNvIGF0IGxlYXN0IEkgd2FudCB0byBtYWtl IHN1cmUNCj4gPj4gdGhlDQo+ID4+IFdHIGlzIGF3YXJlIG9mIHRoZSBjb25zZXF1ZW5jZXMuDQo+ ID4+IA0KPiA+PiBJIGFtIGN1cnJlbnRseSB3b3JraW5nIG9uIGEgZGF0YSBtb2RlbCBmb3IgRE5T IHpvbmUgZGF0YSBhbmQgdGhlDQo+ID4+IHNjaGVtYQ0KPiA+PiBpcyBsaWtlIHRoaXM6DQo+ID4+ IA0KPiA+PiBtb2R1bGU6IGRucy16b25lcw0KPiA+PiAgICstLXJ3IHpvbmVzDQo+ID4+ICAgICAg Ky0tcncgem9uZSogW25hbWVdDQo+ID4+ICAgICAgICAgKy0tcncgbmFtZSAgICAgICAgICAgaW5l dDpkb21haW4tbmFtZQ0KPiA+PiAgICAgICAgICstLXJ3IGRlc2NyaXB0aW9uPyAgIHN0cmluZw0K PiA+PiAgICAgICAgICstLXJ3IGNsYXNzPyAgICAgICAgIGlhbmFkbnM6Y2xhc3MNCj4gPj4gICAg ICAgICArLS1ydyBycnNldCogW293bmVyIHR5cGVdDQo+ID4+ICAgICAgICAgICAgKy0tcncgb3du ZXIgICAgICAgICAgaW5ldDpkb21haW4tbmFtZQ0KPiA+PiAgICAgICAgICAgICstLXJ3IHR5cGUg ICAgICAgICAgIGlkZW50aXR5cmVmDQo+ID4+ICAgICAgICAgICAgKy0tcncgZGVzY3JpcHRpb24/ ICAgc3RyaW5nDQo+ID4+ICAgICAgICAgICAgKy0tcncgdHRsICAgICAgICAgICAgcG9zaXRpdmUt aW50MzINCj4gPj4gICAgICAgICAgICArLS1ydyByZGF0YSogW2lkXQ0KPiA+PiAgICAgICAgICAg ICAgICstLXJ3IGlkICAgICAgICAgICAgIHN0cmluZw0KPiA+PiAgICAgICAgICAgICAgICstLXJ3 IGRlc2NyaXB0aW9uPyAgIHN0cmluZw0KPiA+PiANCj4gPj4gVGhlIGlkZWEgaXMgdGhhdCBzcGVj aWZpYyBSREFUQSB3aWxsIGJlIGFkZGVkIGZvciBlYWNoIFJSIHR5cGUgKHdpdGggYQ0KPiA+PiAi d2hlbiIgY29uZGl0aW9uIGJhc2VkIG9uICJ0eXBlIikuIERhdGEgZm9yIGVzc2VudGlhbCBSUiBU eXBlcyAoU09BLA0KPiA+PiBOUywNCj4gPj4gQSwgQUFBQSwgLi4uKSBjYW4gYmUgZGVmaW5lZCBp biB0aGUgc2FtZSBtb2R1bGUgYnV0IGZvciBzb21lIHR5cGVzDQo+ID4+IHRoZXkNCj4gPj4gbmVl ZCB0byBiZSBkZWZpbmVkIGluIG90aGVyIG1vZHVsZXMgYW5kIGFkZGVkIHZpYSBhdWdtZW50aW5n IHRoZQ0KPiA+PiB0YXJnZXQNCj4gPj4gbm9kZSAicmRhdGEiLiBUeXBpY2FsbHksIHNvbWUgKG9y IGFsbCkgb2YgUkRBVEEgaXMgbWFuZGF0b3J5LCBhbmQgdGhpcw0KPiA+PiBpcyB3aGVyZSBZMjYg Y29tZXMgaW50byBwbGF5LiBUaGUgc29sdXRpb24gcmVjb21tZW5kZWQgYnkgWTI2LTAyIHdvdWxk DQo+ID4+IGxvb2sgbGlrZSB0aGlzOg0KPiA+PiANCj4gPj4gYXVnbWVudCAiL2Ruc3o6em9uZXMv ZG5zejp6b25lL2Ruc3o6cnJzZXQvZG5zejpyZGF0YSIgew0KPiA+PiAgICB3aGVuICJkZXJpdmVk LWZyb20tb3Itc2VsZiguLi9kbnN6OnR5cGUsJ2lhbmEtZG5zLXBhcmFtZXRlcnMnLCINCj4gPj4g ICAgICAgKyAiJ1RMU0EnKSI7DQo+ID4+ICAgIGNvbnRhaW5lciByZGF0YSB7ICAgICAgICAgICAg Ly8gPD09PT09PT09PT09PT09PT09DQo+ID4+ICAgICAgICBwcmVzZW5jZSAiVExTQSBkYXRhIjsN Cj4gPj4gICAgICAgIGxlYWYgY2VydGlmaWNhdGUtdXNhZ2Ugew0KPiA+PiAgICAgICAgICAgIG1h bmRhdG9yeSB0cnVlOw0KPiA+PiAgICAgICAgICAgIC4uLg0KPiA+PiAgICAgICAgfQ0KPiA+IA0K PiA+IFdvcmtpbmcgd2l0aCB3aGF0IHdlIGN1cnJlbnRseSBoYXZlLCBJIHRoaW5rIHRoaXMgd291 bGQgbG9vayBhIGJpdA0KPiA+IGJldHRlciBpZiB5b3UgaW5zdGVhZCBkaWQ6DQo+ID4gDQo+ID4g IGF1Z21lbnQgIi9kbnN6OnpvbmVzL2Ruc3o6em9uZS9kbnN6OnJyc2V0L2Ruc3o6cmRhdGEiIHsN Cj4gPiAgICB3aGVuICJkZXJpdmVkLWZyb20tb3Itc2VsZiguLi9kbnN6OnR5cGUsJ2lhbmEtZG5z LXBhcmFtZXRlcnMnLCINCj4gPiAgICAgICArICInVExTQScpIjsNCj4gPiAgICBjb250YWluZXIg dGxzYSB7IC8vIG5hbWUgY2hhbmdlDQo+ID4gICAgICAgIHByZXNlbmNlICJUTFNBIGRhdGEiOw0K PiA+ICAgICAgICBsZWFmIGNlcnRpZmljYXRlLXVzYWdlIHsNCj4gPiAgICAgICAgICAgIG1hbmRh dG9yeSB0cnVlOw0KPiA+ICAgICAgICAgICAg4oCmDQo+IA0KPiBSaWdodCwgdXNpbmcgdGhlIHNh bWUgbmFtZSBmb3IgdGhlIHByZXNlbmNlIGNvbnRhaW5lciB3b27igJl0IHdvcmsgaWYNCj4gcmRh dGEgZm9yIG11bHRpcGxlIHJyIHR5cGVzIGFyZSBkZWZpbmVkIGluIHRoZSBzYW1lIG1vZHVsZS4N Cj4gDQo+IEJ1dCB0aGUgbWFpbiBwcm9ibGVtIHN0aWxsIHJlbWFpbnM6IGNvbnRhaW5lciDigJx0 bHNh4oCdIG5lZWRu4oCZdCBiZQ0KPiBwcmVzZW50LCB3aGljaCBsZWFkcyB0byBhbiBpbnZhbGlk IHJlc291cmNlIHJlY29yZC4gVGhlIHNlcnZlciB3b3VsZA0KPiBoYXZlIG5vIGNob2ljZSBidXQg cmVqZWN0IHN1Y2ggY29uZmlndXJhdGlvbi4gSSBkb27igJl0IGdldCBob3cgdGhpcw0KPiBoZWxw cyBvbGQgY2xpZW50cy4NCg0KV2VsbCwgaWYgaXQgZG9lc24ndCBtYWtlIGFueSBzZW5zZSB0byBj b25maWd1cmUgYW4gcnJzZXQgb2YgZS5nLiB0eXBlDQonVExTQScgd2l0aG91dCB0aGUgJ3Rsc2En IGNvbnRhaW5lciwgSSBkb24ndCBleHBlY3Qgc3VjaCBjbGllbnRzIHRvIGJlDQpkZXBsb3llZCBp biB0aGUgbmV0d29yay4NCg0KVGhlIHJ1bGUgYWJvdXQgbm90IGF1Z21lbnRpbmcgbWFuZGF0b3J5 IG5vZGVzIGlzIHRoZXJlIHRvIHByb3RlY3QNCnByb3Blcmx5IGZ1bmN0aW9uaW5nIGNsaWVudHMu ICBGb3IgZXhhbXBsZSwgc3VwcG9zZSB5b3UgaGF2ZSB5b3VyIHRsc2ENCm1vZHVsZSBhbmQgYSBj bGllbnQgdGhhdCBrbm93cyB0aGlzIGFuZCB3b3JrcyB3ZWxsLiAgVGhlbiBzb21lIHZlbmRvcg0K d3JpdGVzIGEgbmV3IG1vZHVsZSB0aGF0IGFsc28gYXVnbWVudHMgc29tZSBtYW5kYXRvcnkgbm9k ZXMgd2hlbiB0aGUNCnR5cGUgaXMgJ1RMU0EnLiAgVGhlbiB0aGUgY2xpZW50IHRoYXQgdXNlZCB0 byB3b3JrIGRvZXNuJ3Qgd29yaw0KYW55bW9yZS4NCg0KDQovbWFydGluDQoNCg0KDQoNCj4gDQo+ ID4gDQo+ID4gSSB0aGluayB0aGUgbW9kZWwgaXRzZWxmIGlzIHF1aXRlIG9rIHdpdGggdGhpcyBk ZXNpZ24sIGJ1dCB0aGUNCj4gPiBpbnN0YW5jZSBkYXRhIGNvbnRhaW5zIHRoZSB0eXBlIGluZm9y bWF0aW9uIGVuY29kZWQgdHdpY2U7IG9uY2UgaW4gdGhlDQo+ID4gdGhlICd0eXBlJyBsZWFmIGFu ZCBvbmNlIGluIHRoZSBjb250YWluZXIgJ3Rsc2EnLiAgU2luY2UgdGhlICd0eXBlJw0KPiA+IGxl YWYgaXMgcGFydCBvZiB0aGUga2V5LCBpdCBjYW5ub3QgZWFzaWx5IGJlIHJlbW92ZWQuDQo+ID4g DQo+ID4gDQo+ID4gQXMgZm9yIHRoaXMgaXNzdWUgaW4gZ2VuZXJhbCwgSSB0aGluayB3ZSBhbGwg YWdyZWVkIHRoYXQgaXQgd291bGQgYmUNCj4gPiBuaWNlIGlmIHdlIGNvdWxkIGFsbG93IHN1Y2gg ZGF0YSB0byBiZSBtYW5kYXRvcnksIGJ1dCBub29uZSBjYW1lIHVwDQo+ID4gd2l0aCBhbnkgcHJv cG9zYWwgZm9yIGhvdyB0byBkbyB0aGlzLiAgVGhlICJzYWZlIiB1c2UgY2FzZSB3ZQ0KPiA+IGRp c2N1c3NlZCB3YXMgd2hlbiB0aGUgaWRlbnRpdHkgd2FzIGRlZmluZWQgaW4gdGhlIHNhbWUgbW9k dWxlIGFzIHRoZQ0KPiA+IGF1Z21lbnQsIGJ1dCB0aGF0IGlzIG5vdCB0aGUgY2FzZSBpbiB5b3Ug bW9kdWxlLCB3aGVyZSBhbGwgaWRlbnRpdGllcw0KPiA+IGFyZSBkZWZpbmVkIGluIGEgY2VudHJh bCBtb2R1bGUuDQo+IA0KPiDigKYgYXMgaXQgaXMgd2l0aCBpbnRlcmZhY2UgdHlwZXMuDQo+IA0K PiBJIHRoaW5rIGl0IHdvdWxkIGJlIGJldHRlciB0byByZW1vdmUgdGhlIHJlc3RyaWN0aW9uIGFs dG9nZXRoZXIuIElmIGENCj4gcGFyYW1ldGVyIGlzIG1hbmRhdG9yeSBieSBpdHMgc3Vic3RhbmNl LCBpdCBzaG91bGQgYmUgZGVmaW5lZCBhcw0KPiBtYW5kYXRvcnkgaW4gdGhlIGRhdGEgbW9kZWwu IEFuZCBpZiBzb21lYm9keSB3YW50cyB0byBicmVhayBvbGQgKG9yDQo+IHNvbWVvbmUgZWxzZeKA mXMpIGNsaWVudHMsIHRoZXJlIGFyZSBvdGhlciB3YXlzIGZvciBhY2hpZXZpbmcgaXQuDQo+IA0K PiBMYWRhDQo+IA0KPiA+IA0KPiA+IA0KPiA+IC9tYXJ0aW4NCj4gDQo+IC0tDQo+IExhZGlzbGF2 IExob3RrYSwgQ1ouTklDIExhYnMNCj4gUEdQIEtleSBJRDogRTc0RThDMEMNCj4gDQo+IA0KPiAN Cj4gDQo= From nobody Tue Aug 18 07:19:50 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA6E1A87A4; Tue, 18 Aug 2015 07:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.86 X-Spam-Level: X-Spam-Status: No, score=-5.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFwkXDs4S_1T; Tue, 18 Aug 2015 07:19:46 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0CE61A87D5; Tue, 18 Aug 2015 07:19:45 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 07AC312CF; Tue, 18 Aug 2015 16:19:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id dGcYWhnVqof8; Tue, 18 Aug 2015 16:19: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; Tue, 18 Aug 2015 16:19:40 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6617C2005E; Tue, 18 Aug 2015 16:19:40 +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 OMuBNIbym7VG; Tue, 18 Aug 2015 16:19:38 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2C9FC20058; Tue, 18 Aug 2015 16:19:38 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7AA773655103; Tue, 18 Aug 2015 16:19:34 +0200 (CEST) Date: Tue, 18 Aug 2015 16:19:33 +0200 From: Juergen Schoenwaelder To: Nadeau Thomas Message-ID: <20150818141933.GA67338@elstar.local> Mail-Followup-To: Nadeau Thomas , Benoit Claise , netmod-chairs@tools.ietf.org, netmod@ietf.org, draft-bjorklund-netmod-openconfig-reply@ietf.org References: <1516231808.93378.1438887834598.JavaMail.nobody@jva2tc202.webex.com> <55C4CCEC.4020209@cisco.com> <5D155628-7CEF-4712-BAD2-98259A1DE93E@lucidvision.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <5D155628-7CEF-4712-BAD2-98259A1DE93E@lucidvision.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod-chairs@tools.ietf.org, netmod@ietf.org, draft-bjorklund-netmod-openconfig-reply@ietf.org Subject: Re: [netmod] WebEx meeting invitation: NETMOD Interm meeting on OpenConfig X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 14:19:48 -0000 Tom, this may be a useful read... https://www.ietf.org/iesg/statement/interim-meetings-2000-08-29.html /js On Tue, Aug 18, 2015 at 08:51:07AM -0400, Nadeau Thomas wrote: > > BTW Benoit’s note below and the WebEx should serve as the official notification to the WG that we will be having this interim meeting. It was officially registered with the WG meeting tracker too. Despite this, someone pointed out the other day that I’d not officially announced it. Consider this the official announcement of the meeting on September 10, 2015. > > The rough agenda is to discuss any and all alternatives to the Open Config proposal, and then compare/contrast the differences. The goal of the meeting is to present a way forward to the WG between choosing to adopt this proposal or not, in whole or part, or to recommend in whole or part, the alternatives. > > —Tom > > > > > On Aug 7, 2015:11:21 AM, at 11:21 AM, Benoit Claise wrote: > > > > Dear all, > > > > Let me set the stage for this future interim. > > > > First of (and let me repeat), I'm happy that the operators gathered and collectively worked on YANG models and related requirements. > > > > The previous two interim meetings in June on the openconfig issues (draft-openconfig-netmod-opstate-01 and draft-openconfig-netmod-model-structure-00 ) were successful in the sense that the requirements are now understood. > > > > Unfortunately, some key players were not in Prague and we could not finalize the discussion. > > How to represent the operational state is one important guidance from RFC 6087bis that we must be providing to all existing and future YANG models (and not only in the IETF). > > > > We need to bring closure on that topic, and this is the plan for that interim meeting in September. > > > > http://datatracker.ietf.org/doc/draft-openconfig-netmod-opstate/ has been updated. Please comment on this version. > > Also, any alternate proposals must be prepared for that interim in September. They must be prepared with the same level of rigour as draft-openconfig-netmod-opstate., i.e. must have the same level of details. > > > > In the meeting in September, the goal is to take a decision. > > > > Regards, Benoit (OPS AD) > > > >> > >> Hello, > >> NETMOD Working Group invites you to join this WebEx meeting. > >> > >> NETMOD Interm meeting on OpenConfig > >> Thursday, September 10, 2015 > >> 11:00 am | Eastern Daylight Time (New York, GMT-04:00) | 1 hr > >> > >> Join WebEx meeting > >> Meeting number: 645 732 277 > >> Meeting password: 1234 > >> > >> Join by phone > >> 1-877-668-4493 Call-in toll free number (US/Canada) > >> 1-650-479-3208 Call-in toll number (US/Canada) > >> Access code: 645 732 277 > >> Toll-free calling restrictions > >> > >> Add this meeting to your calendar. > >> > >> Can't join the meeting? Contact support. > >> > >> IMPORTANT NOTICE: Please note that this WebEx service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session. > >> > >> > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > -- 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 Aug 18 07:32:44 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD8A1A8879 for ; Tue, 18 Aug 2015 07:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.239 X-Spam-Level: X-Spam-Status: No, score=0.239 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_75=0.6, 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 ZeeP0z_TT71H for ; Tue, 18 Aug 2015 07:32:41 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3CCB1A884E for ; Tue, 18 Aug 2015 07:32:40 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:7150:746b:9d1b:a30d] (unknown [IPv6:2001:718:1a02:1:7150:746b:9d1b:a30d]) by mail.nic.cz (Postfix) with ESMTPSA id 6523918140A; Tue, 18 Aug 2015 16:32:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1439908359; bh=8gQP6it8zkw4okOlURXXpWVs4ZlsnTYEL4WwQkJKfjM=; h=From:Date:To; b=NftmjVE1x+EsTIv0E1OKE52NPdADRVCFFTX+jD7yZPHzzRDfJT3caW2ZbSdsdZyDf 1i2qaNZa7L790A+xDvRphajMdsrVsqzJHmhXrLBOnFpJaGqzhG/JBxHXJnuOQh7M3C VwmNMDmLMwDaNs5HW4OmITnd/d7Wm270VjAWKIoY= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: <20150818.154223.1301963938445592911.mbj@tail-f.com> Date: Tue, 18 Aug 2015 16:32:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150818.130919.1060632323457095150.mbj@tail-f.com> <778755AA-66CB-491B-9BD7-81061125CAFC@nic.cz> <20150818.154223.1301963938445592911.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Y26 again, sorry X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 14:32:43 -0000 > On 18 Aug 2015, at 15:42, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >>=20 >>> On 18 Aug 2015, at 13:09, Martin Bjorklund wrote: >>>=20 >>> Hi, >>>=20 >>> Ladislav Lhotka wrote: >>>> Hi, >>>>=20 >>>> although YANG 1.1 issue Y26 [1] is marked as DONE, I think the = adopted >>>> solution Y26-02 is really horrible, so at least I want to make sure >>>> the >>>> WG is aware of the consequences. >>>>=20 >>>> I am currently working on a data model for DNS zone data and the >>>> schema >>>> is like this: >>>>=20 >>>> module: dns-zones >>>> +--rw zones >>>> +--rw zone* [name] >>>> +--rw name inet:domain-name >>>> +--rw description? string >>>> +--rw class? ianadns:class >>>> +--rw rrset* [owner type] >>>> +--rw owner inet:domain-name >>>> +--rw type identityref >>>> +--rw description? string >>>> +--rw ttl positive-int32 >>>> +--rw rdata* [id] >>>> +--rw id string >>>> +--rw description? string >>>>=20 >>>> The idea is that specific RDATA will be added for each RR type = (with a >>>> "when" condition based on "type"). Data for essential RR Types = (SOA, >>>> NS, >>>> A, AAAA, ...) can be defined in the same module but for some types >>>> they >>>> need to be defined in other modules and added via augmenting the >>>> target >>>> node "rdata". Typically, some (or all) of RDATA is mandatory, and = this >>>> is where Y26 comes into play. The solution recommended by Y26-02 = would >>>> look like this: >>>>=20 >>>> augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" { >>>> when "derived-from-or-self(../dnsz:type,'iana-dns-parameters'," >>>> + "'TLSA')"; >>>> container rdata { // <=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >>>> presence "TLSA data"; >>>> leaf certificate-usage { >>>> mandatory true; >>>> ... >>>> } >>>=20 >>> Working with what we currently have, I think this would look a bit >>> better if you instead did: >>>=20 >>> augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" { >>> when "derived-from-or-self(../dnsz:type,'iana-dns-parameters'," >>> + "'TLSA')"; >>> container tlsa { // name change >>> presence "TLSA data"; >>> leaf certificate-usage { >>> mandatory true; >>> =E2=80=A6 >>=20 >> Right, using the same name for the presence container won=E2=80=99t = work if >> rdata for multiple rr types are defined in the same module. >>=20 >> But the main problem still remains: container =E2=80=9Ctlsa=E2=80=9D = needn=E2=80=99t be >> present, which leads to an invalid resource record. The server would >> have no choice but reject such configuration. I don=E2=80=99t get how = this >> helps old clients. >=20 > Well, if it doesn't make any sense to configure an rrset of e.g. type > 'TLSA' without the 'tlsa' container, I don't expect such clients to be > deployed in the network. Then it would be better at least to define TLSA identity together with = rdata for TLSA rr, rather than having all identities defined in one = place. >=20 > The rule about not augmenting mandatory nodes is there to protect > properly functioning clients. For example, suppose you have your tlsa > module and a client that knows this and works well. Then some vendor > writes a new module that also augments some mandatory nodes when the > type is 'TLSA'. Then the client that used to work doesn't work > anymore. It seems we all agree that, using Randy=E2=80=99s terminology, = subclassing augments are OK. We only can=E2=80=99t reliably identify = such augments because YANG uses =E2=80=9Cpoor man=E2=80=99s=E2=80=9D = subclassing. You are arguing against mandatory extension augments but then: 1. A standard module might need to be patched by adding a mandatory = parameter, which is currently impossible via both augment and module = update, 2. The rogue vendor can use a must statement to achieve the same effect = (or perhaps just state it in a description?). What=E2=80=99s important = is whether the server that advertises such an extension rejects a = configuration where the new parameter is missing or not. Lada >=20 >=20 > /martin >=20 >=20 >=20 >=20 >>=20 >>>=20 >>> I think the model itself is quite ok with this design, but the >>> instance data contains the type information encoded twice; once in = the >>> the 'type' leaf and once in the container 'tlsa'. Since the 'type' >>> leaf is part of the key, it cannot easily be removed. >>>=20 >>>=20 >>> As for this issue in general, I think we all agreed that it would be >>> nice if we could allow such data to be mandatory, but noone came up >>> with any proposal for how to do this. The "safe" use case we >>> discussed was when the identity was defined in the same module as = the >>> augment, but that is not the case in you module, where all = identities >>> are defined in a central module. >>=20 >> =E2=80=A6 as it is with interface types. >>=20 >> I think it would be better to remove the restriction altogether. If a >> parameter is mandatory by its substance, it should be defined as >> mandatory in the data model. And if somebody wants to break old (or >> someone else=E2=80=99s) clients, there are other ways for achieving = it. >>=20 >> Lada >>=20 >>>=20 >>>=20 >>> /martin >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Aug 18 07:35:55 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E983A1A8886 for ; Tue, 18 Aug 2015 07:35:52 -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_75=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 r4qnZdpBne1Q for ; Tue, 18 Aug 2015 07:35: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 505EC1A8897 for ; Tue, 18 Aug 2015 07:35:51 -0700 (PDT) Received: from localhost (unknown [173.38.220.43]) by mail.tail-f.com (Postfix) with ESMTPSA id 5FF121AE019A; Tue, 18 Aug 2015 16:35:50 +0200 (CEST) Date: Tue, 18 Aug 2015 16:35:49 +0200 (CEST) Message-Id: <20150818.163549.1307568712565200740.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <778755AA-66CB-491B-9BD7-81061125CAFC@nic.cz> <20150818.154223.1301963938445592911.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Y26 again, sorry X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 14:35:53 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+ID4gT24gMTggQXVn IDIwMTUsIGF0IDE1OjQyLCBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4gd3JvdGU6 DQo+ID4gDQo+ID4gTGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gPj4g DQo+ID4+PiBPbiAxOCBBdWcgMjAxNSwgYXQgMTM6MDksIE1hcnRpbiBCam9ya2x1bmQgPG1iakB0 YWlsLWYuY29tPiB3cm90ZToNCj4gPj4+IA0KPiA+Pj4gSGksDQo+ID4+PiANCj4gPj4+IExhZGlz bGF2IExob3RrYSA8bGhvdGthQG5pYy5jej4gd3JvdGU6DQo+ID4+Pj4gSGksDQo+ID4+Pj4gDQo+ ID4+Pj4gYWx0aG91Z2ggWUFORyAxLjEgaXNzdWUgWTI2IFsxXSBpcyBtYXJrZWQgYXMgRE9ORSwg SSB0aGluayB0aGUgYWRvcHRlZA0KPiA+Pj4+IHNvbHV0aW9uIFkyNi0wMiBpcyByZWFsbHkgaG9y cmlibGUsIHNvIGF0IGxlYXN0IEkgd2FudCB0byBtYWtlIHN1cmUNCj4gPj4+PiB0aGUNCj4gPj4+ PiBXRyBpcyBhd2FyZSBvZiB0aGUgY29uc2VxdWVuY2VzLg0KPiA+Pj4+IA0KPiA+Pj4+IEkgYW0g Y3VycmVudGx5IHdvcmtpbmcgb24gYSBkYXRhIG1vZGVsIGZvciBETlMgem9uZSBkYXRhIGFuZCB0 aGUNCj4gPj4+PiBzY2hlbWENCj4gPj4+PiBpcyBsaWtlIHRoaXM6DQo+ID4+Pj4gDQo+ID4+Pj4g bW9kdWxlOiBkbnMtem9uZXMNCj4gPj4+PiAgKy0tcncgem9uZXMNCj4gPj4+PiAgICAgKy0tcncg em9uZSogW25hbWVdDQo+ID4+Pj4gICAgICAgICstLXJ3IG5hbWUgICAgICAgICAgIGluZXQ6ZG9t YWluLW5hbWUNCj4gPj4+PiAgICAgICAgKy0tcncgZGVzY3JpcHRpb24/ICAgc3RyaW5nDQo+ID4+ Pj4gICAgICAgICstLXJ3IGNsYXNzPyAgICAgICAgIGlhbmFkbnM6Y2xhc3MNCj4gPj4+PiAgICAg ICAgKy0tcncgcnJzZXQqIFtvd25lciB0eXBlXQ0KPiA+Pj4+ICAgICAgICAgICArLS1ydyBvd25l ciAgICAgICAgICBpbmV0OmRvbWFpbi1uYW1lDQo+ID4+Pj4gICAgICAgICAgICstLXJ3IHR5cGUg ICAgICAgICAgIGlkZW50aXR5cmVmDQo+ID4+Pj4gICAgICAgICAgICstLXJ3IGRlc2NyaXB0aW9u PyAgIHN0cmluZw0KPiA+Pj4+ICAgICAgICAgICArLS1ydyB0dGwgICAgICAgICAgICBwb3NpdGl2 ZS1pbnQzMg0KPiA+Pj4+ICAgICAgICAgICArLS1ydyByZGF0YSogW2lkXQ0KPiA+Pj4+ICAgICAg ICAgICAgICArLS1ydyBpZCAgICAgICAgICAgICBzdHJpbmcNCj4gPj4+PiAgICAgICAgICAgICAg Ky0tcncgZGVzY3JpcHRpb24/ICAgc3RyaW5nDQo+ID4+Pj4gDQo+ID4+Pj4gVGhlIGlkZWEgaXMg dGhhdCBzcGVjaWZpYyBSREFUQSB3aWxsIGJlIGFkZGVkIGZvciBlYWNoIFJSIHR5cGUgKHdpdGgg YQ0KPiA+Pj4+ICJ3aGVuIiBjb25kaXRpb24gYmFzZWQgb24gInR5cGUiKS4gRGF0YSBmb3IgZXNz ZW50aWFsIFJSIFR5cGVzIChTT0EsDQo+ID4+Pj4gTlMsDQo+ID4+Pj4gQSwgQUFBQSwgLi4uKSBj YW4gYmUgZGVmaW5lZCBpbiB0aGUgc2FtZSBtb2R1bGUgYnV0IGZvciBzb21lIHR5cGVzDQo+ID4+ Pj4gdGhleQ0KPiA+Pj4+IG5lZWQgdG8gYmUgZGVmaW5lZCBpbiBvdGhlciBtb2R1bGVzIGFuZCBh ZGRlZCB2aWEgYXVnbWVudGluZyB0aGUNCj4gPj4+PiB0YXJnZXQNCj4gPj4+PiBub2RlICJyZGF0 YSIuIFR5cGljYWxseSwgc29tZSAob3IgYWxsKSBvZiBSREFUQSBpcyBtYW5kYXRvcnksIGFuZCB0 aGlzDQo+ID4+Pj4gaXMgd2hlcmUgWTI2IGNvbWVzIGludG8gcGxheS4gVGhlIHNvbHV0aW9uIHJl Y29tbWVuZGVkIGJ5IFkyNi0wMiB3b3VsZA0KPiA+Pj4+IGxvb2sgbGlrZSB0aGlzOg0KPiA+Pj4+ IA0KPiA+Pj4+IGF1Z21lbnQgIi9kbnN6OnpvbmVzL2Ruc3o6em9uZS9kbnN6OnJyc2V0L2Ruc3o6 cmRhdGEiIHsNCj4gPj4+PiAgIHdoZW4gImRlcml2ZWQtZnJvbS1vci1zZWxmKC4uL2Ruc3o6dHlw ZSwnaWFuYS1kbnMtcGFyYW1ldGVycycsIg0KPiA+Pj4+ICAgICAgKyAiJ1RMU0EnKSI7DQo+ID4+ Pj4gICBjb250YWluZXIgcmRhdGEgeyAgICAgICAgICAgIC8vIDw9PT09PT09PT09PT09PT09PQ0K PiA+Pj4+ICAgICAgIHByZXNlbmNlICJUTFNBIGRhdGEiOw0KPiA+Pj4+ICAgICAgIGxlYWYgY2Vy dGlmaWNhdGUtdXNhZ2Ugew0KPiA+Pj4+ICAgICAgICAgICBtYW5kYXRvcnkgdHJ1ZTsNCj4gPj4+ PiAgICAgICAgICAgLi4uDQo+ID4+Pj4gICAgICAgfQ0KPiA+Pj4gDQo+ID4+PiBXb3JraW5nIHdp dGggd2hhdCB3ZSBjdXJyZW50bHkgaGF2ZSwgSSB0aGluayB0aGlzIHdvdWxkIGxvb2sgYSBiaXQN Cj4gPj4+IGJldHRlciBpZiB5b3UgaW5zdGVhZCBkaWQ6DQo+ID4+PiANCj4gPj4+IGF1Z21lbnQg Ii9kbnN6OnpvbmVzL2Ruc3o6em9uZS9kbnN6OnJyc2V0L2Ruc3o6cmRhdGEiIHsNCj4gPj4+ICAg d2hlbiAiZGVyaXZlZC1mcm9tLW9yLXNlbGYoLi4vZG5zejp0eXBlLCdpYW5hLWRucy1wYXJhbWV0 ZXJzJywiDQo+ID4+PiAgICAgICsgIidUTFNBJykiOw0KPiA+Pj4gICBjb250YWluZXIgdGxzYSB7 IC8vIG5hbWUgY2hhbmdlDQo+ID4+PiAgICAgICBwcmVzZW5jZSAiVExTQSBkYXRhIjsNCj4gPj4+ ICAgICAgIGxlYWYgY2VydGlmaWNhdGUtdXNhZ2Ugew0KPiA+Pj4gICAgICAgICAgIG1hbmRhdG9y eSB0cnVlOw0KPiA+Pj4gICAgICAgICAgIOKApg0KPiA+PiANCj4gPj4gUmlnaHQsIHVzaW5nIHRo ZSBzYW1lIG5hbWUgZm9yIHRoZSBwcmVzZW5jZSBjb250YWluZXIgd29u4oCZdCB3b3JrIGlmDQo+ ID4+IHJkYXRhIGZvciBtdWx0aXBsZSByciB0eXBlcyBhcmUgZGVmaW5lZCBpbiB0aGUgc2FtZSBt b2R1bGUuDQo+ID4+IA0KPiA+PiBCdXQgdGhlIG1haW4gcHJvYmxlbSBzdGlsbCByZW1haW5zOiBj b250YWluZXIg4oCcdGxzYeKAnSBuZWVkbuKAmXQgYmUNCj4gPj4gcHJlc2VudCwgd2hpY2ggbGVh ZHMgdG8gYW4gaW52YWxpZCByZXNvdXJjZSByZWNvcmQuIFRoZSBzZXJ2ZXIgd291bGQNCj4gPj4g aGF2ZSBubyBjaG9pY2UgYnV0IHJlamVjdCBzdWNoIGNvbmZpZ3VyYXRpb24uIEkgZG9u4oCZdCBn ZXQgaG93IHRoaXMNCj4gPj4gaGVscHMgb2xkIGNsaWVudHMuDQo+ID4gDQo+ID4gV2VsbCwgaWYg aXQgZG9lc24ndCBtYWtlIGFueSBzZW5zZSB0byBjb25maWd1cmUgYW4gcnJzZXQgb2YgZS5nLiB0 eXBlDQo+ID4gJ1RMU0EnIHdpdGhvdXQgdGhlICd0bHNhJyBjb250YWluZXIsIEkgZG9uJ3QgZXhw ZWN0IHN1Y2ggY2xpZW50cyB0byBiZQ0KPiA+IGRlcGxveWVkIGluIHRoZSBuZXR3b3JrLg0KPiAN Cj4gVGhlbiBpdCB3b3VsZCBiZSBiZXR0ZXIgYXQgbGVhc3QgdG8gZGVmaW5lIFRMU0EgaWRlbnRp dHkgdG9nZXRoZXIgd2l0aA0KPiByZGF0YSBmb3IgVExTQSByciwgcmF0aGVyIHRoYW4gaGF2aW5n IGFsbCBpZGVudGl0aWVzIGRlZmluZWQgaW4gb25lDQo+IHBsYWNlLg0KDQpZZXMsIGFuZCAqbWF5 YmUqIGl0IHdvdWxkIGJlIHBvc3NpYmxlIHRvIGNvbWUgdXAgd2l0aCBlaXRoZXIgdGV4dCB0aGF0 DQphbGxvd3Mgc3VjaCBhbiBhdWdtZW50YXRpb24sIG9yIGEgbmV3IFlBTkcgc3RhdGVtZW50IHRv IGhhbmRsZSB0aGlzDQpzaXR1YXRpb24uDQoNCg0KDQovbWFydGluDQoNCg0KDQoNCj4gPiBwcm9w ZXJseSBmdW5jdGlvbmluZyBjbGllbnRzLiAgRm9yIGV4YW1wbGUsIHN1cHBvc2UgeW91IGhhdmUg eW91ciB0bHNhDQo+ID4gbW9kdWxlIGFuZCBhIGNsaWVudCB0aGF0IGtub3dzIHRoaXMgYW5kIHdv cmtzIHdlbGwuICBUaGVuIHNvbWUgdmVuZG9yDQo+ID4gd3JpdGVzIGEgbmV3IG1vZHVsZSB0aGF0 IGFsc28gYXVnbWVudHMgc29tZSBtYW5kYXRvcnkgbm9kZXMgd2hlbiB0aGUNCj4gPiB0eXBlIGlz ICdUTFNBJy4gIFRoZW4gdGhlIGNsaWVudCB0aGF0IHVzZWQgdG8gd29yayBkb2Vzbid0IHdvcmsN Cj4gPiBhbnltb3JlLg0KPiANCj4gSXQgc2VlbXMgd2UgYWxsIGFncmVlIHRoYXQsIHVzaW5nIFJh bmR54oCZcyB0ZXJtaW5vbG9neSwgc3ViY2xhc3NpbmcNCj4gYXVnbWVudHMgYXJlIE9LLiBXZSBv bmx5IGNhbuKAmXQgcmVsaWFibHkgaWRlbnRpZnkgc3VjaCBhdWdtZW50cyBiZWNhdXNlDQo+IFlB TkcgdXNlcyDigJxwb29yIG1hbuKAmXPigJ0gc3ViY2xhc3NpbmcuDQo+IA0KPiBZb3UgYXJlIGFy Z3VpbmcgYWdhaW5zdCBtYW5kYXRvcnkgZXh0ZW5zaW9uIGF1Z21lbnRzIGJ1dCB0aGVuOg0KPiAN Cj4gMS4gQSBzdGFuZGFyZCBtb2R1bGUgbWlnaHQgbmVlZCB0byBiZSBwYXRjaGVkIGJ5IGFkZGlu ZyBhIG1hbmRhdG9yeQ0KPiBwYXJhbWV0ZXIsIHdoaWNoIGlzIGN1cnJlbnRseSBpbXBvc3NpYmxl IHZpYSBib3RoIGF1Z21lbnQgYW5kIG1vZHVsZQ0KPiB1cGRhdGUsDQo+IA0KPiAyLiBUaGUgcm9n dWUgdmVuZG9yIGNhbiB1c2UgYSBtdXN0IHN0YXRlbWVudCB0byBhY2hpZXZlIHRoZSBzYW1lDQo+ IGVmZmVjdCAob3IgcGVyaGFwcyBqdXN0IHN0YXRlIGl0IGluIGEgZGVzY3JpcHRpb24/KS4gV2hh dOKAmXMgaW1wb3J0YW50DQo+IGlzIHdoZXRoZXIgdGhlIHNlcnZlciB0aGF0IGFkdmVydGlzZXMg c3VjaCBhbiBleHRlbnNpb24gcmVqZWN0cyBhDQo+IGNvbmZpZ3VyYXRpb24gd2hlcmUgdGhlIG5l dyBwYXJhbWV0ZXIgaXMgbWlzc2luZyBvciBub3QuDQo+IA0KPiBMYWRhDQo+IA0KPiA+IA0KPiA+ IA0KPiA+IC9tYXJ0aW4NCj4gPiANCj4gPiANCj4gPiANCj4gPiANCj4gPj4gDQo+ID4+PiANCj4g Pj4+IEkgdGhpbmsgdGhlIG1vZGVsIGl0c2VsZiBpcyBxdWl0ZSBvayB3aXRoIHRoaXMgZGVzaWdu LCBidXQgdGhlDQo+ID4+PiBpbnN0YW5jZSBkYXRhIGNvbnRhaW5zIHRoZSB0eXBlIGluZm9ybWF0 aW9uIGVuY29kZWQgdHdpY2U7IG9uY2UgaW4gdGhlDQo+ID4+PiB0aGUgJ3R5cGUnIGxlYWYgYW5k IG9uY2UgaW4gdGhlIGNvbnRhaW5lciAndGxzYScuICBTaW5jZSB0aGUgJ3R5cGUnDQo+ID4+PiBs ZWFmIGlzIHBhcnQgb2YgdGhlIGtleSwgaXQgY2Fubm90IGVhc2lseSBiZSByZW1vdmVkLg0KPiA+ Pj4gDQo+ID4+PiANCj4gPj4+IEFzIGZvciB0aGlzIGlzc3VlIGluIGdlbmVyYWwsIEkgdGhpbmsg d2UgYWxsIGFncmVlZCB0aGF0IGl0IHdvdWxkIGJlDQo+ID4+PiBuaWNlIGlmIHdlIGNvdWxkIGFs bG93IHN1Y2ggZGF0YSB0byBiZSBtYW5kYXRvcnksIGJ1dCBub29uZSBjYW1lIHVwDQo+ID4+PiB3 aXRoIGFueSBwcm9wb3NhbCBmb3IgaG93IHRvIGRvIHRoaXMuICBUaGUgInNhZmUiIHVzZSBjYXNl IHdlDQo+ID4+PiBkaXNjdXNzZWQgd2FzIHdoZW4gdGhlIGlkZW50aXR5IHdhcyBkZWZpbmVkIGlu IHRoZSBzYW1lIG1vZHVsZSBhcyB0aGUNCj4gPj4+IGF1Z21lbnQsIGJ1dCB0aGF0IGlzIG5vdCB0 aGUgY2FzZSBpbiB5b3UgbW9kdWxlLCB3aGVyZSBhbGwgaWRlbnRpdGllcw0KPiA+Pj4gYXJlIGRl ZmluZWQgaW4gYSBjZW50cmFsIG1vZHVsZS4NCj4gPj4gDQo+ID4+IOKApiBhcyBpdCBpcyB3aXRo IGludGVyZmFjZSB0eXBlcy4NCj4gPj4gDQo+ID4+IEkgdGhpbmsgaXQgd291bGQgYmUgYmV0dGVy IHRvIHJlbW92ZSB0aGUgcmVzdHJpY3Rpb24gYWx0b2dldGhlci4gSWYgYQ0KPiA+PiBwYXJhbWV0 ZXIgaXMgbWFuZGF0b3J5IGJ5IGl0cyBzdWJzdGFuY2UsIGl0IHNob3VsZCBiZSBkZWZpbmVkIGFz DQo+ID4+IG1hbmRhdG9yeSBpbiB0aGUgZGF0YSBtb2RlbC4gQW5kIGlmIHNvbWVib2R5IHdhbnRz IHRvIGJyZWFrIG9sZCAob3INCj4gPj4gc29tZW9uZSBlbHNl4oCZcykgY2xpZW50cywgdGhlcmUg YXJlIG90aGVyIHdheXMgZm9yIGFjaGlldmluZyBpdC4NCj4gPj4gDQo+ID4+IExhZGENCj4gPj4g DQo+ID4+PiANCj4gPj4+IA0KPiA+Pj4gL21hcnRpbg0KPiA+PiANCj4gPj4gLS0NCj4gPj4gTGFk aXNsYXYgTGhvdGthLCBDWi5OSUMgTGFicw0KPiA+PiBQR1AgS2V5IElEOiBFNzRFOEMwQw0KPiAN Cj4gLS0NCj4gTGFkaXNsYXYgTGhvdGthLCBDWi5OSUMgTGFicw0KPiBQR1AgS2V5IElEOiBFNzRF OEMwQw0KPiANCj4gDQo+IA0KPiANCg== From nobody Tue Aug 18 09:59:39 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1F61A8A39 for ; Tue, 18 Aug 2015 09:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.311 X-Spam-Level: X-Spam-Status: No, score=-13.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_15=0.6, J_CHICKENPOX_34=0.6, 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 pPfMdL76rh_d for ; Tue, 18 Aug 2015 09:59:34 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 094D51A8A0D for ; Tue, 18 Aug 2015 09:59:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14309; q=dns/txt; s=iport; t=1439917174; x=1441126774; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=Ja5wYr1kVhvpXYyFfFZgV0voOMvfHWGRDFDCu9oqukM=; b=ihIszWNTWc89ZV/kIoapzJcmuRgTy5Gxh3aDsDowoWdOh65WGr4A3Blt qOBFZ2WcsTKvcdZ4+0OEolFkSnf4LBh5rrsmG+ysxn+iYTgNIprZ5zztV 5CeYPVtaLIyq6Oi4mw1bu/t28G6xH9t/odabhCGmghX0i71tcVEBk8BXU w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D0BACGY9NV/xbLJq1dg29pgyS8WgqFMUoCggIBAQEBAQGBC4QjAQEBAwEBAQEgDwEFNgQHDAQLEAEDAQEBAQICBQwVAgIPAhYoCAYBDAYCAQEVAogLCA28EpYwAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EiiS6BA4Q/CUIHBgSCX4FDBYxeAYhChQSCbIR8gUpGhl4iiHCESINnJoIOHIFUPTMBgQaBRQEBAQ X-IronPort-AV: E=Sophos;i="5.15,702,1432598400"; d="scan'208";a="606440264" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 18 Aug 2015 16:59:31 +0000 Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t7IGxVIn017003; Tue, 18 Aug 2015 16:59:31 GMT To: Ladislav Lhotka , Andy Bierman References: <52B35D5C-E9F9-48B7-8B80-9416ABB18642@nic.cz> From: Robert Wilton Message-ID: <55D36473.90609@cisco.com> Date: Tue, 18 Aug 2015 17:59:31 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <52B35D5C-E9F9-48B7-8B80-9416ABB18642@nic.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Y34 - root node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 16:59:38 -0000 On 11/08/2015 08:38, Ladislav Lhotka wrote: >> On 10 Aug 2015, at 22:15, Andy Bierman wrote: >> >> >> >> On Mon, Aug 10, 2015 at 12:34 PM, Acee Lindem (acee) wrote: >> I think there is agreement that there is a problem. The YANG Routing Design Team is addressing this with https://www.ietf.org/id/draft-rtgyangdt-rtgwg-device-model-00.txt (which has evolved from https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt). In essence, a place for everything and everything in its place. However, there are those who feel that can’t mandate a single model structure for network devices and we need mechanisms to manage multiple models but allow for different device structure (e.g., https://www.ietf.org/id/draft-bierman-netmod-yang-package-00.txt). I hope we can agree on an approach in the coming interim meetings. >> >> >> Do you expect "everything in its place" to apply to all other SDOs and >> all vendor modules? Or do you expect just the IETF routing modules >> to follow this subtree hierarchy? If the former, does this mean the >> YANG Routing Design Team is the "YANG data placement authority" >> or all YANG modules that ever get written? How long should >> it take for all other SDOs and vendors to redo all their existing >> modules to re-root them in their assigned place in the data tree? >> >> IMO is is not a good idea to rely on rigid data node placement, >> and a single data placement authority. It is better and use meta-data >> built from the YANG modules (or YANG packages) instead. I think that having fixed paths may end up being too restrictive. >> >> The reason Linux uses packages to install/update functionality >> is because managing 8000 packages is hard enough. >> Managing 247,000 individual files would be insane. >> The actual location of files is quite configurable and different >> across distros. We could learn something from the last decade >> of Linux package management, and try to apply it to YANG. >> > That’s an interesting idea, could a YANG package also specify, e.g. that the root node for the package is X/Y/Z? This could solve some use cases for relocatability, and it would also be relatively easy to modify all absolute XPath expressions inside the package. If someone wants to builds a YANG controller node that is managing the configuration for a network of devices then wouldn't they want a particular device's interface configuration to be located somewhere like /network/device//interfaces/interface? Ideally, they would be able to use the same YANG definitions that are defined for /interfaces/ but root them relative to /network/device//. Having YANG packages being able to control the relative paths of the imported YANG modules would possibly allow for more flexibility in how YANG modules fit together, and also give a more pragmatic way for how these could be changed/upgraded in future if necessary. Cheers, Rob > > Lada > >> >> >> >> >> Thanks, >> Acee >> >> >> Andy >> >> >> >> >> From: netmod on behalf of "Einar Nilsen-Nygaard (einarnn)" >> Date: Monday, August 10, 2015 at 5:29 AM >> To: Jonathan Hansford >> Cc: NETMOD Working Group >> Subject: Re: [netmod] Y34 - root node >> >> As someone sharing responsibilities for guiding a number of development teams both defining new models and implementing to some already defined models in this area, I can only agree with this addition to what I said earlier. >> >> Cheers, >> >> Einar >> >>> On Aug 10, 2015, at 9:46 AM, Jonathan Hansford wrote: >>> >>> And it is not just end users who need help to better understand YANG models and how to use them. For those still on the edge, looking to finally take the plunge and use NETCONF/YANG to configure their devices, help is also required to determine how best to structure their YANG models, make use of the existing ones, etc. For those who have "grown up" with the developments in NETCONF and YANG, much of this is probably second nature. But coming to it cold (in the sense of compiling/writing a first set of YANG models for a device; I've been following the netconf/netmod WGs for 3+ years), it still feels very much like a dark art! It is not just the individual modules, it is how to put them together to best manage a device (let alone a system). >>> >>> Jonathan >>> >>> >>> >>> ----- Original Message ----- >>> From: >>> "Einar Nilsen-Nygaard (einarnn)" >>> >>> To: >>> "Andy Bierman" >>> Cc: >>> "NETMOD Working Group" >>> Sent: >>> Sat, 8 Aug 2015 11:10:15 +0000 >>> Subject: >>> Re: [netmod] Y34 - root node >>> >>> >>> Andy, >>> >>> I agree that there is a need for organization of models, but I don’t have a firm position on draft-openconfig-netmod-model-structure/draft-rtgyangdt-rtgwg-device-model or draft-bierman-netmod-yang-package. But we absolutely need *something* to help end-users of the models comprehend the overall structure of models, their relationship and how to use them. >>> >>> Cheers, >>> >>> Einar >>> >>> On Aug 4, 2015, at 5:16 PM, Andy Bierman wrote: >>> >>> >>> >>> On Tue, Aug 4, 2015 at 2:34 AM, t.petch wrote: >>> ----- Original Message ----- >>> From: "Andy Bierman" >>> To: "t.petch" >>> Sent: Monday, August 03, 2015 5:17 PM >>> >>>> ----- Original Message ----- >>>> From: "Andy Bierman" >>>> To: "t.petch" >>>> Sent: Monday, August 03, 2015 4:10 PM >>>> >>>>> ----- Original Message ----- >>>>> From: "Andy Bierman" andy@yumaworks.com >>>>> Sent: Saturday, August 01, 2015 7:05 PM >>>>> On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem (acee) >>>>> >>>>>> On 8/1/15, 2:51 AM, j.schoenwaelder@jacobs-university.de> wrote: >>>>>> >>>>>> Section 1.1 in >>>>>> >>>> https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt >>>>>> lists the goals of a generic model structure that will accommodate >>>>> most >>>>>> modern network devices. I guess you don’t agree that these are >>>>> desirable? >>>>> >>>>> The only objection I have to this draft is the insertion of a >>> top-level >>>>> root >>>>> called "device". (Might as well be called "self"). >>>>> There are no sibling nodes planned or intended for >>>>> this node, so it serves as an extra document root. >>>>> >>>>> >>>>> One aspect of YANG I have never grasped is what a root means, if >>>>> anything. >>>>> >>>>> I understand that it is needed for NETCONF (filters) and for YANG >>>>> (augments, constraints) and so must be somewhere and must be >>>> relatively >>>>> stable, but has it any other significance in the data model? >>>>> >>>>> As you may recall, I was involved with SMI first, where the root is >>>>> somewhere up in the sky and life only becomes interesting some six >>>>> levels down the hierarchy and that may colour my thinking. >>>>> >>>> YANG does a poor job of defining the root for YANG data nodes. >>>> It is sometimes called a datastore (in the abstract). >>>> Technically, YANG borrows the definition from XPath. >>>> YANG just defines top-level data nodes and the parent of >>>> these nodes is the document root >>>> >>>> There is no protocol or encoding neutral definition, >>>> only an XML-specific definition. >>>> >>>> >>>> >>>> Thanks for that. >>>> >>>> It seems to me that much of the extensive discussion on Y34 (all of >>>> which I have read) is as much political as technical, that is SMI is >>>> hierarchical, top down, perhaps befitting its origins in ISO, whereas >>>> YANG is bottom up. IETF-like. YANG could have had a single tree, but >>>> doesn't. So when I read >>>> >>>> https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt >>>> >>>> I see a plea for a more hierarchical organisation, and when I read >>>> >>>> draft-bjorklund-netmod-openconfig-reply-00 >>>> >>>> I see a response that says we are not like that. >>>> >>>> If so, I doubt that there ever will be a technical solution. >>>> >>>> And I am mindful that when I configure routing in a (Cisco) router, I >>>> have to do some of it under the interface definitions and some of it >>>> under the definition of the routing protocol. Which is life, never >>>> wholy interface-centric and never wholy routing protocol-centric! >>> Are you saying the job would be easier if the >>> path was /device/interfaces/interface instead >>> of just /interfaces/interface? Are you saying >>> that /protocols/routing could not also be defined? >>> Clearly edit-config and copy-config allow both >>> subtrees to be accessed in the same operation, >>> so I don't understand your concern. >>> >>> I have been trying to get the root node to be better defined >>> in the protocols that use YANG (i.e., ncx:root, Y34-04). >>> IMO this is a better approach than defining a YANG module >>> with a special container that all other modules are expected >>> to augment. YANG is designed such that each vendor or SDO >>> is not dependent on other vendors or SDOs in order to >>> define data nodes. >>> >>> >>> >>> Andy >>> >>> I am agreeing with you that adding 'device' brings no technical benefit, >>> rather that the motivation is the opposite of technical (which I >>> referred to as political). I am also agreeing with the current declared >>> consensus on Y34. >>> >>> And yes, YANG is going to give us a large number of modules, some >>> tightly coupled (augments) some loosely so (how many do you need to >>> configure OSPF?) and work in this area will be of benefit now and >>> probably essential in a few years time. That said, I am unsure what >>> such work would be like; I am looking (in despair) at 50 routing area >>> YANG models and wondering how a user will ever get a coherent picture of >>> how to do what they want to do. >>> >>> >>> >>> The "YANG Land Grab" gives a false sense of progress. >>> Reaching WG consensus on every single leaf is hard work. >>> >>> I don't think a collection of 100s of YANG modules is ever >>> going to to be easy to understand. Operators will not examine >>> a NETCONF message, look at 150 module URIs, >>> and say "I know exactly what this device supports". >>> I guess it is up to client tools to do that >>> >>> I wrote a draft that defines YANG Packages, which can provide >>> a higher level of organization for YANG modules. >>> >>> http://datatracker.ietf.org/doc/draft-bierman-netmod-yang-package/ >>> >>> You and I are apparently in the minority, since the official status >>> is that there is no problem with the current approach, and no need >>> to organize individual YANG modules into any larger abstractions. >>> >>> >>> >>> Tom Petch >>> >>> >>> >>> Andy >>> >>> Andy >>> >>>> Andy >>>> >>>>> The well-specified XPath and YANG root (/) can be >>>>> accessed by all protocol operations, exactly the same >>>>> as a node called 'device'. The actual node name will >>>>> depend on the RPC function (e.g. 'data' or 'config'). >>>>> >>>>> This is more than redundant however. It introduces a "super-module" >>>>> into YANG that every other module is expected to augment. >>>>> YANG is intended to be more loosely coupled than that. >>>>> This introduces an extra node and namespace declaration >>>>> in all protocol messages, increasing message sizes. >>>>> >>>>> It also assumes all existing YANG models will get rewritten to >>>>> account for "/device" in all path and XPath expressions. >>>>> This is highly disruptive to existing deployments. >>>>> Also, multiple data models to edit the same thing causes lots >>>>> of extra complexity in the server (supporting both old >>>>> location and new location). >>>>> >>>>> IMO a resource directory approach is much more realistic. >>>>> The /device tree can contain all the organized NP containers. >>>>> Instead of all the actual data nodes, this tree just has pointers >>>>> to the real location of the resource. (like 301 Moved Permanently) >>>>> >>>>>> Acee >>>>>> >>>>> Andy >>> >>> ** Solution Y34-02 >>> >>> Keep 'anyxml'. Introduce 'anydata' as above but without the >>> 'format' substatement. >>> >>> 'anyxml' would still be used to represent unrestricted XML, as is >>> done in NETCONF. >>> >>> 'anydata' would be an unknown chunk of data that can be modelled >>> with YANG. Can be encoded as xml or json. >>> >>> For example: >>> >>> #+BEGIN_EXAMPLE >>> anydata data; >>> #+END_EXAMPLE >>> >>> ** Solution Y34-05 >>> >>> Same as Y34-02 plus two guidelines adopted from Y34-04: >>> >>> - Keep 'anyxml' unchanged as it is defined in YANG 1.0. This >>> ensures backward compatibility. >>> - Introduce a new 'anydata' statement that represents an unknown >>> chunk of data that can be modeled with YANG >>> - Document that implementations MAY have restrictions for anyxml and >>> that anyxml is not necessarily interoperable; data model writers >>> should use anydata whenever possible. >>> - The guidelines document should say that YANG Doctors will review >>> each use of anyxml in IETF modules when YANG 1.1 is adopted to >>> avoid its use whenever possible. >>> >>> >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Aug 18 10:23:06 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E493A1A8A97 for ; Tue, 18 Aug 2015 10:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_34=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 0Po6W466eL99 for ; Tue, 18 Aug 2015 10:22:59 -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 2F7F91A8A87 for ; Tue, 18 Aug 2015 10:22:59 -0700 (PDT) Received: by lbbsx3 with SMTP id sx3so107593219lbb.0 for ; Tue, 18 Aug 2015 10:22:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=W+AgHk1atyruer3EArh/UYO5rGwh5RgBLcIuLQC6vLo=; b=I0hXuQ2gkat7oMrsSisSN8k0yBxvAtboQmACk+jymMipHMzjxXoVaiUXLi3kPlZx0s x3blRlKbXvrQhv6HR8ExZYeHorMgWPAXKwAl36twjOqZP2hYVQuNvoEc/bhCqwvI4vt+ Sgd+8vl/wptnk8QI/KSZ3jMcAY2O1MCHIbffAQ6ocGycFkg6FouQgsnXqZekXkiPZjHr /emCPb5MYfYPBcd/j3PJqsauHim6b7H++UfO4q8l1/VyCp1NpvKsaMpTd0VfPFTH1ivD Llb3MbT3RHH88qiWlDT/66+H2q42Y6hDDjh5lI7tmME6PLU4MkwxgKWBXnjoKyKuPd9g qxUQ== X-Gm-Message-State: ALoCoQmNwDZpwkaldU9hCYWaHsX1uh2o4jd2e4CVTKHqY1TxZDB3HgGh4rpx7wHeWUZvPmpPZcqa MIME-Version: 1.0 X-Received: by 10.112.85.3 with SMTP id d3mr7143217lbz.33.1439918577484; Tue, 18 Aug 2015 10:22:57 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Tue, 18 Aug 2015 10:22:57 -0700 (PDT) In-Reply-To: <55D36473.90609@cisco.com> References: <52B35D5C-E9F9-48B7-8B80-9416ABB18642@nic.cz> <55D36473.90609@cisco.com> Date: Tue, 18 Aug 2015 10:22:57 -0700 Message-ID: From: Andy Bierman To: Robert Wilton Content-Type: multipart/alternative; boundary=001a1134946c51253f051d992b73 Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Y34 - root node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 17:23:05 -0000 --001a1134946c51253f051d992b73 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Aug 18, 2015 at 9:59 AM, Robert Wilton wrote: > > > On 11/08/2015 08:38, Ladislav Lhotka wrote: > >> On 10 Aug 2015, at 22:15, Andy Bierman wrote: >>> >>> >>> >>> On Mon, Aug 10, 2015 at 12:34 PM, Acee Lindem (acee) >>> wrote: >>> I think there is agreement that there is a problem. The YANG Routing >>> Design Team is addressing this with >>> https://www.ietf.org/id/draft-rtgyangdt-rtgwg-device-model-00.txt >>> (which has evolved from >>> https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt)= . >>> In essence, a place for everything and everything in its place. However= , >>> there are those who feel that can=E2=80=99t mandate a single model stru= cture for >>> network devices and we need mechanisms to manage multiple models but al= low >>> for different device structure (e.g., >>> https://www.ietf.org/id/draft-bierman-netmod-yang-package-00.txt). I >>> hope we can agree on an approach in the coming interim meetings. >>> >>> >>> Do you expect "everything in its place" to apply to all other SDOs and >>> all vendor modules? Or do you expect just the IETF routing modules >>> to follow this subtree hierarchy? If the former, does this mean the >>> YANG Routing Design Team is the "YANG data placement authority" >>> or all YANG modules that ever get written? How long should >>> it take for all other SDOs and vendors to redo all their existing >>> modules to re-root them in their assigned place in the data tree? >>> >>> IMO is is not a good idea to rely on rigid data node placement, >>> and a single data placement authority. It is better and use meta-data >>> built from the YANG modules (or YANG packages) instead. >>> >> I think that having fixed paths may end up being too restrictive. > This is how languages like SMIv2 and YANG work. A conceptual object is given a permanent "home" within the tree of object identifiers. Moving data is very expensive, since any clients working with the old data will break as soon as the data is moved. I am not convinced the IETF can or should come up with a set of containers that covers every possible topic that can be modeled in YANG. Even if such a lake could be brought to a boil, I have no confidence that the hierarchy will be 100% stable. It can certainly never be 100% complete. If the IETF thinks it's a good idea to obsolete all YANG RFCs and start over now, who is to say the IETF won't do that again every few years? > >>> The reason Linux uses packages to install/update functionality >>> is because managing 8000 packages is hard enough. >>> Managing 247,000 individual files would be insane. >>> The actual location of files is quite configurable and different >>> across distros. We could learn something from the last decade >>> of Linux package management, and try to apply it to YANG. >>> >>> That=E2=80=99s an interesting idea, could a YANG package also specify, = e.g. that >> the root node for the package is X/Y/Z? This could solve some use cases = for >> relocatability, and it would also be relatively easy to modify all absol= ute >> XPath expressions inside the package. >> > If someone wants to builds a YANG controller node that is managing the > configuration for a network of devices then wouldn't they want a particul= ar > device's interface configuration to be located somewhere like > /network/device//interfaces/interface? Ideally, they would b= e > able to use the same YANG definitions that are defined for /interfaces/ b= ut > root them relative to /network/device//. > > Yes -- some of us (like Martin) have pointed this out many times. The "device" container on an NE does not help at all wrt/ aggregation on a controller. "/device" or "/" work the same for this purpose. Having YANG packages being able to control the relative paths of the > imported YANG modules would possibly allow for more flexibility in how YA= NG > modules fit together, and also give a more pragmatic way for how these > could be changed/upgraded in future if necessary. > > YANG packages provide a way to describe a set of modules. They do not change the top-level data nodes of any objects. This would be very complicated and not really worth it. IMO the "tree of NP containers" should be a resource directory, meaning it contains links to the real resources. Kind of like an index in a library. They don't keep the contents of every book in the index. They keep the location of every book in the index. The index is stable. The resource location does not have to be stable. > Cheers, > Rob > Andy > > > >> Lada >> >> >>> >>> >>> >>> Thanks, >>> Acee >>> >>> >>> Andy >>> >>> >>> >>> From: netmod on behalf of "Einar >>> Nilsen-Nygaard (einarnn)" >>> Date: Monday, August 10, 2015 at 5:29 AM >>> To: Jonathan Hansford >>> Cc: NETMOD Working Group >>> Subject: Re: [netmod] Y34 - root node >>> >>> As someone sharing responsibilities for guiding a number of development >>> teams both defining new models and implementing to some already defined >>> models in this area, I can only agree with this addition to what I said >>> earlier. >>> >>> Cheers, >>> >>> Einar >>> >>> On Aug 10, 2015, at 9:46 AM, Jonathan Hansford >>>> wrote: >>>> >>>> And it is not just end users who need help to better understand YANG >>>> models and how to use them. For those still on the edge, looking to fi= nally >>>> take the plunge and use NETCONF/YANG to configure their devices, help = is >>>> also required to determine how best to structure their YANG models, ma= ke >>>> use of the existing ones, etc. For those who have "grown up" with the >>>> developments in NETCONF and YANG, much of this is probably second natu= re. >>>> But coming to it cold (in the sense of compiling/writing a first set o= f >>>> YANG models for a device; I've been following the netconf/netmod WGs f= or 3+ >>>> years), it still feels very much like a dark art! It is not just the >>>> individual modules, it is how to put them together to best manage a de= vice >>>> (let alone a system). >>>> >>>> Jonathan >>>> >>>> >>>> >>>> ----- Original Message ----- >>>> From: >>>> "Einar Nilsen-Nygaard (einarnn)" >>>> >>>> To: >>>> "Andy Bierman" >>>> Cc: >>>> "NETMOD Working Group" >>>> Sent: >>>> Sat, 8 Aug 2015 11:10:15 +0000 >>>> Subject: >>>> Re: [netmod] Y34 - root node >>>> >>>> >>>> Andy, >>>> >>>> I agree that there is a need for organization of models, but I don=E2= =80=99t >>>> have a firm position on >>>> draft-openconfig-netmod-model-structure/draft-rtgyangdt-rtgwg-device-m= odel >>>> or draft-bierman-netmod-yang-package. But we absolutely need *somethin= g* to >>>> help end-users of the models comprehend the overall structure of model= s, >>>> their relationship and how to use them. >>>> >>>> Cheers, >>>> >>>> Einar >>>> >>>> On Aug 4, 2015, at 5:16 PM, Andy Bierman wrote: >>>> >>>> >>>> >>>> On Tue, Aug 4, 2015 at 2:34 AM, t.petch wrote: >>>> ----- Original Message ----- >>>> From: "Andy Bierman" >>>> To: "t.petch" >>>> Sent: Monday, August 03, 2015 5:17 PM >>>> >>>> ----- Original Message ----- >>>>> From: "Andy Bierman" >>>>> To: "t.petch" >>>>> Sent: Monday, August 03, 2015 4:10 PM >>>>> >>>>> ----- Original Message ----- >>>>>> From: "Andy Bierman" andy@yumaworks.com >>>>>> Sent: Saturday, August 01, 2015 7:05 PM >>>>>> On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem (acee) >>>>>> >>>>>> On 8/1/15, 2:51 AM, j.schoenwaelder@jacobs-university.de> wrote: >>>>>>> >>>>>>> Section 1.1 in >>>>>>> >>>>>>> >>>>> https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.tx= t >>>>> >>>>>> lists the goals of a generic model structure that will accommodate >>>>>>> >>>>>> most >>>>>> >>>>>>> modern network devices. I guess you don=E2=80=99t agree that these = are >>>>>>> >>>>>> desirable? >>>>>> >>>>>> The only objection I have to this draft is the insertion of a >>>>>> >>>>> top-level >>>> >>>>> root >>>>>> called "device". (Might as well be called "self"). >>>>>> There are no sibling nodes planned or intended for >>>>>> this node, so it serves as an extra document root. >>>>>> >>>>>> >>>>>> One aspect of YANG I have never grasped is what a root means, if >>>>>> anything. >>>>>> >>>>>> I understand that it is needed for NETCONF (filters) and for YANG >>>>>> (augments, constraints) and so must be somewhere and must be >>>>>> >>>>> relatively >>>>> >>>>>> stable, but has it any other significance in the data model? >>>>>> >>>>>> As you may recall, I was involved with SMI first, where the root is >>>>>> somewhere up in the sky and life only becomes interesting some six >>>>>> levels down the hierarchy and that may colour my thinking. >>>>>> >>>>>> YANG does a poor job of defining the root for YANG data nodes. >>>>> It is sometimes called a datastore (in the abstract). >>>>> Technically, YANG borrows the definition from XPath. >>>>> YANG just defines top-level data nodes and the parent of >>>>> these nodes is the document root >>>>> >>>>> There is no protocol or encoding neutral definition, >>>>> only an XML-specific definition. >>>>> >>>>> >>>>> >>>>> Thanks for that. >>>>> >>>>> It seems to me that much of the extensive discussion on Y34 (all of >>>>> which I have read) is as much political as technical, that is SMI is >>>>> hierarchical, top down, perhaps befitting its origins in ISO, whereas >>>>> YANG is bottom up. IETF-like. YANG could have had a single tree, but >>>>> doesn't. So when I read >>>>> >>>>> https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.tx= t >>>>> >>>>> I see a plea for a more hierarchical organisation, and when I read >>>>> >>>>> draft-bjorklund-netmod-openconfig-reply-00 >>>>> >>>>> I see a response that says we are not like that. >>>>> >>>>> If so, I doubt that there ever will be a technical solution. >>>>> >>>>> And I am mindful that when I configure routing in a (Cisco) router, I >>>>> have to do some of it under the interface definitions and some of it >>>>> under the definition of the routing protocol. Which is life, never >>>>> wholy interface-centric and never wholy routing protocol-centric! >>>>> >>>> Are you saying the job would be easier if the >>>> path was /device/interfaces/interface instead >>>> of just /interfaces/interface? Are you saying >>>> that /protocols/routing could not also be defined? >>>> Clearly edit-config and copy-config allow both >>>> subtrees to be accessed in the same operation, >>>> so I don't understand your concern. >>>> >>>> I have been trying to get the root node to be better defined >>>> in the protocols that use YANG (i.e., ncx:root, Y34-04). >>>> IMO this is a better approach than defining a YANG module >>>> with a special container that all other modules are expected >>>> to augment. YANG is designed such that each vendor or SDO >>>> is not dependent on other vendors or SDOs in order to >>>> define data nodes. >>>> >>>> >>>> >>>> Andy >>>> >>>> I am agreeing with you that adding 'device' brings no technical benefi= t, >>>> rather that the motivation is the opposite of technical (which I >>>> referred to as political). I am also agreeing with the current declare= d >>>> consensus on Y34. >>>> >>>> And yes, YANG is going to give us a large number of modules, some >>>> tightly coupled (augments) some loosely so (how many do you need to >>>> configure OSPF?) and work in this area will be of benefit now and >>>> probably essential in a few years time. That said, I am unsure what >>>> such work would be like; I am looking (in despair) at 50 routing area >>>> YANG models and wondering how a user will ever get a coherent picture = of >>>> how to do what they want to do. >>>> >>>> >>>> >>>> The "YANG Land Grab" gives a false sense of progress. >>>> Reaching WG consensus on every single leaf is hard work. >>>> >>>> I don't think a collection of 100s of YANG modules is ever >>>> going to to be easy to understand. Operators will not examine >>>> a NETCONF message, look at 150 module URIs, >>>> and say "I know exactly what this device supports". >>>> I guess it is up to client tools to do that >>>> >>>> I wrote a draft that defines YANG Packages, which can provide >>>> a higher level of organization for YANG modules. >>>> >>>> http://datatracker.ietf.org/doc/draft-bierman-netmod-yang-package/ >>>> >>>> You and I are apparently in the minority, since the official status >>>> is that there is no problem with the current approach, and no need >>>> to organize individual YANG modules into any larger abstractions. >>>> >>>> >>>> >>>> Tom Petch >>>> >>>> >>>> >>>> Andy >>>> Andy >>>> >>>> Andy >>>>> >>>>> The well-specified XPath and YANG root (/) can be >>>>>> accessed by all protocol operations, exactly the same >>>>>> as a node called 'device'. The actual node name will >>>>>> depend on the RPC function (e.g. 'data' or 'config'). >>>>>> >>>>>> This is more than redundant however. It introduces a "super-module" >>>>>> into YANG that every other module is expected to augment. >>>>>> YANG is intended to be more loosely coupled than that. >>>>>> This introduces an extra node and namespace declaration >>>>>> in all protocol messages, increasing message sizes. >>>>>> >>>>>> It also assumes all existing YANG models will get rewritten to >>>>>> account for "/device" in all path and XPath expressions. >>>>>> This is highly disruptive to existing deployments. >>>>>> Also, multiple data models to edit the same thing causes lots >>>>>> of extra complexity in the server (supporting both old >>>>>> location and new location). >>>>>> >>>>>> IMO a resource directory approach is much more realistic. >>>>>> The /device tree can contain all the organized NP containers. >>>>>> Instead of all the actual data nodes, this tree just has pointers >>>>>> to the real location of the resource. (like 301 Moved Permanently) >>>>>> >>>>>> Acee >>>>>>> >>>>>>> Andy >>>>>> >>>>> >>>> ** Solution Y34-02 >>>> >>>> Keep 'anyxml'. Introduce 'anydata' as above but without the >>>> 'format' substatement. >>>> >>>> 'anyxml' would still be used to represent unrestricted XML, as is >>>> done in NETCONF. >>>> >>>> 'anydata' would be an unknown chunk of data that can be modelled >>>> with YANG. Can be encoded as xml or json. >>>> >>>> For example: >>>> >>>> #+BEGIN_EXAMPLE >>>> anydata data; >>>> #+END_EXAMPLE >>>> >>>> ** Solution Y34-05 >>>> >>>> Same as Y34-02 plus two guidelines adopted from Y34-04: >>>> >>>> - Keep 'anyxml' unchanged as it is defined in YANG 1.0. This >>>> ensures backward compatibility. >>>> - Introduce a new 'anydata' statement that represents an unknown >>>> chunk of data that can be modeled with YANG >>>> - Document that implementations MAY have restrictions for anyxml a= nd >>>> that anyxml is not necessarily interoperable; data model writers >>>> should use anydata whenever possible. >>>> - The guidelines document should say that YANG Doctors will review >>>> each use of anyxml in IETF modules when YANG 1.1 is adopted to >>>> avoid its use whenever possible. >>>> >>>> >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>> >>>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > > --001a1134946c51253f051d992b73 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Aug 18, 2015 at 9:59 AM, Robert Wilton <rwilton@cisco.com&= gt; wrote:


On 11/08/2015 08:38, Ladislav Lhotka wrote:
On 10 Aug 2015, at 22:15, Andy Bierman <andy@yumaworks.com> wrote:



On Mon, Aug 10, 2015 at 12:34 PM, Acee Lindem (acee) <acee@cisco.com> wrote:
I think there is agreement that there is a problem. The YANG Routing Design= Team is=C2=A0 addressing this with https://www.ietf.org/id/draft-rtgyangdt-rtgwg-device-model-00.txt=C2= =A0 (which has evolved from ht= tps://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt). = In essence, a place for everything and everything in its place. However, th= ere are those who feel that can=E2=80=99t mandate a single model structure = for network devices and we need mechanisms to manage multiple models but al= low for different device structure (e.g., https://www.ietf.org/id/draft-bierman-netmod-yang-package-00.txt)= .=C2=A0 I hope we can agree on an approach in the coming interim meetings.<= br>

Do you expect "everything in its place" to apply to all other SDO= s and
all vendor modules? Or do you expect just the IETF routing modules
to follow this subtree hierarchy? If the former, does this mean the
YANG Routing Design Team is the "YANG data placement authority" or all YANG modules that ever get written? How long should
it take for all other SDOs and vendors to redo all their existing
modules to re-root them in their assigned place in the data tree?

IMO is is not a good idea to rely on rigid data node placement,
and a single data placement authority. It is better and use meta-data
built from the YANG modules (or YANG packages) instead.
I think that having fixed paths may end up being too restrictive.


This is how languages like SMIv2 = and YANG work.
A conceptual object is given a permanent "hom= e" within the tree of object identifiers.
Moving data is ver= y expensive, since any clients working with the old data
will bre= ak as soon as the data is moved.

=C2=A0I am not co= nvinced the IETF can or should come up with a set of containers
t= hat covers every possible topic that can be modeled in YANG.
Even= if such a lake could be brought to a boil, I have no confidence
= that the hierarchy will be 100% stable.=C2=A0 It can certainly
ne= ver be 100% complete.=C2=A0 If the IETF thinks it's a good idea
to obsolete all YANG RFCs and start over now, who is to say
th= e IETF won't do that again every few years?




The reason Linux uses packages to install/update functionality
is because managing 8000 packages is hard enough.
Managing 247,000 individual files would be insane.
The actual location of files is quite configurable and different
across distros. We could learn something from the last decade
of Linux package management, and try to apply it to YANG.

That=E2=80=99s an interesting idea, could a YANG package also specify, e.g.= that the root node for the package is X/Y/Z? This could solve some use cas= es for relocatability, and it would also be relatively easy to modify all a= bsolute XPath expressions inside the package.
If someone wants to builds a YANG controller node that is managing the conf= iguration for a network of devices then wouldn't they want a particular= device's interface configuration to be located somewhere like /network= /device/<device-name>/interfaces/interface? Ideally, they would be ab= le to use the same YANG definitions that are defined for /interfaces/ but r= oot them relative to /network/device/<device-name>/.



Yes -- some of us (like= Martin) have pointed this out many times.
The "device"= container on an NE does not help at all wrt/
aggregation on a co= ntroller. "/device" or "/" work the same for this purpo= se.


Having YANG packages being able to control the relative paths of the import= ed YANG modules would possibly allow for more flexibility in how YANG modul= es fit together, and also give a more pragmatic way for how these could be = changed/upgraded in future if necessary.



YANG packages provide a= way to describe a set of modules.
They do not change the top-lev= el data nodes of any objects.
This would be very complicated and = not really worth it.


IMO the "= tree of NP containers" should be a resource directory,
meani= ng it contains links to the real resources.=C2=A0 Kind of like an
index in a library.=C2=A0 They don't keep the contents of every book i= n the index.
They keep the location of every book in the index.= =C2=A0 The index is stable.
The resource location does not have t= o be stable.


=C2=A0
Cheers,
Rob

Andy
=C2=A0



Lada





Thanks,
Acee


Andy
=C2=A0


From: netmod <netmod-bounces@ietf.org> on behalf of "Einar Nilsen-Nygaard = (einarnn)" <= einarnn@cisco.com>
Date: Monday, August 10, 2015 at 5:29 AM
To: Jonathan Hansford <jonathan@hansfords.net>
Cc: NETMOD Working Group <netmod@ietf.org>
Subject: Re: [netmod] Y34 - root node

As someone sharing responsibilities for guiding a number of development tea= ms both defining new models and implementing to some already defined models= in this area, I can only agree with this addition to what I said earlier.<= br>
Cheers,

Einar

On Aug 10, 2015, at 9:46 AM, Jonathan Hansford <jonathan@hansfords.net> wrote:
=C2=A0 And it is not just end users who need help to better understand YANG= models and how to use them. For those still on the edge, looking to finall= y take the plunge and use NETCONF/YANG to configure their devices, help is = also required to determine how best to structure their YANG models, make us= e of the existing ones, etc. For those who have "grown up" with t= he developments in NETCONF and YANG, much of this is probably second nature= . But coming to it cold (in the sense of compiling/writing a first set of Y= ANG models for a device; I've been following the netconf/netmod WGs for= 3+ years), it still feels very much like a dark art! It is not just the in= dividual modules, it is how to put them together to best manage a device (l= et alone a system).

Jonathan



----- Original Message -----
From:
"Einar Nilsen-Nygaard (einarnn)" <einarnn@cisco.com>

To:
"Andy Bierman" <andy@yumaworks.com>
Cc:
"NETMOD Working Group" <netmod@ietf.org>
Sent:
Sat, 8 Aug 2015 11:10:15 +0000
Subject:
Re: [netmod] Y34 - root node


Andy,

I agree that there is a need for organization of models, but I don=E2=80=99= t have a firm position on draft-openconfig-netmod-model-structure/draft-rtg= yangdt-rtgwg-device-model or draft-bierman-netmod-yang-package. But we abso= lutely need *something* to help end-users of the models comprehend the over= all structure of models, their relationship and how to use them.

Cheers,

Einar

On Aug 4, 2015, at 5:16 PM, Andy Bierman <andy@yumaworks.com> wrote:



On Tue, Aug 4, 2015 at 2:34 AM, t.petch <ietfc@btconnect.com> wrote:
----- Original Message -----
From: "Andy Bierman" <andy@yumaworks.com>
To: "t.petch" <ietfc@btconnect.com>
Sent: Monday, August 03, 2015 5:17 PM

----- Original Message -----
From: "Andy Bierman" <andy@yumaworkscom>
To: "t.petch" <ietfc@btconnect.com>
Sent: Monday, August 03, 2015 4:10 PM

----- Original Message -----
From: "Andy Bierman" andy@yumaworks.com
Sent: Saturday, August 01, 2015 7:05 PM
On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem (acee) <acee@cisco.com>

On 8/1/15, 2:51 AM,=C2=A0 j.schoenwaelder@jacobs-university.de> wrote= :

Section 1.1 in

https://www.ietf.org/id/draft-= openconfig-netmod-model-structure-00.txt
lists the goals of a generic model structure that will accommodate
most
modern network devices. I guess you don=E2=80=99t agree that these are
desirable?

The only objection I have to this draft is the insertion of a
top-level
root
called "device".=C2=A0 (Might as well be called "self")= .
There are no sibling nodes planned or intended for
this node, so it serves as an extra document root.

<tp>
One aspect of YANG I have never grasped is what a root means, if
anything.

I understand that it is needed for NETCONF (filters) and for YANG
(augments, constraints) and so must be somewhere and must be
relatively
stable, but has it any other significance in the data model?

As you may recall, I was involved with SMI first, where the root is
somewhere up in the sky and life only becomes interesting some six
levels down the hierarchy and that may colour my thinking.

YANG does a poor job of defining the root for YANG data nodes.
It is sometimes called a datastore (in the abstract).
Technically, YANG borrows the definition from XPath.
YANG just defines top-level data nodes and the parent of
these nodes is the document root

There is no protocol or encoding neutral definition,
only an XML-specific definition.

<tp>

Thanks for that.

It seems to me that much of the extensive discussion on Y34 (all of
which I have read) is as much political as technical, that is SMI is
hierarchical, top down, perhaps befitting its origins in ISO, whereas
YANG is bottom up. IETF-like.=C2=A0 YANG could have had a single tree, but<= br> doesn't.=C2=A0 So when I read

https://www.ietf.org/id/draft-= openconfig-netmod-model-structure-00.txt

I see a plea for a more hierarchical organisation, and when I read

draft-bjorklund-netmod-openconfig-reply-00

I see a response that says we are not like that.

If so, I doubt that there ever will be a technical solution.

And I am mindful that when I configure routing in a (Cisco) router, I
have to do some of it under the interface definitions and some of it
under the definition of the routing protocol.=C2=A0 Which is life, never wholy interface-centric and never wholy routing protocol-centric!
Are you saying the job would be easier if the
path was /device/interfaces/interface instead
of just /interfaces/interface?=C2=A0 Are you saying
that /protocols/routing could not also be defined?
Clearly edit-config and copy-config allow both
subtrees to be accessed in the same operation,
so I don't understand your concern.

I have been trying to get the root node to be better defined
in the protocols that use YANG (i.e., ncx:root, Y34-04).
IMO this is a better approach than defining a YANG module
with a special container that all other modules are expected
to augment.=C2=A0 YANG is designed such that each vendor or SDO
is not dependent on other vendors or SDOs in order to
define data nodes.

<tp>

Andy

I am agreeing with you that adding 'device' brings no technical ben= efit,
rather that the motivation is the opposite of technical (which I
referred to as political). I am also agreeing with the current declared
consensus on Y34.

And yes, YANG is going to give us a large number of modules, some
tightly coupled (augments) some loosely so (how many do you need to
configure OSPF?) and work in this area will be of benefit now and
probably essential in a few years time.=C2=A0 That said, I am unsure what such work would be like; I am looking (in despair) at 50 routing area
YANG models and wondering how a user will ever get a coherent picture of how to do what they want to do.



The "YANG Land Grab" gives a false sense of progress.
Reaching WG consensus on every single leaf is hard work.

I don't think a collection of 100s of YANG modules is ever
going to to be easy to understand.=C2=A0 Operators will not examine
a NETCONF <hello> message, look at 150 module URIs,
and say "I know exactly what this device supports".
I guess it is up to client tools to do that

I wrote a draft that defines YANG Packages, which can provide
a higher level of organization for YANG modules.

http://datatracker.ietf.org/doc/dr= aft-bierman-netmod-yang-package/

You and I are apparently in the minority, since the official status
is that there is no problem with the current approach, and no need
to organize individual YANG modules into any larger abstractions.



=C2=A0 Tom Petch



Andy
=C2=A0 Andy

Andy

The well-specified XPath and YANG root (/) can be
accessed by all protocol operations, exactly the same
as a node called 'device'.=C2=A0 The actual node name will
depend on the RPC function (e.g. 'data' or 'config').

This is more than redundant however.=C2=A0 It introduces a "super-modu= le"
into YANG that every other module is expected to augment.
YANG is intended to be more loosely coupled than that.
This introduces an extra node and namespace declaration
in all protocol messages, increasing message sizes.

It also assumes all existing YANG models will get rewritten to
account for "/device" in all path and XPath expressions.
This is highly disruptive to existing deployments.
Also, multiple data models to edit the same thing causes lots
of extra complexity in the server (supporting both old
location and new location).

IMO a resource directory approach is much more realistic.
The /device tree can contain all the organized NP containers.
Instead of all the actual data nodes, this tree just has pointers
to the real location of the resource. (like 301 Moved Permanently)

Acee

Andy

** Solution Y34-02

=C2=A0 =C2=A0Keep 'anyxml'.=C2=A0 Introduce 'anydata' as ab= ove but without the
=C2=A0 =C2=A0'format' substatement.

=C2=A0 =C2=A0'anyxml' would still be used to represent unrestricted= XML, as is
=C2=A0 =C2=A0done in NETCONF.

=C2=A0 =C2=A0'anydata' would be an unknown chunk of data that can b= e modelled
=C2=A0 =C2=A0with YANG.=C2=A0 Can be encoded as xml or json.

=C2=A0 =C2=A0For example:

=C2=A0 =C2=A0 =C2=A0#+BEGIN_EXAMPLE
=C2=A0 =C2=A0 =C2=A0anydata data;
=C2=A0 =C2=A0 =C2=A0#+END_EXAMPLE

** Solution Y34-05

=C2=A0 =C2=A0 Same as Y34-02 plus two guidelines adopted from Y34-04:

=C2=A0 =C2=A0 - Keep 'anyxml' unchanged as it is defined in YANG 1.= 0. This
=C2=A0 =C2=A0 =C2=A0 ensures backward compatibility.
=C2=A0 =C2=A0 - Introduce a new 'anydata' statement that represents= an unknown
=C2=A0 =C2=A0 =C2=A0 chunk of data that can be modeled with YANG
=C2=A0 =C2=A0 - Document that implementations MAY have restrictions for any= xml and
=C2=A0 =C2=A0 =C2=A0 that anyxml is not necessarily interoperable; data mod= el writers
=C2=A0 =C2=A0 =C2=A0 should use anydata whenever possible.
=C2=A0 =C2=A0 - The guidelines document should say that YANG Doctors will r= eview
=C2=A0 =C2=A0 =C2=A0 each use of anyxml in IETF modules when YANG 1.1 is ad= opted to
=C2=A0 =C2=A0 =C2=A0 avoid its use whenever possible.



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


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


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




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


--001a1134946c51253f051d992b73-- From nobody Tue Aug 18 13:26:57 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 152461A88B2 for ; Tue, 18 Aug 2015 13:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XT0VHGIyUh-d for ; Tue, 18 Aug 2015 13:26:54 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id B5A051A0158 for ; Tue, 18 Aug 2015 13:26:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=YykD4juz0gB6lO9pmfBsN8YoXF/viDmIyLP81rpIjnWRztGJUbXN1VpZXLilxWN2; 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.35] (helo=elwamui-huard.atl.sa.earthlink.net) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1ZRnT2-0002Zq-14 for netmod@ietf.org; Tue, 18 Aug 2015 16:26:44 -0400 Received: from 76.254.52.208 by webmail.earthlink.net with HTTP; Tue, 18 Aug 2015 16:26:42 -0400 Message-ID: <19754732.1439929603429.JavaMail.root@elwamui-huard.atl.sa.earthlink.net> Date: Tue, 18 Aug 2015 13:26:42 -0700 (GMT-07:00) From: Randy Presuhn To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888ff8848a73c44bba085b2c18c9b87e5e2c24916eb2e696c57350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.35 Archived-At: Subject: Re: [netmod] Y34 - root node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 20:26:56 -0000 Hi - > From: Andy Bierman > Sent: Aug 18, 2015 10:22 AM > To: Robert Wilton > Cc: NETMOD Working Group > Subject: Re: [netmod] Y34 - root node > > On Tue, Aug 18, 2015 at 9:59 AM, Robert Wilton wrote: ... > > I think that having fixed paths may end up being too restrictive. > > This is how languages like SMIv2 and YANG work. A conceptual object > is given a permanent "home" within the tree of object identifiers. But it's *not*, for example, how GDMO works. The CMIP world maintains clear distinctions between the (organizational) hierarchy of object identifiers, the conceptual hierarchies of inheritance and class composition, and the containment hierarchy of object instances. There the "NAME BINDING" template provides the means of describing places where instances of a given class may come home to roost. Randy From nobody Tue Aug 18 17:01:30 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 593621A00AE for ; Tue, 18 Aug 2015 17:01:28 -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 t5SlExTN-766 for ; Tue, 18 Aug 2015 17:01:26 -0700 (PDT) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) (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 D828C1A00F0 for ; Tue, 18 Aug 2015 17:01:24 -0700 (PDT) Received: by lbbtg9 with SMTP id tg9so114095164lbb.1 for ; Tue, 18 Aug 2015 17:01:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=Lb+yes1/Vqwid5X9bPnGS7TgS8x1jyisl7x90nTbLOU=; b=LXpd3/uV1ZspeME1V6N/xDJ/fEb7eh8kQ8nMPfcUSaFqVpqUFDCWnUGupc/c3xBEE3 kAlhAS5r8qWtcc1zm6GofZdOfXJNwyYzivk0f/jg/capV10PEnSqmHFcAMehe0sZn7cI 4u4D6FXlrTcu4MMlSaAY7o1LWmWoQdazGJ9LLnJwGSKUjqb3y0oXWitz9ok3UFMQFBG9 SoetvcYdZGPfdLrWnFNwi/1zcclolR0et2mpdAZuuxds+k8OCufAs9yN2fN7Ads7AJ89 k3rctRQ/zM4VIFeAZLcgtG4TrOnuxGgDs9JyRRT7RT1OC1s1vW67NqHbbl1vh1DHfubU np5A== X-Gm-Message-State: ALoCoQn9fr1BrkQxtAWRKpzwvRiqfxDsjhKapVGYDJ40bOvWEOMyukcKPj3XWZcI4Aln+bH8F7G7 MIME-Version: 1.0 X-Received: by 10.112.170.2 with SMTP id ai2mr8640977lbc.82.1439942483369; Tue, 18 Aug 2015 17:01:23 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Tue, 18 Aug 2015 17:01:23 -0700 (PDT) Date: Tue, 18 Aug 2015 17:01:23 -0700 Message-ID: From: Andy Bierman To: "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11c33e1837f9f7051d9ebca0 Archived-At: Subject: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 00:01:28 -0000 --001a11c33e1837f9f7051d9ebca0 Content-Type: text/plain; charset=UTF-8 Hi, I assume this draft is what we should be reviewing and not the obsolete openconfig draft? https://tools.ietf.org/html/draft-rtgyangdt-rtgwg-device-model-00 Q1) scope sec 2: The model organization can itself be thought of as a "meta-model", in that it describes the relationships between individual models. We choose to represent it also as simple YANG model consisting of lists and containers to serve as anchor points for the corresponding individual models. As shown below, our model is rooted at a "device", which represents a network router, switch, or similar network element. Why is this a meta-model? It looks like a real YANG data model where ad-hoc classification is being done using container names. If vendors augment this tree with their own ad-hoc hierarchy, then how is this any better than what we have now? What is the scope of this work? It appears to be only for "routers switches or similar network elements". The hierarchy seems quite router-centric. Is the expectation that all YANG-based devices will use this data hierarchy, or only some devices? Is the expectation that all YANG modules will use this data hierarchy, or only some modules? Is it just for IETF routing modules or more than that? Q2) interfaces The interface model is taken from [RFC7223 ] and includes possible technology-specific augmentations using example technologies defined in [RFC7277 ]. +--rw interfaces | +--rw interface* [name] | +--rw name string | +--rw bind-network-element-id? uint8 | +--rw ethernet | | +--rw bind-networking-instance-name? string | | +--rw aggregates | | +--rw rstp | | +--rw lldp | | +--rw ptp | +--rw vlans | +--rw tunnels | +--rw ipv4 | | +--rw bind-networking-instance-name? string | | +--rw arp | | +--rw icmp | | +--rw vrrp | | +--rw dhcp-client | +--rw ipv6 | +--rw bind-networking-instance-name? string | +--rw vrrp | +--rw icmpv6 | +--rw nd | +--rw dhcpv6-client Actually the interface model is quite different than the one in RFC 7223. Seems rather ethernet-centric. I notice the "type" leaf was removed, along with everything else. Is the plan to toss out RFC 7223, recharter the interfaces work, and start over? Q3) virtual devices The model supports the potentially independent system management functions and configuration per logical network element. This permits, for example, different users to manage either the whole device or just the associated logical network element. Sec 2.2.1 shows the system management tree but it is wrong. The following tree is what the YANG model defines: +--rw device +--rw logical-network-elements -rw logical-network-element* [network-element-id] +--rw network-element-id uint8 +--rw network-element-name? string +--rw default-networking-instance-name? string +--rw system-management | +--rw device-view? boolean | +--rw syslog | +--rw dns | +--rw ntp | +--rw statistics-collection | +--rw ssh | +--rw tacacs | +--rw snmp | +--rw netconf What about devices that do not have logical network elements? This hierarchy may be appropriate for very large routers but nothing else. How can this tree represent both the physical view and the virtual view? It seems to assume this is the "root user physical view". Please explain how device-type=VIRTUAL is used. Andy --001a11c33e1837f9f7051d9ebca0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I assume this draft is what we shou= ld be reviewing and not
the obsolete openconfig draft?
=



Q1) scope=


sec 2:

The model organization can itself be = thought of as a "meta-model", in that it describes the relationships between individual models. We choose to represent it also as simple YANG model consisting of lists and containers to serve as anchor points for the corresponding individual models. As shown below, our model is rooted at a "device", which repre= sents a network router, switch, or similar network element.

Why is this a meta-model?
It lo= oks like a real YANG data model where ad-hoc classification is being done
using container names.

If vendors augment= this tree with their own ad-hoc hierarchy, then how is this
any = better than what we have now?

What is the scope of= this work?
It appears to be only for "routers switches or s= imilar network elements".

The hierarchy seems= quite router-centric.
Is the expectation that all YANG-based dev= ices will use this
data hierarchy, or only some devices?

Is the expectation that all YANG modules will use thi= s
data hierarchy, or only some modules?=C2=A0 Is it just
for IETF routing modules or more than that?

Q2) interfaces

   The interface model is taken from [RFC7223] and includes possible
   technology-specific augmentations using example technologies defined
   in [RFC7277].


=C2=A0 +--rw interfaces
=C2=A0 =C2=A0 =C2=A0 | = =C2=A0+--rw interface* [name]
=C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2= =A0 +--rw name =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 string
=C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 +--= rw bind-network-element-id? =C2=A0 uint8
=C2=A0 =C2=A0 =C2=A0 | = =C2=A0 =C2=A0 +--rw ethernet
=C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0= | =C2=A0+--rw bind-networking-instance-name? =C2=A0 string
=C2= =A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 | =C2=A0+--rw aggregates
=C2=A0= =C2=A0 =C2=A0 | =C2=A0 =C2=A0 | =C2=A0+--rw rstp
=C2=A0 =C2=A0 = =C2=A0 | =C2=A0 =C2=A0 | =C2=A0+--rw lldp
=C2=A0 =C2=A0 =C2=A0 | = =C2=A0 =C2=A0 | =C2=A0+--rw ptp
=C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2= =A0 +--rw vlans
=C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 +--rw tunnel= s
=C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 +--rw ipv4
=C2= =A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 | =C2=A0+--rw bind-networking-instance-na= me? =C2=A0 string
=C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 | =C2=A0+-= -rw arp
=C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 | =C2=A0+--rw icmp
=C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 | =C2=A0+--rw vrrp
= =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 | =C2=A0+--rw dhcp-client
= =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 +--rw ipv6
=C2=A0 =C2=A0 =C2= =A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw bind-networking-instance-name? =C2= =A0 string
=C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0+--r= w vrrp
=C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw ic= mpv6
=C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw nd
=C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw dhcpv6-cli= ent


Actually the interface mo= del is quite different than the one in RFC 7223.
Seems rather eth= ernet-centric.=C2=A0 I notice the "type" leaf was removed,
<= div>along with everything else.=C2=A0 Is the plan to toss out RFC 7223,
recharter the interfaces work, and start over?

<= div>Q3) virtual devices

   The model supports the potentially independent system managem=
ent
   functions and configuration per logical network element. This
   permits, for example, different users to manage either the whole
   device or just the associated logical network element.

Sec 2.2= .1 shows the system management tree but it is wrong.
The followin= g tree is what the YANG model defines:

 +--rw device
          +--rw logical-network-elements
               -rw logical-network-element* [n=
etwork-element-id]
                   +--rw network-element-id                  uint8
                   +--rw network-element-name?               string
                   +--rw default-networking-instance-name?   string
                   +--rw system-management
                   |  +--rw=
 device-view?                      boolean

                   |  +--rw sysl=
og
                   |  +--rw dns
                   |  +--rw ntp
                   |  +--rw statistics-collection
                   |  +--rw ssh
                   |  +--rw tacacs
                   |  +--rw snmp
                   |  +--rw netconf



What about devices that do not have logical network =
elements?
This hierarchy may be appropriate for very large routers
but nothing else=
.
H=
ow can this tree represent both the physical view and the virtual view?
It seem=
s to assume this is the "root user physical view".
Please explain how=
 device-type=3DVIRTUAL is used.

=



Andy


--001a11c33e1837f9f7051d9ebca0-- From nobody Tue Aug 18 18:38:27 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BDEB1A884D for ; Tue, 18 Aug 2015 18:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ru5ztUpibRc3 for ; Tue, 18 Aug 2015 18:38:21 -0700 (PDT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id 3793D1A7035 for ; Tue, 18 Aug 2015 18:38:21 -0700 (PDT) Received: (qmail 32659 invoked by uid 0); 19 Aug 2015 01:38:15 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy4.mail.unifiedlayer.com with SMTP; 19 Aug 2015 01:38:15 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id 6Re81r00w2SSUrH01ReByx; Tue, 18 Aug 2015 19:38:13 -0600 X-Authority-Analysis: v=2.1 cv=C6F6l2/+ c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=JAI3OqB5mnwA:10 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=uRRa74qj2VoA:10 a=48vgC7mUAAAA:8 a=JB4iHBKHJljutsUiFqQA:9 a=RjeJcJoEaFiMqAon:21 a=1NirKHmA_5zwkdUC:21 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=rVk7wJKtFOK2EZLard6YjivCIhiH3VRWR/9D92csRvY=; b=U8a02lpLfpg00CmRw9ccSEtfDXd5BkZ8w6hPa1WE9fX31UHT6M2XSVJu2n1FlV9AhBosvdW15B/xesbovL0UyVYC0R4sbW6TURxSyDt4j+uhnGuJFwXUSiIdiDAjJRFT; Received: from box313.bluehost.com ([69.89.31.113]:43639 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZRsKQ-0001Mf-EE; Tue, 18 Aug 2015 19:38:10 -0600 To: Andy Bierman , netmod WG References: From: Lou Berger X-Enigmail-Draft-Status: N1110 Message-ID: <55D3DDFC.2080107@labn.net> Date: Tue, 18 Aug 2015 21:38:04 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: draft-rtgyangdt-rtgwg-device-model@ietf.org, Routing WG Subject: Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 01:38:23 -0000 [Adding authors and RTG WG.] Hi Andy, I'm not sure who you are looking to hear from as you addressed this mail to the netmod list. I'm happy to give my opinion as it seems you might have been aiming this at the draft authors. (but then again perhaps not.) On 8/18/2015 8:01 PM, Andy Bierman wrote: > Hi, > > I assume this draft is what we should be reviewing and not > the obsolete openconfig draft? My personal view / hope is that the openconfig draft will be revised to cover requirements while the DT draft leads to an agreed upon approach to addressing those requirements. Again, just stating my view, not the view of the DT, co-authors or OC draft authors. > > > https://tools.ietf.org/html/draft-rtgyangdt-rtgwg-device-model-00 > > > Q1) scope > > > sec 2: > > The model organization can itself be thought of as a "meta-model", > in that it describes the relationships between individual models. We > choose to represent it also as simple YANG model consisting of lists > and containers to serve as anchor points for the corresponding > individual models. > > As shown below, our model is rooted at a "device", which represents a > network router, switch, or similar network element. > > > Why is this a meta-model? because the aim to to show how other models inter-relate rather than define the details of all models. As stated in the intro: This document aims to provide an extensible structure that can be used to tie together other models. It allows for existing, emerging, and future models. The overall structure can be constructed using YANG augmentation and imports. > It looks like a real YANG data model where ad-hoc classification is > being done > using container names. Sure, we're using YANG, or at least trying, to document our proposal. Do you think there's a better way to formally document the work? > > If vendors augment this tree with their own ad-hoc hierarchy, then how > is this > any better than what we have now? > This goes to requirements which is really in the scope of draft-openconfig-netmod-model-structure. From my perspective it comes down to how much information is needed from an actual device in order to come up with its yang-based configuration, and the principle that there is benefit in this being minimized. For example, consider the case where a config is generated before a specific device is fielded or perhaps even purchased/selected. But again, this more of a requirements discussion. > What is the scope of this work? see slide 7 of https://www.ietf.org/proceedings/93/slides/slides-93-rtgwg-3.pdf > It appears to be only for "routers switches or similar network elements". > >From the slide: From DT charter: An overall architecture for the protocols and functionality contained inside the Routing Area > The hierarchy seems quite router-centric. It is intended to be network device centric, routers, switches, firewalls, etc. > Is the expectation that all YANG-based devices will use this > data hierarchy, or only some devices? The proposal is to provide a framework for any device that supports a protocol or other mechanism defined within the routing area. (Or at least that's our understanding of what we were asked to do.) > > Is the expectation that all YANG modules will use this > data hierarchy, or only some modules? I personally think there will be siblings to /device, e.g., /service - but this is beyond the scope of this draft. > Is it just > for IETF routing modules or more than that? > I think this is the same question and answer as above. > Q2) interfaces > > The interface model is taken from [RFC7223 ] and includes possible > technology-specific augmentations using example technologies defined > in [RFC7277 ]. > +--rw interfaces > | +--rw interface* [name] > | +--rw name string > | +--rw bind-network-element-id? uint8 > | +--rw ethernet > | | +--rw bind-networking-instance-name? string > | | +--rw aggregates > | | +--rw rstp > | | +--rw lldp > | | +--rw ptp > | +--rw vlans > | +--rw tunnels > | +--rw ipv4 > | | +--rw bind-networking-instance-name? string > | | +--rw arp > | | +--rw icmp > | | +--rw vrrp > | | +--rw dhcp-client > | +--rw ipv6 > | +--rw bind-networking-instance-name? string > | +--rw vrrp > | +--rw icmpv6 > | +--rw nd > | +--rw dhcpv6-client > > > Actually the interface model is quite different than the one in RFC 7223. > Seems rather ethernet-centric. I notice the "type" leaf was removed, > along with everything else. Is the plan to toss out RFC 7223, > recharter the interfaces work, and start over? > So this may be our/my inexperience at play here. I didn't think it appropriate for a document that is augmenting an existing model to redefine the current model - I actually thought this was part of the power of YANG augmentation. Are you saying we should have included the whole 7223 model to augment it, or something different? Also not the text says: ... possible technology-specific augmentations using example technologies .. and The interfaces container includes a number of commonly used components as examples: > Q3) virtual devices > > The model supports the potentially independent system management > functions and configuration per logical network element. This > permits, for example, different users to manage either the whole > device or just the associated logical network element. > > Sec 2.2.1 shows the system management tree but it is wrong. Yes, good catch of a cut-and-past bug. thankfully it is correct both immediately before in the section intro and the details > The following tree is what the YANG model defines: > +--rw device > +--rw logical-network-elements > -rw logical-network-element* [network-element-id] > +--rw network-element-id uint8 > +--rw network-element-name? string > +--rw default-networking-instance-name? string > +--rw system-management > | +--rw device-view? boolean > | +--rw syslog > | +--rw dns > | +--rw ntp > | +--rw statistics-collection > | +--rw ssh > | +--rw tacacs > | +--rw snmp > | +--rw netconf > What about devices that do not have logical network elements? It would have only a single network-element-id > This hierarchy may be appropriate for very large routers > but nothing else. The intent is to cover all implementations independent of vendors. We had a good range of view points both in the DT and in the RTGWG discussion. Not saying there was full agreement, just that we have a proposed starting point. > How can this tree represent both the physical view and the virtual view? Are you referring to section 2.3? If so, I think we all agree (and said as much in Prague) that this section could be clearer. We/I tried to explain it in the Prague slide 25 (for this you may want to see the animation in https://www.ietf.org/proceedings/93/slides/slides-93-rtgwg-3.pptx) Basically the amount of information provided depends on the logical-network-element context used to access this information. So if a model is "retrieved" via an IP address associated with a network-element-id with device-view=true (e.g., the left side of slide 25), then the device's full view is provided. And when a model is "retrieved" via an IP address associated with a network-element-id with device-view=false (e.g., the ride side of slide 25, either color) only information related to the network-element-id is provided. > It seems to assume this is the "root user physical view". > Please explain how device-type=VIRTUAL is used. This is a bit different and hasn't been a major point of discussion in the WG -- we brought this over from the openconfig draft. I read this as being pretty uninteresting and simply set based on if the device is running on dedicated special purpose h/w (e.g, a classic "name-your-vendor" router) or as a VM (aka NFV). I'll defer to the OC or other DT folks if their opinion differs. Thanks for the comments/discussion! Lou > Andy > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Aug 18 20:04:12 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D36D91AC40E for ; Tue, 18 Aug 2015 20:04: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 cvs2dx5F8zxe for ; Tue, 18 Aug 2015 20:04:06 -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 CD44B1AC40A for ; Tue, 18 Aug 2015 20:04:05 -0700 (PDT) Received: by laba3 with SMTP id a3so7583235lab.1 for ; Tue, 18 Aug 2015 20:04:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Fz2EL/LOVt9dxLk40P+IhBozLupa0eHMrnL8Wc+L97s=; b=BKJPk42q+dlAJOWnPKZhVfJ22EjaVH8u3rjK0WXENt53bM/uBkH4TGhecN2hbaVeoH 6Ko9YHpXI9KtjI7gzwein6YmY/G9tTVLQTyOLuZhegdw9tWcAGED4FvqvTufZhb2fkLq j2q0fLVdTJ+78y79z0Guew69nFwoNlb9kKuut/9kJoXkWZSf/KiFe4VN+hgP27L+Pq8k lAowUHy88c2fksaodxZKfcuk7esIBUYJ5bC/W0cBXZhJINvcdqoFc+IxBTqlM8osm8tW nIlx2HL7aixSrsVz4eOwM/mIsdvxEi3+WvDDNGKOj5Vz9hcbD6uNFXCMHAEbPPQyVs4Z +b3A== X-Gm-Message-State: ALoCoQnhxRfdBLsdtYUehsl8J6iiCJqVJ4a5/oI2WHDT499/julivKZcFm5kJ9+O8BKYLBoou+qP MIME-Version: 1.0 X-Received: by 10.112.170.2 with SMTP id ai2mr9155167lbc.82.1439953444122; Tue, 18 Aug 2015 20:04:04 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Tue, 18 Aug 2015 20:04:03 -0700 (PDT) In-Reply-To: <55D3DDFC.2080107@labn.net> References: <55D3DDFC.2080107@labn.net> Date: Tue, 18 Aug 2015 20:04:03 -0700 Message-ID: From: Andy Bierman To: Lou Berger Content-Type: multipart/alternative; boundary=001a11c33e1887cc66051da1493b Archived-At: Cc: draft-rtgyangdt-rtgwg-device-model@ietf.org, netmod WG , Routing WG Subject: Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 03:04:11 -0000 --001a11c33e1887cc66051da1493b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Aug 18, 2015 at 6:38 PM, Lou Berger wrote: > [Adding authors and RTG WG.] > > Hi Andy, > I'm not sure who you are looking to hear from as you addressed this > mail to the netmod list. I'm happy to give my opinion as it seems you > might have been aiming this at the draft authors. (but then again > perhaps not.) > > Tom sent the meeting invite to netmod so I figured that was where we were supposed to discuss drafts. > On 8/18/2015 8:01 PM, Andy Bierman wrote: > > Hi, > > > > I assume this draft is what we should be reviewing and not > > the obsolete openconfig draft? > > My personal view / hope is that the openconfig draft will be revised to > cover requirements while the DT draft leads to an agreed upon approach > to addressing those requirements. Again, just stating my view, not the > view of the DT, co-authors or OC draft authors. > > Sort of confusing because this draft says it is based on the other draft, so one assumes it is meant to replace it. > > > > > > https://tools.ietf.org/html/draft-rtgyangdt-rtgwg-device-model-00 > > > > > > Q1) scope > > > > > > sec 2: > > > > The model organization can itself be thought of as a "meta-model", > > in that it describes the relationships between individual models. W= e > > choose to represent it also as simple YANG model consisting of lists > > and containers to serve as anchor points for the corresponding > > individual models. > > > > As shown below, our model is rooted at a "device", which represents = a > > network router, switch, or similar network element. > > > > > > Why is this a meta-model? > because the aim to to show how other models inter-relate rather than > define the details of all models. As stated in the intro: > > This document aims to provide an extensible structure that can be > used to tie together other models. It allows for existing, emerging, > and future models. The overall structure can be constructed using > YANG augmentation and imports. > > OK -- the YANG modules themselves should say how they relate to each other. I guess you mean the logical-network-element and other framework nodes. > > It looks like a real YANG data model where ad-hoc classification is > > being done > > using container names. > > Sure, we're using YANG, or at least trying, to document our proposal. > Do you think there's a better way to formally document the work? > > So this document is not the actual set of NP containers that all YANG modules are supposed to augment? It would help to understand how the tree will be managed and maintained over time. > > > If vendors augment this tree with their own ad-hoc hierarchy, then how > > is this > > any better than what we have now? > > > This goes to requirements which is really in the scope of > draft-openconfig-netmod-model-structure. From my perspective it comes > down to how much information is needed from an actual device in order to > come up with its yang-based configuration, and the principle that there > is benefit in this being minimized. For example, consider the case > where a config is generated before a specific device is fielded or > perhaps even purchased/selected. But again, this more of a requirements > discussion. > If a vendor has their own proprietary protocol or HW type, where does it go in the tree? The set of modules used for some function may not be coupled to one node in the data tree. But it is OK if this is out of scope. It is no different than any other standard module that a vendor could augment with proprietary data. > > What is the scope of this work? > see slide 7 of > https://www.ietf.org/proceedings/93/slides/slides-93-rtgwg-3.pdf > > > It appears to be only for "routers switches or similar network elements= ". > > > From the slide: > From DT charter: An overall architecture for > =E2=80=9Cthe protocols and functionality contained inside the Routing = Area=E2=80=9D > > > The hierarchy seems quite router-centric. > It is intended to be network device centric, routers, switches, > firewalls, etc. > So what is the plan for YANG modules that are not specific to these devices= ? For example, some modules like interfaces and NACM could be implemented on any platform, even constrained devices (maybe running CoMI over CoAP). > > Is the expectation that all YANG-based devices will use this > > data hierarchy, or only some devices? > The proposal is to provide a framework for any device that supports a > protocol or other mechanism defined within the routing area. (Or at > least that's our understanding of what we were asked to do.) > > I understand the value of finding data via familiar keywords. (The CLI never went away -- it just grew angle brackets ;-) It is useful to be able to debug with nothing more than a WEB browser and URLs typed by hand. I could never remember a single SNMP OID but YANG data is easy to remember. >From the start, the NETCONF and NETMOD WGs rejected attempts at data organization because it should not matter to a programmatic API. > > > Is the expectation that all YANG modules will use this > > data hierarchy, or only some modules? > > I personally think there will be siblings to /device, e.g., /service - > but this is beyond the scope of this draft. > > > Is it just > > for IETF routing modules or more than that? > > > I think this is the same question and answer as above. > > > Q2) interfaces > > > > The interface model is taken from [RFC7223 < > https://tools.ietf.org/html/rfc7223>] and includes possible > > technology-specific augmentations using example technologies defined > > in [RFC7277 ]. > > +--rw interfaces > > | +--rw interface* [name] > > | +--rw name string > > | +--rw bind-network-element-id? uint8 > > | +--rw ethernet > > | | +--rw bind-networking-instance-name? string > > | | +--rw aggregates > > | | +--rw rstp > > | | +--rw lldp > > | | +--rw ptp > > | +--rw vlans > > | +--rw tunnels > > | +--rw ipv4 > > | | +--rw bind-networking-instance-name? string > > | | +--rw arp > > | | +--rw icmp > > | | +--rw vrrp > > | | +--rw dhcp-client > > | +--rw ipv6 > > | +--rw bind-networking-instance-name? string > > | +--rw vrrp > > | +--rw icmpv6 > > | +--rw nd > > | +--rw dhcpv6-client > > > > > > Actually the interface model is quite different than the one in RFC 722= 3. > > Seems rather ethernet-centric. I notice the "type" leaf was removed, > > along with everything else. Is the plan to toss out RFC 7223, > > recharter the interfaces work, and start over? > > > > So this may be our/my inexperience at play here. I didn't think it > appropriate for a document that is augmenting an existing model to > redefine the current model - I actually thought this was part of the > power of YANG augmentation. Are you saying we should have included the > whole 7223 model to augment it, or something different? > I did not find any augment statements in model-structure.yang. You have to augment /interfaces, not /device/interfaces, if you are using RFC 7223. > Also not the text says: > ... possible technology-specific augmentations using example > technologies .. > and > > The interfaces container includes a number of commonly used > components as examples: > > > Q3) virtual devices > > > > The model supports the potentially independent system management > > functions and configuration per logical network element. This > > permits, for example, different users to manage either the whole > > device or just the associated logical network element. > > > > Sec 2.2.1 shows the system management tree but it is wrong. > > Yes, good catch of a cut-and-past bug. thankfully it is correct both > immediately before in the section intro and the details > > > The following tree is what the YANG model defines: > > +--rw device > > +--rw logical-network-elements > > -rw logical-network-element* [network-element-id] > > +--rw network-element-id uint8 > > +--rw network-element-name? string > > +--rw default-networking-instance-name? string > > +--rw system-management > > | +--rw device-view? boolean > > | +--rw syslog > > | +--rw dns > > | +--rw ntp > > | +--rw statistics-collection > > | +--rw ssh > > | +--rw tacacs > > | +--rw snmp > > | +--rw netconf > > What about devices that do not have logical network elements? > It would have only a single network-element-id > > > This hierarchy may be appropriate for very large routers > > but nothing else. > The intent is to cover all implementations independent of vendors. We > had a good range of view points both in the DT and in the RTGWG > discussion. Not saying there was full agreement, just that we have a > proposed starting point. > > > How can this tree represent both the physical view and the virtual view= ? > Are you referring to section 2.3? If so, I think we all agree (and said > as much in Prague) that this section could be clearer. We/I tried to > explain it in the Prague slide 25 (for this you may want to see the > animation in > https://www.ietf.org/proceedings/93/slides/slides-93-rtgwg-3.pptx) > > Basically the amount of information provided depends on the > logical-network-element context used to access this information. So if > a model is "retrieved" via an IP address associated with a > network-element-id with device-view=3Dtrue (e.g., the left side of slide > 25), then the device's full view is provided. And when a model is > "retrieved" via an IP address associated with a network-element-id with > device-view=3Dfalse (e.g., the ride side of slide 25, either color) only > information related to the network-element-id is provided. > > IMO this logical structure should not be part of data hierarchy itself, since it does not apply to all devices. YANG does not provide a way for the hierarchy to be one way for the physical view and another for a virtual view. The same /path/to/data is seen by both. Is this really what you want? > > It seems to assume this is the "root user physical view". > > Please explain how device-type=3DVIRTUAL is used. > > This is a bit different and hasn't been a major point of discussion in > the WG -- we brought this over from the openconfig draft. I read this > as being pretty uninteresting and simply set based on if the device is > running on dedicated special purpose h/w (e.g, a classic > "name-your-vendor" router) or as a VM (aka NFV). I'll defer to the OC > or other DT folks if their opinion differs. > Each virtual view sees its own slice of the physical device as an entire device, not as 1 entry in a more complex model. IMO it would be better to define a separate data structure and tag it as a special nested datastore root. (e.g. YANG mount). Maybe this would work: container virtual-devices { list virtual-device { key device-id; ... container device { // same data models as the /device contents } } } container device { ... } > Thanks for the comments/discussion! > > Lou > > > Andy > > > Andy > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > --001a11c33e1887cc66051da1493b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Aug 18, 2015 at 6:38 PM, Lou Berger <lberger@labn.net> wrote:
[Adding authors and RTG WG.]=

Hi Andy,
=C2=A0 =C2=A0 I'm not sure who you are looking to hear from as you addr= essed this
mail to the netmod list. I'm happy to give my opinion as it seems you might have been aiming this at the draft authors.=C2=A0 (but then again
perhaps not.)


Tom sent the meeting invite to netmod = so I figured that was where we were
supposed to discuss drafts.

=C2=A0
On 8/18/2015 8:01 PM, Andy Bierman wrote:
> Hi,
>
> I assume this draft is what we should be reviewing and not
> the obsolete openconfig draft?

My personal view / hope is that the openconfig draft will be revised to
cover requirements while the DT draft=C2=A0 leads to an agreed upon approac= h
to addressing those requirements.=C2=A0 Again, just stating my view, not th= e
view of the DT, co-authors or OC draft authors.


Sort of confusing because this draft s= ays it is based on the other draft,
so one assumes it is meant to= replace it.


=C2=A0
>
>
> https://tools.ietf.org/html/dr= aft-rtgyangdt-rtgwg-device-model-00
>
>
> Q1) scope
>
>
> sec 2:
>
>=C2=A0 =C2=A0 The model organization can itself be thought of as a &quo= t;meta-model",
>=C2=A0 =C2=A0 in that it describes the relationships between individual= models.=C2=A0 We
>=C2=A0 =C2=A0 choose to represent it also as simple YANG model consisti= ng of lists
>=C2=A0 =C2=A0 and containers to serve as anchor points for the correspo= nding
>=C2=A0 =C2=A0 individual models.
>
>=C2=A0 =C2=A0 As shown below, our model is rooted at a "device&quo= t;, which represents a
>=C2=A0 =C2=A0 network router, switch, or similar network element.
>
>
> Why is this a meta-model?
because the aim to to show how other models inter-relate rather than
define the details of all models. As stated in the intro:

=C2=A0 =C2=A0This document aims to provide an extensible structure that can= be
=C2=A0 =C2=A0used to tie together other models. It allows for existing, eme= rging,
=C2=A0 =C2=A0and future models. The overall structure can be constructed us= ing
=C2=A0 =C2=A0YANG augmentation and imports.


OK -- the YANG modules themselves shou= ld say how they
relate to each other.=C2=A0 I guess you mean the = logical-network-element
and other framework nodes.
=


> It looks like a real YANG data model where ad-hoc classification is > being done
> using container names.

Sure, we're using YANG, or at least trying, to document our proposal. Do you think there's a better way to formally document the work?



So this document is not= the actual set of NP containers
that all YANG modules are suppos= ed to augment?
It would help to understand how the tree will be m= anaged
and maintained over time.


>
> If vendors augment this tree with their own ad-hoc hierarchy, then how=
> is this
> any better than what we have now?
>
This goes to requirements which is really in the scope of
draft-openconfig-netmod-model-structure.=C2=A0 From my perspective it comes=
down to how much information is needed from an actual device in order to come up with its yang-based configuration, and the principle that there
is benefit in this being minimized.=C2=A0 For example, consider the case where a config is generated before a specific device is fielded or
perhaps even purchased/selected. But again, this more of a requirements
discussion.

If a vendor has their own p= roprietary protocol or HW type,
where does it go in the tree?=C2= =A0 The set of modules used for some
function may not be coupled = to one node in the data tree.=C2=A0

But it is OK i= f this is out of scope.
It is no different than any other standar= d module that a vendor
could augment with proprietary data.
=

=C2=A0
> What is the scope of this work?
see slide 7 of
https://www.ietf.org/proceedings/93/= slides/slides-93-rtgwg-3.pdf

> It appears to be only for "routers switches or similar network el= ements".
>
>From the slide:
=C2=A0 =C2=A0From DT charter: An overall architecture for
=C2=A0 =C2=A0=E2=80=9Cthe protocols and functionality contained inside the = Routing Area=E2=80=9D

> The hierarchy seems quite router-centric.
It is intended to be network device centric, routers, switches,
firewalls, etc.

So what is the plan for= YANG modules that are not specific to these devices?
For example= , some modules like interfaces and NACM could be
implemented on a= ny platform, even constrained devices=C2=A0
(maybe running CoMI o= ver CoAP).=C2=A0



> Is the expectation that all YANG-based devices will use this
> data hierarchy, or only some devices?
The proposal is to provide a framework for any device that supports a
protocol or other mechanism defined within the routing area.=C2=A0 (Or at least that's our understanding of what we were asked to do.)



I understand the value = of finding data via familiar keywords.
(The CLI never went away -= - it just grew angle brackets ;-)
It is useful to be able to debu= g with nothing more than a
WEB browser and URLs typed by hand. I = could never remember
a single SNMP OID but YANG data is easy to r= emember.

From the start, the NETCONF and NETMOD WG= s rejected
attempts at data organization because it should not ma= tter
to a programmatic API.


>
> Is the expectation that all YANG modules will use this
> data hierarchy, or only some modules?

I personally think there will be siblings to /device, e.g., /service -
but this is beyond the scope of this draft.

> Is it just
> for IETF routing modules or more than that?
>
I think this is the same question and answer as above.

> Q2) interfaces
>
>=C2=A0 =C2=A0 The interface model is taken from [RFC7223 <= https://tools.ietf.org/html/rfc7223>] and includes possible
>=C2=A0 =C2=A0 technology-specific augmentations using example technolog= ies defined
>=C2=A0 =C2=A0 in [RFC7277 <https://tools.ietf.org/html/rfc= 7277>].
>=C2=A0 =C2=A0+--rw interfaces
>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw interface* [name]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--rw name=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0strin= g
>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--rw bind-network-elem= ent-id?=C2=A0 =C2=A0uint8
>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--rw ethernet
>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw bind-netw= orking-instance-name?=C2=A0 =C2=A0string
>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw aggregate= s
>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw rstp
>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw lldp
>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw ptp
>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--rw vlans
>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--rw tunnels
>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--rw ipv4
>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw bind-netw= orking-instance-name?=C2=A0 =C2=A0string
>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw arp
>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw icmp
>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw vrrp
>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw dhcp-clie= nt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--rw ipv6
>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw bind-netw= orking-instance-name?=C2=A0 =C2=A0string
>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw vrrp
>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw icmpv6 >=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw nd
>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw dhcpv6-cl= ient
>
>
> Actually the interface model is quite different than the one in RFC 72= 23.
> Seems rather ethernet-centric.=C2=A0 I notice the "type" lea= f was removed,
> along with everything else.=C2=A0 Is the plan to toss out RFC 7223, > recharter the interfaces work, and start over?
>

So this may be our/my inexperience at play here.=C2=A0 I didn't think i= t
appropriate for a document that is augmenting an existing model to
redefine the current model - I actually thought this was part of the
power of YANG augmentation.=C2=A0 Are you saying we should have included th= e
whole 7223 model to augment it, or something different?


=C2=A0I did not find any augment statements= in model-structure.yang.

You have to augment /int= erfaces, not /device/interfaces,
if you are using RFC 7223.
=



Also not the text says:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ... possible technology-specific augmentations= =C2=A0 using example
technologies ..
and

=C2=A0 =C2=A0The interfaces container includes a number of commonly used =C2=A0 =C2=A0components as examples:

> Q3) virtual devices
>
>=C2=A0 =C2=A0 The model supports the potentially independent system man= agement
>=C2=A0 =C2=A0 functions and configuration per logical network element. = This
>=C2=A0 =C2=A0 permits, for example, different users to manage either th= e whole
>=C2=A0 =C2=A0 device or just the associated logical network element. >
> Sec 2.2.1 shows the system management tree but it is wrong.

Yes, good catch of a cut-and-past bug. thankfully it is correct both
immediately before in the section intro and the details

> The following tree is what the YANG model defines:
>=C2=A0 +--rw device
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw logical-network-elements=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -rw logical-net= work-element* [network-element-id]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 += --rw network-element-id=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 uint8
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 += --rw network-element-name?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0string
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 += --rw default-networking-instance-name?=C2=A0 =C2=A0string
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 += --rw system-management
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 +--rw device-view?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 boolean
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 +--rw syslog
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 +--rw dns
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 +--rw ntp
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 +--rw statistics-collection
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 +--rw ssh
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 +--rw tacacs
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 +--rw snmp
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 +--rw netconf
> What about devices that do not have logical network elements?
It would have only a single network-element-id

> This hierarchy may be appropriate for very large routers
> but nothing else.
The intent is to cover all implementations independent of vendors.=C2=A0 We=
had a good range of view points both in the DT and in the RTGWG
discussion.=C2=A0 Not saying there was full agreement, just that we have a<= br> proposed starting=C2=A0 point.

> How can this tree represent both the physical view and the virtual vie= w?
Are you referring to section 2.3?=C2=A0 If so, I think we all agree (and sa= id
as much in Prague) that this section could be clearer.=C2=A0 We/I tried to<= br> explain it in the Prague slide 25 (for this you may want to see the
animation in
https://www.ietf.org/proceedings/93= /slides/slides-93-rtgwg-3.pptx)

Basically the amount of information provided depends on the
logical-network-element context used to access this information.=C2=A0 So i= f
a model is "retrieved" via an IP address associated with a
network-element-id=C2=A0 with device-view=3Dtrue (e.g., the left side of sl= ide
25), then the device's full view is provided.=C2=A0 And when a model is=
"retrieved" via an IP address associated with a network-element-i= d=C2=A0 with
device-view=3Dfalse (e.g., the ride side of slide 25, either color) only information related to the network-element-id is provided.



IMO this logical struct= ure should not be part of data hierarchy itself,
since it does no= t apply to all devices.

YANG does not provide a wa= y for the hierarchy to be
one way for the physical view and anoth= er for
a virtual view. The same /path/to/data is seen by both.
Is this really what you want?

=C2=A0
=
> It seems to assume this is the "root user physical view". > Please explain how device-type=3DVIRTUAL is used.

This is a bit different and hasn't been a major point of discussion in<= br> the WG -- we brought this over from the openconfig draft.=C2=A0 I read this=
as being pretty uninteresting and simply set based on if the device is
running on dedicated special purpose h/w (e.g, a classic
"name-your-vendor" router) or as a VM (aka NFV).=C2=A0 I'll d= efer to the OC
or other DT folks if their opinion differs.

=
Each virtual view sees its own slice of the physical device as an
entire device, not as 1 entry in a more complex model.

=
IMO it would be better to define a separate data structure and
tag it as a special nested datastore root. =C2=A0(e.g. YANG mount)= .

Maybe this would work:

= =C2=A0 container virtual-devices {
=C2=A0 =C2=A0 =C2=A0list virtu= al-device {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 key device-id;
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 =C2=A0 =C2=A0 conta= iner device {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // same d= ata models as the /device contents
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0}
=C2=A0 =C2=A0 =C2=A0}
=C2=A0 }

=C2=A0 container device { ... }



Thanks for the comments/discussion!

Lou

> Andy
>


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


--001a11c33e1887cc66051da1493b-- From nobody Tue Aug 18 23:03:41 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 249091ACD21 for ; Tue, 18 Aug 2015 23:03:40 -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 9JAseb6gvVMz for ; Tue, 18 Aug 2015 23:03:38 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id EDCC31ACD1D for ; Tue, 18 Aug 2015 23:03:37 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 3277A1CC014A; Wed, 19 Aug 2015 08:03:35 +0200 (CEST) From: Ladislav Lhotka To: Randy Presuhn , netmod@ietf.org In-Reply-To: <19754732.1439929603429.JavaMail.root@elwamui-huard.atl.sa.earthlink.net> References: <19754732.1439929603429.JavaMail.root@elwamui-huard.atl.sa.earthlink.net> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Wed, 19 Aug 2015 08:03:33 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] Y34 - root node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 06:03:40 -0000 Randy Presuhn writes: > Hi - > >> From: Andy Bierman >> Sent: Aug 18, 2015 10:22 AM >> To: Robert Wilton >> Cc: NETMOD Working Group >> Subject: Re: [netmod] Y34 - root node >> >> On Tue, Aug 18, 2015 at 9:59 AM, Robert Wilton wrote: > ... >> > I think that having fixed paths may end up being too restrictive. >> >> This is how languages like SMIv2 and YANG work. A conceptual object >> is given a permanent "home" within the tree of object identifiers. > > But it's *not*, for example, how GDMO works. The CMIP world > maintains clear distinctions between the (organizational) hierarchy > of object identifiers, the conceptual hierarchies of inheritance > and class composition, and the containment hierarchy of object > instances. There the "NAME BINDING" template provides the means > of describing places where instances of a given class may come > home to roost. FWIW, RELAX NG also allows for embedding complete grammars inside grammars through the "externalRef" pattern. In our case, the most difficult problem would be XPath expressions and inter-module leafrefs. That's why I thought packages could also be made relocatable, provided that they are self-contained and don't use any references to modules external to the package. Lada > > Randy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Aug 19 02:27:35 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C401AD379; Wed, 19 Aug 2015 02:27: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 KESuQejgrdgm; Wed, 19 Aug 2015 02:27:33 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 01F881AD370; Wed, 19 Aug 2015 02:27:32 -0700 (PDT) Received: from localhost (unknown [173.38.220.43]) by mail.tail-f.com (Postfix) with ESMTPSA id A85431AE0486; Wed, 19 Aug 2015 11:27:30 +0200 (CEST) Date: Wed, 19 Aug 2015 11:27:30 +0200 (CEST) Message-Id: <20150819.112730.1689479932571514728.mbj@tail-f.com> To: lberger@labn.net From: Martin Bjorklund In-Reply-To: <55D3DDFC.2080107@labn.net> References: <55D3DDFC.2080107@labn.net> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: rtgwg@ietf.org, netmod@ietf.org, draft-rtgyangdt-rtgwg-device-model@ietf.org Subject: Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 09:27:35 -0000 SGksDQoNCkxvdSBCZXJnZXIgPGxiZXJnZXJAbGFibi5uZXQ+IHdyb3RlOg0KPiBPbiA4LzE4LzIw MTUgODowMSBQTSwgQW5keSBCaWVybWFuIHdyb3RlOg0KPiA+IFExKSBzY29wZQ0KPiA+DQo+ID4N Cj4gPiBzZWMgMjoNCj4gPg0KPiA+ICAgIFRoZSBtb2RlbCBvcmdhbml6YXRpb24gY2FuIGl0c2Vs ZiBiZSB0aG91Z2h0IG9mIGFzIGEgIm1ldGEtbW9kZWwiLA0KPiA+ICAgIGluIHRoYXQgaXQgZGVz Y3JpYmVzIHRoZSByZWxhdGlvbnNoaXBzIGJldHdlZW4gaW5kaXZpZHVhbCBtb2RlbHMuICBXZQ0K PiA+ICAgIGNob29zZSB0byByZXByZXNlbnQgaXQgYWxzbyBhcyBzaW1wbGUgWUFORyBtb2RlbCBj b25zaXN0aW5nIG9mIGxpc3RzDQo+ID4gICAgYW5kIGNvbnRhaW5lcnMgdG8gc2VydmUgYXMgYW5j aG9yIHBvaW50cyBmb3IgdGhlIGNvcnJlc3BvbmRpbmcNCj4gPiAgICBpbmRpdmlkdWFsIG1vZGVs cy4NCj4gPg0KPiA+ICAgIEFzIHNob3duIGJlbG93LCBvdXIgbW9kZWwgaXMgcm9vdGVkIGF0IGEg ImRldmljZSIsIHdoaWNoIHJlcHJlc2VudHMgYQ0KPiA+ICAgIG5ldHdvcmsgcm91dGVyLCBzd2l0 Y2gsIG9yIHNpbWlsYXIgbmV0d29yayBlbGVtZW50LiAgDQo+ID4NCj4gPg0KPiA+IFdoeSBpcyB0 aGlzIGEgbWV0YS1tb2RlbD8NCj4gYmVjYXVzZSB0aGUgYWltIHRvIHRvIHNob3cgaG93IG90aGVy IG1vZGVscyBpbnRlci1yZWxhdGUgcmF0aGVyIHRoYW4NCj4gZGVmaW5lIHRoZSBkZXRhaWxzIG9m IGFsbCBtb2RlbHMuIEFzIHN0YXRlZCBpbiB0aGUgaW50cm86DQo+IA0KPiAgICBUaGlzIGRvY3Vt ZW50IGFpbXMgdG8gcHJvdmlkZSBhbiBleHRlbnNpYmxlIHN0cnVjdHVyZSB0aGF0IGNhbiBiZQ0K PiAgICB1c2VkIHRvIHRpZSB0b2dldGhlciBvdGhlciBtb2RlbHMuIEl0IGFsbG93cyBmb3IgZXhp c3RpbmcsIGVtZXJnaW5nLA0KPiAgICBhbmQgZnV0dXJlIG1vZGVscy4gVGhlIG92ZXJhbGwgc3Ry dWN0dXJlIGNhbiBiZSBjb25zdHJ1Y3RlZCB1c2luZw0KPiAgICBZQU5HIGF1Z21lbnRhdGlvbiBh bmQgaW1wb3J0cy4NCj4gDQo+IA0KPiA+IEl0IGxvb2tzIGxpa2UgYSByZWFsIFlBTkcgZGF0YSBt b2RlbCB3aGVyZSBhZC1ob2MgY2xhc3NpZmljYXRpb24gaXMNCj4gPiBiZWluZyBkb25lDQo+ID4g dXNpbmcgY29udGFpbmVyIG5hbWVzLg0KPiANCj4gU3VyZSwgd2UncmUgdXNpbmcgWUFORywgb3Ig YXQgbGVhc3QgdHJ5aW5nLCB0byBkb2N1bWVudCBvdXIgcHJvcG9zYWwuIA0KPiBEbyB5b3UgdGhp bmsgdGhlcmUncyBhIGJldHRlciB3YXkgdG8gZm9ybWFsbHkgZG9jdW1lbnQgdGhlIHdvcms/DQoN CkkgY2FuIHNlZSB0d28gYXBwcm9hY2hlczoNCg0KICAxKSBEZWZpbmUgYSBZQU5HIG1vZHVsZSB3 aXRoIHRoZSBzdHJ1Y3R1cmFsIGhpZXJhcmNoeS4gIFRoZW4NCiAgICAgb3RoZXIgbW9kdWxlcyBh dWdtZW50IHRoaXMgbW9kdWxlIGF0IHRoZSBjb3JyZWN0IHBsYWNlIGluIHRoZQ0KICAgICBoaWVy YXJjaHkuICBUaGlzIG1vZHVsZSB3aWxsIHByb2JhYmx5IGJlIHVwZGF0ZWQgcHJldHR5IG9mdGVu LA0KICAgICBlc3BlY2lhbGx5IGlmIHRoZSBpZGVhIHRvIGhhdmUgT05FIG1vZHVsZSB3aXRoIHRo ZSBjb21wbGV0ZQ0KICAgICBoaWVyYXJjaHkgZm9yIEFMTCB0eXBlcyBvZiBkZXZpY2VzLg0KDQog ICAgIEEgdmFyaWFudCBpcyB0byBkZWZpbmUgc3VjaCBhIG1vZHVsZSBmb3Igcm91dGluZy1zcGVj aWZpYyBtb2R1bGVzDQogICAgIG9ubHkgdG8gYXVnbWVudC4gIE90aGVyIGFyZWFzIGNhbiBkZWZp bmUgc2ltaWxhciAic3RydWN0dXJhbCINCiAgICAgbW9kdWxlcy4NCg0KICAyKSBEb2N1bWVudCB0 aGUgaGllcmFyY2h5IGFzIGEgZ3VpZGVsaW5lLiAgV2hlbiBpdCBpcyB0aW1lIHRvIHdvcmsNCiAg ICAgb24gYSBuZXcgbW9kdWxlLCBsZXRzIHNheSBtcGxzLCB3ZSBsb29rIGludG8gdGhpcyBndWlk ZWxpbmUgYW5kDQogICAgIGRlZmluZSB0aGUgbmVjZXNzYXJ5IGhpZXJhcmNoeSBpbiB0aGUgbXBs cyBtb2R1bGUuDQoNCg0KPiA+IElmIHZlbmRvcnMgYXVnbWVudCB0aGlzIHRyZWUgd2l0aCB0aGVp ciBvd24gYWQtaG9jIGhpZXJhcmNoeSwgdGhlbiBob3cNCj4gPiBpcyB0aGlzDQo+ID4gYW55IGJl dHRlciB0aGFuIHdoYXQgd2UgaGF2ZSBub3c/DQo+ID4NCj4gVGhpcyBnb2VzIHRvIHJlcXVpcmVt ZW50cyB3aGljaCBpcyByZWFsbHkgaW4gdGhlIHNjb3BlIG9mDQo+IGRyYWZ0LW9wZW5jb25maWct bmV0bW9kLW1vZGVsLXN0cnVjdHVyZS4gIEZyb20gbXkgcGVyc3BlY3RpdmUgaXQgY29tZXMNCj4g ZG93biB0byBob3cgbXVjaCBpbmZvcm1hdGlvbiBpcyBuZWVkZWQgZnJvbSBhbiBhY3R1YWwgZGV2 aWNlIGluIG9yZGVyIHRvDQo+IGNvbWUgdXAgd2l0aCBpdHMgeWFuZy1iYXNlZCBjb25maWd1cmF0 aW9uLCBhbmQgdGhlIHByaW5jaXBsZSB0aGF0IHRoZXJlDQo+IGlzIGJlbmVmaXQgaW4gdGhpcyBi ZWluZyBtaW5pbWl6ZWQuICBGb3IgZXhhbXBsZSwgY29uc2lkZXIgdGhlIGNhc2UNCj4gd2hlcmUg YSBjb25maWcgaXMgZ2VuZXJhdGVkIGJlZm9yZSBhIHNwZWNpZmljIGRldmljZSBpcyBmaWVsZGVk IG9yDQo+IHBlcmhhcHMgZXZlbiBwdXJjaGFzZWQvc2VsZWN0ZWQuDQoNCkFzIGxvbmcgYXMgdGhl IGRldmljZSBpbXBsZW1lbnRzIHN0YW5kYXJkIGRhdGEgbW9kZWxzLCB3aHkgZG9lcyBpdA0KbWF0 dGVyIGZvciBwcmUtcHJvdmlzaW9uaW5nIGlmIHRoZSBzdGFuZGFyZCBwYXRoIHRvIGNvbmZpZ3Vy ZSBhbg0KaW50ZXJmYWNlIGlzIC9kZXZpY2VzL2ludGVyZmFjZXMvaW50ZXJmYWNlIG9yIC9pbnRl cmZhY2VzL2ludGVyZmFjZT8NCg0KPiA+IFdoYXQgaXMgdGhlIHNjb3BlIG9mIHRoaXMgd29yaz8N Cj4gc2VlIHNsaWRlIDcgb2YNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTMv c2xpZGVzL3NsaWRlcy05My1ydGd3Zy0zLnBkZg0KPiANCj4gPiBJdCBhcHBlYXJzIHRvIGJlIG9u bHkgZm9yICJyb3V0ZXJzIHN3aXRjaGVzIG9yIHNpbWlsYXIgbmV0d29yayBlbGVtZW50cyIuDQo+ ID4NCj4gPkZyb20gdGhlIHNsaWRlOg0KPiAgICBGcm9tIERUIGNoYXJ0ZXI6IEFuIG92ZXJhbGwg YXJjaGl0ZWN0dXJlIGZvcg0KPiAgICDigJx0aGUgcHJvdG9jb2xzIGFuZCBmdW5jdGlvbmFsaXR5 IGNvbnRhaW5lZCBpbnNpZGUgdGhlIFJvdXRpbmcgQXJlYeKAnQ0KDQpCdXQgdGhlIGRlc2lnbiB5 b3UgcHJvcG9zZSBoYXMgaHVnZSBpbXBhY3Qgb24gYWxsIG1vZGVscywgYWxzbyBtb2RlbHMNCmZy b20gb3RoZXIgYXJlYXMuDQoNCj4gPiBRMikgaW50ZXJmYWNlcw0KPiA+DQo+ID4gICAgVGhlIGlu dGVyZmFjZSBtb2RlbCBpcyB0YWtlbiBmcm9tIFtSRkM3MjIzIDxodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvcmZjNzIyMz5dIGFuZCBpbmNsdWRlcyBwb3NzaWJsZQ0KPiA+ICAgIHRlY2hub2xv Z3ktc3BlY2lmaWMgYXVnbWVudGF0aW9ucyB1c2luZyBleGFtcGxlIHRlY2hub2xvZ2llcyBkZWZp bmVkDQo+ID4gICAgaW4gW1JGQzcyNzcgPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3 Mjc3Pl0uDQo+ID4gICArLS1ydyBpbnRlcmZhY2VzDQo+ID4gICAgICAgfCAgKy0tcncgaW50ZXJm YWNlKiBbbmFtZV0NCj4gPiAgICAgICB8ICAgICArLS1ydyBuYW1lICAgICAgICAgICAgICAgICAg ICAgICBzdHJpbmcNCj4gPiAgICAgICB8ICAgICArLS1ydyBiaW5kLW5ldHdvcmstZWxlbWVudC1p ZD8gICB1aW50OA0KPiA+ICAgICAgIHwgICAgICstLXJ3IGV0aGVybmV0DQo+ID4gICAgICAgfCAg ICAgfCAgKy0tcncgYmluZC1uZXR3b3JraW5nLWluc3RhbmNlLW5hbWU/ICAgc3RyaW5nDQo+ID4g ICAgICAgfCAgICAgfCAgKy0tcncgYWdncmVnYXRlcw0KPiA+ICAgICAgIHwgICAgIHwgICstLXJ3 IHJzdHANCj4gPiAgICAgICB8ICAgICB8ICArLS1ydyBsbGRwDQo+ID4gICAgICAgfCAgICAgfCAg Ky0tcncgcHRwDQo+ID4gICAgICAgfCAgICAgKy0tcncgdmxhbnMNCj4gPiAgICAgICB8ICAgICAr LS1ydyB0dW5uZWxzDQo+ID4gICAgICAgfCAgICAgKy0tcncgaXB2NA0KPiA+ICAgICAgIHwgICAg IHwgICstLXJ3IGJpbmQtbmV0d29ya2luZy1pbnN0YW5jZS1uYW1lPyAgIHN0cmluZw0KPiA+ICAg ICAgIHwgICAgIHwgICstLXJ3IGFycA0KPiA+ICAgICAgIHwgICAgIHwgICstLXJ3IGljbXANCj4g PiAgICAgICB8ICAgICB8ICArLS1ydyB2cnJwDQo+ID4gICAgICAgfCAgICAgfCAgKy0tcncgZGhj cC1jbGllbnQNCj4gPiAgICAgICB8ICAgICArLS1ydyBpcHY2DQo+ID4gICAgICAgfCAgICAgICAg Ky0tcncgYmluZC1uZXR3b3JraW5nLWluc3RhbmNlLW5hbWU/ICAgc3RyaW5nDQo+ID4gICAgICAg fCAgICAgICAgKy0tcncgdnJycA0KPiA+ICAgICAgIHwgICAgICAgICstLXJ3IGljbXB2Ng0KPiA+ ICAgICAgIHwgICAgICAgICstLXJ3IG5kDQo+ID4gICAgICAgfCAgICAgICAgKy0tcncgZGhjcHY2 LWNsaWVudA0KPiA+DQo+ID4NCj4gPiBBY3R1YWxseSB0aGUgaW50ZXJmYWNlIG1vZGVsIGlzIHF1 aXRlIGRpZmZlcmVudCB0aGFuIHRoZSBvbmUgaW4gUkZDIDcyMjMuDQo+ID4gU2VlbXMgcmF0aGVy IGV0aGVybmV0LWNlbnRyaWMuICBJIG5vdGljZSB0aGUgInR5cGUiIGxlYWYgd2FzIHJlbW92ZWQs DQo+ID4gYWxvbmcgd2l0aCBldmVyeXRoaW5nIGVsc2UuICBJcyB0aGUgcGxhbiB0byB0b3NzIG91 dCBSRkMgNzIyMywNCj4gPiByZWNoYXJ0ZXIgdGhlIGludGVyZmFjZXMgd29yaywgYW5kIHN0YXJ0 IG92ZXI/DQo+ID4NCj4gDQo+IFNvIHRoaXMgbWF5IGJlIG91ci9teSBpbmV4cGVyaWVuY2UgYXQg cGxheSBoZXJlLiAgSSBkaWRuJ3QgdGhpbmsgaXQNCj4gYXBwcm9wcmlhdGUgZm9yIGEgZG9jdW1l bnQgdGhhdCBpcyBhdWdtZW50aW5nIGFuIGV4aXN0aW5nIG1vZGVsIHRvDQo+IHJlZGVmaW5lIHRo ZSBjdXJyZW50IG1vZGVsIC0gSSBhY3R1YWxseSB0aG91Z2h0IHRoaXMgd2FzIHBhcnQgb2YgdGhl DQo+IHBvd2VyIG9mIFlBTkcgYXVnbWVudGF0aW9uLiAgQXJlIHlvdSBzYXlpbmcgd2Ugc2hvdWxk IGhhdmUgaW5jbHVkZWQgdGhlDQo+IHdob2xlIDcyMjMgbW9kZWwgdG8gYXVnbWVudCBpdCwgb3Ig c29tZXRoaW5nIGRpZmZlcmVudD8NCg0KQXMgbG9uZyBhcyB5b3Ugd2FudCB0byBoYXZlIC9kZXZp Y2UvaW50ZXJmYWNlcywgeW91IG5lZWQgdG8gb2Jzb2xldGUNCnRoZSBtb2RlbCBpbiBSRkMgNzIy MyAoYW5kIGFsbCBvdGhlciBwdWJsaXNoZWQgWUFORyBtb2RlbHMpIGFuZA0KcmV3cml0ZSB0aGVt LiAgSG93ZXZlciwgaWYgd2UgZ2V0IHJpZCBvZiB0aGUgL2RldmljZSBjb250YWluZXIsIHRoZQ0K ZXhpc3RpbmcgbW9kZWwgaW4gUkZDIDcyMjMgZml0IGluIG5pY2VseSBpbiB5b3VyIGhpZXJhcmNo eS4NCg0KSSB0aGluayBtYW55IG9mIHVzIGhhdmUgc2FpZCB0aGlzIGJlZm9yZSwgYnV0IHRoZSB0 b3AtbGV2ZWwgY29udGFpbmVyDQovZGV2aWNlIGRvZXNuJ3QgcmVhbGx5IHNvbHZlIGFueSBwcm9i bGVtLiAgU3VwcG9zZSB3ZSBoYXZlIGEgbW9kdWxlDQp0b2RheSB3aXRoIGEgdG9wLWxldmVsIG5v ZGUgL0ZPTy4gIFdoeSB3b3VsZCB0aGlzIG1vZHVsZSB3b3JrIGJldHRlcg0KaWYgaXQgYXVnZW1l bnRlZCAvZGV2aWNlIHRvIGdpdmUgL2RldmljZS9GT08/DQoNCk1heWJlIHRoZSBwcm9ibGVtIHlv dSBhcmUgdHJ5aW5nIHRvIHNvbHZlIHdpdGggIi9kZXZpY2UiIGlzIHdoYXQgaXMNCndyaXR0ZW4g aW4gc2VjdGlvbiAzLjE6DQoNCiAgIE9uZSBvZiB0aGUgY2hhbGxlbmdlcyBpbiBhc3NlbWJsaW5n IGV4aXN0aW5nIFlBTkcgbW9kZWxzIGlzIHRoYXQgdGhleQ0KICAgYXJlIGdlbmVyYWxseSB3cml0 dGVuIHdpdGggdGhlIGFzc3VtcHRpb24gdGhhdCBlYWNoIG1vZGVsIGlzIGF0IHRoZQ0KICAgcm9v dCBvZiB0aGUgY29uZmlndXJhdGlvbiBvciBzdGF0ZSB0cmVlLiAgQ29tYmluaW5nIG1vZGVscyB0 aGVuDQogICByZXN1bHRzIGluIGEgbXVsdGktcm9vdGVkIHRyZWUgdGhhdCBkb2VzIG5vdCBmb2xs b3cgYW55IGxvZ2ljYWwNCiAgIGNvbnN0cnVjdGlvbiBhbmQgbWFrZXMgaXQgZGlmZmljdWx0IHRv IHdvcmsgd2l0aCBvcGVyYXRpb25hbGx5LiAgSW4NCiAgIHNvbWUgY2FzZXMsIG1vZGVscyBleHBs aWNpdGx5IHJlZmVyZW5jZSBvdGhlciBtb2RlbHMgKGUuZy4sIHZpYQ0KICAgYXVnbWVudGF0aW9u KSB0byBkZWZpbmUgYSByZWxhdGlvbnNoaXAsIGJ1dCB0aGlzIGlzIHRoZSBjYXNlIGZvciBvbmx5 DQogICBhIGZldyBleGlzdGluZyBtb2RlbHMuDQoNCkZpcnN0IG9mIGFsbCBJIGRvbid0IHJlYWxs eSBhZ3JlZSB3aXRoIHRoaXMuICBXZSBqdXN0IGhhdmUgYSBmZXcNCm1vZHVsZSBwdWJsaXNoZWQs IGJ1dCBmb3IgZXhhbXBsZSBpZXRmLWlwIGF1Z21lbnRzIGlldGYtaW50ZXJmYWNlcywNCmFuZCB0 aGUgaWRlYSB3aXRoIGlldGYtcm91dGluZyBpcyB0aGF0IHJvdXRpbmctc3BlY2lmaWMgbW9kdWxl cw0KYXVnbWVudCBpdC4gIEluIGZhY3QsIEkgdGhpbmsgdGhlIHB1Ymxpc2hlZCBtb2R1bGVzIGZv bGxvdyB5b3VyDQpwcm9wb3NlZCBoaWVyYXJjaHkgKHdpdGggc29tZSBleGNlcHRpb24pIC0gaWYg aXQgd2Fzbid0IGZvciB0aGUNCi9kZXZpY2Ugbm9kZS4NCg0KU2Vjb25kLCBpZiB3ZSB3YW50IHRv IGJlIGNvbnNlcnZhdGl2ZSB3aXRoIHRvcC1sZXZlbCBub2RlcyAoSSBhbSBub3QNCmNvbnZpbmNl ZCB0aGF0IHRoaXMgaXMgYSBwcm9ibGVtKSB3ZSBjYW4gc29sdmUgdGhhdCB3aXRob3V0IGdvaW5n IGludG8NCnRoZSBleHRyZW1lIG9mIGhhdmluZyAqb25lKiB0b3AtbGV2ZWwgbm9kZS4gIEluc3Rl YWQgb2YgaGF2aW5nIE4NCnRvcC1sZXZlbCBub2Rlcywgd2Ugd291bGQgaGF2ZSBOIG5vZGVzIHVu ZGVyIC9kZXZpY2UuICBXaHkgaXMgdGhpcw0KYmV0dGVyPw0KDQo+IEFyZSB5b3UgcmVmZXJyaW5n IHRvIHNlY3Rpb24gMi4zPyAgSWYgc28sIEkgdGhpbmsgd2UgYWxsIGFncmVlIChhbmQgc2FpZA0K PiBhcyBtdWNoIGluIFByYWd1ZSkgdGhhdCB0aGlzIHNlY3Rpb24gY291bGQgYmUgY2xlYXJlci4g IFdlL0kgdHJpZWQgdG8NCj4gZXhwbGFpbiBpdCBpbiB0aGUgUHJhZ3VlIHNsaWRlIDI1IChmb3Ig dGhpcyB5b3UgbWF5IHdhbnQgdG8gc2VlIHRoZQ0KPiBhbmltYXRpb24gaW4NCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTMvc2xpZGVzL3NsaWRlcy05My1ydGd3Zy0zLnBwdHgp DQo+IA0KPiBCYXNpY2FsbHkgdGhlIGFtb3VudCBvZiBpbmZvcm1hdGlvbiBwcm92aWRlZCBkZXBl bmRzIG9uIHRoZQ0KPiBsb2dpY2FsLW5ldHdvcmstZWxlbWVudCBjb250ZXh0IHVzZWQgdG8gYWNj ZXNzIHRoaXMgaW5mb3JtYXRpb24uICBTbyBpZg0KPiBhIG1vZGVsIGlzICJyZXRyaWV2ZWQiIHZp YSBhbiBJUCBhZGRyZXNzIGFzc29jaWF0ZWQgd2l0aCBhDQo+IG5ldHdvcmstZWxlbWVudC1pZCAg d2l0aCBkZXZpY2Utdmlldz10cnVlIChlLmcuLCB0aGUgbGVmdCBzaWRlIG9mIHNsaWRlDQo+IDI1 KSwgdGhlbiB0aGUgZGV2aWNlJ3MgZnVsbCB2aWV3IGlzIHByb3ZpZGVkLiAgQW5kIHdoZW4gYSBt b2RlbCBpcw0KPiAicmV0cmlldmVkIiB2aWEgYW4gSVAgYWRkcmVzcyBhc3NvY2lhdGVkIHdpdGgg YSBuZXR3b3JrLWVsZW1lbnQtaWQgIHdpdGgNCj4gZGV2aWNlLXZpZXc9ZmFsc2UgKGUuZy4sIHRo ZSByaWRlIHNpZGUgb2Ygc2xpZGUgMjUsIGVpdGhlciBjb2xvcikgb25seQ0KPiBpbmZvcm1hdGlv biByZWxhdGVkIHRvIHRoZSBuZXR3b3JrLWVsZW1lbnQtaWQgaXMgcHJvdmlkZWQuDQoNCkRvIHlv dSB3YW50IHRoZSB1c2VyIGZyb20gYSBwYXJ0aWN1bGFyIElQIGFkZHJlc3MgdG8gaGF2ZSBhY2Nl c3MgdG8NCmp1c3QgaGlzIHBhcnQgb2YgdGhlIHRyZWUsIG9yIGRvIHlvdSB3YW50IHRoYXQgdXNl ciB0byBoYXZlIGhpcyBvd24NCiJzYW5kYm94IiB0aGF0IGhlIGNhbiBjb250cm9sIGluZGVwZW5k ZW50bHkgb2Ygb3RoZXIgdXNlcnM/DQoNCkluIHRoZSBmaXJzdCBjYXNlLCB5b3UgY2FuIHVzZSBO QUNNIHRvIHNldCB1cCBydWxlcyB0byBnaXZlIGVhY2ggdXNlcg0KcHJvcGVyIGFjY2VzcyAoYmFz ZWQgb24gdXNlciBpZGVudGl0eSByYXRoZXIgdGhhbiBJUCBhZGRyZXNzIHRob3VnaCkuDQpZb3Ug ZG9uJ3QgbmVlZCB0aGlzICJkZXZpY2UtdmlldyIgaW4gb3JkZXIgdG8gZG8gdGhpcy4NCg0KSW4g dGhlIGxhdHRlciBjYXNlLCBJIGRvbid0IHRoaW5rIHRoZSBwcm9wb3NlZCBkZXNpZ24gd29ya3Mu ICAoSSBjYW4NCmdvIGludG8gZGV0YWlscyBpZiBpdCB0dXJucyBvdXQgdGhhdCB0aGlzIHdoYXQg eW91IGhhZCBpbiBtaW5kKS4NCg0KDQoNCi9tYXJ0aW4NCg== From nobody Wed Aug 19 03:38:53 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9AE91B2A0C for ; Wed, 19 Aug 2015 03:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.31 X-Spam-Level: X-Spam-Status: No, score=-13.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_34=0.6, 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 izlvnx2MaVBw for ; Wed, 19 Aug 2015 03:38:45 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 724BE1B2A0A for ; Wed, 19 Aug 2015 03:38:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=66827; q=dns/txt; s=iport; t=1439980724; x=1441190324; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=etZv3Az41bJ10ZgC6g/M+26SUbY8Yr/kYWkuwkXgJRM=; b=Gp4Lxvz7ZE80YPfreEuElbz7QvTEKH8ndKncHLWt0jgMhIcjhdlD7y7o hXMezHNxFiRGY4/zP6GdBUtiLnqWXyGvtAwwFk96XtGxFPL8PGvcTNdkx uBgDcpgwQzBwu8JYfg7B93/kYprezR+EepCl0z3ZCPcEMqOlYeP1fn1BZ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C/BADcW9RV/xbLJq1dg29pgyW8MhkBCYUxSgKCDgEBAQEBAYELhCMBAQEDAQEBARcBCEsEBgEFBwQLEAEDAQEBAQkMCgEBBgMCAgkDAgECARUfCQgGDQYCAQEVAogLCA25MZYVAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4pQgQOEPwkxEQcGBIJfgUMFjF8BhTSDD4UEgmyEfYFKRoZeIohxhEiDaCaCDhyBVD0zAYEGgUUBAQE X-IronPort-AV: E=Sophos;i="5.15,709,1432598400"; d="scan'208,217";a="606454432" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 19 Aug 2015 10:38:41 +0000 Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t7JAce3j027929; Wed, 19 Aug 2015 10:38:41 GMT To: Andy Bierman References: <52B35D5C-E9F9-48B7-8B80-9416ABB18642@nic.cz> <55D36473.90609@cisco.com> From: Robert Wilton Message-ID: <55D45CAF.2070605@cisco.com> Date: Wed, 19 Aug 2015 11:38:39 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------010905010405070905020104" Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Y34 - root node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 10:38:51 -0000 This is a multi-part message in MIME format. --------------010905010405070905020104 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 18/08/2015 18:22, Andy Bierman wrote: > > > On Tue, Aug 18, 2015 at 9:59 AM, Robert Wilton > wrote: > > > > On 11/08/2015 08:38, Ladislav Lhotka wrote: > > On 10 Aug 2015, at 22:15, Andy Bierman > wrote: > > > > On Mon, Aug 10, 2015 at 12:34 PM, Acee Lindem (acee) > > wrote: > I think there is agreement that there is a problem. The > YANG Routing Design Team is addressing this with > https://www.ietf.org/id/draft-rtgyangdt-rtgwg-device-model-00.txt > (which has evolved from > https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt). > In essence, a place for everything and everything in its > place. However, there are those who feel that can’t > mandate a single model structure for network devices and > we need mechanisms to manage multiple models but allow for > different device structure (e.g., > https://www.ietf.org/id/draft-bierman-netmod-yang-package-00.txt). > I hope we can agree on an approach in the coming interim > meetings. > > > Do you expect "everything in its place" to apply to all > other SDOs and > all vendor modules? Or do you expect just the IETF routing > modules > to follow this subtree hierarchy? If the former, does this > mean the > YANG Routing Design Team is the "YANG data placement > authority" > or all YANG modules that ever get written? How long should > it take for all other SDOs and vendors to redo all their > existing > modules to re-root them in their assigned place in the > data tree? > > IMO is is not a good idea to rely on rigid data node > placement, > and a single data placement authority. It is better and > use meta-data > built from the YANG modules (or YANG packages) instead. > > I think that having fixed paths may end up being too restrictive. > > > > This is how languages like SMIv2 and YANG work. > A conceptual object is given a permanent "home" within the tree of > object identifiers. > Moving data is very expensive, since any clients working with the old data > will break as soon as the data is moved. > > I am not convinced the IETF can or should come up with a set of > containers > that covers every possible topic that can be modeled in YANG. I mostly agree, but having some more structure/advice as to where to place YANG modules may be helpful. I'm thinking more along the lines of broad categories rather than precise locations. E.g. I had suggested that it might be good if the Diffserv QoS YANG model was located in some slightly more abstract QoS containers/choices (e.g. for queuing/shaping/policying/etc). Mainly my reasoning for this was the observation that vendor specific extensions would probably fit better augmenting generic QoS containers rather than a DiffServ specific QoS model (e.g. if they were adding L2 specific QoS features which wouldn't sit cleanly on top of a specific L3 QoS model). However, I think that Norman Finn also mentioned a requirement from Deterministic Networking where it may be necessary to interact with some abstract QoS parameters without having to know the precise details of the underlying QoS model. One other observation is that if we do end up with some more hierarchy then the "can't augment with mandatory node" issue may become a much more widespread issue. Today, top level models can introduce mandatory nodes, but if they were all augmentations of an existing container they would not be able to (without a P-container). > Even if such a lake could be brought to a boil, I have no confidence > that the hierarchy will be 100% stable. It can certainly > never be 100% complete. If the IETF thinks it's a good idea > to obsolete all YANG RFCs and start over now, who is to say > the IETF won't do that again every few years? My perception is that YANG models and how to fit them together are still somewhat in flux. There are lots of drafts defining YANG models were folks (myself included) are trying to figure out how these models should all fit together, but relatively few published RFCs. So, personally I think that there is still a potential opportunity to add some more structure at this time if the desire is strong enough. But I'm new to IETF, and hence perhaps this is just my naivety of the IETF processes. Three years down the line and I doubt that will be the case - there will be too much inertia, and unless it is very broken it won't get changed. > > > > The reason Linux uses packages to install/update functionality > is because managing 8000 packages is hard enough. > Managing 247,000 individual files would be insane. > The actual location of files is quite configurable and > different > across distros. We could learn something from the last decade > of Linux package management, and try to apply it to YANG. > > That’s an interesting idea, could a YANG package also specify, > e.g. that the root node for the package is X/Y/Z? This could > solve some use cases for relocatability, and it would also be > relatively easy to modify all absolute XPath expressions > inside the package. > > If someone wants to builds a YANG controller node that is managing > the configuration for a network of devices then wouldn't they want > a particular device's interface configuration to be located > somewhere like /network/device//interfaces/interface? > Ideally, they would be able to use the same YANG definitions that > are defined for /interfaces/ but root them relative to > /network/device//. > > > > Yes -- some of us (like Martin) have pointed this out many times. > The "device" container on an NE does not help at all wrt/ > aggregation on a controller. "/device" or "/" work the same for this > purpose. > > > Having YANG packages being able to control the relative paths of > the imported YANG modules would possibly allow for more > flexibility in how YANG modules fit together, and also give a more > pragmatic way for how these could be changed/upgraded in future if > necessary. > > > > YANG packages provide a way to describe a set of modules. > They do not change the top-level data nodes of any objects. > This would be very complicated and not really worth it. > > > IMO the "tree of NP containers" should be a resource directory, > meaning it contains links to the real resources. Kind of like an > index in a library. They don't keep the contents of every book in the > index. > They keep the location of every book in the index. The index is stable. > The resource location does not have to be stable. What would the real resource location for "/network/device//interfaces/interface" be? If the concrete location for all interfaces (regardless of device) was the flat list /interfaces/ then you would get clashes between the names of the interfaces on different devices. Also, what if someone wanted two separate lists of interfaces in two separate parts of the resource hierarchy. Would that be feasible? Thanks, Rob > > > Cheers, > Rob > > > Andy > > > > > Lada > > > > > > Thanks, > Acee > > > Andy > > > > From: netmod > on behalf of "Einar > Nilsen-Nygaard (einarnn)" > > Date: Monday, August 10, 2015 at 5:29 AM > To: Jonathan Hansford > > Cc: NETMOD Working Group > > Subject: Re: [netmod] Y34 - root node > > As someone sharing responsibilities for guiding a number > of development teams both defining new models and > implementing to some already defined models in this area, > I can only agree with this addition to what I said earlier. > > Cheers, > > Einar > > On Aug 10, 2015, at 9:46 AM, Jonathan Hansford > > wrote: > > And it is not just end users who need help to better > understand YANG models and how to use them. For those > still on the edge, looking to finally take the plunge > and use NETCONF/YANG to configure their devices, help > is also required to determine how best to structure > their YANG models, make use of the existing ones, etc. > For those who have "grown up" with the developments in > NETCONF and YANG, much of this is probably second > nature. But coming to it cold (in the sense of > compiling/writing a first set of YANG models for a > device; I've been following the netconf/netmod WGs for > 3+ years), it still feels very much like a dark art! > It is not just the individual modules, it is how to > put them together to best manage a device (let alone a > system). > > Jonathan > > > > ----- Original Message ----- > From: > "Einar Nilsen-Nygaard (einarnn)" > > > To: > "Andy Bierman" > > Cc: > "NETMOD Working Group" > > Sent: > Sat, 8 Aug 2015 11:10:15 +0000 > Subject: > Re: [netmod] Y34 - root node > > > Andy, > > I agree that there is a need for organization of > models, but I don’t have a firm position on > draft-openconfig-netmod-model-structure/draft-rtgyangdt-rtgwg-device-model > or draft-bierman-netmod-yang-package. But we > absolutely need *something* to help end-users of the > models comprehend the overall structure of models, > their relationship and how to use them. > > Cheers, > > Einar > > On Aug 4, 2015, at 5:16 PM, Andy Bierman > > wrote: > > > > On Tue, Aug 4, 2015 at 2:34 AM, t.petch > > wrote: > ----- Original Message ----- > From: "Andy Bierman" > > To: "t.petch" > > Sent: Monday, August 03, 2015 5:17 PM > > ----- Original Message ----- > From: "Andy Bierman" > To: "t.petch" > > Sent: Monday, August 03, 2015 4:10 PM > > ----- Original Message ----- > From: "Andy Bierman" andy@yumaworks.com > > Sent: Saturday, August 01, 2015 7:05 PM > On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem > (acee) > > > On 8/1/15, 2:51 AM, > j.schoenwaelder@jacobs-university.de > > > wrote: > > Section 1.1 in > > https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt > > lists the goals of a generic model > structure that will accommodate > > most > > modern network devices. I guess you don’t > agree that these are > > desirable? > > The only objection I have to this draft is the > insertion of a > > top-level > > root > called "device". (Might as well be called > "self"). > There are no sibling nodes planned or intended for > this node, so it serves as an extra document root. > > > One aspect of YANG I have never grasped is > what a root means, if > anything. > > I understand that it is needed for NETCONF > (filters) and for YANG > (augments, constraints) and so must be > somewhere and must be > > relatively > > stable, but has it any other significance in > the data model? > > As you may recall, I was involved with SMI > first, where the root is > somewhere up in the sky and life only becomes > interesting some six > levels down the hierarchy and that may colour > my thinking. > > YANG does a poor job of defining the root for YANG > data nodes. > It is sometimes called a datastore (in the abstract). > Technically, YANG borrows the definition from XPath. > YANG just defines top-level data nodes and the > parent of > these nodes is the document root > > There is no protocol or encoding neutral definition, > only an XML-specific definition. > > > > Thanks for that. > > It seems to me that much of the extensive > discussion on Y34 (all of > which I have read) is as much political as > technical, that is SMI is > hierarchical, top down, perhaps befitting its > origins in ISO, whereas > YANG is bottom up. IETF-like. YANG could have had > a single tree, but > doesn't. So when I read > > https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt > > I see a plea for a more hierarchical organisation, > and when I read > > draft-bjorklund-netmod-openconfig-reply-00 > > I see a response that says we are not like that. > > If so, I doubt that there ever will be a technical > solution. > > And I am mindful that when I configure routing in > a (Cisco) router, I > have to do some of it under the interface > definitions and some of it > under the definition of the routing protocol. > Which is life, never > wholy interface-centric and never wholy routing > protocol-centric! > > Are you saying the job would be easier if the > path was /device/interfaces/interface instead > of just /interfaces/interface? Are you saying > that /protocols/routing could not also be defined? > Clearly edit-config and copy-config allow both > subtrees to be accessed in the same operation, > so I don't understand your concern. > > I have been trying to get the root node to be better > defined > in the protocols that use YANG (i.e., ncx:root, Y34-04). > IMO this is a better approach than defining a YANG module > with a special container that all other modules are > expected > to augment. YANG is designed such that each vendor or SDO > is not dependent on other vendors or SDOs in order to > define data nodes. > > > > Andy > > I am agreeing with you that adding 'device' brings no > technical benefit, > rather that the motivation is the opposite of > technical (which I > referred to as political). I am also agreeing with the > current declared > consensus on Y34. > > And yes, YANG is going to give us a large number of > modules, some > tightly coupled (augments) some loosely so (how many > do you need to > configure OSPF?) and work in this area will be of > benefit now and > probably essential in a few years time. That said, I > am unsure what > such work would be like; I am looking (in despair) at > 50 routing area > YANG models and wondering how a user will ever get a > coherent picture of > how to do what they want to do. > > > > The "YANG Land Grab" gives a false sense of progress. > Reaching WG consensus on every single leaf is hard work. > > I don't think a collection of 100s of YANG modules is ever > going to to be easy to understand. Operators will not > examine > a NETCONF message, look at 150 module URIs, > and say "I know exactly what this device supports". > I guess it is up to client tools to do that > > I wrote a draft that defines YANG Packages, which can > provide > a higher level of organization for YANG modules. > > http://datatracker.ietf.org/doc/draft-bierman-netmod-yang-package/ > > You and I are apparently in the minority, since the > official status > is that there is no problem with the current approach, > and no need > to organize individual YANG modules into any larger > abstractions. > > > > Tom Petch > > > > Andy > Andy > > Andy > > The well-specified XPath and YANG root (/) can be > accessed by all protocol operations, exactly > the same > as a node called 'device'. The actual node > name will > depend on the RPC function (e.g. 'data' or > 'config'). > > This is more than redundant however. It > introduces a "super-module" > into YANG that every other module is expected > to augment. > YANG is intended to be more loosely coupled > than that. > This introduces an extra node and namespace > declaration > in all protocol messages, increasing message > sizes. > > It also assumes all existing YANG models will > get rewritten to > account for "/device" in all path and XPath > expressions. > This is highly disruptive to existing deployments. > Also, multiple data models to edit the same > thing causes lots > of extra complexity in the server (supporting > both old > location and new location). > > IMO a resource directory approach is much more > realistic. > The /device tree can contain all the organized > NP containers. > Instead of all the actual data nodes, this > tree just has pointers > to the real location of the resource. (like > 301 Moved Permanently) > > Acee > > Andy > > > ** Solution Y34-02 > > Keep 'anyxml'. Introduce 'anydata' as above but > without the > 'format' substatement. > > 'anyxml' would still be used to represent > unrestricted XML, as is > done in NETCONF. > > 'anydata' would be an unknown chunk of data that > can be modelled > with YANG. Can be encoded as xml or json. > > For example: > > #+BEGIN_EXAMPLE > anydata data; > #+END_EXAMPLE > > ** Solution Y34-05 > > Same as Y34-02 plus two guidelines adopted from > Y34-04: > > - Keep 'anyxml' unchanged as it is defined in YANG > 1.0. This > ensures backward compatibility. > - Introduce a new 'anydata' statement that > represents an unknown > chunk of data that can be modeled with YANG > - Document that implementations MAY have > restrictions for anyxml and > that anyxml is not necessarily interoperable; > data model writers > should use anydata whenever possible. > - The guidelines document should say that YANG > Doctors will review > each use of anyxml in IETF modules when YANG 1.1 > is adopted to > avoid its use whenever possible. > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > --------------010905010405070905020104 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 18/08/2015 18:22, Andy Bierman wrote:


On Tue, Aug 18, 2015 at 9:59 AM, Robert Wilton <rwilton@cisco.com> wrote:


On 11/08/2015 08:38, Ladislav Lhotka wrote:
On 10 Aug 2015, at 22:15, Andy Bierman <andy@yumaworks.com> wrote:



On Mon, Aug 10, 2015 at 12:34 PM, Acee Lindem (acee) <acee@cisco.com> wrote:
I think there is agreement that there is a problem. The YANG Routing Design Team is  addressing this with https://www.ietf.org/id/draft-rtgyangdt-rtgwg-device-model-00.txt  (which has evolved from https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt). In essence, a place for everything and everything in its place. However, there are those who feel that can’t mandate a single model structure for network devices and we need mechanisms to manage multiple models but allow for different device structure (e.g., https://www.ietf.org/id/draft-bierman-netmod-yang-package-00.txt).  I hope we can agree on an approach in the coming interim meetings.


Do you expect "everything in its place" to apply to all other SDOs and
all vendor modules? Or do you expect just the IETF routing modules
to follow this subtree hierarchy? If the former, does this mean the
YANG Routing Design Team is the "YANG data placement authority"
or all YANG modules that ever get written? How long should
it take for all other SDOs and vendors to redo all their existing
modules to re-root them in their assigned place in the data tree?

IMO is is not a good idea to rely on rigid data node placement,
and a single data placement authority. It is better and use meta-data
built from the YANG modules (or YANG packages) instead.
I think that having fixed paths may end up being too restrictive.


This is how languages like SMIv2 and YANG work.
A conceptual object is given a permanent "home" within the tree of object identifiers.
Moving data is very expensive, since any clients working with the old data
will break as soon as the data is moved.

 I am not convinced the IETF can or should come up with a set of containers
that covers every possible topic that can be modeled in YANG.

I mostly agree, but having some more structure/advice as to where to place YANG modules may be helpful.  I'm thinking more along the lines of broad categories rather than precise locations.

E.g. I had suggested that it might be good if the Diffserv QoS YANG model was located in some slightly more abstract QoS containers/choices (e.g. for queuing/shaping/policying/etc).

Mainly my reasoning for this was the observation that vendor specific extensions would probably fit better augmenting generic QoS containers rather than a DiffServ specific QoS model (e.g. if they were adding L2 specific QoS features which wouldn't sit cleanly on top of a specific L3 QoS model).  However, I think that Norman Finn also mentioned a requirement from Deterministic Networking where it may be necessary to interact with some abstract QoS parameters without having to know the precise details of the underlying QoS model.

One other observation is that if we do end up with some more hierarchy then the "can't augment with mandatory node" issue may become a much more widespread issue.  Today, top level models can introduce mandatory nodes, but if they were all augmentations of an existing container they would not be able to (without a P-container).


Even if such a lake could be brought to a boil, I have no confidence
that the hierarchy will be 100% stable.  It can certainly
never be 100% complete.  If the IETF thinks it's a good idea
to obsolete all YANG RFCs and start over now, who is to say
the IETF won't do that again every few years?

My perception is that YANG models and how to fit them together are still somewhat in flux.  There are lots of drafts defining YANG models were folks (myself included) are trying to figure out how these models should all fit together, but relatively few published RFCs.  So, personally I think that there is still a potential opportunity to add some more structure at this time if the desire is strong enough.  But I'm new to IETF, and hence perhaps this is just my naivety of the IETF processes.  Three years down the line and I doubt that will be the case - there will be too much inertia, and unless it is very broken it won't get changed.





The reason Linux uses packages to install/update functionality
is because managing 8000 packages is hard enough.
Managing 247,000 individual files would be insane.
The actual location of files is quite configurable and different
across distros. We could learn something from the last decade
of Linux package management, and try to apply it to YANG.

That’s an interesting idea, could a YANG package also specify, e.g. that the root node for the package is X/Y/Z? This could solve some use cases for relocatability, and it would also be relatively easy to modify all absolute XPath expressions inside the package.
If someone wants to builds a YANG controller node that is managing the configuration for a network of devices then wouldn't they want a particular device's interface configuration to be located somewhere like /network/device/<device-name>/interfaces/interface? Ideally, they would be able to use the same YANG definitions that are defined for /interfaces/ but root them relative to /network/device/<device-name>/.



Yes -- some of us (like Martin) have pointed this out many times.
The "device" container on an NE does not help at all wrt/
aggregation on a controller. "/device" or "/" work the same for this purpose.


Having YANG packages being able to control the relative paths of the imported YANG modules would possibly allow for more flexibility in how YANG modules fit together, and also give a more pragmatic way for how these could be changed/upgraded in future if necessary.



YANG packages provide a way to describe a set of modules.
They do not change the top-level data nodes of any objects.
This would be very complicated and not really worth it.


IMO the "tree of NP containers" should be a resource directory,
meaning it contains links to the real resources.  Kind of like an
index in a library.  They don't keep the contents of every book in the index.
They keep the location of every book in the index.  The index is stable.
The resource location does not have to be stable.
What would the real resource location for "/network/device/<device-name>/interfaces/interface" be?  If the concrete location for all interfaces (regardless of device) was the flat list /interfaces/ then you would get clashes between the names of the interfaces on different devices.  Also, what if someone wanted two separate lists of interfaces in two separate parts of the resource hierarchy.  Would that be feasible?

Thanks,
Rob




 
Cheers,
Rob

Andy
 



Lada





Thanks,
Acee


Andy
 


From: netmod <netmod-bounces@ietf.org> on behalf of "Einar Nilsen-Nygaard (einarnn)" <einarnn@cisco.com>
Date: Monday, August 10, 2015 at 5:29 AM
To: Jonathan Hansford <jonathan@hansfords.net>
Cc: NETMOD Working Group <netmod@ietf.org>
Subject: Re: [netmod] Y34 - root node

As someone sharing responsibilities for guiding a number of development teams both defining new models and implementing to some already defined models in this area, I can only agree with this addition to what I said earlier.

Cheers,

Einar

On Aug 10, 2015, at 9:46 AM, Jonathan Hansford <jonathan@hansfords.net> wrote:

  And it is not just end users who need help to better understand YANG models and how to use them. For those still on the edge, looking to finally take the plunge and use NETCONF/YANG to configure their devices, help is also required to determine how best to structure their YANG models, make use of the existing ones, etc. For those who have "grown up" with the developments in NETCONF and YANG, much of this is probably second nature. But coming to it cold (in the sense of compiling/writing a first set of YANG models for a device; I've been following the netconf/netmod WGs for 3+ years), it still feels very much like a dark art! It is not just the individual modules, it is how to put them together to best manage a device (let alone a system).

Jonathan



----- Original Message -----
From:
"Einar Nilsen-Nygaard (einarnn)" <einarnn@cisco.com>

To:
"Andy Bierman" <andy@yumaworks.com>
Cc:
"NETMOD Working Group" <netmod@ietf.org>
Sent:
Sat, 8 Aug 2015 11:10:15 +0000
Subject:
Re: [netmod] Y34 - root node


Andy,

I agree that there is a need for organization of models, but I don’t have a firm position on draft-openconfig-netmod-model-structure/draft-rtgyangdt-rtgwg-device-model or draft-bierman-netmod-yang-package. But we absolutely need *something* to help end-users of the models comprehend the overall structure of models, their relationship and how to use them.

Cheers,

Einar

On Aug 4, 2015, at 5:16 PM, Andy Bierman <andy@yumaworks.com> wrote:



On Tue, Aug 4, 2015 at 2:34 AM, t.petch <ietfc@btconnect.com> wrote:
----- Original Message -----
From: "Andy Bierman" <andy@yumaworks.com>
To: "t.petch" <ietfc@btconnect.com>
Sent: Monday, August 03, 2015 5:17 PM

----- Original Message -----
From: "Andy Bierman" <andy@yumaworkscom>
To: "t.petch" <ietfc@btconnect.com>
Sent: Monday, August 03, 2015 4:10 PM

----- Original Message -----
From: "Andy Bierman" andy@yumaworks.com
Sent: Saturday, August 01, 2015 7:05 PM
On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem (acee) <acee@cisco.com>

On 8/1/15, 2:51 AM,  j.schoenwaelder@jacobs-university.de> wrote:

Section 1.1 in

https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt
lists the goals of a generic model structure that will accommodate
most
modern network devices. I guess you don’t agree that these are
desirable?

The only objection I have to this draft is the insertion of a
top-level
root
called "device".  (Might as well be called "self").
There are no sibling nodes planned or intended for
this node, so it serves as an extra document root.

<tp>
One aspect of YANG I have never grasped is what a root means, if
anything.

I understand that it is needed for NETCONF (filters) and for YANG
(augments, constraints) and so must be somewhere and must be
relatively
stable, but has it any other significance in the data model?

As you may recall, I was involved with SMI first, where the root is
somewhere up in the sky and life only becomes interesting some six
levels down the hierarchy and that may colour my thinking.

YANG does a poor job of defining the root for YANG data nodes.
It is sometimes called a datastore (in the abstract).
Technically, YANG borrows the definition from XPath.
YANG just defines top-level data nodes and the parent of
these nodes is the document root

There is no protocol or encoding neutral definition,
only an XML-specific definition.

<tp>

Thanks for that.

It seems to me that much of the extensive discussion on Y34 (all of
which I have read) is as much political as technical, that is SMI is
hierarchical, top down, perhaps befitting its origins in ISO, whereas
YANG is bottom up. IETF-like.  YANG could have had a single tree, but
doesn't.  So when I read

https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt

I see a plea for a more hierarchical organisation, and when I read

draft-bjorklund-netmod-openconfig-reply-00

I see a response that says we are not like that.

If so, I doubt that there ever will be a technical solution.

And I am mindful that when I configure routing in a (Cisco) router, I
have to do some of it under the interface definitions and some of it
under the definition of the routing protocol.  Which is life, never
wholy interface-centric and never wholy routing protocol-centric!
Are you saying the job would be easier if the
path was /device/interfaces/interface instead
of just /interfaces/interface?  Are you saying
that /protocols/routing could not also be defined?
Clearly edit-config and copy-config allow both
subtrees to be accessed in the same operation,
so I don't understand your concern.

I have been trying to get the root node to be better defined
in the protocols that use YANG (i.e., ncx:root, Y34-04).
IMO this is a better approach than defining a YANG module
with a special container that all other modules are expected
to augment.  YANG is designed such that each vendor or SDO
is not dependent on other vendors or SDOs in order to
define data nodes.

<tp>

Andy

I am agreeing with you that adding 'device' brings no technical benefit,
rather that the motivation is the opposite of technical (which I
referred to as political). I am also agreeing with the current declared
consensus on Y34.

And yes, YANG is going to give us a large number of modules, some
tightly coupled (augments) some loosely so (how many do you need to
configure OSPF?) and work in this area will be of benefit now and
probably essential in a few years time.  That said, I am unsure what
such work would be like; I am looking (in despair) at 50 routing area
YANG models and wondering how a user will ever get a coherent picture of
how to do what they want to do.



The "YANG Land Grab" gives a false sense of progress.
Reaching WG consensus on every single leaf is hard work.

I don't think a collection of 100s of YANG modules is ever
going to to be easy to understand.  Operators will not examine
a NETCONF <hello> message, look at 150 module URIs,
and say "I know exactly what this device supports".
I guess it is up to client tools to do that

I wrote a draft that defines YANG Packages, which can provide
a higher level of organization for YANG modules.

http://datatracker.ietf.org/doc/draft-bierman-netmod-yang-package/

You and I are apparently in the minority, since the official status
is that there is no problem with the current approach, and no need
to organize individual YANG modules into any larger abstractions.



  Tom Petch



Andy
  Andy

Andy

The well-specified XPath and YANG root (/) can be
accessed by all protocol operations, exactly the same
as a node called 'device'.  The actual node name will
depend on the RPC function (e.g. 'data' or 'config').

This is more than redundant however.  It introduces a "super-module"
into YANG that every other module is expected to augment.
YANG is intended to be more loosely coupled than that.
This introduces an extra node and namespace declaration
in all protocol messages, increasing message sizes.

It also assumes all existing YANG models will get rewritten to
account for "/device" in all path and XPath expressions.
This is highly disruptive to existing deployments.
Also, multiple data models to edit the same thing causes lots
of extra complexity in the server (supporting both old
location and new location).

IMO a resource directory approach is much more realistic.
The /device tree can contain all the organized NP containers.
Instead of all the actual data nodes, this tree just has pointers
to the real location of the resource. (like 301 Moved Permanently)

Acee

Andy

** Solution Y34-02

   Keep 'anyxml'.  Introduce 'anydata' as above but without the
   'format' substatement.

   'anyxml' would still be used to represent unrestricted XML, as is
   done in NETCONF.

   'anydata' would be an unknown chunk of data that can be modelled
   with YANG.  Can be encoded as xml or json.

   For example:

     #+BEGIN_EXAMPLE
     anydata data;
     #+END_EXAMPLE

** Solution Y34-05

    Same as Y34-02 plus two guidelines adopted from Y34-04:

    - Keep 'anyxml' unchanged as it is defined in YANG 1.0. This
      ensures backward compatibility.
    - Introduce a new 'anydata' statement that represents an unknown
      chunk of data that can be modeled with YANG
    - Document that implementations MAY have restrictions for anyxml and
      that anyxml is not necessarily interoperable; data model writers
      should use anydata whenever possible.
    - The guidelines document should say that YANG Doctors will review
      each use of anyxml in IETF modules when YANG 1.1 is adopted to
      avoid its use whenever possible.



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


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


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




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



--------------010905010405070905020104-- From nobody Wed Aug 19 04:26:01 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4181B2A56 for ; Wed, 19 Aug 2015 04:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6omvzNwRRgk for ; Wed, 19 Aug 2015 04:25:58 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E927D1B2A49 for ; Wed, 19 Aug 2015 04:25:57 -0700 (PDT) Received: from localhost (unknown [173.38.220.43]) by mail.tail-f.com (Postfix) with ESMTPSA id E1ED31AE0486; Wed, 19 Aug 2015 13:25:55 +0200 (CEST) Date: Wed, 19 Aug 2015 13:25:55 +0200 (CEST) Message-Id: <20150819.132555.871710491924929960.mbj@tail-f.com> To: rwilton@cisco.com From: Martin Bjorklund In-Reply-To: <55D45CAF.2070605@cisco.com> References: <55D36473.90609@cisco.com> <55D45CAF.2070605@cisco.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Y34 - root node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 11:25:59 -0000 Robert Wilton wrote: > > > On 18/08/2015 18:22, Andy Bierman wrote: > > This is how languages like SMIv2 and YANG work. > > A conceptual object is given a permanent "home" within the tree of > > object identifiers. > > Moving data is very expensive, since any clients working with the old > > data > > will break as soon as the data is moved. > > > > I am not convinced the IETF can or should come up with a set of > > containers > > that covers every possible topic that can be modeled in YANG. > > I mostly agree, but having some more structure/advice as to where to > place YANG modules may be helpful. I'm thinking more along the lines > of broad categories rather than precise locations. +1 > > If someone wants to builds a YANG controller node that is managing > > the configuration for a network of devices then wouldn't they want > > a particular device's interface configuration to be located > > somewhere like /network/device//interfaces/interface? > > Ideally, they would be able to use the same YANG definitions that > > are defined for /interfaces/ but root them relative to > > /network/device//. > > > > > > > > Yes -- some of us (like Martin) have pointed this out many times. > > The "device" container on an NE does not help at all wrt/ > > aggregation on a controller. "/device" or "/" work the same for this > > purpose. Actually, I would argue that / works better. On the controller, you probably have a list of devices you control (this is how our NCS works, and how ODL works (I have been told)): container devices { list device { key name; // meta-info about the device goes here, things like // ip-address, port, auth info... container data { // all models supported by the devices are "mounted" here } } } So on the controller, the path to interface "eth0" on device "foo" would be: /devices/device[name='foo']/data/interfaces/interface[name='eth0'] if we also have a top-level "/device" container we'd have: /devices/device[name='foo']/data/device/interfaces/interface[name='eth0'] > What would the real resource location for > "/network/device//interfaces/interface" be? I don't think there is such a thing as a "real" location. The path is scoped in the system you work with; in the controller it might be as I illustrated above, in the device it starts with /interfaces, but in a controller-of-controllers it might be: /domains/domain[name='bar']/devices/device[name='foo']/data /interfaces/interface[name='eth0'] Currently we have a proprietary way of "relocating" YANG modules, and ODL has its "mount", and I think Andy has some other mechanism. Maybe the time has come to standardize how mount works, and maybe then also standardize the list of devices in a controller model. /martin From nobody Wed Aug 19 05:49:03 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 054361A0389; Wed, 19 Aug 2015 05:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gK5Ri4IVLvaq; Wed, 19 Aug 2015 05:48:59 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCCD71A0155; Wed, 19 Aug 2015 05:48:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1439988481; bh=VAOVeRsCqNGyNLH8APmVy5I5rLs3x+c0efHfhN6MVpE=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=1z4GgwgeTUAD1Nez11jWX5WcLLC/ApoGeexRaekUYk7TWxro94IhphMX3o4IYJvEw rDpuTOPapnOivxFyZyIgchUC3mYAmpjczMznDY0pUgcwfhb3yQxCli3BDslVmY7kJ9 bRvqNId9cdsjDKlYfYcjlZ2wYKrzS1bakW9xXuNQ= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Nadeau Thomas In-Reply-To: <55D3DDFC.2080107@labn.net> Date: Wed, 19 Aug 2015 08:48:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <29B312B3-287D-4E61-8447-CFDF8F6C1734@lucidvision.com> References: <55D3DDFC.2080107@labn.net> To: Berger Lou X-Mailer: Apple Mail (2.2104) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-ShareWhite: 50.255.148.181 X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=18 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181 X-IP-stats: Notspam Incoming Last 0, First 96, in=906, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: Cc: Routing WG , netmod WG , draft-rtgyangdt-rtgwg-device-model@ietf.org Subject: Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 12:49:02 -0000 > On Aug 18, 2015:9:38 PM, at 9:38 PM, Lou Berger = wrote: >=20 > [Adding authors and RTG WG.] >=20 > Hi Andy, > I'm not sure who you are looking to hear from as you addressed this > mail to the netmod list. I'm happy to give my opinion as it seems you > might have been aiming this at the draft authors. (but then again > perhaps not.)=20 >=20 > On 8/18/2015 8:01 PM, Andy Bierman wrote: >> Hi, >>=20 >> I assume this draft is what we should be reviewing and not >> the obsolete openconfig draft? >=20 > My personal view / hope is that the openconfig draft will be revised = to > cover requirements Can you be specific about which requirements you feel are not = covered ? =97Tom > while the DT draft leads to an agreed upon approach > to addressing those requirements. Again, just stating my view, not = the > view of the DT, co-authors or OC draft authors. >=20 >>=20 >>=20 >> https://tools.ietf.org/html/draft-rtgyangdt-rtgwg-device-model-00 >>=20 >>=20 >> Q1) scope >>=20 >>=20 >> sec 2: >>=20 >> The model organization can itself be thought of as a "meta-model", >> in that it describes the relationships between individual models. = We >> choose to represent it also as simple YANG model consisting of = lists >> and containers to serve as anchor points for the corresponding >> individual models. >>=20 >> As shown below, our model is rooted at a "device", which represents = a >> network router, switch, or similar network element. =20 >>=20 >>=20 >> Why is this a meta-model? > because the aim to to show how other models inter-relate rather than > define the details of all models. As stated in the intro: >=20 > This document aims to provide an extensible structure that can be > used to tie together other models. It allows for existing, emerging, > and future models. The overall structure can be constructed using > YANG augmentation and imports. >=20 >=20 >> It looks like a real YANG data model where ad-hoc classification is >> being done >> using container names. >=20 > Sure, we're using YANG, or at least trying, to document our proposal.=20= > Do you think there's a better way to formally document the work? >=20 >>=20 >> If vendors augment this tree with their own ad-hoc hierarchy, then = how >> is this >> any better than what we have now? >>=20 > This goes to requirements which is really in the scope of > draft-openconfig-netmod-model-structure. =46rom my perspective it = comes > down to how much information is needed from an actual device in order = to > come up with its yang-based configuration, and the principle that = there > is benefit in this being minimized. For example, consider the case > where a config is generated before a specific device is fielded or > perhaps even purchased/selected. But again, this more of a = requirements > discussion. >=20 >> What is the scope of this work? > see slide 7 of > https://www.ietf.org/proceedings/93/slides/slides-93-rtgwg-3.pdf >=20 >> It appears to be only for "routers switches or similar network = elements". >>=20 >> =46rom the slide: > =46rom DT charter: An overall architecture for > =93the protocols and functionality contained inside the Routing = Area=94 >=20 >> The hierarchy seems quite router-centric. > It is intended to be network device centric, routers, switches, > firewalls, etc. >=20 >> Is the expectation that all YANG-based devices will use this >> data hierarchy, or only some devices? > The proposal is to provide a framework for any device that supports a > protocol or other mechanism defined within the routing area. (Or at > least that's our understanding of what we were asked to do.) >=20 >>=20 >> Is the expectation that all YANG modules will use this >> data hierarchy, or only some modules?=20 >=20 > I personally think there will be siblings to /device, e.g., /service - > but this is beyond the scope of this draft. >=20 >> Is it just >> for IETF routing modules or more than that? >>=20 > I think this is the same question and answer as above. >=20 >> Q2) interfaces >>=20 >> The interface model is taken from [RFC7223 = ] and includes possible >> technology-specific augmentations using example technologies = defined >> in [RFC7277 ]. >> +--rw interfaces >> | +--rw interface* [name] >> | +--rw name string >> | +--rw bind-network-element-id? uint8 >> | +--rw ethernet >> | | +--rw bind-networking-instance-name? string >> | | +--rw aggregates >> | | +--rw rstp >> | | +--rw lldp >> | | +--rw ptp >> | +--rw vlans >> | +--rw tunnels >> | +--rw ipv4 >> | | +--rw bind-networking-instance-name? string >> | | +--rw arp >> | | +--rw icmp >> | | +--rw vrrp >> | | +--rw dhcp-client >> | +--rw ipv6 >> | +--rw bind-networking-instance-name? string >> | +--rw vrrp >> | +--rw icmpv6 >> | +--rw nd >> | +--rw dhcpv6-client >>=20 >>=20 >> Actually the interface model is quite different than the one in RFC = 7223. >> Seems rather ethernet-centric. I notice the "type" leaf was removed, >> along with everything else. Is the plan to toss out RFC 7223, >> recharter the interfaces work, and start over? >>=20 >=20 > So this may be our/my inexperience at play here. I didn't think it > appropriate for a document that is augmenting an existing model to > redefine the current model - I actually thought this was part of the > power of YANG augmentation. Are you saying we should have included = the > whole 7223 model to augment it, or something different? >=20 > Also not the text says: > ... possible technology-specific augmentations using example > technologies .. > and >=20 > The interfaces container includes a number of commonly used > components as examples: >=20 >> Q3) virtual devices >>=20 >> The model supports the potentially independent system management >> functions and configuration per logical network element. This >> permits, for example, different users to manage either the whole >> device or just the associated logical network element.=20 >>=20 >> Sec 2.2.1 shows the system management tree but it is wrong. >=20 > Yes, good catch of a cut-and-past bug. thankfully it is correct both > immediately before in the section intro and the details >=20 >> The following tree is what the YANG model defines: >> +--rw device >> +--rw logical-network-elements >> -rw logical-network-element* [network-element-id] >> +--rw network-element-id uint8 >> +--rw network-element-name? string >> +--rw default-networking-instance-name? string >> +--rw system-management >> | +--rw device-view? boolean >> | +--rw syslog >> | +--rw dns >> | +--rw ntp >> | +--rw statistics-collection >> | +--rw ssh >> | +--rw tacacs >> | +--rw snmp >> | +--rw netconf >> What about devices that do not have logical network elements? > It would have only a single network-element-id >=20 >> This hierarchy may be appropriate for very large routers >> but nothing else. > The intent is to cover all implementations independent of vendors. We > had a good range of view points both in the DT and in the RTGWG > discussion. Not saying there was full agreement, just that we have a > proposed starting point. >=20 >> How can this tree represent both the physical view and the virtual = view? > Are you referring to section 2.3? If so, I think we all agree (and = said > as much in Prague) that this section could be clearer. We/I tried to > explain it in the Prague slide 25 (for this you may want to see the > animation in > https://www.ietf.org/proceedings/93/slides/slides-93-rtgwg-3.pptx) >=20 > Basically the amount of information provided depends on the > logical-network-element context used to access this information. So = if > a model is "retrieved" via an IP address associated with a > network-element-id with device-view=3Dtrue (e.g., the left side of = slide > 25), then the device's full view is provided. And when a model is > "retrieved" via an IP address associated with a network-element-id = with > device-view=3Dfalse (e.g., the ride side of slide 25, either color) = only > information related to the network-element-id is provided. >=20 >> It seems to assume this is the "root user physical view". >> Please explain how device-type=3DVIRTUAL is used. >=20 > This is a bit different and hasn't been a major point of discussion in > the WG -- we brought this over from the openconfig draft. I read this > as being pretty uninteresting and simply set based on if the device is > running on dedicated special purpose h/w (e.g, a classic > "name-your-vendor" router) or as a VM (aka NFV). I'll defer to the OC > or other DT folks if their opinion differs. >=20 > Thanks for the comments/discussion! >=20 > Lou >=20 >> Andy >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Aug 19 05:49:18 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 319411A039B for ; Wed, 19 Aug 2015 05:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-G0gLgaR4ot for ; Wed, 19 Aug 2015 05:49: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 246A11A03C7 for ; Wed, 19 Aug 2015 05:49:03 -0700 (PDT) Received: from localhost (unknown [173.38.220.43]) by mail.tail-f.com (Postfix) with ESMTPSA id 5A1611AE0486; Wed, 19 Aug 2015 14:49:01 +0200 (CEST) Date: Wed, 19 Aug 2015 14:49:00 +0200 (CEST) Message-Id: <20150819.144900.231414608010857635.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <9B232151-C380-4B43-BAF4-88F7E4821B8D@nic.cz> References: <154527D1-C76B-49DD-B58D-39B197FAD033@nic.cz> <9B232151-C380-4B43-BAF4-88F7E4821B8D@nic.cz> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] extensions and conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 12:49:08 -0000 Hi, [joining this discussion a bit late] Ladislav Lhotka wrote: > > > On 10 Aug 2015, at 18:46, Andy Bierman wrote: > > > > > > > > On Mon, Aug 10, 2015 at 9:37 AM, Ladislav Lhotka > > wrote: > > > > > On 10 Aug 2015, at 17:32, Andy Bierman wrote: > > > > > > > > > > > > On Mon, Aug 10, 2015 at 4:24 AM, Ladislav Lhotka > > > wrote: > > > > > > > On 10 Aug 2015, at 12:17, Andy Bierman wrote: > > > > > > > > Hi, > > > > > > > > I am strongly against changing the contract on extensions. > > > > They MAY be ignored by any YANG tool. Period. > > > > That means they are far from mandatory. > > > > They are little more than a keyword and a description clause. > > > > > > So do you prefer my proposed solution -02 or -03? > > > > > > ** Solution Yxx-03 > > > > > > Make extensions optional. This means that extensions won't be > > > allowed to change YANG language, NETCONF protocol, and validity of > > > datastores and protocol messages. > > > > > > > > > This is how we use extensions to tag YANG data models > > > to drive automation tools. > > > > But that means, for example, that annotations cannot be defined via an > > extension statement as in draft-ietf-netmod-yang-metadata. > > > > > > > > Which means these statements should be real instead of extensions. > > If the statements are defining data that is exchanged between > > peers in a standard protocol, then YANG extensions are not > > appropriate. > > I agree, and -03 is my preferred solution, too. I strongly disagree. IMO the IETF usage of extensions so far (NACM, annotations) works well (in the case of NACM proven by multiple independent implementations), and follows how extensions were intended to be used, and obviously, how the WG has understood them up until now. If the sentence: If a YANG compiler does not support a particular extension, which appears in a YANG module as an unknown-statement (see Section 12), the entire unknown-statement MAY be ignored by the compiler. in 6020 can be interpreted to mean that an occurance of an extension is non-normative, we should fix it so that it matches what was intended and how it is used. Juergen suggested this replacement text, which I support. Maybe it can be improved even more. If a YANG parser does not support a particular extension, which appears in a YANG module as an unknown-statement (see Section 13), the entire unknown-statement MAY be ignored by the parser. Note that even in this case the semantics associated with the extension still apply (as if they were part of a description statement). However, I do agree that an extension cannot "undo" semantics defined by other YANG statements, just as you cannot do that in a description statement. For example, this would be illegal: leaf foo { type int32; description "The type is really a string."; } leaf bar { type int32; xx:real-type string; } It is also a Very Bad Idea (speaking from experience...) to define an extension that introduces new data nodes. The text about "MAY ignore" was meant to capture this. It's supposed to be like for a client that doesn't understand an augemntation; it can skip it. A client that doesn't understand nacm:default-deny-all works just fine and can safely ignore it. /martin From nobody Wed Aug 19 05:54:30 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5451A033B; Wed, 19 Aug 2015 05:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RZpy13iM-ER; Wed, 19 Aug 2015 05:54:23 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A73BF1A19F7; Wed, 19 Aug 2015 05:54:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1439988805; bh=nBd5hgN4yo/VrC6olOG1CSlmayzBNwTASblX5MV8N/A=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=jsP14KzwaAkOVOotwCoS/+G17/0LcJFUAXcOMNkBfJALqBxlInxZZAYAQ54dTJ4AA +z0p+6RVwkhF2rIreJuKyM4jo2Ij4sCjpBKEnjNTFsGWdhrCA9kgFgZBUvUrkMqBTf JpFifpRe+V41beXOdWXOrJ9gkJ+gxXoc8Z3bAoqE= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; Content-Type: multipart/alternative; boundary="Apple-Mail=_F5D72636-8428-4155-91B9-2211C0188B95" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Nadeau Thomas In-Reply-To: Date: Wed, 19 Aug 2015 08:54:19 -0400 Message-Id: <62C72DA8-A6D9-402E-A4E7-4677E9422DC4@lucidvision.com> References: <55D3DDFC.2080107@labn.net> To: Andy Bierman X-Mailer: Apple Mail (2.2104) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-ShareWhite: 50.255.148.181 X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=19 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181 X-IP-stats: Notspam Incoming Last 0, First 96, in=907, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: Cc: netmod WG , draft-rtgyangdt-rtgwg-device-model@ietf.org, Routing WG Subject: Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 12:54:28 -0000 --Apple-Mail=_F5D72636-8428-4155-91B9-2211C0188B95 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 18, 2015:11:04 PM, at 11:04 PM, Andy Bierman = wrote: >=20 >=20 >=20 > On Tue, Aug 18, 2015 at 6:38 PM, Lou Berger > wrote: > [Adding authors and RTG WG.] >=20 > Hi Andy, > I'm not sure who you are looking to hear from as you addressed = this > mail to the netmod list. I'm happy to give my opinion as it seems you > might have been aiming this at the draft authors. (but then again > perhaps not.) >=20 >=20 > Tom sent the meeting invite to netmod so I figured that was where we = were > supposed to discuss drafts. The meeting invite was to get peoples=E2=80=99 attention and ask = that people start planning ahead. However, please discuss here ahead of time.=20 >=20 > On 8/18/2015 8:01 PM, Andy Bierman wrote: > > Hi, > > > > I assume this draft is what we should be reviewing and not > > the obsolete openconfig draft? >=20 > My personal view / hope is that the openconfig draft will be revised = to > cover requirements while the DT draft leads to an agreed upon = approach > to addressing those requirements. Again, just stating my view, not = the > view of the DT, co-authors or OC draft authors. >=20 >=20 > Sort of confusing because this draft says it is based on the other = draft, > so one assumes it is meant to replace it. >=20 >=20 > =20 > > > > > > https://tools.ietf.org/html/draft-rtgyangdt-rtgwg-device-model-00 = > > > > > > Q1) scope > > > > > > sec 2: > > > > The model organization can itself be thought of as a = "meta-model", > > in that it describes the relationships between individual models. = We > > choose to represent it also as simple YANG model consisting of = lists > > and containers to serve as anchor points for the corresponding > > individual models. > > > > As shown below, our model is rooted at a "device", which = represents a > > network router, switch, or similar network element. > > > > > > Why is this a meta-model? > because the aim to to show how other models inter-relate rather than > define the details of all models. As stated in the intro: >=20 > This document aims to provide an extensible structure that can be > used to tie together other models. It allows for existing, = emerging, > and future models. The overall structure can be constructed using > YANG augmentation and imports. >=20 >=20 > OK -- the YANG modules themselves should say how they > relate to each other. I guess you mean the logical-network-element > and other framework nodes. >=20 >=20 >=20 > > It looks like a real YANG data model where ad-hoc classification is > > being done > > using container names. >=20 > Sure, we're using YANG, or at least trying, to document our proposal. > Do you think there's a better way to formally document the work? >=20 >=20 >=20 > So this document is not the actual set of NP containers > that all YANG modules are supposed to augment? > It would help to understand how the tree will be managed > and maintained over time. >=20 >=20 > > > > If vendors augment this tree with their own ad-hoc hierarchy, then = how > > is this > > any better than what we have now? > > > This goes to requirements which is really in the scope of > draft-openconfig-netmod-model-structure. =46rom my perspective it = comes > down to how much information is needed from an actual device in order = to > come up with its yang-based configuration, and the principle that = there > is benefit in this being minimized. For example, consider the case > where a config is generated before a specific device is fielded or > perhaps even purchased/selected. But again, this more of a = requirements > discussion. >=20 > If a vendor has their own proprietary protocol or HW type, > where does it go in the tree? The set of modules used for some > function may not be coupled to one node in the data tree.=20 Its useful if these sorts of things are added to the = requirements. > But it is OK if this is out of scope. > It is no different than any other standard module that a vendor > could augment with proprietary data. >=20 > =20 > > What is the scope of this work? > see slide 7 of > https://www.ietf.org/proceedings/93/slides/slides-93-rtgwg-3.pdf = >=20 > > It appears to be only for "routers switches or similar network = elements". > > > >=46rom the slide: > =46rom DT charter: An overall architecture for > =E2=80=9Cthe protocols and functionality contained inside the = Routing Area=E2=80=9D >=20 > > The hierarchy seems quite router-centric. > It is intended to be network device centric, routers, switches, > firewalls, etc. >=20 > So what is the plan for YANG modules that are not specific to these = devices? > For example, some modules like interfaces and NACM could be > implemented on any platform, even constrained devices=20 > (maybe running CoMI over CoAP).=20 Again, good to add to the requirements document. Backwards = compatability is something we must address; we are unlikely to go forward with a plan that = obsoletes everything that exists today - or at least without a plan to move those things = forward. > > Is the expectation that all YANG-based devices will use this > > data hierarchy, or only some devices? > The proposal is to provide a framework for any device that supports a > protocol or other mechanism defined within the routing area. (Or at > least that's our understanding of what we were asked to do.) >=20 >=20 >=20 > I understand the value of finding data via familiar keywords. > (The CLI never went away -- it just grew angle brackets ;-) > It is useful to be able to debug with nothing more than a > WEB browser and URLs typed by hand. I could never remember > a single SNMP OID but YANG data is easy to remember. >=20 > =46rom the start, the NETCONF and NETMOD WGs rejected > attempts at data organization because it should not matter > to a programmatic API. It does not matter technically speaking, but I think the thing = the operators are saying here is that if its organized in this specific way, it not = only makes their lives easier, it allows them to do things better/less expensively. = That seems important. >=20 > > > > Is the expectation that all YANG modules will use this > > data hierarchy, or only some modules? >=20 > I personally think there will be siblings to /device, e.g., /service - > but this is beyond the scope of this draft. >=20 > > Is it just > > for IETF routing modules or more than that? > > > I think this is the same question and answer as above. >=20 > > Q2) interfaces > > > > The interface model is taken from [RFC7223 = >] and includes possible > > technology-specific augmentations using example technologies = defined > > in [RFC7277 >]. > > +--rw interfaces > > | +--rw interface* [name] > > | +--rw name string > > | +--rw bind-network-element-id? uint8 > > | +--rw ethernet > > | | +--rw bind-networking-instance-name? string > > | | +--rw aggregates > > | | +--rw rstp > > | | +--rw lldp > > | | +--rw ptp > > | +--rw vlans > > | +--rw tunnels > > | +--rw ipv4 > > | | +--rw bind-networking-instance-name? string > > | | +--rw arp > > | | +--rw icmp > > | | +--rw vrrp > > | | +--rw dhcp-client > > | +--rw ipv6 > > | +--rw bind-networking-instance-name? string > > | +--rw vrrp > > | +--rw icmpv6 > > | +--rw nd > > | +--rw dhcpv6-client > > > > > > Actually the interface model is quite different than the one in RFC = 7223. > > Seems rather ethernet-centric. I notice the "type" leaf was = removed, > > along with everything else. Is the plan to toss out RFC 7223, > > recharter the interfaces work, and start over? > > >=20 > So this may be our/my inexperience at play here. I didn't think it > appropriate for a document that is augmenting an existing model to > redefine the current model - I actually thought this was part of the > power of YANG augmentation. Are you saying we should have included = the > whole 7223 model to augment it, or something different? >=20 >=20 > I did not find any augment statements in model-structure.yang. >=20 > You have to augment /interfaces, not /device/interfaces, > if you are using RFC 7223. >=20 >=20 >=20 > Also not the text says: > ... possible technology-specific augmentations using example > technologies .. > and >=20 > The interfaces container includes a number of commonly used > components as examples: >=20 > > Q3) virtual devices > > > > The model supports the potentially independent system management > > functions and configuration per logical network element. This > > permits, for example, different users to manage either the whole > > device or just the associated logical network element. > > > > Sec 2.2.1 shows the system management tree but it is wrong. >=20 > Yes, good catch of a cut-and-past bug. thankfully it is correct both > immediately before in the section intro and the details >=20 > > The following tree is what the YANG model defines: > > +--rw device > > +--rw logical-network-elements > > -rw logical-network-element* [network-element-id] > > +--rw network-element-id uint8 > > +--rw network-element-name? string > > +--rw default-networking-instance-name? string > > +--rw system-management > > | +--rw device-view? = boolean > > | +--rw syslog > > | +--rw dns > > | +--rw ntp > > | +--rw statistics-collection > > | +--rw ssh > > | +--rw tacacs > > | +--rw snmp > > | +--rw netconf > > What about devices that do not have logical network elements? > It would have only a single network-element-id >=20 > > This hierarchy may be appropriate for very large routers > > but nothing else. > The intent is to cover all implementations independent of vendors. We > had a good range of view points both in the DT and in the RTGWG > discussion. Not saying there was full agreement, just that we have a > proposed starting point. >=20 > > How can this tree represent both the physical view and the virtual = view? > Are you referring to section 2.3? If so, I think we all agree (and = said > as much in Prague) that this section could be clearer. We/I tried to > explain it in the Prague slide 25 (for this you may want to see the > animation in > https://www.ietf.org/proceedings/93/slides/slides-93-rtgwg-3.pptx = ) >=20 > Basically the amount of information provided depends on the > logical-network-element context used to access this information. So = if > a model is "retrieved" via an IP address associated with a > network-element-id with device-view=3Dtrue (e.g., the left side of = slide > 25), then the device's full view is provided. And when a model is > "retrieved" via an IP address associated with a network-element-id = with > device-view=3Dfalse (e.g., the ride side of slide 25, either color) = only > information related to the network-element-id is provided. >=20 >=20 >=20 > IMO this logical structure should not be part of data hierarchy = itself, > since it does not apply to all devices. This is an important issue to get to the bottom of. Is this in = the requirements? > YANG does not provide a way for the hierarchy to be > one way for the physical view and another for > a virtual view. The same /path/to/data is seen by both. > Is this really what you want? Please add (or not) to the requirements. >=20 > =20 > > It seems to assume this is the "root user physical view". > > Please explain how device-type=3DVIRTUAL is used. >=20 > This is a bit different and hasn't been a major point of discussion in > the WG -- we brought this over from the openconfig draft. I read this > as being pretty uninteresting and simply set based on if the device is > running on dedicated special purpose h/w (e.g, a classic > "name-your-vendor" router) or as a VM (aka NFV). I'll defer to the OC > or other DT folks if their opinion differs. >=20 > Each virtual view sees its own slice of the physical device as an > entire device, not as 1 entry in a more complex model. >=20 > IMO it would be better to define a separate data structure and > tag it as a special nested datastore root. (e.g. YANG mount). >=20 > Maybe this would work: >=20 > container virtual-devices { > list virtual-device { > key device-id; > ... > container device { > // same data models as the /device contents > } > } > } >=20 > container device { ... } >=20 >=20 >=20 > Thanks for the comments/discussion! >=20 > Lou >=20 > > Andy > > >=20 >=20 > Andy It seems there are a number of things that should be teased out = here as issues that we can come to a consensus on. Some of these things do not appear in the requirements. = Can we get those in there if we agree on them? The others we could track as issues. =E2=80=94Tom > =20 > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod = >=20 >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --Apple-Mail=_F5D72636-8428-4155-91B9-2211C0188B95 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Aug 18, 2015:11:04 PM, at 11:04 PM, Andy Bierman <andy@yumaworks.com> = wrote:



On Tue, Aug 18, 2015 at 6:38 PM, = Lou Berger <lberger@labn.net> wrote:
[Adding authors and = RTG WG.]

Hi Andy,
    I'm not sure who you are looking to hear from as you = addressed this
mail to the netmod list. I'm happy to give my opinion as it seems you
might have been aiming this at the draft authors.  (but then = again
perhaps not.)


Tom sent the meeting invite to netmod so I figured that was = where we were
supposed to discuss = drafts.

= The meeting invite was to get peoples=E2=80=99 attention = and ask that people start planning ahead.
However, please = discuss here ahead of time. 


On 8/18/2015 8:01 PM, Andy Bierman wrote:
> Hi,
>
> I assume this draft is what we should be reviewing and not
> the obsolete openconfig draft?

My personal view / hope is that the openconfig draft will be revised = to
cover requirements while the DT draft  leads to an agreed upon = approach
to addressing those requirements.  Again, just stating my view, not = the
view of the DT, co-authors or OC draft authors.


Sort of confusing because this draft says it is based on the = other draft,
so one assumes it is meant to replace = it.


 
>
>
> https://tools.ietf.org/html/draft-rtgyangdt-rtgwg-device-model-= 00
>
>
> Q1) scope
>
>
> sec 2:
>
>    The model organization can itself be thought of as a = "meta-model",
>    in that it describes the relationships between = individual models.  We
>    choose to represent it also as simple YANG model = consisting of lists
>    and containers to serve as anchor points for the = corresponding
>    individual models.
>
>    As shown below, our model is rooted at a "device", = which represents a
>    network router, switch, or similar network element.
>
>
> Why is this a meta-model?
because the aim to to show how other models inter-relate rather than
define the details of all models. As stated in the intro:

   This document aims to provide an extensible structure that = can be
   used to tie together other models. It allows for existing, = emerging,
   and future models. The overall structure can be constructed = using
   YANG augmentation and imports.


OK -- the YANG modules themselves should say how = they
relate to each other.  I guess you mean = the logical-network-element
and = other framework nodes.



> It looks like a real YANG data model where ad-hoc classification = is
> being done
> using container names.

Sure, we're using YANG, or at least trying, to document our proposal.
Do you think there's a better way to formally document the work?



So this document is not = the actual set of NP containers
that all YANG = modules are supposed to augment?
It would help to = understand how the tree will be managed
and = maintained over time.


>
> If vendors augment this tree with their own ad-hoc hierarchy, then = how
> is this
> any better than what we have now?
>
This goes to requirements which is really in the scope of
draft-openconfig-netmod-model-structure.  =46rom my perspective it = comes
down to how much information is needed from an actual device in order = to
come up with its yang-based configuration, and the principle that = there
is benefit in this being minimized.  For example, consider the = case
where a config is generated before a specific device is fielded or
perhaps even purchased/selected. But again, this more of a = requirements
discussion.

If a vendor has their own proprietary = protocol or HW type,
where does it go in the = tree?  The set of modules used for some
function= may not be coupled to one node in the data = tree. 

= Its useful if these sorts of things are added to the = requirements.

But it is OK if this is out of = scope.
It is no different than any other standard = module that a vendor
could augment with proprietary = data.

 
> What is the scope of this work?
see slide 7 of
https://www.ietf.org/proceedings/93/slides/slides-93-rtgwg-3.pd= f

> It appears to be only for "routers switches or similar network = elements".
>
>=46rom the slide:
   =46rom DT charter: An overall architecture for
=    =E2=80=9Cthe protocols and functionality contained inside = the Routing Area=E2=80=9D

> The hierarchy seems quite router-centric.
It is intended to be network device centric, routers, switches,
firewalls, etc.

So what is the plan for YANG modules = that are not specific to these devices?
For = example, some modules like interfaces and NACM could be
implemented on any platform, even constrained = devices 
(maybe running CoMI over = CoAP). 

= Again, good to add to the requirements document. =  Backwards compatability is something
we must address; we = are unlikely to go forward with a plan that obsoletes = everything
that exists today - or at least without a plan to = move those things forward.

> Is the expectation that all YANG-based = devices will use this
> data hierarchy, or only some devices?
The proposal is to provide a framework for any device that supports a
protocol or other mechanism defined within the routing area.  (Or = at
least that's our understanding of what we were asked to do.)



I understand the value = of finding data via familiar keywords.
(The CLI = never went away -- it just grew angle brackets ;-)
It= is useful to be able to debug with nothing more than a
WEB browser and URLs typed by hand. I could never = remember
a single SNMP OID but YANG data is easy to = remember.

=46rom= the start, the NETCONF and NETMOD WGs rejected
attempts at data organization because it should not = matter
to a programmatic = API.

It does not matter technically = speaking, but I think the thing the operators
are saying here = is that if its organized in this specific way, it not only = makes
their lives easier, it allows them to do things = better/less expensively.  That
seems important.


>
> Is the expectation that all YANG modules will use this
= > data hierarchy, or only some modules?

I personally think there will be siblings to /device, e.g., /service = -
but this is beyond the scope of this draft.

> Is it just
> for IETF routing modules or more than that?
>
I think this is the same question and answer as above.

> Q2) interfaces
>
>    The interface model is taken from [RFC7223 <https://tools.ietf.org/html/rfc7223>] = and includes possible
>    technology-specific augmentations using example = technologies defined
>    in [RFC7277 <https://tools.ietf.org/html/rfc7277>].
>   +--rw interfaces
>       |  +--rw interface* [name]
>       |     +--rw name  =                     =  string
>       |     +--rw = bind-network-element-id?   uint8
>       |     +--rw ethernet
>       |     |  +--rw = bind-networking-instance-name?   string
>       |     |  +--rw = aggregates
>       |     |  +--rw = rstp
>       |     |  +--rw = lldp
>       |     |  +--rw ptp
>       |     +--rw vlans
>       |     +--rw tunnels
>       |     +--rw ipv4
>       |     |  +--rw = bind-networking-instance-name?   string
>       |     |  +--rw arp
>       |     |  +--rw = icmp
>       |     |  +--rw = vrrp
>       |     |  +--rw = dhcp-client
>       |     +--rw ipv6
>       |        +--rw = bind-networking-instance-name?   string
>       |        +--rw = vrrp
>       |        +--rw = icmpv6
>       |        +--rw nd
>       |        +--rw = dhcpv6-client
>
>
> Actually the interface model is quite different than the one in RFC = 7223.
> Seems rather ethernet-centric.  I notice the "type" leaf was = removed,
> along with everything else.  Is the plan to toss out RFC = 7223,
> recharter the interfaces work, and start over?
>

So this may be our/my inexperience at play here.  I didn't think = it
appropriate for a document that is augmenting an existing model to
redefine the current model - I actually thought this was part of the
power of YANG augmentation.  Are you saying we should have included = the
whole 7223 model to augment it, or something different?


 I did not find any = augment statements in model-structure.yang.

You have to augment /interfaces, not = /device/interfaces,
if you are using RFC = 7223.



Also not the text says:
        ... possible technology-specific = augmentations  using example
technologies ..
and

   The interfaces container includes a number of commonly = used
   components as examples:

> Q3) virtual devices
>
>    The model supports the potentially independent system = management
>    functions and configuration per logical network = element. This
>    permits, for example, different users to manage either = the whole
>    device or just the associated logical network = element.
>
> Sec 2.2.1 shows the system management tree but it is wrong.

Yes, good catch of a cut-and-past bug. thankfully it is correct both
immediately before in the section intro and the details

> The following tree is what the YANG model defines:
>  +--rw device
>           +--rw = logical-network-elements
>                -rw = logical-network-element* [network-element-id]
>                  =   +--rw network-element-id            =       uint8
>                  =   +--rw network-element-name?          =      string
>                  =   +--rw default-networking-instance-name?   string
>                  =   +--rw system-management
>                  =   |  +--rw device-view?          =             boolean
>                  =   |  +--rw syslog
>                  =   |  +--rw dns
>                  =   |  +--rw ntp
>                  =   |  +--rw statistics-collection
>                  =   |  +--rw ssh
>                  =   |  +--rw tacacs
>                  =   |  +--rw snmp
>                  =   |  +--rw netconf
> What about devices that do not have logical network elements?
It would have only a single network-element-id

> This hierarchy may be appropriate for very large routers
> but nothing else.
The intent is to cover all implementations independent of vendors.  = We
had a good range of view points both in the DT and in the RTGWG
discussion.  Not saying there was full agreement, just that we have = a
proposed starting  point.

> How can this tree represent both the physical view and the virtual = view?
Are you referring to section 2.3?  If so, I think we all agree (and = said
as much in Prague) that this section could be clearer.  We/I tried = to
explain it in the Prague slide 25 (for this you may want to see the
animation in
https://www.ietf.org/proceedings/93/slides/slides-93-rtgwg-3.pp= tx)

Basically the amount of information provided depends on the
= logical-network-element context used to access this information.  = So if
a model is "retrieved" via an IP address associated with a
network-element-id  with device-view=3Dtrue (e.g., the left side of = slide
25), then the device's full view is provided.  And when a model = is
"retrieved" via an IP address associated with a network-element-id  = with
device-view=3Dfalse (e.g., the ride side of slide 25, either color) = only
information related to the network-element-id is provided.



IMO this logical = structure should not be part of data hierarchy itself,
since it does not apply to all = devices.

= This is an important issue to get to the bottom of. =  Is this in the
requirements?

YANG does not provide a way for the hierarchy to be
one way for the physical view and another for
a virtual view. The same /path/to/data is seen by = both.
Is this really what you = want?

Please add (or not) to the = requirements.


 
> It seems to assume this is the "root user physical view".
> Please explain how device-type=3DVIRTUAL is used.

This is a bit different and hasn't been a major point of discussion = in
the WG -- we brought this over from the openconfig draft.  I read = this
as being pretty uninteresting and simply set based on if the device = is
running on dedicated special purpose h/w (e.g, a classic
"name-your-vendor" router) or as a VM (aka NFV).  I'll defer to the = OC
or other DT folks if their opinion differs.

Each virtual view sees its own slice of the physical device = as an
entire device, not as 1 entry in a more = complex model.

IMO it would be better to define a separate data structure = and
tag it as a special nested datastore root. =  (e.g. YANG mount).

Maybe this would work:

  container virtual-devices = {
     list virtual-device = {
        key = device-id;
        = ...
        container device = {
            // same = data models as the /device contents
    =      }
    =  }
  }

  container device { ... = }



Thanks for the comments/discussion!

Lou

> Andy
>


Andy

= It seems there are a number of things that should be = teased out here as issues that we can come to a
consensus on. =  Some of these things do not appear in the requirements. Can we get = those in there
if we agree on them?  The others we could = track as issues.

= =E2=80=94Tom


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


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

= --Apple-Mail=_F5D72636-8428-4155-91B9-2211C0188B95-- From nobody Wed Aug 19 05:55:57 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4817B1A8A56 for ; Wed, 19 Aug 2015 05:55:56 -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 jehkHfQ75hGF for ; Wed, 19 Aug 2015 05:55:54 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D645D1A8AFC for ; Wed, 19 Aug 2015 05:55:53 -0700 (PDT) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 72F9018134A; Wed, 19 Aug 2015 14:55:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1439988952; bh=zYOLXgn5haXHjSMvqkWBQCQ6j3+2dtP2gE7CiCjbOnM=; h=From:Date:To; b=FJTcI75JOzFOmyTUTPC6zRC77qhdFKrOw9Mx8AjYGYPTcp9800/HnPIrVfpLDp8Td B+JPiSdsgLgOn+o21y2NMjO2CvFeU7EY5AYakCl7+cFblxnAys6Auf/y6qud0ul6m0 syrAI8qKKqO40MdeDIpjtVl7zMGlVx3f5IojJ7GY= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: <20150819.132555.871710491924929960.mbj@tail-f.com> Date: Wed, 19 Aug 2015 14:55:52 +0200 Content-Transfer-Encoding: 7bit Message-Id: <500BB0F6-69CF-4A14-A649-83E4BC03E920@nic.cz> References: <55D36473.90609@cisco.com> <55D45CAF.2070605@cisco.com> <20150819.132555.871710491924929960.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Y34 - root node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 12:55:56 -0000 > On 19 Aug 2015, at 13:25, Martin Bjorklund wrote: > > Robert Wilton wrote: >> >> >> On 18/08/2015 18:22, Andy Bierman wrote: >>> This is how languages like SMIv2 and YANG work. >>> A conceptual object is given a permanent "home" within the tree of >>> object identifiers. >>> Moving data is very expensive, since any clients working with the old >>> data >>> will break as soon as the data is moved. >>> >>> I am not convinced the IETF can or should come up with a set of >>> containers >>> that covers every possible topic that can be modeled in YANG. >> >> I mostly agree, but having some more structure/advice as to where to >> place YANG modules may be helpful. I'm thinking more along the lines >> of broad categories rather than precise locations. > > +1 > >>> If someone wants to builds a YANG controller node that is managing >>> the configuration for a network of devices then wouldn't they want >>> a particular device's interface configuration to be located >>> somewhere like /network/device//interfaces/interface? >>> Ideally, they would be able to use the same YANG definitions that >>> are defined for /interfaces/ but root them relative to >>> /network/device//. >>> >>> >>> >>> Yes -- some of us (like Martin) have pointed this out many times. >>> The "device" container on an NE does not help at all wrt/ >>> aggregation on a controller. "/device" or "/" work the same for this >>> purpose. > > Actually, I would argue that / works better. On the controller, you > probably have a list of devices you control (this is how our NCS > works, and how ODL works (I have been told)): > > container devices { > list device { > key name; > // meta-info about the device goes here, things like > // ip-address, port, auth info... > container data { > // all models supported by the devices are "mounted" here > } > } > } > > So on the controller, the path to interface "eth0" on device "foo" > would be: > > /devices/device[name='foo']/data/interfaces/interface[name='eth0'] > > if we also have a top-level "/device" container we'd have: > > /devices/device[name='foo']/data/device/interfaces/interface[name='eth0'] > >> What would the real resource location for >> "/network/device//interfaces/interface" be? > > I don't think there is such a thing as a "real" location. The path is > scoped in the system you work with; in the controller it might be as I > illustrated above, in the device it starts with /interfaces, but in a > controller-of-controllers it might be: > > /domains/domain[name='bar']/devices/device[name='foo']/data > /interfaces/interface[name='eth0'] > > Currently we have a proprietary way of "relocating" YANG modules, and > ODL has its "mount", and I think Andy has some other mechanism. Maybe > the time has come to standardize how mount works, and maybe then also > standardize the list of devices in a controller model. +1 Lada > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Aug 19 07:39:24 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC82C1A8758 for ; Wed, 19 Aug 2015 07:39:21 -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 u4NlPHn2Gchr for ; Wed, 19 Aug 2015 07:39:21 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7896E1A874F for ; Wed, 19 Aug 2015 07:39:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1216; q=dns/txt; s=iport; t=1439995160; x=1441204760; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=hmk6n1R+xOxqxNz/Qg83SBbvp66pwbBdMqGBadGwMW0=; b=lYKnmzqRkujc0CxisGHj04v9p4CVTd2RBiDeZrHtwmadzOVJVH/PCcD7 icPrPRkrSiJQzSJKSk2rd2iboe4HF5zz/NRK0Uv1ryZRPQed5RGG33khl iAgWOebu7RjESS1/ewMkEQwnd/4yjqctQXOVuuHk3a9BQPZ07S6ALtfJn 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CbBABclNRV/xbLJq1dhFjFRgKCDAEBAQEBAYELhCQBAQQ4QAEQCw4KCRYPCQMCAQIBRQYNBgIBAYgq0QsBAQEBAQEBAQEBAQEBAQEBARuLU4UKB4QsAQSMYIhEjG2IbpFDJoN+PTOCTAEBAQ X-IronPort-AV: E=Sophos;i="5.15,710,1432598400"; d="scan'208";a="606458927" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 19 Aug 2015 14:39:18 +0000 Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t7JEdIDg028702; Wed, 19 Aug 2015 14:39:18 GMT To: Martin Bjorklund References: <55D36473.90609@cisco.com> <55D45CAF.2070605@cisco.com> <20150819.132555.871710491924929960.mbj@tail-f.com> From: Robert Wilton Message-ID: <55D49515.2010906@cisco.com> Date: Wed, 19 Aug 2015 15:39:17 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20150819.132555.871710491924929960.mbj@tail-f.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Y34 - root node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 14:39:22 -0000 On 19/08/2015 12:25, Martin Bjorklund wrote: > Robert Wilton wrote: > >> What would the real resource location for >> "/network/device//interfaces/interface" be? > I don't think there is such a thing as a "real" location. The path is > scoped in the system you work with; in the controller it might be as I > illustrated above, in the device it starts with /interfaces, but in a > controller-of-controllers it might be: > > /domains/domain[name='bar']/devices/device[name='foo']/data > /interfaces/interface[name='eth0'] > > Currently we have a proprietary way of "relocating" YANG modules, and > ODL has its "mount", and I think Andy has some other mechanism. Maybe > the time has come to standardize how mount works, and maybe then also > standardize the list of devices in a controller model. Yes, I agree. I was also questioning whether relocating YANG modules is something that YANG packages could/should be concerned with. There is also draft-clemm-netmod-mount-00 which seems to be concerned with mounting external datastores in part of the data tree that may also be worth considering. Thanks, Rob > > > /martin > . > From nobody Wed Aug 19 08:32:35 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 451401B2A9E for ; Wed, 19 Aug 2015 08:32:34 -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 Lz3MOcVXYY8Q for ; Wed, 19 Aug 2015 08:32:32 -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 79DA21B2AB7 for ; Wed, 19 Aug 2015 08:32:30 -0700 (PDT) Received: by laba3 with SMTP id a3so5467587lab.1 for ; Wed, 19 Aug 2015 08:32:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=XUSnOMX+aQzp6JlBUWTqVmzMvrwtU4mxnuheCWhHKc0=; b=TLPH/CWnG/Hkxv6U4kBTJxx2bR3hk+hwj3hdY75gGoxTRARu4nAEkEOgVSB5dYU2rf xpZPjiAkHqgLo5j9UF5048yJ7Y8YIVH2Y03IlUR47SMwZdsuk1HCxP2z70vnmvjTnoKs qbGVbOwYzLBjQoK2DPxKdW6uV/WtzzigaDXsEVs8I77ADVRcoHUUzqxVOhm+6l84nGIX 8iMIkgCZsQqVTQ9B83woe8QEe4LuuYDdVt4ynhvZk4FP5YgSOCGk7f3E2EFCLfGytMyk H/BH/bhFPkeqp6GkRV3qB4QI9Ofj1Sz6y76whWl2h0lDW0//pXSxZPwnfjBZBGdlFooI qp5A== X-Gm-Message-State: ALoCoQnlXH7pGC/jx2/LX34iy02Yw1rS+wZf/Kq6NTOiVvBrnA+Y6WMohv3nvOky+3FTDCj/AJnh MIME-Version: 1.0 X-Received: by 10.152.37.67 with SMTP id w3mr11752892laj.123.1439998348781; Wed, 19 Aug 2015 08:32:28 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Wed, 19 Aug 2015 08:32:28 -0700 (PDT) In-Reply-To: <20150819.144900.231414608010857635.mbj@tail-f.com> References: <154527D1-C76B-49DD-B58D-39B197FAD033@nic.cz> <9B232151-C380-4B43-BAF4-88F7E4821B8D@nic.cz> <20150819.144900.231414608010857635.mbj@tail-f.com> Date: Wed, 19 Aug 2015 08:32:28 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=089e0158ba0a0e87d2051dabbebf Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] extensions and conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 15:32:34 -0000 --089e0158ba0a0e87d2051dabbebf Content-Type: text/plain; charset=UTF-8 On Wed, Aug 19, 2015 at 5:49 AM, Martin Bjorklund wrote: > Hi, > > [joining this discussion a bit late] > > Ladislav Lhotka wrote: > > > > > On 10 Aug 2015, at 18:46, Andy Bierman wrote: > > > > > > > > > > > > On Mon, Aug 10, 2015 at 9:37 AM, Ladislav Lhotka > > > wrote: > > > > > > > On 10 Aug 2015, at 17:32, Andy Bierman wrote: > > > > > > > > > > > > > > > > On Mon, Aug 10, 2015 at 4:24 AM, Ladislav Lhotka > > > > wrote: > > > > > > > > > On 10 Aug 2015, at 12:17, Andy Bierman wrote: > > > > > > > > > > Hi, > > > > > > > > > > I am strongly against changing the contract on extensions. > > > > > They MAY be ignored by any YANG tool. Period. > > > > > That means they are far from mandatory. > > > > > They are little more than a keyword and a description clause. > > > > > > > > So do you prefer my proposed solution -02 or -03? > > > > > > > > ** Solution Yxx-03 > > > > > > > > Make extensions optional. This means that extensions won't be > > > > allowed to change YANG language, NETCONF protocol, and validity of > > > > datastores and protocol messages. > > > > > > > > > > > > This is how we use extensions to tag YANG data models > > > > to drive automation tools. > > > > > > But that means, for example, that annotations cannot be defined via an > > > extension statement as in draft-ietf-netmod-yang-metadata. > > > > > > > > > > > > Which means these statements should be real instead of extensions. > > > If the statements are defining data that is exchanged between > > > peers in a standard protocol, then YANG extensions are not > > > appropriate. > > > > I agree, and -03 is my preferred solution, too. > > I strongly disagree. IMO the IETF usage of extensions so far (NACM, > annotations) works well (in the case of NACM proven by multiple > independent implementations), and follows how extensions were intended > to be used, and obviously, how the WG has understood them up until > now. > > If the sentence: > > If a YANG compiler does not support a particular extension, which > appears in a YANG module as an unknown-statement (see Section 12), > the entire unknown-statement MAY be ignored by the compiler. > > in 6020 can be interpreted to mean that an occurance of an extension > is non-normative, we should fix it so that it matches what was > intended and how it is used. > > Juergen suggested this replacement text, which I support. Maybe it > can be improved even more. > > If a YANG parser does not support a particular extension, which > appears in a YANG module as an unknown-statement (see Section 13), > the entire unknown-statement MAY be ignored by the parser. Note > that even in this case the semantics associated with the extension > still apply (as if they were part of a description statement). > > I strongly disagree with this change. This would mean that every tool is required to support the semantics of every extension ever defined. For example, we have our own extensions that cause the server to perform internal tasks certain ways (like ywx:sil-delete-children-first). According to the text you propose, all servers would have to provide the behavior embodied in the syntax of this extension statement? This extension does not alter any protocol behavior at all, so it is "well-behaved". A server MAY skip over the entire extension and completely ignore it. Other servers are not required to provide the behavior described in the extension semantics. > However, I do agree that an extension cannot "undo" semantics defined > by other YANG statements, just as you cannot do that in a description > statement. For example, this would be illegal: > > leaf foo { > type int32; > description "The type is really a string."; > } > > leaf bar { > type int32; > xx:real-type string; > } > > It is also a Very Bad Idea (speaking from experience...) to define an > extension that introduces new data nodes. > > The text about "MAY ignore" was meant to capture this. It's supposed > to be like for a client that doesn't understand an augemntation; it > can skip it. A client that doesn't understand nacm:default-deny-all > works just fine and can safely ignore it. > > > /martin > Andy --089e0158ba0a0e87d2051dabbebf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Aug 19, 2015 at 5:49 AM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Hi,

[joining this discussion a bit late]

Ladislav Lhotka <lhotka@nic.cz> = wrote:
>
> > On 10 Aug 2015, at 18:46, Andy Bierman <andy@yumaworks.com> wrote:
> >
> >
> >
> > On Mon, Aug 10, 2015 at 9:37 AM, Ladislav Lhotka <lhotka@nic.cz>
> > wrote:
> >
> > > On 10 Aug 2015, at 17:32, Andy Bierman <andy@yumaworks.com> wrote:
> > >
> > >
> > >
> > > On Mon, Aug 10, 2015 at 4:24 AM, Ladislav Lhotka <lhotka@nic.cz>
> > > wrote:
> > >
> > > > On 10 Aug 2015, at 12:17, Andy Bierman <andy@yumaworks.com> wrote:
> > > >
> > > > Hi,
> > > >
> > > > I am strongly against changing the contract on extensio= ns.
> > > > They MAY be ignored by any YANG tool. Period.
> > > > That means they are far from mandatory.
> > > > They are little more than a keyword and a description c= lause.
> > >
> > > So do you prefer my proposed solution -02 or -03?
> > >
> > > ** Solution Yxx-03
> > >
> > >=C2=A0 =C2=A0 Make extensions optional. This means that exten= sions won't be
> > >=C2=A0 =C2=A0 allowed to change YANG language, NETCONF protoc= ol, and validity of
> > >=C2=A0 =C2=A0 datastores and protocol messages.
> > >
> > >
> > > This is how we use extensions to tag YANG data models
> > > to drive automation tools.
> >
> > But that means, for example, that annotations cannot be defined v= ia an
> > extension statement as in draft-ietf-netmod-yang-metadata.
> >
> >
> >
> > Which means these statements should be real instead of extensions= .
> > If the statements are defining data that is exchanged between
> > peers in a standard protocol, then YANG extensions are not
> > appropriate.
>
> I agree, and -03 is my preferred solution, too.

I strongly disagree.=C2=A0 IMO the IETF usage of extensions so far (NACM, annotations) works well (in the case of NACM proven by multiple
independent implementations), and follows how extensions were intended
to be used, and obviously, how the WG has understood them up until
now.

If the sentence:

=C2=A0 =C2=A0If a YANG compiler does not support a particular extension, wh= ich
=C2=A0 =C2=A0appears in a YANG module as an unknown-statement (see Section = 12),
=C2=A0 =C2=A0the entire unknown-statement MAY be ignored by the compiler.
in 6020 can be interpreted to mean that an occurance of an extension
is non-normative, we should fix it so that it matches what was
intended and how it is used.

Juergen suggested this replacement text, which I support.=C2=A0 Maybe it can be improved even more.

=C2=A0 =C2=A0 =C2=A0 =C2=A0If a YANG parser does not support a particular e= xtension, which
=C2=A0 =C2=A0 =C2=A0 =C2=A0appears in a YANG module as an unknown-statement= (see Section 13),
=C2=A0 =C2=A0 =C2=A0 =C2=A0the entire unknown-statement MAY be ignored by t= he parser. Note
=C2=A0 =C2=A0 =C2=A0 =C2=A0that even in this case the semantics associated = with the extension
=C2=A0 =C2=A0 =C2=A0 =C2=A0still apply (as if they were part of a descripti= on statement).



I strongly disagree wit= h this change.
This would mean that every tool is required to sup= port the
semantics of every extension ever defined.=C2=A0 For exa= mple,
we have our own extensions that cause the server to
perform internal tasks certain ways (like ywx:sil-delete-children-first)= .

According to the text you propose, all servers w= ould have to
provide the behavior embodied in the syntax of this = extension
statement?=C2=A0 This extension does not alter any prot= ocol behavior
at all, so it is "well-behaved".

A server MAY skip over the entire extension and completely= ignore it.
Other servers are not required to provide the behavio= r described
in the extension semantics.

=

However, I do agree that an extension cannot "undo" semantics def= ined
by other YANG statements, just as you cannot do that in a description
statement.=C2=A0 For example, this would be illegal:

=C2=A0 leaf foo {
=C2=A0 =C2=A0 type int32;
=C2=A0 =C2=A0 description "The type is really a string.";
=C2=A0 }

=C2=A0 leaf bar {
=C2=A0 =C2=A0 type int32;
=C2=A0 =C2=A0 xx:real-type string;
=C2=A0 }

It is also a Very Bad Idea (speaking from experience...) to define an
extension that introduces new data nodes.

The text about "MAY ignore" was meant to capture this.=C2=A0 It&#= 39;s supposed
to be like for a client that doesn't understand an augemntation; it
can skip it.=C2=A0 A client that doesn't understand nacm:default-deny-a= ll
works just fine and can safely ignore it.


/martin


An= dy
=C2=A0

--089e0158ba0a0e87d2051dabbebf-- From nobody Wed Aug 19 09:24:37 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 399E91A0366 for ; Wed, 19 Aug 2015 09:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 vSL6EkfNNjKe for ; Wed, 19 Aug 2015 09:24:34 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0711.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::711]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 310381A035F for ; Wed, 19 Aug 2015 09:24:25 -0700 (PDT) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.151.167.91) by DBXPR07MB062.eurprd07.prod.outlook.com (10.242.147.20) with Microsoft SMTP Server (TLS) id 15.1.231.21; Wed, 19 Aug 2015 16:24:01 +0000 Message-ID: <013601d0da9b$907f6b00$4001a8c0@gateway.2wire.net> From: t.petch To: , Martin Bjorklund References: <55D36473.90609@cisco.com> <55D45CAF.2070605@cisco.com> <20150819.132555.871710491924929960.mbj@tail-f.com> Date: Wed, 19 Aug 2015 17:24:41 +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.167.91] X-ClientProxiedBy: DB5PR03CA0072.eurprd03.prod.outlook.com (25.164.34.40) To DBXPR07MB062.eurprd07.prod.outlook.com (10.242.147.20) X-Microsoft-Exchange-Diagnostics: 1; DBXPR07MB062; 2:+UUKdpA/B5OOJDocW/RaKUNu+NSwqUZ04NQmAQ5JKZPyth2ckNETPbuMrFCIdnbqXN+CX9IlySx3ty8oBC0zTsn1yZbW+scPmjG4lWB/TVmyT0JD1YFCnCwvqnMO2Xo5W+NgKr5vylGKCcaMt/oyPoMd9GiOzXJheflSVIwDAao=; 3:DuzfmU4R3mXRxVv07CCsRis5KE7OlbYA4oHXdus7kTKezY83U9jn7+Zugi+yXqzHqaaVeLS8T27EwVNDDqkOx47+w/CgBOYa7NDASXrzMNDmrRFlCqqWrbM6VeOM6DECRL+NLSl6pCUs61X1zgqPzA==; 25:f6tfCLVgW4rc8BD77HYCQC3ClikdzFTlg6gEBfmR1oOqqfFS2A8W1kYMCdZc7wKjxivkQBHyQ+/vwbHxgJT3GLq3WOS0XylUkgaZY09oDbZPX9zptdRr9zu+ZgeMzyvctJTIdsFG3J8/ruB/KiwQQIwzH4bu0nyFF38UwqDcsXHHhQ+Cs+wQdxvxiYE8paSCS/8Qu4ymtN6YxPUlzEUsrprnjSgHx2qbkxUt4Mao2pfSUSgjHwJTCUbXvv7SXmv/RUKWiOvrpZ9CuPUNhqgOPg==; 4:SU9sbVnsTU5KM7BzUA8levi/E8hvQdxM9I+SgWN/ref1VRRqonn2MDfeoY/u+z6ztY0rHpEijl8RuqsnZZTw/rPYIwboMiR6NvYXQ5UuYgAUrEhb8qfUxYfWxumJO2baClZBNjY8R5sgoR1E1DSkunE+mLdA7O7aSWoCVaLnJyJLDpDo1/F4+5zqYx5/g9Y1i7RbJ2HBhx1BFv6BqtjqlbcA6WA/tgmoPQFzUYER6YHIIvCON/w2PlirHktk3hAWQ10ls3WAMQuVB3OmCnIQqEpuxybJ5hoPtTFKzJlMbJZ1rFRhAJjMLyYmiCxC5iyf X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB062; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(8121501046)(5005006)(3002001); SRVR:DBXPR07MB062; BCL:0; PCL:0; RULEID:; SRVR:DBXPR07MB062; X-Forefront-PRVS: 0673F5BE31 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(377454003)(479174004)(199003)(13464003)(24454002)(47776003)(122386002)(5001960100002)(50986999)(5001770100001)(92566002)(4001540100001)(81156007)(5001830100001)(14496001)(44736004)(76176999)(81816999)(19580395003)(93886004)(5001860100001)(1556002)(19580405001)(84392001)(44716002)(189998001)(62236002)(86362001)(97736004)(81686999)(87976001)(23756003)(106356001)(105586002)(64706001)(66066001)(116806002)(50226001)(61296003)(50466002)(42186005)(1456003)(15975445007)(40100003)(101416001)(77096005)(46102003)(62966003)(77156002)(33646002)(68736005)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB062; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; DBXPR07MB062; 23:Xs6Xq7XDCJpgleeEvp9ebGY+yfJv5EHRtF5p+Pn0?= =?iso-8859-1?Q?3qV8B1RKrquF49d7LK9fey3oKURyvmC5HpySh92ZHiChLsgaEeTnv80BmA?= =?iso-8859-1?Q?/9SFRAD1cVz9Nt/hFsVpDwH3/d86bB5pot2GhL2hjhnxKjL7r4Q62Z0Awk?= =?iso-8859-1?Q?YMv8swOs4OAaMPhksOZKNTILi/1IEWxj88UmEm20Ig9eB3hot6gyxOiDif?= =?iso-8859-1?Q?0MBdsvHkN0vHMtjOucbttO+TJD6NyHUeoJsfugf4iu28mYjgbmQeOSpos6?= =?iso-8859-1?Q?HKPP+/dDhIA8+6SEP7t2g8AB42EPKqPBDk6a+USwk7/Jfy4uXht5E25gae?= =?iso-8859-1?Q?sW/WkBo1Rin44dXdhZUWLgLkqRycfFAlgzNNlPLI7m9mOskUpKIhiAZq9f?= =?iso-8859-1?Q?m+VKyfuqgGMWX6vrdrWuTBtEXRFQyN9n/iSIH422Kg9qQfxbR5gg2K3erv?= =?iso-8859-1?Q?/WqVDfuEAtUJrl8NUCats3jMTXcXo1Hnpsg7FGHDA0YbB2mhcvyP9vPklv?= =?iso-8859-1?Q?JBbR457MoZdhGuK7G7KdKiEPQ1oMTHY2g2Af4G9mGywwd7erbr9k4ykR+R?= =?iso-8859-1?Q?nEmT/prUJUb8EX78F2jDOfzhFergSe+ypiRiQSt5Fvng4vNS0INvZTu6bG?= =?iso-8859-1?Q?3xDkjkVYPADuVi38ftbwUWpTGDCBqMgFkw94KHKtrdE4F2I5MVQsprow7C?= =?iso-8859-1?Q?C+3OKdw9qntjh5VkOON0f7tvFfoKNDSflSY+fAQIfnjs05T7EzetaxySod?= =?iso-8859-1?Q?YUlJN9qRj5jEbPogt/rVarkb2svsW5kx7IIy3XpmSn9pdhMcoeKEJewNV3?= =?iso-8859-1?Q?TkOUcsYOcxuC6KaQ717jK/Gtnmv/4WI3+sxKZnsWMKxKAUnSRjOZM85qDs?= =?iso-8859-1?Q?U76gfjGwAERYo36dy6mWuCquoTZKsKaGtcLCRCvXZpztaJCpj0bgep2+UY?= =?iso-8859-1?Q?JALIpngJkrvdS+Mtxtt9rgUvuGzHRA86WLesBV1APlGDumuZkBuL5HFPrK?= =?iso-8859-1?Q?AzQkfJLcz00bm5vga16YdudcP99F0mOl9UHUjh1LDed/tnz7INNA39oV8e?= =?iso-8859-1?Q?lRQ4Xd+Ykzwr5RGiPoc7x8LM4TGkDmReHfwuC32pH4apnUnFu5E+dGJoWS?= =?iso-8859-1?Q?ykgkpVxmtZ7LZrqFm82b8N2BKu1H7+V6EbKncsgkVRTrByft2a2ZnP8N2C?= =?iso-8859-1?Q?bYqNI49xup7W5t9qJHSWVXaWkAoT7bR8dxff5cNfOdm8VAUjd24XW5mFfd?= =?iso-8859-1?Q?zJESrzFmyCdyZjx5Apn6oPD5VlIjVZWAeGA5KcsaXEnXvUnjNNM1oG1ZLD?= =?iso-8859-1?Q?rWY40ZDUf8CvVryWbGC8/XDr5F8i3eaeVoS/zNyh7XcDzJ2qKF4r128XMf?= =?iso-8859-1?Q?ZhcOgEIKpglGadUYDPHRnS6K4drm73udWbMbI11yrRbMHQM9ueqnLIB0l1?= =?iso-8859-1?Q?MD6N7lujaq6tz9D9GXfO3LYkWwHFp69jG6?= X-Microsoft-Exchange-Diagnostics: 1; DBXPR07MB062; 5:v8xNp31+i2h1PtRARKabrC8sK1afPB53Dkmz0lU3fxJ4kusFsuD7Y8aQ7VmJdROZrZKM7GxyqGQT3NvYryYRb5F6ZrFlIWmSW4oT/VXB5pVvXZEO/hbGN8dKdiSPqVSQU5ApXrRN/laPREthg6RzqQ==; 24:E2DJVEjJhTl7WwPWPvaHLs0jqIkn+sYr+gWBVymLE1CFKtTvdLKhzJSwBjTZvUY/C7O7+DS+sj8iJxN9579V3rvdJENW8gpOXmZAzAXRTYo=; 20:b1N4++e2y4kjMTQrVxo7QSfF+ATdYD2tmTwYrdLENlextc3u0cmD3WyVCEPdW2P3HvAPxZ36fqwoxNLs/JMWMw== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Aug 2015 16:24:01.7776 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB062 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Y34 - root node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 16:24:37 -0000 ----- Original Message ----- From: "Martin Bjorklund" To: Cc: Sent: Wednesday, August 19, 2015 12:25 PM > Robert Wilton wrote: > > > > On 18/08/2015 18:22, Andy Bierman wrote: > > > This is how languages like SMIv2 and YANG work. > > > A conceptual object is given a permanent "home" within the tree of > > > object identifiers. > > > Moving data is very expensive, since any clients working with the old > > > data > > > will break as soon as the data is moved. > > > > > > I am not convinced the IETF can or should come up with a set of > > > containers > > > that covers every possible topic that can be modeled in YANG. > > > > I mostly agree, but having some more structure/advice as to where to > > place YANG modules may be helpful. I'm thinking more along the lines > > of broad categories rather than precise locations. > > +1 Martin If I were able to choose someone to ask for advice on this question, well, your name would be joint top of my list. If you are not going to write it, then who is? The current model is a flat architecture of hundreds (or thousands) of modules each with their own top level nodes, namespace, namespace name, prefix etc. (This is quite different to SMI with its hierarchy but that probably is only significant to those who have spent 20 years with SMI). So, is this flat architecture a problem? Does it matter that we have hundreds (or thousands) of top level nodes? I know that top level nodes are different w.r.t the rules of YANG but cannot foresee whether or not that is an issue for model writers or model users because I cannot get my mind around just what the rules are in this regard? Equally, is it a problem to have hundreds (or thousands) of prefixes? or namespaces? or ... And what else is there that having a lot of might be an issue? I see the YANG architecture as reflecting the IETF 'architecture' of hundreds of working groups loosely federated, sometimes collaborating, mostly not, and so is the right way to develop YANG modules. But are there technical dangers lurking there that in a few years time we will wish we had taken more notice of. Tom Petch > > > If someone wants to builds a YANG controller node that is managing > > > the configuration for a network of devices then wouldn't they want > > > a particular device's interface configuration to be located > > > somewhere like /network/device//interfaces/interface? > > > Ideally, they would be able to use the same YANG definitions that > > > are defined for /interfaces/ but root them relative to > > > /network/device//. > > > > > > > > > > > > Yes -- some of us (like Martin) have pointed this out many times. > > > The "device" container on an NE does not help at all wrt/ > > > aggregation on a controller. "/device" or "/" work the same for this > > > purpose. > > Actually, I would argue that / works better. On the controller, you > probably have a list of devices you control (this is how our NCS > works, and how ODL works (I have been told)): > > container devices { > list device { > key name; > // meta-info about the device goes here, things like > // ip-address, port, auth info... > container data { > // all models supported by the devices are "mounted" here > } > } > } > > So on the controller, the path to interface "eth0" on device "foo" > would be: > > /devices/device[name='foo']/data/interfaces/interface[name='eth0'] > > if we also have a top-level "/device" container we'd have: > > /devices/device[name='foo']/data/device/interfaces/interface[name='eth0' ] > > > What would the real resource location for > > "/network/device//interfaces/interface" be? > > I don't think there is such a thing as a "real" location. The path is > scoped in the system you work with; in the controller it might be as I > illustrated above, in the device it starts with /interfaces, but in a > controller-of-controllers it might be: > > /domains/domain[name='bar']/devices/device[name='foo']/data > /interfaces/interface[name='eth0'] > > Currently we have a proprietary way of "relocating" YANG modules, and > ODL has its "mount", and I think Andy has some other mechanism. Maybe > the time has come to standardize how mount works, and maybe then also > standardize the list of devices in a controller model. > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Aug 19 09:55:30 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2DFF1A1B1E for ; Wed, 19 Aug 2015 09:55:27 -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_15=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 Vh4qlFt5rDVq for ; Wed, 19 Aug 2015 09:55:25 -0700 (PDT) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3BE41A1B21 for ; Wed, 19 Aug 2015 09:55:23 -0700 (PDT) Received: by lbbpu9 with SMTP id pu9so7326616lbb.3 for ; Wed, 19 Aug 2015 09:55:22 -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=9hDS9KYwh44XzEJAU/LfVq8Z8HYd8ItjiXqn0Wl48TQ=; b=OVzNvpP567B5q+u/T2F2rRGRJGWvB9IYWtq4N05ECunBhnxBPLwjsy75U2h7KUslsT g7MDluiu9Nb8ITvbmO5Ll2y0OVCgVq0iVLPi7Rg+fcmOMr+dSw9D69e4pLspDq281wnx rNiJBZxb2x/LxVD3iHklZz5bwkG+Ls7iZNwkSSSQHthIsXMSdG9qoyigKsv5T/cEi0oY 44j09zOmukgbl0EEluLknspt2BUVBBfU9oXZx6VtDkHPtZ7LoAFBUaRQM7/ED5dV6jVw PT1Tc/71DTswmowlUy7gQGyljc0Gtpc1PXu2Y4P4tlWWcKrZ5bglT4u4231R2lJYSWOH 3Img== X-Gm-Message-State: ALoCoQnyk4/knEG4UZr9tuyVWDGXtpYWleJmpbR1ranS5pAZmKY59CcX3B9/1tZlVFU+IoqKGJb7 MIME-Version: 1.0 X-Received: by 10.112.154.106 with SMTP id vn10mr12031350lbb.38.1440003322204; Wed, 19 Aug 2015 09:55:22 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Wed, 19 Aug 2015 09:55:22 -0700 (PDT) In-Reply-To: <013601d0da9b$907f6b00$4001a8c0@gateway.2wire.net> References: <55D36473.90609@cisco.com> <55D45CAF.2070605@cisco.com> <20150819.132555.871710491924929960.mbj@tail-f.com> <013601d0da9b$907f6b00$4001a8c0@gateway.2wire.net> Date: Wed, 19 Aug 2015 09:55:22 -0700 Message-ID: From: Andy Bierman To: "t.petch" Content-Type: multipart/alternative; boundary=089e0122af2a7ef0cd051dace65a Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y34 - root node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 16:55:28 -0000 --089e0122af2a7ef0cd051dace65a Content-Type: text/plain; charset=UTF-8 On Wed, Aug 19, 2015 at 9:24 AM, t.petch wrote: > ----- Original Message ----- > From: "Martin Bjorklund" > To: > Cc: > Sent: Wednesday, August 19, 2015 12:25 PM > > Robert Wilton wrote: > > > > > > On 18/08/2015 18:22, Andy Bierman wrote: > > > > This is how languages like SMIv2 and YANG work. > > > > A conceptual object is given a permanent "home" within the tree of > > > > object identifiers. > > > > Moving data is very expensive, since any clients working with the > old > > > > data > > > > will break as soon as the data is moved. > > > > > > > > I am not convinced the IETF can or should come up with a set of > > > > containers > > > > that covers every possible topic that can be modeled in YANG. > > > > > > I mostly agree, but having some more structure/advice as to where to > > > place YANG modules may be helpful. I'm thinking more along the > lines > > > of broad categories rather than precise locations. > > > > +1 > > Martin > > If I were able to choose someone to ask for advice on this question, > well, your name would be joint top of my list. If you are not going to > write it, then who is? > > The current model is a flat architecture of hundreds (or thousands) of > modules each with their own top level nodes, namespace, namespace name, > prefix etc. (This is quite different to SMI with its hierarchy but that > probably is only significant to those who have spent 20 years with SMI). > > So, is this flat architecture a problem? Does it matter that we have > hundreds (or thousands) of top level nodes? I know that top level nodes > are different w.r.t the rules of YANG but cannot foresee whether or not > that is an issue for model writers or model users because I cannot get > my mind around just what the rules are in this regard? > > But this is not what we have. Many times a YANG module augments another on (such as ietf-interfaces). As for 100s maybe 1000s...; Here is the datastore contents that the IETF has defined so far: [not sure if I am leaving out other WGs] Yr RFC root comments 2008 5277 /netconf Notification streams (XSD, no YANG at all) 2010 6022 /netconf-state NETCONF monitoring 2012 6536 /nacm NETCONF access control 2012 6728 /ipfix IPFIX and PSAMP configuration 2014 7223 /interfaces Interface management /interfaces-state 2014 7277 augment /interfaces/interface IP management 2014 7317 /system Host system management 2014 7407 /snmp SNMP configuration Maybe 1000s, maybe 8. I would hardly say that this represents a problem that is out of control. I also would not call 7 RFCs in 5 years with YANG data in them as much progress. At this rate it will take 150 years to fill in the tree of NP containers will real modules. Andy Equally, is it a problem to have hundreds (or thousands) of prefixes? or > namespaces? or ... > > And what else is there that having a lot of might be an issue? > > I see the YANG architecture as reflecting the IETF 'architecture' of > hundreds of working groups loosely federated, sometimes collaborating, > mostly not, and so is the right way to develop YANG modules. But are > there technical dangers lurking there that in a few years time we will > wish we had taken more notice of. > > Tom Petch > > > > > If someone wants to builds a YANG controller node that is > managing > > > > the configuration for a network of devices then wouldn't they > want > > > > a particular device's interface configuration to be located > > > > somewhere like > /network/device//interfaces/interface? > > > > Ideally, they would be able to use the same YANG definitions > that > > > > are defined for /interfaces/ but root them relative to > > > > /network/device//. > > > > > > > > > > > > > > > > Yes -- some of us (like Martin) have pointed this out many times. > > > > The "device" container on an NE does not help at all wrt/ > > > > aggregation on a controller. "/device" or "/" work the same for > this > > > > purpose. > > > > Actually, I would argue that / works better. On the controller, you > > probably have a list of devices you control (this is how our NCS > > works, and how ODL works (I have been told)): > > > > container devices { > > list device { > > key name; > > // meta-info about the device goes here, things like > > // ip-address, port, auth info... > > container data { > > // all models supported by the devices are "mounted" here > > } > > } > > } > > > > So on the controller, the path to interface "eth0" on device "foo" > > would be: > > > > /devices/device[name='foo']/data/interfaces/interface[name='eth0'] > > > > if we also have a top-level "/device" container we'd have: > > > > > /devices/device[name='foo']/data/device/interfaces/interface[name='eth0' > ] > > > > > What would the real resource location for > > > "/network/device//interfaces/interface" be? > > > > I don't think there is such a thing as a "real" location. The path is > > scoped in the system you work with; in the controller it might be as I > > illustrated above, in the device it starts with /interfaces, but in a > > controller-of-controllers it might be: > > > > /domains/domain[name='bar']/devices/device[name='foo']/data > > /interfaces/interface[name='eth0'] > > > > Currently we have a proprietary way of "relocating" YANG modules, and > > ODL has its "mount", and I think Andy has some other mechanism. Maybe > > the time has come to standardize how mount works, and maybe then also > > standardize the list of devices in a controller model. > > > > > > /martin > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --089e0122af2a7ef0cd051dace65a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Aug 19, 2015 at 9:24 AM, t.petch <ietfc@btconnect.com&g= t; wrote:
----- Original Message -= ----
From: "Martin Bjorklund" <mb= j@tail-f.com>
To: <rwilton@cisco.com>
Cc: <netmod@ietf.org>
Sent: Wednesday, August 19, 2015 12:25 PM
> Robert Wilton <rwilton@cisco.c= om> wrote:
> >
> > On 18/08/2015 18:22, Andy Bierman wrote:
> > > This is how languages like SMIv2 and YANG work.
> > > A conceptual object is given a permanent "home" wi= thin the tree of
> > > object identifiers.
> > > Moving data is very expensive, since any clients working wit= h the
old
> > > data
> > > will break as soon as the data is moved.
> > >
> > >=C2=A0 I am not convinced the IETF can or should come up with= a set of
> > >=C2=A0 containers
> > > that covers every possible topic that can be modeled in YANG= .
> >
> > I mostly agree, but having some more structure/advice as to where= to
> > place YANG modules may be helpful.=C2=A0 I'm thinking more al= ong the
lines
> > of broad categories rather than precise locations.
>
> +1

Martin

If I were able to choose someone to ask for advice on this question,
well, your name would be joint top of my list.=C2=A0 If you are not going t= o
write it, then who is?

The current model is a flat architecture of hundreds (or thousands) of
modules each with their own top level nodes, namespace, namespace name,
prefix etc.=C2=A0 (This is quite different to SMI with its hierarchy but th= at
probably is only significant to those who have spent 20 years with SMI).
So, is this flat architecture a problem?=C2=A0 Does it matter that we have<= br> hundreds (or thousands) of top level nodes?=C2=A0 I know that top level nod= es
are different w.r.t the rules of YANG but cannot foresee whether or not
that is an issue for model writers or model users because I cannot get
my mind around just what the rules are in this regard?



But this is not what we= have.
Many times a YANG module augments another on (such as ietf= -interfaces).

As for 100s maybe 1000s...;

Here is the datastore contents that the IETF has defined s= o far:
[not sure if I am leaving out other WGs]

=C2=A0 =C2=A0 Yr =C2=A0 =C2=A0 =C2=A0 =C2=A0RFC =C2=A0 =C2=A0 =C2= =A0root =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 comments

=C2=A0 =C2=A02008 =C2=A0 =C2=A05277 = =C2=A0 =C2=A0 /netconf =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Not= ification streams (XSD, no YANG at all)
=C2=A0 =C2=A02010 =C2=A0 = =C2=A06022 =C2=A0 =C2=A0 /netconf-state =C2=A0 =C2=A0 =C2=A0NETCONF monitor= ing
=C2=A0 =C2=A02012 =C2=A0 =C2=A06536 =C2=A0 =C2=A0 /nacm =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0NETCONF access c= ontrol
=C2=A0 =C2=A02012 =C2=A0 =C2=A06728 =C2=A0 =C2=A0 /ipfix = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IPFIX = and PSAMP configuration
=C2=A0 =C2=A02014 =C2=A0 =C2=A07223 =C2= =A0 =C2=A0 /interfaces =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Interface m= anagement
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /interfaces-state
=C2= =A0 =C2=A02014 =C2=A0 7277 =C2=A0 =C2=A0augment /interfaces/interface =C2= =A0 IP management
=C2=A0 =C2=A02014 =C2=A0 7317 =C2=A0 =C2=A0= /system =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hos= t system management
=C2=A0 =C2=A02014 =C2=A0 7407 =C2=A0 =C2=A0 /= snmp =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = SNMP configuration



M= aybe 1000s, maybe 8.

I would hardly say that this = represents a problem that is out of control.
I also would not cal= l 7 RFCs in 5 years with YANG data in them as much progress.
At t= his rate it will take 150 years to fill in the tree of NP containers will r= eal modules.


Andy


Equally, is it a problem to have hundreds (or thousands) of prefixes? or namespaces? or ...

And what else is there that having a lot of might be an issue?

I see the YANG architecture as reflecting the IETF 'architecture' o= f
hundreds of working groups loosely federated, sometimes collaborating,
mostly not, and so is the right way to develop YANG modules.=C2=A0 But are<= br> there technical dangers lurking there that in a few years time we will
wish we had taken more notice of.

Tom Petch

> > >=C2=A0 =C2=A0 =C2=A0If someone wants to builds a YANG control= ler node that is
managing
> > >=C2=A0 =C2=A0 =C2=A0the configuration for a network of device= s then wouldn't they
want
> > >=C2=A0 =C2=A0 =C2=A0a particular device's interface confi= guration to be located
> > >=C2=A0 =C2=A0 =C2=A0somewhere like
/network/device/<device-name>/interfaces/interface?
> > >=C2=A0 =C2=A0 =C2=A0Ideally, they would be able to use the sa= me YANG definitions
that
> > >=C2=A0 =C2=A0 =C2=A0are defined for /interfaces/ but root the= m relative to
> > >=C2=A0 =C2=A0 =C2=A0/network/device/<device-name>/.
> > >
> > >
> > >
> > > Yes -- some of us (like Martin) have pointed this out many t= imes.
> > > The "device" container on an NE does not help at a= ll wrt/
> > > aggregation on a controller. "/device" or "/&= quot; work the same for
this
> > > purpose.
>
> Actually, I would argue that / works better.=C2=A0 On the controller, = you
> probably have a list of devices you control (this is how our NCS
> works, and how ODL works (I have been told)):
>
>=C2=A0 =C2=A0container devices {
>=C2=A0 =C2=A0 =C2=A0list device {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0key name;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0// meta-info about the device goes here, thi= ngs like
>=C2=A0 =C2=A0 =C2=A0 =C2=A0// ip-address, port, auth info...
>=C2=A0 =C2=A0 =C2=A0 =C2=A0container data {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// all models supported by the device= s are "mounted" here
>=C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0}
>
> So on the controller, the path to interface "eth0" on device= "foo"
> would be:
>
>=C2=A0 =C2=A0/devices/device[name=3D'foo']/data/interfaces/inte= rface[name=3D'eth0']
>
> if we also have a top-level "/device" container we'd hav= e:
>
>
/devices/device[name=3D'foo']/data/device/interfaces/interface[name= =3D'eth0'
]
>
> > What would the real resource location for
> > "/network/device/<device-name>/interfaces/interface&qu= ot; be?
>
> I don't think there is such a thing as a "real" location= .=C2=A0 The path is
> scoped in the system you work with; in the controller it might be as I=
> illustrated above, in the device it starts with /interfaces, but in a<= br> > controller-of-controllers it might be:
>
>=C2=A0 =C2=A0/domains/domain[name=3D'bar']/devices/device[name= =3D'foo']/data
>=C2=A0 =C2=A0 =C2=A0/interfaces/interface[name=3D'eth0']
>
> Currently we have a proprietary way of "relocating" YANG mod= ules, and
> ODL has its "mount", and I think Andy has some other mechani= sm.=C2=A0 Maybe
> the time has come to standardize how mount works, and maybe then also<= br> > standardize the list of devices in a controller model.
>
>
> /martin
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

--089e0122af2a7ef0cd051dace65a-- From nobody Wed Aug 19 10:49:44 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F031A870E for ; Wed, 19 Aug 2015 10:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bnBgRIovE9G for ; Wed, 19 Aug 2015 10:49:36 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A39221A6F7C for ; Wed, 19 Aug 2015 10:49:36 -0700 (PDT) Received: from localhost (unknown [173.38.220.43]) by mail.tail-f.com (Postfix) with ESMTPSA id 906201AE0486; Wed, 19 Aug 2015 19:49:34 +0200 (CEST) Date: Wed, 19 Aug 2015 19:49:34 +0200 (CEST) Message-Id: <20150819.194934.461244528814584733.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <9B232151-C380-4B43-BAF4-88F7E4821B8D@nic.cz> <20150819.144900.231414608010857635.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] extensions and conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 17:49:43 -0000 Andy Bierman wrote: > On Wed, Aug 19, 2015 at 5:49 AM, Martin Bjorklund wrote: > > > Hi, > > > > [joining this discussion a bit late] > > > > Ladislav Lhotka wrote: > > > > > > > On 10 Aug 2015, at 18:46, Andy Bierman wrote: > > > > > > > > > > > > > > > > On Mon, Aug 10, 2015 at 9:37 AM, Ladislav Lhotka > > > > wrote: > > > > > > > > > On 10 Aug 2015, at 17:32, Andy Bierman wrote: > > > > > > > > > > > > > > > > > > > > On Mon, Aug 10, 2015 at 4:24 AM, Ladislav Lhotka > > > > > wrote: > > > > > > > > > > > On 10 Aug 2015, at 12:17, Andy Bierman wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > I am strongly against changing the contract on extensions. > > > > > > They MAY be ignored by any YANG tool. Period. > > > > > > That means they are far from mandatory. > > > > > > They are little more than a keyword and a description clause. > > > > > > > > > > So do you prefer my proposed solution -02 or -03? > > > > > > > > > > ** Solution Yxx-03 > > > > > > > > > > Make extensions optional. This means that extensions won't be > > > > > allowed to change YANG language, NETCONF protocol, and validity of > > > > > datastores and protocol messages. > > > > > > > > > > > > > > > This is how we use extensions to tag YANG data models > > > > > to drive automation tools. > > > > > > > > But that means, for example, that annotations cannot be defined via an > > > > extension statement as in draft-ietf-netmod-yang-metadata. > > > > > > > > > > > > > > > > Which means these statements should be real instead of extensions. > > > > If the statements are defining data that is exchanged between > > > > peers in a standard protocol, then YANG extensions are not > > > > appropriate. > > > > > > I agree, and -03 is my preferred solution, too. > > > > I strongly disagree. IMO the IETF usage of extensions so far (NACM, > > annotations) works well (in the case of NACM proven by multiple > > independent implementations), and follows how extensions were intended > > to be used, and obviously, how the WG has understood them up until > > now. > > > > If the sentence: > > > > If a YANG compiler does not support a particular extension, which > > appears in a YANG module as an unknown-statement (see Section 12), > > the entire unknown-statement MAY be ignored by the compiler. > > > > in 6020 can be interpreted to mean that an occurance of an extension > > is non-normative, we should fix it so that it matches what was > > intended and how it is used. > > > > Juergen suggested this replacement text, which I support. Maybe it > > can be improved even more. > > > > If a YANG parser does not support a particular extension, which > > appears in a YANG module as an unknown-statement (see Section 13), > > the entire unknown-statement MAY be ignored by the parser. Note > > that even in this case the semantics associated with the extension > > still apply (as if they were part of a description statement). > > > > > > I strongly disagree with this change. > This would mean that every tool is required to support the > semantics of every extension ever defined. No. It means that if a server advertises module that uses some extension to define some behaviour, the server supports that behavior. Just as we expect a server to support the text in description statements. For example, the nacm: extensions do not apply unless ietf-netconf-acm is advertised (and nacm is enabled). I expect most extensions to work this way. Another example is if we actually defined i2rs:ephemeral; this would have no effect unless the "i2rs" capability (whatever that is) is also advertised. The text also means that it is perfectly ok for a client to ignore the extension if it doesn't understand it. For example, if the client has no idea what the ephemeral datastore it, it doesn't matter that a node is marked with i2rs:ephemeral true. > For example, > we have our own extensions that cause the server to > perform internal tasks certain ways (like ywx:sil-delete-children-first). > > According to the text you propose, all servers would have to > provide the behavior embodied in the syntax of this extension > statement? Yes, all servers that advertise such a module. B/c as you note below it is "well-behaved". So the defintion probably says something like "if the server implements SIL, then it will delete the children before it deletes the node itself". > This extension does not alter any protocol behavior > at all, so it is "well-behaved". > > A server MAY skip over the entire extension and completely ignore it. > Other servers are not required to provide the behavior described > in the extension semantics. Yes. Aren't we in agreement here? /martin > > > > > However, I do agree that an extension cannot "undo" semantics defined > > by other YANG statements, just as you cannot do that in a description > > statement. For example, this would be illegal: > > > > leaf foo { > > type int32; > > description "The type is really a string."; > > } > > > > leaf bar { > > type int32; > > xx:real-type string; > > } > > > > It is also a Very Bad Idea (speaking from experience...) to define an > > extension that introduces new data nodes. > > > > The text about "MAY ignore" was meant to capture this. It's supposed > > to be like for a client that doesn't understand an augemntation; it > > can skip it. A client that doesn't understand nacm:default-deny-all > > works just fine and can safely ignore it. > > > > > > /martin > > > > > Andy From nobody Wed Aug 19 11:40:57 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E407B1A87F1; Wed, 19 Aug 2015 11:40:55 -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 GfjM7LGa9rsw; Wed, 19 Aug 2015 11:40:53 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C7891A8845; Wed, 19 Aug 2015 11:40:53 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E06181594; Wed, 19 Aug 2015 20:40:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 0qzOxErbbnD2; Wed, 19 Aug 2015 20:40:50 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 19 Aug 2015 20:40:50 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id C2F5C2004E; Wed, 19 Aug 2015 20:40: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 Vilcu9wPw7HA; Wed, 19 Aug 2015 20:40:50 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2CCE220048; Wed, 19 Aug 2015 20:40:48 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 789D3365591F; Wed, 19 Aug 2015 20:40:44 +0200 (CEST) Date: Wed, 19 Aug 2015 20:40:43 +0200 From: Juergen Schoenwaelder To: Lou Berger Message-ID: <20150819184043.GA69779@elstar.local> Mail-Followup-To: Lou Berger , Andy Bierman , netmod WG , draft-rtgyangdt-rtgwg-device-model@ietf.org, Routing WG References: <55D3DDFC.2080107@labn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55D3DDFC.2080107@labn.net> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Routing WG , netmod WG , draft-rtgyangdt-rtgwg-device-model@ietf.org Subject: Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 18:40:56 -0000 On Tue, Aug 18, 2015 at 09:38:04PM -0400, Lou Berger wrote: > > Why is this a meta-model? > because the aim to to show how other models inter-relate rather than > define the details of all models. As stated in the intro: > > This document aims to provide an extensible structure that can be > used to tie together other models. It allows for existing, emerging, > and future models. The overall structure can be constructed using > YANG augmentation and imports. > You can easily extract relationships between YANG data models out of YANG language constructs such as import relationships, leafref path restrictions, augment references, etc. - Why do you think relying on language constructs does not work? - Why do you believe that relying on a certain hierarchy that several independent SDOs and vendors have to augment and fill consistently is going to be lead to a robust solution? If YANG adoption continues as it looks right now, we will count modules in the thousands in a couple of years originating from many different organizations. I would trust tools that are able to interpret YANG language constructs to scale up to such a scenario. I doubt a simple hierarchy of containers (which will essentially become unmaintainable once it is used by several standards) will be of much value in 10+ years. Andy's early work on YANG packages that provide machine readable meta-data is a useful direction to explore further. /js PS: As a spare-time Unix system administrator, I recall several fancy proposals back in the 1990's how to best organize your /usr/local to make software installation and sharing easy. It seems none of these approaches that are essentially relying on naming conventions succeeded in the long run. Instead, we got software package systems that have sufficient machine readable meta-information to make software management easy and reliable. -- 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 Aug 19 11:54:41 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40BDB1A88EF for ; Wed, 19 Aug 2015 11:54: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=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 5YXhVlPugs-Q for ; Wed, 19 Aug 2015 11:54:36 -0700 (PDT) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC5CE1A88F9 for ; Wed, 19 Aug 2015 11:54:31 -0700 (PDT) Received: by lahi9 with SMTP id i9so8842251lah.2 for ; Wed, 19 Aug 2015 11:54: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:content-type; bh=JovrR5/rAc0/ObIM7KNWbQYEacqgzG17XkWO5exlEPI=; b=DhGDS7hZFbxnxXBbyUPrq+wXkGe9g5U3IDyjENuxo5vXNC2xMYbPnX+4dp3FAQXooj 96RXHSGh2MgbIETCJm2U3PnTwIUwrCYH4CoQ34V82hqs3mfCmOOjLwS0wlmfOPhQvAeQ 9QpNR7Kd+qiZzXQzeVZHVlZ84fH/yBcRz7UT+ggGh+xz/kx/ueIeeQJDu4FTda7xRacw O8CO+LL9DQ3EfF64uB8mihej650P1ERIsTyCK8h0J712+kGPS8KNAIQI5/5+3kJ2Xe4x KEokknnf5+YVgUsw5YxaxdE3Jy1vBUthUOBuOKXTONsx7dDg3WMucizqo9VGqBgNkoiU Nmmw== X-Gm-Message-State: ALoCoQmz4YMPzo3/L+WBjz4JTt0eBBruP2WT/w4/bq8CN/jgLi8musowJQldHojm49NiK3S7E6E4 MIME-Version: 1.0 X-Received: by 10.152.120.74 with SMTP id la10mr12722351lab.37.1440010469840; Wed, 19 Aug 2015 11:54:29 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Wed, 19 Aug 2015 11:54:29 -0700 (PDT) In-Reply-To: <20150819184043.GA69779@elstar.local> References: <55D3DDFC.2080107@labn.net> <20150819184043.GA69779@elstar.local> Date: Wed, 19 Aug 2015 11:54:29 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Lou Berger , Andy Bierman , netmod WG , draft-rtgyangdt-rtgwg-device-model@ietf.org, Routing WG Content-Type: multipart/alternative; boundary=089e0122902287a8bf051dae9068 Archived-At: Subject: Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 18:54:38 -0000 --089e0122902287a8bf051dae9068 Content-Type: text/plain; charset=UTF-8 On Wed, Aug 19, 2015 at 11:40 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Aug 18, 2015 at 09:38:04PM -0400, Lou Berger wrote: > > > > Why is this a meta-model? > > > because the aim to to show how other models inter-relate rather than > > define the details of all models. As stated in the intro: > > > > This document aims to provide an extensible structure that can be > > used to tie together other models. It allows for existing, emerging, > > and future models. The overall structure can be constructed using > > YANG augmentation and imports. > > > > You can easily extract relationships between YANG data models out of > YANG language constructs such as import relationships, leafref path > restrictions, augment references, etc. > > - Why do you think relying on language constructs does not work? > > - Why do you believe that relying on a certain hierarchy that several > independent SDOs and vendors have to augment and fill consistently > is going to be lead to a robust solution? > > If YANG adoption continues as it looks right now, we will count > modules in the thousands in a couple of years originating from many > different organizations. I would trust tools that are able to > interpret YANG language constructs to scale up to such a scenario. I > doubt a simple hierarchy of containers (which will essentially become > unmaintainable once it is used by several standards) will be of much > value in 10+ years. > > Andy's early work on YANG packages that provide machine readable > meta-data is a useful direction to explore further. > > I took the conformance stuff out of the YANG packages draft because there were concerns before that it conflicted with YANG module conformance. It seems like the "augment with mandatory nodes" type of problem indicates we need a conformance model that is capable of describing an API that spans more than one YANG module. > /js > > PS: As a spare-time Unix system administrator, I recall several fancy > proposals back in the 1990's how to best organize your /usr/local > to make software installation and sharing easy. It seems none of > these approaches that are essentially relying on naming > conventions succeeded in the long run. Instead, we got software > package systems that have sufficient machine readable > meta-information to make software management easy and reliable. > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > Andy --089e0122902287a8bf051dae9068 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Aug 19, 2015 at 11:40 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Tue, Aug 18, 2015 at 09:38:04PM -0400, Lou Berge= r wrote:

> > Why is this a meta-model?

> because the aim to to show how other models inter-relate rather than > define the details of all models. As stated in the intro:
>
>=C2=A0 =C2=A0 This document aims to provide an extensible structure tha= t can be
>=C2=A0 =C2=A0 used to tie together other models. It allows for existing= , emerging,
>=C2=A0 =C2=A0 and future models. The overall structure can be construct= ed using
>=C2=A0 =C2=A0 YANG augmentation and imports.
>

You can easily extract relationships between YANG data models out of
YANG language constructs such as import relationships, leafref path
restrictions, augment references, etc.

- Why do you think relying on language constructs does not work?

- Why do you believe that relying on a certain hierarchy that several
=C2=A0 independent SDOs and vendors have to augment and fill consistently =C2=A0 is going to be lead to a robust solution?

If YANG adoption continues as it looks right now, we will count
modules in the thousands in a couple of years originating from many
different organizations. I would trust tools that are able to
interpret YANG language constructs to scale up to such a scenario. I
doubt a simple hierarchy of containers (which will essentially become
unmaintainable once it is used by several standards) will be of much
value in 10+ years.

Andy's early work on YANG packages that provide machine readable
meta-data is a useful direction to explore further.



I took the conformance = stuff out of the YANG packages draft because
there were concerns = before that it conflicted with YANG module
conformance.

It seems like the "augment with mandatory nodes" = type of problem
indicates we need a conformance model that is cap= able of
describing an API that spans more than one YANG module.

=C2=A0
/js

PS: As a spare-time Unix system administrator, I recall several fancy
=C2=A0 =C2=A0 proposals back in the 1990's how to best organize your /u= sr/local
=C2=A0 =C2=A0 to make software installation and sharing easy. It seems none= of
=C2=A0 =C2=A0 these approaches that are essentially relying on naming
=C2=A0 =C2=A0 conventions succeeded in the long run. Instead, we got softwa= re
=C2=A0 =C2=A0 package systems that have sufficient machine readable
=C2=A0 =C2=A0 meta-information to make software management easy and reliabl= e.

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


<= /div>
Andy

--089e0122902287a8bf051dae9068-- From nobody Wed Aug 19 17:45:33 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BCA71A8A7C for ; Wed, 19 Aug 2015 17:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7CKUq4KxMc18 for ; Wed, 19 Aug 2015 17:45:27 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id 7240E1A884B for ; Wed, 19 Aug 2015 17:45:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Oi0KxAhCFIAjoVzFZKiWNuuVgAp9pMgqZ7q8CGM39/XEx3vYKWS7IbAs11wSmdOK; 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.48] (helo=elwamui-rustique.atl.sa.earthlink.net) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1ZSDyr-0008Lm-OI for netmod@ietf.org; Wed, 19 Aug 2015 20:45:21 -0400 Received: from 76.254.50.225 by webmail.earthlink.net with HTTP; Wed, 19 Aug 2015 20:45:21 -0400 Message-ID: <16753832.1440031521612.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net> Date: Wed, 19 Aug 2015 17:45:21 -0700 (GMT-07:00) From: Randy Presuhn To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88874d3f0892ff6d3eda82b5a39f835544e853663f4b706b86b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.48 Archived-At: Subject: Re: [netmod] extensions and conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 00:45:32 -0000 Hi - >From: Martin Bjorklund >Sent: Aug 19, 2015 10:49 AM >To: andy@yumaworks.com >Cc: netmod@ietf.org >Subject: Re: [netmod] extensions and conformance ... >> > Juergen suggested this replacement text, which I support. Maybe it >> > can be improved even more. >> > >> > If a YANG parser does not support a particular extension, which >> > appears in a YANG module as an unknown-statement (see Section 13), >> > the entire unknown-statement MAY be ignored by the parser. Note >> > that even in this case the semantics associated with the extension >> > still apply (as if they were part of a description statement). ... >No. It means that if a server advertises module that uses some >extension to define some behaviour, the server supports that >behavior. Just as we expect a server to support the text in >description statements. Sorry, but that interpretation is not supported by the 2119 definition of MAY. >For example, the nacm: extensions do not apply unless ietf-netconf-acm >is advertised (and nacm is enabled). I expect most extensions to work >this way. Another example is if we actually defined i2rs:ephemeral; >this would have no effect unless the "i2rs" capability (whatever that >is) is also advertised. > >The text also means that it is perfectly ok for a client to ignore the >extension if it doesn't understand it. For example, if the client has >no idea what the ephemeral datastore it, it doesn't matter that a node >is marked with i2rs:ephemeral true. You are describing something stronger than a naked MAY. You're describing an "if x MUST y". If the conformance requirement is truly simply MAY, then support is OPTIONAL even if the system claims conformance. Randy From nobody Wed Aug 19 19:00:40 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43A511A8B84 for ; Wed, 19 Aug 2015 19:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnDc2mbRS6XR for ; Wed, 19 Aug 2015 19:00:36 -0700 (PDT) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id 512911A8AFA for ; Wed, 19 Aug 2015 19:00:36 -0700 (PDT) Received: (qmail 31752 invoked by uid 0); 20 Aug 2015 02:00:34 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy2.mail.unifiedlayer.com with SMTP; 20 Aug 2015 02:00:34 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id 6q0R1r00e2SSUrH01q0U0a; Wed, 19 Aug 2015 20:00:34 -0600 X-Authority-Analysis: v=2.1 cv=QdD14Krv c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=4g2epv4a4k0A:10 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=uRRa74qj2VoA:10 a=48vgC7mUAAAA:8 a=pbD9ftrUfG38T_C27-8A:9 a=eETf1X0CnWgoS2HF:21 a=soS_R2eVov-33_RS:21 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=ybQGYHjUrBr/2yuBgThY5AXxrmRwrtyy8Fnf8ORuJDM=; b=EC8wmG6auhp24m2lk9tahbw4bhANoRQBlYy0HFClE6pN19JmJHq+ShDzxekZOXfFW/s3CgnpKLUa6AGUm8roELZuUF0LmrpoejEn+FE+9eb3/2q/eawOshPi83e8NLoV; Received: from box313.bluehost.com ([69.89.31.113]:39930 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZSF9V-0000cy-Ac; Wed, 19 Aug 2015 20:00:25 -0600 Message-ID: <55D534B6.4050506@labn.net> Date: Wed, 19 Aug 2015 22:00:22 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Andy Bierman References: <55D3DDFC.2080107@labn.net> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: draft-rtgyangdt-rtgwg-device-model@ietf.org, netmod WG , Routing WG Subject: Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 02:00:39 -0000 sorry for the slow response -- on a bit of a vacation schedule aat the moment... On 08/18/2015 11:04 PM, Andy Bierman wrote: > > > On Tue, Aug 18, 2015 at 6:38 PM, Lou Berger > wrote: > > [Adding authors and RTG WG.] > > Hi Andy, > I'm not sure who you are looking to hear from as you addressed this > mail to the netmod list. I'm happy to give my opinion as it seems you > might have been aiming this at the draft authors. (but then again > perhaps not.) > > > Tom sent the meeting invite to netmod so I figured that was where we were > supposed to discuss drafts. > NP - just a bit odd to not list the folks you expect to answer on the to line. > > > On 8/18/2015 8:01 PM, Andy Bierman wrote: > > Hi, > > > > I assume this draft is what we should be reviewing and not > > the obsolete openconfig draft? > > My personal view / hope is that the openconfig draft will be revised to > cover requirements while the DT draft leads to an agreed upon approach > to addressing those requirements. Again, just stating my view, not the > view of the DT, co-authors or OC draft authors. > > > Sort of confusing because this draft says it is based on the other draft, > so one assumes it is meant to replace it. > > > > > > > > > > https://tools.ietf.org/html/draft-rtgyangdt-rtgwg-device-model-00 > > > > > > Q1) scope > > > > > > sec 2: > > > > The model organization can itself be thought of as a "meta-model", > > in that it describes the relationships between individual > models. We > > choose to represent it also as simple YANG model consisting of > lists > > and containers to serve as anchor points for the corresponding > > individual models. > > > > As shown below, our model is rooted at a "device", which > represents a > > network router, switch, or similar network element. > > > > > > Why is this a meta-model? > because the aim to to show how other models inter-relate rather than > define the details of all models. As stated in the intro: > > This document aims to provide an extensible structure that can be > used to tie together other models. It allows for existing, emerging, > and future models. The overall structure can be constructed using > YANG augmentation and imports. > > > OK -- the YANG modules themselves should say how they > relate to each other. I guess you mean the logical-network-element > and other framework nodes. as well as the overall presented structure. > > > > > It looks like a real YANG data model where ad-hoc classification is > > being done > > using container names. > > Sure, we're using YANG, or at least trying, to document our proposal. > Do you think there's a better way to formally document the work? > > > > So this document is not the actual set of NP containers > that all YANG modules are supposed to augment? > It would help to understand how the tree will be managed > and maintained over time. I think we're open on this and this is a bit of the point of section 3. If you/the WG think there's a 'right' way to do this, we'd like to hear it. > > > > > > If vendors augment this tree with their own ad-hoc hierarchy, then how > > is this > > any better than what we have now? > > > This goes to requirements which is really in the scope of > draft-openconfig-netmod-model-structure. From my perspective it comes > down to how much information is needed from an actual device in order to > come up with its yang-based configuration, and the principle that there > is benefit in this being minimized. For example, consider the case > where a config is generated before a specific device is fielded or > perhaps even purchased/selected. But again, this more of a requirements > discussion. > > > If a vendor has their own proprietary protocol or HW type, > where does it go in the tree? The set of modules used for some > function may not be coupled to one node in the data tree. > > But it is OK if this is out of scope. > It is no different than any other standard module that a vendor > could augment with proprietary data. > > > > > What is the scope of this work? > see slide 7 of > https://www.ietf.org/proceedings/93/slides/slides-93-rtgwg-3.pdf > > > It appears to be only for "routers switches or similar network > elements". > > > From the slide: > From DT charter: An overall architecture for > “the protocols and functionality contained inside the Routing Area” > > > The hierarchy seems quite router-centric. > It is intended to be network device centric, routers, switches, > firewalls, etc. > > > So what is the plan for YANG modules that are not specific to these devices? If the module relates to something beyond device config, it would go elsewhere, e.g. /services - but this is a question for the organization of those models. > For example, some modules like interfaces and NACM could be > implemented on any platform, even constrained devices > (maybe running CoMI over CoAP). > And the same is true for the device model > > > > Is the expectation that all YANG-based devices will use this > > data hierarchy, or only some devices? > The proposal is to provide a framework for any device that supports a > protocol or other mechanism defined within the routing area. (Or at > least that's our understanding of what we were asked to do.) > > > > I understand the value of finding data via familiar keywords. > (The CLI never went away -- it just grew angle brackets ;-) > It is useful to be able to debug with nothing more than a > WEB browser and URLs typed by hand. I could never remember > a single SNMP OID but YANG data is easy to remember. > > From the start, the NETCONF and NETMOD WGs rejected > attempts at data organization because it should not matter > to a programmatic API. > > > > > > Is the expectation that all YANG modules will use this > > data hierarchy, or only some modules? > > I personally think there will be siblings to /device, e.g., /service - > but this is beyond the scope of this draft. > > > Is it just > > for IETF routing modules or more than that? > > > I think this is the same question and answer as above. > > > Q2) interfaces > > > > The interface model is taken from [RFC7223 > ] and includes possible > > technology-specific augmentations using example technologies > defined > > in [RFC7277 ]. > > +--rw interfaces > > | +--rw interface* [name] > > | +--rw name string > > | +--rw bind-network-element-id? uint8 > > | +--rw ethernet > > | | +--rw bind-networking-instance-name? string > > | | +--rw aggregates > > | | +--rw rstp > > | | +--rw lldp > > | | +--rw ptp > > | +--rw vlans > > | +--rw tunnels > > | +--rw ipv4 > > | | +--rw bind-networking-instance-name? string > > | | +--rw arp > > | | +--rw icmp > > | | +--rw vrrp > > | | +--rw dhcp-client > > | +--rw ipv6 > > | +--rw bind-networking-instance-name? string > > | +--rw vrrp > > | +--rw icmpv6 > > | +--rw nd > > | +--rw dhcpv6-client > > > > > > Actually the interface model is quite different than the one in > RFC 7223. > > Seems rather ethernet-centric. I notice the "type" leaf was removed, > > along with everything else. Is the plan to toss out RFC 7223, > > recharter the interfaces work, and start over? > > > > So this may be our/my inexperience at play here. I didn't think it > appropriate for a document that is augmenting an existing model to > redefine the current model - I actually thought this was part of the > power of YANG augmentation. Are you saying we should have included the > whole 7223 model to augment it, or something different? > > > > I did not find any augment statements in model-structure.yang. looks like a bug. > > You have to augment /interfaces, not /device/interfaces, > if you are using RFC 7223. > Well this is certainly a part of the debate. A bigger issue is actually 7317 (system management) which ends up deeper in the tree and, consequently, just dropping /device doesn't solve anything. > > > Also not the text says: > ... possible technology-specific augmentations using example > technologies .. > and > > The interfaces container includes a number of commonly used > components as examples: > > > Q3) virtual devices > > > > The model supports the potentially independent system management > > functions and configuration per logical network element. This > > permits, for example, different users to manage either the whole > > device or just the associated logical network element. > > > > Sec 2.2.1 shows the system management tree but it is wrong. > > Yes, good catch of a cut-and-past bug. thankfully it is correct both > immediately before in the section intro and the details > > > The following tree is what the YANG model defines: > > +--rw device > > +--rw logical-network-elements > > -rw logical-network-element* [network-element-id] > > +--rw network-element-id uint8 > > +--rw network-element-name? string > > +--rw default-networking-instance-name? string > > +--rw system-management > > | +--rw device-view? boolean > > | +--rw syslog > > | +--rw dns > > | +--rw ntp > > | +--rw statistics-collection > > | +--rw ssh > > | +--rw tacacs > > | +--rw snmp > > | +--rw netconf > > What about devices that do not have logical network elements? > It would have only a single network-element-id > > > This hierarchy may be appropriate for very large routers > > but nothing else. > The intent is to cover all implementations independent of vendors. We > had a good range of view points both in the DT and in the RTGWG > discussion. Not saying there was full agreement, just that we have a > proposed starting point. > > > How can this tree represent both the physical view and the virtual > view? > Are you referring to section 2.3? If so, I think we all agree (and said > as much in Prague) that this section could be clearer. We/I tried to > explain it in the Prague slide 25 (for this you may want to see the > animation in > https://www.ietf.org/proceedings/93/slides/slides-93-rtgwg-3.pptx) > > Basically the amount of information provided depends on the > logical-network-element context used to access this information. So if > a model is "retrieved" via an IP address associated with a > network-element-id with device-view=true (e.g., the left side of slide > 25), then the device's full view is provided. And when a model is > "retrieved" via an IP address associated with a network-element-id with > device-view=false (e.g., the ride side of slide 25, either color) only > information related to the network-element-id is provided. > > > > IMO this logical structure should not be part of data hierarchy itself, > since it does not apply to all devices. > > YANG does not provide a way for the hierarchy to be > one way for the physical view and another for > a virtual view. again, I think you're mixing things here. Per slide 10 of https://www.ietf.org/proceedings/93/slides/slides-93-rtgwg-3.pdf there's device-view which is used as part of representing things like logical systems. and device type which is that the device may be VM or hardware based and the device shouldn't really operate or be managed differently. > The same /path/to/data is seen by both. > Is this really what you want? Think so. > > > > > It seems to assume this is the "root user physical view". > > Please explain how device-type=VIRTUAL is used. > > This is a bit different and hasn't been a major point of discussion in > the WG -- we brought this over from the openconfig draft. I read this > as being pretty uninteresting and simply set based on if the device is > running on dedicated special purpose h/w (e.g, a classic > "name-your-vendor" router) or as a VM (aka NFV). I'll defer to the OC > or other DT folks if their opinion differs. > > > Each virtual view sees its own slice of the physical device as an > entire device, not as 1 entry in a more complex model. you're talking logical-network-element, right? > > IMO it would be better to define a separate data structure and > tag it as a special nested datastore root. (e.g. YANG mount). > > Maybe this would work: > > container virtual-devices { > list virtual-device { > key device-id; > ... > container device { > // same data models as the /device contents > } > } > } > > container device { ... } > If I understand your point, (although virtual-device = logical-network-element) this is pretty close to what we discussed at one point. Two issues came up: 1- this implied, at least to us more substantive impact on the interface model - some were in favor, but in the end the decision was to minimize impact to the existing model. 2- where do unassigned resources go? In the current proposal they are simply unassigned, rather than needing to automatically show in a 'default' logical-network-element/device. Probably worth discussing this further. Thanks, Lou > > > Thanks for the comments/discussion! > > Lou > > > Andy > > > > > > Andy > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > From nobody Wed Aug 19 19:23:36 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F471A8F49 for ; Wed, 19 Aug 2015 19:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQxm0OiLxG5D for ; Wed, 19 Aug 2015 19:23:32 -0700 (PDT) Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by ietfa.amsl.com (Postfix) with SMTP id 8B1881A8F41 for ; Wed, 19 Aug 2015 19:23:29 -0700 (PDT) Received: (qmail 29747 invoked by uid 0); 20 Aug 2015 02:23:29 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy1.mail.unifiedlayer.com with SMTP; 20 Aug 2015 02:23:29 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id 6qPJ1r00C2SSUrH01qPMX0; Wed, 19 Aug 2015 20:23:28 -0600 X-Authority-Analysis: v=2.1 cv=EbVbHpWC c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=4g2epv4a4k0A:10 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=uRRa74qj2VoA:10 a=48vgC7mUAAAA:8 a=dn1_87I5VKBHnakj0ewA:9 a=Sz6WW2GsXg6M490A:21 a=mkX3MEf9549SjOBS:21 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=aVb8YwGwJQdvvGAynX8TG6XevONJy9DqAixF6q+oO1Y=; b=ZNxNzXoM9o7XtJcJHgKmXESMvboMhSIF2caK3GewKLsOpLBVi4OyYuPH00PE0DS2DvuIVNVnU4N0neR01cyAi6SAMfeRy1P0L+6AF7NFyI8F/qgMa2Uy4bXUnRAplhd4; Received: from box313.bluehost.com ([69.89.31.113]:41441 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZSFVe-000465-Ec; Wed, 19 Aug 2015 20:23:18 -0600 Message-ID: <55D53A13.4080505@labn.net> Date: Wed, 19 Aug 2015 22:23:15 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Martin Bjorklund References: <55D3DDFC.2080107@labn.net> <20150819.112730.1689479932571514728.mbj@tail-f.com> In-Reply-To: <20150819.112730.1689479932571514728.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: rtgwg@ietf.org, netmod@ietf.org, draft-rtgyangdt-rtgwg-device-model@ietf.org Subject: Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 02:23:34 -0000 Martin, See below. On 08/19/2015 05:27 AM, Martin Bjorklund wrote: > Hi, > > Lou Berger wrote: >> On 8/18/2015 8:01 PM, Andy Bierman wrote: >>> Q1) scope >>> >>> >>> sec 2: >>> >>> The model organization can itself be thought of as a "meta-model", >>> in that it describes the relationships between individual models. We >>> choose to represent it also as simple YANG model consisting of lists >>> and containers to serve as anchor points for the corresponding >>> individual models. >>> >>> As shown below, our model is rooted at a "device", which represents a >>> network router, switch, or similar network element. >>> >>> >>> Why is this a meta-model? >> because the aim to to show how other models inter-relate rather than >> define the details of all models. As stated in the intro: >> >> This document aims to provide an extensible structure that can be >> used to tie together other models. It allows for existing, emerging, >> and future models. The overall structure can be constructed using >> YANG augmentation and imports. >> >> >>> It looks like a real YANG data model where ad-hoc classification is >>> being done >>> using container names. >> >> Sure, we're using YANG, or at least trying, to document our proposal. >> Do you think there's a better way to formally document the work? > > I can see two approaches: > > 1) Define a YANG module with the structural hierarchy. Then > other modules augment this module at the correct place in the > hierarchy. This module will probably be updated pretty often, > especially if the idea to have ONE module with the complete > hierarchy for ALL types of devices. > > A variant is to define such a module for routing-specific modules > only to augment. Other areas can define similar "structural" > modules. > Or device additions can augment the base model. > 2) Document the hierarchy as a guideline. When it is time to work > on a new module, lets say mpls, we look into this guideline and > define the necessary hierarchy in the mpls module. > I think this is a good topic to discuss. The second sounds lighter weight as long as it is followed while the first makes it hard to not follow. I see advantages in both. > >>> If vendors augment this tree with their own ad-hoc hierarchy, then how >>> is this >>> any better than what we have now? >>> >> This goes to requirements which is really in the scope of >> draft-openconfig-netmod-model-structure. From my perspective it comes >> down to how much information is needed from an actual device in order to >> come up with its yang-based configuration, and the principle that there >> is benefit in this being minimized. For example, consider the case >> where a config is generated before a specific device is fielded or >> perhaps even purchased/selected. > > As long as the device implements standard data models, why does it > matter for pre-provisioning if the standard path to configure an > interface is /devices/interfaces/interface or /interfaces/interface? > I personally see the top level as more about logical separation of model types/classes, like a top level directory structure. So IMO it's a bit subjective and really about establish and agreeing upon conventions. -- and there's a group of users who say they really like it one way. Deeper in the hierarchy the path becomes more significant, but you weren't really questioning this. >>> What is the scope of this work? >> see slide 7 of >> https://www.ietf.org/proceedings/93/slides/slides-93-rtgwg-3.pdf >> >>> It appears to be only for "routers switches or similar network elements". >>> >> >From the slide: >> From DT charter: An overall architecture for >> “the protocols and functionality contained inside the Routing Area” > > But the design you propose has huge impact on all models, also models > from other areas. A very fair point and why it's important to discuss in this WG. No discussion happened in the prague session largely due to multiple scheduling conflicts. > >>> Q2) interfaces >>> >>> The interface model is taken from [RFC7223 ] and includes possible >>> technology-specific augmentations using example technologies defined >>> in [RFC7277 ]. >>> +--rw interfaces >>> | +--rw interface* [name] >>> | +--rw name string >>> | +--rw bind-network-element-id? uint8 >>> | +--rw ethernet >>> | | +--rw bind-networking-instance-name? string >>> | | +--rw aggregates >>> | | +--rw rstp >>> | | +--rw lldp >>> | | +--rw ptp >>> | +--rw vlans >>> | +--rw tunnels >>> | +--rw ipv4 >>> | | +--rw bind-networking-instance-name? string >>> | | +--rw arp >>> | | +--rw icmp >>> | | +--rw vrrp >>> | | +--rw dhcp-client >>> | +--rw ipv6 >>> | +--rw bind-networking-instance-name? string >>> | +--rw vrrp >>> | +--rw icmpv6 >>> | +--rw nd >>> | +--rw dhcpv6-client >>> >>> >>> Actually the interface model is quite different than the one in RFC 7223. >>> Seems rather ethernet-centric. I notice the "type" leaf was removed, >>> along with everything else. Is the plan to toss out RFC 7223, >>> recharter the interfaces work, and start over? >>> >> >> So this may be our/my inexperience at play here. I didn't think it >> appropriate for a document that is augmenting an existing model to >> redefine the current model - I actually thought this was part of the >> power of YANG augmentation. Are you saying we should have included the >> whole 7223 model to augment it, or something different? > > As long as you want to have /device/interfaces, you need to obsolete > the model in RFC 7223 (and all other published YANG models) and > rewrite them. However, if we get rid of the /device container, the > existing model in RFC 7223 fit in nicely in your hierarchy. And this is certainly an important point, and I personally think we should have a full discussion of if it's worth preserving RFC 7223 or open the door for changing it. We had many discussions on this in the DT and while multiple wanted to do an even larger change, in the end the consensus was to try minimize impact to the this and other RFCs -- even if it meant using somewhat more cumbersome mechanisms. > > I think many of us have said this before, but the top-level container > /device doesn't really solve any problem. Suppose we have a module > today with a top-level node /FOO. Why would this module work better > if it augemented /device to give /device/FOO? > as mentioned above, I personally think this is about logical separation of model types/classes, like a top level directory structure. So IMO it's a bit subjective and really about establish and agreeing upon conventions. -- and there's a group of users who say they really like it one way. > Maybe the problem you are trying to solve with "/device" is what is > written in section 3.1: > > One of the challenges in assembling existing YANG models is that they > are generally written with the assumption that each model is at the > root of the configuration or state tree. Combining models then > results in a multi-rooted tree that does not follow any logical > construction and makes it difficult to work with operationally. In > some cases, models explicitly reference other models (e.g., via > augmentation) to define a relationship, but this is the case for only > a few existing models. > > First of all I don't really agree with this. We just have a few > module published, but for example ietf-ip augments ietf-interfaces, > and the idea with ietf-routing is that routing-specific modules > augment it. In fact, I think the published modules follow your > proposed hierarchy (with some exception) - if it wasn't for the > /device node. > > Second, if we want to be conservative with top-level nodes (I am not > convinced that this is a problem) we can solve that without going into > the extreme of having *one* top-level node. Why do you say only one top level node. This isn't my exception, nor do I see this stated in the draft. I do think we say one top level node dealing with device configuration. > Instead of having N > top-level nodes, we would have N nodes under /device. Why is this > better? N would contain only device configuration related modules. There could be others, e.g., /services has been mentioned by some. > >> Are you referring to section 2.3? If so, I think we all agree (and said >> as much in Prague) that this section could be clearer. We/I tried to >> explain it in the Prague slide 25 (for this you may want to see the >> animation in >> https://www.ietf.org/proceedings/93/slides/slides-93-rtgwg-3.pptx) >> >> Basically the amount of information provided depends on the >> logical-network-element context used to access this information. So if >> a model is "retrieved" via an IP address associated with a >> network-element-id with device-view=true (e.g., the left side of slide >> 25), then the device's full view is provided. And when a model is >> "retrieved" via an IP address associated with a network-element-id with >> device-view=false (e.g., the ride side of slide 25, either color) only >> information related to the network-element-id is provided. > > Do you want the user from a particular IP address to have access to > just his part of the tree, or do you want that user to have his own > "sandbox" that he can control independently of other users? The intent was multiple logical-network-elements and when device-view=false, any management operation taking place in the context of that LNE would only have visibility and ability to control that LNE. This matches a pretty common feature set. > > In the first case, you can use NACM to set up rules to give each user > proper access (based on user identity rather than IP address though). I think this would be used too. For example user1 would have ro access while user2 has rw. > You don't need this "device-view" in order to do this. Agreed, but this is something different and matches how a multiple devices from multiple vendors function today. > > In the latter case, I don't think the proposed design works. (I can > go into details if it turns out that this what you had in mind). I think we're interested in a form of the first. Lou > > > > /martin > From nobody Wed Aug 19 19:31:29 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1C651A9008 for ; Wed, 19 Aug 2015 19:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0FUB3i2do0kt for ; Wed, 19 Aug 2015 19:31:25 -0700 (PDT) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id 7E6E31A8F50 for ; Wed, 19 Aug 2015 19:31:25 -0700 (PDT) Received: (qmail 29612 invoked by uid 0); 20 Aug 2015 02:31:19 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy2.mail.unifiedlayer.com with SMTP; 20 Aug 2015 02:31:19 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id 6qXE1r0012SSUrH01qXHib; Wed, 19 Aug 2015 20:31:18 -0600 X-Authority-Analysis: v=2.1 cv=EbVbHpWC c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=4g2epv4a4k0A:10 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=uRRa74qj2VoA:10 a=48vgC7mUAAAA:8 a=gkdtDajsWwLqmO3Mto4A:9 a=eqejzZtndsl9Yf3K:21 a=hvPfSzf2mG6uObun:21 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=shxWceI27m2WNZc4nsZ1CFaYDdmFn1mwzE5jwhZ+r0w=; b=LfQaPNLfHJ3MCOpQpkWzC2BpYxLldqgLsNpsQMwEFpIsIycDghKDQprmavGr6QmcP8wmTpFV27HVnoe6z9HIX35zfSB6T7yxXh4Ufv5xejHagnZvtX1En/YnGw1XUYud; Received: from box313.bluehost.com ([69.89.31.113]:42071 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZSFdK-0005Md-JC; Wed, 19 Aug 2015 20:31:14 -0600 Message-ID: <55D53BEF.2060009@labn.net> Date: Wed, 19 Aug 2015 22:31:11 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Nadeau Thomas References: <55D3DDFC.2080107@labn.net> <29B312B3-287D-4E61-8447-CFDF8F6C1734@lucidvision.com> In-Reply-To: <29B312B3-287D-4E61-8447-CFDF8F6C1734@lucidvision.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: Routing WG , netmod WG , draft-rtgyangdt-rtgwg-device-model@ietf.org Subject: Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 02:31:28 -0000 On 08/19/2015 08:48 AM, Nadeau Thomas wrote: > >> On Aug 18, 2015:9:38 PM, at 9:38 PM, Lou Berger wrote: >> >> [Adding authors and RTG WG.] >> >> Hi Andy, >> I'm not sure who you are looking to hear from as you addressed this >> mail to the netmod list. I'm happy to give my opinion as it seems you >> might have been aiming this at the draft authors. (but then again >> perhaps not.) >> >> On 8/18/2015 8:01 PM, Andy Bierman wrote: >>> Hi, >>> >>> I assume this draft is what we should be reviewing and not >>> the obsolete openconfig draft? >> >> My personal view / hope is that the openconfig draft will be revised to >> cover requirements > > Can you be specific about which requirements you feel are not covered ? > > Tom > I wasn't commenting on what's covered/not covered. I was saying that I don't think the openconfig draft should disappear, rather it should be revised to just focus on requirements. Lou > >> while the DT draft leads to an agreed upon approach >> to addressing those requirements. Again, just stating my view, not the >> view of the DT, co-authors or OC draft authors. >> >>> >>> >>> https://tools.ietf.org/html/draft-rtgyangdt-rtgwg-device-model-00 >>> >>> >>> Q1) scope >>> >>> >>> sec 2: >>> >>> The model organization can itself be thought of as a "meta-model", >>> in that it describes the relationships between individual models. We >>> choose to represent it also as simple YANG model consisting of lists >>> and containers to serve as anchor points for the corresponding >>> individual models. >>> >>> As shown below, our model is rooted at a "device", which represents a >>> network router, switch, or similar network element. >>> >>> >>> Why is this a meta-model? >> because the aim to to show how other models inter-relate rather than >> define the details of all models. As stated in the intro: >> >> This document aims to provide an extensible structure that can be >> used to tie together other models. It allows for existing, emerging, >> and future models. The overall structure can be constructed using >> YANG augmentation and imports. >> >> >>> It looks like a real YANG data model where ad-hoc classification is >>> being done >>> using container names. >> >> Sure, we're using YANG, or at least trying, to document our proposal. >> Do you think there's a better way to formally document the work? >> >>> >>> If vendors augment this tree with their own ad-hoc hierarchy, then how >>> is this >>> any better than what we have now? >>> >> This goes to requirements which is really in the scope of >> draft-openconfig-netmod-model-structure. From my perspective it comes >> down to how much information is needed from an actual device in order to >> come up with its yang-based configuration, and the principle that there >> is benefit in this being minimized. For example, consider the case >> where a config is generated before a specific device is fielded or >> perhaps even purchased/selected. But again, this more of a requirements >> discussion. >> >>> What is the scope of this work? >> see slide 7 of >> https://www.ietf.org/proceedings/93/slides/slides-93-rtgwg-3.pdf >> >>> It appears to be only for "routers switches or similar network elements". >>> >>> From the slide: >> From DT charter: An overall architecture for >> the protocols and functionality contained inside the Routing Area >> >>> The hierarchy seems quite router-centric. >> It is intended to be network device centric, routers, switches, >> firewalls, etc. >> >>> Is the expectation that all YANG-based devices will use this >>> data hierarchy, or only some devices? >> The proposal is to provide a framework for any device that supports a >> protocol or other mechanism defined within the routing area. (Or at >> least that's our understanding of what we were asked to do.) >> >>> >>> Is the expectation that all YANG modules will use this >>> data hierarchy, or only some modules? >> >> I personally think there will be siblings to /device, e.g., /service - >> but this is beyond the scope of this draft. >> >>> Is it just >>> for IETF routing modules or more than that? >>> >> I think this is the same question and answer as above. >> >>> Q2) interfaces >>> >>> The interface model is taken from [RFC7223 ] and includes possible >>> technology-specific augmentations using example technologies defined >>> in [RFC7277 ]. >>> +--rw interfaces >>> | +--rw interface* [name] >>> | +--rw name string >>> | +--rw bind-network-element-id? uint8 >>> | +--rw ethernet >>> | | +--rw bind-networking-instance-name? string >>> | | +--rw aggregates >>> | | +--rw rstp >>> | | +--rw lldp >>> | | +--rw ptp >>> | +--rw vlans >>> | +--rw tunnels >>> | +--rw ipv4 >>> | | +--rw bind-networking-instance-name? string >>> | | +--rw arp >>> | | +--rw icmp >>> | | +--rw vrrp >>> | | +--rw dhcp-client >>> | +--rw ipv6 >>> | +--rw bind-networking-instance-name? string >>> | +--rw vrrp >>> | +--rw icmpv6 >>> | +--rw nd >>> | +--rw dhcpv6-client >>> >>> >>> Actually the interface model is quite different than the one in RFC 7223. >>> Seems rather ethernet-centric. I notice the "type" leaf was removed, >>> along with everything else. Is the plan to toss out RFC 7223, >>> recharter the interfaces work, and start over? >>> >> >> So this may be our/my inexperience at play here. I didn't think it >> appropriate for a document that is augmenting an existing model to >> redefine the current model - I actually thought this was part of the >> power of YANG augmentation. Are you saying we should have included the >> whole 7223 model to augment it, or something different? >> >> Also not the text says: >> ... possible technology-specific augmentations using example >> technologies .. >> and >> >> The interfaces container includes a number of commonly used >> components as examples: >> >>> Q3) virtual devices >>> >>> The model supports the potentially independent system management >>> functions and configuration per logical network element. This >>> permits, for example, different users to manage either the whole >>> device or just the associated logical network element. >>> >>> Sec 2.2.1 shows the system management tree but it is wrong. >> >> Yes, good catch of a cut-and-past bug. thankfully it is correct both >> immediately before in the section intro and the details >> >>> The following tree is what the YANG model defines: >>> +--rw device >>> +--rw logical-network-elements >>> -rw logical-network-element* [network-element-id] >>> +--rw network-element-id uint8 >>> +--rw network-element-name? string >>> +--rw default-networking-instance-name? string >>> +--rw system-management >>> | +--rw device-view? boolean >>> | +--rw syslog >>> | +--rw dns >>> | +--rw ntp >>> | +--rw statistics-collection >>> | +--rw ssh >>> | +--rw tacacs >>> | +--rw snmp >>> | +--rw netconf >>> What about devices that do not have logical network elements? >> It would have only a single network-element-id >> >>> This hierarchy may be appropriate for very large routers >>> but nothing else. >> The intent is to cover all implementations independent of vendors. We >> had a good range of view points both in the DT and in the RTGWG >> discussion. Not saying there was full agreement, just that we have a >> proposed starting point. >> >>> How can this tree represent both the physical view and the virtual view? >> Are you referring to section 2.3? If so, I think we all agree (and said >> as much in Prague) that this section could be clearer. We/I tried to >> explain it in the Prague slide 25 (for this you may want to see the >> animation in >> https://www.ietf.org/proceedings/93/slides/slides-93-rtgwg-3.pptx) >> >> Basically the amount of information provided depends on the >> logical-network-element context used to access this information. So if >> a model is "retrieved" via an IP address associated with a >> network-element-id with device-view=true (e.g., the left side of slide >> 25), then the device's full view is provided. And when a model is >> "retrieved" via an IP address associated with a network-element-id with >> device-view=false (e.g., the ride side of slide 25, either color) only >> information related to the network-element-id is provided. >> >>> It seems to assume this is the "root user physical view". >>> Please explain how device-type=VIRTUAL is used. >> >> This is a bit different and hasn't been a major point of discussion in >> the WG -- we brought this over from the openconfig draft. I read this >> as being pretty uninteresting and simply set based on if the device is >> running on dedicated special purpose h/w (e.g, a classic >> "name-your-vendor" router) or as a VM (aka NFV). I'll defer to the OC >> or other DT folks if their opinion differs. >> >> Thanks for the comments/discussion! >> >> Lou >> >>> Andy >>> >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > From nobody Wed Aug 19 21:28:53 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6041A92B5 for ; Wed, 19 Aug 2015 21:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNtfmbY2BgBk for ; Wed, 19 Aug 2015 21:28:46 -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 292491A88DA for ; Wed, 19 Aug 2015 21:28:45 -0700 (PDT) Received: by laba3 with SMTP id a3so15262506lab.1 for ; Wed, 19 Aug 2015 21:28: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=ByZG+K+xhchNBjIlac+BTKPT0TSRQGY5Y+93XLJdLec=; b=BQC+Yq48ZVH9STpy2sJGKflIiVIcK7xYOTX/NzD+xkZs4lB2/YH5OspxgGADQSRgX+ 8Bj7YrQs00ihYGpX82Afdxut+m3VKeOrAyAcIyBnPNv76JMWI3fWn4HCpYFov5WBcmrg NJe5f8YeEi+XTUYxHHc+/PIs2VwmMN6OjyvJpEu8oTu6JToL21L8dslnFa60uiaH7cJp 3EiBrMRu0JPP7fpAcBfyCaqdER3RT2fNt0+L/VuoRDvgPCFCUSaDDxZGlMm/qViZ8xI6 pju99py8nVL766KrxesZw/RFyTUmlN+nOtwyXrF/KgpMwc14SHtmCoiEJfs53Cj10iCu 64nw== X-Gm-Message-State: ALoCoQn8uP/OUHYudV/kmA5ZQyRGd0XuNUnj0iJb8ql99gO/96G8RfkIMvUL6KAtzs7wjtX/tGID MIME-Version: 1.0 X-Received: by 10.112.141.136 with SMTP id ro8mr1039496lbb.88.1440044923507; Wed, 19 Aug 2015 21:28:43 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Wed, 19 Aug 2015 21:28:43 -0700 (PDT) In-Reply-To: <20150819.194934.461244528814584733.mbj@tail-f.com> References: <9B232151-C380-4B43-BAF4-88F7E4821B8D@nic.cz> <20150819.144900.231414608010857635.mbj@tail-f.com> <20150819.194934.461244528814584733.mbj@tail-f.com> Date: Wed, 19 Aug 2015 21:28:43 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11c343c0206fe3051db6965b Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] extensions and conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 04:28:51 -0000 --001a11c343c0206fe3051db6965b Content-Type: text/plain; charset=UTF-8 On Wed, Aug 19, 2015 at 10:49 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Wed, Aug 19, 2015 at 5:49 AM, Martin Bjorklund > wrote: > > > > > Hi, > > > > > > [joining this discussion a bit late] > > > > > > Ladislav Lhotka wrote: > > > > > > > > > On 10 Aug 2015, at 18:46, Andy Bierman wrote: > > > > > > > > > > > > > > > > > > > > On Mon, Aug 10, 2015 at 9:37 AM, Ladislav Lhotka > > > > > wrote: > > > > > > > > > > > On 10 Aug 2015, at 17:32, Andy Bierman > wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Aug 10, 2015 at 4:24 AM, Ladislav Lhotka > > > > > > wrote: > > > > > > > > > > > > > On 10 Aug 2015, at 12:17, Andy Bierman > wrote: > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > I am strongly against changing the contract on extensions. > > > > > > > They MAY be ignored by any YANG tool. Period. > > > > > > > That means they are far from mandatory. > > > > > > > They are little more than a keyword and a description clause. > > > > > > > > > > > > So do you prefer my proposed solution -02 or -03? > > > > > > > > > > > > ** Solution Yxx-03 > > > > > > > > > > > > Make extensions optional. This means that extensions won't be > > > > > > allowed to change YANG language, NETCONF protocol, and > validity of > > > > > > datastores and protocol messages. > > > > > > > > > > > > > > > > > > This is how we use extensions to tag YANG data models > > > > > > to drive automation tools. > > > > > > > > > > But that means, for example, that annotations cannot be defined > via an > > > > > extension statement as in draft-ietf-netmod-yang-metadata. > > > > > > > > > > > > > > > > > > > > Which means these statements should be real instead of extensions. > > > > > If the statements are defining data that is exchanged between > > > > > peers in a standard protocol, then YANG extensions are not > > > > > appropriate. > > > > > > > > I agree, and -03 is my preferred solution, too. > > > > > > I strongly disagree. IMO the IETF usage of extensions so far (NACM, > > > annotations) works well (in the case of NACM proven by multiple > > > independent implementations), and follows how extensions were intended > > > to be used, and obviously, how the WG has understood them up until > > > now. > > > > > > If the sentence: > > > > > > If a YANG compiler does not support a particular extension, which > > > appears in a YANG module as an unknown-statement (see Section 12), > > > the entire unknown-statement MAY be ignored by the compiler. > > > > > > in 6020 can be interpreted to mean that an occurance of an extension > > > is non-normative, we should fix it so that it matches what was > > > intended and how it is used. > > > > > > Juergen suggested this replacement text, which I support. Maybe it > > > can be improved even more. > > > > > > If a YANG parser does not support a particular extension, which > > > appears in a YANG module as an unknown-statement (see Section > 13), > > > the entire unknown-statement MAY be ignored by the parser. Note > > > that even in this case the semantics associated with the > extension > > > still apply (as if they were part of a description statement). > > > > > > > > > > I strongly disagree with this change. > > This would mean that every tool is required to support the > > semantics of every extension ever defined. > > No. It means that if a server advertises module that uses some > extension to define some behaviour, the server supports that > behavior. Just as we expect a server to support the text in > description statements. > > For example, the nacm: extensions do not apply unless ietf-netconf-acm > is advertised (and nacm is enabled). I expect most extensions to work > this way. Another example is if we actually defined i2rs:ephemeral; > this would have no effect unless the "i2rs" capability (whatever that > is) is also advertised. > > The text also means that it is perfectly ok for a client to ignore the > extension if it doesn't understand it. For example, if the client has > no idea what the ephemeral datastore it, it doesn't matter that a node > is marked with i2rs:ephemeral true. > > > For example, > > we have our own extensions that cause the server to > > perform internal tasks certain ways (like ywx:sil-delete-children-first). > > > > According to the text you propose, all servers would have to > > provide the behavior embodied in the syntax of this extension > > statement? > > Yes, all servers that advertise such a module. B/c as you note below > it is "well-behaved". So the defintion probably says something like > "if the server implements SIL, then it will delete the children before > it deletes the node itself". > > > This extension does not alter any protocol behavior > > at all, so it is "well-behaved". > > > > A server MAY skip over the entire extension and completely ignore it. > > Other servers are not required to provide the behavior described > > in the extension semantics. > > Yes. Aren't we in agreement here? > > > No -- I agree with Randy's interpretation of MAY. However, IMO description-stmts are normative, so if plain text in the NACM RFC says the nacm YANG extensions MUST be supported, then I think that makes it mandatory. YANG conformance does not make it mandatory. We are in agreement if you mean the RFC or module containing the YANG extension can define the conformance for the extension. But I don't agree that statements related to data handling and datastores should ever be extensions. IMO NACM extensions should really be YANG 1.1 keywords and the extensions should be deprecated. I like YANG extensions -- they are like the minor leagues for YANG statements. :-) But once they are stable and there is consensus they are useful, they should probably be made mandatory by converting them to regular statements. > /martin > > Andy > > > > > > > > > > > However, I do agree that an extension cannot "undo" semantics defined > > > by other YANG statements, just as you cannot do that in a description > > > statement. For example, this would be illegal: > > > > > > leaf foo { > > > type int32; > > > description "The type is really a string."; > > > } > > > > > > leaf bar { > > > type int32; > > > xx:real-type string; > > > } > > > > > > It is also a Very Bad Idea (speaking from experience...) to define an > > > extension that introduces new data nodes. > > > > > > The text about "MAY ignore" was meant to capture this. It's supposed > > > to be like for a client that doesn't understand an augemntation; it > > > can skip it. A client that doesn't understand nacm:default-deny-all > > > works just fine and can safely ignore it. > > > > > > > > > /martin > > > > > > > > > Andy > --001a11c343c0206fe3051db6965b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Aug 19, 2015 at 10:49 AM, Martin Bjorklund &l= t;mbj@tail-f.com>= ; wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Wed, Aug 19, 2015 at 5:49 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Hi,
> >
> > [joining this discussion a bit late]
> >
> > Ladislav Lhotka <lhotka@nic.c= z> wrote:
> > >
> > > > On 10 Aug 2015, at 18:46, Andy Bierman <andy@yumaworks.com> wrote:
> > > >
> > > >
> > > >
> > > > On Mon, Aug 10, 2015 at 9:37 AM, Ladislav Lhotka <lhotka@nic.cz>
> > > > wrote:
> > > >
> > > > > On 10 Aug 2015, at 17:32, Andy Bierman <andy@yumaworks.com> wrote:
> > > > >
> > > > >
> > > > >
> > > > > On Mon, Aug 10, 2015 at 4:24 AM, Ladislav Lhotka &= lt;lhotka@nic.cz>
> > > > > wrote:
> > > > >
> > > > > > On 10 Aug 2015, at 12:17, Andy Bierman <andy@yumaworks.com> wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I am strongly against changing the contract o= n extensions.
> > > > > > They MAY be ignored by any YANG tool. Period.=
> > > > > > That means they are far from mandatory.
> > > > > > They are little more than a keyword and a des= cription clause.
> > > > >
> > > > > So do you prefer my proposed solution -02 or -03?<= br> > > > > >
> > > > > ** Solution Yxx-03
> > > > >
> > > > >=C2=A0 =C2=A0 Make extensions optional. This means = that extensions won't be
> > > > >=C2=A0 =C2=A0 allowed to change YANG language, NETC= ONF protocol, and validity of
> > > > >=C2=A0 =C2=A0 datastores and protocol messages.
> > > > >
> > > > >
> > > > > This is how we use extensions to tag YANG data mod= els
> > > > > to drive automation tools.
> > > >
> > > > But that means, for example, that annotations cannot be= defined via an
> > > > extension statement as in draft-ietf-netmod-yang-metada= ta.
> > > >
> > > >
> > > >
> > > > Which means these statements should be real instead of = extensions.
> > > > If the statements are defining data that is exchanged b= etween
> > > > peers in a standard protocol, then YANG extensions are = not
> > > > appropriate.
> > >
> > > I agree, and -03 is my preferred solution, too.
> >
> > I strongly disagree.=C2=A0 IMO the IETF usage of extensions so fa= r (NACM,
> > annotations) works well (in the case of NACM proven by multiple > > independent implementations), and follows how extensions were int= ended
> > to be used, and obviously, how the WG has understood them up unti= l
> > now.
> >
> > If the sentence:
> >
> >=C2=A0 =C2=A0 If a YANG compiler does not support a particular ext= ension, which
> >=C2=A0 =C2=A0 appears in a YANG module as an unknown-statement (se= e Section 12),
> >=C2=A0 =C2=A0 the entire unknown-statement MAY be ignored by the c= ompiler.
> >
> > in 6020 can be interpreted to mean that an occurance of an extens= ion
> > is non-normative, we should fix it so that it matches what was > > intended and how it is used.
> >
> > Juergen suggested this replacement text, which I support.=C2=A0 M= aybe it
> > can be improved even more.
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 If a YANG parser does not support a pa= rticular extension, which
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 appears in a YANG module as an unknown= -statement (see Section 13),
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 the entire unknown-statement MAY be ig= nored by the parser. Note
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 that even in this case the semantics a= ssociated with the extension
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 still apply (as if they were part of a= description statement).
> >
> >
>
> I strongly disagree with this change.
> This would mean that every tool is required to support the
> semantics of every extension ever defined.

No.=C2=A0 It means that if a server advertises module that uses some
extension to define some behaviour, the server supports that
behavior.=C2=A0 Just as we expect a server to support the text in
description statements.

For example, the nacm: extensions do not apply unless ietf-netconf-acm
is advertised (and nacm is enabled).=C2=A0 I expect most extensions to work=
this way.=C2=A0 Another example is if we actually defined i2rs:ephemeral; this would have no effect unless the "i2rs" capability (whatever = that
is) is also advertised.

The text also means that it is perfectly ok for a client to ignore the
extension if it doesn't understand it.=C2=A0 For example, if the client= has
no idea what the ephemeral datastore it, it doesn't matter that a node<= br> is marked with i2rs:ephemeral true.

> For example,
> we have our own extensions that cause the server to
> perform internal tasks certain ways (like ywx:sil-delete-children-firs= t).
>
> According to the text you propose, all servers would have to
> provide the behavior embodied in the syntax of this extension
> statement?

Yes, all servers that advertise such a module.=C2=A0 B/c as you note below<= br> it is "well-behaved".=C2=A0 So the defintion probably says someth= ing like
"if the server implements SIL, then it will delete the children before=
it deletes the node itself".

> This extension does not alter any protocol behavior
> at all, so it is "well-behaved".
>
> A server MAY skip over the entire extension and completely ignore it.<= br> > Other servers are not required to provide the behavior described
> in the extension semantics.

Yes.=C2=A0 Aren't we in agreement here?



No -- I agree with Randy's interpr= etation of MAY.

However, IMO description-stmts are= normative, so if plain text in
the NACM RFC says the nacm YANG e= xtensions MUST be supported,
then I think that makes it mandatory= .

YANG conformance does not make it mandatory.

We are in agreement if you mean the RFC or module
containing the YANG extension can define the conformance for the ext= ension.

But I don't agree that statements rela= ted to data handling and
datastores should ever be extensions. IM= O NACM extensions
should really be YANG 1.1 keywords and the exte= nsions should
be deprecated.

I like YANG= extensions -- they are like the minor leagues for YANG statements. :-)
But once they are stable and there is consensus they are useful, the= y should
probably be made mandatory by converting them to regular= statements.


=C2=A0
/martin



Andy
=C2=A0


>
>
>
> > However, I do agree that an extension cannot "undo" sem= antics defined
> > by other YANG statements, just as you cannot do that in a descrip= tion
> > statement.=C2=A0 For example, this would be illegal:
> >
> >=C2=A0 =C2=A0leaf foo {
> >=C2=A0 =C2=A0 =C2=A0type int32;
> >=C2=A0 =C2=A0 =C2=A0description "The type is really a string.= ";
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0leaf bar {
> >=C2=A0 =C2=A0 =C2=A0type int32;
> >=C2=A0 =C2=A0 =C2=A0xx:real-type string;
> >=C2=A0 =C2=A0}
> >
> > It is also a Very Bad Idea (speaking from experience...) to defin= e an
> > extension that introduces new data nodes.
> >
> > The text about "MAY ignore" was meant to capture this.= =C2=A0 It's supposed
> > to be like for a client that doesn't understand an augemntati= on; it
> > can skip it.=C2=A0 A client that doesn't understand nacm:defa= ult-deny-all
> > works just fine and can safely ignore it.
> >
> >
> > /martin
> >
>
>
> Andy

--001a11c343c0206fe3051db6965b-- From nobody Wed Aug 19 21:39:11 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E471AD359 for ; Wed, 19 Aug 2015 21:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VnyGlLqVuCFy for ; Wed, 19 Aug 2015 21:39:07 -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 3FB811ACED1 for ; Wed, 19 Aug 2015 21:39:07 -0700 (PDT) Received: by lbbtg9 with SMTP id tg9so16268703lbb.1 for ; Wed, 19 Aug 2015 21:39:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=p46MDN+dyc/Jxm2/eENuQdNgIRZQU1396vpq+c/Jmz4=; b=HH8NMlHcJM+NNSRReqj6wapP0F+G2N/+YlGKRinZGCGb+dnsJfYKQl944qEzJmJs9E dIEsRj1aFh8k0c1Gzg8Ptlf4R2CRzEFOVK5ExkQ9fQdQhrbPIgSJbya9Kb1+uN54YNcQ 6e47+6auegnTdhB5qi0YxtERvLVECvFAjTxpDbmnPWW6AuCBj0T4m7XHf+qPKp2RBW6i Dl8RWCJjdfSC32PQ1B/Gn8E4g8lJWX/haxjr2sXnUYwhSrytIwkhhX3GfeEIfcTrRk+u iXxhdjPWlRriG8jnHeq/Lbx+ohS019FB1L3x4RqiU4dr7cvquyfNhgNaNUzjG22fuS2l OPww== X-Gm-Message-State: ALoCoQkCm6cflrpOn2/sGD2RLhyRV3dzjlfv8lEp4C/pp8tu5OeJLr0xqctXyjNu+BFSpRGQru0v MIME-Version: 1.0 X-Received: by 10.152.120.74 with SMTP id la10mr1027295lab.37.1440045545683; Wed, 19 Aug 2015 21:39:05 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Wed, 19 Aug 2015 21:39:05 -0700 (PDT) In-Reply-To: <20150819.132555.871710491924929960.mbj@tail-f.com> References: <55D36473.90609@cisco.com> <55D45CAF.2070605@cisco.com> <20150819.132555.871710491924929960.mbj@tail-f.com> Date: Wed, 19 Aug 2015 21:39:05 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=089e012290223615b4051db6bbd1 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y34 - root node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 04:39:09 -0000 --089e012290223615b4051db6bbd1 Content-Type: text/plain; charset=UTF-8 On Wed, Aug 19, 2015 at 4:25 AM, Martin Bjorklund wrote: > Robert Wilton wrote: > > > > > > On 18/08/2015 18:22, Andy Bierman wrote: > > > This is how languages like SMIv2 and YANG work. > > > A conceptual object is given a permanent "home" within the tree of > > > object identifiers. > > > Moving data is very expensive, since any clients working with the old > > > data > > > will break as soon as the data is moved. > > > > > > I am not convinced the IETF can or should come up with a set of > > > containers > > > that covers every possible topic that can be modeled in YANG. > > > > I mostly agree, but having some more structure/advice as to where to > > place YANG modules may be helpful. I'm thinking more along the lines > > of broad categories rather than precise locations. > > +1 > > > > If someone wants to builds a YANG controller node that is managing > > > the configuration for a network of devices then wouldn't they want > > > a particular device's interface configuration to be located > > > somewhere like /network/device//interfaces/interface? > > > Ideally, they would be able to use the same YANG definitions that > > > are defined for /interfaces/ but root them relative to > > > /network/device//. > > > > > > > > > > > > Yes -- some of us (like Martin) have pointed this out many times. > > > The "device" container on an NE does not help at all wrt/ > > > aggregation on a controller. "/device" or "/" work the same for this > > > purpose. > > Actually, I would argue that / works better. On the controller, you > probably have a list of devices you control (this is how our NCS > works, and how ODL works (I have been told)): > > container devices { > list device { > key name; > // meta-info about the device goes here, things like > // ip-address, port, auth info... > container data { > // all models supported by the devices are "mounted" here > } > } > } > > So on the controller, the path to interface "eth0" on device "foo" > would be: > > /devices/device[name='foo']/data/interfaces/interface[name='eth0'] > > if we also have a top-level "/device" container we'd have: > > /devices/device[name='foo']/data/device/interfaces/interface[name='eth0'] > > > What would the real resource location for > > "/network/device//interfaces/interface" be? > > I don't think there is such a thing as a "real" location. The path is > scoped in the system you work with; in the controller it might be as I > illustrated above, in the device it starts with /interfaces, but in a > controller-of-controllers it might be: > > /domains/domain[name='bar']/devices/device[name='foo']/data > /interfaces/interface[name='eth0'] > > Currently we have a proprietary way of "relocating" YANG modules, and > ODL has its "mount", and I think Andy has some other mechanism. Maybe > the time has come to standardize how mount works, and maybe then also > standardize the list of devices in a controller model. > > +1 We just need to standardize a "docroot within a docroot". This is not relocation of subtrees within the datastore, this is just mounting a datastore somewhere within a parent datastore. In YANG validation terms, you simply adjust the docroot to the nested mount point, and the replicated datastore can be used as if it were stand-alone. This would allow any sort of encapsulation of datastores and not add any data model complexity to devices which do not have virtual servers (most of them). > > /martin > Andy --089e012290223615b4051db6bbd1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Aug 19, 2015 at 4:25 AM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Robert Wilton <rwilton@cisco.com> wrote:
>
>
> On 18/08/2015 18:22, Andy Bierman wrote:
> > This is how languages like SMIv2 and YANG work.
> > A conceptual object is given a permanent "home" within = the tree of
> > object identifiers.
> > Moving data is very expensive, since any clients working with the= old
> > data
> > will break as soon as the data is moved.
> >
> >=C2=A0 I am not convinced the IETF can or should come up with a se= t of
> >=C2=A0 containers
> > that covers every possible topic that can be modeled in YANG.
>
> I mostly agree, but having some more structure/advice as to where to > place YANG modules may be helpful.=C2=A0 I'm thinking more along t= he lines
> of broad categories rather than precise locations.

+1

> >=C2=A0 =C2=A0 =C2=A0If someone wants to builds a YANG controller n= ode that is managing
> >=C2=A0 =C2=A0 =C2=A0the configuration for a network of devices the= n wouldn't they want
> >=C2=A0 =C2=A0 =C2=A0a particular device's interface configurat= ion to be located
> >=C2=A0 =C2=A0 =C2=A0somewhere like /network/device/<device-name= >/interfaces/interface?
> >=C2=A0 =C2=A0 =C2=A0Ideally, they would be able to use the same YA= NG definitions that
> >=C2=A0 =C2=A0 =C2=A0are defined for /interfaces/ but root them rel= ative to
> >=C2=A0 =C2=A0 =C2=A0/network/device/<device-name>/.
> >
> >
> >
> > Yes -- some of us (like Martin) have pointed this out many times.=
> > The "device" container on an NE does not help at all wr= t/
> > aggregation on a controller. "/device" or "/"= work the same for this
> > purpose.

Actually, I would argue that / works better.=C2=A0 On the controller, you probably have a list of devices you control (this is how our NCS
works, and how ODL works (I have been told)):

=C2=A0 container devices {
=C2=A0 =C2=A0 list device {
=C2=A0 =C2=A0 =C2=A0 key name;
=C2=A0 =C2=A0 =C2=A0 // meta-info about the device goes here, things like =C2=A0 =C2=A0 =C2=A0 // ip-address, port, auth info...
=C2=A0 =C2=A0 =C2=A0 container data {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 // all models supported by the devices are &quo= t;mounted" here
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }
=C2=A0 }

So on the controller, the path to interface "eth0" on device &quo= t;foo"
would be:

=C2=A0 /devices/device[name=3D'foo']/data/interfaces/interface[name= =3D'eth0']

if we also have a top-level "/device" container we'd have:
=C2=A0 /devices/device[name=3D'foo']/data/device/interfaces/interfa= ce[name=3D'eth0']

> What would the real resource location for
> "/network/device/<device-name>/interfaces/interface" b= e?

I don't think there is such a thing as a "real" location.=C2= =A0 The path is
scoped in the system you work with; in the controller it might be as I
illustrated above, in the device it starts with /interfaces, but in a
controller-of-controllers it might be:

=C2=A0 /domains/domain[name=3D'bar']/devices/device[name=3D'foo= ']/data
=C2=A0 =C2=A0 /interfaces/interface[name=3D'eth0']

Currently we have a proprietary way of "relocating" YANG modules,= and
ODL has its "mount", and I think Andy has some other mechanism.= =C2=A0 Maybe
the time has come to standardize how mount works, and maybe then also
standardize the list of devices in a controller model.



+1

We just n= eed to standardize a "docroot within a docroot".
This i= s not relocation of subtrees within the datastore, this is just mounting
a datastore somewhere within a parent datastore.

In YANG validation terms, you simply adjust the docroot to the neste= d mount point,
and the replicated datastore can be used as if it = were stand-alone.
This would allow any sort of encapsulation of d= atastores and not add any
data model complexity to devices which = do not have virtual servers
(most of them).
=C2=A0

/martin


<= /div>
Andy

--089e012290223615b4051db6bbd1-- From nobody Wed Aug 19 23:43:33 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8251B2C2A for ; Wed, 19 Aug 2015 23:43:32 -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 kbCUFGxHcg2k for ; Wed, 19 Aug 2015 23:43:30 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 847761B2C29 for ; Wed, 19 Aug 2015 23:43:30 -0700 (PDT) Received: from localhost (unknown [173.38.220.43]) by mail.tail-f.com (Postfix) with ESMTPSA id 6F58D1AE035B; Thu, 20 Aug 2015 08:43:28 +0200 (CEST) Date: Thu, 20 Aug 2015 08:43:27 +0200 (CEST) Message-Id: <20150820.084327.1894555709749612426.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <16753832.1440031521612.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net> References: <16753832.1440031521612.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] extensions and conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 06:43:32 -0000 Randy Presuhn wrote: > Hi - > > >From: Martin Bjorklund > >Sent: Aug 19, 2015 10:49 AM > >To: andy@yumaworks.com > >Cc: netmod@ietf.org > >Subject: Re: [netmod] extensions and conformance > ... > >> > Juergen suggested this replacement text, which I support. Maybe it > >> > can be improved even more. > >> > > >> > If a YANG parser does not support a particular extension, which > >> > appears in a YANG module as an unknown-statement (see Section 13), > >> > the entire unknown-statement MAY be ignored by the parser. Note > >> > that even in this case the semantics associated with the extension > >> > still apply (as if they were part of a description statement). > ... > >No. It means that if a server advertises module that uses some > >extension to define some behaviour, the server supports that > >behavior. Just as we expect a server to support the text in > >description statements. > > Sorry, but that interpretation is not supported by the 2119 definition > of MAY. Note that the original text says "if x then MAY y". Juergen's text says the same. Maybe this should be rephrased... /martin > >For example, the nacm: extensions do not apply unless ietf-netconf-acm > >is advertised (and nacm is enabled). I expect most extensions to work > >this way. Another example is if we actually defined i2rs:ephemeral; > >this would have no effect unless the "i2rs" capability (whatever that > >is) is also advertised. > > > >The text also means that it is perfectly ok for a client to ignore the > >extension if it doesn't understand it. For example, if the client has > >no idea what the ephemeral datastore it, it doesn't matter that a node > >is marked with i2rs:ephemeral true. > > You are describing something stronger than a naked MAY. > > You're describing an "if x MUST y". If the conformance requirement > is truly simply MAY, then support is OPTIONAL even if the system > claims conformance. > > Randy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Thu Aug 20 00:59:00 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C72881A1BBD; Thu, 20 Aug 2015 00:58: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 2d7zIXuE8JhW; Thu, 20 Aug 2015 00:58:56 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id AE69B1A1BB9; Thu, 20 Aug 2015 00:58:55 -0700 (PDT) Received: from localhost (unknown [173.38.220.43]) by mail.tail-f.com (Postfix) with ESMTPSA id 90B441AE035B; Thu, 20 Aug 2015 09:58:53 +0200 (CEST) Date: Thu, 20 Aug 2015 09:58:53 +0200 (CEST) Message-Id: <20150820.095853.255503105278478154.mbj@tail-f.com> To: lberger@labn.net From: Martin Bjorklund In-Reply-To: <55D53A13.4080505@labn.net> References: <55D3DDFC.2080107@labn.net> <20150819.112730.1689479932571514728.mbj@tail-f.com> <55D53A13.4080505@labn.net> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: rtgwg@ietf.org, netmod@ietf.org, draft-rtgyangdt-rtgwg-device-model@ietf.org Subject: Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 07:58:59 -0000 TG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5ldD4gd3JvdGU6DQo+IE1hcnRpbiwNCj4gDQo+IFNl ZSBiZWxvdy4NCj4gT24gMDgvMTkvMjAxNSAwNToyNyBBTSwgTWFydGluIEJqb3JrbHVuZCB3cm90 ZToNCj4gPiBIaSwNCj4gPiANCj4gPiBMb3UgQmVyZ2VyIDxsYmVyZ2VyQGxhYm4ubmV0PiB3cm90 ZToNCj4gPj4gT24gOC8xOC8yMDE1IDg6MDEgUE0sIEFuZHkgQmllcm1hbiB3cm90ZToNCj4gPj4+ IFExKSBzY29wZQ0KPiA+Pj4NCj4gPj4+DQo+ID4+PiBzZWMgMjoNCj4gPj4+DQo+ID4+PiAgICBU aGUgbW9kZWwgb3JnYW5pemF0aW9uIGNhbiBpdHNlbGYgYmUgdGhvdWdodCBvZiBhcyBhICJtZXRh LW1vZGVsIiwNCj4gPj4+ICAgIGluIHRoYXQgaXQgZGVzY3JpYmVzIHRoZSByZWxhdGlvbnNoaXBz IGJldHdlZW4gaW5kaXZpZHVhbCBtb2RlbHMuICBXZQ0KPiA+Pj4gICAgY2hvb3NlIHRvIHJlcHJl c2VudCBpdCBhbHNvIGFzIHNpbXBsZSBZQU5HIG1vZGVsIGNvbnNpc3Rpbmcgb2YgbGlzdHMNCj4g Pj4+ICAgIGFuZCBjb250YWluZXJzIHRvIHNlcnZlIGFzIGFuY2hvciBwb2ludHMgZm9yIHRoZSBj b3JyZXNwb25kaW5nDQo+ID4+PiAgICBpbmRpdmlkdWFsIG1vZGVscy4NCj4gPj4+DQo+ID4+PiAg ICBBcyBzaG93biBiZWxvdywgb3VyIG1vZGVsIGlzIHJvb3RlZCBhdCBhICJkZXZpY2UiLCB3aGlj aCByZXByZXNlbnRzIGENCj4gPj4+ICAgIG5ldHdvcmsgcm91dGVyLCBzd2l0Y2gsIG9yIHNpbWls YXIgbmV0d29yayBlbGVtZW50LiAgDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IFdoeSBpcyB0aGlzIGEg bWV0YS1tb2RlbD8NCj4gPj4gYmVjYXVzZSB0aGUgYWltIHRvIHRvIHNob3cgaG93IG90aGVyIG1v ZGVscyBpbnRlci1yZWxhdGUgcmF0aGVyIHRoYW4NCj4gPj4gZGVmaW5lIHRoZSBkZXRhaWxzIG9m IGFsbCBtb2RlbHMuIEFzIHN0YXRlZCBpbiB0aGUgaW50cm86DQo+ID4+DQo+ID4+ICAgIFRoaXMg ZG9jdW1lbnQgYWltcyB0byBwcm92aWRlIGFuIGV4dGVuc2libGUgc3RydWN0dXJlIHRoYXQgY2Fu IGJlDQo+ID4+ICAgIHVzZWQgdG8gdGllIHRvZ2V0aGVyIG90aGVyIG1vZGVscy4gSXQgYWxsb3dz IGZvciBleGlzdGluZywgZW1lcmdpbmcsDQo+ID4+ICAgIGFuZCBmdXR1cmUgbW9kZWxzLiBUaGUg b3ZlcmFsbCBzdHJ1Y3R1cmUgY2FuIGJlIGNvbnN0cnVjdGVkIHVzaW5nDQo+ID4+ICAgIFlBTkcg YXVnbWVudGF0aW9uIGFuZCBpbXBvcnRzLg0KPiA+Pg0KPiA+Pg0KPiA+Pj4gSXQgbG9va3MgbGlr ZSBhIHJlYWwgWUFORyBkYXRhIG1vZGVsIHdoZXJlIGFkLWhvYyBjbGFzc2lmaWNhdGlvbiBpcw0K PiA+Pj4gYmVpbmcgZG9uZQ0KPiA+Pj4gdXNpbmcgY29udGFpbmVyIG5hbWVzLg0KPiA+Pg0KPiA+ PiBTdXJlLCB3ZSdyZSB1c2luZyBZQU5HLCBvciBhdCBsZWFzdCB0cnlpbmcsIHRvIGRvY3VtZW50 IG91ciBwcm9wb3NhbC4gDQo+ID4+IERvIHlvdSB0aGluayB0aGVyZSdzIGEgYmV0dGVyIHdheSB0 byBmb3JtYWxseSBkb2N1bWVudCB0aGUgd29yaz8NCj4gPiANCj4gPiBJIGNhbiBzZWUgdHdvIGFw cHJvYWNoZXM6DQo+ID4gDQo+ID4gICAxKSBEZWZpbmUgYSBZQU5HIG1vZHVsZSB3aXRoIHRoZSBz dHJ1Y3R1cmFsIGhpZXJhcmNoeS4gIFRoZW4NCj4gPiAgICAgIG90aGVyIG1vZHVsZXMgYXVnbWVu dCB0aGlzIG1vZHVsZSBhdCB0aGUgY29ycmVjdCBwbGFjZSBpbiB0aGUNCj4gPiAgICAgIGhpZXJh cmNoeS4gIFRoaXMgbW9kdWxlIHdpbGwgcHJvYmFibHkgYmUgdXBkYXRlZCBwcmV0dHkgb2Z0ZW4s DQo+ID4gICAgICBlc3BlY2lhbGx5IGlmIHRoZSBpZGVhIHRvIGhhdmUgT05FIG1vZHVsZSB3aXRo IHRoZSBjb21wbGV0ZQ0KPiA+ICAgICAgaGllcmFyY2h5IGZvciBBTEwgdHlwZXMgb2YgZGV2aWNl cy4NCj4gPiANCj4gPiAgICAgIEEgdmFyaWFudCBpcyB0byBkZWZpbmUgc3VjaCBhIG1vZHVsZSBm b3Igcm91dGluZy1zcGVjaWZpYyBtb2R1bGVzDQo+ID4gICAgICBvbmx5IHRvIGF1Z21lbnQuICBP dGhlciBhcmVhcyBjYW4gZGVmaW5lIHNpbWlsYXIgInN0cnVjdHVyYWwiDQo+ID4gICAgICBtb2R1 bGVzLg0KPiA+IA0KPiBPciBkZXZpY2UgYWRkaXRpb25zIGNhbiBhdWdtZW50IHRoZSBiYXNlIG1v ZGVsLg0KPiANCj4gPiAgIDIpIERvY3VtZW50IHRoZSBoaWVyYXJjaHkgYXMgYSBndWlkZWxpbmUu ICBXaGVuIGl0IGlzIHRpbWUgdG8gd29yaw0KPiA+ICAgICAgb24gYSBuZXcgbW9kdWxlLCBsZXRz IHNheSBtcGxzLCB3ZSBsb29rIGludG8gdGhpcyBndWlkZWxpbmUgYW5kDQo+ID4gICAgICBkZWZp bmUgdGhlIG5lY2Vzc2FyeSBoaWVyYXJjaHkgaW4gdGhlIG1wbHMgbW9kdWxlLg0KPiA+IA0KPiAN Cj4gSSB0aGluayB0aGlzIGlzIGEgZ29vZCB0b3BpYyB0byBkaXNjdXNzLiAgVGhlIHNlY29uZCBz b3VuZHMgbGlnaHRlcg0KPiB3ZWlnaHQgYXMgbG9uZyBhcyBpdCBpcyBmb2xsb3dlZCB3aGlsZSB0 aGUgZmlyc3QgbWFrZXMgaXQgaGFyZCB0byBub3QNCj4gZm9sbG93LiBJIHNlZSBhZHZhbnRhZ2Vz IGluIGJvdGguDQo+IA0KPiA+IA0KPiA+Pj4gSWYgdmVuZG9ycyBhdWdtZW50IHRoaXMgdHJlZSB3 aXRoIHRoZWlyIG93biBhZC1ob2MgaGllcmFyY2h5LCB0aGVuIGhvdw0KPiA+Pj4gaXMgdGhpcw0K PiA+Pj4gYW55IGJldHRlciB0aGFuIHdoYXQgd2UgaGF2ZSBub3c/DQo+ID4+Pg0KPiA+PiBUaGlz IGdvZXMgdG8gcmVxdWlyZW1lbnRzIHdoaWNoIGlzIHJlYWxseSBpbiB0aGUgc2NvcGUgb2YNCj4g Pj4gZHJhZnQtb3BlbmNvbmZpZy1uZXRtb2QtbW9kZWwtc3RydWN0dXJlLiAgRnJvbSBteSBwZXJz cGVjdGl2ZSBpdCBjb21lcw0KPiA+PiBkb3duIHRvIGhvdyBtdWNoIGluZm9ybWF0aW9uIGlzIG5l ZWRlZCBmcm9tIGFuIGFjdHVhbCBkZXZpY2UgaW4gb3JkZXIgdG8NCj4gPj4gY29tZSB1cCB3aXRo IGl0cyB5YW5nLWJhc2VkIGNvbmZpZ3VyYXRpb24sIGFuZCB0aGUgcHJpbmNpcGxlIHRoYXQgdGhl cmUNCj4gPj4gaXMgYmVuZWZpdCBpbiB0aGlzIGJlaW5nIG1pbmltaXplZC4gIEZvciBleGFtcGxl LCBjb25zaWRlciB0aGUgY2FzZQ0KPiA+PiB3aGVyZSBhIGNvbmZpZyBpcyBnZW5lcmF0ZWQgYmVm b3JlIGEgc3BlY2lmaWMgZGV2aWNlIGlzIGZpZWxkZWQgb3INCj4gPj4gcGVyaGFwcyBldmVuIHB1 cmNoYXNlZC9zZWxlY3RlZC4NCj4gPiANCj4gPiBBcyBsb25nIGFzIHRoZSBkZXZpY2UgaW1wbGVt ZW50cyBzdGFuZGFyZCBkYXRhIG1vZGVscywgd2h5IGRvZXMgaXQNCj4gPiBtYXR0ZXIgZm9yIHBy ZS1wcm92aXNpb25pbmcgaWYgdGhlIHN0YW5kYXJkIHBhdGggdG8gY29uZmlndXJlIGFuDQo+ID4g aW50ZXJmYWNlIGlzIC9kZXZpY2VzL2ludGVyZmFjZXMvaW50ZXJmYWNlIG9yIC9pbnRlcmZhY2Vz L2ludGVyZmFjZT8NCj4gPiANCj4gDQo+IEkgcGVyc29uYWxseSBzZWUgdGhlIHRvcCBsZXZlbCBh cyBtb3JlIGFib3V0IGxvZ2ljYWwgc2VwYXJhdGlvbiBvZiBtb2RlbA0KPiB0eXBlcy9jbGFzc2Vz DQoNClRoaXMgdGhlbiBzb3VuZHMgbGlrZSBtZXRhIGRhdGEgYWJvdXQgdGhlIG1vZGVsLiAgV2hh dCBraW5kIG9mIG1vZGVsDQppcyBpdCAtIHNlZSBkcmFmdC1ib2dkYW5vdmljLW5ldG1vZC15YW5n LW1vZGVsLWNsYXNzaWZpY2F0aW9uLg0KDQpJIGRvbid0IHRoaW5rIGl0IGlzIGEgZ29vZCBpZGVh IHRvIGVuY29kZSBtZXRhIGRhdGEgaW50byB0aGUgZGF0YQ0KaGllcmFyY2h5LiAgSXQgd291bGQg YmUgYmV0dGVyIElNTyB0byBrZWVwIHRoaXMgZWl0aGVyIGlubGluZSBpbiB0aGUNCm1vZHVsZSBk ZWZpbml0aW9uICh5YW5nLW1vZGVsLXR5cGUgZGV2aWNlOykgb3IgZXh0ZXJuYWxseSBpbiBhDQpz ZXBhcmF0ZSByZWdpc3RyeS4NCg0KDQo+IGxpa2UgYSB0b3AgbGV2ZWwgZGlyZWN0b3J5IHN0cnVj dHVyZS4gIFNvIElNTyBpdCdzIGEgYml0DQo+IHN1YmplY3RpdmUgYW5kIHJlYWxseSBhYm91dCBl c3RhYmxpc2ggYW5kIGFncmVlaW5nIHVwb24gY29udmVudGlvbnMuIC0tDQo+IGFuZCB0aGVyZSdz IGEgZ3JvdXAgb2YgdXNlcnMgd2hvIHNheSB0aGV5IHJlYWxseSBsaWtlIGl0IG9uZSB3YXkuDQo+ IA0KPiBEZWVwZXIgaW4gdGhlIGhpZXJhcmNoeSB0aGUgcGF0aCBiZWNvbWVzIG1vcmUgc2lnbmlm aWNhbnQsIGJ1dCB5b3UNCj4gd2VyZW4ndCByZWFsbHkgcXVlc3Rpb25pbmcgdGhpcy4NCg0KSSBh bSBhbGwgZm9yIHNpZ25pZmljYW50IG5vZGVzIGluIHRoZSBwYXRoISAgTXkgcG9pbnQgaXMgdGhh dCAvZGV2aWNlDQppcyBpbnNpZ25pZmljYW50Lg0KDQoNCj4gPj4+IFdoYXQgaXMgdGhlIHNjb3Bl IG9mIHRoaXMgd29yaz8NCj4gPj4gc2VlIHNsaWRlIDcgb2YNCj4gPj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvcHJvY2VlZGluZ3MvOTMvc2xpZGVzL3NsaWRlcy05My1ydGd3Zy0zLnBkZg0KPiA+Pg0K PiA+Pj4gSXQgYXBwZWFycyB0byBiZSBvbmx5IGZvciAicm91dGVycyBzd2l0Y2hlcyBvciBzaW1p bGFyIG5ldHdvcmsgZWxlbWVudHMiLg0KPiA+Pj4NCj4gPj4gPkZyb20gdGhlIHNsaWRlOg0KPiA+ PiAgICBGcm9tIERUIGNoYXJ0ZXI6IEFuIG92ZXJhbGwgYXJjaGl0ZWN0dXJlIGZvcg0KPiA+PiAg ICDigJx0aGUgcHJvdG9jb2xzIGFuZCBmdW5jdGlvbmFsaXR5IGNvbnRhaW5lZCBpbnNpZGUgdGhl IFJvdXRpbmcgQXJlYeKAnQ0KPiA+IA0KPiA+IEJ1dCB0aGUgZGVzaWduIHlvdSBwcm9wb3NlIGhh cyBodWdlIGltcGFjdCBvbiBhbGwgbW9kZWxzLCBhbHNvIG1vZGVscw0KPiA+IGZyb20gb3RoZXIg YXJlYXMuDQo+IA0KPiBBIHZlcnkgZmFpciBwb2ludCBhbmQgd2h5IGl0J3MgaW1wb3J0YW50IHRv IGRpc2N1c3MgaW4gdGhpcyBXRy4gIE5vDQo+IGRpc2N1c3Npb24gaGFwcGVuZWQgaW4gdGhlIHBy YWd1ZSBzZXNzaW9uIGxhcmdlbHkgZHVlIHRvIG11bHRpcGxlDQo+IHNjaGVkdWxpbmcgY29uZmxp Y3RzLg0KPiANCj4gPiANCj4gPj4+IFEyKSBpbnRlcmZhY2VzDQo+ID4+Pg0KPiA+Pj4gICAgVGhl IGludGVyZmFjZSBtb2RlbCBpcyB0YWtlbiBmcm9tIFtSRkM3MjIzIDxodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvcmZjNzIyMz5dIGFuZCBpbmNsdWRlcyBwb3NzaWJsZQ0KPiA+Pj4gICAgdGVj aG5vbG9neS1zcGVjaWZpYyBhdWdtZW50YXRpb25zIHVzaW5nIGV4YW1wbGUgdGVjaG5vbG9naWVz IGRlZmluZWQNCj4gPj4+ICAgIGluIFtSRkM3Mjc3IDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvcmZjNzI3Nz5dLg0KPiA+Pj4gICArLS1ydyBpbnRlcmZhY2VzDQo+ID4+PiAgICAgICB8ICAr LS1ydyBpbnRlcmZhY2UqIFtuYW1lXQ0KPiA+Pj4gICAgICAgfCAgICAgKy0tcncgbmFtZSAgICAg ICAgICAgICAgICAgICAgICAgc3RyaW5nDQo+ID4+PiAgICAgICB8ICAgICArLS1ydyBiaW5kLW5l dHdvcmstZWxlbWVudC1pZD8gICB1aW50OA0KPiA+Pj4gICAgICAgfCAgICAgKy0tcncgZXRoZXJu ZXQNCj4gPj4+ICAgICAgIHwgICAgIHwgICstLXJ3IGJpbmQtbmV0d29ya2luZy1pbnN0YW5jZS1u YW1lPyAgIHN0cmluZw0KPiA+Pj4gICAgICAgfCAgICAgfCAgKy0tcncgYWdncmVnYXRlcw0KPiA+ Pj4gICAgICAgfCAgICAgfCAgKy0tcncgcnN0cA0KPiA+Pj4gICAgICAgfCAgICAgfCAgKy0tcncg bGxkcA0KPiA+Pj4gICAgICAgfCAgICAgfCAgKy0tcncgcHRwDQo+ID4+PiAgICAgICB8ICAgICAr LS1ydyB2bGFucw0KPiA+Pj4gICAgICAgfCAgICAgKy0tcncgdHVubmVscw0KPiA+Pj4gICAgICAg fCAgICAgKy0tcncgaXB2NA0KPiA+Pj4gICAgICAgfCAgICAgfCAgKy0tcncgYmluZC1uZXR3b3Jr aW5nLWluc3RhbmNlLW5hbWU/ICAgc3RyaW5nDQo+ID4+PiAgICAgICB8ICAgICB8ICArLS1ydyBh cnANCj4gPj4+ICAgICAgIHwgICAgIHwgICstLXJ3IGljbXANCj4gPj4+ICAgICAgIHwgICAgIHwg ICstLXJ3IHZycnANCj4gPj4+ICAgICAgIHwgICAgIHwgICstLXJ3IGRoY3AtY2xpZW50DQo+ID4+ PiAgICAgICB8ICAgICArLS1ydyBpcHY2DQo+ID4+PiAgICAgICB8ICAgICAgICArLS1ydyBiaW5k LW5ldHdvcmtpbmctaW5zdGFuY2UtbmFtZT8gICBzdHJpbmcNCj4gPj4+ICAgICAgIHwgICAgICAg ICstLXJ3IHZycnANCj4gPj4+ICAgICAgIHwgICAgICAgICstLXJ3IGljbXB2Ng0KPiA+Pj4gICAg ICAgfCAgICAgICAgKy0tcncgbmQNCj4gPj4+ICAgICAgIHwgICAgICAgICstLXJ3IGRoY3B2Ni1j bGllbnQNCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gQWN0dWFsbHkgdGhlIGludGVyZmFjZSBtb2RlbCBp cyBxdWl0ZSBkaWZmZXJlbnQgdGhhbiB0aGUgb25lIGluIFJGQyA3MjIzLg0KPiA+Pj4gU2VlbXMg cmF0aGVyIGV0aGVybmV0LWNlbnRyaWMuICBJIG5vdGljZSB0aGUgInR5cGUiIGxlYWYgd2FzIHJl bW92ZWQsDQo+ID4+PiBhbG9uZyB3aXRoIGV2ZXJ5dGhpbmcgZWxzZS4gIElzIHRoZSBwbGFuIHRv IHRvc3Mgb3V0IFJGQyA3MjIzLA0KPiA+Pj4gcmVjaGFydGVyIHRoZSBpbnRlcmZhY2VzIHdvcmss IGFuZCBzdGFydCBvdmVyPw0KPiA+Pj4NCj4gPj4NCj4gPj4gU28gdGhpcyBtYXkgYmUgb3VyL215 IGluZXhwZXJpZW5jZSBhdCBwbGF5IGhlcmUuICBJIGRpZG4ndCB0aGluayBpdA0KPiA+PiBhcHBy b3ByaWF0ZSBmb3IgYSBkb2N1bWVudCB0aGF0IGlzIGF1Z21lbnRpbmcgYW4gZXhpc3RpbmcgbW9k ZWwgdG8NCj4gPj4gcmVkZWZpbmUgdGhlIGN1cnJlbnQgbW9kZWwgLSBJIGFjdHVhbGx5IHRob3Vn aHQgdGhpcyB3YXMgcGFydCBvZiB0aGUNCj4gPj4gcG93ZXIgb2YgWUFORyBhdWdtZW50YXRpb24u ICBBcmUgeW91IHNheWluZyB3ZSBzaG91bGQgaGF2ZSBpbmNsdWRlZCB0aGUNCj4gPj4gd2hvbGUg NzIyMyBtb2RlbCB0byBhdWdtZW50IGl0LCBvciBzb21ldGhpbmcgZGlmZmVyZW50Pw0KPiA+IA0K PiA+IEFzIGxvbmcgYXMgeW91IHdhbnQgdG8gaGF2ZSAvZGV2aWNlL2ludGVyZmFjZXMsIHlvdSBu ZWVkIHRvIG9ic29sZXRlDQo+ID4gdGhlIG1vZGVsIGluIFJGQyA3MjIzIChhbmQgYWxsIG90aGVy IHB1Ymxpc2hlZCBZQU5HIG1vZGVscykgYW5kDQo+ID4gcmV3cml0ZSB0aGVtLiAgSG93ZXZlciwg aWYgd2UgZ2V0IHJpZCBvZiB0aGUgL2RldmljZSBjb250YWluZXIsIHRoZQ0KPiA+IGV4aXN0aW5n IG1vZGVsIGluIFJGQyA3MjIzIGZpdCBpbiBuaWNlbHkgaW4geW91ciBoaWVyYXJjaHkuDQo+IA0K PiBBbmQgdGhpcyBpcyBjZXJ0YWlubHkgYW4gaW1wb3J0YW50IHBvaW50LCBhbmQgSSBwZXJzb25h bGx5IHRoaW5rIHdlDQo+IHNob3VsZCBoYXZlIGEgZnVsbCBkaXNjdXNzaW9uIG9mIGlmIGl0J3Mg d29ydGggcHJlc2VydmluZyBSRkMgNzIyMyBvcg0KPiBvcGVuIHRoZSBkb29yIGZvciBjaGFuZ2lu ZyAgaXQuICBXZSBoYWQgbWFueSBkaXNjdXNzaW9ucyBvbiB0aGlzIGluIHRoZQ0KPiBEVCBhbmQg d2hpbGUgbXVsdGlwbGUgd2FudGVkIHRvIGRvIGFuIGV2ZW4gbGFyZ2VyIGNoYW5nZSwgaW4gdGhl IGVuZCB0aGUNCj4gY29uc2Vuc3VzIHdhcyB0byB0cnkgbWluaW1pemUgaW1wYWN0IHRvIHRoZSB0 aGlzIGFuZCBvdGhlciBSRkNzIC0tIGV2ZW4NCj4gaWYgaXQgbWVhbnQgdXNpbmcgc29tZXdoYXQg bW9yZSBjdW1iZXJzb21lIG1lY2hhbmlzbXMuDQo+IA0KPiA+IA0KPiA+IEkgdGhpbmsgbWFueSBv ZiB1cyBoYXZlIHNhaWQgdGhpcyBiZWZvcmUsIGJ1dCB0aGUgdG9wLWxldmVsIGNvbnRhaW5lcg0K PiA+IC9kZXZpY2UgZG9lc24ndCByZWFsbHkgc29sdmUgYW55IHByb2JsZW0uICBTdXBwb3NlIHdl IGhhdmUgYSBtb2R1bGUNCj4gPiB0b2RheSB3aXRoIGEgdG9wLWxldmVsIG5vZGUgL0ZPTy4gIFdo eSB3b3VsZCB0aGlzIG1vZHVsZSB3b3JrIGJldHRlcg0KPiA+IGlmIGl0IGF1Z2VtZW50ZWQgL2Rl dmljZSB0byBnaXZlIC9kZXZpY2UvRk9PPw0KPiA+IA0KPiANCj4gYXMgbWVudGlvbmVkIGFib3Zl LCBJIHBlcnNvbmFsbHkgdGhpbmsgdGhpcyBpcyBhYm91dCBsb2dpY2FsIHNlcGFyYXRpb24NCj4g b2YgbW9kZWwgdHlwZXMvY2xhc3NlcywgbGlrZSBhIHRvcCBsZXZlbCBkaXJlY3Rvcnkgc3RydWN0 dXJlLiAgU28gSU1PDQo+IGl0J3MgYSBiaXQgc3ViamVjdGl2ZSBhbmQgcmVhbGx5IGFib3V0IGVz dGFibGlzaCBhbmQgYWdyZWVpbmcgdXBvbg0KPiBjb252ZW50aW9ucy4gLS0gYW5kIHRoZXJlJ3Mg YSBncm91cCBvZiB1c2VycyB3aG8gc2F5IHRoZXkgcmVhbGx5IGxpa2UgaXQNCj4gb25lIHdheS4N Cg0KSG9wZWZ1bGx5LCBhIGRlY2lzaW9uIHRvIGNoYW5nZSBhbGwgZXhpc3RpbmcgbW9kZWxzIChp bmNsdWRpbmcgdmVuZG9yDQptb2RlbHMhKSB3aWxsIGJlIGJhc2VkIG9uIHNvbWV0aGluZyBtb3Jl IHRlY2huaWNhbCB0aGFuIHRoZSBmYWN0IHRoYXQNCmEgZ3JvdXAgb2YgcGVvcGxlICJyZWFsbHkg bGlrZSBpdCIgc29tZSBvdGhlciB3YXkuDQoNCj4gPiBNYXliZSB0aGUgcHJvYmxlbSB5b3UgYXJl IHRyeWluZyB0byBzb2x2ZSB3aXRoICIvZGV2aWNlIiBpcyB3aGF0IGlzDQo+ID4gd3JpdHRlbiBp biBzZWN0aW9uIDMuMToNCj4gPiANCj4gPiAgICBPbmUgb2YgdGhlIGNoYWxsZW5nZXMgaW4gYXNz ZW1ibGluZyBleGlzdGluZyBZQU5HIG1vZGVscyBpcyB0aGF0IHRoZXkNCj4gPiAgICBhcmUgZ2Vu ZXJhbGx5IHdyaXR0ZW4gd2l0aCB0aGUgYXNzdW1wdGlvbiB0aGF0IGVhY2ggbW9kZWwgaXMgYXQg dGhlDQo+ID4gICAgcm9vdCBvZiB0aGUgY29uZmlndXJhdGlvbiBvciBzdGF0ZSB0cmVlLiAgQ29t YmluaW5nIG1vZGVscyB0aGVuDQo+ID4gICAgcmVzdWx0cyBpbiBhIG11bHRpLXJvb3RlZCB0cmVl IHRoYXQgZG9lcyBub3QgZm9sbG93IGFueSBsb2dpY2FsDQo+ID4gICAgY29uc3RydWN0aW9uIGFu ZCBtYWtlcyBpdCBkaWZmaWN1bHQgdG8gd29yayB3aXRoIG9wZXJhdGlvbmFsbHkuICBJbg0KPiA+ ICAgIHNvbWUgY2FzZXMsIG1vZGVscyBleHBsaWNpdGx5IHJlZmVyZW5jZSBvdGhlciBtb2RlbHMg KGUuZy4sIHZpYQ0KPiA+ICAgIGF1Z21lbnRhdGlvbikgdG8gZGVmaW5lIGEgcmVsYXRpb25zaGlw LCBidXQgdGhpcyBpcyB0aGUgY2FzZSBmb3Igb25seQ0KPiA+ICAgIGEgZmV3IGV4aXN0aW5nIG1v ZGVscy4NCj4gPiANCj4gPiBGaXJzdCBvZiBhbGwgSSBkb24ndCByZWFsbHkgYWdyZWUgd2l0aCB0 aGlzLiAgV2UganVzdCBoYXZlIGEgZmV3DQo+ID4gbW9kdWxlIHB1Ymxpc2hlZCwgYnV0IGZvciBl eGFtcGxlIGlldGYtaXAgYXVnbWVudHMgaWV0Zi1pbnRlcmZhY2VzLA0KPiA+IGFuZCB0aGUgaWRl YSB3aXRoIGlldGYtcm91dGluZyBpcyB0aGF0IHJvdXRpbmctc3BlY2lmaWMgbW9kdWxlcw0KPiA+ IGF1Z21lbnQgaXQuICBJbiBmYWN0LCBJIHRoaW5rIHRoZSBwdWJsaXNoZWQgbW9kdWxlcyBmb2xs b3cgeW91cg0KPiA+IHByb3Bvc2VkIGhpZXJhcmNoeSAod2l0aCBzb21lIGV4Y2VwdGlvbikgLSBp ZiBpdCB3YXNuJ3QgZm9yIHRoZQ0KPiA+IC9kZXZpY2Ugbm9kZS4NCj4gPiANCj4gPiBTZWNvbmQs IGlmIHdlIHdhbnQgdG8gYmUgY29uc2VydmF0aXZlIHdpdGggdG9wLWxldmVsIG5vZGVzIChJIGFt IG5vdA0KPiA+IGNvbnZpbmNlZCB0aGF0IHRoaXMgaXMgYSBwcm9ibGVtKSB3ZSBjYW4gc29sdmUg dGhhdCB3aXRob3V0IGdvaW5nIGludG8NCj4gPiB0aGUgZXh0cmVtZSBvZiBoYXZpbmcgKm9uZSog dG9wLWxldmVsIG5vZGUuICANCj4gDQo+IFdoeSBkbyB5b3Ugc2F5IG9ubHkgb25lIHRvcCBsZXZl bCBub2RlLiAgVGhpcyBpc24ndCBteSBleGNlcHRpb24sIG5vciBkbw0KPiBJIHNlZSB0aGlzIHN0 YXRlZCBpbiB0aGUgZHJhZnQuICBJIGRvIHRoaW5rIHdlIHNheSBvbmUgdG9wIGxldmVsIG5vZGUN Cj4gZGVhbGluZyB3aXRoIGRldmljZSBjb25maWd1cmF0aW9uLg0KDQpJbiBsaWdodCBvZiB3aGF0 IHlvdSBleHBsYWluZWQsIEkgY2FuIHJlcGhyYXNlIHRoaXM6ICBPbiBhbnkgZ2l2ZW4NCmltcGxl bWVudGF0aW9uIHRoZXJlIHdpbGwgYWx3YXlzIG9ubHkgYmUgb25lIHRvcC1sZXZlbCBub2RlLiAg Rm9yDQpleGFtcGxlLCBvbiBhIGRldmljZSwgdGhlIHRvcC1ub2RlIGlzIGFsd2F5cyAvZGV2aWNl LiAgQ29ycmVjdD8NCg0KPiA+IEluc3RlYWQgb2YgaGF2aW5nIE4NCj4gPiB0b3AtbGV2ZWwgbm9k ZXMsIHdlIHdvdWxkIGhhdmUgTiBub2RlcyB1bmRlciAvZGV2aWNlLiAgV2h5IGlzIHRoaXMNCj4g PiBiZXR0ZXI/DQo+IA0KPiBOIHdvdWxkIGNvbnRhaW4gb25seSBkZXZpY2UgY29uZmlndXJhdGlv biByZWxhdGVkIG1vZHVsZXMuICBUaGVyZSBjb3VsZA0KPiBiZSBvdGhlcnMsIGUuZy4sIC9zZXJ2 aWNlcyBoYXMgYmVlbiBtZW50aW9uZWQgYnkgc29tZS4NCj4gDQo+ID4gDQo+ID4+IEFyZSB5b3Ug cmVmZXJyaW5nIHRvIHNlY3Rpb24gMi4zPyAgSWYgc28sIEkgdGhpbmsgd2UgYWxsIGFncmVlIChh bmQgc2FpZA0KPiA+PiBhcyBtdWNoIGluIFByYWd1ZSkgdGhhdCB0aGlzIHNlY3Rpb24gY291bGQg YmUgY2xlYXJlci4gIFdlL0kgdHJpZWQgdG8NCj4gPj4gZXhwbGFpbiBpdCBpbiB0aGUgUHJhZ3Vl IHNsaWRlIDI1IChmb3IgdGhpcyB5b3UgbWF5IHdhbnQgdG8gc2VlIHRoZQ0KPiA+PiBhbmltYXRp b24gaW4NCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTMvc2xpZGVzL3Ns aWRlcy05My1ydGd3Zy0zLnBwdHgpDQo+ID4+DQo+ID4+IEJhc2ljYWxseSB0aGUgYW1vdW50IG9m IGluZm9ybWF0aW9uIHByb3ZpZGVkIGRlcGVuZHMgb24gdGhlDQo+ID4+IGxvZ2ljYWwtbmV0d29y ay1lbGVtZW50IGNvbnRleHQgdXNlZCB0byBhY2Nlc3MgdGhpcyBpbmZvcm1hdGlvbi4gIFNvIGlm DQo+ID4+IGEgbW9kZWwgaXMgInJldHJpZXZlZCIgdmlhIGFuIElQIGFkZHJlc3MgYXNzb2NpYXRl ZCB3aXRoIGENCj4gPj4gbmV0d29yay1lbGVtZW50LWlkICB3aXRoIGRldmljZS12aWV3PXRydWUg KGUuZy4sIHRoZSBsZWZ0IHNpZGUgb2Ygc2xpZGUNCj4gPj4gMjUpLCB0aGVuIHRoZSBkZXZpY2Un cyBmdWxsIHZpZXcgaXMgcHJvdmlkZWQuICBBbmQgd2hlbiBhIG1vZGVsIGlzDQo+ID4+ICJyZXRy aWV2ZWQiIHZpYSBhbiBJUCBhZGRyZXNzIGFzc29jaWF0ZWQgd2l0aCBhIG5ldHdvcmstZWxlbWVu dC1pZCAgd2l0aA0KPiA+PiBkZXZpY2Utdmlldz1mYWxzZSAoZS5nLiwgdGhlIHJpZGUgc2lkZSBv ZiBzbGlkZSAyNSwgZWl0aGVyIGNvbG9yKSBvbmx5DQo+ID4+IGluZm9ybWF0aW9uIHJlbGF0ZWQg dG8gdGhlIG5ldHdvcmstZWxlbWVudC1pZCBpcyBwcm92aWRlZC4NCj4gPiANCj4gPiBEbyB5b3Ug d2FudCB0aGUgdXNlciBmcm9tIGEgcGFydGljdWxhciBJUCBhZGRyZXNzIHRvIGhhdmUgYWNjZXNz IHRvDQo+ID4ganVzdCBoaXMgcGFydCBvZiB0aGUgdHJlZSwgb3IgZG8geW91IHdhbnQgdGhhdCB1 c2VyIHRvIGhhdmUgaGlzIG93bg0KPiA+ICJzYW5kYm94IiB0aGF0IGhlIGNhbiBjb250cm9sIGlu ZGVwZW5kZW50bHkgb2Ygb3RoZXIgdXNlcnM/DQo+IA0KPiBUaGUgaW50ZW50IHdhcyBtdWx0aXBs ZSBsb2dpY2FsLW5ldHdvcmstZWxlbWVudHMgYW5kIHdoZW4NCj4gZGV2aWNlLXZpZXc9ZmFsc2Us IGFueSBtYW5hZ2VtZW50IG9wZXJhdGlvbiB0YWtpbmcgcGxhY2UgaW4gdGhlIGNvbnRleHQNCj4g b2YgdGhhdCBMTkUgd291bGQgb25seSBoYXZlIHZpc2liaWxpdHkgYW5kIGFiaWxpdHkgdG8gY29u dHJvbCB0aGF0IExORS4NCj4gIFRoaXMgbWF0Y2hlcyBhIHByZXR0eSBjb21tb24gZmVhdHVyZSBz ZXQuDQoNCk9rLCBzbyB0aGlzIG1lYW5zIHRoYXQgdGhlcmUgaXMgc3RpbGwganVzdCBvbmUgY29u ZmlndXJhdGlvbiBmb3IgYWxsDQpsb2dpY2FsLW5ldHdvcmstZWxlbWVudHMsIHJpZ2h0PyAgRS5n LiwgaWYgYSB1c2VyIGZyb20NCmxvZ2ljYWwtbmV0d29yay1lbGVtZW50IEEgbG9ja3MgdGhlIGRh dGFzdG9yZSwgaGUgd2lsbCBsb2NrIG91dCBhDQp1c2VyIGZyb20gbG9naWNhbC1uZXR3b3JrLWVs ZW1lbnQgQjsgaWYgdXNlciBmcm9tIEEgc2F2ZXMgcnVubmluZyB0bw0Kc3RhcnR1cCBjaGFuZ2Vz IGZvciBCIHdpbGwgYWxzbyBiZSBzYXZlZCwgZXRjPw0KDQoNCg0KDQovbWFydGluDQoNCg0KDQoN Cj4gDQo+ID4gDQo+ID4gSW4gdGhlIGZpcnN0IGNhc2UsIHlvdSBjYW4gdXNlIE5BQ00gdG8gc2V0 IHVwIHJ1bGVzIHRvIGdpdmUgZWFjaCB1c2VyDQo+ID4gcHJvcGVyIGFjY2VzcyAoYmFzZWQgb24g dXNlciBpZGVudGl0eSByYXRoZXIgdGhhbiBJUCBhZGRyZXNzIHRob3VnaCkuDQo+IA0KPiBJIHRo aW5rIHRoaXMgd291bGQgYmUgdXNlZCB0b28uICBGb3IgZXhhbXBsZSB1c2VyMSB3b3VsZCBoYXZl IHJvIGFjY2Vzcw0KPiB3aGlsZSB1c2VyMiBoYXMgcncuDQo+IA0KPiA+IFlvdSBkb24ndCBuZWVk IHRoaXMgImRldmljZS12aWV3IiBpbiBvcmRlciB0byBkbyB0aGlzLg0KPiBBZ3JlZWQsIGJ1dCB0 aGlzIGlzIHNvbWV0aGluZyBkaWZmZXJlbnQgYW5kIG1hdGNoZXMgaG93IGEgbXVsdGlwbGUNCj4g ZGV2aWNlcyBmcm9tIG11bHRpcGxlIHZlbmRvcnMgZnVuY3Rpb24gdG9kYXkuDQo+IA0KPiA+IA0K PiA+IEluIHRoZSBsYXR0ZXIgY2FzZSwgSSBkb24ndCB0aGluayB0aGUgcHJvcG9zZWQgZGVzaWdu IHdvcmtzLiAgKEkgY2FuDQo+ID4gZ28gaW50byBkZXRhaWxzIGlmIGl0IHR1cm5zIG91dCB0aGF0 IHRoaXMgd2hhdCB5b3UgaGFkIGluIG1pbmQpLg0KPiBJIHRoaW5rIHdlJ3JlIGludGVyZXN0ZWQg aW4gYSBmb3JtIG9mIHRoZSBmaXJzdC4NCj4gDQo+IExvdQ0KPiANCj4gPiANCj4gPiANCj4gPiAN Cj4gPiAvbWFydGluDQo+ID4gDQo+IA0K From nobody Thu Aug 20 01:04:24 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72F471A1BDC for ; Thu, 20 Aug 2015 01:04:23 -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 SHyIf4cjqfM8 for ; Thu, 20 Aug 2015 01:04:21 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 504BC1A1BCF for ; Thu, 20 Aug 2015 01:04:21 -0700 (PDT) Received: from localhost (unknown [173.38.220.43]) by mail.tail-f.com (Postfix) with ESMTPSA id 453B51AE035B; Thu, 20 Aug 2015 10:04:20 +0200 (CEST) Date: Thu, 20 Aug 2015 10:04:19 +0200 (CEST) Message-Id: <20150820.100419.2184273484864487074.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20150819.194934.461244528814584733.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] extensions and conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 08:04:23 -0000 Andy Bierman wrote: > On Wed, Aug 19, 2015 at 10:49 AM, Martin Bjorklund wrote: > > > Andy Bierman wrote: > > > On Wed, Aug 19, 2015 at 5:49 AM, Martin Bjorklund > > wrote: > > > > > > > Hi, > > > > > > > > [joining this discussion a bit late] > > > > > > > > Ladislav Lhotka wrote: > > > > > > > > > > > On 10 Aug 2015, at 18:46, Andy Bierman wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Aug 10, 2015 at 9:37 AM, Ladislav Lhotka > > > > > > wrote: > > > > > > > > > > > > > On 10 Aug 2015, at 17:32, Andy Bierman > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Aug 10, 2015 at 4:24 AM, Ladislav Lhotka > > > > > > > wrote: > > > > > > > > > > > > > > > On 10 Aug 2015, at 12:17, Andy Bierman > > wrote: > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > I am strongly against changing the contract on extensions. > > > > > > > > They MAY be ignored by any YANG tool. Period. > > > > > > > > That means they are far from mandatory. > > > > > > > > They are little more than a keyword and a description clause. > > > > > > > > > > > > > > So do you prefer my proposed solution -02 or -03? > > > > > > > > > > > > > > ** Solution Yxx-03 > > > > > > > > > > > > > > Make extensions optional. This means that extensions won't be > > > > > > > allowed to change YANG language, NETCONF protocol, and > > validity of > > > > > > > datastores and protocol messages. > > > > > > > > > > > > > > > > > > > > > This is how we use extensions to tag YANG data models > > > > > > > to drive automation tools. > > > > > > > > > > > > But that means, for example, that annotations cannot be defined > > via an > > > > > > extension statement as in draft-ietf-netmod-yang-metadata. > > > > > > > > > > > > > > > > > > > > > > > > Which means these statements should be real instead of extensions. > > > > > > If the statements are defining data that is exchanged between > > > > > > peers in a standard protocol, then YANG extensions are not > > > > > > appropriate. > > > > > > > > > > I agree, and -03 is my preferred solution, too. > > > > > > > > I strongly disagree. IMO the IETF usage of extensions so far (NACM, > > > > annotations) works well (in the case of NACM proven by multiple > > > > independent implementations), and follows how extensions were intended > > > > to be used, and obviously, how the WG has understood them up until > > > > now. > > > > > > > > If the sentence: > > > > > > > > If a YANG compiler does not support a particular extension, which > > > > appears in a YANG module as an unknown-statement (see Section 12), > > > > the entire unknown-statement MAY be ignored by the compiler. > > > > > > > > in 6020 can be interpreted to mean that an occurance of an extension > > > > is non-normative, we should fix it so that it matches what was > > > > intended and how it is used. > > > > > > > > Juergen suggested this replacement text, which I support. Maybe it > > > > can be improved even more. > > > > > > > > If a YANG parser does not support a particular extension, which > > > > appears in a YANG module as an unknown-statement (see Section > > 13), > > > > the entire unknown-statement MAY be ignored by the parser. Note > > > > that even in this case the semantics associated with the > > extension > > > > still apply (as if they were part of a description statement). > > > > > > > > > > > > > > I strongly disagree with this change. > > > This would mean that every tool is required to support the > > > semantics of every extension ever defined. > > > > No. It means that if a server advertises module that uses some > > extension to define some behaviour, the server supports that > > behavior. Just as we expect a server to support the text in > > description statements. > > > > For example, the nacm: extensions do not apply unless ietf-netconf-acm > > is advertised (and nacm is enabled). I expect most extensions to work > > this way. Another example is if we actually defined i2rs:ephemeral; > > this would have no effect unless the "i2rs" capability (whatever that > > is) is also advertised. > > > > The text also means that it is perfectly ok for a client to ignore the > > extension if it doesn't understand it. For example, if the client has > > no idea what the ephemeral datastore it, it doesn't matter that a node > > is marked with i2rs:ephemeral true. > > > > > For example, > > > we have our own extensions that cause the server to > > > perform internal tasks certain ways (like ywx:sil-delete-children-first). > > > > > > According to the text you propose, all servers would have to > > > provide the behavior embodied in the syntax of this extension > > > statement? > > > > Yes, all servers that advertise such a module. B/c as you note below > > it is "well-behaved". So the defintion probably says something like > > "if the server implements SIL, then it will delete the children before > > it deletes the node itself". > > > > > This extension does not alter any protocol behavior > > > at all, so it is "well-behaved". > > > > > > A server MAY skip over the entire extension and completely ignore it. > > > Other servers are not required to provide the behavior described > > > in the extension semantics. > > > > Yes. Aren't we in agreement here? > > > > > > > No -- I agree with Randy's interpretation of MAY. > > However, IMO description-stmts are normative, so if plain text in > the NACM RFC says the nacm YANG extensions MUST be supported, > then I think that makes it mandatory. > > YANG conformance does not make it mandatory. > > We are in agreement if you mean the RFC or module > containing the YANG extension can define the conformance for the extension. Yes, maybe this is what I am trying to say. I guess I can't see how that would be possible if you insist that all extensions always are truly OPTIONAL. > But I don't agree that statements related to data handling and > datastores should ever be extensions. IMO NACM extensions > should really be YANG 1.1 keywords and the extensions should > be deprecated. I don't understand why you think that. We agree that it is ok for the RFC/module for NACM to defined the conformance for the nacm extensions (and this apparently work in multiple implementations), so why should these be proper statements? > I like YANG extensions -- they are like the minor leagues for YANG > statements. :-) > But once they are stable and there is consensus they are useful, they should > probably be made mandatory by converting them to regular statements. This is probably true in some cases, but I also like the idea of extensibility and modularity. It's a feature, not a bug, that we could define NACM w/o revising YANG. /martin From nobody Thu Aug 20 01:15:44 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B979E1A6F1D for ; Thu, 20 Aug 2015 01:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVUj0DHvj4ac for ; Thu, 20 Aug 2015 01:15:36 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A9B191A6EFB for ; Thu, 20 Aug 2015 01:15:35 -0700 (PDT) Received: from localhost (unknown [173.38.220.43]) by mail.tail-f.com (Postfix) with ESMTPSA id 52D4D1AE035B; Thu, 20 Aug 2015 10:15:34 +0200 (CEST) Date: Thu, 20 Aug 2015 10:15:33 +0200 (CEST) Message-Id: <20150820.101533.1535137181522006328.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <55D45CAF.2070605@cisco.com> <20150819.132555.871710491924929960.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Y34 - root node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 08:15:39 -0000 Andy Bierman wrote: > On Wed, Aug 19, 2015 at 4:25 AM, Martin Bjorklund wrote: > > > Robert Wilton wrote: > > > > > > > > > On 18/08/2015 18:22, Andy Bierman wrote: > > > > This is how languages like SMIv2 and YANG work. > > > > A conceptual object is given a permanent "home" within the tree of > > > > object identifiers. > > > > Moving data is very expensive, since any clients working with the old > > > > data > > > > will break as soon as the data is moved. > > > > > > > > I am not convinced the IETF can or should come up with a set of > > > > containers > > > > that covers every possible topic that can be modeled in YANG. > > > > > > I mostly agree, but having some more structure/advice as to where to > > > place YANG modules may be helpful. I'm thinking more along the lines > > > of broad categories rather than precise locations. > > > > +1 > > > > > > If someone wants to builds a YANG controller node that is managing > > > > the configuration for a network of devices then wouldn't they want > > > > a particular device's interface configuration to be located > > > > somewhere like /network/device//interfaces/interface? > > > > Ideally, they would be able to use the same YANG definitions that > > > > are defined for /interfaces/ but root them relative to > > > > /network/device//. > > > > > > > > > > > > > > > > Yes -- some of us (like Martin) have pointed this out many times. > > > > The "device" container on an NE does not help at all wrt/ > > > > aggregation on a controller. "/device" or "/" work the same for this > > > > purpose. > > > > Actually, I would argue that / works better. On the controller, you > > probably have a list of devices you control (this is how our NCS > > works, and how ODL works (I have been told)): > > > > container devices { > > list device { > > key name; > > // meta-info about the device goes here, things like > > // ip-address, port, auth info... > > container data { > > // all models supported by the devices are "mounted" here > > } > > } > > } > > > > So on the controller, the path to interface "eth0" on device "foo" > > would be: > > > > /devices/device[name='foo']/data/interfaces/interface[name='eth0'] > > > > if we also have a top-level "/device" container we'd have: > > > > /devices/device[name='foo']/data/device/interfaces/interface[name='eth0'] > > > > > What would the real resource location for > > > "/network/device//interfaces/interface" be? > > > > I don't think there is such a thing as a "real" location. The path is > > scoped in the system you work with; in the controller it might be as I > > illustrated above, in the device it starts with /interfaces, but in a > > controller-of-controllers it might be: > > > > /domains/domain[name='bar']/devices/device[name='foo']/data > > /interfaces/interface[name='eth0'] > > > > Currently we have a proprietary way of "relocating" YANG modules, and > > ODL has its "mount", and I think Andy has some other mechanism. Maybe > > the time has come to standardize how mount works, and maybe then also > > standardize the list of devices in a controller model. > > > > > > +1 > > We just need to standardize a "docroot within a docroot". > This is not relocation of subtrees within the datastore, this is just > mounting > a datastore somewhere within a parent datastore. > > In YANG validation terms, you simply adjust the docroot to the nested mount > point, > and the replicated datastore can be used as if it were stand-alone. > This would allow any sort of encapsulation of datastores and not add any > data model complexity to devices which do not have virtual servers > (most of them). Compared to the mount draft, I would like to decouple the schema information from the instance population mechanism. I.e., I'd like a mechanism that simply defines the schema, not necessarily how the data is populated (in the mount draft data was fetched from a remote server, but IMO that is just one of several use cases). I can think of two ways to do this. 1) Your "ycx:root" statement. This is open-ended, so we could do: list logical-element { key name; leaf name { ... } yang-root true; } From a schema perspective, any top-level node from any data model could be used within the logical-element list. 2) Cherry-picking: list logical-element { key name; leaf name { ... } mount if:interfaces; mount sys:system; ... } Or maybe combine them into one "mount" statement: mount *; // allow any top-level node mount sys:system; // allow this specific top-level node /martin From nobody Thu Aug 20 01:49:01 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED7BC1A876F for ; Thu, 20 Aug 2015 01:49:00 -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 3JcHxsz5w5R2 for ; Thu, 20 Aug 2015 01:48:58 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 114561A8843 for ; Thu, 20 Aug 2015 01:48:56 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 72B6A1CC0058; Thu, 20 Aug 2015 10:48:54 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund , andy@yumaworks.com In-Reply-To: <20150819.194934.461244528814584733.mbj@tail-f.com> References: <9B232151-C380-4B43-BAF4-88F7E4821B8D@nic.cz> <20150819.144900.231414608010857635.mbj@tail-f.com> <20150819.194934.461244528814584733.mbj@tail-f.com> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Thu, 20 Aug 2015 10:48:53 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] extensions and conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 08:49:01 -0000 Martin Bjorklund writes: > Andy Bierman wrote: >> On Wed, Aug 19, 2015 at 5:49 AM, Martin Bjorklund wrote: >>=20 >> > Hi, >> > >> > [joining this discussion a bit late] >> > >> > Ladislav Lhotka wrote: >> > > >> > > > On 10 Aug 2015, at 18:46, Andy Bierman wrote: >> > > > >> > > > >> > > > >> > > > On Mon, Aug 10, 2015 at 9:37 AM, Ladislav Lhotka >> > > > wrote: >> > > > >> > > > > On 10 Aug 2015, at 17:32, Andy Bierman wrot= e: >> > > > > >> > > > > >> > > > > >> > > > > On Mon, Aug 10, 2015 at 4:24 AM, Ladislav Lhotka >> > > > > wrote: >> > > > > >> > > > > > On 10 Aug 2015, at 12:17, Andy Bierman wr= ote: >> > > > > > >> > > > > > Hi, >> > > > > > >> > > > > > I am strongly against changing the contract on extensions. >> > > > > > They MAY be ignored by any YANG tool. Period. >> > > > > > That means they are far from mandatory. >> > > > > > They are little more than a keyword and a description clause. >> > > > > >> > > > > So do you prefer my proposed solution -02 or -03? >> > > > > >> > > > > ** Solution Yxx-03 >> > > > > >> > > > > Make extensions optional. This means that extensions won't be >> > > > > allowed to change YANG language, NETCONF protocol, and validi= ty of >> > > > > datastores and protocol messages. >> > > > > >> > > > > >> > > > > This is how we use extensions to tag YANG data models >> > > > > to drive automation tools. >> > > > >> > > > But that means, for example, that annotations cannot be defined vi= a an >> > > > extension statement as in draft-ietf-netmod-yang-metadata. >> > > > >> > > > >> > > > >> > > > Which means these statements should be real instead of extensions. >> > > > If the statements are defining data that is exchanged between >> > > > peers in a standard protocol, then YANG extensions are not >> > > > appropriate. >> > > >> > > I agree, and -03 is my preferred solution, too. >> > >> > I strongly disagree. IMO the IETF usage of extensions so far (NACM, >> > annotations) works well (in the case of NACM proven by multiple >> > independent implementations), and follows how extensions were intended >> > to be used, and obviously, how the WG has understood them up until >> > now. >> > >> > If the sentence: >> > >> > If a YANG compiler does not support a particular extension, which >> > appears in a YANG module as an unknown-statement (see Section 12), >> > the entire unknown-statement MAY be ignored by the compiler. >> > >> > in 6020 can be interpreted to mean that an occurance of an extension >> > is non-normative, we should fix it so that it matches what was >> > intended and how it is used. >> > >> > Juergen suggested this replacement text, which I support. Maybe it >> > can be improved even more. >> > >> > If a YANG parser does not support a particular extension, which >> > appears in a YANG module as an unknown-statement (see Section 1= 3), >> > the entire unknown-statement MAY be ignored by the parser. Note >> > that even in this case the semantics associated with the extens= ion >> > still apply (as if they were part of a description statement). >> > >> > >>=20 >> I strongly disagree with this change. >> This would mean that every tool is required to support the >> semantics of every extension ever defined. > > No. It means that if a server advertises module that uses some > extension to define some behaviour, the server supports that > behavior. Just as we expect a server to support the text in > description statements. This is unclear both from the current text and from Juergen's proposal. Maybe I am a nitpicker but assume that either (i)=C2=A0server implementation is completely generated from the data model, or (ii)=C2=A0the parser in question is simply in the implementor's head. Then I don't know how the server can implement the semantics of an extension if the extension is removed while YANG modules containing it are being parsed. A text like "a client MAY ignore an extension that it doesn't understand" would be clearer but I don't think it is acceptable if the extension changes - semantics of YANG, - semantics of the protocol, - schema of the data model (as annotations do). > > For example, the nacm: extensions do not apply unless ietf-netconf-acm > is advertised (and nacm is enabled). I expect most extensions to work > this way. Another example is if we actually defined i2rs:ephemeral; > this would have no effect unless the "i2rs" capability (whatever that > is) is also advertised. The nacm: extensions are probably OK because they only give some additional info about the server behaviour that is independent of client's support. If the client ignores them, then it may be just wondering why it cannot read or write some data. > > The text also means that it is perfectly ok for a client to ignore the > extension if it doesn't understand it. For example, if the client has > no idea what the ephemeral datastore it, it doesn't matter that a node > is marked with i2rs:ephemeral true. I am not convinced at all about this one. If the server advertises the "i2rs" capability and modules that use "i2rs:ephemeral" extension, then a normal NETCONF/RESTCONF client can ignore both (RFC 6241: "Each peer [...] MUST ignore any capability received from the other peer that it does not require or does not understand."). Buth what then: can the client treat nodes tagged with "i2rs:ephemeral" just as standard nodes? Lada > >> For example, >> we have our own extensions that cause the server to >> perform internal tasks certain ways (like ywx:sil-delete-children-first). >>=20 >> According to the text you propose, all servers would have to >> provide the behavior embodied in the syntax of this extension >> statement? > > Yes, all servers that advertise such a module. B/c as you note below > it is "well-behaved". So the defintion probably says something like > "if the server implements SIL, then it will delete the children before > it deletes the node itself". > >> This extension does not alter any protocol behavior >> at all, so it is "well-behaved". >>=20 >> A server MAY skip over the entire extension and completely ignore it. >> Other servers are not required to provide the behavior described >> in the extension semantics. > > Yes. Aren't we in agreement here? > > > /martin > > > >>=20 >>=20 >>=20 >> > However, I do agree that an extension cannot "undo" semantics defined >> > by other YANG statements, just as you cannot do that in a description >> > statement. For example, this would be illegal: >> > >> > leaf foo { >> > type int32; >> > description "The type is really a string."; >> > } >> > >> > leaf bar { >> > type int32; >> > xx:real-type string; >> > } >> > >> > It is also a Very Bad Idea (speaking from experience...) to define an >> > extension that introduces new data nodes. >> > >> > The text about "MAY ignore" was meant to capture this. It's supposed >> > to be like for a client that doesn't understand an augemntation; it >> > can skip it. A client that doesn't understand nacm:default-deny-all >> > works just fine and can safely ignore it. >> > >> > >> > /martin >> > >>=20 >>=20 >> Andy --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Aug 20 02:10:19 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 262541A1EFF for ; Thu, 20 Aug 2015 02:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2ba22fw2zqE for ; Thu, 20 Aug 2015 02:10:13 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8611B1A1A2C for ; Thu, 20 Aug 2015 02:10:13 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id D67781CC0058; Thu, 20 Aug 2015 11:10:12 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman , Martin Bjorklund In-Reply-To: References: <55D36473.90609@cisco.com> <55D45CAF.2070605@cisco.com> <20150819.132555.871710491924929960.mbj@tail-f.com> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Thu, 20 Aug 2015 11:10:13 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y34 - root node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 09:10:18 -0000 Andy Bierman writes: > On Wed, Aug 19, 2015 at 4:25 AM, Martin Bjorklund wrote: > >> Robert Wilton wrote: >> > >> > >> > On 18/08/2015 18:22, Andy Bierman wrote: >> > > This is how languages like SMIv2 and YANG work. >> > > A conceptual object is given a permanent "home" within the tree of >> > > object identifiers. >> > > Moving data is very expensive, since any clients working with the old >> > > data >> > > will break as soon as the data is moved. >> > > >> > > I am not convinced the IETF can or should come up with a set of >> > > containers >> > > that covers every possible topic that can be modeled in YANG. >> > >> > I mostly agree, but having some more structure/advice as to where to >> > place YANG modules may be helpful. I'm thinking more along the lines >> > of broad categories rather than precise locations. >> >> +1 >> >> > > If someone wants to builds a YANG controller node that is managing >> > > the configuration for a network of devices then wouldn't they want >> > > a particular device's interface configuration to be located >> > > somewhere like /network/device//interfaces/interface? >> > > Ideally, they would be able to use the same YANG definitions that >> > > are defined for /interfaces/ but root them relative to >> > > /network/device//. >> > > >> > > >> > > >> > > Yes -- some of us (like Martin) have pointed this out many times. >> > > The "device" container on an NE does not help at all wrt/ >> > > aggregation on a controller. "/device" or "/" work the same for this >> > > purpose. >> >> Actually, I would argue that / works better. On the controller, you >> probably have a list of devices you control (this is how our NCS >> works, and how ODL works (I have been told)): >> >> container devices { >> list device { >> key name; >> // meta-info about the device goes here, things like >> // ip-address, port, auth info... >> container data { >> // all models supported by the devices are "mounted" here >> } >> } >> } >> >> So on the controller, the path to interface "eth0" on device "foo" >> would be: >> >> /devices/device[name='foo']/data/interfaces/interface[name='eth0'] >> >> if we also have a top-level "/device" container we'd have: >> >> /devices/device[name='foo']/data/device/interfaces/interface[name='eth0'] >> >> > What would the real resource location for >> > "/network/device//interfaces/interface" be? >> >> I don't think there is such a thing as a "real" location. The path is >> scoped in the system you work with; in the controller it might be as I >> illustrated above, in the device it starts with /interfaces, but in a >> controller-of-controllers it might be: >> >> /domains/domain[name='bar']/devices/device[name='foo']/data >> /interfaces/interface[name='eth0'] >> >> Currently we have a proprietary way of "relocating" YANG modules, and >> ODL has its "mount", and I think Andy has some other mechanism. Maybe >> the time has come to standardize how mount works, and maybe then also >> standardize the list of devices in a controller model. >> >> > > +1 > > We just need to standardize a "docroot within a docroot". This is not > relocation of subtrees within the datastore, this is just mounting a > datastore somewhere within a parent datastore. The current definition of datastore is too general, so I don't know what datastore inside datastore means. What's clear is that a single module cannot just be mounted anywhere. For example, if ietf-interfaces is mounted under /device and ietf-ip straight under /, then I don't see how references and XPath expressions could be reliably modified to work as expected. That's why I think only self-contained packages can be mounted, and inside them all references can be prepended with the mount root. Lada > > In YANG validation terms, you simply adjust the docroot to the nested mount > point, > and the replicated datastore can be used as if it were stand-alone. > This would allow any sort of encapsulation of datastores and not add any > data model complexity to devices which do not have virtual servers > (most of them). > > >> >> /martin >> > > > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Aug 20 03:37:48 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 341E71A8AB1 for ; Thu, 20 Aug 2015 03:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3F-VBYJntOz for ; Thu, 20 Aug 2015 03:37:45 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C80C61A8ABC for ; Thu, 20 Aug 2015 03:37:43 -0700 (PDT) Received: from localhost (unknown [173.38.220.43]) by mail.tail-f.com (Postfix) with ESMTPSA id 838991AE035B; Thu, 20 Aug 2015 12:37:41 +0200 (CEST) Date: Thu, 20 Aug 2015 12:37:41 +0200 (CEST) Message-Id: <20150820.123741.252355277712113387.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <20150819.194934.461244528814584733.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] extensions and conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 10:37:47 -0000 Ladislav Lhotka wrote: > Martin Bjorklund writes: > = > > Andy Bierman wrote: > >> On Wed, Aug 19, 2015 at 5:49 AM, Martin Bjorklund = wrote: > >> = > >> > Hi, > >> > > >> > [joining this discussion a bit late] > >> > > >> > Ladislav Lhotka wrote: > >> > > > >> > > > On 10 Aug 2015, at 18:46, Andy Bierman = wrote: > >> > > > > >> > > > > >> > > > > >> > > > On Mon, Aug 10, 2015 at 9:37 AM, Ladislav Lhotka > >> > > > wrote: > >> > > > > >> > > > > On 10 Aug 2015, at 17:32, Andy Bierman wrote: > >> > > > > > >> > > > > > >> > > > > > >> > > > > On Mon, Aug 10, 2015 at 4:24 AM, Ladislav Lhotka > >> > > > > wrote: > >> > > > > > >> > > > > > On 10 Aug 2015, at 12:17, Andy Bierman wrote: > >> > > > > > > >> > > > > > Hi, > >> > > > > > > >> > > > > > I am strongly against changing the contract on extension= s. > >> > > > > > They MAY be ignored by any YANG tool. Period. > >> > > > > > That means they are far from mandatory. > >> > > > > > They are little more than a keyword and a description cl= ause. > >> > > > > > >> > > > > So do you prefer my proposed solution -02 or -03? > >> > > > > > >> > > > > ** Solution Yxx-03 > >> > > > > > >> > > > > Make extensions optional. This means that extensions wo= n't be > >> > > > > allowed to change YANG language, NETCONF protocol, and = validity of > >> > > > > datastores and protocol messages. > >> > > > > > >> > > > > > >> > > > > This is how we use extensions to tag YANG data models > >> > > > > to drive automation tools. > >> > > > > >> > > > But that means, for example, that annotations cannot be defi= ned via an > >> > > > extension statement as in draft-ietf-netmod-yang-metadata. > >> > > > > >> > > > > >> > > > > >> > > > Which means these statements should be real instead of exten= sions. > >> > > > If the statements are defining data that is exchanged betwee= n > >> > > > peers in a standard protocol, then YANG extensions are not > >> > > > appropriate. > >> > > > >> > > I agree, and -03 is my preferred solution, too. > >> > > >> > I strongly disagree. IMO the IETF usage of extensions so far (N= ACM, > >> > annotations) works well (in the case of NACM proven by multiple > >> > independent implementations), and follows how extensions were in= tended > >> > to be used, and obviously, how the WG has understood them up unt= il > >> > now. > >> > > >> > If the sentence: > >> > > >> > If a YANG compiler does not support a particular extension, w= hich > >> > appears in a YANG module as an unknown-statement (see Section= 12), > >> > the entire unknown-statement MAY be ignored by the compiler. > >> > > >> > in 6020 can be interpreted to mean that an occurance of an exten= sion > >> > is non-normative, we should fix it so that it matches what was > >> > intended and how it is used. > >> > > >> > Juergen suggested this replacement text, which I support. Maybe= it > >> > can be improved even more. > >> > > >> > If a YANG parser does not support a particular extension,= which > >> > appears in a YANG module as an unknown-statement (see Sec= tion 13), > >> > the entire unknown-statement MAY be ignored by the parser= . Note > >> > that even in this case the semantics associated with the = extension > >> > still apply (as if they were part of a description statem= ent). > >> > > >> > > >> = > >> I strongly disagree with this change. > >> This would mean that every tool is required to support the > >> semantics of every extension ever defined. > > > > No. It means that if a server advertises module that uses some > > extension to define some behaviour, the server supports that > > behavior. Just as we expect a server to support the text in > > description statements. > = > This is unclear both from the current text and from Juergen's > proposal. Maybe I am a nitpicker but assume that either (i)=A0server > implementation is completely generated from the data model, or (ii)=A0= the > parser in question is simply in the implementor's head. Then I don't > know how the server can implement the semantics of an extension if th= e > extension is removed while YANG modules containing it are being parse= d. > = > A text like "a client MAY ignore an extension that it doesn't > understand" would be clearer but I don't think it is acceptable if th= e > extension changes > = > - semantics of YANG, Agreed. > - semantics of the protocol, Maybe... > - schema of the data model (as annotations do). I think it is ok to define an annotation with an extension (as the draft does). When designing a feature that is going to use an annotation it is important to keep in mind that not all clients will understand the annotation. So e.g. if the new feature is a "comment", the server might just blindly return them to all clients, but in the case of "inactive", the server must not send these attributes to a client that doesn't ask for them. (You may argue that even for comments the client should ask for them, but that is besides the point). The bottom line is that you have to be careful when you define a new extension statement. > > For example, the nacm: extensions do not apply unless ietf-netconf-= acm > > is advertised (and nacm is enabled). I expect most extensions to w= ork > > this way. Another example is if we actually defined i2rs:ephemeral= ; > > this would have no effect unless the "i2rs" capability (whatever th= at > > is) is also advertised. > = > The nacm: extensions are probably OK because they only give some > additional info about the server behaviour that is independent of > client's support. If the client ignores them, then it may be just > wondering why it cannot read or write some data. Right. > > The text also means that it is perfectly ok for a client to ignore = the > > extension if it doesn't understand it. For example, if the client = has > > no idea what the ephemeral datastore it, it doesn't matter that a n= ode > > is marked with i2rs:ephemeral true. > = > I am not convinced at all about this one. If the server advertises th= e > "i2rs" capability and modules that use "i2rs:ephemeral" extension, th= en > a normal NETCONF/RESTCONF client can ignore both (RFC 6241: "Each pee= r > [...] MUST ignore any capability received from the other peer that it= > does not require or does not understand."). Buth what then: can the > client treat nodes tagged with "i2rs:ephemeral" just as standard node= s? My idea has been that it would be used as: leaf my-ephemeral-leaf { config false; i2rs:ephemeral true; ... } which means that if the client doesn't know what to do with "i2rs:ephemeral", it will ignore it, as just see this as a normal config false node that can be read with . /martin > = > Lada > = > > > >> For example, > >> we have our own extensions that cause the server to > >> perform internal tasks certain ways (like ywx:sil-delete-children-= first). > >> = > >> According to the text you propose, all servers would have to > >> provide the behavior embodied in the syntax of this extension > >> statement? > > > > Yes, all servers that advertise such a module. B/c as you note bel= ow > > it is "well-behaved". So the defintion probably says something lik= e > > "if the server implements SIL, then it will delete the children bef= ore > > it deletes the node itself". > > > >> This extension does not alter any protocol behavior > >> at all, so it is "well-behaved". > >> = > >> A server MAY skip over the entire extension and completely ignore = it. > >> Other servers are not required to provide the behavior described > >> in the extension semantics. > > > > Yes. Aren't we in agreement here? > > > > > > /martin > > > > > > > >> = > >> = > >> = > >> > However, I do agree that an extension cannot "undo" semantics de= fined > >> > by other YANG statements, just as you cannot do that in a descri= ption > >> > statement. For example, this would be illegal: > >> > > >> > leaf foo { > >> > type int32; > >> > description "The type is really a string."; > >> > } > >> > > >> > leaf bar { > >> > type int32; > >> > xx:real-type string; > >> > } > >> > > >> > It is also a Very Bad Idea (speaking from experience...) to defi= ne an > >> > extension that introduces new data nodes. > >> > > >> > The text about "MAY ignore" was meant to capture this. It's sup= posed > >> > to be like for a client that doesn't understand an augemntation;= it > >> > can skip it. A client that doesn't understand nacm:default-deny= -all > >> > works just fine and can safely ignore it. > >> > > >> > > >> > /martin > >> > > >> = > >> = > >> Andy > = > -- = > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > = From nobody Thu Aug 20 04:06:10 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCFA31A902B for ; Thu, 20 Aug 2015 04:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.239 X-Spam-Level: X-Spam-Status: No, score=0.239 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_64=0.6, 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 fJApFNC9cxRC for ; Thu, 20 Aug 2015 04:06:07 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 063F61A8AED for ; Thu, 20 Aug 2015 04:06:07 -0700 (PDT) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 9056718185E; Thu, 20 Aug 2015 13:06:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1440068765; bh=D9gaBS1xy/yccmTPilbNxRssmt0t670T14dNQGDzAXk=; h=From:Date:To; b=x7uKEQ+bfKD5jScQQfVkfvYyrTlNBUd+K5IUHg35qQu4e1o9KVN4ivpO9FMGlE5FB mln883qmxVXKR9C7VrN0bbBW6uoc04dTWApihj9aHmmKHNJpuq50QkSyZAdnT6OfOf 6c0ajaBav1bgszbj+C36I7UwdDD2uGg7NXZQDct0= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: <20150820.123741.252355277712113387.mbj@tail-f.com> Date: Thu, 20 Aug 2015 13:06:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5E452E16-4728-4A74-AD74-65404E6DA98C@nic.cz> References: <20150819.194934.461244528814584733.mbj@tail-f.com> <20150820.123741.252355277712113387.mbj@tail-f.com> To: =?windows-1252?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] extensions and conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 11:06:10 -0000 > On 20 Aug 2015, at 12:37, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >> Martin Bjorklund writes: >>=20 >>> Andy Bierman wrote: >>>> On Wed, Aug 19, 2015 at 5:49 AM, Martin Bjorklund = wrote: >>>>=20 >>>>> Hi, >>>>>=20 >>>>> [joining this discussion a bit late] >>>>>=20 >>>>> Ladislav Lhotka wrote: >>>>>>=20 >>>>>>> On 10 Aug 2015, at 18:46, Andy Bierman = wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On Mon, Aug 10, 2015 at 9:37 AM, Ladislav Lhotka >>>>>>> wrote: >>>>>>>=20 >>>>>>>> On 10 Aug 2015, at 17:32, Andy Bierman = wrote: >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Mon, Aug 10, 2015 at 4:24 AM, Ladislav Lhotka = >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>>> On 10 Aug 2015, at 12:17, Andy Bierman = wrote: >>>>>>>>>=20 >>>>>>>>> Hi, >>>>>>>>>=20 >>>>>>>>> I am strongly against changing the contract on extensions. >>>>>>>>> They MAY be ignored by any YANG tool. Period. >>>>>>>>> That means they are far from mandatory. >>>>>>>>> They are little more than a keyword and a description clause. >>>>>>>>=20 >>>>>>>> So do you prefer my proposed solution -02 or -03? >>>>>>>>=20 >>>>>>>> ** Solution Yxx-03 >>>>>>>>=20 >>>>>>>> Make extensions optional. This means that extensions won't be >>>>>>>> allowed to change YANG language, NETCONF protocol, and = validity of >>>>>>>> datastores and protocol messages. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> This is how we use extensions to tag YANG data models >>>>>>>> to drive automation tools. >>>>>>>=20 >>>>>>> But that means, for example, that annotations cannot be defined = via an >>>>>>> extension statement as in draft-ietf-netmod-yang-metadata. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Which means these statements should be real instead of = extensions. >>>>>>> If the statements are defining data that is exchanged between >>>>>>> peers in a standard protocol, then YANG extensions are not >>>>>>> appropriate. >>>>>>=20 >>>>>> I agree, and -03 is my preferred solution, too. >>>>>=20 >>>>> I strongly disagree. IMO the IETF usage of extensions so far = (NACM, >>>>> annotations) works well (in the case of NACM proven by multiple >>>>> independent implementations), and follows how extensions were = intended >>>>> to be used, and obviously, how the WG has understood them up until >>>>> now. >>>>>=20 >>>>> If the sentence: >>>>>=20 >>>>> If a YANG compiler does not support a particular extension, = which >>>>> appears in a YANG module as an unknown-statement (see Section = 12), >>>>> the entire unknown-statement MAY be ignored by the compiler. >>>>>=20 >>>>> in 6020 can be interpreted to mean that an occurance of an = extension >>>>> is non-normative, we should fix it so that it matches what was >>>>> intended and how it is used. >>>>>=20 >>>>> Juergen suggested this replacement text, which I support. Maybe = it >>>>> can be improved even more. >>>>>=20 >>>>> If a YANG parser does not support a particular extension, = which >>>>> appears in a YANG module as an unknown-statement (see = Section 13), >>>>> the entire unknown-statement MAY be ignored by the parser. = Note >>>>> that even in this case the semantics associated with the = extension >>>>> still apply (as if they were part of a description = statement). >>>>>=20 >>>>>=20 >>>>=20 >>>> I strongly disagree with this change. >>>> This would mean that every tool is required to support the >>>> semantics of every extension ever defined. >>>=20 >>> No. It means that if a server advertises module that uses some >>> extension to define some behaviour, the server supports that >>> behavior. Just as we expect a server to support the text in >>> description statements. >>=20 >> This is unclear both from the current text and from Juergen's >> proposal. Maybe I am a nitpicker but assume that either (i) server >> implementation is completely generated from the data model, or (ii) = the >> parser in question is simply in the implementor's head. Then I don't >> know how the server can implement the semantics of an extension if = the >> extension is removed while YANG modules containing it are being = parsed. >>=20 >> A text like "a client MAY ignore an extension that it doesn't >> understand" would be clearer but I don't think it is acceptable if = the >> extension changes >>=20 >> - semantics of YANG, >=20 > Agreed. >=20 >> - semantics of the protocol, >=20 > Maybe... >=20 >> - schema of the data model (as annotations do). >=20 > I think it is ok to define an annotation with an extension (as the > draft does). When designing a feature that is going to use an > annotation it is important to keep in mind that not all clients will > understand the annotation. So e.g. if the new feature is a "comment", > the server might just blindly return them to all clients, but in the For a client that doesn=92t understand the annotation (or annotations in = general) it is just extra junk that=92s not in the data model. This is = no different from a new data node type defined through an extension - in = fact, in JSON encoding annotations are just special object members. A = prudent client may consider such data invalid. > case of "inactive", the server must not send these attributes to a > client that doesn't ask for them. (You may argue that even for > comments the client should ask for them, but that is besides the > point). IMO =93inactive=94 data change the NETCONF/RESTCONF protocol. If a = client doesn=92t see inactive data, it may think it is OK to write its = own content to that place, which probably shouldn=92t be allowed. >=20 > The bottom line is that you have to be careful when you define a new > extension statement. >=20 >>> For example, the nacm: extensions do not apply unless = ietf-netconf-acm >>> is advertised (and nacm is enabled). I expect most extensions to = work >>> this way. Another example is if we actually defined i2rs:ephemeral; >>> this would have no effect unless the "i2rs" capability (whatever = that >>> is) is also advertised. >>=20 >> The nacm: extensions are probably OK because they only give some >> additional info about the server behaviour that is independent of >> client's support. If the client ignores them, then it may be just >> wondering why it cannot read or write some data. >=20 > Right. >=20 >>> The text also means that it is perfectly ok for a client to ignore = the >>> extension if it doesn't understand it. For example, if the client = has >>> no idea what the ephemeral datastore it, it doesn't matter that a = node >>> is marked with i2rs:ephemeral true. >>=20 >> I am not convinced at all about this one. If the server advertises = the >> "i2rs" capability and modules that use "i2rs:ephemeral" extension, = then >> a normal NETCONF/RESTCONF client can ignore both (RFC 6241: "Each = peer >> [...] MUST ignore any capability received from the other peer that it >> does not require or does not understand."). Buth what then: can the >> client treat nodes tagged with "i2rs:ephemeral" just as standard = nodes? >=20 > My idea has been that it would be used as: >=20 > leaf my-ephemeral-leaf { > config false; > i2rs:ephemeral true; > ... > } >=20 > which means that if the client doesn't know what to do with > "i2rs:ephemeral", it will ignore it, as just see this as a normal > config false node that can be read with . It of course depends on the particular usage rules - I assumed ephemeral = data would be config=3Dtrue. But even in your example, if ephemeral data = are in a special datastore, they may not be returned with , which = can again violate the schema. I think arbitrary extensions are OK if they are used in a controlled = environment, e.g. in single vendor=92s server and client software, but = in general they can break interoperability unless they are accompanied = with a bidirectional client-server negotiation mechanism. Lada >=20 >=20 > /martin >=20 >=20 >=20 >>=20 >> Lada >>=20 >>>=20 >>>> For example, >>>> we have our own extensions that cause the server to >>>> perform internal tasks certain ways (like = ywx:sil-delete-children-first). >>>>=20 >>>> According to the text you propose, all servers would have to >>>> provide the behavior embodied in the syntax of this extension >>>> statement? >>>=20 >>> Yes, all servers that advertise such a module. B/c as you note = below >>> it is "well-behaved". So the defintion probably says something like >>> "if the server implements SIL, then it will delete the children = before >>> it deletes the node itself". >>>=20 >>>> This extension does not alter any protocol behavior >>>> at all, so it is "well-behaved". >>>>=20 >>>> A server MAY skip over the entire extension and completely ignore = it. >>>> Other servers are not required to provide the behavior described >>>> in the extension semantics. >>>=20 >>> Yes. Aren't we in agreement here? >>>=20 >>>=20 >>> /martin >>>=20 >>>=20 >>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>> However, I do agree that an extension cannot "undo" semantics = defined >>>>> by other YANG statements, just as you cannot do that in a = description >>>>> statement. For example, this would be illegal: >>>>>=20 >>>>> leaf foo { >>>>> type int32; >>>>> description "The type is really a string."; >>>>> } >>>>>=20 >>>>> leaf bar { >>>>> type int32; >>>>> xx:real-type string; >>>>> } >>>>>=20 >>>>> It is also a Very Bad Idea (speaking from experience...) to define = an >>>>> extension that introduces new data nodes. >>>>>=20 >>>>> The text about "MAY ignore" was meant to capture this. It's = supposed >>>>> to be like for a client that doesn't understand an augemntation; = it >>>>> can skip it. A client that doesn't understand = nacm:default-deny-all >>>>> works just fine and can safely ignore it. >>>>>=20 >>>>>=20 >>>>> /martin >>>>>=20 >>>>=20 >>>>=20 >>>> Andy >>=20 >> --=20 >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Aug 20 04:12:51 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 511661A92B3 for ; Thu, 20 Aug 2015 04:12:50 -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_64=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 lRVOpDY6Gb7i for ; Thu, 20 Aug 2015 04:12:48 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 168DA1A9234 for ; Thu, 20 Aug 2015 04:12:44 -0700 (PDT) Received: from localhost (unknown [173.38.220.43]) by mail.tail-f.com (Postfix) with ESMTPSA id C81E71AE035B; Thu, 20 Aug 2015 13:12:42 +0200 (CEST) Date: Thu, 20 Aug 2015 13:12:42 +0200 (CEST) Message-Id: <20150820.131242.583799169537333295.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <5E452E16-4728-4A74-AD74-65404E6DA98C@nic.cz> References: <20150820.123741.252355277712113387.mbj@tail-f.com> <5E452E16-4728-4A74-AD74-65404E6DA98C@nic.cz> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] extensions and conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 11:12:50 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+ID4gT24gMjAgQXVn IDIwMTUsIGF0IDEyOjM3LCBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4gd3JvdGU6 DQo+ID4gDQo+ID4gTGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gPj4g TWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb20+IHdyaXRlczoNCj4gPj4gDQo+ID4+PiBB bmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbT4gd3JvdGU6DQo+ID4+Pj4gT24gV2VkLCBB dWcgMTksIDIwMTUgYXQgNTo0OSBBTSwgTWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb20+ DQo+ID4+Pj4gd3JvdGU6DQo+ID4+Pj4gDQo+ID4+Pj4+IEhpLA0KPiA+Pj4+PiANCj4gPj4+Pj4g W2pvaW5pbmcgdGhpcyBkaXNjdXNzaW9uIGEgYml0IGxhdGVdDQo+ID4+Pj4+IA0KPiA+Pj4+PiBM YWRpc2xhdiBMaG90a2EgPGxob3RrYUBuaWMuY3o+IHdyb3RlOg0KPiA+Pj4+Pj4gDQo+ID4+Pj4+ Pj4gT24gMTAgQXVnIDIwMTUsIGF0IDE4OjQ2LCBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtz LmNvbT4gd3JvdGU6DQo+ID4+Pj4+Pj4gDQo+ID4+Pj4+Pj4gDQo+ID4+Pj4+Pj4gDQo+ID4+Pj4+ Pj4gT24gTW9uLCBBdWcgMTAsIDIwMTUgYXQgOTozNyBBTSwgTGFkaXNsYXYgTGhvdGthIDxsaG90 a2FAbmljLmN6Pg0KPiA+Pj4+Pj4+IHdyb3RlOg0KPiA+Pj4+Pj4+IA0KPiA+Pj4+Pj4+PiBPbiAx MCBBdWcgMjAxNSwgYXQgMTc6MzIsIEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPiB3 cm90ZToNCj4gPj4+Pj4+Pj4gDQo+ID4+Pj4+Pj4+IA0KPiA+Pj4+Pj4+PiANCj4gPj4+Pj4+Pj4g T24gTW9uLCBBdWcgMTAsIDIwMTUgYXQgNDoyNCBBTSwgTGFkaXNsYXYgTGhvdGthIDxsaG90a2FA bmljLmN6Pg0KPiA+Pj4+Pj4+PiB3cm90ZToNCj4gPj4+Pj4+Pj4gDQo+ID4+Pj4+Pj4+PiBPbiAx MCBBdWcgMjAxNSwgYXQgMTI6MTcsIEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPiB3 cm90ZToNCj4gPj4+Pj4+Pj4+IA0KPiA+Pj4+Pj4+Pj4gSGksDQo+ID4+Pj4+Pj4+PiANCj4gPj4+ Pj4+Pj4+IEkgYW0gc3Ryb25nbHkgYWdhaW5zdCBjaGFuZ2luZyB0aGUgY29udHJhY3Qgb24gZXh0 ZW5zaW9ucy4NCj4gPj4+Pj4+Pj4+IFRoZXkgTUFZIGJlIGlnbm9yZWQgYnkgYW55IFlBTkcgdG9v bC4gUGVyaW9kLg0KPiA+Pj4+Pj4+Pj4gVGhhdCBtZWFucyB0aGV5IGFyZSBmYXIgZnJvbSBtYW5k YXRvcnkuDQo+ID4+Pj4+Pj4+PiBUaGV5IGFyZSBsaXR0bGUgbW9yZSB0aGFuIGEga2V5d29yZCBh bmQgYSBkZXNjcmlwdGlvbiBjbGF1c2UuDQo+ID4+Pj4+Pj4+IA0KPiA+Pj4+Pj4+PiBTbyBkbyB5 b3UgcHJlZmVyIG15IHByb3Bvc2VkIHNvbHV0aW9uIC0wMiBvciAtMDM/DQo+ID4+Pj4+Pj4+IA0K PiA+Pj4+Pj4+PiAqKiBTb2x1dGlvbiBZeHgtMDMNCj4gPj4+Pj4+Pj4gDQo+ID4+Pj4+Pj4+ICAg TWFrZSBleHRlbnNpb25zIG9wdGlvbmFsLiBUaGlzIG1lYW5zIHRoYXQgZXh0ZW5zaW9ucyB3b24n dCBiZQ0KPiA+Pj4+Pj4+PiAgIGFsbG93ZWQgdG8gY2hhbmdlIFlBTkcgbGFuZ3VhZ2UsIE5FVENP TkYgcHJvdG9jb2wsIGFuZCB2YWxpZGl0eSBvZg0KPiA+Pj4+Pj4+PiAgIGRhdGFzdG9yZXMgYW5k IHByb3RvY29sIG1lc3NhZ2VzLg0KPiA+Pj4+Pj4+PiANCj4gPj4+Pj4+Pj4gDQo+ID4+Pj4+Pj4+ IFRoaXMgaXMgaG93IHdlIHVzZSBleHRlbnNpb25zIHRvIHRhZyBZQU5HIGRhdGEgbW9kZWxzDQo+ ID4+Pj4+Pj4+IHRvIGRyaXZlIGF1dG9tYXRpb24gdG9vbHMuDQo+ID4+Pj4+Pj4gDQo+ID4+Pj4+ Pj4gQnV0IHRoYXQgbWVhbnMsIGZvciBleGFtcGxlLCB0aGF0IGFubm90YXRpb25zIGNhbm5vdCBi ZSBkZWZpbmVkIHZpYSBhbg0KPiA+Pj4+Pj4+IGV4dGVuc2lvbiBzdGF0ZW1lbnQgYXMgaW4gZHJh ZnQtaWV0Zi1uZXRtb2QteWFuZy1tZXRhZGF0YS4NCj4gPj4+Pj4+PiANCj4gPj4+Pj4+PiANCj4g Pj4+Pj4+PiANCj4gPj4+Pj4+PiBXaGljaCBtZWFucyB0aGVzZSBzdGF0ZW1lbnRzIHNob3VsZCBi ZSByZWFsIGluc3RlYWQgb2YgZXh0ZW5zaW9ucy4NCj4gPj4+Pj4+PiBJZiB0aGUgc3RhdGVtZW50 cyBhcmUgZGVmaW5pbmcgZGF0YSB0aGF0IGlzIGV4Y2hhbmdlZCBiZXR3ZWVuDQo+ID4+Pj4+Pj4g cGVlcnMgaW4gYSBzdGFuZGFyZCBwcm90b2NvbCwgdGhlbiBZQU5HIGV4dGVuc2lvbnMgYXJlIG5v dA0KPiA+Pj4+Pj4+IGFwcHJvcHJpYXRlLg0KPiA+Pj4+Pj4gDQo+ID4+Pj4+PiBJIGFncmVlLCBh bmQgLTAzIGlzIG15IHByZWZlcnJlZCBzb2x1dGlvbiwgdG9vLg0KPiA+Pj4+PiANCj4gPj4+Pj4g SSBzdHJvbmdseSBkaXNhZ3JlZS4gIElNTyB0aGUgSUVURiB1c2FnZSBvZiBleHRlbnNpb25zIHNv IGZhciAoTkFDTSwNCj4gPj4+Pj4gYW5ub3RhdGlvbnMpIHdvcmtzIHdlbGwgKGluIHRoZSBjYXNl IG9mIE5BQ00gcHJvdmVuIGJ5IG11bHRpcGxlDQo+ID4+Pj4+IGluZGVwZW5kZW50IGltcGxlbWVu dGF0aW9ucyksIGFuZCBmb2xsb3dzIGhvdyBleHRlbnNpb25zIHdlcmUgaW50ZW5kZWQNCj4gPj4+ Pj4gdG8gYmUgdXNlZCwgYW5kIG9idmlvdXNseSwgaG93IHRoZSBXRyBoYXMgdW5kZXJzdG9vZCB0 aGVtIHVwIHVudGlsDQo+ID4+Pj4+IG5vdy4NCj4gPj4+Pj4gDQo+ID4+Pj4+IElmIHRoZSBzZW50 ZW5jZToNCj4gPj4+Pj4gDQo+ID4+Pj4+ICAgSWYgYSBZQU5HIGNvbXBpbGVyIGRvZXMgbm90IHN1 cHBvcnQgYSBwYXJ0aWN1bGFyIGV4dGVuc2lvbiwgd2hpY2gNCj4gPj4+Pj4gICBhcHBlYXJzIGlu IGEgWUFORyBtb2R1bGUgYXMgYW4gdW5rbm93bi1zdGF0ZW1lbnQgKHNlZSBTZWN0aW9uIDEyKSwN Cj4gPj4+Pj4gICB0aGUgZW50aXJlIHVua25vd24tc3RhdGVtZW50IE1BWSBiZSBpZ25vcmVkIGJ5 IHRoZSBjb21waWxlci4NCj4gPj4+Pj4gDQo+ID4+Pj4+IGluIDYwMjAgY2FuIGJlIGludGVycHJl dGVkIHRvIG1lYW4gdGhhdCBhbiBvY2N1cmFuY2Ugb2YgYW4gZXh0ZW5zaW9uDQo+ID4+Pj4+IGlz IG5vbi1ub3JtYXRpdmUsIHdlIHNob3VsZCBmaXggaXQgc28gdGhhdCBpdCBtYXRjaGVzIHdoYXQg d2FzDQo+ID4+Pj4+IGludGVuZGVkIGFuZCBob3cgaXQgaXMgdXNlZC4NCj4gPj4+Pj4gDQo+ID4+ Pj4+IEp1ZXJnZW4gc3VnZ2VzdGVkIHRoaXMgcmVwbGFjZW1lbnQgdGV4dCwgd2hpY2ggSSBzdXBw b3J0LiAgTWF5YmUgaXQNCj4gPj4+Pj4gY2FuIGJlIGltcHJvdmVkIGV2ZW4gbW9yZS4NCj4gPj4+ Pj4gDQo+ID4+Pj4+ICAgICAgIElmIGEgWUFORyBwYXJzZXIgZG9lcyBub3Qgc3VwcG9ydCBhIHBh cnRpY3VsYXIgZXh0ZW5zaW9uLCB3aGljaA0KPiA+Pj4+PiAgICAgICBhcHBlYXJzIGluIGEgWUFO RyBtb2R1bGUgYXMgYW4gdW5rbm93bi1zdGF0ZW1lbnQgKHNlZSBTZWN0aW9uIDEzKSwNCj4gPj4+ Pj4gICAgICAgdGhlIGVudGlyZSB1bmtub3duLXN0YXRlbWVudCBNQVkgYmUgaWdub3JlZCBieSB0 aGUgcGFyc2VyLiBOb3RlDQo+ID4+Pj4+ICAgICAgIHRoYXQgZXZlbiBpbiB0aGlzIGNhc2UgdGhl IHNlbWFudGljcyBhc3NvY2lhdGVkIHdpdGggdGhlIGV4dGVuc2lvbg0KPiA+Pj4+PiAgICAgICBz dGlsbCBhcHBseSAoYXMgaWYgdGhleSB3ZXJlIHBhcnQgb2YgYSBkZXNjcmlwdGlvbiBzdGF0ZW1l bnQpLg0KPiA+Pj4+PiANCj4gPj4+Pj4gDQo+ID4+Pj4gDQo+ID4+Pj4gSSBzdHJvbmdseSBkaXNh Z3JlZSB3aXRoIHRoaXMgY2hhbmdlLg0KPiA+Pj4+IFRoaXMgd291bGQgbWVhbiB0aGF0IGV2ZXJ5 IHRvb2wgaXMgcmVxdWlyZWQgdG8gc3VwcG9ydCB0aGUNCj4gPj4+PiBzZW1hbnRpY3Mgb2YgZXZl cnkgZXh0ZW5zaW9uIGV2ZXIgZGVmaW5lZC4NCj4gPj4+IA0KPiA+Pj4gTm8uICBJdCBtZWFucyB0 aGF0IGlmIGEgc2VydmVyIGFkdmVydGlzZXMgbW9kdWxlIHRoYXQgdXNlcyBzb21lDQo+ID4+PiBl eHRlbnNpb24gdG8gZGVmaW5lIHNvbWUgYmVoYXZpb3VyLCB0aGUgc2VydmVyIHN1cHBvcnRzIHRo YXQNCj4gPj4+IGJlaGF2aW9yLiAgSnVzdCBhcyB3ZSBleHBlY3QgYSBzZXJ2ZXIgdG8gc3VwcG9y dCB0aGUgdGV4dCBpbg0KPiA+Pj4gZGVzY3JpcHRpb24gc3RhdGVtZW50cy4NCj4gPj4gDQo+ID4+ IFRoaXMgaXMgdW5jbGVhciBib3RoIGZyb20gdGhlIGN1cnJlbnQgdGV4dCBhbmQgZnJvbSBKdWVy Z2VuJ3MNCj4gPj4gcHJvcG9zYWwuIE1heWJlIEkgYW0gYSBuaXRwaWNrZXIgYnV0IGFzc3VtZSB0 aGF0IGVpdGhlciAoaSkgc2VydmVyDQo+ID4+IGltcGxlbWVudGF0aW9uIGlzIGNvbXBsZXRlbHkg Z2VuZXJhdGVkIGZyb20gdGhlIGRhdGEgbW9kZWwsIG9yIChpaSkNCj4gPj4gdGhlDQo+ID4+IHBh cnNlciBpbiBxdWVzdGlvbiBpcyBzaW1wbHkgaW4gdGhlIGltcGxlbWVudG9yJ3MgaGVhZC4gVGhl biBJIGRvbid0DQo+ID4+IGtub3cgaG93IHRoZSBzZXJ2ZXIgY2FuIGltcGxlbWVudCB0aGUgc2Vt YW50aWNzIG9mIGFuIGV4dGVuc2lvbiBpZiB0aGUNCj4gPj4gZXh0ZW5zaW9uIGlzIHJlbW92ZWQg d2hpbGUgWUFORyBtb2R1bGVzIGNvbnRhaW5pbmcgaXQgYXJlIGJlaW5nDQo+ID4+IHBhcnNlZC4N Cj4gPj4gDQo+ID4+IEEgdGV4dCBsaWtlICJhIGNsaWVudCBNQVkgaWdub3JlIGFuIGV4dGVuc2lv biB0aGF0IGl0IGRvZXNuJ3QNCj4gPj4gdW5kZXJzdGFuZCIgd291bGQgYmUgY2xlYXJlciBidXQg SSBkb24ndCB0aGluayBpdCBpcyBhY2NlcHRhYmxlIGlmIHRoZQ0KPiA+PiBleHRlbnNpb24gY2hh bmdlcw0KPiA+PiANCj4gPj4gLSBzZW1hbnRpY3Mgb2YgWUFORywNCj4gPiANCj4gPiBBZ3JlZWQu DQo+ID4gDQo+ID4+IC0gc2VtYW50aWNzIG9mIHRoZSBwcm90b2NvbCwNCj4gPiANCj4gPiBNYXli ZS4uLg0KPiA+IA0KPiA+PiAtIHNjaGVtYSBvZiB0aGUgZGF0YSBtb2RlbCAoYXMgYW5ub3RhdGlv bnMgZG8pLg0KPiA+IA0KPiA+IEkgdGhpbmsgaXQgaXMgb2sgdG8gZGVmaW5lIGFuIGFubm90YXRp b24gd2l0aCBhbiBleHRlbnNpb24gKGFzIHRoZQ0KPiA+IGRyYWZ0IGRvZXMpLiAgV2hlbiBkZXNp Z25pbmcgYSBmZWF0dXJlIHRoYXQgaXMgZ29pbmcgdG8gdXNlIGFuDQo+ID4gYW5ub3RhdGlvbiBp dCBpcyBpbXBvcnRhbnQgdG8ga2VlcCBpbiBtaW5kIHRoYXQgbm90IGFsbCBjbGllbnRzIHdpbGwN Cj4gPiB1bmRlcnN0YW5kIHRoZSBhbm5vdGF0aW9uLiAgU28gZS5nLiBpZiB0aGUgbmV3IGZlYXR1 cmUgaXMgYSAiY29tbWVudCIsDQo+ID4gdGhlIHNlcnZlciBtaWdodCBqdXN0IGJsaW5kbHkgcmV0 dXJuIHRoZW0gdG8gYWxsIGNsaWVudHMsIGJ1dCBpbiB0aGUNCj4gDQo+IEZvciBhIGNsaWVudCB0 aGF0IGRvZXNu4oCZdCB1bmRlcnN0YW5kIHRoZSBhbm5vdGF0aW9uIChvciBhbm5vdGF0aW9ucyBp bg0KPiBnZW5lcmFsKSBpdCBpcyBqdXN0IGV4dHJhIGp1bmsgdGhhdOKAmXMgbm90IGluIHRoZSBk YXRhIG1vZGVsLiBUaGlzIGlzDQo+IG5vIGRpZmZlcmVudCBmcm9tIGEgbmV3IGRhdGEgbm9kZSB0 eXBlIGRlZmluZWQgdGhyb3VnaCBhbiBleHRlbnNpb24gLQ0KPiBpbiBmYWN0LCBpbiBKU09OIGVu Y29kaW5nIGFubm90YXRpb25zIGFyZSBqdXN0IHNwZWNpYWwgb2JqZWN0DQo+IG1lbWJlcnMuIEEg cHJ1ZGVudCBjbGllbnQgbWF5IGNvbnNpZGVyIHN1Y2ggZGF0YSBpbnZhbGlkLg0KPiANCj4gPiBj YXNlIG9mICJpbmFjdGl2ZSIsIHRoZSBzZXJ2ZXIgbXVzdCBub3Qgc2VuZCB0aGVzZSBhdHRyaWJ1 dGVzIHRvIGENCj4gPiBjbGllbnQgdGhhdCBkb2Vzbid0IGFzayBmb3IgdGhlbS4gIChZb3UgbWF5 IGFyZ3VlIHRoYXQgZXZlbiBmb3INCj4gPiBjb21tZW50cyB0aGUgY2xpZW50IHNob3VsZCBhc2sg Zm9yIHRoZW0sIGJ1dCB0aGF0IGlzIGJlc2lkZXMgdGhlDQo+ID4gcG9pbnQpLg0KPiANCj4gSU1P IOKAnGluYWN0aXZl4oCdIGRhdGEgY2hhbmdlIHRoZSBORVRDT05GL1JFU1RDT05GIHByb3RvY29s LiBJZiBhIGNsaWVudA0KPiBkb2VzbuKAmXQgc2VlIGluYWN0aXZlIGRhdGEsIGl0IG1heSB0aGlu ayBpdCBpcyBPSyB0byB3cml0ZSBpdHMgb3duDQo+IGNvbnRlbnQgdG8gdGhhdCBwbGFjZSwgd2hp Y2ggcHJvYmFibHkgc2hvdWxkbuKAmXQgYmUgYWxsb3dlZC4NCj4gDQo+ID4gDQo+ID4gVGhlIGJv dHRvbSBsaW5lIGlzIHRoYXQgeW91IGhhdmUgdG8gYmUgY2FyZWZ1bCB3aGVuIHlvdSBkZWZpbmUg YSBuZXcNCj4gPiBleHRlbnNpb24gc3RhdGVtZW50Lg0KPiA+IA0KPiA+Pj4gRm9yIGV4YW1wbGUs IHRoZSBuYWNtOiBleHRlbnNpb25zIGRvIG5vdCBhcHBseSB1bmxlc3MgaWV0Zi1uZXRjb25mLWFj bQ0KPiA+Pj4gaXMgYWR2ZXJ0aXNlZCAoYW5kIG5hY20gaXMgZW5hYmxlZCkuICBJIGV4cGVjdCBt b3N0IGV4dGVuc2lvbnMgdG8gd29yaw0KPiA+Pj4gdGhpcyB3YXkuICBBbm90aGVyIGV4YW1wbGUg aXMgaWYgd2UgYWN0dWFsbHkgZGVmaW5lZCBpMnJzOmVwaGVtZXJhbDsNCj4gPj4+IHRoaXMgd291 bGQgaGF2ZSBubyBlZmZlY3QgdW5sZXNzIHRoZSAiaTJycyIgY2FwYWJpbGl0eSAod2hhdGV2ZXIg dGhhdA0KPiA+Pj4gaXMpIGlzIGFsc28gYWR2ZXJ0aXNlZC4NCj4gPj4gDQo+ID4+IFRoZSBuYWNt OiBleHRlbnNpb25zIGFyZSBwcm9iYWJseSBPSyBiZWNhdXNlIHRoZXkgb25seSBnaXZlIHNvbWUN Cj4gPj4gYWRkaXRpb25hbCBpbmZvIGFib3V0IHRoZSBzZXJ2ZXIgYmVoYXZpb3VyIHRoYXQgaXMg aW5kZXBlbmRlbnQgb2YNCj4gPj4gY2xpZW50J3Mgc3VwcG9ydC4gSWYgdGhlIGNsaWVudCBpZ25v cmVzIHRoZW0sIHRoZW4gaXQgbWF5IGJlIGp1c3QNCj4gPj4gd29uZGVyaW5nIHdoeSBpdCBjYW5u b3QgcmVhZCBvciB3cml0ZSBzb21lIGRhdGEuDQo+ID4gDQo+ID4gUmlnaHQuDQo+ID4gDQo+ID4+ PiBUaGUgdGV4dCBhbHNvIG1lYW5zIHRoYXQgaXQgaXMgcGVyZmVjdGx5IG9rIGZvciBhIGNsaWVu dCB0byBpZ25vcmUgdGhlDQo+ID4+PiBleHRlbnNpb24gaWYgaXQgZG9lc24ndCB1bmRlcnN0YW5k IGl0LiAgRm9yIGV4YW1wbGUsIGlmIHRoZSBjbGllbnQgaGFzDQo+ID4+PiBubyBpZGVhIHdoYXQg dGhlIGVwaGVtZXJhbCBkYXRhc3RvcmUgaXQsIGl0IGRvZXNuJ3QgbWF0dGVyIHRoYXQgYSBub2Rl DQo+ID4+PiBpcyBtYXJrZWQgd2l0aCBpMnJzOmVwaGVtZXJhbCB0cnVlLg0KPiA+PiANCj4gPj4g SSBhbSBub3QgY29udmluY2VkIGF0IGFsbCBhYm91dCB0aGlzIG9uZS4gSWYgdGhlIHNlcnZlciBh ZHZlcnRpc2VzIHRoZQ0KPiA+PiAiaTJycyIgY2FwYWJpbGl0eSBhbmQgbW9kdWxlcyB0aGF0IHVz ZSAiaTJyczplcGhlbWVyYWwiIGV4dGVuc2lvbiwNCj4gPj4gdGhlbg0KPiA+PiBhIG5vcm1hbCBO RVRDT05GL1JFU1RDT05GIGNsaWVudCBjYW4gaWdub3JlIGJvdGggKFJGQyA2MjQxOiAiRWFjaCBw ZWVyDQo+ID4+IFsuLi5dIE1VU1QgaWdub3JlIGFueSBjYXBhYmlsaXR5IHJlY2VpdmVkIGZyb20g dGhlIG90aGVyIHBlZXIgdGhhdCBpdA0KPiA+PiBkb2VzIG5vdCByZXF1aXJlIG9yIGRvZXMgbm90 IHVuZGVyc3RhbmQuIikuIEJ1dGggd2hhdCB0aGVuOiBjYW4gdGhlDQo+ID4+IGNsaWVudCB0cmVh dCBub2RlcyB0YWdnZWQgd2l0aCAiaTJyczplcGhlbWVyYWwiIGp1c3QgYXMgc3RhbmRhcmQNCj4g Pj4gbm9kZXM/DQo+ID4gDQo+ID4gTXkgaWRlYSBoYXMgYmVlbiB0aGF0IGl0IHdvdWxkIGJlIHVz ZWQgYXM6DQo+ID4gDQo+ID4gICBsZWFmIG15LWVwaGVtZXJhbC1sZWFmIHsNCj4gPiAgICAgIGNv bmZpZyBmYWxzZTsNCj4gPiAgICAgIGkycnM6ZXBoZW1lcmFsIHRydWU7DQo+ID4gICAgICAuLi4N Cj4gPiAgIH0NCj4gPiANCj4gPiB3aGljaCBtZWFucyB0aGF0IGlmIHRoZSBjbGllbnQgZG9lc24n dCBrbm93IHdoYXQgdG8gZG8gd2l0aA0KPiA+ICJpMnJzOmVwaGVtZXJhbCIsIGl0IHdpbGwgaWdu b3JlIGl0LCBhcyBqdXN0IHNlZSB0aGlzIGFzIGEgbm9ybWFsDQo+ID4gY29uZmlnIGZhbHNlIG5v ZGUgdGhhdCBjYW4gYmUgcmVhZCB3aXRoIDxnZXQ+Lg0KPiANCj4gSXQgb2YgY291cnNlIGRlcGVu ZHMgb24gdGhlIHBhcnRpY3VsYXIgdXNhZ2UgcnVsZXMgLSBJIGFzc3VtZWQNCj4gZXBoZW1lcmFs IGRhdGEgd291bGQgYmUgY29uZmlnPXRydWUuIEJ1dCBldmVuIGluIHlvdXIgZXhhbXBsZSwgaWYN Cj4gZXBoZW1lcmFsIGRhdGEgYXJlIGluIGEgc3BlY2lhbCBkYXRhc3RvcmUsIHRoZXkgbWF5IG5v dCBiZSByZXR1cm5lZA0KPiB3aXRoIDxnZXQ+LCB3aGljaCBjYW4gYWdhaW4gdmlvbGF0ZSB0aGUg c2NoZW1hLg0KDQpSaWdodCwgdGhpcyBpZGVhIGFzc3VtZXMgdGhhdCBlcGhlbWVyYWwgZGF0YSAq aXMqIHJldHVybmVkIGJ5IDxnZXQ+Lg0KDQo+IEkgdGhpbmsgYXJiaXRyYXJ5IGV4dGVuc2lvbnMg YXJlIE9LIGlmIHRoZXkgYXJlIHVzZWQgaW4gYSBjb250cm9sbGVkDQo+IGVudmlyb25tZW50LCBl LmcuIGluIHNpbmdsZSB2ZW5kb3LigJlzIHNlcnZlciBhbmQgY2xpZW50IHNvZnR3YXJlLCBidXQN Cj4gaW4gZ2VuZXJhbCB0aGV5IGNhbiBicmVhayBpbnRlcm9wZXJhYmlsaXR5IHVubGVzcyB0aGV5 IGFyZSBhY2NvbXBhbmllZA0KPiB3aXRoIGEgYmlkaXJlY3Rpb25hbCBjbGllbnQtc2VydmVyIG5l Z290aWF0aW9uIG1lY2hhbmlzbS4NCg0KSSBhZ3JlZSB0aGF0IGl0IGlzIGltcG9ydGFudCB0byB0 aGluayBhYm91dCBwcm90b2NvbCBuZWdvdGlhdGlvbg0KbWVjaGFuaXNtcywgY2xpZW50IGJhY2t3 YXJkcyBjb21wYXRpYmlsaXR5IGV0Yy4gd2hlbiBkZWZpbmluZw0KZXh0ZW5zaW9ucy4NCg0KDQov bWFydGluDQo= From nobody Thu Aug 20 04:23:53 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC9661A923E for ; Thu, 20 Aug 2015 04:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.239 X-Spam-Level: X-Spam-Status: No, score=0.239 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_64=0.6, 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 DXFoXSL9PxvD for ; Thu, 20 Aug 2015 04:23:50 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D62AB1A92AC for ; Thu, 20 Aug 2015 04:23:49 -0700 (PDT) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 522EB18128C; Thu, 20 Aug 2015 13:23:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1440069827; bh=QYZpx94KKI9qcLMe0N4U+p/anCw7iUxaLp2muvA5/Sg=; h=From:Date:To; b=QVb6+v4Jxv7mZvqWb5h2rM4ZV2pOEcDFxSlQnU/TO8LP/P1rjEz1GkWLA6nGbfsnz FHqfI2kXuN9+25vXrYLL4ZaFJcExZ2HLArsOtkEMazvVW07ru7XaaAWG0Tu3+Y11m6 PZ1ecA3HqltoD+0UJQvbcNgg5hOEx+ck2qfBQ7uA= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: <20150820.131242.583799169537333295.mbj@tail-f.com> Date: Thu, 20 Aug 2015 13:23:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3B335831-4C79-4EB4-AC62-EA21D50E5928@nic.cz> References: <20150820.123741.252355277712113387.mbj@tail-f.com> <5E452E16-4728-4A74-AD74-65404E6DA98C@nic.cz> <20150820.131242.583799169537333295.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] extensions and conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 11:23:52 -0000 > On 20 Aug 2015, at 13:12, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >>=20 >>> On 20 Aug 2015, at 12:37, Martin Bjorklund wrote: >>>=20 >>> Ladislav Lhotka wrote: >>>> Martin Bjorklund writes: >>>>=20 >>>>> Andy Bierman wrote: >>>>>> On Wed, Aug 19, 2015 at 5:49 AM, Martin Bjorklund = >>>>>> wrote: >>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> [joining this discussion a bit late] >>>>>>>=20 >>>>>>> Ladislav Lhotka wrote: >>>>>>>>=20 >>>>>>>>> On 10 Aug 2015, at 18:46, Andy Bierman = wrote: >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On Mon, Aug 10, 2015 at 9:37 AM, Ladislav Lhotka = >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>> On 10 Aug 2015, at 17:32, Andy Bierman = wrote: >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On Mon, Aug 10, 2015 at 4:24 AM, Ladislav Lhotka = >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> On 10 Aug 2015, at 12:17, Andy Bierman = wrote: >>>>>>>>>>>=20 >>>>>>>>>>> Hi, >>>>>>>>>>>=20 >>>>>>>>>>> I am strongly against changing the contract on extensions. >>>>>>>>>>> They MAY be ignored by any YANG tool. Period. >>>>>>>>>>> That means they are far from mandatory. >>>>>>>>>>> They are little more than a keyword and a description = clause. >>>>>>>>>>=20 >>>>>>>>>> So do you prefer my proposed solution -02 or -03? >>>>>>>>>>=20 >>>>>>>>>> ** Solution Yxx-03 >>>>>>>>>>=20 >>>>>>>>>> Make extensions optional. This means that extensions won't = be >>>>>>>>>> allowed to change YANG language, NETCONF protocol, and = validity of >>>>>>>>>> datastores and protocol messages. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> This is how we use extensions to tag YANG data models >>>>>>>>>> to drive automation tools. >>>>>>>>>=20 >>>>>>>>> But that means, for example, that annotations cannot be = defined via an >>>>>>>>> extension statement as in draft-ietf-netmod-yang-metadata. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Which means these statements should be real instead of = extensions. >>>>>>>>> If the statements are defining data that is exchanged between >>>>>>>>> peers in a standard protocol, then YANG extensions are not >>>>>>>>> appropriate. >>>>>>>>=20 >>>>>>>> I agree, and -03 is my preferred solution, too. >>>>>>>=20 >>>>>>> I strongly disagree. IMO the IETF usage of extensions so far = (NACM, >>>>>>> annotations) works well (in the case of NACM proven by multiple >>>>>>> independent implementations), and follows how extensions were = intended >>>>>>> to be used, and obviously, how the WG has understood them up = until >>>>>>> now. >>>>>>>=20 >>>>>>> If the sentence: >>>>>>>=20 >>>>>>> If a YANG compiler does not support a particular extension, = which >>>>>>> appears in a YANG module as an unknown-statement (see Section = 12), >>>>>>> the entire unknown-statement MAY be ignored by the compiler. >>>>>>>=20 >>>>>>> in 6020 can be interpreted to mean that an occurance of an = extension >>>>>>> is non-normative, we should fix it so that it matches what was >>>>>>> intended and how it is used. >>>>>>>=20 >>>>>>> Juergen suggested this replacement text, which I support. Maybe = it >>>>>>> can be improved even more. >>>>>>>=20 >>>>>>> If a YANG parser does not support a particular extension, = which >>>>>>> appears in a YANG module as an unknown-statement (see = Section 13), >>>>>>> the entire unknown-statement MAY be ignored by the parser. = Note >>>>>>> that even in this case the semantics associated with the = extension >>>>>>> still apply (as if they were part of a description = statement). >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>> I strongly disagree with this change. >>>>>> This would mean that every tool is required to support the >>>>>> semantics of every extension ever defined. >>>>>=20 >>>>> No. It means that if a server advertises module that uses some >>>>> extension to define some behaviour, the server supports that >>>>> behavior. Just as we expect a server to support the text in >>>>> description statements. >>>>=20 >>>> This is unclear both from the current text and from Juergen's >>>> proposal. Maybe I am a nitpicker but assume that either (i) server >>>> implementation is completely generated from the data model, or (ii) >>>> the >>>> parser in question is simply in the implementor's head. Then I = don't >>>> know how the server can implement the semantics of an extension if = the >>>> extension is removed while YANG modules containing it are being >>>> parsed. >>>>=20 >>>> A text like "a client MAY ignore an extension that it doesn't >>>> understand" would be clearer but I don't think it is acceptable if = the >>>> extension changes >>>>=20 >>>> - semantics of YANG, >>>=20 >>> Agreed. >>>=20 >>>> - semantics of the protocol, >>>=20 >>> Maybe... >>>=20 >>>> - schema of the data model (as annotations do). >>>=20 >>> I think it is ok to define an annotation with an extension (as the >>> draft does). When designing a feature that is going to use an >>> annotation it is important to keep in mind that not all clients will >>> understand the annotation. So e.g. if the new feature is a = "comment", >>> the server might just blindly return them to all clients, but in the >>=20 >> For a client that doesn=E2=80=99t understand the annotation (or = annotations in >> general) it is just extra junk that=E2=80=99s not in the data model. = This is >> no different from a new data node type defined through an extension - >> in fact, in JSON encoding annotations are just special object >> members. A prudent client may consider such data invalid. >>=20 >>> case of "inactive", the server must not send these attributes to a >>> client that doesn't ask for them. (You may argue that even for >>> comments the client should ask for them, but that is besides the >>> point). >>=20 >> IMO =E2=80=9Cinactive=E2=80=9D data change the NETCONF/RESTCONF = protocol. If a client >> doesn=E2=80=99t see inactive data, it may think it is OK to write its = own >> content to that place, which probably shouldn=E2=80=99t be allowed. >>=20 >>>=20 >>> The bottom line is that you have to be careful when you define a new >>> extension statement. >>>=20 >>>>> For example, the nacm: extensions do not apply unless = ietf-netconf-acm >>>>> is advertised (and nacm is enabled). I expect most extensions to = work >>>>> this way. Another example is if we actually defined = i2rs:ephemeral; >>>>> this would have no effect unless the "i2rs" capability (whatever = that >>>>> is) is also advertised. >>>>=20 >>>> The nacm: extensions are probably OK because they only give some >>>> additional info about the server behaviour that is independent of >>>> client's support. If the client ignores them, then it may be just >>>> wondering why it cannot read or write some data. >>>=20 >>> Right. >>>=20 >>>>> The text also means that it is perfectly ok for a client to ignore = the >>>>> extension if it doesn't understand it. For example, if the client = has >>>>> no idea what the ephemeral datastore it, it doesn't matter that a = node >>>>> is marked with i2rs:ephemeral true. >>>>=20 >>>> I am not convinced at all about this one. If the server advertises = the >>>> "i2rs" capability and modules that use "i2rs:ephemeral" extension, >>>> then >>>> a normal NETCONF/RESTCONF client can ignore both (RFC 6241: "Each = peer >>>> [...] MUST ignore any capability received from the other peer that = it >>>> does not require or does not understand."). Buth what then: can the >>>> client treat nodes tagged with "i2rs:ephemeral" just as standard >>>> nodes? >>>=20 >>> My idea has been that it would be used as: >>>=20 >>> leaf my-ephemeral-leaf { >>> config false; >>> i2rs:ephemeral true; >>> ... >>> } >>>=20 >>> which means that if the client doesn't know what to do with >>> "i2rs:ephemeral", it will ignore it, as just see this as a normal >>> config false node that can be read with . >>=20 >> It of course depends on the particular usage rules - I assumed >> ephemeral data would be config=3Dtrue. But even in your example, if >> ephemeral data are in a special datastore, they may not be returned >> with , which can again violate the schema. >=20 > Right, this idea assumes that ephemeral data *is* returned by . >=20 >> I think arbitrary extensions are OK if they are used in a controlled >> environment, e.g. in single vendor=E2=80=99s server and client = software, but >> in general they can break interoperability unless they are = accompanied >> with a bidirectional client-server negotiation mechanism. >=20 > I agree that it is important to think about protocol negotiation > mechanisms, client backwards compatibility etc. when defining > extensions. But even then it might be difficult to handle situations where one = client supports an extension while another doesn=E2=80=99t - the server = simply may not be able to behave simultaneously in two different ways. = That=E2=80=99s why I think the only option that=E2=80=99s really safe = for now is ** Solution Yxx-03 Make extensions optional. This means that extensions won't be allowed to change YANG language, NETCONF protocol, and validity of datastores and protocol messages. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Aug 20 04:29:02 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F34F01A013B for ; Thu, 20 Aug 2015 04:29:01 -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_64=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 QkKrieG_Z2Xz for ; Thu, 20 Aug 2015 04:28: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 808491A0127 for ; Thu, 20 Aug 2015 04:28:59 -0700 (PDT) Received: from localhost (unknown [173.38.220.43]) by mail.tail-f.com (Postfix) with ESMTPSA id 871211AE035B; Thu, 20 Aug 2015 13:28:58 +0200 (CEST) Date: Thu, 20 Aug 2015 13:28:57 +0200 (CEST) Message-Id: <20150820.132857.1812838545863613387.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <3B335831-4C79-4EB4-AC62-EA21D50E5928@nic.cz> References: <5E452E16-4728-4A74-AD74-65404E6DA98C@nic.cz> <20150820.131242.583799169537333295.mbj@tail-f.com> <3B335831-4C79-4EB4-AC62-EA21D50E5928@nic.cz> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] extensions and conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 11:29:02 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+ID4gT24gMjAgQXVn IDIwMTUsIGF0IDEzOjEyLCBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4gd3JvdGU6 DQo+ID4gDQo+ID4gTGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gPj4g DQo+ID4+PiBPbiAyMCBBdWcgMjAxNSwgYXQgMTI6MzcsIE1hcnRpbiBCam9ya2x1bmQgPG1iakB0 YWlsLWYuY29tPiB3cm90ZToNCj4gPj4+IA0KPiA+Pj4gTGFkaXNsYXYgTGhvdGthIDxsaG90a2FA bmljLmN6PiB3cm90ZToNCj4gPj4+PiBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4g d3JpdGVzOg0KPiA+Pj4+IA0KPiA+Pj4+PiBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNv bT4gd3JvdGU6DQo+ID4+Pj4+PiBPbiBXZWQsIEF1ZyAxOSwgMjAxNSBhdCA1OjQ5IEFNLCBNYXJ0 aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4NCj4gPj4+Pj4+IHdyb3RlOg0KPiA+Pj4+Pj4g DQo+ID4+Pj4+Pj4gSGksDQo+ID4+Pj4+Pj4gDQo+ID4+Pj4+Pj4gW2pvaW5pbmcgdGhpcyBkaXNj dXNzaW9uIGEgYml0IGxhdGVdDQo+ID4+Pj4+Pj4gDQo+ID4+Pj4+Pj4gTGFkaXNsYXYgTGhvdGth IDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gPj4+Pj4+Pj4gDQo+ID4+Pj4+Pj4+PiBPbiAxMCBB dWcgMjAxNSwgYXQgMTg6NDYsIEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPiB3cm90 ZToNCj4gPj4+Pj4+Pj4+IA0KPiA+Pj4+Pj4+Pj4gDQo+ID4+Pj4+Pj4+PiANCj4gPj4+Pj4+Pj4+ IE9uIE1vbiwgQXVnIDEwLCAyMDE1IGF0IDk6MzcgQU0sIExhZGlzbGF2IExob3RrYSA8bGhvdGth QG5pYy5jej4NCj4gPj4+Pj4+Pj4+IHdyb3RlOg0KPiA+Pj4+Pj4+Pj4gDQo+ID4+Pj4+Pj4+Pj4g T24gMTAgQXVnIDIwMTUsIGF0IDE3OjMyLCBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNv bT4gd3JvdGU6DQo+ID4+Pj4+Pj4+Pj4gDQo+ID4+Pj4+Pj4+Pj4gDQo+ID4+Pj4+Pj4+Pj4gDQo+ ID4+Pj4+Pj4+Pj4gT24gTW9uLCBBdWcgMTAsIDIwMTUgYXQgNDoyNCBBTSwgTGFkaXNsYXYgTGhv dGthIDxsaG90a2FAbmljLmN6Pg0KPiA+Pj4+Pj4+Pj4+IHdyb3RlOg0KPiA+Pj4+Pj4+Pj4+IA0K PiA+Pj4+Pj4+Pj4+PiBPbiAxMCBBdWcgMjAxNSwgYXQgMTI6MTcsIEFuZHkgQmllcm1hbiA8YW5k eUB5dW1hd29ya3MuY29tPiB3cm90ZToNCj4gPj4+Pj4+Pj4+Pj4gDQo+ID4+Pj4+Pj4+Pj4+IEhp LA0KPiA+Pj4+Pj4+Pj4+PiANCj4gPj4+Pj4+Pj4+Pj4gSSBhbSBzdHJvbmdseSBhZ2FpbnN0IGNo YW5naW5nIHRoZSBjb250cmFjdCBvbiBleHRlbnNpb25zLg0KPiA+Pj4+Pj4+Pj4+PiBUaGV5IE1B WSBiZSBpZ25vcmVkIGJ5IGFueSBZQU5HIHRvb2wuIFBlcmlvZC4NCj4gPj4+Pj4+Pj4+Pj4gVGhh dCBtZWFucyB0aGV5IGFyZSBmYXIgZnJvbSBtYW5kYXRvcnkuDQo+ID4+Pj4+Pj4+Pj4+IFRoZXkg YXJlIGxpdHRsZSBtb3JlIHRoYW4gYSBrZXl3b3JkIGFuZCBhIGRlc2NyaXB0aW9uIGNsYXVzZS4N Cj4gPj4+Pj4+Pj4+PiANCj4gPj4+Pj4+Pj4+PiBTbyBkbyB5b3UgcHJlZmVyIG15IHByb3Bvc2Vk IHNvbHV0aW9uIC0wMiBvciAtMDM/DQo+ID4+Pj4+Pj4+Pj4gDQo+ID4+Pj4+Pj4+Pj4gKiogU29s dXRpb24gWXh4LTAzDQo+ID4+Pj4+Pj4+Pj4gDQo+ID4+Pj4+Pj4+Pj4gIE1ha2UgZXh0ZW5zaW9u cyBvcHRpb25hbC4gVGhpcyBtZWFucyB0aGF0IGV4dGVuc2lvbnMgd29uJ3QgYmUNCj4gPj4+Pj4+ Pj4+PiAgYWxsb3dlZCB0byBjaGFuZ2UgWUFORyBsYW5ndWFnZSwgTkVUQ09ORiBwcm90b2NvbCwg YW5kIHZhbGlkaXR5IG9mDQo+ID4+Pj4+Pj4+Pj4gIGRhdGFzdG9yZXMgYW5kIHByb3RvY29sIG1l c3NhZ2VzLg0KPiA+Pj4+Pj4+Pj4+IA0KPiA+Pj4+Pj4+Pj4+IA0KPiA+Pj4+Pj4+Pj4+IFRoaXMg aXMgaG93IHdlIHVzZSBleHRlbnNpb25zIHRvIHRhZyBZQU5HIGRhdGEgbW9kZWxzDQo+ID4+Pj4+ Pj4+Pj4gdG8gZHJpdmUgYXV0b21hdGlvbiB0b29scy4NCj4gPj4+Pj4+Pj4+IA0KPiA+Pj4+Pj4+ Pj4gQnV0IHRoYXQgbWVhbnMsIGZvciBleGFtcGxlLCB0aGF0IGFubm90YXRpb25zIGNhbm5vdCBi ZSBkZWZpbmVkIHZpYSBhbg0KPiA+Pj4+Pj4+Pj4gZXh0ZW5zaW9uIHN0YXRlbWVudCBhcyBpbiBk cmFmdC1pZXRmLW5ldG1vZC15YW5nLW1ldGFkYXRhLg0KPiA+Pj4+Pj4+Pj4gDQo+ID4+Pj4+Pj4+ PiANCj4gPj4+Pj4+Pj4+IA0KPiA+Pj4+Pj4+Pj4gV2hpY2ggbWVhbnMgdGhlc2Ugc3RhdGVtZW50 cyBzaG91bGQgYmUgcmVhbCBpbnN0ZWFkIG9mIGV4dGVuc2lvbnMuDQo+ID4+Pj4+Pj4+PiBJZiB0 aGUgc3RhdGVtZW50cyBhcmUgZGVmaW5pbmcgZGF0YSB0aGF0IGlzIGV4Y2hhbmdlZCBiZXR3ZWVu DQo+ID4+Pj4+Pj4+PiBwZWVycyBpbiBhIHN0YW5kYXJkIHByb3RvY29sLCB0aGVuIFlBTkcgZXh0 ZW5zaW9ucyBhcmUgbm90DQo+ID4+Pj4+Pj4+PiBhcHByb3ByaWF0ZS4NCj4gPj4+Pj4+Pj4gDQo+ ID4+Pj4+Pj4+IEkgYWdyZWUsIGFuZCAtMDMgaXMgbXkgcHJlZmVycmVkIHNvbHV0aW9uLCB0b28u DQo+ID4+Pj4+Pj4gDQo+ID4+Pj4+Pj4gSSBzdHJvbmdseSBkaXNhZ3JlZS4gIElNTyB0aGUgSUVU RiB1c2FnZSBvZiBleHRlbnNpb25zIHNvIGZhciAoTkFDTSwNCj4gPj4+Pj4+PiBhbm5vdGF0aW9u cykgd29ya3Mgd2VsbCAoaW4gdGhlIGNhc2Ugb2YgTkFDTSBwcm92ZW4gYnkgbXVsdGlwbGUNCj4g Pj4+Pj4+PiBpbmRlcGVuZGVudCBpbXBsZW1lbnRhdGlvbnMpLCBhbmQgZm9sbG93cyBob3cgZXh0 ZW5zaW9ucyB3ZXJlIGludGVuZGVkDQo+ID4+Pj4+Pj4gdG8gYmUgdXNlZCwgYW5kIG9idmlvdXNs eSwgaG93IHRoZSBXRyBoYXMgdW5kZXJzdG9vZCB0aGVtIHVwIHVudGlsDQo+ID4+Pj4+Pj4gbm93 Lg0KPiA+Pj4+Pj4+IA0KPiA+Pj4+Pj4+IElmIHRoZSBzZW50ZW5jZToNCj4gPj4+Pj4+PiANCj4g Pj4+Pj4+PiAgSWYgYSBZQU5HIGNvbXBpbGVyIGRvZXMgbm90IHN1cHBvcnQgYSBwYXJ0aWN1bGFy IGV4dGVuc2lvbiwgd2hpY2gNCj4gPj4+Pj4+PiAgYXBwZWFycyBpbiBhIFlBTkcgbW9kdWxlIGFz IGFuIHVua25vd24tc3RhdGVtZW50IChzZWUgU2VjdGlvbiAxMiksDQo+ID4+Pj4+Pj4gIHRoZSBl bnRpcmUgdW5rbm93bi1zdGF0ZW1lbnQgTUFZIGJlIGlnbm9yZWQgYnkgdGhlIGNvbXBpbGVyLg0K PiA+Pj4+Pj4+IA0KPiA+Pj4+Pj4+IGluIDYwMjAgY2FuIGJlIGludGVycHJldGVkIHRvIG1lYW4g dGhhdCBhbiBvY2N1cmFuY2Ugb2YgYW4gZXh0ZW5zaW9uDQo+ID4+Pj4+Pj4gaXMgbm9uLW5vcm1h dGl2ZSwgd2Ugc2hvdWxkIGZpeCBpdCBzbyB0aGF0IGl0IG1hdGNoZXMgd2hhdCB3YXMNCj4gPj4+ Pj4+PiBpbnRlbmRlZCBhbmQgaG93IGl0IGlzIHVzZWQuDQo+ID4+Pj4+Pj4gDQo+ID4+Pj4+Pj4g SnVlcmdlbiBzdWdnZXN0ZWQgdGhpcyByZXBsYWNlbWVudCB0ZXh0LCB3aGljaCBJIHN1cHBvcnQu ICBNYXliZSBpdA0KPiA+Pj4+Pj4+IGNhbiBiZSBpbXByb3ZlZCBldmVuIG1vcmUuDQo+ID4+Pj4+ Pj4gDQo+ID4+Pj4+Pj4gICAgICBJZiBhIFlBTkcgcGFyc2VyIGRvZXMgbm90IHN1cHBvcnQgYSBw YXJ0aWN1bGFyIGV4dGVuc2lvbiwgd2hpY2gNCj4gPj4+Pj4+PiAgICAgIGFwcGVhcnMgaW4gYSBZ QU5HIG1vZHVsZSBhcyBhbiB1bmtub3duLXN0YXRlbWVudCAoc2VlIFNlY3Rpb24gMTMpLA0KPiA+ Pj4+Pj4+ICAgICAgdGhlIGVudGlyZSB1bmtub3duLXN0YXRlbWVudCBNQVkgYmUgaWdub3JlZCBi eSB0aGUgcGFyc2VyLiBOb3RlDQo+ID4+Pj4+Pj4gICAgICB0aGF0IGV2ZW4gaW4gdGhpcyBjYXNl IHRoZSBzZW1hbnRpY3MgYXNzb2NpYXRlZCB3aXRoIHRoZSBleHRlbnNpb24NCj4gPj4+Pj4+PiAg ICAgIHN0aWxsIGFwcGx5IChhcyBpZiB0aGV5IHdlcmUgcGFydCBvZiBhIGRlc2NyaXB0aW9uIHN0 YXRlbWVudCkuDQo+ID4+Pj4+Pj4gDQo+ID4+Pj4+Pj4gDQo+ID4+Pj4+PiANCj4gPj4+Pj4+IEkg c3Ryb25nbHkgZGlzYWdyZWUgd2l0aCB0aGlzIGNoYW5nZS4NCj4gPj4+Pj4+IFRoaXMgd291bGQg bWVhbiB0aGF0IGV2ZXJ5IHRvb2wgaXMgcmVxdWlyZWQgdG8gc3VwcG9ydCB0aGUNCj4gPj4+Pj4+ IHNlbWFudGljcyBvZiBldmVyeSBleHRlbnNpb24gZXZlciBkZWZpbmVkLg0KPiA+Pj4+PiANCj4g Pj4+Pj4gTm8uICBJdCBtZWFucyB0aGF0IGlmIGEgc2VydmVyIGFkdmVydGlzZXMgbW9kdWxlIHRo YXQgdXNlcyBzb21lDQo+ID4+Pj4+IGV4dGVuc2lvbiB0byBkZWZpbmUgc29tZSBiZWhhdmlvdXIs IHRoZSBzZXJ2ZXIgc3VwcG9ydHMgdGhhdA0KPiA+Pj4+PiBiZWhhdmlvci4gIEp1c3QgYXMgd2Ug ZXhwZWN0IGEgc2VydmVyIHRvIHN1cHBvcnQgdGhlIHRleHQgaW4NCj4gPj4+Pj4gZGVzY3JpcHRp b24gc3RhdGVtZW50cy4NCj4gPj4+PiANCj4gPj4+PiBUaGlzIGlzIHVuY2xlYXIgYm90aCBmcm9t IHRoZSBjdXJyZW50IHRleHQgYW5kIGZyb20gSnVlcmdlbidzDQo+ID4+Pj4gcHJvcG9zYWwuIE1h eWJlIEkgYW0gYSBuaXRwaWNrZXIgYnV0IGFzc3VtZSB0aGF0IGVpdGhlciAoaSkgc2VydmVyDQo+ ID4+Pj4gaW1wbGVtZW50YXRpb24gaXMgY29tcGxldGVseSBnZW5lcmF0ZWQgZnJvbSB0aGUgZGF0 YSBtb2RlbCwgb3IgKGlpKQ0KPiA+Pj4+IHRoZQ0KPiA+Pj4+IHBhcnNlciBpbiBxdWVzdGlvbiBp cyBzaW1wbHkgaW4gdGhlIGltcGxlbWVudG9yJ3MgaGVhZC4gVGhlbiBJIGRvbid0DQo+ID4+Pj4g a25vdyBob3cgdGhlIHNlcnZlciBjYW4gaW1wbGVtZW50IHRoZSBzZW1hbnRpY3Mgb2YgYW4gZXh0 ZW5zaW9uIGlmIHRoZQ0KPiA+Pj4+IGV4dGVuc2lvbiBpcyByZW1vdmVkIHdoaWxlIFlBTkcgbW9k dWxlcyBjb250YWluaW5nIGl0IGFyZSBiZWluZw0KPiA+Pj4+IHBhcnNlZC4NCj4gPj4+PiANCj4g Pj4+PiBBIHRleHQgbGlrZSAiYSBjbGllbnQgTUFZIGlnbm9yZSBhbiBleHRlbnNpb24gdGhhdCBp dCBkb2Vzbid0DQo+ID4+Pj4gdW5kZXJzdGFuZCIgd291bGQgYmUgY2xlYXJlciBidXQgSSBkb24n dCB0aGluayBpdCBpcyBhY2NlcHRhYmxlIGlmIHRoZQ0KPiA+Pj4+IGV4dGVuc2lvbiBjaGFuZ2Vz DQo+ID4+Pj4gDQo+ID4+Pj4gLSBzZW1hbnRpY3Mgb2YgWUFORywNCj4gPj4+IA0KPiA+Pj4gQWdy ZWVkLg0KPiA+Pj4gDQo+ID4+Pj4gLSBzZW1hbnRpY3Mgb2YgdGhlIHByb3RvY29sLA0KPiA+Pj4g DQo+ID4+PiBNYXliZS4uLg0KPiA+Pj4gDQo+ID4+Pj4gLSBzY2hlbWEgb2YgdGhlIGRhdGEgbW9k ZWwgKGFzIGFubm90YXRpb25zIGRvKS4NCj4gPj4+IA0KPiA+Pj4gSSB0aGluayBpdCBpcyBvayB0 byBkZWZpbmUgYW4gYW5ub3RhdGlvbiB3aXRoIGFuIGV4dGVuc2lvbiAoYXMgdGhlDQo+ID4+PiBk cmFmdCBkb2VzKS4gIFdoZW4gZGVzaWduaW5nIGEgZmVhdHVyZSB0aGF0IGlzIGdvaW5nIHRvIHVz ZSBhbg0KPiA+Pj4gYW5ub3RhdGlvbiBpdCBpcyBpbXBvcnRhbnQgdG8ga2VlcCBpbiBtaW5kIHRo YXQgbm90IGFsbCBjbGllbnRzIHdpbGwNCj4gPj4+IHVuZGVyc3RhbmQgdGhlIGFubm90YXRpb24u ICBTbyBlLmcuIGlmIHRoZSBuZXcgZmVhdHVyZSBpcyBhICJjb21tZW50IiwNCj4gPj4+IHRoZSBz ZXJ2ZXIgbWlnaHQganVzdCBibGluZGx5IHJldHVybiB0aGVtIHRvIGFsbCBjbGllbnRzLCBidXQg aW4gdGhlDQo+ID4+IA0KPiA+PiBGb3IgYSBjbGllbnQgdGhhdCBkb2VzbuKAmXQgdW5kZXJzdGFu ZCB0aGUgYW5ub3RhdGlvbiAob3IgYW5ub3RhdGlvbnMgaW4NCj4gPj4gZ2VuZXJhbCkgaXQgaXMg anVzdCBleHRyYSBqdW5rIHRoYXTigJlzIG5vdCBpbiB0aGUgZGF0YSBtb2RlbC4gVGhpcyBpcw0K PiA+PiBubyBkaWZmZXJlbnQgZnJvbSBhIG5ldyBkYXRhIG5vZGUgdHlwZSBkZWZpbmVkIHRocm91 Z2ggYW4gZXh0ZW5zaW9uIC0NCj4gPj4gaW4gZmFjdCwgaW4gSlNPTiBlbmNvZGluZyBhbm5vdGF0 aW9ucyBhcmUganVzdCBzcGVjaWFsIG9iamVjdA0KPiA+PiBtZW1iZXJzLiBBIHBydWRlbnQgY2xp ZW50IG1heSBjb25zaWRlciBzdWNoIGRhdGEgaW52YWxpZC4NCj4gPj4gDQo+ID4+PiBjYXNlIG9m ICJpbmFjdGl2ZSIsIHRoZSBzZXJ2ZXIgbXVzdCBub3Qgc2VuZCB0aGVzZSBhdHRyaWJ1dGVzIHRv IGENCj4gPj4+IGNsaWVudCB0aGF0IGRvZXNuJ3QgYXNrIGZvciB0aGVtLiAgKFlvdSBtYXkgYXJn dWUgdGhhdCBldmVuIGZvcg0KPiA+Pj4gY29tbWVudHMgdGhlIGNsaWVudCBzaG91bGQgYXNrIGZv ciB0aGVtLCBidXQgdGhhdCBpcyBiZXNpZGVzIHRoZQ0KPiA+Pj4gcG9pbnQpLg0KPiA+PiANCj4g Pj4gSU1PIOKAnGluYWN0aXZl4oCdIGRhdGEgY2hhbmdlIHRoZSBORVRDT05GL1JFU1RDT05GIHBy b3RvY29sLiBJZiBhIGNsaWVudA0KPiA+PiBkb2VzbuKAmXQgc2VlIGluYWN0aXZlIGRhdGEsIGl0 IG1heSB0aGluayBpdCBpcyBPSyB0byB3cml0ZSBpdHMgb3duDQo+ID4+IGNvbnRlbnQgdG8gdGhh dCBwbGFjZSwgd2hpY2ggcHJvYmFibHkgc2hvdWxkbuKAmXQgYmUgYWxsb3dlZC4NCj4gPj4gDQo+ ID4+PiANCj4gPj4+IFRoZSBib3R0b20gbGluZSBpcyB0aGF0IHlvdSBoYXZlIHRvIGJlIGNhcmVm dWwgd2hlbiB5b3UgZGVmaW5lIGEgbmV3DQo+ID4+PiBleHRlbnNpb24gc3RhdGVtZW50Lg0KPiA+ Pj4gDQo+ID4+Pj4+IEZvciBleGFtcGxlLCB0aGUgbmFjbTogZXh0ZW5zaW9ucyBkbyBub3QgYXBw bHkgdW5sZXNzIGlldGYtbmV0Y29uZi1hY20NCj4gPj4+Pj4gaXMgYWR2ZXJ0aXNlZCAoYW5kIG5h Y20gaXMgZW5hYmxlZCkuICBJIGV4cGVjdCBtb3N0IGV4dGVuc2lvbnMgdG8gd29yaw0KPiA+Pj4+ PiB0aGlzIHdheS4gIEFub3RoZXIgZXhhbXBsZSBpcyBpZiB3ZSBhY3R1YWxseSBkZWZpbmVkIGky cnM6ZXBoZW1lcmFsOw0KPiA+Pj4+PiB0aGlzIHdvdWxkIGhhdmUgbm8gZWZmZWN0IHVubGVzcyB0 aGUgImkycnMiIGNhcGFiaWxpdHkgKHdoYXRldmVyIHRoYXQNCj4gPj4+Pj4gaXMpIGlzIGFsc28g YWR2ZXJ0aXNlZC4NCj4gPj4+PiANCj4gPj4+PiBUaGUgbmFjbTogZXh0ZW5zaW9ucyBhcmUgcHJv YmFibHkgT0sgYmVjYXVzZSB0aGV5IG9ubHkgZ2l2ZSBzb21lDQo+ID4+Pj4gYWRkaXRpb25hbCBp bmZvIGFib3V0IHRoZSBzZXJ2ZXIgYmVoYXZpb3VyIHRoYXQgaXMgaW5kZXBlbmRlbnQgb2YNCj4g Pj4+PiBjbGllbnQncyBzdXBwb3J0LiBJZiB0aGUgY2xpZW50IGlnbm9yZXMgdGhlbSwgdGhlbiBp dCBtYXkgYmUganVzdA0KPiA+Pj4+IHdvbmRlcmluZyB3aHkgaXQgY2Fubm90IHJlYWQgb3Igd3Jp dGUgc29tZSBkYXRhLg0KPiA+Pj4gDQo+ID4+PiBSaWdodC4NCj4gPj4+IA0KPiA+Pj4+PiBUaGUg dGV4dCBhbHNvIG1lYW5zIHRoYXQgaXQgaXMgcGVyZmVjdGx5IG9rIGZvciBhIGNsaWVudCB0byBp Z25vcmUgdGhlDQo+ID4+Pj4+IGV4dGVuc2lvbiBpZiBpdCBkb2Vzbid0IHVuZGVyc3RhbmQgaXQu ICBGb3IgZXhhbXBsZSwgaWYgdGhlIGNsaWVudCBoYXMNCj4gPj4+Pj4gbm8gaWRlYSB3aGF0IHRo ZSBlcGhlbWVyYWwgZGF0YXN0b3JlIGl0LCBpdCBkb2Vzbid0IG1hdHRlciB0aGF0IGEgbm9kZQ0K PiA+Pj4+PiBpcyBtYXJrZWQgd2l0aCBpMnJzOmVwaGVtZXJhbCB0cnVlLg0KPiA+Pj4+IA0KPiA+ Pj4+IEkgYW0gbm90IGNvbnZpbmNlZCBhdCBhbGwgYWJvdXQgdGhpcyBvbmUuIElmIHRoZSBzZXJ2 ZXIgYWR2ZXJ0aXNlcyB0aGUNCj4gPj4+PiAiaTJycyIgY2FwYWJpbGl0eSBhbmQgbW9kdWxlcyB0 aGF0IHVzZSAiaTJyczplcGhlbWVyYWwiIGV4dGVuc2lvbiwNCj4gPj4+PiB0aGVuDQo+ID4+Pj4g YSBub3JtYWwgTkVUQ09ORi9SRVNUQ09ORiBjbGllbnQgY2FuIGlnbm9yZSBib3RoIChSRkMgNjI0 MTogIkVhY2ggcGVlcg0KPiA+Pj4+IFsuLi5dIE1VU1QgaWdub3JlIGFueSBjYXBhYmlsaXR5IHJl Y2VpdmVkIGZyb20gdGhlIG90aGVyIHBlZXIgdGhhdCBpdA0KPiA+Pj4+IGRvZXMgbm90IHJlcXVp cmUgb3IgZG9lcyBub3QgdW5kZXJzdGFuZC4iKS4gQnV0aCB3aGF0IHRoZW46IGNhbiB0aGUNCj4g Pj4+PiBjbGllbnQgdHJlYXQgbm9kZXMgdGFnZ2VkIHdpdGggImkycnM6ZXBoZW1lcmFsIiBqdXN0 IGFzIHN0YW5kYXJkDQo+ID4+Pj4gbm9kZXM/DQo+ID4+PiANCj4gPj4+IE15IGlkZWEgaGFzIGJl ZW4gdGhhdCBpdCB3b3VsZCBiZSB1c2VkIGFzOg0KPiA+Pj4gDQo+ID4+PiAgbGVhZiBteS1lcGhl bWVyYWwtbGVhZiB7DQo+ID4+PiAgICAgY29uZmlnIGZhbHNlOw0KPiA+Pj4gICAgIGkycnM6ZXBo ZW1lcmFsIHRydWU7DQo+ID4+PiAgICAgLi4uDQo+ID4+PiAgfQ0KPiA+Pj4gDQo+ID4+PiB3aGlj aCBtZWFucyB0aGF0IGlmIHRoZSBjbGllbnQgZG9lc24ndCBrbm93IHdoYXQgdG8gZG8gd2l0aA0K PiA+Pj4gImkycnM6ZXBoZW1lcmFsIiwgaXQgd2lsbCBpZ25vcmUgaXQsIGFzIGp1c3Qgc2VlIHRo aXMgYXMgYSBub3JtYWwNCj4gPj4+IGNvbmZpZyBmYWxzZSBub2RlIHRoYXQgY2FuIGJlIHJlYWQg d2l0aCA8Z2V0Pi4NCj4gPj4gDQo+ID4+IEl0IG9mIGNvdXJzZSBkZXBlbmRzIG9uIHRoZSBwYXJ0 aWN1bGFyIHVzYWdlIHJ1bGVzIC0gSSBhc3N1bWVkDQo+ID4+IGVwaGVtZXJhbCBkYXRhIHdvdWxk IGJlIGNvbmZpZz10cnVlLiBCdXQgZXZlbiBpbiB5b3VyIGV4YW1wbGUsIGlmDQo+ID4+IGVwaGVt ZXJhbCBkYXRhIGFyZSBpbiBhIHNwZWNpYWwgZGF0YXN0b3JlLCB0aGV5IG1heSBub3QgYmUgcmV0 dXJuZWQNCj4gPj4gd2l0aCA8Z2V0Piwgd2hpY2ggY2FuIGFnYWluIHZpb2xhdGUgdGhlIHNjaGVt YS4NCj4gPiANCj4gPiBSaWdodCwgdGhpcyBpZGVhIGFzc3VtZXMgdGhhdCBlcGhlbWVyYWwgZGF0 YSAqaXMqIHJldHVybmVkIGJ5IDxnZXQ+Lg0KPiA+IA0KPiA+PiBJIHRoaW5rIGFyYml0cmFyeSBl eHRlbnNpb25zIGFyZSBPSyBpZiB0aGV5IGFyZSB1c2VkIGluIGEgY29udHJvbGxlZA0KPiA+PiBl bnZpcm9ubWVudCwgZS5nLiBpbiBzaW5nbGUgdmVuZG9y4oCZcyBzZXJ2ZXIgYW5kIGNsaWVudCBz b2Z0d2FyZSwgYnV0DQo+ID4+IGluIGdlbmVyYWwgdGhleSBjYW4gYnJlYWsgaW50ZXJvcGVyYWJp bGl0eSB1bmxlc3MgdGhleSBhcmUgYWNjb21wYW5pZWQNCj4gPj4gd2l0aCBhIGJpZGlyZWN0aW9u YWwgY2xpZW50LXNlcnZlciBuZWdvdGlhdGlvbiBtZWNoYW5pc20uDQo+ID4gDQo+ID4gSSBhZ3Jl ZSB0aGF0IGl0IGlzIGltcG9ydGFudCB0byB0aGluayBhYm91dCBwcm90b2NvbCBuZWdvdGlhdGlv bg0KPiA+IG1lY2hhbmlzbXMsIGNsaWVudCBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eSBldGMuIHdo ZW4gZGVmaW5pbmcNCj4gPiBleHRlbnNpb25zLg0KPiANCj4gQnV0IGV2ZW4gdGhlbiBpdCBtaWdo dCBiZSBkaWZmaWN1bHQgdG8gaGFuZGxlIHNpdHVhdGlvbnMgd2hlcmUgb25lDQo+IGNsaWVudCBz dXBwb3J0cyBhbiBleHRlbnNpb24gd2hpbGUgYW5vdGhlciBkb2VzbuKAmXQgLSB0aGUgc2VydmVy DQo+IHNpbXBseSBtYXkgbm90IGJlIGFibGUgdG8gYmVoYXZlIHNpbXVsdGFuZW91c2x5IGluIHR3 byBkaWZmZXJlbnQNCj4gd2F5cy4NCg0KQnV0IGp1c3QgYi9jIHRoZXJlIGFyZSAqc29tZSogcG90 ZW50aWFsIGV4dGVuc2lvbiB0aGF0IHdvdWxkIGhhdmUNCnByb2JsZW1zLCBkb2VzIG5vdCBtZWFu IHRoYXQgKmFsbCogZXh0ZW5zaW9ucyBzaG91bGQgYmUgYmFubmVkLg0KDQo+IFRoYXTigJlzIHdo eSBJIHRoaW5rIHRoZSBvbmx5IG9wdGlvbiB0aGF04oCZcyByZWFsbHkgc2FmZSBmb3Igbm93DQo+ IGlzDQo+IA0KPiAqKiBTb2x1dGlvbiBZeHgtMDMNCj4gDQo+ICAgTWFrZSBleHRlbnNpb25zIG9w dGlvbmFsLiBUaGlzIG1lYW5zIHRoYXQgZXh0ZW5zaW9ucyB3b24ndCBiZQ0KPiAgIGFsbG93ZWQg dG8gY2hhbmdlIFlBTkcgbGFuZ3VhZ2UsIE5FVENPTkYgcHJvdG9jb2wsIGFuZCB2YWxpZGl0eSBv Zg0KPiAgIGRhdGFzdG9yZXMgYW5kIHByb3RvY29sIG1lc3NhZ2VzLg0KDQpJIHRoaW5rIHdlIG5l ZWQgZXhwbGljaXQgdGV4dCBpbiBvcmRlciB0byBiZSBhYmxlIHRvIGFncmVlIG9uIGENCnNvbHV0 aW9uLg0KDQoNCi9tYXJ0aW4NCg== From nobody Thu Aug 20 05:09:47 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD4E1A92B4 for ; Thu, 20 Aug 2015 05:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmlUmt_xq6Ru for ; Thu, 20 Aug 2015 05:09:44 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9301A1B7C for ; Thu, 20 Aug 2015 05:09:43 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 44FC41CC0058; Thu, 20 Aug 2015 14:09:41 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20150820.132857.1812838545863613387.mbj@tail-f.com> References: <5E452E16-4728-4A74-AD74-65404E6DA98C@nic.cz> <20150820.131242.583799169537333295.mbj@tail-f.com> <3B335831-4C79-4EB4-AC62-EA21D50E5928@nic.cz> <20150820.132857.1812838545863613387.mbj@tail-f.com> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Thu, 20 Aug 2015 14:09:41 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] extensions and conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 12:09:46 -0000 Martin Bjorklund writes: > Ladislav Lhotka wrote: >>=20 >> > On 20 Aug 2015, at 13:12, Martin Bjorklund wrote: >> >=20 >> > Ladislav Lhotka wrote: >> >>=20 >> >>> On 20 Aug 2015, at 12:37, Martin Bjorklund wrote: >> >>>=20 >> >>> Ladislav Lhotka wrote: >> >>>> Martin Bjorklund writes: >> >>>>=20 >> >>>>> Andy Bierman wrote: >> >>>>>> On Wed, Aug 19, 2015 at 5:49 AM, Martin Bjorklund >> >>>>>> wrote: >> >>>>>>=20 >> >>>>>>> Hi, >> >>>>>>>=20 >> >>>>>>> [joining this discussion a bit late] >> >>>>>>>=20 >> >>>>>>> Ladislav Lhotka wrote: >> >>>>>>>>=20 >> >>>>>>>>> On 10 Aug 2015, at 18:46, Andy Bierman wr= ote: >> >>>>>>>>>=20 >> >>>>>>>>>=20 >> >>>>>>>>>=20 >> >>>>>>>>> On Mon, Aug 10, 2015 at 9:37 AM, Ladislav Lhotka >> >>>>>>>>> wrote: >> >>>>>>>>>=20 >> >>>>>>>>>> On 10 Aug 2015, at 17:32, Andy Bierman w= rote: >> >>>>>>>>>>=20 >> >>>>>>>>>>=20 >> >>>>>>>>>>=20 >> >>>>>>>>>> On Mon, Aug 10, 2015 at 4:24 AM, Ladislav Lhotka >> >>>>>>>>>> wrote: >> >>>>>>>>>>=20 >> >>>>>>>>>>> On 10 Aug 2015, at 12:17, Andy Bierman = wrote: >> >>>>>>>>>>>=20 >> >>>>>>>>>>> Hi, >> >>>>>>>>>>>=20 >> >>>>>>>>>>> I am strongly against changing the contract on extensions. >> >>>>>>>>>>> They MAY be ignored by any YANG tool. Period. >> >>>>>>>>>>> That means they are far from mandatory. >> >>>>>>>>>>> They are little more than a keyword and a description clause. >> >>>>>>>>>>=20 >> >>>>>>>>>> So do you prefer my proposed solution -02 or -03? >> >>>>>>>>>>=20 >> >>>>>>>>>> ** Solution Yxx-03 >> >>>>>>>>>>=20 >> >>>>>>>>>> Make extensions optional. This means that extensions won't be >> >>>>>>>>>> allowed to change YANG language, NETCONF protocol, and valid= ity of >> >>>>>>>>>> datastores and protocol messages. >> >>>>>>>>>>=20 >> >>>>>>>>>>=20 >> >>>>>>>>>> This is how we use extensions to tag YANG data models >> >>>>>>>>>> to drive automation tools. >> >>>>>>>>>=20 >> >>>>>>>>> But that means, for example, that annotations cannot be define= d via an >> >>>>>>>>> extension statement as in draft-ietf-netmod-yang-metadata. >> >>>>>>>>>=20 >> >>>>>>>>>=20 >> >>>>>>>>>=20 >> >>>>>>>>> Which means these statements should be real instead of extensi= ons. >> >>>>>>>>> If the statements are defining data that is exchanged between >> >>>>>>>>> peers in a standard protocol, then YANG extensions are not >> >>>>>>>>> appropriate. >> >>>>>>>>=20 >> >>>>>>>> I agree, and -03 is my preferred solution, too. >> >>>>>>>=20 >> >>>>>>> I strongly disagree. IMO the IETF usage of extensions so far (N= ACM, >> >>>>>>> annotations) works well (in the case of NACM proven by multiple >> >>>>>>> independent implementations), and follows how extensions were in= tended >> >>>>>>> to be used, and obviously, how the WG has understood them up unt= il >> >>>>>>> now. >> >>>>>>>=20 >> >>>>>>> If the sentence: >> >>>>>>>=20 >> >>>>>>> If a YANG compiler does not support a particular extension, whi= ch >> >>>>>>> appears in a YANG module as an unknown-statement (see Section 1= 2), >> >>>>>>> the entire unknown-statement MAY be ignored by the compiler. >> >>>>>>>=20 >> >>>>>>> in 6020 can be interpreted to mean that an occurance of an exten= sion >> >>>>>>> is non-normative, we should fix it so that it matches what was >> >>>>>>> intended and how it is used. >> >>>>>>>=20 >> >>>>>>> Juergen suggested this replacement text, which I support. Maybe= it >> >>>>>>> can be improved even more. >> >>>>>>>=20 >> >>>>>>> If a YANG parser does not support a particular extension, w= hich >> >>>>>>> appears in a YANG module as an unknown-statement (see Secti= on 13), >> >>>>>>> the entire unknown-statement MAY be ignored by the parser. = Note >> >>>>>>> that even in this case the semantics associated with the ex= tension >> >>>>>>> still apply (as if they were part of a description statemen= t). >> >>>>>>>=20 >> >>>>>>>=20 >> >>>>>>=20 >> >>>>>> I strongly disagree with this change. >> >>>>>> This would mean that every tool is required to support the >> >>>>>> semantics of every extension ever defined. >> >>>>>=20 >> >>>>> No. It means that if a server advertises module that uses some >> >>>>> extension to define some behaviour, the server supports that >> >>>>> behavior. Just as we expect a server to support the text in >> >>>>> description statements. >> >>>>=20 >> >>>> This is unclear both from the current text and from Juergen's >> >>>> proposal. Maybe I am a nitpicker but assume that either (i) server >> >>>> implementation is completely generated from the data model, or (ii) >> >>>> the >> >>>> parser in question is simply in the implementor's head. Then I don't >> >>>> know how the server can implement the semantics of an extension if = the >> >>>> extension is removed while YANG modules containing it are being >> >>>> parsed. >> >>>>=20 >> >>>> A text like "a client MAY ignore an extension that it doesn't >> >>>> understand" would be clearer but I don't think it is acceptable if = the >> >>>> extension changes >> >>>>=20 >> >>>> - semantics of YANG, >> >>>=20 >> >>> Agreed. >> >>>=20 >> >>>> - semantics of the protocol, >> >>>=20 >> >>> Maybe... >> >>>=20 >> >>>> - schema of the data model (as annotations do). >> >>>=20 >> >>> I think it is ok to define an annotation with an extension (as the >> >>> draft does). When designing a feature that is going to use an >> >>> annotation it is important to keep in mind that not all clients will >> >>> understand the annotation. So e.g. if the new feature is a "comment= ", >> >>> the server might just blindly return them to all clients, but in the >> >>=20 >> >> For a client that doesn=E2=80=99t understand the annotation (or annot= ations in >> >> general) it is just extra junk that=E2=80=99s not in the data model. = This is >> >> no different from a new data node type defined through an extension - >> >> in fact, in JSON encoding annotations are just special object >> >> members. A prudent client may consider such data invalid. >> >>=20 >> >>> case of "inactive", the server must not send these attributes to a >> >>> client that doesn't ask for them. (You may argue that even for >> >>> comments the client should ask for them, but that is besides the >> >>> point). >> >>=20 >> >> IMO =E2=80=9Cinactive=E2=80=9D data change the NETCONF/RESTCONF proto= col. If a client >> >> doesn=E2=80=99t see inactive data, it may think it is OK to write its= own >> >> content to that place, which probably shouldn=E2=80=99t be allowed. >> >>=20 >> >>>=20 >> >>> The bottom line is that you have to be careful when you define a new >> >>> extension statement. >> >>>=20 >> >>>>> For example, the nacm: extensions do not apply unless ietf-netconf= -acm >> >>>>> is advertised (and nacm is enabled). I expect most extensions to = work >> >>>>> this way. Another example is if we actually defined i2rs:ephemera= l; >> >>>>> this would have no effect unless the "i2rs" capability (whatever t= hat >> >>>>> is) is also advertised. >> >>>>=20 >> >>>> The nacm: extensions are probably OK because they only give some >> >>>> additional info about the server behaviour that is independent of >> >>>> client's support. If the client ignores them, then it may be just >> >>>> wondering why it cannot read or write some data. >> >>>=20 >> >>> Right. >> >>>=20 >> >>>>> The text also means that it is perfectly ok for a client to ignore= the >> >>>>> extension if it doesn't understand it. For example, if the client= has >> >>>>> no idea what the ephemeral datastore it, it doesn't matter that a = node >> >>>>> is marked with i2rs:ephemeral true. >> >>>>=20 >> >>>> I am not convinced at all about this one. If the server advertises = the >> >>>> "i2rs" capability and modules that use "i2rs:ephemeral" extension, >> >>>> then >> >>>> a normal NETCONF/RESTCONF client can ignore both (RFC 6241: "Each p= eer >> >>>> [...] MUST ignore any capability received from the other peer that = it >> >>>> does not require or does not understand."). Buth what then: can the >> >>>> client treat nodes tagged with "i2rs:ephemeral" just as standard >> >>>> nodes? >> >>>=20 >> >>> My idea has been that it would be used as: >> >>>=20 >> >>> leaf my-ephemeral-leaf { >> >>> config false; >> >>> i2rs:ephemeral true; >> >>> ... >> >>> } >> >>>=20 >> >>> which means that if the client doesn't know what to do with >> >>> "i2rs:ephemeral", it will ignore it, as just see this as a normal >> >>> config false node that can be read with . >> >>=20 >> >> It of course depends on the particular usage rules - I assumed >> >> ephemeral data would be config=3Dtrue. But even in your example, if >> >> ephemeral data are in a special datastore, they may not be returned >> >> with , which can again violate the schema. >> >=20 >> > Right, this idea assumes that ephemeral data *is* returned by . >> >=20 >> >> I think arbitrary extensions are OK if they are used in a controlled >> >> environment, e.g. in single vendor=E2=80=99s server and client softwa= re, but >> >> in general they can break interoperability unless they are accompanied >> >> with a bidirectional client-server negotiation mechanism. >> >=20 >> > I agree that it is important to think about protocol negotiation >> > mechanisms, client backwards compatibility etc. when defining >> > extensions. >>=20 >> But even then it might be difficult to handle situations where one >> client supports an extension while another doesn=E2=80=99t - the server >> simply may not be able to behave simultaneously in two different >> ways. > > But just b/c there are *some* potential extension that would have > problems, does not mean that *all* extensions should be banned. My concern is that vendors might misuse extensions for creating silos - we all remember browser wars, right? And in the particular case of "annotation", I am not sure whether it is really OK for a server to advertise an annotation in a module and then start using it without client's consent. > >> That=E2=80=99s why I think the only option that=E2=80=99s really safe fo= r now >> is >>=20 >> ** Solution Yxx-03 >>=20 >> Make extensions optional. This means that extensions won't be >> allowed to change YANG language, NETCONF protocol, and validity of >> datastores and protocol messages. > > I think we need explicit text in order to be able to agree on a > solution. Section 6.3.1: OLD If a YANG compiler does not support a particular extension, which appears in a YANG module as an unknown-statement (see Section 12), the entire unknown-statement MAY be ignored by the compiler. NEW Extensions MUST NOT affect the following aspects: o syntax and semantics of YANG language, o management protocols such as NETCONF or RESTCONF, o validity of datastores and protocol messages with respect to the data model. A server advertising modules that define and use an extension MUST adhere to the extension's semantics as specified in its definition. However, clients MAY ignore any or all extensions appearing in modules advertised by the server. By the way, due to the adopted solution Y49-04, the second paragraph in sec. 6.3.1 should also be removed. Lada > > > /martin --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Aug 20 05:34:36 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A0D01ACDEF; Thu, 20 Aug 2015 05:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H_ylaBrRYKUc; Thu, 20 Aug 2015 05:34:32 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88E211ACDEE; Thu, 20 Aug 2015 05:34:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1440074013; bh=6YfQkE62hCHhIimRiuOYsR4JMtEllmgMIPUE52p52qM=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=alAdYcRYvm4pquWvZ2JutZ44Ijsl86f8eeFuTtf+jPTS8Ub+tuL4ufTREFd0KLy54 cVk8Is1MFgcO2cXqgQmlAjq/Fn+C+swWwoJMQ/XwPG97a6sW9v/HYckWC+ZDMZGbow Sx8fK+PznrLebYGQeZ5sDVjMNP3YEoCRnEnTDPYY= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Nadeau Thomas In-Reply-To: <55D53BEF.2060009@labn.net> Date: Thu, 20 Aug 2015 08:34:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <053F2D30-8DC2-4389-8A24-19E75987C616@lucidvision.com> References: <55D3DDFC.2080107@labn.net> <29B312B3-287D-4E61-8447-CFDF8F6C1734@lucidvision.com> <55D53BEF.2060009@labn.net> To: Berger Lou X-Mailer: Apple Mail (2.2104) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-ShareWhite: 50.255.148.181 X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=17 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181 X-IP-stats: Notspam Incoming Last 0, First 97, in=943, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: Cc: Routing WG , netmod WG , draft-rtgyangdt-rtgwg-device-model@ietf.org Subject: Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 12:34:35 -0000 > On Aug 19, 2015:10:31 PM, at 10:31 PM, Lou Berger = wrote: >=20 > On 08/19/2015 08:48 AM, Nadeau Thomas wrote: >>=20 >>> On Aug 18, 2015:9:38 PM, at 9:38 PM, Lou Berger = wrote: >>>=20 >>> [Adding authors and RTG WG.] >>>=20 >>> Hi Andy, >>> I'm not sure who you are looking to hear from as you addressed = this >>> mail to the netmod list. I'm happy to give my opinion as it seems = you >>> might have been aiming this at the draft authors. (but then again >>> perhaps not.)=20 >>>=20 >>> On 8/18/2015 8:01 PM, Andy Bierman wrote: >>>> Hi, >>>>=20 >>>> I assume this draft is what we should be reviewing and not >>>> the obsolete openconfig draft? >>>=20 >>> My personal view / hope is that the openconfig draft will be revised = to >>> cover requirements >>=20 >> Can you be specific about which requirements you feel are not = covered ? >>=20 >> =97Tom >>=20 >=20 > I wasn't commenting on what's covered/not covered. I was saying that = I > don't think the openconfig draft should disappear, rather it should be > revised to just focus on requirements. >=20 > Lou Fair enough. =97Tom >=20 >>=20 >>> while the DT draft leads to an agreed upon approach >>> to addressing those requirements. Again, just stating my view, not = the >>> view of the DT, co-authors or OC draft authors. >>>=20 >>>>=20 >>>>=20 >>>> https://tools.ietf.org/html/draft-rtgyangdt-rtgwg-device-model-00 >>>>=20 >>>>=20 >>>> Q1) scope >>>>=20 >>>>=20 >>>> sec 2: >>>>=20 >>>> The model organization can itself be thought of as a "meta-model", >>>> in that it describes the relationships between individual models. = We >>>> choose to represent it also as simple YANG model consisting of = lists >>>> and containers to serve as anchor points for the corresponding >>>> individual models. >>>>=20 >>>> As shown below, our model is rooted at a "device", which = represents a >>>> network router, switch, or similar network element. =20 >>>>=20 >>>>=20 >>>> Why is this a meta-model? >>> because the aim to to show how other models inter-relate rather than >>> define the details of all models. As stated in the intro: >>>=20 >>> This document aims to provide an extensible structure that can be >>> used to tie together other models. It allows for existing, = emerging, >>> and future models. The overall structure can be constructed using >>> YANG augmentation and imports. >>>=20 >>>=20 >>>> It looks like a real YANG data model where ad-hoc classification is >>>> being done >>>> using container names. >>>=20 >>> Sure, we're using YANG, or at least trying, to document our = proposal.=20 >>> Do you think there's a better way to formally document the work? >>>=20 >>>>=20 >>>> If vendors augment this tree with their own ad-hoc hierarchy, then = how >>>> is this >>>> any better than what we have now? >>>>=20 >>> This goes to requirements which is really in the scope of >>> draft-openconfig-netmod-model-structure. =46rom my perspective it = comes >>> down to how much information is needed from an actual device in = order to >>> come up with its yang-based configuration, and the principle that = there >>> is benefit in this being minimized. For example, consider the case >>> where a config is generated before a specific device is fielded or >>> perhaps even purchased/selected. But again, this more of a = requirements >>> discussion. >>>=20 >>>> What is the scope of this work? >>> see slide 7 of >>> https://www.ietf.org/proceedings/93/slides/slides-93-rtgwg-3.pdf >>>=20 >>>> It appears to be only for "routers switches or similar network = elements". >>>>=20 >>>> =46rom the slide: >>> =46rom DT charter: An overall architecture for >>> =93the protocols and functionality contained inside the Routing = Area=94 >>>=20 >>>> The hierarchy seems quite router-centric. >>> It is intended to be network device centric, routers, switches, >>> firewalls, etc. >>>=20 >>>> Is the expectation that all YANG-based devices will use this >>>> data hierarchy, or only some devices? >>> The proposal is to provide a framework for any device that supports = a >>> protocol or other mechanism defined within the routing area. (Or at >>> least that's our understanding of what we were asked to do.) >>>=20 >>>>=20 >>>> Is the expectation that all YANG modules will use this >>>> data hierarchy, or only some modules?=20 >>>=20 >>> I personally think there will be siblings to /device, e.g., /service = - >>> but this is beyond the scope of this draft. >>>=20 >>>> Is it just >>>> for IETF routing modules or more than that? >>>>=20 >>> I think this is the same question and answer as above. >>>=20 >>>> Q2) interfaces >>>>=20 >>>> The interface model is taken from [RFC7223 = ] and includes possible >>>> technology-specific augmentations using example technologies = defined >>>> in [RFC7277 ]. >>>> +--rw interfaces >>>> | +--rw interface* [name] >>>> | +--rw name string >>>> | +--rw bind-network-element-id? uint8 >>>> | +--rw ethernet >>>> | | +--rw bind-networking-instance-name? string >>>> | | +--rw aggregates >>>> | | +--rw rstp >>>> | | +--rw lldp >>>> | | +--rw ptp >>>> | +--rw vlans >>>> | +--rw tunnels >>>> | +--rw ipv4 >>>> | | +--rw bind-networking-instance-name? string >>>> | | +--rw arp >>>> | | +--rw icmp >>>> | | +--rw vrrp >>>> | | +--rw dhcp-client >>>> | +--rw ipv6 >>>> | +--rw bind-networking-instance-name? string >>>> | +--rw vrrp >>>> | +--rw icmpv6 >>>> | +--rw nd >>>> | +--rw dhcpv6-client >>>>=20 >>>>=20 >>>> Actually the interface model is quite different than the one in RFC = 7223. >>>> Seems rather ethernet-centric. I notice the "type" leaf was = removed, >>>> along with everything else. Is the plan to toss out RFC 7223, >>>> recharter the interfaces work, and start over? >>>>=20 >>>=20 >>> So this may be our/my inexperience at play here. I didn't think it >>> appropriate for a document that is augmenting an existing model to >>> redefine the current model - I actually thought this was part of the >>> power of YANG augmentation. Are you saying we should have included = the >>> whole 7223 model to augment it, or something different? >>>=20 >>> Also not the text says: >>> ... possible technology-specific augmentations using example >>> technologies .. >>> and >>>=20 >>> The interfaces container includes a number of commonly used >>> components as examples: >>>=20 >>>> Q3) virtual devices >>>>=20 >>>> The model supports the potentially independent system management >>>> functions and configuration per logical network element. This >>>> permits, for example, different users to manage either the whole >>>> device or just the associated logical network element.=20 >>>>=20 >>>> Sec 2.2.1 shows the system management tree but it is wrong. >>>=20 >>> Yes, good catch of a cut-and-past bug. thankfully it is correct both >>> immediately before in the section intro and the details >>>=20 >>>> The following tree is what the YANG model defines: >>>> +--rw device >>>> +--rw logical-network-elements >>>> -rw logical-network-element* [network-element-id] >>>> +--rw network-element-id uint8 >>>> +--rw network-element-name? string >>>> +--rw default-networking-instance-name? string >>>> +--rw system-management >>>> | +--rw device-view? boolean >>>> | +--rw syslog >>>> | +--rw dns >>>> | +--rw ntp >>>> | +--rw statistics-collection >>>> | +--rw ssh >>>> | +--rw tacacs >>>> | +--rw snmp >>>> | +--rw netconf >>>> What about devices that do not have logical network elements? >>> It would have only a single network-element-id >>>=20 >>>> This hierarchy may be appropriate for very large routers >>>> but nothing else. >>> The intent is to cover all implementations independent of vendors. = We >>> had a good range of view points both in the DT and in the RTGWG >>> discussion. Not saying there was full agreement, just that we have = a >>> proposed starting point. >>>=20 >>>> How can this tree represent both the physical view and the virtual = view? >>> Are you referring to section 2.3? If so, I think we all agree (and = said >>> as much in Prague) that this section could be clearer. We/I tried = to >>> explain it in the Prague slide 25 (for this you may want to see the >>> animation in >>> https://www.ietf.org/proceedings/93/slides/slides-93-rtgwg-3.pptx) >>>=20 >>> Basically the amount of information provided depends on the >>> logical-network-element context used to access this information. So = if >>> a model is "retrieved" via an IP address associated with a >>> network-element-id with device-view=3Dtrue (e.g., the left side of = slide >>> 25), then the device's full view is provided. And when a model is >>> "retrieved" via an IP address associated with a network-element-id = with >>> device-view=3Dfalse (e.g., the ride side of slide 25, either color) = only >>> information related to the network-element-id is provided. >>>=20 >>>> It seems to assume this is the "root user physical view". >>>> Please explain how device-type=3DVIRTUAL is used. >>>=20 >>> This is a bit different and hasn't been a major point of discussion = in >>> the WG -- we brought this over from the openconfig draft. I read = this >>> as being pretty uninteresting and simply set based on if the device = is >>> running on dedicated special purpose h/w (e.g, a classic >>> "name-your-vendor" router) or as a VM (aka NFV). I'll defer to the = OC >>> or other DT folks if their opinion differs. >>>=20 >>> Thanks for the comments/discussion! >>>=20 >>> Lou >>>=20 >>>> Andy >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>=20 >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >>=20 >=20 From nobody Thu Aug 20 06:26:13 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 593091ACE5B for ; Thu, 20 Aug 2015 06:26:13 -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_64=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 6n_1ekpWogvE for ; Thu, 20 Aug 2015 06:26:06 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 14A001ACE54 for ; Thu, 20 Aug 2015 06:26:06 -0700 (PDT) Received: from localhost (unknown [173.38.220.43]) by mail.tail-f.com (Postfix) with ESMTPSA id 120A51AE035B; Thu, 20 Aug 2015 15:26:04 +0200 (CEST) Date: Thu, 20 Aug 2015 15:26:03 +0200 (CEST) Message-Id: <20150820.152603.242849288817455571.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <3B335831-4C79-4EB4-AC62-EA21D50E5928@nic.cz> <20150820.132857.1812838545863613387.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] extensions and conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 13:26:13 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3JrbHVu ZCA8bWJqQHRhaWwtZi5jb20+IHdyaXRlczoNCj4gDQo+ID4gTGFkaXNsYXYgTGhvdGthIDxsaG90 a2FAbmljLmN6PiB3cm90ZToNCj4gPj4gDQo+ID4+ID4gT24gMjAgQXVnIDIwMTUsIGF0IDEzOjEy LCBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4gd3JvdGU6DQo+ID4+ID4gDQo+ID4+ ID4gTGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gPj4gPj4gDQo+ID4+ ID4+PiBPbiAyMCBBdWcgMjAxNSwgYXQgMTI6MzcsIE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWls LWYuY29tPiB3cm90ZToNCj4gPj4gPj4+IA0KPiA+PiA+Pj4gTGFkaXNsYXYgTGhvdGthIDxsaG90 a2FAbmljLmN6PiB3cm90ZToNCj4gPj4gPj4+PiBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1m LmNvbT4gd3JpdGVzOg0KPiA+PiA+Pj4+IA0KPiA+PiA+Pj4+PiBBbmR5IEJpZXJtYW4gPGFuZHlA eXVtYXdvcmtzLmNvbT4gd3JvdGU6DQo+ID4+ID4+Pj4+PiBPbiBXZWQsIEF1ZyAxOSwgMjAxNSBh dCA1OjQ5IEFNLCBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4NCj4gPj4gPj4+Pj4+ IHdyb3RlOg0KPiA+PiA+Pj4+Pj4gDQo+ID4+ID4+Pj4+Pj4gSGksDQo+ID4+ID4+Pj4+Pj4gDQo+ ID4+ID4+Pj4+Pj4gW2pvaW5pbmcgdGhpcyBkaXNjdXNzaW9uIGEgYml0IGxhdGVdDQo+ID4+ID4+ Pj4+Pj4gDQo+ID4+ID4+Pj4+Pj4gTGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90 ZToNCj4gPj4gPj4+Pj4+Pj4gDQo+ID4+ID4+Pj4+Pj4+PiBPbiAxMCBBdWcgMjAxNSwgYXQgMTg6 NDYsIEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPiB3cm90ZToNCj4gPj4gPj4+Pj4+ Pj4+IA0KPiA+PiA+Pj4+Pj4+Pj4gDQo+ID4+ID4+Pj4+Pj4+PiANCj4gPj4gPj4+Pj4+Pj4+IE9u IE1vbiwgQXVnIDEwLCAyMDE1IGF0IDk6MzcgQU0sIExhZGlzbGF2IExob3RrYSA8bGhvdGthQG5p Yy5jej4NCj4gPj4gPj4+Pj4+Pj4+IHdyb3RlOg0KPiA+PiA+Pj4+Pj4+Pj4gDQo+ID4+ID4+Pj4+ Pj4+Pj4gT24gMTAgQXVnIDIwMTUsIGF0IDE3OjMyLCBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdv cmtzLmNvbT4gd3JvdGU6DQo+ID4+ID4+Pj4+Pj4+Pj4gDQo+ID4+ID4+Pj4+Pj4+Pj4gDQo+ID4+ ID4+Pj4+Pj4+Pj4gDQo+ID4+ID4+Pj4+Pj4+Pj4gT24gTW9uLCBBdWcgMTAsIDIwMTUgYXQgNDoy NCBBTSwgTGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6Pg0KPiA+PiA+Pj4+Pj4+Pj4+IHdy b3RlOg0KPiA+PiA+Pj4+Pj4+Pj4+IA0KPiA+PiA+Pj4+Pj4+Pj4+PiBPbiAxMCBBdWcgMjAxNSwg YXQgMTI6MTcsIEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPiB3cm90ZToNCj4gPj4g Pj4+Pj4+Pj4+Pj4gDQo+ID4+ID4+Pj4+Pj4+Pj4+IEhpLA0KPiA+PiA+Pj4+Pj4+Pj4+PiANCj4g Pj4gPj4+Pj4+Pj4+Pj4gSSBhbSBzdHJvbmdseSBhZ2FpbnN0IGNoYW5naW5nIHRoZSBjb250cmFj dCBvbiBleHRlbnNpb25zLg0KPiA+PiA+Pj4+Pj4+Pj4+PiBUaGV5IE1BWSBiZSBpZ25vcmVkIGJ5 IGFueSBZQU5HIHRvb2wuIFBlcmlvZC4NCj4gPj4gPj4+Pj4+Pj4+Pj4gVGhhdCBtZWFucyB0aGV5 IGFyZSBmYXIgZnJvbSBtYW5kYXRvcnkuDQo+ID4+ID4+Pj4+Pj4+Pj4+IFRoZXkgYXJlIGxpdHRs ZSBtb3JlIHRoYW4gYSBrZXl3b3JkIGFuZCBhIGRlc2NyaXB0aW9uIGNsYXVzZS4NCj4gPj4gPj4+ Pj4+Pj4+PiANCj4gPj4gPj4+Pj4+Pj4+PiBTbyBkbyB5b3UgcHJlZmVyIG15IHByb3Bvc2VkIHNv bHV0aW9uIC0wMiBvciAtMDM/DQo+ID4+ID4+Pj4+Pj4+Pj4gDQo+ID4+ID4+Pj4+Pj4+Pj4gKiog U29sdXRpb24gWXh4LTAzDQo+ID4+ID4+Pj4+Pj4+Pj4gDQo+ID4+ID4+Pj4+Pj4+Pj4gIE1ha2Ug ZXh0ZW5zaW9ucyBvcHRpb25hbC4gVGhpcyBtZWFucyB0aGF0IGV4dGVuc2lvbnMgd29uJ3QgYmUN Cj4gPj4gPj4+Pj4+Pj4+PiAgYWxsb3dlZCB0byBjaGFuZ2UgWUFORyBsYW5ndWFnZSwgTkVUQ09O RiBwcm90b2NvbCwgYW5kIHZhbGlkaXR5IG9mDQo+ID4+ID4+Pj4+Pj4+Pj4gIGRhdGFzdG9yZXMg YW5kIHByb3RvY29sIG1lc3NhZ2VzLg0KPiA+PiA+Pj4+Pj4+Pj4+IA0KPiA+PiA+Pj4+Pj4+Pj4+ IA0KPiA+PiA+Pj4+Pj4+Pj4+IFRoaXMgaXMgaG93IHdlIHVzZSBleHRlbnNpb25zIHRvIHRhZyBZ QU5HIGRhdGEgbW9kZWxzDQo+ID4+ID4+Pj4+Pj4+Pj4gdG8gZHJpdmUgYXV0b21hdGlvbiB0b29s cy4NCj4gPj4gPj4+Pj4+Pj4+IA0KPiA+PiA+Pj4+Pj4+Pj4gQnV0IHRoYXQgbWVhbnMsIGZvciBl eGFtcGxlLCB0aGF0IGFubm90YXRpb25zIGNhbm5vdCBiZSBkZWZpbmVkIHZpYSBhbg0KPiA+PiA+ Pj4+Pj4+Pj4gZXh0ZW5zaW9uIHN0YXRlbWVudCBhcyBpbiBkcmFmdC1pZXRmLW5ldG1vZC15YW5n LW1ldGFkYXRhLg0KPiA+PiA+Pj4+Pj4+Pj4gDQo+ID4+ID4+Pj4+Pj4+PiANCj4gPj4gPj4+Pj4+ Pj4+IA0KPiA+PiA+Pj4+Pj4+Pj4gV2hpY2ggbWVhbnMgdGhlc2Ugc3RhdGVtZW50cyBzaG91bGQg YmUgcmVhbCBpbnN0ZWFkIG9mIGV4dGVuc2lvbnMuDQo+ID4+ID4+Pj4+Pj4+PiBJZiB0aGUgc3Rh dGVtZW50cyBhcmUgZGVmaW5pbmcgZGF0YSB0aGF0IGlzIGV4Y2hhbmdlZCBiZXR3ZWVuDQo+ID4+ ID4+Pj4+Pj4+PiBwZWVycyBpbiBhIHN0YW5kYXJkIHByb3RvY29sLCB0aGVuIFlBTkcgZXh0ZW5z aW9ucyBhcmUgbm90DQo+ID4+ID4+Pj4+Pj4+PiBhcHByb3ByaWF0ZS4NCj4gPj4gPj4+Pj4+Pj4g DQo+ID4+ID4+Pj4+Pj4+IEkgYWdyZWUsIGFuZCAtMDMgaXMgbXkgcHJlZmVycmVkIHNvbHV0aW9u LCB0b28uDQo+ID4+ID4+Pj4+Pj4gDQo+ID4+ID4+Pj4+Pj4gSSBzdHJvbmdseSBkaXNhZ3JlZS4g IElNTyB0aGUgSUVURiB1c2FnZSBvZiBleHRlbnNpb25zIHNvIGZhciAoTkFDTSwNCj4gPj4gPj4+ Pj4+PiBhbm5vdGF0aW9ucykgd29ya3Mgd2VsbCAoaW4gdGhlIGNhc2Ugb2YgTkFDTSBwcm92ZW4g YnkgbXVsdGlwbGUNCj4gPj4gPj4+Pj4+PiBpbmRlcGVuZGVudCBpbXBsZW1lbnRhdGlvbnMpLCBh bmQgZm9sbG93cyBob3cgZXh0ZW5zaW9ucyB3ZXJlIGludGVuZGVkDQo+ID4+ID4+Pj4+Pj4gdG8g YmUgdXNlZCwgYW5kIG9idmlvdXNseSwgaG93IHRoZSBXRyBoYXMgdW5kZXJzdG9vZCB0aGVtIHVw IHVudGlsDQo+ID4+ID4+Pj4+Pj4gbm93Lg0KPiA+PiA+Pj4+Pj4+IA0KPiA+PiA+Pj4+Pj4+IElm IHRoZSBzZW50ZW5jZToNCj4gPj4gPj4+Pj4+PiANCj4gPj4gPj4+Pj4+PiAgSWYgYSBZQU5HIGNv bXBpbGVyIGRvZXMgbm90IHN1cHBvcnQgYSBwYXJ0aWN1bGFyIGV4dGVuc2lvbiwgd2hpY2gNCj4g Pj4gPj4+Pj4+PiAgYXBwZWFycyBpbiBhIFlBTkcgbW9kdWxlIGFzIGFuIHVua25vd24tc3RhdGVt ZW50IChzZWUgU2VjdGlvbiAxMiksDQo+ID4+ID4+Pj4+Pj4gIHRoZSBlbnRpcmUgdW5rbm93bi1z dGF0ZW1lbnQgTUFZIGJlIGlnbm9yZWQgYnkgdGhlIGNvbXBpbGVyLg0KPiA+PiA+Pj4+Pj4+IA0K PiA+PiA+Pj4+Pj4+IGluIDYwMjAgY2FuIGJlIGludGVycHJldGVkIHRvIG1lYW4gdGhhdCBhbiBv Y2N1cmFuY2Ugb2YgYW4gZXh0ZW5zaW9uDQo+ID4+ID4+Pj4+Pj4gaXMgbm9uLW5vcm1hdGl2ZSwg d2Ugc2hvdWxkIGZpeCBpdCBzbyB0aGF0IGl0IG1hdGNoZXMgd2hhdCB3YXMNCj4gPj4gPj4+Pj4+ PiBpbnRlbmRlZCBhbmQgaG93IGl0IGlzIHVzZWQuDQo+ID4+ID4+Pj4+Pj4gDQo+ID4+ID4+Pj4+ Pj4gSnVlcmdlbiBzdWdnZXN0ZWQgdGhpcyByZXBsYWNlbWVudCB0ZXh0LCB3aGljaCBJIHN1cHBv cnQuICBNYXliZSBpdA0KPiA+PiA+Pj4+Pj4+IGNhbiBiZSBpbXByb3ZlZCBldmVuIG1vcmUuDQo+ ID4+ID4+Pj4+Pj4gDQo+ID4+ID4+Pj4+Pj4gICAgICBJZiBhIFlBTkcgcGFyc2VyIGRvZXMgbm90 IHN1cHBvcnQgYSBwYXJ0aWN1bGFyIGV4dGVuc2lvbiwgd2hpY2gNCj4gPj4gPj4+Pj4+PiAgICAg IGFwcGVhcnMgaW4gYSBZQU5HIG1vZHVsZSBhcyBhbiB1bmtub3duLXN0YXRlbWVudCAoc2VlIFNl Y3Rpb24gMTMpLA0KPiA+PiA+Pj4+Pj4+ICAgICAgdGhlIGVudGlyZSB1bmtub3duLXN0YXRlbWVu dCBNQVkgYmUgaWdub3JlZCBieSB0aGUgcGFyc2VyLiBOb3RlDQo+ID4+ID4+Pj4+Pj4gICAgICB0 aGF0IGV2ZW4gaW4gdGhpcyBjYXNlIHRoZSBzZW1hbnRpY3MgYXNzb2NpYXRlZCB3aXRoIHRoZSBl eHRlbnNpb24NCj4gPj4gPj4+Pj4+PiAgICAgIHN0aWxsIGFwcGx5IChhcyBpZiB0aGV5IHdlcmUg cGFydCBvZiBhIGRlc2NyaXB0aW9uIHN0YXRlbWVudCkuDQo+ID4+ID4+Pj4+Pj4gDQo+ID4+ID4+ Pj4+Pj4gDQo+ID4+ID4+Pj4+PiANCj4gPj4gPj4+Pj4+IEkgc3Ryb25nbHkgZGlzYWdyZWUgd2l0 aCB0aGlzIGNoYW5nZS4NCj4gPj4gPj4+Pj4+IFRoaXMgd291bGQgbWVhbiB0aGF0IGV2ZXJ5IHRv b2wgaXMgcmVxdWlyZWQgdG8gc3VwcG9ydCB0aGUNCj4gPj4gPj4+Pj4+IHNlbWFudGljcyBvZiBl dmVyeSBleHRlbnNpb24gZXZlciBkZWZpbmVkLg0KPiA+PiA+Pj4+PiANCj4gPj4gPj4+Pj4gTm8u ICBJdCBtZWFucyB0aGF0IGlmIGEgc2VydmVyIGFkdmVydGlzZXMgbW9kdWxlIHRoYXQgdXNlcyBz b21lDQo+ID4+ID4+Pj4+IGV4dGVuc2lvbiB0byBkZWZpbmUgc29tZSBiZWhhdmlvdXIsIHRoZSBz ZXJ2ZXIgc3VwcG9ydHMgdGhhdA0KPiA+PiA+Pj4+PiBiZWhhdmlvci4gIEp1c3QgYXMgd2UgZXhw ZWN0IGEgc2VydmVyIHRvIHN1cHBvcnQgdGhlIHRleHQgaW4NCj4gPj4gPj4+Pj4gZGVzY3JpcHRp b24gc3RhdGVtZW50cy4NCj4gPj4gPj4+PiANCj4gPj4gPj4+PiBUaGlzIGlzIHVuY2xlYXIgYm90 aCBmcm9tIHRoZSBjdXJyZW50IHRleHQgYW5kIGZyb20gSnVlcmdlbidzDQo+ID4+ID4+Pj4gcHJv cG9zYWwuIE1heWJlIEkgYW0gYSBuaXRwaWNrZXIgYnV0IGFzc3VtZSB0aGF0IGVpdGhlciAoaSkg c2VydmVyDQo+ID4+ID4+Pj4gaW1wbGVtZW50YXRpb24gaXMgY29tcGxldGVseSBnZW5lcmF0ZWQg ZnJvbSB0aGUgZGF0YSBtb2RlbCwgb3IgKGlpKQ0KPiA+PiA+Pj4+IHRoZQ0KPiA+PiA+Pj4+IHBh cnNlciBpbiBxdWVzdGlvbiBpcyBzaW1wbHkgaW4gdGhlIGltcGxlbWVudG9yJ3MgaGVhZC4gVGhl biBJIGRvbid0DQo+ID4+ID4+Pj4ga25vdyBob3cgdGhlIHNlcnZlciBjYW4gaW1wbGVtZW50IHRo ZSBzZW1hbnRpY3Mgb2YgYW4gZXh0ZW5zaW9uIGlmIHRoZQ0KPiA+PiA+Pj4+IGV4dGVuc2lvbiBp cyByZW1vdmVkIHdoaWxlIFlBTkcgbW9kdWxlcyBjb250YWluaW5nIGl0IGFyZSBiZWluZw0KPiA+ PiA+Pj4+IHBhcnNlZC4NCj4gPj4gPj4+PiANCj4gPj4gPj4+PiBBIHRleHQgbGlrZSAiYSBjbGll bnQgTUFZIGlnbm9yZSBhbiBleHRlbnNpb24gdGhhdCBpdCBkb2Vzbid0DQo+ID4+ID4+Pj4gdW5k ZXJzdGFuZCIgd291bGQgYmUgY2xlYXJlciBidXQgSSBkb24ndCB0aGluayBpdCBpcyBhY2NlcHRh YmxlIGlmIHRoZQ0KPiA+PiA+Pj4+IGV4dGVuc2lvbiBjaGFuZ2VzDQo+ID4+ID4+Pj4gDQo+ID4+ ID4+Pj4gLSBzZW1hbnRpY3Mgb2YgWUFORywNCj4gPj4gPj4+IA0KPiA+PiA+Pj4gQWdyZWVkLg0K PiA+PiA+Pj4gDQo+ID4+ID4+Pj4gLSBzZW1hbnRpY3Mgb2YgdGhlIHByb3RvY29sLA0KPiA+PiA+ Pj4gDQo+ID4+ID4+PiBNYXliZS4uLg0KPiA+PiA+Pj4gDQo+ID4+ID4+Pj4gLSBzY2hlbWEgb2Yg dGhlIGRhdGEgbW9kZWwgKGFzIGFubm90YXRpb25zIGRvKS4NCj4gPj4gPj4+IA0KPiA+PiA+Pj4g SSB0aGluayBpdCBpcyBvayB0byBkZWZpbmUgYW4gYW5ub3RhdGlvbiB3aXRoIGFuIGV4dGVuc2lv biAoYXMgdGhlDQo+ID4+ID4+PiBkcmFmdCBkb2VzKS4gIFdoZW4gZGVzaWduaW5nIGEgZmVhdHVy ZSB0aGF0IGlzIGdvaW5nIHRvIHVzZSBhbg0KPiA+PiA+Pj4gYW5ub3RhdGlvbiBpdCBpcyBpbXBv cnRhbnQgdG8ga2VlcCBpbiBtaW5kIHRoYXQgbm90IGFsbCBjbGllbnRzIHdpbGwNCj4gPj4gPj4+ IHVuZGVyc3RhbmQgdGhlIGFubm90YXRpb24uICBTbyBlLmcuIGlmIHRoZSBuZXcgZmVhdHVyZSBp cyBhICJjb21tZW50IiwNCj4gPj4gPj4+IHRoZSBzZXJ2ZXIgbWlnaHQganVzdCBibGluZGx5IHJl dHVybiB0aGVtIHRvIGFsbCBjbGllbnRzLCBidXQgaW4gdGhlDQo+ID4+ID4+IA0KPiA+PiA+PiBG b3IgYSBjbGllbnQgdGhhdCBkb2VzbuKAmXQgdW5kZXJzdGFuZCB0aGUgYW5ub3RhdGlvbiAob3Ig YW5ub3RhdGlvbnMgaW4NCj4gPj4gPj4gZ2VuZXJhbCkgaXQgaXMganVzdCBleHRyYSBqdW5rIHRo YXTigJlzIG5vdCBpbiB0aGUgZGF0YSBtb2RlbC4gVGhpcyBpcw0KPiA+PiA+PiBubyBkaWZmZXJl bnQgZnJvbSBhIG5ldyBkYXRhIG5vZGUgdHlwZSBkZWZpbmVkIHRocm91Z2ggYW4gZXh0ZW5zaW9u IC0NCj4gPj4gPj4gaW4gZmFjdCwgaW4gSlNPTiBlbmNvZGluZyBhbm5vdGF0aW9ucyBhcmUganVz dCBzcGVjaWFsIG9iamVjdA0KPiA+PiA+PiBtZW1iZXJzLiBBIHBydWRlbnQgY2xpZW50IG1heSBj b25zaWRlciBzdWNoIGRhdGEgaW52YWxpZC4NCj4gPj4gPj4gDQo+ID4+ID4+PiBjYXNlIG9mICJp bmFjdGl2ZSIsIHRoZSBzZXJ2ZXIgbXVzdCBub3Qgc2VuZCB0aGVzZSBhdHRyaWJ1dGVzIHRvIGEN Cj4gPj4gPj4+IGNsaWVudCB0aGF0IGRvZXNuJ3QgYXNrIGZvciB0aGVtLiAgKFlvdSBtYXkgYXJn dWUgdGhhdCBldmVuIGZvcg0KPiA+PiA+Pj4gY29tbWVudHMgdGhlIGNsaWVudCBzaG91bGQgYXNr IGZvciB0aGVtLCBidXQgdGhhdCBpcyBiZXNpZGVzIHRoZQ0KPiA+PiA+Pj4gcG9pbnQpLg0KPiA+ PiA+PiANCj4gPj4gPj4gSU1PIOKAnGluYWN0aXZl4oCdIGRhdGEgY2hhbmdlIHRoZSBORVRDT05G L1JFU1RDT05GIHByb3RvY29sLiBJZiBhIGNsaWVudA0KPiA+PiA+PiBkb2VzbuKAmXQgc2VlIGlu YWN0aXZlIGRhdGEsIGl0IG1heSB0aGluayBpdCBpcyBPSyB0byB3cml0ZSBpdHMgb3duDQo+ID4+ ID4+IGNvbnRlbnQgdG8gdGhhdCBwbGFjZSwgd2hpY2ggcHJvYmFibHkgc2hvdWxkbuKAmXQgYmUg YWxsb3dlZC4NCj4gPj4gPj4gDQo+ID4+ID4+PiANCj4gPj4gPj4+IFRoZSBib3R0b20gbGluZSBp cyB0aGF0IHlvdSBoYXZlIHRvIGJlIGNhcmVmdWwgd2hlbiB5b3UgZGVmaW5lIGEgbmV3DQo+ID4+ ID4+PiBleHRlbnNpb24gc3RhdGVtZW50Lg0KPiA+PiA+Pj4gDQo+ID4+ID4+Pj4+IEZvciBleGFt cGxlLCB0aGUgbmFjbTogZXh0ZW5zaW9ucyBkbyBub3QgYXBwbHkgdW5sZXNzIGlldGYtbmV0Y29u Zi1hY20NCj4gPj4gPj4+Pj4gaXMgYWR2ZXJ0aXNlZCAoYW5kIG5hY20gaXMgZW5hYmxlZCkuICBJ IGV4cGVjdCBtb3N0IGV4dGVuc2lvbnMgdG8gd29yaw0KPiA+PiA+Pj4+PiB0aGlzIHdheS4gIEFu b3RoZXIgZXhhbXBsZSBpcyBpZiB3ZSBhY3R1YWxseSBkZWZpbmVkIGkycnM6ZXBoZW1lcmFsOw0K PiA+PiA+Pj4+PiB0aGlzIHdvdWxkIGhhdmUgbm8gZWZmZWN0IHVubGVzcyB0aGUgImkycnMiIGNh cGFiaWxpdHkgKHdoYXRldmVyIHRoYXQNCj4gPj4gPj4+Pj4gaXMpIGlzIGFsc28gYWR2ZXJ0aXNl ZC4NCj4gPj4gPj4+PiANCj4gPj4gPj4+PiBUaGUgbmFjbTogZXh0ZW5zaW9ucyBhcmUgcHJvYmFi bHkgT0sgYmVjYXVzZSB0aGV5IG9ubHkgZ2l2ZSBzb21lDQo+ID4+ID4+Pj4gYWRkaXRpb25hbCBp bmZvIGFib3V0IHRoZSBzZXJ2ZXIgYmVoYXZpb3VyIHRoYXQgaXMgaW5kZXBlbmRlbnQgb2YNCj4g Pj4gPj4+PiBjbGllbnQncyBzdXBwb3J0LiBJZiB0aGUgY2xpZW50IGlnbm9yZXMgdGhlbSwgdGhl biBpdCBtYXkgYmUganVzdA0KPiA+PiA+Pj4+IHdvbmRlcmluZyB3aHkgaXQgY2Fubm90IHJlYWQg b3Igd3JpdGUgc29tZSBkYXRhLg0KPiA+PiA+Pj4gDQo+ID4+ID4+PiBSaWdodC4NCj4gPj4gPj4+ IA0KPiA+PiA+Pj4+PiBUaGUgdGV4dCBhbHNvIG1lYW5zIHRoYXQgaXQgaXMgcGVyZmVjdGx5IG9r IGZvciBhIGNsaWVudCB0byBpZ25vcmUgdGhlDQo+ID4+ID4+Pj4+IGV4dGVuc2lvbiBpZiBpdCBk b2Vzbid0IHVuZGVyc3RhbmQgaXQuICBGb3IgZXhhbXBsZSwgaWYgdGhlIGNsaWVudCBoYXMNCj4g Pj4gPj4+Pj4gbm8gaWRlYSB3aGF0IHRoZSBlcGhlbWVyYWwgZGF0YXN0b3JlIGl0LCBpdCBkb2Vz bid0IG1hdHRlciB0aGF0IGEgbm9kZQ0KPiA+PiA+Pj4+PiBpcyBtYXJrZWQgd2l0aCBpMnJzOmVw aGVtZXJhbCB0cnVlLg0KPiA+PiA+Pj4+IA0KPiA+PiA+Pj4+IEkgYW0gbm90IGNvbnZpbmNlZCBh dCBhbGwgYWJvdXQgdGhpcyBvbmUuIElmIHRoZSBzZXJ2ZXIgYWR2ZXJ0aXNlcyB0aGUNCj4gPj4g Pj4+PiAiaTJycyIgY2FwYWJpbGl0eSBhbmQgbW9kdWxlcyB0aGF0IHVzZSAiaTJyczplcGhlbWVy YWwiIGV4dGVuc2lvbiwNCj4gPj4gPj4+PiB0aGVuDQo+ID4+ID4+Pj4gYSBub3JtYWwgTkVUQ09O Ri9SRVNUQ09ORiBjbGllbnQgY2FuIGlnbm9yZSBib3RoIChSRkMgNjI0MTogIkVhY2ggcGVlcg0K PiA+PiA+Pj4+IFsuLi5dIE1VU1QgaWdub3JlIGFueSBjYXBhYmlsaXR5IHJlY2VpdmVkIGZyb20g dGhlIG90aGVyIHBlZXIgdGhhdCBpdA0KPiA+PiA+Pj4+IGRvZXMgbm90IHJlcXVpcmUgb3IgZG9l cyBub3QgdW5kZXJzdGFuZC4iKS4gQnV0aCB3aGF0IHRoZW46IGNhbiB0aGUNCj4gPj4gPj4+PiBj bGllbnQgdHJlYXQgbm9kZXMgdGFnZ2VkIHdpdGggImkycnM6ZXBoZW1lcmFsIiBqdXN0IGFzIHN0 YW5kYXJkDQo+ID4+ID4+Pj4gbm9kZXM/DQo+ID4+ID4+PiANCj4gPj4gPj4+IE15IGlkZWEgaGFz IGJlZW4gdGhhdCBpdCB3b3VsZCBiZSB1c2VkIGFzOg0KPiA+PiA+Pj4gDQo+ID4+ID4+PiAgbGVh ZiBteS1lcGhlbWVyYWwtbGVhZiB7DQo+ID4+ID4+PiAgICAgY29uZmlnIGZhbHNlOw0KPiA+PiA+ Pj4gICAgIGkycnM6ZXBoZW1lcmFsIHRydWU7DQo+ID4+ID4+PiAgICAgLi4uDQo+ID4+ID4+PiAg fQ0KPiA+PiA+Pj4gDQo+ID4+ID4+PiB3aGljaCBtZWFucyB0aGF0IGlmIHRoZSBjbGllbnQgZG9l c24ndCBrbm93IHdoYXQgdG8gZG8gd2l0aA0KPiA+PiA+Pj4gImkycnM6ZXBoZW1lcmFsIiwgaXQg d2lsbCBpZ25vcmUgaXQsIGFzIGp1c3Qgc2VlIHRoaXMgYXMgYSBub3JtYWwNCj4gPj4gPj4+IGNv bmZpZyBmYWxzZSBub2RlIHRoYXQgY2FuIGJlIHJlYWQgd2l0aCA8Z2V0Pi4NCj4gPj4gPj4gDQo+ ID4+ID4+IEl0IG9mIGNvdXJzZSBkZXBlbmRzIG9uIHRoZSBwYXJ0aWN1bGFyIHVzYWdlIHJ1bGVz IC0gSSBhc3N1bWVkDQo+ID4+ID4+IGVwaGVtZXJhbCBkYXRhIHdvdWxkIGJlIGNvbmZpZz10cnVl LiBCdXQgZXZlbiBpbiB5b3VyIGV4YW1wbGUsIGlmDQo+ID4+ID4+IGVwaGVtZXJhbCBkYXRhIGFy ZSBpbiBhIHNwZWNpYWwgZGF0YXN0b3JlLCB0aGV5IG1heSBub3QgYmUgcmV0dXJuZWQNCj4gPj4g Pj4gd2l0aCA8Z2V0Piwgd2hpY2ggY2FuIGFnYWluIHZpb2xhdGUgdGhlIHNjaGVtYS4NCj4gPj4g PiANCj4gPj4gPiBSaWdodCwgdGhpcyBpZGVhIGFzc3VtZXMgdGhhdCBlcGhlbWVyYWwgZGF0YSAq aXMqIHJldHVybmVkIGJ5IDxnZXQ+Lg0KPiA+PiA+IA0KPiA+PiA+PiBJIHRoaW5rIGFyYml0cmFy eSBleHRlbnNpb25zIGFyZSBPSyBpZiB0aGV5IGFyZSB1c2VkIGluIGEgY29udHJvbGxlZA0KPiA+ PiA+PiBlbnZpcm9ubWVudCwgZS5nLiBpbiBzaW5nbGUgdmVuZG9y4oCZcyBzZXJ2ZXIgYW5kIGNs aWVudCBzb2Z0d2FyZSwgYnV0DQo+ID4+ID4+IGluIGdlbmVyYWwgdGhleSBjYW4gYnJlYWsgaW50 ZXJvcGVyYWJpbGl0eSB1bmxlc3MgdGhleSBhcmUgYWNjb21wYW5pZWQNCj4gPj4gPj4gd2l0aCBh IGJpZGlyZWN0aW9uYWwgY2xpZW50LXNlcnZlciBuZWdvdGlhdGlvbiBtZWNoYW5pc20uDQo+ID4+ ID4gDQo+ID4+ID4gSSBhZ3JlZSB0aGF0IGl0IGlzIGltcG9ydGFudCB0byB0aGluayBhYm91dCBw cm90b2NvbCBuZWdvdGlhdGlvbg0KPiA+PiA+IG1lY2hhbmlzbXMsIGNsaWVudCBiYWNrd2FyZHMg Y29tcGF0aWJpbGl0eSBldGMuIHdoZW4gZGVmaW5pbmcNCj4gPj4gPiBleHRlbnNpb25zLg0KPiA+ PiANCj4gPj4gQnV0IGV2ZW4gdGhlbiBpdCBtaWdodCBiZSBkaWZmaWN1bHQgdG8gaGFuZGxlIHNp dHVhdGlvbnMgd2hlcmUgb25lDQo+ID4+IGNsaWVudCBzdXBwb3J0cyBhbiBleHRlbnNpb24gd2hp bGUgYW5vdGhlciBkb2VzbuKAmXQgLSB0aGUgc2VydmVyDQo+ID4+IHNpbXBseSBtYXkgbm90IGJl IGFibGUgdG8gYmVoYXZlIHNpbXVsdGFuZW91c2x5IGluIHR3byBkaWZmZXJlbnQNCj4gPj4gd2F5 cy4NCj4gPg0KPiA+IEJ1dCBqdXN0IGIvYyB0aGVyZSBhcmUgKnNvbWUqIHBvdGVudGlhbCBleHRl bnNpb24gdGhhdCB3b3VsZCBoYXZlDQo+ID4gcHJvYmxlbXMsIGRvZXMgbm90IG1lYW4gdGhhdCAq YWxsKiBleHRlbnNpb25zIHNob3VsZCBiZSBiYW5uZWQuDQo+IA0KPiBNeSBjb25jZXJuIGlzIHRo YXQgdmVuZG9ycyBtaWdodCBtaXN1c2UgZXh0ZW5zaW9ucyBmb3IgY3JlYXRpbmcgc2lsb3MgLQ0K PiB3ZSBhbGwgcmVtZW1iZXIgYnJvd3NlciB3YXJzLCByaWdodD8NCj4gDQo+IEFuZCBpbiB0aGUg cGFydGljdWxhciBjYXNlIG9mICJhbm5vdGF0aW9uIiwgSSBhbSBub3Qgc3VyZSB3aGV0aGVyIGl0 IGlzDQo+IHJlYWxseSBPSyBmb3IgYSBzZXJ2ZXIgdG8gYWR2ZXJ0aXNlIGFuIGFubm90YXRpb24g aW4gYSBtb2R1bGUgYW5kIHRoZW4NCj4gc3RhcnQgdXNpbmcgaXQgd2l0aG91dCBjbGllbnQncyBj b25zZW50Lg0KPiANCj4gPg0KPiA+PiBUaGF04oCZcyB3aHkgSSB0aGluayB0aGUgb25seSBvcHRp b24gdGhhdOKAmXMgcmVhbGx5IHNhZmUgZm9yIG5vdw0KPiA+PiBpcw0KPiA+PiANCj4gPj4gKiog U29sdXRpb24gWXh4LTAzDQo+ID4+IA0KPiA+PiAgIE1ha2UgZXh0ZW5zaW9ucyBvcHRpb25hbC4g VGhpcyBtZWFucyB0aGF0IGV4dGVuc2lvbnMgd29uJ3QgYmUNCj4gPj4gICBhbGxvd2VkIHRvIGNo YW5nZSBZQU5HIGxhbmd1YWdlLCBORVRDT05GIHByb3RvY29sLCBhbmQgdmFsaWRpdHkgb2YNCj4g Pj4gICBkYXRhc3RvcmVzIGFuZCBwcm90b2NvbCBtZXNzYWdlcy4NCj4gPg0KPiA+IEkgdGhpbmsg d2UgbmVlZCBleHBsaWNpdCB0ZXh0IGluIG9yZGVyIHRvIGJlIGFibGUgdG8gYWdyZWUgb24gYQ0K PiA+IHNvbHV0aW9uLg0KPiANCj4gU2VjdGlvbiA2LjMuMToNCj4gDQo+IE9MRA0KPiANCj4gICAg SWYgYSBZQU5HIGNvbXBpbGVyIGRvZXMgbm90IHN1cHBvcnQgYSBwYXJ0aWN1bGFyIGV4dGVuc2lv biwgd2hpY2gNCj4gICAgYXBwZWFycyBpbiBhIFlBTkcgbW9kdWxlIGFzIGFuIHVua25vd24tc3Rh dGVtZW50IChzZWUgU2VjdGlvbiAxMiksDQo+ICAgIHRoZSBlbnRpcmUgdW5rbm93bi1zdGF0ZW1l bnQgTUFZIGJlIGlnbm9yZWQgYnkgdGhlIGNvbXBpbGVyLg0KPiANCj4gTkVXDQo+IA0KPiAgICBF eHRlbnNpb25zIE1VU1QgTk9UIGFmZmVjdCB0aGUgZm9sbG93aW5nIGFzcGVjdHM6DQo+IA0KPiAg ICBvIHN5bnRheCBhbmQgc2VtYW50aWNzIG9mIFlBTkcgbGFuZ3VhZ2UsDQoNCkkgZG9uJ3Qga25v dyB3aGF0IHRoaXMgbWVhbnMsIGJ1dCBpdCBzb3VuZHMgb2suLi4NCg0KPiAgICBvIG1hbmFnZW1l bnQgcHJvdG9jb2xzIHN1Y2ggYXMgTkVUQ09ORiBvciBSRVNUQ09ORiwNCj4NCj4gICAgbyB2YWxp ZGl0eSBvZiBkYXRhc3RvcmVzIGFuZCBwcm90b2NvbCBtZXNzYWdlcyB3aXRoIHJlc3BlY3QgdG8g dGhlDQo+ICAgICAgZGF0YSBtb2RlbC4NCg0KSSBhbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQgdGhl c2UgdHdvIGVpdGhlci4gIEkgZG9uJ3QgdGhpbmsgdGhpcyBpcw0KbmVlZGVkLiAgSXQncyBsaWtl IGlmIHdlIHdyb3RlIHRoYXQgdGhlIHRleHQgaW4gZGVzY3JpcHRpb24gc3RhdGVtZW50cw0KTVVT VCBOT1QgImFmZmVjdCBtYW5hZ2VtZW50IHByb3RvY29scyBsaWtlIE5FVENPTkYiLCBldGMuICBJ ZiBzb21lb25lDQp0cmllcyB0byBnZXQgc3VjaCBhbiBleHRlbnNpb24gc3RhbmRhcmRpemVkLCBo b3BlZnVsbHkgcmV2aWV3ZXJzIHdpbGwNCmNhdGNoIHRoaXMuDQoNCj4gICAgQSBzZXJ2ZXIgYWR2 ZXJ0aXNpbmcgbW9kdWxlcyB0aGF0IGRlZmluZSBhbmQgdXNlIGFuIGV4dGVuc2lvbiBNVVNUDQo+ ICAgIGFkaGVyZSB0byB0aGUgZXh0ZW5zaW9uJ3Mgc2VtYW50aWNzIGFzIHNwZWNpZmllZCBpbiBp dHMgZGVmaW5pdGlvbi4NCg0KT2suDQoNCj4gICAgSG93ZXZlciwgY2xpZW50cyBNQVkgaWdub3Jl IGFueSBvciBhbGwgZXh0ZW5zaW9ucyBhcHBlYXJpbmcgaW4NCj4gICAgbW9kdWxlcyBhZHZlcnRp c2VkIGJ5IHRoZSBzZXJ2ZXIuDQoNCkhtbSwgSSBhZ3JlZSB3aXRoIEFuZHkncyBpZGVhIHRoYXQg dGhlIGRlZmluaXRpb24gb2YgYW4gZXh0ZW5zaW9uDQpkZWZpbmVzIHRoZSBjb25mb3JtYW5jZSBm b3IgdGhlIGV4dGVuc2lvbi4NCg0KDQo+IEJ5IHRoZSB3YXksIGR1ZSB0byB0aGUgYWRvcHRlZCBz b2x1dGlvbiBZNDktMDQsIHRoZSBzZWNvbmQgcGFyYWdyYXBoIGluDQo+IHNlYy4gNi4zLjEgc2hv dWxkIGFsc28gYmUgcmVtb3ZlZC4NCg0KSSBhc3N1bWUgeW91IG1lYW4gdGhlIHNlY29uZCBwYXJh Z3JhcGggb2YgNi4zLjEgaW4gUkZDIDYwMjA/ICBUaGF0DQpwYXJhZ3JhcGggaXMgYWxyZWFkeSBy ZW1vdmVkIGluIGRyYWZ0LWlldGYtbmV0bW9kLXJmYzYwMjBiaXMtMDYuDQoNCg0KL21hcnRpbg0K From nobody Thu Aug 20 06:43:24 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 623181ACE6C for ; Thu, 20 Aug 2015 06:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.761 X-Spam-Level: X-Spam-Status: No, score=-4.761 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_64=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZvJKfrOMU06 for ; Thu, 20 Aug 2015 06:43:20 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA2E41ACE71 for ; Thu, 20 Aug 2015 06:43:19 -0700 (PDT) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 57DE6181836; Thu, 20 Aug 2015 15:43:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1440078197; bh=NkIGrMBcw0VyRo77bPNMUtEMctIR+LMP8Mde7Epfdso=; h=From:Date:To; b=qxFpUGJ8z/+MzC3beP1OMxvO/aZ0UV2iDXQj4PRqM/NWPzd4JCxwHEPE0Cs7Q/PxZ jvN9IKslvBb2hJyeZov5zqV+nY3rBh8s7VJxPcAiM8Be20Bz8SENMosz4Kebq4MOvG EKXJa9yeaF8ceB/qC2NjfWYGlXnMsM0lpHVwZfjo= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: <20150820.152603.242849288817455571.mbj@tail-f.com> Date: Thu, 20 Aug 2015 15:43:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9A9BA04C-D55D-4745-8458-4C8EF2C873A0@nic.cz> References: <3B335831-4C79-4EB4-AC62-EA21D50E5928@nic.cz> <20150820.132857.1812838545863613387.mbj@tail-f.com> <20150820.152603.242849288817455571.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] extensions and conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 13:43:23 -0000 > On 20 Aug 2015, at 15:26, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >> Martin Bjorklund writes: >>=20 >>> Ladislav Lhotka wrote: >>>>=20 >>>>> On 20 Aug 2015, at 13:12, Martin Bjorklund wrote: >>>>>=20 >>>>> Ladislav Lhotka wrote: >>>>>>=20 >>>>>>> On 20 Aug 2015, at 12:37, Martin Bjorklund = wrote: >>>>>>>=20 >>>>>>> Ladislav Lhotka wrote: >>>>>>>> Martin Bjorklund writes: >>>>>>>>=20 >>>>>>>>> Andy Bierman wrote: >>>>>>>>>> On Wed, Aug 19, 2015 at 5:49 AM, Martin Bjorklund = >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> Hi, >>>>>>>>>>>=20 >>>>>>>>>>> [joining this discussion a bit late] >>>>>>>>>>>=20 >>>>>>>>>>> Ladislav Lhotka wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>> On 10 Aug 2015, at 18:46, Andy Bierman = wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Mon, Aug 10, 2015 at 9:37 AM, Ladislav Lhotka = >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On 10 Aug 2015, at 17:32, Andy Bierman = wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On Mon, Aug 10, 2015 at 4:24 AM, Ladislav Lhotka = >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On 10 Aug 2015, at 12:17, Andy Bierman = wrote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> I am strongly against changing the contract on = extensions. >>>>>>>>>>>>>>> They MAY be ignored by any YANG tool. Period. >>>>>>>>>>>>>>> That means they are far from mandatory. >>>>>>>>>>>>>>> They are little more than a keyword and a description = clause. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> So do you prefer my proposed solution -02 or -03? >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> ** Solution Yxx-03 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Make extensions optional. This means that extensions = won't be >>>>>>>>>>>>>> allowed to change YANG language, NETCONF protocol, and = validity of >>>>>>>>>>>>>> datastores and protocol messages. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> This is how we use extensions to tag YANG data models >>>>>>>>>>>>>> to drive automation tools. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> But that means, for example, that annotations cannot be = defined via an >>>>>>>>>>>>> extension statement as in draft-ietf-netmod-yang-metadata. >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Which means these statements should be real instead of = extensions. >>>>>>>>>>>>> If the statements are defining data that is exchanged = between >>>>>>>>>>>>> peers in a standard protocol, then YANG extensions are not >>>>>>>>>>>>> appropriate. >>>>>>>>>>>>=20 >>>>>>>>>>>> I agree, and -03 is my preferred solution, too. >>>>>>>>>>>=20 >>>>>>>>>>> I strongly disagree. IMO the IETF usage of extensions so = far (NACM, >>>>>>>>>>> annotations) works well (in the case of NACM proven by = multiple >>>>>>>>>>> independent implementations), and follows how extensions = were intended >>>>>>>>>>> to be used, and obviously, how the WG has understood them up = until >>>>>>>>>>> now. >>>>>>>>>>>=20 >>>>>>>>>>> If the sentence: >>>>>>>>>>>=20 >>>>>>>>>>> If a YANG compiler does not support a particular extension, = which >>>>>>>>>>> appears in a YANG module as an unknown-statement (see = Section 12), >>>>>>>>>>> the entire unknown-statement MAY be ignored by the compiler. >>>>>>>>>>>=20 >>>>>>>>>>> in 6020 can be interpreted to mean that an occurance of an = extension >>>>>>>>>>> is non-normative, we should fix it so that it matches what = was >>>>>>>>>>> intended and how it is used. >>>>>>>>>>>=20 >>>>>>>>>>> Juergen suggested this replacement text, which I support. = Maybe it >>>>>>>>>>> can be improved even more. >>>>>>>>>>>=20 >>>>>>>>>>> If a YANG parser does not support a particular = extension, which >>>>>>>>>>> appears in a YANG module as an unknown-statement (see = Section 13), >>>>>>>>>>> the entire unknown-statement MAY be ignored by the = parser. Note >>>>>>>>>>> that even in this case the semantics associated with the = extension >>>>>>>>>>> still apply (as if they were part of a description = statement). >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> I strongly disagree with this change. >>>>>>>>>> This would mean that every tool is required to support the >>>>>>>>>> semantics of every extension ever defined. >>>>>>>>>=20 >>>>>>>>> No. It means that if a server advertises module that uses = some >>>>>>>>> extension to define some behaviour, the server supports that >>>>>>>>> behavior. Just as we expect a server to support the text in >>>>>>>>> description statements. >>>>>>>>=20 >>>>>>>> This is unclear both from the current text and from Juergen's >>>>>>>> proposal. Maybe I am a nitpicker but assume that either (i) = server >>>>>>>> implementation is completely generated from the data model, or = (ii) >>>>>>>> the >>>>>>>> parser in question is simply in the implementor's head. Then I = don't >>>>>>>> know how the server can implement the semantics of an extension = if the >>>>>>>> extension is removed while YANG modules containing it are being >>>>>>>> parsed. >>>>>>>>=20 >>>>>>>> A text like "a client MAY ignore an extension that it doesn't >>>>>>>> understand" would be clearer but I don't think it is acceptable = if the >>>>>>>> extension changes >>>>>>>>=20 >>>>>>>> - semantics of YANG, >>>>>>>=20 >>>>>>> Agreed. >>>>>>>=20 >>>>>>>> - semantics of the protocol, >>>>>>>=20 >>>>>>> Maybe... >>>>>>>=20 >>>>>>>> - schema of the data model (as annotations do). >>>>>>>=20 >>>>>>> I think it is ok to define an annotation with an extension (as = the >>>>>>> draft does). When designing a feature that is going to use an >>>>>>> annotation it is important to keep in mind that not all clients = will >>>>>>> understand the annotation. So e.g. if the new feature is a = "comment", >>>>>>> the server might just blindly return them to all clients, but in = the >>>>>>=20 >>>>>> For a client that doesn=E2=80=99t understand the annotation (or = annotations in >>>>>> general) it is just extra junk that=E2=80=99s not in the data = model. This is >>>>>> no different from a new data node type defined through an = extension - >>>>>> in fact, in JSON encoding annotations are just special object >>>>>> members. A prudent client may consider such data invalid. >>>>>>=20 >>>>>>> case of "inactive", the server must not send these attributes to = a >>>>>>> client that doesn't ask for them. (You may argue that even for >>>>>>> comments the client should ask for them, but that is besides the >>>>>>> point). >>>>>>=20 >>>>>> IMO =E2=80=9Cinactive=E2=80=9D data change the NETCONF/RESTCONF = protocol. If a client >>>>>> doesn=E2=80=99t see inactive data, it may think it is OK to write = its own >>>>>> content to that place, which probably shouldn=E2=80=99t be = allowed. >>>>>>=20 >>>>>>>=20 >>>>>>> The bottom line is that you have to be careful when you define a = new >>>>>>> extension statement. >>>>>>>=20 >>>>>>>>> For example, the nacm: extensions do not apply unless = ietf-netconf-acm >>>>>>>>> is advertised (and nacm is enabled). I expect most extensions = to work >>>>>>>>> this way. Another example is if we actually defined = i2rs:ephemeral; >>>>>>>>> this would have no effect unless the "i2rs" capability = (whatever that >>>>>>>>> is) is also advertised. >>>>>>>>=20 >>>>>>>> The nacm: extensions are probably OK because they only give = some >>>>>>>> additional info about the server behaviour that is independent = of >>>>>>>> client's support. If the client ignores them, then it may be = just >>>>>>>> wondering why it cannot read or write some data. >>>>>>>=20 >>>>>>> Right. >>>>>>>=20 >>>>>>>>> The text also means that it is perfectly ok for a client to = ignore the >>>>>>>>> extension if it doesn't understand it. For example, if the = client has >>>>>>>>> no idea what the ephemeral datastore it, it doesn't matter = that a node >>>>>>>>> is marked with i2rs:ephemeral true. >>>>>>>>=20 >>>>>>>> I am not convinced at all about this one. If the server = advertises the >>>>>>>> "i2rs" capability and modules that use "i2rs:ephemeral" = extension, >>>>>>>> then >>>>>>>> a normal NETCONF/RESTCONF client can ignore both (RFC 6241: = "Each peer >>>>>>>> [...] MUST ignore any capability received from the other peer = that it >>>>>>>> does not require or does not understand."). Buth what then: can = the >>>>>>>> client treat nodes tagged with "i2rs:ephemeral" just as = standard >>>>>>>> nodes? >>>>>>>=20 >>>>>>> My idea has been that it would be used as: >>>>>>>=20 >>>>>>> leaf my-ephemeral-leaf { >>>>>>> config false; >>>>>>> i2rs:ephemeral true; >>>>>>> ... >>>>>>> } >>>>>>>=20 >>>>>>> which means that if the client doesn't know what to do with >>>>>>> "i2rs:ephemeral", it will ignore it, as just see this as a = normal >>>>>>> config false node that can be read with . >>>>>>=20 >>>>>> It of course depends on the particular usage rules - I assumed >>>>>> ephemeral data would be config=3Dtrue. But even in your example, = if >>>>>> ephemeral data are in a special datastore, they may not be = returned >>>>>> with , which can again violate the schema. >>>>>=20 >>>>> Right, this idea assumes that ephemeral data *is* returned by = . >>>>>=20 >>>>>> I think arbitrary extensions are OK if they are used in a = controlled >>>>>> environment, e.g. in single vendor=E2=80=99s server and client = software, but >>>>>> in general they can break interoperability unless they are = accompanied >>>>>> with a bidirectional client-server negotiation mechanism. >>>>>=20 >>>>> I agree that it is important to think about protocol negotiation >>>>> mechanisms, client backwards compatibility etc. when defining >>>>> extensions. >>>>=20 >>>> But even then it might be difficult to handle situations where one >>>> client supports an extension while another doesn=E2=80=99t - the = server >>>> simply may not be able to behave simultaneously in two different >>>> ways. >>>=20 >>> But just b/c there are *some* potential extension that would have >>> problems, does not mean that *all* extensions should be banned. >>=20 >> My concern is that vendors might misuse extensions for creating silos = - >> we all remember browser wars, right? >>=20 >> And in the particular case of "annotation", I am not sure whether it = is >> really OK for a server to advertise an annotation in a module and = then >> start using it without client's consent. >>=20 >>>=20 >>>> That=E2=80=99s why I think the only option that=E2=80=99s really = safe for now >>>> is >>>>=20 >>>> ** Solution Yxx-03 >>>>=20 >>>> Make extensions optional. This means that extensions won't be >>>> allowed to change YANG language, NETCONF protocol, and validity of >>>> datastores and protocol messages. >>>=20 >>> I think we need explicit text in order to be able to agree on a >>> solution. >>=20 >> Section 6.3.1: >>=20 >> OLD >>=20 >> If a YANG compiler does not support a particular extension, which >> appears in a YANG module as an unknown-statement (see Section 12), >> the entire unknown-statement MAY be ignored by the compiler. >>=20 >> NEW >>=20 >> Extensions MUST NOT affect the following aspects: >>=20 >> o syntax and semantics of YANG language, >=20 > I don't know what this means, but it sounds ok=E2=80=A6 Examples: an extension cannot say that=20 - a YANG statement may have two arguments, - a leaf-list may have duplicate entries.=20 >=20 >> o management protocols such as NETCONF or RESTCONF, >>=20 >> o validity of datastores and protocol messages with respect to the >> data model. >=20 > I am not sure I understand these two either. I don't think this is > needed. It's like if we wrote that the text in description statements > MUST NOT "affect management protocols like NETCONF", etc. If someone > tries to get such an extension standardized, hopefully reviewers will > catch this. I think we should state *some* restrictions, albeit general. Otherwise = authors may be wondering why reviewers reject their great extensions. With descriptions I also don=E2=80=99t know how to interpret (and = restrict) their normative character. For example, would this be OK? description "This leaf can be configured only on Christmas Day." >=20 >> A server advertising modules that define and use an extension MUST >> adhere to the extension's semantics as specified in its definition. >=20 > Ok. >=20 >> However, clients MAY ignore any or all extensions appearing in >> modules advertised by the server. >=20 > Hmm, I agree with Andy's idea that the definition of an extension > defines the conformance for the extension. Now I don=E2=80=99t know what this means. >=20 >=20 >> By the way, due to the adopted solution Y49-04, the second paragraph = in >> sec. 6.3.1 should also be removed. >=20 > I assume you mean the second paragraph of 6.3.1 in RFC 6020? That > paragraph is already removed in draft-ietf-netmod-rfc6020bis-06. OK, I thought I was looking into 6020bis, sorry. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Aug 20 07:01:39 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 197171ACE57 for ; Thu, 20 Aug 2015 07:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.412 X-Spam-Level: X-Spam-Status: No, score=-1.412 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_64=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SG2Dz4LxQnor for ; Thu, 20 Aug 2015 07:01:35 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A84F81A038E for ; Thu, 20 Aug 2015 07:01:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1440079236; bh=rnnhol0+1m++ZpaD2PJaWYOURqbiU76Whv1uvs6nMFQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=N959GG+MxF9T9nTHHdI1sZKGon5tz/MCfGTnooC573IwZ5gc4CgN5FqLTKeS0DE9Z aAlioljwDz1an+2w2RTWcAG+ebBEFgVcxjo8900Eokdth42pJt1pgAKzrpjM0AymTj lZi8fA6DRMALPIRmd50lUwo8xwtQvn+MB6e9Ee4c= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Nadeau Thomas In-Reply-To: <20150820.152603.242849288817455571.mbj@tail-f.com> Date: Thu, 20 Aug 2015 10:00:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9AF42DE2-327C-49AB-9947-E725800E618D@lucidvision.com> References: <3B335831-4C79-4EB4-AC62-EA21D50E5928@nic.cz> <20150820.132857.1812838545863613387.mbj@tail-f.com> <20150820.152603.242849288817455571.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.2104) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-ShareWhite: 50.255.148.181 X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=21 Stars=0 Good=0 Friend=4 Surbl=0 Catch=0 r=0 ip=50.255.148.181 X-IP-stats: Notspam Incoming Last 0, First 97, in=947, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] extensions and conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 14:01:38 -0000 > On Aug 20, 2015:9:26 AM, at 9:26 AM, Martin Bjorklund = wrote: >=20 > Ladislav Lhotka wrote: >> Martin Bjorklund writes: >>=20 >>> Ladislav Lhotka wrote: >>>>=20 >>>>> On 20 Aug 2015, at 13:12, Martin Bjorklund wrote: >>>>>=20 >>>>> Ladislav Lhotka wrote: >>>>>>=20 >>>>>>> On 20 Aug 2015, at 12:37, Martin Bjorklund = wrote: >>>>>>>=20 >>>>>>> Ladislav Lhotka wrote: >>>>>>>> Martin Bjorklund writes: >>>>>>>>=20 >>>>>>>>> Andy Bierman wrote: >>>>>>>>>> On Wed, Aug 19, 2015 at 5:49 AM, Martin Bjorklund = >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> Hi, >>>>>>>>>>>=20 >>>>>>>>>>> [joining this discussion a bit late] >>>>>>>>>>>=20 >>>>>>>>>>> Ladislav Lhotka wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>> On 10 Aug 2015, at 18:46, Andy Bierman = wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Mon, Aug 10, 2015 at 9:37 AM, Ladislav Lhotka = >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On 10 Aug 2015, at 17:32, Andy Bierman = wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On Mon, Aug 10, 2015 at 4:24 AM, Ladislav Lhotka = >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On 10 Aug 2015, at 12:17, Andy Bierman = wrote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> I am strongly against changing the contract on = extensions. >>>>>>>>>>>>>>> They MAY be ignored by any YANG tool. Period. >>>>>>>>>>>>>>> That means they are far from mandatory. >>>>>>>>>>>>>>> They are little more than a keyword and a description = clause. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> So do you prefer my proposed solution -02 or -03? >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> ** Solution Yxx-03 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Make extensions optional. This means that extensions = won't be >>>>>>>>>>>>>> allowed to change YANG language, NETCONF protocol, and = validity of >>>>>>>>>>>>>> datastores and protocol messages. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> This is how we use extensions to tag YANG data models >>>>>>>>>>>>>> to drive automation tools. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> But that means, for example, that annotations cannot be = defined via an >>>>>>>>>>>>> extension statement as in draft-ietf-netmod-yang-metadata. >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Which means these statements should be real instead of = extensions. >>>>>>>>>>>>> If the statements are defining data that is exchanged = between >>>>>>>>>>>>> peers in a standard protocol, then YANG extensions are not >>>>>>>>>>>>> appropriate. >>>>>>>>>>>>=20 >>>>>>>>>>>> I agree, and -03 is my preferred solution, too. >>>>>>>>>>>=20 >>>>>>>>>>> I strongly disagree. IMO the IETF usage of extensions so = far (NACM, >>>>>>>>>>> annotations) works well (in the case of NACM proven by = multiple >>>>>>>>>>> independent implementations), and follows how extensions = were intended >>>>>>>>>>> to be used, and obviously, how the WG has understood them up = until >>>>>>>>>>> now. >>>>>>>>>>>=20 >>>>>>>>>>> If the sentence: >>>>>>>>>>>=20 >>>>>>>>>>> If a YANG compiler does not support a particular extension, = which >>>>>>>>>>> appears in a YANG module as an unknown-statement (see = Section 12), >>>>>>>>>>> the entire unknown-statement MAY be ignored by the compiler. >>>>>>>>>>>=20 >>>>>>>>>>> in 6020 can be interpreted to mean that an occurance of an = extension >>>>>>>>>>> is non-normative, we should fix it so that it matches what = was >>>>>>>>>>> intended and how it is used. >>>>>>>>>>>=20 >>>>>>>>>>> Juergen suggested this replacement text, which I support. = Maybe it >>>>>>>>>>> can be improved even more. >>>>>>>>>>>=20 >>>>>>>>>>> If a YANG parser does not support a particular = extension, which >>>>>>>>>>> appears in a YANG module as an unknown-statement (see = Section 13), >>>>>>>>>>> the entire unknown-statement MAY be ignored by the = parser. Note >>>>>>>>>>> that even in this case the semantics associated with the = extension >>>>>>>>>>> still apply (as if they were part of a description = statement). >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> I strongly disagree with this change. >>>>>>>>>> This would mean that every tool is required to support the >>>>>>>>>> semantics of every extension ever defined. >>>>>>>>>=20 >>>>>>>>> No. It means that if a server advertises module that uses = some >>>>>>>>> extension to define some behaviour, the server supports that >>>>>>>>> behavior. Just as we expect a server to support the text in >>>>>>>>> description statements. >>>>>>>>=20 >>>>>>>> This is unclear both from the current text and from Juergen's >>>>>>>> proposal. Maybe I am a nitpicker but assume that either (i) = server >>>>>>>> implementation is completely generated from the data model, or = (ii) >>>>>>>> the >>>>>>>> parser in question is simply in the implementor's head. Then I = don't >>>>>>>> know how the server can implement the semantics of an extension = if the >>>>>>>> extension is removed while YANG modules containing it are being >>>>>>>> parsed. >>>>>>>>=20 >>>>>>>> A text like "a client MAY ignore an extension that it doesn't >>>>>>>> understand" would be clearer but I don't think it is acceptable = if the >>>>>>>> extension changes >>>>>>>>=20 >>>>>>>> - semantics of YANG, >>>>>>>=20 >>>>>>> Agreed. >>>>>>>=20 >>>>>>>> - semantics of the protocol, >>>>>>>=20 >>>>>>> Maybe... >>>>>>>=20 >>>>>>>> - schema of the data model (as annotations do). >>>>>>>=20 >>>>>>> I think it is ok to define an annotation with an extension (as = the >>>>>>> draft does). When designing a feature that is going to use an >>>>>>> annotation it is important to keep in mind that not all clients = will >>>>>>> understand the annotation. So e.g. if the new feature is a = "comment", >>>>>>> the server might just blindly return them to all clients, but in = the >>>>>>=20 >>>>>> For a client that doesn=E2=80=99t understand the annotation (or = annotations in >>>>>> general) it is just extra junk that=E2=80=99s not in the data = model. This is >>>>>> no different from a new data node type defined through an = extension - >>>>>> in fact, in JSON encoding annotations are just special object >>>>>> members. A prudent client may consider such data invalid. >>>>>>=20 >>>>>>> case of "inactive", the server must not send these attributes to = a >>>>>>> client that doesn't ask for them. (You may argue that even for >>>>>>> comments the client should ask for them, but that is besides the >>>>>>> point). >>>>>>=20 >>>>>> IMO =E2=80=9Cinactive=E2=80=9D data change the NETCONF/RESTCONF = protocol. If a client >>>>>> doesn=E2=80=99t see inactive data, it may think it is OK to write = its own >>>>>> content to that place, which probably shouldn=E2=80=99t be = allowed. >>>>>>=20 >>>>>>>=20 >>>>>>> The bottom line is that you have to be careful when you define a = new >>>>>>> extension statement. >>>>>>>=20 >>>>>>>>> For example, the nacm: extensions do not apply unless = ietf-netconf-acm >>>>>>>>> is advertised (and nacm is enabled). I expect most extensions = to work >>>>>>>>> this way. Another example is if we actually defined = i2rs:ephemeral; >>>>>>>>> this would have no effect unless the "i2rs" capability = (whatever that >>>>>>>>> is) is also advertised. >>>>>>>>=20 >>>>>>>> The nacm: extensions are probably OK because they only give = some >>>>>>>> additional info about the server behaviour that is independent = of >>>>>>>> client's support. If the client ignores them, then it may be = just >>>>>>>> wondering why it cannot read or write some data. >>>>>>>=20 >>>>>>> Right. >>>>>>>=20 >>>>>>>>> The text also means that it is perfectly ok for a client to = ignore the >>>>>>>>> extension if it doesn't understand it. For example, if the = client has >>>>>>>>> no idea what the ephemeral datastore it, it doesn't matter = that a node >>>>>>>>> is marked with i2rs:ephemeral true. >>>>>>>>=20 >>>>>>>> I am not convinced at all about this one. If the server = advertises the >>>>>>>> "i2rs" capability and modules that use "i2rs:ephemeral" = extension, >>>>>>>> then >>>>>>>> a normal NETCONF/RESTCONF client can ignore both (RFC 6241: = "Each peer >>>>>>>> [...] MUST ignore any capability received from the other peer = that it >>>>>>>> does not require or does not understand."). Buth what then: can = the >>>>>>>> client treat nodes tagged with "i2rs:ephemeral" just as = standard >>>>>>>> nodes? >>>>>>>=20 >>>>>>> My idea has been that it would be used as: >>>>>>>=20 >>>>>>> leaf my-ephemeral-leaf { >>>>>>> config false; >>>>>>> i2rs:ephemeral true; >>>>>>> ... >>>>>>> } >>>>>>>=20 >>>>>>> which means that if the client doesn't know what to do with >>>>>>> "i2rs:ephemeral", it will ignore it, as just see this as a = normal >>>>>>> config false node that can be read with . >>>>>>=20 >>>>>> It of course depends on the particular usage rules - I assumed >>>>>> ephemeral data would be config=3Dtrue. But even in your example, = if >>>>>> ephemeral data are in a special datastore, they may not be = returned >>>>>> with , which can again violate the schema. >>>>>=20 >>>>> Right, this idea assumes that ephemeral data *is* returned by = . >>>>>=20 >>>>>> I think arbitrary extensions are OK if they are used in a = controlled >>>>>> environment, e.g. in single vendor=E2=80=99s server and client = software, but >>>>>> in general they can break interoperability unless they are = accompanied >>>>>> with a bidirectional client-server negotiation mechanism. >>>>>=20 >>>>> I agree that it is important to think about protocol negotiation >>>>> mechanisms, client backwards compatibility etc. when defining >>>>> extensions. >>>>=20 >>>> But even then it might be difficult to handle situations where one >>>> client supports an extension while another doesn=E2=80=99t - the = server >>>> simply may not be able to behave simultaneously in two different >>>> ways. >>>=20 >>> But just b/c there are *some* potential extension that would have >>> problems, does not mean that *all* extensions should be banned. >>=20 >> My concern is that vendors might misuse extensions for creating silos = - >> we all remember browser wars, right? >>=20 >> And in the particular case of "annotation", I am not sure whether it = is >> really OK for a server to advertise an annotation in a module and = then >> start using it without client's consent. >>=20 >>>=20 >>>> That=E2=80=99s why I think the only option that=E2=80=99s really = safe for now >>>> is >>>>=20 >>>> ** Solution Yxx-03 >>>>=20 >>>> Make extensions optional. This means that extensions won't be >>>> allowed to change YANG language, NETCONF protocol, and validity of >>>> datastores and protocol messages. >>>=20 >>> I think we need explicit text in order to be able to agree on a >>> solution. >>=20 >> Section 6.3.1: >>=20 >> OLD >>=20 >> If a YANG compiler does not support a particular extension, which >> appears in a YANG module as an unknown-statement (see Section 12), >> the entire unknown-statement MAY be ignored by the compiler. >>=20 >> NEW >>=20 >> Extensions MUST NOT affect the following aspects: >>=20 >> o syntax and semantics of YANG language, >=20 > I don't know what this means, but it sounds ok=E2=80=A6 I think what you mean is =E2=80=9CMUST NOT contradict the syntax = or semantics specified in The Yang Language [RFC Reference]=E2=80=9D >=20 >> o management protocols such as NETCONF or RESTCONF, This is trickier. We are now in agreement that Yang as a = language, is not bound to NETCONF and also RestConf, but it seems the = statement above doesn=E2=80=99t buy into that because its coupling the = three things together. =E2=80=94Tom >>=20 >> o validity of datastores and protocol messages with respect to the >> data model. >=20 > I am not sure I understand these two either. I don't think this is > needed. It's like if we wrote that the text in description statements > MUST NOT "affect management protocols like NETCONF", etc. If someone > tries to get such an extension standardized, hopefully reviewers will > catch this. >=20 >> A server advertising modules that define and use an extension MUST >> adhere to the extension's semantics as specified in its definition. >=20 > Ok. >=20 >> However, clients MAY ignore any or all extensions appearing in >> modules advertised by the server. >=20 > Hmm, I agree with Andy's idea that the definition of an extension > defines the conformance for the extension. >=20 >=20 >> By the way, due to the adopted solution Y49-04, the second paragraph = in >> sec. 6.3.1 should also be removed. >=20 > I assume you mean the second paragraph of 6.3.1 in RFC 6020? That > paragraph is already removed in draft-ietf-netmod-rfc6020bis-06. >=20 >=20 > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Aug 20 07:30:34 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72A2F1A6F87 for ; Thu, 20 Aug 2015 07:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.061 X-Spam-Level: X-Spam-Status: No, score=-5.061 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6aHQQ20l_x0 for ; Thu, 20 Aug 2015 07:30:28 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF26A1A026C for ; Thu, 20 Aug 2015 07:30:26 -0700 (PDT) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 4A3041813D8; Thu, 20 Aug 2015 16:30:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1440081025; bh=sSfDL5UcgIM0JBcithcrBOn9Av2rO6sHJHAXVRXfH9k=; h=From:Date:To; b=Vph2/WzYkXQObL4EAbzQ+Z6fqjzCBjp6jsXMh94dNQY6VEe1QsUUmkaMe4dzDcClH ryZF8qi7GxTgm9UXjRQDnIfhzrDUIs8AS31uHSQP7HUZOjQX9/vuA5x401U7HpS2B3 Pg0TzG0G2PVfQHkQsCM40T21MsI8+eTtiezt1PEU= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: <9AF42DE2-327C-49AB-9947-E725800E618D@lucidvision.com> Date: Thu, 20 Aug 2015 16:30:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6C35E6EB-0BA3-448B-82DD-0AB4CD704AAE@nic.cz> References: <3B335831-4C79-4EB4-AC62-EA21D50E5928@nic.cz> <20150820.132857.1812838545863613387.mbj@tail-f.com> <20150820.152603.242849288817455571.mbj@tail-f.com> <9AF42DE2-327C-49AB-9947-E725800E618D@lucidvision.com> To: Thomas Nadeau X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] extensions and conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 14:30:32 -0000 > On 20 Aug 2015, at 16:00, Nadeau Thomas = wrote: >=20 >>=20 >> On Aug 20, 2015:9:26 AM, at 9:26 AM, Martin Bjorklund = wrote: >>=20 >> Ladislav Lhotka wrote: >>> Martin Bjorklund writes: >>>=20 >>>> Ladislav Lhotka wrote: >>>>>=20 >>>>>> On 20 Aug 2015, at 13:12, Martin Bjorklund = wrote: >>>>>>=20 >>>>>> Ladislav Lhotka wrote: >>>>>>>=20 >>>>>>>> On 20 Aug 2015, at 12:37, Martin Bjorklund = wrote: >>>>>>>>=20 >>>>>>>> Ladislav Lhotka wrote: >>>>>>>>> Martin Bjorklund writes: >>>>>>>>>=20 >>>>>>>>>> Andy Bierman wrote: >>>>>>>>>>> On Wed, Aug 19, 2015 at 5:49 AM, Martin Bjorklund = >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> Hi, >>>>>>>>>>>>=20 >>>>>>>>>>>> [joining this discussion a bit late] >>>>>>>>>>>>=20 >>>>>>>>>>>> Ladislav Lhotka wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On 10 Aug 2015, at 18:46, Andy Bierman = wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On Mon, Aug 10, 2015 at 9:37 AM, Ladislav Lhotka = >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On 10 Aug 2015, at 17:32, Andy Bierman = wrote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On Mon, Aug 10, 2015 at 4:24 AM, Ladislav Lhotka = >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> On 10 Aug 2015, at 12:17, Andy Bierman = wrote: >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> I am strongly against changing the contract on = extensions. >>>>>>>>>>>>>>>> They MAY be ignored by any YANG tool. Period. >>>>>>>>>>>>>>>> That means they are far from mandatory. >>>>>>>>>>>>>>>> They are little more than a keyword and a description = clause. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> So do you prefer my proposed solution -02 or -03? >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> ** Solution Yxx-03 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Make extensions optional. This means that extensions = won't be >>>>>>>>>>>>>>> allowed to change YANG language, NETCONF protocol, and = validity of >>>>>>>>>>>>>>> datastores and protocol messages. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> This is how we use extensions to tag YANG data models >>>>>>>>>>>>>>> to drive automation tools. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> But that means, for example, that annotations cannot be = defined via an >>>>>>>>>>>>>> extension statement as in = draft-ietf-netmod-yang-metadata. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Which means these statements should be real instead of = extensions. >>>>>>>>>>>>>> If the statements are defining data that is exchanged = between >>>>>>>>>>>>>> peers in a standard protocol, then YANG extensions are = not >>>>>>>>>>>>>> appropriate. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I agree, and -03 is my preferred solution, too. >>>>>>>>>>>>=20 >>>>>>>>>>>> I strongly disagree. IMO the IETF usage of extensions so = far (NACM, >>>>>>>>>>>> annotations) works well (in the case of NACM proven by = multiple >>>>>>>>>>>> independent implementations), and follows how extensions = were intended >>>>>>>>>>>> to be used, and obviously, how the WG has understood them = up until >>>>>>>>>>>> now. >>>>>>>>>>>>=20 >>>>>>>>>>>> If the sentence: >>>>>>>>>>>>=20 >>>>>>>>>>>> If a YANG compiler does not support a particular extension, = which >>>>>>>>>>>> appears in a YANG module as an unknown-statement (see = Section 12), >>>>>>>>>>>> the entire unknown-statement MAY be ignored by the = compiler. >>>>>>>>>>>>=20 >>>>>>>>>>>> in 6020 can be interpreted to mean that an occurance of an = extension >>>>>>>>>>>> is non-normative, we should fix it so that it matches what = was >>>>>>>>>>>> intended and how it is used. >>>>>>>>>>>>=20 >>>>>>>>>>>> Juergen suggested this replacement text, which I support. = Maybe it >>>>>>>>>>>> can be improved even more. >>>>>>>>>>>>=20 >>>>>>>>>>>> If a YANG parser does not support a particular = extension, which >>>>>>>>>>>> appears in a YANG module as an unknown-statement (see = Section 13), >>>>>>>>>>>> the entire unknown-statement MAY be ignored by the = parser. Note >>>>>>>>>>>> that even in this case the semantics associated with the = extension >>>>>>>>>>>> still apply (as if they were part of a description = statement). >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> I strongly disagree with this change. >>>>>>>>>>> This would mean that every tool is required to support the >>>>>>>>>>> semantics of every extension ever defined. >>>>>>>>>>=20 >>>>>>>>>> No. It means that if a server advertises module that uses = some >>>>>>>>>> extension to define some behaviour, the server supports that >>>>>>>>>> behavior. Just as we expect a server to support the text in >>>>>>>>>> description statements. >>>>>>>>>=20 >>>>>>>>> This is unclear both from the current text and from Juergen's >>>>>>>>> proposal. Maybe I am a nitpicker but assume that either (i) = server >>>>>>>>> implementation is completely generated from the data model, or = (ii) >>>>>>>>> the >>>>>>>>> parser in question is simply in the implementor's head. Then I = don't >>>>>>>>> know how the server can implement the semantics of an = extension if the >>>>>>>>> extension is removed while YANG modules containing it are = being >>>>>>>>> parsed. >>>>>>>>>=20 >>>>>>>>> A text like "a client MAY ignore an extension that it doesn't >>>>>>>>> understand" would be clearer but I don't think it is = acceptable if the >>>>>>>>> extension changes >>>>>>>>>=20 >>>>>>>>> - semantics of YANG, >>>>>>>>=20 >>>>>>>> Agreed. >>>>>>>>=20 >>>>>>>>> - semantics of the protocol, >>>>>>>>=20 >>>>>>>> Maybe... >>>>>>>>=20 >>>>>>>>> - schema of the data model (as annotations do). >>>>>>>>=20 >>>>>>>> I think it is ok to define an annotation with an extension (as = the >>>>>>>> draft does). When designing a feature that is going to use an >>>>>>>> annotation it is important to keep in mind that not all clients = will >>>>>>>> understand the annotation. So e.g. if the new feature is a = "comment", >>>>>>>> the server might just blindly return them to all clients, but = in the >>>>>>>=20 >>>>>>> For a client that doesn=E2=80=99t understand the annotation (or = annotations in >>>>>>> general) it is just extra junk that=E2=80=99s not in the data = model. This is >>>>>>> no different from a new data node type defined through an = extension - >>>>>>> in fact, in JSON encoding annotations are just special object >>>>>>> members. A prudent client may consider such data invalid. >>>>>>>=20 >>>>>>>> case of "inactive", the server must not send these attributes = to a >>>>>>>> client that doesn't ask for them. (You may argue that even for >>>>>>>> comments the client should ask for them, but that is besides = the >>>>>>>> point). >>>>>>>=20 >>>>>>> IMO =E2=80=9Cinactive=E2=80=9D data change the NETCONF/RESTCONF = protocol. If a client >>>>>>> doesn=E2=80=99t see inactive data, it may think it is OK to = write its own >>>>>>> content to that place, which probably shouldn=E2=80=99t be = allowed. >>>>>>>=20 >>>>>>>>=20 >>>>>>>> The bottom line is that you have to be careful when you define = a new >>>>>>>> extension statement. >>>>>>>>=20 >>>>>>>>>> For example, the nacm: extensions do not apply unless = ietf-netconf-acm >>>>>>>>>> is advertised (and nacm is enabled). I expect most = extensions to work >>>>>>>>>> this way. Another example is if we actually defined = i2rs:ephemeral; >>>>>>>>>> this would have no effect unless the "i2rs" capability = (whatever that >>>>>>>>>> is) is also advertised. >>>>>>>>>=20 >>>>>>>>> The nacm: extensions are probably OK because they only give = some >>>>>>>>> additional info about the server behaviour that is independent = of >>>>>>>>> client's support. If the client ignores them, then it may be = just >>>>>>>>> wondering why it cannot read or write some data. >>>>>>>>=20 >>>>>>>> Right. >>>>>>>>=20 >>>>>>>>>> The text also means that it is perfectly ok for a client to = ignore the >>>>>>>>>> extension if it doesn't understand it. For example, if the = client has >>>>>>>>>> no idea what the ephemeral datastore it, it doesn't matter = that a node >>>>>>>>>> is marked with i2rs:ephemeral true. >>>>>>>>>=20 >>>>>>>>> I am not convinced at all about this one. If the server = advertises the >>>>>>>>> "i2rs" capability and modules that use "i2rs:ephemeral" = extension, >>>>>>>>> then >>>>>>>>> a normal NETCONF/RESTCONF client can ignore both (RFC 6241: = "Each peer >>>>>>>>> [...] MUST ignore any capability received from the other peer = that it >>>>>>>>> does not require or does not understand."). Buth what then: = can the >>>>>>>>> client treat nodes tagged with "i2rs:ephemeral" just as = standard >>>>>>>>> nodes? >>>>>>>>=20 >>>>>>>> My idea has been that it would be used as: >>>>>>>>=20 >>>>>>>> leaf my-ephemeral-leaf { >>>>>>>> config false; >>>>>>>> i2rs:ephemeral true; >>>>>>>> ... >>>>>>>> } >>>>>>>>=20 >>>>>>>> which means that if the client doesn't know what to do with >>>>>>>> "i2rs:ephemeral", it will ignore it, as just see this as a = normal >>>>>>>> config false node that can be read with . >>>>>>>=20 >>>>>>> It of course depends on the particular usage rules - I assumed >>>>>>> ephemeral data would be config=3Dtrue. But even in your example, = if >>>>>>> ephemeral data are in a special datastore, they may not be = returned >>>>>>> with , which can again violate the schema. >>>>>>=20 >>>>>> Right, this idea assumes that ephemeral data *is* returned by = . >>>>>>=20 >>>>>>> I think arbitrary extensions are OK if they are used in a = controlled >>>>>>> environment, e.g. in single vendor=E2=80=99s server and client = software, but >>>>>>> in general they can break interoperability unless they are = accompanied >>>>>>> with a bidirectional client-server negotiation mechanism. >>>>>>=20 >>>>>> I agree that it is important to think about protocol negotiation >>>>>> mechanisms, client backwards compatibility etc. when defining >>>>>> extensions. >>>>>=20 >>>>> But even then it might be difficult to handle situations where one >>>>> client supports an extension while another doesn=E2=80=99t - the = server >>>>> simply may not be able to behave simultaneously in two different >>>>> ways. >>>>=20 >>>> But just b/c there are *some* potential extension that would have >>>> problems, does not mean that *all* extensions should be banned. >>>=20 >>> My concern is that vendors might misuse extensions for creating = silos - >>> we all remember browser wars, right? >>>=20 >>> And in the particular case of "annotation", I am not sure whether it = is >>> really OK for a server to advertise an annotation in a module and = then >>> start using it without client's consent. >>>=20 >>>>=20 >>>>> That=E2=80=99s why I think the only option that=E2=80=99s really = safe for now >>>>> is >>>>>=20 >>>>> ** Solution Yxx-03 >>>>>=20 >>>>> Make extensions optional. This means that extensions won't be >>>>> allowed to change YANG language, NETCONF protocol, and validity of >>>>> datastores and protocol messages. >>>>=20 >>>> I think we need explicit text in order to be able to agree on a >>>> solution. >>>=20 >>> Section 6.3.1: >>>=20 >>> OLD >>>=20 >>> If a YANG compiler does not support a particular extension, which >>> appears in a YANG module as an unknown-statement (see Section 12), >>> the entire unknown-statement MAY be ignored by the compiler. >>>=20 >>> NEW >>>=20 >>> Extensions MUST NOT affect the following aspects: >>>=20 >>> o syntax and semantics of YANG language, >>=20 >> I don't know what this means, but it sounds ok=E2=80=A6 >=20 > I think what you mean is =E2=80=9CMUST NOT contradict the syntax = or semantics specified in The Yang Language [RFC Reference]=E2=80=9D Yes. >=20 >>=20 >>> o management protocols such as NETCONF or RESTCONF, >=20 > This is trickier. We are now in agreement that Yang as a = language, is not bound to NETCONF and also RestConf, but it seems the = statement above doesn=E2=80=99t buy into that because its coupling the = three things together. Well, there is still quite a lot of text in 6020bis that has to do with = NETCONF, and some of the existing or proposed extensions clearly affect = the protocol(s). Lada >=20 > =E2=80=94Tom >=20 >=20 >>>=20 >>> o validity of datastores and protocol messages with respect to the >>> data model. >>=20 >> I am not sure I understand these two either. I don't think this is >> needed. It's like if we wrote that the text in description = statements >> MUST NOT "affect management protocols like NETCONF", etc. If someone >> tries to get such an extension standardized, hopefully reviewers will >> catch this. >>=20 >>> A server advertising modules that define and use an extension MUST >>> adhere to the extension's semantics as specified in its definition. >>=20 >> Ok. >>=20 >>> However, clients MAY ignore any or all extensions appearing in >>> modules advertised by the server. >>=20 >> Hmm, I agree with Andy's idea that the definition of an extension >> defines the conformance for the extension. >>=20 >>=20 >>> By the way, due to the adopted solution Y49-04, the second paragraph = in >>> sec. 6.3.1 should also be removed. >>=20 >> I assume you mean the second paragraph of 6.3.1 in RFC 6020? That >> paragraph is already removed in draft-ietf-netmod-rfc6020bis-06. >>=20 >>=20 >> /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 Thu Aug 20 07:47:07 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D47941ACEAD for ; Thu, 20 Aug 2015 07:47:06 -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 F1kFgxPhmA-W for ; Thu, 20 Aug 2015 07:47:05 -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 4271A1A872D for ; Thu, 20 Aug 2015 07:47:05 -0700 (PDT) Received: by lbbtg9 with SMTP id tg9so25481298lbb.1 for ; Thu, 20 Aug 2015 07:47: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=0284aWN3VmWdURbuCyeh1toVGxLrGfkx80dMsQJIWCo=; b=CBMq6hNHHOCzsjx4iLsb9wwPjuSX2YtbM10AuwrbsFEyQcaBQDVCuKgy+rVrvnf4b2 03Ei6ahrpvIjaXMJ/S5NWIuTrGpcEld1k/BDTq7ucLgQFVnMdBPbVUvP2dseyYA30mWO w+7rLQgY5KbofMbujQOK4QzIuEE8vAVSEowmMcITXbUa1VlQ6vgslia09tBcLtkaCFC6 9Wm+J+sdYLwhD4V/LuspG/zcGyD01iBv5w8PqZRQiE4P8xDrDvet26Ww8WAP/rfYp7ud Zf7/RXB+Imx3Fwg7H4HlDyvu5+aGBl2JZLVytmxL9uEWxgcswsQGvwokc6l7izyWRkRF brTQ== X-Gm-Message-State: ALoCoQmfo4KmIQfHbarH+pLoGoVOOGnwOUhzoRT9uqueWSEDjnDAjYRnAh1jCjjK0XXVGcCl9hro MIME-Version: 1.0 X-Received: by 10.152.36.161 with SMTP id r1mr3241630laj.82.1440082023512; Thu, 20 Aug 2015 07:47:03 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Thu, 20 Aug 2015 07:47:03 -0700 (PDT) In-Reply-To: <20150820.152603.242849288817455571.mbj@tail-f.com> References: <3B335831-4C79-4EB4-AC62-EA21D50E5928@nic.cz> <20150820.132857.1812838545863613387.mbj@tail-f.com> <20150820.152603.242849288817455571.mbj@tail-f.com> Date: Thu, 20 Aug 2015 07:47:03 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=089e0158b5e47594cc051dbf3993 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] extensions and conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 14:47:07 -0000 --089e0158b5e47594cc051dbf3993 Content-Type: text/plain; charset=UTF-8 On Thu, Aug 20, 2015 at 6:26 AM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: > > Martin Bjorklund writes: > > > > > Ladislav Lhotka wrote: > > >> > >..... > > However, clients MAY ignore any or all extensions appearing in > > modules advertised by the server. > > Hmm, I agree with Andy's idea that the definition of an extension > defines the conformance for the extension. > > I think this is an important distinction. RFC 6536 says this extension is mandatory for conformance to NACM. RFC 6020 says this extension is optional for conformance to YANG. > > > By the way, due to the adopted solution Y49-04, the second paragraph in > > sec. 6.3.1 should also be removed. > > I assume you mean the second paragraph of 6.3.1 in RFC 6020? That > paragraph is already removed in draft-ietf-netmod-rfc6020bis-06. > > > /martin > Andy --089e0158b5e47594cc051dbf3993 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Aug 20, 2015 at 6:26 AM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Ladislav Lhotka <lhotka@nic.cz> wrote:
> Martin Bjorklund <mbj@tail-f.com<= /a>> writes:
>
> > Ladislav Lhotka <lhotka@nic.c= z> wrote:
> >>
>.....
>=C2=A0 =C2=A0 However, clients MAY ignore any or all extensions appeari= ng in
>=C2=A0 =C2=A0 modules advertised by the server.

Hmm, I agree with Andy's idea that the definition of an extension
defines the conformance for the extension.



I think this is an impo= rtant distinction.
RFC 6536 says this extension is mandatory for = conformance to NACM.
RFC 6020 says this extension is optional for= conformance to YANG.

=C2=A0

> By the way, due to the adopted solution Y49-04, the second paragraph i= n
> sec. 6.3.1 should also be removed.

I assume you mean the second paragraph of 6.3.1 in RFC 6020?=C2=A0 That
paragraph is already removed in draft-ietf-netmod-rfc6020bis-06.


/martin

Andy<= /div>

--089e0158b5e47594cc051dbf3993-- From nobody Thu Aug 20 07:59:02 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4A8D1ACE90 for ; Thu, 20 Aug 2015 07:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.412 X-Spam-Level: X-Spam-Status: No, score=-1.412 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_64=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNJXD-GcidH9 for ; Thu, 20 Aug 2015 07:58:57 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2C6D1A8A62 for ; Thu, 20 Aug 2015 07:58:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1440082678; bh=YzyTrMdVN28poK0M0P5CqmHugKqrfzWEOpaUe4Yo/Ks=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=yCs8bMUBbYcfMC/r1lZSFQSUB5klBa5vbNXgeAQx+wWgM5KpSPKeFLa6wkVsEbHad iO/4UX9z8RSBbgLx22r6mIUls4sFM1qocHAvYb0eqVsk5bqa6L4b4a6HWn+l9J49AZ iAkL6I7US4aMaM2OVOiVT2m+lkggI2JNBPb7JQvU= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Nadeau Thomas In-Reply-To: <6C35E6EB-0BA3-448B-82DD-0AB4CD704AAE@nic.cz> Date: Thu, 20 Aug 2015 10:58:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <14659385-661A-47BA-92DD-130C0768C2C4@lucidvision.com> References: <3B335831-4C79-4EB4-AC62-EA21D50E5928@nic.cz> <20150820.132857.1812838545863613387.mbj@tail-f.com> <20150820.152603.242849288817455571.mbj@tail-f.com> <9AF42DE2-327C-49AB-9947-E725800E618D@lucidvision.com> <6C35E6EB-0BA3-448B-82DD-0AB4CD704AAE@nic.cz> To: Ladislav Lhotka X-Mailer: Apple Mail (2.2104) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-ShareWhite: 50.255.148.181 X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=23 Stars=0 Good=0 Friend=4 Surbl=0 Catch=0 r=0 ip=50.255.148.181 X-IP-stats: Notspam Incoming Last 0, First 97, in=949, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] extensions and conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 14:59:01 -0000 > On Aug 20, 2015:10:30 AM, at 10:30 AM, Ladislav Lhotka = wrote: >=20 >=20 >> On 20 Aug 2015, at 16:00, Nadeau Thomas = wrote: >>=20 >>>=20 >>> On Aug 20, 2015:9:26 AM, at 9:26 AM, Martin Bjorklund = wrote: >>>=20 >>> Ladislav Lhotka wrote: >>>> Martin Bjorklund writes: >>>>=20 >>>>> Ladislav Lhotka wrote: >>>>>>=20 >>>>>>> On 20 Aug 2015, at 13:12, Martin Bjorklund = wrote: >>>>>>>=20 >>>>>>> Ladislav Lhotka wrote: >>>>>>>>=20 >>>>>>>>> On 20 Aug 2015, at 12:37, Martin Bjorklund = wrote: >>>>>>>>>=20 >>>>>>>>> Ladislav Lhotka wrote: >>>>>>>>>> Martin Bjorklund writes: >>>>>>>>>>=20 >>>>>>>>>>> Andy Bierman wrote: >>>>>>>>>>>> On Wed, Aug 19, 2015 at 5:49 AM, Martin Bjorklund = >>>>>>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>> Hi, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> [joining this discussion a bit late] >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Ladislav Lhotka wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On 10 Aug 2015, at 18:46, Andy Bierman = wrote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On Mon, Aug 10, 2015 at 9:37 AM, Ladislav Lhotka = >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> On 10 Aug 2015, at 17:32, Andy Bierman = wrote: >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> On Mon, Aug 10, 2015 at 4:24 AM, Ladislav Lhotka = >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> On 10 Aug 2015, at 12:17, Andy Bierman = wrote: >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> I am strongly against changing the contract on = extensions. >>>>>>>>>>>>>>>>> They MAY be ignored by any YANG tool. Period. >>>>>>>>>>>>>>>>> That means they are far from mandatory. >>>>>>>>>>>>>>>>> They are little more than a keyword and a description = clause. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> So do you prefer my proposed solution -02 or -03? >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> ** Solution Yxx-03 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Make extensions optional. This means that extensions = won't be >>>>>>>>>>>>>>>> allowed to change YANG language, NETCONF protocol, and = validity of >>>>>>>>>>>>>>>> datastores and protocol messages. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> This is how we use extensions to tag YANG data models >>>>>>>>>>>>>>>> to drive automation tools. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> But that means, for example, that annotations cannot be = defined via an >>>>>>>>>>>>>>> extension statement as in = draft-ietf-netmod-yang-metadata. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Which means these statements should be real instead of = extensions. >>>>>>>>>>>>>>> If the statements are defining data that is exchanged = between >>>>>>>>>>>>>>> peers in a standard protocol, then YANG extensions are = not >>>>>>>>>>>>>>> appropriate. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I agree, and -03 is my preferred solution, too. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I strongly disagree. IMO the IETF usage of extensions so = far (NACM, >>>>>>>>>>>>> annotations) works well (in the case of NACM proven by = multiple >>>>>>>>>>>>> independent implementations), and follows how extensions = were intended >>>>>>>>>>>>> to be used, and obviously, how the WG has understood them = up until >>>>>>>>>>>>> now. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> If the sentence: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> If a YANG compiler does not support a particular = extension, which >>>>>>>>>>>>> appears in a YANG module as an unknown-statement (see = Section 12), >>>>>>>>>>>>> the entire unknown-statement MAY be ignored by the = compiler. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> in 6020 can be interpreted to mean that an occurance of an = extension >>>>>>>>>>>>> is non-normative, we should fix it so that it matches what = was >>>>>>>>>>>>> intended and how it is used. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Juergen suggested this replacement text, which I support. = Maybe it >>>>>>>>>>>>> can be improved even more. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> If a YANG parser does not support a particular = extension, which >>>>>>>>>>>>> appears in a YANG module as an unknown-statement (see = Section 13), >>>>>>>>>>>>> the entire unknown-statement MAY be ignored by the = parser. Note >>>>>>>>>>>>> that even in this case the semantics associated with the = extension >>>>>>>>>>>>> still apply (as if they were part of a description = statement). >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> I strongly disagree with this change. >>>>>>>>>>>> This would mean that every tool is required to support the >>>>>>>>>>>> semantics of every extension ever defined. >>>>>>>>>>>=20 >>>>>>>>>>> No. It means that if a server advertises module that uses = some >>>>>>>>>>> extension to define some behaviour, the server supports that >>>>>>>>>>> behavior. Just as we expect a server to support the text in >>>>>>>>>>> description statements. >>>>>>>>>>=20 >>>>>>>>>> This is unclear both from the current text and from Juergen's >>>>>>>>>> proposal. Maybe I am a nitpicker but assume that either (i) = server >>>>>>>>>> implementation is completely generated from the data model, = or (ii) >>>>>>>>>> the >>>>>>>>>> parser in question is simply in the implementor's head. Then = I don't >>>>>>>>>> know how the server can implement the semantics of an = extension if the >>>>>>>>>> extension is removed while YANG modules containing it are = being >>>>>>>>>> parsed. >>>>>>>>>>=20 >>>>>>>>>> A text like "a client MAY ignore an extension that it doesn't >>>>>>>>>> understand" would be clearer but I don't think it is = acceptable if the >>>>>>>>>> extension changes >>>>>>>>>>=20 >>>>>>>>>> - semantics of YANG, >>>>>>>>>=20 >>>>>>>>> Agreed. >>>>>>>>>=20 >>>>>>>>>> - semantics of the protocol, >>>>>>>>>=20 >>>>>>>>> Maybe... >>>>>>>>>=20 >>>>>>>>>> - schema of the data model (as annotations do). >>>>>>>>>=20 >>>>>>>>> I think it is ok to define an annotation with an extension (as = the >>>>>>>>> draft does). When designing a feature that is going to use an >>>>>>>>> annotation it is important to keep in mind that not all = clients will >>>>>>>>> understand the annotation. So e.g. if the new feature is a = "comment", >>>>>>>>> the server might just blindly return them to all clients, but = in the >>>>>>>>=20 >>>>>>>> For a client that doesn=E2=80=99t understand the annotation (or = annotations in >>>>>>>> general) it is just extra junk that=E2=80=99s not in the data = model. This is >>>>>>>> no different from a new data node type defined through an = extension - >>>>>>>> in fact, in JSON encoding annotations are just special object >>>>>>>> members. A prudent client may consider such data invalid. >>>>>>>>=20 >>>>>>>>> case of "inactive", the server must not send these attributes = to a >>>>>>>>> client that doesn't ask for them. (You may argue that even = for >>>>>>>>> comments the client should ask for them, but that is besides = the >>>>>>>>> point). >>>>>>>>=20 >>>>>>>> IMO =E2=80=9Cinactive=E2=80=9D data change the NETCONF/RESTCONF = protocol. If a client >>>>>>>> doesn=E2=80=99t see inactive data, it may think it is OK to = write its own >>>>>>>> content to that place, which probably shouldn=E2=80=99t be = allowed. >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> The bottom line is that you have to be careful when you define = a new >>>>>>>>> extension statement. >>>>>>>>>=20 >>>>>>>>>>> For example, the nacm: extensions do not apply unless = ietf-netconf-acm >>>>>>>>>>> is advertised (and nacm is enabled). I expect most = extensions to work >>>>>>>>>>> this way. Another example is if we actually defined = i2rs:ephemeral; >>>>>>>>>>> this would have no effect unless the "i2rs" capability = (whatever that >>>>>>>>>>> is) is also advertised. >>>>>>>>>>=20 >>>>>>>>>> The nacm: extensions are probably OK because they only give = some >>>>>>>>>> additional info about the server behaviour that is = independent of >>>>>>>>>> client's support. If the client ignores them, then it may be = just >>>>>>>>>> wondering why it cannot read or write some data. >>>>>>>>>=20 >>>>>>>>> Right. >>>>>>>>>=20 >>>>>>>>>>> The text also means that it is perfectly ok for a client to = ignore the >>>>>>>>>>> extension if it doesn't understand it. For example, if the = client has >>>>>>>>>>> no idea what the ephemeral datastore it, it doesn't matter = that a node >>>>>>>>>>> is marked with i2rs:ephemeral true. >>>>>>>>>>=20 >>>>>>>>>> I am not convinced at all about this one. If the server = advertises the >>>>>>>>>> "i2rs" capability and modules that use "i2rs:ephemeral" = extension, >>>>>>>>>> then >>>>>>>>>> a normal NETCONF/RESTCONF client can ignore both (RFC 6241: = "Each peer >>>>>>>>>> [...] MUST ignore any capability received from the other peer = that it >>>>>>>>>> does not require or does not understand."). Buth what then: = can the >>>>>>>>>> client treat nodes tagged with "i2rs:ephemeral" just as = standard >>>>>>>>>> nodes? >>>>>>>>>=20 >>>>>>>>> My idea has been that it would be used as: >>>>>>>>>=20 >>>>>>>>> leaf my-ephemeral-leaf { >>>>>>>>> config false; >>>>>>>>> i2rs:ephemeral true; >>>>>>>>> ... >>>>>>>>> } >>>>>>>>>=20 >>>>>>>>> which means that if the client doesn't know what to do with >>>>>>>>> "i2rs:ephemeral", it will ignore it, as just see this as a = normal >>>>>>>>> config false node that can be read with . >>>>>>>>=20 >>>>>>>> It of course depends on the particular usage rules - I assumed >>>>>>>> ephemeral data would be config=3Dtrue. But even in your = example, if >>>>>>>> ephemeral data are in a special datastore, they may not be = returned >>>>>>>> with , which can again violate the schema. >>>>>>>=20 >>>>>>> Right, this idea assumes that ephemeral data *is* returned by = . >>>>>>>=20 >>>>>>>> I think arbitrary extensions are OK if they are used in a = controlled >>>>>>>> environment, e.g. in single vendor=E2=80=99s server and client = software, but >>>>>>>> in general they can break interoperability unless they are = accompanied >>>>>>>> with a bidirectional client-server negotiation mechanism. >>>>>>>=20 >>>>>>> I agree that it is important to think about protocol negotiation >>>>>>> mechanisms, client backwards compatibility etc. when defining >>>>>>> extensions. >>>>>>=20 >>>>>> But even then it might be difficult to handle situations where = one >>>>>> client supports an extension while another doesn=E2=80=99t - the = server >>>>>> simply may not be able to behave simultaneously in two different >>>>>> ways. >>>>>=20 >>>>> But just b/c there are *some* potential extension that would have >>>>> problems, does not mean that *all* extensions should be banned. >>>>=20 >>>> My concern is that vendors might misuse extensions for creating = silos - >>>> we all remember browser wars, right? >>>>=20 >>>> And in the particular case of "annotation", I am not sure whether = it is >>>> really OK for a server to advertise an annotation in a module and = then >>>> start using it without client's consent. >>>>=20 >>>>>=20 >>>>>> That=E2=80=99s why I think the only option that=E2=80=99s really = safe for now >>>>>> is >>>>>>=20 >>>>>> ** Solution Yxx-03 >>>>>>=20 >>>>>> Make extensions optional. This means that extensions won't be >>>>>> allowed to change YANG language, NETCONF protocol, and validity = of >>>>>> datastores and protocol messages. >>>>>=20 >>>>> I think we need explicit text in order to be able to agree on a >>>>> solution. >>>>=20 >>>> Section 6.3.1: >>>>=20 >>>> OLD >>>>=20 >>>> If a YANG compiler does not support a particular extension, which >>>> appears in a YANG module as an unknown-statement (see Section 12), >>>> the entire unknown-statement MAY be ignored by the compiler. >>>>=20 >>>> NEW >>>>=20 >>>> Extensions MUST NOT affect the following aspects: >>>>=20 >>>> o syntax and semantics of YANG language, >>>=20 >>> I don't know what this means, but it sounds ok=E2=80=A6 >>=20 >> I think what you mean is =E2=80=9CMUST NOT contradict the syntax = or semantics specified in The Yang Language [RFC Reference]=E2=80=9D >=20 > Yes. >=20 >>=20 >>>=20 >>>> o management protocols such as NETCONF or RESTCONF, >>=20 >> This is trickier. We are now in agreement that Yang as a = language, is not bound to NETCONF and also RestConf, but it seems the = statement above doesn=E2=80=99t buy into that because its coupling the = three things together. >=20 > Well, there is still quite a lot of text in 6020bis that has to do = with NETCONF, and some of the existing or proposed extensions clearly = affect the protocol(s). >=20 > Lada Yes, I know. We should think seriously about re-aligning that.=20= =E2=80=94Tom >=20 >>=20 >> =E2=80=94Tom >>=20 >>=20 >>>>=20 >>>> o validity of datastores and protocol messages with respect to the >>>> data model. >>>=20 >>> I am not sure I understand these two either. I don't think this is >>> needed. It's like if we wrote that the text in description = statements >>> MUST NOT "affect management protocols like NETCONF", etc. If = someone >>> tries to get such an extension standardized, hopefully reviewers = will >>> catch this. >>>=20 >>>> A server advertising modules that define and use an extension MUST >>>> adhere to the extension's semantics as specified in its definition. >>>=20 >>> Ok. >>>=20 >>>> However, clients MAY ignore any or all extensions appearing in >>>> modules advertised by the server. >>>=20 >>> Hmm, I agree with Andy's idea that the definition of an extension >>> defines the conformance for the extension. >>>=20 >>>=20 >>>> By the way, due to the adopted solution Y49-04, the second = paragraph in >>>> sec. 6.3.1 should also be removed. >>>=20 >>> I assume you mean the second paragraph of 6.3.1 in RFC 6020? That >>> paragraph is already removed in draft-ietf-netmod-rfc6020bis-06. >>>=20 >>>=20 >>> /martin >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 From nobody Thu Aug 20 08:03:03 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBB021ACEE5 for ; Thu, 20 Aug 2015 08:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.661 X-Spam-Level: X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXW6jnPF3OFB for ; Thu, 20 Aug 2015 08:03:00 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 704B81A88D5 for ; Thu, 20 Aug 2015 08:03:00 -0700 (PDT) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id B6AE2181704; Thu, 20 Aug 2015 17:02:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1440082978; bh=c3qWcPDyJrKmCQ5knVolxL6aT3BWXlUItJOVhRMnxG8=; h=From:Date:To; b=ltH4Lw1MCoYVBwLyxH699pK7PlmK0gSeoZZ3iNeSL4n53srhdtpfVvt724iNq8p9B ni2SnOMBNAVRkL1g/YKHxqYuEHiN4TE9nVCxwQEGs3G9o0BTpYDg1Hu0zB6DYXx//i JAnNgh5eqSuh1RTlVdZPx4B+5PEZs27xPfVKGPM0= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: Date: Thu, 20 Aug 2015 17:02:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <01BB0503-44A6-441B-9168-E5B68B551A61@nic.cz> References: <3B335831-4C79-4EB4-AC62-EA21D50E5928@nic.cz> <20150820.132857.1812838545863613387.mbj@tail-f.com> <20150820.152603.242849288817455571.mbj@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] extensions and conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 15:03:03 -0000 > On 20 Aug 2015, at 16:47, Andy Bierman wrote: >=20 >=20 >=20 > On Thu, Aug 20, 2015 at 6:26 AM, Martin Bjorklund = wrote: > Ladislav Lhotka wrote: > > Martin Bjorklund writes: > > > > > Ladislav Lhotka wrote: > > >> > >..... > > However, clients MAY ignore any or all extensions appearing in > > modules advertised by the server. >=20 > Hmm, I agree with Andy's idea that the definition of an extension > defines the conformance for the extension. >=20 >=20 >=20 > I think this is an important distinction. > RFC 6536 says this extension is mandatory for conformance to NACM. > RFC 6020 says this extension is optional for conformance to YANG. This makes sense, the only problem is that the realm of YANG conformance = is not precisely defined, and involves protocol considerations. For RELAX NG it is much easier because it is a schema language and = nothing else, so schema annotations are deleted early in the validation = procedure. Lada >=20 > =20 >=20 > > By the way, due to the adopted solution Y49-04, the second paragraph = in > > sec. 6.3.1 should also be removed. >=20 > I assume you mean the second paragraph of 6.3.1 in RFC 6020? That > paragraph is already removed in draft-ietf-netmod-rfc6020bis-06. >=20 >=20 > /martin >=20 > Andy >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Aug 20 08:12:13 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62DC51ACEDB for ; Thu, 20 Aug 2015 08:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnaJ52LllxFw for ; Thu, 20 Aug 2015 08:12:09 -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 8DBB71ACED5 for ; Thu, 20 Aug 2015 08:12:09 -0700 (PDT) Received: by lalv9 with SMTP id v9so24502363lal.0 for ; Thu, 20 Aug 2015 08:12:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=JPoZVspih8ApFXx6bPgCgqip4AtWOmajw8wjmDIw7xM=; b=EWgc4gU780IV9R54taAtpMtn1tUpx0kyDJYOxDaUSeqNZAYatzGP9+/l+MiEu0vQ4H ypXIhpNX88V/JitcNcOUVNXOTHDghQQGruhNSNxk/YHmej1Iz7yJJy24SE+BaGOCPbrk GiaextqbOxbKlARB/WkJReEkoZUym/srmJS2acUqELiV0b8Kk4I7bLAORCh7sb15TbtR E6q12S02PqTZErbZdvaT/w52SHu6Ybszhc6f+ffZoti+Akp91jn3YWhEtCsvDn5zV76s BkfwjYTVJVX6x7AoGQ7WVLawqdk6+soiNQ2eBQk34bPtpajSjVQRY7MTJewWiXmY1HUd YRkA== X-Gm-Message-State: ALoCoQlyjxdXKFXX3fT13qrbAQkplvaNU8zf88ooBt06qTT+5m/AMYgCGkgwvZcs7UJtWShZvyD6 MIME-Version: 1.0 X-Received: by 10.152.120.198 with SMTP id le6mr3351855lab.38.1440083527794; Thu, 20 Aug 2015 08:12:07 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Thu, 20 Aug 2015 08:12:07 -0700 (PDT) In-Reply-To: <14659385-661A-47BA-92DD-130C0768C2C4@lucidvision.com> References: <3B335831-4C79-4EB4-AC62-EA21D50E5928@nic.cz> <20150820.132857.1812838545863613387.mbj@tail-f.com> <20150820.152603.242849288817455571.mbj@tail-f.com> <9AF42DE2-327C-49AB-9947-E725800E618D@lucidvision.com> <6C35E6EB-0BA3-448B-82DD-0AB4CD704AAE@nic.cz> <14659385-661A-47BA-92DD-130C0768C2C4@lucidvision.com> Date: Thu, 20 Aug 2015 08:12:07 -0700 Message-ID: From: Andy Bierman To: Nadeau Thomas Content-Type: multipart/alternative; boundary=089e011769051f1b27051dbf93ca Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] extensions and conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 15:12:11 -0000 --089e011769051f1b27051dbf93ca Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Aug 20, 2015 at 7:58 AM, Nadeau Thomas wrote: > > > On Aug 20, 2015:10:30 AM, at 10:30 AM, Ladislav Lhotka > wrote: > > > > > >> On 20 Aug 2015, at 16:00, Nadeau Thomas > wrote: > ..... > >>> > >>>> o management protocols such as NETCONF or RESTCONF, > >> > >> This is trickier. We are now in agreement that Yang as a language= , > is not bound to NETCONF and also RestConf, but it seems the statement abo= ve > doesn=E2=80=99t buy into that because its coupling the three things toget= her. > > > > Well, there is still quite a lot of text in 6020bis that has to do with > NETCONF, and some of the existing or proposed extensions clearly affect t= he > protocol(s). > > > > Lada > > Yes, I know. We should think seriously about re-aligning that. > This is 2 separate issues. There is NETCONF-specific text (e.g. all the insert attributes and how they work in ). Then there is the use of extensions as standard keywords. IMO... If (and only if) the extension can be constrained to extra behavior beyond YANG syntax and semantics, can it be used in an RFC. E.g NACM defines access-control extensions. The routing module could define tags that caused a router to treat a route entry a certain way= . But if the keyword is related to datastores, protocol operations, message encoding, and cannot be constrained to 1 YANG module, then a regular keyword should be used instead. It doesn't save anything to spread keywords around in YANG modules. It makes understanding what is in YANG much more difficult. Since the "ephemeral" keyword applies to datastores and could apply to any YANG module, it clearly is not OK as an extension. > > =E2=80=94Tom > Andy --089e011769051f1b27051dbf93ca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Aug 20, 2015 at 7:58 AM, Nadeau Thomas <tnadeau@lucidvis= ion.com> wrote:

> On Aug 20, 2015:10:30 AM, at 10:30 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
>
>> On 20 Aug 2015, at 16:00, Nadeau Thomas <tnadeau@lucidvision.com> wrote:
.....
>>>
>>>> o management protocols such as NETCONF or RESTCONF,
>>
>>=C2=A0 =C2=A0 =C2=A0 This is trickier. We are now in agreement that= Yang as a language, is not bound to NETCONF and also RestConf, but it seem= s the statement above doesn=E2=80=99t buy into that because its coupling th= e three things together.
>
> Well, there is still quite a lot of text in 6020bis that has to do wit= h NETCONF, and some of the existing or proposed extensions clearly affect t= he protocol(s).
>
> Lada

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yes, I know. We should think seriously about re= -aligning that.


This is = 2 separate issues.
There is NETCONF-specific text (e.g. all the i= nsert attributes and how they
work in <edit-config>).
=

Then there is the use of extensions as standard keyword= s.

IMO...

If (and only if= ) the extension can be constrained to extra behavior beyond
YANG = syntax and semantics, can it be used in an RFC.
E.g NACM defines = access-control extensions. The routing module
could define tags t= hat caused a router to treat a route entry a certain way.

But if the keyword is related to datastores, protocol operations, m= essage encoding,
and cannot be constrained to 1 YANG module, then= a regular keyword
should be used instead.=C2=A0 It doesn't s= ave anything to spread keywords
around in YANG modules.=C2=A0 It = makes understanding what is in YANG much
more difficult.=C2=A0 Si= nce the "ephemeral" keyword applies to datastores
and c= ould apply to any YANG module, it clearly is not OK as an extension.
<= div>


=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=94Tom


Andy
=C2=A0
--089e011769051f1b27051dbf93ca-- From nobody Thu Aug 20 10:50:19 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A01221A1BAA for ; Thu, 20 Aug 2015 10:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4-JS4aaxQoc for ; Thu, 20 Aug 2015 10:50:16 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2D7E81A1ADF for ; Thu, 20 Aug 2015 10:50:16 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 2E1EB1AE035B; Thu, 20 Aug 2015 19:50:14 +0200 (CEST) Date: Thu, 20 Aug 2015 19:50:14 +0200 (CEST) Message-Id: <20150820.195014.935830141166131742.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <01BB0503-44A6-441B-9168-E5B68B551A61@nic.cz> References: <20150820.152603.242849288817455571.mbj@tail-f.com> <01BB0503-44A6-441B-9168-E5B68B551A61@nic.cz> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] extensions and conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 17:50:17 -0000 Ladislav Lhotka wrote: > > > On 20 Aug 2015, at 16:47, Andy Bierman wrote: > > > > > > > > On Thu, Aug 20, 2015 at 6:26 AM, Martin Bjorklund > > wrote: > > Ladislav Lhotka wrote: > > > Martin Bjorklund writes: > > > > > > > Ladislav Lhotka wrote: > > > >> > > >..... > > > However, clients MAY ignore any or all extensions appearing in > > > modules advertised by the server. > > > > Hmm, I agree with Andy's idea that the definition of an extension > > defines the conformance for the extension. > > > > > > > > I think this is an important distinction. > > RFC 6536 says this extension is mandatory for conformance to NACM. > > RFC 6020 says this extension is optional for conformance to YANG. Thanks Andy! This is a nice summary. > This makes sense, the only problem is that the realm of YANG > conformance is not precisely defined, and involves protocol > considerations. Agreed. /martin From nobody Thu Aug 20 14:11:35 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 313E61B29FA for ; Thu, 20 Aug 2015 14:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WawyK18SGrtp for ; Thu, 20 Aug 2015 14:11:32 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD5E1B29AB for ; Thu, 20 Aug 2015 14:11:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Xm295PU01RQ640t+/E2Cf6uvjCtDQz+UTsi/WHyaTfKE961qFZSuEcJY2i4/31L6; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.51] (helo=mswamui-thinleaf.atl.sa.earthlink.net) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1ZSX7N-0006K4-Ah for netmod@ietf.org; Thu, 20 Aug 2015 17:11:25 -0400 Received: from 76.254.49.10 by webmail.earthlink.net with HTTP; Thu, 20 Aug 2015 17:11:24 -0400 Message-ID: <8213705.1440105085122.JavaMail.root@mswamui-thinleaf.atl.sa.earthlink.net> Date: Thu, 20 Aug 2015 14:11:24 -0700 (GMT-07:00) From: Randy Presuhn To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88874d3f0892ff6d3ed239376b28487632c43dd2f1c27e70d50350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.51 Archived-At: Subject: Re: [netmod] extensions and conformance X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 21:11:34 -0000 Hi - >From: Martin Bjorklund >Sent: Aug 19, 2015 11:43 PM >To: randy_presuhn@mindspring.com >Cc: netmod@ietf.org >Subject: Re: [netmod] extensions and conformance > >Randy Presuhn wrote: >> Hi - >> >> >From: Martin Bjorklund >> >Sent: Aug 19, 2015 10:49 AM >> >To: andy@yumaworks.com >> >Cc: netmod@ietf.org >> >Subject: Re: [netmod] extensions and conformance >> ... >> >> > Juergen suggested this replacement text, which I support. Maybe it >> >> > can be improved even more. >> >> > >> >> > If a YANG parser does not support a particular extension, which >> >> > appears in a YANG module as an unknown-statement (see Section 13), >> >> > the entire unknown-statement MAY be ignored by the parser. Note >> >> > that even in this case the semantics associated with the extension >> >> > still apply (as if they were part of a description statement). >> ... >> >No. It means that if a server advertises module that uses some >> >extension to define some behaviour, the server supports that >> >behavior. Just as we expect a server to support the text in >> >description statements. >> >> Sorry, but that interpretation is not supported by the 2119 definition >> of MAY. > >Note that the original text says "if x then MAY y". Juergen's text >says the same. Maybe this should be rephrased... Under the RFC 2119 definition of "MAY", "if x then MAY y" is exactly the same as saying "if x then y is OPTIONAL". It really sounds like you mean to say "if x and z then MUST y", where "z" provides sufficient wiggle to permit situations where the augmentation may be absent for some instances, such as those exhibiting other augmentations. (I'm thinking about what one might see in a system with a bunch of interefaces employing different technologies, but whose management interfaces are all derived from a single abstract class and have various medium- specific extensions.) FWIW there are is another problem with the formulation in question: it's in terms of the capabilities of a particular Yang *parser*, not the client or server in which that parser finds itself. Randy From nobody Fri Aug 21 01:13:41 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE7E31A88ED for ; Fri, 21 Aug 2015 01:13:40 -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 pWgDSWQwWoVW for ; Fri, 21 Aug 2015 01:13:39 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id DEFAC1A88EA for ; Fri, 21 Aug 2015 01:13:38 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 9ED7C1CC012C for ; Fri, 21 Aug 2015 10:13:38 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Fri, 21 Aug 2015 10:13:38 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [netmod] uses under choice X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2015 08:13:40 -0000 Hi, YANG 1.1 will allow 'choice' under 'choice (see issue Y29), but is there any reason for not allowing 'uses' under 'choice'? Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Aug 21 01:18:37 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9EE1A88F7 for ; Fri, 21 Aug 2015 01:18: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 6V-itAV4276h for ; Fri, 21 Aug 2015 01:18:35 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2115F1A88FA for ; Fri, 21 Aug 2015 01:17:59 -0700 (PDT) Received: from localhost (unknown [173.38.220.43]) by mail.tail-f.com (Postfix) with ESMTPSA id 586D31AE097C; Fri, 21 Aug 2015 10:17:57 +0200 (CEST) Date: Fri, 21 Aug 2015 10:17:56 +0200 (CEST) Message-Id: <20150821.101756.1892069606024041047.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] uses under choice X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2015 08:18:36 -0000 Ladislav Lhotka wrote: > Hi, > > YANG 1.1 will allow 'choice' under 'choice (see issue Y29), but is there > any reason for not allowing 'uses' under 'choice'? If you have a grouping with N nodes (N > 1), expanding in directly under a choice would create N cases. Probably not what you wanted. Or did you mean that the case name would be the grouping name? I prefer to leave it as is. /martin From nobody Fri Aug 21 01:27:03 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 468F61A8920 for ; Fri, 21 Aug 2015 01:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.361 X-Spam-Level: X-Spam-Status: No, score=-5.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BD0YisXwltSS for ; Fri, 21 Aug 2015 01:27:00 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED5521A8919 for ; Fri, 21 Aug 2015 01:26:59 -0700 (PDT) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id A829A1810F7; Fri, 21 Aug 2015 10:26:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1440145617; bh=3FFYyaT6h7Eakv97lvrFDIhMGka9F9MeajZrT5PAbJo=; h=From:Date:To; b=xETwI0zQXffQM6VHjlzmJDOCSj/r9Voip1aaZPRF2ypPvn+ntCBIdtA11OPFr5S2c uiH6DSHx4iJIbeownQ1v/GBsf9CMng/sGOilxpHOpVAxF5vG9IDV6gAx9/IJDzfcaJ rDZCU7edknSngP8CRSTLCiU9NgJSOEm6dTvycSDA= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: <20150821.101756.1892069606024041047.mbj@tail-f.com> Date: Fri, 21 Aug 2015 10:26:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2DB7937A-EEB2-4740-97F1-4DA75F9211BB@nic.cz> References: <20150821.101756.1892069606024041047.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] uses under choice X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2015 08:27:01 -0000 > On 21 Aug 2015, at 10:17, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >> Hi, >>=20 >> YANG 1.1 will allow 'choice' under 'choice (see issue Y29), but is = there >> any reason for not allowing 'uses' under 'choice'? >=20 > If you have a grouping with N nodes (N > 1), expanding in directly > under a choice would create N cases. Probably not what you wanted. Why not? One may want to define multiple short cases in the same = grouping. The rules are clear. Currently it is impossible to define multiple cases (short or long) in = one grouping. > Or did you mean that the case name would be the grouping name? No. Lada >=20 > I prefer to leave it as is. >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Aug 21 05:07:51 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E98F1A6EF0 for ; Fri, 21 Aug 2015 05:07:50 -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 53AjvD2gkRtC for ; Fri, 21 Aug 2015 05:07:45 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 758FB1A0127 for ; Fri, 21 Aug 2015 05:07:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5693; q=dns/txt; s=iport; t=1440158866; x=1441368466; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=iPuAGR+LV3B3VguNTdNZ3gVEGuULe9rQZmZQfm+VkOA=; b=YKWBN5Skitl6uPJCVOPKXqmHJcjIuh2PlOpv7MZNfVbJHkXjJw4k+eO9 rFsDL/Pi+aWMn44OUnqd08SrmZfemyvp77l1vjuEsyY5/sIJDkQsY0F5R c8Q8jty8Kk2b94ukKQnYekmpXdzjZ9hiydRUdGrjSpgbBGJwzf0Pf3McP g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CbBAAuFNdV/xbLJq1dhFjFXAKBdREBAQEBAQEBgQqEIwEBAQMBOEABEAsOCgkWDwkDAgECAUUGDQYCAQGIIgjPEgEBAQEBAQEBAQEBAQEBAQEBAQEZi1OEP0sHhCwBBIxliEeMb4FKhyeNZYNpJoN+PTOBByWBIAEBAQ X-IronPort-AV: E=Sophos;i="5.15,721,1432598400"; d="scan'208";a="611088046" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 21 Aug 2015 12:07:44 +0000 Received: from [10.63.23.86] (dhcp-ensft1-uk-vla370-10-63-23-86.cisco.com [10.63.23.86]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t7LC7giM028808; Fri, 21 Aug 2015 12:07:42 GMT To: Martin Bjorklund References: <55D45CAF.2070605@cisco.com> <20150819.132555.871710491924929960.mbj@tail-f.com> <20150820.101533.1535137181522006328.mbj@tail-f.com> From: Robert Wilton Message-ID: <55D7148C.6090508@cisco.com> Date: Fri, 21 Aug 2015 13:07:40 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20150820.101533.1535137181522006328.mbj@tail-f.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Y34 - root node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2015 12:07:50 -0000 Hi Martin, On 20/08/2015 09:15, Martin Bjorklund wrote: > Andy Bierman wrote: >> On Wed, Aug 19, 2015 at 4:25 AM, Martin Bjorklund wrote: >> >>> Robert Wilton wrote: >>>> >>>> On 18/08/2015 18:22, Andy Bierman wrote: >>>>> This is how languages like SMIv2 and YANG work. >>>>> A conceptual object is given a permanent "home" within the tree of >>>>> object identifiers. >>>>> Moving data is very expensive, since any clients working with the old >>>>> data >>>>> will break as soon as the data is moved. >>>>> >>>>> I am not convinced the IETF can or should come up with a set of >>>>> containers >>>>> that covers every possible topic that can be modeled in YANG. >>>> I mostly agree, but having some more structure/advice as to where to >>>> place YANG modules may be helpful. I'm thinking more along the lines >>>> of broad categories rather than precise locations. >>> +1 >>> >>>>> If someone wants to builds a YANG controller node that is managing >>>>> the configuration for a network of devices then wouldn't they want >>>>> a particular device's interface configuration to be located >>>>> somewhere like /network/device//interfaces/interface? >>>>> Ideally, they would be able to use the same YANG definitions that >>>>> are defined for /interfaces/ but root them relative to >>>>> /network/device//. >>>>> >>>>> >>>>> >>>>> Yes -- some of us (like Martin) have pointed this out many times. >>>>> The "device" container on an NE does not help at all wrt/ >>>>> aggregation on a controller. "/device" or "/" work the same for this >>>>> purpose. >>> Actually, I would argue that / works better. On the controller, you >>> probably have a list of devices you control (this is how our NCS >>> works, and how ODL works (I have been told)): >>> >>> container devices { >>> list device { >>> key name; >>> // meta-info about the device goes here, things like >>> // ip-address, port, auth info... >>> container data { >>> // all models supported by the devices are "mounted" here >>> } >>> } >>> } >>> >>> So on the controller, the path to interface "eth0" on device "foo" >>> would be: >>> >>> /devices/device[name='foo']/data/interfaces/interface[name='eth0'] >>> >>> if we also have a top-level "/device" container we'd have: >>> >>> /devices/device[name='foo']/data/device/interfaces/interface[name='eth0'] >>> >>>> What would the real resource location for >>>> "/network/device//interfaces/interface" be? >>> I don't think there is such a thing as a "real" location. The path is >>> scoped in the system you work with; in the controller it might be as I >>> illustrated above, in the device it starts with /interfaces, but in a >>> controller-of-controllers it might be: >>> >>> /domains/domain[name='bar']/devices/device[name='foo']/data >>> /interfaces/interface[name='eth0'] >>> >>> Currently we have a proprietary way of "relocating" YANG modules, and >>> ODL has its "mount", and I think Andy has some other mechanism. Maybe >>> the time has come to standardize how mount works, and maybe then also >>> standardize the list of devices in a controller model. >>> >>> >> +1 >> >> We just need to standardize a "docroot within a docroot". >> This is not relocation of subtrees within the datastore, this is just >> mounting >> a datastore somewhere within a parent datastore. >> >> In YANG validation terms, you simply adjust the docroot to the nested mount >> point, >> and the replicated datastore can be used as if it were stand-alone. >> This would allow any sort of encapsulation of datastores and not add any >> data model complexity to devices which do not have virtual servers >> (most of them). > Compared to the mount draft, I would like to decouple the schema > information from the instance population mechanism. I.e., I'd like a > mechanism that simply defines the schema, not necessarily how the data > is populated (in the mount draft data was fetched from a remote > server, but IMO that is just one of several use cases). Yes, I agree that these could/should be decoupled. Although I note that the mount draft does also allow for local mounts, although this does not seem to be intended to be the mainline case. > > I can think of two ways to do this. > > 1) Your "ycx:root" statement. This is open-ended, so we could do: > > list logical-element { > key name; > leaf name { ... } > yang-root true; > } > > From a schema perspective, any top-level node from any data model > could be used within the logical-element list. > > 2) Cherry-picking: > > list logical-element { > key name; > leaf name { ... } > mount if:interfaces; > mount sys:system; > ... > } I think that that it makes the overall schema more useful if it explicitly states what schema is used for the mounted nodes, although possibly a wildcard mount could still be allowed. I wasn't quite sure how it would work if you wanted to mount a schema that has augmentations. Would you have to list all supported augmentations in the mount point as well? Otherwise you wouldn't know what the full schema is. Thanks, Rob > > Or maybe combine them into one "mount" statement: > > mount *; // allow any top-level node > mount sys:system; // allow this specific top-level node > > > > /martin > > > . > From nobody Fri Aug 21 06:02:08 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4FA1A886E for ; Fri, 21 Aug 2015 06:02:06 -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 pIOH7aUCwOlY for ; Fri, 21 Aug 2015 06:02:01 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 734411A7001 for ; Fri, 21 Aug 2015 06:02:01 -0700 (PDT) Received: from localhost (unknown [173.38.220.43]) by mail.tail-f.com (Postfix) with ESMTPSA id 3F7431AE0703; Fri, 21 Aug 2015 15:01:59 +0200 (CEST) Date: Fri, 21 Aug 2015 15:01:58 +0200 (CEST) Message-Id: <20150821.150158.491063432174006492.mbj@tail-f.com> To: rwilton@cisco.com From: Martin Bjorklund In-Reply-To: <55D7148C.6090508@cisco.com> References: <20150820.101533.1535137181522006328.mbj@tail-f.com> <55D7148C.6090508@cisco.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Y34 - root node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2015 13:02:06 -0000 Robert Wilton wrote: > Hi Martin, > > On 20/08/2015 09:15, Martin Bjorklund wrote: > > Andy Bierman wrote: > >> On Wed, Aug 19, 2015 at 4:25 AM, Martin Bjorklund > >> wrote: > >> > >>> Robert Wilton wrote: > >>>> > >>>> On 18/08/2015 18:22, Andy Bierman wrote: > >>>>> This is how languages like SMIv2 and YANG work. > >>>>> A conceptual object is given a permanent "home" within the tree of > >>>>> object identifiers. > >>>>> Moving data is very expensive, since any clients working with the old > >>>>> data > >>>>> will break as soon as the data is moved. > >>>>> > >>>>> I am not convinced the IETF can or should come up with a set of > >>>>> containers > >>>>> that covers every possible topic that can be modeled in YANG. > >>>> I mostly agree, but having some more structure/advice as to where to > >>>> place YANG modules may be helpful. I'm thinking more along the lines > >>>> of broad categories rather than precise locations. > >>> +1 > >>> > >>>>> If someone wants to builds a YANG controller node that is managing > >>>>> the configuration for a network of devices then wouldn't they want > >>>>> a particular device's interface configuration to be located > >>>>> somewhere like /network/device//interfaces/interface? > >>>>> Ideally, they would be able to use the same YANG definitions that > >>>>> are defined for /interfaces/ but root them relative to > >>>>> /network/device//. > >>>>> > >>>>> > >>>>> > >>>>> Yes -- some of us (like Martin) have pointed this out many times. > >>>>> The "device" container on an NE does not help at all wrt/ > >>>>> aggregation on a controller. "/device" or "/" work the same for this > >>>>> purpose. > >>> Actually, I would argue that / works better. On the controller, you > >>> probably have a list of devices you control (this is how our NCS > >>> works, and how ODL works (I have been told)): > >>> > >>> container devices { > >>> list device { > >>> key name; > >>> // meta-info about the device goes here, things like > >>> // ip-address, port, auth info... > >>> container data { > >>> // all models supported by the devices are "mounted" here > >>> } > >>> } > >>> } > >>> > >>> So on the controller, the path to interface "eth0" on device "foo" > >>> would be: > >>> > >>> /devices/device[name='foo']/data/interfaces/interface[name='eth0'] > >>> > >>> if we also have a top-level "/device" container we'd have: > >>> > >>> /devices/device[name='foo']/data/device/interfaces/interface[name='eth0'] > >>> > >>>> What would the real resource location for > >>>> "/network/device//interfaces/interface" be? > >>> I don't think there is such a thing as a "real" location. The path is > >>> scoped in the system you work with; in the controller it might be as I > >>> illustrated above, in the device it starts with /interfaces, but in a > >>> controller-of-controllers it might be: > >>> > >>> /domains/domain[name='bar']/devices/device[name='foo']/data > >>> /interfaces/interface[name='eth0'] > >>> > >>> Currently we have a proprietary way of "relocating" YANG modules, and > >>> ODL has its "mount", and I think Andy has some other mechanism. Maybe > >>> the time has come to standardize how mount works, and maybe then also > >>> standardize the list of devices in a controller model. > >>> > >>> > >> +1 > >> > >> We just need to standardize a "docroot within a docroot". > >> This is not relocation of subtrees within the datastore, this is just > >> mounting > >> a datastore somewhere within a parent datastore. > >> > >> In YANG validation terms, you simply adjust the docroot to the nested > >> mount > >> point, > >> and the replicated datastore can be used as if it were stand-alone. > >> This would allow any sort of encapsulation of datastores and not add > >> any > >> data model complexity to devices which do not have virtual servers > >> (most of them). > > Compared to the mount draft, I would like to decouple the schema > > information from the instance population mechanism. I.e., I'd like a > > mechanism that simply defines the schema, not necessarily how the data > > is populated (in the mount draft data was fetched from a remote > > server, but IMO that is just one of several use cases). > Yes, I agree that these could/should be decoupled. Although I note > that the mount draft does also allow for local mounts, although this > does not seem to be intended to be the mainline case. > > > > > I can think of two ways to do this. > > > > 1) Your "ycx:root" statement. This is open-ended, so we could do: > > > > list logical-element { > > key name; > > leaf name { ... } > > yang-root true; > > } > > > > From a schema perspective, any top-level node from any data model > > could be used within the logical-element list. > > > > 2) Cherry-picking: > > > > list logical-element { > > key name; > > leaf name { ... } > > mount if:interfaces; > > mount sys:system; > > ... > > } > I think that that it makes the overall schema more useful if it > explicitly states what schema is used for the mounted nodes, although > possibly a wildcard mount could still be allowed. > > I wasn't quite sure how it would work if you wanted to mount a schema > that has augmentations. Would you have to list all supported > augmentations in the mount point as well? Otherwise you wouldn't know > what the full schema is. My idea is that you mount the top-level node, and that means that everything below it is "copied" into the new location. I.e., augmentations to the subtree are also copied. So you would not mount any augmentations (that's why the syntax is mount ). /martin > > Thanks, > Rob > > > > > > Or maybe combine them into one "mount" statement: > > > > mount *; // allow any top-level node > > mount sys:system; // allow this specific top-level node > > > > > > > > /martin > > > > . > > > From nobody Fri Aug 21 06:45:12 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B40C1A904E for ; Fri, 21 Aug 2015 06:45:11 -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 SYcrEa_B3ATM for ; Fri, 21 Aug 2015 06:45:09 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12B5A1A904A for ; Fri, 21 Aug 2015 06:45:08 -0700 (PDT) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 790581812CD; Fri, 21 Aug 2015 15:45:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1440164705; bh=eXKyooB+DBg7aplUUFk9XssSi7ItXhmgCZkhm2r5ey0=; h=From:Date:To; b=Tsrr8xFI2ekQGSXzEOnOhQY2kynGmTmnOFmMI9kBrLdqirNjG+tlba9pnHmzQW2ku UadLISFPynzY8ArTotxJMI3rbNdu5StY2+mfmBSc9aS426FkNp1RR0OJxbS7clSdIG QEzgVgDCiwL4vdqL+pQGuNrpNi7RBIuoVbwrmvtg= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: <20150821.150158.491063432174006492.mbj@tail-f.com> Date: Fri, 21 Aug 2015 15:45:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150820.101533.1535137181522006328.mbj@tail-f.com> <55D7148C.6090508@cisco.com> <20150821.150158.491063432174006492.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Y34 - root node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2015 13:45:11 -0000 > On 21 Aug 2015, at 15:01, Martin Bjorklund wrote: >=20 > Robert Wilton wrote: >> Hi Martin, >>=20 >> On 20/08/2015 09:15, Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> On Wed, Aug 19, 2015 at 4:25 AM, Martin Bjorklund >>>> wrote: >>>>=20 >>>>> Robert Wilton wrote: >>>>>>=20 >>>>>> On 18/08/2015 18:22, Andy Bierman wrote: >>>>>>> This is how languages like SMIv2 and YANG work. >>>>>>> A conceptual object is given a permanent "home" within the tree = of >>>>>>> object identifiers. >>>>>>> Moving data is very expensive, since any clients working with = the old >>>>>>> data >>>>>>> will break as soon as the data is moved. >>>>>>>=20 >>>>>>> I am not convinced the IETF can or should come up with a set of >>>>>>> containers >>>>>>> that covers every possible topic that can be modeled in YANG. >>>>>> I mostly agree, but having some more structure/advice as to where = to >>>>>> place YANG modules may be helpful. I'm thinking more along the = lines >>>>>> of broad categories rather than precise locations. >>>>> +1 >>>>>=20 >>>>>>> If someone wants to builds a YANG controller node that is = managing >>>>>>> the configuration for a network of devices then wouldn't = they want >>>>>>> a particular device's interface configuration to be located >>>>>>> somewhere like = /network/device//interfaces/interface? >>>>>>> Ideally, they would be able to use the same YANG definitions = that >>>>>>> are defined for /interfaces/ but root them relative to >>>>>>> /network/device//. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Yes -- some of us (like Martin) have pointed this out many = times. >>>>>>> The "device" container on an NE does not help at all wrt/ >>>>>>> aggregation on a controller. "/device" or "/" work the same for = this >>>>>>> purpose. >>>>> Actually, I would argue that / works better. On the controller, = you >>>>> probably have a list of devices you control (this is how our NCS >>>>> works, and how ODL works (I have been told)): >>>>>=20 >>>>> container devices { >>>>> list device { >>>>> key name; >>>>> // meta-info about the device goes here, things like >>>>> // ip-address, port, auth info... >>>>> container data { >>>>> // all models supported by the devices are "mounted" here >>>>> } >>>>> } >>>>> } >>>>>=20 >>>>> So on the controller, the path to interface "eth0" on device "foo" >>>>> would be: >>>>>=20 >>>>> = /devices/device[name=3D'foo']/data/interfaces/interface[name=3D'eth0'] >>>>>=20 >>>>> if we also have a top-level "/device" container we'd have: >>>>>=20 >>>>> = /devices/device[name=3D'foo']/data/device/interfaces/interface[name=3D'eth= 0'] >>>>>=20 >>>>>> What would the real resource location for >>>>>> "/network/device//interfaces/interface" be? >>>>> I don't think there is such a thing as a "real" location. The = path is >>>>> scoped in the system you work with; in the controller it might be = as I >>>>> illustrated above, in the device it starts with /interfaces, but = in a >>>>> controller-of-controllers it might be: >>>>>=20 >>>>> /domains/domain[name=3D'bar']/devices/device[name=3D'foo']/data >>>>> /interfaces/interface[name=3D'eth0'] >>>>>=20 >>>>> Currently we have a proprietary way of "relocating" YANG modules, = and >>>>> ODL has its "mount", and I think Andy has some other mechanism. = Maybe >>>>> the time has come to standardize how mount works, and maybe then = also >>>>> standardize the list of devices in a controller model. >>>>>=20 >>>>>=20 >>>> +1 >>>>=20 >>>> We just need to standardize a "docroot within a docroot". >>>> This is not relocation of subtrees within the datastore, this is = just >>>> mounting >>>> a datastore somewhere within a parent datastore. >>>>=20 >>>> In YANG validation terms, you simply adjust the docroot to the = nested >>>> mount >>>> point, >>>> and the replicated datastore can be used as if it were stand-alone. >>>> This would allow any sort of encapsulation of datastores and not = add >>>> any >>>> data model complexity to devices which do not have virtual servers >>>> (most of them). >>> Compared to the mount draft, I would like to decouple the schema >>> information from the instance population mechanism. I.e., I'd like = a >>> mechanism that simply defines the schema, not necessarily how the = data >>> is populated (in the mount draft data was fetched from a remote >>> server, but IMO that is just one of several use cases). >> Yes, I agree that these could/should be decoupled. Although I note >> that the mount draft does also allow for local mounts, although this >> does not seem to be intended to be the mainline case. >>=20 >>>=20 >>> I can think of two ways to do this. >>>=20 >>> 1) Your "ycx:root" statement. This is open-ended, so we could do: >>>=20 >>> list logical-element { >>> key name; >>> leaf name { ... } >>> yang-root true; >>> } >>>=20 >>> =46rom a schema perspective, any top-level node from any data = model >>> could be used within the logical-element list. >>>=20 >>> 2) Cherry-picking: >>>=20 >>> list logical-element { >>> key name; >>> leaf name { ... } >>> mount if:interfaces; >>> mount sys:system; >>> ... >>> } >> I think that that it makes the overall schema more useful if it >> explicitly states what schema is used for the mounted nodes, although >> possibly a wildcard mount could still be allowed. >>=20 >> I wasn't quite sure how it would work if you wanted to mount a schema >> that has augmentations. Would you have to list all supported >> augmentations in the mount point as well? Otherwise you wouldn't = know >> what the full schema is. >=20 > My idea is that you mount the top-level node, and that means that > everything below it is "copied" into the new location. I.e., > augmentations to the subtree are also copied. So you would not mount > any augmentations (that's why the syntax is mount ). But what about normal modules that refer to nodes in the mounted module? = Their XPath expressions and leafrefs would be incorrect. I think they must be mounted to the same root, too. Lada >=20 >=20 > /martin >=20 >=20 >=20 >>=20 >> Thanks, >> Rob >>=20 >>=20 >>>=20 >>> Or maybe combine them into one "mount" statement: >>>=20 >>> mount *; // allow any top-level node >>> mount sys:system; // allow this specific top-level node >>>=20 >>>=20 >>>=20 >>> /martin >>>=20 >>> . >>>=20 >>=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Aug 21 07:27:46 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5D01A923A for ; Fri, 21 Aug 2015 07:27:44 -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_34=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 aPW1hJR2d0DA for ; Fri, 21 Aug 2015 07:27:42 -0700 (PDT) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C32F1A9237 for ; Fri, 21 Aug 2015 07:27:41 -0700 (PDT) Received: by lbbtg9 with SMTP id tg9so44936263lbb.1 for ; Fri, 21 Aug 2015 07:27: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=09xJf+p5Dq0XywSFVPGkZpTU80pXi3ukZzlsOlT9UNI=; b=hrwh6sTFJMnixxsA5ZRTykz0VPGkiq18LE5jy78iOTJ8KBagokBWNaK2CRQWMiuv9m seCdg65abBX8XAlByuQ72F0VCwNQiKF4M9vmD5/4Y0BqWTxHz2BNtCMyzylvbBidPc1D w0t4c3y8mJ/Q7U7G/JHHegY3w8+FKdhxsmvB5PLhR+E96jEffCNJLe8nXXlZc8mI227v u75Hu5igARVyn6rWXPMj3lOcDQJk7+QyTpmJqYQ8XB6WZA4oaMntt5rt3UGDez5we8Ay qeHxs0/W68M29ZV8qwI1Fu9SnEOCrJKuyySbUlpn5R9tzmtoshj1Gv70AOwdABtaAXmg MCSw== X-Gm-Message-State: ALoCoQnsDwBsewQ5rdHzg2ksb1FjRzOoCI05BHiv/CIWnkmf65SNZuieVOSngHr2y/ENoIZNviNh MIME-Version: 1.0 X-Received: by 10.112.163.72 with SMTP id yg8mr8050089lbb.82.1440167259841; Fri, 21 Aug 2015 07:27:39 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Fri, 21 Aug 2015 07:27:39 -0700 (PDT) In-Reply-To: <20150821.150158.491063432174006492.mbj@tail-f.com> References: <20150820.101533.1535137181522006328.mbj@tail-f.com> <55D7148C.6090508@cisco.com> <20150821.150158.491063432174006492.mbj@tail-f.com> Date: Fri, 21 Aug 2015 07:27:39 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=089e0118366cf0bd75051dd311df Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y34 - root node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2015 14:27:44 -0000 --089e0118366cf0bd75051dd311df Content-Type: text/plain; charset=UTF-8 On Fri, Aug 21, 2015 at 6:01 AM, Martin Bjorklund wrote: > Robert Wilton wrote: > > Hi Martin, > > > > On 20/08/2015 09:15, Martin Bjorklund wrote: > > > Andy Bierman wrote: > > >> On Wed, Aug 19, 2015 at 4:25 AM, Martin Bjorklund > > >> wrote: > > >> > > >>> Robert Wilton wrote: > > >>>> > > >>>> On 18/08/2015 18:22, Andy Bierman wrote: > > >>>>> This is how languages like SMIv2 and YANG work. > > >>>>> A conceptual object is given a permanent "home" within the tree of > > >>>>> object identifiers. > > >>>>> Moving data is very expensive, since any clients working with the > old > > >>>>> data > > >>>>> will break as soon as the data is moved. > > >>>>> > > >>>>> I am not convinced the IETF can or should come up with a set of > > >>>>> containers > > >>>>> that covers every possible topic that can be modeled in YANG. > > >>>> I mostly agree, but having some more structure/advice as to where to > > >>>> place YANG modules may be helpful. I'm thinking more along the > lines > > >>>> of broad categories rather than precise locations. > > >>> +1 > > >>> > > >>>>> If someone wants to builds a YANG controller node that is > managing > > >>>>> the configuration for a network of devices then wouldn't they > want > > >>>>> a particular device's interface configuration to be located > > >>>>> somewhere like > /network/device//interfaces/interface? > > >>>>> Ideally, they would be able to use the same YANG definitions > that > > >>>>> are defined for /interfaces/ but root them relative to > > >>>>> /network/device//. > > >>>>> > > >>>>> > > >>>>> > > >>>>> Yes -- some of us (like Martin) have pointed this out many times. > > >>>>> The "device" container on an NE does not help at all wrt/ > > >>>>> aggregation on a controller. "/device" or "/" work the same for > this > > >>>>> purpose. > > >>> Actually, I would argue that / works better. On the controller, you > > >>> probably have a list of devices you control (this is how our NCS > > >>> works, and how ODL works (I have been told)): > > >>> > > >>> container devices { > > >>> list device { > > >>> key name; > > >>> // meta-info about the device goes here, things like > > >>> // ip-address, port, auth info... > > >>> container data { > > >>> // all models supported by the devices are "mounted" here > > >>> } > > >>> } > > >>> } > > >>> > > >>> So on the controller, the path to interface "eth0" on device "foo" > > >>> would be: > > >>> > > >>> /devices/device[name='foo']/data/interfaces/interface[name='eth0'] > > >>> > > >>> if we also have a top-level "/device" container we'd have: > > >>> > > >>> > /devices/device[name='foo']/data/device/interfaces/interface[name='eth0'] > > >>> > > >>>> What would the real resource location for > > >>>> "/network/device//interfaces/interface" be? > > >>> I don't think there is such a thing as a "real" location. The path > is > > >>> scoped in the system you work with; in the controller it might be as > I > > >>> illustrated above, in the device it starts with /interfaces, but in a > > >>> controller-of-controllers it might be: > > >>> > > >>> /domains/domain[name='bar']/devices/device[name='foo']/data > > >>> /interfaces/interface[name='eth0'] > > >>> > > >>> Currently we have a proprietary way of "relocating" YANG modules, and > > >>> ODL has its "mount", and I think Andy has some other mechanism. > Maybe > > >>> the time has come to standardize how mount works, and maybe then also > > >>> standardize the list of devices in a controller model. > > >>> > > >>> > > >> +1 > > >> > > >> We just need to standardize a "docroot within a docroot". > > >> This is not relocation of subtrees within the datastore, this is just > > >> mounting > > >> a datastore somewhere within a parent datastore. > > >> > > >> In YANG validation terms, you simply adjust the docroot to the nested > > >> mount > > >> point, > > >> and the replicated datastore can be used as if it were stand-alone. > > >> This would allow any sort of encapsulation of datastores and not add > > >> any > > >> data model complexity to devices which do not have virtual servers > > >> (most of them). > > > Compared to the mount draft, I would like to decouple the schema > > > information from the instance population mechanism. I.e., I'd like a > > > mechanism that simply defines the schema, not necessarily how the data > > > is populated (in the mount draft data was fetched from a remote > > > server, but IMO that is just one of several use cases). > > Yes, I agree that these could/should be decoupled. Although I note > > that the mount draft does also allow for local mounts, although this > > does not seem to be intended to be the mainline case. > > > > > > > > I can think of two ways to do this. > > > > > > 1) Your "ycx:root" statement. This is open-ended, so we could do: > > > > > > list logical-element { > > > key name; > > > leaf name { ... } > > > yang-root true; > > > } > > > > > > From a schema perspective, any top-level node from any data model > > > could be used within the logical-element list. > > > > > > 2) Cherry-picking: > > > > > > list logical-element { > > > key name; > > > leaf name { ... } > > > mount if:interfaces; > > > mount sys:system; > > > ... > > > } > > I think that that it makes the overall schema more useful if it > > explicitly states what schema is used for the mounted nodes, although > > possibly a wildcard mount could still be allowed. > > > > I wasn't quite sure how it would work if you wanted to mount a schema > > that has augmentations. Would you have to list all supported > > augmentations in the mount point as well? Otherwise you wouldn't know > > what the full schema is. > > My idea is that you mount the top-level node, and that means that > everything below it is "copied" into the new location. I.e., > augmentations to the subtree are also copied. So you would not mount > any augmentations (that's why the syntax is mount ). > > > I am only interested in (1) ncx:root approach because this actually works. Cherry-picking does not work well because (a) subtrees are allowed to have constraints on data outside that subtree (b) YANG XPath cannot be safely relocated up or down (i.e., move /interfaces to /device/interfaces or move /foo/bar/baz to /foo2/baz /martin > Andy > > > > > > Thanks, > > Rob > > > > > > > > > > Or maybe combine them into one "mount" statement: > > > > > > mount *; // allow any top-level node > > > mount sys:system; // allow this specific top-level node > > > > > > > > > > > > /martin > > > > > > . > > > > > > --089e0118366cf0bd75051dd311df Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Aug 21, 2015 at 6:01 AM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Robert Wilton <rwilton@cisco.com> wrote:
> Hi Martin,
>
> On 20/08/2015 09:15, Martin Bjorklund wrote:
> > Andy Bierman <andy@yumaw= orks.com> wrote:
> >> On Wed, Aug 19, 2015 at 4:25 AM, Martin Bjorklund <mbj@tail-f.com>
> >> wrote:
> >>
> >>> Robert Wilton <rw= ilton@cisco.com> wrote:
> >>>>
> >>>> On 18/08/2015 18:22, Andy Bierman wrote:
> >>>>> This is how languages like SMIv2 and YANG work. > >>>>> A conceptual object is given a permanent "ho= me" within the tree of
> >>>>> object identifiers.
> >>>>> Moving data is very expensive, since any clients = working with the old
> >>>>> data
> >>>>> will break as soon as the data is moved.
> >>>>>
> >>>>>=C2=A0 =C2=A0I am not convinced the IETF can or sh= ould come up with a set of
> >>>>>=C2=A0 =C2=A0containers
> >>>>> that covers every possible topic that can be mode= led in YANG.
> >>>> I mostly agree, but having some more structure/advice= as to where to
> >>>> place YANG modules may be helpful.=C2=A0 I'm thin= king more along the lines
> >>>> of broad categories rather than precise locations. > >>> +1
> >>>
> >>>>>=C2=A0 =C2=A0 =C2=A0 If someone wants to builds a = YANG controller node that is managing
> >>>>>=C2=A0 =C2=A0 =C2=A0 the configuration for a netwo= rk of devices then wouldn't they want
> >>>>>=C2=A0 =C2=A0 =C2=A0 a particular device's int= erface configuration to be located
> >>>>>=C2=A0 =C2=A0 =C2=A0 somewhere like /network/devic= e/<device-name>/interfaces/interface?
> >>>>>=C2=A0 =C2=A0 =C2=A0 Ideally, they would be able t= o use the same YANG definitions that
> >>>>>=C2=A0 =C2=A0 =C2=A0 are defined for /interfaces/ = but root them relative to
> >>>>>=C2=A0 =C2=A0 =C2=A0 /network/device/<device-na= me>/.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Yes -- some of us (like Martin) have pointed this= out many times.
> >>>>> The "device" container on an NE does no= t help at all wrt/
> >>>>> aggregation on a controller. "/device" = or "/" work the same for this
> >>>>> purpose.
> >>> Actually, I would argue that / works better.=C2=A0 On the= controller, you
> >>> probably have a list of devices you control (this is how = our NCS
> >>> works, and how ODL works (I have been told)):
> >>>
> >>>=C2=A0 =C2=A0 container devices {
> >>>=C2=A0 =C2=A0 =C2=A0 list device {
> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 key name;
> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 // meta-info about the device = goes here, things like
> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 // ip-address, port, auth info= ...
> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 container data {
> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // all models supported= by the devices are "mounted" here
> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> >>>=C2=A0 =C2=A0 =C2=A0 }
> >>>=C2=A0 =C2=A0 }
> >>>
> >>> So on the controller, the path to interface "eth0&qu= ot; on device "foo"
> >>> would be:
> >>>
> >>>=C2=A0 =C2=A0 /devices/device[name=3D'foo']/data/i= nterfaces/interface[name=3D'eth0']
> >>>
> >>> if we also have a top-level "/device" container= we'd have:
> >>>
> >>>=C2=A0 =C2=A0 /devices/device[name=3D'foo']/data/d= evice/interfaces/interface[name=3D'eth0']
> >>>
> >>>> What would the real resource location for
> >>>> "/network/device/<device-name>/interfaces/= interface" be?
> >>> I don't think there is such a thing as a "real&q= uot; location.=C2=A0 The path is
> >>> scoped in the system you work with; in the controller it = might be as I
> >>> illustrated above, in the device it starts with /interfac= es, but in a
> >>> controller-of-controllers it might be:
> >>>
> >>>=C2=A0 =C2=A0 /domains/domain[name=3D'bar']/device= s/device[name=3D'foo']/data
> >>>=C2=A0 =C2=A0 =C2=A0 /interfaces/interface[name=3D'eth= 0']
> >>>
> >>> Currently we have a proprietary way of "relocating&q= uot; YANG modules, and
> >>> ODL has its "mount", and I think Andy has some = other mechanism.=C2=A0 Maybe
> >>> the time has come to standardize how mount works, and may= be then also
> >>> standardize the list of devices in a controller model. > >>>
> >>>
> >> +1
> >>
> >> We just need to standardize a "docroot within a docroot&= quot;.
> >> This is not relocation of subtrees within the datastore, this= is just
> >> mounting
> >> a datastore somewhere within a parent datastore.
> >>
> >> In YANG validation terms, you simply adjust the docroot to th= e nested
> >> mount
> >> point,
> >> and the replicated datastore can be used as if it were stand-= alone.
> >> This would allow any sort of encapsulation of datastores and = not add
> >> any
> >> data model complexity to devices which do not have virtual se= rvers
> >> (most of them).
> > Compared to the mount draft, I would like to decouple the schema<= br> > > information from the instance population mechanism.=C2=A0 I.e., I= 'd like a
> > mechanism that simply defines the schema, not necessarily how the= data
> > is populated (in the mount draft data was fetched from a remote > > server, but IMO that is just one of several use cases).
> Yes, I agree that these could/should be decoupled.=C2=A0 Although I no= te
> that the mount draft does also allow for local mounts, although this > does not seem to be intended to be the mainline case.
>
> >
> > I can think of two ways to do this.
> >
> > 1)=C2=A0 Your "ycx:root" statement.=C2=A0 This is open-= ended, so we could do:
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 list logical-element {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 key name;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf name { ... }
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang-root true;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> >
> >=C2=A0 =C2=A0 =C2=A0 From a schema perspective, any top-level node= from any data model
> >=C2=A0 =C2=A0 =C2=A0 could be used within the logical-element list= .
> >
> > 2)=C2=A0 Cherry-picking:
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 list logical-element {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 key name;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf name { ... }
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mount if:interfaces;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mount sys:system;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> I think that that it makes the overall schema more useful if it
> explicitly states what schema is used for the mounted nodes, although<= br> > possibly a wildcard mount could still be allowed.
>
> I wasn't quite sure how it would work if you wanted to mount a sch= ema
> that has augmentations.=C2=A0 Would you have to list all supported
> augmentations in the mount point as well?=C2=A0 Otherwise you wouldn&#= 39;t know
> what the full schema is.

My idea is that you mount the top-level node, and that means that
everything below it is "copied" into the new location.=C2=A0 I.e.= ,
augmentations to the subtree are also copied.=C2=A0 So you would not mount<= br> any augmentations (that's why the syntax is mount <top-level-node>= ;).



I am only interested in (1) ncx:root a= pproach because this actually works.

Cherry-pickin= g does not work well because
=C2=A0 =C2=A0(a) subtrees are allowe= d to have constraints on data outside that subtree
=C2=A0 =C2=A0(= b) YANG XPath cannot be safely relocated up or down (i.e., move /interfaces= to
=C2=A0 =C2=A0/device/interfaces or move /foo/bar/baz to /foo2= /baz


/martin

=C2=A0
Andy




>
> Thanks,
> Rob
>
>
> >
> > Or maybe combine them into one "mount" statement:
> >
> >=C2=A0 =C2=A0 =C2=A0mount *;=C2=A0 // allow any top-level node
> >=C2=A0 =C2=A0 =C2=A0mount sys:system; // allow this specific top-l= evel node
> >
> >
> >
> > /martin
> >
> >=C2=A0 =C2=A0 =C2=A0.
> >
>

--089e0118366cf0bd75051dd311df-- From mciglan@cisco.com Fri Aug 21 07:25:42 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8FEF1A9232 for ; Fri, 21 Aug 2015 07:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fW4Yk7v7pJnK for ; Fri, 21 Aug 2015 07:25:41 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A58091A9177 for ; Fri, 21 Aug 2015 07:25:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=403; q=dns/txt; s=iport; t=1440167141; x=1441376741; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=2TVONwFRkVQzfnYC3aJcQWG5nLtcRp+NS9dm9wUEpz4=; b=Up+li/Gd74fGzitnDbtBZ51rm9l0K1d4PX4tJPRIVweyGiLkL+478ZTt RFsoeZ3Y2VvIZIw+07mmPaDKxF14jsUTz+D7MtYPelSAc0equFlQYDQfA 2qVD1tUK4xXVdcgcW8xgVghR9O7sszmGe8Kl+VSvdIjtceV+BrzVXC4Rn o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CCAgCoM9dV/51dJa1dgxuBQ71bAQmHaQkCgTE4FAEBAQEBAQF/C4QlAQQ6UQEqFC8TJgEEG4gmqRWlfgEBAQcBAQEBAR2QLYNQgRQFlS0BC4xkmkQmg32COYEEAQEB X-IronPort-AV: E=Sophos;i="5.15,722,1432598400"; d="scan'208";a="180832908" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP; 21 Aug 2015 14:25:40 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t7LEPees020962 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 21 Aug 2015 14:25:41 GMT Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 21 Aug 2015 09:25:40 -0500 Received: from xhc-rcd-x10.cisco.com (173.37.183.84) by xch-aln-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Fri, 21 Aug 2015 09:25:40 -0500 Received: from xmb-aln-x03.cisco.com ([169.254.6.3]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0248.002; Fri, 21 Aug 2015 09:25:40 -0500 From: "Martin Ciglan -X (mciglan - PANTHEON TECHNOLOGIES at Cisco)" To: "netmod@ietf.org" Thread-Topic: issue & question: yang submodule contains newer revision than parent module Thread-Index: AdDcHUDJBbqwnHHhQYyfH8fdk7TSCg== Date: Fri, 21 Aug 2015 14:25:39 +0000 Message-ID: Accept-Language: sk-SK, en-US Content-Language: sk-SK X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.36.7.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Fri, 21 Aug 2015 09:04:16 -0700 Subject: [netmod] issue & question: yang submodule contains newer revision than parent module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2015 14:26:50 -0000 Hello I'm dealing with issue where one yang module includes many yang submodules. My question is if one of submodules gets updated with newer revision than p= arent module, does parent module needs to be updated too?=20 Is this mandatory? If parent module doesn't get updated, can we consider this as invalid set o= f yangs? Thank you in advance Best Regards Martin= From nobody Sun Aug 23 05:39:31 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 888BC1A1A66 for ; Sun, 23 Aug 2015 05:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.51 X-Spam-Level: X-Spam-Status: No, score=-3.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_INVITATION=-2, 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 3v0cEZ8etfMy for ; Sun, 23 Aug 2015 05:39:29 -0700 (PDT) Received: from sjmda12.webex.com (sjmda12.webex.com [64.68.124.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25D461A1A64 for ; Sun, 23 Aug 2015 05:39:29 -0700 (PDT) Received: from jva2tc111.webex.com (sjc02-wxp00-lbace03-core-vl120-np10b-5.webex.com [64.68.121.240]) by sjmda12.webex.com (Postfix) with ESMTP id B09502A2D for ; Sun, 23 Aug 2015 12:39:28 +0000 (GMT) Received: from jva2tc111.webex.com (localhost [127.0.0.1]) by jva2tc111.webex.com (Postfix) with ESMTP id 6A2CC1BF23D for ; Sun, 23 Aug 2015 12:39:28 +0000 (GMT) Date: Sun, 23 Aug 2015 12:39:28 +0000 (GMT) From: NETMOD Working Group To: netmod@ietf.org Message-ID: <1359891143.10826.1440333568433.JavaMail.nobody@jva2tc111.webex.com> MIME-Version: 1.0 Content-Type: multipart/Mixed; boundary="----=_Part_10824_1130885396.1440333568432" X-Priority: 3 Importance: normal Archived-At: Subject: [netmod] WebEx meeting invitation: NETMOD YANG 1.1 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: netmod-chairs@tools.ietf.org List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Aug 2015 12:39:30 -0000 ------=_Part_10824_1130885396.1440333568432 Content-Type: multipart/Alternative; boundary="----=_Part_10825_1560574622.1440333568432" ------=_Part_10825_1560574622.1440333568432 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: base64 CkhlbGxvLAoKTkVUTU9EIFdvcmtpbmcgR3JvdXAgaW52aXRlcyB5b3UgdG8gam9pbiB0aGlzIFdl YkV4IG1lZXRpbmcuCgoKTkVUTU9EIFlBTkcgMS4xCk1vbmRheSwgQXVndXN0IDI0LCAyMDE1CjU6 MDAgcG0gIHwgIEV1cm9wZSBTdW1tZXIgVGltZSAoQmVybGluLCBHTVQrMDI6MDApICB8ICAxIGhy CgoKSk9JTiBXRUJFWCBNRUVUSU5HCmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9N VElEPW1hNDZhYmM5ZDUyN2IyZGQzODUyNmY3ZDgwZDM3ZmMzNgpNZWV0aW5nIG51bWJlcjogNjQ3 IDYxNSA3NzgKTWVldGluZyBwYXNzd29yZDogY2hvb0ppejYKCg0KSk9JTiBCWSBQSE9ORQ0KMS04 NzctNjY4LTQ0OTMgQ2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChVUy9DYW5hZGEpIAoxLTY1MC00 NzktMzIwOCBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpCkFjY2VzcyBjb2RlOiA2NDcg NjE1IDc3OAoKVG9sbC1mcmVlIGRpYWxpbmcgcmVzdHJpY3Rpb25zOiAKaHR0cDovL3d3dy53ZWJl eC5jb20vcGRmL3RvbGxmcmVlX3Jlc3RyaWN0aW9ucy5wZGYNCg0KCkFkZCB0aGlzIG1lZXRpbmcg dG8geW91ciBjYWxlbmRhcjoKaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9 bWUyYjE1ZDI0OWQ1YTgwOTg3ODkzZTdlMjI5ZDM0NGFlDQoNCgpDYW4ndCBqb2luIHRoZSBtZWV0 aW5nPyBDb250YWN0IHN1cHBvcnQgaGVyZToKaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL21j CgoKSU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZpY2Ug YWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lv biB0byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1h dHRlci4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQg dG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3Jk ZWQsIGRpc2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRo ZSBzZXNzaW9uLgo= ------=_Part_10825_1560574622.1440333568432 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPjxtZXRhIG5hbWU9InZpZXdwb3J0IiBjb250ZW50PSJ3aWR0aD1kZXZpY2Utd2lk dGgsIGluaXRpYWwtc2NhbGU9MSIgLz48Ym9keT48c3R5bGUgdHlwZT0idGV4dC9jc3MiPgpkaXYs cCx0ZCxzcGFuIHt3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7d29yZC1icmVhazogbm9ybWFsO30KCnRh YmxlIHtib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyBib3JkZXI6IDA7Ym9yZGVyLXNwYWNpbmc6 IDA7Ym9yZGVyLWNvbG9yOiB3aGl0ZTsgd2lkdGg6MTAwJSFpbXBvcnRhbnQ7d2lkdGg6NTI1cHg7 IG1heC13aWR0aDo1MjVweCFpbXBvcnRhbnQ7IG1pbi13aWR0aDogMjc5cHghaW1wb3J0YW50O30K dHIge2xpbmUtaGVpZ2h0OiAyMHB4O30KCnRkLGEge2ZvbnQtc2l6ZTogMTVweDtmb250LWZhbWls eTogQXJpYWw7Y29sb3I6ICM2NjY2NjY7cGFkZGluZzowO30KPC9zdHlsZT4KCjx0YWJsZSBzdHls ZT0icGFkZGluZzowOyBtYXJnaW46MCIgd2lkdGg9IjEwMCUiIGFsaWduPSJsZWZ0Ij4KICAgPHRy PgogICAgICA8dGQgc3R5bGU9InBhZGRpbmctdG9wOjVweDsiPgogICAgICAgIDx0YWJsZSBzdHls ZT0id2lkdGg6IDUyNXB4O21hcmdpbi1sZWZ0OjVweCIgYWxpZ249ImxlZnQiPgoJCQk8dHI+CgkJ CQk8dGQgdmFsaWduPSJ0b3AiPgoKPHRhYmxlPgogICAgICAgPHRyPgogICAgICAgICAgPHRkIHN0 eWxlPSJmb250LXNpemU6IDE1cHg7Zm9udC1mYW1pbHk6IEFyaWFsO2NvbG9yOiM0RDRENEQiPgog ICAgICAgICAgICAgSGVsbG8sCiAgICAgICAgICA8L3RkPgogICAgICAgPC90cj4KICAgICAgIDx0 cj4KICAgICAgICAgICA8dGQgc3R5bGU9ImZvbnQtc2l6ZTogMTVweDtmb250LWZhbWlseTogQXJp YWw7Y29sb3I6IzRENEQ0RDtwYWRkaW5nLXRvcDoxMHB4OyI+CiAgICAgICAgICAgICAgICBORVRN T0QgV29ya2luZyBHcm91cCBpbnZpdGVzIHlvdSB0byBqb2luIHRoaXMgV2ViRXggbWVldGluZy4K ICAgICAgICAgICAgICAgIAkgICAgICAgICAgIDwvdGQ+CiAgICAgIDwvdHI+CjwvdGFibGU+CgoK Cgo8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0 OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPgoJCQkJCQk8dGFibGUgIHdpZHRoPSIxMDAl Ij4KCQkJCQkJCTx0cj4KCQkJCQkJCQk8dGQgc3R5bGU9ImZvbnQtc2l6ZToxNnB4OyBjb2xvcjoj NEQ0RDREIj4KCQkJCQkJCQkJPGI+TkVUTU9EIFlBTkcgMS4xPC9iPgoJCQkJCQkJCTwvdGQ+CgkJ CQkJCQk8L3RyPgoJCQkJCQkJPHRyIHN0eWxlPSJtYXJnaW46MHB4Ij4KCQkJCQkJCQk8dGQ+TW9u ZGF5LCBBdWd1c3QgMjQsIDIwMTUKCQkJCQkJCQk8L3RkPgoJCQkJCQkJPC90cj4KCQkJCQkJCTx0 ciBzdHlsZT0ibWFyZ2luOjBweCI+CgkJCQkJCQkJPHRkPjU6MDAgcG0mbmJzcDsmbmJzcDt8Jm5i c3A7Jm5ic3A7RXVyb3BlIFN1bW1lciBUaW1lIChCZXJsaW4sIEdNVCswMjowMCkmbmJzcDsmbmJz cDt8Jm5ic3A7Jm5ic3A7MSBocgoJCQkJCQkJCTwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJCQk8L3Rh YmxlPgoKPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9Imhl aWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KCQkJCQkJPHRhYmxlIHN0eWxlPSJ3 aWR0aDphdXRvOyB3aWR0aDphdXRvIWltcG9ydGFudCI+CgkJCQkJCQk8dHI+CgkJCQkJCQkJPHRk IHN0eWxlPSJjb2xvcjojMDBBRkY5O2ZvbnQtc2l6ZToxNnB4Ij4KCQkJCQkJCQkJPGEgaHJlZj0i aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bWE0NmFiYzlkNTI3YjJkZDM4 NTI2ZjdkODBkMzdmYzM2IgoJCQkJCQkJCQkJc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2Zv bnQtc2l6ZToxNnB4O2NvbG9yOiMwMEFGRjkiPgoJCQkJCQkJCQkJPGI+Sm9pbiBXZWJFeCBtZWV0 aW5nPC9iPgoJCQkJCQkJCQk8L2E+CgkJCQkJCQkJPC90ZD4KCQkJCQkJCTwvdHI+CgkJCQkJCTwv dGFibGU+CgkJCQkJCTx0YWJsZSBzdHlsZT0id2lkdGg6YXV0bzsgd2lkdGg6YXV0byFpbXBvcnRh bnQiPgoJCQkJCQkJPHRyIHN0eWxlPSJtYXJnaW46MHB4Ij4KCQkJCQkJCQk8dGQgc3R5bGU9InBh ZGRpbmctcmlnaHQ6IDVweDsiPgoJCQkJCQkJCQlNZWV0aW5nIG51bWJlcjoKCQkJCQkJCQk8L3Rk PgoJCQkJCQkJCTx0ZD42NDcgNjE1IDc3OAoJCQkJCQkJCTwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJ CQkJPHRyPgoJCQkJCQkJCTx0ZCBzdHlsZT0icGFkZGluZy1yaWdodDogNXB4OyI+TWVldGluZyBw YXNzd29yZDo8L3RkPgoJCQkJCQkJCTx0ZD5jaG9vSml6NjwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJ CQk8L3RhYmxlPgoKCgoJCgoJPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6MjBweCI+PHRk IHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+PHRhYmxlPjx0cj48 dGQgc3R5bGU9ImZvbnQtc2l6ZToxNnB4Ij48Yj5Kb2luIGJ5IHBob25lPC9iPjwvdGQ+PC90cj48 dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZD48Yj4xLTg3Ny02NjgtNDQ5MzwvYj4mbmJzcDtDYWxs LWluIHRvbGwgZnJlZSBudW1iZXIgKFVTL0NhbmFkYSk8L3RkPjwvdHI+PHRyIHN0eWxlPSJtYXJn aW46MHB4Ij48dGQ+PGI+MS02NTAtNDc5LTMyMDg8L2I+Jm5ic3A7Q2FsbC1pbiB0b2xsIG51bWJl ciAoVVMvQ2FuYWRhKTwvdGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZD5BY2Nlc3Mg Y29kZTombmJzcDs2NDcgNjE1IDc3ODwvdGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0 ZD48YSBocmVmPSJodHRwOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25z LnBkZiIgc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2ZvbnQtc2l6ZToxM3B4O2NvbG9yOiMw MEFGRjk7Ij5Ub2xsLWZyZWUgY2FsbGluZyByZXN0cmljdGlvbnM8L2E+PC90ZD48L3RyPjwvdGFi bGU+CgoJCQkJCTx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OjIwcHgiPjx0ZCBzdHlsZT0i aGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPjx0YWJsZT48dHI+PHRkIHN0eWxl PSJmb250LXNpemU6MTNweCI+PGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2ou cGhwP01USUQ9bWUyYjE1ZDI0OWQ1YTgwOTg3ODkzZTdlMjI5ZDM0NGFlIiBzdHlsZT0idGV4dC1k ZWNvcmF0aW9uOm5vbmU7Y29sb3I6IzAwQUZGOTsgZm9udC1zaXplOjEzcHgiPkFkZCB0aGlzIG1l ZXRpbmc8L2E+IHRvIHlvdXIgY2FsZW5kYXIuPC90ZD48L3RyPjwvdGFibGU+Cjx0YWJsZT48dHIg c3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7 PC90ZD48L3RyPjwvdGFibGU+Cjx0YWJsZT4KICAgIDx0cj4KICAgICAgIDx0ZCBzdHlsZT0iZm9u dC1zaXplOiAxM3B4O2ZvbnQtZmFtaWx5OiBBcmlhbDtjb2xvcjogIzY2NjY2NjsiPgogICAgICAg IENhbid0IGpvaW4gdGhlIG1lZXRpbmc/CiAgICAgCTxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJl eC5jb20vaWV0Zi9tYyIgc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2ZvbnQtc2l6ZToxM3B4 O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOiMwMEFGRjk7Zm9udC1jb2xvcjojMDBBRkY5OyI+CiAg ICAgICAgCUNvbnRhY3Qgc3VwcG9ydC48L2E+CgkJPC90ZD4KICAgIDwvdHI+CjwvdGFibGU+Cjx0 YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAxMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MTBw eCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+CgkJCQkJCTx0YWJsZT4KCQkJCQkJCTx0cj4KCQkJ CQkJCQk8dGQgc3R5bGU9ImZvbnQtc2l6ZToxMnB4O2NvbG9yOiAjQTBBMEEwOyI+CgkJCQkJCQkJ CUlNUE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJFeCBzZXJ2aWNlIGFs bG93cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24g dG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0 ZXIuIEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRv IHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVk LCBkaXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUg c2Vzc2lvbi48L3RkPgoJCQkJCQkJPC90cj4KCQkJCQkJPC90YWJsZT4KCQkJCTwvdGQ+CgkJCTwv dHI+CgkJPC90YWJsZT4KCTwvdGQ+CiAgIDwvdHI+CjwvdGFibGU+Cgo8L2JvZHk+ ------=_Part_10825_1560574622.1440333568432-- ------=_Part_10824_1130885396.1440333568432 Content-Type: application/octet-stream; name="WebEx_Meeting.ics" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="WebEx_Meeting.ics" QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP TkUKVFpJRDpFdXJvcGUgVGltZQpCRUdJTjpTVEFOREFSRApEVFNUQVJUOjIwMTMxMDAxVDAzMDAw MApSUlVMRTpGUkVRPVlFQVJMWTtJTlRFUlZBTD0xO0JZREFZPS0xU1U7QllNT05USD0xMApUWk9G RlNFVEZST006KzAyMDAKVFpPRkZTRVRUTzorMDEwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDEzMDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0tMVNVO0JZTU9OVEg9MwpUWk9GRlNFVEZST006KzAx MDAKVFpPRkZTRVRUTzorMDIwMApUWk5BTUU6RGF5bGlnaHQgU2F2aW5ncyBUaW1lCkVORDpEQVlM SUdIVApFTkQ6VlRJTUVaT05FCkJFR0lOOlZFVkVOVApBVFRFTkRFRTtDTj0iIjtST0xFPVJFUS1Q QVJUSUNJUEFOVDtSU1ZQPVRSVUU6TUFJTFRPOm5ldG1vZEBpZXRmLm9yZwpPUkdBTklaRVI7Q049 Ik5FVE1PRCBXb3JraW5nIEdyb3VwIjpNQUlMVE86bmV0bW9kLWNoYWlyc0B0b29scy5pZXRmLm9y ZwpEVFNUQVJUO1RaSUQ9IkV1cm9wZSBUaW1lIjoyMDE1MDgyNFQxNzAwMDAKRFRFTkQ7VFpJRD0i RXVyb3BlIFRpbWUiOjIwMTUwODI0VDE4MDAwMApMT0NBVElPTjpodHRwczovL2lldGYud2ViZXgu Y29tL2lldGYKVFJBTlNQOk9QQVFVRQpTRVFVRU5DRToxNDQwMzMzNTY4ClVJRDozMTBhY2ZhYy02 YzFjLTRjNDgtYWRmYi1jNzMzNmFiNWRjYjIKRFRTVEFNUDoyMDE1MDgyNFQxNTAwMDBaCkRFU0NS SVBUSU9OOlxuXG5cbkpPSU4gV0VCRVggTUVFVElOR1xuaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9p ZXRmL2oucGhwP01USUQ9bThiYjgzY2IzMWI5MTY0N2M1YzAyYjU4M2VjMDBiYzRhXG5NZWV0aW5n IG51bWJlcjogNjQ3IDYxNSA3Nzhcbk1lZXRpbmcgcGFzc3dvcmQ6IGNob29KaXo2XG5cblxuSk9J TiBCWSBQSE9ORVxuMS04NzctNjY4LTQ0OTMgQ2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChVUy9D YW5hZGEpIFxuMS02NTAtNDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKVxu QWNjZXNzIGNvZGU6IDY0NyA2MTUgNzc4XG5cblRvbGwtZnJlZSBkaWFsaW5nIHJlc3RyaWN0aW9u czogXG5odHRwOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBkZlxu XG5cblxuQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz8gQ29udGFjdCBzdXBwb3J0IGhlcmU6XG5odHRw czovL2lldGYud2ViZXguY29tL2lldGYvbWNcblxuXG5JTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ug bm90ZSB0aGF0IHRoaXMgV2ViRXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9y bWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkg YmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lv biwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBk byBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdp dGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uXG4KWC1BTFQtREVTQztGTVRU WVBFPXRleHQvaHRtbDoJPEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxCUj4gPEZP TlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPgkJPGEJCQkJCWhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJl eC5jb20vaWV0Zi9qLnBocD9NVElEPW04YmI4M2NiMzFiOTE2NDdjNWMwMmI1ODNlYzAwYmM0YSI+ PEZPTlQgU0laRT0iMyIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9IkFyaWFsIj5Kb2luIFdlYkV4IG1l ZXRpbmc8L0ZPTlQ+PC9hPgkJCTx0YWJsZT4JCQkJPHRyPgkJCQkJPHRkPgkJCQkJCTxGT05UIFNJ WkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBudW1iZXI6PC9GT05U PgkJCQkJPC90ZD4JCQkJCTx0ZD4JCQkJCQk8Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIg RkFDRT0iYXJpYWwiPjY0NyA2MTUgNzc4PC9GT05UPgkJCQkJPC90ZD4JCQkJPC90cj4JCQk8L3Rh YmxlPgkJCTx0YWJsZT48dHI+PHRkPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNF PSJhcmlhbCI+TWVldGluZyBwYXNzd29yZDo8L0ZPTlQ+PC90ZD48dGQ+PEZPTlQgU0laRT0iMiIg IENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+Y2hvb0ppejY8L0ZPTlQ+PC90ZD48L3RyPjwv dGFibGU+CQk8L0ZPTlQ+PEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxCUj4mbmJz cDs8QlI+PC9GT05UPjxGT05UIFNJWkU9IjQiIEZBQ0U9IkFSSUFMIj48Rk9OVCBTSVpFPSIzIiBD T0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPkpvaW4gYnkgcGhvbmU8L0ZPTlQ+Jm5ic3A7IDxC Uj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjxzdHJvbmc+MS04 NzctNjY4LTQ0OTM8L3N0cm9uZz4mbmJzcDtDYWxsLWluIHRvbGwgZnJlZSBudW1iZXIgKFVTL0Nh bmFkYSk8L0ZPTlQ+Jm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFD RT0iYXJpYWwiPjxzdHJvbmc+MS02NTAtNDc5LTMyMDg8L3N0cm9uZz4mbmJzcDtDYWxsLWluIHRv bGwgbnVtYmVyIChVUy9DYW5hZGEpPC9GT05UPiZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09M T1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5BY2Nlc3MgY29kZTogNjQ3IDYxNSA3Nzg8L0ZPTlQ+ Jm5ic3A7IDxCUj48YSBocmVmPSJodHRwOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVz dHJpY3Rpb25zLnBkZiI+PEZPTlQgU0laRT0iMSIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9ImFyaWFs Ij5Ub2xsLWZyZWUgY2FsbGluZyByZXN0cmljdGlvbnM8L0ZPTlQ+PC9hPiAmbmJzcDsgPEJSPjwv Rk9OVD48QlI+PEJSPgkmbmJzcDs8QlI+CTxGT05UIFNJWkU9IjEiIENPTE9SPSIjNjY2NjY2IiBG QUNFPSJhcmlhbCI+CQkJCUNhbid0IGpvaW4gdGhlIG1lZXRpbmc/PC9GT05UPgk8YSBocmVmPSJo dHRwczovL2lldGYud2ViZXguY29tL2lldGYvbWMiPgk8Rk9OVCBTSVpFPSIxIiBDT0xPUj0iIzAw QUZGOSIgRkFDRT0iQXJpYWwiPkNvbnRhY3Qgc3VwcG9ydC48L0ZPTlQ+PC9hPgkmbmJzcDs8QlI+ Jm5ic3A7PEJSPjxGT05UIENPTE9SPSIjQTBBMEEwIiBzaXplPSIxIiBGQUNFPSJhcmlhbCI+SU1Q T1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxsb3dz IGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBi ZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4g Qnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3Vj aCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRp c2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNz aW9uLjwvRk9OVD48L0ZPTlQ+ClNVTU1BUlk6TkVUTU9EIFlBTkcgMS4xClBSSU9SSVRZOjUKQ0xB U1M6UFVCTElDCkVORDpWRVZFTlQKRU5EOlZDQUxFTkRBUgo= ------=_Part_10824_1130885396.1440333568432-- From nobody Sun Aug 23 10:04:29 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 930E31AD0A5 for ; Sun, 23 Aug 2015 10:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.16 X-Spam-Level: X-Spam-Status: No, score=-1.16 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJQLfzJQqIMM for ; Sun, 23 Aug 2015 10:04:26 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12EF71AD0A4 for ; Sun, 23 Aug 2015 10:04:26 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 84D74358D; Sun, 23 Aug 2015 19:04:24 +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 Je3R-AEvrX9V; Sun, 23 Aug 2015 19:04: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; Sun, 23 Aug 2015 19:04:23 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9801D20055; Sun, 23 Aug 2015 19:04:23 +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 0GbYpEI9C56T; Sun, 23 Aug 2015 19:04:22 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BCAF120054; Sun, 23 Aug 2015 19:04:20 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1C1993656D75; Sun, 23 Aug 2015 19:04:15 +0200 (CEST) Date: Sun, 23 Aug 2015 19:04:15 +0200 From: Juergen Schoenwaelder To: "t. petch" Message-ID: <20150823170415.GA77197@elstar.local> Mail-Followup-To: "t. petch" , rwilton@cisco.com, Martin Bjorklund , netmod@ietf.org References: <55D36473.90609@cisco.com> <55D45CAF.2070605@cisco.com> <20150819.132555.871710491924929960.mbj@tail-f.com> <013601d0da9b$907f6b00$4001a8c0@gateway.2wire.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <013601d0da9b$907f6b00$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Y34 - root node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Aug 2015 17:04:28 -0000 On Wed, Aug 19, 2015 at 05:24:41PM +0100, t. petch wrote: > The current model is a flat architecture of hundreds (or thousands) of > modules each with their own top level nodes, namespace, namespace name, > prefix etc. (This is quite different to SMI with its hierarchy but that > probably is only significant to those who have spent 20 years with SMI). This is most likely a wrong perception. There are basically only two locations where SNMP modules are registered in the IETF: under mib-2 and under transmission (yes there are a few exceptions but overall in number they do not matter). There are close to 240 MIB modules below mib-2 and about 50 MIB modules below transmission. RFC 4181: - The value assigned to the MODULE-IDENTITY descriptor MUST be unique and (for IETF standards-track MIB modules) SHOULD reside under the mgmt subtree [RFC2578]. Most often it will be an IANA-assigned value directly under mib-2 [RFC2578], although for media-specific MIB modules that extend the IF-MIB [RFC2863] it is customary to use an IANA-assigned value under transmission [RFC2578]. In the past, some IETF working groups have made their own assignments from subtrees delegated to them by IANA, but that practice has proven problematic and is NOT RECOMMENDED. /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 Aug 24 01:00:53 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B611A1A8F4C for ; Mon, 24 Aug 2015 01:00:52 -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_20=-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 Ov1fRcQZyMDK for ; Mon, 24 Aug 2015 01:00: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 660941A8F4A for ; Mon, 24 Aug 2015 01:00:51 -0700 (PDT) Received: from localhost (unknown [173.38.220.43]) by mail.tail-f.com (Postfix) with ESMTPSA id 8A1281AE019A; Mon, 24 Aug 2015 10:00:49 +0200 (CEST) Date: Mon, 24 Aug 2015 10:00:48 +0200 (CEST) Message-Id: <20150824.100048.1684671594277633894.mbj@tail-f.com> To: mciglan@cisco.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] issue & question: yang submodule contains newer revision than parent module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2015 08:00:52 -0000 "Martin Ciglan -X (mciglan - PANTHEON TECHNOLOGIES at Cisco)" wrote: > Hello > > I'm dealing with issue where one yang module includes many yang > submodules. > My question is if one of submodules gets updated with newer revision > than parent module, > does parent module needs to be updated too? > Is this mandatory? > If parent module doesn't get updated, can we consider this as invalid > set of yangs? If the parent module uses include-by revision, then it obviously has to be updated. If it doesn't use include-by revision it is not clear what it has to do. We always use include-by revision for this reason. /martin From nobody Mon Aug 24 01:58:21 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 354C81A9234 for ; Mon, 24 Aug 2015 01:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IIOYuY5C19L4 for ; Mon, 24 Aug 2015 01:58:18 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88BF01A9235 for ; Mon, 24 Aug 2015 01:58:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1674; q=dns/txt; s=iport; t=1440406698; x=1441616298; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kW6D0EeEuNMZ6WOTn1h4wnuvgoPlbeM+H9PVZzZ1FiU=; b=AeE7K/yXSpHFfoDCdmeXDgXn5OAg0B7jWZcDlmF68zKgXRc+mSNN85WG lOw/gZwbVj5stMgVEWAUyoMy2n6cA95BqRoyW2xioBT19fqIWsIFqhi4g K9db1G/stQ/LcX+odFRPipNHDJxMqg/qyqM+2ynsMnqM0rTjabQ1Pxx+a c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CQAgBO29pV/5BdJa1dgxqBPQa9XwEJh3ICgSo4FAEBAQEBAQGBCoQkAQEEeRACARYKCiQfEyUBAQQOBQiIJsY8AQEBAQEBAQEBAQEBAQEBAQEBAQEBF5AwMQeDGIEUBYcpinWDFgELjGiBSYxcg3aESYNqJoJAgT5xgUiBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,736,1432598400"; d="scan'208";a="26724415" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Aug 2015 08:58:17 +0000 Received: from XCH-RCD-019.cisco.com (xch-rcd-019.cisco.com [173.37.102.29]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t7O8wHhO012595 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 24 Aug 2015 08:58:17 GMT Received: from xch-rcd-019.cisco.com (173.37.102.29) by XCH-RCD-019.cisco.com (173.37.102.29) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 24 Aug 2015 03:58:16 -0500 Received: from xhc-rcd-x08.cisco.com (173.37.183.82) by xch-rcd-019.cisco.com (173.37.102.29) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Mon, 24 Aug 2015 03:58:16 -0500 Received: from xmb-aln-x03.cisco.com ([169.254.6.3]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0248.002; Mon, 24 Aug 2015 03:58:16 -0500 From: "Martin Ciglan -X (mciglan - PANTHEON TECHNOLOGIES at Cisco)" To: Martin Bjorklund Thread-Topic: [netmod] issue & question: yang submodule contains newer revision than parent module Thread-Index: AdDcHUDJBbqwnHHhQYyfH8fdk7TSCgCT6SYA//+6hX8= Date: Mon, 24 Aug 2015 08:58:16 +0000 Message-ID: References: , <20150824.100048.1684671594277633894.mbj@tail-f.com> In-Reply-To: <20150824.100048.1684671594277633894.mbj@tail-f.com> Accept-Language: sk-SK, en-US Content-Language: sk-SK X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.37.102.22] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: [netmod] =?iso-8859-2?q?ODPOVE=CF=3A__issue_=26_question=3A_yang_?= =?iso-8859-2?q?submodule_contains_newer_revision_than_parent_module?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2015 08:58:20 -0000 Hi Martin Thank you for your answer. Just to be precise, our input looks like this (just relevant parts): parent module a: ------------------------ include b { revision-date 2015-05-05; } revision 2015-03-19 { description "......................."; } submodule b: ------------------ revision 2015-05-05 { description "................"; } What I am missing here is update of parent module with latest submodule rev= ision: revision 2015-05-05 { description "................."; } Can you confirm that this should be present in parent module a to make it a= ll valid? Thanks. Best Regards Martin ______________________________ Od: Martin Bjorklund [mbj@tail-f.com] Odoslan=E9: 24. augusta 2015 10:00 Do: Martin Ciglan -X (mciglan - PANTHEON TECHNOLOGIES at Cisco) K=F3pia: netmod@ietf.org Predmet: Re: [netmod] issue & question: yang submodule contains newer revis= ion than parent module "Martin Ciglan -X (mciglan - PANTHEON TECHNOLOGIES at Cisco)" wrote: > Hello > > I'm dealing with issue where one yang module includes many yang > submodules. > My question is if one of submodules gets updated with newer revision > than parent module, > does parent module needs to be updated too? > Is this mandatory? > If parent module doesn't get updated, can we consider this as invalid > set of yangs? If the parent module uses include-by revision, then it obviously has to be updated. If it doesn't use include-by revision it is not clear what it has to do. We always use include-by revision for this reason. /martin= From nobody Mon Aug 24 02:06:58 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3684C1A92A9 for ; Mon, 24 Aug 2015 02:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.611 X-Spam-Level: X-Spam-Status: No, score=-1.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPSnMB-uU1hc for ; Mon, 24 Aug 2015 02:06: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 6F8AE1A9253 for ; Mon, 24 Aug 2015 02:06:51 -0700 (PDT) Received: from localhost (unknown [173.38.220.43]) by mail.tail-f.com (Postfix) with ESMTPSA id 55FA91AE019A; Mon, 24 Aug 2015 11:06:49 +0200 (CEST) Date: Mon, 24 Aug 2015 11:06:48 +0200 (CEST) Message-Id: <20150824.110648.1047424697491323450.mbj@tail-f.com> To: mciglan@cisco.com From: Martin Bjorklund In-Reply-To: References: <20150824.100048.1684671594277633894.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] =?utf-8?q?ODPOVE=C4=8E=3A__issue_=26_question=3A_yang_su?= =?utf-8?q?bmodule_contains_newer_revision_than_parent_module?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2015 09:06:57 -0000 "Martin Ciglan -X (mciglan - PANTHEON TECHNOLOGIES at Cisco)" wrote: > Hi Martin > = > Thank you for your answer. > = > Just to be precise, our input looks like this (just relevant parts): > = > parent module a: > ------------------------ > include b { > revision-date 2015-05-05; > } > = > revision 2015-03-19 { > description > "......................."; > } This is incorrect. Whenever you make a (published) change to your module, you should update the revision date. In this case, you have changed the parent module a, but forgot to update the revision date. > = > submodule b: > ------------------ > revision 2015-05-05 { > description > "................"; > } > = > What I am missing here is update of parent module with latest > submodule revision: > = > revision 2015-05-05 { > description > "................."; > } > = > Can you confirm that this should be present in parent module a to mak= e > it all valid? Thanks. Yes. /martin > = > Best Regards > = > Martin > = > ______________________________ > Od: Martin Bjorklund [mbj@tail-f.com] > Odoslan=E9: 24. augusta 2015 10:00 > Do: Martin Ciglan -X (mciglan - PANTHEON TECHNOLOGIES at Cisco) > K=F3pia: netmod@ietf.org > Predmet: Re: [netmod] issue & question: yang submodule contains newer= > revision than parent module > = > "Martin Ciglan -X (mciglan - PANTHEON TECHNOLOGIES at Cisco)" > wrote: > > Hello > > > > I'm dealing with issue where one yang module includes many yang > > submodules. > > My question is if one of submodules gets updated with newer revisio= n > > than parent module, > > does parent module needs to be updated too? > > Is this mandatory? > > If parent module doesn't get updated, can we consider this as inval= id > > set of yangs? > = > If the parent module uses include-by revision, then it obviously has > to be updated. If it doesn't use include-by revision it is not clear= > what it has to do. We always use include-by revision for this > reason. > = > = > /martin From nobody Mon Aug 24 02:20:08 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B891ABC75 for ; Mon, 24 Aug 2015 02:20:07 -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 8U8Q7u0apD9T for ; Mon, 24 Aug 2015 02:20:05 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC8C11A9301 for ; Mon, 24 Aug 2015 02:19:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2523; q=dns/txt; s=iport; t=1440407985; x=1441617585; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=r9iNibNMcGBEhWBlu53/hX9e5dTWiV3lVkPMOHSmCUw=; b=eNYkuETYXuVamu9TF9a4KAlJjdLQUXrPKMlE6Thl30ygTgNc16iDnvCP ybmS0DS4QKMYD4Et8fX36Pva3ha08vS6/js+edUh0WalSpCI4A4rnS2ZW AbBQh6VbwwwwuLz6RSMx9BzcLs2g2UfopeJ7Y5bShorTu6hqoOk2st6Av Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CQAgBJ4dpV/49dJa1dgxqBPQa9XwEJh3ICgSo4FAEBAQEBAQGBCoQjAQEBAwF5EgEIDgoKQxMnBA4FCIgeCMZAAQEBAQEBAQECAQEBAQEBAQEai1eEVwIxgx+BFAWHKY4LAQuMaIFJkFKESYNqJoJAgT5xgUiBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,736,1432598400"; d="scan'208";a="180782992" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-2.cisco.com with ESMTP; 24 Aug 2015 09:19:44 +0000 Received: from XCH-RCD-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t7O9Jha2021980 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 24 Aug 2015 09:19:44 GMT Received: from xch-rcd-011.cisco.com (173.37.102.21) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 24 Aug 2015 04:19:43 -0500 Received: from xhc-aln-x06.cisco.com (173.36.12.80) by xch-rcd-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Mon, 24 Aug 2015 04:19:43 -0500 Received: from xmb-aln-x03.cisco.com ([169.254.6.3]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0248.002; Mon, 24 Aug 2015 04:19:43 -0500 From: "Martin Ciglan -X (mciglan - PANTHEON TECHNOLOGIES at Cisco)" To: Martin Bjorklund Thread-Topic: Re: [netmod] issue & question: yang submodule contains newer revision than parent module Thread-Index: AQHQ3k4CfHaLeE7Zi0SFsTbRGs/VrA== Date: Mon, 24 Aug 2015 09:19:41 +0000 Message-ID: Accept-Language: sk-SK, en-US Content-Language: sk-SK X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.37.102.22] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] issue & question: yang submodule contains newer revision than parent module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2015 09:20:07 -0000 Hi Martin Thanks, that's clear to me. Best Regards Martin ________________________________________ Od: Martin Bjorklund [mbj@tail-f.com] Odoslan=E9: 24. augusta 2015 11:06 Do: Martin Ciglan -X (mciglan - PANTHEON TECHNOLOGIES at Cisco) K=F3pia: netmod@ietf.org Predmet: Re: ODPOVE=CF: [netmod] issue & question: yang submodule contains = newer revision than parent module "Martin Ciglan -X (mciglan - PANTHEON TECHNOLOGIES at Cisco)" wrote: > Hi Martin > > Thank you for your answer. > > Just to be precise, our input looks like this (just relevant parts): > > parent module a: > ------------------------ > include b { > revision-date 2015-05-05; > } > > revision 2015-03-19 { > description > "......................."; > } This is incorrect. Whenever you make a (published) change to your module, you should update the revision date. In this case, you have changed the parent module a, but forgot to update the revision date. > > submodule b: > ------------------ > revision 2015-05-05 { > description > "................"; > } > > What I am missing here is update of parent module with latest > submodule revision: > > revision 2015-05-05 { > description > "................."; > } > > Can you confirm that this should be present in parent module a to make > it all valid? Thanks. Yes. /martin > > Best Regards > > Martin > > ______________________________ > Od: Martin Bjorklund [mbj@tail-f.com] > Odoslan=E9: 24. augusta 2015 10:00 > Do: Martin Ciglan -X (mciglan - PANTHEON TECHNOLOGIES at Cisco) > K=F3pia: netmod@ietf.org > Predmet: Re: [netmod] issue & question: yang submodule contains newer > revision than parent module > > "Martin Ciglan -X (mciglan - PANTHEON TECHNOLOGIES at Cisco)" > wrote: > > Hello > > > > I'm dealing with issue where one yang module includes many yang > > submodules. > > My question is if one of submodules gets updated with newer revision > > than parent module, > > does parent module needs to be updated too? > > Is this mandatory? > > If parent module doesn't get updated, can we consider this as invalid > > set of yangs? > > If the parent module uses include-by revision, then it obviously has > to be updated. If it doesn't use include-by revision it is not clear > what it has to do. We always use include-by revision for this > reason. > > > /martin From nobody Mon Aug 24 05:20:27 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE50E1B335F for ; Mon, 24 Aug 2015 05:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.859 X-Spam-Level: X-Spam-Status: No, score=-5.859 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnRXY-LjtICo for ; Mon, 24 Aug 2015 05:20:21 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 833401B3363 for ; Mon, 24 Aug 2015 05:20:20 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 284B5AF5 for ; Mon, 24 Aug 2015 14:20:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id tlduYRIdZ_3r for ; Mon, 24 Aug 2015 14:20:18 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Mon, 24 Aug 2015 14:20:18 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 087B420078 for ; Mon, 24 Aug 2015 14:20:18 +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 uu0Glfwkc4ne; Mon, 24 Aug 2015 14:20:17 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E555620060; Mon, 24 Aug 2015 14:20:16 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4B41036577CF; Mon, 24 Aug 2015 14:20:12 +0200 (CEST) Date: Mon, 24 Aug 2015 14:20:12 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20150824122011.GA79330@elstar.local> Mail-Followup-To: netmod@ietf.org References: <1359891143.10826.1440333568433.JavaMail.nobody@jva2tc111.webex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1359891143.10826.1440333568433.JavaMail.nobody@jva2tc111.webex.com> User-Agent: Mutt/1.4.2.3i Archived-At: Subject: Re: [netmod] WebEx meeting invitation: NETMOD YANG 1.1 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2015 12:20:26 -0000 Hi, we will use this etherpad to take notes: http://etherpad.tools.ietf.org:9000/p/notes-ietf-netmod-virtual-interim-2015-08-24?useMonospaceFont=true Talk to you later. /js On Sun, Aug 23, 2015 at 12:39:28PM +0000, NETMOD Working Group wrote: > > Hello, > > NETMOD Working Group invites you to join this WebEx meeting. > > > NETMOD YANG 1.1 > Monday, August 24, 2015 > 5:00 pm | Europe Summer Time (Berlin, GMT+02:00) | 1 hr > > > JOIN WEBEX MEETING > https://ietf.webex.com/ietf/j.php?MTID=ma46abc9d527b2dd38526f7d80d37fc36 > Meeting number: 647 615 778 > Meeting password: chooJiz6 > > > 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: 647 615 778 > > Toll-free dialing restrictions: > http://www.webex.com/pdf/tollfree_restrictions.pdf > > > Add this meeting to your calendar: > https://ietf.webex.com/ietf/j.php?MTID=me2b15d249d5a80987893e7e229d344ae > > > Can't join the meeting? Contact support here: > https://ietf.webex.com/ietf/mc > > > IMPORTANT NOTICE: Please note that this WebEx service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session. > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Aug 24 09:35:12 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8B91ACCFD for ; Mon, 24 Aug 2015 09:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bI_DaJLLDpBs for ; Mon, 24 Aug 2015 09:35:10 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 1006F1ACCF4 for ; Mon, 24 Aug 2015 09:35:10 -0700 (PDT) Received: from localhost (unknown [172.29.2.202]) by trail.lhotka.name (Postfix) with ESMTPSA id 377DE1CC0047; Mon, 24 Aug 2015 18:35:10 +0200 (CEST) From: Ladislav Lhotka To: Martin =?utf-8?Q?Bj=C3=B6rklund?= In-Reply-To: References: <20150818.130919.1060632323457095150.mbj@tail-f.com> <778755AA-66CB-491B-9BD7-81061125CAFC@nic.cz> <20150818.154223.1301963938445592911.mbj@tail-f.com> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Mon, 24 Aug 2015 18:35:07 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Y26 again, sorry X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2015 16:35:11 -0000 Ladislav Lhotka writes: Hi, > > 2. The rogue vendor can use a must statement to achieve the same > effect (or perhaps just state it in a description?). What=E2=80=99s impor= tant > is whether the server that advertises such an extension rejects a > configuration where the new parameter is missing or not. As a follow-up to the discussion during the interim call, here is an example of a module snippet that augments "ietf-interfaces" with a mandatory node: import ietf-interfaces { prefix if; } augment "/if:interfaces" { container top { must "foo"; leaf accept { type boolean; default true; } leaf foo { type empty; } } } If a server advertises this module along with "ietf-interfaces", then, according to the rules of YANG 1.0, a datastore without the "foo" instance is invalid. Therefore, I think it really makes no practical sense to insist on restricting augments to non-mandatory nodes. Lada --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Aug 24 09:42:55 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE5C1A00B7 for ; Mon, 24 Aug 2015 09:42:54 -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 VpIDz7H3pmtG for ; Mon, 24 Aug 2015 09:42:52 -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 511FD1A0022 for ; Mon, 24 Aug 2015 09:42:52 -0700 (PDT) Received: by labia3 with SMTP id ia3so16966108lab.3 for ; Mon, 24 Aug 2015 09:42:50 -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=1nRk7RsE16gRYqsP4gPww39E0XJXnK2n1UzOnF7eex8=; b=ScIn1wvhvH8wWFRdmAXRrcPjmQHz5KRWW24CDCcKUXnTNLGhqj8AXlXAbVfJK6H4tb SXi7k8Q/F9pGzmljlvMn1P6pSYt4PYKmLVwUm3ftYsxSQAKjPyVrXADG/oJ/4vLc0BCt Q/xAkQ4Fah61twwftF9/+z5jxKPSq8SKeqDI3OeHSEc3dt+wkSKtfrOJ7ibPnBPnvhbK tuzQ9/uk4EAZye8znmNsK0AHEZyXHdQMuJp2gvBT7y581230ZkpqZ7nCu0uz7EwA5oXL XDkMmFtUWkkBg0+1hBr1cFudGC0Sc5tXHDhvVc90w26zjVvqVRjy9Ys2Vc16cE2nf0Po lN4A== X-Gm-Message-State: ALoCoQnh3sESIBmnXorrzFtZZBW55sKy+SLX79iwogVCVW8hXzyyFH7q/j8O9SdvsvSU78grPKL4 MIME-Version: 1.0 X-Received: by 10.152.29.132 with SMTP id k4mr21112111lah.88.1440434570770; Mon, 24 Aug 2015 09:42:50 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Mon, 24 Aug 2015 09:42:50 -0700 (PDT) In-Reply-To: References: <20150818.130919.1060632323457095150.mbj@tail-f.com> <778755AA-66CB-491B-9BD7-81061125CAFC@nic.cz> <20150818.154223.1301963938445592911.mbj@tail-f.com> Date: Mon, 24 Aug 2015 09:42:50 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=089e0158c12ae9d6c5051e114ead Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y26 again, sorry X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2015 16:42:54 -0000 --089e0158c12ae9d6c5051e114ead Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Aug 24, 2015 at 9:35 AM, Ladislav Lhotka wrote: > Ladislav Lhotka writes: > Hi, > > > > > 2. The rogue vendor can use a must statement to achieve the same > > effect (or perhaps just state it in a description?). What=E2=80=99s imp= ortant > > is whether the server that advertises such an extension rejects a > > configuration where the new parameter is missing or not. > > As a follow-up to the discussion during the interim call, here is an > example of a module snippet that augments "ietf-interfaces" with a > mandatory node: > > import ietf-interfaces { > prefix if; > } > > augment "/if:interfaces" { > container top { > must "foo"; > leaf accept { > type boolean; > default true; > } > leaf foo { > type empty; > } > } > } > > If a server advertises this module along with "ietf-interfaces", then, > according to the rules of YANG 1.0, a datastore without the "foo" > instance is invalid. > > When a datastore is validated, all "must" constraints are conceptually evaluated once for each data node in the data tree, and for all leafs with default values in use (see Section 7.6.1). If a data node does not exist in the data tree, and it does not have a default value, its "must" statements are not evaluated. According to sec. 7.5.3, para 2, the must statement is not evaluated for a missing NP container because it has no default-stmt. > Therefore, I think it really makes no practical sense to insist on > restricting augments to non-mandatory nodes. > > It does because the current YANG conformance model does not require the augmenting modules to be present. They are considered optional so a client can be written to work with the base module and not break every time a new augments is added. > Lada > > Andy > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --089e0158c12ae9d6c5051e114ead Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Aug 24, 2015 at 9:35 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:
Ladislav Lhotka <lhotka@nic.cz> writes:
Hi,

>
> 2. The rogue vendor can use a must statement to achieve the same
> effect (or perhaps just state it in a description?). What=E2=80=99s im= portant
> is whether the server that advertises such an extension rejects a
> configuration where the new parameter is missing or not.

As a follow-up to the discussion during the interim call, here is an
example of a module snippet that augments "ietf-interfaces" with = a
mandatory node:

import ietf-interfaces {
=C2=A0 prefix if;
}

augment "/if:interfaces" {
=C2=A0 container top {
=C2=A0 =C2=A0 must "foo";
=C2=A0 =C2=A0 leaf accept {
=C2=A0 =C2=A0 =C2=A0 type boolean;
=C2=A0 =C2=A0 =C2=A0 default true;
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0 leaf foo {
=C2=A0 =C2=A0 =C2=A0 type empty;
=C2=A0 =C2=A0 }
=C2=A0 }
}

If a server advertises this module along with "ietf-interfaces", = then,
according to the rules of YANG 1.0, a datastore without the "foo"=
instance is invalid.




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


According to sec. 7.5.3, para 2, t= he must statement is not evaluated
for a missing NP container bec= ause it has no default-stmt.

=C2=A0
Therefore, I think it really makes no practical sense to insist on
restricting augments to non-mandatory nodes.


It does because the current YANG confo= rmance model does not
require the augmenting modules to be presen= t. They are considered
optional so a client can be written to wor= k with the base module
and not break every time a new augments is= added.

=C2=A0
Lada



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

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

--089e0158c12ae9d6c5051e114ead-- From nobody Mon Aug 24 10:53:27 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B94E1A8986 for ; Mon, 24 Aug 2015 10:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.661 X-Spam-Level: X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UmB9AhI1S8PG for ; Mon, 24 Aug 2015 10:53:24 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B0D81A8960 for ; Mon, 24 Aug 2015 10:53:23 -0700 (PDT) Received: from [IPv6:2a01:5e0:29:ffff:616e:7bc6:ddf2:7585] (unknown [IPv6:2a01:5e0:29:ffff:616e:7bc6:ddf2:7585]) by mail.nic.cz (Postfix) with ESMTPSA id 982691813C6; Mon, 24 Aug 2015 19:53:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1440438801; bh=8/RTa0bcSM6bA5vigsZF4hnNH6CKbhxYHNck+VozaSY=; h=From:Date:To; b=xRgaMYgss09Ryi3YVxUL+AKMFQgb8w2aOwPV9Meg6ogJBiqrfOxIxvpjMwYg0uZx1 sr/EV7FXFluPc55nEptHsbYQftXOL7vjK+4vsetk088spF4/h2631v9AzjKN3XHNeN fVW5GSEZzoSiexFLQq7D+9DqYMmICteD4mEnbnXw= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 24 Aug 2015 19:53:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9EB6F767-1643-4852-8B88-E79D72309E95@nic.cz> References: <20150818.130919.1060632323457095150.mbj@tail-f.com> <778755AA-66CB-491B-9BD7-81061125CAFC@nic.cz> <20150818.154223.1301963938445592911.mbj@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y26 again, sorry X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2015 17:53:26 -0000 > On 24 Aug 2015, at 18:42, Andy Bierman wrote: >=20 >=20 >=20 > On Mon, Aug 24, 2015 at 9:35 AM, Ladislav Lhotka = wrote: > Ladislav Lhotka writes: > Hi, >=20 > > > > 2. The rogue vendor can use a must statement to achieve the same > > effect (or perhaps just state it in a description?). What=E2=80=99s = important > > is whether the server that advertises such an extension rejects a > > configuration where the new parameter is missing or not. >=20 > As a follow-up to the discussion during the interim call, here is an > example of a module snippet that augments "ietf-interfaces" with a > mandatory node: >=20 > import ietf-interfaces { > prefix if; > } >=20 > augment "/if:interfaces" { > container top { > must "foo"; > leaf accept { > type boolean; > default true; > } > leaf foo { > type empty; > } > } > } >=20 > If a server advertises this module along with "ietf-interfaces", then, > according to the rules of YANG 1.0, a datastore without the "foo" > instance is invalid. >=20 >=20 >=20 >=20 > When a datastore is validated, all "must" constraints are > conceptually evaluated once for each data node in the data tree, = and > for all leafs with default values in use (see Section 7.6.1). If a > data node does not exist in the data tree, and it does not have a > default value, its "must" statements are not evaluated. >=20 >=20 >=20 > According to sec. 7.5.3, para 2, the must statement is not evaluated > for a missing NP container because it has no default-stmt. OK, so the the must statement can be moved under =E2=80=9Caccept=E2=80=9D:= must =E2=80=9C../foo=E2=80=9D; In YANG 1.1, NP containers exist for validation purposes, see issue Y41. >=20 > =20 > Therefore, I think it really makes no practical sense to insist on > restricting augments to non-mandatory nodes. >=20 >=20 > It does because the current YANG conformance model does not > require the augmenting modules to be present. They are considered > optional so a client can be written to work with the base module > and not break every time a new augments is added. No text in 6020(bis) supports this interpretation. Lada >=20 > =20 > Lada >=20 >=20 >=20 > Andy > =20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Aug 24 11:17:18 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D391A889B for ; Mon, 24 Aug 2015 11:17:16 -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 KoW60d3au3AA for ; Mon, 24 Aug 2015 11:17:14 -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 035931A00B0 for ; Mon, 24 Aug 2015 11:17:14 -0700 (PDT) Received: by labgv11 with SMTP id gv11so15353045lab.2 for ; Mon, 24 Aug 2015 11:17:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=du9aYVhl2zdt5bpX2knGB59x4vkr0BWdb3ga2w/3LjM=; b=LLQjtKKF/rzj2Qpi79v8nkD6bS+hqjI6vhMIJ/lmdvP8kHycC+FNZ2Tn5v3TspdrMh mATjYo3O4Am7gA1K8mS7h+yod2bG1Ssk2LEc8mbJ+4lRt6Pr8o5KtmEpKLzyJvC6z1gQ 514HDC7vT73Hdg0GlNZekmfq3D7+THxyyKHZWCdAVLhFK1mP8yncxxjkTIoSKRZyyY7P rN6DFuiP5HXOuk+Gq0hmsqf7lZvIbIh1JDNZxDlh5yKZwgjPmrZPMuh2qeR1LzXmEA6S yMJ391Xf3wOgc/kcFVMzpK7Va0tzrRo4AH2THzaFXg+ECueQI74sRbpkONd7YUNy4O30 xyng== X-Gm-Message-State: ALoCoQmPAv2lookgHvENSWg3PZWSqgk6YVjnn4gwNWfV+Y+JCq75P+3g0cGc/UtDcGgUWRFl1I7u MIME-Version: 1.0 X-Received: by 10.152.6.133 with SMTP id b5mr9167427laa.33.1440440232306; Mon, 24 Aug 2015 11:17:12 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Mon, 24 Aug 2015 11:17:12 -0700 (PDT) In-Reply-To: <9EB6F767-1643-4852-8B88-E79D72309E95@nic.cz> References: <20150818.130919.1060632323457095150.mbj@tail-f.com> <778755AA-66CB-491B-9BD7-81061125CAFC@nic.cz> <20150818.154223.1301963938445592911.mbj@tail-f.com> <9EB6F767-1643-4852-8B88-E79D72309E95@nic.cz> Date: Mon, 24 Aug 2015 11:17:12 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=089e01493fa85e00e2051e12a0e9 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y26 again, sorry X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2015 18:17:16 -0000 --089e01493fa85e00e2051e12a0e9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Aug 24, 2015 at 10:53 AM, Ladislav Lhotka wrote: > > > On 24 Aug 2015, at 18:42, Andy Bierman wrote: > > > > > > > > On Mon, Aug 24, 2015 at 9:35 AM, Ladislav Lhotka wrote: > > Ladislav Lhotka writes: > > Hi, > > > > > > > > 2. The rogue vendor can use a must statement to achieve the same > > > effect (or perhaps just state it in a description?). What=E2=80=99s i= mportant > > > is whether the server that advertises such an extension rejects a > > > configuration where the new parameter is missing or not. > > > > As a follow-up to the discussion during the interim call, here is an > > example of a module snippet that augments "ietf-interfaces" with a > > mandatory node: > > > > import ietf-interfaces { > > prefix if; > > } > > > > augment "/if:interfaces" { > > container top { > > must "foo"; > > leaf accept { > > type boolean; > > default true; > > } > > leaf foo { > > type empty; > > } > > } > > } > > > > If a server advertises this module along with "ietf-interfaces", then, > > according to the rules of YANG 1.0, a datastore without the "foo" > > instance is invalid. > > > > > > > > > > When a datastore is validated, all "must" constraints are > > conceptually evaluated once for each data node in the data tree, and > > for all leafs with default values in use (see Section 7.6.1). If a > > data node does not exist in the data tree, and it does not have a > > default value, its "must" statements are not evaluated. > > > > > > > > According to sec. 7.5.3, para 2, the must statement is not evaluated > > for a missing NP container because it has no default-stmt. > > OK, so the the must statement can be moved under =E2=80=9Caccept=E2=80=9D= : > > must =E2=80=9C../foo=E2=80=9D; > > In YANG 1.1, NP containers exist for validation purposes, see issue Y41. > > YANG does not provide any mechanism to REQUIRE modules A and B to both be implemented on a server. You may think it should, but currently the YANG conformance is for an individual module. As long as there is no server requirement to implement 2 modules together, then YANG must allow for the possibility that the augmenting module in not present. Therefore a client which only supports the base module is valid. IMO this issue is closed. The WG decided the only problem to solve with YANG conformance is import-by-revision. This is a conformance issue. You want to force the old client to support every augmenting module a server may add to this base module. Current YANG conformance rules do not work this way for good reason. > > > > > Therefore, I think it really makes no practical sense to insist on > > restricting augments to non-mandatory nodes. > > > > > > It does because the current YANG conformance model does not > > require the augmenting modules to be present. They are considered > > optional so a client can be written to work with the base module > > and not break every time a new augments is added. > > No text in 6020(bis) supports this interpretation. > > Show me the text that says if a server implements a module it must also implement other modules that augment this module. There is none. > Lada > Andy > > > > > > > Lada > > > > > > > > Andy > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --089e01493fa85e00e2051e12a0e9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Aug 24, 2015 at 10:53 AM, Ladislav Lhotka <= ;lhotka@nic.cz> wrote:

> On 24 Aug 2015, at 18:42, Andy Bierman <andy@yumaworks.com> wrote:
>
>
>
> On Mon, Aug 24, 2015 at 9:35 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> Ladislav Lhotka <lhotka@nic.cz= > writes:
> Hi,
>
> >
> > 2. The rogue vendor can use a must statement to achieve the same<= br> > > effect (or perhaps just state it in a description?). What=E2=80= =99s important
> > is whether the server that advertises such an extension rejects a=
> > configuration where the new parameter is missing or not.
>
> As a follow-up to the discussion during the interim call, here is an > example of a module snippet that augments "ietf-interfaces" = with a
> mandatory node:
>
> import ietf-interfaces {
>=C2=A0 =C2=A0prefix if;
> }
>
> augment "/if:interfaces" {
>=C2=A0 =C2=A0container top {
>=C2=A0 =C2=A0 =C2=A0must "foo";
>=C2=A0 =C2=A0 =C2=A0leaf accept {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0type boolean;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0default true;
>=C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0leaf foo {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0type empty;
>=C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0}
> }
>
> If a server advertises this module along with "ietf-interfaces&qu= ot;, then,
> according to the rules of YANG 1.0, a datastore without the "foo&= quot;
> instance is invalid.
>
>
>
>
>=C2=A0 =C2=A0 When a datastore is validated, all "must" const= raints are
>=C2=A0 =C2=A0 conceptually evaluated once for each data node in the dat= a tree, and
>=C2=A0 =C2=A0 for all leafs with default values in use (see Section 7.6= .1).=C2=A0 If a
>=C2=A0 =C2=A0 data node does not exist in the data tree, and it does no= t have a
>=C2=A0 =C2=A0 default value, its "must" statements are not ev= aluated.
>
>
>
> According to sec. 7.5.3, para 2, the must statement is not evaluated > for a missing NP container because it has no default-stmt.

OK, so the the must statement can be moved under =E2=80=9Caccept=E2=80=9D:<= br>
must =E2=80=9C../foo=E2=80=9D;

In YANG 1.1, NP containers exist for validation purposes, see issue Y41.


YANG does not provide a= ny mechanism to REQUIRE =C2=A0modules A and B
to both be implemen= ted on a server.=C2=A0 You may think it should, but
currently the= YANG conformance is for an individual module.

As = long as there is no server requirement to implement 2 modules together,
then YANG must allow for the possibility that the augmenting module<= /div>
in not present.=C2=A0 Therefore a client which only
sup= ports the base module is valid.

IMO this issue is = closed.
The WG decided the only problem to solve with YANG confor= mance
is import-by-revision.=C2=A0 This is a conformance issue.= =C2=A0 You want to
force the old client to support every augmenti= ng module a server
may add to this base module.

Current YANG conformance rules do not work this way for good reason= .



>
>
> Therefore, I think it really makes no practical sense to insist on
> restricting augments to non-mandatory nodes.
>
>
> It does because the current YANG conformance model does not
> require the augmenting modules to be present. They are considered
> optional so a client can be written to work with the base module
> and not break every time a new augments is added.

No text in 6020(bis) supports this interpretation.


Show me the text that says if a server= implements a module
it must also implement other modules that au= gment this module.
There is none.


=C2=A0
Lada


Andy
=C2= =A0

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





--089e01493fa85e00e2051e12a0e9-- From nobody Mon Aug 24 11:44:35 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22A101AD1FE for ; Mon, 24 Aug 2015 11:44:34 -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 9HQSsZb3arjw for ; Mon, 24 Aug 2015 11:44:32 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB2651AD1EE for ; Mon, 24 Aug 2015 11:44:31 -0700 (PDT) Received: from [IPv6:2a01:5e0:29:ffff:9955:95f:86fe:32ad] (unknown [IPv6:2a01:5e0:29:ffff:9955:95f:86fe:32ad]) by mail.nic.cz (Postfix) with ESMTPSA id 4BFF61816AA; Mon, 24 Aug 2015 20:44:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1440441870; bh=lrQOBNS9hW7lGAXpkcrpvgBC2nGP23ehPRo8iQzDx5c=; h=From:Date:To; b=DxSwOkIP6eZKW8CtS7A6iQFnGL9KL7oSRN+aTV+KoVGWKNN+NasY+CbYZ0it02Dqm 1Unk98H+pS6wl4Ab6/GwEVX6w0wILjvzK1Izkg//u0PxjqDQD9A2HmxzvezGo1elU5 BjEJ1wlooK1XD+pTvm9X5xj3gtlflXv936RZQkMs= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 24 Aug 2015 20:44:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7D38FB86-CFB2-4900-A727-A42DC1132F32@nic.cz> References: <20150818.130919.1060632323457095150.mbj@tail-f.com> <778755AA-66CB-491B-9BD7-81061125CAFC@nic.cz> <20150818.154223.1301963938445592911.mbj@tail-f.com> <9EB6F767-1643-4852-8B88-E79D72309E95@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y26 again, sorry X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2015 18:44:34 -0000 > On 24 Aug 2015, at 20:17, Andy Bierman wrote: >=20 >=20 >=20 > On Mon, Aug 24, 2015 at 10:53 AM, Ladislav Lhotka = wrote: >=20 > > On 24 Aug 2015, at 18:42, Andy Bierman wrote: > > > > > > > > On Mon, Aug 24, 2015 at 9:35 AM, Ladislav Lhotka = wrote: > > Ladislav Lhotka writes: > > Hi, > > > > > > > > 2. The rogue vendor can use a must statement to achieve the same > > > effect (or perhaps just state it in a description?). What=E2=80=99s = important > > > is whether the server that advertises such an extension rejects a > > > configuration where the new parameter is missing or not. > > > > As a follow-up to the discussion during the interim call, here is an > > example of a module snippet that augments "ietf-interfaces" with a > > mandatory node: > > > > import ietf-interfaces { > > prefix if; > > } > > > > augment "/if:interfaces" { > > container top { > > must "foo"; > > leaf accept { > > type boolean; > > default true; > > } > > leaf foo { > > type empty; > > } > > } > > } > > > > If a server advertises this module along with "ietf-interfaces", = then, > > according to the rules of YANG 1.0, a datastore without the "foo" > > instance is invalid. > > > > > > > > > > When a datastore is validated, all "must" constraints are > > conceptually evaluated once for each data node in the data tree, = and > > for all leafs with default values in use (see Section 7.6.1). If = a > > data node does not exist in the data tree, and it does not have a > > default value, its "must" statements are not evaluated. > > > > > > > > According to sec. 7.5.3, para 2, the must statement is not evaluated > > for a missing NP container because it has no default-stmt. >=20 > OK, so the the must statement can be moved under =E2=80=9Caccept=E2=80=9D= : >=20 > must =E2=80=9C../foo=E2=80=9D; >=20 > In YANG 1.1, NP containers exist for validation purposes, see issue = Y41. >=20 >=20 >=20 > YANG does not provide any mechanism to REQUIRE modules A and B > to both be implemented on a server. You may think it should, but > currently the YANG conformance is for an individual module. There are sections on conformance and conformance announcement, and they = say nothing like this. In my view, the data model comprises *all* = modules advertised by the server. I think your interpretation of = conformance might be an extrapolation from SNMP/SMI times, but, for = better or worse, it really has no support in the YANG spec. >=20 > As long as there is no server requirement to implement 2 modules = together, > then YANG must allow for the possibility that the augmenting module > in not present. Therefore a client which only > supports the base module is valid. >=20 > IMO this issue is closed. > The WG decided the only problem to solve with YANG conformance > is import-by-revision. This is a conformance issue. You want to > force the old client to support every augmenting module a server > may add to this base module. >=20 > Current YANG conformance rules do not work this way for good reason. >=20 >=20 >=20 > > > > > > Therefore, I think it really makes no practical sense to insist on > > restricting augments to non-mandatory nodes. > > > > > > It does because the current YANG conformance model does not > > require the augmenting modules to be present. They are considered > > optional so a client can be written to work with the base module > > and not break every time a new augments is added. >=20 > No text in 6020(bis) supports this interpretation. >=20 >=20 > Show me the text that says if a server implements a module > it must also implement other modules that augment this module. > There is none. Well, if the server *advertises* such a module, then I guess it has to = implement it. I think it comes down to the definition of the =E2=80=9Cdata model=E2=80=9D= , which is the substance of the client-server contract. It looks like it = needs to be clarified, if we can disagree on such a fundamental thing. Lada=20 >=20 >=20 > =20 > Lada >=20 >=20 > Andy > =20 >=20 > > > > > > Lada > > > > > > > > Andy > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Aug 24 12:01:05 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40E701B319C for ; Mon, 24 Aug 2015 12:01: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 lDcbqq0FovbO for ; Mon, 24 Aug 2015 12:01: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 A1B021B29B7 for ; Mon, 24 Aug 2015 12:00:53 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 07A241AE019A; Mon, 24 Aug 2015 21:00:52 +0200 (CEST) Date: Mon, 24 Aug 2015 21:01:09 +0200 (CEST) Message-Id: <20150824.210109.1638056143186576784.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <7D38FB86-CFB2-4900-A727-A42DC1132F32@nic.cz> References: <9EB6F767-1643-4852-8B88-E79D72309E95@nic.cz> <7D38FB86-CFB2-4900-A727-A42DC1132F32@nic.cz> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Y26 again, sorry X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2015 19:01:04 -0000 Ladislav Lhotka wrote: > > On 24 Aug 2015, at 20:17, Andy Bierman wrote: > > YANG does not provide any mechanism to REQUIRE modules A and B > > to both be implemented on a server. You may think it should, but > > currently the YANG conformance is for an individual module. > > There are sections on conformance and conformance announcement, and > they say nothing like this. No Andy is correct, except that if module A augments module B, then a server that implements A MUST also implement B. But I don't understand what this has to do with the issue. /martin From nobody Mon Aug 24 12:13:17 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2F11A0196 for ; Mon, 24 Aug 2015 12:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.361 X-Spam-Level: X-Spam-Status: No, score=-5.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pw27bfjIYQmF for ; Mon, 24 Aug 2015 12:13:15 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6177E1A00CD for ; Mon, 24 Aug 2015 12:13:15 -0700 (PDT) Received: from [172.29.2.202] (nat-14.bravonet.cz [77.48.225.14]) by mail.nic.cz (Postfix) with ESMTPSA id 090EF1813CB; Mon, 24 Aug 2015 21:13:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1440443594; bh=C94RldjJtFfy0DjNXWh2q7MZdI3bhkis3XqLymwy6SU=; h=From:Date:To; b=faBTt49N35JfPY8zCKFs5eBeyw/fvHtvcQU1LlOihOfdYvr8y2H2NwRmDk4rB3Gwy mxqfdXCTjc6vT02qQRHUDBe+3/fcce5rfgpwWSS8az1l8syo10VRyIBaNZhMc8MXal 4TGuaS4Cf2hy/rWPXLdz5J8Nb21Lv1KTWdwIQzb4= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: <20150824.210109.1638056143186576784.mbj@tail-f.com> Date: Mon, 24 Aug 2015 21:13:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3B7A2EA0-19F0-4D6A-9E15-AF011AD4436F@nic.cz> References: <9EB6F767-1643-4852-8B88-E79D72309E95@nic.cz> <7D38FB86-CFB2-4900-A727-A42DC1132F32@nic.cz> <20150824.210109.1638056143186576784.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Y26 again, sorry X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2015 19:13:17 -0000 > On 24 Aug 2015, at 21:01, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >>=20 >> On 24 Aug 2015, at 20:17, Andy Bierman wrote: >>> YANG does not provide any mechanism to REQUIRE modules A and B >>> to both be implemented on a server. You may think it should, but >>> currently the YANG conformance is for an individual module. >>=20 >> There are sections on conformance and conformance announcement, and >> they say nothing like this. >=20 > No Andy is correct, except that if module A augments module B, then a > server that implements A MUST also implement B. Of course, there is no way how to learn about all modules in the known = universe that augment B, but I=E2=80=99ve been always talking about the = situation where the server advertises *both* A and B.=20 I hope we all agree that the server then does implement A and B, and = both modules are part of the data model.=20 >=20 > But I don't understand what this has to do with the issue. Right, so what=E2=80=99s your answer to my question? Is the datastore = where =E2=80=9Cfoo=E2=80=9D is missing valid or not? Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Aug 24 12:20:44 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF2CE1AD35A for ; Mon, 24 Aug 2015 12:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HiqsEszOFmuC for ; Mon, 24 Aug 2015 12:20:42 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 64FE31AD356 for ; Mon, 24 Aug 2015 12:20:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=AZwxEGNoTXZzkiC1XfSveLzdt3P+fvCnXdFpmlCZANiDmYI3SDgUeOCezZrTRTOV; 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.24] (helo=mswamui-andean.atl.sa.earthlink.net) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1ZTxIK-00076k-Fr for netmod@ietf.org; Mon, 24 Aug 2015 15:20:36 -0400 Received: from 76.254.48.127 by webmail.earthlink.net with HTTP; Mon, 24 Aug 2015 15:20:36 -0400 Message-ID: <20976241.1440444036499.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> Date: Mon, 24 Aug 2015 12:20:36 -0700 (GMT-07:00) From: Randy Presuhn To: "netmod@ietf.org" Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88874d3f0892ff6d3ed3d3c506dba0a8af6efedf169a6ead1b2350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.24 Archived-At: Subject: Re: [netmod] Y26 again, sorry X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2015 19:20:44 -0000 Hi - >From: Ladislav Lhotka >Sent: Aug 24, 2015 11:44 AM >To: Andy Bierman >Cc: "netmod@ietf.org" >Subject: Re: [netmod] Y26 again, sorry ... >> YANG does not provide any mechanism to REQUIRE modules A and B >> to both be implemented on a server. You may think it should, but >> currently the YANG conformance is for an individual module. > >There are sections on conformance and conformance announcement, >and they say nothing like this. In my view, the data model comprises >*all* modules advertised by the server. I think your interpretation >of conformance might be an extrapolation from SNMP/SMI times, but, >for better or worse, it really has no support in the YANG spec. It sounds as though you might be talking past each other. I believe part of Andy's point is that clients will need to deal with servers that do not implement (and thus do not advertise) the augmenting module. But there's (I think) a more interesting issue beneath this. Let's start with module M. Let's say M is for "modem" (to pick an obsolete but widely understood resource). Two different augmenting modules, F (for FSK - frequency shift keying) and Q (for QAM - quadrature amplitude modulation) are developed. Let us say that F and Q are mutually incompatible. A system with multiple Ms could well have both M+F and M+Q modems, but (if we claim F & Q are incompatible) could not have M+F+Q. If naked M is to be prohibited in systems (also) supporting F or Q or both, we don't currently have a mechanism to do so. Randy From nobody Mon Aug 24 12:24:52 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 036471ACE76 for ; Mon, 24 Aug 2015 12:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARq4NAij65LG for ; Mon, 24 Aug 2015 12:24:49 -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 F262E1ACE5E for ; Mon, 24 Aug 2015 12:24:48 -0700 (PDT) Received: by lbbpu9 with SMTP id pu9so86323062lbb.3 for ; Mon, 24 Aug 2015 12:24: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=NLIr6DwA5poYqDl2KVA485kkk1QsIFfk75paws+o63Y=; b=JPCBmYElZVffSA9WynZ1wCqpLQrNpz78/cqsPxeHWjBs+IYzkAf9UsTMrOPCkvfMF5 GdSrm6CvXIBnmqVRfEebHuhGWlM5LpPVaMeTdMALl8qNTWlJ5Dwd1RjteO0A5/6YBBgM aVlei21vssCa2QKowbw7WBRwqO/Y34XhtLzgsGhQl8NhVvrrmfCvaishey16zKmyBxg6 P0TSz4tiyuZsn2Q+kOEpoD9UXYkGIVTFZKoBhxbj2HLl6pKsy3KUOhmxlsq80wvRa7Jf HaoE/Id8ZoUg6B26Fc2a3JndS1ubR8ss/pxI5rVsvnCsWojzXeROxIB8p/qHPRIBti7e SeRw== X-Gm-Message-State: ALoCoQkaSpz/ndMyqqbstT81r0S82UK7TvBCY9bUfZyI2wXfap3+oOw1g5oWKGUZ/K3Nb89809ai MIME-Version: 1.0 X-Received: by 10.112.141.136 with SMTP id ro8mr21910317lbb.88.1440444287507; Mon, 24 Aug 2015 12:24:47 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Mon, 24 Aug 2015 12:24:47 -0700 (PDT) In-Reply-To: <20150824.210109.1638056143186576784.mbj@tail-f.com> References: <9EB6F767-1643-4852-8B88-E79D72309E95@nic.cz> <7D38FB86-CFB2-4900-A727-A42DC1132F32@nic.cz> <20150824.210109.1638056143186576784.mbj@tail-f.com> Date: Mon, 24 Aug 2015 12:24:47 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11c343c0137b14051e1392a3 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y26 again, sorry X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2015 19:24:51 -0000 --001a11c343c0137b14051e1392a3 Content-Type: text/plain; charset=UTF-8 On Mon, Aug 24, 2015 at 12:01 PM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: > > > > On 24 Aug 2015, at 20:17, Andy Bierman wrote: > > > YANG does not provide any mechanism to REQUIRE modules A and B > > > to both be implemented on a server. You may think it should, but > > > currently the YANG conformance is for an individual module. > > > > There are sections on conformance and conformance announcement, and > > they say nothing like this. > > No Andy is correct, except that if module A augments module B, then a > server that implements A MUST also implement B. > > But I don't understand what this has to do with the issue. > > I think Lada is saying it is OK to add mandatory nodes in module A because the client should know about module A. The YANG conformance model does not at all support the concept of a placeholder subtree that will be augmented by modules, based on device capabilities like interface types supported). In this design pattern, there is nothing really to implement in the base module. In this design pattern it is very restrictive to only define optional nodes. It is clear that "augment+when" is a powerful tool that is diminished if mandatory nodes cannot be added. The problem is there is no cookie-cutter formula for a safe "when" statement. The common use-case is pick-an-identity from iana-if-type. Clearly we do not intend for a server to support every interface type just because it advertises the iana-if-types module. Also, we cannot assume the client knows about module A just because it knows about iana-if-type. IMO YANG Packages could at least convey the requirement that N of M augmenting modules MUST be present if the augmented module is supported. But it does not solve the problem of breaking old clients because new mandatory nodes are added to a new revision of a server. Andy > /martin > --001a11c343c0137b14051e1392a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Aug 24, 2015 at 12:01 PM, Martin Bjorklund &l= t;mbj@tail-f.com>= ; wrote:
Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> On 24 Aug 2015, at 20:17, Andy Bierman <andy@yumaworks.com> wrote:
> > YANG does not provide any mechanism to REQUIRE=C2=A0 modules A an= d B
> > to both be implemented on a server.=C2=A0 You may think it should= , but
> > currently the YANG conformance is for an individual module.
>
> There are sections on conformance and conformance announcement, and > they say nothing like this.

No Andy is correct, except that if module A augments module B, then a
server that implements A MUST also implement B.

But I don't understand what this has to do with the issue.



I think Lada is saying it is OK to ad= d mandatory nodes in module A
because the client should know abou= t module A.=C2=A0

The YANG conformance model does = not at all support the concept
of a placeholder subtree that will= be augmented by modules,
based on device capabilities like inter= face types supported).

In this design pattern, the= re is nothing really to implement in
the base module.=C2=A0 In th= is design pattern it is very restrictive
to only define optional = nodes.=C2=A0 It is clear that "augment+when"
is a power= ful tool that is diminished if mandatory nodes
cannot be added.

The problem is there is no cookie-cutter formula fo= r a safe "when"
statement.=C2=A0 The common use-case is= pick-an-identity from iana-if-type.
Clearly we do not intend for= a server to support every interface type
just because it adverti= ses the iana-if-types module.=C2=A0 Also, we
cannot assume the cl= ient knows about module A just because it
knows about iana-if-typ= e.

IMO YANG Packages could at least convey the req= uirement
that N of M augmenting modules MUST be present if
<= div>the augmented module is supported.=C2=A0 But it does not
solv= e the problem of breaking old clients because new mandatory
nodes= are added to a new revision of a server.


Andy








/martin

--001a11c343c0137b14051e1392a3-- From nobody Mon Aug 24 12:25:37 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49C441AD1A6 for ; Mon, 24 Aug 2015 12:25:37 -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 vrEgSQm4P07F for ; Mon, 24 Aug 2015 12:25:36 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 171731AD182 for ; Mon, 24 Aug 2015 12:25:36 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 4CF1A1AE019A; Mon, 24 Aug 2015 21:25:35 +0200 (CEST) Date: Mon, 24 Aug 2015 21:25:53 +0200 (CEST) Message-Id: <20150824.212553.1421049984260058928.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <3B7A2EA0-19F0-4D6A-9E15-AF011AD4436F@nic.cz> References: <7D38FB86-CFB2-4900-A727-A42DC1132F32@nic.cz> <20150824.210109.1638056143186576784.mbj@tail-f.com> <3B7A2EA0-19F0-4D6A-9E15-AF011AD4436F@nic.cz> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Y26 again, sorry X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2015 19:25:37 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+ID4gT24gMjQgQXVn IDIwMTUsIGF0IDIxOjAxLCBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4gd3JvdGU6 DQo+ID4gDQo+ID4gTGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gPj4g DQo+ID4+IE9uIDI0IEF1ZyAyMDE1LCBhdCAyMDoxNywgQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3 b3Jrcy5jb20+IHdyb3RlOg0KPiA+Pj4gWUFORyBkb2VzIG5vdCBwcm92aWRlIGFueSBtZWNoYW5p c20gdG8gUkVRVUlSRSAgbW9kdWxlcyBBIGFuZCBCDQo+ID4+PiB0byBib3RoIGJlIGltcGxlbWVu dGVkIG9uIGEgc2VydmVyLiAgWW91IG1heSB0aGluayBpdCBzaG91bGQsIGJ1dA0KPiA+Pj4gY3Vy cmVudGx5IHRoZSBZQU5HIGNvbmZvcm1hbmNlIGlzIGZvciBhbiBpbmRpdmlkdWFsIG1vZHVsZS4N Cj4gPj4gDQo+ID4+IFRoZXJlIGFyZSBzZWN0aW9ucyBvbiBjb25mb3JtYW5jZSBhbmQgY29uZm9y bWFuY2UgYW5ub3VuY2VtZW50LCBhbmQNCj4gPj4gdGhleSBzYXkgbm90aGluZyBsaWtlIHRoaXMu DQo+ID4gDQo+ID4gTm8gQW5keSBpcyBjb3JyZWN0LCBleGNlcHQgdGhhdCBpZiBtb2R1bGUgQSBh dWdtZW50cyBtb2R1bGUgQiwgdGhlbiBhDQo+ID4gc2VydmVyIHRoYXQgaW1wbGVtZW50cyBBIE1V U1QgYWxzbyBpbXBsZW1lbnQgQi4NCj4gDQo+IE9mIGNvdXJzZSwgdGhlcmUgaXMgbm8gd2F5IGhv dyB0byBsZWFybiBhYm91dCBhbGwgbW9kdWxlcyBpbiB0aGUga25vd24NCj4gdW5pdmVyc2UgdGhh dCBhdWdtZW50IEIsIGJ1dCBJ4oCZdmUgYmVlbiBhbHdheXMgdGFsa2luZyBhYm91dCB0aGUNCj4g c2l0dWF0aW9uIHdoZXJlIHRoZSBzZXJ2ZXIgYWR2ZXJ0aXNlcyAqYm90aCogQSBhbmQgQi4NCj4g DQo+IEkgaG9wZSB3ZSBhbGwgYWdyZWUgdGhhdCB0aGUgc2VydmVyIHRoZW4gZG9lcyBpbXBsZW1l bnQgQSBhbmQgQiwgYW5kDQo+IGJvdGggbW9kdWxlcyBhcmUgcGFydCBvZiB0aGUgZGF0YSBtb2Rl bC4NCj4gDQo+ID4gDQo+ID4gQnV0IEkgZG9uJ3QgdW5kZXJzdGFuZCB3aGF0IHRoaXMgaGFzIHRv IGRvIHdpdGggdGhlIGlzc3VlLg0KPiANCj4gUmlnaHQsIHNvIHdoYXTigJlzIHlvdXIgYW5zd2Vy IHRvIG15IHF1ZXN0aW9uPyBJcyB0aGUgZGF0YXN0b3JlIHdoZXJlDQo+IOKAnGZvb+KAnSBpcyBt aXNzaW5nIHZhbGlkIG9yIG5vdD8NCg0KVGhlIGRhdGEgbW9kZWwgd2FzOg0KDQogIGF1Z21lbnQg Ii9pZjppbnRlcmZhY2VzIiB7DQogICAgY29udGFpbmVyIHRvcCB7DQogICAgICBtdXN0ICJmb28i Ow0KICAgICAgbGVhZiBhY2NlcHQgew0KICAgICAgICB0eXBlIGJvb2xlYW47DQogICAgICAgIGRl ZmF1bHQgdHJ1ZTsNCiAgICAgIH0NCiAgICAgIGxlYWYgZm9vIHsNCiAgICAgICAgdHlwZSBlbXB0 eTsNCiAgICAgIH0NCiAgICB9DQogIH0NCg0KYW5kIHdpdGggY3VycmVudCA2MDIwYmlzLCB3aGlj aCBpbmNsdWRlcyBZNDEtMDEsIHRoaXMgaW5kZWVkIGhhcyB0aGUNCnNhbWUgZWZmZWN0IGFzIGF1 Z21lbnRpbmcgYSBtYW5kYXRvcnkgbm9kZS4NCg0KDQovbWFydGluDQo= From nobody Mon Aug 24 14:05:45 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22D471B2B04 for ; Mon, 24 Aug 2015 14:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.322 X-Spam-Level: X-Spam-Status: No, score=0.322 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MANGLED_FORM=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bpz_T2ORUa5s for ; Mon, 24 Aug 2015 14:05:42 -0700 (PDT) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A6E31B2A1E for ; Mon, 24 Aug 2015 14:05:42 -0700 (PDT) Received: by lbcbn3 with SMTP id bn3so87544913lbc.2 for ; Mon, 24 Aug 2015 14:05:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qX5TaNgMc/nwbTCCWMjJUX3V9QJ2bub40jf6uUPb7p0=; b=VQBj5FLMSR2JCbfMvhZLDHynpkJX3iFAiIe19Y1Tr9XugP7l53LcpFBqKn1qdTDA0o uY+LL21DjBDkjhDzOdAsiGXSrSa/LqX2SqHpZf6MxIJLN7Tk0yttGCXTO2cElpqFrIjd vLZ2jO6fiIQTLGqO7HJKaqrwKeWAzZVAeThlX8ozCDUI6E5BK1I+eMDq0L/PBrY3UFyX nISdcgr7Kueo9h9wKPfBvoGQA6U4mzDJwYhs6KUc/OijbMtDv4LZ6vW6RJyfOUP4g5a5 G7tNiwHRG7b/mDqb7xJkKNHAmPXyk+kJjurMhZq9/+zD/YsjHVPZKv4fR3/n6nxRHQB1 fhXw== X-Gm-Message-State: ALoCoQk68cBG7mkEFYVC7uM++p1AldXDpMCwGTysVIRiGFVpGt2I86mPMWvBwHBK4GK2rrrCNENC MIME-Version: 1.0 X-Received: by 10.152.120.74 with SMTP id la10mr21761509lab.37.1440450340651; Mon, 24 Aug 2015 14:05:40 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Mon, 24 Aug 2015 14:05:40 -0700 (PDT) In-Reply-To: <20976241.1440444036499.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> References: <20976241.1440444036499.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> Date: Mon, 24 Aug 2015 14:05:40 -0700 Message-ID: From: Andy Bierman To: Randy Presuhn Content-Type: multipart/alternative; boundary=089e01229022df199f051e14fad5 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y26 again, sorry X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2015 21:05:44 -0000 --089e01229022df199f051e14fad5 Content-Type: text/plain; charset=UTF-8 On Mon, Aug 24, 2015 at 12:20 PM, Randy Presuhn < randy_presuhn@mindspring.com> wrote: > Hi - > > >From: Ladislav Lhotka > >Sent: Aug 24, 2015 11:44 AM > >To: Andy Bierman > >Cc: "netmod@ietf.org" > >Subject: Re: [netmod] Y26 again, sorry > ... > >> YANG does not provide any mechanism to REQUIRE modules A and B > >> to both be implemented on a server. You may think it should, but > >> currently the YANG conformance is for an individual module. > > > >There are sections on conformance and conformance announcement, > >and they say nothing like this. In my view, the data model comprises > >*all* modules advertised by the server. I think your interpretation > >of conformance might be an extrapolation from SNMP/SMI times, but, > >for better or worse, it really has no support in the YANG spec. > > It sounds as though you might be talking past each other. > I believe part of Andy's point is that clients will need to deal > with servers that do not implement (and thus do not advertise) > the augmenting module. But there's (I think) a more interesting > issue beneath this. > > Let's start with module M. Let's say M is for "modem" (to pick > an obsolete but widely understood resource). > Two different augmenting modules, F (for FSK - frequency > shift keying) and Q (for QAM - quadrature amplitude modulation) > are developed. Let us say that F and Q are mutually incompatible. > > A system with multiple Ms could well have both M+F and M+Q modems, > but (if we claim F & Q are incompatible) could not have M+F+Q. > If naked M is to be prohibited in systems (also) supporting F or Q > or both, we don't currently have a mechanism to do so. > > When I examine the module M, I have absolutely no way of knowing about F or Q. Where are the instructions to the developers that only M+F or M+Q is allowed, and never M or M+F+Q? Where would they go except M or a stand-alone document describing M+* ? If these instructions are not in M, F, or Q, then how will developers find it? It seems we would need a way to say that conformance to M is not meaningful. Only conformance to M+? is meaningful (where M can define the requirements for ?) > Randy > > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --089e01229022df199f051e14fad5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Aug 24, 2015 at 12:20 PM, Randy Presuhn <<= a href=3D"mailto:randy_presuhn@mindspring.com" target=3D"_blank">randy_pres= uhn@mindspring.com> wrote:
= Hi -

>From: Ladislav Lhotka <lhotka@nic.c= z>
>Sent: Aug 24, 2015 11:44 AM
>To: Andy Bierman <andy@yumawor= ks.com>
>Cc: "netmod@ietf.org" = <netmod@ietf.org>
>Subject: Re: [netmod] Y26 again, sorry
...
>> YANG does not provide any mechanism to REQUIRE=C2=A0 modules A and= B
>> to both be implemented on a server.=C2=A0 You may think it should,= but
>> currently the YANG conformance is for an individual module.
>
>There are sections on conformance and conformance announcement,
>and they say nothing like this. In my view, the data model comprises >*all* modules advertised by the server. I think your interpretation
>of conformance might be an extrapolation from SNMP/SMI times, but,
>for better or worse, it really has no support in the YANG spec.

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

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

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


When I examine the module M, I have ab= solutely no way of knowing
about F or Q.=C2=A0 Where are the inst= ructions to the developers that only
M+F or M+Q is allowed, and n= ever M or M+F+Q?=C2=A0 Where would they
go except M or a stand-al= one document describing M+* ?

If these instruction= s are not in M, F, or Q, then how will
developers find it?=C2=A0 = It seems we would need a way to
say that conformance to M is not = meaningful.
Only conformance to =C2=A0M+? is meaningful
(where M can define the requirements for ?)


<= /div>
=C2=A0
Randy


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

--089e01229022df199f051e14fad5-- From nobody Mon Aug 24 14:24:14 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D50961B2B8A for ; Mon, 24 Aug 2015 14:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.211 X-Spam-Level: X-Spam-Status: No, score=-12.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_FORM=2.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-KWRmmYe7pl for ; Mon, 24 Aug 2015 14:24:08 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA06F1B2B2E for ; Mon, 24 Aug 2015 14:24:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2352; q=dns/txt; s=iport; t=1440451448; x=1441661048; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=SIRPf5oN7OJ3NYEuY7NtPyN9bz9PO7DO1TMPlWH/5UM=; b=FAa1O2GYCbATr6+dcS9RUmadb1pGAV5jUVYscjf27We4yHTx9eGaqknK V71dEbaR4sma42RkBD2qBRUz3rG09OTrBMJE5U2m0tMhr1QGLjzrhL2FV DM+c9GYHM/Snufr8V/D7bKwmu0R9iGX0g+yzyXBg5itPwX/T2jgS/QIhZ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BFAgAnittV/xbLJq1dg29pvXQBCYFtCoUxSgKBbBQBAQEBAQEBgQqEIwEBAQMBAQEBNTYKEQsRBAEBAQkWDwkDAgECARUoCAYBDAYCAQGIIggNxygBAQEBAQEBAQEBAQEBAQEBAQEBAQETBItXhD9ShCwBBJU0jHKBS4cpjXKDaiaDfz0zgkwBAQE X-IronPort-AV: E=Sophos;i="5.15,741,1432598400"; d="scan'208";a="611161943" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 24 Aug 2015 21:24:06 +0000 Received: from [10.61.75.177] (ams3-vpn-dhcp2993.cisco.com [10.61.75.177]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t7OLO5ue025887; Mon, 24 Aug 2015 21:24:05 GMT To: Randy Presuhn , "netmod@ietf.org" References: <20976241.1440444036499.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> From: Robert Wilton Message-ID: <55DB8B75.7020001@cisco.com> Date: Mon, 24 Aug 2015 22:24:05 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20976241.1440444036499.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Y26 again, sorry X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2015 21:24:10 -0000 Hi Randy, On 24/08/2015 20:20, Randy Presuhn wrote: > Hi - > >> From: Ladislav Lhotka >> Sent: Aug 24, 2015 11:44 AM >> To: Andy Bierman >> Cc: "netmod@ietf.org" >> Subject: Re: [netmod] Y26 again, sorry > ... >>> YANG does not provide any mechanism to REQUIRE modules A and B >>> to both be implemented on a server. You may think it should, but >>> currently the YANG conformance is for an individual module. >> There are sections on conformance and conformance announcement, >> and they say nothing like this. In my view, the data model comprises >> *all* modules advertised by the server. I think your interpretation >> of conformance might be an extrapolation from SNMP/SMI times, but, >> for better or worse, it really has no support in the YANG spec. > It sounds as though you might be talking past each other. > I believe part of Andy's point is that clients will need to deal > with servers that do not implement (and thus do not advertise) > the augmenting module. But there's (I think) a more interesting > issue beneath this. > > Let's start with module M. Let's say M is for "modem" (to pick > an obsolete but widely understood resource). > Two different augmenting modules, F (for FSK - frequency > shift keying) and Q (for QAM - quadrature amplitude modulation) > are developed. Let us say that F and Q are mutually incompatible. > > A system with multiple Ms could well have both M+F and M+Q modems, > but (if we claim F & Q are incompatible) could not have M+F+Q. > If naked M is to be prohibited in systems (also) supporting F or Q > or both, we don't currently have a mechanism to do so. Could this be achieved by augmenting from a choice statement? M defines the choice statement but with no case statements. F and Q both implement separate case statements that augment the choice statement in M. The case statements have containers which hold the parameters related to F or Q. M without F or Q is meaningless. M+F or M+Q works, but the choice statement means that you cannot have M+F+Q. I can point you to a concrete example if it helps. Thanks, Rob > > Randy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Mon Aug 24 14:50:58 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD471B2AD8 for ; Mon, 24 Aug 2015 14:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.322 X-Spam-Level: X-Spam-Status: No, score=0.322 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MANGLED_FORM=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRMU4zg-P1eh for ; Mon, 24 Aug 2015 14:50:54 -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 D26A41B2B9A for ; Mon, 24 Aug 2015 14:50:50 -0700 (PDT) Received: by lbbsx3 with SMTP id sx3so88350869lbb.0 for ; Mon, 24 Aug 2015 14:50:49 -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=LWD1YPPjmVi74jnD2PmQ8I6ADRCaazvtnilyCeG+7to=; b=jqlMZ1WwAB9r6DTuGIYg2d3SZkUDjxJUcaFj9deKxxLwv4X/HR4j7NCWdbH1yZ9kN3 vDkOYeydOAIwqK5ejZvC+siWT+3hjEAuAe5K/30m347ynMpJXJfRjSytLM7EzkE5OyTy C97xpXKEBrh9CXrXF6XeZID5qRDYIjlz6pe+d46B0fbkHNSlVC/Glz7LxFeM4dH6+rQF gMYOajDND/cUCD+wbyGal3dSAlC60hU/pjP/mErM87xmS0iSROv0Mi439/jhGpn1qIYI kLzTC+diVPnmXenM6IZxprHsYOu6Awy9uqguj02nA+WDLkX3S7r/6GKygv77AHcIGC6p UfLQ== X-Gm-Message-State: ALoCoQmEi8fqDyhsg+s7WuCye43f2z6xyJEZZvxalHy2ehm7clB+77m+3OmIeOMfy0ssGFgziw77 MIME-Version: 1.0 X-Received: by 10.112.161.232 with SMTP id xv8mr22345897lbb.123.1440453049264; Mon, 24 Aug 2015 14:50:49 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Mon, 24 Aug 2015 14:50:49 -0700 (PDT) In-Reply-To: <55DB8B75.7020001@cisco.com> References: <20976241.1440444036499.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> <55DB8B75.7020001@cisco.com> Date: Mon, 24 Aug 2015 14:50:49 -0700 Message-ID: From: Andy Bierman To: Robert Wilton Content-Type: multipart/alternative; boundary=001a11c3c46c5144e1051e159c76 Archived-At: Cc: Randy Presuhn , "netmod@ietf.org" Subject: Re: [netmod] Y26 again, sorry X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2015 21:50:56 -0000 --001a11c3c46c5144e1051e159c76 Content-Type: text/plain; charset=UTF-8 On Mon, Aug 24, 2015 at 2:24 PM, Robert Wilton wrote: > Hi Randy, > > On 24/08/2015 20:20, Randy Presuhn wrote: > >> Hi - >> >> From: Ladislav Lhotka >>> Sent: Aug 24, 2015 11:44 AM >>> To: Andy Bierman >>> Cc: "netmod@ietf.org" >>> Subject: Re: [netmod] Y26 again, sorry >>> >> ... >> >>> YANG does not provide any mechanism to REQUIRE modules A and B >>>> to both be implemented on a server. You may think it should, but >>>> currently the YANG conformance is for an individual module. >>>> >>> There are sections on conformance and conformance announcement, >>> and they say nothing like this. In my view, the data model comprises >>> *all* modules advertised by the server. I think your interpretation >>> of conformance might be an extrapolation from SNMP/SMI times, but, >>> for better or worse, it really has no support in the YANG spec. >>> >> It sounds as though you might be talking past each other. >> I believe part of Andy's point is that clients will need to deal >> with servers that do not implement (and thus do not advertise) >> the augmenting module. But there's (I think) a more interesting >> issue beneath this. >> >> Let's start with module M. Let's say M is for "modem" (to pick >> an obsolete but widely understood resource). >> Two different augmenting modules, F (for FSK - frequency >> shift keying) and Q (for QAM - quadrature amplitude modulation) >> are developed. Let us say that F and Q are mutually incompatible. >> >> A system with multiple Ms could well have both M+F and M+Q modems, >> but (if we claim F & Q are incompatible) could not have M+F+Q. >> If naked M is to be prohibited in systems (also) supporting F or Q >> or both, we don't currently have a mechanism to do so. >> > Could this be achieved by augmenting from a choice statement? > > M defines the choice statement but with no case statements. > > F and Q both implement separate case statements that augment the choice > statement in M. The case statements have containers which hold the > parameters related to F or Q. > > M without F or Q is meaningless. > M+F or M+Q works, but the choice statement means that you cannot have > M+F+Q. > > nice solution This is perhaps the cleanest way to add mandatory nodes to a module. The old client will not attempt to create the new case. As I said before, I am OK with changing MUST NOT to SHOULD NOT add mandatory nodes, and then add MAY when X, Y, Z conditions are met. Two conditions so far: (1) augment + when (2) augment choice with a new case-stmt (1) is hard to define, but not (2) I can point you to a concrete example if it helps. > > Thanks, > Rob > > > >> Andy > Randy >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a11c3c46c5144e1051e159c76 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Aug 24, 2015 at 2:24 PM, Robert Wilton <rwilton@cisco.com&= gt; wrote:
Hi Randy,

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

From: Ladislav Lhotka <lhotka@nic.cz>
Sent: Aug 24, 2015 11:44 AM
To: Andy Bierman <andy@yumaworks.com>
Cc: "netmod@ietf.= org" <netm= od@ietf.org>
Subject: Re: [netmod] Y26 again, sorry
...
YANG does not provide any mechanism to REQUIRE=C2=A0 modules A and B
to both be implemented on a server.=C2=A0 You may think it should, but
currently the YANG conformance is for an individual module.
There are sections on conformance and conformance announcement,
and they say nothing like this. In my view, the data model comprises
*all* modules advertised by the server. I think your interpretation
of conformance might be an extrapolation from SNMP/SMI times, but,
for better or worse, it really has no support in the YANG spec.
It sounds as though you might be talking past each other.
I believe part of Andy's point is that clients will need to deal
with servers that do not implement (and thus do not advertise)
the augmenting module.=C2=A0 But there's (I think) a more interesting issue beneath this.

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

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

M defines the choice statement but with no case statements.

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

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


nice solution

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

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

Two conditions so far:
=

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

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

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

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

Thanks,
Rob





Andy
=

=C2=A0
Randy

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


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

--001a11c3c46c5144e1051e159c76-- From nobody Mon Aug 24 19:14:22 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 642761ACE41 for ; Mon, 24 Aug 2015 19:14:21 -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 cAHCu7L7khWo for ; Mon, 24 Aug 2015 19:14:18 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0122.outbound.protection.outlook.com [65.55.169.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD22F1A9150 for ; Mon, 24 Aug 2015 19:14:16 -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.231.21; Tue, 25 Aug 2015 02:14:13 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.150]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.150]) with mapi id 15.01.0231.024; Tue, 25 Aug 2015 02:14:14 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: review of draft-openconfig-netmod-opstate-01 Thread-Index: AQHQ3tu8vk8YCUirU0+DLVhHvjJZNg== Date: Tue, 25 Aug 2015 02:14:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.13] x-microsoft-exchange-diagnostics: 1; CO1PR05MB460; 5:jKcWNAuoF8kIFhwjv6LUa0GEjyjdB2ao9qRgXentjUVVIKw7j93cVZ97XpiNkVgoRQ6deGbEuBp5bWgDsqTEOF/h6q45f5p4if68+4t1zLZdRgr10ik2PjLoVyJYfEO2PIQc+njfGGuoMtpYZJaWpw==; 24:jqnxR+JCyaJUzxhkJh5kI3F/cqpwYzEEeLXOxPsGnHZS0+48TXecZUpPbOIg+IQkP/4lgYARY++ca63n2nn9/jcO4D/Rsq6EstpqXqUNFf0=; 20:/WU5RTdwjl1pO0EhRcdigwFuTDOc2oxq7CqZ6dqBArZvgwAxl+k/9Fr4EPE0Kv8zEj09amXKER2tO3xSGoKRdw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB460; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(8121501046)(5005006)(3002001); SRVR:CO1PR05MB460; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB460; x-forefront-prvs: 06793E740F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(43234003)(164054003)(5001830100001)(101416001)(40100003)(5001960100002)(5007970100001)(5001920100001)(2351001)(99286002)(5002640100001)(230783001)(105586002)(106116001)(5001860100001)(97736004)(106356001)(110136002)(36756003)(5004730100002)(16236675004)(50986999)(122556002)(64706001)(2501003)(102836002)(46102003)(99936001)(2656002)(229853001)(189998001)(66066001)(83506001)(87936001)(4001350100001)(92566002)(77156002)(68736005)(62966003)(2900100001)(10400500002)(5890100001)(86362001)(4001540100001)(81156007)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/mixed; boundary="_004_D20147B2D28DEkwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Aug 2015 02:14:13.4308 (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: "draft-openconfig-netmod-opstate@tools.ietf.org" Subject: [netmod] review of draft-openconfig-netmod-opstate-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 02:14:21 -0000 --_004_D20147B2D28DEkwatsenjunipernet_ Content-Type: multipart/alternative; boundary="_000_D20147B2D28DEkwatsenjunipernet_" --_000_D20147B2D28DEkwatsenjunipernet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [As a contributor] Section 2 defines the term "applied configuration". It's clear that appli= ed configuration has the same data model as the intended configuration, but= in how many ways might it not be the same? So far, I understand differenc= es including 1) the intended configuration is still being processed (not ye= t applied) and 2) some configuration knobs taking on protocol negotiated va= lues (e.g., MTU and duplex). What else is there? Also in Section 2, the end of the 6th paragraph states "To this end, operat= ional state information can be considered to be 'unknown' to the network ma= nager." - what does this mean? - isn't it just a matter of the NMS pollin= g on this YANG-modeled data? Still in Section 2, paragraph 7 does provide more definition to "applied co= nfiguration" (merge with above?), but I'm unclear about the line card depen= dency part. I would've thought that configuration destined to a missing l= ine card would be present, albeit inactive. Assuming an datasto= re, would a source=3D=3Dapplied have the linecard's configurat= ions missing? If so, then what about unconfigured interfaces, would the= y show up as "applied" configuration with their default/system-provided con= figurations? [update: this is related to Section 7, #3) And yet again in Section 2, Figure 1 and text just below it don't square up= . The applied config is shown as having the same leaves as the intended co= nfig, and is listed below the line marked config: false. Also, the text sa= ys "Only derived state is marked as operational data" and while I also see = "operational:true" in Figure 1, this is a forward reference to Section 9.1,= which is confusing. Attached is a picture illustrating my view on this. In Section 4,1, the last sentence says "This is not considered in [RFC6244]= ". Indeed, and there may be a need to do a 6244bis now...to address a num= ber of new items including the intended and ephemeral datastores as well. Section 4.2 discusses synchronous versus asynchronous. The point of this s= ection seems to impress the reader about the need for asynchronous. That = said, all we have today is asynchronous, albeit without the defined applied= data stores. But I'm now more interested in the synchronous requirement = - is such a thing actually needed? Is it something that the NMS should han= dle instead? Section 6 says "Below we show an example model structure that meets the req= uirements described above for all three types of data we are considering". = This Section seems disconnected to the rest of the draft, which has little= to do with model structure, with exception to Section 5.2. It seems that= this entire section should be removed from the draft (use model-structure = draft for this instead). Thanks, Kent --_000_D20147B2D28DEkwatsenjunipernet_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <37E37F52AFABEB458D1286D4B45233B1@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
[As a contributor]

Section 2 defines the term "applied configuration".   It's c= lear that applied configuration has the same data model as the intended con= figuration, but in how many ways might it not be the same?  So far, I = understand differences including 1) the intended configuration is still being processed (not yet applied) and 2) some configuration knobs= taking on protocol negotiated values (e.g., MTU and duplex).  What el= se is there? 

Also in Section 2, the end of the 6th par= agraph states "To this end, operational state information can be consi= dered to be '= unknown' to the network manager." - what does this mean?   - isn't it just a matter of the NMS polling on this YANG= -modeled data?

Still in Section 2, paragraph 7 does prov= ide more definition to "applied configuration" (merge with above?= ), but I'm unclear about the line card dependency part.  &nb= sp;I would've thought that configuration destined to a missing = line card would be present, albeit inactive.   Assuming an <applied>= datastore, would a <get-config> source=3D=3Dapplied have the linecar= d's configurations missing?    If so, then what about  uncon= figured interfaces, would they show up as "applied" configuration= with their default/system-provided configurations?  [update: this is relat= ed to Section 7, #3)

And yet again in Section 2, Figure 1 and = text just below it don't square up.  The applied config is shown as ha= ving the same leaves as the intended config, and is listed below the line m= arked config: false.  Also, the text says "Only derived state is marke= d as operational data" and while I also see "operational:true" in Figure 1, this is a for= ward reference to Section 9.1, which is confusing.  Attached is a picture illustrating my view on this.

In Section 4,1, the last sentence says &q= uot;This is not considered in [RFC= 6244]".   Indeed, and there may be a need to do a 6244bis now...t= o address a number of new items including the intended and ephemeral datastores as well.

Section 4.2 discusses synchronous versus = asynchronous.  The point of this section seems to impress the  re= ader about the need for asynchronous.  That said, all we have today is= asynchronous, albeit without the defined applied data stores.   But I'm now more interested in the synchronous re= quirement – is such a thing actually needed?  Is it so= mething that the NMS should handle instead?

Section 6 says "Below we show an example model structure that mee= ts the requirements described above for all three types of data we are cons= idering".  This Section seems disconnected to the rest of the dra= ft, which has little to do with model structure, with exception to Section 5.2.   It seems that this entire section sh= ould be removed from the draft (use model-structure draft for this instead)= .

Thanks,
Kent




--_000_D20147B2D28DEkwatsenjunipernet_-- --_004_D20147B2D28DEkwatsenjunipernet_ Content-Type: image/png; name="datastores.png" Content-Description: datastores.png Content-Disposition: attachment; filename="datastores.png"; size=236649; creation-date="Tue, 25 Aug 2015 02:14:13 GMT"; modification-date="Tue, 25 Aug 2015 02:14:13 GMT" Content-ID: <7CD73D74305D0D4EA18BD7EDB0486DDF@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAABhwAAASQCAYAAAAHheVnAAAMFWlDQ1BJQ0MgUHJvZmlsZQAASImV lwdYU8kWx+eWFEISSiACUkJvgvQqvXekg42QBAglhEBQsSOLCq5dRLCiqyAKrgWQxYa9LIK9L4io rKyLBSyovEkC6PO9/d73Jt/c+8uZc879z2TmZgYABTu2UJiFKgKQLcgXRQV4sxISk1ikPwAZUOCH BShsTp7QKzIyFPxjGboNEMn9hoUk1z/7/deixOXlcQBAIiGncPM42ZCPAIBrcISifAAIHdCuPztf KOF3kFVEUCAARLKE02SsKeEUGVtJfWKifCD7AkCmstmiNADokvysAk4azEMXQrYScPkCyDsgu3PS 2VzIXZAnZWfnQFagQjZJ+S5P2r/lTBnPyWanjbOsL9JC9uXnCbPYc//P4fjfJTtLPPYMPVip6aLA KEmf4bjVZOaESBhqR1oFKeERkJUhX+Rzpf4Svp8uDowd9e/n5PnAMQNMAFDAZfuGQIZjiTLFmbFe o2zDFkljoT8azs8PihnlFFFO1Gh+tICX5xc9xum8oNDRnMsFWeFjvC2V7x8EGc409Ehheky8TCd6 toAfFw6ZDrkjLzM6ZNT/cWG6T/iYj0gcJdFsAPldqsg/SuaDqWXnjfULs+SwpRrUIHvmp8cEymKx BF5eQuiYNi7P10+mAePyBLGjmjE4u7yjRmNLhFmRo/7YNl5WQJRsnLGDeQXRY7HX8+EEk40D9iSD HRwp048NCfMjY2TacByEAh/gC1eQGNYUkAMyAL+9v6kffpO1+AM2EIE0wAMWo5axiHhpiwBeo0Eh +AsSD+SNx3lLW3mgANq/jFtlVwuQKm0tkEZkgmeQs3EN3B13xUPh1RNWG9wJdx6LYymMPZXoR/Ql BhL9iabjOjhQdRasIsD/T9u3SMIzQifhCeEWoYtwD4TAVh7ss0ShYLxnceCpNMvo91n8ItEPylkg DHTBOP/R3qXA6L4xH9wIqrbHvXE3qB9qx5m4BrDA7WBPvHAP2Dd7aP1eoXhcxbex/PF5En3f93HU Tjej24+qSBnX7zPu9WMWn+/GiAvvIT96Ysuxw9gF7DR2CWvFmgALO4k1Y1ex4xIenwlPpTNh7GlR Um2ZMA9/zMeqzqrP6vN/PJ09qkAk/b1BPm9OvmRB+OQI54r4aen5LC/4RuaxggQcy0ksGytrewAk 73fZ6+MtU/reRpiXv9lyTwHgXAqNad9sbH0Ajj0DgDH0zab/Bi6vNQAc7+CIRQUyGy65EOC/hgJc GepAG+gDE9gnG+AAXIEn8APBIALEgEQwE456OsiGqmeD+WAJKAFlYA3YCCrBdrAL1IAD4BBoAq3g NDgProAOcAs8gHOjF7wEA2AIDCMIQkJoCANRR3QQQ8QcsUGcEHfEDwlFopBEJBlJQwSIGJmPLEXK kHVIJbITqUV+RY4hp5FLSCdyD+lG+pA3yCcUQ6moCqqFGqGTUSfUCw1BY9AZaBqaixaixegqtAKt Rvejjehp9Ap6C+1CX6KDGMDkMSami1lgTpgPFoElYamYCFuIlWLlWDVWj7XA3/oG1oX1Yx9xIs7A WbgFnJ+BeCzOwXPxhfhKvBKvwRvxs/gNvBsfwL8SaARNgjnBhRBESCCkEWYTSgjlhD2Eo4RzcEX1 EoaIRCKTaEx0hGszkZhBnEdcSdxKbCCeInYSe4iDJBJJnWROciNFkNikfFIJaTNpP+kk6Tqpl/SB LE/WIduQ/clJZAG5iFxO3kc+Qb5Ofk4ellOUM5RzkYuQ48rNlVstt1uuRe6aXK/cMEWJYkxxo8RQ MihLKBWUeso5ykPKW3l5eT15Z/mp8nz5xfIV8gflL8p3y3+kKlPNqD7U6VQxdRV1L/UU9R71LY1G M6J50pJo+bRVtFraGdpj2gc6g25JD6Jz6YvoVfRG+nX6KwU5BUMFL4WZCoUK5QqHFa4p9CvKKRop +iiyFRcqVikeU7yjOKjEULJWilDKVlqptE/pktILZZKykbKfMle5WHmX8hnlHgbG0Gf4MDiMpYzd jHOMXhWiirFKkEqGSpnKAZV2lQFVZVU71TjVOapVqsdVu5gY04gZxMxirmYeYt5mfpqgNcFrAm/C ign1E65PeK82Uc1TjadWqtagdkvtkzpL3U89U32tepP6Iw1cw0xjqsZsjW0a5zT6J6pMdJ3ImVg6 8dDE+5qopplmlOY8zV2aVzUHtbS1ArSEWpu1zmj1azO1PbUztDdon9Du02HouOvwdTbonNT5k6XK 8mJlsSpYZ1kDupq6gbpi3Z267brDesZ6sXpFeg16j/Qp+k76qfob9Nv0Bwx0DMIM5hvUGdw3lDN0 Mkw33GR4wfC9kbFRvNEyoyajF8ZqxkHGhcZ1xg9NaCYeJrkm1SY3TYmmTqaZpltNO8xQM3uzdLMq s2vmqLmDOd98q3nnJMIk50mCSdWT7lhQLbwsCizqLLotmZahlkWWTZavJhtMTpq8dvKFyV+t7K2y rHZbPbBWtg62LrJusX5jY2bDsamyuWlLs/W3XWTbbPvaztyOZ7fN7q49wz7Mfpl9m/0XB0cHkUO9 Q5+jgWOy4xbHO04qTpFOK50uOhOcvZ0XObc6f3RxcMl3OeTyt6uFa6brPtcXU4yn8KbsntLjpufG dtvp1uXOck923+He5aHrwfao9njiqe/J9dzj+dzL1CvDa7/XK28rb5H3Ue/3Pi4+C3xO+WK+Ab6l vu1+yn6xfpV+j/31/NP86/wHAuwD5gWcCiQEhgSuDbwTpBXECaoNGgh2DF4QfDaEGhIdUhnyJNQs VBTaEoaGBYetD3sYbhguCG+KABFBEesjHkUaR+ZG/jaVODVyatXUZ1HWUfOjLkQzomdF74seivGO WR3zINYkVhzbFqcQNz2uNu59vG/8uviuhMkJCxKuJGok8hObk0hJcUl7kgan+U3bOK13uv30kum3 ZxjPmDPj0kyNmVkzj89SmMWedTiZkByfvC/5MzuCXc0eTAlK2ZIywPHhbOK85HpyN3D7eG68dbzn qW6p61JfpLmlrU/rS/dIL0/v5/vwK/mvMwIztme8z4zI3Js5khWf1ZBNzk7OPiZQFmQKzuZo58zJ 6RSaC0uEXbkuuRtzB0Qhoj15SN6MvOZ8FbjVuSo2Ef8k7i5wL6gq+DA7bvbhOUpzBHOuzjWbu2Lu 80L/wl/m4fM489rm685fMr97gdeCnQuRhSkL2xbpLype1Ls4YHHNEsqSzCW/F1kVrSt6tzR+aUux VvHi4p6fAn6qK6GXiEruLHNdtn05vpy/vH2F7YrNK76Wcksvl1mVlZd9XslZefln658rfh5Zlbqq fbXD6m1riGsEa26v9Vhbs05pXeG6nvVh6xs3sDaUbni3cdbGS+V25ds3UTaJN3VVhFY0bzbYvGbz 58r0yltV3lUNWzS3rNjyfit36/Vtntvqt2ttL9v+aQd/x92dATsbq42qy3cRdxXserY7bveFX5x+ qd2jsadsz5e9gr1dNVE1Z2sda2v3ae5bXYfWiev69k/f33HA90BzvUX9zgZmQ9lBcFB88M9fk3+9 fSjkUNthp8P1RwyPbDnKOFraiDTObRxoSm/qak5s7jwWfKytxbXl6G+Wv+1t1W2tOq56fPUJyoni EyMnC08OnhKe6j+ddrqnbVbbgzMJZ26enXq2/VzIuYvn/c+fueB14eRFt4utl1wuHbvsdLnpisOV xqv2V4/+bv/70XaH9sZrjteaO5w7WjqndJ647nH99A3fG+dvBt28civ8Vuft2Nt370y/03WXe/fF vax7r+8X3B9+sPgh4WHpI8VH5Y81H1f/YfpHQ5dD1/Fu3+6rT6KfPOjh9Lx8mvf0c2/xM9qz8uc6 z2tf2Lxo7fPv6/hz2p+9L4Uvh/tL/lL6a8srk1dH/vb8++pAwkDva9HrkTcr36q/3fvO7l3bYOTg 46HsoeH3pR/UP9R8dPp44VP8p+fDsz+TPld8Mf3S8jXk68OR7JERIVvElm4FMFjR1FQA3uwFgJYI 9w7wHEehy85f0oLIzoxSAv/EsjOatDgAsNcTgNjFAITCPco2WA0hU+Fdsv2O8QSore14HS15qbY2 slxUeIohfBgZeasFAKkFgC+ikZHhrSMjX3ZDsfcAOJUrO/dJChHu8XfQJXSpfeVi8EP5F4RkbAmB xhnfAAAACXBIWXMAABYlAAAWJQFJUiTwAAABn2lUWHRYTUw6Y29tLmFkb2JlLnhtcAAAAAAAPHg6 eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0iWE1QIENvcmUgNS40LjAi PgogICA8cmRmOlJERiB4bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRm LXN5bnRheC1ucyMiPgogICAgICA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIgogICAgICAg ICAgICB4bWxuczpleGlmPSJodHRwOi8vbnMuYWRvYmUuY29tL2V4aWYvMS4wLyI+CiAgICAgICAg IDxleGlmOlBpeGVsWERpbWVuc2lvbj4xNTY0PC9leGlmOlBpeGVsWERpbWVuc2lvbj4KICAgICAg ICAgPGV4aWY6UGl4ZWxZRGltZW5zaW9uPjExNjg8L2V4aWY6UGl4ZWxZRGltZW5zaW9uPgogICAg ICA8L3JkZjpEZXNjcmlwdGlvbj4KICAgPC9yZGY6UkRGPgo8L3g6eG1wbWV0YT4K5QBsOwAAQABJ REFUeAHs3Ql8VPW9///3LAlhCYKIIApIcaEqIugtuNQFq2IVLW5Vu6jYH9XrUu/ttVb7s9fl2tZr 6cVaf1r+14ValaKtdatYFcXiggpUcUGEsogoUIwalpDM8v9+z8zJnDOZTGaSSTLL6/A4mbN+l+eZ GZLzOd/vNxA3k5gQQAABBBBAAAEEEEAAAQQQQAABBBBoRSAWi8neQmpoaFC0cbu2r1mqwOfrNeDl /1Fo26dSIKho7WB9fOJ0xXcaogEDBigUCqmqqkqBQMCZW0mazQgggAACZSQQLKO6UBUEEEAAAQQQ QAABBBBAAAEEEEAAga4QsM+v8gxrV0iTBwIIIFBSAuGSKi2FRQABBBBAAAEEEEAAAQQQQAABBBDo XgETaAiETKsFM7tBh3gwJDvb1gzmR/eWj9wRQAABBLpNgBYO3UZPxggggAACCCCAAAIIIIAAAggg gECJCnhaOMRlAhDJf3aZCQEEEECgcgUIOFTutafmCCCAAAIIIIAAAggggAACCCCAQE4CdvwG76xY VM7snB1wwgyJUAOtG3IC5SAEEECgTAUIOJTphaVaCCCAAAIIIIAAAggggAACCCCAQKcJeFo42BCD DTbYmXBDp4mTMAIIIFASAgQcSuIyUUgEEEAAAQQQQAABBBBAAAEEEECgiAQ8AQenVIGQiTaYmQkB BBBAoKIFCDhU9OWn8ggggAACCCCAAAIIIIAAAggggECeAjbYYJsyOE0bEh0puS0c8kyJwxFAAAEE ykwgXGb1oToIIIAAAggggAACCCCAAAIIIIAAAp0sEIjFZGc72WBDMBhU3M7OFn4ggAACCFSqAC0c KvXKU28EEEAAAQQQQAABBBBAAAEEEECgPQIBz0gN7rJ9dZfbkybnIIAAAgiUhQAtHMriMlIJBBBA AAEEEEAAAQQQQAABBBBAoPMF4qY7pXg8pngsItk52aYhFovLzgECD51/EcgBAQQQKGIBWjgU8cWh aAgggAACCCCAAAIIIIAAAggggEDxCZjWDM2DRgecIIM7hoMTcCi+AlMiBBBAAIEuEiDg0EXQZIMA AggggAACCCCAAAIIIIAAAgiUhYAJNjQ3ZLCBBzsFQok5scZPBBBAAIEKFSDgUKEXnmojgAACCCCA AAIIIIAAAggggAAC7RZobuGQaOzgpuPGH9x1XhFAAAEEKkuAgENlXW9qiwACCCCAAAIIIIAAAggg gAACCHRcwIzjYAZySKRjx4sOhZxZnvGkO54JKSCAAAIIlJoAAYdSu2KUFwEEEEAAAQQQQAABBBBA AAEEEOhuAU8LBztutB27wRm/IdnDUncXj/wRQAABBLpHINw92ZIrAggggAACCCCAAAIIIIAAAggg gECpCcSTgYa4bOuGmNOgwQYaGmNxRc0cDAYVtwM8MCGAAAIIVKQALRwq8rJTaQQQQAABBBBAAAEE EEAAAQQQQKB9AnHTpMGGFOxsl22jBreFAw0c2mfKWQgggEC5CBBwKJcrST0QQAABBBBAAAEEEEAA AQQQQACBrhCwXSjFTOsGMzvRBpNnIBB05q7InjwQQAABBIpXgIBD8V4bSoYAAggggAACCCCAAAII IIAAAggUn4Bp2uC2cHAWTAltywa3dYMzlkOy1N7l4qsIJUIAAQQQKLQAAYdCi5IeAggggAACCCCA AAIIIIAAAgggUOYCsXhUdk5N9hZT4jaTM85Dcod3OXUsSwgggAAC5SrAoNHlemWpFwIIIIAAAggg gAACCCCAAAIIINAJAs7YDcnBo+2yM9mBopODRXtbNXiX3UN5RQABBBAoXwECDuV7bakZAggggAAC CCCAAAIIIIAAAgggUHAB22ohlIwv2OWgCTS4XSoFg6aVQzLwUPCMSRABBBBAoOgF6FKp6C8RBUQA AQQQQAABBBBAAAEEEEAAAQS6X8DbPVLMDBjtrttgQyD5zx3HoftLSwkQQAABBLpDgIBDd6iTJwII IIAAAggggAACCCCAAAIIIFBCAm5wwS2yvaEUsN0qJad40LRyMDMTAggggEBlC9ClUmVff2qPAAII IIAAAggggAACCCCAAAII5CVgx2WIB8OJuUcfRc16rKqn4nZ2WjrklRwHI4AAAgiUkQABhzK6mFQF AQQQQAABBBBAAAEEEEAAAQQQ6CwBt5VDPBDSjt6DTMChRpuHHi1Fdijeayeppq8CJuhgx3GwQQkG jO6sK0G6CCCAQPEKEHAo3mtDyRBAAAEEEEAAAQQQQAABBBBAAIGiEXADCHETTAhW91I0GlFT74FS tEmBmt4KmNYOgVCYQEPRXDEKggACCHS9AAGHrjcnRwQQQAABBBBAAAEEEEAAAQQQQKCkBNxgQzhs byXVqKHvYMV6DtC26v6KmwGkw1XVCpl9vU0gIhQKNbdyKKlKUlgEEEAAgQ4LEHDoMCEJIIAAAggg gAACCCCAAAIIIIAAApUhYAMPTpdJ4WozWkNQQdONktPVkulGyUQanKCD3c+EAAIIIFCZAgQcKvO6 U2sEEEAAAQQQQAABBBBAAAEEEEAgZwE3iBCNRp1zevWyXSpFlWjxICcIYY+pqalxlm0rBxuccFtG 5JwRByKAAAIIlLQAAYeSvnwUHgEEEEAAAQQQQAABBBBAAAEEEOg6AbeFgxuAqKqqclo4uAEGu93d 13WlIicEEEAAgWIRCJhmb/FiKQzlQAABBBBAAAEEEEAAAQQQQAABBBAoXoGYGa/BTpFIxAk02NtK 7q0lG4xwAw/21U60cHAY+IEAAghUjAAtHCrmUlNRBBBAAAEEEEAAAQQQQAABBBBAoDACNpBgZxuA 8AYVaN1QGF9SQQABBEpVgBYOpXrlKDcCCCCAAAIIIIAAAggggAACCCDQTQJuq4bWsvcGIVo7hu0I IIAAAuUnECy/KlEjBBBAAAEEEEAAAQQQQAABBBBAAAEEEEAAAQQQ6GoBulTqanHyQwABBBBAAAEE EEAAAQQQQAABBEpcgBYMJX4BKT4CCCDQSQK0cOgkWJJFAAEEEEAAAQQQQAABBBBAAAEEEEAAAQQQ QKCSBGjhUElXm7oigAACCCCAAAIIIIAAAggggAACHRBwx24ww0U7qcSj0URqwVDiNZB4tpUWEB1A 5lQEEECghAUIOJTwxaPoCCCAAAIIIIAAAggggAACCCCAQJcLxGOKN26RYhFpu3mNxxWv7iEFwwr0 7G9ek8GHLi8YGSKAAAIIdLcAAYfuvgLkjwACCCCAAAIIIIAAAggggAACCBS5gNuyIRYzLRt2bFHg /XnS5x8r+M4TUqRRGjRK2mk3RQ/7P1LvnRUKJYIOtHQo8gtL8RBAAIECCxBwKDAoySGAAAIIIIAA AggggAACCCCAAALlKuAEHmKmG6WGetO64XPps48Uj+yQeu0ihXooZlo9BEyLByYEEEAAgcoUIOBQ mdedWiOAAAIIIIAAAggggAACCJS5QN3HcX26TQr3Cmj33cxrkdS3WMtVJDxFWwy3hUPUjNkQj5ig gm3VYOZgMrhgOlcyPSvFZfcH7BwIOLPb0qFoK0bBEChhAb5PS/jilXHREyP5lHEFqRoCCCCAAAII IIAAAggggAAClSZQ/3ZUQ4+MasykqPY/MqL/t6Q4BIq1XMWhU/ylcIMOUkDOYNG2eyWzLE+Dhlg0 Zlo5JAaULv4aUUIESleA79PSvXblXvJiecCh3J2pHwIIIIAAAggggAACCCBQdgLrV8b11ptxLV8d 1+cNUk2NNHBIQMO+FNDo/QIa2KfsqkyFEKg4ATfIYIMIdrmxsVGxHQ0KNe5QwMxVZgBpE3JQ1HSz FItG1NTUpICZbcuGYDDozBaNsRxK863TUBfXu6uzl71XX2nAzuY734wXzoQAAggQcOA9gAACCCCA AAIIIIAAAgggkJfA32ZHdd21cS3MeFbqUefxkwK67oqQvjoy44FsRACBEhRwAhDmYx6zgQYn2GDD DYlGDvbTn9if+h5wdvKjZAVmnhzVNRtzLP6u0rTTg/rmSQGN3zfxvsjxTA5DAIEyEqBLpTK6mFQF AQQQQAABBBBAAAEEEOhUAfOk678fHtGJrQYb/LkvnBvXiZMi+vfZpXnzsWFTXHOfiOmPf4pp7ktx mUYcTAhUrIANJLitHOxrrKnRjOXQlAgwGBUTe3DmiBnfwc72eCf4ULFiZVDxLXE9n2uwwVbXHDvz jpiONUGKgy6LatmWrjXgO7trvckNgdYEaOHQmgzbEUAAAQQQQAABBBBAAAEEUgKbYppyWEzPpLak lsxTrVPGBdR7W1yvviitSO1xlmZeG9O0M0IaVWJ/gb47J6ozZqQq89ySsMbTTVQKhKWKFHACCXbQ BtvFkh2rwT+EgzOcA8+2l8lbw3xnt/jKM9/3e3mqt6KVgMQKE3A+ZG5ED88Na1IXtXLjO9tzYVhE oBsFSuzXvW6UImsEEEAAAQQQQAABBBBAoFIFInH9JEOwYfw5Qc24OKjRu/lhNq2M6cHfxnTNI+72 xBgPLe9cufuL87Wqh79cVf5V1hCoSAG3pUPYhBbM0NFOKwYbYIgFAs5My4YyflvsE9CHT4bkG6oh ItWZ1mBLXonpnulxPZIWgDjDtHJ7+EUTdEj7f6IzlPjO7gxV0kQgfwG6VMrfjDMQQAABBBBAAAEE EEAAgYoSWHpvVLem1XjazSE9d0PLYIM9bODIoC7/77BWzQnqOOe8gAa3eEw2LcESWG0qgTJSRAS6 QsAGGNzAgtuawQ4KzcDQXaHfjXmY7/EWTy6bDf13C2jiaSHd91JYj13RsnxnfC+qupabO30L39md TkwGCGQUaPE9kfEoNiKAAAIIIIAAAggggAACCFSmQENc/32zv+rHXRHUr05zbzP693nXBo4N6pH3 gqozgx/4noj1HuRdNk/K1tdL5sWZetZKNQX6qzViylC/Pb9001s0VHWwLG4Zwibh2lwCMJ3okSTu 8ItbJ5tQIa9XesHMkADabq6hGTJASvp18HI4WRSy/N60bBn753KN0ytaAutuoCEei5oulaJOiW2g IWoW7SpBhxK4iO0tYg5jMky8JKxXaqM69EbP2D3L47rvNenyr7SdcUc+64X4zu5I/m3XLvsR3u8Q vk9T/2eX8/dp9ndE6e4txP/PpVt7So4AAggggAACCCCAAAIIIJBVYM2zMTX3jOQcGdAvv59HY3nz V2fWG6/mRvLCuVH94b64Zi5uWZS9zNgQU6cEdMY3ghpS03K/uyWyNqYLzolpfT+zZXBAd/82pOEm 72XPxzTjlzH9frl7ZOJ1yjkB/eiykEYP9G9f/1JUl/w6rj6mn/Klc/37pp4X0QRzE3lrcvOWXgHN +J9EPu6RLcpxl9lvBl799dVRXeNNb9eAXnwipHHpkZgCebjl6ehrg3H9P67rl4KafVtQlmzNazHN NN1m3WrG7PBO448M6Mp/C2rSAW0HpLznZVq2XXM9afqBf/QvcT2Tdv3s8cdNMu+NqUFNHtt6Xi2u RzvfF5nK52wzAbm5c2K6/w+mK5n0Mpr30LRzg848Kv06t5pgae6wt5bdFg7OcmlWg1IXSGD0d0Oa OT+iaZ7vh2vM98UFXwnKxJFbTB35rHf0O9sWpiP5t6hMlg18n2bBsbv4Pm0DqHR2B0xk2hNyLJ2C U1IEEEAAAQQQQAABBBBAAIHOF7j3wogu9dw0Ou6qkB75Xus3ePMpUf37MX335FYGos6Q0KxHwjr9 gAw7zKb6JVHtdpb75625mf9iUK//36h+6Cl7pjNnPWHS3De1Z/HtER3pGSg6tSfzUvpA0unleG5u QPdMMgGPDKdPN/X5vqc+BfV423hMcT2kn80J6/KxGQrRxiZ/faQXXw5p2S1RTfNHoVqk8u1rQ7rz uy3fJ/W5lKsurhsviurmDAGoFhmZDceZcUQe+vdgy65ezD5/+dv/vsiUb92SmM44K6aFmXambfvZ vSFdfnhLj7TDinLVvW0UMY9+x8wg0Vu3blVsa51Cb9yv4Bcfq3bN30z/SlFtHzxWsb67aduE7ynY ZxfV1tYqGAyqqirx3DktH4ry8mYvlLkB/J3R0VTQ2Yzh8LEZwyFT0CA9oQbz/b6L+X73Ts+9FtZ4 b/CtAJ/1Dn1nFyB/b/3aWvZ/H/F96vWqlO9Tb53LeTlYzpWjbggggAACCCCAAAIIIIAAAh0QMDeb nku7YT/1+MLcNK1/O6bd8gg22FqcNyWie99upT6+vjTiOvLItoMNTponR7TUdNVTsCmtHMe2Emyw +dV6ji24R6Eq5CmjTfLIw9oONtjjfn9jVDc+nwp42G25TksfyD3YYNN85o6Yfv5SK3n5yl+490Wd CXANzRRs2McEQMycPl1zflS/fq2VMqYfXALrNghhvwns7AQkTNVs7Zwalk81S+BKFG8Ra/YN6Gdp n4WFq/3lLehn3Z90Tmtdnr/v+4jvU/ciVfr3qetQTq8EHMrpalIXBBBAAAEEEEAAAQQQQKCAApGN cS31pme6AZowzLuhncsmkPGvU/xPvtqUfnN7SKvME7CfvRfWx+ZJ+sduDGivtCwunRLVmrRtba1O M2NOvPliWB+aNB+8omXA5B7TZY87HXiuGQz73qBeNANeT5/kbk28/ux2s/3+oJ5z5zkhjcmjn/4p FwT1sElj+gWJeg3eOZl+F3v4a9X+tW+blgWvPBfSh6+F9MrMgManJXXztJiWmS6i8p28A73aLrVm mdYBq5aEteUDM5v3xqq5QV01zp/qzb+O5T0obT7vC19u5npd3tyaJrFn/BTzHnvZlO/JsB4x8z/N e+1nae+fa74Vy/u968u3iFYSnyL7GY45QQf7Ix4KOXNiQxEVlqJ0k0BAx0zxZ/38otR3rd1TiM96 R76zC5G/v4btX+P7NGVXad+nqZqXz5Lp0ZIJAQQQQAABBBBAAAEEEEAAgZYC2zfHtcK7eQ8ziLN3 vZ3Ly+Z4uuhw0gjojaUhjfIkXjswoIlnh/Tqv8Q0wbQSSJXDjPXw17huyrGlhb/LpIAmX2JujqcN aDrT9L9/vRkE23YTEu5vbpwnu77pZfKWZ9yFY44MarSnjPlU39elzvHS969Jnd2VHqlcO7aU3r1V /2NMoObFmI490tvFUFyPL4xrVJ5dCQ0+KKApR0pnmbEgJqePBWHuYgwcGdS19wf00Zejqa6qFse1 3AxoOz7HAFC+7wuv1rI/+8c1GW8CSU9f4+/Sqca8fy+/LazdL4vovOb3UFxzzMC5V+YwcK43v6Jc thEH20O3nc1yIB5obuEQIOJQlJesKAq1w1+KQnzWO/KdXYj8/TVq3xrfpym3ivw+TVW/bJZo4VA2 l5KKIIAAAggggAACCCCAAAIFFkjr/kHmhm47HlhPK1Rc993o3zRrrj/Y4N1bY24uP3pz4nlqd/ut d8VV765keX34Of/4DO6ho81Avt92V+yrGdQ5U72aGr0HmadxMx3kPyTj2rdvzNZ/f9d5ZCxcOzbO mtvKWBq7BXX7tf4Er380s63/KP/akMNDus8Mtt0i2OA9LBzQBVd4N0jpb1f/3tRax94XJuB1rfcp bTNweCvjR9gcTzeBCG8rnfvNIOylPtkulJwulcx4DgEz28mKBMyinc3o0c4A0nY7U2UL7HGg/7u7 T9rgD4X+rOf7nV3o/Ntztfk+rezv0/a8Z0rhHAIOpXCVKCMCCCCAAAIIIIAAAgggUAwC+wfUs4Pl aHg7rlu9aYwL6viR3g0tl4eb1gzHeTcvjukDE/zINl01M6RJw1o5wtysnuDtkmd54un4Vo7u2GbT KuKWs/033bwJdpWHN8+OLP/AdHt1epbrNeo4/w12vRPX9o5kmOXcXmk3L7Mc2ryro++LyFoTcGhO zbSouDiQvdWLCcJc7HmvrTBjTdR5zi/tRXuj0HOz0AQabLCBCQFXIJxrFNA9oZXX9nzWW0mqXZs7 K3++T/k+bdcbsgROokulErhIFBEBBBBAAAEEEEAAAQQQKAqB5M3jdvYqlKyC5wal2fLtKYmujLLW r09Qk/aJ6ZnlWY/y7dy1X/YbnwceaQ5fnDqlQPfFUgkml352adDpqqnFjuYNXePRnF0HF4aZroKy TrsFdPqu0s0bk0eZa7bRtAyp7ejdB5NGvRncu2F7witsIl8frchakow7O/q+sN2MeafNn0lL34+r aZt3a2q5qiqutd7gmOnyqaMUqdS7d8lKeDXigaDszISAK/DR++5S4nVLLk3TCvRZ9+ecx1oX5s/3 qfcbRKrk79M83qElcWi5/D9XEtgUEgEEEEAAAQQQQAABBBAoaYEC3CzdsNovMDa9j37/7ua1vQ83 i56Aw1bvaJ/NR6UW0roKT+1ILlX1aLGpWzZ0lUehKteWq3nEXUP3MLm5AQdzS/qfJlAwMsexFbzl jNTF9dTjMT35ZFy/9wSHvMfku9xW+dt8X6RFplY8GNOhD+ZbijI43o7d4E7eZXcbrwgYgSbTXV0u U2d81nPJ1z2mu/Jv6/uI71P3CvFaagIEHErtilFeBBBAAAEEEEAAAQQQQKCLBKqq7NPsnhtG68xT 5mZLO3qyaS7x5k886ZmtO9oIHLgn9k5rVtFkbmKXw1SOHtWmhUNqCmiXtGuX2tf60sLfRXXsjf73 SutHd92e1a92sEzmM2QeoC6LKRCPmsGio6m6BELm/qiZk1OAsRxciop93faFv+qHHeRft2vd/Vnv 7vxbivi38H3q9/CtldH3qa9eZbBCwKEMLiJVQAABBBBAAAEEEEAAAQQ6Q6BmeGLshGfcxDfG9cJK 6dwsffi7h+b6mmtDg8a0BHt3JOqRllYxrZaDR6Ove6H8WzgsbSXYcNyRAe1n3nv9bADDQL08I67m 92YXXcTBX/YH4cafE9AVXwmoMf0Nmqk85pg9Dguqf6Z9pb7Njt1gYzF2ZhyHUr+ahSl/JK577vAn NfpL/i7Zuvuz3t35+3Uyr/F9mtlF5fx92kqVS2kzAYdSulqUFQEEEEAAAQQQQAABBBDoSgFzY/eY feQbO+GuR2M699/b30/7iAP9N2zXbnLuULZZq3cXtnlISR5Qfh5xfbjMcyn2CWiffLpT+jim76S1 bJh2bVDXnmtu1KfdwVhWG9EzN3ry6oLFmp38mYw5KKjJJ/tvovqPKL+1uOlCyc6KmdYNdk5OcRtz qCwKt+q8ZhDY9LeYfu/dvmtAB+7m2dDdn/Xuzt9D0foi36et27CnmAXa/1tiMdeKsiGAAAIIIIAA AggggAACCBRAIKBjvulPZuEdMS32DoLr393mWjitD/xbn4233cVMQ1wLfH34B7RTO7rpabNw3XBA uXlE1sZTA0a3w7PeDMq8wnPelCuC+tV3WwYb7CFNubQq8KRVkMW0LsDeXGYDZpU3OWHDZODBiTG4 LRvclg6VR0KNfQJxzZjm/2xM+X5QQzzHdPdnvbvz91C0usj3aas07ChyAQIORX6BKB4CCCCAAAII IIAAAggg0J0Co08Maq+0Ahx5dcwZyyFtc8bVTe/H9MDsmOqSe3sOCPjTeySmt9oIYKx/MaZHvKlP MmmkPe3u3d1Zy2n3mguSTal5XHNpVCuzDELw1l9jPpe9Dg7kNebHR4v9NymPOKq4blvU7h3QeE8N F94T17IsHp5Dy2rRtnAIBgPO7LR2MLWLB4LOzNgNZXWp21GZuO69LKpb0878t9P8zV+64rOe7Tu7 K/JPI2ixyvcp36ct3hRlsqG4/ucuE1SqgQACCCCAAAIIIIAAAgiUjcBA84T5OWm1mRvTVy+LaX22 gZtNq4THfxXRiJNjmnZtTMuTQYXwsKCuGOdPb+oNMbWa1KaYLrnEfxN6unlStiviDU07/OV88V3/ eiHWSsnDqa8Zx2PMUVEtyxQkMl2UTL3Zr3LFt/K7Vj0H+29Krl3vv/Zu6g0rY7oiLS93X6e+9gnq Xyd5c4jr6l/7gyzevd7lhlbf5N6jSmQ50cTBRBnM9THL9iq5gYbMV6xE6kUxswv0CSitkZrv+Lq1 Mf3kpKgunevbrG/fGNK4tK7VOuOzns93dmfk7691Dmt8n/J9msPbpBQPIeBQileNMiOAAAIIIIAA AggggAACXSgw8UchTUnLb4UJOuwzOqKf3B7Twrfj2mTGYtj0cVxLl8R078+i6jM6qnOaBwwNqJcn QnDqD/03lVeYVg4TzBOxSz/2ZGKeGl/2UkzHHhbzDwxsxgQ46wDPcZ24OHg/fzmv/7eoFiebamxa aQIqT5iWGwV4ur1UPJqpzU2yQ8ZG9MBr8eZA0Rpz3accGfN1hyTTZ/tJ+zafldPCzt4+V8wZt14S 1VwzULl3WvrXqHaZZN533o1duHz89/3vi2dMN2PH/jSmlZtaFqLefC7+9kRU3zkpol3M56Uj3ZG1 TL1rtzSP3eBmGzWBFjsnJzfg4K7zWoYCpgXS6++bVj3mO39pcl5ovqcf+N+oLvpmREOPjenW5f56 7zUlqFvO9n9m7BGd8VnP5zu7M/L31zzHNb5PfVCV8n3qq3QZrnh+5SvD2lElBBBAAAEEEEAAAQQQ QACBjguYp1rveS6o9eZmUvpN3ltnmBtMM9rOosrz12f/r4Q0a1JE53megl0xN65D55q797tK4/tJ C9NuWrk5PHZvSP3dlU5+HXKA7f7JM6aAuTF05Ff8EYYXjzbjC6Q9uZtvsUrFI71e074V1bT0jZ71 6b8JaaBnPZfF2r2CJs2oZnoOPsO8V44z3WiNMxf+hQfjLd6DnkO7ZLH2gJAePieiMx5MZbfwwZjG mNm+f6eMMzdXt5kbssukFRtTx9ilbF28+I8s/jU7XIOd7WSDDbZlg9vSwdnIj9IXMF93/sZMcZ14 cmqg8LYqaMdg+f8uCSrTkDud8VnP5zu7M/JvyyPbfr5PUzqV+H2aqn15LNHCoTyuI7VAAAEEEEAA AQQQQAABBDpVwHb989xrIf1gnzyzMTdfn3s5pFGegINN4fTbQpqZ3mzC7jA3aDMHGwJ66sWwJuZ7 B9ummcOU8Uaw6U7qF+ndSeWQVnsOKTaP1uow5YKAjmttp2f7VbeH9P2xng25LtYEdO2clrcqnjEB qZvTgg3HHelPNOM19B+S91praU66IawHL8iQnHn/PmLK+siLLYMN9mhvS58MZ5fMJhtniMWizpyM OZjxG8LOXDKVoKBtC5hIwaC2j2p5hPnef/iJkO5rJdjgnNAZn/V8vrM7I/+WElm38H2a4Kn079Os b5IS3dnyf/ESrQjFRgABBBBAAAEEEEAAAQQQ6GSB/gHd9GRYb94f1FW+fuxb5vvtcwJ67JGQtvwh pPEZgwQBnfvfJq17g/p22pgOvtTME+P/eWNQH74X0ld38+3xrVRVubc9E5v7Zuto3BxSVe093d/l k3ePcyPkYn/azfuPDGhoWuuGfMvRnJbpCL87PVLlyL50xOkhPbIkpJ+1cv33MiaPPRHWtcdnNsvF p//YoD42LWp+0Nr7wnSrNdO0dHnkrpCvhUWmS55Lft4a5/q+sOdMvias5SY48oO0wIc3Pbu8lwnS /edVQb35WlijMz3qnX5CCazb7pXsFbZz86DRdrkEyk4R8xAIB/SNC9o+frx5j9vv/Jn/Y97nJjBs v/cn7Zv5O8CbWiE/6266+Xxnd0b+bjlyeeX7NKVUyd+nKYXyWQqY/xj4/6B8ric1QQABBBBAAAEE EEAAAQS6TsB0t1Fn+qj/dJvpKsYs226TevYNaFcTYEhr0NBmmRpMvx0bNsT1xfbkoebu8QAzBsCQ fPpPMmWoNwPzVpmbujU5FCBijt1uzulpggZtHm6OXf+RKZ853h48YOeABrZWtjzLkQmnOzwylaP+ 7ah2m5K6bfCzOWFdnmy50FAX10fmif5t5vqrlzTYXK9WTbyJ5+HTsMXk8ZHJI9nUoO+ggIZ7A1gm LWcw5mzXPI/8bDHzel8k62XP2Wi63Nr8RaqivfqaHpaMSW2JBxnc20ZNTU2mRUNM9fX1itVvUq9X fqvgFx+r54a3pGBY9SOOUazvboqO+6aCvfurd+/eCgbNoOHhxKfLdrvEhEBrAgX5rHsTz+c725xX 8Py9ZUku832aASXDpnL+Ps1Q3bLc1ObvVGVZayqFAAIIIIAAAggggAACCCDQcQHzF2X/3QIFGVOh xtz0H27GiujQZMpTm9biIFt6YXMjuDbbAd595tghI00AxLutteU8y5Epme7wyFSObNtqTIuXka0F XbKdmIdPjXlPjMw28LRJy1plnfLIz6aT1/simbE9Z8iwHN8fWQtbQjvt86vJZ1htSModNDoVniqh ulDUbhcoyGfdW4t8vrPNeQXP31uWHJb5Pk0hVeT3aar6ZbFk/ttlQgABBBBAAAEEEEAAAQQQQAAB BBBAIDcBGxqMx2PO7IQJTeuFqIk0xMxMS4bcDDkKAQQQKFcBAg7lemWpFwIIIIAAAggggAACCCCA AAIIINAJAnYEh7h5DDlm5miVaWISMgNGh3uY5iFmZkIAAQQQqGgBAg4VffmpPAIIIIAAAggggAAC CCCAAAIIIJC7gB2XIV7dU9sHj1a87zBt67enGcMhpOiAvRXotZN6mEFU7DFMCCCAAAKVKUDAoTKv O7VGAAEEEEAAAQQQQAABBBBAoG2B5GDNbR/IEZUkEDddKMVq+ikeCCsajZp+lIIK9txJqjatHcw+ ulWqpHcDdc1ZgO/TnKk4sLQFCDiU9vWj9AgggAACCCCAAAIIIIAAAgh0mkBV34DGK66FyRx279tp WZFwkQu4rRbCYXMrqUdvbdtlX0UjEUX6bXeCDDW9+ihcVaWA6VbJBhzs8QQeivyiUrwuFeD7tEu5 yawbBQJxM3Vj/mSNAAIIIIAAAggggAACCCCAAAIIIFCkAu5tI9uSIRaLqaGhQRETaKivr3daNzQ1 NTmBherqatlgRG1trUKhkHr0SAQe7LKdCD4U6QWmWAgggECBBWjhUGBQkkMAAQQQQAABBBBAAAEE EEAAAQTKRcANFLgtFqpMKwYbRLCBCBuAsMEHO9nt9hgbeLCv7vHu+eXiQT0QQAABBLILEHDI7sNe BBBAAAEEEEAAAQQQQAABBBBAAIGkgA0k2Mm2ZnBbP9iggl13gwx2P4EGq8CEAAIIVJ4AXSpV3jWn xggggAACCCCAAAIIIIAAAggggEBeAm5wwXat5LZusK92doML9tW2dLCTd1teGXEwAggggEBJC9DC oaQvH4VHAAEEEEAAAQQQQAABBBBAAAEEuk7ABhLs7AYa7Kud3JYPXVcSckIAAQQQKEYBWjgU41Wh TAgggAACCCCAAAIIIIAAAggggEARC7iBhvQiui0b0rezjgACCCBQGQKJjvcqo67UEgEEEEAAAQQQ QAABBBBAAAEEEEAAAQQQQAABBDpJgC6VOgmWZBFAAAEEEEAAAQQQQAABBBBAAIFyFaAlQ7leWeqF AAIIdEyAgEPH/DgbAQQQQAABBBBAAAEEEEAAAQQQqDyB5NgNzRU34zowIYAAAgggQMCB9wACCCCA AAIIIIAAAggggAACCCCAQE4CztgNNtgQbZQZOTpxjh1IOmRuMdnBpJXovZsWEDlxchACCCBQdgIE HMruklIhBBBAAAEEEEAAAQQQQAABBBBAoBMF4lFpy2YTdGgyQQezHAxJPftKoSqpurfJmNYOnahP 0ggggEBRCxBwKOrLQ+EQQAABBBBAAAEEEEAAAQQQQACB7hdwWjaYYkSjiWBD6PnbpM8/VuCztYpX 91J07FnSTrsp/qVDFTDrwSAtHbr/qlECBBBAoOsFCDh0vTk5IoAAAggggAACCCCAAAIIIIAAAiUp 4AQeYlHFt/xTqt+owOfrTauGXorv2CI1bjMtHmIlWS8KjQACCCBQGAECDoVxJBUEEEAAAQQQQAAB BBBAAAEEEECgbAVisZgZsiGuSCSieFOTgrGIAqY7peaWD2a/7DFmfyAUUVWV6V7JTIzlULZvCSqG AAIIZBRItG/LuIuNCCCAAAIIIIAAAggggAACCCCAAAIIpARs4MHOzoDR7qDRZuxou83pbik5jrQb iEidyRICCCCAQCUI0MKhEq4ydUQAAQQQQAABBBBAAAEEEEAAAQTaIeAGDtxAQ2Njo+k6qVGhyA4F o43qYdK0MYamqGn5YOaQbeFg5lDIDCTNhAACCCBQcQIEHCruklNhBBBAAAEEEEAAAQQQQAABBBBA oH0CNvAQNwNHB8zpdrYBiZht6WCjDmaOmH0h2wKCCQEEEECgIgUIOFTkZafSCCCAAAIIIIAAAggg gAACCCCAQO4CbpdJTsDBBhRMa4aAGTzanaJRG4iImXEd4k4Qwm0Z4e7nFQEEEECgMgQYw6EyrjO1 RAABBBBAAAEEEEAAAQQQQAABBDosYAMJ9l/zGA62mYOZbAMHp6WDs2Z32y1MCCCAAAKVJkDAodKu OPVFAAEEEEAAAQQQQAABBBBAAAEE2ingBBxiphsl05rBzk6kwaRlO1GiI6V2onIaAgggUEYCBBzK 6GJSFQQQQAABBBBAAAEEEEAAAQQQQKDzBbytF5LLAdPUwc5MCCCAAAIVLUDAoaIvP5VHAAEEEEAA AQQQQAABBBBAAAEEchdwWjiY7pKC5o6SnZ3JBhpiyZmgQ+6YHIkAAgiUoYD7X0MZVo0qIYAAAggg gAACCCCAAAIIIIAAAgh0hoAbeGhOmxYOzRQsIIAAApUsQMChkq8+dUcAAQQQQAABBBBAAAEEEEAA AQTaIRCIx2Rnd4qbgIOdmRBAAAEEKluAgENlX39qjwACCCCAAAIIIIAAAggggAACCOQvYLpVkp3t ZF9MsCFg+1hqHtKB4INjww8EEECgwgQIOFTYBae6CCCAAAIIIIAAAggggAACCCCAQEcEbCghnvzX HFYIBM2W5jUn+QAtHjrCzLkIIIBASQoQcCjJy0ahEUAAAQQQQAABBBBAAAEEEEAAge4RsOM32NCC E3iwrRxsYMG+2C3JIAPBhu65NuSKAAIIdLcAAYfuvgLkjwACCCCAAAIIIIAAAggggAACCJSIgDtY dNCM32Dn5ikYkuzMhAACCCBQ0QIEHCr68lN5BBBAAAEEEEAAAQQQQAABBBBAILuADTK4k7NsGzKY DXZO/HD38ooAAgggUOkCBBwq/R1A/RFAAAEEEEAAAQQQQAABBBBAAIEsAt7ukeyyDTTEYlFndoIO 9lw7YLSdmRBAAAEEKlqA/wkq+vJTeQQQQAABBBBAAAEEEEAAAQQQQCC7QIsWDs7httWD2/LBDuBg Qg/O+A3utuxpshcBBBBAoDwFCDiU53WlVggggAACCCCAAAIIIIAAAggggECnCdgbSs03lQJmyQ7n YGe7zIQAAgggULEC/C9QsZeeiiOAAAIIIIAAAggggAACCCCAAAL5C7Rs8UALh/wVOQMBBBAoT4Fw eVaLWiGAAAIIIIAAAggggAACCCCAAAIIFFrACTbYQaTjpjmDnd0pGDJNHkKmVyUzxoPTtZK7g1cE EEAAgUoSoIVDJV1t6ooAAggggAACCCCAAAIIIIAAAgh0UKB5oGiTjrNsh21wx3BgCIcO6nI6Aggg UNoCBBxK+/pRegQQQAABBBBAAAEEEEAAAQQQQKDLBeJmwAY728mJMQTNLSYzE2/o8ktBhggggEBR CRBwKKrLQWEQQAABBBBAAAEEEEAAAQQQQACBIhewrRmcbpVMeCHZhVJq1dv+ocjrQfEQQAABBAou QMCh4KQkiAACCCCAAAIIIIAAAggggAACCJSxgIkuBJOzE3iwVQ2YW0x2ZkIAAQQQqGgB/ieo6MtP 5RFAAAEEEEAAAQQQQAABBBBAAIH8BGy3SbYdg53dLpTsq7tsFpkQQAABBCpUgIBDhV54qo0AAggg gAACCCCAAAIIIIAAAgjkKxBP9p0Ui0VlZ7cDpWAwbIZwCJselgLOnG+6HI8AAgggUB4CBBzK4zpS CwQQQAABBBBAAAEEEEAAAQQQQKDLBNwWDk6GdkwHd/Iuu9t4RQABBBCoGIFwxdSUiiKAAAIIIIAA AggggAACCCCAAAIIFEQgEIiZlgyx5n6Uoqblg9P6oSCpkwgCCCCAQKkKEHAo1StHuRFAAAEEEEAA AQQQQAABBBBAAIEiETAdKZmSeFo6FEm5KAYCCCCAQNcKEHDoWm9yQwABBBBAAAEEEEAAAQQQQAAB BEpfIGaGiLZzcgpUVUl2ZkIAAQQQqGgBAg4VffmpPAIIIIAAAggggAACCCCAAAIIIJBdwA4E7U52 2YYZYtV9JDPbbpRiVeY1GJLsXEatHOo++KNunP+stpla7b7X+br66PHiRpr7TuC1/AQiqtu8Xp/u aFK4x87afUB/3u/depEbtGDuLfr9uvWmFDvrG1//sSYNqe3WEuWaOd+TuUpxHAIIIIAAAggggAAC CCCAAAIIIFCBAt6xGZyAQ48+2jziOKnhCxN5iJjAQ29Fe+2qoAk8BENhBYNBM76D6WTJE6goPbY6 3ffQNN3dmCz51vG6koBD6V1GSpyzQP2quzVi1tXNx9/wrdW6fO/SuMHdXOiyWmjSO2/P0OwtiUrN fmC4Vv3HNPUvgToScCiBi0QREUAAAQQQQAABBBBAAAEEEEAAge4S8AYObDAhFgwr0muA4qEaJ+AQ qO4phc1yyHSpVNJBhpRw/aqH9FM32GA2zzjldJka5jZFG7Tmo3f11j/e0LJNa/Txtu2J86p6are+ wzVqjzE6cM/9NLwfN3NzA+2co5a9eqMmzJ2RTPwozb74AU0alPNV7pxCFVWqJpjY0Slap2UfLNGS 1Yv09qcfa3uT1LPXbhrW/0s6aORB2m/YSNXahlFMGQRqddqkH+uqh3+R2Lflas1ZdY6+P6L4vzcI OGS4nGxCAAEEEEAAAQQQQAABBBBAAAEEEEgJ2KCDDTaEw2HFa/po6+4HKxqJKBqNmlYNIdX2HWha OFQpFDazWS/tFg4N+utzqSe91ec6nZTLTb7oej3+1C/10zdmaVWKruXSG4lNI/qfpxtOuVqTRwxs eQxbOlmgTvMXuMEGm9V8PbB0tQk4jOrkfCsl+YgWL/gfXfjsL1r/LCywFsN1yRG/1o+/doSK/zZ6 11+7gQecpqkm4HB3MuurXnxBF46YXPRdXRFw6Pr3CjkigAACCCCAAAIIIIAAAggggAACJSlggw4h E3Sw3SgpFJV9ONnpQsl2pWRmtzWE+1qSldw8X/+1LlXysw/5utoKCdSvf1rnzTxX81Kntbm0qm6W vjNrlk455FHdffIRRX8Tsc0KdfMBDZ8t0wvL3tFW82B+73776+gDRmVplWLew2ljnPfiLmmBrmCD Hn/gMH1n+Zoc0luj2xecqn57rNCVo1p2FpTfNc0huzwP6e78pZH69iFH6e435idKvuoeLaqfrPFF Hp3ho5TnG43DEUAAAQQQQAABBBBAAAEEEEAAgUoRcAMHttWCDSz06NHDaeVg6x+LxZxBo+326upq p2WD27qhlH0Wv/5bz1PZY3XWQSOzVqd+7YMaevelGY85eNBZOnrwl8yN7wZ9vHmJ7l6XvHHoOfqx N07VCdsf0tNnTiTo4HHJd/HdBZfq7DeWJE8bq6dHPqvxprevzFOVhvQze+pSe0fuMiC1wlK7Bda/ cWOGYMNYTd3/VB3Yv4c2bVymuctnaZEnh7krVmUMOOR3TT0JFmixu/O31dhv3JmSG3AwLXH+8M5a jZ8wrEA17JxkCDh0jiupIoAAAggggAACCCCAAAIIIIAAAmUnYIMLdnK6VorHnYCDDUrYdaelg1l2 gxSlWfn1enKxJyjQ51SNtTemW5vqF+i8DMGGqRMe0H8cdayG9PTfevtVtF5LlzyoK5642nfDddE7 Z+o/916qmw4a0lpObG9DoCps7dyAQ9/0BgxpZ9do8nmrtWjVB/rctIjo1Xeo9hrUVjuWtCRYbSkQ XalfPnGnb/vB+9yrh8+d7Bvs+Er9TCuXPalb/jRNs81YKUfvOdR3jruS3zV1zyrca3fnb2tSM+Rw XWJeb09W6+6F83T9hPOLuguqxP8SyQLzggACCCCAAAIIIIAAAggggAACCCCAQLqADSbY1gtVZpwG 25qhd+/evtm2fLDbbeDBbeVQioGHyIZXNN0zWPTEA4723Sj1u0Q09/HLW3SjNONbK/SrSSe0CDY4 54ZqNfqQaXruikd1ij8x3f7nu7Q+bRur7Rcw4xO3MdVq5IhxGrf3OI0ywQZ/aKiNU9mdWaDxc632 7qm+QvelBRsSu2s0ctTpuvOaj7TovBd00T65BXvavqbezAu/3D35D9Ox+49NVabuMb1Zn1otxiUC DsV4VSgTAggggAACCCCAAAIIIIAAAgggUIQCNojgtmSwr97lUgwwpBOvee9Z36ZT9t3Tt+5bqX9R t6T1U//Dk5fo/L1b9kXvO8+u9DtCM6f+Jm3zDD38gaePn7S9ra1GGutVV1/nzA3R1o7Kbbs3rbrt DbmdlOUoN736HNOKRBtUvz1Rl7rt9TKND3Ke0oZkUJUdYKQzJlvGpHddfb0aovmUMnuBXK9EutmP zba3I47Z0m1rX/0nb/gCcBPHfUPZ2+yYwMOI0RpYnTnlQl3T9noULH/PZ7Q9n6vRXz7BAzRfT60s 7tAkwTvP5WIRAQQQQAABBBBAAAEEEEAAAQQQQKClgBtMsAEGO7mv6Ue6x6VvL431Br323hxPUc/S wbu3PjrrskUP+bpFUv/puuKQ3PtWrxl2jmaPuEVnr0oNrvvT+fP0r3uf7nvavmHD05p219X6yN6U 7Xe5Zn/vfGcQ6zXLHtfM52/V7RvcboQSRT940BW6ctJFmjQit6fG1bhec1+8Xw/8/UE9tiVVFie1 atP3/oEXa9pRp2pUbebbiBFTvqlu+Xqfo7svvlLDty/Tr++/VD9d5ylb9Xmad9mvNC6NdNP6haYb q8f02LKnNC89fw3XxD2m6IKjLtTkvVveul7/9kxd+twC9TFjmC9d96Tn2s3XhXd8V+ON2TbP1tYW t1T9i/7ngss0vLUgRbROC19/SH9YOEd313nqlExwRP+zdMGYM3XGYRM1pJWb5/bQFlbTjFUoomV/ /71mPPtrzU6r/yn7/FxXfn2qRvfLbO+tT0ccvel0aDkt9jJv3XITNBrtez+3lX4+1zTbdWuvR6Hy 7+jnyus0cPihOthscMe9+Mu7S3W96X6t7XeFN5WuWy7WcnWdADkhgEBJCpiuQrUjEpV5MSOVmZ+B kqwGhUaguAXsByxo+uA1Lz3CIdMXb3EXl9IhgAACCCCAAAIIINAhgehqzd/gSaHPWO3Z6s3jes1/ 0xuckH541PF596t++GEXSKuuS2W67lm913i6RnvybfpijR5rXCPZrp62zNOHn03Us49O1cWrWt74 tgkt2jBDZ88y8xHP6M6vjUulnWGp7oMHdYYJDLg3Mlsc0mgGun5jmjPfcMZSXX5Ay5v+233l+4c+ MQGEn8/8umanJ9Y4S6//83oTcEhGHOqX6sa7j9b0uvQDvetrNG/dDM27f4YmjnlIc6b4B9b+ZPVc zaub7xv82T17Vd2TnsG/3a2tvW7RJ40m4JBhkOn6tY+bcTrO9z25n57Kqro5+ukLdh6ru857SKeP yNzKJd1q82crNXfOV3SV933nSfyx5VfrseV36q6p83X6sLRIjXtcARzdpDr6WrvHGE00icxzE1p3 kx5ae7zOaa3s7nGe1/yuaYbr1kGPDudv6lKIz5WHRKr9kiaZ74RF9jvATKtWv2XGOz/BCTwmthTX TwIOxXU9KA0CCOQgEDfRhh1NUb2z7gs1mNdIJJYIPORwLocggEDuAja+EAoFVGPaIh8wdCf1MK+l /cRa7nXnSAQQQAABBBBAAIHMAmX9+2D9en3gqfbBI8e0HkBoXK2XfDfKT9JJ+7a8Ge9JLuNi7fDj dLau89yc36Bt6d0i+e7ePamJM7xP8mdM1tk4e8Fx2n2Xpbq2lYGo6z6YqRH3X90yARNomahPW7Q2 +OnDo81o4ct0+ai0lhO+8s3RCTP9gRhvBn1DqU5qls7/zzaCDd4zzU3sN8/Uz/depmsP8Ob/hf+g DqylSpZKpH7VvRo664epDW0uLdGFs/ZSvRmQ+vwRGQIEaVYTb2vdKpXVGl149yXa55rf+QJR7v7C OLqpdfA1tJN29SWxRhffPUX61u90ToYWKr5Dm1fyuaYtj+24R8s0m4vWYqHlsQX7XPny2ll72BiW G5hqfEUfbpcGZgiQ+U7rphXf27ybykC2CCCAQN4CtlHD9saIE3Cw0QaevM6bkBMQaFPAtiRqjMZl g3z2M8eEAAIIIIAAAggggECzQDyWXLSPqZipDP4oq9v0ju9J/91reyXqluFnpG65lnq39z9Ce7fn 5l/17ppgbiTO9gUvvAlnXz57zExdctih2qNXldatfERX/PlqXx2m//lGnTn6Do1K7yqocal+kBZs OHjEdM089WyN7FfjZNrw2TLNfPhc0y2SaV2RnH46e4ZOve4m09FRbtMp+0/XuSMGaM2qv+jOd7Zq UN/UrUjvALwj+l+k/3vs2Tpy5N7mJqrJ34yTsGnDm7rzoa/7ghLTn3tElx4wrXkg7wOP+q2e3vOf quohvT7/Yl3VXNbhuuHkO3REH8mbj1tqO77Dgme/rp+6N3DdHd5XY3RJi2DDUZpx8v81waX91L9X WNtNkOr1v/9BP3zhF77WFFfM+oWOycPJZjv1kHt1yaFHaOfQp1qw4Jf6zhveYMSTuue1lfrVESO9 JXSWvfVrr2OLRNu7oXqUrvzaeZr97CxPCkt08f2j9b8jfq5bJp2jcYMyBGI8R+d+TU3NQ7tpTNrn rqMeHcq/0z5XNTpgxEkm4OAGG+frrU/qNS5TUMtj2V2LqU95d5WAfBFAAIEcBexNTztFo1E1NUW0 ZXuTorGYvjykVjXVQXpVytGRwxDIVaChMaZ319ebz1zctCSKKhZODBBozy/rJ9tyBeI4BBBAAAEE EECgEgVMoCFu/g4LRMyAwvbBFPMEWMCO6xA2N+dN0KGUf09ct/J13xU9fOSevnXvyvYvNvtuMKtp R14DHHvT2uFd0XwtXFen8W0OPN2y657+B03Tc0OH69jbzvUEHebo8fdu0ChfqwBp2cv/T4958j14 /wf09Jkn+PqEr+k3Spd/72Xt/r+H6cLmG/l3as6y/9CVo+zj1tknXxdMh0zW98/0Hz94z0k65cMv 68xJl2jyiLTWIaEaDRwyXtde+pI+uvHwVAuQurlavn2axidvModrR2r8AYmb8L3WHCA1l/MAHXPg +IwtAtxS9Fpzkgk4uDdw3a2p12Uv3uIzki7Sq9fcpFGe7q5q+w3TxKOv1Cv7jNKhM8/3vCfu1Mw3 LtFNh6TVK5W8Z8lcy6mPeLpM6q/JJljyNxN3+eqCVNDh7kV/0/Um4JB+u74Qjp7CdHhx5BHXasbS WboiLZizaNXVmnjH1Tp4jx/r+q9/T0cMyfwe6sg1tYXvqEdH8u/Mz1XffkN91+aLSNqAGb693btC wKF7/ckdAQTaIWADD/ZfzDxybeceVUHTv3wi4GB/ubX7S/mX3HaQcAoCBRFwPztucM/G+OxnzHyq Ev/sBiYEEEAAAQQQQACBihaIR81NrmiT4p9/4rwGzJhfst3k7LR74jWQ/ih96XLtyHZDL+2O2sHD 929+6j6/GldpSD/TXqAu1Yqgb4+0xFskOFx3TXtCpw9JtETw7R5wgm4/4iRNWJC6kX7Tolf1bwdM 9gQTVmqmGW8gNZ2lGaf6gw2pfTU6fcr1+q/bUjfTH1i6xAQcbE/9rU9nH/1SxvEevGcMMS0Vfmdi BFmn0ChdcMhRmv3G/ObDMnV9ZHea5xI90xaZHpizTv7j0w9dq/s8hnbvXdOu9wUbvGfUDJmsP5sn +8d4nuy//aW/6seHnN8iQOA9Txqr2RfP1aRBLQO7Z+gAAEAASURBVK/56GN+oLNNwGG2e0JTfcag VqEd3eza/9pf51+8QrUPnKkLl7ccZ2TRul/o5Jm/0AgTeLhz8kUan6XFg/8atX1NbZkL6ZFf/p37 uRo0aG/fJXlh5Spd3mZg0ndKl62YEDQTAgggUBoCTqDB3PCMmadp7ByNmSeuzaxYkwJ2jpvfLjyv dpkZA94Dub8H0j9DcfMZsp+xxGct8blzP4el8a1BKRFAAAEEEEAAAQQKJeD8HRYxvx9u/VSxDcsV eORKBe7/ngL3fU/6448U27xGsR1bFTU36e2xpT8N1+590/pqyVKpnWoHZtmbbVeNdu27c7YDWuy7 5ORWgg3JI0eNPVMjvGdt+limu/fmKbLh77q7eU06eMz5WVsCaMDRusjzMPqqNe+YAWuzTIN+o1uO HpXlgPx29aox/SJ18dSwap5u9+bZf7qOH9IyKOA9ZPjB33QGTG7eVjdPH3jhm3ekFn74jQczBhuc I0KJ7raaj97yvGnd0byW90LXOvbX6ec+q3fPu1dTW7l8q0zg4YQ79tRPFvg6J8u7Xu09odAenf25 anJGjffU1hdg82wvgsXsn5QiKCBFQAABBLwC7pPXdpu7bJ6nUTDZXygtG7xaLCPQPgH72bKfJfvZ ssvePxjdfe1LmbMQQAABBBBAAAEESlnA+RssZls4NDotHAL1yT5T7O+MJhhh+uJUsLXHz0uu4gdo RP8MLQhaqce8dW+rQaOV+xluQvX6+1r/U+Bf7Mh+J3HYTumd6rhpJV8HjNFpptuf6Y3J9S1rtNE8 q1ebbHxiu4PyTp9u/4eWru1leoUy1zDDVBXeprXeXWbAhGw3FG/42sltPNWfIRN3k2lBU99Yr4ak QdiMzfDRxrfdvV346uIlsjx7zIS269RzP51gbq7P2+IWs3nB3dDiddfe2d4xtTpw5FFSDq07WiRc JI5DRkzWr/5jgy5Z9qhuf2Ka7s5AcvuzR2tz5CXdWcAgVXd4dPbnqkWdinhDtu+HIi42RUMAgUoU sL/cujc/nRugtncXMzs3Rj0Bh1CofJrwVuJ1ps7dK2DHSHGnRADPhh0CTtDBfu6Ctn9eJgQQQAAB BBBAAIGKEXCCDKa29vfEuGm9EGkwIw6Yuaf5+8ydbAecUaerpYgZ38EEHcwO92Ew99U9tnhfG7R8 XaobIsncGU39atyy2Okxgc/qnVYE2W4ft0wkscXcU/dNPcLZb9e1PVpEfw3tbZJsvmf+nv5plke6 DTbSkl+1/FJ9dbmvCB1cScfJnlykfqWeWvgnPfnO02bwbH/wJfuZnbd3w4Y1vsTHDt/dt555paf2 Hj5WeidVh21tULR1LavCrTQPyFCAYnRMFDOskaNO16/MfLVpOTLjj2fq9rTAw+wXztVJX35NkzN0 LZWhqjlt6nKPTv9c+au9Z7+d/BuKaC2NoohKRlEQQACBHAXcgIP3NcdTOQwBBNIE3ICCG3gonT8Q 0yrCKgIIIIAAAggggEBBBZwHwExgIWYfULGzfS7FnUzsIWq7UbIPqKTiEO7eEnmt0T57nGQGHfYG HVoveu0eY5zuc+a1fkiOe+q1aav30KN00OA2WjB4D8+4XKUeNuBQ5+78snbxDHS8+v0F7o72vW5t 6zZ5rslGtPDZH+mEBbNyPaHLjtv82Xu+vLKO59F8ZFi9fXdav1Bjo404+DY2H124heJ1TK/jwBET dZNp8XDKs5eZ6+4dR2SNZry8SJOnjE8/pR3r3ePR1Z+r1Z993g6brjmls9/xXVMLckEAgYoV8N4M raqqam7t4N1esThUHIE8BdxWRG5LInu6+3ek+2RbnklyOAIIIIAAAggggECJC7i/B9pX+1BKLGJa OJjZtn5125bbfY2Nps8dMweqI8720m95Pl+vf1KvcSNau/mf1nfUljla8tk0TeyX3wWPbHhFNzW3 RDDnVo/VULclQn5JeY5ukr93JH8Lh8F7jDbHpgIrB+/zc13xpQFy7o17Usm4aO6f7/Hl49s5QLY/ xaUtbjon9k8cdJa+vMuX1M/etTTMr7zxC3U8sOPPO9+17J1IpVLz9jwl9VXvXp1/67WUHBNSYY3/ 2h16umGrTngj9T5ctPJNEyMb3+H3Vnd5FMvnKvVu7L6lzn/Xd1/dyBkBBCpEwAYX3KeybZW9yxVC QDURKIiA/Sy5LRvs58j7WSKIVxBiEkEAAQQQQAABBEpSwA062IdRIqZbpYAJPLgPprgVitkucG0r h+Rkzyn13yGzPtVevZP2dCvrvC7RE8vWauKEYb6tba28t+RR3yEj9vyKdvVtac9KvT5sbt1gzu9z jPbxBDFqevu7YhkzbJIm51nu9pTKd87mp/Vd3xPu0tQjHtW1xxyh/m4kK3nCspqlmrAgdWPal04n rYzY8xjp1fnNqa/9vN4stxZ8cg+r1ztp43G4ezrttcgds9V7/KFmcHMTcFjlHtRvgDxvU3drfq/d 6NHZn6u0EKf6hNO35EfVmUcTcOhMXdJGAIHOFUj+huveGLVP0NhfaEv/SZrOZSN1BNoSsH8cMl5D W0rsRwABBBBAAAEEKkvAPpgSNcGGqBkcOmBmNwjhKjRFYmaMh1TAwd1eyq87so3hEBqpb084Snd7 bkrfvcDcMJ9wWe5PaEeX6vZX/TfSL/iXr+TQAU/223mRDYtSA0Y7FyBtlIi0cQXe/HitOSq/QElH r2v9F2tSN5pNYqcc8hf96muZu9NpSitvR/PO5fxwyG92+zuLdP0hQ7Jfm8bVeskb6DEhqZ08XVnl km++xxS7Y9b69NpdI8wBzQGHzza3exwUN59u9Uh7nxb6c7V65RK3ms7rISP39K0X0wojPxbT1aAs CCCAAAIIIIAAAggggAACCCCAQDELmIdTTLTBV0LvmtPSIW2/7+AiXtlz5L/4SvfKiuZbob7t7sqB Yy9wFxOvW67T1c8u9W9rda1Bf7znPM327b9Ip+7d37cl08pPH/qFVmYJhry15B7faSOGDPc9m2/H nzjYc8Sid+7XsizpeQ4t2OJHKxf40jp8/zG+9UKs+Ls3yi/Fnn13c26GN5+16h69tb15LePC+rdm 6zHvnj0O115prTW8uwux3BWOeZUz2qD6HN9Lm95/0tdV1oiB/vdppnzbuqad7ZEt/87+XG1r2OAj 6euPifn2dfcKAYfuvgLkjwACHRawrRqYMeA90DnvgQ5/QEkAAQQQQAABBBBAoCwEbIsGpyVsNGIG jk57lNfUMBYIOnMpV7bnznv6bjKv+mKTWtY0VcPwoKN1x6DUul2aveBo/WRBW0GHOv3xgZN14bo1 vpOnTvq+hvu2tLLSeKcOvvlGLct0A9x0KXOhp9WFTeEHRxzmfzK/5xj96x7etOfomsf8AQDvXu9y Q04DPXjPyLzcs99Q3461mz/1rbsrDesf1xVprUDcfemvTZEtnk3z9eIaX3MDz762F+21/YEv9jNf F875oxpaO/WzBbr0iTt9e28+9ni/u29vYVY6w7H9JavXvb/ZXUNvHKdbFixWfbaE6hfr2j/P8B0x YlDLFiT5XtNCe+SVf6d+rur11sr5Hq+jdODAtrr48hzexYsEHLoYnOwQQAABBBBAAAEEEEAAAQQQ QACBUhSwAQfzvJczp3ep5D4AVIr1csscrt3TDFmbmlatX24Gsc021erM0+71BSns0bc/e7T63frv evDvi7XmszrZm/QNjfXatHmZ5r5wi067bi9duNzfPYoGTdf1+Yyj0DhDE24+TQ8uW5m8CR7Rmg/+ qNNuOzfVRY0tTPWPddKw9BuTNTr+2J/bvc3TvDdP1bEPPKiVn7W8pV7/2VoteHWmvvvLARr8s7O0 OFOgozml3BZ2HuAPrdz+xI81d733FnWDlr5xmwbPPF+LcktSg/cY6zvypj/9Uovrbcgook3rF+vx VxeoLsen7+14Daee8GNfeqtWTdOh/3ublm72vCui9Vr29r06dsapvqf11efnOqvVAcd9yXZopTMc O1IgM6S8mdbopmeP09DrTtONzz6upRvWq958BiImUFlfv14LX71Nx04/Lq11z1m6fuLoFlnne00L 7ZFf/p35udqoDzxvO1UfWoDB5VtwF2xD9k7fCpYNCSGAAAIIIIAAAggggAACCCCAAAIIlLKAiTUk BoY2g0PbZe8UNcM3xEt9CIfqPTVhkGml4PZcsuVRvV9/mbI9SBweNFl/Pfvn2nv21V4OqW6WLv7z LP+21tb6X6d3Lz7f1+1Ra4f6t8/XxbO/oov9G31rN5/5PQ30bUms1I6Yqtn73Kmzl69p3rto+aU6 2MyqHqtTdt1batqgpXXztaqx+RBnIVu3Mv4jW1+r3f1ITTW7724+5EmdPfNJTdzjIo3ttV0vLJ+V c6DBTWLInoeb4M+MVMDFtASZON3b6mCsnh7zrMbnODJx/1EX6a49fmFaorg5mPEG1l2nr952nWN0 sBmfYdGWtMCRc+hR+tP3puY+lkcq+byXOsMx70J4T/C9OeZr+gI7ew/IvPyTM27Q6AzjXbR9TY/S vDFmoPHkNS20R975d9bnavMK/cVDN2L3A7vk/eXJMq9FWjjkxcXBCCCAAAIIIIAAAggggAACCCCA QIUKOBGHeGIMB0/EwbZucCfvsrutdF5rNWHvkzzFXaJX1mzyrGdeHDhqmj6ceq9Oybw769ZTxjyg VT+4TEOyHuXfecr+V2iif1PGtR+e/Jq+3+qYEGFNOne+7tv/qJbnNi7RY+vm6LENLYMNUh/1KsS4 BNWjdO23prfIe966OzU9LdgwcZC/5YLvnrY3hX5H6uf7+FtOeHdLff2r8nbBZOIraXttK4fTv7dM d4zIkKYxyhxsOEtPXDZHE/t1zjPeLcrYGY4tHHLdUKvTTva3nGn7zOG64RtLdOUBmcJi5uw2r2la DoX2yDd/04lWZ3yu1qx6MRVIM1X++v6jO727rjTZvFYJOOTFxcEIIIAAAggggAACCCCAAAIIIIBA BQvETJ80dnYnM3aD7JycSr1rpb32O9GtivP6wHttjceQOLx22GT97roVmnfydE1Nu0HuS9CumBYE lxzyG/3tstX63ZQT8n5S+fDxV+pPV72gG9K6EHLzGTHoIv1p6gpde8hId1Mrr7WafOaf9O637tUl bZR5RJ+T9JMJ92rRD2e2eBK9KuTvsqlvOLeb7f33Pl8fXvyoLumf4Ya+LXGfs3THGUv1p4t/67SG SFSij6paqY2cm73P6b4xZ2U+YtAkfcnTuqFXnz09x7WW7kCdc95iLTrjNzq7tXLaVKqP0k+Ofkir rr1DRwxovf75WlX5khqUMdhTKMd8y+bBa160wbfPrjLX7Ogf65Q+zZszLIzV1ENmatFVi3X5QcMy 7Hc32Rv42a/pUM81tWcVyiNRgvzzt4GqQnyuXAHbJdhb7zyVWtVYHbtXPiFKz6ldtBgwfe7Fuygv skEAAQQ6JBCNRp1BypqamrR1R0QvL9/spHfYPgPUu0dYVVVVpi/RgEKhQjxu0aGicjICJSvQ4nP2 fuJzdvioXZzPWdj88cDnrGQvLwVHAAEEEEAAAQTyFoiZ7pPsraOGhgZFG7dr++q3FPh8vQa8MkOh bWagXxNsiNYO1scnTld8pyEaMGCA8zeZ+/dZ6bV4WKufXDdWtzdLXaQ3r7spt8Gcm88xtwjNmA0b 6zZq87bP1WSHEQhXmZvFvTSg/66miyb/DXrPaRkX61fN1NBZqS6bbvjWCl2ebLnQUL9JH9Vt1rYd 5tn3Hr00uP/uJv2ajOm0tTFV5m3JQ02Ze/XVrqbMtdW+O98tk4o2mH76m1RV3VM1oTaObXm2Grab emz6RNucWFaV+pp6DO/ncTL9/zeY95+qa036GRJI39RYp/X//FRfRIxL2LjX9s/oHmls0HaTZ1V1 TU7pNmyv04a6DfrCetspeU2H5HNN87Ryy9izZ02bT7V32DHPsiUQWv9py7PBvD99Xn131a7m2ub9 LsnxmnpL02EPb2LtyN+e3qHPlU0gukwX3Xh4aswLMz7Iqv+Ylneg0ibVVVPe17arCkY+CCCAAAII IIAAAggggAACCCCAAAJFJGAHjQ4FnNlEIZyCxYMh2dkJLHi6ViqiUudZlGE6/ZCjdPsb85Pn3amX 11+r4UPyu4kfNjfGhwwyc56553t4Te1AjTRzIaYOlTlUo1pzQ7y9U01PU49hWephghg1PT0BiLYy qu6vIUPM3MZxYRNoyCNVU4b+Gm7mDk15WuVTxg475lm2thxseYabuSBTjtfUm1eHPbyJtSN/e3qH Plfm/Pp/vJgKNpj1syccW9TBBlvnVJs3u8aEAAIIIIAAAggggAACCCCAAAIIIIBAawI20OAGG2QC EMl/cbNcLtOBh15gBh9OTQ8tfjO1whICCCDQhQKvv+4d+PwoXTCmra7SurBwrWRFwKEVGDYjgAAC CCCAAAIIIIAAAggggAAClS5gu1Pyzs74Dc1jOAScMEMi1JAaOLrUzcIDjtOPBqVqMe+NP2ilZ9iK 1B6WEEAAgU4UaFyqe5evac5gxD7f1/h8muQ0n9m1CwQcutab3BBAAAEEEEAAAQQQQAABBBBAAIHS FfC0cLAhBhtssHP5hBvspanRyV+7zi4kp1l64L1N7gqvCCCAQJcIrHztHj3myelHRx/lWSveRQIO xXttKBkCCCCAAAIIIIAAAggggAACCCBQXAKegIMtWNwMGm3ncptq9/62buiTqtX0xx5RfWq1a5fs oNNMCCBQYQJ1evLFWak6D/qNpuQ5lkzq5K5dYtDorvUmNwQQQAABBBBAAAEEEEAAAQQQQKA0BWyw wTZlcJo22HYNqRYOzkpZ/eivaRc8o76vv6Edpl67DD5SPbupflW9d9PBJu9FTv5jtXvv7ipJNwGQ LQIVKVCrY47/jW74pF49wrU67PAzTdur0pgIOJTGdaKUCCCAAAIIIIAAAggggAACCCCAQLcLBGIx 2dlONuQQCoYkMyfCD87msvlRM2Cczp80rtvrUzNksp67bnO3l4MCIIBAVwqENfqQczS6K7MsUF7l 1+atQDAkgwACCCCAAAIIIIAAAggggAACCCDgEQh4Rmpwl+2ru+w5lEUEEEAAgcoUoIVDZV53ao0A AggggAACCCCAAAIIIIAAAgjkLBA33SnF4zHFo02SnZNtGmKxuOwcIPCQsyUHIoAAAuUsQAuHcr66 1A0BBBBAAAEEEEAAAQQQQAABBBAolIC33ySzbIMMdpOdnYBDofIhHQQQQACBkhUg4FCyl46CI4AA AggggAACCCCAAAIIIIAAAl0r0KIhQ8CM4WBnJgQQQAABBIwAAQfeBggggAACCCCAAAIIIIAAAggg gAACuQmYrpVM30rOscmXFsu5JcRRCCCAAALlKEDAoRyvKnVCAAEEEEAAAQQQQAABBBBAAAEEOkPA jOMgO9vJjhcdCjmzXWZCAAEEEECAgAPvAQQQQAABBBBAAAEEEEAAAQQQQACB3AQ8LRzs4A127AZn /IZEo4fc0uAoBBBAAIGyFQiXbc2oGAIIIIAAAggggAACCCCAAAIIIIBAQQTiyUBDXLZ1Q8xp0GAD DY2xuKJmDgaDitsBHpgQQAABBCpagBYOFX35qTwCCCCAAAIIIIAAAggggAACCCCQm0DcNGmwIQU7 22XbqMFt4UADh9wMOQoBBBAodwECDuV+hakfAggggAACCCCAAAIIIIAAAgggUAgB24VSzLRuMLMT bTBpBgJBZy5E8qSBAAIIIFD6AgQcSv8aUgMEEEAAAQQQQAABBBBAAAEEEECg8wVM0wa3hYOzYHK0 LRvc1g3OWA7JUniXO79g5IAAAgggUCwCBByK5UpQDgQQQAABBBBAAAEEEEAAAQQQQKDIBWLxqOyc muytJdvKwYYiUpMz5kNqlSUEEEAAgQoRYNDoCrnQVBMBBBBAAAEEEEAAAQQQQAABBBDosECoSnEz R6v6KB4PKFLVSzEzy+laKRV0SA9AdDhfEkAAAQQQKAkBAg4lcZkoJAIIIIAAAggggAACCCCAAAII INB9AjaAEDCBhkjtEMVCvbR55IlSZIdUbYINNX2d12CQjjS67wqRMwIIIFAcAgQciuM6UAoEEECg TARi2r51u2KmSXVVz56q7rK/N7or3zK5bFQDAQQQQAABBBBAAIEcBOJ24IaqGqlHHzX2HCBFmxSu 6Z0MNoRbdKuUQ5IcggACCCBQZgIEHMrsglIdBBBAoPsEInr38f/SnEVuCSbo8p9O0s6dHnTornzd evKKAAIIIIAAAggggED5CrhdI4VCIcWrqqU+AxXr0U/bA6ZLpVhMoaoqhcJh9anuKXuMnWnpUL7v B2qGAAIItCVAwKEtIfYjgAACCOQoENO2rd5DP9O2iLSz+ZvEO9Wve0N/+t8ntMrZOEgnnneuxo/Y yXtInsu55ZtnohyOAAIIIIAAAggggAACHgEbeLCBBNutUtD+q7FjOMQVNAGGgNlugw4EGjxgLCKA AAIVKkDAoUIvPNVGAAEECiVg/8iwUzxuOlIyy8lVu0UB88STHUjOO322+u1ksMFu3aD3PvpCX9mz b97Nr3PN130iy1sGlhFAAAEEEEAAAQQQQCA3AWfsBhNssC0X7HKvXr0UjUaddZuCDTLYuafpUtW+ usfxe3huvhyFAAIIlJsAAYdyu6LUBwEEEOhmATcQYP4WyTg1NGzzbe9RoP+J2srXl2kHVyJb/6nV 6zaqMWq6q+2zq/YctosKVI0OlozTEUAAAQQQQAABBBDoHAEbQHCDCzaHKtOVkv0d3A0wePd1TglI FQEEEECgFAS4P1IKV4kyIoAAAkUs4N7oj0QiikRsi4ZEYWMxs97UpFiV/7+a2n6mz9fYJ801igfD Zt20jjBPQ9kp1yehcs0333SbC9bKgs1349In9Pu5q5NH7KkLrz5PQ3u0EmFpJR02I4AAAggggAAC CCBQCgLu7+c2sGAnu25/J66urnZe7bqd7e/d9tU9rhTqRhkRQAABBAov4L8LVPj0SREBBBBAoEIE 7B8dzr9kwMGttt1u//BwpwFjTtEVux+m+saIGWCujwYN6ufuatdrrvm2K/FWTgqGaj17eijxp5dn E4sIIIAAAggggAACCJSpgBtgcH/Pd3/Xdx/0KdNqUy0EEEAAgRwFCDjkCMVhCCCAAAJ+AfsHhp1s 6wS77LzG4qY/15izPRiMOX27mu5dnYCD/UPECQ6Y03r1H6Aac57dFrWtIMyrbZJtJ/cPFmclw49c 843FUk9aZUgm702Z8rWJBAJxRRyD/Fpo5F0ATkAAAQQQQAABBBBAoBsF3ICC+/t6eksGd3s3FpGs EUAAAQSKQICAQxFcBIqAAALlJxCJNKqpyQ6kVqVwdViJW9G519PpjijSZG7Ym3NM0+Ueprlyvmmk 5xYzZdphymQSVFWPaoXbm6DpKmn7jiYn+WC4WqFk4wUn6JAMQtidNgCRCEb4b8Qngg52cOnE7P6h Ytez/pGSY7528GqbVltTR4y9dIlyt51fpvKkronZa94rPc17hQkBBBBAAAEEEEAAAQQQQAABBBAo VQHubJTqlaPcCCBQdAKR+g167623tejNv2n1Rm/xdtW+B++ncWMP1N577Nxq4GDL5g/1wQfva9my 5Xrfn4BJLJHG2IPHadSQvt7Em5djn6/Qnx94RvW9zKbaA/WNbxyunUwrg03/eFOvvviKFqWleeBX T9bhE8ZpUG/v7fPm5FosbN2wQm+89oaeX7TM2efe1N9l74N02PjDtc/gHoqaFg42yGCnQCARcHBW zI9E8MG0Bqj7QHMff0WbTVCgIdBXXzt1svbql2jd4KbpnmNf25Nv1ERqYrGQE8Bw07TBjK2frtPy 5cuyGo875GDtu1uqyyT3/M9Xv66/vLJWoZ5RbVi0VIla2hK+pz8/9EcNqwmq0azZJ78aq3fX10+a YPzt/rQpUq8Vb7+lN//+ppamXRPtuqcmHPwVHXLgKO3SM9PJaWmxigACCCCAAAIIIIBAFwtkfUio i8tCdggggAACxSdAwKH4rgklQgCBEhT457vz9Zs5z7dS8o16f5GdX5BGnagfnjVetd57yds3aP6j d+j5xH38NtMYddx5OuvwES0CF5Ftn+mtDRuS53+qbcd9qg+e+bWeeCtzkm/97Qm99bfXddalF2q/ XaozH+RsjWntwj/r7qcyJ7Tx/cV6ZNkijRx/pPruSDzpb2/Sm/v7za0Y7B8l7o37yPbPtWTNGmfd bt+8/cTmgIO/EO3P16aTKEOy+UXDRs1/7M4OGW/5eIUJVCxL1CmZvs3H1mHD+0u10bza5URT80Z9 9QQTcEhj3f7xUs357R+1yp6Yadq4Wq8+ZWfpxKk/1PhhqcBHpsPZhgACCCCAAAIIIIBAlws0tyZ2 W/kmf+c2vwszIYAAAggg4L3lhQYCCCCAQB4C9oa2nTe+/ZRu+8O8xI1os+52JZT+6hz/3l/0wnub m4+12z75+zzNey/VxVD6ee66m997f71XL66u96Vh98XMWALuMfH4G7rzl7fq8TfbKE/8E835zeP6 pMn9YyEF4Kb1yeIndNdf3mxO21seu+xOy19+Xq+vMS0ZBqS6NLJpuJO9GW/nUFWi5YG7nr6/I/m6 adlXm76dbHobPMZu+Vt7tcc7xmu2NNfZbovGtjvr7nm2FYWdI5GI8+qWO7E/cay7zb5uX/+6bjbB hn+YZbvuphMbOlR7D92led095y93/VKvrK136sAPBBBAAAEEEEAAAQS6W8D5PdWOXRbZoXiT+X3X PPDkzI3mb5OmrYrbfeb3XCYEEEAAgcoWoIVDZV9/ao8AAh0V2LpKDz/0qpNK8y/Xww/XeV8fr936 1yjWuFWfrl+lhc8+pqUbE798b67bZo7fuTlnO6qCnez5g/Y9QkeM30/DBu+s3rY/fzNuwdbPN2jx M3dr/vLEcfZG+vOvLNP44YeoJrHJ97O5HJ6t40/4pv7ly8PUM7hda995WX94enHzHwOBwFL9ffnR mrT/AM8ZycWtK/SnRxc5K83pDh+vc48brz12rtG2uo/19ktP6bmlG5z0Bg6UPvmkZTLZtqQHHpxj 25mvuZXfXFZbXpu2fbXGbvl33fdwHTnhAA0d1N9v/Ow9mv9+6rgXXn7PtDA4RD2Shd919Ek6f9BW 05VSRB8tflJPLU7UORgcpGPPPFEj+oQVN90pmSE3FAj11WBv64bIBv1l5pPNZbMLw8efosmH769+ vcwJZopu26zFL/xRTy9O9Mdlyz73rle13/X/P3v3AWDHVR/6/3frNq1WvVrNkptccMM9GONCTAuh OgSIMSWUJOT/SEgvhCSQvJf83/unvjxCIHkhgEMwYBvcsXHBDeQmW7Zl2XJRt8pqtbu3zPx/vzP3 d3f2anfVtbv3fgdmp505c85ndq2Z85szc7n0hBT8QAABBBBAAAEEEEBgfAXse2nZwT69eC1J1Peq 6NW2SLFDv0emF79T9co5QzPT+J4hjo4AAgiMvwD/Eoz/OaAECCAwyQS84dqm6x+6UzbUnvIP60+5 Uj791tPFPqMQ6ZPvkm2TmYtOkjdfs0JOfegm+fdbHpcFs6eEJ+KtQdmG9tlLZeXK6bLygrPluNo2 bfaWUsm+CCBS6Jot577tI7LjL/+P/FSXw36r18iWgTNloV7Xe3nK5eRJe29kDzvLEnnHL79bTpxZ DE/Qi5Zs6emXy4eyFfnnG1aFvOwp/XtXrZPXnzRdrI3cy2X5bnjsoeH1W/IG+ZX3niNTksylc/p8 OevKX5IFi2+VL193v9Tf6FTbPtLEyzvSNlt3uI9r+XXOPVZOPnmGnHT+WcHY1lkPg7TxeWq8/Yv/ W1bpeTGD6MmnZdOe0+vGmbZpMn/hVBkYGJBozgw9h6+EKkTRdJk/b5bM7CyG/dra2hJD6/lQy2vr E/fLI6knvpa87ip5zwVL9bVYVoYk5JQpTJXTL/+AdEZflf/66Zbaeb1LHl1/oVx4THv9vPj5Gc2P 9QgggAACCCCAAAIIHE4Bv36362cp7ZHq2ntEdm6Q3GPXac+GAZFZx4n0zJfK6z4pma6Z+gBO8kAN 162H8yyQFwIIIDB5BHil0uQ5V5QUAQQmmkBlg9x3x/OhVHYRHsfHyfsvP13a9UK8/rqc2ny1mpOl 5/yc/PZnPyuvW9ZVDxLYzlMWnSk/93OvH9YQ3rh/JNPl1MuOC/slF/xx/RsO3ngeCqI/bN+kPIvl vZ+8So6fnt+rPLNWni2nhzLXegRYI7pnUJ/ulNU/SD4skeQXy8+/+bXaID5UPwtW2DBv5aVyzdvO HVavpJz1zFJl33vd8LSHftx0fubRdcwZ+hHtS+T4Od0h2LOXr9UpGK8IhUvqG0mmZpQsD72yqlbt Wn1LmmeyzXZ2/6FavioPf3uoR0kcny6XnbvMEu51XqIoKydceLHMTp2bx57bMJQVcwgggAACCCCA AAIIjJNAuCaOqhJrL+54UF/9qUEH2bFB4r6t+mqlVyXWi+T0dfg4FZPDIoAAAgiMswA9HMb5BHB4 BBCYfAJ+Eb1n83pZXWs0tnXRaStldrakT6wnTff+RI9NbbQ04YPCtk9t2db5aE/b27wNvs7nw1T3 sQZ+yyOT0Rf7lMtSyQ59p8B7OPi+F131JlnYXtby2N5DPSGSpTaZc6x+f+AZ7YRh+T23Vp/mP0eO afOPHmsv6V1b5IV0/Y65XOZrfuWG7z1YmeyY01a8Vi499j655dnkVUZ6RDvosLrYscu1bx4k5Rj6 afmYU9R7ZI5r31rwYICV1+ZtsPn6kM2FbzJYOXI5LXuof7LVymf72LRaTYIFtm8mk3zHoVxO7Gzf cJ51t1CfnS/LvTUjS7/o4pUyLSpJuXZ8P7aXI1ucJ6cuq8gta+08Z2TD2g3Sd+Fi6eJJMadiigAC CCCAAAIIIHAUBfw6NVz3a6/q7OCgiI5xlFz3V+yyX+dtu15Mh2vY5Ho66elwFIvKoRBAAAEEJoAA AYcJcBIoAgIITE6BTJyrN6bbRfhFJ84LT8RH6QZsrZpdbPvgF+u27PM29XlPpy3bMlga0Ov1pLdC Vv9r3fvq5tTx9m4sr9rTRrW8bNrZlpTP8xx+jILMXqxP8z/zbO3YGgwJ+3pqvYfYtUmeT+W36Lh5 0lZbHko1NGf56xGHVqTmbJs7eKO/Lzd+XO5IHXd4/bVwalyqWIBIX32lgxnv2rYpzNsPS58EJZLO gHvtX0+594yntWl5j32zI8nPlvsHtsvmrRrYqB3X9/Z98vmq7NR7OF+Won5kW/djQAABBBBAAAEE EEBgvATq16Z6a1O1oIIFF3TevungQ7Wq6xseqvFtTBFAAAEEWkeAgEPrnGtqigAChyjgF9neYN77 qnYdrjVK27QtlwlPx+fzyX9a/Sl3O6w1rvs4ajFKO+W5p9fIM2uelZ8+/UJI7/nbPn58m7ceDskT 90nPiSRdErhIGsk1YFAe1PJkpbE84ckjzaMaZ0MeyTtW/Yn9ZJ0dQz8HN6x+C6e3pdIPBVLS5bL9 bLB11kae3uZuvs7KYSaRTr1Mtu+hHtfyGGmwY8WDO+SZJ1fLs08/J488u75WzqQx391sX0urQuF8 xnEhZJesS3qEZLVniS9nMtnQo8Ec7Zz7GHbSH3Fm+HnZeM918iV97a3vX09nYJa+NrV8LE1GA0lW Nhsb9/F9mSKAAAIIIIAAAgggcKQEkmv75BtzsfZsyFTLYbSHkfSqVq/l9UEdfVDKelxntBe23X+k r4m5hj1SZ4Z8EUAAgYkpQMBhYp4XSoUAApNAYI+++scvvq24+sKeUOrQSBwarJNGZb/A9gZkr5qt t/0z2iD98iP60eXv/jhsStYN9YrwdL6fbddm6dqxfW3SUJ0uj2/x4/vU16envl+Sd7KlcV1Xh31S eqih3PMbPrVyJw3nIfEIP6z46eNYkvSyva7Ij23bDuW4XjYLY7zy2K3yle89MOxYlv9QGltKBj9+ uly+rXFqp9rySI/pNK+uTwIbtm6k/Pz4jdvqyzv049PhnKdzZR4BBBBAAAEEEEAAgaMrYNen9hBM Lrmgr13bDl37R9rbwXpNMyCAAAIItLYAAYfWPv/UHgEEDkLALrLtYrui32rweVvO6jt57Cl3G60R 2XsWeEO0pbF5CzzY4A3NG35yo3zl+ofr6y2dDStWvkZmTZ8mhaweT78nsP7m2+VZXZ9sT44dRUlD t63z/cLO+iOr5bAy2Jgugx0/nTZ5ct6/TaCvRdL9bKhoz4N0/V7ZskfOmt9Zz8/rYd9GSI6vTzvV Gt9t//S8LXsZ/dg+tWP4cSydvRrKly3NgR7X8rAhXefNj/xA/u3Gn9aNbbvlffwpZ8j0nm7tnWL9 Gary0m0/lGdq/pbGBktneZmLzQdTnff6q3Td2da5n+1j6dunzwj18V4ci8+7Qh07dP/kn2BLZ4Nv 92lYrzGsWctOlIKei7jWc8bytMH3Cwv8QAABBBBAAAEEEEDgCAnY9Wf6+rwyOCDZkr4DtDbYdhvt viBbvzcg8OA+TBFAAIFWEyDg0GpnnPoigMAhC/gF99S5CzWvNeHi2jK1J/NtsEZnG61BON0o7A3U 6XXSu1au+95PQjrL14Zz3vpB+ZlTFkkhTr7JYA3QdoG/NLtBnv3Bk7XjjX4BPyz/WnnSZbG8bGhM Z+u8DDZNz9u2kr6T1QavW2N9/Bi19vOQ9kB+pI9p+/nxD/W4md3PyXeu/+mwopzzlg/KhScvlHaN /XjAxKbHFjbJM99fHdI2lse9bJpNVdJeqTRU9+Hn3PLIt7cNO/as2Utk+fIeKRaH9xix82zpPeBg O5lxW1uSblgmLCCAAAIIIIAAAgggcJQF7FrV7iXs8aTQr1mXtbO23VgkfZxrtyiWjgEBBBBAoHUF CDi07rmn5gggcIACjRfOuYaG4CfXb5ULFi8NT7hbQ3Fjw3zj4Sy/0sBO2awbbN7GUy7/JXnDyfN1 xdBT/h5wqJSHggCWl13sWw8HO47t6w3ifpxcrXeDPXFvaXxI9tPuznpj4Pvo7rUyJPl6eXwfm67d 0qs9LRbW6+f72jTJsyi5cJwkoBFuQ1IN8+m80vN+LJ9G0fB6HupxB/fskE1Wwdqw8tIPyhtOWaBl tm80DK0353LKOJSnFpzxfUeaWv3N153d2kxsiPUYXjdb3rJtl/7sCWa27D0i0mlsPQMCCCCAAAII IIAAAuMpYNenNvh1aljWddo3Wtfq99hso/6wq97YrvvDCos/1GZsOwMCCCCAQMsJDLVAtVzVqTAC CCBw4AJ+0R32zBbCxbfnsuXup2S7vl7HB2t4brzYjkol/dbD0LDz5RfqC5b3MYvnhDy9sdo2po+Z ntcN9X19Jn08DSeE4/s6L48t+zrfb6RpYdp8WVk7Rki/6mnZVh3atzG/3S88LN+3dz7Vhv05hqdN T4vT58vJ6TwO4bjmtWvDi+ns5Zgls4OpbfNxNG/f0eti0/S8b7dbrtGGwvQ5sri20Y63/p4n5VW9 K7N5G7wMNu95N87bMgMCCCCAAAIIIIAAAuMuYMEEu4610a6N9X92VRvpss3b4Ne5YYEfCCCAAAIt JzDUMtZyVafCCCCAwMEJeANxbtoyudRbkkNWq+SmB14IjcbWcGwN8kOjyOYn75I//eIX5VsPW5+G 5J392c7uWu+A5DsG27b3hlf82NP29oofm9rxytufldtuSV71E3bex490w7U9QW+jrWsc09l4verT 3DRZtjJJYetEnpDbH3ox5JEONliK3hcflL//xp1hW7LHgf883MdNel1ol+/OKcHQTbfv6Au2tt2O ac42X9mxVu5Q47TdaLWoVkthU+L5rLy0zb5fkfj6PvX6FGbL6aele208Ineqo2/39P674uerUCho nsm5S58/T88UAQQQQAABBBBAAIGjLmD3BdaT10adt7sE/dpZGG2eAQEEEEAAAQIO/A4ggAACBy3Q Lsedfd6wvV+442ty7R2Py/a+pEFaoor0bl0nd379T+Qfr/1hSDutI3mbnTU4t0+ZOqzh+b5v3iHP bR8M65KMK7Jl3cPyP7/0bRn+nP6ww4640NgAPmKiMVcWZfHJjfX7v3LjT56Xvlo3jUpppzx933Xy //3rzWPmdGAbD+9x27oSYy/Dvd+4XdbWjO0c6Fcc6sbrPdE+plNmzxuW4o4f3C8bB/SmSzuU923f IE8/vV7CYkiVl2VnXjEs/dq7viFfv+tJ2bGnUg9U+PmqDOyWV557VK7/+l/IX/3VdbKpPDyQMSwj FhBAAAEEEEAAAQQQOJoC+pCNBRrCaPM62BU1wYZAwQ8EEEAAARXgGw78GiCAAAIHKOANwzbtOe4s uXj2vXLX1uRi27Jac8918vS9SQ+HkbLesKu/3nMhP22RnKVPBz2oCe0JfJHH5Np/ekJWvOY8WdAV yfr7HpTn9YLejzlSfqOta9zHlm1oXD/W/t3H7l2/h2/4N/nJjUON4Emjvd1zpJ/iHy3Xfa+38h3K cUN5tCzmaXnlehYG4wfq5XtcvvmPj8sJZ14o8zoqwfiFfRdrWIops4+R2bpmcy3PzOb75Ev/44GU 7Qny4d98l8zRf2WtDG1zXiPvOu9h+db9W+r5vPzgjfLPD31fZM4SOWXhDMlU9sjmzU/rmCRJejdo BuEbHEO/T5YfAwIIIIAAAggggAAC4yFg19o5vRzN6mjz4co0p8+y2siAAAIIIICACvAvAr8GCCCA wAEIpBt7k/kpcs77rpazZu39TM/IDfDnymWnzqs3zse5GXLB1W8Ky+liPPvIj+VHGmx4IbVyxcph 72+S6DA3PNvz+XsPWr+r3i8n6c1E4+D18+nss98uH/6lK+vJbP3IedaTjDFz8Me156v8mwpWBsnP lAuvfvMwYzt3z6y6T+7+8UOyvuZo645rMPZ89ipo5yK5+FwLOYw2DHlZvhY8OPZ175N3XHRcKiiR 7JvZsl6eWLVKnnjiGdmyJQnkJPvYfJsU9Y7OlhkQQAABBBBAAAEEEBhvAbsq9et/v0K1a1V7PagP XLu6BFMEEECgNQXo4dCa551aI4DAYRCoX1QXZ8slV39Kjn30J/LALffLy7XGYf/OgX0fILP0VLni 3PPk9OPnSVGb4aMoeQLfthVmrZRf+1i33HfrzXL/s1tDydIX6ZklZ8hbLjxfjp83ILev/j/ycEhR lGwIAvhlvkaQs8VhtSru4ymjbC6dvLPesG3ltpsIn0r7fHnzpz8qSx+4V35w/5P1xm+vf3XmifKm Sy+QE+d3S2Xro6lMZ0p7bqjh3Tc0lrMtn3xfwo/n04M9bhzPlA49bgg26EHNuDjnZPnVj3bK/bff Kg+s3eZFCWmC9ZLT5S3nnSsnLizLbav/qWZc0LfRDg1+TmxqAYRlr7tKfr7tTrnurkfr+di24HLq culp03RREixI9i3K8vPfLp9YvlZ++vDD8uBTL4fM0/n60eYsOUVOPXmlnHTycplZSOfhKZgigAAC CCCAAAIIIHB0BTzQEEf6nTkdbbBrWeuoXa0kvbJtnV+H2zwDAggggEDrCWT0H4K9W4Naz4EaI4DA JBCof0C5XJa+wYrc+3TScHzB8TOlqy0vyUd29RU6+gqaIzFYw7UN9pFh+0/n4OBgaMwua3ls2Rqa Mxn9CPHAgOweKElGy1EotEmnfrS4sz1fb6j3svl+pVIp5GN5VEp7ZKB/UJ/Qt7xy0tbVLd0dhbDd jqszYvtli+2aZzHk6Q30oVzVsvQPliWnHxzu6ugIZWprawvp7GbAjmH7W10GtJxVnS9XYym0FaS9 mORnjjZY/Tx9vX7VQdnT1y/9FQ2UaLpCx1Q9jtZN8/V6RFpO3SwdXR2SVxM/vh3T8rF0caqcne3t oXz5fBIDdxefBtcDOG57Z3s4rv8e+HEtPxtizatv9x7tIWK/J9nwHQ0z9uOF8msd8u0ahMnrdi1f cm6T4I7XM9RD66MnXPr61Mo+zJ0rSE9PTzg34WD6wx09veVlQ05/V/r798hgWQNSIVChnm1F6erq Cse1dcl6+10Y+r22+SM57PV3tib5O7vwxFnh78zOU7o8R7Is5I0AAggggAACCCAwfgJ27W6D3WfY NXVfX59Efdsl+9DXJLtrg0x94S67uJY+fX1oNHW+DFzwMclOmSXd3d3h+tnvK4709ev4CXFkBBBA AIGRBOjhMJIK6xBAAIERBPxC2Rv4rUHb1nmDdvINBn2DjzZUT9PRt8d6EV4qReGi27L1hnDPz6aW p+2fL3bK1PYp4ejeAO8BjnDBr2kLGkDI6ktTbT8fbYdQrkxR2rUh3dfbtHHwbZY+o0GGnN5I2Lqw nEpv5bRjDqtfpiCdPRrs0Ey9HlULhOjgNyQW7LCmfAs2WJ4+eFlGK6enDdv1uD6148sBHDc3kkut jlaWTL5duqe1h4CJly1dzxAo0rrna68yci8vv59XX45yGlSa2lYPeNl+ds7cxx3tfNpx/PdEcnnp nNIjXbXyelky+vtSLuvvQq1h34/j25kigAACCCCAAAIIIDCeAvoYk367YejZ1XAdn7ruH8+ycWwE EEAAgfEXIOAw/ueAEiCAwCQV8AbyxgZhb3i3qY2+PT2frrJvT6+zec/H14+WrnG7pRsrrW9Pp/F5 n1qe1lBujf3pdbbey9U4tW2e1qY+70623QZfn07j62z7oRzX9rfjeX429XKm5y2dr7d5H3w/W7Z8 0mX3/W3qo+9n05Hys/Wep09tnQ2W3kYPSNg6S+Pmo+Vn6RgQQAABBBBAAAEEEBgPAbtGtUeabAzz Gnew0EMIPwzFIMajaBwTAQQQQGCCCBBwmCAngmIggMDEF/AGY2+E9oZhexLd5+2i2+Zt8Kmnb9zf 11s6b1z2qe3v857Ol/3Jd5/6dntljx3Dj+PbfZ2vt7xHWufpLT/bbk/i29TWj1Q/L48fvzF/W+/b 7Jg2b/s0HttfheX7WwO8pXUX38899+e4lpd34bZ6+D429R4Gvs6Pa/X0wdbZcW307V4O38/S27wv +76+7PtZfWzwtJ6P18fLY+sZEEAAAQQQQAABBBCYyAJJ/2m739EHk6yg+sNeLWpjsmIil56yIYAA AggcDYGh1pWjcTSOgQACCDSRgDcoe0NxY0Ozb7epj57Wt9k+/kS/N0g35uNknocvW16ej63zJ+XT +6e3W5r0sqdvXO9pfOplTufbuE/jsu1r+3kZbdn39+P6sm1Lj94Qn3ZJ529p00N62ebTx7R0tmzH 8nw9fePU87T1nk9jXul9bJvl6fXx/SyfdDpbtuOPVh/bPtKQzm+k7axDAAEEEEAAAQQQQOCoC9il uF7bhlHnM3HyciXr3KBX0Ue9OBwQAQQQQGDiCRBwmHjnhBIhgMAEF/DGZH8i3pa9Qdum/sS6V8Ma pm2wBmdvRPaprW/cf7SGcUtrQ7oRfKR8bJ0Nvs2Omx78yXw/bjqtrfPy+tTTWbm8nun8bLvn4dP0 OnfyfTy/dBqb93L61D/i7OV1l3Q+fjyfpvP08tvUG/xHOj++TzpfW+ejl9/z8/LYdsvPvteQHmy7 72tT3897Wlj90o42nx48vU19f5syIIAAAggggAACCCAwngJ23WpjRu8LbLQhBBrsk2u2WLuGDhv4 gQACCCDQsgIEHFr21FNxBBA4XALeGGwNxH4Rns7bG459nTco+34+9f09na/3qa33eZuOlI+t9wZs 3+75pafpfHz9aOk9bWP5fD/fblMbw01Ibd7TpKfpdLZ+X8f1PNN52Lyt96mn8bx9fUigP2y9Byy8 wT+9zedtOloejWl8OZ2f7etDY718W6Ojn6/0fp7W1qXnPQ1TBBBAAAEEEEAAAQTGT8DCDKmHZuwa OHUdPH7l4sgIIIAAAhNBgIDDRDgLlAEBBCaVQGMDsD8B7z0b/Al9r5Sn9wZoX27c7g3ijQ3Qo6X3 /DyfxmXfz6eN6fwbB77e0/nUy9FYP1/v6Rr3b1w+0HSev5fPXX39gebn5Wn03Vd+fpzGqTt7+Rrz 9fSNvwe+n6f3qZfPp76/p/dln3o6pggggAACCCCAAAIIHG0Be7zGww31+Yw+eKUjAwIIIIAAAiZA wIHfAwQQQOAwCYzWIDza+sbDjpaucX3jcmM+R2q58bj7Wj5c5djXcRq3j3bc0dI1rm9cHi0/X9+Y vnHZ0/nUt/vU1/t0tPW+nSkCCCCAAAIIIIAAAuMlYA/tWKAhBBsaXg06XmXiuAgggAACE0uAgMPE Oh+UBgEEJpFAY8OwP9HuT843VqUxvW9vXN+4f+N2369xeqDp9pW+cXtj/Rq3N5ZntOV97de4/XAf 92B9vT5ePp8eaH6+n08938bpvrY3pmcZAQQQQAABBBBAAIGjIhBXtZuDjj5k9JtxNtYGu47lWtY1 mCKAAAKtJ0Cft9Y759QYAQQQQAABBBBAAAEEEEAAAQQQOHQB+3ZD/R1L1u+BAQEEEECg1QXo4dDq vwHUHwEEDrvAoT7Nc6j7H/YKNWQ4XuU7XMc9XPk4y8Hmd7D7+XGZIoAAAggggAACCCBwNAWsZ2/o 3Rtp7wYba0NsMQdiDc7BFAEEEGh5AXo4tPyvAAAIIIAAAggggAACCCCAAAIIIIDAvgUsruCBhxBj sN4N1svBezrsOwtSIIAAAgg0uQABhyY/wVQPAQQQQAABBBBAAAEEEEAAAQQQOBwCFmzIZjNhDL0d NNM4kw2j9eClF+/hUCYPBBBAYHILEHCY3OeP0iOAAAIIIIAAAggggAACCCCAAAJHRyDp4mDdHLRX g070qB5osHkGBBBAAAEECDjwO4AAAggggAACCCCAAAIIIIAAAgggMKKAv0KpvrEaidhYGzzg4MtM EUAAAQRaW4CAQ2uff2qPAAIIIIAAAggggAACCCCAAAII7LeAf7LBdrBgg/Vs8J4O+50JCRFAAAEE mlYg37Q1o2IIIIAAAk0lEN4RG5Vk56vbpXfPoESSlUJbu0ydPkO6ilneF9tUZ5vKIIAAAggggAAC CExEAXujUhRV9UfV3qiUBBsyef2GQ77+aqWJWG7KhAACCCBw9AQIOBw9a46EAAIIIHAIAjvXPSRf +9cbZPNeeSyVD/7GB+TYKbmhLdbDmz58Qx7MIYAAAggggAACCCBwGARiDTPE+XaJCx1SKXQnH4wu 6HK+LQQfDsMhyAIBBBBAYJILEHCY5CeQ4iOAAALNLhBFkQy8dL/89Ve+P0pVn5ON2/plaWenbF19 m/zdtXeHdJm5Z8uHP/QWWdRhz14xIIAAAggggAACCCCAwMEI+DcabCoaaOhfeKbEA7ukt2dFkt3c 5ZJpnypFDTqENAdzEPZBAAEEEGgaAZ7/bJpTSUUQQACBZhXok0eu/0G9cslH65bIGWecIktie1us duW2mx8pyQsPJsGGsHLzw/Ly1oEwyw8EEEAAAQQQQAABBBA4DAJ63V1t65FK+wypdM2Sctdsidt7 RNqmaA/jHAGHw0BMFggggMBkF6CHw2Q/g5QfAQQQaFIB69lgw8DGZ+TGDZGEbzjocjTzXPnIB18v c9s1Zn7FG6U8GEtbV17K5ZJ26470nbJht+QdslLV5WRFNkuMPZHhJwIIIIAAAggggAAC+y/gPRwK hYLu1CnVGcukWqlIaerScM0dt3dIXrdlC21i19y5HIGH/dclJQIIINB8AgQcmu+cUiMEEECgqQSq 1cEQbPCAw3mvP1Nm5j2wkJW2Dv1AnfZ0iCUnU/ThqvRQzKe+65DewDwCCCCAAAIIIIAAAgjst4C/ Ksmm2WKHxDn7aHQSWMgW9VVKGmSwQAMP+ew3KQkRQACBphUg4NC0p5aKIYAAApNTwAML1jPB5vt3 9oZptVoNFWpvy0pFn6jyJ6dsPtz46NNUyy/9jHziNdulvxxpr+6ZMntaVmw/fyrLMvCbpcmpQ6kR QAABBBBAAAEjuvLgAABAAElEQVQEEDg6An7dbEEEuy4vFouSzyfNSHat3tHREQpiPR8sjW23qV97 +/5Hp7QcBQEEEEBgoggQcJgoZ4JyIIAAAgiMKNC7dUO4wbGNcTxLprbn6svpHZJARUGmzpgtU3WD BSQ8eJFOxzwCCCCAAAIIIIAAAggcmIAHESygYEEHCzjYvA3es8EDDD49sCOQGgEEEECgWQQIODTL maQeCCDQ8gLWuF6p6HcMKnbxn5d8MS92C7C/F/z1xvlI38daqkjtywchn3ztSaVDQbb8Iy1fScun X5TTfPUJKS1gY/m8HNYzweazmVy4oUl6OMyQninJU1NeFrvBscG/1eBTy9dGvxHy9I3TpFwVqYRv PSQ3ULV7p2FJG8s5bCMLCCCAAAIIIIAAAgg0qYBfB3vvBlu2a2hf7/PJNx70Sn+ki+kmtaFaCCCA AAJ7CxBw2NuENQgggMCkEqj0bpInH31cHn7kR/L85nTR58gJZ62UM884TY47ZkYIPqS3DpuP+uWl px+XJ376hPx4zfPDNtnCnBPOkrNOOUVWnrRMusf4lyPa+axc97VbpLdTd+o+Td7+9gulJxvJ1nWP yn133isPDy+gnHrRm+Wi88+SuV3DP+jc/8qjcv0dj0m+syAPPfREqjxPyq3XZWVqm74xthZo8Knd 6NjgAYfclCXyhsvOkumpvYfNlnbKmkdXyU8euEPWDHMTWXrCqdJdHJZaMuWyLDz3Sjl3WcOHIoYn YwkBBBBAAAEEEEAAgaYU8ACDBxT8+tuXm7LSVAoBBBBA4IAFxmg2OuC82AEBBBBA4CgI+IW9Tbeu vkv+7to7wlF9/VARNsqTD26Upx7S7Se8UT7z3vOlO9WjwNMPbnlKvv13X5enajv6+qF8RDY++aDc +NRDcqMslfd84ipZObe9/kSTp7P9yn3b5ZGNG2urFkjvG7bImlv/Vm54zF6HlAQEPL1NH7nre/Lo jx6Ud3/qGjl5dlvYZAGDbS88IY+tWRP28Z4Ovt+Lz64Ox/ZAg9/gNOafyfTLOW94rcyo9XTw/S3d wKbV8vV/+KY8rysb97N0zz35iE2GDXaDlT/pDfX0fsM1LBELCCCAAAIIIIAAAgg0mYBf9zZOG6vp 2xvXs4wAAggg0FoCwx8pba26U1sEEEBgUgtsXX1TCDZYg3m60XzE5ad+IHc+9epe9S1tWiVfqAUb RtwvFSRItq+Ta//xL2TVptJeeYUVqX9V4vhh+ae//hu5/tHh5dt7x01y7d/dIJsqQ1tyMhDqtK96 De0x0lybJC9batjWt16+8Y/XyroGt9lLjpcls5OyukX6+JbLtj3lhsxYRAABBBBAAAEEEEAAAQQQ QAABBBBwAXo4uARTBBBAYIILeON3mPatk298497wnYX6+sXnywd+9hyZN61NotIe2b5hnTxw+/Xy xJbkWwZbtu2WarWn/k7VqLRRvvv335ZoWMP78fKm91wgKxbMkvZiVioDvbLh+afk1u/cLltqPQWs x8G3//6HsvSPL5f0y4VsfUVH66HgZUqTnn3Zu+TsExdJe3aPvPjEj+U/b11V7yWRyaySh5/8Gbni pOlh/+mnvkU+MG2rfoFOZN29X5HbVuv3HzTfTGa2XPbuK2VBW1ay+rE6e4rKn6TKZGLZsOr7ctOq LeGwtTcu1YuQvGopkmfu+Z6s1XLaYOWcffbb5N0Xn1R7VVQkO195XK7/6g2yvran5X/F1R+X4zsy UuiZUX9lk/es8OPXkjNBAAEEEEAAAQQQQKCpBbj+berTS+UQQACBQxZIPYt6yHmRAQIIIIDAURJY //BdYp8dsAbzMJ78Rvm1X3idLJzeHr7VkC92ypylp8hbrvlv8v4rTg2lWjine1jptjx+jzyq+/sQ x+fLx37znXLK0jkh2GDr8+3dsvikc+SDv/xOmZ0KTMTx3fLQs72+a5haOaJoqDdDvWzxYvn5j31G Lj1rufR0FaXY3iPLz3qjfPjNp9cb7y2DHz/yvAyEDzfrh6QLU2X+McfI3LkLZPGiE1MBjNkyd/48 mT13rixYsCCM8+bNk2TUtAvmpNIOK16yUNkkj969KcyH8s2+RK66NAk2WEDCDt897xR5+/uTVycl dYpk07ZYps+apd91yI6d/wiHZBUCCCCAAAIIIIAAAk0lEOtFs42RPsRjo91TpO4rmqquVAYBBBBA 4IAF6OFwwGTsgAACCIyPgDV+21AZeFF+dNtzobE+aRBfLr/4+lMkXyqJvejInziyaSaTkwWnXymf OeVyKXZ2ag+Hamgwj+Md8sh3Hg3zts6Gt39Mv/EQlaRSO44fL2zsWiJvf+sZ8g/XPRR6SFjed92/ Rs5ferr2WEga4a3B3vIaOoaVd7G8+xPvkGVTYilp+WzwfHuOe42cWn2oHvTIDQxIRfOwf5gsjeVj eZbLSY8JWxfH+qqlqk41keWX1DFTz3dgsBL2SQwqum9ZqvrxZ08XV6oyoPlYrw7L+7zXnyAFTWMv SvJy2frc7GVydqUiP9b11pNhV2+fVHTZ5j0v7+EQDs4PBBBAAAEEEEAAAQSaXCBcL1ugYWCXxhuq kg2X4RmJ8vp9t6x2Tc6FC+9wvdzkFFQPAQQQQGAMAXo4jIHDJgQQQGAiCgxue0XWhMb3Wm+C00+T +W3JfNIoX1ufKnyuUAg9H2xVaMTftE7uruVh6+IVb5Il+n6k9P6N891LT5TjLK0fe8062TaY7iEx VIaQp6a74D1vkWXdmaF9fF+bZqbIvBVDZY2fXydbNT/P3/LYn8HTjzS1uvpg85amkCrD1I5C/Xjp /aMoL8VZyZ7p9TbPgAACCCCAAAIIIIBAywpYj4a+VyWze4vE21+WeOcGyWgAQgb7lIRr5Zb9vaDi CCCAQEqAHg4pDGYRQACBiSjgjdzeYC5R0oDvy+evmCmRPn2f128a2JB+8n60p/HjuDKsJ8Jpx82R vDbIW/N8rvbxg6SXgIR0lm8lO00WL6zK0y/5U/4DIXhRqSQ3FqF3g+bhPRxsn/Z8JixbXp6vBwGq 1ZzMPGa5RM+srT0Fpb0vtB5xIReCAF6PrD465WXJZPzY+j0FDaLY4D7WA8EHX2dTO57vH1ci6bd6 1tZv3qw3RzNnhN38eKF8pe3y0hYNftQyjHUfHywvz8/XMUUAAQQQQAABBBBAoFkF/No6XG9rsCF7 75dENNCQ2/a89jxul+iMd4n0zJd4+c9Ipq2rfj/CNXOz/kZQLwQQQGBsAXo4jO3DVgQQQGDCCeze sa3+VL4VrqtNuy7rYBf03mju8+mppfGbhd3bd9hiGGzd3FlTfHFYPrbS8kxuFvIyfdHi+j6236A2 4Ptgy56/rbP5Spy8rsmWLY/0aOuyuaGgQeP+9bSSvDLJ0ttQXz9CfkmK5GcoS61Mnnes+1gPBx8e /u4DsiV501M9X9v20qr7Za0n0mnXlLbUErMIIIAAAggggAACCLSeQLim1h4OsQYd4t1bRXZtlEzv JokGeiWyHg76uqVwDd56NNQYAQQQQCAlQA+HFAazCCCAwEQW8B4NvTs2h6f2vRE90tCx9R6w0Rrj vaeDN8xbOpu3weatB8LuXUkevq6s62w/39/3te32HQTbL7xmSOMD3mMgivqlNKCt9V0dlmyvmwsL VNhoPRF83vL1etg+Od2eLp+t82P7cbK5oV4N9k2KYrEobW3Zen1tf88jX+udYfloiZKfuj0sWbrs LHntz54kj934RK28q+Qr/2tA3vy+i+TY2VMl6t8h6x69V26477m6WSZznJyxfMawOngZQ8b8QAAB BBBAAAEEEECgiQX8+t16OMR6b9Cu30XLVGvBhXCfoNfbkV5r6/ZMXr/toNf4Ntg1MwMCCCCAQOsJ EHBovXNOjRFAYJIKJI3+2qOg1mnAlpMhuaBPN+qnL+79gn+kanseBW3I98EDF77N9rebDBu8v0Ky rSiFYrItfTxLV1/Wmwyf91cqeb6Wzof0Opu3fWz0snseIX3txiWdn+1jZczWtiX5jnyD05HER/zQ On1GbvyPZ+vL6bLYyvPecZnMTTqR1NMwgwACCCCAAAIIIIBAqwmEe4LwelJ9Zan2ZrAGJbsjsdeV 2itI/RUafj3faj7UFwEEEEAgESDgwG8CAgggMMEFGhvAu+cs0BKvqZdam+frPRzSQQdvrPeE1rPB BsuvZ84Sna6u9wzY1V+uP8Fv+3mDv98s2M1Ftdov2ze85NnVp7bN0lvaSJ9sSg+23gIDlqcHCGxq +9iY094L6SFdV9vHli2I4PlbWpv3MtqyzVte+xosr7h/vdz8rSeGJfVjWr7Dh1nyhne+Xc49flr9 mH7cvdMO35MlBBBAAAEEEEAAAQQmu4BfJ/u1e+j5XCpJoaL3DlXt7WDX11rJSkl7ROuoXaP1lanl +nX/ZK8/5UcAAQQQODgBAg4H58ZeCCCAwFEV8It9O2hWXymUXl79/Ga5YNGyenmsUXxfQzY71KPB 0v543Ua59MSZoWHdGtPTozfmZ6q75KVn0jn3SDHXGGAY2p7OIz3v+YXG+4bvMwztPfJcOh+fNwuf t71sPu2Tzmn3K89pfwZ//dNp8p5rzpbc9ldk/StbpFeDLiIF6Zg+TRbOO0bmL5gjnfqvpOWXNrVl BgQQQAABBBBAAAEEWk3AruOtJ4NebCdjDSD0cLBrcgtA2DYGBBBAAIGWFiDg0NKnn8ojgMBkErCL 99C4nk8+tOxl3/yjJ2Xbhctkfi1Q4I3j3jBu+0T6JFJVexZYmMGWc+1dMlvnN9cyyTz8mGy9/FRZ 0D7Uu6Gx4X73+tWyOt3YfvoxMj0V27D0PoZy6rKVJT3adg84ePlt3ViDb0+mQ8ewZd9m+zcuj5Tn 7lf143a1IV40U+ZOny5FHRcuH/r2hZXdB8uzsfzpY3o6pggggAACCCCAAAIINKuAXb/7aAGH2D4c raMP1snZLqGz+sOupdPX056GKQIIIIBA6wikmopap9LUFAEEEJjMAvlpx8qli9M1WCU3PfBCekVq PpJNq++Uz3/hC/Kthz28oDcDPUvk7BWpZPKsXH/nU1JJr0rP73lRbvrmfek18sYzl9Xf0zpswz4W vBF/H8mOyOZh35Ref7v81033y7oNm2TLq6/KVh137uyV3Xv2yMDAgJQqyWuaPJDh0yNSMDJFAAEE EEAAAQQQQGACC3gQwR4VCj0dNLAQHhuqPasTtqfnJ3BdKBoCCCCAwJEVoIfDkfUldwQQQOCwCXiD dybTIce/9ny55fl76k/4v3DH1+Ta6jvl8vNOkNlTtR9DVJHd21+Sn972r3LHU0kRpnXkU08bFWXF eRfr95J/GDbaDcKmB74lX670yjsvOVPmTu0IecfVQdm6/gm58avflbWa0m80ZPEVctKctnqvAitb emhcTm8bz/npi4/TOiTfrrC6vPjoXfLSYz+qO1rZvOzWsyEz53i56Kyz5OyzTpB2W26o53jWhWMj gAACCCCAAAIIIHA0BUKgwb4Ll9HIgo52PW3/0/4Oov0ewoek7bVKDAgggAACrS1AwKG1zz+1RwCB SSKQbui2+akrzpSLZ98jd24ZuqBfc8918vS9Q68Z8n08SLCxd2BYbdvnny4/95ofyncfTVZbuk0/ uVn+9yO3icxZKks7RZ5//vnkRmLYjcMKueptp0l7LTc/zrDMJ+hCfuZp8uErn5Ev3bj3h6PT9ajP b3lG7rvlOR2Xyvs+/X45Ycbw11lN0GpSLAQQQAABBBBAAAEEjpyA3RvU7g/07kNDDbqoo80zIIAA AgggwCuV+B1AAAEEJoGABw2sqNYYns1OlXPed7WcrR9i8Pep2rSqTxx5F+f0fBy/Vi47ZW7YZvsn Y5uc8MZfkTedObMeVLDjhPw2Pifr1q0L6z2fJN/T5H2ffLss6crV8hj6xoHneyicyUuMGnMoDVsx cpphSeoL+vxVfbC6xXGvvPjC6vo6m5m1/CR5zcqVsmLFClmxeLEsWTJnhJ4Mz8vX/+ZO2VG7sRqW AQsIIIAAAggggAACCLSQQCaOQm8Gq7IFGnKZbBhtngEBBBBAAAF6OPA7gAACCEwCAWvMt8Eb9a3x PNM2Ry65+lOy7NGH5YGb75eXa43hYVstfbz4ZLni3PPk9OPnSTHcDtjDSEO3AnHcISddcrXMP+5J +clPH5JHnt1a326vFLIggw3x7BXy+rNPl1NPWKyvFgqr6mVJlpKf2WwxvShFzWOkwcuQ1X+Fho7T JYURkhc6pqXSFPb6boTl5WOmmP5nrTgsP0vz0n3fkZtT8YaTLvsFefPpC+sBBvMtFAp6A1WVHZue kTv+7XuyVvez9XF8tzz1ykVywSLt+sGAAAIIIIAAAggggEArCuhtid2ZhLuT5Bal3sOhFTmoMwII IIDA3gLplpm9t7IGAQQQQGDcBTzYYA3z1mheLBalUqmEUaRLlpx6kY4XSEk/dtzbPygzZs6UaT3T 5NUdvdLZnvxnPh4clEgb0n3o6OgIDet9fX0hn2nHnCRv0PF1pQEZHByQapzVJ/2XyOYt26SsQYcp 7cVa8CHSxv98aIDP5/PS3t4upVKp3uCfm7FSPvsby2SwXJWcHq+nuzscx9JY8CJpuB8KeMw89a3y J+e+V/bs6ZdKpPvU3gVr5fQgwoyTLpM/O+fnZdur27VcWuPCUIDB65PTr0F3dXVJfPKV8pllF0tZ E1rZ7CPRHjTp7MhJ+4yzdZd1Ybf42CvkDafOq2+3QMOMGTNk9+7dalCWqXNPkCveuVn+9j9/HMpt x5jaJqEXiWVgyzb4+QkL/EAAAQQQQAABBBBAoEkFwvV5pD2iq3pdr2PteSaJs7kw2nUx18ZNevKp FgIIIHAAAiM8S3oAe5MUAQQQQOCoC1jgwRrXrcHfLvqTISuFji5ZtGiRzJs7Vxvb22TOrGn1xnRL 469GsoZ4DxZ0diZP63vjfr7YLt09M+TYY48NgY2FC+bJ9O6ueiO75WNprXHeghZWFguAeCAhlEcD ErZu6pQpIY0dy5Ztmzf++/GmaBrbNm1ajwZH/KsQdpTkOJZvT0+P5DSPWbNmSltBb2Y0Hx8tPyuD HcMCAJZfRqcFTaer6/mEAEtxiiw/5xx55zvfGdZfcPYy7fWRDJaHBRssHzteW1tbqHNcTB7bsuMt X75cTp495FXblQkCCCCAAAIIIIAAAi0k4PcfVuXavF6z6w1BCxlQVQQQQACBsQQIOIylwzYEEEBg Agh447pPo+9cK/GmDTJ16tTQQG6N7hZMsEbybu1RMHjrD2Tgv31c7Pl7a4D33hCexhrVy3/5OSn9 +7+EgIDtY4MHA6ZPny6Z/j0y+NH3SeXxR0IDvAUY7Pg2WIDA8o2eWi2VX36/ZPp2h3X+NJMdxwIZ Npa+/q9S+vM/rAcEbJuVx9NYGQd/45NSuvnGkN6OY9vL5XI4luURb9kkpWveK/ErL2lgYloIblhZ LZ0d0+pTvfcuKf36RyWr+Yfy63o/lgVYLN+B//4HsvZzvyvnnXdeCDqsWbtBe0IkX3mYNWuWZLUX yKDWp/yTB5IgR64sD912ZziOBWDe//73y+Aza6R6y/dD3pa/lcPPSygwPxBAAAEEEEAAAQQQaHIB e7DHH+4JgYZIgw02EnRo8jNP9RBAAIH9EyDgsH9OpEIAAQTGXcAbtjMvrJP4l94Vgg7WAG+N6dYw bw3tA9oYXvzMx6X9pu9pA/zH9BsG2dB4bg3jlsbSlr74R1L46j9J4c9/X0r/98thvQUdrPF+pr6O KTvQL+Vr3iNt994p2Y/+Qgg62NP/FtCwYIOlrT71hGQ+/B7J332HVD98VQg6hFcaaVDCghE2P/gf X5XC539Hiv/+z1L6098PgQHb38oSelno8coabGj7/nek8JufCEEH29fSeC8O2bo51LV4/906fadE L78Yjm9ltR4NltaCDblfvUaKt9woZZ3mtQxmYYOV1cpd+n+/IO1f+bIs/+ZX5dk//h05//zz5ZKl Bbn5wSf1FVSzJKevfCp/7BelTeuT+/gHpP/+H2ke86V35uly3HHHyYc+9CHZ9fiTUvzIe0IAxOrA gAACCCCAAAIIIIBAKwr4fUm97hZosJEBAQQQQAABFSDgwK8BAgggMEEF/ELepv4kvU0HzzpXsps3 1oMOFgywwMOANrgXf0Mb7ufNl21vfZe03XGTDHz6I5LXi38LJFjj/KD2Nij+25ek7w1vlMHTzpTC F/5ABnTZAgRz9VVMIdjwofdIcfVjsvmqqyXWRn0LOpQfWxWOYcep6LaMBiT0U8qy/YMfk9yTj0lF 97GeDvY6Istr4GtfkeKf/q4MnPwa2X3plVL8j3+Rwc//Xgg6WFAh9GzQwEjxlhtkx9veLaUFi0LQ YeCm60MAxNJYz4bqB98h2Y2vyFY9TnbHdhENOlRfWh8CCRa0KN/9Q8n+6oekokGDHe9+vxQ1YDD4 qatD0MHqbGkG/urPpPilv5XeCy6WbcculRXX/qs880e/LRdccIFc/dZLJKffrHj57ZdLcdWDcuOy k2SXvZP2lz8oG2/5QejVcM0118jOVY9I96/8okipLINap3SvkQn660OxEEAAAQQQQAABBBA4IgKZ WK+XdfQh1vsNGxkQQAABBBAwgdwf6wAFAgggMBkErOHdBmt0L2uj8Ivb+sPyopmdUsxnwxPv9uS7 PR3fTIPX217hY/ODM2ZJ6aRTpPN7/ynRzTdIfNmbpPTjezTY8Ekpz1sg6/7wv0vvuReFiHLPjd+W wTWrJX/FW2Twi38s7V/7suzWYMOWX/892X3hJdL+1OPS/l//IQPdPZJfcXzo2VDUAMKGT/2mbH3j 26T3zHNl2o9ulex3/1Mq514o8bYtkv3IVfoEU1Ze+bP/JX3aiF9dcIxM0bJU7rlLsle+TQa+9R/S /me/r8GG0+SVP/xL2aPHyWtPhc7vXiuDr26T3IWvl9JnPiHtt35ftr/7A7L5Ax+V3vMvlu6HfyxF LUtp+fGS7Z4qkQYXchs3yCu/86ey65I3ysApr5Gp2nMj/oGOWofqoz+V/Kc/LNWZs2XDn/9NqHNU 0G9H3PBfMqgBkryVRXs2dPzLP8juiy6Rl37td6TvkstF9JVJi7T3xjObt8i0154vm971s3LMK+vl 68e/Rm5btEIenTVfzt6sPSluvl62HXeilHr3SM+v/ZLkqhXZ/MW/lcwJK8PvmL3KyXta2O+bzTfD 4L9vjX9ni2clf2f299WMf2fNcO6oAwIIIIAAAgggcCQE6vch+gpSGdwtHWvv0NeR7pZsZUAfUGqT /gWni3RMldyMxZLV63HrVc314pE4E+SJAAIITA6BjDYspL/4MzlKTSkRQKAlBfxC197v3zdYkXuf 3hYcLjh+pnS15esXtvaqnWYY/D/P3rthYGAgfDugv78/TDP33yPzPv9bUp02Q3LakF+aO1/W/sFf SGVqT6i+XeTP/c9/k7nf+pqUFi6Sor6OaOfFl8krn/pseALJ8s/o0/1L/uIPpfPxVVLWwEFhw8vy 4i//P/Lqz1xab0Bvf+VFOfbzvy3ZKPneQazBhhc+9z9kz/xjwnHMu+dHt8mCv/kLDXgs1Dxekv6V p8q63/pTibWHgZVD/7GRBf/41zJNe114Wbb8/FWy6aoPhQCSZVTs65Wln/ustOn+FQ0i5F7dKi/9 1udl5yl6A6OD5dO15glZ8ue/K9GUqZLdtTP0bFj/ub+SsgZh7PfDhtnf+abM/Zq+xqlW5x3nvU7W /8pnxbZanWN1XP4/Py/TnnhUdul+3Xqc76w4Vb4/b0nY33qMLM4X5YO3XCttlbLExTbJ6PSlP/lr qaw4IfSusGCDvaLKGt+t54gNVr5mGPb6O1uT/J1deOKs8HfWGGhphjpTBwQQQAABBBBAAIG9Bfx+ pKSvH7VrxF27dons3CA9N/+B5Ho3SnFgh1SL3fLqWXpNP3W+FFdcKLmOKeE7cXad3Cz3ZXvLsAYB BBBAYCwBejiMpcM2BBCYUAJ+wdv45HWr9HCw1/iYgQVczGCPNpb3H3eS9NxyvZQ12PDc739RKj3T hp2zPn39T1YbwqfqNxB2vk6DDdbwbo3uOtoQ5/LhVUOd2guifd2z8sonPhOCDbbNG9Ar2vuh98xz ZNrdt9taef6P/lIGj1lSDxRY2oHFy6Qyf6FMu/37suekU2X97/6Z3ny02aYw2NH6XnuBFLSnQ9ej P5Gt7/gF2fjeq5NttbJIe4fsPO9npFt7IBT0dUrrP/s52f2as4Ydp6SBiEENQEy79QapaP0t2DCo ARerj9epX48f61NVPdqLYef5F4dgQ6w3PL49Uo/t51wkXS+slanPr5UXP/QpKV7zcTnjjDPkrLPO kpUrV8rCE0+Q3WefJzPu014b5ZKs/b0vSNl6Xmg+9k0Im/qTW34j5V6hUpP4R92poScRPRwm8Uml 6AgggAACCCCAwCEI+AMpg9rDIR7olY7ntIdDSXs4lPv1urtd+ufpA0Lt2sNhpvZw0Ad37IEcuza2 a2YGBBBAAIHWE6CHQ+udc2qMwKQV8AvdVunh4CcqXW+b7+vrC08Y7d69OzTGF7QBf1B7FlSnzwi7 NDZ8W3Bi6gP3SK82+OtV/15PGlme1tOh64lHpPeMc/a6MfAG6MKLz1sXASlrcMEGv4Hw7Tadsuoh 6TvxlNCzwRviQ2L9YcfRAkv3g/fKrnMurO/v5bVy2pDRbzW063ca+vUVSjZ4Pn4cS9f59Gopz54b gg5ejpBYf4Tj6LRb67xLXwmV0d4INth+loePkfZ0mPrEKtmldbbB8/Hj2LRt0wYpaMBhcNmK8KSW Pd0/derU8C2Kjo6OsI+ts8HrERYm8Q/zs7rX/87o4TCJzyZFRwABBBBAAAEEDl7Ar4u9h8POnTsl 3vGKzLol6eGQHdgpUXuP9nD4sMQ9C6Sw/DzJtXeFnsB2bezX8QdfAvZEAAEEEJiMAkkryWQsOWVG AAEEWkzALtpHGvtXnhYaiL3B3Kd+g2BT+6aDN4j7ducLDf3au2C3Nc7rSt/u6T0QUNJeDTbkak8q eTo/jqXrO+O1IU06n7BCf4R89PVLoSy67Pv7cTxdVXtp7NFxtOPY8fpPODmxSOXj+3t5ejWokS6H Hce2WTlsGmtPBftGhfUAscHL4/vbtKKvmarqdktjN0yWxvJpLLMfmykCCCCAAAIIIIAAAs0k4NfG Vqcwr5fOdvUcrqCTy+hmqi51QQABBBA4DAIEHA4DIlkggAACR1LAG8LtyXObt1f62Ly9Yskaz+3V Pnbxbw3i1hDujeL+pLo3sPt6T2f72OjbbZre39LZds/Hpjb4/j717Z6PH8enlmc6n9GO4/tbvUY6 jm/3qaWxvL0cIx0nnY9tt8HKa3nYE/xWLltvo5fX0riLzfs269Fgx7Iu4jZNH9fSMSCAAAIIIIAA Aggg0GwCfg1t9fL5SL/tltHRG5Qyem2sF8fNVnXqgwACCCBwkAL+78NB7s5uCCCAAAJHS8Abvq1h 3BrELdDgQQArgzeYp1/x4w39tt32t9H2s8G22eDfhrD9bfCGdJv6YGn9BsOP4/n4eg8UeD7pcqTz 8e2Nx/FyeNrG41iQwAY/jqdrLIett/L6cTwfr4+V17b7aMs2enl8fw+k2HrLw0df9uMzRQABBBBA AAEEEECgWQXsmtkHm08e4bF1yXq9jA5ztmTzDAgggAACCBBw4HcAAQQQmOAC3qBvDfh+wR8u9vWK 3qa+Lt1wblXyngA+TW+3ed/XG9ZtH1vvDfQ2tcG37+9xbB/Lxxvw/VjpfA7mOKOVt/E4Xl+bpo/j 5fB8PHBh623w+no9fWrbbbSeDZbGzoMt23EZEEAAAQQQQAABBBBoNQG7S/DPQYcQhD0XpKOHI1rN g/oigAACCAwXIOAw3IMlBBBAYEILeOO3FdIDENawboM3mHtDuKW1wRr6bfBl73ngDephY+qH7+/5 +ab9PY6n9+P4cX29H/dAj+P7eT4+bTyOBxK8/H4cL4cHJHzZ8rV5T+/H8amns3xs3kc/PlMEEEAA AQQQQAABBFpFwK+Rrb7JvPZtsPuOcO+R9HpoFQvqiQACCCAwsgABh5FdWIsAAghMOAFvEPdXCHlD emMgwBvI/WbAt/t6z8cr6Pl5et/u6X295zPadk/n+Xo6X/bAgKfz7Qd6HC+v5+v7+3R/j9MYiPH9 PV8vpy+7d2O5fTtTBBBAAAEEEEAAAQSaWSBcH9srlmLrzpA89BTqm9Wevzra9XTjNXUze1A3BBBA AIGRBQg4jOzCWgQQQGDCC/jFfGMDuK/3Cvh2X27c7sujTX0/z6cxnW9vnHo6X+/Lo0093cEeZ7R8 G9ePdhxf71Pfb7RlX88UAQQQQAABBBBAAIFWEUh/piHM+8cbrIcDHRxa5deAeiKAAAJjChBwGJOH jQgggMDEE/CGcH/i3p/E9/WNJd7Xdm/g31e6Q91+uI/j9Wys9/4ex9ONlo/Xd7Ttvp4pAggggAAC CCCAAAKtJBDrBxtstCHEGOzbbzoSb2il3wLqigACCIwu4N/5GT0FWxBAAAEEEEAAAQQQQAABBBBA AAEEEAg9GTS0YK9Wqr1CKbxlKSym+z9AhQACCCDQqgL0cGjVM0+9EUCgaQQan/BvrNi+tnv6faU7 1O3NehyvF1MEEEAAAQQQQAABBJpeQKML2doYgg5W4Yw+y2ojAwIIIIAAAirAvwj8GiCAAAIIIIAA AggggAACCCCAAAII7FPAXptk/RhstHkbbOrzYQU/EEAAAQRaWoAeDi19+qk8AggggAACCCCAAAII IIAAAgggsH8CFmiIoqpkdPQnWLPZvMQ6Wo/offWK3r+jkAoBBBBAYDILEHCYzGePsiOAAAIIIIAA AggggAACCCCAAAJHSCAdQLD5WPs2xG3dEpf3SLlSkaio8xZwyOS02wPfcDhCp4FsEUAAgUklQMBh Up0uCosAAggggAACCCCAAAIIIIAAAggcHYHYvghdG0LAob1bti6/UmSgVz/hUBUpdEg8dYFkO3v0 Mw5JLwdPzxQBBBBAoDUFCDi05nmn1ggggAACCCCAAAIIIIAAAggggMCYAukeDtlsViINKlS7Zkmc 79RXK1UkU2iTXL5DMrkiPRzGlGQjAggg0DoCBBxa51xTUwQQQAABBBBAAAEEEEAAAQQQQOCABCzQ YEM+r69OauuUgXmnSlVfp1St6ncccjnp6p6ugYeCBh501GULUqQDFQd0MBIjgAACCEx6AQIOk/4U UgEEEEAAAQQQQAABBBBAAAEEEEDgyApY4CGnQQd7jVImF0k20tHWFYoh8GDzBBqO7DkgdwQQQGAy CBBwmAxniTIigAACCCCAAAIIIIAAAggggAACR1HAgwceSGhra5OC9mSw9ZEGG+z7DjZv66xng6ez KQMCCCCAQOsKEHBo3XNPzRFAAAEEEEAAAQQQQAABBBBAAIH9EvBAQni1kgYbLOhgAQdb9mCDByn2 K0MSIYAAAgg0pQABh6Y8rVQKAQQQQAABBBBAAAEEEEAAAQQQOHQBDzRYTtarwXoz2NQGCzD4aIEH Xxdm+IEAAggg0JICBBxa8rRTaQQQQAABBBBAAAEEEEAAAQQQQGD/BTyw4K9S8j3TAQlfxxQBBBBA oHUFCDi07rmn5ggggAACCCCAAAIIIIAAAggggMCYAv6aJOvZYMNoAQZPN2ZmbEQAAQQQaHoBAg5N f4qpIALNLxDZ+0PDO0Tto2XWrTfp3tv8NaeGCBx+gSiKQxd5m9rIgAACCCCAAAIIIIAAAggggAAC COyvAAGH/ZUiHQIITEgBaxDdU7IG0kgKhUrytE0m+XjZhCwwhUJgAguEd/GG4F0klUok/ZUk6JDN aiSPAQEEEEAAAQQQQAABFaAnA78GCCCAAAJjCRBwGEuHbQggMHEF9MHrXK0RdLCkAQb9n7aN6sVv JNlaV9+JW/jWKpk1Yuv/pVyN9Ctztbpr+3Uhl631SKExeyL9RkTVaujhUNXzFf629PSEPzU/dxOp sJQFAQQQQAABBBBA4OgLRJXaMWvX8dnkVUtHvyAcEQEEEEBgIgoQcJiIZ4UyIYDAPgWyWZEp7XkZ LEfy4qu7Q8Ahr4EGf9rGp/vMiARHXKCqvVDsafmN2/dIxYIOOliwaP6MLsnns6Exm/N1xE/Dfh0g 9HDQlDatVDTwoP9rL+alrWDBoeRVS/uVEYkQQAABBBBAAAEEmk9Ae5VLpNeIfdvCVDJ6U6bBhkzn 9DANy81Xa2qEAAIIIHCAAgQcDhCM5AggMDEErIG6Pa/9GvSp60qsjaGhWMkj2KN9xGxilLy1SuEN 2JE2XJfLFSnVAg5F7d1Q1RuWfKznUIMP9u0NhvEXsL+rKLKgUKyvJ8voz4wUspG02d8aJ2n8TxAl QAABBBBAAAEExlEg1mCDVEoiuzbqdFC7l2uTUr4ocbFTp22S0Wt8BgQQQAABBAg48DuAAAKTTsAa Pq3B+tjZHclHbWsNoR5ooGF0YpxSa7gOr1Iql2WP3o9sDQ9CJT0citqYvXRGXjrbcvpqpXxo3Pbz NzFK37qlqAeJQuBBQw86teCD/c3xt9W6vxfUHAEEEEAAAQRaVyBc11uwYWCXyM4Nkr3+jyTTu1lB 9AGV7jkSvfXzIj3zRdp79GGiXPJdvdblouYIIIBAywsQcGj5XwEAEJh8AtboGRpA9XU8NlgDabIu WaZRdGKcU2uvto96ZyUn9lolbbm2W5JQOJsWc0kjtr2ux84nAYeJcd6GAg7+t5VcKtg54m9rYpwj SoEAAggggAACCIyHQFzVbzdYD4feLdrLYVO9CJGt0230b6iTMIMAAgi0tAABh5Y+/VQegcklkG7s 9HkPNlhNqvqxW1vv2yZX7ZqntEMN1lEIOJRKJRkYKIXvN5T1uwA25LXxenBwUPL6kW+bj/XVSr4f 5298fxfsPPjflZ2L9LyVjL+x8T0/HB0BBBBAAAEEEDhaAn59bvdZFmwoDwxoL4cB6bRuzLXB0lT1 e22iY1TRoIN+P9qv533qaZkigAACCLSGAAGH1jjP1BKBphFIX7Tm9CPRdoGbvHN+6MK2aSrbJBXx GxWb+ryfM6tiso6POEyk0934d5ZeTs9PpDJTFgQQQAABBBBAAIEjI2DX6+H6PenCnDyQkjpUuJ7X NLqhfr2f2swsAggggECLCRBwaLETTnURmMwC3tCZz+eTi9za09feiD2Z69ZMZffzUdEnnPSlSuFV SeF1SbWbEKurhRfsfNpogaOcfh/AzmvYpusYJo5A+jz5/MQpHSVBAAEEEEAAAQQQOFICfl1vUws4 lMvaw0HHdruuTw17tOeydl+Wzs4k4OD72bUjAwIIIIBA6wkQcGi9c06NEWgKgfTFqzVm+0VtU1Su SSoxUuN0+rx5NT2db/Opb2c6fgJ2Lvxvi/MyfueBIyOAAAIIIIAAAuMlMHQtqG9N0geKMuE1tkOl Cdutc4N+s83T2pRrxyEj5hBAAIFWEyDg0GpnnPoiMIkF/KLVPy5cKBRCbdIXtpO4ek1TdD8fVqGM fqPBejBks/p9Df1WQ+jaYOt1PqsveM3l8qFnAz0cJt7p97+30aYTr8SUCAEEEEAAAQQQQOBICFjv BvuOg0Ycwpi+3rfjVeNIgw02DgUdjkQ5yBMBBBBAYHIIEHCYHOeJUiKAwBgC3iA6RhI2jYOAnZf0 2FiE9DaftzQ2zzD+ApyH8T8HlAABBBBAAAEEEJhIAhZU0K4Mw4qUfrtSen5YIhYQQAABBFpKgIBD S51uKotAcwh4Q6hPm6NWzVMLf+Ipmfo3GqyXQzaMVlObT77dYL0ckm842NQGzmtg4AcCCCCAAAII IIAAAhNCwK7rrZeDBxz8et8LF8X2Gs7kVZy2za7nuaZ3HaYIIIBA6wkQcGi9c06NEUAAAQQQQAAB BBBAAAEEEEAAgf0WsD7IIdBgAYXUXhZYsD4P9hlpggwpGGYRQACBFhbItnDdqToCCCCAAAIIIIAA AggggAACCCCAwP4IRPodBxv3GqxpKUvPhr1cWIEAAgi0pgABh9Y879QaAQQQQAABBBBAAAEEEEAA AQQQOCQB69ngQ3re1zFFAAEEEGg9AQIOrXfOqTECCCCAAAIIIIAAAggggAACCCCwXwL2KqXkdUp7 fzTaMoizuTDuV2YkQgABBBBoegG+4dD0p5gKIoAAAggggAACCCCAAAIIIIAAAgcvkHwM2r7TUPuW Qyqr8O0G28CAAAIIIICAChBw4NcAAQQQQAABBBBAAAEEEEAAAQQQQGBUgfDR6Eh7OOjYGFqI4oz2 gGhcO2pWbEAAAQQQaHIBXqnU5CeY6iGAAAIIIIAAAggggAACCCCAAAKHJBAiDvqVBn29UjriEHo3 1DJOzx/SsdgZAQQQQGBSCxBwmNSnj8IjgAACCCCAAAIIIIAAAggggAACR0EgqmoPBx19yGiTko21 wQIOBB1cgykCCCDQugJD/zK0rgE1RwABBBBAAAEEEEAAAQQQQAABBBAYS8B6N9jIgAACCCCAwBgC fMNhDBw2IYAAAggggAACCCCAAAIIIIAAAi0voIGGTE57MOjoQYc4mxMbQ68GPhrd8r8iACCAAAIu QA8Hl2CKAAIIIIAAAggggAACCCCAAAIIIDCyQKqHQywagKj9z+YZEEAAAQQQcAECDi7BFAEEEEAA AQQQQAABBBBAAAEEEEAgCMQaYEiP4fsN9W84ZEKYIQk12BelGRBAAAEEEEgECDjwm4AAAggggAAC CCCAAAIIIIAAAgggMLZAqoeDhRgs2GAj4Yax2diKAAIItJoAAYdWO+PUFwEEEEAAAQQQQAABBBBA AAEEEDhQgVTAwXaNM9kwHmg2pEcAAQQQaG4BAg7NfX6pHQIIIIAAAggggAACCCCAAAIIIHBoAhZs sK4MoWtD8iIl7+FwaBmzNwIIIIBAswnkm61C1AcBBBBAAAEEEEAAAQQQQAABBBBA4PAKZKJIbLTB gg25bE5ExyT8EFbzAwEEEEAAAaGHA78ECCCAAAIIIIAAAggggAACCCCAAAKjC2RSX2rweZv6/Oh7 sgUBBBBAoMUE6OHQYiec6iKAAAIIIIAAAggggAACCCCAAAL7KxDr65TiOJK4WhaxsdanIYpisTFD 4GF/KUmHAAIItIQAPRxa4jRTSQQQQAABBBBAAAEEEEAAAQQQQOAgBdLvTdJ5CzLYKhtDwOEgs2U3 BBBAAIHmEyDg0HznlBohgAACCCCAAAIIIIAAAggggAACh1Vgr44MGf2Gg40MCCCAAAIIpAQIOKQw mEUAAQQQQAABBBBAAAEEEEAAAQQQGEFAX62k71YKG2qTveZH2ItVCCCAAAItJkDAocVOONVFAAEE EEAAAQQQQAABBBBAAAEEDlhAv+MgNtpg34vO5cJo8wwIIIAAAgi4AAEHl2CKAAIIIIAAAggggAAC CCCAAAIIIDCyQKqHg328wb7dEL7fkHR6GHkf1iKAAAIItJxAvuVqTIURQAABBBBAAAEEEEAAAQQQ QAABBPZLIK4FGmKx3g1R6NBggYZSFEtVx2w2K7F94IEBAQQQQAABFSDgwK8BAggggAACCCCAAAII IIAAAggggMCoAtaJIZMrSCZflHKxW7IadojauiUqTtFggy6lAg7p+VEzZAMCCCCAQNMKEHBo2lNL xRBAAAEEEEAAAQQQQAABBBBAAIFDE7AAQiZfkPKUBRLlpsjACT8ncXlQcm3tIm0acCh2STYVcLAe EQQdDs2cvRFAAIHJLEDAYTKfPcqOAAIIIIAAAggggAACCCCAAAIIHHEBfWVSsV2/GV2Vaucsiasl iQodkil2SF4/Hm2vVfKBYINLMEUAAQRaU4CAQ2ued2qNAAIIIIAAAggggAACCCCAAAIIjCrggYN8 Pp98ILpjur6Ye4qUFnRq4MG+55CRnG5rb+sSS5NrCDyMmjEbEEAAAQSaWoCAQ1OfXiqHAAIIIIAA AggggAACCCCAAAIIHLxAeKWSvjIpq69Vytn3GsoVEX1tkvVqCCOBhoPHZU8EEECgCQUIODThSaVK CCCAAAIIIIAAAggggAACCCCAwKEI1AMNGliw+Y6ODom0Z4P1ZrDvNFiwwdfbfL0nROp7DodyfPZF AAEEEJicAgQcJud5o9QIIIAAAggggAACCCCAAAIIIIDAERewoIIN9sokmy8UCiHgYPM2ek+HI14Q DoAAAgggMCkECDhMitNEIRFAAAEEEEAAAQQQQAABBBBAAIGjJ+CBBuu5YIMtW8+GYrEYlm3e1lkg wgYLPDAggAACCCBAwIHfAQQQQAABBBBAAAEEEEAAAQQQQACBMQUsuGCjvVbJBg8w2DoGBBBAAAEE XICAg0swRQABBBBAAAEEEEAAAQQQQAABBBAYJuABBe/J4FNP5Nt9mSkCCCCAQGsL0N+ttc8/tUcA AQQQQAABBBBAAAEEEEAAAQQQQAABBBBA4LAI0MPhsDCSCQIIIIAAAggggAACCCCAAAIIINC8AvRk aN5zS80QQACBwylAwOFwapIXAggggAACCCCAAAIIIIAAAggg0IwCcfLthjiqhtplMrWXZmSTj0Y3 Y5WpEwIIIIDAgQsQcDhwM/ZAAAEEEEAAAQQQQAABBBBAAAEEWkIgjmMRG8t7RKKKyECfLkcSF4r6 5WhtVmrv0WkufFC6JUCoJAIIIIDAmAIEHMbkYSMCCCCAAAIIIIAAAggggAACCCDQ4gLWu6GkAYfK oMjOjRp40F4O7VNE8m0iRZ3Sy6HFf0GoPgIIIDAkQMBhyII5BBBAAAEEEEAAAQQQQAABBBBAAAEV CD0bdBpF2pthcI9kn39Qgw0bRH7yTe3t0C8y61iRnvlSufjTkpkyS/L5pImJbz3w64MAAgi0tgAB h9Y+/9QeAQQQQAABBBBAAAEEEEAAAQQQGFUgeaVSJJEGHWRgt+R3b9HeDv1S7dBXKRXaLSJRD06M mgkbEEAAAQRaRoCAQ8ucaiqKAAIIIIAAAggggAACCCCAAAII7J+ABRpsrFarElf02w3lQclUSpLT dRnNIrLtGmyo2DYds9ls+I5DLsdHpPdPmFQIIIBAcwoQcGjO80qtEEAAAQQQQAABBBBAAAEEEEAA gUMWsKCDvVYpo6P3ZrCAg35GOoy2zdYzIIAAAgggYAIEHPg9QAABBBBAAAEEEEAAAQQQQAABBBAY JuA9HMrlskSlkmTLJcnoWLSeDZoy1u9GR5VYytq7IaOj9YSwXg422sC3HAIDPxBAAIGWEyDg0HKn nAojgAACCCCAAAIIIIAAAggggAAC+ycQAg8aYog0oJDRMbxPSXdN93AIvR/2LztSIYAAAgg0uQAB hyY/wVQPAQQQQAABBBBAAAEEEEAAAQQQOFABf5WS7RdHGl7Qng7Wk8HmwzccdL29SMl6NlggwntE WHoGBBBAAIHWFUj6ubVu/ak5AggggAACCCCAAAIIIIAAAggggMAoAhZIsP4MHlDIWLQh9G/Qn7Vt YU2YtzkGBBBAAIFWFqCHQyuffeqOAAIIIIAAAggggAACCCCAAAIIjCHggYYo1t4NOiZDRkMOuWQM 8Qj7wYAAAggggIAIPRz4LUAAAQQQQAABBBBAAAEEEEAAAQQQGFvAejDUejEkn41Okqfnx86ArQgg gAACrSBAwKEVzjJ1RAABBBBAAAEEEEAAAQQQQAABBA5CwHs4WANSuhEpo+9WspEBAQQQQACBtED6 34r0euYRQAABBBBAAAEEEEAAAQQQQAABBBAI32qw0IKN4bsN9gYlCzbYyNuU+A1BAAEEEEgJ8A2H FAazCCCAAAIIIIAAAggggAACCCCAQCsLJB+CTgILPm+BBvuGg+ho8/Yj1mCDjZksPR1a+feFuiOA AAKNAvRwaBRhGQEEEEAAAQQQQAABBBBAAAEEEEBgSMACC7qUBBts3j4anXRuSLYMJWUOAQQQQKC1 BQg4tPb5p/YIIIAAAggggAACCCCAAAIIIIDA2AL2segoSkadD29UkpyGHXK8UWlsObYigAACLSdA wKHlTjkVRgABBBBAAAEEEEAAAQQQQAABBA5AIHyrQcMMFniweR0s6GAjAwIIIIAAAmkBAg5pDeYR QAABBBBAAAEEEEAAAQQQQAABBOoC9h2HSHs36KcawujfdZCcNinZyIAAAggggEBKgH8ZUhjMIoAA AggggAACCCCAAAIIIIAAAggMF7A+DRZosDHp32AdHTKSzQ41K9kyAwIIIIAAAnkIEEAAAQQQQAAB BBBAAAEEEEAAAQQQGEsgjqpiow0WXKjqbLWiAQh/xZK9bokBAQQQQKDlBYZC0S1PAQACCCCAAAII IIAAAggggAACCCCAwL4ELLTgPRw8zOCBh33ty3YEEEAAgeYWoIdDc59faocAAggggAACCCCAAAII IIAAAggcskBGPxFtow/hdUqpVyr5eqYIIIAAAq0tQA+H1j7/1B4BBBBAAAEEEEAAAQQQQAABBBAY U8C/3eDfcrC4g4UeQvhhKAYxZh5sRAABBBBoDQECDq1xnqklAggggAACCCCAAAIIIIAAAgggcFAC yeegI903Sj4arSviXC6M9a9IH1TO7IQAAggg0GwCBBya7YxSHwQQQAABBBBAAAEEEEAAAQQQQOBw CiRdGzTKoN0ZdD6j//MeDjbPgAACCCCAgAsQcHAJpggggAACCCCAAAIIIIAAAggggAACwwTsdUrh lUqR9m7Q0QYLNmR01kb9enT4gLStZ0AAAQQQQICAA78DCCCAAAIIIIAAAggggAACCCCAAAL7EPA+ DbVkGmiwYAMDAggggAACaQECDmkN5hFAAAEEEEAAAQQQQAABBBBAAAEEhglYWMHDDR5iiLP6DQcd GRBAAAEEEEgL5NMLzE8Agepuidc/L7J9hxamKNLdI5kFy0W6OFUT4OxQBAQQQAABBBBAAAEEEEAA AQRaTiC8UklrHQIP9h0HBgQQQAABBEYRoBV7FJijvdr+8ZYHviTRl78wwqFPkMyff1cyM4ZOVybS f+Z5kGAEK1YhgAACCCCAAAIIIIAAAggggMBhF4ir2s1Bx/pgL80YenFGhm851GWYQQABBFpZYOhf hlZWmAh1f+zvRgk2WOHWiLzcG0oZ3/aHEn18uVQ/eaxUP/0rEu+aCIWnDAgggAACCCCAAAIIIIAA Aggg0DIC9u2G+juW/CVLLVN7KooAAgggMIYAAYcxcI7GpiiKJIo2SfWf/7rhcMdJfOxF9XWRzlUq OyS++d/r62TgRonWbdP9bSsDAggggAACCCCAAAIIIIAAAgggcHgF7I0M4a0MkfZusLE2xBZzINbg HEwRQAABBGoCQ+/ogWT8BNbdLpmB1OHb3iuDv/e7Uu3UtyblypLdMSiZmV2SifskbkvemVhPPdnO 4KtrJH7sCYnLWo8ZJ0vmzBPqVWEGAQQQQAABBBBAAAEEEEAAAQQmnoDFFTzwkMzrCuvl4D0dJl6R KRECCCCAwDgJTLbm6nFiOvyH9V4J5XJZ4v4dUkgdovyzV8kuDS6I/j+bzUq2WJDioAYd9B/y4nSR /OahxFE+L3GlInmd2mDpJ+IQnobQgsU3/brEP9RXRNm86Lcp/upGyXTZNQqPRQQUfiCAAAIIIIAA AggggAACCCAwwQTsnj6bzYQx3N/rPXwml09Gm+eefoKdMYqDAAIIjJ8AAYfxs0+6JNrxt6QiCLpY ndKhr0+qDPsH2wIUmUxWBj9yt1ReWC/ZknZjnLZUMgvbtOeDvThxkgzFeVrQJOAgMmWSFJpiIoAA AggggAACCCCAAAIIINDCAvpwY5TVVy7k2qXS1qNPDepyvl2inK6boA8+tvDZouoIIIDAuAoQcBgn fgsg2FMBpVJJsusfSfVwmCH9uYrs2bMnBBza29vrvRbsiYE41lM299iwzZbbTFGavgAAQABJREFU tIdE6AWh/8Dbsj9V4NNxql79sN6zoVpN3vMYVSPJDW3V1z9WtIeG9tqo9dCYKOWuF5EZBBBAAAEE EEAAAQQQQAABBFpYwNoc4kKH7F54jkQDvZKdcWL4XnRm+iLJtndLId9Wb7doYSaqjgACCCBQE5h8 AYfB3SKD+gGAXIdIV/vBnciqfjChr7+2r77MyPLRroCHPHjZLHzQpU/vD7Wsj5i1NcbbWM3pxxrq w1IZnKZPCmhAIvyjXkvjaT1Z43ZfP+p0UOusvSa0aV9Egxj7Ktuo+RzkBi+/VmfYEGX0g9cH+5Up 9z6U34VhpTmIBS+D7Tqe5TiIorMLAodTwP7GK/bnrH/jFQ0khgBoFOt/yxr+6P2gqbeoRbZTVffX 6KPlk88VdH/9r5W+IY4gpIMxRQABBBBAAAEEEEBgfATCNXk2J3H7VIkyObEHCsP1vi5LW5dk7dVK dgHPgAACCCCAgAochlb2I+tojU+y+XGJb/6mxA/9u0j648oyV2TFWyTzxvdK5tTloSCj/SMXV16V +O5vSXz7f4ls8lf6pMo+90rJnP9O+f/Z+w4Auaqq/9/0me276YUkhF6jiIBYQCyIIiIWUFHRzwI2 ig35RAU/pVgQ26cCIir+UbDAp1IEESmigkY6JKSShPTtO/39z+++OTNvJrvJJtnNzm7OTd7e9245 99zfLe/NOffcG3rlK+WFuaWQy/Gx5g4UL/uSCOwlX8tbEf7seSJkFgHZP34B7zc/ADrXBgjK7Qs+ h9Dbz5DDkSsvX0dHooqP34Dwjb9DsiGByPK/BfL9C1OuuwCT46KtoMWCvNSdX0qh+d1j44uRfv/7 UIxTyFct1HPPfSvkzISfw/vrNTW4Se5px7h6BgoWRU4fQm/4GkJHzBmxjwVnyfGvqxG65QGEmjyE ltwXKPJfiFz+QXcQdlHMMZ1LHI7wuR+tKERqMb9AMO97GsX/PRdYHGjHpLTdxZcjJN87zq35vbTV V6Wt2uRRLELO+zpCU5ND1CuP4q8/Jzg9Juk7gZmfQOTsd5QIVXsO18wa6Y//D979N23Z5sn9gJd8 AKETThJeKu1eTcWeDIGJhQDHRU60Dc9t6EM6m0dXX06UBmHsPaMBMfGpdKido7gkimGME10DMvKj ZfGqXlFWFNHSGEMiFsGcKU2yWsq33ppYiFltDAFDwBAwBAwBQ8AQMAQMgfpHwCkVRC4RiYiyIZ6E 1zrLnSGZbZrlmI8nZEeGmCwWisbdgkmmG0omU/+1NQ4NAUPAEDAERgqB+lc43PVVeDeKwHxQJwL+ xdfA4zXtPIS/IILqwWq0VITPl35iUArlwLW3wvsdLznI+JPXI7RvRzmqfNO5QgT3UiaVHp1L4G18 Frj6tfAkeFC38BJ4C38MfPYOhOY3l5M4wdtjv0NovQjcy6GVm0jXwsrDVu/WI5zxFQ5bJFv0GxS/ 8ektgssBa+8p3wZvvE0DGPF1CYvuRGjdw6I4CpZUul9/X015/fDSH3UHSbsUtZiv/Ae8rwyiDEj/ WhRJXxBFUOlciM7nS21FJZAoJjZ+GRCFw+CuB/iH5Ge7urb9Kby+d1R4CGZ68gYUr/zvYEj1fVrK uvvT8OTCh6RuL5pZHW9PhsAERYAqz3QmjwG5+sQKjdYJmVzKKRU8T0wfhnBFicvlRWEhWofedEYU Dh7izCwEneXDEPks2BAwBAwBQ8AQMAQMAUPAEDAERh8BVTq4rZypdIgUEBYrB7pIQrZSEiUDFQ2M N2cIGAKGgCFgCBCBwcTzdYEMV8bjrs/Au0ksEobj1n4TxT8fj/Br9q5KXXz6OuCKi6vCtv7wNLxv HI7CeQsR2qeprJ13/ISDQjNRTnzh1q2TcrFr4V32cRS/9WNnUUBlg7+qt2dQZcMwCAaSNMlOULKK XlYQ60eAU2Zsul/qMIiyofUwkQD+yxeqB6hU3W7udeaR4c6H4F3/BznXeSghfVWu6ocsrQTE4uCN R7jDr1Hs3o6O1u3OdUDBV3t4IfmYKVMXzL8yNOZyKoZsy+KfFVGdT2SXPDOjtE1VmZzcOLykJWgl UlG0NMmqa6Ej//WjyaV78mp43740mN2/b91HSu5CqKtao+L96GUofORvYn0zpUxny8wWYgiMXwT8 8cNhV0AuV8D6nrQoDXLo6+eWSjJ+Qp1IiaXC9NbollsrSTzz0zJi9ZpODGQL2NCVdunSQqspGRML hwanuOAPGDpbLTV++4pxbggYAoaAIWAIGAKGgCEwfhDQ727d5jkej8t3un8OpfuGl7Mk6RjOtPSZ VuUSmn/81Ng4NQQMAUPAEBhJBOpW4YBNf9lS2dB6KnJnnInC7DaE+jcg/MSfEb35EoS4Kp1uzQb5 E1A4ZGSLnC2UDYehcNonkdtfhMQNUYR7nkfk4d8i+serHInyn29+Dfjfi8qPKlirCKXLUe7Ge9nX kD/mJSiGNyFy93cRve+OQIK/wrtXrCFeNb+02lf2Kj/+WyjMW450IYf4XWejoSyrbkP3qz6FbGtK tiSJIBqTF3jYPwzai8je5n++EIkVrOdQTs5puPEz1ZH7fwmZd52EotRXdlcX3H6F+DWXBgTsspL4 g79FsSmE8HTBT4SAWPtP4AnZwmpH3cI2eCe+2OUuvuYK9M9+DoWYnEtx1+fRuGpTiWoH0id+Cdnm MOJcGSEKnUhyNpCSrZe4XFocWRnKeYddgKJYooQW3YHwwwPwWsTMUz6C+HHDbVoqigqfgrZhkJ4f tmUhLjwYLH1pC2XD/hcg+7Y3o9heUspsfgbx689CeEm5MYHvf7eqHwXLtntDYKIgwPFCawSOOaoG ctzTVdRw6ayMSbFgKBbpy3imUrDkmIdhHKv9YhGRydHSoSB0RFEhESG5SNMfo5rLfEPAEDAEDAFD wBAwBAwBQ8AQ2JUIqPKAflQWPFLxoGFUMqiigTxp+K7kz8oyBAwBQ8AQqD8E6k7h4CwJBKfCby+v FhjP+AS6Pvou5OTlhoG0iK0aETroJMRecDwSt1yA5N8eQHHOVBRE015+yd36jWoaeCt6LvwUMjEK seTshX5JGxXlxVHvR3TPuWj73ucDLXQ9ivf+F7yjZY9CCr5YrgjD5DjoGrcX0h++Gn2z/a1DgCnA ay9CIpJD8z13V9Le+1dRSMxxz6SVi01Hfv/J6OrqQmLeYaJwEMsD5+aga+7+SLc2OLNEXTHAlzhd Ys78KoWDL7SrCOVyvf9GZOHaijIh8T50nX6C4JaB15t2K5Ex6w2InLoeU355jaPJP96yPPpFIRIX bMJyuHRh0LqWkw/jpoC8tEWOtJKz0LN3i6yAFrynzwkoHPZA57y9MZCKoqlJrDVEwZIQxUMok3H3 LKSQzaFhkNKyp96MnoOnubYOHfIKxE7lIbNiDZH1BZpeLl9lVVGUQ2yLJeuHcv8Qunnhz/OEL8lW GQwiIGV4ycqCxRfv/N8qixRvwdfQdeqxfv6eHr/PxWYi/P4b0XjVW5BYrkoh6Uf//hjwQukX4rQd 3YP9MQTGOQKqDOCcJic1YIqcW5ISxeLmHs8pENaJxQLPYmhJUlXrn9dQyeOhZyAr4SE835mR9DJn yNZK8WgI01rjaErJKimhSdqaJzh2xzl0xr4hYAgYAoaAIWAIGAKGgCFQ9wjo93dMzmmg09+z+n2u z2qRrM91XzFj0BAwBAwBQ2BUEajIWEe1mO0j7qX/hdBDzwQyLUDfu9+BrAiMuXUHHV98vHK5BApv uALF14nQuKkFMVEO+G4lwrf9tXTve+mPnIt0lFvryCGlJTqMIR1v6nHoOv4EtN5e2bIndOddKBx1 usvshF5ymGm1wmE++j/2E/RNkdW7JXpKt/DyM9AgCgd/IxAhkel2q++lMEeP6Xi5F3VOeWbUAIoi eGM4y2QavrR5TxevSisiPCeME/5LK4H1xe8Sy5/8iW9yuFGwTqdl5vc6DllcA9lJyLlQ12YnPOeK BdKITH8lCseJdYVYWNCVYXVPW/4pVUsipH45ESJOe6lbyxysp+Otiv9+SSt1jPtYsB20vq5NHAZB bPxy86+8Dp0HTGZlyv2AGPEq15/LpAOO7UMM9UOIUZrW+VXJSwomT3FfgvDvbw9QezV63/gyp0Bh Xl7aPtFoDD0nfwKJK79QTh96eCG8F7za8VoOtBtDYIIgoOOI1aGyIMED7zlh8GyGAhWlBWRFAcgg 32LBrzifqWTg3JGVeYBnNzCPHEknSoqwHDbtz81MzTI4J5gzBAwBQ8AQMAQMAUPAEDAEDIGxQ0AV CvobwL7Rx64trGRDwBAwBOoZgbpROOgLi6vgvSX/qBbszz4J670eFGXVrKbji40XNe3upZdMygHK GRfGcG/RXShtdOPj3/5xbGxJI93t7zVY2yiO3j6vQpMoHMpKgnV/gdd9GgqyxD4jtD3Z9iNIM33C V/B8UoTmcuaw8qV+ONyMxjY5AkGOM3Cu668odr4fOaHFNCqIJ92oKDIqToTXIhxnOIXjSo/xvI/I gawVR0E9rREkXNKyDjkR7JF/Fc1l4iH09fW58pifgnG//CLaRXsSL8Hh5dIYGBhwpEkrnJgLHD/X pWV6VVjwPuhYZtCxPRyWDJc6BOvJto1VKQJk/3ZJk4lGXDsyLfOyPXnPsrIDGTQFC5jycTz3QrFk KVkVaPszreblfaEmXzGXQTabLadhWqYjzoVCGnFpgooySVZaM1yEnlTAhNb+G4kAD8UFJ2FTrg+e WFOoooG06Fzd44egUc4cT+nOUYsekzY6lpGunpqOvjlDYCIg4MafqBibE7INHH2ZKHnuc/eAbJUk OuLnNvpzd8GNf3+s5GUuem6DHFIv4yItlkySDc2pCMSwQeiEkJJLRqkbpxMBI6uDIWAIGAKGgCFg CBgChoAhMN4Q4Lc6Xa1fWw+Nrw23Z0PAEDAEDIHdE4G6UTgQfhXayqYaVa2RXnCArH71LRucYEte evpC43PwogCYcZ6XqaKRO+hgt9JfywhGKk3E90S6EWjs09heZ0EgJH1BfZWwXBbnJ6JOMO6XVxE4 k16hkETf3ANE4fCkEisJ+31BdzlwiBvSUGE2k1AAT8cVwhUndRfmikWeWeArLYpZrhCuuNjq9SjM nF3GiOnc1b8MiSrdS0UZwXjF199yqBJXi5+mY4m8Z3r6FNTTkRbz6OUCy3+CdfEDNZ363N896HqP fpkIMH2rj2DZTM/nYHnBfNwYnmmCLvjso6exiqvPf2jzRo1wfkiwS62kQqUCoCPNP+x7kQFRfgWy xGOOr5AoUswZAhMRAY49KgrDsjcZr6SYJ3Dsuq3rZFjQkoHDww/zESiKRUNGDoyWrKJk5fiVLeNE S8G8ERkqvEgzOM4nInZWJ0PAEDAEDAFDwBAwBAwBQ8AQMAQMAUPAEDAEJhICdaNwUEExV8Fj5aIq jHMxf5sfCp54poGzaJAUfNaV/ZpBBfPeyuUa5Pz09ElOGK4CLN2DUAXqvh/FwCw5Y+CZFaW8YkEg e4xnBSWujhcCVTS9LC0HxLJChGJBATsTsR75UNAeQrYMka2GPM9XppB3XswXqRJEi+BOLAyStNiQ cNaPjmkdRu5J/4hiQ3iiLsLhJsFZEdzxzAO10ojfcy0aD/o8+hv87YaUTtN9PwucWSACv+aUU2qo ZYH6pMtyFSfeBx3p0Wk7sD7B9tG0io+fWkNFQCn1YxzbgzTUQkLL5VYsQVfMDUhd4+V+wLL0Ii+q qMiKgDPoink5T0LqwjMiVNFAn/UpiIVJuEoX4bdVNlvCTM77SAWIhRZ9E1Oru2ggdpDbYtbve1I/ 4ko+tV0HSW1BhsC4QUDHvzLMfp2QKW5GR1IOgs5jU6/Mn6JU6B2g4lHmGdkyiT6dJ5NBX9rp6NyY jImGYZbkaxBFbiIu86LQUsdyasvSOPMNAUPAEDAEDAFDwBAwBAwBQ2DXIGDf5LsGZyvFEDAEDIHx jkDdKBwUSAqAQxuD5zeIQEoO9aVToRN9FUbR13ClQUFyaPNifXR+WLYeomNaCqjp01HYrQJ1iunz FRmXxIqFQzqLYqOfxqva+oi5K1JqpanCbD5XO3/VPMNYdjBdtRCeq3ordVJBvcNF8lWnlfJLQnMt qxDZB90vOwLt9/2jFHQ/pn//PPS+4Ux07zEdXtdyNP/9WrQsCWK8HzYdvIeSKPmy1dO69dRkOCuK iOBHnnn+RZUr4RgOkzdpF7fFlfitM1FoSZXbRttIcVcaESpcpA310nSMV4w0bdDXdMwXVDiUFU4q 1Sxn4mpr/2KQ0taw6uSVdKQXe0KxLBPbvpte2Y5L+nWxhNX2ZbbUhkB9IxAc0/5Y9MRSgdZOsoWY KBEKogTNleaN4DjjvbPYEj8WEWWyWDdExY9JXiphg3NosIz6RsO4MwQMAUPAEDAEDAFDwBAwBCYw AsXSgkD9sBfZhXOhWvnHBMbAqmYIGAKGgCGwTQTGXOGggl8K1FXwH5G98YPOK4bdinYKl1OplBNE URBPIRTzq/C5IjyWles1yoGirOenAKuxsdH5upKeK/dVmO9Wn+uL0zHQgHzMP7/ACbKr4kRxIPS4 Yp680Fd+mLa/v1+EZkH1gFgjiPBebBccZaZnubSciHKz87KTw1Jp3dDQ4ITwaolB3kk3XCO01i2V HH9Cw1kipKqtEIAn0fSHs6vPQiiXJ8dUv1wO026OiaDPtzRgWaEl16Hlqh8EUm3v7fvRf/nHURDM SI/1Zft53Cel7ETAGE+INUfUWXSo0oHRWp9y0tJNSHiklUtTU5Ojp5YgKpBMp2XJ9BBO02g0+wvb gGVVzm/wY4vSL3JykK3jeeY+EvigZkNh7nvQPX8ywgXfGkUa3ilbPFm9zTb26YolAxUw4Rjy+71C zukoICrpWB7xYBq6Wp7KhdiNITAOEND+y3Gic1Q04qEpKRZLMv1NbomJpUMY67rS4JTM/l/rOCV0 NNKyIYLWVFTObojJnOgrIXWe13Jq89qzIWAIGAKGgCFgCBgChoAhYAiMPgLu92tRdhHok+2GReng ye4N7ndwQ6usmBSxUlz2WRClg323j35bWAmGgCFgCIwHBMZc4VALkhMAz3kB8PdHylFhebHxxcWL AigKtnhpmCbkS5DCY/qZPY4QGfFjGoVYb7/kaXH5KBwjHXXM4wuBe5Fas1KDxeeKfv+MhEBg5VZe qMqLCsZUUD7Ui5a8+WX5AmdfUBdUTEg9pW4M14sF8t65YFI/pPzXfQT0PoQpf3qoHLb1m3b0HHMx Vh4yA02CLZ3iKrupbz3rtmIT/iEGpKdCdndfk491ZbiWy3q6etSk00fFhukVH2LNZ+ar7ROaj3FB YefWytA89JmukKo6thq5mS/B+gVzXPmquGK5pE+FB31u38QwKkTYN9qEznDLDJZv94bAeEKA45CO Fk8R0SSkZGskntsQciueOOfx0knMv3fjRA5oZ1rm8fP6CgzSMmcIGAKGgCFgCBgChoAhYAgYAnWA gEeFw2ZZ5Si/9TM98lkvMgp+2kdFdhCTTYj1M78OWDUWDAFDwBAwBMYWgYrUfWz5cEJaVRYUGqoF vA2LFqHnRXOd4Jar24OCZrJNQS4vCnpV4J8PVVctuehpJI6YU7aUIB0Kupie+WgZkO9fi1RXEIgZ yIUlXLYGoWP6oAtFfMsGCpTVwoH0ePl8BlfzB3P696Tnrqo3M1fNi1KldKYB6Tiht9BkWq/KaqLC j2IQW3RP+fwG4ChsOPXdCK35F5pXLEJkYEAKlrMaOmajf9YCdO57EDKytD8mQkLWgZcK/kOJ5i0Z 3p6QybPLihPyRksO8k+BYsXJs9QzJmd0UHBfVqpIAt6zXWpdOJZwWKsgX9uR6ZheFQ+1+SCYDu22 jPMVTb6lRShdfR5E7PmV0sazXLuQT9aLTtuAvmtXtlepb6o/NA8WYwiMXwR03Ol4cIo4mVdmthfQ l4lgfXcGaRkLGQ5p8ek4bGgFwYOiZ07yz25IJcViTOYI0iFNnY9cBvtjCBgChoAhYAgYAoaAIWAI GAK7FAH+jqWjvITKhvBD1wNdaxBZ9ww8UTQUF5wCtM6At+8rEUo0ue93ptffyLw3ZwgYAoaAIbD7 IbClpHUMMNCXGIum0NiLN1ZxEXrmT0gWX4OCE1j7gigV6DIh7ws9oilINpRfbIWmKVVrabHsd2hI vxbhlsqKeualYIuOgq3EE3+o3lpnxgKkS4YFLlHNn1BJ2MzyVTBG/ivP1RmC9WQaOuf7t+XEDKu9 NFJi9HZQP/r8kkp4wzx0TZ+Lwox56Ds66Wiq4DuTkXMF5ONBywkK9xjmzXkLei47xSkKmI5KFM1b KaByp/VXQaEqYDSFluN/rpRDy7XReI2hz7Bax5XSQV61XFVODJaHNOKLlgJ7i+WMONZDHe8jj/8C zZ0aUvE1XX76fqDKQbtCZOmf0JQ/En2y3ZamYS7es3zyVN0PKu1ZoW53hsDEQiA49jgPcDzE43Iu jvg8oyEvV1Z+p1RGnyg75byGOK9YxF08u0HnZKITpDmx0LLaGAKGgCFgCBgChoAhYAgYAuMHAfe7 l7Kafvnh3LcJ6FmPkCgcCmmxdEjKThKMk+9+c4aAIWAIGAKGABEILjcfM0RqhUqF6a9Ar2wBWHEP oPX3D1QJn1SwHQ7Lqva7L0P0/Bcj/n9PupccX3SFSYejt61CAXgcrb+5TVbP+lsVBYXWLD/U9U+0 //7mYAb0HP0Sd6jp0C9Of4snWgaQH734vKWTl6/wRVq8XJksl1dVYnkqCa2Vx6AvUYM6pecFDyPo vwHzbvgx2p5+BLElTyK6YjHCq55DeMPziPV1I5aXky2EV65G1jqwLNIijxSaU9HA1QzcIogXLRWC F8MYr2Fq4cEw3qtT/sIFWlmoexLJld2uPA3RdPpc64dKq5/JM68gNso7aRQjVR0I4b/dgHimWkFA 2pHHrkHHr66qLabcTi4itT86pwWT/BMz7v53OY22J8vXPkCFC6+UmJnSGqPSX21fyyCSdj8xENBx G5xPOD4TMr+kxIJpRnsK09tkezEZv+W0cj+1JYFprQk0yHZKSWfp5Fta6ZykaScGSlYLQ8AQMAQM AUPAEDAEDAFDYHwhUCsT8PI52QZAznBQ2YZsn8rzM/X3P9MzzpwhYAgYAobA7o3AYJLxXY5I8IXk 37di04tfh6Z7bivzElr4GbRlPofi208GJrXIS04OB17xILzrPgCs9ZN5zf6BzP5TIzYdcyqab/5l hcbSS5D6Xjdy73wHMGOKH17oRfg/v0XHT75aLfhveC/Wz26Qo6a3vsq2ViDGZzoXXk3RhY/2n8z+ x8n5F4+Xi4ms/Q2m3vqb8vMWN/EDkT34FKRPfCM82UddXfkDQj8kAr6mUZ9pKWyn4wdG0AXbluHZ GfsBC58oJ0n89ipk534KaM4j9NyjCC8bQPElLynHb3njK2m2DK8OKc58MQbisoGUnGXlu3vQ8u1v I/fxs+FNbUFo4HlE/ngZWu69QxNsxU9gw1HvwaSbf1pOE33qS9gv81Gse+3rkG6VQ75L9XcKh+7V aFh0L1ofvBrRvkPQc/4PEW72LTPKBOzGEJjACOh44HkMVDKk5EDoohyqHpVxUpQzefgTJCxzZSoR RoMcGh+RdHZ2wwTuEFY1Q8AQMAQMAUPAEDAEDIFxjYD7nS+/9emH5KKcxN8ttbKoMmyKhnHdxsa8 IWAIGAIjiUBdKByCFVIB/sALTkXfA7ehURTo6sJPXoLwRZe4x8F05qGN3RI308WTTn7vU7Fp+i/R 8bxSEH/p9xD7yvfE7G8fdy5yuGtRIFJv98f6U09BQYRjcblIq1ZwzpTKq+ZSvxw+hDWCphtJX1cS 5GecjOePfADT//7w8Mhnn0D8X7xuQO6cn6MwJ+HqSnq8uFJBfWLA+6BjXekoYOS9Cho1TS1umT1e KMLG31ZUMdmb0Xx50LLkMHgvOFLOqtjSGsHRlDIU38F8lu/zMg2bD38pUg/cr6yI2ecNiH31hsrz kHcVCxRNkp/9JqybewumLq/svRSWvjT9h9KX4nuiMH2eaFM2ILz5UYTkDK2KCyOWEIVEyRojyHMl jd3tLAK1/Wxn6Vn+HUNA+7fm5hkrYTkHZ0pLHI2iXFjfKWc55GQ+lQRJUXBOaxfrhoRYQSTjzspK 821rHtF05u8aBNiu5kYPAZu/Rg9bo7z7ImDz1ui2vc1bo4uvUd89Eai3eUvHeVAu4MnuBpFCTrZP 8i0c2FJZCWO4bIeAcDRX9U2/e7ak1doQMAQMAUOACNSFwiH4cvWFxRRuTMGKM76J+T85D4mA0mHo ZjsZudccKsLyoLS3AWvfdh3Cvz0Hbc9trs6aFkWDGEls6Y7G2nd/Gl2tcoBySchC/vSFu2X64YcM LbIJbjMkiozhkyynJH8+j+vQtKRa2eC1HIqsCPci+QGEeKEHYTnwqdotRuxb34T3zQvdeQWsc/Bi uwyGgbadtpvmqabtP7m0LYdj8/x2dCypLb86x2BlVacY/ClYfv9Rn0DXM/ejdcPgaTXU2/dCrNz/ ecy55SoNcm1AWuTDpxnF2td/F6E7LsaUZ58pp3M32aWIrFhaHVZ+akQoXtlGyWFQjrObnUGgKG2T yYlizCnCBlNB7gx1y7sjCOi4zeX8M18yGX9rtVxBtrkTc2vXSjLBqS1VXsJzeU8Oli7I/CQ6YI+H sMsh8/Ijhs7Gy460wsjnofUJ34cJeY/oe3HkS9k9KMp0haxsN+jmrQKVb/ru3j3qb7U0BHYVAjpv 8awgzls2d+0c8jnZLoXzFndLpa/v+52jarkNAUMgiAC/ezlXReXgQN/XL+ZgqrG7p+LBE4tljz4X IdYILTgv2Nwwdu1jJRsChoAhUG8I1IXCQV9MfMlyD3CeC8CtadCwLxZ/6FpMvf8GTFp4uy+kmjIH oQNfDu+e630sW16K/HEfROboBfIBnEU+l3d7+6dSKfT398tLrw2r3nQt+pbdJXSuR6xTDjgSF3rd mfDuk+2WekuC7/hBGDjiNKw65FBkZHV9Usrv6OhAOp12K+bdCzZSfZg12ppcWcGzCkhb6+MJuqGX nwbvmb/Ltk8dcq6AfDyUXsT6Qibd5Is/APzrs7IqgMqSlMsfjCcuPA+A5yR4slq+4pJykDYtEWRr EqkvaYVuPB9N6yspsgd/EU8cfbDDderUqejp6XHpYnL2RYNgMvnXV5SFf0j+EbFVwsceste6tAN5 YNmk6+q/lY8IptP2o/KBe7Dzme1IOgwjDR69vPFN/4vird/C5KcerDCqd7OORT4hwsrSeQteDeae 8DUc5/oP2rHqtJ8h+5drMOWxv2yZLXEUel/9fqzdfw4yS34ViJ+LQqJSH/LNldqFQhvWHn8Zelbe i5kP/hrJ9csDeWpuW45G4YUnIf/K46Qfi/JK6q8Y1aS0xx1AgH0qLScQP/TsZhFW52XVfE7G/w4Q siyjgoCbE6WNCqX9XTPpAbGWKqI/nUOB84gILCJyiHSPzNfccimRTJXmC06a/rwxKowZ0e1GgD94 E/LLt1EsUV689ySk5CBwzmXmth8BzltZGQdPPNfl5q1NvRlQiGfOEDAERhYB970l3wS0oDtC5q0G mbdiMZm7pBibv7YPa85bXBywZnO/m7eeXduLTL5yRtv2UbPUhoAhsC0EEjJXHTCrzX13TWoWC2BZ 9DHW8xbnAV78vvfkCsmPLl7qCpQVSLiIOpzjb2f+9jVnCBgChoAhsHsjEJKXR+VtMQZYaPEUpqtQ my+olStXlg8j5ku2oUG23hjowfR9D0ZYhO4Da1YjI0LpQuncBn0RU9Dc0tLiXoqrV6/G5s2b3T0F 6KTbFMphUrsITabORKG/Fz1PP41cYwu65GXO8jOZjBOSz58/3x3229fXh87OzvLWQv09mxERQWdD x2TMmjvX0aQQXwXsugVRd3e3UwJMmjRJlCA5rFmzRlb4FtHU1OTok1/WnQcKU1nQJzRWLZJDnVNc ER9Ba2urS0e6DQ0NrhzSJB0vIxYRWXnhJ1JINTe4+ClT5EwKWXGQ+9a7EXm6JMhveS8effvrkZey 5syZAyocWL/ly5c7eg6PJ76LSf/3O9nfpAnhs69DMTYf2ckUrgt9/bAo+ewe2l61XYX14UX86VNA T1/zsFxiw/YgbSqVkOtG20AGMaGfapkEtE1CqK3V5WE807HOhWw/whlJHxesBBdi0tzcXMaHGbTv DAxQsJl3ihX6VDrRxWX5dGqTWH94wlM0Bq95BrIdLeiV9mU5zBfKphGXTyWvsQFNQp/4qOKlt7fX lcF+SucOghZrkRbhLZr2+4w0HNDYjEL7ZFmq7StctN/RJx706RQb92B/thsB9kMqGu585Hn0ihCb XW2ovrndxC3DTiPAHx1sD3deg/jZTNqNn4E0za+lrWTH13BIznZI8uB3mS9kTueYCIf9+SMs84i5 ekHAn8ebpK1edch0NMmZGzZ/7VjbcEwMlBSlvTIWNvX1O8ufSIj9fUw/xXasQpbLEKhjBLJiPUdF 6TEHTpV5S76l5Swhzl02f21fo3HeyomidIkoGnoGcli8tscpHCIOy+2jZakNAUNgaAT4FUDlHhUO B89pR7PMW7M6kojJwpyxmrf0t5X+LufvYa97LZruvgyRnucR71wuZ0Cm0HnQKSi2zEDkoBNEltHi ZBv6O3roGluMIWAIGAKGwERHYHjLxXchCt6SRUgevAAzZ87Ec889516w7mNXtk6Zsv8CeH29SP/9 AaRecRz6NmxAjwik+RKmoJuCeSob8o8uBFrbMHOPuc4qgC9HJ+CWekzdYw+kxHJh4LbfI3nca5A6 8GBsEOUGLRlYDmnNmzcPCaGXljSNrzvR1X6DlEXnhUUk3drslA3FNatQXLcWzS883AmsVdlA4Xdj YyPa29sxcO/diB14CGZIfagsYBwdX8JMQ8uF9B9+h4YTTsKMffZ2aWgFQVp0rE9ooB/Zh/6OlmNe 5fhct072SXQ/nMQ6QhQWVDbkn3wMiMn/j12D4nf/CxClQ88Lj0RGylNlQ99t/4eU0ODzsmXLHC+R qKw+KCkbsMdBKNz3H+Tb9ndCfZZP4T6dfnC4hyH+6MeQtofmY51ZX16+pYCvcPCizeiVtmB4VpQu EfmgSoqigfmpBNB8/JApRhIunGm1HGWDzwwnj+SX9/QZTgE/6eSKMeTbZ2OgJPhnnFfqF4xnXi+W QFEUJexLzEefF+PYTuTJpZNnlyeSRE+LKCba9NwIn4+QbAcTzlRWdpAf0lE86NfWwUXan20iQNzp nFKpP4t/PrsR/aJ4OGLvDlt5vU30dl0CT7ZGolMLh4JsK0YlRFOSCge/DUOicIjJOKNywY0PN179 +cbGx65rq22V1C/K7X8s3uRWCh+5dztE31Cezzi3mds2Anxv0HHe6hvI4pGVm52idFpTEnGxHmmQ 801su5dt42gpDIHhIpCWbf2eWdMr4yuMfWc1oaOQkPuUs6iz98vwUNR5yy3KEUXpknU96JLvrvXd WWcpMkPOYKIg1JwhYAiMDAK0eFze6W+z3CS/81sb4pjcJL9HRXGq31tjNX/p71/1i2LBHJKr4jgX 2HxQwcPuDAFDwBAwBIhAXSgc9KOWDIX+eDOyv/0lGi/8KmbNmoUlS5Y44e9ee+0l5w6I4uCMtyGx dBH6L/k2Jr/+TU4A3NXV5ZQN3AIp/8i/EfnQO1FsbELh2hsxV6wQli5dCiodZs+e7bZJ6r3m+2j8 5lcwcOTLkPrBT1344sWLWTxo2ZASYXX6Y+9D6r67kV75OTR+8GNOwEylAwXPTENlg/fetyDa3YX8 D36G1GFHuNX0/DCnUJ3KhPSdtyHxyTORFcVH7Ke/wYwZM5y1BOuryoaBr34BqeuvQe89d6Lp0m+7 OlMxwQ8KKizCshVJ4QPvQOyx/yD9lSsw9aS3uDqvXSuKDlmFP23aNOSeeBQRSeNFxMT5O1cjXFI6 NMpZA3OOfasrt/u6q9D8tYvQ/4LDkbrqF5gnSpWlSx9Cxz13OMsGKhtw2jEIvexd8F60n8NCP2ro B9vIRQ7xZ7APomAY7yk0Vr/84SJhg5XDMKZlOvp81oss8D7oNI5p9WI8BT1aFp9r68O0dJonSEfD mYeCURV6M1xpMizIC+lonKYLxjPM3I4jQGyJeVoUkRlZeSff5TJubeXijiM6sjmleZwrlsZBQSwX PLEuyuVoku2PNY6HWIyr5WWsitBCWg8R2WubzsaKg6Eu/nDLPgrv2CbBOa0umBtnTCh+aVHi8PyZ qJxXEpMtHFPubIxxVhlj1xCoZwT4vpFtfzzZ8qNYuvS9VM9s1yNvbt4SDDPyHuCWcAIo5LXt5q2Y bI1ozhAwBEYGAd9qiN/JspGBjDVe+t0wMiWMHBWOfB39pU9+Rzx4P3KlGSVDwBAwBAyB8YrAmCsc KDTUlyn9Yksr4t/5IQZEy9/0pUux5557OiE/lQ2Z974VKbGAyEyeguT5n0Cv5J1y4pudQqKtrQ3Z hQ8j+uHTZVsgWeXeJVv3nPFWp3QgDW7NQwF+94++i+YrL0Fm2gw0/P0+9H7odDT88GdOicBGpLKh /yNnoPGBvyA7YxaS37oEA8JX84c+7tqYVhSF1c8BVDZs3uQUG5Ez3+2UDg2idKClBLdISv/pVsQ/ dZZYC7QjsXwJskx/3a8dD7S2cJYNJWVDZvpMNP3ht+iRt3TTZd921h1uhb5YNuT+6zTEHv8PcsJv 4r/PQZ+sJpj25lOdUoPbLmUfe0QULKJsEO5CstIbH3gncPUvnNIh9MifnWXFwI++g+ZvX4b05Glo /Pc/0fe+tyP14xuwX/t0hD54nZzZUFI2PLUCA29rddYgaiFAn25HBYDatmrZQJ9CeyoAVHAfFGSp 4J5pKLRnetcv+APHCShjLr8qBhxzJf4Yz4txtPxgGVQA8WIYHWnRMR0dLRkYxnLoWF+WrXwG6690 yKNurVRLn3mVD96r0/LU13Dzh4eAtpvOF2xbVSJRRj23NYy2FPH2+4nhPDxcRzsVhdV0+bwKq6l4 8EvlEKSygW2lW43pOPVT2N+xQoDjjRfbhovtouKz3fxxV5njdJypP1b81nu5Om/p+8K9S8TSZ0Zb BFzFOCklViN1sEdzveNo/BkCW0MgOG/1ZEJ4TCzrKBnnN3c2S8vZhFgS+fMa6di8tTU0qxfUcM5y 3+fya2NSQwRJUZLu2SYG0qVFAobn1rG0WENgKASC89ZATr65eiJile9bCOfk29n/bvB/25LGWM9b yi+3cXZXqWIys8rs4H/zD1VXCx87BNhuQbe9/UjzW74gilvKlapjh34yPAfHZlfjMjgXFjrSCIy5 wkErxA7Gq//NpyG86Ck03Pgz9MvLrPmiy1Ho3FxWNiz6wMfRecChOPgbF6HhAhHAiyCk/Q0nIy2C 9JgoGzwRHK/48hWIitXD7C9/BnkqHX5yE9rnzUfPVb6yoVvyP/Xxz2L6Xbdi7q9/jt4Pv9spHUKy Crf/o76yYd3b34NNwsseYhXQeOWl6Bchc/OZZyO7cnlZ2bDkMxchPHMW9vjCeVClQ+pFRyL759ud soFKgsWfvwQNTz2Oed+5FKp0SHZMQvqSLyAplg2dL38VVp51Hqb/+PuY8sffolfq03jplfD6+0TZ IIqFxx/B+k+cj87DjsQeF30aDV/4FPoEtHZROqQf/Q+iomygW3rh5XIGQT/mX/RJhFTpcPgbULz8 U0he9/9kbybZJ31vUZA0R9H46L/hvfklwK/vBybN8S0bRNnQ9/rT0PuKVyEqPyzUsU229+WieYM+ aaiSgDR1qyP3A6YUxzTBi/kptFcegjSCtIP3wTTMy3IYpgIfTcuwWscwpiefzKv8Mh2fGa8+05Ev 0g06pglewTi7HzkEiLtizzMAIiJEiMpKYW7LRcc2MDf2CKjCISJCH44XWjnQpwuOEx4gTce2NDf2 CPhN5M+bHFvaLsFxN/Zcjj8OiB+FB85JV6esLi59PyY39XAo5PhD1Dg2BCoIVM1bsviA3wPuTPbS O4fjj+8gc9uHgHt3iyjRvbsFy5B8a4Xl4twVN4XD9oFpqQ2BGgR03uL4ogERf8bkxaJIRJnl3znM wvh6+W3jeBGeOJv680Llm17YNlcnCLBvZcTSryg3Rfn0lFm8zBn7ErfylF09S77/+5kJmC9LJbPL R0VSaf6XOMtnuPj9Znz3F08WRFJUlHAW5vZdWJ4YRulmzBUOfFHx8jX4/iDefO5/uxVJrTddj145 pDciWwbRsmHRBz+BdS8SQbm4xz/1JRz09S8h9bmz0bP4aTRc/2Nn2fDshZchO2kqQrKaP/e5r2De V//bWTp0n/AmNP/0R+g64BA89TFRRESiWPnaNzpaqnSQ5e1oeuAerHnLu7D2TadC5CxYdt7nMefr F6H5O5ejVywaYn/6A2KbN+KZcy9E7z4HuBXxSz5/GeZ/+bMIi6VD/xlnIvmjbyM7bTqeFWVDWg4R Tr/oKODj55eVDukXvhiNv/4FukS4v+yD5ziT72Wnf9DhMPUPv0GvTPLRFUuRePJRrD7rk+h86Svd ytLF538Z86U+VDr0LFuK1C+vc6+OxRd8Fb1Tprn8fZ+8EId8/X+c0qF4zEsRuv2vTtlQPEgsFeTH gTdTtgSSWoeXbIL3lpeKSUUTQqJs6Dz+LVj5njPQJmVT0M4fZkGB4M585DCvCvC5lRRpq8JBhS8q 3KdlgaZnv1DBPhuK4bQ4UIUAn3kFnaZnXq0DfVokaF9jetLQ/OozXBUK5EN50vSkwzDSCdLjszql RT6YVukoXU1n/o4hwDbgpfOFtqmGB9uVJdT2jx0r1XLtKAKKP/s/nY53pafh+qzp9dn8XYuAzmW1 40qfddzR51irbb9dy239l6Z4cn7iveLn3hPyUz0vPwSd9U9RFOvyKiOmdDYO6r9tjcP6Q4DjS+cq +kWRsFDBUBCtA69gHLm3cTZ4GxInOsXLWbblaFXK+Ypzv9iSRvxvbJnayu8Bnb8Gp2qhhoAhMBgC /D6g0+8D6hoKgW3gaKGVl0/oevrecr+8KSSRy7+XeVZ+jxfl4rZQ5sYeASoLuHXn43JmWJ/sgNHZ J/2o1NeUOx5OfuCsVjTKGSEdzQm38IVx3D7vyVU9Lt/GnoGSAkxzUUhr+QyX8dtfePYnz6NiP37x XpPcGYXR0sLHSi+3u5FEYMwVDrWVcT8SZJJc+9FPu4/dtltulB/iYSz+0NnYdMTL5IAif3VgvrkF T3z6Ihz49S+iWQT8Odm6iMqG9LSZ8v7zP5apEFhCIf2lF6KFyoYDD8XTIvj3YiLULk26q084WV6Y siXLTT93rKymsuHN7/BfoBJSjMaw/JNfEKXDxWj5+dVyqHACiz75RfTsd5BLQ37TU6djxcXfxByx dGj4/jeQmTXHKRtyLW3lcrqOeCmWf+JzmPvtS5AQ5QktG1Z95NP8wvBVyVLW8nd/SFYOhTDltpul ziGsOvM8dB7zGlFIlD5GRHnxzGcuxr6XfwHNV38HOcFg0ee+ivTsufBKZxT0zDsQC8+7CIde+T+I irIhP6kZ+UMSiOR7ykc5Fea0o5BqlK2alkmpm7DydSdjw+nvcwd66A8MJxAZwY8G/WGnP0hUMaDh /JDiPePVF+ZcH6BPp+H0eQ3lNJ60lC4VFVo3pUVfP+A0D8OYbzA+lB4/DpUef4gFnebTctUPprH7 nUcg2JZBatqO2g5Mt7W+Esxr9yOPAPHfmmM7BZ21VRCNXXvPtmJ7DDW2yM3W4nYtt+OvtOBYcAqI 4Eqz0nZKNm+Nv3Y1jusDAZ2/VHgX5IpxwXA+27smiNAw7oOf3KV7/d6q9YdBzZIYAoaAIKDzls5J HEu8D151C5TwKYw69vhXfpm7f1v/6q/b2kwoxth/qLTiIeRdfVmnOOjPyBbTNQoHfoZmRYkcj4rs JYAA2zDHM0RE8TAgZ47lnalgdQLLZ7hojxhv/YWKuE19GSTEvIfWZFTOcXHKVkSLWlXzdxCBMVc4 6Ee/Cjq0Huy8q0XgTnFuj1gldB/5cvA0Aa4Yp+NkCtmaiAL3eT/4Bla/9yw5c2G2mzCVJtP1i2Jg yWe/jCm/vwlLPvIpREVhQKdp+CNk/Rvf5gTPYVlFsO6UdzrTMk3DcopiDbHsvAsx57uXYd1rTkSf 8BMTwYzSoN/bPkm2T7oUs3/8PayUcvKtomwQIhQ4kwbTUOmwTBQerQv/iec+dI57USsN1ovpnpN6 cM/ZgXl7YbMoJVQxQn7oQkL3WbHcmPu9r2HVae9DZs68qnK4QqJ//j5Y+PHPYd6tv8PjZ3wExWTK la9l+ZSAmXffjmRPJ1ZInRtKgVQEqBBe0+2Mr2XWChYVF9J2bSk+06rARfORn6BTOuoH43iv4Xr2 gpbDMvTSPFqG+sH8SqfWr6UX/BHL/KSl9OgrluprnPJg/vYhoG1I3BV7xZl9JZmUPZoDCiPDe/vw He3UOta1HGsfRaI+/NrxxTOJIrKSVdtJx52mqw+u658LxUvxU4655UtUPnj5/o/JPd9birX6mtZ8 Q8AQGBwBHV/0OcYymQyiOf97jAIVHXeabnAqFlqLgOKlfjCe8xPnq3jcn7/4rFcwnd0bAobA4AgE xxXnKGfJIFKPUCjjfwfIfCY/XMu/XZm+nlxItr3mpY7brAjj+mj+GCHAvkRlQ6coGrr6c3j8uW5n sbDn1EY0xH2Ziv99KdviiaIhIZf8dxY2IoVx/a0osqREjILYkDtnrFCsyLykU1o+w2Xc9pekiJH7 RYn2lIwLWjW8YG6rLOxOoKVBznAtyY/GaOhO6GKrpbljWFX9UKVPgaHzRVi/+oNnux8LPLSy1vHl WxQB/NLzZQshide8wXScePv3PwjL9jvQWT7whch06lgW6VDpoDToq4CY+fnMg6iXnfPf7p6bgwTT kpb7WJDDn5de8BVHWktQgTXj6XqOerm7mJ8uGM8w8rL6jLN8+hJfm44KhWJTM5aJ5QadWnOQX5ah 9Pr23AePnfUpR09puAylPwxbc9zrfOGs3DMfaTCc95pH/WDenblXesqn4qs0NVzTabj6Q4VrfK3P 9Ly0nNoPNi1P8yl99TVc/Vp6Q6VTukPFKz3zRwYBbRfizkv7suE/MviOFJXa8WftM1LIjgwdtk+w jXQ8jQx1o1KFgMgOyvOWLDLgnEW8GUbfnCFgCAwPAZ239Dvb5q3h4bajqXTe0rlK5y3OYeYMAUNg eAjot5b+PqXFvI4tUuB93Tphjdw5DktsUh1SXyqRukVvlzDm+pd80/vn7ISQkvN2eF4YnfazuCx4 4ZkhPD5P+xvzMVVMhLEFSd8oSuXgVkxMZ/kMl/HaX6hcc+fkiAUPz5nMiVw1L5csaefQMDdKCIy5 wkE7rP7A5ko/CtX54qUfjOe9ftDyBc1JkWnUMb7KAkIiuGJAX+pMp4JILY/lMF7T6IezrqzXONKh 4zPL0RX0yp9uraN0NL+Wo/xqOuUjWB/S13J4T6f10XL07AA/1ldYaBzL5soulsWVqVqm8qx51Gc+ 0icPPFuBPPOZPsMUC02/M77yqPVVXIaiqekVT02n4fo8lK/0Nb2WO1T62nDNp+H6rHSVL/Vr0w31 rOHmjywCsbistEvIKmFRDLKt2YfZZtpuI1uaUTMEJiYCnM946fuXfiRSWcE2MWs9RrWSX3R8n7j5 KhaVuct//3LO0vfMGHFmxRoC4woBnbfcghz5/qXPect///vf7PYtMHJNKlOUYOv/PonLill+d+lc ZjiPHM5GaWIjoPMWf6vr7/Wcx8UG9S26d3xzGxLZZifErXZKWgYvLDs6yMU5wOaBXd932S507Evy IS8KBg+xhhBOOFi20ZZ28k/wrPDF38lh0TQkZfsQuZX2lD1FpP+RjizTxPTmmPwWCGNaipaDFTkZ v1ktn+EyHvsLvILr1/FQEfGYLPJmT+c3o1xOPiuaCJ271K+MGLvbGQTGXOFA5oONqoJh+gzXF7IK EPlRy3B9OWsaDa/NR/qkwfRMG6TjJtVSGaq4CMYrbeVB0wfpKH31NY3yoYID0mecphuqHI2nz3KU jvLCD3vScS8USaN0GKYXy9LyVMHB/LVO68EygpdiWZvenrdEYDBct0xlIaOJQLAN2I+1/zI8GDea PBhtQ2AiIaDvLa2TjSNFYuR8mZ3KxMJi4aDzlfrlSLsxBAyBYSGg85aNoWHBtVOJ9J1AX7+5FP+d ImyZDYHdCAGOH/52D44j3vOqb1fSMjgmS/fkue75rm9UR5K7CM8Gk+XcTQnugCHWCu7IUL+t2L8i YsHAOZvbygQtHMgD47kSPCwWDqGSEoL9lI5bgbp4y1eWuxku9d1ftO+y34ZFmRaRw+65lZjo0ara 0HVw+zMqCIy5woGNT6eCdD5TmM5JkB1EBeZBwTvTM46XKgqYj5em0zQqeNfOpvH6YayKC6UzVLwK +El3e8phWuUlyK+Wo/GaRuur4ZrOEZE/yq/yw3h1pM/8jKOlA5/VYkLrr2lVUUGfWKRSKYddIuHv gR+kq3lG0tf6bYvmcNMNRWdn8+9qukOVZ+HDQ4DtzUvHzWi1//C4sVSGwPhCgO8JXnyHcOzw3aDv yvFVk/rm1p+n/G8Jna84Z+m8ZZjXd/sZd/WFgH7f0gKYjuOIYyjkFHklYVh9sTyuudH3gj+PVb63 iLs5Q8AQGB4COm8xNceU/l53+4jLClyZwPxreOR2eSphWfguFUteRajtLt6bG3ME9HtefWVI5+1a n/HBPslnTTNUOOPphoofKtzyVX+XKM6Gy+jgwj7K37W8nJxVLB326EhKvxX5c1h+78qzx3ibugjV qLgxVzgEa6UDji9efriyY1ARQReM4zPjOJExLf1gfHDA8p7xwTQM0w9jVUiQDp3SqY3nM2loGqYf TjlKN8iv0mB+jQ/yWMur8sR8yq/yF4zTfCxLL9JX2sxPp3nocwslpiE9XrxnuDlDYDwhwD6rY4l8 Wx8eT61nvNYTAsGxE7yvJx6NF0PAEDAEahHgfGVzVi0qo/dseI8etkZ590NgvI2nWtmCTL788bX7 NVyd15jbxqCkfA/2MZX3BMN4z3alYzxlSQzTew3XPPTpLJ+Pl+FSn/1F+6j2V57n25wUObP09Rhl oOz3ujec69H2Z6QRGHOFgza++lxxT6cCfp34GMY0KlTUF53G02e8CuKZnk4F9Eqfvl6DxdfSUfqc dINue8thfqVFOoOVwzBNo/FaX+W/tj6kpfVhHi2HlgrBZ6WrdDSPKhlYDsNUwaPlkr45Q8AQMAQM AUPAEDAEDAFDwBAwBAwBQ8AQ2L0RCHlcGVyRjXgiQ+BlbmwRUDlPOCJbcIuljOx7IYIiIJmQHS1K MjByqDtdqPxH5VqUF/EiHfrBcObT9OoH4y2fL6ckdoZLRXFFPMayv7BfUn6q7dKQAF64RwO7M1KJ sDsgnWPD3OghMOYKh9qqsTPQ0eelgn52VA13N6U0W4tnOs3HzhZ81nK2Fe8yBejos+bX523R0fit 8bu1+mp5Sqe2PuSDaTScLxIdYIzTcKWjvr5w+KxhTG/OEDAEDAFDwBAwBAwBQ8AQMAQMAUPAEDAE DIEyApSrlGQrbnEw5QiU1fjiFpMplIHa9TdsFq7ezhc8dKfz0hYiWI3FRQhekfVQnqSyn1r5T/CZ gnPKkFSOZPn89jRcKv263vtLkD/234j051Tc3wIyJmeS8LwTc6OLQN0pHFSgrp1DNYRDwVAbr/k0 vdLTZ/U13bbidYLVfOprfn0eio7Gqz8Uv1pObbzm0/K2VY7mV8WG0lVf6QxFtzZe05lvCBgChoAh YAgYAoaAIWAIGAKGgCFgCBgCuycCFM9xCxL+K4vqZNuewJMDxmQKu65/KNb0PTkUt3sgj67+HO54 ZJ0cAB3GW4+chVQyVl6Iq+lVblTLqcqbVBdSuFMAAEAASURBVJ6k8ZpP4zVcfQ23fIqI7xsueuDL 2ODCfs42YL+kr+2h97oAu5o7exopBOpO4TBSFdvd6egLoRaH2vDa59r09mwIGAKGgCFgCBgChoAh YAgYAoaAIWAIGAK7NwJcxEhFg1M8yL1bQk+PIVxOz7iS7x7sz65FQNqiIO2SE+FqrygeorKKmxYP dNou6m+Lsdp0tc9D5a9NV/ts+XwEDJfBcRgtXKhg4FDIy0HRdDFPZzKfD/s7OgjUrcJhuB1tW7Bs i87Oxmv526Kj6Ybyh5t/pNMNxY9aRNTGD7f82nz2bAgYAoaAIWAIGAKGgCFgCBgChoAhYAgYAuMP AcoHeIXl/AZeZReWLUp4mRsTBFRuo+3DPet51TqV4+gKb30eKl1t+Laeh6Jn+XxF3LZwqI03PGsR 8Z+3Fxft7xwfeZm21nQVnOJhzhTZaixG64eI6koHL9BCdwqBulU47FStLPMIIZAHNm0WWtJNWtvl JO8RImtkDAFDwBAwBAwBQ8AQMAQMAUPAEDAEDAFDoG4RUGE2GXT3NGSQeydC3TE5at3WdaIwpooH 1qe2/bZXWDtRMLF6GALs+7T14ZZjtPopFFMyPhhGqy2bzEarh5jCYbSQHad0dc+9YrEfoW8eCjyr FXkzildeikjpkBXVFGqs+YaAIWAIGAKGgCFgCBgChoAhYAgYAoaAITAxEAgKqPW+WCwgJJcKkkKy R7qcSjwxKjyOa0Grhnye1g1F/2I7yfkauVxOrlB57/pxXEVj3RDYbgR03mLGTM7D3xZvFGVDETPa GuA1hhCLyhkTtg3cduM63AyDn+Ax3NyWbsIi4Hk5eD3B6i0H0v7+f8FQuzcEDAFDwBAwBAwBQ8AQ MAQMAUPAEDAEDIGJhUDtCnm/dpQJ+HIByun0yWR2Y9v2atnA1dv+AblUMsgKbhGuBttxbLm00g2B sUGAY6AgSrh0tiiX3MtZDrRuKNlrjQ1Tu0GpqpjeDapqVdwaAvoSomac97lcFlEZf5UOUkQ+m0VR tILUEsZiMUcuqDHcGn2LMwQMAUPAEDAEDAFDwBAwBAwBQ8AQMAQMgfGLAFes6qpVd4Q0j3OQyz9O evzWa7xyrnIc5Z/na0RDHhpiYURE4eCUQmUlhLacpjbfEJjYCFD5xjGil/8sh0fTIkguPnNLpYhZ aY1KR6jIk0eFvBEdbwjUDsQg/9SO+9pye1EFcbF7Q8AQMAQMAUPAEDAEDAFDwBAwBAwBQ2AiI0BZ AXc758V7Z99AibYzb+CzubFAwG8Lv2TRMSAqf5qTEadwkIYqtdVYcGZlGgL1gYDKOclNcLz495zR zI0GAqZwGA1UxyFNHYD0qVRIpzMIyzeDb8fAChWQy6QR86JugDpNoHxYmIXDOGxsY9kQMAQMAUPA EDAEDAFDwBAwBAwBQ8AQGCYCTjDnZAX+GQ7lJYhhOb9BLsoFTDYwTDBHKRmVDY2JMJLRGI7dr8W1 R2Miau0ySngb2fpFwFckiPFVycIhK7u18FK5Zz6flzNPIhIfQ1HGjZ5Ra3PYyLapKRxGFs9xT00V Dv4HRXV11MLBBmE1LvZkCBgChoAhYAgYAoaAIWAIGAKGgCFgCExkBILrgN09jRrUwsEMHMas6VU+ Qz8WCcuWV55YOMScooHNQ6dp/Cf7awjsPgio8oE15hnRYRkUqnjYfVAYm5qawmGEcA924sFI1sbr hK/+YHmCYZpffY2rzV/7rOlqfaWjvmr+eIYDL2r8uB1jxRVRyOUQkjg6zafx23pWvtTXfLW+0lG/ Nl7zq18bb8+GgCFgCBgChoAhYAgYAoaAIWAIGAKGgCEw8giE5HwAXnTub5gSPIq4zY0FAioXoc9V 2tyLXu/JTzQadeEM07RjwaeVaQiMNQLRSAh7dCRFlgmI4Q8inMdsy7FRbRZTOIwqvBXiXroHyOQk QDYpamxCKBZcH1BJt607Lz8A9MnlnNBqSslI2XEzOaXnFWVvv3gjPBl0FPb7CogtuRlKEaApXXym F1466wdFhb+G5Ha/3BydQrpS14TQSWw/HeXLfEPAEDAEDAFDwBAwBAwBQ8AQMAQMAUPAEBgeAkEB Ne+9UBiFRDOQ60chnEQx0QovEocX9lfTD4+qpRoNBLSt6Lt7aSs6KiF0u5jRKNdoGgLjBQFaNvBs k6LIO2NUznFOM1XpqDafKRx2El4K5umKq25H6OsXi1BctGQtp6D4yXPk5ZsH/vn/EL75KoS61lWV VDz0Myi+9T0IT0648KFeArQ2QKETxXtvRPie3yG0blEVHbeSYOrxKB51CrxjjkU4VXmxMKG+eFRR oPwWnr4N4d9fi9Cz//LLL1FNTX41Mq/9KArzmmqGnq+ECJc0gErP8Sd5C/3PIXTnLxH622+2qCuS +6JwxPvhHX8iwu2D17dCL4PQP38D3PozqeszJa5KHum88HR4J56CiGgm6YbCrZTDPEPAEDAEDAFD wBAwBAwBQ8AQMAQMAUPAENhOBPQ3OrPxd3ch2YKNe58kCyn7UMjLAsNYEuHWeSKDECVExJQO2wnv iCZn+7C9orGE7FhRRCabd7KgkCgeGEfLBzqVD41o4UbMEBgHCCSiIRw2p9FxmkxEEJP9laiEMDd6 CJjCYYSw9TqXI5ReC8iifHQthbdhMUI/EQH7c0MU8MjlCD/yE3ifuhXYU17QQzhv6R8Q/vq58F8P QyRaJ8qOW3jtC5z7c3h7tw2RkBZDYmXxqzMRueevg6fZcCcSv7gTM/Z+JwolI4XBE/qhfKl5T/4S ke9eOHSy9DMI/fV8d3kf+AvwwplbpPU/ZtYDV5wsSpBq5Uw5Men87Qty/QneFT9GKGmTQxkbuzEE DAFDwBAwBAwBQ8AQMAQMAUPAEDAERgiBoHCaQuui7KyQa5gML9qIYkG2WxbrBiodQtE4ZF39CJVq ZHYUARHNuNXbedm9onsgL4qGEBriCVMy7Ciglm9CIKDzWETmsFQ84hRz8WjEjY8JUcE6roS/HL6O GaxX1pygXWZ0nnWQk7MNskWxZii72xH5n60oG8rp1olVxNko9vGE9Lw7O4EWCLwczSd+7JQN5eTb vBGLgCuOgPdU5xb0lM/8zecgNJSyIUA/svgXiPdJgOzaVHZULpQuPeeh8PhVCA+mbGiej2Lz5HJW vQldfSy8hWsG5a/w0/ciXKtsSMyHJ7SqXS8K6ZzDSPGqjrcnQ8AQMAQMAUPAEDAEDAFDwBAwBAwB Q8AQ2BkEdHU8V8hH4inkpuyNzLQDkJtxKHLTD0SkeQqiDa2IxuPuvAAK91TAtzPlWt7hIaB40+fu Fz3pAtZ2Z/HHf6/BbQufRzrvOQsHTTc8qpbKEJgYCHD+4hWLxdwVl3kqkUg4ix/OaTzjRM89sXlr 5NvcLBx2ElMK4J3QW/yhXP6Ii9B9xItQiHSi4f6r0PjQPYGk9yF8/7MovnqfcpgT6qcfQ+TbXymH +TeHIH3Sx9C3z97IymKCcO9aND52Kxrvlu2HAinD3/kGit+5qGpLJEdz058Qu+OOQEq5bX4dek86 A33TWxBe+wSa77gEyXUbXRpPlA0hHjtRcqRB52jJfSj7BCLf/1op1ve8vc5F10lvRLrZ11REupeg 5defRGLlhnK68FXfE/4uLvNXru+Dwe2ijkL/f12A7lntLl8434PE4nvQfPNlCGd6HA/CnfNtYihD azeGgCFgCBgChoAhYAgYAoaAIWAIGAKGwIgi4AR3IqALx3iGpL9I0oVFZSulMFcLh03RMKKI7xix glg35GRLpd50HtGIWKVsRU61YyVYLkNg/CHgywxDEP2bczGPEtSgFHX81Wk8cGwKh+1sJRW6U8nA e7VMSMshyQ1b0JqL7nd+CxtnicmhO+thMrpecT6awnlM/8f95dSh+/6CwrF7you6YnBSuP0KVDfO G7D27LPRG+WZEaIF4HZH8Q70HvYuhGfNwryfXxoYLr8E7vsA8i+ZWSoXjs/QHddU02x8B1Z+8D3I kBMZeN6UA7H5nT9F84Nfx4wH765SNjCBKhro0wIj8ucfVhlAFA+4CCtOfImkzIvVBhkUF5mG7rdf g6k3vA/Nqzb5YfiVWDl8DLmD2t2HCellly1EcGOp9OvPwfNy3kNoYMB9uEQiSeT2OQHZC16HaH8R qWQRYYGCec0ZAoaAIWAIGAKGgCFgCBgChoAhYAgYAobAyCCgi/pUkZBMyiHRItPgM3+Dc8cDpuFq YYbpKmHem9t1CKg8hD6vfEF2z5BLHduJl7aLtqvGm28ITEQEtJ/T58X+nyt4WNNVkHECzJkSl2Nn qCiNSPxERKA+6mRvg51sB2fdIC9eHsxT7eZg03u+h3XT/RczJ39VUvQc9U6qDCou2+NeAnwR+OmW I3ZnRSHBhJ3vOgs9ET9eXybqF6YegzXHvKpCT+7Cf74TXkkp4tNcgej9C6vSdL7lXU7ZoHQYSR42 H34Olh7x6qq0+uDT4oqGJYjddqcGi/9ybDz+aBSkTK2n+p4Xx7rjP0SdRtlFHl7o0il+3oBvVaEJ irFQFR0NJ61iU6PDibyYMwQMAUPAEDAEDAFDwBAwBAwBQ8AQMAQMgdFDgAI7XtyChJduUeK2WhLL BxXsjR4HRnk4CARlO0F5SfB+OHQsjSEwkRDg/ETpIc826RrIidySi5cZZjLF0WxnUzjsILqcsFWg Tj+TrWiRSbLvVV/C8y2FMnV9Qbt8oSnoby1HyUZ798PrzCCT8a/sk3+uPiS67cPYPNVvquDLnfd0 pNm936vEriDg1t+Dwqa0s0SgNUL6+adR1dgN78OmNl8Lrho/8sgPBvqbD30XNgdNDliO1JMWHe48 iOcWVvFYPPBEdMr+S/oi0w8RxSnTsAA9wTo/+xiy6Qp//S17IqiyaZCtk9o2Zxw//JhRenqveAZq bLeGgCFgCBgChoAhYAgYAoaAIWAIGAKGgCEwQgiojIByAv4Wp6VDKpVCY2MjGhoa3DP3RefvdbVy oHzB3K5FgAtH/d03/MWwhWJBtlOqyG/KCz1FdqQym13LoZVmCOx6BIKK0EzOw98Wb8QDizZgc28e /Rl/Qfeu52r3KbF6157dp94jVlNO1noFieaTcReuHZwvXxW+A43onb0fWrueLmfxXwClR89tclSO y+5/sFMm8LWtgnZ9SeiLA8m90C97OrX0a7Y+KU+2fSpZOWDdU4Etl4DiXnLQk3wIROQij/xACNaD YW5bMyVX8rUO4c5qi4RQeiWaVok5Zb7oTJLCEelagg1ffPSzxW7EgmYd8rFC3sMl/IrNezirj0S5 vH9h8rUno/UQORPipa9CYVqbq7viqX45ud0YAoaAIWAIGAKGgCFgCBgChoAhYAgYAobAiCPA3990 lEcEnYYHw+x+1yOgshye2eDkLGFuIyO7Rog8hs/mDIHdGQGODyrh0llRyMk5JwVPlA1uw3lTjo5m vzCFww6iqxO6+rVkIrGw28+QWn/V9DNtNpv1hfCx4IkP0unFCiGX8w9aiq5aUUUuPXMquGqAdLii QFcZkF5arAQo1B8YKCA7ew7wjOYVbXZfGvmkbyKU96o/DDIzpzklg/KnHw7KX6Eg5Wwx9irKlXyx yp4CoSXfxYwlVWxv48HXwHulDxfPm4kN7z4Xs352RVW+2KNXYLJc3oxTkHn1O1A4dJ+y4oEJle+q TPZgCBgChoAhYAgYAoaAIWAIGAKGgCFgCBgCO4WAKhQoi6Cr/f2t8TtViGXeYQQoEwq6sCw6jYY8 NIg8KiICHYpbmMZXQlTLhIL57N4QmIgIsN+z/+vlP8sZt7QIKinjZJQ4WetErP9Y18lmnFFrAf9g Er6Y+VLWLYH4QnZXTbk6AOiHNz9bFRsWTRxpBOmQrl4MD4WiKFapj/oQysjeZDKIeNW8h5BvbnR8 BPlTehq2hb5BuFI+Y4seruJxux96xYqjhqnCrBOx+G2fqj7fokQ4tOY3SP7sbWj8/IWIbkhvd3GW wRAwBAwBQ8AQMAQMAUPAEDAEDAFDwBAwBAyBiYQAZTTquGg0Kn+akxF3UeYSjNd05hsCuxMCKsdk nYPjIXi/O+Gxq+paJaLeVYVOtHIG66TheMJZJSQSCacYoFKA6ahR4956teYDRXc2gp8mUnMAtReK u/0SqbQgPV/BIFselV4eDOf5D+GStYCPbwNyMf8QaD7nctUWCalVmxDfd1LZcoL7MdJR2UAFRTYb r2XRxTve5S43dS/5+5AL45/C3Hdj85x2MUqKOkVGuLQColCQcsVkiaZ88qoT3aH8o7XFIa8GT7iI CS50LJcuNOfVWHbuS5F48i+Y9refItG12YWX/2T+D7FLnkThizfDmzSYSqSc0m4MAUPAEDAEDAFD wBAwBAwBQ8AQMAQMAUNghBAwi4YRAnIUyFDZ0JgIIxmN4dj9WpxcpjHhy2dGoTgjaQjULQIqo1UL B+7kwktlqJRr5vMRkc/KVu8ybihjpbP5bWSb1BQOI4DnYJ2SgnV2WlUO0GfndtYNohgY6nwEspPZ 48XAPx4vcxbr7S/nU+sDHUB89un2I7lqeTmPuwloszW9JggV0mXeyJPSCfKpaWt90io2NFUF52Yc hecPmVlWiFAJQscDq5lefcWkqampfH4E0zGczscniYH9XoNlciV7nsHke65G47NPuHj/z2JErvkd cp9+cxnTQKTdGgKGgCFgCBgChkDdI5DH5tWrsGkgj2iqA7NmctGCuYmLgLX3xG1bq5khION7/WY5 czCKZHs7mutuMq93/sZZDypkHcPyE9+5UDQ+ziow8dhVeRT9WERkULLQszkZK8lWSu1UtTh14mFg NTIEhkIgKAuNitiRC7UZFgwfKq+F7xwCvpR352hY7kEQCIkiQLdRok+BPi91VEgEXbCze5Hql3by 6Sdk/z3Zgy+QX2krjWjxeSQ79Yn+DOSicjZEaUulYAzvI6uekxeRmNsJb7zofGG/z1c0mpRnF1z1 RwdmUU54D7rYuufLg1bT0Nd604KC51DwDIpUKuXu+cxwXgzjxXhe5IlKiGzr/lh90tex4pQz5bUZ cOufQL50Hoa/ZZRNGAF07NYQMAQMAUPAEKhLBPQbofuRq9Exax723ntvzJvVge893G0f/nXZYjvH lLX3zuFnuQ2BekbAH98DuOnDMXRMnYqpUzvQEjsXi+V3IuPG2tU7f2ONz/aW78k2z14ujeLGlSiu k8MbNy0DulbBy/TBy1dWDm8vXUu/cwgEZTi8p/yFshTKWOjzmXKVYLqdK9FyGwLjE4FoJIQ9OpKY I5cY/sgCaHlPmeJhVBvTFA6jCq9PnJO7Op3s9Xkwv9g8pVq4vuJmxPurP9z0B5zmjz/xh+qVgTMW YKCi30B+2kHVZyOs+jOS/uIEJVHlxx/9KZpqdjMKJshP3w/FQEBkyR1oFVskfZGpz/qq0kFffvrS Y5zGa/rgS5FxdKxrZu5J2DS/o1JiRs5xyPtbVNXDB22FMbszBAyB0UZg9d9/iONkXvXnjQX49p+X j3aRRt8QMARGHYHqrR9HvTgrYIwRsPYe4waYcMXbt8FYNWkOG9YGy16KDQPB57G+r3f+xhqf4Zfv 8fDVfA7ofh7oXOVfXWt8ZYMoIyi4Mzd2CKg8RX2ERJYil8pcxo4zK9kQqA8EaNnAs02akmG3tXtE nkXKWh/MTVAuTOEwWg1bFoZVlA1alP8S0KeKr4Jzb8qR6G6thANPovnGP8K95EsaOLVccIqHzQ+i 4w+3BDOg7xUvB89RUGE/4vPQPyWY5CG03P6QO09Cz2VwtIR+5NGrMeWW64OJy/f6Ags37I/uGeVg ufk7Zt7zH7elEs+ZUEuGhoYG8GpubkZLS4u7bxSzS7VmUAVDomsZUkvXunCmb2xsdJfG5/N9iHRv qhQYjyIn5py6J5vyXklgd4aAITDRENBxvvwvN+DucuUewW//ubpqLihH2Y0hYAjUDQI6fvne9s+z 4klOFceVk2axWMFjvN9Ze4/3Fhxf/HNOGezbQPvh+KpN/XOruOp8Lkb1AVdEpDTPa7pA5C651XLr lb9dAsIIFkIcC7LfuZfrh9e9CqE7LkP4lguA350P79avwtuwFF5/p5zZKGlM6TCCyG8fKZX7RGNy hmg04bY4K4RionCoyISofFB5zvZRt9SGwPhHIBEN4bA5jTh8bpNTPMRlf6Xqc3DHfx3rrQamcNgF LcJJXd3WJvhKukZsfPnbNIvzQ0u+gvarfgys3Vj5QZ7vQWjhL9B6+ccQMGYAGs7AZhlEWpbvN6L7 Ba+vohn+zyfR9Md7Ecp4jmaxdzliv/oomn7xg6p0tQ8+nwlsOvp9VVHRp76E2Tf9HsnubFmTrhr1 aPcapP5xPdq/dhTaLjoL0QFdnez74b9+BrEfvh7NX7sEyaWr3BZSmjcczqH9b99D24ZAcfEO5OXj R5193CgS5hsCEx+BzZ0bqyrZmqx6tAdDwBCoYwT4vqbwolYm4YfZKqM6brodYs3ae4dgs0w7gEBn zbdBS2LXzSfp9U/htltuwk033YTb7n0KYoe9Wzh/fG+5PtTzOMfvOvyHArve+RuK73oMpziDSoeC bGkc6pfv8N71CPXI1bcRxVwGRVo+mBtzBDjsivInX/TQLWdk9aRFCSRbeVfkTGPOojFgCOxyBLT/ c5v6VDyCZCyMeFQUcTxl3dyoIlB3RzqNam1Hkbh24uEUMdgHWKi0vRCF7PzRnd33NHTOuBFtayoU Qyt+hMSlPwISe8FLiIVc97MQr8btjw3veAsPZ5ADgyJu7z6WR6uDwovejb6//BGNge+ByL3novHe GhJbeaTFAR15LO71dqyf9ztMWVbZeym8+ApM/u4VwuN8FKfNk22PNiK88T9yErbLVvojB2oLb54M cMXCi04TpckiYMONSPxILkxGYc4hUk4vos/9s+bECyB9wmvEwqHg+Nge7INc2L0hYAiMDwR0ntDV z7PnHyyMP1pmvihWU7TU0vnJ5oQyNHZjCNQNArXjOJur3lKnKGOY45jjlxdX6pkbvwhYe4/fthtP nPP3CB3njlk13waerPLVOUXnk5H+PtB+/tgvzsIJ5/zF8QIci791/RlHNvvn45UCJ5THevPyv8sK yFXWgEk9/dXw+bwvyBmL+bze+RsvnUH7t2tnsULMZ+QHvVwxaXsV0zENf5NLZ0BExqGsny8Lt0d6 vI0X3HY1n4ozfar/etIFdPXncPvCNYjKAdKnHj0Hibhv2bCrebPyDIGxRoDyVc5TPNNEvxnIky5u pvyAY0fH0VjzO9HKN4XDGLSo/zKoLlhf2trZQ6FGrD/t5/Bu/Djan6sI9F2uzLNilVCd3386Guvf ez66WqNoCCgwGOfTnYaV7/kq9rrmAsQGyx4I8/Y4Bytf0Is5/3d1OZQ86kDkAAXi2HjSDxC+9YuY tOipcjp3k1mC8Iol1WHlp0Y5ocU/m0HpFZOpcqx/swGRFXdXW26UUuQOuQQb9+2oPrOiJrc9GgKG wMRDQH9A7nP6D7H48HPxfH8W8YbpOOCAWWXl5cSrtdXIEJg4CKjwgn6hJCjU2rmFDDVhGmf++ETA 2nt8ttt45Jp9bd93/6jq22D//Wfusm+DWGJWALaWbf7OCiQe17fEnXO3eAFXspwvjv1GCvXOXwC0 ur5VHGV/Z/kB71uvqOyCjDOenYC+u6/r2kx85gpi3ZArFNEr1g1UONDiwVy9IZDH5tWrsEmsUKKp Dsya2T4OZVtSh/Wb3dZdyfZ2NNe5ZNmXO4Z4DKxzMc9JN+utY0w4fuq8W9Qv3r4AX1bqq2A/LstY As6LxV2cptMoTV+MBV/THQjJMemxWMTl4YvaWSQUpmPdW36G3mduxbQHfoF4V43iQYnGD0D/i96O tYcfAbEPQlxWBfIMBd3Hj/T4MchVPrG2w7DsrB9i6q3/i9ZlC5VCxY+/CD3H/RdW7DUTWB08F2I+ vIaYo8k6sR6kmcu1YtOJ30Tv0rsx7b5fIrlhRYVWzZ3XfCTyC05E5uXHyvlFOYRk5QvpkL/sK76I XNOhSN11HSKbgnsnVYh4ra9E53FnyOHR09AkmkhqIxXPSiq7MwQMgYmGAOcIncc476TlA7p97l5y UH3RKUG9XA55mUt0vqVPp/5Ew8PqYwiMJwQ4dul8oZT8CJbxytWS6XTA3FLiC/msi+O3S/DdbuPY wTdu/lh7j5umGteM1vYz/sYpipCtbc58tMqcwzkkn04jKr+HeM/5R78RRqLiWj7nMrq8CPcqzkNa 9rIXliac5aXWW+fzrGyvUyhkkK06kkfqzu+yvL9v/K6cz+udv0ofGR93iid9niWZzshp4HIlS+91 rUVa+oEnlg+NTCfXSI83Lcf8wRGoaifBP8/5Ry51nKd4cSzS2XeVIjM2PturR85M7VhwVpmBbz3U hU8c5ssT6719/P6Wxq/PbMDbZPMV352DRdlvYi+RLtcL/8oHfV7s/7mChzVdBZmngDlT4og4+WtE 4rUe5o80AqZw2AlEtRM7EnuchBWffrUcmCS7diZSSLU0IVrq3IxnWg5O7fDpYy7D8iPlpZ2TbYFS STTKSek8sERfBPSZnj+8B/Z7PZbuewKimR4kezsRk20IQiF5YUSSSDe1Id2QcnRZDpUNwR/rQXoa 7qXmYM1JX8bqbBeaN28UegWEREHitcxAb3OD04KH5EPRm3kSnvjgaxEthpCcPEm2QQqVLSdYFh1p 0mXmHYsVckUKaSTkcOcUt0pwIzcGr7EZxfbJKCZizpSJPMVdLn9FBOvpyR5R2QVvR9+Bb4bXtxnh rk0I9/W7w6eKsSZkmlqRSSYcPtx7jTR4aRuoXyJrniEwYRDIp3vQw9UP0ZQcvj62hxUoL/ITGik5 CD45Am+Q7aHpzxX+jxne6w8a+tvrtqfcoWhTmDEgcyVkLWNK5vHSjnNDJbdwQ6AuEKj0fWFH5pX2 EZpXgnRTze1Dzg86jmtX3BXlx7AKsZhG6YXkwMOdnW+UlmuAEapzumczZGoeFob5fBo9PfLNJ3Nn c3vzTq1iG+m6KL3hvmNYl4GBASdM5aTXLO+Crb0KttXerk3sjyGwkwhw7tCLfU5/F2j/Gy55HQ/D /c5R+tHSikktJxLmKvDtl2BUyhdKIzRXVWju5LebjP3N3f2uiuF4AxpkixZ1ouupchROe14lviqy 5qHCn0TsTJ1Hib8adne7R/ZxdXxPh2q+ud0YkARMxTEYCqTXfObvWgR0XmKpwfbjvc6Nu5YjK23b CFQURJp29d9/iNOPOhN3u4BDceVdt+ATx83V6DH2c9iwNsjCUmyQz9y9qtdgBxOM+T37Pucpnm3C 3yCFYsq9p0WywI3gxpy/icrA8L4EJmrtd6Je7LC8KPSm0D0ejyPR0IJoWwdiDQ1OsK77ibMYTavp acEQbxaT2/Y2JFMpl9/RkHDGpSSMFy0V1FrBa2jDwNR56J61N7pmzkfXtJnINDY42szLdMF8pMO9 yngpHY1n+ljDJKRn7YueeQegZ/be6GttcmcrkG/lJdnajlhHOxIlPpQeafNqampyF++ZB/FGZCbv IedP7InO6fPQM2sO+to7kJGeRs26/hiohV5fjFyhlIs1YqBjFnqFp57Z+6Bv2gzkpZ7ki/XQssiL toP6tXTt2RAYDwjklt2G0xcswHHHyXX65VgmL0Gv+0lc+eFXIpZqQUdHB1paRLG44Fw8vKkicB9Y dksp33FYcNyHcdeqgaoPy+q65/HgD87FggXHuXJOPvd6rGM5cqnbgo8c43N48q5r8WHhTXnp6GhB Sqy0Tr/gB3hkXfUqZaVFn7R3lKbOCYP5meV/wrlvehNOOeUUHPvmj+BPy/ur6sGy88tvr8Z0mHUJ 4kE6Qed46V6GW35wMU5eEBI8UtIuLa5tYoLHK08+HaefXnOdfLJ8IC7bgr8gXbs3BEYTAddvB1bh tmsvx+lV47gDHW5eOQ7nXnkTntwkCw0C80EtTwPBeerD15bnj2UP3oILTj8uMD90uPnhuNMvxm2P rCuTIW1+A6hfe4aDV4w5S8yn7v4lPnb8i2W7tFZMmjRJ5r/hzTflgko33tbqfOgry3WuzafPg89d A3j4livd+E+1CH4yNzsMhd7F196Lbqmjw7vkr3r4Jpxz8qHyHZby00pdYqEF+PDl12PZQPX8q+XW +o7e1uoic/rW2o/5t6gL+XPvmEq71b5jlA/mX7f4QVx75QU4mf1H6tJSrrtfn5M//P/Z+w44qYrk /9qcl7gIBsCAktRTRAUkGP9nwIThVEzg6ZkQs+eJGI8z3InhDnNGPe78eYp4KgqoGJATFRAwAqKC 5LBs3p1/fd+b70y/tzO7s7uz7MzSPZ+eTtXVVdXd9fp1erfJa5/97Gk/yFd3fes97zoudPhTWGus BBojAbYfuBU6NrjmpJOcscGQEy7SscHWUPsiXK2+EOPYgLQRD9r2ivcelhEjzpVzLz5Xzrr8RYKo O1V+P/Jcufjcc0NjghMvul+WaVl+4+CLd/+OkSeUXZ8BzOr5b8ptF52om9NyHJ0MvdyuIEf6nXKJ /HP2MtXb6TpxY2JyT9XjnY7yMlPhb6p+Jr7moo/4retKAO3d0de6az4A62s7Ad017FiN96dZGW47 CaCO0O+qtUM6Vr+7UaNXYCEOFvXI57Ktp21XLywJMod158S8+rdaP7rO+qG7fNZLwcUGYJgvr8z9 pUXrj/STvnSf3k9L0PZlzhOW6/Px4+/WyUffrpUNxVVSUu6OQ1lH1o2/BOralBT/0lohRiwgwNDl IgPCsGYDJxw6KxYpkAY/XMKbeODH1QNIB17AooObhmXw9ALg/LjMcpEOfHjoAI744IdBmumauOAn 3YBBGHhAF/ACF/wwdJ2A/gFvNAsYf5qZD36UBRiUQ15JG+KtsRJIZgmUrlsmk+fPD7JwsKy6ZY5M 6DFAQqcUydz8iTL3p1tlf90hC1O57hcj30xZuGqCHLZjtFMQW+SLKRMlVMzMJ+SGW8+UImMngp+O dXd9L29e30MunkwCvO7kCRfL5AmT5F+LZ8spPQ1EBlijcS76QEZEwVm2foU89+GHoVK+W3+3HNVd vw1jmKaUe0qvQgNT2Lthwctyyr6nGoO/cBp8s16NLKi8Uyd4AW3ISmAbSmDDvBfklANGRm23Mn+m TBwLKzLx/Z/kisHmXeRhQitNPTXzXVlx+6EyfcIoGTlxZhjI8M2cPF5gL3zyf/LwefuHUjA+cG0o yvFkbP1aXrzmahn73CJvQjAUi75hRvA8ot9Z0XleMEv5hRW5//2fZcxgvUbSZyLpkFcv7SFjX/UB Iqj4xo8aIuNfnSg/vTJGdpQNMvX2UXLC+EjA8+XR60eqfV/+t+5h6dc+Aj4jKh715+cl1meMbFgg t5+/j/JlEFTLO19efRR2vJxw1zvyr2sP85x4iFbf4fjwuNGO52oJ10Y0QAIYGzxrjA2+X1/72evv C00Z5/z6xZsydap5/WyY2IWv/1MWhoPq2yo33DNGuvs+otcc/TtmnnScFW2845JeJbMfOE+GjI08 tlk49Qm5UO3/jRknnbd4mNWAdzLNTI2Hfm5O+kxard8rAZxc0Rd+T6RZ06bfA2QD20QCfK5i9zbm ZVJTMceUojdGuJs+twkRtpB6JYB64hxcCDgYxzkxxG/YuC6UDE+baK/4HqjmD7Cd+ft7wPm+S+LO y4Hual2EK6vQBTk9llcd0MUGZ8SauDQ3f202fwl2waGBMubLECa7YTj5jZMDpuLA7nvAcIIf+dDI EY84GISJj/AmXuADfsDhjky4iGM+5oWL0wV0gYMLA8SHNNICHICHy91lgAOMaUEjw8gLGNCJOBjQ gbhI+BAHw/xwAUs6iQc4aJCH+EiXiYPlm3goS9JEXNa1EkgGCbCf1KSF+4HoMsOAHrWWGkLs5Gr3 Q/+AqdYj+6bBiwD7kSfe6Wfafz1rAgXi7kQIQ/rpOGDn6HSEc82XU3tdLJ8XPyP75rp6kWmgpdE4 e18sX2x9TvbWwRX7N/o+TEaOe5Uby0lVPck0xDk7R3wyjZmXCOU6emrNbBmhiw2zWGjQ7TtkuLRf P1Xe984seKC+WVPsqRfy4wGyASuBOEsA/W/DvEelY//wHbGhIoYOleGyTqa+5224Y4fsLPLRKrn8 oKJQv+Nz2tuXJ8sBO0SehAqVEfQ8OuoA6bLzcrlxaGdn3AB8sNR/hL/h5KPprcOtrW/Yn0jnuv89 LEUHXlIbh8PzeuV5gSftiiE7Sc2HK2XMwZ088V5+H5WYdMirY+WSW/Pl/224Xy59wFuOB7kTUJzn HygbXzlfoJpNHYbkeNVfJD1c1zMmX/UsdCjkuuCZm+pZbHAYCf29ev0R8ueDVspNhxSF4qLVt3vl SvjZx3oMZbQeK4EYJMB2g/6TluUdg6Slu+9iSKN+8I6bYuzXurOU45x9ctx3IGfHcPXGGCgkyEbt V9hhHB6/xEM/R+rfMekq8GSMd6h/KCe4C56+NOpiA7mC++YDt7vBPdX5Bl5Xv5s6nngbq5+vGLCD W0bwP970eZDbQEQJQOaYUORHowmEPoiPsGpyaNzANOtuGwmwf7G0VK2n9JSA5GaoXtQFB0zdAAZ9 kn2dsNbddhKA/FEPeH5UVnk+fKPfvcH3cNyxF9/zd96trxIXHkvWpGc6eVtq/svVAe4JjYBO1ld6 piF0XlH5qtJvtMJAL2A+MhEM5U763TC+vaQngtQirL0kYehNBJnFkwbvyCyemLcTXOhM7FCclOci BNMoCoRpABsJHg8BWMDCJS5M0MMijHz+eBOWec3y4IdFPuIAPuCii3j6GW/Cw088dImLLvKRPuYF bcRLOikHhIELLtOQn37ggJ/5iZPlE491rQSSWQJ4AEYzv7vpYXn11X/Jg+NGS185Q3Zol+Y8GJEH H0j0GncizxvnDjLdh6yZgrzcaRx2TQjTf9m9/5L53/4kPy2dL1PuGWUmqX+yPDXtO1+cW26tSCPi snumyILvfo6C8wXF+b0BXZfX1W+E4ICCYb/b8HKr5K2Jl3kWG/pe9pQsWrlBPp72gkz7eIMsmjFJ hvgKuve9L2TRl1/K0+f2dQaYvmQbtBJoXgmULZArfIsNQy57ROYvXSvF06bJi9M+kbVL58m9o/FC EzZjB06UH8PBkK8uPTX6zskyZ/G38tNPS2XOtPtr9YVbj7pdljjXfPh1Vgi9x3PxX16QL77+UVYs /TJmfeMgAM++xQbwvHD5+iDPH8u6ZfPknlFenq8cVJvnuvgd99QbsnjpT/LtvLflpuM8pMtrt17g WWz43U1PybzvlsnSb+fJk9f4gS+Qt7/Xb39FMnGqv7r4QLF4xrzyypTQM6aonTs5i3zmhXl9h18r k6d/KktXrtHvUei3hTaskaVfzpBxw73E3/K3V2R9Hc80E9qkzfSbMNZvJRCLBNz3guiQaF+00aBi HeewrfY98x/y5tQ35e2335Dbf9fTQLuX3Prca/LW66/L9OnT5d1335T3P54ke+eF9V+gdH5c9DNp MQr3eBs+3nGzB1a/KWeP9m06GXKZvPLBIlm5cqUs+Oi/csupfUJl7RlabAhFOR4PfU3Qz8u9aCVe 9PnQ2mAdEtDX9VAfgt80mKzDL9FMuX5Tcvwj/5Uzb3pOzqrDTpsd+WRlovFTFz1mX9M1BknXv4Ls NMdqxdn3kLqEt43TMMHtf4fHJgxnw1xwUQL12WPkI/LdvE9l9uzZ8um87+SF0X0Soh5BGyftw6Lj VVGeVYhwcgL4QDf7CV2QZfoTgMxWR4I94dDIKsXAFgaT4zCYCIdhg8UkOQxdJ6B/mDiH4cqlE9A/ wvld4AVOWnRu0wCek+9w/flJJ12mo3zSShd4iQtx9COe+cgn4mBID9KJBy79LpSbn/jg+vEwP+SD vPhOg2mQbuan3BFnjZVAskmA/QNXpsFfXlH7Q1Hg6Y7XvpTfH9TZafsDBw6Ts6/GCaNqPfHkvrT6 81XrbgnqFrNvuFef6a4Dj/rQOz21fHzzmLClZeb0EqV6iDz50XMyvEd+EHcnGXL2n2VmRqUcOvY5 AskDz78vt5y0mxQE+yT4Ai2V+lH62sbFeezuuUFd4eKclVklw654NgR+/3OzZNzxXaWNTw8qap9x dQ71ERKrvMwG4RtWbtugfq8qnifP/SW8w0R6j5cpNx8r7WvKpbi4zOGzcM/hMmnqaukzfHyItgVL qmT0abvryS53NwsSIGu//gtlsB4rgThIgP1g4b8f0qXAsDnkhiky5ZrD0DmcCWOn3+fsKOdMeEM6 VP1Wzn+GL9x/kRc/vEKuG+juUufViX5942I+RJ5470k5rmeb0HO/6/6nyZQvOskpvzlDZoeKf1xe /+RmuXJgx+BLCvpsKNHwHCyPzHpGjlN94z73d5DBI++sU98ADgZ8L/n3g/KCgW3wH/8tL44dLGmB Cu2rFW5KNnieJkU1x8h5T38VhL5LeR4rVx/U3uEjul4+Rl769GE5tFuWC5e9t1z62MeyucsAecAo l95b/vOlXDzAPdkhetHSMdc8JE9s+UFGP0JZi7wya7Gc0G3v0HiSeZtaf9cc3MGhEXLxfy+DZfAZ g3DG0CNk5FX6bZoMXWgIXufZoe+RcvrpPeTEKy6QI3q4dVdT47Yf5Mnu1EsunfSBLJ86WEKa+7X/ ypJNo+TA/PAYEbDWWAnEUwIct9SFE/2Y+pDwFXWMSeof57ynY5Juok3bee4H8naRPr9p4/SX0j67 a+ySIDm7y2/27iG75aU737nDMx8n4VNV91ZofwQtX7/89ybpZ7N/N3WcdfMJ3YTjHcgMZu4LDxv7 ajVi0M16Lecl0lm9gGnfbR+54L63ZL8B4+SEq56Sb5yTDchZ2wAe48El+kxqrH5+6aOr5BrVz6zH eNJXm2Ib45cA6hA2ResR1m8CmAcIPov9aS0ZzspIlwtPGiiX3v1vWb2+OCopD035QNMCcuwh4UW0 qMAJnoDFhjw97ZWtJ7yG7VXo9Jm8LPdK7QQnvdWSh74DAz2IZxLGWP5nUWV5mXOjCca0mOdCnkpd MGvXbXdpE3xuBDRflaZDD9ICL/Ui/M1hSD9ohx83r1RXl0uFRxXoPAPoq3I3N4MPjs+bm75oPEei m7fGIM05qaj01ug35Gq037Q0vdH4SPZ49y0t2blIAPrZ6f1uNNL8cAz74RGPxk8Xg1bTmmnEATea IQzyAQ/xIkyLOKQxDJf5/HgZDxgTn0kjcbEsuH5jphGXiYM00PXnt2ErgWSTAB+CcKv1Ae43Ix96 T0YdUOQMTjBAocXDPuTH0WbDBPBxMB8usxzvgYjwTgTixIfFvGaQvPi/l+SY3XKCD2X3o2N4QO95 0gVyjgm8aZNUKC8oj9bB66NH31odnEfvmu3wARgMvGB7nDhaRvpwVio+wJAPJJt+hgFD48jHCLvx jSuXZW8hcnXH3HaStNM6Ac3uYEWPxqo/b+8jxLzI5dc1G5x0ysNAYb1WAs0qgUDgO3n83MeNMs6T 2/8wRPCygjYNy35XXZ0hR195vZiv2S9M/yIEByRow7X1VG957OPn5Jg9C5y+HMan+qpoiEyYOMIo X+RP//nEmWwjPk+iEzhQHtdvyxzVzT0yjr4FnOjPdekb4gHPj51j8nyu3HHxEEkN8su+6upPl+fe zKwueQavkE9tfqFDHpWhu2SE+HVx7ixnPnmBgcn13vzyfGexwSvvNDny3Es9sMWb3Sszzch41R95 8e+kQ1l4xpzfr2NID4MXyIb0wu108Hny8MM3yVF7dQqlEQ6uUz8pu8lpt//WIF9vxNW8KBuGrgFg vVYCcZcA2lmwyYVxO3HhMUT0fh3jOGfjRuH2EFePhD96Xl5mrqBu1QkZY6wGfRIcx4G4QOB7eexc U1c1Tj+zf0fWVS9JbOOszc7YjUJzcS6T/7t6KqMc97H7LpAi37gHOqDnsTfI6xMv9MAqh07YrRPX X1Oj+tnDc0P18+eOLoknfSAS+KxpiAQgL6/MIELOBySiOHfq1Eb+ft0p0qk9lgojm026eeihKbNl 2mxuQogMl8ixnF+Bm5Gmt0Ok4YRDhmM59UKYRObDpK2qqkw3yGyQDRvU6slK6l8TpjH+qrItLk7F WxYHpA3FF+lZhO9s0CCd+tPVee64HfGwsRiTpg1bopykjQ1RSFbFKixTZ3rnFVQzBOmOBe22hjHp TtcZcPQPynhb07K9lWcXHJpY45gAjzZBzslxPoThxgrvh8PO/7osJ+eZj2WSPYYJh5VTWHxTwbQs g+mEp0s8dFke4YmLePwu8TAfXcb74f1hlsPyyZ91rQSSQQJ8sHHAwAmb0tLgzlsycfy9cuUROzi7 kIuLi6WsrEzKy3Unge4oMN0SX76qCheGE0IsB3mAQ99/DaMT5hpPfMBdWual44pn/ir9CktCdGzd ulVgQdOW0nzRza9h8/4MWbLRnbDiizVwlpV7T02YOJ1rOXQASbxbywul7xFhlPL+TFm0ITxBSnn5 d/PV6L3ILBMueCotj85LTOWud+/SBL4KPYGSa5DVSb9VAZpLSkpCLvybN+vpLFwrEDTVlWWu3FUO mJhj/dMlnHWtBOIhAbYr9JOyH+bJgwbSgTeeLF2rw/2X7Rft1ukPefvKWUeFMyyc9aWsVTxu+69w dE+Z7wTUH57QyfcOlY4+MPE5+kH7def+R4p5yYh88ZNsMRY8wqW5vosf+Yv0b6+0q64qLS0N6Rrq mz4e3RDWN+CXPJunDAb88SSHZ+QP6RjqL6WvOP83cpahwxbOmi9rlD7oLUd3+fil7jLxkde8rn09 7Bw89iU59zd5jmw2b96sumFziIbS/C5isjJ15hzZoOWCB8gbuqL0+8+aXH/gBbgcefr0oQy/J/SM Qf2DD8DBmnQgP58fTEfdmBaylQzzVKqeqFAdjOcP2yRca6wE4ikBti20M/QbtNtId2KjDSMNfdpt y9HHJLX6to5zPHrng1mySMcGwMXxFfVFVbXZxrUP6HgM5dGSDrilqp8fMoQx4EZXV6EvkQbo5rr0 c139m7qKYx24IR1Ya5w1w+GJ9DmyXPmNfGLQJwPulP3alYdwgEbqAOiFnYedJzcMNTOEZYF6gqzK 9Po+85nUUP28YOZ8WR0cS1X+8rV8bBbXYPrCmfE+aU1sEkBdQlywtXR6ik4pwQZNor2nt/ZFB1Pe 8GNeBXMmmEeBizDmXEw41lUiuWhXq7/7RJ66/0Y58bB9lf4cKSxsL+3bqy0slIyUfeXEi26T1z77 uXYbNBgpXfamjNx3XzlMcRx20VOyWvEC97JPXpMbRx6m3wIsdHEq3pyMFDls5G3y5vzVBgavN174 QAMs9GxNteelXL9/EB4HIh22fPl0ufKEE+Tkk0+WYSddItOXl9TJd6D0Z3nzqbtlJGRn8Ni+MEdS 9jlUrrz/37J4vfcZ6OXUDTn1MP9Nue2iEyVF66BDhw6ObVeQI/1OuUT+OXuZPlfTdWOOmVtvTgiO x8mnmZoo/nRdaNilfbZ0VasHfyRNv3WiQq1TrolCe7LSoWK2JpkkgAdFMpim0tnU/MkgI0ujlQBf WP27024YOViyMRgJDg4pKTzA0TeQD37/rlWcUEC8acywZjOM+xJYo2cIgRNw1Z4XZpF2+elOWchE mDC+XNnjwMNFpr8bxKkfkXcGSAFnYItIZ0Dlo6dtXpoTT3yAo7+6Olt6HKQ43wnjTFOcgYB7FDjE t+8kBnaFMA34XLl65dDgcoOTGA4+XakxD2J/9/1qqd59F0dmkIdbnu46KV4qX5jXCmga0sMyAzZr rASaVwJobyVr13oKWb/xB1n0bYpUloRfNMx2mZFRJis2G1kK9GOr2gdqgvoGbdyvpzq3za5DP+jN Te176M54vWTk6yDe2StktX7HYeegntKeYRQo0j4/09OPmQg9kpKSU0s3QN9Ap0F/wPh53rBxqSz6 JkPKt5Y76Sa/iMjMVJ63OEnun/KMqyKgJgGLD8mZxtSHZjzok7Zd5TiNfD2YkNfOPQWBIHCZNjWj jfRWubxDuWxydQhhkKd03To4IdPo+lMMkfThDWcPcZ8xKjtMQqBs05hh5CdtTry+UG4t36oTju4i akZ2iqxcyqtkgCXMj4nT+q0EmlMCkXQUd4ya7bmufs2xSBhexzm+MYmrd8I7I9k36uONcKAzsq5K lUrtUzRhGnAdbxT9rMCR+ndDxzs4kQQ84B+2+OdF8gEJUffgI/pKvuq5akNPAN7kKd2rQkI6hTAl a7zPpMboZ+eZpPRsWfGVcV1fY+gLj8tMORssW28ECeBJ68hL24E5G4E24zw3NR3+RDVcdKjreiWe dAAPyXi9EuUP1/EH64MbPBO1bhy6NiyQ28/fR8a/WheV8+XVR2HHywl3vSP/vu5wiTSZWblumUye P99FNPNdWXH7oTJ9wigZOXFmROQzJ48X2Auf+kweOW//WjDxwEddQ53oHwNj7OQ3ZetXyHMffhiK /m793XJU97xQ2PRsmPeCjOh3lkTmUCEXzJKJY2FF7n//ZxkzeEczu+GvktkPnCdDxk424sLehVOf kAvV/t+YcdLZHEM7ILV5COdseR9kDw2Fb5vUqD9Dx79p2kdq10XL09qaKIjUR1sTf9ucFyr6+gqO N1x95fnTYy3fny9auKn4mpo/Gl023kogESWABx5f1uD670avrizVnalZzukjDhLpoq9wsOK/l7sG O/x09xy+gQIYGJaFSTHvZw2wKxA7alOdHQmA8+MrqSjRXXruKSjg4sQUcDk0pGYjOmjcb0Lg7kYn TfG5Ox28k3YlOlFVXa13GetDHrtuYCADGNCekpbj+N0/vb/S2dHm7soBHMqu8F4a6RzhRDzyw8Bf 7d12IfWVKz5eKvQuzfJyl64KFZzJ6dOXPyYnf3ar9CxwJ+pQJ6Dto5ee8Az0OhTleV7iXZ4S+4WM NFo3+SSANoi+5+z0FW+/W/KPsTL8Hw3gqTq40z+ob9Cn/HqK+gH6Bn0AO+hQPmDhVlbmSdFOWiYn 1mWxrNpcLjvquxLS/Qum5fqJYsTDmGOCkM7z9VH3GzThRdYy/baAaZZMulKOnWTG1OPX/M4uaIe2 2nqZ/OIkJ2kCRocXvcvWlHi1LnJAH0XU2xW5UoT3PMol4JZbrfoQeJ3d2L6LAxpef+6pKmhE8OQ/ FVZZXqzlZDv0gR/qY7h+g7jqzcvl3ddfkxlvz5IX3vbsLfaDa1h1sXPaLryYzXqNAGyjrASaJAG0 LVjonUg7RtH+2a6hI6PpMfQDGMASn9NuPXoHZWChM7xTmOMY7bqGca+Z5Q5j7jZG/3bGManu2IIZ 4t2/6xvv+MdZOJFUXe1eswv9U6b8meaAXQsd+YJ+8EI+wAv8kQxkh3TgA0y56jnTNFg/6zMJpyoy tfx40Ee6QadTzyZx1h9dAnp1q3aCCOloM+F+EQEgIaJa+6IDx2HpeuoQ70Hl5W7/g15L02uWkA7D 9t/SlcK+B3fBs+PqWWzwUvvq9UfInw9eJTcdUhTih/hq0syJ78lywA6RJ8+9GEUePb+f7LjzjzLu MAxewybe+ECnfwwMfYl4WD6zMnLc+iIlqVp/SEP9wZLfdf97WIoOvIRgYXfoUBku62XqewvCceq7 YshOUvPhSrliwA6eeOBb8PSlURcbTOA3H7jdDeJkv7PZztX54CNRDWSWnZEq+3d1F22ys9IkQ+9X StV4a5pPAt4RRfOVYzFbCVgJWAlYCfgkwIGFf9BBMA4oMECExSCDgxDAcKBBeOJjvOk6aQR03NoD A/8OZi3AKcNPB8PmcE6pAUEemkiPWaxChILgBXwRn8mbC+TiI56Qa+AAHAY35gCHg7ZQQeqpr1zQ EDZh2Ti4M/eSP/z1pHCy/FOO73epvDJnsazTO51XLp0v/5l4uVzwwCwDZpicMaRbaBBsJFhvnCSw 9pv5cu8hRI8VAABAAElEQVRdz8tpl/5DBo6632OPvvoxuebvs+TL1RVxKi150KDNLvvko6YRvFyv 1gliYH+C6zER9AMm2Nif9aCypLc3c+whbTPCL1RmCvz6+uR5kQIuUz+ENQegw/rG6aNK2/I59U2E I18dZrkuEige6BmYhupDD2bjYlu/noN8PLzoiQ/KGGXD3/T60+v1FA/xwvUYJYD1ZNIHP62bXi2f Txkvu/QcIBdcMyGGxQa3FEz+0lCeDFvXSiBeEmDbgutYb8/SYjw9zSm21ngrgh6LrncwzHHLYv+h 65+wSEtz9RdwcVGCfC+Lg66qq3/XN94hHa7r8oM+y35LuRKufdvckL4AP7SmvvcMoZhRXcpr+aee S5oMiBi9qp+rVPYOnT591hT6YizdggUlwPo0BWL2MtNvwiSSn4sOrfWbDtpNnN3bVToO2VxaJVtw 7z5GWNE6aYJUjrtlzCWm7/BrZfL0T2XpyjXutZ8b1sjSL2fIuOFeYsf/9f9kPRj2Gb8OM5NH3zlZ 5iz+Vn76aanMmXa/DDET1X/LkbfLEg6Ag2nxwGfiMP2+4usJRqjHsgVyhW+xYchlj8jC5euleNo0 eXHax7Ju2Ty5Z5T36s8rB02U5b7SAqvflLNHP+qNHXKZvPLBIlm5cqUs+Oi/csupfULpe4YWG0JR Ceth+0/TcW5OZpqz8JCZrs8zfGXdmmaVgD3h0KzitcitBKwErARqSwADDdP6IdLSM5zTDfn5+c6L XXa2uxOVD0vcmQsTYYxVa0CJcjDZ5N/x7+TX+EAgvEsCE36mScvIdE5L5Obmhib+gA87BvHS533B xs5q3Ble40xYhfkzMWL3YJqDEy+q3BkNWODDfcXeBz9OTeCuZHdHMfiIxEvAd5WUy7N3ANqwcpUe 57SIKw/s0Cso8OITeVeuP/tdL3NG6IIH/ih9813ZcuIUE3msQwPUehshgarV8+Xsv8yUTVHybtpQ Ih999qXaYnn5yeOkSxS41hCN9g7D/oH22m6Pnh7W+o++ST8QXKR9NLxDFW0RebATn3mRSb8YJTsd OExydNdrhbZZGKQHi3HC+EvPzBLoJuoHtG8YTEahP9fUbJFqz3fqvpbVxZXStVCPMis+v6G+od4D feAtmr5x70h39QngCnfFm0/Y9L9gnJyzbzvtc67+IH2QD/kGNMpJUbl0H3ikZCvPNXrncST6TH7Z lyl7fHjbY/QFBncnQxaQEcqgnHFFnF4hGzZKO3ZNg0/AQXbt9ugVTldfQ+tvx/5DJV/5rFZ84Lfa WAABYuySA13QTaw/6mPEwUAGC5+7So4e86QTNv9+O+Js2b37LlKgC0hVqVUy78/3yowQgMsP8kNO kBHlFAKxHiuBOEgA/YUGbcy/mMDrFgkTqV9T77AfACdwRdM7OBlaUxNeDOUJIeySDJtUydSTX9nZ 7jiHE/RIx/itQxP1c739u4HjLJxI4jgLesr/LYx5X/0q5+7b0dFn1BPghfKsrq7w6jQkOvURXmBu 00T9vOugoxz9jGcSvqtlmkbRZyKw/nolQD2eqvedp+DOc58JaJuDTRbDRYfWcr0SdaGjv3R5YUtZ tWzSKzTf+uIXSdeTDacP7CZZmYn3DsKxAfROB/2I3+mn7yEnXnGBHNGjo6NfavTkKb5BA5PdqZdc OukDWT51sDzLhvbaf2XxxlEyoI3b9jB+Ak7/STYX/BB54r0n5biebUJjkq77nyZTvugkp/zmDOOa tsfk1dk3yx6HdHLg4oLvw/Fy9aCiED6SX5+rrPhMeP4ACdDBS15+SF4woAb/8d/y4tjBkhao0G8C BTddZe8o50yYJkU1x8h5T/PD6HfJSx9dJdcc1N4ZewLF3BceFs9ZiEE3yxdTLpHOmgY5tO+2j1xw 31uy34BxcsJVT8k3zskGo/AE9XIsivEtn1sgFfGwiEffYT9KUDaSliy74JC0VWcJtxKwEmitEkjR hx9eUPEQ5IsqHoJ8YEZ7KGIwYD5IETaNL+gkmTC4z9A0LNOkBfAYGEZ6KKPsQMB86TaxuX7w5n/A Y4AIEwknyoNFmkmriy38b6aZfkI0tFxTjjUb5sjNF/6HqOpx95Tr/v5XGTm4i8NnJJ7qQWCTY5BA 2dr1URcbvNnXyM/6Tdsuka889YK2khDabqYuVppmr16DZNiwbo4+wUQ42iUsYDEBBpf9GhNKnHQ2 cdTyB3US9QPyoO8hDJOSUiKrzJeRgwfIbsHrlGrh0gjqO+oH4AE+0uXNE9ZVoB1wWQU+nnsOkqFD d3Qm1IkTOIAPOgcfc6WuQHp+vttIiE9Reo2PX8rPoVMXGMJTn8q7/kx+AAv5oFz4PcA6OYAyaQCT medtsA2tP8qOOP0uaKBMAAvLMGFTf31HRv/Bu9hw0QNT5aqT+0uhXldAOaL9DM1dIjNu4hcswi/E lC9xWtdKIJ4SMNuX6W9IGewL7APsO/XpHacfa0H+fsOyzTEHywCNsJl+XdVA/UwaWZbfNcvmREpd 4yzkhw4CL3BNfYS0ksqy0DOD+AiDME6zmfrPVHDkuen6OdeRHfjwLyw1hT7WI/i0pj4JmA9F04/n PZ5r3lZQH7aWTm9tiw6mPLHJoFKvVCrWhYd0fV773+9M2Jb2U3d3HjhaHu6HxU93PIp4bJiAIUxa 2m5y2u2/lWfHvRkkOyDpCkd9RNhaJ1Sltzz28XNyTPdsZxxm6sOUoiEyYeIIGTz25SBOkRv/M0cu H3is830I4G4yvlfmyBjFF+uSHPmlS8IQpnXjvpfHznmcyeqeK3dcPES/waZ60pAL+mdKSoYcfeX1 0vvpc2RRMMcL0z+Xqw88zAkFAsvl/66eauASeey+C6RIdS5O/8JAFii/57E3yOupGXLcWPM0RFgn +On2IG3BAJ5xSr6elnOJyNBNl+bzqgVJa9VF2wWHVl29ljkrASuBRJdApIdyut4ljEk/7kDlneHg BQ9794EZfrCTx6yMulR6/cMc/7sC6EDZoIUv46AXNGAQ6D2NEKYHMJH4Ap24ZoATmnAxCMLADxZl eXcJuoNMpBFnNLyUAVx3YOV98WlYucpjkCbgWzlvpkyHxzGnyFPTzpfU7/8nc774WlZuKFXacqT9 rl1l316/kf0P2FvaZ7mTEJjYxcs4ZAdrTRwlUFdT9xXj23vuS209QeelSNst3Br90LlpFn+7QvvY zk4/Qlt0JgcUwOxX7DdmHPyIj9Tv0jNynD6LfgucaO+ER5/dunSxPGQuOOjOfme3vcJGxBfUN9B7 wEc9F1nfhGnHxCDwVeqLtWm+/v4Xje/iTIwDF+iDAW3ASQP+kG6aiPRpfuCgPqRcgC+1UhdxDASY 8KOe4wkHh3eFrahI15uuDaMntEwdB3918PsxhGps/TG/38Wubj5fKG+2C/K1ad2PstDIOOKON/Qo /X4qO/0ekH7XBvxAjtgJXloalqfWjHNCjDKGLCPJ00BtvVYC20QCkdphw8Y5Yb1DnYH+Apuhu4jD RhcYHX2R7uhIwrJP6OdqPKap/VuL95iGjXdcntCfwQdo9E/oz1iyUgIYC+p4BnoN/ECWLix0gepA k32DGuAFbGP1s4EqpEdUo5jR0hT6gAh8WxODBFTsGBunqPVVgU5uYpyQfHJsLYsO1G1wYav0JBYs jTOu0HqjLmrpNk96oUMcelVPgEaeLIOLeIzvYAjv0K3fpwgbHYPopofqPPd9EvDAWVbmVbJ/eOJR GdqhUnf8uzIBDAzxdu5/pPSUl2UJEX/xo2xWGrCNJT74VsgWpa0gqGNZjMdVfkkXdWx5hZePGtSr yooLv+XLPpMHDCQD/niSdK3eKsX67Q4Y4iNIev5v5KwjRf403Y1ZMHO+rL72EGkPnb76a/FcTDrg TtmvXbls3erSBVlB/nBRPzsPO09uGPqo/OU9Yg+7Ld2+SAnpgAsLueJ7lis34bkk0q2Tzm/gGw56 OkuTrWkmCUQZHjRTaRatlYCVgJWAlYBHAnwYmpEpKeFTAHxAcpAIuEh5ED/zfz/AcQwHUQjAv27O 8/LH6DcARcEZ3gVr0gE/rVua998s25uitDsP9fCDH3wRl+P3TNvFb6KqYeV6qV6z9NtwRP/dpHe3 btL/iFPlmpvukL/97W9q75A/XfZ7OfKQfZzFBvIDN5Z6CyO3PiuBpksA/S+ne2/pb6D67JH/yg+6 pQdpfst2ynbLPmlkj6gfbrtukvxY7V7RhDy0xPPN+/82Uche++0k3n37nmQNNEzf+PnI6dpTDjRQ zp00zeGZUYRHmDSavBMuulubPuIx+7mb3wtLuLBbuxS8GJLGnO69mlx/LAsl+V+k3JcrVw9zcceE R56f5n0IJ2QOGtjLoQ+TAqAVFn5rrASSRQJo47WNt6/69VjkPOGJKn+/cfHrVWa1C3Ji0MfjoZ8j lxssvQnjLNCX231f/dCoYaa8K9+WR9YXkNeaj5+WcTMM+AjeeOlnhz691uM4s4wG0xduB9Hq10Rv /UEJqNggOUd6YRF6xgfJKE8uOrSmbzpwLIGag5/G9DMuEVzSy7EFwzq7rhPem2TdunWydu1a2bhl rX43L7QsoKSHJ8ORh/n9JxI6t80OjVkAQ1iWU9W+hxy1lyGJD1bIqnJ3rAOYKt9Yp+H4fpRffRuB jNJqeUmXf/GX1wQyvWTNWk/eDRuXyqJvFsmCBQscu3DhQjHtokULZIV7Q5WbryBDT0O447nNK74y rpUSOfiIvpKvfGOch/JgKF+E4U8PNy1NDb+zE97JlEB/0E84+YErxzbrt02qqkGzLqL4V1ATiObW QIpdcGgNtWh5sBKwEkhqCfjfgXG/NncMY0ctX4Dp8kUzPcM7fffWDc/LotLwA59CWfXJo9L3xHEM RnQjDQ5SdTcbdlHQgiZYGuN9w4kCDhOPSyehXRe8+vEBJ+IiGeI03Uhw9cU1rFyXD5aZnmlgn3u3 XDb+cZmp3weYv2iRLP72W1m6dIX8tGqVbN68WUp0QAleUG+w8KPeWGdwrbESaE4JOO02t5f87hSz lFdk4rOfOf2T7RptEW2T/Ro7V2FxPQZc58SRtmG2XROb418ySQYf+4B8X+rtv8CXunqmXD/uHU+W 807YT++UDb+d+PsC9Z5fPxBJrZ7j0zeS11POPI3QcF+W+5+b5+EZvJNf9E/w6J5AcHciI47p/q4a TR+68NrHjaJT9CQX5UY9QLyOPjBgTS/oc17ocnrK6U2oP55aYP16v7ejE0Z6BRToMfUuwoDHy6Wz g67DjiZpsnTZSn3x3+pcRYXdbYABbPmKWXLPnW94YNnG4FpjJZBIEoi1X5Nms18zDi71F/t5VWWJ kfyuzPl2c0gHEBYATt9oon6ut38r0X496u/vBrG1dGQgs7sM9szovya3PfWphx/qs18/fVz6nX6n iU79YalRFzRFP6fq1R3ghzoqJXvXJtLnI9cGY5eAnnDTYw5heN0gpQ+UUJj9IRSRJJ7WsujA5ze+ 2+dY52od90QintnmhHEiPp8xBgkUr5B3X35UbvrDWbJn796y3379ZeDAgTJo0CA5sN9A+f0jXxut Sq/70W/QYEwCC/6ccYnvOy8lFSVOOtsn9SN1c2VlnhTtZKCVxfLr5gpnvINrI/3fhGg4vkWySvFx 3OTqRbM81099CTic1sBpUtMEgvyR3/KAd2l7yaQr5dj/d6ycfPLJjh0xYoSYdvjws+ThTwyM1ZV6 QrXUuVq1rCbcjwFxwK6FjixBU2gsabzPGlhCXsqTfIQSWtjDegcZ5ZUB+ejbdfLhN2tlg554KdGF JdBrTfNJwNuymq8ci9lKwErASsBKIFYJ6BsxH9p1Zcna7SC53NyRIZPlsJF/ky9WFjsPz6rilTL9 H5fL3sP/VBcaJ62+8sx0DDzMcL3IfQDIa+an33HD76m+XE0PNrbc7gfq+VPDzH15olx69hly4nHH yTFHHSWHHz5UhupA+OCDD5b+++0tex5/ifz12RnyS4W769tfroHKeq0EmkkCWTLoDO8i48z7zpfR D7whKza4HydGP+ZLRPmm1fL5rCly3bl7Sc+el8pXpeFFsjoJXHyv9Otyhvxz7g9S5gBWyYovX5Wz +5wWPpqO+D2vkmH4gENdxtAL1AkAj13fKM9njveUMGviKDl/4rQQz8BLnss2/Sqfv/cvufacHtK7 9+UOz5QJ3KYas9+b/Jh+swzvC4/y8rum1R95Mcsw/UgnjaTJpKFwB8/bt0wa9Rd5b9mW0OSkvrbJ N7OflwOPu0Lmmoit30ogSSXAfgDy2T+isWL2FcAU9ejjAb1TT4DN12sb9LZoWfPD5zJt2oeyMTQ3 1HT9XF//Zt8mUeTNcesdZ+VJ/+G/Z1bH/eiOk+SaZz6QNa6il7LiH2XafaNl3+Nv8sBFDzROP193 zp7Sp4+rn7Hg4Bql77h40xedcptiSAATc610cq41LDpAL8Hy/v5U3VwAy53xRk0mnDclpVrm/fNm 2aXnALngmgnywtsfx0QjFhnIN13EeUxQLtSLXIBlGBtt0tubOfaQNhnhiWj/iQn0AZTF/PXj6yHt MsN0miXV5ddSPMl+Xpd/aq4eeEBjCywv1+8Z6DWYunnEz2P7trke/sCjn08dUieVQZ1V6yJcmW4O LKtQf0Dr2JFxkjGSVFLXDRBJRq8l10rASsBKoNVLQKfjQw95DmZMly+aKSk7yPDfny4PXvPPsEw+ vEcO6XFPOBzV5w6W8PCNZkw6/DCgx9jE5k+OHjYmFU2gEH9mZDz9jSiXssnY9SSZ9ufZcuyN3o9p RSVvyTvyj1thn5Up81+Rk3qF78yPmscmWAnESQLoS9ARuT1Olr+PekkufTJ8Jdinj10vh6uVXgNl xAG769dA18iiRW/K4sVm4XqqKTdPd5S6k+58wTEhvP7X5fyhar2RntDNt4+QjsEFDtDmvqh5QKD1 QnrPmxLcTVzP+wD4zt/rVOX5BQ/Pcx69Vo5U6/DcbzeR0rUReNY+mpWtJzvE2QXn0OdTcCZ9IX0V 1CtOmkG0P91IcryaLaqhfs/bs/H1l5aTqyeswnftgh6PId2GC55hnRdPfflM3/EAGa2ZnghlfE0u OPI1OfKMi6Vv23L5eNKTEu1Vt1Z5IRzWYyWQWBIw+7WfMqcd+7qOH4bhTnvtL9j/Edp7u/ghvaLj ISarO1xmrxoge2ifa6p+jrV/G4U73pBe8icYYcJ0OuRMuWrPx+Rvxnd4nr12hDyrqrR+Ex5XUhfA bYp+TsvOUf0c1lE7DG4KffVzYCEiSECfDylp2mPUYsIVJqDXd8E69ax1nOyGiw6X3v1vWb2+OCI7 m4rL5KEps520Yw/xLjRGzLANIvHsNk2qfhsqPUWvR8vQU6y64ICqAQzGc9A/iWKoH3ASdP4zY+Xo MeERB2n87YizZffuu0hBhp7USK2SeX++V8I3uOmYJXhyA3xh/OKOWZnbddMz3e8i5ubmhk5KIQUT 6G6eLVIdXEx1c3wtq4srpVubdAefGxf+byy+HjkZDpL6xtXh8Zh34SSgk+U4/QC6Ydrsuqfj8q// BePknH3baX1nOn2Sdc3TLfwmBuSeUpUiuw46SrLL9YSIyq7Cdypk3le/yrn7dnTKwqln1hVoh6mu rhCogmQwlDflyjaCq7JgEcZYgHJNBp6SiUa74JBMtWVptRKwErASUAk4A4XgwL7rcVfLHbP+KTe9 Xrdoel76uPxtyEo55vTwrtnKurN4UjnQQKRZvgkU2rxnRkbx+/FFAYt6D3I0+PriYy3XK5vVMvdj 72JDj6FHy775qbKupERS1RbLRpkzJzTVECTjAzltn7/I95UTpFt9hNl0K4E4SYD9MyUlXQaNeUbu y7pRrpw0y4t98UfystrIJl/ydLIaLyp8iaVrwp8wdqyUTpwob5uREfyXPvyGnNq70KM3zH4YIUvo xQZp5McPxz5KXKAXV2+A54nK89hG8Ay1avLtL7OusHmhCuBIVyR/hQ8RdCfh4boviWky8PKntf7+ 1OD6y8/E6QV3goF4fUVGDYZeyDJ3k8un3iNPDPfOME5/cZJM9+U+9Nj+MnNa+JwD68YHZoNWAgkt AbOvwG+GSXiktu3Ate8vV1+4l1z4qH8cwJyuS7xN0c+x9m+TftPvpQhnMCKZTnL+U5Plm0FnST3D S+k5epLcfdRaOb6O8WXT9HOB5KlOS011r/Zwn0fxpS+SBGxcBAlgYpuLDbozGJN0+Lm7hCPAJ2FU a1h00DUGSde/gmzdlY6A1lmkcVzCVM/Kt2XURd7FhosemCpXndxfCtPcj0djYQDXGw3NXSIzQi+9 Ll8ct0TlJziuwoQydBGuVEIeTjCnpJTIKmNxVQ4eIDiUG56o9mFuKL4BA6R7jnvCwYepUUHym1WQ 78m/V89BMnTojoKFFVfnuotLWGiA/Mp1cYHtAOn5+blO2F108S5alVSWOc9APDsgL7iQBwzCOBWi Lcsw4VBdzxsjwzb3Um4omHII+8P0b3PCWnmBibPE2coFbdmzErASsBKIJoGMDO+AIT8jtrVgDJTS 0trJ8br7ftL1IyOj7zVC7n7+bXl1zGBpr7tDwmY35wPH4bDojtjY6cCDOsP8toF0lJwIZKen+3A6 gxSzVK+/MTgLIuBMT9eRomHyI8AYyRF54cDki8eulluM9Yajb3xaXtIPRd88YYI88MAD8tDTT8sz z7wq33+9SGa9MlF+ayKWe+XVee41JJ5oG7ASiLME8PLAlyn43e8wtJVDL5oo77x0v1x0/EF1lthn 8Gly630vyhfLH5S+ue51S8CDF4dILw/7Hn623P+/V+XWkQMj4t1r+IXy5NSP5eJDunrowosK8NbS DXXovdr6poPu3HPpAj5a7JJLTc2XQ/9wv8yY8qBcOPzAiLQxss8hp8qtf3tBPl/2oOyd5x4XB22w DdGHqj0ll0jVzc13X2aNKI830wTeNV+yNRUyNusP97RnZbWLS/3V4iWCPqS+wwul+/JZIwW9T5ZP 3npaRh/q3UUXYmbAmXLP8+/Jg3fdJmeFIvV0Rcgf9jSkvsO5rM9KIHYJ1G5jtVtibZgIA5dgkbX1 TkfJDd7qQ71IHYlLAwZf+azcf+UpkQk+/XDpklMdSounfo6lf4cKVk+kcRb1njuudHVhWrv95M6P X5fbLzjWzB7298b4crq8dv3hspNeFxI2Or7Mjq9+7pPj4qOOdOhsCn16mg2Ges8N2X+/BCgfus73 G0LfcMBCg8rQydS6Juu46JCMH5LG+kJeVqoU6QeBh+1VKEP2LNSwO2Hsr9+WClN/svwta5fLQgbU HXHHG3LLqQdIvl6zhN35sBiX4NsFpaWmrgmfcODiACfFDXSSnpHjfLML3+2C7sX4yrSyerE8ZC44 BNJDZaJcv2k4vozQxH4kfH780cL4hgPHaMBTqR8/Ns3X3//ilIMFBljAEj6SXJCXfdu/aDhjyUoJ BOVFmeXk5AisK7t8HSubpXv9kd4bvBDNHyJvlAO/fcF4ti2mM775Kdu+Sog+ytq+5GC5tRKwErAS aDEJZO1+vHz91RGypbRCMnQQ1L5NnmeCz3xom368ILoDiEIZdNZ1suTsK2XtqjVSju1qOvGW035H 2alToZTrhz4xMMnsPlw+/ehI3c2WJrkFudJOnwAmvmylY8nCI6S4rDJERzShIN9uJ98rC397m5RX p0h2fra0Db5gmnmy9jhRcQ4J4czFnSV1mN1PnSgLj7xFSvWjTvlt8yUr+HJvZsnafbjiPDyEs11h bXm55Q4NwcRS7oIjxjvl5qn8dTOdYwKV38nL98wJFz/0ZvnjyX3DYcMXSMuUrvseL3dP/l7ePOvB UEogUOEM6EIR1mMl0IwSgF7AZAz6KCfDinoNk6vu+a2M/XOplJZslY3F5UGYTMltUyhFHTtKgR71 Zp5I5PlfRspLSqUmZw85944X5MzrN8jajcVSUlIhlTqZ3aF9J8kN3lcLnMRLeuBm7XacLNZ+vLWs qkH6RsE9+ob46YJ36MVOvQ+VsXcdLtfcXS0bN2yQrfphOMCkpWVLTmGBw3N+dvij7n6e/XoGepkG eGBYpmT3lHu/+kpu14/vSXq27i5zj7MTjrCumy+n3PeNHHnLJqlOyZD2hYWqkcN3xkM2hKe8mlp/ 0IeLoYdLKyVTXxbr04cOAcG/3C77y5iJ/5LLK4tlzZr1+vyAzLKkoKizdGmX4+w4xPPl6rlz5XKd DMhu014nN0wMrj+SPCPJp3bOBI0pXyvvvL9USjLSIi6wtAjVlToBUbiDHHNQV62l1m/M9oO+kt3j pHrHG5HaYTRJAb85zskpyJE2WB1Uw7Lhss+KFMqh598s888cK1s2l0uJ6qHcNh2kY4cOskOHNpjZ kYogPPPB3db9O9o4izyBP/CEyRfJ3UVOGDNBzrjyNlm1crVsrcZirC6wtt9JduxUEBpfpnY/Xk+C HiWVAb3OT8eXHYMLwsBp2sbqZ+IAbTBNoS9Px4wdt4cO4ooqvv9oE7Bq8BTE1C9C8Lux6mklhosO yXK9Evsv3Iw03TihNVKQ7Y7rNMoxhEm0Kvpp3ocekg4a2MvRPxhbQA9hTAd/LCYSj7fpN3WOfOOP snfwhAP1B2Bhv3n/3x7Ue+23k4RHfJ4kJ9BQfD2D+MBLJPpqlxA9xtHLweTsXfYSbKv5NBieO2ma /HDB/tIzuCHQhCWvADX9CAMut9s+cpz6Qyfaprwr3044RfZTXc53CtQD8kJ+az5+WsbNQG6aYCPT YFN5JMZ4uqYscGNsqvKBODM+nuVZXGEJ2MdtWBbWZyVgJWAlsE0kwAc9HtiweJBLVq7k64Q1H+T+ hzXj8WB0d/G6L32Ix+5eDAIqA5nStvPOThjxsGXFxaFdDsibphP+ObpjAWWyfDIdoiPdnZhjOnER jvGAz8rTu951EIhhBuBg6BIuJSNb8tOznDLNcomXLuEzdEIsPTsgmYrfhHeQ618kOlkmYIAHMA0t N1OPoGZARsF6Ac7qNcvkCxas7kUjD5EcDFDUz0EKXewmQZ6aXO+jFR9rw0AZdJFXA6X1Wgk0SQJs +2xf0Acw2JHEe1vRRp0XBZ0Mb9OhQNoVuboHeZ18Oo1cXu7e7YsdYIxHvrD1klldWeEcz3ZgdfdY x875DizKQZ5KnfxEGvQV+iPwkkbAIL5a+0R+Y/RNkG7gI07wi37GnXB8UcVCYLuiLtJJyyNf4CTV 4bk6pGMoN8DARtIzLMuUBHiFSVH82conYJDXDxvC6UCn66JEoeMDLMtGBOQE2ulSnrHUH8qAHODC gDbQ4VitowKtf5RH+hBPwzyIQzrCsAij7NSsQumySxuHLsJC57GNpSr/eLbkZHrxUz7A6TznjPom HtJqhklXYrpb5enbJsujKxOTuk9Lfyd3DNshMYmLI1VsW0SJ9hPtuU+YSO0QbdzJG+w3gEUc+wLH OegtbKN0AQM62F/RJwKZqmO7tJcOmobdoCgTfRp5AA/DcVxz92/yRZd8+cdZoJFp8GMnKMLo3+Cv XM9htd+xm3QOPh+cON3MAjjw4OgITStQi/zkFTjgb6p+hrxgIGfgh5yp7xtKX3qQPsoErjUxSgDP O9igCaRo+1fbWk2yLDqYbRh+sw+ibhBmXzRhW6re0Gdh0IehO9I77OghZemylbJ1l6JQHOHKV8yS e+58IxQPD3DRehLMwJJJMvjYPPlsxnjp1Sa8kw1yCax8R64f944JLeedsJ+kGe3ck4hAA/GNOqlf 3fhqFRBjRF5POfM0XXCYQviX5f7njpV/XHiwRyYOnwY/CFdWqtyD7wuODs/eVQbrisProRWH1+S2 p86X/4wZ5Ohws139+unj0u/0O1loUrnp+uGJndtlO2pMD/7odyhcncY2mVTMJAmxrfcJkSQVYMm0 ErAS2D4lYA74+JKHOHNASBi6lBTChGVeuHhYYtDAgRf9zEdY5o/ksny6hAEO+OkyHi5gMXihYRph iQsuLE0kfH5Y4idOuoRjOvEynfF0mU6a6BLejw/xMFWVW8MfgdTwux8ukZqg/JkXcOGBymp54a77 EBUy7fMynHoJRViPlUAzSgBtGf0RrulnkaZ+cF4yVGfgZQ6GafQ7kVH+AEsdAz8n+omT/QO0mPSQ LqTDb7rMgyLhp8t4wpr6xsRB3IwDvJ9OvriSTpNnf3nEQ9ekA34Ylsk0ExZ+GhMe9NcFjzTKjC7x kF7SD5f1BxiEAUMDXH6aItFlwjOPmY/pLJ8uYeH6/YyjS3x0GQ/c8CeNWb9M/pmgiw2Q4Yypi/W7 Qq3fsM2wHcFl26JrptHPNLqMh8Tgp8t4uID1wyNMWKbRZf9gP2XYxAXYbdW//byYdNBPlzSBPvLj MKp/5Icu4wlLnhjvx0U40gO5UGfBH4t+Jg66wEVDuugynrB0GW/dBkgAzxWIGjb4jMGTJvy0aQCu JALlokMyXK/EfkVXFRqUWkh/JZrYqRfb6GY500wa9Rd5b5l7HS1gRJc8v5n9vBx43BUy1wRsiH/x vdKvyxnyz7k/iPt96CpZ8eWrcnaf02SJiWfPq2QYPuBQn2kAvkP3yA89W+pD27D0LBl05nhPllkT R8n5E6fJig0VTploC9B70MVlm36Vz9/7l1x3zp7Sp8/l8lWp+f6eJ/2P+70H10d3nCTXPPOBrAl+ ULus+EeZdt9o2ff4mzxwyRJAW4L6wrdN8rN14ybkovJxtxEmCxfJR6d3G2by0W8pthKwErASSDoJ 8OWIAwDs2MLLEQYDSOOOYP+LEQeQHDzgDkVO8uElDfAw7uAs/OKMHQyIQzkwxM8ddigX6XzpA7xJ h5NJ/1gu6caONeZBGsJI444JuAgjHvj54kkXeWiYDy74AjzpQxwtymO5Jp1IBzwMYBBuSLmkH+Ui L8KwOTv2kMMV57sOZpHvnh4jl1VeJ5ecNER677GzXq+QLSkq++Ktm2TF1x/K47dfK6+b94AOuFOG 7ZLm1JOfb5P/IHrrWAk0WgJotzDsd3l6+gj6Ae0MfQI7UWGgK0x9gXbJ9g4c6AOwfmN0VycpRWFN eLZn0gF9Az93+FI/gBZY9HO4pJF6ieUCH/LDgkb2e9CGNORHGvKRfuCDAX/4uCBg4Ych/+TXxE2c gCMfoB/xpp5BXhrkhwEc4p2dzQpv4oWfeVgu+WQ5CAMOeMgHyoUB7YgDX6QfcbAsn3gBhzjgg2E6 2wP1KuCRRhd+lot8xAd5Iy/KZplIR5hlwQUMDHEgH3AQD+KRJ5o8UT5pdRAlwV/xqpWyKZHp1La/ RenLT2Qa40Qb2w77IfQJ+g/bH/UDikN8tHZIcti2gRc4/HqH7dts7+gfZvlo7zCAQZm0CAMnDPQz +zHgm6t/o0wa8OTXB9Q/SKMFvdDboA/54UKuMIwDLNKAD/DUO3DBI/QNXKSTBsoFOBqqn1kecKE8 4Ace0tRQ+qjfyLODyP7VK4EU6P9g+8ZTKi1V27Pa2iOGelHVCTDhqXdk1brNdcJs68SC3CzZuLlU Kqrcducvf1NxmTw0ZbYTfewhffzJ2ySMPof+kZ6BE581egrVHQOinafpNUvUP+yT24SoCIVAF4BO 9GHYtC79ZLTCPRGCfU0uOPI1OfKMi6Vv23L5eNKT8kkozetpGC+vy/lD1XpReEI33z5COgb1IXGD 1sgmNnwdgpmBjzgj42t4bN6ep8jfR70glz75bSjznEevlSPVSq+BMqLfbiKla2XRojdl8eIQiHp0 nJado8849xmFethh8Jly1Z6Pyd+M99hnrx0hzyqq1mAg++yMVOnXzV1QytZ7mzP0fiVcr2RN80nA Ljg0n2wtZisBKwErgTolgAEgDF1O3NT3AoQHJmHMFzoO4FhopEEN4vjCibwIE44DVeRHHMswYZCG eAy+mB9+wtAlHFzihUuccGEAz4Ec0mHoEhZhPxzCMHAJxzjiRj7SSRim+fEBF+EJ49CV1VNGXXu4 vHvPuwBxzNzJd8v5aus3B8nzfz1F2qh8yGP9eSyElUDTJGD2CbRp9He8SMBFO+SkD0sBfCTLdLoK Ra/jpuo1CpH6FXDBUM8Qhv0YaaSRcHAJR1oQB4N49mOkwY84GBOW+AmP8k2d6O+DzOt3AYc45mc5 kegDHA3hCUeX6SwH8TCgF4ZwSIef5TMdeBtTf6TNLA+4gZdlMs0hRP+YB2HAER7x8MPQZV7mQRh+ 5DPLADziKR/gQJg0IJx0RuskoY1OLqzeKtIlhk2aCc1HA4hDm2L7Y7tlm2RbhT6I1g6Zn0UiD/Eg DX7iAYzfT3jiR1nIh3jiZphlIIy+Ahf5UEas+hl5TDrM/ooyaQEDWOCGAZzpEo50IGzyjTAM4ogD YcbDD4M08kFcCJNOxhE/5UScdF1sYd1OHHSZ38TH8k0c9dGHdOJkmdatRwLBNudA0Q+X/nqyNyR5 7qIfdcEBy6bJZRJh0QFdvUb/qmoCsrm0SvtqivPdJvbFRJIo+ixsTeZucvnUe+SJ4d6Z7ekvTpLp PoIPPba/zJw2NxRbGfK5HlMPMOmEsWOldOJEeZsRUdxLH35DTu1dWK9uaAi+0/ro93uCJh51YOKA HgwEMmTQmGdkYtaNMnbSLBbluos/kpfVRjYFkqcfLExNdZ9trtw6yflPTZZvBp0V/pZD5MzSc/Qk ufuotXL86eNCEP66CCUkgIdyw7XJuPoT/GamYzwcHscnAJmtkoQEHzG3SplbpqwErAS2UwnwYccX IQwU4MdOMvMlkzvO+ELFfBQbX0ydQVrwpRb5sUMOce6gwX0hRF7TAgdftLAjj2mIdwcu4V0cpAPl EQ64EY84GISRBkN4hrEDDXQBLw3KBhxgiAN+xHMnIdJhGG/CsTzyCDikIz8sDNzGlAs8xAvXvSM4 RfqNvlseqblLLvpr6JJMp5w6/w69RF6+4xLZu2OKgwewwEn8dea1iVYCjZAA+53ZjtEP0B/Q7kz9 YLZD5INlP2L/pD5gun7ywGPSM/V7MKq70G/N/kd46gMzHWnsB/CDPhrCgw7iACziEQeDMNJgCE89 6ccL/Qb8mKxHGssibrigm3oQrmkoN8axPNKHeOBlOYBnHHATL+JJM1zqe9ID+gFDPgADvNSHpKMh 9Yc8sDDAi7Lg0iAN/KAswpFG8IfyEWY+uNw5DhyE9edHmPKJVZ4m36TPuk2VQL4URvhwd1OxJlJ+ tkG0X/j9/RC0Mt6kG/Bo3zT+fo08SEd8LHoHfQN5cGIBfuSBC70Dg/JgzXJYNuBIT3P1b/IAGlEW 9QrogWE8wvDDgv9c/aYV6KP+YP+nbjDz0g+X/Rn1gfKoD4CLeeFnfcWin008lFe86AM+8g36rYks AdRdIKB1WK1TirB6pgFyq6rGLvXghKWG42WAO1lNSyw6UF5wtaZkS1m1bCqplLe++EXS9WTD6QO7 SZZOLhMuUWQLXQAdALeg98nyyVtF8thf/ixPzDS22JPYAWfKPZdeJEf/pkQmTDtaJjvx+u09ptfh 7nv42XLGyENlysS7ZPzztSfg9xp+oVx/4fly4K4Fjt6CXqDeAW1+01B80IPQjbAwqIeMDO8ZxPyg TjbLSk/3wuAbOaALeNAn+VypqMiXQ/9wv8w49H156bnn5NGp/Iy0ic319znkVDnt5JPk+JMPk11z oO/D7/+O/m63n9z58ety0BOTZNzj02oj6D1C7r7xD3Ligd1ky1cvGum7SfvguMPVF+HnrAHUIl7I DDTx+UwizHpGnSRa/yCdye7aBYdkr0FLv5WAlUDSSoAPNjzg8dDDoAZx8Nf34GM6YJ0BgjN4yXAe qHiowpj4GWYcXOYjPB7E8NdFB/MDH+GRB/GkGy4M8JA+wDAdsCYeB1j/mE56GCY841kuB4HkgziZ j+kMEw/Lo8t0wqMc2DC+Ahlywa0y54SzZf6nn8r/Fnwj33/9hfz8ydfC06m9evWSnfbcV/bbv7/s 229/6btzO32xD0/wsSzrxkcCdvBStxzZ1tG20T/QtvFignbNqyeIge2f/Ygu04krvaCTHKSRc5yE /tK5Ta7TZ/nCg2jAEh/6KcLERzxOdv1DPGBBm5kPfhrTz37Pvsly4JrGxEsY5OEEIHGSPsAQB9MA z/Lqow95kB/lkjbiAV300yVNpNkvH8DBAhfxNqb+WB7xAQcMy2c86TBdpgEWcqAMQBPxgG4YwMAw D+XPOLixyhOw1sRDAmVSgvnu7URRsu2xv7DvIB6GbqztkPDISz2AvIg3+4+Jm/2A8MTB/o10My9p RPq27N+kAeXDMAx6TUv62P8BizgzH/PDZV7GmXiZDpf6ATwTBjjr08/ETzfe9IE2a+qRgDl/SD/6 WLCf1ZN7u0rGosP9L30gOxa1lf322mmb816tpxsq9UqlYl14SE/T53awv29zQhpYYG6X/WXMxH/J 5ZXFsmbNet3ngg1lWVJQ1Fm6tMtxrmKDrrh67ly5XDfZZbdpL3kRFtex6GKa8pJSqcnZQ8694wU5 8/oNsnZjsZSUVEiljm86tO8kuZnhBVHoGOgm2GimofiIk/gQztrjRFmycKjWUaVk6Aa9XN284zdZ uw9XmMNlS2mFZOgGn3YF7rFF6kG6fI506n2ojL3rcLnm7mrZuGGDbC13r8VLS8uWnMICKerYUb9d 4G7SY164NODZ0fG5u8gJYybIGVfeJqtWrpat1e6ieW77nWTHTgVSvnWro7NTux8vcz8+SioDqZJX mCcdE3zM4fKn32cMNo+MAHgP8085WDe+EkjwZhFfZi02KwErASuBRJAAH+54kYPBQAEm2ouck2j8 cRCEiT4Y5Ede0xKcZdFFPPMzji7Lp0s4usTJcvmCyHjC0fVPTLEcpjNM/hmmXBgmPMsh3mh0Mt2P l3iI159uyhE4cMKBsCg7u01XOeiobjL4OHeHCXYKMh20YIci8wEeabDAi7IZRpo1KoGqCtmoO7Aa atLTMmTDhlg/iVolazZtdT4Qp+9dDTT6UbHC7KSbs2M7Zz9FGO2Tlv2DwjDbJdsr0tC/kQf5YXN3 PVKe++abUL/ADlP0VezYRzr7LfzAAwPXjEcccMKw/zGMfDB0nYD+kY/69A3hmR8uccOl34Qj7ybf TKecmM/ESxi45I/8MI1hysKfn3iZTnjmN+FJP1zSRTjygLDJB/OzHOJneUynS3wMky/AEwfpYFnE RRfxLId4iJd0ExfT6RIuGVzKJmFpbddZutWeu0hYcptCGNsP64Ttj22S6Swj1nbYUL3D8lA+2zhc xJuW9JEewrNvkT6mMy/C8DM/+WJZjAcMDNMZ9qdTXv50J7P+MR54WAZpBAzSYRFHWMSzXL+LNBgz PhJeF8qFYxlw/fSzzMbS58fHcq1btwTQvGBDRq9WFFhrPBLI0Kta9uxaJHvv3tkT31wBf1+qqq7S 0yfhY6kYP8Gy/7H/NBc9seIFPeiL7OsIQwemZhVKl13ahE6KAh/eybBhxknX998c3e2Pq3HM/GE5 eCmorqzQ71mUO+WkZuRIx875ju4CLuSprHQn5qH3gQ8nsEiTf+wJzLHiAx7igwuL8uimZGRLfnr4 u1fgn3WEcgAnWblSoDCgB2HobrgI4z0U9EEurGPgD6RlSruiLtJJ+QEccabqEk65LkIgP+L4nCOd 7sl+Fx/wlEu2tN+xm3QOysOJ08UGvu86daFpOHmRHqSJcoPb0oY0kCbwXKV7b1ZuwreeRLp1Utnj Gw76HZoEILelxdVs5dsFh2YTrUVsJWAlYCUQmwT4QCS0P8z4aC4fpHjww48BgWk40GAc8ftdptNl OsN+158eLcx4un48DPvT/eFY4ZjP7zK/3zXh4KccMSCDLBFHi7yIoyUuU+bEB7nDmnkJv927W3+U ay5/RWofbI63ZErk5psebzzS7v3kjZsPkbaNx9DiOdn+2K7ZPv2EUU8wnfn8Lts02zdfXPgCxD7j x+cvj+Uw3h9mPF1/uj/sh2P55JvpdJmfcIyny/RoYX+8H57pftcP5w9HggcM+YgGTz786Qz7XX85 /jDhiZfl++GYznjmY5iuP94fJlwyuNldd5X95DP5PEGJbbNb++3ig9Gm+Nme/K4JAz/TGe8PM56u P90f9sOxP7C/EJ7xhKeLdFg/PNPpMj/xMZ5hv8t0v0s4xvvD/niWS/o41mE+pvvzMZ3xdBnPfMTL dLp+OMbT9acTT6z0EY91GyABnT8MpOjUUWqGVGUXir5xSE1GrlRn6uSthDcaACPrpwHYWw0oFhv2 3qOLTLzqRJ0cbpmTzugH7At0IWD4E6luQAss9AEsw2wMkWgHHPs78xA+mgs8yAMXlid9GWa5GMdy TMtygBPppmksPuCkId+gi3yQDsDQTzoIz3iGQQtgSBPy0g8XBosRgIcx8zkRRhzxsEymU97AR5xI Axxd+p2IBP0D7zjtgyvHnO+c6HVwGWk6b6I/bYkJSnXyk2UXHJK/Di0HVgJWAkkqAf/DmQ9xDgrq Y4v5CY9BUkMM8/nz1EcH89Fl/mhhxtMlvN8l/fWVz3zR4FiO32U+v8tyKU8MRJEXu0jgYgcJB6cY dMGgbOzwQDrLYRrzYec3cHPHDPwmvJ+O7Sm89L2PtsFiQxwkuuwzeeOHA+XM3bz3+8cBc7OjYLvk Tlb2F7okgHAM0wUc0+CiHaOPwDLM9o04tm/2I+Ihjmhh0uOH88P70/3h+uBZjh8uWpjxzNfQ8qLB Q04w9eFl+Q2tv2jlMp4u8ftdpvtdwtVHN/MR3u/Wl98Pn5Dh9J3khlG7y+lPfp+A5O0gt5+9TwLS 1Twksb1Fc6OVWl879OMjHsYzTJf92q//mE7Xn5/wpIduNHh/fj9ctHTCkU6WEw2e8XSZj3jqc5nP D8d4ukwnPQz706OFGR8v+li+db0SgJxTdNd0VeGOUp1RIKW9zpBAVbke8dNxbVaepOUUhiYfkRP1 ybrxYootVK3XAXXQaxsTzZSWV0qJXoETzbT0YoO72x2nGfBtBLU1mGjWXd36XlNVFR6/sW7oRuOn ueJZLvot/HjPwlgH71HcqY+yOdENPQk4jofgZz6kYXyKME+mq9djUhQGcGiXZtuk/sUOf/jx7UHQ hDDxuTR40Omhntjw8T0Q/AE/cKN8vheiXhCmHMgHSkM86IALvkEPx+HAhzBw8t0TcisrK3Pg4YfB eyoM8QPepAN+4IFFOeCfeeHy3Rd+lgcX9AAe9MCQH9Yjy3ESE+APNNOUVwbko2/Xad+oca6GDeSp XPWUgzJIEOvGWQJ2wSHOArXorASsBKwErASSWwIcmGDAhAEVBmowGMgijoZw/jAHcMgHm2gDL9Lb cm6FLFjwa8sV38CS5y1ZowsO2/4O3gaSGTO4v93WlxHwsOwPgGeYfQNxZt9AONFMQ/lONPpJT0vz 0dLlUw4t7e5yyHHy0cH6gq+EJMzLFCYZsvRqg5YWji2/0RLYXvvX9sp3oxtKS2TEhJxe7RLI0Mnr vCJdcNDJTF1wSM3MkXS9ksQcAzS1Pv/z19EtwWHUMjE5ed39U2Xe1z9FhWnpxQYQhncWWOzexkR0 airGbrqrW58NnJiOysA2TjDbCMaSfN9CPPwwdNm2mAdh+PmeRdKZrqNWRjluqi66IA8tIgFLeEyg M42uCdNUfHwXdIjRP46dTb5RLuiBC4P6Al2sN6YxL2DgZzxkRXjKjS5gYQAbyaJMwJr4AI84Ewdp QxoM0oAP5SIveUBcIhrQi0W4sgosxqk/oFfHOiOmxKQ3EWXYGJrsmLQxUrN5rASsBKwEmkECjX1A NzZfNBZixRdvONITL7yx4vGXywEVd2wgHbs7MKDCYAULD6ZhORxocdDFHS3cKYN4ayCBGlm/OXkk 8eNGd4dQ8lAcmVK208iptWPRntHe2Q/w0oMwdjwBF3ZCAQb9AmHip1sbY+SYWOFjhWMpDYVnPr8b K55Y4Yi/ueFZDt2GltfUfMzvdxtLhx9PQoR1si07IQgJEtFC13ckkghibV/xhqMMYsVLeLqNzdfY /LGWFysc6YjVjRfeeOGJle7tDY7yDT3ncZJBr1Gq0g/5BjChje836Ng2Xe+ZNycdW5OcanRi8voH 3MWG8orwdxFMHlt6sQFjM9OkBnSyOiUguRm6q14XHDD/CxiM4/iOY8Jva7/ZrkAXwqAN70lwufMf dBEWLmmHHxbwcPl+FuLPV03pmVnO98b4XubHg3Eu4sz3NdCFdz8HtpH4WB7pBC6TX9JBPlG+aQjP OPCJOPZH4DLxIT9kALoRDz8M5QUX+QFn4mE5+DYb8vjrgWUQF+Dph0v+iBfpLNMBbOE/8ERZUS4q Hv3OiZ7iUIt0bVEOHy1Maqss3i44tMpqtUxZCVgJWAlYCTRVAhyYcWCFAR4Hbxy4oAzAwXCAxQEh BmCMI4wDaP/EO6RObIF0bZtM1MZflnxpQHtmu/f3jfiXajFaCVgJWAlYCVgJWAkkggRC44B0vUIF u8X1w7sYD2CM69jgeDcRaI0nDVhsuO6B1+SzJT9Joi42kF/UB42uMeipkxQpyNaT1ghomplOuERw 2bbQjviehTjQy3cujD9hAANj5oEf8eQP4fSCTnKQws1xoPs7V+cAhgsLxIE4Bz64cYYT5042/WM5 TcVHPCwXYZTNcTXpYDpc8AN5+OVAXHBpgAc4IC/iQj4sPMAQFvhYNuFMfMiDeNYD8iIOFgZppsu8 jDNxOoAJ9mfyQp5AousPyzPByE56cuyCQ9JXoWXASsBKwErASiCeEuCACgMuGAyoMBjBQBUud46w TMRxAIc4c0CHeBMP81g3eSSwrqR1nHBoqMT5IsEXGfYD7Nhimm3fDZWqhbcSsBKwErASsBJIDgmY z3qMBXAnPSY1Ma7F2JcTjNFOPCYHl5GpTKbFBpMDrC/kZen3CHRxaNhehc54LS/LnWg24VrSj3YF E+19C2loX7AwbIf0O5H6x/xok7CcwM/d9Uh57ptvQt90wM59tFm0X+ThexnbL/EiPwzxIR22sfjM chzEwT/Gszy/PAgLOmAoB9ACQ9cJGGHEE9aUnwlHWcL1l2/SEQkP8yKNsMBNevz4WG5LueQBcoQf 37SAhR8WJ2mqqnCqJkNqtEmSD5O3lqK9NZVrFxxaU21aXqwErASsBKwE4i4BDjwwkOLgBYVwIMh0 DFTgp+XAJe4EtQKEyTSFvzWZiG2GtsH2jPbOto5ibPtuBmFblFYCVgJWAlYCVgIJJgE++zEOhp8b cDg+wHigNY0JknGxgXXk1E+a1ofeTl+Q7X5MOTi/7xnDJVITI+1sQ/7xJmllOsPMBzeSBTzi4cKi /dJFPN7pmA6c8NOF328bi89BavyZ5bA8IznkJRwj/GF/POiDiSY/5icc89P1pxMP33396f58DCei Sx5AG74RnRqsfzM+EeluDTTZBYfWUIuWBysBKwErASuBuEuAAzIOsDDwguHOFH+BhGM+pjOeYetm S98+hSIrk+NDDgfu3na7rDK2W7ZnTDDAcHDOeMJtl0KyTFsJWAlYCVgJWAm0Ugnw+c5xL5/7vKqF bPvTGZ+MbjIvNkDeqDMuDLG+ONGONNZpItQNafG7pI3jTaYzPpJLGLi8Ogn8MwwZMN4vHz8+lEvZ MT/CDcVHmvz4Ge93/XAM1yeHaHiYj3gIV1+YcJBTQwzzNSTPtoZNT0uRndtl67uMiB78kTT91gkC fllta7pac3l2waE1167lzUrASsBKwEogbhKobyBVX3rcCGkFiPoe3EPknc+SgJNcGdSrXRLQue1I tO1828nalmQlYCVgJWAlYCWQKBLg85+TsaSL8Qwnq5uMiw2mrFkPcB2/ujCcLDdhk8FPfmKllXyD X04gIw5hc/Lc336j4Y83vmjlNFd8Q+XXXHQkCl60CfQIfNukRv0ZaBfaPnS5IVFIbJV02AWHVlmt likrASsBKwErgXhJgAM2uvHCuz3jyd7tEHnsnCp55auNkp3Z8KHIxmXfG1U0CAAAQABJREFUy4yV sUlw5726yYHtG15GmV6ltM/gQTJAD2Nsz4btnu72LAvLu5WAlYCVgJWAlcD2JgE+/zlp65+wZXoy yyXZFxsge9QPJlXTM7L0e3M1Ul5e5Sw8uBPu4Un3RK2vxtIF/sA3TjBABjiRjjDu6AfOaN8YiVZe vPFF6xfRyvfDxxvOj98fjrU8f75ED4Ov7IxU6dctzyE1O0tPvej9SrheyZrmk0DD38CbjxaL2UrA SsBKwErASqBuCVRtkeXfLZNVazZKhWRKXts2skv3PaSowD7O6hZc4qX2GTZM+gxrHF1VP8yWGXfE ckKig4y/+kTpY5tH4wRtc8VPAlZ3xU+WFpOVgJXAtpGA1VvbRs62lBaVQMyLDbt3kYlXnahXqzbs qpltyZzOszu7t6tqArK5tEp396dIblaWe+JhWxLSAmVhQhmWCy/OjnYNYwEBtqEm3vgaWr6Fj58E UJcwadoOcjLdhblM7cfoH9Y0rwTsK3jzytditxKwErASsBJoogQwYIRZPuMROeGIi2V+LXzDZPqq t+TwTu4d886gokqB7BOulqRaS0SZ7lqKzVRKablC2rYQm7gsVNwlAP0F3XW86q4FtbAPk3d+fVsO Kwo30JRqffkJB2vlsBGJIYGq9Uvl+alfS3lGAlVWperFtrvIWSf0kfzEEJOlIkklYPVWklbcNiKb k3fbqLhmLaZBiw26gSURFxtYH3BxPcyWsmrZVFIpb33xi6TrB6RPH9hNsjLd7xk0qzBbCDn4hsVC AxYWHDno2CsruNDCdH5rBOG6DOHjha+usmxa80uAJ1ZQ//weI0rlQhTiWefNT832V0ICjZK3P+Fb jq0ErASsBKwEYpPAhjkPyK5HjI0CPEu++mGLLji0lyUv/0l6nzrBhdvnQvlk1iNykL2CP4rcto9o dxlq++DVcpl4EqhPdy1U3XVYUTuruxKv6uqgaLNMGveavFhaB0iLJX0t8zPayt+P2anFKLAFJ78E rN5K/jpsFg4CNQ7aQHWl46akBHeNpyXnSKs1LDZEqudqPd1QqVcqFevCQ3pawDnxEAmutcVx0hiT yuaiQmNON0A28cbX2uSdbPy4Cw8iVcFPNmQEsPBU9+JTsvGYiPQ2/GxRInJhabISsBKwErASaHUS wA472JqaX+XZC/2LDUNk9OjfydAg19gUXF29SWb9PbjYgPj5j8onS9Y5OIDHGisBKwErgW0lAbzw Qnc9E0F3jRrl1V1VVRsj6i5zJ9a2otuWU78EqlYvkzcScrHBpf3zd7+V4vrZsBBWArUkYPVWLZHY CJWAMx6vqZZA6WYJbFkrsm65yNqlUrPuR6nZtEqwAJFs4+zWtNjg1E/wnQn+quoqx7LxVldX6zuS 1l8QhvGtxeXCAHes41sOsNi5blrC1cc34eKFr77ybHrzSID1CJd1GdBF0pWbquSXjXoiVNtHmp5S TU11T8Y0DxUWqz3hYNuAlYCVgJWAlUBCS6B08TtypXkXSd+r5ZPpt0gf3Bkx8UHZsr5SCjrl6eRe iQR8H/jNTLcLDQlduZY4K4FWLIGyJe/IVR7ddY18/PbNju5Ke/DvsmltuRTukKeTAFtr6a6s5Nww 2oprM8xa2dr1sikcTDxfWbFsUKrstUqJVzXJQJHVW8lQS9uexoAuoqdWlUqgQldbN/4iKXraoSYj W1Iyc0QH4Xo/ybanqbElxrrY0Hf3zjIxQa9Rqot3c2EBfhr4Mfm6vZh48xpvfNtLPSQKn6i/Gu0D uHIMblW1fmg8zb2GTC/lShQyWx0ddsGh1VWpZchKwErASiC5JcDBMXfjlJZu9DA05saR0k33bxbr Fk4MHnIKc6S6vFzK9cNPHXfxgEqeztpV6X3/gMNdnDB2wOiVkQ1ZCVgJxE8CPJVQWVkpJSWY9g2b MTeeJd1TtsrWre7dsRm5GY7uqlH9VOTTXbmZ6Y7uwu48GOzOsiZBJJDob0/6zFyvbWyXvASRlyUj 4SVg9VbCV1GLEMjxuNM+Ksuk8scvRTavlPS5L0hNxVZJ6dBdpLCLVB5+taTkFzm7yUFoIo+zG7LY cP/VJylPifuBaH+jwHtTVRVOM9S4Vk+l4NorvAdVVbkfTkbdsH7o+vEka5j80G0qH8RDt6n4bP6W kYBZf+WVAfno23VSrQuondvkSiAvRTLSdXyt/cKa5pFAog+Zm4dri9VKwErASsBKIOElgBcd2E0/ /+qhtUPbHMFkHhYQMIjAQNqdjEuT3/75Z1l43nJZX1ol+Z12l55dM5PumLeHWRuwErASSDoJcJJm 8y+rPbR3aJfr6Cvz5QcTOZgQ+H9B3bVBd17lddxVenXPsrrLIz0biF0C2VKYFTu0hbQSgASs3rLt IJoEnPG4Tl4LTjeU6Wrm1rWSWlEi1dl6rDhDTzjoc4ztJxqORIhvzYsNkK9TT/rehN3bGFuk6kYs 2BpdiOCiYiLUg6WhERKo2iLLv1smq9ZslArJlLy2bWSX7ntIUYGdzo1Vmugf1arHyip0QU6/c1Id 0GvGBPKziw2xyrAxcLaFNkZqNo+VgJWAlYCVQLNJIDRg1sEyBsg/LvrMKKunFGVX6c7hEsnMzAzt 0sGCAxYhUlLSpajr7lKkObAzuFxPPmRlZTkLEnwZMif7DMTWayVgJWAl0GQJQGdB11RUVMiKxabu 2kuKsnDqocTRW9nZ2cGFUnc3aCDg6q5Owd2H0Ge8cxY6i3qLbpMJtQhasQSq9IOhyp59y2vFdRxf 1qzeiq88Wws2jpuxc74Gm3uqKvSLqxXOMw5TdJjAD+huejyv9M95ZuEZxRPFiSSH1rzYwHqivFP1 uqv0lIDkZqRKmi44aJU4dYZ+bk9LUkqJ77Jel894RE444mKZX4vkYTJ91VtyeCf3Dk5nfKifJrDP fq+g+HyDPP8/e9cBWEWxtb+Um55A6L1K71JEUUQQBCxYABEFRRG72J5iRezYHvp+xQYqigVERQSx USyI2BCQIr2FTnq/Sf7zzd5z7+4lwQKBBHZgM7O7s2fOnL3z7Zk5c2Z4WOcCZfQI8hnjpJWUSdxy 1qR8nrn+2eXzvblcuxJwJeBKoFgJ5OSkIzk5GenpOaDO8a+CNwfpQoN0kpPTkSOdjMMVvD7+LLoH p6pKQWSEfV2IpqhdLcwoDKqIKRXNz1jTVCo0BOfX64y9OVLn9HRLboevuvYi3LQrAVcCB5HAIWNX GcEtVlExKMpzIHYFd3wUq/QZM7DjM1ocDLNYjotblMKRD+HhZdx9ILEGapVxFo/8WyudEg8Zt8hW GcEuxaDSxi2ryq7OVTq/yMNPVb9DNDDQo5jfKKYDOwPALE9i17cPPxeHRvFYNjaoZPQ98VxsDAiX P/FRYeYQpcToJZrXjcuPBJJ/fB4NizU2sA4L8MeGdFOZ1TPuNRNTQjwydN7uGvzoXNGz/FS4FDnV bxyLsLcXe7oUiz9uSbtzX47bV+9W3JWAK4FjRQLZ25fhw6nv4bW3H8cC+walaIMBowbiyhFD0e+k xvBwiktJwZuMxXPex/uTp2HCzPkH5Go7YBSuHDQYAy/sidrRxdPhB9u7+XOMGHAXkioLiVqXYvLr /0H9cC9Wz3sbEx6dgFfmO+dnXHr3RNx5y1VoUzXwOWKnZf+v7+Lmh95HdNUYvPHGBzZ+PsGjo4tQ Q9ZcDJ79qwqDxiFVumLsg1egcZSlaOt1jZG+GbPemYLJL47FTIfcgB4DLkXt4B03ZdOIzjdNwOhe DWz8uElXAq4E/o0E2A5zkpYb7Jo09XE4ocGJXUSH4Jn9ph0Lbv342bSjilvKl+LK3p/fwa2PfYCI xEhMmWLHrll45KZC1EqwsE73ZtDndbDGnFc+CQ8/MhK1ZdBY6aqMi9I2ubilwjhKcVS9ejgFS7Do KJX/V8VWaF7V3TD6r4T0L+8fKm5psUX5+/82dtWKOhD/lE7+prn/Sudq65sRq/hS6rgleO/XuSaK zuVUBQ+qc93cs/4B+K/1d+PSlQB/HzzowVAoXnvIz0OIHLxmjA4S89tlPIwlDz2PVTcnZ/p9K10u D079eDA22CVAY0NsZCiiwj3o0SzBvIPYyPAy8S7sfLrpkiWguFxYuAtTRt0SlLE7rrqqFtZNeg8L 5U6BvO+CglQseOHxQL5lr2Dx6sfQpWslc60stMMAc0cuFZBjwPOY3se8zsPa2yRMMMyDQpGjev8c r/IqrTcTGOEprRJcuq4EXAm4EnAlUGoSWP3Bw2gx6IES6C/HzFd4jAUGTMD2D0ajVjGon776Ewxr MQAzS6DCy8tmvoJbeOAMTF82AwPbJBabO3vfJkxdpj3Jrtg3fj3m3tUE100tNjumPn6dHBMxfeW3 uKh5vMlEJWDDd9Px/uzZxT605OtZxV4/8OIujBxzBU6oGFiORPMkL5c6tBuEA00rVo4FM4tnOHaQ TaFTYm7sSsCVwD+WwOoZD6PlIMGmYoMTu7ZNvxm1LY9xf+701bMwvOXRx62BLWQNa18gdm1a9AHe m1U8Rv00v3hM0+cD8U5cc59lcAhcA1zcskvjKKbDa2PMLR1x/YRfkB4d9MM8imyZoivWw3NDWx1t Lo7Z8g8VtyiYf6xz/f4BBra1Bo6CBfuvda5V32GgTecqTdwizy52Bb+58nWuA3RFYlwIkcMEsSHJ f3MUyrJK/utlqGo0Njzw8mf4ZdVWxMZEIjY64kDu5Ltdv2YllLcNooMrooOkjD1hskG0vJn4KI8x NOh8M80T/Kx7XjYlkL3qK9xqnxDX+nYs/vJBtOKEuAn/Q/r+fMRXi5UB8ywUBVRRU5mIcLZON6gE iGEauEd0qDQKxTW97salI4Fihp5KpyCXqisBVwKuBFwJHB4J6Edz5fRb0fri5/4e0Zm3YNxH/THx osb+WS6kk778DVRsf9Xfo2Fyzccg6fhO+i0ZI9pVcDzHWU6FYYEPOvAKOtV5xZGn+JNlGNTyOvyW MQVtZCYf6YQVpRaf9R9drYBoz4GDQYW7vsFFYmxYEESrdfdzUWn/LHyzIuiG7XTN7nTDHy/pTAjb bTfpSsCVwF9IgO179Yzb0GrwP8GuvnhpYBM/5bKEW0sz3zK4pR2XsMLDgV0JMjsxXNaTDax86uKW //WXiUSVtqdi2uRTywQvLhOlL4F/h1v98PKgAG6Ry9TfX0dih3+oc7WrjElLU3BFm3iH/kZ6/1rn akGd6020jrRmeh5u3OLAJg+jr+757l/rXH/uyTA6l+pb7oAp3/qRC/pdY8w2IBs5mIPnHMQu4jvm QbOD5jly7P1lSeR59JDu5jhY5sSEGITbvrcHy1sW79nbBdPcQ4OxthueM81r9rxlsS7HM08GL0UA XLaM6ezsFIc4br7nMtRHBsTh3rzH6IRoFMhehbni1lKlriOreLl4zAx+/T3wrvvuZamxsBDUSYwi XEEcfxAme53wRGXvlKJ7djgkEOjJHA5qLg1XAq4EXAm4EjgyEtgzD5cEGxu634Evft2IPbL3wo6t f+L7j1/CkNYBdv7csMf5Qc1ZjhsOMDaci5c++g4bt+01ezjs2LgSs19/BDYyhuBVHZ7A5gBpk/qr j/WNT03D8nXbsW3jMkx76sqgp9/B67PX+Qfzmw17BXM++QRz587CPefaszbB2Nffw4fTpmGWzCKe LV4Qc+fOxeeff44vv5yDJ4e1tGcuJu3F3Ak3OYwNrW+YjFU7U/DD7Hcw+4dkrJw3Ed2Dnnx64W9Y +fvvePPyYEkEZXRPXQm4Eji4BAS7hgQbG7r/x2DX3pQU7Ny2Ft99FIxdewM0yxpufbrO4Crxj0eT y17Cl3PmYM6cmXhgQIBtoAnuf/VtfDJjBj7++GO5PwefffaZwa+vvvrsL7DLxS27JN20K4EjLoF/ gVtrRedyBGLXAcYG0bk+/h4bt+4xOtfOjaswe/LDB+pc7Z/AFgcx6+RgeteNT0/HsrXbStC5phqd q3Rxizx68fmEG506142vY+WO5L/QuZYanesN0bkOVsdiROJeOswSUPmLfQGFshkxjQtMGxuDucYB O17guJ0vYZ0e9b/h4WGomhj3l0d5NjbYhawGBY1lhJmjzMbYoMYHe343XTYloLicun2Xg8HKFaOt 5c3EkEZjmu6pUlgYir6PbceKnxbhm2++wa+rt2NQkwi/buogchyfUK7ELu5tEhcVCo8Y4cKkfRiD 6XEsl9KuumtwKG0Ju/RdCbgScCVwmCSgCghnPix88WHYvSwx6FmsmHYH2tSMMrMdQjwJaNz1fDw/ bwM+eWKw4aBzi5p+5YQ0Vkwdj6kO3m7FD9tex/knn4CosHzkyEbKiEpEx34jMfvHKXAu0jAeL83Z YmZhkJa1DqJXFKECB0Xr5FRMXrQR9w8/HVXjwhAeXQ3dhz2GBc8Nd+R9/u2FSJEN6XJltkZhRHW0 6dABTZu2QudOZ9vyNUaLVi3QrFUrtG7d2hytJN2yZUs0a9Yando3s+V1dnwov4LMpZg63ia5VuPw /gNnIxHWBoZpaVlIaHouJs4aZ6MjS0qtyket+vVRyVNglD3WV9+HI6N74krAlUCxEmDniMeCFx8J wq5nsPKD/6BtrWizCXJRWBxOOPl8vLBwMz5+fJCh1blFDX+7K2u49ZwPtxQHiyJroF2nTmjSpCVO OsluLT0BzQW7mghWEa/0IH4Vi12CV8QYyoy49baLW8X+rtyLrgRKUwKHgludbLhFnWHF1CfwjoPZ 2/Dd5tdwftfG4tHkldms2SiKqoiO/a/GZ0veCtK5nsDE2VsMHpAnrpnPtahz82TG+QHB0rnGXt4D 1eLD/TrX/AnDHDmff2uB0bnMoJWnGtp27HjYcEv1o/z0X/HWEzadq+VYTBOdq1JIrszSzUBqamax Otfy1V7UlL1SqooHhuFP9EzW2w1HRwLaDoq8MvNajkDgUJIs3uP7XgWuu6mjIQF6MvAI90QiLDwS 3iIPCsB9NazrrqfD0Xgrf79M1fnY3qhTbln5i+3h5qga5UVWVpbpJ7OvzO8AD/bXc3LCUbVeY9En m6F+1SiThzRIy22flhhpiIvyhKJj/Vh0bhBnDA8Rsr4Sl1dyQ+lJwDU4lJ5sXcquBFwJuBIoFQkU Zf+KZ8cttNHuh08euRSJoljooBc7aJbCEo1uV08Uj4etuL93DfOM1XHYhLdHvWujAby2+HY0EEOD dd/q0FKRIU1P3TPx1qRrHPnHv/wl0n2dDFWSCg7oEHbDuz+/h34NxRDiU3xUQWpy/lW4zE4xNRV5 PsXIriDl5doNB1kozLcUMeWTddX65uXY88psLBs/SjPdVubohy5AJcnDe+RLacW2ORPX2/Lt3pPs 51/p2G67SVcCrgT+hgSKsn/BhIec2DXTh13a9ti+rPYYiVOuegG7tm/Hvb2q+wbfyzZuUQTEOR7E RCd2ZaIgz7rO+ikear2Lwy7m0yAe9P7g4pZfFG7ClUCpS+BQccsa7NmMt6926lyTltyBxhHOmaqK B+Gic7352ihH3Z589Uuk+fCRN0i3JJ2rfyMx4Pp0I42bXjASjmkePp1LMfdw4ZZVX8tYyrRd57pZ dC7qqnZ9i+lgnWuX6FzkW2k5BOGeHBUJqGcDh+aY5j8N9rRec+OjIwFpcuKJIoY62b8iLduL9Bxp RzKv+1hfTicnJ914iaWn54hf1b8MXpl8JqsEJJsjHTmCQYcreH38JSeT7sGpEveIy5ERsbaMTVG7 WlixmKj5FS8V0/VhXi8peMVYkZ6eLofI7S/4KolGebiuv/8w8WqIjggzhocI8YAKk+Wo3FC6EnD3 cChd+brUXQm4EnAlcMgSUEVBO4PJq3/ELDvVoReiWTjXdHRqCpzJwg8snwuT9cCtdR7FhVD2Nche 8TWestPo8ww6V8kRGr51Wu33fOkKnfugN17Gl3pv1tdYnXIpOsRb6/Rytl1Obr7eNfHoN59Bx4Qs UWQCrtZan5CQeLQ+U7J95Xvkm/n4Y++VODHW4kFnbxSI0hwIMlAnGlG+GB04o8PuIky62Y7ZftKp zcuVWYDW2qXMW5TvhWwT4Q/VYkKRlpZmzvk8D0vOsrZjU7n8p5XVm5ttZhNSppQf81Gho3xVifET dROlL4FjWSsufekd0RLYVhg4qJS2Mhi7LkLTUHZ0rLbHfNqm2M7YZqOiLK+tXMGxnJVfHXXcCg1N OAC3Vu6/Gp3ifAOAwicxxOCXN2Aw4BBNoe86cUTlwjoznZVrx29iV57IzJdPcNXFLUrKDa4EjowE tH0eKm55fTpC1vKv8KSd9T5PoYvoXGlpTp1JsxAHK3TqjT6yF9YXenHWV1idOgwdBGvIF3WQnBzn 8wGdyxpEYR4Gqz5xaGXXub6dD2JXR9G5OLhP3KJelX8IuEX9zOst8q8hny86WYzyLzF1rsxMMb5K WeSJ/DEuKChy6FwF+Zyxm2PoEC/DRYdl0Pfi6l1GHEf8Dzci5mEFLkViXZEv9xHnxS0wIAFtD4xp /EnPKUBqVj4+X5pk9qa4+JT6Mnht7eEQeKr8p7K3L8OHU9/Da28/jgXL7fVpgwGjBuLKEUPR76TG 8IhcSgzeZCye8z7enzwNE2bOPyBb2wGjcOWgwRh4YU/Uji6eDnHJu/lzjBhwF5IqC4lal2Ly6/9B ffFcWz3vbUx4dAJemb/MQfvSuyfizluuQpuqgeFY4uH+X9/FzQ+9j+iqMXjjjQ9sz3yCR0cXoUZs YIksvm/zzqV8Bj8+VumKsQ9egcZRlm6t1zVG+mbMemcKJr84FjMdcgN6DLgUteUb4wjijdb5pgkY 3auB43J5OTH9f5ERvyP6TSTvvM6D11WW5aVO5YnPwC+8PHHt8upKwJWAK4HjUAJUFHiEFnoctR/d tyVCpPPGGS3FBX1OY35sCwtzHVmH9m+HSHY4HVedJwVRjXBaV+DLxXo93XQaZQsmc4EdyGAeKsaG mTx2hUjThYVRaNKllxgcvvYRlE6q6XwGlCYtqaSYdSI9BqsD68ypnVnmM/XOLZTttgJh3frdKGpY y8jVQSdzA5b6jA3MXSTr1vJ5KiaMNW+Akps6khKIa9oRl9f8A2/uOHipzU4/Ba3sE4QOnt29W0oS YPtjCBfXfnu4pb8Pu+SitmVtWzzXI9COjz5uFRQIbp1UHG5Zhld7/YpLs06sjwbiFoMTO1l3ekHI hnY0TuS5uKXycmNXAkdKAmyrDP8Wt7StE9OCda4hfdsiShp4ga8Me534nMFB0bm6i871hV/nkg2U qWcVkp6lkwR7OCTGBQZUSIO0tB6Qof8THNgldRM6ZMGZz86Nleb9v4NbFl8Wf3yysBjsKmhc11+e 1qMwY6ND5yJTf8XTgVy6V0pTAtS09Z0w7VO9TZH2dGny4NL+exLgRK38AtEbxPAQHiZtl438GAur P3gYLQY9UEKtlmPmKzzGAgMmYPsHo1GrmFHP9NWfYFiLAZhZAhVeXjbzFdzCA2dg+rIZGNgmsdjc 2fs2YeoyNSp0xb7x6zH3ria4zrl2sf/ZqY9fh6mPT8T0ld/ioubx5jrb14bvpuN92Z+wuLDk61nF XS7m2i6MHHMFTqh44KS45OVSh3aDML+Yp3hpwcziGY4d9HgJT5Sfy5bhQXYW8jUHT5FBsvJTgXLK aTFNr5zWxGXblYArAVcCx7gEtGO2fd0aR00rRnvMbDcOTLGDGRERYWIqLjzndX5kGXiNM9mSNmwy 5/qnacOK5h7zq6Wf9zQ/47y8UNTp1AVYvMT3mMygycxFbrQ1U81y23eaLLJyOZMt2j+DgA9qp5Uz 9IrC7PN2uQEWZ+1Zs3rNQJupg684E8kGTzITweMJ89eTl8mfDtwFcgs9KYN8WUoGO8xAdCADXr/x JVzwy0NoFmfN/CEd5v15+mSHMlapcrQpg/cpIx5uOIoSCE/ENY+OxsVJ27FuRwr27M9CpnivMETI 2rUVqyeiYZ2aqFvJ/vs6ivwex0WzvbPdsL1vX+/ErgqR4eYe2xNxS3GK50wz5rMMfD5p/WaHJI8W boWE2VFElmMTb4SiIsuYQp55EEedG1FKnQSL6bHBuhHfGJjXkpG9ajrjOMx4ShTJ7F/7L9nFLbus 3LQrgcMvgX+LW6qHKUeql2xfv1Evmbh548p+3YQYQI8uBuorxDwr9qB25yCdKysPeZEWZpB2sFdp Vl6W6GoRBk9Jj1hDesxrsDTUjiRc2oieVBbe8j75OBTcKiigp4SF1yw/Lwi73rjpVVz4yzg0j7f4 Uvxb9N4kh85VuWqswUXe56HBntZrbnzkJFBYJC+Xhy/INBzw0BD8vvS6G5euBEzbliIY8/BKO+Sh ge2fh13H0nvlKdZ6rpx+K1pf/NzfY33mLRj3UX9MvKixH0tIJ335G6jY/qq/R8Pkmo9BbSth0m/J GNGuguM5fi8KxbATCK+gU51XAqclppZhUMvr8FvGFLQRaCadsKLUEnP//RsVEO37ptifKdz1DS4S Y8MC+0VJt+5+Lirtn4VvVgTdsJ2u2Z1u+OMl/R3ZbpfJpH4vFJfINx34dqTyOwvUr8a9TujlwPGT MlmFY4KpwBfimKiOWwlXAq4EXAkcmxJQJYu127NjtaOSuYUycC9fTn5I1bjAtBnwsrkJ6oeXefft cA785eYF3PLtdJSe9awMljkmKKcjVzq/pGc/7MzJHf+p0rV/+IO/71S2NPjzObSAgCspebMfWj99 nrGdL6MQRjTDqCfPt2WZhvM63oCPFq/EXlmzc+fGZZj5/GiM+O98W54zMKhbXaOoKk/FlWV7wE0e IQlUrFUbnTq2Qr/enTGw/8nmOK/3iejetqFrbDhC7+DvFsP2tycpCLuKrA6xvV0Rt4LbNe/z+b1l BLeC60xvBAbyScxhIN45g2X81boeiM/23EJD6LDOBsMim+Pq8QNsGVzcsgnDTboSKDUJHApuKVNs w8HYlefbeJd4QKyw4wLxzwphiHQ4tKYh37f4t2JDoWPJSXnKp48pPcVSPQ9oZCzBeaZ5rLL17z/D LdaVvGko8DTFtc9coKcSv2/pXD+uwr6UFOwQnevjCTdh5PMLbHl64JLu9Y1MbBfdZFmQgLxf/sYY +Fd/M85fkrnt/jmKEjB6g74nX0x2eL3chz3zcEmwsaH7Hfji143YI/24HVv/xPcfv4QhrQM1/XPD Hmfdc5bjhgOMDefipY++w8Zte80eDjs2rsTs1x+BjYwheFWHJ+Cc+vLXcr3xqWlYvm47tgneTXvq ygBjJvUOXp+9zo+bzYa9gjmffIK5c2fhnnPtWZtg7Ovv4cNp0zBr1izMFi+IuXPn4vPPP8eXX87B k8Na2jMXk/ZirmDtAtud1jdMxqqdKfhh9juY/UMyVs6biO62+0w+vfA3rPz9d7x5ebAkgjKWg1Pi Fb19uORYmnxLvWIQLxIvB/tYRTmoRrlj0fVwKHevzGXYlYArgeNNAtqx5Iw3zlDJz3IqjKHhkWZW WnR0tBmo05nC2hFQebFTS2WTa4t7xdXWHjxFoWZGHDun9hm4zM91dFludnY2ChwWglhERFpu/aRl 8eeky1kDkZGRxvjBmDyRJullZWUFzaSTT750VHWgTtdw98jsg0AIQVR0DGJjw8H6ap0oIx6eMHte ecpXFsvkwTzxCU4ega8x5vKvA0UEpUa9cC/aJ1peIzowwCzKZ1B299SVgCsBkQDbG4O2TYMP2c62 V2TDHW3PHIgPDqTFPWKCw9HCLecmc5YnFXw+CMQ51pn8ckO6QBCMjYxCTEyMwWmd0UwcIR6GCjba A69xXXPTQRJ6CQlO3Hdxyy4tN+1K4PBI4FBwS/Ub1b1IS49gnSsCludpbGys0SWIB3yOOEn8YJoY kOfDUat2sQj3eEWHs3CU+YJDmCfC6FyKM8oT8ag4nCF/ISHWOtbMS/3RqXP9M9yiDscln1gWA+sT H38gdt01rGSda+Tzd6N1XMBTjHqpXfcKrrN7XvoS0N8xNWy7ls3fDA83lA0JsN15xZhZIH08cxQW mPbNduj1Btq5vjONywb3JXPB3x8D6/fdiw/Dse3AoGex4n9DUVnycK/CEE8CGnc9H8/P64Ohk8fg vDHT0LlFTYNFasxdOXU8nAsH3Yoftt2LhrLnQlFRvrU3TlQiOvYbidk/1kP/k4bjDz974/HSnOvw yFm1zRXyRr7y8wOeP/6sOBWTF72FsxvH+HTiaug+7DEsiPCix+gp/mzPv70Q951bD5HiyVsYUR1t OsQar97sTmcDs3R5pcZo0aoFmkn/l/hOTNR+KHkIa98MeGulj6YTc3m/MGsppo63Sa7VOLz/wNlI LOKm0dbkloSm52LirN1ode5YP2/LVuVj5JCmUhbrmG/au+qv5eX3Y+czN78Ii9buA5cjrFFB3ovs iWG+eS6O+d/54U7YvxmHm7ZLz5WAKwFXAq4EDqMEjMIgH8iarTo6qOaJksOPqc5k0xnCGut15uFB OnVanOKgsSM5y6+86MxbfY6x1dnLwvqlupwSH7fNwBWaxYUQn0LE55Uu06RpVwDsz5I/BuXXfk+u +vm08xfgsfiOj9IsSlmMsdd+4iRZ4llT3PXip7i1p6VUWjKwZFgS7yWScm+4EjjOJcDBsRqtOjmk kC8dY23nwfig7dve1uq0PNnxfFnDLTuvhv9QOx5Z2KX1Co5L6usQu4pSfsSD17m45Xj57okrgSMg gX+CW6rnsG0zzYOhWJ1LlgHUPMyv+prG1r1s0bl+stUyYMAwuEBsMPPMA1mIQXxWeVBcVZwN5GTK qbf5nz0MuGWoU5dLXYIHRn3sLLbEs6a484VZuLlHTVMHO56W+Ih744hJgL85ftF4MG1+Pvxw8XD+ lI4YT25BTgkoLnAWN7ErVNoyD2vvlwMNlM6ny/5ZUfaveHbcQhuj/fDJI5ciUQb8LWMLDSuW0ZbL +Xa7eqJ4PGzF/b1rmGcok8LCTXh71Ls2GsBri29HgzAu6WtNXuPAOg/S9NQ9E29NusaRf/zLXyJd ZOyXtzwXvJ8O0A3v/vwe+jWMMnRIW+k2Of8qXGanmJqKPLlPesyndPNy7Q0rC4X5NCRxHx+LT8uQ ZNU3L8eeN7B8MYtRmum2Mkc/dAEq+eiQL6UV2+ZMXG/Lt3tPsqNM8lZeA3kvECNcjuwtlJMnaVke zvqGEtXcUFoSOHAaWWmV5NJ1JeBKwJWAK4F/JQFVPFTB8MiMOHuY9cMaXN/lVDMzjZ1LzrDVjizz 2Z+nosIQLrPg7OHVRatw79lNZEZu4Hl29vRZ0s1N24FfHZPS6iI+wlpruKSOYViYRU/5Yj7ywOPA mXSWoqV8scPMELyeMPdwID315FC58Jpz5rFSsmLWZeev88SfQcNAvDZzGCK3LsOiX1diZ3KO3IhB xfp1cGKbTmjbrjkqRVqbtpIXzuhgGXbZKiU3diXgSqB4CbB9sr2z/UUmxDkyfbr4T9x2en1/e2Y7 46F4wmcULzhDN1y8ueyhbOCWnSMrTf5NHRx9GDEKC34QR1hH4pfWj3nDfIOTPgp+oga3fpvv4pZf Im7ClUDpS+BQcYvtVmmQ25BQZ5f75R9W484+9Q0OKB4QB4h3fM4M/mTuhDR9W6iDOA8HowKzyiVl uy/6kuAKsYV6IOlSX1FeSDNYR+I9HszLYLDLQfPf4xbp7pQKfOnncKAsHTICoet/xo9L12BHcraU HY1KDeuhXYv2OLFTG6NzkWfVt8iX8uYn4yZKXQJ8dwz6+2Cav7RCLoMoB9P8rRT6Dr4znrvh6EhA 35eWHirLPMpueLKOv7QfnwGReYgtfFflJWi9VIdMXv0jZtmZH3ohmoVnICMjsF8FbxMzFE+pd9Hz IdeHK9krvsZTdhp9nkHnKjlCw9kHtWep0LkPeuPlAJbN+hqrUy5Fh3irn0z9NHg/ndFvPoOOCVni PWC1I9LT+oSExKP1mXLhK18p38zHH3uvxImxFg9cicAYPBxL5okuLRieL0YHrjxgf4+km51nl4F4 I+TliqdtwPhdJPvc2XfwqRYTirS0NMMAn+dhyRmIbCqX/7R48+ZmG49dypS4zHz8HZlvRTlp8+RX 66j8SzVktQfxCPJ9c/ktdb81vt/jYY6c2s9hJu6ScyXgSsCVgCuBwyMBfiA1hEbGaNLEa577DJtu Ph3t5MNPBUAVf7vy783IkM2do8HlgEkrIrE6bPoE8OYMrL53ADpUsD64pKFl8gPM9O4ln8Ixx/aS jqjn2CTLwZY5CTEbMTn5UkXF8Ono2Aaet/Me3IVRJae4uARyfsK716/1p9G5EVo1aIDKLVrg5L5W B5c3qTiSRyp7DOTTroTYeTMZ3D+uBFwJFCsBxRDeZJsKi3QaHP7832dYf0cfNPcEcEfbtRJU7OJ5 ZKWyiVv2eio+mHpoJXyx1s0ea5ZgnNPrjPdscHHLLg837UqgNCVgb8//BrfYvnM5Y5XLXvgGZCIq VkMzYdq/e9bk6Vjzn744OcHyhKCewaC6Bs/3/PgJPjVXfX8Gd0B90bkMT74BNWt2pj2TpQMa/cqn D7I+xWGO/SlNM1+wHmV/VtP+/JooId6zYV3gjk/nimvYEKedE2V4Im88OMAWzKfKhAQMXwFKbupo SEB+G/xOmW+V73dtnR3s63U0GD0+y2T70UAbgycsBHGRlsFBhsX9fTrNU55ixYnQQsemNhjdtyVC OGBsq7u9XvqcxsTOwsJcexYM7d8OkTKQX9yCSJqxIKoRTusKfLlYr6SbwXkx8ZoLxlAcxEPF2DCT h9il70bThYVRaNKllxgcdAqcGH3NoHjAKKEllRSTpuKiGgrseVlXR71lKb4MW4Z163ejqGEtP+7y lqGTuQFLfcYGXuMeZaRFPGasZfJeeQsqD/Kt7ySQdnGstN5n+TFxlpYEXLquBFwJuBIooxKwfxjJ op576p6Ge0+yM/0u7p20yMwSts/Ap3IQGlqIPz56DDGVKmH4pD/8HbywWifj8p52Gl/j1qfnIF86 sRpIi4cJexfjwRET9ZaJH77sVISJwqN8OW76TtgnUTrsSOvhpxv0kCoAGgfdllPp8Jh6BTrpVj19 my4e+ID/CmmG2x07fnoSN42bhK+X/IZlq1bhjzVrsH79ZuzYswcpspkh92bkbA49yDP5d5Tn73T5 i3ETrgRcCfgkENwxiajfA2O62MUzDXe/8r2jAxNoYxZ2JVSrhhGTVxqcKZu4FcBAYgzrbD8CtQ0Y XhVD7LE1ihPIrSnSDLP3sV3cUtG4sSuBUpHA4cCtuCpVcLkPt9iGQ2t2weUyvhQIX+L2Zz4zOlcA 8wKbR4fsW4J7Lvu/QHZJjR3azTe8ZV0m3eAQ6tPbgvUuzVfSkIods5x5/h1uKb1gneuGB17F/F9+ x7KVK7Fq7Vps3LgV23buNDNts2SZC/Jt17mIkUor+L1ondz4CEmAvzcZcDSHpPnrE/OWOQ78JR4h ntxiDpAAjQ2xkaGoGu9Bz+bx6NEsXs7DHXrWAQ+V8Qsc6OZg+PZ1fpOt4bhitMc/OYz4QM8u7kOo fU3FVmYmXtLLK2nDJvOs/mnasKK5x/Ng/OE1PpeXF4o6nezKawFSM8Vrgp4TcljLETlNFlm5mYZn 8q78kB4DJ7QVhdn9DejVZi3pxPKYn7w4u5gy+c2Hj/Ri40GstPI5UVsaKby2ZZI4kU7gFdFW8ebv 6ze+hD8zrUl1dl30t+mTMd+Wr1LlaCMD8qVYbLtdppPkmQffAQ8jB5GFXrfem7UkFe/r9TJdqXLI nGtwKIcvzWXZlYArgeNdAhXQ63LnepI/PHYJhj40HRv2+OYveHOQtHoeHr4gAu0HjzUCa1DZ7hkR i55X3+4Q5KpXrkaf217Gih0p5rr58Oan488fpmJAs7PxhT13lwfQv5lzaSf7bXs6WEHRTqOJg3Uk 34Oax5yWkMdext9NN+zax5H15w+fx3WXXYwLzz0X/fv0Qc+e3dH9lFNw0kknoVP71mh23g146o15 SBJlUxUyBwH3xJWAK4ESJUAM0WClBbuGXa2XTLzo0cG4/NEPD8CuRy6MRIeLHzR56kuHxwplG7d8 TB72qGHX3g6aLm45xOGeuBI4rBI4VNzy61yVFLfIXizOHHWHg89Vr12DM0ZPxB8+ncvc9GZgzaK3 cGGr8/C5PbfoXP2aOnUuh55kz+tL2+/rwH0x2Ur1UjB2/TRjAm4YdgnOP+cco3P16nU6Tu/WDV27 dkXnDm3Q9Lzr8cyUgM7FOtjrUarMusQPLgGOfvKbzsM3EsovfOArf/DH3bulKwFtJ4w9YeK1LR4O 8VEec/heV7lsS3Y83rNjtUOIuYUycC+/R+KbGheY5iC8DsTbMYR59+1wGi1y8yxvdhK201F6llzD EGWfsIZ05GYFBq5J184naVkmOaYCdJUXg8fWLf9fDnhr8OfTF2duBLzX1IChscWjPm3FyhNjM+Ae 0Qyjnjzflmkazut4Az5avBJ7k5Oxc+MyzHx+NEb8d74tzxkY1K2u39CgfNkylJuk/f2Eywg424fK qNxUopwy6hocyumLc9l2JeBK4PiTgH7oqajUOXMYbuWaSLYw+5mRaNOgujXjISoOdVqeibEzAxl+ 355ilA6lk9D2Yjw7KHCfqZVT7kWXxrUQ1eks9O7dG5GxldG57/X4zpGtJyY9fREShQ/yoocji56I slScIqQ8HEZbgpZYYkzFIqLxIMx65JwS8xxwY81X+L+xI9C54SDM3Zxv6qq8H5DXveBKwJVAiRLQ dlOr51DcFoRdnz13LVrXr2bNTIuMRd1WvR3YtUywSzsGxyVuNRro4laJvyz3hiuB0pPAoeDW70mp fsZIp0L7oQfoXH+8fhe6nFAbESf2NjpXVFwVnNj7Wnzvf5KJnpj8zEBU8OlTpFVSEI3LPzgUnMc8 V/KjwdkP6dwMcMkAmqfhRZj7xHl/n9bqr/DiuKvRvs4F+GKL7Dnh8yr9+wTcnKUhAfP9lfcZEsJZ zmJiEH3aBBnYlk0CSqNIl+Y/kIDiFB9hmu2GA+46A17bkT3fPyB/1LIqjnAmOr0C8rOc5q1Q2deL dYyWJYNjZAm7WNnjMC4uzn/wun0/G9LwFgQG9lkxT1Go8RagZwRp8EhISEB8fLxJkwZlWeDAzlhE RFqz5tk2yF9BEN1QWVKYZStvpEua5JHeCc79CcU8Ie2L/Wm+K9bJeDBwZNwfQhAVbdVR68pY60gj kyMIX/QK4aFyjE9w1h2yO9iYyy/AKTLJ7vS+g3Dfq/McJEa9cC/aJ0aY3xR5M98QyWFPOx4oByfh YmiokxiFunKI4w/CfHjG9+iG0pFA0C+zdApxqboScCXgSsCVwKFJQD/ypGKlZZmRKTNwWdDAXcml 3ITHL2kXdDsWvR9YiPHDiiGyYiEWLlwYlJ+nF2PKvP+ia2XfUktyxc5bMQ/8o0u65ZXjw18kPp+2 oHlsl0pMct6K6Sj5FYld+Gnxp478TXr0x0X9++OMM85Azy5dxLuBKy0Hh+8wqPXj2BJ82T13JeBK oEQJ2LEh0EER7HrrQxQHO8UTugGPDrFjV9nFrQP5d2JXYB7dgTmDr+QLZil2FRXtdHErWEDuuSuB UpLA4cEtS+dy6DLi5fDPda7BeHPes0bnIl88iKUaaGA4lFC8PpXlIPmPcMvxJE92Yckix+5faHJ6 Pww8+2yjc/UqUef6FoPbPuHqXAfI8yhfoC7t16ct/d/xezyIMewoc35cFK8YobEABl+SwQz7eypv wiCOctC8ZquODtbz8gsMJnKQXo0s9livqzxIp06LUxw0diRn+eWjnhH6HGNLd83C+qVLbM9Z/KiO ZrvhT9qX/1W6pEWa5Ke4oN8L5deZJ/Ae7fwFeDw4zaKUxRh7rROLnfTtZ01x14uf4taetc1FSwYl G7PtT5blNOVLKcVHhSEuSryA+D7kXdi9Ucoy/+WVt8CIUXmtgcu3KwFXAq4EjlEJqEJij5nmLIyc nBwgpgnu/GABun/4DiY9+Ap+9MmBMzPatWuHb7/9FjhtMMbfcCMu69cOsUUyOyTfmt1A5YezJ/Ly quCs26ehVc/PMPWdN/HulwF31T6yxNC8efPMzA0074M7Rg7FwLO6IC7E2jSKvHBmhSqxPPdExDve Ro2YSP99+w1VqjwRQDdxp1+xYgVSU6sg2vdV0jrzmajEOugvBoE5c+bIWYx/DWNV9HTmhpkxEmtf NioGUbZNrUlz1buP4yGbvaHvmEl4TDZi5D3KhLNPKNtQcdPd+ed8PHr+zbZlDZ7CrN/uwujO1nqf 9nrb6+amXQm4ErAkoO1c2zPbDNtZQXxz3DF9Pk75YCrefPg16D58ffv2xRdffGE6lsSuJ667HkP7 tkWMtMecHGt9Vc4OS08vLBG3GjRoYGalrZQ1wovDLfLwV7gVJx1C8klssQetD3GrQoUKaNOmDb77 rgqibNq04hLjyiecglq1ViApKUnIxIBbMeh9pc1yuK5seKx9+ZVog4XMS9klzX/voLhF7OORn53h 4pb9hblpVwL/QgJsdwxse0xzQOdguFW9enXUrVsXP//8s9G5nrj+Bp/OlWdmvbKtcyYqdYvc3ET0 vWM62p/1BSa//hre/zqwvAf1nM8++8yUiea9cdeo4TivZ3skyNZa5IXYRf2Ps3Q1hIU7l1mqEx/Y jFnzMFYMJnb16tUL33//vfBT2a9zaV7WlzpXv379DC/BuKWy8cvFgVuWzsV7rDNltvytcXjANsbV 75438MhFbcw98lSxYkVkZWWJXleArSu/xPgLb8FcZQZPY9avd+P6DvHF6pH+bG7iiEmAs7B5MPD9 yeRpFHit7xSv6e+DaTcceQkQq/gOwj2RBntyc71+7AiTGfC8z6B4cOQ5/Gclsi6KJ8QUj+h/9jDr hzW4vsuplseA4A09CoiTPBjsz3OmP0M4QdAWXl20Cvee3QQRtucpH32WOJabtgO/fm17CHURH2F5 NpQky7Awix8+T76s9mJ5HFBf8zi8FyzM1BL0PTm9IMRzRWiRHp9nHSkTxdowbt5RQmBddv46T/wZ NAzEazOHIXLrMiz6dSV2JsuYguioFevXwYltOqFtu+aoFCmz/+X3wkM9ZeyyVUrlKeY7iPKEomN9 63cUJZuq8z2EynU3lJ4EbF2k0ivEpexKwJWAKwFXAocuAX4o+bFXF8rMzExRNBJx6uBb0H3IzchL S8M+2cSqw4knIl5cSpN27kd0pPUMewXsIlDpoPKQmJhojo0bN5rOa90T+2Nct4twf04GMjIykFCp Gpo2bYq9+5KxaccuVImLMhtjUbEREiZUrVrV8EI+uGkWQ2TjAVi5/DSky9qWsTIg16RhQ6McpQlv GsiDhlbDXsI3t1WVDmc2knbvgsf3zbfn6TD0Gcy+qTJ27tyNnXv3oapT3zR14iAkDS2thzyLZd3v QHZ+kXGpjRCFkIF1rpRYAScO+S8avvSbbFS4Eeh+H+48v5WyYgYQ69SpA9aHA4R1252Lx6eswefD XzB5KPuzGlkGDTt/fgJuwpWAKwGHBOwdMbZBHVyycCQRpwy8CWcOvx3pslF7XJUaaNKkCXbv3Y/k 1GxUqWhtqFdE7PJhBjGHA27btm3D/v37EYxbBSEetG/fXnAyDGs2bUGcdCyITXbcIn5WkQ1d6QKv uGTHrUjBknq1avl51QrZ2/wJg59D0nWVxb09Gttlw9MCMRhoYD4e7BS2v/A+bDj3LqxctRYeuutL B06D5iF2sTPa8OxxWN5zDLLyCkwd4315q1SKQr0R/8U1S3Lw8ssvH4BblGv9+vVNeZRLMG6xvPoJ 1sw0ysENrgRcCRxcAnbcUp2L8b59+6RtO3ErQ1wEqHNFRUYJFuxDXLQ1oBdKXUmKYZsjFhBzaChY v369wZ46HfrjwY7n4GGZCJIsWFa1Vj00FH1pu+hbu1PSkBBhDSapbsXya9eubYylqampflyLbHQO Vq3ohTTR/eJE52rauL4Z2KJxgxijdbEwsAhth7+EL++sIdiXLvzuQAUbJlEqfObEyyZgznXxgrNJ SEnPPAC3mIdYTuxpOfBJH27RqBKNBKHH+xygShSdq8OFT6Hq//2CPYLxOP0BjLmglbnPPJRJLcHa lJQU7N27F/VE53py6nrMvfR/5gURF89tYp9EYi67f8qIBPj71n6JSfvOywh7xy0b0rSMzuQtLEJa tlf0oRBpw9aAd3kUCrFCQ2ikEw/WPPcZNt18OtpJ/1h/i4wV9/icV/q0uaKr6YSPiMTqaCrX/1Si b87A6nsHoEMFaykqYq2WSYxjeveST2GzmwKXdEQ924Q2JWWPQ0QPVV5Ik2niMGNzXoJ3mp334GFw pVdcXAI5P0u716/1p9G5EVo1aIDKLVrg5L4y01/wmoGTX8ijGrXJJ2Wgwc6bXisvsfIeJnWKjrDe a0Q4PViCpVxealR++Az4ZJYfnl1OXQm4EnAlcFxJQBULfvh5ID3NdPZq1KhhFBcqCDk5XoTHVUQX cU9PkAG1gm1bULtmZaM0cFCNRgTmo+JUqVIlYN9ehEvnlx1cKhq8zllmQgV1GzYxxgbv5o2oWqUS mtWvjezsbPM8B+mofHBgngNlBZKHMWdbkAaPQhn0o6eAMTZ4ZUOvPbuMMYBKjLXOpTXDg+VyAJG8 xkZFmkE+1pX59OBanJUrV0bexvWoUaMa6tas5r9HWlSKOIBIBYL8VqtWDfFiTImO9oisAutrmjrv 3yubfnmwYMECU+9RQ7vJfA5LwSK/rBPLYZmULTvsBeJ2yUC5v/7662hVLRoFKclivynw19dkcP+4 EnAlcFAJhObLLP7CAtPOOADHtm7hTh5qNDjBGBvyN21ANcGcmlXjxYsh3eAWcYltkUZSeiYwD9sq B7yIE4pblarVQseOHREh5YSlpaBFo/rmPnFPcYtGSQ5yFWzdLOvnhhmcMpgldIpCIwyW1K1Z05Tl lXKILeSTOKNr4TI/ZzRHSwfeK3RqC1ZwYIz3WQ4DMZLYhn174JE6t2zZVDo4VidW6TAPjSfEUNar ppQbIpgYHc2Za9bau+Q1Nr46di5ehIkTJ+Kaa66B4pZ2CBs1agSPlFsoOMsBSfKnuEVezjrrLAxo Jl5ZqSn+OlBuzMfDDa4EXAkcKAHVu8xgi+hcbM/UI+y4FVWxitG5YmTmMPbsRB3RuWggoL7FiQvE Jj5P7CrcsR0RokdQ56I+wfbLvPlFYWjYtKW5TmyrXbM6GtasanQuu9GAmBdNvNiyyUyOIOaQFxPC Is21JoIFIempcqQZTFGsYcy2zmeo27CcChUSUE/wQnUtzcs6Uh+iLlSnTi3UqJponrXnI16FC73C HUkGi2MEV2NiArhFfDd1TtqK6g0bGE9Zym/UJScj0oeT1OtobMjdsM5gOc+Nnik4yUBeP/zwQzSS dba9yfuNvIivLm4Z8Ry1P/LVlnHNwHfD3y85ahy5BVMCilcGn+Q8PacAu9LyMGdpEub+vgM54oXC d6X5yrrUgtu5nnvqnoZ7T7Jz/y7unbTIGHWJO/p7tOJC/PHRY4gRTBs+6Q8/dofVOhmX97TT+Bq3 Pj0H+YLVGkiLhwl7F+PBERP1lokfvuxUhPl0KPJWXCA8Kx1+B/Tw0w16SOloHHRbTkNgX6bJXlfz Xg98wH+FNMPtjh0/PYmbxk3C10t+w7JVq/DHmjViDN+MHWIYpgFYhhTM2AD76TzIM/nXMsvL70gF oHzr++CYBb8x9nfCdHmrl9avrMfWV72sc+ny50rAlYArAVcCfgmETp2M3OlTzcAZO49UJPiRrFev ngxqRSD71lEIGXIO8levNAPw/KiyM8k87ATSAFA4/ALkjRxijA6NGzc2H13S4SAeB9NyvpmHsAvO ROYTDxpjAQeyNLCTaJYe+u/jJo/32/lmkJ6GB6PUiGLCQbBwr3SoZRmmouEXomj3TjN4RxrMww87 O6DedWsQcsm5yLp5pGzeFG46w5qHA7Vn0s0AAEAASURBVP8cIMya/g485/VAxhsvG+ODDjSSDsuk sSH/nlsQOuRs5K/43cz25bMMVCpYH5lCCO+wc7GxzylI9Bkd/lybBK/QYEeX/Gb/8C3CB/VF+tg7 Tbm1alXB9AkvGQWLxobhw4cjacJ/gc9mup1eI133jyuBg0uAbdQf9u+D9/orZIO+QrP8CDGA99n+ ONieNfdThA3oicz/PWXaHwe+iFsc6GIeDv5nP3wPwgeehdzF3xm8IxYonnBJk9DsLORdMQhewRy2 ec78J/4R+4gJxC7vH8sQenF/gxkewRwO6msgnrLczCmvIuzcHsj76H1jFFCjLMsibkUI78Ss0KHn wrt2jcEYzaNlFe7agcJhFyD3qiHwFHhNndnpIQ3yxEG7gu8XGgzNfuZRU2cOKmogbpHnjIduRoUr B2HpKy8ao0NV2eWOuMXymjdvbowNOSMGSVmCs4LtdevWwcKZ3xgyNDZ8/PHHyFyzGkVjbjKyVPpu 7ErAlcDfk0CIYFLOl3OMPkW8UMwxEzYEz3JHXYqiSwegMGmbwQIOahC32EaJUQUywA/BitwbR8jy a5Z+pFhAbCOmZM38AOGi52S+9oJ5hlhEGsQT4hiNDTn33Y5Q0VEKlv1mDAzUbxhYDnUYGhoKiH8j BgNpqUY/Iq+kQ8yh/pf7848IG9wPGffcavBF68N81KeIOdmv/A/hxOJPZhh8VJzVPGFCL0/qgkvP MxM9yB/xmfdZDid+FG7bgqKh5+D30zujaUPL6LB0xWaDXcR7Yl3G7I/hOb8X0p9/yvBWs2Yi3n/m f4bGjBkzzFKaSfffi6Iliwxt0nfD0ZMA5U8TFw/zLuR18I2Yt+K+mqP3YoopuUC8G/JlE+MMMTzw UC/RYrKWs0sV0Ovyaxw8//DYJRj60HRs2JNhXffmIGn1PDx8QQTaDx5rrjWobPeMiEXPq2930Fj1 ytXoc9vLWLEjxVzn77soPx1//jBVJmycjS/subs8gP7Nglzt7fdtaeI3Dw2aNnHgst42seaxThy3 DumkYdc+jud//vB5XHfZxbjw3HPRX5ZQ7tmzO7qfcorsY3gSOrVvjWbn3YCn3piHpDxrsiO/WeU9 sA4hITJBUfCKR1GRIlp5r1nZ5r/8/3LKtnxd7lwJuBJwJXDIEjCKj72jJcpLxLi7kPXeFNNRZeeN nU26zGbIIFjMvM8RmpmBkKsGI3+NZXRgZ5Ad20IZ+C+8/CKEy2y7yGW/ymDYxWbAikuZsOPJTmDW gq8QcctIrgWA2LdeRdpjD5jOLQ0aHNSjESDz6UcQ9dr/mU5H2OiRyBcDBTulvNegQQMzwJYjA21R v/+MMHHbL5QBQA7AkQ8ONNJgkb92NUKvvFh4TUfswi+RLXRodGCnmPmMUWPGe4iWuhbJM7FPPWSM DrzOctTYkDfmZkTMmoGQnGyEjbwEudIZJw+kYwbwZOCxQOocsWM3WnlzsclndHjjpl74ef1u0OCS 8d1CRN40AiEygy5e1pXfdetVUkYVnHb3DOPZQGPDghvHoNarTyNPFHmdNa0zB03n65DftEvAlcCx I4Fg3CoKkT1eFn+LvGuHQfyhTLvjoBqNmRlzPkHUXTeYyse+NAHpE8abNs42TFwiHmQ9dDei33uT C0bDI4Nd2Yu+MQNxxDVjNJX2n3v5QESu+QOebTKwJYP9RWLkIDbSiMBy8pYvRagYWkPEY4uYkSvY EekzSnKQjGVlvPEKYsY/aDDH88AdDqMDB+NobMgZfbXBLOJs6JWDjdGB+McBQOITDazEWWJflOAs sZAGWPJArwbSyf9WjLo3XWkwNHryi8h48iGDs8RY4hbpZAofce/PMPvWNJvwqDE6PHx5LyzdJPU6 oYnB7uwrBiL6j9/hEXzNvbgf0sWIO+L5rzF69GhjbNi+ZBlirx6MIsFBM6NaZla7M4WPnXbm1qR0 JODAL/FSirzjemN0oNGSxkDiCnEs66pLEP2LDOKLNxPbfMH2rWbiBNs58cQYG664CKHiYRT13Xxk X385osVAQMwiHR7pH76P6PtuFS+rUMT+9zGkvfy8eZZ4QV0mVvAv+95bET1zGkLEYyt01FDkL/3F 4Br3kqFuRmODV8r3bJDl29atRoHoVjQ60LDJQRbqTPm/LoHn+mEIES+wOKFFowPvEx+JsUxnSdnR zz0hbp2yDIvwlP3pR0Z35D2WRWNDvuBW5PcLEJqyHyGCP/QupdGBeE1MpwdZEfEvLQOds9P8RodJ 13TDH9tSDL+psz5EzN2jOTUb8S9PwK5HxwgftdDq2smgseFs2VR6wZArUevDN0TnsrxjaThRI3Tp vHWX6sEkEGJuclk+MYQxLX+om/OwLpgM7p+jIAHFK429oifx0MB2U577KxyE50Esq3PmMNzWVGtm xbOfGYk2Dapbs/Gj4lCn5ZkYOzOQ5/ftKX4DLukktL0Yzw4K3Gdq5ZR70aVxLUR1Ogu9e/dGZGxl dO57Pb5zZOuJSU9fhEThg7zo4ciiJz6e9VRjrYvVnvRq6cT6e2Ac0XgQZj1yzt8vaM1X+L+xI9C5 4SDM3Zxv6qq8/30iRzen8stY31WRGBx2pHqRlCLtQ8Ycwjz0jLG8N44ut8du6a7B4dh9t27NXAm4 EjhGJZA18FLkNW+F6EfuQaYYHdhhjZXObcbNVyFeBu639b8AK+6TDqO3wAzoq9GBs1+LZPYbB8F2 3Ps4dlxzK6KW/4YcGTDjkhwc5Mqc/yWibhuF/IqV8Nujz2Nvl25ImDoJaY/ebwwK7FDS2BD7+kRk dOuBrS9NRUGVaggXA0WuGCrYceVsXg6wRctA2/Yrb8T2+8QTgmVLB5QDcRxIK1j/p+GNHd91457F zgsuQcyCL81AHgf02DnOEWND5IP/QXbjJlj538nIaNHGGB2yprxmaHB2cp50WCNnf4TUAYOxYfyL KAyTTWmlM06jA+XCWc40NnAActMt9+DbNjX9RodKkREYLTP0Vrz1BmSdEmyTznGTVdvwRkoWqn8x FwvO6YVzzjnHeDYsGD4SPea/hcwupyCn99lGcVVF7hj9mbnVciVwWCSg7YQ4kX797YiU2aq511hG Bw5O0dgQc/dNyKlWE0sffwH723dC/KvPI/258WYAi4PzmePuRsz7U5Daow/WPvMqCuLiESl4R6MD B+jDc2UzVjE2RK9dhXWCOX9e/x9EyGxjDsCFyBJoxtgg3k/EBg6ObJvwmsGMKMGOnDtvlPXXI/3G htinxiFTsGbDxKnIPaEZ1OhAA6dHOpg0NkQv+AK7LhhisAtiSDBGBxno54CcGhvCBfO23v0Itl15 g8FCejrQ6EDDBI0N4ULHKzLZ+H9vIu3k7oh782Wkjx9n7jNPxhNjESueFsldT8VHpzVCkuC5Gh1u EG8uT34ulp/aHjFibLgmKQX9NuxC+J69SL6wH7w7kzBhwgRs//YH1L7rSoTIYEO64B8HHDTwvbjB lYArgQMlYG8bTGdecR3ya9Y2Roeszz81HlmyPZYxNsQt/Qkbh4zAqtseQLjoG5ABeBodaMD0yrJE HJAPlaWVtj4yAXsuGYGYRQuRdZ1ldOBkERob4sbegaw69fHb4y8ipWVbJDw/Hukv/89gEo0NWeLB GfPJB0jpOwDb/u8NFIphM+zay4zRgXpOaIYYG4ZfhMhN67F19D3YPvpuhAsWFohuR0OEMXCKsSFc jL0FUTFY/cQL2NuzrzE6ZN9/uzE0EN9yXv0/xEjZGe07Y9WEycgRnqLuGW2MDtTJuIwSPRsixHCy Z9jV2DLuGTNhJFQ8rGh0oDGGxgbKgMvabb7/CSxuUsVhdBg1sC+WPPUYou+6EX9kZqPeyq34ND0H 1d95CwuuuASXX365ZWw4ewB6LP8cGb3PQXbHrsYwa38vB74190qpS4AjpPxu8JC0DAGLyU1O5WDa DWVHAmwr2l40Jnf2dNnh9uCccLBYg5WuhhFvfYhhQUYHzXNgfBMeG9I2qO6x6P3AQowvjsiKhVi4 cOGBZHAxpsz7L7pWDmyBa+etmAf+0SU1DzneUVGmg4bmcVws4SSP7dQXLJq78NPiT/WSiZv06I+L +vfHGWecgZ6yJPNJJzVz3LdOvsOg1o9jSzF3ytslvi96+3DJsTRZN8pbwHZCHAvIqrzVqTzwG/ag hPLAqMujKwFXAq4EdHYG177lxpo/b0o3QunUQNaPlWUmImTWGD8mnEHPcDgVAUPwCP9RpYOzupjm rFSmc+RIl8H+yKU/I/rj95EZXwF50lGMX/gVtvW7AJvOH4K8hApIa3siqkrHMPRTmcnbuBlCbr8O 4buSsOWOB5HapgMy6jVEXmJlVJ47EzkycJcbLTPcZNmNvAqVsELy5IjRYV+HLojZvQOJcz+RrSPS kCfLDsW98RJSTzoVW24ag7yoaGSc0h3xP36PiI/fQ3bdBvA+cq8ZYNty+bXYI53avGo1kN2kBRK/ /BSFn89GfoNGCL3pKm6egA33PoZ06dSmywBfqNQxkbzIUlD50kmOengMshs1xdo7H4JXBhiTO3dD nHSiY2VmXlZsPLyytFT0nI+x7+wLkTRsFHKiY5HarjMqfSczh6VzntO4KYruvEGMDVuwSTrg+9p2 QljXHli2ZilO2b0Xa6e+ia25+ThBZg7vl8G8Hpv3YWN+AWZJ57e+Jwzn56RiwWdzsOmHX9Fj0SdI PbELtsqggkcGABg4m/lY+r3pz7ukdta5odXOuHzDsVhvrf/hju3tN0dw648k2exddNv6laNkT5Ew VIjlOqLWxmyUa3nHLZWfvd5M0ysoVwylOZ4IVBBMyv5lCfJkphFn0dLYsELaVo7gVnKnkxEjBsKK YgxIz5d9WubOQtz0t7C/+5nYcvVoeGPjkNLxZFRc/A0iZk5HVv2GKJSlRmhsWHvFDdh90mnIrl4L 2XK9+ry5yBePr7yadeAZLZgj34ZNY59Clpynt+soA4GZSBAMydqwHnnbtyH2afGiatYK625/wJST 2lWwTQb0Iz98FzmVZQk4zv4VY8NuMZBuu2Co4GxFZLbtiEoLv0CIzNjNa9IckCXtaGzYRJyVwcOM +o2QL/kqfzELOYKT+TGy581/roe3cjVsHvc0suRestQnUgYpK8yROnO/HVmmLv7t15AsdflT6lzh xNOwaK/sqbMpCQ2XfIffsnORcscNaJeXhWt2pOJVMZKuF+z6KTsfoxKisE+WodtUoSYaPnGXLGFV gE33j0dRs5bm1dhx61j9vTnaWRWrnVU8RtuZtrfDHav+Qb0jz1uIzXuzzRIdnvBQRMhRu1K0xGFm bWf+jjh78FgIWm/FL7N/i3zrkzufgpgfv0OkLLOWVasO8sUgSGPDhsFXIKlnP+SJ8TBD2n81wYfC z2eJniNLVQrmcJm3zTIBJEP2xkoXbCmUmZSVPv8EmUvFw1QMpXH0VhUdaPkt9yFP9Jz9MskjbuNa g5Hp4R7ky/KZcZ9+iH19zkHSiBuQJ/iRLnhR4duvESa6UI7QLaKn1ub1WC+G1hR5noYCb936qCjY 5hXjZn616jIp5GoUir62Viab5ArepopRwSPG2AqfyZJrSdvN8pb0bCAubrztfuTJJtj7pc4VZFJK 9Eei2wmmFkx4AlGLFmL3ZSOx65yByKmQiFSpU5X5n6NIyspteAJCpZww8azYcNdDSG3cHHldTsOG P35GN1kb/Ne3p2Drzl3o8PbLWJPrRS/RuXbKsi8z0rLRIcqDPnu3Y8GSn7Bp2ofoseYH7D2tF/be PIabaJmZy/x9qf5xrP3etJ1t8bWzcNEJ2M7qHOV2pu3A7AGXl43wbeIlmJOOiLRtprnnx9USZVgm EdU9EdzQ1/59YYZjRZ8xlS0Hf/g78kp/Jl10gSxpY3/uSJd3ALSpI5M0wgM4re9F47JWNfLFQ/FY 96xi/RjyEY9uFw9Bh+oR2L3gF2yXa23btjW/P+5baMJpg/GETER7Y9IlqBNheUdxfIC0LHrRaNR1 IM7t2gBFmduwYsNeM37ApSjXrVtn0eDf5n1wx5j78ewzl6J+nKwwIN8Denwx6O+d/abClA3435uf mevdunVDp54D0KZmnPk2cpk9rQ/bFL1NQ3N24eVp801+oAuuuLkXaggOaj5zIy8dr0z72penNYbd eDZqRAo2+PqfvEEZcb+f5HULMWXucn/e4Tf2QU3ZE4zL3LG8XydehesnW+2WmfqOmYSXbrsUp/fq hYsvvhi9xavsoosuxegbrsWg3s2R9N5nWO+jVrXqWtQ98xp0rhVlrpDH8hbIM2WfKcaGT3/bITpN JhrKfnFh4s0X6RFvFd9vjvUqj/Ury+8jRH6krkmnLL8hlzdXAq4E/AoHFV5+LLgR3970XLy0IMlI 55oetVElPlLczi3XcX6IGcr7B0PhWQeAqTAwzQ0JqXTlynIhdR66EzF/rjL13d7/Qmy5cKiREevO Dlns1k1o8fSDCM9IR6EMFNPYwA4lg3YkKsmgXN1J/zPzk3LEOPDHf8YhV4wNLN/QEct/E5lxXFkG uhhSxNiw9ea7zeAdz1lOePI+NHjwDkTKUk38qGyVGYG7z+hrnldFq+Kq5ajzxH0IlffIGcobpOOb JYNxrJPSqfHB26jx0bvmPOuE5tgkBokc6XSrLELzctHk2YcRt3KZybP/7IuQNHyUua9yipAZdk0f vxcemWFXGBaOjdJhTT3xJKNgkg7lWGnhJ2j9/numzjvl78Vrd+IbGbBj4FIJtRq1xHik4ZQkS+nc J4OK226/H+FilKGXBzu9nDXIuh9rv7fgdjZxvtXOru9ptTMq2sdSvc1LL4U/+ptlx4ZtzXQIMnIx 7efdZlZN9yYVUDE2AvVE4Y0QA5d2ICjbYyFoe+TviWluCMqY+JUw831UFy8phqxadbFSMIeDbZQZ 6x8qXlJNJz6DRBnQY9gvA09bxSOLyzIRk5gvTJYQavrYPYjcu9tcp2fDnq7dzT3Fv0RZ0q3JC08Z ehz03yAzbvPF0GoP1d98CVVloJ8hvXlrrJXBtiIZmGPHlHSihZe6grPRsgQcw+4LL8HOQcP9yxIx X8zmDWgsvIQRZ+X7s23MI0gWWuRT5VBdBiLrvP6CwZxcmS29aezT8Faq7KdTKL+Thi/KWuZLvjfl 7Bdjw8brbjODvKRDOYZsW4m2z09ARZEhcfY+8Wx4TIwNDMStmo1bYVCNSrhh6XyEC9/5YpxZf89j yBfjK70miMX0MCPPx8rvjbJhOKCd/eRrZ82sdla/aoJpZ8fagKWp/GH8o/LU3y1xKyMnHwtX7TMD WDGRsryhTPDo0jhRPCs9ZjCD7YS/rWMhEKsZ9PdkNqUXfYu4hX17Ufu+WxC13ZrruUk8G5J69fdj DuWQKMsZUUcJE12lQPSFTeLhmS26jOpblG81GcCv9cFbppzMeo2w8o6xZvIGLxj8E0+o5v97AhXE 2MmwV7wqaWzghqEsgyFSvJgaPHg7POJVwaWYjLFBDASKW2zfFRYtRK3nHkOI1Cm/UhVsfPBpZMgk E33HpNTgzYmo9LU1SEbPhg233odCeZf6/iPFYHKC6FPRgnEMuy8diX3i3UU8Ih3mixFsbPrUWITJ snYFYqigsSFN6sz7/P2w7tU/nYpms63ZteulDpes3oGfxNjAQOyq26gFns/fi7Z7tppru7udgc1X 3YSK9JoVfYveY/yNUf+gDFjP8hz0HaictZ19u9pqZ5EyGYHt7KSj1M6UP/Y1+P74+y/M3I+IJW8i NG0HYrct5kgnMmt1QmFCTeSedCVC4yr79WK+Mwb9vZbnd1UeeNf3xXaZLwaHHSnZSBZ988sVe0Dj 1SUn1URiXKRZ0tHefsr6+9H2Qf2RbT85Odn8FonL/F0SE0JDCxEqk1MayKQK/l5X/rlBfocVUaWi NTjO96d9Fi4dx7a2ZcsW87zRqwRPeD0/Ox3VRDerLMbjtWvXIml3MmIS4lElTvbP8eEYy2vQQJYN lt/33r2WgYL0eZ+8ZqbJMnPhUWjatKnByPT0dINVilv6XeEzxLS9YojdsHErEiolIJK6pPDBd8L3 qct0btm0Cbv2JCNCxjiqVIw3dTZLCkt+Lt3HsHPnTtO3zZANn7Pzrf14IiJCjZcc6eRk7cM1levg Len/mtD9Psx78hxUlO8El+Tj0qSkkZqaamTF+iV/+zROHP6CWbp53rx5+CGvOq5sV8nwV976Kdo+ KP/90i5em78Z3OdkyCl1UEnahZmQIoYHbQ8aW8Jy/x6qBFwPh0OVoPu8KwFXAkdMAqp48INxPHg4 BAvWXn9+PPMkQ0rX0xCzYin2i8dD0uDhRrGhokCliB2yAulcprfpiAq/LcHmG+9EugycM+jHl+lM zsCVfFGyBMmaux81SyTxWaUTLvRSO5+MKOng5taqg0033mWMDfpBptLHTmaKeCAk/PYjdgwahr3S CTcdZ+kIa8itWh00IsQJvxvGPIxsmQFIPuz5Mlu1M3tHhMg73iDLkXhl4I/3WZY5ZHZ0shg84sTI kiqda3o2kAYP5ccbn4A06ThX+PVHbL7mFqSIl4bmIS/kN6dBc2RXkU1Zt2+WOj+G7tdchyuuuMK4 859//vk447STkX/KaYgSQ0qudNTXXHs7ImTwjnKhgkeeOGuEZdr507qW59j+O7O3M9fD4d+9Vf7e +PtjR8gx8/oY93BQaWn9iduUAw1+9HjiDNrw/XuxTjCnMLGSwSyr8ygGBzEypsryZdFbNiFLZg2r sYE0tZ0X0tNBvCEq/LIYWy+9Gsmn9TwA//LEmJEjHlVxspfNeiknV2b+MigekDdiIj0dOMi2/vax kB6fo00XiNGSOBsng3/Jp/cx+Mbntd2Tnlf4T2vdwcJZMcbSs0H5VIzIlkH/goqJiBAcXS8znvPl GdLRECLYwvpEJW1FtvC58brbxZBibTLNPOQVFarJrONuqLz8V2wcMATV77zPj1vnnXcezji1K6q1 E68KwdbEP1di+c33oECWhSKv7PBSvsQtnhPLyJvyqXyU11h/Zwe0M9fD4V+9Uv1tUp7Hk4eDCkt/ T4pbHJgqkLazV7wL4n/7CTtlGce9ssQR25HqW0x7q9dEZtMWSBDPgA13jkOWtHsGezvLFGNkIdtg Zib+FF2oSHQW0lA6oaJzpXQ5FbGy9CQniGwfcT0JGDqKXfSUShGvS+o5W0fejDTRixSTWBb5z65T z+hsMUKHmJMjOpjmYRwq/FqeDvvhFU9ZejYUSdkMrAuPwohI8Wg9DfGCOXv6nY/d58kG9cQiXyAd r3h/pYmXasLvvwiN+5ApXg+qR2jetBNawSuYHyETQTbcNx49R16NESNG4ArRu4hdPbqfguxupyNu 2yakiUfuRjGwhAkvHICjXKh3qaxZP5Z7LITgdlaWPRxkRBah239HSG4GIn0eDnkV6oqBPgEFtdsj JML1cDhav0n9HbG9FcpAalZ2HvJkEtX25FzZdyoULWrFIUomtrAN2duPHZeOFu/FlWuvD9OsV7jo aXEyME5M5gA/A9Ph4RFo1FS8+GUSnkd0x2o1qyM7M9Xk4X0exA+znO/mjYisWs3oQTQGEKcY+J2r U6+BLAss9DdtQNXGJyBGDOoFueLZ56NBzKFxlMsGc0+sWKHDe+SPseExIsrk4bJ6EeKx65FvBnml 3JmP5dEYbJa5k3Lia9cRXjxiEMgy74VYx8CJbVy1IV904EoNGspzQt+bZ/rlfGfsn9PoAPFSE+YR I7plpnxP8iTtkfccLt5RXAaP+whxubvIarVR6cQT8e6MGYaHq+8egy7Vo8zeO1WrVkXuhnWoWLee MZLQuEhec/b/io8XbACNDU0bNsAvG/eKx0asucf6MJTV349hzvbHahdsG/JdzPPilw3JUg+gRe04 493AtsEvrH5Xyku9bFUs00nXw6FMvx6XOVcCrgQoAX74GNjh48fiePNwYJ0pA9PhFWWFygCVI8qB youXMz1ESVE5FfehDKVSJEoO7+l95tdnTFqUIs1DeWs+TReJkiVPy+wNSyFShYP8MRhaMphIGnpu L89clD/c9FDz6LXguLg8yquhKXs/FInxgUH5NHXw/VaCeWE+yozXKUfG5Jt7SCgd5uF10mNs0hKH iRYSKp1uKm9U8jhbhDE7wlROqDwyKB/mpBz+YX0ZgtuZ6+Hw716mylM7Iux0cMbZ8eLhoLil9Sdu Ea/YKWJs2qHIhJ5Xpq1Ju2NQuTHNvQekkYGD8cHti/nMc/wuCA0N9nzalol/0qszWez3eUH5DCU+ 2HjRjoefrg+37PzpPY0Phluax47FvKb8UCamTuRD/oWIoYPB3qHl/ZJwi3mVN9IM5d4SYrBlx5ad WO6vw5jnxG6mTb5yPnCnddbfmb+duR4O/En846Dy1N8j5Xk8eTho/fU7yPpTd9DBKZ4X2XArWMBs U6ZNcyapYI7iiMYqV/Oc5LFjVzAtg0lsp9JG9XnNo3yKBdehTxWXrzhcUjomFlwJ4SCaDNaVFJSG qZtk0ljro3VW3U6vB+MXcYk6F/lXGva0AJ7RMaNlMI0YxVnA1LcYE7d0oofqnyXxW9av6/tTOWk7 K9MeDhn7EPHTFMvDYesPRsQZdbsaD4e8TsNdD4ej+KNTPYZYRQ+HPSmZZlmlxetTzZIxfVpXRkJM hH/CFNsWg7bBo8h6sUUHtw9OVIm8/VrgFtmfpnlLbN26FVw6idjQuLFMXhNP10LZx6tI+mcRk6bB K/2ybdu2mfrR0MAZ/Pk/fIvwm0Ygb/AwRN0l3v5icNi4caPRqXTT+4xnHkXMW68i95mXEd3rLCQl Jfk9GVhORKHorldfKstmim/8mzMQIgZm8kFa5MXs3SP7eYVeeTHy23ZA1HOvgYtAsX0zMA+NHzmy NF/k2P8gU/bWirvyWuO5QY8J6mfU1WhsyL37FnjEMzb/5amIbHeiqQ/fMzGQ5dDYUCj75UAMuaGT 3jMedRs2bDC6NevLPYLyfvoBnusvR3bvHoh9/FXMmTMHF154IeoNeRzfPnkpqgudtOefQtxr/4fs x59HrOydwzqnpq7F+7cOwsCnLWPD76d3xrqH38T5PWT5Y/kesR787ZTV348Rtu2P4izbh93DYfDJ YogRD4dEWXKTnkD6XSkv9bJVsUwnLbQp0yy6zLkScCXgSuD4lIB+8DTmh5BpDnAzzQ8oD+1g8h4P VST1A0sFRTQcI0R9nidU6HjoQHyRKDG8T3qM9cPrvy95GfS+lmNXdDlgx2f1eU3zOaWjA39aH+Xf wa+PF6XD57Uc5hMh8JIph4qPphmrQYF1Zv1Ig0Gfp/yYNvl8dEwG3x9VdJV3lTcNDCyL56w7D81j f95NuxJwJWC1TW0fjNlJYtvlABRjXuPglLZRbcfaThUPKEvmDe7g2Ns58yguKW7p86R3MPzTATHi EstRXFI6ils6kHbQcoQGA+koPrJ+PJQf0tH7jBX/lA/NbwjJH8qN13jfjlu8VlwgTR4ej7V0khoc SIc8Kf9abnE03GuuBI53CbD9s43od56DRGzDDFw2TYO2J7a5v9POFU8MLtnw4p/inx8vfLwoH4o7 dhxVnYs86n3FGeUnJMTCP62v1k/LCfHxquUoPiqumdjHC8vRoLjFAUPyVFgYwHzmsedlOkTkzDI4 e5e8UO6MKR8t2/6MluPGR0gCsicQeJQQzDu0vf8SsrmXS1ECsjKMLMcViigxIPZsHm/aGJfnKk/t RvUbxTHGIeIdFTLyYnhfew91ZPmk3bt3mxn8NDYUDL/IeI+GyP5f2TIIH/n6dNSuXRspssQQB99z v1uAiNEj2RFE1JRXkSnLucXf85CZ4U/a9ChIe/IhJLz5skzgk6UCb78GmU9NRK3e/QyukwaNDblX D0W07J9I4yzLxJQZSBCjA/GPNLxibAi5cjBCM9IRLfsq5sieNpETXjU4RiwknuV+PB2RD9yBIvnG xD7zMGSxPiSK0YHvh/dpbMiRfXmiZR8zGqTDR12K3Femoo4YHfbv328mvdHDonDEQISLl4QwiLwR gxA+eRoaNmxoDCQ0NuT+uAgRN1wOiDE59pM5WLqsJ/rPnocPP/zQyI7Ghu1PPITab1l1jr77ZqSK J0Wt8wZiwYevOYwNnbPTpJ7W/hfEfh7kV78DpfhzPiTSwb8j9hu078B7/P55veLJV+hBobQbfmMY ylNbOSQBHaGHXYPDERK0W4wrAVcCrgQORQL2j59+4PXDqB3HYAWA9/WDyrK1s6b59Dnes6e1w6n0 WTbva2dbn7fzYX+e+XkoHaWvMZU7Br2vddNyqAAwBJdjL4P3tRzNp8+zY8q8Wo7S1+f1Hu/rNdIL DkqffLIMjZlW2QQ/4567EnAl4JQA2xHbCw+2N2332v7s7Yxp+3XmZ+B1fY5pXg9u53pf26aWp3jC cz6reKFtX2PlmnSZj4cG5lH8K6kcdiYZgsvhNT6vfDPNoHRKKsdk8v1RHikblQ9jBvvzes5rpM+6 2g/ypvyZh90/rgRcCRxUAmwvbH9sRwyM9RrbGc8Z8/g77VzzBeMS2yuDtnVz4vvDZ+x4oXkYKw7o ffLGoDwyj57b6SgN3mOa9+z3mdZnGf9VOaYQ2x8tn5f4LA/SUZwkfQaNzYn8YT34rOIWz3loCM6v 1934CEhAlvgr9MhmubJ0kjeyoimwUNLmmtxzw9GVgLYNxh6ZrS3IhXjfJsS+5nZAezu6HP916Xbs yZJ99GLFQyH0qiFidHgXNVq2Qb4sUWmMDbuSsEaW+41I3Y9Gb0xE9pWDEDl5OqpXl+WVvp2PSDE2 cOnLpIeeRaW3X0XC1EnIFAiqcPdDhgk1Nuzr2BWbLr4CLWUfnug7rkPm0xNRW4wOhbKcU87ISxAj y8YlXXUjIMtW1nj4LvGqEKODeDpUlr0f8mQvmxDxbKA32NqxT6GiLL1XfcZUMTqMEqPDK/DIpDUa GyLuvw05DZtgs+zdU1v26okTo0OmvKCKI65BkeBk7t2jjbFhf/8LsKdnXzR6eIwYHYaK0eEdVG7f EQWylxA9G8JlX53dsvRwiOyzU/W/smSoGB08YmipVasWsn/4DhE3XmH2S9z4wJOoPONttBcDyIKz LaMDK73gikvQ4//Zuxc4Sary4P9P36Z7dnb2BrssK7uwwgIBQQF1MYIGRFcTJQgGeUOAvNFETIyX vB/8iwHFSAJvMIGof4Pv39xMyMdoEF+CGoyiZMWA4qIQhGWF5bouCyx7m51L3/7Pc6qfnuqenp1r z/TlV1Bb1XU5depbXTXV9dQ550f/KV/fOyTv+cV2+eaag+QYDXT8cPMj8puXfUxGBvaJlWywYMOm 37hU23JYEe6D/Xs28dFrrSX875nlSmucCo1E27T49NbKcefkZvQveOfsE3uCAAIIdJSA/3G3H13+ h9F+vNl0++wPwvwHsf/g9GX9B55P9+Ucydf35f3HnW/X5/vQ1/fl/Ieo/4D29Xy5+u348vZgzzpf 3qf7durz6/nz7Xi6ng9Px+bbsr68pePzbJq93WDb8jfu4sv6cjb09SyfNm4lHGyfrISDffbtej4Y IoDAqICfS3ae+Dnm1wT7PN51yeZZN5nz3Jbz5T1tOzetq7+exPNj8329ibbj1yNPr347ns54+2Pb ss7T8eX9+uH59euWb8fya70tb72lb/P8+uXTLW3fNxtauja0fFra1naDDf26ZdNtvq9j69MhgEAk 4OeFn+d2zsXHPdBZv5z7TXSe+3wf+vnv2/Drw0TXJZ/vy/v6PvT0fej59euOr+fpeP59vi/v6/t1 ydP3oU/365+vZ/NtG7a+LWP3W/bZ3y715WyajbuDbd/GrUSWpeFVVzYKBHueGTZfwI5JqadX9h/2 GikND8iLB70sbDSpDUYns3369yX6O9P8nLCFRgJ+Ptk8G7dzJ35e2Wc7hjYtvmyjtFplml+jLD92 3SiuPkL2XfNZOeTy90ny3RfI4J/eIIlrPyY9Gmx4+A8+LC9qG4C2jrVhcdQXb5T9+gBefuf3pfeK D0p+8VJtO+ZaKepwn7aPdZiWcFjyT38je3VZKwFmJRss2PDwuz8gZXV6QNvzOuFTV4Wgw94/+ZQk v/QP0nf/Jnnqt98rO7WNQrtOjXzkallz7RVSvOhcGbnyzyTzxx8SGR6SLf+PtlF4+JGy/4ijgvny r/yjDH7gd0XOeKPk/uQjIdjw6Ef/NLRRuOWDV8i66z8pCz/1J7JPr5PJh/9bFnzja9o+0NnyzG/9 brgP3qzbOebaPw5Bh8FrPyPJv7haep56XJ7RgMWuE04Oh2tQ2xlc89d/IUMaiCi9948kp6UVitrO 2WYNSAzrPr940aVa0GFEfuWu/wxBB9H2fDzYcO5TO0ObkG944gX5zuEHySv+7rNytzbSnbr1X0Ow 4ce/fokseOc7QrVQVvIsMta8qpMfo3b5ThlWWutJPmyp1YCgh16fhKcSOqIffF8CKP/MqgABh1nl JDEEEECg+QJ+0+g/6OyzdX4j6Z/tj6f/AbWhr+fL2To+3Ze1efHl4vP9hsJvZD0dW96Ws88+9Hm+ Tjwd+/Fp0+PpWF5seny5eD48bU/fhtbZ9Phy8fn+Q9i2E+98O7ZsfNyX8fTss6XvD+psuvc2nQ4B BCYnYOeLn6t2Ptp55w/u/HzzZey8jJ/HtgVfN76MjceX9XmWnnV+bttnTy+eTnxdG7cuPt/T9/Ut Pd+GL2freDo+Xr8/8em+rK/v6dl09/AHfL4fvr4PPQ0f2nTr6rdr6dk087Y+Pj9ag38RQGAiATtH rbNzyMb9vPNz14e2jM2z8yy+TP1552n4cvH5Ps/W93FL18bjy8Xn+7gt48v5OjbPtxOfb+M2z9e1 oa9Tvx1ff7zrn8+39T0935ZNs/m2rvfxbdv8+LI27s5+/bL1raebX4FwnJIaRNIGostJbcy2UhK5 J7dYq0bs1XZGovNjfnPJ1u04WVc9ryqf2/U88uuUH9mRI14q266+QQ79Yy0FoG/wW/uFW97/Udl9 3ImiDdOGxZ47/Q16zUiEkg6Jy94rwytWys+1ofrCsoMlactoaZyn/kCrNNLxpf/8t2GdnRps2PKe PwpuOkMK2gjzgx/+hBx/3ce16qUPhGWevORS2fnGt2pLhtG1bp8GOJ7+6J/JYX/2UW0n4eLwgH+L Bgf2a+kH/4X47Dt+K6xrQQe58z9k8Mhj5Ikr/7cUrfo53U5Jgx0//6OPyVEadOj/y6vDsi+85Rx5 5qLfC/mzCUOrDpNHdDtH63Z6tYSHVcX09B9dKXtf+Rqt3Sxq+2vXaWfokmUNOvylJD70uzJy0PKw zvDBK0I6Vh52y8V/IEWtN+hX/utOkcc3y30LF8l12j7hYRpweEznP6dBmN9J9MuXMgk59V8ilyfO v1hKWtKiU7rwN0p3pj+nv0PUP6N/W1J6juhfw07ZxZbcDwIOLXlYyBQCCCAwKuA3kP6jyz/b0P54 xjub5svZDzyfH/7I6jyb772tZ9Pjvc2zztOJz7Nxn+dp2HA2tmPpTpSOz7dtNsqLpXGg/Po6FkCw tOzBnk2z8Xjn+2bTbNzeZKkf+rz4eowjgMBYAb8e2QMk6+xz/Dz1882Htkx8vn32eTa0Lj7fxn26 DX17fr3w5eNp+PLxdGw5m+7p1efTp/ty091Oo3Ti+bBx30YYqfzj1ysrsWDLTPa6Zfm0/Yr7x9Nl HAEExgr4NcLf+Pfrgd0/xM9RW86XrT+PfboNJ3u98OuWrdPM7dgex/Nrn22b3tfPt2Vtni830f54 3j0db4vG9y8+35bx65Rv365XNu7TLRBhnechfOCfpgu4vw2Taf3u96+QkgYbStllYdvlnFaxpPfI qUxUIsUDRk3PGBtoKGD+dm6l9XgU9QHy8HCheh6l2rBRXL8e+M7afdCIlnR4TB/aH6GlC5581/tl 4MSTJVP3O+7FM94sT2gQbOXXb5aff/QaKRx0cDVQYGnp1Uye0JIA4bqmDdk/riUkeip2Yb7dh+nD +s2X/1koXfDcm94mz5/1a1pNVdRZPixvLx59nOQvu0rWfO4v5DGt8mn4pUdLytbVzubbcr849zfD /Vq/VrH0mJZsCMGGKJkQYNViqPKYllY48lOfkEHdt20abPDO/v5YHkdeskaDJtfKkddcIc9o4GPv yeutGHBYzK+lL772DN1OWVZp9UkW+BjRQIvlN+yj5iWh5/DmC7WkhWYvo+1hvKilOT5Wuc66sw2f 3bdHVl5/tWw/9XXy3IZfF7vy2vnv12DPWzsObf9ymaSccnhfyH4um5KM1q+U1Ol0zRMg4NA8W1JG AAEEmiJgfzCtsxsA6/zBk39uNN+m1U+3dW2arW9Dv2mJp9Nofn06vrynUz9/MtuxZSZKx+f7zZOt Y51Pt/GJ8uvrxtdxP1vfuvr8+w8om+7zoiX5FwEEpirg59FkrxeefvyctTR8/UbXLVvHl/fl/Nz1 6bZMPB37bJ3Pr8/nbG2nUTrxfPh8z6/lyab5D0/7bB3XrciBfxGYC4H664Fv068X9rnReezz/Xz2 z+Ndl3y+nfO+jqXt02drO/Xp2GfrZns7fp3y65c9gLPOr3Phg/7j27WhW9vQp/tyDOdHwI6D3QuH oENCS82VK79DMlrFqE4P8yq/SeYnh2zVBex5t729XdCHz3sGC3oOJWSBvkkfv574sq08jOfXvn/x a+bw4S+Vzdf/bWhU2UotxJe1fbLry84zNshuLe1gVSbZtzV+PQnXpVQ6KumgTvYdjnd+fSpquw8P ffKvJKlBAXsT3jpLJ769gZedJA/f8Lda0qenup34fFtnx29cJM/9+jvDMh60sOl+fRQN3D2mVTFp kfqQhs3zNGxo+bGgw+br/ybaTiwv8XT2vO4Nsmf9aWO2Y1XnmaHt5+YL3211fFqxvTH7YmkVtOTD fZf/qeYlK5nKvoZ1Y+e3582Wb5fO85zS/ejtiQJzPWkr/Rsd13bZj3bMJwGHdjxq5BkBBLpSwP9Y 1g9nijHRWwsTzZ/s9mcrnYm2N9F2/AbP31z0G0tP133rP9sNl3X18305hgggML7AVM+fic7jieaP n5PaOROlM9H82tTG/zRROhPN57o1vi1zEGiWQP11a6LzdKL5s5XP2drOROlMNH+y++PXL7/f8mH9 /ZR/rnef7HZYbnYE/Dj40Eqc2HfB63D3Nju8JIpXPWrLez87OSGVyQj4cbKhVQ+zd6gou/fn5faf bNM665Pyzl8+XLI9o+3ZTSbN+Vwmvj92LbDfazbNSkpZ0NKuH+VKqVnLZ/z3nM3zZWyerefr+3XF HsDbcn5dsmV8OVvHplfT0fb74vN93Jaz8yDkRQMF1tk5YvP9uun5CNuxYELddnx+GNbNt2W98+1Y 8MS6A+5PZRnPh+XP3CwPQ0NDYej7b/Os822ZTxjX5W3cStTavlhbOrZNb1vHl/P1QiIt/I/l1/bV 9sGPuWXXplvvnu2yPy1M3TBrBBwasjARAQQQQKBTBSa6oaifX/+5U13YLwQQaF2Bia5D9fPrP7fu npEzBBDodIHxrkf10+s/d7pLO+yfHxMb2sNHe2BnAQbrbJo/fPTPYQb/zKtAUd/az2uVSvs08JBO 6YP1yoPlec3UNDbu3z1/YOwP8m1oD5Btvn8vbWjTfLoNvWv0QNnm24N+6yw9T8c+ezo2bp1vJ56O L2NDf4jtAThb3tez+faA37r4dmwZ3y8bt+XG246tG99OPB82z9f37fg5aUOfb3m0/fW8WnrW+/z4 0Naz3vJr27KhT7NttWtn+2C7XKh8NTKhpFb77k+7HAcCDu1ypMgnAgggUCfQzn/063ZlTj/iNqfc bAyBGgHOvxqOSX/AbdJULIjArAtw/s2MFL+Z+c3X2vaAzjp7kGqdPXi0zh9a+nyf7p/DQvwzZwL+ 4NgfIheKBbHeO3vQbL0fn1Y/Hz1//r2y/bJxm27fPf8+1i8X318bdxd7aG6d778/mI8HHGx+fHv2 2Uvy+Ho+3+ZZ5+v7+eD58uV9vg99uufH1/P8RKmOltjw/fP5vj+eDx96+j709eLzbd3h4eHgZ/tl 27ZpnqatY+M29MCJl2jI5XLBxgMdvh+e31YduoMNrbd8F7TZxl/sthIuIoev0LZnrA2H0Oh9q+5F ++eLgEP7H0P2AAEEEEAAAQQQQAABBBBAAAEEEGiKgD/A8weO/rkpGyPRaQvEHyT7A2VLzB8oTzvh eVrRHxb7984eiPu+2DzvfR9tOTfwdX0Zmx5f39axB/M+34bxdSezHXt4b+vF07F0PS3Pjw3j2/Hp vpyvE1/Otx/Pk6dhy/k6Nj+eni9j8y1flkcPMtg0T8+G3vk6lo715mRDCzTY0Of78u02tPxbaR+r ciy0c1LU70JKj7f+p9+idtudtskvAYe2OVRkFAEEEEAAAQQQQAABBBBAAAEEEJgbAXvYaJ09sIt3 9Z/j8xifewF7w71QsNIMVn2O9qWiHjN9q1ur9CkUoofI8YfGrX78/HvnJQLssz0g9wfnvi8+NPH4 g3Qb9320oa8fX8bW8fV96Ol7ej7dhz49no7Ns86Gnu+ppuPrz/Z2PB/eloN9TyzvNj3exbdr41Z1 mg09kGJDz2N8vVYft33wfI9owZ8fbHlBz42SrFy8QMp9WqJDSznojrb6brRt/gg4tO2hI+MIIIAA AggggAACCCCAAAIIIIAAAt0s4A/A7e1te5icTNrDb32rWx8w1z9cbkcnfyBu++njth/+gN/Gbbrt qw1tOet8vq9TP9+mx5fz5X25+vm2rE3z+Y22E0/Pl5soHVvHOt++jc/Gdiw9N4unbfmKd/H82bj3 8XXiy7fbuBlYEG5oxIJxOl7WwIvY43CCDc08lgQcmqlL2ggggAACCCCAAAIIIIAAAggggEAbC/gD yTbehY7Muj/w9p1LlkuizSpLbyYlKQ04WGfL2APmdnx47Hn275+/ae/7Wz+c6fz69Mb7PNF2xluv fvpE6Uw0vz698T57gMFLjPhy/v1xX5/u262f7vPbZWj77d9/G48+a+PRViKoEoyzKpV8f9tlv9ol nwQc2uVIkU8EEEAAAQQQQAABBBBAAAEEEEBgrgWK+WiL+kA7dMnKoyRtdJVufgX8obHlwmIMVjf9 wmwUcAi11Ffe9p/fXLL1+RSYKHAw0fz5zPtsbNvOET9PfGjpRuOUcpgN40ZpEHBopMI0BBBAAAEE EEAAAQQQQAABBBBAoIsFwoM6DTYk9mwXKY5IaXi/Vreijcj2H6Qt0vaI5BbrU+6o4d0uZmqJXbdg Q182Kbl0Rs48tj9Ui9OXTYdhS2RwBpno9AfiM6CZ1Krd5udBBS/hkM/nxfpwPdPgQ9S2iTWonZGS njf1JWkmhcpCEwoQcJiQiAUQQAABBBBAAAEEEEAAAQQQQACB7hNIaKmG0sALIvlBSQzukbIGHJJp fZSU6ZVSVh9sayU+dPMn4A+TbZhJ6bHRKpX6c5lKPfxRvnyZ+cslW0Zg/gQ80GClfyww55/nL0fd sWUCDt1xnNlLBBBAAAEEEEAAAQQQQAABBBBAYEIBf0PY3gSWgd2S+umtInt+IcltD0o5lZHiy88R WXSolI49SxK5/mod6DzYnpB2VheIe9u41UVvQ39j2z7buE2LLzurmSAxBFpYwK9laQ02vGRJVoMN IlrwR1IJHYlVtdTCu9C2WSPg0LaHjowjgAACCCCAAAIIIIAAAggggAACzREIbwKXCpLSkg0ysEvK A8+JpPWh3dA+rU5pvz6v0zYd7Ake3bwKeDChGljQAIN1Fmzw4MO8ZpCNIzCPAnYdszOiP6fVKOl4 Rs+LlJ4j2rLDPOaq8zdNwKHzjzF7iAACCCCAAAIIIIAAAggggAACCExKwOs+DyUcrJRDflgShRHR VhvCI7qiTitbnejFoiS05y36SbE2bSEryWAPVdOZrBSLJRkeLlRLOqS0miWbb50HJpqWERJGoAUF 7HufyyTllMP7Qu5y2qh6Jq3BuEpgrgWz3BFZIuDQEYeRnUAAAQQQQAABBBBAAAEEEEAAAQRmTyAE HvQBtj04sjeErTBDKPVg49rb/KRNpJt3ATsM9vZ2oVSWPYMFDQIlZEE2S5Bh3o8MGZhPAQ+ypbRU Q29PFJjrSVtVY1EpoPnMW6dvm4BDpx9h9g8BBBBAAAEEEEAAAQQQQAABBBCYQMCCCdZZIMF6K+FQ LuQlpSUcklrCIV2pgiRfKOr0opS0lEMynZe0NiJtD/aovmcC4Fme7Q9TbWjVw+wdKsru/Xm5/Sfb JK0lG975y4dLtidqw2GWN01yCLS8gF2PQskfvT7Z9cw7m269X7f8PPL5DGdHgIDD7DiSCgIIzLOA 3xxbNmycPxrzfEDYfFsK1J9HbbkTZBoBBBBAAAEEEEBgVgTs3jDEIOyfMKJvBYfRcvQAL4pP8Ptr VrRnnkhRSzfktUTKPg08pFN6jMIxm3m6pIBAOwtEgQcRrQAu7EaibENKODT7mBJwaLYw6SOAQNMF 4g9JfWONpvk8hgggMFag0TnTaNrYNZkyHQGzre8tHcyno8k63Srg50ujc6lbTeZiv+Petj0/DnOx bbaBQLsL+PkSP498Wivtm+cvlHCwthq0ceh4A9FFvY+xh9lRywCtlPPuyot/d6rHq1iQgvbeFbV9 Devtgat1vJTnMgw7WcC/5za03r7/BS3g8MyLI3odEznikIWSsjYckimd38kS87tvBBzm15+tI4DA DATsb4O9xWF1VKa0Dr6RckYbxLJGsUrhD4v/oZnBJlh1FgUK+rZNvLNivnStI+A/VPyHyX4tjr1n MPqRYnVe0s1cwK5J9iKg/Ujfny9JShv0e3EgLz2ZkmRGoh+B/oNw5lsjBQQ6XyB+3bKi8oODI+G6 ZW93Wsn5hN4b8ENyht8Du2jpDZcNhvW6lUgUtLqOoowURXry0Y/4ZFLfGQR6htCs3i0Cft2yoV23 hofzsl/vBwb1pBoplLX6Gyup3RoalkfvynZRjX/WWfbR98eXYzi/AvHjUXP89GBxnZ7fY8PW50/A vvsWILUqx0I7J8WyZFJRNWR6pzh/GevwLRNw6PADzO4h0KkC9mdBA9KyT2/Ov3bf8yHg4M9EEwke jrbScQ83vpqh/EhB/8BHObM2mjI9WterfuTmt5WOlv1wjAJD9ruyoDdjwzpclNX6L/XgxX+4tFau 2yc3ab3Z3acPFr730K6Q6XTmeUnqTTDXrfY5huS0FQWiPy5FvWbZiwg79+WlL6sNA+rnhM5qlYd3 rSg3UZ7MLq1/tO0H+gPPDGhVHTbcx3VrIjjmIzBJAbvvsuvW3qGC9KQT8orDFktKf8u03HWrpFFG 67WzK67dv/tDvIReH+jmV8BeGCpomxpFDbiHXo+V3VtaCZVCIaqv3o+Z5ZTfX/N7vNj63Aj499yG +ihC7n70Rb3eluTQJX1S7ktIRks56MkwN5npwq0QcOjCg84uI9AJAvZ3YVFOHyboHwxrIMtu1P3m t6TFSP2PSyfsa7vvg/0GsQcVI/nagINFG+w4JS36QNcSAhZQsONhQws42A3Ywp6E9GvAgeM080Nk 162+nlQI5OweyquxVUcQNWZmDxy4bs3cmBS6T6D+umV/cxZoA5nW9+gPSfsxSbB0+t8Luy7l9CGo 9dmMvdChD7Ts3kunc92avitrImACdm2yewO7T7bTK6vXq1xGzzU931rlniDcE1ZeRgl5Dr+4oqBD +O3FoWwJATtO0bGKSs7Yfbv1JQ1ExBvLbYnMkgkE5ljAzo2iBuEGh+0eRsfL2ui92ONwnkM081AQ cGimLmkjgMCsCtiNt9989+mDhLcev1jyWhmfPqbT6fpQIZMJ81MpahOdVfhpJuY3vvaWzaC+UvCw vhE5nI/ejMpm0nLsSxZITks5pFNa0kH/1vuxnebmWG2WBOwNKTt2IyNWx2VJ9B278MCuTwMP1sXP w1n1zMlDAABAAElEQVTaZEcnE/fq1acJpx3dH65bw/oWmt3kZtLRdSud5paso78I7FxTBfy6Feoa 1+tXSX9IprWo/MpFaa2yLBFKQTY1Ax2ceEZvqY5bmdOXBjJy1MGZEIzu6ekJfwusCji7xlEVXAd/ Adi1pgnYQ+DwEKxy32XXLyutfVBfVq9bKS1Z1LRNTyphv4/3hS07NVmyoubW082rgB2neJfUe3d9 JU969TtkVQ5bZ8vY941rdVyK8W4Q8OusDb23U6ZgJYIqwTh9kqRVcnMta8b3gV+3zVAlTQQQaLqA vbFhJRyKxYQUrdix/pfWO3P74ZtO8wej6QdgEhuIfqiIPqTIa9Fw/UOu97z6nmlYM6lhooV6/Hr1 be+MtuVgx9OOHd38CxS0/mA7dnm98dLyDvruh92EUcJhpkfGvt/WFsZCLS1S1LuvkUL0fffrVsae 6tEhgMC0BPy6VSymwpvCdlcQ2nTSp2P2vMUfjE8r8S5fyap8s7ettVlFKfWm9Qe7vomtwdNwTdO/ EzbkIVaXf0nY/WkJlEpRidL49cvuh3N6ftm9gZ17rdJZTqwsuf0XcqV5szt661spn63iNdf5iAcd 7G+e1U2/UKsVtICDHan4/LnOG9tDoBUEoucS0XOI+PkQjbfOtbYVrGYzDwQcZlOTtBBAoKkC9qPW ei/J0KOtrJb0GZ292Whdyipq1i5RzIch/8yPgP8Rt+qu7MFEWd/kLmvJhvzIoBQqJRz0FliKw2kt zqhvcGlph7LdEFca4bBjTDd/Ano07MV7PR5a0aV29ua9HZoeLUFk434ezl8O22vL5uUPO+1BQkb7 pBIn09GbjfoIL/rFXoiuW3z/2+v4ktvWEPDrVjKh9wN6/UrqiwjRdStd89Ya168DHy+//vjQ3/jL 6N9pu35ZyZHoZdroepXUKuHCn4wyf7cPLMtcBMYKJKOTSe+r9D7A7rv0IbHdAqctwKfjdv5Z3yrX rbJWR2L9aGfnffTbzK8Zo/MYmw8BvUxr+0VaLZeWnj3z2P7w3VmgL3dZ5w9c/Xea52+iY1e/POtF Arj4N6F22Counisv4ZDXFyCtt/xZH7Vtoi+plLTkpp43/uLEROeDp8twcgIEHCbnxFIIINAiAv5H wIb2trD98k3ozbh3Nt2X8WkM51YgCvvoNu1XU/R/aGtDR6tdGLdjp1PszSjvbQGOX5VpXkbs+NmN WLpyXtmxsXPNj4sP5yVzbbxRu5ENrloCy04N0ZIk1tk0M3VXH4aZ/IMAApMSqL9u2Ur2gNzOO/8R adM4v0xh8p15mZ8P7W+BXbO8c08f+nSGCCAwsYCfSfEXbvxciw8nTmlulrBbl3D/rkPLu+XRet+P uckFW2kkYMfBOhuGkuN6VPpzGb1e6+2mvvxlL3wNapVdifB30RqTHr3vzGkJW7vXz2p1xTa0ztbL a5W41rbI/iENNDU4yqyHSyt/X6w9nOg3bPS8Idy76PfaqxnTL3d4PhG+8PzTNAECDk2jJWEEEJgt Ab+Jsrd87I+FlXDwt+7ss0erfTmb5uOzlQfSmbxA+IOui1vJEyvhUNAbVjteSe0Txehnif24smnW 21vzoeoLHbeOYxcY5uUfP3f8GNqxiEo4aOOrWme3PXiyY2bTOU4HPkTuY2bm6dctG7c+aiNj9Fpl 03ydA6fMXAQQiAv4uWND6+w8Cn9z9Nzz65aXjIyvx/j4Ah6ksb/j5pnNZvXveVT/tw29c3v/zBAB BKYmED+H7Fyzc8+vW36/ZcP57CyP4fpqDUfXNB5twQYPQcxnDrt72/F7R//7Z0Prh7WtwyefH5I9 gwX58ZN7ZWgkXkJFSy/rQ9ljX7JYlvT1yPojl8mCbPR40Nbbsm2P7BoYkR/8/AVtaDcq9ezSrIdL u3xfTl7TH6qpi661Za2SWyt21mualSSzF1OsvcIypTT91J71IQGHWSclQQQQaLaA3YzbTVT8QZ79 EYn/CG52Hkh/fIHwo0Rn2zA0OqzHy49VfC2/GbZ53tt8m043/wJ+fOI/eDk20zsu7mZD87RrlT0A 5bo1PU/WQmA8AT/XvPq3+N+W8dZh+vgC7ul/B6K/66P3W/73fvwUmIMAAhMJ1J9nft2y6T5vojSa Pd/Odbs7tz6c9xrfreYvivU2OwukP4GAf1fs+2OdHScb1UHovZFcT8aW13fCtC+F3qf70F4as97n +/We9XCx70R914rfF/vOe2e/vez61a9tSNo5oc0T6jXMrms8d3CjZgwJODRDlTQRQKApAn5j62/6 2Ge/+fFhUzZMolMS8GNhdSMW9U42kdQHrIm8FvHdr6UdoqQyqbTkcjnp1eK+fQt6QwkHe0BknR1X utYQ8GNhQz/v/IdMa+Sw9XPhhhZgsM787BzxvvX3gBwi0H4Cdt5Zb+db/Prl52P77dHc5tid/O+y X7fszWuuXXN7LNha9wjYeRfv/b7Lz8f5lAh35tZWXnhApznRvBa1L2mf0p5u/gXs++K/wWxoNQAk tNGwlx6S1t9fZTnsoN4QQPDvky1jJcz7sxnJaEkH/b/aLmJC5605uFcOXZKVQxZnwu8530PWw6Vd vi9pbQvHSuPYd9a+99aeyWnrFoev8iJtVD2tJRy4fPmZ3ZwhAYfmuJIqAgg0UcBvlPzBZ4hY89ei ieJTS9r+qFsXPaCIhv7Qx4+dDW1afW/r+TI2Tjf/AnaMrOO4zM6xMEfruW7NjiepINBIwK9Xfv1q tAzTJi9Qf93yv/OTT4ElEUBgIoGWv27Z/X3lHt/u9PVuJvwX3fVPtHfMnwsB/w7ZtqK/f1qlZ1qr ttVb+SULakvWhmU1VtSnD2Et8BBVLRMF6S2ElLEqZ/R+dXFvOjywtSr2rGM9XNrl++JVJvn31j73 aaDBurQGImw/6JorQMChub6kjgACsyjgN1H+xk/9gwR+AM8i9gyS8uNgxyuZLEk6X9A/6Fr3s/5R t946G6a0lEM6rW/VhDY59M0aSjjMQH32V/XzzVOu/+zTGR5YwN3qh76Wny/+mSECCExfwM8zT6H+ s09nODkBv89yR7//8rW5frkEQwSmL+DnV30K402vX26uPie0rnPrvQsNxuq9Pt38Cvj3xK/X9nvK rs023V5uKQ5roECPW6o8EqZLKQoc2HLRutY+gz6ELdeWwC1rSfWyBhnSktc677We+1LUjgPr4dI+ 3xcNoOk32L7n1ts5kuuJSpzb/Yx9tqHPn98zuTO3TsChM48re4VAVwpEN01duestudP+x9uH9Zn0 6fGhLWOf6RDoFgG+791ypNlPBDpPgOtX5x1T9giBhgJ2a+4lHCq36VaygdINDbXmfaJfm21ob3Vb eRQLEFljualKyWU7nmG+Tg9L1P3+so9h3cpxZ73osOLSXt8XD8TZ0AJx/qKEffZ5837CdnAGCDh0 8MFl1xDodAG/mer0/WzX/bPj06i3/Wk03Y+nD9t1v8k3AgcS4Pt9IB3mIYBAKwpw3WrFo0KeEJgb gfCALjyoi2IOlXiDvhCvbQZob9cHrhFzcywOtBU/Bv4Q1R+wWklyr8bTjqW1sWedzbd1bOjr+HRb zkoy2HrWsV7khUv7fV/8+hQ/H8KXWv+xefY9t87Pn/CBf2ZNgIDDrFGSEAIIIIAAAggggAACCCCA AAIIINA5AvagVZ/Nhd7GQ+cTOmc3O2pP/AGqDT24YDvoD1ht3ObFq5TxdXwe642+PGcm1uE5GmRs t++L5devX/G8R0eWf5shQMChGaqkiQACCCCAAAIIIIAAAggggAACCHSCgLXf4G04WLChVOltnK5l BPxBarzNHXvI6m94xx+42rLex5e3nbFGolkvCsjEDy4u0XemXb8v8e+/HVc/X+LHmPHZEyDgMHuW pIQAAggggAACCCCAAAIIIIAAAgh0toAFGgg2tPwx9oBCvFoly7Q/aLVARKOO9XCx70D9A/pO+L40 +r4zrTkCBBya40qqCCCAAAIIIIAAAggggAACCCCAQNsLJLR0g/Xele1hJAEH52i5oQcU/E10H46X UV/e5/tn1qstwYNL9A1xh3b7vnh+Gc6NQOOw3dxsm60ggAACCCCAAAIIIIAAAggggAACCLSygLXd 4O03WDMOGmxI2Nvx1SYdah/MtvKukDcEEEAAgeYLUMKh+cZsAQEEEEAAAQQQQAABBBBAAAEEEGg7 AQsllCv/VcMKiaROqX4K+1T/1nPb7WgHZni6x4T1Gn8ZcGlvl8a5Z2qzBCjh0CxZ0kUAAQQQQAAB BBBAAAEEEEAAAQTaWMDqcbfQQgg8WCkHq0rJBjalUq3SdB/EtjELWUcAAQQQOIAAAYcD4DALAQQQ QAABBBBAAAEEEEAAAQQQ6EYBCzZYn9T2G6yvdsmUiPV0CCCAAAIINBAg4NAAhUkIIIAAAggggAAC CCCAAAIIIIBAtwlYgMG7MG4FGXSC9dE/PpchAggggAACjQUIODR2YSoCCCCAAAIIIIAAAggggAAC CCDQVQLx6pFs3AINpVIx9CHooJ8TqVTouwqGnUUAAQQQmLQAAYdJU7EgAggggAACCCCAAAIIIIAA Aggg0LkCY0o4hF21Ug9RyQcLQvineHCic0XYMwQQQACBqQoQcJiqGMsjgAACCCCAAAIIIIAAAggg gAACXSJgD4784VEIO5S1rIP1VgKi0nB0l1CwmwgggAACkxBIT2IZFkEAAQQQQAABBBBAAAEEEEAA AQQQ6HCBeAAhlGZIJKWYXSTl/KAkkhkp9eh4OiuS6ulwCXYPAQQQQGC6AgQcpivHeggggAACCCCA AAIIIIAAAggggEAHCcSrVLKAQ0mDDTuOOVfKI/tFigWRdI8klh8jqdxC6UllKOHQQceeXUEAAQRm S4CAw2xJkg4CCCCAAAIIIIAAAggggAACCCDQxgLxEg7JpJZuSKak1LdcSzYMSVkDDgkNMqQyuRB4 0DqV2nhPyToCCCCAQLMECDg0S5Z0EUAAAQQQQAABBBBAAAEEEEAAgTYTsECDdel0WsrZXhk5aI2U ikUp5PNi87J9S8K8TE+PpFKpUMohHqhos90luwgggAACsyxAwGGWQUkOAQQQQAABBBBAAAEEEEAA AQQQaHcBCy6EgIK22ZBMliSlbTjYtKQGIhIaaLBxAg3tfpTJPwIIIDD7AgQcZt+UFBFAAAEEEEAA AQQQQAABBBBAAIG2EvDggQUZQkmGbFYymSjIYG07lEqlEGDwaV66wZalQwABBBBAwAUIOLgEQwQQ QAABBBBAAAEEEEAAAQQQQACBIOAlGCywYAEHG1rnAQkLUHiQIszgHwQQQAABBFSAgANfAwQQQAAB BBBAAAEEEEAAAQQQQACBIOCBBGvDwbr6oEI88NBofliJfxBAAAEEulaAgEPXHnp2HAEEEEAAAQQQ QAABBBBAAAEEEGgs4IGG+iqTfHrjtZiKAAIIINDtAgQcuv0bwP4jgAACCCCAAAIIIIAAAk0QKD53 v/zz9XfJPlkhb/3YebI6N/FGint3ypPPvCCSOUjWHLlMogpcJl6vXZfY88RWeXr7oGRWHibrDl/U rrvR+fkubJNbP/Z/ZasslTdedoEct7Szd9kDCvVD32uf7p8ZIoAAAgggEBcg4BDXYBwBBBBAAAEE EEAAAQQQQGBWBH564xdk4w1DmtYaefPHJpfk5r+7Vm74yC5deIm879k/lxP7J7deey41IN/49Wvk jkc090efKZ/6yQXSziGHbffcJT99dI8sOPJlctr61Z0VLCoMyL033Cfb9VA92vtS+fSVr27Prxy5 RgABBBBAYA4EknOwDTaBAAIIIIAAAggggAACCCDQTQJ775evXWPBBpGV158raydRusGWzWT9kXuu KxocXLDW9lq7tZn2fkA/9DO58Yx/kFvefYvcpMPHokMf7Vsn/JtbJ+d8YknYk6FrbpOf7e2EnZr8 PliJhng/+TVZEgEEEECgGwUIOHTjUWefEUAAAQQQQAABBBBAAIEmCjz1b7eHt8FFcvKGtx3TxC2N n/Two3fKx17xYfnwKz4mdz46PP6CrTBndytkYmZ5aO8Yw7Dc9cmr5f1nvl8+9tE7pdG35eXnnlEB 2i7/8b1tM8Nqp7XLZZHiiJQLqpLXvqDjpZKITadDAAEEEECggQBVKjVAYRICCCCAAAIIIIAAAggg gMB0BQbkh1/ZEq186i/LCavmpyWGwu7nZfsjVj2TyC922yPkbBjnnyYI5I6R9952vmzaslsWrztZ XjrJEi1NyMk0kyzI9k1PytDdooGy50PAof7bkjryFFl/9C1yj1aB9eCX75WBt50tfdPcWrusVi5r YEEDDeVn9Xy2gENKz+VUj8iyNVJOq1AyI1r0IZR+aJd9Ip8IIIAAAs0XoIRD843ZAgIIIIAAAggg gAACCCDQPQLPPSj33B7t7spzTpRl87TnuQX6MLTSZTL1j499DsPZEUjJ2jPPkvPec56cdebaNqwe KifVb8vizDihqRVy0nlRtUpy873yaDdUqxRKNxRE9myX8q5nJGG9jpfyQ1Iu5mfnq0MqCCCAAAId J0AJh447pOwQAggggAACCCCAAAIIIDB/Ajsf3ixRuQKRV77p8IYZ2bHpTrn5/3xHHvridrGqeJZs WCdvuvJCObx//MDA8HNbZeNXvy/3/fsD8tTWIRl6ZEhyp66U1We8XM659BxZtzwqSVHctkn+z3Ub Zd9PH6xu+/YPfFp2nLpQRgb3ySEbLpAL3ry6Mm9Ytm7cKHd89T7Z/NOn9A13TffonCw5YbWsv/Ac OefN6ybx8HxYfnjdjXLbD16Q4/7wfXLB6wry7eu/It+66VHZZXk8eokc+Ttvkv/xe2fJikm/+T+1 fA0/cZd8+oO3y95DjpNLb7xAinfcKl/6zPdly+12JHKy8uJXyTmXnSsnH9nonfxh2fLvt8s3btKH 6DdHxyN39Eo58sLXyNnvfpOsXTqZEipq8Okb5Vs/2ivZE98k77/s1ZWH9tH0275bsfnlYbn1ui/J 92/eojaaMz1+L3/3OXLBb55cV1pgeqaRw3dleGG/nHH1pfLaw2u/T9vu+JL87Wd+LnLIUXLJZy+Q 1emibPr838vGh3fKg5Ugmdx+m3z6o8+Ifltk3+AhcsE1ulzluB31ppNFrrlDTbfL7d96Sk48z79H 1a9aR4yUtMqksgYbSgU9OzXAkL7z/9VAwy+0GiXdvf4VUtrwx5JYvEqSS7W0QzJNCYeOOOrsBAII IDB7AgQcZs+SlBBAAAEEEEAAAQQQQACBrhfYfl+lOiVZKUe9ZOwD7q03/5Vcc9FoMMDAdt2+Rb58 +1Xj2u3c+CX5yAZ70FvbDd29XbZof90198i7n/hzefVykaHtD8p9n69NX+7eIvdpdTnWPbrqxUrA YYd86cwr5I7K9Giu/qtBgl2PbJHbb75O7vnEpfLnl+lD5gN2BXnqmw/Kdk1n++2fkp8dvUurchpd YUirdXrwI1+WK/72Cbny3nfpQ+7ReY3Hpp6vwgvqcPt2TW67XPXID0Q0cDLaDcn2L26UG7/4Izn/ gevkrCPjD+F3yq0XfURuu3l0aRsbemS7PPjxW7T/rlz4wCfl9TXr1C4bfVKDrz0oT5rlM4/JcDXg EE2PbK6WTRpe8mCUrWfH7567b5R7fnShfOb618dKFkzPNHJ4MmTpqQ9pFUB1AYdd//0zeTI4jciL 14ms7h+QR/76Hnkwdrxs5S033BfS0G+LvPgnowGHRS8/UdbIHWJb2PtMhxdxsICDtdVQLIrse14S 2ltXTmpFGVq6oVwqhKBEIkzlHwQQQAABBEYFqFJp1IIxBBBAAAEEEEAAAQQQQACBGQkMyEPftQff 2p16nKzsj0b93+K2O2uCDWsuf6u8+7YLZf15OV+k4XD73Zsq05fI+uvPl/fdc7lc9t1L5KQNvvgu +afrfxg+5FafIm+9doOcfvFomrmL18tbP7dBNlx7ppz9upXRSnu3yw/sAbl2S85bL+ff9j65fNNl csnnToom6r+7Pv73ctc2feA6QZdZ7At4sGGJnP6FC+WSL5wulUp4NJBxj3zmcz/zBccfTidf1fqA NNlKsGHlBzfIJV89X44/1Tc1JF++amNNg8j3X3ftaLDh1JPkku9fKVc/dJm8/fKKkYYHbjrvy7LT kzjAcNQgU1MqZHS6BxvWyIZ/uUTOv/b40dQ+f5PcUdew9+h6UzCNO4ymXh3LZPWN/EoXxX365JRP vlU2XL9+9DhpiZD119u0DXLm9WfLyl5fo3a4/Uc/l4HaSW3/yUo1WF/UIEOhUJDi8FDobVq8GykU xXpbxnpfL74M4wgggAAC3Ssw4bsV3UvDniOAAAIIIIAAAggggAACCExVoPrMt0Fd+A/+63eqya25 /oNyxXuOC59ffeZp8qrT/lI++yEvHVFdLIwceeFvy/nHFuTVbzlRFlV/xa6VdV9ZJdctukZsraG7 H5M98mpZtPw4Ofv9x0nx4Yxs/OJtYf3Xf/C35Oxj42/26+T+Y+TSr14oQ+tO0qqGFoXl7J+1x66T NT3XySffHVKVp57Sx8qrRudXFxxv5NTT5cpvXFSthueVJx8sf3jyLWHpXR+5U7b9/nGyqroPDRKZ hXydfttVctGZq0Lirz3ryKqR3Pyf8ujnzpLjLBD04v3yrx+vlDc4er1cdce7JFpD5C1X/okcIh+W G6/R+Y9slO8/fP5YvwZZn3DShjPlqq9cUNn/18qRB18n1wRnkf/6+qPyFj1uDbuZmjZM1CamZJ02 /rxOirLg3++RW6xapQ1nyW+95+xYaYvYyrnD5UQNcj1pyz2T17U6uyuVdA+tj3Uh+GDxB+2tBEQy WRuMiC3KKAIIIIBAlwpQwqFLDzy7jQACCCCAAAIIIIAAAgjMusDQNrnf68LfrTWv1GxgQB730g/6 iPed74o/XE7Jie/5I7nkg9XyADVrZlcdJ2e9LR5sqMxOr5GXnVcZ1wBHvLWBoXy+mkZ+v1avM6bL ynFvfn1NsMEXWb3+ZT4qo60Jj04af+x4uTwWbLDlsseeKedf7Gtsle0T1sQzs3wd/49XVoMNYavp tfJr13qJBRFtAjh0A1t/phUwRd3pn9cgQGXcBye/7x36rn/UPfO4HswZdyfJldVgQ5TY2rdt0Iq3 Jupmw3SibQxJ9duyO181OuBaWqol/n074LJtNtMCCSUt5TA0OBh6LcJQswdDI8MyqKUfvPM2H/wz QwQQQACB7hY40HsV3S3D3iOAAAIIIIAAAggggAACCExRIK9N7Va6oxfXviVe2CFbPRhx6ksbvOWf khWHW0mCylv3nk5sOLDtKdl8/2Z5+onnZfeevMYC9skd3v7AdJ+JFwbkKU1z88NPy/PP7JZ8VlP9 7tj2ImLZGH90w9oGDUNn5chT14h80Wr+3yWPPLJHTl4/iRIT08zXYUcvG5O/sVUJiWzTKoG823jG J2Tne5Zro9o+xYajQZqt2qaDvHlFfObUxzeskGX1TyAyaRmt5GicJGfTdJxNTGvy1l2hSqWxrZRM K7WWWcmrT9LKlbSdhpIkrJql0Fp0JYtWssGmWV+Khi2TeTKCAAIIINASAvV/7lsiU2QCAQQQQAAB BBBAAAEEEECgDQWqr4lr3p/dH94Ur1ZkpG9Lv+C7pMGIqf0Y1caNP6TtDXx+/GCEJz2V4c57bpVr z7jtACGOqaSmy+rb8Y26535qwQbrcnLoyokfUc8kX/l8bbmSaLsT/asNWx/ANpcdpyGDiZKNz59u QGiWTONZmZ3xCUMls7OZeUylXNDwofX1nZV40D40Km0NS9MhgAACCCAQE5jaPV5sRUYRQAABBBBA AAEEEEAAAQQQqBHI9Io1DxCq6hnnQXFY/tndtcGImkTqPxTlhx+9SoMNXoXLSjn9+tfIS9cdIv0Z DURs+LL44/z6NQ/4edtdcpUGG6qpvud0ed2ZL5VlK/pl73/+q9z0ca9w6ICp1M6sNh5dO3npsVrC IeRySH7xgrYJEUpy1C5T/dSMfFUTHx3JD48+SD7+C5fK2Sf0N6xKKJ9Py2Enrh1dca7HZsO0GXle u0AmDh01Y8PNT9NKL4RgQiWw4KUebMvxypXi483PFVtAAAEEEGgXAQIO7XKkyCcCCCCAAAIIIIAA Aggg0OoCuRVyjDaqu8WqTqp/UNy/UtadqsGIu3Xe1v0Nq6MZ3DP6ELy6q0OPybduqIQFTl0vV37r XbK6+ku2KM+cpwEHr1apulL9yNja9rd+67vVYMP6r14p73rz6upKxYMf14BD1OB0deJkRjTIMrZ8 QVG2PbyjsvZKOW7dgatTakq+GuT94KMP1alRUOWQY4+RtSe06OPzaZuOPebxIEsDkmhS/fe2ZsFh 2e0lNRrmq2bhtvsQqknSIEMIMOiwWLYqlbSv25OiTimPmVq3EB8RQAABBLpWgEaju/bQs+MIIIAA AggggAACCCCAQBMEFlbSvP1p2eEtFIdJfXLo0ZV5j2yUjZv0Tf9Yt2Pjl+SzjUoVaOPPHoZYcsar YsEGXbmwTR5/IJbIOKP5gbFhgEL1Df8lctL60WCDJbHtZ8+Mk9IEk+++Qz79+ftrF9p2t3y9Wjrj UFk6Qe1ETclXbY7Cp8XrjqhOveP674QAUHVCK41MxTTWUPim72yu2Yud99wsN3xk/FIr1cqwNBg2 9ttSSWpou2yxgJl2uZev7tgSDtEe6r+VEg7Vzz6S0BCE9XQIIIAAAgg0ECDg0ACFSQgggAACCCCA AAIIIIAAAtMR6JNfOm1lZcUXZO/eeBpZOfGck6oTbj/tf8u3N22TPc9tk7s+f51cseGO6ryakUym 2rDwrmv+Ve58YGeYvefRH8pfvfKTct8jNUtXP6QzC6rjGz/+Fdmybads3Xin3HlPVNognfU6+HfJ 1z57p+y04MjQHtn0938ln3znfdV1pzSiAZUnP/RZ+fBHb5Wt2/bIjod/KNf96j9U24hYee3rawMm DRJvSr4abCd75GvlTC1xErqbb5NPfOhWNdojw4WiDO/dI09t+qHc/NGr5fde8VeypVLApEEyzZ80 BdO+tceJf/t2ffxG+ZubfyY7X9yhx/Sv5SNnWLGb8bq0LPBAmQbDbrp5i+zctlXuvPmu2qDZ4FC1 VMyKV62SsWUoxku/PacntXSD9WO6sgYbrKdDAAEEEECggUC1IGqDeUxCAAEEEEAAAQQQQAABBBBA YEoCh7xinS5vb5Jvl7vu2yEnnrmiuv6KN58np596n2wMb4lvly+fdpV8uTq3dqRaOCK3Ts7+xBIt /WANRm+Xm9Z/RG6qXTT6VFcVTvbYl8tJcouE0MHd98h1R90Tllt5/WXy+vUrZO2v/6os+f0bQzBg +zU3yUe0n3FXCX7suuE2uUb72u54+Z+/d1zNpOpb9TrV36pvSr5iW626yiJ5+/93vvzghC+Hh+i7 Pn+bXKf92G6JDFpGc2PnxKc02hebP950X9dLr/jnMcOpmC49Uc65fInceE3UuPg9F90g0VEfk2pd exVZOeXC4+WWmx8MC9530XXR90bDFx/c+VpZUXlysu37G6vBo186YfR7PTb1DpnSoISDtduQqJRw oA2HDjnO7AYCCCAwywKUcJhlUJJDAAEEEEAAAQQQQAABBLpZYNHRL6++Zf7Qv22pPkiPTFbIRd+4 UjZcvGQM0Ulf+KBcventlek9En877sTLrpALP2GBjNpu5QffLu+77cxootetX11klVy86fxqXnxy f38l5aUnyxWbLpQ1Xs2TL6BrvPX298kGbYsi6qbwHvuGM+XdX90w5tn8kovPlMuf/YCsrXton/G3 6hdnRt+Wn0a+0pLxzEomMza/6azPrnXNHnmWXP/z98npDY6HrZHbsE42fPW9cry1BD5B13BfdJ3x pkfJjZZekWoe6zY0RdOTr7xCzr/cGumu7Q70/bIlV7z5f8qFl3v5CF+3PyY7LD/7ehSQEFknJ65r 0TYvPOszHIZ2HKwQgxVmsMBDpbNgQymRDH0ymYyCDz6TIQIIIIAAAiqQ0D8co385IEEAAQQQQGCG Av5npVAoSLFYkoH9g7JvcEQ2/uw5GRyJ3qnr7UnLa39puSzs7ZH+vl5JpZKSTkc//sMbUzPMA6sj gAACCCCAwHwKDMs3L/pDfVvc8nC8XLnnAw2rESpqtT0v7NynT6Rz0rdimfRV4gDFoWEp6BPybDzi 4LszNCA7dw7IkL42v3DZQbKoP3q4buuIrpNqtI6GPPY8tzusk+tfXF3Hk7ThwIs7ZWCP1huk9eoc tHxR9PDfqhbSW5dsbuwD/Pi6urbc+vYPyW1WY8+pG+Qzd5wn2cKw7NwRbTOez9r17JNuY6gg6Zzm fezMKeWrqNvUlNStUUq6pQMa2fwB2W22mo+cHpNsf5/0Tbjv8UyPty/jTa+s29B5JqZRukWtHsu+ XwUN/yye7PdLV7Xv5e69qmDfS/0uVOMgQ1vk6mXXyZOW/HsulL++/vUNj1m09fb8t1QqheDCyMiI FPPDsm/7Vkns3iYHf+cTkhp4PuxUceEKee6Nfyrlxaukf8VL9JzToFFPTwg8WACCDgEEEEAAgYa3 Y7AggAACCCCAAAIIIIAAAgggMD0Bq55GKzO62SozelDuun9ALjh57Nvgqf5FskL7+i41zsP3sFyu T5atapCWrjN+l5JFy5dpBULjd31LNeCxtG6+PrhvGPSoW6z+o71ekdXgx7JVk6lyR7dxgIf6U8lX ygIu9ZmJfTbXA3WpcWwPtE7tvPH2ZbzplbUn4Tw10yjdVE6/X6vGHvUDfr90VfteLmvwvdzz07uj YIMuc/q5JxzQurJnbTuwF4isTxSLoa/fkbIGFqynQwABBBBAoJEAfyEaqTANAQQQQAABBBBAAAEE EEBg2gIrznqrlm2Iujv+8d66apWmnSwrIjBPAgNy12c3Vra9Xjacvmye8jHXm7UKMWorxbA6MqxE svXUlzHXx4PtIYAAAu0hQMChPY4TuUQAAQQQQAABBBBAAAEE2kcgvVrO/lylHv3P3ywP7m2frE8n p3lvP2JnnuDKdAAbrNNSpnsflW+GKsK09YZ/fItMpuxKg11qq0mhhIO232DtQ3uVqdUd0DYcxPpK 5wEI/8wQAQQQQKC7BahSqbuPP3uPAAIIIIAAAggggAACCDRFYO1vvV8u+6Wfy15ZKkdOotHhpmRi ThLNyYkf2iC7frJLlhx3ooyt8GlOMtFhG2kx0/4j5Q+/e2n4Lh+zflWHWTfeHWsvOgQarGql2CIW XCjZPO1tnA4BBBBAAIF6AQIO9SJ8RgABBBBAAAEEEEAAAQQQmLlAepGsW3/yzNNp+RRSsu5t52nf 8hltowy2mmlfl3yX674ipaKI9WM6K92QrFatNGY2ExBAAAEEulqAgENXH352HgEEEEAAAQQQQAAB BBBAAAEEEBgr4CUc4nPiLTrEx+PLMI4AAggg0N0CBBy6+/iz9wgggAACCCCAAAIIIIAAAggggEBV wAIN1icTWp2S9vVdOZEW6+kQQAABBBBoJMBfiEYqTEMAAQQQQAABBBBAAAEEEEAAAQS6ViAeaIiP V9puoP2Grv1msOMIIIDARAIEHCYSYj4CCCCAAAIIIIAAAggggAACCCDQTQIaYygVi5LQPrQQHdt3 bzQ6NolRBBBAAAEEqgLW0g8dAggggAACCCCAAAIIIIAAAggggAACkUBCSzLomPXRP5XJsZINidh4 NJd/EUAAAQQQECHgwLcAAQQQQAABBBBAAAEEEEAAAQQQQKBWoKSlG6z3LqGPkKyvdBZwIOjgGgwR QAABBFxg9C+FT2GIAAIIIIAAAggggAACCCCAAAIIINDdAtpwtLYe3d0G7D0CCCCAwJQFaMNhymSs gAACCCCAAAIIIIAAAggggAACCHSwgAYaEiktwaC9Bx3KyZRYH0o1UJ1SBx98dg0BBBCYmQAlHGbm x9oIIIAAAggggAACCCCAAAIIIIBA5wnESjiUteVoDT+E/2ycDgEEEEAAgfEECDiMJ8N0BBBAAAEE EEAAAQQQQAABBBBAoEsEyhpgiPeh/YZqGw6JEGaIQg2hKekuUWE3EUAAAQSmKkDAYapiLI8AAggg gAACCCCAAAIIIIAAAgh0ukCshIOFGCzYYD3hhk4/8OwfAgggMDMBAg4z82NtBBBAAAEEEEAAAQQQ QAABBBBAoPMEYgEH27lyIhn6zttR9ggBBBBAYDYFCDjMpiZpIYAAAggggAACCCCAAAIIIIAAAu0u YMEGK8oQijZEFSl5CYd23zXyjwACCCDQXIF0c5MndQQQQAABBBBAAAEEEEAAAQQQQACBdhNIlEpi vXUWbEglUyLWJ7TxaO3pEEAAAQQQaCRAwKGRCtMQQAABBBBAAAEEEEAAAQQQQACBbhXQgEI5mZFy qkcKuSWStOqU0jkp9SwKQYd4wCE+3q1c7DcCCCCAwKgAAYdRC8YQQAABBBBAAAEEEEAAAQQQQACB rhYIAYRURkpLDpVibpFsO/ESkcKIlmxISqKnVzK5xZJMjtbQXdbqlwg6dPVXhp1HAAEEagQIONRw 8AEBBBBAAAEEEEAAAQQQQAABBBDodgGtMimdlXKmJMW+FVIu5jWokJRkJhtKOMQDDgQbuv27wv4j gAACtQIEHGo9+IQAAggggAACCCCAAAIIIIAAAgh0nYAHDlIpbadBu0TPQi3UoNUoLU1ISdtySKfS ktB56WyvpNNpseXigYeuA2OHEUAAAQQaChBwaMjCRAQQQAABBBBAAAEEEEAAAQQQQKD7BCzwYIGE pAYULPSQ0mqUrPFo+5zQ6QQauu87wR4jgAACUxEg4DAVLZZFAAEEEEAAAQQQQAABBBBAAAEEOlDA Ag0ebLBhb29vKNmQyWjj0ZV2Gmx6NpsNAQkr5eDrdCAHu4QAAgggME0BAg7ThGM1BBBAAAEEEEAA AQQQQAABBBBAoNMELIhgnZVksHELNljnQQefHibyDwIIIIAAAnUCBBzqQPiIAAIIIIAAAggggAAC CCCAAAIIdJtAPNBg++6frSRDvPPPtN8QV2EcAQQQQMAFav9q+FSGCCCAAAIIIIAAAggggAACCCCA AAJdK+ABh/rAgk/vWhh2HAEEEEDggAIEHA7Iw0wEEEAAAQQQQAABBBBAAAEEEECgewQ8oGBVJ1lH wKF7jj17igACCMyGQHI2EiENBBBAAAEEEEAAAQQQQAABBBBAAAEEEEAAAQQQ6G4BSjh09/Fn7xFA AAEEEEAAAQQQQAABBBBAAIFxBbzEw7gLMAMBBBBAAIGYAAGHGAajCCCAAAIIIIAAAggggAACCCCA AAIqUCqKlMv6vw61S+i4tiQtks6Gz/yDAAIIIIBAIwECDo1UmIYAAggggAACCCCAAAIIIIAAAgh0 oUDZAgvlksjgbinnhyW5d5sGHwpSTC6QRCYriYMPF0n1aOxBgw90CCCAAAII1AkQcKgD4SMCCCCA wPQECsWSvv1UlpL+PgldKfrcMLXYbxN9Z0pKuuxIQX/UaJfUHy724yWdii3UMBEmIoAAAggggAAC CCCAQFMENOBQHhkUGdkv5V0acCgWJNGzUKRngciy1RpwaMpWSRQBBBBAoAMECDh0wEFkFxBAAIH5 FLAgQ16DDTteHJKRfFF2DeYlnUzIEct7JaVDCyaEt6TimbSXpiw4EeYlZaRYlq07dklBoxWLezPS k0nJIUt7JZNK8uZU3I1xBBBAAAEEEEAAAQSaJOD37MWiVqGUHxLZ/pDI7m2S+uE/SXlonySWrBRZ vEpGlh4hif7lkk5Hj5SSyWSTckSyCCCAAALtKEDAoR2PGnlGAAEEWk1AAwiDIwUZGinK4FBeUlo6 YWikRwMGCS2/MH5npbVHCkUNWJRlv65X1AkpLd2QqxaTGH9d5iCAAAIIIIAAAggggMDsC1jgoaxB h2RhOAo87HteksP7pNjTqyUctJSDtu3gwYnZ3zopIoAAAgi0uwABh3Y/guQfAQQQmCcB/5Fhb0AN a7Bh284BGRgqyMDgSAg4JPWHSi6TlIMWatDBIgvxTmtLsml5XXfHjr0anCiF9YsaeOjL5bVPy6ql OUlm05pWVF6bOmLjgIwjgAACCCCAAAIIIDC7An7PHkoh6316YVirVNK+1wIQtin9p6wvBo3k85LQ 3ko22D06JRxm9ziQGgIIINDuAgQc2v0Ikn8EEEBgngXsh8loX5K8tsVQLCVk//CIDpOydEFPND9W 1sGXL+kPlv3DeRnOaxsO2tvnkr4xVdL1fJl53j02jwACCCCAAAIIIIBA1wjYPXjo9AWhkgYdEloF qlSaVrM51ltAIkyPluRfBBBAAAEEagQIONRw8AEBBBBAYLIC/mMk/ODQnx4HLcxINlWW3XuHZWi4 KNteKGgJh5Qs7LE6XTUoocEEX8fGB7VUg9aiJNueH9ChVqukQYZMOqHppGWhtuOQSHgbD9GPHko4 TPbIsBwCCCCAAAIIIIAAAlMX8Bd+8lp6oTQyImV9gSihvU23mIO2zCYlbUy6UNAGpLW3ks5WusHv 8blfn7o5ayCAAAKdKEDAoROPKvuEAAIIzJGA/7iwXyA92l5DNh0FFzS6oCUdopehRvTHiL0oVQol IaKM2fiwBhmSyVIYWhsOWlGsvimVlGxPSno08FB5kSr6gaNFtekQQAABBBBAAAEEEECg+QIeeCjr Pb3d19d3lHCoF+EzAggggEBcgIBDXINxBBBAAIEpC9gPEn2vSZb1pSSXLovWoBSCBfuHtWqlYkme eWEgBA0KGlSwuIEtb+O/2Lk/bMsamrYyDAuySentSciyBWkdT2saoyUippwpVkAAAQQQQAABBBBA AIEpCYwGGqx0st3La1sN2oe3hzSlUjkZqk615WxaCDzwYtCUjFkYAQQQ6AYBAg7dcJTZRwQQQKCJ At5QXFKDCSn9J6vVKGmcQdtm0ELX+kNkaCQKHNi4tdHgRa0Hdb6N2w8VCzj0pLVKJl03pYUkrPdG 6JqYdZJGAAEEEEAAAQQQQACBmEAIJlQ+WxsOSWvDQTu7X/fOSisntadDAAEEEECgkQABh0YqTEMA AQQQmFDAAwe+YFKDDRovkJcs7dFgQ0H27B+WEQ0w7Nah/R4p2I+Vyu8SC0js2m8BB6sLNhGqY1q1 JCrZYNUpWVre2Xbqt+XzGCKAAAIIIIAAAggggMDsCkQvCpUkpffhSe3ts1WcWr0v18/xwMTsbp3U EEAAAQTaXYCAQ7sfQfKPAAIIzKNAPBBgJRJS2vdkklED0Bo0KGrVSQULMnjvedXPGosIXVp/xGS0 SENG23/o0T6l45aWd/Ft+DSGCCCAAAIIIIAAAggg0GQBe2vIeuv0nr16T2/jdAgggAACCIwjQMBh HBgmI4AAAggcWMADAalUKgQIilrk2rrF2ohDjwYNli7MaEmHouzcN6JVLEV1vNanaHGFxX0ZbbMh petZCYeMBh7SGnRISVqH1beo6lfkMwIIIIAAAggggAACCDRVoFTW+3vrK11R4wzW0yGAAAIIIHAg AQIOB9JhHgIIIIDApAWsVIIVrbZ2HNIpa8vBGpUrheqRotIM9naU/0KJ3pSyIto9GW2/IaPDtAYZ KqUb4iUcJp0BFkQAAQQQQAABBBBAAIFZEbC7dq04KfwX7uDDrbyOeUmHWdkKiSCAAAIIdKIAAYdO PKrsEwIIIDCHAtVAg5ZKsBIJVjIhp4GFww7KycBQXnbuLWjVSlED0qPZ0npgE1qFkgYYDlvaK325 jOQ08pC2oIOub2la76UoRtdjDAEEEEAAAQQQQAABBJopYC8RhXYb7OWhSqPRtr1Ewu73o3t+7tOb eQRIGwEEEGhvAQIO7X38yD0CCCDQEgLxHxxWHVJJf6RkNXhQSJc1gCCS1kai8wUv3WBZtlIQOl3n 2XJZbbshqcEHW9e7eJo+jSECCCCAAAIIIIAAAgg0X8DKNngXjdd+jt/Z+3IMEUAAAQQQMAECDnwP EEAAAQRmJOCBASuZYG9ClfQtKJvWmytIQqtXOnRJNrTl8MzOohS0EWnrrMqlg/uszYaULNQ2HHI9 aa1WKRMCDhkd2vqe7owyx8oIIIAAAggggAACCCAwLYGE3ttbH3UJDUFoFaraj1aTOq1kWQkBBBBA oMMFCDh0+AFm9xBAAIG5FvD2F6x9BmvPIZdJhSqVkjqeiBpz0GCCSG9PKjQSrZO1eiVdVks3+Lpz nWe2hwACCCCAAAIIIIAAAqMC8RIMNm73797Fx30aQwQQQAABBFyAgINLMEQAAQQQmJaAl0TwYEGx WAzpZLNZDSKkZdWyopZwSMtz2pbDULKo70Rpg9JahdJLli/QgIOWcsjlJJMZbbfBq1XydKeVKVZC AAEEEEAAAQQQQACBGQmUynpfb32l0xYdxHrvKJXsEgwRQAABBOICBBziGowjgEBbCRS0IWLrvJBv W2W+AzNr1SlZV9BSDDZqw6KOWCAiKsEgktLfK/YTxZpqsGk2z5axkg8pXaekw0TluBJwCJzz/o+/ zJbWNjboEEAAAQQQQAABBLpIwG7qrdfO/vUAQxgPU/kHAQQQQACBsQIEHMaaMAUBBFpcwB5sF/XB 9HN7R0KbAIVCwe+DWzzn3ZE9K+Fgx6iQz2vj0SXZv39YxwuhvQatRSl0aY047No3LPuGi7IgbwGJ kqQzGmwIVSvluwOqDfbSistbiRNrc2PFIi2xYtViUYa+DY4cWUQAAQQQQAABBKYvYPfy1tvrJvFX TjzgMP2UWRMBBBBAoBsECDh0w1FmHxHoQIGS3gAPjhQlr2/DlytV+HTgbrblLnnAwUorWG/tRBe1 GqXwgrw+uNZDpyUbomkJHbeGpJNJXbagS1nAwV6ZomsdAT0+GT14ds6l9DjSIYAAAggggAACCHS+ gAcc7O7Pxu2+XW/Wo5779c7/ArCHCCCAwAwECDjMAI9VEUBgbgXsRtc6G+YLJdm6fY+M5ItyyNJe 0efYVK00t4dj3K35cSroMbLxciLUnyS5HgtARNVghfYekmmdl5QRfaCd0OlpW06PYqI0Wk/suBth RlMFLPBjx86qxXp+97BktM2NlYuzIfDgx5eSDk09BCSOAAIIIIAAAgjMmYDf34V798pvLgs0lMoF vT0vhFdO7N6vVOntXp57wTk7PGwIAQQQaDsBAg5td8jIMAIImIC9bZ3XB9V5fX6d1IfUab3p5UWb 1vhuVH6jaF08WoxBP2iZBT0+2l6DNjFXLkeFsu0HSiaj78vrcQttA+hnW8Y6fry0xnG0Y6Nnmgxb 4EjHOL9a47iQCwQQQAABBBBAYE4E9P7c7s7DHbqOR111ypxkgY0ggAACCLSnAAGH9jxu5BqBrhTw N2+szQbri/omvL5nI8v7U9KbiR5kdyVMi+50qRQdk0IhFd6WL5V6wtCya0EFfzMqnY7+FIVSDy26 L92arUFtTuPJ54qhzZRw3mkhFGvTwToCQ936rWC/EUAAAQQQQKArBOwtIiudbL2O28sn9gqR9dF4 VyiwkwgggAAC0xAg4DANNFZBAIH5Fagp6qsPrq06JXs7ngeg83tc6rdeqrwIldQSDtEx0x8nleIP dqy8T4XGHaxdB4JG9Ybz+dmOlZ1bfl7Fz7v5zBfbRgABBBBAAAEEEJgDASvVYPfu1tu4dhZosJ4O AQQQQACBAwkQcDiQDvMQQKClBOofeBa1kWGf5kN/iN1SGe/SzPiDan8j3ttvcA4PMPhyPp3h/Ar4 uWS5sPGSNsweP0Z2HOOf5ze3bB0BBBBAAAEEEEBgtgXC/aDe8yW1peiEtRZtQQfr7EWhystC0QT+ RQABBBBAYKwAAYexJkxBAIEWF4g/EG2UVR6GNlKZ/2keYPCc+HGqH/p8hvMjYOeXd/FxCzTEP/sy DBFAAAEEEEAAAQQ6VMDuC2P3hnbfHr+n9/v4Dt17dgsBBBBAYJoCBBymCcdqCCAwfwL1AQe70bXe 2gLw8fnLHVseT6D+YTU/UMaTmt/pfpxGRkaikgx6bnkIwufNbw7ZOgIIIIAAAggggMBcCJTthRPt rbN792JRpFiwUg+VKpZiwYi5yA/bQAABBBBoDwECDu1xnMglAgiMI+A3uzbb3raxz/ZQND59nFWZ PM8CHKN5PgANNm/njp1Hfg5xjBogMQkBBBBAAAEEEOhCAXsBxe4Nw72ijVc+dyEFu4wAAgggMIEA AYcJgJiNAAKtL2BtBMRLN2QymdbPNDlEoEUFCoVCyJmdU0l7g62ST0o3tOgBI1sIIIAAAggggECT BKyc62hZ1+gFL404NGlrJIsAAggg0CkCBBw65UiyHwggEN644Y1svggIzEwgfg6NNz6zLbA2Aggg gAACCCCAQKsLhBKvmkl7+SSMW3MONm4ZD//YCB0CCCCAAAJjBQg4jDVhCgIItItA5dVreyhqvVep ZEM6BBCYnoD9oAw/Kivn1fRSYS0EEEAAAQQQQACBdhaIfmpZ+w2lqMSrTihryXLrq0Vg23kHyTsC CCCAQNMEeCrXNFoSRgABBBBAAAEEEEAAAQQQQAABBNpQICraoFEGLc6g4/qKV7WEg43TIYAAAggg MJ4AAYfxZJiOAAIIIIAAAggggAACCCCAAAIIdKlAoqSlG7S3zmpRSuio9Vq8PJQwt+l0CCCAAAII 1AtQpVK9CJ8RQAABBBBAAAEEEEAAAQQQQACBLhYIzUX3LJBST58UcktDmYZiz0Ip62dJ8O5qF381 2HUEEEBgQgECDhMSsQACCCCAAAIIIIAAAggggAACCCDQHQLWJl5Jgw17Dz9NSsP75fnlrwg7nl60 XJLZBZLL9klK23LwtvS6Q4W9RAABBBCYrAABh8lKsRwCCCCAAAIIIIAAAggggAACCCDQ4QIhkJBK a2mGhdpkdFqK/VqPkrblkOxdJImenBZwiIINHc7A7iGAAAIITFOAgMM04VgNAQQQQAABBBBAAAEE EEAAAQQQ6BQBK9lgwQYbJjXgkFp4kJQLBZFMf9jFRK5Xkum09plomcrynbL/7AcCCCCAwOwIEHCY HUdSQQABBBBAAAEEEEAAAQQQQAABBNpewAIOVmWSBRZS2l5Dshg1HJ3K9GggIhXN02XoEEAAAQQQ aCRAwKGRCtMQQAABBBBAAAEEEEAAAQQQQACBLhCwUg3WeZsMaSvFoAGFvr4+KZVKksvlwnyfnslE JRwsKOHrhRH+QQABBBBAQAUIOPA1QAABBBBAAAEEEEAAAQQQQAABBBAIAtVqlSqlGCzAYF18ugcp wgz+QQABBBBAICZAwCGGwSgCCCCAAAIIIIAAAggggAACCCDQjQJWqsE6K8lgnX+2Ug7xz16yweeH mfyDAAIIIIBARYCAA18FBBBAAAEEEEAAAQQQQAABBBBAAIEaAS/F4IEF/1yzEB8QQAABBBCoEyDg UAfCRwQQQAABBBBAAAEEEEAAAQQQQKBbBTzA4MNyuRwoCDh06zeC/UYAAQSmJhCVl5vaOiyNAAII IIAAAggggAACCCCAAAIIIIAAAggggAACCNQIUMKhhoMPCCCAAAIIIIAAAggggAACCCCAAAIuQMkG l2CIAAIIIDAZAQIOk1FiGQQQQAABBBBAAAEEEEAAAQQQQKCbBIojIpXqlMJuJ7SSjERCW5PmUVI3 fQ3YVwQQQGCqAvyVmKoYyyOAAAIIIIAAAggggAACCCCAAAIdKmBtNpQLI5J48SmRwrCU9u+SRDIp icWHiqSzIgsPDkEHSj506BeA3UIAAQRmKEDAYYaArI4AAggggAACCCCAAAIIIIAAAgh0kkBCylLa 94LI8IAkhl7UXdOSDZlekWyfyIJlGnDopL1lXxBAAAEEZlOAgMNsapIWAggggAACCCCAAAIIIIAA Aggg0IYCVrLBukKhIOWB3ZJ55Nsiu7eJPHW/SCotpePfIrJ4lZQWvCboUAAAQABJREFUHKQ1K6Uk lUqF5SnpEBj4BwEEEECgIkDAga8CAggggAACCCCAAAIIIIAAAggggEAQCFUqlYpSHtwrsn+PJAae 14BDRspa2kFG9ku5VKpt2wE3BBBAAAEEYgIEHGIYjCKAAAIIIIAAAggggAACCCCAAALdKFDSQIIF G/L5vJRHtA2HQl4SxYKkQ8mHhJZ80CBEviBSLOn0opZySITeSzp0oxn7jAACCCAwVoCAw1gTpiCA AAIIIIAAAggggAACCCCAAAJdKRAFHjT4YCUZrNfmG8pl/awaodfSD8lK9UtdCcROI4AAAggcUICA wwF5mIkAAggggAACCCCAAAIIIIAAAgh0roC33WCBButDGw7ajkNGSzkktbSDd4WCBh20L+k0m55O R4+UfH3acnAphggggEB3CyS7e/fZewQQQAABBBBAAAEEEEAAAQQQQAABF4jacIhKNljpBi3eEGbZ dAtIeOeBBv/MEAEEEEAAARMg4MD3AAEEEEAAAQQQQAABBBBAAAEEEOhygRBo0KBCUdtnsL6QHwm9 s1iowXpfzoc+nyECCCCAAAImQMCB7wECCCCAAAIIIIAAAggggAACCCCAQAgmRAyJqA2HULpBx2M2 JZ1G6YYYCKMIIIAAAjUCtOFQw8EHBBBAAAEEEEAAAQQQQAABBBBAoDsFvB0GayQ6nU5IMhU1GB00 ytZ6tAYfCDh055eDvUYAAQQmKUAJh0lCsRgCCCCAAAIIIIAAAggggAACCCDQyQKjJRdqSziEIg4J DThYHy/u0MkY7BsCCCCAwLQEKOEwLTZWQgABBBBAAAEEEEAAAQQQQAABBDpPIAQdtBRDqVSUhPW2 i8mEFDXSUNI+lUpq3CFR03eeAnuEAAIIIDBdAUo4TFeO9RBAAAEEEEAAAQQQQAABBBBAAIEOFbBA Qwg22P5ZqQZKOJgEHQIIIIDABAKUcJgAiNkIIIAAAggggAACCCCAAAIIIIBA1wmUSqLFHMJuW7wh mdAGHbSnRqWu+yawwwgggMCUBAg4TImLhRFAAIH2ECgMPC+PP71DRooiPQtXyBFrDpZWv+C3Y57b 49tALhFAAAEEEEAAAQQQmJpAORZW8HELNISCDlNLiqURQAABBLpMoNWfP3XZ4WB3EUAAgZkLWJ2r Ox64Tf7p3x+vJHaEvOvyS2R1tlogeuYbaUIKjfJ8WI+V3G7tfDeBgiQRQAABBBBAAAEEEJhzAfsd MdpotJZo0BzU1MOd1BIO1tMhgAACCCBwAIGavx0HWI5ZCCCAAAJtJJBM9cdym5V2+FnQjnmOITOK AAIIIIAAAggggEDHCNgrP1aywf6zcXsJqFrCgReCOuY4syMIIIBAMwQo4dAMVdJEAAEE5kHA30Yq aT2rNm5D6xKJshTCtCjG3ColBjy/PrT8ep61slgphDesRiFbJd+jOWIMAQQQQAABBBBAAIHOFSiX imL9aBdCDyH4wL35qApjCCCAAAK1AgQcaj34hAACCLSeQKkgg8P5kK9UJiM96Ykv3fHia/ZA34IO U+1Kut1CIS9F+42RSkm2p6e2SPVUE9TlS4URGc4XNbmMZDK15S7qs5iK78Q0ttWMVTz/lnYm2yvp FsxjM/abNBFAAAEEEEAAAQS6TyAKL0T7Hdpu0JINXtKh+zTYYwQQQACByQpM/NRqsimxHAIIIIDA LAqU5LnH/lt+fM8muXvz47XprjhCTjvxZHnFKS+Tg3uT1XpWdz/+I/nGfz0pqd6iPPvjB7SMgHcP yde+crOsySVlRCclkzrseYn86q+dKovrHpgP7HxaHnnkYXn44Udk8+M7PIHKcIUcc8pxcvIrT5Fj Do1X2VS7WGn3z+Vr//wfsqdXf5b0nyjnnPtaWTzyvNzzra/Lv//48erC5RXr5TffcLDce+/jkllQ lu0/vr8mz1/9l6/IYdruREmDHdblew6Tt/za+mqeC7s3y63/fIfsXbBA9ssyefO5b5G1/eP9WSvJ 0/d+S/7tR8/KggX7JXvIafK2N58gfdXcRCMFzfutmve9C/TzstfIO972ClmgAZvdT2+We394t3z/ gcdr1jjihF+R0057lRx1SH1KNYvxAQEEEEAAAQQQQACBthGwF5ZCKeSy/qKwvtJZ5UpRBUs+hSEC CCCAAAJjBcZ7MjN2SaYggAACCMyRwID85N++KF/78bONt7fjcfn+t63/ubz3inNlRaWgwL5f/FwD BQ+HHwehflX9oWCdvYX07OYHZEfljSQLOIiGHk7foAEHbZQ5dIPPyp3/96/luw9XPjcc7JDNP7b+ e3LsGy+R81+7tmGJh8L+XXL/s573F2XvrzwtGz/zN/Lj+jSfvVsee/SoENywWaVKfn0xz3OUX9uP vJy2QQMOlTyX9u+NbWer7Nh31gECDsOy/cG7pZqtrZvktDM14OD7X9loKZ73rY/JnjPXyqMbb5Gv 3v24Z6tm+PgD3xPrTznnPfK2VxxaM48PCCCAAAIIIIAAAgi0q0AoJa2ZD2052H26/m+/K0JVStHP jHbdNfKNAAIIINBkAQIOTQYmeQQQQGCyAuEtIl34qe9/WW65d3t1tTB9xeFyeK/IE088Ed3kh7nD MlzQ9hoqpRSKpcFq2w22zmh7CNGPg1SlpEA0fTDMt2YeQkDip3fIHQ9Fvxw8H9UM1I3Y8g996+/l Pw+7TF6/pq+aH1+vpHUj+bjIvfKFT98bUhidFiVon5OVPNt4MdTdpL9ldNy2YYGG8IOmsv1kUvOs y5RK9rNHAxQ127H1RtetrBIG0XaTkuyxfPkcrR5KP4x+jqaXa9L8qdz45z/1FUK+qh9iI5bHe2+5 UfoX/S95/dr+mjzHFmMUAQQQQAABBBBAAIG2EQh33FbnqfbReEKKet9b0j6lPR0CCCCAAALjCRBw GE+G6QgggMB8CBSelbu09IJ10YPyE+T8S8+Sow+uVNlTGJKd2x+Te775Vdm0Y0jirSCsOOHX5LcP GbDmluWZTV+Xb256NqSRTB4ib/gNrW5oYVqDE0lrjkESqUWyMvZ2vxWUjrYnsuKY18rrTn2ZrD5k qZYA0D8T2pbDwO5nZdO3/07u3ByyFv753g8ekvVrXikaB2nYeXrxmSe8/mw54SW9suuZLfKj7w3L 6pNPk4uPGtD8lOWpe/9Nbv/Jc5V8LJezzn+rrFmgQQfNcCJRknTPEjkklud4upMZrw0uVCMPY1Zt lG9b6OQ3vENedfxh0t+TkD3bH5bb/+mb8kRs7e998U45/sq3yvL4QYnNZxQBBBBAAAEEEEAAgbYS sBvoyk203T1r+Ybw3/h30m21d2QWAQQQQKBJAgQcmgRLsggggMBUBexBd+HFZ+VnVuxAO/v8ugvP lLVah1A+n688iE/K4kOPkQ3v+rD8ynBZepMFLRmgdanaD4GexbJyVb8MDw9LacUynb4tpFMqLZVD Vx4sBy3oCW/fZ7PZ6C38gq5beTspt3ytHH/8Uvml15wi65YvDOlZSYiREWv1QRtI7lsup579bnnx 2s/LT3Qde6s/8dAjsmPwJFmtbUNY5w/q83nLk7U0HXU+/Y0X/aG8anXU9sPq1UfIy9ZHJSGKC/pC aYtCyPP2kE4iEeV5WU9Seqyxag2UhKqVNM+FSp5tO/FSHFb6wbbrJTl8+1FebF5Jl69ODctaNr0U haWV1/Qtv55nW7pcXiPn/e475Jjl2bCyzVuy6gS54PcXyk2f+ZI86R6JH8lDT7xODl67KCzn6YYP /IMAAggggAACCCCAQJsJJLT9Buu9S9p9eOVe3KcxRAABBBBAoF6grrnQ+tl8RgABBBCYS4FSfn/Y nD/0ttII9iA83kfzUpLNZqoPx315G9qyhUL03pF9tvYaisXRh+g2P768jfcddpKcc84ZcvSK/vAg Pr696rgslRPOOqomf4mQ/qhQtL3oc3wbrzj79+SUl0SBhWp6lf3y5fRZf7Url0d0H0b3Ox7A8PVt YV/Xxm16fPs2zTqbZvN83JepXz5KazTN6PNyeful52sJk56aYxDy0HeEvOlXj6tJ99sPPf3/s/cm AJYdV333eVuvs6/SjDTad8vaF1vClndsY7xgbGO8YBsCBBMIEDshkBACBELIB5h8OARwsL8QvGAb GVtesGTLRrJkW/ti7dJon0WzT093v+U7/7rvvL79prcZdfd73f2rmeq6t27dqlO/d999VXXqVOU2 vk6X+AMBCEAAAhCAAAQgAIGFR0CrJqmtL99cQUk9C3kcBCAAAQhAYCoCWDhMRYdrEIAABOaBQAyA V33EvTCwxo73wfFHm4PkX/vrL9r6f/nDdpwvh5SsCnxGkawddKyZ/3IxmK5B+TQQngbys0F25V0o 1Hzwvur3je2LIGuBcnnsJ0DplCYG4XUe+YZ8qbBiKaVT+SVfBqnhZYWVgMpX2rBwaN1/1uvtilMG W9YSyVIhZZb9kRVFlD+mWMjqIkWJ4nSP8stbDYw4h5BXOdV99pXOo9xIm6Vxaw2vn2TNnFsypLRZ 7ynqq7KiHoq7/MffZCcN1NxqpHVjZJBkXn7cqbameqdtTzxcO/T0Xhv2PHrjvJWaAwhAAAIQgAAE IAABCCwMAmoHe2NX/5Nv6hvMit5/cK92drS1F0aNkBICEIAABOaTABYO80mbsiAAAQhMQUAN+0b/ Kjs+Ne6zuUONxt32f/7HH9mXv3O37dyfLW8UWaT06gU8D5c6E83788cpygfkR0YO2YEDB5IfGj5g e3c+2yqt4QP8cU+EulirZ4oHxcm/7KKTrex5xXkrgyM8iPsjzCsXUlZNFroeLo6ze9RhymTS3Kz8 NaWPa/n45X2+70XznonC+sA6O2NDVlq6/uhuOzBmdR5iEEIAAhCAAAQgAAEIQGBBEVDb1vUKyWfH voyr10AeZcOC+igRFgIQgMC8Exib3jrvRVMgBCAAAQiIQAxkZ8cr7KIP/Ih9839dnWbaK06z+2// 5j/aHdcXbMMLXmwvu/QCO3XzmsMa+mr4K20242isI1AoZPsfaG8DXY9Qeeed7msM77YH7r3HHrz/ Ybv9wa3jZAvLAd2TdTJqydqiltvIOVMCZIP5kb7hm043GpWWvNm9YyVLHjEolTI5sw5NVg/JG3VS KBcWCPV6Vo7SR3xYQ6QI/6NroZjQcaRVVymzZlC52S7P6dwVI5G/8hipyYoikz3SRd6yCDHrtf5B t4p4JttHo1B4xva5NcTK3uyzUNr2+sb9hBCAAAQgAAEIQAACEOhqAtq/obmHQ2pxN1wD4T5rfXe1 5AgHAQhAAAIdJIDCoYPwKRoCEIBAnkAMiFfWnGW//IGyXfMXn7Z78gn8ePvdN9pn7r3JChsvs/f+ xMtty4pKSqF7k8KgGeYHubOZSc2Nnv1E1/I+G4Sv21N3/pP97y/cnBuUzwrP5xXihKyhVFC8jiM+ yzNSZ2G+TB1HWikSdK9LNe6G9vTtckQZCtuvjcuoeRLpdZo/zqfNx+s4fz5xGa7AGcznt876iuKA AWGeK8cQgAAEIAABCEAAAouAQNaxWAQVoQoQgAAEIDCXBFA4zCVd8oYABCAwAwIxsB2hBt/Lq0+2 1/3aL9uLn3jY7rj1Jvv+gzvSTH9llwbit3/XPv6n2+zdv/IeO3l5MQ2MK173aoZ+uWnNkBWf7deg PRs0uK+Z+kobM/aVftvtX7FPfOmWVhm6T/Kc/oILbPXK5dbrRgA+j9+e+Po37AGPzzulU34hv8K8 07V8ubH3RKQZHh5O9xfdwkFpM1+ySqXivpjCsG7QPaGgOKw8L7e9bKWPdPV0XTFyY9YRcU+E2fWs HJUlOfLyR34pF5/xVW2udJXdv80OuuHDWv91TUqUZn0iT0IIQAACEIAABCAAAQgsFAIFb+vKh2uo ze8eBwEIQAACEJiKAAqHqehwDQIQgEBHCZRt1XGn2ytOOsdecmCb/eC2G+0rNz6Qk+gx+//+6Qf2 628+28q5hr8Gx4u5cy2pNDaQHwP6Yx2Fwv6H7fNfuCWXr9mlP/Ieu+KczT5b39Im0RpM1xJCJ1ee tQeuyewuYuA9G2gfd/v4E5cllA6STU7ncro34nQe8Tr2k3QecUo3bVnpxuf/J8oMGZRjKGii3lma Udu3fay8xvFbbE1lYsXHWCqOIAABCEAAAhCAAAQgsAAIeFvdG+CZoArUPld7vhnVajMvgKogIgQg AAEIzB8B1nyYP9aUBAEIQGBCAmqoyydFgTfgNbAdVgiKlwVCqX+dnfdDb7ZffO9rTXsUx8B745nt dqh5/4SZe2TkHflGOVHuyNBu25bL8+xXvMde/oJNVmnUkpIh8pUco6PjLQMauWWUIl2EkX85WSpU TBYWeR9ytORqq0fcH2Gkj/MoJ0LtATG5m+padtdE+RYK2WeRtw5pySsFyL5n7IadY8qThq9pK8sG +VBMTC4TVyAAAQhAAAIQgAAEINCdBNTC9ZZ/+teaquQTmdy2eZzAakPjIAABCEAAAnkC04/A5FNz DAEIQAACc0Ig31DXwHr+XAWGgmHgmBfayy9fNzaYvW3URptWzrpH94bL51GLyAnCPU9tHRd73Anr W/nHoLkG0MOFLHE+XejqlFSfkCcfxnF7HoqXubbC8O1p2s8feuK59qjW+cHHb7Vr8sYhrSuHH4RM Cq+95ibb7UqEkKE93P7wneMyWL9ppeX20B53jRMIQAACEIAABCAAAQgsFAJq80uVIJ/a/942dm2D WvbJ0kH1iHazjnEQgAAEIACBIDA2MhUxhBCAAAQgMK8EYhBbyoLawV327I4DVnRrAO11oP0D4vro 6KiNjBy0Pc89k6wekjJgvSsn6tV0HkIrfb0+mk6zex+0J3Zm+yToPJzulyKhPLgidSJkwaBlk3bt PpDCmKWvOB1Xdz9k133tnsM6FkmOMLX2zEPeKCfCsFCIMNJF2MjJbPagPZ6TOS/3WH7jh/bvv+ZW e9YtMMKFXHu33mx//ImvRfQRhYUdN9lHP/bP9tzomNIh5C8eeNS+9NUHx+V3sS9DxQ/rOCScQAAC EIAABCAAAQgsUAJF379BPlxBe8G5x0EAAhCAAASmIsC4yFR0uAYBCEBgHgloUP25H1xjf/PX/8P+ 4O+/aY/s2Gc1j4sBed9NwZ6+63q7+u5sUD0NqPf1W48P9us475atPyZ/atd9+SZ75pA6C3U7sOtp u//+rZZOPaZvWaZwiBtu+OS19tCu4ZaVg8rd/sj37Y//8nM23hYi7pg8DNknUhi03zW4rk3mL31n Upl1b3ntFrtyfT6XW+0vP/lte3pftotzfWSfPXTzF+0jR6lsaOW87Xr76B9+2u56cpeTkKvbnqfv tc985O8st32D2fqX2ilrxytBWnlwAAEIQAACEIAABCAAgYVEoFiyau8KG+1dadWBtVbtX2X1Yq81 it7eHZvDtJBqhKwQgAAEIDBPBNg0ep5AUwwEIACB6Qho5nxPz6rMguCBG+0z99/gg/7r7ezzjrX+ xog9fMudaYA7r1x41Q+d6nstyLY52zsgyli2/jjTWPy2pjKisO1G+8v/dnPKW+WYnWEf+NBmO8Y3 OC4s32QXuQXDTe6zvO+yT330LjvjwivsmP6qbb3xu/ZYZHwUYV7pMJXiYdn6zS2Zla6x7Qb7qz+6 sbWfhWT+6Q+/zTaUQgmz3M65/Hz71tW3jilHHv2m/cV//3bGsClrUsy0KWUKhfEKmomqFZyz8D77 7F+NX5Op1pbnq193ng2OUxBNlCtxEIAABCAAAQhAAAIQ6G4C6i9U+1bYtnPeYXW3sLaqW0+XKlba cLKV+5ZZT7l33FKu3V0bpIMABCAAgfkmgIXDfBOnPAhAAAJTECj3VNLVsUH67Xb3bbfZd2+723b4 YHbenf2Kd9tFx/aPDbbnLw4cby+9bNz0/9bVGEj3G7N7S2vsxe99XTqORCr/gdtutG9/53u2tVmu 4k47e0skSeFUe0OMSziTE5f5qsunkbktn1Vnv9R++Ky2yOZpXtGw7rK32M+857XjEo4Zh4+LHsfh rBe/2E4LTh6Gy+etuCve+jN2/sa+uEwIAQhAAAIQgAAEIACBBUsg9UWKZasNrrXa8o1WHdzgVg7r zHoHzSq9Xq/x/ZIFW1EEhwAEIACBOSGAhcOcYCVTCEAAAkdOQPskrDrn1fZzfcfYTTd/x265b1ua qR/KB+2xoOO1p1xoP/SiS+yMzW7W3LRK0AC4ro25op30knfYm3u/aZ+//o40iB75aMZS4wUn2XK3 boj7+445137xZwbspmv/yW5+aGcrm1a+J5xvP3L5ZXbm5lH7+j1/Yd9PKXyWUyvl2EFRZtY511Oa WrcdchUKJTv5pe+0N1eutc81ZVY2IUPjnJNtednVBM1x/6y+/faC13/QBo+90T73jVtTqapTsGis P8dee9Wlds7xq23o2cwSIhNtrfW3/QKGEiHKVLjp9IvtksvPslu+ca1de8fjY/k2lRDrzr7cXnrJ BbZlTV+a5aVyxVc+6pWVx18IQAACEIAABCAAAQh0NwG1YeW0j5xcccUx1vA+SN33dNO1Uv9yK/le cxXfa66k/Ry87Rvt7nQDfyAAAQhAAAJOoOADLGNTNkECAQhAoIsJaMBdryxtnnxguGo33J8NjL/4 9LU22OsN3+YGy2r8LiQXr+GoXygBasNDdmBoyA4ePGRavqfuA/J9/b5nQ3P8vuyNfTXwe3szk+Zo 7IuP8hgZGclm61cP2YEDvidD2uStYitXrrSBvp6WskHpJYPSyzVqw3Zg/8FUnncz0h4Py/sribvS qcOhjaTLfQNuTq1loHpaHY3Ip1EbtaHhUbe8rtigy6wOiuSUjPH5tOqpTozLO+R11f3K21zmkeGa jfh5j5czODiYZI7PNV+/kLtc9P0p9u230aorX5xN2TtEKwZ7k7xKn7h43rVGwfPsackV8uj60DPf sz/8iy8lOSTLy9/9QbvsuOVJfquO2H7/LKqjvvRUueT16bf+Xl/bVvK6EwfVM8JWR63ZcQvZuz2M 51A80vfsvux7dsWZ69L3LJ674Nbt9UE+CEAAAhCAAAQgAIGpCajdK6d2rdrNw8PD6Xjfvn3pXO1D tXP7vV2vNuDy5Vn7ONqFuoaDAAQgAAEIBIG2+Z0RTQgBCEAAAnNNIBr2EcZArxr5ivN5RNbbP5i8 zvPXJZsa+xrAVwNfPhQOER/n9VKvDazoHVPIeH9Ag8m6R/lGulZY7rPlq/paM5tUltKFXAUvt+K+ 3NpLYfzMppRvocf6XEGiPMMrn7yL8iIu5EnnLkOfa1b6/f5MkRSpsjCfZ+RTa7hCZtlKW+bKhnCh HJH8ckUpIsRrCrni3qzOtdTZUhnlsitPlldavNQhi86Xrkv+8Hn5Ij9CCEAAAhCAAAQgAAEIdCOB aE+rHxFt8lAmRD8gaw+X0/XobygtDgIQgAAEINBOYGxUpv0K5xCAAAQg0BEC0ahX4TFQ3n4cnYL8 wLaOlT7iIk1UIp9XxOXTxP1xbbr06mBMVFbkGdciv4nCSKtryk9KjXYXckTddD3yjrhIo2v5Y52H y5cVcdOF+bwk20R5hCySP89kury5DgEIQAACEIAABCAAgW4jkG/bSumgNrAUDHKhkIg03SY78kAA AhCAQHcQQOHQHZ8DUkAAAhBoEdAgd/tAty7GYHd+6aj8ILeO8/eqg5A/jwIi78hPHYeIU6hZ+3IR F+mUXzjFxeC6wnCKz3vFx+yoiM+n1XF0XGJAX0sSqew4j/Tt8ihdpNG1WNqoPV10kCI+5IlyI//2 MNWxMFa3uD/S6f6UxuuvMP+5tNc17iGEAAQgAAEIQAACEIBAtxJQG1Yu2v3Rzo92cLSrI4z03Vof 5IIABCAAgc4QGBs96kz5lAoBCEAAAtMQaG/Ix2C2OgAx6B9p8qGuxYwkdRLivigu0iqdriutXMS3 h/n7dC3Kz9+jfNQBUSgf1yKvyGOiUPlF+gjz9+k4fNwf9+g86hHX8vcqLu5VqLRxXWFe1vz9haZM iouy8vdFXnFN6eK6jnEQgAAEIAABCEAAAhBYaASiPRtt3InaygutTsgLAQhAAALzRwCFw/yxpiQI QAAC4whEQz4iY6Be8WrUTzVjX2nCt88w0owk3d+eT5QTM/x1rjRySq8OhcJQPKQL/ifS5M+jbIUx A0r3yikuyo9zxbXLmRL7n3xHRsftcuTLypcnOVWONqNW2G6ZEfnqnryL/HQ9fy3F18fS6lxpZLmg MNLHPXEeYXCI6/kyOYYABCAAAQhAAAIQgEC3E4h2bHsYckd8nBNCAAIQgAAEJiKAwmEiKsRBAAIQ 6BCBfCM+FBD5gXxdD6+B7sncRPkobT6+/X6dR1n5fPP3RB4RF2F7esVHXu3l5NPmjyOvdjkUn/dx T8RFOe28otzIV/fpWOkVxvW4X9eLvctsi1/bqhM73pb1lpOiJNIrlJfT/XEecekCfyAAAQhAAAIQ gAAEIAABCEAAAhCAwBIlgMJhiX7wVBsCEOgeAjFY3W4BMJmlQaSPAfM4jxpFvGbmy0U+MbAe6SNd nLena08f+Uf69jCuR75xPlm6uB7pI11YKsT1CNvTRXzcF/JGGPERtqeP86i30lXWnG7v/PCHW0oJ xelzUdkKdd4uR/t5e3lRDiEEIAABCEAAAhCAAAQWEgHatQvp00JWCEAAAt1DAIVD93wWSAIBCEAg EYiGfYSBJc4jjPjpwvb07edx/0zjJ0sX+Tzf8Ejznyx9xEd4pHLpPnkpFOTjPPKL8EjzJT0EIAAB CEAAAhCAAAS6noCWS60Na+1V/ZepsBVKPSnUMQ4CEIAABCAwGQEUDpORIR4CEIDAPBOIAez2sF2M uN4eH+dxPcKY8d9+Pc4jPNL0cV97GPm0x093HveFpcdcyx35R7lhqRB7YEheXQuFQ+x9EekjnK5e XIcABCAAAQhAAAIQgMBCIpAsgEcPmT15m1l12NvEvpRr2fdN23haCq08kCkgUDwspI8VWSEAAQjM GwEUDvOGmoIgAAEIQKCbCYRyQTKGMkFh/rib5Uc2CEAAAhCAAAQgAAEIzBqBetVs77NmIwe8cewK h54Ba6w+zrN3y99yMnmYtaLICAIQgAAEFhcBFA6L6/OkNhCAwCIiEAPdz7dKR5rPkaZ/vvJNdv+R ynG06XVfeMmivS9k/RDLKMXeDZF/hJPJTTwEIAABCEAAAhCAAAQWIoHY26xaHTXbv9N6bvyY2Z6n siWVlq23+g+vNVu5yRUO/WalStrjbCHWE5khAAEIQGBuCaBwmFu+5A4BCEAAAguEQCgSpGiQwiGv hFggVUBMCEAAAhCAAAQgAAEIPC8CagenpUfrdWsceM4K8p5jo1iyRnXE93VwZYTays+rFG6GAAQg AIHFTACFw2L+dKkbBCAAAQhMSyAUDbF3RMzsihsjPtJFPCEEIAABCEAAAhCAAAQWA4GkYPCKqB0s Xxv2/Rvcp0k4uQoOj/gyS+4rtZpPzqkli2Bdpp2cg8QhBCAAAQgYCgceAghAAAIQgECOAB2mHAwO IQABCEAAAhCAAASWHIFa1RUL8jkXSglFSSlRdCsHHAQgAAEIQGAiAigcJqJCHAQgAAEILBkCoWDQ UkoTubg+0TXiIAABCEAAAhCAAAQgsFgI1Nxyoe5+pDrsCodhG2xTKgyPjFhjeNgGmssuSfGgtjLt 5cXyBFAPCEAAArNDYOLRldnJm1wgAAEIQAACEIAABCAAAQhAAAIQgAAEupxAWDAolNKh4cqEiJPo eXuGelPh0OVVQjwIQAACEOgQASwcOgSeYiEAAQhAoLsIMDOruz4PpIEABCAAAQhAAAIQmD8C+bZw ozpqjVHfILrNyaIhFBF5ZURbMk4hAAEIQGCJE0DhsMQfAKoPAQhAYEERqI/Ynud22b6Dw+Yrx1ql t89WrF5jgz0Y7C2ozxFhIQABCEAAAhCAAAS6ikAoELKw4cskuVVD25JKsnLIWzp0VQUQBgIQgAAE uoYACoeu+SgQBAIQgAAEpiKw++Hv2t9+/Iu27bBEJ9p7fu3ddvKy0tiVuh+igxjjwREEIAABCEAA AhCAAASmIZAUDK5kqI5WrSDflr7hDezkWVKpjQynEIAABCCQJ4DCIU+DYwhAAAIQ6EoCQ0/cZH/8 8Wsmke1R27ZrxBUO/bbjnq/bn33qW1m6jRfZT//UG+y4/kluIxoCEIAABCAAAQhAAAIQGE9AWgZZ NsjnNQ6K0iWlTn90gIMABCAAAQgcToD5n4czIQYCEIAABLqIQL2+z267+kumNWPH/PF2/vnn2PER 572eev2QPXLT9cn0O83Oevb79sSOoS6qCaJAAAIQgAAEIAABCECg+wmUCg2TzzudFUvF5LXeUn7P h3w6jiEAAQhAAAJYOPAMQAACEIBAVxOo7njYvvzsmIiN9S+2n33fy21Dj8e97vU2fLBmPYMVP6mZ 9Y2l01Ept8rS+CucQQACEIAABCAAAQhAAALtBDRxR4YNmaHDeKVDFps3e2i/m3MIQAACEICAGQoH ngIIQAACEOhKArJmkBsZOZgsG2LTustecp6tbAzb6GhmpFfpc2WDpx2tN6x/uawgsupo1lWlWEj3 KqZYxKgvI8NfCEAAAhCAAAQgAAEIjBFQOzu8llKq1mtWkB9Lkiwa6h4jdQTWDTkwHEIAAhCAwGEE UDgchoQICEAAAhDoJgKH9h4Y6wC5YAN95ZYSQXKOKRIKdtqrPmS/eMFuG6rW3ephja1biYlDN32W yAIBCEAAAhCAAAQg0P0EwsLhMEl9Qo+WU8JBAAIQgAAEpiKAwmEqOlyDAAQgAIF5JxCWDLJw0PG+ HU+lsFbzJZNsvS3zpZSq1aovl1RKs6t0rFlWmeKhZIOr1tigp9T1sJLQ9ZiJFeG8V4wCIQABCEAA AhCAAAQgsAAIFBpu3eD+MNdwZYM8DgIQgAAEIDAFARQOU8DhEgQgAIGFRqBaHfGlhmo+2F6xck/Z jmoRoXrVRoZHtSOCu5JVestWnqXliOou37DLl+Xb4/mmQqb8UypUksJBiRqN9bZi0E25XRHR7iKu PWxPN9F53ZUW1bQWU9HKZec2A7kmyoc4CEAAAhCAAAQgAAEILGQCaktLpSAf7WrVR63vNHHHJ/Ic 3hJXChwEIAABCEAgI4DCgScBAhCAwAInUN33rN17x132/du/ZY9uy1dmg51x0dl24QUvtNOOWzO1 8qE+ZI/ff5fdfevd9p37Hs1nko43nHGRXfSCF9jZZ51ky6f45ajvedA+/7dfs30DftvyF9qb3nSF rSzWbccjd9iN37zBvj9eQDv3ytfblS+6yDYOjo3wq2Nz6Ok77QvX3mGVwR777nfvSJ2dzMLhTvv6 P9RteU9m0aBOjywZ5KJDFFYNpWUn2MtfeZGtnkx7MLLH7rvjNrvl5uvsvnHczE4841wvI2Xb+lMY HbXNl73WLjtpZSuOAwhAAAIQgAAEIAABCCwFAmp31wtFN3AoJstirIaXwqdOHSEAAQgcHYEpho2O LkPuggAEIACB+SOw455v2p996rpJCtxm931f/htmZ77WfvVtl9nysXH91j0jO+6zz/7Z/7UftGIO P9h23/ftGnk7yd7282+zszf2H57IY6oHd9sdzz7bvPacHXzVc/bA1/7U/vGOCZPbnd/+ovvv2ds+ +AE7e93YCP9zj91td91/f0uJkL976wP35JZQGtvDIRQOERaLB+3iq1zhMJZtK5uhZ++xT/35p+yR Vsz4g0fvu3N8RPOscs4rJ4wnEgIQgAAEIAABCEAAAouBgOsVsja4LB3aVk/yRUq9im2Ri6HS1AEC EIAABGaVwARDT7OaP5lBAAIQgMAsE9CAuvy2u66xj3zy2nSsc83sn8in9Pd+yb5x785xA/iKH37m Vvvdj/yt3dvMc9p8Gg/7QP0f2K3PDB9Wq1ROIZMtHTe+Zx/9b39iX7g9i5tINsU1Gs/YJz/yBXtm dCxdoTHUqpcsGzLrhvFFalbVRF57OcgXCn1WSeHY/g3KobH/MfukKxsebtY55Fp3/Gl2/LqJGWZy NmzH/uGWXOOl4QwCEIAABCAAAQhAAAILm0DWhndFg7e/5dtdw9vW8jgIQAACEIDAVASwcJiKDtcg AAEIdCuBA4/YZz79nSSdOgbJnXCFvfd1l9mxq/usPnLAnnvqEbvpn662O7dl13fuOujJ1mRp9bf6 rP3jR/+hdZ7lc4b96Dt/yE7dvN76KgWrDu2zpx69x776ua/btmY5GuT/h49+y07+rVfaVIsLteRq lnDZa95ul5y1xfqLQ7b17hvsk1+5pVW22R122/1X2WvOzuRbd/4b7T1rd1ihVLCH/vmv7Ot3x5JJ 6+0173itbe51hYLvtSBZYkmlQqFuT916jX351rb1kXKlmNXtwe980R71uJBvw2Vvtndcdbat8Prq +p4n77Sr//rqlEa3qozXvP/n7YwB389iRY6fLuIgAAEIQAACEIAABCCw6Aio/9DsYzTrpq6A2sX+ x9vRi67CVAgCEIAABGaRAKrpWYRJVhCAAATmkoAGyMM/9r1v2tN5i4azX2O/+I4r7ZgVFdMGyFbs tbXHn2Wvf/+v2DtfeU66b9P6ZclSIGb0P+t7PtzezEMWBPX6i+xf/Ju32Jm+30O5ULOq8qn02+bT L7Z3/4u32LpkjdBo5nG93Xz/nnEWFUpfTfnUx5VTrx9vb/4Xv2pXnX+iDSZFwYCdcN4r7f2ve2G6 Pyu7bjfc9ogd9Dx03igts2M2bbJ16zbYCcefmeTPrAzW2oZjNtq6jRvtmGOOSX7Dhg0mv27dRtu8 cW1LpvbPItV75Gm77fpnsjKcZ33dy+ztV51u/Va14eFh96PWt+5M+9F3vTylkSzyT2+v27IVK6zP uQS/+Czay+EcAhCAAAQgAAEIQAACC5WA2rhNvUJqg4+rh+/fYPJNJwVEUkJEBCEEIAABCEDACYz9 UoADAhCAAAQWBoHq03bjdY8mWbNB79PsXa863/ryCoiWIqFkJ176Rvu3H/qQvfTkZbn67bHbr75z XCfizT93pW+wPPGSQsWVp9iPv+WSVnqV++3vP2QjuRwVV69nShFFZ7Jtsbf/y3fY6avLrYH6GLBf d/Yldp7LGa4xNGTV5nl2bzZ1qtpcailLN2KNWrZ8VNwX+em87pbfuncqN9y8rnQveuXZE3KrbDzF LvfrSqP89+2XdUjmpss/0hFCAAIQgAAEIAABCEBgoRGQza/au/L53RqkWFDLXR4lw0L7VJEXAhCA wPwSYEml+eVNaRCAAASOmkAMdB/cttXuaSoUFFd/4dm2vjhiIyPZ4H10ABTKK432NGhotn7zfPTZ B+3bzY6EZvDbaa+z45fVPI9qSi8ho7wQuG/zqXZS9UZ7qLkvgt3zgD178AW2uc/zlhwuU1gE6Fz+ yrf78kd9o245MJZf5Fso9NiGk12mhzIFQenRR2z7oYtts2/yrDTKK+Xp+UZ+jUYcm8s6kuoX9VWa EbeQ0D1ZXNVGR0et5vm1WFRrVvZ0dXlPN+DLKClNvr6K9zusuNotNrZnm1LXZL3hPtsbIuOqYxwE IAABCEAAAhCAAAQWHQHN4pE/zKn9q73SsGw4DA0REIAABCDQIsBoSQsFBxCAAAQWBoFCo5QbgPdB /TOPsYIPoI8NymfH+droWjgNqDcamWIh4s87c5OVU/zh+bTyray1k7eMzXhqNNy+IZdvK10zTuf9 PZkyIn9t7Lhi644/Nckt2RRfdB/XQ97pwkg/UZgpD7IcUr3dOkIWDpF25879reOIU1g/tNOedGWD XD5exzgIQAACEIAABCAAAQgsZgLR/s3XMd8Kzh/n03AMAQhAAAIQEAEUDjwHEIAABLqcQDT4NWCu Wf/7ntuRBsF1Lt/rGyvH7HvNutcmyvIx80hh+2z8/bt2t6wRlMe61f0pLx0rrXzZN2WWj3x8gr8t 37S5lU7WBsPVeio7LBtqfr+OJY/yGqm5hUHTUiHyjfwU3yiUWvnVfRaV7ov6RvpiMZtBFfWI+yuV SpIv6pv/GEMxoFByyKdjT1Rqnivu5s/eaNub60JFecrnidtusgdyiomBgUor+yi/FcEBBCAAAQhA AAIQgAAEFgGBVju84BOB3Le7RqHs7XcWymjnwjkEIAABCIwngMJhPA/OIAABCHQ9gYP7trcG5SWs D+0nmWNAXidxnA8VHwPxyiOc4rTZc7i4J841EK846agrzf5F1hk5ZKPDroVouuigTHauPPI+0imM exWGa6Udt3rs2PJIreuTmHSnvHJKg1RGab1d9rqzowgPb7eP/fFn7c7HnrUDvofEvueetru+9Tn7 u+sfzKU51c47aVXunEMIQAACEIAABCAAAQgsVgJj7XFvpY+rZLS/x0VyAgEIQAACEGgjgGq6DQin EIAABLqVQMzSr/peDXGsQfRisTzOqkFWCXLRIVAaHcvpOFkjNGf5R1ypUWhZM+StGnRdexzoPpVZ 92wUKr96vWzFUqbsiHwUhguLAVkixHF2X2ZtoHQlV2bk5VNcyB3lFEtj68QW3CKip6fHenszSw6l 1f2RR9ktO8Zc1kHSNblI19Mzxk/xxeJD9pVPP6zD5JRO8qp8ucvf8ko71vepyNchZEwJ+AMBCEAA AhCAAAQgAIHFQsCbznWfjFTQhKTx+oY0zaktarHUmnpAAAIQgMAsEsDCYRZhkhUEIACBuSSggXAN gq/YuDkVEwPptVo2MK4B8VhKSccaFJeL4/wg+aqNJ4zLY+9QtnGyImOJokgf9/s2zbbzycfH3acT yRSypIv+J8r2g9ax8o28WtebN+Tvj2OlUXq5kKV5koLIT2ki32KzzilBm2VEijv0uH31s/dkl6f9 u85e/mM/bS89beW0KUkAAQhAAAIQgAAEIACBRUHAuxDqRaSeRNadSNXKt9/zx4uizlQCAhCAAARm lQAWDrOKk8wgAAEIzD6BGICPnEu9PXGYwnu37rAXbzkxKQrGDb43B+sjsSwb5JSfLAUUZscFu+nR Z+0VZ65NFgcxeK+ORFyXUqE2vN+eeki9jpjXtMp6/VdE1yJtvR7XUlEpPhQDCuUU6h75klsv5J3K Cyc5dC4lQuSvazoOGXWuY+U1nVNe+558KO3NkKV9ob3t/RdbeffT9tiT22z/IS0PVbG+VStt8zHH 2THHrrcBr1+UpTCOJQMOAhCAAAQgAAEIQAACi5FAQe37fPu64G12+aZTW5j2cNAghAAEIACBdgIo HNqJcA4BCECgCwnkB+KtWEkD8SHm9m//wHZdebId04zQoHi7q4+MWNUH+mPBoXL/MlvvibZFwu/d adtfcY5t6hu/z4I6EjGYf+Dxe+3uSK/w/M22qm0zufw4fHRE2sPILw3eT2SFkC+j7bg9L52LTcQr ecS13ZpO9/uG23KJ5/Hr7Jg1a2xgwwY78cwxixBdk9cG1nLKL89U5zgIQAACEIAABCAAAQgsWgLe FvYG8aKtHhWDAAQgAIG5JXD4qNTclkfuEIAABCBwlARiILy06iR7xZZ8JrfZV25+rDXorsHxMe9K hXuvt9/5/d+3z96yvTUYX1ixxS4+dSyPQuFB+9K37re63xuD9+MG1g8+bl/51I3pWtz1mgtP8m2k x1z7fTofk2NMprE7sqO4rz0+zkOOLDxcIRL3Rxj3TRQ2jSzSpcbWr9vnvnqz3b/1CXvymWds286d tmvXHtuzb58dPHjQqm40EdYZUY8oI5NlohKIgwAEIAABCEAAAhCAwAImIEWDZinJN5UOjaJbR7uP tvACrh2iQwACEIDAPBDAwmEeIFMEBCAAgdkl0GenXXy5fe3RG1rZPnbd39qnaz9mr778TNuwquLr HFVt364n7JZ/+hu77gdZslUDHt9yPXbq5S81e+AbrZht3/2sfax2wN768gtt44r+LL4+Yju23mlf +pur7aFWSj/Y8mo7c/34pZ3yl6c6VkdFA/idcKu3nObF3tsq+rHbvmFbbx9TYrQuNA8KG06zKy+8 0C688Axb73KjaGgnxDkEIAABCEAAAhCAwKIjkLNwcNtft0nO/ukYBwEIQAACEJiOAAqH6QhxHQIQ gECXEIgZRQpXnnaRvWTdDXZ9tkJQkvC+f/683X/D5IP5z+wd8klKYxsg9x17vr3xvG/Y1XdkSwzJ guLZW75if37b16yw8UQ7caBgjz76aFpeKLoWSmN2qr39Dedaf3MAPuTKY+rWgfny2hfa+3/4AfvL L92d6pWXOatbtoSS4qUUKex82L7z9UftpmtPsnf+0rvsjDV5pU3+bo4hAAEIQAACEIAABCCwMAmE JXVL+rrv/SafnC9h6qF8Ie3lwPKiGRf+QgACEIDAZAQ6M8V0MmmIhwAEIACBCQnkB/Cz42V26Tvf axetOzx5e4chO7/UXnnuMW2D7D12+qt/wX7kIu3mMKZ0SMfPPjqmbHAlQwzG+8YN9hM//0Y7YTB2 gxgboE+ZzPDPWH7jb5h46+eRcYkmTjMuSeskukkR0Wjss8cfuydOU7julLPshWedZaeeeqqdumWL bdmyfpwlQ8b7Ufu7j1xve8bdyQkEIAABCEAAAhCAAAQWGQGfVNTwPePqxR6r9q9xv9ZG+lbbaN8q b/iP7XumWuf7KIuMAtWBAAQgAIHnQQALh+cBj1shAAEIzBeB/AC9GvZpSaKe9fayn/qXdsqdt9rN X7vJnnBh4trg4KAdOHDA7MRz7dWXXmYXnHGsVRp1Vxy0SzxgZ1z1Htt46r1262232O0Pbm9tEr18 +XLbv3+/1Wo1a6w/1V5y8fl27hlbrNc3ig55opMRYbHYmwqI6z3qsDQVFhEXoRIW/Vdo2bJlts/3 TWg0Bqyc24Q67iv3rTTJsnfvXq9fxQoT5Bd5FnrKLdnMKim/uKbNqp+6+Uv21Zy+4axX/oS93je/ lvzy2rMh1cWXpNq7/SG77hNfsIe8vKx+37YfPHWlXb65L9Uxi0uH/IEABCAAAQhAAAIQgMCCJRDt 2hS6sqG24lir9qywJy74WbPaiC+o1LBiT79VBlaPWxpV7ey4d8FWHsEhAAEIQGDWCfi4jf9C4CAA AQgsAAJp4NtfWaOjo3ZguGo33L8zSf3i09faYG/ZKhUfjG4OGi+A6sxYRA2Uy6neOlYdq9VqplDw eJ0XfKC+Njxs+w+N2PoNG2xwYND27j9ofT1jlgixb8LIyIhJIaE8du/enfLWn3K57Fs/jNihQ4dc EdBjxx57rO3as9eGhj19byWV30rsB1IC9PX12bCXq58S5ZvCQwdteLRm5Z4eW7t6dcpXaTSYL6c0 qofSS/aBgQEvc9gOjXgaP+/x+xSvNJF2xYoV9txzuzzfqi0b6EsdHckrp7SxubMUFwddSaINn3t7 e73sYipf6QYGemzno0/YH//VX6W6NE5+tX3wjedYX3OjbOW3Zs0aGxoaSl7nQ49cb3/2mZtSGSrn p/71v7eTVmV7VwRP5b2Y3GHfs/uy79kVZ65L3zNxCeaLqd7UBQIQgAAEIAABCCxVAtHuVps99TP2 PGdVb5sffO5pVzhU3bDBJzyVKzaw/kQr9/alCUNqf6vdLqe2IQ4CEIAABCAQBFhSKUgQQgACEFgg BDTDXwoDDajHgHyt5rpjVxJs2rTJVvrgfMmtGVYu10D+oaQQ0OC+OhChbCj6YL7uX7VqVSuPpNCw og0uX5mUDQW3bFi7epWtHOxvKRWivP7+fpP3HknKR52UcI1C1vlY43kn5YHno1BpojOjfORVj5KH y5YN2qDnp8HuvFfnRcoGlbNmzWpP09u6HuVp4D8Ngvu9UoJUvF49bungC8+mtCpTSo2SlW3DySfb +9///qSguOz8LVb0fFVvySJlg+ocbMVrtJjlIZkuueQSO3m1l+/p1RGL+oQchBCAAAQgAAEIQAAC EFjIBKREULta1gzFvmVWXL7RzK0diqs2W2nlsUnZoEleMdlnIdcV2SEAAQhAYO4IoHCYO7bkDAEI QGDWCGhAPFzjE39ptbtut5UrV6bB/hig12C7BtaH//rPrfoTb7DC/n0pje5TGjldL/px9V99wEZ+ +9+1lA4xeK7B+6SEeOoJq73hpTbylX9Mg/i6L9LoWGWNfv3LVvc09ccfS/lKORDlhGzDv/sbVvvg +7zMalI6qB5Ko1B5FA4esOpPvtGG/+IjSYGhwX5dU1nqyOi8evcdVnvtFVa95eakfFAnJ/JRGp1X /+5vrPa215rt2WWr3apCsiiNnJZskm3FyC+91x5539vt1FNOsQ984AP2yOO+fJTHq1O1wa1CGtue seqPvsxGvvD3zTqX7fZvfjvJcumll9ob3vAGO3j9N6zh1yNv5Y+DAAQgAAEIQAACEIDAQicQVgoK 1cZOvqfXSvKV3mQBrbjFauW70D8/5IcABCDQTQRQOHTTp4EsEIAABCYgoMHt/AB3Y/cuK/7MT1j1 rtuSckDWA7IC0OD8wf/1Z9b7R79jlXvvtOr735aUDhrY1wC+FAUlD0dd2VC5/uvW88mP26H/9G/T skgapFfnYe3atVZ7YqvV3/MWK7siofKhX7BD11yd8pdFhLzKGvnaNVb+1Z+zkqexn3prUjpoYF8d FJWnpZaG/vOvW+/ffszK377ORn/hfVaojmbKAbcO0HUpG2rvf7tV7r7dev/k9+1QU+mQrCI8n1A2 FH/6HVZ++kkr/ey7bPT7N6f46AhJ2TD8fz5mJS+rfP+9VvupH3elw+5UD6WR4iMpG37lZ633G9+w k793gz303rfZab5B9Jsv2Gg33PVwWoKq7sqG+rvfYpWtj1jl13/Z9n3q416PtVY+7RUmZcOb3vQm e/LqL9nAL3/A6lKSeB2kOBHX9s9ngo+QKAhAAAIQgAAEIAABCHQtAbWb5dUfkFJBlsxqi2sikvoJ alOrD6A2vNrqmrCjdHFf11YMwSAAAQhAoCMEUDh0BDuFQgACEDhyAjGwfehVr7NGpcdKP/NOq955 m61fvz4N8kvZMPDH/8UOnHeRPf0L/8YqPgA/+r63WfHA/pSm7IoLKRt6vnWt7X7vz9q+V/+I9X3q Ezb0Wx9OyohjjjkmKRukQCi5UuOJf/NbNrzZN4n+t79oQ1/6h7TkkJYdOvTVL1rl137OqpuOsx3/ 4Q+ssHdPS+mg61JsSNnQ71YH+17xWtv1vp+3nhu+adUP+lJG9VrqsCTLBlc2lF0xsu2DH7IDF11u fVI6/M8/TR0cdWhk2VByxUrDOzNP/8bvW31wmZV/7l3J0kGdHnV4Rv7v/7ae3/sNG37hhbb9V3/T yo886EqHtyalg6wWKt5pGvnXrmxwa4xdb3+3PXXJBXbqLTe60uHHk9LhJ1//Mht67FHb+6ZXWeOZ J+0vz7nUtg6usIHf/nV75KMfsde+9rX21re+1Z749N/bpt/6Ratt2GjDL74qKRqO/BPkDghAAAIQ gAAEIAABCHQvgVAghOJBSgUpF0LBgIVD9352SAYBCECgmwiUfstdNwmELBCAAAQmIxCz/DWrfLRW t8d3DqWkx68dsB7fHDhm2SwWM998fXUcs+qH+wfs4KUvtv5/usaKn/+UjV7yIhu++u9t0Afs9517 gT38K//BDpx0qg0fs8nWfPlqG3ULg4IP/A//ys9Z3z9/w7b/5Ads+5veYXsvvMwqO7fb8i9+1g48 +4zZyadZwQfri74s0cMf+m3be+6FtvvSK2zFbd+zvs9/0g6dcLJVH3rQej/0QRs99jjb+p/+ux04 8RQ7eM4LbeVX/9HqrpSoX/UqO/Qn/9UG3Hpi10tfZVt/5pfs4FnnWsM3l1vxj39vw3fcYoUrrrLa T/+EVX5wlz39wQ/bjh96ue3xcgYefcgGvD5DpXJKn5QNxZI98h//0PadeobtufhFtuqGb1jpc5+0 kQsutdFrv2K9v/ebNnTOebb11zteOn8AAEAASURBVH/X9rt8h447wVZ/+R9s9Lqvmb3ih23k3/2S 9V33Fdvx1nfZk2/5STv4opfYwYfvs1Nu/a49+J0brHzu+TbqSzqtOLjf/vycy+yO1Rvs++s22dm7 ttvx377WHvXy9z3xtG3+nV+z2voN9tTv/akVNx6bnrt4zvTcyamDthhc/rnLf8+2rMu+Z6p3zIBb DPWlDhCAAAQgAAEIQGCpEwhFQ7TxFKqNKy9lg6yKQ/GgtmC0B5UOBwEIQAACEGgn4HuPNhe5br/C OQQgAIEuIxBr/2uT3wPDVbvh/p1JwhefvtYGe7OGcDSOu0z0oxInXs9Rb234rOODBw+msPbg/bbp 3/8rKw4dtKJvDh3Khpp3CuTUEVh94zdty//736zha68WDw3Ztnd+wHa+xa0GYpkmDzf9z//HVl/7 Zav19VvBN5t+yJUN+884J6URz4rvBXHK7/269T31eMp35NjNSdkwutw3c26WM/CDu23zf/6wqcuh cnZd9Wrb+tP/SkKkzonyWf+Fz9j6j/9Pq7uJdsHllbJhz0tfmTZtVj491rDj/vC3bJnv1VB3Wequ pNj6239kBzZu0uUkT68vfXTyb3/ISi5TYfhQUjY8/u9/z+pePylk5Fbe/M92/J/8XrICSXX+sZ+0 bW97T2IW9d70139qG6/9qo26pYi51cUnzrrEblq1Lt0vs/H1y1bae69zq45tT5r3tGx07QZ74nf/ xHz9pWRNog6XTM3FWGblcoulwxXPW+t7dl/2PbvizHXpe6a6L6bvWfrw+AMBCEAAAhCAAAQgkNrb wqAJXvkw2rlq+8rFeYQpkj8QgAAEIACBJgEsHHgUIACBBUMgBuCXioVD+wcTA8HDw8Np8PyQWzrs u/ByW/6tr9vB0862R371P7pioScNgkdnYHjLScnSYdWN37Jn3v5e2/bGt6V7xTB5VzjscWuBynM7 rO/xR5Nlg5QNcspDXoP5ey670la4VUDNlzV66Df/wEaWZftCKA/JdWj1Wjtw9rm2yq0CdvuSQ4+7 ZYPfnPKJsg6cfnbKa/lt37Unfv5X7bkrX9baA0EJ666UkEXFgC+LVNq31x75zf9qQ75sk+6Pz77q 5e91S4eVrkg55FYcj3z4t23ULSKCjdId2nR8snRY5Wm2uSXHM27dEHnouhQTe867xMqutFj22MP2 0L/+TVv1prfa+eefbxdccIGdddZZtuWUk2yvW0Os9P0ltHzV/b/xX8zWbUidKy3lJC5SNCjEwiF9 zPyBAAQgAAEIQAACEFjgBKRAkI9+wERhpEHZsMA/bMSHAAQgMIcEsHCYQ7hkDQEIzC6BGFRuzbxe IhYOMVgeioYDB7JNi4eGhrKBdN/kubpqTVI2TERcg+y9nmbk+BMmupwG8xs+qN/nGzMPbz4+nUdH In9D0TdjlmusWp2Pbh1Lzt6nnkgKDikb2jshcd7jio1hX/oozkOZEOc2MuwKkJ026ktCycX1KEjn le3PWt3l0FJN7dcjXY9vaD183JZUTqRRqOdHTvL2SV6v80ROaUu+QXSl5htEr1mX9qbQ7H7tH5G3 cJCJuVxL/okyW0Bxh33PsHBYQJ8eokIAAhCAAAQgAIHZIxBt6MhxsbR3oz6EEIAABCAwNwSydTfm Jm9yhQAEIACB50EgGvQRapBbs4xiSZvY06HmigQt6qMOgdLqulwMHCu+cfKp1pObsRR56lqkq594 ckqjMnQ9Zu6rnNTZ8OWE5HQtX04oRFJ40inW05Qj8lFa3R/pGr5XRK/HxXWFcq1ytESRW1BUmvnE gH7ImerjigTdpbwjnygn8qlLlqasuiane5WfZGnJ28wn1TF3rPNCry9F5UsqVdzLskFs5WNN28hX eeMgAAEIQAACEIAABCCwmAjQ1l1MnyZ1gQAEIDB/BFA4zB9rSoIABCBw1ATyjX0NdmswXKHiY6A8 Bt5DUaBzXdNAfd6FQiIfp+PIR9eVbygCoozIJ8ptL0cD/XnXXs5E15W3fDjJIEWAXFybaTmRT9Qj wrhfeSpO6RSGpYPi5eL+7Gw8D7FQPvI6DjaRlhACEIAABCAAAQhAAAKLhoDvceYNZmvU3TI4tZ99 qo/a7CWfGJRruy+a+lIRCEAAAhCYVQIoHGYVJ5lBAAIQmH0CMRAeg92aaa9BeQ16x0x9lapzpY0B 9jSD3zsIoShQGl0PiwGda+A9LAJiMF73K10Mqsf1UAREOaFQyJcTeej+UFyoHDkN8Ot6uPZywoIh ylEekY/u0b3yecVF/rqO5drlzZej+yWHyoh0uifKijwUF3KIl+J73dpBecXeDVH//D26DwcBCEAA AhCAAAQgAIGFSCC11aVsGNrljfdDZjsesYYvL2o9fWYV74NsOMsKFbcA9n4HDgIQgAAEIDAZARQO k5EhHgIQgECXEYiB7Wjga8A7PwAfA/yRToPjqdPQrEcoCmIAXtG6rvQK2wfYo/pxPQb6o5yQY6bl RHmTlaP88vUJOUNuXcvLK7nk43rIGWHIGwqDqE/UNdJFfNQnzqMsxctLnjjWvTgIQAACEIAABCAA AQgsPgLe5h4ZMhveb4W9z1ihOuJ7xfWb9S6zwvrTF191qREEIAABCMw6ARQOs46UDCEAAQjMLoEY 3M4PiGswPAb6dSyndOF1rnh5zcwPF3lFGPdGqHSRRz5N5DXV9dkuJ8pSvSWLFBUhZ4QhY4QRH2Hk oesRJwsRHYdCQmnkIo/sbOxvlB8hlg1jbDiCAAQgAAEIQAACEFj4BKKdnCyORw5ZcdtDZnueMrvx Y6542GfF5RvNVm6y4Y3nWKHY09ozLt8/WfgUqAEEIAABCMwWARQOs0WSfCAAAQjMEwENjMcAeoQq OgbMo+GvAfr89RAvrsd5pIvz6fKZ7nrk83zLac8n8muXN+Ijffv1ieRV2rAQifsiXZwrjDiF7eXk 03EMAQhAAAIQgAAEIACBhU5AiodGwyf5jA6bSfHgSysVDu21etmXVHILB/PllkI5sdDrivwQgAAE IDB3BFA4zB1bcoYABCAwqwRi8FuWDXIxAK4B9vx5OvE/kW6y65EuwsnSTZdPXI/OR8gZ+baHR1tO ez7TnU9WTsjZHk4nd/CeLt10cnEdAhCAAAQgAAEIQAAC3URA7WJ5tZ8btZqNuLKh4EqHAcW7oFpM VNeHR0as4F7tYrWJo10cYTfVCVkgAAEIQKBzBFA4dI49JUMAAhCYFQLTNfCnux5CTJfu+V6frXIi n+nCyeQ90vjpyuE6BCAAAQhAAAIQgAAEFgOBltJBE5qkfHAlQ8E1DlI61KV8qOskU05M1qZeDByo AwQgAAEIPD8CKByeHz/uhgAEINAxAtHIj3AyQaa7HvdNl26665HPdOF0+Ux3fbr84/p0+Ux3PfIh hAAEIAABCEAAAhCAwGImIMWCvPY4q7tv+EbR2iw6XM0PZFM9Ojrqlg+j1tPTky6FpXOkI4QABCAA AQiIQBEMEIAABCAAAQhAAAIQgAAEIAABCEAAAhCQ4kFWDGHJkBHRokqFtORSLFsKKQhAAAIQgMBk BLBwmIwM8RCAAAQgAAEIQAACEIAABCAAAQhAYJETCAuHtIeDL6VUHRn2vRrcN+ut5ZRqzSWWpIhQ OqyFF/lDQfUgAAEIPA8CWDg8D3jcCgEIQAACEIAABCAAAQhAAAIQgAAEFjqBZNnglUjbRLtSIW0U rd0bfHPocH6Wll6Kc0IIQAACEIDARASwcJiICnEQgAAEIAABCEAAAhCAAAQgAAEIQGCJEMhbLGhm akHLKjVdw5UOySsuFx/XCSEAAQhAAAJ5Alg45GlwDAEIQAACEIAABCAAAQhAAAIQgAAElhiBsHBQ tRsNbRE9pnBYYiioLgQgAAEIPE8CWDg8T4DcDgEIQAACEIAABCAAAQhAAAIQgAAEFjqB2DC6Vqta w30sptQolNzCoZT2bchbQiz0+iI/BCAAAQjMDQEsHOaGK7lCAAIQgAAEIAABCEAAAhCAAAQgAIEF RUBKByka0h4Ofpy3c8gfL6hKISwEIAABCMwrASwc5hU3hUEAAhCAAAQgAAEIQAACEIAABCAAge4l UPI9G4rNzaKleCgWim7hUGxZPHSv5EgGAQhAAALdQAALh274FJABAhCAAAQgAAEIQAACEIAABCAA AQh0A4H85tBSPMi0Qb6phOgGEZEBAhCAAAS6lwAWDt372SAZBCAAAQhAAAIQgAAEIAABCEAAAhCY NwKyaKjWfQ8H9zqWq/mBPA4CEIAABCAwEwJYOMyEEmkgAAEIQAACEIAABCAAAQhAAAIQgMCSIBAm DV7ZsGwIS4clUX8qCQEIQAACz4cACofnQ497IQABCEAAAhCAAAQgAAEIQAACEIDAIiCgDaPli00f VSoUSr6aknwh+YgnhAAEIAABCExEAIXDRFSIgwAEIAABCEAAAhCAAAQgAAEIQAACS4yAqxxaNdZx +3nrIgcQgAAEIACBSQigcJgEDNEQgAAEIAABCEAAAhCAAAQgAAEIQGCpESi4hYN85gqudCgm77tG LzUU1BcCEIAABI6CAJtGHwU0boEABLqHgJrBw6N1bwLXfCOzojeBC1aseQNZa4ziIACBIyIgE/p6 vZ5M6UdGajZc1bF3Lfk6HRFHEkMAAhCAAAQgAIGFSiDf7NNxvh2YP16o9UNuCEAAAhCYewIoHOae MSVAAAJzREAN4JHRmt3/9AErF13RUGJd0TlCTbZLiECs3Vuv1axab9iIh72V0hIiQFUhAAEIQAAC EIDA0iZQb9R8s2j3TafpXfLh2MshSBBCAAIQgMBEBFA4TESFOAhAoOsJSNnQU3bTXp99Xa+7dYPM fH3KDY3frv/oELDLCbQUDm7pIGuHnnIpfdfys926vAqIBwEIQAACEIAABCDwfAiokyXvTn+jj5WO Uyx/IAABCEAAApMTQOEwORuuQAACXUygUirYGccOWrXmS75oISVXNhSbCodicWz2TRdXAdEg0JUE YkmluncypXzQqr3lUtGtiNTvzDqeXSk4QkEAAhCAAAQgAAEIPC8CMfFEval8jyoUDs8rc26GAAQg AIElQwCFw5L5qKkoBBYXAa0f2ucjoHVfSmm0UfdBUbNKOXulqUGMgwAEjo5Ao5F9f0aro2lGW6VQ sqJ/z/haHR1P7oIABCAAAQhAAAILiYCUDlI2qEWYJp9kJg7ZZg7MPVlIHyWyQgACEOgYARQOHUNP wRCAwNESkAWDXl69lVpqBPc2G77FYj1licLhaMlyHwTGrBh6XMmgrmZBm7G7tqHse6RgPcQTAgEI QAACEIAABBYPgbBeDcsG1UwtwHqj6o3CajpWO7De9GoL0tdaPJ8/NYEABCAwVwRQOMwVWfKFAATm hEA0cBWWfEC07pvaForZhrZpBo7HR5o5EYBMIbDICUh/p++SFAxyOs4sHDLLB75fCQt/IAABCEAA AhCAwOIkoP6U1yy1/Pw4c62YxVlnagUBCEAAArNKAIXDrOIkMwhAYC4JxEBnhJVKJQ2G1mq1VGzE RziXspA3BBYrASkY5CIsueJB36m8X6x1p14QgAAEIAABCEBgyRNQW7DuluPyfqyWoe+Wl3x2vOQJ AQACEIAABKYhgMJhGkBchgAEuo9AKBRk0qtB0RgYDUnjepwTQgACR04gvkdhOh8KhyPPiTsgAAEI QAACEIAABBYMAVk1SOkg37RwkKJBHgcBCEAAAhCYCQEUDjOhRBoIQKArCMQAqGZcy9U168ZdnLcr HtJF/kAAAkdFIL5vEcb+DXF+VJlyEwQgAAEIQAACEIBA1xJIk7m8j1Us+LK17pPSQdKWfBtpeRwE IAABCEBgBgRQOMwAEkkgAIHuJMDAZ3d+Lki1OAjE9yvCxVEragEBCEAAAhCAAAQgMC2BsHBoJlR7 MCafKIr24bQESQABCEBgSRNA4bCkP34qD4GFRSAathFi0bCwPj+kXdgE4nu3sGuB9BCAAAQgAAEI QAAC0xFouJWDvJzagNoyr1aV1UO2iTT9sOkIch0CEIDA0iaATdzS/vypPQQgAAEIQAACEIAABCAA AQhAAAIQaBGQWiFTLWR7N0jRkPbPa6YIxUPrBg4gAAEIQAACOQJYOORgcAgBCCwsAjR0F9bnhbQQ gAAEIAABCEAAAhCAQPcTKPgW0fLh0nJKxWKycKAPFlQIIQABCEBgMgIoHCYjQzwEIAABCEAAAhCA AAQgAAEIQAACEFhCBKRqqFcGrFEZtJG+NVZo1G20Z5k1egadAotkLKFHgapCAAIQOGoCKByOGh03 QgACEIAABCAAAQhAAAIQgAAEIACBhU1AVgvyadmk3kHbf8KVVh8ZsueOvcztHBpWGlhpxZ5+6+9b ltJE+oVda6SHAAQgAIG5IoDCYa7Iki8EIAABCEAAAhCAAAQgAAEIQAACEFggBNJyScWSNXqXWb3Y Y9W6LBrc5sGVEIVKjxX8WkqzQOqDmBCAAAQg0BkCKBw6w51SIQABCEAAAhCAAAQgAAEIQAACEIBA xwiE8kChrBtKpVKSpdS/0pdUqlqx7EsrNRpu3dBjpXLZfSWlUdq4t2PCUzAEIAABCHQtARQOXfvR IBgEIAABCEAAAhCAAAQgAAEIQAACEJgfAmlJJVcwlCsVt2YoWt2P5XQuZYS80uAgAAEIQAACUxEo uLY6+wWZKhXXIAABCEAAAhCAAAQgAAEIQAACEIAABBYdgRgWGhkZSRYNCuv1evK6FoqGiisepHBQ KIfyYdE9ClQIAhCAwKwQwMJhVjCSCQQgAAEIQAACEIAABCAAAQhAAAIQWLgEYpmkUDDUarVUGSkW YtmlSLNwa4nkEIAABCAw1wSwcJhrwuQPAQhAAAIQgAAEIAABCEAAAhCAAAS6nICsGuTaw1AySBEh h2VDwsAfCEAAAhCYhAAWDpOAIRoCEIAABCAAAQhAAAIQgAAEIAABCCw1AqFgQLGw1D556gsBCEBg dghg4TA7HMkFAhCAAAQgAAEIQAACEIAABCAAAQgsGgKxt0MoIBZNxagIBCAAAQjMKYHinOZO5hCA AAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCCwJAiyptCQ+ZioJAQhAAAIQgAAEIAABCEAAAhCA AARmTgDLhpmzIiUEIAABCIwRQOEwxoIjCEAAAhCAAAQgAAEIQAACEIAABCCwtAlUh80aDWcgr7++ OEahYIVyTzrnDwQgAAEIQGAqAigcpqLDNQhAAAIQgAAEIAABCEAAAhCAAAQgsAQIaM+GhisbCjse NhsZsvrBna5nKFph5Saznn5rrNxsVqp4XGEJ0KCKEIAABCBwtARQOBwtOe6DAAQgAAEIQAACEIAA BCAAAQhAAAKLiEBBSoeDz1nj0D4r7tueLBvqlX4r1KtWWFFfRDWlKhCAAAQgMFcEUDjMFVnyhQAE IAABCEAAAhCAAAQgAAEIQAACXU5Alg1yo6OjZgf3Wun+6832PGWFJ26zhls42JmvduuGTVZdvskK /SUrl7OhJCwduvyDRTwIQAACHSKAwqFD4CkWAhCAAAQgAAEIQAACEIAABCAAAQh0C4GkeKjXrDF8 wOzQflc+PGdW9GGjkYOujRjybR1cMdFUTnSLzMgBAQhAAALdRwCFQ/d9JkgEAQhAAAIQgAAEIAAB CEAAAhCAAATmhUC9Xk/KhGq1ag23cijU3PsSSmH5MNKMt1rNr9WsWPR9HXwfh1KpNC/yUQgEIAAB CCwsAigcFtbnhbQQgAAEIAABCEAAAhCAAAQgAAEIQGDWCSTFg5QP7k1eTns6hJfCIeKzq/yFAAQg AAEIHEYAhcNhSIiAAAQgAAEIQAACEIAABCAAAQhAAAKLm0BYMEjRIF9zhULdrRlKbuVQ9LDcXD5J qoe6H9dl3aA0nlZWDnE/ezks7ueE2kEAAhA4UgIoHI6UGOkhAAEIQAACEIAABCAAAQhAAAIQgMAi I5AUCFIsNFzF4L7g9VNcUjZ4KMuHUDIssqpTHQhAAAIQmEUCxVnMi6wgAAEIQAACEIAABCAAAQhA AAIQgAAEFhABKRHkZeEgX/CNo+XlfJto6R6SrzUtISJ9SsAfCEAAAhCAQBsBFA5tQDiFAAQgAAEI QAACEIAABCAAAQhAAAJLjYAUCcm6oVlxV0NkR75BtO8SvdRwUF8IQAACEDhKAigcjhIct0EAAhCA AAQgAAEIQAACEIAABCAAgUVHQNYNTQsH1c0NG1p7SC+6ulIhCEAAAhCYdQLs4TDrSMkQAhCAAAQg AAEIQAACEIAABCAAAQgsHAKybpCLfRviOG/ZwObQCRF/IAABCEBgGgJYOEwDiMsQgAAEIAABCEAA AhCAAAQgAAEIQGCpEEibQ8usIVypZCaPgwAEIAABCMyAAAqHGUAiCQQgAAEIQAACEIAABCAAAQhA AAIQWPwE3MZB1g7J4qEQuzikajd3dFj8CKghBCAAAQg8LwIoHJ4XPm6GAAQgAAEIQAACEIAABCAA AQhAAAKLg0CjUU/GDDJo0LFcwYrJL44aUgsIQAACEJhrAigc5pow+UMAAhCAAAQgAAEIQAACEIAA BCAAgQVBYLyFQzJxKHicPCYOC+ITREgIQAACnSbAptGd/gQoHwIQgAAEIAABCEAAAhCAAAQgAAEI dJhA2jjal1Kq12tWkJc8rmio+UHdfanolg5+nvcdFpniIQABCECgCwlg4dCFHwoiQQACEIAABCAA AQhAAAIQgAAEIACBThCQoiEpG1qFHx7TusQBBCAAAQhAoI0AFg5tQDiFAAQgAAEIQAACEIAABCAA AQhAAAJLlkDd926Qd6dVlIoFn6vqnhWVEhL+QAACEIDANASwcJgGEJchAAEIQAACEIAABCAAAQhA AAIQgMBSINBwtULYM+hYTn9RNiQU/IEABCAAgRkQQOEwA0gkgQAEIAABCEAAAhCAAAQgAAEIQAAC i5GA9m5I+ze0KtemYiiW3MzBPQ4CEIAABCAwAwIoHGYAiSQQgAAEIAABCEAAAhCAAAQgAAEIQGCx E5B1gywb9C9ZOvgm0aF+0GbROAhAAAIQgMB0BFA4TEeI6xCAAAQgAAEIQAACEIAABCAAAQhAYIkQ KPj+DfJjLltkSQoHlA5jVDiCAAQgAIGJCaBwmJgLsRCAAAQgAAEIQAACEIAABCAAAQhAYEkTkHVD KBrYx2FJPwpUHgIQgMCMCaBwmDEqEkIAAhCAAAQgAAEIQAACEIAABCAAgcVJoLWXQ8OtG+SbTosr ZQssRQwhBCAAAQhAYHICKBwmZ8MVCEAAAhCAAAQgAAEIQAACEIAABCCwZAhI6ZAtoOQ6Bz/WBg5h 4ZA2c1gyJKgoBCAAAQgcLQEUDkdLjvsgAAEIQAACEIAABCAAAQhAAAIQgMAiIpC2hS5IyzC2aXTN 926QZ/+GRfRBUxUIQAACc0gAhcMcwiVrCEAAAhCAAAQgAAEIQAACEIAABCCwoAgky4Zsxwb9dVVD +pfFLKiaICwEIAABCHSAQLkDZVIkBCAAAQhAAAIQgAAEIAABCEAAAhCAQBcSKPj+DfLhim7d4OYN cUoIAQhAAAIQmJIAFg5T4uEiBCAAAQhAAAIQgAAEIAABCEAAAhBYIgSkVwgLh6aOQZYNWDcskc+f akIAAhCYBQIoHGYBIllAAAIQgAAEIAABCEAAAhCAAAQgAIGFTCDbJLrRrm8wK/riGO5bm0cv5Eoi OwQgAAEIzDkBFA5zjpgCIAABCEAAAhCAAAQgAAEIQAACEIBA9xOQ0iFWUMqOC8m6Ie3lwLJK3f8B IiEEIACBLiCAwqELPgREgAAEIAABCEAAAhCAAAQgAAEIQAACXUFA+zc093BISyk1fG0l9yyr1BWf DkJAAAIQ6HoCKBy6/iNCQAhAAAIQgAAEIAABCEAAAhCAAAQgMD8EtHVDc/uGrEC3bCgUx4aPtLQS DgIQgAAEIDAZgbFfjMlSEA8BCEAAAhCAAAQgAAEIQAACEIAABCCwqAm09mho1NyiwX3TFUol38Nh /PARSoegQwgBCEAAAu0EfOcfHAQgAAEIQAACEIAABCAAAQhAAAIQgMBSJiAlQqNYslrfKmuMDvsq SiVr9CyzeqnXrOy+afeAsmEpPyXUHQIQgMD0BI5Y4aBNg7rJHekPHfLPzqd3pNyj1G7hj/zxiXQm hH9nuEep8A8SnQnh3xnuUSr8g0RnQvh3hnuUCv8g0ZkQ/p3hHqXCP0h0Jlxq/Lul3xuf9nT8dT18 vXeFPfOCd1l99JDVRg5ZoVS23nVbXN8wYOVyT0oX9YswypmrcDr528udL7nay53sHPknIzM/8fCf H86TlQL/ycjMT/yR8p8tqY5M4eCbBjUO7s42D+qQ4iED5esF9vS5ct1N+soKZ7h+oDY9asrfqR+g kL9RyeQvpHDhyW/e2Ej8Sz0Lkv+Ryp+eFz0/Q3vS89/p58f6BjP+xcrM+Ov72k3y9zblL81M/ka9 uWnZob0d59/wWT2F5vPf8Od/Ri9vsU/8Oy9/+t729GfPT5qlNP3PSaMuk2qvw6F9Hecv+RtN+Qsz lN+6TP5x75/p8bs1ezXjP7y/S/hn7/+Cdzhn5OpN+Q91h/yWf//MpAJdJn+jKX9B78+ZuNpo8/k5 0BXPj/Uta/5+zbAJ2mXyN3oz+TX4MiNXG2nyP9gl/Jc3+fvSGDNxXSZ/oy+Tv+Czb2fkqsMZ/5Gh 7uDfvyLjrz7MTNxCll9tz/z317ea7Wj7Wcz7Vzb5z6DvJfnrzffnIX9/LkD5G/nvbzfIP7Aq4z+T Zz89P7n35wKUv+GD9Wo/FxQuEPnH+jVFt3BYZlXvazbqBV9Jyc/d2sFb4WYHdlmj7FYP1WwcpqGl lubSaazHv7+FI3x+GqPZe7/gcneWv7979P4ZaL5/ZsJKz39Tflug8jdGsnZPyD+Tas9FmtReSO// 5u/vTAoR/6b8svLR89Mpd9TyjzbbnSMdll/tZfFvtt9mxDHxb/ZbRv13oKP8m/L3N9vPM6lAN8mf xtvEv9n/mon8s5hm2t5SNAzrGvDzwfrSdz/h4S6rV30AoRMfvNqHlX5rbLnQX9qrrbH5fD/vSz+C E3EZJ//Qbive+DdJfm9BuvgdeHFI/p4BK5xwcZK/vumFyTRRP+ITuXHyO/fidz6Wyd8B0ZN8Tfnr J1yS5LdN585I/oY6HC5/4aaPd1z+RsUHy055Ufb8bDzbCpXeSQeNxV++qA6HnvvvfNwK/hx14tEf x/+UK5L8hY1nJv5jjcPxT1F6flSHmjd0E///40qTLpD/tJdm8q8/dUby26j/4Lj89t2/6wr5G6e/ LHt+1p08A/ldUauBVvG/5ZNNpdX4z2nezvT99cHK2mkvT/IX159kNoXSJHt+pGhwRYn43/Lpjsvf 6Bm0wlmvSvLXV28xDXpP9fxLWVI45IpCl79xy2f8WEqfeSM+vqDE303Sz3pN9vyvPs75V6aUPylL Dj6X8b/tc9ln0WH57QWvy57/FcdOK7+UJYUDOzP+t3/eCsNSWo3HMm9n4u+N3frZmfyFVS5/sTwN /6o19m5L8hfu+kJT6TZvEo8vqCm/nfujGf/l62cm/55nMvnv/mLH5W/0emP9vDdl8g+uTTMmp/r+ arCyseeppvzXmCWl23gs83aW+Htn9fw3Z/IPrHH+pamfH8m/64lM/nu/0hXy1y/4sSR/oX/VtPI3 qt7Je25rkt9+8DUrjPhvcSe/vxosvvDHM/59/lloAGqSSUfp98sHW+vbH03yFx/4uvPvvPz1C9+e 8W92/KaSvyFlw/aHM/4PXOf8NXgwb0/8+IL8+W/0Of9L35nxL/c7/mn4u/yN7Q9mz/8D32wO3ozP dt7O9P31Z77elL/g8vvDM/XzI/mfvS+T/6Fvd1z+hr6zl78n4++DwHp2pnx+NDi87d4kf/3BG3zQ u7PPj/rt9csy+UNhPpn8adxBz/9Td2X8H7u54/yT/C96X/b91eCZu+nkLzx1R5LfHvte5+RP70j/ Ajj/2ot+Kn0PYtyhXf6Ir1T8+XL+5T1PexvO289P3GmF2rD1eHy5VLRyf4+V9P3345RHUV+wuXKu 7Cj7kJXkv+TdHq5qjfu0yx8SpOfHlTyFJ27N+D/uYRq8jxTzF2qiWrHHl6Fy+asXvTMpTYLzVPI3 XElefOL7Sf7G47f75yHl1fzJ3SpJz7qPlaTn/5KfTErbkDvCVtrmQcZ/yAqPfTeT/8k7nb+Ubh1w kl8TBfX+uegdRyS/PfKd7Pl5+p7Oye/tzIaPHUr+xsUuv7d9gnuE7VQTf7UXHr4hk/+ZH5jpfdoJ p+XYNFAv+S/w9ptPugi5I2wXqyW/fnc1/vDs/R2TX8vJFQa97ePy1877MSvMVH61Nx+6vim/t4Ok /O+E0/Pjsif+6r/M4PmZbTH97T0zlzXcfdB177PW2L/DX3oj8/7O009Zw/8U/EvXOHhy1tHWrNsZ uCS/lCT7nsnkdwWKD8PO4M7ZS9KS3wf8GpopL23TkcivWa57m/K76PMrvXN3FBl/n52+0QftNLtV iqgZuOz58YGnbpDfZyfWDzp/b6ynWRrTyK96pxdfdTST3wfPCp3k7/I3NGiqgdYZKs3SDHX/zib+ nZZf2u0hl1/WMTNyDR9z9Rn2rt0u7n3aGgee6yx/DVg25fcmzIxcmqHuHb+Mf2flNw34jbgCxK3E GnVvBk83KUkKK83w9oZKwTseDSlOOvn8i79mGvpgwYy/vxo0U8Nd759Oy+8NlUZTfl8hd/rnJykM /bdXHSfxd4VhR/lL/mFvxLridibyq59b18wgv6eo31+fuNBZ+VeaOnEmxdVM3p/ir0a6N9wz/nu6 QH7nr4kLC1F+HyioN5+fmY1POP/m81PQ+9/fvR19fgYO+PPjneYebw/M5PvraVJ6/853g/zW7+9O dfqlCPHnR+2bqV2b/G7l1lH+/j1M30f/TUrP/3QV0G+VBlml6HTFm9pOHZXfB7zS8yxF7NTg01XJ WpOSx+UuSX6vR0flHxyyumZK9lTVhJ6Ra6jTre+tfn87/PyoHRAWF+n5TwOxk1cj9V2a/Bv++yuF Z0f5+3e37n0R9b0mmac2rjJ6R9XThBf/3dL7s8PyZ+8eb0/qd1Xvn+n4ez2TktOf/8ZuVzz7Z9FR /t4WyCxOJfs41BOfeB9fzGUdX3DFub4LHZHfhdXbXgqEkH9igbPYsc+lYWVXMkhRVTvofd/qkJUr ZSt6fsXR5mSNkkC4n9kP+lTFTnpNJTTU59XYkyYwzqTto9w0xtJ8/k381Y7rQP9FvOpukZ2sLPy3 K71XJq1t7oKeH1mWa3UOye+/H52QX8+DBrwLajc0+Y89Izl52w8lv7/7G66wKib+/v7tgJNiXPuP FPzdmfqzM3j3SEyNnRSdf1rdZfeTHVM4FFxhUtMgd+qLZ8//zPnvSeMmpfT8eNuvA07WGfWRVf78 +LOvOhwB/4K/O9O4j/irL9YBV5T8PnG3oNUSmt/fGfHX5PYDu33ceaePP+j72xn5NTFKk4ckf11t zxnyn03U0yocNNCqF2NNA34asHnyjvSjmQafPH6+nV7aMqdurNrijcaaVbWmYLHHpImXa38AQv6q lA3+o1N68vbspTfDxv5s10/yS7M0uvJE5+kyHetf/kJlhvIfsNITTfn1sMy2cDPIL+O/wmrrT/Mv nTdkE//p5a/LFGpon2vqu0B+nyFXX3e6Pz/1bE3KQtnXosy+ChM+P/4dkAmpOkw9kl+N9g7y1wyt mltmWM35b3C5ppPfvyf1Yed/wPk/fls26NdB+TVDq7rx3CS/rffvr5UO4x+NsfT99Rdk7ZA3Uvbv bvL3Tmsn5ZeGe9P5/oPpVfCO97Ty+7umrlk1srBK/F1p20n5+13+LRcn+RurXX7XOLQ//+P4u/y1 IR+w2bfL+ev52dZZ+X1WcfWES/1t5R3R1SdMyV+/W2ocN4Z8wGPfc/7+6QL5fVZ3/aQrUuesNnK8 v/59pljb+yf4J/m9gVw/6B2OvTsy/vu3d57/KVc5f5/VtvxYnwBQslLTlD7en+Pk93d/svBRg2vr rVY8sKOz8jv/2qkv9/emNyBXHOPPT3Fq+dVBGfIBg30uv54fn3DR0e/vsnU2eoZbyHi7obhsw/Ty i783eG3Ps/7+Ef+dHZe/dubrXOHca/Vl3gAu+xt0iufHRvX8u/w+2aXk709Zy3SW/3obPXu7P/49 VvR36VTyq93ZcP4FWSh5uyG9/zst//INNrp3p8vfZwXfDNSHoCbln+Qf8bbDwR0u/5NWEX+vS0f5 J/mdZ7Hf5ywsT/K3zxSN909q9/tvtCZJmXdWy/78d17+jf576rP1fLZlo+oDIL7MwFTyq4Na8EkW psFun6lblKVeJ9sP/s6sarahDz6VNADlsy6mlH/Y23j+2yX+xa23WNHbQZ2Wf/SAT3ipLHe5fQDQ f8ni/eOHyR32/Oz177vL36MZ0h2X/1gf+PUJUz541vC2vwbSppI/KTt3b0vyVx4Xfx+86eTzs3KT TzL39ozvDVDUrFHvE08nf6nJv+Tyy0K10/JXNWHE35362ZpOfvPn33a5haGeH3/+Oyq/Bp2cf1Xt mV6fresuL3+03yLU97rko9v9oz7gOuztn133WtEVJorTWEDZFQ0a0nADh1Ze2dEc/E0F9Vhd8mvC Qp+Pn7jLyx+lpgmCfpJ+v4Z9gF4Whs6/svX7Lv/+jjw/DZe/WPHJpk359dsrN538pjGWnU35/fmX wrMjz7+/6Av+e5vkP+T8/flRv0Xyx/OSKuR/xvM/ZKVdjyf+DedfkPKtE86f/YJb57Xk71kxI/nN 2w/1nY8l+ctN/p0QX5u3l7zvIvlH/Pkv+PtzOv6j3nY2HzspyULVn38TfynPO+HcktxWbEzf35qe H3+WZiJ/w7+/lZ1N+R+X/H5vJ5wmiC8/xseeN/v7x8dzXP6pxp0l4hj/7PnJ+HdG/obLX1x9vFlT fn2XJ5N/rvBmo6wzyD0b+KtbRdNh3dd8kFD68jRqNYP7ZyuJOkf+U+cvNC/bfWoYeuNpOpdegJ6u 7lP0C+7VUPOb/bbp750u7yO5HvLHPXU1/GYqvw981xN3bzS05O6M/JJb/GbCX2kiXa1R1PBO18if noEFyD94KlyQz096fpuyz4B/1Lfzz7/m1PtAZfPVkdjPQP66K7ek4Oo2+Wf6/Hcb/4Q8fQbZeyje p5OF8b7qFv615u/XTJ+fzvPXsIz/9KffX72/m04fxEye/2Z9O8d/vPzxPBSnkV/c5aO90TXyz/D5 6Ur5G3p/Zs9NUfXQ8SQu5FeodFm7sxPth/HPT8gzidit6JA/nh+1faSg9ieqlWZ+Dsbkr3sbrMXf mWZXJpYi5JclnH70xp7/zsmv398j5d9sbuSen87KH+2B5jjdxPA9Nvh32/OTvrLpKznD56f5Afic fH/e1Iaa/Ds/KYzndWHs+U/tN+9LJQuBafIM/ukdld4/3SF/7Qjlj+9LN/DX+yfkUdg+WJn/SIJ/ vK/07HTT8zPdlgUhf3zPfa505+TXwHD6zvpMe32B9QxN4eJzUZuvIMsF95rlKwWXTjX+r0F0uchJ aefGadzHfzlj/MllL0wjv+QI/iFTZ59/n6HuvMRMv6fal7Bd0RZyRhjy66lR67uTz4/G3YqudGho pv0R8s9+JVT3bPxQ9ZpfJ34qO5M/jQcewfMT/OsuvybodUb+sn/Psu9BPD9TMQwZRVpV1bhnJ+XX 764/AM7On+MZPD8hv5oKPrfWa643f+eenyS/nh+XQ+9P9d0lY7wn2z+LkD/xb8rfSf6+JER6Tye5 XB6FU8nfXp/ZOJ9U4RCw9MWUH/FZTvV6yarHXW62ZrdVZZLtAqcv7mxIMl0ezR+2kmtUteFycfXJ vp7Wait546Xk8mkmqD74eIG3yy9NU71RtuqJVybTtKpm3HdIftOGp6tOTPJrUZ9ik7Hkj4e3XX7x b7j8oyf4zFif7SeTGKXpBH/tmVFY4fL77L6yvzxmIv+hUZfX3Byyyb+j8ov/ihOS/BV/ERf92dFz MxX/0RGfKd3otZEukb+w3OXvW20Vf3FMxV/fCy1HNOxWAg2fUTos+X2GU6f5F5b5zO7eyeWP18GY /P5yLPXb8AmdlT9phLUO5LLjkvzlSfi3yz+iQZ7SYJP/XqvJJN7dfH9/Q/7GwCafIL3Kevydo0FX yZF//kN+zRDS8zOqxkppwOX/oWTp01n5B63e7zPryytN8xOnkj89P1WXXz+25eXZ8+PmsZ2W3wZ8 Zn1lRfb9nYJ/9vzXXf6Ky78i498B+WMGq35/tQdIo3edW2gOtt4/8XsVv1/x/CT5vXM16rNb6j6j Yvikl/iMm/nnP05+Xzd9OvmjPvpeaLBv1Gez13tWNvnvn/fnZ0x+n2Wjdd/93V8s9/kLRPsLZVao Yh78x8nv76jR8oDV+9Y6f//+uqVnTRaf7ubr/TNefp8l57PLir4eS/x+JWFyf8bJL/7/P3tnAmBJ Vd39U2/vdfYVZhgGhk1U3BUkqMSVuEQUYz5BzKZi1EhCjIp7XHA3iRrziXEhRMU17kvAD5G4EAWV fR9wYGYYpqf3t1TVd/633nldr+a97tfdr/v16/nfmepbdesu5/7qVtWrc+6ibS3QNud+P2gPy47L n12hH986slaNyCkv+v0QE9/9NkMdsKn4Utbe1GHvhuj5r/K7nk9IoOcXwx3EX5+FOq7KyR/OJL8+ Y4ta37A3iNpPp+XHlG76Lkrh41Wf7fBzufrpGY2946+ASzmdN1hnAvWO1N8P2juwo/yd/P0qt348 67vVqSBViRd3Jr97/mgTqVTld/dvx+XXtuDpN5hqAXLa/mEGtPZldYjLD2VBJbda+etvCP394OlI ebt/F7P949mYwqKVWAMEIxuUvaD96GUw+ePPT9d28PxX+Uv67An7NSJ+/ywF+ZW/V9Fnj2s/zeWP 3r9azZ51quDMyMQ2ff92Wn6dUi8MdW2AUlkKOsUM3PT8PZmsyi+QX3UPHW0/mBJQWXo6ahwKeMg+ rfx6h0/2rnd1liNP6xh//XGgUyHpc1Ll91WXkFKdCL57p5Pf1UunXpWVh2uP3j4pY+06bT9F3Dvq 3ExK6tt94wIX4I+Tw8mv7WUa+a1oe/649q/fXn7fYfqc0hFlRz6pM+0nGgqj/FX3APkDbTOq0zH2 rn4mvPpJ+SsDmyXUEX1ypM5o0In2D/kx2qUqv06y5dqPyZ+8/nXy60LjxYHDVX79btiq3706JY6P aWngFuv3j+Ov8ut01OAfqi4T7b8l+fHtu+IInc5rUGcq0JeBjjjsjPz6/sK7S+VXy0FL8rvvd5Xf V31jqL/h9CO+c/Kj/bg1BPD81/Yfe/40az8Hy6/vb50WqCP8Ib+OLofeGc0X929Sbxg16qn71+md NW64crvy19+govdwp+TXeyDdty6SH3rPBvInr4PVp11+U4NDsgD340s/PMJe/eGlH99lTHGCn5rV F08yftuP9WUDl8EiRvojJaXzkGN4mt4+7uHsTk7zxz0AVf5yVX5/UodZd0h+UfkzVfnNUjaN6O6U 8Q+q8lf0xw7kXyyFAX6swGX1w86DwUHn706lC/qDAxZLfQjP4Ex+az8dl19/PKV0DnhI3pL8Gi9Q 6+ZS4C+qaMroUHYonPAx1MoIB7XDOuu246+Gh87y14UGYTTUNRz0Z3tL/F3PBFVa+mj/HZIfD+MQ zx/90ZVWowOeQ2j6M7cfTYe0+rFb6cHzM69TMek0LYt8/8blT6nRzVP+rcmvdUSvDo1f6dEhnR2W X8AfRkOVp6XnJ9ib/K79FDrLH1NR4BmqCtfpnj+1dqXyo2eW498h+fHDHO0HBgf37NfF48BU7wb3 5IesyR8rNfk1Bnqm474N0H70vbHY7T8uP9aeyOjifYEqC+zVNb38+oMd7Ufv9wD3rxo+OyK/sk7n lLi+u9J49qhMeH7CtSS/XrOggOePyo+pfrTyi/X7wfGPyZ/StoAeQ2o+cW5W8quyuZPyQ/GSwbMH 9+Q08uMU6oU4Ae51ved91356ncIb52oNsJrPQnl1/PWjO41nv7Yf+13XrNwlL38zwavhkB+/kfDs DPWdUdb2L+mJDvMfUP7acUqfp3oBpq2B46/yY+7vUH9z+Lh/l4T82p719/BMzrVxraOP+0XbfwjF a1b568euc7gHFsFZ+8/k9fsF317a9qNeq9MXXms/+K2t721fFd+Sneyo/FiDK6Ps0XJmoldrP/qb Kchrp0Eo7jssv+cWq1SF0/To3VknP37/6G+GQN/bYZ+2H1W4drT9qPy4b93oyBnqELUffQeoriLI V6SiRn/JFLXDZtThaLGe/04xpjIHBTW0gb/+g2ytuhDrHqrxzcfvt6wqXKsdFuwaJn/7tZpvq/Eg P5iHBf3drPLje7al716tI2rpa9sJ8trpFO9flX/R+buph1R/oMYba/+t8K+1H50+DR2/XPvJljon f0G/e5U/nj6tyg/+AeRX4677ftdFcyvaAVWzWLTfP66jlD4zs9pZB/Ljd8+s2k9cflUYd0z+Xp1C 0smvV6CF+zdqPzH+2v4l1xn53RoOvfrsQfvRa9Fq+8Gojqn2o+/fDrUfjGwJ1NiDqazcSCvXfA/+ 7tXgmkMd8ayqVNtP2Kvv3w7Jj5mJcv1rovZTfftCvoV+dtdg6M6sDA6+vvRHD3ucGmhKMjI65h6A AXpOA2oLjT9ecKv7gGFA8KOxoC8cPDz6Blaq0kAVlpjDsoWy8bKsqKJseFMk//i49rLRB3gn5E+p /AODOjpA5e9T+fHDZSZ+OA/+w4ed7PiPj+sCTh2Uf3DFaie/2swc/2byIxwbprKqqKJgycg/GMmP 9oMfTTPJjx7ekH+0Q/xxD1j7R/sZHFzj+Pfiw2mm9qNpfYxOSvXX+E9MLG77byY/pmibjr97Tqj8 FVVNVbSHgbWfzsmvCxWDf2/EHy8e+9Hd6JkWtf1Q5VcjbTqS39ePDdy/eCYt1vNnir8q69VoMqDr IOD5A/4zPT/dC1OfnWXtITF82Cm6nknn5O/pgbK+Xv5m965dD8hf1mdnOefJyBKRv78wxd/kTPr2 3nP89YO1rL3qOid/1IuvpydqP4P6wxXtJwfFhz5/ki5+TdwQbO3RXtYRYtZ+cP8ubvuP5O/trbYf /fCP2v/MP3whf0Xlrwjev1H7X2z5rSel8R/QHrcZXUAR/Kdz7vmD9q+jaSphQUYOf2Ld/RtiQb+Z 3h/TFTDDObTh6Nmjz0n9/WbyDxbWud6WprS09mJt3rJ18msdy3ld98fT3w9V+Y3/Ystfaz/51Tr/ ab7GPym3yQ8fiv1JHR1T0d5No4dF/Cd0TRy0f2Nv9Y+na8d+kr/J359bKVk1+pjBsFlZjr++4cr6 vMLvh5ElIv/gLOR3/HU0ZcXrq8k/qR2mOsl/UH8LZPU3QVbvvUbPz/j1wDD8SX1eVVIDMrxZFa+q 7OuE/FD64f7Fc3NQf4vp+BjJ6/3dyFm7xjnIX1JFcUVHVA5vhuIJ8uvCx4vc/uvkT6vSXnt5zyS/ a/8qf9HkP6yz8uP+Bf/+lPrayxXjeho9O+r4a0edyb4Nyn+V8h+o44/rE4+L43a6+PMH/E3+Qf2W wuj4ZmVbOHx0Vij2b9J38BoZFh1dEGs/kNXitlNuy6u5/Ko4bvC7x9KZTPAD/cac6FP5s2tkRLR3 bEflr96/+ns+o/dfM2fvM/gw1pZWbNHORqr3yax18heLOq99Nb3VtVle8wmP809p+xnoV2O/tv8+ lb+VKZVQdqjG/onBw1VZv17G0uucscSeP+68XiPUYSFcM/n7VX48+2dyjq3KPzawVSpqMBxP6/o/ HWg/MJCDf39f9fmD0Z3TtB+rl2v/Tv4jnPxjmY1O/sVuPzX5q+1nQPm3bDDUtdLGdEaPSqEkY1ld P0f5m/wL2fbB0NqPyT/Q3199/rcuP9r/+KqjpdJXktH84U7+aMaaqd+fdr3a7TeVH+2net9Nd++5 9qPPz/FVO5z8I/ktTu+82PJnMjoXDZ4/A/q7wb1/p5c/3i7Q2Whi7XGR3rxn26LJD/Zw8LM6sg1T 4cXlb6X9t7s9tGxwgNAAHsBS7+mwtop+qKvCG/PQxeG2W0Cl5ayRyDdUYLBwhyqHm5ZIFX+AaGCn KxtxPE2HVerDlPbuU+VNp+TX7k1qZUc99CE+a/l1WJo+LDEkjPJPd8Wr5xq0n7nwx3WCojnU3o0d 4a/1sPbv5EePN/2QaLn9qPxIJxhSmNZpctB+cO8u1v27zOQXVTap5bMl/u75BP7afsA/VP7u/u0Q f/f8rMrvnou4R6ZxTn4oNrW+nZdfRyWhHXe5/J7Kj8VCW+aPeR/0R89S4O/asSq79YE4i/afkF+V PZ15/uh0aLgPW5DftXu9L9w1QtvH/Gl2/y6y/O7Zr8+QsKAje/C7R39AprQ9xGVsdAvjPN4R7t7F cAKT357/Lfzob5Rvy2F4ttizPyY/2rK1f+Rl9UjmW5Nf25rrHmPyG/9Fl9/aj8LUe7KZ3FYPnHeb LtjmZfUdjt8PaXTSqbb/Dsnvgf8s5Fcrrz5zl478rj3rO6lV/gfJr8ry+G+f6T567VrOyT+o/Vv7 0fas90Mr8kf3b8Tf3b8ZbT8dkD/Ac6RH56XC81Pfwfj2msmhfpAfSo9QF4dH7/zQya8jTmK/PReD f7fLj989ofYwDpU/vkVcu5jhAhh/jAaVrF6vBH8kX4zvd/f+ismPb/GZ2j5kM/ndCCXKDySzc/Hn zzz4Y1YGvem1/ei3C+5fT2eI0PsXbrHaD545gU7nGaDtt9h+nIBgoMZ1tbDrKDGVPfb86R75o/s3 7NT9q7wj/jpSZC78q+2nxn+x24/Jr6PU2in/grZ9NE67f03+ubb/Gv/q/ZvSGVJi7193nyzEn4T8 IaaznWX7we8MjC53aygU9P6F3nmx5VeZ0f4x0mtO8mNEtz5/ZBHlhznT/UbQaxCo7DD4z0X+djYL pdjY2Y8BCIx9W028Xy1s6FmPucBh4bZeKo1zaU+oyQIfc7VCJtdTTgFCLpPR4qFU27dzkBf7Jj/y 6Wb5jf+CP/ASLI0jeqqA51z5d1r+vj6dUknlx01obcTaTCvtp1PyW/s3/s3kRx3grG523VDv+P27 2O0nLn9cdsjZyC1V+e35Y/LF2068HlZH1Bv7eOaAvz1/ljp/k9/aT/L52Sn5k/ybtR+T3/hD3qXA 3+S3dtNMfmtfS0X+fF571ui96kYaanuG/NiS8lu97Ly1Hzx/cA8gH/vtgGuykM5kgYztkt/uX8jd CflRD7Rt42t1NI7xcOwjPt7V9pun2+W39rNY/MEw3n6MP8KSbR8yGX/bx/2C547x76T8aDd2/9rv esgZdya/1XupyW/8W5Ufz1vwx72Ka4D6wIdbjPvXOJrcM/GHXHYN0L6M/1KR3+phzyDIG3cmu9Xb +CPOUuDfqvx2by8V+a3d2O8B4w/OcWfHJr+1d2s/qE8n2v9s5bf6mfzWfrpNfms/uC7W/u25Y378 +rVz3+5BtAVr9622H+OflD9aUzL63baY8s+2/Zh+wuS39oN8TG7z28k8nhf4g+Nc+ON3M9Ka/J1q Pyb/bPk3kx9z2xt38+PM2rkf52/ym1zWvhEn7uzY4iX5W/tHvG6QH/e9/VbC86fb5Md1w+833ENL QX6wRNtp1n4gJ9qFtZ9OyG9tEz7kgG/Pf5MfciIc22K4pgaHZOEQDM4AowK48IC60DccyjUwKB/7 Bgzn4GYClpQfsnez/KYw6BR/u9ki+rPn30n5rQ1ZW55L++mU/Nbu0Z5nKz/aCtIjbbztL+b9G5cf cmCb6d7F9UE8ym932+x940z+3dX+7d7o1vYP+SG7yZ/83bDY76/Ztv9G8pviErLjOboYbq73L+Vb Fl9EAABAAElEQVSf/9UBQ9vQfq09m49zzVwz/oi/WO3HZIeflL+Z3BZO+Y3E3H3yr3/+4/kJx/bf Wpuy9oPnjf1+t2+Y6XJAOjj4iA+H+x/8EbbY/OcqP+RGvSE3fLxzu1F+yNyV8uO7MSjpIus6sa36 bt20rI7Q0+uC9XEW2oEbtvm2nzh/5LWY7R/lLQf57blj/nTXHrzNod0vBf4mt/kmXyN/OvlxDu0H 20I7lGXtx+Q2f6aykRYb+CMPPEPjz0/KPxPB6P3Zrfzt+s9V/pnpzC6GTkM4/R1jp7FaOPaTPipk cWZXdOuxrQz4uNHg4OPYHmQACoewuDPZknLbseUdT9PufSsDvslvcls9KH+7qU/l1w7+ZpHHAzt+ H1jeU6W1f8/KaNR+rB3hHJz5JoW1f8pvRGbvHwr87fmTpNMt7aeZ/KYQtuf9Urh/7T6GDwUAXLfJ b88d+N0kv8lt713Kv7i/3+bLP3kf27PZNcIF+mNlwJ+r/Mn3rz2HLO8FEt1la2XMVf747x3wh1sq 8tvzE3Vr5PD870b57b0Ln/I3urKth03X/pu1n+XC39q/3a9L5f6156i9f5P3r/Gn/K2382YxG7X/ Vvm7921J1xu6439EytV1b3R6rsq643RqkYJOsaRTBOoaUcnr10yWuYTPR35r93EfMtix5T0XuVpN Y2XAj3O3Y+SD/biz9m9yJn27L+JpFmq/nfLb7zfUz+q4UHJbvnH58bzHcfL3f6v8Kb9Rbd2P80dH XRzjexf+TM//ZLvvNP9ulR9XC7yt/c/Ev/WrO7uYLY9wgLBwuFHjD4r4/uyKnl1sK99AITXCLHym 3CzeUpHfZDe5KP9MBOZ33jhb+yH/iGen7l/yJ//Z3NHL7f6151CrDKz+S+391W3y24eGPX8o/8L3 0ALjePs19hbWyjWwuNb+7Xix319zbT+4301W+N0kP2Q1efGBSPlbabH1cYzfXNoP+deznMsR+Uff 77x/59J65vf+6vr7N9QRMSN7RIojWMVB58DXhafXbtd1HHRaaigOW1gLaG7Up1LN9f419lDQw3Vb +28mPxSxi+nazd+ux2LVwTjadxf8VpylM3mt/dhxK3m0I47J0e3yx+vRCheLb7w7zd/k6bb2Y+1m tvK3co1mE2fGEQ6WmX0s2YVPhtvxQvkAFXfJC548H4+LfcqfJDK74yRf8o/4WbuaHc3Zx27GPxne LGeTc6ndv5R/cRV+1j7s/iV/8rc2MZ2fbCdsPxEte65Ox64d58g/uk/5/ppba2L7YfuZW8uJUrH9 dGf7Sb6fuu35Sfnnc9dOpZ3t/WvtBHO9y4Fdkv/K3zhfAlV0962V4h9eILJis3irj1AtfrSuJkpL ljMlwfz2kvm2+vuT7Wd+3C01+Uck7L4wLsn2ZeHt9smf/OfSppLtxvJo9flp8dvltzzCwQpsVgE7 v1B+u8ptVz6zrWe7ym1XPpR/tgSi+OTfWW7kT/5zI8D7dylw4/07t6vQLm7tyme2tWhXue3Kh/LP lkAUn/w7y438yX9uBHj/LgVu3XT/QpnqFKqYlm5iSDxsoa59mdb5+HU9B2d80H6gqJPVy/z5sG6U tl35tiufRjJOF9auctuVz3SyNjrXrnLblU8jGacLa1e57cpnOlkbnWtXue3Kp5GM04W1q9x25TOd rI3OtavcduXTSMZGYYtdXiMZ4mEtGxxMcPPjmXTDvsltfjfIHJfR5DY/fq4b9k1u87tB5riMJrf5 8XPdsG9ym98NMsdlNLnNj5/rhn2T2/xukDkuo8ltfvxcN+yb3OZ3g8xxGU1u8+PnumHf5Da/G2SO y2hymx8/1w37Jrf53SBzXEaT2/z4uW7YN7nN7waZ4zKa3ObHz3XDvsltfjfIHJfR5DY/fq4b9k1u 87tB5riMJrf58XNLeT8pb/J4KcsO2ZLyJo8pf3sJWI9t9OTGPtYe0j9SUEMDjA1wuAYlrOWjW1bj aMTaGmTWc7a9Us09t2R7SR7PPefFSZmUN3m8OFLMvZSkvMnjuee8OCmT8iaPF0eKuZeSlDd5PPec FydlUt7k8eJIMfdSkvImj+eec3embG0is+6sG6UmARIgARIgARIgARIgARIgARIgARIgARKYgQAM DjA8mPHBoodBNL0Yzsf37Tx9EiABEiABEkgSaHmEQzIhj0mABEiABEiABEiABEiABEiABEiABEiA BLqbABYlxmYjHGzkg9WqoudC3TIwOuhGRwIkQAIkQALTEaDBYTo6PEcCJEACJEACJEACJEACJEAC JEACJEACy5RA3IAAo4OnoxziDuYFjGzAFqixwaPBIY6H+yRAAiRAAg0I0ODQAAqDSIAESIAESIAE SIAESIAESIAESIAESGC5E7B5xmF48Hxdw6FSOmgUg+/rGg+6YbqlpEFiufNh/UiABEiABGZPgGs4 zJ4ZU5AACZAACZAACZAACZAACZAACZAACZBA1xOIj3AIMbqhwQgGN8qh62vKCpAACZAACSwWAY5w WCzSLIcESIAESIAESIAESIAESIAESIAESIAEliABT2Xyw4pOmaRbQr7QSwk2OhIgARIgARJohQDf GK1QYhwSIAESIAESIAESIAESIAESIAESIAESWM4EMLqhwQgH8dQEgY2OBEiABEiABFogwBEOLUBi FBIgARIgARIgARIgARIgARIgARIgARJYjgQwrRLWZ8hU7Qp10yxphd06D2pwwNRKdCRAAiRAAiQw EwGOcJiJEM+TAAmQAAmQAAmQAAmQAAmQAAmQAAmQwLIncPBqDTA2WKgtML3sMbCCJEACJEAC8yLA EQ7zwsfEJEACJEACJEACJEACJEACJEACJEACJNDdBDBhkl/xxcOWrIqX1mEOutGRAAmQAAmQQAsE OMKhBUiMQgIkQAIkQAIkQAIkQAIkQAIkQAIkQALLlgCsDLaGQ9zigGUdcAoVd3+wQ0cCJEACJEAC zQlwhENzNjxDAiRAAiRAAiRAAiRAAiRAAiRAAiRAAocEgbQX6noN9VYFHKXSKQl1w8LRnFbpkGgK rCQJkAAJzIsARzjMCx8TkwAJkAAJkAAJkAAJkAAJkAAJkAAJkEB3E8BC0RjYEA10qDc6RKHxYQ/d XVdKTwIkQAIksLAEOMJhYfkydxIgARIgARIgARIgARIgARIgARIgARJYcgRgZLAN0ylVAl2/AVtM UoxoCDQE5giOboiB4S4JkAAJkEBTAhzh0BQNT5AACZAACZAACZAACZAACZAACZAACZDAoUHARjgc VFs1OmA6JToSIAESIAESaIUADQ6tUGIcEiABEiABEiABEiABEiABEiABEiABEljGBLxQRzfodpAL 1diAjY4ESIAESIAEWiDAKZVagMQoJEACJEACJEACJEACJEACJEACJEACJLBcCTRbwwGrObiplHSE Q3Jlh+XKgvUiARIgARKYHwEaHObHj6lJgARIgARIgARIgARIgARIgARIgARIYFkScGs4eCkd4JCS VCrFdRyW5VVmpUiABEigvQRocGgvT+ZGAiRAAiRAAiRAAiRAAiRAAiRAAiRAAl1FAEs0YJQDFo9O Ltegy0VrXTilUlddUApLAiRAAh0kwDUcOgifRZMACZAACZAACZAACZAACZAACZAACZBAJwnA0OCm VPJ1DQfdki7UkQ3Y6EiABEiABEigFQIc4dAKJcYhARIgARIgARIgARIgARIgARIgARIggWVNAKs0 1K/UgEEPtTUc6k8taxKsHAmQAAmQwNwJ0EQ9d3ZMSQIkQAIkQAIkQAIkQAIkQAIkQAIkQAJdT8CN cNBZk2pTK8VrpOs3CLaqgwHCGSEsgD4JkAAJkAAJxAhwhEMMBndJgARIgARIgARIgARIgARIgARI gARI4FAjgBUaams4xCrvFo3GOd1oZIiB4S4JkAAJkEBTAlMm6qZReIIESIAESIAESIAESIAESIAE SIAESIAESGBZEwh0/QZsBzmojlLO4ECjw0FwGEACJEACJJAgwBEOCSA8JAESIAESIAESIAESIAES IAESIAESIIFDjYCNcIjXO75sQ3w/Hof7JEACJEACJBAnQINDnAb3SYAESIAESIAESIAESIAESIAE SIAESOAQIgBDA7aUF+oohoPNCqGXEWx0JEACJEACJNAKAb4xWqHEOCRAAiRAAiRAAiRAAiRAAiRA AiRAAiSwbAnEDQ3x/eraDVhNmo4ESIAESIAEWiBAg0MLkBiFBEiABEiABEiABEiABEiABEiABEiA BJYtAbUxBL4vnm5uhehYRQPdrzdBxE5ylwRIgARIgAQSBLhodAIID0mABEiABEiABEiABEiABEiA BEiABEjgkCKgAxgwhsGNY4gNZogvEh3fP6TYsLIkQAIkQAKzIsARDrPCxcgkQAIkQAIkQAIkQAIk QAIkQAIkQAIksPwIeEEg2GrO0z6qujlDg06pBJ9Ghxod7pAACZAACTQhQINDEzAMJgESIAESIAES IAESIAESIAESIAESIIFDgoDOmRSmsyKZvJTzq8UPU5JKpcTvWa0LRleNDlUQNDocEi2ClSQBEiCB OROgwWHO6JiQBEiABEiABEiABEiABEiABEiABEiABLqbAAwLYTYvlcFNUsmvlP2PfY2ElZKkdERD SsN7+tZIOp2uVTIMQ450qNHgDgmQAAmQQJIADQ5JIjwmARIgARIgARIgARIgARIgARIgARIggUOE gJsqSY0OXjqnIxxE/P51uoB0RVKhJ+mMBqQzbrSD4eAIByNBnwRIgARIoBEBGhwaUWEYCZAACZAA CZAACZAACZAACZAACZAACSxjAmY4gI9RDplcTo0Oaan4qyXAeg6pKDyXL0hGDQ8Y5YB4dCRAAiRA AiQwHQEaHKajw3MkQAIkQAIkQAIkQAIkQAIkQAIkQAIksEwJmNEB1YNRAS6dzbrFo80QASMDDQ0O Df+QAAmQAAm0QIAGhxYgMQoJkAAJkAAJkAAJkAAJkAAJkAAJkAAJLEcCMDRgXQZsGNlgxzA4YMvn 89EICI1nYcuRA+tEAiRAAiTQHgI0OLSHI3MhARIgARIgARIgARIgARIgARIgARIgga4lgFEMMCjY AtFmXLBwHNORAAmQAAmQwEwEaHCYiRDPkwAJkAAJkAAJkAAJkAAJkAAJkAAJkMAyI2AGhOR0SWZw sOrascW3cPokQAIkQAIk0IgADQ6NqDCMBEiABEiABEiABEiABEiABEiABEiABA4hAmZQSBogLPwQ QsGqkgAJkAAJzIOAp3P0hfNIz6QkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQALLhEBSTUSDwzK5sKwG CZAACSwSgdQilcNiSIAESIAESIAESIAESIAESIAESIAESIAESIAESIAESIAEljEBTqm0jC8uq0YC JEACJEACJEACJEACJEACJEACJEACsyHAEQ2zocW4JEACJEACSQI0OCSJ8JgESIAESIAESIAESIAE SIAESIAESIAEDjECoV8RwazbQcn5nqeTYnieSKYQ+YcYD1aXBEiABEhgbgRocJgbN6YiARIgARIg ARIgARIgARIgARIgARIgga4n4NZsCHzxJvaLlMYlvO8GEb8sYSYvkuuVcMujRLIFSS4m3fUVZwVI gARIgAQWhAANDguClZmSAAmQAAmQAAmQAAmQAAmQAAmQAAmQQLcQCCUsTYpMjokM3ydSnpQw2ydS GNARDzrygY4ESIAESIAEWiRAg0OLoBiNBEiABEiABEiABEiABEiABEiABEiABJYLATeyQSvj+74a GIoS7rtL5MAuyfz8P9TwMCypvtUiKzZLcctjRFJ5yWazruoc6bBcWgDrQQIkQAILQ4AGh4XhylxJ gARIgARIgARIgARIgARIgARIgARIYMkTcIaHMJCwoms3qOHBmzwg4fiQSDorYX5EAl3bwdO1HRCP C0ov+ctJAUmABEig4wRocOj4JaAAJEACJEACJEACJEACJEACJEACJEACJLC4BGyEQxDA2OCLXyyK 6JYNdOFodb56WEO6XC6Lp1s6nXYGBzM6mL+4UrM0EiABEiCBpU4gtdQFpHwkQAIkQAIkQAIkQAIk QAIkQAIkQAIkQALtJ2BGBx2/ICGmVoLxQf+ZMaF2vjrCof0SMEcSIAESIIHlRoAGh+V2RVkfEiAB EiABEiABEiABEiABEiABEiABEpiBAIwJ2DCCoVwq6TbpNgxrQLivIx2wTU5O6sCHotoiArfNkC1P kwAJkAAJHOIEOKXSId4AWH0SIAESIAESIAESIAESIAESIAESIAESCNWggBEOcBjhgImVAjU8JEc7 uAj8QwIkQAIkQAJNCNDg0AQMg0mABEiABEiABEiABEiABEiABEiABEhguRPAyAUf0ykJjA06pRJG OOheyktJqJszOlRHPeAcHQmQAAmQAAlMR4BTKk1Hh+dIgARIgARIgARIgARIgARIgARIgARIYJkS iBsQ3OLRZlBQuwJMC27TaZXi8ZYpClaLBEiABEigTQQ4wqFNIJkNCZAACZAACZAACZAACZAACZAA CZAACXQLgYOMCIGvC0dXIvE99VL6Rzc33sEMEd1SOcpJAiRAAiTQMQIc4dAx9CyYBEiABEiABEiA BEiABEiABEiABEiABDpHwIwOsC8EoU6npP+wj6ENNsLB7XRORJZMAiRAAiTQZQRocOiyC0ZxSYAE SIAESIAESIAESIAESIAESIAESKDdBDwdxYCt5ry0rh6tGx0JkAAJkAAJzIIADQ6zgMWoJEACJEAC JEACJEACJEACJEACJEACJLDcCNjIBoxucFMoeW6cQ1TN+P5yqzjrQwIkQAIk0HYCNDi0HSkzJAES IAESIAESIAESIAESIAESIAESIIEuI6BTKgm2qsPe1JGF0icBEiABEiCB6QnQ4DA9H54lARIgARIg ARIgARIgARIgARIgARIggWVPAGMaYuMaxNORDdjoSIAESIAESGA2BDKzicy4JEACJEACJEACJEAC JEACJEACJEACJEACy4eAWzha127w/YqEupmJIdT1G7DR8LB8rjVrQgIkQAKLQYAjHBaDMssgARIg ARIgARIgARIgARIgARIgARIggSVKAEYHG+GA/djS0XX7S1R8ikUCJEACJLCECHCEwxK6GBSFBEiA BEiABEiABEiABEiABEiABEiABDpBIK3TJ6WqUyjB+JDyUjrCIVUb8dAJmVgmCZAACZBA9xGgwWEx r5k/KuHOu0T2D2mpOZGBFeJtPkqkbzlehkmR++6WcO+BiPDAGvHWH7FAda2I7NklYbEskl+t5axa zKvKskiABEiABEiABEiABEiABEiABEig+wnoyAbBBgfDA3axcR0HEKEjARIgARJokcBy1HS3WPXF iebmQkRRv/iUBJ9+T4NCjxXvXd8Qb03WnXMLMvm6m24QtQuCXH1/9TkJ/u3tjaU95wpJnby1bQtP ufJu/XcJPjjF1nvtdeId3+/K5wJXjS8DQ0mABEiABEiABEiABEiABEiABEjACGBEQyXQNRx0wz4M DX7KcxvnVDJK9EmABEiABFohwDUcWqE03zi//VgTYwMyvlnC34+4EsL/fov4L98u/nm6vfavJRye b8EdSI+6NjM2QJw77l8EoXSkAx0JkAAJkAAJkAAJkAAJkAAJkAAJkMAsCNiQBksC04MzP1gAfRIg ARIgARKYkQANDjMimlsEt8iSDkUMgt0SXPyhRCY7JNx+ai0Mr3TfPyDhD/6jFiaT35Hgzn06mlEX a7IhjVNnl9xeEASurv5BddWOEeseMSXvZEUqFe01Mc96WXrf98XXsuMu0PwjeYJ5lxPPl/skQAIk QAIkQAIkQAIkQAIkQAIksNwI2Pd1Sr/TsZnzsH6D27y2zVJgedMnARIgARJYvgQ4pdICX9vwjv8W T5czqLn8WVK68ELxexEyKZlh7Y2/uk9Swbik8om+A+mpF30t/VLeuefyRF1fJMU3vdHVNZ0uS+ru OyS1aodaINpXL/fDKAjrZ6DS/GFw4HRKS7mxUDYSIAESIAESIAESIAESIAESIIGlQkC7OtZEifbr jznOoYaHOyRAAiRAAjMQoMFhBkCzPQ0FOBx63mPfLx6QaHWGKKfyM14sB4JREf0PhXi+t0e8YlFS OjdiTtc6zuyJ4uFvkM0KeusjXjodLeqw1JToUOzDlctlCUeGEnX9ExkOx0T0P+RPrT9SCoWMpJRN KoWeElP1cpnM4g/KBV83WqLi1xkcgkpJAi0D+aMcuKXGbRZVZVQSIAESIAESIAESIAESIAESIAES WHACnn5jY4ucpyaIlNsSXSMXXA4WQAIkQAIk0N0EaHBYoOvnet7rizrcE7MgaFl+X8Ep56GAhxIc CvNIKZ6W4l9cJZW7d6oBQsNWb5dwU07StZf9AgnahmzNyCJDibr297j6oZ6m8DcubSjWZeEMDzrC Ie7CqrEHZaI8Kzseh/skQAIkQAIkQAIkQAIkQAIkQAIkQAIRgfgIBrdyQyxAP63pSIAESIAESKBl AjQ4tIyqtYimUIciHFv57uskV0u6WiYyvoyPj0sul6spwmFwwAgBz9PLsWG7i53J6EgAHfmQz+ed QcKU+ktNeW4jDUqlkqRuvy42wmG1TGpdJyYmXD0LhYIb5QADC4wtSIe6zHYEgnHACBLHFyMrNM+e GmM16hQnpazyuFEV1ZEUxs38WHTukgAJkAAJkAAJkAAJkAAJkAAJkMAhTyAIfZ0CWbeqC3SEAzZz +J7mN7XRoE8CJEACJNCMwNIyOBR1nqGirmmQVvWxjgSYk/N1wYSxiWpSncwI+aTbVE2TD2r1vn7N t7mEUIxDIR6gLjW3TYordUgiRj4ket4nw5A27pLx4+dEFew6lECDtJ6q2J9Orrp0bTow2f20W5ii mus2mdS6oh5mVJixOFy7Sb12+H2TrjKeIZFj7CdZtbBYdLyd5PUa5efQ3mrtAfLOo83OUEeeJgES IAESIAESIAESIAESIAESIIEFJ6B6ClVWuGLw1wwMbn/BC2cBJEACJEACy4VAmzTxc8cR7v6thD/4 koTX/AfWUI65DSJH/5F4T3+ReA89anorur9fgp98WcLLvyqy++ZYHtXdDc8U7wlnivfkJ4tXaDwW EEpzue8HElz0NlXaa7rBF0jq9eerIrki4S8ulfCr/yoytLs+75PeIN5Z54q3egojFODhjV+UzBe/ Ium+Xinc9bNYml/J+s9dKGtVl+6lYK1QWdADX/fcK33qjxo0HiNj55wtYSEyTjj5EK/68pexnRJ+ /xIJr7w4wU0jbThNFejqx11xTLwz3i+pxx0RD53zvskRXP8FSV32dSn05iV99//E8vuVrPvMG2Vt Pqqnpwp+/9S3S/AHO5wBovbDZefPJbz62yLX/uhgvlJtA2e8TFInbI7lHXGADNFIBweudj7UUQ9m 6DA/OlmR4OfaTr79uYPbSeFYkUefI95zXiDeYKZpewsnd2l7/U8Jf/rlg+VFHk/4C/Ge+RxJrdCL TEcCJEACJEACJEACJEACJEACJEACS5wAvq2xYSzD1HiGKYPDEhef4pEACZAACSwxAlOa8g4IFv7o 3RJc9qkmJaty/7aLJcS24XxJvfWvxWs0ouDOb4n/3tc0yaMavPu7En4d27Hi/d2lktqhqzM3ckM7 VXmv5cLwMXSHhPtuF/nU0yTU4Ibu2vdIeO2nRV7/A/GO1BEP6tyL+jdfk9Tea8Xbe3Cq1NCv6l7g B8ewkL2SLp1d61Fgoc6/9asSfPCCuqC6g93/r+7QDsIHbeSHhczPR13ld1/Xev6q4aCK9IFf1xWQ un9ISjYEc/h68T7yfF3joi5K4qDaBj56sfhPvFjSZz/ZnXfl6p5jXf1hFE+oP5Vq56bC90r4gedq e0oYjSzCpBqqrnqThFf9QOSjn1bDlJ2I+Td+QYKPvDEWkNhFHldcIKFuwcuvktQj640kidg8JAES IAESIAESIAESIAESIAESIIElQQDf1zA2uA6Ruu+hXx8Wb8BW38dvSchLIUiABEiABJYugUU3OJiy OPihKsy/oiMSWnG7PyTB5c8Q7/TttZ7nLp9bPy/hh97eSg7VODer0vlR4r/u15I6drAuHXrCSyo+ NY8aKN7y3bo4jQ92S3jRqyX8sI400FEFLp9wpHHUWYUO6ExQB/eSDx74iUgjY8OKR+p0VL86eLRD vMz9I5F8Gubt/6WEl3xLwv5GmvV4ogb7pf0im8+U8IzHaH4jDY0NDVKJp4s7Y3olN7rh++8SmdbY kMjhqj8X//irxXvk+roTZnSoC8Qok6ohwnz/czp6IWlsKOyIRoIcuDWWfFSCks7plIv6ddj8lMH1 /ybyzxfF4lV3VxyjO0MiB+orE37yieK/8mpJPVxHaaizfNwB/5AACZAACZAACZAACZAACZAACZBA hwg4fYqWbd/LEAOGhiDUqZp1wz6+YYPqZt/xiEdHAiRAAiRAAjMRWHSDgxPowSsONjYMvkjKL3uF +IetEBl/QNI3/VgyX3+3eDbN0n3aQz08ckpxW/xdA2PDI8V/0flSOeFYCXrS4g3fJ5lff0My31Zl cdx9+P0i//rOeIh70SIAL9ZGLnzi+6Vy2hMkSD0o6Sv+RTLoCV9zV2rv+NslePKRLsR/xj9JcfOt Usl6kv7eq6X/AYu4Ukae/g8yUUhJoadHp1VKuYWNUWqgxo7sFW+W/M5aZEsU83V6p8teXy/jsW+V 0tnPE1/rqws5SOqGL0nu4vfWxQn+8msSDqiif8NRklJFPJy3Ww0ON/yH25/Tn2tXSvisR0vl6R8R f9vdMumXJfffr5Xemt59pQw/9QKprOh1dcxlCuId8ZCacQJi1Five5FUnvV88Xds1+umVhudfil1 //WS/bxOpRQfJfKNb4g88i9r1wpy2w+lZnVwP6Amfyfe1bfEopwqlde+QypHrI3CikOSueW/Jf2f b9P2psaiKqNaAm1rBxkbjnujVF50ptYvWhLcG7pVspe8QlJ31ACIfOJfDmpntTy5QwIkQAIkQAIk QAIkQAIkQAIkQAJLhYAaF5yhAfJgVINztZDqMT0SIAESIAESmJnAohkcTDGMOfflq++bUjZDxs2v lf2v+BOpqKLXmyzqSIMBkROeLakT/1D6vqNK+Kt/KuHWjeLrwsjpNBTrann/3gdrymsXIGfK2NtU mZ9SpXyoC09P6JZdJd7jVGm9dYus/sSbo2ju76W65sNfSXjyZncE2ZxcFR/LQSfcUTL58k/J2OE9 VeX2OpGnvV3y6bIM/D81nJi78kpdo2CLlLB+QGaDjB7TJ2Xdl60nqcHh2mqsLTJ8xHEy2pOR3t5e 19vfFlSGDIWt25saHHA+mLhOUtfFpgTK/7kMveSZUgkmJRip9uo/7AxJv2ivrPuijriouvDOkkw8 7RgtT+unMqGnQkoXWo768Fus2fqBVDSvYnq9+MeukeHhYclve6QaHHSUhXNHaF2Pl/KqfslkMtLf 3x8ZHvT6o3z/yNMkd/tRUv6jc2XyyA1SKpUkVKOFjJYdZ2+FTn913udl1dvPnrrOe34g/vDLJOyt 74nRSHLHqzrSIfi9GgxirnLWm2RojY7sGB2thmYke4yuF/K2p0q+qIaZnLazirZF+5H1o4/XsQpP +oDsP/OJ2vujpHnoBpfZJN7LLpOBi18gubvMSnKp+Ne+VuShq2rttpZnlIp/SYAESIAESIAESIAE SIAESIAESKDzBFTnoFMYRJvuo6uiag7cFu13XkRKQAIkQAIk0B0EFs3gYDjCSZ3O6Jp4b/OHy9jZ L5aSD0MBXmORgyI+DAsy+eyPSvmp45JbtcYpfd2URXKPpL73E4vq/IlX/I2Me6qs1ml7kI8zIOgZ GCiCDU+R4Wf8jwx+7ztTaX74IwmfcLY7rimnVQlfb3DYLuN//RkZW5dWZbgaStRZvv6p50qvGhwi 84eeKA676YpqeeEFjfqUp+qE+Y7CciB+zq9NbRTVBx0IPD0Xj4v3/JRRIJqqqf585dnPlXJVqe6M GyoGyqwc9RQpycUS9b3XvA8MOblxDsp/lBVsfLLI6VrbDGJBVvWmcaZ7d1HKahxY9wTxtWzIBSYH 13Xc1RXnbXPl6rHzTzxHyg9RWdWIFGDTcOQB35znbZOJxz5M+n/xGwtycWaStRZZd5BfaqJ+1Eig rd7KQ1zIAzlSqaz4fXmdWUvTaPuL3B2S+ub3q/vwniJjzzlV6x7V2eRFHp6XkZHnvUZWf+TNNYOa d821Epz4pFh67pIACZAACZAACZAACZAACZAACZDAEiOAj358bGOrKgCcmqC6D2nx3UtHAiRAAiRA AjMRWHCDg1NEqxSmlK7c+YuaItwJd9izZZ+MSnlU5wqMORgK8DJDunQ6I2Gx6JTA2WxWF/69Assl TLnVr5EHBielMlqvsJ6KoAMejjld+tTgUDMQ7PmxBMMvlrBPFf36QkUP+6BUlviKBpPPfJfcXxgX cbPsRBp5q4/nDUjvSpEBnb7fueGfiP/gS6XcE8lQVHlhBMjWacdV+a6GlbIaHSYnddqgmlI7MhSk SnEGvlRKRZUp7eI5A0xZleJamL3iSznPjSxA+ZALm3FepbaEnA4YcOfKEwJ5bHSIU47nj5Dw6Vtr inco3F3cOnkP/kFhebi4WgdwQ5moT0YNNlMOslScIh9hyB/yoR4oH2xw7Lirgt/OI6+4S6dy0l8L 8MXHddL1FZAH0jdzMAQgjst31Q7X5oxb7tILJf3nb5EDq/KOCeKhXUE21M9kRHiw69d1bSJ4+HNk f3lMKhMRLzM4mByZ/MOkR9ck79VlLpy75bc6MueJThbkF+dnaeiTAAmQAAmQAAmQAAmQAAmQAAmQ QCcJ4Ps6rQoHqCmwj+9nDzNMJPQWnZSRZZMACZAACXQHgQU3OBgGvLCwBUH9GILJhx8nFeshb5Fj vqUz3yl4dQqhuCuf+DApVhXm8fD4vp87Uib7RPrGLFQXB9ZyPYkQOEW9jo6Iu3I+45TpUBSjfDjb D4K8jG89Xg0ON1aToH7opR+9nKuB03rIE/nBRYaCeHTNT5Xm8XoHpbhCXwcn7Noj4cbNLk5dPhN3 Sr5qbHA5qlymgLd6mG+Kfpy3suJSWL4Is33zLb7lFU830348bS29GijSE8PiFaNpn0IdfJHec0cs q8iYo6K2pLiv5btymwCHjfgQuUbWXPwcGXzIa2T/yafL5Jopk4YVZmnDoX0W5Hxv7C4p7FSjF6b+ UueaBf5Ur6NkJiVdnWXJRchnHXu3zz8kQAIkQAIkQAIkQAIkQAIkQAIksBQJ6Detn+mVMNsvpZ41 4qkewc8Naoc/nfI6FXXdNF3AUhSfMpEACZAACSwdAotmcIBCG1vl3lvral/O5Vxvd/T8xssrp8fw ofCFbz3OkQhhUJB7v99Zl8fkel3AuBrfpgyKx8e5Uikl45u3St+tllZfnuNF8fPR1DjIN9A1HOIu LI2pIaDgerwjXzjUAQ499MtefJxFtKZBkNfpl7Q8yO1kcrHtT0rf07peQDZdqyfOIF6yZ7+Giq9l YLohN7pB4wRqEOmxrNTP/fhi6T/hzTLWM9XjH3FXXX1J1YwSRfb7C07u+I8DMzRgZIK7LloO5LD6 WTGWxq6PXQ/jYbLhOJWyMQRIrbM96o8ShGOzdJZfLd3EvdL3i+9J/vqfSObBu6zYJr5es0pZt4gt 5G3k4vXAyI4gWCvDL/kbOfySj9RFz17/T7Jet3DDc2Ti9BfLxHHbauftelSCch1z77aPyLrbatFm 3gkwoqWs131qpAoSGYeZM2AMEiABEiABEiABEiABEiABEiABEmg/AXyXYsP3eZDvl5Ftp+msApNS 3nyK6wCZ7dG1GHMF6c0PuG96i99+SZgjCZAACZDAciKwKAaHOsXwvnqDg84ZpIruHveCw0sOm73E kj7AI6/Ug/V5eBV0KdeVhNVZHlYmFOiREj2t1noXpfpnVHupo+zplNdTCm2Ty/LFcW1uI5djNCJB +967o7js8VK9ah1NgY9zyNPFj0eshutJd97VI3Os9sh/tKy9+ppqzKtl48fPl5Fn/pWMHLFZvOF7 ZO3/fEpW3HlzLKdjZd9DttSY2okwnJD07gckqwp5jKRIV9fQwBoYdU5/fMDBmIB/aTUeeLqfHtwk lf58Ld9I/nqDg9XVrgnqbC6V0vUyfvBO6b3i2xbUgh8xDoKZpiaK6mDXChmXNj5T7vqTvBz2hYsS 63ToZdz9X9J7qW75Z0nxNRdKeV2PqxfSp278ZQtyTRNlNOKLvOLyTJOCp0iABEiABEiABEiABEiA BEiABEhg0Qi473ntMBiq0SFI5cVXPQl0EX5Wv/kx/bB2nEQcOhIgARIgARJohUCdCr6VBLONA0U5 FK3oUY9e45Vi/bRAqXTBzZ/f09PjLOYY4WDK/fgLDWHIBz3WdcXeOjECfRkiHRTahUI0IgH7iI8e /Ch3YkIV7HXvx16pZFS26ogFyJfMFwrzfD7veujDhzzIE/mNj49LBkaHmENezhChYbYmgJsEsRYn JbmeXunrywjqa3Uyo0gaEybGHMrCtE/w3b7mXy4kDAJyowx893WigxwbusknXSATgznpU1nBpCbf zi/IwL99omGa1gJfJiPvPk8qKhvyBZ9sJi5/SrJ6LbJaT4xwwHmUjX244Jt/L/krfnRQUVjM2l97 uOi4AAnToeSu+2JstIayd+1Ip5PSfMCksZu60HbNELe86TS57dWP1lEuV8nGn31eckMP1icvfkfy 779F0m/+mkwORAtZFzcerWx/Vovnb3upDG1dKVldWwJ5e15UZ6xXgSm1Al1nQ6+WGmXUcOarYeSk Z0hJRzjklAUcrnWUbkrGWubcIQESIAESIAESIAESIAESIAESIIEFJoBvUjj4+E7Hhu/6XF71Mhmd jNiL9Cn4jkc4Oh46X/ct7QKLyOxJgARIgAS6mMCCGxyMjSnMS1tP0in0f2fBqpTVKZL0JWcvLyiS 7aVXixTbQT7FrY+Tgat/WwvNjY7rC3JdTaFtL0zERb7wPW9CCrt21tJgyiIof/VkLCyxq8pky8vk sql2mr1ko7KiYYmN4livf8iFvC0+9qvv/IQQ0QgIBIYjv5CNl//vQecbB6ySkSe9U+5/xGY35iLK P5LLxa+bDqpxDtOG5ksRmyo/y38qjf5wAXutlF1fxHFu748k/6N6Y4P/pH+W4Sc9RvxUdF3GxjCd lS+59M2y9VfXTmVb3QO3ubm8jO04Xe498VmSPXCTrLvyU1K4eaotidwmmU9/Q7zXnuGuja9DSOOu vOkJsvthm6S3t7fWNnAe0yZBXhjE7JriGq9Y0SsZlRVhc5c5LgH3SYAESIAESIAESIAESIAESIAE SKB9BPCtju/Vmt5DRzXAxQ0Nte/59hXLnEiABEiABJYpgQU3OJii1XrxVwrR1EfGs+eWWyVzwslu hAJebtYT3l5m8fSm7A9hcY+5wq03Su6Uo93L0NJDyW1pkW9x5D7pGYolks06PFCVwNpjvpFhADE9 HTaI/EwuxIMMThHuRlTEe/RrXjBgVB2UzXBh3bAKNayoLMjPRnIYF4TVr4FQzajquZf/zT+uTtiE wMfLnjNfLNl9v5Peu26SzAQWMe4Rf9Vmmdj6SNm3/Vgp6m+EvMoBWZA/fGyoR0UXgpqXW3M45lly 8iC/aKvPEb3/M/pDBWXieiKOcwfuqYsYPO4T8uCTH67Xy5eSTnMFJsa5fqHsaEQKzoMHnF3jugyr ByjP2hFGnFieSIP9cPBY2fv8j0r+rq/Luv/8p6kZsh64SUL/GS5OuVi/rkd2zy4tc2O0LoPWCfnC IT/IlXQmn/nJ8zwmARIgARIgARIgARIgARIgARIggU4QsO9l0xdABnzXYkYGOPumtrU28W1v4W6H f0iABEiABEigAYEFNzigTChbzfnZeoODd9MPpE9OrSqsIwVxpLyOTTkzPqqa8+iFh7yC/nU6PkFf fpbpzm9KYfI5UhmIRkrgpWll4oWI/fxN341NzaMJDztJJrU3fXzZZ8vOfK+qnLeXLHy8fKeOLWa9 j/PmVBVvu87HuaZbIm5dQj3I3H/HVFDvNhnaeIRkjjxODjx2SvFdKkUKe/S4R8lggc3KtAzCrWfK yEXPd4pz1Mkp4JWTcbN45lseZjyAot3VU9PAufMJ+a1MnDPn0twyNUURwssnHOe4xhX22G8oS7U8 y6+Znyw7+cMIeaMMbMVtz5OxYy+V/psfiLIrTkpYUgOCp1NYbThGYEawGqRv/74MVB4hxarNKy6j lYlMjJeFmR8VwL8kQAIkQAIkQAIkQAIkQAIkQAIksDQI4HsVzr73oR+AS37XukD+IQESIAESIIEZ CJgedYZosz8NRWxcGWvHlfVPlLG+eH4/kVXf/ZnrgR/18p+axggLC6euuEhSf/8oyf7XDU7BjXyC dY+XkRXxPG6Uwa98TzJVazvOIC9szg39XNZ/71vRfvXv2KmnSFCVMS5nXSRVoFs+ePHaVsu3PnKt vtPlZ1Mq4cUd39wLvt42UZe7q3dmynAj41+Qo778WRm44VrJ3XmjpO66ReSenZLZv1fSI0OSVy05 jALYbH0L+7GAvFx+qmzH2hXYYKDABoNFfEMYzlsYfnhYb/54PQ+WXysTM65YZVz6FZvsMPLvv9+t iYH1NlAOynQ/cO67Qrb87jd1cU32usDEAWRBXXG9cK1yB+6Slffukx5dRwFrfGDUCuIgL0yBNDl5 QMIHq8YG5JVLSzmMuIT5Y2S4Ttyfy+Yf/9qlNVngW9sw3iinLx3xhwzGPiEqD0mABEiABEiABEiA BEiABEiABEigIwTwXYwN36z2LYvvZXzP2oZjnEMci98RYVkoCZAACZBA1xBYlBEO9TQGZeixz5K+ K75TC05d9w/SWxmTyplniGxYrfPTTIrc/XMJPvMXIrujaOFgNMIhOuqTB059oQx+67JaHt7t/yiD n9wr/kvOcXk4ZXBlRNK/uUx6P39Rfd/73pfK/q11Vo9aPsmd5AsVx3AuvD7XWlKLE8WrBc97p3T8 6SI/m1r/Ir37a7LuO19rnm/uBCk/7IUy9vSnH/TDIK4sT+4nM8R5KMzh4qMQEG4uvm9h5sfPwZAQ rt5cN7Ik/90PyMq1b5L9G+yaFGXF9V+UzZdfalnM2ce1yFz9Jsn/9DbpW/PHMvzMF8rIlo2RQUNz DcNJGbzqX2Rgb6yI3GrxtW6QOwxzsu/kl8nKr/x7LULm5nfI0eVXy/2n/6GUV0dTKtk1zwzvkr7b fiorfvEpyYyeKGNvulj8gWjYKTKweLXMuEMCJEACJEACJEACJEACJEACJEACS4CAfa/a978dLwHR KAIJkAAJkEAXEVg0gwNeVNjw4io+6sUydtV3pK88Rcq7/p2S1c0cprGJO++BA07ZbfmUj3qhPLjx Mll9/1Qs7+5PSuZdnxQp7NApmDT8wK2xNQ8s3nGy96w/lgA94HWbrue5lWUpza+FTzMiweK2y4fy 2z/s+XLvo6+Uw6/5dWvZlm6Q7DVvl5XXXCL+331Jgi15p0RHYptOyEYrYBQDyogbFBAPdYUzTji2 eBaG8xYP+41cpLwP3WgJf8NjBWr6qZU4/ldWff75Mrj5DKn0lSR76w9rUxg1yquVMLtGGHmQym3U JLeJ7PuaDF6im6wV//AT1KgwLtnfX3OQ2Wj8qafJpI60gMzIx9/yx7L7iK/JhrunFgFJ3fHPslk3 yR0p/oYjdF6ofZLa/1vxsJRGzaUlV+iRIK9rWbA3SI0Kd0iABEiABEiABEiABEiABEiABJYOAfue x/czHL6F4SzcHfAPCZAACZAACbRIYMGmVIqXH39JRfvrZee5H3KLGsfjNd9/npSf+rDE6V7Z/cLP ytCWVYlwPZy81RkbDj5xiuw5573y4IopO0tctoPjRyHxOPH9ZPzG9oeJumiN49RFqR0grinqo8A9 MnhXvbEhHHy4FNc8XCorjpVK71YJ+hrwkNsl/YH3OcU65G+0wXjQypZMWxPW7YzXHcbravVwfvYo 2fOC8+ri4iC969uSTxgbKlicOuam4x+LVr/bW79uiMgDkr73Ssk1MDaUH3aR3Ld9pUs/VVZa9p7x Mdl71LH1+eKodKek79HFvO9PGhtwUkdsZCOuOKIjARIgARIgARIgARIgARIgARIgARIgARIgARIg geVMYErz3uZamrI27mMfPb3hioWj5Y5XfFY2/PQLsvJX353q0Z7Rfu+VUiTN4ClSOf3lUjr5Ybre QlmCcrRgM/KBclxkjfz+Of8uw7d9Xzb94ouS3f9glE7nzhc/Nnwid6KMP/oFsvtRj5GiLgScqqY3 BTsSIc8w0x+lr/71s9GC02bdj590inMY/2vyrpZAj+NKdsT3B7bo3xuwq67HLXaNvToFvPYecMfV hbFxHnEDXdTaHEYe9PzXBTIYW2qg9JC3yE2nPtzJDq6oj/OV1eC9P5ZVX/rgFFf5oqRuOl/84wZc fMzBiDJRbxvtYDJZmXEf8bBZOej54JhpHkjv9vsP0yTXV5NN1RUByBvO1oyY3Ppsuf0lm2TzNz8k PQf2u3N1f/qeKMNP/iu5e8uQ7PjEa6TgTmqe1XziccO0TcUUhQYqm8kEP3zKP4o/+AjJ/fDTknog PnfSVC7hiifJvlP/VPbvOLzGDHWyelYq/bLnGRfJ2L1XycaffkkKD+ycSpzcGzxZKic9W8qnPUky PdGC3bg2yA8bHQmQAAmQAAmQAAmQAAmQAAmQAAksVQL8bl2qV4ZykQAJkEB3EPBUgTul1V4Amd2c /VoEFgSGg8J5//79bpFgKIMjBXYoAxPD0pfKysBxahzYebdUMn2qrC9UDQtVg4Dmg/hYvOjuu++u LXSMl2FPT49kiqPSXxqTFUceL0GpKBP33COTvYMy2VNw5Tvls+aBRY+2bdsmw8PDNQU25IOsY8MP SqqoCvt1G2Ttpk0ujuUP36YgGhoakhUrVkhaw3bddrukBvolpYruvr4+p1RGWdhWrVoloweGZN+9 u8RTg0LfqkFXB8SDEhr4IfsDDzwgY2NjMjk8JKmKrpnQ2y+e9o5HPGw9hbT4b3yyZEeqFoeBc+Q3 L3ymTumTc+Vt377dlbd7926XLxaKzl33YVn/7f+KrqqumyCv+56UByODj10Xm0oJx3DNmgPqjs0U 8LgOcFZPyI68JtR44OTvUQ66+LJjpFws/vj4uIsH9igTW6Y4JIPjI5IJdJqrTEH8lRtltCfrzk1M TEjoVyRTLkm6MCADa1bW2gDKx3VDueMj+yVd0mmhcgUtNycDAwNOVnCAQ72w+SN6ffUahyOjEF4m 1EpUGlglI2oHwHm0DVwX+PHrjXJwHmE435PypTA6JIWycnNcdLqqvgHxV63V6byyLh7iWj6ov6V1 AvEPCZAACZAACZAACZAACZAACZAACSwVAvq9q7088WEcdeDU71nx0KtS/QzmrKYjARIgARIggdYI LNgIh2TxplxfuTKarsYMECWdKx8ut2KDbDziCKfM7d1+tNx3331SUqU0FNxIix75vTo1DhTJcFu2 bJGdO3c6owOU3lBMp9Rgse6YkySrCnq4yXyvDGk+oZ4rl6MRD1Deb9261SmtnTFgdFRMBqQJUznp WbdaNmr+UBBD3gMHDjhlM85DQY7yEG6ybNpxtNx///0uDs4hHdyaNWvUHpBTA4kuUqxjH/bt2+fi QHENJTmU0JAH8deu1XUFNO/x8ZwEelUyOrohpfFgXBkcHHT5Zf72Ugk++KcianQYfdQTBOQ8rdeO HTtqcZD3rl27nIyhjtBwTo0Nqb/9Tx2BERk4jCfi2kgH7M/krF7wsSEN6gu5kSc2GFWCXChpLduM ExYf+Vs8nIMDh3JuhYwOrHd5xsORt5MrpXFVma8Z1tKbLIiPOB4MFelocWuUAYdwyAaHa4zjiqd8 taywf507LhaLzk9X4+GaID2uG8owGey623FJ86ms2KjTgkXGBSszFVTEm1QjSjUf8MU5V4+qTJDH 5Mc+HQmQAAmQAAmQAAmQAAmQAAmQAAl0ioD7Xq3ot/HumyQsjklqdI8zNASDh+s3vuos1m3X7/Ho G7lTMrJcEiABEiCB7iEQaWYXS94bfiulH3zbKeuhjDcHQwKMAJWdd8nki84Q/567ZZOOLoAy2RTa GAUABX/p+9+S4nnnSk6VwTA6mIIaL0gcQ4E/9pYLZOyT/+R6169fv76mdEZvc5STGlMjw0vPlMqv fyn9/f11SneUgXxK1/6vTP6f54o3fMDlg/xN2QwjAOJNfOaTMvYPr5U+lX/z5s01JTzqBWNGVmUc f9W5Mv71y2TDBh0xoUYFc1BCQ9bwvl1SecnzxL/zdhcHLOBQHkYHIJ/i5d+XyXOfJaKK8pQaHWRg rfTedrOb+ufoo492cUbe8UYZ+fB73D5kCYLdsuaHXxOpGhsklZfg4k9Y8c6HDFB8w29lQ1zwtnQ4 jm/xcMvPCkyes3QWjvrGt3g6i2Np4MPFfYtjvqWPXzfsm+HAyrJ4ljfqFx+NYPU13+I1yxdtxNqJ lQGfjgRIgARIgARIgARIgARIgARIgASWLAH9lpWJIZGxfSJDuyTUTcZ1+uNJnRkC5+jmTQC6AV9Z TpR0do1ipW4bR9hkWSY0vJEGIdC0THfwJSAXtpf4vTTTfXRwC2LIQhFYsBEOpmStU7rqNEfZC86T YvgxWf/0P3IKZowewHRAMDZ4575A58bfI6Vzni+Vz35FDttyhNx7771OMY9e/sXvflNyr3+VeNob ffK8l0r+45+Vo446Su644w457LDDXC//4Te+Tga/8SXHa1h7z69+1flOAbx371458sgjnbGh8rKz JH/LDRK8/CVS+eQlMvAIXdtBe7pDUQwDRfHaaySr59JqmCif+0JJf+Yy6Vmx0k2vFI1YKMjEv/+r FD7wTrdmw2gYSN97PuoMBqiPGRuKr/lz6b3yvyXUbUxfDuv/+Cw3nRTKgqEj2PV7Cc89UzK77pXK y14olU9/SY7Q0R2YLgqGB8gy+aPvSe7vXikpnVIoOPMU8b7y08jo8NGXyqNWPEVSq1fLyFtfLwNf vsTVeaRSllUXvEUGbt0nXkHXIzj/P3RYgQ5/fOEfi3/kVldPKM9hNIHyHMr1ubj4dYWS33r0I1+c s2OUhc0U9eAHpT/iYXQDwsEdzvYtLvKFkQgOIwWQT9xHOPKyeCjXykI85GPODAFmDEDZ5hDPpj6C XMgDx8jX0mEfZdnUStiHs9ExVi7iYcMxnHFyB/xDAiRAAiRAAiRAAiRAAiRAAiRAAkuEAL5X4TAj RDih0xzf+UuRA2pouOvnuvalfgMf+xQJV2iHxjVH6Qd7pqY/iH9rL5GqdIUYPmw6alj49Z371VdF cZ1lAfoZXc0zl5FHbFulfqRTQMWidBWmI5dYO2d7afU+4vMq1mwWcXdu2uY5CIgXmX+EGha2bJPc 379K584PZMMznyPr1q2T8t13iqcjDtJjI3LXi/9Mtnz1UvHV+OB/5suyZes2p8Cd/O5/Sf71fy1l TT/2+FNl1Rc+IxOvPEcKn/icHHfccS6OGRv2PPF0yQ3tk5Uf/6DOza/TFZ33OlmtivlQRytAsZ/T 0QEP/tl5api4TNKvUKPDv14ia9XoAGfGhkAV1nte8pey8dJPS6VqdFixcpVTYhc/+3+dsWH8oY+Q yQ2bZM23vipj+jLuffeH3XoMqkkXGBsKamjY85yzpP+3v5Let/ytjGn+q9ToABaRseEFktq3V/b9 1Wtl5SWfktSfnSXli78oRxy1I6ozjA1/+wopaxlDJ/+BbLjsEgnV6CAwOrzzcl3jQdcNeOVzZeDK ayRYp6MVVAc+oKMugj23SOb9GvcROipi5IDImX8osvdBGX3JF+M/FgAAQABJREFUSyWl3KEQb4eL 37SmYDc/rnjHvsXFPupvowjM6GA/dJKyIRxpkS/OmR/PD3VBOOLCxznbrJ52bOnMt/IsXxxbOZYG x5DT5DajBfI2uRuVY+mtLItDnwRIgARIgARIgARIgARIgARIgASWCgH3Xau6gkDXxBRdGzM9odNK q45DShNqjZh0HfF0AdClIm5XyoGe+KVKIMVyIEPjuuaoGh6y0I9Ua4Pukmkfuppo+mqrZKRz0I6a GnFc1xtFD+74pWA6conrpdheGt9HuP8m9d6By+sU8CmnN7S7jP5CEFhwgwMaOzbXU7yvX/Ze9DFZ e8ErpfAPr5ZxDU8ff6Ib2ZAeHZEb/uZCGT7qGBnZeqSc8JF3iY9pj3SkQ+X630jPG14jxcO3yt1v eZ8uJj0oJZ3Xf8OlF8v4K85Wo8NnZfjtb3AjG3arseG2s/9KUtoD/biPv09WfewDMqLkev/0XClh BMVtt8i9r/57GTvtqTL06CfIlje/TlI6mqH48c+pwT7jRjbA2HDbm94rxc2Hi79xkxz2oX/UkQ4v cCMdSjo9EkY2jJ14ktzxt28RP5MV9M9f980vO4NC7zveL5NqbOj5yeWy56xz5PdqcEif8Xw5+r0X OqPDREqtkI96nAjy2/eA3Pumd8vYQx4uD2qdt7/rjZHRQUc6+HfdLgUdDVJav1FlebeM6yLME3q1 tv3nlNEhfM1Z4lWNDeExGffSSd1UkdR3rlCZXiLeGz6kIxvOcMaGXa88X8ZOeZKsqo4IwPUwZTsa 1lyV4jAc2MMNeeLYHPI3w4KFoxzbR3yMeHBtQ/eRjynpTSaT0QwJNvLA5MUx0uM8nOWBfOFwzsKw j7JxjM2cyYSyLH8rD3EQF+eQ3uTFCAeEIwzO5IaPuIgH3/Ix+Uxul4h/SIAESIAESIAESIAESIAE SIAESKBDBOx72XWw01EO2VJZ14mMOtthOocS9jVMh/u7mSbwjYtvWvu+7ZDYXVOs6R3gF8u+3Hjv ARkeL8tde0elohaEjQM5ZRnNzIC/no4iCXzPdXisqIoDvJ3eIYxmhvADX0c7ROuKGgSm03VFyUXY XqI7otH9gOfVeNGXK2/aq4a7UB5/tE5Tn9eZTbLa4dgZHqJ70O4p+u0hMKUdbk9+DXOxhyxOVtRY cN+7/0k2vuHVzoiA45Qu6nzj+W+W0aOOFVjNR3ccLzfr8bEfeqcEZz9Peg4MSfEwNTa89QNS6dfF gzXO3ufqSAH9hxEIpWecIoN77pc9f/CHcsfZL3fTHIX6YL75Va+X4z72PlmpRofSlz6v0zXtlXte dYEcOPlJklZFcXH9Jtn5jg/L1re8TrLnnYOnu5ixYWKjrsmg5Rx47BNFzr9QjQ5qAHn+06Sg5WBk w51/91Zd3FmNDfriveelr9SkKVmrRofyL34qPbvvc8aGPWf+H305l6Tc0yu3v+Ef5aj3XCg9F54v /qo1khoZdsaG0RMe5vIobT9GbnvDu+To97zJGSOyOtqjtE6NDRe+R0oDK7SnQUl2PeW5+uJJydGX fU4qT3usZA6MqEFEFe5HqUJcZUfFKydq3jf7klajQ/lnT5XM/n1yx7nnycRpT5Os1gfXIn49Gl6w OQTaDw9TwNuxKeItS1O4myLe5LEpjuw80sPF88G+HcNHWju2cq08ywflIB7OI8zKS8Y3w4jJZfmY 3AhHWUhnZSIvm1rJyrN8EMfi2TnLiz4JkAAJkAAJkAAJkAAJkAAJkAAJLBUC+M4Ndapot1aD7jul Skw49z2NcLo5E8AIBUyjZFMpYWxDPqOdNKszJ+k8DTqFtE73rEpQvRhOd2GFQfeg2gwXP9JlRHoO nEe6TIbpyGWqUy3by8H3A9ZOOaDGPr2VpKgzmOT0XtMJ1e0Wo78ABFSnDtztd5YtFMm48TH3PfZH R0edkrZ4/32y7R1/L7m9u+W2C97uRjbEpYCytk/XWdjx/rdVe/m/R4LBFfEo7gG8XpX8m7/w7/KA jli4+8/+2lmrEMnKT6tB4OiPvksGf3ed7HzV38n+J5zmFM+mBIafu3+XHPmOC8RTOW+/8CKZ3HSY KwfnkA/8lb+8WrZ+9N0yevzD5M4L3iphTqcz0nPRQy1SjB/+mY/L2h9+W+5/wUtk9/P/tCaDyZIZ H3VGh8Lv75G7Xv8ON7IB6a0M+IXbbpId732zlFetllvfFBkbEO7mVKz6my//ruz48udl92NPkRvP foV41d79BsfzK3LC//2orNGpnG5TY8i+U09361tgXYOVK1e6dRCwRgQYQ5EOZzwsj1Z9q5sp3u3Y 8rP8k/nFRwggjXG0dPCx4ZztIw/LD7LDWTrz4+lx3uSx8izMwuN5Y99GX1j+iA9n+bueHyoTHPKw fFyA/kE6yxN+Ul6LR58ESIAESIAESIAESIAESIAESIAEOkHAvmNNXzOhnUDD0Qck+9NPSGr4PunZ 9Wv9uM3IyPanqB5mk3iP+VPxele6tRjboUfoRJ07UaZxhj5nbLIiP75xr1sYOu2p8UAVnsevz0e9 rKt6hKzOyJDW/YH+HudDpwAHfURFdVujOhUTFKfIzxziMB25oN2wvUS6zeT9gPtwSI0Nn71yp7t/ Xvj4rbKqLycr+nStWOWW1P/ZvUV/fgQWzeCAhZLxMhsZ0V75+qDEC80b2i9pVfaPb99xkOLWbpS+ O25Rg8Mm8dXYYGFWZXt491/7Szlw4iPQsuxUXX6ePowHb7/ZTYOECMgnmVfmvt+7IYKlw7bU8kju 9F1/nYwdfawzNuAcykc+Jgf2+3/9SxnV9SAsfztneWHqqLwuEj153ENckJ2Hb/uFO26V8uo1Ulmx qhbHDA5YpBjxVt1wnew/7qE6r+LBdUEiGB1W3nKjjJ/0aKf0xiLVMDhgQWso1Xt6etpqcDCFvNXB 6t/sxrX4SUOFqzDk13rBJX3Lz8KtPMvPws1Pnrd4LvPYH8vXDASW3qJYPiZvs3wsneWX9C0/+iRA AiRAAiRAAiRAAiRAAiRAAiTQCQL2fWsGh/Hx8cjgcNXHncGh9/7rJFSDw2jV4BA++sWSUoNDu/QI nahzJ8o0ztDjjKrB4fLf7dGpXSpSyOri0GpweOjmHh21EE3LDF0CdDbQIdgUzaZPgP4BG/RqyDNu cEC9EB/pmW7KEEMubC92X+De2D9Wkk9dcbdbC+Wsx2+W1f15WT0Aw150/3Xi+bDcy1ywKZXiilfs 40EJZS4uOJS27sW2Zq0EqlgvKGXEsXh4gOJhCr9y/EMlrecy1fPWAx15WLziY06Wnup5ywcXzs7D L6kRIKdxIIOVgziQA+dl6zbnI46dh49zlk9Jlfd2HmlxHs7iwC897hTJV/PA+XgeLp7Wv6J1zlbP gQviWH3di0SNERh3gM1eMFZfjBRBnNGHP1oykDvhTKaUrm0woXXOa3lgVigU3MsLLzAwMA4WP5FN y4eWHvnBoY5wFu4OGvyx+Fa/VtMl87XjpJ8s0sqx8GblWT4Wz3wLN9/CLR87Tp5PHls8+iRAAiRA AiRAAiRAAiRAAiRAAiTQSQL4nsUGfUOgupG8TquUwtRKpmvAPEC6QQehf2q6j07K3E1l1+l53NoL WH8BG3RAKWc40Mmbna4mXi/oEeaiS2C6OMWpfXKZYhHfW+5ccP+hjniemXHV1+cZRglhQ5haHGr3 GuLStY/AghkckiJC4YuLbIpm+AhzLy6NbOGmGHYXXsOT5y2e5Y8XI5w1jOR5y8fim8HCyrEXKfJB Hpbe4ln5lk+zckwOi2/prRw7b76FJ+NZOSavxYOPvGGwgW9yW7ykj/iQFfmjTjA0YB/hlmcyTSeP jetiydCu8tqVz2LVm+WQAAmQAAmQAAmQAAmQAAmQAAmQQEMCMDSYsUF9dCd0XQotrGEiBs5EAPqb AMabqsM+wqBPMN2N7cf1NQizeNjHBmd+NbtaPvFjpos4keeh2V7i9wh0qKarxT2CewMb3cISWHCD g93cpuzGRYXSHeHYx0VHQ8B5+NYooHiPNwLEt3hAgjwsL/iW1vJBHITH80EcKN/NRxw7b40vWQ7C 4/m0q5x4PiZrvByEmZzwTQ4MxcO++ZYWPpzlCx91yetIB/hYswF1t+uAsIVwKHc2brbxm+U9Uz4z nW+WbzK8Xfkk8+UxCZAACZAACZAACZAACZAACZAACXSCAHQRqvhwvX6xcDS+6jF9c6B6A2xQzbk4 nRCuC8tMsoL+ynRYOAe9AlQn6BiazUYdRKGjsSmVTG9lehvToUG/g/TQ68SdxTef6SI6xsN8cjk0 uNh1ho/7xbbI0BfpgSuVtNOt6mCj2rON+r74U2X++/VPqfnn1zQHXDhcbLvwuOFx0e0YD1bEQRic 7ePBCmeGBIsP3+LiPOJjs3gIs/Pwbd/KQVw4K8dGFlh6K8fktPTtKif5wDM5rBwnnP6BvHBWB/hm HMG+8XGR9A/kNhnh2wsL4bYhnI4ESIAESIAESIAESIAESIAESIAESIAEpgg400J0CD2K7jkNje7T zY+AThUvWZ2+BVteNXG5TKS7gZ7G9EPmm07HSjQdDuKabsjOwUe4pbG4CLd9ppvq3Ewuh0Z7iV9n 3DN4kPXk1ICq+6odVaMq9KJ8roHTQrkFNzjYAw4PTjgc42JjaiB30as1Q7idqwa586ZctweonbO4 WJvAHMLgzLf8zbdzltZF1j84P1M5sCSbs/zNt/zj+diLws4hbfx8s/rEy0EaKwP7cGbRjlvHozP1 f5EOGwwoKMsMKfDhkvnWp+YRCZAACZAACZAACZAACZAACZAACZDAoUIA+gqMZcBmeoyUp3oc3XQF B7o5EABHY5lRQ8O2tXkpVzJqbNBRDWlP+nryktV96MegtzE9Evbjzo6tw6npdSyO6XcsnoXbMdOR p7UJ+Mu9vaCOuO+g57X7r5BNyWOO7HcmhsGCLsyOR1tVh4z4dO0nsOAGh6TIuKDYcNHjF9f27YFo BgB7kFp8O2/H1nisHDtvx8jH8kaY7Vu8dpaD/E1eK2u+5Zi8yA91Rf7xOsf3EcecpUN87Ntm5+mT AAmQAAmQAAmQAAmQAAmQAAmQAAkc2gRqOgXtv+n0J6p3QOdf9P01PQL7Ac+/jWCEQ49qOWFoyOkG A4TxhQ9n+qNmpVm85Plm4Rav2flm4UwXXQ/jkPSbcWsWbumbnW8WznRzuw7gBqam78V9lU4FMtiT VX2q6m3V2OBsenywWRNbEH/RDA724LQbyXyrlZ23Y/PjDcTC4r6dt7BkPjOdt3QWL5k+ed6Ok/Es fbPzFm7xkumT5+04Gc/S21RLdmzxjWvSt3ws3OLTJwESIAESIAESIAESIAESIAESIAESODQJxHUE GN3ghVPjGYJQlXa6IU483qFJava1NmY248fa/lxk1FE9KnQ0+Vy2ttYm4prepllJlk+z883Cma4x GXJZnlzMiIr7CfdVuVxWI4Mnh62M1kDpyUf3XUqtgDhv92ljGgydK4FFMzgkBWz1gs4Ub77nTa75 5jNT+oUqp9kLyeQx38qnTwIkQAIkQAIkQAIkQAIkQAIkQAIkQAIgYMo59CWO76sWrgaIeoUaijnt gB90N1B6hlUlqIWR7ZyQMhEJtEzA7jWsmwIXGRqmZsBpOSNGnBWBRTc42MPU/JmknSnefM9b+fPN Z6b0i12OlUefBEiABEiABEiABEiABEiABEiABEiABGYiEGLOc91qDmtxVtfjrIVxZ0YCph+Cj816 WtuanMggHt6sI+mMBTECCZDAQQTs/sN9BSOqrSFs4RjZgn3zD8qAAW0hsOgGh7ZIzUwWgEBF5MH9 mq82iRWr9EfFAhTBLEmABEiABEiABEiABEiABEiABEiABJYgAR3RgAnOsekiDvHpzeP7S1DwJS8S lJvAWvajhWxTqbTrZQ21iylBl3wlKCAJdCEBu78CvQGLlWgR9x69/9J6T9ItLAEaHBaW75LPPRoy OSnhBx4i4W0m7pnifex94unbz25OO0OfBEiABEiABEiABEiABEiABEiABEhgeREIde0GG9CAfTjt m+82Ghzmdq1Nn4Ke1BUdOXLnvqKUK4FkM57ksynZvm5AmUfzzM+tBKYiARJoRsBGDsGfKAXy8ztH dE2aUB6zfbX0FVKSU6MD7lG7T5vlw/C5EaDBYW7cllkqHd0wEq/S3SKTetwXD+M+CZAACZAACZAA CZAACZAACZAACZDA8iRQP8LBDXFAL2BstDjM+5Jr32oZL/pSLPvSq8pOYIXyk44ESGBhCcCggDvt wHhZF20PpaL3nTOpIlDvQ7qFIUCDw8JwXfK52mJQgZufUedp1Btt6j7DMCPM3YjFVKJFVWjxW/KX lAKSAAmQAAmQAAmQAAmQAAmQAAmQwKwJOP0AlHCBLx425KBKOh9Kcd3SsYWO2SN41nhVv6JKTh3Z sG+0qD2tfRkoZbSHdSi+Kj9NNzP7XJmCBEhgOgJ2b8EvVXy5d9+43nOBjE+UpaAji8Kcm9Rsuix4 bh4EaHCYB7zlkBQ33tRwSauRhsEQEU6ZIOwMfRIgARIgARIgARIgARIgARIgARIggeVHABqAei3A wSHLr9YLXyPoXQLt0QkDA7ay70vFjzp3LnzpLIEEDm0Ckd4TRofoHsS9iC35tDu0KbW/9jQ4tJ9p V+RoN5yvL7ow9LXbgo5mqEmuN2GlImEl+qmBHgyYc5COBEiABEiABEiABEiABEiABEiABEhgmRJA x0M3C0I0i1LKUy2Bbpz4Z27XG3oXOMwsgc2HwlN7WgeqiXPHfkVUJcOZJeaGl6lIoCEBu+/iek/o PqP7EMa/aKuo3lOHb9XWcODMLg1xzjlwSsc85yyYsJsJ4AbETVfvNKx6M9aH84gESIAESIAESIAE SIAESIAESIAESGC5EdB5DtzoBnQ7xD4c/tLY4FDM+Y8pP9GbOlKAIqv4vjKuGibmXAgTkgAJNCUQ GRqm9J7RfcgnW1NgbTrBEQ5tAtkt2diLDDcc9kulklrUi5LVey9bq4QvflkXU6mk3cgGrOPAtRxq cLhDAiRAAiRAAiRAAiRAAiRAAiRAAl1P4GDFW8LEkNKZDrDRzYqA6V2ML3pSVypYsBa9rDGdkrjN FKEWf1aFMDIJkMC0BEzvidEN0ewuMO6JlFXfWS6n9F7MujVq7P7jCIdpcc76JA0Os0bWQoLiqEix rBFVhd/Xr0N0WkjTKIo/KTI2UT2DvAqa1zwuGfIbHY/yy/RKmJ0a4JK07WENhzCcOt9IvFpYrb4a ku6J5KydbHEnXte85pHXutKRAAmQAAmQAAmQAAmQAAmQAAmQAAksOAEb2WAjHbBotJkfUrpPNz8C IJjV6Vsq6VCgisnoZgaJ+eXM1CRAAs0I1IwJOqqokPV0OiVMJ6/TKOk/jt9qRq094fPQXrdHgG7L xTXW+34gwUVvE4FOfPAFknr9+apo1zUPfnGphF/9V5Gh3fXVOukN4p11rnirM7W5weojTB2FlQcl vOorEl7+VZHdN0+dsL0NzxTvCWeK9+Qnq1L+/7N3HgCOVdX/P+nJtO27NIFdylIVkF0EpAs/G/AX EGyoiAI2pNh7R3+IgoIIKqL8AEURQXoXQQUFKStLk6WJwLJ1WpKXl/zP976c5CU7szOTySzJzvcu N/e+W8699/Pey5BzbtGFeCP84Xf9fVz7e+XPRZ74h0lxr1Zs1kGSOOijktt2pkRrLA66ryD2EtTt zIb7A1jKPi+lGy+V0l2/W3O86fkiu39QIm86RKJTqusmKo1rJHjpwex3UrrmV2uOFTJ2fa9EDjlC Ij0jcwvLZpwESIAESIAESIAESIAESIAESIAESGBsBCI68RC+6qCUU9Wc6h1G0j1U6zBmBEyfgjAW jci82RnxdHlDMh5TH5VYRM07mhfoR6wWQxIggWYSwPuVikdkwdwuZ0TtSUclqRPD+Z3WTMpryqLB YU0mI6esfEYkq0YFXTAgK5+U0rJ/i/zsIClp8pDu/tOkdP8FIp+5USLzuocs4hKXXC3F75w4fD5y XrxOSn+Any+RUy+WyNbT11JeFfq/+ZCUbvvT0GWW3ijJi2+Uqdu8Twr5uiJYZzScW/xrKZ75+eFy lYsaSm77lLb7KSkef6dEd9loiLJLpfS9Q6X0RJ1xxkpCxp1fUOPLjSJnXSARLngwMgxJgARIgARI gARIgARIgARIgARIYEIJQCNghoa1aAcmtA/rk3C1N+gM66hb2ZCMRSSungrP9ekOcyytSgDvGQx+ PZmEGvd0dRF2itMVRjygZmLvGBDTjYKAWZ3dHnvRsMVflf9fXouxoSL7RSl99+NSHCy6Q5pNnoX+ IxeKP5KxoSILkUeldMau4j+62smzLJPn+nnlJ4Y3NlgFDaOP/FKS/RqpLEYIDpKGDHMm1190nvhD GRumbC0yZbYVr4Sl814v/v0vVKz2FTm/eu+axob0VipDfY3rk2Ler9SvyeIFCZAACZAACZAACZAA CZAACZAACZDAuAjY73QpqQ4AvuxwjHRwlLSlMBwLATPY4EzMuG6nNKMzIbO6EjIlE5PudMylIc/K jUU2y5IACYxMwIx6MPBtPDWlPimdqYSueIir0aG6esvKjSyRJUZLgCscRkuqXA5/iOGwsHAoV3r9 6VLYZ3cpRpdL7LazJY4Z+hV3h87Yf1IiB8yrpLhIbpHID75emya7iP+OU8XbZispdeiL0PuCxO69 QuLX/rS23PdPFzn3a7VpelVapu1ee11t+pRDxTvqOPFfNU1K/3lAEld9WeLPL3VlSmpsiODYiTpn 43XJ6OePvltbYpvPS+Gow6UwJenSIysfl8T/nSDRJ1+qljv3bJGffKN6rXIif3msei17SeETX5fC ZjODtNxKiT92i8Qu/apEsr3YfylUllESIAESIAESIAESIAESIAESIAESIIFmEsBvf+g54J0eQH+G VxTh/Ek+LtTgGBgd1IDjplYHbM3YMC7hrEwCJLBWAvb+YRszuMDQELyDa63IzHERoMFhlPjsdPNC QQ820D33KosBKvW3kOzxP5P+TTLBH2eZJXLQ1yQV86T7T7dVSskdfxJv71dJXK1pcO4P+fVn1Bkw jpDeL31Scgns5afbIg14EolPlcjrPiDxuZvJ1HO+WJUnF0vxz8eK7LVpVZ7G/Bt/VntWdff7ZeWp x4v2Xics6AqGOTtK6YO/l/itX5OZd948pLHBGkEfcaK73HKuHq1SdaWdvicrDn+9HrqS18Oo1cPF N5TIMb+V7p8fIcmnAmOGyCXi//NEKe2ohg6VVXr6AQk/eIUjvyArZ+ieSX19gQzNTWz9Vol89UBJ 5dTan1QG2nF8ScRiuvZJHeJ0JEACJEACJEACJEACJEACJEACJEAC4yfgfmHrmQKiPohHxNff3UX8 Dufv7zEBNn0FQngzLCSTybK+KNBpWDpCOhIggeYQsPcP7xV0kPbeWTr0iohb2JxWKaWeAL/V6omM cA3Dg+9XlxgGxefJwMculN6NUk4xjzKe5zk/sNf7RVX1VZdb7f54mwGjhIMfrrujmq+x7EdOlmw8 2HoJBg4o+xHCe7P3l1X/86aa8pGbb6nZpqlYfFqid9xXU2bg6GMkp3LQL5OFcNVun5TnX18rT00S rq4zDujLCVcsPiGRP97g4sHH/tJ/yF7i61gxFpOJvvp+XHr/nxoYQqUj994fGBtgcMi+HMpR2Wp9 CLiirl+R5/sJ8Ts73HVNBV6QAAmQAAmQAAmQAAmQAAmQAAmQAAk0lwB+/5d1APg9r+py9y/82765 DU4OaYGiMyKeX5J8QfUnRTXmlIJJlKYEnRwkOEoSWLcE7P0q6vda1ivJYF51mO4LjZOYJ/pOhCea T3RbbSkfSnc4U4Tn83k9U8CT8BnG2Td9S15ID4i43X+C8lYvGu2WzqkiXSvLw1/1Z/FXflAiU4I1 EsXHb5VUOcsF0z4uy3qykl09xP5GWgAvS2SrA6T7huuqqw1eul2Kq98tpc7ghSku022NwjK7jpPl nTnJ9wdnM6BvkIMQ4xl89Xsk88B1Mk37H7jq/06gDIwBxefvr1mVUHzNIbLC65fCINZMBAaDoG7w GU+9WjLTRDpWlFMfe0jyud2dEaI4dUsny17v5CVflNixX5ZV01IVC2MikXCzAGBxhIdBA9ZJs/zb l0a4TcZJgARIgARIgARIgARIgARIgARIgAQaIxDR8xvgzUVVb6DKA7tkOEYCprdwOg3VqyxZlhNP DQ7Y2iWlB0jPndWl+o7gDIcximZxEiCBEQiY/hBh1ivKPU/1qrGhJAu3mC4dqagkoV8t+xFEMbsB AjQ4jBGaU74H5rBKTS8VdwYJU+Ijw+K+n5b+zbZVg8PicnlV4Oss/mgp7soU/WxFDiLe9jtIXvPN YBHONEOBJOdKtkuV+bYDkejByvrHq6RWcudefNitorC6xa22l2ydTFdeX7SKQcEKW6h5cMh3fuUy y3FhpP8pST+jJ7xnc+7aFceH/c9IPCux8i5LrkAyYASppZ7NBOaU4NQH5P5DZvz8EOnZ/kRZsccB kp2hg6MjARIgARIgARIgARIgARIgARIgARJYNwRgW9CWnFahrFpwv+/tN/666cV624pqVmQg50vO 86VTD4wGVig/6UiABCaWAPSzUOOuHvRUd1oST70zq+L1s++6ie3CpJROg8Mob7sp5oMtg6oWf1Qv 5fvV4JB2s+/tbAYo9OHc1kqR8BoGXT7n5aUU6Oml9OxTknElg4/sBjMqs/nxUmCmPxxm+KMPQRiX gY02lY7HdDsm53SbpwG1lMcD61ypqJa6cg6C3KyeikHE9igLDCc6e2GY/3mw8aI9lPGLXk0/I0+c KbOeCDUyUlQPYfCwOkTLFYuzZNW7T5JXXXxmTa3Ev34os9WX5hwigwe8U7Lbzq30DxZJ9GO4/tYI 4gUJkAAJkAAJkAAJkAAJkAAJkAAJkMCYCBR1++hIaAvpYiSmZzjorgP8LT4mjvWFA11OUZb15XRL F1+y+bgaHXRSpio+kUdHAiTQfAL2biHM61m8zywdcNvCD6jhIa0ri0pJnBFLi0PzyQcSeYbDKMja Q4qitjKgtlr1DwQU46bUh3LcKcprHuBghUNF4b/88RpRUT/YoqhSt/yHHYYMyA2cbjFkUZegeyFl PfeHyrZ+Cgv1ujoqynrIMA+ZpsQf7hXD2OGji/8eFjn2eG9OV2AE5z24l32DN8qSoz7tVjrUC4u8 eJV0XPJOmf7Nb0hSlxzSyFBPiNckQAIkQAIkQAIkQAIkQAIkQAIk0BwC7je3Ghb8jml6juIMyWVm Sb5jlpQSOj0yoRtKRwLVEX+bN8YbOpCiblUFAwO8pztQFEKGncakshYJkMBoCJhe09N3Dueo4F2E p7FhNPQaL8MVDqNgF/6jag9quFpEjQypVEqgwEeI8igH5f/AwIDEomF1vqbj4OZ8MFs/pg972BX1 dAMYKTo7O12IFQ6Qh5UGMFIgDrkRlV91Hbq6QZfm5corFnRPwLDLPPOipLaa4QwN1j/kQx6c73sq 10WrH/iDqPk23tycLaVb/lbJ9zd/n6zcdKokoknXp0j5f0B8NZiU8PJ6Guo/sIn4ymP7/XX5YM6N yeR6G+4jj330tdL9xF2ywd3/J8mVyyvyXSR3jaT+9zEpfu0qiWSCU+RrC/CKBEiABEiABEiABEiA BEiABEiABEigEQLQL5gvpqfIf3c6VvUVOfGzWf0tH5PM9NmSSGUkHgv2ULCyjbQ1GetAnwIHHQi8 r7oaX2daF1UT565Vf6LqHacnQTnwpSMBEhgfAXvvTJ8Z7FSj7517D2FwCDz0rKqwrbx3fP/Gx72+ Ng0O9USGuLaHFVnheKWoKtthJIC3VQN4oOGGemAx098efO9VC0TuXlQRlegbUDk9ThZWIkCeOchE G6VSn2T++6wla2jL8HRfMpWtH6E87UNB/2eh/D8S1j9XTksF8vUFq61RubJ+Fjtqz1XwNtxdXnz1 htLR0eH6hH7BYQsp9DOnxgXURbsYhytXkRqOpKRPD8F+bse3SGLVIzLrjp9J+tGHQgUel+hP/yCl zx0eSmOUBEiABEiABEiABEiABEiABEiABEhgvAQqOgs1MBQ7ZqhCvCAFPZPRpae6dYWDToLU3/uV cuNtcJLVr+qQgompgQ0iHA/0TOQ7yR4MDnedEQgMDVU9qek511kHJmlDVW32JAUw1mG7PwJ1VudI LFjZAOW9rSAwC1oymVSFe3jnKli09TwDL0grlMJ5IunHH5XUwk0lqBdzIdqEPLwksMAVBl6UzKpw zzeUfMRzMp2SXy3mYRd/8QVJaz+i5f4FRotgBUMgU1dM1FocKtXRHmR6erhR2CVeel7TN3AGBsiz syasn+Gy4TiMDyiPEONC+5CPeqWe+bL0sLMk9dQfZNalP6waQZYudmXCchgnARIgARIgARIgARIg ARIgARIgARJonIBNHIQeA7/RMYHQ6QjKOzekdYIh0k0/gd/wTifSeJOToiZ0HHAI4Z0epwC20Otg OyU9p1M9WJtOZFKAKQ8y4FOQFUtXSEF3+UhPmybdqp3ks/XKPAXr6/2wd8v0s3gt4d1Zu6qTLRYT ekZN8J6CPJ+/5j5/tdru5sqeNNIiZeU5Hk78wYZH3K41uobDC42H3+/SfRHDuaps78hW5ZgsU9Tj OvXwNRIcJV2uuOFrJBc608HfcMfasxH+e7ukvPIWTtpXk2n9Sy26SKbUGDDCHQri3pytg1Pcy1mx f98g3YVqzzGe4EsqeElrx19dpmnpGA+8XRsPMMnPfZv0z59Z7UQuq3+Nq/KrGYyRAAmQAAmQAAmQ AAmQAAmQAAmQAAk0SsB+k0NPgEmU+J2OCYXwSDOPcnSNEwC9hE5GdV41cXH1YT1K45LbsWZWLj8h KTPmzJE5c2bIlOQp8u/gONN2HMx60Of1935U9JQ6pTmdiEgmqfpW/adaSr1vVZ3menATW24INDg0 5ZZE3B9m++NsyvRgu6KhGgiU5+6Py8yF0js1XOZfMuX31+seiYFCPvzH3f2PwKq/y7SrrwxXkN49 dnd7kNkfq1JiM+kP6etF7pOe6/9RUe5DjvUx8a9fyIw/XFQjT00GlWuTKen5snrDSrJG7paNbv9n 5Q+klavI1f85wSyIdDotnbGEW/mBWRO4zvQ9K9P+s1w6Mhl3batCIANbMQ0OrpTSiperjaX08Cr9 B2OEWSirmYyRAAmQAAmQAAmQAAmQAAmQAAmQAAmMlkDYyACdA4wL+P3e1dUlPT09FY9rnC+J3/lh 3cRo25ns5UxPghBne86bnZGtN8jI3Fmd8qrpGYlFQrohLbO+O9Pp+H5Olr4QHu2T8mJfcG4pyrSK Q1+e++tPZL/yhOJI5NVy1s1PVfRgrdLPRvvRbvej0XHi/UvFI7JgbpcsnNctPemoJHXSNr4H6SaO AA0OTWJrf7BNnD24Lj2kwLd8C0uljCzb60i7dGFkyWmSOed8ib68spru90n0gUtk+hknqi0u5Dre J0s36QglINopK1/9xpq0yD9PkinX3yWRXDl54FmJ/+YEmfKb82vKDX+RkuV7HFOTHX/067LlVddL R2++YszA/4Tgf0ZS/S/K9Ad+L6869yDZ5PunSiZX3UYp+dcvSfdFb5fZZ5+hhoeXJKmzKKr8ctJz 54+k+6VQU0ndR7K8pVQolVESIAESIAESIAESIAESIAESIAESIIFxELDf4vZbHr/nw5MpkW5lxtHM pK+q9gadYR3VGdZ6GLfOtIYCFFwno4MCOFFjXylJvEUNLs/e8Ru5vXKTHpI/3Pt85Wp9ibTT/WiE Od4zGPx6Mgk1NiR0gjcOaldJNc9gI5JZZ20EeIbD2uiMMm+4P76V9Lq/IXiZw66w5ZGyfIPLZHrY wrvkHEl86xz9i7SVSEpfhlWPh6uU49vI0qMOE1/flJR6/I8ALJRoN7fjUdL/5+ul06tWi915isTu rF4PH6v2D7LgEBY2PUxe2uwKmf101RASffJHspF6Sc4Vf85muhnaMomueKhq2HC1dc/HtFrvU8HK imhqA019QmTZFdLzf+plpvibbCd+aUAS/9GVGK5O9SP7pv0ll89XVpFUuGoR61+1NGMkQAIkQAIk QAIkQAIkQAIkQAIkQAIjEYAOAc7OZISxAc50FpZv6fz97fCM+sN4gWM8VpIZnbpnvJvBX3L6m7hu sYS8sI5j1MLbqKA9T+7sTtWHeV5eCjULGYriqc7H80qOhT2Pxm9dDzW4R7qzt55p+vLyZTXNdyf0 DA5NR9/a9b1ot/tRcwPGeGHPUDwWkY2nptx3WyaVKK/aqm7/PkaxLD4KAjWT5UdRnkXWQsAeZBQJ x+urRENK/KBch7xwxIWyYpNp9UVFsmpoGNLYsIe8ePRpsmJKdXVAbZuz5Jmjv1V7lsOa0l1Kae5n 5blDPjRMbpCMP4LRaEJeess5snSL+WuWzS+R2LO3S+yFemMDinbqBoXVFzmiB0/Vupcl9twdkhzC 2FDY+XvaXnXPKftirK3PKxIgARIgARIgARIgARIgARIgARIggfEQgE4BPvj9v/4rwsfDaix1jSmU ngk9vCGhU6zDxoaxyGrnstDnwLutfGoGoulqiEF6K+l80JdNt9yhpqc6m9b1sZX6WdvB0V9hDPDt cj9GP7Lakvb+JfXdSyWwPRy+59aut62VwKtGCHCFQwPUSjFVoIdcsTwLIJRUEy3VUJ4uRf0jY+c7 uBdbv1QLhenywtt+KQNP3iSz77pYEiuX18ioXCS3l8GF75D/vmYnyevkg4S2bUse8RIhDqsxwkjP TvLYsWfLJrf8TKY8dX9FRCWSep30H3isvLjNppJ98rJKsshmUtTVCJCHfuILCCGuc7kueemN35X+ 5+6UDe66TNIvPxOqVxft2UMKOx0s3j77SiSjBgutD1n+G74thZ6dJXnTBbpt1NK6SsFlacq+snzv 98iKrTaWmFqPjZN9IQ5ZiYkkQAIkQAIkQAIkQAIkQAIkQAIkQAJjIgADA5yFY6rMwmsQgO4EDiE8 uCLEORnQaViepa/v3E2PgxC6nWw2K57vMJQ/ipLTtJIqz6yMsQuXmui43Rv0EXGsZJj3jnNk0Y4f lhcHPEl2biDzt97Q6dxwz1DulejneDlgbOZb+X40Ok7cEzjcI4zT3jtLd/pSLWNho+2w3toJ1KjC 11508ubaQwkCeGD9Vx0qT3zi9RLLF6Sk1s2I/tGozsFfk1N2n/+VJ3ZeKdGC/mHp7JCI/i3PhF4A 1EAbeBEGtn6TPLPNW3RNQF6SvSsk6Qd/jErRtHhTpstqtcThC8HzPLf1EPpj3mQgNC/pTeQ/b/2a rIgXpGP5S5IuauN6IFSpZyPJT+uWvv5+KaqBwp/zFll07AG6j56+kNrHqboiIRaSY/LwQrovpM32 kWfm7ieZqC/pvpWSxl8LLR+L6RKlzm7xp86QYjJeeYHtQQu+1JLi7/wO8XY6Svze5RJdvVxKvX2i gmWwGJN89zTpwwaH6pLus/qHunzJgARIgARIgARIgARIgARIgARIgARIgARankCgq9EdqFW/A31K NBrMssYGVsibLA76IIzf6YVqBg0FeLDCoZV4oK9F1aHN3mIbmaV9dwpqDQO9VqCrqxlGm1202/1o BK89T0W9b1ndsgtj7kjrxO1J9N41wq0ZdUwP3AxZ660MPJBhhwc2Ek+Lr3vw4QsHPqz0d/koo76S nsqoAl4PxtGVAlbH8rEiAZZTfJnZXnB98YREuudU9lK0L+WCGhrQH5ObSqXc6gNY7CAPeZCHdJOL tFwpJfnpmzrLnpUrqbEhr/vkBV+iuoFePCkxleO+RMN913hYHuTCQ24+kpTClA0kp0YMGw9YRYq6 p13Od31DX1HWpZf7iHaR5mn9YvdsKXXNcte5XM6FUZUPh737rD+Qb95l8oMESIAESIAESIAESIAE SIAESIAESIAEWpAA9Bdw0GkUVN+zZFlOPD28INjaJSpzZ3VpXrD6oQW733CXTP9T8gZlRe+g0znF 012SjBbLeipf08LiVRemui7omeCsvpWov/YGV0vvYCHIjmdkek/GirrQuFtifX1Lt9DkxVVWd3fa 9Rd14E0Xhzj0ddBvIQ3O5Fpo8urbt/T6cpZeX76+nPXPlR/FeE2uhSavWffD5LZ6iHsFhzDrFeWe p3oFhoeFW0yXjlRUktQxTugtDOhPaBPtL9xefoTm8cAijtAeYox0bWWtvIX4o4O6Flo6QnwhwJsx wEJrA2XgsdWR1be+1F+jnDmTY6GlW13rj6XXy7Jy1r710fqLPxAmOxyavOHKW30rB/loKxwiLzwW K8uQBEiABEiABEiABEiABEiABEiABEhgHARU/yD5fpGc7j6Q7Q1CX5W6xZq9b8bRwOSuqhoeGdBJ mX3ZguQKvuTV8ADl5/rolj50g3zjhLdJLNUpM2fOlNmzZ6tRoENe944T5bK/PKM6Iz08e4ihQy80 rMs+LzdceLocfcBOkuqc6uRC9sypnRLd6QA55YeXyyMrykaIIYQUnr5Bjt5pJzlA6x9w9OnytJYp rV4sPzxh/4q8qSorttMp8s8VVQGFZ2+RTx12mBx++OGy/+EflVufy1Yy/331N2Xnnd+gMg+QnQ44 Re5cOnz7Vin77z9qPw4I6ux0tNz6/DB1xjleaw/hhNyPcAMtHoceEc/b6kFPVuvWWJ5eOJPRWh63 Fh9SW3SPKxxGeZug/IbDSgIo4WHZxJehKeQtDCvEUQcGAYTpdHCwDGbs49pWJOAaink4hIODgxVD A9LQTtjZWQpYcWBy0TbkWNuQY6sQUBdxk4M4yqEuQsjDOFAfDiHkob8IrT3kWT8hA3vuoR7icFix AIc6Jh9tDOdQD/LgIcf6h/Koj/EhtH4Yd+s38uhIgARIgARIgARIgARIgARIgARIgAQaI4Df4nAu zKmx4d93BEYH3fqnlFCdwOa7qBKkU8947NGtoYPf+o21NLlrBTqPoizry8lgXvUp+bh0puPiq+LT 7kE7E7IxFIt5ufNHx8q+J1885HAWXX2BfEj9QR/5nGysNq2qq11JYOmmg1p27yVy5MKj5XbLqA8f vE3OPAle5Ae3PS0n7r2JK2F6I8jpX7pELn7wwXLNhfLcF+6Sb223l/ysXtZDZ8k/nvuSvGZKp9NJ 5Vc+J7+6665KqSWrTnfpkN33n/vkoYduL+fdJt+7/F2yx3G7OH0bEq39Kp+i3HXxF7UfD5XriDy2 9GzZb8OeyjUi4x2vCWv2/TC57RIad4R5NfI9s3RA37miDKjhIa0ri0pJt6lZuwyn7fpJg8MYbxm+ MOChWMdDixBKcPMQh3x7sJEPZ6GVw7WVM3koBwW/fani2uSgDJzVQwhv8hCG5ZmhAOlwkGOycG3p iMMhD/VRz9rAdX27qIey1k+TaWEgLWBg9U0G8sJpFrd0hNav+rEhPSwHZelIgARIgARIgARIgARI gARIgARIgATGRwC/50u+J7HVL4rodjXFkk4sVENDKTegP9JVbaTbQ9M1TgB8i3pGAQwM8J5OwCz4 w0/QbLylV7bmQxd+fFhjQ7hnN/74tOByaw0eC+esGV9x3/kye+GH18zYe295qyyXq+9YVJN38n6b SeQvL8jHd5tVSXf6qmCObTntZ7LXdmuYGirlu+KBHg8JkcTQk10hc/5+79QSf6zUu+rca+Q/H9pZ XlVJqY2UvMVy2VerxgaRD8peW+h7prLMBeP9iF1WwzGM1ypNxP0w2e0Ugi+85wfvIN5FeL277TSM tusrDQ4j3DJTcpvCGzPtYRAwxTiqI24rDKCIh0M9pGOmPsrbCgLkhcujHB58KNhRzuQjbi8F6sCh rCniIS8sx9q1vqGsxRHaigzIRJ7JgwyLIzRjA/qBPMg1WVYX8qyfWKmAdKSZHJQ3j3KIW2jlTSbk DzVOpKN9W8lh/bD+usb4QQIkQAIkQAIkQAIkQAIkQAIkQAIk0BAB/BaHczsODKyW+KJrRFY9L7G8 7mjQOV386XNFpmykM4F1hYP+g74ADr/n6UYmYHyhL4H3dRslX2daF1Vt5K51yypsGmF6jnbjauNz +qaXdMuiD/60Fsqex8klX/mQLJw3TZY//ZBccfbn5LQrHnFltlZjw2MhY4PphRCCjdMZDTwoH19Q a2x4/Qk/ku997GDZbEawK0b25cfl4v89Xr7wq4crbZ+0xxny5uw3ZHPVKZm8vFe7e0ilsEaO+PRZ cvjO0+T5B26RC74zIDN6gl043H1ziulqaRxu7el5E+hfZJPd5Ot7iXz5z+X8h74mtz76CXn31l0u 3+6r6cFW3ne9hAnt8IX/J3OjeZVXXj2UXSQnLqw1NoxlvPPK+kj0u9SE+1EddXvF7Lm0Zwr84d39 xHZKeMbUu++90Bkq7fb+tfpdWf9MqhNI3H2h6JcKvjRM8Q9FuCnph3o4w2URry9vMiEDHvm2rZGV tXSEyAunW30bNq7RjoUoW+/DcsJ5ZsRAvsmAHDhrJ9yXcF2km0ddyArLMznhMiYLcix9KJn1fbGx MiQBEiABEiABEiABEiABEiABEiABEmicgCnlSlCKD66SknrJrnYeqx5KRd1OGgrMsnGi8ZYmZ80q NzurExzC8erOFu1KCGO87zfnS81agz2/JPdd9hXZe7sN3QTUOVvuIsd9/zq56gfHuGGGjQ1IqHIK jDFQDj/yh3Pl0hCUPT99qVz6lSNk0+nBRGAo/mNTNpcPfPca+dnR24VKni6/vXuFUzBDrimaQwUq 0a///j754Ulvl333PVCOPuV0+dPL58pe06OV7cMrBcsRvAtwkOv70+Sgo9/vru3j8mvvd3nh8SAO f8/vL7RiLvzwW3aqtIP8xVc0Z7yQNd77UdPRNr8I7n9w3zAUux9tPqyW7z5XOIzyFkHpDQeFOBwU 5HCmSLd8u67Pt3r1+U6IfuAFgEM9PPxw4ZcA9awuQpNvoeVZXWsP/bK0oeQhzeqiTRtHfYg8uHD6 UHKDUkE5yDVv9awOrhHHCgaElm7lIQfx8DgszdpgSAIkQAIkQAIkQAIkQAIkQAIkQAIkMDYC9vvb Zv26MxnzOUnqLOCI000EOgmc3agHOEpC05Bu9fBbnW54AsYJITxmUhcKnup9MMsa2ynpqhL1pgi1 8sNLbK0c66/N3C8UlsjvTq1uLYTenn3au6Wjt1f0CHLnjMW8A0+Vy/9X5PBP/6KcgyB43lxMecEV i0/I+e//uYsHH++WL7x/oeT6+x03pFk/8Dzuc8KJss1FJ0iwfkLkkhv+Lifusp+riud7MBecOxrI Cj6P+t61cuR2HdKr/YSOynbYwFmikInx5T29USFXUFm5XM6lIH+T3d4k28iFlXav/vSVsuSju8lm IV2ce8/yj8hvz/hXSNKpstu8uJMV6AOXyPnHjG+8J+16QLnfT437ftj9MsahjrdNFFzRf/CHx6MF D0OV50X1OdIzdfWrzMbI77Xm3lqucBgjTzyAQ/nhxAxVdqiH2MrhSw5GBFxbHNeIIy0cH0qO9WM4 eZBjPiwvnGZ1h5JveSg/VD+RFu4jylmdcDhcfSsfljFUP2ycDEmABEiABEiABEiABEiABEiABEiA BBonYIrvsASncNQEbD1iCjkLw+UYHx0BmGgSun1L4HVyZcxWOVSV7aOT1Hqlii89IfeEu7Xb12Xh 7CDBPUfQ8qpzindVAm+2/zHyuX2C/MpnuYyVyz99v/y4kimy+2ePkC3jpjgOnknItmfXn7FA3nNg tcK/7viXLNe2LL+oW+nUuLd+V05902Yu3/pYH7q6uu9/2MFgZOWcInvqjnJsqF2Rs+S2xatq5ELO sntvkl+FBB34rX1lo3L/IK/w7ENybigf490ihi23qu2hnI1nbeP1X3xC7g7JkkbuR7h+G8fBDE41 uZLW8zgySdW16j9chw1drhA/mkqAKxxGidOU3sOFw4mB4hyu8pCr0WAoVy/XygxXz8pbOQstvT60 fli5kUKrX1/O0i20fOunXdfn11/DsBB2Vr++XP11uA7jJEACJEACJEACJEACJEACJEACJEACjRGA 8hIKTcz41Q9VZhYkogdGmyquqGcOlNQXtExMve1A0Fhrk68W9BzmY9GIzJudEU+XNsDokIzrJM5I Nb8d6ZgBYdmSB8WOMcA4Fu6/rXToqo5SeTKt6XWglzKFeb0yEpyQh7J4HntfeKkGyfIV/5ZHnoiJ N+hVnkNTxqNeLDYoT+tuYBXXqXo4zGTXBKxw8OpWKpx61OskpX30VTdlZ5jatuDWX9enssLa5Pq6 UgUrVlAmGEtadjvyeJGbzrMicvHVi+SdWy50ZZDoeYNy9x9/WckXmS+H77lFxZiA8fa9ONR4o1LI FkY9Xl9XXuS0XyuefFDuDLXWyP0IVW/7KO5jKh6RBXO73FqanrTec1XV2n1u+wG26ADq3/EW7ebk 7Va7vADj7ed460/eJ4QjJwESIAESIAESIAESIAESIAESIIGxEYASzpxT9Oo1DA3hKZLh1Q1WlmFj BNTeoDOs9VxPnXupgVvh0M56kPDz40cTNVAWbjnDKXMxPngYqlDe6rj0mhrVC5RBfilefT6R++h5 n5RDqjr9aoXhYirHGQQ0HzIRr3GlwGiAtsI7cNi19df6XKkbGoelzdp5PzlAzpNbygl3fvVy+fdH dpVtEsEYigOPyNVnVg+1lt2OkNduGGynbn0rRmv7h/EeOsbxwgDjg12seffDxtjOIe4pDH49mYQ+ C3j3sA28jqj2EWvnIbZk32lwaPC24IEdixtt+dGWG23bzZZn7Y5X7njrWz8YkgAJkAAJkAAJkAAJ kAAJkAAJkAAJjI1A+Dc5FJU6bVv3T9IQvuwKqqTFIblx9eEzHCyf4doJGGMotOOxkszo1D3jofhW dVKQFmx5jXJWdu0SWyMXY4Ci3Cm49dkp4ECKkJs5s8cZGTo6OipbbiMbKw2COmlVAIcqlKNmFMCM /yf+8pc1C4wl5ekByekznVG2WJHg122pFNXVFjirAcYQ6ydWOth9sL5AQR12uMa9QzmUceU7d5C3 HSlyy2VW8jy59eFPy9xXT3MJLz/wp5rtlI48Ym/psaIaguUzf6/ZBCmUO8qojndAVzjA1JDL67sc co3ej5CIto3a/cQWZhtPDc6QzaQS5ecyeO+sTNsOskU7ToNDi94YdosESIAESIAESIAESIAESIAE SIAESIAEJoJAeOY24mtMqQwrWsPxiejMei4TCs3AwKCzz93U6mA7F1Nct+vw8dzA15+PcO+/XpR3 bdtTMTbYCgfb6juqs82HsDc4DPZcztpqmxosC479orx/l5lqsKieJwquUPrDQIEQxgykJUoJ2WiB KvXRvxop1Qu7J7gH6Jd5k4lwOIc8q48ykUhcdj34VJHLzqhUueCaB+UDO+6t1wX5xxUXV9JFdpM3 7bGpu7b7jzHPaHC8EJTQfxvturd06fiL2rf6UY/nfoQ63rZRu1fYxgwOzx9u79rucdsOtoU6ToND C90MdoUESIAESIAESIAESIAESIAESIAESIAE1ikBVdaqxra2SVXIQTnuFORl3aspWmsL8qqegCky jZcpljGD3hTqyLN0hO3kMAZ4KPixesBWA9gYsrpKBmOFhyIfZyPAIY46+XzKbS1l5bHkAzxsxQDK JLq6qtka23KrhbL33nMds1QqVVEWox85ndlfY3DQ9tCWsa4RVL6IJZKVFQ5Y6WAGB2SHZUExXe/C 987an7Lz/vJ2OUN+Wy68+PSr5eETXydbFhbL7366uCri4CNk4ZyEniEQq9x/jDfZ4Hgh2M6esPHm 686raPR+2PNb7Xx7xNBvOLxXYGLvnaXjXiNuYXuMqv162V7fau3Hlz0mARIgARIgARIgARIgARIg ARIgARIggZYkYEpKdK42HnXnYD0AAEAASURBVMwAhmJOdXZ04yAQKDr1MGS/JHkcwl2MiF8KlKKm BB2H+FekavhZwVkfYXfTv54VT5W9GBs8FLtQ/pqPRBKaHq5RG4fsYr7WAPbYk/91zyfy6j3agGxr LxxHGlx9e9FooHQO98/q1/am9iosx9px40psKW/82MJQ4Z/LXY/pNkeP3iJXhFKPO2yBpFWItWX9 K3m1DBsZL5oJ3xdrdrz3w+S0Y2h88YxmlfGgPlfB7lpreQDbcaAt2GcaHFrwprBLJEACJEACJEAC JEACJEACJEACJEACJLAuCESlqFvc1Cp4oagraRK8KVbXRV/WpzZMqQyFOwgvWZaTJ5bm5KllWfnP ypxqwYOtfKxcO43dFLnoc8dmr5ZDwp2/9CZ5XIeHrZTg4cJjXHbPRfLZm8MVXIFKApTmHZtvJwsq KSL3nn+9PFmoNTZAJp5N8IXHygfztmrB8qNhSwGa0211UMf6h6Zwbc96eHyhbjjLBcrA2yoOrDCA 32n/Ggpy8403y/XX3xKqfrD8z45zKv1FfVv90Tm38fFCjq36QL+7Nt9RDg61Kg3cj2HHH5bb4nG7 Twix6OOep3rlbvX9Hja6UnW4ssI4zbf4cNquezQ4tN0tY4dJgARIgARIgARIgARIgARIgARIgARI oEkEVME75DIGKGnh6cZNAPvqD+R86csW9DBj3VZIVzrUrwwYdyOvlIDU5rJPja79D/KNX9wzZG9e +Nv5svCdpw2ZV5PYua0cdUQ45Qo566J/VpTDUBKbQtkMBwjhC2qYsDyEwznkmbIZ4Viclbf6qJue v5t8MCTk5u8eLx8982/VlPceLPO7qv0O15XO7eQdDYwXBhMbrxlMRO/H3jUWhybcj+oo2i4GzljV sHrQk9UDnnh64cyrtYtK2m5crd7h4d+8Vu85+0cCJEACJEACJEACJEACJEACJEACJEACJNAQAbf9 ihob9Lhd59dQueq2MwJPNy4C4FxQA8Oyvpws7c3JstV5WanTrH1VfA61Bc64GltHlWv73Sm7HXpC Tct//fYRcuLPbpUX+goufbD3abn2zA/J9m/5XE25ygWMXmUXKOLT8vp3fsmSXHjbD94vx/7oBnmh P+LOX8AqBvjOzk6R7Er511+ukM+8b0vZaquPyePFDrd6AAr5GsW+SVQltKVbaFkjhVbejBq2qiIa 3UQO+uz+w1b//JtfI0k1ctiKCDN4oI/xeKfs2eB458//uDzuZ9yKC8iORrtlt0OOr+nHWO9H7f2t EdU2FxiD+bwa+Z5ZOiBPL+2XATU8eHl/jcO122ZgbdJRHhrdJjeK3SQBEiABEiABEiABEiABEiAB EiABEiCBphOAsjek8K3Ix6zvMc78rtRlpEIASs+i7k0FAwO8p4cEF/z2nv8Lpbs5KM7n7H20nLL1 T+T7j1mqyC9PfZv66vVoY5ANmR1bHSbnfODX8tELHq9Uvfu8U2Uv9bLtHnL4rltIZHCpPPzw9eor RVzEd6sXgjMNwn2tLTW+KzM8mBT0eZsDdGnBd261pFD4Htlnhx5n5EA5eOuXyenc+nA551gd78/H Ol6dwa8rOyKRkpMJeXP2fo/ej/Oacj9Cg2jLqBkdPD94B/EuwuuXW1uOp1063d7fcO1Cmf0kARIg ARIgARIgARIgARIgARIgARIggRYjAGVcXPVu8IibQ8wUodVUy2U4GgKm6CwWVcGp3tdVDr7OtK5c +wXx1fhg5UYjsxXK2HNhWxgF4YZyzC8ulreOooNbv/dMueo33wiVVCOMXpki3uSmUh2y3ycvkbM+ sl+obDm6+C9y+UUXye9+t6axQaRbOpPhQ6qD1QxrCmkspX78WFWAcxTQ/8QmC+XEXdeUu+Ck/WWL dHDWQ7CiITjfIliREPTVjffURsbb5cZrZ0IEKyg2Hsf9wBkH7evsfULo3jt9x/Ce2XuHrczgC4X2 fP/a5c7Q4NAud4r9JAESIAESIAESIAESIAESIAESIAESIIGmE4BJodasAKWqpSJO1xgBKD0Dpzw1 HlyG47WGnsZaeeVqmfLdhVNeI9/+2zXy7eNqDhCodm7bw+T0S26R33/6DbJJyrgge0uZlgqK2bOG MDBAdMu+x58pN//6LDn+kN2qsoaIbf/6t8vXvn+J3P/0D2X7dG0BbFkUdl3lw6zDaYhb+4g7A0Ki G9GKC9dzY6700wwcM+XA99VuLyWyq7znf7Z3siHTHOI2ThhZgvjYx3vfkrNkOx2vyTL5kSbcD5PV zqEZGmwMZpCwa4YTQyCioMNv+cS0QqkkQAIkQAIkQAIkQAIkQAIkQAIkQAIkQAKvOAFTuOXzefE9 T1Yt/Y9EVj0vs2/4vMT6X3L98ztnysv7fUlKUzaSjg3mSiyRcvvl1ys1X/HBtGAHTM0GRSfiuVxO D4v25PaHX5ZB3Tu+Mx2TzlRcdttyhnRoiBnp4Aqlczs4e348fXYwc7yvr8/NFkeIMSM9ku+VpS8t k5V6SHYmk5H01A1k9vQOiZV5OCWwPn/5YkSmzZouaTUAdHV1OSU/WCAf8iA/m806jlDQ+/kBWb1q lazqz5XLJqRjyhSZPXOmdHckHUecqQAZcMYfs9n7Vy139yHV0aHcUzJF62G1AcpDNvijvM18r4xr 5bKaej09Pa4eVhSgHfQRfvXq1W7sCAu5fu1/VnyVifIpbQft4V7j2gwM6CPeQ7Rp7TU6XrsvJq+/ v7/h+5Ep9xN8cE5Guz2f4AqmYAKey/X8lAv//Lzb0uywBbNleldKZvZ0SDwWnKmB8mFjEK7pxkeA ZziMjx9rkwAJkAAJkAAJkAAJkAAJkAAJkAAJkEB7EoBeVpVyzocXMiAJWRiV+0CErlECQJtQ5WYh VtIwoopOW+XQnnBNoY8QilrzUPAiXkr1yIZzp8tGmm/KdVMAV+qoIjuh+ThIGWmWDhmImwEAIQwQ cPFUp8zeaIpsUFfHZZY/UBZ9gAw4kxtJpKUrnnLGAuSbs3JW1kKku7rJTKWepYVDN97yuBGHjyU7 JN0ZrFpIlPuCcSAvXBdtufLlPIs3Ol7XX7Rfljee+4G+tbvD+OH0Tko6oYYsvdQ75K75xTaxd5cG h4nlS+kkQAIkQAIkQAIkQAIkQAIkQAIkQAIk0LIEYu6w2VrFN66iqiAvqVcNqVOStuwAWrRjUHaa j0UjMm92Rjw9wwGGh2RclcLK3fJbdAhr7ZYpz7FCADPhbaY/VnSYwhwCEIciHEpwOMThwvWRBxmm cDdFMWSiPGRg5j6ctYOycKiLMvBIwyoCOMs3uZipD7mmjLcQ5ax+uB5WMKCMGUqsfDhEPXOQj7Zs 5Yf1A3xQxzhZeygLhz4hrbOz07UFmY2M1+RBJuqj3wjHcz/Q7zAbyG43B74pPaRmwdwuZzvtSev7 p49i+N6125jaob80OLTDXWIfSYAESIAESIAESIAESIAESIAESIAESKDJBKCMg8oUHvFaZzm1qbwa OwG1N+gM66ionUE0cCsc2l3haf2HshzPDhTeSIOiG2lQdsMhDmflLUR62JsiH/nwuIaDXBgZEKId k+sy9cPKDxWijLUPeahv7VjbJqc+NHkj1bNyJg/9tDYhE9f1baKOOcStLsqNZ7wmC7Jh8AC3Ru8H +hTup/W33UKMAQa/nkxC7z/ePTwTOor6r7t2G1iL95cGhxa/QeweCZAACZAACZAACZAACZAACZAA CZAACTSLAJSu5qGBKxR1Fjl8qAEo6XReuurkuLohhGVMUVPWQnEb162UZnQmAmW5gg7SAoU7ylnZ MTXwChW2vkI5DodnCUpypMMYgJUBCKHsRp4prm2cVt+uTUFvMlAe9bAiAHLsGisc7LlFaK5eDhTt qAMPh35CjvUXachDOdS1ckiHwzXSbRzh/HA9k4c060+4v1D0w1k7GA/Kop71GfkY91D1Rzte9BNy 4SEX8iEP1+iPjWOs98P6CTnt6sADDluYbTw15bhkUgnHKKpGiPB9aNcxtmq/aXBo1TvDfpEACZAA CZAACZAACZAACZAACZAACZDABBOASi5sbKg0B2VdWWFXSWNkzASg1ITS1p3bUFbeWpopRMcstIUq 2BhMQQ1lN7ylW4h8OFzDWxkzNFi6haY0Rz0ozqG4R5op8g1BWNGOutYPxMPtQQaclbd2XGLdh+Wh LORZXyzdZFs1S3f3WQ0IZnhAPtLMWzmrZ6GlW3uNjjfcL+OAvsNbnoXIh7O2rUz9/bA+tmuI8YEr tjGDCwwNwbjbdUzt0G8aHNrhLrGPJEACJEACJEACJEACJEACJEACJEACJDABBCIlXd2gPuwwf1zV dPqps7fDGYyPSMAUuqbIhbITccw0h1IXzpSgFo4otAULoO9wUFDDYZxwNpMecRsv4igPb4ptq2/1 TAGOsnCWjhB1zJvhIChVlYtryDQ5Vt/6YOn17Vo5k2fXNq6R6pl8K2/1Ld3aq8+39iwfBhU41Lex IhzteK2fJtf6Md77Yf0zua0eWn+No713lg5OiFvY6uNp1/7R4NCud479JgESIAESIAESIAESIAES IAESIAESIIFxEIBCE2pjeFOQVsSpUk41c5VLRhojAOUm7AyeHyiPo9GYm2WN+eWmBG1McmvVsrGY ohuKcktDTy1u+XZt4XCjQT68yRuufL1ck2fl60PLHy6sL2/XI5W3ftj7NFK9enkoD9/oeE2etWv9 MXnD5Vt5C61cO4c2lqK+gFkvMFp1pGN6YDu/1yb6vtLgMNGEKZ8ESIAESIAESIAESIAESIAESIAE SIAE2ogAFHV2hgMUlqa4a6MhvOJdNWaYSV1Q5fuSZTnxCrqnvm7tktKTo+fO6tJZ1u3PNjxOQDcF 92hvgNUfrrytDDAFvoVWvr5+/XV9ueHyhytn5S20chZaen1o+RZavl3Xh5bfrPHaiodm34/6frfq tY0bYdYryj1P9QoMDwu3mC4dKd1iqWzYMe6tOo527RcNDu1659hvEiABEiABEiABEiABEiABEiAB EiABEhgHAUz0dQpcrHSom/Sr86xVcl3iONqazFV1brUM5HzJeb506gxrsIbyk27sBCabgniyjXfs T8Taa4BfUV+11YOerhopiafeneaB149fb2uHN45cGhzGAY9VSYAESIAESIAESIAESIAESIAESIAE SKAdCcDQAB/xC87Xj6GEveTV042PABgXdGXDsr6cDOZ9yebjanSIi6+KT2fsGZ/4lqs9UQry8cpt tP5Y6421/HA3sNXkDNfPVk23dwthvuDLM0sH9J0ryoAaHtK6sqiUdJuatWr3275fNDi0/S3kAEiA BEiABEiABEiABEiABEiABEiABEigUQKY6ls72151dME2Sjo7GHG6xglA4VksFZ2BAUYGz/el4NOQ 0zhR1iSB0RPA+wfv+cE7iHcRnssbRs+wkZI0ODRCjXVIgARIgARIgARIgARIgARIgARIgARIoM0J QBGHmdTwiNe4iCrF4cvOytk1w7UTMJ44rBfe11UOvs60Lqomzl3ryhK1PVTOPGjWjPa194q5JLB+ E7D3DiG8ry8ZfPAewvgX+EKhIBI6Q4XvX3Ofi+pfjubKpTQSIAESIAESIAESIAESIAESIAESIAES IIEWJoAtzE0xF97OHMo3zAF284A1TtcYAVN+YjZ1wBlywvHyGRqNiWctEiCBEQiYwc+K2fedXTOc GAJc4TAxXCmVBEiABEiABEiABEiABEiABEiABEiABFqfQFGn2cOv4TBHNVpZAbFGNhOGJGBGBlNs YiZ1oYADazHLGtspifOmCLXyQwpjIgmQQEME8H7h3bIVDhrVaxHP89RH9V1MSFFtqfb+cYVDQ5iH rUSDw7BomEECJEACJEACJEACJEACJEACJEACJEACk49AeHOlcHzykWjOiLFGJKHbtxRiJQ0jEldv BonmtEApJEAC9QQqxgRdVZRO6Kot/TKLwoiq/9TUUF+c100kQINDE2FSFAmQAAmQAAmQAAmQAAmQ AAmQAAmQAAm0EwFsnuQ2UIqqEg4eWjm4aCLwwRU/x0jADAoIY8p13uy0eLq8IRGLSTIelVgk2GPe lKJjFM/iJEACoyCA9ysVj8iCuV3OxNCTjkoyphubcau4UdBrvAgNDo2zY00SIAESIAESIAESIAES IAESIAESIAESaG8CsYSU4inxMjPU9ICtRvRQ1Y6ZlQOjqZgb/+2FHSediIraGSShF1jhQK7j50oJ JDASAbxnMPj1ZPR7Tm2pcTU2RLFbHBc4jIRuXPk0OIwLHyuTAAmQAAmQAAmQAAmQAAmQAAmQAAmQ QPsRcApvNTZ4HbPFi/XI0gWflKKeNRBVbVwskZSOzpmSiMd5hkODt9YMCuAZ162UZnQm1Zijx3Bj IYlL081dNEQ5K9tgU6xGAiQwBAF7r2Dg23hqym1jlkklJKarjKJqhOC7NwS0JiXR4NAkkBRDAiRA AiRAAiRAAiRAAiRAAiRAAiRAAu1CAMo2KLzVuqDT7kX8zllOIY7jo4uqkIPRAYo5c6a8s2uGoyNg nN25DeCtztLIdHQMWYoEGiVg7xq2MYMLDA3cUqlRnqOtR4PDaEmxHAmQAAmQAAmQAAmQAAmQAAmQ AAmQAAm0OQFTcpsiLpVKSVxXMvi+7wwOMELAJ5NJl26z8Nt82Ous+2G+xhgheNp5DeF0Z/RZZ71j QySwfhOw9w/vFd43e+8sHUZUxC1cv2m8cqOjweGVY8+WSYAESIAESIAESIAESIAESIAESIAESGCd EzDlGxqG4g2KORgdECIPyjqkm7EhXH6dd7bNGwQ77B3v+Xo2hm6pFI0G27lg7Qi5TtzNzS59RG7/ 6yLpy4t0zdlB9t1rG0lPXHNrSH6l21+jQ5Mwwd6vor6AWS84pL0jrau39J2km1gCNDhMLF9KJwES IAESIAESIAESIAESIAESIAESIIGWI2AGBnQMivDwNRR1WPkAgwPScW3Ku5YbSIt2yHjBcFNQvkuW 5cQrFAVbu6T0AOm5s7rUqBOc4dCiQ2jLbtkqkkWXfFjedNLt5THsK39ddavs1j3xRp5Xuv22vGkT 0Gl8d8EhzHpFueepXoHhYeEW06UjpSu4yt9p9p5OQBcmtUgaHCb17efgSYAESIAESIAESIAESIAE SIAESIAEJjMBW8UAxbg5KOEsnQo5o9J4qHOrZSDnS87zpVNnWCtep/xsXCJrjkQgkdo4VKQHx5Ss U/dKt79OB9vCjeH7q6grjFYPempYLYmnXo9uF30l1frUwh1v867R4NDmN5DdJwESIAESIAESIAES IAESIAESIAESIIHREjADgs0AHu31aOWzXC0BzHgv6MqGZX05Gcz7ks3H1eigZ2ao4tNmw9fW4FUj BIwlziKBK/hOrVwWpVvq+AW9D+JW7CDRnvtygXEHr3T74x7AeibA7gfCfMGXZ5YO6DtXlAE1PKR1 ZVEp6TY1W89G3TrDocGhde4Fe0ICJEACJEACJEACJEACJEACJEACJEAC65SAKV7NAGGNW7pdM2yM ABSexVLRGRhgZPBUIV7wg+1eGpM4SWsVsrKid9ANPp7JSHd66BMZwBs+jhnsIReLFjV9bFPaC9rm 4OCgM1SopUK6u7tlJEVqM9tH9wvZXukdVEsJXDwj07qHHndQgJ/1BOx+eGqAwvuHdxGeyxvqSTX3 eqT3pLmtURoJkAAJkAAJkAAJkAAJkAAJkAAJkAAJkMArTsAMChbWGxxe8Q62eQeg6ITD+Rjwvq5y 8HWmdVE1ce5aZ9xjMr5xt/vQ5sNuWvcDfgV55NbL5Pwf/VzOvPK2Wtmv3k8+9+5j5egPHinbTIs7 pv/58/nyse//WTpnleShC34dKv9H+dB73icLuyKSLe/t39+1UM48+0TZPBEYIex+Lf333XLNNVfJ lX+4Wq68/aGQDER3lEOPO0I+cNyxcvAuG9Xk4Z6Op30T5vqRfV5u+PXF8n8XXSwX3/agZQWhjvuk D3xEjjv6UDduPje1eOw+IoTHihf44D2EwSHwBSx3CZ2hQo61HMd7FVH4dTa/8YpkfRIgARIgARIg ARIgARIgARIgARIgARIgARKYvASg4ITKDYrNvmxBbl30kttSqTujWyqlYrLAHV4brxzKbYaHyUus duSl0kty4QkHygfOr1O41xbTq3fLAwMXyXYJX+770eGy2ylXrVFi6IRD9SDpK+R1PWWDw/IH5Rsf eI185cqhS9enHvrdm+W3n9q/suIB9/u+Hx0mC09urH2Tv/zei+WIXd8jdeYVy64Jz7zjOfnEXuGz KmqyJ+WFqbnt/cvlcrJctzO74E/PuhUOR+6+sUzvSsm0zpTE1eAQ15UrcDQ4NPdx4Rqu5vKkNBIg ARIgARIgARIgARIgARIgARIgARJoOwJQ1Jmyru0630IdNo4WwuBQKODAWsyyxnZKel2ZcR0YJci9 egON21//96g1jQ077CP77LNPtbCL6ZZDatBxM9mLK+vy1na5UuuU6+n9eOBXXxq1sQFSr/zMG+Tb d7xYnjlfdIalgj/29oOZ98EqmGX/+InMGMrYoGM+eJ8d1hjMSXtvImf9NejDGpmTPMG42goHTLeH 9zzPecu3522S42r68LmlUtORUiAJkAAJkAAJkAAJkAAJkAAJkAAJkAAJtAkBVbqWdHZ2pJhzGrmS RCSCbWcSHZj22yaDaO1ugmJCZ1MXYiUNIzqzOuKMOzQ0DHPfsg/Jdz97eyjzHXLZfafJm7eeFaRl V8rj/7xJzj75GPn5olUSK68m2f6d58h1Wz8nsXRR7r7gVPnSrx8py5gvX7vodHndtKhEUyndxsrX x3tT2bGzamTLqzLa3A4Hf0o++/EjZM9XbyEzdSa8HqQgLz+7SH7++f3km1dbKZGvfv8K+cieH5Kp 0GSr2+FdP5br5z+nbaD9U0bVvkkrDT4on1jwYbt04d4fO0/OPvVwmTcrOLchu/QxufCb75VP/nxR pdxJe5wph/rfks0rKYwYAXu/9BtN0rp1lh7hIPoE4BtOi4RuuFVg2DQCNDg0DSUFkQAJkAAJkAAJ kAAJkAAJkAAJkAAJkEB7EHDKOJ1xX+pfJpLrk9Iz/1TFqhodEkkppbpEtthLJNlR2WqEW46M7b7a zGmEsWhE5s1Oi6dnOCRiMUnGoxKLBMpuU4qOTfr6V9o4YEXI4BP3S3hjos9e8TXZe6OM9PX1lQce l013OUROv+N5+XJvSaYmcpLL6d78mY1l+52muNUGg9tvoWXN4LCF7LTjVjKvMy5dXV0S03uQ1kOn I/m8FMpb6kzf4QA56qit5NATPyhv3HaO5DWvVPK0Tc8Zh9KztpGP/eTP8uwme8kvDf9V18rilcfo 2RD66mi/ix2buPYxi36k9jN68HVU6+Rh7FPD3qOXnyMXm1wNX//Zy+SyT+4PwdLb2xu8h5mN5L2n XSszCm+UY375cLn0d+TSuz4hn9lztrvm1lwhiBrFc5WKR2TB3C5nYuhJRyUZ4xZKtZSaf8UtlZrP lBJJgARIgARIgARIgARIgARIgARIgARIoA0I6CxfT40MuQGR1f8VWfmcyKoXRHqX6snGeqgqXVMI qL1BZ1hHJaOazozOtIYClAacodFCQez1v1yTmdBFBtgCx7bHQRwKft9PSE9Ph8tDPaQjhM9lwzPY +9WAUFvfDhK28nNed4ycf/6X5aD5swLjgcqqtqNbYWl7BZkrR33zjaG+6YqV8pX1zeSNpn3UgSuV /i0/fd/PypIQvF++ccLeUlLDBfoAb1sBYcxvOvkzsn2o9CU33e/GHEpitEwA7xkMfj0ZfVbSCV1d hIPaNTP8eJBW0wlwhUPTkVIgCZAACZAACZAACZAACZAACZAACZAACbQmAShE4aDsLMHYsOI/amR4 XuL3/15kcKVEMlNFpmwk2S32kUgsI4lEoFKlgnxs99N4YcZ5XLdSmtGZdIpj7OYSpOnmLpqHclZ2 bC2sX6XNWADFfnLO1rKnDu+u8hC/8eZPy7Z3flN2nZ1yqxPAC4f9gh+eZ1ybAQGHBEM5X/DDGuWi GhywCiLmnmeUxSoHeLQLF66PNPQDspEedsW4Wj8qzpfc4KBk1YCEsqiHlRFjaR+iCs/eJ2dXZIrs /vm3yaZ+v/T3BzKRZe+te146XyPvPkjk8zcGlRbd/qAs/cJ+Ml058H2tgrT3CluYbTw15RhmUgl3 36NqhHAslRld8wnQ4NB8ppRIAiRAAiRAAiRAAiRAAiRAAiRAAiRAAi1NAApMnN1Q8j3VeOZFsrpt i/pSJKZbKvViSrlT0KGcKe5aekAt2jmwCwwMqpR2U6uD7VzM2NCi3X7FugWlfXH65rKH9sAMDnpE s7zr9VfKUZ86Q45924Gy5Qa6h1HZmSLerhsN3fuAd6LsnRw1OvT1r5Zs1nPvAGwNzz9p2zShRNWo gX5b3dH0ycqi3sDLtSs6VqxcIg8/FhVvUN/NsgvLTCSy8uxqy9GwW5XoaL/8fIVyJn3U3j9sYwYX GBq4pdJEPxg0OEw0YconARIgARIgARIgARIgARIgARIgARIggRYhEFZ0FnX2djGflYiudEA65vpi vjfUqJilrR9rzMKn8WHtN9L4IDRlJ8JkUs/GUMZw4XQYHiazMybO0KBKc6woKBQ2lKNv/IGcftDJ NWh+c/qp8pvTRbZ520flcx98jxzw2rlupQN4Wn3M8Me1/hdyemaGrmbAqgjk2+qGsNEnqKOV+p+T 2667Rm66/la55Ma/hmQMFdWVEFhNUaiuVkEbcCO1j3LWbz8arLKwFh758Uly8I/tahShr2dRqHHE 1zGCH+RijJPRYexwuLd4tuy9s3RwMT6WNhk5TfSYJ/e32kTTpXwSIAESIAESIAESIAESIAESIAES IAESaEECUMbBF/XgaPiwC9KDveMRp2ucQKDUjIinW/zkC6qgLur2P6VAKUqF55pc7bnMzH2r3Hvt j+WtaxaRR644R973lt1lk/2/Ine/lHcKZLAM+2itxl8V8PGKocGU/ShvRodIxJf7fv0l2XTbPeSY U741CmMDOoZ3KHhPwm07uSO0Hx7WU3ePZNgIlx4i/kzOHT4NowtdlQDuA1xRv8OyXkkGcY6Hfp0F ptVqOcaaT4ArHJrPlBJJgARIgARIgARIgARIgARIgARIgARIoCUJmEIXM6KLmJ2te9tH1Kvm1PW3 FNGZweqxF71+uBnCLTmQFu+UKTsxo7qgiuAly/RsATU4YGuXlB4gPXdWlyrAgzMcWnwo67R7tlIB z2nH3P3ktIf+IR+57w657KLz5MKbH63ty8PnyZu3XSzXLLlW9poRKP4xox1GhER5C52gQlSSqZSk 03H1aWd4QDm7Ryiz6P8+IW888Re18vXqjYcfLVvN3VQyUT3AOVGUe7/1PbmtUsrOWAjuI9odqf2U 9sNWWEBMNpuVGVtuU5GIyIJjvyjHvBaHVwcrFdBPeLDByiNjhLLJSFI2XrCvdGO1UrmMze5HfniM uJ4sDgzgEGa9otzzVK8zPOw2b7p0pDSvzHSy8pno54AGh4kmTPkkQAIkQAIkQAIkQAIkQAIkQAIk QAIk0IoEdAIwznFQDaYq4DDzN3DOKKFRzA9GnG58BHQevAzk9IBhz5fONLZ0CWZdj0/qZKmdklft cqB8fve3yskvL5brLv2xfPZHN4QGf4e85XNXytKfHqLK92DFgimbQ4UkoopnpJs3JT7KlJ6/QY77 SK2x4fgfXiWnHL6bTNEDv6Hg7+/vd9sV7ZlcLLd95Zqy6Np3AzJNfrhtxMPtWzkz/iW7q2dSoOz8 bfeUfffdzBkmqltEBQYHGCjM8AA5MKBgxYbJQn26KgEwKuptWq3nYRQ14ql360Bw6/AFRzchBLil 0oRgpVASIAESIAESIAESIAESIAESIAESIAESaF0CUFq6/d51O6WIejMslHS7H3jkwdONjwC4FnRl w7K+nCztzcmy1XlZ2e+Jr4pPYz6+FtaP2lAMw0N5HvZIg8OzmJ6xjRx1yk/kn9eeIduFh73oYVml xgTbnx91Erp6pOpUrp7dAOW9eWsDZfuXPyuLqoXliG9eK199+wLp1m2WoOCHt/chmw1vWxQYI/Au QQ6MDQjX1j5WQNgqCJRzrno2tLtc/Pizrj23Ckll27uK0AwL1o5dWxgaxqSOGg+E+YIvzywdkKeX 9kufHgAOwx+MgHQTRyD89k1cK5RMAiRAAiRAAiRAAiRAAiRAAiRAAiRAAiTQegSwgiG0igFqOKri mneboPAs6j7/MDDAe6o4L/hhpXXz2mp3SRUFvA4EBoGwAcFxLCvfp213uHz149tWh7soK4OF4NIU 8dVMxCJSzq5N1ivIffbeO2vSF+6xbUXJbxmm7LfrShh6d5DWSPuZzbeTBRWBIveed508WQgMUuhf 2EN+2LARjof5hcRN6qix8/SdwzkqOHMDnssbJvaxoMFhYvlSOgmQAAmQAAmQAAmQAAmQAAmQAAmQ AAm0JAHMry74Becru4tEY7rxeayi5GzJjrdBp0zRCUW1m6Guqxx8nWlduVbumDVv5dpgSBPSRVPQ 21ZEWIGQX/aULHp0qcR1uyBsGYRzD1AOrHK5nAwOrpTnnllc7c92uiqimHfnG1hiwRuwqIa3yN2P r64YA0yW3Yv07E1CZUWWPP2CDAwMuJUNOMsE5ybgXg08dYt877TrasrahY3DwpHat3ru/ndsK+84 wlIQXiFn/ureyrOBMpALRnb+A5jAi8Qq51IYQ5SdrM7eJ4TuvdP7hntn9xoHSMNj9Qjfv4l7Smhw mDi2lEwCJEACJEACJEACJEACJEACJEACJEACLUcAyjg4F2oc6knEoai0FQ6TWWnp4DThwzhjNjXi AfZwvHwPmtDW+iICSvMlV50sbz7wtbLpB74jdz3xovi62gHPY/BM5uSB339fTrkyNOJpM6QzgBs8 05o1a6vtQwVEvvXpc+XBVVjnUJClT/5T/vjHO2W5Fyile+bUGhzOPeY7csfTfRVZIjl5/K6LZeFb PyH31kgd/mKk9q+55i5ZWVl2kZI93/mlGmG3/eAYOfaH18qzK/IVY4MZHHKrXpJ/3n6ZfPp982X+ /I/Kw9nYsGdH1AidhBdmaLChB+8h13AZj4kKeWj0RJGlXBIgARIgARIgARIgARIgARIgARIgARJo QQJhY0IsCkVu0Emo4SL6AY/EcLkWHEZLdsmMDKbYxEzqQgEH1mKWNbZTwqoSnNMdrHyw8i05mHXY KTMoIEymNw5avv6H8l71ItvK2961s0wrDchdl/5BHq3r11c+ub+kdBVCQY0Vxn32/F1kvparlF18 thw0/+xQzYPlLy+9TrZNeJJ81UI5RnN+Ucm9Uo59w5XyhnecIDtOz8tff3yB/K2SN7rIaNq/84Xd ZUsdLwwJHVsdJud84Nfy0QserzRwz08/Iweol233kMN33UJkYKk8/PD1sji0uAMrHCKptDubAnLC HCuCJmEE7xeeBaxiCFYywLgnbrWK50X1/UtIUb/37P3jd11zHxKucGguT0ojARIgARIgARIgARIg ARIgARIgARIggZYmYEo2dLKkijmniXMX+gHrAzyMDnRNIaA03SHGOMg4EdMDjNWbYrwpDaxnQjq6 O+tGtFiuuOQSuWAIY8OhX/ytvO8102t4OuXx9AVy6nEwOazdue12klvIR//wnTUK3vzrn8gP6owN +75515pyBbwrdW4s7VcNBHHZ88Rfyg8+vG+dNL1c/Be5/KKL5PLL640NKNolncnA0IArKs5BIXD2 PaemU0knIpJJqnFH/+GaX3BGaWJCGhwmhiulkgAJkAAJkAAJkAAJkAAJkAAJkAAJkEDLEahXdJd0 1j28c9DD6YoH59fUo7bcWFq5Q8YZIVaRzJudlq03SMvmMzKyydSUxHQZSbhMK49lIvtmDMIrPuYe ebr844/nyvvfUrstUrgfW+/3Hvnhb26R77x7B7cfv9VHGcjUY6dlr5N/JWedXHM4QlXEkfvLrETO zX7HKpTO+YfKPTf9So7db+tqmXDsde+QMy7+s/zgW1+Wd1XSOyTu2qokVA50HrH9ow6QDTPl906r 4zyGZHKq7Hf8mXLzr8+S4w/ZrSp0iNj2ex0pX/vBpfLAs+fIa7rilS2VzIAxRJVJmYRnIRWPyIK5 XbJwXrf0pKOS1GNqaJiZ2MchouBps55YxpROAiRAAiRAAiRAAiRAAiRAAiRAAiRAAi1BAMpVKGez 2awUB3slv/gmia7+r0x/8DcSyfdLvnuO+N0byKr9viiRKRtIT0+PO6g2mUy6/lNRt/bbaGo2O5AW hxx7uofSi6sGdSuloiTU+BDXlQ4zejKSiMdUyZx0ys+4nlMwGZ3xCm+BgzgOa0ZebtUyWbpiuaxc 0Sd5vfZKMemZNk26dMY6HA6ZxkHKXV1dTumONNTv6+tzxgQc+Cy51dK7OicDmt4xZYbMnDFDZk/v cfLRDt6J1atXu3q4b/nBFbJqZa/k/KjE4xnpnrWBzOpOOHmDg4NS0vKoF+volg1mTtMyceno6HD3 EbIgY8WKFWttf86MKeiqk4Py1l88L3A4LLvoDcrgQL+s7Mu5MUYiSe1/j8yaOVO6M4nKc4OtlNAH vJv2HE3W99SeJ/ueA89cviBPvdyv91tkQzX2pZJx6cpklKmuONLnBw4M6ZpHYHJ+mzWPHyWRAAmQ AAmQAAmQAAmQAAmQAAmQAAmQQNsSiKoWDr7iIpj+q55uXARM4euUwbGSzOhMOoU2dnMJ0nRzl9Ce ++NqbD2oDEUxPBT5ZnBA6MVS0jN9jnRPmx0YIFSBjHJQ0sOZwQGKduOJekjHNQwOpWS3TNtwuszQ ayjyoWh2hgitj7KQh7JwUFQn0lNl483mOAU+jBmWbmVVgHR0dzsjAOqZxz1HHPJgSEIf69vPOEV3 zOVZeci3/lobCCPxtEyZoX2fVX1WID+iB1/ncsVKn5Fm/UTbcPb8uYtJ+mEMsIXZxmpoAJtMKjBQ Rd3ZNTynZqIeDRocJoos5ZIACZAACZAACZAACZAACZAACZAACZBACxNQFW+ld4ibgs4lDrE3faUw I6MmYEpld26DKobhLK2G96glrv8FoRg2D6W9KdEtNIYIw8p+8DRvin9jbPKcIl/LmSzkOyV+ua7V s3wLjTry4axeON3asjy0hfJmRICs4dq3dmE4QBlzqBOuZ+lW3vqH0Nq3Mgyr9ykZD+5bYGigQWai nw0aHCaaMOWTAAmQAAmQAAmQAAmQAAmQAAmQAAmQQKsSKOHQ6KqCE7HqVat2unX7ZUpfhKZ4RogZ 76YcDqebArt1R7RuewZG8DA0wJuyHisPzIEfzjxAGKxYCLamMpaog3zUt611UBflww7XUPCjHuSg POKm8Ec+4gjhkQe5cLayAvcVMqwMrlHH0uvbt/EhRB1bmdDZ2VnTPlZ6wBkHG1u4LauLcpAVDt3F JPwwDuAFxvbeWbrxs3ASIlonQ6bBYZ1gZiMkQAIkQAIkQAIkQAIkQAIkQAIkQAIk0HoEoKYMq2Gh mDPlXOv1tv16BJaq95SCWnGKRSiZsT2OKprBvawkbr9RTXyP7Tk0RhaGFe+Imw8rkFHWFM7YagkG ADMcID0sG3Eopm1LJij4LQ2jRPmwCxsKkId24c1ZeYQmd23tW3nUR7s2DvQH9VE37Or7Hs5jvJYA WMEVlWPWCwxZmbTer3J6bWleNZMADQ7NpElZJEACJEACJEACJEACJEACJEACJEACJNAGBKDMhCbc 9wtSUm9Gh5Ke3wBvis02GEpLdtGUnVAgF4q+PPlyVg+P1pnvcZ2dn4jJ3FldqlwOlN8tOYB11Cnj ZAp6rCAw4wBCU7y757XcJ9QxAwHKo64p6lEEZbFiwOojhCEBDmXhUQ9yrF2sWEA9mxGPOrhGGeuj lYcca8/aR3+Qj3oIR2rfzmxAPXOoa/3BCge0b97KQDa8jR/9RR3rj5Wb7CGYwCHMekX5+9O9zvCw cO506UhpXpkjWNI1n0D1qW6+bEokARIgARIgARIgARIgARIgARIgARIgARJoUQJOoap9g8oN8bDD FVVxYSKNx8FyIKcH/Xq+dKbLiuk63o1LX39qmvIXoSnQTeEOZTwc8uBNwW/lLN1omMIZ5dxzXlYs W3nko46Vs3bM8GBbOKEMnJWzelY3fI1y9eXX1n64LtrHNfqHsdb3A7LhrI6Nw8Igl5/1BHA/dGGR rB70lGtJPPXuSeIXXD2qpl7T4NBUnBRGAiRAAiRAAiRAAiRAAiRAAiRAAiRAAu1DANuLRMtKVahW o7rlT0k9jQ3NuYdQJBd0ZcPyfk8G875k80VndPBV8Yk8uoCAKeqhoIfDNfhgBQFCY4V0K4vQykMR H3ZWBgp5q4vQ6odD1DPDgLUVNnAg38qHZSAd8uEabd/qOyH6Yf2t74flWz9wjbjVtxBpdFUDKjjm C748/dKA+GrIee1cT1cZRXWVg9vUjKgmiAANDhMElmJJgARIgARIgARIgARIgARIgARIgARIoOUJ qEJONbJBN6GsRBSeisum3DooPIt6KHfBD7wuctB4rXK8KQ2tJ0JMYW4KfCj+LS08RMsfKg/lLN3K mZz6dLu2OvXlrE0rZ/Ls2kIrZ6GlW/l6uZZu5S1EPfj68pZvodW3diydYS0BM9x4+v4FRj5slYU1 DjTM1JJq7hUNDs3lSWkkQAIkQAIkQAIkQAIkQAIkQAIkQAIk0BYEoHIrFPUMB/VO/aaGBl8PNIZ3 Roe2GEVrdhKKTjgojuF9XeXg60zromri3LWem4FjBag4Du6fKc7rwyAXNrGAp+Vbev21pduMf+Nr 6fWh1Tf5Vs+uLb++nl0Pl29yRtu+ybPy1r6Fll/fXv21lZusofFCCI+zO+CD9xDGv8C7LbNCZ6iQ Y3OfGBocmsuT0kiABEiABEiABEiABEiABEiABEiABEigjQhAkRsoc4NOw/TgzA9tNIbW7KopP8Ez UICin+F4oEinsnPk+7euGa3r9oYj0Cr9GK5/rZ5uBj/rpxki7JrhxBCgwWFiuFIqCZAACZAACZAA CZAACZAACZAACZAACbQsAVO8RXXGL7y5CM5vcL66V77lMRyZgBkZjC9mUhcKOLAWs6x93U4JWypV Vz5Y+ZElT64SzVK0j1bOaMuN9S40KrfRemPt3/paHoYGvFu2wgFfcfCe56mP6ruYkCIWcpW/+8i7 uU8CDQ7N5UlpJEACJEACJEACJEACJEACJEACJEACJNAWBHTTEbeWAesZEIeD4g0eV1zn4JCM+wMc E7p9SyFW0lAPOlZvBolxC6cAEiCBIQlUjAn6TZZO6LkY+qUW1X/6Daflg++7ISsycdwEaHAYN0IK IAESIAESIAESIAESIAESIAESIAESIIH2JIADVINDVIP+6xG9Ak83PgJmUEAY0zMx5s1Oi6dLGxKx mCTjUYlFgj3mTSk6vtZYmwRIYCgCeL9S8YjsunmXMzH0pKOSjAWG1aHKM605BGhwaA5HSiEBEiAB EiABEiABEiABEiABEiABEiCBtiIQnueLuC5sqLhwvJLISEMEcAZ3OhEVtTNIQi+wwoFbuDSEkpVI YEwE8J7B4NeTSbgtleJqbIjqe8gFDmPCOObCNDiMGRkrkAAJkAAJkAAJkAAJkAAJkAAJkAAJkMB6 QkBXOAi8c9hKKea8bahkWyytJ6NdZ8Mwg0JUtZtx3UppRmdS941Xzmp8CNJ0cxfNI991dkvY0CQj YO8gDHybTEu5bcwyqYTEdJVRVI0QfPcm7oGgwWHi2FIyCZAACZAACZAACZAACZAACZAACZAACbQ0 Adv6B520cxwsHlrw0NJjaOXOQakZGBjUmOOmVgfbuZixoZX7zr6RQLsTsPcP25jBBYaG4B1s97G1 cv9pcGjlu8O+kQAJkAAJkAAJkAAJkAAJkAAJkAAJkMAEEDBDA9RwgSouaISzfscHG/zgjKMZFpLJ pJthbXmWjpCOBEigOQTs/cN7he84e+8sHasbELewOa1SSj0BfqvVE+E1CZAACZAACZAACZAACZAA CZAACZAACUxGAiVd5aDKOHj3r6w8n4womjXmQNEZkYLupuT5JQ0j4peqRolmtUM5JEACtQTMyFBU w0PWK8lgvqjvHlZyce1WLanmX3GFQ/OZUiIJkAAJkAAJkAAJkAAJkAAJkAAJkAAJtBQBzPYNO1PG WVoxGhf9TySmH+rr860cw9ERMH6YSV0o+vLky1nx1OqQjEcklYjJ3FldOss6OMNhdBJZigRIYLQE bOUQwqxXlL8/3SswPCycO106Ujr/HkbVsh+tTJYbPQEaHEbPiiVJgARIgARIgARIgARIgARIgARI gARIYP0hENFtR5KdUkx1i9cxSyLFgvjpaVJKT9VVDqoM15Ga4nz9GfS6HwlMPQO5guQ8XzrTgTEH yk86EiCBiSWA76+ivmqrBz09tL0knnpdbIRlDvrlNrFtT2bpNDhM5rvPsZMACZAACZAACZAACZAA CZAACZAACUxKApj566uxoXfTPaSQz0l2zu7KoSTxVIfEkynpzkyp7HNOo0PjjwhWlhR0ZcPyfk+3 dPElq9u6wOjgq+KzftVJ462wJgmQQJiAvVsI8wVfnn5pQN+5orx2rqerjKK6yiGmxWlxCDNrZpwG h2bSpCwSIAESIAESIAESIAESIAESIAESIAESaHECZkCI4GDVZJcUIynxuxJOAR5LpaQU11n40eBw 1RYfSst3DwrPYqkoBT/wushB4zxSteVvHDu4XhDA+wfv6fsXGPmKeo01DjQ2TOQNpsFhIulSNgmQ AAmQAAmQAAmQAAmQAAmQAAmQAAm0AIGKkaF8EDTOFoDLZDKSTCbF9jxPJBJuZQPSUAbe6rbAMNqm C1BywhV1VjW8r6scfJ1pXVRNnLv2dfsqNT4YdzJum1vLjrYwAXvvzNDg60sGH7yHMP4FvlAo6Fk1 1TNU+P4196bS4NBcnpRGAiRAAiRAAiRAAiRAAiRAAiRAAiRAAi1PwBTdCKGcg4EBYVxXN8DIgHQr 0/KDadEOmvITs6kDBSg6Go7rJlbKnMrOFr2B7FbbEzCDnw0keA95forxmKiQBoeJIku5JEACJEAC JEACJEACJEACJEACJEACJNBiBMyIAEUc4h0dHeUZ9zrdXp0ZGrDSAYpwWwlBpfjobqQZGUyxiZnU hQIOrMUsa1+3U8KWStWVD1Z+dNJZigRIYDQE8P2Gd8tWOGhUr0U8z1Mf1XcxoVvJBQY/yOP322io jr4MDQ6jZ8WSJEACJEACJEACJEACJEACJEACJEACJLBeEDAFm61msEHZFkrItzKWx7AxAtgtPqHb txRiJQ0jEldvBonGJLIWCZDASATMmKffZJJORHQ7JTWo6j9cq6lhpOrMHwcBGhzGAY9VSYAESIAE SIAESIAESIAESIAESIAESOD/t3c3PY5j1wFAH/VRqh73eDyJ4wAO4AT5WATO0vv8kPzVIMvsA2SR AEFWsRPvxjPt6S5JJHMvpVel0vR0ldRVJVF13uAVJZEUyUOxB+DlfXdMAjWIkEMnZasZD5nRkK3O l9kwcBz9pwYUcjqdNOWvf3FdVpHaMI/hqq5mkzJtNsVs603RozdkRQIEfiCwe/0tZk35zV+9HUIM P72elKsoX1P/nfvBij54EgEBhydh9CUECBAgQIAAAQIECBAgQIAAgfEJ7N94238/viM6vz2OeEM8 YT0pEWco83iTAYhVG8WkSwy31Ofdz1JmmxGthp2fRHZJZkHkNJetbRgSJgvgxosuxoOJkEWdZT0u fi95ReRFEm21iqLQ8bqN6yw/++mbeb6N6yqDrLHA/UtnWMefpxNoAh3x03n6JgIECBAgQIAAAQIE CBAgQIAAgVcqUG+z1THkl8vlMI78+w/LCBJ0Q3BhHZP/+7Yty7Yv332I4EHcmquBnogxRAbEtPzd L9+WN1ez8lXcKK1Bh5tVW/7r9+/K++W6fPMu6kLEevWunvW4+L3cXQ95HeYwZr/603kE+SLQUNoI yJSymM9KZnddXy+G7K79zK5X+s/Wkx+2DIcnJ/WFBAgQIECAAAECBAgQIECAAAECBDZDt+SwVUPd huHR6nzwuosMh758WHXl+5t1iZf3Ag5tDDa/jKjEfBqRib2WQYf3y+yRHRHL7QYcrMdl7+dSXuvv JQMOV5EltI7i0Bl4mDXtELibRTBvspM1tO/l/dMICDg8jaNvIUCAAAECBAgQIECAAAECBAiMVqA+ mV+ftB/tgZx4x6tfTrNnsCGnV1dXQ4ZDOrd9G30VPV53m4BD3e1cfp0RiByPJHobQwXFt0RgIYeH acs66kAMva0Bh1xwU4vDemHDxe9luCLi2snrb9vz+ptF4CFr0wwBwMhyqNfqdnGTJxQQcHhCTF9F gAABAgQIECBAgAABAgQIEBiNQNzELu2y9DHUT9Otht3uJvPS5E3y6VU+dj+aQznXHa03NWvgYb2O seWjLebTYUik6+00P6vL5rwsKp1VGupnOT9bFpxuu0lZxHSW563JAek3zXpc/F42wbm8InJosqyb koGGJq6nbBlw2DcaZvjzpAJqODwppy8jQIAAAQIECBAgQIAAAQIECJy/wFBPYH1Tyu/+vZSbd6V8 89theJ7pn/1l3A1/W7pf/H1p5gs35448lTVjpE5Xq9WQpZDuWcj2Q9Z2iNc3MaRSDIx0u5UcX34a AZ/rxTxulE7LVYw5nzdINxkOm/XWkenw4UN8X/6XQaNo1ltGdgMXv5e7wEJmNyyiDkpeT4ur+W22 UV5Pajfc/pPzLC9kODwLqy8lQIAAAQIECBAgQIAAAQIECJy5QNQSKO//sOl/+F08UV9K9+bLHMcn Xv+wfsCZH81Z797uU9WZOJJPX/d9PHndtbHfd5kks3gke7ghGk9l7481n+9n0WNOaa42T3LfBRys x+Xud5QXw2v+vUyHrIa4XrbTmmGU19butXjW/2iMeOcEHEZ88uw6AQIECBAgQIAAAQIECBAgQOAQ gXqDehja5/0fS/M//1ZKBBvm//2vwxBKq7/9x1K++mXp//zX8bUzTwIfgruzbL2pWac5lEu1z8+y HkO2Or/O2/kKLwkQOFIgr6vsGWjYDTZkJlC2et0d+fVWe0BAwOEBILMJECBAgAABAgQIECBAgAAB ApcmkDe4+3i6frJ8H0MqfV/6D9/GIcZNutWHUmKopaFY8Xa4nks79lMdT73JWW+G5jnIm6G7wYY6 r05/bF/rd9X5dfk6rZ/vT623L7J5z+WyXR66Lj5+9D49VkDA4Vg56xEgQIAAAQIECBAgQIAAAQIE RiJQb2pnDYF8nRkOffT5elmadlMwOkf2Wa2jNsAqC0nHsErxFP4QeIgnhfMJfe14gQwsZKsBhsVi cXse8vN6furT2HVan8jO+dmttxk6isumVkH9ndQpl0+7pJP2/AICDs9vbAsECBAgQIAAAQIECBAg QIAAgbMSGAIPEVDooo5Dk7Uc4mZ2Zjjk3+xdFDZuIjihPa1AfdK6DqlUh1raDzjU5Xa3vvsUvvXu ZLhshg/adUid3fd+L3e/F6+eX0DA4fmNbYEAAQIECBAgQIAAAQIECBAgcBYCGWjInje8+6wjsFyW yWpVFtu9a9cRhFhF9kPMywyHXDafCq43xHdvYp7FAY1kJ6pbzRSp76vr/mHUJ7HrcnV+fW+9+wWS uWye3K8Ofi8bgR+7jqqP6fMICDg8j6tvJUCAAAECBAgQIECAAAECBAicrUDesM7shrwxlLduY8Ce e/vaxfzJkPVw72Nvnkhg/8bwY7/Weh+X4sLl4wI+PYWAgMMp1G2TAAECBAgQIECAAAECBAgQIHAC gQw0DMGGbaZDpDqUoW/3JQZSKkOP+ZHeMCz7Y0/Tn2D3R7/JemO8Tg89IOt9XIwLl48L+PSjoPxh AAANp0lEQVQUAiplnELdNgkQIECAAAECBAgQIECAAAECJxYYMhu2AYj7A9SceMdsngABAgRGKyDg MNpTZ8cJECBAgAABAgQIECBAgAABAscJ1EyHSGOIL7grDh0DKcXgSm4XHadqLQIECBDwfxC/AQIE CBAgQIAAAQIECBAgQIDAKxTIoENmNtRMhyTISg73qznkpxoBAgQIEHicgIDD45wsRYAAAQIECBAg QIAAAQIECBC4GIGa4dBH4ejs2TLQMG0mQxd0GEj8IUCAAIEDBQQcDgSzOAECBAgQIECAAAECBAgQ IEDgUgRqhkMez5DpENMMNuRrjQABAgQIHCog4HComOUJECBAgAABAgQIECBAgAABAhcgMAQYurb0 0YcAQ9OUdttLTDUCBAgQIHCogIDDoWKWJ0CAAAECBAgQIECAAAECBAhcjEDmM2wHUIqaDkOgIYMN +VojQIAAAQIHCgg4HAhmcQIECBAgQIAAAQIECBAgQIDAJQhkHYe8MZQ9X2ebNNOhD2/8IUCAAAEC BwoIOBwIZnECBAgQIECAAAECBAgQIECAwJgFanAhx1HquiwanZkN29oNkd3QRJffMOYzbN8JECBw OgEBh9PZ2zIBAgQIECBAgAABAgQIECBA4MUFMqBQ2yRCC03f1bel65uh5zK7y90u4AUBAgQIEPiE wOwT88wiQIAAAQIECBAgQIAAAQIECBC4MIGa4ZBhh93Xu4WiBRsu7KQ7HAIECLyQgAyHF4K2GQIE CBAgQIAAAQIECBAgQIDAuQn0OaRS9Ns2nZaSXSNAgAABAkcICDgcgWYVAgQIECBAgAABAgQIECBA gMD4BbJwQ1RrGApG36/boIbD+M+uIyBAgMApBAQcTqFumwQIECBAgAABAgQIECBAgACBEwv0Ubuh JjTk62xNmQz9xLtm8wQIECAwUgEBh5GeOLtNgAABAgQIECBAgAABAgQIEPg8gfsZDlE/OiIO8Vl2 KQ6fR2ttAgQIvFIBRaNf6Yl32AQIECBAgAABAgQIECBAgMDrFRiKRcdQSl3XliZ7UkSgoY0XXfTp JDId4v1uf71ajpwAAQIEHisgw+GxUpYjQIAAAQIECBAgQIAAAQIECFyYQAYahmDD7XH98JPbWV4Q IECAAIEHBGQ4PABkNgECBAgQIECAAAECBAgQIEDgYgW6qN2QPVqOojRp4tnU6EZUGkj8IUCAAIED BWQ4HAhmcQIECBAgQIAAAQIECBAgQIDAJQj0EVao+Qz5emi1hsMlHKBjIECAAIEXFxBweHFyGyRA gAABAgQIECBAgAABAgQInEYgazcM9RtuN5+Bhrt8hi5CENk1AgQIECBwjIAhlY5Rsw4BAgQIECBA gAABAgQIECBAYOQCGVbIzIb8bwgxRHZDDT9ksWiNAAECBAgcKiDgcKiY5QkQIECAAAECBAgQIECA AAECFyLQRP2G7LVNJtMo5DAtGXAQdKgqpgQIECDwWAFDKj1WynIECBAgQIAAAQIECBAgQIAAgQsW uBtYaXeQpQs+YIdGgAABAk8uIODw5KS+kAABAgQIECBAgAABAgQIECBw3gK1lsOmYsNdhkMOrrQd YOm8D8DeESBAgMBZCgg4nOVpsVMECBAgQIAAAQIECBAgQIAAgecXqDUbhi3lm6zdkH033eH5d8MW CBAgQOBCBNRwuJAT6TAIECBAgAABAgQIECBAgAABAo8VGOozZJ2G6VX0Reli2s0WpUzn0WelmUzU cHgspuUIECBA4FZAwOGWwgsCBAgQIECAAAECBAgQIECAwOsQyIBDH8Wh2+uflb5dlW69Kv38Temu flLK/ItNlkNQKBz9On4PjpIAAQJPJSDg8FSSvocAAQIECBAgQIAAAQIECBAgcOYCGUCYRPZCtvbq y/K///BPZb28Kd3yQ2Q1TMviq5+X+eK6fBlZD9lyeUGHgcIfAgQIEHiEgIDDI5AsQoAAAQIECBAg QIAAAQIECBC4JIEMOkxm89K/+ToyG9ZlfbUaAgvX129LM58bUumSTrZjIUCAwAsKCDi8ILZNESBA gAABAgQIECBAgAABAgROKVCzG+YRVMjXb97EMEpdV9q2HXYr30+n03J1dTVMZTic8mzZNgECBMYn IOAwvnNmjwkQIECAAAECBAgQIECAAAECRwvUIEJOM/CQAYf6WQYbhuwHRaOP9rUiAQIEXrOAgMNr PvuOnQABAgQIECBAgAABAgQIEHgVAhlQyJbBhL7vhwyGnObnOc2erWY+ZOAh59WMiGGmPwQIECBA 4AEBAYcHgMwmQIAAAQIECBAgQIAAAQIECFySQA0+5DHNZrMh2JBZDtlqoCGX2V1umOkPAQIECBB4 QKCJCPYmhP3AgmYTIECAAAECBAgQIECAAAECBAhchkANMNRpvT1UgwwZeMhW31/GUTsKAgQIEHhu ARkOzy3s+wkQIECAAAECBAgQIECAAAECZyqwH1DYf3+mu223CBAgQOBMBWQ4nOmJsVsECBAgQIAA AQIECBAgQIAAAQIECBAgQGBMApMx7ax9JUCAAAECBAgQIECAAAECBAgQIECAAAECBM5TQMDhPM+L vSJAgAABAgQIECBAgAABAgQIvJhA1nCodRxebKM2RIAAAQIXJ6CGw8WdUgdEgAABAgQIECBAgAAB AgQIEHiEQAQZyvJdKV0XCzdZIbqU2aKUSTyfOnHL6BGCFiFAgACBPQH/99gD8ZYAAQIECBAgQIAA AQIECBAgcKkCNYthmN5EsOE//rmUm+9K07elzN+U7le/KWXxZWne/jyCDtOIQUQQQiNAgAABAo8U EHB4JJTFCBAgQIAAAQIECBAgQIAAAQKXIjAModSuy/S735f++2/isNalWfykdDfvSzONLIcS2Q8a AQIECBA4UEDA4UAwixMgQIAAAQIECBAgQIAAAQIExipQMxzW63UEGr4ts//8l9J889vSL9+X/ouv S/f135TS/kUpX/xJaeZNmU6nw6HKdBjrGbffBAgQeFkBAYeX9bY1AgQIECBAgAABAgQIECBAgMBJ BYbshqzf0Helex/DKX14V5rVH0sfQyj1kfVQsmddh1xGI0CAAAECBwgIOByAZVECBAgQIECAAAEC BAgQIECAwBgFamZD27YRS+jKcrks/c1NmUdQIas0DPOjXsNytSol+iw/j+XqejIcxnjW7TMBAgRe XmDy8pu0RQIECBAgQIAAAQIECBAgQIAAgVMKZNCh3wYUMqhQgw75eQYlaqChTk+5r7ZNgAABAuMR kOEwnnNlTwkQIECAAAECBAgQIECAAAECnyVQAwqrbSZD30ZGQxdDKEXL4ELX9jGsUh9JDqsyncxv azh81katTIAAAQKvRkCGw6s51Q6UAAECBAgQIECAAAECBAgQeM0Cu9kKQ4ZDlnHY/leGHIeIPWTQ IbpGgAABAgSOEZDhcIyadQgQIECAAAECBAgQIECAAAECIxPYrcOQwyaVdWQxxDFkz9BDtvV2qKWs 4bAboBhm+kOAAAECBB4QkOHwAJDZBAgQIECAAAECBAgQIECAAIFLENgNIOy+3j22DDvIb9gV8ZoA AQIEDhGQ4XCIlmUJECBAgAABAgQIECBAgAABAhcgMAQchiyGLBDdbopGx3FN4r9+6BdwkA6BAAEC BF5cQIbDi5PbIAECBAgQIECAAAECBAgQIEDgPASa2I3s2XLIpZrhsDv80mauvwQIECBA4GEBGQ4P G1mCAAECBAgQIECAAAECBAgQIHCZAl3Ucsi+bV2EH/rbEET91JQAAQIECDxOQMDhcU6WIkCAAAEC BAgQIECAAAECBAhctkCkNwyZDZHpoJDDZZ9qR0eAAIHnEjCk0nPJ+l4CBAgQIECAAAECBAgQIECA wJkKNFG/Ifu9lmMrTaebvh1nKQMQhle6p+QNAQIECHxCQIbDJ3DMIkCAAAECBAgQIECAAAECBAhc msBQMHp7UPdf32U47MciLs3A8RAgQIDA8wgIODyPq28lQIAAAQIECBAgQIAAAQIECJytwKRktYbu 3v5lJkMfH2WfTCYyG+7peEOAAAECjxEwpNJjlCxDgAABAgQIECBAgAABAgQIELgkgUxh+FgaQ9Zv yK4RIECAAIEjBGQ4HIFmFQIECBAgQIAAAQIECBAgQIDAGAWGIZQi0NCVNjIcsu+1SdRwyK4RIECA AIEjBGQ4HIFmFQIECBAgQIAAAQIECBAgQIDAqAVkOIz69Nl5AgQInKuADIdzPTP2iwABAgQIECBA gAABAgQIECDwDAKZ5TDbjpx0r2h0bCvrOOSQSjHgkkaAAAECBA4WkOFwMJkVCBAgQIAAAQIECBAg QIAAAQJjF8iQwv2wwlA0evvpEHgY+yHafwIECBB4cQEZDi9OboMECBAgQIAAAQIECBAgQIAAgdMJ ZN2Gdh31G7Lv70YT9RuyawQIECBA4AgBGQ5HoFmFAAECBAgQIECAAAECBAgQIDBagYwy1BoOuxGH SHi4zXu4n/ww2kO14wQIECDwsgIyHF7W29YIECBAgAABAgQIECBAgAABAicXmDZ9lGq4H1XId9PZ tPTRs46DYZVOfprsAAECBEYnIOAwulNmhwkQIECAAAECBAgQIECAAAECnymwTWXoposYQWkRAYbI bphfR4ZDFowWbPhMXasTIEDg1Qr8P4urLf4vv+FQAAAAAElFTkSuQmCC --_004_D20147B2D28DEkwatsenjunipernet_-- From nobody Tue Aug 25 01:12:49 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F691A0020 for ; Tue, 25 Aug 2015 01:12:48 -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 t86ogmA6KKJd for ; Tue, 25 Aug 2015 01:12:46 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55AE21B2A20 for ; Tue, 25 Aug 2015 01:12:46 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 20F5112AF for ; Tue, 25 Aug 2015 10:12:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Tx6I-ZoEkRsQ for ; Tue, 25 Aug 2015 10:12: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 for ; Tue, 25 Aug 2015 10:12:44 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id D830120063 for ; Tue, 25 Aug 2015 10:12:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id KXSZviHUFHEr; Tue, 25 Aug 2015 10:12: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 7218720062; Tue, 25 Aug 2015 10:12:42 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A248836584E8; Tue, 25 Aug 2015 10:12:38 +0200 (CEST) Date: Tue, 25 Aug 2015 10:12:37 +0200 From: Juergen Schoenwaelder To: "netmod@ietf.org" Message-ID: <20150825081237.GD81550@elstar.local> Mail-Followup-To: "netmod@ietf.org" References: <9EB6F767-1643-4852-8B88-E79D72309E95@nic.cz> <7D38FB86-CFB2-4900-A727-A42DC1132F32@nic.cz> <20150824.210109.1638056143186576784.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: Subject: Re: [netmod] Y26 again, sorry X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 08:12:48 -0000 On Mon, Aug 24, 2015 at 12:24:47PM -0700, Andy Bierman wrote: > > The problem is there is no cookie-cutter formula for a safe "when" > statement. The common use-case is pick-an-identity from iana-if-type. > Clearly we do not intend for a server to support every interface type > just because it advertises the iana-if-types module. Also, we > cannot assume the client knows about module A just because it > knows about iana-if-type. > It might help if we go back to the issues list and the meeting documentation. It seems we are redoing a discussion we already had. 2014-07-09 meeting action: There is agreement that the current text is overly restrictive. The proposal is to add general guiding rules that backwards compatibility needs to be maintained. Lets see whether someone can write more concrete rules when mandatory nodes in augment are allowed. 2015-03-23 ietf 92 meeting: The opinion after discussion at the meeting was leaning towards Y26-02. See the meeting minutes and recordings for more details. Are there any fundamentally new insights that should change the conclusion of the IETF 92 meeting (which was verified on the mailing list in April)? Has someone meanwhile managed to produce text that clearly defines when mandatory nodes in augments are 'safe' in the sense that they do not break clients that are not aware of the augmentation? If not, we should perhaps not waste cycles rehashing an old and closed issue. /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 Aug 25 04:04:05 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D53C21ACE59 for ; Tue, 25 Aug 2015 04:04:03 -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_64=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 3IL2cRxRG-km for ; Tue, 25 Aug 2015 04:04:00 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6A94B1ACE1A for ; Tue, 25 Aug 2015 04:04:00 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 3C3FE1AE0486; Tue, 25 Aug 2015 13:03:58 +0200 (CEST) Date: Tue, 25 Aug 2015 13:03:59 +0200 (CEST) Message-Id: <20150825.130359.1125823029773095202.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] LL review of 6020bis-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 11:04:04 -0000 SGkgTGFkYSwNCg0KVGhhbmsgeW91IGZvciB0aGlzIGV4dGVuc2l2ZSByZXZpZXchICBDb21tZW50 cyBpbmxpbmUuDQoNCkxhZGlzbGF2IExob3RrYSA8bGhvdGthQG5pYy5jej4gd3JvdGU6DQo+IEhp LA0KPiANCj4gdGhpcyB0aW1lIEkgcmV2aWV3ZWQgdGhlIGNvbXBsZXRlIHRleHQgc28gbXkgY29t bWVudHMgYXJlbid0IGxpbWl0ZWQgdG8NCj4gWUFORyAxLjEgc3R1ZmYuDQo+IA0KPiBMYWRhDQo+ IA0KPiAqKioqIEdlbmVyYWwgY29tbWVudHMNCj4gICAgICAxLiBXb3VsZCBpdCBtYWtlIHNlbnNl IHRvIGF0IGxlYXN0IG1lbnRpb24gdGhhdCBZQU5HIGlzIGJlaW5nDQo+ICAgICAgICAgdXNlZCBu b3Qgb25seSBmb3IgTkVUQ09ORiBhbmQgd2l0aCBvdGhlciBlbmNvZGluZ3M/DQoNCkkgdGhpbmsg c28gKGFuZCBJIHRoaW5rIHRoYXQgd2FzIHRoZSBnZW5lcmFsIGNvbnNlbnN1cyBpbiBQcmFndWUp DQpEZXRhaWxzIFRCRC4NCg0KPiAgICAgIDIuIEkgdGhpbmsgaXQgd291bGQgYmUgdXNlZnVsIHRv IGluY2x1ZGUgdGV4dCAocGVyaGFwcyBpbg0KPiAgICAgICAgIHNlYy4gNC4yLjIpIGRlc2NyaWJp bmcgdGhlIHNjaGVtYSB0cmVlIGFuZCBkYXRhIHRyZWUsIGFuZA0KPiAgICAgICAgIGludHJvZHVj aW5nIGFwcHJvcHJpYXRlIHRlcm1zIHNvIHRoYXQsIGUuZy4sIG5vZGVzIGluIGVpdGhlcg0KPiAg ICAgICAgIHRyZWUgY2FuIGJlIGNsZWFybHkgZGlzdGluZ3Vpc2hlZCBpbiB0aGUgc3Vic2VxdWVu dCB0ZXh0LiBJbg0KPiAgICAgICAgIG15IGV4cGVyaWVuY2UsIHRoaXMgY2F1c2VzIGEgbG90IG9m IGNvbmZ1c2lvbi4NCj4gDQo+IAlGb3IgZXhhbXBsZSwgc2VjLiA0LjIuMi4xIHNheXM6ICcgQSBs ZWFmIG5vZGUgY29udGFpbnMgc2ltcGxlDQo+ICAgICAgICAgZGF0YSBsaWtlIGFuIGludGVnZXIg b3IgYSBzdHJpbmcuJyBBbmQgdGhlbiBzZWMuIDcuNjogJyBUaGUNCj4gICAgICAgICAibGVhZiIg c3RhdGVtZW50IGlzIHVzZWQgdG8gZGVmaW5lIGEgbGVhZiBub2RlIGluIHRoZSBzY2hlbWENCj4g ICAgICAgICB0cmVlLicgSWYgdGhlIGxlYWYgbm9kZSBpcyBpbiB0aGUgc2NoZW1hIHRyZWUsIHRo ZW4gaXQgY2Fubm90DQo+ICAgICAgICAgY29udGFpbiBhbnkgdmFsdWUuDQoNClRoZSAibGVhZiIg c3RhdGVtZW50IGRlZmluZXMgYSBub2RlIGluIHRoZSBzY2hlbWEgdHJlZS4gIFRoaXMgY2FuIGJl DQppbnN0YW50aWF0ZWQgaW4gYSBkYXRhIHRyZWUuICBBIGxlYWYgbm9kZSBpbiB0aGUgZGF0YSB0 cmVlIGNvbnRhaW5zIGENCnNpbXBsZSB2YWx1ZS4NCg0KU2luY2Ugc2VjdGlvbiA0LjIgaXMgcmVh bGx5IGp1c3QgaW50ZW5kZWQgYXMgYW4gb3ZlcnZpZXcsIG1heWJlIHdlIGNhbg0Kcy9BIGxlYWYg bm9kZSBjb250YWlucy9BIGxlYWYgY29udGFpbnMvIChhbmQgc2ltaWxhciBmb3IgY29udGFpbmVy KT8NCg0KPiAgICAgIDMuIEl0J3MgbmVjZXNzYXJ5IHRvIGNsZWFybHkgc2VwYXJhdGUgcHJvcGVy dGllcyBvZiB0aGUgZGF0YSB0cmVlDQo+ICAgICAgICAgZnJvbSBwcm9wZXJ0aWVzIG9mIFhNTCBl bmNvZGluZy4gRm9yIGluc3RhbmNlLCBpdCBpcyBhbg0KPiAgICAgICAgIGluaGVyZW50IHByb3Bl cnR5IG9mIGEgY29udGFpbmVyIGluc3RhbmNlIGluIHRoZSBkYXRhIHRyZWUNCj4gICAgICAgICB0 aGF0IGl0cyBjaGlsZHJlbiBhcmUgdW5vcmRlcmVkLCBvciBvcmRlcmVkIGluIFJQQw0KPiAgICAg ICAgIGlucHV0L291dHB1dC4gWWV0IHRoaXMgaXMgb25seSBzcGVjaWZpZWQgaW4gc2VjLiA3LjUu NyAoWE1MDQo+ICAgICAgICAgTWFwcGluZyBSdWxlcykuDQoNCkkgdGhpbmsgdGhpcyBpcyBhIHBy b3BlcnR5IG9mIHRoZSBYTUwgZW5jb2RpbmcsIG5vdCBhbiBpbmhlcmVudA0KcHJvcGVydHkgb2Yg dGhlIGNvbnRhaW5lci4gIEluIEpTT04sIGFsbCBjaGlsZHJlbiBhcmUgYWx3YXlzDQp1bm9yZGVy ZWQuDQoNCj4gCVNpbWlsYXJseSwgdGhlIG5hbWVzcGFjZSBvZiBhIG1vZHVsZSBhbmQgWE1MIG5h bWVzcGFjZSB0aGF0J3MNCj4gICAgICAgICB1c2VkIGluIFhNTCBlbmNvZGluZyBhcmUgSU1PIHR3 byBkaWZmZXJlbnQgdGhpbmdzIChjZi4gc2VjDQo+ICAgICAgICAgNS4zKS4NCg0KWWVzLiAgRG8g eW91IGhhdmUgYW55IHNwZWNpZmljIGVkaXRzIGluIG1pbmQ/DQoNCj4gICAgICA0LiBUZXJtcyAi aW5zdGFuY2UiLyJpbnN0YW50aWF0ZSIvImluc3RhdGlhdGlvbiIgYXJlIHVzZWQgaW4gYQ0KPiAg ICAgICAgIGxvb3NlIHdheSB3aXRob3V0IGJlaW5nIHByb3Blcmx5IGRlZmluZWQsIHByb2JhYmx5 IGFzIFNOTVANCj4gICAgICAgICBsZWdhY3kuIFRoZSBYTUwgdGVybSAiaW5zdGFuY2UgZG9jdW1l bnQiIGFkZHMgeWV0IGFub3RoZXINCj4gICAgICAgICBtZWFuaW5nLg0KDQpJJ20gbm90IHN1cmUg dGhlc2UgYXJlIFNOTVAgc3BlY2lmaWMgdGVybXMuICBJIHRob3VnaHQgdGhleSB3ZXJlIG1vcmUN CmdlbmVyaWMuICBEbyB5b3UgaGF2ZSBhbnkgcHJvcG9zZWQgZWRpdHM/DQoNCj4gICAgICA1LiBB IHRlcm0gaXMgbmVlZGVkIGZvciBkZXNjcmliaW5nIGEgZGF0YSBtb2RlbCBvZiBhIHBhcnRpY3Vs YXINCj4gICAgICAgICBzZXJ2ZXIsIGkuZS4gYSBjb2xsZWN0aW9uIG9mIG1vZHVsZXMgKyBzdXBw b3J0ZWQgZmVhdHVyZXMgKCsNCj4gICAgICAgICBkZXZpYXRpb25zKS4gSSd2ZSB1c2VkICJkYXRh IG1vZGVsIiwgc2VlDQo+ICAgICAgICAgaHR0cHM6Ly9naXRodWIuY29tL21iajQ2NjgvcHlhbmcv d2lraS9UdXRvcmlhbCN5YW5nLWRhdGEtbW9kZWwNCg0KVGhlIHRlcm0gImRhdGEgbW9kZWwiIGlz IGFscmVhZHkgdXNlZCBpbiBhIG11Y2ggbW9yZSBnZW5lcmljIHdheSBpbg0KNjAyMC4NCg0KInNl cnZlciBZQU5HIGRhdGEgbW9kZWwiIG1heWJlLg0KDQo+ICAgICAgNi4gQXMgSsO8cmdlbiBzdWdn ZXN0ZWQsIHNlY3Rpb25zICJYTUwgTWFwcGluZyBSdWxlcyIgc2hvdWxkIGJlDQo+IAltb3JlIGFw cHJvcHJpYXRlbHkgY2FsbGVkICJYTUwgRW5jb2RpbmcgUnVsZXMiLg0KDQpGaXhlZC4NCg0KPiAg ICAgIDcuIEknZCByZW1vdmUgYWxsIG1lbnRpb25zIG9mIHN1Ym1vZHVsZXMgaW5jbHVkaW5nIG90 aGVyDQo+ICAgICAgICAgc3VibW9kdWxlcywgY2lyY3VsYXIgaW5jbHVkZXMgZXRjLiBiZWNhdXNl IGl0IGlzIG5vdw0KPiAgICAgICAgIGNvbmZ1c2luZy4gSWYgImluY2x1ZGUiIGlzIGlnbm9yZWQg aW4gc3VibW9kdWxlcywgdGhlcmUgaXMgbm8NCj4gICAgICAgICBuZWVkIHRvIGJvdGhlciB3aXRo IGFueSBydWxlcy4gVGhpcyBzZW50ZW5jZSBpbiBzZWMuIDcuMS42DQo+ICAgICAgICAgc2hvdWxk IGJlIGVub3VnaDogJ0ZvciBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IHdpdGggWUFORw0KPiAgICAg ICAgIHZlcnNpb24gMSwgdGhlICJpbmNsdWRlIiBzdGF0ZW1lbnQgaXMgcGVybWl0dGVkIGluIGEg c3VibW9kdWxlDQo+ICAgICAgICAgYnV0IGhhcyBubyBlZmZlY3QgdGhlcmUuJw0KDQpJIGZvdW5k IG9ubHkgdGhpcyBzZW50ZW5jZToNCg0KICBTdWJtb2R1bGVzIGFyZSBvbmx5IGFsbG93ZWQgdG8g aW5jbHVkZSBvdGhlciBzdWJtb2R1bGVzIGJlbG9uZ2luZyB0bw0KICB0aGUgc2FtZSBtb2R1bGUu DQoNCndoaWNoIEkgaGF2ZSBub3cgcmVtb3ZlZC4NCg0KPiAqKioqIFNlYy4gMw0KPiAgICAgIC0g U2hvdWxkbid0IHRoZSB0ZXJtICJkYXRhIHRyZWUiIGFsc28gY292ZXIgdGhlIGNvbnRlbnRzIG9m IFJQQw0KPiAgICAgICAgaW5wdXQvb3V0cHV0LCBhY3Rpb25zIGFuZCBub3RpZmljYXRpb25zPw0K DQpZZXMsIHByb2JhYmx5LiAgQnV0IHRoZW4gd2UgbmVlZCB0byBoYXZlIGEgdGVybSBmb3Igc29t ZSBvZiB0aGUNCmN1cnJlbnQgdXNhZ2VzIG9mICJkYXRhIHRyZWUiLiAgTWF5YmUgImRhdGFzdG9y ZSIgd29ya3MgKHRoaXMgdGVybSBpcw0KYWxyZWFkeSB1c2VkKS4NCg0KPiAqKioqIFNlYy4gNC4y LjIuMw0KPiAgICAgIE9MRA0KPiAgICAgICAgICBBIGNvbnRhaW5lciBtYXkgY29udGFpbiBhbnkg bnVtYmVyIG9mIGNoaWxkIG5vZGVzIG9mIGFueQ0KPiAgICAgICAgICB0eXBlIChpbmNsdWRpbmcg bGVhZnMsIGxpc3RzLCBjb250YWluZXJzLCBhbmQgbGVhZi1saXN0cykuDQo+ICAgICAgTkVXDQo+ ICAgICAgICAgIEEgY29udGFpbmVyIG1heSBjb250YWluIGFueSBudW1iZXIgb2YgY2hpbGQgbm9k ZXMgb2YgYW55DQo+ICAgICAgICAgIHR5cGUgKGxlYWZzLCBsaXN0cywgY29udGFpbmVycywgbGVh Zi1saXN0cywgYW5kIGFjdGlvbnMpLg0KDQpGaXhlZC4NCg0KDQo+ICoqKiogU2VjLiA0LjIuOQ0K PiAgICAgIC0gSW5jbHVkZSBhbiBleGFtcGxlIG9mIGFjdGlvbj8NCg0KRml4ZWQuDQoNCj4gKioq KiBTZWMuIDUuMg0KPiAgICAgIC0gVGhlIGxhc3QgcGFyYWdyYXBoIGFib3V0IHNlcGFyYXRlIGNv bXBpbGF0aW9uIG9mIHN1Ym1vZHVsZXMNCj4gICAgICAgIGxvb2tzIGxpa2UgYW4gaW1wbGVtZW50 YXRpb24gZGV0YWlsIGFuZCBjb3VsZCBwZXJoYXBzIGJlDQo+ICAgICAgICByZW1vdmVkLg0KDQpG aXhlZC4NCg0KPiAqKioqIFNlYy4gNS41DQo+ICAgICAgcy9jbG9zZXN0IG1hdGNoaW5nL21hdGNo aW5nLw0KPiANCj4gICAgICAoYmVjYXVzZSBkZWZpbml0aW9ucyBvZiBncm91cGluZ3MvdHlwZWRl ZnMgY2Fubm90IHNoYWRvdyBhbg0KPiAgICAgICBlcXVhbGx5IG5hbWVkIGdyb3VwaW5nL3R5cGVk ZWYgaW4gYW4gb3V0ZXIgc2NvcGUpDQoNCkZpeGVkLg0KDQo+ICoqKiogU2VjLiA1LjYuNA0KPiAg ICAgIC0gT0xEDQo+ICAgICAgICAgICAgQSBzZXJ2ZXIgaW1wbGVtZW50cyBhIG1vZHVsZSBpZiBp dCBpbXBsZW1lbnRzIHRoZSBtb2R1bGUncyBkYXRhDQo+ICAgICAgICAgICAgbm9kZXMsIHJwY3Ms IG5vdGlmaWNhdGlvbnMsIGFuZCBkZXZpYXRpb25zLg0KPiAgICAgICAgTkVXDQo+ICAgICAgICAg ICAgQSBzZXJ2ZXIgaW1wbGVtZW50cyBhIG1vZHVsZSBpZiBpdCBpbXBsZW1lbnRzIHRoZSBtb2R1 bGUncyBkYXRhDQo+ICAgICAgICAgICAgbm9kZXMsIHJwY3MsIGFjdGlvbnMsIG5vdGlmaWNhdGlv bnMsIGFuZCBkZXZpYXRpb25zLg0KPiAgICAgIC0gcy9hdWdlbWVudC9hdWdtZW50Lw0KPiAgICAg IC0gc3B1cmlvdXMgc3RyaW5nICcjfX0nIGF0IHRoZSBlbmQuDQoNCkZpeGVkLg0KDQo+ICoqKiog U2VjLiA2LjEuMw0KPiAgICAgIEkgdGhpbmsgdGhlIHJ1bGVzIGZvciB3aGl0ZXNwYWNlIHRyaW1t aW5nIGFyZSBjb25mdXNpbmcgYW5kIGhhdmUNCj4gICAgICB2ZXJ5IGxpdHRsZSBwcmFjdGljYWwg dXNlcywgc28gSSdkIHJlY29tbWVuZCB0byByZW1vdmUgdGhlbQ0KPiAgICAgIGVudGlyZWx5LiBI b3dldmVyLCBpZiB0aGUgZGVjaXNpb24gaXMgdG8ga2VlcCB0aGVtLCB0aGUgZm9sbG93aW5nDQo+ ICAgICAgYW1iaWd1aXRpZXMgbmVlZCB0byBiZSBhZGRyZXNzZWQ6DQo+ICAgICAgLSBJdCBpcyB1 bmNsZWFyIHdoZXRoZXIgJ1xuJyBpcyBlcXVpdmFsZW50IHRvIHRoZSBsaXRlcmFsIExGDQo+ICAg ICAgICBjaGFyYWN0ZXIgaW4gdGhlIHRyaW1taW5nIHByb2Nlc3MsIGkuZS4gd2hldGhlciB0aGUN Cj4gICAgICAgIHN1YnN0aXR1dGlvbiBvZiBlc2NhcGUgc2VxdWVuY2VzIGlzIGRvbmUgYmVmb3Jl IG9yIGFmdGVyIHRoZQ0KPiAgICAgICAgdHJpbW1pbmcuDQoNCkhvdyBkb2VzIHRoaXMgbWF0dGVy Pw0KDQo+ICAgICAgLSBJcyB0YWIgY2hhcmFjdGVyIHRyZWF0ZWQgYXMgOCBzcGFjZXMgYWxzbyBi ZWZvcmUgdGhlIG9wZW5pbmcNCj4gICAgICAgIGRvdWJsZSBxdW90ZT8gRXhhbXBsZToNCj4gDQo+ ICAgICAgICBkZXNjcmlwdGlvbiAiVGhpcyBpcyBhIGxvbmcNCj4gICAgICAgICAgICAgICAgICAg ICB0ZXh0LiINCj4gDQo+ICAgICAgICBEb2VzIGl0IG1hdHRlciB3aGV0aGVyIHRoZSBjaGFyYWN0 ZXIgYmV0d2VlbiAiZGVzY3JpcHRpb24iIGFuZA0KPiAgICAgICAgdGhlIG9wZW5pbmcgZG91Ymxl IHF1b3RlIGlzIGEgc3BhY2Ugb3IgdGFiIGNoYXJhY3Rlcj8gKEJvdGgNCj4gICAgICAgIGNhc2Vz IG1heSBoYXZlIGlkZW50aWNhbCB2aXN1YWwgcmVuZGVyaW5nIGRlcGVuZGluZyBvbiB0aGUNCj4g ICAgICAgIGNvbHVtbiB3aGVyZSB0aGUgc3RhdGVtZW50IHN0YXJ0cy4pDQoNCkkgd291bGQgdGhp bmsgc28uICBJIHRoaW5rIHdoaXRlc3BhY2UtdHJpbW1pbmcgaW4gZ2VuZXJhbCBpcyB2ZXJ5DQp1 c2VmdWwsIGJ1dCB0aGUgdGFiLWV4cGFuc2lvbiBpcyBhIGJpdCBjb25mdXNpbmcuICBJIHRoaW5r IGl0IHdvdWxkIGJlDQpvayB0byByZW1vdmUgdGhlIGV4cGFuc2lvbiBvZiB0YWIgd2l0aCA4IHNw YWNlcy4NCg0KPiAqKioqIFNlYy4gNi4yDQo+ICAgICAgT0xEDQo+ICAgICAgICAgIEltcGxlbWVu dGF0aW9ucyBNVVNUIHN1cHBvcnQgaWRlbnRpZmllcnMgdXAgdG8gNjQgY2hhcmFjdGVycyBpbg0K PiAJIGxlbmd0aC4NCj4gICAgICBORVcNCj4gICAgICAgICAgSW1wbGVtZW50YXRpb25zIGFyZSBu b3QgcmVxdWlyZWQgdG8gc3VwcG9ydCBpZGVudGlmaWVyIGxvbmdlcg0KPiAgICAgICAgICB0aGFu IDY0IGNoYXJhY3Rlci4NCj4gDQo+ICAgICAgKFRoZSBjdXJyZW50IGZvcm11bGF0aW9uIGNhbiBJ TU8gYmUgdW5kZXJzdG9vZCBzbyB0aGF0IGlkZW50aWZpZXJzDQo+ICAgICAgbG9uZ2VyIHRoYW4g NjQgY2hhcnMgY2Fubm90IGJlIHN1cHBvcnRlZC4pDQoNCkhvdyBhYm91dDoNCg0KICAgICAgICAg SW1wbGVtZW50YXRpb25zIE1VU1Qgc3VwcG9ydCBpZGVudGlmaWVycyB1cCB0byA2NCBjaGFyYWN0 ZXJzIGluDQogICAgICAgICBsZW5ndGgsIGFuZCBNQVkgc3VwcG9ydCBsb25nZXIgaWRlbnRpZmll cnMuDQoNCj4gKioqKiBTZWMuIDYuMy4xDQo+ICAgICAgV2hhdCBkb2VzIHRoZSBsYXN0IHBhcmFn cmFwaCBtZWFuPyBJbiBwYXJ0aWN1bGFyOiBpZiBhbiBleHRlbnNpb24NCj4gICAgICBpcyBpbXBv cnRlZCBhbmQgdXNlZCBpbiBhIG1vZHVsZSB0aGF0IHRoZSBzZXJ2ZXIgYWR2ZXJ0aXNlcywNCj4g ICAgICBjb3VsZCB0aGUgc2VydmVyIGlnbm9yZSB0aGF0IGV4dGVuc2lvbj8NCg0KVGhpcyBpcyBi ZWluZyBpbiBkaXNjdXNzZWQgaW4gYSBzZXBhcmF0ZSB0aHJlYWQuDQoNCj4gKioqKiBTZWMuIDYu NA0KPiAgICAgIC0gJ1RoZSBkYXRhIG1vZGVsIHVzZWQgaW4gdGhlIFhQYXRoIGV4cHJlc3Npb25z IGlzIHRoZSBzYW1lIGFzDQo+ICAgICAgICB0aGF0IHVzZWQgaW4gWFBhdGggMS4wIFtYUEFUSF0s IOKApicNCj4gDQo+ICAgICAgICBJIHRoaW5rIHNvbWUgZXhwbGFuYXRpb24gaXMgbmVlZGVkIGRl c2NyaWJpbmcgaG93IGEgZGF0YSB0cmVlDQo+ICAgICAgICBpcyBtYXBwZWQgb250byB0aGUgKHJl c3RyaWN0ZWQpIFhQYXRoIGRhdGEgbW9kZWwuIFNwZWNpZmljYWxseToNCj4gICAgICAgICogVGhl IGRhdGEgdHJlZSBoYXMgbm8gY29uY2VwdCBvZiBkb2N1bWVudCBvcmRlciwgZXhjZXB0IGZvcg0K PiAgICAgICAgICBSUEMgaW5wdXQvb3V0cHV0LiBUaGUgc3BlYyBzaG91bGQgc2F5IGltcGxlbWVu dGF0aW9ucyBuZWVkDQo+ICAgICAgICAgIHRvIGNob29zZSBzb21lIGRvY3VtZW50IG9yZGVyIGJ1 dCBob3cgaXQgaXMgZG9uZSBpcw0KPiAgICAgICAgICB1bmRlZmluZWQsIHNvIFhQYXRoIGV4cHJl c3Npb25zIGluIFlBTkcgbW9kdWxlcyBzaG91bGRuJ3QNCj4gICAgICAgICAgcmVseSBvbiB0aGUg ZG9jdW1lbnQgb3JkZXIuDQoNCk9rLCBtYWtlcyBzZW5zZS4gIEhvdyBhYm91dCBhZGRpbmcgYSBu ZXcgcGFyYWdyYXBoIHRocmVlOg0KDQogIFRoZSBkYXRhIHRyZWUgaGFzIG5vIGNvbmNlcHQgb2Yg ZG9jdW1lbnQgb3JkZXIuICBBbiBpbXBsZW1lbnRhdGlvbg0KICBuZWVkcyB0byBjaG9vc2Ugc29t ZSBkb2N1bWVudCBvcmRlciBidXQgaG93IGl0IGlzIGRvbmUgaXMgYW4NCiAgaW1wbGVtZW50YXRp b24gZGVjaXNpb24uICBUaGlzIG1lYW5zIHRoYXQgWFBhdGggZXhwcmVzc2lvbnMgaW4gWUFORw0K ICBtb2R1bGVzIFNIT1VMRCBub3QgcmVseSBvbiBhbnkgc3BlY2lmaWMgZG9jdW1lbnQgb3JkZXIu DQoNCj4gICAgICAgICogSXQgbWlnaHQgYmUgdXNlZnVsIHRvIGRlZmluZSBob3cgbmFtZXNwYWNl IG5vZGVzIHJlcHJlc2VudGluZw0KPiAgICAgICAgICBZQU5HIG5hbWVzcGFjZXMgYXBwZWFyIGlu IHRoZSBYUGF0aCB0cmVlIHNvIHRoYXQgdGhlDQo+ICAgICAgICAgIG5hbWVzcGFjZTo6IGF4aXMg d29ya3MgaW4gYSBkZXRlcm1pbmlzdGljIGZhc2hpb24uIEZvcg0KPiAgICAgICAgICBleGFtcGxl LCBvbmUgY291bGQgc2F5IHRoYXQgYWxsIHRoZXNlIG5hbWVzcGFjZXMgYXJlIGluIHNjb3BlDQo+ ICAgICAgICAgIGZvciBhbGwgZWxlbWVudHMgY29ycmVzcG9uZGluZyB0byBZQU5HIGRhdGEgbm9k ZXMuIE9uZSBjb3VsZA0KPiAgICAgICAgICB1c2UgaXQsIGUuZy4gdG8gZGV0ZXJtaW5lIHdoZXRo ZXIgYSBwYXJ0aWN1bGFyIFlBTkcgbW9kdWxlIGlzDQo+ICAgICAgICAgIGEgcGFydCBvZiB0aGUg ZGF0YSBtb2RlbC4NCg0KV2h5IHdvdWxkbid0IHRoZSBuYW1lc3BhY2UgYXhpcyB3b3JrIGluIGEg ZGV0ZXJtaW5pc3RpYyBmYXNoaW9uPyAgQWxsDQpub2RlcyBkZWZpbmVkIGluIGEgbW9kdWxlIGhh dmUgdGhlIHNhbWUgWE1MIG5hbWVzcGFjZSwgd2hpY2ggaXMNCndlbGwtZGVmaW5lZC4NCg0KPiAg ICAgIC0gQW5vdGhlciBwb3NzaWJsZSBzb3VyY2Ugb2Ygc3VycHJpc2VzIGFyZSBlcXVhbGl0eSB0 ZXN0cyAoYnV0DQo+ICAgICAgICBtYXliZSBpdCBiZWxvbmdzIHRvIDYwODdiaXMpLiBXaXRoDQo+ IA0KPiAgICAgICAgY29udGFpbmVyIHRvcCB7DQo+ICAgICAgICAgIG11c3QgInggPSB5IjsNCj4g ICAgICAgICAgbGVhZiB4IHsNCj4gICAgICAgICAgICB0eXBlIGRlY2ltYWw2NCB7DQo+ICAgICAg ICAgICAgICBmcmFjdGlvbi1kaWdpdHMgMTsNCj4gICAgICAgICAgICB9DQo+ICAgICAgICAgIH0N Cj4gICAgICAgICAgbGVhZiB5IHsNCj4gICAgICAgICAgICB0eXBlIHVpbnQ4Ow0KPiAgICAgICAg ICB9DQo+ICAgICAgICB9DQo+IA0KPiAgICAgICAgdGhlIGZvbGxvd2luZyBpbnN0YW5jZSB2aW9s YXRlcyB0aGUgbXVzdCBjb25zdHJhaW50Og0KPiANCj4gICAgICAgIDx0b3A+DQo+ICAgICAgICAg IDx4PjEuMDwveD4NCj4gICAgICAgICAgPHk+MTwveT4NCj4gICAgICAgIDwvdG9wPg0KDQpJZiBp dCBpcyBiZWxvbmdzIGFueXdoZXJlIGl0IHdvdWxkIGJlIGluIDYwODcuICBCdXQgdGhpcyBpcyBq dXN0IGhvdw0KWFBhdGggd29ya3MsIHNvIEkgYW0gbm90IHN1cmUgaXQgaXMgbmVlZGVkLi4uDQoN Cj4gKioqKiBTZWMuIDYuNC4xDQo+ICAgICAgLSBUaGUgYWNjZXNzaWJsZSB0cmVlIHNob3VsZCBh bHNvIGJlIGRlZmluZWQgZm9yIGFjdGlvbg0KPiAgICAgICAgaW5wdXQvb3V0cHV0Lg0KDQpGaXhl ZC4NCg0KPiAgICAgIC0gQ2Fub25pY2FsIHZhbHVlcyBzaG91bGQgYmUgdXNlZCBhbHNvIGZvciBS UENzLCBhY3Rpb25zIGFuZA0KPiAgICAgICAgbm90aWZpY2F0aW9ucy4NCg0KSSBkb24ndCB1bmRl cnN0YW5kIHdoYXQgdGhpcyByZWZlcnMgdG8/DQoNCj4gICAgICAtIHMvYWxsIGFsbC9hbGwvDQoN CkZpeGVkLg0KDQo+IA0KPiAqKioqIFNlYy4gNy4xLjUuMQ0KPiAgICAgIC0gJ1RoZSAicmV2aXNp b24tZGF0ZSIgc3RhdGVtZW50IE1VU1QgbWF0Y2ggdGhlIG1vc3QgcmVjZW50DQo+ICAgICAgICAi cmV2aXNpb24iIHN0YXRlbWVudCBpbiB0aGUgaW1wb3J0ZWQgbW9kdWxlLicNCj4gDQo+ICAgICAg ICBUaGlzIHNob3VsZCBiZSByZW1vdmVkIGJlY2F1c2Ugb3RoZXJ3aXNlIHRoZSBpbXBvcnRpbmcg bW9kdWxlDQoNCj4gICAgICAgIGNvdWxkbid0IHN0aWNrIHRvIGFuIG9sZCByZXZpc2lvbiBvZiB0 aGUgaW1wb3J0ZWQgbW9kdWxlLg0KDQpJIHRoaW5rIHdoYXQgdGhpcyB0cmllcyB0byBzYXkgaXMg aWYgYSBzcGVjaWZpYyByZXZpc2lvbiBvZiBhIG1vZHVsZQ0KaXMgbmVlZGVkIChmb3IgaW1wb3J0 IGJ5IHJldmlzaW9uKSwgdGhlbiB5b3UgbXVzdCBmaW5kIHRoZSBtb2R1bGUgd2l0aA0KZXhhY3Rs eSB0aGF0IGdpdmVuIHJldmlzaW9uIChraW5kIG9mIG9idmlvdXMuLi4pLg0KDQpTbyBJIGFncmVl IHRoYXQgdGhpcyBzZW50ZW5jZSBwcm9iYWJseSBjYW4gYmUgcmVtb3ZlZCAoZG9uZSkuDQoNCj4g KioqKiBTZWMuIDcuMS42DQo+ICAgICAgLSAnSWYgbm8gInJldmlzaW9uLWRhdGUiIHN1YnN0YXRl bWVudCBpcyBwcmVzZW50LCBpdCBpcyB1bmRlZmluZWQgd2hpY2gNCj4gICAgICAgIHJldmlzaW9u IG9mIHRoZSBzdWJtb2R1bGUgaXMgaW5jbHVkZWQuJw0KPiANCj4gICAgICAgIEkgdGhpbmsgaW4g dGhpcyBjYXNlIHRoZSBzdWJtb2R1bGUgcmV2aXNpb25zIG5lZWQgdG8gYmUNCj4gICAgICAgIHNw ZWNpZmllZCBpbiB5YW5nLWxpYnJhcnkuDQoNCkkgdGhpbmsgdGhleSBhcmUuDQoNCj4gKioqKiBT ZWMuIDcuNS4xDQo+ICAgICAgLSAnSW4gdGhlIGZpcnN0IHN0eWxlLCB0aGUgY29udGFpbmVyIGhh cyBubyBtZWFuaW5nIG9mIGl0cyBvd24sDQo+ICAgICAgICBleGlzdGluZyBvbmx5IHRvIGNvbnRh aW4gY2hpbGQgbm9kZXMuJw0KPiANCj4gICAgICAgIEkgZG9uJ3QgdGhpbmsgdGhpcyBpcyByZWFs bHkgdHJ1ZSwgZS5nLiAibXVzdCIgc3RhdGVtZW50IG9uIGENCj4gICAgICAgIE5QIGNvbnRhaW5l cnMgYWRkcyBtZWFuaW5nIHRvIGl0LCBzZWUgWTQxLg0KDQpEbyB5b3UgaGF2ZSBzb21lIHByb3Bv c2VkIHRleHQ/ICBJIGRvbid0IHRoaW5rIHRoZSBleGlzdGFuY2Ugb2YgYSBtdXN0DQpzdGF0ZW1l bnQgaW4gdGhlIE5QLWNvbnRhaW5lciBjaGFuZ2VzIHRoZSBmYWN0IHRoYXQgaXRzIHByZXNlbmNl IGhhcw0Kbm8gbWVhbmluZy4NCg0KPiAgICAgIC0gJ0luIHRoZSBzZWNvbmQgc3R5bGUsIHRoZSBw cmVzZW5jZSBvZiB0aGUgY29udGFpbmVyIGl0c2VsZiBpcw0KPiAgICAgICAgY29uZmlndXJhdGlv biBkYXRhLCByZXByZXNlbnRpbmcgYSBzaW5nbGUgYml0IG9mIGNvbmZpZ3VyYXRpb24NCj4gICAg ICAgIGRhdGEuJw0KPiANCj4gICAgICAgIFdoYXQgYWJvdXQgY29udGFpbmVycyB3aXRoIHByZXNl bmNlIG91dHNpZGUgY29uZmlnPXRydWUgZGF0YT8NCg0KRml4ZWQuDQoNCj4gKioqKiBTZWMuIDcu NS43DQo+ICAgICAgLSBJcyB0aGUgb3JkZXIgb2Ygc3ViZWxlbWVudHMgYWxzbyBmaXhlZCBpbiBh Y3Rpb24gaW5wdXQvb3V0cHV0Pw0KDQpZZXMsIGZpeGVkLiAgKGFuZCB2YXJpb3VzIG90aGVyIHNp bWlsYXIgcGxhY2VzKS4NCg0KPiAqKioqIFNlYy4gNy41LjgNCj4gICAgICAtICcgSWYgYSBjb250 YWluZXIgZG9lcyBub3QgaGF2ZSBhICJwcmVzZW5jZSIgc3RhdGVtZW50IGFuZCB0aGUgbGFzdA0K PiAgICAgICAgY2hpbGQgbm9kZSBpcyBkZWxldGVkLCB0aGUgTkVUQ09ORiBzZXJ2ZXIgTUFZIGRl bGV0ZSB0aGUNCj4gICAgICAgIGNvbnRhaW5lci4nDQo+IA0KPiAgICAgICAgV2l0aG91dCBmdXJ0 aGVyIGV4cGxhbmF0aW9uIHRoaXMgY29udHJhZGljdHMgdGhlIHJlc29sdXRpb24gb2YNCj4gICAg ICAgIFk0MS4gSXQgc2hvdWxkIHNheSBhdCBsZWFzdCB3aGVyZSBzdWNoIGNvbnRhaW5lcnMgbWF5 IGJlDQo+ICAgICAgICBkZWxldGVkIChlLmcuIGluIHRoZSByZXBseSB0byA8Z2V0LWNvbmZpZz4g b3IgPGdldD4pLg0KDQpJIGRvbid0IGFncmVlLCBzaW5jZSB0aGUgdGV4dCBub3cgc2F5cyB0aGF0 IGZvciB2YWxpZGF0aW9uIHB1cnBvc2VzLA0KTlAgY29udGFpbmVycyAqYWx3YXlzKiBleGlzdCBp ZiBpdHMgcGFyZW50IGV4aXN0cy4NCg0KPiAqKioqIFNlYy4gNy42LjENCj4gICAgICAtIFRoZSB0 ZXh0IGlzIHN1aXRhYmxlIGZvciBjb25maWcsIGRlZmF1bHRzIGluIFJQQyBpbnB1dC9vdXRwdXQN Cj4gICAgICAgIGFuZCBub3RpZmljYXRpb25zIGFyZSBjb3ZlcmVkIGVsc2V3aGVyZSwgYnV0IHdo YXQgYWJvdXQNCj4gICAgICAgIGRlZmF1bHRzIChhbmQgbWFuZGF0b3J5KSBpbiBzdGF0ZSBkYXRh Pw0KDQpJIGRvbid0IHRoaW5rIHRoaXMgdGV4dCBpcyBleGNsdWRlcyBzdGF0ZSBkYXRhLg0KDQo+ ICoqKiogU2VjLiA3LjcuMQ0KPiAgICAgIC0gVGhlIHRlcm0gImFycmF5IiBzdWdnZXN0cyBzb21l IGhpZ2hlci1sZXZlbCBkYXRhIHN0cnVjdHVyZSAoYXMNCj4gICAgICAgIGluIEpTT04gZW5jb2Rp bmcpLiBJJ2QgdXNlICJzZXF1ZW5jZSBvZiBsZWFmIG5vZGVzIiBpbnN0ZWFkLg0KDQpJIHRoaW5r ICJhcnJheSIgaXMgb2suDQoNCj4gICAgICAtIHMvZmlyZXdhbGwgZmlsdGVycy9wYWNrZXQgZmls dGVyLw0KDQpGaXhlZC4NCg0KPiAqKioqIFNlYy4gNy43LjQNCj4gICAgICAtICcgVGhlICJkZWZh dWx0IiBzdGF0ZW1lbnQgTVVTVCBOT1QgYmUgcHJlc2VudCBvbiBub2RlcyB3aGVyZQ0KPiAgICAg ICAgIm1pbi1lbGVtZW50cyIgaGFzIGEgdmFsdWUgZ3JlYXRlciB0aGFuIG9yIGVxdWFsIHRvIG9u ZS4nDQo+IA0KPiAgICAgICAgV2h5PyBUaGlzIHNob3VsZCBiZSBPSzoNCj4gDQo+ICAgICAgICBs ZWFmLWxpc3QgZm9vIHsNCj4gICAgICAgICAgdHlwZSB1aW50ODsNCj4gICAgICAgICAgbWluLWVs ZW1lbnRzIDE7DQo+ICAgICAgICAgIGRlZmF1bHQgNTQ7DQo+ICAgICAgICB9DQoNCk5vLCBiL2Mg bWluLWVsZW1lbnRzIDEgc2F5cyB0aGF0IHRoZXJlIG11c3QgYmUgYXQgbGVhc3Qgb25lIGluc3Rh bmNlLA0KYW5kIHRoZSBkZWZhdWx0IHN0YXRlbWVudCBzcGVjaWZpZXMgd2hhdCBoYXBwZW5zIGlm IHRoZXJlIGFyZSBubw0KaW5zdGFuY2VzLg0KDQo+ICoqKiogU2VjLiA3LjcuOQ0KPiAgICAgIC0g SXMgdGhlIGludGVyYWN0aW9uIG9mIDxlZGl0LWNvbmZpZz4gb3BlcmF0aW9ucywgbGVhZi1saXN0 DQo+ICAgICAgICBkZWZhdWx0IHZhbHVlcywgYW5kIHdpdGgtZGVmYXVsdHMgbW9kZXMgc3VmZmlj aWVudGx5IGNsZWFyPw0KPiAgICAgICAgU2VlIGFsc28gdGhlIHRocmVhZCBzdGFydGluZyB3aXRo DQo+ICAgICAgICBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL25ldG1vZC9Q dk16V2Z6cFlhMGJnLVMyakVyWDk3NVkzSmsNCg0KSSBkb24ndCBrbm93IGlmIHdlIG5lZWQgdG8g YWRkIGFueXRoaW5nLiAgU3VnZ2VzdGlvbnM/DQoNCj4gKioqKiBTZWMuIDcuOC42DQo+ICAgICAg LSBJdCB3b3VsZCBiZSBoZWxwZnVsIHRvIGluY2x1ZGUgYW4gZXhhbXBsZSBvZiB5YW5nOmtleSBh dHRyaWJ1dGUNCj4gICAgICAgIHZhbHVlIHdpdGggbXVsdGlwbGUgKHR3bykga2V5cy4gSSByZW1l bWJlciBzb21lYm9keSBhc2tlZCBtZQ0KPiAgICAgICAgYWJvdXQgdGhhdC4NCg0KRml4ZWQuDQoN Cj4gKioqKiBTZWMuIDcuOS4yDQo+ICAgICAgLSBUaGUgcGFyYWdyYXBoIGFib3V0IHNob3J0aGFu ZCBjYXNlIHN0YXRlbWVudCBzaG91bGQgbW9yZQ0KPiAgICAgICAgZXhwbGljaXRseSBleHBsYWlu IHRoYXQgYSBjYXNlIG5vZGUgaXMgcHJlc2VudCBpbiB0aGUgc2NoZW1hDQo+ICAgICAgICB0cmVl IGV2ZW4gZm9yIHNob3J0LWNhc2Utc3RtdCwgYW5kIHRodXMgc2NoZW1hIG5vZGUgaWRlbnRpZmll cnMNCj4gICAgICAgIGFsd2F5cyBuZWVkIHRvIGluY2x1ZGUgY2FzZSBub2RlIGlkZW50aWZpZXJz Lg0KDQpJIGRvbid0IHVuZGVyc3RhbmQgaG93IHRoZSBjdXJyZW50IHRleHQgY291bGQgZ2l2ZSB0 aGUgaW1wcmVzc2lvbiB0aGF0DQp0aGVyZSBpcyBubyBjYXNlIG5vZGUgaW4gdGhlIHNjaGVtYSB0 cmVlIG9mIHNob3J0aGFuZCBjYXNlcyBhcmUgdXNlZC4NCg0KPiAqKioqIFNlYy4gNy4xMA0KPiAg ICAgIC0gVGhlIHNlY3Rpb24gc2hvdWxkIGFsc28gc3RhdGUgdGhhdCB0aGUgZGF0YSBtb2RlbCBm b3IgImFueWRhdGEiDQo+ICAgICAgICBjb250ZW50IG1heSBvciBtYXkgbm90IGJlIGtub3duIGF0 IHJ1biB0aW1lLg0KDQpIb3cgYWJvdXQgdGhpczoNCg0KTkVXOg0KDQogIEFuIGltcGxlbWVudGF0 aW9uIG1heSBvciBtYXkgbm90IGtub3cgdGhlIGRhdGEgbW9kZWwgdXNlZCB0byBtb2RlbCBhDQog IHNwZWNpZmljIGluc3RhbmNlIG9mIGFuIGFueWRhdGEgbm9kZS4NCg0KDQo+ICoqKiogU2VjLiA3 LjEyDQo+ICAgICAgLSAnRm9yIGV4dGVuc2lvbnMsIHRoaXMgbWVhbnMgdGhhdCBleHRlbnNpb25z IGFyZSBhcHBsaWVkIHRvIHRoZQ0KPiAgICAgICAgZ3JvdXBpbmcgbm9kZSwgbm90IHRoZSB1c2Vz IG5vZGUuJw0KPiANCj4gICAgICAgIEkgZG9udCB1bmRlcnN0YW5kIHdoYXQgdGhpcyBtZWFucy4g V2hhdCBpcyB0aGUgImdyb3VwaW5nIG5vZGUiPw0KDQpSaWdodDsgdGhlcmUgaXMgbm8gImdyb3Vw aW5nIG5vZGUiIGFuZCBubyAidXNlcyBub2RlIi4gIEkgc3VnZ2VzdCB3ZQ0Kc2ltcGx5IGRvOg0K DQpORVc6DQoNCiAgIEZvciBleHRlbnNpb25zLCB0aGlzIG1lYW5zIHRoYXQgZXh0ZW5zaW9ucyBh cmUgYXBwbGllZCB0byB0aGUNCiAgIGdyb3VwaW5nIGl0c2VsZi4NCg0KPiAqKioqIFNlYy4gNy4x My4yDQo+ICAgICAgLSBDYW4gYSBsZWFmLWxpc3QgYWxzbyBnZXQgKG5ldykgZGVmYXVsdCB2YWx1 ZXMgdGhyb3VnaCAicmVmaW5lIj8NCj4gICAgICAgIElmIHNvLCBob3cgYXJlIHRoZXkgY29tYmlu ZWQgd2l0aCB0aGUgZGVmYXVsdCB2YWx1ZXMgZGVmaW5lZCBpbg0KPiAgICAgICAgdGhlIGdyb3Vw aW5nPw0KDQpHb29kIHBvaW50LiAgSSBzdWdnZXN0Og0KDQpORVc6DQoNCi0gQSBsZWFmLWxpc3Qg bm9kZSBtYXkgZ2V0IGEgc2V0IG9mIGRlZmF1bHQgdmFsdWVzLCBvciBhIG5ldyBzZXQgb2YNCiAg ZGVmYXVsdCB2YWx1ZXMgaWYgaXQgYWxyZWFkeSBoYWQgZGVmYXVsdHM7IGkuZS4sIHRoZSBzZXQg b2YgcmVmaW5lZA0KICBkZWZhdWx0IHZhbHVlcyByZXBsYWNlcyB0aGUgZGVmYXVsdHMgYWxyZWFk eSBnaXZlbi4NCg0KPiAqKioqIFNlYy4gNy4xNQ0KPiAgICAgIC0gJ0FuIGFjdGlvbiBNVVNUIE5P VCBiZSBkZWZpbmVkIHdpdGhpbiBhbiBycGMsIGFub3RoZXIgYWN0aW9uIG9yIGENCj4gICAgICAg ICBub3RpZmljYXRpb24sIOKApicNCj4gDQo+ICAgICAgICBBbHNvIGl0IE1VU1QgTk9UIGJlIGRl ZmluZWQgd2l0aGluIGxlYWYgYW5kIGxlYWYtbGlzdCwgcmlnaHQ/DQoNClJpZ2h0LCBidXQgdGhp cyBpcyBub3QgYWxsb3dlZCBhY2NvcmRpbmcgdG8gdGhlIGdyYW1tYXIuDQoNCj4gICAgICAtIENh biBhbiBhY3Rpb24gZGVmaW5lZCBvbiBhIGxpc3QgYmUgYXBwbGllZCB0byB0aGUgd2hvbGUgbGlz dD8NCg0KTm8uDQoNCihJdCBpcyBpbiBnZW5lcmFsIElNTyB1bmZvcnR1bmF0ZSB0aGF0IHRoZXJl IGlzIG5vIHdheSB0byBtYW5pcHVsYXRlDQp0aGUgd2hvbGUgbGlzdC4pDQoNCj4gKioqKiBTZWMu IDcuMjEuMw0KPiAgICAgIC0gTWF5YmUgdGhpcyBzZWN0aW9uIHNob3VsZCBhbHNvIGV4cGxhaW4g dGhhdCBkZXNjcmlwdGlvbnMgYXJlIGFuDQo+ICAgICAgICBpbnRlZ3JhbCBwYXJ0IG9mIHRoZSBk YXRhIG1vZGVsIGFuZCBtYXkgc3BlY2lmeSwgZS5nLiwgc2VtYW50aWMNCj4gICAgICAgIGNvbnN0 cmFpbnRzIHRoYXQgY2Fubm90IGJlIGV4cHJlc3NlZCBmb3JtYWxseS4NCg0KQ2FuIHlvdSBzdWdn ZXN0IHNvbWUgdGV4dD8gIChJIGFtIG5vdCBzdXJlIEkgdW5kZXJzdGFuZCB3aGF0IHlvdSB0aGlu aw0KaXMgbmVlZGVkIHRvIGV4cGxhaW4uLi4pDQoNCj4gKioqKiBTZWMuIDkuMTAuMg0KPiAgICAg IC0gcy9zdXBwb3J0ZWQgYnkgdGhlIHNlcnZlci9pbXBsZW1lbnRlZCBieSB0aGUgc2VydmVyLw0K DQpJIHRoaW5rIHRoZXNlIHdvcmRzIG1lYW4gdGhlIHNhbWUgdGhpbmcuICBGb3IgZXhhbXBsZSwg d2UgaGF2ZSAoZm9yDQp0aGUgZGV2aWF0ZSBzdGF0ZW1lbnQpOg0KDQogICBUaGUgYXJndW1lbnQg Im5vdC1zdXBwb3J0ZWQiIGluZGljYXRlcyB0aGF0IHRoZSB0YXJnZXQgbm9kZSBpcyBub3QNCiAg IGltcGxlbWVudGVkIGJ5IHRoaXMgZGV2aWNlLg0KDQoNCj4gKioqKiBTZWMuIDkuMTAuMw0KPiAg ICAgIFRoZSBsYXN0IHBhcmFncmFwaCBzaG91bGQgcHJvYmFibHkgYmUgcmVwbGFjZWQgd2l0aCBh biBhZHZpY2UgdGhhdA0KPiAgICAgIGlkZW50aXR5cmVmIHZhbHVlcyBvciBub2Rlc2V0cyBzaG91 bGQgbmV2ZXIgYXBwZWFyIGFzIGJhcmUNCj4gICAgICBzdHJpbmdzIGluIFhQYXRoIGV4cHJlc3Np b25zLCBhbmQgZnVuY3Rpb25zIGRlcml2ZWQtZnJvbSgpIG9yDQo+ICAgICAgZGVyaXZlZC1mcm9t LW9yLXNlbGYoKSBzaG91bGQgYmUgdXNlZCBpbnN0ZWFkLg0KDQpJIHRoaW5rIHRoZSBzdHJpbmcg dmFsdWUgbmVlZHMgdG8gYmUgZGVmaW5lZC4NCg0KPiAgICAgIEV4YW1wbGUgaW4NCj4gICAgICBz ZWMuIDkuMTAuNSBzaG91bGQgYmUgY2hhbmdlZCB0byB1c2UgZGVyaXZlZC1mcm9tLW9yLXNlbGYo KS4NCg0KSSB0aGluayBpdCByZWFzb25hYmxlIHRvIGV4YW1wbGlmeSB0aGUgc3RyaW5nIHZhbHVl IG9mIGFuIGlkZW50aXR5Lg0KSG93ZXZlciwgSSBhZ3JlZSB0aGF0IHdlIHNob3VsZCBhZGQgYWR2 aWNlIGFib3V0IHVzaW5nDQpkZXJpdmVkLWZyb20tb3Itc2VsZigpLCBidXQgSSB0aGluayB0aGF0 IHNob3VsZCBiZSBkb25lIGluIDYwODdiaXMuDQoNCj4gKioqKiBTZWMuIDEwLjMuMQ0KPiAgICAg IC0gVGhlIGRvY3VtZW50IG9yZGVyIGlzIHVuZGVmaW5lZCBpbiBhIGRhdGEgdHJlZSAoYWxzbyBp bg0KPiAgICAgICAgc2VjLiAxMC40LjEgYW5kIDEwLjQuMikuDQoNCkFib3ZlIChmb3IgNi40KSB5 b3Ugc3VnZ2VzdGVkIHRoYXQgdGhlIGRvY3VtZW50IG9yZGVyIGlzDQppbXBsZW1lbnRhdGlvbi1z cGVjaWZpYy4NCg0KPiAgICAgIC0gSSB0aGluayBkZXJlZigpIGNvdWxkIHJldHVybiBub24tZW1w dHkgbm9kZXNldCBvbmx5IGZvcg0KPiAgICAgICAgaW5zdGFuY2UtaWRlbnRpZmllcnMgYmVjYXVz ZSBmb3IgbGVhZnJlZiBpdCdzIG5vdCBuZWVkZWQuDQoNCk9rLi4uPyAgRG8geW91IGhhdmUgYW55 IGVkaXRzIGluIG1pbmQ/DQoNCg0KPiAgICAgICAgVGhlDQo+ICAgICAgICAibXVzdCIgY29uc3Ry YWludCBpbiBzZWMuIDEwLjMuMS4xIGlzIGJldHRlciBleHByZXNzZWQgbGlrZSBzbzoNCj4gICAg ICAgICcvaW50ZXJmYWNlW25hbWU9Y3VycmVudCgpXS9lbmFibGVkID0gInRydWUiJw0KDQpCdXQg dGhlbiBpdCB3b3VsZG4ndCBleGFtcGxpZnkgdGhlIGRlcmVmKCkgZnVuY3Rpb24sIHdvdWxkIGl0 IDstKQ0KDQpCdXQgbWF5YmUgdGhpcyBpcyBhIGJldHRlciBleGFtcGxlOg0KDQogIGxpc3QgaW50 ZXJmYWNlIHsNCiAgICAgIGtleSAibmFtZSB0eXBlIjsNCiAgICAgIGxlYWYgbmFtZSB7IC4uLiB9 DQogICAgICBsZWFmIHR5cGUgeyAuLi4gfQ0KICAgICAgbGVhZiBlbmFibGVkIHsNCiAgICAgICAg ICB0eXBlIGJvb2xlYW47DQogICAgICB9DQogICAgICAuLi4NCiAgfQ0KDQogIGNvbnRhaW5lciBt Z210LWludGVyZmFjZSB7DQogICAgICBsZWFmIG5hbWUgew0KICAgICAgICAgIHR5cGUgbGVhZnJl ZiB7DQogICAgICAgICAgICAgIHBhdGggIi9pbnRlcmZhY2UvbmFtZSI7DQogICAgICAgICAgfQ0K ICAgICAgfQ0KICAgICAgbGVhZiB0eXBlIHsNCiAgICAgICAgICB0eXBlIGxlYWZyZWYgew0KICAg ICAgICAgICAgICBwYXRoICIvaW50ZXJmYWNlW25hbWU9Y3VycmVudCgpLy4uL25hbWVdL3R5cGUi Ow0KICAgICAgICAgIH0NCiAgICAgICAgICBtdXN0ICdkZXJlZiguKS8uLi9lbmFibGVkID0gInRy dWUiJyB7DQogICAgICAgICAgICAgIGVycm9yLW1lc3NhZ2UNCiAgICAgICAgICAgICAgICAgICJU aGUgbWFuYWdlbWVudCBpbnRlcmZhY2UgY2Fubm90IGJlIGRpc2FibGVkLiI7DQogICAgICAgICAg fQ0KICAgICAgfQ0KICB9DQoNCg0KPiAqKioqIFNlYy4gMTMNCj4gICAgICAtIFRoZSBBQk5GIGNh biBiZSBtYWRlIHN0cmljdGVyIGJ5IHJlcGxhY2luZyAiW2RlZmF1bHQtc3RtdF0iDQo+ICAgICAg ICBhbW9uZyB0aGUgc3Vic3RhdGVtZW50cyBvZiAiY2hvaWNlLXN0bXQiIHdpdGgNCj4gICAgICAg ICJbZGVmYXVsdC1jYXNlLXN0bXRdIiwgYW5kIHRoZW4gYWRkaW5nDQo+IA0KPiAgICAgICAgZGVm YXVsdC1jYXNlLXN0bXQgPSBkZWZhdWx0LWtleXdvcmQgc2VwIG5vZGUtaWRlbnRpZmllcg0KPiAg ICAgICAgICBzdG10ZW5kDQoNCkJ1dCB0aGVuIGl0IHdvdWxkIGJlIHRlbXB0aW5nIHRvIGFkZCBb ZGVmYXVsdC1jYXNlLXN0bXRdIHRvDQpyZWZpbmUtc3RtdCBhbmQgZGV2aWF0ZS0qIGFzIHdlbGwu ICBCdXQgdGhlbiB3ZSdkIGdldCBib3RoDQpbZGVmYXVsdC1zdG10XSBhbmQgW2RlZmF1bHQtY2Fz ZS1zdG10XSBpbiB0aGVzZSBzdGF0ZW1lbnRzLiAgU28gSQ0KcHJlZmVyIHRvIGtlZXAgaXQgYXMg aXMuDQoNCg0KL21hcnRpbg0K From nobody Tue Aug 25 04:04:42 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1873F1AD359 for ; Tue, 25 Aug 2015 04:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_FORM=2.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVSimWb5lVIz for ; Tue, 25 Aug 2015 04:04:39 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id C43CC1ACED1 for ; Tue, 25 Aug 2015 04:04:38 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 8186F1CC0047; Tue, 25 Aug 2015 13:04:39 +0200 (CEST) From: Ladislav Lhotka To: Randy Presuhn , "netmod\@ietf.org" In-Reply-To: <20976241.1440444036499.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> References: <20976241.1440444036499.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Tue, 25 Aug 2015 13:04:35 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] Y26 again, sorry X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 11:04:41 -0000 Randy Presuhn writes: > Hi - > >>From: Ladislav Lhotka >>Sent: Aug 24, 2015 11:44 AM >>To: Andy Bierman >>Cc: "netmod@ietf.org" >>Subject: Re: [netmod] Y26 again, sorry > ... >>> YANG does not provide any mechanism to REQUIRE modules A and B >>> to both be implemented on a server. You may think it should, but >>> currently the YANG conformance is for an individual module. >> >>There are sections on conformance and conformance announcement, >>and they say nothing like this. In my view, the data model comprises >>*all* modules advertised by the server. I think your interpretation >>of conformance might be an extrapolation from SNMP/SMI times, but, >>for better or worse, it really has no support in the YANG spec. > > It sounds as though you might be talking past each other. > I believe part of Andy's point is that clients will need to deal > with servers that do not implement (and thus do not advertise) > the augmenting module. But there's (I think) a more interesting > issue beneath this. As I understand it, the restriction on mandatory nodes in augments addresses the opposite situation where the server addresses both the original and augmenting module, whereas the client supports only the original one. > > Let's start with module M. Let's say M is for "modem" (to pick > an obsolete but widely understood resource). > Two different augmenting modules, F (for FSK - frequency > shift keying) and Q (for QAM - quadrature amplitude modulation) > are developed. Let us say that F and Q are mutually incompatible. > > A system with multiple Ms could well have both M+F and M+Q modems, > but (if we claim F & Q are incompatible) could not have M+F+Q. A solution could be similar to what "ietf-interfaces" does: list modem { key name; leaf name { ... } leaf type { ... } ... } F and G would then augment the "modem" list, for example: augment "/.../M:modem" { when "M:type = 'FSK'"; ... } Module M can also implement the concept of system-controlled modem entries. The server then may advertise M+F or M+Q or M+F+Q depending on the supported technologies. Of course, the author of module M has to anticipate that there may be multiple modems of different types. If M only has container modem { ... } then we are stuck. The problem with the above approach is that either F or Q may need some mandatory parameters to be configured for which no (static) defaults exist - but this condition cannot be properly specified in the data model. That's what this thread is about. > If naked M is to be prohibited in systems (also) supporting F or Q > or both, we don't currently have a mechanism to do so. I don't know whether naked M exactly needs to be prohibited (as an "abstract class"). It causes no harm, as naked "ietf-interfaces", only it is of limited use because there isn't much to be configured. A server implementor should have an idea about what needs to be configured, and will therefore add one or more augmenting modules that will be advertised along with M. Lada > > Randy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Aug 25 05:01:04 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23BB01B2F9C for ; Tue, 25 Aug 2015 05:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aw3wAjA4gz93 for ; Tue, 25 Aug 2015 05:01:01 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 80DD61B2F9B for ; Tue, 25 Aug 2015 05:01:01 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 645BA1AE0486; Tue, 25 Aug 2015 14:01:00 +0200 (CEST) Date: Tue, 25 Aug 2015 14:01:02 +0200 (CEST) Message-Id: <20150825.140102.2117420320519166894.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <20976241.1440444036499.JavaMail.root@mswamui-andean.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: randy_presuhn@mindspring.com, netmod@ietf.org Subject: Re: [netmod] Y26 again, sorry X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 12:01:03 -0000 Hi, I think this could work (thanks Robert; maybe this is what you meant!): container zones { list zone { ... list rrset { ... leaf type { type identityref { ... } } list rdata { key id; ... choice type-specific-params { mandatory true; // to be augmented with type-specific nodes } } } } } And then in another module: augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" + "/type-specific-parameters" { when "derived-from-or-self(../dnsz:type,'iana-dns-parameters'," + "'TLSA')"; leaf certificate-usage { mandatory true; ... } } The empty mandatory choice formally tells the client that additional cases are expected. (If the empty choice looks fishy, it is probably often possible to define at least one case inline...) This pattern is nice to the client, since there is no way an additional augmenting module can break a working client. /martin From nobody Tue Aug 25 05:33:23 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 732731B2D26 for ; Tue, 25 Aug 2015 05:33:21 -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 KylEGDYa8u9T for ; Tue, 25 Aug 2015 05:33:20 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCC611B2BB0 for ; Tue, 25 Aug 2015 05:33:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=639; q=dns/txt; s=iport; t=1440505999; x=1441715599; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=NlUSXb3vfmT8aimq53yUuhYcR08I8Lk8HDuIBZboIWw=; b=RXB8gM0kXVrPazw+Rq0ejvcnezMwJZdPUz42whyXqpJB0Y3i2Mt6rPq5 doSMv1/53RYMzz6p+Mg6mEzhQbxeed4xeFAxbXg3R1qTUNZBi42SQbcC9 ORGJXW3QGpvYjDndBg3xJF8pu+m9V5ViwKrEVDdeMM1t92Zkz8kmeswCg o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CWAgDYX9xV/5xdJa1dgxuBQ718AQmHcgKBNzgUAQEBAQEBAX8LhCUBBDpRASoULxMmAQQbiCaiZqUCAQEBBwEBAQEBHZAwg1CBFAWVNAELjGeBSYQwlFUmg36COYEEAQEB X-IronPort-AV: E=Sophos;i="5.15,745,1432598400"; d="scan'208";a="21480939" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 25 Aug 2015 12:33:19 +0000 Received: from XCH-ALN-017.cisco.com (xch-aln-017.cisco.com [173.36.7.27]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t7PCXJUn000481 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 25 Aug 2015 12:33:19 GMT Received: from xch-aln-017.cisco.com (173.36.7.27) by XCH-ALN-017.cisco.com (173.36.7.27) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 25 Aug 2015 07:33:18 -0500 Received: from xhc-rcd-x01.cisco.com (173.37.183.75) by xch-aln-017.cisco.com (173.36.7.27) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Tue, 25 Aug 2015 07:33:18 -0500 Received: from xmb-aln-x03.cisco.com ([169.254.6.3]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0248.002; Tue, 25 Aug 2015 07:33:18 -0500 From: "Martin Ciglan -X (mciglan - PANTHEON TECHNOLOGIES at Cisco)" To: "netmod@ietf.org" Thread-Topic: issue and question: YANG short-case-stmt in augment-stmt or uses-augment-stmt Thread-Index: AdDfMM/O6VDNtVHdSaS0z8BKaEty3g== Date: Tue, 25 Aug 2015 12:33:17 +0000 Message-ID: Accept-Language: sk-SK, en-US Content-Language: sk-SK X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.37.102.14] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [netmod] issue and question: YANG short-case-stmt in augment-stmt or uses-augment-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 12:33:21 -0000 Hello I've come across a yang module which defines a short-case-stmt in augment-s= tmt or uses-augment-stmt Something like this: grouping grp1 { uses grp2 { augment mychoice { leaf myleaf1 { type string; } } } } grouping grp2 { choice mychoice { leaf myleaf2 { type string; } =20 } } Based on my findings in RFC6020 and errata, this is invalid and there shoul= d be only full case-stmt in augment/uses-augment.=20 Can you confirm please? Many thanks in advance. Best Regards Martin = From nobody Tue Aug 25 05:35:10 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0B21B2FB5 for ; Tue, 25 Aug 2015 05:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.761 X-Spam-Level: X-Spam-Status: No, score=-4.761 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_74=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WM7ZUeXEVQJ for ; Tue, 25 Aug 2015 05:35:07 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A1291B2FAF for ; Tue, 25 Aug 2015 05:35:07 -0700 (PDT) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 14DB71813F1; Tue, 25 Aug 2015 14:35:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1440506106; bh=ETH4vC1bp2UBxwWlFXrczIoJMXho8by6dCUFEDxD+Mw=; h=From:Date:To; b=cmsajrRwxrKqii1s7IBQxdVSuOIeuw0IsJTeXXeO/UHMvKyvWgEcti8Y7olR7X0ca zJhgIITKuR0RMqzV2x7La/VTPzY0sUQ5yS3zsEpPMTZLB6MLKr5sEiZCWm2292iXKh 78z+C30qj0ruG9kfmyoSdPM9lZa3dil7aA8T1ziI= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: <20150825.140102.2117420320519166894.mbj@tail-f.com> Date: Tue, 25 Aug 2015 14:35:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4BF691CC-C048-49AB-BD14-2207D10F2922@nic.cz> References: <20976241.1440444036499.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> <20150825.140102.2117420320519166894.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Randy Presuhn , netmod@ietf.org Subject: Re: [netmod] Y26 again, sorry X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 12:35:10 -0000 > On 25 Aug 2015, at 14:01, Martin Bjorklund wrote: >=20 > Hi, >=20 > I think this could work (thanks Robert; maybe this is what you > meant!): >=20 > container zones { > list zone { > ... > list rrset { > ... > leaf type { > type identityref { ... } > } > list rdata { > key id; > ... > choice type-specific-params { > mandatory true; > // to be augmented with type-specific nodes > } > } > } > } > } >=20 > And then in another module: >=20 > augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" > + "/type-specific-parameters" { > when "derived-from-or-self(../dnsz:type,'iana-dns-parameters'," > + "'TLSA')"; >=20 > leaf certificate-usage { > mandatory true; > ... > } > } >=20 > The empty mandatory choice formally tells the client that additional > cases are expected. >=20 > (If the empty choice looks fishy, it is probably often possible to > define at least one case inline...) >=20 > This pattern is nice to the client, since there is no way an > additional augmenting module can break a working client. Yes, I just tried very similar test modules with pyang, and DSDL seems = to validate instance data as expected: at least one case has to be = present, so no valid instance exists for the =E2=80=9Cabstract=E2=80=9D = module alone. I think it is a better approach to subclassing than augment+when. Lada >=20 >=20 > /martin >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Aug 25 05:48:55 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82EDD1B2CBD for ; Tue, 25 Aug 2015 05:48:54 -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_74=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 7hVqPjmqQx-g for ; Tue, 25 Aug 2015 05:48:53 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2C21B29F9 for ; Tue, 25 Aug 2015 05:48:53 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 05C4B1AE0486; Tue, 25 Aug 2015 14:48:52 +0200 (CEST) Date: Tue, 25 Aug 2015 14:48:54 +0200 (CEST) Message-Id: <20150825.144854.480684454364367671.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <4BF691CC-C048-49AB-BD14-2207D10F2922@nic.cz> References: <20150825.140102.2117420320519166894.mbj@tail-f.com> <4BF691CC-C048-49AB-BD14-2207D10F2922@nic.cz> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: randy_presuhn@mindspring.com, netmod@ietf.org Subject: Re: [netmod] Y26 again, sorry X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 12:48:54 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+ID4gT24gMjUgQXVn IDIwMTUsIGF0IDE0OjAxLCBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4gd3JvdGU6 DQo+ID4gDQo+ID4gSGksDQo+ID4gDQo+ID4gSSB0aGluayB0aGlzIGNvdWxkIHdvcmsgKHRoYW5r cyBSb2JlcnQ7IG1heWJlIHRoaXMgaXMgd2hhdCB5b3UNCj4gPiBtZWFudCEpOg0KPiA+IA0KPiA+ ICBjb250YWluZXIgem9uZXMgew0KPiA+ICAgIGxpc3Qgem9uZSB7DQo+ID4gICAgICAuLi4NCj4g PiAgICAgIGxpc3QgcnJzZXQgew0KPiA+ICAgICAgICAuLi4NCj4gPiAgICAgICAgbGVhZiB0eXBl IHsNCj4gPiAgICAgICAgICB0eXBlIGlkZW50aXR5cmVmIHsgLi4uIH0NCj4gPiAgICAgICAgfQ0K PiA+ICAgICAgICBsaXN0IHJkYXRhIHsNCj4gPiAgICAgICAgICBrZXkgaWQ7DQo+ID4gICAgICAg ICAgLi4uDQo+ID4gICAgICAgICAgY2hvaWNlIHR5cGUtc3BlY2lmaWMtcGFyYW1zIHsNCj4gPiAg ICAgICAgICAgIG1hbmRhdG9yeSB0cnVlOw0KPiA+ICAgICAgICAgICAgLy8gdG8gYmUgYXVnbWVu dGVkIHdpdGggdHlwZS1zcGVjaWZpYyBub2Rlcw0KPiA+ICAgICAgICAgIH0NCj4gPiAgICAgICAg fQ0KPiA+ICAgICAgfQ0KPiA+ICAgIH0NCj4gPiAgfQ0KPiA+IA0KPiA+IEFuZCB0aGVuIGluIGFu b3RoZXIgbW9kdWxlOg0KPiA+IA0KPiA+ICBhdWdtZW50ICIvZG5zejp6b25lcy9kbnN6OnpvbmUv ZG5zejpycnNldC9kbnN6OnJkYXRhIg0KPiA+ICAgICAgICArICIvdHlwZS1zcGVjaWZpYy1wYXJh bWV0ZXJzIiB7DQo+ID4gICAgd2hlbiAiZGVyaXZlZC1mcm9tLW9yLXNlbGYoLi4vZG5zejp0eXBl LCdpYW5hLWRucy1wYXJhbWV0ZXJzJywiDQo+ID4gICAgICAgKyAiJ1RMU0EnKSI7DQo+ID4gDQo+ ID4gICAgbGVhZiBjZXJ0aWZpY2F0ZS11c2FnZSB7DQo+ID4gICAgICBtYW5kYXRvcnkgdHJ1ZTsN Cj4gPiAgICAgIC4uLg0KPiA+ICAgIH0NCj4gPiAgfQ0KPiA+IA0KPiA+IFRoZSBlbXB0eSBtYW5k YXRvcnkgY2hvaWNlIGZvcm1hbGx5IHRlbGxzIHRoZSBjbGllbnQgdGhhdCBhZGRpdGlvbmFsDQo+ ID4gY2FzZXMgYXJlIGV4cGVjdGVkLg0KPiA+IA0KPiA+IChJZiB0aGUgZW1wdHkgY2hvaWNlIGxv b2tzIGZpc2h5LCBpdCBpcyBwcm9iYWJseSBvZnRlbiBwb3NzaWJsZSB0bw0KPiA+IGRlZmluZSBh dCBsZWFzdCBvbmUgY2FzZSBpbmxpbmUuLi4pDQo+ID4gDQo+ID4gVGhpcyBwYXR0ZXJuIGlzIG5p Y2UgdG8gdGhlIGNsaWVudCwgc2luY2UgdGhlcmUgaXMgbm8gd2F5IGFuDQo+ID4gYWRkaXRpb25h bCBhdWdtZW50aW5nIG1vZHVsZSBjYW4gYnJlYWsgYSB3b3JraW5nIGNsaWVudC4NCj4gDQo+IFll cywgSSBqdXN0IHRyaWVkIHZlcnkgc2ltaWxhciB0ZXN0IG1vZHVsZXMgd2l0aCBweWFuZywgYW5k IERTREwgc2VlbXMNCj4gdG8gdmFsaWRhdGUgaW5zdGFuY2UgZGF0YSBhcyBleHBlY3RlZDogYXQg bGVhc3Qgb25lIGNhc2UgaGFzIHRvIGJlDQo+IHByZXNlbnQsIHNvIG5vIHZhbGlkIGluc3RhbmNl IGV4aXN0cyBmb3IgdGhlIOKAnGFic3RyYWN04oCdIG1vZHVsZSBhbG9uZS4NCj4gDQo+IEkgdGhp bmsgaXQgaXMgYSBiZXR0ZXIgYXBwcm9hY2ggdG8gc3ViY2xhc3NpbmcgdGhhbiBhdWdtZW50K3do ZW4uDQoNCkl0IGlzIGF1Z2VtbnQtY2hvaWNlK3doZW4uDQoNCkkgYWdyZWUgaXQgc29sdmVzIHRo ZSAic3ViY2xhc3NpbmciIHVzZSBjYXNlLCBidXQgaXQgaGFzIGl0cw0KbGltaXRhdGlvbnMuICBG b3IgZXhhbXBsZSwgeW91IGNhbm5vdCBoYXZlIHR3byBzZXBhcmF0ZSBtb2R1bGVzDQphdWdtZW50 IHdpdGggdGhlIHNhbWUgdHlwZS4gIEJ1dCB0aGVuLCBpbiBzdWNoIGEgY2FzZSB5b3UgY2FuDQpz dGlsbCB0byB0aGUgb2xkIGF1Z21lbnQtcC1jb250YWluZXIrd2hlbi4NCg0KDQovbWFydGluDQo= From nobody Tue Aug 25 06:01:36 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA561B2E26 for ; Tue, 25 Aug 2015 06:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.239 X-Spam-Level: X-Spam-Status: No, score=0.239 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_74=0.6, 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 E6a8lHY49Vqu for ; Tue, 25 Aug 2015 06:01:33 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26E1B1B2EA1 for ; Tue, 25 Aug 2015 06:01:32 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:5ca8:c28e:2463:2903] (unknown [IPv6:2001:718:1a02:1:5ca8:c28e:2463:2903]) by mail.nic.cz (Postfix) with ESMTPSA id B7DB1181882; Tue, 25 Aug 2015 15:01:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1440507690; bh=0ZRUq2JCbsrjddatX28kqT3seHNo+fz5E+xPC5U31Qs=; h=From:Date:To; b=fiVx7t4foewvMoh9htliahno1WnMVAn3AR1UHIzwrxfl/6nGbzmPkD389JJMe9dvp syokSM4SNVC08WRrtRmHu4yOlE1eW9ep0gHZsEHuwyD2PZA6JjEn0hZVYixc0TKpbY z2xPvfS5634C9xQiLxmRiI5D8wQ/GlCaIQJ5HsvM= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: <20150825.144854.480684454364367671.mbj@tail-f.com> Date: Tue, 25 Aug 2015 15:01:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150825.140102.2117420320519166894.mbj@tail-f.com> <4BF691CC-C048-49AB-BD14-2207D10F2922@nic.cz> <20150825.144854.480684454364367671.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Randy Presuhn , netmod@ietf.org Subject: Re: [netmod] Y26 again, sorry X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 13:01:34 -0000 > On 25 Aug 2015, at 14:48, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >>=20 >>> On 25 Aug 2015, at 14:01, Martin Bjorklund wrote: >>>=20 >>> Hi, >>>=20 >>> I think this could work (thanks Robert; maybe this is what you >>> meant!): >>>=20 >>> container zones { >>> list zone { >>> ... >>> list rrset { >>> ... >>> leaf type { >>> type identityref { ... } >>> } >>> list rdata { >>> key id; >>> ... >>> choice type-specific-params { >>> mandatory true; >>> // to be augmented with type-specific nodes >>> } >>> } >>> } >>> } >>> } >>>=20 >>> And then in another module: >>>=20 >>> augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" >>> + "/type-specific-parameters" { >>> when "derived-from-or-self(../dnsz:type,'iana-dns-parameters'," >>> + "'TLSA')"; >>>=20 >>> leaf certificate-usage { >>> mandatory true; >>> ... >>> } >>> } >>>=20 >>> The empty mandatory choice formally tells the client that additional >>> cases are expected. >>>=20 >>> (If the empty choice looks fishy, it is probably often possible to >>> define at least one case inline...) >>>=20 >>> This pattern is nice to the client, since there is no way an >>> additional augmenting module can break a working client. >>=20 >> Yes, I just tried very similar test modules with pyang, and DSDL = seems >> to validate instance data as expected: at least one case has to be >> present, so no valid instance exists for the =E2=80=9Cabstract=E2=80=9D= module alone. >>=20 >> I think it is a better approach to subclassing than augment+when. >=20 > It is augemnt-choice+when. when isn=E2=80=99t strictly necessary here because different cases = cannot appear together. The schema is much cleaner, which is also = immediately visible on the tree output. >=20 > I agree it solves the "subclassing" use case, but it has its > limitations. For example, you cannot have two separate modules > augment with the same type. But then, in such a case you can > still to the old augment-p-container+when. I am not sure I understand exactly what you mean but perhaps the second = augmenting module could then augment the case node in the first augment.=20= Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Aug 25 06:06:51 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2BB1B2F73 for ; Tue, 25 Aug 2015 06:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEqGihPqlUUw for ; Tue, 25 Aug 2015 06:06:45 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6242D1B2F77 for ; Tue, 25 Aug 2015 06:06:44 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 2C6D51CC0047; Tue, 25 Aug 2015 15:06:45 +0200 (CEST) From: Ladislav Lhotka To: "Martin Ciglan -X \(mciglan - PANTHEON TECHNOLOGIES at Cisco\)" , "netmod\@ietf.org" In-Reply-To: References: User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Tue, 25 Aug 2015 15:06:41 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] issue and question: YANG short-case-stmt in augment-stmt or uses-augment-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 13:06:49 -0000 Hi Martin, as far as I can tell, these groupings are OK, and pyang also doesn't complain. Ahoj, L=C3=A1=C4=8Fa "Martin Ciglan -X (mciglan - PANTHEON TECHNOLOGIES at Cisco)" writes: > Hello > > I've come across a yang module which defines a short-case-stmt in augment= -stmt or uses-augment-stmt > > Something like this: > > grouping grp1 { > uses grp2 { > augment mychoice { > leaf myleaf1 { > type string; > } > } > } > } > > grouping grp2 { > choice mychoice { > leaf myleaf2 { > type string; > }=20=20 > } > } > > Based on my findings in RFC6020 and errata, this is invalid and there sho= uld be only full case-stmt in augment/uses-augment.=20 > > Can you confirm please? Many thanks in advance. > > Best Regards > > Martin > >=20=20=20=20=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Aug 25 07:07:54 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5A461AD05D for ; Tue, 25 Aug 2015 07:07:52 -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_74=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 odvvzra5liAV for ; Tue, 25 Aug 2015 07:07: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 783251ACD52 for ; Tue, 25 Aug 2015 07:07:51 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 51DC41AE0486; Tue, 25 Aug 2015 16:07:49 +0200 (CEST) Date: Tue, 25 Aug 2015 16:07:51 +0200 (CEST) Message-Id: <20150825.160751.94466597464835009.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <4BF691CC-C048-49AB-BD14-2207D10F2922@nic.cz> <20150825.144854.480684454364367671.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=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: randy_presuhn@mindspring.com, netmod@ietf.org Subject: Re: [netmod] Y26 again, sorry X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 14:07:52 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+ID4gT24gMjUgQXVn IDIwMTUsIGF0IDE0OjQ4LCBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4gd3JvdGU6 DQo+ID4gDQo+ID4gTGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gPj4g DQo+ID4+PiBPbiAyNSBBdWcgMjAxNSwgYXQgMTQ6MDEsIE1hcnRpbiBCam9ya2x1bmQgPG1iakB0 YWlsLWYuY29tPiB3cm90ZToNCj4gPj4+IA0KPiA+Pj4gSGksDQo+ID4+PiANCj4gPj4+IEkgdGhp bmsgdGhpcyBjb3VsZCB3b3JrICh0aGFua3MgUm9iZXJ0OyBtYXliZSB0aGlzIGlzIHdoYXQgeW91 DQo+ID4+PiBtZWFudCEpOg0KPiA+Pj4gDQo+ID4+PiBjb250YWluZXIgem9uZXMgew0KPiA+Pj4g ICBsaXN0IHpvbmUgew0KPiA+Pj4gICAgIC4uLg0KPiA+Pj4gICAgIGxpc3QgcnJzZXQgew0KPiA+ Pj4gICAgICAgLi4uDQo+ID4+PiAgICAgICBsZWFmIHR5cGUgew0KPiA+Pj4gICAgICAgICB0eXBl IGlkZW50aXR5cmVmIHsgLi4uIH0NCj4gPj4+ICAgICAgIH0NCj4gPj4+ICAgICAgIGxpc3QgcmRh dGEgew0KPiA+Pj4gICAgICAgICBrZXkgaWQ7DQo+ID4+PiAgICAgICAgIC4uLg0KPiA+Pj4gICAg ICAgICBjaG9pY2UgdHlwZS1zcGVjaWZpYy1wYXJhbXMgew0KPiA+Pj4gICAgICAgICAgIG1hbmRh dG9yeSB0cnVlOw0KPiA+Pj4gICAgICAgICAgIC8vIHRvIGJlIGF1Z21lbnRlZCB3aXRoIHR5cGUt c3BlY2lmaWMgbm9kZXMNCj4gPj4+ICAgICAgICAgfQ0KPiA+Pj4gICAgICAgfQ0KPiA+Pj4gICAg IH0NCj4gPj4+ICAgfQ0KPiA+Pj4gfQ0KPiA+Pj4gDQo+ID4+PiBBbmQgdGhlbiBpbiBhbm90aGVy IG1vZHVsZToNCj4gPj4+IA0KPiA+Pj4gYXVnbWVudCAiL2Ruc3o6em9uZXMvZG5zejp6b25lL2Ru c3o6cnJzZXQvZG5zejpyZGF0YSINCj4gPj4+ICAgICAgICsgIi90eXBlLXNwZWNpZmljLXBhcmFt ZXRlcnMiIHsNCj4gPj4+ICAgd2hlbiAiZGVyaXZlZC1mcm9tLW9yLXNlbGYoLi4vZG5zejp0eXBl LCdpYW5hLWRucy1wYXJhbWV0ZXJzJywiDQo+ID4+PiAgICAgICsgIidUTFNBJykiOw0KPiA+Pj4g DQo+ID4+PiAgIGxlYWYgY2VydGlmaWNhdGUtdXNhZ2Ugew0KPiA+Pj4gICAgIG1hbmRhdG9yeSB0 cnVlOw0KPiA+Pj4gICAgIC4uLg0KPiA+Pj4gICB9DQo+ID4+PiB9DQo+ID4+PiANCj4gPj4+IFRo ZSBlbXB0eSBtYW5kYXRvcnkgY2hvaWNlIGZvcm1hbGx5IHRlbGxzIHRoZSBjbGllbnQgdGhhdCBh ZGRpdGlvbmFsDQo+ID4+PiBjYXNlcyBhcmUgZXhwZWN0ZWQuDQo+ID4+PiANCj4gPj4+IChJZiB0 aGUgZW1wdHkgY2hvaWNlIGxvb2tzIGZpc2h5LCBpdCBpcyBwcm9iYWJseSBvZnRlbiBwb3NzaWJs ZSB0bw0KPiA+Pj4gZGVmaW5lIGF0IGxlYXN0IG9uZSBjYXNlIGlubGluZS4uLikNCj4gPj4+IA0K PiA+Pj4gVGhpcyBwYXR0ZXJuIGlzIG5pY2UgdG8gdGhlIGNsaWVudCwgc2luY2UgdGhlcmUgaXMg bm8gd2F5IGFuDQo+ID4+PiBhZGRpdGlvbmFsIGF1Z21lbnRpbmcgbW9kdWxlIGNhbiBicmVhayBh IHdvcmtpbmcgY2xpZW50Lg0KPiA+PiANCj4gPj4gWWVzLCBJIGp1c3QgdHJpZWQgdmVyeSBzaW1p bGFyIHRlc3QgbW9kdWxlcyB3aXRoIHB5YW5nLCBhbmQgRFNETCBzZWVtcw0KPiA+PiB0byB2YWxp ZGF0ZSBpbnN0YW5jZSBkYXRhIGFzIGV4cGVjdGVkOiBhdCBsZWFzdCBvbmUgY2FzZSBoYXMgdG8g YmUNCj4gPj4gcHJlc2VudCwgc28gbm8gdmFsaWQgaW5zdGFuY2UgZXhpc3RzIGZvciB0aGUg4oCc YWJzdHJhY3TigJ0gbW9kdWxlIGFsb25lLg0KPiA+PiANCj4gPj4gSSB0aGluayBpdCBpcyBhIGJl dHRlciBhcHByb2FjaCB0byBzdWJjbGFzc2luZyB0aGFuIGF1Z21lbnQrd2hlbi4NCj4gPiANCj4g PiBJdCBpcyBhdWdlbW50LWNob2ljZSt3aGVuLg0KPiANCj4gd2hlbiBpc27igJl0IHN0cmljdGx5 IG5lY2Vzc2FyeSBoZXJlIGJlY2F1c2UgZGlmZmVyZW50IGNhc2VzIGNhbm5vdA0KPiBhcHBlYXIg dG9nZXRoZXIuDQoNCldlbGwsIHRoZSB3aGVuIHN0YXRlbWVudCBpcyBuZWVkZWQgdG8gbWFrZSBz dXJlIHRoYXQgeW91IGNvbmZpZ3VyZQ0Kbm9kZXMgZnJvbSBhIGNhc2UgdGhhdCBtYXRjaGVzIHRo ZSBzcGVjaWZpZWQgdHlwZS4NCg0KDQovbWFydGluDQo= From nobody Tue Aug 25 09:23:20 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB9AA1A00FF for ; Tue, 25 Aug 2015 09:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1sl9Vy4hCcf for ; Tue, 25 Aug 2015 09:23:16 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACDB1A00FD for ; Tue, 25 Aug 2015 09:23:15 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 54B831CC0047; Tue, 25 Aug 2015 18:23:17 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20150825.130359.1125823029773095202.mbj@tail-f.com> References: <20150825.130359.1125823029773095202.mbj@tail-f.com> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Tue, 25 Aug 2015 18:23:12 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] LL review of 6020bis-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 16:23:20 -0000 Martin Bjorklund writes: ... >> 2. I think it would be useful to include text (perhaps in >> sec. 4.2.2) describing the schema tree and data tree, and >> introducing appropriate terms so that, e.g., nodes in either >> tree can be clearly distinguished in the subsequent text. In >> my experience, this causes a lot of confusion. >>=20 >> For example, sec. 4.2.2.1 says: ' A leaf node contains simple >> data like an integer or a string.' And then sec. 7.6: ' The >> "leaf" statement is used to define a leaf node in the schema >> tree.' If the leaf node is in the schema tree, then it cannot >> contain any value. > > The "leaf" statement defines a node in the schema tree. This can be > instantiated in a data tree. A leaf node in the data tree contains a > simple value. > > Since section 4.2 is really just intended as an overview, maybe we can > s/A leaf node contains/A leaf contains/ (and similar for container)? What about "A leaf instance contains ..." > >> 3. It's necessary to clearly separate properties of the data tree >> from properties of XML encoding. For instance, it is an >> inherent property of a container instance in the data tree >> that its children are unordered, or ordered in RPC >> input/output. Yet this is only specified in sec. 7.5.7 (XML >> Mapping Rules). > > I think this is a property of the XML encoding, not an inherent > property of the container. In JSON, all children are always > unordered. I assume that data in whatever encoding contribute to the same (conceptual) data tree, so it would be useful to know the properties of the latter, such as whether some document order exists (as in XML) or not (as in JSON).=20 > >> Similarly, the namespace of a module and XML namespace that's >> used in XML encoding are IMO two different things (cf. sec >> 5.3). > > Yes. Do you have any specific edits in mind? Section 5.3 IMO can't say that "All YANG definitions are specified within a module that is bound to a particular XML namespace [XML-NAMES],=C2=A0..." because XML namespaces really make sense only in XML. I'd suggest something like this: A YANG module defines a namespace that is identified by the module name. Names of all YANG definitions specified in a module belong to its namespace. And then Statements "namespace" and "prefix" define a mapping of the module namespace to the XML namespace and recommended prefix taht are used in XML encoding. > >> 4. Terms "instance"/"instantiate"/"instatiation" are used in a >> loose way without being properly defined, probably as SNMP >> legacy. The XML term "instance document" adds yet another >> meaning. > > I'm not sure these are SNMP specific terms. I thought they were more > generic. Do you have any proposed edits? I am not sure what it exactly means. For example, what is an instance in the case of a list/leaf-list: is it the complete array or an individual list entry? > >> 5. A term is needed for describing a data model of a particular >> server, i.e. a collection of modules + supported features (+ >> deviations). I've used "data model", see >> https://github.com/mbj4668/pyang/wiki/Tutorial#yang-data-model > > The term "data model" is already used in a much more generic way in > 6020. > > "server YANG data model" maybe. Perhaps we could use "data model" in the general sense as defined in sec. 3, and then "YANG data model" as the substance of the YANG "contract", which can be exactly constructed from the server's hello or yang-library. > >> 6. As J=C3=BCrgen suggested, sections "XML Mapping Rules" should be >> more appropriately called "XML Encoding Rules". > > Fixed. > >> 7. I'd remove all mentions of submodules including other >> submodules, circular includes etc. because it is now >> confusing. If "include" is ignored in submodules, there is no >> need to bother with any rules. This sentence in sec. 7.1.6 >> should be enough: 'For backward compatibility with YANG >> version 1, the "include" statement is permitted in a submodule >> but has no effect there.' > > I found only this sentence: > > Submodules are only allowed to include other submodules belonging to > the same module. > > which I have now removed. - Sec. 4.1: "Derived types and groupings can be defined in one module or submodule and used in either that location or in another module or submodule that imports or includes it." Remove "or submodule" twice and "or includes". - Sec. 5.1: "There MUST NOT be any circular chains of imports or includes." Remove "or includes" - since includes in submodules are a no-op, circular includes cannot happen. =20=20 > >> **** Sec. 3 >> - Shouldn't the term "data tree" also cover the contents of RPC >> input/output, actions and notifications? > > Yes, probably. But then we need to have a term for some of the > current usages of "data tree". Maybe "datastore" works (this term is > already used). What current usages of "data tree" do you mean? Sec. 3: OLD o data tree: The instantiated tree of configuration and state data on a device. NEW o data tree: The instantiated tree of configuration, state data, combined configuration and state data, RPC input or output, or notification. >> **** Sec. 6.1.3 >> I think the rules for whitespace trimming are confusing and have >> very little practical uses, so I'd recommend to remove them >> entirely. However, if the decision is to keep them, the following >> ambiguities need to be addressed: >> - It is unclear whether '\n' is equivalent to the literal LF >> character in the trimming process, i.e. whether the >> substitution of escape sequences is done before or after the >> trimming. > > How does this matter? Are the following two defaults identical or not? default "foo bar"; default "foo\n\t bar"; > >> - Is tab character treated as 8 spaces also before the opening >> double quote? Example: >>=20 >> description "This is a long >> text." >>=20 >> Does it matter whether the character between "description" and >> the opening double quote is a space or tab character? (Both >> cases may have identical visual rendering depending on the >> column where the statement starts.) > > I would think so. I think whitespace-trimming in general is very > useful, but the tab-expansion is a bit confusing. I think it would be > ok to remove the expansion of tab with 8 spaces. I don't think they are that useful. In practice, such multiline strings only appear in descriptions and references where whitespace trimming is pre= tty much irrelevant. Using it elsewhere means asking for troubles - the "+" operator should be used for splitting long strings. > >> **** Sec. 6.2 >> OLD >> Implementations MUST support identifiers up to 64 characters in >> length. >> NEW >> Implementations are not required to support identifier longer >> than 64 character. >>=20 >> (The current formulation can IMO be understood so that identifiers >> longer than 64 chars cannot be supported.) > > How about: > > Implementations MUST support identifiers up to 64 characters in > length, and MAY support longer identifiers. OK. > >> **** Sec. 6.3.1 >> What does the last paragraph mean? In particular: if an extension >> is imported and used in a module that the server advertises, >> could the server ignore that extension? > > This is being in discussed in a separate thread. Yup. > >> **** Sec. 6.4 >> - 'The data model used in the XPath expressions is the same as >> that used in XPath 1.0 [XPATH], =E2=80=A6' >>=20 >> I think some explanation is needed describing how a data tree >> is mapped onto the (restricted) XPath data model. Specifically: >> * The data tree has no concept of document order, except for >> RPC input/output. The spec should say implementations need >> to choose some document order but how it is done is >> undefined, so XPath expressions in YANG modules shouldn't >> rely on the document order. > > Ok, makes sense. How about adding a new paragraph three: > > The data tree has no concept of document order. An implementation > needs to choose some document order but how it is done is an > implementation decision. This means that XPath expressions in YANG > modules SHOULD not rely on any specific document order. Good. > >> * It might be useful to define how namespace nodes representing >> YANG namespaces appear in the XPath tree so that the >> namespace:: axis works in a deterministic fashion. For >> example, one could say that all these namespaces are in scope >> for all elements corresponding to YANG data nodes. One could >> use it, e.g. to determine whether a particular YANG module is >> a part of the data model. > > Why wouldn't the namespace axis work in a deterministic fashion? All > nodes defined in a module have the same XML namespace, which is > well-defined. The content of the namespace:: axis depends on how exactly XML namespaces are specified. For example, it would be different for the "foo" element in each of the following three cases: xmlns:bar=3D"http://example.com/bar"> I'd suggest to have it by definition so that all namespaces are specified outside the data tree - as if the definitions are on the encapsulating NETCONF or - and with prefixes that are defined in the modules (unless there is a conflict). This would mean that instances of all data nodes have the same namespace:: axis. > >> - Another possible source of surprises are equality tests (but >> maybe it belongs to 6087bis). With >>=20 >> container top { >> must "x =3D y"; >> leaf x { >> type decimal64 { >> fraction-digits 1; >> } >> } >> leaf y { >> type uint8; >> } >> } >>=20 >> the following instance violates the must constraint: >>=20 >> >> 1.0 >> 1 >> > > If it is belongs anywhere it would be in 6087. But this is just how > XPath works, so I am not sure it is needed... Yes, this is how XPath works on XML documents, but if YANG XPath expressions are evaluated conceptually on the data tree (as Juergen suggested), it is less clear - it depends on whether type infomation is available in the data tree. I wouldn't be surprised if 90 % implementors translated "x =3D y" into a numeric equality test. > >> - Canonical values should be used also for RPCs, actions and >> notifications. > > I don't understand what this refers to? Hmm, I probably by mistake looked into original RFC 6020 text. ... > >> **** Sec. 7.5.1 >> - 'In the first style, the container has no meaning of its own, >> existing only to contain child nodes.' >>=20 >> I don't think this is really true, e.g. "must" statement on a >> NP containers adds meaning to it, see Y41. > > Do you have some proposed text? I don't think the existance of a must > statement in the NP-container changes the fact that its presence has > no meaning. OK, you are right. > >> - 'In the second style, the presence of the container itself is >> configuration data, representing a single bit of configuration >> data.' >>=20 >> What about containers with presence outside config=3Dtrue data? > > Fixed. > >> **** Sec. 7.5.7 >> - Is the order of subelements also fixed in action input/output? > > Yes, fixed. (and various other similar places). > >> **** Sec. 7.5.8 >> - ' If a container does not have a "presence" statement and the last >> child node is deleted, the NETCONF server MAY delete the >> container.' >>=20 >> Without further explanation this contradicts the resolution of >> Y41. It should say at least where such containers may be >> deleted (e.g. in the reply to or ). > > I don't agree, since the text now says that for validation purposes, > NP containers *always* exist if its parent exists. OK. > >> **** Sec. 7.6.1 >> - The text is suitable for config, defaults in RPC input/output >> and notifications are covered elsewhere, but what about >> defaults (and mandatory) in state data? > > I don't think this text is excludes state data. I think the semantics of defaults in configuration and state data is different - state data just report (hopefully true) state, so the requirement that "the server MUST operationally behave as if the leaf was present in the data tree with the default value as its value" seems somewhat backwards. > >> **** Sec. 7.7.1 >> - The term "array" suggests some higher-level data structure (as >> in JSON encoding). I'd use "sequence of leaf nodes" instead. > > I think "array" is ok. > >> - s/firewall filters/packet filter/ > > Fixed. > >> **** Sec. 7.7.4 >> - ' The "default" statement MUST NOT be present on nodes where >> "min-elements" has a value greater than or equal to one.' >>=20 >> Why? This should be OK: >>=20 >> leaf-list foo { >> type uint8; >> min-elements 1; >> default 54; >> } > > No, b/c min-elements 1 says that there must be at least one instance, > and the default statement specifies what happens if there are no > instances. OK. > >> **** Sec. 7.7.9 >> - Is the interaction of operations, leaf-list >> default values, and with-defaults modes sufficiently clear? >> See also the thread starting with >> https://mailarchive.ietf.org/arch/msg/netmod/PvMzWfzpYa0bg-S2jErX= 975Y3Jk > > I don't know if we need to add anything. Suggestions? I have to read the text and the mail thread again. I'll come back if I find something. > >> **** Sec. 7.8.6 >> - It would be helpful to include an example of yang:key attribute >> value with multiple (two) keys. I remember somebody asked me >> about that. > > Fixed. > >> **** Sec. 7.9.2 >> - The paragraph about shorthand case statement should more >> explicitly explain that a case node is present in the schema >> tree even for short-case-stmt, and thus schema node identifiers >> always need to include case node identifiers. > > I don't understand how the current text could give the impression that > there is no case node in the schema tree of shorthand cases are used. OLD In this case, the identifier of the case node is the same as the identifier in the branch statement. NEW In this case, the case node still exists in the schema tree, and its identifier is the same as the identifier in the branch statement. Schema node identifiers (Section=C2=A06.5) MUST always explicitly include case node identifiers - if a shorthand case statement is used, the identifier of the branch statement will appear twice.=20 > >> **** Sec. 7.10 >> - The section should also state that the data model for "anydata" >> content may or may not be known at run time. > > How about this: > > NEW: > > An implementation may or may not know the data model used to model a > specific instance of an anydata node. OK. > > >> **** Sec. 7.12 >> - 'For extensions, this means that extensions are applied to the >> grouping node, not the uses node.' >>=20 >> I dont understand what this means. What is the "grouping node"? > > Right; there is no "grouping node" and no "uses node". I suggest we > simply do: > > NEW: > > For extensions, this means that extensions are applied to the > grouping itself. I still don't get the point. How does it apply e.g. to NACM extensions if they are used inside a grouping?=20 > >> **** Sec. 7.13.2 >> - Can a leaf-list also get (new) default values through "refine"? >> If so, how are they combined with the default values defined in >> the grouping? > > Good point. I suggest: > > NEW: > > - A leaf-list node may get a set of default values, or a new set of > default values if it already had defaults; i.e., the set of refined > default values replaces the defaults already given. Yes, this is reasonable. > >> **** Sec. 7.15 >> - 'An action MUST NOT be defined within an rpc, another action or a >> notification, =E2=80=A6' >>=20 >> Also it MUST NOT be defined within leaf and leaf-list, right? > > Right, but this is not allowed according to the grammar. I would still add "leaf and leaf-list" to that sentence. > >> - Can an action defined on a list be applied to the whole list? > > No. > > (It is in general IMO unfortunate that there is no way to manipulate > the whole list.) > >> **** Sec. 7.21.3 >> - Maybe this section should also explain that descriptions are an >> integral part of the data model and may specify, e.g., semantic >> constraints that cannot be expressed formally. > > Can you suggest some text? (I am not sure I understand what you think > is needed to explain...) Unlike comments in programming language, descriptions may contribute to the data model specification. For example, a description can state a semantic constraint that cannot be expressed formally using a "must" statement, or it can specify a dynamic default value for a leaf node.=20 > >> **** Sec. 9.10.2 >> - s/supported by the server/implemented by the server/ > > I think these words mean the same thing. For example, we have (for Sec. 5.6.4 uses strictly "implement". It must be clear that identities defined in modules that are only imported for groupings/typedefs don't appl= y.=20 > the deviate statement): > > The argument "not-supported" indicates that the target node is not > implemented by this device. > > >> **** Sec. 9.10.3 >> The last paragraph should probably be replaced with an advice that >> identityref values or nodesets should never appear as bare >> strings in XPath expressions, and functions derived-from() or >> derived-from-or-self() should be used instead. > > I think the string value needs to be defined. OK, but still some text like this could help: "In general, equality tests involving identityref nodes should be avoided - XPath functions derived-from() or derived-from-or-self() (Section 10.4) should be used instead." > >> Example in >> sec. 9.10.5 should be changed to use derived-from-or-self(). > > I think it reasonable to examplify the string value of an identity. > However, I agree that we should add advice about using > derived-from-or-self(), but I think that should be done in 6087bis. > >> **** Sec. 10.3.1 >> - The document order is undefined in a data tree (also in >> sec. 10.4.1 and 10.4.2). > > Above (for 6.4) you suggested that the document order is > implementation-specific. But that means different implementations may give different results.=20 > >> - I think deref() could return non-empty nodeset only for >> instance-identifiers because for leafref it's not needed. > > Ok...? Do you have any edits in mind? Remove the third paragraph. Unlike instance-identifier, a leafref *instance* doesn't refer to any nodes. > > >> The >> "must" constraint in sec. 10.3.1.1 is better expressed like so: >> '/interface[name=3Dcurrent()]/enabled =3D "true"' > > But then it wouldn't examplify the deref() function, would it ;-) Yes, because for leafrefs it's not needed. I think an example in that section should just use an instance-identifier - see above. > > But maybe this is a better example: > > list interface { > key "name type"; > leaf name { ... } > leaf type { ... } > leaf enabled { > type boolean; > } > ... > } > > container mgmt-interface { > leaf name { > type leafref { > path "/interface/name"; > } > } > leaf type { > type leafref { > path "/interface[name=3Dcurrent()/../name]/type"; > } > must 'deref(.)/../enabled =3D "true"' { > error-message > "The management interface cannot be disabled."; > } > } > } > > >> **** Sec. 13 >> - The ABNF can be made stricter by replacing "[default-stmt]" >> among the substatements of "choice-stmt" with >> "[default-case-stmt]", and then adding >>=20 >> default-case-stmt =3D default-keyword sep node-identifier >> stmtend > > But then it would be tempting to add [default-case-stmt] to > refine-stmt and deviate-* as well. But then we'd get both > [default-stmt] and [default-case-stmt] in these statements. So I > prefer to keep it as is. OK. In fact, the two statements have different semantics, so it might have been better to use a different keyword in the first place, e.g. "default-case". But it's too late now. Lada > > > /martin --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Aug 25 09:28:03 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A66321A0231 for ; Tue, 25 Aug 2015 09:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.761 X-Spam-Level: X-Spam-Status: No, score=-4.761 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_74=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Ee22MDA9nB6 for ; Tue, 25 Aug 2015 09:28:00 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29DF41A0037 for ; Tue, 25 Aug 2015 09:27:43 -0700 (PDT) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id D13C0180C08; Tue, 25 Aug 2015 18:27:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1440520061; bh=ercvbSXTGQtZ8sx7xp0VdRAbjIL59xaCwBIjmNmCKeE=; h=From:Date:To; b=GuCdsbVxylBsPUNIq13efPFs7z4ZS40LY8inoPJXoQTL3xIETVCtH3G+uSCTJi+Kb epPVgMAPdq+diNfA56YJ+dSmx9jMlomKr8cpC8l35PfOQHiXbS3A9Btn+xtkOQhvs8 UQdRm9I0GJV7hEoA7Wby9hHiLoGsHJPDj8GVlRas= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: <20150825.160751.94466597464835009.mbj@tail-f.com> Date: Tue, 25 Aug 2015 18:27:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <56797D25-CBBF-4431-97BD-A8199228DDD0@nic.cz> References: <4BF691CC-C048-49AB-BD14-2207D10F2922@nic.cz> <20150825.144854.480684454364367671.mbj@tail-f.com> <20150825.160751.94466597464835009.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Randy Presuhn , netmod@ietf.org Subject: Re: [netmod] Y26 again, sorry X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 16:28:01 -0000 > On 25 Aug 2015, at 16:07, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >>=20 >>> On 25 Aug 2015, at 14:48, Martin Bjorklund wrote: >>>=20 >>> Ladislav Lhotka wrote: >>>>=20 >>>>> On 25 Aug 2015, at 14:01, Martin Bjorklund wrote: >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> I think this could work (thanks Robert; maybe this is what you >>>>> meant!): >>>>>=20 >>>>> container zones { >>>>> list zone { >>>>> ... >>>>> list rrset { >>>>> ... >>>>> leaf type { >>>>> type identityref { ... } >>>>> } >>>>> list rdata { >>>>> key id; >>>>> ... >>>>> choice type-specific-params { >>>>> mandatory true; >>>>> // to be augmented with type-specific nodes >>>>> } >>>>> } >>>>> } >>>>> } >>>>> } >>>>>=20 >>>>> And then in another module: >>>>>=20 >>>>> augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" >>>>> + "/type-specific-parameters" { >>>>> when "derived-from-or-self(../dnsz:type,'iana-dns-parameters'," >>>>> + "'TLSA')"; >>>>>=20 >>>>> leaf certificate-usage { >>>>> mandatory true; >>>>> ... >>>>> } >>>>> } >>>>>=20 >>>>> The empty mandatory choice formally tells the client that = additional >>>>> cases are expected. >>>>>=20 >>>>> (If the empty choice looks fishy, it is probably often possible to >>>>> define at least one case inline...) >>>>>=20 >>>>> This pattern is nice to the client, since there is no way an >>>>> additional augmenting module can break a working client. >>>>=20 >>>> Yes, I just tried very similar test modules with pyang, and DSDL = seems >>>> to validate instance data as expected: at least one case has to be >>>> present, so no valid instance exists for the =E2=80=9Cabstract=E2=80=9D= module alone. >>>>=20 >>>> I think it is a better approach to subclassing than augment+when. >>>=20 >>> It is augemnt-choice+when. >>=20 >> when isn=E2=80=99t strictly necessary here because different cases = cannot >> appear together. >=20 > Well, the when statement is needed to make sure that you configure > nodes from a case that matches the specified type. Yes, if the type has some meaning on its own. In the case of augments = without choice, something like type has to be present in any case = because otherwise nodes from different cases would get mixed up. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Aug 25 10:25:46 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6A11A87E3 for ; Tue, 25 Aug 2015 10:25:44 -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 l6bX4WpU9Tvh for ; Tue, 25 Aug 2015 10:25:41 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0705.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:705]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A33D1A87E2 for ; Tue, 25 Aug 2015 10:25:41 -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.243.23; Tue, 25 Aug 2015 17:25:37 +0000 Received: from BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.41]) by BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.41]) with mapi id 15.01.0243.020; Tue, 25 Aug 2015 17:25:36 +0000 From: Kent Watsen To: Andy Bierman , Martin Bjorklund Thread-Topic: [netmod] Y34 - root node Thread-Index: AQHQzfwL3STxXfk0JkStKQHFLYxQsZ36YQcAgAAPshCAAAMcgIABIxwkgABu5wCABfPKgIAC/IqAgAAMEQCAAKj7AIAAC1UAgAC+7wCAC50MgIAABoyAgAEhX4CAAA00gIABIKqAgAA8e4CAAdMvAIAADywAgAAX8YCABjf6AA== Date: Tue, 25 Aug 2015 17:25:36 +0000 Message-ID: References: <20150820.101533.1535137181522006328.mbj@tail-f.com> <55D7148C.6090508@cisco.com> <20150821.150158.491063432174006492.mbj@tail-f.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.13] x-microsoft-exchange-diagnostics: 1; BN1PR05MB453; 5:Ahi0Y9j3aiPOLqyj8SEMiQC3tev1fFTpY3bVL7Ai9aYoDqpW+qkhOQTwI7IzVzKATZgeSMHQPqdryDsxPoaidEPI2p/0LyGfuDtoUqYr8QcSHoT9DGYXfa1KbSojwnSovbNgyfnRfbh9BNi5YL9uVw==; 24:QSN+pu5Mp/6e9kGo8+02efhwIXRNeg2XBWJxBbWs4HEtJaRfUK5OY4H1SyZk0Bcep87noJDpmylTbIAeelJIvttSi0xdE0517f9yqXlmNCM=; 20:QmvbBIhks7kU8n0uIjZVS87/iyMM0rcn346bLN4PTTwmEM73p2CtBx1G+9KQndJzK6tybGO5Nw8Ok3nwtSGWYA== 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)(8121501046)(5005006)(3002001); SRVR:BN1PR05MB453; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB453; x-forefront-prvs: 06793E740F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(2656002)(97736004)(81156007)(4001540100001)(2900100001)(2950100001)(62966003)(83506001)(5001770100001)(5002640100001)(4001350100001)(46102003)(77156002)(36756003)(189998001)(10400500002)(99286002)(66066001)(64706001)(106116001)(5007970100001)(102836002)(15975445007)(5001860100001)(5001830100001)(19580395003)(106356001)(5004730100002)(105586002)(92566002)(5001960100002)(93886004)(16236675004)(122556002)(87936001)(86362001)(40100003)(101416001)(50986999)(68736005)(76176999)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB453; H:BN1PR05MB456.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:3; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D200EAAFD22CEkwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Aug 2015 17:25:36.7864 (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: "netmod@ietf.org" Subject: Re: [netmod] Y34 - root node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 17:25:44 -0000 --_000_D200EAAFD22CEkwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I like the idea of relocatable modules. It is almost to say everything def= ined by the IETF should be a grouping, allowing others to assemble the piec= es as they see fit. I do not think it makes sense for IETF to define an ub= er structure, especially using a language mandating forever backwards compa= tibility... How to support logical/virtual systems is a bigger discussion. Certainly = there is a huge data model overlap between the host system and the logical = systems, but some data may only exist in the host system and some data may = only exist in a logical system. Making things more interesting, some data = in the host system (e.g., an interface) can be exported to a logical system= as a read-only value. The way I solved this in another life was using co= nditional enablement [1] on a shared data model to indicate the applicabili= ty of nodes in a context. [1] https://tools.ietf.org/html/draft-kwatsen-conditional-enablement-00 Kent, as a contributor --_000_D200EAAFD22CEkwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <0E2BB91BDE08084AA1217E121C776A18@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

I like the idea of relocatable modules.  It is almost to say ever= ything defined by the IETF should be a grouping, allowing others to assembl= e the pieces as they see fit.  I do not think it makes sense for IETF = to define an uber structure, especially using a language mandating forever backwards compatibility... 

How to support logical/virtual systems is a bigger discussion.   = Certainly there is a huge data model overlap between the host system and th= e logical systems, but some data may only exist in the host system and some= data may only exist in a logical system.  Making things more interesting, some data in the host system (e.g., = an interface) can be exported to a logical system as a read-only value= .   The way I solved this in another life was using conditional enable= ment [1] on a shared data model to indicate the applicability of nodes in a context.

[1] https://tools.ietf.org/html/draft-kwatsen-conditional-enablem= ent-00

Kent, as a contributor



--_000_D200EAAFD22CEkwatsenjunipernet_-- From nobody Tue Aug 25 12:11:33 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9551B2D2D for ; Tue, 25 Aug 2015 12:11:33 -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 JwmZ_KnIEyGS for ; Tue, 25 Aug 2015 12:11:31 -0700 (PDT) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) (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 BEF911B2CE8 for ; Tue, 25 Aug 2015 12:11:30 -0700 (PDT) Received: by lbbsx3 with SMTP id sx3so106161527lbb.0 for ; Tue, 25 Aug 2015 12:11:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=r4ETV6zarBX45dxTwsrHXxxfA7Dztd3iusQlSWWN4pM=; b=dzXrlsHC93/SrlS5y9y+ocDLmZve9aCD/d0e5ZgWu0wkBn+HDt1sFXWJC612rQEX8V HmHna2e2iyhezuCOJKeOm8Awm3f/R6hAzC1sB990WwAPgJosEv5BDq94eNooRimDX2Uv m1EfGJ8XYpiyNlBqnZHgNsAmruuwBDydXPVomxUgAV7YSPSzHptXPZ5IoP1F79bGAKuZ uqQjEFRb1Nl2gGQyq8bRzQM39PNZQ+vfYyOnIdY/Eyc4PMBjcjZrzhbPFXgYmj1n8nCh 0V+Y+fmjGPBr7+SbP/pOefCTAaLZK0WG/YsL9yVQC0Dw9o0ckwDzysiuIeZ3JyuoOAli VM+Q== X-Gm-Message-State: ALoCoQlxC21R2Icmqnee3cjlCqpdnRqr1PzQnBuN6UqcdGRPEWEnXEO7a1AmZDiLIZ6cPGBLh1Ur MIME-Version: 1.0 X-Received: by 10.152.42.132 with SMTP id o4mr3332867lal.88.1440529889228; Tue, 25 Aug 2015 12:11:29 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Tue, 25 Aug 2015 12:11:29 -0700 (PDT) In-Reply-To: References: <20150820.101533.1535137181522006328.mbj@tail-f.com> <55D7148C.6090508@cisco.com> <20150821.150158.491063432174006492.mbj@tail-f.com> Date: Tue, 25 Aug 2015 12:11:29 -0700 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: multipart/alternative; boundary=001a11c34ee456157c051e278044 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y34 - root node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 19:11:33 -0000 --001a11c34ee456157c051e278044 Content-Type: text/plain; charset=UTF-8 On Tue, Aug 25, 2015 at 10:25 AM, Kent Watsen wrote: > > I like the idea of relocatable modules. It is almost to say everything > defined by the IETF should be a grouping, allowing others to assemble the > pieces as they see fit. I do not think it makes sense for IETF to define > an uber structure, especially using a language mandating forever backwards > compatibility... > > YANG groupings are not really relocatable. If any object has a YANG constraint (must/when/path) that is outside the grouping, then the grouping is not really relocatable. Only groupings that have no "external references" can be relocated, and this assumes the YANG is written using only relative roots, not absolute paths. Andy How to support logical/virtual systems is a bigger discussion. Certainly > there is a huge data model overlap between the host system and the logical > systems, but some data may only exist in the host system and some data may > only exist in a logical system. Making things more interesting, some data > in the host system (e.g., an interface) can be exported to a logical system > as a read-only value. The way I solved this in another life was using > conditional enablement [1] on a shared data model to indicate the > applicability of nodes in a context. > > [1] https://tools.ietf.org/html/draft-kwatsen-conditional-enablement-00 > > Kent, as a contributor > > > > --001a11c34ee456157c051e278044 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Aug 25, 2015 at 10:25 AM, Kent Watsen <kwatsen@juniper.net> wrote:

I like the idea of relocatable modules.=C2=A0 It is almost to say ever= ything defined by the IETF should be a grouping, allowing others to assembl= e the pieces as they see fit.=C2=A0 I do not think it makes sense for IETF = to define an uber structure, especially using a language mandating forever backwards compatibility...=C2=A0


YANG groupings are no= t really relocatable.
If any object has a YANG constraint (must/w= hen/path) that is outside the
grouping, then the grouping is not = really relocatable.
Only groupings that have no "external re= ferences" can be relocated,
and this assumes the YANG is wri= tten using only relative roots, not absolute paths.







--001a11c34ee456157c051e278044-- From nobody Tue Aug 25 15:51:14 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A53431B30EC for ; Tue, 25 Aug 2015 15:51:13 -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 zrGGf6Xibjv2 for ; Tue, 25 Aug 2015 15:51:12 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 468481B30ED for ; Tue, 25 Aug 2015 15:51:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2866; q=dns/txt; s=iport; t=1440543072; x=1441752672; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=1zVdJzJMn+UsbANk2dMYuEWHyKmRH2d1yV2QsmY9R0E=; b=j1jgIvyqAb51Glz1Ucneltvjlkt1CaolKyX9ib6meZuLN64vCZi4XcBA ZfoiI1mt2md7Gp45LXrqj5+p3nfU8oRh8sZ9Nji+buZb9DzP7kuc8Prgg B/nrdeclZIpbyDPCTAwb+D1tgUVEtmdDA4wZ2YeHO0p9anISzd94tNe9A M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CBAgAL8NxV/5FdJa1dgxuBQ74LAQmFG4JYAhyBHTgUAQEBAQEBAYEKhCMBAQEEIxFFEAIBCBUFAgYgAgICMBUQAgQBDQ2IJrM1lQkBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSKKNYQ/GhYbB4JpL4EUBZU3AYxymlMmg36BeCUcgQQBAQE X-IronPort-AV: E=Sophos;i="5.17,412,1437436800"; d="scan'208";a="181716834" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Aug 2015 22:51:09 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t7PMp90b005168 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 25 Aug 2015 22:51:09 GMT Received: from xch-rcd-009.cisco.com (173.37.102.19) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 25 Aug 2015 17:51:08 -0500 Received: from xhc-rcd-x01.cisco.com (173.37.183.75) by xch-rcd-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Tue, 25 Aug 2015 17:51:08 -0500 Received: from xmb-aln-x11.cisco.com ([169.254.6.68]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0248.002; Tue, 25 Aug 2015 17:51:08 -0500 From: "Eric Voit (evoit)" To: Andy Bierman , Martin Bjorklund , "Alexander Clemm (alex)" Thread-Topic: [netmod] Y34 - root node Thread-Index: AQHQ2ddUzvwy2SNHuku5toYbWmieK54SVS+AgAEhX4CAAA01gIABIKmAgAA8e4CAAdMvAIAADywAgAAX8YCABlKuwA== Date: Tue, 25 Aug 2015 22:51:07 +0000 Message-ID: References: <20150820.101533.1535137181522006328.mbj@tail-f.com> <55D7148C.6090508@cisco.com> <20150821.150158.491063432174006492.mbj@tail-f.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.118.56.228] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y34 - root node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 22:51:13 -0000 RnJvbTogQW5keSBCaWVybWFuLCAgRnJpZGF5LCBBdWd1c3QgMjEsIDIwMTUgMTA6MjggQU0NCg0K PHNuaXA+DQo+ID4+PiBDdXJyZW50bHkgd2UgaGF2ZSBhIHByb3ByaWV0YXJ5IHdheSBvZiAicmVs b2NhdGluZyIgWUFORyBtb2R1bGVzLCBhbmQNCj4gPj4+IE9ETCBoYXMgaXRzICJtb3VudCIsIGFu ZCBJIHRoaW5rIEFuZHkgaGFzIHNvbWUgb3RoZXIgbWVjaGFuaXNtLsKgIE1heWJlDQo+ID4+PiB0 aGUgdGltZSBoYXMgY29tZSB0byBzdGFuZGFyZGl6ZSBob3cgbW91bnQgd29ya3MsIGFuZCBtYXli ZSB0aGVuIGFsc28NCj4gPj4+IHN0YW5kYXJkaXplIHRoZSBsaXN0IG9mIGRldmljZXMgaW4gYSBj b250cm9sbGVyIG1vZGVsLg0KDQpJdCBzZWVtcyB0aGVyZSBhcmUgbWFueSBwbGFjZXMgd2hlcmUg bW91bnQgaXMgYmVpbmcgdXNlZCBlZmZlY3RpdmVseS4gIEkgYW0gYWxsIGZvciBzb21lIHN0YW5k YXJkIHN5bnRheC4NCg0KPiA+PiArMQ0KPiA+Pg0KPiA+PiBXZSBqdXN0IG5lZWQgdG8gc3RhbmRh cmRpemUgYSAiZG9jcm9vdCB3aXRoaW4gYSBkb2Nyb290Ii4NCj4gPj4gVGhpcyBpcyBub3QgcmVs b2NhdGlvbiBvZiBzdWJ0cmVlcyB3aXRoaW4gdGhlIGRhdGFzdG9yZSwgdGhpcyBpcyBqdXN0DQo+ ID4+IG1vdW50aW5nDQo+ID4+IGEgZGF0YXN0b3JlIHNvbWV3aGVyZSB3aXRoaW4gYSBwYXJlbnQg ZGF0YXN0b3JlLg0KPiA+Pg0KPiA+PiBJbiBZQU5HIHZhbGlkYXRpb24gdGVybXMsIHlvdSBzaW1w bHkgYWRqdXN0IHRoZSBkb2Nyb290IHRvIHRoZSBuZXN0ZWQNCj4gPj4gbW91bnQNCj4gPj4gcG9p bnQsDQo+ID4+IGFuZCB0aGUgcmVwbGljYXRlZCBkYXRhc3RvcmUgY2FuIGJlIHVzZWQgYXMgaWYg aXQgd2VyZSBzdGFuZC1hbG9uZS4NCj4gPj4gVGhpcyB3b3VsZCBhbGxvdyBhbnkgc29ydCBvZiBl bmNhcHN1bGF0aW9uIG9mIGRhdGFzdG9yZXMgYW5kIG5vdCBhZGQNCj4gPj4gYW55DQo+ID4+IGRh dGEgbW9kZWwgY29tcGxleGl0eSB0byBkZXZpY2VzIHdoaWNoIGRvIG5vdCBoYXZlIHZpcnR1YWwg c2VydmVycw0KPiA+PiAobW9zdCBvZiB0aGVtKS4NCj4gPiBDb21wYXJlZCB0byB0aGUgbW91bnQg ZHJhZnQsIEkgd291bGQgbGlrZSB0byBkZWNvdXBsZSB0aGUgc2NoZW1hDQo+ID4gaW5mb3JtYXRp b24gZnJvbSB0aGUgaW5zdGFuY2UgcG9wdWxhdGlvbiBtZWNoYW5pc20uwqAgSS5lLiwgSSdkIGxp a2UgYQ0KPiA+IG1lY2hhbmlzbSB0aGF0IHNpbXBseSBkZWZpbmVzIHRoZSBzY2hlbWEsIG5vdCBu ZWNlc3NhcmlseSBob3cgdGhlIGRhdGENCj4gPiBpcyBwb3B1bGF0ZWQgKGluIHRoZSBtb3VudCBk cmFmdCBkYXRhIHdhcyBmZXRjaGVkIGZyb20gYSByZW1vdGUNCj4gPiBzZXJ2ZXIsIGJ1dCBJTU8g dGhhdCBpcyBqdXN0IG9uZSBvZiBzZXZlcmFsIHVzZSBjYXNlcykuDQo+IFllcywgSSBhZ3JlZSB0 aGF0IHRoZXNlIGNvdWxkL3Nob3VsZCBiZSBkZWNvdXBsZWQuwqAgQWx0aG91Z2ggSSBub3RlDQo+ IHRoYXQgdGhlIG1vdW50IGRyYWZ0IGRvZXMgYWxzbyBhbGxvdyBmb3IgbG9jYWwgbW91bnRzLCBh bHRob3VnaCB0aGlzDQo+IGRvZXMgbm90IHNlZW0gdG8gYmUgaW50ZW5kZWQgdG8gYmUgdGhlIG1h aW5saW5lIGNhc2UuDQoNClRoZSBtb3VudCBkcmFmdCB3YXMgaW5kZWVkIGRyaXZlbiBieSBPcGVu RGF5bGlnaHQncyB1c2UgY2FzZXMuICBJbiBPREwsIG1vdW50IGlzIHVzZWQgZm9yIGxvY2FsIFlB TkcgcmVwcmVzZW50YXRpb24gb2YgcmVtb3RlIGRldmljZSBpbmZvcm1hdGlvbi4gDQoNCkJhc2Vk IG9uIHRoaXMgSSBiZWxpZXZlIGEgZ2VuZXJhbGl6ZWQgbW91bnQgc3ludGF4IHNob3VsZCBub3Qg bWFuZGF0ZSB0aGF0IHRoZSB0YXJnZXQgbXVzdCBiZSBsb2NhbCBhbmQgY2Fubm90IGJlIHJlbW90 ZS4gIE5vciBzaG91bGQgYSBnZW5lcmFsaXplZCBtb3VudCBzeW50YXggaXRzZWxmIHJlc3RyaWN0 IHdoZXRoZXIgdGhlIHRhcmdldCBub2RlIGNvbnRhaW4gc2NoZW1hIG9yIGluc3RhbmNlIGluZm8u ICAgVGhlcmUgYXJlIG1hbnkgd2F5cyBiZXlvbmQgdGhlIHN5bnRheCBpZiBhbiBpbXBsZW1lbnRh dGlvbiBoYXMgbm8gZGVzaXJlIGZvciB0aGlzLg0KDQpFcmljDQoNCg0K From nobody Tue Aug 25 19:54:22 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D73E1A891A for ; Tue, 25 Aug 2015 19:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JNUrHqwa-yIG for ; Tue, 25 Aug 2015 19:54:11 -0700 (PDT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id CE5F71A3B9D for ; Tue, 25 Aug 2015 19:54:08 -0700 (PDT) Received: (qmail 8878 invoked by uid 0); 26 Aug 2015 02:54:08 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy4.mail.unifiedlayer.com with SMTP; 26 Aug 2015 02:54:08 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id 9Etx1r0012SSUrH01Eu0kB; Tue, 25 Aug 2015 20:54:06 -0600 X-Authority-Analysis: v=2.1 cv=C6F6l2/+ c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=4g2epv4a4k0A:10 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=uRRa74qj2VoA:10 a=48vgC7mUAAAA:8 a=I83HPG9nTBwl2gt0s9gA:9 a=XwZlgrJSxQs39icw:21 a=t84gtBqWqwa2n6gj:21 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=G7GuIS9ak/2Ff9o6gF4zo7WNXu5PWHyl++f9gVcr3XI=; b=t/g05d1svp48aTg1Ga90XxhSY1xV4QQnlzq3oik5kFMK5c9QfgwK5LgVF6zUEVLnmMCVF0ovaSjl3Wslxf4/d5Cpes2xIDLIVG/6rSn7tV4JRzOs/a5ho+9nZmYkGGDp; Received: from box313.bluehost.com ([69.89.31.113]:43167 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZUQqc-0004PK-Qz; Tue, 25 Aug 2015 20:53:59 -0600 Message-ID: <55DD2A43.8070300@labn.net> Date: Tue, 25 Aug 2015 22:53:55 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Martin Bjorklund References: <55D3DDFC.2080107@labn.net> <20150819.112730.1689479932571514728.mbj@tail-f.com> <55D53A13.4080505@labn.net> <20150820.095853.255503105278478154.mbj@tail-f.com> In-Reply-To: <20150820.095853.255503105278478154.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: rtgwg@ietf.org, netmod@ietf.org, draft-rtgyangdt-rtgwg-device-model@ietf.org Subject: Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 02:54:14 -0000 Martin, Sorry for the delayed response, was away for a bit. Not sure if any of this is OBE as just starting to catch up on mail. On 08/20/2015 03:58 AM, Martin Bjorklund wrote: > Lou Berger wrote: >> Martin, >> >> See below. >> On 08/19/2015 05:27 AM, Martin Bjorklund wrote: >>> Hi, >>> >>> Lou Berger wrote: >>>> On 8/18/2015 8:01 PM, Andy Bierman wrote: >>>>> Q1) scope >>>>> >>>>> >>>>> sec 2: >>>>> >>>>> The model organization can itself be thought of as a "meta-model", >>>>> in that it describes the relationships between individual models. We >>>>> choose to represent it also as simple YANG model consisting of lists >>>>> and containers to serve as anchor points for the corresponding >>>>> individual models. >>>>> >>>>> As shown below, our model is rooted at a "device", which represents a >>>>> network router, switch, or similar network element. >>>>> >>>>> >>>>> Why is this a meta-model? >>>> because the aim to to show how other models inter-relate rather than >>>> define the details of all models. As stated in the intro: >>>> >>>> This document aims to provide an extensible structure that can be >>>> used to tie together other models. It allows for existing, emerging, >>>> and future models. The overall structure can be constructed using >>>> YANG augmentation and imports. >>>> >>>> >>>>> It looks like a real YANG data model where ad-hoc classification is >>>>> being done >>>>> using container names. >>>> >>>> Sure, we're using YANG, or at least trying, to document our proposal. >>>> Do you think there's a better way to formally document the work? >>> >>> I can see two approaches: >>> >>> 1) Define a YANG module with the structural hierarchy. Then >>> other modules augment this module at the correct place in the >>> hierarchy. This module will probably be updated pretty often, >>> especially if the idea to have ONE module with the complete >>> hierarchy for ALL types of devices. >>> >>> A variant is to define such a module for routing-specific modules >>> only to augment. Other areas can define similar "structural" >>> modules. >>> >> Or device additions can augment the base model. >> >>> 2) Document the hierarchy as a guideline. When it is time to work >>> on a new module, lets say mpls, we look into this guideline and >>> define the necessary hierarchy in the mpls module. >>> >> >> I think this is a good topic to discuss. The second sounds lighter >> weight as long as it is followed while the first makes it hard to not >> follow. I see advantages in both. >> >>> >>>>> If vendors augment this tree with their own ad-hoc hierarchy, then how >>>>> is this >>>>> any better than what we have now? >>>>> >>>> This goes to requirements which is really in the scope of >>>> draft-openconfig-netmod-model-structure. From my perspective it comes >>>> down to how much information is needed from an actual device in order to >>>> come up with its yang-based configuration, and the principle that there >>>> is benefit in this being minimized. For example, consider the case >>>> where a config is generated before a specific device is fielded or >>>> perhaps even purchased/selected. >>> >>> As long as the device implements standard data models, why does it >>> matter for pre-provisioning if the standard path to configure an >>> interface is /devices/interfaces/interface or /interfaces/interface? >>> >> >> I personally see the top level as more about logical separation of model >> types/classes > > This then sounds like meta data about the model. What kind of model > is it - see draft-bogdanovic-netmod-yang-model-classification. > Perhaps. I'll defer to Dan on this as he's also a co-author/DT member. > I don't think it is a good idea to encode meta data into the data > hierarchy. It would be better IMO to keep this either inline in the > module definition (yang-model-type device;) or externally in a > separate registry. > > > >> like a top level directory structure. So IMO it's a bit >> subjective and really about establish and agreeing upon conventions. -- >> and there's a group of users who say they really like it one way. >> >> Deeper in the hierarchy the path becomes more significant, but you >> weren't really questioning this. > > I am all for significant nodes in the path! This is really good/useful to hear. If disagreement is limited to the top level node, it's much easier (but not easy ;-) problem to solve. > My point is that /device > is insignificant. I think the fundamental discussion here, is who get's to say what's significant and we have (at least) two opposing views on this point. >From my standpoint it comes down to how you view full set of models that may be seen. From the device view, you might only (or, more likely, mostly) see models under /device -- so device doesn't add much value. BUT from the controller/NMS/EMS (or whatever you want to call it) view, you're likely to see all the models so /device plays a much more significant role in identifying logical model organization/understanding. -- That said, I'm much more of a device person than an NMS builder, so I'm also willing to trust the opinion of folks who are clearly doing significant work on the controller/NMS side. > >>>>> What is the scope of this work? >>>> see slide 7 of >>>> https://www.ietf.org/proceedings/93/slides/slides-93-rtgwg-3.pdf >>>> >>>>> It appears to be only for "routers switches or similar network elements". >>>>> >>>> >From the slide: >>>> From DT charter: An overall architecture for >>>> “the protocols and functionality contained inside the Routing Area” >>> >>> But the design you propose has huge impact on all models, also models >>> from other areas. >> >> A very fair point and why it's important to discuss in this WG. No >> discussion happened in the prague session largely due to multiple >> scheduling conflicts. >> >>> >>>>> Q2) interfaces >>>>> >>>>> The interface model is taken from [RFC7223 ] and includes possible >>>>> technology-specific augmentations using example technologies defined >>>>> in [RFC7277 ]. >>>>> +--rw interfaces >>>>> | +--rw interface* [name] >>>>> | +--rw name string >>>>> | +--rw bind-network-element-id? uint8 >>>>> | +--rw ethernet >>>>> | | +--rw bind-networking-instance-name? string >>>>> | | +--rw aggregates >>>>> | | +--rw rstp >>>>> | | +--rw lldp >>>>> | | +--rw ptp >>>>> | +--rw vlans >>>>> | +--rw tunnels >>>>> | +--rw ipv4 >>>>> | | +--rw bind-networking-instance-name? string >>>>> | | +--rw arp >>>>> | | +--rw icmp >>>>> | | +--rw vrrp >>>>> | | +--rw dhcp-client >>>>> | +--rw ipv6 >>>>> | +--rw bind-networking-instance-name? string >>>>> | +--rw vrrp >>>>> | +--rw icmpv6 >>>>> | +--rw nd >>>>> | +--rw dhcpv6-client >>>>> >>>>> >>>>> Actually the interface model is quite different than the one in RFC 7223. >>>>> Seems rather ethernet-centric. I notice the "type" leaf was removed, >>>>> along with everything else. Is the plan to toss out RFC 7223, >>>>> recharter the interfaces work, and start over? >>>>> >>>> >>>> So this may be our/my inexperience at play here. I didn't think it >>>> appropriate for a document that is augmenting an existing model to >>>> redefine the current model - I actually thought this was part of the >>>> power of YANG augmentation. Are you saying we should have included the >>>> whole 7223 model to augment it, or something different? >>> >>> As long as you want to have /device/interfaces, you need to obsolete >>> the model in RFC 7223 (and all other published YANG models) and >>> rewrite them. However, if we get rid of the /device container, the >>> existing model in RFC 7223 fit in nicely in your hierarchy. >> >> And this is certainly an important point, and I personally think we >> should have a full discussion of if it's worth preserving RFC 7223 or >> open the door for changing it. We had many discussions on this in the >> DT and while multiple wanted to do an even larger change, in the end the >> consensus was to try minimize impact to the this and other RFCs -- even >> if it meant using somewhat more cumbersome mechanisms. >> >>> >>> I think many of us have said this before, but the top-level container >>> /device doesn't really solve any problem. Suppose we have a module >>> today with a top-level node /FOO. Why would this module work better >>> if it augemented /device to give /device/FOO? >>> >> >> as mentioned above, I personally think this is about logical separation >> of model types/classes, like a top level directory structure. So IMO >> it's a bit subjective and really about establish and agreeing upon >> conventions. -- and there's a group of users who say they really like it >> one way. > > Hopefully, a decision to change all existing models (including vendor > models!) will be based on something more technical than the fact that > a group of people "really like it" some other way. I'm equally unsure that having an argument of "I got there first" is a compelling argument given the number of folks (including vendors) who have stated willingness (or even support) for change. I think having a major class of users stand up and say this is important should garner some notice. -- In the end, this is largely a (I think) netmod WG decision. > >>> Maybe the problem you are trying to solve with "/device" is what is >>> written in section 3.1: >>> >>> One of the challenges in assembling existing YANG models is that they >>> are generally written with the assumption that each model is at the >>> root of the configuration or state tree. Combining models then >>> results in a multi-rooted tree that does not follow any logical >>> construction and makes it difficult to work with operationally. In >>> some cases, models explicitly reference other models (e.g., via >>> augmentation) to define a relationship, but this is the case for only >>> a few existing models. >>> >>> First of all I don't really agree with this. We just have a few >>> module published, but for example ietf-ip augments ietf-interfaces, >>> and the idea with ietf-routing is that routing-specific modules >>> augment it. In fact, I think the published modules follow your >>> proposed hierarchy (with some exception) - if it wasn't for the >>> /device node. >>> >>> Second, if we want to be conservative with top-level nodes (I am not >>> convinced that this is a problem) we can solve that without going into >>> the extreme of having *one* top-level node. >> >> Why do you say only one top level node. This isn't my exception, nor do >> I see this stated in the draft. I do think we say one top level node >> dealing with device configuration. > > In light of what you explained, I can rephrase this: On any given > implementation there will always only be one top-level node. For > example, on a device, the top-node is always /device. Correct? > I don't think this will always be the case for *all* devices, but it may always be the case for *some*. as previously answered: >>> Instead of having N >>> top-level nodes, we would have N nodes under /device. Why is this >>> better? >> >> N would contain only device configuration related modules. There could >> be others, e.g., /services has been mentioned by some. >> >>> >>>> Are you referring to section 2.3? If so, I think we all agree (and said >>>> as much in Prague) that this section could be clearer. We/I tried to >>>> explain it in the Prague slide 25 (for this you may want to see the >>>> animation in >>>> https://www.ietf.org/proceedings/93/slides/slides-93-rtgwg-3.pptx) >>>> >>>> Basically the amount of information provided depends on the >>>> logical-network-element context used to access this information. So if >>>> a model is "retrieved" via an IP address associated with a >>>> network-element-id with device-view=true (e.g., the left side of slide >>>> 25), then the device's full view is provided. And when a model is >>>> "retrieved" via an IP address associated with a network-element-id with >>>> device-view=false (e.g., the ride side of slide 25, either color) only >>>> information related to the network-element-id is provided. >>> >>> Do you want the user from a particular IP address to have access to >>> just his part of the tree, or do you want that user to have his own >>> "sandbox" that he can control independently of other users? >> >> The intent was multiple logical-network-elements and when >> device-view=false, any management operation taking place in the context >> of that LNE would only have visibility and ability to control that LNE. >> This matches a pretty common feature set. > > Ok, so this means that there is still just one configuration for all > logical-network-elements, right? E.g., if a user from > logical-network-element A locks the datastore, he will lock out a > user from logical-network-element B; if user from A saves running to > startup changes for B will also be saved, etc? If A (or B) has device-view=true, I think so. If both have device-view=false, I suspect this may be implementation specific, but am not sure. Lou > > > > > /martin > > > > >> >>> >>> In the first case, you can use NACM to set up rules to give each user >>> proper access (based on user identity rather than IP address though). >> >> I think this would be used too. For example user1 would have ro access >> while user2 has rw. >> >>> You don't need this "device-view" in order to do this. >> Agreed, but this is something different and matches how a multiple >> devices from multiple vendors function today. >> >>> >>> In the latter case, I don't think the proposed design works. (I can >>> go into details if it turns out that this what you had in mind). >> I think we're interested in a form of the first. >> >> Lou >> >>> >>> >>> >>> /martin >>> >> From nobody Tue Aug 25 23:42:00 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA6761B29B5; Tue, 25 Aug 2015 23:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEEs2EcW6GIr; Tue, 25 Aug 2015 23:41:56 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B49D81B2850; Tue, 25 Aug 2015 23:41: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 596641465; Wed, 26 Aug 2015 08:41: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 CmgMWEn3r2fK; Wed, 26 Aug 2015 08:41:54 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 26 Aug 2015 08:41:50 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 519F620149; Wed, 26 Aug 2015 08:40:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id KQHhMRiIUw6z; Wed, 26 Aug 2015 08:40:37 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8F36D2023E; Wed, 26 Aug 2015 08:40:36 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8D00736593C8; Wed, 26 Aug 2015 08:40:32 +0200 (CEST) Date: Wed, 26 Aug 2015 08:40:31 +0200 From: Juergen Schoenwaelder To: Lou Berger Message-ID: <20150826064030.GB84416@elstar.local> Mail-Followup-To: Lou Berger , Martin Bjorklund , rtgwg@ietf.org, netmod@ietf.org, draft-rtgyangdt-rtgwg-device-model@ietf.org References: <55D3DDFC.2080107@labn.net> <20150819.112730.1689479932571514728.mbj@tail-f.com> <55D53A13.4080505@labn.net> <20150820.095853.255503105278478154.mbj@tail-f.com> <55DD2A43.8070300@labn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55DD2A43.8070300@labn.net> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: draft-rtgyangdt-rtgwg-device-model@ietf.org, netmod@ietf.org, rtgwg@ietf.org Subject: Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 06:41:59 -0000 On Tue, Aug 25, 2015 at 10:53:55PM -0400, Lou Berger wrote: > > Hopefully, a decision to change all existing models (including vendor > > models!) will be based on something more technical than the fact that > > a group of people "really like it" some other way. > > I'm equally unsure that having an argument of "I got there first" is a > compelling argument given the number of folks (including vendors) who > have stated willingness (or even support) for change. I think having a > major class of users stand up and say this is important should garner > some notice. Please keep in mind that we are talking about several published proposed standards that have been implemented and deployed. I think there must be convincing technical reasons to declare them broken and to redo them. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Aug 26 00:08:00 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E91AC1A1B6B for ; Wed, 26 Aug 2015 00:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXWVZYAxCOgU for ; Wed, 26 Aug 2015 00:07:56 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 995CE1A006F for ; Wed, 26 Aug 2015 00:07: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 60E6D143C for ; Wed, 26 Aug 2015 09:07: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 HgVbNNcrdT36 for ; Wed, 26 Aug 2015 09:07:54 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 26 Aug 2015 09:07:54 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0083C20078 for ; Wed, 26 Aug 2015 09:07: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 1xfYx5Q8UuaN; Wed, 26 Aug 2015 09:07:52 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 230BA20062; Wed, 26 Aug 2015 09:07:52 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id BCF6B36594C9; Wed, 26 Aug 2015 09:07:47 +0200 (CEST) Date: Wed, 26 Aug 2015 09:07:46 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20150826070746.GA84617@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="5mCyUwZo2JvN/JJP" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: Subject: [netmod] minutes of the NETMOD 2015-08-24 virtual interim meeting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 07:07:59 -0000 --5mCyUwZo2JvN/JJP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, attached are the minutes of the 2015-03-24 virtual interim meeting. Please let me know if something needs fixing. You can find all the virtual interim meeting minutes next to the YANG 1.1 issue list in the NETMOD WG subversion repository: http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 --5mCyUwZo2JvN/JJP Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="netmod-2015-08-24-minutes.txt" ============================================================= NETCONF Data Modeling Language WG (netmod) 18th YANG 1.1 Virtual Interim Monday, August 24th, 2015, 17:00-18:00 CEST Minutes Juergen Schoenwaelder ============================================================= * Participants AB = Andy Bierman IB = Ignas Bagdonas JS = Juergen Schoenwaelder LL = Ladislav Lhotka MB = Martin Bjorklund * Review of Goals and Milestones The WG charter lists the following milestones: Mar 2015 - Submit YANG 1.1 to the IESG Apr 2015 - Submit YANG guidelines update to the IESG Is the goal to wrap up YANG 1.1 with the feature set we agreed on during the last year or is the goal to keep YANG 1.1 a moving target for some additional time so that additional features can be incorporated? This may also touch on the question what can be done with extensions. Whatever the answer is, we should agree on a plan how to move forward with the YANG 1.1 effort and then set realistic milestones. LL: If we do not finish YANG 1.1 quickly, we have to remove the dependency on YANG 1.1 from other documents. AB: If we want to address I2RS or OpenConfig requirements, it might take anything between a months or a year. MB: Can we not make extensions work in YANG 1.1? LL: We need negotiation of extensions and attributes. MB: But this is a different problem. MB: You can design extensions such that they do not badly affect clients. The NACM extensions work just fine. AB: I prefer to update the language instead of having a core language and N extensions of it. MB: I prefer to have modularity. Eventually certain extensions may become part of the language but revising the language every time a new extension is needed is costly. LL: Should annotations be part of YANG 1.1? MB: Annotations define meta-data not regular data nodes. MB: I think we should focus on YANG 1.1 but I do not like to find myself in a situation that we have to add many additional statements once YANG 1.1 is done. MB: We had extensions like actions that worked fine because a client not understanding an action would never invoke one. But yes, you can define extensions that can break things. LL: I think the YANG language should address the extension negotiation problem. AB: There is conformance to YANG, but also conformance to NACM or conformance to EPHEMERAL. LL: What if I implement ietf-system but not NACM? Do I still have to implement nacm: extension semantics? LL: I am concerned about vendors misusing extensions. MB: Vendors can always break things. MB: I think we should finish YANG 1.1 soon as we have it now. MB: If we have to do YANG 1.2 afterwards, so be it. It would also be nice to avoid this if we can work with extensions. AB: I do not mind revising YANG every lets say two years if needed. MB: I think we agree that we should finish YANG 1.1 now. JS: What is a realistic timeline to finish up YANG 1.1? AB: What about delivering YANG 1.1 in October? MB: Works for me. AB: Ideally, the next Internet-Draft should go to WG last call. MB: Lets discuss next week whether we do another I-D or not. * Actions - MB will go though the various comments sent to the WG list and identify comments that are easy to address and comments that require discussion. - JS will change YANG 1.1 milestone to October 2015 - JS will change the YANG guidelines milestone to December 2015 --5mCyUwZo2JvN/JJP-- From nobody Wed Aug 26 01:29:06 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1ED1A8A0B for ; Wed, 26 Aug 2015 01:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqEl6ocj-D4y for ; Wed, 26 Aug 2015 01:29:02 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 088BC1A89FB for ; Wed, 26 Aug 2015 01:29:01 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id DC46E1CC0047; Wed, 26 Aug 2015 10:29:02 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20150825.140102.2117420320519166894.mbj@tail-f.com> References: <20976241.1440444036499.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> <20150825.140102.2117420320519166894.mbj@tail-f.com> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Wed, 26 Aug 2015 10:28:58 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: randy_presuhn@mindspring.com, netmod@ietf.org Subject: Re: [netmod] Y26 again, sorry X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 08:29:04 -0000 Hi, I changed the DNS zone data model to use this pattern - it looks good and works great: - module: https://gitlab.labs.nic.cz/llhotka/zone-data-yang/blob/master/dns-zones.yang - tree: https://gitlab.labs.nic.cz/llhotka/zone-data-yang/raw/master/model.tree Lada Martin Bjorklund writes: > Hi, > > I think this could work (thanks Robert; maybe this is what you > meant!): > > container zones { > list zone { > ... > list rrset { > ... > leaf type { > type identityref { ... } > } > list rdata { > key id; > ... > choice type-specific-params { > mandatory true; > // to be augmented with type-specific nodes > } > } > } > } > } > > And then in another module: > > augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" > + "/type-specific-parameters" { > when "derived-from-or-self(../dnsz:type,'iana-dns-parameters'," > + "'TLSA')"; > > leaf certificate-usage { > mandatory true; > ... > } > } > > The empty mandatory choice formally tells the client that additional > cases are expected. > > (If the empty choice looks fishy, it is probably often possible to > define at least one case inline...) > > This pattern is nice to the client, since there is no way an > additional augmenting module can break a working client. > > > /martin > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Aug 26 02:41:32 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC841ACE46; Wed, 26 Aug 2015 02:41:30 -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 J2_vC5zOERgc; Wed, 26 Aug 2015 02:41:29 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C92FF1ACE27; Wed, 26 Aug 2015 02:41:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1902; q=dns/txt; s=iport; t=1440582089; x=1441791689; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=wKJpWLGMSv0WoZ9r7HxXygL739vWqoMaBtfD+OomvWM=; b=L9LyHjicxsieoyn3vXMmvo4x3Rc8PelqgpjZYbZ0GBnPhZKp0c8q8aZC KIvt1tUCtFoq5MWOdcAuS6ft5KxA2RFjlEwAdBYL6ShxrODmZ4vgBugRE VWTIAqWBm8vgrCAVQrZ2c0kFcrUU9wxuPCb2l+VGuUbYngyBlzN5xoQMF Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ApBQBPiN1V/4oNJK1aA4MbVGkGgx26SYF0hX8CHIEfORMBAQEBAQEBgQqEJAEBBCMRRQ4CAgEIDgIIAgImAgICGRcVEAIEAQ0FiC6zK5R/AQEBAQEBAQEBAQEBAQEBAQEBAQEBFwSBHoo5hFcYCxAHEoJXgUMFlTcBikCCMYFKFYQdlF8mg35xgUiBBAEBAQ X-IronPort-AV: E=Sophos;i="5.17,415,1437436800"; d="scan'208";a="182039793" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-4.cisco.com with ESMTP; 26 Aug 2015 09:41:28 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t7Q9fS71010836 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 26 Aug 2015 09:41:28 GMT Received: from xch-rcd-003.cisco.com (173.37.102.13) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 26 Aug 2015 04:41:27 -0500 Received: from xhc-rcd-x03.cisco.com (173.37.183.77) by xch-rcd-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Wed, 26 Aug 2015 04:41:27 -0500 Received: from xmb-aln-x06.cisco.com ([169.254.1.223]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0248.002; Wed, 26 Aug 2015 04:41:26 -0500 From: "Acee Lindem (acee)" To: Juergen Schoenwaelder , Lou Berger Thread-Topic: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00 Thread-Index: AQHQ2hI5G+RtR4J5pkqypvooyXOij54S3w4AgACDKQCAARvMgIAAXcaAgAkYyICAAD9QgP//73uA Date: Wed, 26 Aug 2015 09:41:26 +0000 Message-ID: References: <55D3DDFC.2080107@labn.net> <20150819.112730.1689479932571514728.mbj@tail-f.com> <55D53A13.4080505@labn.net> <20150820.095853.255503105278478154.mbj@tail-f.com> <55DD2A43.8070300@labn.net> <20150826064030.GB84416@elstar.local> In-Reply-To: <20150826064030.GB84416@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.36.7.18] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-rtgyangdt-rtgwg-device-model@ietf.org" , "netmod@ietf.org" , "rtgwg@ietf.org" Subject: Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 09:41:30 -0000 DQoNCk9uIDgvMjYvMTUsIDI6NDAgQU0sICJKdWVyZ2VuIFNjaG9lbndhZWxkZXIiDQo8ai5zY2hv ZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPiB3cm90ZToNCg0KPk9uIFR1ZSwgQXVnIDI1 LCAyMDE1IGF0IDEwOjUzOjU1UE0gLTA0MDAsIExvdSBCZXJnZXIgd3JvdGU6DQo+DQo+PiA+IEhv cGVmdWxseSwgYSBkZWNpc2lvbiB0byBjaGFuZ2UgYWxsIGV4aXN0aW5nIG1vZGVscyAoaW5jbHVk aW5nIHZlbmRvcg0KPj4gPiBtb2RlbHMhKSB3aWxsIGJlIGJhc2VkIG9uIHNvbWV0aGluZyBtb3Jl IHRlY2huaWNhbCB0aGFuIHRoZSBmYWN0IHRoYXQNCj4+ID4gYSBncm91cCBvZiBwZW9wbGUgInJl YWxseSBsaWtlIGl0IiBzb21lIG90aGVyIHdheS4NCj4+IA0KPj4gSSdtIGVxdWFsbHkgdW5zdXJl IHRoYXQgaGF2aW5nIGFuIGFyZ3VtZW50IG9mICJJIGdvdCB0aGVyZSBmaXJzdCIgaXMgYQ0KPj4g Y29tcGVsbGluZyBhcmd1bWVudCBnaXZlbiB0aGUgbnVtYmVyIG9mIGZvbGtzIChpbmNsdWRpbmcg dmVuZG9ycykgd2hvDQo+PiBoYXZlIHN0YXRlZCB3aWxsaW5nbmVzcyAob3IgZXZlbiBzdXBwb3J0 KSBmb3IgY2hhbmdlLiAgSSB0aGluayBoYXZpbmcgYQ0KPj4gbWFqb3IgY2xhc3Mgb2YgdXNlcnMg c3RhbmQgdXAgYW5kIHNheSB0aGlzIGlzIGltcG9ydGFudCBzaG91bGQgZ2FybmVyDQo+PiBzb21l IG5vdGljZS4NCj4NCj5QbGVhc2Uga2VlcCBpbiBtaW5kIHRoYXQgd2UgYXJlIHRhbGtpbmcgYWJv dXQgc2V2ZXJhbCBwdWJsaXNoZWQNCj5wcm9wb3NlZCBzdGFuZGFyZHMgdGhhdCBoYXZlIGJlZW4g aW1wbGVtZW50ZWQgYW5kIGRlcGxveWVkLiBJIHRoaW5rDQo+dGhlcmUgbXVzdCBiZSBjb252aW5j aW5nIHRlY2huaWNhbCByZWFzb25zIHRvIGRlY2xhcmUgdGhlbSBicm9rZW4gYW5kDQo+dG8gcmVk byB0aGVtLg0KDQpPdGhlciB0aGFuIGFkZGluZyAvZGV2aWNlIGF0IHRoZSB0b3AsIHdlIGFyZSBu b3Qgb2Jzb2xldGluZyBSRkMgNzIyMy4gVGhlDQpjdXJyZW50IGRldmljZSBtb2RlbCBrZWVwcyB0 aGUgaW50ZXJmYWNlcyBjb25maWd1cmF0aW9uIHNpbG8gYW5kIG1lcmVseQ0KYXVnbWVudHMgaXQg d2l0aCBhIGJpbmRpbmcgdG8gdGhlIGxvZ2ljYWwtbmV0d29ya2luZy1lbGVtZW50Lg0KDQpUaGFu a3MsIA0KQWNlZQ0KDQoNCg0KDQo+DQo+L2pzDQo+DQo+LS0gDQo+SnVlcmdlbiBTY2hvZW53YWVs ZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNCj5QaG9uZTogKzQ5 IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJt YW55DQo+RmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cDovL3d3dy5qYWNvYnMt dW5pdmVyc2l0eS5kZS8+DQoNCg== From nobody Wed Aug 26 02:52:07 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11C4F1A8901; Wed, 26 Aug 2015 02:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_BIZ=0.288, IP_NOT_FRIENDLY=0.334] 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 tIsX7WQABXJm; Wed, 26 Aug 2015 02:52:04 -0700 (PDT) Received: from newdragon.webhostserver.biz (newdragon.webhostserver.biz [69.25.136.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 471471A7005; Wed, 26 Aug 2015 02:52:04 -0700 (PDT) Received: from localhost ([::1]:35704 helo=[127.0.0.1]) by newdragon.webhostserver.biz with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.85) (envelope-from ) id 1ZUXN6-0001RP-NY; Wed, 26 Aug 2015 13:51:56 +0400 From: Lou Berger To: Juergen Schoenwaelder Date: Wed, 26 Aug 2015 05:51:55 -0400 Message-ID: <14f696bc290.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <20150826064030.GB84416@elstar.local> References: <55D3DDFC.2080107@labn.net> <20150819.112730.1689479932571514728.mbj@tail-f.com> <55D53A13.4080505@labn.net> <20150820.095853.255503105278478154.mbj@tail-f.com> <55DD2A43.8070300@labn.net> <20150826064030.GB84416@elstar.local> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.5.9.9 (build: 22000010) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - newdragon.webhostserver.biz X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Get-Message-Sender-Via: newdragon.webhostserver.biz: authenticated_id: lberger@blabn.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: draft-rtgyangdt-rtgwg-device-model@ietf.org, netmod@ietf.org, rtgwg@ietf.org Subject: Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 09:52:06 -0000 On August 26, 2015 2:42:26 AM Juergen Schoenwaelder wrote: > On Tue, Aug 25, 2015 at 10:53:55PM -0400, Lou Berger wrote: > >> > Hopefully, a decision to change all existing models (including vendor >> > models!) will be based on something more technical than the fact that >> > a group of people "really like it" some other way. >> >> I'm equally unsure that having an argument of "I got there first" is a >> compelling argument given the number of folks (including vendors) who >> have stated willingness (or even support) for change. I think having a >> major class of users stand up and say this is important should garner >> some notice. > > Please keep in mind that we are talking about several published > proposed standards that have been implemented and deployed. I think > there must be convincing technical reasons to declare them broken and > to redo them. > As Acee says, we have been trying very hard to minimize any impact to existing work even when the result is suboptimal. I also agree that changing PS RFCs should not be done without serious consideration. That said, the IETF process does permit updates and replacements based on WG and IETF consensus -- which is not quite the same as your last statement. Lou > /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 Aug 26 03:23:49 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3EAA1A21C3; Wed, 26 Aug 2015 03:23:47 -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 AnhlWrEgyYFz; Wed, 26 Aug 2015 03:23:45 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64A931A1AB8; Wed, 26 Aug 2015 03:23:45 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2FE7313CD; Wed, 26 Aug 2015 12:23:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id tU_fvHg_6vOs; Wed, 26 Aug 2015 12:23:43 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 26 Aug 2015 12:23:43 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7AF8F20080; Wed, 26 Aug 2015 12:23:43 +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 o1YYa6434i4Y; Wed, 26 Aug 2015 12:23: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 C189120063; Wed, 26 Aug 2015 12:23:41 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D7A9C365971C; Wed, 26 Aug 2015 12:23:37 +0200 (CEST) Date: Wed, 26 Aug 2015 12:23:37 +0200 From: Juergen Schoenwaelder To: "Acee Lindem (acee)" Message-ID: <20150826102336.GA85182@elstar.local> Mail-Followup-To: "Acee Lindem (acee)" , Lou Berger , Martin Bjorklund , "rtgwg@ietf.org" , "netmod@ietf.org" , "draft-rtgyangdt-rtgwg-device-model@ietf.org" References: <55D3DDFC.2080107@labn.net> <20150819.112730.1689479932571514728.mbj@tail-f.com> <55D53A13.4080505@labn.net> <20150820.095853.255503105278478154.mbj@tail-f.com> <55DD2A43.8070300@labn.net> <20150826064030.GB84416@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: "draft-rtgyangdt-rtgwg-device-model@ietf.org" , "netmod@ietf.org" , "rtgwg@ietf.org" Subject: Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 10:23:48 -0000 On Wed, Aug 26, 2015 at 09:41:26AM +0000, Acee Lindem (acee) wrote: > > > On 8/26/15, 2:40 AM, "Juergen Schoenwaelder" > wrote: > > >On Tue, Aug 25, 2015 at 10:53:55PM -0400, Lou Berger wrote: > > > >> > Hopefully, a decision to change all existing models (including vendor > >> > models!) will be based on something more technical than the fact that > >> > a group of people "really like it" some other way. > >> > >> I'm equally unsure that having an argument of "I got there first" is a > >> compelling argument given the number of folks (including vendors) who > >> have stated willingness (or even support) for change. I think having a > >> major class of users stand up and say this is important should garner > >> some notice. > > > >Please keep in mind that we are talking about several published > >proposed standards that have been implemented and deployed. I think > >there must be convincing technical reasons to declare them broken and > >to redo them. > > Other than adding /device at the top, we are not obsoleting RFC 7223. The > current device model keeps the interfaces configuration silo and merely > augments it with a binding to the logical-networking-element. > For the sake of clarity, these are the YANG data models that are published as Proposed Standard RFCs: - RFC 6022 NETCONF Monitoring - RFC 6536 NETCONF Access Control Model - RFC 7223 Interface Management - RFC 7277 IP Management - RFC 7317 System Management - RFC 7407 SNMP Configuration I see text in draft-rtgyangdt-rtgwg-device-model-00 that seems to affect pretty much all of them. I also do not see "augments it (RFC 7223) with a binding to the logical-networking-element" in the YANG fragment in draft-rtgyangdt-rtgwg-device-model-00. /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 Aug 26 03:26:07 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4331ABD3D; Wed, 26 Aug 2015 03:26: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 s7HW2gUZ82As; Wed, 26 Aug 2015 03:26:03 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D0D491A92EF; Wed, 26 Aug 2015 03:26:02 -0700 (PDT) Received: from localhost (unknown [173.38.220.43]) by mail.tail-f.com (Postfix) with ESMTPSA id 3E9AE1AE049C; Wed, 26 Aug 2015 12:26:01 +0200 (CEST) Date: Wed, 26 Aug 2015 12:26:00 +0200 (CEST) Message-Id: <20150826.122600.1110046163132211535.mbj@tail-f.com> To: acee@cisco.com From: Martin Bjorklund In-Reply-To: References: <55DD2A43.8070300@labn.net> <20150826064030.GB84416@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: draft-rtgyangdt-rtgwg-device-model@ietf.org, netmod@ietf.org, rtgwg@ietf.org Subject: Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 10:26:04 -0000 "Acee Lindem (acee)" wrote: > > > On 8/26/15, 2:40 AM, "Juergen Schoenwaelder" > wrote: > > >On Tue, Aug 25, 2015 at 10:53:55PM -0400, Lou Berger wrote: > > > >> > Hopefully, a decision to change all existing models (including vendor > >> > models!) will be based on something more technical than the fact that > >> > a group of people "really like it" some other way. > >> > >> I'm equally unsure that having an argument of "I got there first" is a > >> compelling argument given the number of folks (including vendors) who > >> have stated willingness (or even support) for change. I think having a > >> major class of users stand up and say this is important should garner > >> some notice. > > > >Please keep in mind that we are talking about several published > >proposed standards that have been implemented and deployed. I think > >there must be convincing technical reasons to declare them broken and > >to redo them. > > Other than adding /device at the top, we are not obsoleting RFC > 7223. This doesn't make sense. The YANG model is the contract. You are proposing changing the contract. The fact is that you will be obsoleting 7223 (and the other RFCs). Existing devices and applications will have to change in order to handle this new top-level node (which will be in some other namespace I presume, unless your proposal is one gigantic monolithic model). /martin From nobody Wed Aug 26 03:41:35 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80C151B2A4F; Wed, 26 Aug 2015 03:41:32 -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 UGh1Bbvk6IST; Wed, 26 Aug 2015 03:41: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 10CEC1B2A4A; Wed, 26 Aug 2015 03:41:31 -0700 (PDT) Received: from localhost (unknown [173.38.220.43]) by mail.tail-f.com (Postfix) with ESMTPSA id F2BE81AE049C; Wed, 26 Aug 2015 12:41:29 +0200 (CEST) Date: Wed, 26 Aug 2015 12:41:29 +0200 (CEST) Message-Id: <20150826.124129.323914665465928199.mbj@tail-f.com> To: lberger@labn.net From: Martin Bjorklund In-Reply-To: <55DD2A43.8070300@labn.net> References: <55D53A13.4080505@labn.net> <20150820.095853.255503105278478154.mbj@tail-f.com> <55DD2A43.8070300@labn.net> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: rtgwg@ietf.org, netmod@ietf.org, draft-rtgyangdt-rtgwg-device-model@ietf.org Subject: Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 10:41:32 -0000 Lou Berger wrote: > Martin, > Sorry for the delayed response, was away for a bit. Not sure if any of > this is OBE as just starting to catch up on mail. > > On 08/20/2015 03:58 AM, Martin Bjorklund wrote: > > Lou Berger wrote: > >> Martin, > >> > >> See below. > >> On 08/19/2015 05:27 AM, Martin Bjorklund wrote: > >>> Hi, > >>> > >>> Lou Berger wrote: [...] > >> Deeper in the hierarchy the path becomes more significant, but you > >> weren't really questioning this. > > > > I am all for significant nodes in the path! > > This is really good/useful to hear. If disagreement is limited to the > top level node, it's much easier (but not easy ;-) problem to solve. > > > My point is that /device > > is insignificant. > > I think the fundamental discussion here, is who get's to say what's > significant and we have (at least) two opposing views on this point. > > From my standpoint it comes down to how you view full set of models that > may be seen. From the device view, you might only (or, more likely, > mostly) see models under /device -- so device doesn't add much value. > BUT from the controller/NMS/EMS (or whatever you want to call it) view, > you're likely to see all the models Agreed, but see below. > so /device plays a much more > significant role in identifying logical model > organization/understanding. -- That said, I'm much more of a device > person than an NMS builder, so I'm also willing to trust the opinion of > folks who are clearly doing significant work on the controller/NMS > side. [This was briefly discussed in another mail thread, and I'll repeat it here.] On the controller, you probably have a list of devices you control (this is how our NCS works, and how ODL works (I have been told)): container devices { list device { key name; // meta-info about the device goes here, things like // ip-address, port, auth info... container data { // all models supported by the devices are "mounted" here } } } So on the controller, the path to interface "eth0" on device "foo" would be: /devices/device[name='foo']/data/interfaces/interface[name='eth0'] if we also have a top-level "/device" container we'd have: /devices/device[name='foo']/data/device/interfaces/interface[name='eth0'] (here you again can see that the "device" node in the device model doesn't make much sense) The path is scoped in the system you work with; in the controller it might be as I illustrated above, in the device it starts with /interfaces. But then you might also have a controller-of-controllers. where the path might be: /domains/domain[name='bar']/devices/device[name='foo']/data /interfaces/interface[name='eth0'] Pushing all these concepts down into the device model clearly doesn't help... /martin From nobody Wed Aug 26 03:58:56 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BAED1AC7E8; Wed, 26 Aug 2015 03:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_BIZ=0.288, IP_NOT_FRIENDLY=0.334] 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 JF7_DqXV0GZl; Wed, 26 Aug 2015 03:58:50 -0700 (PDT) Received: from newdragon.webhostserver.biz (newdragon.webhostserver.biz [69.25.136.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 095F71A901C; Wed, 26 Aug 2015 03:58:50 -0700 (PDT) Received: from localhost ([::1]:48539 helo=[127.0.0.1]) by newdragon.webhostserver.biz with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.85) (envelope-from ) id 1ZUYPo-000740-98; Wed, 26 Aug 2015 14:58:48 +0400 From: Lou Berger To: Juergen Schoenwaelder , "Acee Lindem (acee)" Date: Wed, 26 Aug 2015 06:58:46 -0400 Message-ID: <14f69a8f688.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <20150826102336.GA85182@elstar.local> References: <55D3DDFC.2080107@labn.net> <20150819.112730.1689479932571514728.mbj@tail-f.com> <55D53A13.4080505@labn.net> <20150820.095853.255503105278478154.mbj@tail-f.com> <55DD2A43.8070300@labn.net> <20150826064030.GB84416@elstar.local> <20150826102336.GA85182@elstar.local> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.5.9.9 (build: 22000010) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - newdragon.webhostserver.biz X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Get-Message-Sender-Via: newdragon.webhostserver.biz: authenticated_id: lberger@blabn.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: draft-rtgyangdt-rtgwg-device-model@ietf.org, netmod@ietf.org, rtgwg@ietf.org Subject: Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 10:58:54 -0000 On August 26, 2015 6:24:19 AM Juergen Schoenwaelder wrote: > On Wed, Aug 26, 2015 at 09:41:26AM +0000, Acee Lindem (acee) wrote: >> >> >> On 8/26/15, 2:40 AM, "Juergen Schoenwaelder" >> wrote: >> >> >On Tue, Aug 25, 2015 at 10:53:55PM -0400, Lou Berger wrote: >> > >> >> > Hopefully, a decision to change all existing models (including vendor >> >> > models!) will be based on something more technical than the fact that >> >> > a group of people "really like it" some other way. >> >> >> >> I'm equally unsure that having an argument of "I got there first" is a >> >> compelling argument given the number of folks (including vendors) who >> >> have stated willingness (or even support) for change. I think having a >> >> major class of users stand up and say this is important should garner >> >> some notice. >> > >> >Please keep in mind that we are talking about several published >> >proposed standards that have been implemented and deployed. I think >> >there must be convincing technical reasons to declare them broken and >> >to redo them. >> >> Other than adding /device at the top, we are not obsoleting RFC 7223. The >> current device model keeps the interfaces configuration silo and merely >> augments it with a binding to the logical-networking-element. >> > > For the sake of clarity, these are the YANG data models that are > published as Proposed Standard RFCs: > > - RFC 6022 NETCONF Monitoring > - RFC 6536 NETCONF Access Control Model > - RFC 7223 Interface Management > - RFC 7277 IP Management > - RFC 7317 System Management > - RFC 7407 SNMP Configuration > > I see text in draft-rtgyangdt-rtgwg-device-model-00 that seems to > affect pretty much all of them. Agreed. Although we're proposing reusing / rehoming them. > I also do not see "augments it (RFC > 7223) with a binding to the logical-networking-element" in the YANG > fragment in draft-rtgyangdt-rtgwg-device-model-00. > This omission has been pointed out before. We need to fix that. Lou > /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 Aug 26 04:17:28 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59DAB1ACD77 for ; Wed, 26 Aug 2015 04:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3MZ-4_U9VWB for ; Wed, 26 Aug 2015 04:17:24 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDB4C1A8F3E for ; Wed, 26 Aug 2015 04:17:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1440587781; bh=+hSoSJQq90mnK1AYImF0Da+yU8wsNEGE9sknwDjCe2M=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=QrgQLOaqfT1VnrEfS2RkjLqgV65LNRg0O51kserC1lQB/MeZeyP24bxTBTjBfm/Ar 1BlaNAdq9yI2ve2/6/HDjCifQu5UHk16JeqeglOMKuwWkARUPYpjbge4RwIW9msrr1 FtXj0OOispOizhlFd31Z7ARAlaAI4saoTi3r8V9E= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; Content-Type: multipart/alternative; boundary="Apple-Mail=_C5729ADB-CEF2-41A8-AE15-717A9F1F50A5" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Nadeau Thomas In-Reply-To: Date: Wed, 26 Aug 2015 07:17:22 -0400 Message-Id: References: <20150820.101533.1535137181522006328.mbj@tail-f.com> <55D7148C.6090508@cisco.com> <20150821.150158.491063432174006492.mbj@tail-f.com> To: Kent Watsen X-Mailer: Apple Mail (2.2104) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-ShareWhite: 50.255.148.181 X-MyRbl: Color=Unknown ip=50.255.148.181 X-IP-stats: Notspam Incoming Last 1, First 103, in=1141, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y34 - root node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 11:17:26 -0000 --Apple-Mail=_C5729ADB-CEF2-41A8-AE15-717A9F1F50A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 =09 > On Aug 25, 2015:1:25 PM, at 1:25 PM, Kent Watsen = wrote: >=20 >=20 > I like the idea of relocatable modules. It is almost to say = everything defined by the IETF should be a grouping, allowing others to = assemble the pieces as they see fit. I do not think it makes sense for = IETF to define an uber structure, especially using a language mandating = forever backwards compatibility=E2=80=A6=20 =09 I personally think this is an important point not just for a = list of the most recent incarnations of modules, but also as we (perhaps = rapidly) iterate and rev modules going forward. In particular, think = about this within the context of the RFC model and what that implies = going forward for model iteration. Assembling pieces, including = different revisions of models, is something we should think about. =E2=80=94tom >=20 > How to support logical/virtual systems is a bigger discussion. = Certainly there is a huge data model overlap between the host system and = the logical systems, but some data may only exist in the host system and = some data may only exist in a logical system. Making things more = interesting, some data in the host system (e.g., an interface) can be = exported to a logical system as a read-only value. The way I solved = this in another life was using conditional enablement [1] on a shared = data model to indicate the applicability of nodes in a context. >=20 > [1] = https://tools.ietf.org/html/draft-kwatsen-conditional-enablement-00 >=20 > Kent, as a contributor >=20 >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --Apple-Mail=_C5729ADB-CEF2-41A8-AE15-717A9F1F50A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8


On = Aug 25, 2015:1:25 PM, at 1:25 PM, Kent Watsen <kwatsen@juniper.net>= wrote:


I like the idea of relocatable modules.  It is = almost to say everything defined by the IETF should be a grouping, = allowing others to assemble the pieces as they see fit.  I do not = think it makes sense for IETF to define an uber structure, especially = using a language mandating forever backwards = compatibility=E2=80=A6 
=
I personally think this is an = important point not just for a list of the most recent incarnations of = modules, but also as we (perhaps rapidly) iterate and rev modules going = forward.  In particular, think about this within the context of the = RFC model and what that implies going forward for model iteration. =   Assembling pieces, including different revisions of models, is = something we should think about.

= =E2=80=94tom



How to support logical/virtual systems is a bigger = discussion.   Certainly there is a huge data model overlap between = the host system and the logical systems, but some data may only exist in = the host system and some data may only exist in a logical system.  Making things more interesting, some data in the host system = (e.g., an interface) can be exported to a logical system as a = read-only value.   The way I solved this in another life was using = conditional enablement [1] on a shared data model to indicate the applicability of nodes in a context.

[1] https://tools.ietf.org/html/draft-kwatsen-conditional-enablemen= t-00

Kent, as a contributor



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

= --Apple-Mail=_C5729ADB-CEF2-41A8-AE15-717A9F1F50A5-- From nobody Wed Aug 26 04:33:58 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8421C1A8AE1; Wed, 26 Aug 2015 04:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sl47q4GZIlZL; Wed, 26 Aug 2015 04:33:54 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6F4E1A89B8; Wed, 26 Aug 2015 04:33:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1440588771; bh=xc86TPe2Xh4jzvnG/6DqGDBsWpRd80zABcmEmkQkQrk=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=bIurOe4kA1ev8D99sBo2hahDu83kGq78QN+EDvZ0KJltcTGBXjFr8Hvmo0Va/cdut UTnrnBYqt03B+U0iNKKK2zh3Pb2lc8JKIEPJqjOsHhrLsDmb8BDBH81twuAOc+8kvi K6vjrlQVwL91Fbipa6lpiQaih4IwIVcXfspdrQhk= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Nadeau Thomas In-Reply-To: <14f696bc290.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> Date: Wed, 26 Aug 2015 07:33:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <194D29DB-A026-481F-8C4C-9201080829A5@lucidvision.com> References: <55D3DDFC.2080107@labn.net> <20150819.112730.1689479932571514728.mbj@tail-f.com> <55D53A13.4080505@labn.net> <20150820.095853.255503105278478154.mbj@tail-f.com> <55DD2A43.8070300@labn.net> <20150826064030.GB84416@elstar.local> <14f696bc290.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> To: Berger Lou X-Mailer: Apple Mail (2.2104) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-ShareWhite: 50.255.148.181 X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=3 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181 X-IP-stats: Notspam Incoming Last 0, First 103, in=1144, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: Cc: netmod@ietf.org, draft-rtgyangdt-rtgwg-device-model@ietf.org, rtgwg@ietf.org Subject: Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 11:33:56 -0000 > On Aug 26, 2015:5:51 AM, at 5:51 AM, Lou Berger = wrote: >=20 >=20 >=20 > On August 26, 2015 2:42:26 AM Juergen Schoenwaelder = wrote: >=20 >> On Tue, Aug 25, 2015 at 10:53:55PM -0400, Lou Berger wrote: >>=20 >>> > Hopefully, a decision to change all existing models (including = vendor >>> > models!) will be based on something more technical than the fact = that >>> > a group of people "really like it" some other way. >>>=20 >>> I'm equally unsure that having an argument of "I got there first" is = a >>> compelling argument given the number of folks (including vendors) = who >>> have stated willingness (or even support) for change. I think = having a >>> major class of users stand up and say this is important should = garner >>> some notice. >>=20 >> Please keep in mind that we are talking about several published >> proposed standards that have been implemented and deployed. I think >> there must be convincing technical reasons to declare them broken and >> to redo them. >>=20 >=20 > As Acee says, we have been trying very hard to minimize any impact to = existing work even when the result is suboptimal. I also agree that = changing PS RFCs should not be done without serious consideration. That = said, the IETF process does permit updates and replacements based on WG = and IETF consensus -- which is not quite the same as your last = statement. >=20 > Lou [Speaking for myself] Is the resistance to this proposal because of the actual changes = to structure, or is it a resistance to churn/change? And if we solved = the latter by say relaxing the rules around how we progress models to = PS, would this alleviate the concerns for the former? The meta question = I will ask is: is the existing RFC process adequate/sufficient for us to = move forward on such a large scale with Yang models at the IETF? Other = organizations currently iterate on models using certain revision = conventions (that are consistent with the rules we put out here) yet = produce multiple versions of the same model within the same year. As a = matter of fact, multiple versions are allowed to coexist within a single = implementation. In stark contrast, the M.O. at the IETF has been to = treat Yang models much like we did SNMP MIBs (or any other document = here) thereby assuming that once it becomes an RFC, that it is largely = set in concrete for many years to come. =20 =E2=80=94tom >=20 >=20 >> /js >>=20 >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >> Fax: +49 421 200 3103 >>=20 >=20 >=20 > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From nobody Wed Aug 26 04:35:24 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0151B2BBD; Wed, 26 Aug 2015 04:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id haUUOFyhpekj; Wed, 26 Aug 2015 04:35:21 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F07C51B2B87; Wed, 26 Aug 2015 04:35:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1440588857; bh=yi+pMUw/GEuLDSXalIKxeYNHADfUFG52Js0uf72qoBk=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=TwmUL18qcsNDCEBuV77GUc/aEZi/gxuXONIt1xifOKWbx5nn1/JQwsNc6V3C8laY8 kQ2xPcII0QXp5OUET69Nv9MPPDTAXTRC6jHe76z1U1wZCE8IB3+JJVcjt9LY0tqYOE 0rI5yoIfF3fGiZRGmFzpnV4wJTGaFpdDKgbffdbc= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Nadeau Thomas In-Reply-To: <20150826.122600.1110046163132211535.mbj@tail-f.com> Date: Wed, 26 Aug 2015 07:35:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <19CCF9F5-87F1-4C41-8151-18AD36D98CE6@lucidvision.com> References: <55DD2A43.8070300@labn.net> <20150826064030.GB84416@elstar.local> <20150826.122600.1110046163132211535.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.2104) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-ShareWhite: 50.255.148.181 X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=4 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181 X-IP-stats: Notspam Incoming Last 0, First 103, in=1145, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: Cc: netmod@ietf.org, draft-rtgyangdt-rtgwg-device-model@ietf.org, rtgwg@ietf.org Subject: Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 11:35:23 -0000 > On Aug 26, 2015:6:26 AM, at 6:26 AM, Martin Bjorklund = wrote: >=20 > "Acee Lindem (acee)" wrote: >>=20 >>=20 >> On 8/26/15, 2:40 AM, "Juergen Schoenwaelder" >> wrote: >>=20 >>> On Tue, Aug 25, 2015 at 10:53:55PM -0400, Lou Berger wrote: >>>=20 >>>>> Hopefully, a decision to change all existing models (including = vendor >>>>> models!) will be based on something more technical than the fact = that >>>>> a group of people "really like it" some other way. >>>>=20 >>>> I'm equally unsure that having an argument of "I got there first" = is a >>>> compelling argument given the number of folks (including vendors) = who >>>> have stated willingness (or even support) for change. I think = having a >>>> major class of users stand up and say this is important should = garner >>>> some notice. >>>=20 >>> Please keep in mind that we are talking about several published >>> proposed standards that have been implemented and deployed. I think >>> there must be convincing technical reasons to declare them broken = and >>> to redo them. >>=20 >> Other than adding /device at the top, we are not obsoleting RFC >> 7223. >=20 > This doesn't make sense. The YANG model is the contract. You are > proposing changing the contract. The fact is that you will be > obsoleting 7223 (and the other RFCs). Existing devices and > applications will have to change in order to handle this new top-level > node (which will be in some other namespace I presume, unless your > proposal is one gigantic monolithic model). >=20 >=20 > /martin Again I will ask: why is this bad? Obviously the implementation = will have to=20 evolve to the new models, but is this relatively static model where we = really want to=20 get to simply because some device vendors/server vendors find it a pain = to iterate models to support the latest versions? Again, others have figured out = how to do this much more rapidly. In the past we have seen what happens to things that = cannot evolve fast enough... =E2=80=94Tom >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Aug 26 04:58:34 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF9E71A8960; Wed, 26 Aug 2015 04:58:32 -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 3PzSqFJhrHNm; Wed, 26 Aug 2015 04:58: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 CBD071A8870; Wed, 26 Aug 2015 04:58:30 -0700 (PDT) Received: from localhost (unknown [173.38.220.43]) by mail.tail-f.com (Postfix) with ESMTPSA id ECAEA1AE049C; Wed, 26 Aug 2015 13:58:25 +0200 (CEST) Date: Wed, 26 Aug 2015 13:58:23 +0200 (CEST) Message-Id: <20150826.135823.2123307386758409523.mbj@tail-f.com> To: tnadeau@lucidvision.com From: Martin Bjorklund In-Reply-To: <194D29DB-A026-481F-8C4C-9201080829A5@lucidvision.com> References: <20150826064030.GB84416@elstar.local> <14f696bc290.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <194D29DB-A026-481F-8C4C-9201080829A5@lucidvision.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org, draft-rtgyangdt-rtgwg-device-model@ietf.org, rtgwg@ietf.org Subject: Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 11:58:32 -0000 Nadeau Thomas wrote: > [Speaking for myself] > > Is the resistance to this proposal because of the actual changes to > structure, or is it a resistance to churn/change? The former. IMO this is technically not a good proposal, as I have tried to explain several times. > And if we solved the > latter by say relaxing the rules around how we progress models to PS, > would this alleviate the concerns for the former? The meta question I > will ask is: is the existing RFC process adequate/sufficient for us to > move forward on such a large scale with Yang models at the IETF? > Other organizations currently iterate on models using certain revision > conventions (that are consistent with the rules we put out here) yet > produce multiple versions of the same model within the same year. As > a matter of fact, multiple versions are allowed to coexist within a > single implementation. In stark contrast, the M.O. at the IETF has > been to treat Yang models much like we did SNMP MIBs (or any other > document here) thereby assuming that once it becomes an RFC, that it > is largely set in concrete for many years to come. In this specific case the change is cosmetic but has disastrous effects on other standard modules, other vendor-specific modules, existing server code and existing client code. I think people expect IETF standards to be a bit more stable than that. /martin From nobody Wed Aug 26 05:09:25 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6521ACD7C; Wed, 26 Aug 2015 05:09:23 -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 p5ARJKQ1M730; Wed, 26 Aug 2015 05:09:22 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D31501A90D2; Wed, 26 Aug 2015 05:09:21 -0700 (PDT) Received: from localhost (unknown [173.38.220.43]) by mail.tail-f.com (Postfix) with ESMTPSA id 71BFA1AE049C; Wed, 26 Aug 2015 14:09:19 +0200 (CEST) Date: Wed, 26 Aug 2015 14:09:18 +0200 (CEST) Message-Id: <20150826.140918.2163222167742824482.mbj@tail-f.com> To: tnadeau@lucidvision.com From: Martin Bjorklund In-Reply-To: <19CCF9F5-87F1-4C41-8151-18AD36D98CE6@lucidvision.com> References: <20150826.122600.1110046163132211535.mbj@tail-f.com> <19CCF9F5-87F1-4C41-8151-18AD36D98CE6@lucidvision.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org, draft-rtgyangdt-rtgwg-device-model@ietf.org, rtgwg@ietf.org Subject: Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 12:09:23 -0000 Nadeau Thomas wrote: > > > On Aug 26, 2015:6:26 AM, at 6:26 AM, Martin Bjorklund > > wrote: > > > > "Acee Lindem (acee)" wrote: > >> > >> > >> On 8/26/15, 2:40 AM, "Juergen Schoenwaelder" > >> wrote: > >> > >>> On Tue, Aug 25, 2015 at 10:53:55PM -0400, Lou Berger wrote: > >>> > >>>>> Hopefully, a decision to change all existing models (including vendor > >>>>> models!) will be based on something more technical than the fact that > >>>>> a group of people "really like it" some other way. > >>>> > >>>> I'm equally unsure that having an argument of "I got there first" is a > >>>> compelling argument given the number of folks (including vendors) who > >>>> have stated willingness (or even support) for change. I think having > >>>> a > >>>> major class of users stand up and say this is important should garner > >>>> some notice. > >>> > >>> Please keep in mind that we are talking about several published > >>> proposed standards that have been implemented and deployed. I think > >>> there must be convincing technical reasons to declare them broken and > >>> to redo them. > >> > >> Other than adding /device at the top, we are not obsoleting RFC > >> 7223. > > > > This doesn't make sense. The YANG model is the contract. You are > > proposing changing the contract. The fact is that you will be > > obsoleting 7223 (and the other RFCs). Existing devices and > > applications will have to change in order to handle this new top-level > > node (which will be in some other namespace I presume, unless your > > proposal is one gigantic monolithic model). > > > > > > /martin > > Again I will ask: why is this bad? My point above was in reply to the statement that "we are not obsoleting RFC 7223" [because the change is so small?] - you would in fact be obsoleting the model in 7223. /martin From nobody Wed Aug 26 05:29:56 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D75E01ACD81 for ; Wed, 26 Aug 2015 05:29:48 -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 eQyPVp2Ft38S for ; Wed, 26 Aug 2015 05:29:45 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id EF7E41A87D7 for ; Wed, 26 Aug 2015 05:29:44 -0700 (PDT) Received: from localhost (unknown [173.38.220.43]) by mail.tail-f.com (Postfix) with ESMTPSA id 1DE761AE049C; Wed, 26 Aug 2015 14:29:40 +0200 (CEST) Date: Wed, 26 Aug 2015 14:29:39 +0200 (CEST) Message-Id: <20150826.142939.241315678797135798.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <20150825.130359.1125823029773095202.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] LL review of 6020bis-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 12:29:49 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3JrbHVu ZCA8bWJqQHRhaWwtZi5jb20+IHdyaXRlczoNCj4gLi4uDQo+IA0KPiA+PiAgICAgIDIuIEkgdGhp bmsgaXQgd291bGQgYmUgdXNlZnVsIHRvIGluY2x1ZGUgdGV4dCAocGVyaGFwcyBpbg0KPiA+PiAg ICAgICAgIHNlYy4gNC4yLjIpIGRlc2NyaWJpbmcgdGhlIHNjaGVtYSB0cmVlIGFuZCBkYXRhIHRy ZWUsIGFuZA0KPiA+PiAgICAgICAgIGludHJvZHVjaW5nIGFwcHJvcHJpYXRlIHRlcm1zIHNvIHRo YXQsIGUuZy4sIG5vZGVzIGluIGVpdGhlcg0KPiA+PiAgICAgICAgIHRyZWUgY2FuIGJlIGNsZWFy bHkgZGlzdGluZ3Vpc2hlZCBpbiB0aGUgc3Vic2VxdWVudCB0ZXh0LiBJbg0KPiA+PiAgICAgICAg IG15IGV4cGVyaWVuY2UsIHRoaXMgY2F1c2VzIGEgbG90IG9mIGNvbmZ1c2lvbi4NCj4gPj4gDQo+ ID4+IAlGb3IgZXhhbXBsZSwgc2VjLiA0LjIuMi4xIHNheXM6ICcgQSBsZWFmIG5vZGUgY29udGFp bnMgc2ltcGxlDQo+ID4+ICAgICAgICAgZGF0YSBsaWtlIGFuIGludGVnZXIgb3IgYSBzdHJpbmcu JyBBbmQgdGhlbiBzZWMuIDcuNjogJyBUaGUNCj4gPj4gICAgICAgICAibGVhZiIgc3RhdGVtZW50 IGlzIHVzZWQgdG8gZGVmaW5lIGEgbGVhZiBub2RlIGluIHRoZSBzY2hlbWENCj4gPj4gICAgICAg ICB0cmVlLicgSWYgdGhlIGxlYWYgbm9kZSBpcyBpbiB0aGUgc2NoZW1hIHRyZWUsIHRoZW4gaXQg Y2Fubm90DQo+ID4+ICAgICAgICAgY29udGFpbiBhbnkgdmFsdWUuDQo+ID4NCj4gPiBUaGUgImxl YWYiIHN0YXRlbWVudCBkZWZpbmVzIGEgbm9kZSBpbiB0aGUgc2NoZW1hIHRyZWUuICBUaGlzIGNh biBiZQ0KPiA+IGluc3RhbnRpYXRlZCBpbiBhIGRhdGEgdHJlZS4gIEEgbGVhZiBub2RlIGluIHRo ZSBkYXRhIHRyZWUgY29udGFpbnMgYQ0KPiA+IHNpbXBsZSB2YWx1ZS4NCj4gPg0KPiA+IFNpbmNl IHNlY3Rpb24gNC4yIGlzIHJlYWxseSBqdXN0IGludGVuZGVkIGFzIGFuIG92ZXJ2aWV3LCBtYXli ZSB3ZSBjYW4NCj4gPiBzL0EgbGVhZiBub2RlIGNvbnRhaW5zL0EgbGVhZiBjb250YWlucy8gKGFu ZCBzaW1pbGFyIGZvciBjb250YWluZXIpPw0KPiANCj4gV2hhdCBhYm91dCAiQSBsZWFmIGluc3Rh bmNlIGNvbnRhaW5zIC4uLiINCg0KT2suDQoNCj4gPj4gICAgICAzLiBJdCdzIG5lY2Vzc2FyeSB0 byBjbGVhcmx5IHNlcGFyYXRlIHByb3BlcnRpZXMgb2YgdGhlIGRhdGEgdHJlZQ0KPiA+PiAgICAg ICAgIGZyb20gcHJvcGVydGllcyBvZiBYTUwgZW5jb2RpbmcuIEZvciBpbnN0YW5jZSwgaXQgaXMg YW4NCj4gPj4gICAgICAgICBpbmhlcmVudCBwcm9wZXJ0eSBvZiBhIGNvbnRhaW5lciBpbnN0YW5j ZSBpbiB0aGUgZGF0YSB0cmVlDQo+ID4+ICAgICAgICAgdGhhdCBpdHMgY2hpbGRyZW4gYXJlIHVu b3JkZXJlZCwgb3Igb3JkZXJlZCBpbiBSUEMNCj4gPj4gICAgICAgICBpbnB1dC9vdXRwdXQuIFll dCB0aGlzIGlzIG9ubHkgc3BlY2lmaWVkIGluIHNlYy4gNy41LjcgKFhNTA0KPiA+PiAgICAgICAg IE1hcHBpbmcgUnVsZXMpLg0KPiA+DQo+ID4gSSB0aGluayB0aGlzIGlzIGEgcHJvcGVydHkgb2Yg dGhlIFhNTCBlbmNvZGluZywgbm90IGFuIGluaGVyZW50DQo+ID4gcHJvcGVydHkgb2YgdGhlIGNv bnRhaW5lci4gIEluIEpTT04sIGFsbCBjaGlsZHJlbiBhcmUgYWx3YXlzDQo+ID4gdW5vcmRlcmVk Lg0KPiANCj4gSSBhc3N1bWUgdGhhdCBkYXRhIGluIHdoYXRldmVyIGVuY29kaW5nIGNvbnRyaWJ1 dGUgdG8gdGhlIHNhbWUNCj4gKGNvbmNlcHR1YWwpIGRhdGEgdHJlZSwgc28gaXQgd291bGQgYmUg dXNlZnVsIHRvIGtub3cgdGhlIHByb3BlcnRpZXMgb2YNCj4gdGhlIGxhdHRlciwgc3VjaCBhcyB3 aGV0aGVyIHNvbWUgZG9jdW1lbnQgb3JkZXIgZXhpc3RzIChhcyBpbiBYTUwpIG9yDQo+IG5vdCAo YXMgaW4gSlNPTikuIA0KDQpPay4gIFdlIGhhdmUgdHdvIGFsdGVybmF0aXZlczoNCg0KMSkgIFNh eSB0aGF0IHRoZSBkYXRhIHRyZWUgaXMgdW5vcmRlcmVkIChvciByYXRoZXIgdGhlIG9yZGVyIGlz DQogICAgaW1wbGVtZW50YXRpb24gc3BlY2lmaWMpDQoNCjIpICBFbmZvcmNlIGFuIG9yZGVyLiAg VGhpcyB3b3VsZCBwcm9iYWJseSBiZSB0aGUgb3JkZXIgdGhhdCB0aGUgbm9kZXMNCiAgICBhcmUg ZGVmaW5lZCBpbiB0aGUgbW9kdWxlIChidXQga2V5cyBmaXJzdCkgKyBhdWdtZW50cyBhZnRlciB0 aGF0Lg0KICAgIFRoZSBwcm9ibGVtIGlzIHRoZW4gaW4gd2hhdCBvcmRlciBhcmUgdGhlIGF1Z21l bnRlZCBub2RlcyBhZGRlZD8NCiAgICBMZXhpY29ncmFwaGljYWxseSBvbiB0aGUgbW9kdWxlIG5h bWUgbWF5YmUuDQoNCkN1cnJlbnRseSB3ZSBoYXZlICgxKS4NCg0KPiA+PiAJU2ltaWxhcmx5LCB0 aGUgbmFtZXNwYWNlIG9mIGEgbW9kdWxlIGFuZCBYTUwgbmFtZXNwYWNlIHRoYXQncw0KPiA+PiAg ICAgICAgIHVzZWQgaW4gWE1MIGVuY29kaW5nIGFyZSBJTU8gdHdvIGRpZmZlcmVudCB0aGluZ3Mg KGNmLiBzZWMNCj4gPj4gICAgICAgICA1LjMpLg0KPiA+DQo+ID4gWWVzLiAgRG8geW91IGhhdmUg YW55IHNwZWNpZmljIGVkaXRzIGluIG1pbmQ/DQo+IA0KPiBTZWN0aW9uIDUuMyBJTU8gY2FuJ3Qg c2F5IHRoYXQgIkFsbCBZQU5HIGRlZmluaXRpb25zIGFyZSBzcGVjaWZpZWQNCj4gd2l0aGluIGEg bW9kdWxlIHRoYXQgaXMgYm91bmQgdG8gYSBwYXJ0aWN1bGFyIFhNTCBuYW1lc3BhY2UNCj4gW1hN TC1OQU1FU10swqAuLi4iIGJlY2F1c2UgWE1MIG5hbWVzcGFjZXMgcmVhbGx5IG1ha2Ugc2Vuc2Ug b25seSBpbg0KPiBYTUwuDQoNCkkgYWdyZWUgdGhhdCBYTUwgbmFtZXNwYWNlcyBtYWtlIHNlbnNl IGluIFhNTC4gIEJ1dCB3aHkgY2FuJ3Qgd2Ugc2F5DQp0aGF0IGFsbCBkZWZpbml0aW9ucyBhcmUg Ym91bmQgdG8gdGhpcyBYTUwgbmFtZXNwYWNlPw0KDQo+IEknZCBzdWdnZXN0IHNvbWV0aGluZyBs aWtlIHRoaXM6DQo+IA0KPiAgICAgQSBZQU5HIG1vZHVsZSBkZWZpbmVzIGEgbmFtZXNwYWNlIHRo YXQgaXMgaWRlbnRpZmllZCBieSB0aGUgbW9kdWxlDQo+ICAgICBuYW1lLiBOYW1lcyBvZiBhbGwg WUFORyBkZWZpbml0aW9ucyBzcGVjaWZpZWQgaW4gYSBtb2R1bGUgYmVsb25nIHRvDQo+ICAgICBp dHMgbmFtZXNwYWNlLg0KDQpCdXQgdGhpcyB0ZXh0IGRvZW5zJ3QgYmVsb25nIHRvIHNlY3Rpb24g NS4zLg0KDQo+IEFuZCB0aGVuDQo+IA0KPiAgICAgU3RhdGVtZW50cyAibmFtZXNwYWNlIiBhbmQg InByZWZpeCIgZGVmaW5lIGEgbWFwcGluZyBvZiB0aGUgbW9kdWxlDQo+ICAgICBuYW1lc3BhY2Ug dG8gdGhlIFhNTCBuYW1lc3BhY2UgYW5kIHJlY29tbWVuZGVkIHByZWZpeCB0YWh0IGFyZSB1c2Vk DQo+ICAgICBpbiBYTUwgZW5jb2RpbmcuDQo+IA0KPiA+DQo+ID4+ICAgICAgNC4gVGVybXMgImlu c3RhbmNlIi8iaW5zdGFudGlhdGUiLyJpbnN0YXRpYXRpb24iIGFyZSB1c2VkIGluIGENCj4gPj4g ICAgICAgICBsb29zZSB3YXkgd2l0aG91dCBiZWluZyBwcm9wZXJseSBkZWZpbmVkLCBwcm9iYWJs eSBhcyBTTk1QDQo+ID4+ICAgICAgICAgbGVnYWN5LiBUaGUgWE1MIHRlcm0gImluc3RhbmNlIGRv Y3VtZW50IiBhZGRzIHlldCBhbm90aGVyDQo+ID4+ICAgICAgICAgbWVhbmluZy4NCj4gPg0KPiA+ IEknbSBub3Qgc3VyZSB0aGVzZSBhcmUgU05NUCBzcGVjaWZpYyB0ZXJtcy4gIEkgdGhvdWdodCB0 aGV5IHdlcmUgbW9yZQ0KPiA+IGdlbmVyaWMuICBEbyB5b3UgaGF2ZSBhbnkgcHJvcG9zZWQgZWRp dHM/DQo+IA0KPiBJIGFtIG5vdCBzdXJlIHdoYXQgaXQgZXhhY3RseSBtZWFucy4gRm9yIGV4YW1w bGUsIHdoYXQgaXMgYW4gaW5zdGFuY2UgaW4NCj4gdGhlIGNhc2Ugb2YgYSBsaXN0L2xlYWYtbGlz dDogaXMgaXQgdGhlIGNvbXBsZXRlIGFycmF5IG9yIGFuIGluZGl2aWR1YWwNCj4gbGlzdCBlbnRy eT8NCg0KTWF5YmUgaXQgaGVscHMgaWYgeW91IHBvaW50IHRvIHNwZWNpZmljIHRleHQgdGhhdCBp cyBwcm9ibGVtYXRpYy4gIEkNCmZpbmQgZm9yIGV4YW1wbGU6DQoNCiAgIEEgbGlzdCBub2RlIG1h eSBleGlzdCBpbiBtdWx0aXBsZSBpbnN0YW5jZXMgaW4gdGhlIGRhdGENCiAgIHRyZWUuICBFYWNo IHN1Y2ggaW5zdGFuY2UgaXMga25vd24gYXMgYSBsaXN0IGVudHJ5Lg0KDQo+ID4+ICAgICAgNS4g QSB0ZXJtIGlzIG5lZWRlZCBmb3IgZGVzY3JpYmluZyBhIGRhdGEgbW9kZWwgb2YgYSBwYXJ0aWN1 bGFyDQo+ID4+ICAgICAgICAgc2VydmVyLCBpLmUuIGEgY29sbGVjdGlvbiBvZiBtb2R1bGVzICsg c3VwcG9ydGVkIGZlYXR1cmVzICgrDQo+ID4+ICAgICAgICAgZGV2aWF0aW9ucykuIEkndmUgdXNl ZCAiZGF0YSBtb2RlbCIsIHNlZQ0KPiA+PiAgICAgICAgIGh0dHBzOi8vZ2l0aHViLmNvbS9tYmo0 NjY4L3B5YW5nL3dpa2kvVHV0b3JpYWwjeWFuZy1kYXRhLW1vZGVsDQo+ID4NCj4gPiBUaGUgdGVy bSAiZGF0YSBtb2RlbCIgaXMgYWxyZWFkeSB1c2VkIGluIGEgbXVjaCBtb3JlIGdlbmVyaWMgd2F5 IGluDQo+ID4gNjAyMC4NCj4gPg0KPiA+ICJzZXJ2ZXIgWUFORyBkYXRhIG1vZGVsIiBtYXliZS4N Cj4gDQo+IFBlcmhhcHMgd2UgY291bGQgdXNlICJkYXRhIG1vZGVsIiBpbiB0aGUgZ2VuZXJhbCBz ZW5zZSBhcyBkZWZpbmVkIGluDQo+IHNlYy4gMywgYW5kIHRoZW4gIllBTkcgZGF0YSBtb2RlbCIg YXMgdGhlIHN1YnN0YW5jZSBvZiB0aGUgWUFORw0KPiAiY29udHJhY3QiLCB3aGljaCBjYW4gYmUg ZXhhY3RseSBjb25zdHJ1Y3RlZCBmcm9tIHRoZSBzZXJ2ZXIncyBoZWxsbyBvcg0KPiB5YW5nLWxp YnJhcnkuDQoNCldoYXQgZG8geW91IGNhbGwgdGhlIGNvbXBsZXRlIHNldCBvZiBtb2R1bGVzIGlu IGEgY2xpZW50IHRoZW4/DQoNCkJ1dCBJIGFtIG5vdCBzdXJlIHRoZSBjdXJyZW50IHRleHQgbmVl ZCB0aGlzIHRlcm0/DQoNCj4gPj4gICAgICA2LiBBcyBKw7xyZ2VuIHN1Z2dlc3RlZCwgc2VjdGlv bnMgIlhNTCBNYXBwaW5nIFJ1bGVzIiBzaG91bGQgYmUNCj4gPj4gCW1vcmUgYXBwcm9wcmlhdGVs eSBjYWxsZWQgIlhNTCBFbmNvZGluZyBSdWxlcyIuDQo+ID4NCj4gPiBGaXhlZC4NCj4gPg0KPiA+ PiAgICAgIDcuIEknZCByZW1vdmUgYWxsIG1lbnRpb25zIG9mIHN1Ym1vZHVsZXMgaW5jbHVkaW5n IG90aGVyDQo+ID4+ICAgICAgICAgc3VibW9kdWxlcywgY2lyY3VsYXIgaW5jbHVkZXMgZXRjLiBi ZWNhdXNlIGl0IGlzIG5vdw0KPiA+PiAgICAgICAgIGNvbmZ1c2luZy4gSWYgImluY2x1ZGUiIGlz IGlnbm9yZWQgaW4gc3VibW9kdWxlcywgdGhlcmUgaXMgbm8NCj4gPj4gICAgICAgICBuZWVkIHRv IGJvdGhlciB3aXRoIGFueSBydWxlcy4gVGhpcyBzZW50ZW5jZSBpbiBzZWMuIDcuMS42DQo+ID4+ ICAgICAgICAgc2hvdWxkIGJlIGVub3VnaDogJ0ZvciBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IHdp dGggWUFORw0KPiA+PiAgICAgICAgIHZlcnNpb24gMSwgdGhlICJpbmNsdWRlIiBzdGF0ZW1lbnQg aXMgcGVybWl0dGVkIGluIGEgc3VibW9kdWxlDQo+ID4+ICAgICAgICAgYnV0IGhhcyBubyBlZmZl Y3QgdGhlcmUuJw0KPiA+DQo+ID4gSSBmb3VuZCBvbmx5IHRoaXMgc2VudGVuY2U6DQo+ID4NCj4g PiAgIFN1Ym1vZHVsZXMgYXJlIG9ubHkgYWxsb3dlZCB0byBpbmNsdWRlIG90aGVyIHN1Ym1vZHVs ZXMgYmVsb25naW5nIHRvDQo+ID4gICB0aGUgc2FtZSBtb2R1bGUuDQo+ID4NCj4gPiB3aGljaCBJ IGhhdmUgbm93IHJlbW92ZWQuDQo+IA0KPiAtIFNlYy4gNC4xOiAiRGVyaXZlZCB0eXBlcyBhbmQg Z3JvdXBpbmdzIGNhbiBiZSBkZWZpbmVkIGluIG9uZSBtb2R1bGUgb3INCj4gICBzdWJtb2R1bGUg YW5kIHVzZWQgaW4gZWl0aGVyIHRoYXQgbG9jYXRpb24gb3IgaW4gYW5vdGhlciBtb2R1bGUgb3IN Cj4gICBzdWJtb2R1bGUgdGhhdCBpbXBvcnRzIG9yIGluY2x1ZGVzIGl0LiINCj4gDQo+ICAgUmVt b3ZlICJvciBzdWJtb2R1bGUiIHR3aWNlIGFuZCAib3IgaW5jbHVkZXMiLg0KPiANCj4gLSBTZWMu IDUuMTogIlRoZXJlIE1VU1QgTk9UIGJlIGFueSBjaXJjdWxhciBjaGFpbnMgb2YgaW1wb3J0cyBv cg0KPiAgIGluY2x1ZGVzLiINCj4gDQo+ICAgUmVtb3ZlICJvciBpbmNsdWRlcyIgLSBzaW5jZSBp bmNsdWRlcyBpbiBzdWJtb2R1bGVzIGFyZSBhIG5vLW9wLA0KPiAgIGNpcmN1bGFyIGluY2x1ZGVz IGNhbm5vdCBoYXBwZW4uDQoNCkZpeGVkLg0KDQo+ID4+ICoqKiogU2VjLiAzDQo+ID4+ICAgICAg LSBTaG91bGRuJ3QgdGhlIHRlcm0gImRhdGEgdHJlZSIgYWxzbyBjb3ZlciB0aGUgY29udGVudHMg b2YgUlBDDQo+ID4+ICAgICAgICBpbnB1dC9vdXRwdXQsIGFjdGlvbnMgYW5kIG5vdGlmaWNhdGlv bnM/DQo+ID4NCj4gPiBZZXMsIHByb2JhYmx5LiAgQnV0IHRoZW4gd2UgbmVlZCB0byBoYXZlIGEg dGVybSBmb3Igc29tZSBvZiB0aGUNCj4gPiBjdXJyZW50IHVzYWdlcyBvZiAiZGF0YSB0cmVlIi4g IE1heWJlICJkYXRhc3RvcmUiIHdvcmtzICh0aGlzIHRlcm0gaXMNCj4gPiBhbHJlYWR5IHVzZWQp Lg0KPiANCj4gV2hhdCBjdXJyZW50IHVzYWdlcyBvZiAiZGF0YSB0cmVlIiBkbyB5b3UgbWVhbj8N Cg0KRm9yIGV4YW1wbGU6DQoNCiAgVGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBhbiBhY3Rpb24gYW5k IGFuIHJwYyBpcyB0aGF0IGFuIGFjdGlvbiBpcyB0aWVkDQogIHRvIGEgbm9kZSBpbiB0aGUgZGF0 YSB0cmVlDQoNCldlIGFsc28gdGFsayBhYm91dCAiY29uZmlndXJhdGlvbiBkYXRhIHRyZWUiLiAg KEluIHRoZSBzZWN0aW9uIGFib3V0DQpjb25zdHJhaW50cywgd2hpY2ggd291bGQgYmVuZWZpdCBm cm9tIGEgdGVybSBmb3IgZGlmZmVyZW50ICdkYXRhDQp0cmVlcycpLg0KDQo+IFNlYy4gMzoNCj4g DQo+IE9MRA0KPiANCj4gICAgbyAgZGF0YSB0cmVlOiBUaGUgaW5zdGFudGlhdGVkIHRyZWUgb2Yg Y29uZmlndXJhdGlvbiBhbmQgc3RhdGUgZGF0YQ0KPiAgICAgICBvbiBhIGRldmljZS4NCj4gDQo+ IE5FVw0KPiANCj4gICAgbyBkYXRhIHRyZWU6IFRoZSBpbnN0YW50aWF0ZWQgdHJlZSBvZiBjb25m aWd1cmF0aW9uLCBzdGF0ZSBkYXRhLA0KPiAgICAgIGNvbWJpbmVkIGNvbmZpZ3VyYXRpb24gYW5k IHN0YXRlIGRhdGEsIFJQQyBpbnB1dCBvciBvdXRwdXQsIG9yDQo+ICAgICAgbm90aWZpY2F0aW9u Lg0KPiANCj4gPj4gKioqKiBTZWMuIDYuMS4zDQo+ID4+ICAgICAgSSB0aGluayB0aGUgcnVsZXMg Zm9yIHdoaXRlc3BhY2UgdHJpbW1pbmcgYXJlIGNvbmZ1c2luZyBhbmQgaGF2ZQ0KPiA+PiAgICAg IHZlcnkgbGl0dGxlIHByYWN0aWNhbCB1c2VzLCBzbyBJJ2QgcmVjb21tZW5kIHRvIHJlbW92ZSB0 aGVtDQo+ID4+ICAgICAgZW50aXJlbHkuIEhvd2V2ZXIsIGlmIHRoZSBkZWNpc2lvbiBpcyB0byBr ZWVwIHRoZW0sIHRoZSBmb2xsb3dpbmcNCj4gPj4gICAgICBhbWJpZ3VpdGllcyBuZWVkIHRvIGJl IGFkZHJlc3NlZDoNCj4gPj4gICAgICAtIEl0IGlzIHVuY2xlYXIgd2hldGhlciAnXG4nIGlzIGVx dWl2YWxlbnQgdG8gdGhlIGxpdGVyYWwgTEYNCj4gPj4gICAgICAgIGNoYXJhY3RlciBpbiB0aGUg dHJpbW1pbmcgcHJvY2VzcywgaS5lLiB3aGV0aGVyIHRoZQ0KPiA+PiAgICAgICAgc3Vic3RpdHV0 aW9uIG9mIGVzY2FwZSBzZXF1ZW5jZXMgaXMgZG9uZSBiZWZvcmUgb3IgYWZ0ZXIgdGhlDQo+ID4+ ICAgICAgICB0cmltbWluZy4NCj4gPg0KPiA+IEhvdyBkb2VzIHRoaXMgbWF0dGVyPw0KPiANCj4g QXJlIHRoZSBmb2xsb3dpbmcgdHdvIGRlZmF1bHRzIGlkZW50aWNhbCBvciBub3Q/DQo+IA0KPiBk ZWZhdWx0ICJmb28NCj4gICAgICAgICAgYmFyIjsNCj4gDQo+IGRlZmF1bHQgImZvb1xuXHQgYmFy IjsNCg0KTm8uDQoNCk9rLCBob3cgYWJvdXQ6DQoNCk9MRDoNCg0KICBXaGl0ZXNwYWNlIHRyaW1t aW5nIGFuZCBzdWJzdGl0dXRpb24gb2YgYmFja3NsYXNoLWVzY2FwZWQgY2hhcmFjdGVycw0KICBp biBkb3VibGUtcXVvdGVkIHN0cmluZ3MgaXMgZG9uZSBiZWZvcmUgY29uY2F0ZW5hdGlvbi4NCg0K TkVXOg0KDQogIFdoaXRlc3BhY2UgdHJpbW1pbmcgaXMgZG9uZSBiZWZvcmUgc3Vic3RpdHV0aW9u IG9mIGJhY2tzbGFzaC1lc2NhcGVkDQogIGNoYXJhY3RlcnMgaW4gZG91YmxlLXF1b3RlZCBzdHJp bmdzLiAgQ29uY2F0ZW5hdGlvbiBpcyBwZXJmb3JtZWQgYXMNCiAgdGhlIGxhc3Qgc3RlcC4NCg0K PiA+PiAgICAgIC0gSXMgdGFiIGNoYXJhY3RlciB0cmVhdGVkIGFzIDggc3BhY2VzIGFsc28gYmVm b3JlIHRoZSBvcGVuaW5nDQo+ID4+ICAgICAgICBkb3VibGUgcXVvdGU/IEV4YW1wbGU6DQo+ID4+ IA0KPiA+PiAgICAgICAgZGVzY3JpcHRpb24gIlRoaXMgaXMgYSBsb25nDQo+ID4+ICAgICAgICAg ICAgICAgICAgICAgdGV4dC4iDQo+ID4+IA0KPiA+PiAgICAgICAgRG9lcyBpdCBtYXR0ZXIgd2hl dGhlciB0aGUgY2hhcmFjdGVyIGJldHdlZW4gImRlc2NyaXB0aW9uIiBhbmQNCj4gPj4gICAgICAg IHRoZSBvcGVuaW5nIGRvdWJsZSBxdW90ZSBpcyBhIHNwYWNlIG9yIHRhYiBjaGFyYWN0ZXI/IChC b3RoDQo+ID4+ICAgICAgICBjYXNlcyBtYXkgaGF2ZSBpZGVudGljYWwgdmlzdWFsIHJlbmRlcmlu ZyBkZXBlbmRpbmcgb24gdGhlDQo+ID4+ICAgICAgICBjb2x1bW4gd2hlcmUgdGhlIHN0YXRlbWVu dCBzdGFydHMuKQ0KPiA+DQo+ID4gSSB3b3VsZCB0aGluayBzby4gIEkgdGhpbmsgd2hpdGVzcGFj ZS10cmltbWluZyBpbiBnZW5lcmFsIGlzIHZlcnkNCj4gPiB1c2VmdWwsIGJ1dCB0aGUgdGFiLWV4 cGFuc2lvbiBpcyBhIGJpdCBjb25mdXNpbmcuICBJIHRoaW5rIGl0IHdvdWxkIGJlDQo+ID4gb2sg dG8gcmVtb3ZlIHRoZSBleHBhbnNpb24gb2YgdGFiIHdpdGggOCBzcGFjZXMuDQo+IA0KPiBJIGRv bid0IHRoaW5rIHRoZXkgYXJlIHRoYXQgdXNlZnVsLiBJbiBwcmFjdGljZSwgc3VjaCBtdWx0aWxp bmUgc3RyaW5ncw0KPiBvbmx5IGFwcGVhciBpbiBkZXNjcmlwdGlvbnMgYW5kIHJlZmVyZW5jZXMg d2hlcmUgd2hpdGVzcGFjZSB0cmltbWluZw0KPiBpcyBwcmV0dHkgbXVjaA0KPiBpcnJlbGV2YW50 Lg0KDQpJdCBpcyBub3QgaXJyZWxldmFudCBpZiB5b3UgdHJhbnNmb3JtIGRlc2NyaXB0aW9ucyB0 byBzb21lIG90aGVyDQpmb3JtYXQsIHN1Y2ggYXMgWUlOIG9yIGEgbWFuLXBhZ2Ugb3Igd2hhdGV2 ZXIuDQoNCj4gPj4gICAgICAgICogSXQgbWlnaHQgYmUgdXNlZnVsIHRvIGRlZmluZSBob3cgbmFt ZXNwYWNlIG5vZGVzIHJlcHJlc2VudGluZw0KPiA+PiAgICAgICAgICBZQU5HIG5hbWVzcGFjZXMg YXBwZWFyIGluIHRoZSBYUGF0aCB0cmVlIHNvIHRoYXQgdGhlDQo+ID4+ICAgICAgICAgIG5hbWVz cGFjZTo6IGF4aXMgd29ya3MgaW4gYSBkZXRlcm1pbmlzdGljIGZhc2hpb24uIEZvcg0KPiA+PiAg ICAgICAgICBleGFtcGxlLCBvbmUgY291bGQgc2F5IHRoYXQgYWxsIHRoZXNlIG5hbWVzcGFjZXMg YXJlIGluIHNjb3BlDQo+ID4+ICAgICAgICAgIGZvciBhbGwgZWxlbWVudHMgY29ycmVzcG9uZGlu ZyB0byBZQU5HIGRhdGEgbm9kZXMuIE9uZSBjb3VsZA0KPiA+PiAgICAgICAgICB1c2UgaXQsIGUu Zy4gdG8gZGV0ZXJtaW5lIHdoZXRoZXIgYSBwYXJ0aWN1bGFyIFlBTkcgbW9kdWxlIGlzDQo+ID4+ ICAgICAgICAgIGEgcGFydCBvZiB0aGUgZGF0YSBtb2RlbC4NCj4gPg0KPiA+IFdoeSB3b3VsZG4n dCB0aGUgbmFtZXNwYWNlIGF4aXMgd29yayBpbiBhIGRldGVybWluaXN0aWMgZmFzaGlvbj8gIEFs bA0KPiA+IG5vZGVzIGRlZmluZWQgaW4gYSBtb2R1bGUgaGF2ZSB0aGUgc2FtZSBYTUwgbmFtZXNw YWNlLCB3aGljaCBpcw0KPiA+IHdlbGwtZGVmaW5lZC4NCj4gDQo+IFRoZSBjb250ZW50IG9mIHRo ZSBuYW1lc3BhY2U6OiBheGlzIGRlcGVuZHMgb24gaG93IGV4YWN0bHkgWE1MDQo+IG5hbWVzcGFj ZXMgYXJlIHNwZWNpZmllZC4NCg0KW3JlLXJlYWRpbmcgdGhlIHRleHQgb24gbmFtZXNwYWNlIG5v ZGVzLi4uXQ0KDQpPay4NCg0KPiBGb3IgZXhhbXBsZSwgaXQgd291bGQgYmUgZGlmZmVyZW50IGZv ciB0aGUNCj4gImZvbyIgZWxlbWVudCBpbiBlYWNoIG9mIHRoZSBmb2xsb3dpbmcgdGhyZWUgY2Fz ZXM6DQo+IA0KPiA8YSB4bWxucz0iaHR0cDovL2V4YW1wbGUuY29tL2ZvbyI+DQo+ICAgPGIgeG1s bnM9Imh0dHA6Ly9leGFtcGxlLmNvbS9iYXIiLz4NCj4gPC9hPg0KPiANCj4gPGZvbzphIHhtbG5z OmZvbz0iaHR0cDovL2V4YW1wbGUuY29tL2ZvbyI+DQo+ICAgPGIgeG1sbnM9Imh0dHA6Ly9leGFt cGxlLmNvbS9iYXIiLz4NCj4gPC9mb286YT4NCj4gDQo+IDxmb286YSB4bWxuczpmb289Imh0dHA6 Ly9leGFtcGxlLmNvbS9mb28iPg0KPiAgICAgICAgeG1sbnM6YmFyPSJodHRwOi8vZXhhbXBsZS5j b20vYmFyIj4NCj4gICA8YmFyOmIgeG1sbnM9Imh0dHA6Ly9leGFtcGxlLmNvbS9iYXIiLz4NCj4g PC9mb286YT4NCj4gDQo+IEknZCBzdWdnZXN0IHRvIGhhdmUgaXQgYnkgZGVmaW5pdGlvbiBzbyB0 aGF0IGFsbCBuYW1lc3BhY2VzIGFyZQ0KPiBzcGVjaWZpZWQgb3V0c2lkZSB0aGUgZGF0YSB0cmVl IC0gYXMgaWYgdGhlIGRlZmluaXRpb25zIGFyZSBvbiB0aGUNCj4gZW5jYXBzdWxhdGluZyBORVRD T05GIDxkYXRhPiBvciA8Y29uZmlnPiAtIGFuZCB3aXRoIHByZWZpeGVzIHRoYXQgYXJlDQo+IGRl ZmluZWQgaW4gdGhlIG1vZHVsZXMgKHVubGVzcyB0aGVyZSBpcyBhIGNvbmZsaWN0KS4NCg0KV2Vs bCwgc2luY2UgdGhlIGxvY2FsLW5hbWUgb2YgYSBuYW1lc3BhY2Ugbm9kZSBpcyB0aGUgcHJlZml4 LCBJIHRoaW5rDQppdCB3b3VsZCBiZSBtb3JlIGNvcnJlY3QgdG8gc2F5IGFsbCBub2RlcyBkZWZp bmVkIGluIGEgbW9kdWxlIGhhdmUgdGhlDQpzYW1lIHNldCBvZiBuYW1lc3BhY2Ugbm9kZXMsIGFu ZCB0aGF0IHRoaXMgc2V0IGJ1aWx0IGZyb20gdGhlIHRoZSBvd24NCm1vZHVsZSArIGFsbCBpbXBv cnRzLiAgKGV4YWN0IHRleHQgVEJELi4uKQ0KDQoNCj4gPj4gKioqKiBTZWMuIDcuNi4xDQo+ID4+ ICAgICAgLSBUaGUgdGV4dCBpcyBzdWl0YWJsZSBmb3IgY29uZmlnLCBkZWZhdWx0cyBpbiBSUEMg aW5wdXQvb3V0cHV0DQo+ID4+ICAgICAgICBhbmQgbm90aWZpY2F0aW9ucyBhcmUgY292ZXJlZCBl bHNld2hlcmUsIGJ1dCB3aGF0IGFib3V0DQo+ID4+ICAgICAgICBkZWZhdWx0cyAoYW5kIG1hbmRh dG9yeSkgaW4gc3RhdGUgZGF0YT8NCj4gPg0KPiA+IEkgZG9uJ3QgdGhpbmsgdGhpcyB0ZXh0IGlz IGV4Y2x1ZGVzIHN0YXRlIGRhdGEuDQo+IA0KPiBJIHRoaW5rIHRoZSBzZW1hbnRpY3Mgb2YgZGVm YXVsdHMgaW4gY29uZmlndXJhdGlvbiBhbmQgc3RhdGUgZGF0YSBpcw0KPiBkaWZmZXJlbnQgLSBz dGF0ZSBkYXRhIGp1c3QgcmVwb3J0IChob3BlZnVsbHkgdHJ1ZSkgc3RhdGUsIHNvIHRoZQ0KPiBy ZXF1aXJlbWVudCB0aGF0ICJ0aGUgc2VydmVyIE1VU1Qgb3BlcmF0aW9uYWxseSBiZWhhdmUgYXMg aWYgdGhlIGxlYWYNCj4gd2FzIHByZXNlbnQgaW4gdGhlIGRhdGEgdHJlZSB3aXRoIHRoZSBkZWZh dWx0IHZhbHVlIGFzIGl0cyB2YWx1ZSIgc2VlbXMNCj4gc29tZXdoYXQgYmFja3dhcmRzLg0KDQpJ IHRoaW5rIHRoaXMgbWVhbnMgdGhhdCBhIHNlcnZlciBjYW4gY2hvb3NlIHRvIE5PVCBzZW5kIGRl ZmF1bHQgdmFsdWVzDQpmb3Igc3RhdGUgbm9kZS4gIEJ1dCBpdCBhbHNvIGFsbG93cyBhIHNlcnZl ciB0byBhbHdheXMgc2VuZCBhbGwNCnZhbHVlcy4NCg0KPiA+PiAqKioqIFNlYy4gNy44LjYNCj4g Pj4gICAgICAtIEl0IHdvdWxkIGJlIGhlbHBmdWwgdG8gaW5jbHVkZSBhbiBleGFtcGxlIG9mIHlh bmc6a2V5IGF0dHJpYnV0ZQ0KPiA+PiAgICAgICAgdmFsdWUgd2l0aCBtdWx0aXBsZSAodHdvKSBr ZXlzLiBJIHJlbWVtYmVyIHNvbWVib2R5IGFza2VkIG1lDQo+ID4+ICAgICAgICBhYm91dCB0aGF0 Lg0KPiA+DQo+ID4gRml4ZWQuDQo+ID4NCj4gPj4gKioqKiBTZWMuIDcuOS4yDQo+ID4+ICAgICAg LSBUaGUgcGFyYWdyYXBoIGFib3V0IHNob3J0aGFuZCBjYXNlIHN0YXRlbWVudCBzaG91bGQgbW9y ZQ0KPiA+PiAgICAgICAgZXhwbGljaXRseSBleHBsYWluIHRoYXQgYSBjYXNlIG5vZGUgaXMgcHJl c2VudCBpbiB0aGUgc2NoZW1hDQo+ID4+ICAgICAgICB0cmVlIGV2ZW4gZm9yIHNob3J0LWNhc2Ut c3RtdCwgYW5kIHRodXMgc2NoZW1hIG5vZGUgaWRlbnRpZmllcnMNCj4gPj4gICAgICAgIGFsd2F5 cyBuZWVkIHRvIGluY2x1ZGUgY2FzZSBub2RlIGlkZW50aWZpZXJzLg0KPiA+DQo+ID4gSSBkb24n dCB1bmRlcnN0YW5kIGhvdyB0aGUgY3VycmVudCB0ZXh0IGNvdWxkIGdpdmUgdGhlIGltcHJlc3Np b24gdGhhdA0KPiA+IHRoZXJlIGlzIG5vIGNhc2Ugbm9kZSBpbiB0aGUgc2NoZW1hIHRyZWUgb2Yg c2hvcnRoYW5kIGNhc2VzIGFyZSB1c2VkLg0KPiANCj4gT0xEDQo+IA0KPiBJbiB0aGlzIGNhc2Us IHRoZSBpZGVudGlmaWVyIG9mIHRoZSBjYXNlIG5vZGUgaXMgdGhlIHNhbWUgYXMgdGhlDQo+IGlk ZW50aWZpZXIgaW4gdGhlIGJyYW5jaCBzdGF0ZW1lbnQuDQo+IA0KPiBORVcNCj4gDQo+IEluIHRo aXMgY2FzZSwgdGhlIGNhc2Ugbm9kZSBzdGlsbCBleGlzdHMgaW4gdGhlIHNjaGVtYSB0cmVlLCBh bmQgaXRzDQo+IGlkZW50aWZpZXIgaXMgdGhlIHNhbWUgYXMgdGhlIGlkZW50aWZpZXIgaW4gdGhl IGJyYW5jaCBzdGF0ZW1lbnQuIFNjaGVtYQ0KPiBub2RlIGlkZW50aWZpZXJzIChTZWN0aW9uwqA2 LjUpIE1VU1QgYWx3YXlzIGV4cGxpY2l0bHkgaW5jbHVkZSBjYXNlIG5vZGUNCj4gaWRlbnRpZmll cnMNCg0KT2ssIEknbGwgYWRkIHRoaXMuDQoNCj4gLSBpZiBhIHNob3J0aGFuZCBjYXNlIHN0YXRl bWVudCBpcyB1c2VkLCB0aGUgaWRlbnRpZmllciBvZg0KPiB0aGUgYnJhbmNoIHN0YXRlbWVudCB3 aWxsIGFwcGVhciB0d2ljZS4gDQoNCi4uLiBidXQgdGhpcyBwYXJ0IGlzIHNvbWVod2F0IGNvbmZ1 c2luZyAtIEkgdW5kZXJzdGFuZCB3aGF0IHlvdSBtZWFuLA0KYnV0IG1heWJlIHdlIGNhbiBza2lw IGl0Pw0KDQoNCj4gPj4gKioqKiBTZWMuIDcuMTANCj4gPj4gICAgICAtIFRoZSBzZWN0aW9uIHNo b3VsZCBhbHNvIHN0YXRlIHRoYXQgdGhlIGRhdGEgbW9kZWwgZm9yICJhbnlkYXRhIg0KPiA+PiAg ICAgICAgY29udGVudCBtYXkgb3IgbWF5IG5vdCBiZSBrbm93biBhdCBydW4gdGltZS4NCj4gPg0K PiA+IEhvdyBhYm91dCB0aGlzOg0KPiA+DQo+ID4gTkVXOg0KPiA+DQo+ID4gICBBbiBpbXBsZW1l bnRhdGlvbiBtYXkgb3IgbWF5IG5vdCBrbm93IHRoZSBkYXRhIG1vZGVsIHVzZWQgdG8gbW9kZWwg YQ0KPiA+ICAgc3BlY2lmaWMgaW5zdGFuY2Ugb2YgYW4gYW55ZGF0YSBub2RlLg0KPiANCj4gT0su DQo+IA0KPiA+DQo+ID4NCj4gPj4gKioqKiBTZWMuIDcuMTINCj4gPj4gICAgICAtICdGb3IgZXh0 ZW5zaW9ucywgdGhpcyBtZWFucyB0aGF0IGV4dGVuc2lvbnMgYXJlIGFwcGxpZWQgdG8gdGhlDQo+ ID4+ICAgICAgICBncm91cGluZyBub2RlLCBub3QgdGhlIHVzZXMgbm9kZS4nDQo+ID4+IA0KPiA+ PiAgICAgICAgSSBkb250IHVuZGVyc3RhbmQgd2hhdCB0aGlzIG1lYW5zLiBXaGF0IGlzIHRoZSAi Z3JvdXBpbmcgbm9kZSI/DQo+ID4NCj4gPiBSaWdodDsgdGhlcmUgaXMgbm8gImdyb3VwaW5nIG5v ZGUiIGFuZCBubyAidXNlcyBub2RlIi4gIEkgc3VnZ2VzdCB3ZQ0KPiA+IHNpbXBseSBkbzoNCj4g Pg0KPiA+IE5FVzoNCj4gPg0KPiA+ICAgIEZvciBleHRlbnNpb25zLCB0aGlzIG1lYW5zIHRoYXQg ZXh0ZW5zaW9ucyBhcmUgYXBwbGllZCB0byB0aGUNCj4gPiAgICBncm91cGluZyBpdHNlbGYuDQo+ IA0KPiBJIHN0aWxsIGRvbid0IGdldCB0aGUgcG9pbnQuIEhvdyBkb2VzIGl0IGFwcGx5IGUuZy4g dG8gTkFDTSBleHRlbnNpb25zDQo+IGlmIHRoZXkgYXJlIHVzZWQgaW5zaWRlIGEgZ3JvdXBpbmc/ IA0KDQpBaCwgb2ssIEkgc2VlIGhvdyBpdCBpcyB1bmNsZWFyLiAgSG93IGFib3V0Og0KDQpORVc6 DQoNCiAgICBGb3IgZXh0ZW5zaW9ucywgdGhpcyBtZWFucyB0aGF0IGV4dGVuc2lvbnMgZGVmaW5l ZCBhcyBkaXJlY3QNCiAgICBjaGlsZHJlbiB0byBhICJncm91cGluZyIgc3RhdGVtZW50IGFyZSBh cHBsaWVkIHRvIHRoZQ0KICAgIGdyb3VwaW5nIGl0c2VsZi4NCg0KPiA+PiAqKioqIFNlYy4gNy4x NQ0KPiA+PiAgICAgIC0gJ0FuIGFjdGlvbiBNVVNUIE5PVCBiZSBkZWZpbmVkIHdpdGhpbiBhbiBy cGMsIGFub3RoZXIgYWN0aW9uIG9yIGENCj4gPj4gICAgICAgICBub3RpZmljYXRpb24sIOKApicN Cj4gPj4gDQo+ID4+ICAgICAgICBBbHNvIGl0IE1VU1QgTk9UIGJlIGRlZmluZWQgd2l0aGluIGxl YWYgYW5kIGxlYWYtbGlzdCwgcmlnaHQ/DQo+ID4NCj4gPiBSaWdodCwgYnV0IHRoaXMgaXMgbm90 IGFsbG93ZWQgYWNjb3JkaW5nIHRvIHRoZSBncmFtbWFyLg0KPiANCj4gSSB3b3VsZCBzdGlsbCBh ZGQgImxlYWYgYW5kIGxlYWYtbGlzdCIgdG8gdGhhdCBzZW50ZW5jZS4NCj4gDQo+ID4NCj4gPj4g ICAgICAtIENhbiBhbiBhY3Rpb24gZGVmaW5lZCBvbiBhIGxpc3QgYmUgYXBwbGllZCB0byB0aGUg d2hvbGUgbGlzdD8NCj4gPg0KPiA+IE5vLg0KPiA+DQo+ID4gKEl0IGlzIGluIGdlbmVyYWwgSU1P IHVuZm9ydHVuYXRlIHRoYXQgdGhlcmUgaXMgbm8gd2F5IHRvIG1hbmlwdWxhdGUNCj4gPiB0aGUg d2hvbGUgbGlzdC4pDQo+ID4NCj4gPj4gKioqKiBTZWMuIDcuMjEuMw0KPiA+PiAgICAgIC0gTWF5 YmUgdGhpcyBzZWN0aW9uIHNob3VsZCBhbHNvIGV4cGxhaW4gdGhhdCBkZXNjcmlwdGlvbnMgYXJl IGFuDQo+ID4+ICAgICAgICBpbnRlZ3JhbCBwYXJ0IG9mIHRoZSBkYXRhIG1vZGVsIGFuZCBtYXkg c3BlY2lmeSwgZS5nLiwgc2VtYW50aWMNCj4gPj4gICAgICAgIGNvbnN0cmFpbnRzIHRoYXQgY2Fu bm90IGJlIGV4cHJlc3NlZCBmb3JtYWxseS4NCj4gPg0KPiA+IENhbiB5b3Ugc3VnZ2VzdCBzb21l IHRleHQ/ICAoSSBhbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQgd2hhdCB5b3UgdGhpbmsNCj4gPiBp cyBuZWVkZWQgdG8gZXhwbGFpbi4uLikNCj4gDQo+IFVubGlrZSBjb21tZW50cyBpbiBwcm9ncmFt bWluZyBsYW5ndWFnZSwgZGVzY3JpcHRpb25zIG1heSBjb250cmlidXRlIHRvDQo+IHRoZSBkYXRh IG1vZGVsIHNwZWNpZmljYXRpb24uIEZvciBleGFtcGxlLCBhIGRlc2NyaXB0aW9uIGNhbiBzdGF0 ZSBhDQo+IHNlbWFudGljIGNvbnN0cmFpbnQgdGhhdCBjYW5ub3QgYmUgZXhwcmVzc2VkIGZvcm1h bGx5IHVzaW5nIGEgIm11c3QiDQo+IHN0YXRlbWVudCwgb3IgaXQgY2FuIHNwZWNpZnkgYSBkeW5h bWljIGRlZmF1bHQgdmFsdWUgZm9yIGEgbGVhZiBub2RlLiANCg0KWWVzLCB0aGV5IGRlc2NyaWJl IHRoZSBiZWhhdmlvciBvZiB0aGUgbm9kZS4NCg0KPiA+PiAqKioqIFNlYy4gOS4xMC4yDQo+ID4+ ICAgICAgLSBzL3N1cHBvcnRlZCBieSB0aGUgc2VydmVyL2ltcGxlbWVudGVkIGJ5IHRoZSBzZXJ2 ZXIvDQo+ID4NCj4gPiBJIHRoaW5rIHRoZXNlIHdvcmRzIG1lYW4gdGhlIHNhbWUgdGhpbmcuICBG b3IgZXhhbXBsZSwgd2UgaGF2ZSAoZm9yDQo+IA0KPiBTZWMuIDUuNi40IHVzZXMgc3RyaWN0bHkg ImltcGxlbWVudCIuIEl0IG11c3QgYmUgY2xlYXIgdGhhdCBpZGVudGl0aWVzDQo+IGRlZmluZWQg aW4gbW9kdWxlcyB0aGF0IGFyZSBvbmx5IGltcG9ydGVkIGZvciBncm91cGluZ3MvdHlwZWRlZnMg ZG9uJ3QgYXBwbHkuIA0KDQpPay4NCg0KPiA+PiAqKioqIFNlYy4gOS4xMC4zDQo+ID4+ICAgICAg VGhlIGxhc3QgcGFyYWdyYXBoIHNob3VsZCBwcm9iYWJseSBiZSByZXBsYWNlZCB3aXRoIGFuIGFk dmljZSB0aGF0DQo+ID4+ICAgICAgaWRlbnRpdHlyZWYgdmFsdWVzIG9yIG5vZGVzZXRzIHNob3Vs ZCBuZXZlciBhcHBlYXIgYXMgYmFyZQ0KPiA+PiAgICAgIHN0cmluZ3MgaW4gWFBhdGggZXhwcmVz c2lvbnMsIGFuZCBmdW5jdGlvbnMgZGVyaXZlZC1mcm9tKCkgb3INCj4gPj4gICAgICBkZXJpdmVk LWZyb20tb3Itc2VsZigpIHNob3VsZCBiZSB1c2VkIGluc3RlYWQuDQo+ID4NCj4gPiBJIHRoaW5r IHRoZSBzdHJpbmcgdmFsdWUgbmVlZHMgdG8gYmUgZGVmaW5lZC4NCj4gDQo+IE9LLCBidXQgc3Rp bGwgc29tZSB0ZXh0IGxpa2UgdGhpcyBjb3VsZCBoZWxwOiAiSW4gZ2VuZXJhbCwgZXF1YWxpdHkN Cj4gdGVzdHMgaW52b2x2aW5nIGlkZW50aXR5cmVmIG5vZGVzIHNob3VsZCBiZSBhdm9pZGVkIC0g WFBhdGggZnVuY3Rpb25zDQo+IGRlcml2ZWQtZnJvbSgpIG9yIGRlcml2ZWQtZnJvbS1vci1zZWxm KCkgKFNlY3Rpb24gMTAuNCkgc2hvdWxkIGJlIHVzZWQNCj4gaW5zdGVhZC4iDQoNCkkgc3RpbGwg dGhpbmsgdGhpcyB0ZXh0IGRvZXNuJ3QgYmVsb25nIGhlcmUuICBUaGlzIGlzIGEgYmVzdCBwcmFj dGlzZQ0KaXNzdWUuDQoNCj4gPj4gICAgICBFeGFtcGxlIGluDQo+ID4+ICAgICAgc2VjLiA5LjEw LjUgc2hvdWxkIGJlIGNoYW5nZWQgdG8gdXNlIGRlcml2ZWQtZnJvbS1vci1zZWxmKCkuDQo+ID4N Cj4gPiBJIHRoaW5rIGl0IHJlYXNvbmFibGUgdG8gZXhhbXBsaWZ5IHRoZSBzdHJpbmcgdmFsdWUg b2YgYW4gaWRlbnRpdHkuDQo+ID4gSG93ZXZlciwgSSBhZ3JlZSB0aGF0IHdlIHNob3VsZCBhZGQg YWR2aWNlIGFib3V0IHVzaW5nDQo+ID4gZGVyaXZlZC1mcm9tLW9yLXNlbGYoKSwgYnV0IEkgdGhp bmsgdGhhdCBzaG91bGQgYmUgZG9uZSBpbiA2MDg3YmlzLg0KPiA+DQo+ID4+ICoqKiogU2VjLiAx MC4zLjENCj4gPj4gICAgICAtIFRoZSBkb2N1bWVudCBvcmRlciBpcyB1bmRlZmluZWQgaW4gYSBk YXRhIHRyZWUgKGFsc28gaW4NCj4gPj4gICAgICAgIHNlYy4gMTAuNC4xIGFuZCAxMC40LjIpLg0K PiA+DQo+ID4gQWJvdmUgKGZvciA2LjQpIHlvdSBzdWdnZXN0ZWQgdGhhdCB0aGUgZG9jdW1lbnQg b3JkZXIgaXMNCj4gPiBpbXBsZW1lbnRhdGlvbi1zcGVjaWZpYy4NCj4gDQo+IEJ1dCB0aGF0IG1l YW5zIGRpZmZlcmVudCBpbXBsZW1lbnRhdGlvbnMgbWF5IGdpdmUgZGlmZmVyZW50IHJlc3VsdHMu IA0KDQpZZXMuDQoNCj4gPj4gICAgICAtIEkgdGhpbmsgZGVyZWYoKSBjb3VsZCByZXR1cm4gbm9u LWVtcHR5IG5vZGVzZXQgb25seSBmb3INCj4gPj4gICAgICAgIGluc3RhbmNlLWlkZW50aWZpZXJz IGJlY2F1c2UgZm9yIGxlYWZyZWYgaXQncyBub3QgbmVlZGVkLg0KPiA+DQo+ID4gT2suLi4/ICBE byB5b3UgaGF2ZSBhbnkgZWRpdHMgaW4gbWluZD8NCj4gDQo+IFJlbW92ZSB0aGUgdGhpcmQgcGFy YWdyYXBoLiBVbmxpa2UgaW5zdGFuY2UtaWRlbnRpZmllciwgYSBsZWFmcmVmDQo+ICppbnN0YW5j ZSogZG9lc24ndCByZWZlciB0byBhbnkgbm9kZXMuDQoNCk9rLCBJIHNlZSwgSSBtaXMtcmVhZCB5 b3VyIG9yaWdpbmFsIGNvbW1lbnQuDQoNCldlIGhhdmUgaGFkIGRlcmVmKCkgaW1wbGVtZW50ZWQg Zm9yIHNldmVyYWwgeWVhcnMsIGFuZCBpdCBpcyBtb3N0bHkNCnVzZWQgZm9yIGxlYWZyZWZzLiAg SSByZWFsbHkgdGhpbmsgd2Ugc2hvdWxkIGtlZXAgaXQgYWxzbyBmb3INCmxlYWZyZWZzLg0KDQoN Ci9tYXJ0aW4NCg== From nobody Wed Aug 26 06:09:49 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B257C1A89B9; Wed, 26 Aug 2015 06:09:48 -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 f8abarrYiiV8; Wed, 26 Aug 2015 06:09:47 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E20881A8946; Wed, 26 Aug 2015 06:09:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3142; q=dns/txt; s=iport; t=1440594587; x=1441804187; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=TGdtS5vwdSq74FLlmaYv7/L1+sJDC9IfkUM6Mof6Lis=; b=lfcgk8X6uCjPHpM6XxGW67PPWVdRZJps7D2BE7oh8OpAJNIulEFjIurH jPnbgkcMShsfyH2tWZ+6lH08BBeSA+yqqVZjc+NFvNY+JM/Tyl8v/JGFt qiZbEWQeA5cX600vGArA8BY0nRJiMQTybV8Oy8SMe4NNJu+4rKCtQljRs k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ApBQD/ud1V/51dJa1dgxuBPQaDHcI8AhyBHDwQAQEBAQEBAYEKhCQBAQQjEUUQAgEIDgIIAgImAgICMBUQAgQBDQWILrNYlHsBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSKKOYRXMweCaYFDAQSVNwGHcYJPgjGBShWEHZB1g2omg35xgUiBBAEBAQ X-IronPort-AV: E=Sophos;i="5.17,416,1437436800"; d="scan'208";a="182098054" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-4.cisco.com with ESMTP; 26 Aug 2015 13:09:46 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t7QD9kCB006901 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 26 Aug 2015 13:09:46 GMT Received: from xch-aln-011.cisco.com (173.36.7.21) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 26 Aug 2015 08:09:45 -0500 Received: from xhc-aln-x06.cisco.com (173.36.12.80) by xch-aln-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Wed, 26 Aug 2015 08:09:45 -0500 Received: from xmb-aln-x06.cisco.com ([169.254.1.223]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0248.002; Wed, 26 Aug 2015 08:09:45 -0500 From: "Acee Lindem (acee)" To: Martin Bjorklund , "tnadeau@lucidvision.com" Thread-Topic: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00 Thread-Index: AQHQ2hI5G+RtR4J5pkqypvooyXOij54S3w4AgACDKQCAARvMgIAAXcaAgAkYyICAAD9QgP//73uAgABPhQCAABNggIAACX0A///NzIA= Date: Wed, 26 Aug 2015 13:09:44 +0000 Message-ID: References: <20150826.122600.1110046163132211535.mbj@tail-f.com> <19CCF9F5-87F1-4C41-8151-18AD36D98CE6@lucidvision.com> <20150826.140918.2163222167742824482.mbj@tail-f.com> In-Reply-To: <20150826.140918.2163222167742824482.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.37.102.29] Content-Type: text/plain; charset="utf-8" Content-ID: <7145A1B6A60D3E41A557D06060F4F652@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" , "draft-rtgyangdt-rtgwg-device-model@ietf.org" , "rtgwg@ietf.org" Subject: Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 13:09:48 -0000 DQoNCk9uIDgvMjYvMTUsIDg6MDkgQU0sICJNYXJ0aW4gQmpvcmtsdW5kIiA8bWJqQHRhaWwtZi5j b20+IHdyb3RlOg0KDQo+TmFkZWF1IFRob21hcyA8dG5hZGVhdUBsdWNpZHZpc2lvbi5jb20+IHdy b3RlOg0KPj4gDQo+PiA+IE9uIEF1ZyAyNiwgMjAxNTo2OjI2IEFNLCBhdCA2OjI2IEFNLCBNYXJ0 aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4NCj4+ID4gd3JvdGU6DQo+PiA+IA0KPj4gPiAi QWNlZSBMaW5kZW0gKGFjZWUpIiA8YWNlZUBjaXNjby5jb20+IHdyb3RlOg0KPj4gPj4gDQo+PiA+ PiANCj4+ID4+IE9uIDgvMjYvMTUsIDI6NDAgQU0sICJKdWVyZ2VuIFNjaG9lbndhZWxkZXIiDQo+ PiA+PiA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPiB3cm90ZToNCj4+ID4+ IA0KPj4gPj4+IE9uIFR1ZSwgQXVnIDI1LCAyMDE1IGF0IDEwOjUzOjU1UE0gLTA0MDAsIExvdSBC ZXJnZXIgd3JvdGU6DQo+PiA+Pj4gDQo+PiA+Pj4+PiBIb3BlZnVsbHksIGEgZGVjaXNpb24gdG8g Y2hhbmdlIGFsbCBleGlzdGluZyBtb2RlbHMgKGluY2x1ZGluZw0KPj52ZW5kb3INCj4+ID4+Pj4+ IG1vZGVscyEpIHdpbGwgYmUgYmFzZWQgb24gc29tZXRoaW5nIG1vcmUgdGVjaG5pY2FsIHRoYW4g dGhlIGZhY3QNCj4+dGhhdA0KPj4gPj4+Pj4gYSBncm91cCBvZiBwZW9wbGUgInJlYWxseSBsaWtl IGl0IiBzb21lIG90aGVyIHdheS4NCj4+ID4+Pj4gDQo+PiA+Pj4+IEknbSBlcXVhbGx5IHVuc3Vy ZSB0aGF0IGhhdmluZyBhbiBhcmd1bWVudCBvZiAiSSBnb3QgdGhlcmUgZmlyc3QiDQo+PmlzIGEN Cj4+ID4+Pj4gY29tcGVsbGluZyBhcmd1bWVudCBnaXZlbiB0aGUgbnVtYmVyIG9mIGZvbGtzIChp bmNsdWRpbmcgdmVuZG9ycykNCj4+d2hvDQo+PiA+Pj4+IGhhdmUgc3RhdGVkIHdpbGxpbmduZXNz IChvciBldmVuIHN1cHBvcnQpIGZvciBjaGFuZ2UuICBJIHRoaW5rDQo+PmhhdmluZw0KPj4gPj4+ PiBhDQo+PiA+Pj4+IG1ham9yIGNsYXNzIG9mIHVzZXJzIHN0YW5kIHVwIGFuZCBzYXkgdGhpcyBp cyBpbXBvcnRhbnQgc2hvdWxkDQo+Pmdhcm5lcg0KPj4gPj4+PiBzb21lIG5vdGljZS4NCj4+ID4+ PiANCj4+ID4+PiBQbGVhc2Uga2VlcCBpbiBtaW5kIHRoYXQgd2UgYXJlIHRhbGtpbmcgYWJvdXQg c2V2ZXJhbCBwdWJsaXNoZWQNCj4+ID4+PiBwcm9wb3NlZCBzdGFuZGFyZHMgdGhhdCBoYXZlIGJl ZW4gaW1wbGVtZW50ZWQgYW5kIGRlcGxveWVkLiBJIHRoaW5rDQo+PiA+Pj4gdGhlcmUgbXVzdCBi ZSBjb252aW5jaW5nIHRlY2huaWNhbCByZWFzb25zIHRvIGRlY2xhcmUgdGhlbSBicm9rZW4NCj4+ YW5kDQo+PiA+Pj4gdG8gcmVkbyB0aGVtLg0KPj4gPj4gDQo+PiA+PiBPdGhlciB0aGFuIGFkZGlu ZyAvZGV2aWNlIGF0IHRoZSB0b3AsIHdlIGFyZSBub3Qgb2Jzb2xldGluZyBSRkMNCj4+ID4+IDcy MjMuDQo+PiA+IA0KPj4gPiBUaGlzIGRvZXNuJ3QgbWFrZSBzZW5zZS4gIFRoZSBZQU5HIG1vZGVs IGlzIHRoZSBjb250cmFjdC4gIFlvdSBhcmUNCj4+ID4gcHJvcG9zaW5nIGNoYW5naW5nIHRoZSBj b250cmFjdC4gIFRoZSBmYWN0IGlzIHRoYXQgeW91IHdpbGwgYmUNCj4+ID4gb2Jzb2xldGluZyA3 MjIzIChhbmQgdGhlIG90aGVyIFJGQ3MpLiAgRXhpc3RpbmcgZGV2aWNlcyBhbmQNCj4+ID4gYXBw bGljYXRpb25zIHdpbGwgaGF2ZSB0byBjaGFuZ2UgaW4gb3JkZXIgdG8gaGFuZGxlIHRoaXMgbmV3 IHRvcC1sZXZlbA0KPj4gPiBub2RlICh3aGljaCB3aWxsIGJlIGluIHNvbWUgb3RoZXIgbmFtZXNw YWNlIEkgcHJlc3VtZSwgdW5sZXNzIHlvdXINCj4+ID4gcHJvcG9zYWwgaXMgb25lIGdpZ2FudGlj IG1vbm9saXRoaWMgbW9kZWwpLg0KPj4gPiANCj4+ID4gDQo+PiA+IC9tYXJ0aW4NCj4+IA0KPj4g CUFnYWluIEkgd2lsbCBhc2s6IHdoeSBpcyB0aGlzIGJhZD8NCj4NCj5NeSBwb2ludCBhYm92ZSB3 YXMgaW4gcmVwbHkgdG8gdGhlIHN0YXRlbWVudCB0aGF0ICJ3ZSBhcmUgbm90DQo+b2Jzb2xldGlu ZyBSRkMgNzIyMyIgW2JlY2F1c2UgdGhlIGNoYW5nZSBpcyBzbyBzbWFsbD9dIC0geW91IHdvdWxk IGluDQo+ZmFjdCBiZSBvYnNvbGV0aW5nIHRoZSBtb2RlbCBpbiA3MjIzLg0KDQpUaGVyZSBoYXZl IGJlZW4gb3RoZXIgbWVjaGFuaXNtcyBkaXNjdXNzZWQgdG8gcmVsb2NhdGUgWUFORyBtb2RlbHMu DQpQZXJoYXBzLCBvbmUgb2YgdGhlc2UgY291bGQgYmUgZW1wbG95ZWQgaW4gbGlldSBvZiBvYnNv bGV0aW5nIHRoZSBleGlzdGluZw0KbW9kZWxzLiANCg0KVGhhbmtzLA0KQWNlZSANCg0KDQo+DQo+ DQo+L21hcnRpbg0KDQo= From nobody Wed Aug 26 06:18:10 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43D7A1A1BED; Wed, 26 Aug 2015 06:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ff0nSJWkivsw; Wed, 26 Aug 2015 06:18:05 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2DBC1A1EF4; Wed, 26 Aug 2015 06:17:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1440595012; bh=DhoNZHdawI2vMqYTrpQHSJbJEknbEnmQsyGHJyohnGs=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=Sy87ieNQZNHx/+M7pyzjGHByotoQyEz247ErWc1KqxwqL+uAv2psozPu2cbZxiqcW yLnWqcC9JMd7C1J6RSi5CekZHvZ399IkPuFu5ImMR6WckSTKZIyAK5oP8mTG8mhXsx yTpph+ssdMzyGt3SX42jOFuUFOtsDKTwTGrmq260= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Nadeau Thomas In-Reply-To: <20150826.135823.2123307386758409523.mbj@tail-f.com> Date: Wed, 26 Aug 2015 09:17:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7E4038FA-F930-448A-9C65-C82C39E4825B@lucidvision.com> References: <20150826064030.GB84416@elstar.local> <14f696bc290.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <194D29DB-A026-481F-8C4C-9201080829A5@lucidvision.com> <20150826.135823.2123307386758409523.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.2104) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-ShareWhite: 50.255.148.181 X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=9 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181 X-IP-stats: Notspam Incoming Last 0, First 103, in=1150, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: Cc: netmod@ietf.org, draft-rtgyangdt-rtgwg-device-model@ietf.org, rtgwg@ietf.org Subject: Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 13:18:09 -0000 > On Aug 26, 2015:7:58 AM, at 7:58 AM, Martin Bjorklund = wrote: >=20 > Nadeau Thomas wrote: >> [Speaking for myself] >>=20 >> Is the resistance to this proposal because of the actual changes = to >> structure, or is it a resistance to churn/change? >=20 > The former. IMO this is technically not a good proposal, as I have > tried to explain several times. >=20 >> And if we solved the >> latter by say relaxing the rules around how we progress models = to PS, >> would this alleviate the concerns for the former? The meta = question I >> will ask is: is the existing RFC process adequate/sufficient for = us to >> move forward on such a large scale with Yang models at the IETF? >> Other organizations currently iterate on models using certain = revision >> conventions (that are consistent with the rules we put out here) = yet >> produce multiple versions of the same model within the same = year. As >> a matter of fact, multiple versions are allowed to coexist = within a >> single implementation. In stark contrast, the M.O. at the IETF = has >> been to treat Yang models much like we did SNMP MIBs (or any = other >> document here) thereby assuming that once it becomes an RFC, = that it >> is largely set in concrete for many years to come. >=20 > In this specific case the change is cosmetic but has disastrous > effects on other standard modules, other vendor-specific modules, > existing server code and existing client code. I think people expect > IETF standards to be a bit more stable than that. >=20 >=20 > /martin Therein lies the salient part of question I am asking: is this = really=20 the case these days? The operators seem to be providing an answer that = contradicts this age-old assumption. Other projects like ODL are too. Both have = real deployments too - these reference points are not science projects. I = think its fair to bring this specific issue out in the open here to discuss = because its a real issue we need to solve not just here in NETMOD, but at the IETF=20= in general. =E2=80=94Tom From nobody Wed Aug 26 06:19:51 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A02E1A8AF4; Wed, 26 Aug 2015 06:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5soeHASOBg7F; Wed, 26 Aug 2015 06:19:47 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EEAD1AC41D; Wed, 26 Aug 2015 06:19:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1440595118; bh=1uQO1Zi8/Qk7nDb8X7EPkeBAxFhVnEvKyXvYmH0bQvQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=yy6AD7j8EQ3liNOh5msAQ/HavXoTdfP7Rw3yfYANx365uHEiEnYbNE3DyIeoIoa6e 1K35Og+H45qBFjPZ1FTKbrp6q0xshxFAtMIBuFxOGT3EUD5nB4tMVkfTHvTA9H0CNB IXa/RuM7g7JtKjW3+idcO08NOzX+3D0BQtEQKxrU= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Nadeau Thomas In-Reply-To: <20150826.140918.2163222167742824482.mbj@tail-f.com> Date: Wed, 26 Aug 2015 09:19:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150826.122600.1110046163132211535.mbj@tail-f.com> <19CCF9F5-87F1-4C41-8151-18AD36D98CE6@lucidvision.com> <20150826.140918.2163222167742824482.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.2104) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-ShareWhite: 50.255.148.181 X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=10 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181 X-IP-stats: Notspam Incoming Last 0, First 103, in=1151, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: Cc: netmod@ietf.org, draft-rtgyangdt-rtgwg-device-model@ietf.org, rtgwg@ietf.org Subject: Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 13:19:49 -0000 > On Aug 26, 2015:8:09 AM, at 8:09 AM, Martin Bjorklund = wrote: >=20 > Nadeau Thomas wrote: >>=20 >>> On Aug 26, 2015:6:26 AM, at 6:26 AM, Martin Bjorklund = >>> wrote: >>>=20 >>> "Acee Lindem (acee)" wrote: >>>>=20 >>>>=20 >>>> On 8/26/15, 2:40 AM, "Juergen Schoenwaelder" >>>> wrote: >>>>=20 >>>>> On Tue, Aug 25, 2015 at 10:53:55PM -0400, Lou Berger wrote: >>>>>=20 >>>>>>> Hopefully, a decision to change all existing models (including = vendor >>>>>>> models!) will be based on something more technical than the fact = that >>>>>>> a group of people "really like it" some other way. >>>>>>=20 >>>>>> I'm equally unsure that having an argument of "I got there first" = is a >>>>>> compelling argument given the number of folks (including vendors) = who >>>>>> have stated willingness (or even support) for change. I think = having >>>>>> a >>>>>> major class of users stand up and say this is important should = garner >>>>>> some notice. >>>>>=20 >>>>> Please keep in mind that we are talking about several published >>>>> proposed standards that have been implemented and deployed. I = think >>>>> there must be convincing technical reasons to declare them broken = and >>>>> to redo them. >>>>=20 >>>> Other than adding /device at the top, we are not obsoleting RFC >>>> 7223. >>>=20 >>> This doesn't make sense. The YANG model is the contract. You are >>> proposing changing the contract. The fact is that you will be >>> obsoleting 7223 (and the other RFCs). Existing devices and >>> applications will have to change in order to handle this new = top-level >>> node (which will be in some other namespace I presume, unless your >>> proposal is one gigantic monolithic model). >>>=20 >>>=20 >>> /martin >>=20 >> Again I will ask: why is this bad? >=20 > My point above was in reply to the statement that "we are not > obsoleting RFC 7223" [because the change is so small?] - you would in > fact be obsoleting the model in 7223. >=20 >=20 > /martin The flip side to this is that while you evolve the model=20 in 7223, you evolve it rapidly and to conform to the newer model(s). The older model does actually still exist, and if we have a way to refer back to it its not really obsolete; its just an older revision. =E2=80=94Tom =20 From nobody Wed Aug 26 06:34:23 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 653731B29B6 for ; Wed, 26 Aug 2015 06:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 N3KQ6w65SCvV for ; Wed, 26 Aug 2015 06:34:19 -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 B37701ACEAA for ; Wed, 26 Aug 2015 06:34:14 -0700 (PDT) Received: by laba3 with SMTP id a3so119481966lab.1 for ; Wed, 26 Aug 2015 06:34:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=w/7Pp9YhY7VToeQHCl19XUlZzRE9vM3Y5SeO/nSNSZ8=; b=FITsymv05Qyum7RXxCfXpbO/Eq7nISJjzZhhEHYtLAHoWNgmEn2bEllNmvyJzxxC4J xdPc1TEzczAzO1xGDpT3ZO19cQ+tCF+As6ruNljoDTYPeN6NmEacGUdPGiUDZlm3+QZn mYqOrTcwqpa6H/7aaqXABGBZWl/w6zYdPVPXxHtjDo6KRffkg3c4g5BfgbJ/I+N93oQc iOGf4Cbw0eWtcktZwa4MSGr0rcvrN3VJAQ3lQ6qVwK9KawIkrC3EYtN7Z9yplRySM6n5 nPn2LOt5Y6ZCaqHSav8lbzWISaDJM56pcMByLrmtYPoSjuH7c2AykCcGRswg5g8/ho6S gTEw== X-Gm-Message-State: ALoCoQm4pzQK61fUhmx78qOiYB5y+HhFMJosS5EMEfiaV8dTNAKMp3Ucrgr4/o7t4Sdqs7pinKnB MIME-Version: 1.0 X-Received: by 10.112.154.106 with SMTP id vn10mr30814020lbb.38.1440596052202; Wed, 26 Aug 2015 06:34:12 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Wed, 26 Aug 2015 06:34:11 -0700 (PDT) In-Reply-To: <7E4038FA-F930-448A-9C65-C82C39E4825B@lucidvision.com> References: <20150826064030.GB84416@elstar.local> <14f696bc290.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <194D29DB-A026-481F-8C4C-9201080829A5@lucidvision.com> <20150826.135823.2123307386758409523.mbj@tail-f.com> <7E4038FA-F930-448A-9C65-C82C39E4825B@lucidvision.com> Date: Wed, 26 Aug 2015 06:34:11 -0700 Message-ID: From: Andy Bierman To: Nadeau Thomas Content-Type: multipart/alternative; boundary=089e0122af2af4f166051e36e721 Archived-At: Cc: draft-rtgyangdt-rtgwg-device-model@ietf.org, "netmod@ietf.org" , Routing WG Subject: Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 13:34:22 -0000 --089e0122af2af4f166051e36e721 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Aug 26, 2015 at 6:17 AM, Nadeau Thomas wrote: > > > On Aug 26, 2015:7:58 AM, at 7:58 AM, Martin Bjorklund > wrote: > > > > Nadeau Thomas wrote: > >> [Speaking for myself] > >> > >> Is the resistance to this proposal because of the actual changes = to > >> structure, or is it a resistance to churn/change? > > > > The former. IMO this is technically not a good proposal, as I have > > tried to explain several times. > > > >> And if we solved the > >> latter by say relaxing the rules around how we progress models to > PS, > >> would this alleviate the concerns for the former? The meta > question I > >> will ask is: is the existing RFC process adequate/sufficient for > us to > >> move forward on such a large scale with Yang models at the IETF? > >> Other organizations currently iterate on models using certain > revision > >> conventions (that are consistent with the rules we put out here) > yet > >> produce multiple versions of the same model within the same year. > As > >> a matter of fact, multiple versions are allowed to coexist within= a > >> single implementation. In stark contrast, the M.O. at the IETF h= as > >> been to treat Yang models much like we did SNMP MIBs (or any othe= r > >> document here) thereby assuming that once it becomes an RFC, that > it > >> is largely set in concrete for many years to come. > > > > In this specific case the change is cosmetic but has disastrous > > effects on other standard modules, other vendor-specific modules, > > existing server code and existing client code. I think people expect > > IETF standards to be a bit more stable than that. > > > > > > /martin > > Therein lies the salient part of question I am asking: is this > really > the case these days? The operators seem to be providing an answer that > contradicts > this age-old assumption. Other projects like ODL are too. Both have real > deployments too - these reference points are not science projects. I thin= k > its > fair to bring this specific issue out in the open here to discuss because > its > a real issue we need to solve not just here in NETMOD, but at the IETF > in general. > > YANG modules are not relocatable. The issue should be really clear to anybody who has to support product in the field. If you make this change, the existing products stop working. It doesn't matter if you move the YANG objects a little or a lot. Since the proposed change ( / to /device ) adds no value whatsoever to a programmatic interface, the product in the field will be broken for no real reason. If vendors are expected to move all their YANG objects into some uber-tree that the IETF owns, then the disruption is total. I agree the NETMOD WG should think carefully about this change before agreeing to it, but it is the equipment vendors who will pay for it. > =E2=80=94Tom > > Andy > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --089e0122af2af4f166051e36e721 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Aug 26, 2015 at 6:17 AM, Nadeau Thomas <tnadeau@lucidvis= ion.com> wrote:

> On Aug 26, 2015:7:58 AM, at 7:58 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> Nadeau Thomas <tnadeau@l= ucidvision.com> wrote:
>>=C2=A0 =C2=A0 =C2=A0 [Speaking for myself]
>>
>>=C2=A0 =C2=A0 =C2=A0 Is the resistance to this proposal because of = the actual changes to
>>=C2=A0 =C2=A0 =C2=A0 structure, or is it a resistance to churn/chan= ge?
>
> The former.=C2=A0 IMO this is technically not a good proposal, as I ha= ve
> tried to explain several times.
>
>>=C2=A0 =C2=A0 =C2=A0 And if we solved the
>>=C2=A0 =C2=A0 =C2=A0 latter by say relaxing the rules around how we= progress models to PS,
>>=C2=A0 =C2=A0 =C2=A0 would this alleviate the concerns for the form= er?=C2=A0 The meta question I
>>=C2=A0 =C2=A0 =C2=A0 will ask is: is the existing RFC process adequ= ate/sufficient for us to
>>=C2=A0 =C2=A0 =C2=A0 move forward on such a large scale with Yang m= odels at the IETF?
>>=C2=A0 =C2=A0 =C2=A0 Other organizations currently iterate on model= s using certain revision
>>=C2=A0 =C2=A0 =C2=A0 conventions (that are consistent with the rule= s we put out here) yet
>>=C2=A0 =C2=A0 =C2=A0 produce multiple versions of the same model wi= thin the same year.=C2=A0 As
>>=C2=A0 =C2=A0 =C2=A0 a matter of fact, multiple versions are allowe= d to coexist within a
>>=C2=A0 =C2=A0 =C2=A0 single implementation.=C2=A0 In stark contrast= , the M.O. at the IETF has
>>=C2=A0 =C2=A0 =C2=A0 been to treat Yang models much like we did SNM= P MIBs (or any other
>>=C2=A0 =C2=A0 =C2=A0 document here) thereby assuming that once it b= ecomes an RFC, that it
>>=C2=A0 =C2=A0 =C2=A0 is largely set in concrete for many years to c= ome.
>
> In this specific case the change is cosmetic but has disastrous
> effects on other standard modules, other vendor-specific modules,
> existing server code and existing client code.=C2=A0 I think people ex= pect
> IETF standards to be a bit more stable than that.
>
>
> /martin

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Therein lies the salient part of question I am = asking: is this really
the case these days?=C2=A0 The operators seem to be providing an answer tha= t contradicts
this age-old assumption. Other projects like ODL are too.=C2=A0 Both have r= eal
deployments too - these reference points are not science projects. I think = its
fair to bring this specific issue out in the open here to discuss because i= ts
a real issue we need to solve not just here in NETMOD, but at the IETF
in general.



YANG modules are not re= locatable.
The issue should be really clear to anybody who has to= support product
in the field.=C2=A0 If you make this change, the= existing products stop working.
It doesn't matter if you mov= e the YANG objects a little or a lot.

Since the pr= oposed change ( / to /device ) adds no value whatsoever
to a prog= rammatic interface, the product in the field will be broken
for n= o real reason.

If vendors are expected to move all= their YANG objects into some
uber-tree that the IETF owns, then = the disruption is total.

I agree the NETMOD WG sho= uld think carefully about this change
before agreeing to it, but = it is the equipment vendors who will
pay for it.

=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=94Tom


Andy
=C2=A0


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

--089e0122af2af4f166051e36e721-- From nobody Wed Aug 26 06:35:17 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB491B2A2D; Wed, 26 Aug 2015 06:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FK0vQEPQ_HdZ; Wed, 26 Aug 2015 06:35:08 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED1501B2A53; Wed, 26 Aug 2015 06:34:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1440596034; bh=zeW5gCJMTX9U3KgUoXUXplftEzfZ33BGJvHh08KCKxU=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=l7taB+kjeHaIGE0+ogZXhMjALqIRQnf7S3cmPyOWw+rDONL7y1btbyOGASBSMjH+v BheQZ1uniyXlxdJcOfFxDPSM6yQVpurXNu7Z1LV/AeNldUe0hc9lMGttYbKyKm+Z5x W1sMFK4fsvawLy2IDUr3OZI9nVLGaul8z0jVQJJM= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Nadeau Thomas In-Reply-To: Date: Wed, 26 Aug 2015 09:34:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150826.122600.1110046163132211535.mbj@tail-f.com> <19CCF9F5-87F1-4C41-8151-18AD36D98CE6@lucidvision.com> <20150826.140918.2163222167742824482.mbj@tail-f.com> To: "Acee Lindem (acee)" X-Mailer: Apple Mail (2.2104) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-ShareWhite: 50.255.148.181 X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=12 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181 X-IP-stats: Notspam Incoming Last 0, First 103, in=1153, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: Cc: "netmod@ietf.org" , "draft-rtgyangdt-rtgwg-device-model@ietf.org" , "rtgwg@ietf.org" Subject: Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 13:35:14 -0000 > On Aug 26, 2015:9:09 AM, at 9:09 AM, Acee Lindem (acee) = wrote: >=20 >=20 >=20 > On 8/26/15, 8:09 AM, "Martin Bjorklund" wrote: >=20 >> Nadeau Thomas wrote: >>>=20 >>>> On Aug 26, 2015:6:26 AM, at 6:26 AM, Martin Bjorklund = >>>> wrote: >>>>=20 >>>> "Acee Lindem (acee)" wrote: >>>>>=20 >>>>>=20 >>>>> On 8/26/15, 2:40 AM, "Juergen Schoenwaelder" >>>>> wrote: >>>>>=20 >>>>>> On Tue, Aug 25, 2015 at 10:53:55PM -0400, Lou Berger wrote: >>>>>>=20 >>>>>>>> Hopefully, a decision to change all existing models (including >>> vendor >>>>>>>> models!) will be based on something more technical than the = fact >>> that >>>>>>>> a group of people "really like it" some other way. >>>>>>>=20 >>>>>>> I'm equally unsure that having an argument of "I got there = first" >>> is a >>>>>>> compelling argument given the number of folks (including = vendors) >>> who >>>>>>> have stated willingness (or even support) for change. I think >>> having >>>>>>> a >>>>>>> major class of users stand up and say this is important should >>> garner >>>>>>> some notice. >>>>>>=20 >>>>>> Please keep in mind that we are talking about several published >>>>>> proposed standards that have been implemented and deployed. I = think >>>>>> there must be convincing technical reasons to declare them broken >>> and >>>>>> to redo them. >>>>>=20 >>>>> Other than adding /device at the top, we are not obsoleting RFC >>>>> 7223. >>>>=20 >>>> This doesn't make sense. The YANG model is the contract. You are >>>> proposing changing the contract. The fact is that you will be >>>> obsoleting 7223 (and the other RFCs). Existing devices and >>>> applications will have to change in order to handle this new = top-level >>>> node (which will be in some other namespace I presume, unless your >>>> proposal is one gigantic monolithic model). >>>>=20 >>>>=20 >>>> /martin >>>=20 >>> Again I will ask: why is this bad? >>=20 >> My point above was in reply to the statement that "we are not >> obsoleting RFC 7223" [because the change is so small?] - you would in >> fact be obsoleting the model in 7223. >=20 > There have been other mechanisms discussed to relocate YANG models. > Perhaps, one of these could be employed in lieu of obsoleting the = existing > models.=20 >=20 > Thanks, > Acee=20 This is exactly what I want to get on the table. If we can = agree on a mechanism/s to do relocate modules, then this might alleviate the resistance to evolve models. The current issue aside, if you step back = and look=20 at the wider IETF situation around all the Yang models being created and are RFCs, and the dependency graph that is created. You can then=20 imagine a time after that point when others come along that evolve=20 parts or entire modules. We currently refer to this as =E2=80=9Cobsoletin= g=E2=80=9D all of the modules that it depends on, which is a very big problem using the current RFC process. Not only does it require a revision of all = those RFCs (due to obsoleting the previous ones) - and thus all the = procedural/management overhead that will incur - but the time lag from start to finish. And this might happen for any new module. This is not scaleable going = forward. =E2=80=94Tom >=20 >=20 >>=20 >>=20 >> /martin >=20 From nobody Wed Aug 26 06:54:50 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67B7F1B2C5F for ; Wed, 26 Aug 2015 06:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtcS8UsZ1O9R for ; Wed, 26 Aug 2015 06:54:42 -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 626841B2A58 for ; Wed, 26 Aug 2015 06:54:41 -0700 (PDT) Received: by labia3 with SMTP id ia3so55324631lab.3 for ; Wed, 26 Aug 2015 06:54: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=wSQBBqsbXBM9PGUi4J1Gh2cUSCEo4MTevJZIt3MWIFw=; b=mJpdonLsxaIkFOnXUN/ZxjyfJSa4sstgXf5d41V1NIfgLgBtf6lMI2rAlefQebegXi 576sZNi9KiB8G3hIRB7mFdqix2ojMDGnzkvAouyX+ZlUI1VVa0v3eY55H+s+QjsYSt7K izpR38TpcxUVnpKgK/MNBAqU4bGhmF9tFuMay2Tx/nptw2ZJ4scy5XTDejqaVqtI10Z9 fkJE0I42B+VYMOiqlxE/+CAkRh9HlwJw/+olyagWgAmk0AdWgNfBQO0bc2j66ZBk/AH4 JRzb7GHst2f4mkjwZFbdk/748Lk4IdKSnOlVvMk19EzDgk0/EPZgwMooDWhZA9zUKyl+ 0U0w== X-Gm-Message-State: ALoCoQnvYTJH0M7qN8HRCpm7K9tjG1ggZyT+Mnz8z8DayBz7ACRO+1mfP6XNfYwKd9WqboCf3ODv MIME-Version: 1.0 X-Received: by 10.112.85.3 with SMTP id d3mr30654632lbz.33.1440597279803; Wed, 26 Aug 2015 06:54:39 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Wed, 26 Aug 2015 06:54:39 -0700 (PDT) In-Reply-To: References: <20150826.122600.1110046163132211535.mbj@tail-f.com> <19CCF9F5-87F1-4C41-8151-18AD36D98CE6@lucidvision.com> <20150826.140918.2163222167742824482.mbj@tail-f.com> Date: Wed, 26 Aug 2015 06:54:39 -0700 Message-ID: From: Andy Bierman To: Nadeau Thomas Content-Type: multipart/alternative; boundary=001a1134946c20a483051e373159 Archived-At: Cc: "draft-rtgyangdt-rtgwg-device-model@ietf.org" , "netmod@ietf.org" , "rtgwg@ietf.org" Subject: Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 13:54:49 -0000 --001a1134946c20a483051e373159 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Aug 26, 2015 at 6:34 AM, Nadeau Thomas wrote: > > > On Aug 26, 2015:9:09 AM, at 9:09 AM, Acee Lindem (acee) > wrote: > > > > > > > > On 8/26/15, 8:09 AM, "Martin Bjorklund" wrote: > > > >> Nadeau Thomas wrote: > >>> > >>>> On Aug 26, 2015:6:26 AM, at 6:26 AM, Martin Bjorklund > > >>>> wrote: > >>>> > >>>> "Acee Lindem (acee)" wrote: > >>>>> > >>>>> > >>>>> On 8/26/15, 2:40 AM, "Juergen Schoenwaelder" > >>>>> wrote: > >>>>> > >>>>>> On Tue, Aug 25, 2015 at 10:53:55PM -0400, Lou Berger wrote: > >>>>>> > >>>>>>>> Hopefully, a decision to change all existing models (including > >>> vendor > >>>>>>>> models!) will be based on something more technical than the fact > >>> that > >>>>>>>> a group of people "really like it" some other way. > >>>>>>> > >>>>>>> I'm equally unsure that having an argument of "I got there first" > >>> is a > >>>>>>> compelling argument given the number of folks (including vendors) > >>> who > >>>>>>> have stated willingness (or even support) for change. I think > >>> having > >>>>>>> a > >>>>>>> major class of users stand up and say this is important should > >>> garner > >>>>>>> some notice. > >>>>>> > >>>>>> Please keep in mind that we are talking about several published > >>>>>> proposed standards that have been implemented and deployed. I thin= k > >>>>>> there must be convincing technical reasons to declare them broken > >>> and > >>>>>> to redo them. > >>>>> > >>>>> Other than adding /device at the top, we are not obsoleting RFC > >>>>> 7223. > >>>> > This shows a rather diminished understanding of how YANG works. YANG defines data at a specified location /some/path/from/root. Protocols like HTTP can deal with moved resources (e.g., 301). > >>>> This doesn't make sense. The YANG model is the contract. You are > >>>> proposing changing the contract. The fact is that you will be > >>>> obsoleting 7223 (and the other RFCs). Existing devices and > >>>> applications will have to change in order to handle this new top-lev= el > >>>> node (which will be in some other namespace I presume, unless your > >>>> proposal is one gigantic monolithic model). > >>>> > >>>> > >>>> /martin > >>> > >>> Again I will ask: why is this bad? > >> > >> My point above was in reply to the statement that "we are not > >> obsoleting RFC 7223" [because the change is so small?] - you would in > >> fact be obsoleting the model in 7223. > > > > There have been other mechanisms discussed to relocate YANG models. > > Perhaps, one of these could be employed in lieu of obsoleting the > existing > > models. > > > > Thanks, > > Acee > > This is exactly what I want to get on the table. If we can agree > on a mechanism/s to do relocate modules, then this might alleviate the > resistance to evolve models. The current issue aside, if you step back an= d > look > at the wider IETF situation around all the Yang models being created and > are RFCs, and the dependency graph that is created. You can then > imagine a time after that point when others come along that evolve > parts or entire modules. We currently refer to this as =E2=80=9Cobsoleti= ng=E2=80=9D > all of the modules that it depends on, which is a very big problem using > the current RFC process. Not only does it require a revision of all thos= e > RFCs (due to obsoleting the previous ones) - and thus all the > procedural/management > overhead that will incur - but the time lag from start to finish. And > this might happen for any new module. This is not scaleable going forward= . > > So we would just need to retrofit all the clients and servers with complicated code to relocate YANG modules and adjust all the validation tests? Another approach is to not rely so heavily on one giant uber-tree that MUST be correct on the first try and never change. Resource directories and other flexible approaches have been developed for this purpose. > =E2=80=94Tom > > > Andy > > > > > > >> > >> > >> /martin > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a1134946c20a483051e373159 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Aug 26, 2015 at 6:34 AM, Nadeau Thomas <tnadeau@lucidvis= ion.com> wrote:

> On Aug 26, 2015:9:09 AM, at 9:09 AM, Acee Lindem (acee) <acee@cisco.com> wrote:
>
>
>
> On 8/26/15, 8:09 AM, "Martin Bjorklund" <mbj@tail-f.com> wrote:
>
>> Nadeau Thomas <tnade= au@lucidvision.com> wrote:
>>>
>>>> On Aug 26, 2015:6:26 AM, at 6:26 AM, Martin Bjorklund <= mbj@tail-f.com>
>>>> wrote:
>>>>
>>>> "Acee Lindem (acee)" <acee@cisco.com> wrote:
>>>>>
>>>>>
>>>>> On 8/26/15, 2:40 AM, "Juergen Schoenwaelder"=
>>>>> <j.schoenwaelder@jacobs-university.de> wrote:
>>>>>
>>>>>> On Tue, Aug 25, 2015 at 10:53:55PM -0400, Lou Berg= er wrote:
>>>>>>
>>>>>>>> Hopefully, a decision to change all existi= ng models (including
>>> vendor
>>>>>>>> models!) will be based on something more t= echnical than the fact
>>> that
>>>>>>>> a group of people "really like it&quo= t; some other way.
>>>>>>>
>>>>>>> I'm equally unsure that having an argument= of "I got there first"
>>> is a
>>>>>>> compelling argument given the number of folks = (including vendors)
>>> who
>>>>>>> have stated willingness (or even support) for = change.=C2=A0 I think
>>> having
>>>>>>> a
>>>>>>> major class of users stand up and say this is = important should
>>> garner
>>>>>>> some notice.
>>>>>>
>>>>>> Please keep in mind that we are talking about seve= ral published
>>>>>> proposed standards that have been implemented and = deployed. I think
>>>>>> there must be convincing technical reasons to decl= are them broken
>>> and
>>>>>> to redo them.
>>>>>
>>>>> Other than adding /device at the top, we are not obsol= eting RFC
>>>>> 7223.
>>>>



This shows a rather diminished understanding of how YANG works.
YANG defines data at a specified location /some/path/from/root.
Protocols like HTTP can deal with moved resources (e.g., 301).
<= div>

=C2=A0
>>>> This doesn't make sense.=C2=A0 The YANG model is the c= ontract.=C2=A0 You are
>>>> proposing changing the contract.=C2=A0 The fact is that yo= u will be
>>>> obsoleting 7223 (and the other RFCs).=C2=A0 Existing devic= es and
>>>> applications will have to change in order to handle this n= ew top-level
>>>> node (which will be in some other namespace I presume, unl= ess your
>>>> proposal is one gigantic monolithic model).
>>>>
>>>>
>>>> /martin
>>>
>>>=C2=A0 =C2=A0 =C2=A0Again I will ask: why is this bad?
>>
>> My point above was in reply to the statement that "we are not=
>> obsoleting RFC 7223" [because the change is so small?] - you = would in
>> fact be obsoleting the model in 7223.
>
> There have been other mechanisms discussed to relocate YANG models. > Perhaps, one of these could be employed in lieu of obsoleting the exis= ting
> models.
>
> Thanks,
> Acee

=C2=A0 =C2=A0 =C2=A0 =C2=A0 This is exactly what I want to get on the table= .=C2=A0 If we can agree
on a mechanism/s to do relocate modules, then this might alleviate the
resistance to evolve models. The current issue aside, if you step back and = look
at the wider IETF situation around all the Yang models being created and are RFCs, and the dependency graph that is created. You can then
imagine a time after that point when others come along that evolve
parts or entire modules.=C2=A0 We currently refer to this as =E2=80=9Cobsol= eting=E2=80=9D
all of the modules that it depends on, which is a very big problem using the current RFC process.=C2=A0 Not only does it require a revision of all t= hose
RFCs (due to obsoleting the previous ones) - and thus all the procedural/ma= nagement
overhead that will incur - but the time lag from start to finish. And
this might happen for any new module. This is not scaleable going forward.<= br>

So we would just need to retrofit all = the clients and servers with complicated
code to relocate YANG mo= dules and adjust all the validation tests?

Another= approach is to not rely so heavily on one giant uber-tree
that M= UST be correct on the first try and never change.
Resource direct= ories and other flexible approaches have been developed
for this = purpose.

=C2=A0

>
>
>>
>>
>> /martin
>

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

--001a1134946c20a483051e373159-- From nobody Wed Aug 26 07:33:24 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 659DD1AD378 for ; Wed, 26 Aug 2015 07:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k36ziZMAhNWz for ; Wed, 26 Aug 2015 07:33:19 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2E41AD0C8 for ; Wed, 26 Aug 2015 07:33:18 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 4D8B11CC0047; Wed, 26 Aug 2015 16:33:19 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20150826.142939.241315678797135798.mbj@tail-f.com> References: <20150825.130359.1125823029773095202.mbj@tail-f.com> <20150826.142939.241315678797135798.mbj@tail-f.com> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Wed, 26 Aug 2015 16:33:16 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] LL review of 6020bis-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 14:33:23 -0000 Martin Bjorklund writes: ... > >> >> 3. It's necessary to clearly separate properties of the data tree >> >> from properties of XML encoding. For instance, it is an >> >> inherent property of a container instance in the data tree >> >> that its children are unordered, or ordered in RPC >> >> input/output. Yet this is only specified in sec. 7.5.7 (XML >> >> Mapping Rules). >> > >> > I think this is a property of the XML encoding, not an inherent >> > property of the container. In JSON, all children are always >> > unordered. >>=20 >> I assume that data in whatever encoding contribute to the same >> (conceptual) data tree, so it would be useful to know the properties of >> the latter, such as whether some document order exists (as in XML) or >> not (as in JSON).=20 > > Ok. We have two alternatives: > > 1) Say that the data tree is unordered (or rather the order is > implementation specific) > > 2) Enforce an order. This would probably be the order that the nodes > are defined in the module (but keys first) + augments after that. > The problem is then in what order are the augmented nodes added? > Lexicographically on the module name maybe. Are there any use cases where order is important? I cannot think of any. > > Currently we have (1). If we stick to (1) then I think the special ordering rules (keys go first, RPC input/output has fixed order) should apply only to XML encoding because presumably it is important there for streaming data, and in JSON they cannot be enforced. > >> >> Similarly, the namespace of a module and XML namespace that's >> >> used in XML encoding are IMO two different things (cf. sec >> >> 5.3). >> > >> > Yes. Do you have any specific edits in mind? >>=20 >> Section 5.3 IMO can't say that "All YANG definitions are specified >> within a module that is bound to a particular XML namespace >> [XML-NAMES],=C2=A0..." because XML namespaces really make sense only in >> XML. > > I agree that XML namespaces make sense in XML. But why can't we say > that all definitions are bound to this XML namespace? [XML-NAMES] defines specific ways of how XML namespaces are declared, and we use these only in XML encoding but not in general. Or is the problem that you want to have the URI as the "official" namespace identifier? This is possible although I'd rather avoid using URIs and prefixes outside XML. > >> I'd suggest something like this: >>=20 >> A YANG module defines a namespace that is identified by the module >> name. Names of all YANG definitions specified in a module belong to >> its namespace. > > But this text doens't belong to section 5.3. It could belong there if the section is renamed to "Namespaces". IMO XML namespaces should only be dealt with in an "XML Encoding" section. > >> And then >>=20 >> Statements "namespace" and "prefix" define a mapping of the module >> namespace to the XML namespace and recommended prefix taht are used >> in XML encoding. >>=20 >> > >> >> 4. Terms "instance"/"instantiate"/"instatiation" are used in a >> >> loose way without being properly defined, probably as SNMP >> >> legacy. The XML term "instance document" adds yet another >> >> meaning. >> > >> > I'm not sure these are SNMP specific terms. I thought they were more >> > generic. Do you have any proposed edits? >>=20 >> I am not sure what it exactly means. For example, what is an instance in >> the case of a list/leaf-list: is it the complete array or an individual >> list entry? > > Maybe it helps if you point to specific text that is problematic. I > find for example: > > A list node may exist in multiple instances in the data > tree. Each such instance is known as a list entry. On the other hand, section 7.7.1 shows an "XML instance example" consisting of two elements. I'd suggest to use the term "instance" (data node instance) as a data tree counterpart of a data node in the schema tree. That is, an instance of a (leaf-)list would be an array containing (leaf-) list entries. > >> >> 5. A term is needed for describing a data model of a particular >> >> server, i.e. a collection of modules + supported features (+ >> >> deviations). I've used "data model", see >> >> https://github.com/mbj4668/pyang/wiki/Tutorial#yang-data-model >> > >> > The term "data model" is already used in a much more generic way in >> > 6020. >> > >> > "server YANG data model" maybe. >>=20 >> Perhaps we could use "data model" in the general sense as defined in >> sec. 3, and then "YANG data model" as the substance of the YANG >> "contract", which can be exactly constructed from the server's hello or >> yang-library. > > What do you call the complete set of modules in a client then? As it is now, the contract is defined by the server in terms of advertised modules, features and deviations. This sets the rules. The client, on the other hand, doesn't do a similar advertisement, so it has to abide by the rules set by the server, and it is IMO not that important whether the client fully understands the contract. > > But I am not sure the current text need this term? Apparently there are misunderstandings regarding conformance so I guess some clarification would be useful. ... > >> >> **** Sec. 3 >> >> - Shouldn't the term "data tree" also cover the contents of RPC >> >> input/output, actions and notifications? >> > >> > Yes, probably. But then we need to have a term for some of the >> > current usages of "data tree". Maybe "datastore" works (this term is >> > already used). >>=20 >> What current usages of "data tree" do you mean? > > For example: > > The difference between an action and an rpc is that an action is tied > to a node in the data tree Hmm, could actions be attached to nodes in state data? > > We also talk about "configuration data tree". (In the section about > constraints, which would benefit from a term for different 'data > trees'). Configuration data is OK, it is just a special data tree, as is e.g. RPC input data tree. It is important e.g. for XPath evaluation, because as it is now, one can think that canonical values are not used in RPCs or notifications. > >> Sec. 3: >>=20 >> OLD >>=20 >> o data tree: The instantiated tree of configuration and state data >> on a device. >>=20 >> NEW >>=20 >> o data tree: The instantiated tree of configuration, state data, >> combined configuration and state data, RPC input or output, or >> notification. >>=20 >> >> **** Sec. 6.1.3 >> >> I think the rules for whitespace trimming are confusing and have >> >> very little practical uses, so I'd recommend to remove them >> >> entirely. However, if the decision is to keep them, the following >> >> ambiguities need to be addressed: >> >> - It is unclear whether '\n' is equivalent to the literal LF >> >> character in the trimming process, i.e. whether the >> >> substitution of escape sequences is done before or after the >> >> trimming. >> > >> > How does this matter? >>=20 >> Are the following two defaults identical or not? >>=20 >> default "foo >> bar"; >>=20 >> default "foo\n\t bar"; > > No. > > Ok, how about: > > OLD: > > Whitespace trimming and substitution of backslash-escaped characters > in double-quoted strings is done before concatenation. > > NEW: > > Whitespace trimming is done before substitution of backslash-escaped > characters in double-quoted strings. Concatenation is performed as > the last step. > Yes, this solves this issue. >> >> - Is tab character treated as 8 spaces also before the opening >> >> double quote? Example: >> >>=20 >> >> description "This is a long >> >> text." >> >>=20 >> >> Does it matter whether the character between "description" and >> >> the opening double quote is a space or tab character? (Both >> >> cases may have identical visual rendering depending on the >> >> column where the statement starts.) >> > >> > I would think so. I think whitespace-trimming in general is very >> > useful, but the tab-expansion is a bit confusing. I think it would be >> > ok to remove the expansion of tab with 8 spaces. >>=20 >> I don't think they are that useful. In practice, such multiline strings >> only appear in descriptions and references where whitespace trimming >> is pretty much >> irrelevant. > > It is not irrelevant if you transform descriptions to some other > format, such as YIN or a man-page or whatever. In simple cases a straightforward space normalization will usually do, and in more complicated cases, e.g. a description with bullet list, the raw description text isn't of much use anyway. Anyhow, I think such use cases don't warrant a section in the language spec full of relatively tricky rules. > >> >> * It might be useful to define how namespace nodes representing >> >> YANG namespaces appear in the XPath tree so that the >> >> namespace:: axis works in a deterministic fashion. For >> >> example, one could say that all these namespaces are in scope >> >> for all elements corresponding to YANG data nodes. One could >> >> use it, e.g. to determine whether a particular YANG module is >> >> a part of the data model. >> > >> > Why wouldn't the namespace axis work in a deterministic fashion? All >> > nodes defined in a module have the same XML namespace, which is >> > well-defined. >>=20 >> The content of the namespace:: axis depends on how exactly XML >> namespaces are specified. > > [re-reading the text on namespace nodes...] > > Ok. > >> For example, it would be different for the >> "foo" element in each of the following three cases: >>=20 >> >> >> >>=20 >> >> >> >>=20 >> >> xmlns:bar=3D"http://example.com/bar"> >> >> >>=20 >> I'd suggest to have it by definition so that all namespaces are >> specified outside the data tree - as if the definitions are on the >> encapsulating NETCONF or - and with prefixes that are >> defined in the modules (unless there is a conflict). > > Well, since the local-name of a namespace node is the prefix, I think > it would be more correct to say all nodes defined in a module have the > same set of namespace nodes, and that this set built from the the own > module + all imports. (exact text TBD...) Yes, that's what I meant. > > >> >> **** Sec. 7.6.1 >> >> - The text is suitable for config, defaults in RPC input/output >> >> and notifications are covered elsewhere, but what about >> >> defaults (and mandatory) in state data? >> > >> > I don't think this text is excludes state data. >>=20 >> I think the semantics of defaults in configuration and state data is >> different - state data just report (hopefully true) state, so the >> requirement that "the server MUST operationally behave as if the leaf >> was present in the data tree with the default value as its value" seems >> somewhat backwards. > > I think this means that a server can choose to NOT send default values > for state node. But it also allows a server to always send all > values. OK. > >> >> **** Sec. 7.8.6 >> >> - It would be helpful to include an example of yang:key attribute >> >> value with multiple (two) keys. I remember somebody asked me >> >> about that. >> > >> > Fixed. >> > >> >> **** Sec. 7.9.2 >> >> - The paragraph about shorthand case statement should more >> >> explicitly explain that a case node is present in the schema >> >> tree even for short-case-stmt, and thus schema node identifiers >> >> always need to include case node identifiers. >> > >> > I don't understand how the current text could give the impression that >> > there is no case node in the schema tree of shorthand cases are used. >>=20 >> OLD >>=20 >> In this case, the identifier of the case node is the same as the >> identifier in the branch statement. >>=20 >> NEW >>=20 >> In this case, the case node still exists in the schema tree, and its >> identifier is the same as the identifier in the branch statement. Schema >> node identifiers (Section=C2=A06.5) MUST always explicitly include case = node >> identifiers > > Ok, I'll add this. > >> - if a shorthand case statement is used, the identifier of >> the branch statement will appear twice.=20 > > ... but this part is somehwat confusing - I understand what you mean, > but maybe we can skip it? I have seen several YANG users (including myself) who were wondering why a certain schema node identifier doesn't work. It is somewhat counter-intuitive because the shorthand case nodes don't appear in a module hierarchy so it is easy to forget about them. > > >> >> **** Sec. 7.10 >> >> - The section should also state that the data model for "anydata" >> >> content may or may not be known at run time. >> > >> > How about this: >> > >> > NEW: >> > >> > An implementation may or may not know the data model used to model a >> > specific instance of an anydata node. >>=20 >> OK. >>=20 >> > >> > >> >> **** Sec. 7.12 >> >> - 'For extensions, this means that extensions are applied to the >> >> grouping node, not the uses node.' >> >>=20 >> >> I dont understand what this means. What is the "grouping node"? >> > >> > Right; there is no "grouping node" and no "uses node". I suggest we >> > simply do: >> > >> > NEW: >> > >> > For extensions, this means that extensions are applied to the >> > grouping itself. >>=20 >> I still don't get the point. How does it apply e.g. to NACM extensions >> if they are used inside a grouping?=20 > > Ah, ok, I see how it is unclear. How about: > > NEW: > > For extensions, this means that extensions defined as direct > children to a "grouping" statement are applied to the > grouping itself. OK. ... > >> >> **** Sec. 9.10.3 >> >> The last paragraph should probably be replaced with an advice th= at >> >> identityref values or nodesets should never appear as bare >> >> strings in XPath expressions, and functions derived-from() or >> >> derived-from-or-self() should be used instead. >> > >> > I think the string value needs to be defined. >>=20 >> OK, but still some text like this could help: "In general, equality >> tests involving identityref nodes should be avoided - XPath functions >> derived-from() or derived-from-or-self() (Section 10.4) should be used >> instead." > > I still think this text doesn't belong here. This is a best practise > issue. OK. > >> >> Example in >> >> sec. 9.10.5 should be changed to use derived-from-or-self(). >> > >> > I think it reasonable to examplify the string value of an identity. >> > However, I agree that we should add advice about using >> > derived-from-or-self(), but I think that should be done in 6087bis. >> > >> >> **** Sec. 10.3.1 >> >> - The document order is undefined in a data tree (also in >> >> sec. 10.4.1 and 10.4.2). >> > >> > Above (for 6.4) you suggested that the document order is >> > implementation-specific. >>=20 >> But that means different implementations may give different results.=20 > > Yes. > >> >> - I think deref() could return non-empty nodeset only for >> >> instance-identifiers because for leafref it's not needed. >> > >> > Ok...? Do you have any edits in mind? >>=20 >> Remove the third paragraph. Unlike instance-identifier, a leafref >> *instance* doesn't refer to any nodes. > > Ok, I see, I mis-read your original comment. > > We have had deref() implemented for several years, and it is mostly > used for leafrefs. I really think we should keep it also for > leafrefs. deref() for instance-identifiers doesn't need a schema (all "normal" XPath functions don't) whereas for leafrefs the implementation has to find the path of the leafref in the corresponding YANG module. This means that such a function cannot be implemented as an extension to standard XPath/XSLT processors such as "xsltproc". For instance-identifiers this function is indispensable while for leafrefs it is just an abbreviation, and an alternative expression without deref() always exists. Lada > > > /martin --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Aug 26 07:51:48 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0211B3035; Wed, 26 Aug 2015 07:51: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 f-Kxt9HGkD6t; Wed, 26 Aug 2015 07:51:46 -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 0AE891B3016; Wed, 26 Aug 2015 07:51: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.256.15; Wed, 26 Aug 2015 14:51:44 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.27]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.27]) with mapi id 15.01.0256.013; Wed, 26 Aug 2015 14:51:44 +0000 From: Kent Watsen To: Andy Bierman , Nadeau Thomas Thread-Topic: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00 Thread-Index: AQHQ2hI2vvHP2Jfp7UmC49Y77azqQ54Siz0AgACDKACAARvMgIAAXceAgAkYyICAAD9QgIAAMowAgAAMcwCAABNhgIAACXwAgAAQ4gCAAAcMgIAABYGA///M4AA= Date: Wed, 26 Aug 2015 14:51:44 +0000 Message-ID: References: <20150826.122600.1110046163132211535.mbj@tail-f.com> <19CCF9F5-87F1-4C41-8151-18AD36D98CE6@lucidvision.com> <20150826.140918.2163222167742824482.mbj@tail-f.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.13] x-microsoft-exchange-diagnostics: 1; CO1PR05MB458; 5:Au0/pJ7utoBQ2VEdV3acNbJFWAA3AxoxxBbWXJ2abWadI8EP2edQOA9xcjXMC9JLCwaoPagwiPCIQmKkrgEAYn6/cphdV4F1pJ+ol+vo/G2P6jZQ7f1pTTZd1F/JYasXa6d9VN40YJcPfYSpTSEe8A==; 24:Tqa1NMrmVUiE5Ehyqd2xyAae6jT2WfAJuk94g4zJL/Qf75OWB0Q+as3qNZPtXrBDc8/a8sr0kGUEDog4AJ6LZ/e3B0Bj5hlaaAEIOIJI7/0=; 20:kUyXQVAXnFBkvJInenBPNNUiwDF5FHIkhCIA5aTLVFBGUzphaVJgVz70MS57z2tOFO19kTwiF9Np79/T1VwuzQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(8121501046)(3002001); SRVR:CO1PR05MB458; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458; x-forefront-prvs: 0680FADD48 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(105586002)(16236675004)(106356001)(102836002)(10400500002)(99286002)(106116001)(36756003)(54356999)(76176999)(4001540100001)(50986999)(46102003)(68736005)(93886004)(81156007)(4001350100001)(230783001)(87936001)(2656002)(5004730100002)(77156002)(40100003)(2900100001)(5001920100001)(62966003)(2950100001)(92566002)(86362001)(5001960100002)(83506001)(189998001)(5002640100001)(5007970100001)(101416001)(5001860100001)(66066001)(5001830100001)(5001770100001)(97736004)(122556002)(64706001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D203469DD339Dkwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Aug 2015 14:51:44.2198 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB458 Archived-At: Cc: "netmod@ietf.org" , "draft-rtgyangdt-rtgwg-device-model@ietf.org" , "rtgwg@ietf.org" Subject: Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 14:51:47 -0000 --_000_D203469DD339Dkwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > Another approach is to not rely so heavily on one giant uber-tree > that MUST be correct on the first try and never change. I agree that an uber tree stands to make things worse. Distinct modules h= ave distinct namespaces and no collisions concerns. But even better than = that, distinct modules promote competition. I have no issues with there ex= isting modules with overlapping concerns, even when implemented simultaneou= sly by the same server. I'm projecting, but it seems that the uber tree ap= proach would put a freeze to such experimentation, which is fine for a spec= ific project to hoist onto itself, but seems inappropriate for a standards = organization. Again, I like the idea of relocatable modules, as it seems t= o allow coexistence of both options. Kent // as a contributor --_000_D203469DD339Dkwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable


> Another approach is to not rely so heavily on one giant uber-tree
> that MUST be correct on the first try and never change.

I agree that an uber tree stands to make things worse.   Distinct= modules have distinct namespaces and no collisions concerns.   But ev= en better than that, distinct modules promote competition.  I have no = issues with there existing modules with overlapping concerns, even when implemented simultaneously by the same server.  I= 'm projecting, but it seems that the uber tree approach would put a freeze = to such experimentation, which is fine for a specific project to hoist onto= itself, but seems inappropriate for a standards organization.  Again, I like the idea of relocatable modu= les, as it seems to allow coexistence of both options.

Kent // as a contributor



--_000_D203469DD339Dkwatsenjunipernet_-- From nobody Wed Aug 26 08:19:42 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB2401B2C96; Wed, 26 Aug 2015 08:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id auc50Bq8Pap8; Wed, 26 Aug 2015 08:19:38 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 531D51B2BA0; Wed, 26 Aug 2015 08:19:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1440602314; bh=uFDFLwYLJyKHr5IC51DyEbrDo/WDTGJArBnNkSjOrLA=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=0mPb8GjhXfpKiQ8bUzRtlqjTKYQf5m2pbfXFgCz1RfawssfSPVXo1JXFDnjRfViwn N+5j4HA2lVSb7Iji63YTYigAG40kjHN4yMnflSVqbUvs6dkT74ckIzr/lSGJnCd8oF apG1PsKRrE1I19UsUie9A6xgT7SUlJHjhVuCsBxY= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; Content-Type: multipart/alternative; boundary="Apple-Mail=_4ABF2180-4772-47BC-AE24-183B374258F4" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Nadeau Thomas In-Reply-To: Date: Wed, 26 Aug 2015 11:19:34 -0400 Message-Id: <6FBD632F-7F12-4324-8723-B802DC108DC9@lucidvision.com> References: <20150826.122600.1110046163132211535.mbj@tail-f.com> <19CCF9F5-87F1-4C41-8151-18AD36D98CE6@lucidvision.com> <20150826.140918.2163222167742824482.mbj@tail-f.com> To: Kent Watsen X-Mailer: Apple Mail (2.2104) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-ShareWhite: 50.255.148.181 X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=16 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181 X-IP-stats: Notspam Incoming Last 0, First 103, in=1157, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: Cc: "netmod@ietf.org" , "draft-rtgyangdt-rtgwg-device-model@ietf.org" , "rtgwg@ietf.org" Subject: Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 15:19:39 -0000 --Apple-Mail=_4ABF2180-4772-47BC-AE24-183B374258F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Aug 26, 2015:10:51 AM, at 10:51 AM, Kent Watsen = wrote: >=20 >=20 >=20 > > Another approach is to not rely so heavily on one giant uber-tree > > that MUST be correct on the first try and never change. >=20 > I agree that an uber tree stands to make things worse. =20 This seems to be the case the more we think through this. > Distinct modules have distinct namespaces and no collisions concerns. = But even better than that, distinct modules promote competition. =20 Or simply multiple versions of the same modules at the same = time. ODL lets you do this, for example, and happily works. But the = other more IETF-related situation is as you say, if there are two draft = models for the same features. One could and should=20 be able to run them together, for at least experimental purposes.=20 > I have no issues with there existing modules with overlapping = concerns, even when implemented simultaneously by the same server. I'm = projecting, but it seems that the uber tree approach would put a freeze = to such experimentation, which is fine for a specific project to hoist = onto itself, but seems inappropriate for a standards organization. = Again, I like the idea of relocatable modules, as it seems to allow = coexistence of both options. I agree. Tom (as individual). >=20 > Kent // as a contributor >=20 >=20 >=20 --Apple-Mail=_4ABF2180-4772-47BC-AE24-183B374258F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Aug 26, 2015:10:51 AM, at 10:51 AM, Kent Watsen <kwatsen@juniper.net>= wrote:



> Another approach is to not rely so heavily on one giant = uber-tree
> that MUST be correct on the first try and never change.

I agree that an uber tree stands to make things worse. =  

This = seems to be the case the more we think through this.

Distinct modules have = distinct namespaces and no collisions concerns.   But even better = than that, distinct modules promote competition. =  

Or simply = multiple versions of the same modules at the same time. ODL lets you do = this, for example, and happily works.  But the other more = IETF-related situation is as you say, if there are two draft models for = the same features.  One could and should 
be able to = run them together, for at least experimental purposes. 

I have no issues with = there existing modules with overlapping concerns, even when implemented simultaneously by the same server. =  I'm projecting, but it seems that the uber tree approach would put = a freeze to such experimentation, which is fine for a specific project = to hoist onto itself, but seems inappropriate for a standards organization.  Again, I like the idea of relocatable = modules, as it seems to allow coexistence of both = options.

I agree.

Tom  (as = individual).


Kent // as a contributor




= --Apple-Mail=_4ABF2180-4772-47BC-AE24-183B374258F4-- From nobody Wed Aug 26 09:41:22 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B285F1B2B1B for ; Wed, 26 Aug 2015 09:41:20 -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 VwUQDBbne5hO for ; Wed, 26 Aug 2015 09:41:18 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0743.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::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 EAC831B2B08 for ; Wed, 26 Aug 2015 09:41:17 -0700 (PDT) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.151.163.82) by AMSPR07MB050.eurprd07.prod.outlook.com (10.242.81.24) with Microsoft SMTP Server (TLS) id 15.1.231.21; Wed, 26 Aug 2015 16:40:59 +0000 Message-ID: <012901d0e01e$12c22b20$4001a8c0@gateway.2wire.net> From: t.petch To: Juergen Schoenwaelder References: <55D36473.90609@cisco.com> <55D45CAF.2070605@cisco.com> <20150819.132555.871710491924929960.mbj@tail-f.com> <013601d0da9b$907f6b00$4001a8c0@gateway.2wire.net> <20150823170415.GA77197@elstar.local> Date: Wed, 26 Aug 2015 17:41:29 +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.163.82] X-ClientProxiedBy: DB5PR08CA0003.eurprd08.prod.outlook.com (25.163.102.141) To AMSPR07MB050.eurprd07.prod.outlook.com (10.242.81.24) X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB050; 2:bk/+ai/7VbwdpidSPamkMiL8LW0gsu4tu2WweNmGTVJWqb2WQM2ubIVTjbJOQkyIDQBXUAg1dczXmUbwHyk0Ax/REE8fmJ9sDB0Q1dprEDjznMvmae0xk3S/dC0oKjBrru8E+K0sjCNhhWNJjLFY694JRCeO3opLgip0bq9TGFg=; 3:RkC7UUpFEOKO+gph4vUcv751qIAN9Z1RxFfF33tmEmPFbOLUi1V6RafjlgZiyg/CM5BHn24KGx/L/3ztLi/B9Leo+OdAacu/8yd4c5EWgshUVnN08lduwnyef/xMM2qWm25UiC2emJIrv6TO8tDD7Q==; 25:KOhc6E3WyveJrxtoXL+boa0lQqSTKjuRsKK8imQGTwD4M1+gdhUM5M58mM7PPFYMgdVMqRtLqS7EvjkRezeW4XXC7WW3iZt+3eRj6oZgASlGHRIdAoc/upFsmY422JuLGVvZS9kpt+2H7UWj2NvWw1f9Iyvz9xSwHGRxL6lNBfMh3bM5S5ApwdSQkaGoxJ+S8lAvzdzc6xGwGYVTuJdcWigHppphFqYH40f8n37uRh0tBDDuExTpSuZykHrFIgDNgUOsLqlglFe+fmrqsqpA9w==; 4:2hsaOfJvAqgdwoEWbQMN6EGwbEwTb8PB5lGVBhmKjxk7pHnTRK2zhUdO1x4eFcndhnPpKTzv1W57a9a+Rpp+Fb2E2C30E1Uj1qSfLeKBX0+vgd9DypM9+bhDBcwayBLCvkLZhpctTORWXmvY8diT2ikRp8Q3XHGRq3dvm3QpiYd9wjJhtaD0pM2mCTTLYGr8sZ95O4aijZVSpumWDsuyJBNfvmKBZhyd6L3lUulU64RlBW8+rx72W8qSLwldTtrjYhVDqBi1C4HV6Lj0JFM4tu+6ViXZEgOKnOS6tUrWkw6vrhh4NgFwBIFZFj8cX2A3 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB050; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(8121501046)(5005006)(3002001); SRVR:AMSPR07MB050; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB050; X-Forefront-PRVS: 0680FADD48 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(189002)(199003)(54094003)(13464003)(377454003)(50986999)(46102003)(14496001)(81816999)(101416001)(15975445007)(76176999)(50466002)(5001860100001)(77096005)(68736005)(44716002)(62236002)(1456003)(97736004)(81686999)(66066001)(81156007)(1556002)(47776003)(64706001)(87976001)(110136002)(5001960100002)(61296003)(189998001)(5001830100001)(40100003)(4001540100001)(93886004)(116806002)(122386002)(105586002)(5004730100002)(33646002)(5007970100001)(19580395003)(19580405001)(92566002)(42186005)(106356001)(84392001)(23756003)(62966003)(44736004)(86362001)(50226001)(77156002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB050; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; AMSPR07MB050; 23:ORYrSWHBBnjncG3qcYBU2OsHM+Zunb0feRGCDF9Q?= =?iso-8859-1?Q?TZ4bQ91cbgkXIQ239jbhQOmzN0QEfbWXBvok8EgcNFG5pYHqz0WOsLAfji?= =?iso-8859-1?Q?8xQwvKyGc3jfDolOlni9Gq2mD2dDmthoPypuhjhLbssRYvObbQ28OhPcXh?= =?iso-8859-1?Q?Me1MfwVwnNt7WQ2J6VeCtLgVeqD4vl7wHudG1EigpyhL58eHzpkbRQrxkc?= =?iso-8859-1?Q?yFg2r+LPEMcMZpIOy+Hr6jiHrhlCbYNVokGas7oU72csfiHnNeeBrVAOl1?= =?iso-8859-1?Q?HGBmEq87BwS4KVPdlpn92ejEgROxGKTDWf5kGSNhB3RFGI0n6/4arAL/vp?= =?iso-8859-1?Q?sQD5wZcfup4ezUNXNe875bxQ6hVMBNeZR+YeSdRuL/Vazw/ETqZUlKbwvk?= =?iso-8859-1?Q?rn8AIL87hJ5L9dx1GeORPEERJGo2ayzrb1qM2YDV6KTaFI/YldNQyQYdqb?= =?iso-8859-1?Q?Ln3K48zWtpxLnuk9UNOy/rKNgFUaILxuuSJ4yAsg/ltKpV1tFLmfqlsXiS?= =?iso-8859-1?Q?z2ijt3osYr9NBohMq0T1f8p8pvG+RAmue3cc1i6/fnHSSx9mgJQ60bSqDd?= =?iso-8859-1?Q?YeOVv3SAB66K64CS+F+/KPF7PwH4y9Ro/xnrhWYjZGOsy1a7IE3Y7wKl4y?= =?iso-8859-1?Q?6Hyli8FCN9qinRO7isZXFEsB7uCIEHDFqzCXqYrJa+mFHSBTu1JeGtjGMt?= =?iso-8859-1?Q?bDdzHEVwI3cz/UMP4IlQTxmZ42Xii1h4psLaM3bBbl/mz/lHVo1GbiV8DL?= =?iso-8859-1?Q?9owe4YYxN9DhuuYl7TIm2U2A7hm6VWk27H8ck1WDzDaKX+gP+6E6Qd37Ws?= =?iso-8859-1?Q?HfPXDOUnENrRJ/mPMXImm/o0+IulllCbbc8KwfTvO7F/UFbHDpsQtvsSCr?= =?iso-8859-1?Q?M6inL15q+QSLjDzIrB6bVY36arP6kPuwwjEh+wbDEfGkxnxlOYpiISrYqS?= =?iso-8859-1?Q?U0El0Q72HBQNFJTjO/KkDc7Yj3RBE01mtySoNX75Tgl+qxjWgGDiY61OOp?= =?iso-8859-1?Q?FrlQDNPjPOFmoXdp7wvxdhr/t+QyVEB0WQbqt3/fIYKFo3zsJaIq8nT/0G?= =?iso-8859-1?Q?z+csG5tXeUmh0JxEdWzq2RbmVQgTbPG8+BzLi6f2PuFOP2UcQzmdzNG3GK?= =?iso-8859-1?Q?F0LTNl2yeIo6WYwKhdRwTdeHy7xt02uUgmvjmiVaxo2es8qgjhTD0Yg6F0?= =?iso-8859-1?Q?j0b7fPSrLMk8I0LmTPcdVkPbyUvQsMK8Y+GGhrx77aMArnAJQj6drNFLTl?= =?iso-8859-1?Q?2buUdTotHek0hqGrMy8EqKVD2QknXIydK9iq0bPL8sBBIG2KD5Zh0CYja2?= =?iso-8859-1?Q?0iTOJt45oY/AYVyU/P6WtXMCYoN8iBFVtQi6tiiFDOlIJ/bev/uqI8M6UT?= =?iso-8859-1?Q?i83i5wRLpogpHKH7njNCzIRdYEUBxHmWwUIeMayT7m4kRhTTpGOEbMLvVP?= =?iso-8859-1?Q?1AY1SfK8ltOYXAfIu6cnfbdAYGZdxVnijHs4YgZofA1LW+W7o9lruryyTn?= =?iso-8859-1?Q?kJHp2R948+6hpb5JLkiSKj8Pcn4jYkdB+ig5OREP?= X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB050; 5:GUxz73d8JPC08ID5coDczcJQiGLAWCPg3S5YkrZVrTFMsN+yi9GQUBFNb7YkHkOJMH7wwxysFQhmVdStaz8LaZbySAqTF0kzHqflnOM7pAu+OHJTtCKEOm2OhPfD40VxAoCuI0+VnbAVFUaZ3bzXHg==; 24:DFmcZXTZDKvqROybyYqcLxh42NftyDE0j28actbV9dNYs85SFKr80x/gc93thqgZ0MXsxt0gustbwnQrqOrIgGxn4CaIX8vcbh8GQutebng=; 20:D+A8/u8aB52oXXRq9xAgpgM9xBREhcY2rBRX74NCGz+D5fU4fDhUXxeRxRwnmsHG5NksTJXm4QZXBG3/FGXWhw== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Aug 2015 16:40:59.6692 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB050 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Y34 - root node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 16:41:20 -0000 ----- Original Message ----- From: "Juergen Schoenwaelder" To: "t. petch" Cc: ; "Martin Bjorklund" ; Sent: Sunday, August 23, 2015 6:04 PM > On Wed, Aug 19, 2015 at 05:24:41PM +0100, t. petch wrote: > > > The current model is a flat architecture of hundreds (or thousands) of > > modules each with their own top level nodes, namespace, namespace name, > > prefix etc. (This is quite different to SMI with its hierarchy but that > > probably is only significant to those who have spent 20 years with SMI). > > This is most likely a wrong perception. There are basically only two > locations where SNMP modules are registered in the IETF: under mib-2 > and under transmission (yes there are a few exceptions but overall in > number they do not matter). There are close to 240 MIB modules below > mib-2 and about 50 MIB modules below transmission. Juergen I know what you mean, that the MIB module tree is somewhat fasciated, but there is still one root, from which an obvious, absolute OID can be used to identify uniquely any MIB module (or in some contexts a relative one, relative to transmission or mib 2). If SMI did have constraints, then there would not be an issue of how to express them, nor would there be any question of mounting a module elsewhere for whatever reason (which then creates problems for the references in the constraints). A flat sea of YANG modules is different; I haven't counted lately how many top level nodes I have seen but it is a lot and when I see people wanting to organise YANG modules into a tree, I wonder if they are trying to recreate an SMI-like tree and my reaction is that this is not SMI! The flat sea of YANG modules brings a different set of issues and I am unsure what they are; I understand what is involved with the references in constraints, I can see that there will be a lot of namespaces and prefixes and can speculate about what that will bring but what it means to have so many top level nodes, I do not know. I believe that in a year or three we will be wishing we had paid more attention to this. Tom Petch > RFC 4181: > > - The value assigned to the MODULE-IDENTITY descriptor MUST be unique > and (for IETF standards-track MIB modules) SHOULD reside under the > mgmt subtree [RFC2578]. Most often it will be an IANA-assigned > value directly under mib-2 [RFC2578], although for media-specific > MIB modules that extend the IF-MIB [RFC2863] it is customary to use > an IANA-assigned value under transmission [RFC2578]. In the past, > some IETF working groups have made their own assignments from > subtrees delegated to them by IANA, but that practice has proven > problematic and is NOT RECOMMENDED. > > /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 Aug 26 09:57:28 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D80F1A1A52 for ; Wed, 26 Aug 2015 09:57:27 -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_15=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 1ivescYwKgLv for ; Wed, 26 Aug 2015 09:57:25 -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 196471A007C for ; Wed, 26 Aug 2015 09:57:25 -0700 (PDT) Received: by labns7 with SMTP id ns7so6101404lab.0 for ; Wed, 26 Aug 2015 09:57:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NOEKHaIfqIUssM5hBXLX2aPpirj3TWx1vEegHE3LWSo=; b=OiOMVFK4QrplpWUcyMuqbbK+JgB9jfg4yDPIdugMynchi7lz9KuiVCf8evYp68v6MS Oc27UjtH559q8+J7v/q2okvb+wYLxWjDlHrX+vutBGpx7u2yK1gH6aO70OdVSD9fyG+a 0mYxvOtpPC/Qcrtn1cMjsbZJvqiUOye7Crwg5CqlPMBYleFqWURyLpsp5/mi8+/WCCMd ZCt2e1eOVK7jZh2E1tFRcHyLm5Z73pnGjH9zU9UR/wsFILqC3G9pdoLABwSFjR2x0zd7 KtwK+WZw34W70kss0O/8X3Pkg4dqx99v1XqkXLpffysfnVa+cCP0mjYnf8GACPiqMUMv jN1Q== X-Gm-Message-State: ALoCoQn9FJFWulpeGIkGLFEBFZjTo0lHdWzCynI8su0CoM5NNScPni0Z4WdjUzkdKrtiEeXYK+Fn MIME-Version: 1.0 X-Received: by 10.112.161.232 with SMTP id xv8mr31575250lbb.123.1440608243431; Wed, 26 Aug 2015 09:57:23 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Wed, 26 Aug 2015 09:57:23 -0700 (PDT) In-Reply-To: <012901d0e01e$12c22b20$4001a8c0@gateway.2wire.net> References: <55D36473.90609@cisco.com> <55D45CAF.2070605@cisco.com> <20150819.132555.871710491924929960.mbj@tail-f.com> <013601d0da9b$907f6b00$4001a8c0@gateway.2wire.net> <20150823170415.GA77197@elstar.local> <012901d0e01e$12c22b20$4001a8c0@gateway.2wire.net> Date: Wed, 26 Aug 2015 09:57:23 -0700 Message-ID: From: Andy Bierman To: "t.petch" Content-Type: multipart/alternative; boundary=001a11c3c46c9c6056051e39be12 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y34 - root node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 16:57:27 -0000 --001a11c3c46c9c6056051e39be12 Content-Type: text/plain; charset=UTF-8 On Wed, Aug 26, 2015 at 9:41 AM, t.petch wrote: > ----- Original Message ----- > From: "Juergen Schoenwaelder" > To: "t. petch" > Cc: ; "Martin Bjorklund" ; > > Sent: Sunday, August 23, 2015 6:04 PM > > > On Wed, Aug 19, 2015 at 05:24:41PM +0100, t. petch wrote: > > > > > The current model is a flat architecture of hundreds (or thousands) > of > > > modules each with their own top level nodes, namespace, namespace > name, > > > prefix etc. (This is quite different to SMI with its hierarchy but > that > > > probably is only significant to those who have spent 20 years with > SMI). > > > > This is most likely a wrong perception. There are basically only two > > locations where SNMP modules are registered in the IETF: under mib-2 > > and under transmission (yes there are a few exceptions but overall in > > number they do not matter). There are close to 240 MIB modules below > > mib-2 and about 50 MIB modules below transmission. > > Juergen > > I know what you mean, that the MIB module tree is somewhat fasciated, > but there is still one root, from which an obvious, absolute OID can be > used to identify uniquely any MIB module (or in some contexts a > relative one, relative to transmission or mib 2). If SMI did have > constraints, then there would not be an issue of how to express them, > nor would there be any question of mounting a module elsewhere for > whatever > reason (which then creates problems for the references in the > constraints). > > A flat sea of YANG modules is different; I haven't counted lately how > many > top level nodes I have seen but it is a lot and when I see people > wanting to > organise YANG modules into a tree, I wonder if they are trying to > recreate > an SMI-like tree and my reaction is that this is not SMI! > > The flat sea of > YANG modules brings a different set of issues and I am unsure what they > are; > I understand what is involved with the references in constraints, I can > see that > there will be a lot of namespaces and prefixes and can speculate about > what > that will bring but what it means to have so many top level nodes, I do > not > know. > > I believe that in a year or three we will be wishing we had paid more > attention > to this. > > YANG uses XPath absolute-path expressions to identify data instances. Each node in the tree has a QName (namespace + local-name). There is zero ambiguity in an absolute path expression, so it works whether there are 3 modules or 30,000 modules. But if the path expression cannot change over time. We do not need to place every new node at the top. In fact, we don't, as the ietf-ip module proves. We do need to pick a home for data and never change it -- ever. Starting over with a data node means picking a new location for its home. IMO the "logical view" injected into the model is the worst part. This does not apply to very many implementations, and these virtual devices are usually dealt with in the protocol, not the data model. That way, different logical views can be derived, instead of imposing a single logical model (with a uint8 index to cover all possible logical instances). > Tom Petch > Andy > > > RFC 4181: > > > > - The value assigned to the MODULE-IDENTITY descriptor MUST be > unique > > and (for IETF standards-track MIB modules) SHOULD reside under > the > > mgmt subtree [RFC2578]. Most often it will be an IANA-assigned > > value directly under mib-2 [RFC2578], although for media-specific > > MIB modules that extend the IF-MIB [RFC2863] it is customary to > use > > an IANA-assigned value under transmission [RFC2578]. In the > past, > > some IETF working groups have made their own assignments from > > subtrees delegated to them by IANA, but that practice has proven > > problematic and is NOT RECOMMENDED. > > > > /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 > --001a11c3c46c9c6056051e39be12 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Aug 26, 2015 at 9:41 AM, t.petch <ietfc@btconnect.com&g= t; wrote:
----- Original Message -= ----
From: "Juergen Schoenwaelder" <j.schoenwaelder@jacobs-university.de>
To: "t. petch" <ietfc@b= tconnect.com>
Cc: <rwilton@cisco.com>; &qu= ot;Martin Bjorklund" <mbj@tail-f.= com>;
<netmod@ietf.org>
Sent: Sunday, August 23, 2015 6:04 PM

> On Wed, Aug 19, 2015 at 05:24:41PM +0100, t. petch wrote:
>
> > The current model is a flat architecture of hundreds (or thousand= s)
of
> > modules each with their own top level nodes, namespace, namespace=
name,
> > prefix etc.=C2=A0 (This is quite different to SMI with its hierar= chy but
that
> > probably is only significant to those who have spent 20 years wit= h
SMI).
>
> This is most likely a wrong perception. There are basically only two > locations where SNMP modules are registered in the IETF: under mib-2 > and under transmission (yes there are a few exceptions but overall in<= br> > number they do not matter). There are close to 240 MIB modules below > mib-2 and about 50 MIB modules below transmission.

Juergen

I know what you mean, that the MIB module tree is somewhat fasciated,
but there is still one root, from which an obvious, absolute OID can be
used to identify uniquely any MIB module (or in some contexts a
relative one, relative to transmission or mib 2).=C2=A0 If SMI did have
constraints, then there would not be an issue of how to express them,
nor would there be any question of mounting a module elsewhere for
whatever
reason (which then creates problems for the references in the
constraints).

A flat sea of YANG modules is different; I haven't counted lately how many
top level nodes I have seen but it is a lot and when I see people
wanting to
organise YANG modules into a tree, I wonder if they are trying to
recreate
an SMI-like tree and my reaction is that this is not SMI!

The flat sea of
YANG modules brings a different set of issues and I am unsure what they
are;
I understand what is involved with the references in constraints, I can
see that
there will be a lot of namespaces and prefixes and can speculate about
what
that will bring but what it means to have so many top level nodes, I do
not
know.

I believe that in a year or three we will be wishing we had paid more
attention
to this.



YANG uses XPath absolut= e-path expressions to identify data instances.
Each node in the t= ree has a QName (namespace + local-name).
There is zero ambiguity= in an absolute path expression, so it
works whether there are 3 = modules or 30,000 modules.
But if the path expression cannot chan= ge over time.

We do not need to place every new no= de at the top.
In fact, we don't, as the ietf-ip module prove= s.
We do need to pick a home for data and never change it -- ever= .
Starting over with a data node means picking a new location for= its home.

IMO the "logical view" inject= ed into the model is the worst part.
This does not apply to very = many implementations, and these
virtual devices are usually dealt= with in the protocol, not the data model.
That way, different lo= gical views can be derived, instead of imposing
a single logical = model (with a uint8 index to cover all possible logical instances).





=C2=A0
Tom Petch

Andy
=C2=A0

> RFC 4181:
>
>=C2=A0 =C2=A0 - The value assigned to the MODULE-IDENTITY descriptor MU= ST be
unique
>=C2=A0 =C2=A0 =C2=A0 and (for IETF standards-track MIB modules) SHOULD = reside under
the
>=C2=A0 =C2=A0 =C2=A0 mgmt subtree [RFC2578].=C2=A0 Most often it will b= e an IANA-assigned
>=C2=A0 =C2=A0 =C2=A0 value directly under mib-2 [RFC2578], although for= media-specific
>=C2=A0 =C2=A0 =C2=A0 MIB modules that extend the IF-MIB [RFC2863] it is= customary to
use
>=C2=A0 =C2=A0 =C2=A0 an IANA-assigned value under transmission [RFC2578= ].=C2=A0 In the
past,
>=C2=A0 =C2=A0 =C2=A0 some IETF working groups have made their own assig= nments from
>=C2=A0 =C2=A0 =C2=A0 subtrees delegated to them by IANA, but that pract= ice has proven
>=C2=A0 =C2=A0 =C2=A0 problematic and is NOT RECOMMENDED.
>
> /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/>

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

--001a11c3c46c9c6056051e39be12-- From nobody Wed Aug 26 10:28:05 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78E1C1A3B9D for ; Wed, 26 Aug 2015 10:28: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 zoMn1KdqMl6w for ; Wed, 26 Aug 2015 10:28:02 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C74461A87BF for ; Wed, 26 Aug 2015 10:28:00 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 4B0A31AE049C; Wed, 26 Aug 2015 19:27:58 +0200 (CEST) Date: Wed, 26 Aug 2015 19:28:12 +0200 (CEST) Message-Id: <20150826.192812.1957507844648445648.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <20150826.142939.241315678797135798.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=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] LL review of 6020bis-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 17:28:04 -0000 Ladislav Lhotka wrote: > Martin Bjorklund writes: > = > ... > = > > > >> >> 3. It's necessary to clearly separate properties of the da= ta tree > >> >> from properties of XML encoding. For instance, it is an= > >> >> inherent property of a container instance in the data t= ree > >> >> that its children are unordered, or ordered in RPC > >> >> input/output. Yet this is only specified in sec. 7.5.7 = (XML > >> >> Mapping Rules). > >> > > >> > I think this is a property of the XML encoding, not an inherent > >> > property of the container. In JSON, all children are always > >> > unordered. > >> = > >> I assume that data in whatever encoding contribute to the same > >> (conceptual) data tree, so it would be useful to know the properti= es of > >> the latter, such as whether some document order exists (as in XML)= or > >> not (as in JSON). = > > > > Ok. We have two alternatives: > > > > 1) Say that the data tree is unordered (or rather the order is > > implementation specific) > > > > 2) Enforce an order. This would probably be the order that the no= des > > are defined in the module (but keys first) + augments after tha= t. > > The problem is then in what order are the augmented nodes added= ? > > Lexicographically on the module name maybe. > = > Are there any use cases where order is important? I cannot think of > any. Neither can I. The implication is that you can't rely on any specific order when you write your must/when expression. > > Currently we have (1). > = > If we stick to (1) then I think the special ordering rules (keys go > first, RPC input/output has fixed order) should apply only to XML > encoding because presumably it is important there for streaming data,= > and in JSON they cannot be enforced. Agreed. > >> >> Similarly, the namespace of a module and XML namespace that's > >> >> used in XML encoding are IMO two different things (cf. = sec > >> >> 5.3). > >> > > >> > Yes. Do you have any specific edits in mind? > >> = > >> Section 5.3 IMO can't say that "All YANG definitions are specified= > >> within a module that is bound to a particular XML namespace > >> [XML-NAMES],=A0..." because XML namespaces really make sense only = in > >> XML. > > > > I agree that XML namespaces make sense in XML. But why can't we sa= y > > that all definitions are bound to this XML namespace? > = > [XML-NAMES] defines specific ways of how XML namespaces are declared,= > and we use these only in XML encoding but not in general. Agreed. > Or is the problem that you want to have the URI as the "official" > namespace identifier? This is possible although I'd rather avoid usin= g > URIs and prefixes outside XML. No. > >> I'd suggest something like this: > >> = > >> A YANG module defines a namespace that is identified by the mo= dule > >> name. Names of all YANG definitions specified in a module belo= ng to > >> its namespace. > > > > But this text doens't belong to section 5.3. > = > It could belong there if the section is renamed to "Namespaces". IMO = XML > namespaces should only be dealt with in an "XML Encoding" section. Ok. Let me have a look at this. [...] > >> >> - I think deref() could return non-empty nodeset only for > >> >> instance-identifiers because for leafref it's not needed= .= > >> > > >> > Ok...? Do you have any edits in mind? > >> = > >> Remove the third paragraph. Unlike instance-identifier, a leafref > >> *instance* doesn't refer to any nodes. > > > > Ok, I see, I mis-read your original comment. > > > > We have had deref() implemented for several years, and it is mostly= > > used for leafrefs. I really think we should keep it also for > > leafrefs. > = > deref() for instance-identifiers doesn't need a schema (all "normal" > XPath functions don't) whereas for leafrefs the implementation has to= > find the path of the leafref in the corresponding YANG module. This > means that such a function cannot be implemented as an extension to > standard XPath/XSLT processors such as "xsltproc". derived-from() also needs YANG knowledge. > For instance-identifiers this function is indispensable while for > leafrefs it is just an abbreviation, and an alternative expression > without deref() always exists. Agreed. But IMO deref() is a very useful syntactic sugar, as it's meaning is clearer than the unwieldy expanded expression. And it is fairly trivial to expand the deref() expression into the plain XPath alternative. /martin From nobody Wed Aug 26 12:18:23 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6771A1B69 for ; Wed, 26 Aug 2015 12:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwmrB0rEH6L1 for ; Wed, 26 Aug 2015 12:18:20 -0700 (PDT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id 4BB8F1A1A88 for ; Wed, 26 Aug 2015 12:18:20 -0700 (PDT) Received: (qmail 19311 invoked by uid 0); 26 Aug 2015 19:18:18 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy4.mail.unifiedlayer.com with SMTP; 26 Aug 2015 19:18:18 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id 9dJ71r00A2SSUrH01dJAmb; Wed, 26 Aug 2015 19:18:17 -0600 X-Authority-Analysis: v=2.1 cv=GpXRpCFC c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=6PzwTDcoQqoA:10 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=uRRa74qj2VoA:10 a=XGy_LJrRo9pvFte5_ZsA:9 a=IwbviTqQ4vvfJT_8:21 a=2PxcoNywweWTRhDr:21 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=xaRLp62nHEoDByNfINmm7RUMMcET/CJorB1Evxzdf3w=; b=Q0nrTlRY6lY2DZXVuAnq2KAVYobmCP8b1Rf7q6UNArqAzEPu4/DzFz7DWmVP22hW7GIogTVf9pDMLtUlGidFFJTddExgNraNyNdn3BthGVfLV9cDOVWlXM/KgzYUXbAO; Received: from box313.bluehost.com ([69.89.31.113]:53568 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZUgD2-00081c-0j; Wed, 26 Aug 2015 13:18:08 -0600 To: Martin Bjorklund References: <55D53A13.4080505@labn.net> <20150820.095853.255503105278478154.mbj@tail-f.com> <55DD2A43.8070300@labn.net> <20150826.124129.323914665465928199.mbj@tail-f.com> From: Lou Berger X-Enigmail-Draft-Status: N1110 Message-ID: <55DE10EA.1030507@labn.net> Date: Wed, 26 Aug 2015 15:18:02 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150826.124129.323914665465928199.mbj@tail-f.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: rtgwg@ietf.org, netmod@ietf.org, draft-rtgyangdt-rtgwg-device-model@ietf.org Subject: Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 19:18:21 -0000 Martin, On 8/26/2015 6:41 AM, Martin Bjorklund wrote: > Lou Berger wrote: >> Martin, >> Sorry for the delayed response, was away for a bit. Not sure if any of >> this is OBE as just starting to catch up on mail. >> >> On 08/20/2015 03:58 AM, Martin Bjorklund wrote: >>> Lou Berger wrote: >>>> Martin, >>>> >>>> See below. >>>> On 08/19/2015 05:27 AM, Martin Bjorklund wrote: >>>>> Hi, >>>>> >>>>> Lou Berger wrote: > [...] > >>>> Deeper in the hierarchy the path becomes more significant, but you >>>> weren't really questioning this. >>> I am all for significant nodes in the path! >> This is really good/useful to hear. If disagreement is limited to the >> top level node, it's much easier (but not easy ;-) problem to solve. >> >>> My point is that /device >>> is insignificant. >> I think the fundamental discussion here, is who get's to say what's >> significant and we have (at least) two opposing views on this point. >> >> From my standpoint it comes down to how you view full set of models that >> may be seen. From the device view, you might only (or, more likely, >> mostly) see models under /device -- so device doesn't add much value. >> BUT from the controller/NMS/EMS (or whatever you want to call it) view, >> you're likely to see all the models > Agreed, but see below. > >> so /device plays a much more >> significant role in identifying logical model >> organization/understanding. -- That said, I'm much more of a device >> person than an NMS builder, so I'm also willing to trust the opinion of >> folks who are clearly doing significant work on the controller/NMS >> side. > [This was briefly discussed in another mail thread, and I'll repeat it > here.] Thanks. > On the controller, you probably have a list of devices you control > (this is how our NCS works, and how ODL works (I have been told)): > > container devices { > list device { > key name; > // meta-info about the device goes here, things like > // ip-address, port, auth info... > container data { > // all models supported by the devices are "mounted" here > } > } > } > > So on the controller, the path to interface "eth0" on device "foo" > would be: > > /devices/device[name='foo']/data/interfaces/interface[name='eth0'] > > if we also have a top-level "/device" container we'd have: > > /devices/device[name='foo']/data/device/interfaces/interface[name='eth0'] > > > (here you again can see that the "device" node in the device model > doesn't make much sense) if there are siblings, it could still make sense... > > The path is scoped in the system you work with; in the controller it > might be as I illustrated above, in the device it starts with > /interfaces. But then you might also have a > controller-of-controllers. where the path might be: > > /domains/domain[name='bar']/devices/device[name='foo']/data > /interfaces/interface[name='eth0'] > > Pushing all these concepts down into the device model clearly doesn't > help... So, I think it would be good to hear from the openconfig folks on this point. Perhaps they'll respond via e-mail, perhaps it'll have to wait for the interim... Thanks, Lou > > /martin > From nobody Wed Aug 26 12:33:27 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 154911A8AF9 for ; Wed, 26 Aug 2015 12:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uerapSgE9wJc for ; Wed, 26 Aug 2015 12:33:25 -0700 (PDT) Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by ietfa.amsl.com (Postfix) with SMTP id AFFF01A8F46 for ; Wed, 26 Aug 2015 12:33:24 -0700 (PDT) Received: (qmail 2605 invoked by uid 0); 26 Aug 2015 19:33:24 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy1.mail.unifiedlayer.com with SMTP; 26 Aug 2015 19:33:24 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id 9XZB1r00F2SSUrH01XZEz2; Wed, 26 Aug 2015 13:33:23 -0600 X-Authority-Analysis: v=2.1 cv=EbVbHpWC c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=6PzwTDcoQqoA:10 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=uRRa74qj2VoA:10 a=t4kZfSXurUzZjt8LGJ0A:9 a=Z9LhhS483jpqG5uP:21 a=deikZXeXPrg3bohH:21 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=3103hrJUdnj9XJiCZB4nNiYteJjriR/l6ac4l3gjujY=; b=EKdaLgujzOaeZq5UoHPO+4ZIgWmQsFSj9snP6BrjVmVOtRgbOFO9eiT+xdCSKHnkussHMW4f8XTcOrsDuU5HB88khbe+X5lDCcCDO0FAhtODR+DsNjP4MQgDPfuIQVqb; Received: from box313.bluehost.com ([69.89.31.113]:54627 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZUgRb-0002tt-E9; Wed, 26 Aug 2015 13:33:11 -0600 To: Nadeau Thomas , "Acee Lindem (acee)" References: <20150826.122600.1110046163132211535.mbj@tail-f.com> <19CCF9F5-87F1-4C41-8151-18AD36D98CE6@lucidvision.com> <20150826.140918.2163222167742824482.mbj@tail-f.com> From: Lou Berger X-Enigmail-Draft-Status: N1110 Message-ID: <55DE1471.40305@labn.net> Date: Wed, 26 Aug 2015 15:33:05 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: "draft-rtgyangdt-rtgwg-device-model@ietf.org" , "netmod@ietf.org" , "rtgwg@ietf.org" Subject: Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 19:33:26 -0000 Tom, On 8/26/2015 9:34 AM, Nadeau Thomas wrote: > ... > This is exactly what I want to get on the table. So taking a step back, perhaps there is a YANG language question at the heart of this discussion. I think we're seeing cases where the same data model is useful in multiple cases/places. The example I like to use (although I know others disagree with the example) is the case of PE/CE config information, where some of the exact same information may end up on the CE and PE devices as well as the L3 service model. In this case we'd like a core model to be "included" (or "linked") into two larger models. Importantly, I'm referring to doing this as part of model definition - not at server/device run time. This is important for the pre-provisioning case. It is my understanding that there is no way to really do this in a general and extensible way (including allowing for augmentations) today. If there was such support, I do think we'd be saying that we'd like the existing models to support this mechanism rather than our current proposal of being relocated . Lou (BTW this is my opinion, not speaking for the DT.) From nobody Wed Aug 26 12:48:09 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB0491A01F4 for ; Wed, 26 Aug 2015 12:48: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 1owgDSYfvsft for ; Wed, 26 Aug 2015 12:48:06 -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 9B5851A0AFE for ; Wed, 26 Aug 2015 12:48:05 -0700 (PDT) Received: by laba3 with SMTP id a3so126925873lab.1 for ; Wed, 26 Aug 2015 12:48:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=nndxeFnk5/vLCWir+CpbkRUL8s9WKBko4ibA8omo/AI=; b=B6w5E1nYcsHtgBjyFOBfqbaa4asee7Fmkrfk2guqqMfVKal9GVkYMElxVhFCA1q2HG SAdrFG8WaAT546Fs2DSnQ0HfVvdhldzeUX0oDXVHJ529OulPVk3diVVhWJbkpMlzLhbv XRhNaQjSxoYFWJ8sOGaE9aS5Pa+rs/6NbHtw/udz4SB2ZNF9dLtGAmffHJ2IdFjOr2a1 XK72sG57B8nxHoTmMQAsV+4hx1c8gdPXbUvHcia6KideB09PN/ez53dNkbOllmLFnfWw LVGApQUaSTTrgokf0EphYVqnm9rV443xW4SqzgaIzCKwBgO1L0zro9lCFURnZ5+yG8vc Y7rQ== X-Gm-Message-State: ALoCoQn5uiKQ603l0zmm8vdcyv9CJQy1V3wLZ+IhBAg1Xy782K4xvgEtgK8V6AScmPJg/vRVRnOL MIME-Version: 1.0 X-Received: by 10.112.154.106 with SMTP id vn10mr436769lbb.38.1440618484109; Wed, 26 Aug 2015 12:48:04 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Wed, 26 Aug 2015 12:48:03 -0700 (PDT) In-Reply-To: <55DE1471.40305@labn.net> References: <20150826.122600.1110046163132211535.mbj@tail-f.com> <19CCF9F5-87F1-4C41-8151-18AD36D98CE6@lucidvision.com> <20150826.140918.2163222167742824482.mbj@tail-f.com> <55DE1471.40305@labn.net> Date: Wed, 26 Aug 2015 12:48:03 -0700 Message-ID: From: Andy Bierman To: Lou Berger Content-Type: multipart/alternative; boundary=089e0122af2a00b042051e3c21ca Archived-At: Cc: "netmod@ietf.org" , "draft-rtgyangdt-rtgwg-device-model@ietf.org" , "rtgwg@ietf.org" Subject: Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 19:48:07 -0000 --089e0122af2a00b042051e3c21ca Content-Type: text/plain; charset=UTF-8 On Wed, Aug 26, 2015 at 12:33 PM, Lou Berger wrote: > Tom, > > On 8/26/2015 9:34 AM, Nadeau Thomas wrote: > > ... > > This is exactly what I want to get on the table. > > So taking a step back, perhaps there is a YANG language question at the > heart of this discussion. I think we're seeing cases where the same > data model is useful in multiple cases/places. The example I like to > use (although I know others disagree with the example) is the case of > PE/CE config information, where some of the exact same information may > end up on the CE and PE devices as well as the L3 service model. In > this case we'd like a core model to be "included" (or "linked") into two > larger models. Importantly, I'm referring to doing this as part of > model definition - not at server/device run time. This is important for > the pre-provisioning case. > > It is my understanding that there is no way to really do this in a > general and extensible way (including allowing for augmentations) > today. If there was such support, I do think we'd be saying that we'd > like the existing models to support this mechanism rather than our > current proposal of being relocated . > > If you are talking about schema reuse, then YANG has groupings as the solution. But it seems you are talking about YANG Mount -- the ability to have a subtree on server X represent a different subtree on server Y. On the controller the 'mount point' is not the actual data root (as Martin has explained). On the NE, the data models are in their real location On the controller they are not. This can be done with an 'anyxml' hack today. It would be better to have real YANG support for this very basic use-case for YANG Mount. > Lou > (BTW this is my opinion, not speaking for the DT.) > > Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --089e0122af2a00b042051e3c21ca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Aug 26, 2015 at 12:33 PM, Lou Berger <lberger@labn.net><= /span> wrote:
Tom,

On 8/26/2015 9:34 AM, Nadeau Thomas wrote:
> ...
>=C2=A0 =C2=A0 =C2=A0 =C2=A0This is exactly what I want to get on the ta= ble.

So taking a step back, perhaps there is a YANG language question at the
heart of this discussion.=C2=A0 I think we're seeing cases where the sa= me
data model is useful in multiple cases/places.=C2=A0 The example I like to<= br> use (although I know others disagree with the example) is the case of
PE/CE config information, where some of the exact same information may
end up on the CE and PE devices as well as the L3 service model.=C2=A0 In this case we'd like a core model to be "included" (or "l= inked") into two
larger models.=C2=A0 Importantly, I'm referring to doing this as part o= f
model definition - not at server/device run time.=C2=A0 This is important f= or
the pre-provisioning case.

It is my understanding that there is no way to really do this in a
general and extensible way (including allowing for augmentations)
today.=C2=A0 If there was such support, I do think we'd be saying that = we'd
like the existing models to support this mechanism rather than our
current proposal of being relocated .


If you are talking about schema reuse,= then YANG has groupings as the solution.
But it seems you are ta= lking about YANG Mount -- the ability to have a
subtree on server= X represent a different subtree on server Y.=C2=A0 On the controller
=
the 'mount point' is not the actual data root (as Martin has e= xplained).
On the NE, the data models are in their real location = =C2=A0On the controller they are not.

This can be = done with an 'anyxml' hack today.
It would be better to h= ave real YANG support for this very basic
use-case for YANG Mount= .


=C2=A0
Lou
(BTW this is my opinion, not speaking for the DT.)



Andy
=C2=A0

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

--089e0122af2a00b042051e3c21ca-- From nobody Wed Aug 26 15:29:52 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7F71B3406 for ; Wed, 26 Aug 2015 15:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYhw8U9nqPk2 for ; Wed, 26 Aug 2015 15:29:49 -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 0CF741B3369 for ; Wed, 26 Aug 2015 15:29:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9177; q=dns/txt; s=iport; t=1440628189; x=1441837789; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=YEeO3+YF/dyunI6dB2WMx6jnreuMwaMnDJF4tdiZxpo=; b=HqmWTsxkWlZCqeZE8SV/93L8RUEGg4szJYvT7PPtAHB07EwIRlNn7ckt g7wK/25INmBF0XU6BJCrv6qCn0i+7bl/J+E6+NEbFn0LQwy8n/c/h7C0H ooUgH2QS17KMspvPpma2ZqT09j5CSF1igON6m7Efi6IR3FAWR6c16088a 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AeBQARPd5V/4sNJK1dgxtUaQa9e4FuCoUxSgKBNjoSAQEBAQEBAYEKhCMBAQEDAQEBAWsLBQcEAgEIEQQBAQEKHQcnCxQJCAIEAQ0FCIgeCA3JHgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEhEWHFoQ/GjEHBoMSgRQFjGs5hH2DGAGOO5Upg2smg39xgQclHIEFAQEB X-IronPort-AV: E=Sophos;i="5.17,419,1437436800"; d="scan'208";a="181736767" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-2.cisco.com with ESMTP; 26 Aug 2015 22:29:48 +0000 Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t7QMTl2m030338 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 26 Aug 2015 22:29:47 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 26 Aug 2015 17:29:47 -0500 Received: from xhc-aln-x13.cisco.com (173.36.12.87) by xch-rcd-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Wed, 26 Aug 2015 17:29:47 -0500 Received: from xmb-rcd-x05.cisco.com ([169.254.15.111]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0248.002; Wed, 26 Aug 2015 17:29:46 -0500 From: "Alexander Clemm (alex)" To: Ladislav Lhotka , =?iso-8859-1?Q?Martin_Bj=F6rklund?= Thread-Topic: [netmod] Y34 - root node Thread-Index: AQHQzfwQhTp8SpZgRU2/JK7T0ppEc536tNgA//+74lSAAFbtgIAAz1DkgADCswCABfPJgIAC/IuAgAAMEQCAAKj6AIAAC1YAgAC+7gCAC50MgIAABoyAgAEhX4CAAA01gIABIKqAgAA8e4CAAdMvAIAADywAgAAMDoCACAd/8A== Date: Wed, 26 Aug 2015 22:29:46 +0000 Message-ID: References: <20150820.101533.1535137181522006328.mbj@tail-f.com> <55D7148C.6090508@cisco.com> <20150821.150158.491063432174006492.mbj@tail-f.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.204.135] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y34 - root node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 22:29:51 -0000 Coming late to the thread. A couple of comments to add on to and/or respond to others: - Mounting IMHO is a good way to address the requirement for various paths.= As has been been mentioned, this has been successfully used e.g. for Open= Daylight and the use case of mounting / referring to information from remo= te devices in the context of one consolidated network inventory and topolog= y model that is accessed by clients and applications on top of ODL. =20 - The peer-mount draft was aimed at mounting subtrees from remote systems. = There is definitely also the possibility to generalize this for aliasing e= ven within the same system (as discussed here). However, as Eric points ou= t there is no reason to restrict such a capability to the boundaries of a s= ingle system. =20 - As Martin mentioned, clearly by allowing to mount you are decoupling sche= ma information and instance population. Regarding the issue of validation,= this can be addressed by several ways. In the mount draft, our answer has= been that every piece of data has an authoritative owner - the server from= which the data is mounted. This is where validation and enforcing of inte= grity constraints needs to occur. It is possible for an integrity constra= ints to refer to data that has been mounted, but the enforcement / validati= on is always the responsibility of the local "authoritative" server. In ot= her words, mounted information provides an additional, alternative view on = data without replacing/substituting the original instance, and possibly res= tricting the types of operations that it can be subjected to (e.g. retrieva= l only). =20 --- Alex =20 -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav Lhotka Sent: Friday, August 21, 2015 6:45 AM To: Martin Bj=F6rklund Cc: netmod@ietf.org Subject: Re: [netmod] Y34 - root node > On 21 Aug 2015, at 15:01, Martin Bjorklund wrote: >=20 > Robert Wilton wrote: >> Hi Martin, >>=20 >> On 20/08/2015 09:15, Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> On Wed, Aug 19, 2015 at 4:25 AM, Martin Bjorklund >>>> wrote: >>>>=20 >>>>> Robert Wilton wrote: >>>>>>=20 >>>>>> On 18/08/2015 18:22, Andy Bierman wrote: >>>>>>> This is how languages like SMIv2 and YANG work. >>>>>>> A conceptual object is given a permanent "home" within the tree=20 >>>>>>> of object identifiers. >>>>>>> Moving data is very expensive, since any clients working with=20 >>>>>>> the old data will break as soon as the data is moved. >>>>>>>=20 >>>>>>> I am not convinced the IETF can or should come up with a set of =20 >>>>>>> containers that covers every possible topic that can be modeled=20 >>>>>>> in YANG. >>>>>> I mostly agree, but having some more structure/advice as to where=20 >>>>>> to place YANG modules may be helpful. I'm thinking more along=20 >>>>>> the lines of broad categories rather than precise locations. >>>>> +1 >>>>>=20 >>>>>>> If someone wants to builds a YANG controller node that is manag= ing >>>>>>> the configuration for a network of devices then wouldn't they w= ant >>>>>>> a particular device's interface configuration to be located >>>>>>> somewhere like /network/device//interfaces/interfa= ce? >>>>>>> Ideally, they would be able to use the same YANG definitions th= at >>>>>>> are defined for /interfaces/ but root them relative to >>>>>>> /network/device//. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Yes -- some of us (like Martin) have pointed this out many times. >>>>>>> The "device" container on an NE does not help at all wrt/=20 >>>>>>> aggregation on a controller. "/device" or "/" work the same for=20 >>>>>>> this purpose. >>>>> Actually, I would argue that / works better. On the controller,=20 >>>>> you probably have a list of devices you control (this is how our=20 >>>>> NCS works, and how ODL works (I have been told)): >>>>>=20 >>>>> container devices { >>>>> list device { >>>>> key name; >>>>> // meta-info about the device goes here, things like >>>>> // ip-address, port, auth info... >>>>> container data { >>>>> // all models supported by the devices are "mounted" here >>>>> } >>>>> } >>>>> } >>>>>=20 >>>>> So on the controller, the path to interface "eth0" on device "foo" >>>>> would be: >>>>>=20 >>>>> =20 >>>>> /devices/device[name=3D'foo']/data/interfaces/interface[name=3D'eth0'= ] >>>>>=20 >>>>> if we also have a top-level "/device" container we'd have: >>>>>=20 >>>>> =20 >>>>> /devices/device[name=3D'foo']/data/device/interfaces/interface[name= =3D >>>>> 'eth0'] >>>>>=20 >>>>>> What would the real resource location for=20 >>>>>> "/network/device//interfaces/interface" be? >>>>> I don't think there is such a thing as a "real" location. The=20 >>>>> path is scoped in the system you work with; in the controller it=20 >>>>> might be as I illustrated above, in the device it starts with=20 >>>>> /interfaces, but in a controller-of-controllers it might be: >>>>>=20 >>>>> /domains/domain[name=3D'bar']/devices/device[name=3D'foo']/data >>>>> /interfaces/interface[name=3D'eth0'] >>>>>=20 >>>>> Currently we have a proprietary way of "relocating" YANG modules,=20 >>>>> and ODL has its "mount", and I think Andy has some other=20 >>>>> mechanism. Maybe the time has come to standardize how mount=20 >>>>> works, and maybe then also standardize the list of devices in a contr= oller model. >>>>>=20 >>>>>=20 >>>> +1 >>>>=20 >>>> We just need to standardize a "docroot within a docroot". >>>> This is not relocation of subtrees within the datastore, this is=20 >>>> just mounting a datastore somewhere within a parent datastore. >>>>=20 >>>> In YANG validation terms, you simply adjust the docroot to the=20 >>>> nested mount point, and the replicated datastore can be used as if=20 >>>> it were stand-alone. >>>> This would allow any sort of encapsulation of datastores and not=20 >>>> add any data model complexity to devices which do not have virtual=20 >>>> servers (most of them). >>> Compared to the mount draft, I would like to decouple the schema=20 >>> information from the instance population mechanism. I.e., I'd like=20 >>> a mechanism that simply defines the schema, not necessarily how the=20 >>> data is populated (in the mount draft data was fetched from a remote=20 >>> server, but IMO that is just one of several use cases). >> Yes, I agree that these could/should be decoupled. Although I note=20 >> that the mount draft does also allow for local mounts, although this=20 >> does not seem to be intended to be the mainline case. >>=20 >>>=20 >>> I can think of two ways to do this. >>>=20 >>> 1) Your "ycx:root" statement. This is open-ended, so we could do: >>>=20 >>> list logical-element { >>> key name; >>> leaf name { ... } >>> yang-root true; >>> } >>>=20 >>> From a schema perspective, any top-level node from any data model >>> could be used within the logical-element list. >>>=20 >>> 2) Cherry-picking: >>>=20 >>> list logical-element { >>> key name; >>> leaf name { ... } >>> mount if:interfaces; >>> mount sys:system; >>> ... >>> } >> I think that that it makes the overall schema more useful if it=20 >> explicitly states what schema is used for the mounted nodes, although=20 >> possibly a wildcard mount could still be allowed. >>=20 >> I wasn't quite sure how it would work if you wanted to mount a schema=20 >> that has augmentations. Would you have to list all supported=20 >> augmentations in the mount point as well? Otherwise you wouldn't=20 >> know what the full schema is. >=20 > My idea is that you mount the top-level node, and that means that=20 > everything below it is "copied" into the new location. I.e.,=20 > augmentations to the subtree are also copied. So you would not mount=20 > any augmentations (that's why the syntax is mount ). But what about normal modules that refer to nodes in the mounted module? Th= eir XPath expressions and leafrefs would be incorrect. I think they must be mounted to the same root, too. Lada >=20 >=20 > /martin >=20 >=20 >=20 >>=20 >> Thanks, >> Rob >>=20 >>=20 >>>=20 >>> Or maybe combine them into one "mount" statement: >>>=20 >>> mount *; // allow any top-level node >>> mount sys:system; // allow this specific top-level node >>>=20 >>>=20 >>>=20 >>> /martin >>>=20 >>> . >>>=20 >>=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Aug 26 23:26:51 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 145181B342E for ; Wed, 26 Aug 2015 23:26: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 EoiKwyVMuWgT for ; Wed, 26 Aug 2015 23:26: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 9E8A11B3465 for ; Wed, 26 Aug 2015 23:26:49 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id E469C1AE0973; Thu, 27 Aug 2015 08:26:47 +0200 (CEST) Date: Thu, 27 Aug 2015 08:27:06 +0200 (CEST) Message-Id: <20150827.082706.86671891927608851.mbj@tail-f.com> To: alex@cisco.com From: Martin Bjorklund In-Reply-To: References: <20150821.150158.491063432174006492.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Y34 - root node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 06:26:51 -0000 "Alexander Clemm (alex)" wrote: > - As Martin mentioned, clearly by allowing to mount you are > decoupling schema information and instance population. Regarding > the issue of validation, this can be addressed by several ways. I think that the mount point effectively works as a 'chroot' for all mounted data models in the mount point. This means that if ietf-interfaces and ietf-routing are mounted under /devices/device/data, all XPath expressions and leafref paths and instance-identifiers in these models are evaluated in a chrooted environment where their '/' is set to /device/device[name='...']/data. This is how we implement validation for such modules in our NCS (manager product). In an implementation that actually does not store the data locally, but fetches it from a remote device (like the original mount proposal), it is fine to push also validation to the remote node. [maybe mount is not a good name for this generalized thing; this term might make you believe that the data has to be provided by some other server.] /martin From nobody Wed Aug 26 23:42:56 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3C831B37FC for ; Wed, 26 Aug 2015 23:42: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 7vnPcn1CJbqU for ; Wed, 26 Aug 2015 23:42:53 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D48251B3800 for ; Wed, 26 Aug 2015 23:42: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 9F91814D3; Thu, 27 Aug 2015 08:42:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id GyrDz5t1XRFp; Thu, 27 Aug 2015 08:42:50 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 27 Aug 2015 08:42:49 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id D276720054; Thu, 27 Aug 2015 08:42:49 +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 075VOMz_ziiI; Thu, 27 Aug 2015 08:42:48 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 936A92004E; Thu, 27 Aug 2015 08:42:46 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A85B6365A0B0; Thu, 27 Aug 2015 08:42:42 +0200 (CEST) Date: Thu, 27 Aug 2015 08:42:42 +0200 From: Juergen Schoenwaelder To: "t. petch" Message-ID: <20150827064240.GB87367@elstar.local> Mail-Followup-To: "t. petch" , Martin Bjorklund , netmod@ietf.org References: <55D36473.90609@cisco.com> <55D45CAF.2070605@cisco.com> <20150819.132555.871710491924929960.mbj@tail-f.com> <013601d0da9b$907f6b00$4001a8c0@gateway.2wire.net> <20150823170415.GA77197@elstar.local> <012901d0e01e$12c22b20$4001a8c0@gateway.2wire.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <012901d0e01e$12c22b20$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Y34 - root node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 06:42:55 -0000 On Wed, Aug 26, 2015 at 05:41:29PM +0100, t. petch wrote: > ----- Original Message ----- > From: "Juergen Schoenwaelder" > To: "t. petch" > Cc: ; "Martin Bjorklund" ; > > Sent: Sunday, August 23, 2015 6:04 PM > > > On Wed, Aug 19, 2015 at 05:24:41PM +0100, t. petch wrote: > > > > > The current model is a flat architecture of hundreds (or thousands) > of > > > modules each with their own top level nodes, namespace, namespace > name, > > > prefix etc. (This is quite different to SMI with its hierarchy but > that > > > probably is only significant to those who have spent 20 years with > SMI). > > > > This is most likely a wrong perception. There are basically only two > > locations where SNMP modules are registered in the IETF: under mib-2 > > and under transmission (yes there are a few exceptions but overall in > > number they do not matter). There are close to 240 MIB modules below > > mib-2 and about 50 MIB modules below transmission. > > Juergen > > I know what you mean, that the MIB module tree is somewhat fasciated, > but there is still one root, from which an obvious, absolute OID can be > used to identify uniquely any MIB module (or in some contexts a > relative one, relative to transmission or mib 2). If SMI did have > constraints, then there would not be an issue of how to express them, > nor would there be any question of mounting a module elsewhere for > whatever > reason (which then creates problems for the references in the > constraints). While SMIv2 does not have something like MUST and WHEN expressions, it still does have references between model elements. Prime example: ifTabel got augmented by ifXTable registered in a very different location. It is a major mis-conception that the OID tree is relevant; what is relevant are relationships between conceptual tables. > A flat sea of YANG modules is different; I haven't counted lately > how many top level nodes I have seen but it is a lot and when I see > people wanting to organise YANG modules into a tree, I wonder if > they are trying to recreate an SMI-like tree and my reaction is that > this is not SMI! There is no point in organizing them into a tree. There simply is no universal forever stable tree. When SMIv2 started, people thought such a tree would evolve and it was later recognized that this is an illusion and we ended up registering almost everything under mib-2 or transmission. > The flat sea of YANG modules brings a different set of issues and I > am unsure what they are; This is main problem I have. What the heck is the problem we are trying to fix? > I understand what is involved with the references in constraints, I > can see that there will be a lot of namespaces and prefixes and can > speculate about what that will bring but what it means to have so > many top level nodes, I do not know. Having 200+ MIB modules registered below mib-2 has not been a problem as far as I know. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Aug 27 04:13:33 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D20C81B33B8 for ; Thu, 27 Aug 2015 04:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxp0L6S_ZHcW for ; Thu, 27 Aug 2015 04:13:29 -0700 (PDT) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id 6B96D1B2CC7 for ; Thu, 27 Aug 2015 04:13:29 -0700 (PDT) Received: (qmail 23553 invoked by uid 0); 27 Aug 2015 11:13:28 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy8.mail.unifiedlayer.com with SMTP; 27 Aug 2015 11:13:28 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id 9nDJ1r00b2SSUrH01nDMAu; Thu, 27 Aug 2015 05:13:26 -0600 X-Authority-Analysis: v=2.1 cv=C6F6l2/+ c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=4g2epv4a4k0A:10 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=uRRa74qj2VoA:10 a=48vgC7mUAAAA:8 a=AM4U9HTYUM337l1cg80A:9 a=TzunZr6NLibGDXDZ:21 a=qVhNWpL7OwBvqPxE:21 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=SpiqKJ51Q9iREDwWM/0ub7IN00ZdmZPa9P6Y7sM2hSg=; b=cBzHyc9aGSJcbDJdotmlSVMz5S5ngWbuN7aqi717goIobIKGO+p1o141EQFE5mK/kjB3S/VCBx56IRcqsKMhmivMrzAksH1MfaIydegnF4X63xggwpShrgbJIA6b7qkq; Received: from box313.bluehost.com ([69.89.31.113]:33521 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZUv7Q-0004aT-9h; Thu, 27 Aug 2015 05:13:20 -0600 Message-ID: <55DEF0CC.10302@labn.net> Date: Thu, 27 Aug 2015 07:13:16 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Andy Bierman References: <20150826.122600.1110046163132211535.mbj@tail-f.com> <19CCF9F5-87F1-4C41-8151-18AD36D98CE6@lucidvision.com> <20150826.140918.2163222167742824482.mbj@tail-f.com> <55DE1471.40305@labn.net> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: "netmod@ietf.org" , "draft-rtgyangdt-rtgwg-device-model@ietf.org" , "rtgwg@ietf.org" Subject: Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 11:13:32 -0000 On 08/26/2015 03:48 PM, Andy Bierman wrote: > > > On Wed, Aug 26, 2015 at 12:33 PM, Lou Berger > wrote: > > Tom, > > On 8/26/2015 9:34 AM, Nadeau Thomas wrote: > > ... > > This is exactly what I want to get on the table. > > So taking a step back, perhaps there is a YANG language question at the > heart of this discussion. I think we're seeing cases where the same > data model is useful in multiple cases/places. The example I like to > use (although I know others disagree with the example) is the case of > PE/CE config information, where some of the exact same information may > end up on the CE and PE devices as well as the L3 service model. In > this case we'd like a core model to be "included" (or "linked") into two > larger models. Importantly, I'm referring to doing this as part of > model definition - not at server/device run time. This is important for > the pre-provisioning case. > > It is my understanding that there is no way to really do this in a > general and extensible way (including allowing for augmentations) > today. If there was such support, I do think we'd be saying that we'd > like the existing models to support this mechanism rather than our > current proposal of being relocated . > > > If you are talking about schema reuse, then YANG has groupings as the > solution. My understanding is that the usage scope of groupings is pretty limited and not really suitable for complex (sub)tree/module representation. Also groupings can't be augmented > But it seems you are talking about YANG Mount -- the ability to have a > subtree on server X represent a different subtree on server Y. On the > controller > the 'mount point' is not the actual data root (as Martin has explained). > On the NE, the data models are in their real location On the controller > they are not. > > This can be done with an 'anyxml' hack today. > It would be better to have real YANG support for this very basic > use-case I think finding a yang-based solution (to reuse) would be helpful. Lou > for YANG Mount. > > > > > Lou > (BTW this is my opinion, not speaking for the DT.) > > > > Andy > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > From nobody Thu Aug 27 04:28:00 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEA0F1A872E for ; Thu, 27 Aug 2015 04:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6uNTQ1ZTmUS for ; Thu, 27 Aug 2015 04:27:56 -0700 (PDT) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 7440C1A8AF9 for ; Thu, 27 Aug 2015 04:27:56 -0700 (PDT) Received: (qmail 28181 invoked by uid 0); 27 Aug 2015 11:27:54 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy5.mail.unifiedlayer.com with SMTP; 27 Aug 2015 11:27:54 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id 9nTn1r00N2SSUrH01nTqxV; Thu, 27 Aug 2015 05:27:53 -0600 X-Authority-Analysis: v=2.1 cv=EbVbHpWC c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=4g2epv4a4k0A:10 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=uRRa74qj2VoA:10 a=M5kpELkfPMM3tnWEtvsA:9 a=pILNOxqGKmIA:10 a=IGX-_eAHJBQA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=kgxhwXw9KxwvhrTh4NwR/g4k/950CKOyWIaJ8mT4eBc=; b=BD0vCZk3ONNFvGh63LdXAjEIl7omwjzR0ftQiaQ0bk7k0/v7R9uAzAoSvspQINcVP5Sn+yN6tiQnEJBIgaiIZLgn9B8gLmSIsXFNnyGckuBIkygfFvIH+MGShYE8v/v5; Received: from box313.bluehost.com ([69.89.31.113]:34831 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZUvLP-0007LS-FQ; Thu, 27 Aug 2015 05:27:48 -0600 Message-ID: <55DEF430.40801@labn.net> Date: Thu, 27 Aug 2015 07:27:44 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Juergen Schoenwaelder References: <55D36473.90609@cisco.com> <55D45CAF.2070605@cisco.com> <20150819.132555.871710491924929960.mbj@tail-f.com> <013601d0da9b$907f6b00$4001a8c0@gateway.2wire.net> <20150823170415.GA77197@elstar.local> <012901d0e01e$12c22b20$4001a8c0@gateway.2wire.net> <20150827064240.GB87367@elstar.local> In-Reply-To: <20150827064240.GB87367@elstar.local> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Y34 - root node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 11:27:59 -0000 On 08/27/2015 02:42 AM, Juergen Schoenwaelder wrote: >> The flat sea of YANG modules brings a different set of issues and I >> > am unsure what they are; > > This is main problem I have. What the heck is the problem we are trying > to fix? > The first, but not only problem, is today's ~200 top level models (looking at current RFCs and I-Ds) with little apparent organization or inter-relationship. Lou From nobody Thu Aug 27 05:23:41 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6751A1A88BD for ; Thu, 27 Aug 2015 05:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UEHqTxz9EoM for ; Thu, 27 Aug 2015 05:23:37 -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 64EDE1A19E3 for ; Thu, 27 Aug 2015 05:23:36 -0700 (PDT) Received: by labns7 with SMTP id ns7so11282593lab.0 for ; Thu, 27 Aug 2015 05:23:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=dCXt3sc1gVLmKOFaG77rFEOWa+9ekjbqpErBYDTar1A=; b=YnKHrmFXY1aKGbWbUjcx5PEoUZhGOg4trGzVg8DbtrbaVB6KprGtpwRfP14Lo+CiON IhoXMM0YmXKuPXtCno4pMaQ82RNuvW2RjBnjToI7DsntASWR/AzOWjwi36XjQtB1FMYA Qnt1B7QQ8WGU1zPRYMiJjxLB1sCt/Xm7esr2tfMCcz08N0EkrEo23XLtygNDFuLERVTF rd/jXGima/gYMCBwGluOg6Xfvx/xH5E7KcE4nM51U07B/TtzQ3mXc2Ub9RmNPO2SGF97 TH2q1ui3cPCSKzabifoHQREyHGqf0dAx4fLaCl3aunFE5pcU4RwpD9JAXL/8Y36ugNSu P0TA== X-Gm-Message-State: ALoCoQk53ZIsF54Q3tPQ9snukCOrcDuLKTKMvaYL+bChRQAq4XH62C3QMTnW9F6K1Mr3ws7wLJT7 MIME-Version: 1.0 X-Received: by 10.112.85.3 with SMTP id d3mr2048064lbz.33.1440678214618; Thu, 27 Aug 2015 05:23:34 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Thu, 27 Aug 2015 05:23:34 -0700 (PDT) In-Reply-To: <20150827064240.GB87367@elstar.local> References: <55D36473.90609@cisco.com> <55D45CAF.2070605@cisco.com> <20150819.132555.871710491924929960.mbj@tail-f.com> <013601d0da9b$907f6b00$4001a8c0@gateway.2wire.net> <20150823170415.GA77197@elstar.local> <012901d0e01e$12c22b20$4001a8c0@gateway.2wire.net> <20150827064240.GB87367@elstar.local> Date: Thu, 27 Aug 2015 05:23:34 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , "t. petch" , Martin Bjorklund , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a1134946c37e75d051e4a09f4 Archived-At: Subject: Re: [netmod] Y34 - root node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 12:23:39 -0000 --001a1134946c37e75d051e4a09f4 Content-Type: text/plain; charset=UTF-8 On Wed, Aug 26, 2015 at 11:42 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Wed, Aug 26, 2015 at 05:41:29PM +0100, t. petch wrote: > > ----- Original Message ----- > > From: "Juergen Schoenwaelder" > > To: "t. petch" > > Cc: ; "Martin Bjorklund" ; > > > > Sent: Sunday, August 23, 2015 6:04 PM > > > > > On Wed, Aug 19, 2015 at 05:24:41PM +0100, t. petch wrote: > > > > > > > The current model is a flat architecture of hundreds (or thousands) > > of > > > > modules each with their own top level nodes, namespace, namespace > > name, > > > > prefix etc. (This is quite different to SMI with its hierarchy but > > that > > > > probably is only significant to those who have spent 20 years with > > SMI). > > > > > > This is most likely a wrong perception. There are basically only two > > > locations where SNMP modules are registered in the IETF: under mib-2 > > > and under transmission (yes there are a few exceptions but overall in > > > number they do not matter). There are close to 240 MIB modules below > > > mib-2 and about 50 MIB modules below transmission. > > > > Juergen > > > > I know what you mean, that the MIB module tree is somewhat fasciated, > > but there is still one root, from which an obvious, absolute OID can be > > used to identify uniquely any MIB module (or in some contexts a > > relative one, relative to transmission or mib 2). If SMI did have > > constraints, then there would not be an issue of how to express them, > > nor would there be any question of mounting a module elsewhere for > > whatever > > reason (which then creates problems for the references in the > > constraints). > > While SMIv2 does not have something like MUST and WHEN expressions, it > still does have references between model elements. Prime example: > ifTabel got augmented by ifXTable registered in a very different > location. It is a major mis-conception that the OID tree is relevant; > what is relevant are relationships between conceptual tables. > > > A flat sea of YANG modules is different; I haven't counted lately > > how many top level nodes I have seen but it is a lot and when I see > > people wanting to organise YANG modules into a tree, I wonder if > > they are trying to recreate an SMI-like tree and my reaction is that > > this is not SMI! > > There is no point in organizing them into a tree. There simply is no > universal forever stable tree. When SMIv2 started, people thought such > a tree would evolve and it was later recognized that this is an > illusion and we ended up registering almost everything under mib-2 or > transmission. > > > The flat sea of YANG modules brings a different set of issues and I > > am unsure what they are; > > This is main problem I have. What the heck is the problem we are trying > to fix? > > > I understand what is involved with the references in constraints, I > > can see that there will be a lot of namespaces and prefixes and can > > speculate about what that will bring but what it means to have so > > many top level nodes, I do not know. > > Having 200+ MIB modules registered below mib-2 has not been a problem > as far as I know. > > The only thing the same between SMIv2 and YANG here is age-old question of how should we care about "dumb" tools that are not very schema-aware. With YANG, the data related to "foo" can actually be located under /some/path/to/foo. I agree with you that for a programmatic interface, the location is not at all important, but to a human typing URLs into a browser, it will be important. I don't see the 6 modules that have already been published so far in RFCs as the problem. I suggest focusing on the 194 modules that have not been published. Should the IETF spend a year or two debating the ONE TRUE PERFECT uber-tree? 6 months? How long will it take for all interested vendors to agree where every little thing goes, before starting on any of it. > /js > > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a1134946c37e75d051e4a09f4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Aug 26, 2015 at 11:42 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Wed, Aug 26, 2015 at 05:41:29PM +0100, t. petch = wrote:
> ----- Original Message -----
> From: "Juergen Schoenwaelder" <j.schoenwaelder@jacobs-university.de><= br> > To: "t. petch" <ie= tfc@btconnect.com>
> Cc: <rwilton@cisco.com>= ; "Martin Bjorklund" <mbj@ta= il-f.com>;
> <netmod@ietf.org>
> Sent: Sunday, August 23, 2015 6:04 PM
>
> > On Wed, Aug 19, 2015 at 05:24:41PM +0100, t. petch wrote:
> >
> > > The current model is a flat architecture of hundreds (or tho= usands)
> of
> > > modules each with their own top level nodes, namespace, name= space
> name,
> > > prefix etc.=C2=A0 (This is quite different to SMI with its h= ierarchy but
> that
> > > probably is only significant to those who have spent 20 year= s with
> SMI).
> >
> > This is most likely a wrong perception. There are basically only = two
> > locations where SNMP modules are registered in the IETF: under mi= b-2
> > and under transmission (yes there are a few exceptions but overal= l in
> > number they do not matter). There are close to 240 MIB modules be= low
> > mib-2 and about 50 MIB modules below transmission.
>
> Juergen
>
> I know what you mean, that the MIB module tree is somewhat fasciated,<= br> > but there is still one root, from which an obvious, absolute OID can b= e
> used to identify uniquely any MIB module (or in some contexts a
> relative one, relative to transmission or mib 2).=C2=A0 If SMI did hav= e
> constraints, then there would not be an issue of how to express them,<= br> > nor would there be any question of mounting a module elsewhere for
> whatever
> reason (which then creates problems for the references in the
> constraints).

While SMIv2 does not have something like MUST and WHEN expressions, it
still does have references between model elements. Prime example:
ifTabel got augmented by ifXTable registered in a very different
location. It is a major mis-conception that the OID tree is relevant;
what is relevant are relationships between conceptual tables.

> A flat sea of YANG modules is different; I haven't counted lately<= br> > how many top level nodes I have seen but it is a lot and when I see > people wanting to organise YANG modules into a tree, I wonder if
> they are trying to recreate an SMI-like tree and my reaction is that > this is not SMI!

There is no point in organizing them into a tree. There simply is no
universal forever stable tree. When SMIv2 started, people thought such
a tree would evolve and it was later recognized that this is an
illusion and we ended up registering almost everything under mib-2 or
transmission.

> The flat sea of YANG modules brings a different set of issues and I > am unsure what they are;

This is main problem I have. What the heck is the problem we are trying
to fix?

> I understand what is involved with the references in constraints, I > can see that there will be a lot of namespaces and prefixes and can > speculate about what that will bring but what it means to have so
> many top level nodes, I do not know.

Having 200+ MIB modules registered below mib-2 has not been a problem
as far as I know.



The only thing the same between SMIv2= and YANG here is age-old question
of how should we care about &q= uot;dumb" tools that are not very schema-aware.

With YANG, the data related to "foo" can actually be located
under /some/path/to/foo.

I agree with you= that for a programmatic interface, the location is not
at all im= portant, but to a human typing URLs into a browser,
it will be im= portant.

I don't see the 6 modules that have a= lready been published so far in RFCs
as the problem.=C2=A0 I sugg= est focusing on the 194 modules that have not
been published.=C2= =A0 Should the IETF spend a year or two debating the ONE TRUE
PER= FECT uber-tree? 6 months?=C2=A0 How long will it take for all interested
vendors to agree where every little thing goes, before starting on = any of it.

=C2=A0
/js


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

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

--001a1134946c37e75d051e4a09f4-- From nobody Thu Aug 27 05:46:16 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F9091B2DB0 for ; Thu, 27 Aug 2015 05:46:14 -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 ndOOYaCN_SBY for ; Thu, 27 Aug 2015 05:46:12 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C89C01B33FC for ; Thu, 27 Aug 2015 05:46:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1646; q=dns/txt; s=iport; t=1440679572; x=1441889172; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=abUVBrd6RbyGRbeej/vR24Bzj0+FaLo23UEobsaRu2k=; b=Zcd6e695gVYqxxehjKy4tuxKapzA9ntrgqS2IDd5cLdCobFn1tCiszAW WhSmLDWp19DKRde8q8DZ/pEJaxsW9Be3+clSIHXhBok8SKl+4TnlJaxFd Ur7H5/c5dVWKZUCG0FcBkxLyCOFX1vzLcrPMLIgKz4SCZrmInRKMHIPmI 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CmAgBuBd9V/5hdJa1dgxtUaQa9cQEJgW4KhTFKAoEzOBQBAQEBAQEBgQqEJAEBAwEBAQFrEAsCAQgiJB8ICyUBAQQBEgiIHggNyBwBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIthhFgCOIMYgRQFlT0BC4xogUmEMpRkJoJBgT5xgUiBBQEBAQ X-IronPort-AV: E=Sophos;i="5.17,422,1437436800"; d="scan'208";a="22064783" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 27 Aug 2015 12:45:56 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t7RCjvBb006338 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Aug 2015 12:45:57 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 27 Aug 2015 07:45:56 -0500 Received: from xhc-aln-x06.cisco.com (173.36.12.80) by xch-rcd-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Thu, 27 Aug 2015 07:45:56 -0500 Received: from xmb-aln-x03.cisco.com ([169.254.6.3]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0248.002; Thu, 27 Aug 2015 07:45:56 -0500 From: "Martin Ciglan -X (mciglan - PANTHEON TECHNOLOGIES at Cisco)" To: Ladislav Lhotka , "netmod@ietf.org" Thread-Topic: [netmod] issue and question: YANG short-case-stmt in augment-stmt or uses-augment-stmt Thread-Index: AdDfMM/O6VDNtVHdSaS0z8BKaEty3gAL/s6AAFlJ9oE= Date: Thu, 27 Aug 2015 12:45:55 +0000 Message-ID: References: , In-Reply-To: Accept-Language: sk-SK, en-US Content-Language: sk-SK X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.37.102.23] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] issue and question: YANG short-case-stmt in augment-stmt or uses-augment-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 12:46:14 -0000 Hi Ladislav Thanks for the asnwer. I've realized that leaf stmt in augment is parsed as data-def-stmt, not sho= rt-case-stmt (even though it is augmented to choice),=20 so all is valid according to RFC6020. Best Regards Martin ________________________________________ Od: Ladislav Lhotka [lhotka@nic.cz] Odoslan=E9: 25. augusta 2015 15:06 Do: Martin Ciglan -X (mciglan - PANTHEON TECHNOLOGIES at Cisco); netmod@iet= f.org Predmet: Re: [netmod] issue and question: YANG short-case-stmt in augment-s= tmt or uses-augment-stmt Hi Martin, as far as I can tell, these groupings are OK, and pyang also doesn't complain. Ahoj, L=E1=EFa "Martin Ciglan -X (mciglan - PANTHEON TECHNOLOGIES at Cisco)" writes: > Hello > > I've come across a yang module which defines a short-case-stmt in augment= -stmt or uses-augment-stmt > > Something like this: > > grouping grp1 { > uses grp2 { > augment mychoice { > leaf myleaf1 { > type string; > } > } > } > } > > grouping grp2 { > choice mychoice { > leaf myleaf2 { > type string; > } > } > } > > Based on my findings in RFC6020 and errata, this is invalid and there sho= uld be only full case-stmt in augment/uses-augment. > > Can you confirm please? Many thanks in advance. > > Best Regards > > 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 Thu Aug 27 06:00:21 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0BF01B2D7B for ; Thu, 27 Aug 2015 06:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CI5Rrv22PXXs for ; Thu, 27 Aug 2015 06:00:18 -0700 (PDT) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id 927D31B2D67 for ; Thu, 27 Aug 2015 06:00:18 -0700 (PDT) Received: (qmail 19057 invoked by uid 0); 27 Aug 2015 13:00:06 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy2.mail.unifiedlayer.com with SMTP; 27 Aug 2015 13:00:06 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id 9ozo1r00V2SSUrH01ozrUE; Thu, 27 Aug 2015 07:00:05 -0600 X-Authority-Analysis: v=2.1 cv=EbVbHpWC c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=6PzwTDcoQqoA:10 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=uRRa74qj2VoA:10 a=hljkz9boUe-SrVCC4JEA:9 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=pevA5Bkt7c1KfD8YqPvv6g2bU9ezkNqDT9bcs3xkfz4=; b=gPP5YTK+S61k9TNA5xYuu8ECTP8dhDf69DY3DbXNCRGw9xfdxsVRUz/LnEP1HSsvEjG/PR5+73lSojjrTsjhXNqKhN+FSTuHBC0x7FyHJRKm5m3IPn/WB2ssrk08PucD; Received: from box313.bluehost.com ([69.89.31.113]:41771 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZUwmT-0001Nj-BA; Thu, 27 Aug 2015 06:59:49 -0600 To: Andy Bierman , Juergen Schoenwaelder , "t. petch" , Martin Bjorklund , "netmod@ietf.org" References: <55D36473.90609@cisco.com> <55D45CAF.2070605@cisco.com> <20150819.132555.871710491924929960.mbj@tail-f.com> <013601d0da9b$907f6b00$4001a8c0@gateway.2wire.net> <20150823170415.GA77197@elstar.local> <012901d0e01e$12c22b20$4001a8c0@gateway.2wire.net> <20150827064240.GB87367@elstar.local> From: Lou Berger X-Enigmail-Draft-Status: N1110 Message-ID: <55DF09C0.2020708@labn.net> Date: Thu, 27 Aug 2015 08:59:44 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Subject: Re: [netmod] Y34 - root node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 13:00:19 -0000 On 8/27/2015 8:23 AM, Andy Bierman wrote: > > I don't see the 6 modules that have already been published so far in RFCs > as the problem. I suggest focusing on the 194 modules that have not > been published. 100% agree > Should the IETF spend a year or two debating the ONE TRUE > PERFECT uber-tree? 6 months? No, IMO we should take a stab at it and go with our best understanding and consensus -- that is after all what the I*E*TF is all about. > How long will it take for all interested > vendors to agree where every little thing goes, before starting on any > of it. > The DT's proposal seems to be a consensus starting point (from my DT and individual perspective, based on *many* discussions with vendors and users) in at least the routing area. Outside the routing area, I've heard three or four individual objections. Not saying we have it right, but just that we have a solid start. Lou From nobody Thu Aug 27 06:54:15 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C50A41A882C for ; Thu, 27 Aug 2015 06:54:13 -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 YxBP2kRrYgX8 for ; Thu, 27 Aug 2015 06:54:12 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DF2E1A6EED for ; Thu, 27 Aug 2015 06:54:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1666; q=dns/txt; s=iport; t=1440683652; x=1441893252; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=D+JeRu2zHV+t22qVk48I5Ih8mKEdJoV7D4Bneky+Cx0=; b=WJIxcWJz3ti9EsJCGYNS5/afOYoUfoVovVgCdd9DPPYIT/XZ2Hrgd/oX 4t9miE7lwhir4d4uEeSczWvfx9k/QxVh6O2UXyZm00Dy6KLb7djzA2Hqd ur0UWIhvKDByy8B94PM+K6PFgN1faVyDuHSowlOuv1gFxcpF5bkN6EJN7 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CmAgAfFd9V/51dJa1dgxtUaQa9cQEJgW4KhTFKAoEvOBQBAQEBAQEBgQqEIwEBAQMBAQEBNzQQBwQCAQgOAwQBAQEKFAkHJwsUCQgCBAESCBGIDQgNyDcBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIpegQOEWjgGgxKBFAWVPQGnUiaDf3GBSIEFAQEB X-IronPort-AV: E=Sophos;i="5.17,422,1437436800"; d="scan'208";a="182273510" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Aug 2015 13:54:11 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t7RDsB3R005053 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Aug 2015 13:54:11 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 27 Aug 2015 08:54:10 -0500 Received: from xhc-aln-x12.cisco.com (173.36.12.86) by xch-rcd-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Thu, 27 Aug 2015 08:54:10 -0500 Received: from xmb-aln-x08.cisco.com ([169.254.3.202]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0248.002; Thu, 27 Aug 2015 08:54:09 -0500 From: "Ambika Prasad Tripathy (ambtripa)" To: Lou Berger , Andy Bierman , Juergen Schoenwaelder , "t. petch" , Martin Bjorklund , "netmod@ietf.org" Thread-Topic: [netmod] Y34 - root node Thread-Index: AQHQzfwQU3Yk796WUk+nXDjZCMdPCJ36tNgA//+74oqAAFbtgIAAz0+kgADCtACABfPJgIAC/IuAgAAMEQCAAKj6AIAAC1YAgAC+7gCAC50MgIAABoyAgAEhX4CAAA01gP///7DRgAaoK4CABFzVx4ABPtUAgABfPQCAAAobAP//untw Date: Thu, 27 Aug 2015 13:54:08 +0000 Message-ID: <3B675C3A8DF102408C754E30986E43CF110C1378@xmb-aln-x08.cisco.com> References: <55D36473.90609@cisco.com> <55D45CAF.2070605@cisco.com> <20150819.132555.871710491924929960.mbj@tail-f.com> <013601d0da9b$907f6b00$4001a8c0@gateway.2wire.net> <20150823170415.GA77197@elstar.local> <012901d0e01e$12c22b20$4001a8c0@gateway.2wire.net> <20150827064240.GB87367@elstar.local> <55DF09C0.2020708@labn.net> In-Reply-To: <55DF09C0.2020708@labn.net> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.110.128] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] Y34 - root node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 13:54:13 -0000 IMHO, there should a YANG Construct should allow modules to be reused withi= n another module with a restriction of looping. When the YANG modules organized at controller, or any manager, re use of gr= ouping or a particular XPath mount makes life static in YANG.=20 Br, Ambika Prasad Tripathy (ambtripa) -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Lou Berger Sent: Thursday, August 27, 2015 6:30 PM To: Andy Bierman; Juergen Schoenwaelder; t. petch; Martin Bjorklund; netmod= @ietf.org Subject: Re: [netmod] Y34 - root node On 8/27/2015 8:23 AM, Andy Bierman wrote: > > I don't see the 6 modules that have already been published so far in=20 > RFCs as the problem. I suggest focusing on the 194 modules that have=20 > not been published. 100% agree > Should the IETF spend a year or two debating the ONE TRUE PERFECT=20 > uber-tree? 6 months? No, IMO we should take a stab at it and go with our best understanding and = consensus -- that is after all what the I*E*TF is all about. > How long will it take for all interested vendors to agree where every=20 > little thing goes, before starting on any of it. > The DT's proposal seems to be a consensus starting point (from my DT and individual perspective, based on *many* discussions with vendors and users) in at least the routing area. Outside the routing area, I've heard three or four individual objections. Not saying we have it right, but just that we have a solid start. Lou _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Aug 27 06:57:08 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D49401B3C28 for ; Thu, 27 Aug 2015 06:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIairTNhJf-n for ; Thu, 27 Aug 2015 06:57:04 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 004B61B2FCD for ; Thu, 27 Aug 2015 06:57:02 -0700 (PDT) Received: from [76.69.245.91] (helo=corretto.local) by cappuccino.rob.sh with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1ZUxfa-0006RT-Cp for netmod@ietf.org; Thu, 27 Aug 2015 14:56:46 +0100 Date: Thu, 27 Aug 2015 09:56:58 -0400 From: Rob Shakir To: netmod@ietf.org Message-ID: X-Mailer: Airmail Beta (323) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="55df172a_3edf3a74_1ef8" Archived-At: Subject: [netmod] Motivations for Structuring Models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 13:57:07 -0000 --55df172a_3edf3a74_1ef8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline NETMOD, One of the chairs encouraged me to post this to the list. I didn=E2=80=99= t really find how it fits in to the existing threads, but I wanted to mak= e an observation. It strikes me that there is a need to take a step back from the debate of= whether /device is a good idea or not. As a user of something that results from compiling/generating bindings fr= om a YANG model, I have two requirements: I need to be able to compose the right modules to be able to get the func= tionality that that the thing I=E2=80=99m trying to configure uses. Let=E2=80=99s say I want to configure some OAM continuity checking functi= ons - for both MPLS and IP. Right now, I have the choice of =E2=80=98ietf-lspping=E2=80=99 which defi= nes /lsp-pings, then =E2=80=98mplstp-oam=E2=80=99 which defines /mplstp-o= am. Presumably then we=E2=80=99ll have =E2=80=98ietf-ip-oam=E2=80=99 and = then =E2=80=98ietf-ipv6-oam=E2=80=99. As a developer - how do I figure out which models I need to build my OAM = function. Do I have to trawl some directory to find all of the different = fragments of OAM=3F Do I then need to accept the complexity of dealing with the fact that the= structures of LSP pings is completely different to the IP OAM structures= =3F =5BGiven that there is no co-ordination of models, then this will hap= pen.=5D As someone that is building YANG models, how do I know where I should lea= f-ref too. Let=E2=80=99s say I want to tie an OAM probe to some protocol liveliness = - where do I point my leafref to=3F At the moment, without some structure= , than any path that is specified is pointing to some placeholder locatio= n, until we agree where the structure might sit. On the first issue here, it strikes me that this is what ietf-routing is = doing. It is placing a set of models under some root node which happens t= o be /routing. If we don=E2=80=99t need /device, then why do we need /rou= ting=3F The other point here, is that it is entirely unclear how ietf-routing act= ually fits in to the structure. I can configure L3 protocols here, great.= But what happens when the =E2=80=98instance=E2=80=99 that I create has L= 2 protocols too (e.g., is a VPLS with a routed L3 interface in it), or is= a mix of the two=3F ietf-routing doesn=E2=80=99t help me here - but ther= e=E2=80=99s no overall structure that tells me what should fit in. If we = have some structure then we can start to define what models should do wha= t such that they are actually usable to people who want to build things v= ia YANG models. I would also observe that of the vendor implementations of YANG models I = have looked at already, almost all define some form of structure of the d= ata within them. In addition, the OSS tools that I=E2=80=99ve looked at t= hat help interact with devices via NETCON=46/YANG do the same thing. When I originally drew the tree that was iterated on to form openconfig-m= odel-structure, the reason to draw it was not to create some =E2=80=98/de= vice=E2=80=99 node. It was to answer the two questions above. Reviewing S= ection 1 of draft-openconfig-netmod-model-structure, these problems are a= gain drawn out. The issue of the IET=46 here is that we are solutions-driven. It is diffi= cult to bring this =E2=80=98challenge=E2=80=99 to the IET=46 without brin= ging a solution. I first raised these points with one of the routing ADs = almost a year ago. I had found that in our attempts to define any form of= models for higher-layer functions in the systems we were debating at the= time, we needed an architecture for the models at that layer. The same t= hing is needed at the device layer - the draft I presented in Dallas is a= n attempt to suggest a possible solution for the challenges I outlined ab= ove. So. Please can we take a step back and figure out if the IET=46 is intere= sted in building models that are usable to the consumers of them=3F To me, this means debating solutions for the two questions above, and the= n figuring out how to support that structure. If we don=E2=80=99t solve this issue in the IET=46, then efforts elsewher= e that are more usable to developers will probably have to remain separat= e. Just my =C2=A30.0002, r. --55df172a_3edf3a74_1ef8 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

NETMOD,

One of the chairs encouraged me to post this to the list. I didn=E2=80= =99t really find how it fits in to the existing threads, but I wanted to = make an observation.

It strikes me that there is a need to take a step back from the debate= of whether /device is a good idea or not.

As a user of something that results from compiling/generating= bindings from a YANG model, I have two requirements:

  • I need to be able to compose the right modules to be able to get the = functionality that that the thing I=E2=80=99m trying to configure uses.
    • Let=E2=80=99s say I want to configure some OAM continuity checking fu= nctions - for both MPLS and IP.
    • Right now, I have the choice of =E2=80=98ietf-lspping=E2=80=99 which = defines /lsp-pings, then =E2=80=98mplstp-oam=E2=80=99 which defines /mpls= tp-oam. Presumably then we=E2=80=99ll have =E2=80=98ietf-ip-oam=E2=80=99 = and then =E2=80=98ietf-ipv6-oam=E2=80=99.
    • As a developer - how do I figure out which models I need to build my = OAM function. Do I have to trawl some directory to find all of the differ= ent fragments of OAM=3F
    • Do I then need to accept the complexity of dealing with the fact that= the structures of LSP pings is completely different to the IP OAM struct= ures=3F =5BGiven that there is no co-ordination of models, then this = will happen.=5D
  • As someone that is building YANG models, how do I know where I should= leaf-ref too.
    • Let=E2=80=99s say I want to tie an OAM probe to some protocol livelin= ess - where do I point my leafref to=3F At the moment, without some structure, than any path that is specified is pointing to some placeh= older location, until we agree where the structure might sit.

On the first issue here, it strikes me that this is what ietf-routing = is doing. It is placing a set of models under some root node which happen= s to be /routing. If we don=E2=80=99t need /device, then why do we need /= routing=3F

The other point here, is that it is entirely unclear how ietf-routing = actually fits in to the structure. I can configure L3 protocols here, gre= at. But what happens when the =E2=80=98instance=E2=80=99 that I create ha= s L2 protocols too (e.g., is a VPLS with a routed L3 interface in it), or= is a mix of the two=3F ietf-routing doesn=E2=80=99t help me here - but t= here=E2=80=99s no overall structure that tells me what should fit in. If = we have some structure then we can start to define what = models should do what such that they are actually usable to people who wa= nt to build things via YANG models.

I would also observe that of the vendor implementations of YANG models= I have looked at already, almost all define some form of structure of th= e data within them. In addition, the OSS tools that I=E2=80=99ve looked a= t that help interact with devices via NETCON=46/YANG do the same thing. <= /p>

When I originally drew the tree that was iterated on to form openconfi= g-model-structure, the reason to draw it was not to create some =E2=80=98= /device=E2=80=99 node. It was to answer the two questions above. Reviewin= g Section 1 of draft-openconfig-netmod-model-structure, these problems ar= e again drawn out.

The issue of the IET=46 here is that we are solutions-driven. It is di= fficult to bring this =E2=80=98challenge=E2=80=99 to the IET=46 without b= ringing a solution. I first raised these points with one of the routing A= Ds almost a year ago. I had found that in our attempts to define any form= of models for higher-layer functions in the systems we were debating at = the time, we needed an architecture for the models at that layer. The sam= e thing is needed at the device layer - the draft I presented in Dallas i= s an attempt to suggest a possible solution for the challenges I outlined= above.

So. Please can we take a step back and figure out if the IET=46 is int= erested in building models that are usable to the consumers of them=3F

To me, this means debating solutions for the two questions above, and = then figuring out how to support that structure.

If we don=E2=80=99t solve this issue in the IET=46, then efforts elsew= here that are more usable to developers will probably have to remain sepa= rate.

Just my =C2=A30.0002,
r.



--55df172a_3edf3a74_1ef8-- From nobody Thu Aug 27 08:21:09 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C83571B2B8F for ; Thu, 27 Aug 2015 08:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhtQh-nGP5Vu for ; Thu, 27 Aug 2015 08:21:04 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 2AFBA1B2B83 for ; Thu, 27 Aug 2015 08:21:03 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 255E41CC0047; Thu, 27 Aug 2015 17:21:05 +0200 (CEST) From: Ladislav Lhotka To: Rob Shakir , netmod@ietf.org In-Reply-To: References: User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Thu, 27 Aug 2015 17:21:00 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] Motivations for Structuring Models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 15:21:07 -0000 Hi Rob, Rob Shakir writes: > On the first issue here, it strikes me that this is what ietf-routing > is doing. It is placing a set of models under some root node which > happens to be /routing. If we don=E2=80=99t need /device, then why do we = need > /routing? This one is actually easy to explain, exactly as the top-level container "interfaces" in ietf-interfaces: it is a courtesy to XML encoding. In both cases, a list is just below the top-level container. If the top-level container wasn't there we could see interleaved entries of both lists in XML encoding, for example ... ... ... ... ... This was considered problematic, so the top-level containers were added to avoid this. Note that this is not an issue in JSON encoding where all entries of a list are neatly organised in an array: "interface": [{...}, {...}, {...}] "routing-instance": [{...}, {...}] Cheers, Lada --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Aug 27 08:30:55 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC2371B2A64 for ; Thu, 27 Aug 2015 08:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCnU_UoYVtH2 for ; Thu, 27 Aug 2015 08:30:47 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6932A1B2A80 for ; Thu, 27 Aug 2015 08:30:46 -0700 (PDT) Received: from [2607:fa48:6e29:da40:f486:f472:a848:f1ab] (helo=corretto) by cappuccino.rob.sh with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1ZUz8H-0006n6-V8; Thu, 27 Aug 2015 16:30:30 +0100 Date: Thu, 27 Aug 2015 11:30:44 -0400 From: Rob Shakir To: Ladislav Lhotka , netmod@ietf.org Message-ID: In-Reply-To: References: X-Mailer: Airmail Beta (323) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="55df2d24_6b8a63db_1ef8" Archived-At: Subject: Re: [netmod] Motivations for Structuring Models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 15:30:54 -0000 --55df2d24_6b8a63db_1ef8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Lada, Thanks for the reply. On August 27, 2015 at 11:21:18, Ladislav Lhotka (lhotka=40nic.cz) wrote: This one is actually easy to explain, exactly as the top-level container=C2= =A0 =22interfaces=22 in ietf-interfaces: it is a courtesy to XML encoding.=C2= =A0 Apologies, I=E2=80=99m not sure my question was clear enough. The point w= as, why do we need a model that defines a structure for routing if one th= at defines a structure for device is not useful=3F Thanks, r --55df2d24_6b8a63db_1ef8 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

Hi Lada,

Thanks for the reply.<= /div>

On August 27, 2015 at 11:21:18, Ladisl= av Lhotka (lhotka=40nic.cz) wr= ote:

This one is actually easy to explain, exactly as the to= p-level container <= /span>
Just my =C2=A30.0002, > r. > > > Andy > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --089e01493fa8e1edde051e4d6702 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Aug 27, 2015 at 6:56 AM, Rob Shakir <rjs@rob.sh> wrote:=

NETMOD,

One of the chairs encouraged me to post this to the list. I didn=E2=80= =99t really find how it fits in to the existing threads, but I wanted to ma= ke an observation.

It strikes me that there is a need to take a step back from the debate o= f whether /device is a good idea or not.

As a user of something that results from compiling/generating b= indings from a YANG model, I have two requirements:

  • I need to be able to compose the right modules to be able to get the fu= nctionality that that the thing I=E2=80=99m trying to configure uses.
    • Let=E2=80=99s say I want to configure some OAM continuity checking func= tions - for both MPLS and IP.
    • Right now, I have the choice of =E2=80=98ietf-lspping=E2=80=99 which de= fines /lsp-pings, then =E2=80=98mplstp-oam=E2=80=99 which defines /mplstp-o= am. Presumably then we=E2=80=99ll have =E2=80=98ietf-ip-oam=E2=80=99 and th= en =E2=80=98ietf-ipv6-oam=E2=80=99.
    • As a developer - how do I figure out which models I need to build my OA= M function. Do I have to trawl some directory to find all of the different = fragments of OAM?
    • Do I then need to accept the complexity of dealing with the fact that t= he structures of LSP pings is completely different to the IP OAM structures= ? [Given that there is no co-ordination of models, then this will = happen.]
  • As someone that is building YANG models, how do I know where I should l= eaf-ref too.
    • Let=E2=80=99s say I want to tie an OAM probe to some protocol livelines= s - where do I point my leafref to? At the moment, without some st= ructure, than any path that is specified is pointing to some placeholder lo= cation, until we agree where the structure might sit.

On the first issue here, it strikes me that this is what ietf-routing is= doing. It is placing a set of models under some root node which happens to= be /routing. If we don=E2=80=99t need /device, then why do we need /routin= g?

The other point here, is that it is entirely unclear how ietf-routing ac= tually fits in to the structure. I can configure L3 protocols here, great. = But what happens when the =E2=80=98instance=E2=80=99 that I create has L2 p= rotocols too (e.g., is a VPLS with a routed L3 interface in it), or is a mi= x of the two? ietf-routing doesn=E2=80=99t help me here - but there=E2=80= =99s no overall structure that tells me what should fit in. If we have some structure then we can start to define what models should = do what such that they are actually usable to people who want to build thin= gs via YANG models.

I would also observe that of the vendor implementations of YANG models I= have looked at already, almost all define some form of structure of the da= ta within them. In addition, the OSS tools that I=E2=80=99ve looked at that= help interact with devices via NETCONF/YANG do the same thing.

When I originally drew the tree that was iterated on to form openconfig-= model-structure, the reason to draw it was not to create some =E2=80=98/dev= ice=E2=80=99 node. It was to answer the two questions above. Reviewing Sect= ion 1 of draft-openconfig-netmod-model-structure, these problems are again = drawn out.

The issue of the IETF here is that we are solutions-driven. It is diffic= ult to bring this =E2=80=98challenge=E2=80=99 to the IETF without bringing = a solution. I first raised these points with one of the routing ADs almost = a year ago. I had found that in our attempts to define any form of models f= or higher-layer functions in the systems we were debating at the time, we n= eeded an architecture for the models at that layer. The same thing is neede= d at the device layer - the draft I presented in Dallas is an attempt to su= ggest a possible solution for the challenges I outlined above.

So. Please can we take a step back and figure out if the IETF is interes= ted in building models that are usable to the consumers of them?

To me, this means debating solutions for the two questions above, and th= en figuring out how to support that structure.

If we don=E2=80=99t solve this issue in the IETF, then efforts elsewhere= that are more usable to developers will probably have to remain separate.<= /p>




A whole lots of words here, but I am still confused why /device is b= etter than /
for solving your "data model awareness" pr= oblem.

YANG is no different than any other part of= the source code.
Reusable YANG is just as likely or unlikely as = reusable C,
depending on how aware people are of the existing cod= e base.

Which OAM? Read the modules and decide. No= magic there.
How would /device vs / (as the first node) help you= figure this out?

Nobody is objecting at all to cr= eating structure for the new modules.
If /device has siblings, th= en let's see them in the uber-tree.
The objection is to addin= g in a useless layer, and moving existing
data nodes, which break= s existing implementations of all those data nodes.


=C2=A0

Just my =C2=A30.0002,
r.



Andy
=C2=A0


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


--089e01493fa8e1edde051e4d6702-- From nobody Thu Aug 27 09:42:04 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 095E41B37AE for ; Thu, 27 Aug 2015 09:42:04 -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 agVbXgiOJ4hD for ; Thu, 27 Aug 2015 09:42:01 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0700.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::700]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 409F21A026C for ; Thu, 27 Aug 2015 09:42:01 -0700 (PDT) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.151.163.82) by AMSPR07MB049.eurprd07.prod.outlook.com (10.242.81.11) with Microsoft SMTP Server (TLS) id 15.1.256.15; Thu, 27 Aug 2015 16:41:35 +0000 Message-ID: <00e201d0e0e7$5240f3c0$4001a8c0@gateway.2wire.net> From: t.petch To: Lou Berger , Juergen Schoenwaelder References: <55D36473.90609@cisco.com> <55D45CAF.2070605@cisco.com> <20150819.132555.871710491924929960.mbj@tail-f.com> <013601d0da9b$907f6b00$4001a8c0@gateway.2wire.net> <20150823170415.GA77197@elstar.local> <012901d0e01e$12c22b20$4001a8c0@gateway.2wire.net> <20150827064240.GB87367@elstar.local> <55DEF430.40801@labn.net> Date: Thu, 27 Aug 2015 17:42:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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.163.82] X-ClientProxiedBy: HE1PR05CA0082.eurprd05.prod.outlook.com (25.164.28.50) To AMSPR07MB049.eurprd07.prod.outlook.com (10.242.81.11) X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB049; 2:ifWbQaj6plDIpYQ8D3ghZduTuw5cl98SOlet8r/+iPPSD7O1GcjxsNLVpsJsNbwejvfYITETdoz6taoURsa/98NZxKqCz2nT6sRPcNEr2sr0PysklpOivFZOZR632I4emHX9ZMX+06h1U/0qPkmr7HCubVZV2LJ6wgYuNd9sldk=; 3:8ylvZoPCKM8rYZYhT/gQaTb/9Txm6a3b5BCGiKNpx0zbUmsC/HLJgSbz2w25UWsSrRqqt9WL2qTFtpd3O6AVbPvjqzINHPhQmmgMyqXMA7rfuDYtkppnDxMsxTaLLPj0UabU0iHERs2pAePyYwm4Hg==; 25:4w2L6VEs70QYbRbp8MxW6N6IfyaPxZHZ8JtfmGDyaIBUwQnpt4Py1FzCh2RfhL/qo+EXXp9cMqGkFR5zz55wzgQfU11Z0adMGh/yrjoFSWPD3z4Kd+UejLzcRHHItlfdWsiUF8T5H5bKR5zEaYdavH8x+ZsnPwcQaFZNbOLil860RkyomGPZzf5S5oleL5D+PgX6Ii8k826y114/w8LsUGguNVNIp35DBQI7MGV8zVIM13ykBTAWP1fveK/vprg4IgK/7aO1daFWpRY1TOEmdQ==; 4:OGIMiI8JKpNntgtQWicOifVNZo7ePUTacIPZLyVhtY5YOh7nkDNbZBxmmjDgvVZ14R/f66CBuLsVhTFQc4FLdpsA1IlSImSC52h1m/lLHjmDlUpYIqTiFUbY4OzJxcMZHFF2vEkvwD65X0TZSIu0v9mOdOaH86cuoZGFoIjLtvaJ0dOhdrQJnyox9jTuSVjcLVYvxX0vyrSMWw7NfypzM8ztd12MuQZE2OLp48wBArTB19hs20u+Ja26YUu1/tmCVoYK9ZHf4sLcxFRaAaN4MVGYBlfQKMRpCZw1Kk+D/PPNnf1A3ZoOx3Hpf3DBW+RUNfhauFou7xhWGTTL7lbJZw== 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)(5005006)(8121501046)(3002001); SRVR:AMSPR07MB049; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB049; X-Forefront-PRVS: 06818431B9 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(189002)(479174004)(24454002)(199003)(13464003)(86362001)(5004730100002)(122386002)(1556002)(23746002)(66066001)(189998001)(46102003)(40100003)(68736005)(33646002)(62236002)(64706001)(5001920100001)(14496001)(44716002)(101416001)(5001960100002)(106356001)(50466002)(62966003)(5007970100001)(77156002)(105586002)(92566002)(47776003)(19580405001)(42186005)(19580395003)(4001540100001)(81156007)(5001830100001)(84392001)(5001860100001)(5001770100001)(81816999)(81686999)(50986999)(44736004)(50226001)(116806002)(61296003)(1456003)(77096005)(97736004)(76176999)(93886004)(87976001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB049; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; AMSPR07MB049; 23:bL5G/hef3STd6rUa7noRuV6TwG6rCsFx6gsxjd?= =?Windows-1252?Q?ggFVPaNfTOp/l32yBwIfk8aGkFvxvR83aDG+zMJxVfHPmENurkg2N/0H?= =?Windows-1252?Q?xxthPZfPAjzkzH3IMbGAWs5ZwGPGBvR6f/vCzXE/kg7RWNNy9tRaNYql?= =?Windows-1252?Q?AEeb9E3m9mEart0KGzIEzFuq1Z5Q/cR9Pq5uN013EsiJ9m52poGElfSI?= =?Windows-1252?Q?WyXDeO867PpeJdCkI+gI4grZIC4N6x3XZ8HomOV1wrJZd3hxPXxvW3lb?= =?Windows-1252?Q?oXdOTMW0n8M4EiyEYfnpv4n6pafyvth04FSG3LlBQ53gcQZ7iGXS3OAR?= =?Windows-1252?Q?XGw65TAd8J3RoXtAS7yIDtAvxk4lvPbZRRMTwYi1mygre6Gir8DYvDEX?= =?Windows-1252?Q?O/LGqgZedWukWoplspSHeQTNwkrXap+80JW+uP5Kqex/9uwkPnZBi385?= =?Windows-1252?Q?/rXkEIiyUxqGssU3B+MkqdvoaXJh4AhUPOQsty7hRt5lXi5rAi/PMHDA?= =?Windows-1252?Q?wacDoxI2tiQBaW8ZyXCBydpqpJ5344m3z6uubT/tfbntj1VVQ5vLKn7L?= =?Windows-1252?Q?PX5rLdCMuVuTmZT9oVKXWLIazyEHA4lovPIdCWQkHcjP5X7bHB0nlEhW?= =?Windows-1252?Q?Ti2NB01e0hVf8A2ZgBIJTlkTjhpzgQ0a8mGIkbHQmMduTjB3PKkLa6fn?= =?Windows-1252?Q?v+Q04RRl6y4SwFPC4q9Dv4skW4+USs9sXHOpT4wVrhoDQRivl0wkfJv2?= =?Windows-1252?Q?uo7X2YEC1J918T8TKSkORcJ/evVeznvK/QMb8js//MZmrydHfn1yzWKB?= =?Windows-1252?Q?XOZUTtU2byDUo1cH7gtSQy6ig9m4gKOf0HT2cur5RJKJecF9iwSj6DZq?= =?Windows-1252?Q?ujn+qG2aUXtskDo5eFAhVanQnf87LI95IIYQtib3Z5zcUj22hOpejW6L?= =?Windows-1252?Q?q9PTX2zucNmJb+Ch3xyHCA31snP9MULWn9KNYuAaz9v95tS39AtD0odn?= =?Windows-1252?Q?thWTb8DpneV4ZJ9fetEV3g1YBQfY7DtnZL++oa3jyey7uubz4IkJhhtb?= =?Windows-1252?Q?LoNMhQw0AscLolCZ/WsgIt+LrScpjTLt45wNZb6xMAgDXzxjwfMcs90F?= =?Windows-1252?Q?SwopYjrMqpyb17MCJVlF0zbXjTzrMPA9R5WukYmz5x+xjw6pWPR1HiZY?= =?Windows-1252?Q?X01Ig54rwSe014a1RYrupqeZJaYbGFLvz/DiLENvNOuieqm4QsoqIrmW?= =?Windows-1252?Q?q3/ThKLhoC0IfkB6j/UQyAKx9IuPOwr9q7USRV9drmvvvLpMifO7vJ0/?= =?Windows-1252?Q?aWx3fAdBdY3S7t2A1MuCtrjfL/tctqWVMaKAYLKsKt71Hkj9QHVxnfHA?= =?Windows-1252?Q?U//8jjBvGuhWoq/QndHrMhg4q2/DzAKtzsdgI2N5cGQW7HvqgF4BN0Sk?= =?Windows-1252?Q?Dv+KuAPWclWqOXG8YUgRWu8ufUaegNDHA8LrW9Mqow1BS0vUy8WfcVkf?= =?Windows-1252?Q?QDAk/7kx0/8lRMaD7USygMvR72nx1AwHdcAYmQEYsAZWi1tvj57a48+a?= =?Windows-1252?Q?TF8rzC44hDtM9CyV4XD9PqloMA7isu439VcJ/jRZGRUgfTM4odaB71Og?= =?Windows-1252?Q?=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB049; 5:9t0GRK02/Hn1V4FsuHfHqEg0EwiWPbcr9yPUR7haBsyNC2Z0U0S5T2OoxZB/anroh7ZiHQKI0kVFtSi3GQpnFrsLhBrXQ4Tsc4lpI5LwPhzFEOIsh4/ymJcNOszucbJuwaXGFgHuuUfBBBKggTHi7Q==; 24:mAi372cN8aETxbUauuuxft/VU/tH5LXeVc98tkOUYmWL2j0SKzd5dBjnIBTWmZIhYhSsyhjpNB0pBbXxZELUOMkYSVCentgLX2zc4RYFWF8=; 20:cp8iv4WBA+KAZsHsOnoU1yjna+FF+3OMR3N8uWV8Gappwi1LcgT8CoEtQqHN4g5r/FtPhT92koA//NHXfQ87Ig== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Aug 2015 16:41:35.5122 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB049 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Y34 - root node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 16:42:04 -0000 ----- Original Message ----- From: "Lou Berger" To: "Juergen Schoenwaelder" Cc: "t. petch" ; "Martin Bjorklund" ; Sent: Thursday, August 27, 2015 12:27 PM > On 08/27/2015 02:42 AM, Juergen Schoenwaelder wrote: > >> The flat sea of YANG modules brings a different set of issues and I > >> > am unsure what they are; > > > > This is main problem I have. What the heck is the problem we are trying > > to fix? > > > > The first, but not only problem, is today's ~200 top level models > (looking at current RFCs and I-Ds) with little apparent organization or > inter-relationship. Lou yes, but so what:-) I do share Juergen's view here of what is the problem. Earlier this year, the focus was on presenting a coherent picture to the user and Randy rightly pointed out that it took expert writers of NMS to bring together data from mulitple modules to give the user a coherent display; or it took expert writers of DDLs to produce modules that brought the data together so that the writer of NMS have an easier task - either way, it needs experts and I do not see YANG being that different from SMI in that regard. Likely 'augments' will be used more so that YANG will have more defined interrelationships in the DDL than SMI but not enough to produce a coherent picture. I do not see the benefit, in this or other regards, of placing YANG modules in a tree, or in multiple trees. What is the audience that will benefit from that? I do see the flat sea of modules as reflecting the way in which the IETF works, in a loose federation, so that even within an Area, such as Routing, you would not expect OSPF, say, to be au fait with MPLS, say; so when they create their modules, they may not well dovetail as well as they might but that is the way that the IETF is Tom Petch ps I have other concerns, but I have said enough about those lately so I think about them some more > Lou From nobody Thu Aug 27 09:54:43 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7CD81B396A for ; Thu, 27 Aug 2015 09:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.661 X-Spam-Level: X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvyoF3pGsHj8 for ; Thu, 27 Aug 2015 09:54:40 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C93AF1B390C for ; Thu, 27 Aug 2015 09:54:25 -0700 (PDT) Received: from [172.29.2.202] (nat-14.bravonet.cz [77.48.225.14]) by mail.nic.cz (Postfix) with ESMTPSA id BDEE2181333; Thu, 27 Aug 2015 18:54:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1440694462; bh=NcdMgBUJyeuJSyowm05uJmrMZEOdlUlnrVRVw5mwegw=; h=From:Date:To; b=NIQ9Ho/42lDW3D/mtTfmU8DjmW1af8pHah+v3qoYamJ1q8BeIZDd4DcKxxfKWapa7 v1k5t/l7d9vHDNbTaOmAmjH24XuQI4a/rUVYD7IADg1XwhTx/hriyF6rdyOIAct2fQ m5ElNOz9nfo8cAixTtR109qK37LZXa14bd73g5gw= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: Date: Thu, 27 Aug 2015 18:54:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8539636D-F2CC-49D5-A103-7A20AABB2843@nic.cz> References: To: Rob Shakir X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Motivations for Structuring Models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 16:54:41 -0000 > On 27 Aug 2015, at 17:30, Rob Shakir wrote: >=20 >=20 > Hi Lada, >=20 >=20 > Thanks for the reply. > On August 27, 2015 at 11:21:18, Ladislav Lhotka (lhotka@nic.cz) wrote: >=20 >> This one is actually easy to explain, exactly as the top-level = container=20 >> "interfaces" in ietf-interfaces: it is a courtesy to XML encoding.=20 > Apologies, I=E2=80=99m not sure my question was clear enough. The = point was, why do we need a model that defines a structure for routing = if one that defines a structure for device is not useful? We certainly need *some* structure, and since there was a requirement to = support multiple routing instances, a list of them seems natural. In the past we also discussed the option of defining a common root for = all configuration but we came to the conclusion that it is not needed. Choices have been made and in some cases an alternative design could = certainly be usable, too. However, since some of the models already = became RFCs, convincing technical argument are needed to throw them away = and go back to square 1. And I also think that moving from / to /device = isn=E2=80=99t of that category. Lada =20 >=20 >=20 > Thanks, > r -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Aug 27 10:39:39 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9251A8764 for ; Thu, 27 Aug 2015 10:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vq8vaAftRetR for ; Thu, 27 Aug 2015 10:39:35 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 873491A1A1E for ; Thu, 27 Aug 2015 10:39:34 -0700 (PDT) Received: from [96.22.157.164] (helo=corretto) by cappuccino.rob.sh with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1ZV18w-0007Fz-3v; Thu, 27 Aug 2015 18:39:18 +0100 Date: Thu, 27 Aug 2015 13:39:30 -0400 From: Rob Shakir To: Andy Bierman Message-ID: In-Reply-To: References: X-Mailer: Airmail Beta (323) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="55df4b52_473def41_1ef8" Archived-At: Cc: "=?utf-8?Q?netmod=40ietf.org?=" Subject: Re: [netmod] Motivations for Structuring Models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 17:39:38 -0000 --55df4b52_473def41_1ef8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Andy, Apologies, I don=E2=80=99t understand how your mail answers the questions= that I posed. On August 27, 2015 at 12:25:20, Andy Bierman (andy=40yumaworks.com) wrote= : A whole lots of words here, but I am still confused why /device is better= than / for solving your =22data model awareness=22 problem. Please re-read my email - here=E2=80=99s the single statement where I sai= d that this was NOT the discussion that I think is important: It strikes me that there is a need to take a step back from the debate of= whether /device is a good idea or not. I=E2=80=99m not sure how this could be clearer. YANG is no different than any other part of the source code. Reusable YANG is just as likely or unlikely as reusable C, depending on how aware people are of the existing code base. Which OAM=3F Read the modules and decide. No magic there. How would /device vs / (as the first node) help you figure this out=3F Nobody is objecting at all to creating structure for the new modules. If /device has siblings, then let's see them in the uber-tree. The objection is to adding in a useless layer, and moving existing data nodes, which breaks existing implementations of all those data nodes= . Please suggest an alternate approach to the one that is laid out in draft= -openconfig-netmod-model-structure that you believe will help with the tw= o problems that I raised. I=E2=80=99ll rephrase them here with less expla= nation, albeit that comes with less clarity. 1) As a consumer of YANG models, how do I identify the set of models that= provide a set of functionality=3F How do YANG model writers ensure that = their models are as easy to deal with as possible by having consistent mo= delling approaches for config=3F 2) As a creator of YANG models, how do I know the targets for references = such that I capture references to the elements that I want, given there i= s no currently defined structure=3F =E2=80=9CJust read through the modules=E2=80=9D is not acceptable answer = when considering making things easy to use for YANG model consumers. I wa= nt to have things that are logical to humans such that they can easily ad= opt YANG-based netmgmt. If they need to adopt the ecosystem by having to = use hodgepodge approaches, then this feels like we are fundamentally miss= ing an opportunity to simplify things. I want to make sure that we DO have re-usable YANG - like we have re-usab= le code elsewhere. In my experience this is done elsewhere by defining co= nventions that ensure that this is the case.=C2=A0 Regards, r. --55df4b52_473def41_1ef8 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

Andy,

Apologies, I don=E2=80=99t understand how your mail answers the questi= ons that I posed.

On August 27, 2015 at 12:25:20, Andy Bierman (= andy=40yumaworks.com) wro= te:

A whole lots of words here, but I am still confused w= hy /device is better than /
for = solving your =22data model awareness=22 problem.
<= /span>

Please re-read my email - here=E2=80=99s the = single statement where I said that this was NOT the discussion that I thi= nk is important:

It strikes me that there= is a need to take a step back from the debate of whether /device is a go= od idea or not.

I=E2=80=99m not sure how this could be clearer.

YANG is no different th= an any other part of the source code.
Reusable YANG is just as = likely or unlikely as reusable C,
depending on how aware people= are of the existing code base.

Which OAM=3F Rea= d the modules and decide. No magic there.
How would /device vs = / (as the first node) help you figure this out=3F

Nobody is objecting at all to creating structure for the new modules.
If /device has siblings, then let's see them in the uber-tree.
The objection is to adding in a useless layer, and moving existi= ng
data nodes, which breaks existing implementations of all tho= se data nodes.

Please= suggest an alternate approach to the one that is laid out in draft-openc= onfig-netmod-model-structure that you believe will help with the two prob= lems that I raised. I=E2=80=99ll rephrase them here with less explanation= , albeit that comes with less clarity.

1) As a consumer of YANG mod= els, how do I identify the set of models that provide a set of functional= ity=3F How do YANG model writers ensure that their models are as easy to = deal with as possible by having consistent modelling approaches for confi= g=3F

2) As a creator of YANG models, how do I know the targets for = references such that I capture references to the elements that I want, gi= ven there is no currently defined structure=3F

=E2=80=9CJust read t= hrough the modules=E2=80=9D is not acceptable answer when considering mak= ing things easy to use for YANG model consumers. I want to have things th= at are logical to humans such that they can easily adopt YANG-based netmg= mt. If they need to adopt the ecosystem by having to use hodgepodge appro= aches, then this feels like we are fundamentally missing an opportunity t= o simplify things.

I want to make sure that we DO have re-usable YA= NG - like we have re-usable code elsewhere. In my experience this is done= elsewhere by defining conventions that ensure that this is the case.&nbs= p;

body=7Bfont-family:Consolas,Arial;font-size:12px=7D
Regards,
r.

--55df4b52_473def41_1ef8-- From nobody Thu Aug 27 10:49:31 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0601C1A039B for ; Thu, 27 Aug 2015 10:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JgVnK0MACHaA for ; Thu, 27 Aug 2015 10:49:28 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 067771A6FEA for ; Thu, 27 Aug 2015 10:49:26 -0700 (PDT) Received: from [96.22.157.164] (helo=corretto) by cappuccino.rob.sh with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1ZV1IU-0007J3-47; Thu, 27 Aug 2015 18:49:10 +0100 Date: Thu, 27 Aug 2015 13:49:22 -0400 From: Rob Shakir To: Ladislav Lhotka Message-ID: In-Reply-To: <8539636D-F2CC-49D5-A103-7A20AABB2843@nic.cz> References: <8539636D-F2CC-49D5-A103-7A20AABB2843@nic.cz> X-Mailer: Airmail Beta (323) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="55df4da2_70f6581_1ef8" Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Motivations for Structuring Models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 17:49:30 -0000 --55df4da2_70f6581_1ef8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Lada, On August 27, 2015 at 12:54:39, Ladislav Lhotka (lhotka=40nic.cz) wrote: We certainly need *some* structure, and since there was a requirement to = support multiple routing instances, a list of them seems natural.=C2=A0 Great, we agree that we need some structure like we have for routing else= where. Can you point me towards any proposal other than draft-openconfig-netmod-= model-structure or draft-rtgyangdt-rtgwg-device-model=E2=80=9300 for this= structure=3F Already, implementors are having problems with this - because existing mo= dules that are pretty mature (ietf-bgp for example), need more functional= ity than is in ietf-routing to make usable multi-VR=46 systems, let alone= multi-routing-instance. If there were some structure, we could understan= d how these models need to be augmented to support the use cases. I=E2=80= =99ll come back to the case of how I configure something that is a L2 vir= tual forwarding instance, that uses has a L3 IP interface within it. On the latter comments in your mail, I place little importance on obsolet= ing existing R=46Cs, I care about: Primarily: whether the existing models let me configure things that I nee= d to on my network (or form a suitable base for doing so). Secondary: impact to existing implementations where these models are actu= ally usable to some external consumer. Kind regards, r. --55df4da2_70f6581_1ef8 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

Lada,

=
=

On August 27, 2015 at 12:54:39, Ladislav Lhotka (lhotka=40nic.cz) w= rote:

We certainly need *some* struct= ure, and since there was a requirement to support multiple routing instan= ces, a list of them seems natural. 

Great, we agree that we need some structure like we have for routing e= lsewhere.

Can you point me towards any proposal other than draft-openconfig-netm= od-model-structure or draft-rtgyangdt-rtgwg-device-model=E2=80=9300 for t= his structure=3F

Already, implementors are having problems with this - because existing= modules that are pretty mature (ietf-bgp for example), need more functio= nality than is in ietf-routing to make usable multi-VR=46 systems, let al= one multi-routing-instance. If there were some structure, we could unders= tand how these models need to be augmented to support the use cases. I=E2= =80=99ll come back to the case of how I configure something that is a L2 = virtual forwarding instance, that uses has a L3 IP interface within it.

On the latter comments in your mail, I place little importance on obso= leting existing R=46Cs, I care about:

  • Primarily: whether the existing models let me configure things that I= need to on my network (or form a suitable base for doing so).
  • Secondary: impact to existing implementations where these models are = actually usable to some external consumer.

Kind regards,
r.

--55df4da2_70f6581_1ef8-- From nobody Thu Aug 27 10:59:28 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1601ACDA3 for ; Thu, 27 Aug 2015 10:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IaGuui6TMyPX for ; Thu, 27 Aug 2015 10:59:25 -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 BCF6D1A89C5 for ; Thu, 27 Aug 2015 10:59:24 -0700 (PDT) Received: by laba3 with SMTP id a3so17727510lab.1 for ; Thu, 27 Aug 2015 10:59:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vx89LDZZBjfCq79vMKu5zDyt7Fuxw9GMm5PuZZ0FWpY=; b=mgplSbR4TbVy0hiuR4HQHLfXfSIflLEV6hpz/BVDkjpfdwo4jzQAPMkl2gnxwJ5Pah 7IV29n3WTriq+BOgdOX94wPWPYZsNE2E6dNBAQADEe6wwSt281K45QBxB9CBmTVGwxse rfvpTV56xzNZIqfvlUqgAnKzzhk/aZqhalec0pvC8UtdVOhWdiyiTG8l8RRnIzX/KCvy rP0feZ7MSP254JTjFhTO/XBkS3nmJbMFEu+lObtpDbzyXZ4iRwElvsSwFWDueH2pk4qq AaB2SRhpEL79a/41RZ8LhPFk7gUpcEqdWXdugFeg/Fiz9zE+bktmLJjJm094hNpv9UVg PlOw== X-Gm-Message-State: ALoCoQns+kvzzzyIxGKxfScf4PmYCWtF/HVavAgkXU3Z2Tsc8iXdS1n0fpJ2iGX/BkXjpoE4gGZ/ MIME-Version: 1.0 X-Received: by 10.112.141.136 with SMTP id ro8mr2885000lbb.88.1440698363148; Thu, 27 Aug 2015 10:59:23 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Thu, 27 Aug 2015 10:59:23 -0700 (PDT) In-Reply-To: References: Date: Thu, 27 Aug 2015 10:59:23 -0700 Message-ID: From: Andy Bierman To: Rob Shakir Content-Type: multipart/alternative; boundary=001a11c343c02a1c11051e4eba9d Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Motivations for Structuring Models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 17:59:27 -0000 --001a11c343c02a1c11051e4eba9d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Aug 27, 2015 at 10:39 AM, Rob Shakir wrote: > Andy, > > Apologies, I don=E2=80=99t understand how your mail answers the questions= that I > posed. > > On August 27, 2015 at 12:25:20, Andy Bierman (andy@yumaworks.com) wrote: > > A whole lots of words here, but I am still confused why /device is better > than / > for solving your "data model awareness" problem. > > Please re-read my email - here=E2=80=99s the single statement where I sai= d that > this was NOT the discussion that I think is important: > > It strikes me that there is a need to take a step back from the debate of >> whether /device is a good idea or not. >> > I=E2=80=99m not sure how this could be clearer. > > Sorry -- are you suggesting that maybe /device adds no value beyond /? If so, I agree. > YANG is no different than any other part of the source code. > Reusable YANG is just as likely or unlikely as reusable C, > depending on how aware people are of the existing code base. > > Which OAM? Read the modules and decide. No magic there. > How would /device vs / (as the first node) help you figure this out? > > Nobody is objecting at all to creating structure for the new modules. > If /device has siblings, then let's see them in the uber-tree. > The objection is to adding in a useless layer, and moving existing > data nodes, which breaks existing implementations of all those data nodes= . > > Please suggest an alternate approach to the one that is laid out in > draft-openconfig-netmod-model-structure that you believe will help with t= he > two problems that I raised. I=E2=80=99ll rephrase them here with less exp= lanation, > albeit that comes with less clarity. > > 1) As a consumer of YANG models, how do I identify the set of models that > provide a set of functionality? How do YANG model writers ensure that the= ir > models are as easy to deal with as possible by having consistent modellin= g > approaches for config? > RTFM > 2) As a creator of YANG models, how do I know the targets for references > such that I capture references to the elements that I want, given there i= s > no currently defined structure? > The modules you are using have data locations defined. In order to define YANG data (with YANG 1.0 or 1.1) a top-level data node or augment-stmt will be present specifying the /path/from/root How do you know where data is that has not been defined yet? You don't and YANG has no ability to reference undefined data anyway. =E2=80=9CJust read through the modules=E2=80=9D is not acceptable answer wh= en considering > making things easy to use for YANG model consumers. I want to have things > that are logical to humans such that they can easily adopt YANG-based > netmgmt. If they need to adopt the ecosystem by having to use hodgepodge > approaches, then this feels like we are fundamentally missing an > opportunity to simplify things. > Why isn't RTFM good enough? Is there some expectation that just /the/path/from/root is enough to make somebody an expert in managing some feature or an expert in writing new YANG modules? Additional tools outside the scope of IETF standardization work are needed to make development easier. Nothing whatsoever is stopping the routing area from defining some structur= e for new modules. Pick whatever you like. The only pushback is wrt/ obsoleting existing RFC modules and moving the data nodes in them to a different location. Some of us do not agree that a problem has been demonstrated that warrants starting over for these RFCs. I want to make sure that we DO have re-usable YANG - like we have re-usable > code elsewhere. In my experience this is done elsewhere by defining > conventions that ensure that this is the case. > > Regards, > r. > > Andy --001a11c343c02a1c11051e4eba9d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Aug 27, 2015 at 10:39 AM, Rob Shakir <rjs@rob.sh> wrote= :

Andy,

Apologies, I don=E2=80=99t understand how your mail answers the question= s that I posed.

On August 27, 2015 at 12:25:20, Andy Bierm= an (andy@yumaworks.= com) wrote:

A whole lots of words here, but I am still con= fused why /device is better than /
for s= olving your "data model awareness" problem.

Please re-read my email - here=E2=80=99s the= single statement where I said that this was NOT the discussion that I thin= k is important:

It strikes me that there is a need to t= ake a step back from the debate of whether /device is a good idea or not.

I=E2=80=99m = not sure how this could be clearer.

<= /blockquote>

Sorry -- are you suggesting that maybe /dev= ice adds no value beyond /?
If so, I agree.

<= div>=C2=A0
YANG = is no different than any other part of the source code.
Reusable = YANG is just as likely or unlikely as reusable C,
depending on ho= w aware people are of the existing code base.

Whic= h OAM? Read the modules and decide. No magic there.
How would /de= vice vs / (as the first node) help you figure this out?

Nobody is objecting at all to creating structure for the new modules.=
If /device has siblings, then let's see them in the uber-tre= e.
The objection is to adding in a useless layer, and moving exis= ting
data nodes, which breaks existing implementations of all tho= se data nodes.

Please s= uggest an alternate approach to the one that is laid out in draft-openconfi= g-netmod-model-structure that you believe will help with the two problems t= hat I raised. I=E2=80=99ll rephrase them here with less explanation, albeit= that comes with less clarity.

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

=

RTFM

= =C2=A0

2) As a creator of YANG models, how do I know the tar= gets for references such that I capture references to the elements that I w= ant, given there is no currently defined structure?



The modules you are usi= ng have data locations defined.
In order to define YANG data (wit= h YANG 1.0 or 1.1)
a top-level data node or augment-stmt will be = present specifying the /path/from/root

How do you = know where data is that has not been defined yet?
You don't a= nd YANG has no ability to reference undefined data anyway.


=E2=80=9CJust read through the modules=E2=80= =9D is not acceptable answer when considering making things easy to use for= YANG model consumers. I want to have things that are logical to humans suc= h that they can easily adopt YANG-based netmgmt. If they need to adopt the = ecosystem by having to use hodgepodge approaches, then this feels like we a= re fundamentally missing an opportunity to simplify things.

=


Why isn't R= TFM good enough?
Is there some expectation that just /the/path/fr= om/root is enough
to make somebody an expert in managing some fea= ture or an expert
in writing new YANG modules?

Additional tools outside the scope of IETF standardization work are = needed
to make development easier.

Nothi= ng whatsoever is stopping the routing area from defining some structure
for new modules.=C2=A0 Pick whatever you like.

<= div>The only pushback is wrt/ obsoleting existing RFC modules and moving th= e
data nodes in them to a different location. Some of us do not a= gree that
a problem has been demonstrated that warrants starting = over for these RFCs.


I want = to make sure that we DO have re-usable YANG - like we have re-usable code e= lsewhere. In my experience this is done elsewhere by defining conventions t= hat ensure that this is the case.=C2=A0

Regards,
r.


Andy

--001a11c343c02a1c11051e4eba9d-- From nobody Thu Aug 27 11:15:03 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6AAB1ACF24 for ; Thu, 27 Aug 2015 11:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkvNHI8zETTv for ; Thu, 27 Aug 2015 11:14:53 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4713F1ACE93 for ; Thu, 27 Aug 2015 11:14:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1440699228; bh=L23DOjEv9IoeK3+v4Gy1OzdxyZwMCs7TXicVlHSLnEk=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=bwhVhjfDcUfj7BdI5UHv76ve6UyP4kvf8D3cG1i4gTu2w/J50dlSWK3IF8bG8yHF0 mEPFQSv7r0tREvbPxJ3tY2XG30iLYPGZJf9YZzoeI5gNFjbgWjgp2eZTkZpuNX2w/5 /epngceDUEggoYch34xFP/byH+kGbfjQ4+kh5RUY= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; Content-Type: multipart/alternative; boundary="Apple-Mail=_1761D307-67E2-43FC-8EA0-6A2CA1A4C418" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Nadeau Thomas In-Reply-To: Date: Thu, 27 Aug 2015 14:14:49 -0400 Message-Id: <6BD6C8DA-AA4A-4BE7-8836-BDC081D3401D@lucidvision.com> References: To: Andy Bierman X-Mailer: Apple Mail (2.2104) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-ShareWhite: 50.255.148.181 X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=24 Stars=0 Good=0 Friend=2 Surbl=0 Catch=0 r=0 ip=50.255.148.181 X-IP-stats: Notspam Incoming Last 0, First 104, in=1206, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Motivations for Structuring Models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 18:15:01 -0000 --Apple-Mail=_1761D307-67E2-43FC-8EA0-6A2CA1A4C418 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 27, 2015:1:59 PM, at 1:59 PM, Andy Bierman = wrote: >=20 >=20 >=20 > On Thu, Aug 27, 2015 at 10:39 AM, Rob Shakir > wrote: >=20 > Andy, >=20 > Apologies, I don=E2=80=99t understand how your mail answers the = questions that I posed. >=20 > On August 27, 2015 at 12:25:20, Andy Bierman (andy@yumaworks.com = ) wrote: >=20 >> A whole lots of words here, but I am still confused why /device is = better than / >> for solving your "data model awareness" problem. >=20 > Please re-read my email - here=E2=80=99s the single statement where I = said that this was NOT the discussion that I think is important: >=20 >> It strikes me that there is a need to take a step back from the = debate of whether /device is a good idea or not. >>=20 >=20 > I=E2=80=99m not sure how this could be clearer. >=20 >=20 > Sorry -- are you suggesting that maybe /device adds no value beyond /? > If so, I agree. >=20 > =20 >> YANG is no different than any other part of the source code. >> Reusable YANG is just as likely or unlikely as reusable C, >> depending on how aware people are of the existing code base. >>=20 >> Which OAM? Read the modules and decide. No magic there. >> How would /device vs / (as the first node) help you figure this out? >>=20 >> Nobody is objecting at all to creating structure for the new modules. >> If /device has siblings, then let's see them in the uber-tree. >> The objection is to adding in a useless layer, and moving existing >> data nodes, which breaks existing implementations of all those data = nodes. >=20 > Please suggest an alternate approach to the one that is laid out in = draft-openconfig-netmod-model-structure that you believe will help with = the two problems that I raised. I=E2=80=99ll rephrase them here with = less explanation, albeit that comes with less clarity. >=20 > 1) As a consumer of YANG models, how do I identify the set of models = that provide a set of functionality? How do YANG model writers ensure = that their models are as easy to deal with as possible by having = consistent modelling approaches for config? >=20 >=20 > RTFM Andy,=20 While it might be frustrating, coming to an understanding of = what the problem is or might be, and then looking at why the existing mechanisms/models or additional ones solve these = requirements (or do not) is what is at hand. I think everyone agreed at the interim meeting that the requirements were clear and sound. This = is detailed in the meeting minutes. If anyone disputes this, I am happy to do an official WG call for consensus on these specifics, = but given the unanimous agreement at the meeting, I did not feel that it was necessary to do this. Based on that, the next = question is: are these problems solved with what is here today,=20 or do we need another approach/es. Rob is clearly not an idiot and is = asking for detailed reasons why you and others believe what he/OpenConfig have proposed is insufficient. Please be as = considerate and constructive as he has been in asking his questions when you address them.=20 =E2=80=94Tom (Speaking as Co-chair) > 2) As a creator of YANG mode >=20 > ls, how do I know the targets for references such that I capture = references to the elements that I want, given there is no currently = defined structure? >=20 >=20 >=20 > The modules you are using have data locations defined. > In order to define YANG data (with YANG 1.0 or 1.1) > a top-level data node or augment-stmt will be present specifying the = /path/from/root >=20 > How do you know where data is that has not been defined yet? > You don't and YANG has no ability to reference undefined data anyway. >=20 >=20 > =E2=80=9CJust read through the modules=E2=80=9D is not acceptable = answer when considering making things easy to use for YANG model = consumers. I want to have things that are logical to humans such that = they can easily adopt YANG-based netmgmt. If they need to adopt the = ecosystem by having to use hodgepodge approaches, then this feels like = we are fundamentally missing an opportunity to simplify things. >=20 >=20 >=20 > Why isn't RTFM good enough? > Is there some expectation that just /the/path/from/root is enough > to make somebody an expert in managing some feature or an expert > in writing new YANG modules? >=20 > Additional tools outside the scope of IETF standardization work are = needed > to make development easier. >=20 > Nothing whatsoever is stopping the routing area from defining some = structure > for new modules. Pick whatever you like. >=20 > The only pushback is wrt/ obsoleting existing RFC modules and moving = the > data nodes in them to a different location. Some of us do not agree = that > a problem has been demonstrated that warrants starting over for these = RFCs. >=20 >=20 > I want to make sure that we DO have re-usable YANG - like we have = re-usable code elsewhere. In my experience this is done elsewhere by = defining conventions that ensure that this is the case.=20 >=20 >=20 > Regards, > r. >=20 >=20 > Andy >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --Apple-Mail=_1761D307-67E2-43FC-8EA0-6A2CA1A4C418 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Aug 27, 2015:1:59 PM, at 1:59 PM, Andy Bierman <andy@yumaworks.com> = wrote:



On Thu, Aug 27, 2015 at 10:39 AM, = Rob Shakir <rjs@rob.sh> wrote:

Andy,

Apologies,= I don=E2=80=99t understand how your mail answers the questions that I = posed.

On August 27, 2015 at = 12:25:20, Andy Bierman (andy@yumaworks.com) wrote:

A = whole lots of words here, but I am still confused why /device is better = than /
for = solving your "data model awareness" = problem.

Please re-read my email - here=E2=80=99s the single statement = where I said that this was NOT the discussion that I think is = important:

It strikes me that there is a need to take a = step back from the debate of whether /device is a good idea or = not.

I=E2=80=99m not sure how this could be clearer.


Sorry -- are you = suggesting that maybe /device adds no value beyond /?
If so, I agree.

 
YANG is no different than any = other part of the source code.
Reusable YANG is = just as likely or unlikely as reusable C,
depending = on how aware people are of the existing code base.

Which OAM? Read the = modules and decide. No magic there.
How would = /device vs / (as the first node) help you figure this out?

Nobody is objecting at = all to creating structure for the new modules.
If = /device has siblings, then let's see them in the uber-tree.
The objection is to adding in a useless layer, and moving = existing
data nodes, which breaks existing = implementations of all those data = nodes.

Please suggest an alternate approach to the one that is laid = out in draft-openconfig-netmod-model-structure that you believe will = help with the two problems that I raised. I=E2=80=99ll rephrase them = here with less explanation, albeit that comes with less clarity.

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


RTFM

= Andy, 

While it = might be frustrating, coming to an understanding of what the problem is = or might be, and then looking at
why the existing = mechanisms/models or additional ones solve these requirements (or do = not) is what is at hand.  I think everyone agreed
at the = interim meeting that the requirements were clear and sound.  This = is detailed in the meeting minutes.  If anyone disputes = this,
I am happy to do an official WG call for consensus on = these specifics, but given the unanimous agreement at the meeting, I = did
not feel that it was necessary to do this.  Based on = that, the next question is: are these problems solved with what is here = today, 
or do we need another approach/es.  Rob is = clearly not an idiot and is asking for detailed reasons why you and = others
believe what he/OpenConfig have proposed is = insufficient. Please be as considerate and constructive as he has been = in asking his
questions when you address = them. 

=E2=80=94To= m (Speaking as Co-chair)


2) As a creator of YANG = mode

ls, how do I know the targets for references such that I = capture references to the elements that I want, given there is no = currently defined = structure?



The = modules you are using have data locations defined.
In= order to define YANG data (with YANG 1.0 or 1.1)
a = top-level data node or augment-stmt will be present specifying the = /path/from/root

How do you know where data is that has not been defined = yet?
You don't and YANG has no ability to reference = undefined data anyway.


=E2=80=9CJust read through the modules=E2=80=9D is not = acceptable answer when considering making things easy to use for YANG = model consumers. I want to have things that are logical to humans such = that they can easily adopt YANG-based netmgmt. If they need to adopt the = ecosystem by having to use hodgepodge approaches, then this feels like = we are fundamentally missing an opportunity to simplify = things.



Why = isn't RTFM good enough?
Is there some expectation = that just /the/path/from/root is enough
to make = somebody an expert in managing some feature or an expert
in writing new YANG modules?

Additional tools outside the scope of = IETF standardization work are needed
to make = development easier.

Nothing whatsoever is stopping the routing area from defining = some structure
for new modules.  Pick whatever = you like.

The = only pushback is wrt/ obsoleting existing RFC modules and moving = the
data nodes in them to a different location. = Some of us do not agree that
a problem has been = demonstrated that warrants starting over for these = RFCs.


I= want to make sure that we DO have re-usable YANG - like we have = re-usable code elsewhere. In my experience this is done elsewhere by = defining conventions that ensure that this is the = case. 


Regards,
r.

Andy

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

= --Apple-Mail=_1761D307-67E2-43FC-8EA0-6A2CA1A4C418-- From nobody Thu Aug 27 11:19:25 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5AB81ACF0A for ; Thu, 27 Aug 2015 11:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifQcOr9O5Gc7 for ; Thu, 27 Aug 2015 11:19:18 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC19B1ACD55 for ; Thu, 27 Aug 2015 11:19:16 -0700 (PDT) Received: from [96.22.157.164] (helo=corretto) by cappuccino.rob.sh with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1ZV1lL-0007Qe-Nf; Thu, 27 Aug 2015 19:19:00 +0100 Date: Thu, 27 Aug 2015 14:19:11 -0400 From: Rob Shakir To: Andy Bierman Message-ID: In-Reply-To: References: X-Mailer: Airmail Beta (323) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="55df549f_735a674e_1ef8" Archived-At: Cc: "=?utf-8?Q?netmod=40ietf.org?=" Subject: Re: [netmod] Motivations for Structuring Models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 18:19:23 -0000 --55df549f_735a674e_1ef8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Andy, I=E2=80=99m struggling with this debate. On August 27, 2015 at 13:59:55, Andy Bierman (andy=40yumaworks.com) wrote= : Sorry -- are you suggesting that maybe /device adds no value beyond /=3F If so, I agree. No, I am suggesting that should understand what the alternatives to solvi= ng issues are, before moving on to debating the merits of a particular so= lution that has nothing to compare and contrast against. One container does not add value, the structure (which happens to start w= ith /device in ONE proposal, to which there are no alternates) is what ma= tters. Unfortunately you seem to be stuck on this container. Please ignor= e it and focus on the problems I defined. =C2=A0RT=46M Great. So, I need to go and write a bunch of different implementations of= how to set up a ping, and trawl through a huge number of roots to find t= hings that are related. If this is the approach we take with IET=46 modul= es, then they will be worse to use than the existing configuration approa= ches that we have. At least the vendor specific ones have some form of lo= gic as to how they are usable to consumers. 2) As a creator of YANG models, how do I know the targets for references = such that I capture references to the elements that I want, given there i= s no currently defined structure=3F The modules you are using have data locations defined. In order to define YANG data (with YANG 1.0 or 1.1) a top-level data node or augment-stmt will be present specifying the /pat= h/from/root How do you know where data is that has not been defined yet=3F You don't and YANG has no ability to reference undefined data anyway. Consider VRRP =E2=80=98tracking=E2=80=99. I want to be able to add some f= orm of new thing that VRRP might track. If we=E2=80=99ve defined a struct= ure that says that there is some list of =E2=80=98tracking-objects=E2=80=99= that I can leafref to, then my new OAM mechanism can augment there. If t= here is no such structure, then we cannot do that, and rather the VRR=46 = model only leafrefs to the currently known paths (my =E2=80=98track=E2=80= =99 leaf has explicit leafref to a subset of =E2=80=98ping=E2=80=99 and k= nown continuity checks when I wrote the module). Adding the new OAM mecha= nism then means a new version of the VRRP module - which seems suboptimal= . The first approach is cleaner, but needs someone to define the structur= e such that we get it right. Nothing whatsoever is stopping the routing area from defining some struct= ure for new modules.=C2=A0 Pick whatever you like. The only pushback is wrt/ obsoleting existing R=46C modules and moving th= e data nodes in them to a different location. Some of us do not agree that a problem has been demonstrated that warrants starting over for these R=46= Cs. Defining structure with arbitrary subsets of the tree doesn=E2=80=99t hel= p=21 As an operator I want to be able to configure a device, because this= is what my network is built from. Not IET=46 areas. Do you suggest that the existing models are placed as a constraint on any= new work in YANG=3F If so, I=E2=80=99d be grateful if you can point out = to me what the precedent is to show that they are useful in the real worl= d=3F Kind regards, r. --55df549f_735a674e_1ef8 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

Hi Andy,

I=E2=80=99m struggling = with this debate.

On August 27, 2015 a= t 13:59:55, Andy Bierman (and= y=40yumaworks.com) wrote:


Sorry -- = are you suggesting that maybe /device adds no value beyond /=3F
If so, I agree.
<= /div>

No, I am suggesting that should understand what the alternatives = to solving issues are, before moving on to debating the merits of a parti= cular solution that has nothing to compare and contrast against.

On= e container does not add value, the structure (which happens to start wit= h /device in ONE proposal, to which there are no alternates) is what matt= ers. Unfortunately you seem to be stuck on this container. Please ignore = it and focus on the problems I defined.

=
 RT=46M

Great. So, I need to go and write a bunch of different impleme= ntations of how to set up a ping, and trawl through a huge number of root= s to find things that are related. If this is the approach we take with I= ET=46 modules, then they will be worse to use than the existing configura= tion approaches that we have. At least the vendor specific ones have some= form of logic as to how they are usable to consumers.

2) As a c= reator of YANG models, how do I know the targets for references such that= I capture references to the elements that I want, given there is no curr= ently defined structure=3F

T= he modules you are using have data locations defined.
In order = to define YANG data (with YANG 1.0 or 1.1)
a top-level data nod= e or augment-stmt will be present specifying the /path/from/root

How do you know where data is that has not been defined = yet=3F
You don't and YANG has no ability to reference undefined= data anyway.

Conside= r VRRP =E2=80=98tracking=E2=80=99. I want to be able to add some form of = new thing that VRRP might track. If we=E2=80=99ve defined a structure tha= t says that there is some list of =E2=80=98tracking-objects=E2=80=99 that= I can leafref to, then my new OAM mechanism can augment there. If there = is no such structure, then we cannot do that, and rather the VRR=46 model= only leafrefs to the currently known paths (my =E2=80=98track=E2=80=99 l= eaf has explicit leafref to a subset of =E2=80=98ping=E2=80=99 and known = continuity checks when I wrote the module). Adding the new OAM mechanism = then means a new version of the VRRP module - which seems suboptimal. The= first approach is cleaner, but needs someone to define the structure suc= h that we get it right.

=
Nothing whatsoever is stopping the routing area from defining some s= tructure
for new modules.  Pick whatever you like.

The only pushback is wrt/ obsoleting existing R=46C mod= ules and moving the
data nodes in them to a different location.= Some of us do not agree that
a problem has been demonstrated t= hat warrants starting over for these R=46Cs.

Defining structure with arbitrary subsets of the = tree doesn=E2=80=99t help=21 As an operator I want to be able to configur= e a device, because this is what my network is built from. Not IET=46 are= as.

Do you suggest that the existing models are placed as a constra= int on any new work in YANG=3F If so, I=E2=80=99d be grateful if you can = point out to me what the precedent is to show that they are useful in the= real world=3F

Kind regards,
r.

--55df549f_735a674e_1ef8-- From nobody Thu Aug 27 11:29:44 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 225091AD291 for ; Thu, 27 Aug 2015 11:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdZJfMdzcZeT for ; Thu, 27 Aug 2015 11:29:40 -0700 (PDT) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) (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 C78591ACEF8 for ; Thu, 27 Aug 2015 11:29:39 -0700 (PDT) Received: by lbbpu9 with SMTP id pu9so16827365lbb.3 for ; Thu, 27 Aug 2015 11:29:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Eie4EN1OrxgxvY/pGmdhjjoLjJU5fkftROVB6pUaWYY=; b=CZS7VLFvuPKjjcWq+QAwYqJVA7EhmEG+/40K4faQyn2RziU2nbvrvPfVVfDT3g2thX NjLP9/YIWny16AOZQ9FaV12K6uLsV8NDFGXwXHjOGWmNyJBAo5H+/rcafahAyaZR+7GH tDFsMj12+Q8Fgnk/9yZM60yjuq4V6D9JXKcKiH5VlVsfUo8ReJ6G2R3LaYSybLXsmASH 4DC9NZ0yQBoAawtgmJY/gu7RljbkSySts9tnU/eF7DL323YN9cqPgzt8X1q8VlsKkDph ttmfn71A/QPBIHArSWo6kz9rOgvHYeLb+eNQ3sDl4xlyCaM50QZuIHX0WXLtWp5GZEg/ fPiA== X-Gm-Message-State: ALoCoQk1LMGRaX67QMTS+noLKN8sR/sXXE7pgHn6Nxk2KNJldmKdQMOErCkctRZpWsUihiNHL1j1 MIME-Version: 1.0 X-Received: by 10.112.142.6 with SMTP id rs6mr3149878lbb.18.1440700178163; Thu, 27 Aug 2015 11:29:38 -0700 (PDT) Received: by 10.112.77.163 with HTTP; Thu, 27 Aug 2015 11:29:38 -0700 (PDT) In-Reply-To: <6BD6C8DA-AA4A-4BE7-8836-BDC081D3401D@lucidvision.com> References: <6BD6C8DA-AA4A-4BE7-8836-BDC081D3401D@lucidvision.com> Date: Thu, 27 Aug 2015 11:29:38 -0700 Message-ID: From: Andy Bierman To: Nadeau Thomas Content-Type: multipart/alternative; boundary=001a11c3778059020a051e4f267a Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Motivations for Structuring Models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 18:29:43 -0000 --001a11c3778059020a051e4f267a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Aug 27, 2015 at 11:14 AM, Nadeau Thomas wrote: > > On Aug 27, 2015:1:59 PM, at 1:59 PM, Andy Bierman > wrote: > > > > On Thu, Aug 27, 2015 at 10:39 AM, Rob Shakir wrote: > >> >> Andy, >> >> Apologies, I don=E2=80=99t understand how your mail answers the question= s that I >> posed. >> >> On August 27, 2015 at 12:25:20, Andy Bierman (andy@yumaworks.com) wrote: >> >> A whole lots of words here, but I am still confused why /device is bette= r >> than / >> for solving your "data model awareness" problem. >> >> Please re-read my email - here=E2=80=99s the single statement where I sa= id that >> this was NOT the discussion that I think is important: >> >> It strikes me that there is a need to take a step back from the debate o= f >>> whether /device is a good idea or not. >>> >> I=E2=80=99m not sure how this could be clearer. >> >> > Sorry -- are you suggesting that maybe /device adds no value beyond /? > If so, I agree. > > > >> YANG is no different than any other part of the source code. >> Reusable YANG is just as likely or unlikely as reusable C, >> depending on how aware people are of the existing code base. >> >> Which OAM? Read the modules and decide. No magic there. >> How would /device vs / (as the first node) help you figure this out? >> >> Nobody is objecting at all to creating structure for the new modules. >> If /device has siblings, then let's see them in the uber-tree. >> The objection is to adding in a useless layer, and moving existing >> data nodes, which breaks existing implementations of all those data node= s. >> >> Please suggest an alternate approach to the one that is laid out in >> draft-openconfig-netmod-model-structure that you believe will help with = the >> two problems that I raised. I=E2=80=99ll rephrase them here with less ex= planation, >> albeit that comes with less clarity. >> >> 1) As a consumer of YANG models, how do I identify the set of models tha= t >> provide a set of functionality? How do YANG model writers ensure that th= eir >> models are as easy to deal with as possible by having consistent modelli= ng >> approaches for config? >> > > RTFM > > > Andy, > > While it might be frustrating, coming to an understanding of what the > problem is or might be, and then looking at > why the existing mechanisms/models or additional ones solve these > requirements (or do not) is what is at hand. I think everyone agreed > at the interim meeting that the requirements were clear and sound. This > is detailed in the meeting minutes. If anyone disputes this, > I am happy to do an official WG call for consensus on these specifics, bu= t > given the unanimous agreement at the meeting, I did > not feel that it was necessary to do this. Based on that, the next > question is: are these problems solved with what is here today, > or do we need another approach/es. Rob is clearly not an idiot and is > asking for detailed reasons why you and others > believe what he/OpenConfig have proposed is insufficient. Please be as > considerate and constructive as he has been in asking his > questions when you address them. > > Are you suggesting that the openconfig drafts offer some solution to "how do I use this YANG module" that does not involve reading the YANG module? If so, I didn't see it. Please point it out to us. My only objection is to moving data that has already been published in an RFC. I am not the only person on this list that has questioned to value of moving this small number of data models to new roots in the data tree. Everything done in an IETF meeting needs to be confirmed on the mailing list. You know that. So what specifics are you ready to declare have WG consensus? =E2=80=94Tom (Speaking as Co-chair) > > > Andy > 2) As a creator of YANG mode >> > ls, how do I know the targets for references such that I capture >> references to the elements that I want, given there is no currently defi= ned >> structure? >> > > > The modules you are using have data locations defined. > In order to define YANG data (with YANG 1.0 or 1.1) > a top-level data node or augment-stmt will be present specifying the > /path/from/root > > How do you know where data is that has not been defined yet? > You don't and YANG has no ability to reference undefined data anyway. > > > =E2=80=9CJust read through the modules=E2=80=9D is not acceptable answer = when considering >> making things easy to use for YANG model consumers. I want to have thing= s >> that are logical to humans such that they can easily adopt YANG-based >> netmgmt. If they need to adopt the ecosystem by having to use hodgepodge >> approaches, then this feels like we are fundamentally missing an >> opportunity to simplify things. >> > > > Why isn't RTFM good enough? > Is there some expectation that just /the/path/from/root is enough > to make somebody an expert in managing some feature or an expert > in writing new YANG modules? > > Additional tools outside the scope of IETF standardization work are neede= d > to make development easier. > > Nothing whatsoever is stopping the routing area from defining some > structure > for new modules. Pick whatever you like. > > The only pushback is wrt/ obsoleting existing RFC modules and moving the > data nodes in them to a different location. Some of us do not agree that > a problem has been demonstrated that warrants starting over for these RFC= s. > > > > I want to make sure that we DO have re-usable YANG - like we have >> re-usable code elsewhere. In my experience this is done elsewhere by >> defining conventions that ensure that this is the case. >> >> Regards, >> r. >> >> > Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > --001a11c3778059020a051e4f267a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Aug 27, 2015 at 11:14 AM, Nadeau Thomas <<= a href=3D"mailto:tnadeau@lucidvision.com" target=3D"_blank">tnadeau@lucidvi= sion.com> wrote:

On Aug 27, 2015:1:59 = PM, at 1:59 PM, Andy Bierman <andy@yumaworks.com> wrote:



On Thu, A= ug 27, 2015 at 10:39 AM, Rob Shakir <rjs@rob.sh> wrote:

Andy,

Apologies, I don=E2=80=99t understand how your mail an= swers the questions that I posed.

On August 27, 2015 at 12= :25:20, Andy Bierman (andy@yumaworks.com) wrote:

A whole lots of words here, = but I am still confused why /device is better than /
for solving your "data model awareness" problem.

Please re-read my email - = here=E2=80=99s the single statement where I said that this was NOT the disc= ussion that I think is important:

It strikes me that th= ere is a need to take a step back from the debate of whether /device is a g= ood idea or not.

I=E2=80=99m not sure how this could be clearer.

<= /div>

Sorry -- are you suggesti= ng that maybe /device adds no value beyond /?
If so, I agree.

=C2=A0
=
YANG is no different than any other part of the source code.
Reu= sable YANG is just as likely or unlikely as reusable C,
depending= on how aware people are of the existing code base.

Which OAM? Read the modules and decide. No magic there.
How wou= ld /device vs / (as the first node) help you figure this out?
Nobody is objecting at all to creating structure for the new mo= dules.
If /device has siblings, then let's see them in the ub= er-tree.
The objection is to adding in a useless layer, and movin= g existing
data nodes, which breaks existing implementations of a= ll those data nodes.

Pl= ease suggest an alternate approach to the one that is laid out in draft-ope= nconfig-netmod-model-structure that you believe will help with the two prob= lems that I raised. I=E2=80=99ll rephrase them here with less explanation, = albeit that comes with less clarity.

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

=

RTFM

= Andy,=C2=A0

While it might be frustrating, coming to an understanding of= what the problem is or might be, and then looking at
why the exi= sting mechanisms/models or additional ones solve these requirements (or do = not) is what is at hand.=C2=A0 I think everyone agreed
at the int= erim meeting that the requirements were clear and sound.=C2=A0 This is deta= iled in the meeting minutes.=C2=A0 If anyone disputes this,
I am = happy to do an official WG call for consensus on these specifics, but given= the unanimous agreement at the meeting, I did
not feel that it w= as necessary to do this.=C2=A0 Based on that, the next question is: are the= se problems solved with what is here today,=C2=A0
or do we need a= nother approach/es.=C2=A0 Rob is clearly not an idiot and is asking for det= ailed reasons why you and others
believe what he/OpenConfig have = proposed is insufficient. Please be as considerate and constructive as he h= as been in asking his
questions when you address them.=C2=A0


Are you suggesting t= hat the openconfig drafts offer some solution
to "how do I u= se this YANG module" that does not involve reading the YANG module?
If so, I didn't see it.=C2=A0 Please point it out to us.
<= div>
My only objection is to moving data that has already bee= n published in an RFC.
I am not the only person on this list that= has questioned to value of
moving this small number of data mode= ls to new roots in the data tree.

Everything done = in an IETF meeting needs to be confirmed on
the mailing list.= =C2=A0 You know that.=C2=A0

So what specifics= are you ready to declare have WG consensus?




=E2=80=94Tom (Speaking as Co-chair)



Andy
=C2=A0

2) As a creator of YANG mode

ls, how do I know the target= s for references such that I capture references to the elements that I want= , given there is no currently defined structure?



The modules you are using = have data locations defined.
In order to define YANG data (with Y= ANG 1.0 or 1.1)
a top-level data node or augment-stmt will be pre= sent specifying the /path/from/root

How do you kno= w where data is that has not been defined yet?
You don't and = YANG has no ability to reference undefined data anyway.


<= div>

=E2=80=9CJust read through the modules=E2=80=9D is not acceptab= le answer when considering making things easy to use for YANG model consume= rs. I want to have things that are logical to humans such that they can eas= ily adopt YANG-based netmgmt. If they need to adopt the ecosystem by having= to use hodgepodge approaches, then this feels like we are fundamentally mi= ssing an opportunity to simplify things.



Why isn't RTFM good enough?
Is there some expectation that just /the/path/from/root is enough
to make somebody an expert in managing some feature or an expert
in writing new YANG modules?

Additional t= ools outside the scope of IETF standardization work are needed
to= make development easier.

Nothing whatsoever is st= opping the routing area from defining some structure
for new modu= les.=C2=A0 Pick whatever you like.

The only pushba= ck is wrt/ obsoleting existing RFC modules and moving the
data no= des in them to a different location. Some of us do not agree that
a problem has been demonstrated that warrants starting over for these RFCs= .

=

I want to make sure that we DO have re-usable YANG - like we hav= e re-usable code elsewhere. In my experience this is done elsewhere by defi= ning conventions that ensure that this is the case.=C2=A0


Regards,
r.


Andy

_______________________________________________
netmod mailing list
<= a href=3D"mailto:netmod@ietf.org" target=3D"_blank">netmod@ietf.org
= = https://www.ietf.org/mailman/listinfo/netmod

=

--001a11c3778059020a051e4f267a-- From nobody Thu Aug 27 11:48:33 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 849BD1ACEAB for ; Thu, 27 Aug 2015 11:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PfM4tL5wuZTJ for ; Thu, 27 Aug 2015 11:48:29 -0700 (PDT) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7497E1A0461 for ; Thu, 27 Aug 2015 11:48:27 -0700 (PDT) Received: by lbbtg9 with SMTP id tg9so17165373lbb.1 for ; Thu, 27 Aug 2015 11:48: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=TQloR1uG06pWqk5NCzVnJHcxyc3xAuaiq29YOwUD47k=; b=G0U6hLkecmYGX+r+b7esNY6A527+vDZscxHl9mN34BgP0wRl4kRq6tf7gFppYABCHV 2Qde4Smuu8dCgE/+qwnN0A4VvFD7IX47kmEjYko4TVc+SDyzwNwl0xiDpzEbSaRy1KgW 84OjsmIeJv5MtOjmrzJglSujqUfjnLPpqbM8sdzcQ/1+lEkU114X44+IfvbdMivaBcD+ b/Sax69rFb2FLsZqegx/aNIfQrWj7PjDREyAE5bEgVciX7ENGQ0sC2y0BjwmtyVufX3I Zq+tN2qE0b0U3AXQbxPyYhDyHm4nHDS8PPJdR5cu/wVuDEv6Bf6fhXkj3jI5LeNjV3z8 9Ctw== X-Gm-Message-State: ALoCoQlYBV9LzU7+JZkDCoa82qnvV5tCSV8kk5AR7gM2EdZmwswM6YO8Hc1NSH+Y28YvK+rQ/Szz MIME-Version: 1.0 X-Received: by 10.152.42.132 with SMTP id o4mr2956549lal.88.1440701305918; Thu, 27 Aug 2015 11:48:25 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Thu, 27 Aug 2015 11:48:25 -0700 (PDT) In-Reply-To: References: Date: Thu, 27 Aug 2015 11:48:25 -0700 Message-ID: From: Andy Bierman To: Rob Shakir Content-Type: multipart/alternative; boundary=001a11c34ee4912e43051e4f69c6 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Motivations for Structuring Models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 18:48:31 -0000 --001a11c34ee4912e43051e4f69c6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Aug 27, 2015 at 11:19 AM, Rob Shakir wrote: > Hi Andy, > > I=E2=80=99m struggling with this debate. > > On August 27, 2015 at 13:59:55, Andy Bierman (andy@yumaworks.com) wrote: > > > Sorry -- are you suggesting that maybe /device adds no value beyond /? > If so, I agree. > > No, I am suggesting that should understand what the alternatives to > solving issues are, before moving on to debating the merits of a particul= ar > solution that has nothing to compare and contrast against. > There is a proposal for the data root -- use / as we are doing now. > One container does not add value, the structure (which happens to start > with /device in ONE proposal, to which there are no alternates) is what > matters. Unfortunately you seem to be stuck on this container. Please > ignore it and focus on the problems I defined. > > RTFM > > Great. So, I need to go and write a bunch of different implementations of > how to set up a ping, and trawl through a huge number of roots to find > things that are related. If this is the approach we take with IETF module= s, > then they will be worse to use than the existing configuration approaches > that we have. At least the vendor specific ones have some form of logic a= s > to how they are usable to consumers. > Did you really think that just because we created a nice DML that somehow you would not need to know about the topic of your YANG module? I actually have heard this complaint from some people. Great. How does YANG help? I still have to be an expert in MPLS to write a YANG module that manages MPLS. Yep. That's right. Nothing in YANG helps you know more than you do now about specific networking technologies. I don't see what the "huge number of roots" has to do with this issue. > 2) As a creator of YANG models, how do I know the targets for references >> such that I capture references to the elements that I want, given there = is >> no currently defined structure? >> > The modules you are using have data locations defined. > In order to define YANG data (with YANG 1.0 or 1.1) > a top-level data node or augment-stmt will be present specifying the > /path/from/root > > How do you know where data is that has not been defined yet? > You don't and YANG has no ability to reference undefined data anyway. > > Consider VRRP =E2=80=98tracking=E2=80=99. I want to be able to add some f= orm of new thing > that VRRP might track. If we=E2=80=99ve defined a structure that says tha= t there is > some list of =E2=80=98tracking-objects=E2=80=99 that I can leafref to, th= en my new OAM > mechanism can augment there. If there is no such structure, then we canno= t > do that, and rather the VRRF model only leafrefs to the currently known > paths (my =E2=80=98track=E2=80=99 leaf has explicit leafref to a subset o= f =E2=80=98ping=E2=80=99 and known > continuity checks when I wrote the module). Adding the new OAM mechanism > then means a new version of the VRRP module - which seems suboptimal. The > first approach is cleaner, but needs someone to define the structure such > that we get it right. > No matter what set of NP containers you create, there might be stuff that could reasonably be put in different places. So what? This is part of the design choice when picking the one true home for everything. The structure is ad-hoc and arbitrary. Its only value is in the common agreement of where things should go. So make up some structure and fill it in. What's the problem? Nothing whatsoever is stopping the routing area from defining some structur= e > for new modules. Pick whatever you like. > > The only pushback is wrt/ obsoleting existing RFC modules and moving the > data nodes in them to a different location. Some of us do not agree that > a problem has been demonstrated that warrants starting over for these RFC= s. > > Defining structure with arbitrary subsets of the tree doesn=E2=80=99t hel= p! As an > operator I want to be able to configure a device, because this is what my > network is built from. Not IETF areas. > > Do you suggest that the existing models are placed as a constraint on any > new work in YANG? If so, I=E2=80=99d be grateful if you can point out to = me what > the precedent is to show that they are useful in the real world? > I have not seen any evidence that moving /interfaces, /interfaces-state, /nacm, /netconf-state, /netconf, /ipfix, /system and /snmp will solve any real problems. There are implementations of these modules already. Are you suggesting that work the new routing modules cannot proceed because these 8 top-level nodes are somehow preventing this work? Are you suggesting it would solve your OAM or VRRP design problems if the path was /device/interfaces instead of just /interfaces? Kind regards, > r. > > Andy --001a11c34ee4912e43051e4f69c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Aug 27, 2015 at 11:19 AM, Rob Shakir <rjs@rob.sh> wrote= :

Hi Andy,

I=E2=80=99= m struggling with this debate.

On August 27, 2015 at 13:59:55, Andy= Bierman (andy@yuma= works.com) wrote:


Sorry -- are you suggesting that maybe /device adds no val= ue beyond /?
If so, I agree.
<= /span>

No, I am suggesting that should understand what= the alternatives to solving issues are, before moving on to debating the m= erits of a particular solution that has nothing to compare and contrast aga= inst.



There = is a proposal for the data root -- use / as we are doing now.
=C2=A0

One container does not add value, the structure (wh= ich happens to start with /device in ONE proposal, to which there are no al= ternates) is what matters. Unfortunately you seem to be stuck on this conta= iner. Please ignore it and focus on the problems I defined.

=C2=A0RTFM
<= /span>

Great. So, I need to go and write a bunch of di= fferent implementations of how to set up a ping, and trawl through a huge n= umber of roots to find things that are related. If this is the approach we = take with IETF modules, then they will be worse to use than the existing co= nfiguration approaches that we have. At least the vendor specific ones have= some form of logic as to how they are usable to consumers.

=

Did you really think that just because we = created a nice DML that
somehow you would not need to know about = the topic of your YANG module?
I actually have heard this complai= nt from some people.=C2=A0 Great.=C2=A0 How does
YANG help?=C2=A0= I still have to be an expert in MPLS to write a YANG module
that= manages MPLS.=C2=A0 Yep.=C2=A0 That's right.=C2=A0 Nothing in YANG hel= ps you
know more than you do now about specific networking techno= logies.

I don't see what the "huge number= of roots" has to do with this issue.

=C2=A0<= /div>
=

2) As a creator of YANG m= odels, how do I know the targets for references such that I capture referen= ces to the elements that I want, given there is no currently defined struct= ure?

The modules you are using= have data locations defined.
In order to define YANG data (with = YANG 1.0 or 1.1)
a top-level data node or augment-stmt will be pr= esent specifying the /path/from/root

How do you kn= ow where data is that has not been defined yet?
You don't and= YANG has no ability to reference undefined data anyway.
<= /div>

Consider VRRP =E2=80=98tracking=E2=80=99.= I want to be able to add some form of new thing that VRRP might track. If = we=E2=80=99ve defined a structure that says that there is some list of =E2= =80=98tracking-objects=E2=80=99 that I can leafref to, then my new OAM mech= anism can augment there. If there is no such structure, then we cannot do t= hat, and rather the VRRF model only leafrefs to the currently known paths (= my =E2=80=98track=E2=80=99 leaf has explicit leafref to a subset of =E2=80= =98ping=E2=80=99 and known continuity checks when I wrote the module). Addi= ng the new OAM mechanism then means a new version of the VRRP module - whic= h seems suboptimal. The first approach is cleaner, but needs someone to def= ine the structure such that we get it right.


No matter what set of NP containers you create, the= re might be stuff that could
reasonably be put in different place= s.=C2=A0 So what?=C2=A0 This is part of the design choice
when pi= cking the one true home for everything.

The struct= ure is ad-hoc and arbitrary.=C2=A0 Its only value is in the
commo= n agreement of where things should go.=C2=A0 So make up
some stru= cture and fill it in.=C2=A0 What's the problem?


Noth= ing whatsoever is stopping the routing area from defining some structure
for new modules.=C2=A0 Pick whatever you like.

=
The only pushback is wrt/ obsoleting existing RFC modules and moving t= he
data nodes in them to a different location. Some of us do not = agree that
a problem has been demonstrated that warrants starting= over for these RFCs.

D= efining structure with arbitrary subsets of the tree doesn=E2=80=99t help! = As an operator I want to be able to configure a device, because this is wha= t my network is built from. Not IETF areas.

Do you suggest that the e= xisting models are placed as a constraint on any new work in YANG? If so, I= =E2=80=99d be grateful if you can point out to me what the precedent is to = show that they are useful in the real world?


I have not seen any evidence that moving /int= erfaces, /interfaces-state,
/nacm, /netconf-state, /netconf, /ipf= ix, /system and /snmp will solve any real problems.
There are imp= lementations of these modules already.

Are you sug= gesting that work the new routing modules cannot proceed
beca= use these 8 top-level nodes are somehow preventing this work?
Are= you suggesting it would solve your OAM or VRRP design problems
i= f the path was /device/interfaces instead of just /interfaces?


Kind regards,
r.


Andy

--001a11c34ee4912e43051e4f69c6-- From nobody Thu Aug 27 11:56:19 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF8F1B3CDA for ; Thu, 27 Aug 2015 11:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qUb5CqBx423 for ; Thu, 27 Aug 2015 11:56:15 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7534F1B3CD8 for ; Thu, 27 Aug 2015 11:56:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1440701710; bh=w3Ie7JmCoOy3gAtSpZbEH+zGQU/YtSEYfO03zwQ7wO4=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=WrK2kEP8BYPiq3hvo8yx2dSO3D4Zofn2vakzhgBaeovPDy9/4DD3MV+/XuwzxVQRR fYsZ9E2PAdQtIrAy0KMOTU5qCGjd865DER2sijnV9/AllYFX+mDXf9lnkk64zgm/u6 epCK91Fm6BB44lPbwYf7lrEngPl/3kTMgigpuWoE= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; Content-Type: multipart/alternative; boundary="Apple-Mail=_34F85CA9-4102-43A7-8861-02474C90C9AE" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Nadeau Thomas In-Reply-To: Date: Thu, 27 Aug 2015 14:56:12 -0400 Message-Id: References: <6BD6C8DA-AA4A-4BE7-8836-BDC081D3401D@lucidvision.com> To: Andy Bierman X-Mailer: Apple Mail (2.2104) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-ShareWhite: 50.255.148.181 X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=25 Stars=0 Good=0 Friend=2 Surbl=0 Catch=0 r=0 ip=50.255.148.181 X-IP-stats: Notspam Incoming Last 0, First 104, in=1207, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Motivations for Structuring Models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 18:56:18 -0000 --Apple-Mail=_34F85CA9-4102-43A7-8861-02474C90C9AE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 27, 2015:2:29 PM, at 2:29 PM, Andy Bierman = wrote: >=20 >=20 >=20 > On Thu, Aug 27, 2015 at 11:14 AM, Nadeau Thomas = > wrote: >=20 >> On Aug 27, 2015:1:59 PM, at 1:59 PM, Andy Bierman > wrote: >>=20 >>=20 >>=20 >> On Thu, Aug 27, 2015 at 10:39 AM, Rob Shakir > wrote: >>=20 >> Andy, >>=20 >> Apologies, I don=E2=80=99t understand how your mail answers the = questions that I posed. >>=20 >> On August 27, 2015 at 12:25:20, Andy Bierman (andy@yumaworks.com = ) wrote: >>=20 >>> A whole lots of words here, but I am still confused why /device is = better than / >>> for solving your "data model awareness" problem. >>=20 >> Please re-read my email - here=E2=80=99s the single statement where I = said that this was NOT the discussion that I think is important: >>=20 >>> It strikes me that there is a need to take a step back from the = debate of whether /device is a good idea or not. >>>=20 >>=20 >> I=E2=80=99m not sure how this could be clearer. >>=20 >>=20 >> Sorry -- are you suggesting that maybe /device adds no value beyond = /? >> If so, I agree. >>=20 >> =20 >>> YANG is no different than any other part of the source code. >>> Reusable YANG is just as likely or unlikely as reusable C, >>> depending on how aware people are of the existing code base. >>>=20 >>> Which OAM? Read the modules and decide. No magic there. >>> How would /device vs / (as the first node) help you figure this out? >>>=20 >>> Nobody is objecting at all to creating structure for the new = modules. >>> If /device has siblings, then let's see them in the uber-tree. >>> The objection is to adding in a useless layer, and moving existing >>> data nodes, which breaks existing implementations of all those data = nodes. >>=20 >> Please suggest an alternate approach to the one that is laid out in = draft-openconfig-netmod-model-structure that you believe will help with = the two problems that I raised. I=E2=80=99ll rephrase them here with = less explanation, albeit that comes with less clarity. >>=20 >> 1) As a consumer of YANG models, how do I identify the set of models = that provide a set of functionality? How do YANG model writers ensure = that their models are as easy to deal with as possible by having = consistent modelling approaches for config? >>=20 >>=20 >> RTFM >=20 > Andy,=20 >=20 > While it might be frustrating, coming to an understanding of = what the problem is or might be, and then looking at > why the existing mechanisms/models or additional ones solve these = requirements (or do not) is what is at hand. I think everyone agreed > at the interim meeting that the requirements were clear and sound. = This is detailed in the meeting minutes. If anyone disputes this, > I am happy to do an official WG call for consensus on these specifics, = but given the unanimous agreement at the meeting, I did > not feel that it was necessary to do this. Based on that, the next = question is: are these problems solved with what is here today,=20 > or do we need another approach/es. Rob is clearly not an idiot and is = asking for detailed reasons why you and others > believe what he/OpenConfig have proposed is insufficient. Please be as = considerate and constructive as he has been in asking his > questions when you address them.=20 >=20 >=20 > Are you suggesting that the openconfig drafts offer some solution > to "how do I use this YANG module" that does not involve reading the = YANG module? > If so, I didn't see it. Please point it out to us. I am not taking sides. I hope I don=E2=80=99t need to point out = these guys have presented an alternative=20 solution. The WG must consider this seriously as it is a serious = proposal that is being seriously considered in other parts of the IETF such as the routing area. I will = point out again that we are looking at this closely and thoroughly. If its determined to be desired = via consensus,=20 then we will go forward with it; if not, then no. Its my action and job = to determine this and I=E2=80=99ve outlined the process for this.=20 > My only objection is to moving data that has already been published in = an RFC. > I am not the only person on this list that has questioned to value of > moving this small number of data models to new roots in the data tree. >=20 > Everything done in an IETF meeting needs to be confirmed on > the mailing list. You know that.=20 >=20 > So what specifics are you ready to declare have WG consensus? Again, my assumption was that there was sufficient consensus and = understanding around the requirements (not the solutions) after the interim meetings. I = explicitly asked that question at the meeting and went around the WebEx call to confirm. = Those conclusions were documented in the meeting minutes posted on the list. =E2=80=94Tom >=20 >=20 >=20 > =E2=80=94Tom (Speaking as Co-chair) >=20 >=20 >=20 > Andy > =20 >> 2) As a creator of YANG mode >>=20 >> ls, how do I know the targets for references such that I capture = references to the elements that I want, given there is no currently = defined structure? >>=20 >>=20 >>=20 >> The modules you are using have data locations defined. >> In order to define YANG data (with YANG 1.0 or 1.1) >> a top-level data node or augment-stmt will be present specifying the = /path/from/root >>=20 >> How do you know where data is that has not been defined yet? >> You don't and YANG has no ability to reference undefined data anyway. >>=20 >>=20 >> =E2=80=9CJust read through the modules=E2=80=9D is not acceptable = answer when considering making things easy to use for YANG model = consumers. I want to have things that are logical to humans such that = they can easily adopt YANG-based netmgmt. If they need to adopt the = ecosystem by having to use hodgepodge approaches, then this feels like = we are fundamentally missing an opportunity to simplify things. >>=20 >>=20 >>=20 >> Why isn't RTFM good enough? >> Is there some expectation that just /the/path/from/root is enough >> to make somebody an expert in managing some feature or an expert >> in writing new YANG modules? >>=20 >> Additional tools outside the scope of IETF standardization work are = needed >> to make development easier. >>=20 >> Nothing whatsoever is stopping the routing area from defining some = structure >> for new modules. Pick whatever you like. >>=20 >> The only pushback is wrt/ obsoleting existing RFC modules and moving = the >> data nodes in them to a different location. Some of us do not agree = that >> a problem has been demonstrated that warrants starting over for these = RFCs. >>=20 >>=20 >> I want to make sure that we DO have re-usable YANG - like we have = re-usable code elsewhere. In my experience this is done elsewhere by = defining conventions that ensure that this is the case.=20 >>=20 >>=20 >> Regards, >> r. >>=20 >>=20 >> Andy >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod = >=20 >=20 --Apple-Mail=_34F85CA9-4102-43A7-8861-02474C90C9AE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Aug 27, 2015:2:29 PM, at 2:29 PM, Andy Bierman <andy@yumaworks.com> = wrote:



On Thu, Aug 27, 2015 at 11:14 AM, = Nadeau Thomas <tnadeau@lucidvision.com> wrote:

On Aug 27, 2015:1:59 PM, at 1:59 PM, Andy = Bierman <andy@yumaworks.com> wrote:



On Thu, = Aug 27, 2015 at 10:39 AM, Rob Shakir <rjs@rob.sh> wrote:

Andy,

Apologies, I don=E2=80=99t understand how your mail answers = the questions that I posed.

On = August 27, 2015 at 12:25:20, Andy Bierman (andy@yumaworks.com) wrote:

A = whole lots of words here, but I am still confused why /device is better = than /
for = solving your "data model awareness" = problem.

Please re-read my email - here=E2=80=99s the single statement = where I said that this was NOT the discussion that I think is = important:

It strikes me that there is a need to take a = step back from the debate of whether /device is a good idea or = not.

I=E2=80=99m not sure how this could be clearer.


Sorry -- are you = suggesting that maybe /device adds no value beyond /?
If so, I agree.

 
YANG is no different than any = other part of the source code.
Reusable YANG is = just as likely or unlikely as reusable C,
depending = on how aware people are of the existing code base.

Which OAM? Read the = modules and decide. No magic there.
How would = /device vs / (as the first node) help you figure this out?

Nobody is objecting at = all to creating structure for the new modules.
If = /device has siblings, then let's see them in the uber-tree.
The objection is to adding in a useless layer, and moving = existing
data nodes, which breaks existing = implementations of all those data = nodes.

Please suggest an alternate approach to the one that is laid = out in draft-openconfig-netmod-model-structure that you believe will = help with the two problems that I raised. I=E2=80=99ll rephrase them = here with less explanation, albeit that comes with less clarity.

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


RTFM

Andy, 

While it might be frustrating, coming to an = understanding of what the problem is or might be, and then looking = at
why the existing mechanisms/models or additional = ones solve these requirements (or do not) is what is at hand.  I = think everyone agreed
at the interim meeting that = the requirements were clear and sound.  This is detailed in the = meeting minutes.  If anyone disputes this,
I = am happy to do an official WG call for consensus on these specifics, but = given the unanimous agreement at the meeting, I did
not feel that it was necessary to do this.  Based on = that, the next question is: are these problems solved with what is here = today, 
or do we need another = approach/es.  Rob is clearly not an idiot and is asking for = detailed reasons why you and others
believe what = he/OpenConfig have proposed is insufficient. Please be as considerate = and constructive as he has been in asking his
questions when you address them. 

Are you suggesting that the openconfig = drafts offer some solution
to "how do I use this = YANG module" that does not involve reading the YANG module?
If so, I didn't see it.  Please point it out to = us.

= I am not taking sides. I hope I don=E2=80=99t need to = point out these guys have presented an = alternative 
solution. The WG must consider this = seriously as it is a serious proposal that is being = seriously
considered in other parts of the IETF such as the = routing area.  I will point out again that we are
looking = at this closely and thoroughly. If its determined to be desired via = consensus, 
then we will go forward with it; if not, then = no.  Its my action and job to determine this and = I=E2=80=99ve
outlined the process for = this. 

My only objection is to moving = data that has already been published in an RFC.
I = am not the only person on this list that has questioned to value = of
moving this small number of data models to new = roots in the data tree.

Everything done in an IETF meeting needs to be confirmed = on
the mailing list.  You know = that. 

So what specifics are you ready to declare have WG = consensus?

Again, my assumption was that = there was sufficient consensus and understanding around
the = requirements (not the solutions) after the interim meetings.  I = explicitly asked that
question at the meeting and went around = the WebEx call to confirm.   Those conclusions = were
documented in the meeting minutes posted on the = list.

=E2=80=94Tom







=E2=80=94Tom = (Speaking as Co-chair)



Andy
 

2) As a creator of YANG = mode

ls, how do I know the targets for references such that I = capture references to the elements that I want, given there is no = currently defined = structure?



The = modules you are using have data locations defined.
In= order to define YANG data (with YANG 1.0 or 1.1)
a = top-level data node or augment-stmt will be present specifying the = /path/from/root

How do you know where data is that has not been defined = yet?
You don't and YANG has no ability to reference = undefined data anyway.


=E2=80=9CJust read through the modules=E2=80=9D is not = acceptable answer when considering making things easy to use for YANG = model consumers. I want to have things that are logical to humans such = that they can easily adopt YANG-based netmgmt. If they need to adopt the = ecosystem by having to use hodgepodge approaches, then this feels like = we are fundamentally missing an opportunity to simplify = things.



Why = isn't RTFM good enough?
Is there some expectation = that just /the/path/from/root is enough
to make = somebody an expert in managing some feature or an expert
in writing new YANG modules?

Additional tools outside the scope of = IETF standardization work are needed
to make = development easier.

Nothing whatsoever is stopping the routing area from defining = some structure
for new modules.  Pick whatever = you like.

The = only pushback is wrt/ obsoleting existing RFC modules and moving = the
data nodes in them to a different location. = Some of us do not agree that
a problem has been = demonstrated that warrants starting over for these = RFCs.


I= want to make sure that we DO have re-usable YANG - like we have = re-usable code elsewhere. In my experience this is done elsewhere by = defining conventions that ensure that this is the = case. 


Regards,
r.


Andy

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



= --Apple-Mail=_34F85CA9-4102-43A7-8861-02474C90C9AE-- From nobody Thu Aug 27 12:11:25 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2886F1B3438 for ; Thu, 27 Aug 2015 12:11:25 -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 yQ6AZiNx63L6 for ; Thu, 27 Aug 2015 12:11:21 -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 1FC291B350A for ; Thu, 27 Aug 2015 12:11:21 -0700 (PDT) Received: by lbcbn3 with SMTP id bn3so17429955lbc.2 for ; Thu, 27 Aug 2015 12:11: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=IHvG3XTGVFGE9Z1MJiUK6EEIu+eQW1jW5IONOgkJ690=; b=PQeu8HZYbxa4ehpcuPdXWOzQfnqYCYdKpqJtZLYG6enuUCBiuZo84ZUikvFk9odFlX xQvkMTJNHfaca73Y1AEIURblKSrJ0//HXrZcaFKvp85tDHoN2N+RDHslkxTFVzeGGLBB 01aokp3Fd/aINzFlNFNjYhld4H9PzPzf41amUO6A+7O8BOLZC6EEPvZ/rTxBRWIoWGb1 76ptVQMtmYbF1Ry5n0r0oPd8K+mpopNZZ4ulKax5rFYA1JM1GdGfooXVE6Ca5EpqOTFF +7y8cfgZnh3oxL3Uay6jI61QWyaSHNeNqMht10QOa9UVnbuDBkJwG4XVND86eawsy5Yo B7ow== X-Gm-Message-State: ALoCoQlxP/6CqG8PjQlBq//pX0J/D3JPpP7mWXuAv654T0lw2ZCH7QoTPYQZ+s11tuEhfLzNRwBi MIME-Version: 1.0 X-Received: by 10.152.6.133 with SMTP id b5mr2952264laa.33.1440702679433; Thu, 27 Aug 2015 12:11:19 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Thu, 27 Aug 2015 12:11:19 -0700 (PDT) In-Reply-To: References: <6BD6C8DA-AA4A-4BE7-8836-BDC081D3401D@lucidvision.com> Date: Thu, 27 Aug 2015 12:11:19 -0700 Message-ID: From: Andy Bierman To: Nadeau Thomas Content-Type: multipart/alternative; boundary=089e01493fa86f5da0051e4fbb64 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Motivations for Structuring Models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 19:11:25 -0000 --089e01493fa86f5da0051e4fbb64 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Aug 27, 2015 at 11:56 AM, Nadeau Thomas wrote: > > On Aug 27, 2015:2:29 PM, at 2:29 PM, Andy Bierman > wrote: > > > > On Thu, Aug 27, 2015 at 11:14 AM, Nadeau Thomas > wrote: > >> >> On Aug 27, 2015:1:59 PM, at 1:59 PM, Andy Bierman >> wrote: >> >> >> >> On Thu, Aug 27, 2015 at 10:39 AM, Rob Shakir wrote: >> >>> >>> Andy, >>> >>> Apologies, I don=E2=80=99t understand how your mail answers the questio= ns that I >>> posed. >>> >>> On August 27, 2015 at 12:25:20, Andy Bierman (andy@yumaworks.com) wrote= : >>> >>> A whole lots of words here, but I am still confused why /device is >>> better than / >>> for solving your "data model awareness" problem. >>> >>> Please re-read my email - here=E2=80=99s the single statement where I s= aid that >>> this was NOT the discussion that I think is important: >>> >>> It strikes me that there is a need to take a step back from the debate >>>> of whether /device is a good idea or not. >>>> >>> I=E2=80=99m not sure how this could be clearer. >>> >>> >> Sorry -- are you suggesting that maybe /device adds no value beyond /? >> If so, I agree. >> >> >> >>> YANG is no different than any other part of the source code. >>> Reusable YANG is just as likely or unlikely as reusable C, >>> depending on how aware people are of the existing code base. >>> >>> Which OAM? Read the modules and decide. No magic there. >>> How would /device vs / (as the first node) help you figure this out? >>> >>> Nobody is objecting at all to creating structure for the new modules. >>> If /device has siblings, then let's see them in the uber-tree. >>> The objection is to adding in a useless layer, and moving existing >>> data nodes, which breaks existing implementations of all those data >>> nodes. >>> >>> Please suggest an alternate approach to the one that is laid out in >>> draft-openconfig-netmod-model-structure that you believe will help with= the >>> two problems that I raised. I=E2=80=99ll rephrase them here with less e= xplanation, >>> albeit that comes with less clarity. >>> >>> 1) As a consumer of YANG models, how do I identify the set of models >>> that provide a set of functionality? How do YANG model writers ensure t= hat >>> their models are as easy to deal with as possible by having consistent >>> modelling approaches for config? >>> >> >> RTFM >> >> >> Andy, >> >> While it might be frustrating, coming to an understanding of what the >> problem is or might be, and then looking at >> why the existing mechanisms/models or additional ones solve these >> requirements (or do not) is what is at hand. I think everyone agreed >> at the interim meeting that the requirements were clear and sound. This >> is detailed in the meeting minutes. If anyone disputes this, >> I am happy to do an official WG call for consensus on these specifics, >> but given the unanimous agreement at the meeting, I did >> not feel that it was necessary to do this. Based on that, the next >> question is: are these problems solved with what is here today, >> or do we need another approach/es. Rob is clearly not an idiot and is >> asking for detailed reasons why you and others >> believe what he/OpenConfig have proposed is insufficient. Please be as >> considerate and constructive as he has been in asking his >> questions when you address them. >> >> > Are you suggesting that the openconfig drafts offer some solution > to "how do I use this YANG module" that does not involve reading the YANG > module? > If so, I didn't see it. Please point it out to us. > > > I am not taking sides. I hope I don=E2=80=99t need to point out these guy= s have > presented an alternative > solution. The WG must consider this seriously as it is a serious proposal > that is being seriously > considered in other parts of the IETF such as the routing area. I will > point out again that we are > looking at this closely and thoroughly. If its determined to be desired > via consensus, > then we will go forward with it; if not, then no. Its my action and job > to determine this and I=E2=80=99ve > outlined the process for this. > > We are going to interim meetings. We are discussing the issues on the WG mailing list. I was under the impression this is our process. I hope we get past the hand-waving phase and you can enumerate the exact changes and how they are going to be accomplished. For example, do all 7 of the existing RFCs need to recharter and start over? Is a WG going to be formed to create the uber-tree? There have been several objections to moving /interfaces to /device/interfaces. Are you declaring that the IETF agrees that this change is needed, despite all the objections and statements such as "an uber-tree makes things worse"= ? My only objection is to moving data that has already been published in an > RFC. > I am not the only person on this list that has questioned to value of > moving this small number of data models to new roots in the data tree. > > Everything done in an IETF meeting needs to be confirmed on > the mailing list. You know that. > > So what specifics are you ready to declare have WG consensus? > > > Again, my assumption was that there was sufficient consensus and > understanding around > the requirements (not the solutions) after the interim meetings. I > explicitly asked that > question at the meeting and went around the WebEx call to confirm. Thos= e > conclusions were > documented in the meeting minutes posted on the list. > Just because there are objections to a top-level container named /device doesn't mean anything wrt/ the entire list of problems. Stop trying to push these solutions through all-or-none. Even if the IETF agrees to work on a problem, all solutions are subject to review and alteration by the WG. A design team solution is just a starting point (but you know that). >From my reading of the email (from Juergen, Tom, and others) there are real concerns that we have not agreed on the problems to be solved. > > =E2=80=94Tom > > Andy > > > > > > > =E2=80=94Tom (Speaking as Co-chair) >> >> >> > Andy > > >> 2) As a creator of YANG mode >>> >> ls, how do I know the targets for references such that I capture >>> references to the elements that I want, given there is no currently def= ined >>> structure? >>> >> >> >> The modules you are using have data locations defined. >> In order to define YANG data (with YANG 1.0 or 1.1) >> a top-level data node or augment-stmt will be present specifying the >> /path/from/root >> >> How do you know where data is that has not been defined yet? >> You don't and YANG has no ability to reference undefined data anyway. >> >> >> =E2=80=9CJust read through the modules=E2=80=9D is not acceptable answer= when considering >>> making things easy to use for YANG model consumers. I want to have thin= gs >>> that are logical to humans such that they can easily adopt YANG-based >>> netmgmt. If they need to adopt the ecosystem by having to use hodgepodg= e >>> approaches, then this feels like we are fundamentally missing an >>> opportunity to simplify things. >>> >> >> >> Why isn't RTFM good enough? >> Is there some expectation that just /the/path/from/root is enough >> to make somebody an expert in managing some feature or an expert >> in writing new YANG modules? >> >> Additional tools outside the scope of IETF standardization work are need= ed >> to make development easier. >> >> Nothing whatsoever is stopping the routing area from defining some >> structure >> for new modules. Pick whatever you like. >> >> The only pushback is wrt/ obsoleting existing RFC modules and moving the >> data nodes in them to a different location. Some of us do not agree that >> a problem has been demonstrated that warrants starting over for these >> RFCs. >> >> >> >> I want to make sure that we DO have re-usable YANG - like we have >>> re-usable code elsewhere. In my experience this is done elsewhere by >>> defining conventions that ensure that this is the case. >>> >>> Regards, >>> r. >>> >>> >> Andy >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> >> >> > > --089e01493fa86f5da0051e4fbb64 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Aug 27, 2015 at 11:56 AM, Nadeau Thomas <<= a href=3D"mailto:tnadeau@lucidvision.com" target=3D"_blank">tnadeau@lucidvi= sion.com> wrote:

On Aug = 27, 2015:2:29 PM, at 2:29 PM, Andy Bierman <andy@yumaworks.com> wrote:



On Thu, Aug 27, 2015 at 11:14 AM, Nadeau Thomas <= tnadeau@lucidv= ision.com> wrote:

On Aug 27, 2015:1:59 = PM, at 1:59 PM, Andy Bierman <andy@yumaworks.com> wrote:



On Thu, A= ug 27, 2015 at 10:39 AM, Rob Shakir <rjs@rob.sh> wrote:

Andy,

Apologies, I don=E2=80=99t understand how your mail an= swers the questions that I posed.

On August 27, 2015 at 12= :25:20, Andy Bierman (andy@yumaworks.com) wrote:

A whole lots of words here, = but I am still confused why /device is better than /
for solving your "data model awareness" problem.

Please re-read my email - = here=E2=80=99s the single statement where I said that this was NOT the disc= ussion that I think is important:

It strikes me that th= ere is a need to take a step back from the debate of whether /device is a g= ood idea or not.

I=E2=80=99m not sure how this could be clearer.

<= /div>

Sorry -- are you suggesti= ng that maybe /device adds no value beyond /?
If so, I agree.

=C2=A0
=
YANG is no different than any other part of the source code.
Reu= sable YANG is just as likely or unlikely as reusable C,
depending= on how aware people are of the existing code base.

Which OAM? Read the modules and decide. No magic there.
How wou= ld /device vs / (as the first node) help you figure this out?
Nobody is objecting at all to creating structure for the new mo= dules.
If /device has siblings, then let's see them in the ub= er-tree.
The objection is to adding in a useless layer, and movin= g existing
data nodes, which breaks existing implementations of a= ll those data nodes.

Pl= ease suggest an alternate approach to the one that is laid out in draft-ope= nconfig-netmod-model-structure that you believe will help with the two prob= lems that I raised. I=E2=80=99ll rephrase them here with less explanation, = albeit that comes with less clarity.

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

=

RTFM

= Andy,=C2=A0

While it might be frustrating, coming to an understanding of= what the problem is or might be, and then looking at
why the exi= sting mechanisms/models or additional ones solve these requirements (or do = not) is what is at hand.=C2=A0 I think everyone agreed
at the int= erim meeting that the requirements were clear and sound.=C2=A0 This is deta= iled in the meeting minutes.=C2=A0 If anyone disputes this,
I am = happy to do an official WG call for consensus on these specifics, but given= the unanimous agreement at the meeting, I did
not feel that it w= as necessary to do this.=C2=A0 Based on that, the next question is: are the= se problems solved with what is here today,=C2=A0
or do we need a= nother approach/es.=C2=A0 Rob is clearly not an idiot and is asking for det= ailed reasons why you and others
believe what he/OpenConfig have = proposed is insufficient. Please be as considerate and constructive as he h= as been in asking his
questions when you address them.=C2=A0


Are you suggesting t= hat the openconfig drafts offer some solution
to "how do I u= se this YANG module" that does not involve reading the YANG module?
If so, I didn't see it.=C2=A0 Please point it out to us.
<= /div>

I am not taking sides. I hope I don=E2=80=99t need to = point out these guys have presented an alternative=C2=A0
solution= . The WG must consider this seriously as it is a serious proposal that is b= eing seriously
considered in other parts of the IETF such as the = routing area.=C2=A0 I will point out again that we are
looking at= this closely and thoroughly. If its determined to be desired via consensus= ,=C2=A0
then we will go forward with it; if not, then no.=C2=A0 I= ts my action and job to determine this and I=E2=80=99ve
outlined = the process for this.=C2=A0


We are going to interim meetings.
We a= re discussing the issues on the WG mailing list.
I was under the = impression this is our process.

I hope we get past= the hand-waving phase and
you can enumerate the exact changes an= d how they are going
to be accomplished.=C2=A0 For example, do al= l 7 of the existing RFCs need
to recharter and start over? Is a W= G going to be formed to create the uber-tree?

Ther= e have been several objections to moving /interfaces to /device/interfaces.=
Are you declaring that the IETF agrees that this change is neede= d, despite
all the objections and statements such as "an ube= r-tree makes things worse"?


=
=
My only objection is to moving data that ha= s already been published in an RFC.
I am not the only person on t= his list that has questioned to value of
moving this small number= of data models to new roots in the data tree.

Eve= rything done in an IETF meeting needs to be confirmed on
the = mailing list.=C2=A0 You know that.=C2=A0

So w= hat specifics are you ready to declare have WG consensus?
=

Again, my assumption was that there was sufficient consensus= and understanding around
the requirements (not the solutions) af= ter the interim meetings.=C2=A0 I explicitly asked that
question = at the meeting and went around the WebEx call to confirm. =C2=A0 Those conc= lusions were
documented in the meeting minutes posted on the list= .


Just bec= ause there are objections to a top-level container
named /device = doesn't mean anything wrt/ the entire list of problems.
Stop = trying to push these solutions through all-or-none.
Even if the I= ETF agrees to work on a problem, all solutions
are subject to rev= iew and alteration by the WG.=C2=A0 A design team
solution is jus= t a starting point (but you know that).

From my re= ading of the email (from Juergen, Tom, and others) there
are real= concerns that we have not agreed on the problems to be solved.
<= br>
=C2=A0

=E2=80=94Tom


Andy
=C2=A0
<= div style=3D"word-wrap:break-word">


=




=E2=80=94Tom (Speaking = as Co-chair)


Andy
=C2=A0

2) As a creator of YANG = mode

ls, how do I know the targets for references such that I= capture references to the elements that I want, given there is no currentl= y defined structure?



The modules you are using have data locations defined.=
In order to define YANG data (with YANG 1.0 or 1.1)
a = top-level data node or augment-stmt will be present specifying the /path/fr= om/root

How do you know where data is that has not= been defined yet?
You don't and YANG has no ability to refer= ence undefined data anyway.


=E2=80=9CJust re= ad through the modules=E2=80=9D is not acceptable answer when considering m= aking things easy to use for YANG model consumers. I want to have things th= at are logical to humans such that they can easily adopt YANG-based netmgmt= . If they need to adopt the ecosystem by having to use hodgepodge approache= s, then this feels like we are fundamentally missing an opportunity to simp= lify things.


Why isn't RTFM good enough?
Is there some expect= ation that just /the/path/from/root is enough
to make somebody an= expert in managing some feature or an expert
in writing new YANG= modules?

Additional tools outside the scope of IE= TF standardization work are needed
to make development easier.

Nothing whatsoever is stopping the routing area from= defining some structure
for new modules.=C2=A0 Pick whatever you= like.

The only pushback is wrt/ obsoleting existi= ng RFC modules and moving the
data nodes in them to a different l= ocation. Some of us do not agree that
a problem has been demonstr= ated that warrants starting over for these RFCs.


I want to make su= re that we DO have re-usable YANG - like we have re-usable code elsewhere. = In my experience this is done elsewhere by defining conventions that ensure= that this is the case.=C2=A0


Regards,
r.


Andy

_______________________________________________
netmod mailing list
<= a href=3D"mailto:netmod@ietf.org" target=3D"_blank">netmod@ietf.org
= = https://www.ietf.org/mailman/listinfo/netmod

=



--089e01493fa86f5da0051e4fbb64-- From nobody Thu Aug 27 12:44:59 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6E31B2ADB for ; Thu, 27 Aug 2015 12:44: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 wP8hGF6-dZJ3 for ; Thu, 27 Aug 2015 12:44:56 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 758621B2C5F for ; Thu, 27 Aug 2015 12:44:56 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 85D5B1AE0973; Thu, 27 Aug 2015 21:44:54 +0200 (CEST) Date: Thu, 27 Aug 2015 21:45:18 +0200 (CEST) Message-Id: <20150827.214518.77501131721951504.mbj@tail-f.com> To: rjs@rob.sh From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Motivations for Structuring Models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 19:44:58 -0000 SGkgUm9iLA0KDQpbSSBhbSByZXBseWluZyB0byB0aGlzIGVtYWlsIHNpbmNlIHlvdSBoYXZlIHlv dXIgdHdvIGlzc3VlcyBjbGVhcmx5DQplbnVtZXJhdGVkIGhlcmU7IHRoYW5rcyBmb3IgZG9pbmcg dGhhdF0NCg0KW3NpZGUgbm90ZTogdGhlIHRleHQgdmVyc2lvbnMgb2YgeW91ciByZXBsaWVzIGFy ZSB2ZXJ5IGRpZmZpY3VsdCB0bw0KcmVhZCBhbmQgdGh1cyByZXBseSB0bzsgeW91ciBtYWlsIGNs aWVudCBkb2Vzbid0IHF1aXRlIGdldCB0aGUNCmNpdGF0aW9uIHJpZ2h0LiAgaXMgdGhlcmUgYW55 IGtub2IgeW91IGNhbiB0d2VhayB0byBpbXByb3ZlIHRoYXQ/XQ0KDQpSb2IgU2hha2lyIDxyanNA cm9iLnNoPiB3cm90ZToNCj4gUGxlYXNlIHJlLXJlYWQgbXkgZW1haWwgLSBoZXJl4oCZcyB0aGUg c2luZ2xlIHN0YXRlbWVudCB3aGVyZSBJIHNhaWQNCj4gdGhhdCB0aGlzDQo+IHdhcyBOT1QgdGhl IGRpc2N1c3Npb24gdGhhdCBJIHRoaW5rIGlzIGltcG9ydGFudDoNCj4gDQo+Pj4gSXQgc3RyaWtl cyBtZSB0aGF0IHRoZXJlIGlzIGEgbmVlZCB0byB0YWtlIGEgc3RlcCBiYWNrIGZyb20gdGhlIGRl YmF0ZQ0KPj4+IG9mIHdoZXRoZXIgL2RldmljZSBpcyBhIGdvb2QgaWRlYSBvciBub3QuDQoNCk9r LCBJIHdpbGwgdHJ5IHRvIGRvIHRoYXQuDQoNCj4gUGxlYXNlIHN1Z2dlc3QgYW4gYWx0ZXJuYXRl IGFwcHJvYWNoIHRvIHRoZSBvbmUgdGhhdCBpcyBsYWlkIG91dCBpbg0KPiBkcmFmdC1vcGVuY29u ZmlnLW5ldG1vZC1tb2RlbC1zdHJ1Y3R1cmUgdGhhdCB5b3UgYmVsaWV2ZSB3aWxsIGhlbHANCj4g d2l0aCB0aGUgdHdvDQo+IHByb2JsZW1zIHRoYXQgSSByYWlzZWQuIEnigJlsbCByZXBocmFzZSB0 aGVtIGhlcmUgd2l0aCBsZXNzIGV4cGxhbmF0aW9uLA0KPiBhbGJlaXQNCj4gdGhhdCBjb21lcyB3 aXRoIGxlc3MgY2xhcml0eS4NCj4gDQo+DQo+IDEpIEFzIGEgY29uc3VtZXIgb2YgWUFORyBtb2Rl bHMsIGhvdyBkbyBJIGlkZW50aWZ5IHRoZSBzZXQgb2YgbW9kZWxzDQo+IHRoYXQgcHJvdmlkZSBh IHNldCBvZiBmdW5jdGlvbmFsaXR5Pw0KDQpJIHRoaW5rIHRoYXQgbmVpdGhlciB5b3VyIHByb3Bv c2VkIHNvbHV0aW9uIG9yIHdoYXQgd2UgaGF2ZSB0b2RheSAoNw0KcHVibGlzaGVkIG1vZHVsZXMp IHNvbHZlcyB0aGlzIHByb2JsZW0uDQoNClRoaXMgaXMgYSBoYXJkIHByb2JsZW0gdG8gc29sdmUu ICBJdCBpcyBzaW1pbGFyIHRvIHRoZSBwcm9ibGVtIG9mDQpmaW5kaW5nIHRoZSBjb3JyZWN0IGxp bnV4IHBhY2thZ2UgdGhhdCBzb2x2ZXMgYSBnaXZlbiBwcm9ibGVtLiAgSW4NCnNvbWUgY2FzZXMg SSBjYW4gc2VhcmNoIGEgY2VudHJhbCByZWdpc3RyeSAocGFja2FnZSBtYW5hZ2VyKSwgYW5kIGlu DQpzb21lIGNhc2VzIEkgaGF2ZSB0byBleHBhbmQgdGhlIHNlYXJjaC4NCg0KT25lIHNvbHV0aW9u IGlzIHRvIG5vdCBhbGxvdyBleHRlbnNpYmxlIG1vZHVsZXMgYXQgYWxsOyBpbnN0ZWFkIHdlDQp3 b3VsZCB3b3JrIHdpdGggT05FIG1vZGVsIHRoYXQgd2UganVzdCBhZGQgdG8gb3ZlciB0aW1lLCBh bmQgcmVwdWJsaXNoDQp0aGlzIGV2ZXIgZ3Jvd2luZyBtb2R1bGUgd2hlbiB3ZSBuZWVkIHRvLiAg VmVuZG9ycyBhbmQgb3RoZXIgU0RPcw0Kd291bGQgbm90IGJlIGFibGUgdG8gYWRkIHRvIHRoaXMg c2luZ2xlIG1vZHVsZS4gIEkgZG9uJ3QgdGhpbmsgdGhpcyBpcw0KYSByZWFsaXN0aWMgYXBwcm9h Y2guDQoNCkFub3RoZXIgc29sdXRpb24gaXMgdG8gdHJ5IHRvIGhhdmUgc29tZSBraW5kIG9mIHJl Z2lzdHJ5IG9mIGFsbA0KbW9kdWxlcy4gIFRoaXMgbWlnaHQgd29yayBmb3IgSUVURiBtb2R1bGVz LCBidXQgd2hvIGtub3dzIHdoYXQgb3RoZXINClNET3Mgb3IgdmVuZG9ycyBkbz8gIChJbmNpZGVu dGFsbHkgdGhlcmUgaXMgc3VjaCBhIHJlZ2lzdHJ5IGZvciBJRVRGDQptb2R1bGVzLCBtYWludGFp bmVkIGJ5IElBTkENCihodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3lhbmctcGFyYW1l dGVycy95YW5nLXBhcmFtZXRlcnMueGh0bWwjeWFuZy1wYXJhbWV0ZXJzLTEpKQ0KDQpGb3IgTUlC cywgdGhlcmUgYXJlIHNpdGVzIHRoYXQgdHJ5IHRvIGNvbGxlY3QgYWxsIHB1Ymxpc2hlZCBNSUJz LA0KaW5jbHVkaW5nIHZlbmRvciBNSUJzLg0KDQoNCj4gSG93IGRvIFlBTkcgbW9kZWwgd3JpdGVy cw0KPiBlbnN1cmUgdGhhdCB0aGVpciBtb2RlbHMgYXJlIGFzIGVhc3kgdG8gZGVhbCB3aXRoIGFz IHBvc3NpYmxlIGJ5DQo+IGhhdmluZyBjb25zaXN0ZW50IG1vZGVsbGluZyBhcHByb2FjaGVzIGZv ciBjb25maWc/DQoNCkhtbSwgeW91ciBxdWVzdGlvbiBjb250YWlucyB0aGUgYW5zd2VyOyB0aGF0 J3MgY2hlYXRpbmcgOy0pDQoNClNob3VsZG4ndCB0aGUgcXVlc3Rpb24gYmU6DQoNCiAgSG93IGRv IFlBTkcgbW9kZWwgd3JpdGVycyBlbnN1cmUgdGhhdCB0aGVpciBtb2RlbHMgYXJlIGFzIGVhc3kg dG8NCiAgZGVhbCB3aXRoIGFzIHBvc3NpYmxlPw0KDQpUaGUgYW5zd2VyIHRvIHRoaXMgb25lIGlz IHRoZSBzYW1lIGFzIHRvIHRoZSBxdWVzdGlvbiBob3cgZG8gYSBDDQpwcm9ncmFtbWVyIGVuc3Vy ZSB0aGF0IGhpcyBwcm9ncmFtIGlzIGFzIGVhc3kgdG8gZGVhbCB3aXRoIGFzDQpwb3NzaWJsZT8N Cg0KPiAyKSBBcyBhIGNyZWF0b3Igb2YgWUFORyBtb2RlbHMsIGhvdyBkbyBJIGtub3cgdGhlIHRh cmdldHMgZm9yDQo+IHJlZmVyZW5jZXMgc3VjaCB0aGF0IEkgY2FwdHVyZSByZWZlcmVuY2VzIHRv IHRoZSBlbGVtZW50cyB0aGF0IEkNCj4gd2FudCwgZ2l2ZW4gdGhlcmUgaXMgbm8gY3VycmVudGx5 IGRlZmluZWQgc3RydWN0dXJlPw0KDQpBZ2FpbiB5b3VyIHF1ZXN0aW9uIGlzIGJpYXNlZC4uLiAg c2hvdWxkbid0IGl0IGJlOg0KDQogIEFzIGEgY3JlYXRvciBvZiBZQU5HIG1vZGVscywgaG93IGRv IEkga25vdyB0aGUgdGFyZ2V0cyBmb3INCiAgcmVmZXJlbmNlcyBzdWNoIHRoYXQgSSBjYXB0dXJl IHJlZmVyZW5jZXMgdG8gdGhlIGVsZW1lbnRzIHRoYXQgSQ0KICB3YW50Pw0KDQpBbmQgdGhlIGFu c3dlciB0byB0aGlzIG9uZSBpcyB0aGUgc2FtZSBhcyB0byBxdWVzdGlvbiAxIC0gSSBkb24ndA0K dGhpbmsgeW91ciBwcm9wb3NhbCBzb2x2ZXMgdGhpcywgYW5kIHRoZSBzb2x1dGlvbiBpcyB0aGF0 IHlvdSBuZWVkIHRvDQpmaW5kIHRoZXNlIG90aGVyIG1vZHVsZXMuDQoNCj4g4oCcSnVzdCByZWFk IHRocm91Z2ggdGhlIG1vZHVsZXPigJ0gaXMgbm90IGFjY2VwdGFibGUgYW5zd2VyIHdoZW4NCj4g Y29uc2lkZXJpbmcgbWFraW5nIHRoaW5ncyBlYXN5IHRvIHVzZSBmb3IgWUFORyBtb2RlbCBjb25z dW1lcnMuDQoNCkJ1dCBob3cgZG9lcyB0aGUgdG9wLWxldmVsIG5vZGUgL2RldmljZSAoc29ycnks IGJ1dCBJIHJlYWxseSBoYXZlIHRvDQphc2sgdGhpcykgc29sdmUgdGhpcyBwcm9ibGVtPyAgSSAq cmVhbGx5KiBkbyBub3QgdW5kZXJzdGFuZCB0aGlzLg0KRXZlbiB3aXRoIHlvdXIgc29sdXRpb24g eW91J2QgaGF2ZSBhIHNldCBvZiBtb2R1bGVzIHRoYXQgYXVnbWVudCB0aGlzDQpzdHJ1Y3R1cmUs IHJpZ2h0PyAgSG93IGRvIEkga25vdyB3aGF0IHRoZXNlIG90aGVyIG1vZHVsZXMgYXJlPw0KDQpO b3csIEkgc2hvdWxkIGFkZCB0aGF0IHRoZSB3YXkgSSBzZWUgeW91ciBzb2x1dGlvbiBpcyBhIFlB TkcgbW9kdWxlDQp0aGF0IGRlZmluZXMgYSBzdHJ1Y3R1cmUgb2YgTlAtY29udGFpbmVycy4gIFlv dSAob3Igd2FzIGl0IEFuZWVzPykNCnRoZW4gbWVudGlvbmVkIHRoYXQgd2Ugc2hvdWxkbid0IGZv Y3VzIHNvIG11Y2ggb24gdGhlICpZQU5HIG1vZHVsZSo7DQppdCB3YXMgdGhlIHN0cnVjdHVyZSB0 aGF0IHdhcyBpbXBvcnRhbnQuDQoNCg0KL21hcnRpbg0K From nobody Thu Aug 27 12:49:01 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA84F1A6FED for ; Thu, 27 Aug 2015 12:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3duvJ6vLagRo for ; Thu, 27 Aug 2015 12:48:56 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94B151AD0C1 for ; Thu, 27 Aug 2015 12:48:55 -0700 (PDT) Received: from [96.22.157.164] (helo=corretto) by cappuccino.rob.sh with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1ZV3A6-0007jm-Vi; Thu, 27 Aug 2015 20:48:39 +0100 Date: Thu, 27 Aug 2015 15:48:50 -0400 From: Rob Shakir To: Andy Bierman Message-ID: In-Reply-To: References: X-Mailer: Airmail Beta (323) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="55df69a2_520757dc_1ef8" Archived-At: Cc: "=?utf-8?Q?netmod=40ietf.org?=" Subject: Re: [netmod] Motivations for Structuring Models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 19:48:59 -0000 --55df69a2_520757dc_1ef8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Andy, On August 27, 2015 at 14:48:58, Andy Bierman (andy=40yumaworks.com) wrote= : Did you really think that just because we created a nice DML that somehow you would not need to know about the topic of your YANG module=3F= I actually have heard this complaint from some people.=C2=A0 Great.=C2=A0= How does YANG help=3F=C2=A0 I still have to be an expert in MPLS to write a YANG m= odule that manages MPLS.=C2=A0 Yep.=C2=A0 That's right.=C2=A0 Nothing in YANG h= elps you know more than you do now about specific networking technologies. No, I didn=E2=80=99t at all. So, I work operating networks, and the surrounding systems that we use to= manage them. I could consider myself to have some knowledge in the vario= us areas that I=E2=80=99m trying to model right now - and am even luckier= to be able to work with a bunch of folk who have also operated different= networks, such that we can figure out how things should be laid out. So,= we=E2=80=99re writing these modules - and you=E2=80=99ll see them here:=C2= =A0https://github.com/YangModels/yang/tree/master/experimental/openconfig= What I am saying is that as the person looking at how to /actually use/ t= hese modules, it is much, much easier for me if I can have some idea of w= here to find things that I know are related, and have some consistency in= the approach. The group of people that are writing these modules noted the need for us = to have some structure. However, the IET=46 is also writing a bunch of mo= dules, which we figure it=E2=80=99d be super-neat if we can use. So we wrote some conventions, one is a structure; the other is an approac= h for how opstate is modelled. =46rom your mail, I think that you are saying that you don=E2=80=99t care= how we do this. If that=E2=80=99s the case we=E2=80=99ll head off and wr= ite our modules. However, there are two discrepancies: Lots of others in the IET=46 are writing models, and we=E2=80=99d like al= l these to combine to be usable. To do this, we need to agree on a struct= ure. NETMOD looked like the place to do this based on the fact that draft= -ietf-netmod-routing-cfg is a NETMOD draft. So we brought them here.=C2=A0= Your objection is based on a specific subset of models that have already = been created, that you assert will still need to exist. This is then coun= ter to the fact that I can go and model things how I like. Again, it seem= s like raising the issues that we have with these models in context of a = structure should be something raised with NETMOD, given that these docume= nts are the output of NETMOD according to the data tracker. There are really two options: a) NETMOD does not care about how models fit together - because their con= tents are arbitrary. If this is the case, fine, I=E2=80=99ll talk with th= e area directors as to where we should propose these approaches such that= the pan-IET=46 models end up working nicely together within the DML that= this group has defined. b) NETMOD does care, and should try and define a structure because it is = the custodian working group for YANG and YANG models. I think a lot of my problems are solved by having a defined structure for= models, that has been worked through by folks with protocol knowledge, a= nd knowledge of how these elements are used and managed. I would like it = to be adopted by the IET=46. My view is that b) is currently true - and h= ence it was brought to NETMOD. At the moment, I can=E2=80=99t reconcile the apparent disparities between= your statements in this mail and your objections in other messages. =46u= rther to this, I still cannot see any alternative to the structure that w= e did define - so whilst I can remove /device from the start of the path,= which =E2=80=98protects=E2=80=99 /interfaces =5B0=5D - this doesn=E2=80=99= t actually help me progress anything. This is why =E2=80=9C/device or not= =E2=80=9D is irrelevant. r. =5B0=5D: Note that actually, some work to refactor 7223 further to just i= ts path has been done=E2=80=A6=C2=A0https://github.com/YangModels/yang/tr= ee/master/experimental/openconfig/interfaces --55df69a2_520757dc_1ef8 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

Hi Andy,

On Augus= t 27, 2015 at 14:48:58, Andy Bierman (andy=40yumaworks.com) wrote:

<= div>
Did you really think that just because we cre= ated a nice DML that
somehow you would not need to know about t= he topic of your YANG module=3F
I actually have heard this comp= laint from some people.  Great.  How does
YANG help=3F=   I still have to be an expert in MPLS to write a YANG module
<= div>that manages MPLS.  Yep.  That's right.  Nothing in YA= NG helps you
know more than you do now about specific networkin= g technologies.

No, I didn=E2=80=99t at all.

So, I work operating networks, = and the surrounding systems that we use to manage them. I could consider = myself to have some knowledge in the various areas that I=E2=80=99m tryin= g to model right now - and am even luckier to be able to work with a bunc= h of folk who have also operated different networks, such that we can fig= ure out how things should be laid out. So, we=E2=80=99re writing these mo= dules - and you=E2=80=99ll see them here: https://gith= ub.com/YangModels/yang/tree/master/experimental/openconfig

What= I am saying is that as the person looking at how to /actually use/ these= modules, it is much, much easier for me if I can have some idea of where= to find things that I know are related, and have some consistency in the= approach.

The group of people that are writing these modules noted= the need for us to have some structure. However, the IET=46 is also writ= ing a bunch of modules, which we figure it=E2=80=99d be super-neat if we = can use.

So we wrote some conventions, one is a structure; the othe= r is an approach for how opstate is modelled.

=46rom your mail, I t= hink that you are saying that you don=E2=80=99t care how we do this. If t= hat=E2=80=99s the case we=E2=80=99ll head off and write our modules.

<= p>However, there are two discrepancies:

  1. Lots of others in the = IET=46 are writing models, and we=E2=80=99d like all these to combine to = be usable. To do this, we need to agree on a structure. NETMOD looked lik= e the place to do this based on the fact that draft-ietf-netmod-routing-c= fg is a NETMOD draft. So we brought them here. 
  2. Your objecti= on is based on a specific subset of models that have already been created= , that you assert will still need to exist. This is then counter to the f= act that I can go and model things how I like. Again, it seems like raisi= ng the issues that we have with these models in context of a structure sh= ould be something raised with NETMOD, given that these documents are the = output of NETMOD according to the data tracker.
There are r= eally two options:

a) NETMOD does not care about= how models fit together - because their contents are arbitrary. If this = is the case, fine, I=E2=80=99ll talk with the area directors as to where = we should propose these approaches such that the pan-IET=46 models end up= working nicely together within the DML that this group has defined.
b) NETMOD does care, and should try and define a structure because = it is the custodian working group for YANG and YANG models.
I think a lot of my problems are solved by having a defined s= tructure for models, that has been worked through by folks with protocol = knowledge, and knowledge of how these elements are used and managed. I wo= uld like it to be adopted by the IET=46. My view is that b) is currently = true - and hence it was brought to NETMOD.

At th= e moment, I can=E2=80=99t reconcile the apparent disparities between your= statements in this mail and your objections in other messages. =46urther= to this, I still cannot see any alternative to the structure that we did= define - so whilst I can remove /device from the start of the path, whic= h =E2=80=98protects=E2=80=99 /interfaces =5B0=5D - this doesn=E2=80=99t a= ctually help me progress anything. This is why =E2=80=9C/device or not=E2= =80=9D is irrelevant.

r.

=5B0=5D: Note that actually, some work to refactor 7223 further to just= its path has been done=E2=80=A6 https://gi= thub.com/YangModels/yang/tree/master/experimental/openconfig/interfaces

--55df69a2_520757dc_1ef8-- From nobody Thu Aug 27 13:06:30 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58F001B38FE for ; Thu, 27 Aug 2015 13:06: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 RGCzhEGgIYHK for ; Thu, 27 Aug 2015 13:06: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 5D66A1B37E5 for ; Thu, 27 Aug 2015 13:06:28 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id A1F471AE0973; Thu, 27 Aug 2015 22:06:27 +0200 (CEST) Date: Thu, 27 Aug 2015 22:06:52 +0200 (CEST) Message-Id: <20150827.220652.1922127566594038786.mbj@tail-f.com> To: tnadeau@lucidvision.com From: Martin Bjorklund In-Reply-To: <6BD6C8DA-AA4A-4BE7-8836-BDC081D3401D@lucidvision.com> References: <6BD6C8DA-AA4A-4BE7-8836-BDC081D3401D@lucidvision.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Motivations for Structuring Models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 20:06:29 -0000 Nadeau Thomas wrote: > I think everyone agreed > at the interim meeting that the requirements were clear and sound. > This is detailed in the meeting minutes. Which interim meeting do you mean? BTW, are these interim meeting minutes available somewhere? This is not the first time I had to search old emails in order to find interim minutes. The reason I ask is that I don't remember discussing requirements for the structure; I do remember discussing requirements for relating state to config though, but that is a separate issue. /martin From nobody Thu Aug 27 13:37:35 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75CCF1A6F2A for ; Thu, 27 Aug 2015 13:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7CLleo3hkHw for ; Thu, 27 Aug 2015 13:37:23 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE11A1A1BEC for ; Thu, 27 Aug 2015 13:37:21 -0700 (PDT) Received: from [96.22.157.164] (helo=[192.168.1.140]) by cappuccino.rob.sh with esmtpa (Exim 4.80) (envelope-from ) id 1ZV3uy-0007wf-Ji; Thu, 27 Aug 2015 21:37:04 +0100 Message-ID: <55DF74FC.101@rob.sh> Date: Thu, 27 Aug 2015 16:37:16 -0400 From: Rob Shakir User-Agent: Postbox 4.0.3 (Macintosh/20150805) MIME-Version: 1.0 To: Martin Bjorklund References: <20150827.214518.77501131721951504.mbj@tail-f.com> In-Reply-To: <20150827.214518.77501131721951504.mbj@tail-f.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Motivations for Structuring Models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 20:37:32 -0000 Martin, Apologies, I switched to a new client and, wow, yes, it's not readable. I reported a bug and switched clients again... I *hope* this one is more readable (and it was when I checked last). I'll put aside questions of whether the questions I'm asking are completely fair. Apologies. They're written from my perspective of problems I'm actually experiencing. > Martin Bjorklund > August 27, 2015 at 15:45 > 1) As a consumer of YANG models, how do I identify the set of models > that provide a set of functionality? > > I think that neither your proposed solution or what we have today (7 > published modules) solves this problem. I respectfully disagree. By defining some form of structure for the models, I can have a logical grouping that gives me some pointers as to where to find the right things that I need. I want to configure OAM, great, let's go look at /device/logical-network-elements/logical-network-element/network-instances/network-instance/oam-protocols - because that's where all OAM stuff happens to live. If I have to rather look through / to find a subset of some ping functionality in one module, and some in another, it's not clear to me how I even start to find the right thing - because at the moment one type of ping lives in one module, and another in a completely different one, even though they're almost identical in terms of management plane interface. I agree, an alternative is that one can have something that has a registry that defines sets of functionality, and we then need to define the 'blocks' of functionality that we need (hey! this looks a lot like some definition of a set of modules!). If this is a better solution, yes, please, propose it. The way that we proposed in openconfig-model-structure tries to have a way that you can not have a single model code-block and pull in different logical sub-modules, but know where to find the functionality you need. >> How do YANG model writers >> ensure that their models are as easy to deal with as possible by >> having consistent modelling approaches for config? > > Hmm, your question contains the answer; that's cheating ;-) > > Shouldn't the question be: > > How do YANG model writers ensure that their models are as easy to > deal with as possible? > > The answer to this one is the same as to the question how do a C > programmer ensure that his program is as easy to deal with as > possible? How do I write code that is generally easy to deal with? Follow conventions that generally tell me where to put stuff, and how to name it. What I don't understand is why model-structure or opstate is actually different to defining such conventions? >> 2) As a creator of YANG models, how do I know the targets for >> references such that I capture references to the elements that I >> want, given there is no currently defined structure? > > Again your question is biased... shouldn't it be: > > As a creator of YANG models, how do I know the targets for > references such that I capture references to the elements that I > want? > > And the answer to this one is the same as to question 1 - I don't > think your proposal solves this, and the solution is that you need to > find these other modules. Structure really helps me here, since when someone creates a module that wants to reference a particular type of function, then we reference a well-known path for that. If someone adds a function of that type, it must sit in that path so it can be referenced. See the VRRP example I wrote out before. >> “Just read through the modules” is not acceptable answer when >> considering making things easy to use for YANG model consumers. > > But how does the top-level node /device (sorry, but I really have to > ask this) solve this problem? I *really* do not understand this. > Even with your solution you'd have a set of modules that augment this > structure, right? How do I know what these other modules are? > > Now, I should add that the way I see your solution is a YANG module > that defines a structure of NP-containers. You (or was it Anees?) > then mentioned that we shouldn't focus so much on the *YANG module*; > it was the structure that was important. > First off, we drew a picture [0] that showed the set of modules that we figured we might need. These break down into various bits of device functionality. To make this more accessible as something that could be shown in a draft, we expressed it in YANG and used pyang to draw out the tree. The layout of the sets of functions that we have, and how they are grouped, is the important thing. The fact that we are configuring a device makes /device a good starting point. I think this is how you implemented NEDs in NCS too...? Cheers, r. [0]: http://rob.sh/files/model-structure.pdf From nobody Thu Aug 27 14:34:00 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D191A8752 for ; Thu, 27 Aug 2015 14:33:59 -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 H24W29FNwnYU for ; Thu, 27 Aug 2015 14:33:56 -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 06CAF1A89A7 for ; Thu, 27 Aug 2015 14:33:56 -0700 (PDT) Received: by laba3 with SMTP id a3so21066371lab.1 for ; Thu, 27 Aug 2015 14:33:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=SVTRbFyrBwLWR/VW/CnFNVPBjzIuMBiNcFxrA1PSVd0=; b=DvRMEkM8tGn4l/tPzAnl4zWNNHAdmZYvuTtP5IacLiFrmt3mcKU7IDWMcfqwtXV5XE si//N0XpQx+LOj327du8z+4JsP3JwXd5ggOPpIbeZVSj1QNJhXvar7ooZXtiqPyDfOT3 Mtq3odPsueMPTsLcjoKW9RrzKZIYgpK+LmY38S0cb7UU5e0hjybvKJMVLGLV7CPZeGFf Ay86lZFQx8843BgS9E5HW2wATpL30I86y/9hryY/a7nyeQsJVxiDL2zYTI35t82/QAE2 wuT9MSAvCncHkWzExG2RTtUGt/WM8pu6Z6nNXcfEcgxy3/rNIL5fo6kHXTdj7aW/dkxb HSBA== X-Gm-Message-State: ALoCoQnu/DPOHDwF8cOA69Gg/m5qxZxAA5DTIQTiSJsnUMF9Vz4YI96w93c3ECQwtxPwhoU1AxTn MIME-Version: 1.0 X-Received: by 10.112.85.3 with SMTP id d3mr3197312lbz.33.1440711234296; Thu, 27 Aug 2015 14:33:54 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Thu, 27 Aug 2015 14:33:54 -0700 (PDT) In-Reply-To: References: Date: Thu, 27 Aug 2015 14:33:54 -0700 Message-ID: From: Andy Bierman To: Rob Shakir Content-Type: multipart/alternative; boundary=001a1134946c58395f051e51b9d6 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Motivations for Structuring Models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 21:33:59 -0000 --001a1134946c58395f051e51b9d6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Aug 27, 2015 at 12:48 PM, Rob Shakir wrote: > Hi Andy, > > On August 27, 2015 at 14:48:58, Andy Bierman (andy@yumaworks.com) wrote: > > Did you really think that just because we created a nice DML that > somehow you would not need to know about the topic of your YANG module? > I actually have heard this complaint from some people. Great. How does > YANG help? I still have to be an expert in MPLS to write a YANG module > that manages MPLS. Yep. That's right. Nothing in YANG helps you > know more than you do now about specific networking technologies. > > No, I didn=E2=80=99t at all. > > So, I work operating networks, and the surrounding systems that we use to > manage them. I could consider myself to have some knowledge in the variou= s > areas that I=E2=80=99m trying to model right now - and am even luckier to= be able > to work with a bunch of folk who have also operated different networks, > such that we can figure out how things should be laid out. So, we=E2=80= =99re > writing these modules - and you=E2=80=99ll see them here: > https://github.com/YangModels/yang/tree/master/experimental/openconfig > > What I am saying is that as the person looking at how to /actually use/ > these modules, it is much, much easier for me if I can have some idea of > where to find things that I know are related, and have some consistency i= n > the approach. > > The group of people that are writing these modules noted the need for us > to have some structure. However, the IETF is also writing a bunch of > modules, which we figure it=E2=80=99d be super-neat if we can use. > > So we wrote some conventions, one is a structure; the other is an approac= h > for how opstate is modelled. > > From your mail, I think that you are saying that you don=E2=80=99t care h= ow we do > this. If that=E2=80=99s the case we=E2=80=99ll head off and write our mod= ules. > > However, there are two discrepancies: > > 1. Lots of others in the IETF are writing models, and we=E2=80=99d lik= e all > these to combine to be usable. To do this, we need to agree on a struc= ture. > NETMOD looked like the place to do this based on the fact that > draft-ietf-netmod-routing-cfg is a NETMOD draft. So we brought them he= re. > 2. Your objection is based on a specific subset of models that have > already been created, that you assert will still need to exist. This i= s > then counter to the fact that I can go and model things how I like. Ag= ain, > it seems like raising the issues that we have with these models in con= text > of a structure should be something raised with NETMOD, given that thes= e > documents are the output of NETMOD according to the data tracker. > > There are really two options: > > a) NETMOD does not care about how models fit together - because their > contents are arbitrary. If this is the case, fine, I=E2=80=99ll talk with= the area > directors as to where we should propose these approaches such that the > pan-IETF models end up working nicely together within the DML that this > group has defined. > b) NETMOD does care, and should try and define a structure because it is > the custodian working group for YANG and YANG models. > > this is a strawman. Just because some people don't agree that the existing modules should be moved doesn't mean the NETMOD WG wants every module to create its own top-level node. Create some organization for the 194 new modules. I completely agree with you that these modules should be written with a coherent development plan in mind. > I think a lot of my problems are solved by having a defined structure for > models, that has been worked through by folks with protocol knowledge, an= d > knowledge of how these elements are used and managed. I would like it to = be > adopted by the IETF. My view is that b) is currently true - and hence it > was brought to NETMOD > Given that CLIs are being driven by YANG, I completely agree that understanding of the command hierarchy is useful. I have no objections to the creation of a hierarchy or "node placement plan" or whatever. This is a non-issue. The issue I see is whether the existing 7 modules should be grandfathered or whether these RFCs have to be changed to Obsolete status and replaced with new RFCs. Andy > > At the moment, I can=E2=80=99t reconcile the apparent disparities between= your > statements in this mail and your objections in other messages. Further to > this, I still cannot see any alternative to the structure that we did > define - so whilst I can remove /device from the start of the path, which > =E2=80=98protects=E2=80=99 /interfaces [0] - this doesn=E2=80=99t actuall= y help me progress > anything. This is why =E2=80=9C/device or not=E2=80=9D is irrelevant. > > r. > > [0]: Note that actually, some work to refactor 7223 further to just its > path has been done=E2=80=A6 > https://github.com/YangModels/yang/tree/master/experimental/openconfig/in= terfaces > > --001a1134946c58395f051e51b9d6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Aug 27, 2015 at 12:48 PM, Rob Shakir <rjs@rob.sh> wrote= :

Hi Andy,

On August 27, 2015 at 14:48:58, Andy Bierman= (andy@yumaworks.co= m) wrote:

Did you rea= lly think that just because we created a nice DML that
somehow yo= u would not need to know about the topic of your YANG module?
I a= ctually have heard this complaint from some people.=C2=A0 Great.=C2=A0 How = does
YANG help?=C2=A0 I still have to be an expert in MPLS to wri= te a YANG module
that manages MPLS.=C2=A0 Yep.=C2=A0 That's r= ight.=C2=A0 Nothing in YANG helps you
know more than you do now a= bout specific networking technologies.
<= /span>

No, I didn=E2=80=99t at all.

So, I work o= perating networks, and the surrounding systems that we use to manage them. = I could consider myself to have some knowledge in the various areas that I= =E2=80=99m trying to model right now - and am even luckier to be able to wo= rk with a bunch of folk who have also operated different networks, such tha= t we can figure out how things should be laid out. So, we=E2=80=99re writin= g these modules - and you=E2=80=99ll see them here:=C2=A0https://github.com/YangModels/yang/tree/master/experimental/opencon= fig

What I am saying is that as the person looking at how to /act= ually use/ these modules, it is much, much easier for me if I can have some= idea of where to find things that I know are related, and have some consis= tency in the approach.

The group of people that are writing these mod= ules noted the need for us to have some structure. However, the IETF is als= o writing a bunch of modules, which we figure it=E2=80=99d be super-neat if= we can use.

So we wrote some conventions, one is a structure; the ot= her is an approach for how opstate is modelled.

From your mail, I thi= nk that you are saying that you don=E2=80=99t care how we do this. If that= =E2=80=99s the case we=E2=80=99ll head off and write our modules.

How= ever, there are two discrepancies:

  1. Lots of others in the IETF ar= e writing models, and we=E2=80=99d like all these to combine to be usable. = To do this, we need to agree on a structure. NETMOD looked like the place t= o do this based on the fact that draft-ietf-netmod-routing-cfg is a NETMOD = draft. So we brought them here.=C2=A0
  2. Your objection is based on a = specific subset of models that have already been created, that you assert w= ill still need to exist. This is then counter to the fact that I can go and= model things how I like. Again, it seems like raising the issues that we h= ave with these models in context of a structure should be something raised = with NETMOD, given that these documents are the output of NETMOD according = to the data tracker.
There are really two options:
=
a) NETMOD does not care about how models fit together - beca= use their contents are arbitrary. If this is the case, fine, I=E2=80=99ll t= alk with the area directors as to where we should propose these approaches = such that the pan-IETF models end up working nicely together within the DML= that this group has defined.
b) NETMOD does care, and should try= and define a structure because it is the custodian working group for YANG = and YANG models.


this is a strawman.
Just because some people don't agr= ee that the existing modules should be
moved doesn't mean the= NETMOD WG wants every module to create its
own top-level node.

Create some organization for the 194 new modules.
I completely agree with you that these modules should be written w= ith
a coherent development plan in mind.


=C2=A0
I think a lot of my problems are s= olved by having a defined structure for models, that has been worked throug= h by folks with protocol knowledge, and knowledge of how these elements are= used and managed. I would like it to be adopted by the IETF. My view is th= at b) is currently true - and hence it was brought to NETMOD


Given that CLIs are bein= g driven by YANG, I completely agree that
understanding of the co= mmand hierarchy is useful. =C2=A0 I have no objections
to the cre= ation of a hierarchy or "node placement plan" or whatever.
<= div>This is a non-issue.

The issue I see is whethe= r the existing 7 modules should be grandfathered
or whether these= RFCs have to be changed to Obsolete status and replaced
with new= RFCs.



Andy


=C2=A0

At the moment, I can=E2=80=99t reconcile the apparent disparities b= etween your statements in this mail and your objections in other messages. = Further to this, I still cannot see any alternative to the structure that w= e did define - so whilst I can remove /device from the start of the path, w= hich =E2=80=98protects=E2=80=99 /interfaces [0] - this doesn=E2=80=99t actu= ally help me progress anything. This is why =E2=80=9C/device or not=E2=80= =9D is irrelevant.

r.

[0]= : Note that actually, some work to refactor 7223 further to just its path h= as been done=E2=80=A6=C2=A0https://git= hub.com/YangModels/yang/tree/master/experimental/openconfig/interfaces<= /div>


--001a1134946c58395f051e51b9d6-- From nobody Thu Aug 27 15:21:13 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 228661B2F56 for ; Thu, 27 Aug 2015 15:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snr9uLuJgO-R for ; Thu, 27 Aug 2015 15:21:09 -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 08C151B2EF6 for ; Thu, 27 Aug 2015 15:21:08 -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.256.15; Thu, 27 Aug 2015 22:21:05 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.27]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.27]) with mapi id 15.01.0256.013; Thu, 27 Aug 2015 22:21:05 +0000 From: Kent Watsen To: Martin Bjorklund , "tnadeau@lucidvision.com" Thread-Topic: [netmod] Motivations for Structuring Models Thread-Index: AQHQ4NBG8/3jd0Nhp0asxsVvUVRytZ4gCCaAgAAU4ACAAAWPgIAABE+AgAAfTwD//+JuAA== Date: Thu, 27 Aug 2015 22:21:05 +0000 Message-ID: References: <6BD6C8DA-AA4A-4BE7-8836-BDC081D3401D@lucidvision.com> <20150827.220652.1922127566594038786.mbj@tail-f.com> In-Reply-To: <20150827.220652.1922127566594038786.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.13] x-microsoft-exchange-diagnostics: 1; CO1PR05MB459; 5:01aIh1yuCisUEAF8c9/YGBGwNGFnicBwSG8lcVe3xnvN3yhfG0BKWTUUn3gYh3Q/1PJvLj4O+D0eZQkvKb5q78u9qUa7oIW68EbnBf7FjFrQBgAzQ0DUX960WnmisjnfYnkU8+5Ovga4RGPShWO5Hg==; 24:IlJGprD3CaYGdjGFs9x1mhLbgoX0j4gkCpzJJE1TGj2DcIVD9JRL1tsvBK+GNF7IoJ5iYLbJQSVTNKE5P88ZKrLX8vnr8XVN/XeBCr878lE=; 20:J311cMm/rDYDoF468q3+pBPAw0ZvOpSf4IyUR1ZjPXVQFXZMpnl4RU3vyGo7TbclKJnOXodwCJjUreRdngpG6g== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(8121501046)(5005006)(3002001); SRVR:CO1PR05MB459; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; x-forefront-prvs: 06818431B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377424004)(189002)(199003)(10400500002)(40100003)(15975445007)(102836002)(36756003)(86362001)(122556002)(68736005)(4001350100001)(81156007)(64706001)(66066001)(97736004)(5002640100001)(77156002)(5004730100002)(19580395003)(4001540100001)(2656002)(5007970100001)(4001150100001)(87936001)(62966003)(2950100001)(101416001)(50986999)(189998001)(2501003)(2900100001)(5001830100001)(46102003)(5001860100001)(5001770100001)(5001960100002)(5001920100001)(83506001)(92566002)(93886004)(105586002)(106356001)(54356999)(99286002)(76176999)(106116001)(170073001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <1339C2C7159EB746BB662E8A12724392@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Aug 2015 22:21:05.6177 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Motivations for Structuring Models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 22:21:12 -0000 Hi Martin, >BTW, are these interim meeting >minutes available somewhere? This is not the first time I had to >search old emails in order to find interim minutes. I just sent email to the WG chairs alias asking about this. I'm proposing that minutes for interim meetings be linked off the "Minutes" page too, as they are already for conference meetings (http://tools.ietf.org/wg/netmod/minutes) Using the meeting manager tool I have access to, I can see a list of all the interim meetings that were scheduled in 2014 and 2015. And I can drill down to find the link for the minutes that were uploaded for that meeting. Looking at the results (see below), I see that the minutes were uploaded for about 1/2 of the meetings. In some cases, this is an error by the chairs forgetting to upload them or not knowing that they should and, in other cases, this is because (I speculate) that the interim meeting was cancelled and was left dangling. For interim meetings that took place and yet missing minutes, Tom and I will work to get them posted. For the interim meetings that were cancelled, I imagine we can uploaded some fake minutes that just say the meeting was cancelled, though I'd much rather find a way to delete the meeting entirely from the meeting manager tool's record - I'll ask around to see if that's possible... 2015-10-12 : none linked 2015-10-05 : none linked 2015-09-28 : none linked 2015-09-21 : none linked 2015-09-14 : none linked 2015-09-07 : none linked 2015-08-31 : none linked 2015-08-24 :=20 https://www.ietf.org/proceedings/interim/2015/08/24/netmod/minutes/minutes- interim-2015-netmod-15 2015-06-25 : none linked 2015-06-18 : none linked 2015-03-12 : none linked 2015-03-05 :=20 https://www.ietf.org/proceedings/interim/2015/03/04/netmod/minutes/minutes- interim-2015-netmod-5 2015-03-04 : none linked 2015-02-22 : none linked 2015-02-18 :=20 https://www.ietf.org/proceedings/interim/2015/02/18/netmod/minutes/minutes- interim-2015-netmod-4 2015-02-04 :=20 https://www.ietf.org/proceedings/interim/2015/02/04/netmod/minutes/minutes- interim-2015-netmod-3 2015-01-21 :=20 https://www.ietf.org/proceedings/interim/2015/01/21/netmod/minutes/minutes- interim-2015-netmod-2 2015-01-15 : none linked 2015-01-08 : none linked 2015-01-07 :=20 https://www.ietf.org/proceedings/interim/2015/01/07/netmod/minutes/minutes- interim-2015-netmod-1 2014-12-17 :=20 https://www.ietf.org/proceedings/interim/2014/12/17/netmod/minutes/minutes- interim-2014-netmod-19 2014-12-11 : none linked 2014-12-04 : none linked 2014-12-03 :=20 https://www.ietf.org/proceedings/interim/2014/12/03/netmod/minutes/minutes- interim-2014-netmod-18 2014-11-19 :=20 https://www.ietf.org/proceedings/interim/2014/11/19/netmod/minutes/minutes- interim-2014-netmod-17 2014-10-22 : none linked 2014-10-15 :=20 https://www.ietf.org/proceedings/interim/2014/10/15/netmod/minutes/minutes- interim-2014-netmod-15 2014-10-08 :=20 https://www.ietf.org/proceedings/interim/2014/10/08/netmod/minutes/minutes- interim-2014-netmod-14 2014-10-01 :=20 https://www.ietf.org/proceedings/interim/2014/10/01/netmod/minutes/minutes- interim-2014-netmod-13 2014-09-24 : none linked 2014-09-17 :=20 https://www.ietf.org/proceedings/interim/2014/09/17/netmod/minutes/minutes- interim-2014-netmod-11 2014-09-10 : none linked 2014-09-03 :=20 https://www.ietf.org/proceedings/interim/2014/09/03/netmod/minutes/minutes- interim-2014-netmod-9 2014-08-27 :=20 https://www.ietf.org/proceedings/interim/2014/08/27/netmod/minutes/minutes- interim-2014-netmod-8 2014-07-16 : none linked 2014-07-09 :=20 https://www.ietf.org/proceedings/interim/2014/07/09/netmod/minutes/minutes- interim-2014-netmod-6 2014-07-02 :=20 https://www.ietf.org/proceedings/interim/2014/07/02/netmod/minutes/minutes- interim-2014-netmod-5 2014-06-25 : none linked 2014-06-18 : none linked 2014-06-11 :=20 https://www.ietf.org/proceedings/interim/2014/06/11/netmod/minutes/minutes- interim-2014-netmod-2 2014-06-04 :=20 https://www.ietf.org/proceedings/interim/2014/06/04/netmod/minutes/minutes- interim-2014-netmod-1 Kent From nobody Thu Aug 27 15:22:26 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E26E81A9248 for ; Thu, 27 Aug 2015 15:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNx6a8E-JcTY for ; Thu, 27 Aug 2015 15:22:23 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 805C21A9063 for ; Thu, 27 Aug 2015 15:22:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1795; q=dns/txt; s=iport; t=1440714143; x=1441923743; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=GM+KSwxNqVnPv9uToG6U0L7fJc5sYemLMz+mzbvpDS4=; b=cle0xLc9A9Uur1zFeOqjh1BqssVv47lkEAS0feLRJpdRE1CmeWSfCFBP gcoJBFy6Ki+CDvWwP1Od3G1Ac1gVmNT5VfX5yTqCiGvp6OtEM5xlRkbe5 tNH4K2R9UnB96PEzWe5WQlNm5JpCRhprMeKBRpAHBhUCceQ63fS1A7/OW E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AMBQAYjd9V/5NdJa1egxuBPQbFcgKBPTwQAQEBAQEBAYEKhCMBAQEEOj8MBAIBCA4DBAEBAQoUCQcyFAkIAgQOBQiIJsZFAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4thhEAaMQcGgxKBFAEEjGyIUQGnUyaDf3GBByUcgQUBAQE X-IronPort-AV: E=Sophos;i="5.17,423,1437436800"; d="scan'208";a="27930665" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Aug 2015 22:22:22 +0000 Received: from XCH-ALN-019.cisco.com (xch-aln-019.cisco.com [173.36.7.29]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t7RMMMJw011337 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Aug 2015 22:22:22 GMT Received: from xch-aln-019.cisco.com (173.36.7.29) by XCH-ALN-019.cisco.com (173.36.7.29) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 27 Aug 2015 17:22:21 -0500 Received: from xhc-aln-x10.cisco.com (173.36.12.84) by xch-aln-019.cisco.com (173.36.7.29) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Thu, 27 Aug 2015 17:22:21 -0500 Received: from xmb-rcd-x05.cisco.com ([169.254.15.111]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0248.002; Thu, 27 Aug 2015 17:22:21 -0500 From: "Alexander Clemm (alex)" To: Martin Bjorklund Thread-Topic: [netmod] Y34 - root node Thread-Index: AQHQzfwQhTp8SpZgRU2/JK7T0ppEc536tNgA//+74lSAAFbtgIAAz1DkgADCswCABfPJgIAC/IuAgAAMEQCAAKj6AIAAC1YAgAC+7gCAC50MgIAABoyAgAEhX4CAAA01gIABIKqAgAA8e4CAAdMvAIAADywAgAAMDoCACAd/8IAA7B0AgAC1GUA= Date: Thu, 27 Aug 2015 22:22:21 +0000 Message-ID: References: <20150821.150158.491063432174006492.mbj@tail-f.com> <20150827.082706.86671891927608851.mbj@tail-f.com> In-Reply-To: <20150827.082706.86671891927608851.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.204.27] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y34 - root node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 22:22:25 -0000 Yes. The one thing I would add is that validation of the mounted data can = occur in its original path (the authoritative owner (in the distributed cas= e)). It should not be required to do this validation with the chrooted pat= h, although that path can be used by other data nodes that refer to / have = dependencies on the mounted data. =20 Regarding naming, do you have an alternative suggestion? Cheers --- Alex -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com]=20 Sent: Wednesday, August 26, 2015 11:27 PM To: Alexander Clemm (alex) Cc: lhotka@nic.cz; netmod@ietf.org Subject: Re: [netmod] Y34 - root node "Alexander Clemm (alex)" wrote: > - As Martin mentioned, clearly by allowing to mount you are decoupling=20 > schema information and instance population. Regarding the issue of=20 > validation, this can be addressed by several ways. I think that the mount point effectively works as a 'chroot' for all mounte= d data models in the mount point. This means that if ietf-interfaces and i= etf-routing are mounted under /devices/device/data, all XPath expressions a= nd leafref paths and instance-identifiers in these models are evaluated in = a chrooted environment where their '/' is set to /device/device[name=3D'...= ']/data. This is how we implement validation for such modules in our NCS (= manager product). In an implementation that actually does not store the data locally, but fet= ches it from a remote device (like the original mount proposal), it is fine= to push also validation to the remote node. [maybe mount is not a good name for this generalized thing; this term might= make you believe that the data has to be provided by some other server.] /martin From nobody Thu Aug 27 15:30:08 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10BD81B2F1A for ; Thu, 27 Aug 2015 15:30: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 c4wRRGWYTj8t for ; Thu, 27 Aug 2015 15:30:06 -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 2375F1B2EF4 for ; Thu, 27 Aug 2015 15:30:06 -0700 (PDT) Received: by labns7 with SMTP id ns7so21809320lab.0 for ; Thu, 27 Aug 2015 15:30:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=j/U4aimOGHGWQS9gjGXr5yPJ/5n92K5DKmveddRMeO0=; b=Ax0ccezfFL04D4+Nba8v29rA0Ezr3Vdz1WzmBUKf/0SV4zHuuRiG/AtlaENkbE9KN4 opUxDOTO8pIaqWGwZwzUWMDbSiYSrM+ZsvaNqgg8oc34aUEeGWHdZokccpX40KbRSyOp t+xSIRsVAmhPGzD+c/YTdzBXy/MJWQBJTyWvsexksIg4eAY0vVs70IBJLbIsqRuGaZ0c StXagnngNvT3KTuLqi8WxOoQH/H5+xNEdMZHvvBv1sbZPL7Ht0bl3tf33H42n9ImmBSk H5MghU8r06l547B6qR0NaWt1bMVDvmEVNycYsWutYnZQYq2nNo7dMdZml/Qg9D7ZVTVM Lr9Q== X-Gm-Message-State: ALoCoQmAjIH3Z+1K43DfdNZKnfejtwBemTL8AsndcSMDCMM7cpF9UtwBiL+EL6z5CVVa07gZMVUw MIME-Version: 1.0 X-Received: by 10.112.130.97 with SMTP id od1mr3258913lbb.37.1440714604615; Thu, 27 Aug 2015 15:30:04 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Thu, 27 Aug 2015 15:30:04 -0700 (PDT) Date: Thu, 27 Aug 2015 15:30:04 -0700 Message-ID: From: Andy Bierman To: "netmod@ietf.org" Content-Type: multipart/alternative; boundary=047d7b3434363b331e051e5282b7 Archived-At: Subject: [netmod] logical systems model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 22:30:08 -0000 --047d7b3434363b331e051e5282b7 Content-Type: text/plain; charset=UTF-8 Hi, I started a new subject line because the way logical vs. physical systems are managed is a separate issue from the others. +--rw device +--rw logical-network-elements +--rw logical-network-element* [network-element-id] +--rw network-element-id uint8 +--rw network-element-name? string +--rw default-networking-instance-name? string +--rw system-management | +--rw device-view? boolean | +--rw syslog | +--rw dns | +--rw ntp | +--rw statistics-collection | +--rw ssh | +--rw tacacs | +--rw snmp | +--rw netconf I do not know of any systems where the logical view is managed with an array entry like in this proposal. Usually the protocol (or CLI command) picks one logical context and the PDU is for that one logical system. Each logical system is self-contained so that the data models are written for a single system. Putting the multiplexing in the data model adds a lot of extra complexity and protocol overhead for systems that do not have virtual servers. When it comes to converting this tree to CLI (since this is a common practice) the "interfaces" command will become "devices interfaces", "system" becomes "device system", etc. I don't know of any CLIs that work this way. The "nacm enable false" command will become device logical-network-elements logical-network-element 1 \ system-management netconf nacm enable false Andy --047d7b3434363b331e051e5282b7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I started a new subject line becaus= e the way logical vs. physical systems
are managed is a separate = issue from the others.

=C2=A0 =C2=A0+--rw dev= ice
=C2=A0 =C2=A0 =C2=A0 +--rw logical-network-elements
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw logical-network-element* [network-= element-id]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw netwo= rk-element-id =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0uint8
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw network-= element-name? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 string
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw default-networking-ins= tance-name? =C2=A0 string
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 +--rw system-management
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | =C2=A0+--rw device-view? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= boolean
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0+--rw = syslog
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0+--rw dn= s
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0+--rw ntp
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0+--rw statistics-c= ollection
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0+--rw= ssh
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0+--rw taca= cs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0+--rw snmp
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0+--rw netconf


I do not know of any systems wh= ere the logical view
is managed with an array entry like in this = proposal.
Usually the protocol (or CLI command) picks one logical= context
and the PDU is for that one logical system.=C2=A0 Each l= ogical system
is self-contained so that the data models are writt= en for
a single system.

Putting the mult= iplexing in the data model
adds a lot of extra complexity and pro= tocol overhead for
systems that do not have virtual servers.

When it comes to converting this tree to CLI (since th= is
is a common practice) the "interfaces" command will = become
"devices interfaces", "system" becomes= "device system", etc.
I don't know of any CLIs tha= t work this way.

The "nacm enable false"= command will become

device logical-network-elements logical-network= -element 1 \
system-management netconf nacm= enable false


Andy


--047d7b3434363b331e051e5282b7-- From nobody Thu Aug 27 15:35:33 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D441B2FF1 for ; Thu, 27 Aug 2015 15:35:31 -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 egNkuSoNKOkW for ; Thu, 27 Aug 2015 15:35:30 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0706.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::706]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2E421B2FEB for ; Thu, 27 Aug 2015 15:35:29 -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.256.15; Thu, 27 Aug 2015 22:35:26 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.27]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.27]) with mapi id 15.01.0256.013; Thu, 27 Aug 2015 22:35:26 +0000 From: Kent Watsen To: Kent Watsen , Martin Bjorklund , "tnadeau@lucidvision.com" Thread-Topic: [netmod] Motivations for Structuring Models Thread-Index: AQHQ4NBG8/3jd0Nhp0asxsVvUVRytZ4gCCaAgAAU4ACAAAWPgIAABE+AgAAfTwD//+JuAIAABAKA Date: Thu, 27 Aug 2015 22:35:26 +0000 Message-ID: References: <6BD6C8DA-AA4A-4BE7-8836-BDC081D3401D@lucidvision.com> <20150827.220652.1922127566594038786.mbj@tail-f.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.13] x-microsoft-exchange-diagnostics: 1; CO1PR05MB458; 5:OICAvmNlm3hBbpqq6M0uWw4d6weYqbCSssgJJGntmIOnXClFHEiN2nqAQdVy0Ixpl0ZPN/CGmQ3NHmRgO/vT+BPivykAjxQQ5CD6FUiDy1+KQkA0bp2ksSODEWK4PGRDpQn1lwtqEvfC83HiLq6psw==; 24:uwnSRSGL+5o9lS5x+8g1H4qIn0JCZh51CeTWpr+anB1w9Z4FN2QHf3EWNJRTybN7b6+fSzsF5XCbNgfMQhBBwyqiwWataGfKQzN9WdwrVFE=; 20:gfT5qoEDpmJVAq9uevexZc2wS8sNQjvGc/4qVHAhO21AZNyG3AdhxZZC95K+9ittQliBQdi4C8MxkNUp9xl2eA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(8121501046)(5005006)(3002001); SRVR:CO1PR05MB458; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458; x-forefront-prvs: 06818431B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(97736004)(1941001)(2501003)(62966003)(19300405004)(15975445007)(5004730100002)(87936001)(93376004)(40100003)(77156002)(19273905006)(86362001)(64706001)(5001960100002)(2950100001)(5001860100001)(101416001)(5001770100001)(122556002)(66066001)(5001830100001)(83506001)(5007970100001)(2900100001)(189998001)(92566002)(5002640100001)(19580395003)(15188555004)(54356999)(10400500002)(99286002)(106116001)(105586002)(93886004)(102836002)(106356001)(36756003)(2656002)(81156007)(76176999)(4001350100001)(68736005)(50986999)(46102003)(4001540100001)(170073001)(562404015)(563064011)(15302535012); 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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Aug 2015 22:35:26.8912 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB458 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Motivations for Structuring Models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 22:35:31 -0000 One response already, minutes for all interim meetings are linked here: http://www.ietf.org/meeting/interim/proceedings.html This list contains entries other working groups too, and sorting by groups, by clicking "Group" at the top, does not retain the secondary sort on Date, so the NETMOD entries are grouped together, but all out of order - ugh. I'll see if this page can be improved too... Kent From nobody Thu Aug 27 19:05:55 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F421A92E3 for ; Thu, 27 Aug 2015 19:05:54 -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 GNNCIftAqv5n for ; Thu, 27 Aug 2015 19:05:51 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2224C1B363B for ; Thu, 27 Aug 2015 19:05:46 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CAM90761; Fri, 28 Aug 2015 02:05:44 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 28 Aug 2015 03:05:43 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.99]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0235.001; Fri, 28 Aug 2015 10:05:36 +0800 From: Qin Wu To: Andy Bierman , Rob Shakir Thread-Topic: [netmod] Motivations for Structuring Models Thread-Index: AQHQ4NBOADFMJ24pqkmio9Q4U/+UL54fggqAgAEfONA= Date: Fri, 28 Aug 2015 02:05:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA84814B47nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "Carlos Pignataro \(cpignata\)" , "netmod@ietf.org" Subject: Re: [netmod] Motivations for Structuring Models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 02:05:55 -0000 --_000_B8F9A780D330094D99AF023C5877DABA84814B47nkgeml501mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQrlj5Hku7bkuro6IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnXSDk u6PooaggQW5keSBCaWVybWFuDQrlj5HpgIHml7bpl7Q6IDIwMTXlubQ45pyIMjjml6UgMDoyNQ0K 5pS25Lu25Lq6OiBSb2IgU2hha2lyDQrmioTpgIE6IG5ldG1vZEBpZXRmLm9yZw0K5Li76aKYOiBS ZTogW25ldG1vZF0gTW90aXZhdGlvbnMgZm9yIFN0cnVjdHVyaW5nIE1vZGVscw0KDQpPbiBUaHUs IEF1ZyAyNywgMjAxNSBhdCA2OjU2IEFNLCBSb2IgU2hha2lyIDxyanNAcm9iLnNoPG1haWx0bzpy anNAcm9iLnNoPj4gd3JvdGU6DQoNCk5FVE1PRCwNCg0KT25lIG9mIHRoZSBjaGFpcnMgZW5jb3Vy YWdlZCBtZSB0byBwb3N0IHRoaXMgdG8gdGhlIGxpc3QuIEkgZGlkbuKAmXQgcmVhbGx5IGZpbmQg aG93IGl0IGZpdHMgaW4gdG8gdGhlIGV4aXN0aW5nIHRocmVhZHMsIGJ1dCBJIHdhbnRlZCB0byBt YWtlIGFuIG9ic2VydmF0aW9uLg0KDQpJdCBzdHJpa2VzIG1lIHRoYXQgdGhlcmUgaXMgYSBuZWVk IHRvIHRha2UgYSBzdGVwIGJhY2sgZnJvbSB0aGUgZGViYXRlIG9mIHdoZXRoZXIgL2RldmljZSBp cyBhIGdvb2QgaWRlYSBvciBub3QuDQoNCkFzIGEgdXNlciBvZiBzb21ldGhpbmcgdGhhdCByZXN1 bHRzIGZyb20gY29tcGlsaW5nL2dlbmVyYXRpbmcgYmluZGluZ3MgZnJvbSBhIFlBTkcgbW9kZWws IEkgaGF2ZSB0d28gcmVxdWlyZW1lbnRzOg0KDQogICogICBJIG5lZWQgdG8gYmUgYWJsZSB0byBj b21wb3NlIHRoZSByaWdodCBtb2R1bGVzIHRvIGJlIGFibGUgdG8gZ2V0IHRoZSBmdW5jdGlvbmFs aXR5IHRoYXQgdGhhdCB0aGUgdGhpbmcgSeKAmW0gdHJ5aW5nIHRvIGNvbmZpZ3VyZSB1c2VzLg0K DQogICAgICogICBMZXTigJlzIHNheSBJIHdhbnQgdG8gY29uZmlndXJlIHNvbWUgT0FNIGNvbnRp bnVpdHkgY2hlY2tpbmcgZnVuY3Rpb25zIC0gZm9yIGJvdGggTVBMUyBhbmQgSVAuDQogICAgICog ICBSaWdodCBub3csIEkgaGF2ZSB0aGUgY2hvaWNlIG9mIOKAmGlldGYtbHNwcGluZ+KAmSB3aGlj aCBkZWZpbmVzIC9sc3AtcGluZ3MsIHRoZW4g4oCYbXBsc3RwLW9hbeKAmSB3aGljaCBkZWZpbmVz IC9tcGxzdHAtb2FtLiBQcmVzdW1hYmx5IHRoZW4gd2XigJlsbCBoYXZlIOKAmGlldGYtaXAtb2Ft 4oCZIGFuZCB0aGVuIOKAmGlldGYtaXB2Ni1vYW3igJkuDQogICAgICogICBBcyBhIGRldmVsb3Bl ciAtIGhvdyBkbyBJIGZpZ3VyZSBvdXQgd2hpY2ggbW9kZWxzIEkgbmVlZCB0byBidWlsZCBteSBP QU0gZnVuY3Rpb24uIERvIEkgaGF2ZSB0byB0cmF3bCBzb21lIGRpcmVjdG9yeSB0byBmaW5kIGFs bCBvZiB0aGUgZGlmZmVyZW50IGZyYWdtZW50cyBvZiBPQU0NCltRaW5dOiBJIHRoaW5rIHRoaXMg aXMgYWxzbyB3aGF0IExJTUUgV0cgaXMgdHJ5aW5nIHRvIHNvbHZlIGJ5IGRlZmluaW5nIGdlbmVy aWMgWUFORyBtb2RlbCBmb3IgT0FNIHRvIHByb3ZpZGUgdGVjaG5vbG9neSBpbmRlcGVuZGVudCBm cmFtZXdvcmsuIFBsZWFzZSB0YWtlIGEgbG9vayBhdCBMSU1FIFdHIGNoYXJ0ZXI6DQpodHRwOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvbGltZS9jaGFydGVyLw0KDQogICAgICogICBEbyBJIHRo ZW4gbmVlZCB0byBhY2NlcHQgdGhlIGNvbXBsZXhpdHkgb2YgZGVhbGluZyB3aXRoIHRoZSBmYWN0 IHRoYXQgdGhlIHN0cnVjdHVyZXMgb2YgTFNQIHBpbmdzIGlzIGNvbXBsZXRlbHkgZGlmZmVyZW50 IHRvIHRoZSBJUCBPQU0gc3RydWN0dXJlcz8gW0dpdmVuIHRoYXQgdGhlcmUgaXMgbm8gY28tb3Jk aW5hdGlvbiBvZiBtb2RlbHMsIHRoZW4gdGhpcyB3aWxsIGhhcHBlbi5dDQogICAgIEkgdGhpbmsg dGhpcyBpcyBzb21ldGhpbmcgd2UgbmVlZCB0byB0cnkgdG8gYXZvaWQuIEkgYmVsaWV2ZSBjb29y ZGluYXRpb24gb2YgdGhlc2UgbW9kZWxzIGFyZSByZWFsbHkgbmVlZGVkLg0KDQogICogICBBcyBz b21lb25lIHRoYXQgaXMgYnVpbGRpbmcgWUFORyBtb2RlbHMsIGhvdyBkbyBJIGtub3cgd2hlcmUg SSBzaG91bGQgbGVhZi1yZWYgdG9vLg0KDQogICAgICogICBMZXTigJlzIHNheSBJIHdhbnQgdG8g dGllIGFuIE9BTSBwcm9iZSB0byBzb21lIHByb3RvY29sIGxpdmVsaW5lc3MgLSB3aGVyZSBkbyBJ IHBvaW50IG15IGxlYWZyZWYgdG8/IEF0IHRoZSBtb21lbnQsIHdpdGhvdXQgc29tZSBzdHJ1Y3R1 cmUsIHRoYW4gYW55IHBhdGggdGhhdCBpcyBzcGVjaWZpZWQgaXMgcG9pbnRpbmcgdG8gc29tZSBw bGFjZWhvbGRlciBsb2NhdGlvbiwgdW50aWwgd2UgYWdyZWUgd2hlcmUgdGhlIHN0cnVjdHVyZSBt aWdodCBzaXQuDQogICBbUWluXTogVHdvIGNvbW1lbnRzOg0KDQoxLiAgICAgICBJIHRoaW5rIGRy YWZ0LXJ0Z3lhbmdkdC1ydGd3Zy1kZXZpY2UtbW9kZWwtMDAgcHJvdmlkZSBhIGdvb2Qgc3RydWN0 dXJlIGZvciB0aGVzZSBPQU0gbW9kZWxzIG9yZ2FuaXphdGlvbiBidXQgbm90IGxpbWl0ZWQgdG8g cHJvdmlkZSBzdHJ1Y3R1cmUgZm9yIE9BTSBtb2RlbCBvcmdhbml6YXRpb24uDQoNCiAgICAgICAg ICArLS1ydyBsb2dpY2FsLW5ldHdvcmstZWxlbWVudHMNCg0KICAgICAgICAgICAgICAgICstLXJ3 IG5ldHdvcmtpbmctaW5zdGFuY2VzDQoNCiAgICAgICAgICAgICAgICAgICArLS1ydyBuZXR3b3Jr aW5nLWluc3RhbmNlKiBbbmV0d29ya2luZy1pbnN0YW5jZS1uYW1lXQ0KDQogICAgICAgICAgICAg ICAgICAgICAgKy0tcncgb2FtLXByb3RvY29scw0KDQogICAgICAgICAgICAgICAgICAgICAgfCAg Ky0tcncgYmZkDQoNCiAgICAgICAgICAgICAgICAgICAgICB8ICArLS1ydyBjZm0NCg0KICAgICAg ICAgICAgICAgICAgICAgIHwgICstLXJ3IHR3YW1wDQoNCg0KDQoyLiAgICAgICBkcmFmdC10aXNz YS1saW1lLXlhbmctb2FtLW1vZGVsIGFsc28gcHJvdmlkZSBhIGdvb2QgY29tbW9uIHN0cnVjdHVy ZSBmb3IgT0FNIG1vZGVscyBvcmdhbml6YXRpb24uDQpMSU1FIFdHIGlzIGNoYXJ0ZXJlZCB0byB3 b3JrIG9uIGdlbmVyaWMgWUFORyBtb2RlbCBmb3IgT0FNICh0aGUgcmVsZXZhbnQgZHJhZnQgaXMg ZHJhZnQtdGlzc2EtbGltZS15YW5nLW9hbS1tb2RlbClhbmQgcHJvdmlkZXMgYSBjb21tb24gc3Ry dWN0dXJlIGZvciB2YXJpb3VzIE9BTSB0ZWNobm9sb2dpZXMsIHRlY2hub2xvZ3kgc3BlY2lmaWMg T0FNIGRhdGEgbW9kZWxzIHdpbGwgYmUgd29ya2VkIG9uIHJlc3BlY3RpdmUgcHJvdG9jb2wgV0dz KGUuZy4sIEJGRCwgTVBMUykuDQoNClRoZXJlZm9yZSBiYXNlZCBvbiBMSU1FIGNoYXJ0ZXIgKGh0 dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy93Zy9saW1lL2NoYXJ0ZXIvKSwgdGhlIHJlbGF0aW9u IHdpdGggcHJvdG9jb2wgYmFzZWQgT0FNIG1vZGVscyBjYW4gYmUgZGVwaWN0ZWQsIGZvciBleGFt cGxlLCBhcyBmb2xsb3dzOg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0rLSstKy0rLSsN CiAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgTElNRSBnZW58DQogICAgICAgICAgICAgICAg ICAgICAgICAgICB8T0FNIFlBTkcgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0rLSst Ky0rLSsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8DQogICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICAgICAgIHwgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICB8ICAgICAgICAgfCAgICAgICAgICAgICAgICB8DQogICAgKy0rLSstKy0r LSsgICArLSstKy0rLSstKyAgICstKy0rLSstKy0rICstKy0rLSstKy0rICAgICAgKy0rLSstKy0r LSsNCiAgICB8IENGTSAgICAgfCAgIHwgTVBMUy1UUCB8ICAgfCBNUExTICAgIHwgfCBJUCAgICAg IHwgLiAuIC58ICBmb28gICAgfA0KICAgIHxPQU0gWUFORyB8ICAgfE9BTSBZQU5HIHwgICB8T0FN IFlBTkcgfCB8T0FNIFlBTkcgfCAgICAgIHxPQU0gWUFORyB8DQogICAgKy0rLSstKy0rLSsgICAr LSstKy0rLSstKyAgICstKy0rLSstKy0rICstKy0rLSstKy0rICAgICAgKy0rLSstKy0rLSsNCiAg ICAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgfCAgICAgICAg ICAgICAgfA0KICAgICAgICAgIHwgICAgICAgKy0rLSstKy0rLSsgICArLSstKy0rLSstKyAgICAg ICB8ICAgICAgICAgICstKy0rLSstKy0rDQogICAgICAgICAgfCAgICAgICB8IE1QTFMtVFAgfCAg IHwgTVBMUyAgICB8ICAgICAgIHwgICAgIC4gLiAufCAgZm9vICAgIHwNCiAgICAgICAgICB8ICAg ICAgIHxzdWIgdGVjaCB8ICAgfHN1YiB0ZWNoIHwgICAgICAgfCAgICAgICAgICB8c3ViIHRlY2gg fA0K --_000_B8F9A780D330094D99AF023C5877DABA84814B47nkgeml501mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1 IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERl ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30N CnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg6aKE 6K6+5qC85byPIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnAuTXNvTGlzdFBhcmFn cmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0 eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CXRleHQtaW5kZW50OjIxLjBwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWu i+S9kzt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0Kc3Bhbi5IVE1MQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCDpooTorr7moLzlvI8gQ2hh ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiu vuagvOW8jyI7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4w cHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAq Lw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTA3MjMxNzg4MjsNCgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6MTMyNjg2MjI2Mjt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlk aS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1p ZDoxNDI2MjcxNDIyOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRl LWlkczoxNTY4MTYyNjI2IC0xNjM4MzgyOTE4IDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3 Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwxOmxl dmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MjcuMHB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0K b2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGksPG86cD48 L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPuWPkeS7tuS6ujxzcGFu IGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0Ij4gbmV0bW9kIFttYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5v cmddDQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPuS7o+ihqCA8L3Nw YW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+QW5keSBC aWVybWFuPGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7lj5Hp gIHml7bpl7Q8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+IDIwMTU8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQiPuW5tDxzcGFuIGxhbmc9IkVOLVVTIj44PC9zcGFuPuaciDxzcGFu IGxhbmc9IkVOLVVTIj4yODwvc3Bhbj7ml6U8c3BhbiBsYW5nPSJFTi1VUyI+IDA6MjU8YnI+DQo8 L3NwYW4+PGI+5pS25Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxh bmc9IkVOLVVTIj4gUm9iIFNoYWtpcjxicj4NCjwvc3Bhbj48Yj7mioTpgIE8c3BhbiBsYW5nPSJF Ti1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBuZXRtb2RAaWV0Zi5vcmc8YnI+ DQo8L3NwYW4+PGI+5Li76aKYPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxh bmc9IkVOLVVTIj4gUmU6IFtuZXRtb2RdIE1vdGl2YXRpb25zIGZvciBTdHJ1Y3R1cmluZyBNb2Rl bHM8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi Pk9uIFRodSwgQXVnIDI3LCAyMDE1IGF0IDY6NTYgQU0sIFJvYiBTaGFraXIgJmx0OzxhIGhyZWY9 Im1haWx0bzpyanNAcm9iLnNoIiB0YXJnZXQ9Il9ibGFuayI+cmpzQHJvYi5zaDwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHA+PHNwYW4gbGFuZz0i RU4tVVMiPk5FVE1PRCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1V UyI+T25lIG9mIHRoZSBjaGFpcnMgZW5jb3VyYWdlZCBtZSB0byBwb3N0IHRoaXMgdG8gdGhlIGxp c3QuIEkgZGlkbuKAmXQgcmVhbGx5IGZpbmQgaG93IGl0IGZpdHMgaW4gdG8gdGhlIGV4aXN0aW5n IHRocmVhZHMsIGJ1dCBJIHdhbnRlZCB0byBtYWtlIGFuIG9ic2VydmF0aW9uLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj5JdCBzdHJpa2VzIG1lIHRoYXQgdGhl cmUgaXMgYSBuZWVkIHRvIHRha2UgYSBzdGVwIGJhY2sgZnJvbSB0aGUgZGViYXRlIG9mIHdoZXRo ZXIgL2RldmljZSBpcyBhIGdvb2QgaWRlYSBvciBub3QuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHA+PHNwYW4gbGFuZz0iRU4tVVMiPkFzIGEgPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTrl rovkvZMiPnVzZXI8L3NwYW4+PC9lbT4gb2Ygc29tZXRoaW5nIHRoYXQgcmVzdWx0cyBmcm9tIGNv bXBpbGluZy9nZW5lcmF0aW5nIGJpbmRpbmdzIGZyb20gYSBZQU5HIG1vZGVsLCBJIGhhdmUgdHdv IHJlcXVpcmVtZW50czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8 bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxzcGFuIGxh bmc9IkVOLVVTIj5JIG5lZWQgdG8gYmUgYWJsZSB0byBjb21wb3NlIHRoZSByaWdodCBtb2R1bGVz IHRvIGJlIGFibGUgdG8gZ2V0IHRoZSBmdW5jdGlvbmFsaXR5IHRoYXQgdGhhdCB0aGUgdGhpbmcg SeKAmW0gdHJ5aW5nIHRvIGNvbmZpZ3VyZSB1c2VzLg0KPG86cD48L286cD48L3NwYW4+PC9saT48 L3VsPg0KPHVsIHR5cGU9ImRpc2MiPg0KPHVsIHR5cGU9ImNpcmNsZSI+DQo8bGkgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMiBsZm8xIj4NCjxzcGFuIGxhbmc9IkVOLVVTIj5M ZXTigJlzIHNheSBJIHdhbnQgdG8gY29uZmlndXJlIHNvbWUgT0FNIGNvbnRpbnVpdHkgY2hlY2tp bmcgZnVuY3Rpb25zIC0gZm9yIGJvdGggTVBMUyBhbmQgSVAuPG86cD48L286cD48L3NwYW4+PC9s aT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMiBsZm8xIj4NCjxzcGFu IGxhbmc9IkVOLVVTIj5SaWdodCBub3csIEkgaGF2ZSB0aGUgY2hvaWNlIG9mIOKAmGlldGYtbHNw cGluZ+KAmSB3aGljaCBkZWZpbmVzIC9sc3AtcGluZ3MsIHRoZW4g4oCYbXBsc3RwLW9hbeKAmSB3 aGljaCBkZWZpbmVzIC9tcGxzdHAtb2FtLiBQcmVzdW1hYmx5IHRoZW4gd2XigJlsbCBoYXZlIOKA mGlldGYtaXAtb2Ft4oCZIGFuZCB0aGVuIOKAmGlldGYtaXB2Ni1vYW3igJkuPG86cD48L286cD48 L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiMxRjQ5N0Q7bXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6 bDAgbGV2ZWwyIGxmbzEiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjp3aW5kb3d0 ZXh0Ij5BcyBhIGRldmVsb3BlciAtIGhvdyBkbyBJIGZpZ3VyZSBvdXQgd2hpY2ggbW9kZWxzIEkg bmVlZCB0byBidWlsZCBteSBPQU0gZnVuY3Rpb24uIERvIEkgaGF2ZSB0byB0cmF3bCBzb21lIGRp cmVjdG9yeSB0byBmaW5kIGFsbCBvZiB0aGUgZGlmZmVyZW50IGZyYWdtZW50cyBvZiBPQU08L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjwvdWw+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1pbmRlbnQ6MTUuNzVwdCI+DQo8c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltRaW5dOiBJIHRo aW5rIHRoaXMgaXMgYWxzbyB3aGF0IExJTUUgV0cgaXMgdHJ5aW5nIHRvIHNvbHZlIGJ5IGRlZmlu aW5nIGdlbmVyaWMgWUFORyBtb2RlbCBmb3IgT0FNIHRvIHByb3ZpZGUgdGVjaG5vbG9neSBpbmRl cGVuZGVudCBmcmFtZXdvcmsuIFBsZWFzZSB0YWtlIGEgbG9vayBhdA0KIExJTUUgV0cgY2hhcnRl cjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4 dC1pbmRlbnQ6MjEuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy93Zy9s aW1lL2NoYXJ0ZXIvIj5odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvbGltZS9jaGFydGVy LzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8dWwgdHlwZT0i Y2lyY2xlIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IzFGNDk3RDttc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDps MCBsZXZlbDIgbGZvMSI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOndpbmRvd3Rl eHQiPkRvIEkgdGhlbiBuZWVkIHRvIGFjY2VwdCB0aGUgY29tcGxleGl0eSBvZiBkZWFsaW5nIHdp dGggdGhlIGZhY3QgdGhhdCB0aGUgc3RydWN0dXJlcyBvZiBMU1AgcGluZ3MgaXMgY29tcGxldGVs eSBkaWZmZXJlbnQgdG8gdGhlIElQIE9BTSBzdHJ1Y3R1cmVzPyBbR2l2ZW4gdGhhdCB0aGVyZSBp cyBubyBjby1vcmRpbmF0aW9uIG9mIG1vZGVscywgdGhlbiB0aGlzDQo8ZW0+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OuWui+S9kyI+d2lsbDwvc3Bhbj48L2VtPiBoYXBwZW4uXTwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPC91bD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSSB0aGluayB0aGlzIGlz IHNvbWV0aGluZyB3ZSBuZWVkIHRvIHRyeSB0byBhdm9pZC4gSSBiZWxpZXZlIGNvb3JkaW5hdGlv biBvZiB0aGVzZQ0KIG1vZGVscyBhcmUgcmVhbGx5IG5lZWRlZC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omww IGxldmVsMSBsZm8xIj4NCjxzcGFuIGxhbmc9IkVOLVVTIj5BcyBzb21lb25lIHRoYXQgaXMgYnVp bGRpbmcgWUFORyBtb2RlbHMsIGhvdyBkbyBJIGtub3cgd2hlcmUgSSBzaG91bGQgbGVhZi1yZWYg dG9vLg0KPG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPHVsIHR5cGU9ImRpc2MiPg0KPHVs IHR5cGU9ImNpcmNsZSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVs MiBsZm8xIj4NCjxzcGFuIGxhbmc9IkVOLVVTIj5MZXTigJlzIHNheSBJIHdhbnQgdG8gdGllIGFu IE9BTSBwcm9iZSB0byBzb21lIHByb3RvY29sIGxpdmVsaW5lc3MgLSB3aGVyZSBkbyBJIHBvaW50 IG15IGxlYWZyZWYgdG8/IEF0IHRoZSBtb21lbnQsIHdpdGhvdXQNCjxlbT48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk65a6L5L2TIj5zb21lPC9zcGFuPjwvZW0+IHN0cnVjdHVyZSwgdGhhbiBhbnkg cGF0aCB0aGF0IGlzIHNwZWNpZmllZCBpcyBwb2ludGluZyB0byBzb21lIHBsYWNlaG9sZGVyIGxv Y2F0aW9uLCB1bnRpbCB3ZSBhZ3JlZSB3aGVyZSB0aGUgc3RydWN0dXJlIG1pZ2h0IHNpdC48bzpw PjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOyZuYnNwOyBbUWluXTogVHdvIGNvbW1lbnRzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MjcuMHB0O3RleHQtaW5kZW50 Oi0xOC4wcHQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4xLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHRoaW5rIGRyYWZ0LXJ0Z3lh bmdkdC1ydGd3Zy1kZXZpY2UtbW9kZWwtMDAgcHJvdmlkZSBhIGdvb2Qgc3RydWN0dXJlIGZvciB0 aGVzZSBPQU0gbW9kZWxzIG9yZ2FuaXphdGlvbiBidXQgbm90IGxpbWl0ZWQgdG8gcHJvdmlkZSBz dHJ1Y3R1cmUNCiBmb3IgT0FNIG1vZGVsIG9yZ2FuaXphdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDo1LjM1cHQ7bWFyZ2luLXJpZ2h0OjUuMzVwdDttYXJnaW4tYm90dG9tOjUuMzVwdDttYXJnaW4t bGVmdDoyNy4wcHQ7dGV4dC1pbmRlbnQ6MGNtO3BhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+DQo8 c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyBsb2dpY2FsLW5l dHdvcmstZWxlbWVudHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDo1LjM1cHQ7bWFyZ2luLXJpZ2h0OjUu MzVwdDttYXJnaW4tYm90dG9tOjUuMzVwdDttYXJnaW4tbGVmdDoyNy4wcHQ7dGV4dC1pbmRlbnQ6 MGNtO3BhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+DQo8c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZv bnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1y dyBuZXR3b3JraW5nLWluc3RhbmNlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjUuMzVwdDttYXJnaW4t cmlnaHQ6NS4zNXB0O21hcmdpbi1ib3R0b206NS4zNXB0O21hcmdpbi1sZWZ0OjI3LjBwdDt0ZXh0 LWluZGVudDowY207cGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj4NCjxzcGFuIGxhbmc9IkVOIiBz dHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IG5ldHdvcmtpbmctaW5zdGFuY2UqIFtuZXR3b3Jr aW5nLWluc3RhbmNlLW5hbWVdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xp c3RQYXJhZ3JhcGgiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6NS4zNXB0O21hcmdpbi1yaWdo dDo1LjM1cHQ7bWFyZ2luLWJvdHRvbTo1LjM1cHQ7bWFyZ2luLWxlZnQ6MjcuMHB0O3RleHQtaW5k ZW50OjBjbTtwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPg0KPHNwYW4gbGFuZz0iRU4iIHN0eWxl PSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgb2FtLXByb3RvY29sczxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OjUuMzVwdDttYXJnaW4tcmlnaHQ6NS4zNXB0O21hcmdpbi1ib3R0 b206NS4zNXB0O21hcmdpbi1sZWZ0OjI3LjBwdDt0ZXh0LWluZGVudDowY207cGFnZS1icmVhay1i ZWZvcmU6YWx3YXlzIj4NCjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgYmZkPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6NS4z NXB0O21hcmdpbi1yaWdodDo1LjM1cHQ7bWFyZ2luLWJvdHRvbTo1LjM1cHQ7bWFyZ2luLWxlZnQ6 MjcuMHB0O3RleHQtaW5kZW50OjBjbTtwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPg0KPHNwYW4g bGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7ICYj NDM7LS1ydyBjZm08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDo1LjM1cHQ7bWFyZ2luLXJpZ2h0OjUuMzVw dDttYXJnaW4tYm90dG9tOjUuMzVwdDttYXJnaW4tbGVmdDoyNy4wcHQ7dGV4dC1pbmRlbnQ6MGNt O3BhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+DQo8c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQt c2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IHR3YW1wPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6NS4zNXB0O21hcmdpbi1yaWdodDo1LjM1cHQ7bWFyZ2luLWJvdHRvbTo1LjM1 cHQ7bWFyZ2luLWxlZnQ6MjcuMHB0O3RleHQtaW5kZW50OjBjbTtwYWdlLWJyZWFrLWJlZm9yZTph bHdheXMiPg0KPHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2lu LWxlZnQ6MjcuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIi Pg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4yLjxz cGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtl bmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5kcmFmdC10aXNzYS1saW1lLXlhbmctb2FtLW1vZGVsIGFsc28gcHJvdmlkZSBhIGdvb2Qg Y29tbW9uIHN0cnVjdHVyZSBmb3IgT0FNIG1vZGVscyBvcmdhbml6YXRpb24uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5MSU1FIFdHIGlzIGNoYXJ0ZXJlZCB0byB3 b3JrIG9uIGdlbmVyaWMgWUFORyBtb2RlbCBmb3IgT0FNICh0aGUgcmVsZXZhbnQgZHJhZnQgaXMg ZHJhZnQtdGlzc2EtbGltZS15YW5nLW9hbS1tb2RlbClhbmQgcHJvdmlkZXMgYSBjb21tb24gc3Ry dWN0dXJlDQogZm9yIHZhcmlvdXMgT0FNIHRlY2hub2xvZ2llcywgdGVjaG5vbG9neSBzcGVjaWZp YyBPQU0gZGF0YSBtb2RlbHMgd2lsbCBiZSB3b3JrZWQgb24gcmVzcGVjdGl2ZSBwcm90b2NvbCBX R3MoZS5nLiwgQkZELCBNUExTKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJ0ZXh0LWluZGVudDoyMS4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlcmVmb3JlIGJhc2VkIG9uIExJTUUgY2hhcnRl ciAoPGEgaHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL3dnL2xpbWUvY2hhcnRlci8i Pmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy93Zy9saW1lL2NoYXJ0ZXIvPC9hPiksDQogdGhl IHJlbGF0aW9uIHdpdGggcHJvdG9jb2wgYmFzZWQgT0FNIG1vZGVscyBjYW4gYmUgZGVwaWN0ZWQs IGZvciBleGFtcGxlLCBhcyBmb2xsb3dzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgTElNRSBnZW58 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8T0FNIFlB TkcgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0Mzs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7fDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsm bmJzcDsmbmJzcDsgJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzsmbmJzcDsmbmJz cDsgJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzsmbmJzcDsmbmJzcDsgJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzsgJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0Mzs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgQ0ZNJm5ic3A7ICZu YnNwOyZuYnNwOyZuYnNwO3wmbmJzcDsmbmJzcDsgfCBNUExTLVRQIHwmbmJzcDsmbmJzcDsgfCBN UExTJm5ic3A7Jm5ic3A7Jm5ic3A7IHwgfCBJUCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB8IC4gLiAufCZuYnNwOyBmb28mbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJz cDsmbmJzcDsgfE9BTSBZQU5HIHwmbmJzcDsmbmJzcDsgfE9BTSBZQU5HIHwmbmJzcDsmbmJzcDsg fE9BTSBZQU5HIHwgfE9BTSBZQU5HIHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfE9B TSBZQU5HIHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7Jm5ic3A7Jm5ic3A7ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7Jm5ic3A7Jm5ic3A7ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7ICYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzsmbmJzcDsmbmJzcDsgJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8IE1QTFMtVFAgfCZuYnNwOyZuYnNwOyB8IE1QTFMmbmJzcDsmbmJzcDsmbmJzcDsgfCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IC4gLiAufCZuYnNwOyBmb28mbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJz cDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8c3ViIHRlY2ggfCZuYnNwOyZuYnNwOyB8c3ViIHRl Y2ggfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHxzdWIgdGVjaCB8PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_B8F9A780D330094D99AF023C5877DABA84814B47nkgeml501mbschi_-- From nobody Thu Aug 27 23:33:31 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74CEB1ACE7E for ; Thu, 27 Aug 2015 23:33: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 LCIUfjG-7i1K for ; Thu, 27 Aug 2015 23:33:27 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE721ACCDE for ; Thu, 27 Aug 2015 23:33:27 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 9A00D1AE0481; Fri, 28 Aug 2015 08:33:26 +0200 (CEST) Date: Fri, 28 Aug 2015 08:33:54 +0200 (CEST) Message-Id: <20150828.083354.1177215032438250041.mbj@tail-f.com> To: rjs@rob.sh From: Martin Bjorklund In-Reply-To: <55DF74FC.101@rob.sh> References: <20150827.214518.77501131721951504.mbj@tail-f.com> <55DF74FC.101@rob.sh> 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: netmod@ietf.org Subject: Re: [netmod] Motivations for Structuring Models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 06:33:29 -0000 Um9iIFNoYWtpciA8cmpzQHJvYi5zaD4gd3JvdGU6DQo+IA0KPiBNYXJ0aW4sDQo+IA0KPiBBcG9s b2dpZXMsIEkgc3dpdGNoZWQgdG8gYSBuZXcgY2xpZW50IGFuZCwgd293LCB5ZXMsIGl0J3Mgbm90 DQo+IHJlYWRhYmxlLiBJIHJlcG9ydGVkIGEgYnVnIGFuZCBzd2l0Y2hlZCBjbGllbnRzIGFnYWlu Li4uIEkgKmhvcGUqIHRoaXMNCj4gb25lIGlzIG1vcmUgcmVhZGFibGUgKGFuZCBpdCB3YXMgd2hl biBJIGNoZWNrZWQgbGFzdCkuDQoNClRoYW5rIHlvdSBSb2IhDQoNCj4gSSdsbCBwdXQgYXNpZGUg cXVlc3Rpb25zIG9mIHdoZXRoZXIgdGhlIHF1ZXN0aW9ucyBJJ20gYXNraW5nIGFyZQ0KPiBjb21w bGV0ZWx5IGZhaXIuIEFwb2xvZ2llcy4gVGhleSdyZSB3cml0dGVuIGZyb20gbXkgcGVyc3BlY3Rp dmUgb2YNCj4gcHJvYmxlbXMgSSdtIGFjdHVhbGx5IGV4cGVyaWVuY2luZy4NCj4gPiBNYXJ0aW4g QmpvcmtsdW5kIDxtYWlsdG86bWJqQHRhaWwtZi5jb20+DQo+ID4gQXVndXN0IDI3LCAyMDE1IGF0 IDE1OjQ1DQo+ID4gMSkgQXMgYSBjb25zdW1lciBvZiBZQU5HIG1vZGVscywgaG93IGRvIEkgaWRl bnRpZnkgdGhlIHNldCBvZiBtb2RlbHMNCj4gPiB0aGF0IHByb3ZpZGUgYSBzZXQgb2YgZnVuY3Rp b25hbGl0eT8NCj4gPg0KPiA+IEkgdGhpbmsgdGhhdCBuZWl0aGVyIHlvdXIgcHJvcG9zZWQgc29s dXRpb24gb3Igd2hhdCB3ZSBoYXZlIHRvZGF5ICg3DQo+ID4gcHVibGlzaGVkIG1vZHVsZXMpIHNv bHZlcyB0aGlzIHByb2JsZW0uDQo+IEkgcmVzcGVjdGZ1bGx5IGRpc2FncmVlLiBCeSBkZWZpbmlu ZyBzb21lIGZvcm0gb2Ygc3RydWN0dXJlIGZvciB0aGUNCj4gbW9kZWxzLCBJIGNhbiBoYXZlIGEg bG9naWNhbCBncm91cGluZyB0aGF0IGdpdmVzIG1lIHNvbWUgcG9pbnRlcnMgYXMNCj4gdG8gd2hl cmUgdG8gZmluZCB0aGUgcmlnaHQgdGhpbmdzIHRoYXQgSSBuZWVkLiBJIHdhbnQgdG8gY29uZmln dXJlDQo+IE9BTSwgZ3JlYXQsIGxldCdzIGdvIGxvb2sgYXQNCj4gL2RldmljZS9sb2dpY2FsLW5l dHdvcmstZWxlbWVudHMvbG9naWNhbC1uZXR3b3JrLWVsZW1lbnQvbmV0d29yay1pbnN0YW5jZXMv bmV0d29yay1pbnN0YW5jZS9vYW0tcHJvdG9jb2xzDQo+IC0gYmVjYXVzZSB0aGF0J3Mgd2hlcmUg YWxsIE9BTSBzdHVmZiBoYXBwZW5zIHRvIGxpdmUuDQoNClNvIHRoZSBpZGVhIGlzIHRoYXQgdGhp cyBzdHJ1Y3R1cmUgaXMgZGVmaW5lZCBpbiBvbmUgbW9kdWxlLA0KaWV0Zi1zb21ldGhpbmctc3Ry dWN0dXJlLCByaWdodD8NCg0KQW5kIHRoZW4gZGlmZmVyZW50IG9hbSBwcm90b2NvbCBtb2R1bGVz IGF1Z21lbnQgdGhpcyBzdHJ1Y3R1cmU/DQoNCkhvdyBkb2VzIHRoaXMgaGVscCB5b3UgZmluZCB0 aGUgbW9kdWxlcyB0aGF0IGF1Z21lbnQgdGhpcyBzdHJ1Y3R1cmU/DQoNCj4gSWYgSSBoYXZlIHRv DQo+IHJhdGhlciBsb29rIHRocm91Z2ggLyB0byBmaW5kIGEgc3Vic2V0IG9mIHNvbWUgcGluZyBm dW5jdGlvbmFsaXR5IGluDQo+IG9uZSBtb2R1bGUsIGFuZCBzb21lIGluIGFub3RoZXIsIGl0J3Mg bm90IGNsZWFyIHRvIG1lIGhvdyBJIGV2ZW4gc3RhcnQNCj4gdG8gZmluZCB0aGUgcmlnaHQgdGhp bmcgLSBiZWNhdXNlIGF0IHRoZSBtb21lbnQgb25lIHR5cGUgb2YgcGluZyBsaXZlcw0KPiBpbiBv bmUgbW9kdWxlLCBhbmQgYW5vdGhlciBpbiBhIGNvbXBsZXRlbHkgZGlmZmVyZW50IG9uZSwgZXZl biB0aG91Z2gNCj4gdGhleSdyZSBhbG1vc3QgaWRlbnRpY2FsIGluIHRlcm1zIG9mIG1hbmFnZW1l bnQgcGxhbmUgaW50ZXJmYWNlLg0KDQpJIGFncmVlIHRoaXMgc291bmRzIGxpa2UgYSBiYWQgZGVz aWduLiAgSSBhYnNvbHV0ZWx5IGFncmVlIHRoYXQgaXQgaXMNCm5lY2Vzc2FyeSB0byBsb29rIGF0 IGhvdyBhIGdlbmVyaWMgWCBpcyBoYW5kbGVkIGJlZm9yZSBkb2luZyBhIG1vZGVsDQpmb3IgYSBz cGVjaWZpYyBpbnN0YW5jZSBvZiBYLiAgRm9yIGV4YW1wbGUsIGl0IGlzIHByb2JhYmx5IHVzZWZ1 bCB0bw0KZGVmaW5lIGhvdyBpbnRlcmZhY2VzIGluIGdlbmVyYWwgYXJlIG1hbmFnZWQgYmVmb3Jl IGNyZWF0aW5nIGEgbW9kZWwNCmZvciBldGhlcm5ldCBpbnRlcmZhY2VzLiAgQW5kIG1heWJlIHVz ZWZ1bCB0byB0aGluayBhYm91dCBob3cgcm91dGluZw0KcHJvdG9jb2xzIGluIGdlbmVyYWwgYXJl IGhhbmRsZWQgYmVmb3JlIGRvaW5nIGEgbW9kZWwgZm9yIGJncC4NCg0KWy4uLl0NCg0KPiA+PiDi gJxKdXN0IHJlYWQgdGhyb3VnaCB0aGUgbW9kdWxlc+KAnSBpcyBub3QgYWNjZXB0YWJsZSBhbnN3 ZXIgd2hlbg0KPiA+PiBjb25zaWRlcmluZyBtYWtpbmcgdGhpbmdzIGVhc3kgdG8gdXNlIGZvciBZ QU5HIG1vZGVsIGNvbnN1bWVycy4NCj4gPg0KPiA+IEJ1dCBob3cgZG9lcyB0aGUgdG9wLWxldmVs IG5vZGUgL2RldmljZSAoc29ycnksIGJ1dCBJIHJlYWxseSBoYXZlIHRvDQo+ID4gYXNrIHRoaXMp IHNvbHZlIHRoaXMgcHJvYmxlbT8gIEkgKnJlYWxseSogZG8gbm90IHVuZGVyc3RhbmQgdGhpcy4N Cj4gPiBFdmVuIHdpdGggeW91ciBzb2x1dGlvbiB5b3UnZCBoYXZlIGEgc2V0IG9mIG1vZHVsZXMg dGhhdCBhdWdtZW50IHRoaXMNCj4gPiBzdHJ1Y3R1cmUsIHJpZ2h0PyAgSG93IGRvIEkga25vdyB3 aGF0IHRoZXNlIG90aGVyIG1vZHVsZXMgYXJlPw0KDQpZb3UgZGlkbid0IGFuc3dlciB0aGlzIHF1 ZXN0aW9uLiAgU28gSSByZXBlYXRlZCBpdCBhYm92ZSBhbmQgYmVsb3cgOykNCg0KPiA+DQo+ID4g Tm93LCBJIHNob3VsZCBhZGQgdGhhdCB0aGUgd2F5IEkgc2VlIHlvdXIgc29sdXRpb24gaXMgYSBZ QU5HIG1vZHVsZQ0KPiA+IHRoYXQgZGVmaW5lcyBhIHN0cnVjdHVyZSBvZiBOUC1jb250YWluZXJz LiAgWW91IChvciB3YXMgaXQgQW5lZXM/KQ0KPiA+IHRoZW4gbWVudGlvbmVkIHRoYXQgd2Ugc2hv dWxkbid0IGZvY3VzIHNvIG11Y2ggb24gdGhlICpZQU5HIG1vZHVsZSo7DQo+ID4gaXQgd2FzIHRo ZSBzdHJ1Y3R1cmUgdGhhdCB3YXMgaW1wb3J0YW50Lg0KPiA+DQo+IEZpcnN0IG9mZiwgd2UgZHJl dyBhIHBpY3R1cmUgWzBdIHRoYXQgc2hvd2VkIHRoZSBzZXQgb2YgbW9kdWxlcyB0aGF0DQo+IHdl IGZpZ3VyZWQgd2UgbWlnaHQgbmVlZC4gVGhlc2UgYnJlYWsgZG93biBpbnRvIHZhcmlvdXMgYml0 cyBvZiBkZXZpY2UNCj4gZnVuY3Rpb25hbGl0eS4gVG8gbWFrZSB0aGlzIG1vcmUgYWNjZXNzaWJs ZSBhcyBzb21ldGhpbmcgdGhhdCBjb3VsZCBiZQ0KPiBzaG93biBpbiBhIGRyYWZ0LCB3ZSBleHBy ZXNzZWQgaXQgaW4gWUFORyBhbmQgdXNlZCBweWFuZyB0byBkcmF3IG91dA0KPiB0aGUgdHJlZS4N Cg0KVGhhbmtzLCB0aGlzIGlzIHdoYXQgSSByZW1lbWJlciB5b3UgbWVudGlvbmVkIGluIERhbGxh cy4NCg0KQnV0IHdoYXQgZG9lcyB0aGlzIHJlYWxseSBtZWFuPyAgQXJlIHlvdSBwcm9wb3Npbmc6 DQoNCiAgMSkgIHRvIGRlZmluZSBvbmUgbW9kZWwgaWV0Zi1zb21ldGhpbmcgdGhhdCBjb250YWlu cyB0aGlzIHByb3Bvc2VkDQogICAgICBzdHJ1Y3R1cmUsIHdoaWNoIHRoZW4gb3RoZXIgbW9kdWxl cyBhdWdtZW50Pw0KDQogIDIpICB0byBkZWZpbmUgb25lIHNpbmdsZSBpZXRmIG1vZGVsLCBwZXJp b2QuICBubyBhdWdtZW50cyBieSB0aGUNCiAgICAgIGlldGYuDQoNCiAgMykgIHRvIGRlZmluZSB0 aGUgc3RydWN0dXJlIG1vcmUgbG9vc2VseSBpbiB0ZXh0LCBhbmQgdXNlIHRoaXMNCiAgICAgIHN0 cnVjdHVyZSB3aGVuIG5ldyBtb2RlbHMgYXJlIGRldmVsb3BlZD8NCg0KICA0KSAgc29tZXRoaW5n IGVsc2U/DQoNCj4gVGhlIGxheW91dCBvZiB0aGUgc2V0cyBvZiBmdW5jdGlvbnMgdGhhdCB3ZSBo YXZlLCBhbmQgaG93IHRoZXkgYXJlDQo+IGdyb3VwZWQsIGlzIHRoZSBpbXBvcnRhbnQgdGhpbmcu IFRoZSBmYWN0IHRoYXQgd2UgYXJlIGNvbmZpZ3VyaW5nIGENCj4gZGV2aWNlIG1ha2VzIC9kZXZp Y2UgYSBnb29kIHN0YXJ0aW5nIHBvaW50LiBJIHRoaW5rIHRoaXMgaXMgaG93IHlvdQ0KPiBpbXBs ZW1lbnRlZCBORURzIGluIE5DUyB0b28uLi4/DQoNCk5vLCBlYWNoIE5FRCAoZGV2aWNlKSBpcyBt b2RlbGxlZCBhY2NvcmRpbmcgdG8gaXRzIG5hdGl2ZSAibW9kZWwiLiAgU28NCmZvciBleGFtcGxl IHRoZSBJT1MgTkVEIGhhcyAvaW50ZXJmYWNlLCAvaXAsIC94Y29ubmVjdCwgZXRjLg0KDQpCdXQs IGFzIEkgaGF2ZSBzYWlkIGJlZm9yZSwgdGhlIGRldmljZSBhYnN0cmFjdGlvbiBpcyByZWFsbHkN CmltcG9ydGFudCAtIGluIHRoZSBOTVMvT1NTL2NvbnRyb2xsZXIvd2hhdGV2ZXIuICBUaGVyZSB3 ZSBoYXZlIGEgbGlzdA0Kb2YgZGV2aWNlcywgYW5kIGVhY2ggZGV2aWNlIGhhcyBhIG5hbWUgYW5k IG1ldGEtZGF0YSBhbmQgdGhlbiBpdHMgcmVhbA0KZGF0YSwgc28gZm9yIGV4YW1wbGUgd2UgY2Fu IGhhdmU6DQoNCiAgIC9kZXZpY2VzL2RldmljZVtuYW1lPSdydHI0J10vaXANCiAgIC9kZXZpY2Vz L2RldmljZVtuYW1lPSdydHI0J10vcG9ydA0KDQphbmQgdGhlbiB3ZSBwdXQgYWxsIGRhdGEgbW9k ZWxzIGZyb20gdGhlIGRldmljZSB1bmRlciBhIGNvbW1vbg0KY29udGFpbmVyICdkYXRhJzoNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAvZGV2aWNlcy9kZXZpY2VbbmFtZT0n cnRyNCddL2RhdGEvaW50ZXJmYWNlLw0KICAgL2RldmljZXMvZGV2aWNlW25hbWU9J3J0cjQnXS9k YXRhL3hjb25uZWN0Lw0KDQpJZiB0aGUgZGV2aWNlIGhhZCBhIHRvcC1sZXZlbCBjb250YWluZXIg ImRldmljZSIgdGhpcyB3b3VsZCBoYXZlIGJlZW46DQoNCiAgIC9kZXZpY2VzL2RldmljZVtuYW1l PSdydHI0J10vZGF0YS9kZXZpY2UvaW50ZXJmYWNlcw0KDQoNCi9tYXJ0aW4NCg== From nobody Thu Aug 27 23:41:02 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6DE1B316D for ; Thu, 27 Aug 2015 23:41:01 -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 8gjyX1D9kaqe for ; Thu, 27 Aug 2015 23:41:00 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D73BE1B3168 for ; Thu, 27 Aug 2015 23:40:59 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 1EB981AE0481; Fri, 28 Aug 2015 08:40:59 +0200 (CEST) Date: Fri, 28 Aug 2015 08:41:27 +0200 (CEST) Message-Id: <20150828.084127.247634384116908046.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: netmod@ietf.org Subject: Re: [netmod] logical systems model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 06:41:01 -0000 Andy Bierman wrote: > Hi, > > I started a new subject line because the way logical vs. physical systems > are managed is a separate issue from the others. > > +--rw device > +--rw logical-network-elements > +--rw logical-network-element* [network-element-id] > +--rw network-element-id uint8 > +--rw network-element-name? string > +--rw default-networking-instance-name? string > +--rw system-management > | +--rw device-view? boolean > | +--rw syslog > | +--rw dns > | +--rw ntp > | +--rw statistics-collection > | +--rw ssh > | +--rw tacacs > | +--rw snmp > | +--rw netconf > > > I do not know of any systems where the logical view > is managed with an array entry like in this proposal. > Usually the protocol (or CLI command) picks one logical context > and the PDU is for that one logical system. Each logical system > is self-contained so that the data models are written for > a single system. > > Putting the multiplexing in the data model > adds a lot of extra complexity and protocol overhead for > systems that do not have virtual servers. +1 I also believe that it is too limiting. Some systems might do it this way, but then there are others that have the concept of "virtual system" that works differently. For example, the virtual system might give you your very own sandbox not just for the data model but also for the underlying config data store. There are essentially separate instances of a NETCONF server running (or other protocol). > When it comes to converting this tree to CLI (since this > is a common practice) the "interfaces" command will become > "devices interfaces", "system" becomes "device system", etc. > I don't know of any CLIs that work this way. > > The "nacm enable false" command will become > > device logical-network-elements logical-network-element 1 \ > system-management netconf nacm enable false And this would be a weird place for NACM. Would there be another NACM for logical-network-element 2? They would share the same root, so are rules somehow merged? Ditto for the snmp container btw. /martin From nobody Fri Aug 28 00:54:06 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E316E1A6F15 for ; Fri, 28 Aug 2015 00:54: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 IOyR3uBQ4H9c for ; Fri, 28 Aug 2015 00:54: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 9BFC71ACE03 for ; Fri, 28 Aug 2015 00:54:03 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 071EF1AE0481; Fri, 28 Aug 2015 09:54:01 +0200 (CEST) Date: Fri, 28 Aug 2015 09:54:20 +0200 (CEST) Message-Id: <20150828.095420.255404541690458770.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: netmod@ietf.org Subject: Re: [netmod] Motivations for Structuring Models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 07:54:05 -0000 Andy Bierman wrote: > Just because some people don't agree that the existing modules should be > moved doesn't mean the NETMOD WG wants every module to create its > own top-level node. I agree, but I would go one step further and say that just b/c we don't think that /device is a good idea doesn't mean that the NETMOD WG wants every module to create its own top-level node. (The point being that I think /device is a bad idea even if we didn't have these 7 modules published) > Create some organization for the 194 new modules. > I completely agree with you that these modules should be written with > a coherent development plan in mind. +1 > Given that CLIs are being driven by YANG, I completely agree that > understanding of the command hierarchy is useful. I have no objections > to the creation of a hierarchy or "node placement plan" or whatever. > This is a non-issue. +1 (although I think it will be challenging... I wouldn't try to create one single node placement plan for *everything*; routers, app servers, set-top boxes, radio base stations, just to mention a few types of boxes that have YANG models today) /martin From nobody Fri Aug 28 04:19:55 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 518711B3360 for ; Fri, 28 Aug 2015 04:19:53 -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 uTA4Tft67cMG for ; Fri, 28 Aug 2015 04:19:51 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B51C1B335B for ; Fri, 28 Aug 2015 04:19:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4004; q=dns/txt; s=iport; t=1440760791; x=1441970391; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=F16xccS9TaRRohMckXIpXcOvpzoH0FtgeLh8UvSE1Yc=; b=EiFyvu1mL+dTLKPs15f8qD3esJNR2ghQFszqVnTRCVKLLUf6mDwpr9zZ mr2w5Q75hndlPynEEpLR+9PfDNyWJbav3oohLOu6QRCDcMZ1qm2vu+EjT V6VKs5uoRxKAqY0LQotY6wOh/WryBsYjGU5QNXovTjlunhyM4W1KLIy3l 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CXBQBHQuBV/4QNJK1egxtUaQaDHbxTCoUxSgIcgSQ8EAEBAQEBAQGBCoQkAQEEAQEBIBE6CxACAQgOCgICJgICAiULFRACBAENBYguDa1vlGMBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIEiikCEQEsHgmmBQwWMbIhRAYxygUqVLoNrJoN/cYFIgQUBAQE X-IronPort-AV: E=Sophos;i="5.17,424,1437436800"; d="scan'208";a="182867075" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-5.cisco.com with ESMTP; 28 Aug 2015 11:19:50 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t7SBJolD031800 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 28 Aug 2015 11:19:50 GMT Received: from xch-aln-007.cisco.com (173.36.7.17) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 28 Aug 2015 06:19:49 -0500 Received: from xhc-aln-x11.cisco.com (173.36.12.85) by xch-aln-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Fri, 28 Aug 2015 06:19:49 -0500 Received: from xmb-aln-x06.cisco.com ([169.254.1.223]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0248.002; Fri, 28 Aug 2015 06:19:49 -0500 From: "Acee Lindem (acee)" To: Martin Bjorklund , "andy@yumaworks.com" Thread-Topic: [netmod] logical systems model Thread-Index: AQHQ4RfyFdHvfriaRkS/b1nL9C1caJ4hSsKAgAAKvgA= Date: Fri, 28 Aug 2015 11:19:49 +0000 Message-ID: References: <20150828.084127.247634384116908046.mbj@tail-f.com> In-Reply-To: <20150828.084127.247634384116908046.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.37.102.29] Content-Type: text/plain; charset="utf-8" Content-ID: <4FD07A9F1CEAB6448949E96F6EFEBF5F@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] logical systems model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 11:19:53 -0000 TWFydGluLCBBbmR5LCANCg0KT24gOC8yOC8xNSwgMjo0MSBBTSwgIm5ldG1vZCBvbiBiZWhhbGYg b2YgTWFydGluIEJqb3JrbHVuZCINCjxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYg b2YgbWJqQHRhaWwtZi5jb20+IHdyb3RlOg0KDQo+QW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jr cy5jb20+IHdyb3RlOg0KPj4gSGksDQo+PiANCj4+IEkgc3RhcnRlZCBhIG5ldyBzdWJqZWN0IGxp bmUgYmVjYXVzZSB0aGUgd2F5IGxvZ2ljYWwgdnMuIHBoeXNpY2FsDQo+PnN5c3RlbXMNCj4+IGFy ZSBtYW5hZ2VkIGlzIGEgc2VwYXJhdGUgaXNzdWUgZnJvbSB0aGUgb3RoZXJzLg0KPj4gDQo+PiAg ICArLS1ydyBkZXZpY2UNCj4+ICAgICAgICstLXJ3IGxvZ2ljYWwtbmV0d29yay1lbGVtZW50cw0K Pj4gICAgICAgICAgKy0tcncgbG9naWNhbC1uZXR3b3JrLWVsZW1lbnQqIFtuZXR3b3JrLWVsZW1l bnQtaWRdDQo+PiAgICAgICAgICAgICArLS1ydyBuZXR3b3JrLWVsZW1lbnQtaWQgICAgICAgICAg ICAgICAgICB1aW50OA0KPj4gICAgICAgICAgICAgKy0tcncgbmV0d29yay1lbGVtZW50LW5hbWU/ ICAgICAgICAgICAgICAgc3RyaW5nDQo+PiAgICAgICAgICAgICArLS1ydyBkZWZhdWx0LW5ldHdv cmtpbmctaW5zdGFuY2UtbmFtZT8gICBzdHJpbmcNCj4+ICAgICAgICAgICAgICstLXJ3IHN5c3Rl bS1tYW5hZ2VtZW50DQo+PiAgICAgICAgICAgICB8ICArLS1ydyBkZXZpY2Utdmlldz8gICAgICAg ICAgICAgYm9vbGVhbg0KPj4gICAgICAgICAgICAgfCAgKy0tcncgc3lzbG9nDQo+PiAgICAgICAg ICAgICB8ICArLS1ydyBkbnMNCj4+ICAgICAgICAgICAgIHwgICstLXJ3IG50cA0KPj4gICAgICAg ICAgICAgfCAgKy0tcncgc3RhdGlzdGljcy1jb2xsZWN0aW9uDQo+PiAgICAgICAgICAgICB8ICAr LS1ydyBzc2gNCj4+ICAgICAgICAgICAgIHwgICstLXJ3IHRhY2Fjcw0KPj4gICAgICAgICAgICAg fCAgKy0tcncgc25tcA0KPj4gICAgICAgICAgICAgfCAgKy0tcncgbmV0Y29uZg0KPj4gDQo+PiAN Cj4+IEkgZG8gbm90IGtub3cgb2YgYW55IHN5c3RlbXMgd2hlcmUgdGhlIGxvZ2ljYWwgdmlldw0K Pj4gaXMgbWFuYWdlZCB3aXRoIGFuIGFycmF5IGVudHJ5IGxpa2UgaW4gdGhpcyBwcm9wb3NhbC4N Cj4+IFVzdWFsbHkgdGhlIHByb3RvY29sIChvciBDTEkgY29tbWFuZCkgcGlja3Mgb25lIGxvZ2lj YWwgY29udGV4dA0KPj4gYW5kIHRoZSBQRFUgaXMgZm9yIHRoYXQgb25lIGxvZ2ljYWwgc3lzdGVt LiAgRWFjaCBsb2dpY2FsIHN5c3RlbQ0KPj4gaXMgc2VsZi1jb250YWluZWQgc28gdGhhdCB0aGUg ZGF0YSBtb2RlbHMgYXJlIHdyaXR0ZW4gZm9yDQo+PiBhIHNpbmdsZSBzeXN0ZW0uDQo+PiANCj4+ IFB1dHRpbmcgdGhlIG11bHRpcGxleGluZyBpbiB0aGUgZGF0YSBtb2RlbA0KPj4gYWRkcyBhIGxv dCBvZiBleHRyYSBjb21wbGV4aXR5IGFuZCBwcm90b2NvbCBvdmVyaGVhZCBmb3INCj4+IHN5c3Rl bXMgdGhhdCBkbyBub3QgaGF2ZSB2aXJ0dWFsIHNlcnZlcnMuDQo+DQo+KzENCj4NCj5JIGFsc28g YmVsaWV2ZSB0aGF0IGl0IGlzIHRvbyBsaW1pdGluZy4gIFNvbWUgc3lzdGVtcyBtaWdodCBkbyBp dCB0aGlzDQo+d2F5LCBidXQgdGhlbiB0aGVyZSBhcmUgb3RoZXJzIHRoYXQgaGF2ZSB0aGUgY29u Y2VwdCBvZiAidmlydHVhbA0KPnN5c3RlbSIgdGhhdCB3b3JrcyBkaWZmZXJlbnRseS4gIEZvciBl eGFtcGxlLCB0aGUgdmlydHVhbCBzeXN0ZW0gbWlnaHQNCj5naXZlIHlvdSB5b3VyIHZlcnkgb3du IHNhbmRib3ggbm90IGp1c3QgZm9yIHRoZSBkYXRhIG1vZGVsIGJ1dCBhbHNvDQo+Zm9yIHRoZSB1 bmRlcmx5aW5nIGNvbmZpZyBkYXRhIHN0b3JlLiAgVGhlcmUgYXJlIGVzc2VudGlhbGx5IHNlcGFy YXRlDQo+aW5zdGFuY2VzIG9mIGEgTkVUQ09ORiBzZXJ2ZXIgcnVubmluZyAob3Igb3RoZXIgcHJv dG9jb2wpLg0KDQpXZWxsLCBJIGd1ZXNzIHlvdSBhcmUgcmVjb21tZW5kaW5nIGdvaW5nIGRvd24g dGhlIHNhbWUgcGF0aCBhcyBTTk1QIHdoZXJlDQplYWNoIHZlbmRvciBzdXBwb3J0ZWQgbXVsdGlw bGUgdmlydHVhbCByb3V0ZXJzIGFuZCBpbnN0YW5jZXMgZGlmZmVyZW50bHkuDQpJTU8sIHRoaXMg aXMgdW5kZXNpcmFibGUuDQoNCkFjZWUgDQoNCg0KDQo+DQo+DQo+PiBXaGVuIGl0IGNvbWVzIHRv IGNvbnZlcnRpbmcgdGhpcyB0cmVlIHRvIENMSSAoc2luY2UgdGhpcw0KPj4gaXMgYSBjb21tb24g cHJhY3RpY2UpIHRoZSAiaW50ZXJmYWNlcyIgY29tbWFuZCB3aWxsIGJlY29tZQ0KPj4gImRldmlj ZXMgaW50ZXJmYWNlcyIsICJzeXN0ZW0iIGJlY29tZXMgImRldmljZSBzeXN0ZW0iLCBldGMuDQo+ PiBJIGRvbid0IGtub3cgb2YgYW55IENMSXMgdGhhdCB3b3JrIHRoaXMgd2F5Lg0KPj4gDQo+PiBU aGUgIm5hY20gZW5hYmxlIGZhbHNlIiBjb21tYW5kIHdpbGwgYmVjb21lDQo+PiANCj4+IGRldmlj ZSBsb2dpY2FsLW5ldHdvcmstZWxlbWVudHMgbG9naWNhbC1uZXR3b3JrLWVsZW1lbnQgMSBcDQo+ PiBzeXN0ZW0tbWFuYWdlbWVudCBuZXRjb25mIG5hY20gZW5hYmxlIGZhbHNlDQo+DQo+QW5kIHRo aXMgd291bGQgYmUgYSB3ZWlyZCBwbGFjZSBmb3IgTkFDTS4gIFdvdWxkIHRoZXJlIGJlIGFub3Ro ZXIgTkFDTQ0KPmZvciBsb2dpY2FsLW5ldHdvcmstZWxlbWVudCAyPyAgVGhleSB3b3VsZCBzaGFy ZSB0aGUgc2FtZSByb290LCBzbyBhcmUNCj5ydWxlcyBzb21laG93IG1lcmdlZD8NCj4NCj5EaXR0 byBmb3IgdGhlIHNubXAgY29udGFpbmVyIGJ0dy4NCj4NCj4NCj4vbWFydGluDQo+DQo+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5uZXRtb2QgbWFpbGlu ZyBsaXN0DQo+bmV0bW9kQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9uZXRtb2QNCg0K From nobody Fri Aug 28 04:31:00 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B76561B2C4D for ; Fri, 28 Aug 2015 04:30: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 H0afKQiQFtPY for ; Fri, 28 Aug 2015 04:30:57 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 19A0D1B2C4B for ; Fri, 28 Aug 2015 04:30:57 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 8E4DF1CC0047; Fri, 28 Aug 2015 13:30:59 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund , andy@yumaworks.com In-Reply-To: <20150828.084127.247634384116908046.mbj@tail-f.com> References: <20150828.084127.247634384116908046.mbj@tail-f.com> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Fri, 28 Aug 2015 13:30:56 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] logical systems model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 11:30:59 -0000 Martin Bjorklund writes: > Andy Bierman wrote: >> Hi, >> >> I started a new subject line because the way logical vs. physical systems >> are managed is a separate issue from the others. >> >> +--rw device >> +--rw logical-network-elements >> +--rw logical-network-element* [network-element-id] >> +--rw network-element-id uint8 >> +--rw network-element-name? string >> +--rw default-networking-instance-name? string >> +--rw system-management >> | +--rw device-view? boolean >> | +--rw syslog >> | +--rw dns >> | +--rw ntp >> | +--rw statistics-collection >> | +--rw ssh >> | +--rw tacacs >> | +--rw snmp >> | +--rw netconf >> >> >> I do not know of any systems where the logical view >> is managed with an array entry like in this proposal. >> Usually the protocol (or CLI command) picks one logical context >> and the PDU is for that one logical system. Each logical system >> is self-contained so that the data models are written for >> a single system. >> >> Putting the multiplexing in the data model >> adds a lot of extra complexity and protocol overhead for >> systems that do not have virtual servers. > > +1 > > I also believe that it is too limiting. Some systems might do it this > way, but then there are others that have the concept of "virtual > system" that works differently. For example, the virtual system might > give you your very own sandbox not just for the data model but also > for the underlying config data store. There are essentially separate > instances of a NETCONF server running (or other protocol). Whilst most commercial systems might currently work this way, I can easily imagine use cases where a single agent manages multiple virtual devices. An example that comes to my mind is a network simulation using tools like mininet. In general, for light-weight virtualisation methods such as Linux containers, managing each virtual instance separately would mean a significant overhead. > > >> When it comes to converting this tree to CLI (since this >> is a common practice) the "interfaces" command will become >> "devices interfaces", "system" becomes "device system", etc. >> I don't know of any CLIs that work this way. >> >> The "nacm enable false" command will become >> >> device logical-network-elements logical-network-element 1 \ >> system-management netconf nacm enable false > > And this would be a weird place for NACM. Would there be another NACM > for logical-network-element 2? They would share the same root, so are > rules somehow merged? NACM, as well as all other modules we have, is based on the assumption of a single managed device. I think it is a typical trend that what once was a single instance becomes an array. If we did ietf-routing 20 years ago, there would probably be no routing-instance list. So I think it is a real problem that we can't migrate from a container to a list and reuse the container's data model. Groupings might help somewhat but they are still not fully reusable, if, for example, they contain absolute references. Lada > > Ditto for the snmp container btw. > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Aug 28 05:05:55 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A647A1A8825 for ; Fri, 28 Aug 2015 05:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.661 X-Spam-Level: X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CD-Ti7iID5hu for ; Fri, 28 Aug 2015 05:05:50 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E0971A8A5F for ; Fri, 28 Aug 2015 05:05:47 -0700 (PDT) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id B9849181770; Fri, 28 Aug 2015 14:05:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1440763545; bh=Y1VZ9s16DRs/0Q04R5j6bf9FKgqffnNokUMRspx7/pk=; h=From:Date:To; b=NQxigzoOd1NCC4nL2lvLRmwOOsmasFgMId5Hoo6D9xeKermBATAlsAiP//X8m0qJj xlrIT9NHP+alFGumUGgGel/LZLnkdAMlvvHwdoNFFbVCsdapPxJdF/S6jXpNspiE0G UD2zSdBu0oguKWCBBBejZkltMQldOAnLDdqSOpvc= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 28 Aug 2015 14:05:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8F9B5BA0-7A88-428A-9F04-6E36BE5EDB06@nic.cz> References: <8539636D-F2CC-49D5-A103-7A20AABB2843@nic.cz> To: Rob Shakir X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Motivations for Structuring Models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 12:05:53 -0000 > On 27 Aug 2015, at 19:49, Rob Shakir wrote: >=20 > Lada, >=20 >=20 >=20 > On August 27, 2015 at 12:54:39, Ladislav Lhotka (lhotka@nic.cz) wrote: >=20 >> We certainly need *some* structure, and since there was a requirement = to support multiple routing instances, a list of them seems natural.=20 > Great, we agree that we need some structure like we have for routing = elsewhere. >=20 > Can you point me towards any proposal other than = draft-openconfig-netmod-model-structure or = draft-rtgyangdt-rtgwg-device-model=E2=80=9300 for this structure? The current structure was pretty much a direct consequence of the = previous NETMOD charter: http://datatracker.ietf.org/doc/charter-ietf-netmod/06/ And as I said, we did consider having some universal top-level structure = but we rejected this idea, mainly because every other module would then = have to be an augment. >=20 > Already, implementors are having problems with this - because existing = modules that are pretty mature (ietf-bgp for example), need more = functionality than is in ietf-routing to make usable multi-VRF systems, = let alone multi-routing-instance. If there were some structure, we could = understand how these models need to be augmented to support the use = cases. I=E2=80=99ll come back to the case of how I configure something = that is a L2 virtual forwarding instance, that uses has a L3 IP = interface within it. ietf-routing is still open for any changes, but I think it has nothing = to do with the presence or absence of /device. >=20 > On the latter comments in your mail, I place little importance on = obsoleting existing RFCs, I care about: I would concur that the rules for updating published modules are too = strict for this stage, and that more flexibility is needed atleast until = the YANG landscape stabilises. >=20 > =E2=80=A2 Primarily: whether the existing models let me = configure things that I need to on my network (or form a suitable base = for doing so). > =E2=80=A2 Secondary: impact to existing implementations where = these models are actually usable to some external consumer. What I and others don=E2=80=99t understand is how the /device container = helps, or the current flat structure prevents, reaching these aims. Cheers, Lada > Kind regards, > r. >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Aug 28 05:32:42 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE661A88F4 for ; Fri, 28 Aug 2015 05:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8-foRIRRz5R for ; Fri, 28 Aug 2015 05:32:38 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFD221A875A for ; Fri, 28 Aug 2015 05:32:37 -0700 (PDT) Received: from [76.69.245.91] (helo=corretto.local) by cappuccino.rob.sh with esmtpa (Exim 4.80) (envelope-from ) id 1ZVIpQ-0002hZ-8j; Fri, 28 Aug 2015 13:32:20 +0100 Message-ID: <55E054DC.7050906@rob.sh> Date: Fri, 28 Aug 2015 08:32:28 -0400 From: Rob Shakir User-Agent: Postbox 4.0.3 (Macintosh/20150805) MIME-Version: 1.0 To: Martin Bjorklund References: <20150827.214518.77501131721951504.mbj@tail-f.com> <55DF74FC.101@rob.sh> <20150828.083354.1177215032438250041.mbj@tail-f.com> In-Reply-To: <20150828.083354.1177215032438250041.mbj@tail-f.com> Content-Type: multipart/alternative; boundary="------------040509030602020401040604" Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Motivations for Structuring Models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 12:32:41 -0000 This is a multi-part message in MIME format. --------------040509030602020401040604 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Martin, Thanks for the reply. > Martin Bjorklund > August 28, 2015 at 02:33 > So the idea is that this structure is defined in one module, > ietf-something-structure, right? > > And then different oam protocol modules augment this structure? > > How does this help you find the modules that augment this structure? Yes, this is the intention. By then generating the tree of the overall structure, then I can see what different containers are created there. It's not perfect (and hey, this suggestion is a *draft* for a reason - but yet again, there are not alternatives) - but the fact that the modules augment a common path adds some information that they are grouped to providing the same functionality, not disparate. ietf-routing does the same thing, it gives me the fact that at /routing/routing-instance/routing-protocols there are a bunch of control-plane protocols that are related to routing. >>>> “Just read through the modules” is not acceptable answer when >>>> considering making things easy to use for YANG model consumers. >>> But how does the top-level node /device (sorry, but I really have to >>> ask this) solve this problem? I *really* do not understand this. >>> Even with your solution you'd have a set of modules that augment this >>> structure, right? How do I know what these other modules are? > You didn't answer this question. So I repeated it above and below ;) Right. There was really a reason NOT to answer it. /device is irrelevant. It does not matter - it is simply how *this proposal* chooses to group things, based on the fact that we think that operators logically configure devices when dealing with these models. From your comments on NCS below, it seems to me that if we'd made this a list, then there'd be significantly less concern? I just can't understand why this is something to get hung up on. If /device isn't the right root, please show me what is - and WHY it's better. Structuring configuration and operational around some idea that all the configuration belongs to a physical device seems very, very logical to me. Further defining groups so that we have an understanding of how to build a coherent set of models for the functionalities required of that device seems a very clear next step after this. > Thanks, this is what I remember you mentioned in Dallas. > > But what does this really mean? Are you proposing: > > 1) to define one model ietf-something that contains this proposed > structure, which then other modules augment? > > 2) to define one single ietf model, period. no augments by the > ietf. > > 3) to define the structure more loosely in text, and use this > structure when new models are developed? > > 4) something else? As part of iterating on this idea, we are working to understand the practicalities of (1). This is exactly the approach that ietf-routing is taking for routing protocol modules. >> The layout of the sets of functions that we have, and how they are >> grouped, is the important thing. The fact that we are configuring a >> device makes /device a good starting point. I think this is how you >> implemented NEDs in NCS too...? > No, each NED (device) is modelled according to its native "model". So > for example the IOS NED has /interface, /ip, /xconnect, etc. > > But, as I have said before, the device abstraction is really > important - in the NMS/OSS/controller/whatever. There we have a list > of devices, and each device has a name and meta-data and then its real > data, so for example we can have: > > /devices/device[name='rtr4']/ip > /devices/device[name='rtr4']/port > > and then we put all data models from the device under a common > container 'data': > > /devices/device[name='rtr4']/data/interface/ > /devices/device[name='rtr4']/data/xconnect/ > > If the device had a top-level container "device" this would have been: > > /devices/device[name='rtr4']/data/device/interfaces This approach *DOES* logically structure configuration around the concept of a device. If we are really just debating whether /devices/device is a list or whether it's a container, I'm even more confused than I was before. Please see my earlier comment. Cheers, r. --------------040509030602020401040604 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Hi Martin,

Thanks for the reply.
August 28, 2015 at 02:33 
So the idea is that this structure is defined in one module,
ietf-something-structure, right?

And then different oam protocol modules augment this structure?

How does this help you find the modules that augment this structure?
Yes, this is the intention. By then generating the tree of the overall structure, then I can see what different containers are created there. It's not perfect (and hey, this suggestion is a *draft* for a reason - but yet again, there are not alternatives) - but the fact that the modules augment a common path adds some information that they are grouped to providing the same functionality, not disparate. ietf-routing does the same thing, it gives me the fact that at /routing/routing-instance/routing-protocols there are a bunch of control-plane protocols that are related to routing. 
“Just read through the modules” is not acceptable answer when
considering making things easy to use for YANG model consumers.

But how does the top-level node /device (sorry, but I really have to
ask this) solve this problem?  I *really* do not understand this.
Even with your solution you'd have a set of modules that augment this
structure, right?  How do I know what these other modules are?

You didn't answer this question.  So I repeated it above and below ;)
Right. There was really a reason NOT to answer it. /device is irrelevant. It does not matter - it is simply how *this proposal* chooses to group things, based on the fact that we think that operators logically configure devices when dealing with these models. From your comments on NCS below, it seems to me that if we'd made this a list, then there'd be significantly less concern? I just can't understand why this is something to get hung up on. If /device isn't the right root, please show me what is - and WHY it's better.

Structuring configuration and operational around some idea that all the configuration belongs to a physical device seems very, very logical to me. Further defining groups so that we have an understanding of how to build a coherent set of models for the functionalities required of that device seems a very clear next step after this.
Thanks, this is what I remember you mentioned in Dallas.

But what does this really mean?  Are you proposing:

  1)  to define one model ietf-something that contains this proposed
      structure, which then other modules augment?

  2)  to define one single ietf model, period.  no augments by the
      ietf.

  3)  to define the structure more loosely in text, and use this
      structure when new models are developed?

  4)  something else?
As part of iterating on this idea, we are working to understand the practicalities of (1). This is exactly the approach that ietf-routing is taking for routing protocol modules. 
The layout of the sets of functions that we have, and how they are
grouped, is the important thing. The fact that we are configuring a
device makes /device a good starting point. I think this is how you
implemented NEDs in NCS too...?

No, each NED (device) is modelled according to its native "model".  So
for example the IOS NED has /interface, /ip, /xconnect, etc.

But, as I have said before, the device abstraction is really
important - in the NMS/OSS/controller/whatever.  There we have a list
of devices, and each device has a name and meta-data and then its real
data, so for example we can have:

   /devices/device[name='rtr4']/ip
   /devices/device[name='rtr4']/port

and then we put all data models from the device under a common
container 'data':
                                
   /devices/device[name='rtr4']/data/interface/
   /devices/device[name='rtr4']/data/xconnect/

If the device had a top-level container "device" this would have been:

   /devices/device[name='rtr4']/data/device/interfaces
This approach *DOES* logically structure configuration around the concept of a device. If we are really just debating whether /devices/device is a list or whether it's a container, I'm even more confused than I was before. Please see my earlier comment.

Cheers,
r.
--------------040509030602020401040604-- From nobody Fri Aug 28 05:56:35 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDFB01ACD32 for ; Fri, 28 Aug 2015 05:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 aGg5_RV7IYF6 for ; Fri, 28 Aug 2015 05:56:32 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 476D71A8829 for ; Fri, 28 Aug 2015 05:55:27 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 4AACA1AE0481; Fri, 28 Aug 2015 14:55:25 +0200 (CEST) Date: Fri, 28 Aug 2015 14:55:46 +0200 (CEST) Message-Id: <20150828.145546.1509142825487206251.mbj@tail-f.com> To: rjs@rob.sh From: Martin Bjorklund In-Reply-To: <55E054DC.7050906@rob.sh> References: <55DF74FC.101@rob.sh> <20150828.083354.1177215032438250041.mbj@tail-f.com> <55E054DC.7050906@rob.sh> 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: netmod@ietf.org Subject: Re: [netmod] Motivations for Structuring Models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 12:56:33 -0000 Um9iIFNoYWtpciA8cmpzQHJvYi5zaD4gd3JvdGU6DQo+IA0KPiBIaSBNYXJ0aW4sDQo+IA0KPiBU aGFua3MgZm9yIHRoZSByZXBseS4NCj4gPiBNYXJ0aW4gQmpvcmtsdW5kIDxtYWlsdG86bWJqQHRh aWwtZi5jb20+DQo+ID4gQXVndXN0IDI4LCAyMDE1IGF0IDAyOjMzDQo+ID4gU28gdGhlIGlkZWEg aXMgdGhhdCB0aGlzIHN0cnVjdHVyZSBpcyBkZWZpbmVkIGluIG9uZSBtb2R1bGUsDQo+ID4gaWV0 Zi1zb21ldGhpbmctc3RydWN0dXJlLCByaWdodD8NCj4gPg0KPiA+IEFuZCB0aGVuIGRpZmZlcmVu dCBvYW0gcHJvdG9jb2wgbW9kdWxlcyBhdWdtZW50IHRoaXMgc3RydWN0dXJlPw0KPiA+DQo+ID4g SG93IGRvZXMgdGhpcyBoZWxwIHlvdSBmaW5kIHRoZSBtb2R1bGVzIHRoYXQgYXVnbWVudCB0aGlz IHN0cnVjdHVyZT8NCj4gWWVzLCB0aGlzIGlzIHRoZSBpbnRlbnRpb24uIEJ5IHRoZW4gZ2VuZXJh dGluZyB0aGUgdHJlZSBvZiB0aGUgb3ZlcmFsbA0KPiBzdHJ1Y3R1cmUsIHRoZW4gSSBjYW4gc2Vl IHdoYXQgZGlmZmVyZW50IGNvbnRhaW5lcnMgYXJlIGNyZWF0ZWQNCj4gdGhlcmUuIEl0J3Mgbm90 IHBlcmZlY3QgKGFuZCBoZXksIHRoaXMgc3VnZ2VzdGlvbiBpcyBhICpkcmFmdCogZm9yIGENCj4g cmVhc29uIC0gYnV0IHlldCBhZ2FpbiwgdGhlcmUgYXJlIG5vdCBhbHRlcm5hdGl2ZXMpIC0gYnV0 IHRoZSBmYWN0DQo+IHRoYXQgdGhlIG1vZHVsZXMgYXVnbWVudCBhIGNvbW1vbiBwYXRoIGFkZHMg c29tZSBpbmZvcm1hdGlvbiB0aGF0IHRoZXkNCj4gYXJlIGdyb3VwZWQgdG8gcHJvdmlkaW5nIHRo ZSBzYW1lIGZ1bmN0aW9uYWxpdHksIG5vdA0KPiBkaXNwYXJhdGUuIGlldGYtcm91dGluZyBkb2Vz IHRoZSBzYW1lIHRoaW5nLCBpdCBnaXZlcyBtZSB0aGUgZmFjdCB0aGF0DQo+IGF0IC9yb3V0aW5n L3JvdXRpbmctaW5zdGFuY2Uvcm91dGluZy1wcm90b2NvbHMgdGhlcmUgYXJlIGEgYnVuY2ggb2YN Cj4gY29udHJvbC1wbGFuZSBwcm90b2NvbHMgdGhhdCBhcmUgcmVsYXRlZCB0byByb3V0aW5nLg0K DQpPay4gIFNvIHlvdXIgcHJvcG9zYWwgZG9lc24ndCBoZWxwIHdpdGggdGhlIHByb2JsZW0gb2Yg bG9jYXRpbmcNCnJlbGV2YW50IFlBTkcgbW9kdWxlcywgYnV0IG9uY2UgdGhlaXIgbG9jYXRlZCwg aXQgaXMgZWFzaWVyIHRvIGZpbmQNCnRoZSBvbmVzIHJlbGF0ZWQgdG8gYSBzcGVjaWZpYyBmdW5j dGlvbiwgYi9jIHRoZXkgd291bGQgYXVnbWVudCBhDQpjb21tb24gcGF0aC4gIElzIHRoaXMgd2hh dCB5b3UgbWVhbj8NCg0KDQo+ID4+Pj4g4oCcSnVzdCByZWFkIHRocm91Z2ggdGhlIG1vZHVsZXPi gJ0gaXMgbm90IGFjY2VwdGFibGUgYW5zd2VyIHdoZW4NCj4gPj4+PiBjb25zaWRlcmluZyBtYWtp bmcgdGhpbmdzIGVhc3kgdG8gdXNlIGZvciBZQU5HIG1vZGVsIGNvbnN1bWVycy4NCj4gPj4+IEJ1 dCBob3cgZG9lcyB0aGUgdG9wLWxldmVsIG5vZGUgL2RldmljZSAoc29ycnksIGJ1dCBJIHJlYWxs eSBoYXZlIHRvDQo+ID4+PiBhc2sgdGhpcykgc29sdmUgdGhpcyBwcm9ibGVtPyAgSSAqcmVhbGx5 KiBkbyBub3QgdW5kZXJzdGFuZCB0aGlzLg0KPiA+Pj4gRXZlbiB3aXRoIHlvdXIgc29sdXRpb24g eW91J2QgaGF2ZSBhIHNldCBvZiBtb2R1bGVzIHRoYXQgYXVnbWVudCB0aGlzDQo+ID4+PiBzdHJ1 Y3R1cmUsIHJpZ2h0PyAgSG93IGRvIEkga25vdyB3aGF0IHRoZXNlIG90aGVyIG1vZHVsZXMgYXJl Pw0KPiA+IFlvdSBkaWRuJ3QgYW5zd2VyIHRoaXMgcXVlc3Rpb24uICBTbyBJIHJlcGVhdGVkIGl0 IGFib3ZlIGFuZCBiZWxvdyA7KQ0KPiBSaWdodC4gVGhlcmUgd2FzIHJlYWxseSBhIHJlYXNvbiBO T1QgdG8gYW5zd2VyIGl0LiAvZGV2aWNlIGlzDQo+IGlycmVsZXZhbnQuIEl0IGRvZXMgbm90IG1h dHRlcg0KDQpCdXQgdGhpcyBpcyB0aGUgd2hhdCB3ZSBoYXZlIGJlZW4gYXJndWluZyBhYm91dCEg IFJlbW92ZSAvZGV2aWNlIGFuZA0Kd2UgY2FuIHB1dCB0aGlzIGJlaGluZCB1cyBhbmQgbW92ZSBm b3J3YXJkLg0KDQo+IC0gaXQgaXMgc2ltcGx5IGhvdyAqdGhpcyBwcm9wb3NhbCoNCj4gY2hvb3Nl cyB0byBncm91cCB0aGluZ3MsIGJhc2VkIG9uIHRoZSBmYWN0IHRoYXQgd2UgdGhpbmsgdGhhdA0K PiBvcGVyYXRvcnMgbG9naWNhbGx5IGNvbmZpZ3VyZSBkZXZpY2VzIHdoZW4gZGVhbGluZyB3aXRo IHRoZXNlDQo+IG1vZGVscy4NCg0KU3VyZSwgYW4gb3BlcmF0b3IgY29uZmlndXJlIGRldmljZXMu DQoNCj4gRnJvbSB5b3VyIGNvbW1lbnRzIG9uIE5DUyBiZWxvdywgaXQgc2VlbXMgdG8gbWUgdGhh dCBpZiB3ZSdkDQo+IG1hZGUgdGhpcyBhIGxpc3QsIHRoZW4gdGhlcmUnZCBiZSBzaWduaWZpY2Fu dGx5IGxlc3MgY29uY2Vybj8NCg0KTm8gdGhhdCB3b3VsZCBiZSBldmVuIHdvcnNlISAgSWYgZXZl cnkgZGV2aWNlIGhhZCBhIGxpc3Qgb2YgZXhhY3RseQ0Kb25lIGRldmljZSAoaXRzZWxmKSwgdGhl IG9wZXJhdG9yIHdvdWxkIGhhdmUgdG8gZG8gdGhlIGVxdWl2YWxlbnQgb2Y6DQoNCiAgJCBzc2gg cnRyMg0KICAuLi4NCiAgPiBjb25maWcNCiAgIyBkZXZpY2UgZGV2aWNlIHJ0cjIgaW50ZXJmYWNl IGV0aDANCg0KT24gbW9zdCByb3V0ZXJzIHlvdSBkb24ndCBkbyB0aGlzLiBZb3UganVzdCBkbzoN Cg0KICA+IGNvbmZpZw0KICAjIGludGVyZmFjZSBldGgwDQoNCg0KT3IgaW4gYW4gb3JjaGVzdHJh dG9yIGxpa2UgTkNTIHlvdSdkIGhhdmUgdG8gZG8gdGhlIGVxdWl2YWxlbnQgb2Y6DQoNCiAgJCBz c2ggb3JjaGVzdHJhdG9yDQogIC4uLg0KICA+IGNvbmZpZw0KICAjIGRldmljZXMgZGV2aWNlIHJ0 cjIgZGF0YSBkZXZpY2VzIGRldmljZSBydHIyIGludGVyZmFjZSBldGgwDQoNClRoaXMganVzdCBk b2Vzbid0IG1ha2UgYW55IHNlbnNlLg0KDQoNCj4gSSBqdXN0DQo+IGNhbid0IHVuZGVyc3RhbmQg d2h5IHRoaXMgaXMgc29tZXRoaW5nIHRvIGdldCBodW5nIHVwIG9uLiBJZiAvZGV2aWNlDQo+IGlz bid0IHRoZSByaWdodCByb290LCBwbGVhc2Ugc2hvdyBtZSB3aGF0IGlzIC0gYW5kIFdIWSBpdCdz IGJldHRlci4NCg0KSnVzdCB1c2UgJy8nLiAgVGhlIHBvaW50IGlzIHRoYXQgKm9uIHRoZSBkZXZp Y2UqIGEgcm9vdCBvZiAvZGV2aWNlDQpkb2Vzbid0IG1ha2UgYW55IHNlbnNlLg0KDQpJIGFtIGFs bCBmb3IgYSBjb21tb24gbW9kZWwgb2YgYSBkZXZpY2UgbGlzdCB0byBiZSB1c2VkIGluIHRoZQ0K TlNNL09TUy8uLi4sIGJ1dCB0aGF0IGlzIGEgc2VwYXJhdGUgaXNzdWUuDQoNCj4gU3RydWN0dXJp bmcgY29uZmlndXJhdGlvbiBhbmQgb3BlcmF0aW9uYWwgYXJvdW5kIHNvbWUgaWRlYSB0aGF0IGFs bA0KPiB0aGUgY29uZmlndXJhdGlvbiBiZWxvbmdzIHRvIGEgcGh5c2ljYWwgZGV2aWNlIHNlZW1z IHZlcnksIHZlcnkNCj4gbG9naWNhbCB0byBtZS4gRnVydGhlciBkZWZpbmluZyBncm91cHMgc28g dGhhdCB3ZSBoYXZlIGFuDQo+IHVuZGVyc3RhbmRpbmcgb2YgaG93IHRvIGJ1aWxkIGEgY29oZXJl bnQgc2V0IG9mIG1vZGVscyBmb3IgdGhlDQo+IGZ1bmN0aW9uYWxpdGllcyByZXF1aXJlZCBvZiB0 aGF0IGRldmljZSBzZWVtcyBhIHZlcnkgY2xlYXIgbmV4dCBzdGVwDQo+IGFmdGVyIHRoaXMuDQo+ ID4gVGhhbmtzLCB0aGlzIGlzIHdoYXQgSSByZW1lbWJlciB5b3UgbWVudGlvbmVkIGluIERhbGxh cy4NCj4gPg0KPiA+IEJ1dCB3aGF0IGRvZXMgdGhpcyByZWFsbHkgbWVhbj8gIEFyZSB5b3UgcHJv cG9zaW5nOg0KPiA+DQo+ID4gICAgMSkgIHRvIGRlZmluZSBvbmUgbW9kZWwgaWV0Zi1zb21ldGhp bmcgdGhhdCBjb250YWlucyB0aGlzIHByb3Bvc2VkDQo+ID4gICAgICAgIHN0cnVjdHVyZSwgd2hp Y2ggdGhlbiBvdGhlciBtb2R1bGVzIGF1Z21lbnQ/DQo+ID4NCj4gPiAgICAyKSAgdG8gZGVmaW5l IG9uZSBzaW5nbGUgaWV0ZiBtb2RlbCwgcGVyaW9kLiAgbm8gYXVnbWVudHMgYnkgdGhlDQo+ID4g ICAgICAgIGlldGYuDQo+ID4NCj4gPiAgICAzKSAgdG8gZGVmaW5lIHRoZSBzdHJ1Y3R1cmUgbW9y ZSBsb29zZWx5IGluIHRleHQsIGFuZCB1c2UgdGhpcw0KPiA+ICAgICAgICBzdHJ1Y3R1cmUgd2hl biBuZXcgbW9kZWxzIGFyZSBkZXZlbG9wZWQ/DQo+ID4NCj4gPiAgICA0KSAgc29tZXRoaW5nIGVs c2U/DQo+IEFzIHBhcnQgb2YgaXRlcmF0aW5nIG9uIHRoaXMgaWRlYSwgd2UgYXJlIHdvcmtpbmcg dG8gdW5kZXJzdGFuZCB0aGUNCj4gcHJhY3RpY2FsaXRpZXMgb2YgKDEpLiBUaGlzIGlzIGV4YWN0 bHkgdGhlIGFwcHJvYWNoIHRoYXQgaWV0Zi1yb3V0aW5nDQo+IGlzIHRha2luZyBmb3Igcm91dGlu ZyBwcm90b2NvbCBtb2R1bGVzLg0KDQpUaGFua3MgZm9yIHRoZSBjbGFyaWZpY2F0aW9uLg0KDQo+ ID4+IFRoZSBsYXlvdXQgb2YgdGhlIHNldHMgb2YgZnVuY3Rpb25zIHRoYXQgd2UgaGF2ZSwgYW5k IGhvdyB0aGV5IGFyZQ0KPiA+PiBncm91cGVkLCBpcyB0aGUgaW1wb3J0YW50IHRoaW5nLiBUaGUg ZmFjdCB0aGF0IHdlIGFyZSBjb25maWd1cmluZyBhDQo+ID4+IGRldmljZSBtYWtlcyAvZGV2aWNl IGEgZ29vZCBzdGFydGluZyBwb2ludC4gSSB0aGluayB0aGlzIGlzIGhvdyB5b3UNCj4gPj4gaW1w bGVtZW50ZWQgTkVEcyBpbiBOQ1MgdG9vLi4uPw0KPiA+IE5vLCBlYWNoIE5FRCAoZGV2aWNlKSBp cyBtb2RlbGxlZCBhY2NvcmRpbmcgdG8gaXRzIG5hdGl2ZSAibW9kZWwiLiAgU28NCj4gPiBmb3Ig ZXhhbXBsZSB0aGUgSU9TIE5FRCBoYXMgL2ludGVyZmFjZSwgL2lwLCAveGNvbm5lY3QsIGV0Yy4N Cj4gPg0KPiA+IEJ1dCwgYXMgSSBoYXZlIHNhaWQgYmVmb3JlLCB0aGUgZGV2aWNlIGFic3RyYWN0 aW9uIGlzIHJlYWxseQ0KPiA+IGltcG9ydGFudCAtIGluIHRoZSBOTVMvT1NTL2NvbnRyb2xsZXIv d2hhdGV2ZXIuICBUaGVyZSB3ZSBoYXZlIGEgbGlzdA0KPiA+IG9mIGRldmljZXMsIGFuZCBlYWNo IGRldmljZSBoYXMgYSBuYW1lIGFuZCBtZXRhLWRhdGEgYW5kIHRoZW4gaXRzIHJlYWwNCj4gPiBk YXRhLCBzbyBmb3IgZXhhbXBsZSB3ZSBjYW4gaGF2ZToNCj4gPg0KPiA+ICAgICAvZGV2aWNlcy9k ZXZpY2VbbmFtZT0ncnRyNCddL2lwDQo+ID4gICAgIC9kZXZpY2VzL2RldmljZVtuYW1lPSdydHI0 J10vcG9ydA0KPiA+DQo+ID4gYW5kIHRoZW4gd2UgcHV0IGFsbCBkYXRhIG1vZGVscyBmcm9tIHRo ZSBkZXZpY2UgdW5kZXIgYSBjb21tb24NCj4gPiBjb250YWluZXIgJ2RhdGEnOg0KPiA+DQo+ID4g ICAgIC9kZXZpY2VzL2RldmljZVtuYW1lPSdydHI0J10vZGF0YS9pbnRlcmZhY2UvDQo+ID4gICAg IC9kZXZpY2VzL2RldmljZVtuYW1lPSdydHI0J10vZGF0YS94Y29ubmVjdC8NCj4gPg0KPiA+IElm IHRoZSBkZXZpY2UgaGFkIGEgdG9wLWxldmVsIGNvbnRhaW5lciAiZGV2aWNlIiB0aGlzIHdvdWxk IGhhdmUgYmVlbjoNCj4gPg0KPiA+ICAgICAvZGV2aWNlcy9kZXZpY2VbbmFtZT0ncnRyNCddL2Rh dGEvZGV2aWNlL2ludGVyZmFjZXMNCj4gVGhpcyBhcHByb2FjaCAqRE9FUyogbG9naWNhbGx5IHN0 cnVjdHVyZSBjb25maWd1cmF0aW9uIGFyb3VuZCB0aGUNCj4gY29uY2VwdCBvZiBhIGRldmljZS4N Cg0KWWVzIC0gaW4gdGhlIE5NUy9PU1MvY29udHJvbGxlciAtICpub3QqIG9uIHRoZSBkZXZpY2Uh DQoNCg0KDQoNCj4gSWYgd2UgYXJlIHJlYWxseSBqdXN0IGRlYmF0aW5nIHdoZXRoZXINCj4gL2Rl dmljZXMvZGV2aWNlIGlzIGEgbGlzdCBvciB3aGV0aGVyIGl0J3MgYSBjb250YWluZXIsIEknbSBl dmVuIG1vcmUNCj4gY29uZnVzZWQgdGhhbiBJIHdhcyBiZWZvcmUuIFBsZWFzZSBzZWUgbXkgZWFy bGllciBjb21tZW50Lg0KDQoNCi9tYXJ0aW4NCg0K From nobody Fri Aug 28 06:12:08 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE041B2A66 for ; Fri, 28 Aug 2015 06:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrKRYrji6uw7 for ; Fri, 28 Aug 2015 06:12:05 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 696821B33F0 for ; Fri, 28 Aug 2015 06:12:01 -0700 (PDT) Received: from [76.69.245.91] (helo=corretto.local) by cappuccino.rob.sh with esmtpa (Exim 4.80) (envelope-from ) id 1ZVJRY-0002qV-ER; Fri, 28 Aug 2015 14:11:44 +0100 Message-ID: <55E05E1B.2090407@rob.sh> Date: Fri, 28 Aug 2015 09:11:55 -0400 From: Rob Shakir User-Agent: Postbox 4.0.4 (Macintosh/20150825) MIME-Version: 1.0 To: Martin Bjorklund References: <55DF74FC.101@rob.sh> <20150828.083354.1177215032438250041.mbj@tail-f.com> <55E054DC.7050906@rob.sh> <20150828.145546.1509142825487206251.mbj@tail-f.com> In-Reply-To: <20150828.145546.1509142825487206251.mbj@tail-f.com> Content-Type: multipart/alternative; boundary="------------010003060202090700050800" Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Motivations for Structuring Models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 13:12:07 -0000 This is a multi-part message in MIME format. --------------010003060202090700050800 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Martin, We are almost certainly not on the same page as to what we're debating. > Martin Bjorklund > August 28, 2015 at 08:55 > > > Ok. So your proposal doesn't help with the problem of locating > relevant YANG modules, but once their located, it is easier to find > the ones related to a specific function, b/c they would augment a > common path. Is this what you mean? Having a structure to the way that the tree is defined helps a developer trying to consume functions find the relevant functionality. The model-writer needs to be aware of this structure. I think there is an important difference between model writer (not very many of these), and model consumer (lots of these). > > But this is the what we have been arguing about! Remove /device and > we can put this behind us and move forward. > So, if I take openconfig-model-structure and make it look like: module: model-structure [NB: trimmed for legibility.] +--rw info +--rw hardware +--rw system +--rw interfaces +--rw acl +--rw qos +--rw logical-routers +--rw logical-router* [router-id] +--rw router-id uint8 +--rw router-name? string +--rw layer-2-protocols +--rw layer-3-protocols +--rw vrf* [vrf-name] +--rw routing-policy Then you have no objection to this approach? Even though it will *still* very likely obsolete RFC'd models, which don't fit into the structure. I certainly do not have the impression that this is a common position from the other replies. I reviewed this thread, and I'm just not sure that any of my responses say that the very top-level container is the most important thing. I even said this in the original post: "When I originally drew the tree that was iterated on to form openconfig-model-structure, the reason to draw it was not to create some ‘/device’ node. It was to answer the two questions above." Rgds, r. --------------010003060202090700050800 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Martin,

We are almost certainly not on the same page as to what we're debating.
August 28, 2015 at 08:55

Ok.  So your proposal doesn't help with the problem of locating
relevant YANG modules, but once their located, it is easier to find
the ones related to a specific function, b/c they would augment a
common path.  Is this what you mean?
Having a structure to the way that the tree is defined helps a developer trying to consume functions find the relevant functionality. The model-writer needs to be aware of this structure. I think there is an important difference between model writer (not very many of these), and model consumer (lots of these). 

But this is the what we have been arguing about!  Remove /device and
we can put this behind us and move forward.
So, if I take openconfig-model-structure and make it look like:

module: model-structure [NB: trimmed for legibility.]
      +--rw info
      +--rw hardware
      +--rw system
      +--rw interfaces
      +--rw acl
      +--rw qos
      +--rw logical-routers
         +--rw logical-router* [router-id]
            +--rw router-id            uint8
            +--rw router-name?         string
            +--rw layer-2-protocols
            +--rw layer-3-protocols
               +--rw vrf* [vrf-name]
               +--rw routing-policy

Then you have no objection to this approach? Even though it will *still* very likely obsolete RFC'd models, which don't fit into the structure.

I certainly do not have the impression that this is a common position from the other replies.

I reviewed this thread, and I'm just not sure that any of my responses say that the very top-level container is the most important thing. I even said this in the original post:

"When I originally drew the tree that was iterated on to form openconfig-model-structure, the reason to draw it was not to create some ‘/device’ node. It was to answer the two questions above."

Rgds,
r.


--------------010003060202090700050800-- From nobody Fri Aug 28 06:13:45 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EEBC1A7000 for ; Fri, 28 Aug 2015 06:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.138 X-Spam-Level: ** X-Spam-Status: No, score=2.138 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DATE_IN_PAST_06_12=1.543, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, RCVD_IN_DNSWL_LOW=-0.7, 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 NYNXzJ_h2PGX for ; Fri, 28 Aug 2015 06:13:42 -0700 (PDT) Received: from mail.hq.sk (hq.sk [81.89.59.181]) by ietfa.amsl.com (Postfix) with ESMTP id CB9A81A702E for ; Fri, 28 Aug 2015 06:13:41 -0700 (PDT) Received: from [10.0.2.15] (188-167-5-4.dynamic.chello.sk [188.167.5.4]) by mail.hq.sk (Postfix) with ESMTPSA id 2D6FB2438EE; Fri, 28 Aug 2015 15:13:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1440767620; bh=BzJAEdTuKQV+AcCbB2PbRG8x0ZMUr01aCW/Ktxbi0vo=; h=Subject:To:References:From:Date:In-Reply-To; b=ixlL++O70AOc3Sxehj9D5ScCNecR1lKU7mAEuA0VqyTPFCnvDnzNDdVK3TpwP/n7E UYNvA7cQUTPoRa4CvZzWDhGH4vlLegeLjzK9fU7C2jvzWaFEUGr37Mp6tj5zuSFk7c q70kakRprZ6IH5hNUxvTyki2rvssApqcAPrWgeu8= To: Ladislav Lhotka , Andy Bierman , NETMOD Working Group References: <5497CE3E-19A7-4AAC-AE32-AFC9BC2451F1@nic.cz> <06C8EE42-B70D-40A7-8B16-053D37378043@nic.cz> <20150720210041.GA17614@elstar.local> <4D704311-D5B7-43F3-BD23-C13D5289CF46@nic.cz> <20150721074428.GC18607@elstar.local> From: Robert Varga Message-ID: <55DFC6CF.7060105@hq.sk> Date: Fri, 28 Aug 2015 04:26:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150721074428.GC18607@elstar.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Y34 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 13:13:44 -0000 On 07/21/2015 09:44 AM, Juergen Schoenwaelder wrote: > Lada, you can't simply 'mount' a data model into a different place. > Think about paths in must or when expressions, or think about paths > contraints in leafrefs etc In ODL we already have a language extension which does this. Semantically it embeds the conceptual 'root' node into container/list item. That item becomes the logical root against which all expressions in the embedded models are evaluated against, e.g. it is its own little world, no constraints coming in or out of it. While incoming references could be done (by just crossing the embedding item), we have not found a use case for it yet. This works rather well for providing a 'pass-through' function through a network controller down to individual devices: the devices themselves are represented as nodes in the topology model (exposed on the northbound) and a container holding the 'mount-point'. All operations in the mount-point space are mapped to NETCONF operations on the device (and hence it is the device itself who enforces constraints and referential integrity). Bye, Robert From nobody Fri Aug 28 06:20:55 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E752B1B3452 for ; Fri, 28 Aug 2015 06:20:53 -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 OAF0DQInWBy2 for ; Fri, 28 Aug 2015 06:20:49 -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 719871B3461 for ; Fri, 28 Aug 2015 06:20:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10540; q=dns/txt; s=iport; t=1440768049; x=1441977649; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=sLmso0sa/w4ARczAVyulgMkpGx0yRsA6LvR0mak7vJY=; b=bWypimz4E6kRlMTRpPOkYR3qOjjvUxctdarFxcueG0IT5CUwlQ7n41mt DFN/CWaBRthw6305UTK5/39MFOq2vLpbcvzgGURAmMaS13Mu6A6v1bcM2 TynETbEt+aDt2/AqQgoyVX+Y1+5DYHLa64Ctfe1438bHZhLcF/TjUEsOO g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CUBQCbX+BV/4kNJK1egxtUaQaDHbpmgW4KhTFKAhyBHjkTAQEBAQEBAYEKhCQBAQQBAQEgEToLEAIBCA4KAgIjAwICAiULFAEQAgQBDQUbiBMNr1aUYgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgSKJPYEDhFgzB4JpgUMFjGyIUQGMcoFKhDKDH41dg2smgg8cgVRxgUiBBQEBAQ X-IronPort-AV: E=Sophos;i="5.17,424,1437436800"; d="scan'208";a="183058650" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Aug 2015 13:20:48 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t7SDKm6e023714 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 28 Aug 2015 13:20:48 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 28 Aug 2015 08:20:47 -0500 Received: from xhc-rcd-x02.cisco.com (173.37.183.76) by xch-aln-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Fri, 28 Aug 2015 08:20:47 -0500 Received: from xmb-aln-x06.cisco.com ([169.254.1.223]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0248.002; Fri, 28 Aug 2015 08:20:47 -0500 From: "Acee Lindem (acee)" To: Martin Bjorklund , "rjs@rob.sh" Thread-Topic: [netmod] Motivations for Structuring Models Thread-Index: AQHQ4NBLQlr4e3n2uUqD0R28uxSQo54gW/iAgAAU4ACAACMmAIAADoUAgACmsgCAAGQvAIAABoMA///D9QA= Date: Fri, 28 Aug 2015 13:20:47 +0000 Message-ID: References: <55DF74FC.101@rob.sh> <20150828.083354.1177215032438250041.mbj@tail-f.com> <55E054DC.7050906@rob.sh> <20150828.145546.1509142825487206251.mbj@tail-f.com> In-Reply-To: <20150828.145546.1509142825487206251.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.36.7.18] Content-Type: text/plain; charset="utf-8" Content-ID: <8DC756D169AB4D46867B7DF813D307A6@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Motivations for Structuring Models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 13:20:54 -0000 DQoNCk9uIDgvMjgvMTUsIDg6NTUgQU0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIE1hcnRpbiBCam9y a2x1bmQiDQo8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIG1iakB0YWlsLWYu Y29tPiB3cm90ZToNCg0KPlJvYiBTaGFraXIgPHJqc0Byb2Iuc2g+IHdyb3RlOg0KPj4gDQo+PiBI aSBNYXJ0aW4sDQo+PiANCj4+IFRoYW5rcyBmb3IgdGhlIHJlcGx5Lg0KPj4gPiBNYXJ0aW4gQmpv cmtsdW5kIDxtYWlsdG86bWJqQHRhaWwtZi5jb20+DQo+PiA+IEF1Z3VzdCAyOCwgMjAxNSBhdCAw MjozMw0KPj4gPiBTbyB0aGUgaWRlYSBpcyB0aGF0IHRoaXMgc3RydWN0dXJlIGlzIGRlZmluZWQg aW4gb25lIG1vZHVsZSwNCj4+ID4gaWV0Zi1zb21ldGhpbmctc3RydWN0dXJlLCByaWdodD8NCj4+ ID4NCj4+ID4gQW5kIHRoZW4gZGlmZmVyZW50IG9hbSBwcm90b2NvbCBtb2R1bGVzIGF1Z21lbnQg dGhpcyBzdHJ1Y3R1cmU/DQo+PiA+DQo+PiA+IEhvdyBkb2VzIHRoaXMgaGVscCB5b3UgZmluZCB0 aGUgbW9kdWxlcyB0aGF0IGF1Z21lbnQgdGhpcyBzdHJ1Y3R1cmU/DQo+PiBZZXMsIHRoaXMgaXMg dGhlIGludGVudGlvbi4gQnkgdGhlbiBnZW5lcmF0aW5nIHRoZSB0cmVlIG9mIHRoZSBvdmVyYWxs DQo+PiBzdHJ1Y3R1cmUsIHRoZW4gSSBjYW4gc2VlIHdoYXQgZGlmZmVyZW50IGNvbnRhaW5lcnMg YXJlIGNyZWF0ZWQNCj4+IHRoZXJlLiBJdCdzIG5vdCBwZXJmZWN0IChhbmQgaGV5LCB0aGlzIHN1 Z2dlc3Rpb24gaXMgYSAqZHJhZnQqIGZvciBhDQo+PiByZWFzb24gLSBidXQgeWV0IGFnYWluLCB0 aGVyZSBhcmUgbm90IGFsdGVybmF0aXZlcykgLSBidXQgdGhlIGZhY3QNCj4+IHRoYXQgdGhlIG1v ZHVsZXMgYXVnbWVudCBhIGNvbW1vbiBwYXRoIGFkZHMgc29tZSBpbmZvcm1hdGlvbiB0aGF0IHRo ZXkNCj4+IGFyZSBncm91cGVkIHRvIHByb3ZpZGluZyB0aGUgc2FtZSBmdW5jdGlvbmFsaXR5LCBu b3QNCj4+IGRpc3BhcmF0ZS4gaWV0Zi1yb3V0aW5nIGRvZXMgdGhlIHNhbWUgdGhpbmcsIGl0IGdp dmVzIG1lIHRoZSBmYWN0IHRoYXQNCj4+IGF0IC9yb3V0aW5nL3JvdXRpbmctaW5zdGFuY2Uvcm91 dGluZy1wcm90b2NvbHMgdGhlcmUgYXJlIGEgYnVuY2ggb2YNCj4+IGNvbnRyb2wtcGxhbmUgcHJv dG9jb2xzIHRoYXQgYXJlIHJlbGF0ZWQgdG8gcm91dGluZy4NCj4NCj5Pay4gIFNvIHlvdXIgcHJv cG9zYWwgZG9lc24ndCBoZWxwIHdpdGggdGhlIHByb2JsZW0gb2YgbG9jYXRpbmcNCj5yZWxldmFu dCBZQU5HIG1vZHVsZXMsIGJ1dCBvbmNlIHRoZWlyIGxvY2F0ZWQsIGl0IGlzIGVhc2llciB0byBm aW5kDQo+dGhlIG9uZXMgcmVsYXRlZCB0byBhIHNwZWNpZmljIGZ1bmN0aW9uLCBiL2MgdGhleSB3 b3VsZCBhdWdtZW50IGENCj5jb21tb24gcGF0aC4gIElzIHRoaXMgd2hhdCB5b3UgbWVhbj8NCg0K V2h5IGRvZXNu4oCZdCBpdCBoZWxwPyBJbiB0aGUgbmV4dCByZXZpc2lvbiBvZiB0aGUgUm91dGlu ZyBZQU5HIERUIG1vZGVsLA0Kd2XigJl2ZSBzd2l0Y2hlZCBmcm9tIGluY2x1ZGluZyBzcGVjaWZp YyBtb2RlbHMgdG8gZGVmaW5pbmcgY2xhc3NlcyBvZg0KbW9kZWxzIHdpdGggaWRlbnRpdGllcy4g Rm9yIGV4YW1wbGUsDQoNCiBncm91cGluZyBvYW0tcHJvdG9jb2xzIHsNCiAgICAgIGNvbnRhaW5l ciBvYW0tcHJvdG9jb2xzIHsNCiAgICAgICAgICBsaXN0IG9hbS1wcm90b2NvbCB7DQogICAgICAg ICAgICAgIGtleSAidHlwZSI7DQogICAgICAgICAgICAgIGxlYWYgdHlwZSB7DQogICAgICAgICAg ICAgICAgICB0eXBlIGlkZW50aXR5cmVmIHsNCiAgICAgICAgICAgICAgICAgICAgICBiYXNlIG9h bS1wcm90b2NvbC10eXBlOw0KICAgICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAgICAgICAg bWFuZGF0b3J5IHRydWU7DQogICAgICAgICAgICAgICAgICBkZXNjcmlwdGlvbg0KICAgICAgICAg ICAgICAgICAgICAgICJUaGUgT3BlcmF0aW9ucywgQWRtaW5pc3RyYXRpb24sIGFuZA0KICAgICAg ICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAg ICBNYWludGVuYW5jZSAoT0FNKSBwcm90b2NvbCB0eXBlLCBlLmcuLCBCRkQsDQogICAgICAgICAg ICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgIFRX QU1QLCBDRk0sIGV0Yy4iOw0KICAgICAgICAgICAgICB9DQogICAgICAgICAgICAgIGRlc2NyaXB0 aW9uDQogICAgICAgICAgICAgICAgICAiTGlzdCBvZiBPQU0gcHJvdG9jb2xzIGNvbmZpZ3VyZWQg Zm9yIGENCiAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICANCiAgICAgICAg ICAgICAgICAgICBuZXR3b3JraW5nIGluc3RhbmNlLiI7DQogICAgICAgICAgfQ0KICAgICAgICAg IGRlc2NyaXB0aW9uDQogICAgICAgICAgICAgICJDb250YWluZXIgZm9yIGxpc3Qgb2YgT0FNIHBy b3RvY29scyBjb25maWd1cmVkIGZvciBhDQogICAgICAgICAgICAgICAgICAgDQogICAgICAgICAg ICAgICAgICAgDQogICAgICAgICAgICAgICAgbmV0d29ya2luZyBpbnN0YW5jZS4iOw0KICAgICAg fQ0KICAgICAgZGVzY3JpcHRpb24NCiAgICAgICAgICAiR3JvdXBpbmcgZm9yIE9BTSBwcm90b2Nv bHMgY29uZmlndXJlZCBmb3IgYQ0KICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAg ICAgIA0KICAgICAgICAgICBuZXR3b3JraW5nIGluc3RhbmNlLiI7DQogIH0NCg0KDQpUaGVuIHRo ZSBncm91cGluZyBpcyBpbmNsdWRlIHRoZSBuZXR3b3JraW5nLWluc3RhbmNlcy4gIEJ5IGRvaW5n IHRoaXMsIHRoZQ0KaW50ZW50IGlzIHRoYXQgaXQgd291bGQgYmUgZXZpZGVudCBhcyB0byB3aGVy ZSBhIHBhcnRpY3VsYXIgbW9kZWwgd291bGQgYmUNCmZvdW5kLiANCg0KVGhhbmtzLA0KQWNlZSAN Cg0KDQoNCj4NCj4NCj4+ID4+Pj4g4oCcSnVzdCByZWFkIHRocm91Z2ggdGhlIG1vZHVsZXPigJ0g aXMgbm90IGFjY2VwdGFibGUgYW5zd2VyIHdoZW4NCj4+ID4+Pj4gY29uc2lkZXJpbmcgbWFraW5n IHRoaW5ncyBlYXN5IHRvIHVzZSBmb3IgWUFORyBtb2RlbCBjb25zdW1lcnMuDQo+PiA+Pj4gQnV0 IGhvdyBkb2VzIHRoZSB0b3AtbGV2ZWwgbm9kZSAvZGV2aWNlIChzb3JyeSwgYnV0IEkgcmVhbGx5 IGhhdmUgdG8NCj4+ID4+PiBhc2sgdGhpcykgc29sdmUgdGhpcyBwcm9ibGVtPyAgSSAqcmVhbGx5 KiBkbyBub3QgdW5kZXJzdGFuZCB0aGlzLg0KPj4gPj4+IEV2ZW4gd2l0aCB5b3VyIHNvbHV0aW9u IHlvdSdkIGhhdmUgYSBzZXQgb2YgbW9kdWxlcyB0aGF0IGF1Z21lbnQNCj4+dGhpcw0KPj4gPj4+ IHN0cnVjdHVyZSwgcmlnaHQ/ICBIb3cgZG8gSSBrbm93IHdoYXQgdGhlc2Ugb3RoZXIgbW9kdWxl cyBhcmU/DQo+PiA+IFlvdSBkaWRuJ3QgYW5zd2VyIHRoaXMgcXVlc3Rpb24uICBTbyBJIHJlcGVh dGVkIGl0IGFib3ZlIGFuZCBiZWxvdyA7KQ0KPj4gUmlnaHQuIFRoZXJlIHdhcyByZWFsbHkgYSBy ZWFzb24gTk9UIHRvIGFuc3dlciBpdC4gL2RldmljZSBpcw0KPj4gaXJyZWxldmFudC4gSXQgZG9l cyBub3QgbWF0dGVyDQo+DQo+QnV0IHRoaXMgaXMgdGhlIHdoYXQgd2UgaGF2ZSBiZWVuIGFyZ3Vp bmcgYWJvdXQhICBSZW1vdmUgL2RldmljZSBhbmQNCj53ZSBjYW4gcHV0IHRoaXMgYmVoaW5kIHVz IGFuZCBtb3ZlIGZvcndhcmQuDQo+DQo+PiAtIGl0IGlzIHNpbXBseSBob3cgKnRoaXMgcHJvcG9z YWwqDQo+PiBjaG9vc2VzIHRvIGdyb3VwIHRoaW5ncywgYmFzZWQgb24gdGhlIGZhY3QgdGhhdCB3 ZSB0aGluayB0aGF0DQo+PiBvcGVyYXRvcnMgbG9naWNhbGx5IGNvbmZpZ3VyZSBkZXZpY2VzIHdo ZW4gZGVhbGluZyB3aXRoIHRoZXNlDQo+PiBtb2RlbHMuDQo+DQo+U3VyZSwgYW4gb3BlcmF0b3Ig Y29uZmlndXJlIGRldmljZXMuDQo+DQo+PiBGcm9tIHlvdXIgY29tbWVudHMgb24gTkNTIGJlbG93 LCBpdCBzZWVtcyB0byBtZSB0aGF0IGlmIHdlJ2QNCj4+IG1hZGUgdGhpcyBhIGxpc3QsIHRoZW4g dGhlcmUnZCBiZSBzaWduaWZpY2FudGx5IGxlc3MgY29uY2Vybj8NCj4NCj5ObyB0aGF0IHdvdWxk IGJlIGV2ZW4gd29yc2UhICBJZiBldmVyeSBkZXZpY2UgaGFkIGEgbGlzdCBvZiBleGFjdGx5DQo+ b25lIGRldmljZSAoaXRzZWxmKSwgdGhlIG9wZXJhdG9yIHdvdWxkIGhhdmUgdG8gZG8gdGhlIGVx dWl2YWxlbnQgb2Y6DQo+DQo+ICAkIHNzaCBydHIyDQo+ICAuLi4NCj4gID4gY29uZmlnDQo+ICAj IGRldmljZSBkZXZpY2UgcnRyMiBpbnRlcmZhY2UgZXRoMA0KPg0KPk9uIG1vc3Qgcm91dGVycyB5 b3UgZG9uJ3QgZG8gdGhpcy4gWW91IGp1c3QgZG86DQo+DQo+ICA+IGNvbmZpZw0KPiAgIyBpbnRl cmZhY2UgZXRoMA0KPg0KPg0KPk9yIGluIGFuIG9yY2hlc3RyYXRvciBsaWtlIE5DUyB5b3UnZCBo YXZlIHRvIGRvIHRoZSBlcXVpdmFsZW50IG9mOg0KPg0KPiAgJCBzc2ggb3JjaGVzdHJhdG9yDQo+ ICAuLi4NCj4gID4gY29uZmlnDQo+ICAjIGRldmljZXMgZGV2aWNlIHJ0cjIgZGF0YSBkZXZpY2Vz IGRldmljZSBydHIyIGludGVyZmFjZSBldGgwDQo+DQo+VGhpcyBqdXN0IGRvZXNuJ3QgbWFrZSBh bnkgc2Vuc2UuDQo+DQo+DQo+PiBJIGp1c3QNCj4+IGNhbid0IHVuZGVyc3RhbmQgd2h5IHRoaXMg aXMgc29tZXRoaW5nIHRvIGdldCBodW5nIHVwIG9uLiBJZiAvZGV2aWNlDQo+PiBpc24ndCB0aGUg cmlnaHQgcm9vdCwgcGxlYXNlIHNob3cgbWUgd2hhdCBpcyAtIGFuZCBXSFkgaXQncyBiZXR0ZXIu DQo+DQo+SnVzdCB1c2UgJy8nLiAgVGhlIHBvaW50IGlzIHRoYXQgKm9uIHRoZSBkZXZpY2UqIGEg cm9vdCBvZiAvZGV2aWNlDQo+ZG9lc24ndCBtYWtlIGFueSBzZW5zZS4NCj4NCj5JIGFtIGFsbCBm b3IgYSBjb21tb24gbW9kZWwgb2YgYSBkZXZpY2UgbGlzdCB0byBiZSB1c2VkIGluIHRoZQ0KPk5T TS9PU1MvLi4uLCBidXQgdGhhdCBpcyBhIHNlcGFyYXRlIGlzc3VlLg0KPg0KPj4gU3RydWN0dXJp bmcgY29uZmlndXJhdGlvbiBhbmQgb3BlcmF0aW9uYWwgYXJvdW5kIHNvbWUgaWRlYSB0aGF0IGFs bA0KPj4gdGhlIGNvbmZpZ3VyYXRpb24gYmVsb25ncyB0byBhIHBoeXNpY2FsIGRldmljZSBzZWVt cyB2ZXJ5LCB2ZXJ5DQo+PiBsb2dpY2FsIHRvIG1lLiBGdXJ0aGVyIGRlZmluaW5nIGdyb3VwcyBz byB0aGF0IHdlIGhhdmUgYW4NCj4+IHVuZGVyc3RhbmRpbmcgb2YgaG93IHRvIGJ1aWxkIGEgY29o ZXJlbnQgc2V0IG9mIG1vZGVscyBmb3IgdGhlDQo+PiBmdW5jdGlvbmFsaXRpZXMgcmVxdWlyZWQg b2YgdGhhdCBkZXZpY2Ugc2VlbXMgYSB2ZXJ5IGNsZWFyIG5leHQgc3RlcA0KPj4gYWZ0ZXIgdGhp cy4NCj4+ID4gVGhhbmtzLCB0aGlzIGlzIHdoYXQgSSByZW1lbWJlciB5b3UgbWVudGlvbmVkIGlu IERhbGxhcy4NCj4+ID4NCj4+ID4gQnV0IHdoYXQgZG9lcyB0aGlzIHJlYWxseSBtZWFuPyAgQXJl IHlvdSBwcm9wb3Npbmc6DQo+PiA+DQo+PiA+ICAgIDEpICB0byBkZWZpbmUgb25lIG1vZGVsIGll dGYtc29tZXRoaW5nIHRoYXQgY29udGFpbnMgdGhpcyBwcm9wb3NlZA0KPj4gPiAgICAgICAgc3Ry dWN0dXJlLCB3aGljaCB0aGVuIG90aGVyIG1vZHVsZXMgYXVnbWVudD8NCj4+ID4NCj4+ID4gICAg MikgIHRvIGRlZmluZSBvbmUgc2luZ2xlIGlldGYgbW9kZWwsIHBlcmlvZC4gIG5vIGF1Z21lbnRz IGJ5IHRoZQ0KPj4gPiAgICAgICAgaWV0Zi4NCj4+ID4NCj4+ID4gICAgMykgIHRvIGRlZmluZSB0 aGUgc3RydWN0dXJlIG1vcmUgbG9vc2VseSBpbiB0ZXh0LCBhbmQgdXNlIHRoaXMNCj4+ID4gICAg ICAgIHN0cnVjdHVyZSB3aGVuIG5ldyBtb2RlbHMgYXJlIGRldmVsb3BlZD8NCj4+ID4NCj4+ID4g ICAgNCkgIHNvbWV0aGluZyBlbHNlPw0KPj4gQXMgcGFydCBvZiBpdGVyYXRpbmcgb24gdGhpcyBp ZGVhLCB3ZSBhcmUgd29ya2luZyB0byB1bmRlcnN0YW5kIHRoZQ0KPj4gcHJhY3RpY2FsaXRpZXMg b2YgKDEpLiBUaGlzIGlzIGV4YWN0bHkgdGhlIGFwcHJvYWNoIHRoYXQgaWV0Zi1yb3V0aW5nDQo+ PiBpcyB0YWtpbmcgZm9yIHJvdXRpbmcgcHJvdG9jb2wgbW9kdWxlcy4NCj4NCj5UaGFua3MgZm9y IHRoZSBjbGFyaWZpY2F0aW9uLg0KPg0KPj4gPj4gVGhlIGxheW91dCBvZiB0aGUgc2V0cyBvZiBm dW5jdGlvbnMgdGhhdCB3ZSBoYXZlLCBhbmQgaG93IHRoZXkgYXJlDQo+PiA+PiBncm91cGVkLCBp cyB0aGUgaW1wb3J0YW50IHRoaW5nLiBUaGUgZmFjdCB0aGF0IHdlIGFyZSBjb25maWd1cmluZyBh DQo+PiA+PiBkZXZpY2UgbWFrZXMgL2RldmljZSBhIGdvb2Qgc3RhcnRpbmcgcG9pbnQuIEkgdGhp bmsgdGhpcyBpcyBob3cgeW91DQo+PiA+PiBpbXBsZW1lbnRlZCBORURzIGluIE5DUyB0b28uLi4/ DQo+PiA+IE5vLCBlYWNoIE5FRCAoZGV2aWNlKSBpcyBtb2RlbGxlZCBhY2NvcmRpbmcgdG8gaXRz IG5hdGl2ZSAibW9kZWwiLiAgU28NCj4+ID4gZm9yIGV4YW1wbGUgdGhlIElPUyBORUQgaGFzIC9p bnRlcmZhY2UsIC9pcCwgL3hjb25uZWN0LCBldGMuDQo+PiA+DQo+PiA+IEJ1dCwgYXMgSSBoYXZl IHNhaWQgYmVmb3JlLCB0aGUgZGV2aWNlIGFic3RyYWN0aW9uIGlzIHJlYWxseQ0KPj4gPiBpbXBv cnRhbnQgLSBpbiB0aGUgTk1TL09TUy9jb250cm9sbGVyL3doYXRldmVyLiAgVGhlcmUgd2UgaGF2 ZSBhIGxpc3QNCj4+ID4gb2YgZGV2aWNlcywgYW5kIGVhY2ggZGV2aWNlIGhhcyBhIG5hbWUgYW5k IG1ldGEtZGF0YSBhbmQgdGhlbiBpdHMgcmVhbA0KPj4gPiBkYXRhLCBzbyBmb3IgZXhhbXBsZSB3 ZSBjYW4gaGF2ZToNCj4+ID4NCj4+ID4gICAgIC9kZXZpY2VzL2RldmljZVtuYW1lPSdydHI0J10v aXANCj4+ID4gICAgIC9kZXZpY2VzL2RldmljZVtuYW1lPSdydHI0J10vcG9ydA0KPj4gPg0KPj4g PiBhbmQgdGhlbiB3ZSBwdXQgYWxsIGRhdGEgbW9kZWxzIGZyb20gdGhlIGRldmljZSB1bmRlciBh IGNvbW1vbg0KPj4gPiBjb250YWluZXIgJ2RhdGEnOg0KPj4gPg0KPj4gPiAgICAgL2RldmljZXMv ZGV2aWNlW25hbWU9J3J0cjQnXS9kYXRhL2ludGVyZmFjZS8NCj4+ID4gICAgIC9kZXZpY2VzL2Rl dmljZVtuYW1lPSdydHI0J10vZGF0YS94Y29ubmVjdC8NCj4+ID4NCj4+ID4gSWYgdGhlIGRldmlj ZSBoYWQgYSB0b3AtbGV2ZWwgY29udGFpbmVyICJkZXZpY2UiIHRoaXMgd291bGQgaGF2ZSBiZWVu Og0KPj4gPg0KPj4gPiAgICAgL2RldmljZXMvZGV2aWNlW25hbWU9J3J0cjQnXS9kYXRhL2Rldmlj ZS9pbnRlcmZhY2VzDQo+PiBUaGlzIGFwcHJvYWNoICpET0VTKiBsb2dpY2FsbHkgc3RydWN0dXJl IGNvbmZpZ3VyYXRpb24gYXJvdW5kIHRoZQ0KPj4gY29uY2VwdCBvZiBhIGRldmljZS4NCj4NCj5Z ZXMgLSBpbiB0aGUgTk1TL09TUy9jb250cm9sbGVyIC0gKm5vdCogb24gdGhlIGRldmljZSENCj4N Cj4NCj4NCj4NCj4+IElmIHdlIGFyZSByZWFsbHkganVzdCBkZWJhdGluZyB3aGV0aGVyDQo+PiAv ZGV2aWNlcy9kZXZpY2UgaXMgYSBsaXN0IG9yIHdoZXRoZXIgaXQncyBhIGNvbnRhaW5lciwgSSdt IGV2ZW4gbW9yZQ0KPj4gY29uZnVzZWQgdGhhbiBJIHdhcyBiZWZvcmUuIFBsZWFzZSBzZWUgbXkg ZWFybGllciBjb21tZW50Lg0KPg0KPg0KPi9tYXJ0aW4NCj4NCj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPm5ldG1vZCBtYWlsaW5nIGxpc3QNCj5uZXRt b2RAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1v ZA0KDQo= From nobody Fri Aug 28 06:22:12 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD1371A8911 for ; Fri, 28 Aug 2015 06:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.738 X-Spam-Level: X-Spam-Status: No, score=0.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, RCVD_IN_DNSWL_LOW=-0.7, 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 Mw_ftpaaYNZ2 for ; Fri, 28 Aug 2015 06:22:10 -0700 (PDT) Received: from mail.hq.sk (hq.sk [81.89.59.181]) by ietfa.amsl.com (Postfix) with ESMTP id 008471A7000 for ; Fri, 28 Aug 2015 06:22:09 -0700 (PDT) Received: from [10.0.2.15] (188-167-5-4.dynamic.chello.sk [188.167.5.4]) by mail.hq.sk (Postfix) with ESMTPSA id 2B9702438EE; Fri, 28 Aug 2015 15:22:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1440768129; bh=K9q+Qu2Qq6Vz4+0VyqlE2VuE54HTX5pD94Yi+UV/b6A=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=sHfOkUqK7po6XE49G0mYXQNmeEdCR8CDU1NUnzuZ/rGy5d+b8mMpr84J4VqxHqneB 4Ogm3TpIEOyB3ze1UabJ1xaCuSUFVo0D2idT65+s3j6gyHZ9o6dPb3PFjURvRwnUc1 uPr0cszIBXNkP6YzXn4rc8UoADEi6dSgKqwH+q/Y= To: Andy Bierman , Lou Berger References: <5497CE3E-19A7-4AAC-AE32-AFC9BC2451F1@nic.cz> <06C8EE42-B70D-40A7-8B16-053D37378043@nic.cz> <20150720210041.GA17614@elstar.local> <14ecceb6dd0.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> From: Robert Varga Message-ID: <55DFC8CC.5020305@hq.sk> Date: Fri, 28 Aug 2015 04:34:52 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Y34 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 13:22:10 -0000 On 07/27/2015 08:18 AM, Andy Bierman wrote: > (1) Aggregation of datastores > > The simplest form is aggregation. > It is possible to define a YANG container that is a conceptual > document root, such that the set of child nodes matches the set > of top-level YANG data nodes supported by the server. I think a run-time facility to provide an actual list of valid models would be useful. Since the aggregation can be the result of aggregating various devices, the set of valid nodes may differ between root container instances. Bye, Robert From nobody Fri Aug 28 06:24:02 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB7E1ACEA4 for ; Fri, 28 Aug 2015 06:24:01 -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 CQaqNuS6D71b for ; Fri, 28 Aug 2015 06:23: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 75B581ACD4A for ; Fri, 28 Aug 2015 06:23:59 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id B805D1AE0481; Fri, 28 Aug 2015 15:23:58 +0200 (CEST) Date: Fri, 28 Aug 2015 15:24:29 +0200 (CEST) Message-Id: <20150828.152429.253858432985165209.mbj@tail-f.com> To: acee@cisco.com From: Martin Bjorklund In-Reply-To: References: <55E054DC.7050906@rob.sh> <20150828.145546.1509142825487206251.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=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Motivations for Structuring Models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 13:24:01 -0000 IkFjZWUgTGluZGVtIChhY2VlKSIgPGFjZWVAY2lzY28uY29tPiB3cm90ZToNCj4gDQo+IA0KPiBP biA4LzI4LzE1LCA4OjU1IEFNLCAibmV0bW9kIG9uIGJlaGFsZiBvZiBNYXJ0aW4gQmpvcmtsdW5k Ig0KPiA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIG1iakB0YWlsLWYuY29t PiB3cm90ZToNCj4gDQo+ID5Sb2IgU2hha2lyIDxyanNAcm9iLnNoPiB3cm90ZToNCj4gPj4gDQo+ ID4+IEhpIE1hcnRpbiwNCj4gPj4gDQo+ID4+IFRoYW5rcyBmb3IgdGhlIHJlcGx5Lg0KPiA+PiA+ IE1hcnRpbiBCam9ya2x1bmQgPG1haWx0bzptYmpAdGFpbC1mLmNvbT4NCj4gPj4gPiBBdWd1c3Qg MjgsIDIwMTUgYXQgMDI6MzMNCj4gPj4gPiBTbyB0aGUgaWRlYSBpcyB0aGF0IHRoaXMgc3RydWN0 dXJlIGlzIGRlZmluZWQgaW4gb25lIG1vZHVsZSwNCj4gPj4gPiBpZXRmLXNvbWV0aGluZy1zdHJ1 Y3R1cmUsIHJpZ2h0Pw0KPiA+PiA+DQo+ID4+ID4gQW5kIHRoZW4gZGlmZmVyZW50IG9hbSBwcm90 b2NvbCBtb2R1bGVzIGF1Z21lbnQgdGhpcyBzdHJ1Y3R1cmU/DQo+ID4+ID4NCj4gPj4gPiBIb3cg ZG9lcyB0aGlzIGhlbHAgeW91IGZpbmQgdGhlIG1vZHVsZXMgdGhhdCBhdWdtZW50IHRoaXMgc3Ry dWN0dXJlPw0KPiA+PiBZZXMsIHRoaXMgaXMgdGhlIGludGVudGlvbi4gQnkgdGhlbiBnZW5lcmF0 aW5nIHRoZSB0cmVlIG9mIHRoZSBvdmVyYWxsDQo+ID4+IHN0cnVjdHVyZSwgdGhlbiBJIGNhbiBz ZWUgd2hhdCBkaWZmZXJlbnQgY29udGFpbmVycyBhcmUgY3JlYXRlZA0KPiA+PiB0aGVyZS4gSXQn cyBub3QgcGVyZmVjdCAoYW5kIGhleSwgdGhpcyBzdWdnZXN0aW9uIGlzIGEgKmRyYWZ0KiBmb3Ig YQ0KPiA+PiByZWFzb24gLSBidXQgeWV0IGFnYWluLCB0aGVyZSBhcmUgbm90IGFsdGVybmF0aXZl cykgLSBidXQgdGhlIGZhY3QNCj4gPj4gdGhhdCB0aGUgbW9kdWxlcyBhdWdtZW50IGEgY29tbW9u IHBhdGggYWRkcyBzb21lIGluZm9ybWF0aW9uIHRoYXQgdGhleQ0KPiA+PiBhcmUgZ3JvdXBlZCB0 byBwcm92aWRpbmcgdGhlIHNhbWUgZnVuY3Rpb25hbGl0eSwgbm90DQo+ID4+IGRpc3BhcmF0ZS4g aWV0Zi1yb3V0aW5nIGRvZXMgdGhlIHNhbWUgdGhpbmcsIGl0IGdpdmVzIG1lIHRoZSBmYWN0IHRo YXQNCj4gPj4gYXQgL3JvdXRpbmcvcm91dGluZy1pbnN0YW5jZS9yb3V0aW5nLXByb3RvY29scyB0 aGVyZSBhcmUgYSBidW5jaCBvZg0KPiA+PiBjb250cm9sLXBsYW5lIHByb3RvY29scyB0aGF0IGFy ZSByZWxhdGVkIHRvIHJvdXRpbmcuDQo+ID4NCj4gPk9rLiAgU28geW91ciBwcm9wb3NhbCBkb2Vz bid0IGhlbHAgd2l0aCB0aGUgcHJvYmxlbSBvZiBsb2NhdGluZw0KPiA+cmVsZXZhbnQgWUFORyBt b2R1bGVzLCBidXQgb25jZSB0aGVpciBsb2NhdGVkLCBpdCBpcyBlYXNpZXIgdG8gZmluZA0KPiA+ dGhlIG9uZXMgcmVsYXRlZCB0byBhIHNwZWNpZmljIGZ1bmN0aW9uLCBiL2MgdGhleSB3b3VsZCBh dWdtZW50IGENCj4gPmNvbW1vbiBwYXRoLiAgSXMgdGhpcyB3aGF0IHlvdSBtZWFuPw0KPiANCj4g V2h5IGRvZXNu4oCZdCBpdCBoZWxwPyBJbiB0aGUgbmV4dCByZXZpc2lvbiBvZiB0aGUgUm91dGlu ZyBZQU5HIERUIG1vZGVsLA0KPiB3ZeKAmXZlIHN3aXRjaGVkIGZyb20gaW5jbHVkaW5nIHNwZWNp ZmljIG1vZGVscyB0byBkZWZpbmluZyBjbGFzc2VzIG9mDQo+IG1vZGVscyB3aXRoIGlkZW50aXRp ZXMuIEZvciBleGFtcGxlLA0KPiANCj4gIGdyb3VwaW5nIG9hbS1wcm90b2NvbHMgew0KPiAgICAg ICBjb250YWluZXIgb2FtLXByb3RvY29scyB7DQo+ICAgICAgICAgICBsaXN0IG9hbS1wcm90b2Nv bCB7DQo+ICAgICAgICAgICAgICAga2V5ICJ0eXBlIjsNCj4gICAgICAgICAgICAgICBsZWFmIHR5 cGUgew0KPiAgICAgICAgICAgICAgICAgICB0eXBlIGlkZW50aXR5cmVmIHsNCj4gICAgICAgICAg ICAgICAgICAgICAgIGJhc2Ugb2FtLXByb3RvY29sLXR5cGU7DQo+ICAgICAgICAgICAgICAgICAg IH0NCj4gICAgICAgICAgICAgICAgICAgbWFuZGF0b3J5IHRydWU7DQo+ICAgICAgICAgICAgICAg ICAgIGRlc2NyaXB0aW9uDQo+ICAgICAgICAgICAgICAgICAgICAgICAiVGhlIE9wZXJhdGlvbnMs IEFkbWluaXN0cmF0aW9uLCBhbmQNCj4gICAgICAgICAgICAgICAgICAgIA0KPiAgICAgICAgICAg ICAgICAgICAgDQo+ICAgICAgICAgICAgICAgICAgICAgICAgTWFpbnRlbmFuY2UgKE9BTSkgcHJv dG9jb2wgdHlwZSwgZS5nLiwgQkZELA0KPiAgICAgICAgICAgICAgICAgICAgDQo+ICAgICAgICAg ICAgICAgICAgICANCj4gICAgICAgICAgICAgICAgICAgICAgICBUV0FNUCwgQ0ZNLCBldGMuIjsN Cj4gICAgICAgICAgICAgICB9DQo+ICAgICAgICAgICAgICAgZGVzY3JpcHRpb24NCj4gICAgICAg ICAgICAgICAgICAgIkxpc3Qgb2YgT0FNIHByb3RvY29scyBjb25maWd1cmVkIGZvciBhDQo+ICAg ICAgICAgICAgICAgICAgICANCj4gICAgICAgICAgICAgICAgICAgIA0KPiAgICAgICAgICAgICAg ICAgICAgbmV0d29ya2luZyBpbnN0YW5jZS4iOw0KPiAgICAgICAgICAgfQ0KPiAgICAgICAgICAg ZGVzY3JpcHRpb24NCj4gICAgICAgICAgICAgICAiQ29udGFpbmVyIGZvciBsaXN0IG9mIE9BTSBw cm90b2NvbHMgY29uZmlndXJlZCBmb3IgYQ0KPiAgICAgICAgICAgICAgICAgICAgDQo+ICAgICAg ICAgICAgICAgICAgICANCj4gICAgICAgICAgICAgICAgIG5ldHdvcmtpbmcgaW5zdGFuY2UuIjsN Cj4gICAgICAgfQ0KPiAgICAgICBkZXNjcmlwdGlvbg0KPiAgICAgICAgICAgIkdyb3VwaW5nIGZv ciBPQU0gcHJvdG9jb2xzIGNvbmZpZ3VyZWQgZm9yIGENCj4gICAgICAgICAgICAgICAgICAgIA0K PiAgICAgICAgICAgICAgICAgICAgDQo+ICAgICAgICAgICAgbmV0d29ya2luZyBpbnN0YW5jZS4i Ow0KPiAgIH0NCj4gDQo+IA0KPiBUaGVuIHRoZSBncm91cGluZyBpcyBpbmNsdWRlIHRoZSBuZXR3 b3JraW5nLWluc3RhbmNlcy4gIEJ5IGRvaW5nIHRoaXMsIHRoZQ0KPiBpbnRlbnQgaXMgdGhhdCBp dCB3b3VsZCBiZSBldmlkZW50IGFzIHRvIHdoZXJlIGEgcGFydGljdWxhciBtb2RlbCB3b3VsZCBi ZQ0KPiBmb3VuZC4gDQoNCk5vdyBJIGFtIGEgdXNlciBvZiBZQU5HIG1vZGVscy4gIEkgYW0gc2Vh cmNoaW5nIGZvciB0aGUgWUFORyBtb2R1bGUNCnRoYXQgZGVmaW5lcyBPQU0gZm9yIEJGRC4gIEhv dyBkb2VzIHlvdXIgbW9kZWwgYWJvdmUgaGVscCBtZSBmaW5kIGl0Pw0KDQoNCi9tYXJ0aW4NCg== From nobody Fri Aug 28 06:29:00 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC77F1A8A48 for ; Fri, 28 Aug 2015 06:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VoIuV1kdjb0S for ; Fri, 28 Aug 2015 06:28:56 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9810A1A8845 for ; Fri, 28 Aug 2015 06:28:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4956; q=dns/txt; s=iport; t=1440768536; x=1441978136; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=p4ePVrej3idcLujF0CPHNgzLUdfYvEsR7+ewEO9ay/4=; b=PrAuhA5OewE/VnekknOpvTowkDFRMRnCmMgUoAs5gRGh5J9t+9qrJSyp 5+AYU6+c5VjRLVD60yRjWwJi31Gw4ZcCYuL8uwPkr7D50vy82sH+Oe1HJ d3S01EIRvQpVspDewCpRBMDcnw526f5rSogs1aGvoUwmVe+lbdqojY0M1 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0COBQDEYOBV/5hdJa1egxuBPQaDHbpmh3MCHIEeOhIBAQEBAQEBgQqEJAEBBCMRRRACAQgOCgICIwMCAgIwFAEQAgQOBYgur2SUYQEBAQEBAQEBAQEBAQEBAQEBAQEZgSKKQIULB4JpgUMFlT0BjHKBSpUug2smg39xgUiBBQEBAQ X-IronPort-AV: E=Sophos;i="5.17,424,1437436800"; d="scan'208";a="22395065" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 28 Aug 2015 13:28:54 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t7SDSsfc001555 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 28 Aug 2015 13:28:54 GMT Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 28 Aug 2015 08:28:53 -0500 Received: from xhc-aln-x07.cisco.com (173.36.12.81) by xch-rcd-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Fri, 28 Aug 2015 08:28:53 -0500 Received: from xmb-aln-x06.cisco.com ([169.254.1.223]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0248.002; Fri, 28 Aug 2015 08:28:53 -0500 From: "Acee Lindem (acee)" To: Martin Bjorklund Thread-Topic: [netmod] Motivations for Structuring Models Thread-Index: AQHQ4NBLQlr4e3n2uUqD0R28uxSQo54gW/iAgAAU4ACAACMmAIAADoUAgACmsgCAAGQvAIAABoMA///D9QCAAEQRgP//vjIA Date: Fri, 28 Aug 2015 13:28:52 +0000 Message-ID: References: <55E054DC.7050906@rob.sh> <20150828.145546.1509142825487206251.mbj@tail-f.com> <20150828.152429.253858432985165209.mbj@tail-f.com> In-Reply-To: <20150828.152429.253858432985165209.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.36.7.18] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Motivations for Structuring Models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 13:28:58 -0000 DQoNCk9uIDgvMjgvMTUsIDk6MjQgQU0sICJNYXJ0aW4gQmpvcmtsdW5kIiA8bWJqQHRhaWwtZi5j b20+IHdyb3RlOg0KDQo+IkFjZWUgTGluZGVtIChhY2VlKSIgPGFjZWVAY2lzY28uY29tPiB3cm90 ZToNCj4+IA0KPj4gDQo+PiBPbiA4LzI4LzE1LCA4OjU1IEFNLCAibmV0bW9kIG9uIGJlaGFsZiBv ZiBNYXJ0aW4gQmpvcmtsdW5kIg0KPj4gPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFs ZiBvZiBtYmpAdGFpbC1mLmNvbT4gd3JvdGU6DQo+PiANCj4+ID5Sb2IgU2hha2lyIDxyanNAcm9i LnNoPiB3cm90ZToNCj4+ID4+IA0KPj4gPj4gSGkgTWFydGluLA0KPj4gPj4gDQo+PiA+PiBUaGFu a3MgZm9yIHRoZSByZXBseS4NCj4+ID4+ID4gTWFydGluIEJqb3JrbHVuZCA8bWFpbHRvOm1iakB0 YWlsLWYuY29tPg0KPj4gPj4gPiBBdWd1c3QgMjgsIDIwMTUgYXQgMDI6MzMNCj4+ID4+ID4gU28g dGhlIGlkZWEgaXMgdGhhdCB0aGlzIHN0cnVjdHVyZSBpcyBkZWZpbmVkIGluIG9uZSBtb2R1bGUs DQo+PiA+PiA+IGlldGYtc29tZXRoaW5nLXN0cnVjdHVyZSwgcmlnaHQ/DQo+PiA+PiA+DQo+PiA+ PiA+IEFuZCB0aGVuIGRpZmZlcmVudCBvYW0gcHJvdG9jb2wgbW9kdWxlcyBhdWdtZW50IHRoaXMg c3RydWN0dXJlPw0KPj4gPj4gPg0KPj4gPj4gPiBIb3cgZG9lcyB0aGlzIGhlbHAgeW91IGZpbmQg dGhlIG1vZHVsZXMgdGhhdCBhdWdtZW50IHRoaXMNCj4+c3RydWN0dXJlPw0KPj4gPj4gWWVzLCB0 aGlzIGlzIHRoZSBpbnRlbnRpb24uIEJ5IHRoZW4gZ2VuZXJhdGluZyB0aGUgdHJlZSBvZiB0aGUN Cj4+b3ZlcmFsbA0KPj4gPj4gc3RydWN0dXJlLCB0aGVuIEkgY2FuIHNlZSB3aGF0IGRpZmZlcmVu dCBjb250YWluZXJzIGFyZSBjcmVhdGVkDQo+PiA+PiB0aGVyZS4gSXQncyBub3QgcGVyZmVjdCAo YW5kIGhleSwgdGhpcyBzdWdnZXN0aW9uIGlzIGEgKmRyYWZ0KiBmb3IgYQ0KPj4gPj4gcmVhc29u IC0gYnV0IHlldCBhZ2FpbiwgdGhlcmUgYXJlIG5vdCBhbHRlcm5hdGl2ZXMpIC0gYnV0IHRoZSBm YWN0DQo+PiA+PiB0aGF0IHRoZSBtb2R1bGVzIGF1Z21lbnQgYSBjb21tb24gcGF0aCBhZGRzIHNv bWUgaW5mb3JtYXRpb24gdGhhdA0KPj50aGV5DQo+PiA+PiBhcmUgZ3JvdXBlZCB0byBwcm92aWRp bmcgdGhlIHNhbWUgZnVuY3Rpb25hbGl0eSwgbm90DQo+PiA+PiBkaXNwYXJhdGUuIGlldGYtcm91 dGluZyBkb2VzIHRoZSBzYW1lIHRoaW5nLCBpdCBnaXZlcyBtZSB0aGUgZmFjdA0KPj50aGF0DQo+ PiA+PiBhdCAvcm91dGluZy9yb3V0aW5nLWluc3RhbmNlL3JvdXRpbmctcHJvdG9jb2xzIHRoZXJl IGFyZSBhIGJ1bmNoIG9mDQo+PiA+PiBjb250cm9sLXBsYW5lIHByb3RvY29scyB0aGF0IGFyZSBy ZWxhdGVkIHRvIHJvdXRpbmcuDQo+PiA+DQo+PiA+T2suICBTbyB5b3VyIHByb3Bvc2FsIGRvZXNu J3QgaGVscCB3aXRoIHRoZSBwcm9ibGVtIG9mIGxvY2F0aW5nDQo+PiA+cmVsZXZhbnQgWUFORyBt b2R1bGVzLCBidXQgb25jZSB0aGVpciBsb2NhdGVkLCBpdCBpcyBlYXNpZXIgdG8gZmluZA0KPj4g PnRoZSBvbmVzIHJlbGF0ZWQgdG8gYSBzcGVjaWZpYyBmdW5jdGlvbiwgYi9jIHRoZXkgd291bGQg YXVnbWVudCBhDQo+PiA+Y29tbW9uIHBhdGguICBJcyB0aGlzIHdoYXQgeW91IG1lYW4/DQo+PiAN Cj4+IFdoeSBkb2VzbuKAmXQgaXQgaGVscD8gSW4gdGhlIG5leHQgcmV2aXNpb24gb2YgdGhlIFJv dXRpbmcgWUFORyBEVCBtb2RlbCwNCj4+IHdl4oCZdmUgc3dpdGNoZWQgZnJvbSBpbmNsdWRpbmcg c3BlY2lmaWMgbW9kZWxzIHRvIGRlZmluaW5nIGNsYXNzZXMgb2YNCj4+IG1vZGVscyB3aXRoIGlk ZW50aXRpZXMuIEZvciBleGFtcGxlLA0KPj4gDQo+PiAgZ3JvdXBpbmcgb2FtLXByb3RvY29scyB7 DQo+PiAgICAgICBjb250YWluZXIgb2FtLXByb3RvY29scyB7DQo+PiAgICAgICAgICAgbGlzdCBv YW0tcHJvdG9jb2wgew0KPj4gICAgICAgICAgICAgICBrZXkgInR5cGUiOw0KPj4gICAgICAgICAg ICAgICBsZWFmIHR5cGUgew0KPj4gICAgICAgICAgICAgICAgICAgdHlwZSBpZGVudGl0eXJlZiB7 DQo+PiAgICAgICAgICAgICAgICAgICAgICAgYmFzZSBvYW0tcHJvdG9jb2wtdHlwZTsNCj4+ICAg ICAgICAgICAgICAgICAgIH0NCj4+ICAgICAgICAgICAgICAgICAgIG1hbmRhdG9yeSB0cnVlOw0K Pj4gICAgICAgICAgICAgICAgICAgZGVzY3JpcHRpb24NCj4+ICAgICAgICAgICAgICAgICAgICAg ICAiVGhlIE9wZXJhdGlvbnMsIEFkbWluaXN0cmF0aW9uLCBhbmQNCj4+ICAgICAgICAgICAgICAg ICANCj4+ICAgICAgICAgICAgICAgICANCj4+ICAgICAgICAgICAgICAgICAgICAgICAgTWFpbnRl bmFuY2UgKE9BTSkgcHJvdG9jb2wgdHlwZSwgZS5nLiwgQkZELA0KPj4gICAgICAgICAgICAgICAg IA0KPj4gICAgICAgICAgICAgICAgIA0KPj4gICAgICAgICAgICAgICAgICAgICAgICBUV0FNUCwg Q0ZNLCBldGMuIjsNCj4+ICAgICAgICAgICAgICAgfQ0KPj4gICAgICAgICAgICAgICBkZXNjcmlw dGlvbg0KPj4gICAgICAgICAgICAgICAgICAgIkxpc3Qgb2YgT0FNIHByb3RvY29scyBjb25maWd1 cmVkIGZvciBhDQo+PiAgICAgICAgICAgICAgICAgDQo+PiAgICAgICAgICAgICAgICAgDQo+PiAg ICAgICAgICAgICAgICAgICAgbmV0d29ya2luZyBpbnN0YW5jZS4iOw0KPj4gICAgICAgICAgIH0N Cj4+ICAgICAgICAgICBkZXNjcmlwdGlvbg0KPj4gICAgICAgICAgICAgICAiQ29udGFpbmVyIGZv ciBsaXN0IG9mIE9BTSBwcm90b2NvbHMgY29uZmlndXJlZCBmb3IgYQ0KPj4gICAgICAgICAgICAg ICAgIA0KPj4gICAgICAgICAgICAgICAgIA0KPj4gICAgICAgICAgICAgICAgIG5ldHdvcmtpbmcg aW5zdGFuY2UuIjsNCj4+ICAgICAgIH0NCj4+ICAgICAgIGRlc2NyaXB0aW9uDQo+PiAgICAgICAg ICAgIkdyb3VwaW5nIGZvciBPQU0gcHJvdG9jb2xzIGNvbmZpZ3VyZWQgZm9yIGENCj4+ICAgICAg ICAgICAgICAgICANCj4+ICAgICAgICAgICAgICAgICANCj4+ICAgICAgICAgICAgbmV0d29ya2lu ZyBpbnN0YW5jZS4iOw0KPj4gICB9DQo+PiANCj4+IA0KPj4gVGhlbiB0aGUgZ3JvdXBpbmcgaXMg aW5jbHVkZSB0aGUgbmV0d29ya2luZy1pbnN0YW5jZXMuICBCeSBkb2luZyB0aGlzLA0KPj50aGUN Cj4+IGludGVudCBpcyB0aGF0IGl0IHdvdWxkIGJlIGV2aWRlbnQgYXMgdG8gd2hlcmUgYSBwYXJ0 aWN1bGFyIG1vZGVsIHdvdWxkDQo+PmJlDQo+PiBmb3VuZC4gDQo+DQo+Tm93IEkgYW0gYSB1c2Vy IG9mIFlBTkcgbW9kZWxzLiAgSSBhbSBzZWFyY2hpbmcgZm9yIHRoZSBZQU5HIG1vZHVsZQ0KPnRo YXQgZGVmaW5lcyBPQU0gZm9yIEJGRC4gIEhvdyBkb2VzIHlvdXIgbW9kZWwgYWJvdmUgaGVscCBt ZSBmaW5kIGl0Pw0KDQpJZiBvbmUgY2FuIGVudmlzaW9uIGEgZnVuY3Rpb24gdG8gbGlzdCB0aGUg c2NoZW1hIHJhdGhlciB0aGFuIHRoZSBhY3R1YWwNCmNvbmZpZyBkYXRhLCB5b3UgY291bGQgcmV0 cmlldmUgdGhlIHNjaGVtYSBmb3IgdGhlIG9hbS1wcm90b2NvbHMNCmNvbnRhaW5lci4gSXQgd291 bGQgc2VlbSByZWFzb25hYmxlIHRvIHN1cHBvcnQgc3VjaCBhIGZ1bmN0aW9uLg0KDQpUaGFua3Ms DQpBY2VlDQoNCg0KPg0KPg0KPi9tYXJ0aW4NCg0K From nobody Fri Aug 28 06:34:26 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFEFC1B2D0D for ; Fri, 28 Aug 2015 06:34:24 -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 JUopHGcFh0sW for ; Fri, 28 Aug 2015 06:34:23 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CBCB1B2C33 for ; Fri, 28 Aug 2015 06:34:23 -0700 (PDT) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id E7AA318046C; Fri, 28 Aug 2015 15:34:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1440768861; bh=begVxI4CgFHFzreEiVedw/R86l1in0sSsbcD2UZJ9Gk=; h=From:Date:To; b=dQaqDIwPC0zYY7Vor2ZfAAGutnBkObwzsyLmDWSv+c1o7C/qZkYWkGFnvGwDQ4LRj Cy2QS2bcAu4GNeIkUJkS+YLKOdc2opMdIA+AXeoduEOyCB3Gknmz6CAQY4xkNyaVEx XBWJQE+P8NwCoY+vbgNkUGIj1JiM0IBF3o9+d/Qs= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Ladislav Lhotka In-Reply-To: <55DFC6CF.7060105@hq.sk> Date: Fri, 28 Aug 2015 15:34:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6FA04E5F-F0FB-45F7-B17F-BDDA1C9C1D18@nic.cz> References: <5497CE3E-19A7-4AAC-AE32-AFC9BC2451F1@nic.cz> <06C8EE42-B70D-40A7-8B16-053D37378043@nic.cz> <20150720210041.GA17614@elstar.local> <4D704311-D5B7-43F3-BD23-C13D5289CF46@nic.cz> <20150721074428.GC18607@elstar.local> <55DFC6CF.7060105@hq.sk> To: Robert Varga X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Y34 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 13:34:24 -0000 Hi Robert, > On 28 Aug 2015, at 04:26, Robert Varga wrote: >=20 > On 07/21/2015 09:44 AM, Juergen Schoenwaelder wrote: >> Lada, you can't simply 'mount' a data model into a different place. >> Think about paths in must or when expressions, or think about paths >> contraints in leafrefs etc >=20 > In ODL we already have a language extension which does this. = Semantically it embeds the conceptual 'root' node into container/list = item. That item becomes the logical root against which all expressions = in the embedded models are evaluated against, e.g. it is its own little = world, no constraints coming in or out of it. While incoming references = could be done (by just crossing the embedding item), we have not found a = use case for it yet. Yes, I think this could work. Two questions: 1. Is it possible to graft the same module multiple times in different = places, perhaps in different revisions and with different features? 2. Can you identify a *set* of modules that are chrooted this way? For = example, can you say you want to have a common root for ietf-interfaces, = ietf-ip and ietf-system, rather than putting each module in its separate = little world? Thanks, Lada >=20 > This works rather well for providing a 'pass-through' function through = a network controller down to individual devices: the devices themselves = are represented as nodes in the topology model (exposed on the = northbound) and a container holding the 'mount-point'. All operations in = the mount-point space are mapped to NETCONF operations on the device = (and hence it is the device itself who enforces constraints and = referential integrity). >=20 > Bye, > Robert >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Aug 28 06:37:41 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 545651B2FF7 for ; Fri, 28 Aug 2015 06:37:40 -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 6ddxj5WFHywy for ; Fri, 28 Aug 2015 06:37: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 B2D491ACE0E for ; Fri, 28 Aug 2015 06:37:37 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 040E81AE06C0; Fri, 28 Aug 2015 15:37:37 +0200 (CEST) Date: Fri, 28 Aug 2015 15:37:59 +0200 (CEST) Message-Id: <20150828.153759.1294531593347527560.mbj@tail-f.com> To: rjs@rob.sh From: Martin Bjorklund In-Reply-To: <55E05E1B.2090407@rob.sh> References: <55E054DC.7050906@rob.sh> <20150828.145546.1509142825487206251.mbj@tail-f.com> <55E05E1B.2090407@rob.sh> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Motivations for Structuring Models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 13:37:40 -0000 Rob Shakir wrote: > Martin, > > We are almost certainly not on the same page as to what we're > debating. > > Martin Bjorklund > > August 28, 2015 at 08:55 > > > > > > Ok. So your proposal doesn't help with the problem of locating > > relevant YANG modules, but once their located, it is easier to find > > the ones related to a specific function, b/c they would augment a > > common path. Is this what you mean? > Having a structure to the way that the tree is defined helps a > developer trying to consume functions find the relevant > functionality. The model-writer needs to be aware of this structure. I > think there is an important difference between model writer (not very > many of these), and model consumer (lots of these). I don't understand this answer (or maybe you misunderstood my question?). > > But this is the what we have been arguing about! Remove /device and > > we can put this behind us and move forward. > > > So, if I take openconfig-model-structure and make it look like: > > module: model-structure [NB: trimmed for legibility.] > +--rw info > +--rw hardware > +--rw system > +--rw interfaces > +--rw acl > +--rw qos > +--rw logical-routers > +--rw logical-router* [router-id] > +--rw router-id uint8 > +--rw router-name? string > +--rw layer-2-protocols > +--rw layer-3-protocols > +--rw vrf* [vrf-name] > +--rw routing-policy > > Then you have no objection to this approach? Even though it will > *still* very likely obsolete RFC'd models, which don't fit into the > structure. I didn't say that I agree with all nodes in the structure, but I do agree that a structure for common things (like intrefaces, routing protocols, oam functions etc) is useful. RFC 7223 already defines /interfaces and RFC 7317 defines /system, so I assume they can be kept. Unless of course you think the namespace is important. As for logical-routers, see the other thread. /martin From nobody Fri Aug 28 07:08:11 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 171751A90E7 for ; Fri, 28 Aug 2015 07:08: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 3fTZBSVqGEqZ for ; Fri, 28 Aug 2015 07:08:08 -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 69C2D1A009F for ; Fri, 28 Aug 2015 07:08:07 -0700 (PDT) Received: by lbbsx3 with SMTP id sx3so30784914lbb.0 for ; Fri, 28 Aug 2015 07:08:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gKEKwfjeTfqRkHPzGySxA8wNNuLrlXpOMquWvUtjfgI=; b=aJ1A3EyRUX6/VpbJ0XRSzd6jYg4p3L+nQ4jjScfo7nuNkh3zcC2Bz55sDhnJj/Lpu1 PJMoH6c6EbHad3dU72E/f75BXrHNISoTzL5/rzzuZ49NMZavyZxZenOy79LJ48TIyAPB QtVsyCHg4bBkFPmpD5EpzoAQd2m7v9UPLfBIqqIgqRjf3bNOo2GvjDjpDQfP+XhtayU8 vBmohJyubtq71BXfW6F6ZXcNh/SF5tJv8xYyefrOPVwA8IEK8pNFLS5jDD/fMC+TIz0n fWanOi8JzG+dvgoPTjDGgc9NGY9dYoj/nli2C47DVSl/e15TTflF8uV6yR5R11/ge2ii Wrzg== X-Gm-Message-State: ALoCoQmMJ2EYb/hu/ZU6o8WKaYM/ntEzt00xFJHn4VO+tPk4KFdHrmKfOD4SVvHppdG+ZbVB9U0F MIME-Version: 1.0 X-Received: by 10.112.163.72 with SMTP id yg8mr4870026lbb.82.1440770885864; Fri, 28 Aug 2015 07:08:05 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Fri, 28 Aug 2015 07:08:05 -0700 (PDT) In-Reply-To: References: <20150828.084127.247634384116908046.mbj@tail-f.com> Date: Fri, 28 Aug 2015 07:08:05 -0700 Message-ID: From: Andy Bierman To: "Acee Lindem (acee)" Content-Type: multipart/alternative; boundary=089e0118366cdae5d0051e5f9cb2 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] logical systems model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 14:08:10 -0000 --089e0118366cdae5d0051e5f9cb2 Content-Type: text/plain; charset=UTF-8 On Fri, Aug 28, 2015 at 4:19 AM, Acee Lindem (acee) wrote: > Martin, Andy, > > On 8/28/15, 2:41 AM, "netmod on behalf of Martin Bjorklund" > wrote: > > >Andy Bierman wrote: > >> Hi, > >> > >> I started a new subject line because the way logical vs. physical > >>systems > >> are managed is a separate issue from the others. > >> > >> +--rw device > >> +--rw logical-network-elements > >> +--rw logical-network-element* [network-element-id] > >> +--rw network-element-id uint8 > >> +--rw network-element-name? string > >> +--rw default-networking-instance-name? string > >> +--rw system-management > >> | +--rw device-view? boolean > >> | +--rw syslog > >> | +--rw dns > >> | +--rw ntp > >> | +--rw statistics-collection > >> | +--rw ssh > >> | +--rw tacacs > >> | +--rw snmp > >> | +--rw netconf > >> > >> > >> I do not know of any systems where the logical view > >> is managed with an array entry like in this proposal. > >> Usually the protocol (or CLI command) picks one logical context > >> and the PDU is for that one logical system. Each logical system > >> is self-contained so that the data models are written for > >> a single system. > >> > >> Putting the multiplexing in the data model > >> adds a lot of extra complexity and protocol overhead for > >> systems that do not have virtual servers. > > > >+1 > > > >I also believe that it is too limiting. Some systems might do it this > >way, but then there are others that have the concept of "virtual > >system" that works differently. For example, the virtual system might > >give you your very own sandbox not just for the data model but also > >for the underlying config data store. There are essentially separate > >instances of a NETCONF server running (or other protocol). > > Well, I guess you are recommending going down the same path as SNMP where > each vendor supported multiple virtual routers and instances differently. > IMO, this is undesirable. > > I did not say that. IMO NETCONF and RESTCONF could be extended to support identification of virtual servers. I would put the functionality in the protocol where it belongs. If it is the data model then it is inflexible and all virtualization (standard or not) is stuck with this design forever (e.g. uint8 == max 256 virtual server limit forever). Systems that do not have virtual servers should not be indexed as if they do. The localized cost is way too high, and as Martin pointed out, real systems do not work this way. Acee > Andy > > > > > > > > >> When it comes to converting this tree to CLI (since this > >> is a common practice) the "interfaces" command will become > >> "devices interfaces", "system" becomes "device system", etc. > >> I don't know of any CLIs that work this way. > >> > >> The "nacm enable false" command will become > >> > >> device logical-network-elements logical-network-element 1 \ > >> system-management netconf nacm enable false > > > >And this would be a weird place for NACM. Would there be another NACM > >for logical-network-element 2? They would share the same root, so are > >rules somehow merged? > > > >Ditto for the snmp container btw. > > > > > >/martin > > > >_______________________________________________ > >netmod mailing list > >netmod@ietf.org > >https://www.ietf.org/mailman/listinfo/netmod > > --089e0118366cdae5d0051e5f9cb2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Aug 28, 2015 at 4:19 AM, Acee Lindem (acee) &= lt;acee@cisco.com&g= t; wrote:
Martin, Andy,

On 8/28/15, 2:41 AM, "netmod on behalf of Martin Bjorklund"
<netmod-bou= nces@ietf.org on behalf of mbj@tail-f.com> wrote:

>Andy Bierman <andy@yumaworks.com> wrote:
>> Hi,
>>
>> I started a new subject line because the way logical vs. physical<= br> >>systems
>> are managed is a separate issue from the others.
>>
>>=C2=A0 =C2=A0 +--rw device
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw logical-network-elements
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw logical-network-element* [= network-element-id]
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw network-eleme= nt-id=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 uint8 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw network-eleme= nt-name?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0string
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw default-netwo= rking-instance-name?=C2=A0 =C2=A0string
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw system-manage= ment
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw devic= e-view?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0boolean
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw syslo= g
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw dns >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw ntp >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw stati= stics-collection
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw ssh >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw tacac= s
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw snmp<= br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw netco= nf
>>
>>
>> I do not know of any systems where the logical view
>> is managed with an array entry like in this proposal.
>> Usually the protocol (or CLI command) picks one logical context >> and the PDU is for that one logical system.=C2=A0 Each logical sys= tem
>> is self-contained so that the data models are written for
>> a single system.
>>
>> Putting the multiplexing in the data model
>> adds a lot of extra complexity and protocol overhead for
>> systems that do not have virtual servers.
>
>+1
>
>I also believe that it is too limiting.=C2=A0 Some systems might do it = this
>way, but then there are others that have the concept of "virtual >system" that works differently.=C2=A0 For example, the virtual sys= tem might
>give you your very own sandbox not just for the data model but also
>for the underlying config data store.=C2=A0 There are essentially separ= ate
>instances of a NETCONF server running (or other protocol).

Well, I guess you are recommending going down the same path as SNMP where each vendor supported multiple virtual routers and instances differently. IMO, this is undesirable.


I did not say that.
IMO NETC= ONF and RESTCONF could be extended to support identification
of v= irtual servers.=C2=A0 I would put the functionality in the protocol where i= t belongs.
If it is the data model then it is inflexible and all = virtualization (standard or not)
is stuck with this design foreve= r (e.g. uint8 =3D=3D max 256 virtual server limit forever).

<= /div>
Systems that do not have virtual servers should not be indexed as= if they do.
The localized cost is way too high, and as Martin po= inted out, real systems
do not work this way.



Acee


Andy
=C2= =A0



>
>
>> When it comes to converting this tree to CLI (since this
>> is a common practice) the "interfaces" command will beco= me
>> "devices interfaces", "system" becomes "d= evice system", etc.
>> I don't know of any CLIs that work this way.
>>
>> The "nacm enable false" command will become
>>
>> device logical-network-elements logical-network-element 1 \
>> system-management netconf nacm enable false
>
>And this would be a weird place for NACM.=C2=A0 Would there be another = NACM
>for logical-network-element 2?=C2=A0 They would share the same root, so= are
>rules somehow merged?
>
>Ditto for the snmp container btw.
>
>
>/martin
>
>_______________________________________________
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod


--089e0118366cdae5d0051e5f9cb2-- From nobody Fri Aug 28 08:14:07 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85B5E1A9234 for ; Fri, 28 Aug 2015 08:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.805 X-Spam-Level: X-Spam-Status: No, score=-0.805 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_SK=1.35, HOST_EQ_SK=0.555, RCVD_IN_DNSWL_LOW=-0.7, 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 C6Ib96yZMr04 for ; Fri, 28 Aug 2015 08:14:03 -0700 (PDT) Received: from mail.hq.sk (hq.sk [81.89.59.181]) by ietfa.amsl.com (Postfix) with ESMTP id 34A6C1ACDEC for ; Fri, 28 Aug 2015 08:13:49 -0700 (PDT) Received: from [10.0.2.15] (188-167-5-4.dynamic.chello.sk [188.167.5.4]) by mail.hq.sk (Postfix) with ESMTPSA id 6DE73240277; Fri, 28 Aug 2015 17:13:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1440774827; bh=xG43LWjzttuZbbx3gA/0hjDHots3aFpSZSfeGquosfg=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=icXSzMqkAJt0GDSMe8Res8xohNYWb3Qr7JNjRE7ArIM3P8qyvgfOQFxUB+HlAfQIs lSQYt54m7GYic1AdvZ6YzDIwxRgZmZ9v7yqbj7mxehsgO8pmDJj9LXcelX0VvdoiC5 kkxESr3E0A70fEyXi7Qv18Hoi7ols47l7ttpwwkk= To: Ladislav Lhotka References: <5497CE3E-19A7-4AAC-AE32-AFC9BC2451F1@nic.cz> <06C8EE42-B70D-40A7-8B16-053D37378043@nic.cz> <20150720210041.GA17614@elstar.local> <4D704311-D5B7-43F3-BD23-C13D5289CF46@nic.cz> <20150721074428.GC18607@elstar.local> <55DFC6CF.7060105@hq.sk> <6FA04E5F-F0FB-45F7-B17F-BDDA1C9C1D18@nic.cz> From: Robert Varga Message-ID: <55E07AAA.20704@hq.sk> Date: Fri, 28 Aug 2015 17:13:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <6FA04E5F-F0FB-45F7-B17F-BDDA1C9C1D18@nic.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Y34 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 15:14:05 -0000 On 08/28/2015 03:34 PM, Ladislav Lhotka wrote: > Hi Robert, >> On 28 Aug 2015, at 04:26, Robert Varga wrote: >> >> On 07/21/2015 09:44 AM, Juergen Schoenwaelder wrote: >>> Lada, you can't simply 'mount' a data model into a different place. >>> Think about paths in must or when expressions, or think about paths >>> contraints in leafrefs etc >> In ODL we already have a language extension which does this. Semantically it embeds the conceptual 'root' node into container/list item. That item becomes the logical root against which all expressions in the embedded models are evaluated against, e.g. it is its own little world, no constraints coming in or out of it. While incoming references could be done (by just crossing the embedding item), we have not found a use case for it yet. > Yes, I think this could work. Two questions: > > 1. Is it possible to graft the same module multiple times in different places, perhaps in different revisions and with different features? > > 2. Can you identify a *set* of modules that are chrooted this way? For example, can you say you want to have a common root for ietf-interfaces, ietf-ip and ietf-system, rather than putting each module in its separate little world? I would say the answer to both questions should be yes, otherwise it would not work well in a heterogeneous environment and/or presence of inter-module constraints. From implementation perspective, we do not declare these in the model itself -- it acts only as a marker for the client to understand that it talks to a 'sub-device' and should look for a chrooted RFC6020 /netconf-state subtree to see what is going on in a particular chroot instance. Bye, Robert From nobody Fri Aug 28 11:31:41 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A601E1A8940 for ; Fri, 28 Aug 2015 11:31:40 -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 Jh8zEtkFX5Lo for ; Fri, 28 Aug 2015 11:31:39 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CDC31A88D4 for ; Fri, 28 Aug 2015 11:31:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1544; q=dns/txt; s=iport; t=1440786700; x=1441996300; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=9yeiAeBGhO6XEJcofhEdv69FRdgvMnDV0Z9+afhn32M=; b=a33yrZAAunFJPv6FsGbm3+pK4lCwIDXIlhYPCYlKfFDUTf9VqDrO8nFi q3kqXs+Z1GKFNxhnKQySzcfnwMIAcBYN/PbbfYylVL4CjjMX+38K2JSzH uQf4aTY++qXIrEkxbn9tMFvmCdwWeVt46Lqivm/ozbJoHb9swMnKpp+F/ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BiBQDlqOBV/40NJK1egxuBPQbFdwKBPTsRAQEBAQEBAYEKhCMBAQEEOj8MBAIBCBEEAQELFAkHMhQJCAIEAQ0FCIgmxQABAQEBAQEBAQEBAQEBAQEBAQEBAQEXi2KEWjEHBoMSgRQBBJU/AadZJoIPHIFUcYFIgQUBAQE X-IronPort-AV: E=Sophos;i="5.17,426,1437436800"; d="scan'208";a="182894568" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-4.cisco.com with ESMTP; 28 Aug 2015 18:31:38 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t7SIVbvY017990 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 28 Aug 2015 18:31:37 GMT Received: from xch-aln-006.cisco.com (173.36.7.16) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 28 Aug 2015 13:31:36 -0500 Received: from xhc-aln-x03.cisco.com (173.36.12.77) by xch-aln-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Fri, 28 Aug 2015 13:31:36 -0500 Received: from xmb-rcd-x05.cisco.com ([169.254.15.111]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0248.002; Fri, 28 Aug 2015 13:31:36 -0500 From: "Alexander Clemm (alex)" To: Ladislav Lhotka , Martin Bjorklund , "andy@yumaworks.com" Thread-Topic: [netmod] logical systems model Thread-Index: AQHQ4RfyljQ2Se53ok+/QdN9QBRNSp4hSsKAgABQ4gCAAB7kEA== Date: Fri, 28 Aug 2015 18:31:36 +0000 Message-ID: References: <20150828.084127.247634384116908046.mbj@tail-f.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.48.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] logical systems model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 18:31:40 -0000 -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav Lhotka Sent: Friday, August 28, 2015 4:31 AM To: Martin Bjorklund ; andy@yumaworks.com Cc: netmod@ietf.org Subject: Re: [netmod] logical systems model ..... NACM, as well as all other modules we have, is based on the assumption of a= single managed device. I think it is a typical trend that what once was a single instance becomes = an array. If we did ietf-routing 20 years ago, there would probably be no r= outing-instance list. So I think it is a real problem that we can't migrate from a container to a= list and reuse the container's data model. Groupings might help somewhat b= ut they are still not fully reusable, if, for example, they contain absolut= e references. Lada One comment, if you forgive the pitch, but this problem / use case is by th= e way exactly one of the reasons for mounting, which allows you to introduc= e and impose an additional structure on top of an existing structure, and "= insert" the existing structure into it. Augmentations etc can only add bel= ow the hierarchy, there is no way we can put a new container or list or wha= tever on top of an existing structure (without replicating the existing str= ucture in a duplicate model), but peer-mount lets you do that. One use cas= e used in Open Daylight involves organizing/ inserting device-level informa= tion into a network inventory, which is basically imposed "on top". =20 From nobody Fri Aug 28 12:53:05 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B40901B29CA for ; Fri, 28 Aug 2015 12:53:04 -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 uyh3POpaoElX for ; Fri, 28 Aug 2015 12:53:03 -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 BD54A1B29AA for ; Fri, 28 Aug 2015 12:53:02 -0700 (PDT) Received: by lbbtg9 with SMTP id tg9so36051947lbb.1 for ; Fri, 28 Aug 2015 12:53:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=IfkVufmolkiK5VZmR0TUN066FOjnWonbDn2xr2tEmgE=; b=UrxgslzePriKEBzlFuo4myXIvFI0uF94vGM8NjrBfMYmB6tzmzWMGVI73YSMmed3U/ iKslsXk4zdvGGXc7wzCd196VgSnHCa7gejlRhtg6GaXLjPA2LC3rYJ1J2a/j9TkQP2F6 qahmuG3c02f2Ka/ny6xXm8aGOdFwbjKawBM4KUirsXiLqa+lb/NgWC/sBDPn2RXzppDA 0gx3yC274LaVLQiiomljX85x2jYgUK/ymh4j789oUUcxxqi2joRTpq6GGmox23aJLArf 5PKb/e3SBJIqhNFF4J5KuI2x1GMBK8CSu8SaKU55NLUH7fLaMy95mjuQq7+8QU8Pn11L OFWA== X-Gm-Message-State: ALoCoQk0elXJnlqojnmCR/PPApy8ve29dhlr8aGP3efOfQpO8Wc1CkMoRJo3uS0nuiA6e8W9wzzN MIME-Version: 1.0 X-Received: by 10.112.154.106 with SMTP id vn10mr5855077lbb.38.1440791581242; Fri, 28 Aug 2015 12:53:01 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Fri, 28 Aug 2015 12:53:01 -0700 (PDT) In-Reply-To: References: <20150828.084127.247634384116908046.mbj@tail-f.com> Date: Fri, 28 Aug 2015 12:53:01 -0700 Message-ID: From: Andy Bierman To: "Alexander Clemm (alex)" Content-Type: multipart/alternative; boundary=089e0122af2a655060051e646e26 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] logical systems model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 19:53:04 -0000 --089e0122af2a655060051e646e26 Content-Type: text/plain; charset=UTF-8 On Fri, Aug 28, 2015 at 11:31 AM, Alexander Clemm (alex) wrote: > > > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav Lhotka > Sent: Friday, August 28, 2015 4:31 AM > To: Martin Bjorklund ; andy@yumaworks.com > Cc: netmod@ietf.org > Subject: Re: [netmod] logical systems model > > > ..... > > > NACM, as well as all other modules we have, is based on the assumption of > a single managed device. > > I think it is a typical trend that what once was a single instance becomes > an array. If we did ietf-routing 20 years ago, there would probably be no > routing-instance list. > > So I think it is a real problem that we can't migrate from a container to > a list and reuse the container's data model. Groupings might help somewhat > but they are still not fully reusable, if, for example, they contain > absolute references. > > Lada > > > One comment, if you forgive the pitch, but this problem / use case is by > the way exactly one of the reasons for mounting, which allows you to > introduce and impose an additional structure on top of an existing > structure, and "insert" the existing structure into it. Augmentations etc > can only add below the hierarchy, there is no way we can put a new > container or list or whatever on top of an existing structure (without > replicating the existing structure in a duplicate model), but peer-mount > lets you do that. One use case used in Open Daylight involves organizing/ > inserting device-level information into a network inventory, which is > basically imposed "on top". > > I thing YANG Mount would be the best way to solve this problem. It provides a standard way to do "chroot" and it is flexible. The mechanics of a "datastore within a datastore" are the same and independent of the source of the data (local, remote, virtual, etc.) Andy --089e0122af2a655060051e646e26 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Aug 28, 2015 at 11:31 AM, Alexander Clemm (alex) <alex@cisco.com<= /a>> wrote:


-----Original Message-----
From: netmod [mailto:netmod-boun= ces@ietf.org] On Behalf Of Ladislav Lhotka
Sent: Friday, August 28, 2015 4:31 AM
To: Martin Bjorklund <mbj@tail-f.com>; andy@yumaworks.com
Cc: netmod@ietf.org
Subject: Re: [netmod] logical systems model


.....
<snip>

NACM, as well as all other modules we have, is based on the assumption of a= single managed device.

I think it is a typical trend that what once was a single instance becomes = an array. If we did ietf-routing 20 years ago, there would probably be no r= outing-instance list.

So I think it is a real problem that we can't migrate from a container = to a list and reuse the container's data model. Groupings might help so= mewhat but they are still not fully reusable, if, for example, they contain= absolute references.

Lada
</snip>

One comment, if you forgive the pitch, but this problem / use case is by th= e way exactly one of the reasons for mounting, which allows you to introduc= e and impose an additional structure on top of an existing structure, and &= quot;insert" the existing structure into it.=C2=A0 Augmentations etc c= an only add below the hierarchy, there is no way we can put a new container= or list or whatever on top of an existing structure (without replicating t= he existing structure in a duplicate model), but peer-mount lets you do tha= t.=C2=A0 One use case used in Open Daylight involves organizing/ inserting = device-level information into a network inventory, which is basically impos= ed "on top".



I thing YANG Mount woul= d be the best way to solve this problem.
It provides a standard w= ay to do "chroot" and it is flexible.
The mechanics of = a "datastore within a datastore" are the
same and indep= endent of the source of the data (local,
remote, virtual, etc.)


Andy


<= /div>
--089e0122af2a655060051e646e26-- From nobody Fri Aug 28 13:32:05 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16C0A1A1B6A for ; Fri, 28 Aug 2015 13:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, 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 SLNvA8d65HFp for ; Fri, 28 Aug 2015 13:32:02 -0700 (PDT) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id D5EE61B2D8E for ; Fri, 28 Aug 2015 13:32:01 -0700 (PDT) Received: (qmail 32557 invoked by uid 0); 28 Aug 2015 20:31:56 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy10.mail.unifiedlayer.com with SMTP; 28 Aug 2015 20:31:56 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id ALXr1r00s2SSUrH01LXufo; Fri, 28 Aug 2015 14:31:56 -0600 X-Authority-Analysis: v=2.1 cv=EbVbHpWC c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=wU2YTnxGAAAA:8 a=-NfooI8aBGcA:10 a=lszNwCOoVosA:10 a=uRRa74qj2VoA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=xskcdSivAAAA:8 a=AUd_NHdVAAAA:8 a=48vgC7mUAAAA:8 a=u07AKapRAAAA:8 a=8N9tghAndxCBdgAawrgA:9 a=CjuIK1q_8ugA:10 a=ZVKFNPBGD1VGozufUuUA:9 a=d7uo_otWGKXmCVjo:21 a=_W_S_7VecoQA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:CC:To:From; bh=jYlUH3wEgUd0Z1N+sSpC8qAy5tHBCg1z4Fvs3+NxKBQ=; b=QlTI9FNoPrkyLJDhRJvuySCeYCQBGP9/XE5htkPTSOr+IK0Kq+N2j43qIVpgVG22IXpfrF7B18bCq86LNUd+3kMyqIZd4fMn9TVTdiyk8M+JjO85QvZOJo6SyBuIeg5k; Received: from [172.56.3.228] (port=57396 helo=[192.0.0.4]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1ZVQJU-0005uj-5t; Fri, 28 Aug 2015 14:31:52 -0600 From: Lou Berger To: Andy Bierman , "Alexander Clemm (alex)" Date: Fri, 28 Aug 2015 16:31:49 -0400 Message-ID: <14f76023f98.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: References: <20150828.084127.247634384116908046.mbj@tail-f.com> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.5.9.9 (build: 22000010) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------14f76025a3e1718281843817a10" X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 172.56.3.228 authed with lberger@labn.net} Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] logical systems model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 20:32:04 -0000 This is a multi-part message in MIME format. ------------14f76025a3e1718281843817a10 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 8bit On August 28, 2015 3:53:33 PM Andy Bierman wrote: > On Fri, Aug 28, 2015 at 11:31 AM, Alexander Clemm (alex) > wrote: > >> >> >> -----Original Message----- >> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav Lhotka >> Sent: Friday, August 28, 2015 4:31 AM >> To: Martin Bjorklund ; andy@yumaworks.com >> Cc: netmod@ietf.org >> Subject: Re: [netmod] logical systems model >> >> >> ..... >> >> >> NACM, as well as all other modules we have, is based on the assumption of >> a single managed device. >> >> I think it is a typical trend that what once was a single instance becomes >> an array. If we did ietf-routing 20 years ago, there would probably be no >> routing-instance list. >> >> So I think it is a real problem that we can't migrate from a container to >> a list and reuse the container's data model. Groupings might help somewhat >> but they are still not fully reusable, if, for example, they contain >> absolute references. >> >> Lada >> >> >> One comment, if you forgive the pitch, but this problem / use case is by >> the way exactly one of the reasons for mounting, which allows you to >> introduce and impose an additional structure on top of an existing >> structure, and "insert" the existing structure into it. Augmentations etc >> can only add below the hierarchy, there is no way we can put a new >> container or list or whatever on top of an existing structure (without >> replicating the existing structure in a duplicate model), but peer-mount >> lets you do that. One use case used in Open Daylight involves organizing/ >> inserting device-level information into a network inventory, which is >> basically imposed "on top". >> >> > > I thing YANG Mount would be the best way to solve this problem. > It provides a standard way to do "chroot" and it is flexible. > The mechanics of a "datastore within a datastore" are the > same and independent of the source of the data (local, > remote, virtual, etc.) > So I think an example of how you see this working would helpful. Can one of you give an example of how this word work for a device (which may be physical or virtual) that allocates done resources, say interfaces to one logical entity (router, system, etc) and other resources to a second entity? And of course I want to manage all with yang and the first and second (sub) entity must be completely independent and ignorant of each other. Thanks, Lou > > Andy > > > > ---------- > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > ------------14f76025a3e1718281843817a10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit

On August 28, 2015 3:53:33 PM Andy Bierman <andy@yumaworks.com> wrote:

> On Fri, Aug 28, 2015 at 11:31 AM, Alexander Clemm (alex) <alex@cisco.com>
> wrote:
>
>>
>>
>> -----Original Message-----
>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav Lhotka
>> Sent: Friday, August 28, 2015 4:31 AM
>> To: Martin Bjorklund <mbj@tail-f.com>; andy@yumaworks.com
>> Cc: netmod@ietf.org
>> Subject: Re: [netmod] logical systems model
>>
>>
>> .....
>> <snip>
>>
>> NACM, as well as all other modules we have, is based on the assumption of
>> a single managed device.
>>
>> I think it is a typical trend that what once was a single instance becomes
>> an array. If we did ietf-routing 20 years ago, there would probably be no
>> routing-instance list.
>>
>> So I think it is a real problem that we can't migrate from a container to
>> a list and reuse the container's data model. Groupings might help somewhat
>> but they are still not fully reusable, if, for example, they contain
>> absolute references.
>>
>> Lada
>> </snip>
>>
>> One comment, if you forgive the pitch, but this problem / use case is by
>> the way exactly one of the reasons for mounting, which allows you to
>> introduce and impose an additional structure on top of an existing
>> structure, and "insert" the existing structure into it.  Augmentations etc
>> can only add below the hierarchy, there is no way we can put a new
>> container or list or whatever on top of an existing structure (without
>> replicating the existing structure in a duplicate model), but peer-mount
>> lets you do that.  One use case used in Open Daylight involves organizing/
>> inserting device-level information into a network inventory, which is
>> basically imposed "on top".
>>
>>
>
> I thing YANG Mount would be the best way to solve this problem.
> It provides a standard way to do "chroot" and it is flexible.
> The mechanics of a "datastore within a datastore" are the
> same and independent of the source of the data (local,
> remote, virtual, etc.)
>

So I think an example of how you see this working would helpful. 

Can one of you give an example of how this word work for a device (which may be physical or virtual) that allocates done resources, say interfaces to one logical entity (router, system, etc) and other resources to a second entity? And of course I want to manage all with yang and the first and second (sub) entity must be completely independent and ignorant of each other.

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

------------14f76025a3e1718281843817a10-- From nobody Fri Aug 28 14:33:20 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 020401A88D3 for ; Fri, 28 Aug 2015 14:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSL46rDOLGFG for ; Fri, 28 Aug 2015 14:33:16 -0700 (PDT) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB4201A8760 for ; Fri, 28 Aug 2015 14:33:15 -0700 (PDT) Received: by laba3 with SMTP id a3so40195560lab.1 for ; Fri, 28 Aug 2015 14:33: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=F0gtiXKQ1nSEWnR7MIIS8oWjC1aQe+EkcUeU89s3aHE=; b=iMNb+YBS3kAZ7VqD9DomWeaB0eL8JF/t2aKRpsBj8XVfZKvz+4X5OQscC0Cetb1ooV zM8EsUuJpl2J82U6oHPUV2oajAn5An/Acr5lXuow+ByMxjLYU0i70I+suwkIEkYsE95c Pxs60yLz9nDzEMd8nHAcp/7rXAybvRZQzlploEJjJdTehgITLFhUzH04N5OUFAZUclxx dIO2ssnUPlbYIKXcsgvNMfqDKVZVwUG9dr1v2sxROOb7fsyn33lC+ebo3HWhp8BQfRTt ClRdwQkqo3rmk3prDXAOUC72lXMuCRp2cBoKRcNwfP7h2ci/6dcvsfpTBdgK4pNFddEK oB/g== X-Gm-Message-State: ALoCoQk/wOw4Ebf2MfVbQ+m20CfGG2o0NVYHUE1WDEern+EZVhww+z4Y77cb9CgfXYkQtFJ5OhzR MIME-Version: 1.0 X-Received: by 10.112.85.3 with SMTP id d3mr5654245lbz.33.1440797594176; Fri, 28 Aug 2015 14:33:14 -0700 (PDT) Received: by 10.112.200.104 with HTTP; Fri, 28 Aug 2015 14:33:14 -0700 (PDT) In-Reply-To: <14f76023f98.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> References: <20150828.084127.247634384116908046.mbj@tail-f.com> <14f76023f98.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> Date: Fri, 28 Aug 2015 14:33:14 -0700 Message-ID: From: Andy Bierman To: Lou Berger Content-Type: multipart/alternative; boundary=001a1134946ccb6c52051e65d467 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] logical systems model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 21:33:19 -0000 --001a1134946ccb6c52051e65d467 Content-Type: text/plain; charset=UTF-8 On Fri, Aug 28, 2015 at 1:31 PM, Lou Berger wrote: > On August 28, 2015 3:53:33 PM Andy Bierman wrote: > > > On Fri, Aug 28, 2015 at 11:31 AM, Alexander Clemm (alex) > > > wrote: > > > >> > >> > >> -----Original Message----- > >> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav > Lhotka > >> Sent: Friday, August 28, 2015 4:31 AM > >> To: Martin Bjorklund ; andy@yumaworks.com > >> Cc: netmod@ietf.org > >> Subject: Re: [netmod] logical systems model > >> > >> > >> ..... > >> > >> > >> NACM, as well as all other modules we have, is based on the assumption > of > >> a single managed device. > >> > >> I think it is a typical trend that what once was a single instance > becomes > >> an array. If we did ietf-routing 20 years ago, there would probably be > no > >> routing-instance list. > >> > >> So I think it is a real problem that we can't migrate from a container > to > >> a list and reuse the container's data model. Groupings might help > somewhat > >> but they are still not fully reusable, if, for example, they contain > >> absolute references. > >> > >> Lada > >> > >> > >> One comment, if you forgive the pitch, but this problem / use case is by > >> the way exactly one of the reasons for mounting, which allows you to > >> introduce and impose an additional structure on top of an existing > >> structure, and "insert" the existing structure into it. Augmentations > etc > >> can only add below the hierarchy, there is no way we can put a new > >> container or list or whatever on top of an existing structure (without > >> replicating the existing structure in a duplicate model), but peer-mount > >> lets you do that. One use case used in Open Daylight involves > organizing/ > >> inserting device-level information into a network inventory, which is > >> basically imposed "on top". > >> > >> > > > > I thing YANG Mount would be the best way to solve this problem. > > It provides a standard way to do "chroot" and it is flexible. > > The mechanics of a "datastore within a datastore" are the > > same and independent of the source of the data (local, > > remote, virtual, etc.) > > > > So I think an example of how you see this working would helpful. > > Can one of you give an example of how this word work for a device (which > may be physical or virtual) that allocates done resources, say interfaces > to one logical entity (router, system, etc) and other resources to a second > entity? And of course I want to manage all with yang and the first and > second (sub) entity must be completely independent and ignorant of each > other. > Is there an example of this in your draft? Do you mean an example of what the controller looks like? Maybe the analogy to chroot is not universally understood. The logical system knows only about itself: /interfaces /system The / node is represented by or or in the protocol. Each logical system can have its own "eth0" interface or whatever. They are mapped to real interfaces in the physical system. All operations on the logical system are validated against its own virtual datastore. YANG validation does not work on individual array slices -- it only applies to an entire datastore. On the physical server there needs to be a data model to manage the logical servers (as Martin suggested). <--- root on PHY server <--------------- contains the real interfaces, including eth23 vs1 eth23 eth0 <----------- YANG mount point (virtual server root) eth0 ... On the physical system, the virtual roots are within list entries, not at the top of the tree. The physical server data and/or any of the logical servers can be accessed at once. There is no extra indexing cost. The same data model (e.g ietf-interfaces) can be used in physical and virtual server. YANG Mount provides a lot more than simply identifying /virtual-servers/virtual-server/root as the start of an embedded datastore. As Alex said, not all of it needs to be standardized at once. Th "virtual-servers" node is not under each because only the physical server loads and supports that module. Thanks, > Lou > > > Andy > > Andy > > > > > > > > ---------- > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > --001a1134946ccb6c52051e65d467 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Aug 28, 2015 at 1:31 PM, Lou Berger <lberger@labn.net> wrote:

On August 28, 2015 3:53:33 PM Andy Bierman <an= dy@yumaworks.com> wrote:

> On Fri, Aug 28, 2015 at 11:31 AM, Alexander Clemm (alex) <alex@cisco.com>
> wrote:
>
>>
>>
>> -----Original Message-----
>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav Lhotka
>> Sent: Friday, August 28, 2015 4:31 AM
>> To: Martin Bjorklund <mbj@tail-f.com>; andy@yumaworks.com
>> Cc: netmod@ie= tf.org
>> Subject: Re: [netmod] logical systems model
>>
>>
>> .....
>> <snip>
>>
>> NACM, as well as all other modules we have, is based on the assumption of
>> a single managed device.
>>
>> I think it is a typical trend that what once was a single instance becomes
>> an array. If we did ietf-routing 20 years ago, there would probably be no
>> routing-instance list.
>>
>> So I think it is a real problem that we can't migrate from a container to
>> a list and reuse the container's data model. Groupings might h= elp somewhat
>> but they are still not fully reusable, if, for example, they contain
>> absolute references.
>>
>> Lada
>> </snip>
>>
>> One comment, if you forgive the pitch, but this problem / use case is by
>> the way exactly one of the reasons for mounting, which allows you to
>> introduce and impose an additional structure on top of an existing=
>> structure, and "insert" the existing structure into it.= =C2=A0 Augmentations etc
>> can only add below the hierarchy, there is no way we can put a new=
>> container or list or whatever on top of an existing structure (without
>> replicating the existing structure in a duplicate model), but peer-mount
>> lets you do that.=C2=A0 One use case used in Open Daylight involves organizing/
>> inserting device-level information into a network inventory, which is
>> basically imposed "on top".
>>
>>
>
> I thing YANG Mount would be the best way to solve this problem.
> It provides a standard way to do "chroot" and it is flexible= .
> The mechanics of a "datastore within a datastore" are the > same and independent of the source of the data (local,
> remote, virtual, etc.)
>

So I think an example of how you see this working would helpful.=C2=A0

Can one of you give an example of how this word work for a device (which may be physical or virtual) that allocates done resources, say interfaces to one logical entity (router, system, etc) and other resources to a second entity? And of course I want to manage all with yang and the first and second (sub) entity must be completely independent and ignorant of each other.


Is there an example of this in your draft?

Do you mean an example of what the controller looks like?<= /div>
Maybe the analogy to chroot is not =C2=A0universally understood.<= br>

The logical system knows only about itself:

=C2=A0 =C2=A0 /interfaces
=C2=A0 =C2=A0 /s= ystem

The / node is represented by <config> = or <data> or <filter> in the protocol.

=C2=A0 =C2=A0<get-config>
=C2=A0 =C2=A0 =C2=A0 =C2=A0<s= ource><running/></source>
=C2=A0 =C2=A0 =C2=A0 =C2= =A0<filter>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<interface= s />
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<system />
<= div>=C2=A0 =C2=A0 =C2=A0 </filter>
=C2=A0 =C2=A0</getcon= fig>

Each logical system can have its own "= ;eth0" interface or whatever.
They are mapped to real interf= aces in the physical system.

All operations on the= logical system are validated against its own
virtual datastore.= =C2=A0 YANG validation does not work on individual array
slices -= - it only applies to an entire datastore.

On the p= hysical server there needs to be a data model to manage the
logic= al servers (as Martin suggested).

=C2=A0<config= > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <--- root on PHY server
=C2=A0 =C2=A0<interfaces =C2=A0/> =C2=A0 <---------------= contains the real interfaces, including eth23
=C2=A0 =C2=A0<v= irtual-servers>
=C2=A0 =C2=A0 =C2=A0 <virtual-server>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>vs1</name>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<itf-map>
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<real-itf>eth23</real-itf= >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<vir-itf&= gt;eth0</vir-itf>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<itf= -map>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<more-virtual-serve= r-params ... />
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<root>= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <-------= ---- YANG mount point (virtual server root)
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 <interfaces>
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<interface>
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <name>eth0</name&= gt;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 ...
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0</interface>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 </interfaces>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= <system ... />
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</root= >
=C2=A0 =C2=A0 =C2=A0 =C2=A0</virtual-server>
=C2=A0 =C2=A0 </virtual-servers>
=C2=A0 </config>

On the physical system, the virtual roots are within= list entries,
not at the top of the tree.=C2=A0 The physical ser= ver data and/or any
of the logical servers can be accessed at onc= e.

There is no extra indexing cost.=C2=A0 The same= data model (e.g ietf-interfaces)
can be used in physical and vir= tual server.=C2=A0 YANG Mount provides a lot
more than simply ide= ntifying /virtual-servers/virtual-server/root
as the start of an = embedded datastore.=C2=A0 As Alex said, not all of it
needs to be= standardized at once.

Th "virtual-servers&qu= ot; node is not under each <root> because only
the physical= server loads and supports that module.
=C2=A0 =C2=A0 =C2=A0 =C2= =A0=C2=A0


Thanks,
Lou
>



And= y
=C2=A0

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


--001a1134946ccb6c52051e65d467-- From nobody Fri Aug 28 15:16:52 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2DB1B3507 for ; Fri, 28 Aug 2015 15:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eoy1jkrPMhHQ for ; Fri, 28 Aug 2015 15:16:48 -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 AFB831B34F2 for ; Fri, 28 Aug 2015 15:16:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=41008; q=dns/txt; s=iport; t=1440800207; x=1442009807; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=LTQfSySALIHiO/3xRXEr8qEE0hNtZKbKxRQoIHX0GmE=; b=TPDDW8YJb7UY9bqQP616IxQcn4YRcACiaxOBoX6KDUskhIudOUXRvYM8 9ebv8O3XekYNVl84zZ6ODXTvci+TLhPMr9lFMfZ/Mug22NBvdUm1EMANq Gcn6mREAreOEF42rPjAtbojAE3yPR0oIzeflNthlYyJxoxahyJZX7k4S4 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AzBQAu3eBV/4sNJK1dgk5NVGkGgx26aoFVGQEJhTFKAhyBIToSAQEBAQEBAYEKhCMBAQEDAQEBASAKQQsFBwQCAQgRBAEBAQoWAQYDAgICJQsUCQgCBAENBQiIHggNsDyUYwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEi2KEQBoWFwQGAQaCYy+BFAWHKoVEiFEBjjyVMYNsJoIPHIFUcYEHJRyBBQEBAQ X-IronPort-AV: E=Sophos;i="5.17,427,1437436800"; d="scan'208,217";a="183208024" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Aug 2015 22:16:46 +0000 Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t7SMGkq7008485 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 28 Aug 2015 22:16:46 GMT Received: from xch-rcd-016.cisco.com (173.37.102.26) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 28 Aug 2015 17:16:45 -0500 Received: from xhc-rcd-x03.cisco.com (173.37.183.77) by xch-rcd-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Fri, 28 Aug 2015 17:16:45 -0500 Received: from xmb-rcd-x05.cisco.com ([169.254.15.111]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0248.002; Fri, 28 Aug 2015 17:16:45 -0500 From: "Alexander Clemm (alex)" To: Andy Bierman , Lou Berger Thread-Topic: [netmod] logical systems model Thread-Index: AQHQ4RfyljQ2Se53ok+/QdN9QBRNSp4hSsKAgABQ4gCAAB7kEIAAbWOAgAAK2ICAABEoAP//rPpw Date: Fri, 28 Aug 2015 22:16:45 +0000 Message-ID: References: <20150828.084127.247634384116908046.mbj@tail-f.com> <14f76023f98.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> 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.210] Content-Type: multipart/alternative; boundary="_000_DBC595ED2346914F9F81D17DD5C32B571DC8F1B5xmbrcdx05ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] logical systems model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 22:16:51 -0000 --_000_DBC595ED2346914F9F81D17DD5C32B571DC8F1B5xmbrcdx05ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTG91LA0KDQpBbmR5IGJhc2ljYWxseSBhbHJlYWR5IHByb3ZpZGVkIHRoZSBhbnN3ZXIsIGJ1 dCBqdXN0IHRvIGFkZCB0byB5b3VyIHF1ZXN0aW9uOiB5ZXMsIHRoZXJlIGlzIGFuIGV4YW1wbGUg aW4gdGhlIGRyYWZ0IChhcHBlbmRpeCBBKS4NCg0KUkZDIDcyMjMgcHJvdmlkZXMgYSBZQU5HIG1v ZGVsIGZvciBpbnRlcmZhY2VzLiAgSXQgZGVmaW5lcyBhIGhpZXJhcmNoeSB0aGF0IGluY2x1ZGVz IHRoZSBmb2xsb3dpbmc6DQogICAgICArLS1ybyBpbnRlcmZhY2VzLXN0YXRlDQogICAgICAgICAr LS1ybyBpbnRlcmZhY2UqIFtuYW1lXQ0KICAgICAgICAgICAgKy0tcm8gbmFtZSAgICAgICAgICAg ICAgIHN0cmluZw0KICAgICAgICAgICAgKy0tcm8gdHlwZSAgICAgICAgICAgICAgIGlkZW50aXR5 cmVmDQogICAgICAgICAgICArLS1ybyBhZG1pbi1zdGF0dXMgICAgICAgZW51bWVyYXRpb24NCiAg ICAgICAgICAgICstLXJvIG9wZXItc3RhdHVzICAgICAgICBlbnVtZXJhdGlvbg0KICAgICAgICAg ICAgKy0tcm8gbGFzdC1jaGFuZ2U/ICAgICAgIHlhbmc6ZGF0ZS1hbmQtdGltZQ0KDQpUaGUgZXhh bXBsZSByZWZlcnMgdG8gYSBjb250cm9sbGVyIChlLmcuIE9ETCkgYW5kIHRoZSBtb2RlbCB0aGF0 IGl0IGV4cG9zZXMgdG8gaXRzIGFwcGxpY2F0aW9ucy4gIChUaGlzIGlzIGFsc28gd2hhdCBSb2Jl cnQgd2FzIHJlZmVycmluZyB0byBlYXJsaWVyLikgIFRoaXMgbW9kZWwgaXMgc3VwcG9zZWQgdG8g aW5jbHVkZSBhIG5ldHdvcmsgaW52ZW50b3J5LCB3aGljaCBpbmNsdWRlcyBhIGxpc3Qgb2YgdGhl IHZhcmlvdXMgZGV2aWNlcy9zeXN0ZW1zL25vZGVzIGNvbnRyb2xsZWQgYnkgdGhlIGNvbnRyb2xs ZXIsIGFuZCBzaGFsbCBpbmNsdWRlIGZvciBlYWNoIG9mIHRob3NlIGRldmljZXMgaW5mb3JtYXRp b24gcmVnYXJkaW5nIGl0cyBpbnRlcmZhY2VzLiAgSW4gb3RoZXIgd29yZHMsIHRoZSBjb250cm9s bGVyIHdhbnRzIHRvIGltcG9zZSBhbiBhZGRpdGlvbmFsIGxldmVsIChvciB0d28pIG9uIHRvcCBv ZiB0aGUgaGllcmFyY2h5IG9mIHRoZSBpbmRpdmlkdWFsIGRldmljZXMsIG5hbWVseSBzb21ldGhp bmcgb2YgdGhlIHNvcnQNCg0KICAgKy0tIHJ3IG5ldHdvcmstZWxlbWVudHMNCg0KICAgICAgICst LSBydyBuZXR3b3JrLWVsZW1lbnQgW2VsZW1lbnQtaWRdDQoNCkFuZCB0aGVuIGhhdmUgdmlzaWJp bGl0eSBvZiB0aGUgaW50ZXJmYWNlcyBiZWxvdyB0aGUgbmV0d29yayBkZXZpY2VzLg0KDQpJbiB0 aGlzIGNhc2UsIHlvdSBjb3VsZCBkZWZpbmUgcHV0IGFuIOKAnGludGVyZmFjZS1zdGF0c+KAnSBt b3VudHBvaW50IGJlbG93IG5ldHdvcmsgZWxlbWVudCwgYW5kIHBvaW50IGl0IHRvIGludGVyZmFj ZXMtc3RhdGUsIHRvIHJlc3VsdCBpbiB0aGUgZm9sbG93aW5nDQoNCiAgICstLSBydyBuZXR3b3Jr LWVsZW1lbnRzDQoNCiAgICAgICArLS0gcncgbmV0d29yay1lbGVtZW50IFtlbGVtZW50LWlkXQ0K ICAgICAgICAgICstLU0gaW50ZXJmYWNlcy1zdGF0ZQ0KICAgICAgICAgICAgICArLS1ybyBpbnRl cmZhY2UqIFtuYW1lXQ0KICAgICAgICAgICAgICAgICArLS1ybyBuYW1lICAgICAgICAgICAgICAg c3RyaW5nDQogICAgICAgICAgICAgICAgICstLXJvIHR5cGUgICAgICAgICAgICAgICBpZGVudGl0 eXJlZg0KICAgICAgICAgICAgICAgICArLS1ybyBhZG1pbi1zdGF0dXMgICAgICAgZW51bWVyYXRp b24NCiAgICAgICAgICAgICAgICAgKy0tcm8gb3Blci1zdGF0dXMgICAgICAgIGVudW1lcmF0aW9u DQogICAgICAgICAgICAgICAgICstLXJvIGxhc3QtY2hhbmdlPyAgICAgICB5YW5nOmRhdGUtYW5k LXRpbWUNCg0KLS0tIEFsZXgNCg0KRnJvbTogQW5keSBCaWVybWFuIFttYWlsdG86YW5keUB5dW1h d29ya3MuY29tXQ0KU2VudDogRnJpZGF5LCBBdWd1c3QgMjgsIDIwMTUgMjozMyBQTQ0KVG86IExv dSBCZXJnZXIgPGxiZXJnZXJAbGFibi5uZXQ+DQpDYzogQWxleGFuZGVyIENsZW1tIChhbGV4KSA8 YWxleEBjaXNjby5jb20+OyBuZXRtb2RAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbmV0bW9kXSBs b2dpY2FsIHN5c3RlbXMgbW9kZWwNCg0KDQoNCk9uIEZyaSwgQXVnIDI4LCAyMDE1IGF0IDE6MzEg UE0sIExvdSBCZXJnZXIgPGxiZXJnZXJAbGFibi5uZXQ8bWFpbHRvOmxiZXJnZXJAbGFibi5uZXQ+ PiB3cm90ZToNCg0KT24gQXVndXN0IDI4LCAyMDE1IDM6NTM6MzMgUE0gQW5keSBCaWVybWFuIDxh bmR5QHl1bWF3b3Jrcy5jb208bWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbT4+IHdyb3RlOg0KDQo+ IE9uIEZyaSwgQXVnIDI4LCAyMDE1IGF0IDExOjMxIEFNLCBBbGV4YW5kZXIgQ2xlbW0gKGFsZXgp IDxhbGV4QGNpc2NvLmNvbTxtYWlsdG86YWxleEBjaXNjby5jb20+Pg0KPiB3cm90ZToNCj4NCj4+ DQo+Pg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IG5ldG1vZCBbbWFp bHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9y Zz5dIE9uIEJlaGFsZiBPZiBMYWRpc2xhdiBMaG90a2ENCj4+IFNlbnQ6IEZyaWRheSwgQXVndXN0 IDI4LCAyMDE1IDQ6MzEgQU0NCj4+IFRvOiBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNv bTxtYWlsdG86bWJqQHRhaWwtZi5jb20+PjsgYW5keUB5dW1hd29ya3MuY29tPG1haWx0bzphbmR5 QHl1bWF3b3Jrcy5jb20+DQo+PiBDYzogbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0 Zi5vcmc+DQo+PiBTdWJqZWN0OiBSZTogW25ldG1vZF0gbG9naWNhbCBzeXN0ZW1zIG1vZGVsDQo+ Pg0KPj4NCj4+IC4uLi4uDQo+PiA8c25pcD4NCj4+DQo+PiBOQUNNLCBhcyB3ZWxsIGFzIGFsbCBv dGhlciBtb2R1bGVzIHdlIGhhdmUsIGlzIGJhc2VkIG9uIHRoZSBhc3N1bXB0aW9uIG9mDQo+PiBh IHNpbmdsZSBtYW5hZ2VkIGRldmljZS4NCj4+DQo+PiBJIHRoaW5rIGl0IGlzIGEgdHlwaWNhbCB0 cmVuZCB0aGF0IHdoYXQgb25jZSB3YXMgYSBzaW5nbGUgaW5zdGFuY2UgYmVjb21lcw0KPj4gYW4g YXJyYXkuIElmIHdlIGRpZCBpZXRmLXJvdXRpbmcgMjAgeWVhcnMgYWdvLCB0aGVyZSB3b3VsZCBw cm9iYWJseSBiZSBubw0KPj4gcm91dGluZy1pbnN0YW5jZSBsaXN0Lg0KPj4NCj4+IFNvIEkgdGhp bmsgaXQgaXMgYSByZWFsIHByb2JsZW0gdGhhdCB3ZSBjYW4ndCBtaWdyYXRlIGZyb20gYSBjb250 YWluZXIgdG8NCj4+IGEgbGlzdCBhbmQgcmV1c2UgdGhlIGNvbnRhaW5lcidzIGRhdGEgbW9kZWwu IEdyb3VwaW5ncyBtaWdodCBoZWxwIHNvbWV3aGF0DQo+PiBidXQgdGhleSBhcmUgc3RpbGwgbm90 IGZ1bGx5IHJldXNhYmxlLCBpZiwgZm9yIGV4YW1wbGUsIHRoZXkgY29udGFpbg0KPj4gYWJzb2x1 dGUgcmVmZXJlbmNlcy4NCj4+DQo+PiBMYWRhDQo+PiA8L3NuaXA+DQo+Pg0KPj4gT25lIGNvbW1l bnQsIGlmIHlvdSBmb3JnaXZlIHRoZSBwaXRjaCwgYnV0IHRoaXMgcHJvYmxlbSAvIHVzZSBjYXNl IGlzIGJ5DQo+PiB0aGUgd2F5IGV4YWN0bHkgb25lIG9mIHRoZSByZWFzb25zIGZvciBtb3VudGlu Zywgd2hpY2ggYWxsb3dzIHlvdSB0bw0KPj4gaW50cm9kdWNlIGFuZCBpbXBvc2UgYW4gYWRkaXRp b25hbCBzdHJ1Y3R1cmUgb24gdG9wIG9mIGFuIGV4aXN0aW5nDQo+PiBzdHJ1Y3R1cmUsIGFuZCAi aW5zZXJ0IiB0aGUgZXhpc3Rpbmcgc3RydWN0dXJlIGludG8gaXQuICBBdWdtZW50YXRpb25zIGV0 Yw0KPj4gY2FuIG9ubHkgYWRkIGJlbG93IHRoZSBoaWVyYXJjaHksIHRoZXJlIGlzIG5vIHdheSB3 ZSBjYW4gcHV0IGEgbmV3DQo+PiBjb250YWluZXIgb3IgbGlzdCBvciB3aGF0ZXZlciBvbiB0b3Ag b2YgYW4gZXhpc3Rpbmcgc3RydWN0dXJlICh3aXRob3V0DQo+PiByZXBsaWNhdGluZyB0aGUgZXhp c3Rpbmcgc3RydWN0dXJlIGluIGEgZHVwbGljYXRlIG1vZGVsKSwgYnV0IHBlZXItbW91bnQNCj4+ IGxldHMgeW91IGRvIHRoYXQuICBPbmUgdXNlIGNhc2UgdXNlZCBpbiBPcGVuIERheWxpZ2h0IGlu dm9sdmVzIG9yZ2FuaXppbmcvDQo+PiBpbnNlcnRpbmcgZGV2aWNlLWxldmVsIGluZm9ybWF0aW9u IGludG8gYSBuZXR3b3JrIGludmVudG9yeSwgd2hpY2ggaXMNCj4+IGJhc2ljYWxseSBpbXBvc2Vk ICJvbiB0b3AiLg0KPj4NCj4+DQo+DQo+IEkgdGhpbmcgWUFORyBNb3VudCB3b3VsZCBiZSB0aGUg YmVzdCB3YXkgdG8gc29sdmUgdGhpcyBwcm9ibGVtLg0KPiBJdCBwcm92aWRlcyBhIHN0YW5kYXJk IHdheSB0byBkbyAiY2hyb290IiBhbmQgaXQgaXMgZmxleGlibGUuDQo+IFRoZSBtZWNoYW5pY3Mg b2YgYSAiZGF0YXN0b3JlIHdpdGhpbiBhIGRhdGFzdG9yZSIgYXJlIHRoZQ0KPiBzYW1lIGFuZCBp bmRlcGVuZGVudCBvZiB0aGUgc291cmNlIG9mIHRoZSBkYXRhIChsb2NhbCwNCj4gcmVtb3RlLCB2 aXJ0dWFsLCBldGMuKQ0KPg0KDQpTbyBJIHRoaW5rIGFuIGV4YW1wbGUgb2YgaG93IHlvdSBzZWUg dGhpcyB3b3JraW5nIHdvdWxkIGhlbHBmdWwuDQoNCkNhbiBvbmUgb2YgeW91IGdpdmUgYW4gZXhh bXBsZSBvZiBob3cgdGhpcyB3b3JkIHdvcmsgZm9yIGEgZGV2aWNlICh3aGljaCBtYXkgYmUgcGh5 c2ljYWwgb3IgdmlydHVhbCkgdGhhdCBhbGxvY2F0ZXMgZG9uZSByZXNvdXJjZXMsIHNheSBpbnRl cmZhY2VzIHRvIG9uZSBsb2dpY2FsIGVudGl0eSAocm91dGVyLCBzeXN0ZW0sIGV0YykgYW5kIG90 aGVyIHJlc291cmNlcyB0byBhIHNlY29uZCBlbnRpdHk/IEFuZCBvZiBjb3Vyc2UgSSB3YW50IHRv IG1hbmFnZSBhbGwgd2l0aCB5YW5nIGFuZCB0aGUgZmlyc3QgYW5kIHNlY29uZCAoc3ViKSBlbnRp dHkgbXVzdCBiZSBjb21wbGV0ZWx5IGluZGVwZW5kZW50IGFuZCBpZ25vcmFudCBvZiBlYWNoIG90 aGVyLg0KDQpJcyB0aGVyZSBhbiBleGFtcGxlIG9mIHRoaXMgaW4geW91ciBkcmFmdD8NCg0KRG8g eW91IG1lYW4gYW4gZXhhbXBsZSBvZiB3aGF0IHRoZSBjb250cm9sbGVyIGxvb2tzIGxpa2U/DQpN YXliZSB0aGUgYW5hbG9neSB0byBjaHJvb3QgaXMgbm90ICB1bml2ZXJzYWxseSB1bmRlcnN0b29k Lg0KDQpUaGUgbG9naWNhbCBzeXN0ZW0ga25vd3Mgb25seSBhYm91dCBpdHNlbGY6DQoNCiAgICAv aW50ZXJmYWNlcw0KICAgIC9zeXN0ZW0NCg0KVGhlIC8gbm9kZSBpcyByZXByZXNlbnRlZCBieSA8 Y29uZmlnPiBvciA8ZGF0YT4gb3IgPGZpbHRlcj4gaW4gdGhlIHByb3RvY29sLg0KDQogICA8Z2V0 LWNvbmZpZz4NCiAgICAgICA8c291cmNlPjxydW5uaW5nLz48L3NvdXJjZT4NCiAgICAgICA8Zmls dGVyPg0KICAgICAgICAgPGludGVyZmFjZXMgLz4NCiAgICAgICAgIDxzeXN0ZW0gLz4NCiAgICAg IDwvZmlsdGVyPg0KICAgPC9nZXRjb25maWc+DQoNCkVhY2ggbG9naWNhbCBzeXN0ZW0gY2FuIGhh dmUgaXRzIG93biAiZXRoMCIgaW50ZXJmYWNlIG9yIHdoYXRldmVyLg0KVGhleSBhcmUgbWFwcGVk IHRvIHJlYWwgaW50ZXJmYWNlcyBpbiB0aGUgcGh5c2ljYWwgc3lzdGVtLg0KDQpBbGwgb3BlcmF0 aW9ucyBvbiB0aGUgbG9naWNhbCBzeXN0ZW0gYXJlIHZhbGlkYXRlZCBhZ2FpbnN0IGl0cyBvd24N CnZpcnR1YWwgZGF0YXN0b3JlLiAgWUFORyB2YWxpZGF0aW9uIGRvZXMgbm90IHdvcmsgb24gaW5k aXZpZHVhbCBhcnJheQ0Kc2xpY2VzIC0tIGl0IG9ubHkgYXBwbGllcyB0byBhbiBlbnRpcmUgZGF0 YXN0b3JlLg0KDQpPbiB0aGUgcGh5c2ljYWwgc2VydmVyIHRoZXJlIG5lZWRzIHRvIGJlIGEgZGF0 YSBtb2RlbCB0byBtYW5hZ2UgdGhlDQpsb2dpY2FsIHNlcnZlcnMgKGFzIE1hcnRpbiBzdWdnZXN0 ZWQpLg0KDQogPGNvbmZpZz4gICAgICAgICAgICAgPC0tLSByb290IG9uIFBIWSBzZXJ2ZXINCiAg IDxpbnRlcmZhY2VzICAvPiAgIDwtLS0tLS0tLS0tLS0tLS0gY29udGFpbnMgdGhlIHJlYWwgaW50 ZXJmYWNlcywgaW5jbHVkaW5nIGV0aDIzDQogICA8dmlydHVhbC1zZXJ2ZXJzPg0KICAgICAgPHZp cnR1YWwtc2VydmVyPg0KICAgICAgICAgPG5hbWU+dnMxPC9uYW1lPg0KICAgICAgICAgPGl0Zi1t YXA+DQogICAgICAgICAgICAgPHJlYWwtaXRmPmV0aDIzPC9yZWFsLWl0Zj4NCiAgICAgICAgICAg ICA8dmlyLWl0Zj5ldGgwPC92aXItaXRmPg0KICAgICAgICAgPGl0Zi1tYXA+DQogICAgICAgICA8 bW9yZS12aXJ0dWFsLXNlcnZlci1wYXJhbXMgLi4uIC8+DQogICAgICAgICA8cm9vdD4gICAgICAg ICAgICAgICAgICAgPC0tLS0tLS0tLS0tIFlBTkcgbW91bnQgcG9pbnQgKHZpcnR1YWwgc2VydmVy IHJvb3QpDQogICAgICAgICAgICA8aW50ZXJmYWNlcz4NCiAgICAgICAgICAgICAgIDxpbnRlcmZh Y2U+DQogICAgICAgICAgICAgICAgICA8bmFtZT5ldGgwPC9uYW1lPg0KICAgICAgICAgICAgICAg ICAgICAuLi4NCiAgICAgICAgICAgICAgIDwvaW50ZXJmYWNlPg0KICAgICAgICAgICAgPC9pbnRl cmZhY2VzPg0KICAgICAgICAgICAgPHN5c3RlbSAuLi4gLz4NCiAgICAgICAgIDwvcm9vdD4NCiAg ICAgICA8L3ZpcnR1YWwtc2VydmVyPg0KICAgIDwvdmlydHVhbC1zZXJ2ZXJzPg0KICA8L2NvbmZp Zz4NCg0KT24gdGhlIHBoeXNpY2FsIHN5c3RlbSwgdGhlIHZpcnR1YWwgcm9vdHMgYXJlIHdpdGhp biBsaXN0IGVudHJpZXMsDQpub3QgYXQgdGhlIHRvcCBvZiB0aGUgdHJlZS4gIFRoZSBwaHlzaWNh bCBzZXJ2ZXIgZGF0YSBhbmQvb3IgYW55DQpvZiB0aGUgbG9naWNhbCBzZXJ2ZXJzIGNhbiBiZSBh Y2Nlc3NlZCBhdCBvbmNlLg0KDQpUaGVyZSBpcyBubyBleHRyYSBpbmRleGluZyBjb3N0LiAgVGhl IHNhbWUgZGF0YSBtb2RlbCAoZS5nIGlldGYtaW50ZXJmYWNlcykNCmNhbiBiZSB1c2VkIGluIHBo eXNpY2FsIGFuZCB2aXJ0dWFsIHNlcnZlci4gIFlBTkcgTW91bnQgcHJvdmlkZXMgYSBsb3QNCm1v cmUgdGhhbiBzaW1wbHkgaWRlbnRpZnlpbmcgL3ZpcnR1YWwtc2VydmVycy92aXJ0dWFsLXNlcnZl ci9yb290DQphcyB0aGUgc3RhcnQgb2YgYW4gZW1iZWRkZWQgZGF0YXN0b3JlLiAgQXMgQWxleCBz YWlkLCBub3QgYWxsIG9mIGl0DQpuZWVkcyB0byBiZSBzdGFuZGFyZGl6ZWQgYXQgb25jZS4NCg0K VGggInZpcnR1YWwtc2VydmVycyIgbm9kZSBpcyBub3QgdW5kZXIgZWFjaCA8cm9vdD4gYmVjYXVz ZSBvbmx5DQp0aGUgcGh5c2ljYWwgc2VydmVyIGxvYWRzIGFuZCBzdXBwb3J0cyB0aGF0IG1vZHVs ZS4NCg0KDQoNCg0KVGhhbmtzLA0KTG91DQo+DQoNCg0KQW5keQ0KDQoNCj4gQW5keQ0KPg0KPg0K Pg0KPiAtLS0tLS0tLS0tDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gbmV0bW9kQGlldGYub3JnPG1haWx0 bzpuZXRtb2RAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbmV0bW9kDQo+DQoNCg== --_000_DBC595ED2346914F9F81D17DD5C32B571DC8F1B5xmbrcdx05ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnByZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkVtYWlsU3R5 bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJ e21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIExvdSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPkFuZHkgYmFzaWNhbGx5IGFscmVhZHkgcHJvdmlkZWQgdGhlIGFuc3dl ciwgYnV0IGp1c3QgdG8gYWRkIHRvIHlvdXIgcXVlc3Rpb246IHllcywgdGhlcmUgaXMgYW4gZXhh bXBsZSBpbiB0aGUgZHJhZnQgKGFwcGVuZGl4IEEpLiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SRkMgNzIyMyBwcm92aWRlcyBhIFlBTkcgbW9kZWwg Zm9yIGludGVyZmFjZXMuJm5ic3A7IEl0IGRlZmluZXMgYSBoaWVyYXJjaHkgdGhhdCBpbmNsdWRl cyB0aGUgZm9sbG93aW5nOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJvIGlu dGVyZmFjZXMtc3RhdGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICYjNDM7LS1ybyBpbnRlcmZhY2UqIFtuYW1lXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7JiM0MzstLXJvIG5hbWUmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3RyaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcm8gdHlwZSZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpZGVudGl0eXJlZjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJvIGFkbWlu LXN0YXR1cyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBlbnVtZXJhdGlvbjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJiM0MzstLXJvIG9wZXItc3RhdHVzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGVudW1lcmF0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcm8gbGFzdC1jaGFuZ2U/Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHlhbmc6ZGF0ZS1hbmQtdGltZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlIGV4YW1wbGUgcmVmZXJz IHRvIGEgY29udHJvbGxlciAoZS5nLiBPREwpIGFuZCB0aGUgbW9kZWwgdGhhdCBpdCBleHBvc2Vz IHRvIGl0cyBhcHBsaWNhdGlvbnMuJm5ic3A7IChUaGlzIGlzIGFsc28gd2hhdCBSb2JlcnQgd2Fz IHJlZmVycmluZyB0byBlYXJsaWVyLikmbmJzcDsgVGhpcyBtb2RlbA0KIGlzIHN1cHBvc2VkIHRv IGluY2x1ZGUgYSBuZXR3b3JrIGludmVudG9yeSwgd2hpY2ggaW5jbHVkZXMgYSBsaXN0IG9mIHRo ZSB2YXJpb3VzIGRldmljZXMvc3lzdGVtcy9ub2RlcyBjb250cm9sbGVkIGJ5IHRoZSBjb250cm9s bGVyLCBhbmQgc2hhbGwgaW5jbHVkZSBmb3IgZWFjaCBvZiB0aG9zZSBkZXZpY2VzIGluZm9ybWF0 aW9uIHJlZ2FyZGluZyBpdHMgaW50ZXJmYWNlcy4mbmJzcDsgSW4gb3RoZXIgd29yZHMsIHRoZSBj b250cm9sbGVyIHdhbnRzIHRvDQogaW1wb3NlIGFuIGFkZGl0aW9uYWwgbGV2ZWwgKG9yIHR3bykg b24gdG9wIG9mIHRoZSBoaWVyYXJjaHkgb2YgdGhlIGluZGl2aWR1YWwgZGV2aWNlcywgbmFtZWx5 IHNvbWV0aGluZyBvZiB0aGUgc29ydA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHByZT4mbmJz cDsmbmJzcDsmbmJzcDsmIzQzOy0tIHJ3IG5ldHdvcmstZWxlbWVudHM8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLSBydyBu ZXR3b3JrLWVsZW1lbnQgW2VsZW1lbnQtaWRdPG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+QW5kIHRoZW4gaGF2ZSB2aXNpYmlsaXR5IG9mIHRoZSBpbnRlcmZhY2VzIGJlbG93 IHRoZSBuZXR3b3JrIGRldmljZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5JbiB0aGlzIGNhc2UsIHlvdSBjb3VsZCBkZWZpbmUgcHV0IGFuIOKAnGludGVyZmFj ZS1zdGF0c+KAnSBtb3VudHBvaW50IGJlbG93IG5ldHdvcmsgZWxlbWVudCwgYW5kIHBvaW50IGl0 IHRvIGludGVyZmFjZXMtc3RhdGUsIHRvIHJlc3VsdCBpbiB0aGUgZm9sbG93aW5nPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHByZT4mbmJzcDsmbmJzcDsgJiM0MzstLSBydyBuZXR3b3JrLWVsZW1l bnRzPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICYjNDM7LS0gcncgbmV0d29yay1lbGVtZW50IFtlbGVtZW50LWlkXTxvOnA+PC9vOnA+ PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7JiM0MzstLU0gaW50ZXJm YWNlcy1zdGF0ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7JiM0MzstLXJvIGludGVyZmFjZSogW25hbWVd PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmIzQzOy0tcm8gbmFtZSZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzdHJpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyYjNDM7LS1ybyB0eXBlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlkZW50 aXR5cmVmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmIzQzOy0tcm8gYWRt aW4tc3RhdHVzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVudW1lcmF0aW9u PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmIzQzOy0tcm8gb3Blci1zdGF0 dXMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZW51bWVyYXRpb248 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyYjNDM7LS1ybyBsYXN0LWNoYW5n ZT8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgeWFuZzpkYXRlLWFuZC10aW1l PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4tLS0gQWxleDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiBBbmR5IEJpZXJtYW4gW21haWx0bzphbmR5QHl1bWF3b3Jrcy5jb21dDQo8YnI+DQo8Yj5T ZW50OjwvYj4gRnJpZGF5LCBBdWd1c3QgMjgsIDIwMTUgMjozMyBQTTxicj4NCjxiPlRvOjwvYj4g TG91IEJlcmdlciAmbHQ7bGJlcmdlckBsYWJuLm5ldCZndDs8YnI+DQo8Yj5DYzo8L2I+IEFsZXhh bmRlciBDbGVtbSAoYWxleCkgJmx0O2FsZXhAY2lzY28uY29tJmd0OzsgbmV0bW9kQGlldGYub3Jn PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbmV0bW9kXSBsb2dpY2FsIHN5c3RlbXMgbW9kZWw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIEF1ZyAyOCwgMjAxNSBhdCAxOjMxIFBN LCBMb3UgQmVyZ2VyICZsdDs8YSBocmVmPSJtYWlsdG86bGJlcmdlckBsYWJuLm5ldCIgdGFyZ2V0 PSJfYmxhbmsiPmxiZXJnZXJAbGFibi5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 MGluO21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6MGlu Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+T24gQXVndXN0IDI4LCAyMDE1IDM6NTM6MzMg UE0gQW5keSBCaWVybWFuICZsdDs8YSBocmVmPSJtYWlsdG86YW5keUB5dW1hd29ya3MuY29tIiB0 YXJnZXQ9Il9ibGFuayI+YW5keUB5dW1hd29ya3MuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJp Z2h0OjBpbjttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDowaW4iPg0KPHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7IE9uIEZyaSwgQXVnIDI4LCAyMDE1IGF0IDExOjMxIEFNLCBB bGV4YW5kZXIgQ2xlbW0gKGFsZXgpICZsdDs8YSBocmVmPSJtYWlsdG86YWxleEBjaXNjby5jb20i IHRhcmdldD0iX2JsYW5rIj5hbGV4QGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyB3cm90ZTo8 YnI+DQomZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyZndDsgRnJvbTogbmV0bW9kIFttYWlsdG86 PGEgaHJlZj0ibWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgTGFkaXNsYXYgTGhvdGth PGJyPg0KJmd0OyZndDsgU2VudDogRnJpZGF5LCBBdWd1c3QgMjgsIDIwMTUgNDozMSBBTTxicj4N CiZndDsmZ3Q7IFRvOiBNYXJ0aW4gQmpvcmtsdW5kICZsdDs8YSBocmVmPSJtYWlsdG86bWJqQHRh aWwtZi5jb20iIHRhcmdldD0iX2JsYW5rIj5tYmpAdGFpbC1mLmNvbTwvYT4mZ3Q7Ow0KPGEgaHJl Zj0ibWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFuZHlAeXVtYXdv cmtzLmNvbTwvYT48YnI+DQomZ3Q7Jmd0OyBDYzogPGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5ldG1vZEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyBT dWJqZWN0OiBSZTogW25ldG1vZF0gbG9naWNhbCBzeXN0ZW1zIG1vZGVsPGJyPg0KJmd0OyZndDs8 YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IC4uLi4uPGJyPg0KJmd0OyZndDsgJmx0O3NuaXAm Z3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBOQUNNLCBhcyB3ZWxsIGFzIGFsbCBvdGhl ciBtb2R1bGVzIHdlIGhhdmUsIGlzIGJhc2VkIG9uIHRoZSBhc3N1bXB0aW9uIG9mPGJyPg0KJmd0 OyZndDsgYSBzaW5nbGUgbWFuYWdlZCBkZXZpY2UuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyBJIHRoaW5rIGl0IGlzIGEgdHlwaWNhbCB0cmVuZCB0aGF0IHdoYXQgb25jZSB3YXMgYSBzaW5n bGUgaW5zdGFuY2UgYmVjb21lczxicj4NCiZndDsmZ3Q7IGFuIGFycmF5LiBJZiB3ZSBkaWQgaWV0 Zi1yb3V0aW5nIDIwIHllYXJzIGFnbywgdGhlcmUgd291bGQgcHJvYmFibHkgYmUgbm88YnI+DQom Z3Q7Jmd0OyByb3V0aW5nLWluc3RhbmNlIGxpc3QuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyBTbyBJIHRoaW5rIGl0IGlzIGEgcmVhbCBwcm9ibGVtIHRoYXQgd2UgY2FuJ3QgbWlncmF0ZSBm cm9tIGEgY29udGFpbmVyIHRvPGJyPg0KJmd0OyZndDsgYSBsaXN0IGFuZCByZXVzZSB0aGUgY29u dGFpbmVyJ3MgZGF0YSBtb2RlbC4gR3JvdXBpbmdzIG1pZ2h0IGhlbHAgc29tZXdoYXQ8YnI+DQom Z3Q7Jmd0OyBidXQgdGhleSBhcmUgc3RpbGwgbm90IGZ1bGx5IHJldXNhYmxlLCBpZiwgZm9yIGV4 YW1wbGUsIHRoZXkgY29udGFpbjxicj4NCiZndDsmZ3Q7IGFic29sdXRlIHJlZmVyZW5jZXMuPGJy Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBMYWRhPGJyPg0KJmd0OyZndDsgJmx0Oy9zbmlwJmd0 Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgT25lIGNvbW1lbnQsIGlmIHlvdSBmb3JnaXZl IHRoZSBwaXRjaCwgYnV0IHRoaXMgcHJvYmxlbSAvIHVzZSBjYXNlIGlzIGJ5PGJyPg0KJmd0OyZn dDsgdGhlIHdheSBleGFjdGx5IG9uZSBvZiB0aGUgcmVhc29ucyBmb3IgbW91bnRpbmcsIHdoaWNo IGFsbG93cyB5b3UgdG88YnI+DQomZ3Q7Jmd0OyBpbnRyb2R1Y2UgYW5kIGltcG9zZSBhbiBhZGRp dGlvbmFsIHN0cnVjdHVyZSBvbiB0b3Agb2YgYW4gZXhpc3Rpbmc8YnI+DQomZ3Q7Jmd0OyBzdHJ1 Y3R1cmUsIGFuZCAmcXVvdDtpbnNlcnQmcXVvdDsgdGhlIGV4aXN0aW5nIHN0cnVjdHVyZSBpbnRv IGl0LiZuYnNwOyBBdWdtZW50YXRpb25zIGV0Yzxicj4NCiZndDsmZ3Q7IGNhbiBvbmx5IGFkZCBi ZWxvdyB0aGUgaGllcmFyY2h5LCB0aGVyZSBpcyBubyB3YXkgd2UgY2FuIHB1dCBhIG5ldzxicj4N CiZndDsmZ3Q7IGNvbnRhaW5lciBvciBsaXN0IG9yIHdoYXRldmVyIG9uIHRvcCBvZiBhbiBleGlz dGluZyBzdHJ1Y3R1cmUgKHdpdGhvdXQ8YnI+DQomZ3Q7Jmd0OyByZXBsaWNhdGluZyB0aGUgZXhp c3Rpbmcgc3RydWN0dXJlIGluIGEgZHVwbGljYXRlIG1vZGVsKSwgYnV0IHBlZXItbW91bnQ8YnI+ DQomZ3Q7Jmd0OyBsZXRzIHlvdSBkbyB0aGF0LiZuYnNwOyBPbmUgdXNlIGNhc2UgdXNlZCBpbiBP cGVuIERheWxpZ2h0IGludm9sdmVzIG9yZ2FuaXppbmcvPGJyPg0KJmd0OyZndDsgaW5zZXJ0aW5n IGRldmljZS1sZXZlbCBpbmZvcm1hdGlvbiBpbnRvIGEgbmV0d29yayBpbnZlbnRvcnksIHdoaWNo IGlzPGJyPg0KJmd0OyZndDsgYmFzaWNhbGx5IGltcG9zZWQgJnF1b3Q7b24gdG9wJnF1b3Q7Ljxi cj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIHRoaW5nIFlB TkcgTW91bnQgd291bGQgYmUgdGhlIGJlc3Qgd2F5IHRvIHNvbHZlIHRoaXMgcHJvYmxlbS48YnI+ DQomZ3Q7IEl0IHByb3ZpZGVzIGEgc3RhbmRhcmQgd2F5IHRvIGRvICZxdW90O2Nocm9vdCZxdW90 OyBhbmQgaXQgaXMgZmxleGlibGUuPGJyPg0KJmd0OyBUaGUgbWVjaGFuaWNzIG9mIGEgJnF1b3Q7 ZGF0YXN0b3JlIHdpdGhpbiBhIGRhdGFzdG9yZSZxdW90OyBhcmUgdGhlPGJyPg0KJmd0OyBzYW1l IGFuZCBpbmRlcGVuZGVudCBvZiB0aGUgc291cmNlIG9mIHRoZSBkYXRhIChsb2NhbCw8YnI+DQom Z3Q7IHJlbW90ZSwgdmlydHVhbCwgZXRjLik8YnI+DQomZ3Q7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJn aW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDowaW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj5TbyBJIHRoaW5rIGFuIGV4YW1wbGUgb2YgaG93IHlvdSBzZWUgdGhpcyB3b3JraW5nIHdv dWxkIGhlbHBmdWwuJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MTIuMHB0 O21hcmdpbi1sZWZ0OjBpbiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkNhbiBvbmUgb2Yg eW91IGdpdmUgYW4gZXhhbXBsZSBvZiBob3cgdGhpcyB3b3JkIHdvcmsgZm9yIGEgZGV2aWNlICh3 aGljaCBtYXkgYmUgcGh5c2ljYWwgb3IgdmlydHVhbCkgdGhhdCBhbGxvY2F0ZXMgZG9uZSByZXNv dXJjZXMsIHNheSBpbnRlcmZhY2VzIHRvIG9uZSBsb2dpY2FsIGVudGl0eSAocm91dGVyLCBzeXN0 ZW0sIGV0YykgYW5kIG90aGVyIHJlc291cmNlcyB0byBhIHNlY29uZCBlbnRpdHk/DQogQW5kIG9m IGNvdXJzZSBJIHdhbnQgdG8gbWFuYWdlIGFsbCB3aXRoIHlhbmcgYW5kIHRoZSBmaXJzdCBhbmQg c2Vjb25kIChzdWIpIGVudGl0eSBtdXN0IGJlIGNvbXBsZXRlbHkgaW5kZXBlbmRlbnQgYW5kIGln bm9yYW50IG9mIGVhY2ggb3RoZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklzIHRoZXJl IGFuIGV4YW1wbGUgb2YgdGhpcyBpbiB5b3VyIGRyYWZ0PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EbyB5b3UgbWVhbiBhbiBleGFtcGxlIG9m IHdoYXQgdGhlIGNvbnRyb2xsZXIgbG9va3MgbGlrZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1heWJlIHRoZSBhbmFsb2d5IHRvIGNocm9vdCBp cyBub3QgJm5ic3A7dW5pdmVyc2FsbHkgdW5kZXJzdG9vZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGxvZ2ljYWwgc3lzdGVtIGtub3dz IG9ubHkgYWJvdXQgaXRzZWxmOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7IC9pbnRlcmZhY2VzPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7IC9zeXN0 ZW08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhlIC8gbm9kZSBpcyByZXByZXNlbnRlZCBieSAmbHQ7Y29uZmlnJmd0OyBvciAmbHQ7ZGF0YSZn dDsgb3IgJmx0O2ZpbHRlciZndDsgaW4gdGhlIHByb3RvY29sLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7Jmx0O2dldC1j b25maWcmZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7c291cmNlJmd0OyZsdDtydW5uaW5n LyZndDsmbHQ7L3NvdXJjZSZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDtmaWx0ZXImZ3Q7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O2ludGVyZmFjZXMgLyZndDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7c3lzdGVtIC8mZ3Q7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAm bHQ7L2ZpbHRlciZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsmbHQ7L2dldGNvbmZpZyZndDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RWFjaCBsb2dpY2FsIHN5c3Rl bSBjYW4gaGF2ZSBpdHMgb3duICZxdW90O2V0aDAmcXVvdDsgaW50ZXJmYWNlIG9yIHdoYXRldmVy LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhl eSBhcmUgbWFwcGVkIHRvIHJlYWwgaW50ZXJmYWNlcyBpbiB0aGUgcGh5c2ljYWwgc3lzdGVtLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbGwg b3BlcmF0aW9ucyBvbiB0aGUgbG9naWNhbCBzeXN0ZW0gYXJlIHZhbGlkYXRlZCBhZ2FpbnN0IGl0 cyBvd248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PnZpcnR1YWwgZGF0YXN0b3JlLiZuYnNwOyBZQU5HIHZhbGlkYXRpb24gZG9lcyBub3Qgd29yayBv biBpbmRpdmlkdWFsIGFycmF5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5zbGljZXMgLS0gaXQgb25seSBhcHBsaWVzIHRvIGFuIGVudGlyZSBkYXRh c3RvcmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIHRoZSBwaHlzaWNhbCBzZXJ2ZXIgdGhlcmUgbmVlZHMgdG8gYmUgYSBkYXRhIG1vZGVs IHRvIG1hbmFnZSB0aGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPmxvZ2ljYWwgc2VydmVycyAoYXMgTWFydGluIHN1Z2dlc3RlZCkuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZsdDtj b25maWcmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDst LS0gcm9vdCBvbiBQSFkgc2VydmVyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7Jmx0O2ludGVyZmFjZXMgJm5ic3A7LyZndDsg Jm5ic3A7ICZsdDstLS0tLS0tLS0tLS0tLS0gY29udGFpbnMgdGhlIHJlYWwgaW50ZXJmYWNlcywg aW5jbHVkaW5nIGV0aDIzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7Jmx0O3ZpcnR1YWwtc2VydmVycyZndDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZsdDt2aXJ0dWFsLXNlcnZlciZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsmbHQ7bmFtZSZndDt2czEmbHQ7L25hbWUmZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7Jmx0O2l0Zi1tYXAmZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsmbHQ7cmVhbC1pdGYmZ3Q7ZXRoMjMmbHQ7L3JlYWwtaXRmJmd0OzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O3Zpci1pdGYmZ3Q7ZXRoMCZsdDsvdmly LWl0ZiZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7aXRmLW1hcCZndDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7bW9yZS12aXJ0dWFsLXNlcnZlci1wYXJhbXMg Li4uIC8mZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O3Jvb3QmZ3Q7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZsdDstLS0tLS0tLS0tLSBZQU5HIG1vdW50IHBvaW50ICh2aXJ0dWFsIHNlcnZlciByb290KTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O2ludGVyZmFjZXMmZ3Q7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O2ludGVy ZmFjZSZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZsdDtuYW1lJmd0O2V0aDAmbHQ7L25hbWUmZ3Q7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgLi4uPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0Oy9pbnRlcmZh Y2UmZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7L2ludGVyZmFj ZXMmZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7c3lzdGVtIC4u LiAvJmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDsvcm9vdCZndDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyZsdDsvdmlydHVhbC1zZXJ2ZXImZ3Q7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZsdDsvdmly dHVhbC1zZXJ2ZXJzJmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7ICZsdDsvY29uZmlnJmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiB0aGUgcGh5c2ljYWwgc3lzdGVtLCB0 aGUgdmlydHVhbCByb290cyBhcmUgd2l0aGluIGxpc3QgZW50cmllcyw8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm5vdCBhdCB0aGUgdG9wIG9mIHRo ZSB0cmVlLiZuYnNwOyBUaGUgcGh5c2ljYWwgc2VydmVyIGRhdGEgYW5kL29yIGFueTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+b2YgdGhlIGxvZ2lj YWwgc2VydmVycyBjYW4gYmUgYWNjZXNzZWQgYXQgb25jZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlcmUgaXMgbm8gZXh0cmEgaW5kZXhp bmcgY29zdC4mbmJzcDsgVGhlIHNhbWUgZGF0YSBtb2RlbCAoZS5nIGlldGYtaW50ZXJmYWNlcyk8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmNhbiBi ZSB1c2VkIGluIHBoeXNpY2FsIGFuZCB2aXJ0dWFsIHNlcnZlci4mbmJzcDsgWUFORyBNb3VudCBw cm92aWRlcyBhIGxvdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+bW9yZSB0aGFuIHNpbXBseSBpZGVudGlmeWluZyAvdmlydHVhbC1zZXJ2ZXJzL3Zp cnR1YWwtc2VydmVyL3Jvb3Q8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPmFzIHRoZSBzdGFydCBvZiBhbiBlbWJlZGRlZCBkYXRhc3RvcmUuJm5ic3A7 IEFzIEFsZXggc2FpZCwgbm90IGFsbCBvZiBpdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+bmVlZHMgdG8gYmUgc3RhbmRhcmRpemVkIGF0IG9uY2Uu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo ICZxdW90O3ZpcnR1YWwtc2VydmVycyZxdW90OyBub2RlIGlzIG5vdCB1bmRlciBlYWNoICZsdDty b290Jmd0OyBiZWNhdXNlIG9ubHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPnRoZSBwaHlzaWNhbCBzZXJ2ZXIgbG9hZHMgYW5kIHN1cHBvcnRzIHRo YXQgbW9kdWxlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdp bi1sZWZ0OjBpbiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoYW5rcyw8YnI+DQpMb3U8 YnI+DQomZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5keTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFy Z2luLWxlZnQ6MGluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyBBbmR5PGJyPg0K Jmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAtLS0tLS0tLS0tPGJyPg0KJmd0OyBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsg bmV0bW9kIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5ldG1vZEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8L2E+ PGJyPg0KJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DBC595ED2346914F9F81D17DD5C32B571DC8F1B5xmbrcdx05ciscoc_-- From nobody Fri Aug 28 16:44:18 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 605B61ACE5E for ; Fri, 28 Aug 2015 16:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6cM4Q2sOm9D2 for ; Fri, 28 Aug 2015 16:44:14 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 773121ACE1B for ; Fri, 28 Aug 2015 16:44:14 -0700 (PDT) Received: by pacdd16 with SMTP id dd16so76871736pac.2 for ; Fri, 28 Aug 2015 16:44:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=gzRve+1Elx+U2w2CZjXtpdfo7mGWokpXzNnGwB668QY=; b=gq/3dlxxeOoJR8vUkfhyxcllhTT559k3+GoUiQ7hZVbS0Xhr2EZk9nVoG+pEC5vhcZ a6d45UIrHXn9onC3Xp+XLSPzi3JEyo25Iy1YKo8w4fYdXHLwPeiwdMgofX+wDwL78rVb kBgQZ302Lp0LCdnYqGshcBd1NnlpKJ1TxCl3m3TPf0JFxeCDNwdLmZu6ww8lpBuhMPu2 TZmZrBc7PzX7b7jJtxsVWbRtZJH7fGQuvy4JIQtnhoFfI7USJYzhSIDFqcydrFVgj0vN 5QXWExH0YQ+P518gdML7FwcCHWSjHA1tr+1WJzMpRwvQxnfx6XRBbCbIEO8b33fqeSSc +zNw== X-Received: by 10.68.254.200 with SMTP id ak8mr19154205pbd.53.1440805454168; Fri, 28 Aug 2015 16:44:14 -0700 (PDT) Received: from ?IPv6:2001:420:c0c8:1007::16a? ([2001:420:c0c8:1007::16a]) by smtp.gmail.com with ESMTPSA id hs11sm6931344pdb.12.2015.08.28.16.44.12 (version=TLS1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Aug 2015 16:44:13 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_7CD4BC65-2107-41AF-942C-BBD8FE5E7F85" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Mahesh Jethanandani In-Reply-To: Date: Fri, 28 Aug 2015 16:44:11 -0700 Message-Id: References: <55DF74FC.101@rob.sh> <20150828.083354.1177215032438250041.mbj@tail-f.com> <55E054DC.7050906@rob.sh> <20150828.145546.1509142825487206251.mbj@tail-f.com> To: "Acee Lindem (acee)" X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Motivations for Structuring Models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 23:44:16 -0000 --Apple-Mail=_7CD4BC65-2107-41AF-942C-BBD8FE5E7F85 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Acee, This is going to become very interesting very quickly. Routing DT has = decided to define a container for oam-protocols. LIME has decided it = wants to define a generic YANG module for all OAM in = draft-tissa-lime-yang-oam-model. Which model does BFD augment? Or did you just kill the whole charter for = LIME?? > On Aug 28, 2015, at 6:20 AM, Acee Lindem (acee) = wrote: >=20 > Why doesn=E2=80=99t it help? In the next revision of the Routing YANG = DT model, > we=E2=80=99ve switched from including specific models to defining = classes of > models with identities. For example, >=20 > grouping oam-protocols { > container oam-protocols { > list oam-protocol { > key "type"; > leaf type { > type identityref { > base oam-protocol-type; > } > mandatory true; > description > "The Operations, Administration, and >=20 >=20 > Maintenance (OAM) protocol type, e.g., BFD, >=20 >=20 > TWAMP, CFM, etc."; > } > description > "List of OAM protocols configured for a >=20 >=20 > networking instance."; > } > description > "Container for list of OAM protocols configured for a >=20 >=20 > networking instance."; > } > description > "Grouping for OAM protocols configured for a >=20 >=20 > networking instance."; > } >=20 >=20 > Then the grouping is include the networking-instances. By doing this, = the > intent is that it would be evident as to where a particular model = would be > found.=20 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_7CD4BC65-2107-41AF-942C-BBD8FE5E7F85 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Acee,

This = is going to become very interesting very quickly. Routing DT has decided = to define a container for oam-protocols. LIME has decided it wants to = define a generic YANG module for all OAM in = draft-tissa-lime-yang-oam-model.

Which model does BFD augment? Or did = you just kill the whole charter for LIME??

On = Aug 28, 2015, at 6:20 AM, Acee Lindem (acee) <acee@cisco.com> = wrote:

Why doesn=E2=80=99t it help? In the next = revision of the Routing YANG DT model,
we=E2=80=99ve switched from including specific = models to defining classes of
models with identities. = For example,

grouping oam-protocols = {
     container oam-protocols = {
         list = oam-protocol {
          &nb= sp;  key "type";
          &nb= sp;  leaf type {
          &nb= sp;      type identityref {
          &nb= sp;          base = oam-protocol-type;
          &nb= sp;      }
          &nb= sp;      mandatory true;
          &nb= sp;      description
          &nb= sp;          "The = Operations, Administration, and


          &nb= sp;           Maint= enance (OAM) protocol type, e.g., BFD,


          &nb= sp;           TWAMP= , CFM, etc.";
          &nb= sp;  }
          &nb= sp;  description
          &nb= sp;      "List of OAM protocols configured = for a


          &nb= sp;       networking = instance.";
         }<= br style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant: normal; font-weight: normal; letter-spacing: normal; = line-height: normal; orphans: auto; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; widows: auto; word-spacing: = 0px; -webkit-text-stroke-width: 0px;" class=3D"">         descripti= on
          &nb= sp;  "Container for list of OAM protocols configured for = a


          &nb= sp;    networking instance.";
     }
     description
         "Grouping= for OAM protocols configured for a


          net= working instance.";
 }


Then the grouping is include the = networking-instances.  By doing this, the
intent is that it would be evident as to where a = particular model would be
found. 

Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_7CD4BC65-2107-41AF-942C-BBD8FE5E7F85-- From nobody Fri Aug 28 18:40:46 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65C471B38F9 for ; Fri, 28 Aug 2015 18:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.229 X-Spam-Level: X-Spam-Status: No, score=-3.229 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, 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 5Ih0HCDp7OVu for ; Fri, 28 Aug 2015 18:40:43 -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 2BFCE1B38C6 for ; Fri, 28 Aug 2015 18:40:42 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CAN91465; Sat, 29 Aug 2015 01:40:40 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sat, 29 Aug 2015 02:40:39 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.99]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0235.001; Sat, 29 Aug 2015 09:40:33 +0800 From: Qin Wu To: Mahesh Jethanandani , "Acee Lindem (acee)" Thread-Topic: [netmod] Motivations for Structuring Models Thread-Index: AQHQ4NBOADFMJ24pqkmio9Q4U/+UL54fggqAgAAU4ACAACMmAIAADoUAgACmsgCAAGQvAIAABoMAgAAG/YCAAK4tgIAAnf/w Date: Sat, 29 Aug 2015 01:40:33 +0000 Message-ID: References: <55DF74FC.101@rob.sh> <20150828.083354.1177215032438250041.mbj@tail-f.com> <55E054DC.7050906@rob.sh> <20150828.145546.1509142825487206251.mbj@tail-f.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA848150C0nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Motivations for Structuring Models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2015 01:40:45 -0000 --_000_B8F9A780D330094D99AF023C5877DABA848150C0nkgeml501mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIE1haGVzaDoNCkp1c3Qgd2FudCB0byBjbGFyaWZ5Lg0KSSB0aGluayB3aGF0IFJvdXRpbmcg RFQgdGVhbSBpcyBkb2luZyBpcyBjb21wbGVtZW50YXJ5IHRvIHdoYXQgTElNRSBXRyBpcyBkb2lu Zy4NCndoYXQgcm91dGluZyBEVCB0ZWFtIGlzIGRvaW5nIGlzIHRvIGlkZW50aWZ5IGFsbCB0aGUg ZXhpc3RpbmcgbW9kZWxzIGFuZCB0aGUgbW9kZWxzIHRoYXQgYXJlIHVuZGVyIGRldmVsb3BtZW50 IGZvciBPQU0sIHJvdXRpbmcsIGludGVyZmFjZSwgIGV0YywgdG8gc2VlIGhvdyB0aGVzZSBtb2Rl bHMgZm9yIGRpZmZlcmVudCB0ZWNobm9sb2d5LCBwcm90b2NvbCwgZmVhdHVyZShlLmcuLCBBQ0ws IFFvUykgY2FuIGZpdCB0b2dldGhlciB0byBmb3JtIGNvbXByZWhlbnNpdmUgc3RydWN0dXJlIGFu ZCBkZWxpdmVyIHRoZSBzZXJ2aWNlLg0KDQpMSU1FIHdvcmsgd2FudHMgdG8gcHJvdmlkZSBjb21t b24gc3RydWN0dXJlIGZvciB2YXJpb3VzIE9BTSB0ZWNobm9sb2dpZXMgYnkgZGVmaW5pbmcgZ2Vu ZXJpYyBZQU5HIG1vZGVsIGZvciBPQU0uIEJ1dCB0aGUgZm9jdXMgaXMgdG8gZGVmaW5lIGdlbmVy aWMgWUFORyBtb2RlbCBmb3IgT0FNLg0KQmFzZWQgb24gTElNRSBXRyBjaGFydGVyIEFsbCB0aGUg dGVjaG5vbG9neSBzcGVjaWZpYyBtb2RlbHMgYXJlIGV4dGVuc2lvbiB0byB0aGlzIGdlbmVyaWMg bW9kZWwuIFRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGVzZSBPQU0gcmVsYXRlZCBtb2RlbHMg Y2FuIGRlcGljdGVkIGFzIGZvbGxvd2luZzoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICst Ky0rLSstKy0rDQogICAgICAgICAgICAgICAgICAgICAgICAgICB8IExJTUUgZ2VufA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgfE9BTSBZQU5HIHwNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICstKy0rLSstKy0rDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICB8ICAgICAg ICAgICAgICB8ICAgICAgICAgICAgICAgfCAgICAgICAgIHwgICAgICAgICAgICAgICAgfA0KICAg ICstKy0rLSstKy0rICAgKy0rLSstKy0rLSsgICArLSstKy0rLSstKyArLSstKy0rLSstKyAgICAg ICstKy0rLSstKy0rDQogICAgfCBDRk0gICAgIHwgICB8IE1QTFMtVFAgfCAgIHwgTVBMUyAgICB8 IHwgSVAgICAgICB8IC4gLiAufCAgZm9vICAgIHwNCiAgICB8T0FNIFlBTkcgfCAgIHxPQU0gWUFO RyB8ICAgfE9BTSBZQU5HIHwgfE9BTSBZQU5HIHwgICAgICB8T0FNIFlBTkcgfA0KICAgICstKy0r LSstKy0rICAgKy0rLSstKy0rLSsgICArLSstKy0rLSstKyArLSstKy0rLSstKyAgICAgICstKy0r LSstKy0rDQogICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAg IHwgICAgICAgICAgICAgIHwNCiAgICAgICAgICB8ICAgICAgICstKy0rLSstKy0rICAgKy0rLSst Ky0rLSsgICAgICAgfCAgICAgICAgICArLSstKy0rLSstKw0KICAgICAgICAgIHwgICAgICAgfCBN UExTLVRQIHwgICB8IE1QTFMgICAgfCAgICAgICB8ICAgICAuIC4gLnwgIGZvbyAgICB8DQogICAg ICAgICAgfCAgICAgICB8c3ViIHRlY2ggfCAgIHxzdWIgdGVjaCB8ICAgICAgIHwgICAgICAgICAg fHN1YiB0ZWNoIHwNCg0KVGhlIGV4YW1wbGUgZ2l2ZW4gYnkgQWNlZSBpcyB0byBwcm92aWRlIGEg bGlzdCBvZiBPQU0gcHJvdG9jb2xzIHdoaWNoIG5lZWQgdG8gYmUgcmVhZHkgdG8gY29uZmlndXJl IGEgbmV0d29yayBpbnN0YW5jZS4gVGhlcmUgaXMgbm8gb3ZlcmxhcHBpbmcuDQoNCi1RaW4NCuWP keS7tuS6ujogbmV0bW9kIFttYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBN YWhlc2ggSmV0aGFuYW5kYW5pDQrlj5HpgIHml7bpl7Q6IDIwMTXlubQ45pyIMjnml6UgNzo0NA0K 5pS25Lu25Lq6OiBBY2VlIExpbmRlbSAoYWNlZSkNCuaKhOmAgTogbmV0bW9kQGlldGYub3JnDQrk uLvpopg6IFJlOiBbbmV0bW9kXSBNb3RpdmF0aW9ucyBmb3IgU3RydWN0dXJpbmcgTW9kZWxzDQoN CkFjZWUsDQoNClRoaXMgaXMgZ29pbmcgdG8gYmVjb21lIHZlcnkgaW50ZXJlc3RpbmcgdmVyeSBx dWlja2x5LiBSb3V0aW5nIERUIGhhcyBkZWNpZGVkIHRvIGRlZmluZSBhIGNvbnRhaW5lciBmb3Ig b2FtLXByb3RvY29scy4gTElNRSBoYXMgZGVjaWRlZCBpdCB3YW50cyB0byBkZWZpbmUgYSBnZW5l cmljIFlBTkcgbW9kdWxlIGZvciBhbGwgT0FNIGluIGRyYWZ0LXRpc3NhLWxpbWUteWFuZy1vYW0t bW9kZWwuDQoNCldoaWNoIG1vZGVsIGRvZXMgQkZEIGF1Z21lbnQ/IE9yIGRpZCB5b3UganVzdCBr aWxsIHRoZSB3aG9sZSBjaGFydGVyIGZvciBMSU1FPz8NCg0KT24gQXVnIDI4LCAyMDE1LCBhdCA2 OjIwIEFNLCBBY2VlIExpbmRlbSAoYWNlZSkgPGFjZWVAY2lzY28uY29tPiB3cm90ZToNCg0KV2h5 IGRvZXNu4oCZdCBpdCBoZWxwPyBJbiB0aGUgbmV4dCByZXZpc2lvbiBvZiB0aGUgUm91dGluZyBZ QU5HIERUIG1vZGVsLA0Kd2XigJl2ZSBzd2l0Y2hlZCBmcm9tIGluY2x1ZGluZyBzcGVjaWZpYyBt b2RlbHMgdG8gZGVmaW5pbmcgY2xhc3NlcyBvZg0KbW9kZWxzIHdpdGggaWRlbnRpdGllcy4gRm9y IGV4YW1wbGUsDQoNCmdyb3VwaW5nIG9hbS1wcm90b2NvbHMgew0KICAgICBjb250YWluZXIgb2Ft LXByb3RvY29scyB7DQogICAgICAgICBsaXN0IG9hbS1wcm90b2NvbCB7DQogICAgICAgICAgICAg a2V5ICJ0eXBlIjsNCiAgICAgICAgICAgICBsZWFmIHR5cGUgew0KICAgICAgICAgICAgICAgICB0 eXBlIGlkZW50aXR5cmVmIHsNCiAgICAgICAgICAgICAgICAgICAgIGJhc2Ugb2FtLXByb3RvY29s LXR5cGU7DQogICAgICAgICAgICAgICAgIH0NCiAgICAgICAgICAgICAgICAgbWFuZGF0b3J5IHRy dWU7DQogICAgICAgICAgICAgICAgIGRlc2NyaXB0aW9uDQogICAgICAgICAgICAgICAgICAgICAi VGhlIE9wZXJhdGlvbnMsIEFkbWluaXN0cmF0aW9uLCBhbmQNCg0KDQogICAgICAgICAgICAgICAg ICAgICAgTWFpbnRlbmFuY2UgKE9BTSkgcHJvdG9jb2wgdHlwZSwgZS5nLiwgQkZELA0KDQoNCiAg ICAgICAgICAgICAgICAgICAgICBUV0FNUCwgQ0ZNLCBldGMuIjsNCiAgICAgICAgICAgICB9DQog ICAgICAgICAgICAgZGVzY3JpcHRpb24NCiAgICAgICAgICAgICAgICAgIkxpc3Qgb2YgT0FNIHBy b3RvY29scyBjb25maWd1cmVkIGZvciBhDQoNCg0KICAgICAgICAgICAgICAgICAgbmV0d29ya2lu ZyBpbnN0YW5jZS4iOw0KICAgICAgICAgfQ0KICAgICAgICAgZGVzY3JpcHRpb24NCiAgICAgICAg ICAgICAiQ29udGFpbmVyIGZvciBsaXN0IG9mIE9BTSBwcm90b2NvbHMgY29uZmlndXJlZCBmb3Ig YQ0KDQoNCiAgICAgICAgICAgICAgIG5ldHdvcmtpbmcgaW5zdGFuY2UuIjsNCiAgICAgfQ0KICAg ICBkZXNjcmlwdGlvbg0KICAgICAgICAgIkdyb3VwaW5nIGZvciBPQU0gcHJvdG9jb2xzIGNvbmZp Z3VyZWQgZm9yIGENCg0KDQogICAgICAgICAgbmV0d29ya2luZyBpbnN0YW5jZS4iOw0KIH0NCg0K DQpUaGVuIHRoZSBncm91cGluZyBpcyBpbmNsdWRlIHRoZSBuZXR3b3JraW5nLWluc3RhbmNlcy4g IEJ5IGRvaW5nIHRoaXMsIHRoZQ0KaW50ZW50IGlzIHRoYXQgaXQgd291bGQgYmUgZXZpZGVudCBh cyB0byB3aGVyZSBhIHBhcnRpY3VsYXIgbW9kZWwgd291bGQgYmUNCmZvdW5kLg0KDQpNYWhlc2gg SmV0aGFuYW5kYW5pDQptamV0aGFuYW5kYW5pQGdtYWlsLmNvbQ0KDQoNCg0KDQoNCg== --_000_B8F9A780D330094D99AF023C5877DABA848150C0nkgeml501mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0ZiAt LT4NCjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGluZy1s ZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHk+DQo8Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIyIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDsiPg0KPGRpdj5IaSwgTWFoZXNoOjwvZGl2Pg0KPGRpdj5KdXN0 IHdhbnQgdG8gY2xhcmlmeS48L2Rpdj4NCjxkaXY+SSB0aGluayB3aGF0IFJvdXRpbmcgRFQgdGVh bSBpcyBkb2luZyBpcyBjb21wbGVtZW50YXJ5IHRvIHdoYXQgTElNRSBXRyBpcyBkb2luZy48L2Rp dj4NCjxkaXY+d2hhdCByb3V0aW5nIERUIHRlYW0gaXMgZG9pbmcgaXMgdG8gaWRlbnRpZnkgYWxs IHRoZSBleGlzdGluZyBtb2RlbHMgYW5kIHRoZSBtb2RlbHMgdGhhdCBhcmUgdW5kZXIgZGV2ZWxv cG1lbnQgZm9yIE9BTSwgcm91dGluZzxmb250IGZhY2U9IkNvdXJpZXIgTmV3Ij4sPC9mb250PiBp bnRlcmZhY2UsICBldGMsIHRvIHNlZSBob3cgdGhlc2UgbW9kZWxzIGZvciBkaWZmZXJlbnQgdGVj aG5vbG9neSwgcHJvdG9jb2wsIGZlYXR1cmUoZS5nLiwNCkFDTCwgUW9TKSBjYW4gZml0IHRvZ2V0 aGVyIHRvIGZvcm0gY29tcHJlaGVuc2l2ZSBzdHJ1Y3R1cmUgYW5kIGRlbGl2ZXIgdGhlIHNlcnZp Y2U8Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyI+LjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFj ZT0iQ291cmllciBOZXciPiZuYnNwOzwvZm9udD48L2Rpdj4NCjxkaXY+TElNRSB3b3JrIHdhbnRz IHRvIHByb3ZpZGUgY29tbW9uIHN0cnVjdHVyZSBmb3IgdmFyaW91cyBPQU0gdGVjaG5vbG9naWVz IGJ5IGRlZmluaW5nIGdlbmVyaWMgWUFORyBtb2RlbCBmb3IgT0FNLiBCdXQgdGhlIGZvY3VzIGlz IHRvIGRlZmluZSBnZW5lcmljIFlBTkcgbW9kZWwgZm9yIE9BTS48L2Rpdj4NCjxkaXY+QmFzZWQg b24gTElNRSBXRyBjaGFydGVyIEFsbCB0aGUgdGVjaG5vbG9neSBzcGVjaWZpYyBtb2RlbHMgYXJl IGV4dGVuc2lvbiB0byB0aGlzIGdlbmVyaWMgbW9kZWwuIFRoZSByZWxhdGlvbnNoaXAgYmV0d2Vl biB0aGVzZSBPQU0gcmVsYXRlZCBtb2RlbHMgY2FuIGRlcGljdGVkIGFzIGZvbGxvd2luZzo8L2Rp dj4NCjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IExJTUUgZ2VufDwvZGl2Pg0KPGRpdj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfE9BTSBZQU5HIHw8L2Rpdj4N CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 PC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7PC9kaXY+DQo8ZGl2PiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHw8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7Jm5ic3A7Jm5ic3A7ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7Jm5ic3A7Jm5ic3A7ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7ICYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PC9kaXY+DQo8ZGl2PiZu YnNwOyZuYnNwOyZuYnNwOyB8IENGTSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5i c3A7IHwgTVBMUy1UUCB8Jm5ic3A7Jm5ic3A7IHwgTVBMUyZuYnNwOyZuYnNwOyZuYnNwOyB8IHwg SVAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCAuIC4gLnwmbmJzcDsgZm9vJm5ic3A7 Jm5ic3A7Jm5ic3A7IHw8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHxPQU0gWUFORyB8 Jm5ic3A7Jm5ic3A7IHxPQU0gWUFORyB8Jm5ic3A7Jm5ic3A7IHxPQU0gWUFORyB8IHxPQU0gWUFO RyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHxPQU0gWUFORyB8PC9kaXY+DQo8ZGl2 PiZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOyZu YnNwOyZuYnNwOyAmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOyZuYnNwOyZuYnNw OyAmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOyAmIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOzwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PC9kaXY+DQo8ZGl2PiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7Jm5ic3A7Jm5ic3A7ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0Mzs8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfCBNUExTLVRQIHwmbmJzcDsmbmJzcDsgfCBNUExTJm5ic3A7Jm5ic3A7Jm5ic3A7 IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAuIC4gLnwmbmJzcDsgZm9vJm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L2Rpdj4NCjxkaXY+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfHN1YiB0ZWNoIHwmbmJzcDsmbmJz cDsgfHN1YiB0ZWNoIHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8c3ViIHRl Y2ggfDwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+VGhlIGV4YW1wbGUgZ2l2ZW4gYnkg QWNlZSBpcyB0byBwcm92aWRlIGEgbGlzdCBvZiBPQU0gcHJvdG9jb2xzIHdoaWNoIG5lZWQgdG8g YmUgcmVhZHkgdG8gY29uZmlndXJlIGEgbmV0d29yayBpbnN0YW5jZS4gVGhlcmUgaXMgbm8gb3Zl cmxhcHBpbmcuPC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7 PC9mb250PjwvZGl2Pg0KPGRpdj4tUWluPC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IuWui+S9kyI+ 5Y+R5Lu25Lq6PGZvbnQgZmFjZT0iQ2FsaWJyaSI+OiBuZXRtb2QgWzxhIGhyZWY9Im1haWx0bzpu ZXRtb2QtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnPC9h Pl0gPC9mb250PuS7o+ihqDxmb250IGZhY2U9IkNhbGlicmkiPiBNYWhlc2ggSmV0aGFuYW5kYW5p PC9mb250PjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0i5a6L5L2TIj7lj5HpgIHml7bp l7Q8Zm9udCBmYWNlPSJDYWxpYnJpIj46IDIwMTU8L2ZvbnQ+5bm0PGZvbnQgZmFjZT0iQ2FsaWJy aSI+ODwvZm9udD7mnIg8Zm9udCBmYWNlPSJDYWxpYnJpIj4yOTwvZm9udD7ml6U8Zm9udCBmYWNl PSJDYWxpYnJpIj4gNzo0NDwvZm9udD48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IuWu i+S9kyI+5pS25Lu25Lq6PGZvbnQgZmFjZT0iQ2FsaWJyaSI+OiBBY2VlIExpbmRlbSAoYWNlZSk8 L2ZvbnQ+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSLlrovkvZMiPuaKhOmAgTxmb250 IGZhY2U9IkNhbGlicmkiPjogbmV0bW9kQGlldGYub3JnPC9mb250PjwvZm9udD48L2Rpdj4NCjxk aXY+PGZvbnQgZmFjZT0i5a6L5L2TIj7kuLvpopg8Zm9udCBmYWNlPSJDYWxpYnJpIj46IFJlOiBb bmV0bW9kXSBNb3RpdmF0aW9ucyBmb3IgU3RydWN0dXJpbmcgTW9kZWxzPC9mb250PjwvZm9udD48 L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PkFjZWUsPC9kaXY+DQo8ZGl2PiZuYnNwOzwv ZGl2Pg0KPGRpdj5UaGlzIGlzIGdvaW5nIHRvIGJlY29tZSB2ZXJ5IGludGVyZXN0aW5nIHZlcnkg cXVpY2tseS4gUm91dGluZyBEVCBoYXMgZGVjaWRlZCB0byBkZWZpbmUgYSBjb250YWluZXIgZm9y IG9hbS1wcm90b2NvbHMuIExJTUUgaGFzIGRlY2lkZWQgaXQgd2FudHMgdG8gZGVmaW5lIGEgZ2Vu ZXJpYyBZQU5HIG1vZHVsZSBmb3IgYWxsIE9BTSBpbiBkcmFmdC10aXNzYS1saW1lLXlhbmctb2Ft LW1vZGVsLjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+V2hpY2ggbW9kZWwgZG9lcyBC RkQgYXVnbWVudD8gT3IgZGlkIHlvdSBqdXN0IGtpbGwgdGhlIHdob2xlIGNoYXJ0ZXIgZm9yIExJ TUU/PzwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+T24gQXVnIDI4LCAyMDE1LCBhdCA2 OjIwIEFNLCBBY2VlIExpbmRlbSAoYWNlZSkgJmx0O2FjZWVAY2lzY28uY29tJmd0OyB3cm90ZTo8 L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PldoeSBkb2Vzbjxmb250IGZhY2U9IkNvdXJp ZXIgTmV3Ij7igJk8L2ZvbnQ+dCBpdCBoZWxwPyBJbiB0aGUgbmV4dCByZXZpc2lvbiBvZiB0aGUg Um91dGluZyBZQU5HIERUIG1vZGVsLDwvZGl2Pg0KPGRpdj53ZTxmb250IGZhY2U9IkNvdXJpZXIg TmV3Ij7igJk8L2ZvbnQ+dmUgc3dpdGNoZWQgZnJvbSBpbmNsdWRpbmcgc3BlY2lmaWMgbW9kZWxz IHRvIGRlZmluaW5nIGNsYXNzZXMgb2Y8L2Rpdj4NCjxkaXY+bW9kZWxzIHdpdGggaWRlbnRpdGll cy4gRm9yIGV4YW1wbGUsPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5ncm91cGluZyBv YW0tcHJvdG9jb2xzIHs8L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmllciBOZXciPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxmb250IGZhY2U9IkNhbGlicmkiPmNvbnRhaW5lciBv YW0tcHJvdG9jb2xzIHs8L2ZvbnQ+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3Vy aWVyIE5ldyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7PGZvbnQgZmFjZT0iQ2FsaWJyaSI+bGlzdCBvYW0tcHJvdG9jb2wgezwvZm9udD48L2Zv bnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDs8Zm9udCBmYWNlPSJDYWxpYnJpIj5rZXkgJnF1b3Q7dHlwZSZxdW90Ozs8L2ZvbnQ+PC9m b250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7PGZvbnQgZmFjZT0iQ2FsaWJyaSI+bGVhZiB0eXBlIHs8L2ZvbnQ+PC9mb250PjwvZGl2 Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGZvbnQgZmFjZT0iQ2FsaWJyaSI+dHlwZSBpZGVudGl0eXJl ZiB7PC9mb250PjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmllciBOZXciPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOzxmb250IGZhY2U9IkNhbGlicmkiPmJhc2Ugb2FtLXByb3RvY29sLXR5cGU7PC9m b250PjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO308L2ZvbnQ+PC9kaXY+DQo8ZGl2 Pjxmb250IGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs8Zm9udCBmYWNlPSJDYWxpYnJpIj5tYW5kYXRvcnkgdHJ1ZTs8L2ZvbnQ+ PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGZvbnQgZmFjZT0iQ2FsaWJyaSI+ZGVz Y3JpcHRpb248L2ZvbnQ+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3VyaWVyIE5l dyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7PGZvbnQgZmFjZT0iQ2FsaWJyaSI+JnF1b3Q7VGhlIE9wZXJhdGlvbnMs IEFkbWluaXN0cmF0aW9uLCBhbmQ8L2ZvbnQ+PC9mb250PjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rp dj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs8Zm9udCBmYWNlPSJDYWxpYnJpIj5NYWludGVuYW5jZSAoT0FNKSBwcm90 b2NvbCB0eXBlLCBlLmcuLCBCRkQsPC9mb250PjwvZm9udD48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9k aXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7PGZvbnQgZmFjZT0iQ2FsaWJyaSI+VFdBTVAsIENGTSwgZXRjLiZxdW90 Ozs8L2ZvbnQ+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7fTwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmll ciBOZXciPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxmb250IGZhY2U9IkNhbGlicmkiPmRlc2NyaXB0 aW9uPC9mb250PjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmllciBOZXciPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxmb250IGZhY2U9IkNh bGlicmkiPiZxdW90O0xpc3Qgb2YgT0FNIHByb3RvY29scyBjb25maWd1cmVkIGZvciBhPC9mb250 PjwvZm9udD48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRp dj48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGZvbnQgZmFjZT0iQ2FsaWJyaSI+bmV0d29ya2luZyBpbnN0 YW5jZS4mcXVvdDs7PC9mb250PjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmll ciBOZXciPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwO308L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8Zm9udCBmYWNl PSJDYWxpYnJpIj5kZXNjcmlwdGlvbjwvZm9udD48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZh Y2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8Zm9udCBmYWNlPSJDYWxpYnJp Ij4mcXVvdDtDb250YWluZXIgZm9yIGxpc3Qgb2YgT0FNIHByb3RvY29scyBjb25maWd1cmVkIGZv ciBhPC9mb250PjwvZm9udD48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZuYnNwOzwv ZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7PGZvbnQgZmFjZT0iQ2FsaWJyaSI+bmV0d29ya2luZyBpbnN0YW5jZS4mcXVv dDs7PC9mb250PjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmllciBOZXciPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO308L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZh Y2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8Zm9udCBmYWNl PSJDYWxpYnJpIj5kZXNjcmlwdGlvbjwvZm9udD48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZh Y2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs8Zm9udCBmYWNlPSJDYWxpYnJpIj4mcXVvdDtHcm91cGluZyBmb3IgT0FN IHByb3RvY29scyBjb25maWd1cmVkIGZvciBhPC9mb250PjwvZm9udD48L2Rpdj4NCjxkaXY+Jm5i c3A7PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3VyaWVyIE5l dyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7PGZvbnQgZmFjZT0iQ2FsaWJyaSI+bmV0d29ya2luZyBpbnN0YW5jZS4mcXVvdDs7PC9m b250PjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmllciBOZXciPiZuYnNwO308 L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDs8L2ZvbnQ+ PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDs8L2ZvbnQ+PC9kaXY+ DQo8ZGl2PlRoZW4gdGhlIGdyb3VwaW5nIGlzIGluY2x1ZGUgdGhlIG5ldHdvcmtpbmctaW5zdGFu Y2VzLiA8Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7PC9mb250PkJ5IGRvaW5nIHRoaXMs IHRoZTwvZGl2Pg0KPGRpdj5pbnRlbnQgaXMgdGhhdCBpdCB3b3VsZCBiZSBldmlkZW50IGFzIHRv IHdoZXJlIGEgcGFydGljdWxhciBtb2RlbCB3b3VsZCBiZTwvZGl2Pg0KPGRpdj5mb3VuZC48Zm9u dCBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD48L2Rpdj4NCjxkaXY+TWFoZXNoIEpldGhh bmFuZGFuaTwvZGl2Pg0KPGRpdj5tamV0aGFuYW5kYW5pQGdtYWlsLmNvbTwvZGl2Pg0KPGRpdj4m bmJzcDs8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj48 Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD48L2Rpdj4NCjxkaXY+PGZv bnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+PC9kaXY+DQo8L3NwYW4+PC9m b250Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_B8F9A780D330094D99AF023C5877DABA848150C0nkgeml501mbschi_-- From nobody Fri Aug 28 19:12:02 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7F431B3841 for ; Fri, 28 Aug 2015 19:12:00 -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 K0hlFRGoQVWY for ; Fri, 28 Aug 2015 19:11:59 -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 F37241B3A41 for ; Fri, 28 Aug 2015 19:11:57 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CAN92956; Sat, 29 Aug 2015 02:11:56 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sat, 29 Aug 2015 03:11:55 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.99]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0235.001; Sat, 29 Aug 2015 10:11:50 +0800 From: Qin Wu To: "Acee Lindem (acee)" , Martin Bjorklund Thread-Topic: [netmod] Motivations for Structuring Models Thread-Index: AQHQ4NBOADFMJ24pqkmio9Q4U/+UL54fggqAgAAU4ACAACMmAIAADoUAgACmsgCAAGQvAIAABoMAgAAG/YCAAAEJgIAAATkAgAFYzNA= Date: Sat, 29 Aug 2015 02:11:49 +0000 Message-ID: References: <55E054DC.7050906@rob.sh> <20150828.145546.1509142825487206251.mbj@tail-f.com> <20150828.152429.253858432985165209.mbj@tail-f.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Motivations for Structuring Models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2015 02:12:00 -0000 SGksDQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6IG5ldG1vZCBbbWFpbHRvOm5l dG1vZC1ib3VuY2VzQGlldGYub3JnXSDku6PooaggQWNlZSBMaW5kZW0gKGFjZWUpDQrlj5HpgIHm l7bpl7Q6IDIwMTXlubQ45pyIMjjml6UgMjE6MjkNCuaUtuS7tuS6ujogTWFydGluIEJqb3JrbHVu ZA0K5oqE6YCBOiBuZXRtb2RAaWV0Zi5vcmcNCuS4u+mimDogUmU6IFtuZXRtb2RdIE1vdGl2YXRp b25zIGZvciBTdHJ1Y3R1cmluZyBNb2RlbHMNCg0KDQoNCk9uIDgvMjgvMTUsIDk6MjQgQU0sICJN YXJ0aW4gQmpvcmtsdW5kIiA8bWJqQHRhaWwtZi5jb20+IHdyb3RlOg0KDQo+IkFjZWUgTGluZGVt IChhY2VlKSIgPGFjZWVAY2lzY28uY29tPiB3cm90ZToNCj4+IA0KPj4gDQo+PiBPbiA4LzI4LzE1 LCA4OjU1IEFNLCAibmV0bW9kIG9uIGJlaGFsZiBvZiBNYXJ0aW4gQmpvcmtsdW5kIg0KPj4gPG5l dG1vZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBtYmpAdGFpbC1mLmNvbT4gd3JvdGU6 DQo+PiANCj4+ID5Sb2IgU2hha2lyIDxyanNAcm9iLnNoPiB3cm90ZToNCj4+ID4+IA0KPj4gPj4g SGkgTWFydGluLA0KPj4gPj4gDQo+PiA+PiBUaGFua3MgZm9yIHRoZSByZXBseS4NCj4+ID4+ID4g TWFydGluIEJqb3JrbHVuZCA8bWFpbHRvOm1iakB0YWlsLWYuY29tPiBBdWd1c3QgMjgsIDIwMTUg YXQgDQo+PiA+PiA+IDAyOjMzIFNvIHRoZSBpZGVhIGlzIHRoYXQgdGhpcyBzdHJ1Y3R1cmUgaXMg ZGVmaW5lZCBpbiBvbmUgDQo+PiA+PiA+IG1vZHVsZSwgaWV0Zi1zb21ldGhpbmctc3RydWN0dXJl LCByaWdodD8NCj4+ID4+ID4NCj4+ID4+ID4gQW5kIHRoZW4gZGlmZmVyZW50IG9hbSBwcm90b2Nv bCBtb2R1bGVzIGF1Z21lbnQgdGhpcyBzdHJ1Y3R1cmU/DQo+PiA+PiA+DQo+PiA+PiA+IEhvdyBk b2VzIHRoaXMgaGVscCB5b3UgZmluZCB0aGUgbW9kdWxlcyB0aGF0IGF1Z21lbnQgdGhpcw0KPj5z dHJ1Y3R1cmU/DQo+PiA+PiBZZXMsIHRoaXMgaXMgdGhlIGludGVudGlvbi4gQnkgdGhlbiBnZW5l cmF0aW5nIHRoZSB0cmVlIG9mIHRoZQ0KPj5vdmVyYWxsDQo+PiA+PiBzdHJ1Y3R1cmUsIHRoZW4g SSBjYW4gc2VlIHdoYXQgZGlmZmVyZW50IGNvbnRhaW5lcnMgYXJlIGNyZWF0ZWQgDQo+PiA+PiB0 aGVyZS4gSXQncyBub3QgcGVyZmVjdCAoYW5kIGhleSwgdGhpcyBzdWdnZXN0aW9uIGlzIGEgKmRy YWZ0KiBmb3IgDQo+PiA+PiBhIHJlYXNvbiAtIGJ1dCB5ZXQgYWdhaW4sIHRoZXJlIGFyZSBub3Qg YWx0ZXJuYXRpdmVzKSAtIGJ1dCB0aGUgDQo+PiA+PiBmYWN0IHRoYXQgdGhlIG1vZHVsZXMgYXVn bWVudCBhIGNvbW1vbiBwYXRoIGFkZHMgc29tZSBpbmZvcm1hdGlvbiANCj4+ID4+IHRoYXQNCj4+ dGhleQ0KPj4gPj4gYXJlIGdyb3VwZWQgdG8gcHJvdmlkaW5nIHRoZSBzYW1lIGZ1bmN0aW9uYWxp dHksIG5vdCBkaXNwYXJhdGUuIA0KPj4gPj4gaWV0Zi1yb3V0aW5nIGRvZXMgdGhlIHNhbWUgdGhp bmcsIGl0IGdpdmVzIG1lIHRoZSBmYWN0DQo+PnRoYXQNCj4+ID4+IGF0IC9yb3V0aW5nL3JvdXRp bmctaW5zdGFuY2Uvcm91dGluZy1wcm90b2NvbHMgdGhlcmUgYXJlIGEgYnVuY2ggDQo+PiA+PiBv ZiBjb250cm9sLXBsYW5lIHByb3RvY29scyB0aGF0IGFyZSByZWxhdGVkIHRvIHJvdXRpbmcuDQo+ PiA+DQo+PiA+T2suICBTbyB5b3VyIHByb3Bvc2FsIGRvZXNuJ3QgaGVscCB3aXRoIHRoZSBwcm9i bGVtIG9mIGxvY2F0aW5nIA0KPj4gPnJlbGV2YW50IFlBTkcgbW9kdWxlcywgYnV0IG9uY2UgdGhl aXIgbG9jYXRlZCwgaXQgaXMgZWFzaWVyIHRvIGZpbmQgDQo+PiA+dGhlIG9uZXMgcmVsYXRlZCB0 byBhIHNwZWNpZmljIGZ1bmN0aW9uLCBiL2MgdGhleSB3b3VsZCBhdWdtZW50IGEgDQo+PiA+Y29t bW9uIHBhdGguICBJcyB0aGlzIHdoYXQgeW91IG1lYW4/DQo+PiANCj4+IFdoeSBkb2VzbuKAmXQg aXQgaGVscD8gSW4gdGhlIG5leHQgcmV2aXNpb24gb2YgdGhlIFJvdXRpbmcgWUFORyBEVCANCj4+ IG1vZGVsLCB3ZeKAmXZlIHN3aXRjaGVkIGZyb20gaW5jbHVkaW5nIHNwZWNpZmljIG1vZGVscyB0 byBkZWZpbmluZyANCj4+IGNsYXNzZXMgb2YgbW9kZWxzIHdpdGggaWRlbnRpdGllcy4gRm9yIGV4 YW1wbGUsDQo+PiANCj4+ICBncm91cGluZyBvYW0tcHJvdG9jb2xzIHsNCj4+ICAgICAgIGNvbnRh aW5lciBvYW0tcHJvdG9jb2xzIHsNCj4+ICAgICAgICAgICBsaXN0IG9hbS1wcm90b2NvbCB7DQo+ PiAgICAgICAgICAgICAgIGtleSAidHlwZSI7DQo+PiAgICAgICAgICAgICAgIGxlYWYgdHlwZSB7 DQo+PiAgICAgICAgICAgICAgICAgICB0eXBlIGlkZW50aXR5cmVmIHsNCj4+ICAgICAgICAgICAg ICAgICAgICAgICBiYXNlIG9hbS1wcm90b2NvbC10eXBlOw0KPj4gICAgICAgICAgICAgICAgICAg fQ0KPj4gICAgICAgICAgICAgICAgICAgbWFuZGF0b3J5IHRydWU7DQo+PiAgICAgICAgICAgICAg ICAgICBkZXNjcmlwdGlvbg0KPj4gICAgICAgICAgICAgICAgICAgICAgICJUaGUgT3BlcmF0aW9u cywgQWRtaW5pc3RyYXRpb24sIGFuZA0KPj4gICAgICAgICAgICAgICAgIA0KPj4gICAgICAgICAg ICAgICAgIA0KPj4gICAgICAgICAgICAgICAgICAgICAgICBNYWludGVuYW5jZSAoT0FNKSBwcm90 b2NvbCB0eXBlLCBlLmcuLCBCRkQsDQo+PiAgICAgICAgICAgICAgICAgDQo+PiAgICAgICAgICAg ICAgICAgDQo+PiAgICAgICAgICAgICAgICAgICAgICAgIFRXQU1QLCBDRk0sIGV0Yy4iOw0KPj4g ICAgICAgICAgICAgICB9DQo+PiAgICAgICAgICAgICAgIGRlc2NyaXB0aW9uDQo+PiAgICAgICAg ICAgICAgICAgICAiTGlzdCBvZiBPQU0gcHJvdG9jb2xzIGNvbmZpZ3VyZWQgZm9yIGENCj4+ICAg ICAgICAgICAgICAgICANCj4+ICAgICAgICAgICAgICAgICANCj4+ICAgICAgICAgICAgICAgICAg ICBuZXR3b3JraW5nIGluc3RhbmNlLiI7DQo+PiAgICAgICAgICAgfQ0KPj4gICAgICAgICAgIGRl c2NyaXB0aW9uDQo+PiAgICAgICAgICAgICAgICJDb250YWluZXIgZm9yIGxpc3Qgb2YgT0FNIHBy b3RvY29scyBjb25maWd1cmVkIGZvciBhDQo+PiAgICAgICAgICAgICAgICAgDQo+PiAgICAgICAg ICAgICAgICAgDQo+PiAgICAgICAgICAgICAgICAgbmV0d29ya2luZyBpbnN0YW5jZS4iOw0KPj4g ICAgICAgfQ0KPj4gICAgICAgZGVzY3JpcHRpb24NCj4+ICAgICAgICAgICAiR3JvdXBpbmcgZm9y IE9BTSBwcm90b2NvbHMgY29uZmlndXJlZCBmb3IgYQ0KPj4gICAgICAgICAgICAgICAgIA0KPj4g ICAgICAgICAgICAgICAgIA0KPj4gICAgICAgICAgICBuZXR3b3JraW5nIGluc3RhbmNlLiI7DQo+ PiAgIH0NCj4+IA0KPj4gDQo+PiBUaGVuIHRoZSBncm91cGluZyBpcyBpbmNsdWRlIHRoZSBuZXR3 b3JraW5nLWluc3RhbmNlcy4gIEJ5IGRvaW5nIA0KPj50aGlzLCB0aGUgIGludGVudCBpcyB0aGF0 IGl0IHdvdWxkIGJlIGV2aWRlbnQgYXMgdG8gd2hlcmUgYSBwYXJ0aWN1bGFyIA0KPj5tb2RlbCB3 b3VsZCBiZSAgZm91bmQuDQo+DQo+Tm93IEkgYW0gYSB1c2VyIG9mIFlBTkcgbW9kZWxzLiAgSSBh bSBzZWFyY2hpbmcgZm9yIHRoZSBZQU5HIG1vZHVsZSANCj50aGF0IGRlZmluZXMgT0FNIGZvciBC RkQuICBIb3cgZG9lcyB5b3VyIG1vZGVsIGFib3ZlIGhlbHAgbWUgZmluZCBpdD8NCg0KSWYgb25l IGNhbiBlbnZpc2lvbiBhIGZ1bmN0aW9uIHRvIGxpc3QgdGhlIHNjaGVtYSByYXRoZXIgdGhhbiB0 aGUgYWN0dWFsIGNvbmZpZyBkYXRhLCB5b3UgY291bGQgcmV0cmlldmUgdGhlIHNjaGVtYSBmb3Ig dGhlIG9hbS1wcm90b2NvbHMgY29udGFpbmVyLiBJdCB3b3VsZCBzZWVtIHJlYXNvbmFibGUgdG8g c3VwcG9ydCBzdWNoIGEgZnVuY3Rpb24uDQoNCltRaW5dOiBTb3JyeSB0byBjaGltZSBpbiwgVG8g YmUgaG9uZXN0LCBJIHRoaW5rIHRoZSBhYm92ZSBleGFtcGxlIGdpdmVzIGEgbGlzdCBvZiBPQU0g cHJvdG9jb2wgbW9kZWxzIHdlIGNhbiBpZGVudGlmeSBhbmQgYnV0IGRvZXNuJ3QgcHJvdmlkZSBy ZWxhdGlvbnNoaXAgYW1vbmcgdGhlc2UgT0FNIHJlbGF0ZWQgbW9kZWxzLCBlLmcuLCB3aGljaCBt b2RlbCBpcyBhIGJhc2ljIG1vZGVsLCB3aGljaCBtb2RlbCBpcyBleHRlbnNpb24gdG8gYmFzaWMg bW9kZWwuIEZpZ3VyZSAxIG9mIGRyYWZ0LXRpc3NhLWxpbWUteWFuZy1vYW0tbW9kZWwtMDYgcHJv dmlkZXMgc3VjaCByZWxhdGlvbnNoaXAganVzdCBsaWtlIHdoYXQgZHJhZnQtaWV0Zi1uZXRtb2Qt cm91dGluZy1jZmctMTkgZGlkLCBpZXRmLXJvdXRpbmcgaXMgYSBiYXNpYyBtb2RlbCwgaWV0Zi1p cHY0LXVuaWNhc3Qtcm91dGluZyBhbmQgaWV0Zi1pcHY2LXVuaWNhc3Qtcm91dGluZyBhcmUgdHdv IGV4YW1wbGUgb2YgbW9kZWwgZXh0ZW5zaW9uIHRvIGlldGYtcm91dGluZy4NCg0KVGhhbmtzLA0K QWNlZQ0KDQoNCj4NCj4NCj4vbWFydGluDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRtb2RAaWV0Zi5vcmcN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo= From nobody Sat Aug 29 12:09:01 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0FBD1B3913 for ; Sat, 29 Aug 2015 12:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1b1RbAml0gz8 for ; Sat, 29 Aug 2015 12:08:58 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 808A11ACD3F for ; Sat, 29 Aug 2015 12:08:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Vnmet9Vbqi2mIiTxGkBD+OR+WMc8BXpD+QA3sd5VqaX1BR1WpaxbKCq2AQGdxUAz; 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.24] (helo=mswamui-andean.atl.sa.earthlink.net) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1ZVlUi-0002JZ-H9 for netmod@ietf.org; Sat, 29 Aug 2015 15:08:52 -0400 Received: from 76.254.48.232 by webmail.earthlink.net with HTTP; Sat, 29 Aug 2015 15:08:51 -0400 Message-ID: <8207307.1440875332299.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> Date: Sat, 29 Aug 2015 15:08:52 -0400 (EDT) From: Randy Presuhn To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88874d3f0892ff6d3ed40841192e4f3542da4d19c6f390151f4350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.24 Archived-At: Subject: Re: [netmod] Motivations for Structuring Models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2015 19:09:00 -0000 Hi - It is with no little amusement that I watch this thread struggling with questions that were solved fairly neatly a quarter century ago in GDMO/CMIP-land. I'm *not* suggesting we go back there, but would like to offer an observation about modeling that might help. The organization of instance data in SNMP is a direct mirror of the "object" definitions. Simple at first, but quickly becoming baroque as various minds of "multiplexing" are added to compensate for post hoc deficiencies in the index structures. Life is such that once a resource has been modeled, it will be used/re-used/embedded in systems in ways in which its designers couldn't be expected to imagine. A consequence of this is that if instance naming is completely locked down when the management interface for a resource is first defined (as it is in SNMP) then all sorts of peculiar hacks will be needed to deal with, for example, virtual routers. Unfortunately, an SNMP/SMI-like mindset is so pervasive that folks seem to overlook that there are other ways to deal with this situation. What GDMO did was to use a separate "NAME BINDING" construct to specify contexts in which instances might show up, allowing instances to be put in places that weren't even imagined when the original class definition was written. Name bindings could be standardized, or be vendor or even product-specific, allowing the simplicity or complexity of a given system's instance tree to reflect the actual simplicity or complexity of that system, rather than requiring all systems to be structured for the worst case. Yes, separating the specification of instance naming in large part from class definition does have implications for how one does access control, and how clients figure out how to ask a server to create something, but it's not a huge deal - it's just not like VACM, and a whole slew of hacky solutions and "wierd plumbing adapters" (to borrow from Jeff Case) just go away. Strangely, it makes the job of the initial modeler and of the eventual user much easier. Randy From nobody Mon Aug 31 06:48:31 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF0EC1B3615 for ; Mon, 31 Aug 2015 06:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.21 X-Spam-Level: X-Spam-Status: No, score=-6.21 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 ztGNgow8YT4P for ; Mon, 31 Aug 2015 06:48:27 -0700 (PDT) Received: from sjmda09.webex.com (sjmda09.webex.com [64.68.122.166]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8A221B2BE8 for ; Mon, 31 Aug 2015 06:48:27 -0700 (PDT) Received: from jva2tc214.webex.com (sjc02-wxp00-lbace03-core-vl120-np10b-2.webex.com [64.68.121.237]) by sjmda09.webex.com (Postfix) with ESMTP id 68B94224CC for ; Mon, 31 Aug 2015 13:48:27 +0000 (GMT) Received: from jva2tc214.webex.com (localhost [127.0.0.1]) by jva2tc214.webex.com (Postfix) with ESMTP id 1F4D6200E5 for ; Mon, 31 Aug 2015 13:48:27 +0000 (GMT) Date: Mon, 31 Aug 2015 13:48:27 +0000 (GMT) From: NETMOD Working Group To: netmod@ietf.org Message-ID: <1089246557.1411.1441028907126.JavaMail.nobody@jva2tc214.webex.com> MIME-Version: 1.0 Content-Type: multipart/Mixed; boundary="----=_Part_1409_747909790.1441028907125" X-Priority: 3 Importance: normal Archived-At: Subject: [netmod] WebEx meeting invitation: NETMOD YANG 1.1 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: netmod-chairs@tools.ietf.org List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 13:48:30 -0000 ------=_Part_1409_747909790.1441028907125 Content-Type: multipart/Alternative; boundary="----=_Part_1410_898054639.1441028907125" ------=_Part_1410_898054639.1441028907125 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: base64 CkhlbGxvLAoKTkVUTU9EIFdvcmtpbmcgR3JvdXAgaW52aXRlcyB5b3UgdG8gam9pbiB0aGlzIFdl YkV4IG1lZXRpbmcuCgoKTkVUTU9EIFlBTkcgMS4xCk1vbmRheSwgQXVndXN0IDMxLCAyMDE1CjQ6 MDAgcG0gIHwgIEV1cm9wZSBTdW1tZXIgVGltZSAoQmVybGluLCBHTVQrMDI6MDApICB8ICAxIGhy CgoKSk9JTiBXRUJFWCBNRUVUSU5HCmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9N VElEPW0xMGVjOGFhYmVmMThkMTc5NzdmZWM4ZTI0MWQ0NTU1MwpNZWV0aW5nIG51bWJlcjogNjQ3 IDU4NiA2OTAKTWVldGluZyBwYXNzd29yZDogYmVpemFpMlUKCg0KSk9JTiBCWSBQSE9ORQ0KMS04 NzctNjY4LTQ0OTMgQ2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChVUy9DYW5hZGEpIAoxLTY1MC00 NzktMzIwOCBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpCkFjY2VzcyBjb2RlOiA2NDcg NTg2IDY5MAoKVG9sbC1mcmVlIGRpYWxpbmcgcmVzdHJpY3Rpb25zOiAKaHR0cDovL3d3dy53ZWJl eC5jb20vcGRmL3RvbGxmcmVlX3Jlc3RyaWN0aW9ucy5wZGYNCg0KCkFkZCB0aGlzIG1lZXRpbmcg dG8geW91ciBjYWxlbmRhcjoKaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9 bWRmMjRiZGQ0ZDRmNmNiY2U1MjA0M2Y1OTk1Mjg4MDJmDQoNCgpDYW4ndCBqb2luIHRoZSBtZWV0 aW5nPyBDb250YWN0IHN1cHBvcnQgaGVyZToKaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL21j CgoKSU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZpY2Ug YWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lv biB0byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1h dHRlci4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQg dG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3Jk ZWQsIGRpc2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRo ZSBzZXNzaW9uLgo= ------=_Part_1410_898054639.1441028907125 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPjxtZXRhIG5hbWU9InZpZXdwb3J0IiBjb250ZW50PSJ3aWR0aD1kZXZpY2Utd2lk dGgsIGluaXRpYWwtc2NhbGU9MSIgLz48Ym9keT48c3R5bGUgdHlwZT0idGV4dC9jc3MiPgpkaXYs cCx0ZCxzcGFuIHt3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7d29yZC1icmVhazogbm9ybWFsO30KCnRh YmxlIHtib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyBib3JkZXI6IDA7Ym9yZGVyLXNwYWNpbmc6 IDA7Ym9yZGVyLWNvbG9yOiB3aGl0ZTsgd2lkdGg6MTAwJSFpbXBvcnRhbnQ7d2lkdGg6NTI1cHg7 IG1heC13aWR0aDo1MjVweCFpbXBvcnRhbnQ7IG1pbi13aWR0aDogMjc5cHghaW1wb3J0YW50O30K dHIge2xpbmUtaGVpZ2h0OiAyMHB4O30KCnRkLGEge2ZvbnQtc2l6ZTogMTVweDtmb250LWZhbWls eTogQXJpYWw7Y29sb3I6ICM2NjY2NjY7cGFkZGluZzowO30KPC9zdHlsZT4KCjx0YWJsZSBzdHls ZT0icGFkZGluZzowOyBtYXJnaW46MCIgd2lkdGg9IjEwMCUiIGFsaWduPSJsZWZ0Ij4KICAgPHRy PgogICAgICA8dGQgc3R5bGU9InBhZGRpbmctdG9wOjVweDsiPgogICAgICAgIDx0YWJsZSBzdHls ZT0id2lkdGg6IDUyNXB4O21hcmdpbi1sZWZ0OjVweCIgYWxpZ249ImxlZnQiPgoJCQk8dHI+CgkJ CQk8dGQgdmFsaWduPSJ0b3AiPgoKPHRhYmxlPgogICAgICAgPHRyPgogICAgICAgICAgPHRkIHN0 eWxlPSJmb250LXNpemU6IDE1cHg7Zm9udC1mYW1pbHk6IEFyaWFsO2NvbG9yOiM0RDRENEQiPgog ICAgICAgICAgICAgSGVsbG8sCiAgICAgICAgICA8L3RkPgogICAgICAgPC90cj4KICAgICAgIDx0 cj4KICAgICAgICAgICA8dGQgc3R5bGU9ImZvbnQtc2l6ZTogMTVweDtmb250LWZhbWlseTogQXJp YWw7Y29sb3I6IzRENEQ0RDtwYWRkaW5nLXRvcDoxMHB4OyI+CiAgICAgICAgICAgICAgICBORVRN T0QgV29ya2luZyBHcm91cCBpbnZpdGVzIHlvdSB0byBqb2luIHRoaXMgV2ViRXggbWVldGluZy4K ICAgICAgICAgICAgICAgIAkgICAgICAgICAgIDwvdGQ+CiAgICAgIDwvdHI+CjwvdGFibGU+CgoK Cgo8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0 OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPgoJCQkJCQk8dGFibGUgIHdpZHRoPSIxMDAl Ij4KCQkJCQkJCTx0cj4KCQkJCQkJCQk8dGQgc3R5bGU9ImZvbnQtc2l6ZToxNnB4OyBjb2xvcjoj NEQ0RDREIj4KCQkJCQkJCQkJPGI+TkVUTU9EIFlBTkcgMS4xPC9iPgoJCQkJCQkJCTwvdGQ+CgkJ CQkJCQk8L3RyPgoJCQkJCQkJPHRyIHN0eWxlPSJtYXJnaW46MHB4Ij4KCQkJCQkJCQk8dGQ+TW9u ZGF5LCBBdWd1c3QgMzEsIDIwMTUKCQkJCQkJCQk8L3RkPgoJCQkJCQkJPC90cj4KCQkJCQkJCTx0 ciBzdHlsZT0ibWFyZ2luOjBweCI+CgkJCQkJCQkJPHRkPjQ6MDAgcG0mbmJzcDsmbmJzcDt8Jm5i c3A7Jm5ic3A7RXVyb3BlIFN1bW1lciBUaW1lIChCZXJsaW4sIEdNVCswMjowMCkmbmJzcDsmbmJz cDt8Jm5ic3A7Jm5ic3A7MSBocgoJCQkJCQkJCTwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJCQk8L3Rh YmxlPgoKPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9Imhl aWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KCQkJCQkJPHRhYmxlIHN0eWxlPSJ3 aWR0aDphdXRvOyB3aWR0aDphdXRvIWltcG9ydGFudCI+CgkJCQkJCQk8dHI+CgkJCQkJCQkJPHRk IHN0eWxlPSJjb2xvcjojMDBBRkY5O2ZvbnQtc2l6ZToxNnB4Ij4KCQkJCQkJCQkJPGEgaHJlZj0i aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTEwZWM4YWFiZWYxOGQxNzk3 N2ZlYzhlMjQxZDQ1NTUzIgoJCQkJCQkJCQkJc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2Zv bnQtc2l6ZToxNnB4O2NvbG9yOiMwMEFGRjkiPgoJCQkJCQkJCQkJPGI+Sm9pbiBXZWJFeCBtZWV0 aW5nPC9iPgoJCQkJCQkJCQk8L2E+CgkJCQkJCQkJPC90ZD4KCQkJCQkJCTwvdHI+CgkJCQkJCTwv dGFibGU+CgkJCQkJCTx0YWJsZSBzdHlsZT0id2lkdGg6YXV0bzsgd2lkdGg6YXV0byFpbXBvcnRh bnQiPgoJCQkJCQkJPHRyIHN0eWxlPSJtYXJnaW46MHB4Ij4KCQkJCQkJCQk8dGQgc3R5bGU9InBh ZGRpbmctcmlnaHQ6IDVweDsiPgoJCQkJCQkJCQlNZWV0aW5nIG51bWJlcjoKCQkJCQkJCQk8L3Rk PgoJCQkJCQkJCTx0ZD42NDcgNTg2IDY5MAoJCQkJCQkJCTwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJ CQkJPHRyPgoJCQkJCQkJCTx0ZCBzdHlsZT0icGFkZGluZy1yaWdodDogNXB4OyI+TWVldGluZyBw YXNzd29yZDo8L3RkPgoJCQkJCQkJCTx0ZD5iZWl6YWkyVTwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJ CQk8L3RhYmxlPgoKCgoJCgoJPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6MjBweCI+PHRk IHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+PHRhYmxlPjx0cj48 dGQgc3R5bGU9ImZvbnQtc2l6ZToxNnB4Ij48Yj5Kb2luIGJ5IHBob25lPC9iPjwvdGQ+PC90cj48 dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZD48Yj4xLTg3Ny02NjgtNDQ5MzwvYj4mbmJzcDtDYWxs LWluIHRvbGwgZnJlZSBudW1iZXIgKFVTL0NhbmFkYSk8L3RkPjwvdHI+PHRyIHN0eWxlPSJtYXJn aW46MHB4Ij48dGQ+PGI+MS02NTAtNDc5LTMyMDg8L2I+Jm5ic3A7Q2FsbC1pbiB0b2xsIG51bWJl ciAoVVMvQ2FuYWRhKTwvdGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZD5BY2Nlc3Mg Y29kZTombmJzcDs2NDcgNTg2IDY5MDwvdGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0 ZD48YSBocmVmPSJodHRwOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25z LnBkZiIgc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2ZvbnQtc2l6ZToxM3B4O2NvbG9yOiMw MEFGRjk7Ij5Ub2xsLWZyZWUgY2FsbGluZyByZXN0cmljdGlvbnM8L2E+PC90ZD48L3RyPjwvdGFi bGU+CgoJCQkJCTx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OjIwcHgiPjx0ZCBzdHlsZT0i aGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPjx0YWJsZT48dHI+PHRkIHN0eWxl PSJmb250LXNpemU6MTNweCI+PGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2ou cGhwP01USUQ9bWRmMjRiZGQ0ZDRmNmNiY2U1MjA0M2Y1OTk1Mjg4MDJmIiBzdHlsZT0idGV4dC1k ZWNvcmF0aW9uOm5vbmU7Y29sb3I6IzAwQUZGOTsgZm9udC1zaXplOjEzcHgiPkFkZCB0aGlzIG1l ZXRpbmc8L2E+IHRvIHlvdXIgY2FsZW5kYXIuPC90ZD48L3RyPjwvdGFibGU+Cjx0YWJsZT48dHIg c3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7 PC90ZD48L3RyPjwvdGFibGU+Cjx0YWJsZT4KICAgIDx0cj4KICAgICAgIDx0ZCBzdHlsZT0iZm9u dC1zaXplOiAxM3B4O2ZvbnQtZmFtaWx5OiBBcmlhbDtjb2xvcjogIzY2NjY2NjsiPgogICAgICAg IENhbid0IGpvaW4gdGhlIG1lZXRpbmc/CiAgICAgCTxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJl eC5jb20vaWV0Zi9tYyIgc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2ZvbnQtc2l6ZToxM3B4 O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOiMwMEFGRjk7Zm9udC1jb2xvcjojMDBBRkY5OyI+CiAg ICAgICAgCUNvbnRhY3Qgc3VwcG9ydC48L2E+CgkJPC90ZD4KICAgIDwvdHI+CjwvdGFibGU+Cjx0 YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAxMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MTBw eCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+CgkJCQkJCTx0YWJsZT4KCQkJCQkJCTx0cj4KCQkJ CQkJCQk8dGQgc3R5bGU9ImZvbnQtc2l6ZToxMnB4O2NvbG9yOiAjQTBBMEEwOyI+CgkJCQkJCQkJ CUlNUE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJFeCBzZXJ2aWNlIGFs bG93cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24g dG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0 ZXIuIEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRv IHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVk LCBkaXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUg c2Vzc2lvbi48L3RkPgoJCQkJCQkJPC90cj4KCQkJCQkJPC90YWJsZT4KCQkJCTwvdGQ+CgkJCTwv dHI+CgkJPC90YWJsZT4KCTwvdGQ+CiAgIDwvdHI+CjwvdGFibGU+Cgo8L2JvZHk+ ------=_Part_1410_898054639.1441028907125-- ------=_Part_1409_747909790.1441028907125 Content-Type: application/octet-stream; name="WebEx_Meeting.ics" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="WebEx_Meeting.ics" QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP TkUKVFpJRDpFdXJvcGUgVGltZQpCRUdJTjpTVEFOREFSRApEVFNUQVJUOjIwMTMxMDAxVDAzMDAw MApSUlVMRTpGUkVRPVlFQVJMWTtJTlRFUlZBTD0xO0JZREFZPS0xU1U7QllNT05USD0xMApUWk9G RlNFVEZST006KzAyMDAKVFpPRkZTRVRUTzorMDEwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDEzMDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0tMVNVO0JZTU9OVEg9MwpUWk9GRlNFVEZST006KzAx MDAKVFpPRkZTRVRUTzorMDIwMApUWk5BTUU6RGF5bGlnaHQgU2F2aW5ncyBUaW1lCkVORDpEQVlM SUdIVApFTkQ6VlRJTUVaT05FCkJFR0lOOlZFVkVOVApBVFRFTkRFRTtDTj0iIjtST0xFPVJFUS1Q QVJUSUNJUEFOVDtSU1ZQPVRSVUU6TUFJTFRPOm5ldG1vZEBpZXRmLm9yZwpPUkdBTklaRVI7Q049 Ik5FVE1PRCBXb3JraW5nIEdyb3VwIjpNQUlMVE86bmV0bW9kLWNoYWlyc0B0b29scy5pZXRmLm9y ZwpEVFNUQVJUO1RaSUQ9IkV1cm9wZSBUaW1lIjoyMDE1MDgzMVQxNjAwMDAKRFRFTkQ7VFpJRD0i RXVyb3BlIFRpbWUiOjIwMTUwODMxVDE3MDAwMApMT0NBVElPTjpodHRwczovL2lldGYud2ViZXgu Y29tL2lldGYKVFJBTlNQOk9QQVFVRQpTRVFVRU5DRToxNDQxMDI4OTA3ClVJRDowMTNmNzRkNS0x ZjE3LTRmOTUtYmE1Mi04ZjEzZThjMGMwMjkKRFRTVEFNUDoyMDE1MDgzMVQxNDAwMDBaCkRFU0NS SVBUSU9OOlxuXG5cbkpPSU4gV0VCRVggTUVFVElOR1xuaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9p ZXRmL2oucGhwP01USUQ9bWRmOTM2YTA4NzU4OGY2OTNhMjhiODQ5Mzk0NjVhMzFhXG5NZWV0aW5n IG51bWJlcjogNjQ3IDU4NiA2OTBcbk1lZXRpbmcgcGFzc3dvcmQ6IGJlaXphaTJVXG5cblxuSk9J TiBCWSBQSE9ORVxuMS04NzctNjY4LTQ0OTMgQ2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChVUy9D YW5hZGEpIFxuMS02NTAtNDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKVxu QWNjZXNzIGNvZGU6IDY0NyA1ODYgNjkwXG5cblRvbGwtZnJlZSBkaWFsaW5nIHJlc3RyaWN0aW9u czogXG5odHRwOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBkZlxu XG5cblxuQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz8gQ29udGFjdCBzdXBwb3J0IGhlcmU6XG5odHRw czovL2lldGYud2ViZXguY29tL2lldGYvbWNcblxuXG5JTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ug bm90ZSB0aGF0IHRoaXMgV2ViRXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9y bWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkg YmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lv biwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBk byBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdp dGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uXG4KWC1BTFQtREVTQztGTVRU WVBFPXRleHQvaHRtbDoJPEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxCUj4gPEZP TlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPgkJPGEJCQkJCWhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJl eC5jb20vaWV0Zi9qLnBocD9NVElEPW1kZjkzNmEwODc1ODhmNjkzYTI4Yjg0OTM5NDY1YTMxYSI+ PEZPTlQgU0laRT0iMyIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9IkFyaWFsIj5Kb2luIFdlYkV4IG1l ZXRpbmc8L0ZPTlQ+PC9hPgkJCTx0YWJsZT4JCQkJPHRyPgkJCQkJPHRkPgkJCQkJCTxGT05UIFNJ WkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBudW1iZXI6PC9GT05U PgkJCQkJPC90ZD4JCQkJCTx0ZD4JCQkJCQk8Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIg RkFDRT0iYXJpYWwiPjY0NyA1ODYgNjkwPC9GT05UPgkJCQkJPC90ZD4JCQkJPC90cj4JCQk8L3Rh YmxlPgkJCTx0YWJsZT48dHI+PHRkPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNF PSJhcmlhbCI+TWVldGluZyBwYXNzd29yZDo8L0ZPTlQ+PC90ZD48dGQ+PEZPTlQgU0laRT0iMiIg IENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+YmVpemFpMlU8L0ZPTlQ+PC90ZD48L3RyPjwv dGFibGU+CQk8L0ZPTlQ+PEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxCUj4mbmJz cDs8QlI+PC9GT05UPjxGT05UIFNJWkU9IjQiIEZBQ0U9IkFSSUFMIj48Rk9OVCBTSVpFPSIzIiBD T0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPkpvaW4gYnkgcGhvbmU8L0ZPTlQ+Jm5ic3A7IDxC Uj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjxzdHJvbmc+MS04 NzctNjY4LTQ0OTM8L3N0cm9uZz4mbmJzcDtDYWxsLWluIHRvbGwgZnJlZSBudW1iZXIgKFVTL0Nh bmFkYSk8L0ZPTlQ+Jm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFD RT0iYXJpYWwiPjxzdHJvbmc+MS02NTAtNDc5LTMyMDg8L3N0cm9uZz4mbmJzcDtDYWxsLWluIHRv bGwgbnVtYmVyIChVUy9DYW5hZGEpPC9GT05UPiZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09M T1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5BY2Nlc3MgY29kZTogNjQ3IDU4NiA2OTA8L0ZPTlQ+ Jm5ic3A7IDxCUj48YSBocmVmPSJodHRwOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVz dHJpY3Rpb25zLnBkZiI+PEZPTlQgU0laRT0iMSIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9ImFyaWFs Ij5Ub2xsLWZyZWUgY2FsbGluZyByZXN0cmljdGlvbnM8L0ZPTlQ+PC9hPiAmbmJzcDsgPEJSPjwv Rk9OVD48QlI+PEJSPgkmbmJzcDs8QlI+CTxGT05UIFNJWkU9IjEiIENPTE9SPSIjNjY2NjY2IiBG QUNFPSJhcmlhbCI+CQkJCUNhbid0IGpvaW4gdGhlIG1lZXRpbmc/PC9GT05UPgk8YSBocmVmPSJo dHRwczovL2lldGYud2ViZXguY29tL2lldGYvbWMiPgk8Rk9OVCBTSVpFPSIxIiBDT0xPUj0iIzAw QUZGOSIgRkFDRT0iQXJpYWwiPkNvbnRhY3Qgc3VwcG9ydC48L0ZPTlQ+PC9hPgkmbmJzcDs8QlI+ Jm5ic3A7PEJSPjxGT05UIENPTE9SPSIjQTBBMEEwIiBzaXplPSIxIiBGQUNFPSJhcmlhbCI+SU1Q T1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxsb3dz IGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBi ZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4g Qnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3Vj aCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRp c2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNz aW9uLjwvRk9OVD48L0ZPTlQ+ClNVTU1BUlk6TkVUTU9EIFlBTkcgMS4xClBSSU9SSVRZOjUKQ0xB U1M6UFVCTElDCkVORDpWRVZFTlQKRU5EOlZDQUxFTkRBUgo= ------=_Part_1409_747909790.1441028907125-- From nobody Mon Aug 31 06:51:58 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE0C51B4530 for ; Mon, 31 Aug 2015 06:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.859 X-Spam-Level: X-Spam-Status: No, score=-5.859 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQiwvsrsmzuR for ; Mon, 31 Aug 2015 06:51:53 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D8D41B451C for ; Mon, 31 Aug 2015 06:51:53 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A734793D; Mon, 31 Aug 2015 15:51:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 6r6vUfdQYCVp; Mon, 31 Aug 2015 15:51:50 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 31 Aug 2015 15:51:50 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5CF4020053; Mon, 31 Aug 2015 15:51:50 +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 IOewSocQT2Dt; Mon, 31 Aug 2015 15:51:49 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9959D2004E; Mon, 31 Aug 2015 15:51:48 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4106C365C28E; Mon, 31 Aug 2015 15:51:45 +0200 (CEST) Date: Mon, 31 Aug 2015 15:51:44 +0200 From: Juergen Schoenwaelder To: netmod-chairs@tools.ietf.org Message-ID: <20150831135144.GA97455@elstar.local> Mail-Followup-To: netmod-chairs@tools.ietf.org, netmod@ietf.org References: <1089246557.1411.1441028907126.JavaMail.nobody@jva2tc214.webex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1089246557.1411.1441028907126.JavaMail.nobody@jva2tc214.webex.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] WebEx meeting invitation: NETMOD YANG 1.1 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 13:51:57 -0000 Hi, we will use this etherpad to take notes: http://etherpad.tools.ietf.org:9000/p/notes-ietf-netmod-virtual-interim-2015-08-31?useMonospaceFont=true Talk to you later. /js On Mon, Aug 31, 2015 at 01:48:27PM +0000, NETMOD Working Group wrote: > > Hello, > > NETMOD Working Group invites you to join this WebEx meeting. > > > NETMOD YANG 1.1 > Monday, August 31, 2015 > 4:00 pm | Europe Summer Time (Berlin, GMT+02:00) | 1 hr > > > JOIN WEBEX MEETING > https://ietf.webex.com/ietf/j.php?MTID=m10ec8aabef18d17977fec8e241d45553 > Meeting number: 647 586 690 > Meeting password: beizai2U > > > 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: 647 586 690 > > Toll-free dialing restrictions: > http://www.webex.com/pdf/tollfree_restrictions.pdf > > > Add this meeting to your calendar: > https://ietf.webex.com/ietf/j.php?MTID=mdf24bdd4d4f6cbce52043f599528802f > > > Can't join the meeting? Contact support here: > https://ietf.webex.com/ietf/mc > > > IMPORTANT NOTICE: Please note that this WebEx service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session. > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Aug 31 07:07:57 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F01B01AD066 for ; Mon, 31 Aug 2015 07:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.661 X-Spam-Level: X-Spam-Status: No, score=-2.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, 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 7Iu7s573rafK for ; Mon, 31 Aug 2015 07:07:53 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 385121B45A8 for ; Mon, 31 Aug 2015 07:07:43 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:95a8:aacf:3cc9:37b9] (unknown [IPv6:2001:718:1a02:1:95a8:aacf:3cc9:37b9]) by mail.nic.cz (Postfix) with ESMTPSA id D7201181718; Mon, 31 Aug 2015 16:07:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1441030061; bh=Cww2eUwZ/xXKciJZokOuJ6GzAjZAD7zxIC+FY8EMiBg=; h=From:Date:To; b=U3o1MLp1DVA+WxbkylRi4eMZ8D08vFeK6898qzlR+cSaHnAB7F/q4+epboMPJbkpJ hjldH4oAVhv4YEvJkGLctPUeYlgpu2SKSuupWDBwrwuFROxZ4+ODOtKu42/vcp0zdA 4YPAzUpw65VTI0JGGDe8P5pl+icu5OHCe36M0mpQ= Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka X-Priority: 3 In-Reply-To: <1089246557.1411.1441028907126.JavaMail.nobody@jva2tc214.webex.com> Date: Mon, 31 Aug 2015 16:07:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1089246557.1411.1441028907126.JavaMail.nobody@jva2tc214.webex.com> To: netmod-chairs@tools.ietf.org X-Mailer: Apple Mail (2.2102) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] WebEx meeting invitation: NETMOD YANG 1.1 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 14:07:56 -0000 Hi, the invitation has 4:00 pm CEST as the start time. It seems it should be = 5:00 pm CEST. Lada > On 31 Aug 2015, at 15:48, NETMOD Working Group = wrote: >=20 > Hello, > NETMOD Working Group invites you to join this WebEx meeting. > =20 > NETMOD YANG 1.1 > Monday, August 31, 2015 > 4:00 pm | Europe Summer Time (Berlin, GMT+02:00) | 1 hr > =20 > Join WebEx meeting > Meeting number: 647 586 690 > Meeting password: beizai2U > =20 > Join by phone > 1-877-668-4493 Call-in toll free number (US/Canada) > 1-650-479-3208 Call-in toll number (US/Canada) > Access code: 647 586 690 > Toll-free calling restrictions > =20 > Add this meeting to your calendar. > =20 > Can't join the meeting? Contact support. > =20 > IMPORTANT NOTICE: Please note that this WebEx service allows audio and = other information sent during the session to be recorded, which may be = discoverable in a legal matter. By joining this session, you = automatically consent to such recordings. If you do not consent to being = recorded, discuss your concerns with the host or do not join the = session. > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Aug 31 07:11:38 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 603221B49C3 for ; Mon, 31 Aug 2015 07:11:36 -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 sFzmJ_sn9NoZ for ; Mon, 31 Aug 2015 07:11:34 -0700 (PDT) Received: from sjmda12.webex.com (sjmda12.webex.com [64.68.124.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BED341B49C4 for ; Mon, 31 Aug 2015 07:11:34 -0700 (PDT) Received: from jva2tc214.webex.com (sjc02-wxp00-lbace03-core-vl120-np10b-2.webex.com [64.68.121.237]) by sjmda12.webex.com (Postfix) with ESMTP id 798DF2DE2 for ; Mon, 31 Aug 2015 14:11:34 +0000 (GMT) Received: from jva2tc214.webex.com (localhost [127.0.0.1]) by jva2tc214.webex.com (Postfix) with ESMTP id 382E2200E5 for ; Mon, 31 Aug 2015 14:11:34 +0000 (GMT) Date: Mon, 31 Aug 2015 14:11:34 +0000 (GMT) From: NETMOD Working Group To: netmod@ietf.org Message-ID: <843599367.1612.1441030294228.JavaMail.nobody@jva2tc214.webex.com> MIME-Version: 1.0 Content-Type: multipart/Mixed; boundary="----=_Part_1610_1049055008.1441030294227" X-Priority: 3 Importance: normal Archived-At: Subject: [netmod] WebEx meeting rescheduled: NETMOD YANG 1.1 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: netmod-chairs@tools.ietf.org List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 14:11:36 -0000 ------=_Part_1610_1049055008.1441030294227 Content-Type: multipart/Alternative; boundary="----=_Part_1611_626777586.1441030294227" ------=_Part_1611_626777586.1441030294227 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: base64 CkhlbGxvLAoKTkVUTU9EIFdvcmtpbmcgR3JvdXAgY2hhbmdlZCB0aGUgdGltZSBmb3IgdGhpcyBX ZWJFeCBtZWV0aW5nLgoKCk5FVE1PRCBZQU5HIDEuMQpNb25kYXksIEF1Z3VzdCAzMSwgMjAxNQo1 OjAwIHBtICB8ICBFdXJvcGUgU3VtbWVyIFRpbWUgKEJlcmxpbiwgR01UKzAyOjAwKSAgfCAgMSBo cgoKCkpPSU4gV0VCRVggTUVFVElORwpodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/ TVRJRD1tMTBlYzhhYWJlZjE4ZDE3OTc3ZmVjOGUyNDFkNDU1NTMKTWVldGluZyBudW1iZXI6IDY0 NyA1ODYgNjkwCk1lZXRpbmcgcGFzc3dvcmQ6IGJlaXphaTJVCgoNCkpPSU4gQlkgUEhPTkUNCjEt ODc3LTY2OC00NDkzIENhbGwtaW4gdG9sbCBmcmVlIG51bWJlciAoVVMvQ2FuYWRhKSAKMS02NTAt NDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKQpBY2Nlc3MgY29kZTogNjQ3 IDU4NiA2OTAKClRvbGwtZnJlZSBkaWFsaW5nIHJlc3RyaWN0aW9uczogCmh0dHA6Ly93d3cud2Vi ZXguY29tL3BkZi90b2xsZnJlZV9yZXN0cmljdGlvbnMucGRmDQoNCgpBZGQgdGhpcyBtZWV0aW5n IHRvIHlvdXIgY2FsZW5kYXI6Cmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElE PW1kYzdkNTgzYmI2YzdhOTJkYTFiYjAzODczNmYwY2NlOA0KDQoKQ2FuJ3Qgam9pbiB0aGUgbWVl dGluZz8gQ29udGFjdCBzdXBwb3J0IGhlcmU6Cmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9t YwoKCklNUE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJFeCBzZXJ2aWNl IGFsbG93cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Np b24gdG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBt YXR0ZXIuIEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50 IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29y ZGVkLCBkaXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0 aGUgc2Vzc2lvbi4K ------=_Part_1611_626777586.1441030294227 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPjxtZXRhIG5hbWU9InZpZXdwb3J0IiBjb250ZW50PSJ3aWR0aD1kZXZpY2Utd2lk dGgsIGluaXRpYWwtc2NhbGU9MSIgLz48Ym9keT48c3R5bGUgdHlwZT0idGV4dC9jc3MiPgpkaXYs cCx0ZCxzcGFuIHt3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7d29yZC1icmVhazogbm9ybWFsO30KCnRh YmxlIHtib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyBib3JkZXI6IDA7Ym9yZGVyLXNwYWNpbmc6 IDA7Ym9yZGVyLWNvbG9yOiB3aGl0ZTsgd2lkdGg6MTAwJSFpbXBvcnRhbnQ7d2lkdGg6NTI1cHg7 IG1heC13aWR0aDo1MjVweCFpbXBvcnRhbnQ7IG1pbi13aWR0aDogMjc5cHghaW1wb3J0YW50O30K dHIge2xpbmUtaGVpZ2h0OiAyMHB4O30KCnRkLGEge2ZvbnQtc2l6ZTogMTVweDtmb250LWZhbWls eTogQXJpYWw7Y29sb3I6ICM2NjY2NjY7cGFkZGluZzowO30KPC9zdHlsZT4KCjx0YWJsZSBzdHls ZT0icGFkZGluZzowOyBtYXJnaW46MCIgd2lkdGg9IjEwMCUiIGFsaWduPSJsZWZ0Ij4KICAgPHRy PgogICAgICA8dGQgc3R5bGU9InBhZGRpbmctdG9wOjVweDsiPgogICAgICAgIDx0YWJsZSBzdHls ZT0id2lkdGg6IDUyNXB4O21hcmdpbi1sZWZ0OjVweCIgYWxpZ249ImxlZnQiPgoJCQk8dHI+CgkJ CQk8dGQgdmFsaWduPSJ0b3AiPgoKPHRhYmxlPgogICAgICAgPHRyPgogICAgICAgICAgPHRkIHN0 eWxlPSJmb250LXNpemU6IDE1cHg7Zm9udC1mYW1pbHk6IEFyaWFsO2NvbG9yOiM0RDRENEQiPgog ICAgICAgICAgICAgSGVsbG8sCiAgICAgICAgICA8L3RkPgogICAgICAgPC90cj4KICAgICAgIDx0 cj4KICAgICAgICAgICA8dGQgc3R5bGU9ImZvbnQtc2l6ZTogMTVweDtmb250LWZhbWlseTogQXJp YWw7Y29sb3I6IzRENEQ0RDtwYWRkaW5nLXRvcDoxMHB4OyI+CiAgICAgICAgICAgICAgICBORVRN T0QgV29ya2luZyBHcm91cCBjaGFuZ2VkIHRoZSB0aW1lIGZvciB0aGlzIFdlYkV4IG1lZXRpbmcu CiAgICAgICAgICAgICAgICAJICAgICAgICAgICA8L3RkPgogICAgICA8L3RyPgo8L3RhYmxlPgoK CgoKPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdo dDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KCQkJCQkJPHRhYmxlICB3aWR0aD0iMTAw JSI+CgkJCQkJCQk8dHI+CgkJCQkJCQkJPHRkIHN0eWxlPSJmb250LXNpemU6MTZweDsgY29sb3I6 IzRENEQ0RCI+CgkJCQkJCQkJCTxiPk5FVE1PRCBZQU5HIDEuMTwvYj4KCQkJCQkJCQk8L3RkPgoJ CQkJCQkJPC90cj4KCQkJCQkJCTx0ciBzdHlsZT0ibWFyZ2luOjBweCI+CgkJCQkJCQkJPHRkPk1v bmRheSwgQXVndXN0IDMxLCAyMDE1CgkJCQkJCQkJPC90ZD4KCQkJCQkJCTwvdHI+CgkJCQkJCQk8 dHIgc3R5bGU9Im1hcmdpbjowcHgiPgoJCQkJCQkJCTx0ZD41OjAwIHBtJm5ic3A7Jm5ic3A7fCZu YnNwOyZuYnNwO0V1cm9wZSBTdW1tZXIgVGltZSAoQmVybGluLCBHTVQrMDI6MDApJm5ic3A7Jm5i c3A7fCZuYnNwOyZuYnNwOzEgaHIKCQkJCQkJCQk8L3RkPgoJCQkJCQkJPC90cj4KCQkJCQkJPC90 YWJsZT4KCjx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJo ZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+CgkJCQkJCTx0YWJsZSBzdHlsZT0i d2lkdGg6YXV0bzsgd2lkdGg6YXV0byFpbXBvcnRhbnQiPgoJCQkJCQkJPHRyPgoJCQkJCQkJCTx0 ZCBzdHlsZT0iY29sb3I6IzAwQUZGOTtmb250LXNpemU6MTZweCI+CgkJCQkJCQkJCTxhIGhyZWY9 Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW0xMGVjOGFhYmVmMThkMTc5 NzdmZWM4ZTI0MWQ0NTU1MyIKCQkJCQkJCQkJCXN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZTtm b250LXNpemU6MTZweDtjb2xvcjojMDBBRkY5Ij4KCQkJCQkJCQkJCTxiPkpvaW4gV2ViRXggbWVl dGluZzwvYj4KCQkJCQkJCQkJPC9hPgoJCQkJCQkJCTwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJCQk8 L3RhYmxlPgoJCQkJCQk8dGFibGUgc3R5bGU9IndpZHRoOmF1dG87IHdpZHRoOmF1dG8haW1wb3J0 YW50Ij4KCQkJCQkJCTx0ciBzdHlsZT0ibWFyZ2luOjBweCI+CgkJCQkJCQkJPHRkIHN0eWxlPSJw YWRkaW5nLXJpZ2h0OiA1cHg7Ij4KCQkJCQkJCQkJTWVldGluZyBudW1iZXI6CgkJCQkJCQkJPC90 ZD4KCQkJCQkJCQk8dGQ+NjQ3IDU4NiA2OTAKCQkJCQkJCQk8L3RkPgoJCQkJCQkJPC90cj4KCQkJ CQkJCTx0cj4KCQkJCQkJCQk8dGQgc3R5bGU9InBhZGRpbmctcmlnaHQ6IDVweDsiPk1lZXRpbmcg cGFzc3dvcmQ6PC90ZD4KCQkJCQkJCQk8dGQ+YmVpemFpMlU8L3RkPgoJCQkJCQkJPC90cj4KCQkJ CQkJPC90YWJsZT4KCgoKCQoKCTx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OjIwcHgiPjx0 ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPjx0YWJsZT48dHI+ PHRkIHN0eWxlPSJmb250LXNpemU6MTZweCI+PGI+Sm9pbiBieSBwaG9uZTwvYj48L3RkPjwvdHI+ PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij48dGQ+PGI+MS04NzctNjY4LTQ0OTM8L2I+Jm5ic3A7Q2Fs bC1pbiB0b2xsIGZyZWUgbnVtYmVyIChVUy9DYW5hZGEpPC90ZD48L3RyPjx0ciBzdHlsZT0ibWFy Z2luOjBweCI+PHRkPjxiPjEtNjUwLTQ3OS0zMjA4PC9iPiZuYnNwO0NhbGwtaW4gdG9sbCBudW1i ZXIgKFVTL0NhbmFkYSk8L3RkPjwvdHI+PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij48dGQ+QWNjZXNz IGNvZGU6Jm5ic3A7NjQ3IDU4NiA2OTA8L3RkPjwvdHI+PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij48 dGQ+PGEgaHJlZj0iaHR0cDovL3d3dy53ZWJleC5jb20vcGRmL3RvbGxmcmVlX3Jlc3RyaWN0aW9u cy5wZGYiIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZTtmb250LXNpemU6MTNweDtjb2xvcjoj MDBBRkY5OyI+VG9sbC1mcmVlIGNhbGxpbmcgcmVzdHJpY3Rpb25zPC9hPjwvdGQ+PC90cj48L3Rh YmxlPgoKCQkJCQk8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDoyMHB4Ij48dGQgc3R5bGU9 ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT48dGFibGU+PHRyPjx0ZCBzdHls ZT0iZm9udC1zaXplOjEzcHgiPjxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9q LnBocD9NVElEPW1kYzdkNTgzYmI2YzdhOTJkYTFiYjAzODczNmYwY2NlOCIgc3R5bGU9InRleHQt ZGVjb3JhdGlvbjpub25lO2NvbG9yOiMwMEFGRjk7IGZvbnQtc2l6ZToxM3B4Ij5BZGQgdGhpcyBt ZWV0aW5nPC9hPiB0byB5b3VyIGNhbGVuZGFyLjwvdGQ+PC90cj48L3RhYmxlPgo8dGFibGU+PHRy IHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNw OzwvdGQ+PC90cj48L3RhYmxlPgo8dGFibGU+CiAgICA8dHI+CiAgICAgICA8dGQgc3R5bGU9ImZv bnQtc2l6ZTogMTNweDtmb250LWZhbWlseTogQXJpYWw7Y29sb3I6ICM2NjY2NjY7Ij4KICAgICAg ICBDYW4ndCBqb2luIHRoZSBtZWV0aW5nPwogICAgIAk8YSBocmVmPSJodHRwczovL2lldGYud2Vi ZXguY29tL2lldGYvbWMiIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZTtmb250LXNpemU6MTNw eDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjojMDBBRkY5O2ZvbnQtY29sb3I6IzAwQUZGOTsiPgog ICAgICAgIAlDb250YWN0IHN1cHBvcnQuPC9hPgoJCTwvdGQ+CiAgICA8L3RyPgo8L3RhYmxlPgo8 dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMTBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjEw cHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPgoJCQkJCQk8dGFibGU+CgkJCQkJCQk8dHI+CgkJ CQkJCQkJPHRkIHN0eWxlPSJmb250LXNpemU6MTJweDtjb2xvcjogI0EwQTBBMDsiPgoJCQkJCQkJ CQlJTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViRXggc2VydmljZSBh bGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9u IHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0 dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0 byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRl ZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhl IHNlc3Npb24uPC90ZD4KCQkJCQkJCTwvdHI+CgkJCQkJCTwvdGFibGU+CgkJCQk8L3RkPgoJCQk8 L3RyPgoJCTwvdGFibGU+Cgk8L3RkPgogICA8L3RyPgo8L3RhYmxlPgoKPC9ib2R5Pg== ------=_Part_1611_626777586.1441030294227-- ------=_Part_1610_1049055008.1441030294227 Content-Type: application/octet-stream; name="WebEx_Meeting.ics" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="WebEx_Meeting.ics" QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP TkUKVFpJRDpFdXJvcGUgVGltZQpCRUdJTjpTVEFOREFSRApEVFNUQVJUOjIwMTMxMDAxVDAzMDAw MApSUlVMRTpGUkVRPVlFQVJMWTtJTlRFUlZBTD0xO0JZREFZPS0xU1U7QllNT05USD0xMApUWk9G RlNFVEZST006KzAyMDAKVFpPRkZTRVRUTzorMDEwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDEzMDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0tMVNVO0JZTU9OVEg9MwpUWk9GRlNFVEZST006KzAx MDAKVFpPRkZTRVRUTzorMDIwMApUWk5BTUU6RGF5bGlnaHQgU2F2aW5ncyBUaW1lCkVORDpEQVlM SUdIVApFTkQ6VlRJTUVaT05FCkJFR0lOOlZFVkVOVApBVFRFTkRFRTtDTj0iIjtST0xFPVJFUS1Q QVJUSUNJUEFOVDtSU1ZQPVRSVUU6TUFJTFRPOm5ldG1vZEBpZXRmLm9yZwpPUkdBTklaRVI7Q049 Ik5FVE1PRCBXb3JraW5nIEdyb3VwIjpNQUlMVE86bmV0bW9kLWNoYWlyc0B0b29scy5pZXRmLm9y ZwpEVFNUQVJUO1RaSUQ9IkV1cm9wZSBUaW1lIjoyMDE1MDgzMVQxNzAwMDAKRFRFTkQ7VFpJRD0i RXVyb3BlIFRpbWUiOjIwMTUwODMxVDE4MDAwMApMT0NBVElPTjpodHRwczovL2lldGYud2ViZXgu Y29tL2lldGYKVFJBTlNQOk9QQVFVRQpTRVFVRU5DRToxNDQxMDMwMjk0ClVJRDowMTNmNzRkNS0x ZjE3LTRmOTUtYmE1Mi04ZjEzZThjMGMwMjkKRFRTVEFNUDoyMDE1MDgzMVQxNTAwMDBaCkRFU0NS SVBUSU9OOlxuXG5cbkpPSU4gV0VCRVggTUVFVElOR1xuaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9p ZXRmL2oucGhwP01USUQ9bWRmOTM2YTA4NzU4OGY2OTNhMjhiODQ5Mzk0NjVhMzFhXG5NZWV0aW5n IG51bWJlcjogNjQ3IDU4NiA2OTBcbk1lZXRpbmcgcGFzc3dvcmQ6IGJlaXphaTJVXG5cblxuSk9J TiBCWSBQSE9ORVxuMS04NzctNjY4LTQ0OTMgQ2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChVUy9D YW5hZGEpIFxuMS02NTAtNDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKVxu QWNjZXNzIGNvZGU6IDY0NyA1ODYgNjkwXG5cblRvbGwtZnJlZSBkaWFsaW5nIHJlc3RyaWN0aW9u czogXG5odHRwOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBkZlxu XG5cblxuQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz8gQ29udGFjdCBzdXBwb3J0IGhlcmU6XG5odHRw czovL2lldGYud2ViZXguY29tL2lldGYvbWNcblxuXG5JTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ug bm90ZSB0aGF0IHRoaXMgV2ViRXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9y bWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkg YmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lv biwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBk byBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdp dGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uXG4KWC1BTFQtREVTQztGTVRU WVBFPXRleHQvaHRtbDoJPEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxCUj4gPEZP TlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPgkJPGEJCQkJCWhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJl eC5jb20vaWV0Zi9qLnBocD9NVElEPW1kZjkzNmEwODc1ODhmNjkzYTI4Yjg0OTM5NDY1YTMxYSI+ PEZPTlQgU0laRT0iMyIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9IkFyaWFsIj5Kb2luIFdlYkV4IG1l ZXRpbmc8L0ZPTlQ+PC9hPgkJCTx0YWJsZT4JCQkJPHRyPgkJCQkJPHRkPgkJCQkJCTxGT05UIFNJ WkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBudW1iZXI6PC9GT05U PgkJCQkJPC90ZD4JCQkJCTx0ZD4JCQkJCQk8Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIg RkFDRT0iYXJpYWwiPjY0NyA1ODYgNjkwPC9GT05UPgkJCQkJPC90ZD4JCQkJPC90cj4JCQk8L3Rh YmxlPgkJCTx0YWJsZT48dHI+PHRkPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNF PSJhcmlhbCI+TWVldGluZyBwYXNzd29yZDo8L0ZPTlQ+PC90ZD48dGQ+PEZPTlQgU0laRT0iMiIg IENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+YmVpemFpMlU8L0ZPTlQ+PC90ZD48L3RyPjwv dGFibGU+CQk8L0ZPTlQ+PEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxCUj4mbmJz cDs8QlI+PC9GT05UPjxGT05UIFNJWkU9IjQiIEZBQ0U9IkFSSUFMIj48Rk9OVCBTSVpFPSIzIiBD T0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPkpvaW4gYnkgcGhvbmU8L0ZPTlQ+Jm5ic3A7IDxC Uj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjxzdHJvbmc+MS04 NzctNjY4LTQ0OTM8L3N0cm9uZz4mbmJzcDtDYWxsLWluIHRvbGwgZnJlZSBudW1iZXIgKFVTL0Nh bmFkYSk8L0ZPTlQ+Jm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFD RT0iYXJpYWwiPjxzdHJvbmc+MS02NTAtNDc5LTMyMDg8L3N0cm9uZz4mbmJzcDtDYWxsLWluIHRv bGwgbnVtYmVyIChVUy9DYW5hZGEpPC9GT05UPiZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09M T1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5BY2Nlc3MgY29kZTogNjQ3IDU4NiA2OTA8L0ZPTlQ+ Jm5ic3A7IDxCUj48YSBocmVmPSJodHRwOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVz dHJpY3Rpb25zLnBkZiI+PEZPTlQgU0laRT0iMSIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9ImFyaWFs Ij5Ub2xsLWZyZWUgY2FsbGluZyByZXN0cmljdGlvbnM8L0ZPTlQ+PC9hPiAmbmJzcDsgPEJSPjwv Rk9OVD48QlI+PEJSPgkmbmJzcDs8QlI+CTxGT05UIFNJWkU9IjEiIENPTE9SPSIjNjY2NjY2IiBG QUNFPSJhcmlhbCI+CQkJCUNhbid0IGpvaW4gdGhlIG1lZXRpbmc/PC9GT05UPgk8YSBocmVmPSJo dHRwczovL2lldGYud2ViZXguY29tL2lldGYvbWMiPgk8Rk9OVCBTSVpFPSIxIiBDT0xPUj0iIzAw QUZGOSIgRkFDRT0iQXJpYWwiPkNvbnRhY3Qgc3VwcG9ydC48L0ZPTlQ+PC9hPgkmbmJzcDs8QlI+ Jm5ic3A7PEJSPjxGT05UIENPTE9SPSIjQTBBMEEwIiBzaXplPSIxIiBGQUNFPSJhcmlhbCI+SU1Q T1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxsb3dz IGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBi ZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4g Qnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3Vj aCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRp c2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNz aW9uLjwvRk9OVD48L0ZPTlQ+ClNVTU1BUlk6TkVUTU9EIFlBTkcgMS4xClBSSU9SSVRZOjUKQ0xB U1M6UFVCTElDCkVORDpWRVZFTlQKRU5EOlZDQUxFTkRBUgo= ------=_Part_1610_1049055008.1441030294227-- From nobody Mon Aug 31 07:12:05 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB701B414E for ; Mon, 31 Aug 2015 07:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.86 X-Spam-Level: X-Spam-Status: No, score=-5.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q12LGPJwuOx3 for ; Mon, 31 Aug 2015 07:12: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 378C21B475E for ; Mon, 31 Aug 2015 07:12: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 0168C129D; Mon, 31 Aug 2015 16:12: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 t-lBtIcwOuFI; Mon, 31 Aug 2015 16:11:59 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 31 Aug 2015 16:11:59 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4B9922004E; Mon, 31 Aug 2015 16:11:59 +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 Ahya6IrGykzn; Mon, 31 Aug 2015 16:11:58 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4708D20048; Mon, 31 Aug 2015 16:11:58 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id F3EEE365C314; Mon, 31 Aug 2015 16:11:53 +0200 (CEST) Date: Mon, 31 Aug 2015 16:11:53 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20150831141153.GA97524@elstar.local> Mail-Followup-To: Ladislav Lhotka , netmod-chairs@tools.ietf.org, netmod@ietf.org References: <1089246557.1411.1441028907126.JavaMail.nobody@jva2tc214.webex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod-chairs@tools.ietf.org, netmod@ietf.org Subject: Re: [netmod] WebEx meeting invitation: NETMOD YANG 1.1 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 14:12:03 -0000 On Mon, Aug 31, 2015 at 04:07:42PM +0200, Ladislav Lhotka wrote: > Hi, > > the invitation has 4:00 pm CEST as the start time. It seems it should be 5:00 pm CEST. > Oops. I will try to get it fixed... /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 Aug 31 08:04:49 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB351B4DC0 for ; Mon, 31 Aug 2015 08:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.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 9-ctj5J_80or for ; Mon, 31 Aug 2015 08:04:45 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 14BCE1B4DBC for ; Mon, 31 Aug 2015 08:04:45 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id EF5571CC0369; Mon, 31 Aug 2015 17:04:43 +0200 (CEST) From: Ladislav Lhotka To: Randy Presuhn , netmod@ietf.org In-Reply-To: <8207307.1440875332299.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> References: <8207307.1440875332299.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Mon, 31 Aug 2015 17:04:42 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] Motivations for Structuring Models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 15:04:49 -0000 Randy Presuhn writes: > Hi - > > It is with no little amusement that I watch this thread struggling > with questions that were solved fairly neatly a quarter century ago > in GDMO/CMIP-land. I'm *not* suggesting we go back there, but would > like to offer an observation about modeling that might help. > > The organization of instance data in SNMP is a direct mirror of > the "object" definitions. Simple at first, but quickly becoming > baroque as various minds of "multiplexing" are added to compensate > for post hoc deficiencies in the index structures. > > Life is such that once a resource has been modeled, it will be > used/re-used/embedded in systems in ways in which its designers > couldn't be expected to imagine. A consequence of this is that > if instance naming is completely locked down when the management > interface for a resource is first defined (as it is in SNMP) then > all sorts of peculiar hacks will be needed to deal with, for example, > virtual routers. Unfortunately, an SNMP/SMI-like mindset is so > pervasive that folks seem to overlook that there are other ways > to deal with this situation. > > What GDMO did was to use a separate "NAME BINDING" construct to > specify contexts in which instances might show up, allowing > instances to be put in places that weren't even imagined when > the original class definition was written. Name bindings could > be standardized, or be vendor or even product-specific, allowing > the simplicity or complexity of a given system's instance tree > to reflect the actual simplicity or complexity of that system, > rather than requiring all systems to be structured for the > worst case. How could this be expressed in YANG terms? (I tried to figure it out myself but I unfortunately couldn't make any sense of sec. 8.6 in CCITT Recommendation X.722). Thanks, Lada > > Yes, separating the specification of instance naming in large part > from class definition does have implications for how one does access > control, and how clients figure out how to ask a server to create > something, but it's not a huge deal - it's just not like VACM, and a > whole slew of hacky solutions and "wierd plumbing adapters" (to borrow > from Jeff Case) just go away. Strangely, it makes the job of the > initial modeler and of the eventual user much easier. > > Randy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Aug 31 11:45:08 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E90D51B5770 for ; Mon, 31 Aug 2015 11:44:56 -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 8Zuw0WElaGf1 for ; Mon, 31 Aug 2015 11:44:55 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFFE91B5714 for ; Mon, 31 Aug 2015 11:44:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=50773; q=dns/txt; s=iport; t=1441046694; x=1442256294; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=JOqGuu7ZI1c6omrVGp9pMO+L+DqeYvHnSe7XqzL03dc=; b=Hi4o0NEpak2T+kp5tLqH3tjX0Pv5989IjMleI6A+7HS3oszuMMIZhi6t F286Y0ixUd7PV+iBe1pQG90Tq/AVPBEyLKvYyf0yWiyTxK5AGdb9uGqag WXfx2V0aQFF583KTeg/KlIss75Iq2GJNfdpJgJowNcL7nLpqN5spOnaj8 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CxAgDLn+RV/5hdJa1dgk5NgT0Ggx27BAEJh3ICHIEOOBQBAQEBAQEBgQqEIwEBAQQjVhACAQgOAwMBAiEBBgMCAgIfERQJCAIEDgWIGQMSsgOPQQ2FDwEBAQEBAQEBAQEBAQEBAQEBAQEBGItqgk+CKxEHgmmBQwWVQQGLBoFtky6HPCaCDxyBVHGBSIEFAQEB X-IronPort-AV: E=Sophos;i="5.17,442,1437436800"; d="scan'208,217";a="183794162" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-8.cisco.com with ESMTP; 31 Aug 2015 18:44:53 +0000 Received: from XCH-RCD-019.cisco.com (xch-rcd-019.cisco.com [173.37.102.29]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t7VIircL031925 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 31 Aug 2015 18:44:53 GMT Received: from xch-rcd-019.cisco.com (173.37.102.29) by XCH-RCD-019.cisco.com (173.37.102.29) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 31 Aug 2015 13:44:53 -0500 Received: from xhc-rcd-x05.cisco.com (173.37.183.79) by xch-rcd-019.cisco.com (173.37.102.29) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Mon, 31 Aug 2015 13:44:53 -0500 Received: from xmb-aln-x06.cisco.com ([169.254.1.223]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0248.002; Mon, 31 Aug 2015 13:44:53 -0500 From: "Acee Lindem (acee)" To: Mahesh Jethanandani Thread-Topic: [netmod] Motivations for Structuring Models Thread-Index: AQHQ4NBLQlr4e3n2uUqD0R28uxSQow== Date: Mon, 31 Aug 2015 18:44:52 +0000 Message-ID: References: <55DF74FC.101@rob.sh> <20150828.083354.1177215032438250041.mbj@tail-f.com> <55E054DC.7050906@rob.sh> <20150828.145546.1509142825487206251.mbj@tail-f.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.37.102.19] Content-Type: multipart/alternative; boundary="_000_D209E9642D405aceeciscocom_" MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Motivations for Structuring Models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 18:44:57 -0000 --_000_D209E9642D405aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFoZXNoLA0KDQpJIHRoaW5rIHRoYXQgaWYgd2UgbGVhdmUgc3RydWN0dXJlIHRvIHRoZSBX R3MsIHdlIHdpbGwgZW5kIHVwIHdpdGggbW9kZWxzIHRoYXQgaGF2ZSBhIFdHLWNlbnRyaWMgdmll dyB3aXRoIHRoZWlyIGNvcnJlc3BvbmRpbmcgbW9kZWwgYmVpbmcgYXQgdGhlIHJvb3QgYW5kIGFu eSBpbnN0YW50aWF0aW9uIChsb2dpY2FsLW5ldHdvcmstZWxlbWVudCwgbmV0d29ya2luZy1pbnN0 YW5jZSwgVlJGLCBldGMpIGJlaW5nIGRvbmUgd2l0aGluIHRoZSBtb2RlbC4gSXMgdGhpcyB3aGF0 IHdlIHdhbnQ/IEluIHJvdXRpbmcsIHdlIGhhZCB0aGUgYmVuZWZpdCBvZiB0aGUgcm91dGluZy1j ZmcgbW9kZWwgYWxzbyBiZWluZyBjb25zaWRlcmVkIGFuZCBjb25jbHVkZWQgdGhlIGRlYmF0ZSBp biBmYXZvciBvZiBhZG9wdGluZyB0aGUgcm91dGluZy1jZmcgc3RydWN0dXJlIGZvciB0aGUgcm91 dGluZyBwcm90b2NvbCBtb2RlbHMuDQoNClRoYW5rcywNCkFjZWUNCg0KRnJvbTogTWFoZXNoIEpl dGhhbmFuZGFuaSA8bWpldGhhbmFuZGFuaUBnbWFpbC5jb208bWFpbHRvOm1qZXRoYW5hbmRhbmlA Z21haWwuY29tPj4NCkRhdGU6IEZyaWRheSwgQXVndXN0IDI4LCAyMDE1IGF0IDc6NDQgUE0NClRv OiBBY2VlIExpbmRlbSA8YWNlZUBjaXNjby5jb208bWFpbHRvOmFjZWVAY2lzY28uY29tPj4NCkNj OiBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbTxtYWlsdG86bWJqQHRhaWwtZi5jb20+ PiwgInJqc0Byb2Iuc2g8bWFpbHRvOnJqc0Byb2Iuc2g+IiA8cmpzQHJvYi5zaDxtYWlsdG86cmpz QHJvYi5zaD4+LCAibmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+IiA8bmV0 bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtuZXRt b2RdIE1vdGl2YXRpb25zIGZvciBTdHJ1Y3R1cmluZyBNb2RlbHMNCg0KQWNlZSwNCg0KVGhpcyBp cyBnb2luZyB0byBiZWNvbWUgdmVyeSBpbnRlcmVzdGluZyB2ZXJ5IHF1aWNrbHkuIFJvdXRpbmcg RFQgaGFzIGRlY2lkZWQgdG8gZGVmaW5lIGEgY29udGFpbmVyIGZvciBvYW0tcHJvdG9jb2xzLiBM SU1FIGhhcyBkZWNpZGVkIGl0IHdhbnRzIHRvIGRlZmluZSBhIGdlbmVyaWMgWUFORyBtb2R1bGUg Zm9yIGFsbCBPQU0gaW4gZHJhZnQtdGlzc2EtbGltZS15YW5nLW9hbS1tb2RlbC4NCg0KV2hpY2gg bW9kZWwgZG9lcyBCRkQgYXVnbWVudD8gT3IgZGlkIHlvdSBqdXN0IGtpbGwgdGhlIHdob2xlIGNo YXJ0ZXIgZm9yIExJTUU/Pw0KDQpPbiBBdWcgMjgsIDIwMTUsIGF0IDY6MjAgQU0sIEFjZWUgTGlu ZGVtIChhY2VlKSA8YWNlZUBjaXNjby5jb208bWFpbHRvOmFjZWVAY2lzY28uY29tPj4gd3JvdGU6 DQoNCldoeSBkb2VzbuKAmXQgaXQgaGVscD8gSW4gdGhlIG5leHQgcmV2aXNpb24gb2YgdGhlIFJv dXRpbmcgWUFORyBEVCBtb2RlbCwNCndl4oCZdmUgc3dpdGNoZWQgZnJvbSBpbmNsdWRpbmcgc3Bl Y2lmaWMgbW9kZWxzIHRvIGRlZmluaW5nIGNsYXNzZXMgb2YNCm1vZGVscyB3aXRoIGlkZW50aXRp ZXMuIEZvciBleGFtcGxlLA0KDQpncm91cGluZyBvYW0tcHJvdG9jb2xzIHsNCiAgICAgY29udGFp bmVyIG9hbS1wcm90b2NvbHMgew0KICAgICAgICAgbGlzdCBvYW0tcHJvdG9jb2wgew0KICAgICAg ICAgICAgIGtleSAidHlwZSI7DQogICAgICAgICAgICAgbGVhZiB0eXBlIHsNCiAgICAgICAgICAg ICAgICAgdHlwZSBpZGVudGl0eXJlZiB7DQogICAgICAgICAgICAgICAgICAgICBiYXNlIG9hbS1w cm90b2NvbC10eXBlOw0KICAgICAgICAgICAgICAgICB9DQogICAgICAgICAgICAgICAgIG1hbmRh dG9yeSB0cnVlOw0KICAgICAgICAgICAgICAgICBkZXNjcmlwdGlvbg0KICAgICAgICAgICAgICAg ICAgICAgIlRoZSBPcGVyYXRpb25zLCBBZG1pbmlzdHJhdGlvbiwgYW5kDQoNCg0KICAgICAgICAg ICAgICAgICAgICAgIE1haW50ZW5hbmNlIChPQU0pIHByb3RvY29sIHR5cGUsIGUuZy4sIEJGRCwN Cg0KDQogICAgICAgICAgICAgICAgICAgICAgVFdBTVAsIENGTSwgZXRjLiI7DQogICAgICAgICAg ICAgfQ0KICAgICAgICAgICAgIGRlc2NyaXB0aW9uDQogICAgICAgICAgICAgICAgICJMaXN0IG9m IE9BTSBwcm90b2NvbHMgY29uZmlndXJlZCBmb3IgYQ0KDQoNCiAgICAgICAgICAgICAgICAgIG5l dHdvcmtpbmcgaW5zdGFuY2UuIjsNCiAgICAgICAgIH0NCiAgICAgICAgIGRlc2NyaXB0aW9uDQog ICAgICAgICAgICAgIkNvbnRhaW5lciBmb3IgbGlzdCBvZiBPQU0gcHJvdG9jb2xzIGNvbmZpZ3Vy ZWQgZm9yIGENCg0KDQogICAgICAgICAgICAgICBuZXR3b3JraW5nIGluc3RhbmNlLiI7DQogICAg IH0NCiAgICAgZGVzY3JpcHRpb24NCiAgICAgICAgICJHcm91cGluZyBmb3IgT0FNIHByb3RvY29s cyBjb25maWd1cmVkIGZvciBhDQoNCg0KICAgICAgICAgIG5ldHdvcmtpbmcgaW5zdGFuY2UuIjsN CiB9DQoNCg0KVGhlbiB0aGUgZ3JvdXBpbmcgaXMgaW5jbHVkZSB0aGUgbmV0d29ya2luZy1pbnN0 YW5jZXMuICBCeSBkb2luZyB0aGlzLCB0aGUNCmludGVudCBpcyB0aGF0IGl0IHdvdWxkIGJlIGV2 aWRlbnQgYXMgdG8gd2hlcmUgYSBwYXJ0aWN1bGFyIG1vZGVsIHdvdWxkIGJlDQpmb3VuZC4NCg0K TWFoZXNoIEpldGhhbmFuZGFuaQ0KbWpldGhhbmFuZGFuaUBnbWFpbC5jb208bWFpbHRvOm1qZXRo YW5hbmRhbmlAZ21haWwuY29tPg0KDQoNCg0KDQoNCg== --_000_D209E9642D405aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IaSBNYWhlc2gs PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JIHRoaW5rIHRoYXQgaWYgd2UgbGVhdmUg c3RydWN0dXJlIHRvIHRoZSBXR3MsIHdlIHdpbGwgZW5kIHVwIHdpdGggbW9kZWxzIHRoYXQgaGF2 ZSBhIFdHLWNlbnRyaWMgdmlldyB3aXRoIHRoZWlyIGNvcnJlc3BvbmRpbmcgbW9kZWwgYmVpbmcg YXQgdGhlIHJvb3QgYW5kIGFueSBpbnN0YW50aWF0aW9uIChsb2dpY2FsLW5ldHdvcmstZWxlbWVu dCwgbmV0d29ya2luZy1pbnN0YW5jZSwgVlJGLCBldGMpIGJlaW5nIGRvbmUgd2l0aGluIHRoZQ0K IG1vZGVsLiBJcyB0aGlzIHdoYXQgd2Ugd2FudD8gSW4gcm91dGluZywgd2UgaGFkIHRoZSBiZW5l Zml0IG9mIHRoZSByb3V0aW5nLWNmZyBtb2RlbCBhbHNvIGJlaW5nIGNvbnNpZGVyZWQgYW5kIGNv bmNsdWRlZCB0aGUgZGViYXRlIGluIGZhdm9yIG9mIGFkb3B0aW5nIHRoZSByb3V0aW5nLWNmZyBz dHJ1Y3R1cmUgZm9yIHRoZSByb3V0aW5nIHByb3RvY29sIG1vZGVscy4mbmJzcDs8L2Rpdj4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoYW5rcyw8L2Rpdj4NCjxkaXY+QWNlZSZuYnNwOzwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8 ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGln bjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1M RUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47 IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRF Ui1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZv bnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5NYWhlc2ggSmV0aGFuYW5kYW5pICZsdDs8YSBo cmVmPSJtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20iPm1qZXRoYW5hbmRhbmlAZ21haWwu Y29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9z cGFuPkZyaWRheSwgQXVndXN0IDI4LCAyMDE1IGF0IDc6NDQgUE08YnI+DQo8c3BhbiBzdHlsZT0i Zm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj5BY2VlIExpbmRlbSAmbHQ7PGEgaHJlZj0ibWFp bHRvOmFjZWVAY2lzY28uY29tIj5hY2VlQGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5 bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+TWFydGluIEJqb3JrbHVuZCAmbHQ7PGEg aHJlZj0ibWFpbHRvOm1iakB0YWlsLWYuY29tIj5tYmpAdGFpbC1mLmNvbTwvYT4mZ3Q7LCAmcXVv dDs8YSBocmVmPSJtYWlsdG86cmpzQHJvYi5zaCI+cmpzQHJvYi5zaDwvYT4mcXVvdDsgJmx0Ozxh IGhyZWY9Im1haWx0bzpyanNAcm9iLnNoIj5yanNAcm9iLnNoPC9hPiZndDssICZxdW90OzxhIGhy ZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT4mcXVvdDsNCiAm bHQ7PGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+bmV0bW9kQGlldGYub3JnPC9hPiZn dDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJl OiBbbmV0bW9kXSBNb3RpdmF0aW9ucyBmb3IgU3RydWN0dXJpbmcgTW9kZWxzPGJyPg0KPC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVU SU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURE SU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0id29yZC13 cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1i cmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkFjZWUsDQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGlzIGlzIGdvaW5nIHRvIGJl Y29tZSB2ZXJ5IGludGVyZXN0aW5nIHZlcnkgcXVpY2tseS4gUm91dGluZyBEVCBoYXMgZGVjaWRl ZCB0byBkZWZpbmUgYSBjb250YWluZXIgZm9yIG9hbS1wcm90b2NvbHMuIExJTUUgaGFzIGRlY2lk ZWQgaXQgd2FudHMgdG8gZGVmaW5lIGEgZ2VuZXJpYyBZQU5HIG1vZHVsZSBmb3IgYWxsIE9BTSBp biBkcmFmdC10aXNzYS1saW1lLXlhbmctb2FtLW1vZGVsLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+V2hpY2ggbW9kZWwgZG9lcyBCRkQg YXVnbWVudD8gT3IgZGlkIHlvdSBqdXN0IGtpbGwgdGhlIHdob2xlIGNoYXJ0ZXIgZm9yIExJTUU/ PzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIEF1ZyAyOCwgMjAxNSwgYXQg NjoyMCBBTSwgQWNlZSBMaW5kZW0gKGFjZWUpICZsdDs8YSBocmVmPSJtYWlsdG86YWNlZUBjaXNj by5jb20iIGNsYXNzPSIiPmFjZWVAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIg Y2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxl OiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGlu ZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+V2h5DQogZG9lc27igJl0IGl0IGhlbHA/IEluIHRoZSBu ZXh0IHJldmlzaW9uIG9mIHRoZSBSb3V0aW5nIFlBTkcgRFQgbW9kZWwsPC9zcGFuPjxiciBzdHls ZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBu b3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBm b250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6 IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjog c3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFj ZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFu dDsiIGNsYXNzPSIiPndl4oCZdmUNCiBzd2l0Y2hlZCBmcm9tIGluY2x1ZGluZyBzcGVjaWZpYyBt b2RlbHMgdG8gZGVmaW5pbmcgY2xhc3NlcyBvZjwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5 OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZh cmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h bDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7 IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y bWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0 aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBu b3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUt aGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lk b3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog MHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5t b2RlbHMNCiB3aXRoIGlkZW50aXRpZXMuIEZvciBleGFtcGxlLDwvc3Bhbj48YnIgc3R5bGU9ImZv bnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFs OyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGln bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z cGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxiciBzdHlsZT0iZm9udC1mYW1pbHk6 IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy aWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsg dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3Jt YWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRp Y2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1o ZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRv d3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPmdy b3VwaW5nDQogb2FtLXByb3RvY29scyB7PC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhl bHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu dDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBs aW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4 dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7 IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1h bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWln aHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50 OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6 IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2NvbnRhaW5lcg0KIG9hbS1wcm90b2NvbHMgezwvc3Bh bj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9u dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczog YXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt OiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzog MHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6 IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRl ci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRl eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg d2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5l ICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDtsaXN0DQogb2FtLXByb3RvY29sIHs8L3NwYW4+PGJyIHN0eWxl PSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZv bnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50 OyIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7a2V5DQogJnF1b3Q7dHlwZSZxdW90Ozs8 L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7 IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhh bnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNp bmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0 eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBs ZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRv OyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5v bmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7 IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlu bGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7bGVhZg0KIHR5 cGUgezwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTog MTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWln aHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsg b3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQt c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4N CjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZv bnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3Jt YWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6 IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9y bTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6 IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxh eTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDt0eXBlDQogaWRlbnRpdHlyZWYgezwvc3Bhbj48YnIgc3R5bGU9 ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9y bWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9u dC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBu b3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0 YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6 IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7 IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtiYXNlDQogb2FtLXByb3RvY29sLXR5cGU7PC9zcGFuPjxi ciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0 eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBs ZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRv OyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5v bmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7 IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9y bWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWlt cG9ydGFudDsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwO308L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNp emU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQt d2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3Jt YWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0 ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3 b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9 IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4 OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDog bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBo YW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFj aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRp c3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7bWFuZGF0b3J5DQogdHJ1ZTs8L3NwYW4+PGJyIHN0eWxl PSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZv bnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50 OyIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ZGVzY3JpcHRpb248L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250 LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZv bnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBu b3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRv OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xh c3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAx MnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdo dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBv cnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10 cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1z cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7 IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7JnF1b3Q7 VGhlDQogT3BlcmF0aW9ucywgQWRtaW5pc3RyYXRpb24sIGFuZDwvc3Bhbj48YnIgc3R5bGU9ImZv bnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFs OyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGln bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z cGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxiciBzdHlsZT0iZm9udC1mYW1pbHk6 IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy aWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsg dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3Jt YWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNh OyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3Jt YWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVp Z2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu dDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dz OiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1z aXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250 LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9y bWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsg d29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6 IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7TWFpbnRlbmFuY2UNCiAoT0FNKSBwcm90b2NvbCB0eXBlLCBlLmcuLCBCRkQsPC9zcGFu PjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250 LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFs OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBh dXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGJyIHN0eWxl PSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YnIgc3R5bGU9ImZvbnQtZmFt aWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250 LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5v cm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3Rh cnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTog bm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVs dmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50 OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxp bmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0 LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsg d2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0i Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDtUV0FNUCwNCiBDRk0sIGV0Yy4mcXVvdDs7PC9zcGFuPjxiciBz dHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxl OiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFs OyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGln bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z cGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9y dGFudDsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO308L3NwYW4+PGJyIHN0eWxlPSJm b250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1h bDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFj aW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxp Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt c3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFy dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIg Y2xhc3M9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ZGVzY3JpcHRpb248L3NwYW4+PGJyIHN0eWxl PSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZv bnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50 OyIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 JnF1b3Q7TGlzdA0KIG9mIE9BTSBwcm90b2NvbHMgY29uZmlndXJlZCBmb3IgYTwvc3Bhbj48YnIg c3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHls ZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsg dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAt d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxiciBzdHlsZT0iZm9u dC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7 IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2lu Zzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWdu OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw YWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGJyIHN0eWxlPSJmb250LWZhbWlseTog SGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJp YW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7 IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0 ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h bDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGlj YTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9y bWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhl aWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93 czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw eDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7bmV0d29ya2lu Zw0KIGluc3RhbmNlLiZxdW90Ozs8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0 aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBu b3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUt aGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lk b3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog MHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9u dC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBm b250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDog bm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBw eDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0 bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxv YXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fTwvc3Bhbj48YnIg c3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHls ZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsg dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAt d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1h bDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFj aW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxp Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt c3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBv cnRhbnQ7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDtkZXNjcmlwdGlvbjwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBI ZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh bnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg bGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs OyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNh OyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3Jt YWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVp Z2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu dDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dz OiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmcXVvdDtDb250YWluZXINCiBmb3IgbGlzdCBvZiBPQU0gcHJvdG9j b2xzIGNvbmZpZ3VyZWQgZm9yIGE8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0 aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBu b3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUt aGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lk b3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog MHB4OyIgY2xhc3M9IiI+DQo8YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQt c2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9u dC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5v cm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7 IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87 IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFz cz0iIj4NCjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4 OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDog bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBo YW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFj aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1z dHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsg bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0 bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4 OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBp bmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwO25ldHdvcmtpbmcNCiBpbnN0YW5jZS4mcXVvdDs7PC9zcGFuPjxiciBzdHlsZT0iZm9udC1m YW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZv bnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBI ZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh bnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg bGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs OyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNz PSIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO308L3NwYW4+PGJyIHN0eWxlPSJmb250 LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsg Zm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246 IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3Bh Y2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy aWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsg dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3Jt YWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xh c3M9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ZGVzY3JpcHRpb248L3NwYW4+PGJy IHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5 bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl dHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87 IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9u ZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3Jt YWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3Bh Y2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFs aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRl LXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQt dGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1w b3J0YW50OyIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7JnF1b3Q7R3JvdXBpbmcNCiBmb3IgT0FNIHByb3RvY29scyBjb25maWd1 cmVkIGZvciBhPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1z aXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250 LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9y bWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsg d29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNz PSIiPg0KPGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7 IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhh bnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNp bmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YnIg c3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHls ZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsg dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAt d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1h bDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFj aW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxp Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt c3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBv cnRhbnQ7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDtuZXR3b3JraW5nDQogaW5zdGFuY2UuJnF1b3Q7Ozwvc3Bhbj48 YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1z dHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsg bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0 bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4 OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFp bXBvcnRhbnQ7IiBjbGFzcz0iIj4mbmJzcDt9PC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6 IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy aWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsg dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3Jt YWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNh OyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3Jt YWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVp Z2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu dDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dz OiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 OyIgY2xhc3M9IiI+DQo8YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6 ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13 ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1h bDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRl eHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdv cmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0i Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7 IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhh bnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNp bmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlz cGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5UaGVuDQogdGhlIGdyb3VwaW5nIGlz IGluY2x1ZGUgdGhlIG5ldHdvcmtpbmctaW5zdGFuY2VzLiAmbmJzcDtCeSBkb2luZyB0aGlzLCB0 aGU8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEy cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0 OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9y cGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRy YW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNw YWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250 LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFs OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBh dXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6 IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+aW50ZW50DQogaXMgdGhhdCBpdCB3b3VsZCBi ZSBldmlkZW50IGFzIHRvIHdoZXJlIGEgcGFydGljdWxhciBtb2RlbCB3b3VsZCBiZTwvc3Bhbj48 YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1z dHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsg bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0 bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4 OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFp bXBvcnRhbnQ7IiBjbGFzcz0iIj5mb3VuZC48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGlj YTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9y bWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhl aWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93 czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw eDsiIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0i Ij4NCjxkaXYgYXBwbGUtY29udGVudC1lZGl0ZWQ9InRydWUiIGNsYXNzPSIiPg0KPGRpdiBzdHls ZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczog YXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt OiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzog MHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29y ZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdo aXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBs ZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsg dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3Jt YWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3Bh Y2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+TWFoZXNoIEpldGhhbmFuZGFuaTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YSBo cmVmPSJtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20iIGNsYXNzPSIiPm1qZXRoYW5hbmRh bmlAZ21haWwuY29tPC9hPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjwvZGl2 Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxiciBjbGFzcz0iQXBw bGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_D209E9642D405aceeciscocom_-- From nobody Mon Aug 31 12:08:42 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 907851A0199 for ; Mon, 31 Aug 2015 12:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.018 X-Spam-Level: X-Spam-Status: No, score=-1.018 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_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dA32fC6t6ncy for ; Mon, 31 Aug 2015 12:08:39 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E82821A0083 for ; Mon, 31 Aug 2015 12:08:38 -0700 (PDT) Received: by pabzx8 with SMTP id zx8so148248344pab.1 for ; Mon, 31 Aug 2015 12:08:38 -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=GstDGayDoulaf54WqeM9Tg2Il4kNWeRZrVzteuR6nsQ=; b=IKVefG0s4s0UBRnf0d+grdgiJGV9TaPSICrFQie3/wlYUSSDXfGy6cAMCJyHZ/dMHX SW6LLwmsvEt73Bu2MgClvrM4gbLKPQdt+9bMtMwTx4ZePkWAE9KFReJ2UROOrDy2ITGW lwXHcApYOnO1T0w+in4QsPlejFsPxm3YzeCTmr/Mv34KYS0wE0qp88KjXrnyxOyQfzT+ ks+bMf9zii66hkBKl4EsN9QmuFL57/OW65vU1o66ir5HgcVtXEcxbdbnZnKbXidU6idk TqipLuzWNIX4VHz2MvUKzGj23V+45F67mFGVyNkhXcVHVNCNrxrXYLhsvAax/y7IEB4o TF1g== X-Received: by 10.68.243.4 with SMTP id wu4mr26029807pbc.142.1441048118370; Mon, 31 Aug 2015 12:08:38 -0700 (PDT) Received: from dmp-sjc23-3.cisco.com (dmp-sjc23-3.cisco.com. [128.107.157.235]) by smtp.gmail.com with ESMTPSA id vw7sm5116642pab.15.2015.08.31.12.08.36 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 31 Aug 2015 12:08:37 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_684D1548-4905-4EB3-9FA3-B07C50A56A76" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Mahesh Jethanandani In-Reply-To: Date: Mon, 31 Aug 2015 12:10:09 -0700 Message-Id: <8B9D124D-2580-472F-A582-813BBE1463D3@gmail.com> References: <55DF74FC.101@rob.sh> <20150828.083354.1177215032438250041.mbj@tail-f.com> <55E054DC.7050906@rob.sh> <20150828.145546.1509142825487206251.mbj@tail-f.com> To: Qin Wu X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Motivations for Structuring Models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 19:08:41 -0000 --Apple-Mail=_684D1548-4905-4EB3-9FA3-B07C50A56A76 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Qin, My question was more rhetorical. What I was trying to highlight was that = the process of trying to define a strict overall tree like structure is = fraught with issues. Your interpretation of where oam-protocols reside = on a device could be different from say Acee=E2=80=99s interpretation or = mine. And who is to say, that interpretation is wrong.=20 The other point, that Martin also brought up, is that today a BFD = configuration typically looks like this in CLI (under an interface). Device(config-if)# bfd interval 50 min_rx 50 multiplier 5 You are asking that that should now look more like: Device# devices device lime bfd interval 50 min_rx 50 multiplier 5 or even: Device(config-if)# lime bfd interval 50 min_rx 50 multiplier 5 How does that make any more sense? > On Aug 28, 2015, at 6:40 PM, Qin Wu wrote: >=20 > Hi, Mahesh: > Just want to clarify. > I think what Routing DT team is doing is complementary to what LIME WG = is doing. > what routing DT team is doing is to identify all the existing models = and the models that are under development for OAM, routing, interface, = etc, to see how these models for different technology, protocol, = feature(e.g., ACL, QoS) can fit together to form comprehensive structure = and deliver the service. > =20 > LIME work wants to provide common structure for various OAM = technologies by defining generic YANG model for OAM. But the focus is to = define generic YANG model for OAM. > Based on LIME WG charter All the technology specific models are = extension to this generic model. The relationship between these OAM = related models can depicted as following: > +-+-+-+-+-+ > | LIME gen| > |OAM YANG | > +-+-+-+-+-+ > | > | > +---------------------------------------------------------+ > | | | | | > +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ = +-+-+-+-+-+ > | CFM | | MPLS-TP | | MPLS | | IP | . . .| foo = | > |OAM YANG | |OAM YANG | |OAM YANG | |OAM YANG | |OAM YANG = | > +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ = +-+-+-+-+-+ > | | | | | > | +-+-+-+-+-+ +-+-+-+-+-+ | = +-+-+-+-+-+ > | | MPLS-TP | | MPLS | | . . .| foo = | > | |sub tech | |sub tech | | |sub tech = | > =20 > The example given by Acee is to provide a list of OAM protocols which = need to be ready to configure a network instance. There is no = overlapping. > =20 > -Qin > =E5=8F=91=E4=BB=B6=E4=BA=BA: netmod [mailto:netmod-bounces@ietf.org = ] =E4=BB=A3=E8=A1=A8 Mahesh Jethanandani > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2015=E5=B9=B48=E6=9C=8829=E6=97=A5= 7:44 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Acee Lindem (acee) > =E6=8A=84=E9=80=81: netmod@ietf.org > =E4=B8=BB=E9=A2=98: Re: [netmod] Motivations for Structuring Models > =20 > Acee, > =20 > This is going to become very interesting very quickly. Routing DT has = decided to define a container for oam-protocols. LIME has decided it = wants to define a generic YANG module for all OAM in = draft-tissa-lime-yang-oam-model. > =20 > Which model does BFD augment? Or did you just kill the whole charter = for LIME?? > =20 > On Aug 28, 2015, at 6:20 AM, Acee Lindem (acee) > wrote: > =20 > Why doesn=E2=80=99t it help? In the next revision of the Routing YANG = DT model, > we=E2=80=99ve switched from including specific models to defining = classes of > models with identities. For example, > =20 > grouping oam-protocols { > container oam-protocols { > list oam-protocol { > key "type"; > leaf type { > type identityref { > base oam-protocol-type; > } > mandatory true; > description > "The Operations, Administration, and > =20 > =20 > Maintenance (OAM) protocol type, e.g., BFD, > =20 > =20 > TWAMP, CFM, etc."; > } > description > "List of OAM protocols configured for a > =20 > =20 > networking instance."; > } > description > "Container for list of OAM protocols configured for a > =20 > =20 > networking instance."; > } > description > "Grouping for OAM protocols configured for a > =20 > =20 > networking instance."; > } > =20 > =20 > Then the grouping is include the networking-instances. By doing this, = the > intent is that it would be evident as to where a particular model = would be > found.=20 > =20 > Mahesh Jethanandani > mjethanandani@gmail.com Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_684D1548-4905-4EB3-9FA3-B07C50A56A76 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Qin,

My = question was more rhetorical. What I was trying to highlight was that = the process of trying to define a strict overall tree like structure is = fraught with issues. Your interpretation of where oam-protocols =  reside on a device could be different from say Acee=E2=80=99s = interpretation or mine. And who is to say, that interpretation is = wrong. 

The= other point, that Martin also brought up, is that today a BFD = configuration typically looks like this in CLI (under an = interface).

Device(config-if)# bfd interval 50 min_rx 50 = multiplier 5

You are asking that that should now look more like:

Device# devices =
device lime bfd interval 50 min_rx 50 multiplier 5

or even:

Device(config-if)# lime bfd interval 50 min_rx 50 multiplier =
5

How = does that make any more sense?

On Aug 28, 2015, at 6:40 PM, Qin Wu <bill.wu@huawei.com> = wrote:

Hi, Mahesh:
Just= want to clarify.
I think what Routing DT team is = doing is complementary to what LIME WG is doing.
what= routing DT team is doing is to identify all the existing models and the = models that are under development for OAM, routing, interface, etc, to see how = these models for different technology, protocol, feature(e.g., ACL, QoS) = can fit together to form comprehensive structure and deliver the = service.
 
LIME work wants to provide common structure for various OAM = technologies by defining generic YANG model for OAM. But the focus is to = define generic YANG model for OAM.
Based on LIME WG = charter All the technology specific models are extension to this generic = model. The relationship between these OAM related models can depicted as = following:
          &nb= sp;            = ;    +-+-+-+-+-+
          &nb= sp;            = ;    | LIME gen|
          &nb= sp;            = ;    |OAM YANG |
          &nb= sp;            = ;    +-+-+-+-+-+
          &nb= sp;            = ;         |
          &nb= sp;            = ;         |
        = +---------------------------------------------------------+
        = |            &= nbsp; = |            &= nbsp;  |         = |            &= nbsp;   |
    = +-+-+-+-+-+   +-+-+-+-+-+   +-+-+-+-+-+ = +-+-+-+-+-+      +-+-+-+-+-+
    | CFM     = |   | MPLS-TP |   | MPLS    | | = IP      | . . .|  foo    = |
    |OAM YANG |   |OAM = YANG |   |OAM YANG | |OAM YANG |      = |OAM YANG |
    = +-+-+-+-+-+   +-+-+-+-+-+   +-+-+-+-+-+ = +-+-+-+-+-+      +-+-+-+-+-+
          = |             = |             = |           = |            &= nbsp; |
          = |       +-+-+-+-+-+   = +-+-+-+-+-+       = |          = +-+-+-+-+-+
          = |       | MPLS-TP |   | = MPLS    |       = |     . . .|  foo    |
          = |       |sub tech |   |sub tech = |       = |          |sub tech = |
 
The example given by = Acee is to provide a list of OAM protocols which need to be ready to = configure a network instance. There is no overlapping.
 
-Qin
=E5=8F=91=E4=BB=B6= =E4=BA=BA: netmod [mailto:netmod-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Mahesh = Jethanandani
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2015=E5=B9=B48=E6=9C=8829=E6=97=A5 7:44
=E6=94=B6=E4=BB=B6= =E4=BA=BA: Acee Lindem = (acee)
=E6=8A=84=E9=80=81: netmod@ietf.org
=E4=B8=BB=E9=A2=98: Re: [netmod] Motivations for Structuring = Models
 
Acee,
 
This = is going to become very interesting very quickly. Routing DT has decided = to define a container for oam-protocols. LIME has decided it wants to = define a generic YANG module for all OAM in = draft-tissa-lime-yang-oam-model.
 
Which model does BFD augment? Or did you just kill the whole = charter for LIME??
 
On = Aug 28, 2015, at 6:20 AM, Acee Lindem (acee) <acee@cisco.com> = wrote:
 
Why doesn=E2=80=99t it help? In the next = revision of the Routing YANG DT model,
we=E2=80=99ve switched from = including specific models to defining classes of
models with identities. For example,
 
grouping oam-protocols = {
     container oam-protocols {
         list oam-protocol {
          &nb= sp;  key = "type";
          &nb= sp;  leaf type = {
          &nb= sp;      type identityref {
          &nb= sp;          base = oam-protocol-type;
          &nb= sp;      }
          &nb= sp;      mandatory true;
          &nb= sp;      description
          &nb= sp;          "The Operations, Administration, = and
 
 
          &nb= sp;           Maintenance (OAM) protocol type, e.g., = BFD,
 
 
          &nb= sp;           TWAMP, CFM, etc.";
          &nb= sp;  }
          &nb= sp;  description
          &nb= sp;      "List of OAM protocols configured for = a
 
 
          &nb= sp;       networking instance.";
         }<= /div>
         description
          &nb= sp;  "Container for list of = OAM protocols configured for a
 
 
          &nb= sp;    networking = instance.";
     }
     description
         "Grouping for OAM protocols configured for = a
 
 
          networking = instance.";
 }
 
 
Then the grouping is = include the networking-instances.  By doing this, the
intent = is that it would be evident as to where a particular model would = be
found. 
 
Mahesh = Jethanandani
mjethanandani@gmail.com

Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_684D1548-4905-4EB3-9FA3-B07C50A56A76-- From nobody Mon Aug 31 12:31:43 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14B461B5A26 for ; Mon, 31 Aug 2015 12:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2iGOj_-uLaM for ; Mon, 31 Aug 2015 12:31:39 -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 98C891B59E6 for ; Mon, 31 Aug 2015 12:31:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=UssAWFf5u2d3Z/i4GuJpyP1l9QyIWmgwYLzvp0V967y6QUKMPAHaLciwZiwprgy+; 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.32] (helo=elwamui-cypress.atl.sa.earthlink.net) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1ZWUno-0002cV-BU for netmod@ietf.org; Mon, 31 Aug 2015 15:31:36 -0400 Received: from 76.254.53.15 by webmail.earthlink.net with HTTP; Mon, 31 Aug 2015 15:31:35 -0400 Message-ID: <18043244.1441049496150.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> Date: Mon, 31 Aug 2015 12:31:35 -0700 (GMT-07:00) From: Randy Presuhn To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88874d3f0892ff6d3ed2714de1d89d836bfb1e554ed2abab5f0350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.32 Archived-At: Subject: Re: [netmod] Motivations for Structuring Models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 19:31:42 -0000 Hi - >From: Ladislav Lhotka >Sent: Aug 31, 2015 8:04 AM >To: Randy Presuhn , netmod@ietf.org >Subject: Re: [netmod] Motivations for Structuring Models ... >> What GDMO did was to use a separate "NAME BINDING" construct to >> specify contexts in which instances might show up, allowing >> instances to be put in places that weren't even imagined when >> the original class definition was written. Name bindings could >> be standardized, or be vendor or even product-specific, allowing >> the simplicity or complexity of a given system's instance tree >> to reflect the actual simplicity or complexity of that system, >> rather than requiring all systems to be structured for the >> worst case. > >How could this be expressed in YANG terms? (I tried to figure it out >myself but I unfortunately couldn't make any sense of sec. 8.6 in CCITT >Recommendation X.722). A key concept of naming in that universe is "containment". As with X.500 Directory or modern file systems, object instances are identified by their "distinguishing attribute(s)" within the context of a containing object. The containment hierarchy within a given system generally reflects physical or logical containment. Perhaps an example of how it could be used would help. Suppose I've defined a "cpu" class and a "motherboard" class. Further suppose that the "cpu" class has an attribute called "processorId" which is guaranteed to be unique within any naming context in which one might find more than one processor as immediate siblings. To say that a cpu could be identified (named) within the context of a motherboard, one could say something like cpuOfMotherboard NAME BINDING SUBORDINATE OBJECT CLASS cpu AND SUBCLASSES; NAMED BY SUPERIOR OBJECT CLASS motherboard AND SUBCLASSES; WITH ATTRIBUTE processorId; REGISTERED AS blah ; This says that if one has located an instance of the motherboard class or any of its subclasses, instances of the cpu class that are immediately contained by it could be named within that context by their "processorId" attribute. (A meta-model requirement is that any instantiable object class needs to have at least one attribute suitable for use in naming.) Later, say we find that we need to model line cards with cpus, and those line cards (for whatever reason) are not derived from the motherboard class. But we can still use the cpu class to manage those processors by adding another name binding: cpuOfLinecard NAME BINDING SUBORDINATE OBJECT CLASS cpu AND SUBCLASSES; NAMED BY SUPERIOR OBJECT CLASS lineCard AND SUBCLASSES; WITH ATTRIBUTE processorId; REGISTERED AS blahblah ; The point is that the class definition does not by itself determine where object instances might appear in a managed system; the supported name bindings determine where instances can be, whether (and how) they are created, and whether (and how) they can be deleted. Is that a bit clearer? No tidy way to do all of this in Yang-land is apparent to me - the (meta-) modeling assumptions seem too far removed, particularly with regard to inheritance and containment - but someone more creative than me might figure out how to do it. But the point is not to ape GDMO. The point is that this capability was included in that world to address real-world modeling needs, and we're seeing those same needs resurfacing here. Randy From nobody Mon Aug 31 17:01:58 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 888B91A19E4 for ; Mon, 31 Aug 2015 17:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.896 X-Spam-Level: * X-Spam-Status: No, score=1.896 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 I8p9kx0DUhUp for ; Mon, 31 Aug 2015 17:01:54 -0700 (PDT) Received: from mail.hq.sk (hq.sk [81.89.59.181]) by ietfa.amsl.com (Postfix) with ESMTP id 68BD81ACE23 for ; Mon, 31 Aug 2015 17:01:53 -0700 (PDT) Received: from [10.0.2.15] (188-167-5-4.dynamic.chello.sk [188.167.5.4]) by mail.hq.sk (Postfix) with ESMTPSA id B64EF241EB8; Tue, 1 Sep 2015 02:01:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1441065711; bh=HsDds91BlekXVjM+QajQc4NlRexGqjztOGi7j6YrBzQ=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=AyVUb2VggElV1b9a3g8f/vcNPQT7km7awliFX69yEO0ZWJ+xdR+0RHFII/M9Tl0GL eviGesfChBW8rbITa5pfh3ai+kIU/jmbIcaEHKbKrobNLU1/EmQj1s4owXr26KDsfg 0wrHeRwejqZ7RdUIH7JBvs54iCLXq2WIxZLwOJFk= To: Martin Bjorklund , rjs@rob.sh References: <55DF74FC.101@rob.sh> <20150828.083354.1177215032438250041.mbj@tail-f.com> <55E054DC.7050906@rob.sh> <20150828.145546.1509142825487206251.mbj@tail-f.com> From: Robert Varga Message-ID: <55E4EAEF.3070508@hq.sk> Date: Tue, 1 Sep 2015 02:01:51 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150828.145546.1509142825487206251.mbj@tail-f.com> Content-Type: multipart/alternative; boundary="------------030109090206040709030701" Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Motivations for Structuring Models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 00:01:57 -0000 This is a multi-part message in MIME format. --------------030109090206040709030701 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 08/28/2015 02:55 PM, Martin Bjorklund wrote: >>> But, as I have said before, the device abstraction is really >>> > >important - in the NMS/OSS/controller/whatever. There we have a list >>> > >of devices, and each device has a name and meta-data and then its real >>> > >data, so for example we can have: >>> > > >>> > > /devices/device[name='rtr4']/ip >>> > > /devices/device[name='rtr4']/port >>> > > >>> > >and then we put all data models from the device under a common >>> > >container 'data': >>> > > >>> > > /devices/device[name='rtr4']/data/interface/ >>> > > /devices/device[name='rtr4']/data/xconnect/ >>> > > >>> > >If the device had a top-level container "device" this would have been: >>> > > >>> > > /devices/device[name='rtr4']/data/device/interfaces >> >This approach*DOES* logically structure configuration around the >> >concept of a device. > Yes - in the NMS/OSS/controller -*not* on the device! > I will add that at that layer a flat list is probably not going to be good enough in face of layers and federations. That is definitely a different issue and one where 'relocating' YANG models becomes important. At that layer I could not care less if interfaces are enumerated in /interfaces or /device/interfaces -- I will end up relocating the models to fit the logical layout anyway, as I will need to have them placed in a structure which makes sense to my end users. On the device layer, though, I have to say that /device is just a redundant layer of abstraction. Stuff augmenting it will fan out just as it does currently at /. Furthermore we will end up with 'structural models', which are somewhat of a first-class citizen and 'functionality models', which have to augment some structural model. I think end users care more about interaction with the latter. From OpenDaylight implementation perspective, augmentations are slightly harder to work with, simply because their underlying concept does not have a language-level equivalent in Java (but it does in other languages). For this reason I would advocate not using a structural base unless it allows us to express a relationship which we couldn't do otherwise. Bye, Robert --------------030109090206040709030701 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 08/28/2015 02:55 PM, Martin Bjorklund wrote:
But, as I have said before, the device abstraction is really
> > important - in the NMS/OSS/controller/whatever.  There we have a list
> > of devices, and each device has a name and meta-data and then its real
> > data, so for example we can have:
> >
> >     /devices/device[name='rtr4']/ip
> >     /devices/device[name='rtr4']/port
> >
> > and then we put all data models from the device under a common
> > container 'data':
> >
> >     /devices/device[name='rtr4']/data/interface/
> >     /devices/device[name='rtr4']/data/xconnect/
> >
> > If the device had a top-level container "device" this would have been:
> >
> >     /devices/device[name='rtr4']/data/device/interfaces

> This approach *DOES* logically structure configuration around the
> concept of a device.

Yes - in the NMS/OSS/controller - *not* on the device!

I will add that at that layer a flat list is probably not going to be good enough in face of layers and federations. That is definitely a different issue and one where 'relocating' YANG models becomes important.

At that layer I could not care less if interfaces are enumerated in /interfaces or /device/interfaces -- I will end up relocating the models to fit the logical layout anyway, as I will need to have them placed in a structure which makes sense to my end users.

On the device layer, though, I have to say that /device is just a redundant layer of abstraction. Stuff augmenting it will fan out just as it does currently at /. Furthermore we will end up with 'structural models', which are somewhat of a first-class citizen and 'functionality models', which have to augment some structural model. I think end users care more about interaction with the latter.

From OpenDaylight implementation perspective, augmentations are slightly harder to work with, simply because their underlying concept does not have a language-level equivalent in Java (but it does in other languages). For this reason I would advocate not using a structural base unless it allows us to express a relationship which we couldn't do otherwise.

Bye,
Robert

--------------030109090206040709030701-- From nobody Mon Aug 31 17:08:02 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6391B51B8 for ; Mon, 31 Aug 2015 17:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.595 X-Spam-Level: X-Spam-Status: No, score=0.595 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, RCVD_IN_DNSWL_LOW=-0.7, 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 Y6f60kXokTfR for ; Mon, 31 Aug 2015 17:07:59 -0700 (PDT) Received: from mail.hq.sk (hq.sk [81.89.59.181]) by ietfa.amsl.com (Postfix) with ESMTP id 36B481B51B5 for ; Mon, 31 Aug 2015 17:07:59 -0700 (PDT) Received: from [172.16.0.179] (188-167-5-4.dynamic.chello.sk [188.167.5.4]) by mail.hq.sk (Postfix) with ESMTPSA id 6F943241EB8; Tue, 1 Sep 2015 02:07:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1441066078; bh=7ShrTAPP5FHFF16wKZlWdeihEGLlJJDTpEF2D0VUyVQ=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=EbRzoYV/hg91KFuz2pqshPQ7a36K/3KFlKGqY2Rp57aI4MpEcZfwnx/uG9hOkY/dW YToZla8e83Sso8IYJX5K4WreqHH6y1xOmZn5Q4VelN5Fzh5JRmVk+axqwpPJiwCUee +5UV/elpu9p+VLA5yKzidly7b6LrZ2wvznNUlT8o= To: Rob Shakir , Martin Bjorklund References: <20150827.214518.77501131721951504.mbj@tail-f.com> <55DF74FC.101@rob.sh> From: Robert Varga Message-ID: <55E4EC5C.9010606@hq.sk> Date: Tue, 1 Sep 2015 02:07:56 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55DF74FC.101@rob.sh> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Motivations for Structuring Models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 00:08:00 -0000 On 2015-08-27 22:37, Rob Shakir wrote: > First off, we drew a picture [0] that showed the set of modules that > we figured we might need. These break down into various bits of device > functionality. To make this more accessible as something that could be > shown in a draft, we expressed it in YANG and used pyang to draw out > the tree. > > The layout of the sets of functions that we have, and how they are > grouped, is the important thing. The fact that we are configuring a > device makes /device a good starting point. I think this is how you > implemented NEDs in NCS too...? > > Cheers, > r. > > [0]: http://rob.sh/files/model-structure.pdf A picture speaks a thousand words. As someone largely ignorant of routing operations, I have to ask, though: What is the value of having a set of logical routers each containing a set of VRFs? Wouldn't a structure having a 'global router' and a per-VRF logical router achieve the same thing (purely from modeling perspective)? Thanks, Robert From nobody Mon Aug 31 17:24:31 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 387211B6500 for ; Mon, 31 Aug 2015 17:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.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 DH_Y-UX8NheW for ; Mon, 31 Aug 2015 17:24:28 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CB731B64E8 for ; Mon, 31 Aug 2015 17:24:27 -0700 (PDT) Received: from [76.69.245.91] (helo=corretto.local) by cappuccino.rob.sh with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1ZWZMv-00023p-3C; Tue, 01 Sep 2015 01:24:09 +0100 Date: Mon, 31 Aug 2015 20:24:21 -0400 From: Rob Shakir To: Martin Bjorklund , Robert Varga Message-ID: In-Reply-To: <55E4EC5C.9010606@hq.sk> References: <20150827.214518.77501131721951504.mbj@tail-f.com> <55DF74FC.101@rob.sh> <55E4EC5C.9010606@hq.sk> X-Mailer: Airmail Beta (324) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Motivations for Structuring Models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 00:24:30 -0000 Hi Robert, On August 31, 2015 at 20:08:14, Robert Varga (nite=40hq.sk) wrote: > =20 > A picture speaks a thousand words. As someone largely ignorant of > routing operations, I have to ask, though: What is the value of having = a > set of logical routers each containing a set of VR=46s=3F Wouldn't a > structure having a 'global router' and a per-VR=46 logical router achie= ve > the same thing (purely from modeling perspective)=3F We=E2=80=99re modelling two different things here. One is a physical syst= em that we can have run multiple logical systems (think a bare metal mach= ine running multiple VMs), and then the other is a logical separation of = solely routing tables within one of the logical systems (think Linux netw= ork namespaces).=C2=A0 There are N logical systems to each physical system, and M routing tables= (VR=46s) to each logical system. A logical system might come with its ow= n set of protocol daemons, authentication etc., whereas a VR=46 typically= would not. Thanks, r. From nobody Mon Aug 31 17:38:54 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7B601B6239 for ; Mon, 31 Aug 2015 17:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.805 X-Spam-Level: X-Spam-Status: No, score=-0.805 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_SK=1.35, HOST_EQ_SK=0.555, RCVD_IN_DNSWL_LOW=-0.7, 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 bS9ip3ybeDNs for ; Mon, 31 Aug 2015 17:38:52 -0700 (PDT) Received: from mail.hq.sk (hq.sk [81.89.59.181]) by ietfa.amsl.com (Postfix) with ESMTP id CEA281B45E7 for ; Mon, 31 Aug 2015 17:38:51 -0700 (PDT) Received: from [10.0.2.15] (188-167-5-4.dynamic.chello.sk [188.167.5.4]) by mail.hq.sk (Postfix) with ESMTPSA id 307BB241EB8; Tue, 1 Sep 2015 02:38:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1441067930; bh=wc0iwZNn6OJQIArZoZTBxNqoN/uazTVkqkaKeyOMNtg=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=lPfQt1ynejHGrALSZ9cW8G0yYG0coERqzR5f1HiMPkXnAmQGIk0dgSSkcojXbdrK6 gpzo1Su/0fGRz7sT7eSZgCQhli9RswUuzSormjI5kGMVTXW0UYDMdbf9t9ZOtnMB9T SAwHdkJKI8/ESzfYhzve4dqhK45bSi6bsUCFXWG4= To: Rob Shakir , Martin Bjorklund References: <20150827.214518.77501131721951504.mbj@tail-f.com> <55DF74FC.101@rob.sh> <55E4EC5C.9010606@hq.sk> From: Robert Varga Message-ID: <55E4F39A.606@hq.sk> Date: Tue, 1 Sep 2015 02:38:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Motivations for Structuring Models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 00:38:53 -0000 On 09/01/2015 02:24 AM, Rob Shakir wrote: > Hi Robert, > > On August 31, 2015 at 20:08:14, Robert Varga (nite@hq.sk) wrote: >> >> A picture speaks a thousand words. As someone largely ignorant of >> routing operations, I have to ask, though: What is the value of having a >> set of logical routers each containing a set of VRFs? Wouldn't a >> structure having a 'global router' and a per-VRF logical router achieve >> the same thing (purely from modeling perspective)? > We’re modelling two different things here. One is a physical system that we can have run multiple logical systems (think a bare metal machine running multiple VMs), and then the other is a logical separation of solely routing tables within one of the logical systems (think Linux network namespaces). > > There are N logical systems to each physical system, and M routing tables (VRFs) to each logical system. A logical system might come with its own set of protocol daemons, authentication etc., whereas a VRF typically would not. Makes sense, thanks for making it clear. The set of logical systems is a flattened list of the hierarchical reality (e.g. running VMs inside a VM), with some additional metadata to express how logical systems relate to each other from containment perspective. Bye, Robert From nobody Mon Aug 31 17:53:36 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5BA1B56E8 for ; Mon, 31 Aug 2015 17:53:34 -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 8owdbbBUAKiw for ; Mon, 31 Aug 2015 17:53:30 -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 2C1D21B6EA7 for ; Mon, 31 Aug 2015 17:53:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CAQ95030; Tue, 01 Sep 2015 00:53:26 +0000 (GMT) Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 1 Sep 2015 01:53:24 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.99]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0235.001; Tue, 1 Sep 2015 08:53:19 +0800 From: Qin Wu To: Mahesh Jethanandani Thread-Topic: [netmod] Motivations for Structuring Models Thread-Index: AQHQ4NBOADFMJ24pqkmio9Q4U/+UL54fggqAgAAU4ACAACMmAIAADoUAgACmsgCAAGQvAIAABoMAgAAG/YCAAK4tgIAAnf/wgAPMb4CAAN958A== Date: Tue, 1 Sep 2015 00:53:18 +0000 Message-ID: References: <55DF74FC.101@rob.sh> <20150828.083354.1177215032438250041.mbj@tail-f.com> <55E054DC.7050906@rob.sh> <20150828.145546.1509142825487206251.mbj@tail-f.com> <8B9D124D-2580-472F-A582-813BBE1463D3@gmail.com> In-Reply-To: <8B9D124D-2580-472F-A582-813BBE1463D3@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA8481585Fnkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Motivations for Structuring Models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 00:53:34 -0000 --_000_B8F9A780D330094D99AF023C5877DABA8481585Fnkgeml501mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIE1haGVzaDoNCg0K5Y+R5Lu25Lq6OiBNYWhlc2ggSmV0aGFuYW5kYW5pIFttYWlsdG86bWpl dGhhbmFuZGFuaUBnbWFpbC5jb21dDQrlj5HpgIHml7bpl7Q6IDIwMTXlubQ55pyIMeaXpSAzOjEw DQrmlLbku7bkuro6IFFpbiBXdQ0K5oqE6YCBOiBBY2VlIExpbmRlbSAoYWNlZSk7IG5ldG1vZEBp ZXRmLm9yZw0K5Li76aKYOiBSZTogW25ldG1vZF0gTW90aXZhdGlvbnMgZm9yIFN0cnVjdHVyaW5n IE1vZGVscw0KDQpRaW4sDQoNCk15IHF1ZXN0aW9uIHdhcyBtb3JlIHJoZXRvcmljYWwuIFdoYXQg SSB3YXMgdHJ5aW5nIHRvIGhpZ2hsaWdodCB3YXMgdGhhdCB0aGUgcHJvY2VzcyBvZiB0cnlpbmcg dG8gZGVmaW5lIGEgc3RyaWN0IG92ZXJhbGwgdHJlZSBsaWtlIHN0cnVjdHVyZSBpcyBmcmF1Z2h0 IHdpdGggaXNzdWVzLg0KDQpbUWluXTogV2hhdCBMSU1FIGlzIGRvaW5nIGlzIGRlZmluZSB0aGUg c3RydWN0dXJlIGluIHRoZSBzYW1lIHdheSBhcyByb3V0aW5nLWNmZyBkaWQgYW5kIHByb3ZpZGUg Y29tbW9uIHN0cnVjdHVyZSBmb3IgdmFyaW91cyBPQU0gdGVjaG5vbG9naWVzLg0KDQpZb3VyIGlu dGVycHJldGF0aW9uIG9mIHdoZXJlIG9hbS1wcm90b2NvbHMgcmVzaWRlIG9uIGEgZGV2aWNlIGNv dWxkIGJlIGRpZmZlcmVudCBmcm9tIHNheSBBY2Vl4oCZcyBpbnRlcnByZXRhdGlvbiBvciBtaW5l LiBBbmQgd2hvIGlzIHRvIHNheSwgdGhhdCBpbnRlcnByZXRhdGlvbiBpcyB3cm9uZy4NCg0KVGhl IG90aGVyIHBvaW50LCB0aGF0IE1hcnRpbiBhbHNvIGJyb3VnaHQgdXAsIGlzIHRoYXQgdG9kYXkg YSBCRkQgY29uZmlndXJhdGlvbiB0eXBpY2FsbHkgbG9va3MgbGlrZSB0aGlzIGluIENMSSAodW5k ZXIgYW4gaW50ZXJmYWNlKS4NCg0KDQoNCkRldmljZShjb25maWctaWYpIyBiZmQgaW50ZXJ2YWwg NTAgbWluX3J4IDUwIG11bHRpcGxpZXIgNQ0KDQpZb3UgYXJlIGFza2luZyB0aGF0IHRoYXQgc2hv dWxkIG5vdyBsb29rIG1vcmUgbGlrZToNCg0KDQpEZXZpY2UjIGRldmljZXMgZGV2aWNlIGxpbWUg YmZkIGludGVydmFsIDUwIG1pbl9yeCA1MCBtdWx0aXBsaWVyIDUNCg0Kb3IgZXZlbjoNCg0KDQpE ZXZpY2UoY29uZmlnLWlmKSMgbGltZSBiZmQgaW50ZXJ2YWwgNTAgbWluX3J4IDUwIG11bHRpcGxp ZXIgNQ0KDQoNCg0KW1Fpbl06IFdoeSBCRkQgZXh0ZW5kaW5nIGZyb20gTElNRSBtb2RlbCBjaGFu Z2UgdGhpcyBDTEkgY29uZmlndXJhdGlvbiwgd2h5IEJGRCBleHRlbmRpbmcgZnJvbSByb3V0aW5n LWNmZyBub3QgY2hhbmdlIHRoaXMgQ0xJIGNvbmZpZ3VyYXRpb24/DQoNCkJhc2VkIG9uIHlvdXIg cmVhc29uIG9yIGNvbmNlcHQsIEl0IGxvb2tzIHlvdSBhcmUgcHJvcG9zaW5nDQoNCuKAnA0KDQpE ZXZpY2UjIGRldmljZXMgZGV2aWNlIHJ0IGJmZCBpbnRlcnZhbCA1MCBtaW5fcnggNTAgbXVsdGlw bGllciA1DQpvciBldmVuOg0KDQpEZXZpY2UoY29uZmlnLWlmKSMgcnQgYmZkIGludGVydmFsIDUw IG1pbl9yeCA1MCBtdWx0aXBsaWVyIDUNCg0K4oCcDQpieSBhdWdtZW50aW5nIHJvdXRpbmctY2Zn IHdpdGggQkZEIHNwZWNpZmljLg0KSW4gbXkgdW5kZXJzdGFuZGluZywgd2hldGhlciB5b3UgYXJl IHVzaW5nIGNvbW1vbiBzdHJ1Y3R1cmUgb2Ygcm91dGluZy1jZmcgb3IgdXNpbmcgY29tbW9uIHN0 cnVjdHVyZSBvZiBMSU1FIG1vZGVsIG9yIOKAnHVzaW5nIGl0cyBvd24gc3RydWN0dXJlIHdpdGhv dXQgY29uc2lkZXJpbmcgdG8gaW50ZXJhY3Qgd2l0aCBvdGhlciBPQU0gbW9kZWxz4oCdLCBpdCBk b2VzbuKAmXQgY2hhbmdlIENMSSB1c2VkIGZvciBCRkQgY29uZmlndXJhdGlvbi4NCkxldCBtZSBn aXZlIHlvdSBhbm90aGVyIGV4YW1wbGUsDQrigJwNCg0KRGV2aWNlIyBkZXZpY2VzIGRldmljZSBv c3BmIGludGVydmFsIDUwDQoNCuKAnA0KDQpEbyB5b3UgdGhpbmsgQ0xJIHdpbGwgYmUgY2hhbmdl ZCBhcyBmb2xsb3dzOg0KDQrigJwNCg0KRGV2aWNlIyBkZXZpY2VzIGRldmljZSBydCBvc3BmIGlu dGVydmFsIDUwDQoNCuKAnA0KV2hlbiBPU1BGIGNvbmZpZ3VyYXRpb24gbW9kZWwgaXMgZXh0ZW5k aW5nIGZyb20gcm91dGluZy1jZmc/IE15IHVuZGVyc3RhbmRpbmcgaXMgTm8uDQoNCkhvdyBkb2Vz IHRoYXQgbWFrZSBhbnkgbW9yZSBzZW5zZT8NCg0KT24gQXVnIDI4LCAyMDE1LCBhdCA2OjQwIFBN LCBRaW4gV3UgPGJpbGwud3VAaHVhd2VpLmNvbTxtYWlsdG86YmlsbC53dUBodWF3ZWkuY29tPj4g d3JvdGU6DQoNCkhpLCBNYWhlc2g6DQpKdXN0IHdhbnQgdG8gY2xhcmlmeS4NCkkgdGhpbmsgd2hh dCBSb3V0aW5nIERUIHRlYW0gaXMgZG9pbmcgaXMgY29tcGxlbWVudGFyeSB0byB3aGF0IExJTUUg V0cgaXMgZG9pbmcuDQp3aGF0IHJvdXRpbmcgRFQgdGVhbSBpcyBkb2luZyBpcyB0byBpZGVudGlm eSBhbGwgdGhlIGV4aXN0aW5nIG1vZGVscyBhbmQgdGhlIG1vZGVscyB0aGF0IGFyZSB1bmRlciBk ZXZlbG9wbWVudCBmb3IgT0FNLCByb3V0aW5nLCBpbnRlcmZhY2UsIGV0YywgdG8gc2VlIGhvdyB0 aGVzZSBtb2RlbHMgZm9yIGRpZmZlcmVudCB0ZWNobm9sb2d5LCBwcm90b2NvbCwgZmVhdHVyZShl LmcuLCBBQ0wsIFFvUykgY2FuIGZpdCB0b2dldGhlciB0byBmb3JtIGNvbXByZWhlbnNpdmUgc3Ry dWN0dXJlIGFuZCBkZWxpdmVyIHRoZSBzZXJ2aWNlLg0KDQpMSU1FIHdvcmsgd2FudHMgdG8gcHJv dmlkZSBjb21tb24gc3RydWN0dXJlIGZvciB2YXJpb3VzIE9BTSB0ZWNobm9sb2dpZXMgYnkgZGVm aW5pbmcgZ2VuZXJpYyBZQU5HIG1vZGVsIGZvciBPQU0uIEJ1dCB0aGUgZm9jdXMgaXMgdG8gZGVm aW5lIGdlbmVyaWMgWUFORyBtb2RlbCBmb3IgT0FNLg0KQmFzZWQgb24gTElNRSBXRyBjaGFydGVy IEFsbCB0aGUgdGVjaG5vbG9neSBzcGVjaWZpYyBtb2RlbHMgYXJlIGV4dGVuc2lvbiB0byB0aGlz IGdlbmVyaWMgbW9kZWwuIFRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGVzZSBPQU0gcmVsYXRl ZCBtb2RlbHMgY2FuIGRlcGljdGVkIGFzIGZvbGxvd2luZzoNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICstKy0rLSstKy0rDQogICAgICAgICAgICAgICAgICAgICAgICAgICB8IExJTUUgZ2Vu fA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgfE9BTSBZQU5HIHwNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICstKy0rLSstKy0rDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICArLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgICAg ICB8ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfCAgICAgICAgIHwgICAgICAgICAgICAg ICAgfA0KICAgICstKy0rLSstKy0rICAgKy0rLSstKy0rLSsgICArLSstKy0rLSstKyArLSstKy0r LSstKyAgICAgICstKy0rLSstKy0rDQogICAgfCBDRk0gICAgIHwgICB8IE1QTFMtVFAgfCAgIHwg TVBMUyAgICB8IHwgSVAgICAgICB8IC4gLiAufCAgZm9vICAgIHwNCiAgICB8T0FNIFlBTkcgfCAg IHxPQU0gWUFORyB8ICAgfE9BTSBZQU5HIHwgfE9BTSBZQU5HIHwgICAgICB8T0FNIFlBTkcgfA0K ICAgICstKy0rLSstKy0rICAgKy0rLSstKy0rLSsgICArLSstKy0rLSstKyArLSstKy0rLSstKyAg ICAgICstKy0rLSstKy0rDQogICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgIHwg ICAgICAgICAgIHwgICAgICAgICAgICAgIHwNCiAgICAgICAgICB8ICAgICAgICstKy0rLSstKy0r ICAgKy0rLSstKy0rLSsgICAgICAgfCAgICAgICAgICArLSstKy0rLSstKw0KICAgICAgICAgIHwg ICAgICAgfCBNUExTLVRQIHwgICB8IE1QTFMgICAgfCAgICAgICB8ICAgICAuIC4gLnwgIGZvbyAg ICB8DQogICAgICAgICAgfCAgICAgICB8c3ViIHRlY2ggfCAgIHxzdWIgdGVjaCB8ICAgICAgIHwg ICAgICAgICAgfHN1YiB0ZWNoIHwNCg0KVGhlIGV4YW1wbGUgZ2l2ZW4gYnkgQWNlZSBpcyB0byBw cm92aWRlIGEgbGlzdCBvZiBPQU0gcHJvdG9jb2xzIHdoaWNoIG5lZWQgdG8gYmUgcmVhZHkgdG8g Y29uZmlndXJlIGEgbmV0d29yayBpbnN0YW5jZS4gVGhlcmUgaXMgbm8gb3ZlcmxhcHBpbmcuDQoN Ci1RaW4NCuWPkeS7tuS6ujogbmV0bW9kIFttYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmdd IOS7o+ihqCBNYWhlc2ggSmV0aGFuYW5kYW5pDQrlj5HpgIHml7bpl7Q6IDIwMTXlubQ45pyIMjnm l6UgNzo0NA0K5pS25Lu25Lq6OiBBY2VlIExpbmRlbSAoYWNlZSkNCuaKhOmAgTogbmV0bW9kQGll dGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQrkuLvpopg6IFJlOiBbbmV0bW9kXSBNb3Rp dmF0aW9ucyBmb3IgU3RydWN0dXJpbmcgTW9kZWxzDQoNCkFjZWUsDQoNClRoaXMgaXMgZ29pbmcg dG8gYmVjb21lIHZlcnkgaW50ZXJlc3RpbmcgdmVyeSBxdWlja2x5LiBSb3V0aW5nIERUIGhhcyBk ZWNpZGVkIHRvIGRlZmluZSBhIGNvbnRhaW5lciBmb3Igb2FtLXByb3RvY29scy4gTElNRSBoYXMg ZGVjaWRlZCBpdCB3YW50cyB0byBkZWZpbmUgYSBnZW5lcmljIFlBTkcgbW9kdWxlIGZvciBhbGwg T0FNIGluIGRyYWZ0LXRpc3NhLWxpbWUteWFuZy1vYW0tbW9kZWwuDQoNCldoaWNoIG1vZGVsIGRv ZXMgQkZEIGF1Z21lbnQ/IE9yIGRpZCB5b3UganVzdCBraWxsIHRoZSB3aG9sZSBjaGFydGVyIGZv ciBMSU1FPz8NCg0KT24gQXVnIDI4LCAyMDE1LCBhdCA2OjIwIEFNLCBBY2VlIExpbmRlbSAoYWNl ZSkgPGFjZWVAY2lzY28uY29tPG1haWx0bzphY2VlQGNpc2NvLmNvbT4+IHdyb3RlOg0KDQpXaHkg ZG9lc27igJl0IGl0IGhlbHA/IEluIHRoZSBuZXh0IHJldmlzaW9uIG9mIHRoZSBSb3V0aW5nIFlB TkcgRFQgbW9kZWwsDQp3ZeKAmXZlIHN3aXRjaGVkIGZyb20gaW5jbHVkaW5nIHNwZWNpZmljIG1v ZGVscyB0byBkZWZpbmluZyBjbGFzc2VzIG9mDQptb2RlbHMgd2l0aCBpZGVudGl0aWVzLiBGb3Ig ZXhhbXBsZSwNCg0KZ3JvdXBpbmcgb2FtLXByb3RvY29scyB7DQogICAgIGNvbnRhaW5lciBvYW0t cHJvdG9jb2xzIHsNCiAgICAgICAgIGxpc3Qgb2FtLXByb3RvY29sIHsNCiAgICAgICAgICAgICBr ZXkgInR5cGUiOw0KICAgICAgICAgICAgIGxlYWYgdHlwZSB7DQogICAgICAgICAgICAgICAgIHR5 cGUgaWRlbnRpdHlyZWYgew0KICAgICAgICAgICAgICAgICAgICAgYmFzZSBvYW0tcHJvdG9jb2wt dHlwZTsNCiAgICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAgICAgICBtYW5kYXRvcnkgdHJ1 ZTsNCiAgICAgICAgICAgICAgICAgZGVzY3JpcHRpb24NCiAgICAgICAgICAgICAgICAgICAgICJU aGUgT3BlcmF0aW9ucywgQWRtaW5pc3RyYXRpb24sIGFuZA0KDQoNCiAgICAgICAgICAgICAgICAg ICAgICBNYWludGVuYW5jZSAoT0FNKSBwcm90b2NvbCB0eXBlLCBlLmcuLCBCRkQsDQoNCg0KICAg ICAgICAgICAgICAgICAgICAgIFRXQU1QLCBDRk0sIGV0Yy4iOw0KICAgICAgICAgICAgIH0NCiAg ICAgICAgICAgICBkZXNjcmlwdGlvbg0KICAgICAgICAgICAgICAgICAiTGlzdCBvZiBPQU0gcHJv dG9jb2xzIGNvbmZpZ3VyZWQgZm9yIGENCg0KDQogICAgICAgICAgICAgICAgICBuZXR3b3JraW5n IGluc3RhbmNlLiI7DQogICAgICAgICB9DQogICAgICAgICBkZXNjcmlwdGlvbg0KICAgICAgICAg ICAgICJDb250YWluZXIgZm9yIGxpc3Qgb2YgT0FNIHByb3RvY29scyBjb25maWd1cmVkIGZvciBh DQoNCg0KICAgICAgICAgICAgICAgbmV0d29ya2luZyBpbnN0YW5jZS4iOw0KICAgICB9DQogICAg IGRlc2NyaXB0aW9uDQogICAgICAgICAiR3JvdXBpbmcgZm9yIE9BTSBwcm90b2NvbHMgY29uZmln dXJlZCBmb3IgYQ0KDQoNCiAgICAgICAgICBuZXR3b3JraW5nIGluc3RhbmNlLiI7DQogfQ0KDQoN ClRoZW4gdGhlIGdyb3VwaW5nIGlzIGluY2x1ZGUgdGhlIG5ldHdvcmtpbmctaW5zdGFuY2VzLiAg QnkgZG9pbmcgdGhpcywgdGhlDQppbnRlbnQgaXMgdGhhdCBpdCB3b3VsZCBiZSBldmlkZW50IGFz IHRvIHdoZXJlIGEgcGFydGljdWxhciBtb2RlbCB3b3VsZCBiZQ0KZm91bmQuDQoNCk1haGVzaCBK ZXRoYW5hbmRhbmkNCm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPG1haWx0bzptamV0aGFuYW5kYW5p QGdtYWlsLmNvbT4NCg0KTWFoZXNoIEpldGhhbmFuZGFuaQ0KbWpldGhhbmFuZGFuaUBnbWFpbC5j b208bWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPg0KDQoNCg0K --_000_B8F9A780D330094D99AF023C5877DABA8481585Fnkgeml501mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiuvuagvOW8jyBD aGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRh dGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo5LjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0Kc3Bh bi5IVE1MQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiuvuagvOW8 jyI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1z cGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5DaGFy DQoJe21zby1zdHlsZS1uYW1lOiLmibnms6jmoYbmlofmnKwgQ2hhciI7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOuaJueazqOahhuaWh+acrDsNCglmb250LWZhbWls eTrlrovkvZM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0 OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIu MHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1D TiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSwgTWFoZXNoOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7lj5Hku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwv c3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dCI+IE1haGVzaCBKZXRoYW5hbmRhbmkgW21haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbV0N Cjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5Y+R6YCB5pe2 6Ze0PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiAyMDE1PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0Ij7lubQ8c3BhbiBsYW5nPSJFTi1VUyI+OTwvc3Bhbj7mnIg8c3BhbiBsYW5n PSJFTi1VUyI+MTwvc3Bhbj7ml6U8c3BhbiBsYW5nPSJFTi1VUyI+IDM6MTA8YnI+DQo8L3NwYW4+ PGI+5pS25Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO LVVTIj4gUWluIFd1PGJyPg0KPC9zcGFuPjxiPuaKhOmAgTxzcGFuIGxhbmc9IkVOLVVTIj46PC9z cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IEFjZWUgTGluZGVtIChhY2VlKTsgbmV0bW9kQGll dGYub3JnPGJyPg0KPC9zcGFuPjxiPuS4u+mimDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwv Yj48c3BhbiBsYW5nPSJFTi1VUyI+IFJlOiBbbmV0bW9kXSBNb3RpdmF0aW9ucyBmb3IgU3RydWN0 dXJpbmcgTW9kZWxzPG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlFp biw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5NeSBxdWVzdGlvbiB3 YXMgbW9yZSByaGV0b3JpY2FsLiBXaGF0IEkgd2FzIHRyeWluZyB0byBoaWdobGlnaHQgd2FzIHRo YXQgdGhlIHByb2Nlc3Mgb2YgdHJ5aW5nIHRvIGRlZmluZSBhIHN0cmljdCBvdmVyYWxsIHRyZWUg bGlrZSBzdHJ1Y3R1cmUgaXMgZnJhdWdodCB3aXRoIGlzc3Vlcy4NCjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltR aW5dOiBXaGF0IExJTUUgaXMgZG9pbmcgaXMgZGVmaW5lIHRoZSBzdHJ1Y3R1cmUgaW4gdGhlIHNh bWUgd2F5IGFzIHJvdXRpbmctY2ZnIGRpZCBhbmQgcHJvdmlkZSBjb21tb24gc3RydWN0dXJlIGZv ciB2YXJpb3VzIE9BTSB0ZWNobm9sb2dpZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+WW91ciBpbnRlcnByZXRhdGlvbiBvZiB3aGVyZSBv YW0tcHJvdG9jb2xzIHJlc2lkZSBvbiBhIGRldmljZSBjb3VsZCBiZSBkaWZmZXJlbnQgZnJvbSBz YXkgQWNlZeKAmXMgaW50ZXJwcmV0YXRpb24gb3IgbWluZS4gQW5kIHdobyBpcyB0byBzYXksIHRo YXQgaW50ZXJwcmV0YXRpb24gaXMgd3JvbmcuJm5ic3A7PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPlRoZSBvdGhlciBwb2ludCwgdGhhdCBNYXJ0aW4gYWxzbyBicm91Z2h0IHVwLCBpcyB0aGF0 IHRvZGF5IGEgQkZEIGNvbmZpZ3VyYXRpb24gdHlwaWNhbGx5IGxvb2tzIGxpa2UgdGhpcyBpbiBD TEkgKHVuZGVyIGFuIGludGVyZmFjZSkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5 bGU9Im1hcmdpbi10b3A6Ni4wcHQ7bGluZS1oZWlnaHQ6MTQuNHB0O2JhY2tncm91bmQ6d2hpdGU7 d2lkb3dzOiAxIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkRldmljZShjb25maWctaWYpIyBiZmQg aW50ZXJ2YWwgNTAgbWluX3J4IDUwIG11bHRpcGxpZXIgNTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+WW91IGFy ZSBhc2tpbmcgdGhhdCB0aGF0IHNob3VsZCBub3cgbG9vayBtb3JlIGxpa2U6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw cmUgc3R5bGU9Im1hcmdpbi10b3A6Ni4wcHQ7bGluZS1oZWlnaHQ6MTQuNHB0O2JhY2tncm91bmQ6 d2hpdGU7d2lkb3dzOiAxIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkRldmljZSMgZGV2aWNlcyBk ZXZpY2UgbGltZSBiZmQgaW50ZXJ2YWwgNTAgbWluX3J4IDUwIG11bHRpcGxpZXIgNTxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5vciBldmVuOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cHJlIHN0eWxlPSJtYXJnaW4tdG9wOjYuMHB0O2xpbmUtaGVpZ2h0OjE0LjRwdDtiYWNr Z3JvdW5kOndoaXRlO3dpZG93czogMSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5EZXZpY2UoY29u ZmlnLWlmKSMgbGltZSBiZmQgaW50ZXJ2YWwgNTAgbWluX3J4IDUwIG11bHRpcGxpZXIgNTxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLXRvcDo2LjBwdDtsaW5lLWhl aWdodDoxNC40cHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi10b3A6Ni4wcHQ7bGluZS1oZWlnaHQ6MTQuNHB0O2JhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+W1Fpbl06IFdoeSBCRkQgZXh0ZW5kaW5nIGZyb20gTElNRSBtb2RlbCBjaGFu Z2UgdGhpcyBDTEkgY29uZmlndXJhdGlvbiwgd2h5IEJGRCBleHRlbmRpbmcgZnJvbSByb3V0aW5n LWNmZyBub3QgY2hhbmdlIHRoaXMgQ0xJIGNvbmZpZ3VyYXRpb24/PG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tdG9wOjYuMHB0O2xpbmUtaGVpZ2h0OjE0LjRwdDti YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkJhc2VkIG9uIHlvdXIgcmVhc29uIG9yIGNvbmNlcHQsIEl0IGxvb2tz IHlvdSBhcmUgcHJvcG9zaW5nIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLXRvcDo2LjBwdDtsaW5lLWhlaWdodDoxNC40cHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7igJw8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi10b3A6Ni4wcHQ7bGlu ZS1oZWlnaHQ6MTQuNHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RGV2aWNlIyBkZXZpY2VzIGRldmljZSBy dCBiZmQgaW50ZXJ2YWwgNTAgbWluX3J4IDUwIG11bHRpcGxpZXIgNTxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5vciBldmVuOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwcmUgc3R5bGU9Im1hcmdpbi10b3A6Ni4wcHQ7bGluZS1oZWlnaHQ6MTQuNHB0O2JhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+RGV2aWNlKGNvbmZpZy1pZikjIHJ0IGJmZCBpbnRlcnZhbCA1MCBtaW5fcngg NTAgbXVsdGlwbGllciA1PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJn aW4tdG9wOjYuMHB0O2xpbmUtaGVpZ2h0OjE0LjRwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPuKAnDxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+YnkgYXVnbWVudGluZyByb3V0aW5nLWNm ZyB3aXRoIEJGRCBzcGVjaWZpYy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkluIG15IHVuZGVyc3RhbmRpbmcsIHdoZXRoZXIgeW91IGFyZSB1c2luZyBjb21tb24g c3RydWN0dXJlIG9mIHJvdXRpbmctY2ZnIG9yIHVzaW5nIGNvbW1vbiBzdHJ1Y3R1cmUgb2YgTElN RSBtb2RlbCBvciDigJx1c2luZyBpdHMgb3duIHN0cnVjdHVyZQ0KIHdpdGhvdXQgY29uc2lkZXJp bmcgdG8gaW50ZXJhY3Qgd2l0aCBvdGhlciBPQU0gbW9kZWxz4oCdLCBpdCBkb2VzbuKAmXQgY2hh bmdlIENMSSB1c2VkIGZvciBCRkQgY29uZmlndXJhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkxldCBtZSBnaXZlIHlvdSBhbm90aGVyIGV4YW1wbGUsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7igJw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cHJlIHN0eWxlPSJtYXJnaW4tdG9wOjYuMHB0O2xpbmUtaGVpZ2h0OjE0LjRw dDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkRldmljZSMgZGV2aWNlcyBkZXZpY2Ugb3NwZiBpbnRlcnZhbCA1 MDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLXRvcDo2LjBwdDts aW5lLWhlaWdodDoxNC40cHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7igJw8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi10b3A6Ni4wcHQ7bGluZS1oZWlnaHQ6MTQuNHB0O2Jh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+RG8geW91IHRoaW5rIENMSSB3aWxsIGJlIGNoYW5nZWQgYXMgZm9sbG93 czo8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi10b3A6Ni4wcHQ7 bGluZS1oZWlnaHQ6MTQuNHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+4oCcPG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tdG9wOjYuMHB0O2xpbmUtaGVpZ2h0OjE0LjRwdDti YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkRldmljZSMgZGV2aWNlcyBkZXZpY2UgcnQgb3NwZiBpbnRlcnZhbCA1 MDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLXRvcDo2LjBwdDts aW5lLWhlaWdodDoxNC40cHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7igJw8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2hlbiBPU1BGIGNvbmZpZ3VyYXRpb24gbW9kZWwg aXMgZXh0ZW5kaW5nIGZyb20gcm91dGluZy1jZmc/IE15IHVuZGVyc3RhbmRpbmcgaXMgTm8uPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5Ib3cgZG9lcyB0aGF0IG1ha2UgYW55IG1vcmUgc2Vuc2U/PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+T24gQXVnIDI4LCAyMDE1LCBhdCA2OjQwIFBNLCBRaW4gV3UgJmx0OzxhIGhyZWY9Im1h aWx0bzpiaWxsLnd1QGh1YXdlaS5jb20iPmJpbGwud3VAaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+SGksIE1haGVzaDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5KdXN0IHdhbnQgdG8gY2xhcmlmeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5JIHRoaW5rIHdoYXQgUm91dGluZyBEVCB0ZWFtIGlzIGRvaW5nIGlz IGNvbXBsZW1lbnRhcnkgdG8gd2hhdCBMSU1FIFdHIGlzIGRvaW5nLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPndoYXQgcm91dGluZyBEVCB0ZWFtIGlzIGRvaW5n IGlzIHRvIGlkZW50aWZ5IGFsbCB0aGUgZXhpc3RpbmcgbW9kZWxzIGFuZCB0aGUgbW9kZWxzIHRo YXQgYXJlIHVuZGVyIGRldmVsb3BtZW50IGZvciBPQU0sIHJvdXRpbmc8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4sPC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+aW50ZXJmYWNl LA0KIGV0YywgdG8gc2VlIGhvdyB0aGVzZSBtb2RlbHMgZm9yIGRpZmZlcmVudCB0ZWNobm9sb2d5 LCBwcm90b2NvbCwgZmVhdHVyZShlLmcuLCBBQ0wsIFFvUykgY2FuIGZpdCB0b2dldGhlciB0byBm b3JtIGNvbXByZWhlbnNpdmUgc3RydWN0dXJlIGFuZCBkZWxpdmVyIHRoZSBzZXJ2aWNlPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5MSU1FIHdvcmsgd2FudHMgdG8gcHJvdmlkZSBj b21tb24gc3RydWN0dXJlIGZvciB2YXJpb3VzIE9BTSB0ZWNobm9sb2dpZXMgYnkgZGVmaW5pbmcg Z2VuZXJpYyBZQU5HIG1vZGVsIGZvciBPQU0uIEJ1dCB0aGUgZm9jdXMgaXMgdG8gZGVmaW5lIGdl bmVyaWMgWUFORyBtb2RlbA0KIGZvciBPQU0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+QmFzZWQgb24gTElNRSBXRyBjaGFydGVyIEFsbCB0aGUgdGVjaG5vbG9n eSBzcGVjaWZpYyBtb2RlbHMgYXJlIGV4dGVuc2lvbiB0byB0aGlzIGdlbmVyaWMgbW9kZWwuIFRo ZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGVzZSBPQU0gcmVsYXRlZCBtb2RlbHMgY2FuIGRlcGlj dGVkDQogYXMgZm9sbG93aW5nOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB8IExJTUUgZ2VufDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8T0FNIFlBTkcgfDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mIzQz OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsgJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzsmbmJzcDsmbmJzcDsgJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzsmbmJzcDsmbmJzcDsgJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzsgJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0Mzs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsgfCBDRk0mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZu YnNwOyB8IE1QTFMtVFAgfCZuYnNwOyZuYnNwOyB8IE1QTFMmbmJzcDsmbmJzcDsmbmJzcDsgfCB8 IElQJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgLiAuIC58Jm5ic3A7IGZvbyZuYnNw OyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHxPQU0gWUFORyB8Jm5ic3A7Jm5ic3A7IHxPQU0gWUFORyB8 Jm5ic3A7Jm5ic3A7IHxPQU0gWUFORyB8IHxPQU0gWUFORyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHxPQU0gWUFORyB8PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7Jm5ic3A7Jm5ic3A7ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7Jm5i c3A7Jm5ic3A7ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7ICYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7Jm5ic3A7Jm5ic3A7ICYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 IE1QTFMtVFAgfCZuYnNwOyZuYnNwOyB8IE1QTFMmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC4g LiAufCZuYnNwOyBmb28mbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHxzdWIgdGVjaCB8Jm5ic3A7Jm5ic3A7IHxzdWIgdGVjaCB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfHN1YiB0ZWNoIHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5UaGUgZXhhbXBsZSBnaXZlbiBieSBBY2VlIGlzIHRvIHByb3ZpZGUgYSBsaXN0IG9m IE9BTSBwcm90b2NvbHMgd2hpY2ggbmVlZCB0byBiZSByZWFkeSB0byBjb25maWd1cmUgYSBuZXR3 b3JrIGluc3RhbmNlLiBUaGVyZSBpcyBubyBvdmVybGFwcGluZy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+LVFpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij7lj5Hk u7bkuro8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+OiBu ZXRtb2QgWzxhIGhyZWY9Im1haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOm5l dG1vZC1ib3VuY2VzQGlldGYub3JnPC9hPl08c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij7k u6Pooag8L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5NYWhlc2gNCiBKZXRoYW5hbmRh bmk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+5Y+R6YCB5pe26Ze0PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjogMjAxNTwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+5bm0PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPjg8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQiPuaciDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4y OTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+5pelPC9zcGFuPjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+Nzo0NDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij7m lLbku7bkuro8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ OiBBY2VlIExpbmRlbSAoYWNlZSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+5oqE 6YCBPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjo8c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFp bHRvOm5ldG1vZEBpZXRmLm9yZyI+bmV0bW9kQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0Ij7kuLvpopg8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+OiBSZTogW25ldG1vZF0gTW90aXZhdGlvbnMgZm9yIFN0cnVjdHVyaW5n IE1vZGVsczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkFjZWUsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhpcyBpcyBnb2luZyB0byBiZWNvbWUg dmVyeSBpbnRlcmVzdGluZyB2ZXJ5IHF1aWNrbHkuIFJvdXRpbmcgRFQgaGFzIGRlY2lkZWQgdG8g ZGVmaW5lIGEgY29udGFpbmVyIGZvciBvYW0tcHJvdG9jb2xzLiBMSU1FIGhhcyBkZWNpZGVkIGl0 IHdhbnRzIHRvIGRlZmluZSBhDQogZ2VuZXJpYyBZQU5HIG1vZHVsZSBmb3IgYWxsIE9BTSBpbiBk cmFmdC10aXNzYS1saW1lLXlhbmctb2FtLW1vZGVsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPldoaWNoIG1vZGVsIGRvZXMgQkZEIGF1Z21lbnQ/IE9yIGRpZCB5b3UganVz dCBraWxsIHRoZSB3aG9sZSBjaGFydGVyIGZvciBMSU1FPz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5PbiBBdWcgMjgsIDIwMTUsIGF0IDY6MjAgQU0sIEFjZWUgTGluZGVt IChhY2VlKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFjZWVAY2lzY28uY29tIj5hY2VlQGNpc2NvLmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPldo eSBkb2Vzbjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPuKAmTwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij50DQogaXQgaGVscD8gSW4gdGhlIG5leHQg cmV2aXNpb24gb2YgdGhlIFJvdXRpbmcgWUFORyBEVCBtb2RlbCw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij53ZTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PuKAmTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij52ZQ0K IHN3aXRjaGVkIGZyb20gaW5jbHVkaW5nIHNwZWNpZmljIG1vZGVscyB0byBkZWZpbmluZyBjbGFz c2VzIG9mPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+bW9kZWxz IHdpdGggaWRlbnRpdGllcy4gRm9yIGV4YW1wbGUsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+Z3JvdXBpbmcgb2FtLXByb3RvY29scyB7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Y29udGFpbmVyIG9hbS1wcm90b2NvbHMgezxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPmxpc3Qgb2FtLXByb3RvY29sIHs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5rZXkgJnF1b3Q7dHlwZSZxdW90Ozs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5sZWFmIHR5cGUgezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPnR5cGUgaWRlbnRpdHlyZWYgezxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPmJhc2Ugb2FtLXByb3RvY29sLXR5cGU7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDt9PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi Pm1hbmRhdG9yeSB0cnVlOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPmRlc2NyaXB0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+JnF1b3Q7VGhlIE9wZXJhdGlvbnMsIEFkbWluaXN0cmF0aW9uLCBhbmQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5NYWludGVuYW5jZSAoT0FNKSBwcm90b2NvbCB0eXBlLCBlLmcuLCBCRkQs PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VFdBTVAsIENGTSwgZXRjLiZxdW90Ozs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO308L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+ZGVzY3JpcHRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mcXVvdDtMaXN0IG9mIE9BTSBwcm90b2NvbHMg Y29uZmlndXJlZCBmb3IgYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPm5ldHdvcmtpbmcgaW5zdGFuY2UuJnF1b3Q7OzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7fTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5kZXNjcmlwdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiZxdW90O0NvbnRhaW5lciBmb3IgbGlzdCBvZiBPQU0gcHJvdG9jb2xzIGNvbmZp Z3VyZWQgZm9yIGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5uZXR3b3Jr aW5nIGluc3RhbmNlLiZxdW90Ozs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwO308L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+ZGVzY3JpcHRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mcXVvdDtHcm91cGluZyBmb3IgT0FNIHByb3Rv Y29scyBjb25maWd1cmVkIGZvciBhPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+bmV0d29ya2luZyBpbnN0YW5jZS4mcXVvdDs7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDt9PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPlRoZW4gdGhlIGdyb3VwaW5nIGlzIGluY2x1ZGUgdGhlIG5ldHdvcmtpbmctaW5zdGFuY2Vz LjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+QnkNCiBkb2luZyB0aGlzLCB0aGU8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5pbnRlbnQgaXMgdGhhdCBpdCB3b3VsZCBiZSBl dmlkZW50IGFzIHRvIHdoZXJlIGEgcGFydGljdWxhciBtb2RlbCB3b3VsZCBiZTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmZvdW5kLjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+TWFoZXNoIEpldGhh bmFuZGFuaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhy ZWY9Im1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbSI+bWpldGhhbmFuZGFuaUBnbWFpbC5j b208L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPk1haGVzaCBKZXRoYW5hbmRhbmk8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PGEgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tIj5tamV0aGFuYW5k YW5pQGdtYWlsLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B8F9A780D330094D99AF023C5877DABA8481585Fnkgeml501mbschi_--